はじめに
「AIはAPIで借りるもの」という前提が、静かに揺らいでいます。
クラウドAPIで推論を呼び出す設計は、立ち上げ期のスピードを最大化する上で合理的な選択でした。しかし開発が進むにつれ、ある種の壁に突き当たる場面が増えています。障害時の無力感、予測しにくい従量課金、利用規約の変更リスク、そして特定プロバイダーへの深い依存。
こうした状況を背景に、「intelligence を所有する(owning intelligence)」という考え方が注目を集めています。オープンウェイトモデルを自社インフラやローカル環境で動かし、推論エンジンを自分でコントロールするアプローチです。本記事では、その具体的な実装方法を整理します。
こんな人におすすめ
- 外部 LLM API の障害や価格改定に振り回された経験があるエンジニア
- 機密データを外部 API に送信できない制約があるプロダクトを開発している方
- 複数の LLM プロバイダーを切り替えられる柔軟な設計を検討している方
- オープンウェイトモデルの品質が実用レベルに達しているか確かめたい方
- 社内に GPU リソースがあり、自己ホストの費用対効果を試したい方
オープンウェイトとクローズド API の根本的な違い
「オープンソース LLM」という表現は厳密ではなく、実態は オープンウェイト(モデルの重みが公開されている) と呼ぶのが正確です。Llama 3、Mistral、Qwen、Gemma などがこれに該当します。
クローズド API(OpenAI、Anthropic、Google など)との主な差異を整理します。
| 観点 | オープンウェイト | クローズド API |
|---|---|---|
| 実行環境 | 自社・ローカル | ベンダーのクラウド |
| データ漏洩リスク | 自社コントロール下 | 送信が発生する |
| 可用性 | 自社インフラ依存 | ベンダー SLA 依存 |
| コスト構造 | 固定費(インフラ) | 従量課金 |
| モデル更新 | 自分でタイミングを制御 | ベンダーが決定 |
| カスタマイズ | ファインチューニング可 | 原則不可 |
どちらが優れているかではなく、プロダクトの要件に応じた選択と設計が重要です。
主要なオープンウェイトモデルと選び方
2026 年時点で実用的な選択肢を示します。
汎用・指示追従系
- Llama 3.1 / 3.3(Meta): 70B パラメータで GPT-3.5 相当以上の品質
- Qwen 2.5(Alibaba): コーディングと多言語が特に強い
- Mistral / Mixtral(Mistral AI): 効率的なモデル構造で推論が速い
日本語対応
- Qwen 2.5(日本語コーパスが充実)
- LLM-JP(国立情報学研究所)
コーディング特化
- Qwen2.5-Coder、DeepSeek-Coder
ベンチマーク上の数値だけでなく、実際にプロダクトのユースケースに近いプロンプトで試すことが選定の近道です。
ローカル・オンプレミスで動かすための実行環境
Ollama(手軽に始めるなら)
# インストール(macOS / Linux)
curl -fsSL https://ollama.com/install.sh | sh
# Llama 3.1 (8B) をダウンロードして起動
ollama pull llama3.1:8b
ollama run llama3.1:8b
# OpenAI 互換のエンドポイントが自動で立ち上がる
# http://localhost:11434/v1/chat/completions
Ollama は OpenAI 互換の REST API を提供するため、既存コードのエンドポイントを差し替えるだけで動作します。
vLLM(本番・高スループット向け)
pip install vllm
# Qwen2.5-7B を OpenAI 互換サーバーとして起動
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--port 8000
vLLM はページドアテンションによる高効率な KV キャッシュ管理で、複数の同時リクエストを処理する本番環境に向いています。
OpenAI 互換インターフェースを活用したプロバイダー切り替え
オープンウェイトモデルをローカルで動かしつつ、OpenAI や Anthropic にフォールバックできる設計を組んでおくと、障害時や移行期のリスクを下げられます。
TypeScript での実装例
import OpenAI from "openai";
type LLMProvider = "openai" | "local" | "anthropic";
function createLLMClient(provider: LLMProvider): OpenAI {
switch (provider) {
case "local":
return new OpenAI({
baseURL: "http://localhost:11434/v1",
apiKey: "ollama", // Ollama は任意の文字列を受け付ける
});
case "openai":
return new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
});
default:
throw new Error(`Unknown provider: ${provider}`);
}
}
const provider = (process.env.LLM_PROVIDER as LLMProvider) ?? "openai";
const client = createLLMClient(provider);
const response = await client.chat.completions.create({
model: provider === "local" ? "llama3.1:8b" : "gpt-4o-mini",
messages: [{ role: "user", content: "テスト用のメッセージ" }],
});
console.log(response.choices[0].message.content);
環境変数 LLM_PROVIDER=local を切り替えるだけでローカルモデルに向けられます。CI 環境ではローカル、本番では OpenAI という使い分けも容易です。
Python での実装例
import os
from openai import OpenAI
PROVIDER_CONFIG = {
"local": {
"base_url": "http://localhost:11434/v1",
"api_key": "ollama",
"model": "qwen2.5:7b",
},
"openai": {
"base_url": None,
"api_key": os.environ["OPENAI_API_KEY"],
"model": "gpt-4o-mini",
},
}
provider = os.environ.get("LLM_PROVIDER", "openai")
config = PROVIDER_CONFIG[provider]
client = OpenAI(
base_url=config["base_url"],
api_key=config["api_key"],
)
response = client.chat.completions.create(
model=config["model"],
messages=[{"role": "user", "content": "こんにちは"}],
)
print(response.choices[0].message.content)
つまづきやすいポイント
-
モデルサイズと VRAM の対応: 7B モデルは fp16 で約 14GB の VRAM が必要です。Ollama は量子化(Q4_K_M など)を自動で選択しますが、品質とのトレードオフを把握した上で選定しましょう
-
レイテンシの過小評価: ローカル GPU でも、クラウド API と比べてレイテンシが高くなるケースがあります。特にバッチ処理でなくリアルタイム応答が求められる用途では事前に実測してください
-
日本語の品質差: 英語ベースのモデルをそのまま使うと、日本語の品質が期待より低い場合があります。日本語コーパスで学習されたモデルか、ファインチューニングされたバリアントを選ぶことが観察された傾向として有効です
-
モデルの更新管理: クラウド API はプロバイダーが自動でモデルを更新しますが、自己ホストでは自分で更新を管理する必要があります。CI パイプラインでの定期的な品質チェックを設計に組み込むことを目安として検討してください
まとめ
「AIを借りる」設計は立ち上げの速さという点で優れていますが、長期的な運用では集中リスクが顕在化します。
オープンウェイトモデルは 2026 年時点で多くのユースケースで実用レベルに達しており、Ollama や vLLM といったツールのおかげでローカル実行のハードルも大きく下がっています。
まずは開発・ステージング環境でローカルモデルに切り替えてみることをおすすめします。OpenAI 互換インターフェースを利用した設計にしておけば、本番への展開も段階的に進められます。完全に置き換えることが目的ではなく、「いつでも移行できる状態を保つ」ことが、集中リスクへの現実的な備えになります。


