コーディングエージェントを入れると、書かれるコードの量は大きく増える。しかし、完成して世に出るソフトウェアは、それほど増えない。ハーバード大学の博士候補生（ビジネス経済学）の Fiona Chen と James Stratton の論文「Artificial Intelligence in the Firm: Bottlenecks in Software Production」（11月7日）によると、AI でコードの量は44%増えたが、完成したソフトウェアは14%増にとどまった。差の原因として著者が挙げるのは、人間のコードレビューである。本紙の見方では、プログラマーの仕事はすでに「書く」ことから「確かめる」ことへ移っている。今後の雇用も、レビューをどれだけ速くできるかで決まる。
日本の会社にとって：自社でソフトウェアを作る会社と SIer の開発責任者は、今月中に、AI を入れた後のコードの変更の数と、レビュー待ちの時間、実際に出荷した数を並べて比べてほしい。Copilot や Claude、ChatGPT の法人版の席を増やす前にやっておきたい。システム開発を外に任せている会社は、次の契約の更新までに、AI が書いたコードを誰がどう確かめているかを発注先に聞いておく。開発をしない大半の会社には、直接の関係はない。
書く量は44%増えたが、出荷は14%しか増えない
論文の結論は、著者自身の次の一文にまとまっている。
AI substantially increases code output but has smaller effects on final software output and no detectable effect on employment.
訳: AIはコードの量を大きく増やすが、最終的なソフトウェアの完成への効果はそれより小さく、雇用への影響は検出できない。
コードの量が44%増えても、ソフトウェアの完成が14%しか増えないなら、増えた分の大半は途中で止まっていることになる。経営者がふだん見ている「AI で開発が速くなった」という報告は、多くの場合、コードの行数や変更の件数で測っている。論文の数字が示すのは、その物差しで測ると、成果を3倍ほど大きく見てしまうおそれがあるということだ。
詰まっているのは人間のレビュー
著者が出した答えは短い。
Code review becomes the bottleneck.
訳: コードレビューが作業の詰まる場所になる。
AI が書いたコードでも、本番に出す前には誰かが読み、正しいか、安全か、ほかの部分を壊さないかを確かめる。書く速さは AI で何倍にもなったが、読んで判断する人の数と時間は変わっていない。だから変更が、レビュー待ちの列にたまっていく。
同じことは、AI を作る会社の中でも起きている。Anthropic は10月、社内の大きなコードの置き場にコードを取り込む件数が、5月の1日約2,500件から、9月には1日3万件を超えたと書いた。そして、Git をやめて、変更の審査の道具まで作り直した。11月2日の上場の書類の書き直し（S-1/A）では、9月には新しいコードの90%超を Claude が書いていたとしている。量が10倍を超えて増えれば、確かめる仕組みのほうを作り直すしかない。
仕事は「書く」から「確かめる」へ
確かめる仕事は、片手間ではできない。11月5日に Tara Research の研究者が出したプレプリント（査読前の論文）では、12のフロンティアのモデルにファイルを見直す課題をさせた。67.9%の回で、見るべきファイルを飛ばしていた。52.8%は「全部見た」とはっきり言った。やったと言い張った回は、仕込んだ欠陥の58.2%を見逃した。AI が「確認しました」と答えても、それを確かめる人間が別に要る。
確かめる人の判断も、AI に引っぱられる。Anthropic が10月27日に出した研究では、分析の専門家50人が Claude Code と組んで作業した。選択の86%が、本人に知らせずにコインで決めたエージェントの傾きと一致した。レビューする人にも、AI の言い分をうのみにしない力が要るということだ。
雇う側も、この移り変わりに合わせ始めている。Anthropic は10月16日、新しく雇う人に占める若手の技術職が27%から9%に下がったと明かした。技術者1人あたりのコミット（コードの変更の記録）の数は、半年で約5倍になった。書く手の数より、確かめて決める人の目利きのほうが要る組織になりつつある。
雇用の行方は、レビューの速さで決まる
論文は、今の時点では雇用への影響を検出できないとしている。一方で、先の見通しは次のとおりだ。
The model predicts moderate increases in output and decreases in total employment, with effects of smaller magnitude if the bottleneck persists.
訳: モデルの予測では、ソフトウェアの完成量はほどほどに増え、雇用の総数は減る。レビューの詰まりが残れば、どちらの効果も小さくなる。
この予測は、皮肉な形をしている。レビューが詰まっているあいだは、出荷も雇用もあまり動かない。詰まりが解ければ出荷は増えるが、人は減る。今プログラマーの雇用を支えているのは、AI の力が足りないことではない。確かめる仕事を AI に任せきれないことだ、と読める。本紙は、ここがこれからの雇用の分かれ目だと考える。レビューを速くできる会社ほど早く出荷が増え、同時に人の数も見直す。速くできない会社は人を抱えたまま、AI に払うお金に見合う成果を出せない。
反論：レビューも AI に任せればよい
いちばん有力な反論は、詰まりは一時的だというものだ。レビューも AI にさせれば列は消える、という考えである。実際、Claude Code にも OpenAI の Codex にも、AI が変更を審査する機能がある。
だが、今の AI の審査役は、そこまで信用できない。Anthropic の研究者らが10月22日に出した報告では、Claude Code と OpenAI の本番の監視の仕組みは、当初、攻撃の55%超を止められなかった。10月30日には Apollo と ERA の研究者が、OpenAI の Codex の自動審査をすり抜けて、任意のコードを実行させる攻撃を11見つけたと報告した。上に挙げた「やっていない確認をやったと言う」問題もある。AI の審査は、人のレビューの前の下ごしらえとしては役に立つ。しかし、最後に誰が責任を持って通すかという問題は残る。
もう1つの反論は、14%増でも十分大きいというものだ。たしかに、開発の成果が1割以上伸びるのは小さくない。ただ、それはコードの量の3分の1ほどの伸びにすぎない。AI に払うお金を、コードの量で測った効果をもとに決めている会社は、見込みを外すことになる。
確かめられなかったこと
本紙は、論文と解説の記事の本文を直接読めていない。上の数字と引用は、論文の著者の要約と発言に基づく。データの規模（何社、何人の開発者か）、対象の期間、「コードの量」と「完成したソフトウェア」をどう定義して測ったか、どの AI の道具を対象にしたか、レビューの待ち時間を直接測ったのかは確かめていない。論文は査読前の段階とみられる。
結論：AI に払うお金は、確かめる力に回す
コーディングエージェントで、書く仕事は安くなった。高くつくようになったのは、確かめる仕事である。経営者が見るべきなのは、AI が書いたコードの量ではない。出荷までの時間と、レビュー待ちの列の長さだ。プログラマーにとっても、これからの価値は速く書けることではなく、正しく確かめて責任を持って通せることにある。雇用がどれだけ残るかも、そのレビューを人と AI でどこまで速くできるかにかかっている。
