後回しにされるのは人の注意——AI が書いたコードはレビュー開始まで約 5 倍待たされ、始まれば人間のコードより早く終わる

本稿の要点

8 月半ば、三本の投稿をつなぐと、新しい工程が一つ見つかったように見えた。一本目は、仕事を任せるコストの低下だ。Anthropic の最高プロダクト責任者は、今なら四文の指示で足り、年初は足場を一式組む必要があったと述べた。二本目は、機械の稼働時間の伸びである。あるベテラン開発者の日課表では、エージェントが夜通し走り、人がレビューに入るのは一日二回だけだった。三本目は、その変化を受けた道具の変化だ。同じ開発者が立ち上げたスタートアップは、すべての作業ウィンドウを一目で見渡し、手を要するものを探し出す機能を製品の看板にした。筋道は滑らかに見える。人を止めているのはもはや「どう指示するか」ではなく、「どれを先に見るか」だ、という筋道である。当時の本紙はこれを証拠不足と判断し、観察対象として記録するにとどめ、正式には採らなかった。理由ははっきり書いた。根拠は投稿三本だけで、発言者二人はどちらも利害関係者であり、計測はゼロだった。そして最も必要な数字、一晩走らせた成果のうち翌日どれだけ使えるかは、どこにも存在しなかった。

その数字が今は手に入る。補ってみると、方向は合っていたが、見るべき対象を取り違えていた。注視すべきは同時に開いているウィンドウの数ではなく、成果物の一つひとつが人の目に触れるまで待つ時間である。堀(参入障壁)についての判断は、正面から覆された。本稿の道筋は次のとおりだ。まず「注意のルーティング」がどの工程を指すのかを定める。次に、互いに独立した大規模な計測三組で三つの問いに順に答える。何人が並行で走らせているのか、翌日どれだけ使えるのか、人の注意はどこに使われているのか。そのうえで「待ち」を二つに割る。ここが本稿の核心である。最後に時系列の問題を扱う。モデル企業はとうに参入しており、しかも選んだのはこの道ではなかった。

夕刊の同じ項目に比べて、本稿が上乗せするものは三つあり、どれも具体的だ。第一に、「見てもらうまで」と「見る」を二つの数字に分けた。 810 万件のマージリクエストを集めたデータセットで、AI が書いたコードは誰かが見始めるまで平均約 1,050 分かかり、人が書いたコードは約 200 分だった。ところが見始めてからは、AI の分は平均 194 分で見終わり、人の分は 252 分かかる。高くつくのは順番待ちであって、レビューそのものではない。 「注意は検証の前払いコストである」という命題が、初めて値札を得た。第二に、「AI のファイルが大きいだけだ」という反論をこの判断にぶつけたところ、判断は持ちこたえきれなかった。 AI のマージリクエストは確かに 2.6 倍大きく、大きいものはもともと長く待たされる。約 5 倍の差のどこまでが注意で、どこまでが体積なのか、このデータは分解しておらず、本稿の材料でも分けられない。この穴は脚注に隠さず本文に書いた。第三に、「モデル企業はこの層を取り込めない」という一文は、書かれた当日にはすでに成り立っていなかった。 OpenAI のデスクトップ版 Codex は 2 月 2 日の公開時点で、エージェントを束ねる司令塔を名乗っていた。Anthropic の Claude Code の更新履歴では、入力待ちのバックグラウンドエージェントの数を示す画面がすでに出荷され、その状態表示の不具合修正まで進んでいる。直すべき不具合が出るのは、その機能が利用者の手元に十分長くあった証拠である。

「注意のルーティング」とはどの工程か

この言葉には説明が要る。既存のどれか一つの仕組みを指す言葉ではないからだ。

問題はこうして生まれた。 従来、人とソフトウェアの関係は同期的だった。指示を一つ打てば結果が一つ返り、その場に人がいる。この形では「どれを先に見るか」という問題は起きない。対象は一つしかなく、しかも人はその一つを見ているからだ。エージェントが人の寝ている間に 8 時間走れるようになると、二つのことが同時に変わる。成果が出る時刻が人の起きている時間から切り離されること、そして同時に走る委任が一件ではなくなることだ。こうして「委任するかどうかを決める」工程と「正しくできたか検証する」工程のあいだに、以前は存在しなかった工程が一つ生まれた。限られた一回の持ち場入りの中で、手を要するものを先に見分ける工程である。

検証の一部ではなく独立した工程と言える理由は、コスト構造がまるで違うことにある。 検証のコストはタスクの難しさに比例する。難しいものほど確かめるのに時間がかかる。一方、「どれを見るべきか」を見つけるコストは、同時に走っている件数に比例し、一件ごとの難しさとは関係がない。壊れ方も違う。検証が壊れると見誤る(通すべきでないものを通す)。ルーティングが壊れると、そもそも見ない(成果物が置かれたまま待つか、飛ばされる)。この区別が、本稿の以降の判断すべての土台になる。

境界はどこにあるか。 この工程が存在するのは、委任が 2 件以上あり、かつ成果が非同期に出てくる場合だけだ。エージェントを一度に一つだけ走らせ、横で見ているなら、このコストはゼロである。したがって最初に問うべき実証の問いは、実際にその状態にいる人がどれだけいるか、になる。

第一の数字:並行は実在するが、内部の常態であって市場の常態ではない

その問いに最も直接答えるのが、OpenAI 自身の利用データである。6 月 25 日、Drew Johnston、David Holtz、Alex Martin Richmond、Christopher Ong、Prasanna Tambe、Aaron Chatterji の研究グループが、OpenAI Codex の利用データの大規模分析を発表した。この研究が決定的なのは、利用者を三群に分けて見ている点だ。OpenAI の社員、外部の組織アカウント利用者、外部の個人アカウント利用者である。要旨に載った全体の数字は、利用者の 10% 超が毎週どこかの時点で三つ以上の Codex エージェントを同時に管理している、というものだった。

ただし分解すると、この 10% は三群をならした値で、三群の形はまったく違う。6 月 11 日までの一週間の数値はこうだ。

• OpenAI 社内:どの時点でも単線で作業していた人は 10.7% にとどまり、28.6% 近くが五つ以上のエージェントを同時に管理した経験を持つ。
• 外部の組織利用者:67.4% が期間中一度も並行利用していない。並行利用した人も、大半はピークが二つだった。
• 外部の個人利用者:63.9% が一度も並行利用していない。

個人アカウントの群には、もう一段の割り引きが要る。標本はクエリを学習に使うことに同意した利用者に限られ、個人利用者全体を代表するとは限らない。

つまり「エージェントの艦隊」という絵は実在するが、その絵はモデル企業自身の社員の日常であって、市場の日常ではない。市場の中央値はゼロから二だ。これは本紙の手元にある唯一の実測値とちょうど合う。エージェントを日課表に組み込み、この種の道具の会社まで創業しているベテラン開発者が自己申告した普段の並行数は「少なくとも 2」だった。この開発者は控えめなのではなく、外部利用者の上限の側にいる。

ここで一度立ち止まる価値がある。この結果の向きは本稿の結論に不利だが、そのぶん信頼できるからだ。データは OpenAI 自身のもので、著者には同社のチーフエコノミストが入っている。動機があるとすれば、採用を浅くではなく深く描く方向に働く。にもかかわらず出てきた数字は「組織利用者の三分の二は一度も並行利用していない」だった。データ源の偏りの向きと、報告された結論の向きが逆であるとき、その結論は立ちやすい。

ただし同じ研究の中に、向きがまったく逆で、しかも本稿の以降を動かすエンジンになる数字がある。「経験のある人が 8 時間以上かけるタスク」を投げる利用者の割合は、2.1% から 25.6% に上がった。 並行は広がっていないが、一件の長大化は広がった。利用者の四分の一は今、人がまる一日かける仕事を丸ごと投げている。

二つの数字を並べると形が見える。大半の人は八つのウィンドウを同時に見張っているのではない。大きな仕事を一つ投げて、席を離れる。 後の議論にとって重要なのはこの点だ。離れた後にその成果物がどうなるかが、本当の問題だからである。

第二の数字:欠けていた「翌日どれだけ使えるか」が埋まった

離れた後に何が残るのかを測る数字は、当時は存在しなかった。本紙が当時書いたのは、夜間に走らせたエージェントの成果の翌日採用率がなければ、「注意がボトルネックだ」はもっともらしい話にとどまる、という一文だった。

公開されている代理指標で最も近いのは、開発プロセスの改善ツールを販売する LinearB の 2026 年エンジニアリング・ベンチマーク報告である。母集団はマージリクエスト 810 万件、約 4,800 のエンジニアリングチーム、42 か国。マージリクエストを三つに分ける。人だけが書いたもの、人が書き AI が形づくりに関わったもの、エージェントが丸ごと生成したものだ。「受け入れ」の定義は 30 日以内にマージされたこと。結果は次のとおりである。

人が書いたマージリクエストは 84.4% が 30 日以内にマージされ、AI が関わったものは 32.7% にとどまる。

先に、この数字を何に使えないかを書く。「AI が書いたコードの三分の二は不良品だ」という意味ではない。マージされない理由はいくらでもある。重複、よりよいやり方への置き換え、要件の変更、出した本人による取り下げ、どれも含まれる。業界の定数でもない。LinearB が売っているのはまさにこの流れを改善する道具で、データセットは自社顧客のものだ。しかも「AI が関わった」マージリクエストをどう判定したかを公開していない。同じベンダー、同じデータの中の相対的な差は使えるが、絶対水準を常識として持ち出すことはできない。

それだけ割り引いても、硬い部分は残る。同じ判定基準、同じチーム群の中で、AI の成果物が本流に入る確率は人の書いたものの半分に届かない。 あの判断を据えるときに最も欲しかった桁、「一晩走らせた成果のうち翌日どれだけ使えるか」への答えは、「想定よりずっと少ない」だ。8 桁規模の標本でこう言えるのは、これが初めてである。

待ちを二つに割る:高くつくのは順番待ちで、レビューではない

ここからが本稿の本当の上乗せになる。同じ報告は、マージリクエストが開かれてからマージされるまでの時間を二つの区間に分けており、この分け方が先に定めた工程をそのまま射抜いている。

第一区間は「見てもらうまで」(業界ではピックアップタイムと呼ぶ)。開かれてから、最初の一人が実際に見始めるまで置かれている時間だ。第二区間は「見る」。誰かが見始めてから、見終えて結論を出すまでの時間である。数値はこうだ。

二つの区間は逆向きに動く。 見てもらうまでの時間はおよそ 5.25 倍になった。ところが人が腰を据えて見始めると、AI の分のほうが人の書いた分より早く終わる(194 分対 252 分)。

この形が本稿で最も重要な図である。人のレビュー能力は落ちていない。レビュー自体はむしろ軽くなっており、おそらく AI の成果物のほうが構造が整っているためだ。この点は別の実験も支えている。6 月のあるプレプリントは 64 回の対照実行で、委任の契約を明文化しても「正しさ」には影響がないことを見出した。その難易度帯では、もともと全問正解だったからだ。改善したのは何をしたのかが読み取れることで、変更ファイル一覧が付く割合は 7% から 93% に跳ね上がった。ここには割り引きが一つ要る。64 回の受け入れ判定と読みやすさの採点は、すべて LLM の審査役が行っており、人ではない。「人にとって本当にレビューしやすいか」は、まだ人による確認を経ていない。本当に破綻しているのは前の区間だ。成果物ができてから、誰かが注意を割いてくれるまでの空白である。

その空白こそ、先に定義した工程にあたる。だから、「注意は検証の前払いコストである」という命題には、今や値札が付いた。 このデータでは、前払いコストはレビュー本体の 5 倍を超え、しかも悪化しているのはこの区間だけだ。

ただし、この判断には埋まっていない穴がある

この判断に最もわかりやすい反論をぶつけてみる。AI のマージリクエストは大きく、大きいものはもともと長く待たされる。

この反論には根拠がある。同じ報告で、AI が関わったマージリクエストの第 75 パーセンタイルは 408 行、人が書いたものは 157 行で、2.6 倍だ。そしてマージリクエストの大きさと拾われる速さには強い相関がある。小さいマージリクエストは 20 倍速く拾われるという分析があり、Google 社内の経験則でも、200 行を超えるとレビューの質がはっきり落ち始めるとされる。400 行の塊を見た人が無意識に後回しにするのは、エージェントに関する理論を一つも持ち出さずに説明できる。

この反論は退けられなかった。 LinearB は体積をそろえたうえで待ち時間を計算し直しておらず、再計算に使える原データも手元にない。したがって 5.25 倍のうち、どこまでが「同時に走る件数が多すぎて注意が回らない」ことによるもので、どこまでが単に「この塊は大きいから後で見る」ことによるものなのか、本稿では分けられない。

手がかりは一つだけあり、両方が効いていることを示唆する。ただし手がかりにすぎない。同じ報告の三分類で、エージェントが丸ごと生成したマージリクエストは約 290 行で、AI が関わった 408 行より小さい。 体積だけが原因なら、全自動の分類のほうが待ち時間は短いはずだ。しかし報告はその分類の待ち時間を単独で公表していないので、これは確かめられていない推測であって証拠ではない。これが本稿最大の未解決点であり、次に取りにいくべき資料である。

第三の数字:システムの均衡解は並べ替えではなく、捨てることだった

二つ目の独立した資料は、この話をさらに見苦しいところまで押し進める。開発組織の稼働データを集計する Faros AI の 2026 年エンジニアリング報告は、22,000 人の開発者、4,000 超のチームの 2 年分のテレメトリーを母集団にしている。手法は、各組織が自組織の中で、AI 採用が最も低かった時期と最も高かった時期のあいだで指標がどう変わったかを比べるものだ。数値はこうである。

• 最初のレビューまでの待ち時間の中央値が 156.6% 上昇
• レビュー所要時間の中央値が 441.5% 上昇(平均値は 199.6% 上昇)
• 一人あたり完了した大型案件が 66% 増、一人あたりタスク処理量が 33.7% 増、一人あたりマージ率が 16.2% 増
• マージリクエストの 31.3% が、一度もレビューを経ずにマージされた
• マージリクエストあたりのインシデント比率が 242.7% 上昇、コードの手戻り量は 861% 増

31.3% には公開されていない部分がある。Faros は「レビューを経た」をどう数えたかを説明していない。自動チェックやボットの承認を含むのか、母集団にボットが出した変更を含むのかもわからない。したがって「人が一度も見ていない」にどこまで近いのかは、控えめに読むしかない。

このデータの手法には固有の問題があり、先に言っておく必要がある。組織内の「低採用期と高採用期」の比較は時間の前後比較で、その 2 年間に変わったのは AI だけではない。チームの増員、プロセスの改定、人の入れ替わりがすべて混ざっている。だから変化の幅を精密な値として扱うことはできない。それでも LinearB とは会社も顧客層も計測方法も異なり、「最初のレビューまでの待ちが大きく伸び、レビュー本体はボトルネックではない」という方向で両者は一致する。この一致は、どの単独の数字よりも重い。

本当に注意すべきなのは 31.3% だ。三つの数字を並べる。三分の一は誰もレビューせずに入り、AI の成果物は三分の一しか入らず、最初のレビューまでの待ちは何倍にも伸びた。浮かぶ絵は「注意の配分がうまくいっていない」ではなく、「注意がそもそも足りず、システムが見つけた均衡解は捨てること」だ。 しかも漏れは両端から起きる。一方の端は見ずに通すことだ。リスクは本番投入の後に押しやられ、マージリクエストあたりのインシデント比率の 242.7% 上昇はここに掛かっている。実在する 182 のプロジェクトを長期追跡した研究も、プロジェクトのレビュー免除率が 10 ポイント上がるごとに、エージェントが寄与したコードの後続の保守負担が約 6% 増えると測った。もう一方の端は永遠に誰も拾わないことだ。マージされなかった三分の二のうち、どれだけが放置されたまま期限切れになったのか、データは語らない。ただしゼロではありえない。

この診断は「見るべき一件が見つからない」より一段深刻である。「どれを先に見るか」という問いは、すべての成果物がいずれは見られ、順番だけが未定の世界を前提にしている。実測された世界では、成果物の大半はそもそも見られない。順序の問題と容量の問題では、要る解法が違う。順序の問題に要るのは並べ替えのインターフェースで、容量の問題に要るのは人が見るべきものを減らすことだ。

道は二本ではなく三本——そしてモデル企業は半年前に参入していた

容量の問題だと分かると、当初の分岐図も描き直しが要る。観察対象として記録した当時、本紙が書いた分岐は二者択一だった。制約が本当に注意の層にあるなら、道具はプレビューと通知の面に収束する。こちらに賭けたのが Superlogical だ。このスタートアップの創業者が冒頭のベテラン開発者で、製品プレビューでは、三本指で下にスワイプするとすべての作業タブをその場でプレビューできる機能を看板にした。同社が掲げた目標は、注意を要するセッションを見つけやすくすることである。制約がまだ実行の層にあるなら、道具は隔離環境とエージェント群を動かす基盤に収束する。こちらに賭けたのが Cursor だ。コーディングエージェントの道具を作るもう一つの会社で、公式の更新履歴は、タスクを端から端まで処理する並列エージェント群をチームが走らせられるようにすると明言し、そのために設定可能な開発環境、複数リポジトリにまたがるワークスペース、バックグラウンドでの隔離ブランチを用意した。

調べた結果、この二者択一には問題が二つある。

第一に、「モデル企業はデスクトップ級のリアルタイム・インターフェースまでは取り込めない」という一文は、書かれた時点ですでに成り立っていなかった。 当時の理由づけはこうだった。モデル企業は足場なら取り込めるが、デスクトップ級のリアルタイム・インターフェースは取り込めない。Superlogical 自身、ボトルネックはモデルではなく、十分に優秀なネイティブ UI エンジニアが見つからないことだと語っていた。だが時系列が合わない。

• 2026 年 2 月 2 日、OpenAI はデスクトップ版 Codex を公開した。同社自身の説明では、エージェントを束ねる司令塔として作ったもので、売りは複数のタスクを同時に任せ、並列で走らせ、まとめて監督できることだった(3 月 4 日に Windows 版も出た)。
• Anthropic の Claude Code では、GitHub で公開されている更新履歴(anthropics/claude-code の CHANGELOG.md)の中で、すべてのバックグラウンドセッションを並べる画面の細部がすでに作り込まれている。2.1.210 版では、エージェントのフッター表示が入力待ちのバックグラウンドエージェントの数を示すようになり、数が変わると色で短く強調される。2.1.212 版では、サンドボックス待ち、外部ツールの入力待ち、設定の承認待ちのセッションの表示を「作業中」から「入力が必要」に改めた。2.1.206 版は、この状態がときどき「作業中」に戻ってしまう不具合を修正している。本稿執筆時点で手元の環境に入っている版は 2.1.233 で、三項目とも出荷済みだ。

最後の一項は、前の二項より説得力がある。状態表示の不具合を直す必要が出るのは、その機能が利用者の手元に十分長くあり、よく使われてきた証拠だ。 コンセプト動画の段階にとどまる機能に、この種の不具合は出ない。したがって「モデル企業から最も遠い一角」という判断が書かれたとき、最大手のモデル企業二社はすでにその中にいた。(公平を期せば、出荷は出来のよさを意味しない。Superlogical が賭けているのはリアルタイム描画の品質とデスクトップ級の操作感で、更新履歴の一行では体験が同等だとは証明できない。正しい絞り込みはこうなる。この層はもはやモデル企業の手が届かない場所ではないが、どこがうまく作るかはまだ決着していない。)

第二の問題のほうが重要だ。そもそも二者択一ではなかった。市場には三本目の道があり、しかも最も早く走り出していた。

31.3% が一度もレビューを経ずにマージされたという数字に戻る。この数字には二通りの読み方がある。一つは放棄だ。もう一つは、レビューされたが、レビューしたのが人ではなかったという読み方である。

三本目の道の証拠は実在するだけでなく、前の二本より早い。2025 年 9 月、OpenAI の Thibault Sottiaux 氏は公式ポッドキャストで、自社のコードレビュー・ボットを作った動機をこう語った。

"We started to notice that the big bottleneck for us was with increased amounts of code needing to be reviewed is like the amount of review simply that people had to do on the teams."

レビューすべきコードが増えるにつれ、最大のボトルネックはチームの人がこなさなければならないレビューの量そのものになった、という趣旨だ。これは 11 か月前の発言で、本稿の判断の元になった三つのデータ点より一年近く早い。しかも同社の解決策は、人のためにもっとよいダッシュボードを作ることではなく、レビューそのものも委任することだった。範囲を絞った高信号のレビューモードを作り、差分を見るだけでなく、その変更の背後にある意図と契約を理解したうえで、コードがその意図を本当に実現しているかを検証させる。社内に投入した結果について、同氏は "It was quite successful and people were upset actually when it broke because they felt like they were losing that safety net" と述べた。

したがって正しい分岐図は三本の道で、それぞれボトルネックを別の場所に置いている。

1. 注意の面:ボトルネックは、人がどれを見るべきか見分けられないこと。解法は並べ替え、プレビュー、通知。

2. 実行基盤:ボトルネックは、エージェントを走らせる環境のコスト。解法は隔離環境、複数プロジェクトの横断、キャッシュ、ガバナンス。

3. レビューも委任する:ボトルネックは、人のレビューの総量。解法は別のエージェントに先にレビューさせ、人はそのエージェントが手を挙げた箇所だけを見ること。

前の三組の計測は、この三本の道に対して中立ではない。「最初のレビューまでの待ちは 5 倍に伸び、レビュー本体はむしろ速くなり、三分の一は誰もレビューせずに入る」という組み合わせが指しているのは、順序の乱れではなく容量の不足だ。そして並べ替えのインターフェースでは容量の問題は解けない。八件をきれいに並べても、人が見終えられるのは二件である。容量に直接手を付けるのは、三本目の道だけだ。

ただし三本目の道にも未解決の問題が二つあり、結論として扱うことはできない。一つは、根拠がベンダー自身による社内採用の自己申告で、外部の計測がないこと。もう一つは、機械のレビュー役自身も人が見るべきものを生み出すことだ。レビュー役が挙げる手も、順番を待つものの一つになる。この道が仕事量を消したのか、仕事量の形を変えただけなのか、答えられるデータは今のところない。

さらに、三本の道のどれも扱わない、人を要する場面がもう一つある。エージェントが途中で、人にしか押せないボタンの前で止まる場合だ。8 月 9 日と 10 日、Flask の作者は二日続けて同じ種類の故障を記録した。パスワードマネージャーのブラウザ拡張も、パッケージ公開の信頼設定も、ブラウザの前に座る人を前提に設計されており、エージェントは入口までしか進めず、残りは「ここをクリックしてほしい」と人に頼むしかなかった。この種の中断は「どれを先に見るか」という並べ替えの問題でも、レビュー容量の問題でもない。手順がそもそも最後まで通らない問題である。要るのは四つ目のもの、つまり機械でも最後まで通れる承認インターフェースへの作り替えだ。

これは誰にとって何を意味するか

三本の道と容量不足という診断は、立場ごとに違う形で効く。

• エージェント基盤を評価する企業: 調達の評価項目は一つ増え、しかもよくある問い方より精密になる。最もよく聞かれる「どのタスクが人を要するかをどう知らせるか」は、三本の道の一本目しか覆っていない。評価の焦点は三点に移る。(a) 人が見るべき成果物の総量をどう減らすか(レビュー層を内蔵しているか、その誤検知率はどれほどか)。(b) 成果物が人の目に触れるまでの待ち時間について、ベンダーの顧客での実測値はいくらか。(c) 人が見ないまま本流に入った比率はいくらか。三つ目が最も正直な指標である。このシステムが実際にどれだけの監督を手放したかを測るものだからで、大半のベンダーは自ら報告しない。
• エンジニアリングチームを率いる組織: 本稿で最も実務に直結する一文は、納品の上限はもはや書く側にはないということだ。一人あたり処理量(Faros のデータでは +33.7%)だけを見ていれば見栄えのよい数字が並ぶが、同じチーム群でレビュー待ちの中央値は 156.6% 上がり、変更の三分の一は誰も見ないまま入り、変更あたりのインシデント比率は 242.7% 上がっている。勤務の組み方への含意も直接的だ。エージェントが夜に走る組織では、朝一番に夜間の成果物を片付ける担当が名指しの一人として決まっていなければ、成果物は自発性頼みになり、引き取り手のない在庫として積み上がる。32.7% というマージ率の一部は、こうして生まれている。
• この領域で事業を作る企業と投資家: 「注意の面はモデル企業から最も遠い」という投資の論拠には修正が要る。最大手のモデル企業二社はすでにこの層で出荷しており、うち一社は細部の不具合まで直している。残る防御可能な余地は「この画面があるかどうか」ではなく、二か所にある。一つはベンダー横断である。モデル企業が作るのは自社エージェント用の画面だけで、実際の八件は三社の道具にまたがって走る。もう一つは順序ではなく容量を扱うことだ。並べ替えの天井は、人が一回の持ち場入りで見られる量で決まり、削減の天井は並べ替えより一桁高い。三本目の道については、真のボトルネックが容量であるなら、レビューも委任する方向は最大手のモデル企業が自社の社内ツールで裏書きしており、しかも三組の計測より 11 か月早い。ただし現時点ではベンダーの自己評価しかなく、外部の計測はない。機械のレビュー役自身も人が見るべきものを生み出すので、「仕事量を消したのか、形を変えただけなのか」が、この道の評価額でまだ空欄のままの一マスである。
• 個人で道具を買う開発者: 大半の人は八つのウィンドウを同時に見張ってはいない(外部利用者の三分の二は一度も並行利用していない)。ありがちなのは、大きな仕事を一つ投げ、席を離れ、戻って大きな成果物の塊に向き合う形だ。この形で価値を生むのはダッシュボードではなく、その塊を小さく、構造をわかりやすくすることである。契約の実験が測ったのもこの点だった。委任の指示を明確に書いても高い正答率は買えない(その難易度帯はもともと全問正解だった)。買えたのは事後に何をしたのかが読み取れることで、代わりにトークンが 13%、待ち時間が 38% 増えた。「AI の成果物は 2.6 倍大きく、待ちは 5 倍長い」という先の数字と比べれば、割に合う交換である。ただし、この実験の採点役が人ではなくモデルだった点は残る。

本誌の見立て

「エージェントが指示を安くし、稼働を長くしたことで、人のボトルネックは指示の設計から注意へ移った」という方向は、互いに独立した大規模な計測三組に支持されている。最初のレビューまでの待ちは、別々のベンダーの二つのデータでどちらも大きく伸びた(LinearB の 810 万件のマージリクエストでは 200 分が 1,050 分に、Faros の 2 年分のテレメトリーでは中央値が 156.6% 上昇)。一方でレビュー本体は遅くなっておらず、むしろ速くなっている。ただしこの判断は単位を取り違えており、判断の一部だった堀についての命題はすでに覆された。単位について:順番を待っているのは「セッション」ではなく成果物であり、見るべき主要な数字は同時に開いているウィンドウ数ではなく、マージリクエストの待ち時間である。並行そのものは広がっていない(外部の組織利用者の 67.4%、クエリ共有に同意した外部の個人利用者の 63.9% は一度も並行利用していない)。広がったのは一件の長大化で、8 時間級のタスクを投げる利用者の割合は 2.1%→25.6% になった。堀について:モデル企業はこの層を取り込めないという主張には、判断が書かれた時点ですでに反例があった(OpenAI のデスクトップ版 Codex は 2026-02 の公開時からエージェントの司令塔を名乗り、Anthropic のバックグラウンドエージェントの「入力が必要」の件数表示は出荷済みで、不具合修正まで進んでいる)。さらに重要なのは、この競争の道が二本ではなく三本(注意の面、実行基盤、そしてレビューそのものの委任)であることだ。三組の計測がそろって指しているのは順序の乱れではなく容量の不足であり(31.3% が一度もレビューを経ずにマージされ、AI の成果物の 30 日以内マージ率は 32.7%)、並べ替えだけを手がける路線には不利に働く。この判断の最大の未解決点は、AI の成果物の待ち時間 5.25 倍のうち、どこまでが注意で、どこまでが体積か(AI の変更は 2.6 倍大きく、大きな変更はもともと長く待たされる)であり、現在公開されているデータでは切り分けられない。

この判断を覆す条件:第一に、変更の大きさをそろえたうえで待ち時間を計算し直したデータが出ること。体積をそろえた後に AI の成果物の待ちの差がゼロ近くまで縮むなら、「注意は独立した工程で、すでに値札が付いた」という本稿の中核の読みは無効になり、判断全体は「もっともらしいが、まだ実証されていない」状態に戻る。これが最も取りにいくべき資料であり、本稿で最も脆い一節でもある。第二に、「成果物が最初のレビューを受けるまでの時間」が翌年以降のベンチマークで下がること。LinearB と Faros はどちらも年次で発表しており、次の版が観察の窓になる(この窓は本紙が独自に設けたもので、どちらの社も時期を約束していない)。下がれば、ボトルネックは構造的な制約ではなく一時的な渋滞だったことになり、この項は格下げになる。第三に、三本目の道(レビューの委任)について、人のレビュー総量を減らしていない、形を変えただけだと示す外部の計測が出ること。その場合「容量が順序に勝る」という推論は崩れ、三本の道は互角に戻る。第四に、外部の組織利用者の並行率が以降の数値で大きく上がること(本紙が独自に置く閾値:一度も並行利用しない人が五割を切る)。その場合「並行は広がっていない」という判断は反転し、並べ替えのインターフェースの市場は本稿の見積もりよりはるかに大きくなる。第五に、モデル企業が注意の面を自社エージェント限定の閉じた機能として作り、ベンダー横断に開かない場合、「ベンダー横断が残る防御可能な余地だ」という判断は裏付けられる。逆に、どこか一社のモデル企業がベンダー横断のセッション取り込みを開放すれば、この余地も閉じる。

本記事は日本語版・英語版・中国語版と同一の調査と判断にもとづいて書かれています。

出典にはリンクを付け、原文書と報道を区別し、確かめられなかった点を明記しています。

最後までお読みいただきありがとうございます。ご意見・ご感想は [email protected] までお寄せください。

他言語版が引いた出典

以下の出典は、この記事の他言語版の本文ではリンクされているが、この版の本文にはないため、ここに補う。

• github.com/anthropics/claude-code/blob/main/CHANGELOG.md