メインコンテンツへスキップ
あなたのローカルモデルサーバーはほぼ確実に一つの形式のみを扱っています:OpenAIのChat Completionsです。Ollama、llama.cpp、vLLM、LM Studioもすべて /v1/chat/completions を提供しています。しかし実際にそのモデルを利用したいクライアントがすべて同じ形式を使っているわけではありません。Claude CodeはAnthropicのMessages形式を使い、OpenAI CodexはOpenAIのResponses形式を使います。どちらもChat Completionsではなく、またバックエンドに合わせて形式が変更される見込みもありません。 Tokiosはこのギャップをゲートウェイ段階で埋めます。リクエストがあなたのマシンに到達する前に変換が行われるため、三つのサーバーを運用したり独自の変換レイヤーを構築したりすることなく、同一のデプロイがClaude CodeやCodex、そして通常のOpenAI SDK呼び出しにも応答できるのです。
Claude Code(Anthropic Messages)、OpenAI Codex(Responses)、およびOpenAI SDK(Chat Completions)はいずれもリクエストをTokiosゲートウェイへ送信します。このゲートウェイが各フォーマットをChat Completions形式に変換した上で、ローカルに配置されたモデルへ転送するのです。

三つのクライアント形式がゲートウェイに集約され、そこですべてがChat Completions形式に変換されてひとつのローカルモデルへ送信されます。

形式の不一致

三つの通信形式が api.tokios.com に到達しますが、そのうちバックエンドが理解できるのは一つだけです: Ollama、llama.cpp、vLLM、そしてLM Studioでは三番目の方式のみが実装されている。もしTokiosがトンネル内でバイトデータを何も変更せずに転送した場合、Claude CodeやCodexからのリクエストはローカルサーバーに認識不能な形式で届き、即座に失敗してしまうだろう。

翻訳が行われる場所

Tokiosはクライアントからのリクエストを、トンネルを通じてユーザーのマシンへ送信する前に ゲートウェイ側 でOpenAI Chat Completions形式に変換する。このゲートウェイはクラウド上に存在し、api.tokios.comという場所にある。リクエストの全処理フローについては Tokiosがローカルモデルへリクエストをルーティングする仕組み を参照されたい。
  • Anthropic Messages (POST /v1/messages、Claude Codeが送信する形式) はChat Completions形式へ変換される。
  • OpenAI Responses (POST /v1/responses、Codexが送信する形式) も同様にChat Completions形式へ変換される。
  • OpenAI Chat Completions (POST /v1/chat/completions) はそのまま通過するだけで、変換の必要はない。
トンネルを通過できるのは、すでにChat Completions形式になっているリクエストのみです。 tokios-connector はAnthropicやResponses形式のペイロードを一切受け取らず、Chat Completions形式のデータを受信してから、設定済みの BaseUrl へそのまま転送します(例えばOllamaの場合は http://127.0.0.1:11434/v1 となります)。このコネクターは内容を翻訳せず単に転送するだけです。フォーマット処理に関するロジックはすべてゲートウェイ側で、各デプロイごとに一度だけ実装されています。 この集中管理方式により、設定内容を容易に移植できるのです。バックエンド側ではAnthropicやOpenAIが新たに導入した通信フォーマットを実装する必要はなく、従来通りの処理を続けるだけで済みます。
ツール呼び出しや関数呼び出し用のフィールドも翻訳プロセスを通じてそのまま渡されますが、実際にモデルがそれらを利用できるかどうかはモデル自体の仕様によります。翻訳によって変わるのは通信形式のみで、モデルの能力そのものは変わりません。

同一のデプロイに、二通りのアクセス方法がある

例えば gemma-tunnel という名前のデプロイをローカルモデルに向けて登録したとします。この一つのデプロイが、バックエンド側の変更なしにAnthropic形式のクライアントとOpenAI形式のクライアントの両方からのリクエストに応答できます。

Claude Code(Anthropic Messages)

Claude CodeはAnthropic Messages形式で通信するため、ルートベースURLを使用します。 /v1 は不要です。
Claude Codeのモデル選択画面には claude* 形式のIDのみが表示されるため、 gemma-tunnel はそこに現れません。上記のように --model を明示的に指定する必要があります。完全な設定方法については Tokiosを使って自身のローカルモデルでClaude Codeを利用する をご覧ください。

OpenAI SDK(Chat Completions)

OpenAI形式のクライアントは /v1 ベースURLを利用します。
両方のリクエストでは同じ model 名が指定されています。これは公開用のデプロイ名(gemma-tunnel)であり、ローカル環境で実際に使用されている内部IDではありません。必要な翻訳処理を経た後、両者は同一のトンネルを通じて同一のローカルモデルへと転送される単一のChat Completions呼び出しとなります。モデル側から見れば、クライアントがどのプロトコルを使って接続したかは判別できません。 OpenAI Codex follows the same pattern through the Responses API — see Use OpenAI Codex with your own local models via Tokios for the config.toml setup.

エージェントツールにおいてなぜこれが重要なのか

コーディングエージェントの分野こそが、このプロトコルの分裂が実際に顕在化する場面です。Claude CodeはAnthropic Messagesを、CodexはOpenAI Responsesを標準として採用しており、その他の多くのツール群——LangChainや各種チャットUI、SDKなど——はChat Completionsを標準としています。ローカルモデルを運用し、これら複数のツールで試用したい場合、各ツールがご自身のバックエンド形式をネイティブにサポートするか、独自のアダプターを用意する必要があります。 Tokiosを利用すればそうした問題は一切生じません。一度デプロイを登録するだけで、サポートされているすべてのクライアント形式が同一のバックエンド呼び出しへと変換されます。どのローカルモデルをデプロイ用に使用するかを切り替える際にも、クライアント側の設定を変更する必要はありません。なぜなら変換処理およびデプロイの照合処理はすべてゲートウェイ側で行われ、エージェントの設定ファイルには一切関与しないからです。 現在利用可能なクライアントの完全な一覧については、任意のOpenAIまたはAnthropic互換クライアントをTokiosに接続するをご覧ください。

クイックスタート

コネクターをペアリングし、数分で初回リクエストを送信できます。

Tokiosにおけるリクエストのルーティング方法

クライアントからゲートウェイ、コネクターを経てモデルへ至るまでのリクエストの全ライフサイクルを確認できます。

対応クライアント一覧

ご利用のクライアントに必要なベースURLやAPI仕様をご確認ください。

Claude CodeとTokiosの併用方法

ANTHROPIC_BASE_URLを設定すれば、Claude Codeのリクエストをご自身のモデルへとルーティングできます。