コンパイラはこれまでにプログラミングを1000倍加速してない
リーナス・トーバルズは東京開催のOpen Source Summit Japan基調講演で「コンパイラはこれまでにプログラミングを1000倍加速してきた」と言っているが、「コンパイラはこれまでにプログラミングを1000倍加速してきた」エビデンスはない。
リーナスの発言意図
現在の AI の過大評価に対する警鐘としての発言だ。しかし「コンパイラはこれまでにプログラミングを1000倍加速してきた」エビデンスがなく、コンパイラの影響力を逆に過大評価している。
現実
UNDERSTANDING SOFTWARE PRODUCTIVITY では、ある研究では Ada を用いたプログラマは Fortran や Pascal 風言語に比べて「2〜4倍」ほど高い生産性を示したと報告している。この研究ではコンパイラ単体ではなく「言語＋コンパイラ環境」の違いを扱っており、また測定指標や前処理（プリプロセッサによる行数の増減など）の影響があるため、素直に「コンパイラが4倍にした」とは解釈できないとサーベイ中で指摘している。
コンパイラ機能の一部とみなせる「静的な型チェック」の影響を測った 1996 年の SEI 報告では、ANSI C（プロトタイプ宣言に基づくインターモジュール引数チェックあり）と K&R C（引数チェックなし）を比較する制御実験を行った結果、ANSI C を使った被験者の方がインターフェースエラーが有意に少なく、ライブラリインターフェースに慣れた後はエラー除去が速く、時間当たりに実装できる機能量も増える、すなわち生産性が向上していると報告されているが、効果量は「1000倍」ではなく「統計的に有意だが数倍レベル」の改善にとどまる。
動的プログラム解析ツール（プロファイラや実行トレース分析ツールなど）が開発者のデバッグ効率・機能実装速度を向上させるという実験結果もあり、ある研究ではそのようなツール利用により、同じ時間でより多くの機能を実装できたと報告している。ただし、改善幅は数十〜数百パーセント程度であり、オーダーとしては「数倍」であって「1000倍」といった桁違いの向上ではない。
そもそもソフトウェア開発の生産性の計測が難しい
ソフトウェア生産性は、ユースケース・組織・開発プロセス・問題の難易度など多くの要因に依存しており、「コンパイラだけの効果」を分離して測ること自体が難しい。UNDERSTANDING SOFTWARE PRODUCTIVITY でも、コンパイラや言語以外に、開発環境（IDE、バージョン管理、ビルドシステム）、ハードウェア性能向上、ライブラリやフレームワークの充実などが複合的に効いているため、特定の技術だけに大きな倍率を割り当てることには慎重であるべきだと論じている。
歴史的な比較（機械語手書き→アセンブリ→高級言語→現在の最適化コンパイラ）を行おうとすると、そもそも問題規模や品質要求、その時代の典型的な開発対象が全く違うため、「同じ問題を昔のツールで解くと何人月かかったか」を厳密に測ることができない。そのため、文献では「高級言語や対話環境、タイムシェアリング OS などが一桁〜数桁の生産性向上をもたらしてきた」という定性的な議論はあっても、「コンパイラが歴史的に 1000 倍」というような具体的な倍率は提示できない。
ソフトウェア開発の生産性を向上させた技術の例
ソフトウェア開発の生産性向上は以下のような技術の積み上げによる。
- コンパイラ
- プログラミング言語
- IDE/エディタ
- デバッガ
- チャットツール（Discord・Slack など）
- バージョン管理（git・SVN など）
- OS（linux など）
- インターネットとその高速化
- クラウド
- オープンソースソフトウェア
- Continuous Integration
- Continuous Delivery
- ハードウェアの高速化
- 仮想化技術
- DB
- など
AI はソフトウェア開発の生産性を向上させるか？
生産性を向上させるにはボトルネック工程の生産性を向上させる必要がある。ボトルネック工程の生産性を向上させずに他の工程の生産性を向上させると、ボトルネック工程の前にタスクがたまる。
ソフトウェア開発における典型的なボトルネック工程はレビューだ。現在 AI によって作成されたプルリクエストのレビューが追い付かない事象が多発している。これは典型的な生産性向上の失敗例で、ボトルネック工程を改善せずに他の工程を改善するのは製造業でよく見る光景だ（もちろん工場の生産性は上がらず資金繰りも悪化する）。
レビューがボトルネックだとすると、AI がレビューするか、AI を信用してレビューをスキップすると生産性は向上する。しかし現在の性能の AI ではその両方とも難しい。
AI の生成するコードの品質はよくない
2026 年１月現在の AI が生成したプルリクエスト（PR）は、人間が作成したものに比べてサイズが 154% 大きく、受け入れ率が 32.7% と極めて低い（人間は 84.4%）という現実がある。
さらに AI の生成したプログラムの 62.07% に脆弱性が含まれるとする研究がある。
LinearB の報告では、AI 生成コードを含む PR は、レビューが開始されるまでに人間の 4.6 倍の時間を要するが、一度レビューが始まれば２倍速く処理されるという奇妙な挙動を示す。これは、レビュー担当者が詳細な検証を諦め、表面的なチェックのみで承認してしまう「オートメーション・バイアス」や、逆に疑心暗鬼に陥って検証に膨大な時間を費やすという二極化が起きていることを示唆している。
コードレビューは元来、バグの発見だけでなく、知識共有の場としても機能してきた。しかし、AI 生成コードの急増により、シニアエンジニアは「AI が書いたコードのデバッグ」という付加価値の低い作業に追われ、週平均で 5.8 時間をレビュー関連のボトルネックで喪失している。この検証オーバーヘッドは、特に経験豊富な開発者の生産性を 19% 低下させるというランダム化比較試験の結果も出ている。
バグを捏造する AI
Haolin らの研究によると、LLM は自然言語の仕様書とコードを照らし合わせる際、実際には仕様を満たしているコードに対しても「要件を満たしていない」あるいは「欠陥がある」と過度に批判的な判断を下す傾向がある。驚くべきことに、プロンプトに「説明」や「修正案」を求める複雑な指示を追加すると、推論ステップは増えるものの、誤判定率が逆に上昇するという結果が出ている。これは、モデルが指示に従って何らかの欠陥を「見つけ出さなければならない」というバイアスに陥り、存在しないバグを捏造するためであると考えられる。
外部リンク
AI のレビューについては PRのレビューが追いつかない！もう人間がボトルネックなので、気合いではなく仕組みで少しずつなんとかしていくが参考になる。この記事では AI にレビューをさせるのではなく、AI に PR を分類させて、リスクの低い PR を自動マージしている。