測定フレームを組めたら、次の関門はスタックです
「KPI表はすべて描きました。ところが実際にこれをどのモデルで動かすかで、3週間ずっと会議ばかり繰り返しています」。先月、ある製造系列会社のDX担当役員がミーティングで話した言葉です。私はその場で即答できませんでした。実はこの質問に、30分で答えられる正解はないからです。
効果測定フレームは先に整理しましたが（第3回で扱ったROI・KPI設計）、そのKPIをどのスタックで達成するかによって、難易度とコストは2〜3倍ずつ開きます。スタックの決定は技術判断ではなく、稟議判断です。CIO・CFO・法務・情報セキュリティが同じ表を見て意見をすり合わせる文書なのです。
商用API — Claude、OpenAI系
もっとも早く始められる道です。アカウント1つ、API キー1つで、数時間以内にプロトタイプが立ち上がります。Claude 3.5 Sonnet は HumanEval 92%、ツール呼び出しの精度98%水準のベンチマーク結果を維持しており、長文ドキュメントの要約や複雑な推論で特に強みを見せます。GPT-4o/5 系は多言語・速度、Microsoftスタックとの統合が容易で、Office・Teamsベースのワークフローによく馴染みます。
稟議者の視点で見ると、商用APIの本当の価値は性能よりも運用負担の移管にあります。モデルのアップデート、GPUの問題、スケーリング — 社内チームが気にすることはほとんどありません。ただし、2つの点が足を引っ張ります。データが外部に出るという事実そのもの（法務・情報セキュリティのレビューが長引く）と、トラフィックが増えるほどコストが階段状に上がる点です。
率直に言えば、月間のトークン使用量がまだ小さいのであれば、この選択がほぼ大半のケースで正解に近いです。Claude・OpenAIの上位フロンティアモデルで zero-data-retention 契約とプライベートエンドポイントを確保できるなら、金融・法務領域でも実務導入事例が増えています。
オープンソース — Llama、Mistral系
Llama 3 70B や Mistral 系のオープンウェイトモデルは HumanEval 81% 台、ツール呼び出し 82% 台で、商用フロンティアと比べて5〜10%程度の性能ギャップがあります。2年前は20%のギャップでしたから、毎年狭まっている傾向です。ドキュメント要約、社内FAQ、RAGベースの知識検索など、大半の実務タスクでは体感差はそれほど大きくありません。
最大の魅力は2つです。第一に、データが会社の外に一歩も出ないよう設計できます。第二に、商用と比較して5〜50倍安いトークン単価（ホスト型プロバイダー基準）で大量トラフィックをさばけます。自社GPUを使えば実質的には運用費だけで済みます。
ただしオープンソースは「タダ」ではありません。ファインチューニング（LoRAベースで7〜14Bモデル）は1回あたり5万〜30万円、70Bのフルファインチューニングは300万円以上かかります。さらにモデルサービングインフラ、モニタリング、プロンプト管理、バージョンロールバックの体制まで整えると、社内に最低1名のMLOps人材が必要です。この人件費が見積書からよく漏れます。
オンプレミス自社ホスティング — 損益分岐の感覚
完全閉鎖網、規制産業、防衛・公共などでは、オンプレミス以外の選択肢はありません。初期のGPUサーバー構築は規模に応じて数千万円〜億単位です。モデルサービングインフラ自体の月間運用コストは10万〜50万円のラインから始まりますが、そこに24×7の運用とDevOps人件費が加わります。米国のリサーチを基準にしても、インフラ運用だけで月$5,000〜$30,000+が一般的な水準です。
稟議観点での損益分岐点はおおよそ次の通りです。月間の使用トークンが500万〜2Bトークン区間を超えると、自社ホスティングのほうが商用APIより安くなり始めます。それ未満であれば、自社ホスティングは総コストで概ね赤字です。最初は「うちはデータが機微だから絶対にオンプレ」と始めたのに、実際のトラフィックシミュレーションをすると商用APIのプライベートエンドポイントのほうが合理的だった、というケースが、私たちのコンサルティングでも繰り返し出ています。
データ機微度別の推奨スタック
実務で私たちが稟議文書によく入れるマトリクスを整理すると次の通りです。
| 機微度 / トラフィック | 推奨スタック | 主な理由 |
|---|---|---|
| 低 / 低 | 商用API単独 | TTM（Time to Market）最優先、初期投資を最小化 |
| 中 / 中 | 商用API + VPCプライベートエンドポイント、自社ベクトルDB | データ経路を統制しつつ、運用負担は移管 |
| 高 / 低〜中 | ZDR契約の商用API + PIIマスキングプロキシ、または Bedrock/Vertex 上の Llama サービング | 法務リスクを緩和しつつ、インフラチームの負担は最小 |
| 高 / 高、閉鎖網 | オンプレ・オープンソース + ハイブリッドルーティング | 大量トラフィックのコストを抑えつつ、フロンティア要求のみ承認済みの商用APIへ振り分け |
2026年、結局のところ答えはハイブリッドです
現在の市場のコンセンサスはハイブリッドルーティングです。低コスト・高頻度のトラフィック（FAQ、分類、要約）はオープンソースや低コストの商用モデルに流し、フロンティア推論が必要な5〜25%のトラフィックだけを Claude・GPT の上位モデルへルーティングする構造です。全体コストは半分以下に減り、ユーザーが体感する品質はほぼそのまま維持されます。
この構造が可能になった理由は、オープンソースの性能が実務レベルに追いついてきたからです。30%と言うと小さく見えますが、トラフィックの75%を5倍安いモデルで回せば、総コストの60%以上が消える、という話です。稟議文書でこの数字は強い説得力を持ちます。
ただしハイブリッドは、スタックがひとつ増える代わりに、ルーティングロジック・モニタリング・コストダッシュボードが必要になります。この管理負担に見合うだけのトラフィックが出ているか — これがハイブリッド導入の実質的な基準線です。
まとめ — そして次の関門
スタック選択は、先の回で扱ったRAG/ファインチューニング方式の決定と結びついています。RAG中心であれば商用APIでも十分に運用でき、ドメイン特化のファインチューニングが必要であれば、オープンソース自社ホスティングの根拠が強くなります。最初から完璧なスタックを選ぶ必要はありません。6か月後にトラフィック・品質データを見て再調整するという前提で、今はもっとも早く検証できるスタックから始めるほうが、結果的に総コストは低くなりました。
次の第5回では、このスタック別に実際の規模別見積もりがどう出るのか — 自社LLM構築コストと予算策定 — 規模別見積もりガイド2026編を扱う予定です。今回扱ったスタックマトリクスが、実際の数字にどう翻訳されるかをご覧いただけます。
私たち5years+は、韓国・日本の中堅・中小企業の自社LLM導入を支援する中で、このスタック決定を一緒に検討してきました。社内でスタック選定を検討されている方は、無料相談はこちらから、現在のデータ機微度・トラフィック予測に基づいた推奨案をまとめます。