Claude Codeの精度を劇的に上げるプロンプト＆指示出しのコツ

企業のAI担当者の方から、よくこんな相談をいただきます。「開発チームにAIコーディングツールを配ったが、成果の報告がまちまちで、投資対効果を説明しにくい」。実はこれ、世界中の企業で同時に起きている現象です。

マイクロソフトの研究チームが2026年に公開した調査では、数万人規模のエンジニアの実際の利用ログをもとに効果が測定されました。その結果、Claude CodeやCopilot CLIを使い始めたエンジニアは、使わなかった場合と比べてマージされたプルリクエスト（実際にコードとして採用された変更）が約24パーセント増えたと報告されています。一方で、同じ社内でも効果がほとんど見えないチームがあることも各種の調査で指摘されています。

つまり、ツールは確かに効きます。ただし「効かせ方」を知っているかどうかで、結果が大きくぶれるのです。ここからは、Anthropicの公式ドキュメントと、海外企業の導入事例から確認できた指示出しのコツを7つ、順番に見ていきましょう。難しい専門用語には、そのつど説明を添えます。

コツの前に、1つだけ土台になる考え方を共有させてください。Anthropicの公式ガイドは、Claude Codeのベストプラクティスのほとんどがたった1つの制約から導かれると明言しています。その制約が、コンテキストウィンドウです。

コンテキストウィンドウとは、AIが一度に覚えていられる情報の量のことです。イメージとしては「作業机の広さ」に近いものです。会話の履歴、AIが読み込んだファイルの中身、実行したコマンドの出力結果が、すべてこの机の上に積み上がっていきます。

そして重要なのが、机が散らかるほど精度が落ちるという点です。公式ドキュメントも、コンテキストが埋まってくるとAIは以前の指示を忘れたり、ミスを増やしたりすると説明しています。デバッグ作業やコードベースの調査を1回するだけで、数万トークン分の情報が机に乗ることもあります。

最も効果が大きく、しかも今日すぐ試せるのがこれです。Claude Codeは、作業が終わったように見えた時点で手を止めます。判定する手段がなければ、「見た感じ終わっている」が唯一の合図になってしまいます。

すると何が起きるか。人間が検証係になってしまうのです。ミスは、担当者が気づくまで放置されます。逆に、合格か不合格かをAI自身が読み取れる仕組みを渡しておけば、ループはひとりでに閉じます。AIが作業し、チェックを走らせ、結果を読み、通るまで直してくれます。

チェックの中身は難しいものでなくて構いません。テストの実行、ビルドが通るかどうか、コードの書式チェック（リンター）、画面のスクリーンショットとデザイン案の比較。どれも「合格か不合格か」が文字として返ってくれば十分です。

もう1つ、地味ですが効くコツがあります。「できました」と言わせるのではなく、証拠を出させることです。実行したコマンドとその出力、テストの結果、画面のスクリーンショット。証拠を確認するほうが、担当者が自分でもう一度検証するよりずっと速く済みます。席を外していたセッションの結果を後から確認するときにも、この習慣が効いてきます。

すぐにコードを書かせると、そもそも解くべき問題を取り違えたまま作業が進むことがあります。公式ガイドが推奨しているのは、プランモードを使って調査と実行を切り離すやり方です。

プランモードとは、AIがファイルを読んで質問に答えるだけで、変更は一切加えないモードのことです。Claude Codeの画面でShiftキーとTabキーを押していくと切り替わります。おすすめの流れは次の4段階です。

1. 1
   調べる。「認証まわりのフォルダを読んで、ログインとセッションの扱いを理解してください。あわせて、秘密情報を環境変数でどう管理しているかも見てください」といった形で、現状把握だけをお願いします。
2. 2
   計画する。「外部サービス連携のログインを追加したい。どのファイルを変更する必要がありますか。処理の流れも含めて計画を作ってください」と依頼します。出てきた計画は、そのまま編集して修正できます。
3. 3
   実装する。計画を承認してから「計画どおりに実装してください。テストも書いて、テスト全体を実行し、失敗があれば直してください」と進めます。
4. 4
   記録する。「わかりやすいメッセージでコミットして、プルリクエストを作ってください」で締めます。

AIは意図をある程度は推測できますが、担当者の頭の中までは読めません。ここでいう具体性とは、丁寧な言葉づかいのことではなく、対象のファイル、守ってほしい制約、お手本になる既存のコードを名指しすることです。

公式ドキュメントは、「不具合を再現する失敗テストを先に書かせる」型を紹介しています。これはコツ1とも噛み合う考え方で、直った状態が何を指すのかを、作業を始める前に固定してしまうやり方です。

情報の渡し方にもコツがあります。ファイルの場所を言葉で説明するより、記号を使って直接指定したほうが確実です。画面のスクリーンショットは、そのまま貼り付けられます。参考にしてほしい仕様書があるならURLを渡せますし、エラーログはコマンドでそのまま流し込めます。「口で説明する」より「現物を渡す」ほうが、ほぼ常に速くて正確です。

なお、曖昧な指示がいつも悪いわけではありません。「このファイルで改善できそうな点は何ですか」のような開いた問いは、担当者が思いつかなかった論点を拾ってくれることがあります。方向性を探る段階では、あえて広く投げるのも有効です。

Claude Codeには、会話の最初に必ず読み込まれる特別なファイルがあります。CLAUDE.mdと呼ばれるもので、ここにチームの決まりごとを書いておくと、毎回説明しなくても前提を共有できます。ビルドやテストのコマンド、コードの書き方の方針、ブランチ名の付け方など、コードを読むだけでは分からないことを置く場所です。

ここで多くのチームがつまずきます。親切のつもりで書き足しすぎると、逆に守られなくなるのです。公式ドキュメントも、肥大化したCLAUDE.mdは本当に必要な指示を埋もれさせると明確に警告しています。

削るかどうかの判断基準として、公式ガイドは1行ごとにこう問いかけることを勧めています。「この行を消したら、AIはミスをするだろうか」。答えが「いいえ」なら、その行は削ってよいということです。

運用のコツも押さえておきましょう。まず初期化コマンドでたたき台を作り、そこから育てていきます。同じ間違いを2回されたら、それがルールが足りていない合図です。1行だけ足します。どうしても守られない項目が1つあるなら、その行だけ「重要」と強調します。ただし、あちこちを強調すると、どれも目立たなくなります。

そして、たまにしか使わない知識は、このファイルに入れないでください。特定の場面でだけ必要な手順は「スキル」という仕組みに分けて置くと、必要なときだけ読み込まれます。毎回の会話を重くせずに済むわけです。

ここは、経験者ほど効果を実感するポイントです。1つのセッションで別々の話題を扱うと、AIの机の上には関係のない情報が積み重なります。公式ガイドは、関係のない作業に移るときは会話をリセットするコマンドを使うよう推奨しています。

特に覚えておきたいのが、修正のループにはまったときの対処です。AIが間違える、直す、まだ違う、また直す。こうなると、机の上は失敗した案でいっぱいになります。公式ドキュメントの助言はきっぱりしています。同じ問題で2回修正させても直らないなら、リセットして、学んだことを盛り込んだ新しい指示を書き直す。長い会話を続けるより、きれいな状態から良い指示を出したほうが、ほぼ確実に速いのです。

調査作業には、サブエージェントという仕組みが役に立ちます。これは、別の作業机を持った担当者を呼び出すようなイメージです。「サブエージェントを使って、認証まわりでトークン更新をどう処理しているか、再利用できる部品があるかを調べてください」と頼むと、大量のファイルを読む作業は別の机で行われ、こちらの机には要約だけが返ってきます。調査でメインの会話を汚さずに済みます。

途中でおかしいと感じたら、すぐ止めることも大切です。Escキーで作業を中断でき、そのときの文脈は残るので、方向修正がすぐにできます。作業を巻き戻す機能もあるため、思い切った案を試させて、だめなら戻るという進め方もできます。

これは知らない人が多い、しかし効果の大きい使い方です。規模の大きい機能を作るとき、いきなり指示を書くのではなく、まずAIにこちらを取材させるのです。公式ドキュメントが紹介している型は、おおむね次のような依頼になります。

この進め方には2つの利点があります。1つは、担当者が気づいていなかった論点が事前に洗い出されること。もう1つは、仕様書ができたら新しいセッションで実装を始められることです。取材のやりとりで散らかった机を捨て、実装だけに集中したきれいな机で作業を始められます。

良い仕様書の条件も明確です。関係するファイルと接続部分の名前が入っていること、何をやらないかが書かれていること、そして最後に「動いていることをどう確かめるか」が書かれていること。この3点です。公式ガイドは、実装を見張る時間より、仕様を正確にする時間のほうが報われると述べています。

人間の開発現場と同じで、自分が書いたコードは自分では甘く見えます。AIも同じです。そこで、実装したセッションとは別の場所で、差分だけをレビューさせるやり方が効いてきます。

レビュー役は、そこに至るまでの思考過程を知りません。目の前の変更内容と、渡された判断基準だけを見て評価します。だからこそ、実装者が「これでいいはず」と思い込んだ穴に気づけます。依頼文としては、次のような形が公式ガイドで紹介されています。

サブエージェントを使って、今回の変更内容を仕様書と突き合わせてレビューしてください。すべての要件が実装されているか、挙げた例外にテストがあるか、作業範囲の外を変更していないかを確認してください。好みの問題ではなく、抜けだけを報告してください。

ここには重要な注意点があります。公式ドキュメントは、「抜けを探せ」と言われたレビュー役は、実際に問題がなくても何かしら報告してくると指摘しています。指摘をすべて潰そうとすると、不要な抽象化や、起こり得ない場合に備えたテストが増え、かえって複雑なコードになります。正しさや要件に関わる指摘だけを対応対象とし、それ以外は任意扱いにする。この線引きをレビュー役への依頼文に最初から入れておくのが実務的です。

もう少し体制寄りの話をすると、担当を分けるやり方も有効です。片方に実装させ、もう片方に「この実装を、例外処理、競合状態、既存の書き方との一貫性の観点でレビューしてください」と依頼し、返ってきた指摘を実装側に戻す。テストを書く役と、そのテストを通すコードを書く役を分ける、という組み方もできます。

コツを7つ見てきましたが、実際にこれらが効くのかどうかは、導入企業の数字が教えてくれます。公開されている海外の事例を3つ紹介します。

3つ目の数字に注目してください。AIの効果は「同じ仕事が速くなる」だけではなく、「これまで採算が合わずやらなかった仕事が実行できるようになる」形でも現れるということです。社内向けの小さな集計ツール、後回しになっていた技術的な負債の整理、実験的な検証。企業のAI担当者としては、こちらの効果も評価軸に入れておく価値があります。

一方で、冷静な報告もあります。個人の作業速度は上がったのに、チーム全体の納品スピードは変わらなかった、という分析です。理由の1つとして指摘されているのが、コードのレビュー待ち時間が伸びたという現象でした。書く速度だけが上がると、確認する工程が詰まるわけです。コツ7でレビュー役を分ける話をしたのは、まさにここに効くからです。

公式ドキュメントは、よくある失敗の型をはっきり挙げています。社内展開の資料にそのまま転記できる内容なので、表にまとめました。

ここまでは個人の使い方の話でした。最後に、組織として定着させる視点を加えておきます。海外のチーム導入事例で共通して指摘されているのは、「配って終わり」にすると、利用ログ上は使われているのに、チームとしての能力は増えないまま止まるという点です。

差がつくのは、個人のコツが共有資産になっているかどうかです。次の3つを、最初の1か月の目標にすることをおすすめします。

1. 1
   ルールブックを共有物にする。各自のパソコンの中ではなく、コードと一緒にリポジトリへ登録します。誰かが見つけた落とし穴が、そのままチーム全員の資産になります。
2. 2
   うまくいった指示文を集める。週に1回、短い振り返りの時間を取り、成功した依頼文をそのまま貼り付けて共有します。抽象的な感想より、実際の文面が効きます。
3. 3
   検証の工程を先に整える。テストやビルドの確認が自動で走る状態を作ります。コツ1が機能する前提であり、レビュー待ちの詰まりを防ぐ土台にもなります。

投資対効果を説明する場面では、AIが書いた行数のような数字だけを見ないことも大切です。海外の実務者が推奨しているのは、AIが関与した変更とそうでない変更の所要時間を比べる、新しく入った人が初めて成果を出すまでの日数を見る、不具合の発生率とセットで生産量を見る、といった測り方です。量の指標には、必ず品質の指標を添える。これが、経営層に対して説得力のある報告を作る近道です。

参考情報：Anthropic公式ドキュメント「Best practices for Claude Code」、Anthropic社内調査「How AI Is Transforming Work at Anthropic」、ストライプの導入事例、および2026年に公開された企業規模でのAIコーディングツール実証研究。数値や仕様は各社の公開時点のものです。最新の仕様は公式ドキュメントでご確認ください。