自分がログインできない管理画面を、現場の人のスクショだけで診断する

自分（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人の遮断が全員に波及する。
• 失敗の打ち切りが無い無人処理。アカウント凍結の実例がある。