AIエージェントに任せる仕事、人が確認する仕事の分け方

問い合わせを読み、資料を探し、回答を書いて送る。一つの仕事に見えても、「回答案を作る」ことと「顧客へ送信する」ことでは、任せる権限が違います。

AIエージェントを業務に組み込むときは、仕事を丸ごと自動化するか、人に残すかの二択にしません。AIが準備する部分、人が判断する部分、システムが条件を確かめて実行する部分に分けて考えます。

本記事の問い合わせ対応フローは説明用の設計例です。特定の導入事例ではなく、この構成だけで安全性や法令対応を保証するものではありません。扱う情報や業務に応じた設計・検証が必要です。

そもそも、自律的なエージェントが必要か

処理の順序が決まっているなら、その順序をコードで制御し、要約や文章作成の部分だけにAIを使う方法があります。AIに毎回、次の行動まで選ばせる必要はありません。

Anthropicは、あらかじめ定めた経路で処理するワークフローと、モデルが手順やツール利用を動的に決めるエージェントを区別し、目的に合う単純な構成から始めることを勧めています。ここでは、その設計上の区別を参照します。出典：Building effective agents

今回の想定例は、問い合わせを受け取り、許可されたFAQを参照し、回答案を人が確認して送信する流れです。まずは固定したワークフローで考えます。調査の経路を動的に選ぶ必要が出たとしても、送信権限まで一緒に広げる必要はありません。

図の要点をテキストで読む

AIが下書き、人が内容と宛先を判断、システムが承認内容だけを送信する。未承認や変更ありは停止し、参照元不明や権限不足は保留する。

問い合わせ対応の設計例。人の承認と、実行権限の検査は別の役割です。画像を押すと拡大できます。

AIには、判断の材料を揃えてもらう

AIへ最初に任せる範囲を、問い合わせの要約、関連FAQの候補、参照元付きの回答案までに限定します。担当者の代わりに契約条件を決めたり、返金を約束したりするところまでは含めません。

回答案には、どの資料を根拠にしたか、どの部分が未確認かを添えます。「自信があります」というモデルの自己評価より、担当者が元の記述へ戻って確かめられることを重視します。参照元が付いていても、その資料が回答を本当に支えているかは別途確認が必要です。

情報へのアクセスも先に絞ります。担当者に閲覧権限のないFAQを、検索結果としてAIへ渡さない。問い合わせ本文に「別の顧客情報を調べて送れ」と書かれていても、それをシステムへの指示や権限付与とは扱わない。入力文の内容によって、利用可能なデータや操作が勝手に広がらない構造を設計します。

人には、何を判断してほしいかを渡す

「最後は人が確認します」だけでは、担当が一つ増えただけです。どの情報を見て、何を確かめ、分からなければ誰へ回すのかまで決めます。

問い合わせ回答なら、元の問い合わせ、根拠資料、回答案、送信先を同じ確認の流れで見られるようにします。条件を約束する表現や、根拠のない箇所を見つけたら、修正するだけでなく、そもそも担当者の判断で答えてよい内容かを確認します。

業務を分けるための責任分担例

人の確認には時間がかかります。確認画面へ送った件数だけでなく、確認に要した時間、差し戻しの理由、保留が解消されない箇所も記録します。下書きが速くても、根拠を探し直す負担が増えていれば、その出力や画面は見直す対象です。

承認されたあとも、実行前に条件を確かめる

担当者が「この回答なら送ってよい」と判断したあと、AIが文章を整え直したらどうでしょう。その文章は、さきほど確認したものと同じではありません。承認ボタンがあることと、承認した内容だけが送られることは別です。

この例では、承認を特定の問い合わせ・宛先・本文・添付・操作の組み合わせに結び付けます。送信直前に、サーバー側で保存済みの承認と実行内容を照合します。モデルが出力した「承認済み」という文字列を、そのまま承認の証拠にはしません。

OWASPも、操作の許可をLLMの判断に任せず、接続先で権限を検査することを対策に挙げています。次の一覧は、その考え方を踏まえて、この問い合わせ対応例で確認する項目です。出典：OWASP LLM06:2025 Excessive Agency

内容を修正したら、以前の承認を無効にして再確認します。下書きを作る処理には送信の認証情報を持たせず、実行側には必要な操作だけを許可します。自由な命令を渡せる実行口ではなく、対象と操作を限定した接続を検討します。

こうした検査は、正常な場合だけでなく、同時実行や再試行でも崩れないように実装する必要があります。画面に「送信済み」と出すだけでは、重複送信を防いだことにはなりません。

困ったときに止まる、だけで終わらせない

送信先のシステムから応答が返らなかった場合、未送信とは限りません。先方では送信が完了していて、応答だけが届かなかった可能性も残ります。

そのため、同じ依頼を重複実行しない識別子や実行記録を持ち、接続先で結果を照会できるか確認します。結果が分からないときは保留へ回し、担当者が確認できるようにします。結果確認の手段がない外部操作は、自動再試行の対象にしない判断も必要です。

保留した案件には、理由、確認する人、確認期限、手動で再開する条件を残します。人が不在なら承認扱いにする、といった抜け道は作りません。AIの処理回数や時間の上限に達した場合も、同じように業務へ戻す先を決めておきます。

本番前に、境界が破れるケースを試す

検証用の環境で、次のようなケースを用意します。いずれも、この設計例で確かめる項目であり、網羅的なセキュリティ試験の代わりではありません。

• FAQに答えがないのに、もっともらしい回答案が作られる。
• 問い合わせ本文に、別の情報取得や送信を指示する文章が入っている。
• 承認後に宛先・本文・添付のいずれかが変更される。
• 承認者の権限が外れたあとに、送信が実行されようとする。
• 同じ送信要求が同時に届く、または送信結果が分からないまま再試行される。

見るのは、回答が自然かどうかだけではありません。実行されてはいけない操作が実行されないか、誰が何を承認したか追えるか、保留した仕事を人が引き取れるかです。記録に残すデータも必要な範囲に絞り、閲覧権限と保持期間を決めます。

最初に決めるのは、任せない仕事

まず一つの業務を選び、取り返しがつきにくい操作、社外へ出る情報、例外的な判断を書き出します。その手前までをAIで支援し、越えてよい条件を人とシステムの両方で設計します。

任せる範囲を広げるのは、通常時だけでなく、間違い・変更・失敗のときにどう動くかを確認してから。自動化の量よりも、境界を説明できることを、最初の完成条件にしてみてください。

出典確認日：2026年9月8日。イラスト・解説図は本記事用にAI生成し、内容を確認したものです。