プロフェッショナルAI駆動開発〜確率論から決定論へ AIの揺らぎを制御する開発フレームワーク〜

第1章 AI駆動開発の現状と課題
■1.1 AIが当たり前になった開発現場
■1.2 AIがもたらした技術的負債と理解負債
■■バイブコーディングが引き起こしたセキュリティ事故
■■理解なきコードの氾濫とレビュー負荷の増大
■■知覚と現実の乖離 - なぜ自分では見抜けないのか
■■技術的負債と理解負債の正体
■■理解負債の検出方法と測定指標
■1.3 AIが活躍する領域と活躍できない領域
■1.4 「動くコード」では不十分 - 保守運用フェーズの惨劇
■1.5 感覚に依存したAI駆動開発の限界
■■LLMとは確率マシンである
■■確率の嵐によるエラー地獄
■1.6 AI駆動開発の成熟度モデル
■1.7 感覚から工学へ

第2章 AI駆動開発の工学的フレームワーク
■2.1 AI駆動開発を支えるフレームワーク「Y = F(X)」
■■従来開発とAI駆動開発の構造的な違い
■■なぜX・F・Yの3つであり、3つだけなのか
■■AIへのインプットを示す「X」
■■確率的に変換するモデルを示す「F」
■■テストによって確定される結果を示す「Y」
■2.2 3つの要素の相互関係と優先順位
■■3つの制御の優先順位：Y > X > F
■■3つの要素の相互関係とは
■■3つの要素の相互関係が引き起こす好循環・悪循環
■■好循環・悪循環の定量シミュレーション
■2.3 制御しないと何が起きるか
■■インプット（X）の放置が引き起こすコード品質のばらつき
■■モデル（F）の確率的性質が引き起こす品質のばらつき
■■アウトプット（Y）の判定不在が引き起こすセキュリティ事故
■■アウトプット（Y）を人間だけで判定する限界
■■X・F・Yの制御不在がもたらす構造的な帰結
■■Y = F(X)で読み解く現場の失敗3選
■2.4 Y = F(X)を他の工学分野から見る
■2.5 AI駆動開発を3つの制御で成立させる
■■インプット制御のためのコンテキストエンジニアリング
■■アウトプット制御のためのテスト駆動開発
■■確率を制御するためのLLM並列実行

第3章 インプット制御のためのコンテキストエンジニアリング
■3.1 コンテキストエンジニアリングとは
■■プロンプトに留まらないAIへのインプット
■■与えられた情報だけで判断するAI
■■コンテキストウィンドウの有限性を理解する
■3.2 コンテキスト設計が破綻する2つの理由
■■古い情報が性能を低下させる
■■無関係・対立する情報が混乱を招く
■3.3 古い情報を扱わないための対処法
■■長すぎる対話履歴の罠
■■履歴をサマライズして新しいチャットに引き継ぐ
■3.4 無関係・対立する情報を混ぜないコンテキスト設計
■■情報の不足を避ける
■■必要な情報だけを与える
■■矛盾する情報を排除する
■■コードベースそのものがコンテキストを汚染する
■■コンテキスト設計のBefore/After
■■ルールファイル設計のベストプラクティス
■■1責務1ファイルのコード設計とインデックス整備
■■サブエージェントに小タスク依頼
■3.5 コンテキストの腐敗・汚染アンチパターン5選
■■ゾンビコメント
■■タイムカプセル仕様書
■■ログ洪水
■■何でもコンテキスト
■■矛盾ルール
■3.6 コードベースの衛生管理
■■1ファイル1責務の徹底
■■定期的なデッドコード削除
■■状態管理パターンの一元化
■■フォルダ構造の整理
■3.7 最小のコンテキストでインプットを最適化する
■■インプット最適化に向けた2つの原則
■■鮮度とS/N比を定量的に判断する
■■インプット最適化の限界

第4章 アウトプット制御のためのテスト駆動開発
■4.1 テスト駆動開発とは
■■Kent Beckが提唱するテスト駆動開発
■■テストを先に書き、実装を後から行う開発手法
■■Clean code that works
■4.2 AI時代におけるテストの役割変化
■■AI時代のTDDの革命
■■安全網から実行可能な仕様書へ
■■AI時代における品質保証の自動化
■4.3 ゴールが定義されていないAI開発の破綻
■■曖昧な指示の罠
■■Human in the Loopのボトルネック
■■従来のAI開発の効率限界
■4.4 テストという絶対的なゴール判定
■■準委任契約と請負契約
■■ゴールの定義で変化するAIの振る舞い
■■テストによる自動検証の実装例
■■テストが可能にする自律的反復
■4.5 テストが可能にする自律的な開発ループ
■■AIが自律的に反復できる条件
■■自律型エージェントの真価
■■効率化の数学
■■業界の実践例
■4.6 テストコードの具体例
■■単体テスト：境界値テストの例
■■E2Eテスト：ユーザーフローの例
■4.7 テストそのものが間違っている場合
■■常にパスするテスト
■■ダミーAPIによる偽の安心
■■テストのテスト問題 - 実践的な対策
■4.8 脆いテスト（Brittle Tests）とその対策
■4.9 テスト戦略の意思決定フレームワーク
■4.10 テストがAIの学習データになる
■4.11 AIにテストを書かせるときの注意点

第5章 確率制御のためのLLM並列実行
■5.1 モデルとは何か
■■LLMの基本的な仕組み
■■トークン生成のメカニズム
■■100回実行すれば100通りの結果
■5.2 実装完了確率という考え方
■■実装完了確率の定義
■■実装完了確率の測定方法
■■確率を左右する変数
■■直列実装が確率を下げる理由
■5.3 確率制御のための並列実行
■■並列実行の数学的根拠
■■並列実行のコストとトレードオフ
■■LLMの得意不得意で使い分ける並列実行
■■並列実行の実践パターン集
■5.4 並列実行とテストの相互依存
■■テストなしの並列は非効率
■■テストありの並列が生む自律的選別
■■きれいなコードを選ぶ = 次のXを最適化する

第6章 最適化を壊さないAIによる相互レビュー
■6.1 相互レビューが必要な理由
■6.2 AIによる相互レビューとは何か
■■AIが出力したアウトプットを別のAIが評価する
■■AIは複数の目的を同時に追いかけるのが苦手
■■単一目標最適化が生むSingle Source of Truth崩壊
■■役割分離による品質向上
■6.3 インプットを向上させる相互レビュー（X）
■■アウトプットが次のインプットになるサイクル
■■きれいなコードのためのルールとリファクタリング
■■悪循環から好循環への転換
■6.4 アウトプットを面で保証する相互レビュー（Y）
■■点の品質保証から面の品質保証へ
■■可読性・保守性・シンプルさの評価
■■レビュー評価基準の具体的ルブリック
■■レビューAIへの指示方法
■■開発ルールへの準拠確認
■■テストコードそのものをレビューする
■6.5 モデルの出力を選別する相互レビュー（F）
■■並列実装の選別にレビューを使う
■■テスト通過→レビュー評価→最適選択のフロー
■6.6 統合最適化の威力
■■X × Y × F の好循環
■6.7 フィードバック振動の問題と対策
■6.8 人間レビューとAIレビューの役割分担
■■セキュリティ審査の専門エージェント
■6.9 レビューのBefore/After実践例

第7章 AI駆動開発を成立させる実践フロー
■7.1 再現性を生むリポジトリ設計
■■ファイル分割とコンテキスト最適化
■■クリーンアーキテクチャによるファイル構成
■■インデックスファイル（README.md）の役割
■■ドキュメントフォルダの設計
■■リポジトリ設計の実践例：READMEとdocs/の実物
■■ドキュメントフォルダの実テンプレート
■7.2 並列開発の実装パターン
■■ローカル並列開発（Git Worktree）
■■クラウド並列開発（ブラウザ環境）
■■ローカルとクラウドの使い分け
■■リファクタリングとスマホ運用
■7.3 テストコードの実装
■■単体テスト：Red-Green-Refactor
■■TDD実践のコツとコミットルール
■■E2Eテスト：Playwrightの概要
■■並列E2Eのテストデータ設計
■■E2Eテストの実行環境（Sandbox）
■■単体テストとE2Eの使い分け
■■E2Eテストの運用と最新化
■7.4 開発フローの6ステップ
■■6ステップの時間配分ガイド
■■機能ブランチの作成
■■フロントエンドUIの構築
■■実装プランとテストファイルの作成
■■バックエンドロジックの実装
■■AI相互レビューとマージ
■■テスト駆動リファクタリング
■7.5 AI駆動開発の落とし穴
■■AIがテストを「騙す」問題
■■無限ループ問題とその脱出法
■7.6 AI駆動開発の時間配分の現実
■■時間配分の現実：機能実装1/3、仕様・テスト・リファクタリング2/3
■■落とし穴を回避するためのチェックリスト
■7.7 筆者のSaaS開発から学んだこと
■■テスト漏れの失敗と封じ込め
■■リファクタリング週間によるV字回復
■■try-catch戦略 - AIフレンドリーなエラー設計

第8章 AI駆動開発を組織へ展開するために
■8.1 個人から組織へ
■■個人開発と組織開発の本質的な違い
■8.2 複数AIのオーケストレーション
■■リソース配分と品質確認の判断基準
■■個人のオーケストレーションが組織で直面する壁
■8.3 組織がAI時代に直面する固有の課題
■■シニアエンジニアのレビュー地獄
■■従来の分業制の限界
■■理解負債の組織的影響
■■巨大なコードベースによるコンテキスト肥大化
■8.4 AI駆動前提の開発体制とガバナンスフレームワーク
■■新しい分業制の確立
■■レビュー体制の再設計
■■AIワークフローの標準化
■■意思決定と責任の所在を明確にする
■8.5 組織で回すためのAIワークフロー標準化
■■個人のドキュメントから組織のドキュメントへ
■■開発ルールの明文化と標準化
■■コンテキストを最適化し続ける仕組み
■■テスト駆動開発とリファクタリングで品質を担保
■■本番リリースのリスクをより減らす
■8.6 段階的導入のロードマップ
■■失敗しないAI駆動開発の組織展開
■■AI駆動開発の段階的導入ロードマップ
■■4フェーズ導入モデルとGo/No-Go判断基準
■■組織導入の先行事例に学ぶ
■■経営層を説得するROIケース
■8.7 組織KPIとメトリクス
■■導入KPI
■■品質KPI
■■理解負債インデックス
■8.8 規制産業でのAI駆動開発
■■規制産業固有の要件
■■Y = F(X)の厳格適用
■■規制産業向けの実装例
■8.9 エンジニアの役割変化 - スキルトランスフォーメーション
■■歴史に学ぶツールの変遷と役割変化
■■新しいスキル軸
■■「コードを書くスキル」は不要になるか
■■組織としてのスキル移行を支援する