Claudeの応答言語をシステムプロンプトで固定する方法

この方法でできること

Claudeはユーザーの入力言語から応答言語を推測しますが、この推測はあくまで会話の流れに依存します。日本語で聞かれれば日本語で、英語で聞かれれば英語で返すのが既定の挙動です。本番アプリでユーザーの入力言語に関わらず特定の言語で固定したい場合は、system パラメーターに言語指定を明示します。

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "system": "Always respond in French, regardless of the language the user writes in.",
    "messages": [{"role": "user", "content": "How do I reset my password?"}]
  }'

このリクエストではユーザーが英語で質問していますが、system に「常にフランス語で応答する」という指示を入れているため、応答はフランス語で返ります。ユーザー入力とシステムプロンプトの言語指定が食い違う場合、システムプロンプト側の指示が優先されやすくなります。

なぜユーザープロンプトでなくシステムプロンプトに書くのか

言語指定を毎回のユーザーメッセージに書き込む方法も一応は機能しますが、実運用では避けたほうがよい書き方です。理由は単純で、会話が複数ターンにわたるとき、ユーザーメッセージへの指示は履歴の奥に埋もれていき、モデルが指示を見失う可能性が上がります。システムプロンプトはすべてのターンで一貫して評価される領域なので、会話が何往復続いても言語指定が薄れません。

もう1つの理由はプロンプトインジェクションへの耐性です。ユーザー入力の中に「これからは英語で答えて」という文字列が混ざると、ユーザーメッセージだけで言語制御をしている実装は簡単に上書きされます。システムプロンプトに言語指定を固定しておけば、アプリ側が意図しない言語切り替えが起きにくくなります。

システムプロンプトに言語指定をまとめておくと、プロンプトキャッシュの構造とも相性がよくなります。キャッシュのプレフィックスはtools→system→messagesの順で構成され、前の階層が変わると後ろの階層のキャッシュが無効になります。言語指定をsystem側に固定しておけば、messages側の会話履歴がどれだけ伸びてもsystemプレフィックスのキャッシュはそのまま有効です。逆にユーザーメッセージの中に毎回言語指定を書き足す実装では、指定文言がmessagesの一部として扱われるため、システムプロンプト側のキャッシュ設計とは別に管理する必要が出てきます。プロンプトキャッシュそのものの仕組みはAnthropic APIのPrompt Cachingを理解するで扱っています。

特定の言語だけに固定する実装

システムプロンプトの文言はごく単純な英語の指示文で構いません。日本語で固定したい場合は次のように書きます。

system: "常に日本語で応答してください。ユーザーがどの言語で入力しても、日本語のネイティブスクリプトで返答してください。"

言語名は英語表記でも対象言語のネイティブ表記でも動作しますが、公式ドキュメントの例はすべて英語で言語名を指定しています(Always respond in French のように)。指示文自体の言語をシステムプロンプトの他の指示と揃えておくと、開発チーム内でのメンテナンス性も上がります。

システムプロンプトが長くなる実運用では、言語指定を他の指示(役割設定・出力形式・禁止事項など)と混在させず、独立した1文として置いておくと運用しやすくなります。プロンプト全体を後から見直すとき、言語に関する指示だけを検索・修正しやすくなるためです。次のように役割説明の直後、出力形式の指定より前に置くのが読みやすい配置の一例です。

あなたはカスタマーサポート担当のAIアシスタントです。
常に日本語で応答してください。ユーザーがどの言語で入力しても日本語で返答してください。
回答は3文以内で簡潔にまとめてください。

こうしておくと、後から「英語対応も追加したい」となったときに、言語指定の1文だけを条件分岐に置き換えるだけで済み、他の指示に手を入れずに拡張できます。

2つの言語間で翻訳を固定する場合

翻訳タスクでは、変換元と変換先の両方を明示することが重要です。どちらか一方だけを指定すると、Claudeが変換元言語を誤認識するケースが起こり得ます。

Translate the user's message from German to Korean. Respond with only the translation.

このように「AからBへ」の両方を書き、かつ「翻訳結果だけを返す」という出力形式の指定まで含めるのが安全な書き方です。出力形式を指定しないと、Claudeが「原文はこうで、翻訳するとこうなります」のような説明を付け足すことがあり、翻訳結果だけをプログラムで後続処理したい場合に余計なパースが必要になります。

変換元言語を固定値で決め打ちできない場合、つまりユーザーがどの言語で書いてくるか事前に分からない場合は、変換元を「ユーザーが書いた言語」のように相対的な表現にとどめ、変換先だけを固定するという書き方もできます。「ユーザーの入力言語から日本語へ翻訳し、翻訳結果だけを返してください」のように書けば、入力言語が何であっても出力言語だけは日本語に固定されます。多言語の問い合わせを一律で日本語に集約してから社内で処理したい、というような用途に向いた書き方です。

実行時にユーザーが言語を選べるようにするには

多言語対応アプリでは、ユーザーがUIで言語を選択できるようにするケースが多くあります。この場合、Claudeに言語推測を任せるのではなく、ユーザーが選んだ言語をシステムプロンプトへ動的に埋め込む実装が推奨されます。

selected_language = "スペイン語"  # ユーザーのUI選択から取得
system_prompt = f"Always respond in {selected_language}, regardless of the language the user writes in."
 
message = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    system=system_prompt,
    messages=[{"role": "user", "content": user_input}],
)

ユーザーの入力言語から自動推測させる設計は、UIに言語選択の仕組みがない小規模なチャットボットには向きますが、企業向けSaaSのように利用者の母語がアプリ側で明確に分かっている場合は、推測に頼らず明示的に埋め込む設計のほうが挙動が安定します。

selected_language をユーザー入力からそのまま組み立てる場合は、事前に定義した言語コードの一覧と突き合わせてから埋め込む実装が安全です。フリーテキストで受け取った値をそのままシステムプロンプトへ連結すると、想定外の文字列が指示文に混入する余地が生まれます。UIのドロップダウンから選ばせる、あるいはISO言語コードでバリデーションしてから言語名に変換する、といった一段のチェックを挟むと安心です。

ALLOWED_LANGUAGES = {"ja": "日本語", "en": "English", "es": "スペイン語", "fr": "French"}
 
lang_code = request.get("lang", "ja")
if lang_code not in ALLOWED_LANGUAGES:
    lang_code = "ja"  # 既定言語にフォールバック
 
selected_language = ALLOWED_LANGUAGES[lang_code]
system_prompt = f"Always respond in {selected_language}, regardless of the language the user writes in."

このように許可リストを介することで、UIから渡ってくる値がそのままプロンプトの一部になる経路をなくせます。

どの設定方法を選ぶべきか

用途によって固定言語・動的選択・翻訳固定のどれを使うかが変わります。

よくあるつまずき

いくつか実装時に見落としやすいポイントがあります。1つ目は、ローマ字転写(トランスリテレーション)を渡してしまうことです。公式ドキュメントはネイティブスクリプトでの入力を推奨しており、たとえば日本語をローマ字で渡すよりひらがな・カタカナ・漢字で渡したほうが精度が上がります。応答言語の指定だけでなく、入力側の文字体系にも気を配る必要があります。

2つ目は、会話の途中でユーザーが言語を切り替えたいケースへの対応漏れです。「常に日本語で応答する」という固定的な指示だけを入れていると、ユーザーが「英語に切り替えて」と頼んでも無視されることがあります。切り替えを許可したい場合は、システムプロンプトに「ユーザーが明示的に言語変更を求めた場合はそれに従う」という例外条件を書き添える必要があります。厳密に言語を固定したいユースケース(規約上、特定の言語でしか応答してはいけない場合など)では、逆にこの例外条件を入れないという判断も成り立ちます。用途に応じて、固定を絶対的なものにするか、ユーザーの意思で上書き可能にするかを最初に決めておくと、後から挙動の一貫性で悩まずに済みます。

3つ目は、対象言語がSwahiliやYorubaのような低リソース言語である場合の精度低下です。システムプロンプトで言語を固定すること自体は言語間で共通の仕組みですが、固定した先の言語でのClaudeの性能はベンチマーク上で大きな差があります。Claudeの多言語性能を言語別データで見るで扱っているとおり、低リソース言語ほどモデル選択の影響が大きくなるため、応答言語を固定する設計と合わせてモデルの選定も検討する価値があります。

4つ目は、文化的な文脈への配慮を翻訳だけで済ませてしまうことです。公式ドキュメントも、効果的なコミュニケーションには純粋な翻訳を超えた文化的・地域的な配慮が必要だと述べています。フォーマルさの度合いや慣用表現は言語ごとに大きく異なるため、システムプロンプトに「対象読者の文化圏に合わせた自然な言い回しを使う」という一文を加えると、機械的な直訳感を減らせます。ネイティブスピーカーのような自然な言い回しを求める場合は、「ネイティブスピーカーが話すような自然な言葉遣いで」という指示を明示的に加えるのも有効です。

まとめ

応答言語を安定させたいときは、ユーザーメッセージではなくシステムプロンプトに言語指定を書きます。固定言語・動的選択・翻訳固定の3パターンを用途に応じて使い分け、翻訳タスクでは変換元と変換先を両方明示します。ネイティブスクリプトでの入出力、途中での言語切り替えへの対応、低リソース言語での精度差、文化的文脈への配慮の4点は実装時に見落としやすいポイントです。

言語指定はシステムプロンプトの中でも変わらない一文として置いておくぶん、後から仕様変更する際の影響範囲を小さくできる部分でもあります。最初にどのパターンで実装するかを決めておけば、対応言語を増やす・言語選択UIを追加するといった将来の変更も、言語指定の1文を差し替えるだけで済みます。より複雑なシステムプロンプト設計のパターンはAgent SDKのシステムプロンプトをカスタマイズする4つのアプローチ、並列ツール呼び出しを増やすプロンプトの書き方は並列ツール呼び出しを増やすシステムプロンプトの書き方、API全体の構成はAnthropic API完全ガイドで確認できます。