複数の予約サイトの料金と残室を、エージェントが毎朝自社の料金台帳と突き合わせ、ずれの原因と直す案をまとめる

処理の起点を決める

毎朝6時の定時実行にします。 PMSの夜間の書き出しと前夜の配信が終わり、予約担当が出勤する前の時刻です。Schedule Trigger は秒〜月の間隔と Custom（Cron）を指定でき、曜日を限らず毎日動かします。

時刻の基準に注意してください。 Schedule Trigger はワークフローのタイムゾーン、無ければインスタンスの既定を使い、自前で立てたインスタンスの既定は America/New York です。 ワークフローの設定で Asia/Tokyo を指定します。

また、Schedule Trigger を起点にしたワークフローは、保存して公開（publish）しないと定時に動きません。 道具として呼ぶワークフローも、公開されていないと「Workflow is not active and cannot be executed」で失敗します。親だけ公開して道具を公開し忘れるのが、最初の週にいちばん起きる失敗です。

入力データを集める

質を決めるのは、料金台帳の「経路ごとの意図した差」の列です。 「海外のサイトは税・サービス料の見せ方が違う」「このサイトは会員割引をサイト側の負担で付けている」。これが台帳に無いと、意図した差がすべて「ずれ」として出ます。

残室の「取得した時刻」も必ず持ちます。 夜間の書き出しが止まった日に前日の残室で計算すると、昨夜埋まった部屋が「サイトに出ていない」と出ます。

サイトコントローラーの書き出しやAPIの有無は、製品と契約によって違い、この部分は利用環境に応じた個別実装になります。

データの取得方法を決める

ずれの計算に使うデータは、エージェントの外で先にそろえます。 エージェントが道具で引くのは、ずれと出た組み合わせの詳細だけです。

楽天トラベルの空室検索APIは、n8n の HTTP Request ノードで呼びます。applicationId と accessKey が必須で、施設番号は1回に最大15個まで指定できます。短い時間に大量に呼ぶと一定時間使えなくなることがあり、上限を超えると429が返ります。 HTTP Request ノードの Batching で呼ぶ速さを抑え、Never Error は使わずに2xx以外を失敗として扱います。呼ぶ日付は、繁忙日と翌14日と、前日にずれが出た日に絞ります。

AIへ渡す前に整形する

1. 鮮度の確認 … 残室と配信状況の取得時刻が当日の夜間の処理より後かを確かめます。古ければ見回りを止め、本部へ知らせます
2. 単位をそろえる … 1人あたりか1室あたりか、税・サービス料を含むか、何名利用の料金かを、経路ごとの決まりで台帳と同じ単位に直します。楽天トラベルは料金が1人単位か1室単位かを示す値が返るので、それで換算します
3. 出すつもりの値の計算 … 台帳の基本料金ランクに、プランごとの上乗せと経路ごとの意図した差を当てて、経路ごとの「出すつもりの値」を出します
4. ずれの判定 … 出すつもりの値と出ている値の差が、決めた幅を超えたものを候補にします。残室は1室でも違えば候補にします
5. 意図した差の除外 … 差が意図した差の一覧で説明できるものは、候補から外して「説明済み」として記録だけ残します
6. 前日との差分 … 前日も拾ったものか、新しく出たものかを付けます
7. 束ねる … 同じプランのコード・同じ配信の日時のものを1件にまとめます

2番目が、この構成の要です。 単位をそろえずに比べると、すべての経路が「ずれ」になります。 換算の規則は台帳の別のシートに持たせます。計算はすべて Code ノードで行い、AIには結果だけを渡します。

AIに処理させる

させるのは、計算が拾ったずれの原因を記録から決め、直す場所と直す案を作ることです。

原因の「サイト側の割引・会員料金」は、直す対象にしません。 施設の配信は正しいからです。ただし、その割引への参加を施設が把握していなければ questions_for_hq に回します。

最後の行は、意図して置いています。 この構成が見るのは、自社が決めた料金どおりに出ているかであって、サイト同士をそろえることではありません（第13章）。

指示内容を固定する

System Message に次の内容を入れます。

あなたは宿泊施設の販売部門で、予約サイトに出ている料金と残室のずれの
原因を調べる担当です。計算のノードから渡される「ずれ」の結果を前提に、
道具で記録を引き、原因と直す場所、直す案、施設への説明文を作ってください。

【前提として変えないこと】
- expected、observed、diff、unit は計算の結果です。書き換えないでください。
- 金額や部屋数の足し引き、税や人数の換算をしないでください。
  必要な数値は道具の結果から写してください。
- 料金台帳を正として扱ってください。台帳が古い疑いがあれば
  questions_for_hq に書き、台帳の値を変えないでください。

【道具の使い方】
1. まず get_distribution_log で、その経路・日付の配信が成功しているかを確認してください。
2. 配信が成功しているのに値が違う場合は get_plan_mapping を呼んでください。
3. 台帳より安く見えている場合は get_intended_diff を呼んでください。
4. 直近に料金を改定した日付なら get_rate_changes を呼んでください。
5. 同じ組み合わせを前にも指摘していれば get_past_findings で処置を確認してください。
同じ道具を同じ引数で2回呼ばないでください。

【原因の選び方】
- push_failed ....... 配信の記録に失敗またはエラーがある
- push_delayed ...... 改定の後の配信がまだ無い、または改定より前の値が出ている
- mapping_error ..... プランや部屋の紐付けが別のもの、または外れている
- channel_discount .. サイト側の割引・会員料金の登録で説明できる
- ledger_stale ...... 改定の記録より台帳が古いと読める
- unit_mismatch ..... 人数・税・1室か1人かの扱いが経路の決まりと違う
- unknown ........... 上のどれとも決められない
迷ったときは unknown を選び、questions_for_hq に理由を書いてください。

【厳守事項】
- 記録に無いことは書かないでください。サイト側の設定を推測しないでください。
- サイトの画面がどう見えているかは、楽天トラベルの API の結果以外は分かりません。
  分からないことは「配信の記録上は」と書き分けてください。
- 他の経路の料金にそろえる案を出さないでください。
  直す案は、台帳どおりに出すための操作だけにしてください。
- 料金の値上げ・値下げの提案をしないでください。
- 残室のずれは、売り止めの漏れか配信の失敗かを必ず区別してください。
- evidence には、判断の根拠にした記録の種類と識別子と、該当する文字列を写してください。
- 急ぎの段階は決めないでください。

【計算の結果】{discrepancy}
【前日の見回りの結果】{previous}
【施設と担当】{property}

「楽天トラベルの API の結果以外は分からない」を書かないと、AIは配信の記録が成功というだけで「サイト上も正しく表示されています」と書きます。 確かめていないことを確かめたように報告させないためです。

「他の経路にそろえる案を出さない」を明記しないと、AIは一番安いサイトに合わせる案を出します。 消したいのは台帳とのずれであって、経路の間の差ではありません。

出力形式を固定する

Require Specific Output Format を有効にし、Structured Output Parser をつなぎます。 次の形のJSONで受け取ります。

{
  "property_code": "",
  "run_date": "",
  "discrepancy": {
    "channel": "", "stay_date": "", "room_type": "", "plan_code": "",
    "kind": "rate | availability",
    "expected": 0, "observed": 0, "diff": 0, "unit": "",
    "observed_source": "rakuten_api | distribution_log"
  },
  "cause": "push_failed | push_delayed | mapping_error | channel_discount | ledger_stale | unit_mismatch | unknown",
  "evidence": [ { "source": "distribution_log | mapping | intended_diff | rate_change", "id": "", "quote": "" } ],
  "fix_location": "site_controller | channel_extranet | rate_ledger | pms | none",
  "proposed_fix": "repush | fix_mapping | stop_sell | update_ledger | check_channel_setting | no_action",
  "message_to_property": "",
  "questions_for_hq": [],
  "confidence": "high | low"
}

Structured Output Parser は、JSONの例から形を作る方法と、JSON Schema を書く方法の2つから選べます。例から作ると、すべての項目が必須として扱われます。 原因が channel_discount のときは proposed_fix を no_action にし、questions_for_hq が空のこともあるので、JSON Schema で書き、必須の項目を自分で決めます。 JSON Schema の $ref による参照は使えないとされているので、discrepancy の入れ子はその場に展開して書きます。

1つ目の理由は、原因と段階を別の層に置けることです。 段階は後段の規則で決めます。

残室のずれを料金より上に置いているのは、取り返しがつかないからです。 満室の日に入った予約は、お客様の旅行の予定そのものに響きます。

2つ目は、observed_source で「見えている」と「記録上そうなっている」を分けられることです。 楽天トラベルのAPIで確かめた値と、配信の記録から読んだ値を、一覧で見分けられます。

システムへ連携する

エージェントに渡す道具はすべて読み取りです。 投稿と記録への書き込みは、後段のノードが規則で行います。AIが書き込みを持たないので、料金が勝手に変わることはありません。 OpenAI Chat Model ノードの Sampling Temperature は高いほど誤りのおそれが増えるとされているので低めに置き、Timeout と Max Retries で見回り全体が止まらないようにします。

人が確認する

人が見るのは、エージェントが出した全件です。 ただし、見る深さを段階で変えます。

1. 段階Aを最初に見る … 施設の予約担当は、残室のずれから先に、サイトコントローラーかサイトの管理画面で売り止めを確かめます
2. confidence が low と unknown のものを見る … 原因が決まらないものは、紐付けか台帳の側に欠けがあることが多い
3. mapping_error を見る … 直す前に、同じプランのコードを使う他の経路に響かないかを確かめます
4. ledger_stale は本部が見る … 台帳を直すか、配信を直すかは本部のレベニュー担当が決めます
5. 段階B・Cは一覧で見る … 再配信で済むものはまとめて行います

目標は1件をならして10分です。

例外に対処する

上の3行で、誤った指摘の大半を止めます。 どれもAIの問題ではなく、データがそろわないまま計算した問題です。

記録を残す

• その日の計算の入力（台帳・残室・配信状況の取得時刻と件数、楽天トラベルのAPIで取れた日付と取れなかった日付）
• 経路・日付・部屋タイプごとの、出すつもりの値と出ている値、差、「説明済み」として外したもの
• エージェントの出力の全文と、Return Intermediate Steps で残した途中の過程
• 規則で決めた段階と、知らせた先
• 施設の担当者が直したかどうかと、直した日時と場所
• 翌朝の見回りで解消したかどうか

2つ目で「説明済み」を残すのは、意図した差の一覧が古くなるためです。 外したものの記録が無いと、いつから説明がつかなくなったかが分かりません。