本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ケーススタディ」カテゴリ追補として、AIプロダクト・スタートアップのケースを解説する記事です。
LLM（大規模言語モデル）を中核に据えたプロダクトは、「モデル選定」「推論コスト」「ハルシネーション」「Eval（評価）」という4つの新しい論点を抱えます。本記事ではモデルベンダー選定、RAG設計、推論コストの管理、データ整備の優先順位、AI固有の評価設計を整理します。
このカテゴリの他の記事
AIプロダクトの4大論点
flowchart TB
AI[AIプロダクト・スタートアップ]
A[① モデル選定<br/>Claude/GPT/Gemini/OSS]
B[② 推論コスト管理<br/>$/1Mトークンとレート制限]
C[③ ハルシネーション対策<br/>RAG・引用・Guardrails]
D[④ Eval/評価設計<br/>定量・定性ループ]
AI --> A
AI --> B
AI --> C
AI --> D
classDef root fill:#fef3c7,stroke:#d97706,stroke-width:2px;
classDef axis fill:#dbeafe,stroke:#2563eb;
class AI root;
class A,B,C,D axis;モデル選定の判断軸
2026年時点の主要LLMの位置付けです。用途・コスト・ロックイン耐性で住み分けます。
| モデル | 強み | 弱み | 使いどころ |
|---|---|---|---|
| Claude (Anthropic) | 長文・コーディング・推論精度 | 画像生成は別途 | 業務ツール・エージェント |
| GPT (OpenAI) | エコシステム最大・マルチモーダル | レート制限が厳しい時期がある | 汎用・画像 |
| Gemini (Google) | 100万トークンコンテキスト・低コスト | エージェント周辺の成熟度 | 大量文書処理 |
| OSS (Llama/Mistral等) | 自社ホスト・データ持ち出さず | 運用コスト高・モデルが追いつかない | 機密データ・規制業種 |
| Azure OpenAI Service | エンタープライズ契約・SLA・データ滞留 | OpenAI 直契約より高め | 大企業のChatGPT利用 |
新規スタートアップはClaude or GPT を主軸、Gemini を長文ジョブ用、OSSは規制業務だけが現実解。「複数モデル抽象化」を先回りして自作するのは過剰設計の典型です。LiteLLM等の薄いルーターで十分です。
推論コストの構造
LLMコストは入力トークン × 出力トークン × ユーザー数で爆発します。MVP段階で月数万円が、PMF後に月数千万円まで一気に膨れ上がる例が珍しくありません。
| 段階 | 月間コスト目安 | 主な施策 |
|---|---|---|
| MVP（〜1000ユーザー） | 数千〜数万円 | プロンプト圧縮・キャッシュ |
| 成長期（〜10万ユーザー） | 数十万〜数百万円 | プロンプトキャッシュ・モデル分岐 |
| スケール期（10万〜） | 数百万〜数千万円 | 複数モデル使い分け・自社ファインチューニング |
具体策は次の3つが効きます。
- プロンプトキャッシング（Claude/GPTの公式機能）で繰り返し部分のコストを90%削減
- モデル分岐（小タスクは Haiku/GPT-mini、複雑タスクは Opus/GPT-4 系）
- RAGでコンテキスト圧縮（全文渡しではなくTop-K抽出）
「とりあえず最強モデルで全部処理」は資金ショートの典型ルートです。
RAG（Retrieval-Augmented Generation）設計
社内文書・FAQ・商品マスタ等を扱う場合、RAG が事実上の標準です。「LLM単体に全部持たせる」のは精度・コスト・更新性の全てで詰みます。
flowchart LR
Q([ユーザー質問])
EMB[埋め込みベクトル化]
VDB[(ベクトルDB<br/>pgvector / Pinecone)]
TOPK[Top-K文書抽出]
LLM[LLM<br/>+ コンテキスト注入]
A([回答 + 引用])
Q --> EMB --> VDB --> TOPK --> LLM --> A
classDef q fill:#fef3c7,stroke:#d97706;
classDef ret fill:#dbeafe,stroke:#2563eb;
classDef llm fill:#fae8ff,stroke:#a21caf;
class Q,A q;
class EMB,VDB,TOPK ret;
class LLM llm;| 構成要素 | 推奨 |
|---|---|
| ベクトルDB | pgvector（PostgreSQL拡張） / Pinecone / Weaviate |
| 埋め込みモデル | text-embedding-3-small / OSS の bge-m3 |
| 検索 | ハイブリッド（ベクトル + BM25） |
| リランカー | Cohere Rerank / 自前 Cross-Encoder |
| 引用表示 | 必須（ハルシネーション抑制 + 信頼形成） |
「とりあえず ChatGPT API に全文投げる」からのアップグレードパスとして、まず pgvector で始めるのが2026年の鉄板です。
ハルシネーションとガードレール
LLMは「もっともらしい嘘」を生成します。プロダクトに載せる以上、これを構造で抑え込む設計が必須です。
| 対策 | 内容 |
|---|---|
| RAG + 引用 | 根拠文書を必ず提示、未掲載なら回答しない |
| Structured Output | JSON Schemaで出力を縛る |
| Guardrails層 | 個人情報・暴言・禁止話題のフィルタ |
| Confidence表示 | 「自信度が低い」を明示してエスカレーション |
| Human-in-the-loop | 重要判断は人間レビューを挟む |
医療・法務・金融のようなクリティカル領域は原則 Human-in-the-loop 必須。AIは下書き作成までで、最終判断は人間が下す設計に倒します。
Eval（評価）設計
AIプロダクトは「動いているように見える」状態でも、実際には品質が劣化していくことがあります。Eval がCI/CDに組み込まれていないAIプロダクトは、本番障害が顕在化しません。
| Eval種別 | 内容 | ツール |
|---|---|---|
| オフライン Eval | 過去の質問・期待回答セットで自動評価 | Promptfoo / OpenAI Evals / LangSmith |
| オンライン A/B | 本番で複数プロンプト・モデルを比較 | LaunchDarkly + 内製 |
| LLM-as-a-Judge | 別の強いLLMが採点 | GPT-4o / Claude Opus |
| 人手 Eval | サンプリングして人間が評価 | 内製 + アノテーションツール |
| ユーザーフィードバック | 👍/👎 ボタン・コメント収集 | Sentry / Posthog |
オフラインEvalはPRごとに自動実行するのがあるべき姿で、回帰検知の自動化なくしてLLM運用は崩壊します。
推奨スタック
| 領域 | 推奨 |
|---|---|
| LLM API | Claude API / OpenAI API（複数同時契約推奨） |
| エージェント基盤 | LangGraph / Mastra / 自前 |
| ベクトルDB | pgvector（小〜中規模）/ Pinecone（スケール） |
| Eval | Promptfoo + LangSmith |
| 観測（LLM特化） | LangSmith / Helicone / Phoenix |
| プロンプト管理 | Git管理 + テンプレート |
| 課金（ユーザー側） | Stripe + 利用量メトリクス |
| 言語 | TypeScript / Python |
| ホスティング | Vercel / Cloud Run / Modal |
決めるべきこと — あなたのプロジェクトでの答えは？
| 項目 | 選択肢の例 |
|---|---|
| 主モデル | Claude / GPT / Gemini / OSS |
| 副モデル（コスト最適） | Haiku / GPT-mini / Gemini Flash |
| ベクトルDB | pgvector / Pinecone / Weaviate |
| ハルシネーション対策 | RAG + 引用 / Structured / 人間レビュー |
| Eval戦略 | オフライン / A/B / LLM-as-Judge |
| データ滞留要件 | API直接 / Azure OpenAI / OSSセルフホスト |
| 課金モデル | サブスク / 従量課金 / ハイブリッド |
| プロンプト管理 | Git管理 / 専用SaaS |
AIプロダクト固有の鬼門
| 禁じ手 | なぜダメか |
|---|---|
| モデル抽象化を先回りで自作 | LangChain乱用と同じ罠、薄いルーターで十分 |
| 「とりあえず最強モデル」で全タスク | 推論コスト10倍、Haiku/Flash で済むタスクが大半 |
| Eval なしで本番運用 | プロンプト変更で品質劣化が見えない |
| 引用なしの自由記述出力 | ハルシネーションで信頼失墜、SLA違反リスク |
| 個人情報・機密をプロンプトに直接 | データ滞留・学習リスク、マスキング必須 |
| LLM呼び出しに同期処理だけ使う | レート制限・タイムアウトで詰む、Job Queue が必須 |
| エージェントの暴走を制御せず本番へ | 無限ループで請求書爆発、最大ステップ・予算上限を必ず設定 |
| データ品質を後回しでRAG構築 | ゴミデータ → ゴミ回答、データ整備が先 |
AI時代の「AI時代の視点」
AIプロダクトでは「AI時代に有利」がそのままプロダクトの本質です。
| 効くこと | 効かないこと |
|---|---|
| データ品質・整理度 | 「とりあえずモデルで殴る」 |
| プロンプト・Eval をGit管理 | プロンプトを管理画面で編集して履歴消失 |
| プロンプトキャッシング・モデル分岐 | 全タスクで最強モデル |
| Structured Output / 引用付き | 自由記述で全部任せる |
| ユーザーフィードバックループ | 一方通行のリリース |
データの整備が遅れると、後から最強モデルを入れても精度は上がりません。データアーキテクチャへの投資が、そのままAIプロダクトの天井になります。
最終的な判断の仕方
AIプロダクトの核心は「モデルではなくデータと評価ループで勝つ」という認識です。最強モデルは時間とともに陳腐化しますが、整備されたデータと運用されているEvalループは、複利で効く資産になります。
もう一つの軸は「コスト構造を最初から設計」すること。MVP段階で「とりあえず動く」を優先して全部最強モデルに投げると、PMF後の請求書で経営が揺らぎます。プロンプトキャッシュ・モデル分岐・RAGによるコンテキスト圧縮の3点を最初から組み込みます。
選定の優先順位
- データ整備とEvalを最優先 — モデル選定より先
- モデルは Claude/GPT 主軸 + 副モデル — マルチプロバイダで耐障害性
- RAG + 引用 — ハルシネーション抑制の標準装備
- コスト管理機構を最初から — キャッシュ・分岐・上限設定
「モデルはコモディティ化、勝負はデータと評価」が2026年AIプロダクトの定石です。
まとめ
本記事はAIプロダクト・スタートアップのケースについて、モデル選定・推論コスト・RAG・ハルシネーション・Evalまで含めて解説しました。如何だったでしょうか。
データと評価ループで勝ち、モデルは複数主軸、RAGと引用で信頼を作り、コスト構造を最初から設計する。これが2026年のAIプロダクトの現実解です。
これで「ケーススタディ」カテゴリの追補3記事（公共・モバイル・AIプロダクト）が揃い、規模軸（startup/saas/enterprise）と業種軸（public/mobile/ai-product）の両面から自分のプロジェクトを位置づけられるようになります。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（86/89）