#claude-code-prompting

Claude Code に長い説明を毎回書くのが面倒なら、先に「こういう仕上がりで」と 1 つだけ見せると、話がかなり速くなります。 このやり方は、英語圏では few-shot と呼ばれることがありますが、要するに「見本を 1 つ渡して、残りを同じ調子でやってもらう」頼み方です。Claude Code では、細かなルールを全部言葉で列挙するより、短い指示と実例を組み合わせたほうが、意図が伝わりやすい場面が多いです。 たとえば、フォルダ整理をしたい人なら、こんな頼み方ができます。 まず、やってほしいことを一言で伝えます。そのあと、理想の出力例を 1 つだけ置きます。 ```text このフォルダの中身を見て、重複しそうなものや不要そうなものを整理したいです。 判断のしかたは、次の例に合わせてください。 例: report_final_v3.docx → 最終版に見えるので残す候補 report_old.docx → 古い版なので確認候補 .DS_Store → macOS の不要ファイルなので削除候補 この例と同じ考え方で、他のファイルも 「残す候補 / 確認候補 / 削除候補」 の 3

Claude Code に「長い仕事をそのまま進めて」と渡すと、途中で迷ったり、どこまでやったか見えにくくなったりします。先に小さな ToDo に分けさせると、作業の見通しが立ち、途中確認もしやすくなります。コード修正だけでなく、フォルダ整理、重複ファイルの洗い出し、長文の下書きにも効きます。 このやり方の肝は、いきなり実行させるのではなく、まず「何を順番にやるか」を書き出させることです。Claude Code は対話しながら進められるので、最初に作戦を出させてから、ひとつずつ潰していく運びに向いています。 たとえば、案件フォルダを整理したいなら、こんなふうに頼みます。 ```text この作業を、実行前に小さな ToDo に分解してください。 目的: 旧案件フォルダの整理と不要ファイルの削減 条件: まず手順だけ提案する 危険な削除は勝手にしない 迷う点があれば確認質問を先に出す 作業は小さく分ける ``` コード修正なら、もう少し具体的にしておくと安定します。 ```text 次の変更作業を、実行前に ToDo に分解してください。 やってほしいこと: 影響範囲の確認 変更対象ファ

Claude Code は、お願いの仕方ひとつで動きがかなり変わります。 「何をしてほしいか」だけでなく、「何をしてほしくないか」を先に置くと、不要な編集、余計な削除、勝手な整形をかなり減らせます。ファイル整理でも、文書作成でも、コード修正でも効きます。 たとえば、重複ファイルの整理を頼むときに「安全第一で、削除はしないで。まず候補を出して」と添えるだけで、作業の進め方が落ち着きます。逆にそこを書かないと、こちらの意図より前に進んでしまうことがあります。 禁止事項は、遠回しに匂わせるより、短く具体的に書くほうが通じます。 よく効く形は、依頼文の最初か最後に「やらないこと」をまとめて置くやり方です。Claude Code に渡す文章に、そのまま入れてしまってかまいません。 ```text この作業では、次のことはしないでください。 ファイルの削除 既存文書の全面書き換え フォルダ構成の変更 こちらの確認なしでの実行 まずは提案だけ出してください。 ``` 言い方のコツは、抽象的な禁止を避けることです。 「適当にやらないで」では伝わりにくいですが、「削除はしない」「移動はしない」「上書き保

Claude Code に既存ファイルを読ませて、「このプロジェクトの書き方に寄せて」と頼むだけで、あとから直す手間をかなり減らせます。 新しく機能を足すときも、文書を整えるときも、ファイル整理をするときも、まずは“その場の流儀”を真似させるのが近道です。 たとえば、何人かで触っているコードベースには、見た目には小さいけれど守られている癖があります。変数名の付け方、コメントの温度感、改行の入り方、エラーメッセージの言い回し。Claude Code はそこを雑に平均化してしまうことがあるので、最初に「このファイル群の作法を読んで、同じ調子で書いて」と明示しておくと安定します。 使い方は難しくありません。手本を渡して、守ってほしい範囲を絞るだけです。 ```text 次の既存ファイルを読み、命名、コメントの量、関数の長さ、改行の癖を このコードベースの作法として把握してください。 そのうえで、新しく追加するコードは、既存の書き方に合わせてください。 見た目だけ真似るのではなく、同じ意図の処理があれば同じ構造を優先してください。 ``` もう少し実務寄りにするなら、何を真似るのかを具体化しま

Claude Code に雑に「直して」とだけ頼むより、「まず調べて、次に直して」と分けて指示したほうが、手戻りが減ります。 とくに、既存コードの修正、フォルダ整理、重複ファイルの洗い出し、文書の整形のように、先に状況把握が必要な作業で効きます。 理由は単純で、いきなり修正に入ると、Claude Code が「何を根拠に直すか」を自分で補ってしまうからです。 先に調べさせると、対象のファイル、命名、依存関係、似た設定、既存の方針を確認したうえで、その情報に沿って直せます。人間がレビューするときも、この順番のほうが判断しやすいはずです。 たとえば、README を整えたいときに、最初から「読みやすくして」とだけ頼むと、書き換えの方向がぶれやすいです。 先に「このリポジトリの README、見出し構成と重複表現を確認して」と頼み、その結果を見てから「では、その指摘に沿って最小限で直して」と続けると、修正の筋が通ります。 同じことは、開発者以外の用途でも起きます。 たとえば、外付けディスクの中身を減らしたいとき、いきなり「不要なものを消して」では危ない。まず「このフォルダ群の中で、重複してい

Claude Code に作業を頼むとき、いちばん効くのは「何を作るか」だけでなく「何をしないか」まで先に渡すことです。 ゴール、制約、成功条件、触ってよい範囲を最初に揃えると、やり直しが減ります。ファイル整理でも、文書作成でも、コード修正でも効きます。 たとえば、ただ「このフォルダを整理して」と頼むと、見た目は整っても、必要なものまで移動されたり、命名が勝手に変わったりします。 逆に、目的と境界を先に書くと、Claude Code は判断しやすくなります。人に仕事を頼むときと同じで、曖昧さを減らすほど返答の精度が上がります。 依頼文の骨格はシンプルです。次の4点を最初に置きます。 1. 目的 2. 制約 3. 成功条件 4. 変更してよい範囲 この順で書くと、相手は「何を達成すればよいか」と「どこまで手を出してよいか」を先に理解できます。 Claude Code はターミナル上でファイルを読んだり編集したりできるので、境界が曖昧だと、意図しない変更が入りやすくなります。 たとえば、文書整理ならこんな依頼です。 ```text 目的: 取引先向け提案書のたたき台を、読みやすく短くしたい

Claude Code に仕事を投げるとき、いちばん効くのは難しい命令ではありません。 「何を直すのか」と「どこまで触ってよいのか」を、先に狭く決めることです。 このひと手間で、生成された差分を読みやすくできるし、意図しないファイルまで触られる事故も減ります。 エンジニアならリファクタリングや機能追加の前さばきに使えます。非エンジニアでも、文書整理、重複ファイルの洗い出し、フォルダ内の資料の整形にそのまま効きます。 曖昧な依頼が弱いのは、Claude Code がサボるからではなく、境界がないからです。 「このフォルダだけ」「このファイル群だけ」「本文だけ直して、見出し構成は変えない」のように、先に線を引くと結果が安定します。 たとえば、README の整備ならこう書けます。 ```text 次の作業をしてください。 対象: docs/README.md やってほしいこと: 導入文を短くする 見出しの順番は変えない 手順の重複を減らす 文章は日本語のまま、意味は変えない やらないこと: コード例は変更しない 他のファイルは触らない 新しい機能説明を勝手に足さない 完了条件: READM

Claude Code に頼むとき、同じ一文に「何がどうなっているか説明して」と「ついでに直して」まで詰め込むと、返ってくる作業の焦点がぼやけます。 この TIPS は、依頼を「説明」「修正」「整理」に分けて投げるだけで、やり取りの手戻りを減らすためのものです。特に、ファイル整理や文書作成のように、コード以外の作業でも効きます。 Claude Code は、たしかに一度にいろいろ頼めます。ですが、全部を同じ粒度で混ぜると、どこまでが現状把握で、どこからが変更作業なのかが曖昧になります。曖昧なまま進むと、意図しない修正をしたり、説明は合っているのに直し方がずれたりします。 人が隣で仕事を受けるときと同じで、「まず現状を見て」「次に直して」と順番を切るほうが、結果が安定します。 まずは、頼み方を分けるところから始めます。たとえば、文章の推敲ならこうです。 ```text この文書の構成を説明して。まだ直さないで。気になる点だけ箇条書きで挙げて。 ``` 次に、説明を受けたあとで修正を頼みます。 ```text さっき挙げた気になる点のうち、語尾の重複だけ直して。内容は変えないで。 ```