言出法随 操作手册
言出法随は、Claude Codeの圧倒的な能力の上に成り立っている——ツールが強いからこそ、あなたは「描写する」だけで「操作しない」でいられる。高忠実度は、AI時代にプロダクトマネージャーが需要にスピーディーに応えるための仕事原則だ——ワイヤーフレームを描かず、長い仕様書を書かず、直接動く本物を作る。このページでは「AIへの語りかけの骨格」4つと「高忠実度検証チェックリスト」1枚を渡す。より正確に伝え、より本物を作り、より速く改善できるように。
まず言っておく：フォームを埋めるものではない
多くの方法論では、まず大量のドキュメントを書くよう求める——PRD、仕様書、アーキテクチャ、タスクリスト……全部書いてから動き出す。それは doaipm ではない。
私たちのコアは言出法随だ：あなたが欲しいものを言葉で伝えれば、Claude Code が直接それを作る。だから以下の4つの「テンプレート」は、埋めるためのフォームではなく、AIに語りかけるときに頭に置く骨格だ——骨格を補完すること自体、AIに任せてしまっていい。あなたは確認するだけでいい。
そして出来栄えを測る基準は一つだけ：高忠実度。動く、クリックできる、内容が本物、状態が揃っている。高忠実度は「最後に磨く」ものではなく、AI時代にPMが極速で需要に応える仕事の様式そのものだ——直接検証できる本物を生み出し、すぐ試し、すぐ直す。
骨格① 一言スペック：「何を作るか」を明確に伝える
動き出す前に、この一文を整理する。整理できなければ、AIに聞き返させて、答えてから始める。
【誰】のために、【何の問題】を解決したい。 作るものは、ユーザーが【一番核心的なひとつのアクション】に使える。 うまくいった証は【目に見えるひとつの結果】。 今回はやらないこと：【非目標、スコープの境界線】。 わかっているリスク／前提：【……】。
この文章を Claude Code に渡して、こう一言添える：
このステップが生み出すのはドキュメントではなく、共通認識だ。AIが正確に復唱し、本質を突いた質問ができたなら、本当に理解できた証拠——そこから作られる高忠実度プロトタイプは、的を外さない。
骨格② スモールステップ開発：一歩ずつ言って、一歩ずつ見る
大量の要件を一度に渡してうんうんと作らせない。「一歩ごとにすぐ動いて確認できる」小さなステップに分ける。
どう分けるか
AIに分解させればいい：「この要件をいくつかの小さなステップに分けてください。各ステップが終わるたびにブラウザで動いて効果が確認できるように。リストアップして、一緒に一歩ずつ進めましょう。」
各ステップのリズム
- 一歩だけ伝える：いまのこの一歩だけを伝える。
- 動かして見せてもらう：「完成したらサーバーを起動して、ブラウザで確認させてください。」
- その場でフィードバック：合っていれば次の一歩へ。違ったら「ここが違う、こうであるべきだ……」と伝える。
骨格③ プロジェクトの流儀：一度言えば、ずっと覚えている
毎回繰り返したくない好みがある——技術スタック、スタイル、制約、レッドライン。一度言ってプロジェクトの記憶に書き込めば、以後は自動で守られる。
このプロジェクトでは、常に守ってください： · 技術の流儀：【例：Astroを使う、重いフレームワークを入れない、静的にできるなら静的に】 · スタイル：【例：ダーク、ミニマル、余白多め、テキストは普通の言葉で】 · 制約：【例：有料・サードパーティトラッキングを一切加えない；モバイルファースト】 · レッドライン：【例：本番データに触れない；削除・公開・支払い系の操作は先に確認する】
AIにこれをプロジェクトの「長期的な取り決め」として保存させる（どこに置くかはAIが知っている）。これはプロジェクトの「憲法」を作るようなものだ——でもフォーマットを覚える必要はない、普通の言葉でいい。
⭐ 高忠実度検証チェックリスト（このページで最も重要なブロック）
「作り終えた」は「うまくできた」と同じではない。高忠実度の検収は、スクリーンショットを見ることではなく、本物を動かして、項目ごとに確認することだ。
| 確認項目 | 自分に問う |
|---|---|
| 本物のコンテンツ | 本物のコンテンツとデータ構造か？Lorem ipsum、「サンプルテキスト」、偽のプレースホルダーはないか？ |
| 4つの状態 | ローディング中 / 空データ / エラー / 成功、4つ全部作ったか？空とエラーは最も忘れやすい。 |
| 本物のインタラクション | ボタンは本当にクリックできるか、フォームは本当に送信できるか、遷移は本当に機能するか？「それっぽく見える」だけではないか？ |
| クリティカルパス | ユーザーにとって最も重要なメインフロー、最初から最後まで通ったか？ |
| クロスデバイス | スマートフォンとPCで両方確認したか？少なくとも狭い画面で一度チェックしたか？ |
| 意地悪な入力 | わざと間違えて入力、空欄、異常に長い値、変な文字を貼り付けた——壊れないか？ |
AI機能を作っている場合は、もう一項目加える
AI機能は「一回成功した」だけで合格にしてはいけない。本物でかつ手強い入力を一連でテストし続けて、安定しているか、でたらめを言わないか、失敗したときにどう立て直すかを見る。Claude Codeに数十件のテスト入力を列挙させて一通り走らせる——これが業界で言う「評価ループ（eval）」で、PMでもできる。
骨格④ 発見の問いかけ：考えがまとまらないとき、構造を借りる
「まず3〜5つの質問で明確にする」と言っても、何を聞けばいいかわからないときは、定番の問いかけ構造を一つ借りる（どれか一つ選んで、AIに一緒に問いかけてもらう）。
- JTBD（ユーザーはこれを何のために雇うのか）：「ユーザーはどんな状況で、このものを使って何のタスクを完了しようとするのか？今はどうやってとりあえず解決しているのか？」
- Opportunity Solution Tree（機会解決ツリー）：「私たちが達成したいアウトカムは何か？ユーザーにはどんな痛みの機会があるか？それぞれの機会にどんなソリューションが考えられるか？」
- Working Backwards（結果から逆算する）：「これがすでに完成して公開されたと仮定して、『ユーザーがどう褒めるか』の文章を書いてください——そこから逆算して、私たちが本当に作るべきものを導き出してください。」
上級編：大規模プロジェクト専用（小さなプロジェクトは無視してOK）
小さなプロトタイプなら、前のセクションで十分だ。プロジェクトが大きくなり、会話が長くなったときだけ、この数手が必要になる——それでも「普通の言葉で」で変わらない。
会話が長くなって、AIが鈍くなってきた
長い会話の中でAIは「忘れる」ことがある。そのときはまず調べさせ、計画を立てさせ、あなたが確認してから動かせるようにする。そして折を見て「いまの結論を小さなドキュメントにまとめて保存してください、新しい会話で続けましょう」と言う。コンテキストをクリーンに保てば、AIはずっと賢いままでいられる。
やることが多すぎて、並行したい
複雑なタスクは分身を何体か並行で動かさせることができる（例えば一体が調査し、一体が書き、一体がレビューする）。あなたは「この仕事を分けて並行処理して、最後にまとめてください」と言うだけでいい。
プロトタイプが完成して、本番へ進む
プロトタイプから本番への移行は、また別の道のりだ：本物のデータ、セキュリティ、パフォーマンス、誰が「公開」ボタンを押すか。プロトタイプは大胆に、本番は慎重に——不可逆なボタン（公開 / 削除 / 支払い）は常に人間が押す。このセーフティネットは、本番に近づくほど引き締まる。
