ローカルLLMに載せ替える前に考えるべきこと：APIプロバイダーが作りこんでいる周辺機構の分析
はじめに
オープンウェイトのLLMでも、最近は先端モデルと遜色ないものが多く登場しています。しかし、実際に社内のGPUで動かしてみると、簡単な問い合わせなら、APIで使っていたときと遜色ない答えが返ります。ところが、資料を検索して引用させたり、途中で計算をさせたり、決まった形式のJSONで返させようとすると、API経由のときほど安定しません。同じモデルの重みなのに、なぜ差が出るのでしょうか。
答えは、モデルの外側にあります。ChatGPTやClaudeのようなAPIを叩いて返ってくる品質は、モデルの重みだけで決まっているわけではなく、その周りでプロバイダーが動かしている周辺機構（harness、モデルを実運用で使うための足回り）込みの結果です。重みをダウンロードして手に入るのは、この構造の中心にある一つだけで、周りの層は付いてきません。
オープンウェイトモデルのガードレールは剥がせるという記事で、クローズドAPIの安全性が学習時のアラインメントだけでなく推論時のフィルタや契約に支えられていて、その多くはローカルには移らないことを整理しました。同じ構造は安全性に限りません。性能を作っている足回りも、大半がモデルの外にあります。この記事では、その周辺機構に何があるのかを一つずつ棚卸しし、ローカルに載せ替えるときに自分で組むことになるのはどこかを整理します。
対象読者:
- ローカルLLM・オープンウェイトモデルへの移行を検討していて、「重みがあればAPIと同じ」と見込んでよいか判断したい方
- 自前のLLM基盤に何を組み込むべきか、構成要素を一望したい方
- APIの便利さがどこから来ているのかを、構造として理解したい方
記事のポイント:
- APIの1リクエストの裏で動いている周辺機構を、入力・推論・ツール実行・出力・運用の5つの位置で整理します
- 各機構が何をしていて、無いと何が起きるか、自前で組むならどのOSSが対応するかを一覧にします
- トークン単価だけで載せ替えを判断する落とし穴と、載せ替え前に確認すべき点を示します
APIの1リクエストの裏で動いているもの
APIに1つのプロンプトを送って答えが返るまでの間には、モデルの推論以外にいくつもの処理が挟まっています。位置ごとに見ていきます。
まず入力側です。プロンプトはそのままモデルに渡っているわけではありません。プロバイダーが用意したシステムプロンプトが前に付き、必要なら関連文書を検索して文脈に足し（retrieval、いわゆるRAG）、使ってよいツールの定義が差し込まれます。入力を検査して、扱えない依頼をここで弾く仕組みも入ります。
推論側を見ると、1回生成して終わりとは限りません。同じ入力から複数回サンプリングして良いものを選ぶ、答えを出す前に思考を長く回す（test-time compute、いわゆる推論時の追加計算）といった工夫が、品質を押し上げています。温度やトップpといったデコーディングの設定も、用途に合わせて調整されています。
ツール実行はモデルの外の仕事です。モデルが「このコードを実行したい」「これを検索したい」と出力したとき、それを実際に走らせて結果をモデルに戻すのは、外側の実行環境です。コードのサンドボックス、Web検索、外部APIの呼び出しと、その結果を受けて次の生成に進むループが、エージェント的な動作を成立させています。
出力側でも、生成された文字列がそのまま返るとは限りません。決まったスキーマのJSONに収まるよう生成を制約し（構造化出力）、整形や後処理をかけ、有害な出力がないかを別の分類器で最終確認します。
運用側には、重みを速く、かつ精度を落とさずに動かす推論基盤があります。量子化やバッチ処理、KVキャッシュといった最適化がここに当たります。加えて、モデルは継続的に更新され、挙動は監視され続けています。
これらを一覧にすると、次のようになります。自前で組むときに対応するOSSも並べますが、この領域は動きが速いので代表だけを挙げます。
| 位置 | 主な機構 | 無いと起きること | 対応するOSSの例 |
|---|---|---|---|
| 入力 | システムプロンプト、retrieval・RAG、ツール定義の注入 | 文脈が足りず的外れになる、根拠を引けない | LlamaIndex、Haystack |
| 推論 | 複数回サンプリング、長考、デコーディング設定 | 1回の生成に頼るため出力が安定しない | vLLM、SGLang |
| ツール実行 | コード実行、Web検索、外部API、結果を戻すループ | 計算・最新情報・外部操作ができない | LangGraph、smolagents |
| 出力 | 構造化出力、整形、安全分類器 | 形式が崩れて後段が壊れる、有害な出力が検査されず通る | Outlines・Guidance、Llama Guard・NeMo Guardrails |
| 運用 | 量子化・バッチ・KVキャッシュ、更新、監視 | 遅い・費用がかさむ、劣化に気づけない | vLLM・SGLang、Langfuse |
一覧にすると、モデルの推論そのものは全体の一部分でしかないことが見えます。APIで得ていた品質の相当部分は、この周辺機構が担っていました。
ダウンロードできるのは重みだけ
重みをダウンロードして手に入るのは、この構造の中心にある1つだけです。周りの機構は、重みのファイルには含まれません。
つまり載せ替えとは、モデルを1つ用意することではなく、上の表の残りをどこまで自前で用意するかを決める作業です。全部を自前で組めば、原理的にはAPIに近い構成になります。ただし、プロバイダーは同じ部品をあらかじめ統合し、自社のモデルに合わせて調整したうえで渡してきます。同じOSSを並べても、組み合わせとチューニングは自分の仕事として残ります。
単純な分類や要約なら、重みを推論サーバに載せるだけで足りることもあります。一方、資料を引きながら多段で処理させたいなら、retrievalもツール実行も構造化出力も要ります。表のどの行が自分のタスクに必要かで、作る範囲が決まります。
コストもトークン単価だけでは測れない
コストの見え方にも、同じ落とし穴があります。ローカルなら自前のGPUなので、トークンあたりの単価は一見すると安く、固定的に見えます。ここだけを見て「APIより安い」と判断するのは危険です。
課金の単位はトークンでも、意思決定の単位はタスクです。1つのタスクを解ききるのに何トークン使うかは、周辺機構の出来で変わります。周辺機構が弱いと、同じタスクでも失敗してやり直したり、多めにサンプリングして選んだりで、消費するトークンが膨らみます。トークン単価が安くても、1タスクあたりのトークンが増えれば、タスクを1件仕上げるまでの費用は逆転することがあります。比べるべきは、トークンの単価ではなく、タスクを1件仕上げるまでの総額です。
さらにローカルでは、GPUの費用は使っても使わなくても発生します。稼働率が低いと、処理した1タスクあたりの費用はそのぶん高くなります。単価表の数字ではなく、自社の想定タスク量で割り戻した実際の額で見ないと、判断を誤ります。
変化の速さも引き受けることになる
周辺機構を組み上げれば終わり、ではありません。この領域は入れ替わりが速く、その追従も自社の仕事になります。
例えば推論サーバの定番だったHugging FaceのTGI（Text Generation Inference）は、2026年3月にアーカイブされ、メンテナンスモードに入りました。いま主流のvLLMやSGLangも機能と性能の更新が続いていて、去年組んだ構成が今年も最適とは限りません。監視まわりのように、まだ穴の残る部分もあります（並行実行でトレースの一部が欠ける、といった問題が知られています）。
APIを使っているあいだ、こうした追従はプロバイダーが吸収していました。自前で組むと、部品の保守とバージョン追従、壊れた箇所の切り分けが、運用として乗ってきます。安全性・性能に続く3つ目の「移ってくるもの」が、このエコシステムへの追従コストです。
載せ替える前の棚卸し
移行を検討するなら、モデルの性能を比べる前に、自分のタスクが周辺機構のどれを必要とするかを棚卸しするところから始めます。やることは3つあります。
1つ目は、APIで測った品質を、モデル単体の品質と勘違いしないことです。可能なら、周辺機構を外した素の重みでも同じタスクを試し、どれだけ差がつくかを見ます。2つ目は、表のどの行が自分のタスクに要るかを選び、それぞれを自前で用意する工数を見積もることです。多くのタスクで要になるのは、モデルの性能そのものより、retrievalとツール実行と構造化出力の作り込みです。3つ目は、コストをトークン単価ではなく、想定タスク量で割ったタスクあたりの総額で比べることです。
この棚卸しをすると、「重みがあるからAPIと同じ」という当初の見込みが、「重みは手に入る、残りは自分で組む」に置き換わります。載せ替えの是非は、モデルの優劣ではなく、この残りを引き受けられるかで決まります。
まとめ
APIの1リクエストの裏では、入力の準備、推論時の工夫、ツールの実行、出力の整形と検査、それを支える推論基盤と監視が動いています。ダウンロードで手に入るのは中心の重みだけで、この周辺機構は付いてきません。ローカルへの載せ替えは、モデルを1つ選ぶことではなく、周りの足回りをどこまで自前で組むかを決めることです。
自前で組むための道具はOSSとして揃っていますが、プロバイダーのように統合・調整された状態では手に入らず、エコシステムの速い変化に追従する運用も自社に残ります。
移行を考えているなら、まず手元のタスクを1つ選び、それをAPIで処理したときに裏で何が働いているかを、この記事の表と突き合わせてみてください。retrievalが要るのか、ツール実行が要るのか、構造化出力が要るのか。ここで挙がった項目が、重みを落としたあとに自分で用意するものです。モデルの優劣を比べるのは、その規模が見えてからでも遅くありません。
