【インフラエンジニアのKiro活用】基本設計書と実環境の乖離をAIで洗い出す

はじめに

インフラエンジニアの皆さん、こんな状況に心当たりはないでしょうか。

• 数年前に書いた基本設計書がある
• 運用中に「ちょっとした変更」が積み重なっている
• 設計書と実環境がどれくらいズレているか、正直わからない

定期的な棚卸をしていても、最後は実環境にログインして目視確認。設計書のページをめくりながらコンソールと見比べる。数十台のEC2、数十個のセキュリティグループ、CloudWatchアラームの設定……。正直、気が遠くなる作業です。

今回はKiroにAWS CLIを叩かせて、実環境の設定情報をReadOnlyで取得し、基本設計書に準拠していない項目を自動で洗い出すということをやってみました。

やりたかったこと

• 実環境からReadOnlyで構成情報を取得する（Describe/List/Get系APIのみ）
• 基本設計書（Word）に記載されている設計規約・命名規則・構成定義を読み取る
• 実環境が設計書に準拠しているかを突き合わせる
• 非準拠の項目をリストアップする

人間がやると数日かかる監査作業です。

構成

workspace/
├── 基本設計書.doc          # 既存の設計書（Word形式）
└── output/
    └── compliance_report.md # 出力される非準拠レポート

AWS CLIの準備（ReadOnlyで安全に）

Kiroはターミナルでコマンドを実行できるので、AWS CLIが使える状態であればそのまま叩いてくれます。ポイントはReadOnly権限のプロファイルを使うことです。

# ~/.aws/config に ReadOnly 用のプロファイルを用意
[profile readonly-audit]
sso_start_url = https://your-org.awsapps.com/start
sso_account_id = 123456789012
sso_role_name = AWSReadOnlyAccess
region = ap-northeast-1

事前にログインしておけば、KiroがCLIを叩くときにこのプロファイルが使われます。

aws sso login --profile readonly-audit

ReadOnlyで実行するメリット：

• フェイルセーフ: AIが万が一変更系のコマンドを叩こうとしても権限不足で弾かれる
• 事故防止: 承認ダイアログを見落としても実害がない
• 監査対応: 「読み取りしかできない権限で実行した」と説明できる

Control Tower環境なら、既存の AWSReservedSSO_AWSReadOnlyAccess 権限セットをそのまま使えます。

Kiro でどうやったか

1. Kiro に整合性チェックを依頼

Vibeモードで以下のように依頼しました。

「基本設計書.docの内容を読み込んで、AWS CLIで実環境の設定情報を取得し、設計書に準拠していない項目をリストアップしてください。プロファイルは readonly-audit を使ってください」

2. Kiro が自動で行ったこと

Kiroは以下を自動的に実行してくれました：

1. 設計書の読み込み: Word文書から命名規則、ネットワーク設計、監視設計、セキュリティ設計を抽出
2. AWS CLIの実行: 設計書の各章に対応するDescribe系コマンドをターミナルで実行
3. 突き合わせ: 設計書の規定 vs CLI出力のJSON を比較
4. 非準拠レポート出力: 準拠していない項目を一覧化

Kiroが実際に叩いたCLIコマンドは以下の通りです（すべて --profile readonly-audit 付き）：

設計書の章	実行されたCLIコマンド
EC2設計	aws ec2 describe-instances
ネットワーク設計	aws ec2 describe-vpcs, describe-subnets, describe-route-tables, describe-nat-gateways, describe-internet-gateways
セキュリティグループ	aws ec2 describe-security-groups
DirectConnect	aws directconnect describe-connections, describe-virtual-interfaces
ELB設計	aws elbv2 describe-load-balancers, describe-target-groups, describe-listeners
RDS設計	aws rds describe-db-instances, describe-db-clusters
S3設計	aws s3api list-buckets, get-bucket-encryption, get-bucket-lifecycle-configuration, get-bucket-policy
IAM設計	aws iam list-roles, list-policies, get-role-policy
監視設計	aws cloudwatch describe-alarms
通知設計	aws sns list-subscriptions-by-topic
バックアップ設計	aws backup list-backup-plans, aws rds describe-db-snapshots
WAF設計	aws wafv2 list-web-acls, get-web-acl
ログ/監査設計	aws cloudtrail describe-trails, aws config describe-config-rules

設計書を読んで「何を確認すべきか」をKiroが判断し、必要なコマンドを自分で組み立てて実行してくれます。人間が全部のコマンドを覚えている必要はありません。

Kiroが自分でCLIコマンドを組み立てて実行し、返ってきたJSONを解釈して設計書と比較してくれる。ここが手動との大きな違いです。

3. 検出された非準拠項目の例

実際に検出された非準拠項目はこのような形で出力されます：

EC2 命名規則違反

設計書に「{環境}-{システム名}-{役割}-{連番} の形式で命名すること」と規定されているのに対し、規則に従っていないインスタンスが検出されました。

【非準拠】EC2 命名規則
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
設計書の規定:
  命名規則: {環境}-{システム名}-{役割}-{連番}
  例: prd-webapp-ap-01

検出された違反 (aws ec2 describe-instances):
  - i-0abc1234: Name = "test-server" ← 規則に不適合
  - i-0def5678: Name = (タグなし) ← Nameタグ未設定
  - i-0ghi9012: Name = "Tanaka_test" ← 個人名使用
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CloudWatch 監視設定漏れ

設計書に「全EC2インスタンスに対してCPU/メモリ/ディスクのアラームを設定し、SNS経由で通知すること」と規定されているのに対し、アラームは存在するがSNSアクションが未設定のものが検出されました。

【非準拠】CloudWatch 監視設定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
設計書の規定:
  - 全EC2にCPU使用率アラーム（閾値80%）を設定
  - アラーム発報時にSNSトピックへ通知すること

検出された違反 (aws cloudwatch describe-alarms):
  - アラーム "prd-webapp-ap-01-cpu" 
    状態: OK
    問題: AlarmActionsが空 ← SNSトピックが紐付いていない
  - アラーム "prd-batch-01-cpu"
    状態: OK  
    問題: AlarmActionsにSNSトピックARNあり、
          ただしSNSトピックのSubscriptionが0件
          ← トピックはあるが通知先が未設定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

この例が特に面白くて、「アラーム自体は設定されている」「SNSトピックも紐付いている」のに「トピックにサブスクリプションが無い」というパターン。Kiroは describe-alarms でアラームのActionsを確認した後、さらに list-subscriptions-by-topic でサブスクリプションの有無まで追跡してくれました。人間の目視チェックでは見落としがちな部分です。

セキュリティグループの設計乖離

設計書に「WebサーバーのSGはHTTP(80)とHTTPS(443)のみ許可」と規定されているのに対し、実環境では追加のポートが開いていたケースです。

【非準拠】セキュリティグループ設定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
設計書の規定:
  sg-web (Webサーバー用):
    Inbound: TCP/80 (0.0.0.0/0), TCP/443 (0.0.0.0/0)
    Outbound: All traffic

実環境の設定 (aws ec2 describe-security-groups):
  sg-0abc1234 (sg-web):
    Inbound: TCP/80 (0.0.0.0/0)  ← OK
             TCP/443 (0.0.0.0/0) ← OK
             TCP/8080 (0.0.0.0/0) ← 設計書に無いルール
             TCP/22 (10.0.0.0/8)  ← 設計書に無いルール

検出された違反:
  - TCP/8080が全開放されている（設計書に記載なし）
  - SSH(22)が10.0.0.0/8に開放されている（設計書に記載なし）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

「AWS Config でやればいいのでは？」について

本来、こういったコンプライアンスチェックは AWS Config のルールで実現するのがベストプラクティスです。マネージドルールやカスタムルールを設定すれば、継続的にリソースの準拠状況を監視できます。

ただ、実際のところConfig をそこまで作り込んでいる現場は少ないのではないでしょうか。

• マネージドルールは汎用的で、「うちの命名規則に準拠しているか」のような独自ルールには対応できない
• カスタムルールは Lambda を書く必要があり、導入・保守のコストが高い
• 「CloudWatch アラームに SNS が紐付いているか」→「そのSNSにサブスクリプションがあるか」のような複数リソースを横断するチェックは Config 単体では実装が面倒
• Config は有効にしているけど、マネージドルール数個だけ。評価結果を定期的に確認する運用も回っていない

もちろん、Config でルールを作り込めるならそれに越したことはありません。継続的・自動的に監視してくれるのは Config の強みです。

ただ、「そこまでの投資はまだできないけど、設計書との乖離は気になる」という温度感の環境には、Kiro + AWS CLI のアプローチがフィットします。Config より手軽で、チェック内容も自然言語で柔軟に指定できる。Config ルールを書くための事前調査として使うのもアリです。

何が嬉しいのか

「見落としがちな非準拠」を拾える

上述のCloudWatchの例のように、「一見設定されているように見えるが、実は機能していない」パターンをAIが検出してくれます。人間のチェックリストでは「アラーム設定あり → OK」で通してしまいがちですが、Kiroは関連リソースまで芋づる式に確認してくれました。

CLIコマンドを自分で考えなくていい

「この設計規定を確認するにはどのCLIコマンドを叩けばいいか」を考える必要がありません。Kiroが設計書の記載内容から適切なCLIコマンドを判断して実行してくれます。JSONの出力を読み解くのもAIがやってくれる。

設計書のどの記載に対する違反かが明確

単に「こんなリソースがあります」ではなく、「設計書のこの規定に対してこう違反している」という形で出力されるので、是正のアクションが取りやすい。

ReadOnlyなので安心して実行できる

本番環境に対して実行しても、読み取りしかしないので事故のリスクがゼロです。「まず現状を把握する」フェーズでは最強の安心感です。

特別なツール導入が不要

AWS CLIさえ入っていれば動きます。MCPサーバーの追加セットアップやエージェント用のIAMロール作成は不要。既存の運用環境にそのまま適用できます。

注意点

設計書の記載粒度に依存する

設計書に「命名規則は○○とする」と明確に書いてあればKiroも判定できますが、曖昧な記載（「適切に設定すること」など）だと判定が難しくなります。設計書自体の品質が問われます。

CLIの実行回数と時間

EC2が数十台、SGが数十個、アラームが数百個あるような環境では、CLIの実行回数が多くなり処理に時間がかかります。Kiroは必要に応じてコマンドを分割実行してくれますが、大規模環境では対象を絞って実行するのが実用的です。

「設計変更承認済み」の判別ができない

実環境が設計書と違っていても、それが「変更管理プロセスを経て承認済みの変更」なのか「無断変更」なのかはAIにはわかりません。検出結果は人間が判断する必要があります。

Wordの読み取り精度

設計書が複雑な表や図を多用している場合、Kiroが内容を正確に読み取れない場合があります。特に図形内のテキストや複雑なネスト表は注意が必要です。

実務での活用シーン

シーン	効果
定期監査（月次/四半期）	設計乖離の早期検出
引き継ぎ時の現状把握	「設計書通りに動いているか」の確認
セキュリティ監査対応	SG/NACLの設計準拠確認
障害発生時の原因調査	「設計と違う設定」が障害原因かの確認
更改提案の事前調査	現状の非準拠項目の把握

まとめ

基本設計書と実環境の突き合わせは、インフラ運用における永遠の課題です。設計書は書いた瞬間から陳腐化が始まり、運用中の「ちょっとした変更」が積み重なって、いつの間にか設計書と実環境が別物になっている。

KiroにAWS CLIを叩かせれば、ReadOnlyで安全に実環境の情報を取得し、設計書と自動で突き合わせて非準拠項目を洗い出せます。特に「アラームのSNSトピックにサブスクリプションが無い」のような、人間が見落としがちな問題を検出できるのが強みです。

特別なツールの追加導入は不要で、AWS CLIとKiroさえあれば今すぐ試せます。完璧な監査ツールの代替にはなりませんが、「まず現状を把握する」「大きな乖離を検出する」という初動としては十分すぎる精度でした。

環境情報

• Kiro 0.12.x
• AWS CLI v2（ReadOnlyプロファイルで実行）
• 対象: 本番AWS環境（ReadOnlyAccess権限）
• リージョン: ap-northeast-1
• 所要時間: 設計書読み込み〜非準拠レポート出力まで約5分