【BUZZ SYNC】「AIが速いほど、設計の悪さが露呈する」——やねうら王氏の√t則が、AI時代の発注者に突きつける現実

「AIにプログラムを書かせる時代、本質的なのは書くスピードではない」——将棋AI「やねうら王」の開発者として知られるやねうら王氏（@yaneuraou）が2026年4月21日に投稿した一連のポストが、AI開発の現場に静かな波紋を広げている。

主張は明快だ。AIがどれだけ速くコードを書けても、実開発では必ずオーバーヘッドが乗る——コンパイル、テスト、デバッグ、影響範囲の調査。問題はそのコストが、コード総量が増えるにつれてどう膨らむかである。

コードを10倍にするのに、100倍の時間がかかる世界

やねうら王氏は、オーバーヘッドの増え方を2つに単純化する。

• ケース1：オーバーヘッドがコード量に比例して増える（例：フルビルド時間）
• ケース2：オーバーヘッドがlog程度に抑えられる（例：二分探索で原因を絞れるデバッグ）

計算すると、結論は残酷だ。ケース1の世界では、コードを10倍にしたければ100倍の時間がかかる。ケース2の世界なら、ほぼ10倍で済む。同じAIを使っていても、構造次第で開発速度は一桁変わる。

「ソフトウェア工学のかなりの部分は、1の世界をいかに2に近づけるかという試みだった」と氏は続ける。モジュール分割、依存の局所化、テスト単位の分離——半世紀にわたる設計論の蓄積は、この一点に収束する。マイクロサービスやクリーンアーキテクチャもこの文脈で理解できる。

AI時代、設計の悪さはむしろ露呈する

ここから議論は核心に入る。AIが速く書けるようになると、設計の良し悪しは隠れるのではなく、かえって目立つようになる。

生成速度が上がるほど、相対的にレビュー・統合・検証のコストが支配的になる。設計が悪く、影響範囲が広く、テスト単位が粗いプロジェクトでは、せっかくのAIの生産性がオーバーヘッドに食われてしまう。

氏の結論はこうだ。AI時代のエンジニアに求められるのは、プロンプトの巧拙ではなく、システムを分割し、影響範囲を閉じ込め、検証単位を細かく設計して、開発全体のスケーリング則そのものを改善する能力である、と。

経営層が読み替えるべき「発注者リテラシー」

この議論は、コードを書かない経営層にも直結する。なぜなら、AI導入でコード生産性が数倍になっても、統合コストが線形に増える組織は、結局「10倍のコードに100倍の時間」という√tの呪縛から抜けられないからだ。

内製チームでも外注先でも、生産性を決めるのは以下の問いに答えられるかだ。

• タスクの「影響範囲」を事前に列挙させているか
• 1つの変更を1つのコミットに絞らせているか
• テストを書く単位を細かく指示しているか
• 「ついでの修正」を禁止できているか

AIコーディングツール（Claude Code、Cursor、GitHub Copilotなど）に巨大なタスクを丸投げすれば、AIは最も近くにある大きなファイルに追記し、影響範囲が読めない変更を量産する。これが「生成は速いのに、プロジェクトは遅い」現象の正体である。

SYNCONの視点：AI時代の真の差は「設計を指示できるか」

経営層がAIコーディングツールを評価するとき、つい「どれだけ速くコードが書けるか」に目が行く。しかしやねうら王氏の指摘が正しいなら、本当に差がつくのはその先だ。

CLAUDE.mdやカーソルルールといった「AIへの設計指示ファイル」を整備できるかどうか。1ファイルの行数上限、変更スコープの明示、コミット粒度のルール——こうした数値化された制約を与えられる組織は、log Cの世界で開発できる。与えられない組織は、√tの世界に留まる。

AIが書く速度は、もはや差別化要因ではない。差がつくのは、AIに正しい制約を与えられる「発注者側の設計力」である。やねうら王氏のポストが示しているのは、そういう時代の到来だ。

元ポスト：やねうら王氏のポストを読む