Business

AIエージェント承認フロー設計ガイド - tool実行・MCP・外部操作をどこで止めるか

nidoneko · · 13 min read
AIエージェントAIガバナンスMCPセキュリティAIワークフロー設計
🛂

AIエージェントを組織で使い始めると、「全部聞かれると遅いが、全部自動許可は怖い」という問題にすぐ当たります。特に Claude Code、Codex、MCP server、Agents SDK のように tool を呼び、ファイルを書き、外部サービスへ到達できる仕組みでは、承認ダイアログを出すだけでは統制になりません。

この記事では、AIエージェントの 承認フロー設計 に絞って整理します。社内ルール全体は AIコーディングツールの社内ガイドライン、実行後に何を残すかは AIエージェント監査ログ設計ガイド、本番投入前の評価は AIエージェント評価設計ガイド、Codex の差分受け入れは Codex レビュー完了ゲート設計ガイド に分けています。

先に結論: 承認は「操作の直前」に置く

承認フローで一番やってはいけないのは、最初に大きな許可を与えることです。

このリポジトリの修正をお願いします。必要な操作は全部許可します。

これは速いですが、承認としては弱いです。AIエージェントは途中で調査対象を広げたり、外部情報に引っ張られたり、別の tool を使った方が早いと判断したりします。最初の一括許可では、その時点ごとのリスクを見られません。

私なら、承認を次の4段階に分けます。

レベル操作承認方針
Readファイル閲覧、ログ確認、公開docs参照原則自動許可
Draftpatch作成、PR本文案、設定案sandbox内なら自動許可
Writecommit、PRコメント、MCP write、依存追加条件付き承認
External actiondeploy、課金、顧客通知、token発行、削除毎回人間承認

ポイントは、「AIを止めるかどうか」ではありません。どの操作は自動で進めてよく、どの操作は人間の責任に戻すかを決めることです。

承認疲れを設計で避ける

承認を増やせば安全になる、という考えは雑です。細かい確認が多すぎると、承認者は内容を見なくなります。実務では、毎回 Approve を押す運用は長続きしません。

Claude Code は標準で read-only に近い保守的な権限から始まり、編集や実行には明示的な許可を求めます。一方で、許可ルールを雑に広げると、確認ダイアログを減らす代わりにリスクの見落としが増えます。OpenAI Agents SDK でも human-in-the-loop は sensitive tool call の直前で run を一時停止し、approve / reject 後に同じ state から再開する形です。

つまり、承認フローは「全部聞く」でも「全部任せる」でもなく、次のように設計します。

  1. よくある低リスク操作は自動許可する
  2. 高リスク操作は tool call 単位で止める
  3. 却下時は安全な代替案へ戻す
  4. 同じ run 内の一時的な許可と、組織全体の恒久許可を分ける
  5. 承認理由と却下理由を監査ログへ残す

承認対象は tool 名ではなく「影響」で決める

Bash を許可するか、MCP を許可するか、という粒度だけでは粗すぎます。同じ tool でも影響は違います。

たとえば Bash(pnpm run build) は検証ですが、Bash(npm publish) は外部公開です。mcp__github__get_pull_request は read ですが、mcp__github__merge_pull_request は本番に近い write です。WebFetch も、公開docsを読むのと、社内URLへアクセスするのでは扱いが違います。

承認対象は、少なくとも次の軸で切ります。

軸低リスク高リスク
対象sandbox、feature branchmain、本番、顧客データ
方向read、dry-runwrite、delete、send
可逆性patch破棄で戻せるrollbackや通知が必要
外部性local検証外部API、MCP write、deploy
機密性公開情報secret、個人情報、未公開コード

この表で高リスク側に入る操作は、tool 名に関係なく承認へ戻します。

最小の承認マトリクス

最初から複雑なワークフローエンジンを作る必要はありません。小さく始めるなら、次のマトリクスで十分です。

操作例承認者有効期限
local readgit status, cat, test log確認不要run内
local writepatch作成、Markdown追加依頼者run内
dependency changepackage追加、lockfile更新repo ownerPR単位
MCP readGitHub issue取得、docs検索不要または依頼者run内
MCP writeissueコメント、label変更、PR作成repo owner操作ごと
external sendSlack通知、email送信、顧客向け投稿業務owner操作ごと
deploy / destructivedeploy、DB migration、削除変更責任者 + reviewer操作ごと

ここで大事なのは、承認者を「近くにいる人」にしないことです。AIエージェントの作業を依頼した人と、外部影響を承認する人は分けた方がよい場合があります。特に deploy、顧客通知、権限変更、token発行は、依頼者本人のセルフ承認だけでは弱いです。

承認リクエストに入れる項目

承認者が見るべき情報が足りなければ、承認は形だけになります。AIエージェントから人間へ戻すときは、最低限この形にします。

approval_request:
  agent_run_id: 20260620-support-fix-04
  requested_action: mcp.github.create_pr
  target: repo:nidoneko/HP
  risk_level: write
  reason: 記事追加の差分をPR化するため
  diff_or_payload_summary: 1 new markdown file, keyword-plan update, llms update
  alternatives_checked:
    - local draft only
    - manual PR creation
  expiry: this run only

この程度の情報がなければ、承認者は「何を許可するのか」を判断できません。

逆に、承認リクエストへ raw prompt や secret をそのまま載せる必要はありません。監査ログと同じで、通常の承認画面には要約を出し、必要な raw payload はアクセス制限された場所へ分けます。

却下時の戻り方を決める

承認フローは approve だけでなく reject が重要です。却下されたときに AIエージェントが同じ操作を言い換えて再申請し続けるなら、承認フローは壊れています。

却下時は、次のどれかに落とします。

却下理由戻し方
情報不足追加調査だけ許可する
権限不足権限を下げた代替案を出させる
scope逸脱元の依頼範囲へ戻す
外部影響が大きいhuman ownerへhandoffする
危険操作の反復runを停止する

Anthropic の auto mode の説明でも、危険と判定された操作は単に止めるだけでなく、より安全な経路へ戻す考え方が示されています。これは承認フローにもそのまま使えます。却下は「失敗」ではなく、AIエージェントに境界を再認識させる signal として扱います。

長時間承認は state と version を持たせる

承認が数分で返るとは限りません。夜間 automation、セキュリティレビュー、顧客影響のある操作では、承認待ちが数時間から数日になることがあります。

OpenAI Agents SDK の human-in-the-loop は、pending work を durable な RunState として保存し、あとで復元する設計を持っています。実務でも同じで、承認待ちをただのチャット通知にしない方がよいです。

長時間承認には次を持たせます。

  • agent_run_id
  • tool名と引数の要約
  • requester
  • approver候補
  • policy version
  • agent / prompt / tool definition version
  • 作業branchまたはsandbox snapshot
  • expiry
  • reject時の戻り先

特に policy version と tool definition version は軽視されがちです。承認待ちの間に MCP server や agent prompt が変わると、承認者が見た内容と実行内容がずれる可能性があります。数日寝かせる承認は、再開前に version を再検証します。

MCP write は個別承認に寄せる

MCP は便利ですが、承認フローでは慎重に扱います。MCP server は GitHub、Slack、Notion、database、browser、社内SaaSなどへ接続できるため、read と write の差が大きいからです。

私なら、MCP は次のように分けます。

MCP操作方針
public docs read自動許可しやすい
repo readrepo単位で許可
issue / PR comment操作ごとに承認
label / status変更操作ごとに承認
secret / member / billing原則禁止または管理者承認
database write本番は禁止、stagingも操作ごと

MCP server 自体を allowlist に入れても、全 tool を同じ扱いにしない方が安全です。Claude Code の permissions でも MCP tool を pattern で絞る考え方があり、OpenAI Agents SDK でも MCP tool call を approval 対象にできます。server単位の信頼と、tool単位の承認は分けて考えます。

承認フローをAGENTS.mdに固定する

AIエージェント運用では、承認ルールを口頭で伝えると揺れます。repo内で回すなら、AGENTS.md に最小ルールを置きます。

## AI agent approval rules

- Read-only inspection and local build commands may proceed without approval.
- Dependency changes, MCP write operations, deploys, token changes, and external notifications require explicit approval.
- Approval requests must include target, risk level, reason, payload summary, alternatives checked, and expiry.
- Rejected actions must not be retried by changing wording; propose a lower-risk alternative or stop.
- Never approve actions that touch secrets, billing, production data, or customer notifications without the responsible owner.

これを置くと、Claude Code、Codex、社内 agent、手動運用の判断が揃います。細かい tool 設定は製品ごとに違っても、承認思想を repo に残せます。

承認ログは監査ログとつなぐ

承認は、その場の安全確認だけではありません。あとから説明するための証跡でもあります。

承認ログには次を残します。

  • approval_id
  • agent_run_id
  • requested action
  • approver
  • approved / rejected
  • reason
  • expiry
  • policy version
  • linked PR / issue / deployment

承認ログだけを独立させると、後から使いにくいです。tool実行ログ、PR、CI、MCP server log と agent_run_id でつなぎます。何を残すかの全体設計は監査ログ側の仕事ですが、承認フロー側でも ID を渡す前提にしておく必要があります。

小さく始める導入手順

最初の導入は、この順番が現実的です。

  1. AIエージェントが触ってよい repo / workspace を限定する
  2. read / draft / write / external action の4分類を作る
  3. MCP write、依存追加、deploy、外部通知だけを承認対象にする
  4. 承認リクエストのテンプレートを固定する
  5. agent_run_id をPR本文や作業ログに入れる
  6. 却下時の戻り方を決める
  7. 1か月後に、承認が多すぎる操作と少なすぎる操作を棚卸しする

最初から完璧な承認システムを作るより、危険な外部操作だけを確実に止める方が価値があります。承認疲れが出たら、承認数を減らすのではなく、低リスク操作を明示的に自動許可し、高リスク操作の情報量を増やします。

参考にした一次情報

まとめ

AIエージェントの承認フローは、作業を遅くするための儀式ではありません。人間が責任を持つべき操作だけを、ちょうどよい粒度で人間へ戻すための設計です。

実務では、read と draft はできるだけ滑らかに流し、write と external action で止めます。承認リクエストには target、risk、reason、payload summary、expiry を入れます。却下されたら同じ操作を再申請させず、低リスクな代替案へ戻します。

この線引きができると、Claude Code、Codex、MCP、Agents SDK のような強い tool を、単なる「怖い自動化」ではなく、説明可能な業務フローとして組織に入れやすくなります。

WRITTEN BY nidoneko

Full-stack engineer with 8+ years of experience in TypeScript, React, Node.js, and cloud-native development across healthcare, finance, HR, and IoT domains.

View Profile →
// Related articles View All
🧩
OpenClaw

OpenClaw multi-agent routing 設計ガイド - agentId・accountId・binding を分ける

·15 min read

OpenClaw の multi-agent routing を、agentId、accountId、binding、workspace、agentDir、session store、per-agent sandbox / tool policy の境界で整理します。複数チャネルや複数personaを安全に分けるための実務ガイドです。

Read More →
⚙️
Codex

Codex config profile 設計ガイド - sandbox・approval・MCPを作業別に切り替える

·13 min read

Codex の config.toml と profile を、調査・通常実装・PRレビュー・自動化でどう分けるかを整理します。sandbox、approval、permissions profile、MCP、project config の境界を実務目線で設計します。

Read More →
🧭
Codex

Codex auto-review ガイド - approvals_reviewer・auto_review・codex auto approval の境界

·16 min read

Codex auto-review / codex approvals_reviewer / approvals_reviewer = `auto_review` / codex autoreview を調べている方向けに、auto_review が承認を消す機能ではなく reviewer 差し替えであること、approval request の発火条件、denial、circuit breaker、/approve 境界を整理します。

Read More →