「特定の部屋・プランだけ OTA から予約が来ない」を3層に分けて切り分ける手順

サイトコントローラー（チャネルマネージャー）を使っていると、同じ建物の中の1室だけ、 ある OTA からの受注がゼロという状態が起きる。ここで最もよくある誤診が 「マッピングが抜けているのだろう」で止めること。実際には抜けていないことが多く、 その場合は原因を探す場所そのものが間違っている。

この指示書は、原因を ①自分側の設定 ②OTA側の状態 ③実際に送っている値 の3層に分け、 層ごとに実値を読んで無罪／有罪を確定させる手順である。AI エージェントにそのまま読ませて使う。

0. 前提と置き換え

プレースホルダ	意味
<SC>	サイトコントローラーの管理画面ドメイン
<PROPERTY_ID>	施設ID
<ROOM_ID_問題>	受注ゼロの部屋の内部ID
<ROOM_ID_対照>	同じ建物で受注がある部屋の内部ID（必須。比較対象なしに結論を出さない）
<CHANNEL>	対象OTAの識別子（管理画面のページ名やAPIパスに出る）

この手順は全部読み取りだけで完結する。 設定を書き換えない。書き換えは原因が確定してから別作業。

1. まず「本当にゼロか」を数え直す（ここで前提が崩れることがある）

受注ゼロの主張は集計窓の取り方に強く依存する。実例では「直近10ヶ月で0件」が、 窓を21ヶ月に広げると 2件あった（しかも片方は高単価の連泊）。 「ゼロが続いている」のか「途中で止まった」のかで原因はまったく別物になる。

• 窓を2通り以上で数える（例: 直近10ヶ月／過去3年）。
• 予約APIは月単位の窓で取り、予約IDで重複除去する。窓の境界で同じ予約が二重に出る。
• ページング（nextPage 等）が真なら、その窓を半分に割って再取得する。 「上限100件で黙って切る」実装が多く、切られたことに気づかないまま「0件」と報告する事故が起きる。
• キャンセル済みも別カウントで残す。「一度も来ていない」と「来たが全部消えた」は原因が違う。
• 出力は **部屋 × チャネル の行列（件数 / 泊数 / ADR）**にする。1室だけ見ると異常が異常に見えない。

判定は人間の読解でなく exit code にする（例: --expect-zero "<部屋>:<チャネル>" を持たせ、 1件でもあれば exit 1）。あとで「本当にゼロだったのか」を機械で再確認できる。

2. 三層それぞれの実値を読む

層① 自分側の設定（マッピングと同期フラグ）

管理画面の当該OTA設定ページを開き、入力欄の value を読む。

<SC>/control3.php?pagetype=syncroniser<CHANNEL>&propid=<PROPERTY_ID>

注意: マッピングIDは <input> の value なので、ページのテキスト（innerText）には出ない。 テキストだけ読んで「空欄だ」と判断するのが誤診の最大の入口。ブラウザ自動化で document.querySelectorAll('input,select,textarea') の name と value を列挙する。

見るもの: OTA側の施設ID / 部屋ID / 料金プランID が入っているか、在庫・価格・予約の同期チェックが ON か。 対照部屋と並べる。 差分が「IDと名前だけ」なら自分側は無罪。

層② OTA側の状態（掲載が生きているか）

多くのサイトコントローラーには「OTAからマッピング情報を取り直す」エンドポイントがある。

<SC>/api/<CHANNEL>/getmapping.php?roomid=<ROOM_ID_問題>

ここに OTA が返す 掲載の生死（live_status 等）・料金プランの販売期間・最小泊数・ 先行予約可能日数・キャンセル規定が出る。対照部屋の同じXMLと diff する。 差分が id と名前だけなら、OTA も「生きている」と言っていることになる。

層③ 実際に送っている値（在庫・価格）

<SC>/api/<CHANNEL>/showdata.php?roomid=<ROOM_ID_問題>

日付ごとの在庫数・価格・最小泊数の表が数百行出る。先頭数行で判断してはいけない。 実例では先頭5行が closed だったため「全期間閉じている」と誤読しかけたが、 365行を数えると閉じているのは 31日（既存予約で埋まっている日）だけだった。 必ず全行を集計し、「在庫>0 の日数 / 全日数」を対照部屋と比べる。 ページ上の「最終更新時刻」も見る（今日の時刻なら送信は生きている）。

履歴（誰がいつ触ったか）

<SC>/control3.php?pagetype=reportactivity

数年分の設定変更ログが取れる。全文を落として当該OTA名で grep する。 0件なら「途中で貼り替えられた」説は消える（実例では2年分でヒット0）。

3. 三層すべて正常だったときの結論の書き方

「自分側は無罪」までしか言えない。 残る原因は OTA のマーケット側 （検索への露出・写真やコンテンツの充足・重複掲載としての統合・ランキング）で、 サイトコントローラーからは読めない。ここを推測で埋めてはいけない。

ゲスト目線のページを開いて確かめようとして失敗することがある。実例で起きたこと:

• URL の ?hid=<施設ID> パラメータが無視され、別の掲載が表示される。
• URL スラッグを推測するとすべて別掲載の canonical URL へ寄せられる（緩い照合）。
• 検索ページは SPA で、URLパラメータでは検索が実行されない（トップページが出るだけ）。
• 検索エンジンの索引の有無は判断材料にならない（受注のある対照部屋も索引されていなかった）。

→ 取れなかったら「取れなかった」と書く。 スクショは自分で開いて目視し、 「bot にブロックされたのか」「URLの組み方が違うだけか」を区別して書く。 最後の1歩が OTA の管理画面（extranet）しかないなら、人がやる1操作として明示して渡す （何を・どこで・どの2件を並べて見るか）。

4. 金額を必ず添える（優先度を誤らないため）

「ゼロが16ヶ月」は不整合の信号として価値があるが、取り戻せる額とは別。

• 同じOTAの他室の実績中位値 × ADR で概算する。
• その部屋が他チャネルで既に埋まっているかを見る。 実例では問題の部屋が 室泊数で全室トップだったため、OTAを直しても他チャネルと食い合い、純増は小さいと結論できた。
• 概算を出してから優先度（高/中/低）を書く。額を書かない報告は必ず過大評価される。

5. ツール化のときの注意（実際に踏んだ罠）

• 管理画面を読むスクリプトは「新しいタブ」を開く。 既存タブを使い回す実装だと、 同じブラウザで作業している別プロセス（別の作業セッション）の画面を巻き込んで壊す。 読み終わったら自分が開けたタブだけ閉じる（ブラウザは閉じない）。
• ログインに CAPTCHA があるなら迂回しない。人が1回ログインした窓を開けたままにし、 以降はその生きたブラウザにデバッグポート経由で繋ぐ。
• 集計スクリプトを LLM に書かせたら、要約の数値を検算する。 実例では 「総レコード数」「分割再取得の回数」を実測せず式で捏造していた（件数 + 窓数×100）。 カウンタを実際に増やす実装へ直した。数値は独立に別経路で数えて突き合わせる。
• シェルのヒアドキュメントで整形スクリプトを流すときは必ず引用付き（<<'EOF'）にする。 引用なしだと本文中のバッククォートがコマンド置換として実行され、 重い集計コマンドが起動してタイムアウトする（実際に発生）。

6. 完了条件のテンプレ

1. 部屋 × チャネル行列を2つの窓で出し、ゼロの組を exit code で確定した。
2. 層①②③と履歴の実値を、問題の部屋と対照部屋の両方について取得した。
3. 差分を列挙し、「自分側は無罪／有罪」を明言した。
4. ゲスト目線の実表示を取れたか取れなかったかを書いた（取れなければ理由も）。
5. 概算金額と優先度を書いた。
6. 過去に書いた誤った仮説（「マッピング欠落の疑い」等）を打ち消す追記を元ファイルに入れた。