簡単な結論
すべての 4 方式では受信用ポートを開くことはありません。これらは 呼び出し可能なエンドポイントの範囲、認証の仕組み、そして APIワークロード向けに設計されているかどうか という点で互いに異なります。
ローカルLLM APIの脅威モデル
各手法を比較する前に、ローカルの推論サーバーを公開した際に起こり得る問題を説明します：
重要な原則として ローカルモデルAPIにはユーザー管理機能が備わっていない。 Ollama、vLLM、llama.cpp、LM Studioはいずれもデフォルトで認証不要のエンドポイントを公開している。認証処理はこれらの前段に配置される仕組みによって実施される必要がある。
方式 1：SSHトンネル
SSHトンネルは暗号化されたSSHセッションを通じてローカルポートの通信を中継する。これがここで挙げる最も歴史のある方式であり、設定作業も最も手動的となる。仕組みの概要
8000番ポートをローカルマシンにフォワードします。このトンネルが開いている間は、アップストリームモデルIDがhttp://localhost:8000であるモデルをまるでローカルにあるかのように利用できます。
セキュリティ特性
- 暗号化: SSHでは強力な暗号化が実施される。
- 認証: オペレーティングシステムレベルの認証情報（パスワードまたは鍵ペア）が用いられる。
- アクセス範囲: SSHキーを所有する者はマシンに対して完全なシェルアクセス権を得られる。これは単にAPIポートに限られるわけではない。
LLM利用時の問題点
- SSH利用には安定したパブリックIPまたはジャンプホストが必要だ。CGNAT環境下では利用不可となる。
- ネットワーク環境の変化でトンネルが切断され、自動再接続は行われない。
- 各ユーザーはそれぞれ独自のトンネルとSSH認証情報を必要とする。範囲限定されたAPIキーという概念は存在しない。
- ストリーミング機能は標準で備わっておらず、クライアント側で再接続処理を実装する必要がある。
利用シーン
SSHトンネルは個人開発者が手早くテストを行う際に適している。ただしチームメンバーやエージェント、無人で実行する必要がある用途には適さない。方法 2：Tailscale
Tailscaleは、利用者のデバイス間でゼロトラスト型のメッシュネットワーク（「テイルネット」）を構築します。各デバイスには安定したIPアドレスが割り当てられ、通信は暗号化されたWireGuardを通じて行われます。仕組み
セキュリティ特性
- 暗号化： 各デバイスごとに固有の鍵を用いたWireGuardによる暗号化。
- 認証： テイルネットの調整サーバーによってデバイスの身元が確認される。
- アクセス範囲： テイルネットに登録されたデバイスのみがモデルにアクセス可能。
LLM利用時の問題点
- 呼び出し側のすべてのデバイスはまずテイルネットに参加する必要がある。自身のデバイスには問題ないが、チームメンバーやSaaSクライアント、コーディングエージェントなどはAPIキーを必要とするためVPN方式では対応できない。
- Tailscale Funnelを使えばサービスを公開可能だが、利用可能なポートは 443、8443、10000 に限られる。帯域幅にも制限があり、設定変更もできない。
- APIキーの管理機能が存在せず、デバイス単位でのアクセス管理のみが可能でリクエスト単位の認証は行えない。
- モデルサーバー側にも認証機能が備わっておらず、テイルネット内の誰でも認証情報なしで呼び出しが可能だ。
いつ利用すべきか
Tailscaleは個人が複数のデバイスを利用する際に最適なツールです。例えば、ノートパソコンから自宅のサーバーにアクセスする場合などです。すべてのデバイスを自分で管理しており、APIキーの配布が不要な場合に最適な選択肢です。方法 3：Cloudflare Tunnel
Cloudflare Tunnel（cloudflared）では、インバウンドポートを必要とせずにCloudflareのエッジネットワーク経由で通信が行われます。これはリバースプロキシとして機能します。
仕組みについて
セキュリティ特性
- 暗号化： クライアントからCloudflareエッジまでTLSで暗号化され、その後Cloudflareからオリジンサーバーまでも同様に暗号化されます。
- 認証： 認証機構は自前で構築可能です。Cloudflare AccessやAPIトークン、あるいは独自のミドルウェアを利用できます。
- アクセス範囲： デフォルトでは公開可能な状態ですが、必要に応じて認証機構を追加できます。
LLM利用時の注意点
- バッファリング： デフォルトではCloudflareが応答内容をバッファリングします。ただし応答に
text/event-streamcontent-typeヘッダーが含まれる場合はこの限りではありません。そのためSSEストリーミングが途切れたり遅延したりする可能性があります。 - プロキシタイムアウト： 無料プランではCloudflareのプロキシタイムアウト値がおよそ 100秒となっています。コンテキストが長く、
max_tokens値が高い場合の生成処理ではストリームが途中で中断される恐れがあります。 - APIキー層が存在しない： 認証処理は自前で実装する必要がある。Cloudflare Accessやミドルウェア、あるいはAPIゲートウェイを前段に配置する必要がある。
- 複雑さ： DNSレコードの設定やCloudflare Accessのポリシー管理、さらにトンネルのライフサイクル管理も加わるため手間が増える。
いつ利用すべきか
Cloudflare Tunnelは、Cloudflareのエッジサービスの背後でウェブアプリケーションを公開し、かつ同社のエコシステムを既に利用している場合に適している。ただし生の推論用APIとしては、バッファリングやタイムアウトの挙動が原因で、大幅なチューニングなしでは不向きだ。方法 4：Tokiosコネクター
Tokiosコネクターは特定の目的のために作られており、ローカルにあるモデルエンドポイントをどこからでもアクセス可能な認証済みAPIへ変換する。仕組み
1
モデルサーバー上にコネクターをインストールする
Windows
macOS
Linux
2
デプロイを登録し、APIキーを作成する
In the Tokios dashboard, register your model with a public name (for example,
llama3-tunnel), then create a sk-tok-… key scoped to it.3
どこからでも呼び出し可能
セキュリティ上の特性
- 暗号化： クライアントから
api.tokios.comまでTLSで通信し、その後外部トンネル経由でご自身のマシンまで再度TLSで接続します。 - 認証： リクエストごとにビーアートークン（
sk-tok-…）を使用し、必要に応じてモデル名によるスコープ設定も可能です。 - アクセス範囲： 各APIキーは特定のデプロイに限定して利用できます。キーを無効化すればコネクターやバックエンドに影響を与えることなく即座にアクセスが遮断されます。
アーキテクチャ
The connector only dials out tohttps://api.tokios.com. No inbound port is opened on your machine. No DNS record, no public IP, no port forwarding.
利用シーン
Tokiosは以下のような場合に最適です：- 個人ごとにAPIキーを割り当ててチームメンバーとモデル利用権を共有したい場合。
- 標準的なOpenAIやAnthropicのベースURLを求めるコーディングエージェント（Claude Code、Codex、Clineなど）と連携したい場合。
- CGNATや企業内NAT、受信接続が遮断されているネットワーク環境下で作業したい場合。
- 独自の認証レイヤーの構築や維持を行いたくない場合。
比較マトリックス
使用ケース別の推奨事項
これらの方法は互いに排他的なものではありません。同一マシン上で個人用デバイス向けにTailscaleを、チームメンバーやエージェント向けにTokiosを利用することも可能で、互いに干渉しません。
単にポートを開放するだけではどうでしょうか？
SettingOLLAMA_HOST=0.0.0.0, forwarding a router port, or binding vLLM to 0.0.0.0 makes the model reachable — with no authentication at all. Security researchers reported roughly 175,000 exposed Ollama hosts on the open internet (SentinelLABS/Censys, 2026). Internet-wide scanners index exposed services within hours. None of the 4 methods above require you to open an inbound port, and none should be skipped in favor of binding wider.
モデルは常にローカル環境に留まり、エンドポイントはどこからでも利用可能
どの方法を選択しても原則は同じです。モデルは決して外部に流出せず、エンドポイントの公開範囲はユーザー側で自由に設定できます。Tokiosを利用すれば「複数ユーザーに対して安全にエンドポイントを公開する」ための手順が最も簡単になります。詳細な解説
以下の比較項目では上記の表に記載されていない点も含め、アーキテクチャや障害発生時の挙動、特定のワークロード条件下でどのアプローチが優位となるかを詳しく説明します。TokiosとTailscaleの比較
デバイスメッシュとAPIゲートウェイ：ピアツーピア通信用のWireGuardで十分なケースと、スコープ付きAPIキーが必要となるケースの違い
TokiosとCloudflare Tunnelの比較
SSEバッファリングやプロキシのタイムアウト処理、そしてなぜCloudflareのエッジサービスがストリーミング推論処理を意図せず中断させてしまうのか
TokiosとLiteLLMの比較
オープンソースのマルチプロバイダー対応プロキシと管理型トンネル — 両者を組み合わせる方法も紹介します。
Tokiosと自作スタックの比較
The 7-layer self-hosted stack (runtime, proxy, tunnel, auth, TLS, DNS, monitoring) and when building it yourself is worth the hours.
Tokiosを利用すべき場面
意思決定フレームワーク：CGNATの有無、チーム規模、エージェントの互換性、ネットワーク分離要件 — 各制約に最適なツールは何かを解説します。
クイックスタート
コネクターをペアリングし、わずか 2分で最初のモデルを登録できます。
送信専用通信方式を採用した理由
このアーキテクチャ選定がもたらすメリットと排除される課題について説明します。
vLLMのリモートアクセス設定
ローカル環境にあるvLLMサーバーを外部から利用可能にするための手順を詳しく解説します。
セキュリティ強化チェックリスト
10 steps to secure a self-hosted LLM deployment.