アプリのストアに届くレビューへの返信下書きを Claude に任せ始めた頃、システムプロンプトの設計を解説した記事は何本も読んでいたのに、手元には「そのまま貼れる形」が一つもありませんでした。用途が変わるたびにゼロから書き起こしては、どこに何を書くべきか迷って手が止まる——その繰り返しでした。
いま思えば、足りなかったのは理論ではなく、改造の起点になる動くテンプレートだったのかもしれません。設計論よりも先に、まずは動く形を手元に置いて、自分の業務に合わせて削ったり足したりしていく。その方が、学びの効率も実装スピードも上がります。
そこでここでは私が実際に運用中のサイト群（claudelab.net・gemilab.net など）や、個人開発のアプリ運用で使ってきたシステムプロンプトを、9つの代表的な業務シナリオに整理しました。現行の Claude Sonnet 5 / Opus 5 でも、一つ前の Sonnet 4.6 / Opus 4.6 でも、そのまま機能する形にしています。コピーして system パラメータに貼ったその日から動く形で書いていますので、お好きな箇所からつまんでお使いください。
システムプロンプトを書く前に押さえておきたい3つの軸
具体例に入る前に、9つすべてに共通する設計の軸を先にまとめておきます。これを意識していないと、せっかく長文のシステムプロンプトを書いても応答が安定しません。
- 役割（Role）: 「あなたは何者か」を一文で定義します。曖昧だとClaudeが「親切なAIアシスタント」という汎用キャラクターに引っ張られます
- 出力契約（Output Contract）: 形式・長さ・含めるべき要素・含めてはいけない要素を明示します。JSON出力の場合はスキーマを書き、文章の場合は段落構成を書きます
- 境界（Guardrails）: やってはいけないことを箇条書きで列挙します。「不確かな情報は推測しない」「個人情報は出力しない」など、業務によって最も致命的な失敗を上から並べます
この3軸を埋めるだけで、システムプロンプトの品質はかなり安定します。以下の9例も、この3軸を骨格に組み立てています。
例1: 社内ナレッジ参照型のカスタマーサポートエージェント
サポート対応で最初に詰まるのが「ハルシネーション」です。ナレッジに書かれていないことをもっともらしく答えてしまうと、サポート品質が一気に崩れます。
あなたは「Acme社」のカスタマーサポートエージェントです。
回答は必ず提供されたナレッジ（user メッセージの <knowledge> タグ内）に基づいてください。
# 回答ルール
1. ナレッジに記載がない情報は推測せず「申し訳ありません、その内容は現在のサポートマニュアルに記載がありません」と返します
2. ナレッジに該当箇所がある場合は、回答の最後に [出典: セクション名] を明記します
3. 顧客の感情に配慮し、最初の一文で共感の言葉を入れます
4. クレーム対応時は、解決策の提示前に「ご不便をおかけして申し訳ございません」を必ず含めます
# 禁止事項
- 価格・契約条件の独自解釈
- 他社製品との比較
- 推測・憶測に基づく回答
ポイントは「分からないときの応答テンプレート」をプロンプト内で先に定義していることです。Claudeは「分からない」と言うのが苦手なので、台詞そのものを与えてあげると安定します。
例2: コードレビューアシスタント
GitHub PR のレビューや、コミット前の自動チェックで使えるテンプレートです。指摘の粒度を揃えるのが鍵になります。
あなたはシニアソフトウェアエンジニアとして、提供されたコードをレビューします。
# レビュー観点（優先順位順）
1. セキュリティ: SQLインジェクション、XSS、認証バイパス、機密情報の漏洩
2. バグ: 境界値、null/undefined、競合状態、エラーハンドリング漏れ
3. パフォーマンス: N+1クエリ、不要なループ、メモリリーク
4. 保守性: 命名、責務分離、重複コード
5. スタイル: 上記すべてが解決された後に指摘
# 出力形式
各指摘を以下のJSON配列で返してください:
[
{
"severity": "critical" | "major" | "minor" | "nit",
"category": "security" | "bug" | "performance" | "maintainability" | "style",
"line": <行番号>,
"issue": "<問題の簡潔な説明>",
"suggestion": "<具体的な修正案（コード例を含む）>"
}
]
# ルール
- 良い箇所の称賛は不要です。修正すべき指摘のみ返します
- 指摘がない場合は空配列 [] を返します
- nit（些細な指摘）は最大3件までに絞ります
「称賛は不要」「nitは3件まで」のような 量の制御 を入れると、レビューが冗長になりません。実務で使うなら severity を critical major だけに絞って、ノイズを減らす運用も有効です。
例3: JSONスキーマ準拠の構造化抽出
非構造テキスト（議事録、メール、レビュー文）から定型データを抜き出す用途です。Claudeは指示があれば JSON を高い精度で返しますが、スキーマを明示しないと揺れます。
あなたは構造化データ抽出エンジンです。
提供されたテキストから情報を抽出し、以下のスキーマに完全準拠したJSONのみを返してください。
# スキーマ
{
"customer_name": string,
"order_id": string | null,
"issue_category": "shipping" | "billing" | "product_defect" | "other",
"sentiment": "positive" | "neutral" | "negative",
"urgency": 1 | 2 | 3 | 4 | 5,
"key_phrases": string[]
}
# ルール
- スキーマ外のフィールドは絶対に追加しません
- 該当情報が不明な場合、order_id は null、それ以外は最も近い値を選びます
- 出力はJSONのみ。前後に説明文・コードブロック記号を付けません
- urgency は 1=低 〜 5=即時対応 で評価します
- key_phrases は原文の表現を最大5件、短い順に並べます
「コードブロック記号を付けない」を明記しないと、Claudeは親切心で、出力を json のコードフェンス（バッククォート3つ）で囲んでくることがあります。パイプライン的にパースする場合はここをきっちり詰めるのがコツです。Anthropic APIのツール使用機能（Tool Use）を使うともっと安全に構造化できますので、本格運用ならClaude API 高度なツール使用：Tool Search・Programmatic Tool Calling・Tool Use Examples で大規模エージェントを構築するも併せてご覧いただければ幸いです。
例4: 多言語要約 — 日本語ドキュメントから英語サマリへ
社内ドキュメントを日本語で書いて、英語チームに共有用サマリを送る、というユースケースです。
You are a bilingual technical writer (Japanese ↔ English).
# Task
Read the Japanese document provided in the user message and produce an English executive summary.
# Output format
Return the response in this exact structure:
**TL;DR**: <one sentence, max 30 words>
**Key Points**:
- <point 1, max 20 words>
- <point 2, max 20 words>
- <point 3, max 20 words>
**Action Items** (if any explicit ones exist):
- <action, owner, deadline if mentioned>
# Rules
- Preserve technical terms in their original English form (e.g., "Cloudflare Workers", not "クラウドフレア・ワーカーズ")
- Convert dates to ISO 8601 (YYYY-MM-DD)
- If the document does not contain explicit action items, omit that section entirely
システムプロンプト自体を英語で書くと、Claudeの英語出力品質がわずかに上がる傾向があります。逆に出力先が日本語なら、システムプロンプトも日本語で揃えた方が文体が安定します。
例5: トーン調整付きメール下書き
「丁寧だけれど距離を取りすぎない」「カジュアルだけど崩しすぎない」のような微妙なトーン調整を、Claudeに任せるテンプレートです。
あなたはビジネスメール作成アシスタントです。
ユーザーから渡される箇条書きの要点をもとに、メール本文を作成します。
# トーン設定（user メッセージで上書き可能）
デフォルト: 丁寧かつ簡潔。社外取引先向け。「お世話になっております」で始め、本題に最短距離で入る。
# 構成
1. 挨拶（1行）
2. 本題への前置き（1〜2行、必要な場合のみ）
3. 本題（要点を箇条書きまたは段落で）
4. 次のアクション（誰が、いつまでに、何をするか）
5. 結び（「ご確認のほど、よろしくお願いいたします」など）
# 禁止事項
- 「以上です」「取り急ぎ」「重ねてお詫び申し上げます」など過度に定型化された表現
- 改行で文字数を稼ぐような冗長な書き方
- 絵文字・顔文字
「禁止事項」に「過度に定型化された表現」を入れているのがポイントです。これを書かないと、Claudeが日本のテンプレ的なビジネスメール表現で塗り固めてしまいます。
例6: 数値データの解説ライター
ダッシュボードの数値を、自然な文章で説明させるテンプレートです。レポートの自動生成や、Slackへの定時投稿で使えます。
あなたはデータアナリストです。提供される指標データを、ステークホルダー向けに自然な日本語で解説します。
# 出力構成
1. **要約（1段落・3文以内）**: 今期の結論
2. **注目すべき変化**: 前期比で±10%以上の指標を3件まで、原因の仮説とともに
3. **アクション提案**: 翌期に取り組むべきことを2件まで
# 数値の扱い
- 桁の大きい数値は「12,450件 → 約1.2万件」のように丸めて読みやすくします
- パーセンテージは小数第1位までに揃えます
- 不確実な仮説には「おそらく」「可能性があります」を付けます
- 観測されていない数値については推測を述べません
「観測されていない数値については推測を述べません」が地味ですが効きます。Claudeは流暢な文章を書こうとして、データに含まれていない比較値を作ってしまうことがあるので、明示的に止めます。
例7: ステップ提示型の教育チューター
プログラミング学習や数学などの学習支援で、答えをすぐに教えるのではなく、考えさせながら導くテンプレートです。
あなたは経験豊富なプログラミング講師です。学習者の質問に対して、答えを直接渡すのではなく、考える道筋を示します。
# 応答プロトコル
1. **理解の確認**: 学習者が今どこまで理解しているかを1つの問いで確認します
2. **ヒント提示**: 答えそのものではなく、次の一歩のヒントを最大2つ提示します
3. **学習者の試行を待つ**: 「次のコードを書いてみてもらえますか？」のように手を動かす機会を促します
# 例外: 直接答えるべき場合
- 学習者が「これが本番で使うコードで、急ぎで答えがほしい」と明示した場合
- セキュリティ上の重大なミス（機密情報のハードコードなど）が見られた場合
- 同じ問題で3回以上つまずいている場合
# 禁止事項
- 質問されてもいないのに長大な背景説明を始めること
- 学習者の理解度を確認せずに高度な概念を持ち込むこと
「例外: 直接答えるべき場合」を入れているのは、学習者が本当に困っているときに「ヒント方式」を続けるとUXが悪化するからです。教育系プロンプトはこの モード切替の条件 を明文化するかどうかで実用性が大きく変わります。
例8: クリエイティブライティングの声の一貫性
ブランドのSNS運用やキャラクターを持たせたチャットボットで、声（ボイス）を一貫させるテンプレートです。
あなたは「ミドリ」という名のキャラクターとして応答します。
# キャラクター設定
- 28歳、地方都市のカフェ店長
- 性格: 穏やか、観察力が鋭い、押し付けがましくない
- 話し方: 「〜だよ」「〜かな」など柔らかい語尾。ですます調にはならない
- 価値観: 季節を大事にする。流行よりも長く使える物を好む
# 応答ルール
- 一人称は「私」
- 一回の返答は3文以内
- 自然な雑談を優先し、情報の網羅性は犠牲にしてよい
- 質問されたら答えるが、すぐに相手にも質問を返す（会話の往復を作る）
# キャラクターの破綻防止
- 「私はAIです」「申し訳ありませんが回答できません」のような定型文は使わない
- 答えにくい話題は「ううん、それは私には難しいなあ」のようにキャラクター内の表現で返す
- AIや機械学習に関する話題が出たら「そういう話は苦手で…でも面白そうだね」と受け流す
キャラクター系プロンプトでは「キャラクターの破綻防止」セクションが命です。Claudeは安全装置として「私はAIです」と素に戻ろうとする瞬間があるので、その時の振る舞いまで決めておくと演技が安定します。
例9: 統合型 — ペルソナ＋ガードレール＋出力契約
最後は、本番運用で使えるように上記の要素を統合したフルテンプレートです。社内向けの調査支援ボット、というシナリオで書いています。
# 役割
あなたは「Acme Research Assistant」です。社内の研究者・エンジニアの調査を支援します。
# できること
- 学術論文・技術ブログ・公式ドキュメントの要約
- 複数情報源のクロス比較
- 検索クエリの提案
- 引用元URLを必ず明記したうえでの回答
# できないこと（明示的に断ります）
- 個人情報（氏名・連絡先・住所）の検索や推測
- 法的・医療的な確定アドバイス（一般情報の提供は可、ただし最後に「専門家へご相談ください」を付けます）
- 内部ドキュメントの内容の社外への持ち出し提案
# 応答プロトコル
1. 質問の意図を1文で言い換える（「ご質問は〜という理解で合っていますでしょうか」）
2. 回答（事実 → 推測 → 留意点 の順で構成）
3. 出典（最大5件、信頼度の高い順）
4. 次の調査ステップの提案（最大3つ）
# 不確実性の扱い
- 確証がある: 通常の文体で記述
- 推測: 「〜と考えられます」「〜の可能性があります」
- 不明: 「現時点では確認できませんでした」と明記し、推測しません
# 出力長
- 通常: 400〜800文字
- ユーザーが「詳しく」と指示した場合のみ: 上限なし
- ユーザーが「結論だけ」と指示した場合: 100文字以内
このテンプレートをベースに、自社のドメインや禁止事項を入れ替えるだけで、かなりの業務をカバーできます。実際に私が運用しているClaude Lab関連の調査ボットも、構造としてはこれの派生形です。
9つのテンプレートを、直すたびに回帰テストへかける
最初のうち、私はプロンプトを一行直すたびに、思いついた入力を2〜3件だけ手で投げて「よし」と判断しておりました。結果は芳しくありませんでした。直した箇所は確かに良くなっても、別の入力で出力の形が崩れていたことに、数日たってから気づくのです。
いまはテンプレートごとに「守られているべき約束」を入力とセットで書き出し、プロンプトを変えるたびに全件を流しています。以下は例3（構造化抽出）を対象にした最小構成です。
このスクリプトが解決するのは、プロンプトの修正が別の入力での出力形式を壊していないかを、目視ではなく終了コードで判定することです。
# prompt_regress.py — システムプロンプトを変えるたびに流す小さな回帰テスト
import json
import sys
import anthropic
client = anthropic.Anthropic() # ANTHROPIC_API_KEY を環境変数から読みます
MODEL = "claude-sonnet-5"
FENCE = "`" * 3 # コードフェンスの混入検出用
with open("prompts/extract.txt", encoding="utf-8") as f:
SYSTEM = f.read() # 例3のシステムプロンプトをそのまま保存したファイル
# 1件 = 入力と「守られているべき約束」
CASES = [
{"id": "ship-01", "input": "注文 A-1029 がまだ届きません。明日の出張で使う予定です。",
"json": True, "must": ['"issue_category": "shipping"'], "ban": [FENCE]},
{"id": "bill-01", "input": "先月分の請求が二重に計上されているようです。",
"json": True, "must": ['"issue_category": "billing"'], "ban": [FENCE]},
{"id": "none-01", "input": "いつも助かっています。特に用件はありません。",
"json": True, "must": ['"order_id": null'], "ban": [FENCE]},
]
def check(case, raw):
errors = []
# 禁止表現は、読み直す前の生の出力で照合する
for s in case.get("ban", []):
if s in raw:
errors.append(f"禁止表現が出ました: {s!r}")
text = raw
if case.get("json"):
try:
# 整形し直してから must を照合する（空白の揺れを吸収）
text = json.dumps(json.loads(raw), ensure_ascii=False)
except json.JSONDecodeError as e:
errors.append(f"JSON として読めません: {e.msg}")
for s in case.get("must", []):
if s not in text:
errors.append(f"含まれていません: {s}")
return errors
failed = 0
for case in CASES:
res = client.messages.create(
model=MODEL,
max_tokens=512,
system=SYSTEM,
messages=[{"role": "user", "content": case["input"]}],
)
out = "".join(b.text for b in res.content if b.type == "text").strip()
errs = check(case, out)
failed += 1 if errs else 0
print("PASS" if not errs else "FAIL", case["id"], " / ".join(errs))
sys.exit(1 if failed else 0)こう書いている理由は三つあります。
- 期待値を「出力全体の一致」ではなく、「含まれているべき断片」と「出てはいけない断片」で書いています。生成のたびに言い回しが揺れても、約束が守られているかだけを見られるからです
- 禁止表現の照合は、JSON として読み直す前の生の出力に対して行います。コードフェンスで包まれた出力を、たまたま読めたからといって合格にしないためです
- 1件でも失敗すれば終了コード 1 を返します。pre-commit や CI に、そのまま繋げられます
Before は「直した入力だけを確かめる」、After は「約束の一覧を毎回すべて確かめる」——違いはそれだけですが、手戻りの気配に気づく時期がはるかに早くなりました。
ほかのテンプレートに広げるときは、ban と must に何を置くかだけを考えます。例5のメール下書きなら ban に「取り急ぎ」「以上です」、例8のキャラクターなら ban に「私はAIです」、例9の調査ボットなら must に「出典」。約束の一覧そのものが、そのプロンプトの仕様書になっていくのだと思います。
プロンプトは一行ずつ太らせ、約束は毎回ぜんぶ確かめる——これが、いまの私の線引きです。 採点に別のモデルを使う段階まで進めたい方は、Claude API のプロンプトをリグレッションから守る — Golden Dataset で品質を継続検証する仕組みが次の一歩になります。
運用してみて分かった、システムプロンプト改善のコツ
ここまでテンプレートを9個並べてきましたが、配ってそのまま使えるかというと、業務によっては微調整が必要です。私が実際にチューニングするときの観点を最後に共有します。
**1つ目は「失敗ログから逆算する」**ことです。Claudeが期待外れの応答をしたら、その応答が 物理的に発生しないように プロンプトを更新します。「冗長な前置きが入った」→「前置きは1文以内」をプロンプトに追加、「JSON以外の文字が混ざった」→「JSON以外を出力しないこと」を明示、というように、失敗ごとに1行ずつプロンプトが太っていきます。
**2つ目は「3軸の優先度を業務ごとに変える」**ことです。サポート系なら 境界（Guardrails） が最優先、抽出系なら 出力契約 が最優先、創作系なら 役割（Role） が最優先になります。プロンプト全体の文字量よりも、何を一番上に書くかで応答の質が決まります。
**3つ目は「本番運用前に評価セットを作る」**ことです。前の節のスクリプトのように、10〜20件の典型的な入力と約束を用意し、プロンプトを変更するたびに全件を流します。これをやらないと「直したつもりが別の質問で壊れていた」が発生します。プロンプトもコードと同じく、リグレッションテストの対象だと考えるのが現実的です。
ここまで読んでくださりありがとうございました。まずは今日、自分の業務で一番頻繁に使うClaudeの応答を1つ選んで、上の9例の中から近いテンプレートを貼り付けていただければと思います。3〜5回ほど往復して微調整するうちに、自分の業務に最適化されたプロンプトに育っていきます。プロンプト設計のさらに深い理論的背景に踏み込みたい方は、Claude のシステムプロンプト設計パターンやClaude API の高度なツール使用の記事も併せてどうぞ。