【比較】プロンプト・コンテキスト・システムプロンプトの違い¶
概要¶
LLM を API から使い始めると、最初につまずくのが「プロンプト」「コンテキスト」「システムプロンプト」という 3 つの言葉です。日常会話ではどれも「AI への指示文」のように聞こえますが、API 仕様上はレイヤー（層）も役割も異なります。
ざっくり言うと、コンテキストはモデルが 1 回の生成で参照できる入力の総体（器）、プロンプトはその器に入れる具体的な入力（中身）、システムプロンプトはプロンプトの中でも「振る舞いや役割を最上位で固定する特別な枠」です。この三層を区別できると、「指示が効かない」「会話履歴が消える」「プロンプトインジェクションが刺さる」といった問題の切り分けが一気に楽になります。
例えるなら：関数呼び出し¶
- システムプロンプト … 関数の定義そのもの（ふるまいの規約・前提・禁止事項）。OpenAI Model Spec は developer メッセージを「関数定義」、user メッセージを「その関数への引数」に例えています。
- プロンプト（ユーザー入力） … その関数に渡す引数（今回処理してほしい具体的な内容）。
- コンテキスト … 関数が一度に受け取れる引数の最大サイズ（メモリ上限）。定義も引数も会話履歴も、全部この枠の中に収まっていなければなりません。
詳細比較¶
| 比較軸 | システムプロンプト | プロンプト（ユーザー入力） | コンテキスト（コンテキストウィンドウ） |
|---|---|---|---|
| 何を指すか | 振る舞い・役割・制約を定義する最上位の指示 | その回で処理してほしい具体的な依頼・入力 | モデルが 1 回の生成で参照できる全テキストの「器」 |
| API 上の位置 | Anthropic は最上位 system パラメータ／OpenAI は推論モデル(o1 以降)で developer ロール（従来の system と機能的にほぼ同等。system は非推論モデルでは引き続き有効） |
messages 配列の user ロール |
リクエスト全体（system＋履歴＋ツール定義＋入力＋出力）の合計トークン |
| 適用範囲 | 会話全体に持続的に効く | 基本はその 1 ターン中心 | 1 リクエスト内のすべて |
| 権限（優先度） | プラットフォーム＞developer/system＞user の上位側 | 上位指示と矛盾しなければ尊重される下位側 | 権限ではなく容量の概念（優先度ではない） |
| 典型的な中身 | ペルソナ、出力フォーマット規約、禁止事項、安全制約 | 質問、変換対象テキスト、タスク指示 | システム＋会話履歴＋RAG 抜粋＋ツール定義＋生成中の出力 |
| 上限に達すると | （履歴ではないので原則保持される） | 長すぎると切り詰め設計が必要 | 超過時は精度劣化（context rot）や打ち切りが発生 |
よくある誤解¶
- 誤解1：「システムプロンプトは強い user メッセージにすぎない」 — 違います。OpenAI Model Spec は権限の階層（chain of command）を定義しており、Platform ＞ Developer ＞ User ＞ Guideline の順で上位が下位を上書きします（OpenAI は推論モデル(o1 以降)で
developerロールを導入。developerは推論モデルでの上位指示ロールで従来のsystemと機能的にはほぼ同等、systemも非推論モデルでは引き続き有効で廃止ではありません）。Anthropic Messages API ではsystemはmessages配列とは別の最上位パラメータで、messagesの中に"system"ロールは存在しません。つまりシステムプロンプトは「並びが先頭の user」ではなく、構造的に別レイヤーです。 - 誤解2：「コンテキスト＝会話履歴のこと」 — 会話履歴はコンテキストの一部にすぎません。コンテキストウィンドウは「モデルが応答生成時に参照できる全テキスト（生成する出力自身を含む）」であり、システムプロンプト・ツール定義・RAG で差し込んだ文書・現在の入力・生成中の出力まで全部が同じトークン枠を共有します。
- 誤解3：「コンテキストは大きいほど良い」 — 公式ドキュメントも明確に否定しています。トークン数が増えると精度・想起が劣化する "context rot" が起きるため、容量を埋めることより「何を入れるか」を選別することが重要です。
実務での選び分け¶
- 常に守らせたい規約（口調・出力 JSON スキーマ・禁止事項・役割） → システムプロンプトに置く。毎ターンの user メッセージに書くと、ターンが進むにつれ希釈・無視されやすい。
- その回限りの依頼・データ → user プロンプトに置く。
- ユーザー由来テキスト／ツール出力／外部文書 → 「データ」として明示的に枠で囲い、指示として解釈させない（プロンプトインジェクション対策）。Model Spec はツール出力や引用テキストを既定で「権限なし」と扱う。
- 会話が長くなってきた／RAG で大量に差し込む → 容量問題なので、コンテキスト管理（要約・コンパクション・不要なツール結果のクリア）で対処する。システムプロンプトを強くしても解決しない。
- 指示が効かない不具合の切り分け → 「規約が守られない＝システムプロンプト側／レイヤーの問題」「履歴が消える・話が噛み合わない＝コンテキスト容量の問題」と切り分けると速い。
ひとことまとめ¶
コンテキストは「モデルが一度に見られる入力の器（容量）」、プロンプトは「その器に入れる今回の中身」、システムプロンプトは「中身の中でも振る舞いを最上位で固定する別レイヤーの枠」。優先度の話か容量の話かを見極めるのが切り分けの近道です。
出典・参考¶
- OpenAI Model Spec（chain of command / Platform・Developer・User・Guideline の権限階層）: https://model-spec.openai.com/2025-04-11.html
- Anthropic Messages API（
systemは最上位パラメータ、messagesに"system"ロールは存在しない）: https://platform.claude.com/docs/en/api/messages - Anthropic「Context windows」（コンテキストウィンドウの定義、context rot、容量の考え方）: https://platform.claude.com/docs/en/build-with-claude/context-windows
- Anthropic「System prompts」（システムプロンプトで役割・文脈を与える）: https://platform.claude.com/docs/en/docs/build-with-claude/prompt-engineering/system-prompts