AIエージェントにどこまで任せる？送信・更新の前に人が確認すること

まずは「返事を書いておく」まで任せてみる

説明用の例として、取引先から注文数量の変更依頼が届く業務を考えます。担当者は元の注文を探し、在庫と納期を確認し、台帳を直して返事を書きます。AIエージェントは、こうした複数の処理をツールと組み合わせて進める仕組みです。ただし、一連の仕事をすべて自動にする必要はありません。

最初は、対象の注文候補、変更内容、返信案を用意するところまで任せられます。担当者はメールの原文と候補を見て確定し、送信や登録は従来の操作で行います。この使い方でも、情報を集めて文章を作る負担が減るかを検証できます。

下書きを使ってみると、同名の顧客や注文番号のない依頼など、判断に迷う場面が分かります。それらを整理してから更新や送信へ進める方が、何を自動化すればよいかを決めやすくなります。想定だけで広い実行権限を付ける前に、実際に残る確認作業を見ておきます。

確認を挟む場所は、間違えたときの影響で選ぶ

資料を探すたびに承認を求めると、担当者の手間が増え、内容を読まずに許可する運用になりかねません。閲覧できる資料の検索や限定した下書き保存は事前に範囲を定め、取引先への送信や重要項目の更新は個別に確認する、という分け方が考えられます。

OWASPのExcessive Agencyの資料では、機能と権限を必要最小限にし、影響の大きい操作へ人の承認を入れる対策が示されています。以下は説明用の方針例です。読み取りでも外部サービスへ情報を送る場合は、送信できるデータの範囲を別途確認します。

表が収まらない場合は横にスクロールできます。

参考：OWASP GenAI Security Project：LLM06:2025 Excessive Agency

「実行してよいですか」だけでは、判断できない

承認画面には、何を、誰に対して、どう変えるかを出します。注文変更なら、注文番号、変更前後の数量、連絡先、最終的なメール本文、添付です。長い説明を読むより、原文と変更差分を見比べられる方が、担当者は確認すべき箇所を見つけやすくなります。

承認した後でAIが本文を作り直すと、担当者が見ていない内容を送ることになります。そのため、承認対象は版などで固定し、宛先や内容が変われば再確認へ戻します。「この注文について返信してよい」という広い同意ではなく、表示した具体的な内容への同意を記録します。

待っている間に別の担当者が台帳を更新することもあります。実行直前に対象の状態と権限を確かめ、条件が変わっていれば古い内容で上書きしません。一括処理では対象一覧も固定し、承認後に増えた注文まで勝手に含めないようにします。

承認待ちのまま翌日になっても、続きを追えるようにする

承認はすぐに返ってくるとは限りません。担当者が不在、通知が埋もれた、システムが再起動した、といった場合も、待っている依頼を一覧で追える必要があります。承認待ち、却下、期限切れ、取消、実行中、完了を保存し、誰が判断する番なのかを分かるようにします。

開発基盤が中断と再開に対応していても、作業がそのまま安全に続くとは限りません。たとえばLangGraphの公式資料では、再開時に中断した処理単位の先頭から実行し直すと説明されています。中断前の位置に外部への登録を置いていると、その処理が再び走る点を考慮する必要があります。

使う製品の名前より、承認待ちの記録が残ること、却下や取消後に実行されないことを確認しましょう。担当者が交代する場合も、誰でも代わりに押せるようにせず、その操作を承認できる人へ引き継ぎます。

参考：LangChain：Interrupts

返事が来ないとき、もう一度送ってよいとは限らない

外部システムが注文を更新した直後に通信が切れると、こちらには成功の返事が届かない場合があります。そこで失敗と決め付けて再送すると、登録や通知が重複するおそれがあります。「未実行」と「実行したか不明」を区別することが必要です。

AWSのBuilders’ Libraryは、呼び出し側が一意の依頼IDを付けて、再試行を同じ操作として扱う設計を説明しています。採用するAPIでも、同じ依頼の重複を防ぐ機能や結果の照会が使えるかを調べます。API側で対応できない場合は、結果不明のまま保留し、人が記録を照合する運用も選択肢になります。

複数の操作は、途中だけ成功することもあります。注文変更の例なら「台帳は更新済み、メール送信は未完了」と表示できると、必要な処理だけを再開できます。送信済みのメールは取り消せない場合があるため、一括で最初からやり直す仕組みにはしません。

参考：Amazon Web Services：Making retries safe with idempotent APIs

開発会社には、止まった後の画面も見せてもらう

依頼先を比べるときは、連携できるツール数や自動で進むデモに加えて、却下、通信断、承認後の変更をどう扱うかを見ます。担当者が画面を見て、実行済みのこと、残っていること、次に誰が動くかを説明できる状態が望ましいです。

費用には、文章生成だけでなく、承認画面、状態の保存、外部APIの制御、運用記録、復旧の確認が含まれます。予算が限られるなら、まず下書き支援に絞り、送信と更新の自動化は別段階にする方法があります。確認作業を含めても業務が楽になるかを、その段階で測れます。

相談には、実際の依頼文を加工した例と、担当者が普段使う画面、失敗すると困る操作を持ち寄ると話が進みます。どこまで任せるかを決めてから、必要な承認と復旧の仕組みを具体化しましょう。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □検索・下書き・送信・更新を別の操作として整理した。確認状況・メモ：
• □取り消せない操作と、一括処理の影響を把握した。確認状況・メモ：
• □承認画面で原文と変更差分を確認できる。確認状況・メモ：
• □承認後の内容変更や期限切れの扱いを決めた。確認状況・メモ：
• □通信断で結果が分からないときの確認先がある。確認状況・メモ：
• □一部だけ成功した処理を追えるか確かめた。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• LLM06:2025 Excessive AgencyOWASP GenAI Security Project
• InterruptsLangChain
• Making retries safe with idempotent APIsAmazon Web Services