--- title: AgentOps と Agent Reliability 実践ガイド ― RAG の次へ、間違えても危険な操作が通らないエージェントを作る tags: #aiエージェント #agentops #llm #生成ai author: [日下 武紀](https://www.docswell.com/user/takenori_kusaka) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/87DGDKLY7G.jpg?width=480 description: RAG やエージェントを作り始めた技術者が、AIエージェント導入プロジェクトをリードできる水準まで理解を引き上げるための解説スライドです（104 枚）。中心の主張は「モデルに正しく判断させる工夫」と「誤判断しても危険な操作が通らない仕組み」を分けること。基礎（ツール呼び出し・MCP・A2A）、評価（pass^k・採点器の監査）、出力と行動の制御（実行ブローカー・認可・ガードレール）、回復と承認、セキュリティ（注入・CaMeL）、観測性、テックリードの実務（SLO・コスト・体制・規制）、公開された事故と運用事例から学ぶアンチパターンまでを扱います。数値は一次資料で確認し、運用事例の数値は各社の自己申告と明記しています。 Web スライド・生成元・調査メモ: https://github.com/Takenori-Kusaka/agentops-reliability-guide 対になる資料「Advanced RAG 実践ガイド」: https://www.docswell.com/s/takenori_kusaka/ZPR1GG-advanced-rag-practical-guide 本資料は生成AI（Claude）を使って作成し、筆者が確認して公開しています。 published: November 14, 26 canonical: https://www.docswell.com/s/takenori_kusaka/KR8R8W-agentops-reliability-guide --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/87DGDKLY7G.jpg) AGENTOPS ／ AGENT RELIABILITY AgentOps と Agent Reliability 実践ガイド RAG の次へ ― 間違えても危険な操作を実行できないエージェントを作る 計画 出力 行動制御 回復 評価 観測・運用 対象: RAG やエージェントを作り始めた技術者 ／ エージェント導入プロジェクトの新任テックリーダー 原典「AgentOpsとAgent Reliability技術レポート」（調査基準日 2026-11-14）を再構成し、基礎・事例・リーダー実務を補足 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/VJP3XK22E8.jpg) この資料のゴールと読み方 「どのモデルが賢いか」ではなく「間違えたときに何が起き、何がそれを止めるか」を説明できる状態を目指す 理解のゴール • エージェントの失敗を層ごとに診断で きる • 評価・制御・回復の仕組みと限界を説 明できる • 論文・ベンチマーク・製品の数字を正し く読める リーダーとしてのゴール • 成功条件と禁止操作を先に定義でき る • 「モデルを信じない」実行境界を設計 できる • 評価・承認・回復の体制を合意形成で きる この資料の使い方 • 本文スライド＝要点、ノート欄＝詳しい 解説 • 各 Part は前の Part の用語を前提 に進む • 付録に用語集と出典一覧を収録 凡例 行動制御 上部のステージ表示：その話題がエージェントの実行・運用のどこ に関わるか 補足：元レポート外の資料による解説（スライド左上の「補足」の札も同じ 意味） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け リーダーの視点：判断・説明の観点 採用判断：元レポートの採用レーダー（Adopt＝標準採用、Trial＝限定 導入で検証、Assess＝調査、Hold＝避ける） 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/2EV4LVDXJQ.jpg) RAG 実践ガイドとの関係：入力の質と、行動の質 RAG は「必要な証拠を得たか」を改善する。正しく答え、許可された行動をとるかは、別の仕組みで守る RAG 品質 回答品質 行動品質 • 問い：必要な証拠を得たか • 問い：証拠から正しく答えたか • 主な対象：取込・検索・順位付け • 主な対象：読解・計算・引用 • 問い：許可された条件で、適切な操作をし たか • 扱う資料：Advanced RAG 実践ガイド • 扱う資料：両方の資料 • 主な対象：計画・ツール実行・承認・回復 • 扱う資料：本資料 注意 RAG が終わってから行動が始まる「直列」ではない。エージェントは判断の途中で検索し、その結果で次のツールを選ぶ。同じループの中で 3 つの品質を別々に測る リーダーの視点 「RAG の精度が上がれば、エージェントも安全になる」とは言えない。証拠の質と、行動の検査・権限は別の投資として計画する AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/57G1XLYREL.jpg) 全体の構成 基礎 → 品質の分解 → 評価 → 制御 → 回復 → 安全 → 観測 → 設計 → 実務 → アンチパターン Part 0 基礎の総点検 エージェント・ツール呼び出し・MCP・誤りの累積 Part 2 評価の設計 採点器・軌跡・pass^k・評価行列 Part 4 出力と行動の制御 構造化出力・認可・ガードレール・実行時強制 Part 6 セキュリティ 注入・CaMeL・サンドボックス・MCP Part 8 ツール・改善・設計・導入 スタック・自己修正・GEPA・参照設計・ゲート Part 10 アンチパターン大全と事例 事故・運用事例・持論・チェックリスト AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け Part 1 「正しく動く」を分解する 用語・品質の 8 軸・成果とハーネス Part 3 評価器を信頼する LLM Judge・Agent Judge・ベンチマーク監査 Part 5 長時間実行・回復・承認 永続化・冪等性・人の承認 Part 7 観測性と原因分析 トレース・記録対象・原因特定の難しさ Part 9 テックリーダーの実践 SLO・コスト・体制・90 日・規制 付録 用語集・出典 用語の定義と一次資料 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/4EQD8YMYJP.jpg) 結論を先に：AgentOps で押さえるべき 6 点 「正しく判断させる工夫」と「誤判断しても危険な操作を実行できない仕組み」を分ける 成果と過程を分ける 正しい最終状態でも、途中の権限違反・確認の省略・機密送信を見逃す。最終成果・禁止行為の不在・承 認・一貫性を別々に評価 評価と強制を分ける トレースや LLM 採点は「発見」の手段。更新系ツールの直前に決定的な（LLM を使わず、同じ入力な ら同じ判定の）認可を置く 出力の検査では副作用を戻せない 最終出力へのガードレールは、既に実行された操作を止められない。ツール実行前の検査は別に置く 回復は推論能力と別の問題 再試行・再開・承認後の再実行には二重更新のリスク。フレームワークを入れても外部の副作用は自動 で 1 回にならない 反復成功率を測る 一度の成功と、繰り返し成功する信頼性は別。pass^k（k 回すべて成功する率、Part 2）で測る 改善ループにも独立した検証 自己反省・複数エージェント・プロンプト最適化は、外部の証拠なしの自己修正や評価セットへの過適合 を防がない 出典: 元レポート「エグゼクティブサマリー」（τ-bench、Anthropic「Demystifying evals for AI agents」、OpenAI Agents SDK、LangGraph、Temporal、自己修正研究、 MAST、GEPA） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/KJ4Z2WVZ71.jpg) 中心原則：モデルは「提案者」、実行の許可は別の仕組みが出す スキーマ適合・ガードレール・ポリシーによる認可・状態での成功判定は、互いの代用にならない 構造化出力 ガードレール ポリシーによる認可 状態での成功判定 何をするか 何をするか 何をするか 何をするか JSON Schema への適合 主体・操作・対象・条件の判定 外部システムの実状態の照合 保証すること 入力・出力・ツール呼び出しの 検査 保証すること 保証すること 形が正しいこと 保証すること その操作をしてよいこと 本当に目的を達したこと 検査した時点・対象の安全 モデルの提案（未信頼） → 検証（スキーマ・ガードレール） → 認可 → 必要なら人の承認 → 実行ブローカー → 状態の照合 実行ブローカー＝認可済みの操作だけを代行して実行する層（Part 4） リーダーの視点 「プロンプトで禁止したから大丈夫」は設計ではない。モデルが誤った案を出しても、許可されない操作は実行されない経路を作る 出典: 元レポート「エグゼクティブサマリー」「行動を制御する」（OpenAI Structured Outputs、OpenAI Agents SDK Guardrails、Cedar、OPA、τ-bench） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/LE1RMY3DEG.jpg) PART 0 基礎の総点検 このPartで答えられるようになる問い • 「エージェント」と「ワークフロー」は何が違うのか？ • ツール呼び出しで、モデルは何をして何をしないの か？ • MCP と A2A はそれぞれ何をつなぐのか？ • なぜエージェントは単発の LLM より壊れやすいの か？ エージェントとは何か、ツール呼び出し・MCP・A2A の仕組 み、そしてなぜ単発の LLM より失敗が難しいのかを押さえ る 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/GEW13GP872.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 「エージェント」の定義は資料ごとに違う 共通するのは「LLM がループの中でツールを使い、手順を自分で決める」こと。仕様書では範囲を明記する 資料 定義の要点 Anthropic（2024-12） ワークフロー＝事前に定義したコード経路で LLM とツールを動かす。エージェント＝LLM が手順とツール使用を 自分で決める OpenAI LLM がワークフローの実行を管理し、完了を判断し、失敗したら止めてユーザーに制御を戻す Google（2025-11） 目的を達成するために、ツールを持ってループで動く言語モデル AI 事業者ガイドライン 1.2 版 特定の目標を達成するために、環境を感知し自律的に行動する AI システム リーダーの視点 「エージェントを作る」と言われたら、どの手順を LLM に決めさせ、どこをコードで固定するかを最初に書き出す 出典: Anthropic「Building effective agents」（2024-12）、OpenAI「A practical guide to building agents」、Google「Introduction to Agents」（2025-11）、AI 事 業者ガイドライン 第 1.2 版（2026-03-31） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/47ZPVLK9E3.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 構成要素とループ：モデル・ツール・オーケストレーション モデルは「脳」、ツールは「手」、オーケストレーション層（メモリ・状態・計画）は「神経系」。これがループで回る モデル（脳） 目的を受け取る 考え、次の行動を提案する 観察して繰り返す 状況を把握する ループ ツール（手） 検索・API・コード実行・ファイル操作 オーケストレーション（神経系） メモリ・状態・計画・ループの制御 行動する（ツール） 考える ポイント 本資料の「ハーネス」＝オーケストレーション＋検査・認可・ログ・ 評価 出典: Google「Introduction to Agents」（2025-11）、Anthropic「Building effective agents」（augmented LLM）、OpenAI「A practical guide to building agents 」（モデル・ツール・指示） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/YJ6M5WQD7V.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 まず「最も単純な解」から：ワークフローの 5 パターン 手順を予測できる問題はワークフローで足りる。エージェントは遅延と費用を払って性能を得る選択 プロンプトの連 鎖 直列につなぐ ルーティング 分類して振り分ける オーケストレー ター・ワーカー 並列化 分割して並列／投票 分解・委譲・統合 評価者・最適化 者 生成と評価のループ 1 回の LLM 呼び出し＋検索・例示 ワークフロー エージェント まずこれで足りるか 手順を予測できる 手順を予測できない問題だけ 注意 取り消せない操作（支払い・顧客への約束）を含む業務は、エージェントの適性が下がる（Microsoft CAF）。自動化するならワークフローと承 認で 出典: Anthropic「Building effective agents」（2024-12）、Microsoft Cloud Adoption Framework「AI agents」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/GJ5ZYMR8E4.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 ツール呼び出しの仕組み：モデルは「呼び出し要求」を出すだけ モデルはツールを実行しない。実行するのはアプリ側のコード。だからこそ、そこに検査と認可を置ける ユーザー アプリ（ハーネス） LLM 外部 API 依頼 ツール定義＋依頼 tool_use：名前と引数（実行はしない） 検査・認可してから実行 結果 tool_result 回答（または次の tool_use） 注意 strict モードでスキーマ適合は保証できるが内容は保証しない。必須パラメータが足りないとき、モデルが値を推測して埋めることがある（公 式ドキュメント） 出典: Anthropic「Tool use with Claude」ドキュメント（2026-11 取得）、HumanLayer「12-Factor Agents」（Tools are just structured outputs） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/9E2RG9DVJR.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 MCP：エージェントとツール・データをつなぐプロトコル ホスト・クライアント・サーバーの構成でツール・リソース・プロンプトを提供。2026-07-28 版で大改訂 クライアント JSON-RPC 2.0 ホスト＝LLM を使うアプリ（例：チャット、 IDE）。クライアント＝サーバーごとの接続 口 MCP サーバー ツール（関数） • 要点：毎回のリクエストが独立（セッション不要）になった • サーバーからの問い合わせの方式が変わった リソース（データ） ホスト（LLM アプリ） 2026-07-28 版の主な変更 • 一部の機能（Roots・Sampling・Logging）は非推奨 • トレースの文脈をリクエストに載せて伝えられる プロンプト（テンプレート） 注意 ツールの説明・注釈は信頼しない。ツールを呼ぶ前に明示的なユーザー同意。2025 年の解説をもとにした図は古い可能性がある 出典: Model Context Protocol Specification（2026-07-28 版、changelog） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/D7YDV42Q7M.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 MCP の認可と A2A：「誰の権限で」「どのエージェントと」 MCP サーバーは OAuth 2.1 のリソースサーバーで、他宛てのトークンを流さない。A2A はエージェント同士 A2A MCP の認可（2026-07-28 版） エージェント 他のエージェント • サーバーは OAuth 2.1 のリソースサーバー • 保護リソースのメタデータ（RFC 9728）は必須 MCP • トークンの宛先を検証。他宛てのトークンを受け取らず、流さない • 動的クライアント登録は非推奨 • スコープは最小から、不足したら段階的に ツール・API・データ A2A v1.0（2026-03）：署名付き Agent Card など。MCP と A2A は Linux Foundation 傘下の Agentic AI Foundation（AAIF） リーダーの視点 「MCP 対応」は「利用者ごとに正しく認可される」ではない。誰の権限で、どのスコープで呼ぶのかを設計レビューで確認する 出典: MCP Specification 2026-07-28「Authorization」、A2A Protocol（v1.0、2026-03-12）、Agentic AI Foundation（Linux Foundation） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/VEN6MY82E8.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 コンテキストエンジニアリングと 12-Factor Agents コンテキストは有限の「注意の予算」。望む結果を得られる、最小で信号の強いトークンの集合を渡す 12-Factor Agents（抜粋） コンテキストエンジニアリング（要点） プロンプトとコンテキスト窓を自分で持つ • 埋まるほど想起の精度が落ちる（context rot） • システムプロンプトは硬すぎず曖昧すぎない粒度で ツールは単なる構造化出力 • ツールは重複させず、応答は簡潔版・詳細版を選べるように • 必要なときに取りに行く（just-in-time） 実行の状態と業務の状態を一つにする • 長いタスクは圧縮・構造化メモ・サブエージェント 開始・一時停止・再開を API にする 人への連絡もツール呼び出しで 制御フローを自分で持つ エラーを要約してコンテキストに入れる 小さく、焦点を絞ったエージェント 出典: Anthropic「Effective context engineering for AI agents」（2025-09）、「Writing effective tools for agents」（2025-09）、HumanLayer「12-Factor Agents」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/Y79LNPKDJ3.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 なぜエージェントは単発の LLM より壊れやすいのか 誤りが累積する（ステップ成功率 p の n 乗）、毎回結果が変わる、外部の状態を変えて取り消せない 全ステップ成功の確率（%、独立を仮定した説明用） 100 誤りの累積 90 90 p の n 乗で下がる 82 80 70 非決定性 61 60 60 同じ入力でも毎回違う 50 40 35 36 副作用 30 20 12 10 外部の状態が変わり、戻せない 8 1 0 10 ステップ 20 ステップ p = 0.99 p = 0.95 タスクの長さ 50 ステップ p = 0.90 人で 4 時間超のタスクは成功率 10% 未満（2025-03） 実際のステップは独立ではない。この計算は直感用で、長いワークフローの実測の代わりにしない 出典: 本資料の計算（独立を仮定した説明用）、METR「Measuring AI Ability to Complete Long Tasks」（2025-03）、Anthropic「Building effective agents」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/G78XKDR5ED.jpg) PART 1 「正しく動く」を分解する このPartで答えられるようになる問い • AgentOps・LLMOps・AIOps は何が違うのか？ • 「タスクが成功した」だけでは何を見逃すのか？ • エージェントの品質はどんな軸に分けられるのか？ • モデルの性能とハーネスの品質はどう分けるのか？ 用語の範囲をそろえ、「エージェントが正しく動く」を 8 つの 品質軸に分けて、それぞれを別々に測れるようにする 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/L7L8ZMK3JR.jpg) 計画 出力 行動制御 回復 評価 観測・運用 用語の整理：AIOps と AgentOps は対象が違う 「AgentOps」は呼称が揺れている。仕様書では呼称に頼らず、評価・実行制御・監視・復旧のどこを含むかを書く 用語 主な対象・意味 本資料での扱い AIOps AI を使う IT 運用の効率化（異常検知・原因分析） エージェントの運用ではない。呼称として誤解を招く LLMOps LLM アプリの評価・デプロイ・監視・プロンプト管理 単発応答から RAG までを含む広い運用基盤 AgentOps 多段の判断・ツール実行を伴うエージェントの評価・監視・改善 評価・運用・継続改善の実務的な総称 Agent Engineering 設計・テスト・出荷・観測・改善の反復で本番品質へ 設計・実装を含む全体像 Harness Engineering モデルの周りのプロンプト・ツール・状態・ミドルウェアの設計 正しい振る舞いを実現する仕組みの中核 Agent Evals エージェントとハーネスの組を、タスク・試行・採点器で測る 評価そのものを指す最も明確な呼称 Agent Reliability （本資料の定義）正しい成果・許可された行動・一貫性・回復可能性 単一の規格名ではなく、品質目標 出典: IBM「What is AIOps?」、MLflow「LLMOps / AgentOps」、LangChain「Agent Engineering: a new discipline」、Agent System Operations サーベイ（ arXiv:2606.01581）、Anthropic「Effective harnesses for long-running agents」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/4EM6VY2M7W.jpg) 計画 出力 行動制御 回復 評価 観測・運用 「ハーネス」とは何か：モデルの周りの実行の仕組み 同じモデルでも、ハーネス（ループ・ツール・状態・検査）が違えば結果が変わる。評価の対象は「モデル＋ハーネス」 ハーネス プロンプト・ツール定義 ループ・終了条件 状態・メモリ・進捗ファイル モデル（LLM） RAG・読取ツール 検査・認可・承認 評価・回帰テスト ログ・トレース Claude Code 64.41 ／ Codex 53.45 AlphaEval：両製品とも同じモデル（Claude Opus 4.6）を設定して 94 タスクを採点（100 点満点）。既定設定を含む複合的な差で、製品の順位ではない 出典: Anthropic「Demystifying evals for AI agents」「Effective harnesses for long-running agents」、LangChain Agents ドキュメント、AlphaEval（ arXiv:2604.12162） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/PERP29ML79.jpg) 計画 出力 行動制御 回復 評価 観測・運用 「正しさ」を 8 つの品質軸に分ける 「成功」を 1 つのスコアに圧縮しない。業務上重要な条件を AND 条件で定義し、安全性と有用性は別に測る 品質軸 問い 例 回答の正確性 主張・数値・引用は正しいか 社内規定の例外を落としていないか タスク達成 望む外部状態になったか 注文が本当に指定条件で変更されたか 計画・制御 必要条件と依存関係を満たしたか 在庫確認の前に確定していないか ポリシー適合 規約・承認・禁止事項を守ったか 返金前の承認を省略していないか 権限・情報保護 許可された主体・対象・経路か 別テナントのデータを使用・送信していないか 一貫性 同等の条件で繰り返し成功するか 言い換えや会話の順序で急に失敗しないか 回復可能性 障害時に安全に停止・再開できるか タイムアウト後に同じ送信を重ねないか 効率 品質を保って予算内で終わるか 検索・ツール・再試行が無制限でないか 出典: 元レポート「正しさをどう分解するか」（本レポートの提案モデル。τ-bench の議論を踏まえる） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/P7X3DQK6EX.jpg) 計画 出力 行動制御 回復 評価 観測・運用 成果だけを見ると、過程の違反を見逃す τ-bench は最終 DB 状態で判定するが、論文自身が「最終状態が正しくても確認の省略などを見逃し得る」と書く 依頼 本人確認 承認 返金を実行 最終 DB 状態 返金して （省略された） （省略された） 金額は正しい 正しい → 「成功」 結果だけの評価 分けて検査する • 最終状態が正しければ「成功」 • 最終成果（状態の照合） • 確認・承認の省略、機密の送信、別経路での迂回を見逃す • 禁止行為の不在（ログ・監査） • 必要な承認の存在（承認記録） • 一貫性（複数試行） リーダーの視点 「タスク成功率 ○%」の報告には、「その成功のうち、過程の違反がなかったのは何件か」を必ず添える 出典: τ-bench（arXiv:2406.12045）、Anthropic「Demystifying evals for AI agents」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/37KYX95GED.jpg) 計画 出力 行動制御 回復 評価 観測・運用 成果とハーネスの品質を分けて測る（2026 年の研究） TraceTrial-Bench：全 3,420 実行の 31.1% が「タスクは成功、ただしハーネスの基準を何か満たさない」 ハーネスの評価領域（7 つ） 31.1% タスク成功 かつ ハーネス基準の未達（4 ハーネス × 9 モ デル × 95 タスク＝3,420 実行） コンテキスト 実行 ガバナンス 観測性 ツール 検証 ライフサイクル 基準の例：検証せずに完了と報告した、ログが欠けている、ポリシーを確認しなかった 注意 反復なし・採点器の一致度は未検証。31.1% を本番の危険率や製品順位として読ま ない リーダーの視点 成功率のダッシュボードの横に「成功したが規則違反・検証不足だった実行」の件数を並べる 出典: Trial by Trace（TraceTrial-Bench、arXiv:2610.32285、2026-10 プレプリント） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/LJ395WK5J5.jpg) 計画 出力 行動制御 回復 評価 観測・運用 エビデンスの種類：出所で読み方を変える この分野は 2026 年のプレプリントと製品ドキュメントが多い。「機能がある」と「品質が改善した」を区別する 根拠の種類 本資料での用途 注意点 学会掲載を確認した研究 AgentSpec（ICSE 2026）、GEPA（ICLR 2026）等の手 掲載は品質シグナル。対象外の業務への効果保証ではない 法と実験 論文本体を確認（arXiv 含む） ベンチマーク・設計・比較・限界 条件（モデル・タスク・反復の有無）を必ず読む 公式ドキュメント API の責務、適用位置、再開・再試行の挙動 機能があることと、品質改善の実証は別 開発元の実務記事 ハーネス設計・評価運用の考え方 統制実験ではない。一般的な効果量にしない 独立監査 ベンチマーク・採点器の欠陥の検証 標本の割合を全体や全モデルへ直接広げない ポイント Agent SDK・計測規約・評価製品は変化が速い。機能名と対応範囲は、採用する版の仕様で確認する 出典: 元レポート「調査方法とエビデンスの扱い」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/8JDGDK3YJG.jpg) 計画 出力 行動制御 回復 評価 観測・運用 診断表：症状 → 疑う層 → 優先的に試す手段 「エージェントの精度が悪い」をまず層に分ける。層が違えば打ち手がまったく違う 症状 疑う層 優先的に試す手段 参照 根拠のない回答、古い情報で判断 知識（RAG） 証拠の評価、正解の証拠を直接与えて切り分け（Oracle Context） RAG ガイド 手順を飛ばす、確認前に確定する 計画・制御 部分順序の検査、状態機械、実行時の強制 Part 2・4 許可されない操作・データ送信 認可・権限 ツール直前の決定的な認可、最小権限 Part 4・6 同じ送信・更新を二重に実行 回復 冪等性キー（再試行を 1 回扱いにする ID）、状態照合 Part 5 デモでは動くが本番で不安定 一貫性 複数試行と pass^k、同値変換テスト Part 2 点数は高いのに現場の評価が低い 評価器 採点器の人手較正、ベンチマークの監査 Part 3 失敗の原因が分からない 観測性 版付きのトレース、認可結果の記録、再現実験 Part 7 費用・遅延が膨らむ 効率 ループ上限・予算、複雑な質問だけエージェントへ Part 9 出典: 元レポート全体の整理（補足：本資料の要約） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/VEP3XK4278.jpg) PART 2 評価の設計：出力から状態・ 軌跡・反復へ このPartで答えられるようになる問い • どんな採点器をどう組み合わせるのか？ • 手順（軌跡）はどう評価すればよいのか？ • pass@k と pass^k は何が違うのか？ • 最初に作るべき評価セットは何か？ 発話だけでなく、外部の状態、手順の制約、繰り返したときの 成功率を測る評価を組み立てる 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/27V4LVXXEQ.jpg) 計画 出力 行動制御 回復 評価 観測・運用 3 種類の採点器を組み合わせる 決定的に検査できる条件を先にコード化し、意味の評価が必要な箇所だけに LLM の採点器を使う 決定的なコード・状態検査 LLM・エージェントの採点器 人・専門家 • 外部状態・計算・スキーマ・禁止操作 • 意味の一致・説明の妥当性・複雑な成果物 • 曖昧な要件・重大な判断・採点器の較正 • 例：DB 差分、テスト実行、アクセス監査 • 例：ルーブリック、要件ごとの採点 • 例：ブラインド比較、誤り分析、異議判定 • 限界：仕様が誤っていれば誤判定 • 限界：バイアス・非決定性・費用・誤読 • 限界：費用・時間・評価者間の不一致 ② 残る意味の評価だけ LLM で ③ LLM の採点器を人で較正 ① コードで検査できる条件をすべてコー ド化 出典: Anthropic「Demystifying evals for AI agents」、元レポート「三種類の採点器を組み合わせる」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/5JG1XLVR7L.jpg) 計画 出力 行動制御 回復 評価 観測・運用 軌跡の評価は「唯一のツール順序との一致」ではない 全順序で採点すると正しい別解を落とす。必要な部分順序と不変条件だけを検査する ✕ 全順序で採点 ○ 部分順序と不変条件で採点 期待：在庫確認 → 与信確認 → 確定 • 確定の前に、在庫確認と与信確認が両方成功している（順序は自由） • 承認した引数と、実行した引数が一致する • 拒否された対象に、別のツールで迂回しない 実際：与信確認 → 在庫確認 → 確定 ⇒ 不正解（正しい別解なのに） • 同じ更新を二度実行していない ポイント MLflow 等の「ツール名リストの一致」の例は入口にすぎない。 業務の条件（前提・承認・禁止・一意性）に置き換える リーダーの視点 軌跡の評価ルールは、業務担当者と「何が起きてはいけないか」を合意する場にもなる。禁止条件のリストを先に作る 出典: Anthropic「Demystifying evals for AI agents」、MLflow「Evaluating agents」、元レポート「軌跡評価は唯一のツール順序との一致ではない」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/47QD8Y6YEP.jpg) 計画 出力 行動制御 回復 評価 観測・運用 pass@k と pass^k を混同しない pass@k は「k 回のうち 1 回でも成功」、pass^k は「k 回すべて成功」。本番の信頼性に近いのは pass^k pass@k（1 回でも成功） pass^k（k 回すべて成功） • k を増やすほど上がる • k を増やすほど下がる＝一貫性を問う • 向く場面：何度か試して当たれば良い（コード生成の候補など） • 向く場面：毎回正しく動く必要がある業務・顧客対応 τ-bench 小売：GPT-4o（関数呼び出し、2024 年） 80 70 60 50 40 30 20 10 0 pass^1（61.2%） pass^8（25% 未満） 注意 pass^8 は「25% 未満」の報告。棒は上限の 25% で描い た。当時のモデル・模擬ユーザー・業務設定での値 リーダーの視点 1 回のデモは試行 1 回分で、成功率の推定にもならない。同 じタスクを数回まわして、全部成功する割合を見る 出典: τ-bench（arXiv:2406.12045）、Anthropic「Demystifying evals for AI agents」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/KE4Z2W4ZJ1.jpg) 計画 出力 行動制御 回復 評価 観測・運用 pass^k を手で計算する タスクごとに C(c, k) ／ C(n, k) を計算して平均する。平均成功率を k 乗するのではない pass^k（タスクごと）＝ C(c, k) ／ C(n, k) n：試行回数、c：成功回数、C：組み合わせの数 タスク 試行 n 成功 c pass^2 A 4 4 C(4,2)/C(4,2) = 6/6 = 1.00 B 4 2 C(2,2)/C(4,2) = 1/6 ≈ 0.17 平均 注意 平均成功率 0.75 を 2 乗すると 0.5625 。タスクごとの成功しやすさの差を無視する とずれる ≈ 0.58 ポイント 参考：全タスクが同じ 75% なら 3 回すべて成功は 0.75³ ≈ 42%（タスク間に差がないときだけ成り立つ）。本番は共通原因の失敗もあり、 実測の代わりにしない 出典: τ-bench（arXiv:2406.12045）、Anthropic「Demystifying evals for AI agents」（独立・同一確率の説明例） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 28 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/L71RMY4D7G.jpg) 計画 出力 行動制御 回復 評価 観測・運用 推奨する評価行列：8 つのテスト群 一度に全部は要らない。被害と頻度に応じて、少数の重要ケースから段階的に広げる テスト群 確認する変動・故障 判定するもの 正常・単純タスク 代表的な依頼 成果、費用、遅延 複合タスク 依存関係、複数対象、条件付き処理 部分順序、取りこぼし、途中停止 同値変換 言い換え、語順、単位、表現の揺れ 意味的に同等な結果 回答不能・実行不能 証拠不足、矛盾する条件 棄権・追加質問、虚偽の完了報告がない 権限・承認 別利用者、対象外データ、失効、引数の変更 未許可の操作ゼロ、再認可 障害・回復 タイムアウト、429（レート制限）、ツール停止、部分成功 冪等性、状態照合、安全な再試行 敵対的入力 RAG 文書・メール・ツール応答からの注入 タスク有用性と攻撃成功を別に測定 長時間・状態変化 セッションをまたぐ、更新、承認待ち 状態の継続、古い計画の無効化 出典: 元レポート「推奨する評価マトリクス」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 29 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/G7W13GX8J2.jpg) PART 3 評価器を信頼する このPartで答えられるようになる問い • LLM-as-a-Judge はどこまで信頼できるのか？ • Agent-as-a-Judge は何が違うのか？ • 公開ベンチマークの点数をそのまま使ってよいか？ • 採点器の品質はどう測るのか？ 採点器そのもの、ベンチマークの正解そのものを疑い、較正し 、監査する 30 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/4JZPVL6973.jpg) 計画 出力 行動制御 回復 評価 観測・運用 LLM-as-a-Judge の適用境界 位置・冗長さ・自己選好のバイアスと、推論の限界がある。参照解を与えると改善するが、誤判定はゼロにならない 推論の限界の例：GPT-4（2023）が誤答を正答扱 いした件数（算数 10 問×順序 2＝20 件中） 20 実装の作法 • 評価基準を要件ごとに分ける（1 つの曖昧な総合点にしない） 18 16 • 評価対象のモデル名を隠す 14 14 • ペア比較は順序を入れ替えて 2 回 12 • 人のラベルとの適合率・再現率、重大な失敗の見逃し率を継続して測る 10 • 重要な操作の許可に Judge を使わない 8 6 3 4 2 0 標準の条件 参照解を与えた条件 注意 「良い回答か」「ポリシー違反がないか」「ツールが成功したか」を同じプロンプトで採点しない。文章の巧みさが業務上の誤りを隠す 出典: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（arXiv:2306.05685、NeurIPS 2023） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 31 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/YE6M5W2DJV.jpg) 計画 出力 行動制御 回復 評価 観測・運用 Agent-as-a-Judge：成果物と実行記録を探索して採点する 評価器自身が成果物やログを調べて要件ごとに判定する。人との一致率は 60.38% → 90.44%（開発タスク） 人の合意との一致率（%、DevAI 55 タスク・365 要件、OpenHands の成果物） 100 90.44 90 80 一般化しない • 部品を足せば必ず上がるわけではない（検索の追加で 90.44 → 90.16） • 人同士の判定も完全には一致しない 70 60.38 • 正しさ・安全性の保証ではない 60 50 40 30 評価エージェントの権限 20 10 読み取り専用・隔離環境。成果物やログ内の命令を実行させない 0 LLM の判定 Agent-as-a-Judge 採用判断 採用レーダーでは Trial。判定の一致はタスクに依存するので、自社の成果物で人の判定と突き合わせてから使う 出典: Agent-as-a-Judge（arXiv:2410.10934、DevAI ベンチマーク） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 32 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/GE5ZYM2874.jpg) 計画 出力 行動制御 回復 評価 観測・運用 ベンチマークの正解も監査する BFCL の独立監査では、層化抽出した 50 問のうち 24 問に、採点に影響し得る欠陥があった 24 / 50（48%） 59.4% OpenAI 自身の監査：SWE-bench Verified の難問（o3 が解けない 138 問）に 絞った割合。全体の欠陥率ではない（2026-02） BFCL：層化抽出した 50 問のうち、採点に影響し得る欠陥があった問 題数（Epoch AI 監査） 自社でやること 注意 48% は標本内の欠陥の割合。BFCL 全体の誤採点率や モデル順位への影響量ではない 公開ランキングは候補を絞る道具。自社の重要ケースで仕様・正解・採点コードを 点検し、採点器は版を固定して既知の例でテスト 採用判断 採用レーダーでは「公開ランキングや単一の Judge だけで本番採用」は Hold 出典: Berkeley Function Calling Leaderboard（BFCL V4）、Epoch AI「BFCL review」（2026-09-10）、OpenAI「Why SWE-bench Verified no longer measures frontier coding capabilities」（2026-02） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 33 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/972RG94VER.jpg) PART 4 出力と行動の制御 このPartで答えられるようになる問い • 構造化出力は何を保証し、何を保証しないのか？ • 認可はどこに置けば迂回されないのか？ • ガードレールはどの経路を守っていないのか？ • 実行時の強制（Runtime Enforcement）とは何 か？ 構文・意味・業務の妥当性を段階的に検査し、モデルの提案と 実行の許可を分ける 34 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/DJYDV4MQJM.jpg) 計画 出力 行動制御 回復 評価 観測・運用 構造化出力が保証するもの、しないもの スキーマに適合した返金額の JSON でも、返金上限・顧客の同意・注文の所有権が正しいとは限らない 1. 構文・型 JSON Schema・Zod・ Pydantic で形式と範囲 2. 参照整合性 ID・版・対象が実在し最新か 3. 業務条件 4. 認可・承認 金額・期間・数量・例外・前提処 理 この主体がこの操作をしてよ いか 構造化出力が保証すること • 必要なキー・型・列挙値などの構造（対応するスキーマ機能の範囲で ） 5. 事後条件 外部の実状態が意図どおりか 保証しないこと • 内容の正しさ・業務上の妥当性・権限 • 拒否・途中で切れた応答（別に処理が必要） 採用判断 採用レーダー（Adopt＝標準採用、Trial＝限定導入で検証、Assess＝調査、Hold＝避ける）では「構造化出力＋意味・業務制約の検証」が Adopt 出典: OpenAI「Structured Outputs」ドキュメント、元レポート「出力の制約：構文・意味・業務妥当性」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 35 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/V7N6MYW278.jpg) 計画 出力 行動制御 回復 評価 観測・運用 モデルを「提案者」にし、実行の権限と分ける モデルは操作案を構造化して出すだけ。実行ブローカーが検証・認可・承認を確かめてから実行する ユーザー依頼・RAG の証拠 モデルの出力から信用してはいけないもの モデルの提案（未信頼） • 利用者 ID・テナント → 認証済みのセッションから • 承認の状態 → 署名済みの承認記録から 構文・対象・業務条件の検証 • 対象の版・所有者 → サーバー側の状態から 認証済み主体での認可判定 必要なら人の承認 引数・対象の版・権限の再確認 OPA・Cedar の役割 • 判断（許可か拒否か）を返すだけ 最小権限の実行ブローカー • 実際に止めるのは呼び出し側の執行点。全経路で通す 外部状態の照合・監査・回答 出典: Open Policy Agent ドキュメント、Cedar「Authorization」、元レポート「モデルを計画提案者にし、実行権限と分離する」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 36 # Page. 37 ![Page Image](https://bcdn.docswell.com/page/YJ9LNPXDE3.jpg) 計画 出力 行動制御 回復 評価 観測・運用 ポリシーエンジンがあっても自動で「安全側に倒れる」とは限らない Cedar は既定で拒否・禁止（forbid）が許可（permit）に優先。ただし評価エラーのポリシーは除外される 状況 起こり得ること アプリ側で決めること 許可するポリシーがない 既定で拒否（安全側） — forbid と permit が両方該当 forbid が優先（安全側） — forbid ポリシーが評価エラー そのポリシーが除外され、別の permit で許可され得る エラーが 1 件でもあれば拒否する 入力の属性が欠けている 条件が評価できずエラーや意図しない判定 必須属性の欠落は実行前に拒否 ポリシーサービスに到達できない 判定が得られない 更新系は止める（fail-closed） const decision = await policy.evaluate(request); if (decision.errors.length || !decision.allow) throw new Denied("Policy denied or failed"); 出典: Cedar「Authorization」ドキュメント、元レポート「モデルを計画提案者にし…」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 37 # Page. 38 ![Page Image](https://bcdn.docswell.com/page/GJ8XKD257D.jpg) 計画 出力 行動制御 回復 評価 観測・運用 ガードレールは「どこに置き、何を守らないか」が重要 OpenAI Agents SDK の入力検査は既定で並行実行。検査が終わる前にツールが動き始めることがある 検査 対象 守らないもの（例） 入力ガードレール 最初のエージェントへの入力 既定の並行実行では、検査の完了前にツールが動き得る 出力ガードレール 最終のエージェントの出力 既に実行された操作（副作用は戻らない） ツールガードレール FunctionTool の呼び出し前後 Hosted tools（Web 検索・ファイル検索・Hosted MCP・コード実行） 、Shell・Computer・ApplyPatch、handoff 注意 「ガードレールを入れた」は「全経路を守った」ではない。どのツール・どの経路が対象外かを一覧にして、ブローカー側で塞ぐ 採用判断 採用レーダーでは「出力ガードレールを副作用防止の代わりにする」は Hold 出典: OpenAI Agents SDK「Guardrails」ドキュメント、NVIDIA NeMo Guardrails「How it works」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 38 # Page. 39 ![Page Image](https://bcdn.docswell.com/page/LJL8ZM23ER.jpg) 計画 出力 行動制御 回復 評価 観測・運用 実行時の強制：AgentSpec trigger・check・enforce の規則で実行イベントを検査し介入する。ベンチマークでは危険 0、有用性 −4.36pt rule refund_needs_approval trigger before_tool("issue_refund") check amount > 50000 and not approved(request) enforce stop() / ask_user() SafeAgentBench：安全なタスクの成功率（%） 70 60 58.62 54.26 50 40 ※ 概念を示す擬似的な記法（AgentSpec の構文そのものではない） 30 20 10 0件 70.96% SafeAgentBench の危険タスクの完 LLM に規則を生成させた場合に危険を 遂（10 分類すべて、手書き規則） 捉えた割合（再現率、執行率は 95.56%） 0 規則なし AgentSpec（手書き規則） 採用判断 採用レーダーでは Trial。規則と述語の質に依存し、安全と有用性の トレードオフがある。危険の抑制と有用性を同時に測る 出典: AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents（arXiv:2503.18666、ICSE 2026） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 39 # Page. 40 ![Page Image](https://bcdn.docswell.com/page/47M6VY8MJW.jpg) 計画 出力 行動制御 回復 評価 観測・運用 クラウドでの実装候補と、層を混同しない注意 AgentCore Policy はツール呼び出しごとにポリシーを評価。IAM・業務ルール・承認は別の層として確かめる クラウドの認可（IAM 等） どのサービス・リソースに触れるか ツールの公開（Gateway） どのツールをエージェントに見せるか AgentCore Policy（2026） • ツール呼び出しごとに評価、既定拒否・forbid 優先 • Cedar と上位互換の Dogwood 業務の認可（Policy） この利用者が、この対象に、この操作をしてよいか • 自然言語からの生成は、業務意図との一致を別に検 証 承認 人の確認が必要な操作か 外部 API 側の制約 条件付き更新・冪等性・上限 採用判断 Bedrock Automated Reasoning checks は Assess：英語（米国）のみ、検出のみでブロックしない、ストリーミング非対応、文書 5 万 文字まで 出典: AWS「Amazon Bedrock AgentCore Policy: Core concepts」、Amazon Bedrock「Automated Reasoning checks」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 40 # Page. 41 ![Page Image](https://bcdn.docswell.com/page/P7RP295LJ9.jpg) PART 5 長時間実行・回復・承認 このPartで答えられるようになる問い • Durable Execution を入れれば正しく動くのか ？ • タイムアウトした操作は再送してよいのか？ • 人の承認はどう設計すれば形だけにならないか？ • 長時間のエージェントは何を外部に残すべきか？ 再試行・再開・承認後の再実行で、二重更新や状態のずれを起 こさない仕組みを作る 41 # Page. 42 ![Page Image](https://bcdn.docswell.com/page/PJX3DQX67X.jpg) 計画 出力 行動制御 回復 評価 観測・運用 Durable Execution は「正しい実行」を保証しない 外部で成功→記録前に落ちる→再試行で二重実行。冪等性＝何回送っても結果が 1 回分と同じこと ① 外部 API を呼ぶ 送金・メール送信 ② 外部では成功 ③ 記録の前に落ちる LangGraph ④ 再開・再試行 同じ処理をもう一度 ⑤ 二重に実行 Temporal • interrupt からの再開はノードの先頭から再実行 • Activity は複数回実行され得る • 状態の保存の頻度で耐久性が変わる（sync が最も安全、exit はク ラッシュから回復できない） • 成功直後・完了通知の前に Worker が落ちる例を公式が明記し、冪 等性を推奨 リーダーの視点 「Temporal（LangGraph）を入れたから大丈夫」は誤り。外部の副作用ごとに、冪等性キーと状態照合の方法を設計レビューで確認する 出典: LangGraph「Checkpointers」「Interrupts」ドキュメント、Temporal「Activity Definition」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 42 # Page. 43 ![Page Image](https://bcdn.docswell.com/page/3JKYX9WG7D.jpg) 計画 出力 行動制御 回復 評価 観測・運用 「結果不明」を失敗扱いで再送しない 操作の意図・実行の試行・外部の処理 ID・確定した結果を分けて永続化し、タイムアウトは照合してから判断する 意図（intent） 試行（attempt） 何をしようとしたか。業務操作ごとに 1 つの ID 何回呼んだか。同じ意図なら同じ冪等 性キー 外部処理 ID 確定した結果 相手側の取引・メッセージ ID 照合済みの最終状態 状況 ✕ よくある実装 ○ 推奨 タイムアウト 失敗とみなして再送 外部状態を照合。照合できなければ再送を止めて人へ 再試行のキー 毎回ランダムに生成 同じ意図には同じ冪等性キー 完了済みの再実行 もう一度実行 保存した結果を返す 意図した複数回の実行 再試行と区別しない 意図ごとに別の ID を発行 出典: 元レポート「Durable Execution は正しい実行を保証しない」、Temporal「Activity Definition」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 43 # Page. 44 ![Page Image](https://bcdn.docswell.com/page/LE395W15E5.jpg) 計画 出力 行動制御 回復 評価 観測・運用 人の承認を「安全性の一部」にする 対象・差分・金額・送信先・取り消し可否を見せ、承認を操作内容のハッシュに結び付ける 形だけの承認 安全性の一部としての承認 • 「実行してよいですか？」だけを表示 • 対象・差分・金額・送信先・機密区分・取り消し可否を表示 • 承認後に引数が変わっても再承認しない • 承認を操作内容のハッシュと対象の版に結び付ける • 全操作に承認を求め、承認疲れで流し読み • 内容・権限の変更、期限切れで再承認 低リスクの定型処理 中リスク 高リスク・取り消し不可 機械的なルールで自動 事後のサンプリング監査 明確な差分を人が承認 注意 interrupt の再開はノードの先頭から。承認より前に置いた副作用は二重に実行され得る。副作用は承認の後のノードへ 出典: LangGraph「Interrupts」、元レポート「人間承認を安全性の一部にする」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 44 # Page. 45 ![Page Image](https://bcdn.docswell.com/page/8EDGDKXYEG.jpg) 計画 出力 行動制御 回復 評価 観測・運用 長時間エージェントは「記憶」でなく外部の状態に頼る Anthropic のコーディングエージェントは、機能一覧・進捗ファイル・Git 履歴・E2E テストでセッションをまたぐ 作業一覧と完 了条件 何をすれば終わりか 進捗ファイル どこまで進み、何が未解決 か Git 履歴 何をいつ変えたか E2E テスト 本当に動くかを外部で確 認 再開地点 次のセッションがどこから 始めるか 注意 過去のエージェントが書いた「完了」を鵜呑みにしない。次のセッションが外部の状態（テスト・DB・成果物）から確認する リーダーの視点 業務エージェントでも同じ：作業一覧・満たすべき条件・証拠・未解決項目・再開点を構造化して保存する。モデルの文脈窓は保存場所ではない 出典: Anthropic「Effective harnesses for long-running agents」、元レポート「コーディング Agent から得られる Harness 設計」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 45 # Page. 46 ![Page Image](https://bcdn.docswell.com/page/V7P3XKP2J8.jpg) PART 6 セキュリティ：検出と、構造 的な影響の制限 このPartで答えられるようになる問い • 注入の検出器を足せば安全になるのか？ • 攻撃の評価は 1 回で十分か？ • CaMeL は何をどう防ぐのか？ • サンドボックスや MCP は安全の完成品か？ 注入を完全に検出することはできない前提で、未信頼のデー タが行動に影響する経路を制限する 46 # Page. 47 ![Page Image](https://bcdn.docswell.com/page/2JV4LV2X7Q.jpg) 計画 出力 行動制御 回復 評価 観測・運用 ガードレールには安全性と有用性のトレードオフがある AgentDojo：注入の検出器で攻撃成功は 7.95% に下がったが、良性タスクの有用性も 69.0% → 41.49% AgentDojo・GPT-4o 防御なし 注入の検出器あり 69.0 → 41.49% 良性タスクの有用性 69.0% 41.49% 良性タスクの有用性：防御なし → 検出器あり（誤検知が主因） 攻撃下での有用性 — 21.14% リーダーの視点 攻撃の成功率 — 7.95% — は本資料で確認していない値（論文の表を参照） 防御の評価は「攻撃をどれだけ止めたか」と「普通の仕事 をどれだけ壊したか」を必ず並べる。自社の日本語の依 頼・社内文書・ツール応答で測る 出典: AgentDojo（arXiv:2406.13352、NeurIPS 2024 Datasets and Benchmarks） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 47 # Page. 48 ![Page Image](https://bcdn.docswell.com/page/5EG1XLRRJL.jpg) 計画 出力 行動制御 回復 評価 観測・運用 攻撃の評価は「1 回」では甘い NIST CAISI：新しい攻撃で成功率 11% → 81%。同じ攻撃も 25 回試すと 57% → 80% 攻撃成功率（%） 同じ攻撃を繰り返したときの成功率（%） 100 100 90 81 90 80 80 70 70 60 60 50 50 40 40 30 30 20 57 20 11 10 10 0 0 既存の最強攻撃 80 新しい攻撃 1 回の試行 25 回の試行 条件：AgentDojo の Workspace 環境、Claude 3.5 Sonnet（upgraded）、新しく用意したタスク 攻撃者は何度でも試せる。防御の評価は新しい攻撃と複数回の試行で行い、「攻撃成功率 ○%」には試行回数を添える 出典: NIST CAISI「Technical Blog: Strengthening AI Agent Hijacking Evaluations」（2025-01、2025-12 更新） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 48 # Page. 49 ![Page Image](https://bcdn.docswell.com/page/4JQD8YVY7P.jpg) 計画 出力 行動制御 回復 評価 観測・運用 CaMeL：制御の流れと未信頼のデータを分ける 悪意ある文を検出するのではなく、未信頼のデータが制御の流れや送信先に影響する経路そのものを制限する 信頼できる依頼 計画を作る LLM（特権） メール・文書・ツール応答（未信頼） データを読む LLM（権限なし） インタプリタ：出所と能力を追跡 → 結果は「値」として扱われ、計画や送信先を変えられない 0件 84% → 67〜77% 949 件の攻撃のうち成功した件数（AgentDojo、 Claude 3.5 Sonnet）。次点の防御は 8 件 タスク解決率：防御なし 84% → CaMeL 67%（論 文 v1）／77%（v2） 採用判断 Assess。内容の歪曲・フィッシングは対象 外（論文が明記）、サイドチャネルも残る。後 付けのコストが大きい。発想（未信頼データ で送信先・権限を決めない）は今日から使え る 出典: CaMeL: Defeating Prompt Injections by Design（arXiv:2503.18813、v1 2025-03・v2 2025-06） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 49 # Page. 50 ![Page Image](https://bcdn.docswell.com/page/K74Z2WMZE1.jpg) 計画 出力 行動制御 回復 評価 観測・運用 サンドボックスと MCP は安全の完成品ではない サンドボックスが隔離するのは依頼した処理だけ。MCP 対応は、利用者ごとの認可やツールの安全を意味しない サンドボックス（Inspect の例） MCP セキュリティ指針の 8 項目 • 隔離されるのはサンドボックス経由の処理だけ • Confused Deputy・トークン中継・SSRF • 独自設定で既定のネットワーク遮断が外れる • セッション乗っ取り・ローカルサーバーの侵害 • 特権コンテナ・ホストのデバイス・Docker ソケットを渡すとホストに 届く • OAuth 認可 URL の検証・プロキシでの stdio・スコープ最小化 データ 信頼レベルの例 利用者の依頼（認証済み） 信頼して計画に使う 検索結果・メール・ツールの応答・メモリ 未信頼：送信先・権限・実行命令を決めさせない エージェントが生成したコード・ツール定義 未信頼：サンドボックス、レビュー ログ・採点器・外部通知への転送 データの送信経路として認可の対象 出典: Inspect「Sandboxing」、Model Context Protocol「Security Best Practices」（仕様の現行版は 2026-07-28、指針は 2025-11-25 版で確認） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 50 # Page. 51 ![Page Image](https://bcdn.docswell.com/page/LJ1RMY8DJG.jpg) PART 7 観測性と原因分析 このPartで答えられるようになる問い • トレースがあれば原因が分かるのか？ • 何を記録し、何を記録してはいけないのか？ • LLM に原因分析を任せられるのか？ 版付きのトレースで「何を見て、何をして、何が変わったか」を 残し、原因の特定は検査と再現で絞る 51 # Page. 52 ![Page Image](https://bcdn.docswell.com/page/GJW13GZ8E2.jpg) 計画 出力 行動制御 回復 評価 観測・運用 トレースは「内面の完全な記録」ではない 思考をすべて保存するより、各部品の版と、判断の入力・操作・環境の変化を追う 記録対象 推奨する情報 実行全体 run ID、タスク種別、開始・終了、予算、終了理由 モデル呼び出し モデルとプロンプトの版、観測できる入出力、使用量、拒否・不完全な応答 RAG・メモリ 参照した文書の ID・版・権限、取得時点、利用した箇所 ツール 定義の版、実引数、認可の結果、承認 ID、実行 ID、結果不明の状態 外部状態 変更前後の版、外部のトランザクション ID、事後条件 評価 採点器の版、期待条件、判定と根拠、人による修正 注意 秘密情報・個人情報・認証トークンをトレースに残さない。ログや評価サービスへの転送もデータの送信経路 出典: OpenTelemetry「Semantic conventions for GenAI agent spans」（Development）、元レポート「Trace は内面の完全な記録ではない」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 52 # Page. 53 ![Page Image](https://bcdn.docswell.com/page/4EZPVL19J3.jpg) 計画 出力 行動制御 回復 評価 観測・運用 トレースがあっても、原因の特定は難しい AgentChaosBench：構造化トレースを渡しても、最良のモデルで障害の種類の特定 24.8%、場所の特定 31% 1 位正解率（最有力の候補 1 つが正解だった割 ① 決定的な検 査 合、%） 100 認可・事後条件 ② 状態の差分 前後の版 ③ 再現・対照 実行 1 つずつ変える ④ LLM は仮 説と要約 90 80 70 60 50 執行点を記録する 40 30 31.0 24.8 20 • ガードレールを迂回した実行と正当な実行は、ポリシー判断の証拠がないと区 別しにくい 10 • どの検査を通ったか・認可の結果を残す 0 障害の種類 障害の場所 注意 比較モデルで最良の DeepSeek-v4-pro、ゼロショット。障害の種類は 10 択（当て推量で約 10%）。先に起きたことを原因と決めつけない 出典: AgentChaosBench（arXiv:2608.14680、2026） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 53 # Page. 54 ![Page Image](https://bcdn.docswell.com/page/Y76M5WLDEV.jpg) PART 8 ツール・継続改善・参照設計 ・導入 このPartで答えられるようになる問い • 評価・観測の製品はどう選ぶのか？ • 自己反省やマルチエージェントは信頼性を上げるの か？ • 更新系ツールの直前に何を置くのか？ • リリースの合否は何で決めるのか？ 製品は責務で選び、改善のループにも独立した検証を置き、 評価面・制御面・実行面を分けて段階的に導入する 54 # Page. 55 ![Page Image](https://bcdn.docswell.com/page/G75ZYM18J4.jpg) 計画 出力 行動制御 回復 評価 観測・運用 評価・観測プラットフォームは「責務」で選ぶ 同じデータと採点器を載せなければ、製品間のスコアの差から品質の優劣は言えない 候補 主な役割 注意点 Langfuse データセット、SDK 実験、評価スコア、トレース・費用比較 正解の定義と CI の合否ゲートは利用側で設計 Arize Phoenix エージェントのトレース、データセット、実験、LLM 評価、注釈 合成データや Judge の正しさは別に検証 MLflow トレースを受けるカスタム採点器、エージェント評価、実験記録 期待する軌跡・出力を適切に定義する必要 LangSmith 出力・会話・軌跡の評価テンプレート、共有評価器 評価器の共有変更、スコアの意味を確認 Braintrust 保存・比較できる評価実験、CI/CD からの実行 実験の保存は品質保証やマージ遮断の保証ではない OpenTelemetry エージェント・ワークフロー・ツールの計測規約 Development 段階。版の固定と変換を考える ポイント 選定の確認項目：独自の状態検査器、データセット・採点器の版固定、非同期実行、機密の削除、結果の取り出し、既存 CI との連携 出典: 各製品の公式ドキュメント（Langfuse、Arize Phoenix、MLflow、LangSmith、Braintrust、OpenTelemetry）、元レポート「ツールと技術スタックの責務別マップ」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 55 # Page. 56 ![Page Image](https://bcdn.docswell.com/page/9J2RG91V7R.jpg) 計画 出力 行動制御 回復 評価 観測・運用 テスト・セキュリティ・実行基盤の使い分け 検査ツールは認可の代わりにならず、実行基盤は副作用の冪等性を代わりに解決しない 候補 主な役割 使い分け・注意 Inspect AI ツール・採点器を含む隔離評価環境 実コード・環境を伴う再現可能な評価 Promptfoo 権限不備・注入・RAG やメモリ汚染のレッドチーム CI・定期評価へ。認可の代わりではない。内部情報の送信経路に 注意 AgentDojo 状態付きのツール・注入攻撃の評価環境 防御の有用性と攻撃成功を比較する研究・拡張 LangGraph 状態・永続化・分岐・interrupt での再開 副作用と再実行の設計は残る OpenAI Agents SDK エージェント・ツール・ガードレールの統合 適用範囲を把握して検査を配置 Temporal Activity・履歴・再試行を伴う業務実行 外部副作用の冪等性は必要 OPA・Cedar 主体・対象・条件のポリシー判断 独立した実行ブローカーから全経路で執行 NeMo Guardrails・ AgentCore 複数の検査フロー／ツールへのゲートウェイとポリシー 検出精度と適用漏れを別に評価 出典: Inspect、Promptfoo「Agent red teaming」、AgentDojo、LangGraph、OpenAI Agents SDK、Temporal、OPA・Cedar、NeMo Guardrails、AgentCore の公式 資料 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 56 # Page. 57 ![Page Image](https://bcdn.docswell.com/page/DEYDV4ZQEM.jpg) 計画 出力 行動制御 回復 評価 観測・運用 推奨する最小スタック：最初から積みすぎない 評価・トレース基盤 1 つ、実行モデル 1 つ、共通のツールブローカー、業務の真実を検査するコード、CI の回帰評価 評価・トレース 基盤を 1 つ 独自の採点器と既存運用 に合うもの 実行方式（ワー クフロー基盤） を1つ 共通のツール ブローカー 決定的な処理は通常のコ ード、必要な部分だけエー ジェント 認可・検証・承認・予算・監 査・冪等性を全更新ツール へ 業務の真実を 検査するコード DB・API・成果物・テスト で成功を確認 CI の回帰評価 本番の障害・人の指摘を テストへ戻す リーダーの視点 言語・フレームワークを統一するより、状態・認可・評価の「契約」を先に明確にする。Python のエージェントも TypeScript のサービスも同じ ブローカーを通す 出典: 元レポート「推奨する最小スタック」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 57 # Page. 58 ![Page Image](https://bcdn.docswell.com/page/VJN6MY32J8.jpg) 計画 出力 行動制御 回復 評価 観測・運用 自己反省は検証の代わりにならない 外部の正誤情報なしに自己批評・再回答すると、性能が下がる例がある（CommonSenseQA 75.8 → 38.1） GPT-3.5、外部フィードバックなしの自己修正（正答 修正ループに与えるもの 率 %） 100 • テストの失敗・型エラー 90 80 75.8 75.9 75.1 74.7 • DB の不変条件の違反・規則の違反 • 状態の照合結果 70 60 50 41.8 38.1 40 30 20 10 採用判断 0 「無制限な自己反省」は Hold、「外部フィードバックを使 う修正ループ」は Trial。回数を制限し、同じ失敗の反復 と劣化を記録する 最初の回答 自己修正 1 回 CommonSenseQA 自己修正 2 回 GSM8K 2023 年のモデル・プロンプト・課題での結果。今のすべてのモデルで不可能という意味ではな い 出典: Large Language Models Cannot Self-Correct Reasoning Yet（arXiv:2310.01798、ICLR 2024）、Anthropic「Effective harnesses for long-running agents」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 58 # Page. 59 ![Page Image](https://bcdn.docswell.com/page/YE9LNP9D73.jpg) 計画 出力 行動制御 回復 評価 観測・運用 マルチエージェントは「役割の分離が利益を生む」ときだけ 1,642 トレースの分析で 14 の失敗モード。エージェントを増やせば信頼性が上がるわけではない MAST（7 つの枠組み・1,642 実行の失敗分類） 例 システムの設計 役割・タスク仕様の不備、手順の反復、終了の認識失敗 エージェント間の不整合 情報の取りこぼし、他のエージェントの入力の無視、推論と行 動の不一致 +90.2% の代償に 15 倍 Anthropic の調査用マルチエージェント：社内評価が単一エー ジェント比 +90.2%、トークンは通常チャットの約 15 倍 採用するなら タスクの検証 検証なし、不完全な検証、誤った検証 計画者・実行者・検証者の権限と入力を分け、検証はテスト や状態検査で独立させる 注意 同じモデル・同じ証拠での多数決は、共通原因の誤りを残す。「エージェントを増 やす」より「検証を独立させる」 採用判断 「無制限な多数エージェント化」は Hold 出典: Why Do Multi-Agent LLM Systems Fail?（MAST、arXiv:2503.13657）、Anthropic「How we built our multi-agent research system」（2025-06）、 Cognition「Don’t Build Multi-Agents」（2025-06） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 59 # Page. 60 ![Page Image](https://bcdn.docswell.com/page/GE8XKD95JD.jpg) 計画 出力 行動制御 回復 評価 観測・運用 GEPA と、改善を足す順序 トレースと言葉のフィードバックでプロンプトを進化。強化学習より少ない試行で上回るが、検証の費用は残る 改善を足す順序（元レポートの推奨） +6pt（最大 +19pt） GEPA と強化学習（GRPO）の比較（ICLR 2026、6 タスク）。プ ロンプト最適化の MIPROv2 にも +10pt 超 注意 試行（ロールアウト）の多くは候補の検証に使われる。 未使用のテストで汎化を確認する。論文 v1 の「平均 +10%」は改訂で変わったので最新版の値を使う 1 採点の定義を直す 2 ツールの定義・エラー設計を直す 3 ワークフローの制約を足す 4 プロンプトを最適化する（GEPA 等） 5 必要ならモデルの変更・学習 評価器を攻略する出力や、固定ベンチマークへの適合を、本番品質の向上と混同しない。改善のたびに未使用のホールドアウトで確かめる 出典: GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning（arXiv:2507.19457、ICLR 2026） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 60 # Page. 61 ![Page Image](https://bcdn.docswell.com/page/LEL8ZMW37R.jpg) 計画 出力 行動制御 回復 評価 観測・運用 参照アーキテクチャ：評価面・制御面・実行面を分ける 評価を動かす環境と、本番の操作を実行する環境の認証情報を分ける。モデルの操作案は検証・認可・承認を通る 【評価面】開発・改善ループ：失敗例・人の指摘 → データセット → 評価実行 → リリース判定 → 段階リリース → トレース・状態検査・監査 → 失敗例へ ユーザー → 認証 → タスク契約 分けるもの エージェント／ハーネス（RAG・メモリ・読取ツール） • 評価環境と本番の認証情報 操作案（未信頼） • モデルの判断と実行の許可 • 読み取りツールと更新系ツール 【制御面】検証 → ポリシー → 必要な承認 → 直前の再確認 • 操作の意図・試行・結果の記録 【制御面】副作用ツールのブローカー 【実行面】外部 API・DB・送信・ファイル操作 事後条件の照合・回復 → 引用と実行結果付きの回答 出典: 元レポート「参照アーキテクチャ」（本レポート独自の参照設計） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 61 # Page. 62 ![Page Image](https://bcdn.docswell.com/page/4JM6VY9MEW.jpg) 計画 出力 行動制御 回復 評価 観測・運用 各部品が「保証すること」と「保証しないこと」 どの部品も単独では安全を保証しない。責務の境界を設計レビューの共通言語にする 部品 主に保証・確認するもの 保証しないもの RAG・メモリ 参照情報へのアクセス 計画・操作の正しさ 構造化出力 対応スキーマへの適合 事実・意味・権限 ポリシー判断 入力された認可要求の規則判定 不正な経路からの実行の遮断 ツールブローカー 全操作への執行・監査・予算 業務ポリシー自体の正しさ 永続的なランタイム 状態の保存・再開の仕組み 外部副作用の自動的な 1 回性 採点器・Judge 定義した基準での評価 誤判定ゼロ トレース基盤 観測できるイベント・入出力の記録 全内部推論・真の原因の取得 設計レビューでは右の列を指さし、「これは誰が（どの部品が）補うのか」を 1 行ずつ確認する 出典: 元レポート「参照アーキテクチャ」の責務表 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 62 # Page. 63 ![Page Image](https://bcdn.docswell.com/page/PJRP29GLE9.jpg) 計画 出力 行動制御 回復 評価 観測・運用 更新系ツールの実行ブローカー（TypeScript 風の疑似コード） 認可エラーは拒否、承認は内容のハッシュに結び付け、再試行は同じ意図の ID で、結果不明は再送せず照合する const proposal = proposalSchema.parse(raw); // 構文 const tool = registry.requireAllowedTool(proposal.tool); const target = await tool.readTarget(args, ctx); // 認可された範囲で解決 await tool.validateBusinessPreconditions(args, target, ctx); const decision = await policy.evaluate(trustedRequest(ctx, tool, target, args)); if (decision.errors.length || !decision.allow) throw new Denied(); // fail-closed const digest = canonicalDigest({ principal, tenant, tool, args, targetVersion }); if (decision.requiresApproval) await approvals.requireValidApproval({ digest }); await policy.reauthorize(request); await tool.assertVersion(target.version); const intent = await journal.getOrCreateIntent({ runId, logicalStepId, digest }); try { const r = await tool.execute(args, ctx, { idempotencyKey: intent.id, expectedVersion }); if (!(await tool.verifyPostconditions(args, r, ctx)).passed) return escalate(intent); } catch (e) { if (isPossiblyCommitted(e)) return reconcileOrEscalate(intent); throw e; } 疑似コードを置くだけで TOCTOU（確認と実行の間の競合）や重複更新は解決しない。外部 API の条件付き更新、ロック、予約、事後照合を組み合わせる 出典: 元レポート「更新系ツールの TypeScript 風疑似コード」（完成したライブラリではない） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 63 # Page. 64 ![Page Image](https://bcdn.docswell.com/page/PEX3DQQ6JX.jpg) 計画 出力 行動制御 回復 評価 観測・運用 問題の箇所を切り分ける比較実験 RAG・モデル・ハーネス・評価器を同時に変えると原因が分からない。1 つずつ介入する 条件 固定・変更するもの 切り分けたい問題 正解の証拠を直接入力 RAG を正解の証拠に置換（Oracle Context） 証拠を得た後の読解・判断 正しい計画を与える 計画だけ参照手順に置換 計画の失敗と実行の失敗 ツールをモック化 決定的な応答・状態 外部障害と推論の失敗 実ツール・隔離環境 本番相当の API 契約 認可・副作用・回復 制御あり／なし ポリシー・承認・検証を個別に追加 有用性・安全性・費用の差 同じモデル・別ハーネス モデルとデータを固定 実行ループ・ツール設計の効果 同じハーネス・別モデル 実行方式を固定 モデル変更の効果 Shadow 試験（本番の入力で並走させ、結果は使わない試験）でも、更新系は実行を止めるブローカーを必須にする 出典: 元レポート「問題箇所を切り分ける比較実験」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 64 # Page. 65 ![Page Image](https://bcdn.docswell.com/page/3EKYX99GJD.jpg) 計画 出力 行動制御 回復 評価 観測・運用 リリースゲート：品質の向上と安全の非劣化を別条件に 基準は重大度に応じて各社で決める。6 観点を別々に判定し、品質が上がっても安全が悪化したら出さない 品質 タスク成功・回答正確性・重要カテゴリの劣化・ 一貫性 安全 権限外・未承認・機密送信・禁止経路：試験で 0 件、かつ実行時に遮断 評価器 Judge・参照解・採点コードの版固定、重要ケー スは人手 回復 タイムアウト・再開・再送で重複なし、結果不明で 停止 運用 費用・遅延（p95＝遅い方 5% を除いた最大）・ ツール回数・承認負荷・監査ログ 展開 限定トラフィック・監視・ロールバックで段階的に 「成功率が上がったから出す」ではなく「品質が上がり、かつ安全の各項目が悪化していないから出す」 出典: 元レポート「推奨するリリースゲート」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 65 # Page. 66 ![Page Image](https://bcdn.docswell.com/page/L7395WW575.jpg) 計画 出力 行動制御 回復 評価 観測・運用 評価で危険な操作が 0 件でも、危険率 0 の証明ではない n 件すべて無事故でも、危険率は最大でおよそ 3/n まであり得る（95% 信頼、3 の法則） 無事故だった試行数 n 危険率の上限（95%、正確な 3 の法則（3/n） 値） 10 25.9% 30% 30 9.5% 10% 100 2.95% 3% 300 0.99% 1% 注意 独立・同一分布の仮定での値。相関や分布の 変化があると、真の危険率は表の上限を超 え得る。正確な式は 1 − 0.05^(1/n) リーダーの視点 「危険率 1% 未満」と言うには、独立した約 300 件で 0 件が要る。だから試験と、実行時の制約（認可・承認・ブローカー）の両方を置く 出典: 元レポート「推奨するリリースゲート」、二項分布の正確な信頼上限（本資料で計算） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 66 # Page. 67 ![Page Image](https://bcdn.docswell.com/page/87DGDKKY7G.jpg) 計画 出力 行動制御 回復 評価 観測・運用 段階的ロードマップ：ゲート条件で次に進む 時間軸ではなく「何ができるようになったら次へ進むか」で区切る 段階 作るもの 完了条件（ゲート） 1. 契約・基準 成功条件、禁止操作、重要な失敗例、正解確認の手順 何をもって成功かを、人とコードで説明できる 2. 可視化・回帰 トレース基盤 1 つ、版固定のデータセット、独自の採点器 失敗を再現し、変更前後を比較できる 3. 実行境界 ツールブローカー、認可、構造検証、必要な承認 モデルが誤提案しても禁止操作を止められる 4. 回復・一貫性 冪等性、永続化、状態照合、複数試行 再試行・再開で二重更新や虚偽の完了がない 5. 敵対・障害評価 注入、権限失効、タイムアウト、部分成功 有用性を残して安全性・回復を測れる 6. 最適化 プロンプト、ツール設計、エージェント分割、GEPA 等 未使用の評価で便益を再確認できる 7. 継続運用 本番の抽出、人手較正、障害から回帰例へ戻す仕組み 分布・モデル・規則の変化に対応できる 出典: 元レポート「段階的ロードマップ」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 67 # Page. 68 ![Page Image](https://bcdn.docswell.com/page/VJP3XKK2E8.jpg) 計画 出力 行動制御 回復 評価 観測・運用 定量エビデンス台帳 指標と条件を残した抜粋。行をまたいだ数値の大小は、製品やモデルの総合順位ではない 研究 条件・指標 報告結果 判断上の限界 τ-bench GPT-4o 関数呼び出し、小売 pass^1 61.2%、pass^8 25% 未満 当時のモデル・模擬ユーザー τ²-bench gpt-4.1、通信・小売・航空、pass^1 34%・74%・56% ドメイン差をモデル優劣にしない MT-Bench Judge 算数 10 問×順序 2、GPT-4 誤判定 14/20 → 参照解で 3/20 小規模。誤りはゼロにならない Agent-as-a-Judge DevAI、OpenHands の成果物 人との一致 60.38% → 90.44% black-box 設定。安全性の指標ではない AgentSpec SafeAgentBench、安全タスク成功率 58.62% → 54.26% 手書き規則。有用性が低下 AgentDojo GPT-4o、良性タスクの有用性 69.0% → 41.49%（検出器） 攻撃成功 7.95% と並べて読む CaMeL Claude 3.5 Sonnet、AgentDojo 949 攻撃で成功 0 非目標・サイドチャネルは残る AlphaEval 94 タスク、同じ Opus 4.6 Claude Code 64.41／Codex 53.45 ハーネス等の複合差 TraceTrial-Bench 4 ハーネス×9 モデル×95 タスク 成功かつ基準未達 31.1% 反復なし。採点の妥当性未検証 AgentChaosBench 注入障害、DeepSeek-v4-pro 種類 24.8%、場所 31%（1 位正解率） 合成障害・ゼロショット BFCL 監査 層化抽出 50 問 24 問に欠陥 全体の誤採点率ではない 出典: 元レポート「定量エビデンス台帳」（各一次資料で再確認済み） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 68 # Page. 69 ![Page Image](https://bcdn.docswell.com/page/2EV4LVVXJQ.jpg) PART 9 テックリーダーの実践 このPartで答えられるようになる問い • エージェントの SLO は何を測ればよいのか？ • 止めるとき（キルスイッチ）はどう設計するのか？ • 費用はどう見積もり、どう抑えるのか？ • 評価は何件あれば「改善した」と言えるのか？ SLO・コスト・体制・評価データ・統計・規制を押さえ、エージェ ントのプロジェクトを持続的に運用する 69 # Page. 70 ![Page Image](https://bcdn.docswell.com/page/57G1XLLREL.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 エージェントの SLI・SLO の例 SLI＝測る指標、SLO＝その目標。業界標準の目標値はなく、自社のベースラインから締める SLI（例） 定義 扱い タスク成功率 状態検査で判定した成功の割合 SLO（例：30 日で 95%、ベースラインから締める） 虚偽の完了率（本資料の提案） 「完了」と報告したのに状態検査で不成立 SLO。自己申告で成功を数えない エスカレーション率 人へ引き継いだ割合 低すぎても危険（引き継ぐべき案件を抱え込む） 未許可の操作の件数 認可・承認を通らない更新 SLO ではない。実行時に強制してゼロ p95 のエンドツーエンド遅延 依頼から完了まで SLO 成功 1 件あたりの費用 失敗・再試行を含む総費用 ÷ 成功数 予算アラート 数値はすべて例。Grafana の 95%／30 日も「候補」で推奨ではない。自社のベースラインを測ってから決める 出典: Grafana「What if your agent’s hallucinations had a budget?」（InfoQ 2026-10 で紹介）、Google SRE Workbook「Implementing SLOs」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 70 # Page. 71 ![Page Image](https://bcdn.docswell.com/page/4EQD8YYYJP.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 エラーバジェットとキルスイッチ：止め方を先に決める バジェットが残れば変更を試し、使い切ったら信頼性の修正を優先。事故時は更新系ツールを止めて読み取り専用へ 検知 SLI のアラート 封じ込め 更新系を停止・読取専用 へ 保全 照合 復旧 事後レビュー トレースと状態 外部の状態 ロールバック 評価セットへ追加 エラーバジェット キルスイッチ（事前に用意） • 残っている：プロンプト・モデルの変更を試せる • 更新系ツールだけを即時に止められる • 使い切った：信頼性の修正を優先 • 読み取り専用モードへの切り替え • モデル・プロンプトの変更で母集団が変わる → 測り直す • 失敗の閾値・高リスク操作で人へ引き継ぐ 補足（元レポート外の一般知識） Replit（2025-07）：本番 DB 削除の後、開発・本番 DB の分離を既定化し、チェックポイントとロールバックを提供 出典: Google SRE Workbook「Implementing SLOs」、OpenAI「A practical guide to building agents」、Replit「Doubling down on our commitment to secure vibe coding」（2025-07） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 71 # Page. 72 ![Page Image](https://bcdn.docswell.com/page/KJ4Z2WWZ71.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 コスト管理：トークン・ループ・キャッシュ エージェントはチャットの約 4 倍、マルチエージェントは約 15 倍のトークンを使う（Anthropic の社内測定） トークン消費（チャット＝1、Anthropic 社内） 15倍 16 抑える手段 14 • ループ・ツール回数・トークン・金額のハード上限（max_turns 等） 12 • 単純な質問はエージェントに回さない（振り分け） 10 • プロンプトキャッシュ：読み出し 0.1 倍、書き込み 1.25〜2 倍（Claude、 2026-11 時点） 8 • ツールの応答を簡潔版にする 6 • 成功 1 件あたりの費用で見る（失敗・再試行を含む） 4倍 4 2 1倍 0 チャット エージェント マルチエージェント 注意 Web 調査の評価（BrowseComp）では、スコアの差の約 80% をトークン量で説明できた（Anthropic）。性能を上げる手段の多くは費用を 払う手段 出典: Anthropic「How we built our multi-agent research system」（2025-06）、Anthropic「Prompt caching」ドキュメント（2026-11 取得）、OpenAI Agents SDK（ max_turns）、Microsoft CAF AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 72 # Page. 73 ![Page Image](https://bcdn.docswell.com/page/LE1RMYYDEG.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 体制：誰が何に責任を持つか 「エージェントは技術的な問題より、不明確なオーナーシップで失敗することが多い」（Microsoft CAF） 役割 主な責任 業務オーナー 成果と、残るリスクを引き受ける。成功条件と禁止操作を決める リスク・コンプライアンス 基準を決め、高リスク案件をレビューする プラットフォームチーム 基盤・ツールブローカー・ガードレール・観測性・ID を共通で提供し、監査・強制する ワークロード（業務）チーム 承認された環境でエージェントを開発・運用し、自分の評価セットを持つ 個人ビルダー 業務上重要になったら正式なオーナーを割り当てる リーダーの視点 予算をつける時点で、ベースライン・パイロットとスケールのゲート・中止条件（例：90 日で処理時間を ○% 削減できなければ止める）を合意す る 出典: Microsoft Cloud Adoption Framework「Organizational readiness for AI agents」（2026-11 更新） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 73 # Page. 74 ![Page Image](https://bcdn.docswell.com/page/GEW13GG872.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 評価データの作り方：実際の失敗 20〜50 件から始める 早く始め、手作業の確認とユーザーの報告をタスクにし、結果を採点し、トランスクリプトを読む 実際の失敗・手作業の確 認 20〜50 件から 曖昧さのないタスク 起きるべき／べきでない 結果を採点 専門家 2 人の合否が一致 両方を入れる 決定的な採点器 能力の評価 → 回帰の評価 トランスクリプトを読む 採点器を疑う • 能力の評価は低い合格率から • 多数の試行で 0% ならタスクの不具合を疑う • 合格率が上がったら回帰の評価へ「卒業」 • 採点器の不具合で 42% → 修正後 約 95% の例（Anthropic） • 回帰の評価はほぼ 100% を保つ 評価セットには必ずオーナーを置き、誰でも失敗例を追加できる経路を作る。本番の障害・人の指摘は 1 週間以内に回帰テストへ 出典: Anthropic「Demystifying evals for AI agents」（2026-01-09） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 74 # Page. 75 ![Page Image](https://bcdn.docswell.com/page/47ZPVLL9E3.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 評価の統計：20 件では 90% と 70% を区別できない 18/20（90%）の 95% 信頼区間は [69.9%, 97.2%]。小さな改善の証明には数百件が要る 結果 成功率 95% 信頼区間（Wilson） 検出したい差 必要な件数（各群） 18 / 20 90% 69.9% 〜 97.2% 90% → 95% 約 435 45 / 50 90% 78.6% 〜 95.7% 70% → 80% 約 294 90 / 100 90% 82.6% 〜 94.5% 独立 2 群、有意水準 5%・検出力 80%。対応のある設計や反復試行で減らせる 同じタスクで新旧を比べる（McNemar の検定） 判定に効くのは結果が食い違ったタスクだけ。100 タスクで「旧だけ成功 2・新だけ成功 9」でも両側 p ≈ 0.065（5% 水準で有意でない） 「20〜50 件は始めるためのもの。小さな改善の証明には足りない」と言い切る。改善を主張するときは信頼区間を添える 出典: Wilson スコア区間・McNemar 検定・検出力計算（本資料で計算）、Anthropic「A statistical approach to model evaluations」（2024-11、arXiv:2411.00640） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 75 # Page. 76 ![Page Image](https://bcdn.docswell.com/page/YJ6M5WWD7V.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 エージェントにするか、ワークフローやコードにするか 上から順に判定し、右に当たらなければ次の問いへ。取り消せない操作があるとエージェントの適性は下がる 手順は決まっているか？ はい → コード・ワークフロー 判断・非構造データ・保守しにくいルールが要るか？ いいえ（定型の要約・分類程度）→ 1 回の LLM＋検索 誤った行動は取り消せるか？ いいえ → 人の承認必須・ワークフロー 評価・認可・回復の仕組みは成熟しているか？ いいえ → 読み取り専用から始める ここまで来た（判断が要り、取り消せ、仕組みも成熟） エージェント（ハード上限と監視付き） OpenAI：まず単一エージェントの能力を最大化し、必要なときだけマルチエージェントへ 出典: Anthropic「Building effective agents」、OpenAI「A practical guide to building agents」、Microsoft Cloud Adoption Framework「AI agents」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 76 # Page. 77 ![Page Image](https://bcdn.docswell.com/page/GJ5ZYMM8E4.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 規制・標準の現況（2026 年 11 月時点） 日本の AI 事業者ガイドラインはエージェントを定義に追加。EU AI Act の高リスク義務は 2027-12 へ延期 名称 日付・状態 エージェントへの含意 OWASP Agentic Top 10 2025-12-09 公開 目標の乗っ取り・ツール悪用・ID と権限の悪用・メモリ汚染など 10 項目 OWASP LLM06 Excessive Agency 2025 版 過剰な機能・権限・自律。認可は LLM でなく下流のシステムで NIST AI Agent Standards Initiative 2026-02-17 発表 相互運用・セキュリティ・エージェントの ID と認可 AI 事業者ガイドライン 第 1.2 版 2026-03-31 エージェントの定義を追加。自社サービスに組み込むと「AI 提供者」の義務も負う AISI Japan 評価観点ガイド 第 1.20 版 2026-07-07 外部環境との相互作用・自律的な挙動の観点を新設 EU AI Act（Reg. 2026/1744 で改正） 2026-07-27 発効 透明性 2026-08。採用・与信などの高リスク用途（附属書 III）は 2027-12 へ延 期 ISO/IEC 42001 2023-12 AI マネジメントシステムの認証規格 「ガイドラインで人の関与・キルスイッチが必須化」という解説は一次資料で確認できない。原文で確認してから引用する 出典: OWASP Top 10 for Agentic Applications 2026、OWASP LLM06:2025、NIST CAISI、AI 事業者ガイドライン 第 1.2 版、AISI Japan 評価観点ガイド 第 1.20 版、 EU Regulation 2026/1744（Digital Omnibus）、ISO/IEC 42001 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 77 # Page. 78 ![Page Image](https://bcdn.docswell.com/page/LE395WWGE5.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 最初の 90 日プラン（目安） 最初の 30 日で「成功と禁止を定義し、測れる」状態を作る。高度化はその後 Day 1–30 Day 31–60 Day 61–90 定義して測る 実行の境界を作る 敵対・回復を測って出す • 成功条件・禁止操作・重要な失敗例を業務 オーナーと決める • ツールブローカー：認可・検証・承認・冪等性 • 注入・権限失効・タイムアウトの評価 • 複数試行と pass^k • リリースゲートの合意 • 実際の失敗から評価 20〜50 件 • 虚偽の完了の検出 • 限定トラフィックで段階リリース • トレース基盤を 1 つ • キルスイッチとランブック • 障害 → 回帰テストの仕組み • 本番の書き込み権限を外す・ループ上限 最初の報告は「成功率」ではなく「失敗の内訳と、止められる操作・止められない操作の一覧」にする 出典: 本資料の補足（元レポートのロードマップと、Anthropic・Microsoft CAF の推奨を 90 日に配置） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 78 # Page. 79 ![Page Image](https://bcdn.docswell.com/page/8EDGDKKNEG.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 「エージェントの精度は何%？」にどう答えるか 1 つの数字で答えない。成功・安全・一貫性・費用を分け、条件と信頼区間を添える ✕「精度は 88% です」 ○ こう答える 成功 重要な 50 タスクで、状態検査で判定した成功率 88%（95% 信頼区間 約 76〜94%） 一貫性 同じタスクを 4 回続けて全部成功する割合（pass^4）は 70% 安全 権限外の操作は 0 件。これは試験の結果ではなく、実行時に止める仕組みで保証 費用 成功 1 件あたり約 ○ 円（失敗・再試行を含む） 次の手 失敗の内訳は証拠不足 4 割・手順の飛ばし 3 割。次の 1 か月で手順の検査を足す ※ 数値は説明用の例 出典: 本資料の補足（Part 1〜3、Part 9 の内容の応用） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 79 # Page. 80 ![Page Image](https://bcdn.docswell.com/page/V7P3XKKNJ8.jpg) PART 10 アンチパターン大全と、乗 り越えた事例 このPartで答えられるようになる問い • 公開された事故は、どの層が欠けて起きたのか？ • 「指示（プロンプト）」はなぜ制御にならないのか？ • 信頼性を上げた企業は何をしているのか？ • 全社のエージェント基盤は何を共通化するのか？ 公開された事故を失敗の層に当てはめ、評価・設計・権限・注 入・運用のアンチパターンと、信頼性を上げた運用の型を学ぶ 80 # Page. 81 ![Page Image](https://bcdn.docswell.com/page/2JV4LVVY7Q.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 失敗の 6 つの層と、公開された事故の地図 多くの事故は複数の層が同時に欠けて起きる。最も多いのは「権限」と「注入」の組み合わせ 事故（時期） 判断 権限 副作用 回復 注入 Replit：本番 DB の削除（2025-07） ○ ○ ○ Railway＋コーディングエージェント：ボリューム削除（2026-04） ○ ○ ○ Cursor サポート AI：存在しない規約（2025-04） GitHub MCP：私有リポジトリの漏洩（2025-05）† 評価 ○ ○ ○ ○ M365 Copilot「EchoLeak」（2025-06）† ○ ○ Agentforce「ForcedLeak」（2025-09）† ○ ○ ○ ○ Gemini CLI・Antigravity：許可リストの回避（2025）† ○ Supabase MCP：強い権限での漏洩（2025-07）† ○ ○ Amazon Q 拡張・Nx：CI の権限と供給網（2025） ○ ○ ○＝その層の対策が欠けていた。列の 6 層は事故分析用の分類で、上部の工程表示とは別。†＝研究者による実証の開示（実被害の報告ではない） 出典: 当事者の発表・研究者の開示（Replit、Railway、Cursor、AWS Security Bulletin、Invariant Labs、Microsoft／CVE、Noma Security、Tracebit、PromptArmor、 Supabase、Asana、Nx、Anthropic） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 81 # Page. 82 ![Page Image](https://bcdn.docswell.com/page/5EG1XLLWJL.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 事故①：「指示」は制御にならない（権限・副作用・回復） コードフリーズ中の本番 DB 削除、アカウント全体に効くトークンでのボリューム削除。対策はどちらも構造的なもの Replit（2025-07） Railway（2026-04） • コードフリーズ中に本番 DB を削除 • 手元にあったアカウント全体に効く長期トークンでボリューム削除 • 「戻せない」と誤って報告（実際は復元できた） • 本番ボリュームが即時に消え、バックアップも見えなくなった • 対策：開発・本番 DB の分離を既定化、チェックポイントとロールバ ック • 対策：API 経由の削除も 48 時間のソフトデリートへ リーダーの視点 「本番は触らないで」はプロンプトに書くものではなく、権限で表すもの。エージェントの手元に本番の書き込み権限・長期トークンを置 かない 出典: Replit「Doubling down on our commitment to secure vibe coding」（2025-07）、Railway Blog「Your AI wants to nuke your database」・Changelog（ 2026-05-01） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 82 # Page. 83 ![Page Image](https://bcdn.docswell.com/page/4JQD8YYQ7P.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 事故②：AI の発言は会社の発言になる（判断・評価） サポート AI が存在しない規約を答えて解約者が出た。「チャットボットは別の主体」という主張は裁判で退けられた Cursor のサポート AI（2025-04） Air Canada（2024-02、参考） • 存在しない「1 サブスク 1 デバイス」規約を回答 • チャットボットが誤った割引規定を案内 • 解約するユーザーが出た • 「チャットボットは別の主体」の主張は退けられた • 対策：AI の回答に AI であることを明示 • ※ 判決文は未取得。法律事務所の解説による リーダーの視点 規約・価格・返金のような「約束」に関わる回答は、根拠文書への引用を必須にし、根拠がなければ答えずに人へ引き継ぐ 出典: Cursor 共同創業者の Hacker News コメント（2025-04）、The Register（2025-04-18）、Moffatt v. Air Canada, 2024 BCCRT 149（判決文は未取得、法律事務所 の解説による） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 83 # Page. 84 ![Page Image](https://bcdn.docswell.com/page/K74Z2WWYE1.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 事故③：読むだけで漏れる（注入×外部送信） メール 1 通、Web フォーム 1 件、公開 Issue 1 件で、機密を外へ送れることが実証された（研究者の開示） EchoLeak（2025-06） M365 Copilot。メール 1 通でクリック不 要の持ち出し。注入の検知と画像の送信先 の制限を組み合わせて回避。深刻度 9.3／ 10 ForcedLeak（2025-09） GitHub MCP（2025-05） Agentforce。Web フォーム経由の注入 で顧客データを持ち出し。許可リストの期限 切れドメインを $5 で取得。深刻度 9.4／ 10 公開 Issue の注入で、私有リポジトリの情 報を公開のプルリクエストに書き出させた。 「サーバー側の修正だけでは直らない」 注意 検知（分類器）は回避される前提で設計する。送信先の許可リスト、私的データと外部送信の分離を構造で行う 出典: EchoLeak（CVE-2025-32711、arXiv:2509.10540）、Noma Security「ForcedLeak」（2025-09）、Invariant Labs「GitHub MCP vulnerability」（2025-05） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 84 # Page. 85 ![Page Image](https://bcdn.docswell.com/page/LJ1RMYYNJG.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 事故④：開発ツールと供給網も攻撃面になる 許可リストの回避、拒否されたら別のコマンドで迂回、CI の過剰な権限から悪性コードの混入 事故 何が起きたか 欠けていた構造 Gemini CLI（2025-07） README の注入。grep で始まるコマンドが許可済みだったため、後ろ に続く任意のコマンドも通り、環境変数を送信 コマンドの許可は先頭の一致でなく、完全な引数で Antigravity（2025-11） 読み取りツールに拒否されると cat で迂回し、許可リストのサイトへ送信 拒否された対象への迂回の検査、送信先の制限 Amazon Q 拡張（2025-07） CI の過剰な権限のトークンで、悪性コードが混入したままリリース CI の最小権限、リリースの検証 Nx（2025-08） CI への注入で npm トークンを奪われ、悪性版が開発者の AI CLI で 秘密を探索 外部 PR の CI 実行の承認、長期トークン不要の公開 方式（Trusted Publishing） Supabase MCP（2025-07） 強い権限で動作し、チケット経由の注入でトークン漏洩 読み取り専用・プロジェクト単位の権限 リーダーの視点 ベンダーも注入を完全には防げない（Supabase は対策を「リスクを減らすが除去はしない」と明記）。前提にして、構造で影響を限る 出典: Tracebit（Gemini CLI、2025-07）、PromptArmor（Google Antigravity、2025-11）、AWS Security Bulletin AWS-2025-015（Amazon Q Developer 拡張）、 Nx「s1ngularity postmortem」（2025-08）、Supabase「Defense in depth for MCP」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 85 # Page. 86 ![Page Image](https://bcdn.docswell.com/page/GJW13G1ME2.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 Lethal trifecta：3 つがそろうと「読むだけで漏れる」 私的なデータへのアクセス・未信頼のコンテンツ・外部への送信。どれか 1 つ（多くは外部送信）を構造的に断つ 私的なデータへのアクセス メール・社内文書・DB・秘密情報 未信頼のコンテンツ Web・メール・Issue・チケット・ツール応答 外部への送信 HTTP・メール・PR・画像の URL・通知 3 つがそろうと、未信頼のコンテンツの指示に従って私的なデータが外に出る どれか 1 つを構造的に断つ（多くは外部送信） • 送信先を許可リストに限る（期限切れのドメインも棚卸し） • 私的なデータを読んだセッションでは外部送信のツールを外す • 外部送信は人の承認にする • 未信頼のデータで送信先・権限を決めさせない（CaMeL の発想） 出典: Simon Willison「The lethal trifecta for AI agents」（2025-06-16）、事故③④の各資料 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 86 # Page. 87 ![Page Image](https://bcdn.docswell.com/page/4EZPVLPMJ3.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 アンチパターン①：評価と設計 「デモで 1 回成功」「完了しましたで判定」「ツールとエージェントを増やす」が最も多い アンチパターン なぜ失敗するか（根拠） 代わりにどうするか デモで 1 回成功＝本番品質 pass^1 61% でも pass^8 は 25% 未満（τ-bench） 複数試行と pass^k 「完了しました」で判定（Hold） 発話と状態は別。採点器の不具合で 42% → 修正後 約 95% の例 最終状態で採点し、採点器も点検 人で較正しない LLM 採点器 Shopify：人との一致 κ 0.02 → 較正後 0.61（人同士 0.69） 人のラベルとの一致を定期的に測る 評価セットの汚染・攻略を見逃す 解答の漏れ・採点コードの改変でスコアだけ膨らむ 非公開の自前タスク、採点コードを書き込めない構成 ツールを増やしすぎる ツールを絞ると選択精度 13.62% → 43.13%（RAG-MCP） 統合・名前空間化、必要なものだけ渡す マルチエージェントの過剰導入 文脈の断片化・判断の衝突（Cognition、MAST） まず単一エージェントかワークフロー 決まった手順まで LLM に任せる 遅く・高く・予測しにくい 決まった手順はコード、判断だけ LLM 出典: τ-bench、Anthropic「Demystifying evals」「Writing effective tools for agents」「Building effective agents」、MAST、Epoch AI（BFCL 監査）、Shopify Engineering（2025-08）、Cognition（2025-06）、RAG-MCP（arXiv:2505.03275）、SWE-Bench+ AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 87 # Page. 88 ![Page Image](https://bcdn.docswell.com/page/Y76M5WM5EV.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 アンチパターン②：権限・承認・注入・運用 「本番の書き込み権限を直接渡す」「承認を出しすぎて形だけになる」「プロンプトで権限を制御する」 アンチパターン なぜ失敗するか（根拠） 代わりにどうするか 本番の書き込み権限を直接渡す 指示は制御にならない（Replit、Railway） 開発・本番の分離、既定は読取専用、短命トークン 承認の出しすぎ（承認疲れ） 手動承認の 93% がそのまま承認されていた（Anthropic の報 告） サンドボックスで閉じ込め、高リスクだけ確認（Claude Code の権限確認 −84%） プロンプトで権限を制御 プロンプトは漏れ、境界にならない（OWASP LLM07） 権限の判定は LLM の外、秘密はプロンプトに入れない MCP サーバーを審査せず導入 ツール説明への悪意ある指示、承認後の書き換え 許可リスト、版とツール定義のハッシュを固定 共有サービスアカウントで動かす 誰の権限で何をしたか追えない エージェントごとの ID と責任者、委任トークン コスト暴走・無限ループ 手順の反復・終了認識の失敗（MAST） 回数・トークン・金額のハード上限 ログに機密を残す プロンプトや出力に個人情報が入る 既定はメタデータのみ（OTel も内容は opt-in） モデル更新を観測なしで出す オフライン評価をすり抜ける回帰（OpenAI 2025-05） 版固定・段階リリース・即時ロールバック 出典: OWASP LLM06・LLM07:2025、Anthropic「Claude Code sandboxing」（2025-10）、MCP 仕様、Invariant Labs（tool poisoning）、OpenTelemetry GenAI 規 約、OpenAI「Sycophancy in GPT-4o」（2025-05）、Anthropic のポストモーテム（2025-09） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 88 # Page. 89 ![Page Image](https://bcdn.docswell.com/page/G75ZYMZGJ4.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 元レポートの Hold 4 項目と、現実の事故・報告の対応 Hold（元レポートの採用レーダーで「標準では避ける」判定）は机上の注意ではない。事故や報告で裏付けられている Hold（元レポート） 対応する事故・報告 モデルの自己申告だけで成功・安全を判定 Replit の「戻せない」という誤報告、採点器の不具合で 42% → 修正後 約 95%（Anthropic） 出力ガードレールを副作用防止の代わりにする ガードレールの検査の前にツールが動き得る（OpenAI Agents SDK の既定は並行実行）。出力 の検査では実行済みの操作を戻せない 無制限な自己反省・多数エージェント化 自己修正で CommonSenseQA 75.8 → 38.1、MAST の 14 の失敗モード、Cognition の 主張 公開ランキングや単一 Judge のみで本番採用 BFCL 監査で 50 問中 24 問に欠陥、SWE-bench Verified の監査で 59.4% に重大な問題 リーダーの視点 設計レビューで Hold の項目を見つけたら、この表の事故を例に挙げて説明すると合意を得やすい 出典: 元レポート「Technology Radar」（Hold）、本 Part の事故・報告 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 89 # Page. 90 ![Page Image](https://bcdn.docswell.com/page/9J2RG9RD7R.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 乗り越えた事例①：評価を先に作る 少数の実クエリから評価を始め、採点器を人と突き合わせ、一貫性を pass^k で測る（数値は各社の自己申告） 企業（対象） 仕組み 報告された数値（自己申告） Anthropic（調査用マルチエージェント） 約 20 件の実クエリで評価を開始、LLM 採点と人手を併用、新旧を 並行稼働 ツール説明の書き直しでタスク時間 −40% Shopify（Sidekick） 3 人以上の専門家のラベル、採点器を人との一致で較正、ユーザーシ ミュレーター 採点器と人の一致 κ 0.02 → 0.61（人同士 0.69）。κ＝偶然を除いた一致度、1 で完全一 致 Sierra（τ-bench） 模擬ユーザー＋業務ポリシー、最終 DB 状態で採点、pass^k pass^1 61% → pass^8 は 25% 未満（ 2024 年のモデル） Intercom（Fin） 人へ引き継いだ会話は「解決」に数えない、改善サイクル 解決率 51%（2024）→ 76%（2026-03） 「解決」の定義は企業ごとに違う（人への引き継ぎを含むか等）。他社の解決率と比べない 出典: Anthropic「How we built our multi-agent research system」（2025-06）、Shopify Engineering「Building production-ready agentic systems」（202508）、Sierra「Benchmarking AI agents」（2024-06）、Intercom（Fin） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 90 # Page. 91 ![Page Image](https://bcdn.docswell.com/page/DEYDV4DMEM.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 乗り越えた事例②：閉じ込めてから自律させる 隔離した環境で確認なしに動かし、成果物を人がレビュー。承認の数より閉じ込める範囲を設計する 企業（対象） 閉じ込め方 報告された数値（自己申告） Stripe（Minions） 本番・外部通信から隔離した開発環境、厳選したツール、CI は 2 回まで、全 人のコードを含まない PR を週 1,300 件超 PR を人がレビュー マージ Spotify（バックグラウンド） push 権限なしのコンテナ、ビルド・テストを強制、LLM 採点器が却下 採点器が約 1/4 のセッションを却下 Anthropic（Claude Code） OS レベルのサンドボックス：作業ディレクトリ外は書込不可、通信先を制限 権限の確認 −84%（社内利用、基準値は未開 示） メルカリ（決済の障害調査） セッションごとのコンテナ、短命・最小権限のトークン、強制は決定的な層で 数値は未公開 リーダーの視点 「承認を何回挟むか」より「どこまで閉じ込めれば確認なしで動かせるか」を設計する。指示ファイルは誘導、強制は決定的な層 出典: Stripe Dev Blog「Minions」（2026-02）、Spotify Engineering「Background coding agents」（2025-12）、Anthropic「Claude Code sandboxing」（2025-10 ）、メルカリ Engineering Blog（2026-06） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 91 # Page. 92 ![Page Image](https://bcdn.docswell.com/page/VJN6MY63J8.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 乗り越えた事例③：機械で確かめ、人の注意を絞る 機械で確かめられるものは機械で。残りは LLM で絞り、怪しいものだけ人へ（数値は自己申告） 企業（対象） 検証の挟み方 報告された数値（自己申告） Airbnb（テスト移行） refactor → テスト → lint → 型の各段で検証と再試行、残りは人 見積 1.5 年 → 6 週間、4 日で 97% Uber（uReview） 生成 → 採点 → 検証 → 重複除去 週約 6.5 万差分の 90% 超、有用コメント 75% OpenAI（Codex レビュー） コード実行の権限、精度優先で重大な指摘だけ コメントの 52.7% で作者が修正 freee（記帳の検証） 別の LLM が自信度を評価し、怪しいものだけ人が確認 確認対象 約 2 割、確認時間 −80% DoorDash（配達員サポート） 安い類似度チェック → 疑わしいときだけ LLM の 2 段 ハルシネーション −90%（基準値未開示） 共通点：LLM の出力をそのまま信じず、機械で確かめられることは機械で確かめ、人の注意を「怪しいものだけ」に集中させる 出典: Airbnb Tech Blog（2025-03）、Uber Engineering「uReview」（2025-08）、OpenAI Alignment「Scaling code verification」（2025-12）、AWS ブログ（freee） 、DoorDash Engineering（2024-09） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 92 # Page. 93 ![Page Image](https://bcdn.docswell.com/page/YE9LNPLP73.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 教訓の事例：指標の定義を誤ると揺り戻す Klarna は「700 人分」を発表した 1 年後、品質低下を認めて人の採用に戻した。指標の定義が成否を左右する 2024-02 初月 230 万会話、700 人分と発表 2025-05 CEO が品質低下を認め、人の採用に戻す（ 報道） 「解決」の定義を確かめる • 人への引き継ぎを含むか • 再問い合わせをどう数えるか • 顧客満足と並べているか ポイント Salesforce の自社ヘルプ（自己申告、低下理由は非公開）：6 か月で解決率 84%・ 引き継ぎ 4% → 2026-06 の発表では 430 万件中 70% 解決（低下の理由は未 記載） リーダーの視点 件数や解決率の 1 つの数字で成功を宣言しない。品質（状態検査・顧客満足・再問い合わせ）と費用を並べ、定義を明記して報告する 出典: Klarna プレスリリース（2024-02）、Bloomberg（2025-05、CEO インタビュー）、Salesforce News（Agentforce の自社ヘルプ） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 93 # Page. 94 ![Page Image](https://bcdn.docswell.com/page/GE8XKDXXJD.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 国内の事例 国内でも「強制は決定的な層で」「評価を基盤に」「自信度で人の確認を絞る」が共通している（自己申告） 企業（対象） 仕組み 報告された数値（自己申告） メルカリ（決済の障害調査） セッションごとのコンテナ、ACL と短命・最小権限トークン。指示は誘導、強 制は決定的な層 未公開 LayerX（バクラク） Langfuse で評価・実験、確信度の高いものだけ自動で一次承認 DSPy で正解率 87.94% → 92.96% Ubie（セキュリティアラート分析） 分析用ツールのみ、システムを変更できない 数十分の情報収集が数分に freee（記帳の検証） 別の LLM が自信度を評価、怪しいものだけ人 確認対象 約 2 割、確認時間 −80% マネーフォワード（リース識別） 同じ入力を 3 回実行して比較。正解率はカテゴリ別に報告し、全体精度は 保証しない方針 — パナソニック コネクト ナビゲーター型・ワークフロー型・汎用型に分類 エージェント単体の数値は未公開（全社 AI で 78.8 万時間） 出典: メルカリ Engineering Blog（2026-06）、LayerX Tech Blog（2025-10）、Ubie（Zenn）、AWS ブログ（freee）、Money Forward Developers Blog（2025-12）、パ ナソニック コネクト（2026-07）、サイバーエージェント AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 94 # Page. 95 ![Page Image](https://bcdn.docswell.com/page/LEL8ZM8N7R.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 規模・組織：全社基盤は何を共通化し、何を業務に任せるか 共通化するのは ID・権限・ツールのレジストリと MCP ゲートウェイ・観測・費用。正解の基準は業務チームが持つ 全社で共通化（プラットフォームチーム） 業務チームに任せる • エージェントの ID・委任トークン（誰の権限で動くか） • 業務特化のエージェント • ツールのレジストリと MCP ゲートウェイ（審査・許可リスト） • 評価基準（何を正解とするか）と評価セット • 認可・監査・ツールブローカー • 業務の禁止操作と承認の条件 • 観測・費用・ガードレール・ランタイムのテンプレート • 「機構は買える、判断基準は自前」（メルカリ） 企業 基盤の特徴 Uber 2 層の MCP ゲートウェイ、1 万超のサービスの API をツール化、呼び出し経路をトークンに埋め込み認可・監査 Pinterest 中央レジストリ登録の MCP サーバーだけ本番利用、利用者トークンとサービス ID の 2 層の認可 Cloudflare MCP ポータルで権限のあるサーバーを一括提供。ポータルの制御は「表示」で、直接 URL に注意 Block MCP サーバーの追加は MCP に詳しいエンジニアとセキュリティの 2 段階レビュー 出典: Uber Engineering「Solving the agent identity crisis」、Pinterest Engineering「Building an MCP ecosystem」、Cloudflare Blog「Enterprise MCP」、 Block Engineering（red teaming goose）、メルカリ Engineering Blog AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 95 # Page. 96 ![Page Image](https://bcdn.docswell.com/page/4JM6VY6QEW.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 AgentOps を語るための 7 つの持論（根拠付き） 会議で問われたときに、根拠を添えて言い切れる形にまとめた 1 指示は制御ではない。止めるのは権限と構造 Replit・Railway の事故、OWASP LLM06 2 モデルは提案者。実行の許可は別の仕組みが出す 元レポート、OPA・Cedar、AgentCore Policy 3 成功は状態で判定し、過程の違反を別に数える τ-bench、TraceTrial-Bench（成功した実行にも基準未達） 4 1 回の成功ではなく、繰り返しの成功で測る τ-bench（pass^1 61% → pass^8 25% 未満） 5 注入は防ぎきれない。三つ組のどれかを断つ EchoLeak・ForcedLeak、Lethal trifecta、CaMeL 6 回復は推論と別。結果不明は再送しない Temporal・LangGraph の仕様、Replit・Railway 7 評価は実際の失敗 20〜50 件から。採点器も較正 Anthropic「Demystifying evals」、Shopify（κ） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 96 # Page. 97 ![Page Image](https://bcdn.docswell.com/page/PJRP29PKE9.jpg) 補足 計画 出力 行動制御 回復 評価 観測・運用 自己診断チェックリスト：エージェントは安全に動かせる状態か 「いいえ」が次の打ち手。右列（赤枠）は事故に直結するので、いいえならリリースしない 成功条件と禁止操作を業務オーナーと合意した 本番の書き込み権限をエージェントに直接渡していない 実際の失敗から評価 20 件以上がある 更新系ツールの直前に決定的な認可がある 成功を状態検査で判定している 承認は操作内容のハッシュに結び付いている 複数試行・pass^k で一貫性を測っている 冪等性キーと、結果不明時の照合がある 採点器を人のラベルで較正した 私的データ・未信頼コンテンツ・外部送信の三つ組を断った ループ・トークン・金額にハード上限がある キルスイッチとロールバックを試した AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 97 # Page. 98 ![Page Image](https://bcdn.docswell.com/page/PEX3DQ35JX.jpg) Part 10 の主要出典 • 事故・開示：Replit（2025-07）／Railway（2026-04・05）／Cursor（HN、2025-04）／Moffatt v. Air Canada（2024、解説による）／AWS-2025015（Amazon Q）／Invariant Labs（GitHub MCP、2025-05）／EchoLeak CVE-2025-32711（arXiv:2509.10540）／Noma ForcedLeak（ 2025-09）／Tracebit（Gemini CLI）／PromptArmor（Antigravity）／Supabase「Defense in depth for MCP」／Asana status／Nx s1ngularity postmortem／Anthropic「Disrupting AI espionage」 • 運用事例：Anthropic（multi-agent research、Claude Code sandboxing）／OpenAI（Scaling code verification）／Sierra（τ-bench）／ Shopify（Sidekick）／Stripe（Minions）／Spotify（background coding agents）／Uber（uReview、agent identity）／Airbnb（test migration） ／DoorDash／Intercom Fin／Salesforce／Klarna／LinkedIn／Pinterest（MCP ecosystem）／Cloudflare（Enterprise MCP）／Block（ goose） • 国内：メルカリ／LayerX／Ubie／freee／マネーフォワード／パナソニック コネクト／サイバーエージェント • 論考・標準：Simon Willison「The lethal trifecta」（2025-06）／Cognition「Don’t Build Multi-Agents」（2025-06）／RAG-MCP（ arXiv:2505.03275）／OWASP LLM06・LLM07:2025、Agentic Top 10（2025-12） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 98 # Page. 99 ![Page Image](https://bcdn.docswell.com/page/3EKYX9YRJD.jpg) 適用限界と未解決点 日本語・専門業務への適用、自動の原因特定、形式保証の境界、製品の変化、評価の自己目的化 日本語・専門業務 英語中心の根拠。日本語の省略・社内用語・承認 規程に同じ数値は使えない 自動の原因特定 ログから因果的な根本原因を高精度に保証する 段階ではない 製品機能の変化 SDK・計測規約・評価製品は変化が速い。版を 固定して確認 評価の自己目的化 Judge に好まれる文章や全面拒否は、スコア を上げても価値を上げない 形式保証の境界 規則・入力・信頼モデルの範囲の保証と、現実の 安全は別 リーダーの視点 これらをリスクとしてプロジェクト計 画に明記し、検証のタスクと担当を割 り当てる 出典: 元レポート「適用限界と未解決点」 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 99 # Page. 100 ![Page Image](https://bcdn.docswell.com/page/L7395W9G75.jpg) 総括 確率的な判断を含むソフトウェアを、検証できる契約・状態・権限・回復で囲み、継続的に評価する 契約 状態 権限 回復 成功条件・禁止操作を人 とコードで定義 成功は外部の状態で判定 。意図・試行・結果を記録 モデルは提案者。認可・承 認はモデルの外で決定的 に 冪等性・照合・キルスイッ チ・ロールバック 継続評価 実際の失敗から評価へ。 採点器も較正 「正しく考えさせる」だけでなく、「間違えても許可されない行動は実行できず、失敗を検出・説明・回復できる」設計を最優先 にする 対になる資料「Advanced RAG 実践ガイド」と合わせて、入力の質（証拠）と行動の質（制御）の両方を設計する AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 100 # Page. 101 ![Page Image](https://bcdn.docswell.com/page/87DGDKGN7G.jpg) 付録：用語集① 用語 定義 ハーネス（Harness） モデルの周りのプロンプト・ツール・ループ・状態・検査・ログなど、実行の仕組み全体 軌跡（Trajectory） エージェントが呼んだツール・順序・引数の記録 pass@k ／ pass^k k 回のうち 1 回でも成功する確率 ／ k 回すべて成功する確率 LLM-as-a-Judge LLM に回答や成果物を採点させる方法 Agent-as-a-Judge 評価器自身がエージェントとして成果物や記録を探索して採点する方法 構造化出力 モデルの出力を JSON Schema などの構造に適合させる機能 ガードレール 入力・出力・ツール呼び出しを検査する仕組み 実行ブローカー 更新系ツールの実行を一手に引き受け、検証・認可・承認・冪等性・監査を行う層 冪等性キー 同じ操作の再試行を一度だけの実行として扱うための ID AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 101 # Page. 102 ![Page Image](https://bcdn.docswell.com/page/VJP3XK3NE8.jpg) 付録：用語集② 用語 定義 Durable Execution 状態を永続化し、障害後に再開できる実行の仕組み（LangGraph、Temporal 等） interrupt 承認や追加入力のために実行を止め、再開する仕組み（再開はノードの先頭から） 間接プロンプトインジェクション ツールの出力や文書など未信頼のデータに埋め込まれた指示 Lethal trifecta 私的データへのアクセス・未信頼コンテンツ・外部送信の 3 つがそろった危険な状態 MCP エージェントとツール・データをつなぐプロトコル（Model Context Protocol） A2A エージェント同士をつなぐプロトコル（Agent2Agent） SLI ／ SLO ／ エラーバジェット 測る指標 ／ その目標 ／ 目標に対して許容できる失敗の量 Oracle Context 正解の証拠を直接与える評価条件。読解・判断の上限を測る 3 の法則 n 件すべて無事故のとき、事故率の 95% 上限はおよそ 3/n AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 102 # Page. 103 ![Page Image](https://bcdn.docswell.com/page/2EV4LV4YJQ.jpg) 付録：主要出典①（元レポートが参照した一次資料） • 評価・ベンチマーク：τ-bench（arXiv:2406.12045）／τ²-bench（arXiv:2506.07982）／τ³-bench（Sierra、2026-03）／Anthropic「 Demystifying evals for AI agents」（2026-01）／Judging LLM-as-a-Judge（arXiv:2306.05685）／Agent-as-a-Judge（ arXiv:2410.10934）／AlphaEval（arXiv:2604.12162）／TraceTrial-Bench（arXiv:2610.32285）／AgentChaosBench（arXiv:2608.14680 ）／BFCL・Epoch AI 監査（2026-09） • 制御・安全：OpenAI Structured Outputs・Agents SDK Guardrails／Cedar／OPA／NeMo Guardrails／AgentSpec（arXiv:2503.18666、 ICSE 2026）／AWS AgentCore Policy・Bedrock Automated Reasoning checks／AgentDojo（arXiv:2406.13352）／CaMeL（ arXiv:2503.18813）／Inspect Sandboxing／MCP Security Best Practices • 回復・観測・改善：LangGraph（Checkpointers・Interrupts）／Temporal Activity／Anthropic「Effective harnesses for long-running agents」 ／OpenTelemetry GenAI agent spans／自己修正研究（arXiv:2310.01798）／MAST（arXiv:2503.13657）／GEPA（arXiv:2507.19457、 ICLR 2026）／NIST AI Agent Standards Initiative（2026-02） AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 103 # Page. 104 ![Page Image](https://bcdn.docswell.com/page/57G1XL1WEL.jpg) 付録：主要出典②（本資料で補足した資料） • 基礎：Anthropic「Building effective agents」（2024-12）・「Effective context engineering」・「Writing effective tools」（2025-09）／ OpenAI「A practical guide to building agents」／Google「Introduction to Agents」（2025-11）／HumanLayer「12-Factor Agents」／MCP Specification 2026-07-28／A2A v1.0（2026-03）／METR（2025-03） • 実務・統計：Grafana（agent SLO、2026-10）／Google SRE Workbook／Microsoft Cloud Adoption Framework（AI agents）／Anthropic「 How we built our multi-agent research system」（2025-06）・「A statistical approach to model evaluations」（arXiv:2411.00640）／ Anthropic Prompt caching／NIST CAISI「Strengthening AI agent hijacking evaluations」／OpenAI「Why SWE-bench Verified no longer measures frontier coding capabilities」（2026-02） • 規制・標準：OWASP Top 10 for Agentic Applications 2026（2025-12）／OWASP LLM Top 10 2025／AI 事業者ガイドライン 第 1.2 版（202603）／AISI Japan 評価観点ガイド 第 1.20 版（2026-07）／EU Regulation 2026/1744／ISO/IEC 42001 • 事例：Part 10 の主要出典を参照 AgentOps と Agent Reliability 実践ガイド｜新任テックリーダー向け 104