自己紹介 2000年代後半からSAPベーシス、2025年からSAP BDCとJouleを専門に働いています。 今でもSAPGUIでワークロード分析とかやってます。 JouleとかBDCとか、新しいことが大好きですが、古いことも大好きです。 最近は、SAPNote 3255746 - Unpermitted usage of ODP Data Replication APIs で巷をざわつかせている、ODP-RFCインターフェース経由でのSAPデータ抽出に関する対応についても取り組んでおります(興味がある方はいつでもご相談ください)。 新しい技術は好きですが、新しすぎる技術の「公式ドキ

こんにちは！AIエージェント開発課です。 近年、生成AIの進化スピードは凄まじく、単なるテキストの要約やドラフト生成の枠を超え、自律的に判断してタスクを実行する「AIエージェント」が大きなトレンドとなっています。 このような技術的な潮流の中、私たちのチームは2025年5月に「AIエージェント開発課」として産声を上げました。累計導入社数 約20,000社以上の顧客基盤と、16年以上にわたって蓄積された膨大な業務データ（ドメイン知識）というラクスの強みを活かし、バックオフィス業務の「完全自動化」という未来へ向けて、日々泥臭く開発を続けています。 私たちがメインで取り組んでいるのは、主力プロダクトである「楽楽精算」へのAIエージェント機能の実装です。 この記事では、私たちが直面した「3つの壁」とそれを突破した設計原則、そしてそこで得られた知見を社内の他プロダクトへ共通LLM基盤として還元していくファーストペンギンならではの面白さについて、生々しい試行錯誤のプロセスを交えてお届けします。 「プロダクトへAI機能を実装してみたいけれど、何から手をつければいいかわからない」「大規模言語モデル（LLM）の不確実性を前にアーキテクチャ設計で立ち止まっている」というエンジニアの皆さんに、明日から試せるヒントとして届くことを願っています。 ラクス最先端の挑戦を担う「AIエージェント開発課」とは 主力プロダクト「楽楽精算」をAIネイティブへ進化させるミッション 理想と現実。リリースへ向けて立ちはだかった「3つの壁」 【コストの壁】大規模クラウドサービスならではの推論量とLLM費用の問題 【精度の壁】個社ごとに異なる複雑な社内ルールにどう寄り添うか 【応答速度の壁】完了までの待ち時間、ユーザー体験を損なわないための葛藤 技術的工夫で壁を突破した「設計原則」 「ルールを考えさせる」から「お手本を真似させる」への転換 AIの不確実性を受け入れ、既存のルールベース機能と組み合わせるハイブリッド構成 「定期起動」から「イベント駆動」へ。非同期アーキテクチャ進化の裏側 ファーストペンギンとして「共通LLM基盤」を検証・構築する面白さ ビジネスロジックと責務を分離する「LLMゲートウェイ」の構築 他チームのコンパスとなる「オブザーバビリティ（監視基盤）」の検証・構築 楽楽精算での検証が、他プロダクトの道標になるダイナミズム 技術を「机の上から社会の中へ」実装したいエンジニアへ ラクス最先端の挑戦を担う「AIエージェント開発課」とは AIエージェント開発課は、エンジニアだけでなくUXデザイナーやビジネスサイドのメンバーも内包する、9名のクロスファンクショナルな少数精鋭チームとして立ち上がりました。 従来のラクスの開発スタイルは、「熟考を重ねた綿密な設計と、確実な法要件対応」を最大の強みとしていました。しかし、数日単位で前提が変わる現在のAI領域においては、既存のやり方に縛られない高速な試行錯誤（仮説検証ループ）が求められます。 そこで私たちは、顧客の「一次情報」に最も早くアクセスできるよう、開発本部の枠からあえて飛び出し、ビジネスサイド直結の組織という特異な構造を選択しました。職能の垣根を完全に取り払い、顧客ヒアリングの結果を受けて全員でUI/UXの改善案を出し合うような「オールラウンド型チーム」を醸成するのが狙いでした。 ※現在はファーストリリースを終えたため、開発本部へ戻っています。 主力プロダクト「楽楽精算」をAIネイティブへ進化させるミッション 私たちが最初に課されたミッションは、「楽楽精算」における経費申請ワークフローの自動化、すなわち「伝票作成AIエージェント」の開発です。 従来の経費精算では、申請者がスマートフォンなどで領収書をアップロードした後、自ら手作業で関連する事前申請やクレジットカードの利用明細をデータの山から探し出し、それらを一つひとつ目視で確認しながら紐付ける必要がありました。この「めんどくさい」「煩わしい」という体験を、AIエージェントの力で根本から変えることが私たちの目的です。 利用イメージとしては、ユーザーが領収書を選択するだけで、AIエージェントがその内容を意味的に推論し、関連するデータを裏側で自動的に探し出して申請用の伝票の下書きを作成します。申請者は、最後に「内容を確認するだけ」という、入力作業ゼロの世界を目指す挑戦が始まりました。 理想と現実。リリースへ向けて立ちはだかった「3つの壁」 「領収書を投げれば、AIが考えていい感じに伝票をつくってくれる」と言葉にするのは簡単ですが、いざ本番運用を前提とした開発に着手すると、AIならではの不確実性と、大規模なプロダクトゆえの制約が、重い壁となって私たちの前に立ちはだかりました。 【コストの壁】大規模クラウドサービスならではの推論量とLLM費用の問題 最初の壁は「コスト」でした。 LLMに対して、領収書データ、事前申請の候補リスト、個社ごとの勘定科目マスタ、さらには過去の申請履歴といった大量のコンテキストを愚直に流し込んで推論させると、1リクエストあたりのトークン消費量が爆発的に跳ね上がります。 検証段階でLLM費用の試算を行った際、このまま数万社という規模のお客様に機能を提供すれば、莫大な運用コストが発生し、事業継続性（Viability）が破綻しかねないという現実に直面しました。 【精度の壁】個社ごとに異なる複雑な社内ルールにどう寄り添うか 2つ目の壁は「精度」です。 経費精算というドメインは、法規制だけでなく、「この部署のこの用途なら勘定科目は交際費にする」「交際費の備考欄には必ず同席者の氏名と人数を記載する」といった、企業ごとに異なる明文化しづらい独自のルールが無数に存在します。この独自ルールが汎用的なLLMモデルでの推論精度に大きく影響しました。 【応答速度の壁】完了までの待ち時間、ユーザー体験を損なわないための葛藤 3つ目の壁は、ユーザーが体感する「応答速度（パフォーマンス）」でした。 伝票作成のワークフローの中で、データの検索、仕訳の推論、構造化出力の生成など、複数回のLLM呼び出しを同期的に（順番に待ちながら）実行する設計にしていたため、画面のローディングが完了するまでに最低でも5～15分という、とてつもない時間がかかってしまうことが判明しました。 その結果、画面遷移を同期的にすると「自分で入力した方が早い」という感想を持たれてしまったのです。この応答速度の遅さは、リリースを阻む最大のボトルネックとして私たちの前に横たわっていました。 技術的工夫で壁を突破した「設計原則」 これらの課題に対して、私たちは「最新のモデルをただ叩く」というアプローチを捨て、ラクスが大切にしてきた「顧客志向（誰のどんな課題を解決するか）」の原点に立ち返り、泥臭いアーキテクチャの変更と設計原則の再定義を行いました。 「ルールを考えさせる」から「お手本を真似させる」への転換 開発が大きく前進したブレイクスルーは、β版公開後のタイミングで導入した「ベクトルDBを用いた過去伝票のコンテキスト注入」でした。 それまでは、LLM自身に「複雑な社内規定や多様な仕訳ルール」を解釈させてゼロから深く推論させようとしていましたが、これでは推論の難易度が上がり、精度が出ないばかりか処理コストも膨らむ一方でした。 そこで私たちは、アプローチを転換しました。過去に確定した膨大な伝票データから、ベクトルDBを用いて「申請者本人が過去に作成した、今回と最も類似している確定伝票（真に正しいお手本）」を高速に検索。そのお手本データをプロンプトの「コンテキストとして補強する」RAGアーキテクチャを採用しました。 LLMに高度なルール解釈を強いるのをやめ、目の前に提示した正しいお手本を「そのまま真似しなさい（Few-Shot）」と指示する。この設計により、LLMが迷うことなく一瞬で正確な伝票を作成できるようになり、精度が劇的に向上しました。さらに、深く考えさせるプロセス（推論の難易度やループ回数）を大幅に下げられたことで、高額な推論コストをカットし、LLM費用を当初の数十分の一にまで抑え込むことに成功したのです。 AIの不確実性を受け入れ、既存のルールベース機能と組み合わせるハイブリッド構成 精度の壁を乗り越えるための私たちの結論は、「AIに完璧を求めない」ということでした。ハルシネーションをプロンプトだけで完全に防ぐのは不可能です。 そこで、AIの責務を「高速にドラフト（下書き）を作成すること」に特化させ、出力されたデータの正当性の担保は、「楽楽精算」が元々持っている強力なルールベースの「規定違反チェック機能」に委ねるというハイブリッドな構成を採用しました。 AIが推論した結果に矛盾や規定違反があれば、既存の強固なシステムが検知して申請前に画面上でユーザーに「確認」を促します。人間が最終的な「確認・承認」の責任を持つ「Human-in-the-Loop」の思想を取り入れたことで、AIの利便性を活かしつつ、業務システムとしての絶対的な安心感と確実性を担保することができました。 「定期起動」から「イベント駆動」へ。非同期アーキテクチャ進化の裏側 応答速度の課題は設計段階からある程度想定していました。伝票作成のような重い処理をユーザーを待たせながら同期的に実行するのは現実的ではないと早い段階で判断し、当初からAWSの「Amazon SQS」を用いた非同期処理をアーキテクチャの前提としていたのです。 とはいえ、ファーストリリース時点では、キューに溜まったリクエストを一定間隔で確認しに行く「定期起動」方式で処理を捌いていました。ところがベータ版として実際にユーザーに使っていただくと、この定期起動の間隔そのものが待ち時間のボトルネックとなり、「思ったより遅い」という声が集まってきたのです。 そこで私たちは、Kubernetesのイベント駆動型オートスケーラーである「KEDA」を導入。キューに溜まった未処理の伝票作成リクエスト数に応じて、K8s jobをスケーリングする仕組みへと進化させました。 この改善を反映したベータ版をリリースした結果、ユーザーは領収書を「まとめて一括で投げる」だけで、ローディングを待つことなく次の画面へ進めるようになり、AIの処理が裏で完了したものから順次、確認・申請ができるという圧倒的にスムーズな体験（従来比約40%の工数削減）へと昇華させることができました。 ファーストペンギンとして「共通LLM基盤」を検証・構築する面白さ 私たちAIエージェント開発課のミッションは、単に「楽楽精算」の機能を良くすることだけではありません。ラクス開発本部のビジョンである「AIネイティブな開発組織への変革」を牽引するファーストペンギンとして、自ら検証したアーキテクチャを全社の「共通LLM基盤」として型化し、波及させていくことに大きなやりがいがあります。 ビジネスロジックと責務を分離する「LLMゲートウェイ」の構築 開発を進める中で、各プロダクトのアカウントから外部のLLMプロバイダーへ直接APIを叩きに行くと、リトライ制御やモデルのバージョン管理、レートリミット対策がアプリケーションコード内に散らばり、保守性が著しく低下するという課題が見えてきました。 そこで私たちは、独立した抽象化レイヤーとして、プロキシ層となる「LLMゲートウェイ」をAmazon EKS上に構築しました。 ここでは、プロバイダーのAPI障害が発生した際に、自動で別リージョンや別モデルへリクエストを切り替える「フォールバック制御」や、一時的なネットワークエラーに対するリトライ処理を一元管理しています。アプリケーション側のビジネスロジックから外部AIへの依存性を完全に分離したことで、外部APIとの接続に関わる改修コストを最小限に抑える足回りを構築しました。もちろん、モデルを差し替えたからといって、そのまま期待通りに動作するとは限りません。モデル固有の出力特性やハルシネーションの傾向変化に伴い、アプリケーション側でのプロンプトの微調整や追加のバリデーション改修は必要になりますが、そうした検証と変更のサイクルを素早く回すための強固な土台となっています。 他チームのコンパスとなる「オブザーバビリティ（監視基盤）」の検証・構築 AIエージェントが本番環境で「今、どんな推論をして、なぜそのエラーを起こしたのか」を追跡する仕組み（トレース収集）は、プロダクト運用において死活問題となります。 私たちは、OpenTelemetry（OTel）Collectorを活用したログ・メトリクス・トレースの収集基盤を他プロダクトに先んじてEKS上に検証・構築しました。 当初、AWS Distro for OpenTelemetry（ADOT) Collectorと呼ばれる配布ディストリビューションを利用していましたが、必要なプラグインが不足していたため、自分たちでカスタムビルドを行うなど、かなり泥臭い対応も経験しています。 この基盤により、Amazon CloudWatchのダッシュボード上に、リアルタイムでのトークン消費量やエラーレート、エージェントの推論プロセス（トレース）が綺麗に可視化できるようになりました。 楽楽精算での検証が、他プロダクトの道標になるダイナミズム 私たちが「楽楽精算」の伝票作成AIエージェントを通じて血を流しながら検証したこれら「LLMゲートウェイ」や「オブザーバビリティ基盤」のアーキテクチャマニフェストは、開発本部全体へ展開され大きな反響を呼びました。 個別最適のサイロ化に陥りがちな複数プロダクトの開発組織において、自分たちの小さな試行錯誤が、数百名の開発体験（DevEx）を一気にAIネイティブへと変革していく「全体最適」のダイナミズムを肌で感じられることこそが、この課で働く最大の面白さだと断言できます。 技術を「机の上から社会の中へ」実装したいエンジニアへ ラクスのAI開発の根底にあるのは、論文の精度を競う研究ではなく、日々の業務の中で実際に動くシステムをつくり、数万社のお客様の働き方を変えていくという「実装主義」の思想です。 AIエージェントという不確実で正解のない未知の領域だからこそ、私たちは完璧を待つよりも、仮説を立てて小さく試すスピードを何よりも大切にしています。 私たちが構築した足回りはまだ完成形ではありません。2030年の「完全自動化」という高いゴールに向けて、これからさらに「個社別のルール最適化」や、「領収書収集から伝票作成までの自動化」、「共通LLM基盤」の整備など、エキサイティングな課題への挑戦が続いていきます。 「AIの力で、働く人の日常を本質的に『楽！』にしたい」 「最先端の技術を自らの手で社会のインフラへと落とし込んでみたい」 そんな熱い顧客志向とAIネイティブな視点を持ったエンジニアのあなたと、これからのクラウドサービスの新しい常識を一緒に創り上げていける日を、AIエージェント開発課一同、心から楽しみに待っています！

LLM as a Judge とは、AI・エージェントの回答品質を自動的に評価する手法の一つで、大規模言語モデル（LLM）を「評価者」として活用し、人手による評価コストを大幅に削減しながら、一貫した基準で大量のテストケースを継続的に評価する方法です。 現在、生成AI（LLM）を自社の業務プロセスや自社プロダクトへ組み込む企業が急速に増えています。しかし、検証を進める中で多くの開発現場が直面するのが「AIの品質管理（QA）の難しさ」という壁です。 AIが出力する結果の妥当性をどう判断し、どのように安定性を担保すればよいのか。本記事では、ドットデータ社が自社製品「 dotData Insight 」などの開発プロセスで検証してきた内容をもとに、AIがAIを自動評価するアプローチ「LLM as a Judge」の基本的な仕組みや考え方について解説します。 なぜAIの品質管理は難しいのか AIプロダクトの品質管理では、従来のソフトウェアテストをそのまま適用してもうまくいきません。理由は以下の通りです。 正解が一つではない 従来のソフトウェア開発（決定的） ：1+1=2のように期待出力の仕様が明確であり、入力に対して出力が常に同じになります。このため 「一つの期待される出力（Expected）」と「実際の出力（Actual）」が完全一致するかどうか を機械的に判定することで、評価できます。 AIエンジニアリング（非決定的） ：同じ入力であっても、モデルの確率的な挙動によって出力が毎回変わり、出力が完全一致することは少ないです。正解は無数にあり、判定は「出力が妥当であるか」という評価が必要です。 仕様の曖昧さと組み合わせの爆発 「分かりやすい原因仮説を考えて出力して欲しい」といった曖昧な仕様による挙動が存在します。さらに、ユーザーとの対話プロセス（コンテキストの積み重ね）が加わることで、出力パターンは無数に広がり、組み合わせの爆発が起こります。これを人間がすべて網羅してテストすることはできません。 ハルシネーションと「80点の壁」 一見それらしく見えるもっともらしい誤情報（ハルシネーション）を出力することがあります。開発の初期段階で「なんとなく動く80点レベル」のプロトタイプを作るのは容易ですが、そこから製品・実業務レベルへ品質を引き上げ、モデルのアップデート時にも品質を維持し続けること（「80点の壁」の突破）が容易ではありません。 LLM進化への追従 近年のAIの進化の速度は非常に早く、日々、コストや性能が異なるモデルがリリースされ続けています。モデルのアップデートも頻繁に行われるため、新しいモデルごとにAIの品質を人手でチェックしていては時間とコストの面で追いつきません。 LLM as a Judgeとは何か LLM as a Judgeとは、出力を生成するAIとは別に評価専用のAIを用意し、AIの品質評価を自動化する方法です。 基本的な流れは次の通りです。 機能AIが、入力データやユーザー指示に対して出力を生成する 評価AIが、評価基準（ルーブリック）と評価データセットを参照する 評価AIが、機能AIの出力を採点し、理由やコメントを返す 開発チームが、スコア、コメント、ばらつきを見て品質を判断する 必要に応じて、プロンプト、モデル、評価基準、評価データセットを改善する この方法を使うと、人間がすべての出力を個別にレビューする代わりに、評価AIが大量のテストケースを一貫した基準で評価できます。また、モデルを変更した場合も、同じ評価基準で比較できるため、継続的なAI品質管理に活用できます。 ただし、LLM as a Judgeで重要なのは「評価AIに任せること」ではありません。人間が何を良い出力とみなすのかを定義し、その基準を評価AIが再現できるようにすることです。 LLM as a Judgeを機能させる3つの要素 LLM as a Judgeを品質管理の仕組みとして使うには、評価基準、評価データセット、評価AIの3つをセットで設計する必要があります。 要素 役割 設計時のポイント 評価基準 何を良い出力とみなすかを定義する 合否で判定する条件を実例とともに精緻に設計する 評価データセット 評価対象となる入力、期待される出力例、望ましくない出力例を用意する Good例、Bad例、グレーケースを含める 評価AI ルーブリックに基づいてAI出力を評価する 評価理由を返し、複数回評価でばらつきも確認する 評価基準だけがあっても、評価対象となるデータが不十分であれば品質は測れません。反対に、テストデータだけを増やしても、何を基準に合否やスコアを判断するかが曖昧であれば、評価結果は安定しません。 LLM as a Judgeでは、評価基準と評価データセットを整合させ、評価AIがその基準を再現できているかを確認しながら運用することが重要です。 評価基準の設計 LLM as a Judgeの精度を左右するのが、評価基準（ルーブリック）です。ルーブリックとは、出力が満たすべき品質条件を具体的に定義したものです。 ルーブリックは、ハードルールとソフトルールに分けて設計すると整理しやすくなります。 種類 役割 判定方法の例 ハードルール 出力が必ず満たすべき条件を定義する OK/NGで判定する ソフトルール 主観や曖昧性を含む品質を評価する 0〜3点などの段階スコアで評価する ハードルールは最低限の合格条件を定義する ハードルールは、出力が満たすべき絶対条件です。条件を満たしていない場合、どれほど自然な文章に見えても品質上はNGと判断します。 dotData Insightのカラムエンリッチ機能を例に考えます。カラムエンリッチ機能とは、与えられたデータに対して、四則演算により分析に役立つ新しい特徴量を自動設計・抽出する機能です。 たとえば、ローン申請データに次のような列があるとします。 年齢 性別 年収 ローン金額 支払期間（月数） この入力に対して、AIが「返済負担率」という追加カラムを提案する場合、次のような出力が考えられます。 項目 例 カラム名 返済負担率 算出方法 （ローン金額 / 支払期間（月数）） x 12 / 年収 x 100 解説 収入に対して、年間のローン支払い金額がどの程度の割合を占めるかを表す値です。 このとき、数式として計算できるだけでは十分ではありません。ビジネス的、物理的に意味が通るかを評価する必要があります。 ハードルールの例は次の通りです。 評価項目 判定基準 OK/NGの考え方 単位の整合性 計算自体は可能でも、ビジネス的・物理的に無意味な数式になっていないこと 「売上合計 / 来店者数」は来店者あたり売上として解釈できるためOK。「周波数 / 電圧」は業務指標として意味が説明できなければNG 定数の妥当性 計算式に登場する定数に直感的な解釈があり、不要な数値が混入していないこと 為替レートの近似値としての定数は説明できる場合がある。一方、理由のない +1 はNGになりやすい ハードルールでは、評価AIが迷わないように、何を満たせばOKで、何があればNGなのかを明確にします。 ソフトルールは曖昧な品質をスコア化する 一方で、AI出力の品質には、完全なOK/NGで判定しにくい観点もあります。たとえば、提案されたカラム名が「直感的に理解しやすいか」は、一定の主観を含みます。 このような品質は、段階的なスコアで評価します。 例として、次の数式に対するカラム名を評価します。 （ローン金額 / 支払期間（月数）） x 12 / 年収 x 100 スコア 評価 カラム名の例 判定基準 3点 Perfect 返済負担率 計算式の意味を正確に表し、業務担当者にも直感的に伝わる 2点 Good ローン・年収比率 概ね妥当だが、やや抽象的で説明を補う余地がある 1点 Poor 返済インデックス 計算式の意味を推測しにくい 0点 Failure 年間支払利息 計算式の説明として誤っている ソフトルールでは、単に点数を付けるだけでなく、なぜその点数になるのかを説明できる基準が必要です。評価が割れやすいケースを蓄積し、どのような場合に2点と3点を分けるのかを具体化していくことで、ルーブリックの品質が上がります。 評価データセットの作り方 評価データセットは、ルーブリックに沿って評価するための材料です。LLM as a Judgeでは、入力データだけでなく、期待される出力例や望ましくない出力例もセットで準備します。 基本構成は次の3つです。 入力データ: AIへ与える入力 Good例: 期待する出力例 Bad例: 避けたい出力例 カラムエンリッチ機能の例では、次のような評価データセットを用意できます。 項目 例 入力データ ローン申請テーブル（年齢、年収、申請額、支払期間（月数）） Good出力例 カラム名: 毎月支払額。計算式: 申請額 ÷ 支払期間（月数）。解説: ローン金額を支払期間で割ることで算出される月々の返済額。返済負担を把握するのに有用。 Bad出力例 カラム名: 一人当たり所得。計算式: 年収 ÷（子どもの数 + 1）。解説: 本人および子どもを含めた1人当たりの所得。 テストケースは、代表的なケースとエッジケースだけでは不十分です。LLM as a Judgeでは、グレーケースを含めることが重要です。 ケース 内容 目的 代表的なケース 実務で頻繁に出る標準的な入力 基本品質を確認する エッジケース 極端な入力、境界条件、例外的なパターン 想定外の破綻を見つける グレーケース 人間でも判断が分かれやすい入力や出力 評価基準の曖昧さを発見する グレーケースは、評価基準を改善するための重要な材料です。たとえば、「正確だが専門的すぎる」「分かりやすいが厳密さに欠ける」といった出力は、単純なOK/NGでは扱いにくいものです。こうしたケースを蓄積し、人間のレビュー結果と照らし合わせながらルーブリックを更新することで、評価AIの判断を安定させやすくなります。 評価の実行と結果の見方 評価AIは、ルーブリックと評価データセットを使って、機能AIの出力を採点します。評価結果では、スコアだけでなく、評価理由やコメントも確認します。 たとえば、カラムエンリッチ機能に対する評価結果は、次のような形で整理できます。 指標 Run1 Run2 Run3 平均 標準偏差 ハードルール達成率 100% 100% 100% 100% 0.0 解釈性（0〜3点） 3 2 3 2.7 0.5 説明文品質（0〜3点） 3 2 2 2.3 0.6 総合スコア（100点） 95 89 94 92.7 3.2 この結果を見るときは、平均スコアだけで判断しないことが重要です。ばらつきが大きい場合、プロンプト、ルーブリック、評価データセットのどこかに曖昧さが残っている可能性があります。 評価コメントも重要です。たとえば、次のようなコメントが返ると、改善すべき箇所が見えやすくなります。 ハードルールはすべて満たしており、数式としての妥当性に大きな問題はない カラム名は概ね適切だが、「返済負担率」と「ローン・年収比率」のどちらを高く評価するかで判定にばらつきがある 説明文に曖昧な表現があり、ルーブリックで説明文品質の基準を追加する余地がある LLM as a Judgeの評価結果は、合否を機械的に決めるためだけのものではありません。どの品質観点が安定しており、どの品質観点に改善余地があるのかを把握するための材料です。 評価は1回ではなく統計的に行う 生成AIは非決定的に動作します。同じ入力でも、プロンプト、モデル設定、文脈の違いによって出力が変わることがあります。評価AIも同様に、曖昧なケースでは評価が揺れる可能性があります。 そのため、LLM as a Judgeでは、一度だけの評価スコアで品質を判断せず、複数回実行した結果を見ます。 確認すべき観点は次の通りです。 平均スコア: 品質水準がどの程度か 標準偏差や分散: 評価や出力がどの程度安定しているか ハードルール違反の有無: 最低条件を満たしているか 評価コメントの傾向: どの観点で改善が必要か 人間レビューとの一致: 評価AIが人間の判断を再現できているか ばらつきが大きい場合、機能AIの出力が不安定なだけでなく、評価基準自体が曖昧である可能性もあります。この場合は、出力側だけでなく、ルーブリックや評価データセットを見直す必要があります。 評価AIにはより高性能なモデルを使う LLM as a Judgeでは、評価AIに機能AIよりも推論能力の高いモデルを使うことが推奨されます。理由は、評価そのものの精度が、改善サイクル全体の品質を左右するためです。 機能AIは、ユーザー向けの応答速度やコストの制約を受けます。一方、評価AIは開発・検証環境でバックグラウンド実行されることが多く、多少時間がかかっても高精度な判断を優先しやすい領域です。 評価AIに期待する役割は、単に点数を返すことではありません。次のような判断を行う必要があります。 ルーブリックの各項目に照らして、どこが満たされているか 出力のどの部分が評価に影響したか どの品質観点で改善余地があるか 人間レビューが必要なグレーケースか 評価AIの品質を確認するには、人間が評価した結果（Golden Set）との一致率や相関を定期的に見ることが有効です。評価AIが人間の判断からずれている場合は、評価プロンプト、ルーブリック、データセットのいずれかを改善します。 LLM as a Judge導入時の注意点 LLM as a Judgeは便利な仕組みですが、設計を誤ると、品質管理の精度を高めるどころか、誤った安心感につながることがあります。導入時には、次の点に注意が必要です。 注意点 内容 対応策 ルーブリックが曖昧 評価AIが判断基準を安定して再現できない OK/NG例、スコア別基準、グレーケースを追加する 評価データが偏る 実運用で出る入力を十分にカバーできない 代表ケース、エッジケース、失敗事例を継続的に追加する 評価AIを過信する 評価AI自身の誤判定を見落とす Golden Setとの一致率を確認し、人間レビューを残す スコアだけを見る 改善すべき品質観点が分からない 評価理由、コメント、ばらつきを併せて確認する 生成と評価を同じプロンプトに詰め込む 自己評価のバイアスや文脈負荷が起きやすい 機能AIと評価AIの役割を分ける 特に、機能AI自身に自己評価させるだけでは不十分な場合があります。生成と評価を同じプロンプト内で行うと、AIが自身のミスを見落としやすくなります。また、生成と評価の指示が混在することで、どちらの精度も下がる可能性があります。 LLM as a Judgeでは、機能AIと評価AIの役割を分け、評価AIにはルーブリックに沿った判断をさせることが基本です。 dotData Insightの開発における品質管理との関係 dotDataでは、dotData Insightなどの開発プロセスにおいて、生成AIを活用した機能の品質管理を検証してきました。dotData Insightは、業務部門がデータからインサイトを導くためのデータ分析プラットフォームです。業務データから隠れたパターンを抽出し、生成AIが分析結果のビジネス解釈や要因仮説の設計を支援します。 このような機能では、出力が単に文法的に自然であればよいわけではありません。業務上の意味が通っているか、データから導ける内容になっているか、利用者が次の判断に進める説明になっているかを確認する必要があります。 LLM as a Judgeの考え方は、こうしたAI機能の品質を継続的に検証するうえで有効です。評価基準を定義し、評価データセットを整備し、評価AIで出力を確認することで、AI機能の改善サイクルを回しやすくなります。 生成AIを活用したデータ分析や、自社のデータ活用・DX戦略に関心がある場合は、dotData Insightの製品情報や業界別ソリューションも参考になります。 dotData Insight 製品ページ 業界別ソリューション・導入事例 まとめ LLM as a Judgeは、生成AIの出力を評価するために、評価専用のAIを使う品質管理の方法です。AIがAIを評価する仕組みではありますが、評価の出発点は人間が定義する品質基準にあります。 AI品質管理で重要なのは、次の3つです。 評価基準（ルーブリック）: 何を良い出力とみなすかを定義する 評価データセット: Good例、Bad例、グレーケースを含むテストデータを準備する 評価AI: ルーブリックに基づいて出力を評価し、スコア、理由、ばらつきを確認する 生成AIを実ビジネスで活用するには、「AIが動くこと」だけでは不十分です。AIの出力品質を継続的に評価し、改善できることが重要です。 LLM as a Judgeは、人間を置き換える仕組みではありません。人間が定義した品質基準を、大規模かつ再現可能な形で適用し、AI開発の品質を支えるための仕組みです。 実際の開発では、評価基準をどのように改善するか、評価データをどのように収集・更新するか、評価AIと人間レビューをどう組み合わせるかも重要になります。LLM as a Judgeを導入する際は、評価を一度作って終わりにせず、プロダクトや業務の変化に合わせて継続的に見直すことが大切です。 The post AIがAIを評価するとは？LLM as a JudgeによるAI品質管理の基礎 appeared first on dotData .