ADKエージェントを本番環境へ――Agent RuntimeとCI/CDで考える安全なデプロイ

1. はじめに

ローカルで動くことと、本番で動かせることは違う

ADKを利用すると、モデルへの指示や利用するツールを定義し、AIエージェントを開発できます。

開発端末上でエージェントを起動し、想定した回答が返ってくるところまでは、比較的短い期間で到達できます。しかし、ローカル環境で一度動いたことと、業務システムとして継続的に利用できることは同じではありません。

本番環境では、エージェントの処理だけでなく、次のような点も考える必要があります。

本番利用には、エージェントのロジックだけでなく、テスト、デプロイ、権限管理、監視を含めた仕組みが必要です。そこで利用するのが、ADK、Agent Runtime、CI/CDです。

2. ADK、Agent Runtime、CI/CDの役割

最初に、三つの役割を整理します。

ADKは「エージェントを作る」ための仕組み

ADKは、AIエージェントを構築するためのオープンソースの開発フレームワークです。

モデルへの指示、利用するツール、複数の処理やエージェントの連携などを、アプリケーションコードとして定義できます。

Agent Runtimeは「エージェントを動かす」ための仕組み

Agent Runtimeは、開発したエージェントをデプロイし、管理し、スケールさせるためのマネージドな実行基盤です。

実行基盤の管理をサービスへ任せることで、開発者はエージェントのロジックや業務機能へ集中しやすくなります。

CI/CDは「確認して安全に届ける」ための仕組み

CI/CDは、ソースコードの変更を検査し、定められた条件を満たした変更だけを、ステージング環境や本番環境へ反映する仕組みです。

AIエージェントの場合、一般的な単体テストや結合テストだけではなく、適切なツールを選んだか、正しい引数を渡したか、期待する回答や動作になっているかといった評価も必要になります。

この三つをつなぐことで、開発から本番運用までの流れが成立します。

3. ADKでエージェントを開発する

ADKでは、エージェントを構成する要素をコードや設定として管理します。たとえば、次のような要素があります。

コードとして管理することで、Gitなどのソースコード管理システムを利用できます。誰が、いつ、エージェントの指示やツール、処理ロジックをどのように変更したのかを、履歴として確認できます。使用する依存パッケージの変更も記録できます。

一方で、開発環境と本番環境で異なる値を、エージェントのコードへ直接書き込むべきではありません。Google Cloudのプロジェクト、リージョン、接続先、実行ID、シークレット、ログや監視の設定は、環境ごとの設定として分離します。

エージェントのロジックと環境固有の設定を分けることで、同じコードを開発、ステージング、本番の各環境へ展開しやすくなります。依存パッケージのバージョンも管理し、環境によって意図せず異なるバージョンが使われないようにします。

4. テストと評価をデプロイの条件にする

エージェントを変更した後、確認せずに本番環境へデプロイするのは危険です。プロンプトを数行変更しただけでも、呼び出すツール、引数、回答形式、確認処理、これまでの回答能力に影響する可能性があります。

そのため、エージェントのテストでは、一般的なアプリケーションテストと、AIエージェント固有の評価を組み合わせます。

一般的なアプリケーションテスト

AIエージェント固有の評価

あらかじめ質問や操作と期待する動作を評価データとして用意し、変更前後の結果を確認します。

生成AIの回答は毎回完全に同じになるとは限りません。そのため、文章が一字一句一致するかだけではなく、最終回答とそこへ至る処理の流れが、業務上必要な条件を満たしているかを評価することが重要です。

評価結果が基準を下回った場合は、デプロイを停止します。テストと評価の結果を基準に、変更を次の環境へ進めるか、ここで止めるかを判断します。この確認をデプロイ前に設けることで、基準を満たさない変更が本番環境へ進むことを防げます。

5. Agent Runtimeへデプロイする

テストと評価を通過したエージェントを、Agent Runtimeへデプロイします。

Agent Runtimeを利用することで、開発したエージェントをマネージドな実行環境で動かし、アプリケーションなどから利用できる状態にします。

デプロイ時には、エージェントのコードだけでなく、識別情報、依存パッケージ、環境変数、シークレット、実行ID、CPUやメモリなどの実行条件、ネットワーク接続、ログや監視の設定も考慮します。

特に重要なのが、エージェントがGoogle Cloudへアクセスするときに使用する実行IDです。実行IDには、サービスアカウントなどの実行主体を使用します。開発、ステージング、本番で同じIDを使い回すのではなく、環境やエージェントの役割に応じて分離します。

これにより、開発中のエージェントが誤って本番データへアクセスすることや、必要以上の操作を実行することを防ぎやすくなります。

6. CI/CDでステージングから本番へ進める

ここまでの作業を、CI/CDパイプラインとしてつなぎます。全体の流れを図1に示します。

図1　ADK、CI/CD、Agent Runtimeをつないだ開発・デプロイ・運用の流れ

1．変更をレビュー可能な形で登録する

Gitを利用する構成では、たとえばエージェントの指示、ツール、処理ロジック、設定、評価データなどの変更をPull Requestとして登録します。この時点では、本番環境へのデプロイは行いません。

2．CIでテストと評価を実行する

Pull Requestを契機に、コードの形式チェック、単体テスト、結合テスト、依存パッケージの確認、エージェント評価、セキュリティチェックを実行します。一つでも基準を満たさなければ、変更を次の工程へ進めません。

3．ステージング環境へデプロイする

レビューとテストを通過した変更を、ステージング環境へデプロイします。

ステージング環境では、Agent Runtime上での起動、アプリケーションからの呼び出し、ツールやデータへの接続、ステージング用権限、ログやトレース、応答時間や実行条件を確認します。ローカル環境では確認しにくい、IAM、ネットワーク、API、シークレットなどの問題をここで検出します。

4．承認後に本番環境へ反映する

ステージング環境での確認に成功したら、承認を経て本番環境へ反映します。本番には、ステージングで確認した変更と対応するコミットや成果物をデプロイします。

本番デプロイの直前に依存パッケージを無条件で更新したり、別の内容を再作成したりすると、ステージングで確認したものとは異なる状態になる可能性があります。何をテストし、何を本番へ反映したのかを追跡できるようにすることが重要です。

7. 安全なデプロイのために分離するもの

CI/CDを導入しても、すべてを一つの環境、一つのID、一つの設定で実行していては、十分な安全性を確保できません。少なくとも、次の項目を分けて考えます。

環境を分離する

開発、ステージング、本番の環境を分離します。Google Cloudプロジェクトを環境ごとに分けることで、IAM、API、ログ、ネットワーク、利用上限などを管理しやすくなります。

エージェントの実行IDを分離する

エージェントがツールやデータへアクセスするときのIDは、環境や役割に応じて分離します。本番用のIDには、本番業務に必要な権限だけを付与します。

CI/CDのIDを分離する

CI/CDパイプラインがデプロイに使用するIDと、デプロイ後のエージェントが業務処理に使用するIDは役割が異なります。

CI/CDのIDにはデプロイに必要な権限を付与し、エージェントの実行IDには業務上必要なAPIやデータへアクセスする権限を付与します。デプロイする権限と、業務データへアクセスする権限を一つのIDへまとめないことが重要です。

設定とシークレットを分離する

プロジェクトやリージョンなどの通常の設定値と、APIキーや認証情報などのシークレットを分けて管理します。シークレットをソースコードへ直接記載せず、シークレット管理サービスなどから取得する構成にします。

デプロイした変更を識別する

どのコミットや成果物からデプロイされたエージェントなのかを確認できるようにします。コミットID、ビルド番号、リリース番号などを記録しておけば、問題発生時に影響範囲を特定しやすくなります。

問題が発生した場合は、本番環境をその場で直接書き換えるのではなく、正常動作が確認されているコミットや成果物を再デプロイします。

CI/CDは、デプロイ作業を速くするだけの仕組みではありません。変更内容、テスト結果、承認、デプロイ先、利用したIDを記録し、定められた条件を満たした変更だけを本番へ届けるための統制でもあります。

8. まとめ

「作る」「動かす」「安全に更新する」を一つの流れにする

ADKを使うことで、エージェントの指示、ツール、処理フローをコードとして開発できます。

Agent Runtimeを使うことで、開発したエージェントをマネージドな実行環境へデプロイし、アプリケーションなどから利用できます。

さらにCI/CDを組み合わせることで、変更のたびにテストと評価を行い、ステージング環境で確認したうえで、本番環境へ反映できます。

重要なのは、自動的にデプロイできることだけではありません。

これらをあらかじめ設計しておくことが、AIエージェントを継続的かつ安全に運用するための土台になります。

ADK、Agent Runtime、CI/CDを個別の機能として扱うのではなく、開発から本番運用までをつなぐ一つのライフサイクルとして設計することが重要です。

参考情報

• Agent Development Kit
• Agent Runtime
• Deploy an agent
• Manage revisions and traffic
• Managing access for deployed agents
• Why evaluate agents
• Agent evaluation
• Set up logging
• Set up monitoring