はじめに

この記事は、ラスベガスで開催されたGoogle Cloud Next 2025のセッション聴講記事です。

セッションタイトル：
Productionizing OSS agents: Best practices for agent frameworks and Vertex AI

セッション内容は、OSSを用いたエージェント開発についてのビルドとデプロイという2つの視点の課題とGoogle Cloudでの解決策方法。という内容です。
うち、この記事は、ビルドについての記事です。
デプロイについて記事はこちら

ビルド

課題は何か？

まず、OSSフレームワークを使用したエージェント開発の基本的な課題として、「配管」と呼ばれるような複雑な作業がより多く発生してしまいます。
基本的にローコード、ノーコードなどのサービスより、デプロイメント、シリアライズ、そして様々なサービスとの連携、管理といった作業がどうしても必要になってしまいます。
また、AIの進化はご存知の通りすさまじく…、毎秒と言っていいほど多くのAIフレームワークが次々と登場していますよね。
そんな中でよりスピーディーに運用コストも少なく、開発者がエージェントの核となるロジックに集中できるよう支援することが、とてもとても重要です。

具体的には以下のような課題があります。

開発フェーズ

  • OSSエージェントの構築は、迷路を進むように感じられる
  • 無数のフレームワーク、一貫性のないツール、進化し続けるパターン
  • 主要なハードルは、構築、デプロイ、監視といったライフサイクル全体にわたって現れる

Agentライフサイクル全体

  • 構築の課題
    • フレームワークの断片化、APIの差異、依存関係地獄（dependency hell）、困難な統合。
  • デプロイの課題
    • 手動でのセットアップ、複雑なステートフルスケーリング、汎用インフラが適合しない。
  • 監視の課題
    • 非同期フローの追跡は困難、可視性の低さ、厄介な評価設定。
  • 骨の折れる作業 (The Grind)
    • 焦点がエージェントのロジックから、インフラの基盤整備（配管作業）との戦いに移ってしまう。

エージェントのフレームワーク選定

  • ツールサポート
    • Python関数？ OpenAPI？ カスタムコネクタ？
  • Google Cloud連携
    • 簡単なBigQuery？ Cloud SQL？ GCSアクセス？
  • メモリ/状態管理
    • シンプルなバッファ？ ベクトルストア？ 構造化グラフ？ データベース？
  • オブザーバビリティフック
    • 組み込みトレース（OpenTelemetry）？ ロギング？
  • デプロイパッケージング
    • コンテナ対応？ ラッパーが必要？ Cloud Runフレンドリー？
  • コミュニティとドキュメント
    • アクティブなサポート？ 明確な例？ デバッグガイド？
  • 学習曲線
    • クイックスタート vs 複雑なセットアップ？ パラダイムシフト？

などなど…エージェントをOSS開発しようとすると課題は山積みです。
かくして、開発者の労力はエージェントの核となるロジック開発ではなく、インフラの整備や問題解決（配管作業）に奪われてしまいますが、
このまま、手を拱くしかないのか…

そうだ！Google Cloudで解決しよう！

安心してください！Google Cloudが解決します！
なんといっても、Google Cloudの哲学は「write what you want deploy it on Google Cloud（好きなように書いて、Google Cloudにデプロイする）」
そう！我々はエージェント構築の自由を手に入れました！わーーい！

構築の自由：Vertex AI ❤️ OSS

  • Bring Your Own Framework (BYOF)
    • Vertex AIはオープンソースと互換性があります。LangChainやLangGraph、CrewAIといったフレームワークで作られたエージェントを、Agent Engineのコンテナを通じて展開可能です。プラットフォームの制約を受けることなく、柔軟な開発が実現できます。
  • エージェントのロジックに集中
    • Googleがインフラ周りの面倒な作業を全て引き受けてくれるので、開発者は本来の目的であるエージェントの機能開発に専念することができます。
  • Agent Development Kit (ADK)
    • Googleのオープンソースキットは、特にGoogle Cloud統合（ツール、認証など）のためのヘルパー機能や開発パターンを提供します。このキットは単独で、または他のフレームワークと組み合わせて使用できます。

こんなにすごいよ！Geminiくん

  • 最先端の基盤モデル – Gemini 2.0, 2.5！
  • 長いコンテキスト、マルチモーダル対応
  • 特定タスク向けのファインチューニング機能
  • Vertex AI SDK経由での、フレームワーク間での一貫したAPIアクセス
  • エンタープライズレベルのセキュリティ、データガバナンス、責任あるAI機能が組み込み済み

みんなのアイドル、GeminiくんはGoogle Cloudなら使えます！
なんと、Geminiはモデル自体をエージェント向けに調整していますし、
なにより、コストもお手頃なので、マルチエージェントのような推論が複数回連鎖するような使い方には最適すぎますね！

ツールどうしよう？

最高のモデル、Geminiを選んだら、次はエージェントにどんな道具を与えるか！ですね。
この世界を操るぱわーーー。

  • エージェントは、外部システムやデータと対話するためにツールを必要とします。
  • 標準的な方法（Python関数、OpenAPI仕様）を使用してツールを定義します。
  • フレームワークによって、ツールの定義、説明、実行の管理方法が異なります。
  • Vertex AI Geminiモデルには、堅牢なFunction Calling機能が組み込まれています。
  • 課題：ツールに対して安全に認証情報を提供し、実行環境を管理すること。（ここではADKとAgent Engineが役立ちます！）

メモリも大事

  • エージェントは、対話のターンを通じてコンテキスト（文脈）と状態を維持するためにメモリを必要とします。
  • シンプルなアプローチ：基本的なチャット履歴のバッファは長くなる可能性があります！
  • より高度な方法：要約、意味検索のためのベクトルデータベース。
  • 構造化された状態：LangGraphのようなフレームワークは、明示的な状態オブジェクトを使用します。
  • フレームワークは、メモリの永続性（データを保存し続けること）を異なる方法で処理します（インメモリ、ファイル、データベース）。
  • Vertex AIは統合ポイント（例：Vector Search）を提供しますが、メモリストラテジー（記憶方法の戦略）は、多くの場合フレームワークやアプリケーション固有です。

メモリや状態管理を適切にすることで、UXが爆上がりしますね。

LATAM Airlines社事例

LATAM Airlines社では、顧客体験を向上させるために、AIコンシェルジュを開発しました。
多くの旅行業界の企業が、購入後でのカスタマーサポートにAIを活用していますが、
LATAM Airlines社は、はじめの旅行の計画フェーズから顧客支援するためにエージェントを活用しています！

そんなエージェントをどのように開発したか、以下の3点、紹介されました。

  1. Tools
  2. Agent
  3. Evaluation

1. Tools

まずは、ツールから。
ツールは主に以下の3種類を使用。

  • どこへ旅行する？
    • Destinations Recommendations Tool
      • LATAM Airlines社の旅行雑誌
      • LATAM Airlines社の就航都市
  • そこで何をする？
    • Activities Planification Tool
      • 関連性が高く最新の情報
  • どうやってそこへ行く？
    • Flights Prices Tool
      • 全日程の参考価格
      • 日付範囲での検索を可能にする

特に、2つ目のActivities Planification Toolは、Google検索のグランディングツールをラップする形で作成しているそうです。
Google Cloud提供のサービスを使用することで、高品質かつ、開発・運用コストが下がるという事例ですね。

2. Agent

ここが、まさにエージェントの心臓ですね。
フレームワークの選定には悩んだそうですが、最終的にLangGraphで構築しているそうです。
選定の理由としては、モデル柔軟性と決定フローのバランスが良かったとのこと。
まさに、AIモデルが制御する箇所と、開発者が制御したい箇所を好きに制御できるため、従来のプログラミングとのいいとこ取りですよね。

開発は、段階的なアプローチで進められ、大きく3つのバージョンを経て進化したそうです。


バージョン1：新米トレーニー
最初のバージョンは、新入社員や研修生のようなイメージで開発されました。利用可能なツール（目的地検索、アクティビティ提案、フライト検索）を全てAIエージェントに与え、「親切な旅行代理店」として振る舞うように指示したシンプルな構成でした。
しかし、このバージョンでは、複数のツールを適切に管理し、いつ、どのツールを呼び出すべきかの判断に苦労が見られました。また、ユーザーの真の意図を理解することも難しく、プロンプトを何度も修正するうちに、エージェントが過剰な指示に混乱し、基本的なルールを忘れてしまうこともありました。例えば、競合他社のフライトを提案してしまうといった問題も発生しました。


バージョン2：チーム体制の導入
バージョン1の課題を踏まえ、バージョン2ではチーム体制を導入しました。AIエージェントの役割を、各ツールを専門とする4人のスペシャリストと、それらを管理するスーパーバイザーに分割しました。
この構成により、各スペシャリストは自身の専門分野に集中できるようになりましたが、新たな課題も発生しました。エージェント同士が互いの能力を理解しきれず、タスクの委譲がうまくいかないことがありました。また、全員が同じメッセージリストに読み書きするため、混乱が生じ、他のエージェントのツールを誤って使用しようとするといった問題も発生しました。この経験から、最終的な応答だけでなく、そこに至るまでのメッセージ履歴を注視することの重要性を学びました。


バージョン3：コミュニケーションチャネルと推論ステップの追加
バージョン3では、エージェント同士が集中力を維持しながらコミュニケーションできる専用のチャネルを設けました。さらに、次の行動を実行する前に熟考するための「推論ステップ」を追加しました。
バージョン3は大幅な改善を見せましたが、新たな問題も発生し、修正を行うたびに別の問題が生まれるという状況に陥りました。この状況を打破するために導入されたのが評価でした。

3. Evaluation


評価の導入：信頼できる指標の重要性
LATAM Airlines社は、開発の比較的後期、バージョン3の段階で本格的な評価指標を導入しました。初期段階で形式的な評価指標を設定するのではなく、課題が明確になった段階で、何を測定し、どのように測定するかを理解する時間が必要だったと振り返っています。
導入された評価指標の中でも特に重要だったのが「Trajectory（軌跡）」です。これは、「エージェントが質問に答えるための正しい道を辿っているか」を評価するもので、複数のエージェントが連携する複雑な構成において、ツール連携や意図理解の課題を特定する上で非常に有効でした。
UXチームが作成した正解データを用いて、新しいバージョンを評価し、以前のバージョンよりもスコアが向上した場合にのみ、チームに展開して更なるフィードバックを得るというサイクルを繰り返しました。
そして、「評価指標が新しいバージョンをデプロイするかどうかを決定する」という、強い信頼を置ける目標を設定することの重要性を強調していました。

さいごに

AIエージェントの開発の特にOSSでの開発周辺などの課題や、エージェント全体のライフサイクル課題などを、
いかにGoogle Cloudが便利にしてくれてるんだろうか、ということが分かりましたね！
また、お馴染みのLangChainやLangGraphはもちろん、新登場のAgent Development Kitを使ってもりもり開発していきましょう！
そして、LATAM Airlines社の事例では、本番で使用されている素晴らしいサービスの開発サイクル、という貴重な知見が得られ、
今後のAIエージェント構築でも、より効果的な開発と運用を実現する上で重要な指針となりますね。