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

プロフェッショナル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 エンジニアの役割変化 - スキルトランスフォーメーション
  ■■歴史に学ぶツールの変遷と役割変化
  ■■新しいスキル軸
  ■■「コードを書くスキル」は不要になるか
  ■■組織としてのスキル移行を支援する

• 内容紹介

  AI駆動開発が急速に普及する一方、LLMの出力は本質的に確率的であり、同じ入力でも毎回異なるコードが生成される。この不確実性を放置したまま開発を進めた結果、セキュリティ事故やデータ消失、保守不能なコードの蓄積といった深刻な問題が現場で顕在化しています。本書『プロフェッショナルAI駆動開発』は、LLMの確率的性質を工学的に制御するフレームワーク「Y = F(X)」を軸に、AI駆動開発を再現性のあるプロセスとして体系的に解説した実践書です。本書の主な特徴は、以下3点にあります。特徴の1つ目が、「LLMを確率マシンとして正面から捉え、その出力を制御する3つの工学的手法を提示する」点です。コンテキストエンジニアリングによるインプットの最適化（X）、テスト駆動開発によるアウトプットの品質保証（Y）、LLM並列実行による確率制御（F）を、数学的根拠とともに解説します。特徴の2つ目が、「著者自身のSaaS開発における実体験に基づく実践知を共有している」点です。テストがAIに"騙される"問題、無限ループからの脱出法、リファクタリング週間によるV字回復など、理論だけでは見えない落とし穴と対処法を具体的に取り上げます。特徴の3つ目が、「個人の開発スキルから組織への展開までを射程に収めている」点です。リポジトリ設計、6ステップの開発フロー、AIによる相互レビュー体制、段階的な組織導入ロードマップまで、現場で再現可能な具体的ステップを提供します。LLMの不確実性に振り回されるのではなく、それを前提として制御する。ツールが変わっても通用する原則を身につけ、AIに任せながらも主導権を握る開発スタイルを確立したいエンジニアにとって、確かな指針となる1冊です。

• 著者について

  松本 淳太郎 (マツモト ジュンタロウ)
  東京大学工学部を経て同大学院技術経営戦略学専攻修了。新卒で東京海上日動火災保険にエンジニア／データサイエンティストとして入社し、2020年よりシリコンバレー駐在でAI/ML領域の技術開発・プロジェクト推進を担当。2023年サイバーエージェントに入社し、MLエンジニアとして生成AI技術の実務適用に従事。在籍中に株式会社ジブリッシュ・ラボを起業し、画像生成AIサービス「SketchMe.App」を開発。SNSではフォロワー4,500人超に向けてAI駆動開発について継続発信。X：@xjuntaro
  
  サカモト
  SNSでエンジニアキャリアに関する発信をする外資IT企業で働くシニアソフトウェアエンジニア。ビッグテック・メガベンなどのトップのテック企業へ入社するためのキャリア論と面接対策情報を発信。AI時代のソフトウェア開発とエンジニアキャリアについても共有。テック企業面接対策サービスInterviewCat開発者。X：@sakamoto_582
  
  株式会社松尾研究所 金 剛洙 (カブシキガイシャ マツオケンキュウジョ キム カンス)
  松尾研究所・東京大学・VCファンドを横断するAI社会実装のプロフェッショナル。生成AIの社会実装を軸に、研究・事業開発・投資を横断して活動。AI・知能化技術の日本社会への実装と普及をミッションに、複数の組織で事業創出とエコシステム形成に取り組む。X：@kangsoo_kim_

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