前回、基本ループの4動作を確認しました。頼む、働く、見る、直させる。今回はその最初の一歩、「頼む」の質だけを掘り下げます。
同じClaude Codeを使っていても、依頼の質で結果はまったく変わります。ある人は曖昧な一言で望んだものを引き出し、ある人は長文の指示書を書いてもズレた結果しか出てきません。差は才能ではなく、伝え方の型にあります。
多くの人は2つの極のどちらかに寄ります。曖昧すぎて何も伝わらないか、細かすぎて指示書を書く時間の方が長くなるか。どちらも「意図が渡っていない」という同じ問題の裏表です。
この回では、その間にある型を渡します。目的・制約・確認方法という3点です。
依頼の質が結果を決める
依頼の精度を決めるのは、長さではなく中身です。
「このスライドをもっと良くして」という依頼と、「社外発表用に文字数を3分の1に削って、数値データと図形は変えないで、削った後の文字数を数えて教えて」という依頼では、返ってくるものの精度がまったく違います。前者は目的も制約も確認方法も渡していません。後者はその3つがすべて入っています。
依頼が具体的になるほど、Claudeが迷う余地が減ります。これは細かく指示することとは別の話です。何を細かくするかが違います。
具体的にするとは、実は4つの型に分解できます。Claude Code公式ドキュメントは、依頼を具体化する方法をこの4つで整理しています。
4つ目の「症状を描写する」は、特に効果が高い型です。原因がまだ分かっていない段階でも使えるからです。
「月次レポートがなんか変」
何が変なのか、どこを見ればいいのか、Claudeには何も渡っていません。
「先月の月次レポートで、地域別の売上合計が全社合計と一致しない。集計元シートのB列とC列を見て、どこで数字がずれているか原因を特定してから直して」
起きている現象と、見るべき場所は渡っています。原因の特定と修正は、Claude側の仕事として任せています。
ただし常に具体的であればよいわけではありません。何を作るか自体をまだ探っている段階では、あえて曖昧な依頼のほうが良いアイデアを引き出すこともある、と公式ドキュメントも留保をつけています。
Plan modeという道具
Plan modeを使うと、ズレは実行が始まる前に見つかります。
いきなり実行させず、まず調査と計画だけを行わせるモードです。コードや文章を変更する前に、Claudeが状況を調べ、やろうとしていることを提示します。
“it can like two, three X success rates pretty easily”
筆者訳（Plan modeを使うと）成功率は2倍、3倍に簡単に上がる。
なぜここまで効くのか。計画を文章にする過程で、あなた自身が意図の抜けに気づくからです。頭の中では繋がっていた話も、書き出すと矛盾や飛躍が見えてきます。それを実行前に直せるのがPlan modeの価値です。
$過去半年分の顧客満足度アンケートを集計して、部署ごとの傾向をまとめて
計画: 1) 元データの列構成を確認 2) 部署列で集計 3) 自由記述欄は別途カテゴリ分類が必要か確認したい 自由記述欄はどう扱いますか。数値項目だけの集計で進めてよいですか。
実行前に質問が返ってきているのが分かります。曖昧さは、実行が始まる前に潰す方が安いという好例です。
マイクロマネジメントにならない渡し方
手順を逐一指定するほど、かえって結果の質は落ちます。
意図を具体的にすることと、手順を逐一指定することは別物です。
“a context minimalist ... too much context can become micromanagement”
筆者訳自分は「コンテキスト・ミニマリスト」だ。詰め込みすぎたコンテキストは、マイクロマネジメントになりかねない。
目的と制約を渡すことと、手順を細かく指定することは違います。前者は結果の精度を上げ、後者はむしろ現場の判断力を奪います。新人に「このデータの意味を考えて方針を決めて」と言うのと、「1行目から10行目まで、この通りに報告書を書いて」と言うのとで、育ち方がまったく違うのと同じです。
依頼の型：目的・制約・確認方法
実務で使える型はこの3つです。
3つ目の確認方法は、次回のCLAUDE.mdの育て方、そして第7回の検証ループへ直結する一番大事な要素です。ここで確認方法まで決めておく癖がつくと、後の回がぐっと楽になります。
「このスライドをもっと良くして」
目的も制約も確認方法もない。返ってくるものの方向性は運任せになります。
「社外発表用に文字数を3分の1に削る(目的)。数値データと図形は変えない(制約)。削った後の文字数を数えて教えて(確認方法)」
同じ依頼でも、迷う余地がほとんど残っていません。
ここまでは、目的・制約・確認方法をあなたが決めて渡す型でした。もっと規模の大きい機能を一から作るときは、順番を逆にする型もあります。Claudeに聞き出させるのです。
海外のClaude Codeユーザーの間では、この技を「interview me（私をインタビューして）」という合言葉で呼んでいます。この一言を添えると、Claudeは実装を始める前に、想定読者・制約・あなたが考えていなかった論点を質問してくる、インタビューする側に回ります。
“my favorite way to use Claude Code to build large features is spec based start with a minimal spec or prompt and ask Claude to interview you using the AskUserQuestionTool then make a new session to execute the spec”
筆者訳大きな機能をClaude Codeで作る一番好きなやり方は仕様書ベースだ。最小限の仕様書かプロンプトから始めて、AskUserQuestionツールを使ってClaudeに自分をインタビューさせ、その後新しいセッションを立てて仕様書を実行させる
やり方はこうです。作りたいものを一言で伝え、AskUserQuestionツールでインタビューしてもらい、答えを1つの仕様書にまとめさせます。実装は、その仕様書を渡した別の新しいセッションで行います。公式ドキュメントは、そのままコピーして使える定型文まで示しています。文中の[brief description]の部分を、作りたいものの一言説明に置き換えて使います。
$claude "I want to build [brief description]. Interview me in detail using the AskUserQuestion tool. Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered. Keep interviewing until we've covered everything, then write a complete spec to SPEC.md."
Claudeが1問ずつ質問を返してくる。答えるたびに、選べる実装の幅が絞られていく。最後に、SPEC.mdへ仕様がまとまる。
役立つ仕様書の条件も明確です。関係するファイルとインターフェースを名指しし、やらない範囲を書き、最後に「これができていれば完成」と確かめられる手順で締めくくる。3つ目の条件は、この回で決めた確認方法そのものです。仕様書ができたら、そのファイルを渡して新しいセッションで実行に移ります。同じセッションのまま続けて実装させると、インタビューの往復がそのまま雑音として残ってしまうからです。ここでも中身は変わりません。目的・制約・確認方法という3点を、今度はClaudeに質問で引き出させているだけです。
現場の例で考える：申し送りとの相似
この型は、実は多くの現場で毎日使っている技術です。申し送りを思い出してください。良い申し送りには必ず、何が起きているか(目的の裏返し)、何を試して何を試していないか(制約)、どうなったら連絡すべきか(確認方法にあたる判断基準)が入っています。
「見ておいて」だけの申し送りが危ういのと同様に、「もっと良くして」だけの依頼も危ういのです。すでに知っている技術を、そのまま持ち込めばいいというのがこの回の要点です。
よくある罠
注意
依頼の型で崩れやすい3点
制約を後出しする。最初に言わず、途中で「あ、それはやらないで」と付け足すと、やり直しが増えます。
確認方法を決めずに投げる。結果が出てから初めて「これじゃない」と気づくのは、確認方法を決めていなかった証拠です。
目的だけ言って制約ゼロにする。自由度が高すぎると、意図していない範囲まで変更されることがあります。
こうして依頼の質が上がっても、まだ課題は残ります。今日気づいたことは、今日のセッションが終わると消えます。次回、その学びを持ち越す仕組みに入ります。
今日のまとめ
- 依頼の質は「目的・制約・確認方法」の3点で決まる
- 詳細を詰め込みすぎるとマイクロマネジメントになり、成果はむしろ落ちる
- Plan modeは、実行前にこの3点のズレに気づくための仕組み
明日のアクション
直近でClaude Codeに頼んだタスクを1つ選び、目的・制約・確認方法の3行に書き直してみてください。
もし確認方法がうまく書けなければ、それは責めるべき点ではなく、次回のテーマである検証ループの入り口です。
書けた3行を、次に似たタスクを頼むときにそのまま使ってみてください。