エージェント基盤を、業務の一往復で比較する

エージェントを部署に配るとき、モデルの回答精度に加えて確認したいことがある。 誰の権限でデータを読み、更新前にどこで承認を取り、失敗した処理をどう調べるかである。 本稿は2026年5月7日までの発表を基に、こうした確認を基盤選定に組み込む方法を考える。 製品資料だけから、モデル性能の重要性が下がったことや、市場全体が一つの方式に収束したことまでは言えない。

比較対象を具体化するため、社内の問い合わせを読み、担当部署を提案し、人の確認後にチケットを更新する仕組みを想定する。 この一往復を候補の基盤で動かせば、機能一覧にある「統制」や「評価」が、実際のどの操作を扱うのかを確かめられる。

発表が示すのは、実行以外にも用意された機能である

Googleは4月22日のGemini Enterprise Agent Platform発表で、開発・拡張・統制・最適化を並べ、実行環境に加えてIdentity、Registry、Gateway、評価と観測の機能を説明した。 これは、エージェントの作成後に必要になる管理機能も製品の範囲として示した例である。 ただし、機能名が並んでいることは、自社の既存システムまで同じ規則が適用される証明ではない。

AWSは3月31日のAgentCore Evaluationsの一般提供発表で、本番のトレースを抽出して採点するオンライン評価と、変更をテストするオンデマンド評価を区別した。 実行後の品質を測る機能が具体化している。ただし、採点する仕組みと、不適切な更新を実行前に拒否する仕組みは役割が異なる。

この二例から私が導くのは、調達時の質問を増やす必要性である。 「動くか」に加え、「許可されない処理を止められるか」「失敗を判別できるか」を問う。 両社の提供範囲や性能が同等である、という比較結果ではない。

チケット更新のどこで責任が移るかを試す

想定した業務では、まずテスト用の問い合わせから適切な部署を選べるかを確認する。 ここはモデルの読解や分類が関わる。次に、権限のないチケットを指定し、接続先が読み取りや更新を拒否するかを確かめる。 正しい部署名を返せても、別の担当者の権限を借りて更新できてしまえば、導入条件を満たさない。

人の確認を挟む場合には、承認した対象と内容が実際の更新と一致するかを見る。 承認待ちの間にチケットが変わった場合や、実行が中断した場合も試したい。 再開後の重複更新を防ぐ責任が基盤、業務API、アプリケーションのどこにあるかを、処理記録と保存結果から確認する。

最後に、部署の誤分類と、承認を飛ばした更新を別々に検出できるかを調べる。 前者には分類用の正解例、後者には承認と更新を結び付けた記録が必要になる。 単一の品質スコアだけでは、この違いを見落とす可能性がある。

必要な管理機能を、既存の仕組みも含めて揃える

全機能を一つの製品から導入することが常に最適とは限らない。 Anthropicの設計記事は、簡単な構成から始め、必要に応じて複雑さを増やす考え方を示している。 既存のチケットシステムに承認と監査があるなら、それを利用する案と、新しい基盤に寄せる案を比べられる。

私は、試行結果を「基盤が提供すること」「接続先が保証すること」「自分たちが実装すること」に分けて残すことを勧める。 機能が不足する箇所だけでなく、設定、障害対応、変更時の再検証を誰が担うかも書く。 この比較なら、モデル品質を測りながら、業務を運用するための追加作業と費用も判断できる。