『プロフェッショナルAI駆動開発 確率論から決定論へ』要約

• 著者：松本淳太郎、サカモト、金剛洙、株式会社松尾研究所
• 出版社：技術評論社（2026年）
• 要約日：2026-11-04
• 要約の範囲：本文全体と付録（第8章の組織展開は要点のみ）

ひとことで：AIの出力（Y）は、渡した情報（X）をLLM（F）が確率的に変換した結果。制御する順番は X → Y → F。コンテキストを整え、テストで機械判定し、モデルは最後に選び方と使い方で調整する。そして「Yは次のXになる」ので、定期的なリファクタリングで汚れを戻し続ける。

すぐ使えるポイント

• CLAUDE.md / AGENTS.md は「地図＋重大な落とし穴」だけにして200行未満。詳細は1トピック1ファイルのルールに分ける
• 1プロンプトに1ゴール。3機能をまとめて頼むと成功率は 0.9³ ≒ 73% に落ちる
• タスクの区切りでセッションを新しくする。調査やログ読みはサブエージェントに任せる
• テストシナリオ（WHAT）は人間、テストコード（HOW）はAI。「このコードのテストを書いて」は頼まない
• 新しいテストは必ずRed（失敗）を確認してから通す
• 実装のレビューは、経緯を知らない別コンテキストのAIに差分だけを渡し、P0/P1/P2で指摘させる
• 往復は1〜4回で打ち切る。P0・P1がゼロなら合格
• 週1回、テストを安全網にしてリファクタリングする

全体像：Y = F(X)

章ごとの要点

第1章 AI駆動開発の現状と課題

• バイブコーディングの代償は、本番事故、誰も理解していないコード、「書く時間が減って確かめる時間が増えた」こと。
• 失敗が必然な理由は3つ。同じ指示でも出力が毎回違う、目の前のタスクにしか最適化しない、認識されない負債は返済されない。
• 進行中は「目視で合格」に見えるので気づけない。感覚ではなく工学として扱う必要がある。

第2章 AI駆動開発のフレームワーク（Y=F(X)）

• X：AIが見ている情報のすべて。頭の中の方針やチャットでの合意は、書かない限りAIには存在しない。
• F：与えられた範囲で確率的に変換するLLM。Y：意図の説明責任を負わないコード。
• Yは次のXになる：汚いコードを積むと次の手本が汚れる。試算では、手を打たないと実装完了確率は90%から50回目に40%まで落ち、10回ごとにリファクタリングすると85〜90%を保つ。
• 制御の順番は X → Y → F。Xは今日から整備でき、すぐ効く。Fは作るものではなく選ぶもの。

第3章 コンテキストエンジニアリング（Xの制御）

• 品質の3原則：鮮度、必要十分性（情報量より情報効率）、一貫性。
• 対策は、実行前（6要素の整備）、実行時（プロンプトとサブエージェント）、実行後（リファクタリング）の3時点で打つ。

第4章 テスト駆動開発（Yの制御）

• テストは「正解の定義」。あるとAIの報告が「頑張りました」から「テストが通りました」に変わり、AIが自走する。人間の仕事は定義と検収になる。
• AIが作る骨抜きテストは3種類：何でも通るassert、ダミー返却のモック、環境変数での条件付きスキップ。
• 対策：人間がシナリオを異常系まで列挙、Red確認、ミューテーション（わざと壊して落ちるか）、テストコード自体をAIにレビューさせる。
• 配分：主要フロー・認可・状態遷移はE2E（内部APIはモックしない）、細かい分岐と計算は単体。副作用を外側に寄せる（Functional Core / Imperative Shell）とモックなしで単体テストできる。
• テストを先に書くかは目的で選んでよいが、「機械の判定が人間の確認より先」は守る。
• UIの美しさ、体感性能、セキュリティ、作るべきかの判断はテストの守備範囲外。

第5章 LLMオーケストレーション（Fの制御）

• 実装完了確率pを体感で3段階に見立てる：90%以上（定型CRUD）、70〜90%（既存との整合が要る）、70%未満（新規設計・正解が曖昧）。
• 直列は p^n で下がり、並列は 1−(1−p)^n で上がる。p=70%なら2並列で91%。並列はテストがあって初めて成立する。
• 並列の型は2つ。正解のある難所は「保険」、正解のないUI案や設計は「コンペ」で外れ値を拾う。
• 適材適所：計画は上位モデル、確定した仕様の実装は1つ下のティア、調査は安いサブエージェント。安い通貨（API料金）を積んで、高い通貨（人間の時間）を払う回数を減らす。
• モデル選びの問い：正解があるか（安定型／探索型）、どれだけ複雑か（賢さ・thinking effort）。上げすぎは考えすぎで逆効果。

第6章 AIによる相互レビュー

• テストは「点」でしか守れず、同じセッションでは実装とテストが結託して矛盾が見えない。経緯を知らない別コンテキストのAIに差分だけを読ませる。
• 観点は判定可能な粒度でルールに書く。優先度はP0（マージ不可）、P1（原則修正）、P2（任意）。
• フィードバック振動を止める：P0・P1ゼロで合格、P2は直さなくてよい、3ラウンドを超えたら人間が裁定。
• 別系統のモデルを1体混ぜると見落としが重なりにくい。
• プルリクエスト、設計ドキュメント、セキュリティの3場面で使う。決済・認証・データ削除・権限は必ず人間も見る。

第7章 実践フロー（8ステップ）

• プランの8項目：概要、背景、詳細設計、テスト影響範囲、新規テストケース、実装順、コミット前テスト実行、スコープ外。
• 並列の足場は、ローカルならGit Worktree、任せて手放すならクラウドのエージェント。
• エラーには「どの関数が・どの入力で・誰の操作で」を構造化して記録しておくと、AIがログだけで原因に辿り着ける。
• 著者の教訓：本番のデプロイ設定とログまでXに入れる、テスト網羅は人間が見る、スキップとダミー応答をレビューで潰す、レビューのしすぎは過剰品質でXを汚す、リファクタリングを止めると無限ループになる。

第8章 組織への展開

• 全社ルールで3領域を決める：本番・機密への書き込み禁止、破壊的コマンドの自律実行禁止、認証情報の隔離。
• 設定は配布して強制する。個人の善意に任せない。
• 3層レビューをCIで機械化：テスト＝全コード、AIレビュー＝全PR、人間＝重要箇所。
• リリースは機能フラグとカナリアで守る。ただし漏洩はロールバックで戻せない。
• 導入はパイロットチームから始め、成功例をテンプレート化して広げる。経営層は投資対効果で動かす。

チェックリスト

最初に1回

• Git管理し、.gitignore に .env を入れた
• AGENTS.md／CLAUDE.md に地図（スタック・構成・コマンド・ルールへの誘導）を書いた
• フォルダ構成を機能単位・1ファイル1責務にした
• ルール3本（architecture / testing / review）を置いた
• テストが1コマンドで走る
• 秘密鍵は自分で管理し、AIに .env を読ませない設定にした

毎タスク

• AIに逆質問させてからプランを書いた
• プランを観点別レビューにかけ、P0を実装前に反映した
• テストケース一覧に自分がビジネスの目で介入した
• 実装はプランを渡すだけにした
• Redを確認してからGreenにした
• 実装レビューを別コンテキストで走らせ、P0/P1ゼロにした（往復1〜4回）
• マージ前に決めたテスト一式を回した

週次・月次

• テスト駆動リファクタリングを回した
• 同じレビュー指摘をルールに昇格した
• 新しいテストのごまかし手口をルールに追記した
• デプロイ設定・ログ基盤など「式の外」に原因が残っていないか見た

詰まったときの診断：X → Y → F の順に疑う

1. X：指示は曖昧でないか、古い文書を読んでいないか、履歴が長すぎないか、巨大ファイルやSSoT違反はないか。原因の大半はここ
2. Y：テストの期待値の誤り、矛盾するテスト、骨抜きはないか
3. F：最後にモデルを疑う。それでも遅ければ同じタスクを並列に投げ、最初にテストが通ったものを採用する。XとYが汚れたままの並列ごり押しは悪手

読むときの注意点

• 数値：実装完了確率の推移は単純化したシミュレーションと著者の体感で、厳密な計測ではない。
• ツールの書式：設定ファイルの書式は執筆時点（2026年）のClaude Code・Codexのもの。中身の構造（役割・観点・境界・優先度）を写す。
• 題材：付録のテンプレートはTypeScript＋Node.js＋PostgreSQLの請求書SaaSが前提。自分のスタックに読み替える。
• ルールの厚み：最初から全部入れない。薄く始めて、レビューで同じ指摘が繰り返された箇所から厚くする。

開発で使える定義ファイル（AI駆動開発キット）

本書の Y=F(X) フレームワークと8ステップを VS Code ですぐ回せるように、Claude Code / GitHub Copilot 両対応の定義ファイルを zip にまとめた。

ダウンロードページへ（パスワードが必要）

導入

1. zip の中身をリポジトリのルートにコピー（既存の .vscode/settings.json があればマージ）
2. AGENTS.md の【】と技術スタック・コマンドを自分のプロジェクトに書き換える
3. docs/rules/*.md の paths: とパス例を自分の構成に合わせる（最初は architecture / testing / review の3本で十分）
4. node scripts/sync-ai-config.mjs を実行して、Claude Code 用と Copilot 用のルール・プロンプトを生成
5. .gitignore に .env と .claude/settings.local.json が入っていることを確認してコミット

8ステップの回し方

軽微な修正は Step 1〜3 と 7 を省略してよい。決済・認証・データ削除・権限は Step 7 を厚くする。

育て方

• レビューで同じ指摘が2回出たら、docs/rules/ に1行足して sync
• 同じ手順を何度もチャットに貼っていたら、.claude/skills/ にスキル化
• AI がテストをごまかす新しい手口を見つけたら testing.md の骨抜き禁止に追記