オープンソースAIエージェントのセルフホスティング戦略

なぜセルフホスティングなのか——「外に出したくない」は正当な理由だ

AIコーディングツールの利用が拡大する中、企業が直面する課題の一つがデータのコントロールだ。Copilotや商用エージェントを使う場合、コードがサードパーティのサーバーに送信されることになる。知的財産の保護が重要な企業や、規制業界では、このデータフローが法的・コンプライアンス上の問題になり得る。「うちのコードを外部に出してはいけない」というルールが社内にあるなら、セルフホスティング一択だ。

セルフホスティングの主な動機は三つある。一つ目はデータ主権（コードや機密情報を外部に出さない）、二つ目はコスト最適化（APIコールの削減と固定コスト化）、三つ目はカスタマイズ性（自社のコードベースに特化したファインチューニングや設定）だ。「月のAPIコストが50万円を超えた」という規模になると、GPU1枚のサーバーを借りた方がトータルコストで安くなる計算になる。あなたの組織のAPI費用はどれくらいか、一度計算してみてほしい。

ローカルLLMの選定——コーディング特化モデルを選ぶのが鍵

セルフホスティングの核心はローカルLLMの選定だ。2026年時点でコーディングタスクに推奨される主なモデルはDeepSeek Coder V3（671B MoEで商用品質）、Qwen2.5 Coder 32B（バランス重視）、CodeLlama 70B（Metaが公開した老舗）などだ。これらのモデルはOllamaまたはvLLMを通じて提供でき、Continue.dev、Cline、Aiderなどのフロントエンドツールから透過的に利用できる。

M2/M3 Mac Studioクラスのマシンであれば32Bモデルまでは実用的な速度で動作する。個人的にM3 Max MacBook ProでQwen2.5 Coder 32Bを試したが、インライン補完としては十分実用的な速度で動いた。ただし大規模なリファクタリングタスクでは速度が遅く感じる場面もあった。より大きなモデルにはA100/H100 GPUが必要になるが、GPU 1枚のサーバーコストは月額5〜15万円程度で、チームが多数のAPIコールを消費する場合は十分ペイする。

LiteLLMで統合セルフホスト環境を作る——ハイブリッド構成が現実解

OpenHandsはLiteLLMプロキシとの組み合わせで、複数のLLMプロバイダーを統一したインターフェースで管理できる。ローカルモデルをデフォルトとして使いつつ、コンテキストが不足する場合や特に高精度が必要な場合のみクラウドAPIにフォールバックするハイブリッド構成が現実的な選択肢だ。LiteLLMはOpenAI互換のAPIを提供するため、ほぼすべてのAIツールがそのまま動作する。

実際に構築した経験から言うと、LiteLLMのルーティング設定が最初の難関だ。「タスクの複雑度をどう判定してルーティングするか」という基準設計に一番時間がかかる。最初はシンプルに「ローカルモデルをデフォルト、エラーが出たらCloudにフォールバック」という設定から始めて、徐々に細かくチューニングするアプローチをすすめる。

運用フェーズで直面する現実——モニタリングなしでは続かない

セルフホスト環境の運用では、モデルのバージョン管理、推論サーバーの可用性監視、コスト追跡が主な課題だ。Prometheus + Grafanaによるメトリクス収集でGPU使用率とレスポンスタイムを可視化し、SLAを定義してオンコール体制を整備することが推奨される。モデルの更新時にはBlue-Greenデプロイを採用することで、サービスを止めずに新バージョンに切り替えられる。

正直に言うと、セルフホスト環境の維持管理はクラウドAPIよりも確実に手間がかかる。「サーバー管理をやりたくない」という場合は、anthropicやOpenAIのエンタープライズプランのデータ保護オプションを確認する方が現実的かもしれない。セルフホスティングを選ぶのは「本当にそれが必要な理由がある」場合に限定し、理由なくセルフホストに飛び込まないことをすすめる。