大企業にバグ報告をするのは、良い歯車への第一歩

最近仕事でAIエージェント開発用のAI駆動開発の標準を作っている（ややこしい）。

作ったエージェントの応答・性能がちゃんとしているかは、Google の ADK（Agent Development Kit）の評価機能で確かめる方針を取ることにした。 評価基準が公式で用意しているなら、活用するに限る。

なんか想定と違う動き

GoogleADKの評価は 0 から 1 のスコアで、1 に近いほど安全ということになっている。そのため、普通の応答なら 1 に近い値が出るはずで、0 は「危ない」という判定になる。

今回想定と違う挙動をしたのは「safety_v1」で、安全性を確かめる指標だ。

最初に疑ったのは自分の調査不足。使っているのは Google の公式のフレームワークで、こちらは触り始めたばかりだ。おかしいのは自分の使い方のほうだろう、と思った。

調査も我が相棒 Claude Code と話しながら進めた。「safety_v1」は内部でAI が評価するので、怪しいところはいくらでもある。日本語だからうまく判定できていないのかもしれないし、AI の判定だから実行のたびに結果が揺れているのかもしれない。

原因をきりわけていく

こういう時は、事実と推測を分けてから原因を探すのがいい。

ただ厄介なのは、採点しているのが AI だというところだ。普通のライブラリなら、同じ入力には同じ結果が返ってくるので、動かした結果をそのまま事実として扱える。返してくるのが AI だと、結果そのものが揺れているかもしれず、事実として置けるものが少なくなる。

面倒だなと思いながら、まずは手元にあるものを仕分けた。

事実（確かめられること）

• ADK のドキュメント（評価基準のページ）には、safety_v1 は 0 から 1 のスコアで、1 に近いほど安全と書いてある
• Vertex AI のドキュメント（評価指標の詳細）にも、Safety の最新版は safety_v1 で、0 が危険、1 が安全と書いてある
• ADK のコードでは、スコアが基準値以上なら合格になる（score >= threshold）
• ADK と Vertex AI SDK のコードは手元で読める。読めないのは Google Cloud 側の評価サービスの中身だけ

推測（原因の候補）

• 自分の使い方が間違っている
• 日本語だからうまく判定できていない
• AI の判定なので、実行のたびに結果が揺れている
• AI の判定の性能が足りていない
• ライブラリのバージョンの組み合わせが悪い
• ドキュメントが間違っている

仕分けてみると、推測の多くは試せば事実に変えられるものだった。一つずつ潰していった。

候補	確かめたこと	結果
使い方の間違い	設定はドキュメントどおり {"criteria": {"safety_v1": {"threshold": 0.8}}}。safety_v1 の設定で読まれるのは threshold だけで、ほかに変えられる項目がない	間違えようがなかった
日本語	英語の短い文（Today is September 24, 2026.）でも同じことが起きた	関係ない
結果の揺れ	何度実行しても、問題のない応答は 0.0、有害な応答は 1.0 と、同じ結果が出る	揺れではなく、毎回決まって起きている
性能不足	同じ応答を、バージョンを明示した safety_v1 で採点すると、問題のない応答は 1.0、有害な応答は 0.0 と正しく出た	採点する AI は悪くない
バージョン	SDK のコードに、バージョンのない safety を safety_v3 に読み替える対応表があった。issue で別の開発者が確かめてくれたところでは、古い SDK（1.148.1）にはこの表がなく、safety_v1 のまま送られる	これが原因
ドキュメント	Vertex AI のドキュメントは最新版を safety_v1 としているのに、SDK は safety_v3 を最新版として扱う。safety_v3 はどのドキュメントにも載っていない	ドキュメントと SDK がずれていた

最後に残ったのは、事実の側に置いていたはずのドキュメントだった。ドキュメントにそう書いてあることは事実だが、書いてある内容が今も正しいとは限らない。

公式のバグっぽい

つまり、こういうことだった。

ADK には safety_v1 という安全性の評価がある。ところが ADK は、評価を頼むときにバージョンを指定していなかった。間に入る Vertex AI SDK は、バージョンのない指定を最新版に読み替える。そのせいで、裏では safety_v3 という別の評価が使われていた。そして、この二つはスコアの向きが逆だった。

流れで書くとこうなる。

応答	safety_v1	safety_v3（実際に使われていた）
問題のない応答	1.0	0.0
有害な応答	0.0	1.0

ADK は、スコアが基準値以上なら合格にする。向きが逆なので、問題のない応答が落ちて、有害な応答が通ることになる。安全性のチェックが丸ごと裏返っていたわけだ。

しかも厄介なことに safety_v3 はドキュメントのどこにも載っていないし、結果の画面にも safety_v1 と出たままになる。使っている側から、入れ替わりに気づく手がかりはなかった。

仕様でしたをやめるために、はじめての issue

これまでは、調べた結果が「公式の仕様です」なら、そこで終わりにしていた。あとは直るのを待つか、自分で回避策を考えるだけ。でもそれでは何も積み上がらない。と今さら気づいて（遅い）、はじめて OSS に issue を出した。

一旦書けることを全て全部書いてみた。起きていること、再現手順、計測結果、影響、直し方の案、回避策。

反応は思ったより早かった。出して 30 秒程度で別の開発者が「自分が直す」とコメントし、12 分後には修正のプルリクエストが出ていた。

3 時間ほどして、また別の開発者が最新版の ADK でも再現することを確かめて、回避策を教えてくれた。ただ、その人の環境では実際の採点までは動かせないので、効くかどうか見てほしいとのこと。その少し後には Google の担当者からも、お礼と「把握していて、いま直している」という返事が来た。

頼まれた確認は、評価のクラスを直接呼ぶ方法と、adk eval から通す方法の二通りでやった。どちらでも、問題のない応答は合格に、有害な応答は不合格に戻った。報告だけのつもりが、いつの間にか修正の確認まで手伝っていた。

日本時間の翌朝、その開発者からまたコメントが来ていた。自分が回した確認は、修正のプルリクエストに足りていなかった「実環境での通しの確認」になったらしい。さらに、起きるかどうかは SDK のバージョン次第で、ADK が対応する最も古い 1.148.1 では起きず、1.165.1 では起きることまで調べてくれていた。そのうえで Google の担当者に、このプルリクエストを修正として採用すること、影響を受けた環境では safety_v1 の結果が逆になっていたのでリリースノートにも書くことを提案してくれていた。

どうせならいい性能の歯車になれ

小さいことでも自分から動けば、自信も、周りからの信用も、スキルも積み上がっていく。社会人として歯車をやっている以上、どうせなら便利な歯車でいたい。今回の issue も、この報告がきっかけで直るはずだ。

あと技術の先端にいる開発者の対応スピードを直に経験できた。なるほどこれは積極的に動いてIssueをあげないと気づけない。と思った。

それと、コードを読むのが得意ではない自分がここまでたどり着けたのは、Claude Code と話しながら進めたからだ。一人だったら、たぶん自分のミスということにして終わっていた。技術は好きだけど得意ではない。だからこそ、こういう道具は使い倒したい。

反応があって、お礼まで言われたのはうれしかった。これからは見つけたら報告するし、次は自分で直してプルリクエストを出すところまでやってみたい。

修正のプルリクエスト（#7259）はまだマージされていない。直ったら追記する。

報告した issue：google/adk-python#7258