プロバイダー検出
FIM Oneはユニバーサルアダプターとして LiteLLM を使用します。core/model/openai_compatible.py の _resolve_litellm_model() 関数は、ユーザーの LLM_BASE_URL + LLM_MODEL を、プロバイダープレフィックス付きの LiteLLM モデル識別子にマッピングします。プレフィックスは、LiteLLM がリクエストをどのようにルーティングするかを決定します — ネイティブ API プロトコル（Anthropic Messages API、Gemini など）またはジェネリック OpenAI 互換の /v1/chat/completions。
解決順序：
- 明示的なプロバイダー（DB の
ModelConfig.provider フィールドから）— 最優先。プロバイダーが URL 内の既知ドメインと一致する場合、api_base は返されません（LiteLLM はネイティブでルーティング）。それ以外の場合、api_base はリレー URL に設定されます。
KNOWN_DOMAINS に対するドメイン一致 — 公式 API エンドポイントはホスト名で認識されます。PATH_PROVIDER_HINTS に対する URL パスヒント — UniAPI のようなリレープラットフォームで一般的です。パスに /claude または /anthropic が含まれている場合、アップストリームプロトコルを示します。- フォールバック —
openai/ プレフィックス（ジェネリック OpenAI 互換）。
| ドメイン / パス | プロバイダープレフィックス | プロトコル |
|---|
api.openai.com | openai/ | OpenAI Chat Completions |
anthropic.com | anthropic/ | Anthropic Messages API |
generativelanguage.googleapis.com | gemini/ | Google Gemini |
api.deepseek.com | deepseek/ | DeepSeek（OpenAI 互換） |
api.mistral.ai | mistral/ | Mistral |
パスに /claude または /anthropic を含む | anthropic/ | Anthropic Messages API（リレー経由） |
パスに /gemini を含む | gemini/ | Google Gemini（リレー経由） |
| その他すべて | openai/ | ジェネリック OpenAI 互換 |
api_base にリクエストを送信します。これは、プロバイダー固有の動作（以下で説明する Bedrock プリフィル問題を含む）がリクエストが公式 API に送信されるか、リレー経由で送信されるかに関わらず適用されることを意味します。
リレー URL のパスに /claude が含まれている場合、FIM One は自動的に Anthropic のネイティブプロトコル経由でルーティングします。これは通常正しい選択です（ストリーミングとシンキングサポートが向上）が、プロバイダー固有の動作が適用されることを意味します — 以下で説明する Bedrock プリフィル問題を含みます。
tool_choice パラメータは OpenAI 形式で標準化されています。LiteLLM はリクエストを送信する前に、各プロバイダーのネイティブプロトコルに変換します。
| モード | 意味 | プロバイダーサポート |
|---|
"auto" | モデルがツール呼び出しまたはテキスト応答を決定 | すべてのプロバイダー |
"required" | ツール呼び出しが必須だが、モデルが選択 | ほとんどのプロバイダー |
{"type":"function","function":{"name":"X"}} | 関数 X の呼び出しが必須 | ほとんどのプロバイダー — Anthropic thinking と互換性なし |
"none" | ツール使用不可、テキストのみ | すべてのプロバイダー |
"auto" と強制モード（{"type":"function",...}）の区別は、FIM One のあらゆる互換性問題の核心です。これら 2 つのモードは、異なる要件を持つまったく異なるサブシステムで使用されています。
2つのサブシステムがtool_choiceを使用しており、それらは根本的に異なる方法でそれを使用しています。
ReAct ループでは、モデルが各イテレーションで以下を決定する必要があります: ツールを呼び出すか、最終的な回答を提供するか。ここで意味があるのは "auto" だけです — モデルは tool_calls を生成するか、テキスト コンテンツを生成するかを自由に選択します。これはすべてのプロバイダー、すべてのモデル、拡張思考を含むすべてのモードと互換性があります。
ReAct エンジンは、abilities["tool_call"] = True の場合にネイティブ関数呼び出し (_run_native) を使用し、それ以外の場合は JSON-in-content モード (_run_json) にフォールバックします。両方のモードで "auto" を使用します — 違いは、ツールが tools パラメータを介して渡されるか、システム プロンプトで説明されるかです。詳細は ReAct エンジン — デュアルモード実行 を参照してください。
ワンショット構造化抽出（スキーマアノテーション、DAG計画、計画分析）。モデルに特定の仮想関数を呼び出すことを強制し、構造化JSON出力を保証します。これはプロバイダー固有のエラーをトリガーするコールサイトです。
structured_llm_call は3レベルの劣化チェーンを実装します：
重要な設計上の違い：structured_llm_call のフォールバックは実行時です — 各レベルを動的に試行し、例外をキャッチして次のレベルに進みます。ReActエンジンのモード選択はビルド時です — 開始時に _native_mode_active を一度チェックし、ループ全体で1つのモードにコミットします。つまり、structured_llm_call はプロバイダー固有の400エラーから透過的に回復できますが、ReActは事前に正しくモードが選択されていることに依存しています。
Bedrockプリフィル トラップ
response_format={"type":"json_object"} が anthropic/ プレフィックスで解決されたモデルに渡される場合、LiteLLMは内部的にアシスタント プリフィル メッセージを挿入してJSON モードをシミュレートします。Anthropic Messages APIにはネイティブな response_format パラメータがないため、LiteLLMは開き括弧をアシスタント コンテンツとして先頭に追加することで近似します:
{"role": "assistant", "content": "{"}
role: "assistant" である会話を拒否します — これを「アシスタント メッセージ プリフィル」と呼び、以下をスローします:
ValidationException: This model does not support assistant message prefill.
The conversation must end with a user message.
- モデルが
anthropic/ プレフィックスで解決されている（ドメイン マッチまたはURLパス ヒント経由）。
response_format={"type":"json_object"} が渡されている（structured_llm_call のjson_modeコード パス）。- 実際のバックエンドがAWS Bedrock（プリフィルを拒否）である。
これはネイティブ ツール呼び出し（tool_choice="auto" と tools= パラメータ）には影響しません。プリフィル挿入は response_format に対してのみ発生します。ReAct エージェント実行は完全に影響を受けません。
修正: json_mode_enabled
モデルごとの json_mode_enabled フラグは、Level 2 (json_mode) が試行されるかどうかを制御します:
- DB設定モデル: Admin → Models → Advanced settings でトグル。フラグは
ModelConfig.json_mode_enabled に保存されます (デフォルト TRUE)。
- ENV設定モデル: 環境変数で
LLM_JSON_MODE_ENABLED=false を設定。
- 効果: 無効化すると、
abilities["json_mode"] は False を返す → response_format は渡されない → プリフィルなし → Bedrock が動作。デグラデーションチェーンは native_fc → plain_text となり、失敗する json_mode 呼び出しをスキップします。
- 品質低下なし: システムプロンプトがモデルに有効な JSON を返すよう指示するため、モデルは依然として有効な JSON を返します。plain_text レベルは
extract_json() を使用してフリーフォーム コンテンツから JSON を解析し、最新のモデルで確実に動作します。
Anthropic の API は、拡張思考が有効な場合、tool_choice={"type":"function","function":{"name":"X"}} を拒否します。エラーメッセージ：
Thinking may not be enabled when tool_choice forces tool use
structured_llm_call のレベル 1（native_fc）のみに影響します。これは強制的な tool_choice を使用して構造化出力を保証します。_call_llm の既存の try/except は 400 レスポンスをキャッチし、json_mode またはプレーンテキストにフォールスルーします。abilities 辞書での特別な処理は不要です。
重要なことに、tool_choice="auto" は Anthropic の思考が有効な場合でも完全に機能します。ReAct エンジンは "auto" のみを使用するため、影響を受けることはありません。
思考 + 強制 tool_choice の競合を回避するために abilities["tool_call"] = False を設定しないでください。これにより ReAct の _run_native モード（tool_choice="auto" を使用し、思考で正常に機能）が無効になり、_run_json モードに強制されます。_run_json では、モデルはそのコンテンツで有効な JSON を生成する必要があります。これはあまり信頼性が高くなく、Bedrock では json_mode が有効な場合、プリフィルの問題をトリガーする可能性があります。正しい修正は、structured_llm_call フォールバックチェーンに処理させることです。
クイックリファレンス：どこで何が機能するか
| シナリオ | ReAct mode | structured_llm_call path | 注記 |
|---|
| OpenAI（任意のモデル） | _run_native | native_fc | 完全サポート、注意事項なし |
| Anthropic（thinking なし） | _run_native | native_fc | 完全サポート |
| Anthropic + thinking | _run_native | native_fc → 400 → json_mode | 自動フォールバック、1 回の無駄な呼び出し |
| Bedrock relay（thinking なし） | _run_native | native_fc | 完全サポート |
| Bedrock relay + thinking | _run_native | native_fc → 400 → json_mode → 400 → plain_text | 2 回の無駄な呼び出し；json_mode_enabled=false を設定 |
Bedrock relay + json_mode_enabled=false | _run_native | native_fc → 400 → plain_text | Bedrock with thinking の推奨設定 |
Bedrock relay（thinking なし） + json_mode_enabled=false | _run_native | native_fc | 影響なし — native_fc が初回で成功 |
| Gemini | _run_native | native_fc | 完全サポート |
| DeepSeek | _run_native | native_fc | 完全サポート |
| Generic OpenAI-compatible | _run_native | native_fc | 完全サポート |
tool_call=false を使用する任意のモデル | _run_json | json_mode or plain_text | ツール呼び出しをサポートしないモデルのフォールバック |
# .env またはエンバイロンメント内で
LLM_JSON_MODE_ENABLED=false
native_fc → plain_text（思考なし）または native_fc → 400 → plain_text（思考あり）になります。どちらのパスも高速で信頼性があります。
推論努力と思考設定
FIM One は、拡張思考/推論を制御するための 2 つの環境変数を公開しています:
| 変数 | 値 | 効果 |
|---|
LLM_REASONING_EFFORT | low, medium, high | LiteLLM に reasoning_effort として渡されます。Anthropic: thinking パラメータにマップされます。OpenAI o シリーズ: そのまま渡されます。その他: サイレントにドロップされます (drop_params=True)。 |
LLM_REASONING_BUDGET_TOKENS | 整数 (例: 10000) | Anthropic のみ: 明示的な thinking.budget_tokens キャップを設定し、LiteLLM の自動マッピングをバイパスします。Claude モデルのコスト制御に便利です。 |
reasoning_effort が設定され、モデルが anthropic/ として解決される場合、以下の 2 つの追加動作が適用されます:
- 温度は 1.0 に強制されます。 Bedrock は思考が有効な場合、
temperature != 1.0 を拒否します。FIM One はこれを自動的に処理します — ユーザーアクションは不要です。
- GPT-5.x とツール:
tools が存在する場合、reasoning_effort はサイレントにドロップされます。これは GPT-5 の /v1/chat/completions エンドポイントがこの組み合わせを拒否するためです。これは ReAct ツールループにのみ影響します。tools パラメータを持たない structured_llm_call 呼び出しは影響を受けません。
トラブルシューティング
「このモデルはアシスタントメッセージプリフィルをサポートしていません」
Bedrock + json_mode。LLM_JSON_MODE_ENABLED=falseを設定するか、管理者モデル設定でJSON Modeを無効にしてください。
「tool_choiceがツール使用を強制する場合、Thinkingは有効にできない可能性があります」
Anthropic thinking + structured_llm_callでの強制関数呼び出し。これはエラーではなく、予期された動作です。フォールバックチェーンが400をキャッチし、native_fcをスキップして、json_modeまたはplain_textで成功します。ログはDEBUGレベルです — LOG_LEVEL=DEBUGの場合のみ表示されます。コスト: ~300msのネットワーク往復、ゼロトークン（モデルは400では実行されません）。アクションは不要です。
ReActが予期せずJSON modeにフォールバックする
モデルのabilities["tool_call"]がTrueであることを確認してください。これはOpenAICompatibleLLMでは常にTrueですが、カスタムBaseLLMサブクラスはこれをオーバーライドする可能性があります。管理者APIのモデル詳細エンドポイントで確認してください。
structured_llm_callがすべてのレベルを使い尽くしてStructuredOutputErrorを発生させる
モデルがいかなるレベルでも解析可能なJSONを生成できませんでした。これは最新のモデルではまれです。確認してください: (1) スキーマが有効なJSON Schemaである、(2) モデルに完全な応答を生成するのに十分なmax_tokensがある、(3) システムプロンプトがスキーマ指示と矛盾していない。DAGプランナーとアナライザーは両方ともdefault_valueフォールバックを提供するため、このエラーはデフォルトを明示的に省略した呼び出しサイトからのみ伝播します。
