はじめに
私はデータ基盤の運用保守に携わっており、主にバッチ処理まわりの保守や追加開発を担っています。
最近、AIエージェントが話題ですね。AIにどこまで仕事を任すことができ、人がどのようにかかわっていく未来になるのかを知るためにClaude の Pro プランを使い始めました。この2週間で、日々その実力に驚かされており、このブログのリサーチや示唆出しも、Claudeに手伝ってもらっています。
そんな中、データエンジニアとして「どこまで・どう活用できるのか」を考えてみたくなり、データ基盤を要件定義からリリース・運用まで、AIと一緒に作るという前提で全体像を整理してみます。
結論（この記事で言いたいこと）：自然言語からのコード生成も、ガバナンス機能も、いまはクラウドベンダーや AI がどんどん「飲み込んで」います。そんな中で人に残り続けるのは、特定の基盤に依存しない要件定義プロセスだと考えました。本記事は、それを起点に要件→設計→実装→テスト→運用まで貫く「全体設計図」を1枚で示す回です。
この分野はまだ発展途上で、半年後にはツールも常識も変わっているはずです。本記事は「正解」ではなく、いま私が考えている現時点の設計図として読んでください。
また、2026年6月に「ループエンジニアリング」というキーワードが話題になりました。私は学生時代に制御工学を学んでいたので、フィードバック制御に似ているなと感じました。その視点も少しだけ添えています。
なぜ「要件定義」なのか
「AIでデータ基盤を作る」こと自体は、もう特別ではないようです。
-
実装はベンダー／AIが飲み込みつつある。 自然言語で意図を伝えると本番の ETL を生成してくれる機能が、各データ基盤に組み込まれてきました。「どう作るか」は急速にコモディティ化しています。
-
ガバナンスもプラットフォームに内製化されつつある。 エージェントごとの権限管理・監査や、外部ツール接続の仕組みも、基盤側に取り込まれてきています。
-
それでも、プロジェクトは失敗している。 2025年、ガートナーは「エージェンティックAIプロジェクトの40%超が2027年末までに中止される」と予測しています（理由はコスト増・ビジネス価値の不明確さ・リスク統制の不備）。加えて業界では「エージェンティックな企業の土台はデータ基盤だ」という指摘も強まっています。
つまり、コモディティ化しないのは「何を・誰のために・どんな価値で・どんな統制で作るか」という要件定義の部分です。そしてそれは要件定義フェーズで終わらず、設計・実装・運用まで一貫して効き続けます（要件が曖昧なまま進めると、運用で破綻します）。
これは「ツールが不要」という話ではありません。むしろツールは積極的に使います。ただ、勝負どころは要件定義であって、ツール選びではないのではないか、という整理です。
全体設計図：フェーズ × 4つの関心事
私が考えた全体像は、開発フェーズ（要件定義→設計→タスク→実装→テスト→運用） を縦軸に、4つの関心事を横軸に置いたマトリクスです。
4つの関心事は、優先度の高い順に次の4つです。
| 関心事 | 意味 | 性格 |
|---|---|---|
| ① 価値 / Value | 誰の何の課題を、どんな成果（outcome）で解くか | 🔵 基盤非依存（持ち運べる） |
| ② ガバナンス / Governance | 所有者・定義・品質・来歴などの統制 | 🔵 基盤非依存（持ち運べる） |
| ③ 実行 / Execution | AIエージェントが実際に手を動かす仕組み | 🟣 交換可能 |
| ④ 方法論 / Methodology | どんな規律（手順）で進めるか | 🟣 交換可能 |
ポイントは、①②と要件定義は「持ち運べる（基盤非依存）」、③④は「交換可能」 だということです。
- 持ち運べる（Portable）：価値とガバナンスは、使う基盤やツールを変えても変わりません。どのクラウドでも「誰のための、どんな価値か」「誰がデータを持ち、どう品質を担保するか」は同じように成り立ちます。
- 交換可能（Replaceable）：実行（どのAIエージェントを使うか）と方法論（どの開発手法を使うか）は、いつでも差し替えられる「一例」にすぎません。本連載では実行に Claude Code、方法論に後述の cc-sdd を使いますが、それはあくまで私の一例です。
承認ゲートと「手戻り」
各フェーズの境目には、人が成果物を確認して次へ進む承認ゲートを置きます。要件定義・設計・タスク・テスト（リリース判定）の後など、節目で人が確認する設計です。
そして、後のフェーズでつまずいたら前のフェーズへ戻る（手戻り）。たとえば設計で無理が見つかったら、要件定義に戻って合意し直す。この「進んで・確認して・必要なら戻る」のループこそが、全体を動かすエンジンになります。
![データ基盤づくりの全体設計図：開発フェーズ × 4つの関心事。各フェーズの境目に承認ゲートを置き、つまずいたら前のフェーズへ戻る（手戻りループ）。]
ちょっとだけ制御の話（詳細は別記事で）
制御工学とは、ざっくり言うと「目標に近づくように、測定値を見ながら自動で調整し続ける仕組み」を扱う分野です。身近な例だとエアコンが分かりやすく、設定温度（目標）と室温（測定値）の差を見て、運転を強めたり弱めたりします。この「目標と測定値の差を見て入力を直し続ける」やり方をフィードバック制御と呼びます。
そして「進む→測る→ずれていたら戻る」というプロセスの構造は、このフィードバック制御とよく似ています。目標値（仕様）と出力（成果物）の差（テストの不合格など）を見て、次の一手を決める——閉じたループ（閉ループ）です。
冒頭で触れたループエンジニアリング（人が都度プロンプトを打つのではなく、エージェントを自律で回す「ループ」自体を設計する考え方）も、この延長線上にあるように捉えています。
制御工学では、「では、そのループは必ず目標に到達すると保証できるのか？」——という論点があり、数学の問題に落とし込むプロセスがあります。データ基盤構築の目標は、運用し価値を生み出すことが目標ですね。
制御工学の視点で踏み込むと面白いのですが、長くなるので別記事で詳しく書きます。ここでは「ループは制御に似ている」とだけ押さえておきます。
土台に選んだ cc-sdd と、ツールの位置づけ
方法論（④）には、仕様駆動開発（SDD：Spec-Driven Development） を採り、その実装として国産 OSS の cc-sdd を土台にします。要件定義→設計→タスク→実装を段階的に文書化し、承認ゲートを挟みながら進められるのが選定理由です。
ただし、SDD ツールは cc-sdd だけではありません。海外では GitHub Spec Kit や BMAD などが広く使われていて、それぞれ得意・不得意があります。ツールは主役ではないので、選び方は別途まとめます。cc-sdd 自身にも「設計が長くなると文脈が劣化しやすい」「既存のプロジェクト設定ファイルと共存させにくい」といった弱点があり、そこは運用で工夫します。
通し例：製造業の設備データ基盤（次回から）
第2回以降は、ひとつの題材を例に、AI駆動のデータ基盤構築プロセスをより深く考えていきます。私が選んだのは 製造業の設備データ基盤 です（製造業は国内のIT投資が最も大きい領域でもあります）。
具体的には、製造設備のデータを集めて「設備の停止を予知する」「設備総合効率（OEE） を改善する」ことをゴールにしたデータ基盤を想定します。OEE は ISO 22400 で定義される製造KPIで、可用性 × 性能 × 品質で表されます。「ダッシュボードを何枚作ったか」ではなく「OEEがどれだけ良くなったか」という**成果（outcome）**で価値を測る、という①の考え方を具体化するのにちょうどよい題材です。
題材は一般化した例です。特定企業や案件固有の情報には踏み込みません。
まとめ・次回予告
- AIとベンダーが「実装」と「統制」を飲み込む時代に、人に残るのは特定基盤に依存しない要件定義。
- それを起点に、フェーズ × 4つの関心事（価値・ガバナンス・実行・方法論） で要件→運用まで貫く。①②は持ち運べる、③④は交換可能。
- 承認ゲートと手戻りのループで全体を回す。土台は cc-sdd（あくまで一例）。
- ただしこの分野は発展途上。これは現時点の設計図です。
次回（第2回）は、いちばんの肝である「特定基盤に依存しない要件定義」を、具体的なヒアリング項目に落とし込み、AIが実行するタスクにどのように橋渡しできるのか。について考えていきます。