クラウド設計図鑑

Level 1：生成AIの導入方式を決める

Deployment Strategy

外部API・Managed・Self-hostのどれを選ぶ？

Level 0で、Nortia株式会社の社内ナレッジAIに求められる機能要件・非機能要件が固まりました。ここからが最初の技術判断です。

そして最初の判断は、モデル選定でもGPU選定でもありません。「そもそも生成AIを、どこで動かすのか」 です。

1. 現在の企業状況

  • 要件は文書化され、経営層の承認も得た
  • 評価用の想定質問100件と正解・出典のセットがある
  • 予算はPoCフェーズ分のみ確保。本番投資は成果を見て判断される
  • AI専任は1人、兼任2人。GPUサーバーの運用経験はない

2. 発生した課題

要件のうち、次の2つが真正面から衝突します。

「機密文書を外部サービスへ送信しない」
        ×
「AI専任1人＋兼任2人で運用できる範囲」

前者を厳密に守るならSelf-hostが視野に入りますが、GPUサーバーの運用経験がない組織にとって運用負荷は跳ね上がります。逆に運用負荷を最小化しようとすれば、外部APIかManagedサービスになり、機密要件との整合を取る必要があります。

「とりあえずSelf-host」から始めない

社内AIの構築記事は、Self-hostを前提に書かれているものが多くあります。しかしSelf-hostは常に優れた選択ではありません。GPU調達、モデル更新、障害対応、性能監視のすべてが自社の責任になります。要件が許すなら、運用を他社に任せられる方式のほうが合理的です。

3. 要件（この判断に関係する部分）

Level 0の非機能要件から、この判断を左右する項目を抜き出します。

要件 内容 この判断への影響
機密性 人事・法務・未公開の事業計画を含む文書を扱う データの送信先が決定的な制約になる
性能 TTFT 2秒以内、回答完了約5秒以内 ネットワーク経路とキュー待ちが効く
スループット ピーク20〜50人の同時利用 レート制限・同時実行数の上限が効く
コスト 年間運用費に上限あり 従量課金と固定費のどちらが有利か
運用 専任1人＋兼任2人 障害対応・モデル更新の負荷が効く
監査 質問・参照文書・回答を90日保管 ログの取得可否と保管場所が効く
カスタマイズ性 将来のFine-tuning（Level 8）を否定しない モデルの選択自由度が効く

4. 選択肢

                  生成AI導入
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
     外部API       Managed       Self-host

  ベンダーの      クラウド上の    自社GPU上で
  APIを利用       マネージド基盤   OSS LLMを稼働
方式 具体例 責任範囲
外部API 各社が提供する商用LLMのAPI 利用のみ。モデルも基盤もベンダー側
Managed Amazon Bedrock等のマネージドLLMサービス モデル選択とアプリ実装。基盤は事業者
Self-host GPUサーバー＋OSS LLM（vLLM / SGLang / Ollama） モデル・推論基盤・ハードすべて自社

5. 技術比較

Level 0の要件から導いた8つの判断軸で評価します。

判断軸 外部API Managed（Bedrock等） Self-host
機密性 △ 事業者のポリシーに依存 ○ 自社アカウント内で完結させやすい ◎ 社内ネットワークから出さない
データ送信先 社外（越境の可能性あり） クラウド事業者のリージョン内 自社データセンター内
Latency ○ ネットワーク経由。安定性は事業者依存 ○ リージョン選択で短縮可能 ◎ 経路が短い。ただし実装依存
利用量への耐性 △ レート制限とコストが利用量に比例 ○ クォータ調整が可能 ◎ ハードの上限まで追加課金なし
運用能力 ◎ ほぼ不要 ○ アプリ運用が中心 △ GPU・推論基盤・モデル更新まで自社
カスタマイズ △ 提供された範囲 ○ 提供モデルの範囲で調整可能 ◎ モデル・量子化・Servingまで選べる
モデル選択自由度 △ 事業者のラインナップ ○ 複数ベンダーのモデルから選択 ◎ OSSモデル全般
TCO 利用量比例（少量なら安い） 利用量比例（運用費込みで見ると割安） 初期投資が大きく、利用量が増えるほど有利

TCOは「単価×トークン数」だけではない

Self-hostの比較で最も間違えやすいのがコストです。GPUの購入費だけを外部APIの従量課金と比べると、Self-hostが有利に見えます。実際には次を積む必要があります。

費目 外部API / Managed Self-host
モデル利用 トークン単価×利用量 なし（ハードの償却に含まれる）
ハードウェア なし GPUサーバー購入費 or クラウドGPUの時間課金
設置・電力・空調 なし データセンター費用または社内設置コスト
運用工数 小 障害対応・モデル更新・性能監視の人件費
待機コスト なし（使った分だけ） 利用が少ない時間帯もGPUは確保され続ける
スケール時の追加 クォータ引き上げで対応可 GPU追加調達（リードタイムあり）

利用量が少ないうちは従量課金が有利で、一定量を超えるとSelf-hostが有利という交点が存在します。その交点がどこかは、実測しないと分かりません（Level 4とLevel 9で扱います）。

待機コストという固定費

Nortia株式会社の利用時間帯は8:00〜22:00です。残りの10時間、Self-hostのGPUは基本的に遊びます。従量課金ならゼロになる時間に固定費が発生する——これがSelf-hostの見落とされやすいコストです。

6. 採用判断

Self-hostをPoC対象とし、非機密領域ではManagedを併用するハイブリッドを前提に進めます。

決め手になったのは、8軸のうち1つ、機密性です。

要件：人事・法務・未公開の事業計画を含む文書を扱う
      機密文書を原則として外部LLMへ送信しない
                    ↓
外部API   → 要件を満たせない（社外送信が前提）
Managed   → 契約・リージョン・ネットワーク構成次第では成立しうる
Self-host → 要件を最も素直に満たす
                    ↓
      まずSelf-hostをPoCし、実現可能性を実測で確認する

他の7軸ではSelf-hostは勝っていない

運用能力の軸では、Self-hostは明確に不利です（専任1人＋兼任2人）。それでも採用するのは、機密性が「満たさなければ導入自体が不可」という制約条件だからです。

判断軸には、比較して優劣を測る軸（トレードオフ）と、満たさなければ失格になる軸（制約）の2種類があります。この2つを混ぜて総合点で決めると、制約を満たさない構成が選ばれます。

併用方針

すべてをSelf-hostにする必要はありません。文書の機密区分で経路を分けます。

対象 経路 理由
人事・法務・未公開の事業計画 Self-host 社外送信不可
公開済み規程・一般的なFAQ・技術ドキュメント Managed（将来検討） 機密性の制約がなく、運用負荷を下げられる
社外公開情報の要約など Managed（将来検討） 同上

併用は「後から足す」設計にする

PoC段階から2経路を実装すると、検証項目が倍になります。まずSelf-host単独で成立させ、アプリケーション側はモデル呼び出しをOpenAI互換インターフェースで抽象化しておく——これが現実的な進め方です。抽象化しておけば、後からManagedを足す判断が実装の作り直しになりません。

7. Architecture

PoCフェーズの論理構成です。まだRAGも権限制御も入っていません。

        社員（検証メンバー）
              │
              ↓
     ┌──────────────────┐
     │  検証用UI          │
     └────────┬─────────┘
              │ OpenAI互換API
              ↓
     ┌──────────────────┐
     │  推論サーバー       │  ← Level 3で方式を選ぶ
     │  （Self-host）      │
     └────────┬─────────┘
              ↓
          OSS LLM           ← Level 2でモデルを選ぶ
              ↓
             GPU            ← Level 2でサイジングする

インターフェースをOpenAI互換に固定することが、この構成の設計上の要点です。推論エンジン（Ollama / vLLM / SGLang）を差し替えても、アプリケーション側の変更が不要になります。Level 3で推論方式を比較検討できるのは、ここで抽象化しているからです。

8. 実装

このLevelの実装は「PoC計画の確定」です。

  1. 検証環境の調達 — 手元で完結するGPU環境を用意する（Level 4のGX-10）
  2. 抽象化レイヤの決定 — アプリからはOpenAI互換APIのみを呼ぶ
  3. 検証項目の定義 — 応答時間、同時実行、メモリ使用量、回答品質
  4. PoC合否基準の合意 — 何が出たら本番投資へ進むのかを、測定前に決める

9. Benchmark / Evaluation

PoCの合否基準を、Level 0の非機能要件から逆算して先に決めます。

検証項目 合格ライン 根拠となる要件
TTFT 単一リクエストで2秒以内 性能要件
回答完了時間 想定質問で約5秒以内 性能要件
同時実行 検証機で同時8リクエストまで応答時間が線形以内 ピーク20〜50人への外挿元
メモリ モデル＋KV Cacheが検証機の容量に収まる サイジングの前提
回答品質 想定質問100件で正答率60%以上（RAGなしの素点） Level 5の改善余地を測る基準
運用 起動・モデル差し替え・ログ取得が手順化できる 運用要件（専任1人）

RAGなしで60%という基準

この段階ではまだRAGがないため、社内固有の質問には答えられません。60%という数字は「一般知識で答えられる範囲の質問に、破綻なく答えられるか」を見るものです。ここが低ければ、モデル選定かServing設定に問題があります。RAGを足す前に、素の状態を測っておくことが後の切り分けを容易にします。

10. 残った課題

  • どのモデル（パラメータ数・量子化・Dense/MoE）を選ぶかが未決定
  • 必要なGPUメモリの見積もり方が分からない
  • 推論サーバーをOllama / vLLM / SGLangのどれにするか未検討
  • Managed併用の判断は、Self-hostの実測が出るまで保留

11. 次のLevelへ

Level 2：モデルとGPUを理解するでは、「27BモデルだからこのGPU」という短絡ではなく、

Model weights + KV Cache + Batch + Context Length + Runtime = 必要メモリ

というサイジングの考え方を扱います。パラメータ数だけでGPUを選ぶと、同時利用が増えた瞬間にOOMで破綻します。