優れたシステムプロンプトの例とは、チュートリアルにあるような「あなたは役立つアシスタントです」という一行ものではありません。それは、深夜2時に本番アプリが暴走するのを防ぐための具体的な指示ブロックなのです。私たちのコンテンツパイプラインでは10以上のClaudeサブエージェントを運用しており、それぞれがClaude Opus 4.8やGPT-5でバグを出してしまった後に何度も書き直されたシステムプロンプトによって制御されています。この記事ではおもちゃのようなデモは省略します。代わりに、コピペして使える実際のシステムプロンプト7つ（そのうち2つは私たちの本番スタックから直接引っ張ってきたもの）と、信頼性の高いプロンプトすべてに共通する6つの構成要素を紹介します。
主なポイント
- システムプロンプトとは、ユーザーメッセージの前に一度設定される永続的な指示（役割、制約、出力形式、ガードレール）のことです。
- 1,000回のリクエストで内容が同一になるものはシステムプロンプトに入れ、リクエストごとに変わる内容はユーザーターンに入れます。
- 信頼性の高いプロンプトは、役割、コンテキスト、制約、出力形式、ガードレール、例という6つのブロックで構築されます。
- 推論モデル（oシリーズ、GPT-5、Claude Opus 4.5以降）は、「あなた MUST（必須）」といった強制的な表現ではなく、高レベルの目標を求めています。
システムプロンプトに含まれるもの：6つの構成要素
システムプロンプトとは、セッション全体を通じてモデルの役割、動作、制約、出力形式を定義する一連の永続的な指示であり、ユーザーメッセージの前に一度設定されます。信頼性の高いプロンプトには、役割、コンテキスト、制約、出力形式、ガードレール、そしてオプションの例という6つの構成要素が共通しています。これらを正しい順序で配置すれば、本番環境でも耐えうるシステムプロンプトの書き方の要点を押さえたことになります。
各ブロックの役割は以下の通りです。
| ブロック | 役割 | 一行の例 |
|---|---|---|
| 役割 (Role) | モデルの正体と範囲を定義する | 「あなたはAcme社の請求チームのサポートエージェントです。」 |
| コンテキスト (Context) | 毎ターン必要な安定した背景情報 | 「顧客はProプランを利用中。返金は14日以内なら可能。」 |
| 制約 (Constraints) | 厳格なルールと制限 | 「エスカレーションなしで200ドルを超える返金を約束してはいけません。」 |
| 出力形式 (Output format) | レスポンスの正確な形状 | 「120語以内、プレーンテキスト、マークダウン不使用で回答してください。」 |
| ガードレール (Guardrails) | 拒否およびフォールバックの動作 | 「法的助言を求められた場合は、拒否して人間に引き継ぎます。」 |
| 例 (Examples) | 良い回答のサンプル1〜2件 | 理想的な回答を含むサンプル質問。 |
役割ブロックは見た目以上に重要です。Anthropicのドキュメントは明確に述べています。システムプロンプトで役割を設定することはモデルの動作とトーンを焦点化し、「たった一文でも違いを生む」のです。ガードレールブロックについては、拒否ルールと安全性ルールに真剣に向き合う必要があります。これらについてはガードレールガイドで詳しく解説しています。また、Claudeを使用する場合、AnthropicはXMLタグ（<instructions>、<context>、<input>）を使用して各タイプのコンテンツを分離することを推奨しており、モデルがそれらを混同しないようにします。
以下は、6つのブロックを一つのテンプレートにまとめた、コピペ可能なスケルトンです。
# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.
# CONTEXT
{Stable facts the model needs on every request.}
# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.
# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}
# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.
# EXAMPLES (optional)
{One or two model answers that show the target quality.}6つのブロックにより、曖昧な雰囲気を明確な仕様に変えます。これはあくまでシステムプロンプト層のみに関する話です。より広範なテクニック（Few-shot、Chain-of-thought、プロンプトチェーンニング）については、プロンプトエンジニアリングガイドを参照し、それらはシステムプロンプト自体からは除外してください。セッション用システムプロンプトは、コードベース全体を管理するCLAUDE.mdのような永続的なプロジェクトレベルの指示ファイルとは異なり、単一のAPIセッションを対象とします。
本番環境用システムプロンプト例7選（コピペ可能）
今日からsystemパラメータやdeveloperメッセージに貼り付けられるシステムプロンプト例を7つ紹介します。それぞれが実際の業務（エージェント、RAG、サポート、コーディング、JSON、コンテンツQA、翻訳）を対象としており、なぜその主要なブロックが存在するのかを示しています。最後の2つは私たちのパイプラインで実際に稼働しているものです。CursorやDevinのプロンプトがリークされているリポジトリは需要を証明していますが、誰も公開していないのは、なぜ各ブロックが必要なのかを説明する注釈です。
1. 自律型エージェント
役割の範囲を狭く定め、ツール使用ルールを明文化し、無限ループを防ぐための停止条件を与えます。
You are a research agent. Your only job is to answer the user's
question using the provided tools.
TOOLS: web_search, read_url, calculator.
RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.
STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
human and explain why.なぜ有効か：狭い役割と明示的な停止条件があることが、タスクを完了するエージェントと、トークンを浪費してループするエージェントの違いとなります。これは優れたエージェント用システムプロンプトのベストプラクティスの核心です。
2. RAG / 検索Q&A
検索における最大の課題は、モデルが自身の記憶に基づいて回答してしまうのを防ぐことです。一つのルールでこれが実現できます。
You answer questions using ONLY the context provided below.
CONTEXT
{retrieved_chunks}
RULES
- If the answer is not in the context, say: "I don't have that
in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].
OUTPUT
Two to four sentences, plain text, with citations.なぜ有効か：「コンテキストからのみ」という指示と引用形式は、RAGシステムプロンプトにおいて最もコストのかからない幻覚防止策です。
3. カスタマーサポートボット
トーン、エスカレーション経路、そして厳格な金銭的ルールにより、サポートボットはできないことを約束することなく、有益な存在であり続けられます。
You are a support agent for Northwind's billing team. Be warm,
brief, and factual.
CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.
CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.
GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.なぜ有効か：返金に関するガードレールとエスカレーションのフォールバック措置は、サポートボットが本番環境から撤退させられる二大失敗モードを防ぎます。
4. コーディングアシスタント
出力形式とバージョンを制約し、編集前に説明を行うよう強制します。
You are a coding assistant for a Next.js 15 + TypeScript codebase.
RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.
If a request is ambiguous, ask one clarifying question before editing.なぜ有効か：「ファイル全体ではなくdiff形式」という指示とバージョン上限により、アシスタントをあなたの技術スタック内に留めます。コーディングエージェントのためのプロンプト設計は奥が深いため、専用のガイドが必要なほどですが、ここではこの例を簡潔に保っています。
5. 構造化データ / JSON抽出
出力形式ブロックにスキーマを記載し、散文を禁止します。これが信頼性の高い構造化出力のパターンです。
You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.
SCHEMA
{
"company": "string",
"amount_usd": "number",
"date": "YYYY-MM-DD",
"confidence": "low | medium | high"
}
RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.なぜ有効か：説明的な形式よりも、リテラルなスキーマと「有効なJSONのみ」という指示の方が常に優れています。プロンプト以外の強制パターン（JSONスキーマ検証、ツールベースの抽出）については、構造化出力ガイドを参照してください。
6. コンテンツQA / バリデーターエージェント（本番パイプラインより）
これは私たちのスタックで実際に稼働しているものです。バリデーターのシステムプロンプトは「否定制約」の例であり、モデルに対して書いてはいけないことを正確に指示し、その後スクリプトがルールを文字通りチェックします。
You are a content QA agent. You check one blog draft against a
fixed style contract.
BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"
FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
per 500 words of body.
ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
exits non-zero on any hit. If it fails, the post does not publish.なぜ有効か：列挙された禁止リストとgrepコマンドによるチェックは、「流行語を避ける」といった曖昧な指示では決して達成できない強制力を持ちます。モデルは雰囲気に対して反論できますが、非ゼロの終了コードに対しては反論できません。
7. 翻訳エージェント（本番パイプラインより）
これも私たちのものです。翻訳者のプロンプトは、出力形式と完全性の契約であり、モデルが自身の出力に対してセルフチェックを行う仕組みを含んでいます。
You are an expert translator. You translate ONE blog post into ONE
target language.
COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.
DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
"karşılaştırma" (Turkish), or "developpement" instead of
"développement" (French), the translation is WRONG. Re-do it.
If you cannot meet the contract, report the problem. Do not ship a
truncated post.なぜ有効か：完全性の契約と具体的な誤った出力の例により、「正確に翻訳せよ」という曖昧な指示では見過ごされてしまう潜在的な失敗を検知できます。
本番環境でシステムプロンプトを運用して学んだこと
私たちのパイプラインで発生した3つのシステムプロンプト関連のバグは、どのドキュメントページよりも多くのことを教えてくれました。これら3つすべて、聞こえは良いものの具体的でも検証可能でもない指示から生じたものです。以下は、私たちの16以上のClaudeサブエージェント間で発生した問題と、その都度定着した正確な修正方法です。パターンは毎回同じです。曖昧なルールは無視され、具体的で外部チェックされるルールは遵守されます。
禁止用語バグ。 何週間もの間、どれだけ丁寧に依頼してもモデルは下書きにleverage（活用する）やrobust（堅牢な）といった言葉を入れ続けていました。「流行語を避ける」という曖昧な指示は何の効果もありませんでした。解決策は例#6でした。プロンプト内での列挙された禁止リストに加え、出力をgrepし、ヒットがあれば非ゼロで終了するスクリプト、さらに1,000語あたり最大3回というエムダッシュの上限を設定しました。教訓：曖昧な制約は無視されるが、列挙され外部検証される制約は遵守される。
ダイアクリティカルマーク（発音区別符号）バグ。 翻訳者がトルコ語、フランス語、スペイン語でASCII文字を黙って出力していました。karşılaştırmaがkarsilastirmaとなり、ネイティブの読者が指摘するまで誰も気づきませんでした。解決策は、プロンプト内のネイティブ文字テーブル、明示的な誤った出力の例、そして実行後のgrepチェック（ネイティブ文字がゼロなら再翻訳）でした。教訓：ルールだけでなく、失敗の具体的な例をモデルに示すこと。
安定IDバグ。 これは高額なバグです。再翻訳のたびにローカライズされたスラグを再導出するシステムプロンプトのため、パブリッシャーは投稿ごとに2番目のライブドキュメントを発行してしまいました。2026-06-13に54件の重複したライブドキュメントを公開し、リンクエクイティの分裂と重複コンテンツのフラグが発生した3週間後の2026-07-05まで公開を停止できませんでした。解決策：識別子を明示的に固定し、既存のIDをそのまま再利用すること。決定論的でない独自の識別子を再生成するシステムプロンプトは重複を生み出します。私たちがIDを固定する前に、54件のライブドキュメントが発行されてしまいました。
よくあるシステムプロンプトのミスとは？
最も一般的なシステムプロンプトのミスは、長文の指示、矛盾するルール、否定形のみの表現、リクエストごとのコンテキストを静的プロンプトに詰め込むこと、そしてフォールバックの欠如です。2026年のモデルには新しいミスがあります。攻撃的な大文字や「あなた MUST」表現が、Claude Opus 4.5以降で過剰にトリガーされてしまうのです。
簡単な修正リストは以下の通りです。
- 長文の壁。 修正：6つのブロックに分割し、安定したコンテンツを最初に配置する。
- 矛盾する指示。 修正：1行に1ルール；公開前に競合を解決する。
- 否定形のみの表現。 修正：避けるべきことだけでなく、行うべきことを言う。
- 大文字と「MUST」の過剰使用。 Anthropicの新しいモデルでは逆効果になります。同社のドキュメントでは、以前なら"CRITICAL: You MUST use this tool"と書いていた箇所を、「このツールを次の場合に使用してください」といった通常の表現で代替できるとしています。2025年のアドバイスは、今やミスとなっています。
- 静的プロンプトへの動的コンテキスト埋め込み。 リクエストごとのデータはユーザーターンに残す。何がどこ belong するかはそれ自体が規律であり、コンテキストエンジニアリングガイドで解説しています。
- フォールバックの欠如。 常に拒否反応とエスカレーション経路を定義する。
- 長さとコストの無視。 長いプロンプトは呼び出しごとにレイテンシとトークンコストを増加させる；価値のあるものだけを残して削る。
指示の明確さに関する基本的な事項については、OpenAIのベストプラクティス記事が依然として確かなチェックリストとなっています。
システムプロンプトをテストし改善するには？
システムプロンプトはコードと同じようにテストします。期待される出力を持つ小さなゴールデンセットの入力を構築し、変更のたびにモデルのレスポンスに対してアサーションを行います。同じ入力に対して2つのプロンプトバージョンをA/Bテストし、より多くのチェックをパスした方を保持します。アサーションは目視確認よりも常に優れています。
最小限の評価ループは以下のようになります。
# pseudo eval loop
for case in golden_set:
out = model(system=PROMPT, user=case.input)
assert is_valid_json(out) # format check
assert case.expected_field in out # content check
if case.no_context:
assert "I don't have that" in out # refusal check
# ship the prompt version that passes the most cases例#6のgrepは、実行できる最も安価なアサーションです。コストがかからず、疲れることもありません。プロンプトライブラリが数個を超えて成長したら、ファイル間でのコピペではなく、実際のプロンプト管理ツールを使用してプロンプトのバージョン管理とテストを行ってください。規模に関わらずポイントは同じです。生産性プロンプトを変更する際は、それが良くなったのか悪くなったのかを教えてくれるチェックなしで行わないこと。
システムプロンプト vs ユーザープロンプト vs 開発者メッセージ
システムプロンプトは固定された動作を設定し、ユーザープロンプトはリクエストごとのタスクを運び、開発者メッセージはOpenAIの推論モデルにおけるロールで、コマンドチェーンにおいてユーザーメッセージよりも上位にランクされるアプリレベルの指示を保持します。Anthropicはrole: "system"メッセージの代わりにトップレベルのsystemパラメータを使用します。以下は、競合他社がしばしば見逃す3者の違いです。
| 層 | 設定者 | リクエストごとに変更？ | OpenAIの仕組み | Anthropicの仕組み |
|---|---|---|---|---|
| システムプロンプト | アプリ開発者 | いいえ、安定 | メッセージ内の role "system" | トップレベルの system パラメータ |
| 開発者メッセージ | アプリ開発者 | まれに | 推論モデルでの role "developer" | system パラメータに統合 |
| ユーザープロンプト | エンドユーザー | はい、毎ターン | メッセージ内の role "user" | メッセージ内の role "user" |
OpenAIはランキングについて明確にしています。「開発者メッセージはアプリケーション開発者によって提供される指示であり、ユーザーメッセージよりも優先されます」。したがって、ユーザーがアプリのルールを上書きしようとしても、開発者メッセージがコマンドチェーンで勝ります。
推論モデルには異なるシステムプロンプトが必要か？（2026年）
はい。OpenAIのoシリーズ、GPT-5、Claude Opus 4.5以降などの推論モデルは、段階的なスクリプトではなく、高レベルの目標を求めています。OpenAIは、推論モデルを詳細を任せることができるシニアな同僚と比較し、一方のGPTモデルは明示的な指示を必要とするジュニアのように振る舞うと説明しています。
この枠組みはプロンプトの書き方を変えます。推論モデルの場合、目標と制約を述べ、「詳細の処理は彼らに任せる」べきです。一方、GPTモデルの場合は手順を詳述します。推論モデルに対して過度に詳細を指定すると、むしろ性能が低下することがあります。
Claude側にも2026年の変化があります。Opus 4.5以降はシステムプロンプトに対してより反応するため、CRITICAL:やMUSTを重ねる古い習慣は現在、過剰トリガーを引き起こします。この言語表現を通常の表現に戻しましょう。コストに関する注意点：安定した再利用コンテンツはプロンプトの先頭に配置し、プロンプトキャッシュが機能して繰り返し呼び出し時のレイテンシを削減できるようにします。また、推論モデルが段階的な作業を行っている場合、Chain-of-thoughtプロンプティングはそれ自体がテーマであり専用ガイドがあるため、ここでは再解説しません。
Techsyのアプローチ
TechsyではB2Bクライアント向けのエージェントシステムを構築しており、上記のバリデーターと翻訳者のプロンプトはその本番スタックで稼働しています。私たちはすべてのシステムプロンプトをコードとして扱います。バージョン管理し、ゴールデンセットに対してテストし、希望ではなくスクリプトで不可欠なルールを強制します。LLM機能をデモから本番環境へ移行し、AI統合作業で支援が必要な場合は、無料相談をご利用ください。
著者について
Mert Batur GurbuzはTechsy.ioの共同創設者であり、チームはB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを提供しています。バーミンガム大学で学び、Techsyチームが本番環境で実際に使用しているLLMツールスタックについて執筆しています。
共同創設者, Techsy.io, バーミンガム大学 · LinkedIn
よくある質問
システムプロンプトとは何ですか？
システムプロンプトとは、ユーザーメッセージの前に一度設定される永続的な指示のセットであり、セッション全体を通じてモデルの役割、動作、制約、出力形式を定義します。これは固定された「どのように動作するか」の層であり、ユーザーのリクエストごとのメッセージが毎ターン変化しても同一のまま維持されます。
システムプロンプトとユーザープロンプトの違いは何ですか？
システムプロンプトは固定された「どのように動作するか」であり、すべてのリクエストで同一です。一方、ユーザープロンプトはリクエストごとの「何をすべきか」です。簡単な経験則として、1,000回のリクエストで内容が同一になるものはシステムプロンプトに属し、呼び出しごとに変化するものはユーザーターンに入れます。
開発者メッセージとシステムプロンプトの違いは何ですか？
OpenAIの推論モデル（oシリーズ、GPT-5）は、systemメッセージの代わりにdeveloperメッセージを受け取ります。これはコマンドチェーンにおいてユーザーメッセージよりも上位にランクされるアプリレベルの指示を運び、ユーザーがルールを上書きしようとした場合に勝ります。Anthropicはロールベースのメッセージではなく、単一のトップレベルsystemパラメータを維持しています。
システムプロンプトはどのくらいの長さにすべきですか？
役割、制約、出力形式、ガードレールをカバーできる限り短くすべきです。長すぎるプロンプトは呼び出しごとにトークンコストとレイテンシを追加し、Claude Opus 4.5以降で余計な推論を過剰にトリガーする可能性があります。安定したプロンプトが長くなる必要がある場合は、再利用されるコンテンツを最初に配置し、プロンプトキャッシュがコストを相殺できるようにします。
システムプロンプトはChatGPT/GPTとClaudeで同じように機能しますか？
概念は同じですが、仕組みは異なります。OpenAIはメッセージ配列内でsystemまたはdeveloperロールを使用しますが、Anthropicは別のトップレベルsystemパラメータを使用し、指示、コンテキスト、例を分離するためにXMLタグを好みます。指示自体はプロバイダー間で移植可能ですが、配線方法とフォーマット規約は異なります。
会話の途中でシステムプロンプトを変更できますか？
API経由では呼び出しごとにメッセージペイロード全体を再送信するため、技術的にはターン間でシステムプロンプトを入れ替えることができます。しかし、会話の途中で変更すると連続性が損なわれ、モデルが自身のルールについて混乱する可能性があります。一度設定することを推奨するか、特定のタスク用プロンプトのために意図的に入れ替えるのが良いでしょう。
システムプロンプトではXMLタグとマークダウンのどちらを使うべきですか？
AnthropicはClaudeにおいて、モデルがそれらを混同しないよう、指示、コンテキスト、例を分離するためにXMLタグを推奨しています。OpenAIモデルはマークダウンやプレーンな見出しを適切に処理します。両方で一つのスタイルを強制するのではなく、プロバイダーの規約に合わせて選択し、単一のプロンプト内では一貫性を保つようにしてください。
推論モデルには異なるシステムプロンプトが必要ですか？
はい。推論モデルは、段階的なマイクロマネジメントではなく、シニアな同僚にブリーフィングするような高レベルの目標を求めています。Claude Opus 4.5以降などの新しいモデルで過剰トリガーを引き起こす攻撃的な大文字や「あなた MUST」言語は避け、目的とガードレールを述べ、そこに至る経路の計画はモデルに任せます。
良いシステムプロンプトの構成要素は何ですか？
6つのブロック：役割、コンテキスト、制約、出力形式、ガードレール（またはフォールバック）、そしてオプションでいくつかの例。役割と制約が大部分の仕事を担い、出力形式ブロックがレスポンスを解析可能にし、ガードレールが境界での動作を定義します。例は、目標とする品質を言葉で説明するのが難しい場合にのみ追加する価値があります。