Claude Code で詰まる人の多くは、指示が雑だからではない。終わり方が曖昧だから詰まるのだ。
どこから始めるか、何が終わりか、終わったとみなす条件は何か。ここを先に固定しておかないと、Claude Code はそれなりに動くのに、最後に「で、これで完了なのか？」という微妙な空気が残る。人間のほうも迷うし、再依頼でコンテキストを無駄にする。地味だが、これが一番だるい。
この話をするときは、開始条件、完了条件、着地条件の3つを分けて考えるといい。入口は「何を見て作業を始めるか」、出口は「何をもって終わりにするか」、着地条件は「終わったあとにどの形で返すか」だ。名前は違っても、やることは同じである。
たとえば「README を直して」とだけ投げると、Claude Code は古い説明を直すのか、足りない章を足すのか、文体を整えるのか、判断に幅が出る。結果として、修正の方向がブレる。逆に、入口と出口を明示すると、作業が急に締まる。差分が小さくなるし、戻りも減る。筆者は最初、ここを甘く見て、文章修正を何度も往復した。悪いのは Claude Code ではなく、こっちの終点設計だった。
たとえば文書作成なら、こう書く。
このフォルダ内の README.md を確認して、次の条件で修正してください。
開始条件:
- 既存の見出し構成と語り口を読み取ること
- 外部資料は使わず、このリポジトリ内の情報だけを使うこと
作業内容:
- 料金説明が曖昧な箇所を直す
- 手順の順番を実行しやすい形に並べ替える
- 冗長な説明を削る
完了条件:
- 初見の人が手順をそのまま追える
- 古い表現が残っていない
- 変更した箇所を最後に要約する
着地条件:
- 変更内容を箇条書きで3点以内にまとめる
- 迷った点があれば、どこで判断したかも書く
これだけで、終わり方がかなり安定する。Claude Code に「何を終わりとするか」を与えているからだ。単に「直して」だと、修正は進んでも完了判定が人によってズレる。そこが手戻りの温床になる。
開発作業でも同じだ。コード修正を頼むなら、完了条件は「テストが通ること」だけでは足りないことがある。たとえば、既存の挙動を壊さない、差分を広げすぎない、関連ファイルに説明コメントを残す、などを着地条件に入れておくといい。
src/ 配下の検索処理を調整してください。
開始条件:
- search.ts とその周辺だけを先に読む
- 既存のテストがあれば確認する
完了条件:
- 検索結果の並び順が仕様どおりになる
- 既存テストが壊れない
- 必要ならテストを追加する
着地条件:
- 何を変更したかを短く説明する
- 追加したテストがあれば、その意図も書く
ここで大事なのは、入口と出口を「作業の中」に埋め込むことだ。あとから口頭で補うと、すぐに抜ける。Claude Code は文脈を読んで動くが、曖昧さまで自動で補完してくれる道具ではない。そこを期待すると痛い目を見る。
ファイル整理やディスク削減でも、この考え方はそのまま使える。非エンジニアでも効く。むしろこちらのほうが効く。たとえば「重複ファイルを整理して」とだけ言うと、見つかったものをどう扱うかで迷う。削除なのか、退避なのか、一覧化だけなのかが曖昧だからだ。入口と出口を決めれば、かなり安全になる。
このフォルダ内の重複ファイルを調べてください。
開始条件:
- 対象は Downloads フォルダ内に限る
- 画像と PDF だけを見る
完了条件:
- 完全に同じ内容の重複候補を一覧にする
- どれを残すべきか判断材料を示す
- 削除はしない
着地条件:
- 画面にそのまま貼れる形で一覧を出す
- サイズと更新日も添える
こうしておくと、勝手に消される心配がない。まずは一覧化だけ、次に人間が判断、という順番になる。終わり方を先に決めると、途中の安全性まで上がるのだ。
ここで一つ、筆者がやらかした話を挟む。以前、ドキュメントの整備を頼むときに「読みやすくして」とだけ渡したことがある。結果、要約はうまくいったが、必要な注意書きまで削られた。作業自体は丁寧だったのに、完了条件が空っぽだったせいで、仕上がりの評価軸がブレたのである。あれは完全にこちらの負けだ。Claude Code は悪くない。指示した側の責任である。
迷いを減らすコツは、完了条件を「見た目」ではなく「判定できる状態」にすることだ。
「きれいにする」より「見出しを4階層以内に収める」。「わかりやすくする」より「手順を番号順に並べる」。「安全にする」より「削除はしない、候補だけ出す」。判定できる言葉に落とすと、終わったかどうかがぶれない。
ただし、やりすぎると逆に窮屈になる。開始条件を細かくしすぎて、読むべき範囲がどんどん広がるのはよくない。入口は絞る。出口は測れる形にする。着地条件は、最終出力の形だけ決める。ここまでで十分だ。全部をガチガチに固定する必要はない。
もう一段うまく使うなら、依頼の最後に「終わったら何を返すか」を毎回入れるといい。実務ではこれが効く。
終わったら、次の順で返してください。
1. 変更した点
2. 迷った点
3. 追加で確認したい点があればその質問
この一文があるだけで、返答の着地が整う。作業そのものより、最後の報告が整うほうが後で助かることが多い。人は途中より、終わりの確認でミスに気づくからだ。
Claude Code を道具として使いこなしたいなら、入口と出口を毎回言葉にする癖をつけるべきだ。雑な依頼でも動くことはある。だが、終わり方が曖昧な作業は、だいたい後で燃える。開始条件、完了条件、着地条件。この3つを先に置くだけで、作業は驚くほど静かに終わる。そこまで持っていければ、Claude Code はかなり頼れる相棒になる。