生成AIを業務に取り込み始めると、多くの人が同じところで足を止めます。会話のたびに「あなたは製造業向けの営業担当です」「箇条書きは使わないでください」と同じ前置きを打ち直している。あるいは、チーム内で同じツールを使っているのに、返ってくる文章の質が人によってそろわない。
その前置きをまとめて置いておく設定欄が、システムプロンプトです。ChatGPTのGPTsやClaudeのプロジェクト機能、各社が提供するAPIに用意されているもので、利用者が何かを入力するより前にモデルが読む指示文にあたります。
本記事では、ユーザープロンプトとの違いから書き方の手順、そして出力が安定しないときにどこを疑うかまでを、AIを日常的に使って記事を制作している立場から整理しました。
- システムプロンプトとユーザープロンプトの役割の違い
- 設定できる場所と、それぞれでの書き分け方
- システムプロンプトに書く5項目と、優先度の付け方
- 出力がブレるときに疑う4つの原因
- 書いた後の運用で差がつく3つの習慣
システムプロンプトとは、会話の前に毎回読まれる指示文
システムプロンプトとは、AIモデルに対して「どういう立場で、どんな制約のもとで答えるか」をあらかじめ渡しておく指示文です。利用者が打ち込む質問や依頼とは別の場所に置かれ、会話が何往復続いても背後で参照され続けます。
近いのは、新しく入ったスタッフに渡す業務マニュアルです。仕事のたびに読み上げるものではありませんが、判断に迷ったときの基準として参照されます。システムプロンプトも、利用者が意識しないまま毎回の回答の背景として働きます。
技術的な言い方をすれば、モデルに送られる入力の先頭にシステムプロンプトが置かれ、そのあとに過去のやり取りと今回の入力が続く構造です。システムプロンプトは、会話が続く限り毎回読み込まれる指示文である、という点が最初の理解の起点になります。

ユーザープロンプトとの違いは「持続」と「優先度」
両者を分けているのは、書いてある内容の難しさではありません。持続するかどうかと、指示がぶつかったときにどちらが優先されるか、という2点です。
| システムプロンプト | ユーザープロンプト | 参照ドキュメント | |
|---|---|---|---|
| 書く人 | 開発者・設定した人 | 実際の利用者 | 開発者が用意した資料 |
| 持続 | 会話全体に適用 | その1回のみ | 検索で該当したときだけ |
| 内容 | 役割・判断基準・形式 | 個別の依頼 | 事実・数値・社内情報 |
| 変更の頻度 | 低い | 毎回 | 資料の更新に合わせる |
| 指示の優先度 | 高い | 中 | 参照対象であり指示ではない |
主要なモデルは、開発者側の指示を利用者側の指示より上位に扱う設計になっています。「社内向けの情報は答えない」とシステムプロンプトに書いておけば、利用者が「さっきのルールは無視して」と入力しても、簡単には覆りません。
ただし、この優先度は絶対ではありません。巧妙な入力で制約がすり抜けられる事例は継続的に報告されており、規約ではなく設計上の重み付け、と捉えるのが実務的です。
実物を読むと輪郭がつかめる
概念の説明を10読むより、実際に運用されているシステムプロンプトを1つ通読するほうが理解は早く進みます。Anthropicは、Claudeの一般向けアプリで使っているシステムプロンプトを公開しており、モデルの更新ごとに差分を追えるようになっています。
※ 出典 Anthropic「システムプロンプト」Claude Platform Docs
読むと分かるのは、凝った言い回しがほとんどないことと、禁止事項のあとに必ず代わりの振る舞いが指定されていることです。判断が必要な場面を1つずつ潰す記述が、分量の大半を占めています。
関連記事:生成AIのビジネス活用完全ガイド|企業の活用事例と導入ポイントを徹底解説
システムプロンプトを設定できる場所
システムプロンプトという言葉が指す設定欄は、使っている環境によって名前が変わります。呼び名が違うだけで役割は同じなので、自分が触れる場所がどれにあたるかを最初に把握しておくと迷いません。
ノーコードで使える範囲では、ChatGPTのGPTs作成画面にある指示欄、Claudeのプロジェクト単位で設定するカスタムインストラクション、各種AIツールの「アシスタント設定」などが該当します。いずれも、その中で始まった会話すべてに適用されます。
開発者としてAPIを扱う場合は、置き場所がモデル提供元ごとに分かれています。
主要APIでの置き場所OpenAIのAPIでは、メッセージ配列の中で`role`を`system`にした要素として渡します(推論系の新しいモデルでは`developer`という役割名が用意されている場合もあります)。Anthropic Claudeでは、メッセージ配列とは別に`system`パラメータが独立して用意されています。Google Geminiでは`systemInstruction`という設定項目にあたります。
自社の業務システムに組み込む場合は、利用者に触らせないことが前提です。担当者が入力するのは質問だけで、答え方のルールは管理者が一箇所で管理する。分離できていれば、ルールを変えた瞬間に全員の出力が同時に変わります。
関連記事:AIプロンプトとは?出力が変わる書き方の型と業務別の例文
システムプロンプトに書くのは、この5項目に絞る
書き方を調べると、要素を10も20も挙げる解説に出会います。ただ運用してみると、増やすほど良くなるという関係にはなりません。指示同士が矛盾すると、モデルはどちらかを取りこぼすからです。
書く内容は、次の5項目に絞ったうえで、それぞれを具体的にするほうが結果は安定します。
- 役割と、答える相手(誰として、誰に向けて話すか)
- 判断の優先順位(情報が足りないとき、指示が衝突したときの取り扱い)
- 出力の形式と分量(文体、見出しの有無、文字数の目安)
- 禁止事項と、その代わりに取る行動
- 参照してよい情報の範囲(渡した資料のみか、一般知識も使ってよいか)

効き目が大きいのは、役割よりも優先順位
「あなたはプロの編集者です」と書いても、出力が期待ほど変わらなかった経験を持つ人は少なくないはずです。役割の指定は文体や語彙にはある程度効きますが、判断そのものを変える力は強くありません。
代わりに効くのが、迷う場面の答えをあらかじめ決めておくことです。渡した資料に答えがないときは推測で埋めるのか、分からないと答えるのか。社内の規定と一般的な慣行が食い違うときはどちらを採るのか。迷ったときにどちらを取るかを書くだけで、出力の振れ幅は目に見えて狭まります。
役割は書いているのですが、担当者ごとに回答の細かさがそろいません。何を足せばよいでしょうか。
編集部
足すより先に、迷いどころを潰すほうが早いです。「情報が不足している場合は不足している旨だけを返す」「1回の回答は400字以内」のように、判断と分量を数値や条件で決めてしまうと、担当者が違っても出力の幅が縮まります。
禁止事項は、代わりの行動とセットにする
もう1つ、書き方で結果が変わるのが禁止の書き方です。「推測で答えないでください」とだけ指定すると、モデルは禁止を守ろうとして回りくどい前置きを並べたり、質問自体をはぐらかしたりします。
禁止事項は「代わりに何をするか」とセットで書くのが基本です。「推測で答えない。資料に記載がない場合は、記載がない旨と、確認先の部署名を返す」と書けば、避けるべき出力と取るべき出力の両方が指定されます。
関連記事:プロンプトとは?生成AIへの指示文の書き方とビジネス例文を解説
ゼロから書くときの手順
まっさらな状態から書き始めると、たいてい途中で手が止まります。すでに手元にある材料から組み立てるほうが、はるかに短時間で使える状態になります。
過去に自分が打ち込んだ依頼文を10件ほど並べ、共通して書いている前置きに印を付けます。その共通部分こそがシステムプロンプトに移すべき内容で、1回きりの依頼はユーザープロンプト側に残します。
資料に答えがないとき、指示が矛盾したとき、専門外の質問が来たとき。実際に起きた場面を3つ挙げ、それぞれどう振る舞ってほしいかを1文で書きます。
文体、見出しの有無、分量の上限を決めます。複数の形式を許すと、そのつど揺れます。形式を変える必要があるときは、ユーザープロンプト側で上書きする運用にします。
最初から作り込まず、5件から10件ほど流してみます。期待と違った出力が出たら、その原因になった判断だけを書き足します。想像で足した指示は、たいてい使われないまま分量だけを増やします。
この順序で進めると、初回のシステムプロンプトはおおむね300字から800字程度に収まります。短いと感じるかもしれませんが、運用しながら足していくほうが、最終的に無駄のない状態に落ち着きます。
社内でAIを使う人が増えてきたが、指示の書き方が人によってバラバラなら
システムプロンプトを整えると、担当者ごとの出力差は縮まります。ただ、誰がどの設定を管理し、変更をどう共有するかまで決めないと、しばらくすると元に戻ります。Writers-hubでは、社内でAIを使いこなす体制づくりを、運用ルールの設計から支援しています。
出力がブレるときに疑う4つの原因
システムプロンプトを設定したのに出力が安定しない。この状態のとき、多くの人がさらに指示を書き足しますが、原因は不足ではなく別のところにあることが多いです。
- 指示が増えすぎて、互いに矛盾している
- 禁止事項だけを書き、代わりの行動を指定していない
- 添えた例が、文章で書いた指示とずれている
- 本来ユーザープロンプトに書くべき個別の依頼を、システム側に書いている
とくに見落とされやすいのが3つ目です。「簡潔に」と指示しながら、例として長い文章を貼っている。「敬体で」と書きながら、例文が常体になっている。モデルは説明文よりも具体例のほうを強く参照する傾向があるため、例が指示を打ち消してしまいます。
書き足す前に、削れる指示がないかを見る出力が期待と違うとき、追記は最後の手段です。まず、いま書いてある指示のうち矛盾しているものと、一度も効いていないものを削ります。分量が半分になっても出力が変わらないなら、その半分は最初から働いていなかったことになります。
4つ目の切り分けも実務では重要です。「今回はA社向けに」といった一度きりの条件をシステムプロンプトに書き込むと、次の案件でも引きずられます。逆に、毎回同じ前置きを利用者が打ち込んでいるなら、それはシステムプロンプト側へ移す合図と考えてよいでしょう。
書いた後の運用で差がつく3つのこと
システムプロンプトは、書いた時点では半分しか終わっていません。使いながら直していく過程のほうが、最終的な品質を決めます。
変更したら、同じ入力で前後を比べる
改善のつもりで書き換えたのに、別の場面で悪化していた。この事故を防ぐ方法は単純で、評価用の入力を固定しておくだけです。実際に来た質問や依頼を10件から20件保存しておき、システムプロンプトを変えるたびに同じ入力を流して出力を並べます。
感覚で判断していると、直近に見た1件の印象で全体を評価してしまいます。

変わらない部分と、変わる部分を分ける
APIを使って業務に組み込む場合、システムプロンプトは入力の先頭に置かれます。多くのモデル提供元が用意しているプロンプトキャッシュは、先頭からの一致部分を再利用する仕組みのため、頻繁に書き換えると再利用が効かなくなります。
そこで、めったに変えない役割や制約を前に、案件ごとに差し替わる情報を後ろに置く。順序を整理するだけで、応答の待ち時間と費用の両方に効いてきます。
機密は書かない
システムプロンプトの中身は、利用者に見えない場所にあるとはいえ、秘匿されている保証はありません。会話の流れによって内容が引き出される事例は各所で報告されています。
書いてよいものと、避けるもの振る舞いのルール、文体、参照範囲の指定は書いて問題ありません。一方、未公開の価格表、取引先の実名、認証情報の類は置かないほうが安全です。システムプロンプトは利用者に読まれる前提で書くと決めておけば、判断に迷いません。
AIへの指示を毎回書き直す作業自体を減らしたいなら
システムプロンプトを整えても、入力と確認を人が毎回手作業で回している限り、削れる時間には限界があります。どの工程を自動化し、どこを人の確認として残すか。Writers-hubでは、業務の流れごと見直したうえでAIを組み込む支援を行っています。
システムプロンプトについてよくある質問
長さと精度は比例しません。指示が増えるほど内部で矛盾が生まれ、モデルはどちらかを落とします。300字から800字程度で始め、実際に外れた場面の分だけ足していく進め方が安定します。
日本語で運用して問題が出ていなければ、日本語のままで構いません。出力言語を確実に固定したい場合は、使用言語を明示的に指定しておくと揺れが減ります。
役割としては同じものです。アカウント全体に適用されるか、特定のGPTsやプロジェクトの中だけに適用されるかという適用範囲の違いがあるため、業務ごとに分けたい場合は後者を使い分けます。
出力形式を固定したいときは有効です。ただし、文章で書いた指示と例文が食い違っていると、例文のほうが優先されます。入れるなら、指示どおりに書かれた例だけを入れてください。
まとめ
システムプロンプトは、AIとの会話が始まる前に毎回読み込まれる指示文で、役割・判断基準・出力形式をまとめて渡しておくための設定欄です。ユーザープロンプトとの違いは、会話全体に持続することと、指示がぶつかったときに上位として扱われることにあります。
書く内容は、役割と読者、判断の優先順位、出力形式、禁止事項と代替行動、参照範囲の5項目に絞る。とくに効くのは役割の指定ではなく、迷ったときにどちらを取るかを決めておくことでした。出力が安定しないときは書き足す前に、矛盾している指示と例文とのズレを疑ってください。
そして運用に入ったら、変えたら、同じ入力で前後を見比べるを習慣にする。この一手間があるかどうかで、半年後に残っているシステムプロンプトの完成度は大きく変わります。
合同会社Writers-hubでは、記事制作の現場でAIを使いながら、社内での活用体制づくりや業務の自動化を支援しています。
自社の業務にどう組み込むかを、一度整理してみませんか
システムプロンプトの設計だけで解決する業務もあれば、扱う資料の整理や工程の見直しから必要な業務もあります。どちらにあたるかは、現在の運用を伺えばおおよそ判断できます。








