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

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

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

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

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

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

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

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

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

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

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

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

検索できても、資料が古い、同名商品を取り違える、別の注文に使う予定の在庫を含める、生産予定が変わる、といった誤りは起こり得ます。人が資料名と確認時点へ戻り、この注文に使える最新の在庫数を確かめます。

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

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