原材料とエネルギーの市況を毎週巡回して、調達と価格改定の材料にする

処理の起点を決める

毎週決まった曜日と時刻に起動します。 ここを「値上げ依頼のメールを受け取ったら」というイベント起動にすると、本記事の目的が崩れます。依頼が来る前に持っておくための構成なので、出来事に紐づけてはいけません。

曜日は、参照する統計の公表日の翌営業日あたりに寄せます。品目群ごとに公表の周期が違うため、巡回はすべての品目群について毎週まわします。 12品目群を1本ずつ、順番に処理します。同時に走らせないのは、検索のコンテキストウィンドウが128kに限られることと、品目群をまたいで出典が混ざるのを防ぐためです。

月次の統計を毎週見に行くことになりますが、無駄ではありません。業界紙や仕入先の公表情報は随時出ますし、統計の公表日が月によってずれることもあります。 新しい数字が無い週は、次の「入力データ」で渡す前回値をそのまま返させます。

入力データを集める

この構成の質を決めるのは、いちばん上の巡回先リストです。 技術的な作り込みよりも、「この品目群は、どの統計の、どの指標を見るのか」を決めて維持する作業のほうが重く、そこが決まっていなければAIを足しても結果は安定しません。

自社の購買単価は、AIへは渡しません。 生産管理システムから取り出したあと、社内のプログラムが相場の側の結果と突き合わせます。理由は第13章に書きます。

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

公的統計を軸に、品目群ごとに参照先を先に決めて表にしておきます。 例として、日本銀行の企業物価指数があります。2020年基準で、月次で公表されます（2026年9月11日に2026年8月分のデータが掲載されていることを確認しました）。基本分類指数として、国内企業物価指数・輸出物価指数・輸入物価指数が提供されます。時系列のデータは時系列統計データ検索サイトから入手でき、公表データは月別のPDFで、ウエイト等の参考資料はXLSX形式で提供されます。

巡回先のリストは、そのまま filters.allowed_domains に渡します。 最大100個まで指定でき、ドメインは openai.com の形式で、HTTPSのプレフィックスは不要です。リストに無いドメインは見に行きません。この一手で、根拠の弱い情報が混ざるのを構造的に防げます。 プロンプトで「信頼できる情報源を使ってください」と書くより確実です。

呼び出しは Responses API で行い、user_location に国として JP を指定します。検索の範囲は search_context_size で調整し、値を読み取るだけの品目群では広げすぎないようにします。 検索のコンテキストウィンドウは128kに限られるため、1回の呼び出しで扱うのは1品目群までにします。

出典URLは、モデルの本文からではなく message.content[0].annotations から取り出します。 本文に書かれたURLは書き換わることがありますが、annotations は検索の結果として返る引用情報です。配布する1枚には、この引用をクリックできる形で載せます。 ツールの要件として、本文中の引用ははっきり見える形で、クリックできるようにしなければならないとされています。

巡回の頻度と公表の頻度がずれることを、設計に織り込みます。 月次の統計を毎週見に行っても、新しい数字は月に1回しか出ません。前回のまとめを渡し、値と対象期間が同じであれば updated を false で返させます。変わっていない品目群は「変化なし」の1行で済み、担当者が読むのは変わった品目群だけになります。

AIへ渡す前に整形する

1. 巡回先リストの読み込み … 品目群ごとに、指標名と許可ドメインの一覧を組み立てます
2. ドメイン数の確認 … allowed_domains は最大100個です。超える場合は品目群の分け方を見直します
3. 前回のまとめの取り出し … 前回の値、対象期間、公表日、出典URLをプロンプトに渡します
4. 公表予定日の突き合わせ … その週に新しい数字が出る予定が無い品目群には、その旨を渡します
5. 品目群ごとの分割 … 12品目群を1本ずつの呼び出しに分けます
6. 自社の購買単価の取り出し … 生産管理システムから読み取り専用で取り出し、AIへは渡さず社内に保持します

4番目を入れておくと、まだ公表されていない月の数字を探しに行って、別の月の数字を拾ってくる事故が減ります。

AIに処理させる

させるのは、許可した先の中から値と出どころを取り出すことと、前回との差があるかを返すことの2つだけです。 指標ごとに、値・対象期間・公表日・出典URLをそろえ、前回のまとめと比べて更新の有無を返し、公表情報から読み取れる背景を出典URL付きで書きます。

下から2つ目がいちばん大事です。 「このところ上昇傾向」とだけ書かれた記述は、読めばもっともらしく見えますが、どの月と比べたのかが分からないので使えません。 対象期間を必須の項目にし、埋まらない指標はそもそも返させません。

指示内容を固定する

あなたは食品製造業の購買部門で、原材料とエネルギーの市況を定点観測する担当です。
与えられた web search ツールを使い、許可された参照先の中だけで調べてください。

【調べること】
1. 品目群「{group}」について、指定された指標を1つずつ調べてください。
   指標名・値・対象期間（何年何月の数字か）・公表日・出典URLの5つをそろえてください。
2. 前回のまとめ {previous} と比べてください。
   値と対象期間が前回と同じであれば updated を false とし、
   value と period には前回と同じ内容をそのまま入れてください。
   新しい数字が公表されていれば updated を true としてください。
3. 公表情報から読み取れる背景があれば notes に書いてください。
   無ければ notes は空のままにしてください。

【厳守事項】
- 対象期間が特定できない数値を返さないでください。
  「直近」「足元」「このところ」としか書かれていない数値は使わないでください。
  指標ごとに period（対象年月）を必ず入れてください。
  特定できない場合はその指標を返さず、needs_human を true にして理由を書いてください。
- 出典URLが確認できない記述を notes に書かないでください。
  一般に言われていること、以前から知っていること、推測は書かないでください。
- 値は公表されている表記のまま書いてください。
  四捨五入、単位の変換、前月比や前年比の計算をしないでください。
- 今後の見通し、上がる・下がるの予想、値上げ交渉への助言を書かないでください。
- 自社の購買単価、価格改定の要否、仕入先との交渉方針を書かないでください。
  own_price と gap は空のままにしてください。社内で埋めます。
- 許可された参照先以外を見ないでください。
  許可された参照先で見つからない場合は、見つからなかったと書いてください。
  他の情報源で補わないでください。
- 記載が確認できない項目は「不明」としてください。
  空欄を推測で埋めないでください。前回の値以外から補わないでください。

【品目群と指標】{indicators}
【前回のまとめ】{previous}
【今週の公表予定】{calendar}

「対象期間が特定できない数値を返さない」を、例を挙げて書いているのは、言い方を変えて出てくるためです。 「直近」を禁じると「最新の」と書き、それも禁じると日付の無いまま数字だけを置きます。禁止するのは言葉ではなく、period が埋まらない状態そのものです。

「他の情報源で補わない」も必ず入れます。 何も言わないと、許可した先で見つからなかったときに、一般に知られている数字を書いてきます。見つからなかったことは、出力を見ただけでは分かりません。

出力形式を固定する

品目群ごとに、次のJSONで返させます。

{
  "group": "",
  "run_date": "",
  "indicators": [
    { "name": "", "value": "", "unit": "", "period": "",
      "source_url": "", "published_at": "", "updated": true }
  ],
  "own_price": { "unit_price": null, "period": "", "source": "" },
  "gap": { "description": "", "basis": "" },
  "notes": [ { "text": "", "source_url": "" } ],
  "needs_human": { "flag": false, "reason": "" }
}

1つ目の理由は、source_url と period を必ず持たせるためです。 どの月の数字かが分からない相場情報は、交渉の材料になりません。項目として持たせておけば、埋まっていない指標を後段のプログラムで機械的にはじけます。 本文だけで返させると、この2つは真っ先に落ちます。

2つ目は、updated で週ごとの差分を機械的に扱えることです。 false の指標は「変化なし」として1行にまとめ、true の指標だけを担当者の確認対象にします。毎週12品目群すべてを読み直させない設計が、確認を12分に収める前提になります。

3つ目は、own_price と gap を空のまま返させることです。 この2つはAIが埋めず、社内のプログラムが生産管理システムの購買単価を書き足します。スキーマに欄はあるが、外部には渡さない。 出力の形を先に決めておくことで、突き合わせの処理を社内側に寄せられます。

notes を文字列の配列ではなく text と source_url の組にしているのも同じ理由です。出典URLを持てない背景説明は、書く場所がありません。

システムへ連携する

生産管理システムへの照会は読み取り専用にしてください。 この構成は購買実績を1行も書き換えません。書き込みの経路を作らなければ、基幹データを壊す事故は起きません。

配布する1枚には、引用をクリックできる形で載せます。PDFやPowerPointに貼り直すときにURLが切れると、この構成の値打ちの半分が消えます。

人が確認する

全件、人が確認します。確認せずに配布する設計にはしません。 目標は1件12分（まとめ案の確認8分、出典の突き合わせ4分）です。

1. 更新のあった指標を確かめる … updated が true の指標だけ、出典URLを開いて値と対象期間の2つを必ず見ます
2. 相場と自社単価の開きを読む … gap は社内のプログラムが機械的に作った記述です。意味があるかを判断するのは人です
3. notes が出典に書いてあるかを見る … 出典URLを開き、書かれていない内容が混じっていないかを確かめます

2番目が、この構成の中心の作業です。 相場が上がっていても自社の単価が据え置きなら、次の協議で説明を求められるのは仕入先の側です。逆に相場が落ち着いているのに自社だけ上がっていれば、こちらから確かめに行く材料になります。この読み取りに担当者の時間を使えるようにするのが、ねらいです。

12分を超えるようなら、updated の判定が効いていません。 毎週すべての指標が true になっているなら、前回値の渡し方を見直します。プロンプトで「短くまとめて」と指示するのではありません。

例外に対処する

2行目を軽く見ないでください。 見つからなかったことを素直に返させないと、どこかから持ってきた数字が、いちばんもっともらしい形で1枚に載ります。 空欄のまま配布されるほうが、はるかに安全です。

記録を残す

• その回に使った巡回先リストの版（品目群名、指標名、許可ドメインの一覧）
• 呼び出しごとの生のJSONと、annotations から取り出した引用URLの一覧
• 担当者が直した箇所と、直した理由
• 配布した1枚の確定版、配布先、配布日時
• 公表予定日と、実際に新しい数字を拾えた日のずれ

3つ目と5つ目を突き合わせると、巡回先リストのどこが古いかが分かります。 同じ品目群で毎週同じ直しが入るなら、参照する指標の選び方が合っていません。