llama.cpp b11377: JSON Schema 出力をパーサー固有の契約として扱う

影響を受ける契約は「JSON を返せる」より狭い

2026年10月3日公開の llama.cpp b11377 は、広い互換性を約束する安定版ではなく prerelease である。関連する pull request #29813 には、Ling 3.0 パーサーが以前は tool call 用の grammar だけを構築し、inputs.json_schema を処理していなかったとある。リリースは、その場合の response_format リクエストは制約されていなかったと説明する。マージされた commit 9bf55f4 は、tool より先に response-format 用 grammar の経路を置き、thinking が有効なら JSON の前に思考ブロックを閉じることを要求し、JSON の後ろの文章を許さないようにした。

これはパーサー固有の信頼性変更である。llama.cpp の全モデル、全テンプレート、全 API クライアント、全 JSON Schema 機能、tool call、エンドポイントが、正しい業務データを返すようになったという意味ではない。現在の server README は、通常の JSON と schema で制約した response_format の両方を記している。しかし互換性については「多くのアプリケーションには十分だった経験がある」と限定し、最適な利用には対応する chat template を持つモデルが必要だとしている。「一回の応答が JSON らしく見えた」ことは、特定の消費側が必要とする schema を parse し、別の検証器で検証する証拠より弱い。

1. 1固定した b11377 と Ling 3.0 template
2. 2一つの名前付き schema の response_format
3. 3生の応答

1. 1独立した JSON parser
2. 2schema 検証
3. 3一つの消費側の結果を受理

1. 1不正 JSON、余計な文章、timeout、schema 不一致
2. 2対象状態を拒否
3. 3一つの境界を診断

ここで扱う日付付きの系譜は意図的に狭くした。構造化出力は少なくとも2024年から活発なインターフェース課題だが、本稿は一般的な業界年表をローカルランタイムの根拠に流用しない。この経路で観測できる系譜は、2026年10月1日の pull request、10月3日の merge、10月3日の b11377 prerelease である。それで何が変わったかは特定できるが、古いパーサーや別のパーサーも同じ振る舞いだったという証拠にはならない。

パーサー、モデル、template を一緒に固定する

b11377 はビルド成果物と attestation への参照を含むが、リリースタグだけでは観測した実行の完全な同一性にならない。採用を決める前に、b11377 タグ、解決した成果物の checksum、commit 9bf55f4a3677af697d914d959eaa70f93cfdc494、モデル revision、Ling 3.0 の正確な chat-template 設定、エンドポイント、リクエスト payload、response-format schema、バックエンド、実行基盤を記録する。モデル変更は template の動作を変え得る。template の変更は reasoning text が現れる位置を変え得る。クライアントはサーバーと異なる方法で応答を parse し得る。それらを匿名の「構造化出力バージョン」にまとめると、失敗境界が失われる。

リポジトリに示された MIT license は、リポジトリコードの利用条件表示である。モデル、weight file、データセット、クライアントライブラリ、プロンプトの権利を与えるものではない。security policy は、server 機能を信頼できないネットワークで使わないことを注意し、一部の実験的または信頼できない環境向けの面を対象セキュリティ項目から外している。これはプロジェクトの方針であって、b11377 や手元のサービスを安全と評価したものではない。

このフィクスチャはローカルで、機密データを含めずに行う。agent や tool 実行を有効にせず、ファイルシステム、ブラウザ、認証情報、審査していないリモート MCP command を渡さない。server README は、tool/agent mode が API を通じたファイル read/write を公開し得ること、CORS のデフォルトを変えることを明記している。JSON 制約が統制するのは出力の構文であって、操作の認可、prompt injection の防止、モデルプロセスの隔離ではない。

未実行で、境界を固定したフィクスチャ

以下は独自の未実行演習であり、b11377 の手順を検証済みと述べるものでも、適合結果を主張するものでもない。対象は一つの具体的な消費側だけで、汎用 schema wrapper は導入しない。

1. 隔離環境で確認済みの b11377 成果物を取得し、checksum を固定する。意図した Ling 3.0 設定だけを loopback listener で起動する。リクエストを送る前に、たとえば10秒の短い client timeout と固定した request-size 上限を記録する。timeout は失敗した観測であり、別のパーサーへ再試行してよい根拠ではない。
2. 消費側が実際に必要とする小さな schema を一つ定義する。たとえば、必須の文字列 decision を allow または deny に限定し、必須の整数 confidence を0から100に限定する。正しい fixture request と、意図的に矛盾または不正にした request を分ける。どちらも本番判断ではない。
3. 文書化された schema 制約付き response_format で各 request を送る。機密でない生 bytes、HTTP status、経過時間、正確な server/template identity、validator の出力を保存する。最初に JSON として parse し、その後モデルクライアントの外で同じ schema を検証する。正規表現が波括弧を見つけただけの文字列を受け入れてはいけない。
4. client timeout、非成功 status、parse 失敗、消費側が禁じる余計な文章、必須 field の欠落、schema 外の enum、manifest と異なる parser/template があれば、フィクスチャを失敗にする。証拠を残し、一つの条件を変える前に transport、server、template、generation、parser、validator のどこで失敗したかを分類する。

受理結果が表すのは「この固定済み設定が、この二つの記録済み入力で schema-valid output を出した」だけである。正確さ、安全性、tool の認可、throughput、異なるモデルとの互換性を表すものではない。フィクスチャが失敗したなら、その消費側では機能を利用可能にしない。制約なし JSON、別の chat template、第二の runtime、自動 repair 経路へ黙って切り替えてはいけない。

この演習はローカルの計算時間、電力、保存容量、担当者の時間を消費し得る。課金 API や外部モデル upload は必要としないが、運用コストがゼロになるわけではない。明記した timeout と資源上限で止め、機密でない成果物だけを残し、隔離したテスト環境はそのデータ取り扱い方針に従って片付ける。本稿の作成中に、benchmark、schema 適合試験、checksum 検証、security test は実行していない。