オープンウェイトモデルにおけるツールコールの品質向上：制約付きデコーディングによる 100% スキーマ正確性の達成

著者：Jesse Donkervliet と Junhao Li（シニアソフトウェアエンジニア）
日付：2026 年 10 月 20 日

オープンウェイトモデルを利用する際、取得される成果が品質ベンチマークで示される水準に程遠いと感じることはありませんか？

本記事では、ツールコールの正確性と**制約付きデコーディング（constrained decoding）**について解説し、エージェント系ワークロードにおける品質を確保するための実装戦略を共有します。

---

ツールコールスキーマとエージェント開発

ツールコール（機能呼び出し）の正確性は、オープンウェイトモデルを提供する上で極めて重要です。

エージェント系ワークロードでの課題

• 不正確なツールの影響: ツールコールが不正確であれば、モデルは意味をなさない文脈データを蓄積します。
• 低品質の結果: これにより、マルチターンセッションやエージェント系ワークロードにおいて特に低品質な結果が生み出されます。
• 既存プロバイダーの課題: 多くのプロバイダーや推論エンジンでは、ツールコールの正確性に関するテストを完全にパスできていません。

vLLM と Kimi K2.6 の事例

• vLLM 0.28 バージョンでの実績: Kimi K2.6 を提供した際、期待されるツールコールスキーマが正常に取得できたのは約 92% のみでした。
  • 言い換えれば、試行したツールコールのうち 4 に 1 は失敗していました。
• 解決策の登場: vLLM は直近で「制約付きデコーディング（constrained decoding）」という技術をサポートするようになり、これにより 100% のスキーマ正確性を獲得することが可能になりました。
  • 現在：vLLM 0.31 バージョンよりサーバーサイドフラグとしてリリースされています。

---

ツールコールスキーマの仕組み

LLM に外部ツールの呼び出しをさせるには、以下の 2 つのステップが必要です。

1. AI モデルに対して、利用可能な外部ツールの存在を通知する。
2. モデルに対し、構造化された形式でツールコールを出力するための指示を提供する。

具体的な構成例（OpenCode と Kimi）

OpenCode は Kimi に利用可能なツールを記述した JSON 配列を送信します。以下は「webfetch」ツールのスキーマの一例です。

[{
  "type": "function",
  "function": {
    "name": "webfetch",
    "description": "- 指定された URL からコンテンツを取得します\n- URL とオプションのフォーマットを入力として受け取ります...",
    "parameters": {
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "url": { "type": "string", "description": "コンテンツを取得するための URL" },
        "format": { 
          "type": "string", 
          "enum": ["text", "markdown", "html"], 
          "default": "markdown" 
        },
        "timeout": { "type": "number", "description": "オプションのタイムアウト時間（秒）" }
      },
      "required": ["url"]
    }
  }
}]

トークン変換プロセス

1. 推論エンジンによるラッピング: JSON 記述は、LLM がツール宣言を認識するためのトークンにラップされます。

   <|im_system|>tool_declare<|im_middle|>[{"type":"function","function":{...}, ...]
   

2. ユーザーからのリクエスト: ユーザーから Web ページ取得の依頼があった場合、LLM は以下のような出力を生成します。

   I'll fetch that page. <|tool_calls_section_begin|><|tool_call_begin|>functions.webfetch:0<|tool_call_argument_begin|>{"url": "https://ubicloud.com", "format": "markdown"}<|tool_call_end|><|tool_calls_section_end|>
   

3. パーサーによる解析: 推論サーバーはトークンを抽出し、コールを JSON オブジェクトに変換してハルネス（例：OpenCode）へ返却します。

   {
     "role": "assistant",
     "content": "I'll fetch that page.",
     "tool_calls": [
       {
         "id": "functions.webfetch:0",
         "type": "function",
         "function": {
           "name": "webfetch",
           "arguments": "{\"url\": \"https://ubicloud.com\", \"format\": \"markdown\"}"
         }
       }
     ]
   }
   

---

スキーマ正確性の重要性

ツールコールが成功するためには、コールは必ずツールのスキーマに準拠していなければなりません。

単純なアプローチの限界

• 手法: モデルによる生成を自由にさせ、トレーニングにより正しいコールが生成されると信頼する。
• 問題点:
  • 文法的に正しい文章を生成する際と同様に、「多くの場合」しか機能しません。
  • 「多くの場合で成功」ということは、多くのツールコールが依然として失敗することを意味します。
• 引き起こされるリスク:
  • エラーメッセージによるコンテキストウィンドウの汚染
  • モデル性能の低下
  • コスト増（エージェントがコールを 1 回以上再試行するため）

品質評価基準：K2VV ToolCall ベンチマーク

Moonshot AI は、Kimi K2.6 の品質を検証するための「K2VV ToolCall ベンチマーク」を発表しました。

• 構成: ツールコール生成タイミングおよび文法正しさを評価する 2,000 件のリクエスト。
• 主要指標:
  1. トリガー類似度（trigger similarity）: サービス側がツールコールのトリガーを判断するタイミングと Moonshot AI のサービスとの類似性。
  2. スキーマ正確性（schema accuracy）: スキーマに準拠し成功して呼び出されるツールコールの割合。

例: スキーマ正確性が 50% の場合、モデルによって生成されたツールコールの半分に破損があることになります。

失敗の主な原因

• 言語モデルの確率的な性質: モデルはトークンの出現可能性に基づいて生成しており、コンパイラーや型チェックを行っていません。
• トレーニングデータと環境の不整合:
  • トレーニングデータに含まれるツール名やフィールド名（例：

    search_web

    ）が、現在のプロダクション環境のスキーマ（例：

    web_search

    ）と異なる場合、エラーが発生します。

---

制約付きデコーディング（Constrained Decoding）による解決

基本概念

• 仕組み: 推論エンジンが生成を段階的にガイドし、各ステップにおいて有効なトークンのみが許可されます。
• 効果:
  • 文法的に無効なツールコールにつながるトークンのサンプリングを防ぎます。
  • 「尽力に基づくアプローチ」から**「ランタイムでの保証」**へと変化します。
• パフォーマンス: トークンマスクを事前計算し GPU で効率的に適用するため、わずかなオーバーヘッドしかありません。

実装例（vLLM と XGrammar）

vLLM は XGrammar ライブラリの構造的タグを使用して制約付きデコーディングを実装しています。以下は Kimi K2.6 での実装抜粋です。

# Kimi K2.6 のツールコール構文:
# <|tool_call_begin|>{function.name}:{index}
# <|tool_call_argument_begin|>{arguments}
# <|tool_call_end|>
TagFormat(
    begin=f"{TOOL_CALL_BEGIN_PREFIX}{name}{TOOL_CALL_SUFFIX}",
    content=SequenceFormat(
        elements=[
            RegexFormat(pattern=r"\d+"),
            ConstStringFormat(value=TOOL_CALL_ARGUMENT_BEGIN),
            JSONSchemaFormat(
                json_schema=parameters,
                any_order=any_order,
                max_whitespace_cnt=max_whitespace_cnt,
            ),
        ]
    ),
    end=TOOL_CALL_END,
)

有効な経路: ツールコール開始 → ツール名 → ツールコールインデックス → 引数の開始 → スキーマに制約された JSON → ツールコール終了。
無効な経路（例：整数トークン以外）は生成中にブロックされます。

---

制約付きデコーディングの実装における注意点

vLLM の振る舞いに関する課題

Moonshot AI は制約付きデコーディングを推奨していますが、vLLM の初期実装にはいくつかの課題がありました。

問題点と対応策

1. 初期の失敗（vLLM 0.28）:

   • vLLM に機能を追加しましたが、デフォルト設定では正確性スコアが再び 91% に低下しました。
   • 原因：vLLM は幅広いモデルをサポートするため、制約付きデコーディングを明示的にオンにしないリクエストに対してデフォルトの振る舞いを変更していたためです。

2. 特定のモデルでの問題カテゴリー:

   • 汎用モデルの問題: 非制約出力がスキーマから逸脱し、意図しないトークンを選択してしまう場合がある（gpt-oss-20b, Qwen 3.6, GLM 5.1 など）。
   • 文法変換のバグ: モデル固有の文法への変換でエラーが発生し、制約付きデコーディングが無効化される。
   • 機能間相互作用のバグ: 推測的デコーディング（speculative decoding）との連携で失敗するケースがある。

対応と現状

• vLLM の方向転換: 多くの報告から、モデルアグノースティックな vLLM ではデフォルトで無効化とするのが安全な選択となりました。
  • 最新：

    --tool-strict-level

    フラグを追加し、ユーザーが環境に合わせて厳格度を調整可能にしています。
• Ubicloud のアプローチ:
  • vLLM とは異なり、ファーストパーティプロバイダーとして**期待される品質（K2VV ToolCall ベンチマーク 100%）**を提供することに焦点を当てています。
  • 対策: 常に制約付きデコーディングを有効にし、すべての提供モデルで 100% の正確性を確認した後に本番環境に展開しています。

---

結論

LLM を使用する際、観察される品質はモデルそのものだけで決定されるわけではありません。推論エンジンもまた重要な役割を果たします。

• Kimi K2.6 および DeepSeek V4 Flashにおける品質低下の要因：ツールコールスキーマの不正確さ。
• 解決策: vLLM のフォーク版を維持しつつ、新しい制約付きデコーディング機能を明示的に有効化しました。
• 成果: K2VV ToolCall ベンチマークにおけるツールコールの正確性を 92% から 100% に改善することに成功しました。

推論エンジンやその設定を変更することで、モデルの出力品質を劇的に変化させることができます。もしご興味がある方や、モデル提供に関する戦術的知恵（war stories）をお持ちでしたら、サポートまでご連絡ください。