AIエージェントの権限設計｜最小権限とHuman-in-the-loopの実装
最終更新日：2026/10/14
AIエージェントの権限設計とは、エージェントが呼び出せるツールと操作範囲をあらかじめ絞り、影響の大きいアクションに人間の承認を挟む設計です。PoCでは動いたのに本番導入でつまずく論点の1つがここにあります。本記事は、権限の切り方と承認フローの実装をエンジニア視点で整理します。
先に結論
エージェントの権限はツール単位ではなくリソース単位・条件単位まで絞る。読み取りと書き込みを同じツールにまとめない
OWASPは過剰な権限の問題を LLM06:2025「Excessive Agency」 として整理している。原因は「機能の過剰」「権限の過剰」「自律性の過剰」の3つ
Human-in-the-loop（HITL）は全アクションに挟まない。不可逆性と影響範囲の2軸で、承認が必要なものだけに絞る
承認フローで事故が起きやすいのは設計そのものより運用の穴。タイムアウト時の既定挙動、承認者不在時のエスカレーション、再開時の二重実行の3点を先に決める
受託・業務委託で入る場合、権限設計は見積もりに載りにくい。要件定義フェーズで「誤実行時の責任分界点」を文書化しておくと後工程が揉めにくい
この記事でわかること
AIエージェントの権限が、通常のアプリケーション権限と何が違うのか
最小権限をスコープ設計に落とし込む具体的な手順
Human-in-the-loopをどのアクションに、どう挟むか
承認キューの滞留・タイムアウト・冪等性といった運用設計の勘所
OpenAI Agents SDK・LangGraph・MCPでの実装の入り口
対象は、実務経験3年以上で、エージェントを社内システムや顧客環境に組み込む立場のエンジニアです。エージェントそのものの概念から知りたい場合はAIエージェントとは？仕組み・種類・活用事例をわかりやすく解説を先に読んでください。
目次
AIエージェントの権限設計とは｜ツール実行の認可がなぜ新しい論点なのか
最小権限をエージェントに落とし込む｜スコープ設計の考え方
Human-in-the-loopとは｜どこに人間を挟むか
承認キューの設計｜ここで事故が起きる
フレームワーク別の実装の入り口
承認を挟むコストとレイテンシ
よくある失敗と対策
権限設計チェックリスト
フリーランス案件で権限設計はどう効くか
まとめ
よくある質問
AIエージェントの権限設計とは｜ツール実行の認可がなぜ新しい論点なのか
結論から言えば、権限の主語が「人」から「推論結果」に変わったことが新しさの正体です。従来のアプリでは、誰がどの操作をできるかはコードとロール定義で静的に決まっていました。エージェントでは、どのツールをどの引数で呼ぶかをモデルがその場で決めます。
条件として、これは「モデルが暴走する」という話だけではありません。入力が外部から入ってくる限り、ツール呼び出しの内容は攻撃者に誘導されうる、という構造的な問題です。関連する攻撃面はプロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイドで扱っています。
例外的に、完全に閉じた環境で読み取り専用のツールしか持たせないなら、権限設計の負荷は小さくなります。問題になるのは書き込み・送信・課金・削除が絡むときです。
従来のアプリ権限との3つの違い
実行主体が動的に決まる。ロールは事前に決められても、引数は実行時にしか確定しない
委任が多段になる。ユーザー → エージェント → ツール → 外部API、と権限が渡っていく。途中で誰の権限で動いているかが曖昧になりやすい
失敗が静かに起きる。エージェントは意図と違う操作をしても、それらしい完了報告を返すことがある
3点目が実務では厄介です。エラーとして明示されないため、監査ログや実行ログを確認するまで発見が遅れやすくなります。実行結果の検証やアラートを設計していれば気づけますが、そこまで作り込んでいない環境では見落としが残ります。
OWASP LLM06:2025「Excessive Agency」が示す3つの根本原因
OWASPは、LLMアプリの主要リスクとして LLM06:2025 Excessive Agency を定義しています。根本原因は次の3つです。
原因 | 内容 | 典型例 |
|---|---|---|
過剰な機能（Excessive Functionality） | 必要のないツール・関数まで持たせている | 要約目的なのにメール削除APIも叩ける |
過剰な権限（Excessive Permissions） | ツールが持つ認証情報の権限が広すぎる | 読み取り用途なのに書き込み可のトークンを使っている |
過剰な自律性（Excessive Autonomy） | 影響の大きい操作を人間の確認なしで実行できる | 承認なしで送金・外部送信ができる |
公式ドキュメントでは、メール要約の拡張機能を例に「読み取り権限のみで足り、削除や送信の機能を含むべきではない」と説明されています。素朴ですが、実装では高頻度で破られます。
なお項番には注意が必要です。Excessive Agency は2023年版では LLM08 でしたが、OWASP Top 10 for LLM Applications 2025 では LLM06:2025 に再編されており、LLM08:2025 は別のリスク（Vector and Embedding Weaknesses）を指します。解説記事の項番がずれているケースは珍しくないので、原典で確認してください。Webアプリ側の Top 10 と混同しやすい点はOWASP Top 10とは｜Webアプリの主要リスク10カテゴリ解説で整理しています。
エージェント特有の脅威については、OWASPが別途 Agentic AI – Threats and Mitigations（2025年2月17日公開）をまとめています。
ミニFAQ：ガードレールを入れれば権限設計は不要ですか？
役割が違います。ガードレールは「何を言わせないか」の出力制御、権限設計は「何をさせてよいか」の操作制御です。出力フィルタを通っても、ツール実行の権限が広ければ被害は止まりません。出力側の制御はLLMのガードレールとは｜出力制御の実装パターンとツール選定を参照してください。
最小権限をエージェントに落とし込む｜スコープ設計の考え方
最小権限は原則としては誰も反対しませんが、エージェントに適用すると「どの粒度で切るか」で必ず迷います。結論としては、ツール単位では粗すぎるので、リソース単位と条件単位まで降ろすのが実務解です。
ツール単位・リソース単位・条件単位のどこで切るか
粒度 | 切り方 | 向く場面 | 弱点 |
|---|---|---|---|
ツール単位 | 「請求書検索ツールは許可、請求書更新ツールは不許可」 | 初期設計・PoC | 1ツールの中で読み書きが混ざると意味をなさない |
リソース単位 | 「自社テナントの請求書のみ参照可」 | マルチテナントSaaS | スコープの受け渡し実装が必要 |
条件単位 | 「10万円未満の更新のみ自動、以上は承認」 | 金額・件数・時間帯に閾値がある業務 | 閾値の根拠を業務側と握る必要がある |
実装の順序としては、まずツールを読み取り専用と書き込み系に分割します。ここを分けずに「操作ツール」として束ねると、以降の設計が全部崩れます。
スコープの表現にはOAuth 2.0のスコープがそのまま使えます。委任の仕組みを整理したい場合はOAuth 2.0とは｜認可の仕組み・4つのグラントとPKCEを解説が参考になります。
クラウドIAMの権限評価ルールを借りる
ゼロから権限モデルを考える必要はありません。AWS IAMの評価ロジックは、エージェント権限の設計にほぼそのまま写像できます。AWS公式のポリシー評価ロジックで定義されている考え方のうち、特に有用なのは次の2つです。
明示的なDenyは常にAllowに優先する。禁止リストを後から足しても、許可側の記述に埋もれない
権限境界（permissions boundary）との関係は和集合ではなく積集合。「エージェントに与えた権限」と「そのエージェントが代理するユーザーの権限」の両方を満たすものだけ実行可能、という設計にできる
2点目は委任設計の肝です。エージェントがユーザーより強い権限を持った瞬間、権限昇格の経路になります。
AWS IAMのセキュリティベストプラクティスでは、長期のアクセスキーではなく一時的な認証情報を使うこと、IAM Access Analyzer（100を超えるポリシーチェックを提供）で過剰な権限を検出することが推奨されています。アクセス履歴から実際に使われた権限だけを抽出してポリシーを絞る手法は、エージェントでも同じ手順が使えます。
読み取り専用から始める3段階の権限付与
いきなり自律実行させず、段階を踏みます。
第1段階：読み取り専用。ツール呼び出しのログだけ貯める。この期間に「実際にはどのツールが何回呼ばれたか」が分かる
第2段階：承認付き書き込み。書き込み系を解放するが、全件を人間の承認キューに流す。承認率と却下理由がデータになる
第3段階：条件付き自律。第2段階のログで「承認率がほぼ100%」だった操作だけ、閾値を切って自動化する
第2段階を飛ばすと、第3段階で切るべき閾値を決める根拠が手元にありません。順番に意味があります。
ミニFAQ：エージェントに専用のアカウントを作るべきですか？
作ったほうが追跡しやすくなります。人間と資格情報を共有すると、監査ログ上で「誰がやったのか」が永久に分からなくなります。ただしアカウントを分けるだけでは不十分で、そのアカウントが代理している実行ユーザーを別フィールドで記録する必要があります。
Human-in-the-loopとは｜どこに人間を挟むか
Human-in-the-loop（HITL）とは、AIの処理の途中に人間の判断を組み込む設計を指します。エージェント文脈では、ツール実行の直前に承認を挟む形が中心になります。
よく混同される3つの位置づけを整理しておきます。
用語 | 人間の関わり方 | エージェントでの例 |
|---|---|---|
Human-in-the-loop | 処理の途中で人間が判断し、その結果が処理に反映される | 送信前に承認ボタンを押す |
Human-on-the-loop | 人間は監視役。通常は介入せず、異常時に止める | ダッシュボードで実行を監視し、必要なら停止 |
Human-out-of-the-loop | 人間は介在しない | 完全自動のバッチ処理 |
全部をin-the-loopにすると運用が回らず、全部をout-of-the-loopにすると事故が止まりません。実務では操作ごとに使い分けます。
不可逆性と影響範囲で承認の要否を決める
承認を挟むかどうかは、次の2軸で機械的に判断できます。
影響が社内に閉じる | 影響が社外に及ぶ | |
|---|---|---|
取り消せる操作 | 自動実行でよい（例：社内メモの下書き作成） | ログを残して自動実行（例：下書き状態での外部文書作成） |
取り消せない操作 | 承認を挟む（例：本番データの削除） | 必ず承認を挟む（例：メール送信・決済・公開） |
判断に迷ったら「取り消せるか」を先に問います。影響範囲より不可逆性のほうが、事故時のダメージを決めます。
承認者に渡す選択肢は4つ用意する
承認・却下の二択だけでは現場が回りません。実装では次の4つを用意しておくと、差し戻しの往復が減ります。
承認：提案されたツール呼び出しをそのまま実行する
却下：実行せず、理由をエージェントに返す
引数の編集：引数を人間が直してから実行する（金額や宛先の軽微な誤りはこれで吸収できる）
フィードバック付き再試行：実行せず、方針だけ伝えて再提案させる
引数の編集を用意していない実装は多いのですが、実際の却下理由の相当数は「やろうとしていることは正しいが引数が惜しい」です。
承認キューの設計｜ここで事故が起きる
承認を挟む設計そのものは難しくありません。本番で落ちるのは、承認が返ってこなかったときです。この節が本記事の中心になります。
待ち続けたときの既定挙動を先に決める
承認待ちは必ず滞留します。設計時に決めておくべき項目は次のとおりです。
項目 | 決めること | 推奨の置き方 |
|---|---|---|
タイムアウト | 何分・何時間待つか | 業務のSLAから逆算する。営業時間内と夜間で別の値を持つ |
タイムアウト時の挙動 | 既定で実行するか、しないか | fail closed（既定で拒否）にする |
エスカレーション | 一次承認者が不在のときの転送先 | 承認者を個人ではなくロール（グループ）に紐づける |
通知チャネル | どこに承認依頼を出すか | 既存の業務チャネルに寄せる。専用画面を作ると見られない |
再提案の上限 | 却下後に何回まで作り直させるか | 回数上限を設け、超過したら人間にハンドオフ |
fail closedを推奨する理由は単純で、取り消せない操作に承認を挟んでいる以上、「返事がないから実行する」は設計の前提を裏切るからです。OpenAI Agents SDKでも、承認ルールを関数で書く場合に引数を安全に検査できなければ拒否側に倒す、という方針が公式ドキュメントで示されています。
承認者をロールに紐づける話は、ゼロトラストとは｜境界型との違い・主要技術・案件動向を解説で扱う考え方と地続きです。
再開時の二重実行を防ぐ
ここが最大の落とし穴です。承認待ちで中断したワークフローを再開するとき、中断前の処理が再び走る実装があるという点を知らないと、副作用が二重に発生します。
LangGraphの interrupts のドキュメントには、再開時にノードが先頭から再実行されるため、interrupt を呼ぶ前に書いたコードはもう一度実行される、と明記されています。つまり、interrupt の前に「在庫を1つ減らす」ような副作用を置くと、承認のたびに在庫が二重に減ります。
対策は3つです。
interrupt の前に副作用を置かない。承認ゲートはノードの先頭近くに寄せる
冪等キーを持たせる。ツール呼び出しごとにIDを発行し、同じIDの実行は2回目以降をスキップする
チェックポイントを永続化する。インメモリのチェックポインタは本番で使わない。プロセスが落ちたら承認待ちが消える
LangGraphの基本構造はLangGraphとは｜LangChainとの違い・エージェント構築の基本にまとめています。
監査ログに何を残すか
承認フローを入れても、ログが足りないと事後の調査ができません。最低限、次を残します。
実行を提案したエージェントのID、およびそれが代理している実行ユーザーのID（この2つは必ず別フィールドにする）
呼び出されたツール名と、実際に渡された引数の全量
承認者・承認日時・判断（承認／却下／編集）と、編集された場合は編集前後の差分
ツールの実行結果（成功・失敗、エラー内容）
紐づく会話・スレッドのID
プロンプトとモデルの出力だけを残しているケースをよく見かけますが、監査で問われるのはツールに渡った引数です。ログ基盤側の設計はNew Relicとは｜オブザーバビリティの基本・Datadogとの違い・案件動向が参考になります。
ミニFAQ：承認ログの保持期間はどう決めますか？
業界規制と契約から逆算します。一般論の数字を持ち込むより、その顧客が既存システムで採用している保持期間に合わせるのが安全です。金融・医療など規制業種では既に社内規程があるため、要件定義でヒアリングしてください。
フレームワーク別の実装の入り口
OpenAI Agents SDK
ツール定義に needs_approval を指定すると、そのツールは承認待ちになります。真偽値だけでなく関数も渡せるため、「金額が閾値を超えるときだけ承認」といった条件付きの制御が書けます。
承認待ちは実行結果の interruptions として表面化し、実行状態をJSONにシリアライズして永続化できます。承認・却下を記録してから再開する流れです。詳細はHuman-in-the-loop の公式ドキュメントにあります。SDK全体の立ち位置はOpenAI Agents SDKとは｜使い方とLangGraphとの違いを参照してください。
LangGraph
interrupt を呼ぶとグラフの実行が停止し、状態が永続化レイヤに保存されます。再開は Command に resume を渡す形です。前述のとおりチェックポインタが必須で、ノードの再実行仕様に注意が必要です。
Claudeのツール使用とMCP
Claudeのツール使用では、モデルがツールを呼びたいときに停止理由が tool_use になって返り、実際に実行するのはアプリケーション側です。公式のtool useドキュメントにあるとおり、結果を返すまでモデルは待ちます。この「アプリ側が実行する」構造自体が、承認ゲートを差し込む場所になります。
MCPを使う場合は仕様側にも要件があります。MCP仕様（2025-06-18版）では、ホストはツールを呼び出す前にユーザーの明示的な同意を得なければならない、と定められています。あわせて、ツールの説明（annotations）は信頼できるサーバー由来でない限り信頼すべきでないとも書かれています。ツールの説明文自体が攻撃面になる、という指摘です。MCPの全体像はModel Context Protocolとは｜MCPの仕組み・活用事例をエンジニア視点で解説にまとめています。
フレームワークに乗らない場合
自前実装でも構造は同じです。ツール実行の直前に1つの関数を挟み、そこで「自動実行してよいか」を判定して、必要なら承認レコードを作って処理を止めます。重要なのはフレームワークの選択ではなく、ツール実行の経路を1本に絞ることです。経路が複数あると、どこかが承認を迂回します。
OpenAIの function calling のドキュメントでも、モデルが返すのは呼び出しの提案であって実行は開発者側の責務、という整理になっています。承認はアプリ層の仕事だ、と考えて設計してください。
承認を挟むコストとレイテンシ
ここは競合記事でもあまり触れられませんが、見積もり時に効いてきます。
レイテンシ。承認を挟んだ瞬間、その処理の完了時間は「人間が気づくまでの時間」に支配されます。数秒だった処理が数時間になる、という桁の変化です。したがって、ユーザーが同期的に待つ画面で承認を挟む設計は成立しません。非同期前提に組み替える必要があります。
トークンコスト。ツール定義をモデルに渡すと、ツール利用のためのシステムプロンプトが自動で加算されます。モデルごとの加算トークン数はAnthropicの公式ドキュメントに一覧で掲載されています。ツールを闇雲に増やすと、呼ばれなくても毎回課金される点は意識しておくべきです。却下後の再提案も、そのたびに推論が1回走ります。
運用コスト。承認件数がそのまま人件費です。第2段階（全件承認）を恒久運用にすると、自動化のメリットが消えます。だからこそ第3段階への移行基準を先に決めておきます。
コスト全般の最適化はLLMコスト最適化案件の単価相場｜トークン削減・推論設計のフリーランス実務でも扱っています。
よくある失敗と対策
開発用の広い権限のまま本番に出す
PoCでは管理者権限のトークンで通してしまいがちです。本番移行時に絞ろうとすると、どの権限が実際に必要か分からず、結局そのまま出る。対策は第1段階の読み取り専用期間でログを取り、使われた権限だけを残すことです。
承認が形骸化する
承認依頼が1日に数百件来ると、人間は中身を見ずに承認します。承認率が100%に張り付いたら、それは安全ではなく承認が機能していない信号です。閾値を見直して件数を減らすか、その操作を自動化側に倒してください。
ツールの説明文を信頼してしまう
外部のMCPサーバーを繋ぐ場合、ツールの説明文は相手が書いたものです。説明に悪意ある指示が仕込まれる経路があります。信頼できないサーバーのツールは、説明文を鵜呑みにせず許可リストで管理します。
監査ログにツール引数が残っていない
障害調査で「何が実行されたか」を追えません。プロンプトと応答だけでは足りず、引数と実行結果が必要です。設計段階でログスキーマを決めてください。
エージェント同士の委任で権限が増幅する
複数エージェントを連携させると、サブエージェントが親より広い権限で動くことがあります。委任のたびに権限は狭まる方向にしか動かない、という制約をコードで強制します。構成の考え方はマルチエージェントとは｜設計パターン5つと単一エージェントの違いを参照してください。
権限設計チェックリスト
受託で入るときに、そのまま要件定義のヒアリング項目として使える形にしました。
権限の棚卸し
[ ] ツールを読み取り系と書き込み系に分割したか
[ ] 各ツールが使う認証情報の権限は、そのツールの用途に一致しているか
[ ] エージェント専用のアカウント・資格情報を分離したか
[ ] エージェントの権限が、代理する実行ユーザーの権限を超えないことをコードで保証しているか
[ ] 長期のアクセスキーではなく、短命のトークンを使っているか
承認フロー
[ ] 承認が必要な操作を「不可逆性 × 影響範囲」で選別したか
[ ] タイムアウト値と、タイムアウト時の既定挙動（fail closed）を決めたか
[ ] 承認者をロールに紐づけ、不在時のエスカレーション先を定義したか
[ ] 承認・却下・引数編集・再提案の4つの選択肢を用意したか
[ ] 再提案の回数上限と、超過時のハンドオフ先を決めたか
再開と冪等性
[ ] 中断前の副作用が再実行されない構造になっているか
[ ] ツール呼び出しに冪等キーを持たせたか
[ ] チェックポイントを永続ストレージに保存しているか
監査と運用
[ ] エージェントIDと実行ユーザーIDを別フィールドで記録しているか
[ ] ツール名・引数全量・実行結果をログに残しているか
[ ] 承認率をモニタリングし、形骸化を検知できるか
[ ] 緊急時に全ツール実行を止めるスイッチがあるか
契約・体制
[ ] 誤実行時の責任分界点を文書化したか
[ ] 権限設計・承認フローの工数を見積もりに積んだか
[ ] 顧客側の既存IdPと監査要件をヒアリングしたか
最後の「契約・体制」を要件定義で握っておくと、後工程の揉め事がかなり減ります。
フリーランス案件で権限設計はどう効くか
エージェント開発の案件では、モデル選定やプロンプト設計よりも、本番導入の手前で止まっている現場のほうが多いのが実情です。止まる理由は精度ではなく、情シスやセキュリティ部門の承認が下りないこと。ここを設計として言語化できる人は、要件定義フェーズから入りやすくなります。
案件の全体像や求められるスキルはAIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説に、規制対応寄りの関わり方はAIガバナンス案件のフリーランス実務｜規制対応と単価相場【2026】にまとめています。ガバナンス側の枠組みとしては、NIST AI Risk Management Framework（バージョン1.0、2023年1月26日公開。GOVERN / MAP / MEASURE / MANAGE の4機能で構成）や、Googleの Secure AI Framework が参照されることがあります。
自分の経験がどの程度の単価レンジに対応するかを把握しておきたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。AI関連の公開案件はフリコンの案件一覧からも探せます。
まとめ
AIエージェントの権限設計は、ツールを読み取りと書き込みに割ってリソース単位まで絞り、取り消せない操作にだけ承認を挟む。この2つを押さえると、過剰権限と誤実行に起因するリスクはかなり下げられます。ただし入力経路の対策や監査ログの設計まで含めて初めて機能するため、権限設計だけで完結するものではありません。
要点を整理します。
過剰な権限はOWASPが LLM06:2025 Excessive Agency として整理しており、原因は機能・権限・自律性の3つの過剰にある
最小権限はツール単位では粗い。リソース単位・条件単位まで降ろし、クラウドIAMの評価ルール（明示的Deny優先・権限境界との積集合）を写像する
権限付与は読み取り専用 → 承認付き書き込み → 条件付き自律の3段階で進める。中間段階のログが閾値設計の根拠になる
承認フローの事故はタイムアウト・エスカレーション・再開時の二重実行で起きる。fail closedと冪等キーを先に決める
監査ログにはエージェントIDと実行ユーザーIDを分けて記録し、ツールに渡った引数の全量を残す
受託では、誤実行時の責任分界点を要件定義で文書化しておく
次のステップとしては、手元のエージェントのツール定義を開き、読み取りと書き込みが混ざっているツールを探すところから始めてください。そこが最初に直す場所です。
なお、本記事の項番・仕様名・APIの挙動は執筆時点（2026年10月）に各公式ドキュメントで確認できた内容です。この領域は更新が早いため、実装時は必ず下記の公式ドキュメントで最新版を確認してください。
参照した一次情報は以下のとおりです。
よくある質問
権限設計はいつ着手すべきですか？
PoCの終盤ではなく、ツール定義を書き始める時点です。ツールの粒度そのものが権限設計の一部だからです。後から絞ろうとすると、1ツールの中で読み書きが混ざっていて分割から始めることになります。
社内利用だけなら承認フローは不要ですか？
不可逆な操作があるなら必要です。社外への影響がなくても、本番データの削除や設定変更は取り消せません。影響範囲より不可逆性で判断してください。
承認は誰が担当すべきですか？
その操作の業務責任を持つ人です。エンジニアが承認者になると、業務的な妥当性（この宛先で合っているか、この金額で合っているか）を判断できません。技術的な安全性はコード側で担保し、承認者には業務判断だけを任せる分担が機能しやすいです。
RBACとABACのどちらで設計すべきですか？
ロールが少なく操作が定型的ならRBACで足ります。金額・時間帯・データの属性で可否が変わるならABAC寄りにします。両方を混ぜる設計も一般的で、ロールでベースを決めて属性で絞り込む形がよく使われます。
MCPサーバーを自作する場合、権限はどこで制御しますか？
MCPサーバー側とホスト側の両方です。サーバー側で提供するツールの権限を絞り、ホスト側で呼び出し前の同意を取ります。片方だけでは、別のホストから繋がれたときに制御が効きません。実装手順はMCPサーバーの作り方｜自作の実装手順とMCP開発案件の単価にあります。
ブラウザを操作するエージェントの権限はどう絞りますか？
ツール単位の制御が効きにくいため、実行環境ごと隔離する方向になります。専用の仮想環境に閉じ込め、アクセスできるドメインとアカウントを限定するアプローチです。詳細はComputer Useとは｜AIエージェントのブラウザ操作と使いどころで扱っています。
承認待ちの間、エージェントの状態はどこに保存しますか？
永続ストレージです。インメモリだとプロセス再起動で承認待ちが消え、ユーザーから見ると処理が無言で失われます。承認までの待ち時間は時間単位になりうるため、リクエストのライフサイクルとは切り離して保存します。
承認率が高いのに自動化に踏み切れません
承認率だけでなく、却下された案件の内訳を見てください。却下が特定の条件に偏っているなら、その条件を閾値として切り出せば残りは自動化できます。却下理由がばらけている場合は、まだ自動化の時期ではありません。
エージェントが権限エラーで止まったら、どう扱うべきですか？
エラー内容をそのままモデルに返すのが基本ですが、権限エラーの詳細（どのリソースが存在するか等）が情報漏洩になる場合があります。モデルに返すメッセージは「権限がないため実行できません」程度に抽象化し、詳細はログ側にだけ残す分け方が安全です。
複数の顧客テナントを跨ぐエージェントの設計で注意する点は？
テナント識別子をモデルに決めさせないことです。会話の文脈から推論させると、プロンプト経由で他テナントを指定される余地が残ります。テナントはセッション開始時にアプリ側で固定し、ツール実行時に強制的に上書きしてください。
権限設計の工数はどのくらい見ておくべきですか？
対象システムの数と既存IdPの有無で大きく変わるため、一律の目安は置きにくいのが実情です。ただし、ツール分割・承認フロー・監査ログの3つは独立した作業として見積もりに立てておくと、後から「追加作業ですか」という議論になりにくくなります。
ガードレールと権限設計、先に入れるべきなのはどちらですか？
書き込み系のツールを持たせるなら権限設計が先です。出力の品質問題は不快ですが取り消せます。誤ったツール実行は取り消せません。
