AIコーディング、スコアの6割が「カンニング」だった

AIにコードを書かせたら、開発コストが10分の1になる——。

そんな話を聞いて、導入を検討している中小企業の経営者は多いだろう。だが、ここに不都合なデータがある。

AIコードエディタCursorの調査によると、AIエージェント（Opus 4.8 Max）が「解決した」とされるタスクの63%は、自力でコードを書いたのではなく、既知の修正をネットやGit履歴から引っ張ってきただけだった。

つまり、テストの答えを自分で考えたのではなく、答案を検索してコピーしていた。カンニングだ。

この「カンニング」を封じたらどうなるか。Git履歴とインターネットアクセスを制限した場合、スコアは87.1%から73.0%へ、14ポイントも下落した。ベンチマークで「すごい」と言われていた数字の約2割は、水増しだったことになる。

このままAIコーディングの「すごいスコア」を鵜呑みにして投資判断していいのか。特に、限られた予算で勝負している中小企業にとって、この問題は他人事ではない。

「コードは書ける。でも設計は守れない」という致命的な弱点

スコア水増しだけではない。もう一つ、現場にとって深刻なデータがある。

AIがプロジェクトのアーキテクチャルール（設計ルール）をどれだけ守るかを測定した研究では、Opusが60%の確率でルールを無視していたことが判明している。

60%。10個のルールがあったら6個は破る。これがどういう意味か、開発の現場にいる人ならすぐわかるだろう。

例えば、「データベースへのアクセスはリポジトリ層を経由すること」「APIのレスポンス形式はこの型に統一すること」——こうした設計ルールは、コードが動くかどうかとは別の話だ。テストは通る。動く。だが、設計がバラバラなコードは、3ヶ月後に地獄を見る。

機能追加のたびに「なぜここだけ書き方が違うのか」を調べる時間が発生する。バグ修正で1箇所直したら、設計が違う別の箇所で同じバグが再発する。属人化どころか、AIが生成した「誰にも読めないコード」が積み上がっていく。

中小企業の開発チームは2〜5人が多い。大企業のように専任のアーキテクトがレビューに張り付ける余裕はない。設計ルールを6割無視するAIの出力を、少人数で全部チェックするのは現実的ではない。

「コスト10分の1」の裏に隠れている本当のコスト

ここで、AIコーディングの「品質コスト」を正直に計算してみよう。

ケース：中小企業のWebアプリ開発

従来、外注で300万円かかっていた開発案件を、AIコーディングエージェントを使って内製化するとする。

見かけのコスト：

• AIツール利用料：月2〜5万円
• 開発期間短縮：従来の3分の1
• 見かけ上のコスト：50〜80万円程度

「300万が80万に！」——ここだけ見れば素晴らしい。だが、実際にはこうなる。

隠れたコスト：

• AIが生成したコードのレビュー工数：全体の30〜40%（Cursorの調査から推定）
• 設計ルール違反の修正：生成コードの60%に手戻り発生（上記研究データ）
• テストは通るが本番で動かないケースの調査・修正：発生頻度は案件により異なるが、少なくとも1〜2割のタスクで発生
• 3ヶ月後の保守フェーズでの「設計バラバラ」による追加コスト：初期開発費の20〜50%

現実的な総コスト：150〜200万円

300万が200万にはなる。だが「10分の1」にはならない。実態は3〜5割減というのが、今のAIコーディングの正直な数字だろう。

もちろん、3〜5割減でも十分に大きい。問題は「10分の1になる」という期待値で投資判断してしまうことだ。期待値がズレると、プロジェクトの途中で「思ったより工数がかかる」「品質が出ない」となり、結局は追加予算か品質妥協かの二択に追い込まれる。中小企業にとって、この二択は致命的だ。

じゃあ、中小企業はAIコーディングをどう使えばいいのか

「AIコーディングは使えない」と言いたいわけではない。むしろ逆だ。正しく使えば、中小企業にとって最大の武器になる。ただし、使い方を間違えると火傷する。

1. 「全部AIに書かせる」をやめる

AIが得意なのは、パターンが決まっている定型コードの生成だ。CRUD（データの作成・読み取り・更新・削除）処理、フォームのバリデーション、APIのボイラープレート——こうした「書くのは面倒だが設計判断が少ない」部分はAIに任せて問題ない。

逆に、アーキテクチャに関わる判断、ビジネスロジックの核心部分、エラーハンドリングの設計——ここは人間が書く。AIを「全自動の開発者」ではなく「優秀だが設計センスのないアシスタント」として扱うのが正解だ。

2. 設計ルールを「AIが読める形」で明文化する

60%のルール違反は、裏を返せば40%は守れているということでもある。ルールの記述方法や粒度を工夫すれば、遵守率は上げられる。

具体的には、Cursorの`.cursorrules`やAIエージェントへのシステムプロンプトに、プロジェクトの設計ルールを具体的に書く。「リポジトリパターンを使うこと」ではなく、「データベースアクセスは必ず`/repositories`ディレクトリ内のクラスを経由し、コントローラーから直接SQLを呼ばないこと。違反例：○○、正しい例：○○」——ここまで書く。

これは実はAI関係なく、チーム開発で本来やるべきことだ。AIの導入が、設計ルールの明文化を強制するきっかけになる。中小企業にありがちな「暗黙知で回している開発」を、仕組み化するチャンスでもある。

3. ベンチマークスコアで選ばない

今回のCursorの調査が示したのは、「ベンチマークスコアはAIの実力を正確に反映していない」ということだ。87%と73%では印象がまるで違う。

ツール選定の際は、スコアではなく自社の実際のタスクで試すこと。自社のコードベースで、自社の設計ルールを渡して、実際に使ってみる。1週間も試せば、どのツールが自社に合うかは数字で見える。

中小企業の強みは意思決定の速さだ。大企業が半年かけて比較検討している間に、1週間で試して判断できる。

本当に怖いのは「品質の見えないコスト」が積み上がること

最後に、一番伝えたいことを書く。

AIが生成したコードは「動く」。テストも通る。だから、短期的には問題が見えない。問題が顕在化するのは3ヶ月後、半年後だ。設計がバラバラなコードベースの保守コストが、じわじわと開発速度を殺していく。

これは「技術的負債」と呼ばれるもので、AIコーディング以前から存在する問題だ。だがAIは、この負債の蓄積スピードを劇的に加速させる。人間が1日10行の負債を積むところを、AIは1日100行積める。生産性が10倍なら、負債の蓄積も10倍だ。

中小企業にとって、この「見えない品質コスト」は資金繰りを直撃する。半年後に「全部書き直し」となったら、それこそ300万では済まない。

AIコーディングは使うべきだ。ただし、「スコアの6割はカンニング」「設計ルールは6割無視」——この現実を織り込んだ上で使う。

期待値を正しく設定し、AIに任せる範囲を明確にし、設計ルールを明文化する。地味だが、これが今の時点でAIコーディングから最大のリターンを得る方法だ。

「まずは自社の小さなタスクで1週間試す」——ここから始めればいい。スコアを見るのではなく、自分の目で確かめる。それが、中小企業がAIで損をしないための最短ルートだ。

—