AWS Quick をエンタープライズ対応に: 自動化され監査も可能な、アカウント間のリソース昇格

本記事は 2026 年 10 月 5 日 に公開された「Making AWS Quick enterprise-ready: Automated, auditable cross-account resource promotion」を翻訳したものです。

AWS Quick は、仕事のために作られた Amazon のエージェント型 AI アシスタントです。データをもとに推論し、アクションコネクタを呼び出し、複数ステップのタスクを最後まで実行するエージェントを構築できます。ただし、こうしたリソース (チャットエージェント、アクションコネクタ、ナレッジベース、フロー、スペース) を、他のアプリケーションと同じように開発用の AWS アカウントから本番用の AWS アカウントへ昇格（プロモーション）させる作業は、これまで手作業で、ミスも起きやすいものでした。本記事では、Amazon Bedrock AgentCore 上で動く、冪等で監査可能な Model Context Protocol (MCP) サーバーを利用して、昇格作業を自動化する方法を紹介します。

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

多くの企業は、開発用と本番用に別々の AWS アカウントを運用しており、その間に品質保証 (QA) 用のアカウントを置くこともあります。開発アカウントでエージェント、アクションコネクタ、ナレッジベースを検証し終えても、それらを次のアカウントへワンクリックで昇格させるネイティブな手段はありません。そのため、チームは各リソースを手作業で作り直しています。同じ指示とスタータープロンプトで各エージェントを再作成し、エージェントごとにアクションコネクタを付け直し、リソースの権限を付与し直し、各ナレッジベースの裏側にある Amazon Simple Storage Service (Amazon S3) バケット、バケットポリシー、データソースを用意し直す必要があります。時間がかかるうえに監査しにくく、気づきにくい誤りも入り込みやすいため、企業に求められるガバナンスが損なわれます。

API で AWS Quick のリソースを管理する

Quick のリソースはプログラムから操作できます。スペース、エージェント、アクションコネクタ、ナレッジベース、フローは Quick API (AWS Quick Sight API の一部) で管理でき、作成・読み取り・更新・削除・一覧取得というリソースのライフサイクル全体に対応しています。指示とスタータープロンプトを持つエージェント、コネクタ、ナレッジベース、フローなど、ビジネスユーザーが Quick で設定したものは、権限も含めてすべてプログラムから確認、再作成、更新、管理できます。

プログラムから操作できるからこそ、ガバナンスを確保した昇格が可能になります。各リソースを手作業で作り直す代わりに、API でリソースとその権限を読み取り、別のアカウントにそのまま適用し直します。本記事で紹介する移行ツールは、作成・読み取り・更新・一覧取得の操作を組み合わせて 1 つの繰り返し実行できるワークフローにしています。移行先に対して削除は一切実行しないため、1 回の実行で行われるのは追加か更新のみです。

本記事では、Quick Resource Migrator を紹介します。Quick Resource Migrator は、Amazon Bedrock AgentCore の機能である Amazon Bedrock AgentCore Runtime 上で動くサンプルの MCP サーバーで、Quick リソースのアカウント間の昇格を 1 回のツール呼び出しで自動化します。リソース単位で動作し、リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース) を選び、ID、名前、またはすべてを指定して対象を選択します。冪等なので何度実行しても安全です。また、移行元の権限を取得し、同じアクションを移行先で再現することで、権限を正確にコピーします。ソースコード一式は aws-samples リポジトリで公開しています。

ソリューションの概要

移行ツールは、選んだリソース群を 1 回の呼び出しで昇格させます。動作はアップサートで、移行先にまだないリソースは作成し、すでにあるリソースはその場で更新します。更新の前には必ずバージョン付きのバックアップを Amazon S3 に書き込むため、各リソースの履歴をすべて残し、確認したり以前の状態に戻したりできます。読み取り専用のプレビューで、実行した場合に何が作成・更新されるかを事前に正確に確認できます。移行処理そのものは Amazon Bedrock AgentCore 上で動くため、Quick や任意の MCP 対応クライアントから操作できます。

移行される内容

1. 選択モデル: リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース) を選び、ID、名前、またはすべてを指定してリソースを選択します。選択はリソース単位です。リソースタイプを直接移行することも、スペースを移行して、スペースに紐づくリソースをまとめて移すこともできます。
2. チャットエージェント: カスタム指示、アイデンティティ、トーン、スタータープロンプト、ウェルカムメッセージを含めて再作成し、アクションコネクタも (移行先アカウントのものに対応付けて) 付け直します。スペースを移行すると、エージェントはスペースに自動で紐づけ直されます。
3. アクションコネクタ: 設定を含めて再作成します。シークレットの値を移行元から読み取ることはありません。コネクタは仮の認証情報で作成されるため、移行先で改めて認証を設定します。
4. ナレッジベース: 移行先アカウントにナレッジベースを登録し、データソースを再作成して、権限をコピーします。S3 をデータソースとするナレッジベースの場合は、移行先のバケットとそのバケットポリシーも作成します (移行の出力として別に報告されます)。ドキュメント (S3 オブジェクト) そのものはコピーされません。
5. フロー: 定義をもとに移行先アカウントで再作成します。フローの ID はアカウントごとに異なるため、フローは名前で照合します。移行先に同じ名前のフローがあれば更新し、なければ新しく作成します。フローの権限もコピーされます。
6. スペース: 移行先アカウントで再作成し、エージェント、コネクタ、ナレッジベースに紐づけ直します (リソースの Amazon リソースネーム (ARN) は移行先のものに対応付けます)。移行先の ARN を解決できるよう、紐づくリソースを先に移行してください。スペースの権限もコピーされます。

主な設計方針

1. リソース単位の選択。 移行は 1 回に 1 つのリソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース) ずつ行い、ID、名前、またはすべてで対象を選びます。エージェントはアクションコネクタを付け直した状態で再作成されます。スペースは再作成されたうえで、エージェント、コネクタ、ナレッジベースに紐づけ直され、ARN は移行先アカウントのものに対応付けられます。
2. 権限の忠実な再現。 権限はハードコードしません。サーバーは移行元の各リソースに対して該当する Describe*Permissions API を呼び出し、まったく同じアクションのリストを移行先で適用します。その際、プリンシパルは移行先アカウントに登録されているユーザーに対応付けます。
3. 冪等性。 すべてのリソースは「作成または更新」で処理します。サーバーはまず移行先の状態を取得し、作成するか更新するかを判断します。そのため、移行を再実行しても重複や失敗は起きず、同じ状態に収束します。
4. 最小権限と分離。 移行元のロールは読み取り専用です。移行先のロールには、移行に必要なアクションのみを許可します。ランタイムは Amazon Cognito の JSON Web Token (JWT) で呼び出し元を認証し、Amazon Virtual Private Cloud (Amazon VPC) のネットワークモードで実行することもできます。
5. 安全で元に戻せる更新。 移行先の既存リソースを更新する前に、そのリソースと依存リソースのバージョン付きスナップショットを専用のバックアップバケットに書き込みます。バックアップを書き込めない場合、更新は中止されます。作成・更新したリソースもすべてスナップショットを取得し、復元ツールでどのリソースも以前のバージョンに戻せます。

アーキテクチャ

本ソリューションは 3 つのアカウントで構成します。中央のランナーアカウントが、Amazon Bedrock AgentCore Runtime 上で MCP サーバーをホストします。サーバーは AWS Security Token Service (AWS STS) を利用して、移行元アカウントでは読み取り専用ロール、移行先アカウントでは読み書きロールを引き受けるため、長期的な認証情報をどこにも保存しません。

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

各コンポーネントの役割

表 1: アーキテクチャのコンポーネント

移行の流れ

1. リソースの特定: リソースタイプとセレクター (ID、名前、またはすべて) から、移行元アカウントの具体的なリソース ID を特定します。
2. 移行元の取得: 選択した各リソースの設定と権限を取得します。
3. コネクタ: 各コネクタを再作成します。認証設定は作成 (書き込み) 用のモデルに合わせて整え、シークレットは仮の値にしたうえで作成するため、移行先で改めて認証を設定します。権限もコピーします。
4. ナレッジベース: 移行先のバケット (knowledge-base-<env>-<account>)、バケットポリシー、データソース、ナレッジベースを作成し、ナレッジベースの権限をコピーします。S3 オブジェクトはコピーしません。
5. エージェント: 各エージェントを、(移行先アカウントのものに対応付けた) アクションコネクタを付けた状態で再作成し、エージェントの権限をコピーします。エージェントとスペースの紐づけは、スペースそのものを移行したときに復元されます (スペースの手順を参照)。
6. フロー: 各フローを定義から再作成します。フローの ID はアカウントごとに異なるため、名前で照合します。移行先に同じ名前のフローがあれば更新し、なければ新しく作成したうえで、フローの権限をコピーします。
7. スペース: 各スペースを再作成し、ARN を移行先アカウントのものに対応付けて、エージェント、コネクタ、ナレッジベースに紐づけ直します (これらのリソースを先に移行しておきます)。その後、スペースの権限をコピーします。
8. レポート: 作成・更新したリソース、バケット、バックアップ、スキップした権限、エラーをまとめた JSON レポートを返します。

MCP サーバーが提供するツール

サーバーは 5 つのツールを提供しており、すべて server.py で定義されています。

preview_migration (読み取り専用)

preview_migration は、移行元のアカウント ID、リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース、またはすべて)、セレクター (ID、名前、またはすべて)、AWS リージョンを受け取ります。変更は一切加えずに、移行対象となるエージェント、アクションコネクタ、ナレッジベース、フローの一覧を名前とタイプ付きで返します。ドライランとして対象範囲を確かめたり、昇格前の変更管理の承認手順に利用したりできます。移行先のアカウント ID も渡すと、各リソースを CREATE または UPDATE で示した移行元と移行先の対応表が応答に加わるため、移行を実行する前に何が変わるかを正確に確認できます。

migrate_resources (移行の実行)

migrate_resources は、移行元と移行先のアカウント ID、リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース)、セレクター (ID、名前、またはすべて)、リージョン、移行元と移行先の環境名 (ナレッジベースのバケット名に使用)、Quick Sight のサービスロール名を受け取ります。前述の「作成または更新」の移行を一通り実行し、作成・更新・付与したものすべてとエラーをまとめた構造化レポートを返します。冪等なので、たとえばリリースのたびに繰り返し実行しても、移行先は同じ状態に収束します。

list_backups (読み取り専用)

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

get_backup (読み取り専用)

get_backup は、指定したアセットとバージョン (既定では最新) について、保存されているバックアップ全体を返します。取得したリソースの設定と依存リソースも含まれます。

restore_backup

restore_backup は、保存されているバックアップのバージョンを移行先のリソースに適用し直します。リソースはその場で更新され、存在しない場合は再作成されます。復元の前に新しいバックアップを取得するため、元に戻す操作そのものも取り消せます。

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

ソースコード一式と詳しいデプロイ手順は、aws-samples リポジトリの README にあります。大まかには、アカウント間で使用する AWS Identity and Access Management (IAM) ロール、VPC ネットワーク、MCP サーバーをホストする Cognito 認証付きの AgentCore Runtime という 3 つの AWS CloudFormation スタックをデプロイし、AgentCore Runtime を Quick にアクションコネクタとして登録します。

Quick App から移行ツールを利用する

ランタイムをアクションコネクタとして登録すると、Quick から自然言語で移行ツールを操作できます。さらに、同じ MCP ツールの上にクリック操作で利用できる Web 画面を重ねた Quick App も構築できます。UI を手で作る必要はありません。リポジトリにはすぐに利用できるアプリビルダー用のプロンプトが含まれており、Quick のアプリビルダーに貼り付け、プレースホルダーのコネクタ ID とアクション ID を自分のものに置き換えるとアプリが生成されます。アプリでは、移行元と移行先のアカウントと昇格するリソースを選択し、作成・更新される内容をプレビューし、移行を実行し、過去のすべての移行履歴を確認する、という流れを画面の案内に沿って進められます。各履歴は、サーバーが書き込んだバージョン付きの S3 スナップショットに裏付けられています。以下の画面で、その操作を紹介します。

Quick App の例

1. アプリはプロンプトから生成されるため、ビルドするたびに内容が変わります。以下はその一例です。この例では、ランディングページで Source Account ID、Target Account ID、リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース)、セレクター (ID、名前、またはすべて) を入力します。必要に応じて追加のオプションも指定できます。

図 3: ランディングページで指定できる追加の移行オプション

2. Confirm & migrate を選択すると、次のような応答が表示されます。

図 4: Confirm and migrate を選択したあとの確認の応答

3. 確認して移行を実行すると、作成・更新されたリソースの一覧が MCP サーバーから返ってきます。

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

4. History タブを開くと、過去のすべての移行を確認できます。各エントリは、移行ツールが Amazon S3 に書き込んだバージョン付きのスナップショットに裏付けられているため、何をいつ昇格したかを監査できる完全な記録が残り、以前のバージョンを確認することもできます。

図 6: 過去の移行を監査できる記録として表示する History タブ

5. 元に戻すには、リソースのバックアップのバージョンを選択し、Restore を選択します。アプリが保存済みのバージョンを移行先に適用し直します。復元の前に新しいバックアップを取得するため、元に戻す操作そのものも取り消せます。

図 7: リソースを以前のバックアップのバージョンに戻す

まとめ

アカウント間の昇格は、エンタープライズ向けソフトウェアでは当然求められる機能ですが、Quick ではこれまで欠けていました。Quick Resource Migrator を利用することで、時間がかかり監査もしにくかった手作業を、すばやく繰り返し実行でき、ガバナンスも確保できる作業へと変えることができます。1 回のツール呼び出しで、エージェント、コネクタ、ナレッジベースを移行先アカウントに再作成し、権限も正確にコピーします。すべて冪等に動作するため、リリースのたびに実行できます。

サンプルリポジトリをクローンしてランナーアカウントにデプロイし、エージェントやナレッジベースを開発環境から本番環境へ昇格させてみてください。そのうえで、自社のガバナンスやセキュリティ強化の要件に合わせて構成を調整してください。

著者について

翻訳は Solutions Architect の 守田 凜々佳 が担当しました。