AIエージェントの開発手法において、インフラ管理をプロバイダー側に委ねるマネージドエージェントへの移行が急速に進んでいる。従来の単発の応答から、数分から数時間に及ぶ長期的なタスクの実行へとエージェントの役割が変化する中、コード実行環境のサンドボックス化や状態の永続化、認証情報の管理といった複雑なインフラ構築が開発者の大きな負担となっていた。本内容では、この課題を解決するアプローチとして先行するAnthropicと、Gemini APIで追随するGoogleの設計思想の違い、具体的な機能差、そして今後のエージェント開発に与える影響について解説する。
マネージドエージェントが注目される理由
マネージドエージェントについてお話ししましょう。これは間違いなく大きなトレンドになります。GoogleはGemini APIにアンチグラビティ2.0の一環としてマネージドエージェントを組み込んできました。これはAnthropicが最初のバージョンをリリースし、猛烈な勢いでアップデートを続けていることに追従した形です。
現在、エージェントは1回限りの応答から、数分あるいは数時間も実行されるような長期的なタスクへと移行しています。もしあなたがまだそのような作業のために独自のエージェントループを自前で構築しているなら、このパターンに注目する必要があります。業界全体がこの方向へと収束しつつあるからです。
この動画では、マネージドエージェントとは一体何なのか、それがどのような課題を解決するのか、そしてGoogleとAnthropicの実装がどのように異なり、エージェントを開発する上でなぜこのカテゴリーが重要なのかを詳しく見ていきます。
簡単に説明すると、マネージドエージェントとは、エージェントのループ処理を代わりに実行してくれるホストされたランタイムのことです。開発者は、モデル、システムプロンプト、そしてツールというエージェントの構成要素を定義してメッセージを送信するだけです。プラットフォーム側がそれ以外のすべてを処理してくれます。
そして、そのそれ以外の部分こそが、最も時間がかかる部分なのです。エージェントの実行時間が長くなればなるほど、これらは難しくなります。コードを実行するためのサンドボックスを起動し、ツールの呼び出し間で状態を維持し、コンテキストウィンドウを管理しなければなりません。さらに、エラー処理や再試行、OAuthの更新、ネットワークの外部接続、時にはコンテナの分離まで考慮する必要があります。
モデルやツールの定義自体は最も簡単な部分です。実際に最も重要で大変なのは、それ以外のオーケストレーションの部分なのです。マネージドエージェントは、これらすべてをプロバイダー側のサンドボックスに移行させます。プロバイダーがリカバリロジックを含むセッション状態を管理し、開発者はイベントのストリームと最終的な出力を受け取るだけになります。
Anthropicはこのカテゴリーを3つの要素に分解して表現していますが、これは非常に分かりやすい考え方です。
1つ目はブレイン、つまりモデルとその意思決定ループです。これはステートレスなので、セッションを失うことなく再起動が可能です。
2つ目はハンズ、つまりサンドボックスとツールです。これらは一時的なもので、使い捨てが可能です。どれかが失敗しても、プラットフォームが新しいものを起動してセッションを継続します。
3つ目はセッション、つまり何が起きているかを正確に記録する永続的なアペンドオンリーのログです。最も重要なのは、これがモデルのコンテキストウィンドウの外側で維持される点です。もしブレインがクラッシュしても、新しいブレインを立ち上げてこのセッションを渡せば、最後に記録されたイベントから処理を再開できます。
これら3つの要素を切り離す設計こそが、特に長期実行されるワークロードにおいて、ランタイムに強靭性をもたらす鍵となります。そして、マネージドエージェントが単なる機能ではなく、真の製品カテゴリーである理由は、プロバイダーが現在提供しているのがもはやモデルそのものではなく、ランタイムであり、そのモデルの上に構築される製品そのものだからです。そこにマネージドエージェントの価値があります。
自前での開発が直面する具体的な課題
では、これらの課題が実際にどのようなものか、具体的に見ていきましょう。
まずはコードの実行です。エージェントは、BashコマンドやPythonなど、エージェント自身が書くと決めたスクリプトを実行する必要があります。サンドボックス化しない限り、そのコードはあなた自身のインフラストラクチャ上で実行されてしまいます。そのために必要なものを挙げると、セッションごとのコンテナ、エージェントが読み書きできるファイルシステム、パッケージマネージャー、ネットワークポリシー、そしてセッション終了時にすべてを綺麗に強制終了する方法などが必要です。
次に、長期実行されるエージェントにおける状態の永続化です。長期のエージェントは、単一のAPI呼び出しではなくループ処理です。このループの中で、モデルはどのツールを呼び出すべきかを決定し、結果が返ってくると、モデルは再び決定を下します。もしこのループが途中でクラッシュしたと想像してみてください。最初からやり直すのではなく、中断したところから再開したいはずです。そのためには、モデルのコンテキストウィンドウの外側に存在し、コンテナの再起動後も存続する、アペンドオンリーのイベントログが必要になります。重要なのは、これらを独立したものとして扱う関心の分離という考え方です。
さらに、エージェントが使用する認証情報の問題もあります。エージェントがユーザーの代理として、例えばSlackに投稿したりGitHubを読み取ったりする場合、OAuthトークンが必要になります。トークンが失効したときに更新する方法や、それらをサンドボックスの外部に保管する方法も必要です。そうしないと、プロンプトインジェクションによって漏洩する危険があります。また、ユーザーのアイデンティティを考えるのと同じように、エージェントのアイデンティティについても考える必要があります。
これらを適切に構築するには数週間、安定させるには数ヶ月かかるでしょう。
4つ目の課題は、エラーからの回復です。セッションが長くなればなるほど、問題が発生する確率は高くなります。ネットワークの一時的な瞬き、コンテナのメモリ不足、あるいは現在の世代のモデルでよくあるレートリミットへの到達などが考えられます。もしこれらを制御する仕組みがメモリ上だけに存在していると、1つのエラーでセッション全体が終了してしまいます。解決策は、セッションをステートレスにし、状態をイベントログに押し出すことです。これはアーキテクチャにおける全く新しい考え方であり、単なる設定の調整レベルの話ではありません。
ここで重要なのは、これらインフラの構築は、エージェント開発において全く面白い部分ではないということです。すべてが単なる配管作業です。だからこそ、プロバイダー側がこれを吸収しようとしています。インフラはエージェントの進化に合わせて変化し続けるため、開発者がその部分を心配する必要をなくすためです。どの企業も同じ配管を一から作っている状態なので、エージェントプロバイダーはマネージドエージェントという形でその配管を提供しているのです。
N8Nによるワークフロー構築の効率化
ここで、少し本編を離れて便利なプラットフォームをご紹介します。オートメーションワークフローを構築するためのプラットフォーム、N8Nです。
ノードを繋ぎ合わせることで、各ノードが特定の処理を行い、全体としてエンドツーエンドで動作します。N8Nのクラウド環境、またはセルフホスト環境で実行可能です。最近、独自のMCPサーバーがリリースされ、あらゆるコーディングエージェントからワークフローを作成・編集できるようになりました。MCPサーバーを設定すれば、エージェントに対して指示を出すだけで、ワークフローを反復的に改善し、テストすることができます。これを利用するには、設定でインスタンスレベルのMCPを有効にする必要があります。
今回の例では、Claudeを使用します。すでにN8NのMCPサーバーを接続してあります。ここでClaudeに対し、ウェブフックのポストボディからトピックを受け取り、arXivから最新の論文を、Hacker Newsから最新の記事を、GitHubからトレンドのリポジトリを並列で取得し、それらをAIエージェントで短い要約にまとめるN8Nワークフローの構築を依頼します。
指示を送信すると、ClaudeはMCPサーバーだけを使ってワークフロー全体を構築してくれます。生成されたワークフローを確認すると、すべてのノードがClaudeによって接続されています。このワークフローのテストと検証を依頼することも可能です。
すべてのノードが正常に実行されたようです。提供されたリクエストに基づいて、エージェントがどのような応答を生成したかも実際に確認できます。テストの過程でarXivにレートリミットがあることが判明した場合、エージェントはMCPサーバーを介して、正常に動作するまでワークフローを更新し続けることができます。
現在、リクエストを送信できる状態になっているため、これを任意のアプリケーションに統合し、どこからでもワークフローをトリガーできます。例えば、データの永続性を持たせたいとします。APIを呼び出すたびに、調査履歴と要約自体をこのテーブルに保存したい場合、Claudeにその実装を伝えるだけで、ワークフローに戻って編集を行ってくれます。クエリは正常に実行され、データを確認すると、指定した要約や保存を求めたカラムがしっかりと格納されています。これはセッションをまたいで保持されます。
N8Nのクラウドで実行されているため、任意のアプリケーション内のどこからでもトリガー可能です。試してみたい方は、説明欄に無料トライアルのリンクと1ヶ月無料のクーポンがあります。ワークフローのテンプレートもリンクされているので、ワンクリックで自身のインスタンスにインストールできます。
AnthropicとGoogleの実装アプローチの比較
それでは本編に戻りましょう。両社ともマネージドエージェントを提供していますが、その実装は大きく異なります。特に差が顕著に現れている4つのポイントを説明します。
まずはAPIです。Anthropicでは、エージェントを作成し、環境を作成し、セッションを作成してから、その特定のセッションにイベントを送信します。つまり、4つの異なるエンドポイントを持つ4つのリソースが存在します。素晴らしいのは、これらが再利用可能であり、エージェント自体がバージョン管理されているため、アップデートを適用できる点です。セッションからは、エージェントのメッセージ、ツールの使用、エージェントのステータスといった型定義されたイベントがストリームとして返され、実行途中で割り込むことも可能です。新しいメッセージでエージェントを誘導したり、実行の合間にツールやMCPサーバーを更新したりできます。
一方、Googleの場合はシンプルな1回の呼び出しです。エージェントID、インプット、および環境パラメータを指定して、 interactions.create を呼び出します。エージェントが計画を立て、実行し、ツールの結果を確認するループを、全体の処理が終わるまで自動で繰り返し、最終的な出力を返します。同じサンドボックスを再利用したい場合は、次の呼び出しで同じ環境IDを渡します。これが全体の仕組みです。
つまり、Anthropicはコントロールのための多くのノブを提供しているのに対し、Googleは開発者が関与できる部分が少ない、非常にシンプルなアーキテクチャを目指しています。同じ思想に基づきながらも、賭けている方向性が真逆なのです。
次に大きな差があるのがツール群です。Googleのバージョンはリリースからまだ1週間、Anthropicは5〜6週間が経過している点に留意してください。Anthropicは、あらかじめ構築されたフルセットのツール群を提供しています。バックエンドにはBash、ファイル操作、ウェブ検索、ウェブフェッチがあり、第一級のMCPをサポートしているほか、クライアント側で定義して実行するカスタムツール、さらにはExcelやPDF用の構築済みスキルも備わっています。その上、ユーザーごとのOAuth認証情報を管理・更新してくれる「Vaults」という機能もあります。
これに対して、Googleのインテグリティエージェントが提供するのは、コード実行、Google検索、URLフェッチ、およびファイルシステムです。現時点ではこれだけです。現段階では、このエージェント用のMCPやカスタムファンクションコーディング、Vaultsなどは存在せず、多くの機能が欠けています。ただし、これには少し裏話があるので、後ほど詳しく説明します。
現時点でAnthropicはマネージドエージェントを取り巻くエコシステム全体を提供しているのに対し、Googleはまさにスタートしたばかりと言えます。
基本的なループに加えて、AnthropicはGoogleがまだ持っていない3つの機能を備えています。
1つ目はメモリ、つまりセッションをまたいで永続化され、書き込みごとにバージョン管理されるデータストアです。
2つ目はアウトカム、つまりエージェントに評価基準（ルーブリック）を与える機能です。プラットフォームが別の評価器を起動して成果物をチェックし、エージェントに改善を指示します。
3つ目はドリーム、つまり過去のセッションを読み込んでメモリをより綺麗な形に整理・統合する非同期ジョブです。これらは非常に興味深いアイデアであり、今後他のマネージドシステムにも取り入れられていくでしょう。
次に、実行環境とコストについて見ていきます。どちらの企業もインフラを代わりに管理してくれます。
Anthropicは、ホストされたクラウドコンテナに加えて、セルフホスト型のサンドボックスオプションを提供しています。これは、オーケストレーションはAnthropic上で行い、ツールの実行自体は自社のインフラに移動させる仕組みです。データの居住性やコンプライアンスの制約がある場合にこれが重要になります。現時点でGoogleはクラウドのみで、セルフホストのオプションはありません。
価格設定について、Anthropicは標準的なトークン料金に加えて、アクティブなセッション1時間あたり8セントを課金します。Googleはトークン料金のみで、プレビュー期間中はサンドボックスの計算リソースは無料です。
これは一見、Googleの方が安価に構築できるように見えますが、エージェントのループは長時間実行される可能性があり、数百万トークンを消費することもあります。そのため、1回あたりの実際のコストは、エージェントが何を行うかに大きく依存します。
Googleのエンタープライズ版と両社の戦略的違い
これまで述べた内容は、Gemini APIを通じて直接アクセスできる、Googleのコンシューマー向けのアンチグラビティエージェントに関するものです。しかし実は、Googleはもう1つのマネージドエージェント製品を「Gemini Enterprise Agent Platform」上で提供しています。これは水面下で同じアンチグラビティの仕組みを使用していますが、機能セットはAnthropicが提供しているものに非常に近いです。これはドキュメントを読み進めて見つけたもので、公式のリリースでは明示されていませんでした。
このエンタープライズ版には、MCPサーバーのサポート、OAuthベースの認証マネージャー、Anthropicのメモリ機能によく似たメモリバンク、カスタムスキル用のスキルレジストリ、そして複数エージェントの協調を可能にするエージェント間フレームワークが含まれています。
ただし、これは現在プライベートプレビュー段階、つまり実質的にプレGAの状態です。Googleは明示的に、まだ機密データを使用しないよう求めています。
つまり、両者の間を行き来できる同じエージェント定義が存在しているわけです。今日時点でAnthropicと同等の機能を求めるのであれば、実際に選ぶべきはエンタープライズ層となります。Gemini APIバージョンは、ほとんどの開発者が最初に触れるシンプルな製品という位置づけです。
要約すると、同じ問題を解決するために、非常に異なる2つの哲学を持つ2つの製品が存在しています。どちらが勝者になるかはこれからの展開を見守る必要がありますが、より重要なのは、これがユーザーである皆様にとって何を意味するのかという点です。
APIの詳細から一歩引いて考えてみましょう。この比較の本質は機能の一覧表ではなく、AnthropicとGoogleが、マネージドエージェントのあるべき姿に対して全く異なる賭けをしているという点にあります。
Anthropicの賭けは「深さ」にあります。エージェントをバージョン管理されたリソースとして設計し、環境に紐付け、セッションを実行してイベントをストリームで受け取ります。すべての概念に独自のエンドポイントが用意されています。プラットフォームは、認証情報、メモリ、評価、複数エージェントの協調といった仕組みを、それぞれ独立した第一級のリソースとして公開し、開発者がそれらを組み合わせて構成できるようにしています。その代償として、開発者はより多くの概念を学習する必要があります。しかし、ユーザーごとのOAuth Vaultsや、バージョン管理されたセッション間メモリを備えているのは、現在の市場でこの製品だけです。彼らはコンポーネントを仮想化し、安定したインターフェースを公開し、運用レイヤー全体を吸収することで、エージェントのランタイムをまるでオペレーティングシステムのように扱っています。
これに対してGoogleの賭けは「シンプルさ」です。エージェントID、インプット、環境を指定して interactions.create を呼び出すだけで、システムが単一の自律ループですべてを処理します。独立したセッションはなく、環境はIDによって保持されますが、呼び出し自体は単一の単位として完結します。この場合のカスタマイズはJSONではなくMarkdownファイルで行われます。その代償として、彼らのプラットフォーム上にはまだ存在しない機能カテゴリーが数多くあります。現時点ではMCPも、カスタムツールも、認証情報を保存するVaultsも、メモリもありません。これらのほとんどは先ほど触れたエンタープライズ層で利用可能になる予定ですが、そちらはまだプレGAです。
市場の動向を分析すると、Anthropicはエージェントランタイムの「深さ」で勝負しています。彼らはエージェントの運用レイヤー全体を吸収し、それらの要素すべてをAPIの第一級のプリミティブにしたいと考えています。対するGoogleは、圧倒的な「シンプルさ」で勝負しています。APIもモデルも、軽快に動作するように設計されています。Flashモデルは他の最先端モデルよりも約4倍高速に動作しますが、これはエージェントが長いループを実行する際に非常に重要となります。
ただし、価格設定は表面的な見出しよりも複雑です。トークン単位で見ればFlashはOpusよりも安価ですが、Gemini 3.5 Flashは、前世代のFlashに比べてトークン単価が数倍に上がっています。そして、これらのエージェントループは1回の実行で300万から500万トークンを消費することがあります。そのため、GoogleのFlashであっても、そのスケールでは1回のインタラクションあたり約5ドルに達することになります。したがって、トークン単位で安いからといって、必ずしも1回あたりの実行コストが安くなるとは限りません。彼らの狙いは、スピード、シンプルなAPI、そして低いトークン単価が合わさることで、実際の実行コストがエージェントの挙動に大きく依存するとしても、最終的に勝利を収めることができるという計算のようです。彼らは、単一のシンプルなAPI呼び出しを、それがエージェントであることを意識させないほど洗練されたものにしようとしています。
これらは単なる段階的な製品の差異ではありません。エージェントの価値がどこから生まれるかという、2つの異なる理論の対立です。Anthropicは、ランタイムそのものが製品であり、モデルはその内部のエンジンであると主張しています。Googleは、モデルが十分に高速でAPIが十分にシンプルであれば、ランタイムは単一の呼び出しの中に消え去るべきだと考えているのです。
開発者にとって、これは何を意味するのでしょうか。もしあなたの製品の差別化要因が、エージェントの動作、保有するツール、保持する認証情報、目標に向かって反復するプロセスそのものにあるなら、今日のAnthropicはまさにそのために構築されたプラットフォームです。Googleはその逆の選択肢となります。エージェントが何を生み出すかによって差別化を図り、今日最もシンプルな経路で製品を出荷したいと考えている開発者向けです。
開発者が考慮すべきベンダーロックインと今後の展望
そして、最も考慮すべきであり、多くのチームが見誤りがちなのが、分かりやすい意味でも、そうでない意味でも生じる「ベンダーロックイン」のリスクです。
分かりやすい意味でのロックインとは、AnthropicのAPIはGeminiでは動作せず、その逆もまた然りという点です。どちらかを選択するということは、そのプロバイダーのロードマップ、価格設定、レートリミット、可用性に自社の命運を委ねることを意味します。
より分かりにくく、かつ実際に本番システムを崩壊させる原因となるのが、もう一つのロックインです。これらはそもそも非決定的（確実ではない）システムである上に、単一のプロバイダー内であっても、水面下で基礎となるモデルが変化していきます。最先端のAI研究所は、内部でシステムプロンプトを更新し、モデルを量子化してより高速かつ安価に動作させ（と言われていますが）、安全性のために挙動を再調整するといったサイクルを、開発者に見えないところで常に回しています。
これらの一つひとつが、エージェントの挙動を変化させる可能性があり、時には研究所自体が予期しない形で影響が出ます。このような事態は何度も繰り返されてきました。研究所がコストやスピードのために最適化されたバージョンのモデルをリリースした結果、下流のシステムで測定可能な性能低下が発生するケースです。ツールの呼び出し精度が悪化したり、思考の連鎖が短くなったり、先週まで動いていた特定のタスクが突然失敗し始めたりします。
厄介なのは、これらの変更が変更履歴（チェンジログ）には一切記載されない点です。開発者が気づくのは、評価指標がブレ始めたり、ユーザーから苦情が出始めたりしたときだけです。マネージドエージェントのプラットフォーム上で構築するということは、単にAPIの仕様に縛られるだけでなく、基礎となる挙動が変化していくこと、そしてそのタイミングや方法を自分ではコントロールできないことを受け入れるという意味でもあります。
この点を念頭に置いて開発を進めてください。評価のための仕組みをしっかりと構築し、出力を長期的に追跡し、モデルの挙動に関する前提をシステムの重要な部分に直接埋め込まないようにすることが大切です。
その他のトレードオフは簡潔です。どちらの製品も設計上、状態を保持する（ステートフルである）ため、現時点ではデータ不保持（ゼロデータリテンション）やHIPAAの業務提携契約の対象外となっています。また、どちらもまだプレビュー版またはベータ版であるため、価格設定や機能セットが変更される可能性があります。
しかし、より大きな視点で見れば、これが最先端プロバイダーがエージェント機能を提供する際のデフォルトの方法になりつつあるということです。Anthropicが先陣を切り、Googleがそれに続き、AWSやOpenAIも独自のバージョンを携えてすぐ後ろに控えています。
単一のAPI呼び出しよりも長く実行されるものを構築する場合、次に直面する問いは「それを実行するのは自分たちか、それともプロバイダーか」という点になります。エージェントを構築している方は、どちらの道を進むか、Googleのシンプルさか、Anthropicの深さか、あるいは自前で構築するか、ぜひ意見を聞かせてください。
コメント