書籍「プロフェッショナルAI駆動開発」紹介スライド

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

AIの揺らぎは消せない。だが、再現性はつくれる。感覚に頼らないAI駆動開発の1冊

AIに指示すればコードは動く。だが同じ指示でも、返ってくるコードは毎回違う。LLMの出力は本質的に確率的です。この揺らぎを放置した結果、セキュリティ事故やデータ消失、誰も理解していないコードの蓄積が、現場で実際に起きています。

本書『プロフェッショナルAI駆動開発』は、この揺らぎを制御するフレームワーク「Y = F(X)」を軸に、AI駆動開発を再現性のあるプロセスとして体系化した実践書です。何を入力し（X）、何をもって完成とし（Y）、どのモデルにどう任せるか（F）。開発をこの3要素で捉え直すことで、感覚に頼っていた判断を手順として扱えるようにします。

特徴は3点です。1つ目は、揺らぎを制御する4つの手法、すなわちコンテキストエンジニアリング（X）、テスト駆動開発（Y）、LLMオーケストレーション（F）、AI相互レビューを、根拠とともに解説する点。2つ目は、著者自身のSaaS開発の実体験に基づく点。AIが書いたテストに騙された話、リファクタリングを後回しにして無限ループに捕まった話など、理論だけでは見えない落とし穴を取り上げます。3つ目は、個人の開発から組織展開までを射程に収める点。リポジトリ設計、8ステップの開発フロー、組織導入ロードマップまで、そのまま真似できる手順と実物のテンプレートを提供します。

Transcript

1. page 1 プロフェッショナル AI 駆動開発 書籍紹介
2. 概要 page 2 AIの出力は、3つの変数(Y=F(X))で制御しろ X インプット コンテキストエンジ ニアリングで制御 F LLM LLMオーケストレ ーションで制御 Yアウトプット テスト駆動開発で制御 Yは蓄積されて、次のXになる Xを整える Fを選ぶ Yを固める
3. page 3 目次 第１章 第2章 第3章 第4章 第5章 第6章 第7章 第8章 AI駆動開発の現状と課題 AI駆動開発のフレームワーク コンテキストエンジニアリング テスト駆動開発 LLMオーケストレーション AIによる相互レビュー AI駆動開発の実践フロー AI駆動開発を組織へ展開
4. 第１章 AI駆動開発の現状と課題 Vibe Codingを重ねれば重ね るほどAIが馬鹿になる！？ 悪 循 環 一定の確率で汚い コードが混ざる AIへのインプット の質が低下する AIのコーディング 精度が下がる page 4
5. page 5 第１章 AI駆動開発の現状と課題 AIの2つの特性 AIの挙動は、全体最適 ではなく個別最適 AIの出力は、決定論 ではなく確率論 AIは、単一ゴールに強く最適化 出力は、同じ指示でも毎回異なる 可読性・整合性・保守性といった複 数ゴールを同時に追うのは苦手 どんなに優れたAIでも、一定の確 率で汚れたコードが紛れる 第１章、Vibe Codingの課題と その背景にあるAIの特性を解説 第１章、Vibe 第 １章、Vibe Codingの課題と その背景にあるAIの特性を解説 その背景にあるAIの特性を解説
6. 第2章 AI駆動開発のフレームワーク page 6 AI駆動開発のフレームワーク(Y=F(X))を提案 X インプット コンテキストエンジ ニアリングで制御 F LLM LLMオーケストレ ーションで制御 Yアウトプット テスト駆動開発で制御 Yは蓄積されて、次のXになる Xを整える Fを選ぶ Yを固める
7. 第3章 コンテキストエンジニアリング AIへ与えるインプット(X)は、 情報の過不足と矛盾を排除 AIへ与えるインプット(X)は、 情報の過不足と矛盾を排除 情報の過不足と矛盾を排除 プロンプトはどう書くか？ 対話履歴はいつ圧縮？ ルールは何を書けばいい？ スキルは何を入れればいい？ コードベースの構成は？ 外部情報は何を与える？ ドキュメントはどう書く？ page 7
8. 第4章 テスト駆動開発 page 8 ※Kent BeckのTDD とは別の概念 AI駆動開発は、「速さ」と「品質」のトレードオフ 「速さ」 「品質」 AIを信頼して、品質を検証 をスキップする AIを疑い、すべてのコード を人間でレビューする トレードオフを解消するのは、 品質の機械判定（自動テスト）のみ
9. 第4章 テスト駆動開発 page 9 ※Kent BeckのTDD とは別の概念 AIのアウトプット(Y)は、テストで自律的フィードバックループへ AIのアウトプット(Y)は、テストで自律的フィードバックループへ AIのアウトプット(Y)は、テストで自律的フィードバックループへ 人間が指示 人間が指示 AIが実装 AIが実装 機械で正誤判定 人間が手動テスト とフィードバック AIが修正 人間が手動テスト とフィードバック テスト駆動 開発の導入 AIが修正 機械で正誤判定 AIが修正 人間が手動テスト AIが修正 機械で正誤判定 人間が最終確認 で手動テスト 完了 完了
10. page 10 確率を「数」で買う 試行A タスク 試行B 選択 試行C 確率を「適所」で買う 第5章 LLMオーケストレ ーション タスクA タスクB タスクC 思考力 クリエイティブ 安定感 に強いAI に強いAI に強いAI
11. 第6章 AIによる相互レビュー X, Y, Fの全てを改善する「AI相互レビュー」 page 11 X インプット コンテキストエンジ ニアリングで制御 Xに入り込むコードの「汚れ」を関所で止め、 Xを綺麗に保つ Yアウトプット 定量評価（自動テスト）で検知しきれない テスト駆動開発で制御 F LLM LLMオーケストレ ーションで制御 課題を、定性（相互レビュー）で検知 LLM同士のコミュニケーションが、 オーケストレーションの質を向上
12. 第7章 AI駆動開発の実践フロー プランドキュメントの作成 プランのAIレビュー（仕様・設計・実装） プランのAIレビュー（テスト計画） 実装 テスト通過まで自律的に修正 AIレビュー通るまで自律的に修正 人間による手動テスト・レビュー リファクタリング page 12
13. 第8章 AI駆動開発を組織へ展開する 個人から組織へ視点を変えると見える3つの壁 page 13 属人性の壁 ハーネス環境を共有資産化 シニアが書いたコードをAI が参考にする 障害影響の壁 フィーチャーフラグ／カナリア リリースで影響範囲を絞る 品質責任の壁 3層レビュー：テスト（全コード） →AIレビュー（全PR）→人間 （重要箇所のみ）
14. 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駆動開発を、ガバナンスの設計と段階的な導入によっ て組織の能力へ広げる方法を説明した章。
15. page 15 THANK YOU! @xjuntaro @sakamoto_582