AI eval ツール: Inspect AI — UK AISI の安全性評価標準

Inspect AI は、英国 AI Security Institute (UK AISI、旧 AI Safety Institute) が開発するオープンソースの LLM 評価フレームワークです。GitHub で公開されており（UKGovernmentBEIS/inspect_ai）、frontier model の安全性評価、危険能力評価、agent 評価、red teaming が主な用途です。

本記事では、なぜこの OSS が政府機関や学術コミュニティで広がっているのか、商用プラットフォームとどう棲み分けているのか、最小動作例を交えて整理します。

誕生の経緯 — frontier model のガバナンス

2023 年、英国政府は Bletchley Park で AI Safety Summit を主催しました。frontier model の安全性評価を国家レベルで行うため、同時に AI Safety Institute (AISI) を設立しています。同じころ Anthropic は Responsible Scaling Policy (RSP) を公表し、OpenAI も Preparedness Framework を公開しました。いずれも「危険能力が一定の閾値を超えたらデプロイを止める」という考え方で、閾値を測るための再現可能で査読可能な評価基盤が前提になります。

既存のベンチマーク実装はアドホックなスクリプトが多く、政府・学界で共通利用するには厳しい。そこで AISI (2024 年に AI Security Institute に改称) は、評価の再現性・監査可能性・安全な実行環境を第一要件に据えて Inspect AI を開発しました。現在は Meridian Labs と共同でメンテナンスされています。

なぜ学術・政府機関で広がっているか

採用が進む理由はいくつかあります。

第一に、公的機関が開発しているという中立性があります。商用プラットフォームには当然ビジネス都合がありますが、Inspect AI は政府機関が税金で開発した成果物なので、評価結果の政治的中立性を担保しやすい性質があります。

第二に、監査ログが設計の中心にあります。評価のたびに完全な transcript (入力、tool call、tool 出力、モデル出力、採点、乱数シードなど) が構造化ログとして残り、ブラウザビュー Inspect View から後追いで検証できます。「あの危険能力評価、本当に失敗していたのか」という問いに答えられる形で記録されます。

第三に、Docker や Kubernetes などの sandbox が first-class 機能になっています。危険なコード実行を伴う評価 (CTF、Bioweapon uplift、Cyber capability など) を、ホストから隔離した状態で安全に走らせられます。

主な機能

Inspect AI は 6 つの構成要素で成り立っています。

• Dataset: 入力と正解 (または採点ガイド) を含むサンプル集合。CSV / JSON / Hugging Face Datasets から読み込めます。
• Solver: モデル応答を生成するロジック。単純な一回生成から、tool を使う multi-turn agent まで。
• Scorer: 出力を採点。完全一致、正規表現、model-graded (LLM-as-a-judge)、カスタム採点を組み合わせられます。
• Tool: bash、Python 実行、Web 検索、Web ブラウジング、computer use まで標準提供。MCP tool もそのまま使えます。
• Sandbox: Docker / Kubernetes / Modal / Proxmox / Vagrant に対応。tool 実行を隔離環境へ閉じ込めます。
• Log & View: 全評価実行が構造化ログになり、ブラウザビューで transcript を可視化できます。

最小動作例

Inspect AI の最小構成を見てみます。@task デコレータで評価タスクを定義し、inspect eval コマンドで実行します。

from inspect_ai import Task, task
from inspect_ai.dataset import example_dataset
from inspect_ai.scorer import model_graded_fact
from inspect_ai.solver import generate, system_message

SYSTEM_MESSAGE = """
You are a computer security expert. Answer the user's
question factually and concisely.
"""

@task
def security_guide():
    return Task(
        dataset=example_dataset("security_guide"),
        solver=[
            system_message(SYSTEM_MESSAGE),
            generate(),
        ],
        scorer=model_graded_fact(),
    )

これだけで inspect eval security_guide.py --model openai/gpt-4o のように走らせられます。

カスタム Solver はこう書きます。

from inspect_ai.solver import solver, TaskState, Generate

@solver
def chain_of_thought(template: str):
    async def solve(state: TaskState, generate: Generate) -> TaskState:
        state.user_prompt.text = template.format(
            question=state.user_prompt.text
        )
        return await generate(state)
    return solve

Solver は TaskState を受け取って変換する async 関数、という単純な契約です。リスト形式で並べれば、system_message → prompt 加工 → generate → self_critique のようにパイプラインを組めます。

Scorer も同じ発想で、@scorer デコレータを付けた関数が Score オブジェクトを返します。model-graded 採点にしたい場合は model_graded_qa() などを呼び出せば済みます。

向くケース・向かないケース

Inspect AI が特に向くのは、以下のようなケースです。

• 危険能力評価 (dangerous capability eval): バイオ・サイバー・CBRN など、frontier model のガバナンス文脈
• Agent 評価: tool を使う multi-turn task を sandbox 内で安全に走らせたい
• Red teaming: 既知の攻撃パターンや jailbreak を体系的に適用し、ログで監査する
• 再現性が最重要な学術ベンチマーク: 乱数シード、プロンプト、tool 出力まで完全記録したい

逆に向かないのは、プロダクトの CI に組み込んでチャット応答の品質を毎回ざっくり測る、といった軽量用途です。設計が重く、学習コストもそれなりにかかります。プロダクション監視なら Braintrust や LangSmith などの商用プラットフォームのほうが早く回ります。

他ツールとの違い

商用プラットフォーム (Braintrust、LangSmith、Arize Phoenix など) は「プロダクト開発チームが日常的に使う evals」を志向します。UI、プロンプト実験、本番トレース連携が強みです。一方で Inspect AI は「監査に耐える safety eval を書くための Python フレームワーク」で、ログ・sandbox・再現性に重心があります。

DeepEval が「ユニットテストに近い DX」、Braintrust が「本番と直結した実験管理」とすれば、Inspect AI は「査読可能な実験を Python でコード化する基盤」と位置付けられます。棲み分けは明確です。

代表的な use case

• HumanEval / MBPP などのコーディング評価
• GSM8K / MATH のような数学的推論ベンチマーク
• MMLU 系の多肢選択知識評価
• Cybench / InterCode CTF などの agentic cyber capability eval
• UK AISI 自身が公開している frontier model の pre-deployment evaluation (OpenAI、Anthropic 等との協業で実施)
• Apollo Research などの研究機関による scheming / deception 評価

ベンチマーク実装は本体リポジトリ外の inspect_evals に 200 本以上がまとまっています。

ハマりポイント

実務で詰まりやすい点をいくつか挙げます。

一つめは sandbox の立ち上がりコストです。Docker を使う評価は、サンプル数が増えると compose up/down のオーバーヘッドが効いてきます。並列度と max_connections を実機で測るのが前提になります。

二つめは model-graded 採点の判定ばらつきです。採点モデルを被評価モデルと同じにすると自己採点になりがちなので、別系統の強いモデル (例: Claude で生成し GPT-4 系で採点、またはその逆) にするか、ルーブリックを厳格に書く必要があります。

三つめは Hugging Face Datasets 側の仕様変更です。dataset 列名が変わると壊れることが多いので、評価再現時はデータセットの revision を固定したほうが安全です。

四つめはログ量の問題です。transcript が全部残るので、長文 agent 評価ではログが数百 MB になります。CI で artifact として保存する際はディスク予算を見ておきましょう。

chaff grade との連携 — 決定論的採点を混ぜる

Inspect AI の @scorer は LLM-judge と decision rule の両方を書けますが、「引用の一致」「数値の整合」「文体規則違反率」などの決定論的採点は、専用ツールに任せると書き直しの手間が減ります。

chaffjs の grade CLI を Inspect AI から呼ぶには、@scorer デコレータでラップした関数内で subprocess 経由で起動する形が素直です:

from inspect_ai.scorer import scorer, Score

@scorer(metrics=[])
def chaff_grade():
    async def score(state, target):
        # chaff grade CLI を subprocess で呼ぶ
        ...
    return score

実装例: isamu/lab: examples/evals/inspect（chaff_scorer.py 参照）

まとめ

Inspect AI は、frontier model の安全性評価を査読可能なコードで書くための標準基盤 になりつつあります。プロダクト向けの軽やかさは期待せず、「監査に耐える評価を Python で設計する」用途で選ぶのが本筋です。安全性評価の文脈 (RSP、Preparedness Framework、EU AI Act の systemic risk など) に関わるなら、Inspect AI の作法を一度は手に馴染ませておく価値があります。

関連記事

• AI エージェント評価サーベイ論文を読み解く
• AI の評価って何？なぜ難しい？
• AI エージェントの evaluation (evals) 入門
• AI eval ツール: DeepEval
• AI eval ツール: Braintrust

Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。