コンテンツへ移動
記事一覧

数百のエージェントを並べても、組織にはならない

  • エージェンティックAI
  • 組織設計
  • 研究

計算は簡単に並列化できます。しかし、一貫性はそうではありません。Cursor、Anthropic、OpenAI の実験は、組織論が何十年も前から扱ってきた問題を別の形で再発見しています。同時に、人間の組織には存在しなかった難題にも直面しています。同じモデルから作られたエージェントは、同じ誤りを共有しうるという問題です。

20体動かしても、実効性能は2体か3体

2026年1月、Cursor は、AIのデモというより分散システムの障害報告に近い実験結果を公開しました。

同じ立場の複数エージェントを一つのプロジェクトで動かし、共有ファイルを見ながらタスクを選び、進捗を書き込み、同じ仕事を二重に取らないようロックを使う、という設計です。仕組みだけを見れば単純です。

ところが実際には、エージェントがロックを長時間保持したり、解放を忘れたり、自分がすでに持っているロックを再取得しようとしたりしました。仕事を調整するための仕組みそのものが、新しい仕事になったのです。

結果は明快でした。20体を動かしても、Cursor が観測した実効スループットは2体から3体程度でした。時間の大半は待機に消えました。1

問題はエージェントの知能ではありませんでした。組織の作り方だったのです。

この現象自体は新しいものではありません。Frederick Brooks は1975年、遅れているソフトウェア開発に人を追加すると、かえって遅延が拡大することがあると論じました。問題は個々の能力よりも、依存関係、コミュニケーション、統合のコストにあります。2 エージェントもこの制約から自由ではありません。ただ、これまで観測しにくかった現象を、はるかに速く、大きな規模で再現できるようになりました。

本当に並列化できるものは何か

すべての仕事が同じように分割できるわけではありません。

互いにほとんど依存せずに進められる仕事があります。20社をそれぞれ調査する。1000件の文書を読む。複数の仮説を別々に検証する。大量のテストケースを実行する。こうした作業では、それぞれの枝が他の枝を待ち続けなくても成果を出せます。

一方で、強く結合した仕事もあります。あるアーキテクチャ上の判断が、他のすべての判断の前提を変えることがあります。同じ文章を複数人が同時に書き直せば衝突します。同じファイルを複数のエージェントが編集すれば、最終的に変更を統合しなければなりません。実行者の数を増やしても、依存関係は消えません。

1967年に示されたアムダールの法則は、並列計算の速度向上には直列部分が上限を与えることを示しています。3 これは仕事にもそのまま当てはまります。100人で100か所の図書館を調べることはできます。しかし、同じ報告書の同じ1ページを100人が同時に書き換え、最終版を誰も決めないまま完成させることはできません。

だからといって、マルチエージェントが機能しないわけではありません。

Anthropic は、Opus 4 を主エージェント、Sonnet 4 をサブエージェントとして使った研究システムで、Opus 4 単独より内部評価が90.2%向上したと報告しています。4 ただし、ここで扱われたのは、多数の独立した枝に分解しやすい breadth-first 型の調査です。たとえば、S&P 500 のIT企業について取締役を網羅的に調べるような課題です。

コストも重要です。Anthropic によれば、通常のチャットと比べてエージェントは約4倍、マルチエージェントシステムは約15倍のトークンを使います。BrowseComp では、トークン使用量だけで性能差の80%を説明できたといいます。さらに同社は、コード作業は調査よりも「本当に並列化できる部分」が少なく、全エージェントが同じ文脈を共有しなければならない仕事や、依存関係の多い仕事はマルチエージェントに向きにくいと明記しています。4

Claude Code のドキュメントも同じ方向を示しています。順序依存の強いタスク、同一ファイルへの同時変更、依存関係の多い作業では、単一セッションやサブエージェントの方が効率的な場合が多いとしています。5

マルチエージェントは機能します。時には大きな効果を発揮します。

問うべきなのは、使うかどうかではありません。何を任せるかです。

希少になるのは、実行能力ではなく分解能力

有用なオーケストレータは、単なるタスク配布係ではありません。

本当に重要なのは、同時に実行しても互いに邪魔をしない程度まで仕事を分解することです。並列化によって処理量が増えるかどうかは、その分解でほぼ決まります。

Anthropic のコンパイラ実験は、この点を非常に分かりやすく示しています。2026年2月、Nicholas Carlini は16体のエージェントに、Linux カーネルをビルドできる C コンパイラを Rust で一から作らせました。約2000回の Claude Code セッションと約2万ドルのAPI費用を経て、約10万行のコンパイラが作られ、Linux 6.9 を x86、ARM、RISC-V 向けにコンパイルできるところまで到達しました。6

調整方法自体は意外なほど簡素でした。エージェントは git で同期されるディレクトリにテキストファイルを書き、タスクを確保します。マージコンフリクトは頻繁に起きましたが、多くはエージェント自身が解消しました。

重要な教訓は別のところにありました。

カーネルのコンパイル失敗が一つの大きな共通エラーとして現れると、すべてのエージェントが同じバグに行き着きました。全員が同じ問題を直し、互いの修正を上書きするおそれがありました。16体あっても、見ている問題が一つなら、並列化の意味はほとんどありません。

そこで Anthropic は、問題の構造そのものを変えました。大部分は既知の基準である GCC でコンパイルし、残った異なるファイルだけを新しいコンパイラで処理させ、それぞれ別のエージェントに割り当てたのです。最終目的は同じままですが、仕事は識別可能で、分割可能なものになりました。6

並列化するのは目標ではありません。並列化するのは仕事の構造です。

Melvin Conway は1968年、システムの構造は、それを設計する組織のコミュニケーション構造を反映しやすいと述べました。7 エージェントでは、この見方を反転させることができます。使えるエージェントの数から組織を決めるのではなく、仕事の構造からチームの構造を決めるべきです。

Anthropic が、同じファイルを複数のチームメイトに編集させず、各エージェントに異なるファイル群を持たせるよう勧めているのは、その実装上の表れです。5

私たちの研究では、さらに実務的な基準を置いています。順番を入れ替えても最終結果が変わらない処理は並列化します。ページの取得、主張の抽出、証拠の紐付けなどがこれに当たります。一方で、共有状態の改訂や意思決定のように、順序が結果に影響する処理は直列化します。

ある監視システムでは、直列ループだと監視対象1コンポーネントあたり約12分かかっていました。主な原因は、すでに読んだページを繰り返し取得していたことでした。性能を改善したのは、より速いモデルではありません。共有キャッシュとページ単位の分解でした。

階層は、結局戻ってくる

Cursor は最終的に、水平的な自己調整を諦めました。代わりに、役割を分けたのです。

planner はコードベースを調べてタスクを作ります。worker は全体の調整を気にせず、自分のタスクを完了させます。サイクルの最後には judge が次のサイクルを始めるかどうかを判断します。この構造によって、Cursor は同一コードベース上で数百の worker を並行稼働させられるようになりました。ブラウザを一から作る実験では、エージェント群がほぼ1週間動き続け、約1000ファイルにわたって100万行以上を書きました。1

ただし、この行数は品質の指標ではありません。

Cursor 自身、Solid から React への別の移行実験について、CI と初期チェックは通っているものの、なお慎重なレビューが必要だと書いています。1 重要なのはコード量ではなく、組織形態の変化です。自己調整に時間を使いすぎるフラットな構造が、最小限の階層に置き換わりました。

NeurIPS 2025 で発表された MAST は、こうした失敗をより体系的に整理しています。著者らは7種類のマルチエージェントフレームワークから1600件を超える実行トレースを収集し、システム設計、エージェント間の不整合、検証と終了条件という3つの領域にまたがる14種類の失敗モードを特定しました。8

頻出する問題は意外なほど地味です。同じ手順を繰り返す。推論と実際の行動がずれる。いつ止まるべきかを理解できない。仕様を守らない。ここで起きていることは、知能不足だけでは説明できません。システム設計の失敗です。

2026年のプレプリント OrgAgent は、この考え方をさらに進め、マルチエージェントを企業のようにガバナンス、実行、コンプライアンスの3層に分けています。SQuAD 2.0 と GPT-OSS-120B の組み合わせでは、フラット構造に比べて性能が102.73%向上し、トークン使用量は74.52%減ったと報告されています。9

もちろん、一つのベンチマーク、一つのモデルによる結果であり、普遍的な法則ではありません。それでも興味深いのは、階層が有効に働く条件を著者らが明示していることです。安定した能力配分、制御された情報の流れ、段階的な検証です。

ここには、古典的な組織論との強い共通点があります。

Herbert Simon は、組織を限定合理性への応答として捉えました。仕事を分割し、各地点で処理する情報量を減らし、必要なものだけを上に集約し、一部の判断を手続き化するというものです。10 Max Weber もまた、官僚制の優位性を道徳的な観点からではなく、精度、継続性、記録へのアクセス、摩擦の低減といった技術的な性質から論じています。11

エージェントの世界では、この考え方を次のような共有制御の文法に置き換えることができます。

オペレーター組織上の役割
役割行動範囲と権限を明確にする
手続き実行結果を比較可能にする
求められる証拠検証可能な根拠がなければ受理しない
承認効果が出る前に確認点を置く
役割分離作った本人だけで自分の成果を承認させない
監査何が起きたかを再現し、説明できるようにする
エスカレーション不確実性を判断可能な権限者へ送る

組織は、完璧な構成員を前提にしません。

誤りを見えるようにし、その場所を特定し、修正できるようにする規則を持っています。

構造が少なすぎれば衝突する。多すぎれば官僚制になる

逆方向の問題も、同じくらい重要です。

Cursor は品質管理とコンフリクト解消のために、integrator という役割も追加しました。しかし最終的には削除しています。worker 自身で処理できる問題まで integrator を経由するようになり、解決する以上のボトルネックを生んだからです。1

Cursor の結論は明確です。構造が少なすぎれば、衝突、重複、逸脱が増えます。構造が多すぎれば、脆さが増します。1

組織論にも同じ病理があります。

Robert Merton は1940年、手続きの遵守そのものが本来の目的に取って代わる「目的の転移」を論じました。12 Adler と Borys は後に、実行者を縛る強制的な形式化と、実行者がより良く判断できるよう支援する有効化型の形式化を区別しました。13

エージェントのハーネスにも、同じ選択があります。

あらゆる手順を細かく規定し、エージェント間のやり取りを増やすこともできます。あるいは、通過すべきチェックポイントだけを定義し、その間の実行は自由に任せることもできます。

私たちの研究は後者を採ります。

二つのチェックポイントの間では、エージェントは自分で実行方法を選べます。チェックポイントに到達したら、求められた証拠を提出し、それを別の検証主体が確認します。どう考えるかを細かく指定するのではありません。次へ進むために何を示す必要があるか、そして誰がそれを承認できるかを決めるのです。

この違いは見た目だけの話ではありません。EMNLP 2024 の研究では、出力形式を強く制約すると、モデルの推論性能が有意に低下する場合があると報告されています。14 一方で、最終結果だけでなく途中のステップを監督する研究は、中間段階で検証することの価値を示しています。15

したがって、調整機能に存在価値があるのは、それが生む待ち時間よりも多くの衝突を取り除ける場合に限られます。

ロック、planner、受付キュー、arbiter、共有メモリ、人間によるレビュー、テスト。どれもが、その調整コストを正当化しなければなりません。

エージェント特有の罠。同じ頭脳を増やしても、委員会にはならない

ここまでの問題のほとんどは、人間の組織も経験してきたものです。

しかしエージェントには、人間の組織にはほとんどなかった問題があります。構成員が同じモデル、あるいは非常に近いモデルから作られているため、誤りまで共有しうることです。

Condorcet の陪審定理には、魅力的な直感があります。独立した投票者がそれぞれ偶然より少し高い確率で正しければ、人数を増やすほど多数決は正解に近づく、というものです。16

ただし、前提は二つあります。能力と独立性です。

言語モデルでは、この独立性を当然視することはできません。

2026年、Apple の Guneet Kohli は、7つの異なるモデルファミリーから選んだ9つのフロンティアモデルを評価パネルとして調べました。その結果、9人の判定者が持つ情報量は、実質的には独立した約2票分にしかなりませんでした。誤りが相関しており、実験条件によっては最良の単一モデルがパネル全体と同等、あるいはそれ以上の性能を示しました。論文の結論は明快です。パネルを大きくしても、真に独立した評価の代わりにはならない、というものです。17

この結果は丁寧に読む必要があります。

研究対象はすでに7つの異なるモデルファミリーであり、同一モデルを9体複製した条件を直接測ったものではありません。したがって「同じモデルを9体動かすと実質2体になる」と一般化するのは正しくありません。

しかし、より重要な点は残ります。票の数と、独立した情報の量は同じではないということです。

Fudan University の2026年5月のプレプリントでは、同じLLMで動く均質なマルチエージェントにおいて、人数を増やすと性能がいったん上がった後に下がるケースが報告されています。Llama-3.1-70B を用いた抽象代数のベンチマークでは、4体で72.55%、8体で64.71%でした。その一方で、トークンコストは人数とともに大きく増加しました。18

これはプレプリントであり、特定のアーキテクチャによる結果です。それでも示唆は明快です。複数体にすれば自動的に集合知が生まれる、というわけではありません。

Chen らも2024年、同じモデルを複数回呼び出し、多数決で答えをまとめる複合システムについて、似た現象を示しています。呼び出し回数を増やすと、最初は性能が上がり、その後下がることがあります。追加の投票は、簡単な問題では助けになる一方、難しい問題では間違った答えを強化する可能性があるからです。19

Cognition は、さらに強い形で反論しています。行動には暗黙の意思決定が含まれています。サブエージェント同士が完全な実行履歴を共有しないまま異なる前提で判断すると、最後の統合担当には、整合させられない部品が届くことになります。20

だからといって、並列化を捨てる必要はありません。

共有された意思決定を含まない部分だけを並列化し、検証では独立性を意図的に作り出す必要があります。

生成するエージェントと検証するエージェントは、単に同じインスタンスの別ターンであってはなりません。さらに望ましいのは、検証手段そのものを異質にすることです。コードを実行する。一次情報に直接問い合わせる。業務ルールを適用する。複数の文書で裏を取る。こうした検証は、第二の生成モデルとは異なる失敗の仕方をします。

検証者同士の判断が食い違った場合、その差は平均して消すべきノイズではありません。不確実性として人に上げるべき信号になります。

同意する情報源やエージェントの数を数えることは、独立性を測ることではありません。私たちもこの問題を研究しており、マルチエージェントにまだ欠けている重要な指標の一つだと考えています。

正しい組織モデルは一つではない

ここまで読むと、答えは単純に階層を増やすことだと思いたくなるかもしれません。

しかしそれでは、別の誤りに移るだけです。

強く統制された構造は、実行の正確さが重要な仕事に向いています。手順を適用する。コンプライアンスを確認する。成果物を統合する。役割が事前に分かっている作業を遂行する。

一方で、探索そのものに価値がある仕事には、あまり向きません。アーキテクチャを設計する。戦略を考える。原因の分からないバグを調べる。こうした局面で初めから細かなタスクを押し込むと、まだ分からない解決策の構造を、早い段階で固定してしまいます。

組織論は、この緊張関係を長く扱ってきました。Burns と Stalker は mechanistic structure と organic structure を対比しました。Mintzberg は機械的官僚制と adhocracy など、異なる組織形態を整理しました。March は、既知の能力を活かす exploitation と、新しい可能性を探る exploration の緊張関係を論じました。21

Toyota の製品開発にも、有用な示唆があります。

Set-Based Concurrent Engineering では、早い段階で一つの案に決めて改良し続けるのではなく、複数の候補を一定期間残し、比較しながら絞り込みます。22 Reinertsen はさらに、進行中の仕事量を制限し、上から仕事を押し込み続けるのではなく、処理能力に応じて仕事を引き取るという考え方を整理しています。23

エージェントシステムも、名前こそ付けていないものの、同じ形を再発見し始めています。

Google の Co-Scientist は、2026年5月に Nature に掲載されました。複数の仮説を生成し、批判し、トーナメント形式で順位付けし、より良い案へと進化させます。ここでの調整とは、中央の計画がすべての手順を命令することではありません。複数の代替案を競わせ、実験に進む前に選別することにあります。24

Claude Code のドキュメントも、デバッグでは複数のチームメイトに競合する仮説を検証させ、互いの仮説を反証させる方法を推奨しています。一つずつ順番に調べると、最初の仮説に引きずられるからです。5

私たちは、これらを同じ基盤の上にある二つの運用レジームとして扱っています。

統制のレジームでは、役割と検証ポイントが中心になります。探索のレジームでは、エージェントが処理可能な仕事を引き取り、複数の仮説を並行して残し、弱い案を徐々に落としていきます。ログ、検証、人間によるレビューは、どちらのレジームにも残ります。

調整の形は、利用可能なエージェントの数ではなく、仕事の性質に合わせるべきです。

同じプロセスの中で、レジームを切り替えることもできます。意思決定の前は探索を広く保ち、決定後は厳格な実行に移ります。統合は、生産フローから切り離した方が良い場合も多くあります。

歩きながら地図を書き換える必要はありません。

機械の生産量が、人間の吸収能力を超え始めている

これは、もはや研究用エージェントだけの話ではありません。

OpenAI は2026年9月6日、自社の研究組織におけるエージェント利用の状況を公開しました。8月中旬時点で、人間の労働1日あたり3.1エージェント日分の実行時間が使われていました。エージェント利用量で見た中央値の研究者は、API価格換算で1日600ドル超の推論を使い、90パーセンタイルでは7000ドルを超えていました。25

この数字は、3.1エージェント日が3.1人日と同じ価値を持つという意味ではありません。

OpenAI 自身、実行量の数字は解釈が難しいと注意を促しています。また、特に複雑なタスクでは、人間による相当なステアリングが今も必要だとしています。25

それでも、方向性は明らかです。

同社は2026年6月の時点で、社内の99パーセンタイルの利用者が、複数の並列エージェントを通じて1日に60時間を超える Codex のエージェント実行を日常的に生み出していると報告していました。26

実行コストが下がるほど、制約は別の場所に移ります。

問題設定、統合、検証、裁定、受け入れ。並列化しにくいこれらの部分が、全体の速度を決めるようになります。

これは、私たちが8月の記事で扱った検証の問題と同じ構造です。出力量は、人間が判断できる量よりもはるかに速く増やせます。27

だからといって、すべてを人にエスカレーションすればよいわけでもありません。ケースが多すぎれば意思決定者が飽和し、最後には反射的に承認し始めてしまいます。

人間に渡すべき単位は、「高リスク」というアラートではありません。

必要なのは、判断できる形まで整理された案件です。何を主張しているのか。何が根拠なのか。どのような矛盾が残っているのか。なぜ人の判断が必要なのか。選択肢は何か。

人間がエージェントの作業を最初から監査し直す必要はありません。判断できる状態に準備された案件を、裁定できればよいのです。

見るべきKPIは「エージェント数」ではない

エージェント数は、導入した処理能力の規模を示すにすぎません。

有効なスループットを示す指標ではないのです。

エージェントチームでは、むしろ次のような指標を見るべきです。

  1. 独立して進められる仕事の比率。 他のタスクを待たずに進められる仕事は、どれだけありますか。
  2. 待機比率。 ロック、マージ、判断、共有資源を待つ時間は、どれだけありますか。Cursor の初期実験では、20体を起動して実効性能は2体から3体でした。能力の大半が待機に吸収されていたことを示しています。1
  3. 衝突率。 破棄、やり直し、再統合が必要になった仕事は、どれだけありますか。
  4. 実効的な独立票数。 判定者を増やしたとき、本当に異なる情報はいくつ増えましたか。Apple の研究は、名目上は9票あっても、独立した情報ははるかに少ない場合があることを示しました。17
  5. 成果物1単位あたりの統合時間。 出力を一つ増やすたびに、吸収コストはどれだけ増えますか。
  6. 人間のレビュー時間と、人間の削減時間の比率。 自動化は仕事を減らしたのでしょうか。それとも、場所を移しただけでしょうか。

こうした指標を見ると、組織の上限が見えてきます。

ある数を超えると、エージェントを追加しても納期は短くなりません。統合、判断、レビューのいずれかが支配的なボトルネックになるからです。

Claude Code の現在の推奨も示唆に富んでいます。多くのワークフローでは、まず3体から5体のチームメイトで始め、同時実行の利点が本当にあるときだけ増やす、というものです。ドキュメントには、集中した3体の方が分散した5体より良い場合が多い、とまで書かれています。5

適切なエージェント数は、目標ではありません。

仕事を正しく分解した結果として決まるものです。

マルチエージェントは、仕事の組織化の問題である

モデルが進歩すれば、大規模なソフトウェア労働力を作るコストはさらに下がります。

10体を起動することも、100体を起動することも、その先も、簡単になるでしょう。

希少なまま残るのは、エージェントに扱える仕事を与える能力です。独立させられる仕事は独立させる。直列にすべき判断は直列にする。検証では、本当の意味で異なる根拠を用意する。そして最後に、成果をきちんと受理するか、棄却する。

組織とは、実行者の数ではありません。

実行者をつなぐ文法です。

Cercle が Beyond Core を単なるオーケストレータとして考えていないのは、このためです。私たちはこれを組織レイヤーとして設計しています。役割と権限を定義し、主張の種類ごとに必要な証拠を定め、生成と検証を分離し、後から再現できるログを残します。そして、システムだけで判断すべきでない案件は、人間が判断できる形にまとめてエスカレーションします。28

Companion は何体いても構いません。

組織を成り立たせるのは、その間にある規則です。

問いはもう、「何体のエージェントを起動できるか」ではありません。

一貫性を失わずに、私たちの組織はいくつの変化を吸収できるでしょうか。

出典

  1. Wilson Lin, Cursor, Scaling long-running autonomous coding, 2026年1月14日。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975. ↩

  3. Gene M. Amdahl, Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities, AFIPS, 1967, https://doi.org/10.1145/1465482.1465560. ↩

  4. Anthropic Engineering, How we built our multi-agent research system, 2025年6月13日。 ↩ ↩2

  5. Anthropic, Orchestrate teams of Claude Code sessions, 2026年9月15日参照。 ↩ ↩2 ↩3 ↩4

  6. Nicholas Carlini, Anthropic Engineering, Building a C compiler with a team of parallel Claudes, 2026年2月5日。 ↩ ↩2

  7. Melvin E. Conway, How Do Committees Invent?, Datamation, 1968年4月。 ↩

  8. Mert Cemri, Melissa Z. Pan, Shuyi Yang et al., Why Do Multi-Agent LLM Systems Fail?, NeurIPS 2025. ↩

  9. Yiru Wang, Xinyue Shen, Yaohui Han et al., OrgAgent: Organize Your Multi-Agent System like a Company, arXiv preprint, 2026年4月1日。 ↩

  10. Herbert A. Simon, Administrative Behavior, 1947; The Sciences of the Artificial, 1969. ↩

  11. Max Weber, Wirtschaft und Gesellschaft, 1922; H. H. Gerth and C. Wright Mills, From Max Weber, 1946. ↩

  12. Robert K. Merton, Bureaucratic Structure and Personality, Social Forces, 18(4), 1940. ↩

  13. Paul S. Adler and Bryan Borys, Two Types of Bureaucracy: Enabling and Coercive, Administrative Science Quarterly, 41(1), 1996. ↩

  14. Zhi Rui Tam et al., Let Me Speak Freely? A Study On The Impact Of Format Restrictions On Large Language Model Performance, EMNLP Industry Track, 2024. ↩

  15. Hunter Lightman et al., Let’s Verify Step by Step, ICLR 2024. ↩

  16. Nicolas de Condorcet, Essai sur l’application de l’analyse à la probabilité des décisions rendues à la pluralité des voix, 1785. ↩

  17. Guneet Kohli, Apple Machine Learning Research, Nine Judges, Two Effective Votes: Correlated Errors Undermine LLM Evaluation Panels, preprint, 2026年5月。 ↩ ↩2

  18. Jialing Li, Zhouhong Gu, Yin Cai and Hongwei Feng, Scaling Behavior of Single LLM-Driven Multi-Agent Systems, arXiv preprint, 2026年5月30日。 ↩

  19. Lingjiao Chen et al., Are More LLM Calls All You Need? Towards the Scaling Properties of Compound AI Systems, NeurIPS 2024. ↩

  20. Walden Yan, Cognition, Don’t Build Multi-Agents, 2025年6月12日。 ↩

  21. Tom Burns and G. M. Stalker, The Management of Innovation, 1961; Henry Mintzberg, The Structuring of Organizations, 1979; James G. March, Exploration and Exploitation in Organizational Learning, Organization Science, 2(1), 1991. ↩

  22. Allen C. Ward, Jeffrey K. Liker, John J. Cristiano and Durward K. Sobek II, The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster, Sloan Management Review, 36(3), 1995; Durward K. Sobek II, Allen C. Ward and Jeffrey K. Liker, Toyota’s Principles of Set-Based Concurrent Engineering, Sloan Management Review, 40(2), 1999. ↩

  23. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas, 2009; John D. C. Little, A Proof for the Queuing Formula L = λW, Operations Research, 9(3), 1961. ↩

  24. Juraj Gottweis et al., Accelerating scientific discovery with Co-Scientist, Nature 655, 487-496, 2026, DOI 10.1038/s41586-026-10644-y. ↩

  25. OpenAI, Research acceleration: the view inside OpenAI, 2026年9月6日。 ↩ ↩2

  26. OpenAI, How agents are transforming work, 2026年6月25日。 ↩

  27. Cercle, 生成がほぼ無料になったとき、ボトルネックは検証になる, 2026年8月21日。 ↩

  28. Cercle, Cercleに投資する, 「4つの要素からなる構成」「Compagnons（業務エージェント）」, 2026年9月15日参照。 ↩