目次

• はじめに

第1章　AI駆動開発の現状と課題

1.1　AIが当たり前になった開発現場

1.2　バイブコーディングの代償

• 本番で起きた事故
• 動くが、誰も理解していないコード
• 書く時間が減り、確かめる時間が増えた

1.3　なぜ失敗は必然なのか LLMの2つの癖

• 同じ指示でも、出力は毎回違う
• 目の前のタスクにしか最適化しない
• 認識されない負債は、返済されずに増える

1.4　なぜ渦中で気づけないのか

1.5　どこまで通用し、どこから崩れるか

1.6　感覚から工学へ

第2章　AI駆動開発のフレームワーク

2.1　開発をY = F(X)という式で捉える

• X（インプット）とは
• F（LLM）とは
• Y（アウトプット）とは

2.2　Yは次のXになる 好循環と悪循環

• 実装完了確率のシミュレーション

2.3　好循環と悪循環の具体例 あるファイル共有サービスの2つの結末

• 結末1（悪循環）
• 結末2（好循環）

2.4　どこから制御するか X→Y→Fの優先順位

2.5　本書の地図

第3章　インプット制御のためのコンテキストエンジニアリング

3.1　AIの挙動はすべてXで決まる

• 与えられた情報がすべて
• プロンプトからコンテキストへ
• 何を読みに行くかも、Xが決める
• 情報量より情報効率
• コンテキストエンジニアリングの定義

3.2　コンテキストの7要素

3.3　コンテキスト品質の3原則

• 鮮度の原則
• 必要十分性の原則
• 一貫性の原則

3.4　3原則を守る対策 実行前・実行時・実行後

• 実行前の対策
  • ルールを整える
  • コードベースを整える
  • ドキュメントを整える
  • スキルを整える
  • 外部情報の接続を整える
  • 対話履歴を整える
• 実行時の対策
  • プロンプトを書く
  • サブエージェントで分割する
• 実行後の対策
  • リファクタリングで衛生を保つ

3.5　まとめ

第4章　アウトプット制御のためのテスト駆動開発

4.1　速度と品質は両立しない AI駆動開発のトレードオフ

• 出力が揺れる以上、判定は省略できない
• 人間が判定すると、速度が頭打ちになる
• 判定を省くと、品質が崩れる
• 速度か品質かというトレードオフ

4.2　テストという「正解の定義」

• テストコードとは何か
• 機械は速く、何度でも、ぶれずに判定する

4.3　速度の解決 テストがAIを自走させる

• 「頑張りました」から「テストが通りました」へ
• AIが自律する3つの条件
• 人間の仕事は「定義」と「検収」に変わる
• AIの守備範囲が20%から100%へ広がる
• 業界の実践例

4.4　品質の解決 テストが最後の検証点になる

• 人間の目はもう全コードを追えない
• テストが品質保証の本体になる
• ここが緩めば、止めるものは何もない

4.5　従来のTDDと、本書が変えること

• 従来のTDD
• 本書が変えること

4.6　何を・どう・いつテストするか

• 何をテストするか
• E2Eテストの役割
• 単体・結合テストの役割
• いつテストを書くか

4.7　AIが生む「悪いテスト」からゴール判定を守る

• AIはテストを「通すこと」に最適化する
• WHATは人間、HOWはAI
• テスト品質を担保する仕組み

4.8　テストで守れる範囲、守れない範囲

4.9　テストがAIの参照するコンテキストになる

4.10　まとめ

第5章　確率制御のためのLLMオーケストレーション

5.1　編成は単体最強を上回る FusionとFugu

5.2　前提1: LLMはなぜ揺れるのか 生成モデルの仕組み

5.3　前提2: モデルには得意不得意がある

5.4　前提3: 賢さは買える。ただし高い

5.5　実装完了確率 揺れを数字で扱う

5.6　実装完了確率を最小のコストでどう上げるか

5.7　並列実行 確率を「数」で買う

• 直列と並列 方向が真逆の2つの式
• 並列のコストと人間の時間
• 並列実行の2つの型 「保険」から「多様性の活用」へ
• テストが並列を成立させる

5.8　タスク割り当て 確率を「適材」で買う

• どこまで投資するか 2つの通貨
• 公式が裏づける分業の2つの型
• タスクごとにサブエージェントを最適化する

5.9　モデルをどう選ぶか 2つの問いで決める

5.10　オーケストレーションはY = F(X)の好循環を回す

5.11　まとめ

第6章　最適化を壊さないAIによる相互レビュー

6.1　AIによる相互レビューとは

6.2　なぜテストだけでは足りないか

• 1つ目の根: 単一ゴール最適化
• 2つ目の根: テストは点でしかない
• 3つ目の根: 自己レビューの限界
• 3つの根を合わせる

6.3　相互レビューはX・Y・Fの3軸を守る

• Xを守るレビュー
• Yへのフィードバックの質を上げるレビュー
• Fのオーケストレーションに関所を置くレビュー
• 3軸は同時に回る

6.4　レビューを実践に落とし込む

• 観点を言語化する
• 優先度を3段階で定義する
• テストコードそのものをレビューする
• フィードバック振動を止める
• 人間レビューとの境界を引く

6.5　相互レビューの3つの場面

• 場面1: プルリクエストのレビュー
• 場面2: 設計ドキュメントのレビュー
• 場面3: セキュリティレビュー専門エージェント

6.6　まとめ

第7章　AI駆動開発を成立させる実践フロー

7.1　再現性を生むリポジトリ設計

• すべての前にGit 確率的なFの安全網
• エージェント向けREADME（AGENTS.md / CLAUDE.md）
• コードのファイル構造
• クリーンアーキテクチャの議論
• ルールファイル
• スキル
• 要件定義ファイル
• 外部情報の接続
• エラーをAIが読める形にしておく

7.2　テストコードの実装

• テストを走らせる土台
• 並列実行に耐えるテストデータ
• 無効なテストをルールとレビューで弾く

7.3　オーケストレーションの実装パターン

• ローカル並列（Git Worktree）
• クラウド並列（タスクを投げてPRで受け取る）
• ローカルとクラウドの使い分け
• タスク割り当ての道具 サブエージェント
• 観点別レビューの編成を組む
• 別系統のAIに聞く Claude CodeからCodexへ

7.4　開発フローの8ステップ

• 前の介入点となるプランドキュメント
• 8ステップの全体像
  • Step 1: プランドキュメントの作成
  • Step 2: プランのAI相互レビュー 仕様・設計・実装
  • Step 3: プランのAI相互レビュー テストの網羅性
  • Step 4: 実装
  • Step 5: テストの実装と全通過の確認
  • Step 6: 実装のAI相互レビュー
  • Step 7: 人間のレビュー
  • Step 8: テスト駆動リファクタリング
• 後の介入点となるテスト駆動リファクタリング

7.5　現場で起きたこと 筆者の実体験

• 体験1: Xを本番の運用基盤まで広げたら、障害が減った
• 体験2: テストの網羅をAIに任せて、後悔した
• 体験3: AIが書いたテストに騙された
• 体験4: レビューのしすぎは、かえって毒になる
• 体験5: リファクタリングを後回しにして、無限ループに捕まった
• 実体験からの教訓

7.6　まとめ

第8章　AI駆動開発を組織へ展開するために

8.1　個人から組織へ 何が崩れるか

8.2　ガバナンスの3段階 開発・リリース・運用

• 開発段階のガバナンス 式の中を統制する
  • 組織で統制するXのルール
  • 組織で使い回すXのハーネス環境
  • 見せるX・見せないX IaCとデータベース
  • Yを統制する3層レビュー体制
• リリース段階のガバナンス 出し方で影響を絞る
  • フィーチャーフラグ 機能単位のON/OFFスイッチ
  • カナリアリリース 一部のユーザーから段階的に広げる
  • 漏洩はロールバックで巻き戻せない
• 運用段階のガバナンス 出したあとを見張る
  • SLI/SLOと可観測性
  • LLMによる異常検知 LLM-as-a-Judgeの運用版

8.3　段階的導入

• 導入は組織変革である 心理的抵抗という現実
• AI Enablementチームによる伴走
• 成功事例をテンプレート化して広げる

8.4　経営層と現場を動かす

• 組織はトップダウンで動く ボトムアップの限界
• アッパーマネジメントを味方にする
• 経営層は投資対効果で動かす
• 原動力はリーダーの意志 KPIはサポート指標にすぎない

8.5　まとめ

実物テンプレート集

• リポジトリ装置の実物一式

エージェント向けREADME（AGENTS.md）

ルールファイル（1）アーキテクチャ — architecture.md

ルールファイル（2）テスト — testing.md

ルールファイル（3）レビュー — review.md

ルールファイル（4）ロギング — logging.md

ルールファイル（5）データベース — database.md

サブエージェント定義の編成一式

スキルの実例（3本）

• tdd テスト駆動開発の実行手順
• create-pr PR本文を構造化して投稿する
• eng-practices — 外部の定番で自己レビューする
• プランドキュメントの完全版
• 組織ガバナンスの実物一式

管理者設定ファイル managed-settings.json

3層レビューのCIワークフロー

LLM異常検知の判定プロンプト

• プロンプト集 8ステップをそのまま回す依頼文

Step 1: プランドキュメントの作成（インタビュー式）

Step 2: プランのAI相互レビュー（観点別）

Step 3: テスト網羅のレビュー

Step 4: 実装

Step 5: テストの実装と全通過

Step 6: 実装のAI相互レビュー（観点別並列）

Step 8: テスト駆動リファクタリング

• チェックリスト集

個人導入のチェックリスト 今日から3日で装置を組む（第7章）

毎タスクのチェックリスト 8ステップの関所（第7章）

週次・月次のチェックリスト 実体験からの教訓（第7章）

品質が揺れたときの切り分け X→Y→Fの順に疑う（第2〜6章）

組織導入のチェックリスト（第8章）

• おわりに