はじめに

株式会社Azitでエンジニアリングマネージャーをしている岩瀬です。
2025年後半から2026年にかけて、AI開発の世界では大きな変化が起きています。Thoughtworks Technology Radarが仕様駆動開発をADOPT（採用推奨）に分類し、AWSは仕様駆動開発のワークフローを組み込んだIDE「Kiro」をリリースしました。テスト駆動開発の提唱者であるKent Beckはインタビューで「TDD is superpower with AI agents（テスト駆動開発はAIエージェントにとってスーパーパワーだ）」と発言しています。
バイブコーディングの限界が広く認識され、より構造化されたアプローチへの移行が進んでいます。私自身も、バイブコーディングで痛い目を見た一人です（※詳細は過去記事「AIを活用した需給予測モデル開発で学んだこと」をご覧ください）。その後、AI駆動開発をどう進めるべきか試行錯誤する中で、気づいたら仕様駆動開発的なアプローチを取るようになっていました。後から振り返って「これは仕様駆動開発だな」と認識した形です。さらに、AIならテスト駆動開発のコスト増を相殺できるのではないかと考え、テスト駆動開発も取り入れました。
この記事では、その過程で得た学びをお伝えします。仕様駆動開発やテスト駆動開発×AIという組み合わせは、業界でもよく目にするようになりました。私としても目指していた方向だったので、今回、在庫シミュレーターという、社内ツールの開発機会を利用して実際に試してみました。教科書通りにはいかない部分も多く、どう工夫したか、何がうまくいって何がうまくいかなかったか。そういった体験を共有したいと思います。
この記事を読んで得られること:

• バイブコーディングの限界と、仕様駆動開発・テスト駆動開発への移行の背景
• AI駆動開発×仕様駆動開発×テスト駆動開発を組み合わせた具体的なフロー
• Claude Code Skillsによるフローの定型化と、サブエージェントとしての設計方法
• 実際の開発で直面した課題（レビュー漏れ、仕様変更の未反映）と、その解決策
• AIの特性を踏まえた、人とAIの役割分担の考え方

本記事の位置づけ

この記事は、過去に公開した記事と関連しています。
記事 テーマ 関連 AIを活用した需給予測モデル開発で学んだこと バイブコーディングでの開発体験 → 本記事の出発点 需給予測モデル開発で実践するAI駆動開発手法 AI駆動開発の方針検討 → 本記事で実践 プロダクトデリバリー責任者とは ForecastX導入を担う職種の紹介 → 本記事のフローを活用する職種 「AIを活用した需給予測モデル開発で学んだこと」「需給予測モデル開発で実践するAI駆動開発手法」での経験と検討を経て、実際に開発を進めながら開発フローを実用的なものへと整理しました。本記事ではその作業を取り上げます。また、「プロダクトデリバリー責任者とは」で紹介したプロダクトデリバリー責任者は、現在私が担っている役割であり、本記事で取り上げたフローを活用して顧客対応の開発業務を行う想定です。

バイブコーディングの限界と仕様駆動開発への移行

バイブコーディングは簡単な指示でコードが生まれ、動くものができる。しかし、プロジェクトが進むにつれて修正が難しくなる。作るまでは早いが、改善しようとすると何倍ものコストがかかる。IBMは2026年のレポートで、バイブコーディングはプロトタイプ向け、仕様駆動開発はミッションクリティカルなシステム向けと分類しています。
私がバイブコーディングで経験した問題の本質は、指示の曖昧さに気づけないことでした。
人が相手なら、曖昧な指示を出せば「それだと分からない」「もう少し具体的に教えてください」と返ってきます。しかし、AIは曖昧な指示を出しても、特に質問もせずにそれなりのものを出してしまいます。だから自分の指示に問題があると気づきにくいのです。そうやって出てきたものは、AIが自由に解釈して形にしています。要求にそぐわない過度な機能が入っていたり、あるべき姿ではあるものの状況に合わなかったりします。例えば、機能の追加や変更時に、不要なラッパークラスを作成していたり、必要のない後方互換を実装していたりしました。一見すると誤りではないですが、ゴールから逆算すると「何のためにやっているのか」が分からないものでした。
この問題を解決するために、試行錯誤する中で自然と「曖昧な箇所を明示的にしていく」アプローチを取るようになりました。ルールや仕様、設計で曖昧さを狭めていく。AIが自由に解釈できる余地を潰していく。後から振り返ると、これが仕様駆動開発でした。
さらに、テスト駆動開発も取り入れました。バイブコーディングでは、追加や変更を行うとバグが多発しました。どこかを直すと別の場所が壊れる。その原因は、変更の影響範囲が把握できていないことでした。テストを先に書けば、変更時にどこが壊れたかすぐに分かります。また、テスト駆動開発の従来のデメリットだった「テストを書くコスト」は、AIに任せれば相殺できるのではないかと考えました。

整理した開発フロー

三つの手法の組み合わせ

私が試したフローは、三つの開発手法を組み合わせたものです。
AI駆動開発では、作成やレビューをAIが実行し、人は指示・判断・ルール設定のみを担当します。仕様駆動開発では、ドキュメントを正（Single Source of Truth）とし、概要から仕様書、設計書、コードの順に落とし込んでいきます。テスト駆動開発では、テストを先に書き、仕様からテスト設計、テストコード、実装コードの順に進めます。
これらは別々の概念ですが、AI開発という文脈では相性が良いのです。仕様書は「AIへの明確な指示」として機能し、テストは「AIの出力を検証する仕組み」として機能します。

基本フロー

具体的なフローは以下の通りです。

要求/要件 → 作業計画 → 仕様書 → 設計書 → テスト設計書 → テストコード → 実装コード

各ステップでドキュメント間の整合性やコードと仕様の整合性をレビューし、後工程での手戻りを防ぎます。AWS Kiroも仕様駆動開発のワークフローを採用していますが、私のフローではテスト駆動開発の概念を組み込んでいます。テスト設計とテストコードを明示的に挟むことで、仕様や設計のレビューも兼ねています。テストを書く過程で「この仕様は曖昧だ」「この設計では実装できない」といった問題が見つかることがあるからです。

要求整理と要件定義

AI駆動開発は、最上流の要求整理から活用できます。ただし、AIは人のようにはヒアリングができません。対話自体はできますが、要求の背後にある本当の課題を探り当てたり、潜在的なニーズを引き出したりすることは苦手です。要求を引き出すこと、スコープを決めていくことは、人が担う必要があります。
今回は社内ツールの開発だったため、必要とする社内メンバーとGoogle Meetで打ち合わせを行いました。打ち合わせの中で、要求整理とスコープの調整（要件定義の一部）を私が行いました。その会話はGoogle MeetのAI文字起こし機能で記録し、内容をClaude Codeに読み込ませて概要資料を作成させました。社内ツールだったので要件定義書だと冗長なものになりそうだったため、概要資料の形を取りましたが、中身は簡易的な要件定義書です。議事録を作成するステップはなく、会話の文字起こしから直接ドキュメントを生成する形です。
このアプローチにより、打ち合わせで出た要求を漏らさず拾い上げ、整理された形で概要資料にまとめることができました。要求整理の段階からAIを活用することで、フロー全体を通してAI駆動開発を実践しています。なお、この打ち合わせはAIのインプットになるため、後工程への影響が大きく、相対的にヒアリングの重要度が上がります。

作業計画の作成

概要資料の作成以降は、全て先に作業計画を立ててから実施します。
作業計画には、タスク名だけでなく、参照すべき仕様書・設計書のセクション、影響を受けるファイル一覧、削除が必要な項目を明記します。「何を見て」「どこを変えて」「何を消すか」を事前に整理することで、作業漏れを防ぎます。
実際に作成した作業計画の抜粋です。仕様書の変更とその影響範囲を明示しています。

### フェーズ4: 新ドキュメント作成

**参照**:
- 概要資料 セクション4.1（統合ドキュメント構成）
- 概要資料 セクション4.2（新ドキュメント目次案）

| # | タスク | 成果物 | 備考 |
|:-:|--------|--------|------|
| 4.10 | シミュレーション結果CSV列定義の変更 | 仕様書 | OP, Q, 財務インパクト列削除、種別列の位置変更 |
| 4.12 | ユニットテスト設計書の最適化対応 | ユニットテスト設計書 | 4.10に伴いOutputWriterテストの列定義変更 |
| 4.13 | シナリオテスト設計書の最適化対応 | シナリオテスト設計書 | 4.10に伴い出力形式検証ケースの列定義変更 |

4.10で仕様書を変更したら、4.12と4.13でテスト設計書も変更する必要があります。この影響範囲を事前に明記することで、「仕様は変えたがテスト設計を変え忘れた」という漏れを防いでいます。
また、各タスク完了時に確認を取り、承認を得てから次のタスクに進むルールにしています。これにより、問題を早期に発見し、手戻りを最小化できます。

仕様駆動開発で上流を固める

ドキュメントをしっかり書く必要があるため、上流（仕様・設計）の作業負荷は確かに上がります。しかし、これはAIに明確な指示を出すために必要な投資です。
バイブコーディングでは、曖昧な指示でもAIがそれなりのものを出してしまいました。仕様駆動開発では、先に仕様を固めることで、AIへの指示が明確になります。AIは仕様通りに実装してくれるので、下流（実装）の負荷は大幅に下がりました。
このフローでは、常に一つ上位のドキュメントをインプットとして、下位のドキュメントを作成します。概要資料から仕様書を作成し、仕様書から設計書を作成し、設計書からテスト設計書を作成する。各ステップで上位ドキュメントの内容を具体化していくことで、情報の抜け漏れを防ぎます。
特に重要なのは、仕様書と設計書の役割分担です。私のプロジェクトでは、以下のように整理しました。

• 仕様書: 計算式・閾値・パラメーター、判定条件を定義（What）
• フロー設計書: 処理の流れ・順序、分岐条件を定義（How）
• クラス設計書: クラス・メソッド定義、実装詳細を定義（How）

また、AIが理解しやすいよう、記載ルールも設けました。

• 処理フローは図だけでなく、ステップごとにテキストで明確に記載する
• 入出力のデータ形式・型を明示する
• 条件分岐がある場合は、すべてのパターンを網羅する
• 曖昧な表現（「適宜」「必要に応じて」など）を避け、具体的に記載する
• 仕様書と設計書で重複する内容は、参照先を明記して重複を避ける

こうすることで、AIが自由に解釈する余地を減らしています。上記の役割分担とルールに則って、「発注点計算」を例にそれぞれのドキュメントでどう記載するかを示します。
仕様書（What: 何を計算するか）

### 5.1 発注点計算
発注点 = 安全在庫 + (日次平均出庫数 × 発注リードタイム日数)
- 安全在庫: 需要変動に対するバッファ在庫
- 日次平均出庫数: 直近N日間の出庫数平均（N=30）
- 発注リードタイム日数: 発注から入庫までの日数

フロー設計書（How: いつ、どの順序で処理するか）

### 3.2 在庫計算フロー
1. CSVファイルから入出庫データを読み込む
2. 日次平均出庫数を算出する（仕様書5.1参照）
3. 発注点を算出する（仕様書5.1参照）
4. 現在在庫と発注点を比較する
5. 結果をCSVファイルに出力する

クラス設計書（How: どのクラスが担当するか）

### 4.1 InventoryCalculator
発注点計算を担当するクラス。
- calculate_reorder_point(): 発注点を算出（仕様書5.1、フロー設計書3.2参照）
- calculate_daily_average(): 日次平均出庫数を算出（仕様書5.1参照）

このように、仕様書では「計算式そのもの」を、フロー設計書では「処理の流れ」を、クラス設計書では「クラスとメソッドの対応」を記載します。
「上流からの修正原則」も徹底しています。テスト実行時に仕様漏れが発見された場合は、実装コードを直接修正するのではなく、仕様書から順に修正していきます。ドキュメントと実装が異なる状態で作業を進めることは許容しません。

テスト駆動開発でAIの出力を検証する

テスト駆動開発は以前から知っており、メリットも把握していました。しかし、「テストを書くコストが上がる」というデメリットがあり、これまで導入を見送っていました。
AIで開発するようになって、「テスト駆動開発によるコスト増を、AI駆動開発で相殺できるのではないか」という仮説が浮かびました。
具体的には、以下の手順でテスト駆動開発を進めました。

1. テスト設計書の作成: 仕様書・設計書を参照し、テストケースを一覧化
2. テストコードの実装: テスト設計書に基づき、AIにテストコードを書かせる（Red状態：テストが失敗する状態）
3. 実装コードの作成: 仕様書・設計書に従い、AIに実装コードを書かせる（Green状態：テストが成功する状態）

テストコードもAIが書いてくれるので、従来の「テストを書くコスト」というデメリットが消えました。また、テスト設計書でテストケースを事前に一覧化することで、「何をテストすべきか」が明確になり、AIへの指示も具体的になります。
テスト要件としては、カバレッジ目標を90%以上（ライン・ブランチ共に）と定めました。ただし、今回の開発では、テストレベルごとの役割分担（コンポーネントテスト・統合テスト・システムテストで何を担保するか）と、テストケースの網羅性の担保（仕様書との対応関係の明示）は十分にできておらず、課題として残っています。

Claude Codeの機能でフローを定型化する

Skillsとは

フローを整理しただけでは、毎回同じ品質で開発を進めることは難しいです。そこで、Claude Codeの「Skills」という機能を活用し、各ステップを定型化しました。
Skillsは、Claude Codeの拡張機能の一つです。以前は「カスタムスラッシュコマンド」と呼ばれていた機能がSkillsに統合され、/doc-reviewと入力するとドキュメントレビューが始まり、/tdd-redと入力するとテストコード作成が始まる、といった形で使えます。各Skillには、実行手順、確認すべき観点、出力形式などを定義でき、誰が実行しても同じ品質の成果物が得られるようになります。
重要なのは「サブエージェントとして実行する」という設計です。context: forkを設定すると、Skillsはサブエージェントとして独立したコンテキストで実行されます。メインの会話コンテキストを消費せず、実行結果のみが要約されて返ってきます。Claude Codeを長時間使っていると、コンテキストが膨らんで応答品質が劣化することがあります。Skillsをサブエージェントとして実行することで、この問題を回避しています。また、disable-model-invocation: trueを設定することで、AIが自動的にSkillsを呼び出すことを防ぎ、意図したタイミングでのみ実行されるようにしています。例外として、/plan-create（作業計画作成）は会話の文脈を引き継ぐ方が適切なため、context: conversationとしています。

Plan Modeとの違い

Claude CodeにはPlan Modeという機能もあります。計画を立てて承認を得てから一気に実行に移るモードです。世の中では、コードを変更せずに安全に分析できる点や、計画をPRのドキュメントに活用できる点がメリットとして挙げられています。一方で、シンプルなタスクに対して過度に計画を立てると時間の無駄になる点がデメリットとして指摘されています。
私も試してみましたが、採用を見送りました。CLAUDE.md（開発ルールを定義したファイル）で整備したルールに従わないことは、Plan Modeを使わなくても起きます。ただ、ステップごとに対話・確認しているので方向修正が容易です。Plan Modeの「一気に実行」だと、途中での方向修正ができません。そのため「勝手に作業を進められている」と感じてしまい、コントロールしづらいと思いました。私は「ステップごとに対話・確認しながら進める」アプローチの方が合っていました。Skillsで各ステップを定型化し、細かい粒度でコントロールしています。

作成したSkills

主なSkillsは以下の通りです。
Skill 役割 /plan-create 仕様書・設計書から作業計画を作成。影響ファイル、削除対象を明記 /doc-review ドキュメント間の整合性をレビュー /tdd-red テスト設計書に基づいてテストコードを作成（Red状態を確認） /tdd-green 仕様書・設計書に基づいて実装コードを作成（Green状態を確認） /code-review 実装コードと仕様書・設計書の整合性をレビュー /doc-reviewの具体例を示します。

/doc-review spec-design docs/designs/inventory_simulator_spec.md

• パラメータ: <レビュー種別> [インプット資料パス]
• レビュー種別: spec-design（仕様書→設計書）、flow-class（フロー設計書→クラス設計書）、test（仕様書→テスト設計書）

このコマンドを実行すると、AIは以下のフェーズで処理を進めます。

1. 確認: 対象ファイルを読み込み、レビュー範囲を把握
2. 棚卸し: 参照箇所を全て一覧化
3. 検証: 一覧化した箇所をチェックし、不整合を検出
4. 横展開: 1件の問題を見つけたら、同種の問題を全体から検索
5. 出力: レビュー結果を所定のフォーマットで出力

処理が完了すると、以下のような形式でレビュー結果が返ってきます。
参照一覧（棚卸し結果）
# 参照元（ドキュメント:行） 参照先 検証結果 1 flow:220 クラス設計書 3.2.1節 OK 2 flow:227 仕様書 3.1節 OK 3 overview:206-226 仕様書の目次案 NG 指摘事項
# 重要度 箇所 内容 修正提案 1 中 overview.md:4.2節 仕様書の目次案に2.4節「シミュレーション種別」が欠落 概要資料の目次案を実際の仕様書に合わせて更新 このように、参照箇所を全て一覧化した上で検証結果を示し、問題があれば具体的な修正提案が出力されます。

AIをチームメンバーとしてマネジメントする

私はもともとプロジェクトマネージャや組織のマネージャを担っていました。計画してルールを定め、メンバーに指示を出して仕事をするのが当たり前でした。この経験が、AI駆動開発のアプローチに影響しています。
マネジメントにおいて、指示を出す以上は相手を信頼する姿勢を大切にしてきました。信頼していないと、細かく監視し続けることになり、双方が疲弊します。任せられる部分は任せ、重要なポイントで確認を入れる。これはAIでも同じです。
ただし、AIには人とは異なる特性があります。AIは知識はあるが、使いどころがわからないのです。ベストプラクティスや設計パターンの知識は豊富ですが、「今この状況でどれを適用すべきか」の判断は苦手です。例えば、小規模でサクッと作りたい簡易ツールなのに、DDDのレイヤー構造を取り入れた重厚なプログラムを組んできたりします。また、プロジェクト全体を俯瞰できないです。これはコンテキストウィンドウの制約によるもので、AIの経験や理解はセッション内で永続せず、状況把握が刹那的になります。さらに、重層的な判断が苦手です。「AとBとCを満たしつつ、Dの影響を最小限にする」といった、複数の判断軸を同時に考慮するトレードオフ判断は、AIには難しいです。
これらのAIの特性を考慮し、人が要点を押さえてAIをマネジメントする必要があります。具体的には、以下のような観点です。

• あるべき姿からの逆算: 最終的なゴールから逆算して、今何をすべきかを判断する。
• 優先順位の設定や変更: 状況の変化に応じて、タスクの順序を見直す。
• 作業範囲の調整: このタスクでどこまでやるか、やらないかを決める。
• 粒度・密度の調整: ドキュメントや実装の詳細度を状況に合わせて調整する。

バイブコーディングの問題を振り返ると、あれは「AIの問題」ではありませんでした。「指示の出し方の問題」だったのです。AIは言われた通りに動きます。私の指示が曖昧で一貫性がなかったから、一貫性のないコードが生まれました。AIを変えようとするのではなく、自分（指示の出し方）を変える必要がありました。

実際の効果

在庫シミュレーター開発での検証

このフローを試したのは、社内ツール「在庫シミュレーター」の開発です。ForecastX導入前の投資判断で使用するツールで、理想的な入出庫を設定し、最適な在庫推移の理論値を導出します。
結果として、異なるタイプの開発でこのフローを試すことができました。
Phase 開発タイプ 内容 1 新規開発 在庫シミュレーター本体をゼロから構築 2 機能追加 既存システムにOPQ-S自動算出機能を追加 3 リファクタリング 2つのプロジェクトを統合・コード整理 Phase 1（新規開発）は、約10日間で完了しました。成果物は、仕様書、設計書（フロー設計書・クラス設計書）、テスト設計書、テストコード、実装コードです。同じ成果物をAIなしで出すとしたら、数ヶ月かかると思います。
Phase 2（機能追加）では、既存システムに大きな変更を加えることなく追加開発ができました。Phase 3（リファクタリング）では、2つのプロジェクトを統合しましたが、基本機能への破壊的な改変が入ることはありませんでした。これらはバイブコーディングではできなかったことです。仕様と設計が固まっていて、テストで検証できる状態だからこそ、安心して追加や変更ができました。
新規開発、機能追加、リファクタリングという異なる開発タイプで同じフローが適用でき、それぞれの段階で問題を抽出して改善できました。

テスト駆動開発の効果

テスト駆動開発のコスト増は全く感じられないレベルでした。むしろ、テストがあることでAIの出力を検証でき、安心して開発を進められるようになりました。

作業を進める中で改善したこと

Skillsは最初から完成していたわけではありません。実際に使う中で問題が発生し、改善を重ねてきました。
棚卸し・横展開フェーズの追加
仕様書や設計書を更新すると、セクション番号が変わることがあります。他のドキュメントで参照しているセクション番号も修正が必要ですが、それが修正されないまま残ってしまうことがありました。
例えば、仕様書の「3.2 在庫計算ロジック」を「3.3」に変更したとします。設計書やテスト設計書では「仕様書3.2参照」と書いてある箇所が複数あります。仕様書を更新したときに、それらの参照箇所も全て「3.3参照」に修正しなければなりません。しかし、レビューで指摘は出るものの、網羅的ではありませんでした。1箇所指摘される、修正する、再レビューする、また別の修正漏れが見つかる...このサイクルが終わらない。スケジュールは遅延し、「またか」と正直うんざりしました。
なぜAIは網羅的にチェックしてくれないのか。考えてみると、私の指示が悪かったのです。「整合性をチェックして」とだけ言っていたから、AIは見つけたものから順に報告してきました。
そこで、レビューのSkillsに「棚卸し」「横展開」という2つのフェーズを追加しました。「棚卸し」では、まず参照箇所を全部一覧化してからチェックします。「横展開」では、1件の問題を発見したら、同種の問題を全体から検索します。AIに「一覧化してから検証せよ」「1件見つけたら横に展開せよ」と明示的に指示することで、レビュー漏れが大幅に減りました。
受入テストのエラー分析と改善
受入テストでエラーが多発したため、原因を分析しました。15件のエラーのうち、ユニットテストで検出されたものは0件でした。
原因カテゴリ 件数 比率 仕様変更の未反映 7 41% 出力形式の不一致 3 18% 設計上の問題 2 12% 入力処理の問題 2 12% 計算ロジックの誤り 2 12% その他 1 5% 最多は「仕様変更の未反映」で、全体の41%を占めていました。仕様書を更新したのに、実装やテストが追従していなかったのです。また、ユニットテストで検出0件という事実は、テストにも問題があることを示しています。テストの観点が「機能動作」に偏り、「仕様との整合性」の検証が不足していました。テストの問題は2つあります。1つは、パターンや境界値を網羅したマトリクス表がなく、テストケースの網羅性が担保できていなかったこと（全テストレベルに共通する問題）。もう1つは、テストレベルごとにテストケースを設計せず「テスト」とひとまとめにしていたため、上位のテストレベル（統合テスト、シナリオテスト）のテストケースが不足していたことです。
この分析結果を受けて、2つの対策を行いました。
対策1: Skillsの改善（実施済み）
CLAUDE.md（開発ルールを定義したファイル）に以下の原則を追加しました。

影響範囲を明示する: 仕様変更時は、影響を受けるドキュメント・コード・テストを一覧化する 削除も計画する: 追加・変更だけでなく、削除すべき項目も作業計画に含める 残存を許容しない: 旧仕様のコード・設定・テストが残存している状態で作業を完了としない

/plan-createSkillも改善し、作業計画に「影響範囲」「削除対象」を必ず明記するようにしました。
対策2: テスト設計の改善（今後の課題）
Phase 1ではテスト設計を省略し、後追いで作成していました。仕様と設計に意識が集中しており、テスト設計の重要性を十分に認識していなかったのです。今後は、テスト設計書に仕様書・設計書との対応関係を明記し、パターンや境界値を網羅したマトリクス表を作成すること、テストレベルごとにテストケースを設計することで、テストの網羅性と充実を図る予定です。

プロダクトデリバリー責任者とこのフローの関係

※詳細は過去記事「プロダクトデリバリー責任者とは」をご覧ください。
プロダクトデリバリー責任者は、ForecastX導入時に基幹システムやWMSとの連携API開発を担う職種です。技術とビジネスの両方を活かして顧客課題を解決します。
このフローは、プロダクトデリバリー責任者が顧客ごとに異なる要件に対応しながら、再現性のある開発を行うための手段として位置づけています。顧客の基幹システムとForecastXを連携させるためのAPI設計やデータ変換、業務フローに合わせたシステム構築など、技術的な実装が発生します。そこで、今回整理したフローを使用します。

おわりに

AIで生産性を上げるなら、従来のやり方をAIに代替させるだけでは不十分です。AIが作業する前提で、やり方を再構築する。人がやる場合にできなかったことを実現する。これがAI駆動開発の本質だと考えています。
AI駆動だからといって、AIに任せっきりにはできません。また、AIが作業するようになっても、従来の開発に関する知見が不要になるわけでもありません。AIを使うから楽にはなりますが、真にその楽を達成するには各工程の知識や知見を幅広く必要とします。
仕様駆動開発もテスト駆動開発も、従来は「コストがかかりすぎる」「時間がない」という理由で見送られがちでした。概念としてのメリットは知っていても、実際の開発で導入するのは難しかった。AI駆動開発により、そのコストの問題が解消されました。これまで理想論だったことが、現実的な選択肢になったのです。
AI駆動開発に興味はあるが踏み出せていない方へ。まずは使ってみてください。正解やゴールはまだありません。この記事で紹介したフローも試行錯誤の結果であり、最終形ではありません。一緒に模索していきましょう。
最後まで読んでいただき、ありがとうございました。