協力運送会社と船会社の燃料サーチャージの改定のお知らせをエージェントが毎週各社のWebで見回り、自社の運賃表への反映候補と影響額の一覧を出す

処理の起点を決める

毎週月曜の朝7時に、Schedule Trigger で動かします。 改定のお知らせは月末から月初に出ることが多く、週1回でも適用の開始より前に気づけるという想定です。運送会社の多くは月ごとに額を決めるので、毎日見ても結果は変わりません。

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

月末の最終営業日には、もう1回動かします。 翌月1日から適用される改定が、月末の数日前に出ることがあるためです。月曜だけだと、月末の金曜に出たお知らせを、適用の開始の後に拾います。

入力データを集める

質を決めるのは、「自社が使う区分」です。 船会社の表には自社が使わない航路が何十行もあります。区分を渡さないと、エージェントは表のどの行を読めばよいかを決められません。

見る順の覚え書きは、エージェントの道しるべです。 「お知らせの一覧の『運賃』のタグの記事。本文の下のPDFの3ページ目」のように、担当者が知っている探し方を一覧に書いておきます。 覚え書きどおりに見つからないときに、エージェントが自分で探します。

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

前回との比較は、ページ全体ではなく記事の一覧で行います。 ページには日付や広告の表示など毎回変わる部分があり、全体で比べると毎週「変わった」になります。 記事の見出しと日付の並びを取り出し、その並びが前回と同じかを見ます。

PDFは Extract From File で文字にします。 PDFから文字を取り出す操作があり、ページをつなげるか、何ページまで読むか、パスワードを指定できます。表が画像で貼られたPDFは文字が取れないので、例外処理で扱います。

エージェントが道具に渡すURLは、$fromAI() で決めさせます。 n8n では、道具のパラメーターをAIに動的に決めさせる $fromAI() の関数が使えます。ただし、取りに行けるのは仕入先の一覧に載ったドメインだけに絞ります。 道具の前に、URLのドメインを一覧と照らす段を置きます。

AIへ渡す前に整形する

1. ドメインの確認 … 取りに行くURLが、仕入先の一覧に載ったドメインかを確かめます
2. 取得の間隔 … 同じ仕入先へのリクエストは、数秒の間を置いて1件ずつにします
3. 記事の一覧の取り出し … ページから見出しと日付の並びを取り出し、前回と比べます
4. 新しい記事の絞り込み … 前回より後の日付の記事だけを、エージェントに渡します
5. PDFの文字化 … ページ数の多いものは、読むページの上限を決めて文字にします
6. 区分の添付 … その仕入先について、自社が使う区分と現在の額を、エージェントへの指示に添えます

1番目と2番目は、相手のWebへの配慮です。 見回りは週1回、1社あたり数件のリクエストに収めます。仕入先のWebの利用規約に機械による取得を禁じる定めがあれば、その仕入先は見回りから外し、改定の連絡をもらう形に切り替えます。

AIに処理させる

エージェントにさせるのは、新しい記事のなかから燃料サーチャージの改定を見つけ、自社の区分の新しい額を取り出すことです。

1. 新しい記事が燃料サーチャージ（運送会社の燃料サーチャージ、船会社のBAFや低硫黄燃料の割増など）の改定に当たるかを見分ける
2. 当たれば、本文とPDFをたどって改定の表を探す
3. 表から、渡された区分の行を探し、新しい額・単位・適用の開始日を読む
4. 改定の根拠として書かれている燃料価格や価格帯があれば、そのまま写す
5. 読めなかった区分、見つからなかった表は、その旨を書く

国土交通省が示す燃料サーチャージの考え方では、燃料価格を一定の価格帯に分け、価格帯ごとに算出上の上昇額を決めておく形が示されています。 燃料価格は短期間で変動するため、その都度改定するのではなく価格帯を設定し、改定や廃止の条件を設定時に荷主に明示しておく必要があるとされています。運送会社のお知らせも多くはこの形で、「どの価格帯に入ったか」と「その価格帯の額」の2つを取り出せば足ります。

2行目がいちばん起きやすい失敗です。 自社の区分の行が見つからないとき、隣の行の額や前回の額で埋めます。埋めた額は、正しそうに見えるので確認をすり抜けます。

指示内容を固定する

AI Agent の System Message には、次の文を入れます。

あなたは物流会社の運賃グループで、仕入先のWebから燃料サーチャージの
改定を探す補助をします。道具を使ってページとPDFを読み、改定の内容を
決まった形で返してください。

【探すもの】
- 燃料サーチャージ、燃料割増、BAF、低硫黄燃料の割増など、
  燃料価格の変動を運賃に別建てで上乗せする料金の改定・新設・廃止
- 渡された「自社が使う区分」の行の、新しい額・単位・適用の開始日

【探し方】
- まず「見る順の覚え書き」に従ってください。
  見つからないときは、同じドメインの中で記事やPDFのリンクをたどってください。
- 道具で取れるのは、渡されたドメインのページだけです。

【厳守事項】
- 額は表に書かれたとおりに写してください。単位（円/km、円/L、USD/TEU など）も
  そのまま写してください。換算や計算をしないでください。
- 自社の区分の行が見つからないときは、found を false にしてください。
  隣の行、前回の額、似た区分の額で埋めないでください。
- 適用の開始日が書かれていなければ空にしてください。告知日で埋めないでください。
- 改定の根拠として書かれた燃料価格や価格帯は、そのまま basis に写してください。
- 燃料サーチャージと関係の無い記事なら、is_fuel_surcharge を false にして終えてください。
- 根拠にしたページのURLと、表のある箇所（ページ番号など）を必ず書いてください。

【仕入先】{carrier_name}
【見る順の覚え書き】{navigation_note}
【自社が使う区分と現在の額】{lanes}
【新しい記事の一覧】{new_articles}

「換算や計算をしない」と「隣の行で埋めない」を、どちらも書いています。 船会社の表はドル建てで、指示が無いと円に直して返します。直した値は、原文と並べたときに照らせなくなります。

Max Iterations は既定の10のままにします。 1社につき、記事を読む・PDFを取る・区分を引くで数回に収まるはずで、10回を使い切る仕入先は、見る順の覚え書きが古くなっている合図です。 「Return Intermediate Steps」を有効にし、どの道具をどの順で使ったかを残します。

出力形式を固定する

Structured Output Parser で、仕入先ごとに次の形のJSONを受け取ります。

{
  "carrier": "",
  "is_fuel_surcharge": true,
  "change_type": "increase | decrease | new | abolish | unknown",
  "announced_on": "",
  "lanes": [
    { "lane": "", "found": true, "new_amount": "", "unit": "",
      "effective_from": "", "source_url": "", "source_location": "" }
  ],
  "basis": "",
  "notes": ""
}

運送会社のお知らせから取り出した例です（額と社名は架空のものです）。

{
  "carrier": "協力運送A社",
  "is_fuel_surcharge": true,
  "change_type": "increase",
  "announced_on": "2026-09-25",
  "lanes": [
    { "lane": "大型車・距離制", "found": true, "new_amount": "12.5",
      "unit": "円/L（算出上の燃料価格上昇額）", "effective_from": "2026-11-01",
      "source_url": "https://example.com/news/2026/0925.pdf", "source_location": "2ページ目の表" },
    { "lane": "4t車・時間制", "found": false, "new_amount": "", "unit": "",
      "effective_from": "", "source_url": "https://example.com/news/2026/0925.pdf", "source_location": "" }
  ],
  "basis": "軽油価格（ローリー）110円超～115円の価格帯",
  "notes": "時間制の表はこのPDFに見当たらない"
}

2つ目の区分は、見つからなかったことがそのまま返っています。 1つ目と同じ額で埋めずに found を false にし、notes に理由を書いています。この行が一覧の先頭に来ます。

ワークフローは、このJSONに次の計算結果を足して一覧にします。

1つ目の理由は、AIが返す額を文字列のまま持てることです。 new_amount と unit を分け、単位が現在の運賃表と同じときだけワークフローが差を計算します。 円とドル、円/kmと円/Lが混ざっても、黙って引き算をしません。

2つ目は、found と source_location で確認が速くなることです。 担当者は原文の該当のページを開き、書かれた行を見るだけで済みます。 found が false の区分は、一覧の先頭に出します。

3つ目は、change_type で廃止を拾えることです。 燃料価格が下がると、燃料サーチャージは減額や廃止になります。減額も荷主への反映が要るので、増額と同じ一覧に載せます。

国土交通省の資料が示す算出式は、「燃料サーチャージ額＝走行距離（km）÷燃費（km/L）×算出上の燃料価格上昇額（円/L）」です。 仕入先が上昇額（円/L）で示している場合は、ワークフローの計算で、自社の区分の距離と燃費を使ってこの式で1便あたりの額に直します。 燃費は仕入の運賃表に車格ごとに持たせておきます。

システムへ連携する

運賃表には書き込みません。 仕入の運賃表を直すのは担当者で、販売の運賃表は荷主との合意の後に直します。 一覧は、直すための材料です。

仕入先のWebには、取りに行くだけです。 問い合わせのフォームに送る、ログインして見る、といった動きはさせません。

人が確認する

担当者は、改定の一覧の1行ずつについて、原文と取り出した額を照らします。

1. found が false の区分を先に見る … 原文を開き、自社の区分の行が本当に無いのか、表の書き方が変わったのかを確かめます
2. 額と単位を原文と照らす … source_location のページを開き、行と額を目で見ます。ここは省きません
3. 仕入の運賃表を直す … 適用の開始日を付けて直します
4. 営業と申し入れを決める … 影響額と申し入れの期限の目安を見て、荷主ごとに決めます

2番目に使う時間が、第10章の1件4分の中心です。 改定の無かった仕入先は一覧に「変わらず」と載るだけで、見るのは改定のあった数社の数行です。

エージェントのたどった道順も、ときどき見ます。 Return Intermediate Steps で残した道具の順を見て、覚え書きと違う道順で見つけていたら、覚え書きを新しい道順に書き直します。 次の週から道具の呼び出しが減ります。

荷主への申し入れは、この構成の外の判断です。 契約の条項で機械的に反映できる荷主もあれば、交渉が要る荷主もあります。一覧はその判断の材料で、決めるのは営業と運賃グループです。

例外に対処する

8行目の「前回の要約値は更新しない」が大事です。 更新してしまうと、次の週には「変わっていない」と判定され、取り出せなかった改定が二度と拾われません。 取り出しが終わって初めて、前回の要約値を新しくします。

記録を残す

• 仕入先ごとの取得の日時、ステータスコード、記事の一覧の要約値
• エージェントが使った道具の順（Return Intermediate Steps の内容）
• 取り出したJSONの全文と、根拠のURL・箇所
• 差と影響額、反映候補の計算に使った運賃表と実績の値
• 担当者が額を直した記録 … どの区分を、どの額からどの額へ
• 仕入の運賃表を直した日時と、荷主に申し入れたかどうか

4つ目で、計算に使った値を残すのは、運賃表が後から変わるためです。 影響額の根拠を後で確かめるとき、当時の現在の額と数量が残っていないと計算をたどれません。

最後の行で、改定を知ってから申し入れまでの日数を数えます。 この日数が、この構成の効き目を測る物差しです。