# 「特定の部屋・プランだけ OTA から予約が来ない」を3層に分けて切り分ける手順サイトコントローラー（チャネルマネージャー）を使っていると、**同じ建物の中の1室だけ、ある OTA からの受注がゼロ**という状態が起きる。ここで最もよくある誤診が **「マッピングが抜けているのだろう」で止めること**。実際には抜けていないことが多く、その場合は原因を探す場所そのものが間違っている。この指示書は、原因を **①自分側の設定 ②OTA側の状態 ③実際に送っている値** の3層に分け、層ごとに**実値を読んで**無罪／有罪を確定させる手順である。AI エージェントにそのまま読ませて使う。 ## 0. 前提と置き換え | プレースホルダ | 意味 | |---|---| | `` | サイトコントローラーの管理画面ドメイン | | `` | 施設ID | | `` | 受注ゼロの部屋の内部ID | | `` | **同じ建物で受注がある**部屋の内部ID（必須。比較対象なしに結論を出さない） | | `` | 対象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 を読む**。 /control3.php?pagetype=syncroniser&propid= **注意: マッピングIDは `` の value なので、ページのテキスト（innerText）には出ない。** テキストだけ読んで「空欄だ」と判断するのが誤診の最大の入口。ブラウザ自動化で `document.querySelectorAll('input,select,textarea')` の `name` と `value` を列挙する。見るもの: OTA側の施設ID / 部屋ID / 料金プランID が入っているか、**在庫・価格・予約の同期チェックが ON か**。 **対照部屋と並べる。** 差分が「IDと名前だけ」なら自分側は無罪。 ### 層② OTA側の状態（掲載が生きているか）多くのサイトコントローラーには「OTAからマッピング情報を取り直す」エンドポイントがある。 /api//getmapping.php?roomid= ここに OTA が返す **掲載の生死（`live_status` 等）・料金プランの販売期間・最小泊数・先行予約可能日数・キャンセル規定**が出る。**対照部屋の同じXMLと diff する。** 差分が id と名前だけなら、OTA も「生きている」と言っていることになる。 ### 層③ 実際に送っている値（在庫・価格） /api//showdata.php?roomid= 日付ごとの在庫数・価格・最小泊数の表が数百行出る。**先頭数行で判断してはいけない。** 実例では先頭5行が `closed` だったため「全期間閉じている」と誤読しかけたが、 365行を数えると閉じているのは **31日（既存予約で埋まっている日）だけ**だった。必ず**全行を集計**し、「在庫>0 の日数 / 全日数」を対照部屋と比べる。ページ上の「最終更新時刻」も見る（今日の時刻なら送信は生きている）。 ### 履歴（誰がいつ触ったか） /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. 過去に書いた誤った仮説（「マッピング欠落の疑い」等）を**打ち消す追記**を元ファイルに入れた。 ---