「ChatGPT Enterprise を入れたいが、機密データを社外に出せない」「100 万トークンを使える LLM をオンプレで動かしたい」——金融・製造・公共系を中心に、こうした「LLM をクラウド API ではなく自社環境で動かしたい」相談が 2026 年に入って急増しています。背景には、DeepSeek が 100 万トークンのコンテキストを「エージェントが実用レベルで扱える」DeepSeek-V4 をリリースしたことがあります。重みがオープンソースで配布され、Web / API での利用に加えて自社 GPU 上での動作も可能になりました。
本記事では、DeepSeek-V4 を採用したエンタープライズ RAG 受託案件の設計指針と、既存 OpenAI / Anthropic API 構成からの段階移行ステップを整理します。
なぜ「100 万トークン × オンプレ」が今エンタープライズに効くのか
これまでオンプレ LLM の選択肢は、Llama / Qwen / 国産モデル（LLM-jp 等）が中心で、コンテキスト長は 32K〜128K が現実的でした。一方、エンタープライズ RAG の現場では次のような要件が頻繁に出ます。
| 要件 | 32K の場合 | 100 万トークンの場合 |
|---|---|---|
| 契約書 1 件丸ごと参照 | チャンク分割必須 | そのまま投入可 |
| 議事録 1 年分の横断分析 | RAG パイプライン必須 | 全文埋め込み可能 |
| 既存コードベース全体の参照 | 関数単位で抽出 | リポジトリ全体を一度に |
| 過去ログの要約 | バッチ事前処理必要 | エージェントがその場で要約 |
DeepSeek-V4 はこのギャップを埋めるモデルとして登場しました。特に**「エージェントが実用レベルで使える」長文処理（位置エンコーディングや注意機構の最適化）が施されており、長いコンテキストを単に詰め込めるだけでなく、その内容を横断的に推論**できる点が他モデルとの違いです。
アーキテクチャ全体像 — オンプレ RAG の参照構成
弊社が受託案件で標準化している構成は次の 5 層です。
- データソース層 — SharePoint / Confluence / 基幹 DB / ファイルサーバー
- インジェスト層 — ドキュメントパース、メタデータ抽出、PII マスキング
- ベクトル / 検索層 — pgvector / Weaviate / Elastic、ハイブリッド検索
- LLM 層（DeepSeek-V4 オンプレ） — vLLM / TensorRT-LLM、GPU クラスタ
- エージェント / UI 層 — 社内チャット、Slack、業務 Web UI
注目すべきは、100 万トークン対応によって第 3 層（検索）と第 4 層（LLM）の責任分界が変わることです。従来は「検索で 5 件に絞り込み、LLM に投げる」が定番でしたが、100 万トークンを使えるなら「検索で 100 件に広く拾い、LLM に判断を任せる」設計が選択肢に入ります。これにより検索チューニングのコストが激減します。
受託で押さえる 5 つの設計指針
1. GPU クラスタのサイジングを「ピーク同時接続数」で見積もる
DeepSeek-V4 の本番運用は、「平均同時接続数」ではなく「ピーク同時接続数」で見積もります。LLM はリクエスト中ずっと GPU メモリを保持するため、同時 N リクエストを捌くには N 倍の VRAM が必要です。
| 同時接続 | 推奨 GPU 構成（目安） |
|---|---|
| 〜10 | A100 80GB × 2 |
| 10〜30 | H100 80GB × 4 |
| 30〜100 | H100 × 8（マルチノード） |
vLLM の連続バッチング（continuous batching）を有効化すると体感スループットは 3〜5 倍に上がります。
2. 100 万トークンを「常に埋める」設計は禁物
100 万トークンを毎回フルに使うと、1 リクエストあたりのレイテンシと GPU 占有時間が爆発します。受託案件では次のレイヤリングを推奨します。
- 通常クエリ: 32K 以内
- 長文要約クエリ: 128K まで
- 大規模横断分析: 100 万トークン（明示的なジョブとしてキューイング）
「100 万を使う必要があるか」をアプリ側で判定し、ユーザーに「処理に数分かかります」と表示してから走らせる UX が現実解です。
3. PII マスキングは「インジェスト時」と「LLM 渡し前」の二段で
LLM は確率的にしか PII を保護しません。ベクトル化前と LLM 投入前の 二段階でマスキングします。
def ingest_document(doc: Document):
masked_text = pii_masker.mask(doc.text) # 第1段
chunks = chunker.split(masked_text)
for chunk in chunks:
vector = embedder.embed(chunk)
vector_store.upsert(chunk, vector, metadata=doc.metadata)
def query_llm(question: str, retrieved_chunks: list[str]):
safe_chunks = [pii_masker.mask(c) for c in retrieved_chunks] # 第2段
return llm.generate(prompt=build_prompt(question, safe_chunks))二段で重複しているように見えますが、後段は検索後に動的に判定が変わる PII（例: ユーザーの権限ロールに応じてマスキング強度を変える）に対応するために必要です。
4. 監査ログは「質問 / 検索結果 / LLM 出力 / 引用元」の 4 階層
エンタープライズ要件では、回答の根拠を引用元のドキュメント ID まで追えるよう構造化ログを残します。
- conversation_id ─┬─ question
├─ retrieval (chunk_ids[], scores[])
├─ llm_call (prompt_tokens, output_tokens)
└─ answer (citations[chunk_id, doc_id])「この回答はなぜこの結論になったのか」を後追いできる構造にすることが、社内利用を超えて顧客向けに使う段階の必須条件です。
5. 評価セットは「事実性 / 機密保持 / 拒否動作」の 3 軸で
オンプレ LLM の評価は、回答品質だけでなく次の 3 軸で測ります。
| 評価軸 | チェック内容 |
|---|---|
| 事実性 | 引用元と回答内容が一致しているか |
| 機密保持 | マスキング対象が漏れていないか |
| 拒否動作 | 答えるべきでない質問を拒否しているか |
CI に組み込み、モデルアップデート時に必ず回します。
既存 OpenAI / Anthropic 構成からの段階移行
「すでに ChatGPT Enterprise / Claude for Work を運用している」案件では、いきなり全面切り替えではなくハイブリッド運用が現実的です。
Step 1: ユースケース仕分け
- クラウド API 維持: 機密性が低く、レイテンシが重要なもの（一般 Q&A、ドラフト作成）
- DeepSeek-V4 オンプレ: 機密データを含む RAG、長文契約書解析、ソースコード分析
Step 2: 並行運用フェーズ（3〜6 ヶ月）
両方を同じインターフェース（自社チャット UI）から呼べるようにし、ユースケース別にルーティング。
Step 3: 業務測定とコスト比較
3 ヶ月運用したコスト（API 課金 vs GPU 償却）と回答品質を比較。
Step 4: 配分の最適化
業務ごとに「クラウド / オンプレ」の最適配分を決定し、ガバナンス文書に反映。
弊社が LLM-jp-4 でのプライベート LLM 構築ガイド で整理した「オンプレ LLM の運用設計」と組み合わせると、DeepSeek-V4 への置き換え検討もスムーズです。
ライセンス・地政学的な留意点
DeepSeek の利用にあたっては、受託案件の初期ヒアリングで以下を必ず確認します。
- モデル重みのライセンス条項: 商用利用範囲、改変・再配布の可否
- トレーニングデータの来歴: 規制業界では、データ来歴の証明が必要な場合あり
- 地政学的リスク: モデル提供元の所在地に対するクライアントの内規
- 代替モデルへの切替可能性: 単一モデルロックインを避けた抽象化レイヤー
特に大手金融・公共系では、モデルそのものより「将来別モデルに差し替えられる構成か」が問われます。受託では初期から モデル抽象化レイヤー を入れ、Llama / Qwen / 国産モデルにも入れ替え可能な構造にしておきます。
エンタープライズ MCP ガバナンス設計 で整理した「ベンダー選定基準」の考え方は、LLM ベンダー選定にもそのまま応用できます。
まとめ
DeepSeek-V4 の登場で、「100 万トークン × オンプレ」の選択肢が現実的になりました。エンタープライズ RAG 受託で押さえる 5 点は次の通りです。
- GPU サイジングはピーク同時接続数で
- 100 万トークンは明示的なジョブとして扱う
- PII マスキングはインジェスト時と LLM 渡し前の二段
- 監査ログは 4 階層で構造化
- 評価セットは事実性 / 機密保持 / 拒否動作の 3 軸
弊社では DeepSeek-V4 を含むオープンソース LLM を採用したエンタープライズ RAG 案件を進めています。「機密データの制約でクラウド LLM が使えない」「100 万トークン級の長文解析が必要」案件があれば、お気軽にご相談ください。
