Claude Code（など）で進める「AI × AWS開発」実践フロー：設計→IaC→図面化まで
AWSで何か作りたいけど、
- まず何を作るか曖昧
- アーキ検討で迷子になる
- IaCを書き始めると手戻りが増える
- 図面やドキュメント更新が後回しになる
…みたいな状態、よくあります。
この記事では AIコーディングツール（Claude Code等）を相棒にして、設計→IaC→図面化までを一気通貫 で回すやり方を紹介します。
（特定ツール依存ではなく、考え方と手順に寄せています）
最後に自身が使っているclaudeのAWS用rulesを掲載します！
TL;DR（先に結論）
- 最初はAIと壁打ちして「作るもの」と「必要なAWSリソース」を具体化する
- 固まったら Plan（実装チェックリスト付き） をMarkdownで作る
- IaC（CloudFormationなど）で実装し、テンプレの規約・命名・セキュリティを機械的に守る
- 最後に IaC→draw.io図 + データフロー説明 を自動生成して、Planとの差分を目視確認する
前提
- AWSは IaC（Infrastructure as Code） で管理する（CloudFormation / CDK / Terraform 等）
- AIは「設計補助」「雛形生成」「レビュー観点の抜け漏れ防止」「ドキュメント生成」に強い
- 機密情報（実アカウントID、社内URL、IP、固有の運用情報、秘密鍵、シークレット）はプロンプトに入れない
全体フロー（これだけ覚えればOK）
- 壁打ちで要件を具体化
- PlanをMarkdownで固定（チェックボックス化）
- IaCを生成・修正
- lint/validate/testで機械的に検証
- IaCから図面（draw.io）とデータフロー説明を生成
- Planと差分がないか目視レビュー
1. まずは「壁打ち」で設計を固める
最初にやるべきは、いきなり実装ではなく 会話で要件を尖らせること です。
プロンプト例
- 「◯◯をするアプリを作りたい。AWSで必要なリソース候補を挙げて」
- 「前提条件：同時接続数、想定データ量、SLA、コスト上限、リージョン制約はこれ。アーキ案を2〜3案出して、メリデメ比較して」
- 「セキュリティ・運用（ログ、監査、暗号化、アラート）まで含めた設計観点で不足を洗い出して」
ポイントは、AIに一発回答を期待せず 追加条件を与えながら“収束”させる ことです。
2. PlanをMarkdown化して“手戻り”を減らす
会話で形になってきたら、次は Plan（実装プラン）を文章で固定 します。
おすすめは、タスクをチェックボックスにして「進捗と抜け漏れ」を見える化する方法。
Plan.md のイメージ
- VPC / Subnet / RouteTable（必要なら）
- セキュリティグループ設計
- ALB or API Gateway
- ECS / Lambda / Batch など実行基盤
- IAM最小権限
- ログ（CloudWatch / ALBログ / CloudTrail）
- 暗号化（KMS or デフォルト暗号化）
- デプロイ手順（Change Set等）
- 図面更新（draw.io）
- データフロー説明更新
3. IaCで実装する（CloudFormation例）
AIにAWSリソースを作らせるなら、IaCで作る のが圧倒的に安全です。
理由は「差分が見える」「レビューできる」「再現できる」から。
生成をうまく回すコツ
- まずAIに「テンプレの雛形」を出させる
- 次に「既存の規約に合わせて整形して」と指示して寄せる
- 1回で完璧を狙わず、差分を小さく刻んで直す
4. CloudFormationの“規約”を先に決めておく（重要）
AIは放っておくと書き方がブレます。
なので、テンプレのスタイルや命名規則、セキュリティ観点は 最初からルール化 しておくのが効きます。
例：テンプレの基本スタイル
- YAMLで書く / インデントは2スペース
- セクション順を固定（Parameters→Mappings→Conditions→Resources→Outputs）
例：命名（チームで揃えると強い）
- 論理ID：
サービス名 + 用途 + 番号（例：AppAlb,AppAlbListener） - 実リソース名：
{ProjectPrefix}-{Env}-{名前}（例：FT-dev-ApiGateway）
例：セキュリティの最低ライン
- IAMで
Action:"*"/Resource:"*"を原則避ける（最小権限） - シークレットはテンプレに直書きしない（Secrets Manager / SSM）
- 暗号化を有効化（KMS or デフォルト暗号化）
- ログを無効化しない（CloudTrail等）
5. 検証（lint / validate / テスト）を“必ず”通す
AI生成は便利ですが、検証しないと事故る ので、ここは自動化前提で。
-
cfn-lint（構文・ベストプラクティスチェック） -
aws cloudformation validate-template（CloudFormationの検証） - 必要なら
taskcat等で統合テスト
6. IaCから「図面」と「データフロー説明」を自動生成する
最後に効くのがここです。
AIに、
- 「このCloudFormationを読んで、作成されるリソースを draw.ioファイル として出力して」
- 「データの流れが分かる 文章（Markdown） を書いて」
と指示して、実装の最終成果物を“設計図”に戻す。
そして Planと差分がないか目視確認 します。
これをやると、ドキュメントが腐りにくくなります。
おまけ：MCPやエージェントを使うと何が嬉しい？
（使える環境なら）AIが外部知識やツールにアクセスできる仕組みを入れると、
- AWS公式ドキュメント参照
- IaC生成の精度UP
- 運用トラブルの原因調査の補助
などが効いてきます。
ただし組織のセキュリティポリシー・データ持ち出し規約は必ず守りましょう。
まとめ
AIをAWS開発に使うコツは
- 壁打ちで設計を収束
- Planを固定して手戻りを減らす
- IaCで差分管理し、規約とセキュリティを守る
- IaC→図面化で“設計に戻す”
という 開発プロセスの型 に落とし込むことでした。
もし同じように「設計からドキュメントまで一気に整えたい」人の参考になれば嬉しいです。
また、こっちの方が良いなどあれば、コメントをお願いします。
rules
.claude/rules/aws/AWS.md となるように、設置してください。
# CloudFormationガイドライン
## Claudeの役割
- このリポジトリではAWS CloudFormationテンプレートの追加・修正を主なタスクとする。
- 既存テンプレートのスタイル・構成を尊重し、それに合わせて変更する。
- アプリケーションコードは、CloudFormationからの参照に必要な場合のみ最小限で変更する。
## 設計図
- 作業の終わりには，必ず設計図を作成してください．
1. CloudFormationで作成されるリソースの図を draw.ioで作成し， architecture.drawio として保存してください．
2. データの流れがわかる図を， architecture.md として保存してください．
## ディレクトリ構成
- `templates/`: メインのCloudFormationテンプレート(YAML)
- `templates/network/`: VPC / Subnet / RouteTable などのネットワークレイヤー
- `templates/app/`: アプリケーション用のリソース(ALB, ECS, Lambda など)
- `templates/shared/`: 共通のIAMロール / KMS / LogGroupなど
- `scripts/`: デプロイ補助スクリプト
## テンプレートのスタイル
- 必ずYAML形式で記述する。
- インデントは 2スペース。タブは禁止。
- `AWSTemplateFormatVersion` と `Description` は必ず記載する。
- `Parameters` → `Mappings` → `Conditions` → `Resources` → `Outputs` の順にセクションを並べる。
## 命名規則 / タグ
- CloudFormation の論理 ID（`Resources` セクションのキー）は、これまでどおり
- `サービス名 + 用途 + 番号` 形式（例: `AppAlb`, `AppAlbListener`, `AppEcsTaskRole`）とする。
- 実リソース名（`Name` タグや、サービス固有の名前プロパティ）は、
- 原則として `{ProjectPrefix}-{Env}-{動作関係の名前}` 形式とする。
- `{ProjectPrefix}` には、このプロジェクトごとに割り当てられた **大文字2文字のプレフィックス** を使用する。
- 例: `FT`, `AB`, `XY` など。
- ProjectPrefix はユーザに聞くことにする．
- 例:
- `FT-dev-ApiGateway`
- `FT-stg-BatchJob`
- `AB-prod-BackendAlb`
- `{Env}` は `dev` / `stg` / `prod` を使用する。
## CloudFormation 設計方針
- 環境ごとに変わる値は `Parameters` で受け取る。`Mappings` や `Conditions` で環境ごとの差分を表現する。
- 同じ値を複数リソースで再利用するときは `!Ref` または `!Sub` を使う。
- 他スタックから参照される可能性がある値（VPC ID, Subnet IDs, SecurityGroup IDs など）は `Outputs` としてエクスポートする。
- ハードコードされた ARN / ID は避け、`!Ref`, `!GetAtt`, `!ImportValue` を優先する。
## セキュリティ / ガバナンス
- IAM ポリシーでは `"Action": "*"` や `"Resource": "*"` を原則禁止する。必要なアクションのみ列挙する。
- シークレット値（パスワード、API キーなど）はテンプレート内に直接書かない。
- Secrets Manager または SSM Parameter Store を利用する。
- 可能なリソースでは暗号化を有効化する（KMS またはデフォルト暗号化）。
- ログ（CloudTrail, ALB アクセスログ, アプリケーションログ）を無効化しない。
## テスト / 検証 / デプロイ
- テンプレートを変更したら、PR 提出前に必ず次を実行する：
- `make lint` または `cfn-lint templates/**/*.yaml`
- `make validate` または
- `aws cloudformation validate-template --template-body file://PATH/TO/template.yaml`
- 統合テストが必要な場合:
- `taskcat test run` または `make integration-test`
- これらのコマンドを実行し、失敗した場合は自分で修正を試みる。
- 修正できない場合は、失敗したコマンドとエラーメッセージを PR 説明に残す。
## PR / レビュー方針
- 変更は可能な限り小さな単位に分割する。
- 破壊的変更の可能性がある場合は CloudFormation Change Set を作成し、その内容を PR 説明で共有する。
- PR 説明には「目的」「変更内容」「実行したテストと結果」を含める。
## あいまいな要件への対応
- 要件があいまいな場合や既存設計の意図が不明な場合、
- 仮定で進めるのではなく、コメントや TODO で質問を残し、人間の判断を求める。
- リスクが高い変更（ネットワーク構成変更、データベース関連など）の場合は、
- 複数案（例: パターン A, B）を提案し、どれを採用すべきか人間に選んでもらう。