improving-prompts

プロンプトの改善

概要

Anthropic が現在公開しているベストプラクティスを既存のプロンプトに適用します。「改善」をでっち上げず、実際のガイダンスを使ってください。

使用する場面

• CLAUDE.md ファイルまたは AGENTS.md ファイルを最適化する
• カスタムコマンドのプロンプトを改善する
• スキルの指示を見直す
• プロンプトを現在の Claude モデル（4.x）に移行する

使用しない場面

• 新しいプロンプトをゼロから作成する（ベストプラクティスに直接従ってください）
• プロンプトが問題なく機能しており、ユーザーが問題を指摘していない

根本的な問題

このスキルがないと、エージェントは次のようなことをします。

• 一般知識から「ベストプラクティス」をでっち上げる
• 何が問題なのかを尋ねずに構造を変更する
• 構造を増やせばよくなると考え、複雑さを加える
• 問題を解決するのではなく、価値を示すために変更する

次のような考えが浮かんだら中断してください

これらは失敗につながる考え方です。次のいずれかを考えたら、作業を止め、まず具体的な問題を確認してください。

考え	実際のところ
「曖昧すぎる／ベストプラクティスに沿っていない／一貫性がない」	具体的な対応につながりません。どの動作に問題がありますか？
「十分な状況が分かった」／「ユーザーはこう望んでいるはず……」	具体的な失敗を挙げられないなら、十分ではありません。質問してください。
「自分は専門家だ」／「自分ならこう書く」	専門性があっても、具体的な問題の確認を省略することはできません。あなたはユーザーではありません。
「一般的なベストプラクティスに基づいて……」	文書化されたプラクティスを使ってください。ガイダンスを示してください。
「構造化すれば常によくなる」	構造化は構造上の問題を解決しますが、あらゆる問題を解決するわけではありません。
「時間がない。明日デモがある」	プレッシャーの中で最悪の変更が行われます。
「これは明らかな改善だ」	自分にとって明らかでも、ユーザーの実際の問題を解決するとは限りません。
短いプロンプトに10個以上の変更を加えようとする	中断してください。どの具体的な問題を解決しようとしていますか？

必須の手順

ステップ 1：変更前に理解する

変更を加える前に、必ず次のことを確認してください。

1. どの具体的な動作に問題があるのかを尋ねる
2. 現状では実現できていないが、プロンプトで何を実現したいのかを尋ねる
3. ユーザーが「とにかく全般的に改善して」と言った場合は、具体的な問題を少なくとも1つ挙げてもらう

「具体的な問題」に該当する例：

• 「Claude が簡潔にするという指示を無視します」✓
• 「Claude が変更を提案しますが、実装しません」✓

該当しない例：

• 「曖昧すぎる」✗（何について曖昧ですか？）
• 「ベストプラクティスに従っていない」✗（どのプラクティスですか？何に問題がありますか？）

思い込みに基づく一般的な「改善」は行わないでください。

ステップ 2：実際のベストプラクティスを参照する

詳しくは references/anthropic-best-practices.md を参照してください。主な原則は次のとおりです。

指示を明確にする： 現在のモデルは指示に忠実に従うため、曖昧な依頼は狭く、文字どおりに解釈されます。「期待以上の成果」を求めるなら、そのように明示してください。

適用範囲を明示する： 現在のモデルは、一度だけ示した指示を暗黙に一般化しません。「最初のセクションだけでなく、すべてのセクションに適用してください」と指定してください。

背景や目的を加える： 何をすべきかだけでなく、なぜルールがあるのかを説明してください。Claude は説明から一般化します。「省略記号は絶対に使わないでください」ではなく、「テキスト読み上げエンジンが省略記号を発音できないため、省略記号は使わないでください」と伝えます。

例には注意する： 例は意図しないパターンも含めて、そのまま模倣されます。望ましい動作に沿った例を3～5個、<example> タグで囲んで使用してください。

思考と作業量： 手順を一つずつ手書きで指定するより、一般的な指示（「十分に考えてください」「完了する前に、[基準]に照らして回答を検証してください」）を優先してください。拡張思考を使わない場合は think という語を避ける、という以前のルールは、現在は適用されません。現在のモデルでは、適応型思考と effort が使われます。

冗長さを明示的に制御する： Opus 4.7 は、タスクの複雑さに対する認識に応じて回答の長さを調整します。ワークフローで長さを固定したい場合や、ツール使用後の要約が必要な場合は、そのように指定してください。

ツールの使用： 「変更案を提案してください」は提案のみを求める指示です。「これらの変更を行ってください」は編集を求める指示です。実行するのか、助言するのかを明確にしてください。

強いトリガー表現を控える： 「Xが役立つ場合は使ってください」のような表現を、「重大：Xを必ず使わなければなりません」より優先してください。現在のモデルは、強い表現により過剰に反応し、必要以上に調査する傾向があります。

ステップ 3：うまくいっている部分を維持する

• 問題のないセクションは再構成しないでください
• 明示された問題の解決に必要な場合を除き、複雑さを加えないでください
• 特に依頼されていない限り、トーンや文体を変えないでください
• 正しい動作を示している場合は、ユーザーの例を残してください

ステップ 4：根拠を添えて変更を提案する

変更ごとに、次の内容を説明してください。

1. どの具体的なベストプラクティスを適用するか
2. どの問題を解決するか
3. 変更前／変更後

文書化されたガイダンスとの関連を示さずに、変更を加えないでください。

クイックリファレンス：問題 → 解決策

問題	解決策
出力の範囲が狭い／汎用性がない	対象範囲を明示する（「すべてのセクション」「すべてのケース」など）
Claude が推論を説明しない	推論の説明を求めるか、effort の値を上げる
Claude の説明が冗長すぎる	「簡潔に」または「X 文で回答する」と指示する
Claude の説明が簡潔すぎる	「詳しい説明をする」と指示する
Claude が提案するだけで実行しない	「できますか？」を命令形の「〜してください」に変える
指示に従わない	それが重要な理由を伝える
出力が例と一致しない	例が望ましい形式を正確に示すようにする
CLAUDE.md が長すぎる／無視される	削除しても誤りにつながらない行を削除する（200 行未満を目標とする）