ホテルの周辺で開かれるコンサート・学会・スポーツの大会の予定をエージェントが毎週見回り、宿泊の需要が高まりそうな日を料金と販売の担当へ知らせる

処理の起点を決める

毎週月曜の朝7時の定時実行にします。 会場や主催者の発表は週の後半に出ることが多く、週明けにまとめて拾えば、その週の料金の会議に間に合います。 Schedule Trigger は秒・分・時・日・週・月と Custom（Cron）を指定でき、ここでは「週」で月曜を選びます。

時刻の基準に注意してください。 Schedule Trigger はタイムゾーンの設定に従い、自前で立てたインスタンスの既定は America/New York です。 ワークフローの設定で Asia/Tokyo を指定しないと、日本時間の夜に動きます。

Schedule Trigger を起点にしたワークフローは、保存して公開しないと定時に動きません。 道具として呼ぶワークフローも同じです。親だけを公開して道具を公開し忘れるのが、最初の週にいちばん起きる失敗です。週1回では遅い見回り先だけは、台帳の「頻度」の列で毎日に指定します。

入力データを集める

質を決めるのは、会場の台帳と過去の催事と実績です。 会場の台帳が無ければ、「〇〇ホール」が何人入る会場かを毎回エージェントが探しに行き、根拠の無い規模を書く余地が生まれます。 過去の実績が無ければ、「前回はどう効いたか」が言えず、知らせる段階が規模だけで決まります。

会場の表記ゆれは必ず台帳に入れてください。 命名権で名前が変わった会場は、旧名と略称を同じ行に並べないと過去の実績が引けません。

自動での取得を禁じている先、ログインが要る先は登録せず、人が見る一覧に回します。

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

見回り先の取得は、間隔を空けて1か所ずつ行います。 HTTP Request ノードの Batching で、1回にまとめる件数（Items per Batch）と、まとまりの間に待つ時間（Batch Interval、ミリ秒）を決められます。同じサイトの複数のページを続けて取りに行かないよう、1件ずつ数秒の間隔を空けます。Timeout で、応答の始まりを待つ時間も決めておきます。

robots.txt は見回りの朝に読み直します。 RFC 9309 は、キャッシュした robots.txt を、取得できない場合を除いて24時間を超えて使うべきではないとしています。利用条件の確認は、人が台帳の登録時に行います。

エージェントが自分でURLを選んで取りに行くことは、許可した先に限ります。 詳細ページを取る道具の側で、台帳に登録したドメインかどうかを先に確かめ、それ以外は取得せずに返します。 検索エンジンを道具としてつなぐことはしません。

AIへ渡す前に整形する

1. 見る範囲の切り出し … 台帳のセレクターで、予定表の部分だけを取り出します。メニュー、広告、関連記事は落とします
2. タグの除去 … HTMLのタグと属性を取り除き、本文の文字だけにします
3. 前週との差 … 切り出した本文を前の週の本文と比べ、差の無い見回り先はエージェントに渡しません
4. 日付の正規化の準備 … 「10/12(日)」「2027.1.18」「令和9年1月」のような表記を、年を補わずにそのまま残します。年の補い方はエージェントの判断に任せず、規則で行います
5. 取得の失敗の記録 … 応答が無い、ステータスが2xxでない、本文が空、の3つを分けて記録します
6. 構造の変化の検知 … 先週は催事の行が20あったのに今週は0、のように急に減った見回り先は、エージェントに渡さず人に回します

3番目と6番目が、量と誤りの両方を抑えます。 3番目で、エージェントが読むのは40か所のうち差のあった十数か所になります。6番目を入れないと、サイトの作り直しで予定表が取れなくなった週に「催事はすべて中止」という知らせが出ます。

AIに処理させる

させるのは、差のあった見回り先の本文から催事を拾い、台帳の形にそろえ、道具で判断の材料を付けることまでです。

右端の列が、この構成でいちばん大事な決まりです。 とくに規模は、書かれていない人数を会場の収容人数から推定して書くと、満席の公演と空席の多い催しが同じ扱いになります。 会場の収容人数は会場の台帳の値として別の欄に持ち、催事の規模の欄には本文に書かれたことだけを入れます。

最後の行が、いちばん起きやすい誤りです。 予定表から行が消える理由は、中止のほかに、終わった催事を消した、月のページが切り替わった、もあります。「中止」「延期」と本文に書かれているときだけ cancelled にし、行が消えただけなら disappeared として人に回します。

指示内容を固定する

あなたはホテルの経営企画部で、周辺の催事の予定を整理する担当です。
渡された本文と、道具で引いた情報だけを使ってください。推測で埋めないでください。

【あなたの仕事】
1. 本文から催事を拾い、1件ずつ次の項目にそろえる
   name / category / venue_text / date_text / scale_text / evidence
2. venue_text を「会場の台帳」の道具で引き、venue_id を付ける
3. 同じ会場・同じ category の過去の催事を「過去の催事と実績」の道具で引く
4. 開催日が決まっている催事は「予約の入り方」の道具で、施設ごとの予約の数を引く
5. 「催事の台帳」の道具で、前の週までに拾った同じ催事があるかを確かめる

【category の選び方】
concert（公演） / convention（学会・大会・試験） / sports（スポーツ）
exhibition（展示会・見本市） / local（地域の催し） / other

【厳守事項】
- date_text には本文の日付の文字列をそのまま写してください。
  年が書かれていなければ、年を補わないでください。
- scale_text には、本文に書かれた公演数・日数・参加の見込み・席数だけを写してください。
  書かれていなければ空にしてください。会場の収容人数で埋めないでください。
- 会場が台帳に見つからなければ venue_id を "venue_unknown" にしてください。
  似た名前の会場に寄せないでください。
- evidence には、その催事を拾った本文の文をそのまま写してください。
  写せない催事は拾わないでください。
- 「中止」「延期」「変更」と本文に書かれているときだけ、status_hint に
  cancelled / postponed / changed を入れてください。書かれていなければ空にしてください。
- 料金の案、販売を止める案、需要が高いかどうかの結論は書かないでください。
- 詳細ページを取りに行くのは、本文に詳細ページへのリンクがあり、
  日程か規模が本文だけでは分からないときに限ってください。
- 道具が失敗したら、その項目を空にし、tool_errors に道具の名前を書いてください。

【見回り先】{source_name}（種類：{source_type}、対象の施設：{hotels}）
【取得日】{fetched_at}
【前週との差の本文】{diff_text}

「会場の収容人数で埋めない」を明記しないと、規模の欄が埋まります。 エージェントは道具で会場の台帳を引けるので、収容人数という数字が目の前にあれば、それを規模として書きます。 禁じるのは、台帳の値を催事の値として扱うことそのものです。

「似た名前の会場に寄せない」も同じ理由です。 市内に「〇〇ホール」が3つあれば、いちばん大きいものに寄せがちです。会場を取り違えると、施設からの距離も過去の実績も別物になります。 詳細ページの条件を書かないと、全件の詳細を取りに行き、Max Iterations の上限に先に届きます。

出力形式を固定する

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

{
  "source_id": "SRC-012",
  "fetched_at": "2026-10-05T07:03:00+09:00",
  "events": [
    {
      "name": "",
      "category": "concert | convention | sports | exhibition | local | other",
      "venue_text": "",
      "venue_id": "",
      "date_text": "",
      "scale_text": "",
      "status_hint": "cancelled | postponed | changed | ",
      "evidence": "",
      "history": [
        { "event_date": "", "hotel": "", "occupancy": 0, "adr": 0 }
      ],
      "pickup": [
        { "hotel": "", "date": "", "booked_rooms": 0, "vs_same_weekday": 0 }
      ]
    }
  ],
  "tool_errors": []
}

1つ目の理由は、AIが写したものとワークフローが決めたものを分けられることです。 日付の確定、new／changed／cancelled の付与、知らせる段階は、受け取った後に Code ノードで決めます。

2つ目の理由は、出力パーサーの決まりに合わせて欄を必ず出させられることです。 n8n の Structured Output Parser は、JSONの例から作るとすべての項目を必須として扱います。 空でも欄は出るので、後段の処理が欄の有無で分岐せずに済みます。JSON Schema で書く場合は、$ref による参照が使えないので、history と pickup の形は展開して書きます。

3つ目は、evidence で、どの文から拾ったかを開く前に読めることです。

システムへ連携する

PMSへは書き込みません。 予約の数を読むのも、夜間に書き出した表からです。PMSに直接つなぐと、エージェントの道具から予約の個人の情報まで届く経路ができます。書き出しの段階で、日付と室数だけの表にしておきます。 チャットへの投稿は施設ごとに1つにまとめ、段階Aだけはまとめを待たずに送ります。

人が確認する

人が見るのは、段階AとBの一覧と、人へ回したものだけです。 記録のみの催事は、月に一度、件数と見回り先を流し見ます。

1. 人へ回したものを先に見る … venue_unknown は会場の台帳に足すか、対象外にするかを決めます。disappeared は見回り先を開いて、中止か、終わっただけかを確かめます
2. 段階Aの根拠を確かめる … evidence と見回り先のページで、日程と会場を目で確かめます。料金を動かす前に、必ず元のページを開きます
3. 料金と販売の判断をする … レベニューの担当が料金の見直しの候補に入れるか、営業の担当が主催者へ提案するかを決めます
4. 判断の結果を台帳に付ける … 見直した／見送った／誤り（日付・会場・催事の取り違え）のどれかを付けます

2番目を省かないでください。 日付を写し間違えると、催事の無い日に料金を上げることになります。

人へ回す件数が増えた週は、見回り先の構造が変わったか、会場の台帳が足りていません。

例外に対処する

上から2行目がいちばん多く起きます。 会場や自治体のサイトは年に何度か作り直され、セレクターが合わなくなります。

記録を残す

• 見回り先ごとの取得の日時、ステータス、切り出した本文と行の数
• 前週との差の本文と、エージェントに渡したかどうか
• エージェントの出力（JSONの全文）と、Return Intermediate Steps で残した道具の呼び出しの記録
• 催事の台帳（催事ごとの内容の履歴、new／changed／cancelled／disappeared、知らせた段階）
• 人の判断（見直した／見送った／誤り）と、誤りの種類
• 見回り先ごとの robots.txt と利用条件の確認日

3つ目は、会場の取り違えが本文の読み違いか台帳の引き違いかを分けるために残します。 5つ目は、段階の規則を直す材料です。「見送った」ばかりの種類は、記録のみに下げます。