# 自分がログインできない管理画面を、現場の人のスクショだけで診断する 自分（AI）が入れない SaaS・OTA・広告・決済の管理画面について、**その画面を開ける人に スクショを撮ってもらうだけで原因を特定する**ための手順書。依頼文の型と、集めた数字の読み方、 そして「人に二度手間をかけさせない」ための自己点検までを含む。 想定する場面: - 売上・配信・在庫などの指標が特定の日を境に落ちたが、原因が管理画面の中にしかない - 自分のログインが無効・未発行・2要素で止まっている - 自動化ブラウザでログインするのは禁止、またはアカウント凍結のリスクがある 前提は**相手が非エンジニア**であること。1往復の失敗が丸1日の遅れになる。 --- ## 0. 着手前の3つの確認 ### 0-1. 他に誰が入れるかを数える 「自分が入れない」を「その画面は見られない」と書かない。事業用の管理画面は**ほぼ必ず複数人**が アクセスできる。運用担当・経理・代理店・前任者を数える。ここを飛ばすと、見られる画面を 「唯一の計測器が失われた」と評価して何日も止まる。 止まったのが**アカウント**か**ユーザー**かも区別する。掲載・配信が生きているなら、 止まっているのは人であって事業ではない。 ### 0-2. 自分で取れる経路を、頼む前に全部叩く 「できない」も断定である。**そのターンで実際に叩いて失敗した記録だけが証拠**になる。 最低でもこの順で試し、結果を1行ずつ残す。 | 経路 | 確かめ方 | |---|---| | 公式 API / CLI | 認証情報の在処を探し、1回叩く | | 既存の連携（MCP コネクタ等） | **誰のアカウントに紐づいているか**を結果から読む | | サービスアカウント＋権限委譲 | 鍵ファイルの実在を確認してから叩く | | 公開側のページ | ログイン不要で同じ値が出ないか | ### 0-3. 計測器を対照群で検定する 「0件だった」は「存在しない」ではない。**見えるはずのものが見えるか**を先に試す。 例: 共有メールボックスから他人宛の受信を探して0件だった時、 `to:<その人>` で検索すると数件ヒットしたが、**全件に自分も宛先として入っていた**。 ＝ その人の受信箱そのものは見えていない。この検定をしないと「届いていない」と誤断定する。 --- ## 1. 依頼文の型 ### 1-1. クリック手順ではなく「探す内容」で書く 自分が見たことのない画面の操作手順を書くと、存在しないラベル名を創作して相手を迷わせる。 代わりに**何が写っていればいいか**を書き、見つからない時の逃げ道を必ず添える。 ★2 「表示回数」「検索結果に表示された回数」の推移グラフ 期間は <開始月> 〜 今日 が入るようにできるだけ広く。 「分析」「パフォーマンス」のような名前のメニューにあることが多いです。 メニューの名前は画面によって違うので、見つからないものは飛ばして、 代わりに「メニューが全部見える状態のトップ画面」を1枚送ってください。 実績: この形で依頼した16項目のうち14項目が一発で目的の画面だった。外した2つは、 **存在を確かめずに書いた項目**だった。 ### 1-2. 自分がすでに出した結論を必ず持ち込む 分析と依頼文を別々に書くと、直前に確定させた事実が依頼文に載らない。 とくに**否定の結論**（「そのユーザーは存在しない」「その経路は使えない」）は、 書かないと相手が探しに行って必ずエラーを踏む。現場には古い情報が残っている。 ### 1-3. 読み戻しは成功側ではなく失敗側に置く 「終わったら一覧に戻って結果を確認してください」と**成功したあとの節**に書くと、 途中で止まった時には実行されない。**失敗した時こそ読み戻しが要る** （裏で処理されている／重複しているかもしれない）。 ### 1-4. 失敗条件を症状の列挙で書かない 「ボタンが**押せない**場合は止めてください」と書いたら、実際に起きたのは 「**押せるが反応しない**」で、条件に当たらず相手は何度も押した。列挙は漏れる。包括で書く。 手順のどこでも、思ったとおりに進まなかったら、 探さずに、そのときの画面をそのまま1枚撮って送ってください。 ボタンが無い、名前が違う、エラーが出た、何も起きない、どれでも同じ対応です。 ### 1-5. 打ち切りを必ず入れる 回数か時間、できれば両方。**同じ操作の反復は、サービス側から異常アクセスに見える。** 2回試して駄目なら、3回目は押さずにその画面を1枚送ってください。 5分ほど触って進まなければ、そこで止めていただいて結構です。 ### 1-6. 1通で完結させる 入力値・URL・施設やアカウントの識別子を全部その1通に書く。相手に過去ログを探させない。 複数のアカウント・物件を扱う画面なら、**どれを選んだ状態で作業するか**を冒頭に置く。 一覧画面は見分けがつきにくく、取り違えると別の担当に話が回る。 ### 1-7. 答えが別の依頼で返るなら、二重に聞かない 依頼を出す前に「この答えは、いま飛んでいる別の依頼で返ってくるか」を1回問う。 返るなら聞かずに待つ。 ### 1-8. 撮り方を毎回書く OS別のショートカット、URL 欄と日付を入れること、長い画面は分割可、 **写真ではなくスクリーンショット**であること。 --- ## 2. 集めた数字の読み方 ### 2-1. 期間合計で「落ちていない」と判定しない 合計は窓の中のスパイク1つで簡単に埋まる。**必ず月次・週次に割る。** 実例: 過去365日の表示回数は対競合 −8.4% で「露出は無事」に見えたが、 月次にすると後半は明確に落ちていた。合計を押し上げていたのは、窓の前半にある 通常月の約2倍のスパイク1か月分だった。合計は「いつ」を消す量なので、 **断絶を探している時には原理的に使えない。** ### 2-2. ファネルは段ごとに時系列を並べ、先に落ちた段を探す 表示 → クリック → 到達 → 成約 のような多段指標は、**どの段が先に落ちたか**で 原因側と結果側が分かれる。多くのプラットフォームは成約率を順位の決定要因にしているので、 成約が落ちる → 順位が下がる → 露出が減る、の順で伝播する。 実例の月次（概数）: | 月 | 表示回数 | ページ到達 | 成約 | 競合の成約 | |---|---:|---:|---:|---:| | 断絶の前月 | 109,000 | 3,230 | 73 | 56 | | 断絶の月 | 74,000 | 2,220 | **7** | 56 | | +1ヶ月 | 39,000 | 1,930 | 9 | 41 | | +2ヶ月 | 44,000 | 1,180 | 8 | 57 | 成約が 73→7（−90%）に落ちた月、**到達は前月の69%あった**。人は来ていた。 到達→成約の転換率は 2.26% → 0.32%。競合は同月 56→56 で横ばい。 露出が競合を下回るのは**その2ヶ月後から**。 → **打ち手の順番が決まる。** 露出施策を先に打っても、転換率が 0.3% のままでは順位は戻らない。 ### 2-3. 「期日超過」は、同じ表の過去行で決済周期を数えてから言う 請求が1日過ぎているだけで警告を上げない。過去の請求日→支払い日の間隔が 毎回ほぼ同じなら自動決済であり、**滞納ではなく未反映**。人が都度振り込む運用で 12〜15日の規則性は出ない。 ### 2-4. 画面に出ている集計値を根拠に使う前に、桁を別経路と突き合わせる 実例: プロモーション一覧の「収益」列が、同期間の請求額とも自前の受注データとも 1桁以上合わなかった（表示期間の指定が効いていないか、過去実績を引き継いでいる）。 **桁が合わない列は根拠に使わない。** ### 2-5. 1つの設定面を見て「設定は同じ」と言わない API に出ない管理画面専用の欄がある。API 全数走査で0件でも「存在しない」の証拠にならない。 --- ## 3. 自己点検（依頼を送る直前に5つ） 1. このセッションで確定させた事実のうち、相手の操作を変えるものを全部書いたか。とくに否定の結論。 2. 読み戻しの指示を、失敗側の節に置いたか。 3. 失敗条件を包括で書いたか（症状の列挙になっていないか）。 4. 打ち切り（回数・時間）を書いたか。 5. この答えは、いま飛んでいる別の依頼で返ってこないか。 加えて、報告に次の2行を必ず入れる。自分の報告に「未確認」と書いて安心し、 **実際に操作する人には伝えていない**という取り違えを防ぐ。 確認済み: <どの画面をどう見たか> 未確認: <何を見ていないか。ラベル名や現在値が違う可能性> --- ## 4. やってはいけないこと - **検知回避フラグ付きブラウザで認証情報を入力する**（人が手で打つ場合も含む）。 ログイン画面が端末指紋を収集している場合、それ自体が「セキュリティ上の理由」を作る。 ログインは通常のブラウザで行い、必要ならセッション Cookie を自動化側へ渡す。 - ボット検知・CAPTCHA の突破や回避。検知されたら透明化して人に委ねる。 - 共有 ID の使い回しを前提にした設計。誰の操作か追えず、1人の遮断が全員に波及する。 - 失敗の打ち切りが無い無人処理。アカウント凍結の実例がある。 ---