🚀 要件定義が終わると、開発が終わっている
従来の開発では、要件定義→設計→実装→テストに数ヶ月かかるのが当たり前でした。
AI コーディングツール（Claude Code 等）を正しく活用すると、この常識が変わります。要件と設計をドキュメントに落とし込んだ時点で、 AI が実装の大部分を完了させる ことが現実になっています。
つまり「何を作るか」を明確にする作業 = 開発そのものになる。ステアリング駆動開発は、この「AI に何をどう伝えるか」を体系化した手法です。
💡 これは机上論ではありません。本番のマルチクラウド IaC を、この手法で「全管理」しています。
CTS では、GCP + AWS のマルチクラウド・マルチクライアント Terraform 基盤の開発から運用までを、丸ごとステアリング駆動開発で回しています。tf コードの生成・ローカルでの
plan確認・git push・MR 作成までを Claude Code が一貫運用し、本番 apply だけ人間が承認。新規クライアントの追加は、AI が既存規約を手本に tf 一式を生成し、CI は動的 child pipeline で不変——「ディレクトリを 1 つ足す」作業に近づいています。アプリ開発だけでなく インフラ（IaC）の本番運用そのものが、この手法の射程です。実例は Terraform IaC 実践ガイド を参照。
🏗️ AI 駆動開発におけるステアリングの位置づけ
AI 駆動開発は、AI にコードを書かせるだけでは成立しません。以下の 3 層で成り立っています。
ステアリング駆動開発は最上位層 です。どんなに優秀な AI ツールでも、「何を作るか」が曖昧なら正しいコードは生まれません。逆に、ステアリングで要件と設計が明確になれば、AI は驚くほど正確にコードを生成します。
🧱 LAYER 2: 開発手法（予備知識） — 「どう作るか」の設計原則
AI に正しく指示し、生成されたコードの品質を判断するには、開発者自身が 設計原則を理解している 必要があります。LAYER 2 の各テーマは 開発手法ガイド：概要 を起点とした 全 10 本のシリーズ で詳しく解説しています。
| # | 手法 | 一言で |
|---|---|---|
| 2 | オブジェクト指向編 | AI に階層分離を指示するための土台 |
| 3 | SOLID 原則編 | AI 生成コードをレビューするチェックリスト |
| 4 | DDD 編 | AI に「何を作るか」を正確に伝える力 |
| 5 | TDD 編 | Kent Beck が「AI エージェントの superpower」と呼ぶ手法 |
| 6 | CQRS 編 | AI に複雑クエリを任せても壊れない設計 |
| 7 | イベントソーシング編 | AI にバグ再現と What-if 分析を任せる |
| 8 | CES アプローチ編 | AI に長期トランザクションを任せる |
| 9 | アトミックデザイン編 | AI に粒度を指定して UI を量産する |
| 10 | モノレポ編 | AI に渡すコンテキスト範囲を構造で設計 |
ステアリング駆動開発（LAYER 1）はこれらの設計原則の上に立っているため、 LAYER 2 の知識が薄いままステアリングを書くと、AI が生成するコードの品質判断ができない 状態になります。本シリーズに入る前に、LAYER 2 を一巡しておくことを推奨します。
⚠️ バイブコーディングの限界
「AI に雰囲気で指示を出して、出てきたコードをそのまま使う」— いわゆるバイブコーディングには限界があります。
- コンテキストが揮発する（セッションをまたぐと忘れる）
- 品質が不安定（同じ指示でも結果がブレる）
- 大規模プロジェクトでスケールしない
小さな修正ならこれでも動きます。しかしプロジェクトが大きくなるほど、「何を作るか」の定義が曖昧なまま進めるリスクは大きくなります。
ステアリング駆動開発は、 作業の規模に応じてドキュメントの量を変える ことで、この問題を解決します。バグ修正に 8 ファイルの仕様書は不要ですが、新ドメイン追加には必要です。規模判定によって、過不足のない準備を行います。
🔄 ステアリング駆動開発の統一フロー
すべての作業は以下のフローに従います。
壁打ち → 規模判定 → オーナー承認 → ステアリング作成 → レビュー → 実装 → 完了壁打ちフェーズ
実装前に背景・目的・スコープを整理します。 壁打ちのスキップは禁止 です。
- なぜこの作業が必要か？
- 何を達成したいか？成功の定義は？
- スコープ（含むもの / 含まないもの）
- リスク・懸念
壁打ちの結果は ADR（Architecture Decision Record）として永続ドキュメントに保存します。
🔑 壁打ちは「基本中の基本」であり、バグを減らす最大の近道です。
承認ゲートやレビューは最後の確認にすぎません。品質は、その手前の ① 徹底したステアリングファイルの作成と、② 開発進行中の AI との適切な壁打ちで作り込まれます。実装が始まってからも、迷ったら手を止めて壁打ちする——この往復が、手戻りと不具合を最も効率よく減らします。
「速く作る」ために壁打ちを省くのは逆効果です。曖昧なまま AI に書かせたコードを直す時間 > 壁打ちで仕様を固める時間。壁打ちへの投資が、結果的に最短経路になります。本番のインフラ（IaC）運用で「本番 apply だけ人間承認」が成立するのも、その手前の壁打ちとステアリングで設計が固まっているからです。
規模判定（S / M / L）
| 規模 | 条件 | ステアリング | 作成ファイル数 |
|---|---|---|---|
| S | バグ修正、軽微な変更 | 不要 | 0 |
| M | 単機能追加、リファクタ | 必須 | 4 |
| L | 複数機能、アーキテクチャ変更、新規ドメイン | 必須 | 8 |
「全タスクにステアリングを適用する」罠を避けることが重要です。 S 規模にステアリングは不要です。
L 規模のシグナル
以下のいずれかに該当すれば L 規模：
- 複数の Bounded Context にまたがる
- 新しいエンティティ・集約を導入する
- 既存アーキテクチャの変更を伴う
- 新しい用語（ユビキタス言語）を導入する
📄 2 層のドキュメント設計
ステアリング駆動開発では、ドキュメントを 2 層に分離します。
永続ドキュメント（docs/）= 北極星
プロジェクトの方向性を定義するドキュメント。ステアリング完了後も残り続けます。
- アーキテクチャ設計書
- API 仕様
- ドメインモデル
- ADR（Architecture Decision Record）
ADR とは、「なぜその技術的判断をしたのか」を記録するドキュメントです。壁打ちフェーズの議論や設計判断を ADR として残すことで、後から「なぜこうなっているのか」を誰でも追跡できます。
作業ドキュメント（.steering/）= 今回の航路
タスクごとに作成し、完了後はアーカイブに移動します。
M 規模（4 ファイル）:
| ファイル | 内容 |
|---|---|
| requirements.md | 詳細要求・受入テストシナリオ |
| design.md | コンポーネント設計・データフロー |
| tasklist.md | TDD 必須のタスクリスト |
| decision.md | 設計判断記録（ADR 形式） |
L 規模（8 ファイル）:
上記 4 ファイルに加えて：
| ファイル | 内容 |
|---|---|
| architecture.md | 技術仕様書 |
| repository-structure.md | リポジトリ構造定義 |
| development-guidelines.md | 開発ガイドライン |
| glossary.md | ユビキタス言語の用語集 |
✅ 3 つの承認ゲート
ステアリング駆動開発では、 人間が 3 回承認する ことで品質を担保します。
1. 壁打ち後の規模判定承認
↓
2. ステアリング作成後のドキュメントレビュー承認
↓
3. 実装完了後の受入テスト承認AI が自動で進めるのではなく、各段階でオーナーが判断します。これが「Humans on the Loop」です。
🗺️ 業界用語との対応
| 業界用語 | ステアリング駆動開発での対応 |
|---|---|
| SDD (Spec-Driven Dev) | .steering/ ワークフロー |
| Context Engineering | skills + path scoping + prepare-context |
| Harness Engineering | pre-push + サブエージェント + hooks |
| Humans on the Loop | 3 つの承認ゲート |
🔧 ステアリングのワークフロー
以下の図は、ステアリング駆動開発の全体フローを示しています。
📚 シリーズ記事
| # | タイトル | 内容 |
|---|---|---|
| 1 | 概要 （本記事） | ステアリング駆動開発の全体像 |
| 2 | 壁打ち・規模判定編 | 壁打ちの進め方、ADR の書き方、規模判定の基準 |
| 3 | ステアリング作成編 | M/L 規模のドキュメント作成、TDD タスク分解 |
| 4 | 実装・完了編 | TodoWrite 連携、進捗管理、アーカイブ運用 |
| 5 | コンテキスト設計編 | AI に渡すコンテキストの最適化、skills 設計 |
| 6 | 品質ゲート編 | doc-reviewer、テスト品質チェック、受入テスト |
| 7 | Claude Code ベストプラクティス | CLAUDE.md 設計、hooks、commands、rules、skills |
| 8 | Agent Teams 編 | agents 定義、チーム構成、マルチエージェント協調 |
| 9 | Remote Control 編 | スマホ・Web から CLI セッションを操る席拘束からの解放 |
🔗 関連記事
- 開発手法ガイド：概要 — LAYER 2「予備知識」の体系。AI に正しく指示するための設計原則シリーズ（全 10 本）
- 開発手法ガイド：DDD 編 — ステアリングで使う「ユビキタス言語・Bounded Context・集約」の前提知識
- 開発手法ガイド：TDD 編 —
tasklist.mdで TDD タスク分解を行う前提知識 - CTS-EC 共通商品マスタ — ステアリング駆動開発で構築した AI マルチモール商品管理の実例
- Terraform IaC 実践ガイド：概要 — 本手法でマルチクラウド IaC の開発・運用を全管理している実例（インフラ編）
📖 関連用語
- ADR — ステアリング駆動開発の 2 段構成で使う設計判断記録
- ハルシネーション — 壁打ちでスコープを明確にすることで抑制する失敗モード
- コンテキストエンジニアリング — ステアリング駆動開発の上位概念
- MVP — スコープ判断に通じる「最小限」の考え方