1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kouki_y

【AgentOps】AIエージェントの評価・テストはどう設計する？Google指針とOSS事例から学ぶ実践知見

1
Posted at

初めに

どうも、某自社開発系の会社でエンジニアをしている者です。

私は去年の年末ごろ、業務の方でAIエージェントが絡んだ機能の開発を担当していました。
その際、AIエージェントの運用設計（AgentOps）、特にその中核となる「評価方法」についても設計する機会を頂けました。
今でも勿論そうですが、当時は情報がかなり少なく自分でも一次情報を求めて奔走していました。

この記事では、AgentOpsを設計する際に実際に調べた事やそこで得られた知見を備忘録的にまとめたいと思います。

こういった0から1を考える際、生成AIに頼り切るのはまだ難しい現状があると思います。
この記事では評価設計の知見は勿論、自分の辿った思考プロセスが誰かの参考になればと思います。

AgentOps とは？

まず初めにAgentOpsについて軽く説明しますが、詳しくはご自身で調べて頂ければと思います。

AgentOpsとは、AIエージェントを安全かつ継続的に運用するための枠組みのことを指します。

従来のソフトウェア開発を監視するDevOpsや、機械学習モデルを監視するMLOpsから派生して生まれた考え方です。

AIエージェントの現実

まず前提として、AIエージェントが組み込まれているシステムの運用は辛いというのがあります。

  • プロンプトを少し手直しする度に毎回動作検証をする必要がある
  • モデルを切り替えた際、プロンプトもモデルに合わせて手直しする必要がある
  • 使っているモデルがバージョンアップした時もプロンプトを直す必要がある
  • 利用中のモデルがサイレントアップデートされていきなり挙動が変わる
  • AIエージェントの挙動を予測し切る事は困難であり、どんなに動作確認したとしても上手く動かないパターンは潰しきれない
  • ある日いきなりAIエージェントが無限ループを起こし、高額コストの発生といった事故につながる可能性がある
  • AIエージェントがどういった思考でその動作をしたかを後から追跡するのが難しい

このように、少しの変更だったとしても必ず動作確認が付きまといます。
また、GeminiのようなエンタープライズのLLMに依存している場合はアップデートに追いつく必要があります。
バージョンアップは勿論ですが古いLLMは提供終了になる事もありますので、そうなる前に工数を割いて新しいバージョンにあげる必要があります。
勿論その際も動作確認を毎回する必要があり、保守コストがバカになりません。

厄介なことに、LLMはプログラムのコードと違って、毎回のように出力内容が変化します。そのため、どうしても動作確認をし切るのが難しくなります。
AIエージェントの挙動を100%予測し切るのは不可能であり、予想外の挙動をする事もあります。
また、ただプログラムのログだけを見てもAIエージェントの思考回路までデバッグし切るのは不可能です。

こういった現実がある以上、AIエージェントを監視・評価できる体制を作って継続的に運用できるようにする必要があります。
さもないと保守・運用が恐ろしい事になってしまいます。

AgentOps の必要性

そこで生まれたのがAgentOpsという考え方です。
これらの問題を解消するために、AgentOpsではAIエージェントに対して以下の仕組みを整備すべきと考えられています。

  1. 可観測性（オブザーバビリティ）
    • 実行に対しては適切にログやトレース結果を残し、後から実行結果を追跡する仕組み。
    • プログラムの実行結果は勿論、AIエージェントの思考内容を残すこともここの要件に含まれる。
  2. ガードレール
    • AIエージェントに対して絶対にやってはいけない事を整理する仕組み
      • 個人情報の漏洩や有害コンテンツについて予めブロックしたり、高リスクな行動は人間の承認を得る等
    • ここを整備する事で、AIエージェントが予想外の挙動を取る事の防止に繋がる
  3. コストとパフォーマンス管理
    • トークン消費量やAPIコスト、処理時間をリアルタイムで追跡できるようにする仕組み。
    • 予想外のコストを抑えるのは勿論、意図せず動作時間が伸びてしまっているパターンの防止にも繋がる。
  4. 評価とフィードバック
    • 品質維持と継続的改善のために、「観測 → 改善 → 評価」を回す仕組み。
    • ここを整備する事でAIエージェントの動作精度向上は勿論、モデルやプロンプト更新の度の動作確認も効率化可能。

これらの仕組みを取り入れる事で、AIエージェントを効率的かつ継続的に運用していくための仕組みを作るという考え方です。

AIエージェントにおける「評価」の難しさ

先ほど挙げたAgentOpsの枠組みにおいて、1～3についてはどうすれば良いかピンと来る人も多いのではないのかなと思います。

「可観測性」と「コストとパフォーマンス管理」に関してはAgentOpsに限った話では無く、通常のソフトウェア開発やクラウドインフラの運用でも考慮すべき部分です。
これまでプログラムに適用していた考え方をAIエージェントへ応用する形をとるため、イメージしやすいと思います。

「ガードレール」については、システムプロンプトレベルでの制御を加えたり、LLMの出力結果に対してプログラムレベルでのバリデーションを行う事で対処可能な部分も大きいです。
比較的身近な概念ではあると思うので、イメージが付く方も多いと思います。

では、AIエージェントの評価はどのように行う必要があるのでしょうか？
前述の通り、AIエージェントの出力には決定性が無く、毎回結果が変わってしまいます。
ですので、プログラムの単体テストと違い毎回固定値で評価するというのが非常に難しいです。

AIエージェントのプロトタイプはすぐにできても、それを本番運用レベルまで品質を担保するのが非常に難しいという性質を持っています。
だからこそこの「評価」というのが大事になってくるのですが、これに関してはどうすれば良いのかピンと来ない人が多いと思います（当時の私はそうでした）

ですので私はこのAIエージェントの評価をどう行うかというのにかなり頭を悩ませました。
ここからはAgentOpsの中の「評価とフィードバック」について重点的に書いていきたいと思います。

AIエージェントの評価において実際に調べた事

ここからは筆者が実際にAIエージェントの評価方法を設計する際に調べた手順や内容を書いていきます。

著:Google様 Prototype to Production を読む

私がAIエージェントの評価を設計し始めた当時、何をどうすれば良いのか全く分からず困っていました。
そんな時、ちょうどいいタイミングで天下のGoogle様から「Prototype to Production」が発表されました。

これはGoogle様から発表されたAgentOpsについてまとめられたホワイトペーパーです。
タイトルの通り、AIエージェントを試作品から本番へ移行させるためのガイドラインが書かれています。

「Prototype to Production」の概要

「Prototype to Production」は全編英語で書かれています。内容の理解は生成AIにフルで助けてもらいました。

この概要はNotebookLMに生成してもらって私の方で調整してます。

このホワイトペーパーは、Googleが発表したAIエージェントの本番運用（AgentOps）に関する実践的な技術ガイドです。

プロトタイプを作るのは容易ですが、それを企業で安心して運用できるレベルに引き上げるには、インフラ・セキュリティ・評価検証といった「ラストマイル」に開発努力の約80%が費やされると指摘されています。

ホワイトペーパー全体は、主に以下の3つの軸で構成されています。

  1. 評価を中心としたCI/CD

    • 従来ソフトのテストだけではエージェントの動的な自律挙動をカバーできないため、「評価」を品質ゲートとしてCI/CDパイプラインに組み込む重要性を解説している。
    • カナリアデプロイなどの安全なロールアウト戦略や、入力フィルター・ガードレールによる多層防御を定義している。

  2. 本番運用モデル（Observe ➔ Act ➔ Evolve）

    • 本番稼働後は、Logs/Traces/Metricsによる「Observe」やサーキットブレーカー等による「Act」を実施する。さらに本番の失敗事例をテストケースへ還元する「Evolve」のサイクルを回し続ける運用モデルを提示している。

  3. マルチエージェント連携

    • 単一エージェントにとどまらず、組織内の複数エージェントを連携させるアプローチを提示している。ツール呼び出し用の「MCP」と、自律対話を行う「A2A」プロトコルの役割分担を整理している。

一言でまとめると、予測困難なAIエージェントの品質と安全性を継続的に担保する仕組みを体系化した資料となっています。具体的には、「評価ゲート付きのCI/CD」と「本番環境でのObserve ➔ Act ➔ Evolveループ」が提示されています。

AIエージェントの代表的な評価手法

ここからは人間が書いてます。

このホワイトペーパーでは、AIエージェントの評価手法についても触れられていました。
それによると、大きく分けて2つの代表的な手法があります。

  1. ゴールデンデータセット
    • 人間が用意した正しい応答に基づくテストケース群
    • 人間が用意したテストケースとAIエージェントが出した結果を比較してテストを行う手法
    • LLMが返す結果を人間で作る事ができるのであればこの手法
  2. LLM-as-a-judge
    • 実行役のLLMが出力した結果を、審査役の別LLMに評価させるというやり方
    • AIエージェントの出力を人間が予測しづらく、プログラムによる結果の比較も難しい場合はこの手法
    • 基本的には最大限頭の良いモデルを使った方が良さげ

AIエージェントの評価にはこれらの手法のどちらか、あるいは両方を組み合わせて行う事が多いと書かれています。

ゴールデンデータセットでは、人間がLLMに返して欲しい結果を予め用意しておき、従来の単体テストのような感覚で比較検証するアプローチです。これは、AIエージェントの出力が構造データのようなプログラムでの検証ができる場合に有効です。

それに対してLLM-as-a-judgeは、評価用のLLMにAIエージェントの評価を任せるというアプローチです。AIエージェントの返す結果が画像や文章のような非構造データの場合はこの手法が有効です。

これらの手法を組み合わせるというパターンも存在します。ゴールデンデータセットを用意し、その出力をLLM-as-a-judgeに採点させるというアプローチです。

これら評価の手法をCI/CDのパイプラインとして組み込むことで、前述した動作確認の手間を効率化する事がAgentOpsにおける評価プロセスになります。

個人的な所感

このホワイトペーパーを読んで最も共感した部分は、「プロトタイプを作ってから本番まで持っていくのが一番大変」という部分です。

実際自分もAIエージェントを作っていて、動きはするけど果たしてこれで完成だと言ってしまって良い物かと頭を悩ませました。
あのGoogle様がそう言っているのだから、全エンジニアが悩ませている課題なんだなとこの時思いました。

個人的に最も心に響いた格言が「AIエージェントを作るのは簡単、信頼するのが難しい」です。

ここからは、AIエージェントを信頼するためにこれら手法をどう具体的に実装するかに迫っていきます。

オープンソースのAIエージェント系リポジトリを探検して評価手法を探る

「Prototype to Production」で評価手法について理解した後、私はこれらの手法を具体的にどう実装すべきなのかを調査しました。
どう調べるべきなのか頭を悩ませましたが、やはり先駆者がどう実装しているのかを見るべきだと考え、OSS系のリポジトリでの評価体制を調査する事にしました。

ここからは実際に私が調査した3つのリポジトリと採用されている評価手法をまとめたいと思います。

去年の年末～今年の年始頃に調査した内容を元に執筆しています。
再調査はしていますが、情報に齟齬があった場合は申し訳ございません。

1. Browser Use

AIエージェントにWebブラウザを人間のように操作させ、各種タスクを自動化するためのオープンソースのPythonライブラリです。

  • playwright を立ち上げて実際にブラウザ操作をさせて意図した動作をやってくれるかテストしてる
    • 「アマゾンで商品をカートに入れる」「Googleで検索する」みたいなタスクを事前に定義しておいて、それを意図通りこなせているかテストする感じ
  • テストの際はAIエージェントに過程と結果を出力させ、それを評価用のLLMが評価するという手法
  • 手法としては LLM-as-a-judge
  • 関連ページ

2. Tongyi Deep Research

Alibaba が公開した Deep Researchをオープンソースで再現しようとしているプロジェクト
https://github.com/Alibaba-NLP/DeepResearch

  • json 形式で質問とその回答のデータセットを用意して、エージェントが回答通りの出力をしてくれるかテストをする
{"question": "フランスの首都は？", "answer": "パリ"}
{"question": "(ファイル 'report.pdf' をアップロード): 主要な発見は？", "answer": "売上が20%増加したこと..."}
  • AIエージェントの回答はどうしても文章になるため、評価用のLLMに出力をテストさせるやり方。
  • 手法としては ゴールデンデータセット + LLM-as-a-judge
  • 関連ページ

3. OpenHands

AIによる自動コーディングエージェント。ブラウザでドキュメントを調べ、プログラムを書き、テスト実行をし、エラーが出たらログを見て修復する、みたいな機能を内包してる。
https://github.com/OpenHands/OpenHands

  • 評価体制としては主に2つ
    • AIエージェントに予め設定した課題でコードを生成させ、生成したコードに対してあらかじめ用意したテストコードを走らせる
      • 設定した課題とそれに対するテストコードがゴールデンデータセットになる
    • AIエージェントが出力した複数のコード案に対して、評価担当の別モデルが最適なコードを評価する
      • このモデルは独自に作ってるらしい
  • 手法としてはLLM-as-a-judge、ゴールデンデータセット、コードによる評価 のハイブリッド
  • 関連ページ

個人的な所感

オープンソースのAIエージェント系リポジトリの中で、スター数が多い物をピックアップして調査しました。
逆にスター数が少ないリポジトリは評価体制が整って無さげなのが多かったです。
世の中のAIエージェントって果たしてすべて検証されているのか少し不安になってきてしまいますね。

実際に調べて見て最も感じたことは、AIエージェントの評価に銀の弾丸は存在しないという事です。
どのリポジトリもAIエージェントの性質によって採用している手法が全く違うため、コピペで通じるパターンがほぼ存在しないと痛感しました。

これらの手法は知見として頭に刻みつつ、各々が開発しているAIエージェントに対して具体に落とし込むことが大切だと理解しました。
正直、当時の自分は答えを追い求めて調査をしていた節がありました。しかし、このAI時代においてその点に気付けたことが、一番の収穫でした。

今後このAIエージェントの評価手法は時代が進んでいずれ集合知が形成されていって新たな領域として成長していくのかなと予想しています。

終わりに

以上が、AgentOpsを設計した際に行った事と得られた知見になります。

現在AgentOpsの設計に頭を悩ませている方は、とりあえず「Prototype to Production」を読みこめば何かヒントが得られるのではないかなと思います。

この記事が将来の誰かのためになればと思いつつ、私は転職活動を頑張ります。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?