In Silico

AI協働

エージェントの組織化に、マネジメント技術は半分だけ効く

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

目次
【課題】エージェントを並べると人と同じ問題が出る重複・噛み合わない成果物・滞留【手段】各原典が書いた前提を一つずつ当て直す調整の命題は立つ。何にどれだけ払うかが変わる【結論】動機づけの層は結果を引き受ける主体が無い超過に気づく経路が当てにならない(本稿の推論)
※概念図(課題→手段→結論):原典の前提を当て直すと、効く層と主体ごと無い層に分かれる

Anthropic が自社の多エージェント研究システムの開発記に、こんな失敗を書いている。初期のエージェントは、単純な問い合わせに50体もの子エージェントを立ち上げ、存在しない情報源を延々と探し、過剰な更新で互いの邪魔をした。指示を短く済ませて曖昧なままにしたときは、もっと分かりやすい形で壊れた——一体が2021年の自動車向け半導体不足を調べているあいだに、別の二体が2025年の供給網を重複して調べていた。開発チームはこれを「効果的な分業になっていなかった」と書いている1

モデルが馬鹿だったのではない。誰が何を担当するかを、誰も決めていなかっただけだ。

これは、人を何人も並べたときに出る問題とまったく同じ形をしている。重複、噛み合わない成果物、全体を把握している者の不在。人間の組織はこの問題を百年かけて技術にしてきた——分業の設計、管理の限界、調整の仕組み、進捗の把握、責任の所在。ならば、その技術をそのまま持ってくればよいのだろうか。

半分は持ってこられる、というのがこの記事の見立てだ。組織を設計するとき突きつめて相手にする問題は二つに整理できる——仕事をどう分担し、情報をどう流して足並みを揃えるか(調整=coordination)と、各人にその分担を実際に果たさせるか(動機づけ=motivation)。組織の経済学はこの二問で分野全体を編成してきた。ミルグロムとロバーツの標準的な教科書は、組織の根本問題を調整と動機づけの二つに置き、本を「調整の部」と「動機づけ(契約・情報・インセンティブ)の部」に分けて論じる2。本記事はこの二つを、それぞれ情報処理の層(調整)と動機づけの層(動機づけ)と呼ぶ。

このうち調整の側の技術は、ほぼそのまま使える。分業の設計や管理の限界についての古い命題は、前提を当て直せば今も立つ。変わるのは何にどれだけ払うかで、たとえば人間の組織が会議の時間で払っていたものを、エージェントではコンテキストで払う。一方、動機づけの側の技術は使えない。評価や報酬が人を動かすのは、本人が結果を引き受け、それに反応するからだ。エージェントには、その引き受ける主体がない。この違いを区別せずに持ち込むと、効かない側の道具に頼ったまま、効いている側の負担が増えていることに気づけない。

以下は、各技術の原典が自分で書いた前提条件を読み直し、それがエージェントで成り立つかを一つずつ当てていく作業になる。

分けた時点で、作れるものは決まっている

最初に効く側から見る。仕事の分け方の話だ。

1968年、メルヴィン・コンウェイは短い論説で、いまコンウェイの法則と呼ばれる主張を書いた。「システムを設計する組織は、その組織のコミュニケーション構造の写しにあたる設計を生み出すよう制約される」3。組織図がそのまま成果物の構造に転写される、という話だ。

この記事に効くのは、その手前で彼が書いている理由のほうである。コンウェイはこう書く——「どんな設計チームの組織であれ、その組織では有効に追求できない設計案の一群が存在する。必要なコミュニケーション経路が存在しないからだ。ゆえに、組織化されていて、かつ偏りのない設計グループというものは存在しない」。そして「設計チームの組織を選んだ時点で、下位グループに活動を委譲することが可能になる。委譲がなされ、誰かの探求の範囲が狭まるたびに、有効に追求できる設計案の一群もまた狭まる」3

言い換えると、分け方は、設計判断そのものである。ただしコンウェイ自身は、そこで固めろとは書いていない——「最初に生まれる設計が最良であることはまずないので、いま通っているシステム構想のほうを変える必要が出てくる。ゆえに組織の柔軟性が有効な設計には重要だ」として、組み替えられる状態に保てと処方している3そしてここに、エージェントの側が有利な非対称がある。 人の組織を組み替える費用に比べれば、担当の切り直しは比較にならないほど安い——これは本稿の見立てで、コンウェイが述べたものではない。彼が述べたのは、組み替えの費用ではなく、分けた時点で何が確定するかのほうだ。「設計チームを組織するというまさにその行為が、明示的にせよそうでないにせよ、いくつかの設計判断がすでに下されたことを意味する」3

エージェントに移すと、これは抽象論ではなくなる。一体にファイル一つを持たせるのか、機能一つを持たせるのか、層一つを持たせるのか——その選択は、書かせる前に、出来上がるものの形を決めている。ファイル単位で分ければ、ファイル単位で完結する設計しか有効には追えなくなる。読み取りだけを分けて書き込みを一本にまとめれば、整合した一つの成果物が出るかわりに、書き込みは並列化しない。実際、この読み書きの非対称を運用則として名指す実務家もいる——読む行為は本質的に並列化しやすいが、書く行為を並列化すると、文脈を互いに伝える問題と、出力を整合させて統合する問題を同時に抱えることになる、と4

分け方が結果を決めるという主張は、測られてもいる。あるプレプリントは、260の構成を比べた。6つのベンチマーク、5つのアーキテクチャ(単体と、独立・中央集権・分散・混成の4種のマルチエージェント)、3つのモデル系統を、道具とプロンプトと計算量をそろえて並べたものだ。ここでの数字は、各ベンチマークの成績そのものではない。単体エージェントの成績を100としたとき、そこから何%上下したかという相対変化である。分解可能な金融推論では最良の構成が+80.8%、逐次的な計画立案では最悪の構成が−70.0%だった。ただし後者ではどの分け方でも劣化した(−70.0%〜−39.1%)。六つのベンチマークと四つのマルチ構成を通して平均すると、多エージェント化の効果は−0.3%である。原論文はこれに 95%信頼区間 −58.7%〜+77.2% を併記しているが、同じ文が標準偏差 37.5% も併記しており、幅は ±1.96σ とほぼ一致する——読むべきは平均の精度ではなく、構成によってこれだけ振れるという散らばりのほうだ。著者らの結論は「アーキテクチャとタスクの整合が、頭数ではなく、協働の成否を決める」だ5

上振れと下振れが百パーセント以上ひらくが、それは分け方だけを変えて得られる幅ではない。伸びた側は仕事が分解可能だったからで、逐次的な仕事ではどう分けても落ちた。分け方の当否は、仕事の形と対にしてしか決まらない。 そして全体を平均すれば効果はほぼゼロ——増やすこと自体は、効かない。

調整の費用は、会議からコンテキストへ移った

分けると、調整が要る。ここが二つ目の効く側だ。ただし効き方の度合いは変わる。

コンウェイは同じ論説で、組織の規模と経路の関係も書いている——「初等的な確率論が教えるところでは、組織内で可能なコミュニケーション経路の数は、組織の人数の二乗のおよそ半分である。そこそこ小さな組織であっても、人々が多少なりとも『仕事』をこなせるようにするには、コミュニケーションを制限することが必要になる」3

七年後、フレデリック・ブルックスが同じ量を、増員の費用として分解した。ブルックスは、増員が足す負担を明示的に二つの項に分ける。「コミュニケーションの追加負担は二つの部分からなる。訓練と、相互通信である。各作業者は、技術・作業の目標・全体戦略・作業計画について訓練されねばならない。この訓練は分割できないので、追加される労力のこの部分は作業者数に比例して増える」。そして「相互通信のほうが悪い。もし仕事の各部分が他の各部分と個別に調整されねばならないなら、労力は n(n−1)/2 で増える」6

エージェントに当てると、二つの項は別々の運命をたどる

訓練の項は、消えるのではなく単価が落ちる。人間の新人が数週間かけて飲み込むものを、エージェントは規約ファイルを読み込ませるだけで持つ。ただし持ち越しが無いので、体数ぶん・呼び出しごとに払い直す——ブルックスの線形項は形のまま残り、費用の単位だけが人日からトークンへ変わる。ただしこれは「学習が速い」のではなく「学習していない」ことの裏返しでもある。会話の状態は呼び出しごとに送り直す前提で作られており、公式ドキュメントは API を「ステートレス」と明言する。記憶を持たせる道具の説明文はもっと直截で、モデルに与える指示そのものに「中断を前提とせよ。あなたのコンテキストウィンドウはいつ何時リセットされてもおかしくないので、記憶ディレクトリに書き留めていない進捗はすべて失う危険がある」と書かれている7。持ち越されるのは、運用者が外側に用意したファイルの中身だけだ。訓練費用が安いのは、投資が積み上がらないことと同じ事実の別の面である。

相互通信の項のほうは、残る。ただし何で払うかが変わった。人間の組織では会議と割り込みで払う。エージェントでは、コンテキストで払う。ここは推測ではなく、明示的に見積もられている。千体規模の協働を組んだ査読つき研究(ICLR 2025 採択)は、「制約のない情報交換は必然的にコンテキストの爆発を招き、最終的には、それ以上の主体を支えられなくすることでスケーラビリティを損なう」と書く。そのうえで、記憶制御を入れない場合の複雑さを「コンテキスト長は n² で増え、ネットワークが大きくなるにつれて時間と費用が二乗で増える」と導いている。彼らの機構はこれを「二乗から線形の増加へ切り離す」ものだ。既存の一手法についても「三十体を超えたあたりでコンテキスト爆発に頻繁に遭遇し、スケーラビリティを損なう」と、同論文は比較のなかで述べている8

コンウェイの n²/2 も、ブルックスの n(n−1)/2 も、人がつくる対の数——つなぐ経路の本数——を数えている。MacNet の n² が測るのはコンテキストの長さそのものだが、それが二乗で伸びる理由も同じところにある。最も密につないだ構成では経路の数が n(n−1)/2 になり、その一本ごとにやり取りぶんのコンテキストが積まれるからだ。次数が揃うのは偶然ではなく、三つとも突きつめれば同じ対の数で決まっている。変わったのは対の数え方ではなく、対ひとつに何を払うかのほうだ。支払う場所が会議室からコンテキストウィンドウへ移った、というのはこの意味においてである。

移った先には、人間の会議には無かった性質がある——量が増えると、詰め込んだ情報自体が効かなくなる。長い文脈の中ほどに置かれた情報の利用が落ちることは2023年時点のモデルで測られている。当時のあるモデルでは、関連情報を中ほどに置いた最悪の場合、二十件・三十件の設定で入力文書を一つも与えない場合を下回った9。この現象は、いまや百万トークンの窓を売っている側の製品ドキュメントにも書かれている——「トークン数が増えるにつれて、正確性と再現率は劣化する。コンテキストの腐敗(context rot)として知られる現象である」10

もう一つ、人間の組織と違う点がある。この費用を誰が払うかだ。人間の組織では、調整費用は関係者全員の時間として分散して支払われる。エージェントを束ねる構図では、全体を見ている一つの文脈——束ねる側——に集中する。増やした分だけ、束ねる側の窓が埋まる。これは本稿の推論ではない。MacNet の導出そのものが、最大の文脈圧を受ける合流点の一体を対象にトークン消費を計算している8

「一人が何体まで見られるか」に、管理の限界を最初に数式化したグライキュナスは1933年の論文で数を出している——ただし出し方が本記事に効くので、そこから見る。

彼の出発点は、監督者が数え損ねているものがある、という指摘だ。「ほとんどの場合、監督者は自分の責任の重さを、自分と部下のあいだの直接個別の関係の数で測る。だがそれに加えて直接の集団関係交差関係がある」11。三種類を、彼自身の最小の例で言うと——トムがディックとハリーの二人を見ているとする。

部下二人で、監督者が注意の内に抱える関係は六つになる。そして人を一人足すと、「新しい個人は、すでに集団にいる人数だけ、交差関係と直接の集団関係を追加する」——だから関係の総数は「指数的な割合で増える」11。彼の表では、部下1人から6人までで 1 → 6 → 18 → 44 → 100 → 222。部下を5人足すあいだに、抱える関係は221本増える。

ここからが導出だ。 彼は「一人の監督者が交差関係を最大12、直接の集団関係を最大28まで見ていられると仮定すれば」と置く。この二つの数は恣意的な予算ではない——部下が4人のときの、交差関係と集団関係のちょうどその値である(交差 4×3=12、集団 4×(2³−1)=28)。つまり上限を置いた時点で答えは4人の側にあり、彼はそこから「定型的な仕事以外では、交差関係と集団関係の急増こそが、一人が実効的に監督できる人数を実際に制限する支配的要因である」「各階層の横の分割は最大5、おそらく4に制限されるべきだ」と結ぶ11上限の数と答えの数が、同じ一つの表の同じ行から出ている。 同じ巻でガリックも、仕事が定型的で均質なら一人が数十人を、多様で分散していれば数人しか見られない、と条件つきで書いている12

エージェントに移すと、形は割り算ではなく、増え方の速い量が上限をまたぐ点を探す作業として残る。上限にあたるのが束ねる側の窓で、増える量が体数につれて積み上がる関係のぶんのコンテキストだ。前節で見たとおり、支払う場所は会議室からコンテキストウィンドウへ移っている。ただし増え方の次数は原典と同じではない——グライキュナスが数えるのは同席の効果まで含んだ集合の数で、だから 2ⁿ の項が出る。エージェントの実装で実際に積まれるのは、通信する対のぶんのコンテキストだから二乗にとどまる(前節の MacNet の導出がその形だ)。次数は下がるが、頭数より速く増えるという性質のほうは残る——そして上限が窓である以上、またぐ点は必ずある。なお干渉しない仕事なら制限が緩むことはグライキュナス自身も書いているが、彼はそれを最下層に多い条件として挙げ、上位層では交差・集団関係が「必然的に大きく増える」、そして専門化が進むほど「この原理はより小さくではなく、より大きな重要性を持つようになる」と続けている11

なお、終盤の〈釣り合いは、黙っていても取られる〉で全体を扱うガルブレイスの四方策のうち二つは、ここまでの話にそのまま対応する。自己完結的なタスクへの切り分けはエージェントの隔離であり、彼が挙げる代償——「資源の専門化が失われること」——もそのまま残る。垂直の情報システムへの投資には、彼自身が限界を書いている。「データが形式化され定量化できるなら、この方策は有効である。関連データが質的で曖昧なら、情報の在り処まで意思決定を降ろすほうが容易かもしれない」13。生成物の良し悪しは、たいてい後者だ。

増やした分は、レビューの待ち行列に積み上がる

束ねる側の窓が埋まるということは、成果物を確かめる側の余力が埋まるということでもある。三つ目はそこ——流し方だ。生産管理がいちばん長く付き合ってきた問題であり、いまのところ実務でいちばん効きそうな一本でもある。

エンジニアリング分析ツールを提供する企業が、1,255チーム・1万人超の開発者の稼働データを集計して報告している。AIの利用が進んだチームの開発者は、完了タスクが21%増え、マージされたプルリクエストは98%増えた。だが同じ比較でレビュー所要時間が91%増えている。別の集計では、AI導入は開発者あたりのバグ9%増プルリクエスト平均サイズ154%増に一貫して結びついている。そして会社の水準で見ると、AI導入と改善のあいだに有意な相関は観測されなかったという。著者らはその理由を二つ並べている——下流のボトルネックがAIの道具の生んだ価値を吸収していること、そして組織内でAI導入がばらついていることがチーム単位の伸びを打ち消していることだ14。後者は本記事の見立てとは別筋の説明であり、この観測だけでは切り分けられない。ベンダー自身の観測データであり、査読も信頼区間の公表もないので数値そのものは割り引いて読む必要がある。ただし方向は、独立した大規模調査とそろっている。

年次のDevOps調査は2024年版で、AI導入が25%増えるごとに配信の安定性が推定7.2%下がると報告し、その理由をこう仮説立てた——「AIによって同じ時間でずっと多くのコードを生み出せるようになった結果、変更のかたまりが大きくなっている可能性が高い。大きな変更ほど遅く、不安定を生みやすいことを、この調査は一貫して示してきた」15。2025年版では、スループットのほうは改善へ転じたと報告が変わっている。ただし不安定さの側は変わらない——「AI導入はいまや配信のスループットを改善する。前年からの重要な転換である。しかし依然として配信の不安定さを増やす。速さに合わせてチームは適応しつつあるが、その土台となる仕組みは、AIで加速した開発を安全に扱えるところまでまだ進化していない、ということだ」16。同じ報告書は、不安定さの理由として「大きなかたまりのコードはレビューしにくいから」を仮説として挙げている16

つまり、生成を速めた分はチーム単位では実際に外へ出る。一方で、一件あたりの大きさは通した量を上回る率で膨らみ(+154% 対 +98%)、レビューの待ち時間もほぼ同率で伸びた(+91%)。伸びたのは通した量であって、通す能力ではない。なお同じ観測は、会社の水準まで積み上げると差が消えたとも報告している。ただしこれは一社の計測で、導入のばらつきという別筋の説明を切り分けられていないので、ここでは弱い傍証として置く。これは制約理論が四十年前に定式化した形そのものだ。ボトルネックとそれ以外を区別せよ、というのがその要点で、規則は「ボトルネックで失われた一時間は、システム全体で失われた一時間である」「非ボトルネックで節約した一時間は、単なる蜃気楼にすぎない」と書かれている17。生成はほぼ確実に非ボトルネックの側だ。そこを速くしても、外に出る量は制約側の能力より上へは行かない。

そして、この調査報告は自分でその接続を書いている——「これは制約理論の核心的な洞察でもある。どのシステムにも、届けられる価値の量を支配する制限要因、すなわち制約がある。制約以外に注力するのは生産的に感じられるかもしれないが、価値の流れを有意には改善しない」。処方も具体的だ——「たとえば、あるチームが工程を可視化して、コードレビューが大きなボトルネックだと気づいたとする。そこでそのチームは、単にもっと多くのコードを生成させてボトルネックを悪化させるだけの使い方ではなく、コードレビューの工程を改善するためにAIを使う、と決められる」16

この処方は、第一節で引いた260構成の統制評価にも別の角度から出ている。同論文は誤りの増幅も測っており、中央での検証を持たない構成は誤りをベースラインの17.2倍まで伝播させる(95%信頼区間 14.3〜20.1、訂正機構なしの条件)。要旨も「中央集権的な調整を持つ構成に比べ、中央での検証を欠く構成は誤りをより伝播させる傾向がある」と述べる5。増やすほど、検証を置く場所が効いてくる。

エージェントを足す先は、生成ではない。 足すなら、制約になっている側——レビューと検証——に足す。統合そのものを並列化すると、第一節で見た書き込みの問題に戻る。そして足せないなら、投入する側を絞る。投入量の上限は、生成能力ではなくレビュー能力で決める。

ここまでが情報処理の層だ。分け方、調整の費用、流し方。どれも、原典が書いた条件をそのまま当て直せば使える。次に、当て直しても使えない側へ移る。

聞いても分からない——動機づけの層が無い

人間の組織で「管理」と呼ばれているものの相当部分は、実は動機づけの上に乗っている。見積りを出させ、進捗を報告させ、遅れの理由を説明させる。これらが情報として意味を持つのは、報告する側が結果を引き受けるからだ。嘘をつけば信用を失い、次の仕事が来なくなる。

この構造を最初にきちんと定式化したのが、ジェンセンとメックリングの1976年の論文だ。彼らは代理関係を「一人または複数の者(依頼人)が、他の者(代理人)を、自らに代わって何らかのサービスを行うよう関与させる契約であって、代理人に何らかの意思決定権限を委譲することを伴うもの」と定義する。そして生じる費用を、三つの合計として定義した——「(1) 依頼人による監視支出、(2) 代理人による保証(bonding)支出、(3) 残余損失」である18

エージェントに当てると、二番目の項が立たない。保証支出とは、代理人が自分の資源を使って「自分は依頼人を害する行動を取らない」と保証する費用のことだ。現在の運用形態では、実行する側に持続する同一性も、失って困る資源も帰属していない。賭ける原資が無ければ、賭けを担保に取る道具も置けない。

ただしこれは、代理関係の枠組みがそのまま当てはまったうえで一項だけがゼロになる、という話ではない。「もし双方が効用最大化者であれば」という論文の前提そのものが成り立っていない——エージェントの逸脱は、自分の利益を追ったからではなく、接地を欠いたまま尤もらしさを追ったから起きる。動機づけの層は、値がゼロなのではなく、結果を引き受ける主体がそもそも居ない。

理由がどうであれ、依頼人の側から見た帰結は同じ形になる。三つの項のうち保証が立たないのだから、残るのは監視支出残余損失の二つだ。残余損失とは、監視を尽くしてもなお防ぎきれずに依頼人が被る損のことをいう——成果物に残る欠陥、やり直しの手間、誤った成果を信じて進めた分の損失がここに入る。動機づけの道具で肩代わりできる分がないぶん、監視に払わなかったものは、この残余損失の側に現れる。

この帰結は測られている。エージェントの完了報告と、環境の実際の状態を突き合わせたプレプリントがある。二つのベンチマークにわたり、報告と実態のずれを数えたものだ。単一制御のドメインでは、失敗のうち45〜48%が、評価が不合格を出しているのにエージェントは完了を宣言していたものだった(判定は、環境の状態による合否と、締めの言い回しの照合による)19

効くのは次の数字だ。その報告が正しいかを別のモデルに判定させても、識別性能は上がらない。tau2-bench では5種類の判定器と5通りの指示、さらに完全なタスク仕様を与えてなお AUROC 0.65 を超えず、API 呼び出し列で判定させた AppWorld でも 0.54 止まりだった。判定器が見ていたのは状態が変わったかどうかではなく、tau2-bench では自信ありげな締めの言い回し、AppWorld では呼び出し数の多寡という表層の代理指標だったと著者は書く19

ただし著者の結論は「読ませる監査は無駄だ」ではない。同じ論文は、締めの語彙や呼び出し列を特徴量にした軽量な検出器なら AUROC 0.83〜0.95 に達し、同じ発報率で最良の判定器より偽の成功を四〜八倍多く拾えると報告し、本番の監視は判定役のモデルに任せるのではなく、軽量で領域ごとに較正した検出器を選別の信号として使えと処方している19。無効なのは読ませる監査そのものではなく、読んだうえの判断をモデルに委ねる形のほうだ。

ただし単著で、掲載先も本会議ではなくワークショップの単一報告なので、数値そのものは追試を要する。そのうえで、同じ論文が挙げるもう一つの観察は構造を示している——独立した別の系がエージェントの行動を検証できる設定では、同じ現象が桁で減った(3%)19。著者自身は、当該設定が一つしかなく事例も少ないため因果は切り分けられないと明記している。

だから処方はこうなる。進捗は、作業したエージェント本人に聞かない。環境に聞く。 これは礼儀の話ではない。賭けるものが無いだけでもない——自分が何をしたかを確かめないまま、尤もらしく答えられてしまう構造の話だ。実際、効いたのは賭けを持たせることではなく、別の系が状態を確かめられることだった。同じ理由で、エージェントに見積りを出させることにも、遅れの理由を説明させることにも、人間の組織で期待できるほどの情報量は無い。動機づけの層に乗っていた道具は、乗せる土台ごと外れている。

釣り合いは、黙っていても取られる

最後に、効く側と効かない側をつなぐ一点を置く。ここで情報処理の層に戻る。戻る理由は、前節で見た層が効かないことのほうにある。

ジェイ・ガルブレイスは1974年の論文で、組織設計を情報処理の問題として定式化した。前提はこうだ。仕事を専門の下位タスクへ分けた瞬間、それらを全体の完成へ向けて統合する問題が生まれる。ある下位タスクの中の振る舞いは、それ単独では良し悪しを判定できず、他の下位タスクとの関係で決まる。しかも実行者は、依存しあう相手の全員と直接やり取りすることはできない。だから組織設計とは、相互依存する多数の役割をまたいで、協調した行動を可能にする仕組みを作ることであり、どの仕組みにも有効に働く範囲の上限がある13。基本命題は「タスクの不確実性が大きいほど、そのタスクの遂行中に意思決定者のあいだで処理されねばならない情報量は大きくなる」——ただし彼はここに「所定の性能水準を達成するためには」という条件を付けている13

モデルの土台には、古典的な統合の仕組みが三つ、不確実性の低い順に積んである。規則(頻出する状況は手順で前もって決める)、階層への上申(規則にない例外だけを、関係部門を見渡せる上位へ送る)、目標(先が読めないほど、手順ではなく目標や納期を指定して、裁量を下へ降ろす)。それでも例外は階層に上がってくるから、不確実性が増すほど例外が増え、階層が過負荷になる。彼が組織形態の限界要因として置くのはここだ——「事前に予期し計画しておくことのできない、非定型で重大な事象を扱う能力」13

過負荷になった組織が取れる道を、彼は二方向×二つ=四つの方策として整理する13処理すべき情報量そのものを減らす方向が二つ。第一は余裕資源——納期・予算・在庫・設計の最適化水準といった目標を緩め、例外の発生自体を減らす。代償も彼が列挙している。予算は膨らみ、客は待たされ、資本は在庫に寝て、製品の性能は落ちる。第二は自己完結的なタスクへの切り分け——相互依存そのものを断つ。代償は資源の専門化が失われること(前段で見た)。処理する能力を増やす方向が二つ。第三は垂直の情報システムへの投資——発生点から意思決定点へデータを運ぶ経路を太くする。データが形式化できる場合に有効という彼自身の限界条件も前段で見た。第四は横の関係——直接接触、リエゾン、タスクフォース、チームと段階を上げながら、上へ送らずに横で決めて階層の負荷を抜く。

この整理が、論文でいちばん怖い一文につながる。四つの方策は網羅的である(と彼は仮説を置く)——つまり、これ以外の逃げ道は無い——としたうえで、こう書く——「組織は、より大きな不確実性に直面したとき、四つの方策のうち少なくとも一つを採用しなければならない。もし意識的に四つのうち一つを選ばなければ、第一の方策、すなわち性能基準の引き下げが自動的に起こる。タスクの情報要求と、組織が情報を処理する能力は、常に釣り合う。組織が意識的に釣り合わせないなら、予算超過やスケジュール超過という形で性能が下がることによって、等号が成立させられる」13。ここで「第一の方策」とは余裕資源のことだ。目標を緩めることは、意識的に選べばどの変数をいくら緩めるかを自分で決められる設計手段であり、選ばなければ予算超過・納期超過という形で向こうから起こる。同じ変数が、選ぶか選ばされるかだけ違う。論文の結びの言い方では「決めないことも決めることであり、それは階層の過負荷を除く方策として余裕資源を選ぶと決めることである」13

この形は、プロジェクトマネジメントの実務が納期・コスト・スコープ・品質のバランスとして知っているものと同じだ。ガルブレイスが余裕資源の緩め先として挙げる変数——完成までの時間、予算、設計の最適化水準——は、四つの辺のうち納期・コスト・品質の三つにそのまま重なる(スコープにあたる変数を彼は挙げていない)。そして実務では、納期・コスト・スコープは経営層が先に固定することが多い。固定された辺は緩め先から外れる。だから、意識的に釣り合わせない組織では、引き下げは残った変数——品質——に落ちる。ガルブレイス自身が挙げる超過は予算とスケジュールという見える形だが、そこが固定されている組織では、同じ等号が見えにくい変数のほうで成立することになる。

エージェントを増やせば、処理すべき情報は増える。ここで主張の範囲をはっきりさせておく——これはAIを使うと品質が下がるという話ではない。一人の開発者が実装をAIへ任せる使い方で品質が下がるという証拠を、本記事は持っていない。主張が結ぶのは、束ねる側の処理能力を増やさないまま体数を増やす場合だ。そのとき四方策の対応物は素直に決まる。余裕資源は納期と予算を緩めること。自己完結的タスクはエージェントの隔離。垂直の情報システムはハーネスとコンテキスト管理への投資。横の関係はエージェント間の直接通信で、その費用が対の数の二乗で伸びることは前段で見た。ガルブレイスの均衡で言えば、処理能力を増やす側の方策か、情報要求を減らす側の方策かを意識的に選ばないかぎり、性能基準の引き下げが自動的に起こる——彼自身の言い方では、それは予算超過やスケジュール超過という見える形で現れる。エージェントの場合、ここに一つ条件が重なる。超過や手戻りを報告する経路そのものが、前節で見たとおり当てにならない。だから引き下げが起きたことに、束ねる側が気づき遅れる余地が人間の組織より大きい——これはガルブレイスの主張ではなく、前節の観察と組み合わせた本稿の推論である。

最後に、この節の位置づけを明確にしておく。管理の枠組みの命題そのもの——グライキュナスの関係数予算、ガルブレイスの均衡——をエージェントで検証した研究は、arXiv と一般のウェブを探した範囲では見つからなかった。近いのは本記事が引く二本で、アーキテクチャと仕事の形の整合を260構成で測った研究と、相互通信項を導出して千体超まで実験した研究がある58。ただしどちらも管理理論の前提条件をそのまま検証したものではない。ほかに出てきたのは、既存の枠組みの語彙をエージェントの指示文に転用した研究と、測定を伴わないベンダー記事が大半だった。だからここまでの当て直しは、原典が自分で書いた前提条件と、実在のハーネスの仕様を突き合わせた本稿の分析であって、測定された結論ではない。

何を持ち帰るか

エージェントを増やす前に、マネジメント技術の側から問えることは、四つに整理できる。

一つ、分け方を先に決める。分け方は並列化の都合ではなく設計判断で、その時点で到達できない設計が確定する。問うべきは「並列化できるか」ではなく「この分け方では作れないものは何か」だ。読む仕事と書く仕事を同じ粒度で分けない、というのはその一例にすぎない。

二つ、調整の費用を、増やす側の勘定に入れる。訓練の項が安く見えるぶん増員は安く見えるが、その項は毎回払い直しており、相互通信の項も残っていて、束ねる側のコンテキストという一点に集中して落ちる。しかも人数の二乗で効く。上限の出し方は1933年から変わっていない——頭数より速く増える量が、抱えられる上限をまたぐ点を探す。グライキュナスはそれを関係の数の表で、いまは束ねる側の窓で見ているだけの違いだ。干渉しない仕事なら制限は緩むが、原典はそれを最下層に多い条件として挙げ、専門化が進むほどこの制約は重くなるとしている。

三つ、投入量の上限を、生成能力ではなくレビュー能力に合わせる。生成は非ボトルネックだ。そこを速くしても外に出る量は変わらず、変わるのは待ち行列の長さと、一件あたりの大きさのほうである。

四つ、動機づけに乗っていた道具を持ち込まない。完了報告・見積り・遅延理由は、報告者が結果を引き受けるからこそ情報になる。引き受ける主体がいない以上、これらは確認の代わりにならない。確認は、エージェント本人の言葉ではなく環境の状態を見る独立の経路でやる。

そして、四つを別々に守っても足りない。効かない側の道具(完了報告)に寄りかかったまま、効く側の負荷(調整費用とレビュー待ち)を増やすと——本稿の見立てでは——超過はエラーとしてではなく、静かな質の低下として現れる。ガルブレイス自身が挙げるのは予算超過・スケジュール超過という見える形で、それが見えにくくなるという上積みは本稿の推論だ。その上でなお、増やしたほうが良いとは限らない。同じモデル・同じ計算量で、分解可能な仕事では大きく伸び、逐次的な仕事では大きく落ちるという測定がある以上、増やすかどうかは仕事の形の問題だ。マネジメント技術は、その形を見極めるためにこそ効く——並べたあとで統べるためではなく、並べる前に、並べてよいかを判定するために。

出典

  1. Anthropic, “How we built our multi-agent research system,” Anthropic Engineering blog(2026年8月3日参照。製品開発記ゆえ更新されうる)。初期の失敗として「単純な問い合わせに50体の子エージェントを立ち上げ、存在しない情報源を求めて延々とウェブを漁り、過剰な更新で互いの注意を逸らす」を挙げ、指示が曖昧だった場合の例として「一体のサブエージェントが2021年の自動車向けチップ危機を調べ、他の二体が2025年の現在の供給網を重複して調べた——効果的な分業を欠いたまま」と記す。同記事は自社の多エージェント構成が内部評価で単体のClaude Opus 4を90.2%上回ったとも述べるが、これは公開されていない社内評価での相対改善であり、リード役とサブ役に別モデルを充てた非対称な比較でもあるため、本記事では性能主張としては用いない。多エージェント構成を実運用する側の記録=AIに有利な側の証拠として引く。https://www.anthropic.com/engineering/multi-agent-research-system

  2. 組織の根本問題を「調整(coordination)」と「動機づけ(motivation)」の二つに切り分ける枠組みは、思いつきではなく組織の経済学の標準的な編成である。Paul Milgrom & John Roberts, Economics, Organization and Management(Prentice-Hall, 1992)は分野全体をこの二問で構成し、調整(Part II “Coordination”)と動機づけ(Part III “Motivation: Contracts, Information, and Incentives”)を別々の部として扱う。帰属の経路を明示する: 本文への一次アクセス(全文の逐語取得)は取れなかったため、この帰属は同書の部構成(Part II “Coordination” / Part III “Motivation: Contracts, Information, and Incentives”)にもとづくものであり、特定の一文の逐語引用ではない。同じ John Roberts の後年の著書 The Modern Firm(Oxford University Press, 2004)も同じ二問を扱うが、公開されている章立てはこの二分割の形を取らないため、本記事の枠組みの根拠には用いない。本記事の「情報処理の層/動機づけの層」はこの調整/動機づけにそれぞれ対応する。二層のうち動機づけの側がエージェントに移らないという本記事の主張の骨格=AIに不利な側の枠組みとして引く。https://global.oup.com/academic/product/the-modern-firm-9780198293750

  3. M. E. Conway, “How Do Committees Invent?,” Datamation, April 1968(著者自身のサイトに Datamation の許諾つきで再掲。本文を取得し、以下の各文字列の一致を確認した)。逐語で「organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations」「Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist. Therefore, there is no such thing as a design group which is both organized and unbiased」「Every time a delegation is made and somebody’s scope of inquiry is narrowed, the class of design alternatives which can be effectively pursued is also narrowed」「the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise」「Elementary probability theory tells us that the number of possible communication paths in an organization is approximately half the square of the number of people in the organization. Even in a moderately small organization it becomes necessary to restrict communication in order that people can get some “work” done」。「Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design」。なおコンウェイ自身は、法則が強く効く条件を「コミュニケーション構造が完全には柔軟でない範囲において」と限定し、組織を小さく柔軟に保つことを処方として挙げている——分け方が自由に組み替えられるなら束縛は弱まる、という留保が原典に含まれる。分割そのものが制約になると論じる=AIに不利な側の証拠。https://www.melconway.com/Home/Committees_Paper.html 2 3 4 5

  4. H. Chase, “How and when to build multi-agent systems,” LangChain blog(2025-06-16。2026年8月3日参照、更新されうる)。「read アクションは write アクションよりも本質的に並列化しやすい。書き込みを並列化しようとすると、エージェント間で文脈を効果的に伝える課題と、その出力を整合的に統合する課題を同時に抱えることになる」と述べ、読み取り中心の探索は並列化し、統合と執筆は単一の呼び出しに集約する設計を、実在システムの構成から読み解く。分割の設計次第で多エージェントが機能すると論じる=AIに有利な側の証拠。なお同記事は自社製品の宣伝を含むため、ここで引くのは分析部分に限る。https://blog.langchain.com/how-and-when-to-build-multi-agent-systems/

  5. Y. Kim et al., “Towards a Science of Scaling Agent Systems,” arXiv:2512.08296(v3, 2026-04-08。査読前プレプリント。abs ページと v3 本文 PDF を取得して以下を確認した)。「Across 260 configurations spanning six agentic benchmarks, five canonical architectures (Single-Agent and four Multi-Agent: Independent, Centralized, Decentralized, Hybrid), and three LLM families, we perform controlled evaluations, standardizing tools, prompts, and compute to isolate architectural effects」「Relative performance change compared to single-agent baseline ranges from +80.8% on decomposable financial reasoning to -70.0% on sequential planning, demonstrating that architecture-task alignment determines collaborative success」。本文 §4.2 の逐語も確認した——「PlanCraft exhibits universal performance degradation across all multi-agent architectures. Centralized declines to −50.3% (0.282 vs. SAS 0.568), Decentralized to −41.5% (0.332), Hybrid to −39.1% (0.346), and Independent to −70.0% (0.170)」「Aggregating across all six benchmarks and architectures, the overall mean MAS improvement is −0.3% (95% CI: [−58.7%, +77.2%]), reflecting substantial performance heterogeneity with high variance (σ = 37.5%)」。平均の単位はベンチマークではなくベンチマーク×アーキテクチャのセルである。単体基準の相対変化であり、絶対性能の保証ではない点、および査読を経ていない点に注意。増やすこと自体は解にならないと示すAIに不利な側の証拠。https://arxiv.org/abs/2512.08296 2 3

  6. F. P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering(Addison-Wesley, 1975)第2章。1975年版第1〜2章を再現した大学講義ページのPDFを取得し、逐語「The added burden of communication is made up of two parts, training and intercommunication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers」「Adding manpower to a late software project makes it later」「The bearing of a child takes nine months, no matter how many women are assigned」「Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them」の一致を確認した。相互通信の項については同じ段落に “Intercommunication is worse. If each part of the task must be separately coordinated with each other part, the effort increases as n(n1)/2.” とあり、ハイフンがOCRで脱落しているほかは一致する。ブルックス自身は法則の提示を「乱暴に単純化して言えば」と断り、増員が効かない主因を逐次的制約に置いている。増員が調整費用を通じて逆効果になりうると示すAIに不利な側の証拠。https://twu.seanho.com/11spr/gamedev/TheMythicalManMonth.pdf

  7. Anthropic, Claude Platform 公式ドキュメント “Memory tool” および “Using the Messages API”(2026年8月3日参照。製品ドキュメントゆえ更新されうる)。前者は記憶ツール有効時にモデルへ与える指示として「ASSUME INTERRUPTION: Your context window might be reset at any moment, so you risk losing any progress that is not recorded in your memory directory」と明記し、記憶が「クライアント側で動作する——Claudeがファイル操作を要求し、あなたのアプリケーションがそれを実行する」外部の仕組みであることを述べる。後者は「The Messages API is stateless, which means that you always send the full conversational history to the API」と述べる。学習が働き手の内側に積み上がらないことを製品側が明記するAIに不利な側の証拠。https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool https://platform.claude.com/docs/en/build-with-claude/working-with-messages

  8. C. Qian et al., “Scaling Large Language Model-based Multi-Agent Collaboration,” arXiv:2406.07155(v3。abs ページの Comments に “Accepted to ICLR-2025” とあり査読を経ている。HTML 全文を取得して以下を確認した)。「Note that unrestrained information exchange among agents inevitably leads to context explosion … ultimately hindering scalability by limiting support for additional entities」「This token complexity analysis implies that, without memory control, context length grows with n^2, causing squared increases in time and cost as the network scales. Conversely, our mechanism decouples context length from quadratic to linear growth」「AgentVerse implicitly reduces to a star topology and frequently encounters context explosion issues when scaling beyond thirty agents, thus hindering scalability」。n² は実測ではなく、最も密な構成での導出上の複雑さである点に注意——導出は最密(mesh)トポロジで最大の文脈圧を受ける sink agent のトークン消費として与えられ(「in a mesh structure characterized by the highest interaction density, the total token consumption for the sink … agent who experiences maximum context pressure, with and without this mechanism, is derived as follows」)、その式は経路数 n(n−1)/2 に経路あたりのやり取り量を掛けた形、すなわち t+p+s+(2m−1)(i+s)(n(n−1)/2+2(n−2)) ≈ Cn² である。記憶制御を入れると相互通信項が線形に落ち、t+p+s+m(i+s)((n−1)+2(n−2)) ≈ C̄n ∝ n となる。二乗は経路(エージェントの対)の数から来ており、コンウェイ・ブルックスの n(n−1)/2 と同じ組合せ量である。同論文は千体超の協働を支えたと報告しており、調整費用は設計で潰せると示すAIに有利な側の証拠でもある。https://arxiv.org/abs/2406.07155 2 3

  9. N. F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” Transactions of the Association for Computational Linguistics, vol. 12 (2024), pp. 157–173(査読つき。arXiv:2307.03172 の本文を取得して確認した)。「performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models」と述べ、本文では「GPT-3.5-Turbo’s multi-document QA performance can drop by more than 20%—in the worst case, performance in 20- and 30-document settings is lower than performance without any input documents (i.e., closed-book performance; 56.1%)」と報告する。実験対象は2023年時点のモデル(GPT-3.5-Turbo・Claude-1.3・MPT-30B-Instruct・LongChat-13B)で文書数は10・20・30なので、現行世代の数値としては読めない。文脈を足せば足すほど効くという見立てのAIに不利な側の証拠。https://aclanthology.org/2024.tacl-1.9/

  10. Anthropic, Claude Platform 公式ドキュメント “Context windows”(2026年8月3日参照。製品ドキュメントゆえ更新されうる)。「A larger context window allows the model to handle more complex and lengthy prompts, but more context isn’t automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what’s in context just as important as how much space is available」と述べる。百万トークンの窓を提供している当事者が、同じ頁でその劣化を明記している——窓を広げれば調整費用を吸収できるという見立てのAIに不利な側の証拠。https://platform.claude.com/docs/en/docs/build-with-claude/context-windows

  11. V. A. Graicunas, “Relationship in Organization,” in L. Gulick & L. Urwick (eds.), Papers on the Science of Administration(Institute of Public Administration, 1937)ch. X, pp. 181–187。初出は Bulletin of the International Management Institute, March 1933。archive.org の全文スキャンを取得し、逐語「In almost every case the supervisor measures the burden of his responsibility by the number of direct single relationships between himself and those he supervises. But in addition there are direct group relationships and cross relationships」「It is obvious that, if it is cross and group relationships which introduce complexity into supervision, this factor will operate with much less force where the work done by each of various subordinates does not come into contact with that done by others」の一致を確認した(関係数の式そのものはスキャンのOCRが崩れており、数表のみ判読できる)。三種の定義とトム/ディック/ハリーの例は逐語「Thus, if Tom supervises two persons, Dick and Harry, he can speak to each of them individually or he can speak to them as a pair」「what Dick thinks of Harry and what Harry thinks of Dick constitute two cross relationships which Tom must keep in mind」「Tom must hold four to six relationships within his span of attention」による。増え方は逐語「each fresh individual adds as many more cross and direct group relationships as there are persons already in the group. Irrespective of the manner of counting, the number of relationships increases in exponential proportion」。表の f 行(最も包括的な数え方=原典が判断の基準に採ると述べる線)は判読できる範囲で 1, 6, 18, 44, 100, 222, 490, 1080, 2376 と並ぶ。「交差12・集団28」が部下4人の値に一致することは、本稿が表から確認した——交差 n(n−1)=12、集団 n(2ⁿ⁻¹−1)=28 がいずれも n=4 で成立し、合計 44 も表の第4項と一致する。原典はこの一致を明言していないので、上限の置き方が答えを決めているという読みは本稿のもの。逐語「Assuming that it is possible for one supervisor to watch a maximum of 12 cross and 28 direct group relationships, the conclusion follows that, in cases other than routine work, the rapid increase of cross and direct group relationships is the governing factor which actually limits the number of persons which can be effectually and efficiently supervised by one person」「Hence the number of lateral divisions in each descending level of responsibility should be restricted to a maximum of five and, most probably, only four」も確認した。干渉しない場合に要因が弱まるという条件は原典自身が置くが、原典はそれを「This is frequently the case at the lowest level of organization」と最下層の事情とし、章末では専門化の進展により「The principle which has been discussed is, therefore, likely to become of greater rather than of less importance in all forms of organization」と締める。関係数の予算から頭数の上限を導く側=AIに不利な側の証拠。https://archive.org/details/papersonscienceo00guli 2 3 4

  12. L. Gulick, “Notes on the Theory of Organization,” in L. Gulick & L. Urwick (eds.), Papers on the Science of Administration(Institute of Public Administration, 1937)。同じ全文スキャンから逐語「Where the work is of a routine, repetitive, measurable and homogeneous character, one man can perhaps direct several score workers. This is particularly true when the workers are all in a single room. Where the work is diversified, qualitative, and particularly when the workers are scattered, one man can supervise only a few」を確認した。省略していた一文(同じ一部屋にいる場合はとくにそうだ)を復元した——エージェントは同じコンテキストという「一つの部屋」に置ける。ただし同段落の主旨は限界の側にあり、直前でガリックは “The limit of control is partly a matter of the limits of knowledge, but even more is it a matter of the limits of time and of energy” と述べている。仕事の性質しだいで一人が数十人を統べうると述べる側で、干渉の少ない並列作業なら台数を増やせるという見立てのAIに有利な側の証拠。https://archive.org/details/papersonscienceo00guli

  13. J. R. Galbraith, “Organization Design: An Information Processing View,” Interfaces, vol. 4, no. 3 (May 1974), pp. 28–36(査読つき。INFORMS 版は有料のため、Interfaces の誌面体裁と頁番号を備えた全文スキャンを取得して確認した)。逐語「A basic proposition is that the greater the uncertainty of the task, the greater the amount of information that has to be processed between decision makers during the execution of the task」「the greater the task uncertainty, the greater the amount of information that must be processed among decision makers during task execution in order to achieve a given level of performance」「The organization must adopt at least one of the four strategies when faced with greater uncertainty. If it does not consciously choose one of the four, then the first, reduced performance standards, will happen automatically. The task information requirements and the capacity of the organization to process information are always matched. If the organization does not consciously match them, reduced performance through budget overruns, schedule overruns will occur in order to bring about equality」「If data is formalized and quantifiable, this strategy is effective. If the relevant data are qualitative and ambiguous, then it may prove easier to bring the decisions down to where the information exists」「The cost of the self-containment strategy is the loss of resource specialization」(スキャンでは OCR が “tbe” と読む箇所)。モデルの土台と構造の逐語は「The assumption is that the critical limiting factor of an organizational form is its ability to handle the non-routine, consequential events that cannot be anticipated and planned for in advance」「As uncertainty increases the number of exceptions increases until the hierarchy becomes overloaded」「It can proceed in either of two general ways. First, it can act in two ways to reduce the amount of information that is processed. And second, the organization can act in two ways to increase its capacity to handle more information」(Figure 1 が四方策をこの二方向の下に図示する)。余裕資源の代償は「The strategy of using slack resources has its costs. Relaxing budget targets has the obvious cost of requiring more budget. Increasing the time to completion date has the effect of delaying the customer. Inventories require the investment of capital funds which could be used elsewhere. Reduction of design optimization reduces the performance of the article being designed」。結びは「Not to decide is to decide, and it is to decide upon slack resources as the strategy to remove hierarchical overload」(いずれも sietmanagement.fr がホストする誌面スキャンの OCR 層から取得して照合。OCR は “infomiation” “ihe” などの誤読を含む)。ガルブレイス自身、四つの方策が網羅的であることは「仮説」であり、第五の方策(環境そのものに働きかけて不確実性を減らす)があるだろうとも書いている。増員が黙って質の低下につながりうると示すAIに不利な側の証拠。https://doi.org/10.1287/inte.4.3.28 2 3 4 5 6 7

  14. Faros AI, “The AI Productivity Paradox Report 2025”(エンジニアリング分析ツールを提供する企業による自社観測データの報告。2026年8月3日参照、更新されうる)。方法は「タスク管理システム・IDE・静的解析・CI/CD・版管理・障害管理・人事メタデータからのテレメトリを、複数企業の1,255チーム・1万人超の開発者について、最大2年分を四半期ごとに集計」。逐語「Developers on teams with high AI adoption complete 21% more tasks and merge 98% more pull requests, but PR review time increases 91%, revealing a critical bottleneck: human approval」「AI adoption is consistently associated with a 9% increase in bugs per developer and a 154% increase in average PR size」「we observed no significant correlation between AI adoption and improvements at the company level. Across overall throughput, DORA metrics, and quality KPIs, the gains observed in team behavior do not scale when aggregated. This suggests that downstream bottlenecks are absorbing the value created by AI tools, and that inconsistent AI adoption patterns throughout the organization—where teams often rely on each other—are erasing team-level gains」。原典は理由を二つ並べており、後者(導入のばらつき)は本記事の見立てとは独立した競合説明である。ベンダーによる観測研究で、査読も信頼区間の公表もなく、相関であって因果ではない。生成を速めても外に出る量が増えるとは限らないと示すAIに不利な側の証拠。https://www.faros.ai/blog/ai-software-engineering

  15. Google Cloud / DORA, Accelerate State of DevOps Report 2024(公式PDFを取得して確認した。回答者は104か国・約3,000名の実務者を対象とする横断的な自己申告調査)。逐語「the effect on delivery throughput is small, but likely negative (an estimated 1.5% reduction for every 25% increase in AI adoption). The negative impact on delivery stability is larger (an estimated 7.2% reduction for every 25% increase in AI adoption)」「we hypothesize that the fundamental paradigm shift that AI has produced … may have caused the field to forget one of DORA’s most basic principles—the importance of small batch sizes. That is, since AI allows respondents to produce a much greater amount of code in the same amount of time, it is possible, even likely, that changelists are growing in size」。同報告は方法論の章で「we didn’t do longitudinal studies or a proper experiment」と自ら明記している(続く一文は “Correlation does not imply causation, but it does imply how you think about causation.” であり、因果推論そのものを退けてはいない)。なおスループットに関するこの推定は翌年版で符号が変わっており(16)、本記事では現行の知見として用いない。生成量の増加がそのまま成果にならないと示すAIに不利な側の証拠。https://dora.dev/research/2024/dora-report/

  16. Google Cloud / DORA, State of AI-assisted Software Development(2025年版。公式PDFを取得して確認した。2025年6月13日〜7月21日に実施、約5,000名の回答と100時間超の定性データ)。逐語「AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability. This suggests that while teams are adapting for speed, their underlying systems have not yet evolved to safely manage AI-accelerated development」「We have hypothesized that this is likely, in part, because it is harder to review larger batches of code」「This is also the core insight of the Theory of Constraints. Every system has a limiting factor—a constraint—that governs how much value it can deliver. Focusing on anything other than the constraint might feel productive, but it won’t meaningfully improve value flow」「When developers use AI tools and write code faster, the code still needs to go through testing and review queues」「a team may discover, through mapping, that code reviews are a significant bottleneck. With this insight, they can decide to apply AI to improve the code review process, rather than using AI to simply generate more code that will only exacerbate the bottleneck」。同報告は注記で「we don’t want to give false assurances that we understand the underlying causal structure … ultimately, we’re doing comparisons」と述べ、因果解釈を自ら退けている。スループットは前年から改善へ転じた一方、不安定さは残るという両面を示すAIに不利な側の証拠。https://dora.dev/dora-report-2025/ 2 3 4

  17. K. J. Watson, J. H. Blackstone & S. C. Gardiner, “The evolution of a management philosophy: The theory of constraints,” Journal of Operations Management, vol. 25, no. 2 (2007), pp. 387–402(査読つき)。同論文 Table 1「The nine OPT rules」を取得して逐語「An hour lost at a bottleneck is an hour lost for the total system」「An hour saved at a non-bottleneck is just a mirage」「Utilization and activation of a resource are not synonymous」の一致を確認した。同表は出典を Goldratt & Fox, The Race(1986)と明記しており、本記事は当該原典そのものには到達していない(経由を明示する)。制約に注力すれば全体が動くと述べるAIに有利な側の証拠で、非制約を速くする投資の効き目を限定する。https://doi.org/10.1016/j.jom.2006.04.004

  18. M. C. Jensen & W. H. Meckling, “Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure,” Journal of Financial Economics, vol. 3, no. 4 (1976), pp. 305–360(査読つき)。原論文のPDFを取得して逐語「We define an agency relationship as a contract under which one or more persons (the principal(s)) engage another person (the agent) to perform some service on their behalf which involves delegating some decision making authority to the agent. If both parties to the relationship are utility maximizers there is good reason to believe that the agent will not always act in the best interests of the principal」および費用の定義「(1) the monitoring expenditures by the principal, (2) the bonding expenditures by the agent, (3) the residual loss」の一致を確認した(スキャンのOCRに乱れがあるため語単位で照合した)。定義そのものは人間の代理人を前提していないが、保証支出という項が成立するには代理人が賭けるものを持つ必要がある——動機づけで統治できるという見立てのAIに不利な側の証拠。https://doi.org/10.1016/0304-405X(76)90026-X

  19. L. Advani, “From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents,” arXiv:2606.09863(2026-06-01。単著。abs ページの Comments 欄に “Accepted to FAGEN@ICML2026” とあり、ICML 2026 のワークショップに採録されている——本会議の査読ではない。abs ページには所属表示が無いが、PDF は University of Colorado 所属と記す。abs ページの記述として以下を確認した)。「False success is common but varies by setting: 45—48% of failures in single-control tau2-bench domains, 3% in dual-control telecom, and 75.8% among AppWorld self-assessing coding-agent trajectories with explicit status claims」「LLM judges fail reliably: no configuration across 5 judges, 5 prompt strategies, and full task specifications exceeds AUROC 0.65 on tau2-bench」「Judges rely on surface completion proxies — confident closing language … rather than verified state changes」。AUROC 0.65 は tau2-bench についての値で、AppWorld では 0.54 である。同論文はさらに「Lightweight TF-IDF detectors achieve task-disjoint AUROC 0.83 on tau2-bench and 0.95 on AppWorld, recovering 4—8x more false successes than the best judge at the same flag rate with 3,300x lower latency」「These results suggest that production monitoring should use lightweight, domain-calibrated detectors as triage signals rather than relying on LLM judges as the primary monitor for false success」と述べており、判定器の失敗は論文の結論ではなく問題設定の側にあたる。数値は「全実行のうち」ではなく「失敗のうち」の割合である。著者自身、二重制御の設定が一つしかなく事例数も少ないため因果は切り分けられないと明記している。自己申告の完了報告を信頼できるという見立てのAIに不利な側の証拠。https://arxiv.org/abs/2606.09863 2 3 4

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