【ITニュース解説】My Snowflake Agent Was Wrong. So Was My Evaluation.

AI技術が進化し、システムにAIエージェントを組み込む機会が増える中で、システムエンジニアとしてその開発や運用に関わることは今後ますます重要になる。AIエージェントは、ユーザーの質問に答えたり、特定の作業を自動で実行したりするプログラムだが、これを完璧に動作させるのは簡単ではない。この記事は、AIエージェント「Snowflake Cortex Agent」の開発者が直面した具体的な課題と、その解決を通じて得られた教訓について述べている。この経験は、AIシステムを開発・評価する上での大切な考え方を教えてくれるだろう。

まず、エージェントが期待通りの結果を出せないとき、問題がどこにあるのかを特定することが非常に難しいという点がある。筆者は、エージェントの挙動を評価する際に、「質問に正しく答えられたか？」「その答えにたどり着くまでの手順は適切だったか？」「評価基準は本当に求めている動作を測っていたか？」という三つの問いを立てることを提唱している。例えば、エージェントが「データベースに特定のオブジェクトは存在しない」と回答したにも関わらず、実際にはそのオブジェクトのデータ（メタデータ）は存在していたケースがある。

この問題の原因を探る過程で、筆者は問題がエージェント自身と、エージェントが情報を検索するために使う「セマンティックツール」という特別なツールの両方にまたがっていることを発見した。最初はエージェントの指示に、オブジェクトが見つからなかった場合の「代替案」を追加したが解決しなかった。次に、セマンティックツールが特定の情報源（ソース）で検索できないのではないかと疑われたが、ツールの定義を詳しく調べると、実際には検索機能は存在していた。本当の問題は、ツールの設定が「ビューの名前」で検索することを優先するように指示されていたことにあった。結局、エージェントへの指示と、セマンティックツールの検索に関する設定の両方を変更することで、ようやくオブジェクトを正しく見つけられるようになったのだ。この経験は、「データがない」「ツールが使えない」「エージェントの質問が悪い」という異なる診断が、それぞれ全く異なる解決策を必要とすることを示している。最初の診断に飛びつくのではなく、ツールの定義を詳細に確認し、何度も再テストすることの重要性を強調している。

エージェントの挙動を正しく評価するには、具体的な「証拠」が不可欠である。筆者は、実際のユーザーからの質問、エージェントの応答、そしてシステム内部の動作を示す追跡ログ（トレース）を並行して確認した。驚くべきことに、アプリケーションのツール呼び出しカウンターが「ゼロ」を示しているにも関わらず、詳細なトレースログを見ると実際には活動があったことが判明したケースがあった。これは、計測方法の不備によって、活動がなかったかのように見えてしまっていた例である。システムの動作状況を示すデータ（テレメトリー）が欠落している場合、表面上の数字だけを信じると誤った判断をしかねないため、複数の異なる情報源からの証拠を比較検討することの重要性がここからわかる。

AIエージェントの「評価」そのものも複雑だ。単純に「スコアはどうだったか？」と聞くだけでなく、「何についてのスコアなのか？」という問いを続ける必要がある。Snowflakeの評価システムでは、「回答の正確性」「ツールの選択精度」「ツールの実行精度」「論理的整合性」といった複数の評価項目がある。例えば、エージェントが余分なツールを呼び出したために「ツールの選択精度」のスコアが下がったとしても、最終的な回答の質は実際には向上している場合がある。この違いを理解しないと、誤った解釈に基づいた修正を行ってしまいかねない。筆者は、期待されるツールのリストに前提条件となるツールが含まれていなかったり、複数の適切なルートがあるにも関わらず一つしか許容されていなかったりするケースで、評価が混乱することがあったと述べている。

良いテストケースを作成することも、AIエージェント開発において非常に重要である。実際のユーザーからの質問は、開発者が想像しにくい多様なパターンを提供してくれるため、テスト入力として非常に有効だ。しかし、過去の会話から切り離された質問は意味を失ったり、時間が経つと答えが古くなったり、そもそも元々間違った情報を含んでいたりする可能性がある。そのため、信頼できる「回帰テスト」（過去に発生したバグが再発しないかを確認するテスト）を作成するには、質問の文脈、独立して確認された期待される答え、許容できる不確実性の範囲、そして二度と発生させてはならない挙動を明確に定義する必要がある。

さらに、作成したテストが本当に意図した機能を検証しているかを確認することも重要だ。例えば、Pythonコードを安全に実行するための「Pythonサンドボックス」という隔離された環境を有効にしたにもかかわらず、エージェントが別の方法で正解を導き出してしまい、サンドボックスが実際に利用された証拠が得られないケースがあった。正解が出たとしても、それが意図した機能パスを通っているか、内部的なトレースログで確認する必要がある。「設定した」「計画に含めた」と「実際に呼び出された」は異なる状態であり、単に正解が出ただけでは、本当にその機能が検証されたとは言えないのである。

エージェントが正しい答えを出すだけでなく、「適切なユーザーとのやり取り（インタラクション）」を実現することも重要だ。記事では、ユーザーが求めていないオブジェクト名でエージェントが勝手に分析を進めてしまった事例が紹介されている。この場合、エージェントは正解に近い情報を引き出せたかもしれないが、ユーザーにとっては不適切な行動であった。修正として、類似のオブジェクトが複数見つかった場合に、勝手に分析せずにユーザーに確認を求めるような機能が導入された。しかし、修正後のテストでは、意図したオブジェクトを見つけられたものの、ユーザーに確認を求めることなく分析を始めてしまうという問題が再び発生した。これは、「情報の取得は改善されたが、インタラクションの要件は満たされていない」ことを示している。このようなケースでは、エージェントがどこで停止し、ユーザーに確認を求めるべきか、その具体的な境界を指示に含める必要がある。

エージェントへの変更を行う際は、それがどの層（エージェントの指示、ルーティング、セマンティックツールの設定、データソースのカバー範囲、ツール自体の能力、出力形式、評価方法、監視方法など）に影響を与えるのかを明確に理解し、適切な層を修正する必要がある。また、修正のたびにその理由を明確に記録し、エージェントのバージョン管理を適切に行うことも重要だ。開発中にエージェントが再作成されてしまい、過去のバージョン履歴がリセットされるという経験から、筆者は既存のエージェントを修正しコミットするワークフローを推奨している。これは、変更が誰によって、なぜ行われたのかという記録を残し、将来のデバッグや改善に役立てるためである。

最後に、AIエージェントの開発は、最初から完璧な計画で進められるものではないと筆者は語る。ユーザーからのフィードバックや実際の運用状況から学び、それを繰り返しのエンジニアリングプロセスとして取り入れていくことが重要だ。具体的には、「関連する証拠を保持し、失敗を調査し、適切な層を変更し、再度テストする」というサイクルを回す。そして、「観測と仮説を区別する」「コンポーネントテストとアプリケーションテストを区別する」「評価スコアの向上と実際の回答品質の向上を区別する」ことが求められる。最も重要なのは、修正を行う前に「もし誰かが同じ質問をしたら、エージェントはどのように振る舞うべきか、そしてそれが実現したと確信する証拠は何か」という「回帰テスト」の考え方を先に持つことだ。この問いかけは、単に「エージェントが良いかどうか」を問うよりも、開発プロセスにおいて遥かに有用であると述べられている。AIシステム開発は、常に学びと改善の連続であり、この反復的なプロセスこそが成功への鍵となる。