AI機能つきアプリ（中規模）の推奨構成｜2026年版

「AIがアプリの中心機能になった」「複数のAI機能があり、品質とコストを管理したい」── この中規模では、個人向けの「APIを呼ぶだけ」から一段上げ、可用性・品質・コストを仕組みで管理します。

対象と前提

• AI機能がプロダクトの主役級(チャット・検索・生成が中心)
• 自社データに基づく回答(RAG)が必要
• 品質とコストを継続的に管理したい
• 止まると困る(プロバイダ障害への耐性が要る)

全体構成（リファレンスアーキテクチャ）

結論: 「アプリ → AI抽象化層(複数プロバイダ切替) → LLM群」。RAGと評価・観測で囲みます。

各要素の具体は次のとおりです。

主系プロバイダが落ちたり遅かったりしたら別プロバイダへ自動で切り替えるのが中規模の肝です。RAGは検索拡張生成、コスト/品質の観測はLLMアプリの可観測性を参照。外部ツール連携が増えるなら直接API vs MCPサーバーも判断材料になります。

なぜこれを選ぶか

• 止まりにくい ── 複数プロバイダのフォールバックで、1社の障害・規制に耐える
• 品質を保てる ── 評価(eval)で、プロンプトやモデル変更による劣化を検知できる
• コストを管理できる ── 観測でトークン・レイテンシを把握し、最適化や上限設定ができる

コスト感

落とし穴

• 品質評価が難しい ── 正解が一つでない。テストデータと評価指標を用意しないと、変更の良し悪しが分からない
• レイテンシ ── LLM呼び出しは遅い。ストリーミング応答やキャッシュで体感を改善する
• RAGの精度 ── 検索が外すと答えも外す。データの整備とチャンク設計が効く
• 過剰な作り込み ── まだ小さいうちから大層な基盤を作らない。必要に応じて足す

スケール時の移行余地

AIが事業の中核になり、大量リクエスト・高信頼・ガバナンスが要るようになったら、AI機能つきアプリ（大規模）へ。LLMゲートウェイの本格化、セルフホストOSSモデルの退避先、ガードレールの強化に進みます。

よくある質問

Q. 複数プロバイダのフォールバックは本当に必要ですか？

A. AIが主役級で「止まると困る」なら必要です。1社のAPIに全面依存すると、その障害・値上げ・規制・規約変更がそのまま事業リスクになります。抽象化層で複数プロバイダを切替可能にしておけば、主系が使えなくてもサービスを継続できます。これはAI依存リスクへの備えの中核的な実装です。

Q. 品質はどう管理しますか？

A. 評価(eval)の仕組みを作ります。代表的な入力と期待される出力のデータセットを用意し、プロンプトやモデルを変えたときに品質が落ちていないかを自動でチェックします。LLMは「正解が一つでない」ため、人手の評価やAIによる評価を組み合わせます。これがないと、変更のたびに勘で判断することになります。

Q. RAGのベクトルDBは何を使えばいいですか？

A. 既存のPostgreSQLがあるなら、拡張のpgvectorで始めるのが手軽です。専用が欲しければPineconeなどのマネージドも選択肢です。規模が小さいうちはpgvectorで十分なことが多く、検索精度やスケールで足りなくなったら専用サービスを検討します。まず既存資産で始め、必要に応じて移るのが無駄になりません。

Q. レイテンシ(応答の遅さ)はどう改善しますか？

A. ストリーミング応答(生成しながら順次表示)で体感を大きく改善できます。あわせて、繰り返す処理のキャッシュ、軽いモデルへの振り分け、不要に長いプロンプトの削減が効きます。LLM呼び出し自体は遅いので、ユーザー体験は「待たせ方」の工夫で補うのが基本です。

関連する考え方

• このページの背骨: AI依存リスクへの備え
• 前の段階: AI機能つきアプリ（個人）
• 次の段階: AI機能つきアプリ（大規模）