システムプロンプトとユーザープロンプトの違い・使い分け完全ガイド

ChatGPT や Claude を業務に組み込んでいると、「システムプロンプト」「ユーザープロンプト」という言葉を聞きます。両者の責務分担を理解すると、出力品質と再現性が一段上がります。

この記事では、両者の違いに加えて、何をどちらに置くかの判断基準、実装上の扱い、プロンプトキャッシュとの関係まで解説します。

そもそもなぜ分けるのか

「全部まとめて書けばいいのでは」と思うかもしれません。分ける理由は3つあります。

理由1: 再現性が上がる

役割・トーン・禁止事項が毎回同じ文面で渡されるため、出力のばらつきが減ります。ユーザー側に混ぜていると、書く人や書くタイミングで表現が変わり、それが出力の揺れになります。

理由2: コストが下がる

多くのAIサービスには、同じ内容の指示を再利用してコストを下げる仕組み（プロンプトキャッシュ）があります。システムプロンプトが固定されていれば、その部分が再利用対象になります。ユーザー側に混ぜていると、毎回内容が変わるため再利用されません。

理由3: 直す場所が分かる

出力に不満があるとき、原因がルール側なのかタスク側なのかを切り分けられます。ひとつの長文になっていると、どこを直せば何が変わるのかが分からず、試行錯誤が長引きます。

システムプロンプトの役割

システムプロンプトは、AI に「自分が何者で、どう振る舞うべきか」を定義する指示です。

• AI の 役割・人格・専門性 を設定
• トーン・スタイル・禁止事項 を指定
• 出力形式の基本ルール を定義
• 常に守るべき制約 を埋め込む

例:

あなたは {{company}} のカスタマーサポート担当です。
- 丁寧語ベース、絵文字は使わない
- 個人情報を顧客から聞き出さない
- 不確実な情報は推測せず「確認します」と返す
- 出力は「結論 → 理由 → 次のアクション」の 3 段構成

「役割」は肩書きでなく判断基準を書く

システムプロンプトで最も誤解されているのが役割の書き方です。「あなたは優秀な〇〇です」という修飾は、実際にはほとんど効きません。

（効きにくい）
あなたは優秀なマーケターです。この施策を評価してください。

（効く）
予算配分を決める立場のマーケティング責任者として評価してください。
実行可能性とコストを優先し、新規性は評価軸に入れないでください。

効くのは 「どの視点で、何を優先して判断するか」 です。肩書きは、その視点を説明するための補助にすぎません。

ユーザープロンプトとの責務分担

ユーザープロンプトは、具体的なタスクを渡す指示です。「今回これをやってください」という単発の依頼。

• 個別タスクの 入力データ
• そのタスク固有の オプション・条件
• 例外的な要望

例:

以下の問い合わせに対する返信ドラフトを作成してください。

# 問い合わせ
{{customer_message}}

# 顧客情報
{{customer_profile}}

「変わらない部分はシステムへ、変わる部分はユーザーへ」が基本原則です。

何をどちらに置くか：判断表

迷ったときは「同じ内容を明日も来月も送るか」で判断してください。送るならシステム、送らないならユーザーです。

内容	置き場所	理由
役割・判断基準	システム	毎回同じ
トーン・文体	システム	毎回同じ
禁止事項・制約	システム	毎回同じ
出力形式（項目・順序）	システム	毎回同じ
業界用語の定義・略語表	システム	毎回同じ
処理対象のテキスト・データ	ユーザー	毎回変わる
顧客名・案件名・日付	ユーザー	毎回変わる
今回だけの例外指示	ユーザー	今回限り
出力の分量（今回は短めに等）	ユーザー	状況で変わる
Few-shot の例	どちらでも	固定ならシステム、タスクごとに変えるならユーザー

例外：Few-shot の例をどちらに置くか

出力例（Few-shot）は判断が分かれます。目安は次の通りです。

• 形式やトーンを固定したい → システム。毎回同じ例を使う
• タスクごとに参照すべき例が違う → ユーザー。その都度渡す

社内文書のトーンを揃えるような用途では、システム側に置いて固定する方が安定します。

Claude と ChatGPT の扱いの違い

観点	Claude	ChatGPT
API での指定方法	system パラメータ	system ロールのメッセージ
対話画面での代替	プロジェクト単位の指示	カスタム指示 / プロジェクト指示
遵守度	システム指示への忠実度が高い	高いがやや user に引っ張られやすい
キャッシング	プロンプトキャッシュでシステム部分を再利用できる	部分的なキャッシング

Claude はシステムプロンプトをかなり厳格に守る傾向があり、業務組み込みでの再現性が高いです。ChatGPT はユーザー側の指示で振る舞いが上書きされやすいので、システム側で 明示的に禁止事項を書く ことが大事です。

なお、対話画面（ブラウザやアプリ）には「システムプロンプト欄」が用意されていないのが一般的です。カスタム指示やプロジェクト単位の指示が、実質的に同じ役割 を果たします。API経由で組み込む場合は、明示的にシステムとして指定できます。

具体的なパラメータ名や指定方法はサービスとバージョンによって変わるため、実装前に公式ドキュメントで確認してください。

プロンプトキャッシュとの関係

システムとユーザーを分ける実利のうち、見落とされやすいのがコストです。

多くのAPIでは、プロンプトの先頭から一致する部分だけがキャッシュの対象 になります。前方一致なので、先頭側が1文字でも変わると、それ以降はすべて対象外になります。

ここから導かれる実務上の注意点は次の通りです。

やってはいけないこと	なぜ壊れるか
システムプロンプトの冒頭に現在日時を入れる	毎回先頭が変わり、以降すべてが対象外になる
実行IDやセッションIDを先頭に入れる	同上
顧客名をシステムに埋め込む	顧客ごとに別のキャッシュになり、共有されない
条件分岐でシステムの一部を出し入れする	分岐の組み合わせごとに別のキャッシュになる
リクエストごとにツールの並び順が変わる	ツール定義は先頭側にあるため、順序が変わると全体が無効化される

安定して変わらないものを前に、毎回変わるものを後ろに——これだけを守れば、キャッシュはおおむね機能します。システムとユーザーの分離は、この原則を構造として実装したものだと考えると理解しやすくなります。

キャッシュが効いているかは、レスポンスに含まれるキャッシュ読み込みトークン数で確認できます。同じ先頭を持つリクエストを繰り返しているのにゼロのままなら、どこかに毎回変わる要素が混ざっています。

会話の途中でルールを変えたいとき

長い会話の途中で「ここからは簡潔に答えて」「今日から新しいルールを適用」といった指示を追加したい場面があります。

このときシステムプロンプト自体を書き換えるのは避けてください。先頭が変わるため、それまでの会話がすべてキャッシュ対象外になり、コストと待ち時間が跳ね上がります。

代わりの方法は2つあります。

1. 会話の途中にシステムメッセージを差し込む：モデルによっては、会話の流れの中に運営側の指示として挿入できます。対応状況はモデルによって異なるため、使う前に確認してください
2. ユーザーターンに条件として書く：対応していない場合はこちら。「以下の条件を追加します」とユーザーメッセージの中で伝えます

いずれの場合も、すでに送った会話の内容には手を触れない のが原則です。

システムに書いても効かないもの

システムプロンプトは万能ではありません。次のものは、書いても効きません。

• 正確な計算：複雑な計算をさせると誤ります。計算はプログラム側で行ってください
• 最新情報の参照：学習時点以降の情報は知りません。検索機能を併用するか、入力として渡してください
• 矛盾する指示の両立：「網羅的に、かつ簡潔に」はどちらかに寄ります。優先順位を書くか、片方を捨ててください
• 抽象的な品質指示：「高品質に」「適切に」は解釈の幅が広すぎます。何をもって適切とするかを書いてください
• 能力を超えるタスク：入力にない事実は作れません。「知らないことは知らないと書く」と指示しても、完全には防げません

守られないと感じたときは、まず 指示同士が矛盾していないか を確認してください。次に、その指示が具体的かどうかを見ます。多くの場合、原因はこの2つです。

長さの目安と、書きすぎの弊害

システムプロンプトは長ければ良いわけではありません。

• 制約は3つ程度に絞る：10個並べても全部は守られません。指示同士が競合し、優先すべきものが薄まります
• 禁止より肯定形で書く：「専門用語を使わない」より「中学生でも分かる言葉で書く」の方が効きます
• 本当に毎回必要かを見直す：一度だけ必要だった指示が残り続けていることがあります

長くなってきたら、タスクが分割されていない可能性 を疑ってください。ひとつのシステムプロンプトで複数の業務をこなそうとすると、条件分岐が増えて肥大化します。業務ごとにプロンプトを分ける方が、結果的に短く保守しやすくなります。

そのまま使えるシステムプロンプトの雛形

業務用のシステムプロンプトは、次の5ブロックで構成すると過不足がなくなります。

# 役割
{{どの立場で、何を優先して判断するか}}
例：予算配分を決める立場の責任者として。実行可能性とコストを優先し、
　　新規性は評価軸に入れない。

# 前提
{{毎回変わらない背景。業種・規模・体制・用語の定義}}
例：当社は従業員80名の製造業。情報システム担当は1名。
　　社内では「案件」を受注前の商談を指す語として使う。

# 守ること
{{最大3つ。多いほど個々が薄まる}}
例：
1. 入力にない事実を追加しない
2. 判断が分かれる点は「要確認」と明記する
3. 推奨は1つに絞る（複数案を並べない）

# 書き方
{{トーン・文体・禁止表現}}
例：敬体。専門用語は初出で説明を添える。断定的な表現は避ける。

# 出力形式
{{項目・順序・分量}}
例：
1. 結論（1文）
2. 理由（3行以内）
3. 次のアクション（箇条書き、担当と期限つき）

このうち 最も効くのは「前提」 です。一般論しか返ってこないときの原因は、ほぼここの不足にあります。業種・規模・体制・直近の状況——「これを知らない人には答えられない情報」を優先して書いてください。

逆に、分量を最も食うのに効きが薄いのは「役割」 です。肩書きを飾るより、判断基準を1〜2行で書く方が結果が変わります。

動画で見る：同じ用件をトーン五要素で書き分ける（Fitsel AI の無料AI講座） →

業務での具体例

カスタマーサポート Bot

• システム: 役割定義、トーン、禁止事項、出力形式
• ユーザー: 個別の問い合わせ本文と顧客情報

禁止事項の具体性が品質を決めます。「不適切な回答をしない」ではなく、「価格の変更・返金可否・契約解除は回答せず、担当者へエスカレーションする」のように書いてください。

分類タスク

• システム: 分類軸の定義、JSON 出力形式、推測禁止
• ユーザー: 分類対象テキスト

分類軸は、境界のケースをどう扱うかまで書く と精度が上がります。「どちらとも取れる場合はどちらを選ぶか」が書かれていないと、毎回判断が変わります。

コード生成

• システム: 言語、コーディング規約、コメント方針
• ユーザー: 具体的な仕様

既存コードのスタイルに合わせたい場合、規約を文章で説明するより 実際のコードを例として1つ渡す 方が効きます。

議事録の整形

• システム: 出力構造（決定事項/宿題/保留事項）、要約せず原文を残す範囲、推測禁止
• ユーザー: メモ・文字起こし

「メモにない事実を補わない」「発言と推測を分ける」の2条件は、システム側に固定しておくべき典型例です。

よくある失敗

• 全部 user に詰め込む: 役割定義もタスクも一緒くたにすると、毎回長文で送る必要があり、再現性も落ちる
• system を空にする: サービスのデフォルトの振る舞いがそのまま出るので、業務トーンと乖離する
• system に固有データを書く: 顧客名など可変情報を system に入れると、複数顧客向けの呼び出しで使い回せない
• system に日時を埋め込む: プロンプトキャッシュが毎回無効になり、コストと待ち時間が増える
• 矛盾する制約を並べる: 「網羅的に」と「簡潔に」が同居していると、毎回どちらかに寄る
• 会話の途中で system を書き換える: それまでの会話がすべて再処理される。差分は後ろに足す

設計チェックリスト

• システムに書いた内容は、明日も来月も同じか
• 顧客名・日付・案件名がシステムに混ざっていないか
• 役割が肩書きだけになっていないか（判断基準を書いたか）
• 禁止事項が具体的か（「適切に」で済ませていないか）
• 矛盾する制約が同居していないか
• 重要な制約は3つ程度に絞れているか
• 出力形式（項目・順序・分量）を指定したか
• ツールを使う場合、定義の並び順が毎回同じか
• ひとつのシステムプロンプトで複数業務をこなそうとしていないか

このシリーズで読む

本記事は プロンプトエンジニアリング完全ガイド のシリーズの一部です。あわせて以下も参考にしてください。

• Few-shot プロンプティング完全ガイド — 例示で出力を安定させる
• Chain-of-Thought プロンプトの仕組み — 段階的推論で複雑タスクの精度を上げる
• Meta Prompting 完全ガイド — AI にプロンプトを書かせる
• コンテキストエンジニアリングとは？ — プロンプトの先にある設計領域
• AIプロンプト診断・改善 完全ガイド — 効かないプロンプトの直し方

PrompTune で運用する

PrompTune の 無料診断ツール では、プロンプト全体を 5 軸で診断し、システム/ユーザーへの責務分担が適切かを判定します。プロンプト品質の見直しに活用ください。