「昨日と同じように頼んだのに、今日は3回も出し直しになった」。Claude Codeを触り始めた人から、この話をよく聞きます。
依頼文そのものは、前回とそう変わっていません。それでも返ってきたものが的を外していて、指示を書き直すことになります。手の速い相手ほど、ずれたまま進んだときに戻す作業が増えます。
この記事は、その差がどこで生まれるのかを、依頼文の分解・完了条件・停止基準という4つの要素に分けて整理します。素材は公式ドキュメント5件と、運営元WEBMARKSで実際に起きた事故の記録です。
検証環境：claude-opus-5 / Claude Code v2.1.x / macOS 15 / 2026-08-02検証
こんなふうに調べていませんか
- 同じような依頼なのに、うまくいく日といかない日があって理由が分からない
- 「良い感じにして」以外の頼み方が思いつかず、毎回自分で確認し直している
- 途中で止まってほしい場所があるのに、どう書けば伝わるのか分からない
この記事を読み終えたときに手に入るもの
- 手戻りが出た指示と通った指示の差を、4つの要素に切り分けて説明できるようになります
- 完了条件を、機械が合否を出せる形へ書き直せるようになります
- 停止基準をプロンプトに書く場面と、別の仕組みへ渡す場面を選び分けられるようになります
結論30秒でわかる、この記事の結論
- 依頼文の出来を決めるのは、文章のうまさではありません。Claude Codeに埋めさせている空欄の数です。
- 空欄は4つあります。目的・対象範囲、段階への分解、完了条件、停止基準。
- 停止基準だけは、依頼文に書くだけでは足りない場面があります。
進行役は3人です。若葉さんが言葉の側から聞き、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。
01Claude Codeのプロンプトの書き方で、AIエージェントの手戻りはなぜ増えるんですか？
若葉さんプロンプトが下手だと手戻りが増える、とよく聞きます。これは文章力の話なんでしょうか。
鈴木さんそこはあまり関係ないと思っています。引っ越しの見積もりに近くて、荷物の量と行き先を伝えていないと、来た人がその場で判断するしかないんですよね。判断そのものは速いんですが、こちらの想定と違えば運び直しになります。
Claude Code公式ドキュメントは、Claudeが意図を推測することはできても、考えを読み取ることはできないと述べています。参照するファイルや制約をプロンプトに渡すほど、修正の回数は減るとも説明しています（出典: Claude Code公式ドキュメント）。
結論は3点です。
- 手戻りが出るプロンプトは、目的・対象範囲・完了条件のどれかを、Claude Codeの解釈に委ねたまま渡しています。
- 通るプロンプトは、依頼文を「目的・対象範囲」「段階への分解」「完了条件」「停止基準」の4つに分けて書いています。
- 停止基準は1段階ではありません。プロンプトに書く、セッション条件にする、フックで縛る、別の担当に確認させる、の4段階から選びます。
02同じ依頼でもプロンプトの結果が変わるのは、AIエージェントが何を自分で埋めるからですか？
Claude Code公式ドキュメントは、Claude Codeの動作を、文脈収集・実行・検証という3段階が混ざり合うループだと説明しています。1つの質問が文脈収集だけで終わることもあれば、1つのプロンプトで3段階を何度も回すこともあります（出典: Claude Code公式ドキュメント）。
目的や対象範囲を書かないと、Claude Codeは文脈収集の段階で自分なりの解釈を選びます。その解釈が依頼者の意図とずれていた場合、実行段階まで進んでから、ようやくずれに気づくことになります。
やっかいなのは、あいまいさが残っていてもClaude Codeは止まらない点です。公式ドキュメントも、あいまいなプロンプトはそのまま動くが、その分だけ後で軌道修正する回数が増えると述べています（出典: Claude Code公式ドキュメント）。
並べてみると、4つが同じ場所で効いているわけではないと分かります。書き忘れた要素ごとに、崩れる場所が違うということです。
だから、手戻りの出方から原因を逆算できます。方向がずれるなら入口の欄が、進みすぎるなら手前の欄が、終わりが判定できないなら出口の欄が空いています。
会話が長くなるほど古い指示が埋もれる問題は、Claude Codeのコンテキスト管理｜指示がぶれない3つの手で扱いました。この記事が見るのは、その手前にある最初の1通です。
この章のまとめ
手戻りの出方は、原因の在りかを指しています。犯人捜しではなく、空欄探しをします。
03手戻りが出るプロンプトと通るプロンプトは、AI活用の現場で何が違うんですか？
Claude Code公式ドキュメントは、具体的なプロンプトとあいまいなプロンプトの対を7パターン示しています。このうち検証条件・対象範囲・症状のどれかを具体化した3パターンが、この記事の主題と重なります（出典: Claude Code公式ドキュメント）。
| 欠けやすい要素 | 手戻りが出る書き方 | 通る書き方 |
|---|---|---|
| 検証条件 | 「メールアドレスを検証する関数を実装して」 | 「validateEmailを実装して。テストケースはuser@example.comがtrue、invalidがfalse、user@.comがfalseとする。実装後にテストを実行して」 |
| 対象範囲 | 「foo.pyにテストを足して」 | 「foo.pyに、ユーザーがログアウトした状態のエッジケースをカバーするテストを書いて。モックは使わない」 |
| 症状の具体性 | 「ログインのバグを直して」 | 「セッションタイムアウト後にログインが失敗すると報告が来ている。src/auth/の認証フロー、特にトークン更新まわりを確認して。再現する失敗テストを先に書いてから直して」 |
（出典: Claude Code公式ドキュメント）
3つに共通するのは、具体化した対象が検証条件・範囲・症状のどれかであって、実装の手順そのものではないことです。
同じ公式ドキュメントは、実装の手順まで事細かに指定することを勧めていません。任せるのは実装の細部で、書くべきなのは目的・制約・確認方法だと説明しています（出典: Claude Code公式ドキュメント）。
長く書けば通る、という話ではありません。増やした分が段取りの指定なら、相手が自分で考えられる幅を削っただけになります。
なお、差分を一文で言い表せるような小さな修正まで、毎回3つをそろえる必要はありません。公式ドキュメントも、そのような修正はそのままプロンプトにしてよいとしています（出典: Claude Code公式ドキュメント）。
この章のまとめ
足りないのは文章量ではありません。検証条件・範囲・症状のどれが空欄かを見ます。
04Claude Codeのプロンプトの書き方は、AI社員へ渡す依頼文をどう分解するんですか？
高梨課長分解すると言われても、どこで切ればいいのか分かりません。
鈴木さん料理の段取りと同じ切り方でよいと思っています。材料を確かめる、作る順番を見せる、作る、味を見る。この4つに分けて、それぞれ何をもって終わりとするかを添えるだけです。
高梨課長毎回そこまで書くんでしょうか。
鈴木さんいえ、一言で言える直しはそのまま頼みます。分けるのは、複数のファイルにまたがるときや、見慣れないコードを触るときですね。
Anthropicは、タスクを段階に分解し、各段階の結果を次へ渡す前に検証する「プロンプトチェイニング」という設計パターンを紹介しています（出典: Anthropic公式）。複数回のAI呼び出しを前提にした手法ですが、1回のプロンプトの中でも考え方は同じです。
Claude Code公式ドキュメントは、複雑な変更ほど、調べる・計画を見せる・実装する・確定する、の4段階に分けるよう勧めています（出典: Claude Code公式ドキュメント）。
①目的・対象範囲：〈達成したい状態を1文で。触ってよい／触ってはいけない範囲を添える〉
②段階への分解：〈調べる→計画を見せる→実装する→確定する、のように段階を分ける〉
③完了条件：〈各段階、または全体が終わったと判定する基準〉
④停止基準：〈ここから先は人に確認してから続ける境界〉4つの要素が埋める空欄と、書かないときに起きることは次のとおりです。
| 要素 | 書く内容 | 書かないとどうなるか |
|---|---|---|
| ①目的・対象範囲 | 達成したい状態と、触ってよい／触ってはいけない範囲 | 権限の強さではなく範囲の未宣言が、記事3本の上書き事故につながった（2026-07-24） |
| ②段階への分解 | 調べる→計画→実装→確定、のように作業を段階に分ける | Claude Codeが選んだ順序で一気に進み、違っていたときの手戻りが大きくなる |
| ③完了条件 | テスト・数値・チェックリストなど、合否を判定できる基準 | 「終わったように見える」ことだけが判断材料になる（出典: Claude Code公式ドキュメント） |
| ④停止基準 | どこから先は人に確認してから続けるか | 意図しない書き込みや送信まで進むことがある |
②はplan mode（実装の前に計画だけを見せるモード）と相性の良い要素です。調べる段階と計画を見せる段階までをplan modeで進め、承認してから実装へ移せます（出典: Claude Code公式ドキュメント）。
05完了条件をプロンプトへ書き込むと、AIエージェントの動きは何が変わるんですか？
高梨課長完了条件というのは、「テストを通して」と書けばいいのでしょうか。
鈴木さんそれで足りる場面は多いです。大事なのは、Claude Code自身が実行できる形かどうかですね。人にしか判定できない条件を書くと、結局こちらへ戻ってきます。
公式ドキュメントは、Claude Code自身が実行できる確認を渡すよう勧めています。挙がっている例は、テストやビルド、差分をfixture（期待する結果の見本）と比較するスクリプト、スクリーンショットの比較です（出典: Claude Code公式ドキュメント）。
確認を渡さなければ、「終わったように見える」ことだけが唯一の判断材料になります。確認を渡すと、Claude Codeは実行・確認・合否判定・やり直しを自分で回せます（出典: Claude Code公式ドキュメント）。
機械的に判定できる形は、主に次の4つです。
- テストを実行して、通過するかを見る
- ビルドやlintを実行して、終了コードを見る
- 出力をfixtureと比較する
- スクリーンショットを撮って、意図したデザインと比較する
分かれ目は、確認する手間がどちら側に積み上がるかです。渡す確認が実行できる形になっていれば、こちらの手元に残るのは根拠を読む時間だけになります。
無人で走る場面では、完了条件を書かないと詰みます。スケジュール実行では、成功の定義と結果の扱いを明示しないと、Claude Codeは実行中に質問できません（出典: Claude Code公式ドキュメント）。
公式ドキュメントは、合格したと言わせるのではなく、テスト結果や実行コマンドなど根拠を見せてもらうことも勧めています。根拠を確認するほうが、人が毎回ゼロから採点し直すより早く終わります（出典: Claude Code公式ドキュメント）。
この記事自体の完了条件も、プロンプトではなく品質ラインの側に書いてあります。独立ファクトチェック・機械検証・批評という3つの確認を順に通過したかどうかで判定しています。自己検証を組み込む型は、Claude Codeの自己検証｜完了報告を証拠に変える3つの型にまとめました。
この章のまとめ
完了条件は、書いたかどうかではなく、相手が自分で回せる形かどうかで効き目が変わります。
06止まってほしい地点は、生成AIのプロンプトのどこに書けばいいんですか？
公式ドキュメントは、完了条件を用意したあと、それをどこまで厳格に守らせるかを4段階に分けて説明しています（出典: Claude Code公式ドキュメント）。
| 段階 | プロンプトでどう書くか | 向いている場面 | 対応する公式機能 |
|---|---|---|---|
| ①その場で確認 | 「実装したらテストを実行し、通るまで直して」と1回のプロンプトに含める | 短時間で終わる作業 | 通常のプロンプト内指示 |
| ②セッション全体で監視 | 完了条件を目標として設定し、別の評価者に毎ターン確認させる | セッションをまたいで続く作業 | /goal条件 |
| ③機械的に止める | 確認スクリプトが通るまでターンを終わらせない | 無人で走らせる作業 | Stopフック |
| ④別の視点で確認する | 実装した本人とは別のセッションに、差分だけを見せて確認させる | 見落としが心配な作業 | 検証用サブエージェント |
Stopフックは、確認スクリプトを実行し、合格するまでターンの終了をブロックできます。ただし8回連続でブロックすると、Claude Codeは自動でターンを終わらせます（出典: Claude Code公式ドキュメント）。無限に足止めする仕組みではありません。
07プロンプトへ書いた停止基準だけで、AIエージェントは止まりきるんですか？
段を上がるほど、書く場所が依頼文の外へ出ていきます。①は文章の中に収まりますが、③は設定ファイル、④は別セッションの手配になります。
言い換えると、止める力を強くするとは、言い方を強めることではありません。書く場所を移していく作業です。
どのイベントに何を仕込むかは、Claude Code hooksの一覧｜30種類から選ぶ2つの軸にまとめています。送信・公開・削除を人が止める全社的な設計は、AIエージェントの承認ゲート｜止める操作4種と3層の選び方を参照してください。
08停止基準を書かないプロンプトでAIエージェントを走らせると、実際どうなったんですか？
高梨課長実際に何か起きた例はありますか。書いていないと、どのくらい困るのかを知りたいです。
鈴木さん2件あります。どちらも権限を強く与えすぎた話ではなく、書いていなかった話でした。読み返すと決まりが悪いのですが、残しています。
2026-07-28 11:13、調査だけを目的にしたサブエージェントが、指示していないSVGファイルを生成しました。生成物は5,333バイトで、タイトルと説明文つきの図解として体裁が整っていました。
プロンプトには「読んで返すだけ」という前提はありました。ただし「ファイルを作らない」という停止基準は書かれていませんでした。内容を検証したうえで採用しましたが、調査系のプロンプトには禁止操作を明記する運用を追加しています。
09対象範囲をプロンプトに書かずにAI社員を並行させると、何が起きるんですか？
2026-07-24 22時07分から22時27分にかけては、別の事故が起きました。30分ごとに動く監視プロセスと、本体セッションの実働レーンが、同じ記事ファイルへ同時に書き込みました。当事者は両方ともAIです。
原因は権限の強さではなく、どの範囲を誰が担当するかを先に宣言していなかったことでした。対策として、着手前に担当範囲を宣言するファイルを置き、宣言のない範囲には手を付けない運用にしています。
| 事故 | 発生 | プロンプトに欠けていたもの | 結果 |
|---|---|---|---|
| 想定外のSVG書き込み | 2026-07-28 11:13 | 停止基準（禁止操作の明記） | 5,333バイトのSVGファイルを指示なく生成した |
| 記事の並行上書き | 2026-07-24 22:07〜22:27 | 対象範囲（担当範囲の宣言） | 記事3本（AIOM-032・033・035）が上書きされた |
2件を置いてみると、同じ区画に入ります。どちらも、やってはいけないことを書いていなかった側の失敗でした。
書き忘れは、書き間違いより気づきにくい性質があります。書いた文は読み返せば目に入りますが、書かなかった文はどこにも表示されないからです。
10プロンプトの落とし穴は、AI導入のどこでつまずきやすいんですか？
- 完了条件を「良い感じにして」で済ませる：Claude Codeは「終わったように見える」ことだけを頼りに終了します。確認は結局、こちらの仕事として戻ってきます（出典: Claude Code公式ドキュメント）。
- 止める条件を、目的とずれた代理指標で書く：WEBMARKSには、更新時刻を判定材料にしたゲートがありました。他セッションの成果物を誤って対象と判定し、3日間で233回発火した記録があります（2026-07-10、社内タスク台帳）。止める基準にも同じ罠があります。
- 対象範囲を宣言せず並行して走らせる：2026-07-24、監視プロセスと本体セッションが担当範囲を宣言せずに動き、記事3本が上書きされました。
- 実装の手順まで事細かに指定する：目的・対象範囲・完了条件・停止基準を書けば足りる場面があります。そこで手順まで指定すると、Claude Codeが自分で判断する余地を削ります（出典: Claude Code公式ドキュメント）。
- 同じ問題を2回訂正しても、同じプロンプトで押し切る：公式ドキュメントは、2回訂正したら
/clearで仕切り直すよう勧めています。学んだことを踏まえて、プロンプトを書き直します（出典: Claude Code公式ドキュメント）。
5つを並べると、失敗の向きが2つに分かれます。1と4は、書く量を取り違えた失敗です。2・3・5は、書く場所や書き直す機会を取り違えた失敗です。
11書いたプロンプトは、AIエージェントに渡す前にどこを点検すればいいんですか？
渡す直前に見るのは、次の9項目です。
- 目的を1文で書いたか
- 触ってよい範囲／触ってはいけない範囲を書いたか
- 複雑な依頼は、調べる→計画→実装→確定の段階に分けたか
- 完了条件を、テスト・数値・チェックリストなど機械的に判定できる形で書いたか
- 止まってほしい地点（停止基準）を書いたか
- 手順そのものより、目的と確認方法を優先して書いたか
- 小さな修正まで4つをフルに書いていないか
- 無人実行・スケジュール実行では、成功の定義と結果の扱いを明示したか
- 止める条件が、目的とずれた代理指標になっていないか
9項目のうち、7番目だけ向きが逆になっています。ほかは「書いたか」を聞いていますが、7番目は「書きすぎていないか」を聞いています。
点検の狙いは、完璧な依頼文を作ることではありません。渡したあとに自分の手元へ戻ってくる作業を減らすことです。
この章のまとめ
点検は、書き足すためではなく、戻ってくる作業を減らすために行います。
12エージェントに任せる範囲と、プロンプトの4要素はどうつながるんですか？
若葉さん書き方は分かってきました。でも、そもそも何を頼んでいいのかが分かりません。
鈴木さん順番としては、任せる範囲を決めるほうが先です。範囲が決まっていない状態で依頼文だけ整えても、書ける中身が出てきません。
若葉さん範囲は誰が決めるんでしょうか。
鈴木さん依頼する側です。そこはAIに渡せない部分だと思っています。
Claude Codeを業務のどこまで任せるかは、Claude Codeの業務活用｜任せる仕事の地図と判断軸4つで整理しました。この記事はその中でも、任せると決めたあとの依頼文に絞っています。
4つのうち①目的・対象範囲は、任せる範囲の決定をそのまま書き写す欄です。決まっていれば書けますし、決まっていなければ書けません。書けないという事実が、まだ決まっていないことを教えてくれます。
停止基準も同じです。どこから先を人が確定させるかは、依頼文を書く場面ではなく、業務の設計として先に決めておくものです。プロンプトは、その決定を運ぶ乗り物にあたります。
対応させてみると、欄の並びは書き方の都合ではないと分かります。先に決まっているはずのことが、そのまま欄の並びになっています。
だから、書き方だけを練習しても、任せる範囲があいまいなままなら手戻りは減りません。書き方の前に、決めごとがあります。
この章のまとめ
依頼文は、決まっていることを運ぶ器です。器を磨いても、中身は増えません。
13よくある質問
プロンプトは毎回4つの要素をフルに書く必要がありますか
必要はありません。差分を一文で言い表せる小さな修正は、そのまま依頼して構いません（出典: Claude Code公式ドキュメント）。4つが効くのは、対象が複数ファイルにまたがる場面や、見慣れないコードを触る場面です。短い依頼にまで型を当てはめると、書く手間だけが増えていきます。
完了条件が数値化できない依頼はどうすればよいですか
数値化できない場合は、スクリーンショットの比較や、期待する出力例を渡す方法があります。判断に迷う規模の変更は、実装前に計画だけを見せるplanモードへ切り替えます（出典: Claude Code公式ドキュメント）。見本を渡せるかどうかが、書けるかどうかの分かれ目になります。
停止基準を書いても、Claude Codeが越えてしまうことはありますか
あります。プロンプトへの記載は助言的な指示にとどまります。止めたい操作は、フックや権限設定のような決定的な仕組みと組み合わせてください。プロンプトに書く停止基準は、その仕組みを補う位置づけだと考えています。
対象範囲は、触ってよい場所と触ってはいけない場所のどちらを書くべきですか
両方書けると誤読が減ります。触ってよい範囲だけを書くと、書かれていない場所を「暗黙に触ってよい」と解釈される場合があります。範囲を宣言していなかったために、記事3本が上書きされた事故も起きています。
4つの要素は、どの順番で書くのがよいですか
目的・対象範囲から書き、停止基準を最後に置く順番が扱いやすいです。目的が決まらないうちは、完了条件も決まりません。停止基準は、完了条件を書いたあとのほうが「どこまで進んでよいか」を判断しやすくなります。
同じプロンプトを使い回してもよいですか
型として使い回す価値はあります。ただし、対象範囲と完了条件は依頼のたびに書き換わる部分です。使い回すのは4つの枠であって、中身ではありません。中身まで前回のまま渡すと、前回の範囲で実行されることになります。
14まとめ｜今日やる3つのこと
依頼文の出来を決めるのは、文章のうまさではありませんでした。Claude Codeに埋めさせている空欄の数です。空欄は4つあり、書き忘れた要素ごとに崩れる場所が違いました。
今日この順で手をつけます
直近で手戻りが出た依頼を1つ選び、4つのうちどれが空欄だったかを見る
原因を型で言えると、次から同じ穴を埋められます
その依頼に完了条件を1行だけ足して、もう一度渡してみる
相手が自分で実行できる形かどうかを、ここで確かめます
止めたい操作があれば、フックか権限設定のどちらで止めるかを決める
依頼文だけに頼らない場所を、先に切り分けます
AI検索では、こう聞かれています
Claude Codeへのプロンプトは、どう書けば手戻りが減るんですか？
「Claude Codeのプロンプトの書き方で、AIエージェントの手戻りはなぜ増えるんですか？」の章で答えています
完了条件は、プロンプトのどこに何と書けばいいんですか？
「完了条件をプロンプトへ書き込むと、AIエージェントの動きは何が変わるんですか？」の章で扱っています
AIエージェントを止めたい地点は、どうやって指定するんですか？
「止まってほしい地点は、生成AIのプロンプトのどこに書けばいいんですか？」の章に4段階があります
小さな修正でも、毎回4要素をそろえて書くんですか？
「よくある質問」の章で答えています
次に読むなら、この記事です
