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

Slide 1

Slide 1 text

生成 AI アプリの本番導入を可能にした 3 つの評価プロセス～DB 設計レビュー自動化の取り組み～ KINTO テクノロジーズ株式会社プラットフォーム開発部 DBRE グループ廣瀬真輝 @Developers Summit 2025 (02/14)

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

©KINTO Technologies Corporation. All rights reserved. 5 生成 AI アプリケーション開発で重要な「評価」 • 生成 AI からの応答を 100 % コントロールすることはできない • プロンプトが少し違えば同じ命令でも違う応答がくる可能性 • テスト時にうまくいった → リリース後もうまくいくわけではない • 生成 AI アプリケーションを評価する必要性 • デプロイ可否の判断、運用中の品質等を「何らかの基準・方法」で評価 • 「生成 AI アプリの評価」とは？ → 開発時に最も詰まった箇所の 1 つ

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

©KINTO Technologies Corporation. All rights reserved. 9 KINTOテクノロジーズ株式会社について（グループ組織）トヨタ自動車株式会社トヨタファイナンシャルサービス株式会社（TFS） KINTOテクノロジーズ株式会社株式会社KINTO • モビリティ・カンパニー化を目指すトヨタの IT サービスを支える内製開発部隊 • 東京、大阪、名古屋にまたがる 350 名超のソフトウェアエンジニア組織 • システム開発の経験を、国を代表する巨大産業のビジネスに活かすチャンス

Slide 10

Slide 10 text

©KINTO Technologies Corporation. All rights reserved. 10 開発プロダクト・支援実績ユニークな体験プランや多彩な商品が発見できる、 KINTOご契約者向けの優待サイトクルマのオーナーに向けた、愛車のカスタム・機能向上サービス KINTO ONEのリースアップ車を中心としたトヨタの中古車サブスクあなたにぴったりの場所を見つけ出す、お出かけ先インスピレーションAIアプリ KINTOで手軽にマイカーを。車のサブスクリプションサービスあなたの移動はもっと自由にもっと楽しく！おでかけコンシェルジュアプリクルマ好きなお客様と一緒に楽しみ、旧車に乗れる喜びを分かち合う旧車コミュニティトヨタのキャッシュレス決済アプリ決済プラットフォームで Woven Cityで生み出される発明に貢献開発支援開発支援

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

©KINTO Technologies Corporation. All rights reserved. 17 構文解析 vs 生成 AI • 「オブジェクト名は Lower snake case で定義」 • 構文解析で可能 • 「格納データが推測できるオブジェクト名をつける」 • たとえば「text」「data1」などは意味が曖昧なのでNG • 生成 AI の方が得意 • 理想はレビュー観点に応じた使い分けだが、まず生成 AI のみで実装 • やってみないと分からず、先に挑戦する価値があると判断

Slide 18

Slide 18 text

©KINTO Technologies Corporation. All rights reserved. 18 なぜ自前で仕組みを作るか • 多数のガイドラインを生成 AI で高精度にチェックするタスクは既存のサービス / OSS での対応は現状困難と判断 • 例：GitHub Copilot / PR-Agent / CodeRabbit • フィードバックの方法を柔軟に調整したい • 例：意味が曖昧な「data1」カラムの修正提案は難しくコメントのみに • 将来的に構文解析とのハイブリッド構成で精度向上を目指したい

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

©KINTO Technologies Corporation. All rights reserved. 25 “GenAIOps” ライフサイクルにおける 3 つの評価プロセス出典： Microsoft 社 - 生成 AI アプリケーションの評価 • モデル選定フェーズ • 基盤モデルを評価し、使用するモデルを決定 • アプリケーション開発フェーズ • アプリの出力（≒ 生成 AI の応答）を品質・安全などの観点で評価しチューニング • デプロイ後の運用フェーズ • Production 環境へデプロイ後も品質・安全性などを継続的に評価し改善を続ける

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

©KINTO Technologies Corporation. All rights reserved. 28 モデル選定時に発生するトレードオフ • 「性能」「コスト」「パフォーマンス」のトレードオフ • 一般的には性能が高いほど高コスト、高レイテンシの傾向 • 長期的にはコスト低下傾向 / Fine-Tuning などで同精度・低コスト化も可能 • ユースケースに応じて優先事項を決定出典：Claude 3.5 Sonnet

Slide 29

Slide 29 text

Slide 30

Slide 30 text

©KINTO Technologies Corporation. All rights reserved. 30 モデル選定：ベンチマークスコアの調査 • 「性能」はベンチマークスコアを参考に • タスクで順位変動するが、性能調査のエントリーポイントとして有益 • ユースケースに特化したモデルがあれば第一選択肢に • 例：コーディングなら OpenAI o3-mini 出典：Chatbot Arena

Slide 31

Slide 31 text

©KINTO Technologies Corporation. All rights reserved. 31 モデル選定時のジレンマ • 生成 AI アプリの性能＝基盤モデルの性能＋Prompt Tuning • Prompt Tuning は基盤モデルごとに方針が異なる点も • GPT は Markdown 形式 / Claude は XML 形式 • （チューニング前の）同一プロンプトで各モデルの性能を評価 ? • チューニング次第で順位逆転の可能性 • 各モデル用にチューニングしたプロンプトで評価 ? • チューニング工数が必要以上に肥大する懸念 • ベンチマークスコアの良いモデル＋粗いプロンプトで結果を確認 • 「いけそう」と思えたら次のフェーズへ

Slide 32

Slide 32 text

©KINTO Technologies Corporation. All rights reserved. 32 今回は Claude 3.5 Sonnet を採用 • AWS 上での開発のしやすさから Bedrock 内のモデルに限定 • 性能重視で Anthropic 社の Claude 3.5 Sonnet を採用 • 粗いプロンプトで DDL をレビューさせて一定の精度を確認 • プロンプトチューニングでさらに高い精度が期待できると判断

Slide 33

Slide 33 text

Slide 34

Slide 34 text

©KINTO Technologies Corporation. All rights reserved. 34 磨かれた（Polished な）プロンプトをデプロイするために出典： Anthropic 社 - Create strong empirical evaluations 1. テスト用のデータセットを作成 2. 評価とプロンプトチューニングを繰り返す • 「推論結果が期待にどれだけ近いか」などの評価観点を • 「何らかの方法で算出したスコア」として定義して • 「最良のスコアを得たプロンプト」を採用 • 定量化でチューニング前後の比較時の曖昧さを排除 & 自動化もできるとベスト

Slide 35

Slide 35 text

©KINTO Technologies Corporation. All rights reserved. 35 生成 AI の評価観点をブレークダウン • Evaluation = Quality + Compliance by deepchecks • さらに「真実性」「安全性」「公平性」「堅牢性」などの観点に分類 • 同じ観点でも、算出方法はアプリケーションの特性に応じて選ぶ必要性 • 例：Amazon Bedrock でも、タスクごとに異なる指標を使用 Amazon Bedrock のモデル評価ジョブにおけるスコア算出方法まとめ

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

©KINTO Technologies Corporation. All rights reserved. 40 実例：DDL レビューの評価設計 - Quality • スコア算出は Code-based アプローチを選択 • 正解との完全一致をベストスコアにしつつ、類似度を定量化できるため • 算出ロジックは「レーベンシュタイン距離」を採用 • 完全一致で距離「0」、値が大きいほど類似度が低いとみなす • 「DDL の類似度」をはかるベストな指標ではない • 基本的は全データセットでスコア 0 （完全一致）を目指してチューニングする方針

Slide 41

Slide 41 text

©KINTO Technologies Corporation. All rights reserved. 41 実例：DDL レビューの評価設計 - Compliance • 今回は不要と判断 • 社内向けアプリケーション • プロンプトに埋め込むユーザー入力を DDL に限定する実装 • Compliance はクラウドベンダ提供のガードレール機能が便利 • ユーザー向けチャットアプリ等、セキュリティリスクがあれば必須 • 例：Amazon Bedrock のガードレール • 固有のポリシーに基づいた入出力の評価 • ポリシー違反のユーザー入力、FM応答をブロック（評価＋フィルタリング機能）

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

©KINTO Technologies Corporation. All rights reserved. 46 チューニング結果：プロンプトをデプロイ可能と判断 • 60 個のデータセットほぼ全てにおいて、最良の結果（0）を達成 • 専用アプリ開発により、チューニングと自動評価の高速ループが可能に出典： Anthropic 社 - Create strong empirical evaluations

Slide 47

Slide 47 text

©KINTO Technologies Corporation. All rights reserved. 47 Claude のベストプラクティスに則ったプロンプトチューニング • ロールを設定 • XML タグを活用 • Claude に思考させる • 思考過程の出力を指示し、期待外れの回答時にデバッグを容易に • Few-Shot Prompting（出力例を提示） • 参照データを冒頭に、指示を末尾に配置 • 明確かつ具体的な指示を与える • プロンプトを Chain させる出典：Anthropic 社 - プロンプトエンジニアリング

Slide 48

Slide 48 text

©KINTO Technologies Corporation. All rights reserved. 48 チューニング：プロンプトを Chain させる • 1 回で全ガイドラインをチェック → 数が増えるほどプロンプトが複雑化 • LLM によるチェック漏れや精度低下の懸念が高まる • 1 回のプロンプト実行で AI にチェックさせる項目を 1 つに限定 • 推論により得た「修正後の DDL」を次のプロンプトへの入力として渡し（Chain）、繰り返し処理して最終的な DDL を得る仕組みに • Step Functions 内のループで実装

Slide 49

Slide 49 text

©KINTO Technologies Corporation. All rights reserved. 49 プロンプトの Chain によるメリット / デメリット • メリット • プロンプトが短く、タスクが 1 つに絞られるため精度が向上 • ガイドライン追加時は新規プロンプトを作成 → 既存プロンプトへの精度影響なし • デメリット • LLM の Invoke 回数が増えるため、応答時間と金銭的コストは増加

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

©KINTO Technologies Corporation. All rights reserved. 52 LLM-as-a-Judge における評価基準（Criteria）の設計 • 2 つの Criteria を独自に定義（1-10点） • Appropriateness • LLM の出力がガイドラインに沿って適切に修正されているか • Formatting Consistency • 不要な改行や空白などが付与されておらず、フォーマットの一貫性が保たれているか

Slide 53

Slide 53 text

Slide 54

Slide 54 text

©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 による監視

Slide 55

Slide 55 text

©KINTO Technologies Corporation. All rights reserved. 55 LLM-as-a-Judge の信頼性について • 完全に信頼できるものではない • 人間による評価結果と比較して信頼性を測ることが重要とされている • 今回はユーザーの声を集めやすい社内向けシステム • 定量的なスコアで継続的にモニタリング＋ユーザーフィードバック収集出典：AWS re:Invent 2024 AIM342

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

©KINTO Technologies Corporation. All rights reserved. 58 評価が非常に重要＆難しい • 最初に評価を設計 → チューニング & 評価サイクルを高速にまわせた • 3 つの評価プロセス（モデル選定 / 開発 / 運用）で都度判断が必要 • ユースケースごとに判断する必要があり「評価設計の妥当性判断」が困難 • 評価観点の不足でコンプライアンス面で問題を抱えたままデプロイするリスク • ガードレール、フィルタリング機能の進化である程度マネージドな世界へ

Slide 59

Slide 59 text

©KINTO Technologies Corporation. All rights reserved. 59 テストデータの作成が大変 • 今回は手動で作成 • それなりに時間を要した＆精神的負荷が高い • 自動でテストデータを LLM に生成させる手法も存在 • 別途プロンプト作成とチューニングが必要 • 人間による正確性チェックは入れた方がいい • テストデータはプロンプトチューニングの指針となる非常に重要なデータのため

Slide 60

Slide 60 text

©KINTO Technologies Corporation. All rights reserved. 60 性能が低いモデルほどプロンプトチューニングの工数・難易度が増加 • 最初は Claude 3.0 Haiku / Sonnet / Opus それぞれでチューニング実施 • 性能は Opus > Sonnet > Haiku • Haiku は今回のタスクに対して性能が低すぎてチューニングを断念 • 後から出た 3.5 Sonnet で一気にチューニングが楽に • まずは最高性能のモデルでデプロイし、後から低性能モデルを Fine-tuning して Quality と Cost のバランスを取るアプローチも有効