うちの会社では、一番賢いAI（Claude の最上位モデル Fable 5）に、コードをほとんど書かせていない。書かせているのは設計書。書き溜めた設計書のうち5本を1つ下のモデルに順に委任して、1日で全部一発検収に通した。この記事では、その役割分担の判断表から、実際に検収を通った設計書の実物、コピペで使えるプロンプト4本まで、全部公開する。
一番賢いAIに、コードを書かせていない
「一番賢いAIには、一番難しい作業をさせる」が普通の発想だと思う。うちも最初はそうだった。最上位モデルが出たらまず一番重い実装を任せて、出てきたコードに感心して終わり。でも毎日使い倒すうちに、逆のほうが得だと気づいた。
理由は単純で、会話の中の賢さは消えるが、設計書はファイルで残るから。
どんなに賢い回答をもらっても、セッションを閉じれば消える。会話が長くなれば劣化もする（このあたりはcompact で会話が壊れていく話で書いた）。一方、賢いモデルに書かせた設計書・ルール・手順書は、モデルが変わっても動き続ける資産になる。モデルは放っておいても進化して安くなるけど、設計資産は自分が書かせた分しか貯まらない。
だから最上位モデルが使えるうちに、その賢さを「消えない形」に変換しておく。うちではこれを「設計書の書き溜め」と呼んで、運用の軸にしている。
「どのAIに何をやらせるか」の判断表
役割分担は、迷わないように表で固定している。
| 作業 | 任せる先 | 理由 |
|---|---|---|
| 発案・壁打ち | 最上位モデル | 曖昧な要望から要件を引き出す力が一番効く場面 |
| 設計書（SPEC）を書く | 最上位モデル | ここの品質が実装の成否をほぼ全部決める |
| 実装 | 1つ下のモデル | 良い設計書があれば、実装は下位モデルで足りる |
| 検収 | 最上位モデル | 「できました」を疑って検証する仕事。ここは賢さが要る |
| typo・1〜2行の修正 | どのモデルでも直接 | 設計書を書くほうが高くつく |
ポイントは、実装だけを下位モデルに落としていること。上流（何を作るか・どう作るか）と下流（できたものの検証）は最上位に握らせて、真ん中の量産部分を安いほうに流す。人間の組織で言えば、設計とレビューをベテランが持って、実装を若手に任せる形に近い。
あわせて「そもそも設計書を書くべきか」も基準を決めている。全部の依頼に設計書を書いていたら、それはそれで回らない。
| 依頼の種類 | 設計書 | 理由 |
|---|---|---|
| typo修正・数行の変更 | 書かない | 会話で直接頼めばいい |
| 独立した機能をまるごと作る | 書く | ファイルで渡せば、別の会話・別のモデルでも回せる |
| 複数ファイルにまたがる変更 | 書く | 「触っていいファイル」を先に確定しないと事故る |
| 設計判断そのものが必要 | 壁打ち→書く | 採用案だけでなく、捨てた案と理由も残す |
設計書は「6要素」で書かせる——実物つき
設計書のフォーマットは6要素で固定している。
- 背景 — なぜやるか。この設計書だけ読めば文脈がわかるように
- 変更対象ファイル表 — どのファイルを触るか。裏返すと「これ以外触らない」宣言
- 具体的変更内容 — 実装者が迷わない粒度で
- 完成条件（DoD） — 「動く」ではなく「テスト◯件通過」のような検証できる形
- 非スコープ — やったら違反になる変更。ついで修正・勝手な整理を含む
- 報告形式 — 「✅検証済（根拠付き）/ ❌不明 / 🟡仮定」の3値で報告させる
抽象論だとイメージしづらいので、実物を見せる。今週うちで実際に一発検収を通った設計書のうち1本（ブログ記事の素材集めを自動化する小さな機能）から、②と⑤の抜粋。
## 変更対象ファイル表（これ以外触らない）
| ファイル | 操作 |
|---|---|
| blog_material.py | Write（新規・週次素材パッケージ生成） |
| config.py | Edit（設定2行の追加のみ） |
| tests/test_blog_material.py | Write（新規） |
| specs/RESULT-SPEC-05e.md | Write（報告） |
## 非スコープ（やったら違反）
- 記事本文の生成・HTML化・デプロイ（既存フローの領分）
- X への投稿・告知文の生成（別機能の領分。呼び出しもしない）
- タスクスケジューラへの組み込み（自動化は運用が回ってから判断）6要素のうち、効いているのは②と⑤だと思っている。AIに仕事を頼むと、頼んでいない箇所まで「良かれと思って」直してしまう事故が起きる。動いていたコードのリファクタ、勝手なファイル整理、関係ない箇所のスタイル統一。「これ以外触らない」「やったら違反」を先に文書で確定させると、これがほぼ消える。操作の粒度も「Edit（設定2行の追加のみ）」まで絞るのがコツで、ここが緩いと解釈の余地が生まれる。
コピペで使えるプロンプト3本（設計→実装→検収）
この型は、プロンプト3本で今日から試せる。まず、実装を頼む前に設計書を書かせる。
この依頼を実装する前に、設計書を1枚書いて。要素は6つ。
①背景(この設計書だけで文脈がわかるように)
②変更対象ファイル表(パスと操作。これ以外触らない宣言)
③具体的変更内容(実装者が迷わない粒度で)
④完成条件(『動く』ではなく『テストX件通過』のような検証可能な形)
⑤非スコープ(やったら違反になる変更。ついで修正・リファクタ含む)
⑥報告形式(✅確認済=根拠付き/❌不明/🟡仮定の3値)
設計書だけ出して、私がOKと言うまで実装しないで最後の1行が肝で、設計と実装を区切って、間に人間の承認を挟む。設計書ができたら、実装は別の会話（下位モデルでいい）に渡す。
SPEC-XX.mdを読んで、記載の変更だけ実装して。
設計書と実ファイルが食い違ったら止めて❌報告。
完成条件は1項目ずつ検証してから✅(未検証は🔄のまま)。
終わったらRESULT.mdにDoD照合表+変更ファイル一覧を3値ラベルで「できました」の報告を受け取ったら、検収する。これもプロンプト1本。
RESULT.mdのDoD照合表で、✅の根拠が薄い項目を1つ選んで
自分で再実行して確かめて。
変更対象ファイル表と実際の変更を突合して、
表にないファイルが変わってたら報告してコツは、「できました」を信じない仕組みごと渡すこと。AIは「たぶん動く」を「できました」と報告する癖がある。悪気はなくて、そういう生き物だと思って運用を設計する。だから報告は3値（検証済/不明/仮定）に縛り、検収では抜き打ちで再実行させる。
検証は3段。「もう一回同じ操作」まで
実装が終わっても、それで完了にしない。うちの検証は3段に分けている。
- コードはテスト必須 — 今週時点で自動テスト21件が通っている状態を維持。テストが通るまで「完了」と言わせない
- 画面があるものはブラウザで実操作 — AIにブラウザを実際に操作させて確認する。今週も「承認した2件だけが書き出されて、未承認の4件が混ざらない」ことを実ブラウザで確認させ、スクリーンショットまで残させた
- 公開物は6観点の最終チェック — 論理・セキュリティ・法的・技術・SEO・ブランドの6つで別のAIにレビューさせて、重大指摘ゼロになるまで出さない（この記事も通してから公開している）
教訓をひとつ。以前「1回目の読み込みは正常、2回目でクラッシュ」というバグを実際に踏んだことがある。1回動かして満足するテストだと、これは通ってしまう。だから検証には「もう一回同じ操作をする」まで入れている。
実録：5本書き溜めて、1日で全部一発合格
この型が実際どう回ったか、今週の実録を時系列で置いておく。
| 日 | やったこと |
|---|---|
| 7/2 | 最上位モデルと壁打ちしながら、機能7本分の設計書パックを生成 |
| 7/3 | 方針変更（露出優先への組み替え）に合わせて設計書側を改訂。実装前なので直すのはファイルだけ |
| 7/4 昼 | うち5本を、1つ下のモデルに順に委任 |
| 7/4 夕 | 5本すべて一発で検収合格。自動テスト累計21件 green |
正直に書くと、「一発合格」は実装側のモデルが優秀だったというより、設計書の時点で失敗パターンを潰してあったのが大きい。差し戻しの原因になりがちな「頼んでいない変更」「未検証の完了報告」が、⑤非スコープと⑥3値報告で先回りして封じてある。実装中に仕様の曖昧さで手が止まることも、②と③で潰してある。設計書の品質が、そのまま検収の通過率になる。
途中の方針変更に強いのも書き溜めの利点だった。7/3に投稿戦略を組み替えたとき、直したのは設計書ファイルだけ。実装に入った後の方針変更は手戻りコストが大きいけど、設計書の段階なら書き換えて済む。
全部を一発で立ち上げるプロンプト
最後に、この仕組み全体を自分の環境に作らせるプロンプトを置いておく。いま使っている一番賢いAIに、これを打つところから始めればいい。
あなたに私のAI開発環境の設計者になってほしい。順に設計して:
①ルールの2層化: 常駐ルール(毎回読む・上限行数を先に決める)と
場面別ルール(キーワードで必要時だけ読む)に分けて、既存の指示書を仕分けして
②作業の型: 実装依頼は必ず『6要素の設計書→私の承認→実装→3値ラベル報告→検収』の流れに。
各段階のテンプレを作って
③検証の型: 変更にはテスト必須。UIがあるものはブラウザ自動テスト(E2E)まで。
『テストが通るまで完了と言わない』をルール化して
④手順のSkill化: 毎回やる作業(リリース前チェック等)を起動条件付きの手順書ファイルに
まず現状の私の環境を調査して、4つの設計案と移行手順を出して。実装は私のOK後うちはこの型で、常駐ルールを6ファイル・合計700行以下に絞り、場面別ルール15本を必要な時だけ読み込む形にして、繰り返し手順は63本のSkill（起動条件付きの手順書）として貯めてきた。ここまでの仕組みは全部、AI自身に設計させたものだ。環境整備の具体的な進め方は自分仕様化の7ステップに分けて書いてある。
まとめると、こうなる。
- 最上位モデルには、今日のコードを書かせるより、設計書とルールと検収の型を書かせる
- 会話の賢さは消える。ファイルは残る
- 設計資産は書いた分しか貯まらない。始めるなら早いほうがいい
モデルの賢さそのものは、どの会社も同じ値段で買える時代になった。差が付くのは賢さを何に変換して貯めるかで（この話はAI活用の本当の分かれ目として別記事に書いた）、設計書の書き溜めはその一番実践的な形だと思っている。あなたがいま使っている一番賢いAIに、何を「残る形」で作らせますか。