この提案には説得力があります。オープンソースモデルは競争力を持ち、GPUは利用可能です。vLLM、TGI、SGLangなどの推論サーバーも成熟しています。同等のものを自社でホストできるのに、なぜOpenAIやAnthropicに5～10倍の上乗せ料金を支払うのでしょうか。
現実はもっと複雑です。自社運用（セルフホスティング）が本当に有利になる規模は存在します。一方、それ以外の規模では、運用コストが推論費用の削減額をはるかに上回ります。損益分岐点は、ワークロード、モデルサイズ、レイテンシー要件、チームの能力によって異なります。
本記事では、計算、運用の現実、そして自社運用すべきチームとそうでないチームを分ける特徴を詳しく掘り下げます。自社運用を真剣に検討し、率直な数字を求めていることを前提とします。
自社運用が適している場合
自社運用に有利な特徴は次のとおりです。
規模。 推論量が多いことです。具体的には、APIの月間推論費用が€5～10Kを超える場合、通常は自社運用を検討する根拠になります。
予測可能なワークロード。 利用量が安定し、予測可能であることです。自社運用にはキャパシティプランニングが必要です。急増するワークロードでは、キャパシティが無駄になるか（利用率不足）、処理に失敗します（過負荷）。
プライバシー／コンプライアンス要件。 クラウド事業者に送信できないデータを扱う場合です（規制対象業界、特定の政府契約、社内限定データ）。
カスタムモデル。 マネージド事業者が提供していないファインチューニング、カスタムアーキテクチャ、特化型バリアントを利用する場合です。
レイテンシーの制御。 アプリケーションによっては、最初のトークンまで100ms未満というレイテンシーを実現するために、自社で制御するインフラ上でモデルを実行する必要があります。
呼び出し当たりのコストが損益分岐点を下回ること。 計算した結果、自社運用が実際に有利になる場合です。
これらの大半が当てはまるなら、自社運用を真剣に検討する価値があります。
自社運用が適していない場合
反対側も見てみましょう。マネージドAPIに有利な特徴は次のとおりです。
規模が小さい、または変動する。 推論費用が月額€5K未満の場合です。削減額では運用コストを正当化できません。
急増するワークロード。 ピーク時と閑散時で利用量が10倍変動する場合です。自社運用では、利用量が少ない時間帯にキャパシティが無駄になります。
最先端の能力が必要。 GPT-5.5、Claude Opus 4.8、最新の推論階層などはクローズドであり、APIを通じてしか利用できません。ワークロードに最先端の品質が本当に必要なら、APIに料金を支払うことになります。
小規模なチーム。 自社運用推論には運用の専門知識が必要です。専任の余力がなければ、問題が発生します。
迅速な反復。 多数の異なるモデル、設定、事業者を試す場合です。APIなら容易ですが、自社運用では変更のたびにデプロイが必要です。
マルチリージョン／世界各地のユーザー。 自社運用では、各リージョンで自社が運用する必要があります。マネージドAPIなら事業者が対応します。
このような場合は、相当な費用がかかってもマネージドAPIが適切な選択です。
コスト計算（慎重に）
代表的なケースで実際の数字を計算してみましょう。前提は次のとおりです。
- ワークロード：入力1億トークン／月、出力3,000万トークン／月。
- 品質目標：Claude Sonnet 5または現在のGPT-5.x階層に相当。
- 利用可能なオープンモデル：Llama 3.3 70B（多くのタスクで、品質はクローズドなフラッグシップモデルに近い水準です。「Llama 4 70B」は存在せず、Llama 4はScout/Maverick MoEモデルとして提供されている点に注意してください）。
選択肢A：クローズドモデルのAPI。
- クローズドなフラッグシップAPI（Claude Sonnet 5の定価、2026-07-07確認）：入力$3/M × 100M = $300。出力$15/M × 30M = $450。合計：約$750／月。
この支出水準では、自社運用は正当化できません。
ワークロードを10倍に増やしてみます。
- 入力10億トークン、出力3億トークン。
- クローズドAPI：$7,500／月。
この規模になると、自社運用が興味深い選択肢になります。
選択肢B：マネージド型オープンソース事業者上のオープンモデルAPI。
- Together AI上のLlama 3.3 70B：入力・出力ともに$0.88/M（定価、2026-07-07確認）。
- 入力1B × $0.88/M = $880。出力300M × $0.88/M = $264。合計：約$1,144／月。
クローズドモデルと比べて約85%の削減です。大きな差です。
選択肢C：レンタルGPUで自社運用。
- 量子化した（INT8/FP8）70Bモデルは、1台のH100 80GBに収まります。FP16の重み、またはバッチ処理のスループットに余裕を持たせるには、H100を約2台見込んでください。以下のサイジングでは、スループットのために2台を想定します。
- H100のレンタル料金：1台当たり$2～3／時間。
- H100 2台 × $2.50／時間 × 730時間／月 = コンピューティング費用だけで$3,650／月。
- さらに、ストレージ、ネットワーク、運用時間が加わります。
このワークロードでは、純粋なコストだけを比べると、マネージド事業者上のオープンソースモデルが自社運用より有利です。自社運用が有利になるのは、制御も必要な場合（プライバシー、カスタムモデル）、またはスループットがはるかに高い場合に限られます。
選択肢D：所有または長期予約したGPUで自社運用。
- 購入または長期予約したH100 2台：実質$1～2／時間。
- H100 2台 × $1.50／時間 × 730時間 = $2,190／月。
- 利用率を高めればコストを分散できます。このGPUで複数のワークロードを処理すれば、ワークロード当たりのコストは下がります。
この場合、マネージド型オープンソース事業者と競争できる水準になります。ただし、運用上の負担は現実に発生します。
重要な洞察： このワークロード規模（約1.3Bトークン／月）では、マネージド型オープンソース事業者に対する自社運用の削減効果はわずかです。クローズドAPIに対する削減効果は劇的ですが、その大半はマネージド型オープンソースでも得られます。
このワークロードの10倍（約13Bトークン／月）になると、自社運用が明確に有利になり始めます。10分の1なら、ホステッド型が正解です。
運用コスト
推論そのものの費用以外にも、自社運用には運用コストがあります。
初期セットアップ：
- 適切な推論サーバー（vLLM、TGI、SGLang）の選定。
- モデルとハードウェアに合わせた設定。
- GPUインフラ（クラウドまたは所有）の構築。
- ネットワーク、セキュリティ、可観測性。
- 量子化と最適化。
一般的には、初回デプロイにエンジニア1～4人週が必要です。
継続的な運用：
- 監視（レイテンシー、スループット、エラー、GPU使用率）。
- キャパシティプランニング。
- アップグレード（新しいモデルバージョン、推論サーバーの更新、セキュリティパッチ）。
- インシデント対応（GPU障害、OOMクラッシュ、ソフトウェアのバグ）。
- スケーリング（負荷の増加に応じたGPUの追加）。
一般的には、規模に応じて継続的にエンジニア0.25～1 FTEが必要です。
隠れたコスト：
- GPU価格の変動。
- ハイブリッド構成の場合のクラウド下り通信費。
- 専門知識（CUDA、量子化、最適化）。
- 所有ハードウェアの交換／故障コスト。
諸経費込みでエンジニア1人当たり年間€100～200Kかかる場合、パートタイムでの対応でも大きな費用になります。月額€5Kの推論費用を削減しても、月額€15Kのエンジニアリング費用で消えてしまいます。
チームが自社運用のコストを過小評価するのはこの点です。推論の計算だけを切り離して見ると魅力的ですが、総保有コストははるかに高くなります。
推論サーバー
自社運用する場合の主な選択肢は次のとおりです。
vLLM。 オープンソースです。オープンソースLLMのサービング用途では、おそらく最も普及しています。PagedAttention、継続的バッチ処理、幅広いモデル対応を備えています。標準的な選択です。
TGI（Text Generation Inference）。 Hugging Faceのサーバーです。成熟しており、幅広いモデルに対応し、性能も良好です。最近はvLLMほど急速に機能開発が進んでいません。
SGLang。 より新しく、非常に高性能です。構造化生成に強みがあります。活発に開発されています。
LMDeploy。 InternLMチームによるものです。量子化に強く、高速です。
llama.cpp／Ollama。 小規模モデルや低スループット用途向けです。CPUでも使いやすく、一部のユースケースでは本番運用に耐えます。
Hugging Face TGI Inference Endpoints。 マネージド型の自社運用です。インスタンスの時間単位で料金を支払い、HFが運用します。完全な自社運用とマネージド型の中間に位置します。
Modal、RunPod、Replicate。 推論向けのFunction-as-a-Serviceです。完全な自社運用より導入負担は小さい一方、DIYより高コストです。
ほとんどのチームでは、本番環境の自社運用にvLLMまたはSGLangが適しています。どちらも成熟し、高速で、ドキュメントも充実しています。
ハードウェアの選択
GPUに関する選択肢は次のとおりです。
NVIDIA H100。 現時点で推論向けの最先端製品です。レンタル料金は約$2～3／時間です。80GBのVRAMと高速な推論性能を得られます。70Bモデルは、量子化すればH100 1台で、量子化しなければ2台で良好に動作します。
NVIDIA H200。 H100の後継で、より多くのVRAM（141GB）を搭載しています。非常に大規模なモデル向けです。
NVIDIA L40S。 より利用しやすく、約$1～2／時間です。中規模モデル（量子化すれば最大約30B）に適しています。
NVIDIA A100。 前世代ですが、今も広く利用できます。約$1～2／時間です。多くの本番環境で主力として使われています。
AMD MI300X。 一部のワークロードではH100と競合する性能を持ちます。利用可能な環境が増えています。NVIDIAのスタックと比べると、ソフトウェアには未成熟な部分があります。
Apple Mシリーズ。 非常に小規模なモデル（8B未満）では、ユニファイドメモリを搭載したMac StudioやMac Proが使えます。用途は限定的です。
2026年に本番環境で自社運用する場合、大規模モデルが必要ならH100またはH200、中規模ならL40SまたはA100が多くのケースに適しています。
レンタル元には、AWS、GCP、Azure（大手）、Lambda Labs、Runpod、Together、Vast.ai（専門事業者）があります。価格はさまざまです。中断を許容できるなら、スポット／プリエンプティブルインスタンスで50～70%削減できます。
量子化
本番環境で自社運用する構成の多くは、量子化したモデルを使用します。トレードオフは次のとおりです。
FP16（16ビット）。 標準の精度です。品質を完全に維持します。メモリ消費量が最も多くなります。
INT8／FP8（8ビット）。 メモリ使用量を半減し、品質はわずかに低下します。本番環境で一般的な選択です。
INT4（4ビット）。 メモリ使用量を4分の1に抑えます。品質低下はより明確ですが、引き続き有用です。積極的な選択です。
AWQ、GPTQ、GGUF。 それぞれ異なるトレードオフを持つ量子化形式です。
70Bモデルの場合：
- FP16：140GB VRAM。
- INT8：70GB VRAM。
- INT4：35GB VRAM。
H100のVRAMは80GBです。INT8なら余裕を持って収まり、FP16にはGPUが2台必要です。
品質への影響：
- INT8：ベンチマーク上の低下は通常<1%です。
- INT4：1～5%低下し、タスクによって異なります。
デプロイ前に、自社のワークロードでテストしてください。一部のタスク（特に構造化出力やコード）は、ほかのタスクより量子化の影響を受けやすくなります。
スループットとキャパシティプランニング
計画時の重要な問いは、1秒当たり何トークンが必要かです。
単一リクエストのスループット。
- H100上の70Bモデル、INT8：単一ユーザーで約50～80トークン／秒。
バッチ処理のスループット。
- 複数の同時リクエスト：リクエスト全体で合計1000～3000トークン／秒（適切にバッチ処理したvLLM）。
レイテンシーに関する考慮事項。
- 最初のトークンまでのレイテンシー：通常100～500ms。
- トークン当たりのレイテンシー：10～30ms。
キャパシティプランニングでは、次の作業を行います。
- ピーク時の同時リクエスト数を見積もる。
- リクエストの平均長を見積もる。
- 必要な総トークン数／秒を計算する。
- 50%の余裕を加える。
毎時1Mトークンを処理し、ピーク時の同時ユーザーが50人のチームでは、一般的に、十分な利用率を確保したH100が2～4台必要です。
信頼性とフォールバック
自社運用では、信頼性に自社で責任を持ちます。
ヘルスチェック。 継続的に健全性を監視し、異常なインスタンスを再起動します。
グレースフルデグラデーション。 キャパシティが飽和した場合は、失敗させるより応答が遅くなる方を優先します。
APIへのフォールバック。 多くのチームは主要トラフィックを自社運用し、過負荷時にはマネージドAPIへフォールバックします。両方の利点を得られますが、複雑性は確実に増します。
予備ハードウェア。 GPUは故障します。予備のキャパシティを準備します。
マルチリージョン。 世界各地にユーザーがいる場合は複製します。または、遠隔リージョンにはマネージドAPIを利用します。
更新戦略。 新しいモデルバージョンやサーバーのアップグレードには、ダウンタイムを避けるためブルーグリーンデプロイを利用します。
これらはすべて、マネージドAPIなら事業者が引き受けるエンジニアリング作業です。
事例：あるチームの自社運用判断
実例を見てみましょう。AI機能を提供するSaaSチームで、マネージドAPIの月間推論費用は€18,000です。
計算：
- 推論の80%は分類と抽出です（より小規模なオープンモデルで実行可能）。
- 20%は複雑な生成です（クローズドな最先端モデルが必要）。
計画：
- ワークロードの80%をLlama 3.3 70Bで自社運用する。
- 20%にはClaude/GPT APIを維持する。
- Lambda LabsでH100を3台予約：約€4,500／月。
- エンジニアリングのセットアップ：4週間、初期費用€25K。
- 継続的な運用：エンジニア0.25 FTE、約€30K／年。
6か月後の結果：
- 推論費用は月額€18Kから€6Kに低下（自社運用€4.5K + 難しいタスク向けクローズドAPI €1.5K）。
- 従来比の純削減額：€12K／月 = €144K／年。
- エンジニアリング投資を差し引く：€25K + €30K = €55K／年。
- 純財務効果：約€89K／年。
隠れた複雑性：
- デプロイの設定ミスによる障害が1回発生。2時間にわたり部分的に性能が低下。
- スループットを最適化するため、数週間にわたる継続的な調整。
- 自社運用を担当したエンジニアは、ほかの仕事をしたいと感じていた。
結果： 財務的にはプラスでしたが、運用負担は予想以上でした。チームは自社運用を継続しています。処理量が50%減少したら、マネージド型に戻す予定です。
実際に成功した自社運用の判断とは、このようなものです。魔法ではなく、測定可能なROIを伴うエンジニアリング作業です。
事例：あるチームが「APIへ戻る」と判断した場合
出発点が似ている別のチームです。
当初の構成： レンタルGPU上でLlama 3 70Bを自社運用。推論費用はレンタル料€3K／月。さらに、継続的なエンジニアリング費用が約€20K／年です。
変化：
- マネージド型オープンソース事業者の価格が18か月で50%低下。
- チームは成長したが、専任のMLOps担当者を採用しなかった。
- 新しいモデルに追随するには、自社運用構成の大幅な改修が必要になった。
判断：
- 自社運用を停止する。
- Together AIでオープンモデルをホストする構成へ移行する。
- 費用：マネージド型オープンモデルに€2.5K／月。わずかに費用を削減し、複雑性も軽減。
- エンジニアを別の業務に充てる。
結果：
- 財務面では小幅な削減。
- エンジニアの時間を製品開発に振り向けられた。
- 運用上の負担が軽減。
結論： このチームには適切な判断でした。自社運用が有利なチームもあれば、そうでないチームもあります。
判断を見直すタイミング
この判断は恒久的なものではありません。次の点を定期的に見直してください。
処理量の変化。 大幅に増えれば、自社運用の魅力が増します。大幅に減れば、魅力は下がります。
価格の変化。 クローズドAPIの値下げまたは値上げ。マネージド型オープンモデルの値下げ。ハードウェアの値下げ。
モデルの改善。 クローズドモデルに匹敵する新しいオープンソースモデル。さらに差を広げる新しいクローズドモデル。
運用能力。 チームのML／運用能力が増加または縮小した場合。
プライバシー／コンプライアンスの変化。 自社運用を必須とする新しい要件。
四半期ごとの確認が妥当です。常に再評価する必要はありませんが、「一度決めたら終わり」でもありません。
よくある誤り
自社運用の判断でよく見られるパターンは次のとおりです。
誤り1：運用コストを含めずに費用を計算する。 「自社運用で月額€10Kを削減できる」と考えながら、月額€15Kのエンジニアリング費用を無視します。ROIはマイナスです。
誤り2：早すぎる自社運用。 ワークロードが小さい段階で、自社運用にエンジニアリング工数を費やします。時期尚早の最適化です。
誤り3：小規模なオープンモデルで最先端の品質を自社運用しようとする。 「小さいモデルを使えば節約できる」と考えますが、品質が低下してユーザーから苦情が出て、APIにフォールバックします。
誤り4：フォールバックがない。 自社運用基盤が停止しても、グレースフルデグラデーションがありません。APIを利用していれば発生しなかった障害が起きます。
誤り5：最適化への投資不足。 適切に構成すれば50トークン／秒を得られるのに、1台のGPU上で70Bモデルを5トークン／秒で実行します。価値の大半を捨てています。
誤り6：品質ドリフトを無視する。 自社運用モデルの品質が現在のクローズドモデルより低下していても、チームは気づかず、顧客は気づきます。
誤り7：再検討しない。 一度自社運用したら、再評価しません。2年前には正しかった判断が、今は誤りかもしれません。
誤り8：グレースフルな処理を用意せずスポット／プリエンプティブルを使う。 コンピューティング費用を60%削減しても、インスタンスが回収されるたび、数時間おきに障害が発生します。
判断用チェックリスト
意図的に判断するためのチェックリストです。
- APIの推論費用が少なくとも€5～10K／月ですか？
- ワークロードは安定し、予測可能ですか？
- チームにMLOps／推論の専門知識がある、または採用できますか？
- 十分な品質のオープンソースモデルが存在しますか？
- レイテンシー要件は自社運用と両立しますか？
- 運用コストを含む詳細な費用計算を行いましたか？
- フォールバック計画がありますか？
- コンプライアンス／プライバシー要件によって、どちらか一方が必須になっていませんか？
- 四半期ごとに見直しますか？
大半が「はい」なら、自社運用を真剣に検討する価値があります。
ハイブリッドパターン
すべてを一方に統一する必要はありません。多くのチームはハイブリッド構成を運用しています。
大部分は自社運用し、難しいケースにはAPIを利用する。 分類や単純な生成は自社運用し、複雑な推論にはクローズドAPIを利用します。
安定負荷は自社運用し、急増分にはAPIを利用する。 ベース負荷は自社運用で処理し、ピーク分をAPIで吸収します。
機密データは自社運用し、一般データにはAPIを利用する。 機密データは自社運用経由、一般的なクエリはAPI経由で処理します。
ファインチューニング済みモデルは自社運用し、ベースモデルにはAPIを利用する。 カスタムモデルは自社で実行し、既製モデルはAPIから利用します。
ハイブリッド構成は複雑性を増しますが、両方の利点を得られる場合が多くあります。一定規模のチームでは、ハイブリッドが適切な答えになることがよくあります。
結論
2026年には、LLM推論の自社運用は現実的な選択肢です。オープンソースモデルには競争力があり、推論サーバーは成熟し、ハードウェアも利用できます。
しかし、運用コストは現実に発生し、過小評価されがちです。マネージドAPIに対する損益分岐点は推論費用で月額およそ€5～10Kです。それ未満では、エンジニアリング投資を回収できません。
自社運用に成功するチームには、次の特徴があります。
- 運用コストを含め、率直に計算している。
- MLOps能力がある、または構築できる。
- 投資を正当化する十分な規模で運用している。
- ワークロードが安定している。
- 最先端モデルだけに存在する能力を必要としない。
- 信頼性、監視、更新を計画している。
APIを使い続けるべきチームには、次の特徴があります。
- 規模が小さい。
- ワークロードが急増する。
- 迅速な反復が必要。
- 小規模で運用の余力がない。
- クローズドな最先端モデルの能力が必要。
正解は個別の状況によって異なります。慎重に数字を計算し、運用能力を率直に評価してください。自社運用が明らかに有利でない限り、APIを標準選択とします。
自社運用が有利な場合、その効果は経済面でもアーキテクチャ面でも大きくなります。有利でない場合、マネージドAPIこそ正解だったと知るために高い費用を払うことになります。
