書籍「プロフェッショナル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章 第１章 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の出力は、同じ指示でも毎 回異なる 逆に、可読性・既存設計との整合・ 保守性・セキュリティといった複数ゴ ールを同時に追うのは苦手分野 どんなに優れたAIでも、一定の確 率で汚れたコードが紛れる
6. 第2章 AI駆動開発のフレームワーク page 6 AI駆動開発のフレームワーク(Y=F(X))を提案 X インプット コンテキストエンジ ニアリングで制御 F LLM LLMオーケストレ ーションで制御 Yアウトプット テスト駆動開発で制御 Yは蓄積されて、次のXになる Xを整える Fを選ぶ Yを固める
7. 第3章 コンテキストエンジニアリング AIへ与えるインプット(X)は、 情報の過不足と矛盾を排除 プロンプトはどう書くか？ 対話履歴はいつ圧縮？ ルールは何を書けばいい？ スキルは何を入れればいい？ コードベースの構成は？ 外部情報は何を与える？ ドキュメントはどう書く？ page 7
8. 第4章 テスト駆動開発 page 8 ※Kent BeckのTDD とは別の概念 AI駆動開発は、「速さ」と「品質」のトレードオフ 「速さ」 「品質」 AIの出力、AIを信じて、 品質を検証をスキップする AIを疑い、すべてのコード を人間でレビューする トレードオフを解消するのは、 品質の機械判定（自動テスト）のみ
9. 第4章 テスト駆動開発 page 9 ※Kent BeckのTDD とは別の概念 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 THANK YOU! @xjuntaro @sakamoto_582