LLMのツール呼び出し：オープンソースモデルにおける「M×N問題」の正体

現在、オープンソースのLLMにおける「ツール呼び出し（Tool Calling）」機能には、非常に厄介な「M×N問題」が存在しています。これは、モデル（M）とツール（N）の組み合わせが爆発的に増える中で、それぞれに最適化された独自の実装が必要になり、エコシステムが断片化してしまっている状況を指しています。互換性の欠如が開発者の工数を圧迫し、モデルを乗り換えるたびにツール側のインテグレーションを書き直さなければならない現状について、どう解決すべきかを考える必要があります。

今年のHNでのAI関連投稿の中で、最も的を射た投稿の一つ。誇大広告っぽくないし、議論する価値がある。業界が少なくともある程度標準化されたフォーマットに収束していないのは不思議に思うけど、あらゆる進歩があってもまだ初期段階ってことなんだろうね。

OpenAIのHarmonyフォーマットがもっと広く普及していない理由を知ってる人いる？それとも、普及するには次のモデル世代を待たないといけない感じかな？

これがそんなに大きな問題なのかイマイチ理解できないんだけど。確かにワイヤフォーマットが標準化されているか、標準的なスキーマ記述があればいいのは分かる。でも、複数のフォーマットを扱うパーサーを書くのって、本当にそんなに難しいこと？モダンなモデルなら、午後一で人気言語用のバインディングを備えた「libToolCallParser」みたいなのを作れそうだし、新しいフォーマットが増えても自動ワークフローで最小限の労力で対応できそう。面倒ではあるけど、「難しい」問題には思えないな。オープンソース界隈が簡単に扱えるライブラリに集約されていないという、どちらかと言えば社会的な問題に見えるんだけど、見落としてるかな？

vllmやsglangみたいな推論サーバーって、この辺のものをOpenAI互換のAPI形式に翻訳してくれないの？

役立つ記事だね。まさに昨晩、GLMのツール呼び出しフォーマットと格闘してたところだよ。UIと一貫して互換性を持たせるためのストリッピングやサニタイズには...本当に楽しませてもらった（笑）

MCPはエージェントとツールの間のワイヤフォーマットであって、モデル自体が呼び出しを出力する時のフォーマットじゃないんだよね。そっちの部分（HarmonyやJSON、XML風のやつ）は依然としてモデル固有のもの。だから記事で説明されているM×Nの問題は、実は2つの問題が積み重なっているんだ。MCPはその下の半分しか解決していない。それに実際、Claude CodeやCursor、Codexは同じMCPツールでも扱いが違う（必須パラメータとか、ツール説明、レスポンスの切り捨てなど）。結局、MCPでコントラクトは提供されても、クライアントのUXという点ではまだ漏れがあるんだよ。

この記事の肝は、トークン構造の解釈が単なる入出力処理の問題じゃなく、「トレーニング時」の懸念事項だってことだよ（もちろん入出力の断片化や非整合性も問題だけどね！）。つまり、モデル開発元のトレーニング担当者がツールや構文の開発プロセスに深く関わる必要があって、それが摩擦や遅延を生んでいるわけ。それに、LLMの構造化入出力のやり方が改善・標準化されたとしても、新しいモデルの開発やトレーニングには時間がかかるから、トレーニング側に反映されるまで数ヶ月から数年のラグが生じるのは必然。かなり厄介な問題だよね……それも、標準化へのインセンティブが低いという話を抜きにしてもね（標準化すると、巨大AIラボは自社の堀やロックイン効果を失うリスクがあるからね）。

素晴らしい記事だけど、サイトの背景のせいでコーヒーをこぼしたと思ってノートパソコンの画面を一生懸命拭こうとしちゃったよ。

それを全部スキップするネイティブな方法は、モデルファミリーごとに一度だけ「隠れ状態」を「トークンや特定の何か」にマッピングする小さな層を学習させることかな。あるいは、一度だけ処理して、使っているモデルの状態を自分が作ったマップに合わせて変換（プロクラスティス分析的）しちゃうとかね。

ツール呼び出しのフォーマットを、実行時に切り替え可能なエングラム層（Deepseekのエングラム論文を参照）に詰め込むのはいい解決策になるんじゃないかな。アイデアとしては、ツール呼び出しのセマンティクスを一度単一の層でエンコードして、必要に応じて注入する感じ。そうすれば、ハーネスプロバイダーはユーザーに対して、モデルロード時に注入する専用のツール呼び出し層を提供できる。どうかな、うまくいく気がする。たいていのオープンソースモデルならエングラム層を注入できると思うけど、どの層に適合させるのがベストかはテストが必要だね。