システムプロンプトとは？AIアプリの振る舞いを固定する設計方法 – devsakaso

システムプロンプトは、AIアプリの振る舞いを決めるための高位の指示です。ユーザーが毎回入力する質問とは別に、アプリ側が「このAIは何の役割で、何をしてよくて、何をしてはいけないか」をあらかじめ渡すために使います。

たとえば、問い合わせ対応AIなら「丁寧なサポート担当として答える」「契約や請求を断定しない」「不明点は人間確認へ回す」といったルールを置きます。記事構成AIなら「検索意図を優先する」「公式情報が必要な場合は明記する」「コピペ例文集ではなく構成案を返す」といった方針を置けます。

この記事では、システムプロンプトとは何か、通常のプロンプトやユーザー入力と何が違うのか、AIアプリでどう設計すればよいのかを、Web開発者向けに整理します。

プロンプト全体の設計を先に見たい場合は、プロンプトエンジニアリングとは？AIに安定した出力をさせる基本が入口になります。一般利用者向けの指示文の書き方は、プロンプトの書き方に分けています。

この記事の内容は、2026年7月9日時点のOpenAI API、Google AI for Developers、Claude Platform Docsの公式情報をもとにしています。APIごとの名称、メッセージロール、推奨される指定方法は変わるため、本番実装前には必ず利用するモデルの公式ドキュメントを確認してください。

結論：システムプロンプトはAIアプリの土台になる固定指示

システムプロンプトは、AIアプリの基本的な振る舞いを定義するための固定指示です。ユーザーの質問ごとに変わる指示ではなく、アプリ全体や機能単位で共通して守ってほしいルールを置きます。

OpenAI APIのPrompt engineeringドキュメントでは、`instructions` パラメータやメッセージロールによって、異なる権限レベルの指示をモデルに渡せることが説明されています。`instructions` は、応答時の振る舞い、トーン、ゴール、正しい応答例などを含められ、`input` のプロンプトより優先される高位の指示として扱われます。

Gemini APIでも、`system_instruction` パラメータでモデルの振る舞いを設定できることが説明されています。

実務では、次のように分けると理解しやすいです。

場所	書くこと	例
システムプロンプト	役割、方針、禁止事項、出力の基本ルール	サポート担当として、断定を避け、不明点は人間確認へ回す
ユーザープロンプト	今回の依頼、質問、入力データ	この問い合わせ文に返信案を作ってください
アプリ側の検証	入力制限、権限、出力チェック、ログ	顧客情報を渡せる権限があるか確認する

システムプロンプトは便利ですが、万能な安全装置ではありません。アプリ側の権限管理、入力検証、出力検証、人間レビューと組み合わせて使うものです。

システムプロンプトとは

システムプロンプトとは、AIに対して会話や処理全体の前提を伝えるための指示です。多くの場合、ユーザーが直接入力する内容とは別に、アプリ開発者がサーバー側で組み立ててAI APIへ渡します。

たとえば、次のような内容を含めます。

AIの役割: サポート担当、編集者、分類器、レビュー担当など
対象範囲: どのサービス、どの業務、どの入力を扱うか
回答方針: 簡潔に、丁寧に、根拠を分ける、不明点を明記する
禁止事項: 推測で断定しない、契約判断をしない、機密情報を出さない
出力形式: 箇条書き、Markdown、項目名、JSON風の構造など
エスカレーション条件: 人間確認へ回す条件

システムプロンプトは、ユーザー入力のたびに同じ基本姿勢を保つために使います。毎回ユーザーに「丁寧に答えて」「安全に配慮して」「不明点は分けて」と書かせるのではなく、アプリ側で共通ルールとして持たせるイメージです。

通常プロンプト・ユーザー入力・開発者指示との違い

システムプロンプトは、通常のプロンプトやユーザー入力と役割が違います。

種類	主な役割	変わりやすさ	例
システムプロンプト	AIアプリの基本方針を決める	機能単位で固定される	あなたは問い合わせ対応AIです
ユーザープロンプト	今回の具体的な依頼を渡す	毎回変わる	この文章を要約してください
開発者側のテンプレート	入力を整形し、必要情報を差し込む	実装で管理される	問い合わせ本文、会員情報、FAQ抜粋を組み立てる
出力検証	AIの返答をアプリ側で確認する	仕様変更で変わる	必須項目があるか、禁止語がないか確認する

OpenAIのResponses APIでは、`instructions` と `input` を分けて渡す例が公式ドキュメントにあります。また、Chat CompletionsからResponses APIへ移行する説明では、従来のsystem/developer guidanceはトップレベルの `instructions` に対応づけられると説明されています。

なお、モデルやAPIによっては、system message、developer message、instructions、system_instructionなど名称や扱いが異なります。記事内では便宜上「システムプロンプト」と呼びますが、実装時は使うAPIの現在の書き方に合わせます。

システムプロンプトが必要になる場面

システムプロンプトが役に立つのは、AIに毎回同じ役割や制約を守らせたいときです。

場面	固定したいこと	注意点
問い合わせ対応AI	丁寧な口調、断定回避、確認事項の明記	契約や請求は人間確認へ回す
記事構成AI	検索意図、読者、書かない範囲、見出し構成	事実確認をAIだけに任せない
コードレビューAI	バグ、セキュリティ、テスト不足を優先する	好みのリファクタだけを大量に出さない
分類AI	カテゴリ定義、判断基準、例外処理	曖昧な場合の扱いを決める
AIエージェント	ツール利用方針、確認が必要な操作、完了条件	権限や破壊的操作はアプリ側でも制限する

システムプロンプトは、アプリの「人格」だけでなく、業務ルールや品質基準を伝える場所です。特に、複数ユーザーが同じAI機能を使う場合は、ユーザーごとに依頼文が違っても基本方針を保つために重要になります。

システムプロンプトに書くべきこと

システムプロンプトには、長い説明を詰め込むより、アプリの振る舞いに本当に必要な方針を書きます。

基本要素は次のとおりです。

要素	書くこと	例
役割	AIがどの立場で答えるか	あなたはSaaSのカスタマーサポート担当です
目的	何を達成するAI機能か	問い合わせに対して返信案と確認事項を作る
対象範囲	扱う情報、扱わない情報	提供されたFAQと問い合わせ本文だけを根拠にする
禁止事項	やってはいけないこと	契約変更、返金可否、法的判断を断定しない
出力方針	形式、口調、長さ、項目	返信案、確認事項、人間確認が必要な理由に分ける
失敗時の扱い	不明、矛盾、情報不足のときの対応	不明点を明記し、人間確認へ回す

たとえば、問い合わせ対応AIなら次のような形です。

あなたはSaaSのカスタマーサポート担当です。
ユーザーからの問い合わせに対して、返信案と確認事項を作成してください。

ルール:
- 提供された問い合わせ本文とFAQ抜粋だけを根拠にする
- 返金、契約変更、法的判断は断定しない
- 不明な点は「確認が必要なこと」に分ける
- 返信案は丁寧で簡潔な日本語にする
- 最後に human_review_required を true/false で示す

このように、役割、根拠、禁止事項、出力方針をまとめると、ユーザー入力が多少変わっても基本の振る舞いを保ちやすくなります。

システムプロンプトに書かないほうがよいこと

システムプロンプトは便利ですが、何でも入れればよいわけではありません。

次のような内容は避けます。

APIキー、パスワード、社外秘の認証情報
ユーザーごとに変わる大量の個人情報
現在の質問に関係ない長いマニュアル全文
矛盾したルールや優先順位のない禁止事項
出力検証で担保すべき仕様をプロンプトだけに任せること
セキュリティ対策を「この指示を守って」だけで済ませること

システムプロンプトは、ユーザーから直接見えにくい場所に置かれることが多いですが、秘密情報の保管場所ではありません。プロンプトインジェクション、ログ、デバッグ、外部連携などで漏れる可能性も考えます。

また、長いルールを詰め込みすぎると、コンテキストを消費し、モデルが重要な指示を見落とすことがあります。長文資料や履歴の扱いは、コンテキストウィンドウとは？AIに渡せる長文量と設計の考え方も参考になります。

Web開発での使いどころ

Webアプリでは、システムプロンプトはフロントエンドのテキストエリアに置くものではなく、サーバー側で管理する設計にします。

理由は次のとおりです。

ユーザーに改変されるとAIの振る舞いが変わる
モデル名、プロンプト、入力制限、ログをまとめて管理したい
権限に応じて渡す資料を変える必要がある
プロンプト変更をコードレビューやリリース管理に乗せたい
失敗時に原因を追跡できるようにしたい

Webアプリの全体構成で見ると、次のようになります。

ブラウザ
  ↓ ユーザー入力
サーバー
  ↓ 入力検証・権限確認
システムプロンプト + ユーザー入力 + 必要な文脈
  ↓
AI API
  ↓
出力検証・ログ保存
  ↓
ブラウザへ返す

Webアプリ全体の役割分担は、Webアプリケーションの構成やクライアントサーバーシステムとはの考え方とつながります。

AI APIのレスポンスもJSONとして受け取ってUIへ反映することが多いため、JavaScriptでJSONデータを取得する方法の基礎も役に立ちます。

最小構成で考える処理の流れ

システムプロンプトを使う最小構成は、次のような流れです。

1. 機能ごとにシステムプロンプトを定義する
2. ユーザー入力を受け取る
3. 入力を検証する
4. 必要な文脈だけを追加する
5. AI APIへ送る
6. 回答を検証する
7. ログを保存する
8. 失敗例を見てプロンプトを改善する

JavaScriptの概念コードでは、次のような形です。実際のSDK、モデル名、レスポンス形式は利用するAPIの公式ドキュメントに合わせてください。

const SUPPORT_SYSTEM_PROMPT = `
あなたはSaaSのカスタマーサポート担当です。
提供された問い合わせ本文とFAQ抜粋だけを根拠に、返信案を作成してください。

ルール:
- 返金、契約変更、法的判断は断定しない
- 情報が不足している場合は確認事項に分ける
- 丁寧で簡潔な日本語で回答する
- 人間確認が必要な場合は理由を示す
`;

const response = await client.responses.create({
  model: process.env.AI_MODEL,
  instructions: SUPPORT_SYSTEM_PROMPT,
  input: `
問い合わせ本文:
${inquiryText}

FAQ抜粋:
${faqExcerpt}
`
});

console.log(response.output_text);

この例では、固定方針を `instructions` に置き、今回の問い合わせ本文やFAQ抜粋を `input` に置いています。こうすると、固定ルールとユーザーごとの入力を分けて管理できます。

APIごとの指定方法の違い

システムプロンプトは考え方としては共通していますが、APIごとに指定方法が違います。

API/サービス	指定の考え方	注意点
OpenAI Responses API	`instructions` に高位の振る舞い指示を渡す	`input` と分けて管理する。会話継続時も安定指示を再送する設計を確認する
OpenAI Chat Completions	system/developer guidance をメッセージロールで扱う	新規実装ではResponses APIの現在の推奨に合わせる
Gemini API	`system_instruction` でモデルの振る舞いを設定する	入力、生成設定、システム指示を分ける
Claude API	system promptやツール定義がモデルの利用文脈に入る	ツール定義や利用方針もモデルの振る舞いに影響する

OpenAIのReasoning best practicesでは、reasoning modelではdeveloper messagesが新しいsystem messagesとして扱われると説明されています。つまり、モデルやAPIによって「どの場所に高位の指示を書くか」は変わります。

記事や設計書では「システムプロンプト」とまとめて呼んでも、実装では必ず現在のAPI仕様に合わせてください。

システムプロンプトを管理する方法

システムプロンプトは、アプリケーションコードとして管理するのが基本です。

OpenAIのPromptingドキュメントでは、プロンプトをアプリケーションコードとして扱い、名前付きモジュールに保存し、型付きの引数や検証済み入力で動的部分を作り、プロダクトの挙動と同じPull Requestでレビューする考え方が紹介されています。

実務では、次のように管理します。

機能ごとにプロンプトを分ける
ファイル名や関数名に用途を入れる
バージョンを付ける
変更理由をログやPRに残す
代表的な入力と期待出力をテストケースとして保存する
モデル変更時に評価し直す
本番の失敗例をもとに改善する

たとえば、次のようなメタ情報を残します。

name: support-reply-system-v1
purpose: 問い合わせ返信案を作る
owner: support-team
model: production-model-name
input: inquiryText, faqExcerpt
must_not:
  - 返金可否を断定する
  - FAQにない情報を事実として言う
review_cases:
  - 請求金額の問い合わせ
  - 解約希望
  - 不具合報告
  - FAQに答えがない質問

こうしておくと、AIの回答が崩れたときに、モデルの問題なのか、入力の問題なのか、システムプロンプトの問題なのかを調べやすくなります。

セキュリティと安全性の注意点

システムプロンプトは、AIの振る舞いを整える助けになりますが、セキュリティ境界そのものではありません。

特に注意したいのは、次の点です。

ユーザー入力を信用しない
ユーザーの権限外の資料をAIに渡さない
APIキーや秘密情報をプロンプトに入れない
AIの出力をそのままDB更新や外部送信に使わない
危険な操作は人間確認やサーバー側の権限チェックを入れる
プロンプトインジェクションを想定する

たとえば、システムプロンプトに「機密情報を出さないで」と書いても、そもそも権限のない機密情報をAIに渡してしまえば、出力に混ざるリスクがあります。プロンプトで抑えるのではなく、アプリ側で渡す情報を制限します。

生成AIの基本的な注意点は、生成AIの安全な使い方も参考になります。プロンプトインジェクション対策は、後続記事で別に深掘りするテーマです。

実装前に確認すること

システムプロンプトを本番機能に入れる前に、次の項目を確認します。

このAI機能の役割を1文で説明できるか
ユーザー入力と固定指示を分けているか
禁止事項に優先順位があるか
不明、矛盾、情報不足の扱いを決めているか
出力形式をアプリ側で検証できるか
ユーザー権限に応じて渡す資料を制限しているか
プロンプト変更時のテストケースがあるか
モデル変更時に再評価できるか
ログにモデル名、プロンプトバージョン、usageを残せるか

厳密なJSONやスキーマ固定が必要な場合は、システムプロンプトだけで完結させず、後続の `ai-json-output` や `structured-outputs-basics` で扱うように、出力形式の指定、バリデーション、Structured Outputsなどを検討します。

よくある誤解と注意点

システムプロンプトでは、次のような誤解が起きやすいです。

システムプロンプトを書けば必ず守られる

高位の指示として扱われても、AIの出力が必ず完全に制御されるわけではありません。重要な仕様は、出力検証、テスト、人間レビュー、権限管理と組み合わせます。

長いほど安全になる

長いルールは、コンテキストを消費し、矛盾やノイズも増やします。短く、優先順位が分かり、実際の出力に効く指示へ絞るほうが保守しやすいです。

ユーザー入力に上書きされないから安心

システムプロンプトはユーザー入力より上位の指示として扱われる場合がありますが、プロンプトインジェクションや複雑な文脈で期待どおりに動かない可能性はあります。安全対策をプロンプトだけに任せないことが大事です。

システムプロンプトに全資料を入れればよい

システムプロンプトは固定方針を書く場所です。大量のFAQ、マニュアル、DB情報は、必要なときに検索してユーザー入力側の文脈として渡すほうが管理しやすい場合があります。

JSON形式を頼めば必ず使えるデータになる

OpenAIのStructured Outputsドキュメントでは、JSON modeでも特定のスキーマ一致までは保証しないため、Structured Outputsや検証処理を使う考え方が説明されています。システムプロンプトは出力方針を示せますが、厳密な構造保証は別に設計します。

次に読むべき関連記事

システムプロンプトを理解したら、次は出力制御やAPI設計へ進むと流れがつながります。

プロンプトエンジニアリングとは？: 指示設計全体を整理したい場合
プロンプトの書き方: 一般向けの指示文テンプレートを確認したい場合
コンテキストウィンドウとは？: 長い指示や履歴が上限に与える影響を確認したい場合
AIのトークンとは？: システムプロンプトの長さと料金の関係を理解したい場合
AIとは？エンジニアがWeb開発で押さえるべき基本を解説: AI API設計の全体像を見たい場合
Webアプリケーションの構成: サーバー側でAI機能を管理する考え方を確認したい場合
生成AIの安全な使い方: 情報漏洩や誤回答への基本対策を確認したい場合

今後は、AIのJSON出力、Structured Outputs、Function Calling、プロンプトインジェクション対策へ進めると、AIアプリの出力制御と安全設計がより具体化します。

まとめ

システムプロンプトは、AIアプリの振る舞いを固定するための高位の指示です。ユーザーごとの依頼とは別に、役割、目的、禁止事項、出力方針、失敗時の扱いを定義します。

通常のプロンプトが「今回何をしてほしいか」を伝えるものだとすれば、システムプロンプトは「このAI機能はどう振る舞うべきか」を決める土台です。問い合わせ対応、記事構成、コードレビュー、分類、AIエージェントなど、同じ処理を何度も使う機能で特に重要になります。

ただし、システムプロンプトは万能ではありません。秘密情報を入れない、ユーザー権限を確認する、出力を検証する、ログを残す、人間確認へ回す条件を作る、といったアプリ側の設計とセットで使いましょう。