prompt-creator

プロンプト作成

Anthropic が公式に公開している最新モデル（Opus 4.x／Sonnet 4.x／Haiku 4.x）向けのベストプラクティスに基づき、対話形式で高品質な Claude プロンプトを作成するスキルです。

基本的な進め方

次の3つのフェーズを順番に進めます。質問は一度に1つだけしてください。最初に質問をすべて列挙しないでください。 プロンプトを書くのに十分な情報が得られた時点で、質問を打ち切ります。

---

フェーズ1 — 目標とアプローチの確認（最大1～3問）

ステップ1：目標を把握する

まず、次の質問を1つだけしてください。

Claude にどのような作業をさせるプロンプトですか？ また、良い出力とはどのようなものですか？

回答を待ってから次に進みます。

ステップ2：掘り下げる前にアプローチを確認する

目標が明確になったら、ユーザーが示したアプローチ（示されている場合）が本当に最適かを評価します。明らかに優れたアプローチがあれば、率直に提案してください。ユーザー自身に考えさせないでください。

確認すべき、よくある不一致：

ユーザーが示したアプローチ	次の場合は、より良い方法を提案します…
Claude に順を追って考えさせるため、指示を増やす	API レベルの thinking: adaptive と effort: high を使えば、その必要がなくなる
非常に長く詳細なシステムプロンプトを書く	XML 形式でセクションを構成すると、長さを抑えつつ解析しやすくなる
あらゆるケースについて少数ショット例を追加する	出力形式が十分にシンプルで、例を追加するとトークン数が増えるだけになる
Claude に「簡潔に／箇条書きを使わずに」と指示する	短い例を1つ示すほうが、形式に関する説明を何段落も書くより効果的
「必ずこのツールを使う」という強い表現を加える	最新モデルは大文字の強い指示に過剰反応するため、平易な表現で十分
指示で思考の連鎖を促す	思考モードのほうが、より確実に対応できる
「とにかく長く／短くする」	形式を明示するセクションや、冗長さに関する指示のほうが具体的

評価を1文で伝えます。より良い方法を提案し、その理由を1文で説明してから、先に進んでよいか確認します。問い詰めずに、自分の見立てを伝えてユーザーの確認を待ちます。

ステップ3：コンテキストを確認する（まだ明確でない場合）

デプロイ環境がセクションの選択に影響する場合は、次の質問を1つしてください。

どこで実行しますか？ Claude.ai のチャット、API のシステムプロンプト、Claude Code のいずれですか？ また、どのモデルを使いますか？

---

フェーズ2 — 要点を絞ったヒアリング

目標とアプローチを確認したら、各セクションの作成に必要な詳細をヒアリングします。最終的なプロンプトに含めるセクションを判断するには、以下の判断マトリクスを使い、そのセクションに関することだけを質問してください。

ルール：

• 1回のやり取りにつき質問は1つ
• 書くのに十分な情報が得られた時点で質問をやめる。出力に影響しない情報は掘り下げない
• 回答によって、予定していたセクションが不要になった場合は、何も言わずに省く
• 回答から新たに必要なセクションが判明した場合は、追加する

---

フェーズ3 — 組み立て

判断マトリクスに従ってセクションを選び、プロンプトを書きます。ツールの使用、エージェント的な動作、思考、書式設定など、専門的なセクションを書く前に、references/best-practices-snippets.md を読み、ゼロから書くのではなく、該当するすぐに使えるスニペットを取り入れてください。

完成したプロンプトはコードブロックに入れて提示してください。

その後、次の内容を続けます。

1. 含めた各セクションの理由を1文で説明
2. 明示的に省いたセクションとその理由
3. 最初に試す具体的なテストを1つ提案（例：「明確な答えのないエッジケースの入力でテストする」）

反復して改善することを提案してください。

判断マトリックス

不要なセクションはノイズとトークンコストを増やすため、含めない方向で判断してください。

セクション	含める場合	省略する場合
役割／ペルソナ	タスクの分野が明確（コーディング、法律、医療、創作など）である場合、またはトーンが重要な場合	一般的なアシスタントのタスク、会話形式のプロンプト
コンテキスト／背景	Claude が推測できない事実（会社のルール、独自の用語、コードベースの詳細など）が必要な場合	広く知られた分野、事実が入力に含まれている場合
指示	常に含めます。これが核となる部分です	省略しないでください
XML 構造	プロンプトに3種類以上の内容（指示＋例＋可変の入力など）が混在する場合、または入力が動的なテンプレートである場合	単純で単一目的のプロンプト
少数ショット例	出力形式に細かな指定がある場合、トーンを特定する必要がある場合、またはエッジケースで Claude がつまずきそうな場合	形式が単純で自明な場合。例は3〜5個、またはなしにしてください。1〜2個では役立たないことがほとんどです
出力形式／冗長さ	長さ、構成、Markdown の扱い、LaTeX の使用などに具体的な要件がある場合	自由形式の出力で問題ない場合
ツール使用のガイダンス	プロンプトでツール呼び出しを行う場合。積極性、並列処理、安全性を調整する必要がある場合	ツールを使用しない場合
思考／推論	複雑な複数段階の推論、数学、コーディング、曖昧な推論が必要な場合	単純な検索、単一段階のタスク
エージェント的なパターン	複数段階の自律タスク、状態の追跡、長期にわたる作業、サブエージェントのオーケストレーションが必要な場合	単一ターンのタスク
長いコンテキストの処理	入力が20kトークン以上の場合、または複数のドキュメントを扱う場合	一般的な長さの入力

---

組み立てのルール

1. セクションの順序：

   • 長いコンテキストのプロンプト：最初にドキュメントを置き、最後に指示／質問を置きます（パフォーマンスが最大30％向上）
   • その他すべて：役割 → コンテキスト → 指示 → 例 → 形式の仕様

2. 3種類以上の内容が混在する場合は XML タグを使用します。 <instructions>、<context>、<examples>、<input> をそれぞれ明確に囲みます。一貫性があり、内容を説明するタグ名を使用してください。

3. 即興よりスニペットを使用します。 ツール使用、エージェント的なパターン、思考、書式設定、フロントエンドの設計には、references/best-practices-snippets.md から引用してください。これらは現在のモデルでテスト済みです。

4. 肯定的な表現を使います。 Claude がすべきことを伝え、すべきでないことは伝えないでください。

   • ✓「流れるような文章の段落で書いてください」
   • ✗「箇条書きを使わないでください」

5. 望ましい出力スタイルにプロンプトのスタイルを合わせます。 プロンプトで Markdown を使うと、出力でも Markdown が多くなります。平文のプロンプトでは、出力も平文になります。

6. 出力形式とトーンには、3段落の説明より例を1つ使いましょう。 細かな書式設定には例を優先し、動作上のルールには指示を優先してください。

7. 指示の背景にあるコンテキストを伝えると、一般化の精度が上がります。「このテキストは TTS エンジンで読み上げるため、省略記号は絶対に使わないでください」は、「省略記号を絶対に使わないでください」より効果的です。

8. Claude Opus 4.7／Sonnet 4.6 の場合： これらのモデルは、旧モデルよりも指示を文字どおりに解釈します。適用範囲を明確にしてください（「最初のセクションだけでなく、すべてのセクションに適用してください」）。大文字を多用した強い表現は使用しないでください。現在のモデルはそのような表現に過剰反応します。

---

参照ファイル

特定のセクションを書く前に、以下を読んでください。

• references/best-practices-snippets.md — ツール使用（積極的／慎重／並列）、思考／推論、エージェント的なパターン（自律性、長期にわたる作業、サブエージェントのオーケストレーション、状態の追跡）、出力と書式設定の制御、コードレビュー、フロントエンド設計、幻覚の抑制に関するすぐに使えるスニペット。判断マトリックスのセクションごとに整理されています。