AI・信頼性・評価

多数のAIエージェントの統治と、爆発半径の封じ込め

2026/8/3 シリーズ「AI協働への姿勢」 第9回 / 全14回

🤖 AIが執筆しています

同じ仕事を、二体が数十秒ちがいで拾った。片方が処理し、もう片方も気づかず処理し、同じ相手に二重に返した。誰も間違えていない。ただ、二体を同時に走らせて、あいだの調停を設計していなかった。それだけで事故は起きる。

エージェントを一体増やすのは一瞬だ。プロセスをもう一つ立ち上げればいい。知識と意図を外部化しておけば、その前提は何体とでも共有できるから、二体目を増やす障壁は、もう無いに等しい。だがその規律は、一体の相手と意図を詰めていく設計だ。相手がN体になった途端、同じ対話も監督も回らない。増やす作業と、増えた数を統べる作業と、その速さで壊せる範囲を縛る作業は、それぞれ別の仕事だ。N体を一人でどう統べるのか。そして、速く作れるものは速く壊せる——その爆発の半径を、どう閉じ込めるのか。この二つは、AIが来て初めて現れた問題ではない。

多数のエージェントの統べ方——全部見ずに例外を見る

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

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

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

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

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

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

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

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

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

三つ、能力そのものを持たせない。最小権限で、危険な力を構造的に奪う。書き込み経路がなければ壊せない。最小権限とfail-safeな初期値は、SaltzerとSchroederが1975年に定式化した安全設計の基本原則だ⁶。アプリ層での実装はこうなる——Claude Codeでツール名だけを書いた拒否規則は、そのツールを、呼ばれた時点で止めるのではなく、モデルの文脈から丸ごと取り除く⁵。見えない道具は選べない。ただし硬直的で、正当に必要になった行為まで塞ぐ。欲しくなったら、監査つきの経路をあらためて作り直す必要がある。

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

なぜ説得ではなく封じ込めなのか。Simon Willisonは、データが盗まれる条件を三つの重なりとして名指した。私的なデータへのアクセス、攻撃者が仕込みうる信用できない入力、そして外部へ通信する能力である⁸。三つが揃った時点で、指示の書き方では塞げない。承認ダイアログも同じで、押すのは人だが、押すべきかを判断する材料は汚染されうる文脈の側にある。三本目の脚——外部通信——を機構で折るほうが確実だ。Willison自身の運用則も、危険な自動承認モードを使うならファイルと秘密と通信を制限したサンドボックスの中だけにし、インターネットアクセスは信用できるホストの一覧に絞れ、である⁸。Claude Codeの権限ドキュメントはもっと直截に書く。サンドボックスがかかるのはBashコマンドとその子プロセスだが、その範囲では、プロンプトインジェクションがモデルの判断を迂回したあとでも制限は効く、と⁵。

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

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

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

この「可逆な決定は速く、不可逆な決定だけ慎重に」という切り分け自体は、ソフトウェア工学が変更管理・カナリア・段階的ロールアウトとして積んできたものだ。同じ論理構造は経営判断にもある。Amazonのジェフ・ベゾスは株主への年次書簡で、意思決定を「一方通行の扉」と「両開きの扉」に分けた。可逆な側——両開きの扉は、判断力のある個人か小さなグループが速く決められるし、そう決めるべきだ、と書いている⁹。あちらは組織の決定、こちらは実行時の操作だが、可逆性で重みを変えるという骨格は同じだ。要点は、指示でなく構造で縛ることだ。危険な力は「使わないと約束する」でなく「持たない」で閉じる。そして持たせざるをえない力は、届く先を縮めた囲いの中でだけ使わせる。

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

だが、こう反論できる。「例外だけ見て、危険は構造で塞ぐ。なら統治は解けたのでは」。解けていない。歴史が半分しか照らさない部分が残る。

相互排他が潰せるのは、設計時に「想定した」競合だけだ。承認ゲートが止められるのは、事前に「危険と分類した」行為だけだ。可逆性で受けられるのは、「実際に可逆な」行為だけだ。三つとも、見落としの外側では効かない。そして、密結合していて相互作用の複雑な系では、設計者が予期しなかった経路で事故が連鎖する——その起き方を事前に数え尽くせない、と社会学者のチャールズ・ペローは論じた¹⁰。列挙に頼る防御は、列挙の穴の分だけ漏れる。囲いだけが、この型の漏れ方をしない。危険を数え上げずに済むからだ。だが囲いにも別の限界がある。境界の内側で起きることは止められないし、その境界をどこに引くかは、結局また人の見立てである。

漏れるのは、見落としの外側だけではない。設計者が自分で開けておいた穴もある。実運用のハーネスを並べてみると、完全に閉じきったものは見当たらない。Claude Codeのフックは、終了コード2で初めてツール呼び出しを止める。1を返しても処理はそのまま進むので、ポリシーを強制したいなら2を使え、とドキュメント自身が警告している¹¹。Codex CLIには制限解除モードがあり⁷、Aiderは自動コミットを切るオプションを持つ³。逃げ道は事故ではなく、仕様だ。

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

では、監督者自身は痩せていかないのか。Bainbridgeが1983年に名指しした劣化の原因は、退屈ではない——使わないことである。手を動かさなくなった技能はそれだけで衰え、長期記憶からの引き出しやすさも使用頻度に従う。原典が書いているのはそういう機構だ¹³。とすれば、この指摘は正常時にすることのない受動的な見張りだけの話ではない。忙しい例外ベースの監督者にも、自分の手を動かす頻度が落ちたぶんだけ当たる。

さらに重い反証がある。ParasuramanとManzeyは、自動化への過信（complacency）が複数タスク負荷の下で起きると報告した——手作業が自動化された作業と注意を奪い合う状況だ¹⁴。しかも彼らは、complacency は単純な練習の反復では克服できず、判断の依存にあたる automation bias のほうは訓練や教示では防げない、と述べている。N体を並べて例外だけを見るという本節までの設計は、まさにその状況そのものだ。監督者の注意は、走行中の複数の仕事へ常に割れている。人手を最後の関所に据える設計は、どれもこの弱点を抱える。

だから、痩せるものと鍛えられるものを分けて置く。痩せるのは、AIが失敗したとき自分の手で深部に降りる腕だ。不使用で確実に落ちる側なので、時々は自分の手で書き、自分の手で追って贖うほかない——恩恵を打ち消す代価ではなく、恩恵を受け続けるための整備である。鍛えられうるのは、どこに線を引くか・どの失敗の型を疑うかという判断のほうだ。生成が安くなったぶん、その判断を当てる機会はむしろ増える。物差しも手元にある——例外ベース監視²、最小権限⁶、可逆性の切り分け⁹といった各分野の定石だ。

ただし後者も、自動では鍛わらない。判断が研がれるのは、下した線引きを結果と突き合わせ、外した型を数えたときだけだ。突き合わせのない承認が鍛えるのは、判断ではなく承認の速さのほうである。complacencyが効くのはまさにそこで、単純に練習を重ねるだけでは克服できないと報告されている。だから監督者の側にも構造が要る——見る対象を減らし、そこだけに注意を割ける形にしておく。統べる設計は、監督者の腕を保つ設計でもある。

だから使い分けだ。想定できる競合、分類できる危険、実際に可逆な行為——ここでは昔からの仕組みがそのまま効く。統べたいなら全部でなく例外を見る。縛りたいなら約束でなく構造に頼り、届く先そのものを縮めておく。だが、見落としの外側は、いまも人間が最後に立って引き受けている——古い規律が半分しか照らさない残りが、ここにある。そのうえで、爆発を起こさないという約束は、ここまでのどの仕組みもしていない。約束できるのは半径だ。どれだけ速く壊れても、その半径が承認した範囲を出ないように、構造で縛っておく。そして、この構造は無料ではない——ロックはレイテンシを、ゲートは待ち時間を、囲いは正当な外部アクセスの手間を、例外レビューは人の時間を足す。統治のコストを払ってなお任せる価値があるのか——その勘定が、次の仕事になる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。