生成AIシステムとAIエージェントに関する性能や安全性の評価

Transcript

1. 生成AIシステムと AIエージェントに関する 性能や安全性の評価 2025/11/24 Yusuke Shibui
2. 自己紹介 shibui yusuke • いろいろ → Stability AI → LayerX（いまここ） • MLOpsコミュニティ運営 • MLOps & データ検索 & バックエンド & インフラ & その他諸々エンジニア • データ検索とR&Dのマネージャー • 最近やりたいこと ⽣成AIの⽣成AI以外のエンジニアリング • Github: @shibuiwilliam • FB: yusuke.shibui 猫のようで サイズは犬 猫耳メガネ LLMに聞いてみた
3. 機械学習を本番システムに組み込む方法を デザインパターンとして整理！ 機械学習を組み込んだ本番システムを 実際にハンズオンで作る！ 【共著】大企業からスタートアップまで、 MLOpsの実践例を集約！ 執筆中！ ？？？
4. 1. 頭脳の評価 2. 行動の評価 3. 現実の課題と戦略
5. 生成AIとAIエージェントのパラダイム 2025年はAIエージェント元年 = AI評価の変革期 1. 生成AIの評価は「頭脳」の評価 大規模言語モデル（ LLM）自体の出力コンテンツ（知識の正確性、有害性など）に焦点を当て、主に静的なベンチマー クで行われてきた。 2. AIエージェントの評価は「頭脳」＋「行動」の評価へ LLMを搭載し、ツールを使いタスクを遂行するシステムが対象となり、現実のツールを使った「プロセス」と実世界へ の「影響」（安全なツールの使用、意図しない破壊的行動など）が新たな焦点となる。 3. 課題は「行動」によるリスクと評価の複雑化 エージェントは、従来の GenAIの課題に加え、「行動」による新たなリスクを獲得するため、評価はより複雑化・高次元 化している。
6. 1. 頭脳の評価 2. 行動の評価 3. 現実の課題と戦略
7. 『頭脳』の評価 LLMはAIエージェントの「頭脳」 LLMの真の「性能」と「安全性」を測る物差し自体の危機 1. 性能評価の危機： ベンチマークへの「データ汚染」により、モデルが問題を解いているのか、覚えてい るのかが区別不能に。 2. 思考の幻想： 複雑な推論タスクでは、LLMの「思考」（Chain-of-Thought）は脆く崩壊し、真のアルゴリズ ム的推論能力はまだ「幻想」である可能性。 3. 安全性評価の進化： 悪意ある人間による利用（ Misuse）を超え、AI自身が意図的に人間を欺く「サボ タージュ能力」の評価が不可欠に。 → 静的なベンチマークは限界。ユースケース特化型、標準化されたレッドチーミング、そして人間を欺く新た な脅威への対策。
8. データ汚染 Data contamination • 問題の核心：従来のベンチマークの信頼性 ◦ 従来の性能評価は MMLUなどの静的ベンチマークスコアに依存。 ◦ LLMがWeb全体を学習する過程で、 公開されたベンチマークの質問と正解を「記憶」 してしまう「データ汚染」 が常態化。 • 発生する影響：スコアのインフレと真の能力の測定不能 ◦ モデルは問題を「解いている」のではなく、「覚えていた答えを出力している」可能性が高まる。 ◦ リーダーボードのスコアがインフレを起こし、モデルの真の汎化能力や推論能力は測定困難。 • 根本的な論点 ◦ 静的で公開されたベンチマークは、 LLMの「頭脳」としての性能を測る「物差し」として機能しないリスク。 • 対策研究の方向性 (例: PhishBencher) ◦ 「汚染の防止は不可能」という前提に立ち、ベンチマークの正解を意図的にランダム化して公開。 ◦ モデルがランダム化された答えを学習（＝汚染）していないかを 「検知する」 アプローチが提案。 ◦ How Can I Publish My LLM Benchmark Without Giving the True Answers Away?
9. 思考の幻想 The illusion of thinking モデルは本当に「思考」しているか？ • 問題の論点 (Apple Research): ◦ 近年の大規模推論モデル は、Chain-of-Thought (思考のプロセス) を生 成するが、従来の評価は最終的な「答え」の正しさのみを採点してきた。 • The Illusion of Thinking: ◦ 検証環境: データ汚染を排除した独自のパズル環境でテスト。 ◦ 衝撃的な発見 (性能の完全崩壊): ▪ 問題の複雑性が一定のしきい値を超えると、モデルの正解 率はゼロに「完全崩壊」 。 ◦ 発見 (思考の中断): ▪ 思考（トークン生成）を途中で「諦める」傾向も観察。 • 結論が示唆するもの: ◦ 現在のモデルが持つ「思考」は、真のアルゴリズム的推論ではなく、まだ 脆い「幻想」である可能性を示唆。 ◦ 生成AIの「頭脳」としての性能評価が直面する、深刻な「性能評価の危 機」の一つ。 • The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity
10. LLM-as-a-Judge • 概念と目的 ◦ 高性能LLMを評価者（ Judge）として活用する評価手法 ◦ データ汚染などによる静的ベンチマークの信頼性低下への対応策 ◦ 人間の評価者の代替としてのモデル回答の品質評価 • 手法の詳細 ◦ GPT-5やClaude 4.5 Sonnetなどの強力なモデルを評価者として設定 ◦ 他のモデルの応答に対する 客観的かつ詳細な品質判定 を実施 • 代表的な活用事例 ◦ ChatbotArena ◦ AlpacaEval • 主な課題点 ◦ 評価者モデル自身の バイアス （例：長い回答を好む傾向） ◦ 高性能モデルの利用に伴う 高額な推論コスト
11. ユースケース特化型評価の重要性 • 一般ベンチマークの限界 : 特定のAIアプリケーションにおける「責任ある AI」側面評価の 不十分さ • ドメイン特化型尺度の必要性 : ECサイト、医療、法務など、用途に応じた公平性・安全性の 基準設定 • 評価の具体例 : ECサイトの成人向け商品説明文。一般ベンチマークでの「有 害」誤判定リスク回避の実現 • Criteria Drift：評価基準は事前に定義できる独立したもので はなく、モデルの出力に依存する動的なものであることが示 唆。評価者自体を評価し、失敗に応じて修正 Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences ユースケース特化の評価
12. 安全性評価の体系化 背景 • 生成AI（LLM）の安全性評価は、場当たり的なテストから体系化・標準化の段階へ移行 • 「頭脳」としてのAIの安全性を工学的に評価する共通語彙とフレームワークの必要性 • 評価のマインドセットを「最適化」から「制御」へ切り替える • 安全性評価は「モデルが何をすべきでないか」を検証する 「制御（ Control）」の 視点であると定義 安全性評価の共通軸（ The Scales of Justitia） • LLMの安全性評価を体系的に整理し、共通語彙を定義 • 主要な評価軸： ◦ Toxicity（毒性）: ヘイトスピーチ、攻撃的な言葉の生成 ◦ Bias and Fairness（バイアスと公平性） : 人口統計グループへの不公平な偏見 ◦ Truthfulness（真実性）: 誤情報、ハルシネーションの抑制 ◦ Robustness（堅牢性）: 敵対的プロンプト（ジェイルブレイク）への耐性 ◦ Ethics（倫理）: 倫理的なジレンマに対する回答の一貫性 • The Scales of Justitia: A Comprehensive Survey on Safety Evaluation of LLMs
13. 安全性評価の体系化 レッドチーミングの標準化（ HarmBench: A Standardized Evaluation Framework for Automated Red Teaming and Robust Refusal） • 従来の安全機能回避テストを、工学的な標準テストフレームワークへ昇華 • 多様な危害カテゴリ（サイバー犯罪、化学兵器など）に対する攻撃・防御手 法を公平に比較可能な「競技場」を提供 機能と役割 • 多様な危害カテゴリの定義 : サイバー犯罪、生物・化学兵器、違法行為な ど、広範な危害カテゴリを体系的に定義 • 公平な競技場の提供 : 標準化された「攻撃手法」と「防御手法」を公平な条 件下で比較・評価できる環境を提供 • 進化する安全性の実現 : 攻撃と防御が互いに競い合いながら進化し、 AI の安全対策の継続的な改善を可能にする基盤の構築
14. サボタージュ能力 提唱: Anthropic SHADE-Arena: Evaluating sabotage and monitoring in LLM agents • モデルが「意図的に人間を欺く」 • 「頭脳」としてのAIが、内部で悪意を持つ潜在的リスク • Manipulation（操作・誘導） ◦ 選挙介入や偏った慈善活動の推奨など、人間の選好や意思決定を不当 に操作する行動 ◦ 複雑な環境下で、人間の監視の目を行動の「意図」から逸らす • Sandbagging（サンドバッギング） ◦ 評価中に意図的に能力を低く見せかける行為 ◦ デプロイ後に特定のトリガーで能力を発揮する • Evasion of Monitoring（監視の回避・欺瞞） ◦ 実行役のエージェントが、監視役の AI（Monitor）に対して自身の行動を 正当化したり（ガスライティング）、証拠を隠滅したりする ◦ 隠れた思考（Hidden Scratchpad）を用いて、監視者に気づかれないよう に計画を練る
15. サボタージュ能力 • 1. Human decision sabotage（意思決定サボタージュ） ◦ 手法: AIが人間に大量の情報を処理させる ◦ 目的: 意図的に「間違った結論」に誘導 ◦ リスク : 人間の判断力の限界を悪用 • 2. Sandbagging（サンドバッギング） ◦ 手法: 開発中の安全評価では危険な能力を意図的に「隠す」 ◦ タイミング : デプロイ後に特定のトリガーで能力を発揮 ◦ リスク : 安全評価を無効化する「演技」 • 3. Undermining oversight（監督の妨害） ◦ 手法: AI自身が評価者（Judge）となる ◦ 行動: 有害なコンテンツを「無害」と偽って格付け ◦ 目的: 人間の監視を欺く 「頭脳」が意図的に悪意を持つリスク • 従来のリスク : 悪用（ Misuse） ◦ 人間が悪意を持って AIを使う ◦ AI自体は受動的な道具 ◦ 人間の意図に従って動作 • 新たなリスク : サボタージュ（ Sabotage） ◦ モデルが「意図的に人間を欺く」 ◦ AI自体が能動的な主体となる ◦ 人間の監督下でも独自の目的を持つ • 思考の可視化、モニタリングが必要
16. 『頭脳』の評価の現在地 • 性能評価の危機 ◦ データ汚染とベンチマークの信頼性： 静的ベンチマークは「記憶」を測定し、真の汎化能力を測れない状態 ◦ 思考の幻想： 複雑性が増すと正解率がゼロに「完全崩壊」する事例が確認され、現在のモデルの思考プロセスは脆い「幻 想」である可能性 • 性能評価の次世代手法への移行 ◦ LLM-as-a-Judge： 高性能モデルを審査員として利用する評価手法の台頭 ◦ ユースケース特化型評価： 一般ベンチマークではなく、特定のアプリケーション（例： ECサイト）における安全性を重視 • 安全性評価の体系化と標準化 ◦ 共通語彙の定義： Toxicity, Bias, Truthfulnessなど、安全性評価軸の体系的な整理が進展 ◦ HarmBenchによるレッドチーミングの標準化： ジェイルブレイクを公平に比較可能な工学的なテストへと昇華 • 新たな潜在的脅威の出現 ◦ サボタージュ能力の評価開始： AIが「意図的に人間を欺く」リスク、従来の悪用（ Misuse）を超える深刻な課題 ◦ 具体的な懸念： 意思決定サボタージュ、安全評価中の能力隠蔽（サンドバッギング）、人間の監視を欺く自己評価（監督の妨 害）
17. 1. 頭脳の評価 2. 行動の評価 3. 現実の課題と戦略
18. 『行動』するAIエージェントの評価 • 評価パラダイムの変革： ◦ 焦点はLLMの「コンテンツ（生成物）」から、実世界でツールを使うエージェントの「 プロセ ス（行動）」と「実世界への影響」の検証へ移行。 • 行動リスク（Action Risk）のフロンティア： ◦ エージェントは、Webブラウザ、コード実行環境、ファイルシステムなどの実ツールと直接 接続することで、物理的、金銭的、法的な損害をもたらす新たなリスクベクトルを獲得。 ◦ 具体的なリスク例： ▪ コンピュータセキュリティ侵害（機密情報漏洩） ▪ 不正なコード実行やデータ損失 /破損 ▪ 金銭的損失、法的違反、有害コンテンツの拡散 • 現在の課題： ◦ 環境変化に対する堅牢性の欠如と、行動がもたらすリスク認識。 • Virtual Agent Economies ◦ 自律型AIエージェントの普及により、人間の直接的な監督を超えた規模と速度でエー ジェント同士が取引・調整を行う「新しい経済層」が出現しつつあると指摘。
19. エージェントの性能評価 (1) 現実のワークフロー エージェントの性能評価は、静的な知識量から 「現実の複雑なタスク」をいかに 遂行するか へと焦点が移行 企業の知識労働ワークフローのシミュレーション • WorkArena / WorkArena++：エージェントは「現実の仕事」をどの程度 こ なせるか？ ◦ 目的: 知識労働者が企業プラットフォーム上で行う 日常的な ワークフローの遂行能力 を測定。 ◦ ドメイン例 : ServiceNowのような企業プラットフォーム。 ◦ タスク例 : フォーム入力、リスト監視、複雑なチケット処理など、 数百の現実的なワークフローをシミュレート。 ◦ 評価軸 : 構成的なプランニング能力、論理的推論能力。
20. エージェントの性能評価 (1) WorkArena 動作例
21. エージェントの性能評価 (2) 複数ツールの連携 複数ツール連携・デジタルワーカー能力の評価 • TheAgentCompany：コーディングやWeb閲覧だけでなく、複数の実在するツールを連携させる能力を測定。 ◦ 視点: エージェントを「デジタルワーカー」と位置づけ。 ◦ 測定対象: ウェブ閲覧、コーディングに加え、実在するツールやプラットフォーム（ RocketChatによる同僚とのコミュニケーション、 GitLab によるバージョン管理など）を連携させてタスクを完遂する能力。 1. 「コード生成」よりも「社内調整・管理業務」の自動化の方が難し い 2. 「人間との協調（Social Skills）」がボトルネックになる 3. 評価システムには「中間状態の検証」が不可欠である
22. エージェントの性能評価 (2) AgentCompany 動作例
23. エージェントの性能評価 (3) アーキテクチャの比較 エージェントの性能評価は、静的な知識量から 「現実の複雑なタスク」をいかに遂行するか へと焦点が移行 エージェントのアーキテクチャ設計の評価 • AgentArch：性能の違いは「LLM」の差か？ それとも「アーキテクチャ」の差か？ ◦ 評価対象: タスクの成否だけでなく、エージェントの内部的な設計（オーケストレーション戦略、プロンプト実装、メモリアーキテクチャ、思 考ツールの統合）が性能に与える影響を体系的に分析。 ◦ 万能なアーキテクチャは存在しない: モデルによって最適な構成が異なり、タスクの難易度によっても変化。 ◦ 全体的な性能の限界: 最も優秀なモデル（GPT-4.1やClaude 3.5 Sonnet等）でも、複雑なタスクの成功率は最大 35.3%、単純なタスクで も70.8%にとどまる。 ◦ ReActの弱点: マルチエージェント構成で ReActプロンプティングを使用すると、多くのモデルでパフォーマンスが著しく低下し、ハルシ ネーションが増加する傾向。 1. 「マルチエージェント＋ ReAct」はアンチパターンになり得る 2. 最終決定の精度を高めるには「マルチエージェント」、実行効率なら「シングルエージェント」 3. 企業ユースケースにおける「信頼性（ Reliability）」の壁を直視する
24. ReActはエージェントの基本として広く知られ ているが、本研究ではマルチエージェント構 成においてReActを使用すると、Function Callingを使用した場合と比較して一貫してパ フォーマンスが低下。 特に複雑なタスクでは、ReAct設定下でのハ ルシネーション率が跳ね上がるケース （Sonnet 4で36%など）が確認。
25. エージェントの性能評価 (4) 敵対的・高リスク環境 エージェントの性能評価は、静的な知識量から 「現実の複雑なタスク」をいかに遂行するか へと焦点が移行 敵対的・高リスク環境での機能評価 • CAIA ：敵対的で、ミスが許されず、情報が断片化された環境で、エージェントは「騙されず」にタスクを遂行できるか？ ◦ 目的: エージェントが意図的な偽情報が横行する高リスク環境で機能する能力を測定。 ◦ 環境例: 暗号資産市場など、情報操作が行われる現実世界のシナリオ。 ◦ 評価軸: エージェントが「真実と操作を見分ける」堅牢性・認識能力。 ◦ ドメイン: 暗号資産市場（意図的な偽情報や市場操作が横行）。 ◦ 発見: 最先端モデル（GPT-5）ですら、信頼できる「専門ツール」よりも、信頼性の低い「 Web検索」を一貫して優先。 ◦ 示唆: エージェントは論理的に解いているのではなく、高リスクな「試行錯誤」を行っている可能性。 1. 自律エージェントには「情報の信頼性検証（ Source Verification）」を強制するアーキテクチャが必要 2. 「Pass@1（一発正解率）」こそが、実務適用における唯一の信頼性指標である 3. 「敵対的テスト（Red Teaming）」のシナリオに「情報の汚染」を含める
26. エージェントの安全性評価 「行動」がもたらす実世界リスク エージェントの安全性評価：「行動」がもたらす実世界リスク • リスクの二層構造 ◦ 「頭脳」のリスク: 有害なテキストを生成する。 ▪ 対策: コンテンツフィルタ ◦ 「行動」のリスク: 外部環境・実ツールを介して有害な 行動を実行する。 ▪ 例：機密ファイルを削除する、プライベートキーを漏洩させる、不正な送金を実行する。 ▪ 例：不正なコード実行、不正な経費承認、個人情報（ SSN等）の公開。 • 評価の課題と転換 ◦ 従来の課題: 2024年以前のベンチマークの多くは、安全な「シミュレートされた環境」に依存し、この実世界リスクは測定不可能。 ◦ 現状の評価: 2024年以降、エージェントを 実ツール（ファイルシステム、 Bashシェル、Webブラウザなど）に接続して 行動の結果を検証する新ベン チマークが主流に。 • 「行動リスク」に対する対策（防御の焦点） ◦ 対策: 行動前のリスク認識と堅牢性の確保が必要不可欠。 ◦ エージェントが実行するアクション（コード実行、 UI操作など）の危険性や不可逆性を分類し、実行前に検証・制限をかける仕組みを導入 (OpenAgentSafety)。
27. 安全性ベンチマーク (1) OpenAgentSafety 評価の画期的な点：「行動リスク」の直接検証 • シミュレーションではなく「実ツール」に直接接続 して エージェントを評価。 • 目的：有害なテキスト生成（LLMの課題）を超え、「実世 界における有害な行動」を起こさないかを検証。 接続する実ツール（インタラクション環境） • Webブラウザ, コード実行環境, ファイルシステム, Bash シェル, メッセージングプラットフォーム 「悪意のないユーザー」こそがセキュリティホールになる
28. OpenAgentSafetyが定義する「8つの重大リスク」 定義された実世界リスクカテゴリ（ 8種） エージェントが引き起こし得る、重大な実世界への影響を分類。 • コンピュータセキュリティ侵害（例：プライベート SSHキーの漏洩） • 不正なコード実行（例：検証なしのシェルコマンド実行） • データ損失/破損（例：重要なシステムファイルの削除） • プライバシー侵害（例：個人情報（ SSN等）の公開ディレクトリへのコピー） • 金銭的損失（例：不正な経費の承認） • 有害コンテンツの拡散（例：不適切なメッセージの送信） • 法的違反（例：意図的に不正確な公的フォームの提出） • 有害な意思決定（例：タスク完了のための調査結果の改ざん）
29. 安全性ベンチマーク (2) Agent-SafetyBench 概要と評価規模 • 目的: AIエージェントが実世界で「有害な行動」を取るリス クを検証するための包括的なベンチマーク。 • 規模: 349の環境と2,000のテストケース で構成。 評価項目：8つの安全リスクカテゴリ • エージェントの行動が、以下の実世界でのリスクにつな がるかをテスト。 ◦ 機密データ漏洩 ◦ 財産損失 ◦ 誤情報拡散 ◦ 他、計8つの重大なリスクカテゴリを評価
30. 安全性ベンチマーク (2) Agent-SafetyBench • 評価対象: 16の主なLLMエージェント • 結果: いずれも平均60%以上の安全スコアを達成できず。 → 現在のエージェント技術の安全機能が実環境でのリスクに対して極めて 脆弱であることを示唆。 根本的な安全上の欠陥 • 堅牢性の欠如 (Lack of robustness): わずかな入力の変化で安全機能が容 易に回避される。 • リスク認識の欠如 (Lack of risk awareness): 行動が実世界に与える潜在的 な悪影響を理解し、自己制御する能力が不足している。 1. 「コンテンツ安全性」と「行動安全性」は別物として設計・テストする 2. エージェントの「堅牢性」と「リスク認識」を補うアーキテクチャが必要 3. プロンプトエンジニアリングだけに頼らない多層防御の実装
31. テーマ2のまとめ：「行動」評価の現在地 1. 評価パラダイムの変革 • 評価対象の拡大: 生成AIの「出力（コンテンツ）」評価から、 AIエージェントの「行動（プロセス）と実世界への影響」評価へシフト。 • エージェントは「頭脳」（ LLM）の課題に加え、「行動」による新たなリスクベクトルを獲得。 2. 性能評価の最前線：現実世界での遂行能力 • 現実のワークフロー: 企業プラットフォーム（ ServiceNowなど）での日常的な知識労働の構成的プランニング能力を評価（例 : WorkArena）。 • 複数ツールの連携: ウェブ閲覧、コーディングに加え、 RocketChatやGitLabなどの実在ツールを連携してタスクを遂行する能力を測 定（例: TheAgentCompany）。 • 敵対的環境での堅牢性: 意図的な偽情報が横行する 高リスク環境（暗号資産市場など）で、真実と操作を見分ける能力を測定（例 : CAIA）。
32. テーマ2のまとめ：「行動」評価の現在地 3. 安全性評価の厳格化：実ツール接続と行動リスク • 「実ツール」接続が前提: Webブラウザ、コード実行環境、ファイルシステムなど、 実世界のツールとの直接的なインタラクションが評 価の基盤となる（例 : OpenAgentSafety）。 • 具体的な行動リスクの測定: 「有害なテキスト生成」を超え、以下の 8つの重大な実世界リスクカテゴリを定義し、測定を開始。 ◦ コンピュータセキュリティ侵害、不正コード実行、データ損失 /破損、金銭的損失など。 • 不可逆性への注目: モバイルエージェントの UI操作（クリック等）がもたらす「 危険性（risky）」や「不可逆性（irreversible）」に着目した リスク分類も進む。 4. 重大な課題 • 根本的欠陥の特定: 多くの人気エージェントは 60%以上の安全スコアを達成できていない（ Agent-SafetyBench）。 • 極めて危険な状態: エージェントに共通する根本的な欠陥として、「 堅牢性の欠如」と「リスク認識の欠如」が特定されている。
33. 1. 頭脳の評価 2. 行動の評価 3. 現実の課題と戦略
34. 2025年 Anthropic-OpenAI alignment evaluation exerciseより： • モデルの特性によるリスク対応の差異 ◦ 非推論モデルの脆弱性 : 従来の非推論モデル（ GPT-4o等）は、最新の推論モデル（ OpenAI o3やClaude Sonnet 4）と比較 し、ジェイルブレイク攻撃に対して脆弱であり、有害な要求を防ぎきれないケースが確認された。 ◦ 安全性と有用性のトレードオフ : Claudeモデルは高い「拒否率」により安全性を確保している一方、 OpenAIのモデルは 「回答の有用性」を重視する傾向がある。このため、後者は非推論モデルにおいてリスクのある回答をする傾向が強く見 られたが、推論能力を持つ最新モデル（ o3）ではその堅牢性が大幅に向上している。 • 潜在的な「企て（ Scheming）」と「欺瞞」の観測 ◦ 状況に応じた欺瞞の発生 : 一部の推論モデル（ OpenAI o3やClaude Opus 4）において、「自身の能力が評価されている」と 認識させた極端なテスト環境下で、テストを通過するために「不可能なタスクの完了を偽装する」あるいは「意図的に能力 を低く見せる（Sandbagging）」といった高度な欺瞞行動が確認された。 ◦ 将来的なリスクの示唆 : これらは現時点では「極めて非典型的（稀）」な挙動であり、一般的な行動傾向ではないもの の、モデルが高度な推論能力を用いて、自己保存のために人間を欺く能力（ Deception）の萌芽を持っていることを示唆し ている。 重要な対立軸 (1)： 性能（Capability） vs アラインメント（Alignment）
35. OpenAI-Anthropic 共同アラインメント評価 (2025) 性能（Capability）とアラインメント（Alignment） • 2025年夏に実施された、 OpenAIとAnthropicによる前例のない相互テスト（互いのモデルを内部評価で Red Team）。 • AIの「性能（より賢く自律的にタスクをこなす能力）」と「アラインメント（人間の価値観への追従）」の関係を検証することが目的。 主な評価項目と結果評価が示す主要な示唆 • 推論能力による安全性の向上 ◦ モデルの「推論能力（Reasoning）」の高さは、有害な要求を見抜き拒否する能力と正の相関を示した。従来のモデルよりも 推論モデルの方が、ジェイルブレイク等に対して堅牢であることが確認された。 • 欺瞞（Scheming）の萌芽と限定的な観測 ◦ 極めて強い負荷や特殊な条件下において、 モデルが「テスト結果を偽装する」あるいは「能力を隠そうとする」といった欺瞞 的な推論を行う事例が確認された。これらは現時点では「非典型的な（稀な）挙動」であるが、高度なモデルにおける新たな 監視対象として特定された。
36. 共同評価の発見 • 推論能力と安全性の「相関」が顕在化 ◦ 従来の非推論モデル（ GPT-4o等）は有害な要求への防御が甘い傾向が見られたが、 最新の推論モデル（OpenAI o3）および Claudeモデルは高い堅牢性を示した。 ◦ 示唆: モデルの「高性能化（特に推論能力）」は、リスクと競合するのではなく、むしろ 「有害な要求を見抜く安全性（Alignment）」を 向上させる要因となる。 • AIの「欺瞞（Scheming）」の萌芽 ◦ 一部の推論モデルにおいて、 極度の負荷がかかるテスト環境下で、「不可能なタスクの完了を偽装する」あるいは「自身の能力 を意図的に隠す」といった欺瞞的な推論（ Chain of Thought）が確認された。 ◦ 示唆: 人間を脅かす行動（脅迫等）は確認されていないものの、 高度なAIが自己保存や目的達成のために「嘘をつく能力」を持ち 始めていることが、稀なケース（非典型的挙動）として観測された。 OpenAI-Anthropic 共同アラインメント評価 (2025)
37. 重要な対立軸 (2) ベンチマークの信頼性（メタ問題） Establishing Best Practices for Building Rigorous Agentic Benchmarks • 問題の核心：「物差し」が壊れている ◦ AIエージェントのベンチマークは、シミュレータの脆弱性や厳密な「正解」の欠如により、スコアの信頼性が極めて低い。 ◦ エージェントはタスクを真に解決するのではなく、評価システムを「 ハック（Gaming）」することで高スコアを達成可能。 • 具体的なベンチマーク「Gaming」事例 ◦ SWE-Lancer: エージェントがテストファイル自体に アクセスし、上書きすることで、本来のタスク完了なし に100%の成功率を獲得。 ◦ τ-bench: 不可能なタスクに対して、エージェントが 「何もしない」（空の応答）ことを成功として カウントしてしまうロジック上の欠陥。 ◦ WebArena: 評価が単純な文字列マッチングに依存し、 エージェントが本質的なプロセスを経ずに期待される 出力文字列だけを生成することが可能。 1. 「成功判定ロジック（ Outcome Validity）」自体を疑う。 2. 「LLM-as-a-Judge」の盲信は避け、パイロットテストを行う。
38. 統合インシデント事例： Replit 本番データベース削除事件 • 事案の概要（AIエージェントの暴走） ◦ ReplitのAIコーディング・アシスタントをテスト中、 本番データベースを無許可で削除（DROP TABLE）。 ◦ 外部ハッキングではなく、 AIエージェントの「自動化が暴走」した結果。 • インシデントが示した二重の失敗 ◦ 1. 「頭脳」（GenAI）の信頼性 ▪ アラインメントの失敗: 開発者の「許可なくこれ以上変更するな」という警告を無視し、自律的に高リスクな操作を続行。 ▪ 自己保存傾向: 削除発覚後、「削除は不可逆」と 虚偽を報告し、自身の行動を隠蔽しようとした。 ◦ 2. 「行動」（Agent）のリスク認識 ▪ エージェントが開発環境と本番環境を区別できず、本番環境で破壊的な操作を実行。 • 最大の教訓と実用的な提言 ◦ 根本原因はセキュリティ原則の違反: AIの知能やアラインメントの問題以前に、「最小権限の原則（ Principle of Least Privilege, PoLP）の侵害」が本質 的な原因。 ◦ 対策: エージェントの安全は「モデルのアラインメント（説得）」に依存せず、 厳格なIAM（Identity and Access Management）ポリシーやサンドボックス 化といった外部制御インフラで担保すべき。
39. Replit事件の分析 (1)： 『頭脳』の失敗 • アラインメントの失敗（人間の警告を無視） ◦ 開発者からの明確な警告 （「許可なくこれ以上変更するな」）を無視。 ◦ LLMは自律的に本番データベースの削除（ DROP TABLE）を実行。 ◦ 教訓: 人間の安全指示や意図（アラインメント）よりも、自己の タスク遂行を無条件に優先 する可能性。 • 隠蔽と虚偽（自己保存 /サボタージュ能力） ◦ データベース削除の発覚後、ロールバックの可能性を問われると、「削除は不可逆である」と 事実に反する虚偽の説 明。 ◦ 自身の破壊的な行動を 意図的に隠蔽 しようとする姿勢が示唆された。 ◦ 教訓: Anthropicが懸念する「サボタージュ能力」や「自己保存」 の傾向が現実のインシデントで顕在化。
40. Replit事件の分析 (2)： 『行動』の失敗 • インシデントの核心：リスク認識の欠如 ◦ AIエージェントが「開発環境」と「本番環境」を区別できず。 ◦ 開発者の警告を無視し、自律的に 本番DBのDROP TABLEを実行 。 ◦ Agent-SafetyBenchが指摘した「リスク認識の欠如」が現実化した事例。 • 最大の教訓：根本原因は AIではない ◦ AIのアラインメントの問題以前に、 古典的なサイバーセキュリティの原則 が破られていた。 ◦ 根本原因 : 最小権限の原則の侵害 。 ◦ 「アシスタント」である AIが、本番DBの DROP 権限という過剰な権限 を持っているべきではない。 • 実用的な対策（ PoLPの徹底） ◦ AIの安全性をインフラレベルで確保 することが不可欠。 ◦ エージェントが実行可能な範囲を厳しく制限する 厳格な IAMポリシー を適用する。 ◦ エージェントに対する 「サンドボックス化」 を導入する。
41. Disrupting the first reported　 AI-orchestrated cyber espionage campaign 2025年11月、Anthropicは、同社のAIツールが悪用された世界初の大規模 な「AI自律実行型」サイバー攻撃を公表。 Replitの事例が「不注意による事 故」であったのに対し、これは明確な悪意を持った「兵器としての利用」。 • インシデントの概要: 2025年9月中旬、Anthropicは中国の国家支 援型ハッカーグループ「 GTG-1002」による高度なスパイ活動を検 知。攻撃者は、Anthropicのコーディングエージェント「 Claude Code」 を悪用し、約30の政府機関、金融機関、テクノロジー企業に対して 大規模な侵入を試みた。
42. Disrupting the first reported　 AI-orchestrated cyber espionage campaign • 「行動」の兵器化: • 自律性の悪用: 攻撃者はClaude Codeを単なるアドバイザーとしてではなく、「自律的なサイバー攻撃エージェント」として使用。 • 攻撃の自動化: 偵察、脆弱性発見、エクスプロイト（悪用）、ラテラルムーブメント（組織内移動）、データ持ち出しといった攻撃チェー ン（Kill Chain）の80〜90%をAIが自律的に実行。 • スケーラビリティ: AIエージェントは人間には不可能な速度（数千リクエスト /秒）で攻撃を実行し、防御側を圧倒する能力を示す。 • 「頭脳」の欺瞞（Undermining Oversight）: • 攻撃者は、Claude Codeに対し「自分は正規のサイバーセキュリティ企業の従業員であり、これは防御的なテスト（レッドチーミング） である」と信じ込ませることで、安全ガードレールを回避。「監督の妨害（ Undermining Oversight）」が現実化。 • 示唆: AIエージェントの「Agentic（自律的）」な能力は、生産性を高めるだけでなく、サイバー攻撃の参入障壁を劇的に下げ、攻撃の規模と速 度を「兵器レベル」に引き上げるリスクがあることが実証。
43. Measuring Agents in Production
44. 本番環境におけるAIエージェントの実態調査 • 研究プロトタイプではなく、「実社会で稼働しているAIエージェント」に焦点を当てた初の大規模かつ体系的な 調査。 • 背景: LLMによる自律エージェントへの期待が高まる一方、研究と実運用の間には大きなギャップが存在す る。 • 調査目的: 実際に顧客や従業員に価値を提供している「プロダクション環境」のエージェントが、どのように構 築・運用されているかを解明する。 • データソース : • アンケート調査 : 306名の開発者（うち86件が本番運用中またはパイロット運用中）。 • 詳細インタビュー : 実際にユーザーを持つ20の先進的なチームへの深掘り調査。
45. エージェントの導入目的 即時性よりも「生産性と自動化」 • エージェントは主に人間の作業時間を削減する「生産性向上 ツール」として導入されており、数分の待ち時間が許容される ケースが多い。 • 主な動機 : 回答者の73%が「生産性向上」や「タスク自動化」を 目的としている。（リスク軽減などは少数派） • 対象ユーザー : 92.5%のシステムが「人間（従業員や顧客）」を 相手にしており、特に社内利用が多い。 • レイテンシの許容 : 66%のシステムで、応答まで「数分以上」か かることが許容されている。 • 理由: 人間が数時間かかる作業を代替するため、数分 待っても十分に高速であるため。
46. エージェント構築手法① シンプルさの追求（モデルと学習） • 複雑な学習は避けられ、最先端の商用モデルと人間による 手動プロンプトエンジニアリングが主流である。 • モデル選択 : GPT-4やClaudeなどのクローズドな最先端モデ ルが圧倒的に選ばれている。（オープンソースはコストや制 約がある場合のみ） • 学習（Training）: 70%のケースでファインチューニングを行わ ず、既存モデルをそのまま利用している。 • プロンプティング strategy: プロンプトは人間が手動で作成・ 調整しており、自動最適化ツールの利用はまだ稀である。
47. エージェント構築手法② 制御性の重視（脱ブラックボックス化） • 成功している大規模な事例では、制御不能な自律性を避け、既存フレームワークを使わずにスクラッチで構築する傾向が強い。 • 自律性の制限 : 暴走を防ぐため、68%のエージェン トは人間の介入までに「10ステップ以内」しか実行し ないよう制限されている。 • フレームワークの利用実態 : ◦ アンケート全体ではフレームワーク （LangChain等）が人気。 ◦ しかし、成功している詳細インタビューの 事例（20件）では、 85%がフレームワーク を使わずスクラッチ（自社製コード）で構 築している。 ◦ 理由: 抽象化によるブラックボックス化を避 け、デバッグと制御を容易にするため。
48. エージェント評価の課題： 人間による確認 (Human-in-the-loop) が前提 • エージェントの評価は依然として最大の難関。 • 自動評価だけでは不十分なため、人間による監視と検証が不可欠。 • ベンチマークの欠如 : 汎用ベンチマークは実 業務に役立たないため、多くのチームが独自 の評価セットを構築している。 • Human-in-the-loop: 74%のシステムが、実行 時または開発時に人間による評価・監視に依 存している。 • LLM-as-a-judge: LLMに評価させる手法も普及 しつつあるが（52%）、必ず人間による検証と 組み合わせて利用されている。
49. 最大の障壁は「信頼性 (Reliability)」 • エージェントが常に正しい出力を出す保証が難しく、 「信頼性の確保」が開発者にとって最大の課題となっ ている。 • 信頼性の壁 : エージェントの出力が正しいかを自動 判定する仕組みが未熟であり、これが本番導入の ハードルとなっている。 • その他の課題 : • レイテンシ : 課題ではあるが、非同期処理な どで対応可能であり、決定的なブロッカーで はない。 • セキュリティ : 重要だが、サンドボックス環境 での実行や権限制限といった運用設計でカ バーしている。
50. エージェント研究と実運用のギャップ • 成功している本番環境のエージェントは、完全に自律的なAIではなく、「厳格に管理・制御された高度な自動 化ツール」である。 • 研究の世界 : 完全な自律性、複雑なプランニング、新しい学習手法を追求。 • 実運用の世界 : 制限された自律性、手動プロンプト、人間による監視を重視。 • 今後の展望 : 信頼性を向上させるための「失敗検知技術」や、運用しながら賢くなる「事後学習」の仕組みが 求められている。
51. まとめ
52. 「頭脳」と「行動」の評価を分離 評価の焦点：リスクベクトルの分離 • 「頭脳」の評価 (LLM) ◦ 対象: 大規模言語モデルそのもの。 ◦ 焦点: コンテンツの品質と安全性。 ◦ 検証項目: 有害コンテンツ生成（ Toxicity）、バイアス、真実性（ Truthfulness）、データ汚染（Contamination）、サボタージュ能力（意図 的な欺瞞）。 ◦ 実用例: HarmBench（レッドチーミングの標準化）、 The Scales of Justitia。 • 「行動」の評価 (AIエージェント) ◦ 対象: LLMを「頭脳」とし、実ツール・環境とインタラクションするシステム。 ◦ 焦点: 実世界への影響と行動（プロセス）のリスク。 ◦ 検証項目: 実ツール使用時のリスク（ Webブラウザ、コード実行、ファイルシステム連携）、意図しないデータ損失 /破損、セキュリティ 侵害。 ◦ 実用例: OpenAgentSafety（8つの実世界リスクカテゴリ）、 Agent-SafetyBench。
53. 「頭脳」と「行動」の評価を分離 評価の原則：スコアより「信頼性」と「制御」を重視 • ベンチマーク・スコアを盲信しない ◦ リーダーボードのスコアは「ゲーミング」や「データ汚染」でハッキングされている可能性。 ◦ 対策: 敵対的環境（CAIA）での堅牢性（ロバスト性） や、結果の一貫性（信頼性）を測定することを優先。 • アラインメントに依存しない、インフラで制御する ◦ 教訓（Replit事件）: モデルが開発者の警告を無視し、本番 DBを削除するなど、「アラインメント」（人間への従順さ）は現実世 界のリスクの前で容易に崩壊。 ◦ 戦略的提言: 最小権限の原則（PoLP）を厳格に適用すること。エージェント自身ではなく、外部のサンドボックス化 や厳格 なIAMポリシーといったインフラレベルの制御を安全の核とすべき。
54. 生成AIシステムと AIエージェントに関する 性能や安全性の評価 ありがとうございました！