gaipack
お問い合わせ
HOME/ブログ/AWS Knowledge MCP・IaC MCPで実現する、AIDDのAWS設計・構築フロー
aws-mcp-aidd-design-build-thumbnail
AI 駆動開発

AWS Knowledge MCP・IaC MCPで実現する、AIDDのAWS設計・構築フロー

avatar
Yutaro Hiyama

AI に AWS の設計・構築を任せきりにすると、ベストプラクティスに沿わない構成や、古い情報に基づいた実装が混ざってしまうことがあります。本記事では、AWS Knowledge MCP Server・AWS IaC MCP Server・awsdac（AWS Diagram as Code）を使い分けながら、設計から構築・レビュー・納品まで進めている AIDD 現場の型を紹介します。

やりたいこと / 前提

AI に AWS の設計・構築を丸ごと任せると、次のような課題が起きがちです。

  • ベストプラクティスに反した構成を提案してしまう
  • 古い情報をもとにコードやドキュメントを生成してしまう

そこで、設計・実装の各フェーズで 公式かつ最新の情報を AI に参照させる ために、複数の MCP サーバーを使い分けています。基本的な作業は Claude 上で行っています。

構成 / アーキテクチャ

使っている MCP は大きく2つです。役割で分けると次のようになります。

MCP主な役割使うフェーズ
AWS Knowledge MCP Server公式ドキュメント横断検索、Well-Architected の観点での構成の裏取り設計・レビュー
AWS IaC MCP ServerCDK のベストプラクティス参照、CFN のバリデーション・セキュリティチェック、デプロイ失敗時の原因調査実装・レビュー

大まかな流れは以下の通りです。

Code
要件整理
  └→ AWS Knowledge MCP で最新ドキュメント・Well-Architected を参照しながら設計
       └→ CDK コードを実装
            └→ AWS IaC MCP でベストプラクティス／セキュリティをチェック
                 └→ レビュー（同じ MCP を使って古い書き方などを指摘）
                      └→ awsdac で構成図を生成し、設計書として納品

手順

1. 設計フェーズ：AWS Knowledge MCP Server で裏取りする

要件をベースに構成を検討する際、AWS Knowledge MCP Server を使い、公式ドキュメントを横断検索しながら Well-Architected の観点に沿っているかを確認します。AWS がフルマネージドで提供しているリモート MCP サーバーで、ローカルのセットアップなしに https://knowledge-mcp.global.api.aws へ接続するだけで使えるのが利点です。

JSON
{
  "mcpServers": {
    "aws-knowledge-mcp-server": {
      "url": "https://knowledge-mcp.global.api.aws",
      "type": "http"
    }
  }
}

2. 実装フェーズ：AWS IaC MCP Server でチェックする

CDK のコードを実装する段階では、AWS IaC MCP Server を使います。CDK の書き方のベストプラクティスに加えて、cfn-lint による文法チェック、cfn-guard によるセキュリティ・コンプライアンスチェック（S3 バケットの意図しない公開検知など）まで一気通貫でカバーしてくれます。

JSON
{
  "mcpServers": {
    "awslabs.aws-iac-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-iac-mcp-server@latest"]
    }
  }
}

デプロイに失敗した際の原因調査機能も備えているため、構築段階だけでなくレビュー工程でも同じ MCP を活用しています。レビューで「この書き方は古いので、こちらのほうが良い」といった指摘を受けることも多く、コードレビューの精度向上にも役立っています。

3. 納品フェーズ：awsdac で構成図を作る

設計書として構成図をお客様に納品する際は、awsdac（AWS Diagram as Code） を使っています。Claude で CDK コードを生成したうえで、構成を表す YAML（DAC ファイル）を定義し、awsdac でレンダリングする流れです。AWS 公式の OSS で、AWS の公式アイコンを使って自動的に構成図を生成してくれます。

MCP 経由で構成図を生成する方法も試しましたが、実際の AWS 公式アイコンと異なる見た目になることがありました。正確な構成図を納品する用途では、awsdac のほうが向いていると感じています。

4. 運用フェーズ：ログ調査は MCP なしでも十分

デプロイ後にアプリケーションのエラーが発生した場合は、あえて MCP を使わず、読み取り専用の IAM ロールを用意して SSO でログインし、ロググループを指定したプロンプトで Claude に直接調査させています。ログ調査系の MCP サーバーも存在しますが、読み取り権限だけのシンプルな調査であれば、プロンプトだけで十分にまかなえている、というのが現状の感覚です。

ハマったポイント

  • MCP 経由の構成図生成は、公式アイコンと差異が出ることがある：Python の diagrams パッケージ的なアプローチでは AWS 公式アイコンそのものではない場合があり、正確性が求められる納品物には awsdac のほうが適していました。
  • MCP を使う／使わないは厳密なルール化をしていない：ログ調査のように「困っていない部分」は無理に MCP 化せず、プロンプトベースで運用しています。使い分けは今後もアップデートしていく前提です。

まとめ

フェーズ使うツールやっていること
設計AWS Knowledge MCP Server最新ドキュメント・Well-Architected での裏取り
実装・レビューAWS IaC MCP ServerCDK ベストプラクティス、cfn-lint／cfn-guard によるチェック、デプロイ失敗の原因調査
納品awsdac公式アイコンでの構成図生成、設計書化
運用調査なし（読み取り専用ロール＋プロンプト）ロググループ指定でのアプリケーションエラー調査

MCP をどこで使い、どこは使わないか——ここに絶対的な正解があるわけではなく、現場でハマったところ・困っていないところを見ながら日々アップデートしている段階です。同じように AIDD で AWS の設計・構築に取り組む方の参考になれば幸いです。KDDIアイレットでは、こうした知見を活かした AWS 設計・構築のご支援も行っています。お気軽にお問い合わせください！

記事一覧に戻る