🎯 AI 駆動開発の前に知っておくべきこと
AI コーディングツール（Claude Code 等）は強力ですが、 開発の基礎が曖昧なまま使うと、品質の低いコードを高速に量産するだけ になります。
AI に的確な指示を出し、生成されたコードの良し悪しを判断するには、開発者自身がソフトウェア設計の原則を理解している必要があります。
本シリーズは、AI 駆動開発の精度を高めるための 予備知識 として、以下のテーマを体系的に解説します。
🧲 すべての設計原則は「疎結合」と「テスト容易性」のためにある
設計原則・パターン・アーキテクチャは、見た目の語彙はバラバラでも、突き詰めると 同じ目的 を共有しています。
モジュール同士を疎結合に保ち、テストを書きやすい状態を維持すること。
これが守られている設計では、 AI が生成したコードを安心して受け取れる 。守られていない設計では、AI の出力を信じる根拠そのものがなくなります。設計原則は「美しさ」のためではなく、 AI 駆動開発で量産されるコードを成立させるためのインフラ だと捉えるのが本シリーズの立場です。
確信的な原則スローガン
各原則を 「やってはいけないこと」と「やるべきこと」 で言い切ると、AI への指示にもレビューにも使える共通語になります。曖昧に運用すると AI 生成コードに侵食されます。
| 原則 | スローガン |
|---|---|
| SRP（単一責任） | 1 つのクラスに、変更理由は 1 つだけ |
| OCP（開放閉鎖） | 改修するな、拡張せよ |
| LSP（リスコフ置換） | 親と入れ替えても破綻させるな |
| ISP（インターフェース分離） | 使わないメソッドに依存させるな |
| DIP（依存性逆転） | 上位は下位を知らない。抽象が境界を切る |
| DRY | 同じ知識を二箇所に書くな |
| SoC | 関心の違うものを混ぜるな |
| TDD | テストが書けない設計は壊れている |
| DDD | 業務の言葉でコードを書け |
| CQRS | 書き込みと読み取りを混ぜるな |
| イベントソーシング | 事実を上書きするな、追記せよ |
| ヘキサゴナル / クリーン | コアにフレームワークを混ぜるな |
| アトミックデザイン | 下位は上位を知らない。依存方向は一方向 |
| モノレポ | 共通化しすぎるな。境界を lint で強制せよ |
特に OCP の「改修するな、拡張せよ」 は、AI 駆動開発で if/switch 文が肥大化する典型的な失敗を防ぐ最重要スローガンです。「動くから良い」で既存コードに分岐を足し続けると、AI も人間もレビュー不能なコードに育ちます。
疎結合がもたらす 4 つの果実
設計原則を守ると、AI 駆動開発で次の 4 つが手に入ります。逆に守られていないと、AI を導入するほど被害が大きくなります。
| 果実 | なぜそうなるか |
|---|---|
| テストが書ける | 依存をモック・スタブ・インメモリ実装に差し替え可能。単体テストが数 ms で回る |
| AI 生成コードを信頼できる | テストで即座に Red/Green を判定できる。 Kent Beck が「TDD は AI エージェントの superpower」と語る根拠 |
| 影響範囲が予測できる | 依存方向が一方向に固定される。AI の変更がどこまで波及するかをレビュー前に見積もれる |
| 新メンバーがオンボードできる | 局所的に読めば全体が分かる。AI 支援によるオンボーディングも加速 |
疎結合が崩れた瞬間に起きること
| 崩れた状態 | 起きる事態 |
|---|---|
| God Class（責務の混在） | AI が変更すると無関係な機能が壊れる |
| 依存方向の逆流（インフラがドメインを汚染） | AI が ORM を意識せずドメインに侵食 |
| 巨大インターフェース | AI がモック作成に失敗、テストを書かなくなる |
| Read Model なしの直接 SELECT | 画面要件が AI 経由でドメインに流れ込む |
AI は 「動く」と判断したコードを高速に提案 します。設計原則を持たないチームは、その提案を「動くから OK」で受け取り、気づいたときには疎結合が完全に失われています。
🧱 各テーマの位置づけ
オブジェクト指向
└→ なぜ階層（プロジェクト）を分けるのか
ドメイン層 / アプリケーション層 / インフラストラクチャー層 / インターフェース層
SOLID 原則
└→ オブジェクト指向設計を保守可能に保つ 5 原則
SRP / OCP / LSP / ISP / DIP
DDD（ドメイン駆動設計）
└→ ビジネスの言葉でコードを書く設計手法
Bounded Context / ユビキタス言語 / 集約
TDD（テスト駆動開発）
└→ テストを先に書くことで設計を磨く
Canon TDD / テスト網羅性
テスト技法
└→ 何をどうテストするか — レベル × 技法の体系
単体 / 結合 / E2E / UAT / 限界値分析 / 同値分割 / カバレッジ
CQRS（コマンド・クエリ責務分離）
└→ 書き込みと読み取りを別モデルにする
Command / Query / Read Model
イベントソーシング
└→ 状態ではなくイベント列を真実とする永続化
Event Store / Projection / Snapshot
CES アプローチ
└→ CQRS + イベントソーシング + Saga の統合
長期トランザクション / 補償トランザクション
アトミックデザイン
└→ UI コンポーネントの分類・再利用戦略
Atoms / Molecules / Organisms / Design Tokens
モノレポ
└→ 複数サービスを 1 リポジトリで管理する運用戦略
Nx / Turborepo / pnpm workspaces📐 なぜこの順番なのか
| 順番 | テーマ | 理由 |
|---|---|---|
| 1 | オブジェクト指向 | すべての設計原則の土台。階層分離の考え方がないと SOLID も DDD も理解できない |
| 2 | SOLID 原則 | オブジェクト指向を保守可能にする 5 原則。AI 生成コードのレビュー観点として機能する |
| 3 | DDD | ビジネスロジックの設計手法。AI に「何を作るか」を正確に伝える力 |
| 4 | TDD | 設計の品質を検証する手法。「いつテストを書くか」 |
| 5 | テスト技法 | 「何をどうテストするか」の体系。単体・結合・E2E・UAT、限界値分析・同値分割 |
| 6 | CQRS | 書き込みと読み取りを分離する設計。AI に複雑クエリを任せてもドメインが汚染されない |
| 7 | イベントソーシング | 状態ではなくイベント列を残す永続化。バグ再現・What-if 分析を AI に任せられる |
| 8 | CES アプローチ | CQRS + ES + Saga の統合。長期トランザクションを AI に組み立てさせる土台 |
| 9 | アトミックデザイン | UI の設計原則。フロントエンド開発で AI との協働を効率化する |
| 10 | モノレポ | 複数サービスを扱う運用戦略。AI に渡すコンテキストの範囲を構造で設計する |
下から始めると、なぜそうするのかが分からないまま手法だけを覚えることになります。 上から順に積み上げる ことで、各手法の必然性が理解できます。CQRS・イベントソーシング・CES の 3 つは応用領域なので、 業務要件で必要になってから着手 しても遅くありません。
🤖 AI 駆動開発との関係
これらの知識があると、AI との協働で以下が変わります。
| 知識 | AI への指示 | 結果 |
|---|---|---|
| オブジェクト指向がわかる | 「ドメイン層とインフラストラクチャー層を分離して」と指示できる | 保守しやすいコード |
| SOLID 原則がわかる | 「OCP に従って if 分岐ではなく Strategy で」と指示できる | 拡張に強いコード |
| DDD がわかる | 「ユビキタス言語に合わせて」と指示できる | ビジネスと一致したコード |
| TDD がわかる | 「テストを先に書いて」と指示できる | 仕様通りのコード |
| テスト技法がわかる | 「限界値分析と同値分割で網羅して」と指示できる | 境界バグが残らない |
| CQRS がわかる | 「Command と Query を別モデルで」と指示できる | 画面要件でドメインが汚染されない |
| イベントソーシングがわかる | 「過去のイベント列を再生してバグを再現して」と指示できる | デバッグと What-if 分析が容易 |
| CES アプローチがわかる | 「Saga として補償も含めて設計して」と指示できる | 長期トランザクションが安全 |
| アトミックデザインがわかる | 「Atom / Molecule で分けて」と指示できる | 再利用可能な UI |
| モノレポがわかる | 共有ライブラリの変更影響を把握できる | 安全なリファクタリング |
AI は道具であり、使い手の設計力がそのまま成果物の品質に反映されます。
📚 シリーズ記事
| # | タイトル | 内容 |
|---|---|---|
| 1 | 概要 （本記事） | シリーズの全体像と各テーマの位置づけ |
| 2 | オブジェクト指向編 | 階層分離（ドメイン / アプリケーション / インフラストラクチャー / インターフェース） |
| 3 | SOLID 原則編 | 5 原則の使い所・典型違反パターンと是正方針 |
| 4 | DDD 編 | Bounded Context・ユビキタス言語・集約設計 |
| 5 | TDD 編 | テスト駆動開発の実践・テスト網羅性・Canon TDD |
| 6 | テスト技法編 | 単体・結合・E2E・UAT のレベル別戦略、限界値分析・同値分割・カバレッジ |
| 7 | CQRS 編 | コマンド・クエリ責務分離と Read Model 設計 |
| 8 | イベントソーシング編 | 状態ではなくイベント列を真実とする永続化・イベント DB（Event Store）の選定 |
| 9 | CES アプローチ編 | CQRS + Event Sourcing + Saga による長期トランザクション設計 |
| 10 | アトミックデザイン編 | UI コンポーネントの分類と設計・Design Tokens との統合 |
| 11 | モノレポ編 | 単一リポジトリでの複数サービス管理・Nx / Turborepo / pnpm workspaces |
📖 関連用語
- オブジェクト指向 — すべての設計原則の出発点となるパラダイム
- SOLID 原則 — オブジェクト指向設計を保守可能に保つ 5 原則
- DDD — 業務ドメインをそのままコードに反映させる設計手法
- ビジネスケイパビリティ — 業務側の「何ができるか」を表す能力単位。DDD の Bounded Context と対応
- 集約 — DDD のトランザクション境界の単位
- RDD（責務駆動設計） — 責務を起点にクラスを切り出す設計手法
- リポジトリパターン — ドメイン層を永続化詳細から切り離す DIP の代表例
- DAO — データアクセス層を分離する類似パターン
- ヘキサゴナルアーキテクチャ — ポートとアダプタで入出力技術を差し替え可能に保つ設計
- クリーンアーキテクチャ — 依存方向ルールを明文化した同型整理
- オニオンアーキテクチャ — 同心円でドメインを中心に置く同型整理
- CQRS — 書き込みと読み取りをモデルレベルで分離するパターン
- イベントソーシング — イベント列を真実として状態を再構築する永続化
- Saga パターン — 集約・サービスを跨ぐ長期トランザクション
- CES アプローチ — CQRS + Event Sourcing + Saga による分散トランザクション設計
- アクセシビリティ — Web の必須要件。色覚多様性・スクリーンリーダー対応など
- オブザーバビリティ — AI 生成コードの本番運用を支える監視基盤
- SoC（関心の分離） — 階層分離の上位原則
- DRY — 知識の重複を排除する基本原則