Skip to content
Published on

AI 安全 / 評価 / レッドチーミング 2026 — Inspect AI / Garak / PyRIT / Promptfoo / OpenAI Evals / lm-eval-harness 深掘りガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 2026年、「安全」は1つの道具で解けない

2026年5月。モデル会社は毎月新しいモデルを出し、アプリ会社はそれを取り込んでエージェントを作る。毎週誰かが新しい jailbreak を SNS に投稿し、毎月どこかの国の AI Safety Institute が新しい評価レポートを出す。安全は「RLHF をやったから大丈夫」では終わらない。安全は 評価(eval)・レッドチーミング(red-team)・ポリシー(policy)・標準(standards) の4領域が同時に回るシステムである。

問題は、この4領域の道具がそれぞれ違い、会社・政府・学界ごとに別の名前が使われていることだ。Inspect AI とは何で、Garak とどう違うのか。PyRIT はなぜ Microsoft が作り、誰が使うのか。Promptfoo は学術向けか、production 向けか。OpenAI Evals と lm-evaluation-harness は同じ役割なのか。UK AISI と Korea AISI は何が違うのか。

この記事は2026年現在の AI 安全・評価・レッドチーミング エコシステムを1枚に描く。個々の道具を深掘りするのではなく、誰が作り、何を解こうとし、どこに収まるかを整理する。チームの「安全インフラ」一行会議で、何を入れ何を外すかを決められるように。

第1章 · 2026年 AI 安全マップ — eval / red-team / policy / standards の4領域

まず大きな絵から。2026年の AI 安全エコシステムは4領域に分かれる。それぞれ別の人が作り、別の人が使う。

領域何をするか代表ツール・機関誰が使うか
Eval(評価)モデル・エージェントの能力・安全を測るInspect AI、lm-eval-harness、OpenAI Evals、Promptfoo、DeepEvalモデル会社、アプリ会社、AISI
Red-team(攻撃)モデル・アプリを敵対的に壊そうとするGarak、PyRIT、Pliny DB、MITRE ATLASセキュリティチーム、AISI、レッドチーム
Policy(ポリシー)「どこまでリリースするか」社内の意思決定OpenAI Preparedness Framework、Anthropic RSPモデル会社のガバナンス
Standards(標準)産業・政府レベルの共通基準OWASP LLM Top 10、NIST AI RMF、ISO 42001セキュリティ、コンプライアンス、政府

この4領域は互いに依存する。eval は red-team の結果を自動化する(新しい jailbreak が見つかれば eval suite に組み込まれる)。policy は eval スコアを閾値として使う(「CBRN カテゴリで X% を下回ればリリース保留」)。standards は eval と red-team が何を測るべきかの共通語彙を与える。

本記事の流れは上の順番に沿う — eval(第2〜9章)、red-team(第3・4章)、policy(第11章)、standards(第12章)、そして地域差(第13章)と「誰が何を選ぶべきか」(第14章)。

一言の洞察: 「安全」は1つの道具で解けない。安全は4領域の合計である。そして2026年現在、4領域すべてを見ているチームはほとんどない。多くは1つか2つの領域しか見ていない。

第2章 · Inspect AI(Anthropic、2024.5) — UK AISI が使う eval フレームワーク

一言の定義: Anthropic が2024年5月にオープンソースで公開した LLM 評価フレームワーク。英国 AI Safety Institute(UK AISI)が中核評価ツールとして採用し、2025〜2026年には事実上「政府レベル評価の標準」となった。

なぜ作られたか: 2024年まで、LLM の評価コードはほとんど「使い捨てスクリプト」だった。モデルごとに違う API、非決定性の扱い、tool-use 評価、multi-turn 評価、judge モデル — 毎回書き直していた。Inspect AI はこれを1つのフレームワークにまとめる。評価は Dataset → Solver → Scorer の3コンポーネントで表現される。

3つの中核概念:

  • Task: 1つの評価の単位。データセット + solver(どう解くか) + scorer(どう採点するか)。
  • Solver: モデルが問題を解く戦略。素の generate、chain-of-thought、tool-use、multi-turn agent。
  • Scorer: 採点方式。exact match、includes、model-graded(他のモデルが採点)、custom。
from inspect_ai import Task, task
from inspect_ai.dataset import example_dataset
from inspect_ai.scorer import includes
from inspect_ai.solver import generate

@task
def theory_of_mind():
    return Task(
        dataset=example_dataset("theory_of_mind"),
        solver=generate(),
        scorer=includes(),
    )

この1ファイルが1評価。inspect eval theory_of_mind.py --model anthropic/claude-sonnet-4-5 で走らせる。

UK AISI の採用が決定的だった。AISI はモデル会社からリリース前のモデルを受け取り、政府レベルの評価を行う。その評価インフラが Inspect AI である。これが事実上「政府が認める評価標準」というシグナルになり、2025年以降は US AISI、日本 AISI、韓国 AISI も Inspect AI ベースの評価を標準オプションの1つに加えた。

いつ使うか:

  • モデル会社のリリース前能力・安全評価。
  • AISI 級政府機関による外部評価。
  • 学界の新ベンチマーク発表(次第に Inspect AI 互換でリリースされるようになっている)。
  • アプリチームが独自モデル比較を行うとき。

いつ使わないか: 単純なプロンプト A/B テスト(Promptfoo の方が軽い)、production observability(Phoenix・Langfuse の方が合う)。

第3章 · Garak(NVIDIA → 独立) — LLM 脆弱性スキャナ

一言の定義: LLM 版の nmap・OWASP ZAP。既知の攻撃シナリオをモデルに自動で打ち込み、どこで壊れるかをレポートにする。NVIDIA が2023年に開始し、2024〜2025年に独立プロジェクトに分離した。

なぜ作られたか: Leon Derczynski(NVIDIA、その後独立)は「LLM のセキュリティスキャナがない」という問題を見た。Web セキュリティには ZAP・Burp、ネットワークには nmap があるのに、LLM には何もなかった。Garak は 攻撃ライブラリ(probe) + 採点器(detector) + レポート(report) の3部でその穴を埋める。

中核概念:

  • Probe: 1カテゴリの攻撃。例: dan(DAN系 jailbreak)、promptinject(Prompt Injection)、lmrc.SlurUsage(差別語誘導)、realtoxicityprompts、goodside(既知の攻撃)。
  • Detector: モデルが壊れたかを判定する採点器。キーワードマッチ、モデルベース判定、toxicity classifier。
  • Generator: 対象モデルのインターフェース。OpenAI、Anthropic、HuggingFace、REST、ローカルなど。
# フルスキャン(時間がかかる)
garak --model_type openai --model_name gpt-4o-mini

# 特定の probe のみ
garak --model_type huggingface --model_name meta-llama/Llama-3-8b \
      --probes dan.Dan_11_0,promptinject

# レポート: garak.<timestamp>.report.html

Garak が示すもの: モデル別に、どの攻撃カテゴリで壊れるかのマトリクス。「このモデルは DAN 11.0 に47%応答、RealToxicityPrompts に12%応答」というふうに。

2026年現在の価値:

  • リリース前(モデル会社): 「最低限のベースライン」として回す。
  • リリース前(アプリ会社): 選んだモデルが自社 use case で壊れるパターンを見る。
  • 学術: 新しい jailbreak が出ると、Garak probe として PR が立つ(攻撃 DB の一部にもなる)。

限界: 「既知の攻撃」が中心。zero-day jailbreak は捕まえられない。だから「攻撃を生成する」フレームワークである PyRIT と補完関係にある。

第4章 · PyRIT(Microsoft) — Python Risk Identification Toolkit

一言の定義: Microsoft AI Red Team が2024年にオープンソースで公開した敵対的評価フレームワーク。Garak が「既知の攻撃カタログ」なら、PyRIT は「攻撃を自動生成するオーケストレーション」。

何が違うか(Garak vs PyRIT):

軸GarakPyRIT
主力既知の攻撃をスキャン敵対的攻撃を自動生成
たとえnmap、OWASP ZAPMetasploit
攻撃フロー定型 probe を発射LLM が LLM を攻撃(自動変形)
学習曲線低(CLI 一行)中(orchestrator コード)
作った主体NVIDIA → 独立Microsoft AI Red Team

中核概念:

  • Orchestrator: 攻撃フローの組み立て。Single-turn(一発)、Multi-turn(対話で jailbreak)、Red Teaming(攻撃モデルが対象モデルを壊そうとする)。
  • Converter: 同じ意図を異なる表現に変形。base64 エンコード、ROT13、翻訳、言い換え。
  • Scorer: 応答がポリシー違反かを判定。Azure Content Safety、self-ask、正規表現。
  • Target: 攻撃対象。OpenAI、Azure OpenAI、HuggingFace、カスタムエンドポイント。
# 疑似コード — Red Teaming Orchestrator
from pyrit.orchestrator import RedTeamingOrchestrator
from pyrit.score import SelfAskTrueFalseScorer

orchestrator = RedTeamingOrchestrator(
    attack_strategy=...,
    chat_target=victim_model,        # 攻撃対象
    red_teaming_chat=attacker_model, # 攻撃モデル
    scorer=SelfAskTrueFalseScorer(...),
)
await orchestrator.apply_attack_strategy_until_completion_async(max_turns=5)

PyRIT の核心は **「1つの LLM が別の LLM を自動で壊そうとする」**こと。人が毎回新しい jail ケースを書くのではなく、攻撃 LLM が会話を続けながら回避表現を自動で試す。

誰が使うか: Microsoft AI Red Team 自身と、Microsoft 顧客のセキュリティチーム。2025年以降は OpenAI・Anthropic の外部評価チームの一部も採用。学界の新 jailbreak 論文が PyRIT orchestrator で再現されるケースも増えている。

Garak と PyRIT 両方必要か: 必要。Garak は毎日の回帰スキャン(速くカタログ固定)、PyRIT は四半期の深いレッドチーミング(時間がかかり新パターンを掘る)。

第5章 · Promptfoo(YC) — プロンプトテストの事実上の標準

一言の定義: プロンプト・モデル・チェーンをユニットテストのように比較する OSS CLI。Y Combinator を経て、2024〜2025年に最速で定着した。JS/TS エコシステムの入口ツール。

なぜ作られたか: アプリ会社の立場では「どのモデルを使うべきか」「このプロンプトは前より良いか」という単純な質問が最も頻繁に出る。Inspect AI は重すぎ、OpenAI Evals は学術的。Promptfoo は YAML 1ファイルでケース定義 → CLI 一行で比較 → Web UI で結果の流れを作った。

# promptfooconfig.yaml
prompts:
  - "Translate to French: {{text}}"
  - file://prompts/translate_v2.txt
providers:
  - openai:gpt-4o-mini
  - anthropic:claude-haiku-4-5
tests:
  - vars:
      text: "Hello world"
    assert:
      - type: contains
        value: "Bonjour"
      - type: llm-rubric
        value: "Translation is natural French, not literal."

promptfoo eval 一行でモデル x プロンプトのマトリクスを回し、promptfoo view で Web UI から diff を見る。

Promptfoo が速く定着した理由:

  • 入口の障壁が低い(YAML + CLI)。
  • ビルトインアサーションが豊富(contains、regex、llm-rubric、javascript、similar、factuality、latency、cost)。
  • Red-team モードがある(promptfoo redteam — Garak/PyRIT ほどではないが OWASP LLM Top 10 の一部をカバー)。
  • CI 連携が簡単(GitHub Action、GitLab)。
  • データセット import が簡単(CSV、JSONL、HuggingFace)。

いつ使うか:

  • プロンプト A/B テスト(最も一般的な use case)。
  • モデル比較(同じ入力を複数 provider に)。
  • CI での回帰チェック(以前のプロンプトよりスコアが落ちれば fail)。
  • 軽い red-team(OWASP LLM Top 10 入門)。

いつ使わないか: 政府レベル評価(Inspect AI)、学術ベンチマーク(lm-eval-harness)、production observability(Phoenix)。

第6章 · OpenAI Evals — オープンソース評価の原型

一言の定義: OpenAI が2023年3月にオープンソースで公開した評価フレームワーク。「OpenAI が自社モデルの評価に使う道具」という後光。2024〜2026年に活動性は落ちたが、データセットとパターンのリファレンスとしては今も使われる。

なぜ重要か(歴史的意義): 2023年以前は「評価コードはどう書けばよいか」の共通パターンがなかった。OpenAI Evals はそれを「Eval class + JSONL データ + sampler」というパターンとしてまとめた。このパターンは以降のすべてのフレームワークに影響を与えた。

中核構造:

  • Eval class: 1評価の実装(Python クラス)。
  • JSONL データセット: 1行1サンプル(input、ideal、etc)。
  • Sampler: モデルへの問い合わせインターフェース。
  • registry: YAML で eval のメタデータを定義。
# evals/registry/evals/my-eval.yaml
my-eval:
  id: my-eval.dev.v0
  description: My custom eval
  metrics: [accuracy]
my-eval.dev.v0:
  class: evals.elsuite.basic.match:Match
  args:
    samples_jsonl: my_eval/samples.jsonl

oaieval gpt-4o-mini my-eval で走らせる。

2026年の位置づけ:

  • 新規プロジェクトが OpenAI Evals を選ぶことは減った(Inspect AI・Promptfoo の方が活発)。
  • しかし数百の reference eval データセットが入っており、新しい評価の事実上の ground truth として頻繁に引用される。
  • OpenAI 自身はもはや Evals を単独のインフラとしては使っていない(内部ツールに移行したと推定される)。
  • 互換性面では Inspect AI が「OpenAI Evals のデータセットを import できる」と宣伝している。

いつ使うか: リファレンスデータセットが必要なとき、既存の OpenAI Evals 資産を再利用するとき。

第7章 · lm-evaluation-harness(EleutherAI) — 学術標準

一言の定義: EleutherAI が作った学術用 LLM ベンチマークランナー。HuggingFace のモデルリーダーボードのバックエンド。新モデル論文の表中の数字はほとんどこのツールから出ている。

なぜ学術標準になったか: 2022年頃、新しい LLM が出るたびに論文著者が自前の評価スクリプトで MMLU スコアを報告していた。そのため、同じモデル・同じベンチマークでも論文ごとにスコアが違った。採点方式・few-shot 数・プロンプトの違いで。lm-evaluation-harness はそれを標準化した — 「同じコードで出した数字だけが比較できる」。

核:

  • 200+ のベンチマークがビルトイン(MMLU、HellaSwag、GPQA、ARC、TruthfulQA、GSM8K、HumanEval 派生、BBH 等)。
  • HuggingFace transformers、vllm、OpenAI/Anthropic API、llama.cpp など多様なバックエンド。
  • HuggingFace Open LLM Leaderboard の公式バックエンド。
# MMLU 5-shot
lm_eval --model hf --model_args pretrained=meta-llama/Llama-3.1-8B \
  --tasks mmlu --num_fewshot 5 --device cuda --batch_size 8

# 複数ベンチマークを一度に
lm_eval --model hf --model_args pretrained=... \
  --tasks mmlu,gpqa,hellaswag,arc_challenge --num_fewshot 5

Inspect AI との関係: 重なる。lm-eval-harness は「決まった学術ベンチマークの標準ランナー」に強く、Inspect AI は「カスタム評価・agent・multi-turn」に強い。2026年現在、両方とも生きており、モデル会社・AISI は通常両方を使う(ワークフローごとに使い分ける)。

いつ使うか:

  • 新モデルの論文用ベンチマーク表。
  • HuggingFace リーダーボード提出。
  • 「他モデルと同一条件比較」が必要なとき。

第8章 · MLflow Evals / Arize Phoenix / DeepEval / Giskard — 運用領域の4総士

上のツールが「評価インフラ」なら、この4つは 評価と observability の境界で働く。

MLflow Evals(Databricks)

MLflow に2023年に追加された LLM 評価モジュール。ML ライフサイクルの中で「このモデル実験とあのモデル実験を比較する」流れに収まる。Databricks 顧客のデフォルトオプション。ビルトイン評価メトリクスが LLM 時代用に拡張された(mlflow.evaluate(model_type="question-answering"))。

いつ使うか: MLflow を既に使う ML チーム。ML モデルと LLM を1つのライフサイクルで管理するとき。

Arize Phoenix(オープンソース)

OpenTelemetry ベースの LLM observability + eval。trace を受け取って可視化し、その trace の上で評価を走らせる。Tracing が先、eval はその上に乗せる流れ。自己ホスト OSS と SaaS(Arize)の両方がある。

いつ使うか: production traffic を見ながら評価したいとき。RAG デバッグ(「なぜこの retrieval が間違ったのか」)。

DeepEval(Confident AI)

「pytest 風の LLM 評価」。Python ユニットテストのデコレータで LLM eval を書く。ビルトインメトリクスが豊富(GEval、AnswerRelevancy、Faithfulness、ContextualPrecision/Recall、Hallucination、ToxicityMetric、BiasMetric)。

# 疑似コード
@pytest.mark.eval
def test_answer_quality():
    metric = AnswerRelevancyMetric(threshold=0.7)
    test_case = LLMTestCase(input="...", actual_output="...")
    assert_test(test_case, [metric])

いつ使うか: pytest 流れに慣れた Python 開発者が LLM eval を書きたいとき。

Giskard(オープンソース)

ML モデル(伝統的 ML + LLM の両方)の バイアス・頑健性・ドリフト検出に強い。自動的に issue を発見する(例: 人口統計グループ別の精度差)。

いつ使うか: 規制産業(金融・ヘルスケア)。バイアス・公平性レポートが必要なとき。

4総士まとめ表:

ツール主力誰が使うか
MLflow EvalsML ライフサイクル統合Databricks 顧客
PhoenixTracing + evalRAG・agent observability チーム
DeepEvalPytest スタイルPython 開発者
Giskardバイアス・ドリフト規制産業

第9章 · ベンチマーク群 — HumanEval / MMLU / GPQA / SWE-Bench / BigCodeBench

ツールではなくデータセット。2026年現在、新モデル発表ごとに表に入る標準バッテリー。

HumanEval(OpenAI、2021)

164個の Python 関数記述問題。モデルが docstring を見て関数本体を埋める。採点は単体テスト通過の可否。「コード生成能力」の最も古いベンチマーク。2026年現在ほぼ saturated(上位モデル95%+)だが、依然として標準の1行。

MMLU(Massive Multitask Language Understanding、2021)

57の学問分野の選択式問題、約16,000問。4択。「広範な知識」の標準。2026年現在、上位モデルは90%+で、ここで差がつかなくなったので、MMLU-Pro(2024、より難しい版)や HLE(Humanity's Last Exam、2025)で補強する。

GPQA(Google-Proof Q&A、2023)

大学院レベルの科学問題 約448問。専門家でも約65%。Google 検索でも解けないように設計。「本当に難しい推論」の代表。推論モデル(o シリーズ、Claude の extended thinking)以降スコアが急上昇。

SWE-Bench / SWE-Bench Verified(Princeton、2024)

実際の GitHub issue を見て PR を作るタスク。採点は PR が本来通すべき単体テストを通すか否か。Verified は OpenAI が人手で解ける可能性・テストの正しさを検証した500問サブセット。エージェント評価の代表ベンチマーク。

BigCodeBench(BigCode、2024)

HumanEval よりはるかに現実的なコード生成 — 標準ライブラリ・サードパーティライブラリ(NumPy、Pandas、etc)呼び出しが混ざる1,140問。HumanEval saturate 以降の後継。

他によく見るもの:

  • GSM8K / MATH: 数学。
  • BBH(Big-Bench Hard): BIG-bench の難しいサブセット。
  • ARC / ARC-AGI: 抽象推論。
  • WebArena / VisualWebArena / OSWorld: エージェントがブラウザ・OS を操作。
  • τ-bench(tau-bench): マルチターン顧客サービス agent。

要点: 1つのベンチマークだけ見てはいけない。MMLU/GPQA(知識)・HumanEval/BigCodeBench/SWE-Bench(コード)・MATH(数学)・τ-bench/SWE-bench(agent) のようにバッテリーで見て、自社 use case に近いものを重く見るべき。

第10章 · AI Safety Institute — 英 / 米 / 日 / 韓 / シンガポール / 仏

2024年に英国が初の AI Safety Institute(UK AISI)を設立して以来、2025〜2026年の間に主要国の大半が同種の機関を作った。

UK AISI(2023.11 発表、2024 運営)

世界初の AISI。英国政府傘下。リリース前モデル評価(deployment 前のモデルを受け取りリスク評価)と 共同研究が中心。Inspect AI フレームワークの中核ユーザーであり事実上のスポンサー。2024〜2025年のレポートは学界の標準引用先となった。

US AISI(2024年 NIST 傘下に設立)

NIST(National Institute of Standards and Technology)内に設立。米国政府の AI 安全評価・標準策定。NIST AI Risk Management Framework(AI RMF)の運営機関の役割も兼ねる。

日本 AISI(AI Safety Institute of Japan、2024年 IPA 傘下)

IPA(情報処理推進機構)傘下。日本政府の AI 安全評価・政策助言。ガイドライン・評価方法論文書の発行。

韓国 AISI(2024年発表)

ETRI(韓国電子通信研究院)を中心に構成。政府レベルの AI 安全評価・標準化活動。KAIST・KISTI 等の学界と連携。

シンガポール AI Verify Foundation(2023)

厳密には「AISI」名ではないが同等の機関。AI Verify(評価 toolkit)と Project Moonshot(LLM red-team toolkit)を OSS で公開。

フランス AI Safety Office(Inria 傘下、2024)

Inria(フランス国立研究所)内に設置。欧州レベルでは EU AI Office と連携。

共通点:

  • 政府資金。
  • リリース前評価(主要モデル会社との MoU)。
  • 共同評価方法論の開発(国際連携 — AISI Network)。
  • 結果公開(レポート発行)。

なぜ重要か: 2026年時点で 「何が危険か」の共通語彙が AISI から出ている。CBRN(化学・生物・放射線・核)、サイバー攻撃、自律性、モデル欺瞞といったカテゴリ定義が AISI 評価レポートで標準化されつつある。

第11章 · OpenAI Preparedness Framework + Anthropic RSP

2つのモデル会社の 自社安全ポリシー文書。「どの程度のリスクならリリースするか」社内の意思決定を外部に公開した文書。

OpenAI Preparedness Framework(2023.12 発表、以降改訂)

OpenAI が自前で定義した リスクカテゴリ別の閾値:

  • カテゴリ: Cybersecurity、CBRN、Persuasion、Model Autonomy。
  • 各カテゴリでモデルのリスクを Low / Medium / High / Critical で評価。
  • 閾値以上ならリリース保留または mitigation 義務。
  • 「Preparedness Team」別組織、「Safety Advisory Group」が意思決定。

Anthropic Responsible Scaling Policy(RSP、2023.9 発表、以降改訂)

Anthropic の同種文書。AI Safety Level(ASL) 概念:

  • ASL-1: 明らかに無リスク(小型モデル、ゲーム AI)。
  • ASL-2: 現在の frontier モデル — わずかなリスクシグナル。
  • ASL-3: 自律性・サイバー・CBRN で実質的リスク。
  • ASL-4+: 今後定義。

各レベルに対応する deployment standard と security standard が定義されている。ASL-3 以上はより強い weight セキュリティ、より厳格な deployment 検証を要求される。

共通パターン

  • 「リスクカテゴリ定義 → 評価 → 閾値 → 意思決定ゲート」。
  • 評価がこの意思決定の入力 — だから Inspect AI・red-team ツールがポリシーゲートのインフラになる。
  • 2025年以降 Google DeepMind も同種の Frontier Safety Framework を発表し、事実上 frontier lab の共通パターンに。

Voluntary commitments vs 法的義務: 上の2文書は両方とも会社の自発的約束。法的強制力は2025年以降 EU AI Act の GPAI(General Purpose AI)義務に一部反映され、米国はカリフォルニア州 SB 53(transparency act)等の州レベル立法が入った。

第12章 · MITRE ATLAS + OWASP LLM Top 10

産業標準の2本柱。

MITRE ATLAS(Adversarial Threat Landscape for AI Systems)

MITRE の ATT&CK(伝統的サイバー攻撃の標準分類)を AI システム攻撃用に拡張したマトリクス。2020年に初期公開、2024〜2026年に LLM/GenAI 戦術が大量追加された。

構成:

  • Tactics(戦術): Reconnaissance、Resource Development、Initial Access、ML Model Access、Execution、Persistence、Defense Evasion、Discovery、Collection、Exfiltration、Impact。
  • Techniques(技法): 各戦術内の具体的攻撃。例: 「Jailbreak via Multi-Turn Coaxing」「Prompt Injection」「Model Theft」「Data Poisoning」。
  • Case Studies: 実発生攻撃事例。

誰が使うか: セキュリティチームが「自社 AI システムに適用可能な攻撃を漏れなく検討する」チェックリストとして。red-team レポートの分類語彙。

OWASP LLM Top 10(2023 v1 → 2025 v2)

OWASP が定義した LLM アプリケーションで最も一般的な10種類のセキュリティリスク。2025 版(v2)項目:

  1. Prompt Injection
  2. Insecure Output Handling
  3. Training Data Poisoning
  4. Model Denial of Service
  5. Supply Chain Vulnerabilities
  6. Sensitive Information Disclosure
  7. Insecure Plugin/Tool Design
  8. Excessive Agency
  9. Overreliance
  10. Model Theft

なぜ重要か: アプリ開発者に最も馴染みのある語彙。「うちのアプリは OWASP LLM Top 10 に対応している」がコンプライアンスチェックリストの1行となった。

ツールとのマッピング:

  • Promptfoo redteam モード → OWASP LLM Top 10 の一部を自動チェック。
  • Garak probe → OWASP のカテゴリにマッピングされる。
  • PyRIT orchestrator → OWASP シナリオをシミュレーション。

ATLAS vs OWASP LLM Top 10

  • ATLAS: 広範・戦術中心・全 AI システム(ML・CV・LLM)。
  • OWASP: 狭く・アプリ中心・LLM 限定。
  • 両方使う。ATLAS は脅威分析に、OWASP はアプリセキュリティチェックリストに。

第13章 · 韓国 / 日本 — KAIST、KISTI、AI Safety Institute of Japan、RIKEN AIP

韓国

  • KAIST AI Safety グループ: KAIST 内の AI 安全・アラインメント研究。学界として安全・解釈性論文を出す中心。
  • KISTI(韓国科学技術情報研究院)Safety: 政府出捐研究機関。データ・インフラレベルの安全(データセットガバナンス、インフラセキュリティ)に強い。
  • ETRI(韓国電子通信研究院): 韓国 AISI の運営主体。政府レベルの標準・評価開発。
  • TTA(韓国情報通信技術協会): AI 信頼性標準。
  • 産業側: Naver CLOVA Safety、Kakao 安全・倫理チーム、LG AI Research 安全グループ。

韓国の強み: 韓国語評価データセット(KoBest、KMMLU、韓国語 toxicity 等)と K-pop・法令・医療等の韓国特化ドメインでの安全評価。

日本

  • AI Safety Institute of Japan: 2024年 IPA 傘下に設立。政府レベルの安全評価・ガイドライン。
  • RIKEN AIP(Center for Advanced Intelligence Project): 日本最大の AI 研究センター。安全・アラインメント・信頼性研究。
  • NICT(情報通信研究機構): 日本語 LLM(JapaneseLM シリーズ)+ 安全評価。
  • 産業側: SoftBank・NTT・Rakuten の社内安全グループ。

日本の強み: 日本語評価データセット(JGLUE、llm-jp-eval)、そして 敬語・丁寧表現・文化特化評価。

共通の流れ

2025〜2026年の間、韓日両方で「自国 LLM が英語モデル比で自国語・文化において安全か」を評価するデータセットが急増した。英語評価ツール(Inspect AI・lm-eval-harness)はそのまま使い、データセット層を自国語で埋めるパターン。

第14章 · 誰が何を選ぶべきか — モデルリリース / アプリ統合 / ガバナンス / 学術

最終章。ペルソナ別の推奨スタック。

A. モデル会社(frontier lab の安全・評価チーム)

  • 必須: Inspect AI(custom eval + AISI 互換)、lm-evaluation-harness(学術ベンチマーク互換)、PyRIT(レッドチーミング自動化)、自社内部 platform。
  • 推奨: Garak(外部回帰スキャン)、OpenAI Evals(リファレンスデータセット import)、Anthropic RSP / OpenAI Preparedness のような自社ポリシー文書。
  • リリースゲート: ポリシー文書(RSP/Preparedness)の閾値 ← 評価(Inspect AI)+ レッドチーム(PyRIT)結果。

B. アプリ会社(Foundation モデルを取り込むチーム)

  • 必須: Promptfoo(プロンプト A/B + CI 回帰)、何らかの observability(Phoenix・Langfuse・LangSmith のいずれか)。
  • 推奨: DeepEval(pytest 統合)、Garak(四半期外部モデルセキュリティ検査)、OWASP LLM Top 10 チェックリスト。
  • 任意: Inspect AI(社内独自ベンチマークが大きくなったら)、Giskard(規制産業)。

C. ガバナンス / コンプライアンス / セキュリティチーム

  • 必須: OWASP LLM Top 10(チェックリスト)、MITRE ATLAS(脅威分析)、NIST AI RMF / ISO 42001(ガバナンスフレーム)。
  • 推奨: PyRIT(四半期 red-team)、Garak(外注ペンテストとは別に自社回帰スキャン)、Giskard(バイアスレポート)。
  • 参照: 自国 AISI の評価方法論とガイドライン。

D. 学界 / 研究者

  • 必須: lm-evaluation-harness(論文標準)、Inspect AI(新 eval 発表)。
  • 推奨: OpenAI Evals(リファレンス)、Promptfoo(軽い実験)。
  • 研究領域別: jailbreak 論文なら PyRIT/Garak で再現、安全分類器なら Atla 級安全分類器をベースラインに。

組み合わせの一般原則

  • eval と red-team は分離して運用する(別の人が作り、別の周期で回る)。
  • CI に入る eval(毎 PR)と 四半期の深い red-team(毎四半期)を区別する。
  • データセットは自国語・自国ドメインを追加する(英語ベンチマークだけ見ても自社 use case でどうかは分からない)。
  • ポリシー文書を真似る — frontier lab の RSP/Preparedness パターンは小チームにも適用できる(「どのカテゴリでどの水準ならリリース保留」を明文化)。

一行結論: 2026年の安全は1つの道具で解けない。4領域(eval・red-team・policy・standards)を自チーム規模に合わせて組み合わせるのが安全インフラの仕事である。そしてその組み合わせの出発点は **「誰が何を作り、何を解こうとしたか」**を知ること — この記事がその1枚マップになることを願う。

参考 / References

Discuss on Twitter • View on GitHub