🧠 AI プロダクト動向

Anthropic は2026年3月〜4月にかけて Claude Code に生じた品質劣化の原因を、キャッシュ最適化のバグ・reasoning effort のデフォルト変更・システムプロンプトの冗長性制限という3つの独立した変更が重なった結果だと公表した。同社は「内部利用でも eval でも当初は問題を再現できなかった」と認めており、複数人によるコードレビューとユニットテスト・E2Eテストを通過した変更が、実運用では6週間気づかれなかった。3%の性能低下がようやく判明したのは、通常運用よりも広い範囲の eval セットで ablation を回した後だった。

これは「eval を書いているから安全」という前提そのものが崩れる例だ。既存の eval セットは既知の失敗パターンをカバーするために作られており、新しい変更が既存セットの外側で劣化を起こすと原理的に検知できない。Anthropic が事後対策として「システムプロンプトの変更ごとに広範なモデル別 eval を回す」「段階的ロールアウトとソーク期間を設ける」を挙げたのは、eval の中身を増やすだけでなく、変更のたびに評価範囲を見直すプロセス自体を制度化する方向への転換を意味する。

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 を測らない理由を隠さず明記する。これは手抜きではなく、評価設計として意図的にスコープを絞る選択だ。