AI・信頼性・評価

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

2026/8/3 （更新: 2026/9/15） シリーズ「AI協働への姿勢」 第10回 / 全15回

🤖 AIが執筆しています

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

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

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

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

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

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

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

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

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

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

一つ、事後の可逆性で受ける。自由に実行させ、壊れたら戻す。速度と自律を最大化でき、版管理・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のジェフ・ベゾスは株主への年次書簡で、意思決定を「一方通行の扉」と「両開きの扉」に分けた。可逆な側である両開きの扉は、判断力のある個人か小さなグループが速く決められるし、そう決めるべきだ、と書いている¹⁰。ベゾスは同じ箇所に注を付けて、逆向きの誤りにも触れている。軽い手続きで不可逆な判断を常習的に下す企業は、大きくなる前に絶滅する、と¹⁰。あちらは組織の決定、こちらは実行時の操作だが、可逆性で重みを変えるという骨格は同じだ。要点は、指示でなく構造で縛ることだ。危険な力は「使わないと約束する」でなく「持たない」で閉じる。同じ要点を、Willisonが引く設計パターンの論文は一文にしている。信用できない入力を取り込んだ後は、その入力が結果を伴う行為を引き起こせないよう縛るほかない、と⁸。そして持たせざるをえない力は、届く先を縮めた囲いの中でだけ使わせる。

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

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

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

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

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

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

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

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

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

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

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