システムプロンプトに何を書くか・何を書かないか — 7つの判断基準

この記事でわかること:

• システムプロンプトとユーザープロンプトの役割分担
• システムプロンプトに書くべき7つの判断基準
• 2026年の実例と失敗パターン

結論: システムプロンプトは「変わらないこと」だけを書く

システムプロンプトの設計でよくある失敗は「あれもこれも詰め込む」ことです。2026年の正解は明確で、「セッションを通じて変わらないこと」だけをシステムプロンプトに書き、それ以外はユーザープロンプトに置きます。具体的な7つの判断基準を紹介します。

判断基準1: 役割定義（書く）

「あなたは○○の専門家です」のような役割定義は、セッション全体で一貫しているべきです。途中で変わると応答が不安定になります。1〜2行で簡潔に書きます。

判断基準2: 守るべき制約（書く）

「個人情報を回答に含めない」「敬語で応答する」「英語で出力しない」など、セッション全体で守るべきルールはシステムプロンプトに置きます。これを忘れると一貫性のない応答になります。

判断基準3: 出力フォーマット（書く）

常に同じフォーマット（JSON、Markdown、特定の見出し構造）で出力させたい場合は、システムプロンプトに記述します。例示も含めると効果的です。

判断基準4: 専門用語の定義（書く）

業務固有の用語（「テナント」「ワークスペース」など、組織独自の意味）はシステムプロンプトで定義します。毎回ユーザーが説明するのは非効率です。

判断基準5: 個別タスクの内容（書かない）

「今回は注文データを分析してほしい」のような毎回変わる指示はシステムプロンプトに書きません。ユーザープロンプト側に置くべきです。

システムプロンプトに具体タスクを書くと、新しいタスクに切り替える時に全体を書き換える必要が出てきます。

判断基準6: 入力データ（書かない）

分析対象のデータ、ドキュメント本文、コードはユーザープロンプトに置きます。システムプロンプトに入れるとキャッシュ効率が悪化することもあります。

判断基準7: 例示の使い分け

普遍的な例（出力フォーマットの例など）はシステムプロンプトに、タスク固有の例はユーザープロンプトに置きます。使い分けで品質が大きく変わります。

システムプロンプトのテンプレート

# 役割
あなたは[役割]です。

# 専門用語
- [用語1]: [定義]
- [用語2]: [定義]

# 守るべきこと
- [制約1]
- [制約2]

# 出力フォーマット
[フォーマット仕様]

# 出力例
[例1]

失敗パターン

失敗1: タスク内容を全部書く

「今回はXX社のYY機能の設計をして、ZZの仕様に基づき…」のように具体タスクをシステムプロンプトに詰め込むと、他のタスクで使い回せなくなります。

失敗2: 例示が多すぎる

システムプロンプトに10個のFew-shot例を入れると、トークン数が膨大になり、精度も逆に下がります。3個までが目安です。

失敗3: 矛盾する指示

「簡潔に」と「詳しく」を同時に書くと、LLMはどちらを優先するか判断できません。優先順位を明示するか、片方を削ります。

失敗4: 更新管理されていない

システムプロンプトは「本番コードと同じく」Gitで管理し、変更時はPRレビューを通すべきです。直接編集して秘伝のタレ化させてはいけません。

サイズの目安

システムプロンプトの理想サイズは200〜600字程度です。これを大きく超えるなら、何かを切り出してユーザープロンプト側に移せないか検討してください。1000字を超えるシステムプロンプトは、たいてい肥大化しています。

事例

あるカスタマーサポートAIで、当初は3500字のシステムプロンプトを使っていましたが、判断基準に従って整理した結果、500字まで圧縮できました。精度は変わらず、レイテンシが30%短縮。タスク追加時のメンテナンスコストも激減しました。

キャッシュとの関係

2026年のLLMサービスはプロンプトキャッシュをサポートしているものが多く、システムプロンプトを固定するとキャッシュヒットが効きます。長期間変えないシステムプロンプトはコスト最適化にも貢献します。

まとめ

システムプロンプトには「変わらないこと」だけを書きます。7つの判断基準—役割・制約・フォーマット・用語・タスク（書かない）・データ（書かない）・例示—を参照して、200〜600字に収めましょう。2026年のプロンプト設計は、明確な役割分担で安定性とコスト効率を両立させる時代です。