エージェント評価のフレームワーク：Inspect AIの調査と選定の記録

LLMがシンプルなチャットボットを超え、「ツールを使い、自律的に思考する」エージェントへと進化する中で、避けて通れないのが「評価（Evaluation）」のプロセスと考えています。どのエージェントが、どのようなサイエンス業務で真に役立つのか、それを客観的に測る物差しが必要です。

現在、私は科学系AIエージェント（BiomniやOriGeneなど）の評価研究を進めていますが、その基盤として英国政府発のOSS「Inspect AI (https://inspect.aisi.org.uk/)」を暫定的に採用することに決めました。数日間の簡易的な試行錯誤を通じて見えてきた、Inspect AI選定の理由をまとめてみます。

1. なぜ「Inspect AI」なのか？

Inspect AI以外にも、OpenAI Evals、DeepEval、Promptfoo、MLflowなどの評価フレームワークが既に存在します。それら全てを実際に使ってみての比較検討はまだできていませんが、ChatGPTやClaudeなどのLLMに「研究のためのエージェント評価に最適なものは？」と壁打ちした際、共通して名前が挙がったのが Inspect AI でした。

開発元: The AI Security Institute（UK AISI）。政府機関が「AIの安全性を科学的に評価する」ために作ったという背景。
思想: 単なる最終出力の正誤だけでなく、エージェントの「推論プロセス」や「ツール使用」を網羅的かつ明確に記録することに特化。

評価結果の数字だけでなく、過程のログがどれだけ精密に残るか、を重視した結果、このツールに注力してみる価値があると感じました。

2. 研究用途でのさらなる決め手

特に研究用途であれば Inspect AI が最も適しているという結論に至った理由は、主に以下の3点です。

ログの精密さと統一感: エージェントが「何を推論し」「どんなツールを使い」「どんなエラーが出たか」が時系列で詳細に記録されます。実行時の設定や使用モデル情報、使用トークン数等も全て含めて統一された形式で出力されるため、その後のデータ解析の利便性が非常に高いです。
高い拡張性: 複雑な評価ロジックにも対応できる設計になっています。@score デコレータでカスタムスコアラーを定義したり、@task デコレータで独自の評価タスクを組み立てたりと、研究目的に合わせた柔軟なカスタマイズが可能です。
充実したエコシステム: LAB-Bench や Humanity's Last Exam など、有名なベンチマークがすでにライブラリに組み込まれており、すぐに利用できる点も魅力です。

現時点では、3番の充実したエコシステムと、次の3章で紹介するサンドボックス機能が、特に差別化ポイントと考えています。

3. 実際に触って感じた「ここが良さそう」

ログビューアの見やすさ

実行後、ブラウザやエディター（VScode）でログを確認できるのですが、推論過程やツール使用の履歴、躓いたエラーの内容が非常に綺麗に可視化されます（Fig1-3参照）。「なぜこのエージェントは失敗したのか？」という分析の工数が、自作スクリプトに比べて劇的に削減されるはずと考えました。

Fig1：VScodeでログを開いた画面。theory_of_mindという評価問題を検証としてgpt-4に解かせてみた結果のログ。本画面から主要な情報が確認可能。

Fig2：Sample1（問題1個目）を解かせた際の詳細なログ。SOLVERにより質問に対する回答生成、SCORERにより回答を評価する。

Fig3：本タスクのメタ情報。TASKタブから確認している。MODELS、INFO、JSONタブのそれぞれから他のメタ情報も確認可能。

サンドボックス（Docker等）連携の標準化

エージェントにコードの生成と実行をさせる際、自分の環境を壊されることは絶対に避けたい点かと思います。また第三者も同様の処理が行えるという意味合いでもコンテナ環境でエージェントを実行させることは重要かと考えます。

Inspect AIは、必ずDocker等のコンテナを通してエージェントを実行させることで「使い捨ての実験室（サンドボックス）」として扱う仕組みが組み込まれており、安全性を担保しながら複雑なタスクを投げられる安心感があります。

4. 実践の記録：独自エージェントの組み込み

既存ライブラリに組み込まれているLAB-Benchの利用、独自の評価データの利用、OpenAIのいくつかのモデルの利用などはすぐに動作を確認できました。

今回の調査で時間がかかったポイントは、自分が扱っているカスタムAIエージェントを Inspect AI の枠組みで動かすことです。

Inspect AIには、Agent Bridge機能があり、OpenAI Agents SDK、LangChain、Pydantic AI、Claude Code、Codex CLIをフレームワークとして作成されているAIエージェントであれば容易に利用できるようです。

私の作成したカスタムエージェントはLangChainベースであったため、Agent Bridge機能の利用を試みました。しかし、実際にはLangChain Coreの外側レイヤーに、Docker実行環境ラッパー、ローカルファイルシステムへの依存、MCPとの統合、ログファイルベースの結果取得、などが全てセットで必要なシステムであったために、Agent Bridge機能は使えませんでした。

そのため、下記のような構成のカスタムSolver関数を作成することで動作を確認しました。

Solver（解き手）の定義: Inspect AIから問題文を受け取る。
Dockerの直接操作: Pythonの非同期処理を使って、エージェントが動くコンテナを起動・コマンド実行。
ローカルディレクトリのマウント：エージェント実行時に適切なローカルディレクトリとマウントさせ、依存ファイルと連携。
ログの回収: 実行後にコンテナから結果を吸い出し、Inspect AIに返す。

このように、Agent Bridge機能が使えない場合でも、独自のSolver関数を定義することで、多様なAIエージェントを柔軟にInspect AIで使うことができるようです。

5. 運用上の注意点と仕様

検証の過程で、いくつか留意すべき仕様も見えてきました。

レイテンシー（実行時間）の評価 Inspect AIは非同期アーキテクチャを採用しているため、複数の問題が並列実行されます。そのため、「各問題の実行時間の合計」が「全体の実行時間」を大きく超える点に注意が必要です。また、個別問題（Sample）の計測地点と問題全体での計測地点に若干の差があるようで、0.1秒程度の微細なずれが生じることがあります。厳密な時間計測が必要な場合は、この特性を考慮する必要があります。

ログ（.eval ファイル）の扱い 評価結果は .eval というバイナリファイルで出力されます（Fig1-3参照）。当初は解析方法に不安がありましたが、Inspect AIのライブラリを用いることで、Pandasでのデータ処理やJSONへの変換も容易に行えることを確認しました。

6. まとめ

今後新たな評価フレームワークが出てくる可能性もありますし、既存の有力なフレームワークについてもまだ検討の余地があり、今後も比較を続けていきたいと考えています。

しかし、現時点での検証結果として、「ログの可読性と使い勝手の良さ」「多様なエージェントへの対応力」「シンプルかつ強力な動作」という観点から、私の研究に必要な機能は十分に揃っていると判断しました。

今後、実際に運用する中で見えてくる課題や新たなメリットについても、継続的にアップデートしていきたいと思います。