プロフェッショナルAI駆動開発 ～確率論から決定論へ AIの揺らぎを制御する開発フレームワーク～（技術評論社） [電子書籍]

プロフェッショナルAI駆動開発 ～確率論から決定論へ AIの揺らぎを制御する開発フレームワーク～（技術評論社） の 商品概要

• AIに指示すればコードは動く。だが同じ指示でも，返ってくるコードは毎回違う。LLMの出力は本質的に確率的です。この揺らぎを放置した結果，セキュリティ事故やデータ消失，誰も理解していないコードの蓄積が，現場で実際に起きています。
  本書『プロフェッショナルAI駆動開発』は，この揺らぎを制御するフレームワーク「Y = F(X)」を軸に，AI駆動開発を再現性のあるプロセスとして体系化した実践書です。何を入力し（X），何をもって完成とし（Y），どのモデルにどう任せるか（F）。開発をこの3要素で捉え直すことで，感覚に頼っていた判断を手順として扱えるようにします。
  特徴は3点です。1つ目は，揺らぎを制御する4つの手法，すなわちコンテキストエンジニアリング（X），テスト駆動開発（Y），LLMオーケストレーション（F），AI相互レビューを，根拠とともに解説する点。2つ目は，著者自身のSaaS開発の実体験に基づく点。AIが書いたテストに騙された話，リファクタリングを後回しにして無限ループに捕まった話など，理論だけでは見えない落とし穴を取り上げます。3つ目は，個人の開発から組織展開までを射程に収める点。リポジトリ設計，8ステップの開発フロー，組織導入ロードマップまで，そのまま真似できる手順と実物のテンプレートを提供します。
  

• 目次

  第1章 AI駆動開発の現状と課題
  1.1 AIが当たり前になった開発現場
  1.2 バイブコーディングの代償
  本番で起きた事故
  誰も理解していないコード
  書く時間が減って確かめる時間が増えた
  1.3 なぜ失敗は必然なのか
  同じ指示でも出力は毎回異なる
  目の前のタスクにしか最適化しない
  認識されない負債は返済されない
  1.4 なぜ進行中に気づけないのか
  1.5 どこまで通用してどこから崩れるか
  1.6 感覚から工学へ
  
  第2章 AI駆動開発のフレームワーク
  2.1 開発をY=F(X)という式で捉える
  X（インプット）とは
  F（LLM）とは
  Y（アウトプット）とは
  2.2 Yは次のXになる（好循環と悪循環）
  実装完了確率のシミュレーション
  2.3 好循環と悪循環の具体例
  結末1（悪循環）
  結末2（好循環）
  2.4 どこから制御するのか
  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%へ広がる
  3.5 業界の実践例
  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 編成は単体最強を上回る
  5.2 なぜLLMは揺れるのか
  5.3 モデルには得意と不得意がある
  5.4 賢さは買えるが高い
  5.5 揺れを数字で扱う
  5.6 実装完了確率を最小のコストでどう上げるか
  5.7 確率を「数」で買う
  方向が真逆の2つの式（直列と並列）
  並列のコストと人間の時間
  並列実行の2つの型とは
  テストが並列を成立させる
  5.8 確率を「適材」で買う
  どこまで投資するか
  公式が裏づける分業の2つの型
  タスクごとにサブエージェントを最適化する
  5.9 モデルをどう選ぶか
  5.10 オーケストレーションはY=F(X)の好循環を回す
  5.11 まとめ
  
  第6章 最適化を壊さないAIによる相互レビュー
  6.1 AIによる相互レビューとは
  6.2 なぜテストだけでは足りないか
  単一ゴール最適化
  テストは点でしかない
  自己レビューの限界
  3つの要因を合わせる
  6.3 相互レビューはX・Y・Fの3軸を守る
  Xを守るレビュー
  Yへのフィードバックの質を上げるレビュー
  Fのオーケストレーションに関所を置くレビュー
  3軸は同時に回る
  6.4 レビューを実践に落とし込む
  観点を言語化する
  優先度を3段階で定義する
  テストコードそのものをレビューする
  フィードバック振動を止める
  人間レビューとの境界を引く
  6.5 相互レビューの3つの場面
  プルリクエストのレビュー
  設計ドキュメントのレビュー
  セキュリティレビュー専門エージェント
  6.6 まとめ
  
  第7章 AI駆動開発を成立させる実践フロー
  7.1 再現性を生むリポジトリ設計
  すべての前にGit
  エージェント向けREADME（AGENTS.md
  コードのファイル構造
  クリーンアーキテクチャの議論
  ルールファイル
  スキル
  要件定義ファイル
  外部情報の接続
  エラーをAIが読める形にしておく
  7.2 テストコードの実装
  テストを走らせる土台
  並列実行に耐えるテストデータ
  無効なテストをルールとレビューで弾く
  7.3 オーケストレーションの実装パターン
  ローカル並列（Git Worktree）
  クラウド並列（タスクを投げてPRで受け取る）
  ローカルとクラウドの使い分け
  タスク割り当ての道具（サブエージェント）
  観点別レビューの編成を組む
  別系統のAIに聞く（Claude CodeからCodex）
  7.4 開発フローの8ステップ
  前の介入点となるプランドキュメント
  8ステップの全体像
  後の介入点となるテスト駆動リファクタリング
  7.5 現場で実際に起きたこと
  Xを本番の運用基盤まで広げたら障害が減った
  テストの網羅をAIに任せて後悔した
  AIが書いたテストに騙された
  レビューのしすぎはかえって毒になる
  リファクタリングを後回しにして無限ループに捕まった
  7.6 まとめ
  
  第8章 AI駆動開発を組織へ展開するために
  8.1 個人から組織へ
  8.2 ガバナンスの3段階（開発・リリース・運用）
  開発段階のガバナンス
  リリース段階のガバナンス
  運用段階のガバナンス
  8.3 段階的導入
  導入は組織変革である
  AI Enablementチームによる伴走
  成功事例をテンプレート化して広げる
  8.4 経営層と現場を動かす
  組織はトップダウンで動く（ボトムアップの限界）
  アッパーマネジメントを味方にする
  経営層は投資対効果で動かす
  原動力はリーダーの意志
  8.5 まとめ
  
  Appendix 実物テンプレート集
  A.1 リポジトリ装置の実物一式
  エージェント向けREADME（AGENTS.md）
  ルールファイル（1）アーキテクチャ
  ルールファイル（2）テスト
  ルールファイル（3）レビュー
  ルールファイル（4）ロギング
  ルールファイル（5）データベース
  サブエージェント定義の編成一式
  スキルの実例（4本）
  A.2 テスト装置の実物一式
  単体テストの実物
  E2Eテストの実物
  テスト基盤の実物
  テスト設定の実物
  A.3 プランドキュメントの完全版
  A.4 8ステップを回すためのプロンプト
  1. プランドキュメントの作成（インタビュー式）
  2. プランのAI相互レビュー（観点別）
  3. テスト網羅のレビュー
  4. 実装
  5.テストの実装と全通過
  6.実装のAI相互レビュー（観点別並列）
  7.人間のレビュー（AIへの壁打ち）
  8.テスト駆動リファクタリング
  A.5 チェックリスト集
  個人導入のチェックリスト（第7章）
  毎タスクのチェックリスト（第7章）
  週次・月次のチェックリスト（第7章）
  品質が揺れたとき：X→Y→Fの順に疑う（第2〜6章）
  組織導入のチェックリスト（第8章）
  

プロフェッショナルAI駆動開発 ～確率論から決定論へ AIの揺らぎを制御する開発フレームワーク～（技術評論社） の商品スペック