Google AX · AWS Strands — エージェントにも「Kubernetes」が必要な理由

なぜ突然、エージェントの開発手法が根本から変わりつつあるのでしょうか？これまではプロンプトの精緻化や、複数のAPIを軽量に連携させることに注力してきました。しかし、エージェントが実際のビジネス課題を解決しようとした途端、ネットワークの切断やサーバーダウンによって、作業フローや状態がすべて消えてしまうというインフラの難題に直面し始めたのです。

Googleがオープンソースとして発表した分散型エージェントランタイム「AX」と、AWSが展開するマルチクラウドベースの「Strands Harness」は、まさにこうしたシステム上の課題を解決するために登場しました。いまや単なる開発ライブラリの枠を超え、サーバーインフラを安定運用するKubernetesのように、エージェントを安全に復旧・管理する「ランタイム」技術が重要視されています。本稿では、エージェント開発の文法を塗り替えるこれらの興味深い技術について、易しく解説していきます。

Google AX — エージェントの世界に到来したKubernetes

Googleがオープンソースとして公開したAXは、既存のエージェントフレームワークとは全く異なる動きをする「分散型エージェントオーケストレーションランタイム」です。コンテナを最適に管理するKubernetesのように、膨大なエージェントの実行状態やリソースをインフラレベルで安定制御する役割を担います。

これまで、AIエージェントを実務に投入するのは非常に困難でした。ネットワークが途切れたりサーバーが停止したりすると、そこまで推論しツールを実行してきた過程がすべて無に帰してしまったからです。

AXはこの問題を解決するため、エージェントのすべての行動やツール呼び出し記録をデータベースにイベントログとして逐次記録します。おかげで、システム障害が発生してもログを再生し、中断した地点から驚くほどスムーズに作業を再開できます。

さらに、単一のコントローラーが状態を一貫して管理する「単一作成者アーキテクチャ」により、複雑な分散環境でもデータの不整合やツールの重複実行といった競合を根本から防ぎます。エージェントはもはや不安定な使い捨てスクリプトではなく、エンタープライズレベルのインフラ上で動作する安定したシステムへと進化しています。

AWS Strands Harness — トークンコストを28%削減する秘訣

GoogleにAXがあるように、AWS陣営には「Strands Harness」があります。このツールは特定のクラウドやAIモデルに依存しないオープンソースのマルチクラウドランタイムです。Amazon Bedrockをはじめ、Anthropic、OpenAI、Google Geminiはもちろん、ローカルで軽量に動作するOllamaモデルまで自由に接続可能です。

Strands Harnessの最大の魅力は、エージェント開発者の悩みの種であるAPIコストを劇的に削減できる点です。エージェントが複雑な業務を解くために外部ツールを何度も実行すると、以前の実行結果が蓄積しコンテキストウィンドウを圧迫します。その結果、不要なトークン料金が発生し続けるという非効率が生まれます。

この問題を解決するため、Strands Harnessはツール実行結果を別ファイルとして安全に保存し、コンテキストウィンドウをリアルタイムで適切に解放します。重複するプロンプトを賢くキャッシュすることで、複雑な作業時に発生するトータルのトークンコストを約28%も節約してくれます。

実際のStrands Harnessの設定ファイルを見れば、その構造は直感的に理解できるはずです。

おかげで開発者は、モデルごとのAPI連携コードをいちいち書き直したり、コンテキスト最適化ロジックを自力で実装したりする必要がありません。インフラがコストやモデル移行の問題を肩代わりしてくれるため、開発者はエージェントが本来取り組むべき本質的なビジネスロジックにのみ注力できるようになります。

なぜ単なるフレームワークではダメなのか？

これまで多くの開発者が便利なライブラリを駆使してAIエージェントを開発してきました。しかし、実際のサービスに適用しようとすると壁にぶつかります。ネットワークが不安定で接続が途切れたり例外が発生したりすると、エージェントが記憶していた文脈や作業状態がすべて消えてしまうからです。まるでメモ帳で長い文章を書いている最中にPCが強制終了してしまうようなものです。

Google AXやAWS Strandsといったエージェントランタイムの登場は、このパラダイムを変えます。これらは、作成中の文書をリアルタイムで自動保存してくれるGoogleドキュメントのような存在です。ネットワーク接続が一時的に切れても実行状態がシステムアーキテクチャレベルで保護されているため、接続が回復すればエージェントはすぐに作業を再開できます。

もはや開発者は、複雑な例外処理やセッション復旧、呼び出しコストの最適化といったインフラの課題を毎回コーディングする必要はありません。以下のように、シンプルなランタイム設定一つで複雑な環境を容易に構築できます。

結局のところ、インフラレベルでの安定性が担保されることで、開発者はエージェントが解決すべきビジネスロジックや高度な行動フローの設計という本質的な作業に没頭できるようになるのです。

プロンプトを越え、「エージェントランタイム」の時代へ

AIエージェントの開発は、単にプロンプトを洗練させたりライブラリを組み合わせたりする段階を超えました。Google AXとAWS Strandsが示すように、これからはネットワークが切れても停止地点から自律的に再開し、トークンコストを自動で節約する安定したインフラエンジンが開発の核となるでしょう。

かつてのWebサービス市場がKubernetesの登場で運用安定性を劇的に高めたように、エージェントもまた堅牢なシステムランタイムの上で、真の実戦的なビジネスツールへと進化しています。スマートなプロンプトの書き方を悩む段階を過ぎ、サービスを支える骨組みとなる新しいエージェントインフラに目を向けるべき時です。