「毎回うまいプロンプトを書かなきゃ」——その発想自体が、Claude Codeの使い方としては古くなりつつあります。
Anthropic関係者がCode w/ Claudeなどの公式動画で伝えている核心は、次の1行に集約されます。Claude Codeにプロンプトを書くな。自分で自分にプロンプトを出す仕組みを作れ。 チャットに長文を貼る運用から、リポジトリに蓄積する運用へ切り替える話です。
この記事でわかること
- 「プロンプトを書かない」とは何を指すのか
- 公式が推す3層の仕組み（CLAUDE.md・Skills・Hooks）
- 初日から始められる設定手順
- Anthropic Consoleのプロンプト自動生成との使い分け
https://code.claude.com/docs/en/best-practices
なぜ「毎回プロンプトを書く」がボトルネックになるか
Claude Codeは、質問に答えるチャットではなく、ファイルを読み、コマンドを実行し、完了まで自律的に動くエージェント型の開発環境です。会話が進むほど、読み込んだファイルやコマンド出力がコンテキストに積み上がり、ウィンドウが満杯になると指示の遵守が落ちやすくなります。
Anthropicのベストプラクティスでも、コンテキスト管理が最優先課題だと明記されています。同じ「テストは単体だけ」「コミット前にlint」といったルールを、セッションごとにプロンプトで繰り返すと、毎回トークンを消費し、表現のブレも起きます。
逆に、ルールと手順をファイルやスキルに固定すれば、Claudeは起動時や呼び出し時にそれを読み込み、あなたはゴールと検証方法だけを渡せます。これが「自分で自分にプロンプトを出すシステム」の意味です。
3層で組む「自己プロンプト」設計
公式ドキュメントが示す構成は、役割ごとに分けるのが要点です。
| 層 | 置き場所 | 役割 | いつ効くか |
|---|---|---|---|
| 常時コンテキスト | CLAUDE.md / .claude/rules/ |
規約・ビルドコマンド・禁止事項 | セッション開始時 |
| タスク手順 | .claude/skills/*/SKILL.md |
PR作成・レビュー・デプロイなど | /skill名 または文脈一致時 |
| 確実な自動化 | Hooks（.claude/settings.json） |
編集後のフォーマット、危険コマンド阻止 | ツール実行のたび |
第1層：CLAUDE.mdで「毎回言うこと」を消す
CLAUDE.mdは、セッション開始のたびに読み込まれるプロジェクトの記憶です。ビルド・テストコマンド、コーディング規約、PRの作法など、コードだけでは推測しにくい前提を書きます。
まだファイルがなければ、/initを実行します。Claudeがコードベースを走査し、ビルドシステムやテストの有無を反映したたたき台を生成します（メモリの公式ドキュメント）。既存ファイルがある場合は上書きではなく改善提案になります。
目安は1ファイル200行以内。長くなるほど遵守率が下がるため、タスク専用の長い手順はSkillsへ移します。
第2層：Skillsで「手順書プロンプト」を資産化する
Skillsは、.claude/skills/<名前>/SKILL.mdにMarkdownで手順を書く機能です。フォルダ名がそのまま/deployのようなスラッシュコマンドになります。
YAMLフロントマターのdescriptionに「いつ使うか」を具体的に書くと、Claudeが会話の文脈からスキルを自動選択します。副作用のある処理（本番デプロイなど）はdisable-model-invocation: trueを付け、人間が/deployと明示呼び出しする設計が推奨されています。
!git diff HEAD“のような動的コンテキスト注入を使えば、実行時点のdiffやコマンド結果をプロンプトに埋め込めます。毎回「今の差分を見て」と書く必要がなくなります。
FAQでも、再利用可能なプロンプトはSkillsで作り、Claudeに書かせてよいと案内されています（Claude Code ユーザーFAQ）。
第3層：Hooksで「絶対守らせたいこと」をコード化する
CLAUDE.mdの指示はコンテキストであり、100%の強制力はありません。コミット前に必ずテストを走らせたい、特定ディレクトリへの書き込みを止めたい場合は、Hooksが適切です。ツール実行の前後でシェルが必ず動くため、Claudeの判断に依存しません。
今日からの導入手順
- リポジトリで
claudeを起動し、/initでCLAUDE.mdの草案を作る - 週に3回以上繰り返している作業を1つ選び、
.claude/skills/にSKILL.mdを置く（まずは/code-reviewなどバンドルスキルの動きを観察してもよい） - フォーマットやlintを毎回忘れるなら、
/hooksからPostToolUseフックを追加する - 長いセッションの区切りで
/clearし、無関係な履歴を捨てる
プロンプトに書くのは「何を達成したいか」と「どうなれば完了か（テスト・ビルド・スクリーンショット比較など）」に絞ります。手順の細部はSkillsとCLAUDE.mdに任せる、という分担です。
API向けプロンプトはConsoleのジェネレータと連携する
Claude Code内に「チャット文を自動生成する」専用ボタンはありません。一方、Anthropic Consoleには、目的の説明からプロンプトテンプレートを生成するPrompt Generatorと、既存テンプレートを改善するPrompt Improverがあります。変数は{{variable}}形式で、chain-of-thoughtやXML構造などのベストプラクティスが組み込まれます（Console prompting tools）。
使い分けの目安は次のとおりです。
- リポジトリ内の開発作業 → CLAUDE.md・Skills・Hooks
- Claude APIに渡す本番プロンプト → Consoleで生成・評価し、コードに組み込む
- CIやスクリプト →
claude -p "指示"で非対話実行（ベストプラクティス）
「プロンプトを書くな」はAPIプロンプトを不要にする意味ではなく、同じ指示を毎回手打ちするなという意味に近いです。メタプロンプトでテンプレートを作り、Skillsで現場手順を固定する——二段構えにすると、再現性と改善のしやすさが両立します。
よくある誤解
誤解1：何も指示しなくてよい
ゴールと検証基準は人間が渡します。変わるのは、手順の繰り返しをファイル化することです。
誤解2：CLAUDE.mdに全部書けばよい
長い手順書はSkillsへ。パス限定のルールは.claude/rules/でスコープを絞ります。
誤解3：公式動画を見なくても雑談ポストだけで十分
話題の起点となった投稿（元ポスト）は要約です。実装の細部はCode w/ Claudeのベストプラクティス動画やPrompting 101など、Anthropic公式チャンネルの解説とドキュメントをセットで参照するのが安全です。
締めくくり
Claude Codeを使いこなすとは、長文プロンプトの巧みさを競うことではありません。CLAUDE.mdで前提を固定し、Skillsで手順を再利用し、Hooksで破れないルールを足す——この3層をリポジトリにコミットしていく運用が、Anthropicが示す実務的な答えです。
次に同じ説明をチャットに打ちそうになったら、一度止めて「これはSkillか、CLAUDE.mdか」と分類してください。1ファイル追加するだけで、次のセッションからClaudeは自分への指示書を読みに行きます。