はじめに
かつてはAWSやAzureに代表されるパブリッククラウドは、単体利用のケースが多かったかと思いますが、ここ数年来、耐障害性や拡張性を考慮して、マルチクラウドで利用するケースが増えてきているかと思います。その一方で、個々のクラウドのエキスパートは年々増加傾向にあるものの、マルチクラウド運用では片方のクラウドだけでの知識やスキルでは不足し、両方のクラウドに対する知見や勘所が必要になってくると思います。
私自身もありとあらゆるクラウドベンダーのサービスや設計思想を完全理解できているわけではないので、自身の不足している知識を補えるマルチクラウド活用を支援してくれるAIエージェントがあればいいなと思ってきました。
そのような課題を解決すべく、先日社外のAWS JawsユーザーズグループAI/ML支部にて、AWS Kiroを使って、AWSとAzureを横断したマルチクラウド活用を支援してくれるスキルを作成してみて、そこで得られた知見を共有するLT(ライトニングトーク)を行いました。その時の資料は下記になります。
今回、同じ解決方法を、AWSとGCP(Google Cloud Platform)をマルチクラウド活用する場合にも応用できると考え、スキルの横展開として、AWSとGCPを横断したマルチクラウド活用支援スキルをAWS Kiroを使って作成してみましたので、スキルの作成方法や実際にスキルを使ってみて得られた気づきを纏めてみました。
事前準備
今回作成するスキルでは、以下4つのMCPサーバーと、過去に作成した「terraform-aws」、「terraform-gcp」スキルを活用します。
AWS MCPサーバー
AWSのドキュメントにアクセスして、各々のAWSサービスに関する情報を取得したり、AWSのベストプラクティスやサービスガイドを提供してくれるMCPサーバーです。
Google Developer Knowledge MCPサーバー
Google Cloudのドキュメントにアクセスして、各々のGoogle Cloudサービスに関する情報を取得したり、Google Cloudのベストプラクティスやサービスガイドを提供してくれるMCPサーバーです。
Terraform MCPサーバー
現行のTerraformプロバイダーが提供しているTerraformレジストリーから、現行のドキュメント・モジュール・ポリシーをリアルタイムでアクセスし、最新情報をAIに提供してくれるMCPサーバーです。
drawio MCPサーバー
drawioフォーマットでアーキテクチャ図等を作画してくれるMCPサーバーです。
今回はWindows版のKiroでMCPサーバー接続を行いましたが、Node.jsがv24.xx.xxとかだとWindows版のNode.jsのバグとかで接続ができませんでした。安定板のv22.23.2をご利用ください。
上記4つのMCPサーバーをAWS Kiroのmcp.jsonファイルに下記のように登録します。
{
"mcpServers": {
"aws-mcp": {
"command": "uvx",
"timeout": 100000,
"transport": "stdio",
"args": [
"mcp-proxy-for-aws@latest",
"https://aws-mcp.us-east-1.api.aws/mcp",
"--metadata", "AWS_REGION=ap-northeast-1"
]
},
"google-developer-knowledge": {
"url": "https://developerknowledge.googleapis.com/mcp",
"headers": {
"X-Goog-Api-Key": "YOUR_API_KEY"
},
"disabled": false
},
"terraform": {
"command": "C:/Users/userid/terraform-mcp-server.exe",
"transport": "stdio"
},
"drawio": {
"command": "npx",
"args": [
"-y",
"@drawio/mcp"
],
"disabled": false
}
}
}
その後、AWS KiroのMCP画面上で、これら4個のMCPサーバーが接続状態になっていることを確認してください。
terraform-aws/terraform-gcpスキル
IBM Bobで作成したAWS、GCPのTerraformコード生成を行うスキルになります。詳細は下記の記事をご参照ください。
AWS Kiroを活用したスキル作成
スキルはグローバル設定とし、スキル名は「aws-gcp-multi」としました。ファイル構造は下記の通りです。
C:.kiro
└─skills
├─aws-gcp-multi
│ SKILL.md
├─terraform-aws
│ SKILL.md
├─terraform-gcp
│ SKILL.md
ある程度AIに実施させたい作業方針を自分なりに整理した上で、今回はAWS Kiroに下記のようなプロンプトを入力して、スキルを作成してもらいました。
あなたはAWSとGGP(Google Cloud Platform)両方のスキルをもったエキスパートです。両者をマルチクラウド利用する場合の設計・構築・運用観点での考慮点やHint&Tips等、適切なガイドを行うスキルを作成してください。
・スキル名:aws-gcp-multi
・AWS側の考慮点やHint&Tipsについては、既存の「aws-mcp」MCPサーバーにアクセスして、必要な情報を抽出しガイドを行う。
・GCP側の考慮点やHint&Tipsについては、既存の「google-developer-knowledge」MCPサーバーにアクセスして、必要な情報を抽出しガイドを行う。
・アーキテクチャー構成図については、下記の要領て作成を行う。
- AWS側の構成図(アーキテクチャー)については、既存の「drawio」MCPサーバーにアクセスし、URL(https://aws.amazon.com/jp/architecture/icons/ )にあるAWSアーキテクチャアイコンを用いて作画する。
- GCP側の構成図(アーキテクチャー)については、既存の「drawio」MCPサーバーにアクセスし、URL(https://cloud.google.com/icons?hl=ja#google-cloud-product-icons )にあるGCPプロダクトアイコンを用いて作画する。
- 最後は、「drawip.png」フォーマットでファイルを「aws-gcp-architecture.draw.png」としてPC上のフォルダに保存する。
・照会者の必要に応じて、「terraform-aws」や「terraform-gcp」といったスキルを活用して、希望の環境をプロビジョニングするAWSあるいはGCP環境のTerraformコード作成を行う。
その後、Kiro君はこちらが指定したMCPサーバーを使用して、AWSやGCPの情報を抽出し、スキルを作成してくれました。

最終的なSKILL.mdファイルとREADMEについては、下記リンク先のGitHubリポジトリに公開していますので、ご参照ください。
スキルの稼働確認
AWS Kiroのチャットウィンドウ上で「/」コマンドを入力し、「aws-gcp-multi」スキルを選択した上で、下記のような内容のプロンプトを投げて検証してみました。
現在、下記のAWS構成で運用しています。
■AWS構成
・東京リージョンにVPCを1個配置。(AZは2個使用)
・VPC内にはAZあたり、プライベートサブネットを3個(Webサーバー用、APLサーバー用、DBサーバー用)用意し、ALBで負荷分散を実施。
今後、GCPでも同じような構成を組む予定ですが、制約や考慮点等があれば教えてください。
Kiro君は必要なMCPサーバーにアクセスして調査を行い、制約や考慮点の纏めを開始します。

最終的に下記のような制約や考慮点を纏めて教えてくれました。

個人的にはサブネットについてはAWSもGCPも同じだと思っていたのですが、Kiro君の纏めを元に改めてGCPのマニュアルを見たところ、確かにGCPの場合サブネットはリージョナルリソースであり、作成時にリージョンは指定するものの、ゾーン(AWSのAZに相当)を明示的に指定するといった設定はありませんでした。
スキルを作成して使ってみて、自分が如何に誤った理解をしたまま今日まで来たかということを強く思い知らされました。。ここは反省が必要ですね。
その他にも、ロードバランサーや、DBサーバーへのアクセス、ファイアーウォールのかけ方等に大きな違いが見られました。


結構な差異が見られたので、AWSの3層アーキテクチャをGCPで再現する場合のアーキテクチャ図も作成してもらいました。いくつか修正してもらいましたが、最終的に下記のようなアーキテクチャ図を作成してくれました。

今回得られた気づき
今回、AWSとGCPのマルチクラウド活用支援スキルを作成して、実際に使ってみた所感としては下記になります。
誤った理解をしていることに気づくことができる。
個人的には5年程前からマルチクラウドエンジニアを目指してきており、AWS/Azure/GCPいずれも同じ位理解していたつもりでしたが、今回のスキル稼働検証を実施したことにより、理解したつもり(誤った理解)になっていたことを強く痛感させられました。その為、今回のAWSとGCPのサブネットの違いに関して改めて理解し直すべく、次のようなプロンプトを追加で入力してみました。
GCPのサブネットはリージョナルリソースということで、ゾーン単位に作成が必要なものではなく、リージョンに1個作成すれば複数ゾーンを跨って利用可能と理解しました。
これを受けて、Kiro君は改めてこの点の違いについて説明してくれました。

誤った理解はそのままにせず、その場で理解するようにすれば、頭に残りやすくなるかなと思います。
パブリッククラウド1つは深く理解しておく方が良い
マルチクラウド活用支援スキルを使って壁打ちするにしても、どのパブリッククラウドも理解度レベルが少なくては質問時の初期プロンプトの入力に困ってしまうと思います。その為、AWSやAzure、GCPの少なくともどれか1つは深く理解しておく必要があると思いました。その上で、残りのパブリッククラウドについても更にスキル強化していこうと思います。
おわりに
今回は、以前にAWS Kiroで作成したAWS/Azureのマルチクラウド活用支援スキルの応用編として、AWS/GCPのマルチクラウド活用支援スキルを作成して、実際に使ってみて得られた気づきを纏めてみました。
これまで、様々な投稿記事において、「スキルは育てるもの」と書いてきましたが、AIだけでなく人間のスキルも「育てるもの」であることに違いは無いと思います。改めて、真のマルチクラウドエンジニアとなるべく、今後も幅広いパブリッククラウドのスキルを身に着けていきたいと思います。