FlashLabs、OrcaRouterにローカルGPU共有機能「Orca Connect」を追加

編集: グリットアーツ編集部

公開日：2026年10月28日

3行解説

ニュースの概要

FlashLabs株式会社は2026年10月27日、AI推論ゲートウェイ「OrcaRouter」に新機能「Orca Connect」を追加したと発表しました。Orca Connectは、Ollama、vLLM、LM Studioなどのローカル推論ランタイムで動くモデルを、OrcaRouterのカタログに登録して共有できる仕組みです。マシン側から外向きに1本の接続を開くだけで使え、受信ポートの開放や複雑なネットワーク設定は不要としています。

あわせて、共有リンクには有効期限やリクエスト上限を設定でき、チーム内でキーを直接渡さずに利用できるとしています。さらに、ローカルで処理した応答は課金対象外で、ホスト型モデルが応答した場合のみ課金される設計です。

何が新しいのか

今回の新しさは、ローカルGPUで動くモデルを「そのまま社内の実験用」にとどめず、共有可能なAPIとして扱える点です。従来は、外部から使えるようにするにはポート開放、トンネル設定、NAT越えなどの作業が必要でした。Orca Connectは、そうした設定を避けながら、同じOrcaRouterのAPIキーとエンドポイントでローカルモデルとクラウドモデルを扱えるようにします。

また、課金の考え方も明確です。ローカルのマシンが処理したレスポンスには X-Orca-Billed: false が付き、リクエストは$0として記録されます。一方で、ローカルが応答できない場合にホスト型モデルへ切り替える「スピルオーバー」では、見積もり費用が付くため、どこでクラウド課金が発生するかを追いやすくしています。

グリットアーツ編集部の分析

注目すべきは、Orca Connectが単なる接続機能ではなく、ローカル処理とクラウド処理の境界を運用上見える化している点です。自前GPUが処理した分は無料で、ホスト型モデルが応答した場合のみ課金されるため、コストを抑えたい企業には分かりやすい設計です。ただし、スピルオーバーを有効にすると、想定外のクラウド応答が費用に直結する可能性があります。導入時は、どの条件で切り替わるかを先に決めておく必要があります。

もう一つの実務上の価値は、ポート開放なしで共有できることです。社内FWやゼロトラスト環境では、受信ポートを増やさずに済む構成は導入しやすい一方、監査やログ保管の要件と整合するかは別問題です。暗号化リレーやZero Data Retentionがあるとはいえ、企業側のデータ保持ポリシーに合うかは個別確認が必要です。

日本の現場で考えると

日本企業で使う場合、まず論点になるのは社内ネットワークの制約です。閉域網や厳格なファイアウォール運用では、受信ポートを開けない設計は相性がよい一方、プロキシ設定や端末認証の流れを事前に確認しないと、PoCでつまずきやすくなります。画面のないサーバーでコード承認できる点は、無人運用の現場では扱いやすい要素です。

向いているのは、ローカルLLMを少人数で試す開発チーム、社内のAIエージェント基盤、データを外に出しにくい用途です。逆に、外部公開を広く行う用途や、課金の発生条件を厳密に固定したい用途では、スピルオーバーの扱いを慎重に決める必要があります。チーム共有も、共有リンクの期限や上限をどう設計するかが運用の鍵になります。

導入・検討時に確認したいこと

• 自社のFW、プロキシ、ゼロトラスト環境で外向き接続のみで動くか。
• スピルオーバーの発動条件と、想定外のクラウド課金をどう抑えるか。
• Zero Data Retentionの範囲が、自社の監査・ログ要件と合うか。
• Ollama、vLLMなど既存ランタイムが現場のGPU環境で安定動作するか。
• 共有リンクの有効期限、上限、取り消し手順が運用ルールに合うか。

現時点で分かっていないこと

公式発表では、対応ランタイムや対応エージェント、仕様は今後変更される可能性があるとしています。また、SLA、障害時の切り分け方法、将来の仕様変更が既存運用に与える影響は、本文だけでは確認できません。企業導入では、ここを事前に詰める必要があります。

ローカルGPUを社内外で安全に共有する設計は、ネットワークや課金境界の整理が欠かせません。AI基盤の運用条件を詰めたい場合は、既存環境との接続や保守の観点から検討する価値があります。

出典: PR TIMES