Antigravityの研究成果が問い直す、エージェントの受入基準

2026年11月13日、Google ResearchはAntigravity /teamworkによる新たな研究・工学成果を公表した。人との協働に加え、証明検査器や変更していないテスト群など、外部の評価手段を説明している。これは開発元が報告した成果であり、当編集部が独立に再現した結果ではない。Google Research

初めての発表でもない。Googleは8月27日の記事ですでにプレビュー版を紹介していた。以前の発表 いま重要なのは、何体のエージェントを同時に動かせるかではなく、その成果をチームが何を根拠に受け入れるかだ。以下はOpen Market Notesの分析であり、未公開の製品動作を説明するものではない。

答えの外に判断基準を置く

長く筋の通った説明は、提案を理解しやすくする。しかし、それだけで提案が正しくなるわけではない。批判役のエージェントを追加すれば、見落としを発見できるかもしれない。それでも生成する側同士の合意は、問題の解決を保証しない。評価者全員が同じ未検証の前提を引き継ぐ場合があるからだ。独立した受入手続きには、会話ではなお説得力のある成果を却下できるという意味がある。

社内のデータ処理サービスを書き直す仮想的な案件を考えたい。通常の入力で同じ出力になることは必要だが、業務では不正な入力への安定した対応、メモリ使用量の制約、後続システムとの互換性も求められるかもしれない。既知の負荷で高速な候補が、その条件の一つを満たさない可能性はある。目立つベンチマークだけで成功とすれば、当初の仕事を知らない間に容易な仕事へ置き換えたことになる。

受入基準は成果が出た後の祝賀的な説明ではなく、依頼の一部であるべきだ。有用な記録は、検査した版、環境、判定条件、対象外の範囲を結び付ける。そうしなければ、合格したのは旧版なのに納品物は別のファイル、という状態が起こる。意図的な誇張がなくても、評価の結論と受け取る成果の不一致は引き継ぎを不確かにする。

形式検証は問題を選ばない

Leanの文書は、証明の妥当性と、証明された命題の意味を区別する。また、別に信頼された命題と候補の証明を照合する方法も説明している。Leanの文書

この区別は、印象的な実演を読む際に役立つ。形式化した問題を解くことと、意味があり正確に表現された問題を選ぶことは別の貢献だ。信頼性を「整ったデータセットで完了すること」と定義したなら、その定義の下での証明やテストは、欠損データへの挙動を自動的に説明しない。そのケースが条件に含まれている必要がある。形式手法を否定する話ではなく、業務要件と形式条件の対応を明示するということだ。

仕様を承認する人が、すべての実験を自ら行う必要はない。ただし、仕様が意図した仕事を表すかどうかには、誰かが責任を持つ必要がある。実行を委任しても責任は消えず、人の仕事の重点が移る。複数部門が結果を使うなら、技術部門のいう「完了」に運用部門が気にする例外処理が含まれていないこともある。違いを早く明確にするほど、得られた証拠が何を支えるか判断しやすい。

試行を増やすなら終了条件も必要だ

並行探索は、一人では試さない経路も含め、選択肢を増やせる。ただし費用はモデル呼び出しだけではない。出力の比較、矛盾する証拠の調査、テスト環境の維持にも資源が必要だ。もっともらしい候補が大量にある状態より、却下理由が明確な少数の候補の方が有用な場合もある。少なくとも、調べた方向と推測のままの方向を区別できる。

評価の一案は、再確認と失敗した試行も総費用に含め、実際に採用された仕事と比較することだ。これは本稿の分析上の提案であり、Googleが開示した指標ではない。システムが動いていた時間を、そのまま顧客が節約した時間と数える誤りを避けられる。改善と反復を区別できない評価手続きなら、追加計算は審査待ちの資料を増やすだけかもしれない。

終了する理由も必要になる。目標を満たした、予算を使い切った、あるいは新たな証拠によって依頼を変更すべきだと分かった場合だ。成功という結果を得るために黙って基準を下げれば、比較は意味を失う。依頼の合理的な変更は可能だが、理由と時点を残し、新基準での結果を旧基準への適合として示してはならない。

最終テストを探索の一部にしすぎない

同じテストから詳細なフィードバックを繰り返し受けると、別の問題が生じる。候補はそのテストには強くなっても、より広い仕事では改善していないかもしれない。前述の仮想的な書き直し案件なら、開発用のケースで反復を進め、別に管理するケースで最終受入を判断する方法が考えられる。これは本稿が提案する防護策であり、Googleの実装についての主張ではない。探索が繰り返し最適化の対象にしていない情報を、ある程度残すことが目的だ。

分離にも費用がある。保留したケースは診断に直接使いにくく、有限のテストではすべての運用上の故障を網羅できない。したがって万能な保証ではない。失敗の発見と最終判断を区別し、評価ルールを候補の編集権限の外に置き、異常に大きな改善を自動的に評価するのでなく調査する必要がある。テストが容易になったための改善は、実装自体の改善とは異なる。

楽観的に見れば、多エージェント研究は希少な専門家が関わる前に探索量を増やせる。慎重に見れば、仕様の定義や再確認が新たな制約になる。二つは両立する。探索を効率化する仕組みは、同時に受入手続きの質を一層重要にしうる。

11月の更新は、開発元による研究進展の報告として注目に値する。しかし、あらゆる仕事の成功率、顧客の総費用、導入準備の成熟度を確定するものではない。実際の採用判断で問うべきなのは、具体的なチームが十分な受入基準を定義し、保存し、独立に適用できるかだ。それまでは、追加のエージェント活動を調査の過程として扱い、完了した業務成果とは区別する必要がある。