Claude Codeのプロンプト術：より良い結果を出すための実践ガイド

Claude Codeはチャットボットじゃない。そのように使うのをやめよう

ほとんどの人はチャットウィンドウからClaude Codeに移行し、同じように使います：曖昧な依頼、大量のやり取り、「違う、そうじゃない」の繰り返し。だいたいはうまくいきますが、それはこのツールを最も遅く使う方法でもあります。

メンタルモデルは異なります。Anthropicのベストプラクティスガイドによると、Claude Codeは「探索し、計画し、実装する」のを自分で行います：ファイルを読み込み、コマンドを実行し、あなたが見守ったり軌道修正したり、その場を離れたりする間に問題を解決します。だからあなたの仕事は「答えを入力する」ことから「作業をセットアップする」ことに変わります。ツールで実際のアプリを1年間構築してきたSean Tierneyは、「クォーターバックではなく、プレイメーカーとして行動することを学ぶ」と表現しています。

その捉え直しがこの記事全体です。以下はすべて、Claudeが4回目ではなく1回目で正しく作業できるよう、作業をセットアップするための具体的な方法です。

具体的に伝える：手順ではなく成果を説明する

「指示が正確であるほど、修正が少なくなります」とAnthropicは述べています。「Claudeは意図を推測できますが、心を読むことはできません。」これはコストゼロで行える、最もレバレッジの高い変更です。

Anthropic自身のガイドの前後比較で明らかになります。「foo.pyのテストを追加して」とは言わないでください。代わりに：「ユーザーがログアウト状態のエッジケースをカバーするfoo.pyのテストを書いて。モックなし。」「ログインのバグを修正して」とは言わないでください。「セッションタイムアウト後にログインが失敗するとユーザーが報告しています。src/auth/の認証フロー、特にトークン更新を確認し、問題を再現する失敗するテストを書いて、その後修正してください」と言いましょう。

コツは成果と制約を伝え、どこで行うかはClaudeに見つけさせることです。Anthropicのヘルプセンターはこれを"成果を伝えよ、手順ではなく"と呼んでいます：「userService.tsを開き、validate関数を見つけ、42行目にnullチェックを追加して」ではなく、「メールのないユーザーが検証をクラッシュさせています。適切に処理してテストを追加してください」。差分をマイクロマネジメントするのではなく、あなたが実現したい世界を説明するのです。

一つ覚えておく点：探索しているときは曖昧でも構いません。「このファイルで何を改善しますか？」というプロンプトは、思いつかなかった事柄を発見してくれるから優れています。具体性は何が欲しいかわかっているときのためで、探索のためではありません。

生のデータを与える：ファイル、スクリーンショット、URL、パイプされたログ

正確なプロンプトには生のデータも必要です。Claude Codeには会話にコンテキストを直接取り込む複数の方法があり、記憶から説明するより使った方が効果的です：

• @でファイルを参照する。@src/auth/login.tsと入力するとClaudeが返答前にファイルを読みます。パスがわかっているなら、検索させるより速くて安上がりです。これは整理されたリポジトリ構造が大切な理由でもあり、Claude Codeでコードベースをナビゲートするような記事が重要な理由でもあります。
• **画像を貼り付ける。**デザインやエラーのスクリーンショットをドラッグ＆ペーストして「このデザインを実装し、結果のスクリーンショットを撮って、差分をリストアップして」と言いましょう。ClaudeはUIを見ることができます。
• **URLを与える。**ドキュメントページやAPIリファレンスを指定できます。よく使うドメインを/permissionsでホワイトリストに追加できます。
• データをパイプする。cat error.log | claudeでファイルを直接送信します。これがUNIXの組み合わせ可能なツールとしてClaude Codeをターミナルで使う入り口です。

ヘルプセンターはこれに関して明確なルールを示しています：エラーをそのまま与えてください。要約せずに完全なスタックトレースを貼り付けましょう。ファイル名、行番号、メッセージが正確であるからこそ、Claudeが推測ではなく正しいコードにたどり着けます。難しいセッションについては、Claude Codeでのデバッグガイドで詳しく解説しています。

コードを書く前に計画させる

これがClaude Codeを「好き」と言う人と「大好き」と言う人を分けるポイントです。「Claudeを直接コーディングに走らせると、間違った問題を解くコードができる可能性があります」とAnthropicは警告しています。解決策は4フェーズのループです：探索、計画、実装、コミット。

最初の2フェーズはプランモードで行われます。Claudeはファイルを読み込んでアプローチを提案しますが、一切の編集を行いません。Shift+Tab（2回押してプランモードに入る）で有効化するか、claude --permission-mode planでセッションを開始します。VS Codeではプランがインラインでコメントできるマークダウンドキュメントとして開きます。ターミナルではCtrl+Gでエディタにプランが開き、Claudeが進める前に直接編集できます。詳細な設定はインタラクティブモードガイドをご覧ください。

実践者の間での合意はAnthropicの推奨よりさらに強いです。毎日このツールで構築しているSean Tierneyはこう語っています：

「常にプランモードから始めてください。すぐに実装に飛び込む誘惑に抵抗してください。CCにまったく同じプロンプトを与えても、まずプランモードで始めて事前に考えさせることで、計画を提案・説明しなければならないためにはるかに良い結果が得られます。この少し遅れる満足感は、実装に焦るよりも2分待つ価値があります。」 - Sean Tierney, Vibecode Lisboa

いつ計画しないか？私が使っているAnthropicの目安は：差分を一文で説明できるならプランをスキップ。タイポ、ログ行、変数のリネームなら直接依頼するだけ。アプローチが不明な場合、変更が複数ファイルにまたがる場合、またはコードをよく知らない場合に計画が効果を発揮します。

Claudeに自分の作業を確認する方法を与える

誰も警告しない失敗パターンがあります：Claudeは作業が完了して見えると止まります。実行可能なチェックがなければ「完了して見える」が唯一のシグナルになるため、あなたが検証ループになり、すべての差分を手動で読み直すことになります。

解決策は合格か失敗かを返すものを渡すことです：テストスイート、ビルド、リンター、出力をフィクスチャと比較するスクリプト、またはデザインと比較するスクリーンショット。「Claudeが実行できるチェックを与えてください」とAnthropicは言います。「それが観察するセッションと、その場を離れられるセッションの違いです。」だから検証はプロンプトの中に含める：「validateEmail関数を書いて。テストケースの例：user@example.comはtrue、invalidはfalse、user@.comはfalse。実装後にテストを実行して。」

だからテスト駆動プロンプティングがうまく機能するのです。まずClaudeにテストを書かせ、失敗することを確認し、通るまで実装させましょう。そして成功を主張するのではなく証拠を示すように依頼してください：テスト出力、実行したコマンド、スクリーンショット。証拠を確認する方が自分でチェックを再実行するより速いです。これをより厳格にしたい場合は、Claudeが終了しようとしたときに発動する決定論的なフックにエスカレートできます。フックリファレンスで説明しています。

コンテキストウィンドウを予算のように扱う

Claude Codeのプロンプティング問題のほとんどは一つのことに起因します：コンテキストウィンドウはセッション全体（すべてのメッセージ、ファイル読み込み、コマンド出力）を保持し、ウィンドウが埋まるほどモデルのパフォーマンスが低下します。1回のデバッグセッションで数万トークンを消費し、混雑すると以前の指示を「忘れ」始めます。

だから意識的に管理しましょう：

• 無関係なタスクの間に/clear。 これが最も重要です。Tierneyはこれを「核の選択肢、フィーチャーの間に惜しみなく使え」と呼んでいます。鋭いプロンプトで始めた新鮮なウィンドウは、行き詰まりだらけの長いセッションより優れています。
• /compact <指示> 続けたいがスリム化したいときに。例えば/compact APIの変更に集中して。
• サブエージェントに委任する。 大きなコードベースを調査するとファイル読み込みでウィンドウが埋まります。サブエージェントは自分自身のウィンドウでその読み込みを行い、要約だけを報告します。「コンテキストが根本的な制約であるため、サブエージェントは最も強力なツールの一つです」とAnthropicは言います。「サブエージェントを使ってトークン更新の処理方法を調査して」と言うだけです。構築できるClaude Codeサブエージェントのガイドにさらに多くのパターンがあります。

ウィンドウを何が消費しているか正確に見たい場合、/contextで何がロードされているか、どの接続ツールがトークンを最も消費しているかを視覚化できます。

素早く修正し、やり直す時期を知る

Anthropicは「最良の結果は密接なフィードバックループから生まれます」と明確にしています。Claudeが間違った方向に進み終わるのを待ってからすべて説明し直す必要はありません。修正ツール：

• Esc はClaudeの動作を途中で止めます。コンテキストは保持されるため、その場でリダイレクトできます。
• Esc Esc（または/rewind）で巻き戻しメニューを開き、以前の会話やコード状態を復元できます。
• 「それを元に戻して」 でClaudeが自分の変更を戻します。

ここで、聞こえる以上に重要なトーンについての注意があります：検索エンジンにではなく、同僚に修正するように伝えましょう。リクエスト全体を再入力するのではなく、「それはパブリックAPIを変えてしまう、シグネチャはそのままにして」など何が間違っているかを言うだけで、Claudeはそれだけを調整します。そして私が最も頼りにするヒューリスティック：同じ問題でClaudeを2回以上修正したなら、コンテキストは失敗したアプローチで汚染されています。/clearを実行し、今学んだことを組み込んだより良いプロンプトで最初からやり直しましょう。きれいなセッションは積み重なった修正を抱えた長いセッションをほぼ常に上回ります。

CLAUDE.mdを書く：一度だけ書くプロンプト

ここまでのすべてはセッションごとのものです。CLAUDE.mdファイルはプロンプトの中で持続する部分です。Claudeはすべての会話の最初にそれを読むため、プロジェクトの永続的なコンテキストが住む場所です：推測できないビルドコマンド、コードスタイルのルール、リポジトリのエチケット、開発環境の癖、注意点。ヘルプセンターはこれを「有能な新しいチームメンバーの初日の朝に行うブリーフィング」と呼んでいます。

/initを実行してプロジェクトから初期ファイルを生成し、その後簡潔に保ちましょう。Anthropicの警告は明確です：「肥大化したCLAUDE.mdファイルはClaudeに実際の指示を無視させます。」各行について「これを削除したらClaudeがミスをするか？」と自問してください。しないなら削除。Claudeが2回間違えたら規則を追加し、四半期ごとに整理し、チーム全員が貢献できるようにファイルをコミットしましょう。ファイルがどこに存在し、ディレクトリをまたいでどのようにマージされるかを含む設定の全体像は、Claude Code設定ガイドとsettings.jsonリファレンスをご覧ください。繰り返し可能なワークフローには、同じロジックがスラッシュコマンドにも適用されます。

こっそりトークンを無駄にするプロンプティングの習慣

無駄なセッションのほとんどは、いくつかの繰り返し可能なミスから来ています。Anthropicは5つを挙げており、それぞれの解決策はプロンプティングの習慣です：

Anthropicが締めくくるメタポイントは覚えておく価値があります：これらは出発点であり、法律ではありません。時にはコンテキストを蓄積させるべき（一つの難しい問題に深くハマっているとき）、計画をスキップすべき（探索的な作業）、または曖昧なプロンプトを投げるべき（制約をかける前にどう解釈するか確認するため）場合もあります。出力が優れているときに何が起きているかを観察し、苦戦しているときにはなぜかを問いましょう。それがどんなチェックリストも置き換えられない直感を育てる方法です。厳選されたセットが欲しいなら、Claude Codeのベストプラクティスのまとめが実際のプロジェクトで生き残ったものを集めています。

サポートチケットに答えるAIとの関連

Claude Codeを使い始めて予想外だったこと：プロンプティングの規律は、ライブサポートキューにAIを導入するために使う同じ規律です。エージェントに適切なコンテキストを与える。触れていい範囲を定める。行動前に確認させる。素早く修正してその教訓を捉える。

その順番を厳しい経験から学びました。初期の頃、自信ありそうなボットが顧客に静かに間違った回答を渡すのを見ました。だから今は、一つのライブ返信も出る前に企業の過去チケットに対してすべてのロールアウトをシミュレートします。それがサポートのプランモードです：世界を読み、どう対処するかを提案し、承認を得て、その後行動する。Gridwiseがそれを実施すると、エージェントは初月に第1階層リクエストの73%を解決し、7日間のトライアルで結果が現れました。その数字はモデルが賢くなったからではなく、セットアップから来ました。

同じように内容を書くなら、そのパラレルはAI執筆にも当てはまります：eesel AIブログライターはその裏側ではチャットボックスではなく、ブリーフして検証するエージェントです。

eeselを試す

eesel AIは同じエージェント的規律をヘルプデスクに活用します。既存のツール（Zendesk、Freshdesk、HubSpot、Gorgias、Slack、100以上）を接続すると、エージェントは初日から過去チケットとヘルプドキュメントから学習します。上記すべてに直接対応する部分：シンプルな言葉で設定し、顧客に返信する前に何千もの実際の過去チケットに対してシミュレーションで実行するので、何を言ったか、どこでエスカレーションしたかを正確に確認できます。

Claude Codeのプロンプティングと同じ教訓をサポートキューに向けたもの：エージェントは与えたコンテキストとガードレールの質以上にはなれません。eeselを試すのは無料でクレジットカード不要。顧客を信頼する前に自社の履歴に対して実行されるのを確認できます。