要点
-
Agent Toolkit for AWS（AWS公式のMCPサーバー群）を Kiro に接続すると、
AIエージェントが AWS の現状を直接読み取ってくれる - 操作は すべて読み取り専用。AIに「読み取りだけで」と伝えれば、確認しながら進む
- 集めた「実機の事実」をもとに、draw.io のアーキテクチャ図を自動生成できる
- 既存案件で「設計書が古い・正しいか分からない」場合でも、
実機を"正"にして 構成を再現できるのが最大の利点 - 認証は IAM Identity Center（SSO）+ 読み取り専用ロール が安全でおすすめ
- 利用者がやることは、基本 AIに日本語で頼むだけ。スクリプトは書かない
背景
既存なシステムの運用を引き継ぐと、こういう壁にぶつかります。
- 設計書はあるが、最新かどうか確信が持てない
- 実際のリソース構成・監視設定がドキュメントとズレている
- 当時の担当者しか分からない暗黙知がある
AWS上に実在するリソースを正にして、そこから構成を起こせば、
ドキュメントの正しさに依存せず現状を把握できます。
使ったもの
| ツール | 役割 |
|---|---|
| Kiro | AIエージェント（IDE） |
| Agent Toolkit for AWS | AWS公式のMCPサーバー。AIにAWSアクセス能力を与える |
| aws-architecture-diagram | 実機情報から draw.io 図を生成するKiroのAgent Skill |
| AWS CLI (SSO) | ローカルの認証状態を作る |
セットアップ
1. AWS MCP Server を Kiro に追加
Kiro の MCP 設定ファイル（~/.kiro/settings/mcp.json）に AWS MCP Server を追加します。
{
"mcpServers": {
"aws": {
"command": "uvx",
"args": [
"mcp-proxy-for-aws-cli@latest",
"https://aws-mcp.us-east-1.api.aws/mcp",
"--metadata",
"AWS_REGION=ap-northeast-1"
],
"env": {
"AWS_PROFILE": "<your-sso-profile>"
}
}
}
}
前提:
uv（uvx）がインストール済みであること。
社内プロキシ/SSLインスペクション環境では、envに証明書パス
（SSL_CERT_FILE/REQUESTS_CA_BUNDLE/AWS_CA_BUNDLE/UV_NATIVE_TLS=true）を
追加するとTLSエラーを回避できます。
2. SSO でログイン（推奨）
アクセスキーより、IAM Identity Center（SSO）+ 読み取り専用ロール を推奨します。
# 初回のみ: SSO設定を作成
aws configure sso
# 以降: セッションが切れるたびにログイン
aws sso login --profile <your-sso-profile>
設定後、Kiro の MCP Server ビューで再接続すれば準備完了です。
3. 作図スキル（aws-architecture-diagram）を導入
npx skills add ... で一式入れることもできますが、今回は
必要なこのスキルだけを、Kiro の Agent Skills 機能から GitHub URL 指定で入れました。
- Kiro の機能パネルから Agent Skills のセクションを開く
- GitHub URL からのインポートを選び、次のURL（スキルのディレクトリ）を指定する
https://github.com/awslabs/agent-plugins/tree/main/plugins/deploy-on-aws/skills/aws-architecture-diagram
やりとりの流れ
ここからが本題です。実際に Kiro と交わした「頼みごと」と「返ってきたもの」を紹介します。
「現状を全部まとめて教えて」と頼む
🙋 AIへの依頼
「東京リージョンのstg環境について、現状を読み取り専用で棚卸しして。
① どんなリソースがどれだけあるか（タグや命名規則も）
② VPC構成と、各Lambdaが何に繋がっているか
をまとめて教えて」
🤖 返ってきたもの
① リソースの全体像
- リージョン内のリソース総数（例: 数百件）とサービス別の内訳
（RDS ◯件、Lambda ◯件、CloudFormation ◯件 …）- 使われているタグとその値（
Environment: dev/stg/prod、Project: xxx）、命名規則② 構成と接続関係
- VPC / サブネットの構成（AZ配置、公開/非公開）、Aurora の構成
- 各Lambdaのトリガー（SQSなど）と接続先
（環境変数から判明したSES・外部APIなど）
設計書を一切見ずに、実機環境を把握できます。
また、設計書を眺めていたら気づけなかった「監視の抜け」が、実機の棚卸しで一発で見えます。
💡 ハマりどころ: 同じ「読み取り専用」でも、ロールによって読める範囲が違います。
あるロールではDescribeAlarmsが拒否されてAccessDeniedになる可能性があります。
（AIがエラー内容を読んで「このロールにこの権限が無い」と教えてくれます）
💡 安全確認を先にしたいなら（任意）: いきなり本番で不安な場合は、
最初に「GetCallerIdentity だけ実行して、どのロールで繋がっているか確認して」と
頼むと、AIがアカウントIDと接続ロール（ARN）だけを返します。
ARN に...ReadOnly...と出ていれば読み取り専用で繋がっている証拠です。
実機情報から draw.io 図を自動生成
集めた「実機の事実」をもとに、いよいよ図を起こします。
Kiro の aws-architecture-diagram スキルが、AWSリファレンスアーキテクチャ風の
draw.io 図を生成してくれます。
🙋 AIへの依頼
「今まで取得した実機情報をもとに、アーキテクチャ図を draw.io で作って」
🤖 返ってきたもの
.drawioファイル（VS Codeの拡張や app.diagrams.net で開ける）- VPC/サブネット境界、AWSアイコン、外部連携まで反映した構成図
- 確証レベルを線種で区別（実線=確認済み / 破線=推定）
AIが勝手に見栄えの良い図を作るのではなく、実機から取った事実に基づいて描くので、
「この接続は本当に存在する」「ここは推定」が図の上で区別できます。
やってみて分かったこと
良かった点
- 設計書ゼロでも構成が起こせること
- 接続が実データで取れる。Lambdaの環境変数などから、推測を事実に昇格できる
- 実装or設計の抜けが可視化できる
- 既存件名をAI-readyまで持っていくために、実環境の棚卸し
- 利用者はAIに日本語で頼むだけ。収集も作図も修正も、対話で進む
注意点・ハマりどころ
- 権限はロール次第。「読み取り専用」でもサービスごとに許可の有無が分かれる
-
SSOセッションは数時間で切れる。切れたら
aws sso loginし直す - AI生成のシステム図は少し見づらくて、有識者の改修が必要
まとめ
-
Kiro + Agent Toolkit for AWS で、AWS実機から現状を読み取り、
そのままアーキテクチャ図まで起こせた - 利用者がやることは、基本 AIに日本語で頼むだけ
- 既存案件の「設計書が信用できない」問題に対して、
実機を正とするアプローチが有効 - 収集は読み取り専用で安全に。認証は SSO + 読み取り専用ロール を推奨
既存システムの難しさは「設計書が正しいとは限らない」点にあるので、
上記のアプローチでは現状をいつでも正確に把握できます。
既存運用をAI-ready化する第一歩として試す価値がありました。