Tokiosの仕組み：ご自身のモデル、ご自身のハードウェア、そして単一のエンドポイント

Most networking problems with local models come down to direction: cloud clients want to send traffic in, but home networks, firewalls, and corporate VPNs block inbound connections by default. Tokios solves this by flipping the direction entirely. The tokios-connector dials out to Tokios once on startup and keeps that connection alive. Nothing on your side ever listens for an inbound connection — which means nothing on your side ever needs to be opened up. Connect a model, point a client at api.tokios.com, and your local hardware does the work.

​

Tokiosが埋めるギャップ

クラウド型AIゲートウェイはOpenAIやAnthropic、Azureといったホスティングサービスへのトラフィックルーティングに優れています。しかしlocalhost上やプライベートVPC内にあるモデルへは、公開可能な接続先アドレスが存在しないためアクセスできません。 Tokiosはまさにこの課題を解決するために作られました。外部からユーザーのマシンへ接続しようとするのではなく、逆にマシン側からTokiosへ接続する仕組みです。クラウド側のエンドポイントは常に安定して公開されており、背後にあるモデルは常にプライベートなローカル環境に存在します。ファイアウォールやルーター、DNSの設定を一切変更することなく、完全に利用可能なAPI環境が実現されます。

​

送信専用のアーキテクチャ

リクエストが到着する前の待機状態において、各コンポーネントがどのように関連しているかを以下に示します。 The one connection your machine opens is the connector’s outbound WebSocket (the thick arrow). Every request rides back down that same tunnel (the dotted arrow) — nothing ever connects in. The connector maintains a persistent outbound WebSocket to the Tokios gateway. Claude Code, OpenAI Codex, or any other API client sends its request to api.tokios.com from anywhere on the internet — the Tokios gateway holds that inbound connection and pushes the request down the existing WebSocket to the connector, which forwards it to your local model. Your model never needs to be reachable from the outside world.

​

リクエストの流れ

コーディングエージェントがAPI呼び出しを実行した際、実際にどのような処理が行われるかを以下に示します。 手順の詳細：

1. クライアントはリクエストを送信する という処理を行い、https://api.tokios.com/v1/chat/completions （または /v1/messages、/v1/responses）に対して Authorization: Bearer sk-tok-... というヘッダーを付与して送信します。
2. TokiosがAPIキーを認証し、該当するデプロイを特定します。ゲートウェイは sk-tok-... トークンを確認してテナント情報と照合し、キーが有効であることを検証します。次に model フィールドに記載されたデプロイ名（例：gemma-tunnel）を検索し、そのデプロイのアップストリームモデルID（例：gemma4:e4b）へ置き換えます。
3. ゲートウェイがリクエストを変換し、トンネル経由で送信します。クライアントがAnthropic MessagesまたはOpenAI Responses形式で通信していた場合、ゲートウェイはまずそれらをOpenAI Chat Completions形式へ変換し（詳細は後述）、該当デプロイ用のコネクターが確立したWebSocket経由で転送します。
4. このコネクターはローカルモデルへリクエストを転送する。 tokios-connectorはトンネル経由で送られてきたチャット補完リクエストを受信し、設定済みの BaseUrlに対して標準的なHTTP呼び出しを行います。例えばOllamaの場合は http://127.0.0.1:11434/v1となります。ローカルモデル側から見れば、これはごく普通のローカルリクエストに過ぎません。
5. レスポンスが順次返送されます。ローカルモデルからの応答内容は、"stream": trueを指定した場合は生成中のトークンも含めてトンネルを通じてTokiosゲートウェイへ戻り、そこから待機中のクライアントへ送信されます。全体としてこの一連の処理は、通常のHTTP API呼び出しと同様の挙動を示します。

​

プロトコル変換の仕組み

コーディングエージェントが使用するAPI形式とローカルモデルの形式は必ずしも一致する必要はありません。実際の変換処理は ゲートウェイ 側で行われ、クライアントからのリクエストがユーザーのマシンに到達する前に完了します。Tokiosはクライアント形式をOpenAI Chat Completions形式へ変換し、トンネル経由で送信します。コネクターは単にその内容をローカルサーバーの /v1/chat/completions へ転送するだけです。

• Anthropic Messages（/v1/messages、Claude Codeが使用する形式）はChat Completions形式へ変換されます。
• OpenAI Responses（/v1/responses、Codexが使用する形式）も同様にChat Completions形式へ変換されます。
• OpenAI Chat Completions（/v1/chat/completions）はそのまま通過します。

この仕組みにより、バックエンド側ではOpenAI Chat Completions形式に対応するだけで十分となります。Ollama、llama.cpp、vLLM、LM Studioもすべてこの形式をサポートしています。コネクター自体は変換処理を行わず単に転送のみを行うため、ゲートウェイ側で変換処理が集中管理されているおかげで、デプロイ先のモデルを切り替えてもエージェント側の設定を変更する必要はありません。

​

セキュリティ

本システムのアーキテクチャは送信専用かつテナント単位で管理されるため、設計段階から攻撃対象領域が極めて限定的になっています。

• 受信用ポートは一切開放されません。遠隔地からの攻撃者が調査したり接続したりできる対象が存在しないのです。
• モデルは常にローカルホスト上に留まります。デフォルトではコネクターはループバック先（127.0.0.1）にのみ通信します。LAN内のモデルにアクセスするには明示的な許可が必要です。モデルがインターネットに公開されることは決してありません。
• プロンプトおよび応答内容は転送中に暗号化されます。コネクターと api.tokios.com 間のすべての通信はTLSで保護されたWebSocket（wss://）を通じて行われ、データが平文のままインターネット上を流れることはありません。
• テナント単位で管理されるAPIキーにより被害範囲が制限されます。各 sk-tok-... キーは特定のテナントおよび登録済みデプロイにのみ適用されます。キーが漏洩しても他の顧客のモデルやインフラにアクセスできません。
• デフォルトでは一切のデータが保存されません。計測機能ではトークン数や遅延時間、ステータス、識別子のみが記録されます。応答内容は一切保存されず、リクエスト内容もワークスペース管理者が リクエストログ記録 を有効化した場合にのみ保存されます（暗号化済みで添付ファイルは除外、機密情報は伏せられ、7日後に削除されます）。

モデルもハードウェアもすべてご自身の管理下。エンドポイントは一つだけです。