作成日: 2026-08-19
生成AIによるソフトウェア開発の変化というと、「コーディングが速くなる」ことが注目されがちです。しかし、本当に大きな変化は、コードを書く工程だけではありません。
これまでのSDLC（Software Development Life Cycle）は、おおむね次のように、人が成果物を順番に受け渡す流れでした。
要求を聞く → 要件にする → 設計する → 実装する → テストする → 運用で学ぶ
AIを開発に組み込むと、人が実現したい目的、制約、成功条件を定め、AIがそれを要件、設計、コード、テストの候補へ連続的に変換する形に変わります。
ただし、AIが生成したコードを速く出すことは、正しいソフトウェアを作ることと同じではありません。仕様が曖昧なら、AIは間違ったものを高速に作るだけです。AIネイティブなSDLCで中心になるのは、意図を明確にし、仕様を検証可能にし、人が判断する地点を設計することです。
要件定義は「文書作成」から「認識差の発見」へ
要件定義で難しいのは、文章を書くこと自体ではありません。関係者がそれぞれ異なる完成イメージを持っていることです。
たとえば、保険会社が「事故受付をオンライン化したい」と考えたとします。
- 営業部門は、スマートフォンから簡単に申請できることを望む
- 法務部門は、本人確認と同意取得を確実にしたい
- システム部門は、既存の契約管理システムとの連携を確認したい
- セキュリティ担当は、個人情報の扱いと記録を確認したい
従来は会議、議事録、要件定義書、回覧を通じて、こうした違いを少しずつ調整していました。AIは、利用を許可した過去の要件書、業務フロー、会議記録、規程、既存API仕様、問い合わせ記録を横断し、次のような確認すべき点を候補として示せます。
- 営業要求とセキュリティポリシーに矛盾がないか
- 本人確認に失敗した場合の処理が定義されているか
- 必要なデータ項目を既存APIが提供しているか
- 誰が、いつ、どの情報を見られるべきか
- 例外時にどの部署へ引き継ぐか
重要なのは、AIに要件定義書を完成させてもらうことではありません。実装に入る前に「そんなつもりではなかった」という認識差を表面化させることです。
プロトタイプは、説明資料ではなく要件を発見する装置になる
文章だけでは、完成後の画面や利用手順を正確に想像しにくいものです。
会議中に、次のような意図をAIコーディングツールへ渡すとします。
顧客名と契約番号で検索できる画面を作る。検索結果には契約状態、担当営業、最終更新日を表示し、結果から事故受付を始められるようにする。
生成した画面をその場で見せれば、利用部門は「電話番号検索は不要」「契約状態より担当営業を優先したい」「一覧から直接受付へ進みたい」と具体的に指摘できます。
説明 → 文書化 → レビュー → 修正
だった往復が、次の短いループに変わります。
意図を話す → 試作品を生成する → 見る → 認識差を話す → 修正する
試作品を本番コードへ流用するかは別の判断です。プロトタイプの価値は、実装を急ぐことよりも、利用者が実物を見て初めて言語化できる要件を早く見つけることにあります。
設計では、AIに「答え」ではなく反証を求める
AIにアーキテクチャを任せきりにするのは危険です。一方で、設計案を多面的に批判する相手として使うと有効です。
たとえば「1万人が同時利用する社内AIアシスタント」という案に対し、次の観点から反証を求めます。
- 認証基盤や外部APIに単一障害点はないか
- レート制限、キュー、タイムアウト、再試行は必要か
- LLMや検索基盤の障害時に、どこまで機能を縮退させるか
- 機密情報や個人情報がプロンプト・ログへ残らないか
- ツール実行権限が広すぎないか
- トークン、検索、再試行を含む費用の上限はあるか
- 利用者やエージェントの退職・廃止時に権限を失効できるか
AIの指摘は設計の正解ではなく、検証候補です。人間が採否と根拠を決め、設計記録へ残します。見るべきKPIも「設計書を何時間で書けたか」ではなく、重大な設計上の問題を本番前へどれだけ前倒しできたかです。
コーディングでは、既存資産を理解できる状態にする
AIはCSV集計、API呼び出し、テスト、README、コンテナ設定などの骨格を素早く作れます。特に新規開発では、初期の試行を早めやすいでしょう。
しかし実務の多くは、既存システムを変えるブラウンフィールド開発です。「この機能を追加して」という一文だけでは安全に変更できません。
AIが必要とする文脈は、ソースコードだけではありません。
| 文脈 | AIに渡すべき理由 |
|---|---|
| アーキテクチャと境界 | 変更してよい責務と依存関係を判断するため |
| コーディング規約 | チームの保守性を保つため |
| API・DBスキーマ | 互換性を壊さないため |
| テストと障害履歴 | 既知の失敗を繰り返さないため |
| セキュリティ要件 | 認可、入力、秘密情報を守るため |
| 実行・検証手順 | 生成後に機械的に確かめるため |
GitHub Copilotも、リポジトリ全体・パス別・エージェント向けのカスタム指示を用意しており、プロジェクトの構造、規約、ビルド・テスト方法といった継続的な文脈を与えられます。GitHub Docs: Customize Copilot for your project
AI時代のエンジニアリングとは、既存システムをAIが変更できる状態に整える仕事でもあります。
テストは、実装後の検査から仕様の継続的な検証へ
従来は、実装後にテストし、バグを見つけて修正する流れになりがちでした。AIを使えば、コードを書く前の仕様段階から境界条件を洗い出せます。
「パスワードを5回間違えたらロックする」という仕様に対して、少なくとも次を問えます。
- 4回失敗した時点では何が起きるか
- 5回目だけ正しい場合はどうするか
- 複数端末から同時に試行されたらどう数えるか
- 管理者が解除した直後の状態はどうなるか
- 分散環境で回数カウンターが競合したらどうするか
- ロック通知は、攻撃者への情報開示にならないか
ここでAIが出すケースはテストの網羅性を保証しません。けれど、仕様、テスト観点、実装のつながりを早く可視化できます。
Intent → Specification → Design → Code → Test → Evaluation
この鎖のどこかが変わったら、後工程だけではなく、前提となる仕様や受入条件にも戻って確認する。これがAIを使ったSDLCで特に重要になります。
仕様駆動型開発で、コードは「意図の実装」になる
「顧客の退会処理を実装する」という依頼だけでは、AIにも人にも不足があります。
より実務的な仕様は、たとえば次のようになります。
顧客は退会を申し込める。未払い契約がある場合は即時退会させず、理由と次の手順を表示する。退会後はログインを停止する。法令上保存が必要なデータを除き、定めた期間内に削除する。すべての処理を監査ログへ残す。
ここには、利用者、ルール、例外、禁止事項、監査、成功条件が含まれます。この意図から、受入条件、設計案、コード、テスト、運用手順を生成・検証できるようになります。
GitHubのSpec Kitは、仕様をコードより上位の「主要な成果物」として扱い、仕様から実装計画やタスクを導くSpecification-Driven Developmentを説明しています。Spec-Driven Developmentの説明
これは、仕様書を増やすことが目的ではありません。仕様とコードを別々に更新して乖離させるのではなく、変更の起点を意図と検証可能な仕様へ戻す考え方です。
エンジニアの役割は、コードの外側へ広がる
AIが速くコードを生成するほど、仕様を間違えたときの損失も速く大きくなります。エンジニアに必要な能力は、正しいコードを速く書く力だけではなくなります。
- 曖昧な要求から、解決すべき問題を取り出す
- 成功条件、制約、禁止事項、例外を定義する
- 設計案を性能、セキュリティ、運用、コストから批判する
- AIの成果物をテスト、レビュー、観測可能な証拠で評価する
- 人・AI・ツールの役割と承認点を組み立てる
これは「コードを書ける人が不要になる」という意味ではありません。むしろ、AIが作った変更が本当に既存システムの文脈に合い、検証を通り、障害時に戻せるかを判断するには、深い技術理解が必要です。
最初からSDLC全体を自動化しない
最初の導入では、一つの小さな開発単位で、次のループを試すのが現実的です。
- Intentを書く — 利用者、解決したい問題、成功条件、制約、禁止事項、例外を記す。
- AIに曖昧さを探させる — 不足した要件、矛盾、確認すべき点を出させる。
- 試作品を見せる — 文書で合意する前に、画面・API・操作フローを確認する。
- 設計を反証する — 性能、セキュリティ、可用性、運用、費用の観点でレビューする。
- 仕様からテストを作る — 正常、異常、境界値、認可、障害時のケースを先に定める。
- 人が承認する — 重要な設計、権限、リリース、顧客影響は人が最終判断する。
AWSが提唱するAI-DLCも、AIが計画を作り、不明点を質問し、人が重要な判断を検証した後に実装する流れを中核に置いています。AWS: AI-Driven Development Life Cycle
生産性は「生成コード量」では測らない
「開発速度が何%向上した」という数字は、新規開発か既存改修か、コードベースの品質、渡せる文脈、テスト自動化、チーム経験によって大きく変わります。ある組織の数字をそのまま自社目標にしてはいけません。
本番で見るべきなのは、生成量よりも業務成果です。
- 要件確定までの日数
- 設計レビューで見つかった重大な問題数
- 仕様変更による手戻り率
- PRのリードタイムとレビュー滞留
- 本番流出欠陥数と変更失敗率
- 障害時の復旧時間（MTTR）
- エンジニアが判断・設計へ使えた時間
AI導入の目的は、コードを大量生産することではありません。正しいソフトウェアを、より早く、より安全に作れているかを測ることです。
まとめ: コード中心からIntent中心へ
AIネイティブなSDLCは、次の転換として捉えられます。
人間 → 要件書 → 設計書 → コード → テスト → システム
から、
人間のIntent
→ AIによる仕様化と論点抽出
→ 設計・試作品・コード・テストの生成
→ 継続的な検証
→ 人間の判断と承認
→ 運用から仕様へのフィードバック
への移行です。
AI時代に価値が高まるのは、プロンプトの巧拙だけではありません。意図を取り出し、制約を定義し、仕様を検証可能にし、AIの成果を批判的に評価し、必要な場面で責任を持って止められる力です。
コードを書く能力の価値がなくなるのではありません。コードを書く前に「何を、なぜ、どの条件で作るのか」を正しく決める能力の価値が、これまで以上に高くなります。