はじめに
記事の概要
この記事はNTTドコモソリューションズ Advent Calendar 2025 2日目の記事です。
NTTドコモソリューションズの掛内です。
普段はこちらのような、エンジニアのスキルの可視化/分析や人材戦略の高度化などを担当しております。
直近は、このスキルの可視化/分析を行うアプリをAI駆動開発(仕様駆動開発)にシフトさせ、AI駆動開発のナレッジの蓄積や、プロセスの標準化を推進しております。
業務を行っていく中で、AI駆動開発/仕様駆動開発には、技術・組織体制・人材・マインド・運用整理など様々な事前準備を行う必要性を感じましたので、記事として整理をして共有させて頂きます。
なお、筆者のバックグラウンドとしましては、開発経験は15年弱、E資格、CSP-SM/CSP-PO、いくつかのIPAの高度試験やAWSの認定資格を保有しており、技術書の出版なども行っております。
AI駆動開発とは
まず、AI駆動開発について軽く説明をさせて頂きます。
※すでにご存じの方は、次の項目まで飛ばして頂ければと思います。
出鼻をくじかれるのですが、残念ながら、AI及びAI駆動開発には、厳密な定義が未だありません。
ただし、一般的な解釈においてAI駆動開発とは、開発工程でコーディングのアシストをするだけではなく、AIを開発プロセスの中心に据えて、工程や複数のタスクを横断して活用する開発手法を指します。
大切なポイントとしては、人間が主軸ではなくAIが主軸であり、人間はサポーター/フォロワー/レビュアーのようなスタンスをとります。AIが最大限実力を発揮できるようにプロセスを最適化し、人間と協調をしながら開発を進めていきます。
つまり、人間はAIにすべてを任せるというわけではなく、逆に、人間がAIをマイクロマネージメントするというわけでもありません。人間とAIは良きパートナーであるのが理想です。
AIを使った開発とAI駆動開発の違いについては、下記の記事が参考になると思います。
仕様駆動開発とは
続いて、仕様駆動開発についてのご説明です。
仕様駆動開発は、AI駆動開発の1つのパターンになります。
AI駆動開発では、AIのブラックボックス性(AIがなぜその出力をしたのかが分からない)や非決定性(常に同じ結果になるとは限らない)に頭を悩ませることになります。
システム開発は、ウォータフォールでもアジャイルでも、粒度やサイクルは異なるものの抽象的には下記のような作業が必須となります。
- 【要件定義】 何を作りたいかを決める
- 【設計】 具体的な詳細を詰める
- 【製造】 モノづくり/コーディングをする
- 【試験】 動作確認をする
- 【運用】 安定稼働のために定期的にチェックをする
これをAIに、プロンプト一発で全部作らせるのは(少なくとも2025年12月時点の技術では)難しいものがあります。
そこで、段階的にAIに成果物やアウトプットを作らせ、途中で人間がレビューや修正を指示して軌道修正をしながら、数段階に分けて作業をさせることで、人間が期待する物を作らせようとするのが仕様駆動開発です。
仕様駆動開発のイメージ
仕様駆動開発にはいくつかのツールがあるのですが、現時点でいちばん有名なKiroというツールでイメージをお伝えしたいと思います。(Kiro以外には、Spec Kitやcc-sddなどがあります)
Kiroでは、下記の3つの成果物を通して、詳細化をしていきます。
- 要件定義(requirements.md)
- 設計(design.md)
- 実装計画(tasks.md)
出典：「Kiro(バージョン0.6.0) Specモードの実行画面」(筆者ローカル環境/スクリーンショット取得日：2025年11月20日）
今回は花火ゲームを作りたいと思いますので、プロンプトに「花火ゲームを作って」といれます。
通常は、ステアリングと呼ばれる共通的な設定など様々な準備をしますが、今回は動作確認程度で十分ですので、無邪気なプロンプト1つだけで行きたいと思います。
プロンプトからは、要件定義書(requirements.md)を作成してくれます。
このファイルには、EARS (Easy Approach to Requirements Syntax)形式で、ユースケースや受け入れ基準などが記載されています。
通常は、レビューや軌道修正を行いますが、今回はそのまま続けます。
要件定義書からは、設計書(design.md)が作られます。
このファイルには、アーキテクチャ図やクラス設計やテスト設計などが含まれています。
こちらも通常は、レビューなどを念入りに行いますが、今回は確認作業をせずに続けます。
設計書からは、実装計画(tasks.md)が作られます。
このファイルは、設計書の内容を実装していくための作業リストが記載されています。
このファイルは要件定義書や設計書と異なり、一括ではなく項目単位での実行を行います。
項目ごとに実行をして、プログラムなどをAIに書かせていき、人間がチェックします。
今回は、レビューなどは行わず、うまくいくことをお祈りしながら、どんどん実行していきます。
最終的には、大変簡素なものですが、一旦動く花火ゲームができあがりました。
たった一言のプロンプトから始めて、ここまでにかかった時間は15分程度です。15分でゼロからこのアプリができたことは、非常に驚異的なことだと思います。
また、良くも悪くも技術的な要素を求められることはありませんでした。
そして、早さも重要ですが、要件定義→設計→実装計画という流れにおいて、人間がAIのアウトプットを確認し、軌道修正をできる余地があるというのが、解釈性を高め、AIをコントロールしやすくしています。
システム開発の経験があまり無い方ですと、直感的に「たった1人で15分でこのレベルまで開発できるのなら、開発チーム全員が1ヶ月かけたらすごいものができる」と考えるのは自然なことだと思います。
一方で、AIに造形が深い方や開発経験が豊かな方は「いやいやそんなにうまくいかないよ」という気配を察しているのではないでしょうか？
(実際、なかなかうまくいかないことも多くあります)
ここからは、この隔たりのある両者(期待と現実)に、準備の定義を用いて、歩み寄りの道を作っていきたいと思います。
準備の定義とは
前フリの最後のパートとして、準備の定義についても軽くご説明します。
※こちらもご存じの方は、次の項目まで飛ばして頂ければと思います。
準備の定義とは、その名の通り、準備完了を確認するためのチェックリストです。
別名としては、準備完了の定義、Readyの定義、DoR(Definition of Ready)などがあります。
準備の定義は、アジャイル/スクラム開発でよく用いられるもので、具体的には以下のようなものになります。
(チームや案件の特性に合わせて作成されますので、下記はあくまで一例となります。粒度や対象もチームにより異なります)
- 背景やニーズ(なぜ必要なのか？)が明確になっている
- ユーザーストーリーが明確になっている
- 技術的に実現可能で、チーム内で不明点がない
- 作業内容が洗い出されており、見積もりが出来ている
- 受け入れ基準が明確になっている
本記事では、この「準備の定義」の考え方を用いて、事前作業の洗い出しやAI駆動開発の期待値コントロールに使ってみようという趣旨になります。
AI駆動開発/仕様駆動開発の準備の定義について考える
それでは、本題に入っていきます。
私が今までの経験から、AI駆動開発/仕様駆動開発を始める前にやるべきと考えている項目で、他の方にも活用頂きやすいトピックについて、いくつかの観点に分けてご紹介していきたいと思います。
ご紹介する項目がAI駆動開発/仕様駆動開発の準備の定義を網羅的にカバーしているわけではありません。
また逆に、場合によっては不要になる項目もあるかと思いますので、必要な部分をご活用頂ければ幸いです
共通認識編
AIの基本的な性質を理解する
これから仲間になってもらうAIのことを知らなくては話になりません。
AIについての最低限の知識をスクラムチーム/マネージャー/ステークホルダーで獲得しましょう。
特に、AIができないこと・能力の限界・苦手なこと・人間がサポートしないといけないことを共通認識とすることで、期待値がインフレするのを避けることができ、AI駆動開発の勘所を押さえることができます。
また、それって仕組み的にAIでできるのか？という嗅覚も磨くことができます。
客観的で一般的な知識レベルを獲得するという意味では、一旦G検定あたりを目指すのが有益だと思います。
もし、いままでにAIやITに馴染みがなかった方で、G検定のハードルが高い方は、生成AIパスポートあたりから挑戦していくのも良いかもしれません。
ただし、資格試験は体系的な知識の獲得には有益ですが、開発に関する尖った知識や、最新情報は獲得できないため、過信は禁物です。
AI駆動開発とAIを使う開発の違いを理解する
再掲に近いですが、AI駆動開発は、単にAIを使った開発を指すわけではありません。
人間とAIのドライバーとナビゲーターの関係が入れ替わるため、従来のアジャイル/スクラム開発やウォータフォール開発に生成AIを入れるだけではないということを共通認識としておくことをオススメします。
AIが開発プロセスの中心になるということは、時としてBPR(Business Process Re-engineering)やスクラムの改革が必要となります。
大きな利益を得るために、多くのリスクを覚悟をしなければならないことを開始前にスクラムチーム/マネージャー/ステークホルダーで認識できているかは、後々大きな差になってきます。
ウォータフォールとアジャイル/スクラムとAI-DLCの違いを読み合わせる
AI駆動開発の開発フローのベースとして取り扱われる事が多いのは、AWSのAI-DLCだと思います。
AI駆動開発は、ウォータフォールかアジャイル/スクラムかの2択で考えるならばスクラム寄りではありますが、単純にスクラムにAIを導入するだけではAI駆動開発の真価を発揮することは出来ません。
その証拠に、AI-DLCではスクラムでの概念に似たものはありますが、スプリントではなくボルト、インクリメントではなくデプロイメントユニットなどに用語や定義が変わっていますので、読み替えではなく、新たな定義として受け入れ、自身のプロジェクトにどう取り込んでいくかが重要になります。
また、仕様駆動開発は、(Kiroを用いる場合)要件定義→設計→実装計画と段階的に詳細化していくため、ウォータフォール的な側面もあり、やはりどちらかではなく、守破離のプロセスを経て「離」にうまくたどり着くことが重要といえます。
1つの事例の参考として、Water-Scrum-Fastの記事を紹介しておきます。
カンファレンス/勉強会で、AI駆動開発の情報をリアルタイムに集める
AI駆動開発/仕様駆動開発は未だ黎明期で、発展にはナレッジの収集やハンガーフライト(経験の共有)が必要不可欠です。
様々な企業や個人のトライアンドエラーをウォッチし、最新のナレッジやツールを常に取り込み続ける必要があります。
XなどのSNSや、Qiita/Zenn/Noteなどの情報発信プラットフォーム、connpass/TECH PLAYなどの勉強会・イベントサイトで情報をリアルタイムに収集すると良いでしょう。
AI駆動開発については、多くのイベントや勉強会が日夜開催されていますが、大きく活発な団体としては「AI駆動開発カンファレンス」があります。
環境整備編
社内のAI利用のルールを確認する
多くの企業は、AIを推進していますが、その反面リスクにも敏感です。
代表的なリスクを上げると、下記のようなところでしょうか。
- 自社データが学習に使われてしまう
- AIの予期せぬ動作や返答で、ブランドイメージを低下させてしまう
- シャドーAIで、知らないうちに許可していないAIが使われる
- 新しいAIツールやAIサービスでリスクが見えない
経営層による積極的なAI活用でケイパビリティを上げてほしいという声や、現場からの最新のツールを早く簡単に使いたいという声を踏まえたうえで、会社としてのガバナンスをきかせ、コンプライアンスを守る必要があり、このトレードオフは常に繊細な問題です。
特に大企業になればなるほど、スピード感や手続きが長く複雑なものとなりやすいですが、ここは一つ一つ丁寧に実施していくしかありません。
スピード感やアジリティは、企業文化によりまちまちだと思いますが、法律や社内ルールを破って成果を出しても評価はされませんし、他のチームに水平展開することもできません。
必要な手続きを早めに確認し、少しでも前倒しで準備を行い、改善できると思える部分に関しては、組織や事務局にフィードバックをするという当たり前の活動を行います。
「AIさん」が気持ちよく働ける環境を整備する
しつこいぐらいの繰り返しですが、AI駆動開発とは、AIがフローの中心にいて、人間はサポートをするというのが基本スタンスです。したがって、「AIさん」が気持ちよく働ける職場環境が必要です。
もう少しタスク的な表現に落とし込むと、AIが人間と同じ情報源や環境やツールに触れられることが必要です。
まず、そもそもAIが環境やツールにアクセス出来ないと何も出来ません。
(プロンプトだけですべての情報を伝えて作業をさせるのは、現実的ではありません)
ただし、AIが暴走した際に、勝手にファイルを消されたり、ソースコードをプッシュしたりするリスクも同時に存在します。このトレードオフ/リスクコントロールを鑑みて、ガードレールの設計や、人間による承認(HITL：Human In The Loop)をどのように入れるかを検討する必要があります。
また、上記と関連しますが、AI駆動開発ではMCP(Model Context Protocol)は必須です。
AIが直接外部リソースを操作できないと、コンテキストや作業が分断され、効率が非常に落ちてしまいますので、MCPの導入が必要です。
ただし、MCPサーバにも脆弱性などの問題が指摘されていますので、出どころが不明で品質に不安があるMCPサーバは使うのを控えるのが無難でしょう。
最後に、設計書や暗黙知をMarkdownやAIが読める形式(yaml/jsonなど)にしたうえで理解させる必要があります。
AIは、誤字やTypoぐらいであればうまく解釈できますが、書かれていない行間や空気を読むことはできません。また、Office製品やPDFなどのアプリで作られたデータは、AIに直接読み込ませても(2025年12月時点では)解釈の精度に大きなばらつきがあります。
そのため、暗黙知やアプリデータは、Markdownなどに書き起こすと後々楽になります。
これは、事前準備としては非常に重たいものであり、どこまでやるかという問題も生まれやすいですが、既存プロジェクトの暗黙知が減るというメリットもあるため、できるだけ頑張りたいところです。
AIと人間を育てる仕組みを作る
2025年12月時点で、一般的にAIの開発能力は3-5年目の社員程度と言われることが多いです。そのため、AIを継続的に育てる必要があります。
具体的には、人間が誤差関数(期待する理想とAIの出力の差を評価)として動き、出来ていない部分をフィードバックして継続的に精度を上げます。
フィードバック内容は、プロンプトの追加/修正や(Kiroの場合)ステアリングの追加/修正として反映します。
一方で、人間も継続的に成長していく必要があります。
前述の継続的なAIに関する勉強や情報のキャッチアップも必要ですが、もっと具体的で即物的なところとして、レトロスペクティブなどで
- AIをより高度に使いこなすには？
- AIがより働きやすくなるためには？
- AIによるリスクを減らすには？
などの改善するべきことを、専用のトピックとして取り上げ、スプリント/ボルトの振り返りを行うことで、AIを扱う技術を洗練します。
案件準備編
パイロットプロジェクトの選定
社内にノウハウが少ない場合には、AI駆動開発においてもスクラムと同じく、小さく独立したトライアルができるパイロットプロジェクトで、ノウハウを貯めることが必要です。
一般論に近くなってしまいますが、パイロットプロジェクトには、下記のような性質があると良いと言われています。
- 失敗が許容され、トライアンドエラーができる
- テックリードやエンジニアリングマネージャに権限が移譲されている
- 検証に高いプライオリティを設定できる
- 経営層やお客様などの多数の外部ステークホルダに振り回されない
- 興味関心/モチベーションの高いメンバを集められる
一方で、パイロットプロジェクトは完全なる投資となり、成果や評価が売上や開発内容ではなくなるため、KPIとして、検証項目やなにを整備するためにどんな活動をするのかを明確にすることは重要です。
期待値をコントロールする
AI駆動開発/仕様駆動開発への期待は、アジャイル/スクラムの黎明期に非常によく似ています。
日本でアジャイル開発が本格導入され始めた頃は、ウォータフォールの上位互換で、途中で仕様変更が許され、早く安く簡単に素晴らしいアプリが作れるという誤解が蔓延しましたが、AI駆動開発も人によってはスクラムの上位互換のように捉えられている方もいらっしゃるように思います。
期待値をインフレさせる要因に、AIの初速度の速さがあります。冒頭のKiroによる花火ゲームのPoCのように、良くも悪くもAIはそれっぽいものを早く作ることが非常に得意です。ただし、この初速度が維持されることは極めて稀で、技術的負債や理解負債に阻まれ多くの場合は、数週間から数ヶ月で失速します。
そのため、世の中の輝かしい成功事例をベースにするのではなく、現実解がどのあたりなのかというのを、ステークホルダと丁寧にすり合わせる事が重要です。
とはいえ、もしかすると、お客様からの「AI駆動開発はもっと早く高品質なものが出てくると思っていた」という声は、AI駆動開発に携わるものが必ず一度は通る道なのかもしれません。。。
エンジニアの「質」を重要視する
AI駆動開発では、製造/コーディングの部分が高速になる代わりに、設計とレビューが非常に重たくなるという声がたくさん上がっています。
つまり、AI駆動開発をうまく回すためには、AI(≒3-5年目社員相当)に要件や設計内容をうまく伝え、成果物をレビューできるシニアエンジニアのレベルが求められるといえます。近年アメリカのビッグテックで、ジュニアエンジニアが氷河期で、シニアエンジニアが引く手数多という2極化は、この辺に起因していると思われます。
日本企業は、AI導入の目的を労働時間の削減にしがちと言われており（参考：PwC 生成AIに関する実態調査2025春 5か国比較の資料）、人間をAIに置き換えることを目的にしやすいですが、質の良いエンジニア(AIに使われる人ではなくAIを使いこなす人、AIに指示を出せる人、AIの限界を理解している人、AIのアウトプットをレビューできる人)を軽視するべきではありません。
開発準備編
AI駆動開発のフローを整理する
AI-DLC、Kiro、スクラム、開発方法論(DDD/BDD/TDD)などは、概念や対応関係が必ずしもきれいに紐づくわけではありません。
前述の通り、ウォータフォールの段階的な詳細化とスクラムのクィックなサイクルをベースにAIを加えて、新たな開発方法を編み出す必要があります。
その際に、具体的に手を動かして開発を進めていくためには、下記のようなものを抽象的な概要ではなく、開発のフローに落とし込んでいく必要があります。
- 開発フローそのものをどのようにするのか
- AIと人間はどこまでどんなタスクをするのか
- AIにどこまで権限を渡すのか。AIが暴走したときに人間がどうフォローするのか
- ユニットやボルト(AI-DLCの作業の単位)をどのような大きさにするのか
- 仕様書に共通項目や非機能要件はどこまで書くのか
- 各設計書/テストのレビューはどんな観点で行うのか
- 準備の定義/完成の定義/受け入れ基準はどうするのか
- イベントのアジェンダや会議体の設計はどうするのか
- パイプラインや環境などの準備はどうするのか
一部、通常のシステム開発でも定義するような内容も含まれますが、AI駆動開発には、まだ分かりやすいプラクティスがないため、明文化や可視化による共通認識の形成が必要です。
場合によっては人間だけではなく、AIとも認識を合わせる必要があります。
1つの仕様や開発の単位を決める
上記のユニットやボルトの大きさを決める部分に対応しますが、1つの仕様の大きさや区切り方をチームで認識合わせすることをおススメします。
(スクラムでいうところの基準バックログや、これ以上大きい場合は分割するなどのルールに相当します)
これには現状正解はありませんが、大きくなるほどAIが解釈するのが難しくなり、小さくなるほど人間が細分化する手間が増えます。
また、DDD(ドメイン駆動開発)/TDD(テスト駆動開発)/BDD(振る舞い駆動開発)など、仕様をうまく分割するために、これらの手法や概念を活用するのも一つの手だと思います。
ただし、それぞれの手法が考案されたタイミングでは、AI駆動開発というものはなかったため、過剰に引きずられないように注意も必要です。
ユビキタス言語/用語集を作る
ユビキタス言語は、DDDから生まれた概念となりますが、語弊を恐れずに言ってしまうと、用語集です。
本来は、ビジネス側の方と開発側の方が同じ概念に対して、同一の用語を用いて認識齟齬を起こさないようにするものですが、AI駆動開発においても、人間とAIが同じ認識を持つために非常に重要な役割を果たします。
仮に、ビジネス側と開発側で同じ用語を使っていたとしても、業界用語や社内の用語だった場合は、AIには伝わらず、一般的な解釈や意図しない意味として理解してしまいます。
そのため、ユビキタス言語を定義しておくと、人間とAIで同じ用語を話すことができるようになります。
ただし、ユビキタス言語は書き出していくと無限におわらないため、やはり重要度に応じて、主要な概念から定義・言語化していくのがよいでしょう。
技術的負債・理解負債のリスクを認識する
DORAのレポートでは、AIを増幅器であると表現しています。つまり、優秀な人がAIを使えば何倍にも威力を発揮する一方で、知識不足/技術不足でAIを使うと負債が加速度的に増えていくという側面が指摘されています。
また、AI駆動開発特有の問題として、昨今問題視されているのが、理解負債です。
AIが作った成果物のチェックやレビューを疎かにした結果、AIに任せていたので人間の方がわからないというのが理解負債です。
「AIが作ったものをどれだけ人間が自分の物にできるのか」や「トラブルが起きたときにAI自身に説明や解決をさせることができるのか」などチーム内で理解負債へのリスクコントロールをする必要がでてきています。
Mob Elaborationをする
AI-DLCでは、Mob Elaborationが推奨されています。
前述の通り、AI駆動開発/仕様駆動開発では、コーディングが軽い代わりに、設計とレビューが重くなります。
つまり、通常POが主に作るバックログなども、POとDevが総出でAIと認識を合わせながら、仕様を詰めていく必要があります。これは必然的にAIを加えたモブワーク(Mob Elaboration)となります。
個人的には、仕様駆動開発を本格的に始める前に、一度Mob Elaborationをチーム全体で行うのをおススメします。
ひとまず題材は重要ではなく、メモアプリでもシンプルなゲームでもなんでも良いと思います。
どちらかというと、ツールを動かしながら作業のイメージをチーム全体でつかみ、
- 要件定義は、POもDevも協力してやらないとまともなものを作ってくれなさそう
- AIが作ったものをどうやってレビューしようか
- 何を教えたらAIがいい動きをしてくれるだろうか
などを、チームで取り上げる機会になれば良いと思います。
最後に
AIやAI駆動開発の登場は、我々の生活や開発スタイルを大きく変化させましたが、これらは魔法のツールではないと思いますし、恐怖のパンドラボックスでもないと思います。個人的には、新しい選択肢や可能性が登場したと考えています。
そして最後に、長文をここまで読んでくださったエンジニアの皆様が、AI駆動開発/仕様駆動開発を始めるきっかけに、本記事がお役に立てば幸甚の極みです。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。