システムプロンプトとは？3社APIの指定方法と書き方・禁止事項

システムプロンプトは、エンドユーザーの入力より先にモデルへ渡しておく指示です。呼び名も渡し方もベンダーごとに違い、OpenAI では instructions パラメータ、Anthropic Claude では system パラメータ、Google Gemini では system_instruction パラメータを使います。定義から3社の指定方法、書き方、書いてはいけない情報、コストへの影響までを公式ドキュメントの記述に沿って整理します。

まとめ：システムプロンプト設計の要点

システムプロンプトは「モデルの人格と制約を先に固定する層」であり、ユーザープロンプトは「その制約下で処理する個別の入力」です。両者を混ぜると、ユーザー入力でルールが上書きされたり、キャッシュが効かずコストが膨らんだりします。

実装上の要点は4つです。第一に、渡し方はベンダーごとに違うため、OpenAI は instructions、Anthropic は system、Gemini は system_instruction と対応表で押さえます。第二に、システムプロンプトの指示は絶対ではありません。OpenAI の Model Spec では開発者の指示は Root と System より下の階層に位置づけられており、上位ルールと衝突すれば負けます。第三に、認証情報や権限構造をシステムプロンプトに書かないことです。OWASP は LLM07:2025 でこれを明確に禁じています。第四に、システムプロンプトはキャッシュのプレフィックスを構成するため、頻繁に書き換えるとキャッシュヒットを失います。

システムプロンプトの定義とユーザープロンプトとの役割分担

システムプロンプトとユーザープロンプトの違い

システムプロンプトは、会話が始まる前にアプリケーション開発者が設定する指示です。モデルの役割、守るべき制約、出力形式といった「毎回同じであってほしい前提」を書きます。対してユーザープロンプトは、エンドユーザーがその都度入力する個別の依頼です。

OpenAI はこの関係を、テキスト生成ガイドの中で関数にたとえています。開発者メッセージが関数定義にあたり、ユーザーメッセージがその関数へ渡される引数にあたる、という説明です。「要約して」というユーザー入力に対し、何字で・どんな語調で・どの形式で返すかを決めているのがシステムプロンプト側です。

この分離が崩れる典型が、役割設定や制約をユーザープロンプトに毎回コピーして貼る運用です。指示が会話履歴の途中に散らばるため、後続のユーザー入力に押し流されやすくなります。プロンプト全体の設計思想についてはプロンプトエンジニアリングとは？推論モデルでの使い分けと4要素で整理しています。

指示階層におけるシステムプロンプトの権限レベル

OpenAI の Model Spec（2025年12月18日版）は、指示の権限を Root、System、Developer、User、Guideline の5段階に定義しています。

注意したいのは、Model Spec でいう「System」が OpenAI 自身の設定するルールを指しており、API 利用者が書く指示は「Developer」に分類される点です。日本語で「システムプロンプト」と呼び慣わしているものは、OpenAI の仕様上は Developer レベルの指示にあたります。Spec は Developer について「Root または System の指示によって上書きされない限り、モデルは開発者の指示に従うべきである」と定めており、上位の安全ルールと衝突する指示は通りません。

User レベルについても「Developer、System、Root レベルの指示と衝突しない限り、モデルはユーザーの要求を尊重すべきである」とされています。つまり開発者の指示はユーザー入力より優先されますが、それはあくまで階層内での相対的な優先であって、絶対的な強制力ではありません。この前提を取り違えると、後述する OWASP の指摘どおりのセキュリティ設計ミスにつながります。

主要3社APIでのシステムプロンプトの指定方法

OpenAI：instructionsパラメータとdeveloperロール

OpenAI のテキスト生成ガイドは「テキスト生成アプリを構築するなら、旧来の Chat Completions API より Responses API を推奨する」と明記しています。Responses API でシステムプロンプトにあたるのが instructions パラメータで、ガイドは「instructions パラメータは、応答を生成する際にどう振る舞うべきかについて、語調・目標・正しい応答の例を含む高水準の指示をモデルに与える」と説明しています。

// Responses API
const response = await client.responses.create({
  model: "gpt-5.6",
  instructions: "あなたは社内規程の照会に答えるアシスタントです。規程に記載のない事項は推測せず、記載がない旨を回答してください。",
  input: "有給の繰越上限は何日ですか",
});

ガイドはこの例について、input 配列に developer ロールのメッセージを置いた形と「おおむね等価」だと述べています。ロールを明示して組み立てる場合は次の形になります。

// Chat Completions API
{
  "model": "gpt-5.6",
  "messages": [
    { "role": "developer", "content": "あなたは社内規程の照会に答えるアシスタントです。規程に記載のない事項は推測せず、記載がない旨を回答してください。" },
    { "role": "user", "content": "有給の繰越上限は何日ですか" }
  ]
}

ガイドが挙げるロールは developer / user / assistant の3種で、system ロールの記載はありません。developer メッセージは「アプリケーション開発者が提供する指示であり、ユーザーメッセージより優先される」、user メッセージは「エンドユーザーが提供する指示であり、開発者メッセージの後ろに優先される」と定義されています。新規実装は Responses API の instructions で書き、ロール単位の制御が要る場合だけ developer メッセージを使う切り分けになります。

Anthropic Claude：systemパラメータ

Anthropic の Messages API では、システムプロンプトはメッセージのロールではなく、リクエスト直下の system パラメータとして渡します。messages 配列の中に入れるものではない、という点が OpenAI のロール方式との構造差です。

// Messages API
curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "system": "あなたは社内規程の照会に答えるアシスタントです。",
    "messages": [
      { "role": "user", "content": "有給の繰越上限は何日ですか" }
    ]
  }'

Anthropic のプロンプト設計ドキュメントは、システムプロンプトでの役割設定について「システムプロンプトで役割を設定すると、Claude の振る舞いとトーンがユースケースに合わせて絞り込まれる。一文でも違いが出る」と述べています。長大な人格設定を書かなくても、一行の役割定義で出力の方向は変わります。

Google Gemini：system_instructionパラメータ

Gemini API も Anthropic と同様、リクエスト直下の system_instruction パラメータで渡します。公式ドキュメントは「システム指示で Gemini モデルの振る舞いを誘導できる」と説明しています。

# Google Gen AI SDK (Python)
interaction = client.interactions.create(
    model="gemini-3.6-flash",
    system_instruction="あなたは社内規程の照会に答えるアシスタントです。",
    input="有給の繰越上限は何日ですか"
)

3社の対応関係を整理すると次のようになります。

複数ベンダーを切り替えて使う構成では、この差がそのまま抽象化レイヤの設計課題になります。システムプロンプトを文字列として一元管理し、送信直前にベンダーごとの形へ詰め替える作りにしておくと、モデル差し替え時の修正範囲が小さくなります。

APIを使わない場合のアプリ側設定

ChatGPT や Claude をアプリとして使う場合、API のような明示的なシステムプロンプト欄はありません。ChatGPT ではカスタム指示（Custom Instructions）、Claude ではプロジェクトのカスタム指示が、実質的に同じ役割を担います。

アプリ側で押さえておきたいのは、提供元があらかじめ設定しているシステムプロンプトが別に存在することです。Anthropic は claude.ai とモバイルアプリで使っているシステムプロンプトをリリースノートとして公開しており、現在の日付などの最新情報を会話開始時に与える役割や、コードスニペットを常に Markdown で提供させるといった振る舞いの指定が含まれると説明しています。ただし同ページには「これらのシステムプロンプトの更新は Claude API には適用されません」と明記されています。アプリで得られた出力の再現性を API で期待すると食い違うのは、この差が原因です。

システムプロンプトの書き方：4ブロック構成と記述例

役割・タスク・制約・出力形式の4ブロック

システムプロンプトに書く内容は、役割、タスク、制約、出力形式の4つに分解できます。逆に言えば、この4つに当てはまらない情報はユーザープロンプト側か外部の仕組みへ逃がす候補です。

• 役割：どの立場で応答するか（社内規程の照会担当、コードレビュアーなど）
• タスク：毎回共通して行う処理（要約する、分類する、質問に答える）
• 制約：してはいけないこと、判断がつかないときの振る舞い
• 出力形式：文字数、構造、言語、Markdown の可否

Anthropic のプロンプト設計ドキュメントは、指示・文脈・入力といった種類の異なる内容をそれぞれ専用のタグで囲むことを推奨しており、「各種類の内容を独自のタグ（たとえば <instructions>、<context>、<input>）で囲むことで誤読が減る」と述べています。4ブロックをタグで区切っておくと、後からブロック単位で差し替えやすくなります。

業務アシスタントの記述例

社内規程の照会に答えるアシスタントを例にすると、次のような形になります。

<role>
あなたは当社の就業規則・社内規程に関する照会に答えるアシスタントです。
</role>

<task>
提供された規程文書の記載範囲内で、質問に対する回答と該当する条項番号を示してください。
</task>

<constraints>
- 提供された文書に記載がない事項は推測せず、記載がない旨を回答してください。
- 個別の労務判断や法的助言は行わず、人事部への確認を案内してください。
- 回答の根拠となる条項番号を必ず併記してください。
</constraints>

<format>
1. 回答（3行以内）
2. 根拠条項
3. 補足が必要な場合のみ注記
</format>

制約ブロックに不明時の振る舞いを書かないと、モデルは一般的な労働法の知識で穴埋めします。社内文書を参照させる構成そのものの設計についてはOmniRAGとは？意図に応じてDB・ベクトル検索・ナレッジグラフを使い分けるRAG設計パターンで扱っています。

要約タスク・分類タスクの記述例

同じ4ブロックの型は、タスクを差し替えるだけで転用できます。要約なら出力形式ブロックに字数と構造を、分類なら制約ブロックにラベル集合と迷ったときの既定値を書くのが要点です。

# 要約タスク
役割：技術記事を社内共有向けに要約する編集者。
タスク：与えられた本文を要約する。
制約：本文に無い情報を補わない。固有名詞とバージョン番号は原文表記を維持する。
出力形式：見出し1行（30字以内）＋箇条書き3点（各60字以内）。

# 分類タスク
役割：問い合わせメールを一次振り分けする担当者。
タスク：本文を1つのカテゴリに分類する。
制約：カテゴリは 障害報告、仕様質問、見積依頼、その他 の4つのみ。
      複数に該当する場合は最も緊急度の高いものを選ぶ。判断できない場合は その他 とする。
出力形式：カテゴリ名のみを1語で出力する。

分類タスクで「判断できない場合は その他」まで指定しておくと、モデルが勝手にカテゴリを新設する事故を防げます。

深津式・ゴールシークプロンプトとの使い分け

深津式プロンプトは、深津貴之氏が考案したとされるテンプレートで、命令書・制約条件・入力文・出力文を Markdown の見出しで区切って渡します。ゴールシークプロンプトは、目的だけを先に伝えてモデル側に必要な情報をヒアリングさせる進め方です。

これらをシステムプロンプトに丸ごと入れるべきかというと、答えは分けるべき、です。深津式でいう命令書と制約条件はシステムプロンプト側の役割・タスク・制約に対応するため固定化に向きますが、入力文は毎回変わるのでユーザープロンプト側に置きます。テンプレート全体を system に埋め込むと、変化しない指示と変化する入力が同じ層に混ざり、後述するキャッシュのプレフィックスが毎回変わってしまいます。

ゴールシークプロンプトはさらに相性が悪く、対話を通じて要件を詰めるという性質上、システムプロンプトに固定するものではありません。「不明点があればユーザーに質問してから作業を始める」という振る舞いの指定だけをシステム側に置き、実際のヒアリングは会話で進めるのが素直な分担です。

効きにくい表現とその直し方

指示が効かないときに強調語を足していく対処は、逆効果になることがあります。Anthropic はプロンプト設計ドキュメントの中で、Claude Opus 4.5 および Opus 4.6 が従来モデルよりシステムプロンプトに反応しやすくなったと述べ、ツール呼び出しの過少発火を抑えるために書いた強い表現がかえって過剰発火を招くと指摘しています。修正方針として「『CRITICAL: You MUST use this tool when…』と書いていたところは、『Use this tool when…』のような通常の表現でよい」と明示しています。

効きにくい書き方は、おおむね次のように直せます。

共通するのは、評価語を具体的な条件と出力の形に置き換えるという方向です。「丁寧に」はモデルによって解釈幅が大きい一方、「敬体で、3文以内」なら判定できます。

システムプロンプトに置いてはいけない情報（OWASP LLM07:2025）

OWASP は LLM アプリケーションのリスク一覧に LLM07:2025 System Prompt Leakage を挙げ、システムプロンプトが漏れる前提で設計するよう求めています。文書は「認証情報や接続文字列などの機微なデータをシステムプロンプトの文面に含めるべきではない」と述べたうえで、リスクの本質について「システムプロンプトそのものの開示が真のリスクなのではなく、セキュリティリスクはその背後にある要素にある」と整理しています。

示されている対策は次の4点です。

• 機微情報を書かない：APIキー、認証キー、データベース名、ユーザーロール、アプリケーションの権限構造を直接埋め込まない
• 挙動の強制制御に頼らない：可能な限りシステムプロンプトでモデルの振る舞いを制御せず、LLM の外側の仕組みに依存させる
• ガードレールを別立てにする：出力の検査と適合確認は LLM とは独立した系で行う
• 重要な制御を委譲しない：権限分離や認可の境界チェックといった重要な制御を LLM に任せない

ここで前節の指示階層が効いてきます。Model Spec 上、開発者の指示は上位階層に上書きされうる Developer レベルにすぎません。仕様として上書きの余地が定義されているものに認可判断を載せるのは、設計として筋が悪いということです。「このユーザーは閲覧のみ可」といった判定はアプリケーション側で行い、システムプロンプトには結果として渡せる情報だけを載せます。

Anthropic が claude.ai のシステムプロンプトを公開している事実も、この前提を裏づけます。システムプロンプトは秘匿を前提とした置き場所ではありません。漏洩耐性そのものを高めたい場合は、Prompt Hardenerとは？LLMアプリ向けプロンプト堅牢化ツールの概要と特長で扱っているような、プロンプトの堅牢化を支援するツールの併用が選択肢になります。

システムプロンプトがトークンコストを左右する仕組み

システムプロンプトは毎回のリクエストに付いて回るため、長さがそのまま入力トークン数に乗ります。ここで効いてくるのがプロンプトキャッシュです。

Anthropic のプロンプトキャッシュのドキュメントは、キャッシュ対象となるプレフィックスの構成順序を明記しています。「キャッシュのプレフィックスは tools、system、messages の順に作られる。この順序は各層が前の層の上に積み上がる階層を形成する」という記述です。つまりシステムプロンプトはキャッシュ対象の前半に位置し、ここを書き換えると後ろの層のキャッシュもまとめて無効になります。

キャッシュが成立する最小トークン数はモデルによって異なります。

設計上の含意は2つあります。ひとつは、システムプロンプトに日付や実行時刻のような可変値を埋め込むと、リクエストのたびにプレフィックスが変わりキャッシュが外れることです。可変値はユーザーメッセージ側か、キャッシュ区切りより後ろに置きます。もうひとつは、モデルによって最小長が8倍も違うため、モデルを差し替えたときに「今までキャッシュされていた長さのシステムプロンプトが対象外になる」事態が起きうることです。キャッシュ機構そのものの挙動はプロンプトキャッシュ（Prompt Caching）とは｜仕組みと主要APIの使い方で詳しく扱っています。

なお、システムプロンプトを長くして振る舞いを作り込むより、学習側で解くほうが安定する領域もあります。定型的な出力形式や社内固有の言い回しを毎回の指示で強制していて、かつ入力パターンが数十件単位で集まっているなら、ファインチューニング用データセットの作り方｜サンプル形式・件数・品質の要件で扱う方向への切り替えが有効です。

よくある質問

システムプロンプトとは何ですか？

アプリケーション開発者が会話の開始前にモデルへ渡しておく指示で、役割・タスク・制約・出力形式を固定する層です。OpenAI では instructions パラメータまたは developer ロールのメッセージ、Anthropic では system パラメータ、Gemini では system_instruction パラメータで渡します。

システムプロンプトとユーザープロンプトの違いは何ですか？

システムプロンプトは開発者が事前に設定する前提条件、ユーザープロンプトはエンドユーザーが都度入力する個別の依頼です。優先度は開発者側が上で、OpenAI は開発者メッセージを「ユーザーメッセージより優先される」と定義しています。

システムプロンプトの例は？

役割・タスク・制約・出力形式の4ブロックで書きます。最小構成は次の形です。

役割：問い合わせメールを一次振り分けする担当者。
タスク：本文を1つのカテゴリに分類する。
制約：カテゴリは 障害報告、仕様質問、見積依頼、その他 の4つのみ。判断できない場合は その他 とする。
出力形式：カテゴリ名のみを1語で出力する。

ChatGPTのシステムプロンプトの設定方法は？

ChatGPT のアプリではカスタム指示（Custom Instructions）が該当します。API を利用する場合は Responses API の instructions パラメータ、または developer ロールのメッセージとして送ります。Claude ではプロジェクトのカスタム指示、API では system パラメータが対応します。

システムプロンプトはユーザーの入力で上書きされますか？

OpenAI の Model Spec 上、User レベルの指示は Developer レベルと衝突する場合には通らないため、通常のユーザー入力で上書きされることは想定されていません。ただし Developer レベル自体が Root と System に上書きされうるため、上位の安全ルールと衝突する指示は効きません。

システムプロンプトはユーザーに見えますか？

画面には表示されませんが、秘匿できる前提で設計してはいけません。OWASP は LLM07:2025 でシステムプロンプトの漏洩を独立したリスク項目として扱い、認証情報や権限構造を書かないよう求めています。Anthropic は自社アプリのシステムプロンプトをリリースノートで公開しています。

システムプロンプトはどのくらいの長さが適切ですか？

一律の目安はありませんが、コスト面ではキャッシュの最小トークン数が判断材料になります。Claude では Opus 5 系が512トークン、Opus 4.6 や Haiku 4.5 が4,096トークンと差があり、これを下回るとキャッシュが成立しません。役割の指定自体は一文でも効果があるとされているため、まず短く書き、必要な制約だけを足していく順序が現実的です。

関連記事

• プロンプトエンジニアリングとは？推論モデルでの使い分けと4要素
• プロンプトキャッシュ（Prompt Caching）とは｜仕組みと主要APIの使い方
• OmniRAGとは？意図に応じてDB・ベクトル検索・ナレッジグラフを使い分けるRAG設計パターン
• ファインチューニング用データセットの作り方｜サンプル形式・件数・品質の要件