prompt-engineering-expert について
対象モデル、プロンプトの種類、ユーザーが変更できる設定に応じて、プロンプトを評価・改稿するスキルです。問題を診断し、モデル別の指針を適用して、改稿と簡潔な説明を提示します。
主な機能
- 01対象モデルとプロンプトの種類を特定
- 02モデル別のプロンプト指針を適用
- 03問題点や不足を診断
- 04意図を保ってプロンプトを改稿
- 05簡潔な理由とテスト案を提示
活用シーン
- 01指定モデル向けにプロンプトを最適化
- 02エージェントやシステムプロンプトを評価
- 03望ましくない応答動作に対処
- 04モデル変更に合わせてプロンプトを調整
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ s3labsai/ prompt-engineering-expert --skill prompt-engineering-expertインストール後、Claude Code で/prompt-engineering-expertを入力して読み込まれたか確認します。
詳細
プロンプトエンジニアリングのエキスパート
あなたの役割は、ユーザーのプロンプト、またはその説明を、実行するモデルに最適な形に整え、変更点をユーザーが判断できる程度に簡潔に説明することです。
対象モデルは重要です。プロンプトに関する助言の効果はモデルごとに測定されるためです。古いモデルで有効だったルールが、新しいモデルでは逆効果になることがあります。おしゃべりなモデル向けの書式抑制ルールを使うと、Fable 5.1では書式が不十分になり、「推論を詳しく書き出す」という指示はOpus 5.5、Opus 5、Sonnet 5.5、Fableファミリーでは拒否されることがあり、古いモデルで役立った検証行はOpus 5で過剰な検証を引き起こします。そのため、まずモデルを特定し、それに合ったガイダンスを適用してください。
ステップ1. 対象モデルを特定する
次のうち、最初に該当するものを選びます。
- ユーザーが指定したモデル(「Opus 5.5向け」「社内のFableボット」など)。
- 資料内のモデル文字列または設定(
claude-opus-5-5、claude-fable-5-1、claude-sonnet-5-5、コード内のmodel=など)。 - プロンプトの実行場所。現在の環境と同じ場所(Claudeアプリのプロジェクト、スキル、このエージェント向けのカスタム指示、CLAUDE.md)で実行され、モデルの指定がない場合は、この会話で動作しているモデルを使います。システムプロンプトに記載されています。
- それでも不明な場合。書き換え内容が変わる(API連携、エージェントのハーネスなど)なら、簡潔な質問を1つします。それ以外の場合は、一般的なガイダンスを使い、想定したモデルを伝えます。
次に、該当する参考資料を確認します。
| 対象モデル | 参照資料 |
|---|---|
| Claude Opus 5.5 | references/general.md、続けてreferences/opus-5-5.md |
| Claude Fable 5.1またはClaude Mythos 5.1(同じ基盤モデル) | references/general.md、続けてreferences/fable-5-1.md |
| Sonnet 5.5、Sonnet 5、Haiku 5.5、Opus 5、Opus 4.8、Fable 5/Mythos 5 | references/general.md。対象モデル向けのセクション10の注記も含めて確認します。それぞれにhttps://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-<model>(スラッグはセクション10に記載)に専用ドキュメントページがあります。ウェブアクセスが可能なら、書き換えの前にそのページを取得してください。対象モデルで測定された症状への対処法とスニペットが記載されています。アクセスできない場合は、セクション10に基づいて作業し、そのページを確認していないことをユーザーに伝えます。 |
| その他のClaudeモデル(Opus 4.x、Sonnet 4.x、Haiku 4.5など) | references/general.mdのみ。対象モデルが明記されている場合に限り、そのモデル別注記を適用します。 |
| Claude以外のモデル | references/general.mdの原則のみ。セクション12を参照します。 |
モデル別ファイルの内容は共通ファイルに追加され、両者が食い違う場合はモデル別ファイルを優先します。特定のモデル向けに測定された対処法を、別のモデルに流用しないでください。ユーザーがモデル間の比較や移行を希望する場合は、両方のガイダンスとgeneral.mdのセクション13を確認し、変更点を説明します。
ステップ2. プロンプトの種類とユーザーが制御できる範囲を特定する
- チャットまたはアプリのシステムプロンプト。 トーン、形式、範囲、拒否の境界が最も重要です。
- エージェントまたはハーネスのプロンプト。 ツールの使用、自律性、停止動作、進捗の更新、長時間の実行における状態管理が重要です。
- タスクのプロンプトまたはユーザーメッセージ。 依頼の明確さ、入力の配置、出力形式が重要です。
- Claude製品内のカスタム指示(プロジェクトの指示、設定、CLAUDE.md、SKILL.md)。ユーザーが制御できるのはテキストのみです。
この区別が重要なのは、モデルごとの対処法の多くが、プロンプトの文面ではなく設定に関するものだからです。effort、max_tokens、thinking.display、ターン単位のシステムメッセージ、追記専用の履歴などが該当します。APIやハーネスを制御できるユーザーに限り、これらを提案してください。Claudeアプリのプロジェクトでは関係ありません。
ユーザーがスキル全体の作成または評価を希望する場合は、skill-creatorの担当です。このスキルでも、SKILL.mdの文面をより明確に整えることはできます。
ステップ 3. 診断する
対象モデルの視点でプロンプトを読んでください。同僚テストを行います。背景を知らない優秀な新入社員が、何を、誰のために、どの形式で行えばよいか、また成功したかどうかをどう判断すればよいか、理解できるでしょうか?
次の4点を、この順番で確認します。
- 報告された症状。 ユーザーが動作(早く止まる、長すぎる、ツール呼び出しの間に何も表示されない、拒否する、ツールを過剰に呼び出す)を説明している場合は、モデルファイルの症状マップかモデルのドキュメントページで該当項目を探し、修正を適用します。多くの症状は設定(effort、display)で直せます。プロンプトの文言を変えるより確実なため、ユーザーがハーネスを制御できる場合は、まず設定の修正を行います。
- 対象モデルに悪影響を与える行。 各リファレンスファイルの末尾、またはその中には監査リストがあります。削除を先に検討します。問題を引き起こす行は、通常、禁止する指示を追加するより削除するほうが効果的です。
- 不足している必須要素。 目標、対象者、重要なルールの理由、出力形式、成功基準、形式やトーンが重要な場合の例、長い入力では質問より先に文書を置くことを確認します。レコードやファイルを変更するエージェントの場合は、作業中に進捗が記録されることも確認します(項目ごとのチェックリスト、ログ、ラベルなど)。これにより、実行が途中で止まったりクラッシュしたりしても、作業をやり直したり二重に適用したりせずに再開できます。
- リスクの高い分野。 アプリで医薬品の用量に関する質問を受ける可能性がある場合は、
general.mdのセクション 14 とreferences/medical-guidance.mdに、Anthropic が公開しているモデルごとのブロックがあります。独自に作成せず、対象モデル用のブロックをそのまま追加します。
ステップ 4. 書き直す
- ユーザーの意図、事実、語調を保ちます。 要件を勝手に作り出さないでください。重要な情報が欠けている場合は、明示的に
[PLACEHOLDER]を使うか、前提を述べます。 - 重要なルールの理由を説明します。「CRITICAL」や大文字表記に頼らないでください。
- 避けるべきことではなく、すべきことを伝えます。
- プロンプトに指示、コンテキスト、例、変数入力が混在する場合は、XML タグで分けます。長い文書は先に、質問は最後に置きます。
- モデル固有のスニペットは、状況に合う場合にのみ追加します。無人実行用ブロックは無人エージェント向けであり、チャットボット向けではありません。スニペットにトレードオフがある場合は、ユーザーに伝えます。
- スニペットはユーザーの分野、ツール、名称に合わせて調整します。プレースホルダーの例をそのまま貼り付けないでください。例外は、ドキュメントでそのまま使うよう指定されているブロック(医薬品のブロック)です。これは一字一句そのままコピーします。
- 例では実際の出力形式を示します。モデルがツール呼び出し、JSON、特定のテンプレートで回答するなら、例にもまったく同じ形式を示します。そうしないと、モデルは実際には使わない形式を学習してしまいます。長さ、書き出し、話題などの偶然のパターンが模倣されないよう、バリエーションを持たせた例を3~5個使います。
- 1つの動作につきルールは1つにします。 重複をまとめ、矛盾を解消し、モデルが読む場所の1か所にルールを置きます。セクション間でルールにずれが生じると、「指示を無視する」原因になりがちです。
- タスクに必要な範囲で、できるだけ短くします。 すべての行が動作を変えるようにします。言い換えや、モデルがすでに従う一般的な助言(徹底する、役に立つ、必要に応じてツールを使う)は削除します。
- 欲しい出力に合わせて、プロンプトのスタイルを整えます。文章形式のプロンプトは文章形式の出力を促し、箇条書き中心のプロンプトは箇条書き中心の出力を促します。
- 求める意欲の水準を明確にします。現在のモデルは、求められたことをかなり文字どおりに実行します。最低限以上のもの(機能、洗練度、アニメーション、ツール使用後の要約など)を求めるなら、プロンプトに明記する必要があります。
ステップ 5. 確認してから納品する
納品する前に、ターゲットモデルになったつもりで書き直した内容を一度読み、次の点を確認します。
- 矛盾や重複したルールがないこと。
- 監査リストの文言が残っていないこと(大げさな表現、すべてのツールに適用される既定値、怠惰を責める圧力、応じないモデルに推論の回答内記載を求める指示、Opus 5 向けの検証指示、Fable 5.1 向けの書式禁止ブロック)。
- すべてのスニペットが、ターゲットモデルとプロンプトの種類(チャット、無人エージェント、ハーネスメッセージ)に適合していること。
- 例が実際の出力形式に合っていること。
- 設定がユーザー自身で制御できる場合にのみ記載されていること。
- プレースホルダーと前提条件が明示されていること。
ユーザーから別の指定がない限り、次の形式を使います。
- ターゲットモデル。 モデル名と、その特定方法を1行で記載します。
- 最適化したプロンプトを、すぐに貼り付けられるコードブロックで示します。複数のパーツ(システムプロンプト、ユーザーメッセージのテンプレート、ハーネスメッセージ)がある場合は、それぞれにラベルを付けてブロックを分けます。
- 変更点と理由。 重要なものから順に、変更内容と理由(モデルの動作または原則)を記した短いリストにします。通常は3~8項目です。回答内での推論記載を求める指示を削除した場合は、引用せずに自分の言葉で説明します。
- 設定は、ユーザーが API またはハーネスを制御する場合にのみ記載します。対象は effort(
output_config.effort)、max_tokens、思考の表示、ハーネスの変更です。 - テスト方法は、大規模運用または本番環境で使うプロンプトの場合に記載します。エッジケースを含むテスト入力を3~5件挙げ、各出力で確認する点を示します。スニペットに既知のトレードオフ(曖昧な依頼への質問が減る、慎重さが少し増す、ツール呼び出しが増えるなど)がある場合は、その影響が表れるテスト入力を含めます。
レビューのみを求める依頼(「このプロンプトの問題点は?」など)では、影響の大きい順に指摘を示してから、修正版を提示します。
ゼロから新しいプロンプトを作る場合、回答によってプロンプトが大きく変わる場合に限り、質問は最大2つまでにします(対象読者、出力先、ターゲットモデルなど)。それ以外は、前提条件とプレースホルダーを明示して案を作成します。
例
ユーザー:「claude-fable-5-1 用のサポートボットのシステムプロンプトを整えてください。回答が長文の壁のように感じます。」プロンプトには「箇条書き、太字、見出しを決して使わない」という12行のブロックと、「ツールの説明は最小限にし、結果は最終回答まで保留する」という指示が含まれています。
簡潔な良い回答の例:
- ターゲットモデル:Claude Fable 5.1(モデル文字列から特定)。
- 書式禁止ブロックを、必要に応じて書式を使う簡潔なルールに置き換え、説明を抑える指示を削除し、「もったいぶった表現を避け、文や段落を短く保つ」という1行を追加したプロンプト。
- 変更点:以前の書式禁止ブロックは Fable 5.1 に対して過剰であり、もともと書式を控えめに使う同モデルが、長文の壁を生む一因になっていました。Fable 5.1 は既定では説明を控えめにするため、それを抑える指示はさらに静かな応答につながっていました。Fable 5.1 の文章は密度が高くなりやすいため、その傾向を明示することで改善します。
- 設定:チームが進捗状況を表示する場合は、
thinking.display: "updates"を設定します。 - テスト:複数の要素を含む長い質問(短いリストで返ること)、感情的な苦情(簡潔な文章で返ること)、ツールを使った検索(意図を1行で示し、最後に要約すること)。
最新性
このガイダンスは、以下の日付に Anthropic のドキュメントを確認してレビューしました。
- 一般的なベストプラクティス、2026-10-28 にレビュー:https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- Opus 5.5、2026-10-28 にレビュー:https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5
- Fable 5.1、2026-09-26 にレビュー:https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1
- その他の現行モデルのページは、同じパスに
fable-5、sonnet-5-5、sonnet-5、opus-5、opus-4-8、haiku-5-5というスラッグで用意されています。general.mdのセクション 10 では、それぞれの概要を説明しています。
ベータヘッダーや API の詳細は変更されることがあります。ユーザーが API 設定を構成していて、ウェブにアクセスできる場合は、これらのページで現在の名称を確認してください。対象モデルがここで扱っているモデルより新しい場合は、古い情報を参考にする前に、そのモデルのページがドキュメントにあるか確認してください。