LLM プロバイダー互換性

​

プロバイダー検出

1. 明示的なプロバイダー（DB の ModelConfig.provider フィールドから）— 最優先。プロバイダーが URL 内の既知ドメインと一致する場合、api_base は返されません（LiteLLM はネイティブでルーティング）。それ以外の場合、api_base はリレー URL に設定されます。
2. KNOWN_DOMAINS に対するドメイン一致 — 公式 API エンドポイントはホスト名で認識されます。
3. PATH_PROVIDER_HINTS に対する URL パスヒント — UniAPI のようなリレープラットフォームで一般的です。パスに /claude または /anthropic が含まれている場合、アップストリームプロトコルを示します。
4. フォールバック — openai/ プレフィックス（ジェネリック OpenAI 互換）。

​

tool_choice — 4つのモード

​

tool_choiceが使用される場所

​

ReAct エンジン — tool_choice=“auto”

​

structured_llm_call — tool_choice=forced

​

構造化出力：4つの保証レベル

​

T1とT2は互換性がありません

​

T2 のコスト

• スキーマのサブセット。 OpenAI の strict mode では、すべてのオブジェクトに additionalProperties: false を指定し、すべてのプロパティを required に列挙する必要があります。オプショナル性は required から省略するのではなく、null とのユニオンとして表現します。ルートはオブジェクトでなければなりません。プロパティの総数とネストの深さには上限があります。手書きのスキーマの多くは、利用可能にする前に編集が必要です。
• 文法のコンパイル。 新しいスキーマを含む最初のリクエストでは、プロバイダー側で一度だけコンパイルレイテンシが発生します。安定したスキーマを再利用すればそのコストを分散できますが、リクエストごとに新しいスキーマを生成すると分散できません。
• 新たな失敗パターン。 モデルが回答しない場合、スキーマに沿ったオブジェクトではなく拒否を返すため、呼び出し側でそのための分岐が必要になります。

​

どのティアでも保証されないこと

​

FIM Oneの位置付け

1. チェーンには、スキーマによって制約されたフォールバック段階がない。 Level 1 が失敗した場合、次の段階は json_object であり、保証されるのはテキストをパースできることだけです。フィールドを引き続き強制する中間段階はありません。
2. Level 1 の保証は、その名前から受ける印象よりも弱い。 strict なしのネイティブ function calling は、2024年以前の非 strict 形式です。モデルは通常スキーマに従いますが、必須フィールドの省略、存在しないキーの追加、数値として宣言された値の文字列での返却を防ぐことはできません。
3. anthropic/ ルートでは、Level 2 は実質的には T3 ではない。 Anthropic Messages API には response_format がないため、LiteLLM は assistant prefill を注入して JSON mode をエミュレートします。これはプロンプト層の仕組みなので、実効的な保証は T4 と T3 の間に位置し、T3 と同等ではありません。以下で説明する Bedrock の prefill trap は、このエミュレーションが明示的に失敗するケースです。より見えにくい問題は、パラメーター名が示唆するような保証が、そもそも存在していなかったことです。
4. 結果が後からスキーマに対して検証されることはない。 jsonschema は依存関係に含まれていません。行われる検証はすべてオプションの parse_fn 内、呼び出し箇所ごとのものであり、その厳密さは呼び出し箇所によって異なります。
5. 失敗は表面化せず、吸収される。 ほぼすべての呼び出し元が default_value を渡すため、チェーンを使い切っても例外を送出せず、一見もっともらしいオブジェクトを返します。StructuredCallResult.level_used にはどの段階で値が生成されたかが記録されますが、これを読み取る呼び出し箇所はありません。また、default_value の経路では、実際には何も生成されていないチェーンについても plain_text と報告されます。

structured_llm_call: fn=classify_mode level=native_fc attempt=first calls=1
structured_llm_call: fn=annotate_tables level=json_mode attempt=reformat_retry calls=3

​

各ティアのプロバイダーサポート

​

Bedrock プリフィル トラップ

{"role": "assistant", "content": "{"}

ValidationException: This model does not support assistant message prefill.
The conversation must end with a user message.

1. モデルが anthropic/ プレフィックスで解決されている（ドメイン マッチまたは URL パス ヒント経由）。
2. response_format={"type":"json_object"} が渡されている（structured_llm_call の json_mode コード パス）。
3. 実際のバックエンドが AWS Bedrock である（プリフィルを拒否）。

​

修正: json_mode_enabled

• DB で構成されたモデル: Admin → Models → Advanced settings で切り替えます。このフラグは ModelProviderModel.json_mode_enabled に保存されます（デフォルトは TRUE）。
• ENV で構成されたモデル: 環境変数に LLM_JSON_MODE_ENABLED=false を設定します。
• 効果: 無効にすると、abilities["json_mode"] は False を返すため、response_format が渡されることはなく、prefill も行われません。その結果、Bedrock が動作します。フォールバックチェーンは native_fc → plain_text となり、失敗する json_mode 呼び出しを完全にスキップします。
• スキップによるコスト: システムプロンプトが JSON を要求し、最新のモデルでは extract_json() が自由形式のコンテンツを確実に解析できるため、実際にはモデルは引き続き有効な JSON を返します。失われるのは出力そのものではなく保証です。チェーンは T4 で終了し、結果を制約するのはプロンプトだけになります。anthropic/ ルートでは、この損失は見た目ほど大きくありません。エミュレートされた JSON モードも、デコーダーレベルでの保証ではなかったためです。

​

思考モデル + 強制 tool_choice

tool_choice 'specified' is incompatible with thinking enabled

​

修正: tool_choice_enabled

• DB設定モデル: Admin → Models → Advanced → “Native Function Calling” で切り替え。フラグは ModelProviderModel.tool_choice_enabled に保存されます (デフォルト TRUE)。
• ENV設定モデル: 環境で LLM_TOOL_CHOICE_ENABLED=false を設定。
• 効果: 無効にすると、abilities["tool_choice"] は False を返す → 劣化チェーンは Level 2 (json_mode) または Level 3 (plain_text) から開始され、native_fc は完全にスキップされます。これにより、互換性のないモデルの構造化呼び出しあたり約10秒のペナルティが排除されます。
• ReAct エージェントは影響を受けない: tool_choice_enabled は structured_llm_call での強制ツール選択のみを制御します。ReAct エンジンは tool_choice="auto" (モデルが自由に決定) を使用し、この設定に関係なくすべてのモデルで動作します。

​

プロバイダー機能マトリックス

​

表 A: プロトコルのルーティング

• store=false にすると、上流では会話がステートレスに保たれ、include=["reasoning.encrypted_content"] を指定すると、暗号化されたペイロードが返されるよう要求できます。include がない場合、推論アイテムは空で返され、再生しても何も起きないままになります。
• 再生する推論アイテムでは、サーバー側の id を削除する必要があります。store=false では上流に何も保存されないため、id をそのまま返すと Item with id 'rs_...' not found. Items are not persisted when 'store' is set to false というエラーになります。encrypted_content のデータ自体に状態が含まれているため、id を削除しても問題ありません（sanitize_reasoning_item）。

​

Table B: 競合と回避策

​

Table C: 思考プロトコル

​

Relay/proxy gotchas

​

モデルごとの推奨設定

# Disable native_fc globally (for thinking-model-only deployments)
LLM_TOOL_CHOICE_ENABLED=false

# Disable json_mode globally (for Bedrock relay deployments)
LLM_JSON_MODE_ENABLED=false

​

推理努力度と思考設定

1. 温度は自動的に処理されます。 思考がアクティブなanthropic/ルートでは、_build_request_kwargsはtemperatureを1.0に固定します。これはBedrockが要求する値です。サンプリングパラメータを完全に拒否するモデル（Opus 4.7および4.8、Fable 5、Mythos 5）は、思考の有無にかかわらず、リクエストからtemperatureが削除されます。このためにLLM_TEMPERATURE=1を手動で設定しないでください。
2. GPT-5.xは可能な限りツールと推理を一緒に保ちます。 FIM Oneは、GPT-5.xの場合、Responses ブリッジを最初にプローブします。これが2つが組み合わさる唯一のサーフェスだからです。使用可能な/v1/responsesルートがないエンドポイントはチャット補完にフォールバックし、判定はエンドポイントごとにキャッシュされます。そのパスでtoolsを含むリクエストは、明示的なreasoning_effortとしてnoneを送信します。フィールドを省略することは同等ではありません。サーバーのデフォルトがnoneではないからです。

​

構造化出力の防御的パース

1. 配列の代わりに単一オブジェクト。 一部のモデルは{"steps": [{"id": "1", "task": "..."}]}（配列）の代わりに{"steps": {"id": "1", "task": "..."}}（単一ステップオブジェクト）を返します。パーサーはidまたはtaskキーをチェックしてこれを検出し、オブジェクトをリストでラップします。
2. ダブルエンコードされたJSON文字列。 構造化出力がスキーマ強制を欠くjson_modeにフォールバックする場合、一部のプロバイダーはsteps値をネイティブ配列ではなくJSON文字列として返します。例えば{"steps": "[{\"id\": \"1\", ...}]"}です。この文字列には、標準的なjson.loadsを破壊するモデルのフォーマットからのリテラル改行も含まれる場合があります。パーサーはextract_json_value()（_repair_json_stringsを含む）を使用して以下を処理します:
   • JSON文字列値内のリテラル改行
   • 無効なエスケープシーケンス（LaTeXまたはコードコンテンツで一般的）
   • 互換性レイヤーからの他のシリアライゼーション特性
3. stepsラッパーの欠落。 モデルはstepsラッパーキーなしでトップレベルオブジェクトとして単一ステップを返す場合があります。パーサーはルートレベルでidとtaskを検出し、それに応じてラップします。

​

プロンプトキャッシング（クロスプロバイダー）

​

アーキテクチャ

• PromptSection — 静的な content: str または動的な content: Callable を持つ名前付きフラグメント
• PromptRegistry — メモ化されたストア（静的セクションは1回レンダリングされ、動的セクションはコール毎に再レンダリングされます）
• DYNAMIC_BOUNDARY — レジストリが最後の静的セクションと最初の動的セクションの間に挿入するセンチネルマーカー。呼び出し元がキャッシュ破断点でレンダリングされた提示词を分割できるようにします

• 静的プレフィックス（提示词の約95%）— アイデンティティ、コアガイドライン、ツール説明
• 動的サフィックス — 現在の日時、リクエスト毎の言語指示、ハンドオフコンテキスト

​

キャパビリティ検出

​

プロバイダー間の対応状況

​

可観測性

"cache": {
  "read_tokens": 1067,
  "creation_tokens": 0
}

​

マルチターンキャッシュ ROI

​

推論リプレイポリシー（モデルレス正確性）

​

4つのポリシー

• anthropic_thinking — Claude ファミリー（anthropic/、bedrock/anthropic、vertex_ai/claude を含む）。思考ブロックは signature を付けて必ずリプレイする必要があります。Anthropic は署名がない場合または変更された場合、後続のターンを拒否します。
• informational_only — CoT を出力しますが、リプレイを期待しないモデル：DeepSeek 推論モード（V3.2 の deepseek-reasoner、および古い deepseek-r1 と R1-Distill ID はフラグメントテーブルが一致）、Qwen QwQ、Gemini flash-thinking、OpenAI o1 / o3 / o4。ドキュメントでは明確に「メッセージ履歴に reasoning_content を送信しないでください」と述べられています。それでも送信した場合：
  • プロバイダー契約に違反します（将来のバージョンで拒否を開始する可能性があります）
  • 自動プレフィックスキャッシュを静かに無効化します — メッセージバイトはターンごとに変更され、ハッシュが破損します
• openai_responses — GPT-5.x、gpt-5 フラグメントでマッチします。その推論状態はテキストではなく、暗号化されたペイロードを含む不透明なアイテムのシーケンスであり、/v1/responses だけがそれらのスロットを持ちます。そのプロトコルでは、アイテムはそのままリプレイされ、これがツールラウンド全体でモデルの思考の連鎖を保つものです。読み取り可能なサマリーは依然として送信リクエストから削除されるため、chat-completions フォールバックではこれは informational_only と全く同じように動作します。汎用の reasoning エントリがプロキシタグ付き GPT-5 ID を吸収する可能性がある情報フラグメントの前にチェックされます。
• unsupported — キャッチオール：推論機能のないモデル（GPT-4o、Gemini 1.5、Mistral、Llama）、および ID がフラグメントと一致しない推論モデル（GLM、MiniMax、Kimi、Doubao）。どちらの方法でもフィールドをリプレイしないため、このポリシーは informational_only と同じバイト列をワイヤに配置します。また、不明なモデル ID の安全なデフォルトでもあります。

​

実装

​

ユーザー向け

• 同じ会話内でClaudeとDeepSeekの間でエージェントを切り替える場合、履歴は思考ブロックをそのまま保存されます。次のターンで、送信メッセージの形状は現在のモデルに適応します。
• プロキシ / カスタム BaseLLM サブクラスを使用する場合、そのモデルIDが認識可能であることを確認してください（フラグメントの1つを含む）。そうでない場合、デフォルトの unsupported ポリシーが適用されます — これは安全ですが、異常なプロキシの背後にあるClaudeが思考リプレイを失う可能性があります。モデルIDフラグメントを _CACHE_CAPABLE_MODEL_FRAGMENTS（core/prompt/caching.py 内）および/または推理ポリシー検索に追加してください。

​

トラブルシューティング