Claude Codeへの依頼文は4ブロックで書く: 前提・成果物・制約・確認

「この記事、もっと良くしといて」

そう打って席を立ち、戻ってきたら、Claude Codeは記事の本文をまるごと書き直していました。確かに前より読みやすい。でも、僕がページ末尾に置いていた有料教材へのリンクが、3本まとめて消えていたんです。

差分を見るまで、まったく気づきませんでした。文章はきれいになっているから、ぱっと見では「良くなった」としか思えない。これが一番こわい事故です。

原因はモデルの賢さではありません。僕の依頼文に「どこまでやるか」と「何を残すか」が一行も書いてなかった。それだけでした。

この記事の要点

• 1つの作業を頼むときの依頼文（ブリーフ）は、前提・成果物・制約・確認の4ブロックで書くと差分が暴れない。
• いちばん効くのは制約。「触らないファイル」「残すリンク」を先に書くだけで、収益リンクや設定が消える事故が止まる。
• 成果物は「良くして」ではなく「終わったと判定できる条件」で書く。曖昧だと差分が広がる。
• 確認はClaude Code自身にコマンドを実行させ、証拠を報告させる。人間の記憶に任せない。
• ブリーフは1作業=1ファイル単位。「全部やって」をやめて小さく切るほど、結果的に速い。

この記事は「1つの作業を頼むときの依頼文の型」に絞っています。プロンプト全般の基本型を先に押さえたい人は Claude Code/Codexプロンプト入門、チーム運用で再利用するパケット化の話は 高度プロンプト設計 を読むと、ちょうど補い合います。

なぜ「頼み方」で差分が暴れるのか

Claude Codeは、コードベースを読んでファイルを編集し、コマンドまで実行するエージェントです。公式の Claude Code overview にもそう書いてあります。つまり、相手は「文章を返すチャットボット」ではなく「作業を代行する同僚」です。

ここを勘違いすると事故ります。同僚に「いい感じにやっといて」と頼んだら、その人は自分の判断で動きます。判断の材料が少ないほど、推測の幅が広がる。推測が広がるほど、あなたの意図から外れた手を打つ。Claude Codeもまったく同じで、情報が足りない依頼は、賢いがゆえに「良かれと思って」広く手を入れます。

冒頭の事故も、Claude Codeは悪くありません。「良くして」としか言われていないので、本文を磨くついでに「不要そうなリンク」を整理した。僕がリンクを残せと書いていなかっただけです。

だから依頼文に必要なのは、文才ではなく材料です。新人にバイトを頼むときと同じ材料を、4つのブロックで渡します。

ブリーフの4ブロック

僕がいま毎回使っている型がこれです。難しい言葉はいりません。順番に意味を見ていきます。

ブロック	平易な意味	抜けると起きる事故
前提	誰のために、どこを、なぜ直すか	見当違いの場所を直す／意図とズレる
成果物	「終わった」と言える条件	どこまでやるか分からず差分が広がる
制約	触らないファイル・残すリンク	設定や収益リンクが静かに消える
確認	実行するコマンドと報告の形	動作確認なしで「できました」が返る

英語の世界では順に Context / Definition of done / Constraints / Verification と呼ばれますが、覚えなくて大丈夫です。「どこを・どこまで・何を残して・どう確かめる」——この4つを毎回書く、とだけ覚えてください。

ポイントは、4つとも1〜3行で十分なことです。長文の背景を読ませる必要はありません。むしろ短く絞るほうが、重要な指示が埋もれずに効きます。

ブロック1: 前提（どこを・誰のために・なぜ）

最初に、対象と理由をはっきりさせます。

対象: site/src/content/blog/claude-code-productive-prompt-brief.mdx の導入文とCTA周辺だけ
読者: Claude Codeを初めて触る個人開発者
なぜ: 無料PDFを読んだあと、有料テンプレートか相談へ自然に進めるようにしたい

ここで効くのは「どこを」を狭く切ることです。「導入文とCTA周辺だけ」と書けば、Claude Codeは本文全体を作り直す必要がありません。範囲が狭いと差分も小さく、レビューも一瞬で終わります。

「なぜ」を一行入れるのも地味に効きます。理由があると、Claude Codeは単なる文章の装飾ではなく、読者の次の行動に合わせた直し方を選びます。僕の体感では、この一行があるかないかで仕上がりの方向性がはっきり変わりました。

ブロック2: 成果物（どこまでで「完了」か）

ここが初心者のいちばんの落とし穴です。「読みやすくして」「SEOを強くして」は、方向としては正しい。でもClaude Codeには合否を判定できません。

判定できない依頼:

この記事をSEOに強くして、いい感じにして。終わったら教えて。

判定できる依頼:

完了条件:
- 導入の最初の3行で、読者の悩みに触れている
- descriptionは120文字以内
- 内部リンクを2本、公式ドキュメントへの外部リンクを1本入れる
- 本文の段落は3〜5行以内に収める
- 末尾に有料教材か相談への導線を1つ置く

違いは「通るか落ちるか」が分かることです。SEOと一口に言っても、キーワードを足すのか、内部リンクを増やすのか、descriptionを直すのかで作業はまるで変わります。やってほしいことを、チェックボックスに分解する。これだけで、Claude Codeが迷う余地が消えます。

完了条件は、細かく縛るためではありません。あなたとClaude Codeが「この仕事は終わったか」を同じ基準で見るためのものです。だから、自分がレビューで確認したい点を、そのまま条件に書けば十分です。

ブロック3: 制約（触らないもの・残すもの）

僕にとって、4ブロックでいちばん事故を減らしたのがここです。冒頭のリンク消失も、このブロックがあれば起きませんでした。

制約は「触らないもの」と「残すもの」を具体名で書きます。

触らない:
- frontmatter（pubDate, category, heroImage など）
- slug
- 既存のコードブロック
変更しない・残す:
- ページ末尾のGumroad教材リンク3本
- 他言語版の記事

なぜこの4種類を毎回守るのか、理由を一度だけ書いておきます。frontmatterは公開日やOGP画像を含むので、壊すとページ生成や見た目が崩れます。slugを変えると、これまで積み上げた検索評価がリセットされます。Gumroadリンクは収益の導線そのものです。コードブロックは読者がコピーして使う実用品です。どれも「消えても差分をよく見ないと気づけない」ものばかりです。

ここで一つコツがあります。禁止だけでなく、許可も書く。「余計なことをしないで」だけだと、何が余計か伝わりません。「導入とCTA周辺だけ編集してよい。それ以外は読むだけ」と、触ってよい範囲も一緒に書くと、Claude Codeの動きがぴたっと落ち着きます。

ブロック4: 確認（証拠を出させる）

最後は確認です。「できました」を信じず、証拠を出させます。

このサイトには記事品質をチェックするスクリプトがあるので、Claude Codeにそのまま実行させます。手元で動かすときはこのコマンドです。

# 変更したファイルだけを確認する
git diff --name-only

# 記事品質チェック（文字数・description・リンク・コードフェンスを機械チェック）
node scripts/check-updated-article-quality.mjs

依頼文には、この確認をやらせる指示をこう書きます。

確認:
- 上の2コマンドを実行する
- このslug由来のエラーが消えたことを報告する
- 変更したファイルと、確認したこと・できなかったことを最後に一覧で出す

Claude Code自身にコマンドを叩かせ、結果を報告させるのがポイントです。人間の記憶に頼ると、忙しい日に必ず破綻します。文字数オーバー、リンク切れ、コードフェンスの閉じ忘れは、あとから静かに見つかるものです。機械で分かることは機械に確かめさせる。これで夜中の見直しがぐっと減りました。

4ブロックを1つにつなげる: コピペできるブリーフ

ここまでの4ブロックを、そのまま貼れる形にまとめます。{ } の中だけ書き換えてClaude Codeに渡してください。

# 依頼ブリーフ（1作業ぶん）

## 前提
- 対象: { 直すファイルや範囲を1つだけ }
- 読者: { 誰のための改善か }
- なぜ: { 改善の狙いを一行で }

## 成果物（完了条件）
- { 通る／落ちるが判定できる条件を3〜5個 }
- descriptionは120文字以内
- 内部リンク2本・公式の外部リンク1本を入れる

## 制約
- 触らない: { frontmatter, slug, コードブロック など }
- 残す: { 収益リンク, 他言語版 など消えてはいけないもの }
- 編集してよいのは前提に書いた範囲だけ。それ以外は読むだけ。

## 確認
- { 実行する検証コマンド }
- 変更ファイルと、確認できたこと・できなかったことを最後に報告する

まず対象ファイルと関連箇所を読んでから、最小の差分で進めてください。
前提・成果物・制約・確認のどれかが足りなければ、編集前に最大3つまで質問してください。

最後の2行が地味に効きます。「足りなければ質問して」と添えると、Claude Codeは推測で突っ走らず、不足した材料を聞き返してくれます。完璧なブリーフを毎回書けなくても、この一文が安全網になります。

良い依頼と悪い依頼を並べてみる

同じ作業でも、依頼文でここまで変わります。

悪い依頼:

この記事をSEOに強くして、いい感じにしといて。

良い依頼:

claude-code-productive-prompt-brief.mdx の導入文とCTA周辺だけ直して。
読者はClaude Codeを初めて触る個人開発者。無料PDFのあと、有料テンプレか相談へ進めたい。
完了条件は、導入3行で悩みに触れる/descriptionは120字以内/内部リンク2本と外部公式1本。
frontmatter・slug・コードブロック・末尾のGumroadリンク3本は触らないで。
最後に node scripts/check-updated-article-quality.mjs を実行して、このslugのエラーが消えたか報告して。

長く見えますが、書くのは1分です。この1分で、本文全体の作り直しと、リンク消失の事故と、「良くなった気がするけど何か変」というレビューの迷いが、まとめて消えます。書くより消すコストのほうが、いつも高くつきます。

僕がやらかした3つの失敗

正直に書きます。4ブロックにたどり着くまで、同じ失敗を何度もやりました。

1つ目は、「全部やって」と頼んだこと。「記事を全部読みやすくして」と投げたら、10記事ぶんの差分が返ってきて、レビューに半日かかりました。今は1依頼=1ファイルに切っています。範囲を小さくするほど、失敗しても戻すのが一瞬です。

2つ目は、制約を書かなかったこと。冒頭のリンク消失がこれです。「触らない・残す」を2行足すだけで防げたのに、それを惜しんで30分のリカバリーをやりました。今はブリーフを書くとき、まず制約から埋めます。

3つ目は、確認を自分の目だけに頼ったこと。「最後に僕がチェックすればいい」は、忙しい日に必ず飛びます。検証コマンドをClaude Codeに実行させる一行を入れてからは、descriptionの文字数超過もコードフェンスの閉じ忘れも、公開前に止まるようになりました。

よくある質問

Q. ブリーフが長くなりすぎませんか？ A. 4ブロックとも1〜3行で十分です。長い背景説明はかえって逆効果で、重要な指示が埋もれます。迷ったら「前提・成果物・制約・確認」を各1行ずつ、まず最小で書いてください。

Q. 毎回4つ全部書くのは面倒です。最低限ならどれ？ A. 「対象（前提）」「制約」「確認」の3つです。この3つがあればClaude Codeは残りを質問で埋められます。逆にこの3つがないと、差分の正しさをあとから説明できなくなります。

Q. 5つの型や作業契約の記事と何が違うの？ A. プロンプト入門 は複数のタスク種別に効く5つの型、高度プロンプト設計 はチームで再利用するファイル化の話です。本記事は「1つの作業を頼むその場の依頼文」に絞った、いちばん手前の入口です。

Q. Claude Codeが勝手に範囲外まで直すのを完全に止められますか？ A. 100%ではありませんが、制約で「編集してよいのは○○だけ、それ以外は読むだけ」と許可範囲を明示すると、かなり落ち着きます。心配な作業は「まず計画だけ出して、編集しないで」と分けるのが確実です。

Q. 確認コマンドが手元にない場合は？ A. git diff --name-only で変更ファイルだけでも報告させると効果があります。最低限「何を変えたか」をClaude Code自身に言語化させるだけで、想定外の差分に気づけます。

実際に試した結果

冒頭のリンク消失以来、僕は依頼を出す前に必ず制約ブロックから書くようになりました。「触らない・残す」を2行入れただけで、収益リンクや設定が消える事故はゼロになっています。

成果物をチェックボックスに分解してからは、「良くして」と投げて広い差分にがっかりする、ということもなくなりました。そして確認の一行を足したら、文字数オーバーやリンク切れが公開前に止まる。賢いプロンプトを探すより、4つの材料を毎回そろえるほうが、ずっと速くて安全でした。

このブリーフを使う前に、まず日々のコマンドを 無料Claude Codeチートシート で確認してください。同じ依頼を何度も書くようになったら 50個のClaude Codeプロンプトテンプレート で型を増やすのが早いです。チーム導入や権限設計、収益導線の保護まで絡むなら 導入相談 のほうが近道な場面もあります。教材の一覧は 商品一覧 にまとめています。