運送を委託している会社との月次の実績会議の資料を、運行と事故と請求からまとめる

処理の起点を決める

月初の決まった日時を起点にします。

日付は、データが確定してからにしてください。 請求の確定が第3営業日なら、第4営業日に走らせます。確定前に走らせると、数字が後から変わります。

時刻は早朝にしてください。 担当者が出社したときに下書きができている状態を目指します。3つのシステムへの負荷も、日中を避けられます。

会議の日程に合わせた2つ目のトリガーも有効です。 委託先ごとに会議の日が違う場合、会議の3営業日前に個別に走らせるという形にできます。ただし、まず月初に全社分をまとめて作る形から始めてください。

会議後のトリガーも置きます。 依頼事項を記録へ足す処理です。ここは担当者が入力したことを起点にします。 自動で議事録から抜き出す形は、最初は避けてください。

手動での実行も用意してください。 データの修正があったときに、資料を作り直せる入口が要ります。

入力データを集める

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

指標の定義を先にそろえてください。 ここが担当者ごとに違うことが、比較できない原因です。

「除く」「分けて示す」の注記が、この構成では重要です。 遅延に再配達を含めるかどうかで、数字が大きく変わります。定義を明文化し、委託先とも共有してください。

資料の型も、全委託先で共通にしてください。

セクション9と10が、この構成で新しく足す部分です。 現状の資料には入っていません。この2つがあるだけで、会議の質が変わります。

前月の依頼事項： 次の形で記録します。

「関係する指標」の列が要ります。 これがあると、翌月の集計と機械的に突き合わせられます。依頼が自由文だけだと、突合できません。

依頼を出すときに、この列を埋める運用にしてください。 会議の場で「時間指定の遵守率を上げてほしい」と伝えたら、その場で「関係する指標＝時間指定の遵守率」と記録します。 後から付けようとすると、対応づけが曖昧になります。

指標に結びつかない依頼もあります。 「ドライバーへの教育を強化してほしい」といった依頼です。この場合は「指標なし」として記録し、翌月は状況を口頭で確認する形にしてください。 無理に指標へ結びつけると、測る対象のずれた評価になります。

委託先の情報も、次の粒度で持ってください。

「契約の形態」が、単価の見方を変えます。 車建て（1台いくら）と個建て（1件いくら）では、1件あたり単価の意味が違います。 混ぜて比べないでください。

AIへ渡す前に整形する

1. 期間の確定 … 前月の1日から末日まで。締めの日が月末でない場合は、その定義に合わせます
2. 委託先コードの統一 … 3つのシステムで委託先の呼び方が違うことがあります。対応表で統一します
3. 除外の適用 … 自社便、緊急便、試験的な配送など、比較の対象外とするものを外します
4. 指標の計算 … 定義に従って計算します。ここはすべてワークフロー側で行います
5. 前月・前年同月との比較 … 差と変化率を計算します
6. 前月の依頼事項の取得 … 関係する指標と、今月の値を紐づけます
7. フィルタによる絞り込み … 変化が小さい指標を、本文の対象から外します

7のフィルタが、資料の読みやすさを決めます。 10セクションすべてに「前月比＋0.2％」といった記述を並べても、読まれません。変化が閾値を超えた指標だけ、本文で触れる形にしてください。

閾値は、指標ごとに変えてください。 事故は1件でも触れる価値がありますが、件数の±5％は触れる必要がありません。

4の計算をワークフロー側で行うことが重要です。 遵守率も前月比も、計算で決まります。生成AIに計算させると、桁を間違える余地を作るだけです。

AIに処理させる

計算処理にさせること（生成AIには任せない）：

Claude API にさせること：

委託先を評価させません。 「この委託先は品質が低い」「契約の見直しが必要」といった記述を禁じてください。

増減の理由も断定させません。 「遅延が増えたのは人員不足によるものです」と書かせないでください。理由は委託先に聞いて初めて分かります。 「遅延が15件から28件へ増えています」という事実までにとどめます。

数値の計算もさせません。 遵守率も前月比も、ワークフロー側で確定させます。

今後の見通しもさせません。 「来月はさらに悪化する見込みです」といった記述は不要です。

指示内容を固定する

あなたは物流部で運送委託先との月次会議の資料を作る担当者です。
集計済みの数値から、会議資料の本文を下書きすることが役割です。

【厳守事項】
- 委託先を評価しないでください。
  「品質が低い」「改善が見られない」「契約の見直しが必要」と書かないでください。
- 増減の理由を断定しないでください。
  「人員不足によるものです」「繁忙期の影響です」と書かないでください。
  数値がどう変わったかという事実までにしてください。
  理由は会議で委託先に聞くことです。
- 今後の見通しを書かないでください。
  「来月はさらに悪化する見込みです」と書かないでください。
- 計算をしないでください。
  遵守率、前月比、前年同月比はすでに計算済みです。
  与えられた数値をそのまま使ってください。
- 与えられていない数値を書かないでください。
  データにない項目について記述しないでください。
- 本文で触れるのは、下の「本文の対象」に含まれる指標だけにしてください。
  閾値を下回った指標について書かないでください。
- 1セクションの本文は3文以内にしてください。
  会議で読み上げるものではなく、数値の表を補う説明です。
- 前月の依頼事項については、依頼の内容と、今月の該当する指標の値を
  並べて書いてください。
  達成／未達成の判定はしないでください。
  **達成したかどうかは、会議で双方が確認することです。**
- 確認すべき点は、数値の変化から「聞くとよいこと」を挙げてください。
  「なぜ増えたのか」「どう対応するのか」を問う形にしてください。
  対応を指示する形にしないでください。
- 全委託先で同じ書き方にそろえてください。
  委託先によって丁寧さや詳しさを変えないでください。

【委託先】
{carrier_name}

【集計済みの数値（指標 / 当月 / 前月 / 前年同月 / 差 / 変化率）】
{metrics}

【本文の対象（閾値を超えた指標）】
{metrics_to_mention}

【事故・クレームの明細（発生日 / 区分 / 内容 / 対応状況）】
{incidents}

【前月の依頼事項（依頼 / 関係する指標 / 期限 / 委託先の回答）】
{prior_requests}

【資料の型（セクションの構成と、書くべき内容）】
{report_template}

「理由を断定しない」の指示が、この構成でもっとも重要です。 資料に「人員不足によるものです」と書かれていると、会議がそこから始まります。委託先が「そうではない」と言えば、資料が間違っていたことになります。 事実だけを書いて、理由は会議で聞くのが正しい順序です。

「達成／未達成の判定をしない」の指示も外せません。 「95％以上」という依頼に対して94.8％だったとき、それを未達成と書くかどうかは、双方の合意の問題です。 集計の期間、除外の扱いで数字は動きます。

「1セクション3文以内」の指示は、資料の使い勝手を守ります。 数値の表があるところに長い文章を付けると、読まれません。表を補う説明に徹してください。

「全委託先で同じ書き方にそろえる」の指示が、比較できる資料を作ります。 現状の問題の1つがここにあります。

出力形式を固定する

{
  "carrier": "",
  "period": "",
  "sections": [
    {
      "section_no": 0,
      "title": "",
      "metrics_mentioned": [],
      "body": "",
      "sentence_count": 0
    }
  ],
  "prior_requests_status": [
    {
      "request": "",
      "related_metric": "",
      "prior_value": "",
      "current_value": "",
      "note": ""
    }
  ],
  "points_to_ask": [
    {
      "topic": "",
      "based_on": "",
      "question": ""
    }
  ],
  "data_gaps": []
}

Claude API で出力をスキーマに沿わせるには、output_config の format に json_schema を指定します。 古い output_format は非推奨で、output_config.format に置き換わりました。

スキーマには制約があります。 required と additionalProperties: false は使えます（オブジェクトには additionalProperties: false の設定が必要です）。一方、数値の minimum / maximum / multipleOf、文字列の minLength / maxLength / pattern、条件付きの if / then / else は使えません。 minItems は0と1のみです。

sentence_count を持たせている理由があります。 「3文以内」という制約をスキーマでは縛れないため、返ってきた値を受け取り側で確かめます。 超えていたら書き直させる処理を入れてください。

prior_requests_status に判定の欄を置いていないことが、設計上の意図です。 依頼と、前月の値、今月の値を並べるだけにします。達成したかは会議で決まります。

points_to_ask は「問う形」で書かせます。 「時間指定の遵守率が3.2ポイント下がっている理由を確認する」という形です。「遵守率を改善すること」という指示の形にしないでください。

data_gaps は、取得できなかったデータです。 品質の記録が未入力、請求が未確定。空欄のまま資料を作ると、数字がないことに気づけません。

システムへ連携する

資料の下書きを作るだけで、他のシステムへの書き込みは行いません。

委託先へ自動で送らないでください。 資料は担当者が確認してから渡します。下書きのまま送ると、誤りがそのまま伝わります。

輸配送管理システムや会計システムへの書き戻しもありません。 データはそれらのシステムが正です。

会議後の依頼事項の入力は、人が行ってください。 議事録から自動で抜き出す形は、最初は避けてください。依頼の内容と、関係する指標を紐づける作業に判断が要ります。

通知は、下書きができたときだけにしてください。 月に1回です。毎日の通知が来る仕組みにしないでください。

人が確認する

担当者の確認は必ず残します。

「理由の補足」が、担当者の残る仕事です。 「先月、A社の管轄で大雪があった」という事情は、データからは分かりません。担当者が知っていることを書き足すことで、資料が使えるものになります。

確認を速くするための設計が効きます。

• 数値の表と本文を並べて表示する
• data_gaps を先頭に置く
• 前月の依頼事項を、依頼の内容とともに表示する
• 委託先どうしを並べた比較表を別に作る
• 理由の補足を書き込む欄を用意する

4つ目が、現状できていない部分です。 同じ方面を2社に任せている場合、並べて見られると議論の材料になります。 ただし、委託先へ渡す資料には他社の数字を載せないでください。

社内用と委託先用で、資料を分けてください。 比較表と、社内の評価に関わる内容は、社内用にとどめます。

例外に対処する

「事故が0件の月に0と書く」は、細かいようで重要です。 触れないでおくと、データが取れなかったのか、本当に0件だったのかが分かりません。

記録を残す

この記録は、委託先の管理の履歴になります。

• 各月の集計結果（委託先 × 指標）
• 資料の下書きと、担当者が補った内容
• 会議での確認事項と依頼事項
• 依頼事項の翌月の状況
• data_gaps の内容と、その後の補完
• 資料の作成にかかった時間

「担当者が補った内容」を記録してください。 毎月同じ補足が必要なら、その情報はデータとして取れるようにすべきです。

「依頼事項の翌月の状況」が、この構成を続ける理由になります。 会議で伝えた依頼が、翌月どうなったか。この追跡ができるようになることが、いちばんの変化です。

この記録は、契約の更新や運賃の交渉の材料になります。 「過去12か月の遵守率の推移」を示せる状態は、交渉の場で力を持ちます。ただし、評価そのものは人が行ってください。

委託先の実績データには、取引条件（単価）が含まれます。 保管場所と閲覧範囲を物流部に限定してください。他の委託先の数字が混ざらないよう、資料の作り分けにも注意が要ります。

保存期間は、契約の期間と、運送の記録の保存期間に合わせてください。 事故の記録は、後から参照されることがあります。