# ハイブリッドLLM基盤——ローカル×Claude API設計

> ローカルLLMとClaude APIを併用するハイブリッド構成は、データの機密度に応じて推論先を振り分ける設計です。Ollamaの認証機能の欠如を補う設計と、inference_geoによる地域制御の実装手順を示します。

- Canonical: https://kuucorp.com/blog/hybrid-llm-local-cloud-routing-smb/
- Date: 2026-10-06
- Last modified: 2026-10-06
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
## ハイブリッドLLM基盤とは何か

> ハイブリッドLLM基盤とは、機密度に応じてローカルのOllamaとクラウドのClaude APIへ推論を振り分ける構成です。

専任のインフラ担当者がいない中小企業でも、議事録の要約や社内FAQ応答のように個人情報を含むタスクはローカルの小型モデルで処理し、複雑な推論や長文解析はClaude APIに任せる、という二段構えの設計が現実的な選択肢になっています。全部をクラウドに出す設計は機密情報の扱いで慎重な判断が要り、全部をローカルで処理する設計は複雑なタスクで精度が不足しがちです。ハイブリッド構成はこの両極の間を、リクエスト単位の振り分けで解決します。

## なぜ中小企業にハイブリッド構成が向くのか

> ハイブリッド構成が向くのは、専用GPUを増設せずにAPIコストと機密情報の扱いを同時に抑えられるためです。

Ollamaは自分のPCやオンプレのサーバー上でモデルを動かし、テキストが外部に送信されない設計です。これにより、個人情報や契約情報を含む下書き作業はローカルで完結させ、API呼び出し自体を発生させません。一方で、込み入った文書解析やコード生成のような精度が要るタスクは、API利用分だけ課金されるClaude APIに振り分けることで、GPUサーバーを常時起動させておくコストを避けられます。どちらも「全部を自前インフラで持つ」「全部を外部APIに出す」という二択を避けるための構成です。

## ルーティングはどう設計すればよいか

> ルーティングは、データの機密度・タスクの複雑度・システムの可用性という3つの軸で振り分け先を判断します。

LiteLLMのようなAIゲートウェイをアプリケーションとモデル群の間に置くと、OllamaやvLLMのローカルモデルとClaude・OpenAI・Geminiなどのクラウドモデルを単一のエンドポイントの背後にまとめ、モデルエイリアスとフォールバックチェーンで振り分け先を切り替えられます。個人情報を含む入力はローカルモデルに固定し、ローカルモデルが落ちている場合やタスクが複雑と判定された場合にのみクラウドへフォールバックする、という構成が典型です。ゲートウェイ側でリクエストごとのコストと利用量を記録できるため、どの業務がどれだけAPIコストを使っているかも同時に可視化できます。

## Claude API側はどう地域を制御すればよいか

> Claude APIはinference_geoパラメータでus/globalを指定でき、Claude 4.6以降のモデルで利用できます。

ハイブリッド構成でクラウド側に振り分けたリクエストについても、データの処理地域を制御する手段があります。Claude APIの`inference_geo`パラメータは`POST /v1/messages`呼び出しごとに設定でき、`"global"`（既定・最適なパフォーマンス優先）と`"us"`（米国内インフラのみで推論）のいずれかを選べます。`"us"`を指定した推論は、入力・出力トークン・キャッシュ書き込み・読み取りのすべてで標準料金の1.1倍となり、ワークスペース単位で`default_inference_geo`や`allowed_inference_geos`を設定して組織全体の既定動作を固定することもできます。米国内処理が必須の契約がある場合は、この設定をルーティングポリシーの一部として明示しておく必要があります。

## 運用で気をつけるべき点は何か

> Ollamaは既定でlocalhost:11434にのみ応答し認証機能を持たないため、外部公開時は別途認証層が必要です。

Ollamaのローカルサーバーはポート11434でlocalhostにバインドされ、ローカルからのリクエストには認証を要求しません。社内の複数端末からOllamaサーバーへアクセスできるようにネットワーク越しに公開する場合、Ollama自体にはアクセス制御の仕組みが無いため、リバースプロキシや上述のAIゲートウェイ側でAPIキー・IP制限・利用者ごとのロギングを追加する設計が前提になります。ローカルモデルだからといって無条件に安全というわけではなく、[エージェントの権限管理](/blog/ai-agent-permission-management-design/)と同じ発想で、誰がどのモデルにどこまでアクセスできるかを明示的に設計することが欠かせません。基盤の選定からルーティングポリシーの運用設計まで、Kuu株式会社の[AI Ops](https://kuucorp.com/services/ai-ops/)で相談できます。

## 参考

- [Data residency - Claude Platform Docs](https://platform.claude.com/docs/en/manage-claude/data-residency)
- [Using with LiteLLM AI Gateway](https://docs.litellm.ai/docs/harness/gateway)
- [Ollama API Reference](https://docs.ollama.com/api)

## まとめ

ハイブリッドLLM基盤は、機密度・複雑度・可用性の3軸でローカルのOllamaとクラウドのClaude APIにリクエストを振り分ける設計です。AIゲートウェイでルーティングとコストを一元管理し、クラウド側はinference_geoで地域を制御し、ローカル側は認証層を別途用意する——この3点を押さえれば、専用のインフラチームがいない中小企業でも段階的に導入できます。自社のデータ特性に合わせたルーティング設計は、Kuu株式会社にご相談ください。