人は、自分で直したコードや片づけたファイルをいちばん雑に見てしまう。見たつもりで見落とすし、「たぶん合ってる」で突っ走る。Claude Code を使う場面でも、ここが一番まずい。
この手の失敗は、派手なバグより地味に痛い。ファイル整理なら不要データを残したまま「空いた気になる」。文書作成なら、参照漏れや表記ゆれを見逃す。開発なら、テストが通っただけで安心して、実は境界条件を壊している。だから Claude Code には「作って」と頼むだけでなく、「自分の作業を疑え」と頼むのが効く。
要は、Claude Code を作業者ではなく、検査役として使う発想だ。しかも、ただ「チェックして」と投げるだけでは弱い。どこを、何と照合し、何をもって問題なしとするかを、先に決めておく必要がある。
一番ありがちな失敗は、作業のあとにこう言うことだ。
これ、確認して。
これでは甘い。Claude Code は広く見られるぶん、広く見て終わる。見る範囲が曖昧だと、確認の密度が下がる。確認役にしたいなら、検証対象をはっきり切るべきだ。
たとえば、コードなら「変更した関数だけ」「テストが触る周辺だけ」「差分に出たファイルだけ」を見させる。文書なら「見出し構成」「重複表現」「数字」「固有名詞」など、観点を分ける。ファイル整理なら「重複削除候補」「名前の衝突」「参照が残るファイル」を見る。
実際の頼み方は、こんな具合だ。
今の作業内容を検証してください。
対象はこの差分です。
- 変更点が元の意図から外れていないか
- 見落とした副作用がないか
- 追加した処理に対してテストが足りているか
曖昧な点があれば、推測で埋めずに質問してください。
ポイントは、「検証して」ではなく「何を基準に検証するか」を書くことだ。これだけで返答の質が変わる。
Claude Code に検証させるときは、作業内容そのものより、判断基準のほうが重要になる。ここを渡さないと、もっともらしい総論で終わる。
たとえばコード修正なら、次のように具体化する。
次の観点で、変更が正しいか検証してください。
1. 仕様との一致
2. 既存の挙動を壊していないか
3. 例外ケースが抜けていないか
4. テストが不足していないか
差分を読んだうえで、各項目について
- 問題なし
- 要確認
- 明確に怪しい
で分類してください。
この形がいいのは、Claude Code に「説明」ではなく「判定」をさせやすいからだ。判定軸があると、返答がぼやけにくい。
文書作成でも同じだ。たとえば、報告書や契約関連のたたき台を検証させるなら、こう切る。
この文書をチェックしてください。
観点は次の4つです。
- 記載漏れ
- 表記ゆれ
- 数字や日付の整合性
- 読み手に誤解される箇所
修正案は、必要な箇所だけ抜き出して示してください。
ここで大事なのは、Claude Code に「全部直して」と丸投げしないことだ。検証と修正を同時にやらせると、確認が甘くなることがある。まずは点検。直すのはそのあとでいい。
自分の作業を検証させるなら、最初からプロジェクト全体を見せる必要はない。むしろ、差分に絞ったほうが強い。余計な情報が減るし、確認の焦点がぶれにくい。
CLI らしくやるなら、まず変更箇所を差分で渡すのが素直だ。Claude Code が現在の作業ツリーを見られる前提なら、変更ファイルに限定して確認させればいい。
変更したファイルだけを対象に、次を確認してください。
- 変更の意図と実装が一致しているか
- 参照先のパスや名前が壊れていないか
- 削除したものの代わりが抜けていないか
差分にない箇所は、勝手に話を広げないでください。
この「勝手に広げるな」が地味に効く。確認役は、思い込みで周辺を補完しがちだ。そこが危ない。自分でも、少し前にファイル整理を頼んだとき、Claude Code が「たぶん関係ある」として周辺のキャッシュや生成物まで候補に入れてきたことがある。便利ではあるが、同時に危うい。不要ファイルを減らしたいだけなのに、削除候補が広がりすぎると事故る。
だから、削除や整理では境界を先に引く。
この作業では、削除候補の判断だけをしてください。
対象は Downloads 配下の重複ファイルと、明らかに不要なキャッシュだけです。
アプリ本体や設定ファイルは削除対象にしないでください。
候補ごとに、
- 削除してよい理由
- 残すべき理由
を分けて示してください。
こうしておくと、Claude Code は「たぶん不要そうなもの」を雑に広げにくい。
確認の依頼で本当に役に立つのは、正解を即答させることではない。自分の見落としを炙り出すことだ。そのためには、Claude Code に「疑う観点」を返させるのがいい。
たとえば、こういう頼み方だ。
この作業に対して、見落としやすい失敗を先に挙げてください。
そのうえで、今の状態を見て
- 実際に問題があるもの
- 気にしなくてよいもの
を分けてください。
根拠が弱いものは、弱いと書いてください。
これをやると、ただのチェックリストでは見えない穴が見つかる。人間は、自分がやった作業に対して「できている前提」で見てしまうからだ。Claude Code に先に疑わせると、その前提が崩れる。
筆者はここで一度、文書の章立てを直したあとに「見出しは整ったはず」と思い込んで、本文中の用語ゆれを見落としたことがある。見出ししか見ていなかったわけだ。Claude Code に「構成を見て」とだけ頼んだのが悪かった。後から「用語」「数字」「参照関係」まで分けて見させたら、すぐに拾えた。確認は、観点を切らないと浅くなる。
Claude Code に検証を頼むと、たまに丁寧な説明文が返る。悪くはないが、検証としては使いにくい。何が問題で、どこを直せばいいかが埋もれるからだ。
なので、出力形式を縛っておくといい。
次の形式で返してください。
1. 問題なしの点
2. 要確認の点
3. 明確に修正が必要な点
4. 修正提案
各項目は箇条書きで、根拠を1行添えてください。
これだけで、返答が実務向きになる。ファイル整理でも同じだ。例えば、重複画像や古い書類の整理を検証させるなら、こんな形が扱いやすい。
候補を次の3段階に分けてください。
- 安全に削除しやすい
- 人間の確認が必要
- 残すべき
判断理由を短く添えてください。自信がない場合は「不明」と書いてください。
「自信がない場合は不明」と明示するのも大事だ。推測で埋める癖を止められる。ここを曖昧にすると、見た目は整っていても中身が危ない確認になる。
検証の依頼では、何をしてほしいかだけでなく、何をしてほしくないかを書くと強い。Claude Code は素直だが、素直さゆえに余計な提案まで出してくることがある。
この作業を検証してください。
ただし、次のことはしないでください。
- 勝手に仕様を補完する
- 変更していないファイルまで前提に含める
- 曖昧な点を断定する
- 修正案を広げすぎる
必要なら質問を返してください。
この書き方は地味だが効く。特に、作業の途中で何度も往復したくないときに効く。雑な提案が減るからだ。
自分の経験でも、ここを省いたときに「その場で便利そうな改善」がどんどん出てきて、差分が無駄に膨らんだことがある。結果、確認したいだけなのに、追加修正の検討まで始まってしまった。検証と改修の境目が溶けると、作業が散らかる。かなりだるい。
本当に思い込みを潰したいなら、1回で終わらせないほうがいい。まず検証だけ、次に必要なら修正だ。
流れはこうだ。
第1段階: 検証だけしてください。修正しないでください。
第2段階: 問題がある箇所だけ、最小限で直してください。
この二段構えにすると、検証と修正が混ざらない。最初の段階で「どこが怪しいか」を洗い出し、次の段階でだけ直す。これがいちばん事故が少ない。
特に、削除や整理ではこの順番が大事だ。先に消してしまうと、後から「本当に必要だった」と気づいても戻しにくい。だから、まず候補を出させ、次に人間が選ぶ。この順が安全だ。
細かいことを考えるのが面倒なら、まずこれで十分だ。
今の作業を検証してください。
対象は差分だけです。
観点:
- 意図と実装の一致
- 見落としや副作用
- 抜けているテストや確認
- 誤解を生みそうな表現や命名
出力:
- 問題なし
- 要確認
- 明確に修正が必要
推測で埋めず、根拠が弱ければ弱いと書いてください。
この形のいいところは、開発でも文書でもファイル整理でも、そのまま流用しやすいことだ。Claude Code に自分の作業を検証させるときは、うまくやろうとするより、疑う範囲を絞るほうが効く。広く賢く見せるより、狭く厳しく見せるほうが、結局は強い。最後に残るのは、派手な提案ではなく、思い込みを1つずつ潰した跡だ。