Claudeを業務アプリケーションに組み込む際、最も重要な設計要素の一つがシステムプロンプトです。システムプロンプトの品質が、AIの出力精度、一貫性、安全性を大きく左右します。しかし、効果的なシステムプロンプトの設計には体系的な知識と経験が必要であり、場当たり的に書いたプロンプトでは期待通りの結果を得られないことが多いのが実情です。本記事では、システムプロンプトの設計原則から、業務別のテンプレート、アンチパターン、テスト方法まで、実務に直結する設計パターン集をお届けします。
システムプロンプトの役割と設計原則
システムプロンプトは、ClaudeのAPI呼び出し時にsystemパラメータとして設定する指示文です。ユーザーからの入力（humanメッセージ）とは別に、AIの動作を規定する「裏側の設定」として機能します。システムプロンプトの主な役割は4つあります。第一に「ペルソナの定義」です。AIがどのような立場で、どのようなトーンで応答するかを規定します。第二に「制約条件の設定」です。回答してはいけない内容、触れてはいけないトピック、守るべきルールを明確にします。第三に「出力フォーマットの指定」です。回答の構造、長さ、形式を統一します。第四に「コンテキストの提供」です。業務固有の知識や前提情報を与えることで、的確な回答を導きます。
設計の基本原則として、以下の5つを常に意識してください。原則1「明確性」として、曖昧な表現を避け、具体的で解釈の余地がない指示を書きます。原則2「構造化」として、XMLタグや見出しを使って情報を整理し、Claudeが指示を正確に理解できるようにします。原則3「優先順位」として、最も重要なルールを冒頭に配置し、Claudeが優先すべき指示を明確にします。原則4「テスト可能性」として、システムプロンプトの効果を客観的に測定できるように設計します。原則5「保守性」として、将来の変更や拡張が容易な構造にします。
XMLタグによる構造化テクニック
Claudeは、XMLタグで構造化された指示を非常に正確に理解・遵守する特性があります。これはAnthropicが公式に推奨しているテクニックで、システムプロンプトの精度を大幅に向上させます。基本的な構造化パターンとして、roleタグでAIの役割を定義し、constraintsタグで制約条件を列挙し、output_formatタグで出力形式を指定し、examplesタグで具体例を示します。各セクションをXMLタグで囲むことで、Claudeは各指示の境界と目的を明確に認識できます。
XMLタグの命名は、内容が一目でわかる英語名にするのが効果的です。例えば、role、constraints、output_format、examples、context、rules、prohibited_topicsなどです。日本語のタグ名でも機能しますが、英語名の方が慣例的によく使われており、他のチームメンバーとの共有もスムーズです。また、タグのネスト（入れ子）も活用できます。constraintsタグの中にtoneタグとlengthタグを入れるなど、階層構造で情報を整理することで、より細かい制御が可能になります。
ペルソナ設定と制約条件の書き方
ペルソナ設定は、システムプロンプトの冒頭に配置する最も重要な要素の一つです。効果的なペルソナ設定には、AIの専門性（何の専門家か）、対象ユーザー（誰に向けて応答するか）、コミュニケーションスタイル（フォーマル/カジュアル、敬語/丁寧語）、知識の範囲（何を知っていて、何を知らないか）を明確に定義する必要があります。例えば、社内FAQ botのペルソナ設定は次のようになります。「あなたは株式会社XXXの社内ヘルプデスク担当者です。社員からの質問に対して、社内規則や手続きに基づいて正確に回答します。敬語を使用し、簡潔で分かりやすい回答を心がけてください。社内規則に記載のない質問については、推測で回答せず、担当部署への問い合わせを案内してください。」
制約条件は、AIが「やってはいけないこと」を明確にする部分です。制約条件の書き方のコツとして、否定形だけでなく、代替行動も示すことが重要です。「個人情報について回答しないでください」ではなく「個人情報に関する質問を受けた場合は、人事部（内線XXXX）への問い合わせを案内してください」と書くことで、Claudeは適切な代替行動を取ることができます。また、制約条件はできるだけ具体的に書きましょう。「不適切な回答をしない」という曖昧な指示よりも、具体的にどのような回答が不適切なのかを例示する方が効果的です。
出力フォーマット指定とFew-shot例の入れ方
出力フォーマットの指定は、Claudeの出力を後続処理で利用するために不可欠です。テキストで人間が読む場合は緩やかな指定で十分ですが、プログラムが処理する場合は厳密なフォーマット指定が必要です。フォーマット指定のベストプラクティスとして、構造を明示的に定義することが重要です。JSONの場合はスキーマを、テーブルの場合はカラム名と各カラムのデータ型を、箇条書きの場合は階層構造のルールを具体的に指示します。例えば「以下のJSONスキーマに厳密に従って出力してください。追加のフィールドは含めないこと」という指示とともにスキーマ定義を記載します。
Few-shot例（具体的な入出力の例示）は、Claudeに期待する出力の品質とフォーマットを最も効果的に伝える方法です。Few-shot例の入れ方のポイントは3つあります。第一に、典型的なケースと境界ケースの両方を含めること。第二に、例は2〜3個で十分であること（多すぎるとトークンを消費し、かえって性能が低下する場合がある）。第三に、各例にはなぜその出力が正しいのかのコメントを添えると、Claudeの理解がより正確になること。examplesタグ内にexampleタグを入れ子にして、inputとoutputを対にして示すのが標準的なパターンです。
業務別テンプレート：5つの実践パターン
ここからは、業務別のシステムプロンプトテンプレートを5つ紹介します。パターン1は「社内FAQ bot」です。社内FAQ botのシステムプロンプトでは、roleとして「社内ヘルプデスクの一次対応担当」を定義し、knowledge_baseとして社内規則や手続き文書をcontextに含めます。constraintsとして、ナレッジベースに記載のない質問への推測回答の禁止、個人情報の取り扱いルール、エスカレーション先の情報を設定します。output_formatとして、回答の構成（結論→根拠→補足情報）を指定し、根拠には必ず参照元の文書名と条項番号を含めるよう指示します。
パターン2は「議事録要約」です。会議の文字起こしから、構造化された議事録を自動生成するシステムプロンプトです。roleとして「議事録作成の専門アシスタント」を定義し、output_formatとして、会議基本情報（日時、参加者、議題）、各議題の要約、決定事項、アクション項目（担当者・期限付き）、次回予定という構成を指定します。constraintsとして、発言者の意図を正確に反映すること、推測や補完を行わないこと、不明瞭な部分は「確認が必要」と明示することを記載します。
パターン3は「契約書チェック」です。契約書のリスクポイントを自動的にチェックするシステムプロンプトです。roleとして「法務部のリスクレビュー支援アシスタント」を定義し、チェック項目として、不利な条項の検出、曖昧な表現の指摘、一般的な契約慣行との乖離、損害賠償条項や解約条項のリスク評価を設定します。最も重要なconstraintとして、「法的助言ではなく、チェックリスト的な指摘に留めること。最終判断は必ず法務担当者が行うこと」を明記します。
パターン4は「コードレビュー」です。開発チーム向けのコードレビュー支援のシステムプロンプトです。roleとして「シニアソフトウェアエンジニアのレビューアー」を定義し、レビュー観点としてバグの可能性、セキュリティリスク、パフォーマンス、可読性、テスタビリティを設定します。output_formatとして、各指摘に重要度（Critical/Warning/Suggestion）を付与し、修正案のコード例を添えるよう指定します。パターン5は「カスタマー対応」です。顧客からの問い合わせに対する回答ドラフトを生成するシステムプロンプトです。roleとして「カスタマーサポートの担当者」を定義し、toneとして「丁寧で共感的、かつ簡潔」を指定します。constraintsとして、値引きや特別対応の約束をしないこと、技術的な問題は技術チームへのエスカレーションを案内すること、回答に自信がない場合は上長確認を促すことを記載します。
システムプロンプトのアンチパターン
効果的なシステムプロンプトを設計するためには、よくあるアンチパターンを知っておくことも重要です。アンチパターン1は「指示の過積載」です。一つのシステムプロンプトに大量の指示を詰め込みすぎると、Claudeが優先順位を判断できず、重要なルールが無視される可能性があります。指示は必要最小限に絞り、優先度の高いものから順に記載しましょう。アンチパターン2は「矛盾する指示」です。「簡潔に回答してください」と「詳細な根拠を示してください」のように、相反する指示を含めてしまうケースです。指示間の整合性を確認し、矛盾がある場合は優先順位を明示的に示します。
アンチパターン3は「曖昧な制約条件」です。「適切に対応してください」「必要に応じて判断してください」のような曖昧な表現は、Claudeの解釈に任せることになり、意図しない動作につながります。何が「適切」で何が「必要」なのかを具体的に定義しましょう。アンチパターン4は「ネガティブ指示のみ」です。「〜しないでください」という禁止事項ばかりで、望ましい行動を示さないパターンです。禁止事項には必ず代替行動をセットで記載しましょう。アンチパターン5は「テストなしの本番投入」です。システムプロンプトを作成後、十分なテストを行わずに本番環境に投入するのは大きなリスクです。想定されるユーザー入力のバリエーション、エッジケース、悪意ある入力に対する挙動を確認してから展開しましょう。
システムプロンプトのテスト方法
システムプロンプトの品質を担保するためには、体系的なテストが不可欠です。テストは3つのフェーズで実施します。フェーズ1「機能テスト」では、システムプロンプトが意図通りに機能するかを確認します。典型的な入力に対して期待通りの出力が得られるか、出力フォーマットが仕様に合致しているか、ペルソナ設定が反映されているかをチェックします。テストケースは最低10パターンを用意し、各パターンについて期待する出力を事前に定義しておきます。フェーズ2「境界テスト」では、エッジケースや異常系の入力に対する挙動を確認します。極端に長い入力、無関係な質問、禁止トピックに関する質問、プロンプトインジェクションの試み、多言語での入力などをテストします。
フェーズ3「回帰テスト」では、システムプロンプトを変更した際に、既存の機能が壊れていないかを確認します。過去のテストケースを再実行し、変更の影響範囲を把握します。テスト結果はスプレッドシートやテスト管理ツールで記録し、バージョンごとの品質推移を追跡できるようにしましょう。システムプロンプトの設計は、一度作って終わりではなく、テストと改善を繰り返す継続的なプロセスです。numomentのClaude研修では、こうしたテスト手法を含む実践的なシステムプロンプト設計スキルを体系的に習得できます。
関連記事
Claude研修プログラムの設計方法について詳しく知りたい方は、 Claude AI研修プログラム設計ガイド2026 をご覧ください。また、非エンジニア向けの活用法については、 非エンジニアのためのClaude活用ガイド2026 も参考になります。