Googleが公開した内容
Googleは11月7日、Agent Development Kit for Python v2.14.0をGitHubで公開しました。Release note上のversion日付は11月4日です。同社によると、execution environmentとsandbox、A2A integration、evaluationとuser-simulation class、その他のruntime moduleをexperimentalからstableへ移行しました。Multi-run evaluation、semantic tool-argument matching、Microsoft TeamsとOpenAI Decisionsのintegration、長いmulti-turn workflowの改善も追加しています。
今回のreleaseはAPI labelだけの変更ではありません。RunSkillScriptToolはfree-form shell commandではなく、検証済みpathとargumentを受け取るようになり、prompt injectionされたmodelが任意のshell commandを実行できた経路を閉じました。またGoogleは、30 node、200 turnのworkflowで実行時間を23%短縮し、peak memoryを9%削減したと報告しています。
運用上重要なcompatibility変更もあります。Enum annotation付きtool parameterはenum memberとして渡され、stableへ移行したfeatureは従来のfeature flagでは無効化できなくなり、2.14のFirestoreSessionServiceが書いたsessionは2.13以前では読めません。ここまではGoogleが公表したrelease detailと測定値です。以下の本番上の結論はIneezaの分析です。
「Stable」はAPIの約束であり、Isolationの証明ではない
LocalEnvironment、E2BEnvironment、DaytonaEnvironment、共通environment toolsetはstable interfaceを提供するようになりました。同じinterfaceの背後でもtrust boundaryは大きく異なり得ます。Local process、remote sandbox、container image、network policy、credential delivery、filesystem persistence、teardown guaranteeは同一ではありません。
Ineezaの分析: Environment implementationを交換可能なbackendではなく、capability profileとして検証すべきです。Imageまたはruntime identity、effective user、mount data、secret path、outbound destination、resource ceiling、file retention rule、termination authorityを記録します。Prompt injection、network denial、process escapeの試行、timeout、orphan cleanup、evidence captureを含む同じconformance suiteを、許可する全backendで実行します。Stable adapterが意味すべきなのはmethod signatureの互換性だけでなく、予測可能なcontrol semanticsです。
安全なArgumentにも独立したAuthorizationが必要
Modelが生成するshell stringを、検証済みscript pathとstructured argumentに置き換えることは、重要なcommand construction riskを除きます。しかし選択されたscript、target file、argument value、business actionが、このagentとtaskに対して承認済みであることまでは証明しません。
Ineezaの分析: 実行可能な各skillを、digest、許可interpreter、argument schema、filesystem scope、egress policy、credential class、approval requirementを含むimmutable manifestに結び付けます。Pathの解決と検証はmodelの外で行い、traversalとsymlink escapeを拒否し、実行前にdecision recordを出力します。Runtime sandboxとbusiness-policy engineはagent frameworkから独立させ、parsing mistakeやframework upgradeだけで権限が付与されないようにすべきです。
Multi-run Evaluationには統計とPolicyの境界が必要
ADKは各evaluation caseを複数回、並列に実行し、scoreまたはpass rateを集約できるようになりました。ToolArgsMatcherはargumentをexact、case-insensitive、numeric tolerance、またはLLM-backed semantic checkで比較できます。これらは非決定的systemのtestを容易にしますが、matching modeごとに答えるassurance questionは異なります。
Ineezaの分析: Security principal、destination、asset identifier、monetary value、policy version、irreversible actionにはexact matchingを使います。Semantic matchingはequivalenceが明示的に安全なfieldに限定し、matcher model、prompt、verdictを証跡として保存します。Sample countとacceptance thresholdはfailureの影響から定め、平均pass rateだけでなくdistributionとworst caseを報告します。Model、tool fixture、policy、dataset、environmentのversionを固定し、release gateを再現可能にすべきです。
UpgradeとRollbackを一体で設計する
今回のreleaseにはtool argumentのbreaking behavior、stableへ移行したfeatureのdisable control削除、旧versionで読めないFirestore session writeが含まれます。そのためdeploymentは、toolが変更後のtypeを受け取るまで、緊急feature停止を試みるまで、または新形式sessionが残る状態でrollbackするまで正常に見える可能性があります。
Ineezaの分析: Recorded trafficと、tool input、session serialization、feature availability、telemetryに対する明示的assertionを使ってframeworkをcanary展開します。Schema versionでsession readerとwriterをgateし、検証済みdowngradeまたはforward-repair pathを維持し、mixed-version workerが非互換sessionをclaimしないようにします。削除されたframework feature flagはdeployment、routing、policy layerのcontrolで置き換えます。Rollback readinessはincident時の前提ではなく、release acceptance testの一部です。
A2A DiscoveryはAgent Trustではない
A2A integrationはstableとなり、CLIでagent cardを生成できます。Discoveryとinteroperabilityを標準化できますが、cardはendpointとcapabilityを説明するものであり、どの組織が運用するか、どのauthorityを付与すべきか、特定taskのresultを安全に受け入れられるかは確立しません。
Ineezaの分析: Remote workloadを認証し、そのcardとprotocol versionを承認済みidentityへ結び付け、action、resource、tenant、expiryごとにtaskを認可します。Delegation、progress、cancellation、artifact、terminal stateを一つのdurable task identityで相関させます。Remote outputはprovenanceとpolicy checkを通過するまでuntrusted inputとして扱い、network failure時のcancellationとduplicate deliveryをtestします。Interoperabilityはintegration surfaceと同時にcontrol surfaceも拡大します。
Ineezaの見解
ADK 2.14が重要なのは、本番agent teamが必要とするsandbox adapter、agent間通信、非決定的evaluationをstable interfaceへ移す一方、framework versionを単純なlibrary updateとして扱うコストも明確にしたためです。正しい本番単位は、environment capability、executable authority、evaluation policy、session schema、interoperability identity、observability、rollbackを含むruntime contract全体です。Teamはこのcontractを環境間で一体としてpromoteし、frameworkのstable labelをoperational readinessとして受け入れる前に、各boundaryの証跡を要求すべきです。