このページの本文へ

FIXER Tech Blog - Cloud

FIXER cloud.config Tech Blog

インフラ構成図をコードで書けるDaC+IaC+AIエージェントで時短ができるか

2026年01月08日 15時00分更新

文● 玉置 淳成 /FIXER

  • この記事をはてなブックマークに追加
  • 本文印刷

 本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「『awsdac』×『AI』で実現する、アーキテクチャ図の時短戦略の夢を見てみた」を再編集したものです。

 この記事はFIXER Advent Calendar 2025 17日目の記事です。

1. はじめに

 私は入社からフロントチームでやってきて、個人開発でクラウドサービスを使うこともありましたがあまり得意ではなかったので勉強してみようと思って色々調べていたところインフラの構成情報(IaC)だけでなく、構成図もコードで管理するDiagram as Code(以下 DaC)という方法があることを知りました。

この記事の目的

 この構成図もコードで管理する方法(DaC)を紹介し、ぜひインフラチームの皆さんに実用できるのか検討し、技術選定のときに選択肢として持ってもらいたいと思いこの記事を書きます。

 きっかけとなったIaCとDaCの相互運用についても紹介できたらと思います!

2. 概念とツール

Diagram as Codeとは

 Diagram as Code(DaC)とはテキストファイルに構造を記述し、描画する手法や概念のことです。

 よく使われているDaCツールにはPlantUMLMermaidがあり、これらはシーケンス図やフローチャートの描画にも使われるためインフラチーム以外の人にも馴染みがあるかと思います。

AWSが提供するDaCツール『AWS Diagram-as-code(awsdac)』

 AWSでは公式から構成図を描画するためのCLIツールとして『AWS Diagram-as-code』(以下、awsdac)が提供されています。

 このツールはAWSの構成図の作成に特化していて、公式サイトからアーキテクチャアイコンをダウンロードしてきてインポートしたり、手動でリソースからリソースへ線を引いたりすることなくコードのみで構成図を描画できます

 上の構成図を作成するときは、次のようなコードを書きます。

Diagram:
  DefinitionFiles:
    - Type: URL
      Url: "https://raw.githubusercontent.com/awslabs/diagram-as-code/main/definitions/definition-for-aws-icons-light.yaml"

  Resources:
    Canvas:
      Type: AWS::Diagram::Canvas
      Direction: horizontal
      Children:
        - Users
        - AWSCloud

    Users:
      Type: AWS::Diagram::Resource
      Preset: Users

    AWSCloud:
      Type: AWS::Diagram::Cloud
      Preset: AWSCloudNoLogo
      Direction: horizontal
      Children:
        - VPC

    VPC:
      Type: AWS::EC2::VPC
      Direction: horizontal
      Children:
        - PublicSubnet
      BorderChildren:
        - Position: W
          Resource: InternetGateway
    InternetGateway:
      Type: AWS::EC2::InternetGateway
      IconFill:
        Type: rect

    PublicSubnet:
      Type: AWS::EC2::Subnet
      Preset: PublicSubnet
      Children:
        - WebServer

    WebServer:
      Type: AWS::EC2::EC2Instance

  Links:
    - Source: Users
      SourcePosition: E
      Target: InternetGateway
      TargetPosition: W
      TargetArrowHead:
        Type: Open

    - Source: InternetGateway
      SourcePosition: E
      Target: WebServer
      TargetPosition: W
      TargetArrowHead:
        Type: Open

 このようにYAMLファイルに書いていくだけでシステムの構成を表すことができます。

3. DaCとIaCの相互運用戦略

 DaCもIaCもコードでインフラを管理する方法なので相互に運用したくなってきました。

 さらに、どちらもコードで管理するならAIエージェントを使ったら爆速開発&効率化できるのではと思い、フローを考えてみました。

※インフラの専門家から見たらかなり拙いフローかと思います。温かく見守っていただけますと幸いです。

【1】DaC→IaCフロー

 まず、DaC構成からIaC化するフローです。

 主に新規プロジェクトでの使用を想定しています。

 要件定義後、AIを使ってawsdac用のYAMLファイルを生成します。

 これで十分な構成もあったりしますが、大規模になるとリソース間を繋ぐ線がグッチャグチャになるのでいい感じに直してください。

 繋がりはだいたいいいんですけどね。

 ここだけは人間の視覚的なものなのでどこからどこに繋がるかは調整せざるを得ないのが現状です。

 そして、作成したYAMLをもとにTerraformなどのコードに変換(生成)します。

 もちろん、設定値などが適当だったりしますが構成自体はだいたいできます。

 人間のレビューも必要だと思います。

 しかし、「だいたいできた」ところまでが高速に、手軽にできるようになることでインフラ担当以外でもこの辺りを(AIの力も借りつつ)精度高く作成できるため、

 インフラ担当は構成図とインフラコードの作成を非インフラ担当のメンバーにも依頼することができます。

 そして、インフラ担当は

1.作成した構成図をレビューする
2.構成図(コード)をもとに作成したTerraformなどのコードをレビューする

 と、レビュー担当に回ることで業務を分散することができます。

 DaCの強みはGitなどで構成図の差分を管理しやすいところですが、レビューする分にはコードを見てもいいですし、出力された画像を見てもいいです。

【2】IaC→DaCフロー

 そして、既存のプロジェクトで作成していたTerraformやAWS CloudFormationテンプレートからDaCを作成する方法です。

 Terraformであれば、AIエージェントでawsdac用のYAMLに変換するよう命令してみてください。8割くらいできます。

 AWS CloudFormationテンプレートですが、awsdacではベータ版ですがオプションでテンプレートから構成図を生成できます。

awsdac your-cfn.yaml --cfn-template --dac-file

 以下、簡単にオプションの説明です。

--cfn-template:CloudFormationテンプレートから構成図に変換するオプションです。
--dac-file:構成図に変換するときにawsdacのYAMLファイルを生成するときにつけるオプションです。これをつけない場合、構成図のみが生成されます。

 CloudFormationテンプレートから生成したawsdacのYAMLファイルを見るとLinksにリソースの接続が書かれていません。

    Links: []

 そんな時はAIエージェントにLinksを生成してもらいましょう。これで9割くらいできます。

あとは生成された構成図を見て微調整してください。これで10割です。

4. Draw.ioやPowerPointとの差

 Draw.ioやPowerPointとの違いですが、やはり一番大きな差はレイアウトの自由度です。

 既存のツールは手動で配置するため自由に配置することができ、リソース間の矢印など見栄えを十分に確保した構成図を作成できます。

 しかしawsdacでは、矢印の曲がり方などはある程度操作できますが、自動配置が基本になるため被ってしまう部分があったりと複雑な構成になるほど少し見づらいところもあります。

5. まとめ

 簡単にまとめるとこちらです。

・構成図をコードで作成することでAIの力も借りてベースを簡単に作成できる
・DaCとIaCを組み合わせて全てコードで管理できる

 これからも DaCとAIをうまく活用してインフラチームの工数を削減し、インフラメンバーがより専門的なことに時間をかけられるような環境を目指して調査を続けていきたいと思います。

 拙い文章でしたが、ここまで読んでいただきありがとうございました!

玉置 淳成 /FIXER
タマオキです。
好きな言葉はフルパワー

カテゴリートップへ

この連載の記事