新規プロジェクトでは魔法のように動くAIコーディングエージェント。だが、10年モノの業務システムに突っ込んだ途端、使い物にならなくなる。

これは感覚の話ではない。最新の研究が、数字で証明した。

—

最高性能のAIでも「完成」は14%——成熟リポジトリの壁

「When Coding Agents Outpace Review: Evaluating PRD-Driven Development in Mature Enterprise Repositories」という研究が、この問題を正面から扱っている。

実験の設計はこうだ。成熟した企業リポジトリ上で43のエンタープライズタスクを設定し、750の専門家監査済みコードポイントでAIの成果物を評価した。製品要件文書（PRD）をどこまで満たせるか、という実務に近い検証である。

結果。最も成績が良かったモデル（GPT-5.6-Sol）でも、完全なデリバリー率はわずか14%だった。

14%。つまり、7回に1回しか「これで納品できる」レベルに到達しない。

問題の核心は「部品は作れるが、全体が組み上がらない」ことにある。個々のコンポーネントの生成精度はそこそこ高い。しかし、未実装の要素が残る、既存モジュールとの統合が欠落する、ビジネスロジックの前提を理解していない——こうした「成熟リポジトリならではの複雑さ」にAIが対応できていない。

新規プロジェクトなら、AIが全体の設計を一から組める。だが成熟リポジトリでは「既にある設計思想」「過去の経緯で生まれた例外処理」「ドキュメントに書かれていない暗黙のルール」が無数に存在する。AIはそれを読めない。

これは地方の中小企業にとって、極めて重要な話だ。なぜなら、中小企業のシステムこそ「成熟リポジトリ」そのものだからだ。10年前に外注で作った販売管理システム。退職した担当者しか知らない仕様。ドキュメントは存在しないか、あっても古い。まさにAIが最も苦手とする環境である。

—

セキュリティハルシネーション——テストは通るが穴がある

もう一つ、見過ごせない問題がある。AIが生成するコードの「セキュリティハルシネーション」だ。

「SPLASH: Contrastive Audit Pressure for Detecting and Localizing Security Hallucinations in Generated Code」という研究が、この現象を定量的に分析している。

セキュリティハルシネーションとは何か。機能テストには合格するが、セキュリティ上の脆弱性を含むコードをAIが生成する現象だ。見た目は動く。テストも通る。だが、SQLインジェクションやクロスサイトスクリプティングの穴が開いている。

この研究では、AIが生成した63,684のプログラムを分析。セキュリティレビューとスタイルレビューの間に生じる「監査圧力」の差を利用して脆弱なコードを検出する手法を提案し、74%の精度で安全なコードを選別できたと報告している。

74%。裏を返せば、4回に1回は脆弱なコードが見逃されるということだ。

中小企業の業務システムが顧客情報や決済情報を扱っている場合、この数字は笑えない。AIが書いたコードをそのまま本番に入れることのリスクが、ここにある。

—

過剰防御という別の罠——AIが「やりすぎる」問題

セキュリティの穴だけではない。逆に「やりすぎる」問題もある。

「Over-Defense in Coding Agents Begins at Silent Forks」という研究は、AIエージェントが不要な防御行動を取る傾向を明らかにしている。

どういうことか。AIは「安全側に倒す」ように学習されているため、必要のないバリデーション、冗長なエラーハンドリング、過剰な権限チェックを勝手に追加する。一見、丁寧に見える。だが実際には、コードの複雑性が増し、パフォーマンスが落ち、保守コストが上がる。

中小企業の現場で考えてみてほしい。限られたエンジニアリソースで運用しているシステムに、AIが「念のため」と大量の防御コードを追加する。動作は遅くなり、次に改修する人間が読み解くのに余計な時間がかかる。AIが「安全のため」にやったことが、結果的にプロジェクトの遅延とコスト増を招く。

この研究が指摘する「Silent Forks（沈黙の分岐）」は特に厄介だ。AIが明示的にエラーを出さず、静かに不要な防御分岐を挿入する。人間のレビューでも見落としやすい。気づいたときにはコードベースが膨張している。

—

で、中小企業はどうすればいいのか

ここまでの話をまとめると、こうなる。

• 成熟リポジトリでのAIの完全デリバリー率は14%
• セキュリティの穴を4回に1回見逃す
• 不要な防御コードを勝手に追加して保守コストを上げる

「じゃあAIは使えないのか」という話ではない。使い方を間違えなければいい。

1. 新規モジュールの切り出しに使う

成熟リポジトリの「中」をいじらせるのではなく、新規のマイクロサービスやAPIエンドポイントなど「外」に切り出せる部分でAIを活用する。AIが得意な「ゼロからの構築」と、成熟リポジトリの改修を分離する発想だ。

2. コード生成ではなく「コード理解」に使う

ドキュメントのない10年モノのコードを読み解く作業。これにAIを使う方が、生成させるより遥かに価値が高い。「この関数は何をしているのか」「この例外処理はなぜ入っているのか」をAIに解説させる。属人化の解消に直結する使い方だ。

3. テストコードの生成に絞る

ビジネスロジック本体をAIに書かせるのはリスクが高い。だがテストコードの生成は別だ。既存コードに対するユニットテストやリグレッションテストの雛形を作らせる。テストが増えれば、人間が改修する際の安全網になる。外注費で1本あたり数万円かかっていたテスト作成が、AIなら数分で叩き台ができる。

4. セキュリティレビューは人間が必ず入る

AIが書いたコードを本番に入れる前に、セキュリティ観点でのレビューを必ず人間が行う。74%の検出率を「まあまあ」と思ってはいけない。顧客データが漏洩したら、中小企業は一発で信用を失う。ここだけは省略してはいけないコストだ。

5. 「AIが追加したコード」を定期的に棚卸しする

過剰防御問題に対処するには、AIが生成・追加したコードを定期的にレビューし、不要な防御ロジックを削除する運用ルールを設ける。コードの膨張を放置すると、半年後に「誰も触れないシステム」が出来上がる。

—

本質は「AIの得意領域と苦手領域の見極め」

AIコーディングエージェントの進化は速い。今日の14%が、半年後には30%になるかもしれない。だが、成熟リポジトリの複雑さ——暗黙知、属人化、ドキュメント不在——は技術だけでは解消しない。

中小企業にとって重要なのは、「AIに全部やらせる」でも「AIは使えない」でもない。どこに使えばコスパが最大化するかを見極めることだ。

新規構築にはAIを全力で使う。成熟リポジトリの改修には、AIを「補助輪」として使う。この切り分けができるかどうかが、AI活用の成否を分ける。

300万円かけて外注していたシステム改修が、AIの補助で100万円になる。それは十分な成果だ。ただし「300万円が5万円になる」と期待して突っ込むと、14%の完全デリバリー率に足をすくわれる。

地に足のついた期待値設定。それが、中小企業のAI活用における最大の武器になる。

—