Prompt Engineering 2026年4月12日

システムプロンプト設計パターン

LLMの振る舞いを安定的に制御するシステムプロンプトの設計パターンと、Claude・GPT別の最適化手法を解説。

#prompt-engineering #system-prompt #design-patterns #claude #chatgpt

システムプロンプトとは

システムプロンプトは、LLMの会話全体を通じた永続的な指示セットです。ユーザープロンプトが「今回何をするか」を指定するのに対し、システムプロンプトは「どのように振る舞うか」を定義します。2026年現在、制約条件・出力フォーマット・ペルソナ設定はシステムプロンプトに集約し、ユーザープロンプトには純粋に質問とデータのみを入力する設計が標準です。

Anthropicの表現を借りれば、良いシステムプロンプトは**「短い契約書」**のように読めるべきです。明示的で、範囲が限定されていて、チェック可能であること。

基本設計パターン

パターン1: 4ブロック構造

最も汎用的な構造パターンです。

# INSTRUCTIONS
あなたはシニアTypeScriptエンジニアです。
コードレビューを行い、改善提案を具体的なコード例付きで提示してください。

# CONTEXT
対象プロジェクトはAstro + React + TypeScriptのWebアプリケーションです。
テストフレームワークはVitestを使用しています。

# CONSTRAINTS
- any型の使用は必ず指摘する
- 改善提案には重要度（高・中・低）を付与する
- セキュリティに関する指摘は最優先で報告する
- 不明な点は推測せず、質問として返す

# OUTPUT FORMAT
以下の形式で出力してください:
## 重要度: 高
- [指摘内容] → [改善コード例]
## 重要度: 中
- ...

4ブロック（INSTRUCTIONS / CONTEXT / CONSTRAINTS / OUTPUT FORMAT）に分割することで、各要素の役割が明確になり、モデルの解釈精度が向上します。

パターン2: XMLタグによるセクション分離（Claude推奨）

ClaudeではXMLタグによる構造化が公式に推奨されています。Claude Sonnet 4.5の内部システムプロンプトでも、<behavior_instructions>や<artifacts_info>などのタグが使用されています。

<role>
あなたはプロダクトマネージャーのアシスタントです。
ユーザーストーリーの作成と優先順位付けを支援します。
</role>

<rules>
- INVEST原則に従ったユーザーストーリーを作成する
- 受入基準は具体的かつテスト可能な形で記述する
- 技術的な実装詳細はストーリーに含めない
- 見積もりはストーリーポイント（フィボナッチ数列）で行う
</rules>

<guardrails>
- 個人情報や機密情報を含む要件は受け付けない
- 不明確な要件は実装提案せず、明確化のための質問を返す
</guardrails>

<examples>
<example>
ユーザーストーリー: 「ユーザーとして、パスワードをリセットしたい。なぜなら、ログインできなくなった際に自力で復旧したいから。」
受入基準:
- 登録済みメールアドレスにリセットリンクが送信される
- リンクの有効期限は24時間
- 新しいパスワードは8文字以上で設定できる
ポイント: 3
</example>
</examples>

パターン3: ガードレール分離パターン

AIエージェント向けの設計で重要なパターンです。ガードレール（安全制約）を通常の指示から構造的に分離することで、制約の遵守率が向上します。

# ROLE AND CAPABILITIES
あなたはカスタマーサポートAIです。
製品の問い合わせに回答し、必要に応じてチケットを作成します。

# OPERATIONAL INSTRUCTIONS
1. まず顧客の問題を正確に特定する
2. ナレッジベースから該当する解決策を検索する
3. 解決策を分かりやすく提示する
4. 解決しない場合、人間のオペレーターにエスカレーションする

# GUARDRAILS（必ず遵守）
- 返金・キャンセルの最終承認は行わない（人間に委任する）
- 競合他社の製品について評価・比較しない
- 顧客の個人情報を応答に含めない
- 医療・法律のアドバイスを提供しない

ガードレールを段落内に埋め込むのはアンチパターンです。独立したセクションとして視覚的・構造的に分離することで、モデルが制約を見落とすリスクを低減できます。

モジュラープロンプト設計

2026年のベストプラクティスとして、システムプロンプトを再利用可能なモジュールに分割する手法が普及しています。

# トーンモジュール（共通）
<tone>
- 丁寧だが簡潔に回答する
- 専門用語は必要に応じて平易な言葉で補足する
- 不確実な情報は「〜の可能性があります」と明示する
</tone>

# フォーマットモジュール（タスク別に差し替え）
<format_rules>
- 見出しは##で始める
- コードブロックには言語を指定する
- 箇条書きは5項目以内に収める
</format_rules>

# ドメインモジュール（プロジェクト別に差し替え）
<domain_knowledge>
- 技術スタック: Astro + Cloudflare Workers
- コーディング規約: camelCase、1ファイル1責務
- テスト方針: TDD、Vitestを使用
</domain_knowledge>

トーンやフォーマットのモジュールは複数プロジェクトで共有し、ドメイン知識のモジュールだけをプロジェクトごとに差し替えることで、品質の一貫性と保守性を両立できます。

モデル別の最適化

Claude向け

XMLタグの活用: セクション分離にはXMLタグが最も効果的
契約書スタイル: 曖昧さを排除し、チェック可能な条件を記述する
例示の明確な分離: <example>タグで例をインストラクションと区別する
肯定形での指示: 「〜しないで」より「〜してください」が効果的

GPT-4.1向け

Markdown見出しの活用: #による階層構造が最も効果的
具体的な数値制約: 「簡潔に」ではなく「5つの箇条書き、各15語以内」
システムプロンプトの長さ: 過度に長いプロンプトは逆効果。必要最小限に留める

Gemini向け

XMLタグの推奨: Claudeと同様にXMLタグでの構造化が公式推奨
thinking_level設定: 複雑なプロンプト設計よりパラメータ制御が効果的

いつ使うべきか

チャットボット・アシスタント: 一貫した人格と応答スタイルの維持
AIエージェント: 安全制約と行動範囲の定義
API統合: 出力形式と処理ルールの標準化
チーム開発: プロンプトの組織的な共有・管理

注意点・限界

前方詰め込みのアンチパターン: あらゆる指示を事前にシステムプロンプトに詰め込むと、単純なタスクでも全指示をコンテキストに保持するコストが発生する。動的に必要な指示だけを注入する設計が望ましい
高性能モデルでの過度な制約は逆効果: GPT-5やClaude Opusレベルでは、精巧な制約条件が「過度な字義通りの解釈」を引き起こし、自律的な推論を妨げるケースが報告されている（標準CoTが96.36%に対し、制約ベースが94%）
組織レベルでの蓄積が必要: 個人が各自でプロンプトを工夫し、組織に蓄積されない状態は最大のアンチパターン。バージョン管理とレビュープロセスを導入すべき
モデルアップデートへの追従: モデルの挙動変更によりシステムプロンプトの効果が変わることがある。定期的な評価が必要