AIエージェント基盤は何を引き受けるか：五社を一件の業務で比べる

便利な回答を、一件の仕事として任せられるか

社内の問い合わせを読み、担当部署を提案するAIは作れた。 ところが、確認した内容がチケットへ保存されたか分からず、担当者が画面を開いて調べ直している。 ここで不足しているのは文章の上手さか、保存処理か、それとも確認後の引き継ぎか。 基盤選びでは、この違いが問われる。

これは仕組みを考えるための想定例であり、特定企業の導入結果ではない。 2026年5月7日までのOpenAI、Anthropic、Microsoft、Google、AWSの一次情報を比較すると、モデルを呼び出すSDKから、実行、権限、登録、評価を管理するサービスまで、提供される範囲に違いが見える。 同じ「エージェント基盤」でも、買うものと開発するものは揃っていない。

私が重視するのは、判断、確認、保存、失敗の調査を一件の業務としてつなげられるかである。 モデルの理解力を測ることに加え、利用チームが残された処理と保守を引き受けられるかを見たい。 五社の発表は、その問いを具体化する材料になる。

OpenAI：SDKで実行を組み立てると、何が残るか

OpenAIの4月15日のAgents SDK拡張の発表は、モデルの指示を道具の実行へつなぐ仕組みと、隔離した作業環境を扱う。 実行状態を外へ保持し、スナップショットで作業環境を引き継ぐ設計も示した。 まずPythonへ提供し、TypeScript対応などは今後の予定としている。

問い合わせ業務に当てはめると、SDKは読む、提案する、道具を呼ぶ流れを組み立てる手段になる。 しかし、「契約の質問はどの部署へ送るか」「この利用者がこの案件を変更できるか」は会社のルールである。 作業環境を保存できても、担当部署の正しさやチケットへの保存成功までは決まらない。

この方式の利点は、既存のAPIや確認画面に合わせて処理を設計できることだ。 一方、開発側は道具の接続、保存の確認、変更後の検証まで保守する必要がある。 SDKの柔軟さを評価するなら、自分たちが扱える実装量も同時に見積もるべきだ。

Anthropic：長く動かす仕組みと、完了を確かめる仕組み

Anthropicの2025年11月26日の長時間実行の検討は、Webアプリ開発で、途中の作業が伝わらない、未完成なのに完成と判断する問題を扱った。 初回に機能一覧を作り、後の実行が一機能ずつ進め、進捗とGit履歴を残し、実際の画面で確認する構成を示している。 これは同社の開発例であり、あらゆる業務の成功率を証明した比較実験ではない。

重要なのは、長い会話を保つだけでは、何が済んだか分からないことだ。 問い合わせ業務でも、提案済み、確認待ち、保存済みを区別できなければ、人が記録を読み直す。 「前の実行がどうなったか」を調べる負担を減らすには、実際の結果に結びついた進捗が必要になる。

4月8日のManaged Agentsの設計説明は、イベント履歴を持つセッション、モデルと道具を動かす仕組み、隔離環境を分離する。 実行環境の交換と履歴の保持を別に扱う構成だ。 ただし、履歴が残ることから、接続先のチケットが正しく更新されたとは判断できない。

管理サービスに実行の継続を任せても、業務の完了条件は利用側が定義する。 中断後に人が引き取るなら、最後の提案だけでなく、保存結果や未確認の処理を渡せるかを見る。 「動き続ける」と「仕事が終わる」の間を埋める責任は残る。

Microsoft：判断と固定手順を組み合わせ、実行前に介入する

Microsoftは4月3日、.NETとPythonのAgent Framework 1.0を発表した。 安定した機能として、モデルを使うエージェント、関数や分岐を組み合わせる処理、チェックポイント、実行へ介入するミドルウェアを挙げる。 同じ記事でも、Foundryへの管理済み実行や評価の統合はプレビューとして区別されている。

この組み合わせなら、問い合わせの意味を読む部分はモデルに委ね、案件番号の照合や保存前の確認は決められた手順へ置ける。 自由な判断が必要な箇所と、毎回同じ条件を守る箇所を一つの処理にできる点が比較の対象になる。 SDKの安定版という説明を、組み合わせる全サービスの安定性へ広げてはいけない。

4月2日のAgent Governance Toolkitは、実行前の方針確認、身元、実行の管理などを別々に導入できるパッケージとして示した。 既存のフレームワークの介入箇所へ接続する構成で、モデルへの指示とは別に制御を置く設計を説明している。

方針を書く場所があっても、業務APIへ至る経路に確認が入らなければ強制できない。 私は、採用時には許可されない案件を実際の接続経路から指定し、保存に到達しないことを確認すべきだと考える。 ここで引用した発表は、その接続試験や全経路の強制を本記事が検証した証拠ではない。

Google：作成から運用改善までを束ねる

Googleの4月22日のGemini Enterprise Agent Platform発表は、作成、規模の拡大、統制、改善の四つに機能を整理した。 実行環境に加え、身元、登録簿、接続のゲートウェイ、シミュレーション、評価、観測を一つの基盤として説明する。 開発後に必要になる管理も、製品の比較範囲に含めている。

一体化した管理画面や接続は、複数の処理を運用するチームにとって検討材料になる。 ただし、登録簿は何が使えるか、身元は誰が動くか、ゲートウェイはどこへ接続するか、評価は結果がどうだったかを扱う。 一つの製品内でも、これらは別の問いに答える。

私は、チケット一件を通して、その情報を追えるかを確かめたい。 提案した部署、確認した人、保存先、保存結果がつながれば、担当者は何を調べればよいか分かる。 発表が述べる安全性や成果の保証はベンダーの説明であり、利用企業の既存APIまで含めた正確さや調査時間の実測ではない。

AWS：公開の承認、操作の許可、結果の採点を分ける

AWSの4月9日のAgent Registryプレビューは、エージェントや道具の所有者、機能、呼び出し方を登録する。 下書きから承認待ち、承認済みへ進み、社内で発見可能にする手順と、記録の版や廃止を説明している。 これは使える資産を公開する承認であり、チケット一件を書き換える承認とは役割が違う。

3月3日に一般提供となったAgentCore Policyは、エージェントのコードの外に方針を置き、関連づけたGatewayで要求を検査する。 ここでは、接続された道具の実行を許すかが対象になる。 利用側は、その経路に必要な操作が通ることと、接続先の案件ごとの権限をどう扱うかを確認する必要がある。

3月31日のAgentCore Evaluations一般提供は、本番の実行記録を抽出して採点するオンライン評価と、変更を試すオンデマンド評価を区別する。 期待する回答や道具の順序との比較、独自の採点も説明している。 採点は改善材料になり得るが、実行前の拒否とは別の働きだ。

この三つを分けると、会社として利用を認めたエージェントでも、ある案件には書き込みできず、許された操作でも分類を間違え得ることが分かる。 承認、許可、品質を一つの点数で代用しない方が、失敗を直す場所を選べる。 Registryの今後の自動登録や運用情報との統合は、プレビューで使える機能と区別して導入を判断したい。

比較を、一件の問い合わせに戻す

各社の範囲が分かったら、想定したチケット処理を候補の構成へ当てはめる。 比較したいのは、同じ機能名を持つかより、必要な処理がどこで実施されるかだ。 次の四項目は、そのための整理であり、製品共通の仕様ではない。

案件の照合や承認を既存のチケットシステムが担うなら、そこを利用できる。 新しい基盤へ移す部分と、既存の処理を残す部分を具体的に決めると、必要な開発も見えやすい。 確認した内容を保存までつなぐには、両者の間で案件や内容が変わった場合の扱いも必要になる。

この整理は、業務を必ず四つのサービスへ分割する提案ではない。 一つの既存APIが複数の条件を満たすこともある。 重要なのは、処理が止まったとき、人がどの記録を見て次の行動を決められるかである。

モデルの誤りと、基盤の不備を同じ点数にしない

比較試験では、部署の選択を間違えた、許可のない案件へ保存した、接続先が停止した、保存結果が分からないまま終わった、を分けて記録する。 理解の誤りには参照する正しい分類が必要だ。 許可の誤りには、利用者、確認内容、実際の更新を照合する記録が必要になる。

Anthropicの評価の解説は、実行の記録と最終結果、採点方法の限界を区別する。 この考え方に沿うなら、正しい部署を回答しただけでチケット業務を成功とせず、許された内容が保存されたかまで見る。 「実行が終わった」と「期待した結果が残った」を分けることが出発点になる。

モデルの差を知りたい試験では、問い合わせ、道具、権限、時間や費用の条件を揃える。 製品全体を選ぶ試験では、その製品で必要になる準備、確認、待ち時間、失敗後の調査も含める。 同じ試験から、モデルの優劣と製品の使いやすさを無条件に説明できるわけではない。

私は、人が何件を修正し、何件を調べ直したかも残すことを勧める。 提案の精度が高くても、毎回保存を確かめるなら負担は別の場所へ移る。 これは比較試験の提案であり、五社について負担や成功率を測定した結果ではない。

必要な管理だけを増やす

Anthropicの設計指針は、簡単な方法から始め、必要に応じて複雑さを加えることを勧める。 既存のチケットシステムに承認と監査があり、一部署で使うだけなら、SDKと限定したAPIの接続で要件を満たせるかを先に試せる。

複数部署で処理を共有し、実行が長くなり、担当チームも増えるなら、身元や登録、実行記録をまとめて管理する価値を検討しやすくなる。 ただし、集中管理を買えば保守がなくなるわけではない。 部署のルール、接続先の変更、確認する人、採点の基準は更新し続ける必要がある。

費用を比べる際は、モデルや実行の料金に加え、接続を作る作業、権限の設定、記録の保管、採点、担当者による調査も含める。 管理サービスで削減できる部分と、利用側に残る部分を書き分ける。 その上で、既存の担当者が維持できる構成を選びたい。

引き受けられる責任で、基盤を選ぶ

五社の資料は、SDK、長時間実行、固定手順、管理サービス、評価を具体的に比較する材料を増やした。 ただし、機能の並びが似ていることから、実装や業務の成果まで同じとは言えない。 モデルの性能が重要でなくなったと読む根拠でもない。

問い合わせを誤解するなら、モデル、入力、担当ルールを改善する必要がある。 正しく理解したのに保存結果が分からないなら、実行と接続先の確認を直す。 誰の権限で動いたかを追えないなら、身元と許可をつなぐ設計を見直す。 困っている担当者にとって、この切り分けが次の改善を選ぶ手がかりになる。

私の判断は、一件の業務を最後まで試し、基盤が提供する処理、既存システムが保証する条件、利用チームが保守する仕事を明確にして選ぶ、というものだ。 良い回答を作れることから始め、失敗したときにも人が結果と次の行動を判断できる構成へ進めたい。