輸入の本船の動静（入港予定・遅延・抜港）をエージェントが毎日見回り、通関・配送・納品の手配に影響する案件を拾って、顧客と社内への連絡の案を作る

処理の起点を決める

2つのトリガーを使います。 1つは毎朝7時30分の Schedule Trigger で、担当する全部の本船の予定を船会社のAPIから取り直します。もう1つは Gmail Trigger で、フォワーダーから届く予定変更・抜港・到着案内のメールを受けたときに、その本船だけを見ます。

朝の見回りを残すのは、メールが来ない変化があるからです。 フォワーダーによって、予定変更を毎回知らせる会社と、大きな変化だけを知らせる会社があります。メールだけを起点にすると、知らせの少ないフォワーダーの案件だけが見回りから落ちます。

Schedule Trigger は、ワークフローのタイムゾーンか n8n のインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。Asia/Tokyo を設定します。また、保存して公開しないと動かないとされています。

Gmail Trigger は、新しいメッセージをポーリングで見る作りで、ラベル、検索の条件、差出人で絞れます。フォワーダーのアドレスからのメールに「本船動静」のラベルを付けるフィルタを Gmail 側で作り、そのラベルで絞ります。 1回のポーリングで取るメールの数には上限（既定10、最大50）があるとされ、朝に届くメールが多いなら上限を上げます。

入力データを集める

質を決めるのは、いちばん下から2行目の必要日数の表です。 入港から納品まで何日かかるかが無ければ、入港予定が2日遅れたときに納期に響くかを計算できません。揚げ港と通関の種類（通常、検査が多い品目など）ごとに、過去の実績から目安を作ります。 表が無いうちは、納期への影響を判定しません。

台帳の入港予定は、「手配に使った値」として持ちます。 船会社の最新の予定ではなく、通関業者やドレージに伝えた時点の予定です。比べる相手を最新の予定にすると、手配がずれていることに気づけません。

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

船会社のAPIへの問い合わせは、台帳にある本船・航海だけにします。 HTTP Request ノードの Batching のオプションで、まとめて送る件数と間隔を決めます。応答のステータスを含め、Never Error にしておけば、1つの船会社のAPIが止まっても見回り全体は止まりません。 止まった船会社の分は「本日の予定取得なし」として通知の先頭に出します。

メールの本文からの取り出しは、エージェントの前段で別に行います。 本船名、航海番号、港、新しい予定、抜港かどうかを取り出し、取り出せなかったメールは、そのまま担当者に回します。 本文の書き方はフォワーダーごとに違うので、取り出しの成否を毎回記録します。

AIへ渡す前に整形する

1. 本船名と航海番号の表記をそろえる … 「M/V」「MV」の有無、大文字小文字、航海番号の末尾の記号。そろえないと、同じ本船が別の本船として扱われます
2. 日時を揚げ港の現地時刻にそろえる … 予定がUTCで届くものと現地時刻で届くものがあります
3. 予定の種類を分ける … 計画値・見込み値・実績値。見込み値を実績として扱わない
4. 本船・航海ごとに、台帳の値と比べて変化を判定する … 下の表のとおり
5. 載っている案件を拾い、手配の日付と比べる … 新しい入港予定に必要日数を足し、手配の日と納期と比べます

early を拾うのを忘れないでください。 遅延ばかりに目が行きますが、早着すると通関の書類が間に合わず、コンテナが港に置かれたままになる日数が増えることがあります。

AIに処理させる

させるのは、本船・航海1つごとに、載っている案件の手配の状況を調べ、影響を整理し、連絡の案を作ることです。 日付の計算と影響の種類は規則で付け終えています。

顧客ごとにまとめるのが、エージェントに任せる理由の一つです。 同じ本船に同じ顧客の案件が3件載っていれば、連絡は1通にまとめます。担当者が別々だと、同じ顧客に3通届く、ということが起きていました。

3行目がいちばん起きやすい失敗です。 抜港のメールに次の寄港地が書かれていると、エージェントは「次の港で揚げて陸送」と案を書きます。揚げる港を決めるのは船会社で、書かれた寄港地で揚がるとは限りません。 推測を禁じ、確認の依頼文を作らせます。

指示内容を固定する

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

あなたは輸入商社の輸入業務課で、本船の動静の変化が、通関・配送・納品の
手配にどう響くかを整理する担当です。入力は、規則で判定した本船・航海1つと、
そこに載っている案件と、案件ごとの影響の種類です。

【やること】
1. 案件ごとに手配の予約の状況を引き、予約済み・仮・未手配を確かめる。
2. 過去の連絡の記録を引き、同じ変化について連絡済みかを確かめる。
3. port_omission または port_change のときは、フォワーダーのメールを探し、
   代わりの港・次の本船について何が書かれているかを確かめる。
4. 関係先（通関業者・陸送の会社・倉庫）ごとに、連絡の案を作る。
5. 顧客ごとに案件をまとめ、営業担当が直して送れる連絡の案を作る。

【厳守事項】
- 日付は入力に書かれた値をそのまま使ってください。日数を足したり
  引いたりしないでください。
- 顧客への連絡の案に、新しい納期を書かないでください。
  「現時点の入港予定は○月○日です。納品日は改めてご連絡します」の形にしてください。
- 抜港・揚げ港の変更のとき、代わりの港や本船を推測しないでください。
  メールに書かれていなければ「船会社・フォワーダーに確認中」と書き、
  フォワーダーへの確認の依頼文を作ってください。
- 航空への切り替えなど、代わりの輸送手段を提案しないでください。
- 連絡済みで、その後に予定が変わっていない案件には、新しい連絡の案を
  作らないでください。
- 道具で確かめられなかったことは unverified に書いてください。
- 「見込み」の予定を「確定」と書かないでください。

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

「新しい納期を書かない」を明記しないと、入港予定に必要日数を足した日を、納期として書きます。 計算としては合っていても、通関で検査が入れば数日ずれます。 一度顧客に書いた日付は、約束として受け取られます。

「見込みを確定と書かない」も同じ理由です。 船会社の予定には、計画・見込み・実績の区別があり、見込みの日付で「入港しました」と書くと、ドレージを手配してしまう相手が出ます。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。 スキーマは JSON Schema で定義します。JSONの例から作ると、すべての項目が必須として扱われるとされているので、unverified のような空になりうる項目がある場合は、JSON Schema で必須を指定します。

{
  "vessel": "", "voyage": "", "port": "",
  "change_type": "delay | early | port_omission | port_change | unknown",
  "planned_eta_in_ledger": "", "latest_eta": "", "eta_status": "planned | estimated | actual",
  "shipments": [
    {
      "bl_no": "", "customer": "", "owner": "",
      "impacts": ["customs_reschedule", "drayage_reschedule", "warehouse_reschedule", "delivery_at_risk", "early_arrival"],
      "booking_status": { "customs": "booked | tentative | none", "drayage": "", "warehouse": "" },
      "already_notified": false
    }
  ],
  "drafts_to_partners": [ { "partner": "", "bl_nos": [""], "body": "" } ],
  "drafts_to_customers": [ { "customer": "", "bl_nos": [""], "sales_owner": "", "body": "" } ],
  "forwarder_inquiry": "",
  "unverified": [""]
}

1つ目の理由は、本船・航海を1つの単位にできることです。 変化は本船ごとに起き、影響は案件ごとに出ます。shipments に案件を並べることで、1隻の遅れが何件に響くかが一目で分かります。 第3章の（b）がここで解けます。

2つ目は、eta_status で見込みと実績を分けられることです。 通知でも、見込みの日付には「見込み」と付けて出します。

3つ目は、already_notified で連絡の重なりを止められることです。 予定が細かく何度も変わる本船では、毎朝同じ顧客に連絡の案が出ます。連絡済みで予定が変わっていなければ、案を作りません。

システムへ連携する

書き込むのは影響の一覧だけです。 台帳、通関業者、陸送の会社、倉庫、顧客へは、この構成からは何も送りません。エージェントに渡す道具も読み取りだけにし、メールを送る道具をつなぎません。

人が確認する

1. 抜港・揚げ港の変更を最初に見る … フォワーダーへの確認の依頼文を直して送ります。返事が来るまで、顧客には「確認中」とだけ伝えます
2. delivery_at_risk の案件を営業担当に回す … 顧客への連絡の案を添えます。納期をどう伝えるかは営業担当が決めます
3. 手配を動かす … ドレージの予約、倉庫の受け入れ、通関業者への連絡を、案を直して行います
4. 台帳を直す … 手配に使う入港予定を、新しい値に更新します。直した時点で、次の朝からはこの値と比べます
5. unverified を見る … 予定が取れなかった本船は、船会社のサイトかフォワーダーへの問い合わせで確かめます
6. 入港した本船は、Colins で搬出可否を確かめる … eta_status が actual になった本船について、コンテナを引き取れる状態かを見てから、ドレージに最終の連絡をします。入港したことと、コンテナを引き取れることは別です

4番目を忘れると、同じ変化が毎朝出ます。 台帳を直すまで、規則は古い値と比べ続けます。連絡を送ったら台帳を直す、を1つの手順にします。

目標は、1件をならして4分です。 影響の一覧と案の確認に2分、連絡の確認と送付に1分、台帳の更新に1分という見込みです。

例外に対処する

上から4行目を、運用の最初に決めてください。 船会社のAPIとフォワーダーのメールで日付が違うことは珍しくありません。更新のタイミングが違うだけのこともあれば、片方が古いこともあります。 どちらを手配に使うかは、担当者がフォワーダーに確かめて決めます。

記録を残す

• その日に取った船会社のAPIの応答と、受けたメールのID
• 規則で判定した変化と影響の種類
• エージェントのJSON出力と、呼んだ道具の順番
• 担当者の対応 … 手配を動かした、連絡を送った、台帳を直した、とその日時
• 変化に気づいた日と、入港予定日の差 … 何日前に気づけたか

最後の行が、この構成の物差しです。 気づくのが入港の前日だった案件が、何日前に気づけるようになったかを毎月数えます。ドレージの予約を動かせる日数が残っているかどうかが、この差で決まります。