生成AIの普及でソフトウェア開発の生産性は高まっている。ただ、AIが生成するコードが増えるほど、レビューや修正、保守にかかる負担も重くなる。今後の焦点は、AIにどれだけ多く書かせるかではなく、新規生成をどこまで抑え、検証済みの資産をどう再利用するかに移りつつある。

Gigazineが5月29日（現地時間）に報じたところによると、WaveMakerの共同創業者で最高技術責任者（CTO）のディパク・アヌパリ氏は、AIコード生成ツールの限界に言及し、「問題は、生成したコードをどう検査するかではなく、そもそもどれだけ少なく生成するかだ」と述べた。

同氏は、AIコーディングツールが反復的な開発作業の効率化に寄与している点は評価する。入力フォームやデータテーブル、API連携の基本構造といった定型コードを素早く生成でき、プロトタイプ開発や社内業務アプリの構築で効果が大きいという。

一方で、生成コードが増えれば、人手で確認し、修正しなければならない対象も増える。この点が大きな課題だと指摘した。

開発現場では、AIが書くコードの比率が急速に高まっている。ソフトウェア品質プラットフォームのSonarが公表した2026年の開発者調査では、リポジトリに反映されたコードの42％がAI支援で作成された。このうち約29％は、人手によるレビューを経ずにそのままマージされたという。

コードの生産速度は上がっている一方で、品質検証の体制がそのスピードに追いついていない可能性がある。企業では一般に、AIが生成したコードを後から検証する手法が取られており、静的解析ツールやリンター、セキュリティスキャン、アクセシビリティ検査、画面比較テストなどで問題を洗い出している。

ただ、アヌパリ氏は、こうしたやり方では根本的な解決になりにくいとみる。アプリケーション数が少ないうちは対応できても、数十のサービスを同時に運用し始めると、レビュー対象となるコード量は急速に膨らむためだ。AIによって開発速度を引き上げても、検証や保守の負担が再び開発者の時間を圧迫することになる。

そこで同氏が代案として示したのが「Assembly Model（アセンブリーモデル）」だ。AIが毎回ゼロからコードを書くのではなく、検証済みのコンポーネントやライブラリを優先的に再利用する考え方を指す。例えば「検索機能付きの顧客一覧画面を作りたい」という要件に対して、新たにテーブルコードを生成するのではなく、社内で検証済みのテーブルコンポーネントを選び、必要な設定だけを適用する。

狙いは、新規に記述するコードそのものを減らすことにある。ボタン、入力フォーム、認証画面、データ一覧といった構成要素を、セキュリティやアクセシビリティの検証を終えた状態で繰り返し活用すれば、アプリケーションごとに同じ検査を何度も繰り返す必要は薄れる。AIはデータ接続や画面遷移など最小限の範囲を担い、業務ロジックや外部システム連携など不可欠な部分だけを新たに生成する形だ。

この原則はバックエンドにも当てはまるという。アヌパリ氏は、データ保存構造やAPI、認証基盤、アクセス権限管理は設計ミスの影響が大きい領域であり、単純なコード生成よりも構造的な統制が重要だと強調した。機密情報の管理やロールベースアクセス制御（RBAC）、標準化されたAPI契約をあらかじめ整備すべきだとしている。

もっとも、この方式にもコストはかかる。AIが企業内のルールやコンポーネント構造を理解するには、追加のコンテキスト情報が必要になり、トークン消費も増えるためだ。

それでも同氏は、コードを大量に生成した後で修正や再生成、セキュリティ点検を繰り返すやり方に比べれば、長期的な総コストはむしろ下がる可能性があるとみる。レビュー対象となるコード自体が減るため、重大なバグが検証をすり抜けるリスクも抑えられると説明した。

金融、医療、公共など規制要件の厳しい分野では、このアプローチの重要性はさらに高まりそうだ。生成コードをすべて検証したと示すよりも、検証済み部品を使い、新規生成部分だけを追加レビューしたという構造のほうが、説明責任の面で有利になりやすいからだ。

AIコーディングの次の競争軸は、生成能力そのものではなく、生成範囲の最適化に移りつつある。AIにどれだけ多くのコードを書かせるかよりも、企業が何を新たに作り、何を再利用するのかを先に設計できるかが、生産性と費用対効果を左右する重要な差別化要因になりそうだ。