Claude Code の「プロンプト術」は公式に答えがあった — 連載スタート記

Claude Code、ちゃんと「公式の作法」で使っていますか?

「今日の Claude、なんか調子悪いな…」

そんなふうに、Claude の出力品質を その日の運や気分のせい にしてしまっていることはありませんか?

実は、半年前までの私がまさにそれでした。AI 駆動開発で個人プロダクトを 3 つ動かしながら、Claude Code をヘビーに使っていたのですが、使い方の核は最後までずっと「感覚」のままだったのです。

「今日はなんか賢い」「今日はなんかダメ」と、原因を Claude の側に押し付けてばかりいました。

そこから抜け出すきっかけになったのが、Anthropic 公式のベストプラクティス をちゃんと読んだことです。読み終えた瞬間、ため息のような感想が出ました。

「答え、全部ここに書いてあったんだ」

何を読んだか

一次ソースとして読み込んだのは、たった 2 つです。

英語ではありますが、分量自体はそれほど多くありません。コードを書く合間に読んでも、半日あれば一通り目を通せる程度のボリュームです。

それなのに、日本語でこれを丁寧に解説した記事はまだ少ない印象でした。ここを埋めるところに、自分なりの価値があるかもしれない。そう感じて、連載というかたちで整理してみることにしました。

読んだあと、私の使い方はこう変わった

公式を読んで、私の Claude との付き合い方は地味にいくつか変わりました。とくに効果が大きかったのは、次の 3 つです。

1. 「検証手段」を必ず添えるようになった

公式が「単独で最も効果が大きい(“the single highest-leverage thing”)」と明言しているのが、この検証手段の話。テスト・スクショ・期待出力のいずれかを必ずプロンプトに添える だけで、生成コードの精度が一段上がるのを体感しました。

2. /clear を恐れず使うようになった

「同じ指摘を 2 回以上したら /clear」が公式の鉄則として書かれていました。コンテキストが埋まると Claude の性能が劣化する、ということが、はっきりと明文化されています。

セッションを長引かせれば長引かせるほど Claude は学んで賢くなる、と私はずっと信じていたのですが、これは見事に誤解でした。

3. 「いきなり Code」をやめた

Explore → Plan → Code → Commit という 4 段階のワークフローも、目から鱗の話でした。Plan を飛ばしていきなりコードを書かせると、間違った問題に対する正しい解 が出てくる、と公式は警告しています。

たしかに、思い当たる節がいくつもありました。これを知ってから、複雑なタスクでは必ず Plan Mode を挟むようになっています。

これから連載します

このホームページでは、公式ドキュメントをベースに、筆者の解釈・体感を添えた連載 として整理していきます。タイトルは「Claude プロンプト術 完全ガイド」。全体としては、こんな流れで進みます。

テーマ
第1回最重要3原則(ゴールデンルール / コンテキスト管理 / 検証手段)
第2回開発ワークフロー(Explore → Plan → Code → Commit)
第3回開発編プロンプト11パターン
第4回指示の書き方 5 技法(CLAUDE.md / XML / Few-shot 等)
第5回Claude Code 固有機能の使い分け
第6回思考系プロンプト 13 パターン
第7回日常系プロンプト 18 パターン
第8回総まとめ

信頼度の凡例

連載中、公式の引用と私の解釈を混ぜると、読み手として「これは公式なの? 個人の感想なの?」と迷ってしまいます。なので、明確に分けるための凡例を最初に置いておきます。

凡例意味
🟢 公式引用公式ドキュメント原文の直接引用・翻訳
🟡 公式記述公式ドキュメントに記載された技術・手順
🔵 筆者解釈公式情報を再整理・優先度付けしたもの

Anthropic 公式が明言している内容と、私個人の解釈は、ここで線を引かせていただきます。

技術記事版は Qiita にあります

ホームページ版は、個人的な所感や体感を中心に、読みやすさを優先 した構成にしています。

一方、公式ドキュメントの引用を網羅したリファレンス版 は Qiita に順次公開していくつもりです。深く掘りたくなった方は Qiita の筆者ページ から該当記事を覗いてみてください。

明日からは原則編に入ります。気軽についてきていただければ嬉しいです。

関連記事

お問い合わせ

ご質問やフィードバックなど、お気軽にお問い合わせください。

お問い合わせはこちら