企画書を一つ直すために、全工程をやり直す必要はなかった
meta-plan は、Claude Code で企画作業を一連の流れとして進めるための非公開プラグインだ。プラグインは、よく使う作業手順やツールをまとめて追加する拡張機能を指す。テーマを受け取ると、資料調査、PRD の作成、異なる役割によるレビュー、画面モックアップ、最終検証を順に進める。PRD は、何を作り、どの条件を満たすべきかを記す製品要求仕様書で、モックアップは実装前に画面の見た目や流れを確認する試作案だ。
前回の記事では、書く AI と問い直す AI を分ける構造を説明した。今回は、その構造を実際に運用する中で生じたコストを減らした。すでに決めた機能を文書にまとめる際に外部論文から探し直すか、まだ画面を議論する段階ではないのにモックアップまで作るかを選べるようにした。レビューを丸ごとなくすのではなく、今回の実行で何を作るかを先に決める。
社内システムにつながる非公開ツールのため、公開のインストール先 URL は提供しない。以下のオプション例は、meta-plan を利用できる環境向けの説明だ。インストールしていない読者も、最後の節にある依頼文を自分の AI 作業に使える。
Quick は調査量を減らす。レビューの役割は変えない
トラックは、調査規模を選ぶ実行方式だ。Quick は小さく慣れたテーマ、Standard は一般的な企画、Deep は比較対象の範囲が広いテーマに向いている。三つのトラックすべてで、抽出した主張に対して、原文との照合、反例の探索、誇張の確認という三つの観点から検証する。
Quick の基本調査は 3 つの観点で行い、読む原文は最大 6 件、検証する主張は最大 8 件だ。Standard はそれぞれ 6・15・20 件、Deep は 8・24・30 件となる。抜けていた問いを補う調査や、別途行う補強の実行は、この基本範囲と分けて記録する。読む資料が少なくても、同じ問いに同じ深さで答えたとは主張しない。
| トラック | 原文の上限 | 検証する主張の上限 | 選択例 |
|---|---|---|---|
| Quick | 6 件 | 8 件 | 範囲の小さな変更 |
| Standard | 15 件 | 20 件 | 一般的な企画 |
| Deep | 24 件 | 30 件 | 広範な比較調査 |
/meta-plan:meta-plan <repo> <テーマ> --quick
/meta-plan:meta-plan <repo> <テーマ> --depth deep資料調査と画面制作は、それぞれ省略できる
--skip-research は、外部論文やトレンドの調査を省略する。すでに集めた資料をもとに要件を整理するときに使える。会社のナレッジベース、つまり既存の機能や方針をまとめた文書群と、実際のコードは引き続き確認する。必要な法的根拠の確認も残す。外部調査をしていないのに最新動向まで確認したとは記さず、不足する根拠は未検証として残す。
--skip-mockups は、画面案の制作と画面レビューを省略する。代わりに PRD HTML、つまりブラウザーで開いて読む企画書を作る。必要な画面や、結果が空の場合・エラー時にどう動作するべきかは文書に残す。文書の表示状態は検査するが、まだ作っていない製品画面を検証済みとは表示しない。
二つのオプションは、どのトラックでも併用できる。--full-review は、選択した範囲に対する追加のクロスレビューを常に実行するオプションだ。省略した調査やモックアップを作り直すという意味ではない。実行時の選択は記録に保存され、中断後に再開するときも同じ範囲を維持する。
/meta-plan:meta-plan <repo> <テーマ> --skip-research --skip-mockupsPRD だけの成果物でも、省略した範囲を示す
以下は、公開説明用の架空の例を実際の変換ツールで生成した PRD 画面だ。顧客資料や実際の運用事例ではなく、AI が企画の全工程を最後まで実行した結果でもない。モックアップ省略の案内が表示され、画面一覧と要件が企画仕様として残っていることを確認するための例だ。
基本の文書検査では、目標と要件の対応、根拠の記載、決定状況、必要な節を確認する。モックアップを省略する経路でも、これらの検査を維持した。画面状態の仕様が空の場合はエラーとして検出するようにも補強した。省略は選択範囲を変えるが、残した内容の欠落を認める免除ではない。
減らしたのは繰り返しの呼び出しだ。総コストを 80% 削減したわけではない
以前は、レビューの指摘を反映するときに編集ツールを何度も呼び出していた。今は複数の修正をまとめて適用し、画面状態もまとめて確認できる。PRD を 10 万文字前後で書くという目標をなくし、必要な要件・受け入れ基準・根拠を盛り込む分量に変えた。承認後の再レビューや再開も、合意段階の最大 5 ラウンドに含めて数える。最後に修正した版がレビューされていなければ、以前の版の承認を流用しない。
引用の確認は最大 5 件ずつまとめた。標準調査で 20 の主張を確認するとき、リクエストファイルの書き込みと確認コマンドの実行を合わせた回数が、40 回から 8 回に減る仕組みだ。この作業の呼び出し回数が 80% 減ったという意味である。文章の前後を読んだり、確認に失敗した資料を再確認したりする作業は別にある。
トークンは、AI が文章を読み書きするときに処理する小さな断片の単位だ。呼び出し回数が減れば、繰り返し読む量を減らせる可能性はあるが、総トークン数と所要時間が同じ割合で減ったという実測はまだない。自動テスト 77 件とブラウザーの回帰検査 33 件は通過したが、実際の企画品質や総コストの削減率を証明するものではない。
自分の AI 作業では、まずこの三つの指示を加えてみる
ツールを直接使わなくても、開始時に調査範囲、作る成果物、最後まで残す確認手順を分けて書ける。たとえば、既存機能の改善会議に持ち込む文書が必要なら、次のように依頼する。
この依頼は、速さや正確さを保証する呪文ではない。AI がどこまで作業するべきかを定める作業範囲だ。成果物を受け取ったら、何を省略したか、どの根拠を確認したか、まだ何が分かっていないかを先に読む。外部との比較や画面の議論が実際に必要になったときに、その作業を別途追加すればよい。
既存の文書と実際の動作を根拠に、要件を整理してください。
外部動向の調査と画面案の制作は、今回の範囲から除外します。
要件・受け入れ基準・根拠・未確認事項を残し、
作成とレビューの役割を分けて確認してください。
確認していない内容を検証済みと表示しないでください。