26Mパラメータに閉じ込められたGemini — Needleが鳴らしたルーター・スペシャリスト時代の号砲

ツール呼び出しは本当に推論(reasoning)なのか、それともよく擬装された構造化出力(structured output)なのか。もし後者であるなら、我々はこの2年間、大きすぎるモデルに単純すぎる仕事をさせ続けてきたのではないか。

導入 — 14メガバイトの指先

2026年5月8日、cactus-computeという小さなスタートアップがHacker Newsに「Show HN: Needle — We Distilled Gemini Tool Calling into a 26M Model」というタイトルの投稿を上げた。24時間で415ポイントを集め、コメントは144件付いた。添付されたGitHubリポジトリは三日間で700個以上のスターを獲得した。発表時点でモデルサイズは26,000,000パラメータ、FP16の重みファイルは約14メガバイト、ライセンスはMIT、学習の出発点はGoogle Gemini 3.1である。

数字だけ見れば奇妙な発表である。2026年春時点のフロンティアLLMが1兆パラメータ単位に突入してから1年以上が経つ。同じ月に公開されたGPT-5.5とClaude Opus 4.6は、いずれもlong-horizon agentワークフローにおけるツール呼び出し精度とバックトラッキングを核心指標として打ち出した。その真っ只中で、誰かが26Mパラメータ — つまりPhi-3 Miniの約150分の1、Llama 3 8Bの約300分の1 — のモデルで「Geminiのツール呼び出しをそのまま真似させた」と主張したのである。

最初は冗談のようにも見えるこの発表が真剣に受け止められた理由は二つある。第一に、cactus-computeは以前からモバイル/エッジ向け推論ランタイムを作ってきたチームであり、Needleは自社SDK上で6,000 tokens/sec prefill、1,200 tokens/sec decodeというフォン親和的な性能数値を引っ提げて登場した。第二に、この発表は過去2年間SLM(Small Language Model)陣営がぶつかり続けてきた壁 — 「小さなモデルはツール呼び出しで馬鹿げたハルシネーションを起こす」 — をピンポイントで狙い撃ちしている。

この出来事の含意は単純ではない。モバイルデバイス上でLLMが動作するという話は2024年のApple Intelligence発表以来陳腐な話題になったが、「エージェントがモバイルデバイスで動作する」という話は別物である。Needleがやることは結局一つだ。ユーザの自然言語発話を受け取り、適切な関数名と引数をJSONで吐き出す。その単純な仕事がもし26Mパラメータで足りるのなら、我々が今まで100B、1Tモデルにやらせていた仕事の相当部分は非効率の結果だったということになる。

本文1 — Needleは何をやったのか、そして何ができないのか

まず事実関係を整理しよう。NeedleのGitHub READMEによれば、このモデルは「Simple Attention Network」と名付けられた変形トランスフォーマー構造を採用する。12個のエンコーダレイヤと8個のデコーダレイヤ、各デコーダレイヤに8個のアテンションヘッドと4個のKV(key-value)ヘッド、埋め込み次元512、語彙サイズ8,192 BPEトークン。最も際立った特徴は、エンコーダレイヤにFFN(feed-forward network)が存在しないという点である。この決定の根拠を著者らはREADMEに直接書いている。「Cactusでの実験は、モデルが外部知識ソースに依存しさえすれば、トランスフォーマーネットワークからMLPを完全に取り除いてもよいことを示した(Experiments at Cactus showed that MLPs can be completely dropped from transformer networks, as long as the model relies on external knowledge source)」。

この一行が含意するところは大きい。トランスフォーマーにおいてFFNは通常「知識の貯蔵庫」の役割を担うとされる。アテンションがトークン間の関係を作るのに対し、FFNはその関係の上に事実情報を載せる。Needleはツール呼び出しという仕事が「プロンプトの中に既に必要な情報(使用可能なツールの名前とシグネチャ)が全て入っている」仕事であることを狙い、FFNを丸ごと抜き取った。これが26Mという数字が出てくる核心の仕掛けである。

Hacker Newsのコメント欄でfizza_pizzaというユーザがまさにこの点を突いた。「検索タスクでFFNが要らないという観察が興味深い。本質的には、知識がコンテキストの中にあるならFFNの重みはそのタスクに対して冗長だという主張だ。これが、モデルが複数の呼び出しにまたがって状態を追跡しなければならないマルチターンのツール呼び出しにも一般化するのか、それともそこで崩れるのかが気になる(The ‘no FFN for retrieval tasks’ observation is interesting essentially arguing that if the knowledge is in the context, FFN weights are redundant for that task. Curious whether this generalizes to multi-turn tool calling where the model needs to track state across several calls, or if it breaks down there)」。これは核心を突く問いである。そしてcactus-computeの答えはREADMEに既に書かれている。Needleは「single-shot function call」に特化していると明記された。すなわち、一度のユーザ発話に対して一度のツール呼び出しを選び引数を埋める仕事までが約束の範囲である。

性能比較は相対的な形で提示された。著者らは「single-shot function callにおいてFunctionGemma-270m、Qwen-0.6B、Granite-350m、LFM2.5-350mを上回る」とのみ書いている。BFCL(Berkeley Function Calling Leaderboard)のような標準ベンチマークのスコアは発表時点で公開されていない。この部分はコメントでmeander_waterが正確に指摘した弱点である。「Gemma4のエッジモデルがエージェント用途に良いと約束されていたが、私のテストでは最も基本的なツール使用シナリオでさえ失敗した。Needleについてツール使用ベンチマークを回したか、回す予定はあるか?結果をリポに上げてくれると嬉しい(Have you run any tool-use benchmarks for Needle, or do you plan to? Would be great if you could add results to the repo)」。発表が生み出す興奮と学術的検証との時間差を示すコメントである。

もう一つ興味深いコメントはvarencのものだ。「Googleがこの作業にどう反応するか心配ではないか?Googleは蒸留の試みに対して、学生モデルの性能を低下させ得るリアルタイムの能動防御で対応すると報告されている。だからもし彼らが君らを検出していたら、意図的にもう少し馬鹿だが妥当に見えるGemini変種を食わせていた可能性もある(Google reportedly reacts to distillation attempts with real-time proactive defenses that can degrade student model performance)」。この発言はGoogleの公式脅威インテリジェンスブログの文言を直接引用したものである。この懸念に対してcactus-compute側は直接答えていないが、二点指摘できる。第一に、Needleはツール呼び出しという狭い仕事に限定された蒸留であり、Googleのビジネスの核心を脅かさない。第二に、ツール呼び出しの期待される出力はJSONスキーマという外部検証可能な形式である。すなわち「もっともらしいが微妙に壊れている」学習データがあったなら、学生モデルの出力自体がパースできなかった可能性が高い。ツール呼び出しは自然言語要約とは異なり、間違っているときにそれが間違っていることを即座に判定できる仕事なのだ。

学習データ生成とライセンスに関しては微妙なグレーゾーンが残る。著者らは自分たちがどのAPI規約のもとでGeminiの出力を取得したのか明示しておらず、現時点でのGoogle APIの利用規約は「Googleモデルと競合するモデルの学習目的で出力を使用すること」を禁ずる条項を含む。Needleがその条項にどう適合するのかは発表だけでは不明瞭だ。これは蒸留陣営全般に共通する未解決の課題であり、Needleはそのグレーゾーンの上に発表された最初の意味あるツール呼び出しモデルという位置づけになる。

要約すれば、Needleは「ツール呼び出しという狭い仕事」を「プロンプト依存的な構造化出力」として再定義した上で、その定義に合わせてトランスフォーマー構造そのものを削り落とすという方法でモデルサイズを二桁メガバイト単位まで引き下げた。マルチターン推論や新規スキーマへの一般化は約束しない。しかしその狭い約束自体が持つ意味は決して小さくない。

本文2 — なぜツール呼び出しは蒸留できるのか、推論はなぜできないのか

Needleの発表を受け止めるうえで最大の精神的障壁は、我々が過去2年間「ツール呼び出しも結局は推論の一部だ」と仮定してきたことにある。ReActパターン、ChatGPTのfunction calling、Anthropicのtool use、OpenAI Assistants API — これらすべてのインターフェースはツール呼び出しをモデルの思考(thought)の流れの中に深く埋め込んだ。結果として、ツールをうまく呼べるモデルがうまく推論できるモデルであり、その逆も成り立つという直観が固まった。

Needleはこの直観をひっくり返す。ユーザの発話「What’s the weather in San Francisco?」とツールシグネチャget_weather(location: string)が与えられたとき、出力{"name":"get_weather","arguments":{"location":"San Francisco"}}を作る仕事は、推論というよりはパターンマッチングである。より正確には、自然言語のスロットから関数引数のスロットへの写像(mapping)作業である。この仕事でモデルが解かなければならないのは「サンフランシスコの今日の天気が曇りかどうか」ではなく、「サンフランシスコ」というトークン列がlocation引数に入る適切な値であるという事実の認識である。

ここにツール呼び出しの第二の特徴が結び付く。出力の形式が厳格に定義されているという点だ。JSONスキーマはモデル出力に対する外部検証関数を提供する。間違った出力はパース段階で即座に弾かれる。自然言語応答が「もっともらしいが間違っている」答えを生み出し得るのとは異なり、ツール呼び出しは「構文的に正しいか間違っているか」という二値判定を受ける。このような仕事に対してRLHFは報酬信号がきれいに定義され、学習効率が飛躍的に高まる。これが結局、26Mという小さなパラメータ予算の中に十分な能力を押し込められた第二の要因である。

HNコメント欄のjumploopsがこの点を別の角度から突いた。「Sonnetはしばしばより多くのコンテキストを集めるためにツールを素早く呼ぶ一方、Opusは自分が持っているコンテキストで問題を解こうとしてより長く推論する。(…) 私の結論は、『より馬鹿な』(つまりより小さい)モデルがエージェントハーネスとしてはより良いかもしれない、少なくとも大きな範囲の問題に対しては実現可能なほど安く速く動かせる、ということだ(My takeaway was that ‘dumber’ (i.e. smaller) models might be better as an agentic harness, or at least feasibly cheaper/faster to run for a large swath of problems)」。この観察はNeedleの仮説と正確に一致する。大きなモデルはツールを呼ぶ前に長く考えすぎ、その結果として同じ関数を二度定義したり、すでに呼んだツールを再び呼んだり、ユーザが訊いてもいない副次作業をしてしまう傾向がある。

この分離をアーキテクチャ的に表現するとルーター・スペシャリスト(router-specialist)構造になる。小さなモデル — ルーター — がユーザの発話を受けて「これはコード検索ツールで処理せよ」とか「これはカレンダー追加ツールで処理せよ」と決定すると、そのツールの結果を受けて自然言語応答を生成する大きなモデルが別に動作する。あるいはより極端には、ツールの出力自体がユーザに直接返される形態も可能だ。この分業構造においてルーターはわざわざ推論する必要がない。そしてルーターが推論する必要がないなら、ルーターはモバイルデバイスに収まる。

ここでNeedleの発表が真に衝撃的である理由が浮かび上がる。26Mという数字は単なる小さなモデルではなく、「ルーターは本当にモバイルフォンのNPU上で動作できる」という命題の最初の実証である。6,000 tokens/sec prefill数値は1,000トークンのツールシグネチャコンテキストを0.2秒以内に処理することを意味し、1,200 tokens/sec decode数値は100トークンのJSON出力を0.1秒以内に吐き出すことを意味する。ユーザが話し終えた時点から関数呼び出しが始まるまでの遅延が0.3秒以内なら、それは人間が知覚できない遅延である。

ただしこの絵には決定的な但し書きが付く。ルーターが間違ったツールを選んだとき、その間違いに気づけるメタ認知能力は小さなモデルには存在しない。nlというコメント投稿者がまさにこの点を指摘した。「私の質問は曖昧さの処理にどれほど効くかだ。『明日10時にコーヒーで追いつこう』というテキストメッセージと『これを保存して』という命令を一緒に送ったとき、何百個(あるいは何十個)もの可能なツールの中から『add appointment』アクションを選ぶことができるか(Can I send it something like a text message ‘lets catch up at coffee tomorrow 10:00’ and a command like ‘save this’ and have it choose a ‘add appointment’ action from hundreds (or even tens) of possible tools)?」。この問いに対する正直な答えは「Needleには無理だ」である。ツールプールのサイズが大きくなるほど、そしてユーザの意図が曖昧になるほど、蒸留モデルの限界が露わになる。

この限界は蒸留一般の本質的な弱点である。学生モデルは教師モデルが見た分布の中でしか信頼できる動作をしない。新しいツールシグネチャ、新しい引数の型、新しい呼び出しパターン — これらすべてには追加のfine-tuneが必要だ。cactus-computeがREADMEで「テスト後は自前のツールに対してfine-tuneすることを推奨する」と書いている部分は、単なるユーザガイドではなく、蒸留モデルの本質に対する正直な告知である。

本文3 — エッジエージェントの未来、そしてそれが意味する分業

Needleのようなモデルが定着すると何が変わるのか。三つのシナリオを描いてみよう。

第一に、オンデバイスアシスタントの真の意味の変化である。これまでのモバイルアシスタント(Siri、Google Assistant、Bixby)は実際にはクラウドアシスタントだった。音声認識と意図分類はデバイス上で行えても、その意図を適切な作業に写像する推論段階はクラウドで起きていた。Needle系のモデルはその写像段階そのものをデバイスへ持ち込む。結果として「機内モードでも動作するアシスタント」「帯域幅ゼロの環境でカレンダーに予定を追加するアシスタント」が可能になる。これはAppleのApple Intelligenceが2024年に約束したが部分的にしか達成できなかった未来である。

第二に、CLIツールの新しいインターフェース層である。これはilakshというコメント投稿者が興味深く突いた部分だ。「これはひょっとすると、引数を自然言語でオプション指定できるコマンドラインプログラムを作ることを実現可能にするかもしれない。(…)『> toolcli what can you do』が『toolcli —help summary』を実行し、『toolcli add tom to teamfutz group』が『toolcli —gadd teamfutz tom』になるような形だ(this might make it feasible to build something like a command line program where you can optionally just specify the arguments in natural language. E.g. ’> toolcli what can you do’ runs ‘toolcli —help summary’)」。このシナリオは、14メガバイトのモデルをすべてのCLIバイナリに同梱して配布することが合理的になる最初の時点を指している。同じコメント投稿者が付け加えた懸念 — 「すべてのCLIがそれをやり始めたらかなり悪いことになり得る」 — も正当である。しかしその懸念は同時に、このモデルが本当に多様な場所に組み込まれ得る臨界点に達したという信号でもある。

第三に、プライバシーとエージェントの和解である。これまでエージェントの最大の採用障壁はデータの露出だった。コーディングエージェントがコードを見るということはコードがクラウドに上がるということであり、個人アシスタントがメッセージを見るということはメッセージが他社のサーバで処理されるということだった。ルーター・スペシャリスト構造はこの問題を部分的に解決する。ルーターがデバイス上にあれば「どのツールを呼ぶか」という決定そのものは外部に出ない。ツール自体がクラウドAPIを呼ばなければならないならその時点でデータが外部へ出るが、少なくともユーザの意図はデバイスの中にとどまる。

ただしこの絵全体に対する懐疑もまた正直に押さえておくべきだ。binyang_qiuというコメント投稿者の一行がその懐疑をきれいに表現している。「多くのエージェントワークフローは事実上、ツール選択 + 引数抽出 + 構造化出力にすぎない。ワークフローがマルチステップになり、呼び出しの間に状態が積み上がり始めるとどう振る舞うのか(How does this behave once workflows become multi-step and state starts accumulating across calls)?」。この問いは、Needleのようなモデルが適合する領域と不適合な領域を分ける決定的な基準を指している。適合領域は「単一発話 → 単一ツール呼び出し → ユーザに結果返却」という短いループだ。不適合領域は「複数のツールを連鎖的に呼び、ツール出力が次のツールの入力になる」長いループである。後者は依然として大きなモデルの領分として残る。

技術的にこれを言い換えれば、Needleはエージェントシステムの「最前段」 — ユーザの意図をツール空間にマップする最初のホップ(hop) — に入るモデルである。その後ろに何が来るかはシステム設計者の自由だ。別の小さなモデルかもしれないし、大きなクラウドモデルかもしれない。重要なのは、その最初のホップがデバイス内に入ってきたという点であり、その結果としてシステム全体の遅延、コスト、プライバシーのカーブが描き直されるという点である。

結論

ツール呼び出しは本当に推論なのか。Needleの発表はこの問いに否を突きつける。少なくともツール呼び出しの最も基本的な形態であるsingle-shot function callは推論ではなく、よく擬装された構造化出力である。それは自然言語のスロットを関数引数のスロットへ写像する作業であり、その作業の報酬関数はJSONパーサを通るかどうかという二値信号できれいに定義される。このような仕事に対して、26Mパラメータは十分な予算である。

これが意味する分業は明快だ。推論が必要な領域 — マルチステップの計画、曖昧な意図の解釈、ツールプールが動的に変わる環境 — は依然として大きなモデルの取り分である。しかしユーザ意図の最初のマッピング、ツール呼び出しの単一ホップ、引数の抽出といった作業は、もはやデバイス上で実行できる。我々は過去2年間、大きすぎるモデルに単純すぎる仕事をさせ続けてきた。Needleはその非効率の請求書をついに可視化した。

cactus-compute単独でこの未来を作るわけではないだろう。Apple Intelligenceの次バージョン、Googleの次世代Gemini Nano、そしてオープンソース陣営の後続蒸留モデルたちが同じ道を辿る可能性が高い。しかしその流れの最初の意味ある座標を打ち立てた発表が、26Mパラメータ、14メガバイト、MITライセンスという条件で出てきたという点は記憶しておく価値がある。巨大資本がなくても、狭い仕事に十分狭くアプローチすればフロンティアモデルの一つの能力をフォンの中に持ち込めるという証明である。そしてこれは、LLM時代に入って初めて「スケールが正解ではない」最初の仕事が明示的に切り分けられた瞬間でもある。