🙆‍♀️

Diagram as Code(DaC)でインフラ図をAIと一緒に書いてみた

に公開

SREエンジニアの高見です。
インフラ構成図の作成とメンテナンスは、インフラ管理者の悩みのタネです。GUIツールでの手作業は時間がかかり、構成変更に追随できず、図が「化石化」することも少なくありません。

この問題を解決するアプローチとしてDaC: Diagram as Codeが注目されています。これは、図をコード(多くの場合YAMLやPythonなど)で記述し、CI/CDに組み込むことで、図のバージョン管理と自動生成を実現する手法です。

今回は、AWSが提供するDaCツールと、強力なAIアシスタントを組み合わせて、「AIにインフラ図を自動で描かせる」試みを行いました。その過程と、見えてきた現実的な課題をレポートします。

公式リポジトリ・公式Blogなど

今回使用したDaCツールは、AWS Labsが公開しているものです。

https://github.com/awslabs/diagram-as-code
https://aws.amazon.com/jp/blogs/news/aws-visualization-diagram-as-code-amazon-bedrock/

インストール方法や、使い方などは、上記を参考にしてください。
本記事では特に触れません。

使ったAI

DaCのYAMLコードを生成するために、以下のAI環境を利用しました。

  • AIエージェント: Cursor
  • AIモデル: Claude 4.5 Sonnet

正直AIエージェントはClaude CodeでもCodexでも何でも良いです。追体験されたい方は、皆さんの使いたいエージェントをお使いください。

結論:現時点での所感

数時間AIと格闘してみた結論から言うと、まだ、Figmaやdraw.ioで手で書いたほうが早かったというのが正直な感想です。
AIとの共同作業には、いくつかの大きな壁がありました。

  • 適当な指示では雑な結果が返って来る
    • 不要なリソース、情報や、アイコンが生成されたりする
  • 人間にとってフレンドリーではない図になりがち
    • リソース間の接続線が重なったり、どこに繋がっているか分かりにくい。
    • アイコンの配置が「人間的でない」。例えば、関連するリソースが不自然に離れていたりする
  • 「分かりやすい図」にするには膨大なコストがかかる

結局、人間が見て分かりやすい図にするには、「そのアイコンを右にずらして」「この線を点線にして」といった微調整を、AIとチャットで延々とやり取りする必要があり、かなりの労力と時間が必要でした。

とりあえず動かしてみるとこうなる

最初に、AIにどれだけできるか試すため、以下のようなプロンプトを投げてみました。

## 依頼
awsdacを用いて、インフラ概要の内容のyamlファイルと、それをawsdacでコンパイルしたインフラ図を作成せよ。

## インフラ概要
- ELB-> ECS(Fargate) -> RDS(Aurora PostgreSQL)
- VPCやサブネットなどのネットワークは一般的なもの

## 仕様
https://github.com/awslabs/diagram-as-code

出てきた結果

謎なサブネットのゴミアイコンがいっぱいある、このままでは利用出来ない図が出来上がりました。サブネットとアイコンの位置関係も微妙です。IPアドレスも勝手にAIが選択して記述してしまいました。
にも関わらずAIは「完璧です!awsdac を使用して、ELB → ECS(Fargate) → RDS(Aurora PostgreSQL) のインフラ構成図を作成しました」と自信満々でした。

上手くやっていくために工夫したこと

このままでは使い物にならないため、AIへの指示の出し方を根本的に見直しました。

1. 既に他の人が作っているものからスタートする

ゼロからAIに書かせると失敗するため、公式リポジトリにあるサンプルYAMLなど、既にある程度「動く」コードをAIに読み込ませ、それをベースに変更させるアプローチを取りました。AIも具体的なコード例がある方が、指示を理解しやすくなります。

2. 少しづつ丁寧に改善していく

一度に完璧を求めるのではなく、段階的に、かつ具体的に指示を出すようにしました。

  • 「(サンプルコードの)EC2をAWS Fargateに変えて」
  • 「ELBをpublic subnetの枠の中に入れよ」
  • 「RDSにSecondary(リードレプリカ)を追加し、Primaryと左右に並べて配置せよ。PrimaryからSecondaryへの線は点線を使うこと」

このように、人間がGUIツールで操作するのと同じレベルの具体的な指示を出すことで、少しずつ理想の図に近づけていきました。

3. 常に公式のGithubリポジトリの仕様を確認させる

AIは時々、DaCの仕様にないアイコン名や記述方法を「創造」してしまうことがあります。

そこで、「アイコンの種類や記述方法に関しては、常に提示したGitHubリポジトリの仕様を確認すること」をチャットのルール(システムプロンプト)に追記しました。これにより、AIが勝手な記法を作る頻度を減らすことができました。

最終的に作ったインフラ図(一部抜粋)

これらの工夫を重ねた結果、最終的にはかなり見栄えの良い、意図した通りの構成図をYAMLコードとして生成することに成功しました。ただし、時間はだいぶかかりました。

VPCやAZ(アベイラビリティゾーン)の枠組みが正しく配置され、Public/Privateサブネットの区分、ELBからFargate、FargateからRDSへのデータの流れ、RDSのMulti-AZ構成(点線によるレプリケーション)などが、人間が見てもそれなりに分かりやすいレイアウトで表現されています。

まとめ

Diagram as Code (DaC) と AI の組み合わせは、非常に大きな可能性を秘めています。しかし現状では、「AIにお任せで図が出来上がる」という魔法のような体験は期待できません。

AIを「自動作図ツール」としてではなく、DaCの記法を理解した、超高速タイピストのペアプログラマーとして扱う必要があります。

人間が明確な設計とレイアウトの意図を持ち、AIに具体的な修正指示を根気よく出し続けることで、初めて「メンテナブルな構成図」という成果物が得られます。

現状ではFigma等での手書きの方が早いのは事実ですが、一度YAMLコード化してしまえば、その後のメンテナンス性はいくらか向上すると期待しています。AIの進化とDaCツールの成熟が進めば、このコストが逆転する日もそう遠くはないと感じました。

個人的雑談:ちなみにDACというと、オーディオのDigital Analog Converterという意味もあります。WiseVineでは、フルリモート推奨で、自宅の据え置きオーディオ環境で上質な音楽を聴きながら仕事することも出来ます!
※DACはS.M.S.L D400EXを最近買いました。

WiseVine Tech Blog

Discussion