メインコンテンツまでスキップ

モデル間でプロンプトを移植する

中級

あるモデルで見事に動くプロンプトがある。今度はそれを別のモデルで動かす必要がある — クライアントが GPT を使っている、コスト目標のためにオープンモデルへ移らざるを得ない、あるいは Claude と Gemini を A/B テストしている、といった具合だ。朗報は、どのプロバイダーの公式ドキュメントでも繰り返し述べられているとおり、良いプロンプトの骨格は普遍的だということ。変わるのは、表層的な慣習という薄い一層だけだ。このページではその二つを切り分け、書き直さずにプロンプトを移せるようにし、さらに繰り返し使える移行ワークフローと移植可能なテンプレートを提供する。

What you'll learn
  • プロンプトのどの部分が Claude、GPT、Gemini、オープンモデルの間できれいに引き継げるかを理解する
  • どの部分がモデルごとの調整を必要とするか — そしてその理由を理解する
  • 試行錯誤の書き直しではなく、繰り返し使える移行ワークフローを実行する
  • ターゲットごとに特化できる、移植可能でモデル中立なプロンプトテンプレートを保持する

メンタルモデル：構造は引き継げる、慣習は引き継げない​

どんなプロンプトも二つの層として捉えよう。

  • 推論層（reasoning layer） — 何を尋ねているか、どんなコンテキストを与えるか、例、求める出力。これはコミュニケーションに関わるもので、モデルをまたいでもほぼそのまま引き継げる。
  • 慣習層（convention layer） — この特定のモデルが、そのコミュニケーションをどう包装してほしいか。システムプロンプトをどこに置きどれだけ強く従うか、XML を好むか Markdown を好むか、正確なツール呼び出しスキーマ、デフォルトのおしゃべりさやリフューザルの姿勢、どの生成パラメータが存在するか。

プロンプトの移植は、推論層の書き直しになることはほとんどない。それは慣習層の再フィッティングだ。この区別を正しく押さえれば、移行は不可解なものではなく機械的なものになる。（そもそもプロバイダー中立にターゲットを選ぶ方法については、モデルを選ぶを参照。）

きれいに引き継げるもの​

これらは Claude、GPT、Gemini、主要なオープンモデルのいずれでも同様に成り立つ — 各プロバイダーのベストプラクティスドキュメントが独立にこれらを推奨している。

  • 明確な役割 + タスク + 明示的な指示。 「あなたは X です。あなたの仕事は Y です。次のルールに従ってください。」どのプロバイダーもペルソナ／役割の構造を文書化しており、曖昧なものより具体的で明確な指示を好む。
  • 具体的な例（few-shot）。 入力→出力のペアを 2〜5 個示すと、説明するよりも確実にパターンを教えられる。主要な三つのプロバイダーはいずれも明示的に few-shot の例を推奨しており、Gemini のドキュメントはほぼ常に含めるべきだとまで言っている。
  • 指定された出力フォーマット。 「列 X、Y、Z を持つ Markdown テーブルを返す」あるいは「JSON のみ、散文なし」はどこでも機能する。厳格モードの仕組みが異なっても（後述）、指示自体は引き継げる。
  • 思考連鎖（chain-of-thought）／「答える前に推論する」。 難しいタスクで段階的な推論を求めると、モデルをまたいで結果が改善する。モデルごとに当てはまる注意点が一つある。専用の推論／思考モデルはこれを内部で行うことが多いため、明示的な「ステップごとに考えよ」は冗長、あるいは逆効果になり得る — 調整リストを参照。
  • グラウンディング／RAG。 「以下のコンテキストのみを使うこと。答えがそこになければ、わからないと言うこと。」取得したコンテキストを与え、モデルをそれに制約するという規律は普遍的だ — どのプロバイダーも、ハルシネーションを減らす方法として RAG 風のグラウンディングを文書化している。
  • 長いコンテキストを先に、質問を最後に。 文書／データを先頭に、指示を末尾に置く。この順序はモデルをまたいで有効で、Gemini のガイダンスでも明示的に言及されている。

プロンプティングの基礎を身につけていれば、移植可能な 80% はすでに手中にある。

モデルごとに調整が必要なもの​

これが慣習層 — 本当に違う部分だ。移行するときはこれらを再フィッティングする。

観点モデル間で何が変わるか何をすべきか
システムプロンプトの扱いと重みどのモデルにもシステム／開発者メッセージはあるが、それがユーザーのターンをどれだけ強く上書きするかは異なる。専用の開発者／システム役割をユーザー指示より上に重み付けするモデルもあれば、その境界が曖昧なモデルもある。システムプロンプトが同じ強さで従われると仮定しないこと。制約が実際に保たれるか再テストし、すり抜けるなら重要なルールをより上位へ昇格させる。
XML 対 Markdown 対デリミタClaude は指示／コンテキスト／例を分けるのに XML タグを特によく解析する。GPT と Gemini も XML を受け付けるが、Markdown の見出しやデリミタにも依拠する。何らかの明示的な構造は保ちつつ、その流儀をターゲットの好みに合わせて入れ替える。プロンプトのフォーマットを望む出力に合わせると、出力スタイルも誘導できる。
ツール／関数呼び出しの JSON 形状ループ（ツールを宣言 → モデルが呼び出しを要求 → あなたが実行 → 結果を返す）はどこでも同一だが、ワイヤフォーマットは違う — フィールド名、呼び出し／結果がメッセージリストにどう収まるか、厳格モードのオプションが異なる。生のツール JSON をプロバイダー間でコピーしてはいけない。ターゲットのスキーマに再マッピングする。ツール利用を参照。
デフォルトの冗長性新しいモデルはデフォルトで簡潔になる傾向があり、詳細はこちらが尋ねることを期待する。古いモデルはよりおしゃべりだった。プロンプトを移植して答えが短く／長くなったら、プロンプトのせいにする前に冗長性を明示的に設定する。
リフューザル／安全性の姿勢どのモデルも、際どい要求を拒否したり言葉を濁したりする独自の閾値を持ち、これらはリリースのたびに再チューニングされる。移植後にエッジケースを再テストする。あるモデルでは一度もリフューザルを引き起こさなかったプロンプトでも、別のモデルでは再フレーミングが必要になることがある。
回答のプレフィルフォーマットを強制するためにアシスタントの口に言葉を入れるのは、Claude 時代の古典的なレバーだ — しかし新しい Claude モデル（4.6 以降）はプレフィルされた最終アシスタントターンを拒否し、他所でのサポートもまったくまちまちだ。プレフィルを、直接の指示（「前置きなしで応答せよ」）、出力スキーマ、またはツール呼び出しに置き換える。
ストップシーケンスと max tokensすべてが長さの上限を公開し、ほとんどがストップシーケンスを公開するが、パラメータ名、デフォルト、上限が異なる — そして一部の思考バジェットのつまみは、effort／max_tokens を優先して非推奨化されつつある。ターゲット側でパラメータ名と上限を再確認すること。古い値がそのまま移植できると仮定しない。

移行ワークフロー​

移植は、当てずっぽうの書き直しではなく、短く規律のあるループとして扱う。

Guided walkthrough1 of 6
  1. 既存のプロンプトを読み、頭の中で分割する。推論層（役割、タスク、コンテキスト、例、出力仕様）対 慣習層（XML/Markdown の選択、プレフィル、ツール JSON、パラメータ）。前者は保ち、後者を再フィッティングする。

:::tip ゼロから書き直さない 役割、タスク、例を作り直していると気づいたら、止まること — それは移植可能な層だ。きれいな移植が変えるのは包装であって、意味ではない。 :::

移植可能なプロンプトテンプレート​

プロンプトをモデル中立な形で書き、ターゲットごとに慣習層だけを特化する。この核は、軽く普遍的に理解される構造を使う（Markdown としてきれいに読め、タグは Claude 向けに XML へ容易に変換できる）。

モデル中立なプロンプトの核 — ターゲットごとに慣習層を特化する

# ROLE
You are {role}.

# TASK
{One clear sentence describing the single goal.}

# RULES
- Use ONLY the information in CONTEXT below. If the answer is not there, say "I don't know" — do not guess.
- Be concise. Respond directly, with no preamble like "Here is..." or "Based on...".
- {Any other hard constraints.}

# OUTPUT FORMAT
{Exact format — e.g. "A Markdown table with columns Name, Value, Source." or "JSON only matching this schema: {...}".}

# EXAMPLES
Input: {example input 1}
Output: {ideal output 1}

Input: {example input 2}
Output: {ideal output 2}

# CONTEXT
{Retrieved documents / data go here — long content first.}

# REQUEST
{The actual user question, last.}

その上に重ねる、ターゲットごとの微調整。

  • Claude — セクションマーカーを XML タグ（<role>、<rules>、<context>、<request>）に移す。Claude はそれらを特にきれいに解析する。現行モデルではプレフィルされたアシスタントターンを使わず、「前置きなし」ルールやツール／スキーマに頼る。
  • GPT — RULES をシステム／開発者メッセージに置いてより重みを持たせる。Markdown の見出しで問題ない。スキーマを散文で説明するだけでなく、構造化出力／厳格 JSON モードを使う。
  • Gemini — ROLE + RULES + OUTPUT FORMAT を system-instruction フィールド経由で渡し、プロンプトを直接的に保つ（新しい Gemini は冗長なプロンプトを過剰解釈し得る）。そして CONTEXT を先に、REQUEST を最後に保つ。
  • オープンモデル（Llama／Mistral／Qwen など） — モデルが公開しているチャットテンプレートに正確に従い、明示的な few-shot の例とフォーマット制約により強く依拠する。指示追従性は通常、フロンティアのクローズドモデルほど頑健ではないからだ。

クイックチェック​

自分を試す

0/3
  1. 動作する Claude のプロンプトを GPT へ移そうとしている。本質的に変えずに済むと期待すべき部分はどれか？
  2. 移植したプロンプトが、新しいモデルで突然はるかに短い答えを出すようになった。最も可能性の高い原因は？
  3. プロバイダー間で移植するとき、ツール／関数呼び出しについて正しいのはどれか？
移植チートシート
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 6
Key takeaways
  • プロンプトは推論層（引き継げる）と慣習層（モデルごとに再フィッティングする）からなる — 後者を移植し、前者は保つ。
  • 明確な役割／タスク／指示、few-shot の例、出力フォーマット仕様、思考連鎖、RAG グラウンディングは、Claude、GPT、Gemini、オープンモデルをまたいで引き継げる。
  • システムプロンプトの重み、XML 対 Markdown の構造、ツール呼び出しの JSON、デフォルトの冗長性、リフューザルの姿勢、プレフィル、長さパラメータをターゲットごとに調整する。
  • 実入力で小さな評価セットをビフォー／アフターに実行し、推論に手を付ける前に慣習を直す。
  • モデル中立なテンプレートとターゲットごとの微調整をバージョン管理下に保ち、切り替えを安価にする。
  • 特定の挙動はリリースのたびに変動する — パラメータと上限は各プロバイダーの現行ドキュメントで確認し、決して記憶から答えないこと。

ソースと参考資料​

次へ​