■ 1. AIのコード生成能力の向上と人間のコードレビューの限界
- 現状のAIコード生成:
- 現状まだ酷いコードを生成することが多い
- ここ1年を振り返るとAIが生成したコードからクラスを切り出してることが多かった
- 2026年の予測:
- おそらく2026年にはだいぶ洗練されるのではないかと予想している
- 画像生成AIが気づいたら指6本画像を生成しなくなったように
- コードレビューの物理的限界:
- いよいよボトルネックになるのは人間のコードレビュー
- 現状でも既にコードレビュー結構しんどい
- 今後仮に毎日100万行のコードが生成される世界になるとすると1日8時間稼働として1時間で約12万行読まないといけなくなる
- 1時間に12万行って単にニュース記事を読むのでも無理
- 8時間ひたすらコードレビューするの自体無理
- 土日もコード生成され続け月曜朝には200万行のレビューが待っている
■ 2. 2026年のAIコードレビューの台頭
- 既存の自動化状況:
- 現状既に静的解析やセキュリティチェックや脆弱性診断は一定Botで可能になっている
- AIのコードが洗練されるのであればそもそも設計不備や既存コードとの不整合などのコードレビューは不要になる
- 必要になるのは今後の拡張性やそもそもの品質チェック
- 参考となる既存事例:
- 量が多すぎて全部は見られない会計監査や製造業の品質管理が参考になる
- AIコードレビューはかなりの確率でこれらの手法を輸入した形になると予想している
- 全数検査の放棄:
- 会計監査も工場検査もまず全数検査を諦めている
- 会計監査ではリスクが高い領域を重点監査する
- 工場では抜取検査やSQCが一般的
- 未来のコードレビュー手法:
- 現状のコードレビューは全行チェックが当たり前だが今後はこれら手法に収斂していく
- 基本的にはAIはSQC的にバグや品質を傾向分析する
- リスクが高い領域のごく一部を時々人間にレビューするように指示する
- そのサンプリングレビュー情報をSQCに反映する形になる
■ 3. 次のボトルネックとしての要件定義
- コードレビュー後のボトルネック:
- コードレビューがAIに置き換わってもボトルネックはなくならず次に移る
- 次に詰まるのは要件定義
- 要件定義の速度変化:
- 人間が精緻に要件定義して3ヶ月かかるところを人間が雑にAIに振ってAIが3分で要件定義するようになる
- 人間が要件定義に3ヶ月かけていたら市場競争に勝てないようになる
- 特に懸念している問題:
- 牛乳を1つ買ってきて卵があったら6つお願い問題
■ 4. 牛乳を1つ買ってきて卵があったら6つお願い問題
- ジョークの内容:
- プログラマの夫に買い物を頼む妻が牛乳を1つ買ってきて卵があったら6つお願いと頼む
- すると夫が牛乳を6パック買ってきた
- 妻がなんで6パックも買ってきたのと聞くと夫はだって卵があったからと答える
- AIの対応:
- この質問を生成AIにするとちゃんと牛乳を1つと卵を6個買ってくれる
- ところがこれが逆に困ったことになる
■ 5. スクラッチ開発の目的
- パッケージとスクラッチの違い:
- ちゃんと牛乳を1つと卵を6個買ってくれるようなシステムが欲しいのであれば業務システムであれば正直ERPなどをそのまま使えばいい
- なぜわざわざスクラッチ開発をしたりあるいは原形をとどめないほどのカスタマイズをするかというと俺の考える最強のシステムや牛乳を6パック買わせるシステムを作りたいから
- AIエージェントの出力傾向:
- AIエージェントに雑に振ると要件は最大公約数的なや平均的なものを出力する
- 変な要件やこだわりの要件を盛り込もうとすると細かく書いてやるしかない
- 牛乳を6パック買わせようとすると牛乳を1つ買ってきてもし卵が売っていた場合は卵は買わずに牛乳を6本買ってきてと要件を伝える必要がある
- 詳細な要件定義の負担:
- これくらいであればそこまでの負担ではないし正直本来の要件定義とはこういうものだろう
- しかし今後の未来はこれを書いてる脇で雑に要件を振って爆速で堅牢なシステムが生まれるものたちとの競争が待っている
- 1つのこだわりが要件定義を遅らせコーディングやレビューを遅らせる
- 特殊要件のためAIが十分整合性を取れずバグの温床になる可能性も増す
- 生産性競争の帰結:
- 今後はこのようなこだわりや俺の考える最強のシステムを作ろうとすると生産性で負ける世界になる
- 要件は平準化や一般化されていく
■ 6. パッケージソフトウェアへの回帰
- スクラッチ開発の必要性の喪失:
- 要件が平準化や一般化されていくとそもそもスクラッチ開発の必要性がなくなっていく
- SAPをノンカスタマイズで使うやSalesforceをそのまま使えばいい
- AIに要件定義や開発させても出てくるものは同じなのだから
- ERPへの回帰:
- まさかの1周回ってERPに業務を合わせるが合理的な世界になる
■ 7. ベンチャー・スタートアップの開発の行方
- 残る可能性の検討:
- 標準化された業務はERPでいいかもしれないがまだシステム化されていないベンチャーやスタートアップ領域のシステム開発は残る
- そもそも要件も一般化されていないので人間が要件定義しなければならない領域はベンチャーやスタートアップに残る
- 実際の予測:
- 残念ながら以下のような流れになると予想している
- ERPや既存SaaSの生産性が異常に高くなる
- AI前提で最適化される
- スクラッチで作るコストが相対的に高騰し経済合理性がなくなる
- ベンチャー・キャピタルがベンチャーやスタートアップに投資する経済合理性がなくなる
- 誰も投資しなくなり結果誰もやらなくなる
- 結論:
- だいたいの業務が既存SaaSやパッケージで足りるようになる
- 結果ベンチャーやスタートアップがやる意味や意義とはという問いがnode_modules級に重くなる
■ 8. まとめ
- 提言:
- もうみんなSAPやSalesforceで働こう