LLMエージェント×Spec駆動開発で挑む、次世代の分析基盤構築
1. 導入: なぜ手戻りは終盤に集中するのか
データ基盤構築のプロジェクトでは、終盤に手戻りが集中する。既存帳票との数値差分が出る、暗黙のロジックが後から発覚する、リリース直前のレビューで実際の業務フローと合わず大幅な改修要望をいただく。経験のあるエンジニア・コンサルタントなら一度は遭遇したパターンである。
これは個別案件のスキル不足ではなく、従来型のフェーズ構成そのものに組み込まれた構造的問題だと考えている。要件定義をある程度で切り上げ、動くものを作ってから顧客と詳細を詰める。短期的には早く見えるが、終盤の手戻りを前提にした構造になっている。
LLM によって SQL や Dataform の実装は確かに速くなった。ただし、実装だけが速くなると、曖昧な要件のまま下流へ早く進んでしまうだけで、後工程の手戻りはむしろ拡大する。
そこで、アプリケーション開発で広がってきた spec 駆動開発を分析基盤構築に持ち込み、複数のプロジェクトでの実践知見をもとに本記事では一般化して整理した。実感した本質的な変化は、実装が速くなることそのものではない。プロジェクト全体の時間配分と品質構造が変化することである。要件定義はむしろ長くなる。しかし、後工程の手戻りが減ることで、全体工数は減り、不確実性も小さくなる。
本記事ではこの変化を、フェーズ構成・工数配分・顧客コミュニケーション・差分検証の観点から整理する。
筆者は MBKデジタル SD部所属の井上である。実装比重の低いコンサルタントとして、データ基盤構築・BI 実装・AI 活用支援に従事している。本記事は直近の実プロジェクトでの実感をもとに執筆した。
本記事のスコープ
- spec 駆動導入前後で、フェーズ構成がどう変わるか
- 各フェーズで具体的に何をするか
- データ基盤における spec とは何を指すか
- 直近プロジェクトで何が変わったか
- 残っている課題は何か
2. データ基盤における spec の定義
2-1. spec 駆動開発と spec の中身
spec 駆動開発とは、実装に入る前に「何を満たすべきか」を仕様として明確にし、その仕様を起点に設計・実装・テスト・レビューを進める考え方である。アプリケーション開発の文脈では、画面の振る舞い、API の入出力、エラー時の挙動などを spec として定義する。
データ基盤構築における specを、本記事では次のように定義する。
データ基盤における spec とは、業務、データソース、データセット概要、指標定義、集計ロジック、出力結果、分析の軸を、実装前に構造化した内部表現である。
特に重要なのは、顧客の業務ルールや既存帳票の意味を網羅的に整理し、一つずつ定義を確認することだ。
Excel の計算式、過去から引き継がれたマクロ、帳票の並び順、例外的な除外条件は、長い運用の中で仕様が暗黙知化し、現担当者でも全容を把握しきれていないことが多い。spec はこの曖昧さを上流で見える化する。
2-2. 主な spec セクション
| spec セクション | 定義すること |
|---|---|
| ビジネス要件 | なぜ必要か、誰が使うか、何を判断するか |
| 指標定義 | 何を数えるか、単位、粒度、ディメンション |
| 集計ロジック | 変換・結合・除外・補正のルール、業務ルール |
| データソース / リネージ | 入力 → 中間 → 出力 の経路 |
| 結果の軸 | 行・列の構造、横持ち/縦持ちの方針 |
| Open Questions | 顧客確認が必要な未確定事項 |
| 改訂履歴 | 変更理由と日付 |
2-3. spec 運用上の原則
- 推定と確定を分ける
- 不明点を実装で吸収せず、Open Questions に出す
- 顧客には spec ではなく、質問リストやモックアップを見せる
- 顧客回答や差分検証結果は spec に戻す
2-4. ドキュメント構造の変化
spec 駆動の本質的な利点の一つは、spec がすべての成果物の起点になることだ。
導入前は、要件定義書、DB 設計書、SQL、Dataform、BI 画面定義、モックアップ、データカタログがそれぞれ独立して管理されがちだった。
導入後は、spec を中心に置き、すべての成果物が spec から派生する構造になる。
顧客回答や差分検証結果は spec に戻す。これによって変更管理の中心が spec に寄り、ドキュメント間の整合性を保ちやすくなる。
分析基盤は一度作って終わりではなく、指標定義・データソース・組織の見方が変わり続ける。変更の起点を一箇所に寄せることには大きな意味がある。
3. フェーズ構成: Before / After
3-1. LLM Agent + Spec へのシフト: ワークフローの変化
Agent LLM 活用以前は、SQL の生成などにチャットベースの LLM を活用していたが、「SQL の集計を自発的に行い、特定のテーブルと比較検証を行い、整合性の確認をおこなう」といった複雑な処理をするには不向きだった。
また顧客へのヒアリング結果や既存の Excel ファイルの集計定義の解析結果など多数のドキュメントを統合し、整合性を担保し続けるには人間の工数が多く必要だった。
これを LLM Agent × Spec 駆動の活用に落とし込むことで、解析やドキュメント管理の作業を LLM に移管し、顧客との方針設計に関する議論や要件定義に集中できるようになる
| 活用形態 | 成果物 | 整合性管理 |
|---|---|---|
| 既存の LLM 活用（チャットベース） | 個別スニペット（SQL / 要約 / コード片） | 人間のコピペ統合で担保 |
| LLM Agent + Spec 活用 | spec を中心に統合された成果物群 | spec が担保（変更はすべて spec に戻る） |
この前提のもとで、フェーズ構成は次のように変わる。
3-2. Before: 従来型
| # | フェーズ | 起きやすい問題 |
|---|---|---|
| 1 | 初期ヒアリング | 顧客側も詳細を言語化しきれない |
| 2 | 既存資料の確認 | 暗黙ロジックや例外処理が埋もれている |
| 3 | ざっくり設計 | 指標定義や粒度が曖昧なまま残る |
| 4 | 実装 | 実装中に不明点が増える |
| 5 | 顧客確認 | 「思っていたものと違う」がここで出る |
| 6 | 修正・再実装 | 手戻りが大きくなりやすい |
3-3. After: spec 駆動 × LLM Agent 導入後
LLM Agent には ファイル読み取り・SQL 実行・スクリプト生成などのツール実行と、結果に基づく次手の判断を、自律的にループさせる といった用途で活用。
これにより、人間は「指示 → 確認 → 修正方針提示」のレビュアー役に集中でき、ツール実行や中間生成物の組み立てそのものから解放される。
各フェーズにおける LLM Agent の役割は次の通りである。
| # | フェーズ | LLM Agent の役割 |
|---|---|---|
| 1 | 業務要件の深掘り | 議事録・既存資料を横断走査し、論点を抽出・整理 |
| 2 | spec 化 | Excel・VBA・帳票を自律的に解析し、推定/確定/不明を分けて初稿化 |
| 3 | モックアップ作成 | spec から HTML モック・BI 試作画面を生成、フィードバックで再生成 |
| 4 | モックアップ確認・要件深掘り | 議事から追加論点を抽出、spec への差分反映を提示 |
| 5 | Open Questions 化・spec 更新 | 質問の重複排除、顧客が答えやすい形へ言い換え |
| 6 | 実装生成 | SQL・Dataform・BI・検証スクリプトを連携生成 |
| 7 | 差分検証 | クエリ実行と結果分析を反復し、差分原因の仮説を提示 |
| 8 | 最終調整 | 引き継ぎ資料・運用メモの初稿生成 |
3-4. 何が変わったか
最大のポイントは、モックアップ確認が実装後ではなく、実装生成の前に入ることだ。
先に spec からモックアップを作って顧客に見せ、Open Questions と追加要件を引き出す。そのうえで spec を更新し、確定度が上がった spec から実装を生成する。差分検証は、最終成果物に近い出力ができてから既存帳票と照らして行う。
変化を3点にまとめると:
- 要件定義と spec 化の比重が増える(上流工程は長くなる)
- 実装工程が短くなる(LLM Agent が初期実装を生成、人間はレビューと修正に集中)
- 顧客レビューの一部が、実装前のモックアップ確認に移る(完成後の手戻りを上流で未然に防ぐ)
4. 直近プロジェクトで起きた変化
4-1. 工数配分の再構造化
直近の分析基盤構築プロジェクトでは、実装部分の工数が実感として明確に減った。一方で、要件定義・spec 化・ヒアリング項目の整理には従来より多くの時間を使うようになった。
しかしこの変化は、上流工程が「重くなった」ということではない。従来も同じ作業は発生していたが、それが実装後の手戻りという形で終盤に押し込まれていただけである。
従来の進め方では、要件定義を浅めにして動くものを作り、その後に詳細確認を進めていた。結果として:
- 既存 Excel と数値が合わない
- 差分原因が、SQL の誤りなのか、既存帳票の暗黙ロジックなのかが分からない
- 顧客が完成画面を見て初めて「この粒度では使えない」と気づく
- スコープに入れるべき帳票の判断が後ろ倒しになる
こうした作業はすべて発生する。spec 駆動では、これらを上流で扱う構造に変える。
結果として上流工程で行なう要件定義・アセスメントの時間は伸びる。しかし、そのぶん後工程の手戻りが減り、全体の業務工数と終盤の不確実性は減る。
4-2. 既存帳票解析: 推定と不明を分けて持つ
Before: Excel や VBA を人間が目視で確認する。分からない点は後で顧客に聞くが、実装が進んでから疑問が出るため、回答待ちと手戻りが発生する。
After: Excel・VBA・帳票構造を LLM とスクリプトで先に解析し、明確なロジック・不明確なロジック・推定しているロジックを分けて spec に書く。不明点は Open Questions として一覧化し、顧客ヒアリングに回す。
変化: 「分からないまま実装する」状態が減る。顧客への質問が、思いつきの個別質問ではなく、spec から派生した一覧になる。ヒアリングの質が上がる。
4-3. モックアップによる合意形成: 完成前に「使えるか」を見る
Before: PowerPoint や口頭説明で完成イメージを共有する。本番の BI やダッシュボードができてから使い勝手を確認するため、完成後に「これでは業務に使えない」が発生する。
After: HTML モックアップや簡易 BI 画面を spec から早期に生成する。顧客は spec ではなく、画面や出力イメージを見て判断する。フィードバックを spec に戻してから実装を再生成する。
変化: 顧客との対話が具体的になる。完成後の大幅手戻りを防ぎやすくなる。
5. 顧客コミュニケーションの変化
spec は、開発者と LLM のための内部表現である。顧客にそのまま見せても、レビューは進まない。
一方で、顧客に確認しなければならないことは spec の中に集まっている。そこで、spec を直接読んでもらうのではなく、spec をもとに顧客が判断しやすいアウトプットへ変換する。
| 顧客向けインターフェース | 役割 |
|---|---|
| ヒアリング項目集 | spec の Open Questions を顧客が答えやすい質問に変換 |
| モックアップ | spec から生成した画面・出力イメージを確認するためのもの |
この設計によって:
- 顧客が答えるべきことが明確になる
- 画面や帳票の完成イメージを早期に確認できる
- 顧客レビューが「終盤の検収」から「上流の合意形成」に変わる
副次的な効果として、spec として残った業務ルールは引き継ぎ資料にもなる。これまで担当者の頭の中や Excel に閉じていたルールが構造化されることで、運用側の担当者が変わったときの引き継ぎや、顧客側でブラックボックス化していた業務知識の整理にも寄与する。
6. 差分検証は暗黙ロジックの発掘装置である
既存帳票と新基盤の数値が合わないとき、原因は単純な実装ミスとは限らない。むしろ、差分は業務知識を発見する入口になる。
| 類型 | 内容 | 例 |
|---|---|---|
| 1. 顧客の認識違い | 既存 Excel の式が壊れていた、古い誤りが運用されていた | 過去の改修ミスが残置 |
| 2. 暗黙の例外処理 | 特定コード除外、特定部署だけ別処理が口伝になっていた | 特定取引先の特殊扱い |
| 3. 時期による定義変更 | 過去と現在で定義が変わっているが、資料が更新されていない | 2年前から数え方が変更 |
| 4. 部署間の定義差 | 同じ用語を部署ごとに異なる意味で使っている | 営業の「active」と運用の「active」 |
差分原因をその場限りの修正で終わらせると、同じ問題が別帳票で再発する。spec 駆動では、差分原因を spec に戻す。これによって:
- 同じロジックを別マートでも再利用できる
- 顧客確認済みの業務ルールとして残せる
- 後続の実装生成や検証に反映できる
- 引き継ぎ時に判断の経緯を説明できる
差分検証は、終盤の火消しから、上流の暗黙知発掘に位置づけが変わる。
7. まとめ
分析基盤構築における spec 駆動開発の本質は、プロジェクトの時間配分と品質構造を変えることにある。
従来は要件定義を浅めにして早く実装し、完成物を見せてから詳細を詰める構造だった。そのため暗黙ロジック、数値差分、利用イメージのズレが終盤に発覚し、手戻りが構造的に発生していた。
spec 駆動では、LLM によって短縮された実装工数を、要件定義・spec 化・差分検証・モックアップ確認に再配分する。要件定義はむしろ長くなる。しかし、後工程の手戻りが減ることで、全体工数と終盤の不確実性は減る。
さらに、spec として残った業務ルールは再利用できる。指標定義の経緯、暗黙ロジックの発掘結果、顧客との合意プロセスが構造化された資産として残ることは、開発側だけでなく顧客側の業務引き継ぎにも効いてくる。
LLM 時代のデータエンジニアリングでは、SQL を速く書くこと以上に、業務の暗黙知を spec として構造化し、顧客が判断できる形に翻訳する力が重要になる。