ラジカルAIプログラミング実践編 — 1人PoCから考えるマルチエージェント開発の「統治と委任」

夏休み自由研究連載 2026 の2本目です。

こんにちは、井上です。

ループエンジニアリングからグラフエンジニアリングへ——生成AIによる開発自動化の議論は、この1年で急速に解像度を上げています。論点は「AIをどう使うか」から「AIの実行をどう統治するか」へと移り、人間がすべての判断点に立つ Human in the Loop（HITL）から、ループの外から監督する Human on the Loop（HOTL）へ、という整理も広く語られるようになりました¹。

当ブログの2025年11月公開記事 ラジカルAIプログラミング では、人間は「What」と「Why」の明文化・ビジョン設定に専念し、実装の裁量はAIに委ねるという開発観を提示しました。今回紹介するツール開発は、この思想を企画段階から取り入れ、単一セッションでの開発を超えてマルチエージェントの決定論的ワークフローとして実践してみた試みです。

一方で、こうしたAI統治の議論の多くは、月間数千億トークンを消費するような大規模組織の実践から語られています。本稿はその対極、1名・約1週間で仕上げるツール開発光速イテレーションというミクロな実践から、同じ問いを考えてみる試みです。規模は小さくとも——むしろ小さいからこそ——見えてきた構造があり、それは突き詰めると「統治と委任」、すなわち経営でいう「ガバナンスと権限委譲」という、人間の組織論と地続きの話でした。

何を作っていたか

発端は些細な “思い付き” でした。複数のコード生成AIセッションを並行して使っていると、あるセッションの回答を別のセッションへ転記する作業が地味に面倒で、だったらその転記自体をAIに代行させればいいのでは、と思いついたのが始まりです。実装にはClaude Codeを使っていますが、本稿の主題は汎化できるテーマと考えましたので、以降は単に「コード生成AI」、略してAIと呼びます。

最初は同じモデルの2セッションを向かい合わせ、応答を相互に自動転記するだけのPoCでした。ところがこのAI同士の会話の中で、AI自身が印象的な指摘を返してきます。当時のログから引用します。

AとBは同じベースモデル（重み）を共有しているため、人間の異なるレビュアー同士が持つような認知的多様性はありません。（中略）つまりここでの価値は「思考の多様性」ではなく、役割分担に伴うインターフェースの強制（責務境界・情報の非対称性・確認プロトコルの明文化）から来ていると考えるのが妥当だと思います。

「マルチエージェントの価値は多様性ではなく、情報の非対称性の設計にある」。頼んでもいないのにAIが自分たちの構成の限界を言語化してきたこの指摘は、結果的にこのツール開発全体を貫く設計思想になりました。

これを踏まえ、方向性を「会話を続けるPoC」から「成果物を段階的に引き渡すワークフロー基盤」へ転換しました。機能配置は次の通りです。

• 企画層: 最上位モデルが方針とタスク分解を担当
• 実行層: タスク単位で個別セッションを起動し、実装を担当
• レビュー層: 実行層とは別セッション（別モデル）が成果物を検証
• トリアージ層: 想定外の事態の一次判断を、これも別モデルが担当

さらに、この基盤の開発自体に開発中の基盤を使う、ドッグフーディングの形で開発を進めました。設計・実装・レビュー・指摘対応はAIに任せ、人間が担うのは企画方針の決定と各段階の受入レポートのレビュー・承認のみ。感覚としては、開発会社に外部委託し、提案依頼と受入検収だけを自社で行うイメージ（ふだんは我々がむしろ仕事を受ける側の進め方）に近いものです。

ミクロな実践でも、「統治」の形に収束した

興味深いのは、この構成を統治論から演繹して設計したわけではない、という点です。「人間が介在しなくても自律的に回り続ける仕組み」を素朴に目指した結果として、役割はこう分離されていきました。

大規模組織のAI統治で語られる「ルール定義・適合判定・実行の分離」と、実質的に同じ形です。1名・1週間のミクロなPoCでも同じ構造に行き着いたということは、これは規模の産物ではなく、AIの実行を自律させようとしたときに必然的に要請される構造なのだと考えています。マルチエージェントハーネスの設計論が繰り返し似た形（プランナー／ワーカー／ジャッジ）に収束するのも、同じ力学でしょう。

そして人間の位置は、自然と「ループの中」から「ループの外」へ移りました。HOTLへの移行は、目指して起きたというより、自律化を進めた結果として残った人間の仕事が「企画」と「検収」だった、という順序です。

事故が教えてくれた、統治の解像度

とはいえ、概念図の上で統治が成立していることと、実際に統治が効いていることは別物でした。ドッグフーディング中の事故がそれを教えてくれます。

ルールは「書かれている」だけでは効かない

レビューで差し戻しを出した際、指摘内容を修正担当のAIへ引き継ぐ設計のはずが、実際にはその指摘が再実行時の指示に一切渡っておらず、修正担当が同じ問題を延々と繰り返す状態に陥っていたことがありました。フィードバックループは「存在すること」ではなく「実際に配線されていること」を確認しなければ意味がない——ルールや指摘の伝達経路そのものを検証対象にする必要がある、という教訓です。統治の議論で「ルールの由来や効き方を追跡可能にせよ」と言われるのは、まさにこの問題だと実感を持って理解できました。

AIは自分の足場を壊しうる

「設定ファイル群の記法を新形式に一括変換する」タスクを任せたAIが、変換対象の中に自分自身の実行を支える設定ファイルを含めて書き換えてしまい、以後の処理が「空の設定」を読んで何もせず完了扱いになる、という事故もありました。「自分が今使われている土台には手を出さない」というのは、人間の開発では明文化されない暗黙のルールです。AIへの委任範囲を設計する際は、こうした自己言及が起きる境界を洗い出し、明文化しておく必要があります。

やり直しは安い

一方で、希望の持てる発見もありました。処理量の見積もり超過でタスクが中断した際、実は作業は完了しコミット済みで、同じタスクを再登録するとAIは既存の成果物を認識し、初回よりずっと低いコストで完了まで到達したのです。成果物さえ永続化されていれば、失敗からの再実行は高くつきません。人間の介入なしにAIが走り続けられる度合い——いわばAIの実行密度を支えるのは、高度な制御よりもまず「リトライが安い」構造なのだと学びました。

これは見方を変えると、生成AIの推論も純粋なシステム処理の一つとして捉え、チューニングできるという示唆です。適切なトランザクション制御をあらかじめ設計しておけば、異常系が発生してもデータの完全性は保たれ、冪等な再実行が可能になる——バッチ処理やジョブ設計で積み上げられてきたシステム処理設計のノウハウは、そのままマルチエージェントのフロー設計にも生かせます。AIだからと特別視せず、従来の設計資産を持ち込めることを実感した出来事でした。

論点: 統治の源流に、人間は何を置くべきか

さて、ここからが本稿でいちばん考えたかったことです。

AI統治の議論では、「人間が定義した一次情報（SSOT）と、機械が自動生成した派生データを厳密に区別し、自動生成物を判断の根拠にしない」という原則が語られることがあります。統治の崩壊——出所不明の情報が根拠として増殖していく事態——を防ぐ、という問題意識には全面的に同意します。

ただ、この原則を厳密に適用した未来には、私は懐疑的です。AIの生成物をSSOTに昇格させるため、人間が全量レビューするのだとしたら、人間が処理すべき情報量はHITLと変わらず、律速点がループの中から承認プロセスへ移動しただけになってしまいます。実際、1週間のドッグフーディングで生成された設計書・実装・レビューレポートの総量は、1人の人間が精読できる量をあっさり超えました。ツール開発という、ミクロな実践ですらそうなのです。

では、どう考えるか。推論の源流をたどれば人間の意思・判断があるべきだ、という点は揺るぎません。しかしそこに置くべきは、「目的」に始まり、「方針」や「前提」といったきわめてミニマムな原則だけでよいのではないか。そこからAIが推論し具体化した成果物は——適切な検証を経る前提で——たとえAIの生成物であってもSSOTとして扱ってよいのではないか。これが、今回の実践を通じて私が持った仮説です。

統治と委任 — 人間の組織が、すでに答えを持っている

この仮説は、実は新しい話ではありません。人間の組織が何百年もやってきた「統治と委任」そのものです。

最終承認者が経営者であるようなプロジェクトを考えてみてください。経営者がすべての成果物を自らレビューするのは不可能です。実際には、信頼できる部門のメンバーに確認させ、その報告——つまり要約と解釈——をインプットとして承認します。統治は「全量を自分で見る」ことではなく、「信頼できる検証構造を設計し、読める粒度の報告を受け、権限を適切に委任する」ことで成立してきました。

同じ設計がAIの統治にも適用できるはずです。今回の実践でいえば、レビュー層に敵対的検証の役割を与える——実装担当とは別のモデルに「この成果物の欠陥を探せ」という立場で確認・サマリをさせる——ことで、経営者が受け取る「信頼できる部下の報告」に相当するものを作れます。人間はその報告を読んで承認する。これは「ちゃんと読まずに承認」とは違います。読める分量に凝縮された、検証済みの報告を読んで承認するのです。

もちろん、委任には設計が要ります。承認が形骸化したとき実害を被るのは人間であり、それを防ぐ責務も人間にあります。だからこそ、すべてを同じ重さで承認するのではなく、リスクレベルに応じて承認権限をAIに委任する／しないを切り分けることが重要になります。本番環境に触れる変更は人間が握り、開発環境内で完結する中間成果物はAIの相互検証に委ねる、といった具合です。これも人間の組織における職務権限規程と、考え方は何も変わりません。

これからのマルチエージェント開発

最後に、今回の実践から見えた気づき・見通しを3点にまとめます。

1. 伝送路はコモディティ化し、価値は統治層へ移る。 今回自作したセッション間の転記機構のようなものは、すでに公式機能として整備が始まっており²、いずれ「作る」ものではなく「使う」ものになります。残るのは「何を、どのタイミングで、誰（どの役割・どのモデル）に渡し、何を渡さないか」という情報の非対称性の設計——すなわち統治と委任の設計です。競争力の源泉、つまり差別化要素はここに移っていくと見ています。

2. 統治は「配線の検証」から始まる。 ルールを書くこと、フィードバックループを設計図に描くことは出発点にすぎません。それが実際に効いているか——指摘は次の実行に渡っているか、AIが自分の足場に触れない境界は機能しているか——を検証する仕組みまで含めて、はじめて統治と呼べます。ミクロな実践でも、事故はすべて「書かれていたが、配線されていなかった」場所で起きました。

3. HOTLは大規模開発特有のものではない。 1名・1週間のツール開発でも、観測手段（コックピット）と受入ゲートさえ用意すれば、人間がループの外から統治する体制は成立しました。むしろ小さく始めて、自分の手元の小規模開発で「統治の事故」を安全に経験しておくことが、来たるべき大規模なマルチエージェント開発への最良の準備になると感じています。

おわりに — 生成AIと人間のチームワークの追求

コピペ代行の思いつきから始まった1週間は、最終的に「AIをどこまで信じ、何を委ねるか」という問いに行き着きました。

生成AIの出力をすべて疑い、全量を人間が確認する道は、安全に見えて、実際にはAIの能力を人間の処理能力の枠内に閉じ込める道です。逆にすべてを盲信する道は、統治の崩壊に至ります。その間にある道——源流にミニマムな人間の意思を置き、検証構造を設計した上で、抽象レベルの意思入れと結果の確認・承認によって協調する道——を探ることが、マルチエージェント開発の本題になっていくのだと思います。

人間の組織が「統治と委任」のバランスで成果を出してきたように、生成AIとの間にも同様のバランスは設計できる。それを信じられるだけの手応えが、今回のミクロな実践にはありました。