Skip to Content
Docs03. 実装モデル間の違いと移行(横断比較)
中級prompt-designmodel-selection更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

モデル間の違いと移行(横断比較)

この記事の目的

1 つのプロンプトを複数モデルで使う、あるいはモデルを乗り換えるときに、何が壊れ、何を書き直すかを判断できるようになります。Claude / OpenAI / Gemini の各特化ガイドが個別の作法を扱うのに対し、本記事は3 社の差分だけを横並びにし、移行とマルチプロバイダー設計の勘所を示します。

本記事は鮮度管理型です。 モデル世代・機能名は変化が速いため、本文冒頭の最終確認日と各特化ガイド・公式ページを必ず確認してください。

対象読者

  • 複数のモデルプロバイダーを併用・切り替えする設計をしているエンジニア
  • モデルを乗り換える際に、プロンプトの何を作り直すべきか見極めたいエンジニア

前提知識

本文

最終確認日: 2026-09-10 — 本記事の各社仕様は、この日付時点の 3 つの特化ガイド(それぞれの一次情報発信源そのものの情報(論文の原典・公式ドキュメント・公式ブログ・規格本文・法令)。解説・まとめ(二次情報)と区別し、根拠は一次情報に置くのが情報リテラシーの基本。二次情報は「存在を知る」までに使い、一次まで遡って確かめる。に基づく)を統合したものです。個別仕様は各特化ガイドと公式ページを正とします。

概要: 何が普遍で、何がモデル依存か

移行で書き直す量を最小化する鍵は、普遍的な部分とモデル依存の部分を切り分けることです。

層普遍性正本
生成の原理(なぜ効くか)普遍(モデルに依存しない)10 章の基礎
汎用技法(明確な指示・区切り・例示・分解)ほぼ普遍(効き方の強弱は差あり)基礎技法 / 上級パターン
モデル別の具体(記法・パラメータ・API)モデル依存(本記事の対象)Claude / OpenAI / Gemini の各ガイド
移行の運用(回帰評価・段階リリース)プロセスは普遍バージョニングとモデル更新追従

普遍的な部分(役割を与える・指示とデータを区切る・例で仕様を示す)は乗り換えても生き残ります。壊れるのは主に記法の癖・制御パラメータ・API の非互換です。以下はその差分に絞ります。

相違の構造マップ(3 社横並び)

本記事の核です。プロンプト設計に効く差分を並べます(2026-09-10 確認。詳細と根拠は各特化ガイド)。

観点ClaudeOpenAI(GPT 系)Gemini
構造化記法XML タグが第一選択Markdown 見出し + XML タグ併用、既定は素のパラグラフ、入れ子箇条書きを避けるXML タグ・Markdown 見出しのどちらでも可
システム指示system(役割)。会話途中の system は一部モデルのみdeveloper > user の指示階層。推論モデル応答の前に中間の思考(推論トークン)を生成してから答える LLM。多段推論・検証可能な問題で精度が上がる一方、単純タスクでは遅く高くなる(overthinking)。思考量は努力パラメータ等で制御する。では developer が system を置換system_instruction / 冒頭に重要指示
例示(few-shot)Relevant / Diverse / Structured、<example> タグzero-shot を先に、必要なら few-shot常時推奨・全例でフォーマット統一
思考制御の名前アダプティブ思考 + effort(low〜max)reasoning effort(Astra は low〜max、none / minimal 非対応)+ reasoning.modethinking_level(3.8 Flash は low / medium / high、既定 medium)
出力形式の強制構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。(output_config.format)Structured Outputs(strict json_schema)JSON スキーマ強制
応答書き出し指定(prefill)最新世代で非対応(400)主要技法として非採用未確認(前提にしない)
サンプリング温度非既定値は最新世代で400Astra は temperature / top_p / top_logprobs 非対応。旧モデルの対応条件を流用しない既定 1.0 維持を強く推奨(下げると劣化)
長文の配置データを上・クエリを末尾、文書を XML 構造化RAG / file search + コンパクションコンテキスト上限に近づいた際に、会話履歴を要約・圧縮して容量を確保する仕組み。トリガ設計と「必ず残す情報」の定義が要で、決定の消失は議論のループを招く。資料を先・質問を末尾 + 転換句
強調表現の効き方CRITICAL / MUST は過剰反応ALWAYS / NEVER は不変条件だけに過度に丁寧・説得的な前置きは不要

特に壊れやすい差分

上の表のうち、共通プロンプトを流用したときに静かに品質を落とす危険が高いのは次の 3 つです。

  • 共通の temperature を送らない: Astra は temperature 自体が非対応、Claude の最新世代も非既定値を拒否します。Gemini 3.x は既定維持が推奨です。旧 GPT で有効だった設定を全モデルへ流すと、リクエスト拒否や品質劣化が起こります
  • 思考制御のパラメータが三者三様: effort / reasoning effort / thinking_level は名前も値域も既定も違います。しかも同一ベンダー内でも世代で既定が変わります(例: GPT の既定 effort、Gemini のモデル別既定)。ベンダー横断の共通値は作れません
  • 強制系ハックの効き方が逆転している: prefill・固定思考予算・強い強調(CRITICAL/ALWAYS)は、あるモデルでは非対応・別のモデルでは過剰反応になります。「効くから」で足したハックほど移行で壊れます

Fable 5.1 の tool_choice: any / tool は 400 で、strict tool use のスキーマ制約とは別です。思考履歴の前方を書き換えるクライアントや旧モデルへのフォールバックも検証します。Gemini の数値予算は一律廃止ではなく、2.5 Live の公式説明に残っています。詳細は各特化ガイドのモデル / API 別条件を参照してください。

移行チェックリスト

モデルを乗り換える(または新世代へ上げる)ときにプロンプト面で確認する項目です。移行の運用手順(段階リリース・ロールバック)は バージョニングとモデル更新追従 が正本です。

マルチプロバイダー設計

複数モデルを併用・切り替えする前提なら、プロンプトをモデル別に差し替えられる構造にします。

  • 共通の骨格 + モデル別の薄い差分: 「完全に共通のプロンプト」は各社の最大公約数に丸める分、どのモデルでも本来の性能を引き出せません。現実解は、タスクの意図・制約・例といった骨格を共通化し、記法(XML か Markdown か)・思考制御・出力形式といった差分だけをモデル別バリアントに切り出すことです
  • バリアントを資産として管理する: モデル別のプロンプト変種は、その場で分岐させず、テンプレートとして管理・バージョニングします(プロンプト資産の管理とバージョニング)
  • 差し替え層で吸収する: モデル選択とプロンプト差し替えを 1 つの層にまとめると、上位のアプリはモデルを意識せずに済みます(ゲートウェイ的な構成。マルチプロバイダーの運用基盤は LLM ゲートウェイ を参照してください)

「1 つのプロンプトで全社」を目指すより、「骨格は共通、差分は明示的に分ける」方が、品質と保守性の両立に現実的です。

実務での注意点

アンチパターン

  • 1 つのプロンプトを全モデルに無検証で流用する → 記法・パラメータ・API の差で、あるモデルだけ静かに品質が落ちる → 骨格を共通化し、差分をモデル別バリアントに分けて各モデルで回帰評価する
  • 「temperature=0」を全社共通で使う → Astra では非対応、Gemini 3.x では劣化・looping を招く → サンプリングの扱いをモデル別に分ける
  • 思考制御パラメータをベンダー横断で共通値にする → 名前も値域も既定も違い、成立しない → 移行先の名前・既定に明示的に置き換える
  • 前モデル向けの強調・prefill・固定思考予算を残して乗り換える → 非対応エラーか過剰反応を招く → 移行先の作法に合わせて外す・置き換える
  • トークナイザ差を無視して max_tokens・コストを流用する → 出力が途中で切れる・コスト見積りが外れる → 移行先で再計測する

チェックリスト

  • 普遍的な骨格とモデル依存の差分を切り分けている
  • 移行先で拒否される API 機能(prefill・固定思考予算・非既定サンプリング)を洗い出した
  • 思考制御を移行先の名前・既定に置き換えた
  • 出力形式を移行先の構造化出力機構に載せ替えた
  • 強調表現の効き方の差(過剰反応・非対応)を調整した
  • トークナイザ差で max_tokens・コスト・コンテキスト予算を再計算した
  • 言い換え・崩れた入力を含む回帰評価で移行前後を比較した
  • マルチプロバイダーではモデル別バリアントを資産として管理している

関連トピック

参考資料

  • 各社公式のプロンプトガイド・移行ガイドは、それぞれの特化ガイド(Claude / OpenAI / Gemini)の参考資料を参照してください(本記事はそれらの差分を統合したものです)。
  • Model migration guide(Anthropic)  — トークナイザ差など移行時の代表的な非互換の例(アクセス日: 2026-08-18)

TODO・未確認事項

なし(個別項目の未確認事項は各特化ガイドの TODO を参照)

変わりやすい項目(定点観測)

Gemini 特化プロンプティングガイド埋め込み(embeddings)の選定と運用