生成 AI アプリの本番導入を可能にした 3 つの評価プロセス ～DB 設計レビュー自動化の取り組み～ @Developers Summit 2025

Transcript

1. 生成 AI アプリの本番導入を可能にした 3 つの評価プロセス ～DB 設計レビュー自動化の取り組み～ KINTO テクノロジーズ株式会社 プラットフォーム開発部 DBRE グループ 廣瀬 真輝 @Developers Summit 2025 (02/14)
2. ©KINTO Technologies Corporation. All rights reserved. 2 Index 1 概要・自己紹介 2 会社概要・サービス紹介 3 DBRE グループについて 4 生成 AI アプリの開発背景 5 完成した仕組み 6 生成 AI アプリケーションの評価 目次 7 7 得られた学び
3. ©KINTO Technologies Corporation. All rights reserved. 3 概要・自己紹介 1
4. ©KINTO Technologies Corporation. All rights reserved. 4 生成 AI を活用した社内アプリを本番導入 • 機能：DB のテーブル設計の自動レビュー • 本番導入までに取り組んだ 3 つの評価プロセスについてご紹介
5. ©KINTO Technologies Corporation. All rights reserved. 5 生成 AI アプリケーション開発で重要な「評価」 • 生成 AI からの応答を 100 % コントロールすることはできない • プロンプトが少し違えば同じ命令でも違う応答がくる可能性 • テスト時にうまくいった → リリース後もうまくいくわけではない • 生成 AI アプリケーションを評価する必要性 • デプロイ可否の判断、運用中の品質等を「何らかの基準・方法」で評価 • 「生成 AI アプリの評価」とは ？ → 開発時に最も詰まった箇所の 1 つ
6. ©KINTO Technologies Corporation. All rights reserved. 6 本セッションのゴール • 「生成 AI アプリの評価とは？」という抽象的な概念から、 ユースケースに沿った具体的な実装例まで紹介することで、 生成 AI アプリの評価に関する実践的な基礎知識を提供する
7. ©KINTO Technologies Corporation. All rights reserved. 7 自己紹介 KINTOテクノロジーズ株式会社 プラットフォーム開発部 DBRE グループ Principal Database Reliability Engineer 廣瀬 真輝（ひろせ まさき） DBに関するプラットフォーム・ツール開発 運用、トラブルシューティング等に従事
8. ©KINTO Technologies Corporation. All rights reserved. 8 会社概要・サービス紹介 2
9. ©KINTO Technologies Corporation. All rights reserved. 9 KINTOテクノロジーズ株式会社について（グループ組織） トヨタ自動車株式会社 トヨタファイナンシャルサービス株式会社（TFS） KINTOテクノロジーズ 株式会社 株式会社KINTO • モビリティ・カンパニー化を目指すトヨタの IT サービスを支える内製開発部隊 • 東京、大阪、名古屋にまたがる 350 名超のソフトウェアエンジニア組織 • システム開発の経験を、国を代表する巨大産業のビジネスに活かすチャンス
10. ©KINTO Technologies Corporation. All rights reserved. 10 開発プロダクト・支援実績 ユニークな体験プランや多 彩な商品が発見できる、 KINTOご契約者向けの優待 サイト クルマのオーナーに向けた、 愛車のカスタム・機能向上 サービス KINTO ONEのリースアッ プ車を中心としたトヨタの 中古車サブスク あなたにぴったりの場所を 見つけ出す、お出かけ先イ ンスピレーションAIアプリ KINTOで手軽にマイカーを。 車のサブスクリプション サービス あなたの移動はもっと自由 にもっと楽しく！おでかけ コンシェルジュアプリ クルマ好きなお客様と一緒 に楽しみ、旧車に乗れる喜 びを分かち合う旧車コミュ ニティ トヨタのキャッシュレス 決済アプリ 決済プラットフォームで Woven Cityで生み出される 発明に貢献 開発支援 開発支援
11. ©KINTO Technologies Corporation. All rights reserved. 11 DBRE グループについて 3
12. ©KINTO Technologies Corporation. All rights reserved. 12 DBRE（データベース信頼性エンジニアリング）とは • Database Reliability Engineering • SRE の考え方を DB 領域に適用したもの • 弊社では専任組織（DBRE グループ）が存在
13. ©KINTO Technologies Corporation. All rights reserved. 13 弊社の DBRE 活動に関する詳細 • SRE Kaigi 2025 の発表内容をご参照ください
14. ©KINTO Technologies Corporation. All rights reserved. 14 生成 AI アプリの開発背景 4
15. ©KINTO Technologies Corporation. All rights reserved. 15 DB のテーブル設計（スキーマデザイン）の重要性 出典：AWSでデータベースを始めるのに 必要な 10 のこと • テーブル設計は作成後の修正が大変（特に RDB） • 「良い設計」でテーブルが作り続けられる仕組みを整えたい • 例：社内ガイドラインの作成・レビューの実施
16. ©KINTO Technologies Corporation. All rights reserved. 16 レビューに関する弊社の現状 • DBRE が「テーブル設計ガイドライン」を提供 • 課題：準拠の認知負荷が高い • プロダクト数が多く、DBRE が組織横断でレビューするのは困難 • 数十個存在し今後も増加を想定 • 自動レビュー機能を開発 ＆ 提供することに
17. ©KINTO Technologies Corporation. All rights reserved. 17 構文解析 vs 生成 AI • 「オブジェクト名は Lower snake case で定義」 • 構文解析で可能 • 「格納データが推測できるオブジェクト名をつける」 • たとえば「text」「data1」などは意味が曖昧なのでNG • 生成 AI の方が得意 • 理想はレビュー観点に応じた使い分けだが、まず生成 AI のみで実装 • やってみないと分からず、先に挑戦する価値があると判断
18. ©KINTO Technologies Corporation. All rights reserved. 18 なぜ自前で仕組みを作るか • 多数のガイドラインを生成 AI で高精度にチェックするタスクは 既存のサービス / OSS での対応は現状困難と判断 • 例：GitHub Copilot / PR-Agent / CodeRabbit • フィードバックの方法を柔軟に調整したい • 例：意味が曖昧な「data1」カラムの修正提案は難しくコメントのみに • 将来的に構文解析とのハイブリッド構成で精度向上を目指したい
19. ©KINTO Technologies Corporation. All rights reserved. 19 完成した仕組み 5
20. ©KINTO Technologies Corporation. All rights reserved. 20
21. ©KINTO Technologies Corporation. All rights reserved. 21 折りたたみを展開後：詳細表示 デフォルト：概要のみ表示
22. ©KINTO Technologies Corporation. All rights reserved. 22 AWS 上に構築したアーキテクチャ
23. ©KINTO Technologies Corporation. All rights reserved. 23 プロダクトへの導入は 2 ステップ・数分で完了 • AWS リソースへのアクセスキーを GHA Secrets に登録 • 対象リポジトリに専用の GitHub Actions ワークフローを追加 • DBRE が提供するテンプレートを 1 箇所修正するだけ
24. ©KINTO Technologies Corporation. All rights reserved. 24 生成 AI アプリケーションの評価 6
25. ©KINTO Technologies Corporation. All rights reserved. 25 “GenAIOps” ライフサイクルにおける 3 つの評価プロセス 出典： Microsoft 社 - 生成 AI アプリケーションの評価 • モデル選定フェーズ • 基盤モデルを評価し、使用する モデルを決定 • アプリケーション開発フェーズ • アプリの出力（≒ 生成 AI の 応答）を品質・安全などの観点で 評価しチューニング • デプロイ後の運用フェーズ • Production 環境へデプロイ後も 品質・安全性などを継続的に 評価し改善を続ける
26. ©KINTO Technologies Corporation. All rights reserved. 26 本セッションにおける「評価」のスコープ • 入出力のデータ形式はテキストのみ • 音声、画像などには言及なし（Not マルチモーダル） • 単一のプロンプトに関する評価を対象 • RAG や AI エージェントの評価には言及なし • ただし、基本的な考え方は同じで、応用可能
27. ©KINTO Technologies Corporation. All rights reserved. 27 生成 AI アプリケーションの評価 1.モデル選定フェーズ 6
28. ©KINTO Technologies Corporation. All rights reserved. 28 モデル選定時に発生するトレードオフ • 「性能」「コスト」「パフォーマンス」のトレードオフ • 一般的には性能が高いほど高コスト、高レイテンシの傾向 • 長期的にはコスト低下傾向 / Fine-Tuning などで同精度・低コスト化も可能 • ユースケースに応じて優先事項を決定 出典：Claude 3.5 Sonnet
29. ©KINTO Technologies Corporation. All rights reserved. 29 今回はユースケースを踏まえて性能を優先 • レビュー頻度は高くないため 1 回あたりのコストに寛容 • 高速な応答も求められない • PR の Open をトリガーに非同期で処理するため • 今回は「性能」を優先
30. ©KINTO Technologies Corporation. All rights reserved. 30 モデル選定：ベンチマークスコアの調査 • 「性能」はベンチマークスコアを参考に • タスクで順位変動するが、性能調査のエントリーポイントとして有益 • ユースケースに特化したモデルがあれば第一選択肢に • 例：コーディングなら OpenAI o3-mini 出典：Chatbot Arena
31. ©KINTO Technologies Corporation. All rights reserved. 31 モデル選定時のジレンマ • 生成 AI アプリの性能＝基盤モデルの性能＋Prompt Tuning • Prompt Tuning は基盤モデルごとに方針が異なる点も • GPT は Markdown 形式 / Claude は XML 形式 • （チューニング前の）同一プロンプトで各モデルの性能を評価 ? • チューニング次第で順位逆転の可能性 • 各モデル用にチューニングしたプロンプトで評価 ? • チューニング工数が必要以上に肥大する懸念 • ベンチマークスコアの良いモデル＋粗いプロンプトで結果を確認 • 「いけそう」と思えたら次のフェーズへ
32. ©KINTO Technologies Corporation. All rights reserved. 32 今回は Claude 3.5 Sonnet を採用 • AWS 上での開発のしやすさから Bedrock 内のモデルに限定 • 性能重視で Anthropic 社の Claude 3.5 Sonnet を採用 • 粗いプロンプトで DDL をレビューさせて一定の精度を確認 • プロンプトチューニングでさらに高い精度が期待できると判断
33. ©KINTO Technologies Corporation. All rights reserved. 33 生成 AI アプリケーションの評価 2.アプリケーション開発フェーズ 6
34. ©KINTO Technologies Corporation. All rights reserved. 34 磨かれた（Polished な）プロンプトをデプロイするために 出典： Anthropic 社 - Create strong empirical evaluations 1. テスト用のデータセットを作成 2. 評価とプロンプトチューニングを繰り返す • 「推論結果が期待にどれだけ近いか」などの評価観点を • 「何らかの方法で算出したスコア」として定義して • 「最良のスコアを得たプロンプト」を採用 • 定量化でチューニング前後の比較時の曖昧さを排除 & 自動化もできるとベスト
35. ©KINTO Technologies Corporation. All rights reserved. 35 生成 AI の評価観点をブレークダウン • Evaluation = Quality + Compliance by deepchecks • さらに「真実性」「安全性」「公平性」「堅牢性」などの観点に分類 • 同じ観点でも、算出方法はアプリケーションの特性に応じて選ぶ必要性 • 例：Amazon Bedrock でも、タスクごとに異なる指標を使用 Amazon Bedrock のモデル評価ジョブにおけるスコア算出方法まとめ
36. ©KINTO Technologies Corporation. All rights reserved. 36 評価観点をスコア化する 3 つの方法 anthropic-cookbook に記載のスコア算出方法まとめ • Code-based / Human / Model-based の 3 種類に大別
37. ©KINTO Technologies Corporation. All rights reserved. 37 評価スコアの算出ロジックは？ • クラウドサービスや OSS が提供するものを利用 or 自作 • いずれにせよ、評価基準は自分たちで設定する必要性 • 例：JSON 形式の出力なら「文字列の一致」より「各要素単位の一致」 が適切な場合も
38. ©KINTO Technologies Corporation. All rights reserved. 38 例：Model-based の評価基準を自作 • LLM への指示：「2 種類以上の筋力トレーニングを教えて」 評価の指示 正しさの定義 「正しい」 「正しくない」
39. ©KINTO Technologies Corporation. All rights reserved. 39 まとめ：生成 AI の評価とは、設定した観点を数値化すること
40. ©KINTO Technologies Corporation. All rights reserved. 40 実例：DDL レビューの評価設計 - Quality • スコア算出は Code-based アプローチを選択 • 正解との完全一致をベストスコアにしつつ、類似度を定量化できるため • 算出ロジックは「レーベンシュタイン距離」を採用 • 完全一致で距離「0」、値が大きいほど類似度が低いとみなす • 「DDL の類似度」をはかるベストな指標ではない • 基本的は全データセットでスコア 0 （完全一致）を目指してチューニングする方針
41. ©KINTO Technologies Corporation. All rights reserved. 41 実例：DDL レビューの評価設計 - Compliance • 今回は不要と判断 • 社内向けアプリケーション • プロンプトに埋め込むユーザー入力を DDL に限定する実装 • Compliance はクラウドベンダ提供のガードレール機能が便利 • ユーザー向けチャットアプリ等、セキュリティリスクがあれば必須 • 例：Amazon Bedrock のガードレール • 固有のポリシーに基づいた入出力の評価 • ポリシー違反のユーザー入力、FM応答をブロック（評価＋フィルタリング機能）
42. ©KINTO Technologies Corporation. All rights reserved. 42 評価の実装：専用アプリケーションを開発（Python + Streamlit） • OSS やクラウドベンダーの機能で効率的に開発可能だが、今回は独自実装 id -> テキスト変換 データセット：jsonl 形式
43. ©KINTO Technologies Corporation. All rights reserved. 43 独自に実装した理由 • 出力 DDL と正解 DDL の diff を表示 • 視覚的に差異（＝チューニングポイント）が分かるように
44. ©KINTO Technologies Corporation. All rights reserved. 44 Demo：入力データ例
45. ©KINTO Technologies Corporation. All rights reserved. 45 demo
46. ©KINTO Technologies Corporation. All rights reserved. 46 チューニング結果：プロンプトをデプロイ可能と判断 • 60 個のデータセットほぼ全てにおいて、最良の結果（0）を達成 • 専用アプリ開発により、チューニングと自動評価の高速ループが可能に 出典： Anthropic 社 - Create strong empirical evaluations
47. ©KINTO Technologies Corporation. All rights reserved. 47 Claude のベストプラクティスに則ったプロンプトチューニング • ロールを設定 • XML タグを活用 • Claude に思考させる • 思考過程の出力を指示し、期待外れの回答時にデバッグを容易に • Few-Shot Prompting（出力例を提示） • 参照データを冒頭に、指示を末尾に配置 • 明確かつ具体的な指示を与える • プロンプトを Chain させる 出典：Anthropic 社 - プロンプトエンジニアリング
48. ©KINTO Technologies Corporation. All rights reserved. 48 チューニング：プロンプトを Chain させる • 1 回で全ガイドラインをチェック → 数が増えるほどプロンプトが複雑化 • LLM によるチェック漏れや精度低下の懸念が高まる • 1 回のプロンプト実行で AI にチェックさせる項目を 1 つに限定 • 推論により得た「修正後の DDL」を次のプロンプトへの入力として渡し（Chain）、 繰り返し処理して最終的な DDL を得る仕組みに • Step Functions 内のループで実装
49. ©KINTO Technologies Corporation. All rights reserved. 49 プロンプトの Chain によるメリット / デメリット • メリット • プロンプトが短く、タスクが 1 つに絞られるため精度が向上 • ガイドライン追加時は新規プロンプトを作成 → 既存プロンプトへの 精度影響なし • デメリット • LLM の Invoke 回数が増えるため、応答時間と金銭的コストは増加
50. ©KINTO Technologies Corporation. All rights reserved. 50 生成 AI アプリケーションの評価 3.運用フェーズ 6
51. ©KINTO Technologies Corporation. All rights reserved. 51 デプロイ後の品質評価：運用時は「正解データ」がない • Model-based の評価アプローチを採用 • LLM の推論結果を LLM に評価させる「LLM-as-a-Judge」 • 3 種類に大別 Confident AI に記載の 3 種類の LLM-as-a-Judge
52. ©KINTO Technologies Corporation. All rights reserved. 52 LLM-as-a-Judge における評価基準（Criteria）の設計 • 2 つの Criteria を独自に定義（1-10点） • Appropriateness • LLM の出力がガイドラインに沿って適切に修正されているか • Formatting Consistency • 不要な改行や空白などが付与されておらず、フォーマットの一貫性が 保たれているか
53. ©KINTO Technologies Corporation. All rights reserved. 53 LLM への入力 LLM の推論結果 Criteria の定義 Evaluator の作成 LLM-as-a-Judge の実行
54. ©KINTO Technologies Corporation. All rights reserved. 54 LLM-as-a-Judge のアーキテクチャ 1. レビュー結果が S3 に保存される 2. SQS 経由で非同期で LLM-as-a- Judge 用の Lambda を実行 3. 結果を保存 • ログを S3 • メトリクスを CloudWatch • CloudWatch Alarm による監視
55. ©KINTO Technologies Corporation. All rights reserved. 55 LLM-as-a-Judge の信頼性について • 完全に信頼できるものではない • 人間による評価結果と比較して信頼性を測ることが重要とされている • 今回はユーザーの声を集めやすい社内向けシステム • 定量的なスコアで継続的にモニタリング＋ユーザーフィードバック収集 出典：AWS re:Invent 2024 AIM342
56. ©KINTO Technologies Corporation. All rights reserved. 56 今後：オフラインでの事後評価とFine-Tuning • 本番環境での Input DDL と、LLM が修正した DDL が蓄積 • 出力された DDL をアノテーションし、事後評価を実施 • 本番環境でのデータセットを使って Fine-Tuning
57. ©KINTO Technologies Corporation. All rights reserved. 57 7 得られた学び
58. ©KINTO Technologies Corporation. All rights reserved. 58 評価が非常に重要 ＆ 難しい • 最初に評価を設計 → チューニング & 評価サイクルを高速にまわせた • 3 つの評価プロセス（モデル選定 / 開発 / 運用）で都度判断が必要 • ユースケースごとに判断する必要があり「評価設計の妥当性判断」が困難 • 評価観点の不足でコンプライアンス面で問題を抱えたままデプロイするリスク • ガードレール、フィルタリング機能の進化である程度マネージドな世界へ
59. ©KINTO Technologies Corporation. All rights reserved. 59 テストデータの作成が大変 • 今回は手動で作成 • それなりに時間を要した ＆ 精神的負荷が高い • 自動でテストデータを LLM に生成させる手法も存在 • 別途プロンプト作成とチューニングが必要 • 人間による正確性チェックは入れた方がいい • テストデータはプロンプトチューニングの指針となる非常に重要なデータのため
60. ©KINTO Technologies Corporation. All rights reserved. 60 性能が低いモデルほどプロンプトチューニングの工数・難易度が増加 • 最初は Claude 3.0 Haiku / Sonnet / Opus それぞれで チューニング実施 • 性能は Opus > Sonnet > Haiku • Haiku は今回のタスクに対して性能が低すぎてチューニングを断念 • 後から出た 3.5 Sonnet で一気にチューニングが楽に • まずは最高性能のモデルでデプロイし、後から低性能モデルを Fine-tuning して Quality と Cost のバランスを取るアプローチ も有効
61. ©KINTO Technologies Corporation. All rights reserved. 61 まとめ • DB のテーブル設計レビューを生成 AI で自動化した事例を紹介 • 本番導入までに取り組んだ 3 つの評価プロセスについて解説
62. ©KINTO Technologies Corporation. All rights reserved. 62 弊社テックブログも是非ご覧ください
63. Thank you！
64. Appendix
65. ©KINTO Technologies Corporation. All rights reserved. 65 チューニング：明確かつ具体的な指示を与える • 当初：社内ガイドラインの文章をそのままプロンプトに埋め込み • 「あるべき姿」のみ記載され「具体的な修正手順」が含まれてい • Step-by-step 形式の「具体的な修正指示」に書き換え Before After