AIエージェントはどこで動かす？ Cloud RunとAgent Runtimeの選び方
AIエージェントをGoogle Cloudへデプロイする段になると、「Cloud RunとAgent Runtimeのどちらに置くか」で手が止まることがあります。
名前だけを見ると、AIエージェントならAgent Runtimeを選ぶように思えます。ただ、Cloud RunでもAIエージェントは動きます。公式ドキュメントにも、Cloud Run上でエージェントをホストする構成が用意されています。
分かれ目は「AIエージェントかどうか」ではありません。アプリケーションとしてどこまで自分で組み立てたいのか、エージェント向けの管理機能までまとめて使いたいのか。ここで考えると整理しやすくなります。
この記事では機能の一覧を作るのではなく、構成を決めるときの選び方に絞って書きます。
- 1. Cloud RunでもAIエージェントは動かせる
- 2. Agent Runtimeはエージェント運用まで含めて考える
- 3. 迷ったら「何を自分で持つか」で考える
- 4. どちらか一つに統一する必要はない
- 5. まとめ
1. Cloud RunでもAIエージェントは動かせる
Cloud Runは、コンテナ化したアプリケーションを動かすサーバーレス基盤です。Web APIを置く場所という印象が強いかもしれませんが、公式ドキュメントにはCloud RunのリソースへAIエージェントをホストする案内があり、ADK、LangGraph、Difyといったフレームワークで作ったエージェントを載せる前提で書かれています。
分かりやすいのは、すでにあるWebアプリケーションへエージェント機能を足すケースです。画面、業務API、エージェントを一つのアプリケーションとして扱いたいなら、Cloud Runを中心に置けば今の構成をそのまま延ばせます。コンテナイメージ、環境変数、サービスアカウント、ネットワークまわりの運用も引き継げます。
社内の申請システムに問い合わせ対応のエージェントを足す、といった場面を想像すると分かりやすいと思います。認証も業務APIも既存のものを使うなら、エージェントだけ別の基盤へ切り出す理由は多くありません。
図1 Web画面や業務APIと一緒に、AI機能もCloud Runで動かせる
Cloud Runには用途の違うリソースタイプがあり、エージェントの動かし方で選べます。リクエストを受けて返すチャット型のエージェントはサービス、バッチ評価やデータ取り込みのように最後まで走って終わる処理はジョブ、キューからタスクを受け取り続ける常時稼働の処理はワーカープール、状態を持ったまま動き続ける常駐型のエージェントループはインスタンス（プレビュー）が候補になります。
種類を覚えることが目的ではありません。「Cloud RunはHTTPリクエストに答える場所だけではない」と分かっていれば、エージェントの形に合わせて置き方を変えられます。
2. Agent Runtimeはエージェント運用まで含めて考える
Agent Runtimeも、エージェントのコードを動かす場所です。公式にはフルマネージドで方針の定まったランタイムと説明されていて、インフラの作り込みを引き受ける代わりに、動かし方の形はある程度決まっています。
ADKとの統合が深く、LangChain、LangGraph、AG2、LlamaIndexはAgent Platform SDK経由で扱えます。ランタイムの決まりに沿ってコンテナ化すれば、独自のフレームワークやカスタムコンテナも配置できます。
ただ、実行できるかどうかだけを見ると、Cloud Runとの差は見えにくいままです。違いが出るのは、Agent Platformの周辺機能と組み合わせたときです。
図2 会話の状態、長期の記憶、動作の記録、品質の評価がエージェントにつながる
Agent Platformには、一つの会話の履歴と状態を扱うSessions、会話をまたいで利用者ごとの情報を残すMemory Bank、実行の流れをスパンの連なりとして追えるObservabilityとTrace、テストケースを走らせて品質を測るEvaluationがあります。
たとえばSessionsは、中断した会話を続きから再開させたいときに効きます。Memory Bankは、前回の会話で聞いた利用者の状況を次回も踏まえて答えさせたいときに使います。どちらも自前で作れないものではありませんが、保存先の設計、期限の管理、取り出し方まで含めて自分たちで面倒を見ることになります。
品質を測る仕組みも同じです。Evaluationは、テストケースを実行して結果をスコア化し、トレースで実際の動きを確認しながら直していく流れを想定しています。
Agent Runtimeを選ぶ理由は「AIエージェントが動くから」ではなく、会話の状態、動作の記録、品質の評価までAgent Platformの仕組みに預けたいから、と言い換えると判断しやすくなります。
3. 迷ったら「何を自分で持つか」で考える
既存のアプリケーションへAIを組み込みたい、コンテナやAPIの構成は自分たちで決めたい。この場合はCloud Runが候補です。会話履歴やメモリの持ち方も、自分たちのデータベースやキャッシュで設計することになります。
エージェントを中心にシステムを作り、会話の状態、長期記憶、トレース、評価まで一緒に回したい。この場合はAgent Runtimeが候補です。
図3 どこまで自分で持つかで、Cloud RunとAgent Runtimeを選び分ける
「Cloud Runが簡易版でAgent Runtimeが上位版」という関係ではありません。持つ範囲が違うだけです。Cloud Runは実行の仕方を自分で決められる代わりに、エージェント特有の状態管理や評価の仕組みは自分で用意します。Agent Runtimeは用意された仕組みに乗る代わりに、構成はランタイムの形に合わせます。
どちらに手をかけたいかで決まる、と考えると迷いにくくなります。すでにあるアプリケーション運用の延長で進めたいのか、エージェントの品質改善そのものに時間を使いたいのか、という違いです。
判断に迷ったら、会話の履歴と長期記憶をどこに置くつもりか、エージェントの良し悪しを誰がどう測るつもりかを先に決めてみてください。この2つを自分たちで設計する気があるならCloud Run、任せたいならAgent Runtimeに寄っていきます。実行環境の比較より、この答えの方が先に決まります。
4. どちらか一つに統一する必要はない
実際のシステムでは、両方を使う構成も自然です。利用者向けのWeb画面と業務APIはCloud Run、中心になるエージェントはAgent Runtimeに置き、APIから呼び出す。この形なら、既存の運用とエージェントの管理機能を両方使えます。
図4 Web・APIはCloud Run、エージェントはAgent Runtimeという分け方
反対に、AI機能が小さいうちは、Web APIとエージェントをCloud Runへまとめた方が見通しがよいこともあります。
Cloud Run側にも、Agent Identity、Agent Registryといった機能を有効化する仕組みが用意されています（どちらもプレビュー）。Cloud Runに置いたらAgent Platformと無関係になる、という切り分けでもありません。
Google CloudにはCompute Engine（GCE）やGoogle Kubernetes Engine（GKE）もあり、既存システムが動いている場所はさまざまです。すべてを一つの基盤へ寄せるより、アプリケーションの形と運用に合わせて置き場所を決める方が現実的です。
最初から「AIエージェントだからAgent Runtime」と決めず、どこまでをGoogle Cloudに任せたいかから考えると、選択肢を整理できます。
5. まとめ
Cloud RunとAgent Runtimeは、どちらもAIエージェントを動かせる環境です。
Cloud Runは、エージェントを含めたアプリケーション全体をコンテナとして構成したいときに扱いやすい基盤です。Agent Runtimeは、実行に加えてSessions、Memory Bank、Observability、Evaluationといった仕組みと一緒にエージェントを育てたいときに向いています。
決め手は優劣ではなく、アプリケーションとして管理する範囲と、エージェントとして管理する範囲をどこで分けるかです。ここが決まっていれば、片方に寄せる構成も、組み合わせる構成も、後から理由を説明できます。