先日、「GITが読めなかった初心者でもSaaSアプリが作れた秘密：Claude Code×ChatGPT×Codexの使い分け完全ガイド」を投稿した者です。
想像以上の反響をいただきましたが、その中で最も多かった疑問が「具体的にどうやってAIに指示を出していたのか？」という点でした。
実は、私は今回、コードは書いていません。
その代わり、徹底的に**「ランブック（運用手順書）」**を記述し、それをAI（Claude Code）に実行させるという手法をとりました。
これは、単なる「AIへの丸投げ」とは異なります。
「コード」という実装の詳細から、「ランブック」という仕様の定義へと、エンジニアリングの抽象レイヤーを一段階上げる試みです。
今回は、将来のAIドリブン開発のスタンダードになるかもしれない**「ランブック駆動開発（Runbook-Driven Development）」**の実践例と、そのメリットを共有します。
1. なぜ「チャット」ではなく「ランブック」なのか
AIを使った開発でよくある失敗が、チャットで「ここのバグを直して」「機能を追加して」と五月雨式に指示を出してしまうことです。これでは文脈が散逸し、デグレ（既存機能の破壊）が起きます。
私はこれを防ぐため、**「システムのあるべき姿（To-Be）」と「変更手順」を定義したドキュメント（ランブック）**を作成し、これを正（Source of Truth）としました。
人間の役割
- コーディング（How）はしない。
- **「現状の課題」と「達成すべき数値目標」「具体的な変更方針」の定義（What）**に集中する。
AIの役割
- ランブックを読み込み、そこに書かれた手順通りにコードを書き、テストし、デプロイする。
2. 実際のランブック（実例）
以下は、実際にスケーラビリティ改善のフェーズで使用したランブックの一部（Markdown）です。
これを見ると、「プロンプト」というよりは「設計図」に近いことがお分かりいただけると思います。
# Phase 14.2 スケーラビリティ改善ランブック
## 概要
| 項目 | 内容 |
|------|------|
| 目的 | 同時利用可能人数を20人→100人に向上 |
| 現状 | 認証処理に10ms/リクエスト (DB負荷高) |
| 目標 | 認証処理を2ms以下 (キャッシュ利用) |
## 実装タスク
### 1.1 セッションキャッシュの導入
**目的**: 認証チェックのDB負荷を90%削減
**変更対象**: `lib/server/auth.ts`
**要件定義**:
1. **キャッシュ層の追加**:
- Vercel KV (Redis) からセッション取得を試行する。
- キャッシュミス時はDBから取得し、TTL: 300秒で保存する。
2. **ファイル構成**:
- キャッシュロジックは `lib/server/session-cache.ts` に分離すること。
3. **ロールバック手順**:
- 環境変数 `DISABLE_SESSION_CACHE=true` を設定するだけで、即座にDB直接参照に戻せるように実装すること。
（以下、具体的なAPIレート制限の閾値などが続く）
このドキュメントをClaude Codeに渡すと、AIは**「迷い」を消します。
ファイルパス、目的、そして「失敗時のロールバック手順」**まで定義されているため、AIは自律的に実装を行い、仮にエラーが出ても「要件と違う挙動になった」と自己判断して修正を行います。
3. 「コード」は資産ではなく「中間生成物」になる
この開発手法を通じて、私の中でエンジニアリングに対する価値観が大きく変わりました。
従来、ソースコードは「資産」であり、大切に保守し続けるものでした。
しかし、AIネイティブな開発において、**コードは「ランブック（要件）を実現するためにAIが出力した、一時的なコンパイル結果」**に過ぎないのかもしれません。
「技術的負債」への新しいアプローチ
「AIにコードを書かせると、保守できないスパゲッティコードになるのではないか？」
この懸念はもっともです。しかし、AIのモデル性能は指数関数的に向上しています。
もし将来、コードが古くなったり、フレームワークが陳腐化したとしても、手元には**「論理的な日本語で書かれたランブック」**が残っています。
その時の最新モデル（Claude 5や6など）にランブックを渡し、こう指示すれば良いのです。
「このランブックの要件を満たすシステムを、202X年の最新技術スタックで再生成（Regenerate）して」
これからの時代は、「コードのリファクタリング（手直し）」よりも、AIによる「コードのリジェネレーション（再生成）」の方が、コストパフォーマンスが良くなる可能性があります。
4. 結論：AI時代の「エンジニアリング」とは
私は今回、Gitのコマンド操作やDBの接続設定といった「作業」をAIに任せました。
その代わり、「システムがどう振る舞うべきか」「運用はどうあるべきか」というロジックの記述に全力を注ぎました。
結果として分かったのは、**「日本語（自然言語）こそが、最も抽象度の高いプログラミング言語である」**という事実です。
- **Syntax（構文）**を覚えるのではなく、**Logic（論理）**を組み立てる。
- **Implementation（実装）**をするのではなく、**Definition（定義）**をする。
これこそが、AIドリブン開発における人間の役割であり、エンジニアが本来集中すべき「価値」なのかもしれません。
もし「AI開発で思い通りのものができない」と悩んでいる方がいたら、プロンプトを工夫する前に、一度**「完璧な運用手順書（ランブック）」**を書いて、それをAIに読ませてみてください。
驚くような精度で、あなたの"部下"が動き出すはずです。