page 1 プロフェッショナル AI 駆動開発 書籍紹介 

概要 page 2 AIの出力は、3つの変数(Y=F(X))で制御しろ X インプット コンテキストエンジ ニアリングで制御 F LLM LLMオーケストレ ーションで制御 Yアウトプット テスト駆動開発で制御 Yは蓄積されて、次のXになる Xを整える Fを選ぶ Yを固める 

page 3 目次 第１章 第2章 第3章 第4章 第5章 第6章 第7章 第8章 AI駆動開発の現状と課題 AI駆動開発のフレームワーク コンテキストエンジニアリング テスト駆動開発 LLMオーケストレーション AIによる相互レビュー AI駆動開発の実践フロー AI駆動開発を組織へ展開 

第１章 AI駆動開発の現状と課題 Vibe Codingを重ねれば重ね るほどAIが馬鹿になる！？ 悪 循 環 一定の確率で汚い コードが混ざる AIへのインプット の質が低下する AIのコーディング 精度が下がる page 4 

page 5 第１章 AI駆動開発の現状と課題 AIの2つの特性 AIの挙動は、全体最適 ではなく個別最適 AIの出力は、決定論 ではなく確率論 AIは、単一ゴールに強く最適化 出力は、同じ指示でも毎回異なる 可読性・整合性・保守性といった複 数ゴールを同時に追うのは苦手 どんなに優れたAIでも、一定の確 率で汚れたコードが紛れる 第１章、Vibe Codingの課題と その背景にあるAIの特性を解説 第１章、Vibe 第 １章、Vibe Codingの課題と その背景にあるAIの特性を解説 その背景にあるAIの特性を解説 

第2章 AI駆動開発のフレームワーク page 6 AI駆動開発のフレームワーク(Y=F(X))を提案 X インプット コンテキストエンジ ニアリングで制御 F LLM LLMオーケストレ ーションで制御 Yアウトプット テスト駆動開発で制御 Yは蓄積されて、次のXになる Xを整える Fを選ぶ Yを固める 

第3章 コンテキストエンジニアリング AIへ与えるインプット(X)は、 情報の過不足と矛盾を排除 AIへ与えるインプット(X)は、 情報の過不足と矛盾を排除 情報の過不足と矛盾を排除 プロンプトはどう書くか？ 対話履歴はいつ圧縮？ ルールは何を書けばいい？ スキルは何を入れればいい？ コードベースの構成は？ 外部情報は何を与える？ ドキュメントはどう書く？ page 7 

第4章 テスト駆動開発 page 8 ※Kent BeckのTDD とは別の概念 AI駆動開発は、「速さ」と「品質」のトレードオフ 「速さ」 「品質」 AIを信頼して、品質を検証 をスキップする AIを疑い、すべてのコード を人間でレビューする トレードオフを解消するのは、 品質の機械判定（自動テスト）のみ 

第4章 テスト駆動開発 page 9 ※Kent BeckのTDD とは別の概念 AIのアウトプット(Y)は、テストで自律的フィードバックループへ AIのアウトプット(Y)は、テストで自律的フィードバックループへ AIのアウトプット(Y)は、テストで自律的フィードバックループへ 人間が指示 人間が指示 AIが実装 AIが実装 機械で正誤判定 人間が手動テスト とフィードバック AIが修正 人間が手動テスト とフィードバック テスト駆動 開発の導入 AIが修正 機械で正誤判定 AIが修正 人間が手動テスト AIが修正 機械で正誤判定 人間が最終確認 で手動テスト 完了 完了 

page 10 確率を「数」で買う 試行A タスク 試行B 選択 試行C 確率を「適所」で買う 第5章 LLMオーケストレ ーション タスクA タスクB タスクC 思考力 クリエイティブ 安定感 に強いAI に強いAI に強いAI 

第6章 AIによる相互レビュー X, Y, Fの全てを改善する「AI相互レビュー」 page 11 X インプット コンテキストエンジ ニアリングで制御 Xに入り込むコードの「汚れ」を関所で止め、 Xを綺麗に保つ Yアウトプット 定量評価（自動テスト）で検知しきれない テスト駆動開発で制御 F LLM LLMオーケストレ ーションで制御 課題を、定性（相互レビュー）で検知 LLM同士のコミュニケーションが、 オーケストレーションの質を向上 

第7章 AI駆動開発の実践フロー プランドキュメントの作成 プランのAIレビュー（仕様・設計・実装） プランのAIレビュー（テスト計画） 実装 テスト通過まで自律的に修正 AIレビュー通るまで自律的に修正 人間による手動テスト・レビュー リファクタリング page 12 

第8章 AI駆動開発を組織へ展開する 個人から組織へ視点を変えると見える3つの壁 page 13 属人性の壁 ハーネス環境を共有資産化 シニアが書いたコードをAI が参考にする 障害影響の壁 フィーチャーフラグ／カナリア リリースで影響範囲を絞る 品質責任の壁 3層レビュー：テスト（全コード） →AIレビュー（全PR）→人間 （重要箇所のみ） 

page 14 第1章 AI駆動開発の現状と課題 最後に、各章の概要 AIへの丸投げ（Vibe Coding）がなぜ必ず行き詰まるのかを、LLMの性 質と調査データから構造的に説明した章。 AI駆動開発をY = F(X)という1本の式で捉え直し、感覚的だった開発が 第2章 AI駆動開発のフレームワーク 3つの変数の制御問題になることを示した章。 第3章 コンテキストエンジニアリング AIの挙動はインプット（X）だけで決まるという前提に立ち、コンテキストをど う設計し、劣化からどう守るかを説明した章。 第4章 テスト駆動開発 AI駆動開発に「テスト」を使った「正解の機械判定」を取り入れることで、品 質とスピードのトレードオフが解消されることを理論的に説明した章。 第5章 LLMオーケストレーション 消せないAIの出力の揺れを「実装完了確率」という数字で扱い、並列実行 とモデルの使い分けでその確率を買う方法を説明した章。 第6章 AIによる相互レビュー テストという「点」の検証だけでは守れない品質を、別のAIによる独立した レビューで埋める方法を説明した章。 第7章 AI駆動開発の実践フロー ここまでの理論を、リポジトリ設計と8ステップの開発フローという「毎日回せ る形」に組み上げた実践の章。 第8章 AI駆動開発を組織へ展開 個人でうまく回るAI駆動開発を、ガバナンスの設計と段階的な導入によっ て組織の能力へ広げる方法を説明した章。 

page 15 THANK YOU! @xjuntaro @sakamoto_582