はじめに
AIを開発に使い始めると、「意図しない作業や回答をしたからプロンプトを修正する」「バグが出たらコードを確認して直す」こうした個別対処の繰り返しになりがちです。ひどい時には修正と確認のループからなかなか抜け出せません。私もそうでした。
個別に対処しても根本は変わりません。プロジェクトを重ねる中で、問題はコードやプロンプトではなく、開発プロセスそのものにあると私は考えるようになりました。
この記事では、複数のプロジェクトを通じて到達した「AIを開発プロセスに組み込む際の考え方」と、その実践をまとめています。核にあるのは「AIをマネジメントする」という発想です。プロジェクトマネジメントやエンジニアリングマネジメントの経験が、この方向に導いてくれました。
この記事を読んで得られること:
- バイブコーディングの限界と、その本質的な原因
- AIをマネジメントするという視点
- 仕様駆動開発 × テスト駆動開発 × AI駆動開発を組み合わせた開発フロー
- Claude Code Skillsによるプロセス定型化の実例
- 「代替」ではなく「再構築」という考え方
バイブコーディングの壁と原因
バイブコーディングで何が起きたか
私もあるプロジェクトでバイブコーディングを試しました。自然言語でざっくりとした要望を伝え、AIに実装を任せるアプローチです。思っていたよりも表面上はうまくいき、動くものができて一定の成果も出ました。
しかし、開発が進むにつれて問題が出てきました。
- 処理を調整しようとすると、関係ないと思った箇所でエラーが出る
- 全体設計が存在せず、不要な機能や使われない関数が大量に残っている
- 規模や機能に見合わない、過剰な構成や実装になっていた
計画的なプロセスを導入することで、一旦は改善はできました。しかし、なぜこうなったのかを理解しなければ、次のプロジェクトでも同じことが繰り返されます。
なぜ起きたか
問題が繰り返される背景にはAIへの指示の曖昧さに気づけないことがありました。
たとえば、数百行で完結する簡易ツールに対して、ドメイン駆動設計のレイヤ構造を適用してくるケースがありました。設計パターンとしては正しいのですが、この規模には不釣り合いです。不要なラッパークラスや、必要のない後方互換が実装されていることもありました。一見すると誤りではないのですが、ゴールから逆算すると「何のためにやっているのか」がわからないものでした。
なぜこうなるのか。人に曖昧な指示を出せば、「それだとわかりません」「もう少し具体的に教えてください」と返ってきます。ところがAIは、曖昧な指示でも質問せずにそれなりのものを出してしまいます。だから自分の指示に問題があっても気づきにくいのです。
問題の原因を深掘りすると、AIと指示する私の両方にありました。
まずAI側です。発生した問題やAIの回答を観察していくと、3つの特性が浮かび上がってきました。
1つ目は、知識はあるが使いどころを判断できないことです。設計パターンやベストプラクティスの知識は豊富ですが、「今この状況でどれを適用すべきか」の判断ができません。先ほどの簡易ツールへのドメイン駆動設計の適用は、まさにこれです。
2つ目は、プロジェクト全体を俯瞰できないことです。コンテキストウィンドウの制約により、AIの状況把握は刹那的です。個々のタスクは処理できても、プロジェクト全体を見渡した判断はできません。
3つ目は、重層的なトレードオフを伴う判断が苦手なことです。「AとBを満たしつつ、Cの影響を最小限にする」といった、複数の判断軸を同時に考慮する場面で、バランスの取れた判断を下すのが難しいようです。
指示する私側にも原因がありました。詳しく説明しなくてもAIが出力するので、それに頼り切っていたのです。AIの特性を理解した上で自分がカバーするべきでしたが、そのプロセスを持っていませんでした。
振り返ると、これは「AIの問題」ではありませんでした。AIは指示された通りに動いています。曖昧な指示を出していた私の側に問題がありました。
AIの特性は変えられません。変えられるのは、自分たちの指示の出し方と開発の進め方です。
AIをマネジメントする
マネジメントという発想
バイブコーディングで失敗した後、思考が向いたのはコーディングの改善ではなく、開発の進め方そのものでした。計画を立て、ルールを定め、メンバーに指示を出して仕事をする。その経験が、AIとの協働の方向性に影響しています。
人のマネジメントとAIのマネジメントには、違いと共通点があります。
| 観点 | 人のマネジメント | AIのマネジメント |
|---|---|---|
| フィードバック | 不明点を質問してくる | 曖昧でもそのまま出力する |
| 信頼 | 任せて、要所で確認する | 同じ |
| 記憶 | 経緯や仕様を記憶している | 記憶がない。ドキュメントで補う |
| 帰属 | まず自分の指示を疑う | 同じ |
最大の違いはフィードバックと記憶です。人のマネジメントではフィードバックが自然に返ってくるので指示の問題に気づけますが、AIにはそれがありません。記憶もないため、口頭の指示を重ねるほど全体像が失われます。この2つの不在を、検証の仕組みとドキュメントで補う必要がありました。
一方で、信頼と帰属は共通しています。任せられる部分は任せ、要所で確認する。出力が意図に合わないときはまず自分の指示を疑う。これは人に対しても大事にしてきた姿勢であり、AIでも同じでした。
重要なのは、人の作業をそのままAIに置き換えるのではなく、違いと共通点を踏まえて、人とAIが協働する前提で開発の進め方を組み直すことです。
人が担うべき判断と役割分担
前章で見た3つの特性（判断できない・俯瞰できない・トレードオフが苦手）を裏返すと、人が担うべき判断が見えてきます。
| 判断軸 | 内容 | 例 |
|---|---|---|
| あるべき姿からの逆算 | ゴールを定義し、必要な作業を導く | プロジェクトの完成状態を定義する |
| 優先順位の設定・変更 | 何を先にやるか、状況に応じて変更する | 機能Aを先に、BはPhase2に回す |
| 作業範囲の調整 | 何をやり、何をやらないかを決める | MVPに含める範囲を決定する |
| 粒度・密度の調整 | どこまで詳細に設計・実装するかを決める | 画面は設計書を厚く、バッチは軽く |
これらを踏まえると、人とAIの役割分担は以下のようになります。
| 担当 | 役割 |
|---|---|
| 人間 | ヒアリング、要求整理、戦略決定、品質管理、最終判断 |
| AI | 要件定義、設計、実装、テスト、ドキュメント |
要求整理にはヒアリングが不可欠ですが、要求の背後にある課題を探り当てたり、潜在的なニーズを引き出すことはAIにはできないので人が実施します。人は「何を作るか」「何を優先するか」「品質は十分か」を判断し、AIは「どう作るか」を実行します。では、この役割分担を開発プロセスとしてどう実現するか。次章ではそれを3つの開発手法の組み合わせとして示します。
AI駆動 × 仕様駆動 × テスト駆動
3つの開発手法を組み合わせる
前章の役割分担 — 人が方向づけ・検証・判断を担い、AIが実行する — を開発プロセスに落とし込むと、自ずと3つの開発手法の組み合わせになりました。
| マネジメントの考え方 | 開発手法 | 問題への対応 |
|---|---|---|
| 方向づけを明確にする | 仕様駆動開発 | 仕様書で曖昧さを排除し、AIへの指示を明確にする |
| 出力を検証する | テスト駆動開発 | テストでAIの出力を客観的に検証する |
| 役割を設計する | AI駆動開発 | 人とAIの役割分担を設計し、人がマネジメントする |
この3つにそれぞれ独立に到達したわけではありません。実践の中で自然とこの組み合わせに至りました。
AIには記憶がないため、指示や決定をドキュメントとして残す必要があります。そして記録する以上、曖昧なままでは意味がありません。仕様や設計をルールとして書き下し、AIが自由に解釈する余地を狭めていく。後から振り返ると、これが仕様駆動開発でした。
テスト駆動開発にも、別の経路から到達しました。変更の影響を即座に検知する手段が必要でした。テストを先に書いておけば、変更時にどこが壊れたかすぐにわかります。テスト駆動開発は以前から知っていましたが、「テストを書くコストが高い」という理由で導入を見送っていました。しかし、AIがテストを書くならそのコストは相殺できるのではないか。この仮説が出発点でした。
つまり、仕様書は「AIへの明確な指示」として、テストは「AIの出力を検証する仕組み」として機能します。
仕様駆動開発もテスト駆動開発も、従来は「コストがかかりすぎる」として見送られることが多かったのではないでしょうか。仕様書を詳細に書く工数、テストを先に書く工数が、人だけでは現実的ではありませんでした。AIが作業を担うことで、このコスト問題が解消されます。
開発フロー
3つの開発手法の統合を開発フローとして表現すると、以下のパイプラインになります。
要求/要件 → 作業計画 → 仕様書 → 設計書 → テスト設計書 → テストコード → 実装コード
各フェーズの要点を示します。
| フェーズ | 担当 | 要点 |
|---|---|---|
| 要求/要件 | 人間 | あるべき姿の定義、スコープと優先順位の決定 |
| 作業計画 | AI（人が承認） | 影響範囲の明示、削除対象も計画に含める |
| 仕様書 | AI（人が承認） | What（何を）を定義。計算式やパラメータ定義で曖昧さを排除 |
| 設計書 | AI（人が承認） | How（どうやって）を定義。フロー設計とクラス設計 |
| テスト設計書 | AI（人が承認） | マトリクス表でパターンを網羅。テストレベル（コンポーネントテスト/統合テスト/システムテスト）ごとに設計 |
| テストコード | AI | テスト設計書に基づきテストを実装（Red確認） |
| 実装コード | AI | 仕様書・設計書に基づき実装（Green確認） |
AI駆動 — AIが生成し人が承認する
要求整理の段階からAIを活用します。ヒアリング自体は人が行いますが、会話の記録をAIに読み込ませ、要件を構造化して概要資料を作成させます。議事録を挟まず、会話の記録から直接ドキュメントを生成する形です。
作業計画はAIをマネジメントするための手段です。参照すべきドキュメント、影響を受けるファイル、削除が必要な項目を事前に明示させることで、余計な作業を防ぎます。
仕様書以降も同様に、全工程でAIが生成し人が承認する構造です。この構造を定型化するのが、次章で紹介するSkillsです。
仕様駆動 — ドキュメントで曖昧さを排除する
上流の作業負荷は上がります。しかし、これはAIに明確な指示を出すための投資です。仕様を先に固めることでAIへの指示が明確になり、下流の負荷は大幅に下がりました。
常に上位のドキュメントをインプットとして下位のドキュメントを作成します。概要資料から仕様書を、仕様書から設計書を、設計書からテスト設計書を作成する。各ステップで上位の内容を具体化していくことで、情報の抜け漏れを防ぎます。
仕様書はWhat（何を作るか）を、設計書はHow（どう作るか）を定義します。たとえば「発注点 = 安全在庫 + 日次平均出庫数 × リードタイム日数」が仕様であり、「CSVから入出庫データを読み込み、日次平均を算出し、発注点を計算して結果を出力する」が設計です。この分離により、仕様変更時の影響範囲が明確になります。
上流からの修正原則も設けています。テスト実行時に仕様漏れが見つかった場合、コードを直すのではなく仕様書から修正します。仕様書がSingle Source of Truthであり、コードはその実装にすぎません。
テスト駆動 — AIの出力を検証する
テスト設計書を先に作成し、テストコード（Red確認）→ 実装コード（Green確認）の順で進めます。テストを書く過程で「この仕様は曖昧だ」「この設計では実装できない」といった問題が見つかることもあり、仕様や設計のレビューも兼ねています。
AIにテストを書かせるからといって、テストの設計まで任せきりにはしません。コンポーネントテスト・統合テスト・システムテストの各レベルで何を担保するかを事前に設計し、段階的に検証の粒度を上げていきます。
Skillsと実践
Skills
前章の開発フローをAI駆動で実現するために、Claude Code Skillsを活用しています。Skillsは、Claude Codeの拡張機能です。/doc-reviewと入力するとドキュメントレビューが始まり、/tdd-redと入力するとテストコード作成が始まります。各Skillに実行手順、確認すべき観点、出力形式を定義しています。
| Skill | 対応フェーズ | 役割 |
|---|---|---|
| /plan-create | 作業計画 | 影響ファイルと削除対象を明記した作業計画を作成 |
| /doc-review | 仕様書〜設計書 | ドキュメント間の整合性をレビュー |
| /test-design | テスト設計書 | 仕様書・設計書からテスト設計書を自動生成 |
| /test-review | テスト設計書 | テスト設計の品質を7軸で検証 |
| /tdd-red | テストコード | テスト設計書に基づきテストコードを作成（Red確認） |
| /tdd-green | 実装コード | 仕様書・設計書に基づき実装コードを作成（Green確認） |
| /code-review | 実装コード | 実装と仕様書・設計書の整合性をレビュー |
Skillsの設計にはいくつかのポイントがあります。
サブエージェント実行（context: fork） — Skillsはサブエージェントとして独立したコンテキストで実行します。メインの会話コンテキストを消費せず、応答品質の劣化を防ぎます。ただし/plan-createは会話の文脈を引き継ぐ必要があるためcontext: conversationにしています。
自動呼び出しの抑制（disable-model-invocation: true） — AIが自律的にSkillsを呼び出すことを禁止しています。人が意図したタイミングでのみ実行する。マネジメントの原則（人が判断する）をツールレベルで実装しています。
マルチエージェント構成 — /test-designでは、テスト設計を4つのエージェントに分割しています。コンポーネントテスト・統合テスト・システムテストの各レベルを専任エージェントが並列で設計し、オーケストレーターが統合とトレーサビリティマトリクスの生成を担います。テストレベル間の漏れを構造的に防ぐ設計です。
実践結果
異なるプロジェクトでこのフローを検証した結果を示します。
プロジェクトA では、テスト駆動開発を導入しましたが、コスト増は感じませんでした。しかし課題も見つかりました。受入テストで検出されたエラー15件を分析したところ、最多は「仕様変更の未反映」で7件（41%）でした。
| エラー分類 | 件数 | 割合 |
|---|---|---|
| 仕様変更の未反映 | 7 | 41% |
| 出力形式の不一致 | 3 | 18% |
| 設計上の問題 | 2 | 12% |
| 入力処理の問題 | 2 | 12% |
| 計算ロジックの誤り | 2 | 12% |
| その他 | 1 | 5% |
仕様書を更新したのに、テストや実装が追従していなかった。トレーサビリティマトリクスがなく、仕様変更時にどのテストを更新すべきかが把握できていなかったことに起因すると考えています。
プロジェクトB では、この課題を受けて/test-designと/test-reviewを導入しました。
| 指標 | 結果 |
|---|---|
| テストケース数 | 204件（コンポーネント 162 + 統合 24 + システム 18） |
| 仕様カバレッジ | 100%（29/29セクション） |
| レビューラウンド | 3回（23件→22件→OK判定） |
プロジェクトAで最多だった「仕様変更の未反映」は、/test-designのトレーサビリティマトリクス自動生成で構造的に解消されたと考えています。仕様書のセクションとテストケースの対応が自動生成されるため、仕様変更時にテストの更新漏れが検知できるようになりました。
おわりに
複数のプロジェクトを通じて到達した考え方をまとめます。
従来の開発プロセスは、人のみが作業する前提で設計されています。AIで生産性を上げるなら、人の作業をAIに置き換えるだけでは不十分です。人とAIが協働する前提で、プロセス自体を作り直す。本記事で示した開発フローは、人だけで運用するにはコストが重すぎます。AIが作業を担うからこそ成立するフローであり、これは単純な代替ではなくAIがあることを前提とした開発プロセスの再構築です。
AIが作業を担っても、従来の開発手法や設計概念、プロジェクトを通じて培った経験は不要になりません。むしろ今までよりも必要になります。AIは膨大な知識を持っていますが、その使いどころを見極めるのは人です。システム開発に関する様々なことを知らなければ、AIが持つ知識を正しく引き出すことも、その出力を評価することもできません。楽にはなります。しかし、楽を達成するには各工程の知識が幅広く必要です。AIとの協働は、AIへの丸投げではありません。
一方で、AIが作業を担うことで、従来はコストを理由に見送っていた手法を採用できるようになりました。選択肢が広がることで、開発プロセスの設計そのものが変わります。
2026年2月、OpenAIが「ハーネスエンジニアリング（Harness Engineering）」を発表しました。AIエージェントが確実に動作するための制約・ツール・フィードバックループ・検証の仕組みを設計する技術分野です。本記事の考え方と方向性が一致します。仕様書はAIへの明確な指示であり、テストはAIの出力を検証する仕組みであり、Skillsはフローを定型化するツールです。実際に、同じモデルでも周囲の仕組みの設計を変えるだけでベンチマークの成功率が大幅に変動する事例が報告されています。モデルの選定よりも、モデルを包む仕組みの設計が重要だということです。