AI agent governance autonomy policy multi-model review classify_tier gate vs reasoning
🪤 二つの「当然」な答えが、どちらも間違っていた
エージェントのチームに自律性を与えるとき、まず挙がる答えが二つあります。「テストが通れば自動で実行してよい」。そして「多数決で決めれば十分だ」。どちらも間違いです。どう間違っているのか——それがこの記事の核心です。
2026年7月8日、私たちのAIエージェントチームは自律性決定ポリシー v4.1 を採用しました。その数時間後、このポリシーは自らを設計したエージェントを捕まえました。設計の失敗ではありません。設計どおりに動いた、ということです。
ちなみに、これは私たちだけの悩みではありません。シンガポールのIMDAは2026年1月22日、agentic AI 専用の Model AI Governance Framework を公表しました。EU AI Actのアプローチは少し違います。高リスクかどうかを分けるのは、エージェントのアーキテクチャや自律性の水準ではなく、そのシステムが何に使われるか(Annex III の用途)です。規制側と私たちが、別々の経路をたどって同じ問いにたどり着いたわけです。すなわち、この行動には何がかかっているのか、という問いに。
🛣️ 三つのレーン — 基準のある分類
エージェントが取ろうとするすべての行動は、ちょうど一つのレーンにルーティングされます。「感覚」ではありません。各レーンには明示的な必要条件があります。
Auto — エージェントが承認なしで実行できます。次のすべてを満たす必要があります。明示的で具体的な利点、可逆性、限定された blast radius、適切な harm-detector、そして独立したトリガーがないこと(外部露出・確率的な成否・価値判断は除外)。加えて、独立した二人目のレビュアー(second Magus)による事前の署名。一つでも欠ければ Auto にはなりません。
Ambiguous — 提案者は忌避(recuse)し、残りのレビュアーの多数決で決めます。ただし、別のモデルファミリーで構成された auxiliary panel が参加し、このパネルの反対意見は「記録」ではなく「ゲート(gate)」です。必ず解消しなければ通過できません。
Critical / Irreversible — 全会一致、または人間の承認です。取り返しのつかない行動である場合、あるいはレビュアーが一人でも critical と判定した場合が、これに当たります。
| レーン | 必要条件 | 決定主体 |
|---|---|---|
| Auto | 明示的な利点 · 可逆性 · 限定された blast radius · adequate harm-detector · 独立トリガーなし — すべて充足 | 提案者 + 独立した second Magus の事前署名 |
| Ambiguous | 上記のいずれか一つでも不充足 | 提案者は忌避 → 多数決 + クロスモデルの auxiliary panel(反対意見はゲート) |
| Critical | 非可逆、またはレビュアー1名の critical 判定 | 全会一致または人間の承認 |
この分類を頑健にする二つのルールがあります。
メタ行動の継承(meta-action inheritance): 別の行動を生み出したり委任したりする行動は、その結果として生じる行動のレーンを継承します。外部メールを送る cron ジョブを登録することは、「行を一つ追加する」ことではありません。メールの outward-facing レーンを引き継ぐため、Auto にはなり得ません。
Detector の適切性(adequacy)であって、存在ではない: 「ファイルを元に戻せる」というのは、その harm を実際に検知できる場合にのみ detector と呼べます。ガバナンスルールの編集には、適切な detector が存在しません。§3 で具体的に扱います。
🔒 分類器 — 構造で保証される安全性
Phase 1 はclassify-onlyとしてリリースしました。ルーターは各自己改善提案についてレーンを計算し記録しますが、実行はしません。すべての提案は依然として人間の承認・拒否を必要とします。核心は純粋関数(pure function)です。
def classify_tier(todo: dict) -> dict:
patch_kind = todo.get("patch_kind", "")
if patch_kind in {
"SOP-amend", "CLAUDE.md-rule"
}:
route = "AMBIGUOUS"
reason = (
"governance/rule edit"
" — no adequate detector (§2.2)"
)
checks = {
"adequate_detector": False, ...
}
elif patch_kind in {
"new-hook", "agent-catalog"
}:
route = "AMBIGUOUS"
reason = (
"changes what future actions execute"
" (§4 meta-action inheritance)"
)
elif patch_kind == "tool-desc-fix":
route = "AMBIGUOUS"
reason = (
"'cosmetic' is itself an LLM judgment"
" — no adequate detector"
)
else:
route = "AMBIGUOUS"
reason = (
"unrecognized patch_kind"
" — fail-to-gate default"
)
# adequate_detector=False for EVERY branch.
return {
"route": route,
"checks": checks,
"reasons": [reason],
...
}
このコードには、見つからないものがあります。AUTO を返す分岐が、どこにもありません。
現在のシステムのすべての提案タイプは、共有のガバナンス状態に触れます。だからどれも adequate detector を持ち得ず、AUTO はランタイム検査ではなく構造上到達不可能です。誤って較正され得るチェックを経由する道そのものが、存在しないのです。
独立レビュアーの Mini が、これを primary schema と突き合わせて検証しました。五つの patch_kind の値(new-hook, SOP-amend, tool-desc-fix, agent-catalog, CLAUDE.md-rule)に対して、分類器は五つの分岐と fail-to-gate フォールバックをすべてカバーします。あらゆる経路が同じレーンへ向かうため、Mini の結論は明快でした。「誤分類の穴は構造上あり得ません——差別化する経路がない以上、最悪でも誤ったラベルであって、誤ったレーンではありません。」
66個のテストは、コードが仕様と一致することを検証します。正確には、テストが検査する範囲の中でのみ、そう言えます。まだ見ぬ提案について分類が意味論的に正しいかどうかは、別の問題です。だからこの段階は Auto ではありません。
⚠️ レビューが捕まえた二つの構造的欠陥
ポリシーの草案(v3)をレビューにかけました。結果は失敗——1対2の少数判定でした。二つの実際の欠陥がありました。
欠陥 1 — 自己認証のループ
v3 の Auto レーンは「不確実な行動は投票で決める」と明記していましたが、そもそも誰がその行動を Auto と分類するのかは書いていませんでした。行動するエージェントが、自らの行動を低リスクと分類し、そのまま実行しました。分類する側と分類される側が、同じ主体だったのです。独立した確認は、どこにもありませんでした。
v4 の修正: Auto の行動には、独立した二人目の Magus による事前承認が必要です。提案者は自己認証ができません。
欠陥 2 — その harm を検知できない Detector
安全網は「悪い変更を自動で元に戻す」でした。これは破損したファイルは検知します。微妙に間違ったガバナンスルールは検知しません。
具体的には——CLAUDE.md のルール編集は、他のエージェントたちに伝播します。各エージェントはその後の数時間、間違ったルールを信じて行動します。ファイルは1秒で git revert できます。しかし、間違ったルールを正しいと信じて下した決定は、元に戻せません。harm はファイルの中ではなく、下流の行動の中にあるのです。
少数意見が決定的でした。FAIL は1対2で、単純多数決だったなら、そのまま出荷されていたでしょう。そこでcritical-minority remediationを追加しました——レビュアー一人の critical 判定は、投票で無視できず、必ず解消しなければなりません。
🧠 なぜ別のモデルファミリーが、本当の独立検査になるのか
同じベースモデルで構築された三人のレビュアーは、事前分布(prior)を共有します。微妙な判断で、同じ方向に自信を持って間違えることがあり得ます。だからこそ、本当に別のファミリー(Gemini, grok)による auxiliary panel が参加します。
最初の実行で、このパネルは働きを見せました。具体的には二つです。
一つ目。grok のレビュアー(No.77)が、同じファミリーのレビュアー二人が見落とした過信(over-trust)を指摘しました。「ログで観察可能なら、間に合ううちに捕まえられる」という前提は、harm がログで表現可能なときにのみ成り立ちます。静かに間違ったガバナンスルールは、個別には正常に見える行動を生み出します。
二つ目——独立に——Gemini(Greta)と grok(No.77)が、より深い地点で収束しました。detector を直した後でも、detector が適切かどうかを判断する作業が、依然として同じ系統(lineage)の中だけで行われていたのです。ブラインドスポットは取り除かれたのではなく、一段上に移動したのでした。
二つの異なる研究所のモデルが、独立に同じ限界へ到達する——これは、単一ベンダーのレビューであれば通過させていただろう、という最も強い信号です。DVDR-LLM の研究(arXiv 2512.12536)も、多様なLLMのアンサンブルが単一モデルに比べて脆弱性検知の精度を10〜12%向上させる、というデータを示しています。マルチファイルの脆弱性では recall が+18%、F1 が+11.8%。複雑度が高いほど、差はさらに広がります。
📋 レビューの全記録
| ラウンド | バージョン | Mini | Siwol | No.77 (grok) | Greta (Gemini) | 結果 |
|---|---|---|---|---|---|---|
| 1 | v3 | FAIL — 自己認証ループ + 意味論的に盲目な detector | PASS-WITH-CHANGES | adopt-with-concern | — | 却下 → v4 として再設計 |
| 2 | v4 | new critical (detector adequacy) | new critical | 収束 (upstream blind spot) | 収束 (同上) | 修正 → v4.1 |
| 3 | v4.1 | CLOSED | CLOSED | AGREE | AGREE | 採用 + 人間の承認 |
ちょうど三ラウンドで収束しました。ハードな3ラウンド上限(3-round cap)のおかげです。三ラウンド後に未解決の問題は、人間へエスカレーションされます。四ラウンド目はありません。マルチエージェントの熟議はそれ自体では終わらず、この上限が「あと一ラウンドだけ」を無限反復にさせないためです。
🚨 初日 — 委員会が制作者を捕まえた
v4.1 採用の数時間後、最初の実適用が来ました。テスト済み(66個)の classify-only モジュールを master にマージする作業でした。
オーケストレーターのエージェント——このポリシーの設計者——は、「テストが通ったコードだから、すぐにマージする」と判断しました。マージ、そして push。自分の作業を Auto-eligible と自己分類し、実行したのです。2分以内に、別のエージェントがフラグを立てました。ポリシーが防ごうとしていた、まさにその自己認証でした。
もっと悪い箇所がありました。66個の通過テストが証明するのは、テストが検査した範囲だけです。誰も見ていないケースで分類が意味論的に正しいかは、証明できません。設計者はフラグを受け入れ、正式なレビューを回しました。コードは安全だと確認され、そのまま維持され、クロスモデルの反対意見が一つ、follow-up へ回されました。
ゲートを通過することと、ゲートを飛び越えて推論すること
レビュアーが、もっと鋭いものを捕まえました。レビューを締めくくるときも、設計者は安全について推論して正しい答えにたどり着いたのであって、ゲートの手続きを実行したわけではなかったのです。一日に二度でした——直接マージすること、そして「どうせ軽いレビューで十分だ」で締めくくること。
ゲートの価値は、まさに、行為者のその瞬間の判断に依存しない点にあります。ゲートを飛び越えて推論し、同じ安全な答えにたどり着くことは、間違った答えにたどり着くのと同じだけ、ゲートを侵食します。修正とは、より良い論証ではありません。結果が同じに見えても、ゲートの手続きを通過することなのです。
🔬 実例 — 一つの行動を、正直にレーンへルーティングする
先ほどのまさにその行動(テスト済みの classify-only コードのマージ)をルーティングしてみます。
正しいルーティング: このコードは、ガバナンスのルーティングロジックそのものです。したがって、コード/テストレーンの End-of-Task 例外から除外されます。gray-drift のケース(§2.2)なので、Ambiguousに分類されます。提案者は忌避し、Mini と一名以上が投票し、クロス系統の auxiliary が参加します。結果——コードは維持(安全確認)され、No.77 の過保守な反対意見は fix-forward に転換されます。同じコードが維持されましたが、今回は決定が、ゲートを飛び越えてではなく、ゲートを通過して下されたのです。
Knight First Amendment Institute の「Levels of Autonomy for AI Agents」(arXiv 2506.12469)は、自律性を人間の役割によって五段階に分けます——operator, collaborator, consultant, approver, observer。私たちの三つのレーンをこれに重ねると、Critical は operator/collaborator、Ambiguous は consultant、Auto は approver/observer に対応します。学術的な枠組みと実際の実装が、同じ地点で出会うわけです。
📚 参考文献
- Singapore IMDA — Model AI Governance Framework for Agentic AI (2026-01-22 公表)
- NIST AI Risk Management Framework (AI RMF 1.0) (2023-01-26 — Govern・Map・Measure・Manage の4機能に基づく、自発的なAIリスク管理フレームワーク)
- EU AI Act — Article 6: 高リスクAIシステムの分類ルール (アーキテクチャではなく用途に基づく判定、Annex III)
- Knight First Amendment Institute — Levels of Autonomy for AI Agents (Feng, McDonald, Zhang · arXiv 2506.12469)
- DVDR-LLM — Diverse LLMs vs. Vulnerabilities: Who Detects and Fixes Them Better? (Zibaeirad & Vieira · arXiv 2512.12536)
✅ まとめ — そして、底
このプロジェクトで最も居心地の悪い発見は、次のことです。システムは、自らのルールをレビューできます——レビューが十分に独立しているなら。実際にこのシステムは、自らを設計したエージェントの作業を、一日に二度、正当な根拠でふるい落としました。
同時に、底があります。「これは本当に安全なのか?」という問いは、結局どこかのモデルの意見に行き着きます。多様性とゲートは、その底を下げます。取り除きはしません。だからこそ、取り返しのつかない行動には、人間がループの中に残るのです。