【ITニュース解説】How to Write Your First AI Agent Evals

AIエージェントは、単に情報を提供するだけでなく、外部のツールを使ったり、複数のステップを経て複雑なタスクをこなしたりする、より自律的なソフトウェアの総称だ。例えば、顧客の質問に答えるチャットボットが、内部データベースを検索し、必要に応じて予約システムを操作するといった一連の処理を自動で行う場合、それはAIエージェントと呼ぶことができる。従来のプログラムが明確に定義された手順を実行するのに対し、AIエージェントは与えられた目標に基づいて自ら判断し、行動を決定する能力を持つため、その開発と運用には特別な注意が必要となる。

このようなAIエージェントを開発する上で不可欠なのが、その振る舞いを評価し、検証するための「Evals（イーバルズ）」という仕組みだ。Evalsは、AIエージェントが意図した通りに機能するか、あるいは予期せぬ問題を起こさないかを客観的に確認するための評価およびテストの一種である。システムエンジニアが通常のソフトウェア開発において、単体テストや結合テストを通じてプログラムの品質を保証するのと同様に、AIエージェントにおいてもEvalsは、その信頼性と安全性を確保するための重要なプロセスとなる。

Evalsを作成する主な目的は、AIエージェントの性能を測定し、その改善点を発見することにある。AIエージェントは、学習データや運用環境によってその振る舞いが変化する可能性があるため、継続的な評価を通じて、常に最適な状態を維持することが求められる。Evalsは、開発したエージェントが「何をできて、何をできないのか」を明確にし、潜在的なバグや不具合を早期に発見するための指針となる。

では、Evalsの最初の評価ケースはどこから生まれるのだろうか。最も効果的なEvalsケースは、AIエージェントが実際に失敗した事例から見つけることができる。例えば、ユーザーからの「エージェントが間違った情報を提供した」というフィードバック、開発中に発見されたバグ、あるいはテスト運用中に観察された予期せぬ動作など、具体的な問題点こそがエージェントの弱点を示し、改善すべき点を明確にする貴重な情報源となる。これらの失敗事例を詳細に分析し、「どのような入力があったときに」「どのような条件下で」「なぜ間違った出力や行動をしたのか」を特定することで、同様の失敗を繰り返さないための具体的なEvalsケースを作成できる。

また、AIエージェントに期待する機能やシナリオを具体的にリストアップすることからもEvalsケースは生まれる。例えば、「特定の情報要求に対して正確な回答を生成する」「指定されたタスクを完了する」といったエージェントの主要な役割について、「どのような入力に対して、どのような出力が期待されるか」を明確に定義し、テストケースとして記述していく。さらに、発生頻度は低いが、発生すると大きな問題につながる可能性のある「エッジケース」や「境界条件」もEvalsの対象とすべきだ。例えば、非常に長い入力、特定の記号を含む入力、曖昧な指示、あるいはシステムの負荷が高い状況など、特殊な条件下でのエージェントの振る舞いを確認することは、堅牢なシステムを構築する上で欠かせない。悪意のある入力、いわゆるプロンプトインジェクションに対する耐性を評価するケースも非常に重要だ。

作成したEvalsケースの中から、実際に評価スイート、つまり定期的に実行するテストの集合体として「残すべきケース」をどのように選定するかは重要な課題となる。すべてのケースを網羅することは現実的ではないため、重要性と効率性を考慮して厳選する必要がある。選定基準としては、まず「網羅性」が挙げられる。エージェントの主要な機能、重要なリスク、および過去に発生した重大なバグをカバーしているかを確認する。次に「再現性」も重要だ。特定の入力と条件下で、常に同じ問題や期待される出力を引き起こすケースであるべきだ。また、「簡潔さ」も考慮に入れる。テストケースは、その意図が明確で、理解しやすい形式であることが望ましい。複雑すぎるケースはメンテナンスが難しくなるため、可能な限り単純化することが重要だ。さらに、そのケースが検出する問題の「重要度」も判断基準となる。ユーザー体験に大きな影響を与える問題や、システム全体の信頼性を損なう可能性のある問題を検出するケースは、優先的にスイートに残すべきだ。そして、同じような問題を検証する「冗長なケース」は統合するか削除し、評価スイート全体の効率性を高める必要がある。最終的には、自動化が容易で、継続的に実行できるEvalsケースが理想的である。

記事では「ある行動を促すすべてのケースには、その行動を制限するケースも必要だ」と指摘している。これはEvalsにおいて非常に重要な考え方だ。例えば、「ユーザーが問い合わせた商品に関する情報を正確に提示する」という肯定的なテストケースがある。これはエージェントが期待通りに情報を提供できるかを確認するものだが、これだけでは不十分だ。同時に「ユーザーが問い合わせていない、個人情報や機密情報については提示しない」といった、エージェントの行動を制限する否定的なテストケースも必要となる。

この「制限するケース（bounding case）」は、エージェントが過剰なサービスを提供したり、範囲外の情報を漏洩したり、悪意のある入力（プロンプトインジェクションなど）に対して不適切な応答をしたりすることを防ぐために不可欠だ。肯定的なケースだけでは、エージェントが何でもかんでも答えようとしてしまう「過剰応答」や、セキュリティ上の脆弱性を看過してしまう可能性がある。Evalsでは、エージェントに「何をすべきか」を教えるだけでなく、「何をしてはならないか」「どこまでが許容範囲か」を明確に定義し、検証することが求められる。これにより、AIエージェントは指定された役割を適切に果たしつつも、予期せぬ問題行動を起こすリスクを最小限に抑えることができるのだ。

具体的なEvalsケースの書き方としては、いくつかの要素を含めることが一般的だ。まず「入力（Input）」として、エージェントに与えるプロンプトやデータ、あるいはエージェントが利用できる外部情報などを明確に記述する。次に「期待される出力（Expected Output）」を定義する。これは、エージェントがその入力に対して、どのような情報を含む回答を生成すべきか、どのような行動を取るべきかを示す。期待される出力は、一字一句正確である必要はなく、その「意図」や「情報内容」が一致しているかを評価することも多い。さらに、そのEvalsケースが「成功か失敗か」を判断するための「評価基準（Metric）」も明確にしておく。例えば、「回答の正確性」「関連性の高さ」「有害な内容の有無」「タスク完了の可否」など、具体的な指標を設定する。必要に応じて、エージェントが利用できる特定の「コンテキスト（Context）」、例えば参照すべきドキュメントの指定や、特定のツールを使うべき指示などもケースに含めることがある。

AIエージェントは、継続的に開発され、進化していく。新しい機能が追加されたり、基盤となるAIモデルが更新されたり、利用環境が変化したりするたびに、エージェントの振る舞いが変わる可能性がある。そのため、Evalsも一度作成したら終わりではなく、継続的に更新し、実行していく必要がある。新しい問題が発見されればEvalsケースを追加し、エージェントの機能が拡張されればそれに応じた評価項目を設ける。このようにEvalsを継続的に運用することで、AIエージェントの品質を維持し、長期にわたって信頼性を保証できるのだ。システムエンジニアとしてAIエージェントの開発に関わるならば、Evalsは開発プロセスの不可欠な一部として、その設計、作成、運用に深く関わっていくことになるだろう。Evalsを通じて、より安全で、より信頼性の高いAIエージェントを社会に提供することを目指す。