運送会社で、道路の通行止め・規制と気象の警報をエージェントが毎朝見回り、当日の配送ルートと照らして、影響する便と迂回の検討が要る配送先を配車担当へ知らせる

処理の起点を決める

毎朝4時15分に、Schedule Trigger で動かします。 早番の担当者が4時半に出社したときに、影響の一覧ができている時刻にします。工数の試算は稼働日の朝ごとの件数で数えています。

Schedule Trigger は、ワークフローのタイムゾーンが設定されていればそれを、無ければ n8n のインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローのタイムゾーンを Asia/Tokyo にしないと、日本時間の夕方に動きます。 時刻は cron の式でも指定できます。保存して公開（有効化）しないと動かないとされているので、作った日に公開の状態を確かめます。

前日の夕方の取り込みは、別のワークフローにします。 配車システムの書き出しが遅れた日に、朝の見回りまで止まらないようにするためです。朝の時点で当日の配車表が無ければ、照合を止めて担当者に知らせます。

入力データを集める

質を決めるのは、2行目のルートの一覧です。 規制は「○○町△△地先」のように市町村と地名で書かれることが多いので、区間の起点・終点を、市町村と目印（IC、峠、トンネル、交差点）で持たせます。 道路名だけの一覧では、同じ国道でも規制の区間を通らない便まで候補に挙がります。

見回り先の一覧の「自動で取ってよいか」の列は、必ず埋めます。 道路情報のページの中には、利用条件で機械による取得を認めていないものがあります。認められていないページは、自動の見回りから外し、担当者が開くページとして一覧に残します。

過去の記録は、「この区間が止まったときは、この県道に回して40分増えた」を、迂回の検討の材料として添えるために持ちます。

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

気象庁のフィードは、エントリの発表者（気象台）で先に絞ります。 当日のルートが通る県の気象台のものだけを残し、電文の本体はその分だけ取ります。 気象庁は、公開しているURLに1日10GB以上のダウンロードを伴うアクセスがあるとアクセス元を遮断するとしており、一度取った電文を取り直さない作りにすることを求めています。 取った電文のIDを記録し、2回目以降は取りません。

電文は XML ノードで JSON にし、取るのは、警報の種類、対象の地域（市町村）、発表時刻と、警報が「発表」「継続」「解除」のどれかです。

道路の規制のページは、見回り先の一覧の URL だけを取ります。 HTTP Request ノードには応答の状態コードを含めて受け取るオプションがあり、取れなかったページを「規制なし」と取り違えないよう、状態コードと取得時刻を残します。

AIへ渡す前に整形する

1. 当日の配車表を確かめる … 前日の取り込みが無ければ、照合を止めて担当者に知らせます。古い配車表で照合すると、今日だけの臨時便が漏れます
2. 警報を地域で絞る … ルートの一覧にある市町村に掛かる警報だけを残します。「解除」の電文は、同じ地域の発表と組にして消します
3. ページの共通部分を外す … メニュー、フッター、お知らせの一覧を外し、見る見出しの下の本文だけを残します
4. 前回との差を出す … 前日の朝と同じ規制は「継続」として印を付けます。エージェントに渡すのは、新しい規制と、期間・区間が変わった規制です
5. 道路名の書き方をそろえる … 「R18」「国道18号」「一般国道18号」をそろえます。ルートの一覧の側も同じ規則でそろえます

4番目は、何か月も続く工事規制を毎朝読み直させないためです。 読ませると、本当に新しい通行止めが一覧の下に埋もれます。 継続のものは一覧の末尾に件数で並べます。

AIに処理させる

させるのは、規制の情報1件ごとに、道路・区間・規制の種類・期間を取り出し、ルートの一覧と当日の配車表を引いて、影響する便の候補を挙げることです。

取り出しの段階では、ページに書かれた文言をそのまま写させます。 区間の起点・終点、規制の種類、期間の書き方は道路管理者ごとに違います。言い換えると、元のページと見比べられなくなります。

3行目がいちばん起きやすい失敗です。 「○○峠付近で通行止め」とだけ書かれた規制を渡すと、生成AIは峠の前後の区間を知識から補い、もっともらしい起点と終点を書きます。 合っていることもありますが、外れると、通らない便を止めるか、通る便を見落とします。区間が書かれていなければ、峠の名前でルートの一覧を引くまでにとどめます。

指示内容を固定する

AI Agent ノードの System Message に、次のように書きます。

あなたは運送会社の運行管理課で、道路の通行止め・通行規制の情報を、
当日の配車表と照らす担当です。入力は、新しく見つかった規制の情報1件
（道路管理者のページから取り出した本文）と、当日のルートが通る地域に
出ている気象の警報の一覧です。

【やること】
1. 規制の情報から、道路名、区間の起点・終点、市町村、規制の種類、
   開始・終了の日時を、書かれた文言のまま取り出す。
2. 区間や迂回路の案内が別のページにあると書かれていれば、
   そのリンクのページを取って読む。
3. ルートの一覧を、道路名と市町村、峠・IC・トンネルの名前で引き、
   規制の区間を通るルートを探す。
4. 見つかったルートを使う当日の便を、配車表から引く。
5. 同じ区間の過去の規制と迂回の記録を引き、前回の迂回を添える。
6. 規制が事前通行規制の区間のもので、同じ地域に大雨・大雪の警報が
   出ている場合は、まだ通行止めでなくても日中に止まるおそれとして
   別に挙げる。

【厳守事項】
- 道路名、区間、期間は、ページに書かれた文言をそのまま写してください。
- ページに区間の起点・終点が書かれていないとき、区間を補わないでください。
  section_in_source を false にし、峠などの名前だけで引いてください。
- 解除の見込みが書かれていないときは「記載なし」としてください。
- 迂回のルートを提案しないでください。過去の記録にある迂回を、
  そのまま「前回の迂回」として添えるだけにしてください。
- 運行を取りやめるべきか、遅らせるべきかを書かないでください。
  match_basis に、どの道具で何が一致したかだけを書いてください。
- 規制が当日の配送の時間帯と重ならない場合も、候補から外さず、
  time_overlap を false にして返してください。
- 取得したページに規制の情報が無いと判断したときは、relevant を false
  にして、取り出しをしないでください。

【出力】指定のJSONの形で返してください。

「区間を補わない」と「section_in_source」を組にしているのが、この指示の要です。 補わないよう指示するだけだと、ページにあった区間と、補った区間の区別が出力から消えます。 ページにあったかどうかを項目として持たせれば、後段の規則で、区間の書かれていない規制は必ず人が地図で確かめる、と決められます。

「迂回を提案しない」のは、生成AIが道路の知識から出す迂回路が、トラックの通れない道を含むことがあるからです。 前回の記録を添えるところまでにします。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "source_url": "",
  "fetched_at": "",
  "relevant": true,
  "road": "",
  "section_text": "",
  "section_in_source": true,
  "municipalities": [""],
  "restriction_type": "closure | alternating | chain | pre_closure_area | other",
  "start": "", "end": "",
  "affected_runs": [
    { "run_no": "", "departure": "", "destination": "", "route_id": "",
      "match_basis": "road_and_section | road_and_landmark | municipality_only",
      "time_overlap": true,
      "previous_detour": "" }
  ],
  "daytime_risk": { "is_pre_closure_area": false, "warnings": [""] },
  "unverified": [""]
}

Structured Output Parser は、JSON の例から形を作るか、JSON Schema を直接書けます。例から作ると、すべての項目が必須として扱われるとされているので、空のときも項目を返させる形になります。$ref の参照は使えないので、便の形は入れ子のまま書きます。

1つ目の理由は、match_basis で確からしさを分けられることです。 道路名と区間、道路名と峠・ICの名前、市町村だけ、の3つを通知で分けて出します。

2つ目は、section_in_source で補った区間を締め出せることです。 false の規制は、affected_runs があっても無くても、配車担当が地図で区間を確かめます。

3つ目は、daytime_risk で第3章の（d）を解けることです。 事前通行規制の区間で、同じ地域に警報が出ているものは、今は通れても配送先へ遅れの可能性を先に伝える材料になります。

4行目も消さずに残します。 「影響なし」も、見回りをした記録だからです。

システムへ連携する

影響の一覧への書き込みは、ワークフローの側で行います。 エージェントの道具には Insert を含めず、ルートと配車表を引く Select と Execute Query だけを渡します。公式の説明では、クエリパラメーターのデータは n8n が無害化し、SQL インジェクションを防ぐとされています。ページの本文の文字を、そのまま問い合わせに埋め込まないでください。

エージェントに取らせるページは、見回り先のページの中のリンクだけにします。 AI Agent ノードの Return Intermediate Steps を有効にすると、エージェントがたどった途中の手順が出力に含まれます。後段で、取ったURLが見回り先の一覧のドメインに入っているかを確かめ、外れていれば結果を使わずに人へ回します。 HTTP Request ノードを道具として使うときは、応答から要る部分だけを選んでトークンを減らす設定もあります。

人が確認する

1. 出発の早い便から見る … 通行止めで時間帯が重なる便は、出発の前に迂回か時間の変更を決めます
2. road_and_section の一致を確かめる … 規制のページと便のルートを並べ、本当にその区間を通るかを見ます
3. section_in_source が false の規制を地図で確かめる … 峠の名前だけの規制は、どこからどこまでかを道路管理者のページの地図で見ます
4. daytime_risk の便を決める … 出発を早めるか、配送先に遅れの可能性を伝えるかを決めます。ここが配車担当の仕事の中心です
5. 迂回を決めて記録する … 選んだ迂回、増えた時間を影響の一覧に残します。次に同じ区間が止まったとき、エージェントが前回の迂回として引きます
6. ドライバーと配送先へ連絡する … 連絡は人が行います

3番目を省かないでください。 峠の名前だけの規制は広めに候補を挙げる作りで、候補はその便が止まることを意味しません。

目標は、1日をならして25分です。 影響の一覧の確認と区間の確かめに15分、迂回と連絡の判断に10分という見込みです。

例外に対処する

上から2行目は、悪天候の日ほど起きます。 取れなかったページを黙って飛ばすと、いちばん規制が出ている日に「影響なし」と出ます。

記録を残す

• 実行ごとの、取ったページと気象庁の電文のID、取得の成否と状態コード
• 新しく拾った規制と、継続中の規制の一覧
• エージェントのJSON出力と、呼んだ道具の順番
• 配車担当の判断 … 便ごとの迂回・時間の変更・取りやめと、その理由
• 規制の発表時刻、見回りで拾った時刻、便の出発時刻
• 迂回で増えた時間と、配送先の受け入れに間に合ったか

5つ目の行が、この構成の物差しです。 規制が出てから何分で拾い、出発の何分前に判断できたかを並べると、見回りの時刻が早すぎるのか、判断に時間がかかっているのかが分かれて見えます。