はじめに
GO株式会社でデータサイエンスチームのマネージャーを務めている織田です。
この記事では、最近注目されているスペック駆動開発（Spec-Driven Development: SDD）が、データ分析プロジェクトにどこまで適用できるかを考察し、探索的なプロジェクトに適したアプローチを提案します。
SDDとは何か
「雰囲気」でコーディングエージェントに指示を出してコードを生成させるVibe Codingは、大規模で長期のシステム開発では破綻すると言われています。アーキテクチャを考慮しないスパゲッティコードの量産、対話が進むにつれてAIが初期要件を忘れるContext Drift、開発者がコードの中身を理解しないまま進む「理解なき実装」といった問題が起きてきます。
こうした問題への対策として注目されているのがスペック駆動開発（Spec-Driven Development: SDD）です。SDDのエッセンスはシンプルで、「コードではなく仕様（Spec）がSource of Truthである」という考え方です。人間が仕様を書き、AIエージェントがそれに基づいて実装する。仕様を変更すればAIがコードを再生成するので、仕様とコードの乖離が起きにくくなります。
具体的なプロセスとしては、GitHub Spec Kitなどで標準化されつつある4フェーズモデルがあります。
| フェーズ | 目的 | 成果物 |
|---|---|---|
| Specify（仕様化） | 意図の明確化 | spec.md |
| Plan（計画） | 技術的実現性の検証 | plan.md |
| Tasks（分解） | 実装単位の定義 | tasks.md |
| Implement（実装） | コーディングと検証 | コード, テスト |
SDDのメリットは、AIへの指示が明確になりやり直しが減ること、ワークフローが標準化されること、チーム内の認識共有が進むことなどです。一方で、簡単なバグ修正にまで仕様書を書くのはオーバーヘッドになりますし、AIが生成する大量のMarkdownをレビューする手間もかかります。プロジェクトの規模や性質に応じた使い分けが必要です。
なお、「AIがもっと賢くなれば仕様なんて不要では？」という疑問もあると思います。個人的には、仕様による意図の明確化は、AIの性能とは独立した問題と思っています。AIの能力が上がるほど「可能性の空間」が広がり、指示が曖昧だとかえって意図しない方向に進むリスクが増すのではないかという声もあるようです。
データ分析にSDDは有効か
SDDの背景を踏まえたうえで、これをデータ分析プロジェクトに適用するとどうなるかを考えます。データ分析プロジェクトといっても色々あるので、次の2つの軸で整理してみたいと思います。
- 探索性（縦軸）: ゴールまでの道筋にどれだけ不確実性があるか、データや分析手法の有効性にどれだけ事前知識があるか
- 複雑性（横軸）: 用いる分析手法（アルゴリズム）がどれだけ複雑か、作成するシステムがどれだけ大規模か
- 低探索 × 低複雑（左下）: Vibe Codingで十分なケースも多く、後から仕様化するアプローチでも問題ありません。
- 低探索 × 高複雑（右下）: 通常のソフトウェア開発と類似点が多く、SDDが最も適している領域と言えます。
- 高探索（上）: 事前に「何を作るか」の仕様を完全に決めることが難しく、探索プロセスの仕組み化・ドキュメント化を行うアプローチが必要になりそうです。複雑性が高いほど構造化がより重要になってきます。
データ分析プロジェクトの特殊性
探索性が高いとなぜ事前に仕様を決めるのが難しいのでしょうか？そもそも、探索的なデータ分析プロジェクトは通常のソフトウェア開発と何が違うのでしょうか？データ分析プロジェクトの特殊性を次の4点に整理してみました。
1. 「問い」が本質
ソフトウェア開発は「仕様」を定義して「作る」プロセスですが、データ分析は「問い」に対する答えを「発見する」プロセスです。分析の中で新たな問いが生まれることもあり、事前に立てた計画を修正しながら進む必要があります。
学術研究においては「リサーチクエスチョン」を見つけることが最も難しいと言われることがありますが、ビジネスにおける分析でも「答えたい問い」を事前に明確に定義することがアウトプットを最大化する上で重要だと思います。特にエージェントを活用する場合、明確なゴールを決めずにAIと分析を始めると、様々な分析や可視化をAIが次々と提案してくるので、その解釈にマインド・時間を要し、無駄に時間を浪費するリスクがあります。
2. データの不確実性と変化
データ分析ではコードだけでなくデータを扱う必要があります。データの仕様（欠損値、外れ値、カテゴリの意味など）についてはエージェントが扱いやすい形のドキュメントが管理されていないことが多く、また、サービスの変化に伴ってスキーマやカテゴリ定義が変わることもあります。
データの不確実性に対処するためには、事前に詳細な計画を立てるのではなく、データを見ながら臨機応変に分析方針を調整できるような柔軟な枠組みが必要です。例えば、データ数が思ったより少ないことがわかったら、他のデータソースを探したり、複雑なモデルを試すのはやめて単純な集計に切り替えたりといった判断が必要になります。
3. 「静かなる失敗」のリスク
コードは正常に動き評価指標も十分なのに、方法論的に間違っているケース（データの解釈間違い、SQLバグ、データリークなど）があります。ソフトウェアのバグはテストで検出できますが、こうした方法論的な欠陥を見つけることは困難です。
「静かなる失敗」に対しては、分析の途中結果（例えば、データセットの記述統計や簡単な可視化結果など）を人間がレビューした上で次のステップに進むようなプロセスが必要です。コードが正しく動いているかだけでなく、分析の方法論的な妥当性をレビューする機会を設けることが重要になります。
4. 「意思決定の根拠」の重要性
改善サイクルを効率的・効果的に回すためには、「なぜその判断をしたのか」を自身とAIが理解できるようにすることが重要になります。なぜこの手法が適切なのか？なぜこのパラメータの値が適切なのか？なぜこの打ち手が最も筋が良いのか？こうした意思決定の根拠を理解しないと自身の分析に対して自信を持てず不安になりますし、ステークホルダーに求められても説明することもできません。試行錯誤の過程や棄却した仮説も含めて記録することで、チーム全体の学習が蓄積され、同じ失敗を繰り返さない組織的な知見が形成されます。
データ分析構造化の試み
SDD的な発想でデータ分析を構造化する試みとしては ARIA（arXiv:2510.11143）フレームワークなどがあるようですが、私自身はより柔軟でビジネスの分析プロジェクトに合ったアプローチを試しています。基本はHuman-in-the-Loopで、1ループごとに人間が結果を解釈しながら進めるスタイルで、Claude Codeのスキルを使って、データ分析プロセスをSDD的に構造化するアプローチです。まだ試行錯誤の途中ですが、一例として紹介します。
Phase 1: 準備
ビジネス上の問いを定義します。「なぜこの分析が必要か」「何を明らかにしたいか」をidea.mdに記載します。
Phase 2: 方針策定
/spec-initを実行すると、AIがidea.mdを読み込んで分析方針（仮説、手法、評価基準）をspec.mdとして生成します。人間が確認・修正してから次に進みます。
Phase 3: データ準備
/data-selectionにより、AIがspec.mdに基づいてSQLを生成します。AIが必要な情報を自分で引き出せるように、データスキーマの参照、データパイプライン定義の参照、過去の分析知見の検索といったスキルを用意しています。
必要に応じて、/data-checkでSQLの実行結果をもとにデータの記述統計や簡単な可視化を生成し、データ品質を確認します。欠損値やスキーマの問題がここで見つかれば、spec.mdに立ち返って方針を修正します。データの現実を見てから方針を調整できるフィードバックループが組み込まれている点が、事前に完全な仕様を求めるSDDとの違いです。
Phase 4: 分析実行（探索タスクループ） ここがプロセスの中核です。AIが1タスクをレビューしやすい粒度に分解し、人間が適宜レビューしながら以下のサイクルを繰り返します。このループは探索アルゴリズムのように、ゴール（問いの答え）に到達するまで続くイメージです。
- Plan:
/task-planで作業計画書（workplan.md）を作成。このタスクで「何を明らかにするか」「どの手法を使うか」を事前に定義。 - Execute:
/task-executeで作業計画書に従ってノートブックを作成・実行。必要により人間が修正。 - Report:
/task-reportでタスクレポート（report.md）を作成。「何がわかったか」「次に何をすべきか」を記録。
Phase 5: 最終化 全タスクの統合レポートを生成し、人間が最終確認します。
成果物は以下のように整理されます。
projects/YYMM_project-name/ ├── docs/ │ ├── idea.md # ビジネス上の問い（人間が作成） │ ├── spec.md # 分析方針（AI生成→人間承認） │ ├── data_check.md # データ品質確認結果 │ ├── 01_task-name_workplan.md # タスク1作業計画書 │ ├── 01_task-name_report.md # タスク1レポート │ ├── 02_another-task_workplan.md # タスク2作業計画書 │ ├── 02_another-task_report.md # タスク2レポート │ └── final_report.md # 最終レポート ├── sql/ # データ取得SQL ├── notebook/ # 分析ノートブック └── src/ # 再利用可能なコード
このプロセスの重要な副産物は、workplan.mdとreport.mdに意思決定の根拠が自然に蓄積されることです。「なぜこの手法を選んだのか」「別のアプローチを試した結果なぜ棄却したのか」が記録に残ることで、自身の思考の整理にもなりますし、後からプロジェクトを引き継ぐ際にも分析の全体像を理解しやすくなるのではないかと期待しています。
まとめ
今回、スペック駆動開発（SDD）の考え方をデータ分析に適用しようとしたことで、結果的にデータ分析プロジェクトがソフトウェア開発とどう異なるかを整理できました。重要なのは、事前に完全な仕様を決めるのではなく、データを見ながら方針を調整できる柔軟な枠組みを持つことだと思います。Human-in-the-Loopで1ステップごとに人間がレビューし、意思決定の根拠を蓄積していくアプローチは、探索性と構造化のバランスを取る一つの方向性になるのではないかと考えています。
最後までお読みいただき、ありがとうございました。
