顧客の希望は『注文Q-17の商品A10個を、10月30日ではなく25日までに届けてほしい』です。AIへ頼む目的は、前倒しの判断材料と不明点を業務担当へ返すこと。顧客への返答は人が行います。

図の『検索』は、資料を調べるために接続した機能です。AIは許可した道具から必要なものを選びます。在庫が足りれば生産の確認を省ける場合があり、不足なら生産予定へ進みます。

製品ごとに『エージェント』の範囲は違います。名称だけで選ばず、目的、読める資料、操作、人へ戻す場所を確認します。仕事の責任は人に残ります。

図の6個は、倉庫の総数ではなく、この注文に使える在庫です。不足4個の完成日は10月24日の予定で、顧客へ届く日ではありません。配送条件が資料にないため、25日到着の可否は人へ戻します。

回答案には、参照した資料名と確認時点も付けます。資料が見つからない、検索が失敗する、権限外の情報が必要な場合は、理由と残った確認を返し、推測で完成扱いにしません。個数と日付は説明用の架空条件です。

同じQ-17でも、資料を1度そろえれば済むなら単発チャット、決まった順序と分岐で調べられるなら固定フローが候補です。必要な資料や次の作業が結果によって変わる仕事では、エージェントを検討できます。

チャットは話しかける形式で、チャット画面から道具を使う製品もあります。ここでの単発チャットは、人が資料を渡して整理を頼む使い方です。『チャットには道具が使えない』という区別ではありません。

道具や手順が増えるほど、待ち時間、費用、確認する結果も増え得ます。名称で選ばず、自社の仕事が単純な方法で済むかを先に確かめます。

この例のAIには、対象の注文と商品について注文・在庫・生産を読む接続を用意します。すべての社内ファイルを読ませる必要はありません。営業情報を渡せる契約、データの扱い、社内の決まりも、利用前に確認します。

業務担当は、注文数量、この注文に使える在庫数、生産予定、配送条件を元資料と照合し、責任者が前倒しの約束を判断します。顧客への返答は人が行います。記録更新は、約束を承認し、更新が必要な場合だけ人が行い、保留中は更新しません。

『送らないで』という依頼文だけでなく、AIの道具側でも更新・送信の権限を付けない設計にします。資料を読む接続があることと、会社としてその利用や操作を認めることは別です。

この分担を設定担当へどう伝えるか迷う場合は、AIに読ませる資料・案の保存先・人の操作を分ける権限表の作り方で、注文確認の記入例を見てください。この章で決めた「検索はAI、返信は人」を、具体的な参照先と操作の一覧にできます。

OpenAIの現行Agents資料には、道具の操作を検査し、人の確認で一時停止する設計例があります。自社の重要な操作を確認点が覆うかは、開発・運用側で確かめます。図の分担だけで権限設定が完了するわけではありません。

在庫表に「6個」と書いてあっても、いつ更新された表か分からなければ、今も6個使えるとは言い切れません。別の注文へ使った分が引かれていない可能性があります。同じ商品名でも型番が違う、完成予定が変わった、といった点も担当者が元資料へ戻って確かめます。

図は、注文表で商品A10個を確認した後、在庫表の更新日が分からず止めた別の場面です。業務担当へは、Q-17の注文表、読んだ在庫表、止めた理由、未確認の欄を一緒に返します。在庫の最新数も、生産予定も、配送条件も未確認です。最初の例の「6個」を、この場面の最新数として写してはいけません。

メモの次の仕事は「業務担当が在庫担当へ、この注文に使える最新の数を確かめる」です。答えが分からないだけのメモより、誰が何を調べれば続けられるかが分かります。分かった結果を同じQ-17へ追記し、普段の納期確認を続けます。

記録を手元で見比べる：調べた結果の見本（CSV）／途中で止めた記録の見本（CSV）／2つの見本と使い方をまとめて保存（ZIP）。すべて架空の教材です。

外部メールや文書にAIへの操作指示が紛れていても、それを理由に許可外の参照や送信・更新へ進めない設計にします。回答への注意書きだけでは防げません。

この例の初回試行は、注文・在庫・生産の参照3回までとする提案です。同じ検索が続く、または上限に達したら止めます。回数は普遍的な基準ではありません。使った道具、結果、残り作業を渡して通常の確認に戻り、原因を確かめてから再開します。