AI・信頼性・評価

AIエージェントを多数動かすガバナンス：例外監視と権限の絞り方

2026/8/3 （更新: 2026/10/13）

🤖 AIを使用して執筆

多数のエージェントを、全部見ずに例外だけ見て統べる

素朴な答えから始める。何も足さないことだ。全体を並列で開放し、各エージェントに完全な自律を与える。スループットと幅は最大で、いちばん速い。ただし調停を一つも置いていないから、二体が同じ仕事を拾えば二重作業になり、同じ共有状態を上書きすれば壊れる。途中で固まった一体は、何も知らせずに止まる。だから気づけない。

なら調停を足せばいい。共有状態に触れる仕事に、ロックや claim を置いて奪い合いを一点に絞る。これが中央の相互排他だ。予期した競合点を決定的に潰せるから、同じ仕事の二重処理はこれで消える。だが一つ直すと、次の破れ方が見えてくる。ロック自体がクラッシュを生き延びる仕組み（奪取のためのTTL）を要し、共有面とレイテンシが増える。何より、守れるのは「想定した」競合だけだ。かといって安全側に倒して全体を直列化すれば、そもそもNにした意味が消える。もう一つの道は、触れ合う面そのものを無くすことだ。OpenHandsは仕事のセッションごとに隔離されたコンテナを立て、イベントストリームの全アクションをその中で実行する¹。同じ状態を共有しないなら、競合は起きようがない。ただし、この論文が隔離しているのは仕事のセッションであって、エージェントではない。同論文の多エージェント機構は、あるエージェントが別のエージェントへ subtask を委譲する形をとるが、委譲先を別の囲いへ分けるとは書いていない¹。境界の引き方しだいで、隔離はN体の競合には届かない。同じリポジトリ、同じ待ち行列を触るなら、最後の書き戻しで衝突する。

それでも不安なら、残る手は人間が全部見ることだ。全アクションに同期の監督を挟む。最も安全で、文脈も責任も人が持つ。だが、まったくスケールしない。自律プロセスを何体も並べておいて「全部の出力を毎回見る」なら、監督者が単一のボトルネックになり、Nにした意味は消える。安い労働が余っている今、全数を人が見るのは最大の浪費だ。

放任は調停を欠いて事故り、相互排他は想定内しか守れず、隔離は本当に共有された状態には届かず、全数監督は回らない。この破れ方が、そのまま初期値の形を決める。監督を「全アクション審査」でなく「例外ベース＋不変条件」で設計する。互いに触れないステートレスな仕事は、完全自律で並列に走らせる。同じ状態に触れる仕事は、その競合点だけに相互排他をかける。全体は直列化しない。不可逆・対外・高被害だけを人間ゲートへ通す。この「正常は自動で回し、逸脱だけを人が見る」という発想自体は新しくない。起こりにくい異常を人が見張り続けることは人間には不可能なので自動の警報系に任せるほかない、という指摘は1983年からある²。Googleのサイト信頼性工学（SRE）チームは、この設計をエラーバジェットと例外ベースの監視として大規模に回していると報告している³。要点は、スケールさせたいなら「全部見る」でなく「例外だけ見る」に設計を落とすことだ。

仕事を配る役と並列に走る役を分ける形は、実運用のハーネスにもある。Clineのチーム機能（CLIなどに限る）では、調整役のエージェントが共有のタスクボードを通じて仕事を専門のエージェントへ配る⁴。より簡単な委譲として別に置くサブエージェントは並列に走って報告を返すが、Actモードではファイルを編集しコマンドを実行できる。調べ物だけを頼んでもPlanモードにしても、変更が起きにくくなるだけで、すべては止まらない、と同じ文書は書く⁴。書き込む仕事どうしの競合をどう調停するかは、どちらの頁にも書かれていない⁴。

ただし、放任を選ぶときも「放置」にはしない。自律プロセスは、止まったことを自分から知らせない。だから、生きているかを明示信号にする。ハートビートは「ターンが終わった」を意味するだけで「仕事が進んだ」ではない。進捗はコミットや成果物の更新で測る。そして競合は、規律（気をつけると約束する）でなく機構（構造的に奪い合えなくする）で排除する。

可逆性と被害で仕分け、届く先を縮めて爆発半径を縛る

次に、二つ目の問い、壊せる範囲をどう縛るかに移る。自律実行が安くなると、同じ速さで壊せるようにもなる。非決定なアクターは、指示していない危険な行為を、もっともらしく実行しうる。縛り方は、いつ・どこで守るかで四つに分かれる。事後に戻す、実行前に止める、そもそも持たせない、そして届く先を縮める、だ。実運用のコーディング・エージェント・ハーネスは、このどれを既定に置くかで現に分岐している。

一つ、事後の可逆性で受ける。自由に実行させ、壊れたら戻す。速度と自律を最大化でき、版管理・undo・ステージングがあれば大半の事故は巻き戻せる。これを既定に振り切ったのがAiderで、AIがファイルを編集するたびに説明つきのコミットを打ち、undoコマンドで即座に取り消せるようにしている⁵。Clineも同じ方向で、ツールを使うたびに影のgitリポジトリへコミットするチェックポイントを持ち、「失敗の代償をほぼゼロにする」ことが自律を許容する安全予算になると説明する⁴。可逆性は待つものではなく、機構で製造できる。だが効くのは「実際に可逆な」行為だけだ。対外送信・破壊・秘密の露出はすり抜ける。送ったメール、消したディスク、公開してしまった漏洩は、取り消せない。しかも、信号を出さない破壊には、戻す前に気づけない。

二つ、実行前の人間承認ゲートを置く。不可逆・対外・高被害だけを止める。最悪ケースを確実に閉じられ、責任と文脈を人が持つ。ここで効くのは、ゲートがモデルの外側にあることだ。Claude Codeの権限規則は、拒否・確認・許可の順に評価され、最初に一致した規則が結果を決める。規則の具体性は順序を変えない⁶。Clineは既定で「ファイルの編集と端末コマンドの一つ一つに承認を要求する」とし、自動承認は明示のトグルとして別に置く。ただし同じ公式ドキュメントは、チェックポイントがあるなら「変更を一つ一つ吟味して承認する代わりに、速く走らせて問題が起きたら戻せばいい」と書き、自動承認を前提にした手順を勧める⁴。可逆な行為の同意をどこへ置くかは、一社の中でも定まっていない。そしてこの手の弱点は共通で、レイテンシと人間ボトルネックを足すうえ、捕まえられるのは「事前に危険と分類した」行為だけだ。見落とした不可逆行為は通ってしまう。過剰にゲートすれば、自律の意味を殺す。

三つ、能力そのものを持たせない。最小権限で、危険な力を構造的に奪う。書き込み経路がなければ壊せない。最小権限とfail-safeな初期値は、SaltzerとSchroederが1975年にまとめた安全設計の基本原則だ（fail-safe な既定は同論文がE. Glaserの1965年の提案として挙げている）⁷。原典は最小権限の効能を、主として事故や誤りによる被害を抑えることだと書いている。攻撃者を想定しなくても、この原則はそのまま当たる。アプリ層での実装はこうなる。Claude Codeでツール名だけを書いた拒否規則は、そのツールを、呼ばれた時点で止めるのではなく、モデルのコンテキストから丸ごと取り除く。見えないツールは選べない。ただし同じドキュメントは、この丸ごと取り除く扱いに例外がひとつあることも書いている。会話を終了するツールだけは、他のツールが残っているかぎり拒否規則で取り除けず、確認規則でも尋ねられない⁶。能力を構造的に奪う設計にも、機構の側が最後に一つだけ残す口がある。ただし硬直的で、正当に必要になった行為まで塞ぐ。欲しくなったら、監査つきの経路をあらためて作り直す必要がある。

四つ、届く先そのものを縮める。能力は取り上げず、行為が着地できる世界のほうを小さくする。ここが、実運用ハーネスでいちばん広く合意が取れた場所だ。ただし囲いの中身を外から確かめられるか、という別の穴もある。Willisonは、コーディング・エージェントが実装するサンドボックスについて、信用に足るだけの文書をまだ見ていないと書いた。もっとも同じ記事は直後に追記を置き、AnthropicがClaude CodeのSafe YOLOモードについて文書を持っていることを本人が挙げている⁸。OpenAIのCodex CLIは、サンドボックスを読み取り専用・作業領域書き込み・制限解除の三段に切り、OSが持つ機構でそれを強制する。macOSはSeatbelt、LinuxとWSL2はbubblewrapだ⁹。Codex CLIはネットワークも既定では切っており、開けるには設定で明示的に有効にする必要がある。OpenHandsは仕事のセッションごとに隔離されたDockerコンテナを立ち上げ、イベントストリームの全アクションをその中で実行する。動機は安全だけではなく、同じ環境を再現できることも含まれる¹。発想が違う。エージェントを賢く安全にするのではない。失敗が着地できる範囲を縮めて、失敗を安くする。

なぜ説得ではなく封じ込めなのか。Simon Willisonは、データが盗まれる条件を三つの重なりとして名指した。私的なデータへのアクセス、攻撃者が仕込みうる信用できない入力、そして外部へ通信する能力である⁸。三つが揃った時点で、指示の書き方では塞げない。承認ダイアログも同じで、押すのは人だが、押すべきかを判断する材料は汚染されうるコンテキストの側にある。三本目の脚である外部通信を、機構で折るほうが確実だ。Willison自身の運用則も同じ向きだ。危険な自動承認モードをどうしても使うなら、選択肢は三つだと彼は書く⁸。ファイルと秘密とネットワーク接続を制限したサンドボックスに閉じるか、他人の計算機の上で走らせるか、リスクを取るか、である。彼自身は二つ目を好み、GitHub Codespaces を挙げる。何か起きても最悪なのは、その環境に持ち込んだコードが攻撃者に持ち出されるか、つないだリポジトリへ悪いコードが送り込まれるところまでだからだ。インターネットアクセスを信用できるホストの一覧に絞ることは、私的なソースコードの流出を防ぐ優れた方法だ、とも書く⁸。Claude Codeの権限ドキュメントは、この点をはっきり書いている。サンドボックスがかかるのはBashなどシェルコマンドを走らせるツールとその子プロセスだが、その範囲では、プロンプトインジェクションがモデルの判断を迂回したあとでも制限は効く、と⁶。

ではアプリ層のゲートは要らないのか。要る。両者は精度が違う。アプリ層の規則は「この編集は許すが、あのパスへの書き込みは止める」という細かさを書けるが、ハーネスが見ていない経路には届かない。同じ権限ドキュメントがその穴を自分で明記している。読み書きの拒否規則は、ファイルを自分で開くスクリプトのような任意のサブプロセスには適用されない、と⁶。そして続けて、あらゆるプロセスに対してパスへの到達を止めたいならサンドボックスを有効にせよ、と書く。逆にOS層の境界は堅いが粗い。書き込みを許した領域の中で、消してよいファイルと消してはいけないファイルの区別はつかない。だから重ねる。細かい線引きはアプリ層、最後の壁はOS層に置く。同じ文書が両方を使えと言うのは、この非対称のためだ⁶。

初期値は「可逆か × 被害の大きさ」の二軸で分ける。担い手を決める仕分けでは、不可逆という一語が「戻せない」と「外したとき被害が大きい」の両方を畳み込んでおり、縛る力は機構・指示・人手の順に強い。実行時の一操作ごとの既定へ落とすには、その不可逆を二つの軸へ分解しておく必要がある。

四つは排他ではない。Codex CLIは、囲いと同意を独立した二本のダイヤルとして置く。サンドボックスが「何が起こりうるか」を決め、承認ポリシー（on-request／never。かつて選べた untrusted は2026年9月時点で退役している）が「何をしてよいか」を別に決める。既定のon-requestは、囲いの中では黙って働き、境界を越えるときだけ聞く、という形だ⁹。自律を一本のスライダで上げ下げしない。縛る対象を、行為の一つ一つではなく境界の側へ置き換えている。同意を求める回数は減り、最悪ケースは縮む。

この「可逆な決定は速く、不可逆な決定だけ慎重に」という切り分け自体は、ソフトウェア工学が変更管理・カナリア・段階的ロールアウトとして積んできたものだ。同じ論理構造は経営判断にもある。Amazonのジェフ・ベゾスは株主への年次書簡で、意思決定を「一方通行の扉」と「両開きの扉」に分けた。可逆な側である両開きの扉は、判断力のある個人か小さなグループが速く決められるし、そう決めるべきだ、と書いている¹⁰。ベゾスは同じ箇所に注を付けて、逆向きの誤りにも触れている。軽い手続きで不可逆な判断を常習的に下す企業は、大きくなる前に絶滅する、と¹⁰。あちらは組織の決定、こちらは実行時の操作だが、可逆性で重みを変えるという骨格は同じだ。要点は、指示でなく構造で縛ることだ。危険な力は「使わないと約束する」でなく「持たない」で閉じる。OWASPのLLMアプリ向けリスク一覧（2025年版）は、LLMの予期しない・曖昧な・操作された出力に応じて有害な行為が実行されうる脆弱性を「過剰な主体性（Excessive Agency）」と名指し、その根本原因をたいてい過剰な機能・過剰な権限・過剰な自律のうち一つ以上に置く。対策の一つは、行為の可否をLLMに決めさせず、下流のシステムで認可することだ¹¹。同じ要点を、プロンプトインジェクション対策の設計パターンを整理した論文は一文にしている。信用できない入力を取り込んだ後は、その入力が結果を伴う行為を引き起こせないよう縛るほかない、と¹²。そして持たせざるをえない力は、届く先を縮めた囲いの中でだけ使わせる。

見落としの外側では、統治は解けていない

だが、読者はこう反論できる。「例外だけ見て、危険は構造で塞ぐ。なら統治は解けたのでは」。解けていない。古い規律が効かない部分が残る。

相互排他が潰せるのは、設計時に「想定した」競合だけだ。承認ゲートが止められるのは、事前に「危険と分類した」行為だけだ。可逆性で受けられるのは、「実際に可逆な」行為だけだ。三つとも、見落としの外側では効かない。そして、密結合していて相互作用の複雑な系では、設計者が予期しなかった経路で事故が連鎖し、その起き方を事前に数え尽くせない、と社会学者のチャールズ・ペローは論じた¹³。列挙に頼る防御は、列挙の穴の分だけ漏れる。囲いだけが、この型の漏れ方をしない。危険を数え上げずに済むからだ。ペローの枠組みで言えば、囲いは二つの条件のうち結合の側を緩める。事故の連鎖が要求する密結合を、境界で断つ。疎結合の利点は、故障が起きても影響を受けた領域を隔離できるので回復の余地があることだ、とペロー自身も書いている¹³。だが囲いにも別の限界がある。境界の内側で起きることは止められないし、その境界をどこに引くかも、結局は人が判断する。囲いそのものにも古い留保がある。SaltzerとSchroederは、共有系でプログラムを完全に封じ込めるのは非常に困難か、おそらく不可能だと書いた⁷。共有領域への書き込み以外の、もっと微妙な手段で外へ信号を出しうるからである。ペローの議論はもう一段強い。警告や安全装置を積むという工学の常道そのものが失敗し、予防策は複雑さを足すことで新種の事故を生みうる、というのが中心の主張である¹³。層を重ねる本稿の設計も、その射程の内側にある。

漏れるのは、見落としの外側だけではない。設計者が自分で開けておいた穴もある。実運用のハーネスを並べてみると、完全に閉じきったものは見当たらない。Claude Codeのフックは、終了コード2で初めてツール呼び出しを止める。stdoutに妥当なJSONを出さないかぎり、1を返しても処理はそのまま進むので、ポリシーを強制したいなら2を使え、とドキュメント自身が警告している¹⁴。Codex CLIには制限解除モードがあり⁹、Aiderは自動コミットを切るオプションを持つ⁵。ClineのCLIとDesktopでは、サブエージェントの起動を一度承認すると、その後の子のツール呼び出しは承認を求めず、承認の設定も子の中では効かない⁴。逃げ道は事故ではなく、仕様だ。しかも、開けるのが利用者だとも限らない。同じAiderは、2026年8月時点の公式ドキュメントによれば、コミットを打つとき手元のリポジトリに仕掛けられたpre-commitフックを既定で飛ばす。--no-verify を付けて回すのが既定側で、検査を走らせたいほうが明示的に有効化する⁵。ゲートを置いたのは人間で、それを迂回すると決めたのはツールの既定値だ。Claude Codeのドキュメントも、フックが起動できないときは大半のイベントで処理が止まらず、設定でパスを打ち間違えれば門は一度も走らない、と注意している¹⁴。失敗したら止める設定はフックごとに選べるが、既定は続行のほうだ¹⁴。開く側へ倒れるのは、終了コードの解釈だけではない。

そして、逃げ道があること自体は責められない。閉じた側に倒れて自律ループを恒久的に止めるほうが損害の大きい位置は実在するからだ。どちらへ倒すかはゲートごとの判断になる。Claude Codeも、作業の終わりに走るフックには失敗時に止める設定を効かせない。そこで止めればClaudeは作業へ送り返されるが、走らないフックをClaudeは直せないからだ¹⁴。ここで問うのは、置くと決めた扉をどう運用するかのほうだ。Claude Code向けのフック集ECCは、そこを明示的に設計している。多くのブロックのメッセージには解除方法を同梱する。同じブロックが所定の回数を超えると、長文の説明を一行に圧縮する。ゲート自身が食うコンテキストまで設計の対象にしている¹⁵。だから問いは「fail-closedか否か」ではない。誰が、どれだけ目立つ形で、その扉を開けられるか、である。ゲートは、解除手順と文量まで設計して初めて運用に耐える。

では、監督者自身は痩せていかないのか。Bainbridgeが1983年に名指しした劣化の原因は、退屈ではなく、使わないことである。手を動かさなくなった技能はそれだけで衰え、長期記憶からの引き出しやすさも使用頻度に従う。原典が書いているのはそういう機構だ²。原典はこの拡張を自分で書いている。異常時だけ上位者を呼ぶ体制について、その上位者も知識を見直さず要となる手技を練習していなければ引き継げない、と述べる²。この指摘は、正常時にすることのない受動的な見張りだけの話ではない。

さらに重い反証がある。ParasuramanとManzeyは、自動化に任せた側の監視が落ちる現象（complacency）が複数タスク負荷の下で起きると報告した。手作業が自動化された作業と注意を奪い合う状況だ¹⁶。しかも彼らは、complacency は単純な練習の反復では克服できず、判断の依存にあたる automation bias のほうは訓練や教示では防げない、と述べている。N体を並べて例外だけを見るという本節までの設計は、その条件に当たる。監督者は自分の手でも仕事をしており、その手作業が、任せた側の監視と注意を奪い合うからだ¹⁶。しかもこの効果は、熟達では抜けられない。原典は、飛行経験を積んだパイロットでも経験ある航空管制官でも同じ効果が出た研究を挙げる。人手を最後の関所に据える設計のうち、監督者が自分の手でも仕事をするものは、この弱点を抱える。

だから、痩せるものと鍛えられるものを分けて置く。痩せるのは、AIの失敗を自分で追って直す技能だ。不使用で確実に落ちる側なので、時々は自分の手で書き、自分の手で追って取り戻すほかない。原典も、交代のたびに短時間は手動で操作させることを一案として挙げる²。恩恵を打ち消す代価ではなく、恩恵を受け続けるための整備である。原典は、手動介入がめったに要らない最も成功した自動化ほど、人間の訓練に最大の投資が要るかもしれない、と結んでいる²。鍛えられうるのは、どこに線を引くか・どの失敗の型を疑うかという判断のほうだ。生成が安くなったぶん、その判断を当てる機会はむしろ増える。判断の基準になる定石も手元にある。例外ベース監視³、最小権限⁷、可逆性の切り分け¹⁰だ。

ただし後者も、自動では鍛わらない。判断が研がれるのは、下した線引きを結果と突き合わせ、外した型を数えたときだけだ。突き合わせのない承認が鍛えるのは、判断ではなく承認の速さのほうである。complacencyが効くのはこの点である。原典は、単純に練習を重ねるだけでは克服できないと報告している。練習の量では消えないと述べたうえで、注意の配分そのものを訓練する方法なら効きうる、と続けている¹⁶。実験でも、失敗しうると教えられただけの群より、訓練中に支援の診断が外れるのを実際に経験した群のほうが complacency が有意に低かった。支援が故障を知らせ損ねる失敗を経験した群では、差は有意にならなかった。だから監督者の側にも構造が要る。見る対象を減らし、そこだけに注意を割ける形にしておく。原典の実験でも、他の職務を持たず自動化の後詰めだけを担った条件では、検出はほぼ完全だった¹⁶。これは机上の処方ではない。SREの運用記録には、Bigtableを担当するチームのかつての事例がある。アラートが多すぎて担当者が選別に時間を取られ、実際に利用者へ影響した問題のほうを見落とした³。是正は三本立てで、Bigtableの性能改善に力を注ぎながら、SLO目標を一時的に緩め、メール通知を止めた。アラートを一時的に引いたことで長期の問題を直す余裕ができ、より良いサービスへ速く進めた、と原典は書く³。統べる設計は、監督者の腕を保つ設計でもある。

想定できる競合、分類できる危険、実際に可逆な行為については、昔からの仕組みがそのまま効く。統べたいなら全部でなく例外を見る。縛りたいなら約束でなく構造に頼り、届く先そのものを縮めておく。だが、見落としたものへの対処は、いまも最後は人間が担っている。古い規律が効かない残りが、ここにある。そのうえで、爆発を起こさないという約束は、ここまでのどの仕組みもしていない。約束に近づけられるのは半径のほうだ。どれだけ速く壊れても、その半径が承認した範囲を出ないように、構造で縛っておく。ただし、その境界も完全には閉じきれない。そして、この構造は無料ではない。ロックはレイテンシを、ゲートは待ち時間を、囲いは正当な外部アクセスの手間を、例外レビューは人の時間を足す。SREの記録では、10〜12人のチームに監視系の構築と維持を主務とする担当者が1〜2人つく³。例外だけを見る体制は、見る人の時間だけでなく、見る仕組みを保つ人員も要る。統治のコストを払ってなお任せる価値があるのか。その勘定が、次の仕事になる。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。