10月20日、InfoQが「Beyond the Prototype: Scaling Framework Agnostic AI Agent Infrastructure with Ray」と題した記事を公開した。LangGraph・LlamaIndex・AutoGenといったエージェントフレームワークが乱立する今、「どのフレームワークを選んでも通用するインフラ基盤」をRayで構築するという設計思想は、本番運用に踏み出せないチームが見落としがちな視点を正面から突いている。AIエージェントのプロトタイプから本番Kubernetes環境へのスケールを題材に、実践的なアーキテクチャと運用知見が詳しく紹介されている。

なぜ今このテーマが重要か

2025〜2026年にかけて、LLMを活用したAIエージェントの実用化は急速に進んでいる。LangGraph・LlamaIndex・AutoGenといったフレームワークはそれぞれ独自のオーケストレーション機構を持ち、プロトタイプ開発のハードルは大きく下がった。しかし「プロトタイプは動いたが本番に持っていけない」という声は依然として多い。スケーリング・耐障害性・可観測性といったインフラ層の課題は、フレームワーク側では解決されないからだ。本セッションはその空白を埋める内容となっている。

フレームワーク非依存という設計思想

タイトルにある「Framework Agnostic」は、このセッション全体の核心だ。LangGraph、LlamaIndex、AutoGenなど乱立するエージェントフレームワークに依存せず、Ray Serveの上に乗せる形で本番インフラを構成する——特定フレームワークへのロックインを避けながら運用基盤を統一できる。

エージェントフレームワーク選定はプロジェクトの要件次第で変わるが、スケーリング・観測性・耐障害性といったインフラ層の関心事はRayで分離して扱うという設計は、実際の開発現場での意思決定コストを下げる。この「インフラ層とオーケストレーション層の分離」という思想を前提に置いた上で、以降の技術的詳細を読むと理解が深まる。

プロトタイプから本番へ——何が壁になるのか

LLMを使ったAIエージェントのプロトタイプを作るのは難しくない。問題はその先だ。FastAPIで包んでKubernetesにデプロイする——一見すっきりした構成だが、エージェントならではの特性がすぐに壁になる。

本セッションの登壇者であるDeepaKumar ChandramouliとBhumik Vinodkumar Thakkarは、旅行プランナーエージェント（Trip-Planner） を題材に、プロトタイプから本番運用まで一気通貫で解説している。このエージェントは「目的地検索」「天気取得」「旅程合成」の3ツールをLLMが自律的にオーケストレーションする構成だ。

素のKubernetesでは何が足りないか

登壇者が整理した「本番デプロイに必要な要件」は、見落とされがちな点まで踏み込んでいる。

キャパシティ・スケーリング
エージェントのワークロードは通常のREST APIと異なる。CPU・メモリだけでなく、並列実行中のリクエスト数を基準にオートスケールしなければならない。LLMへのAPIコール、並列ツール呼び出し、ステートフルな多段ターン——これらが重なると、単純なHTTPリクエスト数でのスケーリング指標は機能しなくなる。

プロトコルの多様性
短いRESTレスポンスだけでなく、長時間実行されるエージェントにはServer-Sent Events（SSE）やストリーミングが必要になる。さらに「深い調査タスク」のようなバックグラウンド処理には非同期ジョブの投入・状態照会APIも求められる。

フォールトトレランス
インフラ層（ノード障害）とアプリ層（メモリリーク、クラッシュループ）の両方に対する耐障害性を最初から組み込む必要がある。

可観測性とガードレール
LLMのトークン使用量、ツール呼び出し回数、非決定的なオーケストレーションの追跡——同一クエリでも毎回異なる実行経路をたどる可能性があるため、分散トレーシングが不可欠だ。安全ガードレールはリクエスト受信・プランニング・結果集約の各フェーズに埋め込む必要がある。

これらの要件は相互に独立しているわけではない。スケーリングが不十分であれば可観測性データが偏り、耐障害性がなければストリーミング接続の維持も危うくなる。素のKubernetesはこれらを個別に解決する手段は提供するが、エージェントワークロード向けに統合してはくれない——そこにRayが入り込む余地がある。

Rayが解決するもの

Rayはオープンソースの分散コンピューティングフレームワークで、MLワークロード（学習・推論・ファインチューニング）に特化している。本セッションのポイントは、Ray ServeとKubeRayを組み合わせることで、上記の要件の多くを「最初から」解決できるという点だ。

KubeRayによるKubernetes統合

KubeRayオペレータはRay固有のCRD（Custom Resource Definition）を管理し、KubernetesのオートスケーラーとRayClusterを連携させる。これにより：

• クラスタレベルのオートスケーリング（KubeRay + Kubernetesオートスケーラー）
• アプリケーションレベルのオートスケーリング（並列リクエスト数・キュー数ベース、min/maxレプリカ設定）

の2層構造でスケーリングを制御できる。CPUとGPUが混在するヘテロジニアスなワークロードも単一RayCluster上で扱える。

FastAPI・gRPCのネイティブサポート

Ray ServeはFastAPIとgRPCをネイティブサポートしており、既存のFastAPIコードをそのまま移植できる。SSE・ストリーミング・HTTPはRay Serve側でカバーされる。フレームワーク移行コストが低い点は、既存のFastAPIベースのエージェントを持つチームにとって現実的な入口になる。

非同期バックグラウンドタスク

Ray Actorを使ったバックグラウンド非同期タスクの投入が可能で、Celeryとの併用でさらに複雑なタスクオーケストレーションにも対応する。長時間の調査系エージェント処理に直接適用できる構成だ。

Rayダッシュボード

Ray ServeにはRay Dashboardが標準付属しており、以下を統合的に確認できる：

• CPU・メモリ使用率などコンピュートメトリクス
• リクエスト数・QPS・ステータスコードなどリクエストレベルメトリクス
• レイテンシなどパフォーマンスメトリクス
• Ray CoreログおよびアプリケーションログのUI

実装の起点

セッションでは旅行プランナーのコード実装も示されており、ツール定義→グラフ構成→FastAPIラッピング→Ray Serve化という段階的な移行パスが示されている。既存のFastAPIエージェントをRay Serveに乗せる移行コストは低く、エントリーポイントとして現実的な選択肢だ。フレームワーク非依存の設計思想と組み合わせることで、LangGraphやLlamaIndexで書かれたエージェントロジックをそのまま活かしながら、インフラ層だけをRayに任せるという構成が自然に実現できる。

詳細はBeyond the Prototype: Scaling Framework Agnostic AI Agent Infrastructure with Rayを参照していただきたい。