主要LLMにおけるReasoning表現とチャットテンプレート仕様

2026年4月5日更新

主要LLMにおけるReasoning表現とチャットテンプレート仕様

本ドキュメントは、公開されている chat_template.jinjatokenizer_config.json、エンコーダ実装、モデルカード、および公式APIドキュメントの仕様に基づき、主要なLLM(大規模言語モデル)のチャットテンプレート上でReasoning(推論)がどのように表現されるかを整理した技術リファレンスです。
定義: 本ドキュメントにおける「Reasoning表現」とは、モデル内部の不可視な推論プロセスではなく、テンプレート、トークナイザ、またはプロンプト上に明示的に出力される構造を指します。具体例として、<think>...</think>[THINK]...[/THINK] のようなタグ、あるいはHarmonyアーキテクチャにおける analysis チャネルなどが該当します。

対象モデルの概要

2026年4月5日時点において、公開テンプレートからReasoningの仕様を特定および追跡できる主要なモデル系統は以下の9種類です。
  • gpt-oss-120b
  • LLM-jp-4-thinking
  • Gemma 4
  • DeepSeek-V3.2
  • Qwen3.5
  • Kimi K2.5
  • Phi-4-reasoning
  • GLM-5
  • Mistral 3 系(公開テンプレートの代表として Ministral-3-14B-Reasoning-2512 を採用)
注記: Llama 4 および OLMo 2 については、通常のInstruct/Chat用テンプレートの存在は確認されています。しかし、Reasoning専用の公開テンプレート仕様、および推論深度(Reasoning Effort)を制御する明示的なパラメータが確認できなかったため、本ドキュメントの主要な比較対象からは除外し、補遺として扱います。

1. アーキテクチャの前提: API SurfaceとPrompt Surfaceの分離

各モデルの実運用環境を正確に評価・実装するため、本ドキュメントでは入出力のインターフェースを以下の2つの層に分類して定義します。

1.1 API Surface

利用者がシステムを介して直接送信する入力ペイロードです。典型的な構造は以下の通りです。
{
  "messages": [
    {"role": "user", "content": "明日の東京の天気を調べて要約してください"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "都市の天気を返す",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string"}
          },
          "required": ["city"]
        }
      }
    }
  ]
}

1.2 Prompt Surface

上記のAPI Surfaceに入力されたデータが、最終的にモデルへ投入される文字列および特殊トークン列として直列化された状態です。このPrompt Surfaceの構造はモデルごとに大きく異なります。代表的なパターンは以下の通りです。
  • <think>...</think> 系: GLM、Kimi、Qwen、DeepSeek、Phi
  • <|think|> または thought チャネル系: Gemma 4
  • [THINK]...[/THINK] 系: Ministral Reasoning
  • Harmonyチャネル(analysis / commentary / final)系: gpt-oss、LLM-jp-4-thinking
本ドキュメントでは、主にこの「Prompt Surface」の仕様を中心に解説し、必要に応じてAPI層の制御パラメータ(reasoning_effortenable_thinking など)の仕様も併記します。

2. 評価用の標準入力ペイロード

各モデルのテンプレートによる直列化プロセスの違いを横断的に比較するため、本ドキュメントでは以下の抽象入力を標準のベースラインとして使用します。

2.1 メッセージ入力

[
  {"role": "user", "content": "明日の東京の天気を調べて要約してください"}
]

2.2 利用可能なツール定義

[
  {
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "都市名を受け取り、天気情報を返す",
      "parameters": {
        "type": "object",
        "properties": {
          "city": {"type": "string"}
        },
        "required": ["city"]
      }
    }
  }
]
注記: 以降のセクションで示されるコードブロックは、この標準ペイロードが各モデルのテンプレートでどのように処理および表現されるかを示す概略(重要トークンと構造を抽出した縮約版)です。

3. モデル別仕様サマリー

以下は、各主要モデル系統における公開アーティファクト、Reasoningの明示表現、制御パラメータ、およびツール呼び出し仕様の概要一覧です。
  • gpt-oss-120b
    • 公開アーティファクト: openai/gpt-oss-120b/chat_template.jinja
    • Reasoning表現: analysis チャンネル
    • 制御パラメータ: reasoning_effort=low|medium|high
    • ツール呼び出し表現: Harmony 呼び出し構文
  • LLM-jp-4-thinking
    • 公開アーティファクト: llm-jp/llm-jp-4-8b-thinking/chat_template.jinja
    • Reasoning表現: Harmony の analysis チャンネル
    • 制御パラメータ: reasoning_effort=low|medium|high
    • ツール呼び出し表現: Harmony 呼び出し構文
  • Gemma 4
    • 公開アーティファクト: google/gemma-4-E2B-it/chat_template.jinja
    • Reasoning表現: <|think|> / thought チャンネル
    • 制御パラメータ: enable_thinking=True|False
    • ツール呼び出し表現: <|tool>, <|tool_call>, <|tool_response>
  • DeepSeek-V3.2
    • 公開アーティファクト: deepseek-ai/DeepSeek-V3.2/encoding/encoding_dsv32.py
    • Reasoning表現: <think>...</think>
    • 制御パラメータ: thinking_mode="thinking"|"chat", drop_thinking
    • ツール呼び出し表現: DSML 構文(<|DSML|function_calls>
  • Qwen3.5
    • 公開アーティファクト: Qwen/Qwen3.5-35B-A3B/tokenizer_config.json
    • Reasoning表現: <think>...</think>
    • 制御パラメータ: enable_thinking=False
    • ツール呼び出し表現: <tool_call><function=...><parameter=...>
  • Kimi K2.5
    • 公開アーティファクト: moonshotai/Kimi-K2.5/chat_template.jinja
    • Reasoning表現: <think>...</think>
    • 制御パラメータ: thinking on/off(デフォルトは on)
    • ツール呼び出し表現: tool_declare, <|tool_calls_section_begin|>
  • Phi-4-reasoning
    • 公開アーティファクト: microsoft/Phi-4-reasoning/tokenizer_config.json
    • Reasoning表現: <think>...</think>(固定のシステム指示)
    • 制御パラメータ: 該当仕様なし
    • ツール呼び出し表現: ツール呼び出し用構文なし
  • GLM-5
    • 公開アーティファクト: zai-org/GLM-5-FP8/chat_template.jinja
    • Reasoning表現: <think>...</think>
    • 制御パラメータ: enable_thinking / thinking.type=disabled / clear_thinking
    • ツール呼び出し表現: <tools>...</tools>, <tool_call>...
  • Mistral 3 系
    • 公開アーティファクト: mistralai/Ministral-3-14B-Reasoning-2512/chat_template.jinja
    • Reasoning表現: [THINK]...[/THINK]
    • 制御パラメータ: 公開テンプレートは固定で、API 側は reasoning_effort をサポート
    • ツール呼び出し表現: [AVAILABLE_TOOLS], [TOOL_CALLS], [TOOL_RESULTS]

4. gpt-oss-120b 仕様詳細

4.1 参照アーティファクト

  • Hugging Face: openai/gpt-oss-120b/chat_template.jinja
  • GitHub: openai/harmony README
本モデルの主要な設計上の特徴は、推論ブロックに <think> タグを使用せず、Harmonyプロトコルに基づく analysis チャネルを採用している点です。

4.2 API 仕様

標準的なチャットメッセージおよびツール定義に加え、テンプレートの適用時に以下のキーワード引数(kwargs)をサポートします。
  • builtin_tools (例: ["browser", "python"])
  • model_identity
  • reasoning_effort ("low", "medium", または "high")
実装例:
tokenizer.apply_chat_template(
    messages,
    tools=tools,
    builtin_tools=["browser"],
    reasoning_effort="high",
)

4.3 プロンプト構造

Harmony形式に基づく直列化プロンプトの基本構造は以下の通りです。
<|start|>system<|message|>
You are ChatGPT...
Knowledge cutoff: 2024-06
Current date: 2026-04-05
Reasoning: high
# Valid channels: analysis, commentary, final.
...
<|end|>
<|start|>developer<|message|>
# Tools
## functions
namespace functions {
  type get_weather = (_: { city: string }) => any;
}
<|end|>
<|start|>user<|message|>
明日の東京の天気を調べて要約してください
<|end|>
Reasoningおよびツールの呼び出しは以下の構造をとります。
<|start|>assistant<|channel|>analysis<|message|>
Need a weather lookup.
<|end|>
<|start|>assistant to=functions.get_weather<|channel|>commentary json<|message|>
{"city":"東京"}
<|call|>
ツール実行結果のプロンプト構造は以下の通りです。
<|start|>functions.get_weather to=assistant<|channel|>commentary<|message|>
"{\"weather\":\"sunny\"}"
<|end|>
ユーザーへの最終応答は以下のように出力されます。
<|start|>assistant<|channel|>final<|message|>
明日の東京は晴れです。...
<|end|>

4.4 推論(Reasoning)の表現仕様

本モデルは思考プロセスをテキストタグ内に展開するのではなく、論理チャネルとして分割処理します。
  • 推論(Reasoning): アシスタントメッセージの analysis チャネルを使用します。
  • ツール連携: commentary チャネルを使用します。
  • 最終回答: final チャネルを使用します。

4.5 推論エフォートおよびモードの仕様

本モデルは、テンプレート引数として明示的なEffort制御をサポートしています。指定された "low", "medium", "high" の値は、合成システムメッセージ内の Reasoning: ... ディレクティブとしてプロンプトテキストに直接挿入されます。

4.6 ツール呼び出し仕様

ツール定義と呼び出しには、厳密なHarmonyグラマーが適用されます。
  • ツール定義: TypeScriptの namespace 形式でdeveloperメッセージ内に定義します。
  • 呼び出し命令: assistant to=functions.NAME の形式を使用します。
  • チャネル設定: commentary json を指定します。
  • 引数: JSONペイロードとして構成します。
  • 終端タグ: <|call|> を使用します。

4.7 推論履歴の管理

パフォーマンスおよびコンテキスト長の最適化のため、推論時には過去のChain of Thought (CoT) を除外する処理がテンプレートロジックに組み込まれています。すべての analysis 履歴を生データのまま保持する設計ではありません。

4.8 実装時の留意点

  • 本モデルの統合には、Harmonyプロトコル専用のパーサーおよびデータモデルが必須となります。汎用的な <think> パーサーは適用できません。
  • 同一のアシスタントテキストブロック内にTool CallingとReasoningを混在させず、適切なチャネルと宛先属性を用いてルーティングする必要があります。

5. LLM-jp-4-thinking 仕様詳細

5.1 参照アーティファクト

本モデルにおける代表的な公開アーティファクトは以下の通りです。
  • Hugging Face: llm-jp/llm-jp-4-8b-thinking/chat_template.jinja
  • 該当のモデルカード
アーキテクチャの特性として、LLM-jp-4-thinkingはOpenAI Harmony仕様との互換性を強く志向した設計が採用されています。

5.2 API 仕様

チャットテンプレートの適用時、追加の引数(kwargs)として以下のパラメータをサポートします。
  • builtin_tools
  • model_identity
  • reasoning_effort="low"|"medium"|"high"
モデルカードにて公開されている実装例では、tokenizer.apply_chat_template(..., reasoning_effort="medium") のようにパラメータを指定する構成が案内されています。

5.3 プロンプト構造

gpt-ossと高度な類似性を持ち、概ね以下のHarmony形式の構造に変換されます。
<|start|>system<|message|>
You are LLM-jp-4...
Knowledge cutoff: 2025-12
Current date: 2026-04-05
Reasoning: medium
# Valid channels: analysis, commentary, final.
<|end|>
<|start|>developer<|message|>
# Tools
## functions
namespace functions {
  type get_weather = (_: { city: string }) => any;
}
<|end|>
<|start|>user<|message|>
明日の東京の天気を調べて要約してください
<|end|>
推論(Reasoning)およびツール呼び出しのリクエストは以下の通りです。
<|start|>assistant<|channel|>analysis<|message|>
まず天気を取得する
<|end|>
<|start|>assistant to=functions.get_weather<|channel|>commentary json<|message|>
{"city":"東京"}
<|call|>
最終的な回答出力は以下の通りです。
<|start|>assistant<|channel|>final<|message|>
明日の東京は晴れです。...
<|end|>

5.4 推論(Reasoning)の表現仕様

  • 推論プロセスは <think> タグではなく、analysis チャンネルとして表現されます。
  • tokenizer.parse_response(response) メソッドを実行することで、推論部分(thinking)と最終回答(content)を分離することが可能です。
  • 専用のトークナイザを使用する必要がある旨が、モデルカードにて明記されています。

5.5 推論エフォートおよびモードの仕様

LLM-jp-4-thinkingは、gpt-ossと同様にプロンプトテンプレートのパラメータとして多段階の推論深度(Reasoning Effort)を指定可能なアーキテクチャです。
  • 指定可能な値: reasoning_effort="low"|"medium"|"high"
  • テンプレート評価時、合成されたシステムメッセージ内の Reasoning: ... 行に該当パラメータが埋め込まれます。

5.6 ツール呼び出し仕様

ツール呼び出しはHarmony形式の文法に準拠します。
  • TypeScript形式の namespace functions を使用した定義
  • 呼び出し構文: assistant to=functions.NAME
  • 使用チャンネル: commentary json
  • 終端トークン: <|call|>
  • レスポンス形式: functions.NAME to=assistant

5.7 推論履歴の取り扱い

テンプレートのコメントブロックにて明示されている通り、推論フェーズにおいて過去のCoT(Chain of Thought)履歴を破棄する設計が採用されています。これはgpt-ossの思想と一致します。

5.8 実装時の留意点

  • openai-harmony ライブラリの思想と互換性を持ちますが、トークナイザの実装は完全に同一ではありません。安全性の観点から、LLM-jpが提供する公式のトークナイザおよびパーサーを使用することを推奨します。
  • 提供されているReasoningパーサーを実行する際、構成によっては trust_remote_code=True オプションの有効化が必須となる公開事例が存在します。

5.9 関連リソース

6. Gemma 4 仕様詳細

6.1 参照アーティファクト

本節では、Gemma 4 ファミリーの代表的なアーティファクトとして以下を参照します。
  • google/gemma-4-E2B-it/chat_template.jinja
  • 公式ドキュメント: Thinking mode in Gemma

6.2 API 仕様

推論機能の有効化は、apply_chat_template メソッドの引数を使用して制御します。
tokenizer.apply_chat_template(messages, tools=tools, enable_thinking=True)

6.3 プロンプト構造

Gemma 4 において推論機能を有効化した場合、動的にシステムターンが挿入されるアーキテクチャを採用しています。直列化構造は以下の通りです。
<|turn>system
<|think|><turn|>
<|tool>
declaration:get_weather{description:..., parameters:{city:string}}
<tool|>
<|turn>user
明日の東京の天気を調べて要約してください<turn|>
<|turn>model
なお、26B / 31B モデルの公式ドキュメントでは、推論無効時にモデル側へ thought チャンネルを開放する構成についても言及されています。

6.4 推論(Reasoning)の表現仕様

Gemma 4 における推論の表現方法は、モデルのパラメータサイズに応じて以下の通り異なります。
  • E2B / E4B 系モデル: 推論有効時、先頭に <|think|> が挿入されます。
  • 26B / 31B 系モデル: model ターンの後方に thought チャンネルを開放する表現形式が案内されています。
  • 提供されるテンプレートには、履歴再構築時に推論部分を削除する strip_thinking マクロが含まれています。
これらはプレーンテキストベースのタグ挿入ではなく、チャンネルやターン制御に基づく設計思想に基づいています。

6.5 推論エフォートおよびモードの仕様

本モデルの推論機能は、以下のブール値パラメータにより制御されます。
  • enable_thinking=True|False
多段階のエフォート指定は確認されていません。

6.6 ツール呼び出し仕様

ツール呼び出しには、以下の専用タグ構文を使用します。
  • ツール定義: <|tool> ... <tool|>
  • ツール呼び出し: <|tool_call>call:FUNC{arg:...}<tool_call|>
  • ツールの実行結果: <|tool_response>response:FUNC{...}<tool_response|>
呼び出しおよび結果返却時の直列化例は以下の通りです。
<|tool_call>call:get_weather{city:<|"|>東京<|"|>}<tool_call|>
<|tool_response>response:get_weather{weather:<|"|>sunny<|"|>}<tool_response|>

6.7 実装時の留意点

  • 以前の Gemma の仕様とは異なり、Gemma 4 の公開テンプレートは推論およびツール呼び出し用のシステムターンを生成するよう更新されています。
  • 実装時は、実際の chat_template.jinja ファイルを仕様の正(Source of Truth)として参照することを強く推奨します。

7. DeepSeek-V3.2 仕様詳細

7.1 参照アーティファクト

本モデルのプロンプト構築ロジックは Jinja テンプレートではなく、以下の Python エンコーダ実装により定義されています。
  • deepseek-ai/DeepSeek-V3.2/encoding/encoding_dsv32.py

7.2 API 仕様

エンコード処理時に以下のパラメータを指定することで、推論動作および履歴の保持を制御します。
encode_messages(
    messages,
    tools=tools,
    thinking_mode="thinking",
    drop_thinking=True,
    add_default_bos_token=True,
)
  • thinking_mode: "thinking" または "chat" を指定します。
  • drop_thinking: コンテキストサイズを節約するため、過去の推論履歴を破棄するかどうかを指定します。

7.3 プロンプト構造

入力データの直列化構造は以下の通りです。
<|begin▁of▁sentence|>
## Tools
...
<|User|>明日の東京の天気を調べて要約してください<|Assistant|><think>
ツール呼び出しには、以下の DSML 構文が使用されます。
<|DSML|function_calls>
  <|DSML|invoke name="get_weather">
    <|DSML|parameter name="city" string="true">東京</|DSML|parameter>
  </|DSML|invoke>
</|DSML|function_calls>
ツールの実行結果は以下のブロック構造で返却されます。
<function_results>
  <result>{"weather":"sunny"}</result>
</function_results>
<think>

7.4 推論(Reasoning)の表現仕様

  • 推論プロセスは <think>...</think> ブロックに格納されます。
  • ユーザーとアシスタントの区切りとして、それぞれ <|User|><|Assistant|> が使用されます。
  • アシスタントの出力完了時は、推論内容、回答コンテンツ、ツール呼び出し、および EOS トークンが連結される仕様です。

7.5 推論エフォートおよびモードの仕様

多段階のエフォート指定はサポートされておらず、以下の 2 つのモードを指定します。
  • thinking_mode="thinking": 推論モードを有効化します。
  • thinking_mode="chat": 推論を抑制した標準対話モードを有効化します。
  • drop_thinking=True|False: 過去の推論履歴の保持または破棄を制御します。

7.6 ツール呼び出し仕様

DeepSeek-V3.2 は、独自の DSML(DeepSeek Markup Language)構文を使用してツールを呼び出します。
  • 関数呼び出しブロックは <|DSML|function_calls> で定義されます。
  • 各呼び出し(invoke)には対象ツールを指定する name 属性が付与されます。
  • パラメータは <|DSML|parameter ...> で定義し、文字列型の場合は明示的に string="true" を指定します。
  • リスト型またはオブジェクト型のデータは JSON 形式で埋め込まれます。

7.7 実装時の留意点

  • プロンプト構築の仕様確認においては、Jinja テンプレートではなく encoding_dsv32.py を正として参照する必要があります。
  • クライアント側には DeepSeek-V3.2 専用のパーサー実装が求められます。

8. Qwen3.5 仕様詳細

8.1 参照アーティファクト

本節では、Qwen3.5 ファミリーの代表的なアーティファクトとして以下を参照します。
  • Qwen/Qwen3.5-35B-A3B/tokenizer_config.json
  • Qwen/Qwen3.5-9B のモデルカードおよびクイックスタートドキュメント

8.2 API 仕様

Qwen3.5 では、推論機能(Thinking)はデフォルトで有効化されています。推論機能を無効化する場合は、APIリクエスト時に以下のように指定します。
extra_body={"chat_template_kwargs": {"enable_thinking": False}}

8.3 プロンプト構造

モデルに入力される直列化データの構造は以下の通りです。
<|im_start|>system
# Tools
You may call one or more functions...
<tools>
[{"name":"get_weather", ...}]
</tools><|im_end|>
<|im_start|>user
明日の東京の天気を調べて要約してください<|im_end|>
<|im_start|>assistant
<think>
ツール呼び出し時には、以下のような XML 風の独自ブロックが出力されます。
<tool_call>
<function=get_weather>
<parameter=city>
東京
</parameter>
</function>
</tool_call>
ツールの実行結果は tool ロールではなく、user ターン内に内包された <tool_response> ブロックとしてプロンプトに組み込まれます。
<|im_start|>user
<tool_response>
{"weather":"sunny"}
</tool_response><|im_end|>

8.4 推論(Reasoning)の表現仕様

推論プロセスは <think>...</think> ブロックに格納されます。推論機能が有効な場合、アシスタントの生成出力は <think> タグから開始され、推論完了後に最終的な回答が出力される仕様です。

8.5 推論エフォートおよびモードの仕様

現時点で確認可能な公開仕様は、推論機能の有効・無効の切り替えのみです。
  • デフォルト: 推論機能有効
  • 無効化設定: enable_thinking=False

8.6 ツール呼び出し仕様

ツール呼び出しには、Qwen 独自の構文が使用されます。
  • システムプロンプト内の <tools>...</tools> ブロックにスキーマを定義します。
  • アシスタントは <tool_call> ブロックを出力します。
  • ツールの実行結果は user ターン内の <tool_response> で返却されます。
  • 推論ブロックはツール呼び出しの前に配置する必要があり、呼び出しの後に配置することは許可されていません。

8.7 実装時の留意点

  • テンプレートは、最後のユーザーリクエストより前の推論履歴を自動的に圧縮する設計となっています。
  • セルフホスティング環境では、Qwen 専用の推論パーサーおよびツール呼び出しパーサーを組み込む必要があります。

9. Kimi K2.5 仕様詳細

9.1 参照アーティファクト

  • Hugging Face: moonshotai/Kimi-K2.5/chat_template.jinja
  • 公式ドキュメント: Kimi API Platform (thinking model guide)

9.2 API 仕様

Kimi K2.5はデフォルトでThinkingモードが有効化されています。無効化を行う場合は、OpenAI互換APIの extra_body パラメータを通じて以下の指定を行います。
extra_body={"thinking": {"type": "disabled"}}
Thinkingモード有効時は、レスポンスペイロードから message.reasoning_content および message.content を分離して取得する設計が前提となります。

9.3 プロンプト構造

本ドキュメント「2. 共通比較用の抽象入力」に基づく抽象入力は、以下の形式へ直列化されます。
<|im_system|>tool_declare<|im_middle|>
[{"name":"get_weather", ...}]
<|im_end|>
<|im_user|>user<|im_middle|>
明日の東京の天気を調べて要約してください
<|im_end|>
<|im_assistant|>assistant<|im_middle|>
<think>
ツール呼び出しは、アシスタントのターン内に以下の専用ブロックとして出力されます。
<think>先に天気を取得する</think>
<|tool_calls_section_begin|>
<|tool_call_begin|get_weather
<|tool_call_argument_begin|>{"city":"東京"}
<|tool_call_end|>
<|tool_calls_section_end|>
ツール実行結果は tool ロールに割り当てられますが、プロンプト上では以下のラベルが付与されたテキストとしてフォーマットされます。
## Return of call_1
{"weather":"sunny"}

9.4 推論(Reasoning)の表現仕様

  • アシスタントの推論プロセスは <think>...</think> ブロック内に格納されます。
  • Thinkingモードの有効状態に応じ、生成開始時は有効であれば <think>、無効であれば空の <think></think> が先頭に配置されます。
  • Kimiのテンプレート仕様として、過去ターンのアシスタントのReasoningを意図的に破棄し、直近のReasoningのみを保持する圧縮ロジックが組み込まれています。

9.5 推論エフォートおよびモードの仕様

公開仕様として確認できる制御パラメータはThinkingモードの有効化/無効化のみです。
  • デフォルト状態: Thinkingモード有効 (on)
  • 無効化指定: thinking.type="disabled"
  • 段階的なEffort指定(low/medium/highなど)は、現行の公開テンプレートおよび公式APIドキュメントではサポートされていません。

9.6 ツール呼び出し仕様

Kimi K2.5は固有のツール定義および呼び出し表現を採用しています。
  • ツール定義: tool_declare を用いたシステムターン内で宣言されます。
  • ツール呼び出し: <|tool_calls_section_begin|> から開始する専用ブロックを使用します。
  • 呼び出し引数: tool_call_begintool_call_argument_begintool_call_end の一連の特殊トークンによって構成されます。
  • ツール実行結果: APIレイヤーでは tool ロールとして扱われますが、プロンプト内では Return of <id> 形式のプレーンテキストに変換されます。

9.7 実装時の留意点

  • Thinkingモード利用時は、過去ターンの reasoning_content を履歴に完全な状態で復元することが推奨されます。
  • Hugging Face提供のテンプレート自体が履歴中の一部のReasoningデータを圧縮する性質を持つため、APIクライアント側の履歴管理実装と、テンプレートレイヤーでの圧縮方針を混同しないよう留意してください。

10. Phi-4-reasoning 仕様詳細

10.1 参照アーティファクト

  • Hugging Face: microsoft/Phi-4-reasoning/tokenizer_config.json
  • Model card
本モデルは、ChatML形式に準拠したテンプレート内に、固定のシステムプロンプトを常時注入するアーキテクチャを採用しています。

10.2 API 仕様

入力インターフェースは標準的なChatML形式の messages です。設定時の重要事項として、トークナイザーテンプレートの処理時に専用の固定システムインストラクションが自動的に先頭へ挿入される仕様となっています。

10.3 プロンプト構造

プロンプトの直列化構造は以下の通りです。
<|im_start|>system<|im_sep|>
[固定の reasoning 指示。Thought と Solution を分け、
<think>{Thought}</think>{Solution} の形で答えるよう促す]
<|im_end|>
<|im_start|>user<|im_sep|>
明日の東京の天気を調べて要約してください
<|im_end|>
<|im_start|>assistant<|im_sep|>

10.4 推論(Reasoning)の表現仕様

  • Reasoningの内容は <think>...</think> ブロック内に記述されます。
  • 出力フォーマットはユーザーがAPIリクエストのシステムメッセージとして指定するものではなく、トークナイザーテンプレートが自動挿入するシステムプロンプトによって強制されます。
  • トークナイザーの語彙(Vocabulary)には、専用トークンとして <think> および </think> が登録されています。

10.5 推論エフォートおよびモードの仕様

本モデルは多段階のEffort制御パラメータ(low, medium, high など)や、有効化/無効化のスイッチをサポートしていません。常に「Thought + Solution」形式を出力する固定動作となります。

10.6 ツール呼び出し仕様

公式テンプレートおよびモデルカードの仕様上、Phi-4-reasoningに特化したネイティヴなTool Callingのグラマーは定義されていません。
システム統合時の推奨構成:
  1. Tool Callingロジックは外部のエージェントレイヤーで実装します。
  2. モデル自体は、<think>...</think> を生成する推論専用のコンポーネントとして配置します。

10.7 実装時の留意点

  • テンプレートによって挿入される先頭の固定システムプロンプトを改変または削除すると、モデルの期待出力フォーマットが崩壊するリスクがあります。
  • セルフホスティング環境においてパーサーを構築する際、DeepSeek-R1系のReasoningパーサーコンポーネントを流用することが可能です。

11. GLM-5 仕様詳細

11.1 参照アーティファクト

  • Hugging Face: zai-org/GLM-5-FP8/chat_template.jinja
  • 公式ドキュメント: GLM-5 overview / Thinking Mode / Function Calling

11.2 API 仕様

OpenAI互換のAPIリクエストをサポートします。リクエストペイロードにおいて、messagestoolstool_choicetool_callsreasoning_content を指定可能です。
Thinkingモードを無効化する場合、以下のパラメータを指定します。
{"thinking": {"type": "disabled"}}
また、複数ターンの対話履歴においてReasoningのプロセスを保持したまま再投入を行う場合は、clear_thinking=false を指定します。

11.3 プロンプト構造

本ドキュメント「2. 共通比較用の抽象入力」に基づく抽象入力は、以下の形式へ直列化されます。
[gMASK]<sop>
<|system|>
# Tools
You may call one or more functions...
<tools>
[{"name":"get_weather", ...}]
</tools>
<|user|>
明日の東京の天気を調べて要約してください
<|assistant|>
<think>
ツール呼び出し実行時、アシスタントの出力には以下の構造が挿入されます。
<think>まず天気ツールを使う</think>
<tool_call>
get_weather
<arg_key>city</arg_key><arg_value>東京</arg_value>
</tool_call>
ツール実行結果は、tool ロールに相当するメッセージとして以下の形式で再直列化されます。
<|observation|>
<tool_response>{"weather":"sunny"}</tool_response>

11.4 推論(Reasoning)の表現仕様

  • 推論プロセスは <think>...</think> ブロック内に格納されます。
  • テンプレートは message.reasoning_content の存在を優先的に評価し、該当データがない場合は assistant.content から <think>...</think> ブロックの抽出を試みます。
  • Thinkingモードの有効状態に応じて、生成開始トークンは <|assistant|><think>(有効時)、または <|assistant|></think>(無効時)となります。

11.5 推論エフォートおよびモードの仕様

GLM-5では、Reasoningの深度を指定する段階的なパラメータ(low/medium/highなど)は提供されていません。Thinkingモードの有効化/無効化、および履歴保持の有無のみをサポートします。
  • ローカル環境 / テンプレート: enable_thinking=True|False
  • ホステッドAPI: thinking.type="disabled"
  • マルチターン履歴保持: clear_thinking=false

11.6 ツール呼び出し仕様

APIリクエストと内部プロンプトで構造に差異が存在します。
  • API入力レイヤーではOpenAI互換の tools / tool_calls フォーマットを利用します。
  • モデル入力プロンプトへ変換される際、<tools>...</tools> および <tool_call>...</tool_call> ブロックに再構成されます。
  • ツールの実行結果は <tool_response>...</tool_response> ブロックとして扱われます。

11.7 実装時の留意点

  • マルチターンでReasoningを継続させる要件がある場合は、明示的に clear_thinking=false を指定してください。
  • セルフホスティング環境を構築する場合、GLM系に特化した専用のReasoningパーサーおよびツールパーサーの実装が必要です。

12. Mistral 3 系 仕様詳細(代表モデル: Ministral-3-14B-Reasoning-2512)

12.1 参照モデルと選定基準

Mistral系列のモデルにおいてReasoningの内部テンプレート仕様を検証するため、本項ではオープンウェイトモデルである mistralai/Ministral-3-14B-Reasoning-2512 を基準とします。Hosted API側でもReasoning機能は提供されていますが、内部プロンプトが非公開であるため、詳細な仕様確認にはオープンウェイトのテンプレートを参照する必要があります。

12.2 API 仕様

利用環境に応じて、入力仕様が異なります。
  • オープンウェイトモデル: 標準的な messages および tools パラメータを使用します。
  • Hosted APIモデル:
    • mistral-small-latest: reasoning_effort パラメータによる段階的な調整がサポートされています。
    • magistral-small-latest / magistral-medium-latest: ネイティヴReasoningモデルであり、常時Thinking処理が実行されます。

12.3 プロンプト構造

標準的な入力値に基づくプロンプトの直列化構造は以下の通りです。
[SYSTEM_PROMPT]...[/SYSTEM_PROMPT]
[AVAILABLE_TOOLS][{"name":"get_weather",...}][/AVAILABLE_TOOLS]
[INST]明日の東京の天気を調べて要約してください[/INST]
アシスタントの推論および回答プロセスは以下の順序で構成されます。
[THINK]まず天気を取得する[/THINK]
[TOOL_CALLS]get_weather[ARGS]{"city":"東京"}
ツール実行結果のプロンプト構造は以下の通りです。
[TOOL_RESULTS]{"weather":"sunny"}[/TOOL_RESULTS]

12.4 推論(Reasoning)の表現仕様

  • オープンウェイトのテンプレートでは、Reasoningプロセスは [THINK]...[/THINK] ブロック内に格納されます。
  • システムプロンプトは、モデルがReasoningを出力することを前提とした構成になっています。
  • アシスタントのコンテンツは、thinking チャンクと text チャンクに分割して処理されるアーキテクチャを採用しています。

12.5 推論エフォートおよびモードの仕様

デプロイメント方式によってパラメータのサポート状況が異なります。
  • オープンウェイトモデル: 公開されている chat_template.jinja には low|medium|high などの動的パラメータは存在せず、固定のReasoningモードとして機能します。
  • Hosted APIモデル: mistral-small-latest では reasoning_effort を介した調整が可能です。また、ネイティヴモデル(magistral-*)では、追加のパラメータ指定なしでThinkingチャンクが出力されます。

12.6 ツール呼び出し仕様

Ministral-3-Reasoningのテンプレートは、専用のデリミタ文字列を使用してツールインターフェースを定義します。
  • 定義: [AVAILABLE_TOOLS]...[/AVAILABLE_TOOLS]
  • 呼び出し: [TOOL_CALLS]name[ARGS]{json}
  • 実行結果: [TOOL_RESULTS]...[/TOOL_RESULTS]

12.7 実装時の留意点

  • Mistral系統のタグは一般的なXML形式の <think> ではなく、角括弧を用いた [THINK] である点に注意してください。
  • Hosted APIの reasoning_effort パラメータは内部プロンプトとしてどう処理されるか公開されていないため、厳密なパーサーを実装する場合はオープンウェイトの仕様に準拠することを推奨します。

13. 横断比較: 主要パターン

各モデルのReasoning表現におけるアーキテクチャパターンは、大きく以下の3つのカテゴリに分類されます。

13.1 インラインタグ構成(<think>...</think> 型)

推論プロセスをテキストデータのタグとしてプロンプトおよびコンプリーション内に直接埋め込む構成です。
  • 対象モデル: GLM-5、Kimi K2.5、Qwen3.5、DeepSeek-V3.2、Phi-4-reasoning
  • 特徴:
    • パーサーの実装が比較的容易です。
    • ただし、ツール呼び出し(Tool Calling)の文法については各社独自の仕様が採用されており、標準化されていません。

13.2 専用区切りトークン構成

推論プロセスを特定の特殊トークンまたはチャンネル的区切り文字で分離する構成です。
  • 対象モデル: Ministral-3-Reasoning([THINK]...[/THINK])、Gemma 4(<|think|> または thought チャンネル)
  • 特徴:
    • 特殊トークン(Special Token)としての区切りが厳密に定義されています。
    • 標準的な <think> 用パーサーの流用が困難な場合があります。

13.3 マルチチャンネル / Harmony構成

推論およびツール呼び出しをテキストタグではなく、独立した通信プロトコル上のチャンネルとして扱う構成です。
  • 対象モデル: gpt-oss-120b、LLM-jp-4-thinking
  • 特徴:
    • Reasoningプロセス: analysis チャンネルを使用
    • ツール呼び出し: commentary チャンネルを使用
    • 最終回答: final チャンネルを使用

14. 横断比較: 推論エフォートのパラメータ仕様

推論の深度(Reasoning Effort)の制御インターフェースは、モデルによって以下のパターンに分類されます。

14.1 プロンプト露出型(多段階指定)

  • 対象モデル: gpt-oss-120b、LLM-jp-4-thinking
  • 仕様:
    • low|medium|high の明示的なパラメータ入力をサポートします。
    • 指定値はテンプレートの引数(kwargs)として渡され、合成されたシステムメッセージ内に Reasoning: high の形式で直接展開されます。
    • パーサーおよびサービング環境はHarmony仕様を前提とする構成が一般的です。

14.2 二値トグル型(有効化 / 無効化)

  • 対象モデル: GLM-5、Kimi K2.5、Qwen3.5、Gemma 4
  • 仕様:
    • 推論の深度ではなく、Reasoningチャンネル自体の出力有無を制御します。
    • 代表的なパラメータ設定として、enable_thinking=Falsethinking.type=disabled を使用します。

14.3 モード列挙型

  • 対象モデル: DeepSeek-V3.2
  • 仕様:
    • APIインターフェース上において、thinking_mode="thinking"|"chat" のようなEnum値としてモードを選択します。
    • 推論履歴の圧縮制御については、独立したパラメータ(drop_thinking)によって管理されます。

14.4 静的構成(固定型)

  • 対象モデル: Phi-4-reasoning、オープンウェイト版 Ministral-3-Reasoning
  • 仕様:
    • プロンプトテンプレート内にReasoning形式が静的に定義(ハードコード)されています。
    • 外部パラメータから推論深度(Effort)を動的に調整するユースケースは想定されていません。

15. 横断比較: ツール呼び出しの構文仕様

各モデルにおけるツール呼び出し(Tool Calling)の書式は、アーキテクチャに基づき以下の4つの主要なパターンに分類されます。
  • XML / 疑似XML型: <tools><tool_call>などのXMLライクなタグを利用して定義します。該当モデルは、GLM-5、Qwen3.5、およびDeepSeek-V3.2(DSML)です。
  • 専用特殊トークン型: モデル固有の特殊なシステムトークン(例: <|tool|>)を利用して構造を定義します。該当モデルは、Kimi K2.5、Gemma 4です。
  • 区切り文字列(Delimiter)型: [AVAILABLE_TOOLS]のような特定の文字列を使用してブロックを区切ります。該当モデルは、Ministral-3-Reasoningです。
  • プロトコル / チャネル型: メッセージを論理的なチャネルに分割して処理する高度な構成です。該当モデルは、gpt-oss-120b、LLM-jp-4-thinkingです。
Note: ツール呼び出し対応のサーバーを実装する際、OpenAI互換のJSON形式(messages, tools, tool_calls)のみを基準とすることは推奨されません。実際にモデルに入力される構文仕様はモデルごとに大きく異なるため、バックエンド側でモデル専用のパーサーを実装する必要があります。

16. 実装時のベストプラクティスと留意事項

各モデルをシステムへ組み込む際の技術的な留意事項および制約を以下に示します。

16.1 テンプレートの互換性に関する制限

Reasoning(推論)機能を持つモデル間であっても、プロンプトテンプレートの互換性は極めて限定的です。GLM、Qwen、DeepSeekは共通して<think>タグを使用しますが、ツール呼び出しの構文、履歴圧縮のアルゴリズム、および生成プロンプトの構築方法はそれぞれ異なります。

16.2 Harmony系モデルの取り扱い

gpt-ossおよびLLM-jpに代表されるHarmony系モデルは、他のモデルとは根本的に異なるアーキテクチャを持ちます。単純な<think>タグのテキストパーサーを流用するのではなく、チャネルを認識する専用のプロトコルスタックとして実装する必要があります。

16.3 推論機能とエフォートパラメータの分離

Reasoning機能の有無と、推論の深さ(Effort)を制御するAPI仕様は、モデルの系統に依存します。
  • 推論機能あり・Effort指定なし: Phi-4、Ministral(オープンウェイト版)、DeepSeek(thinking mode)
  • 推論機能あり・有効化/無効化の二値制御: GLM、Kimi、Qwen、Gemma
  • 推論機能あり・多段階のEffort指定あり: gpt-oss、LLM-jp、Mistral API(マネージド版)

16.4 コンテキスト履歴の再投入仕様

過去の対話履歴(Reasoningコンテンツ)の保持、または破棄に関する挙動は、以下の通りモデルごとに異なります。
  • 推論時に履歴から思考過程を破棄: gpt-oss、LLM-jp、Kimi、Qwen、DeepSeek(drop_thinking=Trueパラメータ指定時)
  • 明示的なパラメータによる保持: GLM(clear_thinking=falseパラメータ指定時)
  • 固定システムプロンプトによる制御: Phi-4

17. 補遺: 本ドキュメントの適用対象外モデル

以下のモデルは、本調査時点においてReasoningに関する固有仕様が確認できなかったため、比較対象から除外しています。
  • Llama 4: Instructモデル(meta-llama/Llama-4-Scout-17B-16E-Instruct等)の存在は確認されていますが、Reasoning専用のチャットテンプレート、Effort仕様、およびツール構文の公開情報は確認されていません。
  • OLMo 2: 通常のチャットテンプレート(allenai/OLMo-2-1124-13B-Instruct等)は提供されていますが、Reasoningに特化したテンプレートやEffortパラメータの仕様は公開されていません。

18. 総括

本ドキュメントにおける各モデルのアーキテクチャ特性に基づく分類は以下の通りです。
  • テキストベースのReasoning表現が最も明確なモデル群: GLM-5、Kimi K2.5、Qwen3.5、DeepSeek-V3.2、Phi-4-reasoning
  • プロトコル指向であり専用のパーサー実装を要求するモデル群: gpt-oss-120b、LLM-jp-4-thinking
  • 独自のツール構文を持ち、パーサー実装の難易度が高いモデル群: DeepSeek-V3.2(DSML)、Gemma 4、Kimi K2.5
  • Reasoning EffortのAPI仕様が明示的なモデル群: gpt-oss-120b、LLM-jp-4-thinking、Mistral(マネージドAPI版)

19. 関連リソース

各モデルの仕様を定義する公式アーティファクトおよびドキュメントへのリンクは以下の通りです。

gpt-oss-120b

LLM-jp-4-thinking

Gemma 4

DeepSeek-V3.2

Qwen3.5

Kimi K2.5

Phi-4-reasoning

GLM-5

Mistral 3 系

補遺対象