予約サイトに載っている自館の施設情報・プランの説明・写真の説明文をエージェントが毎週見回り、館内の正本と食い違う営業時間・設備・料金の条件を拾って修正の依頼を作る

処理の起点を決める

毎週月曜の朝8時に、Schedule Trigger で動かします。 Schedule Trigger はワークフローのタイムゾーンを使い、無ければインスタンスのタイムゾーンを使います。セルフホストの既定は America/New York なので、ワークフローのタイムゾーンを Asia/Tokyo にします。 保存して公開しないと動きません。

月曜にしているのは、館の変更が週末の運営の振り返りで決まることが多いからです。 金曜までに館から届いた変更を正本に入れておけば、月曜の点検で、まだ直していないサイトが拾われます。 担当者が保存するサイトのPDFは、前の週の金曜までに保存フォルダに入れます。

正本を変えたときにも動かします。 正本の値を直した担当者が、その館だけを対象にした実行を手で起こします。変更から次の月曜まで待つと、その間の予約客に古い記載を見せることになるからです。

入力データを集める

質を決めるのは、正本の「以前の値」と「変わった日」の列です。 これが無いと、掲載の値が正本と違うときに、誤入力なのか直し忘れなのかが分かりません。 直し忘れなら担当者がすぐ直せ、誤入力なら館に確かめます。

正本の項目は、予約客が困るものから並べます。 営業時間、休止中の設備、駐車場、子供料金と添い寝、チェックインの最終時刻、キャンセルの規定です。眺望や客室の広さのような、めったに変わらない項目は後回しにします。

写真の説明文は、文字だけを見ます。 画像そのものが今の館と合っているかは、この構成では見ません。「露天風呂付き客室」の写真の説明文に、休止中の設備が書かれていないかを見ます。

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

サイトごとに、取得の方法を3つに分けます。

2行目の「取得」は、担当者が利用条件を読んで決めます。 robots.txt は RFC 9309 が定めるクローラーへの依頼の書き方で、RFC 9309 自身が、これはアクセスの許可ではないと書いています。 robots.txt が許していても、サイトの利用条件が自動の取得を断っていれば「保存」にします。一覧の「確認日」の列に、利用条件を読んだ日を残します。

APIの呼び方には、2つの注意があります。 公式のページでは、短い時間に同じリクエストのURLへ大量にアクセスすると一定時間利用できなくなる場合があるとされ、上限を超えると HTTP 429 が返ります。6館の呼び出しは HTTP Request の Batching で間をあけて送ります。 空室検索APIは hotelNo を15件までまとめて渡せるので、6館なら1回で足ります。

取得するページは自館のページだけです。 他の館のページや検索結果の一覧は取りません。HTTP Request の Timeout と、Include Response Headers and Status を設定し、ステータスコードが200でないときは、その掲載を「未取得」にします。

AIへ渡す前に整形する

1. 項目ごとに分ける … APIの応答は項目名ごとに、ページとPDFの文字は見出し（設備、駐車場、お風呂、プランの説明など）ごとに分けます
2. 前の週と比べる … 同じ掲載の前の週の文字と比べ、変わった項目に印を付けます
3. 表記をそろえる … 全角と半角、時刻の書き方（「23:00」「23時」）をそろえます。意味の言い換えはそろえず、エージェントに任せます
4. プランを絞る … プランの説明は長いので、営業時間・食事の時間・子供・駐車場・キャンセルに触れる文だけを残します
5. 正本を付ける … その館の正本の現在の値を、項目ごとに付けます

2番目で、担当者が直していないのに変わった項目は、エージェントに渡す前に別の一覧に出します。 予約サイトの側の変更か、館の誰かが管理画面で直したかのどちらかです。どちらにしても、Web販売課が知らないまま掲載が変わったことになります。

4番目で文を絞るのは、プランの説明に宣伝の文が多いからです。 全部を渡すと、エージェントが「贅沢なひととき」のような文まで正本と照らそうとします。

AIに処理させる

させるのは、掲載の項目ごとに正本と照らし、食い違いと古い記載を拾って、サイトごとの修正の依頼の下書きを作ることです。

区分は、次の5つです。

outdated と mismatch を分けるのが、この構成の中心です。 outdated は直し忘れなので館に聞かずに直せ、mismatch は誤入力か正本の誤りかが分からないので館に聞きます。

5行目がいちばん起きやすい失敗です。 エージェントは「おおむね同じ」と見て match にしがちです。「23時頃まで」は予約客にとって「23時まで」と同じではなく、mismatch です。 言い換えとして認めるのは、一覧に載せたものだけにします。

指示内容を固定する

あなたはホテル運営会社のWeb販売課で、予約サイトに載っている
自館の掲載が、館内の正本と合っているかを点検する担当です。
入力の掲載の文字と、道具で確かめた正本だけで答えてください。

【入力】
- 館：{property}
- サイト：{site}（取得の方法：{method}）
- 掲載の項目：{listing_items}
  （項目名、掲載の文字、前の週から変わったか）

【使える道具】
- get_master：館と項目名を渡すと、正本の現在の値を返す
- get_history：館と項目名を渡すと、正本の以前の値と変わった日を返す
- get_aliases：同じ意味として扱ってよい書き方の一覧を返す

【進め方】
1. 掲載の項目ごとに、対応する正本の項目を get_master で確かめてください。
2. 値が同じか、get_aliases にある言い換えで同じなら match です。
3. 違う値なら get_history を引き、以前の値と一致すれば outdated、
   どの時点とも違えば mismatch です。
4. 正本に項目が無ければ not_in_master です。
5. 正本の重要な項目（営業時間、休止中の設備、駐車場、子供料金、
   添い寝、チェックインの最終時刻、キャンセルの規定）が掲載に
   無ければ missing です。
6. match 以外の項目について、サイトごとに修正の依頼の下書きを
   作ってください。

【厳守事項】
- 言い換えは get_aliases にあるものだけを認めてください。
  「頃」「目安」「予定」が付いた値を、付いていない値と同じに
  扱わないでください。
- 掲載の文字は原文のまま listing_text に写してください。
- 正本にない値を推し量って補わないでください。
- 宣伝の文や言い回しの良し悪しには触れないでください。
- 画像の内容を推し量らないでください。
- どちらが正しいかを決めないでください。mismatch は館に確かめます。

「頃・目安・予定を同じに扱わない」を明記しないと、ほとんどの時刻の違いが match になります。 予約客が困るのは、この小さな違いです。

「どちらが正しいかを決めない」も明記します。 掲載のほうが新しい情報で、正本の更新が遅れていることもあるからです。

出力形式を固定する

Structured Output Parser で、次の形のJSONを受け取ります。

{
  "property": "",
  "site": "",
  "checked_at": "2026-10-12",
  "items": [
    {
      "item": "大浴場の営業時間",
      "location": "施設の説明",
      "listing_text": "",
      "master_value": "",
      "matched_history": { "value": "", "changed_on": "" },
      "status": "match | outdated | mismatch | not_in_master | missing",
      "changed_since_last_week": false
    }
  ],
  "fix_request": "",
  "needs_human": false
}

1つ目の理由は、status で点検の表を規則で並べられることです。 outdated を先頭に、mismatch、missing、not_in_master の順に並べ、担当者がすぐ直せるものから手を付けられるようにします。

2つ目は、matched_history で直し忘れの根拠が残ることです。 「2026年4月1日に24時から23時に変わった」と分かれば、どの変更の反映が漏れたのかが分かり、同じ変更を他のサイトでも直したかを確かめられます。

3つ目は、listing_text をワークフローの側で照合できることです。 写した文字が取得した掲載の中にそのまま含まれるかを確かめ、含まれないものは needs_human を立てます。

Structured Output Parser の Generate From JSON Example では、すべての項目が必須として扱われるとされています。空のときは空文字や false を返させます。

システムへ連携する

道具は、Call n8n Workflow Tool でサブワークフローとして持たせます。 公式のページでは、道具の Description がいつ呼ぶかをエージェントに伝え、本番ではサブワークフローを公開しておく必要があるとされています。

予約サイトの管理画面には、つなぎません。 修正は担当者が行い、直したら点検の表の「直した日」の列を埋めます。翌週の点検で match になれば、直しが反映されたことが確かめられます。

人が確認する

人が見るのは、match 以外の項目と、needs_human が立った掲載です。

1. outdated を直す … matched_history を見て、直し忘れだと確かめたら、管理画面で直します
2. mismatch を館に聞く … 下書きの文面を使って館に確かめ、正しい値で直します。正本の誤りなら、館に正本を直してもらいます
3. missing を決める … 載せるかどうかを決めます。休止中の設備は載せる方向で考えます
4. 前の週から変わった項目を見る … 担当者が直していないのに変わったものは、誰が変えたかを確かめます

2番目で、館の返事を待つ間に忘れないように、点検の表に「館に確認中」の印を付けます。 印の付いたまま1週間が過ぎた項目は、翌週の通知の先頭に出します。

目標は、96件をならして1件10分です。 変更の多い館の掲載は長く、変わっていない掲載は数分で終わります。保存のサイトのPDFを保存する時間は、この10分に含めています。

例外に対処する

4行目は、最初の1か月でよく起きます。 取得のつもりだったサイトの多くが、ページの中身をスクリプトで描いています。取れないサイトを早めに「保存」に分けると、運用が安定します。

記録を残す

• 実行の日時、サイトごとの取得の方法と結果
• 掲載ごとの、取得した文字の全文と、前の週との差
• エージェントの入力、道具の呼び出しの記録、結果のJSONの全文、写しの照合の結果
• 担当者が直した日、館に確かめた結果、正本を直した記録
• 各サイトの利用条件を確かめた日

取得した文字の全文を残すのは、予約客から「サイトにこう書いてあった」と言われたときに、その日の掲載を確かめるためです。 Tools Agent の Return Intermediate Steps を有効にすると、どの道具を引いて区分を決めたかも残ります。