「この修正、Claude Codeに頼んだらまた違うところまで触られて戻ってきた」「指示は通ったように見えるのに、結局自分で書き直している」。Claude Code を使い始めたチームから、最近よく聞く声です。便利なはずが、依頼の往復が増えてレビューに時間が取られ、いつの間にか「自分でやった方が早い」に戻ってしまう。
その原因の多くは、AIの能力ではなく依頼の書き方にあります。本記事では、Claude Code への指示で手戻りが続く現場の典型例から出発し、依頼を「目的・制約・出力形式・反証条件」の4要素に分解して書き直す型を整理しました。この記事を読めば、明日からすぐに使える依頼の型が身につきます。
よくある「曖昧な指示」の現場
あるPMが、認証まわりのリファクタを依頼したとします。指示は「ログイン処理を整理しておいて」。Claude Code は素直にコードを書き換えますが、返ってきたのは関数名が変わり、エラーハンドリングのスタイルまで全面的に書き換えられたコードでした。テストは通る。でも、レビュアーは「なぜここまで触ったのか」を読み解くのに30分かかります。
別の場面では、リーダーが「不要なログを消して」と頼みます。すると、デバッグ用ログだけでなく運用監視で必要なログまで削られて返ってきます。Claude Code に悪気はありません。「不要」の定義が共有されていないだけです。
これらに共通するのは、依頼者が「自分の頭の中にある前提」を書いていない、という点です。人間同士なら「いや、そこまでは触らないでよ」と言えば伝わります。しかしAIは書かれていない前提を空気で読みません。むしろ、書かれていない部分を「自由度」として広く解釈します。これは、要件が固まらないまま開発に入って手戻りが発生するのと、構造はまったく同じです。
なぜ Claude Code への指示は曖昧になるのか
依頼が曖昧になる理由は、大きく3つあります。
ひとつは、依頼者自身が「何をしたいか」を言語化しきれていないこと。頭の中では「読みやすくしたい」と思っていても、読みやすさの基準が定まっていないので、AIに丸投げしてしまいます。
ふたつめは、「やってほしくないこと」を書く習慣がないこと。人に頼むときは「ここは触らないで」と自然に添えるのに、AIへの依頼ではポジティブな指示だけを書きがちです。AIは禁止事項が書かれない限り、自由に動いてよいと判断します。
3つめは、「出来上がりの形」を共有していないこと。差分だけ欲しいのか、ファイル全体を再掲してほしいのか、コミットメッセージ案も欲しいのか。これらが指示に入っていないと、毎回違う粒度の出力が返ってきます。
つまり Claude Code に必要なのは、もっと賢いプロンプトの言い回しではなく、依頼そのものの構造です。
依頼を4要素に分解する
Claude Code への依頼は、以下の4要素で書き直すと安定します。
- 目的（なぜそれをするのか）
- 制約（やってよいこと・やってはいけないこと）
- 出力形式（何が、どんな形で返ってきてほしいか）
- 反証条件（どういう状態だったら失敗とみなすか）
目的：なぜそれをするのかを1行で書く
「ログイン処理を整理して」では目的が抜けています。整理する理由が「新人がコードを読みやすくするため」「テストを書きやすくするため」「セキュリティ監査で指摘されたため」のどれかで、最適な書き直しは変わります。
目的は依頼の最初に1〜2行で書きます。「新人エンジニアがログイン処理の流れを5分で把握できる状態にしたい」と書くだけで、AIは関数名や責務分割の方向性を、その目的に沿って選んでくれます。
制約：触ってよい範囲と触ってはいけない範囲を明示する
制約は、PMが普段「線引き」と呼んでいるものに近いです。受託開発で追加要望をどう扱うかと同じで、AIへの依頼でも「どこまでが今回のスコープか」を先に決めます。
具体例は次のとおりです。
- 触ってよいファイル：
src/auth/login.tsのみ - 触ってはいけない箇所：エラーメッセージ文言、ログ出力フォーマット
- 守るべき外部仕様：
POST /api/loginのリクエスト・レスポンス形式
これは、追加要望で納期崩壊する前に｜受託PMの線引き合意フレームで扱っているスコープ判定の考え方を、AI依頼に持ち込んだものです。人に対して線引きできるPMは、AIに対しても線引きできます。
出力形式：差分か、全文か、説明付きか
出力形式は、レビュー側のコストに直結します。差分だけ欲しいのに全文が返ってくると目視比較が増え、逆に全文が必要なときに差分だけ返ってくると適用が手間です。
指定例は次のようなものです。
- 修正後のコードを「変更箇所のみ」 unified diff 形式で
- 変更点ごとに「なぜそう変えたか」を1行で添える
- 影響を受けるテストケースの一覧を末尾に箇条書きで
レビューフローに合わせて、必要な粒度で指定します。たとえばGitHub上でのコードレビューが中心のチームなら差分形式が向いていますし、ペアプロ的に対話しながら進めるなら全文と説明をセットで返してもらう方が早いはずです。
反証条件：どういう結果なら「失敗」とみなすか
4要素のなかで最も抜けやすいのが反証条件です。これは「テストの合格基準」「受入基準」に近い概念で、AIにとっては自分の出力をセルフレビューする基準になります。
たとえば次のように書きます。
- 既存のテストが落ちたら失敗
- ログイン処理のレスポンス形式が変わっていたら失敗
- 関数の責務が増えて1ファイル200行を超えたら失敗
反証条件があるだけで、Claude Code は出力前に自分でチェックします。結果として、レビュアーが見つけるはずだった問題のかなりの部分が、依頼の段階で潰れます。受入基準の考え方は受入基準とリリース延期を止める品質ゲート設計の実務でも整理しています。
Before / After で書き直してみる
Before（曖昧な指示）
ログイン処理をリファクタしておいて。読みやすくしてくれればいい。
これだと、関数名・ファイル分割・エラーハンドリング・ログ出力まで、すべてAIの裁量で動きます。返ってきたコードのどこをレビューすべきかも分かりません。
After（4要素で書き直し）
【目的】新人エンジニアが
login.tsを読んだとき、5分で処理の流れを追える状態にしたい。【制約】
- 触ってよいファイル：
src/auth/login.tsのみ- 関数名の変更は可。ただし
loginUserという公開関数名は維持- エラーメッセージ文言・ログ出力フォーマットは変更しない
POST /api/loginの入出力スキーマは変更しない【出力形式】
- 修正後の
login.ts全文- 末尾に「変更点」を箇条書きで5行以内
【反証条件】
- 既存テスト（
login.test.ts）がすべて通ること- 1関数あたりの行数が30行を超える場合は分割の根拠を添える
- 既存の公開関数シグネチャが変わっていたら失敗
After で依頼を出すと、Claude Code は範囲外を触らず、レビューしやすい粒度で返してきます。重要なのは、これは特別なプロンプトテクニックではなく、PMが人に依頼するときの当たり前を書き起こしただけ、という点です。
チームで「依頼の型」を運用する
個人の工夫で終わらせず、チームの再現性に変えるためのコツを3つ挙げます。
ひとつは、4要素のテンプレートをリポジトリ内に置いてしまうことです。docs/ai-request-template.md のような形で、目的・制約・出力形式・反証条件の見出しだけ書かれた雛形を用意し、依頼するときはそれを埋めるだけにします。
<!-- docs/ai-request-template.md -->
## 【目的】
<!-- なぜこの作業をするのかを1〜2文で書く -->
## 【制約】
<!-- 触ってよいファイル・ディレクトリ -->
- 対象:
<!-- 触ってはいけない箇所・守るべき外部仕様 -->
- 変更禁止:
<!-- プロジェクト固有の前提（命名規則・APIスキーマ等） -->
- 前提:
## 【出力形式】
<!-- 差分のみ / ファイル全文 / コミットメッセージ案付き 等 -->
## 【反証条件】
<!-- どういう結果なら「失敗」とみなすか。客観的に確認できる条件で書く -->
- 失敗:「制約あるある」を最初から書き込んでおくのがポイントです。「命名規則は変えない」「マイグレーションは別PR」など、何度も書く制約はテンプレートに最初から書き込んでおきます。
3つめは、レビュー時に「依頼文も一緒にレビューする」習慣をつけることです。出力が悪かったとき、AIではなく依頼文を直す視点を持てると、改善が積み上がります。これは停滞プロジェクトが動く！PMのためのAI活用プロンプト術で扱っているプロンプト改善の考え方とも共通します。
よくある失敗
- 制約を書きすぎて、AIの裁量がゼロになる：制約は重要な3〜5項目に絞ります。すべての可能性を潰そうとすると、依頼文がコードの設計書になり、結局自分で書いた方が早くなります。
- 反証条件を「曖昧な品質」で書く：「読みやすいこと」「保守性が高いこと」では検証できません。テストが通る、行数が一定以下、公開APIが変わらない、など客観的に確認できる条件にします。
- 4要素を毎回フルセットで書こうとする：小さな修正には、目的1行＋制約1行＋出力形式1行で十分です。型は守りつつ、粒度は調整してください。
まとめ
Claude Code に振り回されないために必要なのは、AIに賢くなってもらうことではなく、依頼者の側で「目的・制約・出力形式・反証条件」を言語化することです。これはプロンプトエンジニアリングの特別な技術ではなく、PMが普段の業務で行っている要件整理・線引き・受入基準設定の延長線上にある、ごく自然なスキルです。
逆に言えば、AIへの依頼が曖昧なままだと、人への依頼も曖昧なままになっている可能性が高いです。AI依頼の型を整えることは、チームの依頼設計そのものを鍛え直すきっかけにもなります。
体系的に AI を業務文書・PM運用へ適用する流れまで学びたい方は、生成AIの実践コースを用意しています。
- 仕様書・報告書・議事録など、文書業務に AI を組み込みたい方は【生成AI実践】仕様書・報告書・議事録を半分の時間で仕上げる技術
- 進捗・課題・リスク管理にまで AI を運用設計として広げたい方は【生成AI実践】進捗・課題・リスク管理をAIで加速する運用設計
明日の依頼から、まず1件だけでも「目的・制約・出力形式・反証条件」で書き直してみてください。返ってくる出力の質が変わるはずです。