AIにコードを書かせても、設計と採否は人が決める
AIコーディングは、自然言語の指示や既存コードをもとに、AIがコードを生成・補完する開発方法です。導入を検討するときは、書く作業をどこまで任せるかと、できた変更を誰が確かめるかをセットで決めます。コードが生成されたことと、業務で使える変更ができたことは別です。
まず1つの変更で、受入条件、編集してよい範囲、レビュー担当を決めます。AIには実装やテスト案を任せ、人は要求に合うか、権限を越えないか、既存機能を壊していないかを確認する。この分担から始めると、ツールの速度だけで導入を判断せずに済みます。
3つの使い方と、人がコードを見る範囲
補完型とエージェント型はツールの動き方を指します。バイブコーディングは自然言語でAIにコードを作らせる広い言葉です。図では、その一例として、コードを読まずに動作を見て修正を指示する使い方を示します。3つは排他的な製品分類ではありません。同じエージェント型ツールでも、差分を読んで採否を決める使い方と、見た目の動作だけを頼りに進める使い方があります。
- 補完型続きを提案。人が書いているコードの中で採否を決める
- エージェント型複数ファイルの編集やテストを進める。人が変更範囲と差分を確かめる
- バイブコーディングの一例コードを読まず、動かして修正を指示する。業務利用には別途コードの検証を用意する
試作を触って課題を探す目的と、保守しながら本番で使う目的では、確認すべきものが違います。プロトタイプとMVPの違いを先に決め、試作で見た目が動いたという確認を、本番の受入条件に置き換えないことが必要です。
生産性の研究は、自分たちと条件を比べる
「AIで速くなるか」には、1つの割合で答えられません。短い新規実装と、熟知した大きなリポジトリの変更では、同じコード生成でも仕事が違います。研究を読むときは、発表元だけでなく、タスク、開発者の経験、コードベース、ツールの時期を確認します。
| 確認する条件 | GitHub Copilotの比較試験（2023年論文） | METRの比較試験（2025年公表） |
|---|---|---|
| タスク | JavaScriptのHTTPサーバーを実装 | 既存プロジェクトの修正・機能追加など246件 |
| 開発者 | 職業プログラマー95名を割り付け | 対象リポジトリで長く活動する経験豊富な16名 |
| コードベース | 課題用のひな形と共通テスト | 参加者が熟知した大規模オープンソース |
| ツールと時期 | 2022年5〜6月のGitHub Copilot | 2025年初めのツール。主にCursor ProとClaude 3.5・3.7 Sonnet |
| 完了時間の結果 | 完了者の平均でAI使用群が55.8%短い | AI使用を許可した条件で19%長い |
Copilotの論文は「The Impact of AI on Developer Productivity: Evidence from GitHub Copilot」です。タスク完了率には統計的に有意な差がなく、コード品質全体の影響も調べていません。完了者の時間が短いという結果を、チーム全体の出荷や保守まで55.8%改善するという意味にはできません。
METRの2025年の結果も、AIコーディング全般の否定ではありません。2025年初めのツールを、経験豊富な開発者が慣れた大規模リポジトリで使った試験の結果です。
METRの後続実験は、元の結果を撤回していない
METRは2026年2月24日に後続実験の設計変更を発表しました。旧研究の参加者10名と新規参加者47名が加わりましたが、調査回答者の30%から50%は、AIを使えない条件に割り当てられたくないため一部のタスクを提出しなかったと答えています。回答者の実数は資料に示されていません。参加やタスク選択の偏りから、METRは現在の効果の大きさを測るには信頼性の低い手がかりと評価しています。
2025年の「19%長くかかった」という結果は撤回されていません。後続実験には時間短縮方向の点推定がありますが、信頼区間がゼロをまたぎ、選択の偏りもあります。2026年10月時点の開発全般に「19%遅くなる」と広げることも、後続実験から改善率を確定することもできません。
設計では、完成条件と変更の境界を先に渡す
AIへの依頼は「画面を作る」で止めず、誰が何をできれば完了かを決めます。受入条件がないと、AIの提案が要求を満たしたかをレビューで判定できません。変更してよいファイルや接続先、データを書き換えてよい範囲も一緒に渡します。
- 受入条件を決める利用者、許される操作、異常時の振る舞いを人が確認する
- 変更を小さく実装するAIが差分とテスト案を作る。範囲が広がったら依頼を分ける
- 根拠を持って採否を決める人が要求と差分を照合し、テスト結果と残る確認を記録する
次の「請求書のCSV出力を追加する」は、確認項目を示すための架空の設計例です。実施結果や開発速度の実績ではありません。
| 設計で決めること | 依頼に含める条件 |
|---|---|
| 受入条件 | 担当者が指定した期間の請求書を、既存画面と同じ金額・件数で出力できる |
| 権限の境界 | 自社のデータだけを取得する。閲覧権限のない利用者には出力を許可しない |
| 変更の範囲 | 出力処理を追加し、請求額の計算と確定済みデータは変更しない |
| 異常時 | 期間の入力が不正なら処理しない。取得失敗を空の成功ファイルとして返さない |
大きな機能を一度に依頼するより、出力対象の取得、CSVへの変換、権限確認のように確認できる単位へ分けると、どの条件を満たしているかを差分で追えます。AIが要求の穴を質問できるよう、未確定の仕様は決定済みと扱わせず、人が決める項目として残します。
レビューは、生成した差分と業務条件を照合する
テストが通ることは確認材料の1つです。テストに書かれていない要求まで満たすとは限りません。CSV出力の例なら、次の確認を分けて行えます。
| 見る対象 | 差分と確認結果で見ること |
|---|---|
| 要求への一致 | 画面と同じ期間・金額・件数になるか。出力列の定義が合うか |
| 権限 | 画面でボタンを隠すだけでなく、サーバー側で取得対象と利用者を制限しているか |
| 既存機能の回帰 | 請求計算や確定処理が変わっていないか。関係する既存テストが通るか |
| 異常入力と失敗 | 不正な期間、対象0件、取得失敗を区別し、利用者が判断できる結果になるか |
| 保守の手がかり | 担当者が変更理由と処理を説明できるか。新しい依存の用途を説明できるか |
AIが自分で生成したテストだけでなく、先に決めた受入条件から確認項目を作ります。未確認の項目は、確認した人と結果が残るまで未確認のまま扱います。失敗したテストを消して成功にしたり、関係のない警告を理由なく無視したりしていないかも、差分に含めて見ます。
製品の生成AI機能には、別の評価が加わる
AIを使ってコードを書くことと、利用者に生成AIの回答を返す製品を作ることは別です。CSV出力をAIで実装しても、製品が生成AIの回答を返すとは限りません。
製品に生成AIの要約や回答を組み込む場合は、上のコードレビューに加えて、出力を原文や業務の正解と照合する評価、入力データの扱い、誤ったときに人へ戻す条件を設計します。処理が正常終了したことだけでは、回答の正しさは確認できません。導入後の点検については生成AIのPoCが本番に行かない理由でも、合格条件と運用の境界を整理しています。
小さく試し、レビューを含む時間で判断する
導入試験では、ツール名と版、タスク、担当者の経験、コードベースへの慣れを記録します。コードを書いていた時間だけでなく、指示、待ち時間、確認、修正に使った時間も分けて残す。品質の受入条件を変えずに比べると、生成は速いが確認が増えた、といった内訳を判断できます。
効果を確かめるための作業と、本番のコードを採用する判断は分けます。同じタスクを2回解くと学習の影響が入るため、後の試行が速かったという理由だけでツールの効果と断定しません。測り方と比較条件を決めたうえで、続ける業務と、人が実装した方がよい業務を選びます。
正しさを判定できる担当者がいない変更、影響範囲が追えない変更、元に戻す手段がない本番変更は、採用前の確認から始めます。AI受託開発を相談する際も、生成する量より、完成条件・レビュー担当・戻し方が決まるかを確認すると、納品後に使える範囲を判断できます。