system-prompt-creator

System Prompt Creator

Claude（Anthropic）、GPT-5（OpenAI）、Gemini（Google）の公式プロンプトガイドに基づく、体系的で調査に裏付けられたプロセスを使って、あらゆる LLM に効果的なシステムプロンプトを作成します。

このスキルでは、ヒアリング、分析、構成、ドラフト作成、最適化の各段階を通じて、明確で構成が整い、対象モデルに合わせたシステムプロンプトを作成できます。

ワークフロー

以下の5つのステップを順番に進めます。各ステップは前のステップを踏まえて進みます。

Step 1: ヒアリング — 要件を収集する

何かを書く前に、ユーザーから次の必須情報を集めます。

1. 対象モデル — どの LLM ですか？（Claude、GPT、Gemini、オープンソース、またはモデル非依存）
2. ユースケース — AI に何をさせますか？（チャットボット、エージェント、コンテンツ生成、データ抽出、コードアシスタントなど）
3. ペルソナ — AI はどのような存在であるべきですか？（役割、専門知識のレベル、性格特性）
4. 対象ユーザー — 誰が利用しますか？（開発者、エンドユーザー、社内チーム、顧客）
5. 入力の種類 — ユーザーは何を送りますか？（自由記述のテキスト、コード、ドキュメント、画像、構造化データ）
6. 出力形式 — 回答はどのような形式にしますか？（文章、JSON、Markdown、コード、表）
7. トーンとスタイル — フォーマル、カジュアル、技術的、親しみやすい、のどれですか？簡潔にしますか、それとも詳しくしますか？
8. 制約事項 — 何をしてはいけませんか？（安全ルール、トピックの制限、行動の制限）
9. ツールと機能 — ツールを利用できますか？（API、ファイルシステム、ウェブ検索、コード実行）
10. 例 — 良い回答や悪い回答の例をユーザーから提示してもらえますか？

ユーザーの回答が曖昧な項目については、妥当なデフォルトを提案し、先に進む前に確認します。

十分な情報を集める: 基本情報を集めた後、「ユーザーはほかにどんなことを尋ねる可能性がありますか？」と尋ねます。多くのプロンプトが失敗するのは、中核となるタスクへの対応が不十分だからではなく、関連するシナリオを想定していないからです。請求に関するチャットボットにも、アカウントへのアクセス方法、製品に関する質問、苦情が寄せられます。コーディングエージェントには、機能の実装だけでなく、デバッグ、リファクタリング、プロジェクトのセットアップへの対応も必要です。作成前に、想定される対応範囲全体を整理します。

Step 2: 分析 — 複雑さと範囲を判断する

ヒアリングに基づいて、プロンプトの複雑さを分類します。

複雑さ	特徴	目安の長さ
シンプル	単一タスク、ツールなし、固定形式	50～200語
中程度	複数の動作、一部のツール、多様な出力	200～800語
複雑	エージェント型、複数のツール、長時間の処理、安全性が重要	800～2000語以上

次に、必要なセクションを決定します。

• 役割／ペルソナ — ほとんどの場合に必要
• コンテキスト／知識 — 専門分野の知識や背景情報が必要な場合
• 指示／ルール — 常に必要
• ドメイン別プレイブック — システムが複数の異なる運用シナリオに対応する場合（以下を参照）
• 出力形式 — 回答の構成が重要な場合
• 例 — 正確さと一貫性が重要な場合（多様な例を3～5件）
• ツールの使用 — モデルがツールや API を利用できる場合
• 安全性／ガードレール — 行動が現実世界に影響を及ぼす場合
• エージェント動作 — モデルが自律的に動作する場合

ドメイン別プレイブック: 複数の異なるワークフローに対応するシステム（実装、デバッグ、リファクタリング、レビューを行うコーディングエージェントや、請求、アカウント、技術的な問題に対応するサポートボットなど）には、シナリオごとに名前を付けたプレイブックを含めます。よくある状況について、一般的な指示から毎回アプローチを導き出させるのではなく、簡潔なステップ形式のパターンを示すことで、モデルに信頼できる判断手順を与えられます。プレイブックはシナリオ名ごとに整理し、<instructions> セクション内に配置します。

ステップ 3：構成 — レイヤー化アーキテクチャを適用する

次の汎用アーキテクチャを使ってプロンプトを整理します。ユースケースに関連するセクションのみを含めてください。

XML 構造（複雑なプロンプトに推奨）：

<role>
  Who the AI is, expertise, personality
</role>

<context>
  Domain knowledge, background information, constraints
</context>

<instructions>
  Core behavior rules, workflow steps, decision criteria
</instructions>

<output_format>
  Response structure, formatting rules, verbosity guidelines
</output_format>

<examples>
  3-5 diverse input/output pairs covering normal cases and edge cases
</examples>

<tools>
  Tool usage guidelines, when to use each tool, safety thresholds
</tools>

<guardrails>
  Safety boundaries, escalation rules, refusal criteria
</guardrails>

Markdown 構造（シンプルなプロンプトに適しています）：

# Role
...

# Instructions
...

# Output Format
...

構成が重要な理由： 指示、コンテキスト、例、入力が明確な境界なしに混在したプロンプトでは、モデルが各コンテンツの役割を取り違えることがあります。構造化タグを使えば、この曖昧さをなくし、指示への準拠を直接改善できます。

ステップ 4：草案作成 — 12 の汎用原則を適用する

これらの原則は、システムプロンプトを効果的にする要素について、主要な LLM プロバイダー 3 社すべての合意をまとめたものです。

A. 構成の原則

P1 — レイヤー化アーキテクチャ。 役割、コンテキスト、指示、形式、例、ガードレールなどを、ラベル付きの独立したセクションに整理します。これは、モデルが情報を解析し、優先順位を付ける方法に直接影響します。

P2 — 一貫したタグ。 XML タグまたは Markdown の見出しを一貫して使用します。異なる規則を混在させないでください。階層的なコンテンツ（サブドキュメントを含むドキュメント）には、タグをネストして使います。

P3 — コンテンツの順序。 長い参考資料は先頭に配置します。タスクやクエリは末尾に配置します。これだけで、複数のドキュメントを扱う複雑なタスクの品質が最大 30% 向上することがあります。「上記の情報に基づいて……」などのアンカーフレーズを使用します。

B. コンテンツの原則

P4 — 明確な意図と理由。 ルールが「何か」だけでなく、「なぜ」存在するのかも説明します。モデルは、簡潔な命令よりも理由から汎用的な学びを得やすくなります。

• 悪い例：省略記号は絶対に使わない
• 良い例：回答は TTS で読み上げられるため、省略記号は避けてください。TTS エンジンでは発音できません。

P5 — 肯定的な表現。 してはいけないことではなく、するべきことを述べます。

• 悪い例：Markdown を使わないでください
• 良い例：流れるような自然な文章で書いてください

P6 — 段階的な自律性。 エージェント型システムでは、行動の段階を明確に定義します。

• 安全（自由に実行可能）：ファイルの読み取り、検索、テストの実行
• 中程度（慎重に実行）：ファイルの編集、ブランチの作成
• リスクあり（要確認）：削除、強制プッシュ、公開投稿

P7 — 内部整合性。 矛盾は実害をもたらします。最新のモデルは、相反するルールの調整に推論トークンを浪費します。ルールに優先順位がある場合は明示します。「ルールが競合する場合は、タスクの完了よりユーザーの安全を優先してください。」

C. 調整の原則

P8 — モデルの知能に合わせて強度を調整する。 最新のモデルは大幅に高い能力を備えています。旧世代のモデル向けの強い指示（「重大：必ず……」など）は、過剰な反応を引き起こします。自然な言葉を使います。

P9 — 少数例学習の例。 例は、利用できる中で最も強力な誘導手段です。エッジケースを含む、多様な例を 3～5 件含めます。指示と区別するために <example> タグで囲みます。例だけで、明示的な指示を完全に置き換えられる場合もあります。

P10 — 制御する次元を分ける。 独立した軸が 3 つあります。推論の深さ（モデルがどれだけ深く考えるか）、出力の詳細度（回答の長さ）、温度（出力の多様性）です。それぞれに適切な制御を使い、混同しないでください。

D. エージェント型システムの原則

P11 — 状態管理。 長時間実行するタスクでは、エージェントが状態をどのように追跡するかを定義します。スキーマで定義されたデータには構造化形式（JSON）、進捗メモにはプレーンテキスト、復元可能なチェックポイントには git を使用します。

P12 — 自己検証ループ。 重要なセクションの末尾に、次のように記します。「最終化する前に、指定された基準に照らして出力を検証してください。」これにより、コード、データ抽出、構造化出力のエラーを確実に発見できます。

E. ドメイン固有のパターン

生データの保持（抽出／変換システム向け）。 入力データを正規化または変換するスキーマを設計する際は、正規化した値とともに元の生の値を保持するフィールドを必ず含めてください。たとえば、価格を抽出する場合は、"price": 12.50（正規化済み）と "price_raw": "$12.50"（入力元のまま）の両方を保存します。これにより、元の入力を再処理しなくても、後続の検証やデバッグが可能になります。

信頼度とメモ（不確実な出力向け）。 雑然とした入力や曖昧な入力（OCR、手書き文字、ノイズの多いデータなど）を処理するシステムでは、項目ごとに confidence（high／medium／low）と notes のフィールドを含めてください。これによりシステムの自己説明性が高まり、後続の利用者は、どの出力を信頼し、どの出力を人間による確認のためにフラグ付けすべきかを把握できます。信頼度を明示しないより、不確実性を明示するほうが適切です。

運用プレイブック（複数シナリオを扱うシステム向け）。 システムが複数の異なるワークフローを扱う場合は、それぞれに簡潔な手順を付けた名前付きパターンを定義してください。コーディングエージェントには、「機能の実装」「バグ修正」「リファクタリング」「デバッグ」「プロジェクトのセットアップ」などのパターンが考えられます。サポートボットには、「質問への回答」「返金処理」「人間へのエスカレーション」「苦情への対応」などが考えられます。プレイブックを用意すると、モデルの判断対象が減り、同様のリクエストに対する一貫性が高まります。

3 つのガイドすべての詳細な例を含む原則全体については、references/principles.md をお読みください。

ステップ 5：レビューと最適化

提出前に、このチェックリストを確認してください。

構成と形式：

• 明確な構成 — セクションが一貫したタグまたは見出しで区分されている
• 適切な順序 — 長い参考資料が先頭にあり、タスクが末尾にある
• 簡潔 — すべてのセクションに意義があり、重複がない

コンテンツの品質：

• 内部に矛盾がない — すべての指示を同時に実行できる
• 肯定的な表現 — ルールは避けることだけでなく、行うことを示している
• 理由が添えられている — 自明でないすべてのルールに「なぜ」がある
• 強度が適切 — 本当に重要な場合を除き、不必要な大文字や MUST を使っていない

完全性：

• ドメインを網羅 — システムが遭遇するすべての運用シナリオに対応している（主要なユースケースだけでなく、関連する状況も含む）
• 例を含む — 通常のケース、エッジケース、失敗モードを網羅する多様な例が 3～5 個ある
• エッジケースへの対応 — 入力が曖昧、不正形式、または対象範囲外の場合の対応をプロンプトで定めている
• プレイブックを含む — 複数シナリオを扱うシステムでは、各ワークフローについて名前付きの手順パターンがある

モデルと検証：

• モデルに適している — 対象モデルの強みと特性を考慮している
• テスト可能 — 望ましい動作が生成されるかどうかを検証できる
• テストプロンプト — 期待される動作とともに、検証用プロンプトが 3～5 個含まれている

モデル固有の最適化のヒントについては、references/model-specific.md をお読みください。

クイックリファレンス：モデルの比較

項目	Claude 4.6	GPT-5	Gemini 3
思考	適応型（自動調整）	reasoning_effort パラメーター	思考レベル（low／med／high）
構成	XML タグを推奨	XML タグまたは構造化仕様	XML または Markdown 見出し
冗長さ	自然に簡潔	verbosity API パラメーター	既定では直接的
並列ツール	優秀、プロンプトで約 100% に調整可能	良好、Responses API が有効	重視されていない
リスク	過剰に設計する場合がある	コンテキストを過剰に検索する場合がある	低い温度でループする場合がある
独自の強み	サブエージェントのオーケストレーション	ツールの前置き、メタプロンプト	グラウンディング、マルチモーダル

参考ファイルは必要なものだけを選んでください — 毎回すべてを読む必要はありません：

• references/model-specific.md — ユーザーが対象モデルを指定している場合、または複数モデルへの対応が必要な場合に読みます
• references/templates.md — ユースケースに合った開始用テンプレートが必要な場合に読みます
• references/principles.md — 特定の原則について、より詳しいガイダンスが必要な場合に読みます

モデルとユースケースがすでにわかっているシンプルなプロンプトでは、この SKILL.md のガイダンスで十分なことがよくあります。

出力形式

最終的なシステムプロンプトをユーザーに提示する際は、次の内容を含めてください：

1. システムプロンプト — コピーしてすぐに使えるよう、フェンス付きコードブロックに記載します
2. アーキテクチャに関する注記 — この構成を選んだ理由を簡潔に説明します
3. モデル固有の注記 — 対象モデルに合わせた調整（API パラメーターや既知の癖など）を記載します
4. テスト用プロンプト — システムプロンプトが意図どおりに機能するかを検証するためのプロンプトを3～5個提示します