Amazon Quickをエンタープライズ対応にする: 自動化された監査可能なクロスアカウントリソースプロモーション

Amazon Quickは、仕事向けに構築されたAmazonのエージェント型AIコンパニオンです。ユーザーは、自身のデータに基づいて推論し、アクションコネクタを呼び出し、複数ステップのタスクを完了まで遂行するエージェントを構築できます。これらのリソース(チャットエージェント、アクションコネクタ、ナレッジベース、フロー、スペース)を、他のアプリケーションと同じように開発用AWSアカウントから本番用AWSアカウントへプロモートすることは、手作業が多く、エラーが起きやすい面倒な作業でした。この記事では、Amazon Bedrock AgentCore上に冪等性と監査可能性を備えたModel Context Protocol (MCP) サーバーを構築して、このプロセスを自動化する方法を示します。

エージェント型ソリューションの構成要素は、その エージェント、アクションコネクタ、ナレッジベース、スペース: カスタム指示で設定されたチャットエージェント、Slack、Jiraなどの連携用コネクタ、自社のドキュメントに基づくナレッジベース、そしてそれらをまとめるスペース。チームは開発アカウントでこれらを素早く組み立て、反復改善できます。

ほとんどの企業では、開発用と本番用に別々のAWSアカウントを実行しており、その間に品質保証(QA)用のアカウントを挟む場合もあります。エージェント、アクションコネクタ、ナレッジベースを開発アカウントで検証した後、それらを次のアカウントへ昇格させるネイティブなワンクリック手段は存在しません。チームは各リソースを手作業で再構築しなければなりません。同じ指示とスタータープロンプトで各エージェントを再作成し、各エージェントのアクションコネクタを再度アタッチし、リソースの権限を再付与し、各ナレッジベースの背後にあるAmazon Simple Storage Service(Amazon S3)バケット、バケットポリシー、データソースを再プロビジョニングします。この作業は時間がかかり、監査が難しく、微妙な誤りが入りやすく、企業が必要とするガバナンスの仕組みを損ないます。

API を通じて Amazon Quick のリソースを管理する

Amazon Quickのリソースはプログラム可能です。スペース、エージェント、アクションコネクタ、ナレッジベース、フローは、Amazon Quick API(の一部である)を通じて管理されます。 Amazon Quick Sight API サーフェス)、リソースの完全なライフサイクル(作成、読み取り、更新、削除、一覧表示)を提供します。ビジネスユーザーが Amazon Quick で設定したもの、つまり命令とスタータープロンプトを含むエージェント、コネクタ、ナレッジベース、フローは、権限を含めてプログラムによって検査、再作成、更新、管理できます。

このプログラマブルなサーフェスこそが、管理された昇格を可能にするものです。各リソースを手作業で再作成する代わりに、APIを通じてリソースとその権限を読み取り、それらを別のアカウントに元どおり正確に再適用します。本投稿で扱うマイグレーターは、create、read、update、list の各操作を1つの繰り返し可能なワークフローにまとめ、ターゲットに対して delete を発行することは決してないため、実行は追加または更新のみを行います。

この記事では、Amazon Bedrock AgentCoreの機能であるAmazon Bedrock AgentCoreランタイム上でホストされたサンプルMCPサーバー「Quick Resource Migrator」を取り上げ、単一のツール呼び出しでAmazon Quickリソースのクロスアカウントへの昇格を自動化する方法を解説します。このツールはリソース駆動型で、リソースタイプ（agent、connector、knowledge base、flow、space）を選択し、idによる指定、名前による指定、またはすべてを選択できます。べき等性があり（再実行しても安全）、ソースの権限を記述してターゲットで同じアクションを再生することで、権限を忠実にコピーします。完全なソースコードは以下で入手できます。 aws-samplesリポジトリ.

ソリューション概要

このマイグレーターは、選択された一連のリソースを1回の呼び出しでプロモートします。これはアップサートであり、ターゲットにまだ存在しないリソースは作成され、すでに存在するリソースはその場で更新されます。すべての更新は、変更前にAmazon S3に書き込まれるバージョン付きバックアップによって保護されているため、各リソースは確認やロールバックが可能な完全な履歴を保持します。コミット前に読み取り専用のプレビューで、実行時に作成または更新される内容を正確に確認でき、マイグレーション自体はAmazon Bedrock AgentCore上で実行されるため、Amazon QuickやMCP互換の任意のクライアントから実行できます。

移行される内容

1. 選択モデル: リソースタイプ（エージェント、コネクタ、ナレッジベース、フロー、スペース）を選択し、リソースを id、名前、またはすべてで選択します。選択はリソース主導で行われます。リソースタイプを直接移行するか、スペースを移行してリンクされたリソースを一緒に移動することができます。
2. チャットエージェント: カスタム指示、アイデンティティ、トーン、スタータープロンプト、ウェルカムメッセージを再現し、アクションコネクタを再接続(ターゲットアカウントへの再マッピング)して作成されます。スペースが移行されると、そのエージェントは自動的に再リンクされます。
3. アクションコネクタ: ソースからは機密値は決して読み取られません。接続先ではプレースホルダーの資格情報でコネクタが作成され、ターゲット側で再認証されます。
4. ナレッジベース: ナレッジベースはターゲットアカウントに登録され、そのデータソースが再作成され、権限がコピーされます。S3 バックエンドのナレッジベースの場合、マイグレーターはターゲットバケットとそのバケットポリシー（マイグレーションの別個の出力）もプロビジョニングします。ドキュメント（S3 オブジェクト）自体はコピーされません。
5. フロー: ターゲットアカウント内でその定義から再作成されます。フローIDはアカウント間で異なるため、フローは名前で照合されます。同じ名前のターゲットフローが存在する場合は更新され、存在しない場合は新規作成されます。フローの権限はコピーされます。
6. スペース: ターゲットアカウントに再作成され、エージェント、コネクタ、ナレッジベースに再リンクされます(リソース Amazon Resource Names (ARN) はターゲットに再マッピングされます)。ターゲットの ARN が解決できるよう、リンクされたリソースを先に移行してください。スペースの権限はコピーされます。

主要な設計原則

1. リソース駆動の選択。 一度に 1 つのリソースタイプ(エージェント、コネクタ、ナレッジベース、フロー、またはスペース)を移行し、id、名前、またはすべてで選択します。エージェントはアクションコネクタを再アタッチして再作成されます。スペースは再作成され、エージェント、コネクタ、ナレッジベースに再リンクされ、ARN はターゲットアカウントに再マッピングされます。
2. 権限の忠実性。 権限はハードコードされていません。サーバーは各ソースリソースに対して関連する Describe*Permissions API を呼び出し、同一のアクションリストをターゲットで再生し、プリンシパルをターゲットアカウントの登録ユーザーに再マッピングします。
3. 冪等性。 すべてのリソースは作成または更新されます。サーバーは最初にターゲットを記述(describe)して作成か更新かを判断するため、移行を再実行しても重複や失敗が発生するのではなく、同じ状態に収束します。
4. 最小権限と分離。 ソースロールは読み取り専用です。ターゲットロールには、移行に必要なアクションのみが付与されます。ランタイムは Cognito JSON Web Token (JWT) で呼び出し元を認証し、仮想プライベートクラウド (VPC) ネットワークモードで実行できます。
5. 安全で可逆的な更新。 マイグレータが既存のターゲットリソースを更新する前に、そのリソースとその依存関係のバージョン付きスナップショットを専用のバックアップバケットに書き込みます。そのバックアップを書き込めない場合、更新は中止されます。作成または更新されたすべてのリソースもスナップショットされ、復元ツールで任意のリソースを以前のバージョンにロールバックできます。

アーキテクチャ

このソリューションは 3 アカウントモデルを使用します。中央のランナーアカウントが Amazon Bedrock AgentCore ランタイム上で MCP サーバーをホストします。サーバーは AWS Security Token Service (AWS STS) を使用して、ソースアカウントの読み取り専用ロールとターゲットアカウントの読み書きロールを引き受けるため、長期間有効な認証情報はどこにも保存されません。

図 1: Amazon Quick Resource Migrator MCP サーバーのアーキテクチャ

コンポーネントの責務

表 1: アーキテクチャ構成要素

移行フロー

1. リソースの解決: リソースタイプとセレクター（id、name、または all）から、ソースアカウント内の具体的なリソース ID を解決します。
2. ソースの記述: 選択された各リソースを describe し、その構成と権限を取得します。
3. コネクター: 各コネクターを再作成します。認証設定はプレースホルダーのシークレットを用いた create（write）モデルにサニタイズされ、その後ターゲット側で再認証されます。権限をコピーします。
4. ナレッジベース: ターゲットバケット（knowledge-base-<env>-<account>）、バケットポリシー、データソース、ナレッジベースを作成し、その後ナレッジベースの権限をコピーします。S3 オブジェクトはコピーされません。
5. エージェント: アクションコネクター（ターゲットアカウントに再マッピング）をアタッチした状態で各エージェントを再作成し、その後エージェントの権限をコピーします。スペース自体が移行される場合（スペースのステップを参照）、エージェントとスペースの関連付けは復元されます。
6. フロー: 定義から各フローを名前で照合して再作成します（フロー ID はアカウント間で異なります）。同名のターゲットフローを更新するか新規作成した後、フローの権限をコピーします。
7. スペース: 各スペースを作り直し、ARN をターゲットアカウントに付け替えたうえで(まずそれらのリソースを移行しておきます)、エージェント、コネクタ、ナレッジベースを再リンクし、その後スペースの権限をコピーしてください。
8. Report: 作成または更新されたリソース、バケット、バックアップ、スキップされた権限、およびエラーがあればその内容の JSON レポートを返します。

MCPサーバーが公開するツール

サーバーは5つのツールを公開しており、これらはすべて以下で定義されています。 server.py.

preview_migration（読み取り専用）

preview_migration ソースアカウントID、リソースタイプ（agent、connector、knowledge base、flow、space、またはall）、セレクター（id、name、またはall）、およびAWSリージョンを受け取ります。移行対象となるエージェント、アクションコネクタ、ナレッジベース、フローのインベントリを、名前とタイプ付きで返しますが、いかなる変更も行いません。ドライランとして利用し、昇格前にスコープを確認し、変更管理の承認ステップをサポートするために使用できます。ターゲットアカウントIDも渡した場合、レスポンスには各リソースをCREATEまたはUPDATEとしてマークするソースからターゲットへのマッピングが追加され、移行を実行する前に正確に何が変更されるかを確認できます。

migrate_resources(完全移行)

migrate_resources 送信元と送信先のアカウント ID、リソースタイプ(agent、connector、knowledge base、flow、space のいずれか)、セレクター(id、name、all のいずれか)、リージョン、送信元と送信先の環境名(knowledge base のバケット名に使用)、および Quick Sight サービスロール名を受け取ります。このツールは、前述の作成または更新の完全なマイグレーションを実行し、作成、更新、付与したすべての内容の構造化されたレポートと、発生したエラーを返します。べき等性があるため、リリースのたびなどに繰り返し実行でき、常に同じ送信先の状態に収束します。

list_backups (read-only)

list_backups バックアップカタログを検索し、各アセットで利用可能なバージョンを一覧表示します。バックアップは、マイグレーターがバックアップバケットに書き込む更新前のスナップショットで、更新ごとに 1 つのバージョン管理されたオブジェクトとして保存されるため、移行されたリソースの完全な履歴を確認できます。

get_backup (read-only)

get_backup 指定したアセットとバージョン(デフォルトでは最新)の保存済みバックアップ全体を返します。キャプチャされたリソース設定とその依存関係が含まれます。

restore_backup

restore_backup 保存済みのバックアップバージョンをターゲットリソースに再適用し、その場で更新するか、リソースが存在しない場合は再作成します。まず復元前の新しいバックアップを取得するため、この復元自体も元に戻すことができます。

ソリューションのデプロイ

完全なソースコードとステップバイステップのデプロイ手順は、 aws-samples リポジトリ の README にあります。大まかには、3 つの AWS CloudFormation スタック、つまりクロスアカウントの AWS Identity and Access Management (IAM) ロール、VPC ネットワーク、および MCP サーバーをホストする Cognito 認証の AgentCore ランタイムをデプロイし、そのランタイムを Amazon Quick のアクションコネクタとして登録します。

Quick App を通じたマイグレーターの利用

ランタイムをアクションコネクタとして登録することで、Amazon Quick から自然言語でマイグレーターを操作できるほか、Quick App、つまり同じ MCP ツールの上に構築されたポイントアンドクリック型のウェブエクスペリエンスを構築することもできます。その UI を手作業で構築する必要はありません。リポジトリにはすぐに使える app-builder プロンプト が含まれており、これを Amazon Quick アプリビルダーに貼り付け、プレースホルダーのコネクタ ID とアクション ID を自分のものに置き換えることでアプリを生成できます。このアプリは、ワークフローをガイド付きのフローに変換します。送信元と送信先のアカウントおよびプロモートするリソースを選択し、作成または更新される内容をプレビューし、マイグレーションを実行し、サーバーが書き込むバージョン管理された S3 スナップショットに裏付けられた過去のすべてのマイグレーションの履歴を確認します。以下の画面はそのエクスペリエンスを示しています。

Quick App の例

1. アプリはプロンプトから生成されるため、ビルドごとに結果は異なります。以下の画面はその一例を示しています。この例では、ランディングページで送信元アカウント ID、送信先アカウント ID、リソースタイプ(agent、connector、knowledge base、flow、space のいずれか)、およびセレクター(id、name、all のいずれか)の入力を求められ、必要に応じて追加のオプションも利用できます。

図 3: ランディングページで利用可能な追加のマイグレーションオプション

1. 選択した後 Confirm & migrateを選択すると、次のようなレスポンスが表示されます。

図 4: Confirm and migrate を選択した後の確認レスポンス

1. 確認してマイグレーションを実行すると、MCP サーバーから、作成または更新されたリソースを返すレスポンスが表示されるはずです。

図 5: 作成または更新されたリソースを一覧表示する MCP サーバーのレスポンス

1. 「履歴」タブを開くと、過去のすべてのマイグレーションを確認できます。各エントリは、マイグレーターがAmazon S3に書き込んだバージョン付きスナップショットに裏付けられているため、何がいつプロモートされたかについての完全で監査可能な記録が得られ、以前のバージョンを調べることもできます。

図6: 過去のマイグレーションの監査可能な記録を表示している「履歴」タブ

1. ロールバックするには、リソースのバックアップバージョンを選択して、 Restoreを選択します。アプリはその保存されたバージョンをターゲットに再適用します。リストアの前にまず新しいバックアップを取得するため、このリバート自体も元に戻すことができます。

図7: リソースを以前のバックアップバージョンにロールバックする様子

まとめ

クロスアカウントでのプロモーションはエンタープライズソフトウェアにおける基本要件であり、これまでAmazon Quickには欠けていた部分でした。Quick Resource Migratorは、時間がかかり、手作業で、監査が困難なタスクを、高速で、繰り返し可能で、ガバナンスに準拠したタスクに変えます。単一のツール呼び出しで、ターゲットアカウント内にエージェント、コネクタ、ナレッジベースを再作成し、権限を忠実にコピーします。すべてべき等に実行されるため、毎回のリリースで実行できます。

クローンを作成します サンプルリポジトリ、ランナーアカウントにデプロイし、エージェントやナレッジベースを開発環境から本番環境へ昇格させてみてください。その後、このパターンを自分のガバナンスおよび強化要件に合わせて調整してください。

著者について