RAGりたいけど、RAGれない…。toC 医療ドメインでの “遅延拡張” RAG

Transcript

1. 2026.07.29 RAG ✕ 実サービス運用の最前線 RAGりたいけど、RAGれない…。 toC 医療ドメインでの “遅延拡張” RAG 株式会社トリビュー 取締役 CTO 小尾 勇太（@ob1yuta）
2. 小尾 勇太 Obi Yuta 取締役 CTO 起業やEC関連スタートアップ企業を経て、2018年ト リビューにジョイン。リリース前から開発に携わり、 COO兼務などを経て、現在はCTOとして開発・プロ ダクト領域を中心に色々しています。
3. 会社概要 株式会社トリビュー 代表者 毛 迪 所在地 東京都渋谷区恵比寿 設立 2017年7月26日🎉 従業員数 55名（2025年7月1日 時点） 業務委託・派遣・アルバイトを含めると142名 ありたい自分で いられる世界を 実現する
4. 美容医療の口コミ・予約プラットフォーム「トリビュー」 美容外科・美容皮膚科・審美歯科など 自由診療のクリニック検索・来院予約が完結
5. プロダクト 01 02 03 04 施術について 施術の クリニックの チャット予約 知れる リアルがわかる リアルがわかる 即時予約 05 施術を 受ける 06 口コミ投稿 ポイント獲得 施術お疲れ様でした。支払い金額を 入力するとポイントが受け取れます 100,000 円です！ トリビューポイントが付与されました！ 10,000Pとなります。ご確認くださいませ 10,000P トリビューポイントが付与されました！
6. 今日の話 「美容医療 AI相談」
7. 今日の話 AI相談：チャットで美容医療の検討をサポート ユーザーの検討ステップに沿った設計 どのステップに相当する質問かに応じて情報を提示 候補の提示から、そのまま予約の検討までの情報収集をサポート 1 悩みの言語化 抽象から具体に 2 → 施術の理解・比較 悩みにアプローチできる施術 3 → 個別の選択 クリニック・メニュー・ドクター
8. 前提 プロジェクトの与件と、医療ドメインの規制 独自データでの差別化 2 アプリ水準のUI品質 3 コスト制約 4 ロジックの透明性 5 法令・ガイドライン遵守 1 回答は専門家を挟まずユーザーに直接届く → 構造で安全を担保する必要
9. 課題 とりあえずそのまま食わせてプロトタイプに ↓ 口コミなどの自社データを食わせた RAG チャット ↓ ↓ 課題 1：回答の偏り 課題 2：コスト 課題 3：法務 一般知識由来の回答が混ざり、特定 のクリニックを根拠なく過度に推薦 ツール実行ループに本文を載せると トークンが雪だるま式に増加 要約・引用が体験談を「評価」や 「効果」に使ってしまう 偏る 膨らむ 危ない いかにもRAG向きのデータだが、そのままユーザー向けに提供できるわけではない
10. 課題 検討ステップごとの要件とアプローチ 1 悩みの言語化 悩み・予算・ダウンタイムの許容度などから、施術の選択肢を提示
 → LLMの一般知識から十分なヒアリングや具体化 施術の詳細を説明し、迷いがあれば代替案やカウンセリングを提示 2 1施術の理解・比較 → 1と同様のLLM 2 3 + 独自の施術マスタなどの知識をシステムプロンプトで指定 3 個別の選択 希望施術に応じてメニューやクリニック、ドクターなどの候補を提示
 → API・RAGを組み合わせて独自の価値発揮 + 危ない情報を分離
11. 設計 一般知識と会話は LLM、実データは API、体験談は RAG 構造化された実データと、非構造化の体験談で、大きく性質や制約が異なるため、役割を明確化 LLM 一般知識と会話 施術の一般論、相談を検索条件に変換 構造化 API 実データ クリニック・施術・メニュー・料金の候補はすべて既存検索 API から RAG 体験談 口コミをセマンティック意味検索し、ID で返却 画面に出す具体候補はトリビューの実データ以外から出さない
12. 実装 技術スタック LLM ベクトル検索 Embedding ツールレイヤー セーフティレイヤー コスト最適化 Claude Sonnet 4.5（Bedrock converse API） Bedrock Knowledge Base + OpenSearch Serverless Titan Text Embeddings V2 内製 MCPサーバー Bedrock Guardrails（モデル入出力に適用） プロンプトキャッシュ（TTL 1時間） + テンプレートJSON
13. 実装 全体の処理フロー ユーザー フロントエンド メッセージ 相談API エージェントループ POST /messages LLM（Bedrock） メッセージ + ツール定義 loop ─ ツールが必要な間（上限 2 回） 実行してほしいツール ツール実行 実行結果（口コミは ID のみ） 結果を添えて再送 回答 描画（表示統制ルール適用） 回答（テンプレート JSON） ID の実体・表示データを直接取得 実データ MCPサーバー 既存API・検索基盤 検索・取得 口コミ検索のみKnowledge Base へ
14. RAGの活用 Retrieval-Augmented Generation 個別の口コミについては検索はするが、生成には使わせない 一般的な RAG：合流は「生成」の時点 口コミの RAG：合流は「表示」の時点 LLM が要約・引用して生成 ↑ → 表示 → 表示 検索した本文 LLM の回答 口コミは ID で参照のみ ↑ ID の実体 = 実データ
15. RAGの活用 拡張の合流を、生成時から表示時へ遅らせる = 遅延拡張 RAG 検索で回答を拡張する ただし合流は生成の時点ではなく表示の時点 → （振る舞いとしては最終的にRAGっぽく） 法務 口コミは IDで参照するだけ。改変も評価化も構造的に起きない コスト 本文を LLM の往復に載せない → 初期版比・実測で約 1/10 合流を遅らせれば、RAGれる🎉 → 遅延拡張的なRAGの利用
16. 実装 品質の向上 WAF Bedrock Guardrails システムプロンプト ツール（MCP） フロントの表示統制 レートリミット モデル入出力のフィルタリング 出力の設計 候補の根拠を実データに限定 効果表現の置換・差し替え 決定論的に動く部分を増やし、確率的な揺らぎが品質に極力影響しない設計に
17. まとめ 品質も、安全も、コストも、トレードオフにしない 偏り コスト 法務 具体候補はトリビューの実データに限定、ロジックも既存実装をそのまま活用 本文を往復に載せない、キャッシュで初期版比・約 1/10 AI に扱わせない、スクリプトで確実にカバー LLMを使ったプロダクトだからこそ、ユーザーに届ける品質を、確率任せにしない トレードオフにしない選択肢をつくるのがエンジニアの役割でもある
18. お知らせ 取り組みをご紹介しています 公開中 フロントエンド編 フロントエンドでの取り組みを中心にご紹介 https://zenn.dev/tribeau/articles/72c9278da55a3b 近日公開予定 バックエンド編 公開中 プロダクト編 PdM視点での狙い、体験、苦労などををご紹介 https://note.com/tribeau/n/nb514a459c372
19. お知らせ 一緒にチャレンジしてくれる仲間を募集しています 求人（オープンポジション）： https://herp.careers/v1/tribeau/JlZLGByjWm5z Entrance Book： https://tribeau.notion.site/3fe15ab7ee3a4957aece6bfbf07d54fb 採用サイト： https://corp.tribeau.jp/career/ We Are Hiring