AIエージェントのアムダールの法則

マルチエージェントシステムは実際に成果を上げている。ジェフリー・ハントリーのRalph Loopは、全てのPRD項目が完了するまで自律コーディングエージェントをwhileループで実行する。スティーブ・イェッグのGas Townは、7つの専門役割にわたって20～30の同時エージェントを調整する。Cursorは8エージェント並列システムを出荷している。スループットの向上は現実のものだ。そして、最も効果を上げているチームには共通のパターンがある。

しかし、その向上は自動的には起こらない。Flaskの作成者アルミン・ロナッハーは『The Pragmatic Engineer』にこう語っている。「並列エージェントを起動することもあるが、以前ほどではない。問題は、私の頭ではレビューできる量に限りがあるということだ！」最も価値を引き出しているチームはあるパターンを共有しており、1967年の法則がそのてこの所在を正確に説明している。

**オリジナルの洞察**

1967年、ジーン・アムダールは並列計算について単純な観察を行った。プログラムの高速化は、逐次的に実行しなければならない部分によって制限される。彼の公式：speedup = 1 / (S + (1-S)/N)。ここでSは逐次部分、Nは並列プロセッサ数である。重要な洞察は公式そのものではなく、その限界にある。Nが無限大に近づくにつれ、高速化は1/Sに収束する。作業の10%が本質的に逐次的なら、10倍以上の高速化は決して達成できない。100コアでも、100万コアでもだ。これは並列性への反論ではなく、集中すべき工学上の指針だった。同じ論理がエージェントにも当てはまる。

**エージェント版**

AIエージェントの同等の法則：AIエージェントによる最大高速化は1/Hに制限される。ここでHは人間の判断を必要とするワークフローの割合である。Hには、意図の明確化、判断、レビューサイクル、承認ゲート、あいまいさの解決、センスの適用など、システムが人間を待つすべての瞬間が含まれる。Hが総ワークフロー時間の40%を占めるなら、エージェント能力のいかなる向上も2.5倍以上の高速化をもたらさない。50%なら上限は2倍。楽観的な20%でもせいぜい5倍だ。

人間割合Hが高速化の式を支配し、エージェント能力ではない。しかし、アムダールの元の逐次部分S（アルゴリズムの固定特性）とは異なり、Hは静的ではない。優れたモデルはHの一部の構成要素を縮小する。明確化や検証が少なくて済むエージェントは直接的に人間の時間を減らす。問題は、モデルが減らす構成要素は、大規模になると支配的ではなくなるということだ。モデルの改良は明確化と検証を減らす。センスと新しい決定——機械的な部分を自動化した後に支配的になる構成要素——は、より優れたモデルではほとんど削減できない。これらの上限はどの時点でも現実のものだ。重要なのは、Hがどの速さで減少しているか、そしてその利益をどう活用するかである。

**自己流動化H**

最大のてこ入れはエージェントをより速く、より賢くすることではない。Hの性質を変えることだ。そのためのツールは新しいものではない——テスト、仕様、自動化、文書化された決定。これらは何十年も存在してきたエンジニアリングのベストプラクティスだ。新しいのは投資収益率である。エンコードされた決定すべてに対してエージェントが自律的に行動できるようになれば、そのテストを書いたり仕様を更新したりする見返りは以前よりはるかに高くなる。目標は人間の関与を最小化することではない。それを自己流動化することだ：人間の介入は毎回、同じタイプの介入を次回不要にする成果物——テスト、仕様更新、文書化された決定——を生み出すべきである。（この用語は金融に由来する：自己流動化ローンは返済する収入を生み出す。自己流動化的介入は、それ自体の再発を排除する成果物を生み出す。）

ワークフロー時間の40%が人間で、それがすべてセンスと戦略に使われるチームと、40%が人間でそれがすべて「XとYのどちらを意味している？」「この出力を再確認しよう」に使われるチームでは、立場が根本的に異なる。自己流動化プラクティスは後者を前者に変換する。

これには私が構成（コンフィギュランジー）と呼ぶものが必要である——境界のあるエージェントがシステムを安全に変更し、不変条件を再発見しなくて済むようにするための、最小限の明示的な行動の約束（とその根拠）のセット。仕様、適合スイート（仕様に対する動作を検証する自動テストスイート）、文書化された根拠。システム内の暗黙の前提はすべて、将来の人間のブロックイベントである。

人間のレビューを不要にする適合スイートは結晶化された認知である——正しさに関する人間の判断を、行われた時点でエンコードし、エージェントが再発見しなくて済むようにする。既知の落とし穴にエージェントが陥るのを防ぐAGENTS.mdファイルも同じことだ。優れた足場はすべて、人間の判断を永続的で機械可読な成果物として捉えたものである。

どの人間の関与をターゲットにするべきか？テストは具体的だ：「この介入はエンコード可能か？」人間がバグを発見したとき、その発見はテストケースになるか？人間があいまいさを明確にしたとき、その明確化は仕様を更新するか？人間がセンスの判断を下したとき、その判断は文書化された先例になるか？エージェントが同じタイプの人間の介入を繰り返し必要とするなら、あなたの構成は不完全である。

検証は高度にエンコード可能——発見はテストケースになる。明確化も高度にエンコード可能——解決策は仕様更新になる。仕様は部分的にエンコード可能——パターンは再利用可能なテンプレートになる。センスと新しい決定は最もエンコードが難しい——それは問題ない、なぜならそれらは人間の判断が真に価値を生む構成要素だからである。システムは自然に、人間がエンコードできない仕事だけをする状態に収束する。なぜならエンコード可能なものはすべてエンコードされているからだ。

しかし、単に捕捉するだけでは不十分だ。すべての介入を無造作に追加すると、独自の問題が生じる——矛盾する落とし穴が400行もある誰も読まないAGENTS.md、矛盾する仮定をエンコードする重複したテストケースのスイート。生の蓄積はノイズを生み、知識を生まない。真のパターンは蓄積してから圧縮することだ：個々の判断が積み重なり、定期的に首尾一貫した高レベルの成果物に統合される。コモンローはケース判断を蓄積し、それを原則や法規に統合する。科学は論文を蓄積し、レビュー記事や教科書に圧縮する。実践としては、各介入をローカルな成果物（テストケース、AGENTS.mdエントリ、決定記録）として捕捉し、それらを定期的に更新された仕様、リファクタリングされたテストスイート、改訂されたスキル定義に統合する。圧縮とは、支配的な変数自体がまだ正しいかどうかを問うことである——ある仮定の40のバリエーションをエンコードした40のテストケースが、その仮定が間違っていることを明らかにするかもしれない。蓄積だけのチームはドリフトと矛盾に行き着く。圧縮だけを試みるチームは事前に過剰エンジニアリングすることになる。サイクルは両方を必要とする。

自己流動化サイクルを実用的にする2つのレバー：

1. シグナルを捕捉する。人間が介入するとき——バグを発見する、仕様を明確にする、センスの判断を下す——システムはその介入をエンコードする成果物を生成すべきである。バグを発見したがテストスイートを更新しないレビューは無駄なシグナルである。仕様を更新しない明確化は繰り返されるだろう。

1. 高い構成を維持し、他の場所ではエージェントが自律的に動作できるようにする。システムの知識が明示的であるとき——仕様、不変条件、適合スイート、文書化された根拠——エージェントは事前にエンコードできたはずのことで人間をブロックしない。エージェント足場はAI時代の逐次コード最適化である。それは人間の時間を最大のてこがある場所に集中させ、すべての介入からのシグナルをシステムが再利用できる永続的な知識として捕捉する。

**足場の実際**

ElectricSQLでは、エージェントが最近、プロトコル変更を67ファイル（仕様、2つのサーバー実装、10言語の10クライアントライブラリ）に20～30分で伝播させた。人間は67ファイルをレビューしなかった。適合スイートがレビューなのだ。それがなければ、10言語にわたる入念な手動検証に何時間もかかる。それがあれば、PRのレビューに数分しかかからなかった。人間がプロトコル変更を設計し、スイートが下流のすべてを自動化した。そして正しさに関する新しい決定はすべて別のテストケースとなり、次の変更をさらに自律的にする。

エミール・ステンストロームは、最初からhtml5lib-tests適合スイートを組み込むことで、エージェントを使って完全なHTML5パーサーを構築した。その後、サイモン・ウィリソンが別のエージェントを同じスイートに向けることで、4.5時間でJavaScriptに移植した。適合スイートは人間のレビューを不要にした。なぜなら仕様が実行可能な検証としてすでにエンコードされていたからだ。

モデルがタスクを処理し、構成が信頼を扱う。両者が一緒に複利効果を生む。

エージェントの展開を「モデルを選んでプロンプトを書く」だけと考えるチームはすぐに頭打ちになる。彼らはHに手をつけていない。真の加速を目にしているチームは足場層に多大な投資をしており、多くの場合、エージェント統合自体よりも構成により多くのエンジニアリングリソースを費やしている。

**ボトルネックを超えてのスケーリング**

エージェントが高速化するにつれ、Hが増大しているように感じられる。エージェントがトピックを調査するのに2時間かかり、その出力をレビューするのに30分かかる場合、その30分は背景ノイズだった。エージェントが30秒で終わり、それでもレビューに30分かかる場合、突然あなたがボトルネックになる。絶対時間は変わっていないが、相対的な重みは劇的に変化した。あなたはもはや待つことはない——つまり、あなたが常に待たれる側になったということだ。

そしてさらにエージェントを追加すれば、状況は悪化する。

アムダールの法則は上限があることを教える。ドナルド・レイナートセンの『製品開発フローの原理』は工学上の問題がどこにあるかを示している：ナイーブに並列エージェントを追加するとパフォーマンスが低下する可能性があるが、修正は扱いやすい。

レイナートセンは待ち行列理論を製品開発に適用し、容量利用率が指数関数的に待ち行列サイズを増加させることを示した。利用率50%では待ち行列は管理可能。80%では4倍大きくなる。90%では9倍。95%では19倍。エージェントの出力をレビューする人間は待ち行列の中の単一サーバーである。5つの並列エージェントは到着率を5倍にし、利用率を100%に近づけ、待ち時間を無限大に向かわせる。

Gas Townが最も鮮明な例である。イェッグは、20～30のエージェントが理解できない速度で同時に実行される「明らかなストレス」を描写する。初期ユーザーは自分の役割を「タマゴッチを生かし続けること」と表現し、「管理範囲は注意力と記憶力に直接相関する」と指摘する。あるユーザーは3時間で5件のPRから4時間で36件のPRへと移行したが、Claudeトークンに1時間100ドル、そして強烈で途切れない認知投入を伴っていた。スループットは現実だが、人間の待ち行列飽和も現実である。

レイナートセンの処方箋：利用率を最大化するのではなく、待ち行列サイズを直接管理すること——仕掛品制限、小さいバッチサイズ、より速いフィードバックループ。エージェント版：並列エージェントをスケールする方法は、そもそも人間をブロックする摩擦を排除すること——エージェントが自身の作業を検証できるようにする構成に投資し、人間が必要な時は本当に重要な判断のためだけにする。

Ralph Loopはこれを正しく行っている。成功しているのはエージェントを並列実行しているからではなく、自己流動化エンジンだからだ：明確に定義されたPRDを仕様とし、自動テスト検証を合格基準とし、反復をまたいで発見されたパターンを蓄積するAGENTS.mdファイル。人間がエージェントを修正する各反復は、その修正を次回の反復が消費できる成果物としてエンコードする。同じパターンがすべての規模で現れる。shadcnは/doneの実行について説明している