#Evaluation

Google Developers Blogは、エージェント品質改善のための「Agent Quality Flywheel」を、コーディングエージェントから実行できる開発者向けスキルとして紹介しました。評価データ準備、推論、採点、失敗分析、最適化を反復する流れを自動化します。

この更新は、プロンプト変更が本当に品質を改善したか、別のケースを壊していないかを検証する開発者向け手法です。既存のOpenTelemetry traces、手作りケース、合成シナリオから評価データを作り、エージェントを実行してトレースを生成します。採点ではGoogleのadaptive AutoRatersまたは独自メトリクスを利用し、失敗クラスタを分析して改善対象を絞ります。AutoRatersはGoogle DeepMindとの協力で開発されたと説明されています。対象は本番エージェントを継続改善する開発チームで、特定APIの移行期限や破壊的変更は示されていません。

Google Developers Blogは、Julesを含むプロアクティブなAIコーディングエージェントを評価するための研究的取り組みを紹介しました。 SWE-Benchのようなタスク完了評価ではなく、目標に対して何を重要と判断して通知するかを測る「insight policy」が焦点です。

記事では、AIコーディングエージェントが単発タスクを解くだけでなく、コードベースを探索し、リスクや診断的洞察を能動的に提示する段階へ移っていると説明されています。 Google Labsの研究では、実際のバグ修正履歴を使い、時間的近接性と意味的類似性から、複数のバグが示す上位目標を推定する評価セットを作っています。 初期評価では、705件のバグと1,178件のCLを使い、修正前の状態に戻したコードベースをエージェントに探索させ、予測した洞察をLLMで1〜5点評価しました。 1回の探索では平均4.5/5の関連性が出た一方、複雑な問題では探索予算を2回から3回へ増やすことでHit@5が33%から57%へ改善したとされています。 Julesや将来のプロアクティブな開発エージェントでは、いつ通知し、いつ黙るべきかを評価することが重要になります。 製品の一般提供条件、無料/有料、日本での利用可否、APIの破壊的変更はこの記事では示されていません。

OpenAIは、実際の生命科学研究ワークフローに近いAI評価ベンチマーク「LifeSciBench」を発表しました。 750件の専門家作成タスク、1,062件の添付アーティファクト、19,020件のルーブリック基準で、研究支援能力を細かく評価します。

LifeSciBenchは、AIが単なる生物学知識の回答ではなく、実際の生命科学研究タスクを支援できるかを測るベンチマークです。 タスクはPh.D.レベルの訓練とバイオテック/製薬業界経験を持つ173人の専門家が作成し、453人の専門レビュー担当者が評価しました。 750件のタスクは、エビデンス処理、分析、設計・最適化、科学的推論、検証・運用、トランスレーション、科学コミュニケーションの7ワークフローと7生物領域をカバーします。 タスクの79%は複数ステップの推論や意思決定を必要とし、53%は図、PDF、表、配列ファイル、構造/化学ファイル、Web参照など少なくとも1つの添付アーティファクトの解釈・統合を要求します。 評価は最終答えだけでなく、科学的に妥当な理由づけ、重要な caveat、運用上有用な形式まで、19,020件の詳細ルーブリックで採点します。 開発者向けAPI変更、モデル移行期限、破壊的変更はありません。生命科学向けAIエージェントや研究支援モデルの評価に関わる研究者・開発者に重要です。

OpenAIは、新モデル公開前に実運用に近い会話文脈を再現して望ましくない挙動を予測する「Deployment Simulation」を紹介しました。 GPT-5系Thinkingモデルやエージェント的なツール利用環境で、従来評価より実運用時のリスク推定を改善できたと説明しています。

従来の安全性評価は、合成プロンプトや高リスクケースに偏りやすく、実際の利用分布でどの程度問題が起きるかを推定しにくい課題がありました。 Deployment Simulationは、過去の会話から元のアシスタント応答を取り除き、公開候補モデルで応答を再生成して、実運用に近い分布で望ましくない挙動を測ります。 OpenAIは、GPT-5系Thinkingモデルの複数デプロイで、望ましくない挙動の発生率推定、未知のミスアラインメント検出、モデルが評価中だと認識するリスクの低減に役立ったとしています。 約130万件の匿名化済み会話を分析し、GPT-5.4 Thinkingでは20種類の望ましくない挙動について事前登録した予測も行っています。 エージェント的なコーディング環境では、ライブ環境に実ツールを実行せず、リポジトリ状態や過去のツール応答を使ってツール呼び出しをシミュレーションする方法も示されています。 開発者向けのAPI変更や移行期限はありませんが、モデル公開前評価、レッドチーム、システムカード、エージェント安全性評価に関わるチームには重要な研究更新です。

OpenAIがフロンティアモデルに対する第三者評価の取り組みを紹介しました。自社評価だけでなく、外部専門家・組織による安全性や能力評価を重視する内容です。

これは新機能ではありませんが、将来モデルの公開条件や安全性レビューに関わります。高性能モデルでは、サイバー、バイオ、欺瞞、説得、モデル自律性などのリスク評価が重要になります。第三者評価を入れることで、社内だけでは見落としやすいリスクを検出しやすくする狙いです。OpenAIのガバナンス標準と合わせて、モデル公開前のチェックがより制度化されていく流れです。

Anthropicが、フロンティアAIモデルの危険能力を評価するための **Frontier Red Teaming Protocol** を公開しました。モデルがサイバー、生物、化学、核、AI研究開発などの高リスク領域でどの程度危険な支援能力を持つかを測る枠組みです。

これはClaudeなどの高性能モデルを安全に展開するための評価手順で、AnthropicのResponsible Scaling Policyと接続する重要な研究更新です。評価対象には、悪用可能な専門知識、実行可能な手順の生成、攻撃・開発支援能力などが含まれます。単なるベンチマークではなく、専門家によるレッドチーミングと実践的なタスク評価を組み合わせる設計です。開発者や企業ユーザーに直接新機能を提供する発表ではありませんが、今後のClaudeモデルの提供条件、安全制限、公開タイミングに影響する可能性があります。AI安全性・ガバナンス観点では重要度が高いです。