openai-reusable-prompts

OpenAI の再利用可能なプロンプト

概要

このスキルでは、高品質なプロンプトの作成と、明確さ、一貫性、モデルのステアリング精度を高めるための書式設定にのみ焦点を当てています。

信頼性の高い出力を実現するために、プロンプトの構成、表現の質、例、書式のパターンを定義するのに役立ちます。

詳しい OpenAI のプロンプトエンジニアリングガイドについては、references を参照してください。

使用する場合

• 指示の優先順位が明確な、より質の高いプロンプトを作成したい場合。
• タスクやチーム間でプロンプトの書式を統一したい場合。
• 明確な例と制約を備えた、再利用可能なプロンプトテンプレートが必要な場合。
• 一貫性のない出力を生む、曖昧なプロンプトを改善したい場合。
• 複数のエージェントやチームで共有する、安定した再現可能な手順を標準化したい場合。
• バージョン管理し、時間をかけて個別に改善できる、再利用可能な動作を定義したい場合。

使用しない場合

• API 連携コード、デプロイ、またはバージョン展開の戦略を求めている場合。
• プロンプト作成のガイダンスではなく、実行時の実装の詳細が必要な場合。
• 再利用可能な構成が不要な、真に一度限りの依頼である場合。
• 手順が日々変化し、まだ安定していない場合。
• 主に外部の最新状態や副作用を伴うタスクの場合。その場合はツールまたは API を使用してください。

必要な入力

次の情報を提示するか、推測してください。

• 成果：プロンプトが生成すべきもの。
• 対象者またはタスクの種類：誰が出力をどのように使うか。
• 出力仕様：自由記述、Markdown、JSON、またはスキーマで制約された出力。
• 制約：スタイル、トーン、安全上の制限、禁止される動作。

関連する場合は、入力例と期待される出力も含めてください。

詳細が不足している場合は、使用可能な v1 テンプレートを作成するために必要な最小限の情報のみを尋ねてください。

振り分けのガイダンスと例外

• 再利用可能な手順、安定した執筆基準、または組織全体で適用するプロンプトの規約には、このスキルの使用を優先してください。
• 厳密な構成を必要としない、その場限りのブレインストーミングをユーザーが求めている場合は、このスキルの使用を避けてください。
• 振り分けの精度を高めるため、作成するプロンプト一式には肯定例と否定例の両方を含めてください。
• 振り分けが一貫しない場合は、スクリプトや実行時コードを変更する前に、frontmatter の name、description、および例を改善してください。

手順

1. 目標とする動作を定義する

   • プロンプトの目的を1文で記述します。
   • 成功を、観察可能な出力基準として定義します。

2. 指示の優先順位を設定する

   • 優先度の高い動作を先に記述します。
   • 必須ルールと推奨事項を分けます。
   • モデルがすべきこと、してはいけないことを明示します。
   • 再利用可能なアプリケーションルールは、Responses API の instructions パラメーターまたは developer メッセージに記述します。これらは user 入力よりも優先されます。
   • previous_response_id を使う場合、前のターンの instructions に依存しないでください。再度送信してください。

3. 一貫した書式でプロンプトを作成する

   • 必要に応じて、次の順序で明確なセクション見出しを使います：Identity、Instructions、Examples、Context。
   • 指示は明確かつ検証可能にします。
   • たとえば {{customer_name}} のように、動的な値にはプレースホルダーを使います。
   • プロンプトキャッシュの節約効果を高めるため、安定して繰り返し使う内容は冒頭付近に配置します。

4. 書式の厳守を強化する

   • 制約や出力ルールには箇条書きを使います。
   • 役立つ場合は、入出力例のブロックに XML 形式の区切りを使います。
   • 要件が埋もれるような長い段落は避けます。

5. 動作を教える例を追加する

   • 信頼性の向上に大きく役立つ場合、特に厳密な形式が求められる場合は、多様な例をいくつか追加します。
   • 一般的な入力と境界事例を扱います。
   • 例と記載済みのルールに一貫性を持たせます。

6. 出力契約の確認事項を追加する

   • 形式の要件（フィールド、順序、使用可能なラベル）を正確に指定します。
   • 逸脱を減らすため、明示的な禁止事項を追加します。

7. 明確さと簡潔さを見直す

   • 重複する指示を削除します。
   • 曖昧な表現を、測定可能な要件に置き換えます。
   • モデルの判断に影響するコンテキストだけを残します。
   • GPT モデルには正確な指示を使います。推論モデルでは、まず上位の目標を示し、評価結果で必要だと分かった場合に詳細を追加します。

8. プロンプトをスキル成果物として使う場合、運用準備に関する注意事項を追加する

   • 使用するタイミング、実行方法、期待される出力、注意点を記載します。
   • 脆弱な複数ステップのワークフローには、明示的な検証手順と出力確認項目を追加します。

分岐ロジック

• 出力が厳密なスキーマに従う必要がある場合： フィールドごとの書式ルールと、スキーマ形式の例を明示します。

• 顧客やロケールによって動作が異なる場合： グローバルルールは一定に保ち、ロケール固有のルールは専用のコンテキストブロックに分けます。

• プロンプトが長く複雑な場合： セクションを明確に分け、重要でないコンテキストを削除します。

• 推論が多く、要件が不十分な場合： 目標と制約から始め、失敗を確認した後に例を追加して絞り込みます。

• タスクが決定的で、書式に敏感な場合： 厳密な書式指示と、非常に具体的な例を使います。

品質基準

以下のすべてを満たした場合、スキルの実行は完了です。

• プロンプトの目的と出力契約が明確である。
• 指示の優先順位（必須事項と推奨事項）が明確である。
• セクション間で書式に一貫性がある。
• 例が、求められる動作と形式を補強している。
• 曖昧な表現が取り除かれている。
• 振り分けの精度を高めるため、望ましくないトリガーの例が含まれている。
• 複数ステップのワークフローを実行する場合、検証手順と出力確認項目が定義されている。
• 本番環境のプロンプト変更に対し、代表的なフィクスチャ、テスト、評価確認項目が用意されている。

API のデプロイに関するガイダンス

• 新しい OpenAI API の作業では、プロンプトは再利用可能なプロンプトオブジェクトではなく、アプリケーションコードで管理してください。
• 対応する機能の近くに、小規模なプロンプトビルダーモジュールを配置してください。
• 動的な値には、型付き関数入力またはスキーマを使用してください。
• 生成した instructions と input を Responses API に直接渡してください。
• 本番環境では特定のモデルスナップショットを固定し、プロンプトやモデルを変更する前に動作を評価してください。
• 通常のデプロイ管理を通じて変更を展開してください。段階的なリリースには、機能フラグまたは設定を使用してください。
• 再利用可能なプロンプトオブジェクトは非推奨です。作成は 2026 年 6 月 3 日に推奨されなくなり、v1/prompts は 2026 年 11 月 30 日に終了する予定です。既存のプロンプトオブジェクトとの統合に限り、OpenAI の移行ガイドを使用してください。

エージェントスキルのパッケージ化

プロンプトテンプレートを OpenAI API のプロンプトオブジェクトではなく、エージェントスキルとしてパッケージ化する場合は、以下を適用してください。

1. スキルを見つけやすくします。

   • 明確な frontmatter name と description を使用してください。
   • 「使用する場合」と「使用しない場合」のガイダンスを明記してください。
   • 肯定的な例とあわせて、否定的な例も含めてください。

2. システムプロンプトは簡潔にします。

   • 安定して再利用できる手順はスキルに記述してください。
   • グローバルポリシーと常時有効な動作はシステムプロンプトに記述してください。
   • スキルの手順全体をシステムプロンプトに重複して記載しないでください。

3. スクリプトを利用するスキルは、小規模な CLI として設計します。

   • コマンドがコマンドラインから実行できるようにしてください。
   • 主要なステータスと結果を示す stdout が決定的になるようにしてください。
   • 明確な使用方法または検証エラーを表示して、問題があれば確実に失敗するようにしてください。
   • 出力は、既知の文書化されたファイルパスに書き込んでください。

4. スキルのアセットに実行例を含めます。

   • 入力、コマンド、期待される出力を提示してください。
   • 通常のケースに加えて、少なくとも 1 つの境界ケースを取り上げてください。

5. 明示的な検証ゲートを追加します。

   • 出力形式と必須フィールドを検証してください。
   • 想定されるパスに成果物が存在することを確認してください。
   • 処理の一部しか完了していないことを検出するチェックを追加してください。

6. ネットワークアクセスは慎重に扱います。

   • 可能な限り、ネットワークを使用しない実行を優先してください。
   • ネットワークアクセスが必要な場合は、厳格な許可リストと明示的なデータ送信制約を使用してください。

7. 複数ステップのワークフローを確実に完了できるモデルを使用します。

   • 実行が不安定な場合は、ワークフローを簡素化し、検証ガイダンスを強化してください。

再現性とバージョン管理

• プロンプトとプロンプトビルダーをソース管理下に置き、コードレビューを通じて変更してください。
• 再現性が重要な場合は、本番環境で特定のモデルスナップショットを固定してください。
• プロンプトの動作を確認するため、代表的なフィクスチャ、テスト、評価スイートを維持してください。
• プロンプトの変更はアプリケーションとともにバージョン管理してデプロイしてください。段階的なロールアウトには、機能フラグまたは設定を使用してください。
• このガイダンスをエージェントスキルとしてもパッケージ化する場合は、API プロンプトとは別にスキルのバージョンを管理してください。

成果物

以下を作成してください。

1. コード管理する instructions または developer メッセージ用の再利用可能なプロンプトテンプレート（手順 1～4）
2. プロンプト形式のチェックリスト（手順 6）
3. 改善した例のセット（適切な例と境界ケース。手順 5）
4. 重要な明確化の変更を説明する、プロンプトの書き換えに関する注記（手順 7）
5. 運用準備に関する注記（実行方法、期待される出力、注意点、検証チェック。手順 8）

コード管理するプロンプトテンプレート

Responses API に送信する instructions の値または developer メッセージとして、これを使用してください。対応する機能の近くでソース管理してください。

既存の保存済みプロンプトオブジェクトがある場合は、新たに再利用可能なプロンプトオブジェクトを作成せず、コードに移行してください。

# Identity

You are an assistant that {role-purpose}.

# Instructions

- Primary objective: {objective}
- Required constraints: {constraints}
- Output requirements: {format-rules}
- Never do: {prohibited-behaviors}

# Examples

<input id="example-1">
{example-input-1}
</input>
<output id="example-1">
{example-output-1}
</output>

# Context

{stable-reference-context}

スキル作成用の追加テンプレート（実行可能なスキルのワークフロー向け）

プロンプトパッケージをスクリプトやアセットとともにスキルとして実行する場合は、この補助テンプレートを使用してください。

# When to use

- {positive-trigger-1}
- {positive-trigger-2}

# Do not use when

- {negative-trigger-1}
- {negative-trigger-2}

# Inputs

- {input-contract}

# How to run

- {install-command}
- {run-command}

# Expected outputs

- {path-1}: {artifact-description}
- {path-2}: {artifact-description}

# Gotchas

- {failure-mode-1}
- {failure-mode-2}

# Verification checks

- {check-1}
- {check-2}

# Worked examples

<input id="example-1">
{example-input-1}
</input>
<run id="example-1">
{example-command-1}
</run>
<output id="example-1">
{example-output-1}
</output>

プロンプト形式のチェックリスト

プロンプトを改訂するたびに、このチェックリストを使用してください。

- [ ] Objective is one sentence and testable
- [ ] Required behavior is listed before optional preferences
- [ ] Output format is explicit and easy to verify
- [ ] Examples are diverse and included when they materially improve reliability
- [ ] Negative constraints are included
- [ ] Context is minimal and relevant
- [ ] No contradictory instructions
- [ ] "Use when" and "Do not use when" routing guidance is explicit
- [ ] At least one negative trigger example is included
- [ ] Prompt is code-managed, model snapshot is pinned when needed, and rollout intent is defined
- [ ] Verification steps and output checks are defined for multi-step workflows

プロンプトのスターターパターン

• 「意図を保ったまま、このプロンプトを Identity、Instructions、Examples、Context の各セクションを使って書き直してください：{prompt}。」
• 「曖昧さをなくし、次の形式を徹底できるよう、このプロンプトを簡潔にしてください：{format-rules}。」
• 「次の動作を教える、質の高い例を追加してください：{objective}。」
• 「この長い段落形式のプロンプトを、制約を明示した簡潔で構造化されたプロンプトに変換してください。」

ガードレール

• プロンプトのテキストにシークレットや個人データを含めないでください。
• 複数のセクションに矛盾する指示を混在させないでください。
• 正確さが求められる場合、出力形式を暗黙のままにしないでください。
• 1つの例に過剰適合させないでください。多様な例を使用してください。
• 再利用可能な開発者向け指示の中に、スキルの手順全体を重複して記載しないでください。
• 厳格な許可リストと明示的なデータ送信ルールなしに、オープンネットワークアクセスに依存しないでください。
• スクリプトを使用するワークフローでは、出力パスを未定義のままにしないでください。