「AIで開発が速くなる」——この言葉は正しいが、雑すぎる。
公開日：2026年7月21日｜カテゴリ：AI駆動開発・システム開発・生産性向上
「AIで開発が速くなる」——この言葉は正しいが、雑すぎる。
実際には、工程ごとに変化の質がまったく違う。ある工程は劇的に短縮され、ある工程は逆に重要性が増し、ある工程では人間の役割そのものが入れ替わる。この違いを理解しないまま「AIを入れれば全部速くなる」と考えると、見積もりも人員計画も現場運用も、すべて狂う。
電通総研が2025年6月に実施した検証では、AIエージェント活用により要件定義・基本設計工程で30%の生産性向上が確認された。同社は2027年までに全新規開発案件へ導入する。上流工程のAI化は、もう実験段階ではない。
本記事では、AIを「置き換え」ではなく「サポートツール」として使った場合に、要件定義・設計・コーディング・テストの4工程がそれぞれどう変わるのかを、実測データと認知科学の視点から具体的に解説する。開発者だけでなく、発注側の経営者・管理職が読んでも判断材料になるように書く。
第1章：全体像——「作る時間」が減り、「決める時間」が残る
2025年から2026年で起きた変化の順序
AI活用は下流から上流へと広がってきた。もともとテスト工程で始まり、2025年にはコーディング工程を中心に本格化した。そして2026年に想定される動向が、要件定義や基本設計といった上流工程を支援するツールの登場だ。AIが内容を理解できる「AI-Ready」な設計書を先に作り、それを基にAIが開発を進める——この流れが主流になりつつある。
富士通は要件定義から設計・実装・結合テストまでの全工程をAIエージェントが協調実行する開発基盤の運用を開始し、2026年度中に金融・製造・流通・公共へ適用範囲を拡大すると発表している。もはや「一部のスタートアップの話」ではない。
認知科学：AIが奪ったのは「作業」、残したのは「判断」
Microsoft Researchの研究では、AI導入により「実装よりもレビューや評価に時間を割く役割変化」が起きることが指摘されている。これは認知科学でいう「認知資源の再配分」だ。
人間の集中力は有限だ。従来はその大半が「コードを書く」という作業に消費されていた。AIがその作業を引き受けたことで、認知資源が「何を作るべきか」「この出力は妥当か」という判断に振り向けられるようになった。減ったのは手を動かす時間であって、頭を使う時間ではない。むしろ頭を使う時間の密度は上がっている。
第2章：4工程はこう変わる——変化サマリー
まず全体像を1枚で掴んでほしい。工程ごとに「何が減り、何が増えるか」がまったく違う。
図1｜AI導入による4工程の変化サマリー
| 工程 | 工数の変化 | AIが担うこと | 人間に残ること |
|---|---|---|---|
| 要件定義 |
約30%減
重要度はむしろ上昇
|
ヒアリング項目の生成、抜け漏れ指摘、議事録の構造化、仕様書ドラフト作成 | 顧客との合意形成、優先順位の決定、ビジネス上の判断、部門間の調整 |
| 設計 |
約30%減
AI-Ready設計が新常識
|
設計パターンの提案、DB設計の叩き台、API定義書生成、既存コードからの設計復元 | アーキテクチャの選択、非機能要件の判断、将来の拡張性を見越した構造決定 |
| コーディング |
最大87%減
最も劇的に変化
|
コード生成、リファクタリング、エラー解決、コードの解説・文書化 | 生成コードのレビュー、セキュリティ判断、設計意図との整合性確認 |
| テスト |
作成は減・検証は増
総量は減りにくい
|
テスト項目・シナリオ・スクリプトの生成、境界値やエッジケースの網羅 | テスト観点の妥当性判断、受入基準の決定、AI生成コードの脆弱性確認 |
※数値出典：電通総研の検証（要件定義・基本設計で30%向上）、トランスコスモス実測（小規模開発の実装工数87%減）。案件規模・種別により変動する。
第3章：要件定義——「聞き出す」から「詰める」へ
何が変わるか：ヒアリングの準備コストが消える
従来の要件定義では、「何を聞けばいいか」を考える段階で経験の差が大きく出た。ベテランは抜け漏れなく聞き出し、若手は聞き忘れて後で手戻りが発生する。
AIはこの差を埋める。「在庫管理システムの要件定義で、顧客に確認すべき項目を業務フロー順に50個挙げて」と指示すれば、経験10年分のチェックリストが数十秒で手に入る。実務では、商談・プリセールスの段階から要件定義を回し始めることで、受注前に要件の解像度を一気に高める使い方も広がっている。
具体的な実践方法（そのまま使えるプロンプト）
① 抜け漏れ検出：「以下の要件メモを読み、業務システムとして考慮が漏れている観点を指摘してください。特に権限管理・データ移行・帳票出力・例外処理の観点で」
② 曖昧さの発見：「この要件定義書の中で、解釈が複数あり得る曖昧な記述を全て抜き出し、それぞれ確認すべき質問文を作ってください」——認知科学の「知識の呪縛」（詳しい人ほど自分の前提を説明し忘れる）を、AIが第三者視点で破ってくれる。
③ 議事録の構造化：打ち合わせの録音を文字起こしし、「この議事録から、決定事項・保留事項・要確認事項・宿題を担当者付きで整理して」と指示する。従来1時間かかった整理が5分で終わる。
人間に残る仕事：合意形成と優先順位
AIは「網羅」は得意だが、「取捨選択」はできない。予算と納期の制約下で何を諦めるか、部門間で利害が対立したときにどう調整するか——これは人間の仕事だ。AI活用により、プロジェクトメンバーはシステム戦略の立案や顧客とのコミュニケーション・合意形成といった付加価値の高い業務に注力できるようになる。要件定義は「作業が減って、対話が増える」工程になる。
第4章：設計——「AI-Ready設計書」という新常識
何が変わるか：設計書がAIへの指示書になる
最大の変化は、設計書の役割が変わったことだ。従来の設計書は「人間の実装者に伝える文書」だった。これからは「AIが読んで実装できる文書」でなければならない。あらかじめAIが内容を理解できる「AI-Ready」な設計書を作成しておき、それを基にAIが開発を進めるスタイルが2026年の潮流だ。
これは実務上、大きな示唆を持つ。曖昧な設計書はAIに曖昧なコードを生成させる。設計の精度が、そのまま実装の精度になる。「設計はざっくりでいい、実装で調整する」という従来のやり方は、AI駆動開発では成立しない。
具体的な実践方法
① 設計の叩き台生成：「この要件を満たすDB設計（ER図の説明とテーブル定義）を作成し、正規化の観点と将来の拡張性の観点で選択理由も説明して」
② 設計レビュー：「この設計の弱点・スケール時のボトルネック・セキュリティ上の懸念を、優先度順に指摘して」——設計段階でAIに批判させることで、実装後の手戻りを防ぐ。
③ 既存システムの設計復元：ここが見落とされがちな重要用途だ。NTTデータはLLMでソースコードを解析し設計情報を復元するリバースエンジニアリングに取り組み、COBOLのマイグレーションを進めている。復元結果をRAGに登録することで、有識者以外でもシステム仕様を調べられるようになり、問い合わせ対応が迅速化したという。設計書のない古いシステムを抱える企業にとって、これは福音だ。
人間に残る仕事：アーキテクチャの選択
「この規模ならモノリスで十分か、マイクロサービスにすべきか」「5年後の事業拡大を見越してどう作るか」——ビジネス文脈を踏まえた構造判断は人間の領域だ。AIは選択肢と根拠を提示できるが、会社の将来を賭けた選択はできない。
第5章：コーディング——「書く人」から「レビューする人」へ
何が変わるか：最も劇的に、そして最も危険に
コーディングはAIの影響が最大の工程だ。小規模開発では実装工数87%減という実測もある。だが同時に、最も危険な工程でもある。AI生成コードには一定割合で脆弱性が混入するという調査結果が複数あり、レビューなしの本番投入は事故に直結する。
ここで役割が入れ替わる。エンジニアの主業務は「コードを書くこと」から「AIが書いたコードを評価すること」へ移った。この変化は、必要なスキルセットも変える。
図2｜工程別 AIと人間の役割分担
| 要件定義 |
|
||
| 設計 |
|
||
| コーディング |
|
||
| テスト |
|
※比率は目安。重要なのは「コーディングだけAI比率が突出し、その分レビュー負荷が人間に集中する」という構造。ここがボトルネックになりやすい。
具体的な実践方法
① 生成前にルールを与える：「OWASP Top 10の脆弱性を避け、入力値検証を必ず入れ、機密情報をハードコードしないこと」をプロンプトの定型文にする。生成段階で欠陥を減らすのが最も安いコストだ。
② 小さく作らせる：一度に大きなコードを生成させず、関数単位で生成してその都度レビューする。大きな塊はレビュー不能になり、確認が形骸化する。
③ 理解できないコードを本番に入れない：AIが生成したコードで理解できない箇所は、そのままAIに「このコードが何をしているか説明して」と聞く。説明できないコードを承認しないというルールが、技術的負債の最大の防波堤になる。
認知科学の警告：スキル低下と自動化バイアス
リスクとして「ツール依存によるスキル低下」と「レビュー工程の軽視による不具合増加」が指摘されている。人は機械の出力を過信する傾向（自動化バイアス）を持つ。「AIが書いたから大丈夫」は最も危険な思考だ。若手が「書く経験」を積まないままレビュー役になると、そもそも評価能力が育たないというジレンマもある。意識的に「自分で書く時間」を残す設計が、組織には必要になる。
第6章：テスト——「作る」は自動化、「決める」は人間
何が変わるか：作成は激減、検証は増加
テストは、AI活用が最も早くから始まった工程だ。現在、LLMを活用してテスト項目・テストシナリオ・テストスクリプトを出力させることが可能になっている。ただし実務では課題もある。Excel形式の長大な図や表を入力するとLLMが構造を正確に認識できず、出力に問題が生じるケースがあるため、NTTデータは複数のAIエージェントを組み合わせて前処理を行い、総合テスト項目表の生成を実現している。
重要なのは、テスト工程の総工数は思ったほど減らないという現実だ。テスト項目の作成は自動化できても、AI生成コードの脆弱性確認という新しい負荷が加わったからだ。実装で浮いた工数の一部は、ここに再投資すべきものだと考えたほうがいい。
具体的な実践方法
① テストコードを資産化する：「この機能の単体テストを、正常系・異常系・境界値を網羅して書いて」と指示し、自動テスト一式を必ず残す。自動テストがあれば、将来の改修で「直したら別が壊れた」を機械的に検知でき、保守コストが下がり続ける。
② 観点の抜けをAIに探させる：「このテスト項目表を見て、抜けているテスト観点を指摘して。特に同時実行・大量データ・権限違いの観点で」
③ 別のAIにレビューさせる：コードを生成したのとは別のAIに脆弱性チェックをさせる。同じAIに自己チェックさせても、同じ盲点を見逃す。
第7章：成功者の思考パターン——「浮いた時間」の使い道で差がつく
ここまでの実測値を足すと、上流30%減・実装最大87%減という大きな余剰が生まれる。この浮いた時間をどう使うかが、AI時代の組織の分岐点だ。
失敗する組織は、浮いた時間をそのまま「値下げ」か「納期短縮」に変える。短期的には競争力に見えるが、レビュー・テスト・文書化が削られ、数年後に保守不能なシステムが残る。
成功する組織は、浮いた時間を3つに再投資する。①レビューと品質保証（AI生成コードの検証）、②要件定義と顧客対話（そもそも作るべきものを正しく決める）、③ドキュメントとテストの整備（10年使えるシステムにする）。
行動経済学の「機会費用」の観点で言えば、浮いた時間は「タダで手に入った時間」ではなく「何に投資するかを選べる資本」だ。優れた経営者は、コスト削減として消費するのではなく、品質と持続性への投資として使う。
まとめ：今日から動ける3つのアクション
アクション1（開発者・今日から）： 要件定義メモをAIに読ませ、「考慮が漏れている観点を指摘して」と聞く。上流工程のAI活用は、実装より投資対効果が高い。ここから始めるのが最短ルートだ。
アクション2（チーム・今週中）： 「AIが説明できないコードは承認しない」というレビュー原則をチームで合意する。理解できない箇所はAIに解説させ、それでも不明なら差し戻す。この1つのルールが技術的負債の大半を防ぐ。
アクション3（管理職・今月中）： AI導入で浮いた工数の使い道を明文化する。「値下げに回す」のか「レビュー・テスト・文書化に再投資する」のか。決めていない組織は、自動的に前者になり、5年後に負債を抱える。
AIは4工程すべてを変えたが、変え方は同じではない。要件定義は対話が増え、設計は精度が求められ、コーディングは役割が入れ替わり、テストは重心が移った。この違いを理解した組織だけが、AI時代の生産性向上を本当に手にできる。
データ出典：電通総研プレスリリース（2025年10月）・NTTデータ DATA INSIGHT・富士通プレスリリース（2026年2月）・日経クロステック・Microsoft Research「Empirical Studies of AI Pair Programming Tools」・トランスコスモス実測・各社公開情報（2025〜2026年）。数値は各検証時点のものであり、案件規模・種別により変動します。
タグ： AI駆動開発 | 要件定義 | 設計 | コーディング | テスト | 生産性向上 | システム開発 | AI活用 | 認知科学 | 行動経済学
