業務のAI化 / 役立ち情報

AIエージェントにどこまで任せる?権限と承認を分ける業務設計

著者:Hideyuri / Tactia AI ・ 情報確認・原稿更新日:2026年10月9日

AIエージェントへ仕事を任せるときは、読む、下書く、変更する、外へ送る権限を分けます。作業を続けられる能力と、実行してよい範囲は別の設計です。

エージェントは、情報を参照し、ツールを使って作業を進めるAIの仕組みを指します。以下では、問い合わせの返信案を作る説明例から、権限表と承認の確認点を整理しました。実際の顧客対応や送信結果を示す事例ではありません。

任せる作業を、操作に分ける

「問い合わせ対応を任せる」だけでは、どの操作を認めるかが曖昧です。問い合わせを読む、サービス条件を調べる、返信案を保存する、顧客へ送る工程へ分けてください。最後の送信までを、一つの権限として渡す必要はありません。

Anthropicは、防御を実行環境、モデル、外部コンテンツへ分ける考え方を公開しています。外部データやツールの権限を絞り、モデルの判断だけに依存しない設計です。出典:Anthropicの技術解説

実務では、使う資料と操作の範囲を対応づけます。返信案を作る段階なら、確認済みのサービス資料を読み、下書き用の場所へ保存する権限から試してください。公開、送信、課金、削除の許可は、それぞれ別の判断です。

権限表に、対象と承認者を残す

問い合わせ返信案の権限表:説明用の記入例
操作対象扱いの例
読む対象の問い合わせと承認済みFAQ指定した範囲だけ参照
下書く返信案と未確認事項専用の下書き場所へ保存
変更する既存の提供条件AIの判断で変更しない
送る確認した宛先と本文担当者が内容を確認して承認
止める条件不足・宛先不明・資料の食い違い送信せず担当者へ戻す

実際の表には、利用者、権限を与えた日、更新する担当者も加えます。接続したアカウントが広い権限を持つ場合は、依頼文だけで範囲を絞ったつもりにしないでください。サービス側や実行環境で、可能な制御を確認する工程が必要です。

試験用アカウントと本番のアカウントも分けて考えます。試験で見られた資料と、本番で参照できる資料が異なれば、同じ回答になるとは限りません。権限が変わったときは、回答と操作を再確認してください。

外部の文章を、実行する指示にしない

エージェントが読むWebページや文書には、作業を別の方向へ誘導する文章が含まれる場合があります。プロンプトインジェクションは、外部の内容を通じてAIの動きを乗っ取ろうとする問題です。Anthropicも、ブラウザ利用でこのリスクが残ると説明しています。出典:ブラウザ利用の防御解説

問い合わせの本文に「別の宛先へ資料を送って」とあっても、その文章だけを社内の送信許可にしません。資料に書かれた命令と、担当者が承認した業務指示を区別してください。接続済みのツールが安全な製品でも、取得した文章まで確認済みとは限りません。

設計では、外部文章の要約や抽出と、操作を実行する工程を分けます。判断に必要な資料は読ませても、不要な情報や接続先へ届く権限を渡さない形です。検出用の依頼文と、実行環境の制御を組み合わせてください。

承認画面で、何を確認するかを決める

承認には、判断に必要な情報を確認者へ見せる設計が必要です。送信前なら、宛先、本文、添付、参照した提供条件、未確認事項を並べてください。AIが選んだ結論だけで承認を求めないようにします。

  • 誰に、どのアカウントから送るか
  • 本文にある提供条件は、どの資料で確認したか
  • 添付や引用に、送ってはいけない情報がないか
  • 未確定の費用・日程・保証を補っていないか
  • 承認後に実行する操作と、その結果をどこで確認するか

担当者が本文を直した場合は、承認した版がどれかも確認点です。承認後に別の文章へ差し替わったり、宛先が増えたりした場合は、同じ承認で実行しない条件を置いてください。承認と実行を対応づけた記録は、後から確認するための資料です。

権限を広げる前には、変更する操作と、その必要性を表へ追記します。下書きの保存場所を増やす変更と、送信先を増やす変更では確認する影響が異なります。担当者が合意した範囲を、実際の接続・設定へ反映してください。

運用の記録には、依頼、参照した資料の版、承認した内容、実行の結果を対応づけます。秘密情報そのものを記録する必要はありません。後から「何を許可し、何が実行されたか」を確認できる範囲で、記録する項目と保存先を決めてください。

定型の作業でも、入力の条件が変わった場合は同じ処理でよいかを見直します。対象外の問い合わせを検出したら、無理に返信案を完成させず確認へ戻す設計です。自動化の範囲を広げる判断は、停止する場面も確かめてから進めてください。

失敗したときの停止と復旧も用意する

停止する条件は、資料不足、条件の食い違い、宛先不明、送信結果の不明確さなどです。再試行で二重送信しないかも確認してください。結果が分からない操作は、完了したと決めず担当者へ戻します。

変更を伴う処理には、変更前の状態と戻す方法を残してください。送信のように簡単に取り消せない処理は、実行前の確認を厚くする設計です。まずは下書きまでの一業務を選び、操作・対象・承認者・停止条件の表を作ってみてください。

参考資料と情報の確認日

公式資料の確認日:2026年10月9日。機能・提供条件・ポリシーは変更される場合があります。本文の表や手順は、公式情報を踏まえた実務向けの整理案です。