要点
今週の論点は、どのモデルが賢いかより、どの基盤が作成・実行・統制・評価を一続きで回せるかにある
2026年5月7日までに公開されている Google、Microsoft、AWS、Anthropic、OpenAI の一次情報を重ねると、 AIエージェントの比較対象がはっきり変わってきたことが見える。以前なら、主役はモデル性能や単体のツール接続力だった。 しかし今は、それだけでは本番導入の説明にならない。どこでエージェントを設計するのか、どの実行環境で動かすのか、 誰が権限を与えるのか、どのルールで止めるのか、どうやって失敗を観測し改善するのかまでが、同じ製品面で比較され始めている。
今週を単独の発表として読むより、主要ベンダーが「作成」「実行」「承認」「評価」を一体の運用基盤として公開面にそろえ始めた 収束週として読む方が自然である。Google は Gemini Enterprise Agent Platform を「作成」「拡張」「統制」「最適化」の4本柱で見せ、 Microsoft は Agent Framework 1.0 と Agent Governance Toolkit を並べ、AWS は AgentCore に Registry、Policy、Observability、 Evaluations を載せた。Anthropic と OpenAI は Agent SDK、permissions、sessions、sandbox、tracing、eval harness の公開資料で、 その基盤をどう運用するかを補っている。
31件
公開根拠
公式 docs、公式告知、公式 SDK ドキュメントだけで、今週の主論点を十分に比較できる厚みがある。
5系統
比較対象
Google、Microsoft、AWS、Anthropic、OpenAI の運用面を横並びで読むと、共通の設計語彙が見えてくる。
4層
新しい比較軸
作成、実行、統制、評価の4層で見ると、各社の違いと収束が同時に整理しやすい。
1変化
主役が変わった
モデル単体ではなく、エージェントを安全に回し続ける運用基盤そのものが製品の主役になっている。
今週の意味
2026年春の点だった動きが、今週は一つの運用スタックとして線でつながった
AWS は AgentCore Evaluations を GA にし、評価を本番監視と結びつけた
評価は研究用の補助ではなく、本番トラフィックの継続監視と変更検証に使う前提が明示された。
Microsoft は Agent Governance Toolkit を公開し、統制を独立レイヤーとして前面化した
policy、identity、runtime、compliance、marketplace governance を別パッケージとして扱う姿勢がはっきりした。
Microsoft Agent Framework 1.0 は agents と workflows を本番向け SDK として固定した
sessions、middleware、checkpointing、human-in-the-loop を伴う運用前提が、抽象論ではなく標準機能になった。
AWS Agent Registry preview は、発見と承認を runtime の外に切り出して製品化した
agent、tool、skill、MCP server を approval workflow とメタデータ付きで扱う前提が公開面に出た。
Google は Agent Platform の公開 docs を作成・拡張・統制・最適化でそろえた
Agent Studio、Runtime、Identity、Gateway、Evaluation、Observability が同一の運用面として並び、比較軸が一気に読みやすくなった。
ここに Anthropic の eval harness と long-running harness の整理、OpenAI Agents SDK の sandbox、sessions、tracing を重ねると、 今週の変化はさらに明確になる。各社が競っているのは「より賢い応答」だけではなく、 人間が境界を定め、長時間動かし、途中で止め、失敗を追跡し、再利用しやすくする基盤そのものである。 だから今回の週次記事は単独テーマ記事ではなく、複数の公開面が一度にそろった週次総括として読む方が内容を正確に表せる。
4層の整理
今のエージェント基盤は、少なくとも作成・実行・統制・評価の4層で比較すると見通しが良い
1. 作成の層
まず必要なのは、エージェントをどう設計し、どこまで決め打ちで組むかである。Google は Agent Studio と ADK、 Microsoft は workflows と型安全な routing、OpenAI は handoffs と最小の primitives、 Anthropic は workflows と agents の切り分けを明文化している。ここでは「何を作れるか」より、 どの粒度で設計を固定できるかが差になり始めた。
2. 実行の層
次に必要なのは、長く動く仕事をどこで持続させるかである。OpenAI は sandbox agents と sessions、 Anthropic は long-running harness、Google は Agent Runtime と Memory Bank、AWS は AgentCore Runtime と Identity を出している。 ここでは「一度動くか」より、状態、権限、再開性、隔離実行をどう揃えるかが重要になる。
3. 統制の層
本番導入では、何を許可し、誰が承認し、どの境界で止めるかが必要になる。Google の Agent Gateway と agent identity、 Microsoft の middleware と Agent Governance Toolkit、AWS の Policy と Registry、Anthropic の permissions と security docs は、 いずれも統制を prompt の外へ出している。エージェントは自由度だけでなく、止め方の設計まで含めて比べる対象になった。
4. 評価の層
最後に必要なのは、何をもって改善とみなすかである。Anthropic はタスク、試行、採点器、実行記録、結果状態を分け、 OpenAI はトレーシングを標準化し、Google は評価ケース、トレース、指標、最適化を一体化し、 AWS は Evaluations と Observability を production monitoring に結びつけた。ここではモデル評価ではなく、 agent run 全体の品質をどう測るかが競争軸になっている。
観測点
今の AI エージェントは、単一モデルを包む UI ではなく、設計、実行、統制、評価がつながった運用基盤として読んだ方が現実に近い。
各社の差
同じ方向へ進んでいても、どの層を前面に出すかはかなり違う
OpenAI は、軽量な実行基盤と可視化を強く押し出す
OpenAI Agents SDK は agents、handoffs、guardrails という少数の要素を保ちながら、 sandbox、sessions、human in the loop、tracing を標準機能として持つ。特徴は、複雑な基盤を大きな control plane ではなく 開発者向け実行基盤として扱っている点にある。
Anthropic は、評価設計とハーネス設計を中心に据える
Anthropic の資料は、agent 自体よりハーネスと評価の設計を前に出す。タスク、試行、採点器、結果状態を分け、 long-running harness では initializer agent と incremental progress を使う。強みは、運用を始めた後の品質維持を 最初から設計課題として扱っている点である。
Microsoft は、agents と workflows の分離を製品の中心に置く
Agent Framework 1.0 は、LLM 主導の agent と、型付きで checkpointing できる workflow を明確に分ける。 さらに middleware と Agent Governance Toolkit で policy や compliance を外付けできる。 つまり Microsoft は、エージェントを推論体というより企業向けソフトウェア部品として見せている。
Google は、最も一連で読める製品語彙を与えた
Build、Scale、Govern、Optimize を同じ docs 面で並べ、Agent Studio、ADK、Runtime、Identity、Gateway、 Evaluation、Observability を一連の流れとして見せている。Google の特徴は、agent platform という言葉に 製品境界を与え、個別機能ではなく全体像で比較しやすくしたことにある。
AWS は、runtime より外側の catalog と policy まで運用面に含めた
AgentCore は Runtime、Gateway、Identity、Policy、Registry、Observability、Evaluations を分けて持ち、 特に Registry と Policy で承認と境界設定を強く前面化している。AWS の見せ方は、 「何を作るか」だけでなく「何を登録し、何を許し、どう監査するか」まで含めて agent platform と読むものだ。
業務フロー
この比較軸が効くのは、エージェントを試作品ではなく組織の運用対象として扱う場面である
社内調査・文書作成エージェント
- 基盤担当チームが承認済みの tool や MCP server だけを registry に載せる
- agent identity と policy で、読めるデータと書ける操作を分ける
- トレースと評価結果を残せない基盤は、導入後の説明責任が重くなる
長時間のコーディング・運用支援
- sandbox や secure runtime がないと、再開性と権限分離を両立しにくい
- session と progress artifact がないと、長い仕事ほど品質がぶれやすい
- human approval を途中で差し込めるかが、実務投入の分かれ目になる
複数部門での再利用
- agent や skill を catalog 化しないと、同じ業務ロジックが各部門で重複しやすい
- approval、deprecation、ownership metadata がないと、使ってよい資産が曖昧になる
- 今週の収束は、reuse を runtime の外で管理する方向を強めている
顧客向け運用と継続改善
- 本番後も safety、task success、tool use quality を継続評価する必要がある
- policy が agent code の外にある方が、修正と監査を切り分けやすい
- observability を持たない agent は、失敗しても改善点が追いにくい
まだ早いこと
ただし、公開面が整ったことと、現場の標準解が固まったことは同じではない
protocol 対応だけで統制は完成しない
MCP や A2A に対応しても、approval、revocation、least privilege は別レイヤーで設計し続ける必要がある。
low-code 化だけで本番品質は出ない
visual builder や studio があっても、task 定義、grader 設計、権限境界の詰めが弱いと品質は安定しない。
catalog があっても day-two 運用は残る
登録、承認、発見が整っても、変更管理、メモリ更新、コスト制御、障害解析までは別に回す必要がある。
評価自動化は task 設計に強く依存する
多くのベンダーが自動評価を前面化したが、良い grader と ground truth を持たないままでは、数字だけが先に立ちやすい。
結論
今週読むべき変化は、AIエージェントが「賢い機能」から「統制された運用基盤」へ商品定義を変え始めたことだ
2026年5月上旬の一次情報を横断すると、エージェントの競争軸は model leaderboard だけでは説明しにくくなっている。 実務で問われるのは、誰が設計し、どこで動かし、どの権限で接続し、どう失敗を測るかである。 各社の実装はまだ揃っていないが、比較する単位はすでに agent app から統制付き運用基盤へ移り始めた。
この変化は、エージェントを試す企業より、複数部門へ配る企業ほど重く効く。今後の導入判断では、 モデル性能表の次に、ワークフロー、承認、ポリシー、トレース、評価をどこまで標準装備で持つかを見る必要がある。 今週は、その読み方が主要ベンダーの公開面で共通化し始めた週だった。