#claude-code-prompting

「これ、何をしてほしいのか曖昧なまま投げているな」と思ったら、だいたい当たっている。Claude Code への依頼で一番もったいないのは、説明と修正を一度に混ぜることだ。読み解きと編集は別作業で、同じ呼びかけに押し込むと、返ってくる結果が中途半端になる。 たとえば「この Python スクリプトの処理を説明して、ついでに変数名も直して」と一息で頼むと、Claude Code は説明も修正もやろうとする。すると、説明は浅くなるか、修正は小さくなる。コンテキストも食うし、diff も散る。筆者は以前、文章校正を頼みながら「意図の説明も」と混ぜてしまい、返ってきた修正を見てから改めて説明を求める羽目になった。最初から分けていれば、やり取りは半分で済んだはずだ。 コツは単純で、依頼の粒度を揃えることだ。 「説明して」は理解の仕事、「直して」は変更の仕事。どちらか一方に寄せると、Claude Code の出力はかなり安定する。 たとえばコードを見せる場面なら、まずはこう分ける。 ```text このスクリプトの処理の流れだけ説明して。 変更はしないで、箇条書きで要点を整理して。 ``` そのあ

「ちゃんと考えて」とだけ投げて、思った通りになるはずがない。Claude Code も同じで、雑な依頼は雑な結果を呼ぶ。ここで効くのが、長々と説明するより、たった 1 つの例を見せるやり方だ。 few-shot という呼び方をすることもあるが、要するに「こういう出力がほしい」と例示してから頼む方法である。Claude Code ではこれがかなり強い。特に、ファイル整理、文書作成、リネーム、要約、コメント整形みたいに、正解の形がある程度わかっている作業で効く。逆に、言葉だけで曖昧に指示すると、こちらが想像していた粒度とズレやすい。筆者も最初はここで何度か手戻りした。説明を盛るほど伝わる気がして、結局はコンテキストを食うだけだった。 たとえば、README を整えたい。いきなり「読みやすくして」では弱い。こう頼む。 ```text この README を、次の例のようなトーンと構成に寄せて整えてください。 例: 冒頭で何をするプロジェクトかを 2 行で説明する 見出しは短くする 手順は 1, 2, 3 の順で並べる 冗長な言い回しは消す コマンドはコードブロックのまま残す 対象ファ

長い仕事をそのまま投げると、Claude Code はだいたい雑に走る。で、あとから「それ先に必要だったのはこっちだった」と気づいて手戻りする。ここを避けるなら、最初にやることは単純だ。いきなり本作業に入らせず、先にToDoへ割らせるのである。 この一手で、作業の抜け、順番違い、コンテキストの無駄遣いがかなり減る。ファイル整理でも、ディスク掃除でも、文書作成でも効く。長い依頼ほど効き目が大きい。 たとえば「このフォルダ内の重複を洗って、不要なものを消して、最後に要約して」と一気に頼むと、途中で判断がぶれる。何を先に確認するか、どのファイルを触るか、削除の前に何を残すかが曖昧なまま進むからだ。 こういうときは、まずClaude Codeに「作業手順をToDoとして出せ」と命じる。そこで出てきた項目を見て、人間が順序と危険箇所を潰してから進ませる。 実際の頼み方はこうだ。 ```bash この作業を、まず実行用のToDoに分解してください。 まだ変更は加えず、次の形式で出してください。 1. 調査 2. 判定 3. 実行 4. 確認 各項目には、何を確認するか、どのファイルやディレ

「やってほしいこと」だけ書いて、やってほしくないことを放置する。これ、Claude Code への依頼でかなり危ない。余計な編集、勝手な要約、触ってほしくないファイルの改変まで一気に起きる。禁止事項は、気を使ってぼかすより、先に切っておいたほうが早い。 Claude Code は、雑に言えば「範囲が広いほど働きすぎる」タイプだ。だからこそ、禁止事項の伝え方が効く。 たとえばファイル整理なら、「古いものを片付けて」と言うだけでは、思い切りよく削除されて困ることがある。文書作成なら、「読みやすくして」と頼んだだけで、表現をいじられすぎて意図がずれる。開発なら、関連しない設定ファイルまで手を入れて差分が肥大化する。筆者も最初はこの手の依頼で何度か戻した。うまくいくときより、余計なことをして手戻りが出るときのほうが面倒だ。 コツは単純で、「何をしてほしいか」と同じ熱量で「何をしてほしくないか」を書くことだ。しかも、あいまいにではなく、対象を切って書く。 たとえば、こう書く。 ```text このフォルダ内の文書を整理してほしい。 ただし、次は触らないでほしい。 元の本文の意味を変える書き換え

新しいコードをいじらせる前に、まず既存コードの空気を読ませろ。ここを雑にやると、動くけど場違いな差分が増える。名前の付け方も、関数の切り方も、コメントの濃さも、ぜんぶちぐはぐになる。Claude Code でも同じで、「このリポジトリの作法に合わせて」と丸投げするより、見本を渡して真似させたほうがずっと安定する。 Claude Code は、渡した文脈の中でかなり素直に動く。だからこそ、既存コードの一部を「これと同じ調子で」と見せるのが効く。要するに、スタイルを抽象論で説明するのではなく、実例を食わせるやり方だ。ファイル整理や文書作成でも同じで、「このフォルダの命名規則に合わせて」「この報告書の文体に寄せて」と言い換えれば使える。 いちばん簡単なのは、対象のコードと、その周辺の見本を一緒に渡すことだ。たとえば新しい関数を追加したいなら、既にある似た関数を指定して、その流れを踏襲するよう頼む。 ```text このリポジトリでは、既存の `src/users/*` の書き方に合わせてください。 特に次のファイルのスタイルを真似してください。 `src/users/create-user.

雑に「これ直して」で投げると、Claude Code はだいたい手広く動きすぎる。調べるべきことと、直すべきことが頭の中で混ざるからだ。 先に調べさせ、あとで直させる。この順番に分けるだけで、無駄な修正、見当違いの変更、差分の膨張がかなり減る。ファイル整理でも文書作成でも同じで、いきなり“完成形”を頼むより、まず現状を見せたほうが話が早い。 実際、筆者も最初は「このフォルダを整理して」「この文章を直して」と丸投げして、あとで手戻りした。Claude Code は賢いが、前提が曖昧だと遠慮なく広く動く。削除していいものまで候補に入れるし、文書なら表現だけでなく構成までいじってくる。悪気はない。だからこそ、段階を切る。 やり方は単純だ。最初の依頼では、変更禁止で調査だけさせる。次の依頼で、調査結果を前提に修正を指示する。 たとえばコードなら、こういう頼み方にする。 ```text まず調べてください。変更はしないで、次を出してください。 何が原因候補か どのファイルを触る可能性があるか 修正方針を2〜3案 それぞれのリスク まだ編集しないで、調査結果だけ返してください。 ``` この一段目

「とりあえず直して」でうまくいくと思っていると、だいたい手戻りする。Claude Code は空気を読んで全部やってくれる便利屋ではない。何を終点にしたいのか、何を触ってよくて何を触るな、ここを先に渡したほうが速い。 特に Claude Code は、こちらの依頼文そのものを仕事の設計図として読む。だから、ゴールがぼんやりしていると、出力もぼんやりする。逆に、先に制約を渡すだけで、不要な調査や修正、でかい diff をかなり減らせる。ファイル整理でも文書作成でも同じだ。何を残し、何を捨て、どこまでやれば終わりかを先に言っておくのが効く。 筆者も最初は「このフォルダを見て適当に整えて」で頼んで、見事に遠回りした。見た目は整ったが、欲しかったのは重複ファイルの退避であって、構成変更ではなかった。指示が曖昧だと、エージェントは丁寧に暴れる。そこを抑えるのがこの TIPS だ。 まずは、依頼文の骨格を固定してしまうのが早い。Claude Code には、最初にこう投げる。 ```text 目的: 何を完成形とするかを先に決める 変更は最小限にする 既存の命名や構成は極力維持する 制約: 触って

「いい感じにやって」で済むと思っていると、だいたい遠回りになる。Claude Code も例外ではない。 雑に投げると、広く見に行きすぎる。触ってほしい範囲がぼやけるから、無駄にファイルを読み、無駄に大きな差分を作り、あとで「そこじゃない」を直す羽目になる。筆者も最初はこれで何度か手戻りした。頼み方が曖昧だと、エージェントは親切に広く動く。親切さが、そのままコンテキストの浪費になるわけだ。 Claude Code に渡すべきなのは、ふわっとした願望ではない。「何を」「どこまで」「何は触らないか」だ。これを先に切るだけで、作業の速さが変わる。コード修正だけの話ではない。ファイル整理、重複削除の候補出し、文章の整形、案件フォルダの整理でも同じだ。 たとえば、こういう投げ方は弱い。 ```text このプロジェクトを見て、使いやすくして。 ``` これでは広すぎる。何を直すのか分からない。UIなのか、READMEなのか、不要ファイルの削除なのか、テスト追加なのか、全部あり得る。Claude Code は勝手に範囲を解釈するが、その解釈があなたの頭の中と一致する保証はない。 代わりに、最初の一