荷主から届く配送日時の変更依頼メールを、Make のAIエージェントが出荷と配車の状況に照らして、変更できるものは手配の案を作り、出荷済みや判断の要るものを担当へ回す

処理の起点を決める

受付のシナリオを、Gmail の Watch emails で5分ごとに動かします。 対象は「変更依頼」のラベルが付いた未読のメールです。荷主のドメインから届き、件名か本文に「変更」「延期」「日時」「納品日」などの語があるメールにラベルを付ける Gmail のフィルターを置きます。取り込んだときに既読にする設定にはしません。 窓口が受信箱でも追えるようにします。

5分ごとにするのは、便の出発に間に合わせるためです。 午後の便が14時に出るなら、13時半に届いた依頼は30分以内に保留をかけないと積み込まれます。 1時間ごとの処理では、第3章の（a）がそのまま残ります。

受付のシナリオは、エージェントを呼ぶ前に荷主を決めます。 差出人のアドレスで荷主の一覧を Search Rows で引き、荷主のコードを決めます。荷主が決まらないメールはエージェントを呼ばずに担当へ回します。 別の荷主の出荷を調べる道を最初から作らないためです。

同じスレッドで続けて届いた依頼は、同じ会話として扱います。 スレッドのIDから会話のIDを作って Run an agent に渡します。「先ほどの件、やはり午後着で」という2通目を、前の依頼とつなげて読めるようにするためです。

入力データを集める

エージェントに最初から渡すのは、依頼の本文と荷主のコードだけです。 出荷・便・届け先は、エージェントが道具で取りに行きます。最初に全部を渡さないのは、依頼に書かれた出荷番号や届け先が正しいとは限らないからです。 道具の結果を見て、番号の書き間違いに気づけるようにします。

届け先の受け入れの一覧は、最初の準備で作ります。 配車のベテランの記憶と、過去のメールに書かれていた条件を1行ずつ書き出します。第3章の（c）を表に移す作業で、この構成の効果の半分はここで出ます。

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

どの道具も、Google Sheets の Search Rows で表を引き、Return outputs で必要な列だけを返します。 「出荷を探す」は、荷主のコードを必ず条件に入れます。 エージェントが渡す値ではなく、受付のシナリオで決めた荷主のコードを道具の入力の固定の値にします。エージェントが別の荷主の出荷を引く道を、道具の側で塞ぐためです。

出荷の進み具合には、いつ時点の状態かを必ず付けて返します。 表は30分ごとの書き出しなので、ピッキングが始まっていても、表の上ではまだ「引当済み」に見えることがあります。 このため、便の出発の60分前を過ぎた出荷は、表が「引当済み」でも案を作らずに担当へ回す規則を、手配案を作る道具の側に置きます。

道具をすべてシナリオにするのは、条件を道具の中に閉じ込めるためです。 Google Sheets のモジュールをそのまま道具に渡すと、エージェントがどの列をどの条件で引くかまで決めることになります。 シナリオにしておけば、引く条件も、返す列も、案を書く前の確かめ直しも、こちらで決めた形に固定できます。

AIへ渡す前に整形する

1. 引用の除去 … 返事のメールに付いている過去のやり取りを外し、最新の本文だけを渡します
2. 添付の扱い … 依頼が表計算の添付で届いたときは、エージェントに渡さず担当へ回します。複数の出荷を一覧で送ってくる依頼は、人が確かめたほうが早いからです
3. 出荷番号の候補を拾う … 本文から出荷番号の形の文字列を拾い、候補として添えます。確定はエージェントが道具で行います
4. 会話のIDを作る … スレッドのIDから作ります
5. 自動の通知を外す … 荷主のシステムから自動で送られる出荷の予定の通知などを、件名の語で外します

1番目を省くと、エージェントが古い依頼を読みます。 「先日20日への変更をお願いしましたが、やはり元の18日でお願いします」というメールで、引用された古い本文の「20日へ変更」を読んで案を作るのが、いちばん困る誤りです。

AIに処理させる

エージェントにさせるのは、依頼を読み、道具をどの順で使うかを決め、結果を見て次を選ぶことです。

手配案を作ってよいのは、次の4つがそろうときだけです。 手配案を作る道具も、書く前に同じ4つを表で確かめ直します。

2行目を「させない」に置いているのは、運送の約款の扱いに関わるからです。 標準貨物自動車運送約款は、荷送人が運送の中止、返送、転送その他の処分を指図できること、運送上の支障が生ずるおそれがあると認めるときは指図に応じないことがあり、そのときは遅滞なく通知することを定めています。出発した後の変更をどう受けるかは、配車の担当が決めます。

指示内容を固定する

エージェントの指示（Instructions）に書く内容の例です。

あなたは物流会社の荷主窓口で、荷主から届いた配送日時の変更依頼を
調べる担当です。依頼の本文と、道具が返した結果だけを根拠にしてください。
推測で補わないでください。

【進め方】
1. 依頼が、日の変更／時間帯の変更／両方／その他のどれかを決める。
   その他（キャンセル、届け先の変更、数量の変更など）は担当へ回す。
2. 出荷を探す道具で出荷を特定する。出荷番号の候補があればそれで探し、
   無ければ届け先と元の予定日で探す。
   見つからない、または2件以上見つかって1つに決まらないときは担当へ回す。
3. 出荷の状態と書き出しの時刻を確かめる。
4. 便を調べる道具で、新しい日の同じ方面の便をすべて調べる。
   1本目が満載でも、2本目以降を必ず確かめる。
5. 届け先の条件を調べる道具で、新しい日と時間帯が合うかを確かめる。
6. 4つの条件（進み具合・便の空き・届け先・締め時刻）がすべて合うときだけ、
   手配案を作る道具を呼ぶ。1つでも合わなければ担当へ回す。

【厳守事項】
- 新しい日時は本文に書かれたものだけを使ってください。
  「来週あたり」「できるだけ早く」のように日が決まらない依頼は、
  日を決めずに担当へ回してください。
- 依頼に複数の出荷があれば、出荷ごとに2〜6を行い、
  出荷ごとに案を作るか回すかを決めてください。
- 運賃、手数料、追加の費用について書かないでください。
- 依頼に書かれていない出荷を変えないでください。
- 担当へ回すときは、reason に合わなかった条件と、道具が返した値
  （状態と書き出しの時刻、便の空き、受け入れの時間帯）を書いてください。

【荷主のコード】{shipper_code}
【依頼の件名】{subject}
【依頼の本文（引用を除いたもの）】{body}
【出荷番号の候補】{candidates}

「2本目以降を必ず確かめる」と書くのは、第3章の（b）を防ぐためです。 エージェントは最初に見つけた便が満載だと、そこで「空きなし」と結論しがちです。同じ方面の便を全部見ることを手順として書きます。

「日が決まらない依頼は回す」も明記します。 書かないと、エージェントは「来週あたり」を来週の月曜と読み、空いている便を見つけて案を作ります。荷主の顧客がいつを望んでいるかは、荷主に聞き返すしかありません。

出力形式を固定する

Run an agent の応答の形を Data structure にし、次の形で受け取ります。

{
  "request_type": "date | time | both | other",
  "items": [
    {
      "shipment_no": "",
      "original": { "date": "", "time_slot": "" },
      "requested": { "date": "", "time_slot": "" },
      "status_seen": "",
      "status_as_of": "",
      "result": "planned | escalated",
      "plan_row_id": "",
      "reason": ""
    }
  ],
  "reply_kind": "accepted | checking"
}

1つ目の理由は、出荷ごとに結果が分かれることです。 3つの出荷のうち2つは案ができ、1つは出荷済みで回した、という結果をそのまま items に並べられます。 返事の下書きも、出荷ごとに「手配します」「確認します」を書き分けます。

2つ目は、status_as_of で何時点の状態を見たかが残ることです。 配車の担当は案を反映する前に、その時刻から倉庫の状態が変わっていないかだけを確かめれば済みます。

3つ目は、返事の下書きをワークフローの側で組めることです。 reply_kind と items から、定型の文に出荷番号と日時を差し込んで下書きにします。 エージェントに返事の文を自由に書かせないので、費用の約束が紛れ込みません。

手配案の表には、手配案を作る道具が次の列を書きます。

システムへ連携する

倉庫管理システムと配車表の元のデータには書き込みません。 道具が書くのは、手配案の表と確認の表の2枚だけです。配車表はコピーを引いて空きを見るだけにし、反映は配車の担当が元の配車表で行います。 エージェントが便の空きを使ったことにして、同じ空きに2件の案が載ることは起こりえます。手配案の表に「その便に載せた案の重さ・才数」の合計の列を置き、空きからその合計を引いた値で次の案の判定をするように道具の中で計算します。

人が確認する

1. 手配案は配車の担当が見る … status_as_of から倉庫の状態が変わっていないかを確かめ、反映します
2. 回したものは理由から見る … 出荷済み、便の空きなし、届け先の条件、日が決まらない、の順に多いはずです
3. 出荷済み・積込済みは配車の担当と荷主窓口で決める … 持ち戻りか再配達か、費用をどうするかを決めて荷主に伝えます
4. 下書きを直して送る … 送信は荷主窓口の担当が行います
5. 差し戻した案は理由を書く … どの条件の見方が違ったかを残します

1番目を省かないでください。 案はエージェントが表を見た時点の判断で、その後の30分で倉庫の状態が変わっていることがあります。

目標は、400件をならして1件3分です。 手配案を確かめて反映するだけのものは1〜2分、回したものは配車の担当と相談して数分かかります。回すのが4割前後という想定です。

例外に対処する

上から4行目までが大半を占めます。 どれもエージェントの判断の問題ではなく、表の書き出しと、届け先の一覧の整い方の問題です。 書き出しが止まったことに気づく仕組みを、最初に作っておきます。

記録を残す

• 受信したメールのID、受信日時、荷主のコード、会話のID
• エージェントに渡した入力と、エージェントの応答の全文
• 道具の呼び出しごとの入力と返した値 … 各シナリオの実行の履歴に残る
• 手配案の表と確認の表の行、状態を変えた日時と人
• 差し戻した案の理由

3つ目が、後から誤りをたどる材料になります。 「空きがあると判断した便に、実は空きが無かった」ときに、エージェントの読み違いか、表の値が古かったのかを、道具が返した値で切り分けられます。