Business

AIエージェント tool risk tier 設計ガイド - 自動許可・承認・禁止を分類表で決める

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

AIエージェントを組織で使い始めると、「どの tool を許可するか」を製品設定の話として扱いがちです。けれど実務で詰まるのは、Bash を許可するかどうかではありません。Bash(pnpm run build) は検証ですが、Bash(npm publish) は外部公開です。GitHub MCP でも、PR を読む操作と、issue にコメントする操作は同じリスクではありません。

この記事では、AIエージェントに渡す tool を risk tier に分け、自動許可・人間承認・禁止へ写像する設計を整理します。承認フローそのものは AIエージェント承認フロー設計ガイド、実行後の証跡は AIエージェント監査ログ設計ガイド、MCP server の台帳化は MCP サーバーカタログ設計ガイド、社内ルール全体は AIコーディングツールの社内ガイドライン に分けています。

先に結論: tool 名ではなく影響で分類する

tool risk tier は、tool の名前ではなく「失敗したときの影響」で決めます。

tier操作基本方針
T0 read公開docs、repo read、ログ閲覧原則自動許可
T1 inspecttest、typecheck、dry-run、差分確認sandbox / branch 内なら自動許可
T2 draftpatch作成、PR本文案、設定案自動可。ただし外部送信しない
T3 writefile write、commit、PR作成、MCP write条件付き承認
T4 external actiondeploy、削除、課金、通知、権限変更操作ごとに人間承認
T5 forbiddensecret閲覧、prod DB write、billing変更原則禁止

この表を作ると、承認疲れを減らせます。低リスク操作は止めずに進め、高リスク操作だけを人間へ戻せるからです。逆に tier がないと、全部を聞くか、全部を広く許可するかの二択になり、どちらも運用で崩れます。

既存記事との役割分担

このテーマは、既存のガバナンス記事と近いです。重複させないために責務を分けます。

近い記事扱うことこの記事で扱うこと
承認フローsensitive tool call をいつ止め、approve / reject 後にどう戻るかそもそもどの操作を sensitive と判定するか
監査ログ実行後に何を残し、どう検索可能にするか実行前に risk_tier をどう付けるか
評価設計本番前に wrong tool / scope excess を落とす evaleval の期待値になる tier 表
本番監視稼働中の tool error、approval wait、scope drift監視メトリクスに付与する分類
MCP server catalogserver / endpoint / owner / scope の台帳server 内の tool ごとの許可レベル

つまり、tool risk tier は承認や監査の前処理です。分類が曖昧なまま承認画面や監査ログを作っても、「なぜこの操作を止めたのか」を説明できません。

分類軸は5つに絞る

最初から細かい点数表を作る必要はありません。私はまず次の5軸で分類します。

軸低リスク高リスク
対象sandbox、feature branch、公開docsmain、本番、顧客データ、社内SaaS
方向read、list、dry-runwrite、delete、send、publish
可逆性patch破棄、branch削除で戻せるrollback、復旧、外部訂正が必要
外部性local実行、公開情報取得MCP write、API送信、通知、deploy
機密性公開情報、匿名化ログsecret、個人情報、未公開コード

この5軸のうち高リスク側が2つ以上入るなら、T3以上に上げます。外部送信、削除、権限変更、課金、production 変更は、他の条件に関係なく T4 以上です。secret や個人情報の直接閲覧は、原則 T5 として別ルートに逃がします。

具体例で分類する

同じ tool でも、引数と対象で tier は変わります。

tool calltier判断
git statusT0local read で可逆性の問題がない
pnpm run buildT1local検証。副作用は dist 生成程度
apply_patch で記事草稿を作るT2branch内の draft。PR化前なら外部影響がない
git commitT3履歴に残る write。branch限定なら条件付き承認
gh pr createT3GitHub への write。組織運用では承認対象
mcp.github.create_issue_commentT4外部サービスへ発言が残る
wrangler deployT4本番公開に近い外部 action
aws iam create-access-keyT5権限・secretを増やすため通常は禁止
psql prod -c "delete ..."T5production destructive write

ここで大事なのは、便利な tool を禁止することではありません。低リスクの使い道と高リスクの使い道を分けることです。Bash を全面禁止すると開発は進みませんが、Bash の中で publish、deploy、token、prod DB を別 tier に上げれば、速度と統制を両立できます。

MCP は server 単位で信頼しない

MCP では、server を allowlist に入れた瞬間に「その server の tool は安全」と見なしてしまいがちです。これは粗すぎます。

たとえば GitHub MCP server には、read-only の取得系 tool と、comment、label、merge、release に近い write tool が混ざります。社内検索 MCP でも、検索だけなら T0 に近いですが、document update や ticket creation があるなら T3 以上です。

MCP の catalog には、server だけでなく tool tier も持たせます。

server_id: github-mcp
owner: platform-team
auth_subject: user-oauth
default_scope: repo:read
tools:
  get_pull_request:
    tier: T0
    approval: auto
  list_workflow_runs:
    tier: T0
    approval: auto
  create_issue_comment:
    tier: T4
    approval: per_call
  add_label:
    tier: T3
    approval: per_run
  merge_pull_request:
    tier: T5
    approval: forbidden
review_cycle: 30d

MCP の security best practices でも、scope、token handling、human-in-the-loop、監査証跡は重要な論点です。実務では、scope を狭めるだけでなく、tool tier を catalog と承認フローへ渡す方が扱いやすくなります。

tier は policy として機械に渡す

分類表をドキュメントで終わらせると、運用で忘れます。最低限、policy として機械に渡せる形にします。

tool_policy:
  default: deny
  tiers:
    T0:
      approval: auto
      logging: summary
    T1:
      approval: auto
      constraints:
        - local_only
        - no_network_write
    T2:
      approval: auto
      constraints:
        - branch_or_sandbox_only
        - no_external_send
    T3:
      approval: human_per_run
      require:
        - diff_summary
        - rollback_plan
    T4:
      approval: human_per_call
      require:
        - target
        - payload_summary
        - business_owner
        - expiry
    T5:
      approval: forbidden

この policy は、Claude Code や Codex の設定そのものとは別に置きます。製品ごとの設定は変わっても、組織として「何を危険と見るか」は repo やチームの contract として残した方がよいからです。AGENTS.md には短い原則を置き、細かい tool map は docs/ai-agent-tool-policy.yml のような別ファイルにしても構いません。

承認リクエストには tier を入れる

人間承認へ戻すときは、なぜ承認が必要なのかを明示します。

approval_request:
  agent_run_id: 20260623-customer-docs-02
  requested_tool: mcp.github.create_issue_comment
  risk_tier: T4
  target: repo:nidoneko/HP issue:#123
  reason: external service にコメントとして残るため
  payload_summary: "検証結果と再現条件を issue に追記する"
  alternatives_checked:
    - local draft only
    - PR body に記載
  expiry: this_call_only

risk_tier が入ると、承認者は「この操作だけ例外なのか」「policy 自体を変えるべきなのか」を分けて判断できます。T4 の操作が毎日何十件も出るなら、承認を雑に広げる前に、作業設計か tool 分割を見直すべきです。

評価と監視にも同じ tier を使う

tool risk tier は、承認画面だけのために作るものではありません。eval と runtime monitoring にも同じ分類を使います。

eval では、次のような期待値を置けます。

case: pr-review-read-only
allowed_tiers: [T0, T1]
blocked_tiers: [T2, T3, T4, T5]
expected_behavior:
  - PR diff と CI log だけを読む
  - patch を作らない
  - GitHub comment を投稿しない

監視では、trace に risk_tier を付けます。

{
  "agent_run_id": "run_20260623_04",
  "tool_name": "mcp.github.create_issue_comment",
  "risk_tier": "T4",
  "approval_id": "apr_20260623_07",
  "target": "repo:nidoneko/HP issue:#123"
}

これで、T4 が承認なしで実行された、T3 が特定 agent に偏っている、T5 が呼ばれそうになった、という検知ができます。OpenTelemetry GenAI semantic conventions は tool call の名前や引数を表現する方向を持っていますが、組織固有の risk_tier は自分たちで付け足す前提で考えた方が実務的です。

tier の棚卸しを定例化する

tool risk tier は一度作って終わりではありません。MCP server の tool が増える、GitHub の権限 scope が変わる、agent が別 workflow に流用される、という変化で tier はずれます。

月次の棚卸しでは、最低限これを見ます。

見るもの判断
T4 承認件数多すぎるなら workflow 分割か draft 化を検討
T3 却下率policy が曖昧か、agent が過剰 write している
T0 / T1 の失敗read-only でも機密境界を越えていないか
新規 MCP tooldefault deny から始め、owner が tier を付ける
incident / near miss該当 tool の tier を上げるか禁止へ移す

特に MCP は、server の version 更新で tool definition が変わることがあります。catalog の review_cycle と tool definition version を持たせ、承認待ちの間に tool が変わった場合は再承認に戻します。

導入手順

小さく始めるなら、この順番で十分です。

  1. 直近1か月で使った tool call を集める
  2. read / inspect / draft / write / external action / forbidden に分ける
  3. T3 以上だけ承認リクエストのテンプレートを作る
  4. MCP server catalog に tool tier を追加する
  5. eval に「許可 tier 以外を呼ばない」ケースを入れる
  6. trace や作業ログに risk_tier を残す
  7. 月次で T4 件数、却下理由、incident を見て tier を更新する

最初から完璧な agent platform を作る必要はありません。まずは「何を自動で進めてよいか」と「何を絶対に止めるか」を分類表に落とすことです。ここが決まると、承認フロー、監査ログ、eval、runtime monitoring が同じ言葉でつながります。

参考にした一次情報

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 →