Anthropic は2026年3月〜4月にかけて Claude Code に生じた品質劣化の原因を、キャッシュ最適化のバグ・reasoning effort のデフォルト変更・システムプロンプトの冗長性制限という3つの独立した変更が重なった結果だと公表した。同社は「内部利用でも eval でも当初は問題を再現できなかった」と認めており、複数人によるコードレビューとユニットテスト・E2Eテストを通過した変更が、実運用では6週間気づかれなかった。3%の性能低下がようやく判明したのは、通常運用よりも広い範囲の eval セットで ablation を回した後だった。
これは「eval を書いているから安全」という前提そのものが崩れる例だ。既存の eval セットは既知の失敗パターンをカバーするために作られており、新しい変更が既存セットの外側で劣化を起こすと原理的に検知できない。Anthropic が事後対策として「システムプロンプトの変更ごとに広範なモデル別 eval を回す」「段階的ロールアウトとソーク期間を設ける」を挙げたのは、eval の中身を増やすだけでなく、変更のたびに評価範囲を見直すプロセス自体を制度化する方向への転換を意味する。
", "examples": [ { "product": "Claude Code（Anthropic 公式ポストモーテム）", "approach": "品質劣化の原因を3つの独立した変更の重なりと特定し、既存 eval・コードレビュー・単体テストがすべてこれを見逃していたと公表", "detail": "「neither our internal usage nor evals initially reproduced the issues」と明記し、広い ablation テストでようやく3%の性能低下を検出したと報告している", "source_url": "https://www.anthropic.com/engineering/april-23-postmortem" } ], "takeaway": "既存の eval セットが通ったことを「安全」の証明にしない。変更のたびに評価範囲を見直し、段階的ロールアウトとソーク期間をセットで運用する。" }, { "heading": "測る軸を先に決める — Outcome / Process / Style / Efficiency", "body_html": "OpenAI は Codex のエージェントスキルを評価する型を「プロンプト→キャプチャされた実行（トレース＋成果物）→小さなチェック群→比較可能なスコア」という4段階で定式化した。その上で成功の測り方を、タスクが完了したかという Outcome、意図した手順・ツールを踏んだかという Process、指定した規約に沿っているかという Style、無駄なコマンドやトークン消費を避けられているかという Efficiency の4軸に分けて設計するよう推奨している。
この定式化が意味を持つのは、軸を分けないと「なんとなく良さそう」という単一の印象評価に流れやすいからだ。codex exec --json のイベントトレースを使った決定的チェックと、--output-schema によるモデル採点によるルーブリック評価を組み合わせ、まず1スキールにつき10〜20件程度のプロンプトから始めて実際の失敗が見つかるたびに増やす、という規模の目安まで示している点が実務的だ。
Cognition の Devin は自社の脆弱性検出エージェント「Security Swarm」の評価を、学習カットオフ後に公開された50件の実脆弱性（14言語、60KB〜92MBのリポジトリ）に対する recall のみに絞った。CWE と該当ファイルパスの一致を手がかりに見逃しを厳密に判定する一方、false positive の判定は「大量に発生するものを一件ずつ true/false と判定するのは規模的に不可能」として明示的に採点対象から外している。結果は Security Swarm が72% recall（1スキャン90.23ドル）、Claude Security が68%（131.87ドル）、Codex Security が48%、Cursor Security が26%（4.60ドル）と、競合含めた具体的な数値で公開されている。
この割り切りが示すのは、「全部を公平に測る」ことより「その製品にとって見逃しと誤検知のどちらが致命的か」を先に決めて測定コストを片方に集中させる判断の方が実務的だという点だ。セキュリティ用途では見逃しの方が誤検知よりコストが高いため recall を主指標に選び、false positive を測らない理由を隠さず明記する。これは手抜きではなく、評価設計として意図的にスコープを絞る選択だ。
", "examples": [ { "product": "Devin Security Swarm（Cognition 公式ブログ）", "approach": "脆弱性検出エージェントの評価指標を recall のみに絞り、false positive の判定は規模的に不可能として意図的に対象外にする", "detail": "50件の実脆弱性データセットで Security Swarm 72%・Claude Security 68%・Codex Security 48%・Cursor Security 26% という recall とスキャン単価を具体的に公開している", "source_url": "https://devin.ai/blog/security-swarm-eval" } ], "takeaway": "全軸を均等に測ろうとせず、自分のプロダクトで見逃しと誤検知のどちらのコストが高いかを先に決め、測らないと決めた軸は理由込みで明記する。" } ] }, "editorial": "3社の記事に共通するのは、エージェントの評価・観測性が「テストカバレッジを増やす」話ではなく、「何を測るか」と同じ重みで「何を意図的に測らないか」を設計時に選び取る作業だという認識だ。Anthropic の事例は測り漏れが起きた後の話、OpenAI と Devin の事例は測る前にスコープを決める話であり、両方揃って初めて実運用に耐える評価設計になる。", "quick_picks": [ { "title": "Anthropic、長時間タスク開発における Planner / Generator / Evaluator の3エージェント構成を公開", "summary": "2026年3月24日公開の記事で、Evaluator エージェントが Playwright MCP で実際にアプリを操作し、事前に合意した完了基準に照らして Generator の成果を採点する構成を解説する。自己評価をエージェント自身の役割として組み込む設計は、本文で扱った『測る軸を先に決める』の実装例として読める。", "url": "https://www.anthropic.com/engineering/harness-design-long-running-apps" }, { "title": "LangChain「State of Agent Engineering」、オフライン eval 導入率52.4%を報告", "summary": "2026年6月12日公開の調査レポートで、オフライン eval を導入している組織が52.4%、オンライン eval は37.3%（本番運用組織では44.8%）にとどまると報告する。本文セクション1で触れた『eval を書いていても検知できない』構造は、そもそも半数近くの組織がオフライン eval すら回していないという前提の上にある。", "url": "https://www.langchain.com/state-of-agent-engineering" }, { "title": "Langfuse、エージェントスキル評価でCLIエラー率を25%からゼロへ改善した事例を公開", "summary": "2026年2月26日公開の記事で、スキル評価をプロンプト評価と同様に入力定義・トレース取得・スコアリングの反復として扱い、Langfuse CLI のエラー率を25%からゼロまで下げた具体例を報告する。本文で扱った OpenAI の『プロンプト→トレース→チェック→スコア』の型を別ベンダーの実装で裏付ける一例。", "url": "https://langfuse.com/blog/2026-02-26-evaluate-ai-agent-skills" } ] }