LLM/AIをプロダクトに組み込む際のアーキテクチャ判断軸

LLMをプロダクトに組み込む場合、「どのアーキテクチャを選ぶか」という問いは技術的な選択であると同時に、事業戦略上の意思決定でもあります。コストの構造、スケール時の挙動、競合優位性の持続性——いずれもアーキテクチャ選択から派生するからです。

結論を先に述べます。LLM組み込みのアーキテクチャ形態は4つに分類でき、選択は「精度要件・データ機密性・コスト許容度・開発スピード」の4軸で決まります。API利用はスピードと柔軟性に優れ、RAGはドメイン知識の注入に適し、Fine-tuningは精度と独自性のトレードオフを伴い、自前モデルは究極の制御を可能にしますが最大のコストを要求します。この4形態を正しく理解し、4軸で評価することが、AIプロダクト開発における最初の設計判断です。

4つのアーキテクチャ形態

形態1：API利用型（Prompt Engineering）

外部モデルプロバイダ（OpenAI・Anthropic・Google等）のAPIを呼び出し、プロンプト設計によって出力を制御する形態です。現時点で最も広く採用されており、多くのAIスタートアップの出発点となります。

費用構造：従量課金（トークン単価 × 使用量）。初期固定費は実質ゼロで、ユーザー数・処理量に比例してコストが増大します。モデルの選択（GPT-4o vs GPT-4o-mini等）によってコスト差が数倍に及ぶため、ユースケースに合わせたモデルの使い分けが重要になります。

スケール特性：水平方向のスケールは容易ですが、APIレート制限に依存します。大規模トラフィックでは「スロットリングへの対応」と「コスト予算の上限設計」が必要です。

強みと弱み：最新モデルへの追従コストが低く、インフラ管理が不要である反面、プロバイダの価格改定・仕様変更・サービス終了の影響を直接受けます。「自社の差別化がプロンプトにある」構造では、競合による模倣速度が速いという点も留意すべきです。

形態2：RAG（Retrieval-Augmented Generation）

ベースモデルのパラメータを変更せず、検索によって関連する文書や知識を動的にコンテキストとして注入し、出力の精度・最新性を高める形態です。

費用構造：API利用コストに加えて、ベクトルデータベースのホスティング費用（Pinecone・Weaviate・pgvector等）、文書のインデックス化・エンベディング生成コストが発生します。ただし、Fine-tuningに比べると初期投資は格段に小さく抑えられます。

スケール特性：ドキュメント数が増加するにつれて、検索精度の維持が課題になります。再ランキング機能（リランカー）やハイブリッド検索（キーワード＋ベクトル）の導入が必要になる閾値は、一般的に数十万ドキュメントを超えたあたりから顕在化します。

強みと弱み：モデルを変更せずにドメイン知識を注入できるため、新しいデータが発生するたびにモデルを再学習する必要がありません。「常に最新情報が必要」「社内ドキュメントへのQ&A」といったユースケースに特に適しています。一方、検索精度が低いとハルシネーションが増加するという逆説的なリスクがあります——検索で間違ったコンテキストを渡すと、モデルはそれを事実として処理するためです。

形態3：Fine-tuning型

汎用モデルを自社データで追加学習させる形態です。特定ドメインにおける語調・形式・用語の統一、タスク特化型の精度向上を目的とします。

費用構造：学習データの整備（アノテーション含む）、Fine-tuning実行コスト（GPUリソース or プロバイダ課金）、評価・改善のサイクルコストが発生します。学習データの質と量が直接的に精度に影響するため、データ整備のコストを過小評価すると計画が崩れます。

スケール特性：学習済みモデルの推論コストはAPI利用型と同等かそれ以下になる場合があります（特に小さいベースモデルを使う場合）。ただし、モデルの更新サイクル管理がオペレーションとして加わります。

強みと弱み：特定ドメインの精度が汎用APIを上回る可能性があり、自社データを活用したことによる差別化の根拠になります。また、システムプロンプトに頼らず挙動を制御できるため、プロンプトインジェクションへの耐性も向上します。弱みは初期投資の大きさと、「精度の天井がベースモデルに依存する」点です。学習データが不足または低品質な場合、汎用モデルより劣化することがあります。

形態4：自前モデル型

自社でモデルアーキテクチャの設計から学習まで行う形態です。現実には研究機関・大手テック企業・特定の規制業界（医療・防衛等）以外での採用は限定的です。

費用構造：GPU/TPUクラスタの構築・運用、MLエンジニアリングチームの維持、大規模な学習データの収集・管理が必要です。初期投資は数億〜数十億円のオーダーに達することがあります。

スケール特性：完全な制御が可能である反面、規模を活かした恩恵を受けるためにはモデルサイズとデータ量の両方が必要です。Scaling Lawの恩恵は大規模になるほど顕著ですが、それは同時に大規模な計算リソースを要求します。

強みと弱み：API依存リスクがゼロであり、プロプライエタリデータを外部に送出しないセキュリティ上のメリットがあります。ただし、スタートアップにとっては現実的な選択肢である場面は限られており、特定の規制要件・機密性要件がある場合か、モデル自体がコアプロダクトである場合に限定されます。

4軸の判断フレームワーク

アーキテクチャ選択は4つの軸で評価します。各軸を「High / Mid / Low」で評価し、それぞれの形態との適合性を判断します。

軸1：精度要件

ユースケースが求める精度水準を評価します。

• High（医療診断支援・法律文書作成・金融レポート）：Fine-tuning または RAG との組み合わせ。ハルシネーション許容度が低く、ドメイン固有の正確性が求められる。
• Mid（カスタマーサポート・コンテンツ生成）：API利用型 + 適切なプロンプト設計で対応可能。出力の品質管理（ガードレール）を別途実装。
• Low（ブレインストーミング・下書き生成）：API利用型で十分。レスポンス速度とコストを優先。

精度要件が高い場合の鉄則は「評価基準を先に定義する」ことです。Fine-tuningに踏み込む前に、何をもって「精度が高い」とするかのベンチマークセットを構築しなければ、改善のサイクルが成立しません。

軸2：データ機密性

学習・推論に使うデータが外部に送出できるかを評価します。

• High（個人情報・医療記録・営業秘密を含む）：自前モデルまたはオンプレミス型の推論環境が必要。クラウドAPIへのデータ送出は規制・契約上のリスクになる場合があります。
• Mid（社内ドキュメント・顧客データ）：RAGとプライベートクラウドの組み合わせ、またはエンタープライズ向けAPIプラン（データ学習に使用しない契約）の活用。
• Low（公開情報・一般的なコンテンツ）：通常のAPI利用型で対応可能。

見落とされがちなのが「推論時に送るデータの機密性」です。学習データは送らなくても、推論時のプロンプトに機密情報が含まれる場合があります。プロンプトにPII（個人識別情報）が入る設計になっているなら、エンタープライズ契約かオンプレ環境が必要です。

軸3：コスト許容度

現時点の月次コストと、スケール後の単位コストの両方を考慮します。

• High（VC資金での成長期・コストよりスピード優先）：API利用型で速く動かし、コスト最適化は後回し。モデルの使い分け（高精度タスク vs 低精度タスク）で効率化。
• Mid（PMF後・収益化しながら最適化）：RAGによるAPIコスト削減 + ユースケース別モデル選択。
• Low（コスト構造が競争力のコア）：Fine-tuningによる小型モデルへの蒸留、または自前推論環境の構築を検討。

「API利用型は安い」は初期段階での話であり、月10億トークン規模になると費用構造が逆転する場合があります。スケール計画とコスト推移のシミュレーションは、PMF達成後すぐに行うべきです。

軸4：開発スピード

プロダクトの市場投入速度と技術チームの習熟度を評価します。

• High（3ヶ月以内のリリース・小規模チーム）：API利用型のみ。Fine-tuningやRAGの構築に割けるエンジニア工数がない。
• Mid（6ヶ月以内・機械学習エンジニアが1〜2名）：RAGの構築は可能。Fine-tuningは小規模なユースケースに限定。
• Low（1年以上の開発期間・専門チームあり）：Fine-tuningまたは自前推論環境の構築を組み込める。

重要なのは「最初のアーキテクチャは捨てる前提で選ぶ」という考え方です。API利用型でPMFを達成し、課題が明確になってからRAGやFine-tuningに移行するパターンが実用的です。最初から「最適なアーキテクチャ」を設計しようとすることは、仮説検証のスピードを犠牲にします。

アーキテクチャ選択フレームワーク：判断マトリクス

4軸を組み合わせると、以下の判断マトリクスが得られます。

精度要件	データ機密性	推奨形態	補足
Low〜Mid	Low	API利用型	プロンプト設計に注力
Mid〜High	Low	API利用型 + RAG	検索品質の設計が鍵
Mid〜High	Mid	プライベートRAG + エンタープライズAPI	データガバナンス設計が必須
High	High	Fine-tuning（オンプレ or プライベートクラウド）	評価基準の先行定義が前提
High	High + コア差別化	自前モデル	スタートアップにはほぼ非推奨

コスト許容度が低い、または開発スピードが高いフェーズでは、上の表よりも1段シンプルな形態（API利用型 or API+RAG）を選ぶことを推奨します。

典型ケースで読む判断ロジック

ケース1：SaaS企業向け法律文書レビューツール

判断軸の評価：精度要件=High（法的解釈の正確性）・データ機密性=High（顧客の法務書類）・コスト許容度=Mid・開発スピード=Mid

選択：Fine-tuning型（法律ドメイン特化）+ オンプレ推論環境またはエンタープライズAPI契約

理由：顧客データをAPI事業者のサーバーに送出することは、クライアントとの守秘義務契約に抵触するリスクがあります。Fine-tuningによる精度向上は、法的解釈の特殊性（条文解釈・判例引用スタイル）を汎用モデルより正確に表現するために不可欠です。

ケース2：ECプラットフォームの商品説明生成

判断軸の評価：精度要件=Mid（自然な日本語・商品特性の反映）・データ機密性=Low・コスト許容度=High（初期）→Mid（スケール後）・開発スピード=High

選択：API利用型（初期）→ スケール後にFine-tuningを検討

理由：PMFを確認するまではAPI利用型で速く動かします。月間生成件数が数十万件規模になったタイミングで、Fine-tuningによるコスト削減（小型モデルへの蒸留）と品質向上（ブランドトーンの一貫性）を検討します。初期からFine-tuningを組み込んでも、ユースケースが変われば学習データが無駄になります。

ケース3：製造業向け設備保全ナレッジベースシステム

判断軸の評価：精度要件=High（設備仕様の正確な参照）・データ機密性=Mid（製造ノウハウ含む）・コスト許容度=Mid・開発スピード=Mid

選択：RAG型（社内マニュアル・保全記録をベクトルDB化）+ エンタープライズAPI契約

理由：設備保全のナレッジは頻繁に更新され（新機種導入・故障事例の蓄積）、都度Fine-tuningするよりもRAGによる動的な知識注入のほうが運用コストが低くなります。機密性への対応はエンタープライズ契約（データ非学習保証）で担保します。

評価・投資判断への応用

AIをプロダクトに活用するスタートアップの技術DDには追加論点があるように、アーキテクチャ選択はDDの重要な評価ポイントでもあります。投資・買収検討においては、選択されたアーキテクチャが「なぜそれか」を説明できるチームかどうかを確認することが、技術的成熟度の指標になります。

確認すべき問いは以下の3点です。

「なぜAPI利用型（またはRAG/Fine-tuning）を選んだのか？」

合理的な理由（スピード優先・コスト最適化・精度要件・機密性）を語れるチームは、技術的な意思決定が体系的です。「とりあえずOpenAIを使った」という回答が出る場合は、スケール後のコスト構造やリスクについての検討が不十分な可能性があります。

「スケール後のアーキテクチャ移行計画はあるか？」

現在のアーキテクチャを選んだ理由と、どのタイミングでどこに移行するかのロードマップがあるかを確認します。AIスタートアップの競合優位性は独自データ資産とドメイン知識のエンコードに源泉があるため、その方向性に向けた移行計画があるかが重要です。

「LLMのコスト構造は把握されているか？」

現在の月次LLMコスト、1ユーザーあたりの推論コスト、スケール時の単位コスト変化の見通し——これらを即答できないチームは、コスト構造のリスクを潜在させています。Unit Economicsの計算にLLMコストが含まれていることを確認します。

まとめ

LLM組み込みアーキテクチャの選択は「4形態の特性を理解した上で、4軸（精度要件・データ機密性・コスト・スピード）で評価する」という構造で整理できます。

最も重要な原則は**「段階的なアーキテクチャ進化」**です。API利用型→RAG→Fine-tuningという段階的な移行は、各フェーズで得られた知見を次のアーキテクチャ選択に反映できます。最初から「完璧なアーキテクチャ」を目指すことは、不確実性が高い初期フェーズにおいてリスクの大きい選択です。

投資家・技術DD担当者にとっては、アーキテクチャ選択の合理性を評価することが「このチームは技術的な意思決定を体系的に行えるか」を測る手がかりになります。技術的な詳細ではなく「なぜその選択をしたか」の論理を問うことで、チームの技術的成熟度の見極めが可能です。