結論：autoを許可設定ではなく、server評価の監督ルールとして使う
Claude Managed Agentsのpermission policyに追加されたautoは、全操作を無条件に実行するスイッチではありません。serverが各agentまたはMCP tool callを評価し、実行する、拒否する、承認待ちにする、という結果へ振り分けます。導入時は低リスクの読み取りから始め、書き込み・外部送信・秘密情報に触れる操作は承認または拒否へ寄せます。
まず業務を「自動で進めてよい」「必ず止める」「条件を満たした時だけ人が確認する」に分類してください。公式更新ではagent.tool_useとagent.mcp_tool_useのeventにevaluationとevaluated_permissionが出ます。つまり結果を画面で見ただけで終わらせず、何を評価し、誰が介入したかを監査できる形にすることが導入の完了条件です。
根拠はClaude Platform公式release notesとManaged Agents公式permission policiesです。これはClaude Codeのpermission modeをそのまま移す記事ではなく、Managed Agentsのserver側評価と企業の確認責任を決める実務ガイドです。
always_ask・auto・denyを比較する
| 方針 | 向く操作 | 残すべき確認 |
|---|---|---|
| auto | 定義済み環境の低リスクtool call | evaluationとevent、例外時の承認 |
| always_ask | 外部送信、公開、重要データ更新 | 承認者、理由、対象resource |
| deny | 禁止された秘密情報取得や破壊操作 | 拒否理由、再申請経路、停止記録 |
autoを採用するかどうかは、agentの目的だけでなくtool callの結果で決めます。同じagentでも、社内文書を読む操作と顧客へ送信する操作では影響が違います。MCPも同様に、検索だけのserverと書き込み可能なserverを一つの許可グループへ入れません。評価結果が実行になった時も、リスクが消えたのではなく、serverがその時点のpolicyで判断した事実が増えたと考えます。
evaluationとevaluated_permissionを証跡にする
公式更新は、agentのtool利用とMCP tool利用を別のevent種類として示しています。運用台帳にはsession ID、agent version、environment、tool名、引数の分類、評価結果、実行結果、承認者、時刻を持たせます。引数そのものに個人情報や秘密が含まれる場合は、原文を広く複製せず、マスキング済みの要約と参照可能な保管先を記録します。
評価と実行結果は同じではありません。serverが実行を選んでも、toolが失敗することがあります。反対に拒否されたcallにも、なぜ拒否されたかを追跡できる理由が必要です。集計では「auto率」だけをKPIにせず、承認待ちの滞留時間、拒否の再申請率、policy変更後の例外数、秘密情報検知数を並べます。数字が改善しても、危険な操作を測定対象から外していれば安全になったとは言えません。
導入手順：小さなscopeからautoを検証する8ステップ
- 公式のpermission policiesとrelease notesをreadbackし、Managed Agentsの対象workspace、agent、environmentを記録します。
- 業務を読み取り、内部更新、外部送信、公開、削除の5種類へ分解し、データ分類と影響範囲を付けます。
- 各toolとMCP serverについて、入力、出力、書き込み先、認証主体、失敗時の再試行を台帳へ登録します。
- 読み取り専用のfixtureを作り、
autoでserver評価、eventのevaluation、evaluated_permissionを確認します。 - 外部送信と破壊操作は
always_askまたはdenyにし、承認者が不在の時の停止状態をテストします。 - 同じtaskを複数回実行し、評価結果だけでなくtoolの成否、retry、所要時間、監査記録の欠落を比較します。
- policyのrevision、agent version、environment変更を紐付け、例外申請とrollback担当を決めます。
- 一週間の実測後に、autoの範囲を維持・縮小・拡大のどれにするかを人間が判断し、承認記録を残します。
判断を急ぐ場合でも、最初から全MCPをautoにしないでください。低リスクのfixtureが通った後に、内部更新を一つだけ追加します。変更は一度に一項目に限定し、評価結果が変わった理由を説明できるようにします。承認待ちの処理を誰も見ない構成では、autoの技術的な成立より業務の停止リスクが大きくなるため、当番とSLAも先に決めます。
既存のManaged Agentsの予算上限は金額と停止を扱い、Web到達先制限はネットワーク境界を扱います。今回のauto policyは操作ごとのserver評価です。さらに企業利用のセキュリティ確認と接続し、データ分類・権限・証跡・停止条件を同じ導入表へまとめてください。
特に承認待ちの扱いは、policyの設定だけでは完結しません。勤務時間外に停止したsessionを翌営業日に誰が再開するか、拒否されたtool callをagentが繰り返す場合に何回で打ち切るか、eventの欠落をどこへ通知するかを決めます。autoの適用範囲を広げる判断は、成功率だけでなく、例外を人が処理できる体制と一緒に行ってください。
チェックリスト：autoを本番へ広げる前に
□公式versionとpolicyの対象を記録した □agentとMCPを分けた □read・write・送信・削除を分類した □autoの理由を一文で説明できる □evaluationとevaluated_permissionを保存した □承認者と不在時の停止を決めた □秘密情報の記録方法を決めた □retryとtool失敗を測った □policy revisionとrollbackを管理した □一週間の見直し日を置いた。
よくある質問
autoは全てのtool callを許可しますか？
いいえ。serverがcallを評価して、実行、拒否、承認待ちに振り分けます。操作のリスク分類とpolicyの対象範囲を確認してください。
evaluationは何を残しますか？
公式更新ではagent.tool_useとagent.mcp_tool_useに評価情報が報告されます。組織ではsession、version、承認者、結果を追加して追跡可能にします。
autoにすれば人間確認は不要ですか？
不要にはなりません。serverが判断できない操作や高リスク操作は止め、承認・拒否・再申請の責任を残します。
公式情報と無料診断
autoの追加とevent名は公式release notes、policyの考え方は公式permission policiesを公開直前にreadbackしました。Miraigentの無料診断では、tool境界、承認責任、監査項目、停止条件を業務別に整理します。