MEGAZONE株式会社 Tech BlogPublicationへの投稿
☁️

Codex CLI x AWS CDK x cdk-nag で進める AWS インフラ実装プロセス

Dawn Craft
に公開
AWS
AWS CDK
Model Context Protocol
Codex
tech

1. はじめに

  • 本記事では、Coding AI ツールを活用して AWS インフラ用の IaC コードを実装する流れを、簡単なサンプルを題材に紹介します
  • Coding AI ツールとしては Codex CLI を、IaC ツールとしては AWS CDK を採用しています
    • ただし、本記事で言及している内容は 類似のツールであれば、細部や作法は違えど実現できると思います
  • セキュアさを担保する手段として cdk-nag を併用します
    • cdk-nag: CDK コードをベストプラクティスに沿ってチェックするツール
  • AWS 関連のナレッジを補強する手段として、AWS 提供の MCP サーバーを使います

免責事項

  • Coding AI ツールは非常に速いペースで進化しているため、数か月も経過すれば本記事の内容が陳腐化する可能性もあります
    • 記事を執筆している最中にも、既に Gemini 3 Pro, Claude Opus 4.5, Antigravity などが矢継ぎ早に登場し、状況が変化しています😅
    • 本記事は2025年後半時点の取り組みの一例として参照いただければ幸いです
  • 本記事は「Codex CLI や AWS CDK をある程度触ったことがある方」を主な読者像としています
    • そのため、各ツールごとの詳細な利用方法等は記載しておりません
  • 本記事では「要件整理」と「実装」の一部を抜粋して紹介します
    • 記事ボリュームの都合、「設計」に関しては割愛します

2. 主な使用ツール

項目 ツール
Coding AI ツール Codex CLI
IaC ツール AWS CDK (TypeScript)
セキュリティチェック cdk-nag
MCP サーバー AWS Knowledge MCP Server / AWS CDK MCP Server
  • 以降、上記ツールの設定が完了しているという前提が成立しているものとして話を展開します

3. フロー概要

  • 「要件を伝えて後はコード生成まで一気通貫でお任せ」というスタイルではなく、「段階的に人間が AI の成果物を確認したり、すり合わせをしながら進めていく」スタイルを採用します
  • いわゆる「段階的詳細化」の哲学に則り、「要件整理」->「設計」->「実装」という3ステップで作業を進めていきます
    • いわゆる Specification-Driven Development にも、ある程度通じるアプローチかと思います
  • 本記事では、話が広がりすぎないようにテストはスコープ外とします

要件整理、設計

  • 「要件整理」「設計」は、作業の流れを以下のように定義します
  • より成果物の質を高めるためには、他の Coding AI ツール（Claude Code など）によるレビューを含めてもよいかもしれませんね

実装

  • 「実装」では、セキュアさ担保を目的に「実作業」と「セルフレビュー」の間に「cdk-nagによるチェック」を配置します

4. カスタムプロンプト

  • 前セクションで紹介したフローを効率よく回す手段として、Codex CLI の カスタムプロンプト機能 を利用します
  • カスタムプロンプトの例として、「要件整理用」と「実装用」のものを以下に示します
    • 以下のような内容の md ファイルを ~/.codex/prompts/ 以下に配置することで、prompts:プロンプト名 で呼び出せます
      • 例: ~/.codex/prompts/coding.md を配置した場合、prompts:coding 引数1 引数2 ... の形式で呼び出せます
  • サンプルカスタムプロンプト内でのaws_knowledge MCP Server、aws_cdk MCP Server はそれぞれ AWS Knowledge MCP Server と AWS CDK MCP Server を意味します

「要件整理」用カスタムプロンプトの例

---
description: ユーザーが求める AWS インフラスタックの要件を整理する
argument-hint: OUTPUT_FILE_PATH
---

## 留意点
設計ではないので HOW? ではなく、WHY? WHAT? のスコープで検討すること

## ステップ
1. 要件整理
2. セルフレビュー
3. ユーザーレビュー

## 1. 要件整理
構築する AWS インフラスタックに関しての要件を以下の手段を活用して整理する
- ユーザーへの質問
  - この際、一度にたくさんの質問はしないこと
  - 1回にする質問の数は1-3個程度に制限する
- aws_knowledge MCP Server への問い合わせ

整理した結果は $1 に出力する

## 2. セルフレビュー
- $1 の内容をセルフレビューする
  - aws_knowledge MCP Server を活用する
  - セルフレビューの結果をユーザーに提示する
    - この際 項目ごとにIDを振るなど、ユーザーが認識しやすい形式にすること
  - 修正、変更が必要な際にはユーザーに指示を仰いでおこなうこと

## 3. ユーザーレビュー
- ユーザーに $1 の内容をレビューしてもらう
  - ユーザーから受理したフィードバックをもとに $1 の内容を更新する
  • 自分が Coding AI ツールを利用している限りは、単純に指示すると以下のような結果に陥る傾向が見られがちなため、これらを防止するような指示も含めています
    • A. 詳細な成果物を作りたがる: 要件整理においてはノイズになります
    • B. ユーザーへ同時に大量に質問する: ユーザー（人間）は同時に多くのことを考えるのが苦手なため、多大なストレスを受けます
# A の結果を抑制する指示
設計ではないので HOW? ではなく、WHY? WHAT? のスコープで検討すること

# B の結果を抑制する指示
- ユーザーへの質問
  - この際、一度にたくさんの質問はしないこと
  - 1回にする質問の数は1-3個程度に制限する
  • 特に B 抑制のための指示は分かりやすく効果を感じます
  • この指示により Coding AI は重要度の高い項目から順に質問してくれるようになり、結果的にコミュニケーション・成果物の質が高まります

「実装」用カスタムプロンプト

---
description: AWS インフラスタックを AWS CDK ベースで実装する
argument-hint: DESIGN_FILE_PATH CDK_FILE_PATH
---

## ステップ
1. 実装
2. チェック
3. セルフレビュー
4. ユーザーレビュー

## 1. 実装
以下の手段を活用して、引数 $1 の内容を実現する CDK コードを実装する
- ユーザーへの質問
  - この際、一度にたくさんの質問はしないこと
  - 1回にする質問の数は1-3個程度に制限する
- aws_cdk MCP Serverへの問い合わせ

CDK コードは $2 に出力する

## 2. チェック
- `npx cdk synth` コマンドを用いて表示される `cdk-nag` のエラーメッセージを確認する
- エラーメッセージが出る場合は、その内容をユーザーに分かりやすく提示する
- エラーの解消方法をユーザーに相談する
- 解消方法についてユーザーの承認を得られれば $2 に反映する
- 必要に応じてMCP Server を活用する
  - aws_knowledge MCP Server
  - aws_cdk MCP Server


## 3. セルフレビュー
- $2 の内容をセルフレビューする
  - aws_cdk MCP Server を活用する
  - セルフレビューの結果をユーザーに提示する
    - この際 項目ごとにIDを振るなど、ユーザーが認識しやすい形式にすること
  - 修正、変更が必要な際にはユーザーに指示を仰いでおこなうこと

## 4. ユーザーレビュー
- ユーザーに $2 の内容をレビューしてもらう
  - ユーザーから受理したフィードバックをもとに $2 の内容を更新する
  • cdk-nag によるチェック・洗練を実施してもらうために、「2. チェック」のステップを配置しています
  • cdk-nag のエラーに関しては、ユーザーが知らない間に自動修復されるよりは、ユーザーも認知しておくほうが好ましいと考え、ユーザーにその内容を提示し、AI とユーザーが協力して解決するプロンプトにしています

5. 実践例

  • サンプルとして、以下のような単純なシナリオを想定しつつ、「3. フロー概要」で示したフローを実際に回してみました
    • ちょっとした検証用途で安価な EC2 インスタンスを1台構築する
  • その結果の一部を紹介します。
    • 全て紹介することは困難なため、ここでは「要件整理」「実装」を部分的に紹介します

5.1 「要件整理」の過程

  • Codex CLI を起動し、要件整理用のカスタムプロンプトを実行すると、まずは以下のような「大枠」を把握するための質問が投げかけられます
🤖
• 要件整理のため、まず基本的な前提を確認させてください（質問は2つに絞ります）:

  1. どんなアプリ/ワークロードをデプロイする予定でしょうか（例: API + Lambda、Webフロント + S3/CloudFront、バッチ、データ基盤など）?
  2. 目標の利用環境やスケール感はありますか（例: 開発用のみ/本番運用、想定リクエスト規模、可用性/RTO/RPOの期待など）?

シンプルに以下のように回答しました

👨
1. 軽い検証用途でEC2インスタンスを1台用意したい
2. 想定利用者=私のみ

この最初のやり取りで、「大枠」を把握してくれたので、その「大枠」を前提に続いて少し具体的な質問をしてくれました

🤖
• 要件整理のため追加で2点だけ確認させてください:

  1. 利用したいリージョンやアカウントの制約はありますか（例: ap-northeast-1固定など）?
  2. 希望するOSイメージ・アクセス方法はありますか（例: Amazon Linux 2023でSSHキー接続/Systems Manager
     Session Manager利用など）?

👨
› 1. リージョン、アカウントは CDK コマンド打鍵時に指定します。
  2. Amazon Linux 2023最新版を使いたいです。アクセスはSSH経由ではなくSession Manager 経由が好ましいですね。
  • 確かに EC2 インスタンスを用意するときに気にすべき大切な情報ですね
  • 個人的にはアクセス方法を問い合わせてくれるあたり、「なかなか気が利いているな」と嬉しくなりました
  • 同様のやり取りを数回繰り返すと、指定したファイルへの出力がなされ、続いてセルフレビューが実行されます
🤖
• REQUIREMENTS.mdを作成し、検証用の低コストEC2スタックのWHY/WHATを整理しました（REQUIREMENTS.md）。

  セルフレビュー（ID付き）:

  - R1: Session Manager前提でのIAM/ネットワーク要件が未明示。AL2023はSSM Agent同梱だが、インスタンスプ
    ロフィールにAmazonSSMManagedInstanceCore相当を付ける必要性を要件として書くか決めたい（参考: Session
    Manager prerequisites）。
  - R2: インターネットを使わない運用なら、Systems Manager/EC2向けのVPCエンドポイント（PrivateLink）要否を
    決めると要件が明確になる。NAT依存を避けるかどうか。
  - R3: インスタンスアーキテクチャの確定が未了。Arm可ならt4g.micro、x86必須ならt3a.microが安価という前提
    を要件に反映してよいか。

  ご確認とフィードバックをお願いします:

  1. Armベースで問題なければt4g.micro、x86必須ならt3a.microを前提要件にしてもよいですか？
  2. Session Manager接続のため、インターネット経由/NAT許容か、PrivateLink(VPCエンドポイント)必須としま
     すか？
  • 最初の出力段階では見落としていた事項に自分自身で気づき、ユーザーに問い合わせてくれました
  • この調子で何回か 「🤖セルフレビュー -> 🤖気づき -> 🤖質問 -> 👨回答」を繰り返していくと、セルフレビューのステップが完了します
  • 最後に、ユーザーによる成果物レビューが求められます

ユーザーレビューも数回対話を続けると、以下のような成果物を得られました

# 背景
- 検証用途でコストを抑えつつ、単一のEC2インスタンスを立ち上げたい。

# スコープ
- CDKでデプロイするAWS インフラスタックは、安価なEC2インスタンス1台と、それに必要な最小構成のネットワーク/アクセス/ストレージ設定。

# 構成条件
## 環境
- リージョン/アカウント: CDK実行時に指定（固定しない）。

## ネットワーク
- VPC/サブネット: 新規作成（既存流用なし）。
- 通信経路: インターネット経由で問題なし（PrivateLink/VPCエンドポイント必須ではない）。
- アクセス: SSHは使わず、AWS Systems Manager Session Manager経由（必要なIAM権限付与が前提）。

## コンピュート
- OS: Amazon Linux 2023 最新版。
- インスタンスタイプ: x86の `t3.micro` を採用（安価かつ汎用、Armは不採用）。
- CPUクレジットを使い切るような継続高負荷は想定しない（検証用途の低〜中負荷）。

## ストレージ
- ルートボリューム: gp3 20GiB程度。
- EBS暗号化: 有効（追加コストなしのため標準でオン）。
  • 今回の題材はシンプルなため、自力でも同様の文書を作成できますが、AI と協働することで、独力の場合と比べてより楽に、かつ楽しく作業を進めることができました
  • 自分一人でこの類の作業に取り組むと視野に限界があり見落としが発生しがちで、その視野の狭さを補う意味でも他メンバーとの協働が必要でしたが、AI がその役割をある程度担ってくれます
  • 何とも頼もしい相棒ですね

5.2 「実装」の過程

  • 設計結果をもとに作業をするため、コーディング自体はスムーズに終わりました
  • 生成されたコードに対して cdk-nag によるチェックを走らせると、エラーが発生し、その内容が報告されました
🤖
• cdk synthでcdk-nagエラーが出ました（警告含む）:

  - AwsSolutions-VPC7: VPCにフローログなし
  - AwsSolutions-IAM4: AWS管理ポリシー AmazonSSMManagedInstanceCore を使用
  - AwsSolutions-EC28: EC2詳細モニタリングが無効
  - AwsSolutions-EC29: 単一インスタンスでTermination Protection無効

  対応提案:

  - VPCフローログをCloudWatch Logsへ出力（最小構成のLogGroup/IAMロールを追加）
  - EC2: 詳細モニタリング有効化、Termination Protection有効化
  - IAM4対策: (A) AmazonSSMManagedInstanceCoreを継続利用しつつcdk-nagを理由付き抑止、または (B) 同等権限のカスタムマネージドポリシーに置き換え

  質問（2点、番号で回答OKです）:

  1. 上記方針で修正を進めてもよいでしょうか？
  2. IAM4は A: 抑止、B: カスタムポリシー作成 のどちらを希望しますか？
  • cdk-nag は実運用を想定してかなり厳格なチェックをしてくれることが読み取れますね
  • 一方で、今回のように「ちょっとした用途」でインフラを用意したい場合には、オーバースペックではあります😅
  • 今回は「Termination Protection」は有効、その他は無視、という指示を出してみました
👨
› EC29: これは有効にしてほしいです。その他は、「意図的に無視する」ことを示すコードを追加してください。

  • ⚠️ 今回は検証目的のため上記のように「無視」の指示を出しましたが、本番環境においては可能な限りエラーの無視は避けるべきです。この点について誤解のないようお願いいたします🙇

  • cdk-nag を用いたチェック、洗練の後は 「AI のセルフレビュー」「ユーザーレビュー」と続きます

  • 最終的に得られたコードの一部を紹介します

    const instance = new ec2.Instance(this, 'Instance', {
      vpc,
      vpcSubnets: { subnetType: ec2.SubnetType.PUBLIC },
      securityGroup: instanceSg,
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
      machineImage: ec2.MachineImage.latestAmazonLinux2023({
        cpuType: ec2.AmazonLinuxCpuType.X86_64,
      }),
      blockDevices: [
        {
          deviceName: '/dev/xvda',
          volume: ec2.BlockDeviceVolume.ebs(20, {
            volumeType: ec2.EbsDeviceVolumeType.GP3,
            deleteOnTermination: true,
            encrypted: true,
          }),
        },
      ],
      /** 省略 **/
      disableApiTermination: true, // cdk-nag の指摘に基づき追加されたコード
    });
  • cdk-nag のエラーを意図的に無視していることを示すコードも以下のように生成されています
    NagSuppressions.addResourceSuppressions(
      instance,
      [
        {
          id: 'AwsSolutions-EC28',
          reason: '個人検証用で詳細モニタリングを無効化しコスト削減。',
        },
      ],
      true,
    );
  • reason 部分まで生成してくれるのは、大変ありがたく感じます

5.3 動作確認

  • 一連の作業を終え、出来上がった CDK コードを用いて実際に AWS 環境へデプロイし、期待通り Session Manager 経由でアクセスできることも確認しました
    • また、SSH 等、他の経路ではアクセスできないよう、セキュリティグループのインバウンドが封じられていることも確認できました
  • 今回デプロイは私が手動で行いましたが、権限を委譲すればデプロイ作業もある程度 Coding AI ツールに任せられますね

6. まとめ

6-1. 今回の進め方まとめ

  • 本記事では、AWS インフラ構築の手段として Coding AI ツールと CDK の活用例を紹介しました
  • 特徴
    • プロセス:
      • 段階的詳細化の考えに基づき、要件整理 -> 設計 -> 実装の順で進める
      • レビューは AI によるセルフレビュー→ユーザーによるレビューと、二段階構成
      • 上記の進め方を効率化する手段として、Codex CLI の カスタムプロンプト機能を活用
    • プロンプトの工夫:
      • AI-人間間のコミュニケーションの質を高めるために、AIからの質問数を制限
      • 要件整理の際に、設計レベルの検討に進まないよう、スコープを明示
    • 品質担保の工夫:
      • cdk-nag によるチェックの義務化
    • ナレッジの補強:
      • AWS 公式の MCP サーバーを活用
        • AWS Knowledge MCP Server
        • AWS CDK MCP Server

6-2. 実践しての所感

  • ツールやカスタムプロンプトの設定などの初期投資は必要になりますが、フローを回してみると従来のように人力で進めるのに比べて以下のようなポジティブな効果を感じます
    • 検討の抜け・漏れを防ぎやすい
    • 要件整理、設計での対話は必要だが、そこを面倒がらずに丁寧におこなえば、コーディングの大部分をお任せできる
    • cdk-nag のエラーに立ち向かうための支援はありがたい
    • 要件や設計内容を出力した markdown ファイルは、今後の保守や拡張、あるいは、別 AI ツールの支援を受ける際等に有用
  • 一方で、「SSH 接続 と Session Manager の違い」や「詳細モニタリングとは何か」といった 基礎知識 を有していないことには AI との対話が成立しないな、とも思います
    • よく言われることではありますが、AI は非常に便利ですが、それを使いこなすための「基礎」を利用者側が有していることが活用の前提になります
    • 逆に言えば、基礎力を鍛えておくことで AI との協働により生産性を大きく伸ばせる時代になったとも言えますね

6-3. 拡張可能性

  • MCP サーバー:
    • 今回紹介したもの以外にも、例えば設計図作成を目的に AWS Diagram MCP Server なども併用するとより開発しやすくなると思います
  • フロー:
    • 本記事で紹介したフローは非常にシンプルですので、要件のスコープが広くなったり、複雑になると、収拾がつかなくなります
    • そういった状況に対しては、一連のワークフローの序盤で例えばスタックを分割するなど、粗い粒度での設計を挟む必要が生じるでしょう
  • テスト:
    • 今回の記事ではスコープ外としたテストについても、IaC と Coding AI ツールの組み合わせにより効率化できる余地は多いと思います
MEGAZONE株式会社 Tech Blog
MEGAZONE株式会社 Tech BlogPublication

MEGAZONEはAWS プレミアティア サービスパートナーとして多数のCompetencyを取得しており、大企業、ゲーム会社、スタートアップ、公共機関などさまざまな分野の5,000以上のお客様にAWSソリューションとサービスを提供しています。

Discussion