デモデータ
バックエンドで DEMO_DATA=true を設定すると、承認つきで状態を変える 3 つの例 — 「EC2 インスタンスを起動する」例、「GKE の Pod を再起動する」例、「Azure Key Vault のシークレットをローテーションする」例 — に必要なものが一式、初期投入された Default テナントに登録されます。一つずつ手で登録しなくても、すぐに動かせるものが手元にある状態になります。ワークフロー自体はあえて登録しません。これらはワークフローを生成するための材料で、実際に生成するところからの手順がウォークスルーです。
有効にする
backend/.env にフラグを足してバックエンドを再起動します。Docker Compose ならすでに有効です。compose.yml が DEMO_DATA: ${DEMO_DATA:-true} を設定しています。
DEMO_DATA=true
DEMO_PASSWORD=change-me-now-123
DEMO_AWS_ACCESS_KEY_ID=AKIA...
DEMO_AWS_SECRET_ACCESS_KEY=...
DEMO_AWS_REGION=us-east-1
DEMO_GCP_CREDENTIALS_JSON='{"type":"service_account",...}'
DEMO_AZURE_TENANT_ID=...
DEMO_AZURE_CLIENT_ID=...
DEMO_AZURE_CLIENT_SECRET=...
DEMO_PASSWORDは 11 のデモユーザーで共有され、ROOT_PASSWORDやADMIN_PASSWORDと同じく、未設定なら生成してログに一度だけ出力します。参照されるのは、そのアカウントがまだ存在しないときだけです。- AWS、Google Cloud、Azure の認証情報はいずれも任意です。未設定なら
REPLACE_MEというプレースホルダーが保存されるので、形としてはデモが揃った状態になり、実際の値はシークレットのページから入れられます。 DEMO_AWS_REGIONは、デモの AWS MCP サーバーのツールが操作する対象のリージョンです。既定はus-east-1です。DEMO_GCP_CREDENTIALS_JSONは Google Cloud の認証情報 JSON を 1 行にしたものです。サービスアカウントの鍵か、OAuth クライアント ID とシークレットで一度サインインしたあとにgcloudが書き出す authorized-user JSON のどちらかを入れます。GKE MCP サーバーはここからアクセストークンを発行します。Google の MCP サーバーは API キーを受け付けません。入手方法は Google Cloud の MCP サーバーを参照してください。DEMO_AZURE_TENANT_ID・DEMO_AZURE_CLIENT_ID・DEMO_AZURE_CLIENT_SECRETは Azure のサービスプリンシパルです。az ad sp create-for-rbacが表示するテナント、アプリのクライアント ID、クライアントシークレットをそのまま入れます。デモでシークレットをローテーションする Key Vault に対して、Microsoft.KeyVault/vaults/secrets/readMetadata/actionとMicrosoft.KeyVault/vaults/secrets/setSecret/actionのデータアクションだけを持つカスタムロールを付与しておいてください。アクセスポリシー方式の Key Vault なら、シークレットの権限は List と Set だけを付与します。組み込みの Key Vault Secrets Officer ロールでも動きますが、すべてのシークレットの値まで読めてしまいます。
⚠️ AWS・GKE・Azure の MCP サーバーは、読み取りだけでなく、状態を変える操作を実行できます。AWS MCP サーバーの認証情報は実際の AWS リソースを作成・削除でき、GKE MCP サーバーの身元は実際のクラスタでワークロードのローリング再起動や Pod の削除を行え、Azure MCP サーバーのサービスプリンシパルは Key Vault のシークレットを書き込めます。いずれも使い捨てのアカウントか、権限を絞った認証情報を使ってください。実際のプロバイダにまったく触れずにデモを試す方法は、下の試してみるを参照してください。
登録されるもの
- エージェントスキル
Demo AWS EC2 Launch— インスタンスの構成を聞き取り、それについて管理職の明示的な承認を得てから、MCP ツールでインスタンスを起動します。リポジトリは起動後にバックグラウンドで clone するので、使えるようになるまでの間スキルはpendingと表示されます。 - エージェントスキル
Demo GKE Pod Restart— 対象(プロジェクト・クラスタ・namespace・そして Deployment/StatefulSet 名か単一の Pod 名のいずれか)をユーザーと合意し、その対象について管理職の明示的な承認を得てから、既定では GKE MCP Server でワークロードをローリング再起動し、ユーザーが1つの Pod だけを望む場合はその Pod を削除して所有コントローラーに再作成させ、結果を報告します。リポジトリの clone も同じ仕組みなので、最初は同様にpendingと表示されます。 - エージェントスキル
Demo Azure Key Vault Secret Rotation— Key Vault と、その中にある既存のシークレットをユーザーと合意し、そのシークレットについて管理職の明示的な承認を得てから、新しく生成したランダムな値をシークレットの新しいバージョンとして Azure MCP Server で書き込み、新しいバージョンの作成日時を報告します。値はチャットに表示しません。リポジトリの clone も同じ仕組みなので、最初は同様にpendingと表示されます。 - MCP サーバー
AWS MCP Server— AWS のマネージド AWS MCP Server に接続するstdioサーバーです。EC2 のツールはここから来ます。 - MCP サーバー
GKE MCP Server— Google Cloud のマネージド GKE(Google Kubernetes Engine)MCP サーバーのフルエンドポイントに接続するstreamable_httpサーバーです。AuthorizationヘッダーはBearer ${gcp-token:demo-gcp-credentials/GOOGLE_CREDENTIALS_JSON}なので、接続のたびにdemo-gcp-credentialsシークレットから発行したばかりのアクセストークンを送ります。ツールはクラスタや Kubernetes リソースを管理でき、ワークロードのローリング再起動や Pod の削除も含まれます。 - MCP サーバー
Azure MCP Server— Microsoft の Azure MCP Server を、Key Vault のツールだけに絞って動かすstdioサーバーです。demo-azure-credentialsシークレットのサービスプリンシパルでサインインし、Key Vault のシークレット・キー・証明書を一覧したり書き込んだりできます。シークレットに対する操作のたびに同意を求め、その質問は実行の申請者にチャットでの確認として届きます。ローテーションに対する管理職の承認とは別に求められます。デモのスキルはデザインエージェントにこのツールへ「質問する」印を付けるよう伝えるので、ツールを使うタスクはそれぞれ申請者の再開を待ちます。新しいシークレットの値は Key Vault に届くまでにエージェントの会話を通るので、実行のチャットはシークレットと同じように扱ってください。 - MCP サーバー
EC2 Cost Estimator— Python のスクリプトサーバーです。指定したリージョンの価格を AWS の価格表からその場で取得し、EC2 インスタンスタイプのオンデマンド月額を見積もるツール(estimate_monthly_cost)と、複数のタイプを安い順に並べるツール(compare_instance_types)を提供します。Packages でboto3をインストールし、demo-aws-credentialsシークレットを使います。そのため Test Run で試すには、AWS の価格表を読む権限(pricing:GetProducts)を持つ認証情報が必要です。読み取りしか行いません。 - MCP サーバー
Kubernetes Manifest Toolkit— JavaScript のスクリプトサーバーです。Kubernetes マニフェストに必須項目の抜けがないかを確認するツール(validate_manifest)と、Deployment・StatefulSet・DaemonSet をローリング再起動するパッチを作るツール(build_restart_patch)を提供します。Packages でjs-yamlをインストールします。認証情報は不要で、クラスタには接続しないので、Test Run ですぐに試せます。 - MCP サーバー
Secret Value Generator— JavaScript のスクリプトサーバーです。暗号論的に安全なランダムなシークレット値を生成するツール(generate_secret_value)を1つだけ提供します。パッケージのインストールも認証情報も不要で、Azure には接続しないので、Test Run ですぐに試せます。 - ナレッジベース
AWS EC2 Pricing— ソースを 1 つ持ちます。ec2-on-demand-pricing.pdfという価格表で、ウォークスルーで選べる 10 種類のインスタンスタイプについて、us-east-1・us-east-2・us-west-2でのオンデマンドの時間単価と月額、vCPU、メモリ、それにストレージとパブリック IP の料金が載っています。数値はデモ用の参考値です。ソースは Not read の状態で登録されるので、誰かがソースの Read を押すまで、ナレッジベースにページはありません。ウォークスルーでは AWS の開発者がこの操作をします。EC2 起動のワークフローにリンクすると、申請するインスタンスの費用にエージェントが答えられるようになります。 - シークレット
demo-aws-credentials— AWS MCP Server が読む、AWS のアクセスキー ID とシークレットアクセスキーです。 - シークレット
demo-gcp-credentials— GKE MCP Server がアクセストークンを発行する元になる、Google Cloud の認証情報 JSON です。 - シークレット
demo-azure-credentials— Azure MCP Server がサインインに使う、Azure サービスプリンシパルのテナント ID・クライアント ID・クライアントシークレットです。 - ツールモック — デモ実行で副作用のあるツールのスタブです。AWS MCP Server の
aws___call_awsとaws___run_script(どちらも起動成功を返す)、GKE MCP Server のpatch_k8s_resource(ローリング再起動成功を返す)とdelete_k8s_resource(Pod 削除成功を返す)、Azure MCP Server のkeyvault_secret_get(Key Vault のシークレット一覧を返す)とkeyvault_secret_create(新しいシークレットバージョンを返す)、および組み込みのrequest_approval(approved を返す)。ドラフト実行の Run ダイアログで選ぶと、AWS や実際の GKE クラスタ、実際の Key Vault に触れることも管理職の承認を待つこともなく、3 つのワークフローのどれも最後まで動きます。 - タグ
AWS・GCP・Azure— それぞれアクセス制御タグです。Demo AWS Group/Demo GCP Group/Demo Azure Groupのメンバー(およびadmin、スーパー管理者)以外には、そのプロバイダのタグが付いた上記のレコードは見えません。EC2 Cost EstimatorとAWS EC2 PricingナレッジベースにはAWS、Kubernetes Manifest ToolkitにはGCP、Secret Value GeneratorにはAzureが付いており、それぞれが補助するプロバイダのレコードと同じ扱いになります。Approval Requiredは 3 つのエージェントスキルすべてに付く普通のタグで、何も制限しません。 - デモユーザーとグループ:
| ユーザー | ロール | アクセス制御グループ | 役割 |
|---|---|---|---|
demo-aws-developer | developer | Demo AWS Group | EC2 起動ワークフローを生成する |
demo-aws-reviewer | reviewer | Demo AWS Group | EC2 起動ワークフローを公開する |
demo-aws-requester | requester | Demo AWS Group | EC2 起動ワークフローを実行する |
demo-gcp-developer | developer | Demo GCP Group | GKE Pod 再起動ワークフローを生成する |
demo-gcp-reviewer | reviewer | Demo GCP Group | GKE Pod 再起動ワークフローを公開する |
demo-gcp-requester | requester | Demo GCP Group | GKE Pod 再起動ワークフローを実行する |
demo-azure-developer | developer | Demo Azure Group | シークレットローテーションワークフローを生成する |
demo-azure-reviewer | reviewer | Demo Azure Group | シークレットローテーションワークフローを公開する |
demo-azure-requester | requester | Demo Azure Group | シークレットローテーションワークフローを実行する |
demo-approver-1、demo-approver-2 | approver | Demo Approvers(3 つのタグすべて) | 起動、Pod の再起動、またはローテーションを承認する |
いずれもロールを直接は持ちません。それぞれユーザーグループ Demo Developers、Demo Reviewers、Demo Requesters、Demo Approvers から継承します。AWS・GCP・Azure の3人組はそれぞれ、もう一つのグループ Demo AWS Group・Demo GCP Group・Demo Azure Group のいずれかにも所属します。このグループはロールを一切付与せず、対応するアクセス制御タグを保持するためだけに存在するので、その3人組だけがそのプロバイダのタグ付きレコードを見られ、それ以外には見えません。ただし admin(またはスーパー管理者)は例外で、アクセス制御タグを完全に素通りするため、グループに所属する必要すらありません。Demo Approvers 自体は AWS・GCP・Azure の 3 つのアクセス制御タグを直接持ちます。承認者は特定のプロバイダに縛られる立場ではないためで、これにより 3 つのデモワークフローのどれから来た承認依頼でも、デモ承認者のどちらかを宛先にできます。
試してみる
どの例も、生成、公開、実行、承認、結果の確認までを一気に通す手順がウォークスルーです。root で一度サインインし、デモアカウントを順になりすましで演じます。DEMO_PASSWORD で各アカウントにサインインし直しても同じことができます。誰が何をするかは上の表のとおりです。
Demo AWS Group・Demo GCP Group・Demo Azure Group はそれぞれ自分のプロバイダのレコードしか見えないため、demo-aws-developer は Demo GKE Pod Restart を開けず、demo-gcp-developer は Demo Azure Key Vault Secret Rotation を開けません。Demo Approvers は 3 つのアクセス制御タグすべてを直接持っているので、承認者アカウントはどの例でもどちらでも構いません。GKE の例を実際に動かすには、実際の GKE クラスタに届く権限を持つ身元の認証情報を DEMO_GCP_CREDENTIALS_JSON に設定しておく必要があります。ローテーションを実際に動かすには、DEMO_AZURE_* のサービスプリンシパルが実際の Key Vault のシークレットを書き込める必要があります。
AWS アカウントも GKE クラスタも Key Vault もない場合。 公開せず、draft のまま実行してください。developer であるそのプロバイダの開発者アカウント(demo-aws-developer、demo-gcp-developer、demo-azure-developer)はそれができ、ツールモックを選べる Run ダイアログが出るのはドラフト実行のときだけです。Mock tools に並ぶ同梱のスタブ(起動用の aws___call_aws または aws___run_script、Pod 再起動用の patch_k8s_resource または delete_k8s_resource、ローテーション用の keyvault_secret_get と keyvault_secret_create、request_approval)にチェックを入れれば、実際のプロバイダに届くことも人の承認を待つこともなく、ワークフローが最後まで動きます。ローテーションのモックを選んだ場合は Key Vault のシークレット一覧も作り物になるので、その中から db-password を選んでください。
削除する
DEMO_DATA=false にすると(または行を削除すると)、次の起動時にこれらのレコードが削除されます。どちらの方向にも宣言的に働くということです。
意図的に残るものが 2 つあります。ほかから依存されるようになったデモレコード(デモスキルの上に作られたワークフローなど)は、削除せずログに記録して残します。レコードを作成したデモユーザーは論理削除にとどめるので、そのレコード上で名前は引き続き解決できます。