推論基盤をセルフホストする動機

AI を業務や自作アプリに組み込むとき、外部 API は手軽な選択肢です。一方、扱うデータや処理量、モデルの変更管理によっては、推論をどこで動かすかも設計上の判断になります。

では、なぜエンジニアは推論基盤を自分で動かそうとするのでしょうか。この記事では、社内ツールや企業の共通基盤、小規模な自動化の事例を手がかりに、セルフホストを選ぶ動機と、引き受ける運用上の負担を整理します。

なぜセルフホストを選ぶのか

社内文書を要約するツールなら、外部 API を呼び出すだけでも試作できます。モデルの実行環境を用意せずに始められるのは、大きな利点です。しかし、そのツールが継続して使われると、次のような要求が生まれるかもしれません。

こうした要求に対する選択肢の一つが、学習済みモデルを自分たちの管理する環境で実行する「セルフホスト」です。自社管理のクラウドでも、社内の物理サーバーでも構成できます。ただし、実行場所によってデータの通り道や管理できる範囲は異なります。

セルフホストを考える動機は、データ、コストと性能、モデルと運用の3つに整理できます。

データと実行場所を管理したい

非公開ソースコード、契約書、顧客情報などを扱う場合、モデルの性能だけでなく、データの取り扱い条件を満たす必要があります。

ただし、外部 API への送信が、そのままモデルの学習利用を意味するわけではありません。OpenAI の API データ管理資料によれば、API に送信したデータは明示的にオプトインしない限りモデルの学習・改善に使用されません。不正使用監視ログや一部機能のアプリケーション状態には別の保持条件があり、ゼロデータ保持にも承認や対象機能の制限があります。

Amazon Bedrock のデータ保持資料でも、推論時の入力・出力の保持を制御する仕組みが説明されています。適用条件はモデルやリージョン、アカウント・プロジェクトの設定によって異なります。こうした公式資料は、利用する契約と機能に照らして確認する必要があります。

外部 API でも要件を満たせる場合はあります。一方、社外送信そのものが認められない場合には、実行場所と通信経路の管理が必要です。セルフホストでも、アクセス制御やログ管理まで適切に設計して初めて、求めるデータ管理に近づきます。

コストと性能を管理したい

API とセルフホストでは、費用の発生の仕方が異なります。

例えば、毎晩10万件のログを分析する業務を仮定します。このとき、月間件数だけでは、どちらが経済的かは決まりません。

• 入力と出力：1件当たりのトークン数、必要な回答品質
• 処理時間：何時間以内に終えるか、ピーク時に何件並ぶか
• 実行負荷：同時リクエスト数、再処理に必要な余裕
• 総費用：API の現行単価、計算資源費、稼働率、運用人件費

一定量の処理を継続するなら、専用の計算資源を確保する構成も比較対象になります。一方、処理量が少ない、あるいは大きく変動するなら、API の従量課金が合う場合もあります。自前のサーバーでも、メモリや同時処理能力が不足すれば待ち時間は増えます。実際の入力を使い、レイテンシとスループットの両方を測る必要があります。

モデルと運用を管理したい

業務システムでは、モデルの更新が後段の処理に影響することがあります。例えば、請求書から JSON 形式で項目を抽出する処理。モデルや設定の変更で出力が変われば、データ登録や確認作業にも影響します。

ただし、バージョンを固定しても出力が完全に決定的になるとは限りません。評価データを用意し、変更前後の品質を検証する必要があります。また、一部の管理は外部 API や自社ゲートウェイでも実現できます。社内向けの共通 API を作ることと、推論エンジンまで自前で運用することは別の要求です。

この3つの要求に共通するのは、推論の実行条件を自分たちで決めたいということです。どのモデルを、どこで、どのような設定で動かし、いつ変更するか。セルフホストは、その制御範囲を広げる選択です。

ただし、制御できる範囲が広がるほど、運用の責任も増えます。実際のエンジニアは、どのような要求からセルフホストを選んでいるのでしょうか。

実際に何を動かしているのか

公開された事例を、課題と残った負担に分けて見てみます。

小規模な社内 AI：外部送信できないデータを扱う

2024年6月、Reddit の r/LocalLLaMA への投稿で、ある利用者が社内 AI の運用について報告しました。

この事例では、社外へ送信できないライブラリのヘッダーファイルを扱えることが動機です。一方、投稿者は推論サービスが不安定になり、再起動が必要になることもあると書いています。利用できるデータの範囲が広がるのと同時に、安定稼働の責任も自分たちに移ります。

企業の共通推論基盤：実行条件を最適化する

Atlassian は2025年7月、自社の推論基盤「Inference Engine」を公表しました。複数のクラウド製品で利用する LLM のほか、検索用モデルやコンテンツモデレーション用モデルも対象としています。

同社が報告した、対象 LLM ワークロードを第三者ホスティングから自社基盤へ移した際の比較結果は次のとおりです。

同社は遅延や費用に加え、観測性とモデルのデプロイを柔軟に管理することも基盤の目的として挙げています。複数製品が AI を利用する規模になると、推論サービス自体が最適化の対象になります。ただし、そのための専用基盤を開発・維持する投資も必要です。

小規模な自動化：決まった仕事を継続して処理する

Heaps Smart の技術ブログでは、組織の WordPress 記事を取得して要約し、月次ニュースレターの HTML を作るローカルのワークフローが紹介されています。これは組織のコンテンツ制作に関する実践例であり、家庭内の個人利用とは異なります。

一方、2026年6月のReddit の r/selfhosted の投稿には、家庭用の Matrix チャットに送った文書画像や PDF を、ローカル AI で分類・タグ付けして保存する例もあります。こちらは投稿者本人による個人利用の報告です。

用途は違いますが、いずれも繰り返し発生する仕事にモデルを組み込んでいます。まず仕事を決め、必要なモデルの品質と実行環境を考える順序です。ただし、書類の分類や保存には誤処理の可能性があります。必要に応じて、人間による確認と再処理の仕組みを残す必要があります。

セルフホストで引き受ける責任

実行条件を管理できる範囲が広がるほど、運用の責任も増えます。

社内文書を検索してモデルの入力に渡す RAG（検索拡張生成）を導入するなら、検索品質、資料の更新、閲覧権限の継承も別途設計する必要があります。

費用と品質の両立が難しい場合もあります。2025年4月、r/LocalLLaMA に投稿した B2B 開発者は、規制業界向けのプライベート LLM を試し、計算資源の費用、モデル品質、処理速度のトレードオフに直面したと報告しています。同じスレッドには、GPU の選定や量子化、機器の購入とレンタルなど、試算条件に対する異論もあります。単一の投稿者による当時の試算を、一般的な運用費として扱うことはできません。

API・セルフホスト・併用の判断

どの方式を使うかは、処理ごとの制約に合わせて考えます。

社外に送信できない文書の分類だけを自前で実行し、ほかの処理は外部 API を利用する構成も考えられます。共通 API の整備とモデルのセルフホストを切り分けて検討することが大切です。

推論基盤の最小構成

ここまでの事例で使われているのは、主に学習済みモデルの「推論（Inference）」です。データからモデルを作る「学習」とは異なり、既存のモデルに入力を渡して出力を得る処理を指します。モデルが段階的に問題を考える意味での「推論（Reasoning）」とも、ここでは区別します。

自分で推論基盤を動かすために、モデルを最初から学習する必要はありません。

基本となる構成

flowchart LR
    A[業務アプリ・自作ツール] --> B[HTTP等のインターフェース]
    B --> C[推論エンジン＋学習済みモデル]
    C --- D[CPU・GPU／メモリ]
    C --> E[応答]

必要な計算資源は、モデルの大きさだけでは決まりません。

• モデルサイズ：重みを保持するためのメモリ容量
• 量子化：重みの表現を小さくした場合のメモリ使用量と品質
• コンテキスト長：一度に扱う入力の長さ
• 同時処理：複数リクエストを受ける際の容量
• 要求性能：許容できる応答時間と処理量

小さなモデルなら CPU だけで実行することもできます。ただし、必要なメモリ、応答速度、出力品質は用途ごとに確認する必要があります。小規模環境で動いたことを、そのまま複数部署向けの本番運用には当てはめられません。

最初に試すこと

まずは、日常的に繰り返している仕事を一つ選びます。例えば、短い文章の分類や要約。入力と期待する出力を決めて学習済みモデルを実行すれば、メモリ、応答速度、品質を具体的に確認できます。HTTP API から呼び出す構成にすれば、アプリに組み込む際の条件も見えてきます。

私がこの選択を考えるうえで重視したいのは、最初からすべてを自前にすることより、どの処理の実行条件を管理する必要があるかを明確にすることです。

参考資料

• Atlassian, “Atlassian’s Inference Engine, our self-hosted AI inference service”Inside Atlassian
• Reddit r/LocalLLaMA, “Local LLMs in industry?”reddit.com
• Reddit r/LocalLLaMA, “The real cost of hosting an LLM”reddit.com
• OpenAI, “OpenAI プラットフォームのデータ管理”developers.openai.com
• AWS, “Data retention - Amazon Bedrock”docs.aws.amazon.com
• Heaps Smart, “Running low-cost automations locally using n8n and Ollama”Heaps Smart
• Reddit r/selfhosted, “Selfhosted LLMs for selfhosted services”reddit.com