こんにちは。アジアクエスト株式会社の足立です！
この記事は「2025 Japan AWS Jr. Chanpions 夏のQiitaリレー 」の5日目の記事です。
過去の投稿（リンク集）はこちらからご覧ください！
1. なぜ図表作成はこんなに面倒なのか
AWSインフラの構成図、こんな悩みありませんか？
- 仕様変更のたびに図を描き直し
- チームで最新版が分からなくなる
- 手作業での修正が面倒
- コードと図表がすぐズレる
私も「またPowerPointで修正…」「最新版はどれ？」と何度も悩まされてきました。
図表作成や管理に多くの時間を取られ、本来の設計や運用に集中できない――そんな経験、きっと多くの方に共通するはずです。
この記事ではDiagram as Codeを使ってこれらの課題に対処する方法をご紹介します。
本記事での用語の使い分けについて
Diagram as Code
「コードで図を描く」という概念全体を指します。PlantUMLやMermaidなども含めた広い意味で使います。AWS Diagram-as-code（awsdac）
AWS公式が提供するDiagram as Code専用ツールの名称です。
本記事では、特に断りがない限り「Diagram as Codeの実践例」としてawsdacを中心に解説します。※以降、概念として述べる場合は「Diagram as Code」、ツールとして述べる場合は「awsdac」と表記を統一します。
2. Diagram as Codeとは何か
「コードで図を描く」——これまでとは全く違うアプローチです。
PowerPointやDraw.ioでの手作業に代わる新しい選択肢があります。テキストファイルに設定を書くだけで、プログラムが図表を作成してくれます。
Infrastructure as Code（IaC）をご存知ですか？サーバーやネットワークの設定をコードで管理する手法です。Diagram as Codeは、この考え方を図表作成に適用したものです。
「設定もコード、インフラもコード、そして図表もコード。」
Diagram as Codeと従来の手法を比較してみましょう。
従来の手法では、
- まずAWS公式サイトからアーキテクチャアイコンをダウンロード
- PowerPointやDraw.ioにインポートし、VPC用に紫、Public Subnet用に緑の枠をそれぞれ描画
- アイコンと「VPC」「Public Subnet」「Instance」というテキストを配置
- EC2インスタンスアイコンをPublic Subnet内に置いて整列・分布ツールで微調整
- 各要素をグループ化してPNG／SVG形式で書き出し
・・・という手順が必要でした。
Diagram as Codeでは、こんなYAMLファイルを書くだけです：
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: vertical
Children:
- MyVPC
MyVPC:
Type: AWS::EC2::VPC
Children:
- MySubnet
MySubnet:
Type: AWS::EC2::Subnet
Preset: PublicSubnet
Children:
- MyInstance
MyInstance:
Type: AWS::EC2::Instance
このYAMLファイルを実行すると、以下の構成図が自動生成されます。
3. メリット・デメリット
メリット
-
圧倒的な再利用性
一度テンプレートを作れば似たような構成の図表は短時間で生成できます。共通テンプレートを作って使い回すことで、効率が向上します。# 共通テンプレート定義 WebTier: &web-tier Type: AWS::EC2::Instance # 使い回し例 Resources: WebServer1: *web-tier WebServer2: *web-tier WebServer3: *web-tier # スタックでまとめる WebTierStack: Type: AWS::Diagram::HorizontalStack Children: - WebServer1 - WebServer2 - WebServer3 -
チーム全体での一貫性
誰が作っても同じスタイルの図表になります。図表の書き方に習熟していなくても、統一された見た目の図表を作成できます。ただし、細かいデザイン調整は制限があるので、完全に自由な表現は難しいです。 -
CI/CDパイプラインに組み込める
コードが更新されるたびに、自動で最新の図表を生成できます。図表が常に最新の状態で維持される感覚を味わえます。# GitHub Actions例 - name: Generate Diagrams run: awsdac architecture.yaml -o docs/architecture.png -
差分がGitで見える
図表の変更内容がコードの差分として確認できます。Resources: WebServer: - Type: AWS::EC2::Instance + Type: AWS::ECS::Service -
AI・LLMとの親和性
YAMLという構造化されたテキスト形式のため、AI・LLMとの相性が抜群です。
詳細は後述しますが、個人的にはDiagram as Codeという概念が今注目されている一番の理由だと思います。
デメリット
-
学習コスト
最初はawsdacの記法を覚える必要があります。例えばawsdacの場合、基本的には通常のYAMLファイルですが、リソース間の関係性を表現するため特有の書き方があります。特に非エンジニアの場合、YAMLの構文を理解するのにも時間がかかります。私の場合、CloudFormationが何となく分かるので、基本的な図はすぐ作れるようになりました。
補足：CloudFormationsテンプレートから直接図表を生成できないの？
awsdacコマンドの--cfn-templateフラグを使用することで可能です。ただし、Beta版機能のため複雑な依存関係があるとリソースの配置がうまく表現されないことがあります。 -
自由度の制限とレイアウトの制約
自由自在なデザインや細かい位置調整は難しいです。自動レイアウトのため、定義されたスタイルの範囲内での表現になります。「この要素をもう少し右に…」という微調整ができないので、完璧主義な人にはストレスかもしれません。複雑な構成になると、自動レイアウトの結果が期待と異なることがあります。
-
ツール依存とLLM依存のリスク
特定のツールに依存するため、ツールの制約や更新に影響を受けます。また、AI・LLMに依存している場合、間違いが起こった際に自分で修正が困難になることがあります。生成されたコードが正しくない場合、YAMLの構文やawsdacの仕様を理解していないと修正できません。
-
チーム浸透の壁
私はまだ個人でしか使っていませんが、もしチーム開発で適用しようとすると、これまでの慣習をどう変えるか、どのようにレビューをするのか、CI/CDにどのように組み込むのか、といった課題が考えられます。
5. 実践編：実際に作ってみよう(awsdac)
この章ではawsdacというツールを使ったDiagram as Codeの実践例を見ていきます。
awsdacについて詳しく知りたい方は、以下のGithubページをご確認ください。
環境準備（5分でできる）
macOSの場合はbrew install awsdac、
Windows/Linuxの場合はgo install github.com/awslabs/diagram-as-code/cmd/awsdac@latest
でインストールできます。
※Go 1.21.x以上を事前にインストールする必要があります。
最初の図表作成
最もシンプルな構成から始めましょう。sample1.yamlを作成します：
sample1.yaml
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:
- User
- WebServer
User:
Type: AWS::Diagram::Resource
Preset: User
WebServer:
Type: AWS::EC2::Instance
Links:
- Source: User
SourcePosition: E
Target: WebServer
TargetPosition: W
TargetArrowHead:
Type: Open
awsdac diagrams/sample1.yaml -o output/sample1.pngを実行すると、最初の図表が完成します。
次に、VPCやサブネット、インターネットゲートウェイを追加してみましょう。
sample2.yaml
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:
- User
- MyVPC
User:
Type: AWS::Diagram::Resource
Preset: User
MyVPC:
Type: AWS::EC2::VPC
Children:
- MySubnet
BorderChildren:
- Position: W
Resource: IGW
MySubnet:
Type: AWS::EC2::Subnet
Preset: PublicSubnet
Children:
- WebServer
WebServer:
Type: AWS::EC2::Instance
IGW:
Type: AWS::EC2::InternetGateway
IconFill:
Type: rect
Links:
- Source: User
SourcePosition: E
Target: IGW
TargetPosition: W
TargetArrowHead:
Type: Open
- Source: IGW
SourcePosition: E
Target: WebServer
TargetPosition: W
TargetArrowHead:
Type: Open
それっぽくなってきました。さらにインスタンスを増やしてロードバランサーも追加してみます。
sample3.yaml
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:
- User
- AWSCloud
User:
Type: AWS::Diagram::Resource
Preset: User
AWSCloud:
Type: AWS::Diagram::Cloud
Direction: horizontal
Preset: AWSCloudNoLogo
Align: center
Children:
- MyVPC
MyVPC:
Type: AWS::EC2::VPC
Direction: horizontal
Children:
- ALB
- EC2Stack
- RDSStack
BorderChildren:
- Position: W
Resource: IGW
ALB:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
Preset: Application Load Balancer
EC2Stack:
Type: AWS::Diagram::VerticalStack
Children:
- PublicSubnet1
- PublicSubnet2
PublicSubnet1:
Type: AWS::EC2::Subnet
Preset: PublicSubnet
Children:
- WebServer1
PublicSubnet2:
Type: AWS::EC2::Subnet
Preset: PublicSubnet
Children:
- WebServer2
WebServer1:
Type: AWS::EC2::Instance
WebServer2:
Type: AWS::EC2::Instance
IGW:
Type: AWS::EC2::InternetGateway
IconFill:
Type: rect
Links:
- Source: User
SourcePosition: E
Target: IGW
TargetPosition: W
TargetArrowHead:
Type: Open
Type: straight
- Source: IGW
SourcePosition: E
Target: ALB
TargetPosition: W
TargetArrowHead:
Type: Open
Type: straight
- Source: ALB
SourcePosition: E
Target: WebServer1
TargetPosition: W
TargetArrowHead:
Type: Open
Type: orthogonal
- Source: ALB
SourcePosition: E
Target: WebServer2
TargetPosition: W
TargetArrowHead:
Type: Open
Type: orthogonal
最後にプライベートサブネットにRDSを配置します。
sample4.yaml
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:
- User
- AWSCloud
User:
Type: AWS::Diagram::Resource
Preset: User
AWSCloud:
Type: AWS::Diagram::Cloud
Direction: horizontal
Preset: AWSCloudNoLogo
Align: center
Children:
- MyVPC
MyVPC:
Type: AWS::EC2::VPC
Direction: horizontal
Children:
- ALB
- EC2Stack
- RDSStack
BorderChildren:
- Position: W
Resource: IGW
ALB:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
Preset: Application Load Balancer
EC2Stack:
Type: AWS::Diagram::VerticalStack
Children:
- PublicSubnet1
- PublicSubnet2
RDSStack:
Type: AWS::Diagram::VerticalStack
Children:
- PrivateSubnet1
- PrivateSubnet2
PublicSubnet1:
Type: AWS::EC2::Subnet
Preset: PublicSubnet
Children:
- WebServer1
PublicSubnet2:
Type: AWS::EC2::Subnet
Preset: PublicSubnet
Children:
- WebServer2
PrivateSubnet1:
Type: AWS::EC2::Subnet
Preset: PrivateSubnet
Children:
- DatabaseServer1
PrivateSubnet2:
Type: AWS::EC2::Subnet
Preset: PrivateSubnet
Children:
- DatabaseServer2
WebServer1:
Type: AWS::EC2::Instance
WebServer2:
Type: AWS::EC2::Instance
DatabaseServer1:
Type: AWS::RDS::DBInstance
DatabaseServer2:
Type: AWS::RDS::DBInstance
IGW:
Type: AWS::EC2::InternetGateway
IconFill:
Type: rect
Links:
- Source: User
SourcePosition: E
Target: IGW
TargetPosition: W
TargetArrowHead:
Type: Open
Type: straight
- Source: IGW
SourcePosition: E
Target: ALB
TargetPosition: W
TargetArrowHead:
Type: Open
Type: straight
- Source: ALB
SourcePosition: E
Target: WebServer1
TargetPosition: W
TargetArrowHead:
Type: Open
Type: orthogonal
- Source: ALB
SourcePosition: E
Target: WebServer2
TargetPosition: W
TargetArrowHead:
Type: Open
Type: orthogonal
- Source: WebServer1
SourcePosition: E
Target: DatabaseServer1
TargetPosition: W
TargetArrowHead:
Type: Open
Type: orthogonal
- Source: WebServer2
SourcePosition: E
Target: DatabaseServer2
TargetPosition: W
TargetArrowHead:
Type: Open
Type: orthogonal
さらに複雑な例を見たい方はGithubのExampleをご確認ください。
4. 生成AIとの連携でさらに効率化
ここまで読んで「コードで図を書けるのは分かったけど、ちょっと面倒…」と思われた方もいるのではないでしょうか？
Diagram as Codeの真価が発揮されるのは、生成AIとの連携です。
AWS Blogでは、Diagram as CodeとAmazon Bedrockを組み合わせたアーキテクチャ図の自動生成手法が紹介されています。
生成AIによる図表自動生成と一貫性の課題
生成AIを使ってAWS構成図を自動生成する場合、出力の一貫性や正確性を保つのが難しいという課題があります。
同じCloudFormationテンプレートと要件を与えても、AIの温度パラメータやプロンプトの書き方次第で、毎回微妙に異なるYAMLや図表が生成されてしまうのは厄介です。
中間ファイルとプロンプト設計による安定化
AWS Blogでは、この課題に対して以下のような工夫が紹介されています。
1. 中間ファイル（YAML）を経由
- 直接図を生成するのではなく、一度AWS Diagram-as-code用のYAMLファイルを生成し、それを図表化することで、出力内容を明示的にコントロールしています。
- 生成物の差分管理や手動修正も可能になります。
2. プロンプト設計の工夫
- 生成AIへの指示（プロンプト）に以下のようなものが含まれています。
- 「Diagram-as-code YAMLのみを返す」「説明文は不要」などの指示
- カスタムルールやスキーマ
- インプット例（画像）
- 出力形式や内容を厳密に指定することで、AIの“ゆらぎ”を抑制しています。
3. 推論パラメータの固定
- temperature=0.2など、AIのランダム性を下げる設定を使うことで、同じ入力からほぼ同じ出力が得られます。
4. 差分検証スクリプトの活用
- CloudFormationと生成YAMLのリソース一覧を比較し、抜けや余計なノードを自動チェックすることで、品質を担保しています。
中間ファイル作成のフロー
(自然言語)\”]\n C[\”Amazon Bedrock
(要件解釈・中間出力)\”]\n D[\”中間 Dac YAML ファイル\”]\n E[\”Diagram-as-code ツール
(図の描画)\”]\n F[\”アーキテクチャ図
(PNG等)\”]\n G[\”フィードバック\”]\n\n A –> C\n B –> C\n C –> D\n D –> E\n E –> F\n F –> G\n G –> C\n\n subgraph \”Inputs\”\n A\n B\n end”,”key”:”81862d139440185e6eb98e281459cc75″}”>
パラメータ指定部分の実装例（Pythonコード抜粋、公式ブログより引用）
# Amazon Bedrock へメッセージを送信
response = client.converse(
modelId = model_id,
messages = conversation,
inferenceConfig={"maxTokens": 8192, "temperature": 0.2, "topP": 0.9},
)
response_text = response["output"]["message"]["content"][0]["text"]
カスタムルール（公式ブログより引用）
CUSTUMRULE.txt
全体に関する指示
- YAML構文に従い、回答に不要な説明や説明文を含めないでください。
- 回答の最初と最後にトリプルバッククォートのYAMLマーカーを含めないでください。
Links に関する指示
- 特に指示がない場合、CloudFormation template に含まれる Resource は全て表示してください。
- Resources の後に Links を出力してください
- Links セクションでは、SourcePosition が S の場合、TargetPosition は N が望ましく、その逆も同様です。また、SourcePosition が E の場合、TargetPosition は W が望ましく、その逆も同様です。
- Links セクションの要素は、Resource セクションに存在する Resource 間でのみ接続する必要があり、存在しない Resource を Source もしくは Target に指定することはできません。
- Links セクションの要素には必ず orthogonal プロパティを追加し、Source から Target への方向を明示してください。
- AWS::Diagram::VerticalStackとAWS::Diagram::HorizontalStack はグループ化に使用し描画しないソースであるため、Link の Source と Target に指定しないでください。
- 同じ SourcePosition や TargetPosition を指定する Link が 3 つ以上存在する場合、2文字目に同じ方角を重ねた後、3文字目に違う方角を追加し Link が重なることを避けてください（例: 同じ Resource の同じ Position である N を指定する複数の Link が存在する場合、Position の値を NNE, NNW とすることで描画時の Link の重なりを避けることができます)
Resource に関する指示
- 同じ Resource を 複数の Resource の Children プロパティに指定できません。子の親は必ず 1 つです。
- Resource が所属するグループを明示的に指定する場合は、AWS::Diagram::Resource を使用し、その Children プロパティにグループに所属させたい Resource を指定してください。
- 指示がありUserアイコンを表示した方が良い場合には、以下の表記を使用できます：
User:
Type: AWS::Diagram::Resource
Preset: "User"
Label に関する指示
- 同じ Resource を Target もしくは Source として指定する複数の Link があり、それぞれに Label がある場合、Label の重なりを防ぐため Label のプロパティに TargetLeftまたはTargetRight を使用してください。
- Resource アイコンの下には Label が付与されるため、SourcePositionがSのLink の Label は TargetLeft か TargetRight のプロパティ使用して配置してください
配置に関する指示
- VerticalStack の Children は西(W)から東(E)に描画されます。HorizontalStack の Children は北(N)から南(S)に描画されます。
- Userからの距離が2より大きい Resource については、HorizontalStackまたはVerticalStackをネストして使用することを積極的に検討してください。これにより Links で Resource を接続した時に、 Links がアイコンと重なる可能性が下がります
- Vertical と Horizontal を交互に使ってリソースを配置することで図全体が一方向に長くならないようにしてください。
- 以下の優先度のルールに従って配置してください。優先度は値が小さいものが優先されます。
1. Link は SourcePosition: S と TargetPosition: N で固定してください。ただし、深い階層から浅い階層へフィードバックする Link のみ SourcePosition, TargetPosition に E もしくは W が許可されます。
2. AWSCloud (AWS::Diagram::Cloud) の中で AWS::Diagram::HorizontalStack で hierarchy を作成してください。hierarchy は User から辿れる Link 数です。hierarchy は何個作成しても構いません。
3. Link が交差しないように Children の順序を入れ替えてください。Link(A->D), Link(B->C) ならば VerticalStack(HorizontalStack(A, B), HorizontalStack(D, C)) が Link が交差しない HorizontalStack 内の Children の順序です。前の hierarchy の並び順から Link されている Resource の順序を決定してください。
このように、中間ファイルの導入やプロンプト設計の工夫によって、生成AIを使った図表自動生成でも一貫性・再現性を高めることが可能です。生成AIの“創造性”と、業務で求められる“安定性”を両立するための実践的なノウハウとして、非常に参考になる事例です。
7. 他ツールとの比較
Diagram as Codeの位置づけを理解するために、主要な図表作成ツールを3つのカテゴリに分けて比較してみましょう。
GUIベースの図表作成ツール
Draw.io、Lucidchart、PowerPointなどのGUIツールは、マウス操作で直感的に図表を作成できるのが特徴です。ドラッグ&ドロップで要素を配置し、視覚的に編集できるため、コード記述が苦手な方でも使いやすく、汎用的な図表作成に適しています。
ただし、複雑な構成になると手作業での修正が煩雑になり、バージョン管理やチーム間での共有に課題があります。また、AWSリソースの正確な表現には、アイコンの手動配置や関係性の手動設定が必要です。
| ツール | 図解の豊富さ | バージョン管理 | AIとの相性 | AWSとの相性 |
|---|---|---|---|---|
| Draw.io | 高（豊富な図形・テンプレート） | 中（ファイルベース） | 中 | 中 |
| Lucidchart | 高（プロプランもあり） | 中（クラウド同期） | 中 | 中 |
| PowerPoint | 中（基本的な図形） | 低（ローカルファイル） | 低 | 中 |
テキストベースの図解ツール
PlantUML
UML図全般に対応し、クラス図、シーケンス図、コンポーネント図など豊富な図種をサポートします。専用のDSL（Domain Specific Language）で図を記述し、主要IDEとの統合も充実しています。
システム設計やアーキテクチャ設計に適しており、テキストベースのためバージョン管理が容易です。ただし、UML記法の理解が必要で、AWS特化の機能はありません。
Mermaid
Webベースで動作し、GitHubのREADME.mdやIssueで直接表示できるのが特徴です。JavaScriptライブラリとして動作するため、サーバー不要で軽量です。
実は、MermaidでもAWS構成図を美しく作成できるようです。以下の記事では、AWS公式アイコンを使用した構成図の作成方法が詳しく紹介されています。ただし、私自身はこの記事ほど使いこなせていないので、若干難しく感じました。
これらはフローチャートやシーケンス図の作成に適しており、学習コストも低いです。ただし、複雑な構成図を作成するには一定の学習が必要です。
| ツール | 図解の豊富さ | バージョン管理 | AIとの相性 | AWSとの相性 |
|---|---|---|---|---|
| PlantUML | 中（UML全般対応） | 高（テキストベース） | 高 | 低 |
| Mermaid | 中（AWSアイコン対応） | 高（GitHub統合） | 高 | 中 |
AWS特化の図表作成ツール
AWS Diagram-as-code (awsdac)
AWSインフラ図に特化しており、AWS公式アイコンを使用した図表を作成できます。
中間ファイルを生成するため、リソース間の関係を具体的に記述したり、後から編集することが可能になります。
また、CloudFormationテンプレートからの直接変換も可能で、AWS環境の可視化に最適です。
AWS Documentation MCP Server
AWS Documentation MCP Serverは、Model Context Protocol（MCP）を使用してAWSドキュメントにアクセスし、図表生成を支援するツールです。
MCPサーバーを活用することで、LLMにAWSドキュメントの情報を参照させ正確な図表作成が可能になります。
Diagram as Codeとは少し異なりますが、非常に手軽で便利です。
例えば、以下のような依頼をするだけで簡単にAWS構成図を作成できます。
シンプルなサーバーレスアーキテクチャの構成図をAWS Diagram MCP Serverを使って書いて
| ツール | 図解の豊富さ | バージョン管理 | AIとの相性 | AWSとの相性 |
|---|---|---|---|---|
| awsdac | 中（AWS特化） | 高 | 高 | 高 |
| AWS MCP Server | 中（AWS特化） | 中 | 高 | 高 |
9. 将来の展望
双方向変換の実現
最も期待されるのは、CloudFormation/Terraformとの双方向変換です。現在はCloudFormationからDiagram as Codeへの一方向変換が可能ですが、将来的にはTerraformへの対応や逆方向の変換も実現されるでしょう。
双方向変換がもたらす革新的なワークフロー
双方向変換が可能になると、以下のような新しい設計プロセスが実現できます：
1. 設計段階：自然言語から自動生成
- 自然言語で要件を入力
- AIが自動でIaCテンプレート（CloudFormation/Terraform）と図表を同時生成
- 人間が理解しやすい図表ベースで編集も可能な状態
2. レビュー・修正段階：図表ベースでの編集
- 生成された図表を人間が視覚的に確認
- 変更点を自然言語で指示するか、図表を直接編集
- 修正内容が即座に図表と元のIaCテンプレートに反映される
3. コードレビュー段階：AIによる自動チェック
- 複雑なコードを読み解く必要がなくなる
- 図表ベースでのレビューが可能
- AIによる自動解析でセキュリティ要件やWell-Architected構成のチェック
具体的なメリット
このワークフローにより、以下のようなメリットが期待できます：
- 非エンジニアでも参加可能：図表を見ながら自然言語で修正指示ができる
- レビュー効率の向上：コードレベルではなく、図表レベルでのレビューが可能
- 品質向上：AIによる自動チェックでセキュリティやベストプラクティスの漏れを防止
- 設計と実装の乖離解消：図表とコードが常に同期される
10. まとめ
Diagram as Codeは、AWSインフラの構成図作成への新しいアプローチです。従来の手作業による煩雑さを解消し、設計や運用の効率化に役立ちます。
- 図表をテキストで管理することで、バージョン管理や再利用がしやすくなる。
- aws公式ツールを使うと、AWSリソースに特化した構成図を簡単に作成できる。
- 生成AIと連携することで、要件から図表を自動生成したり、IaCテンプレートと図表の同期が可能になる。
- 今後は、CloudFormationやTerraformとの双方向変換や、AIによる自動レビューなど、さらなる発展が期待される。
まずは小さな図から試してみることで、Diagram as Codeの利便性を実感できるはずです。ぜひ皆さんも試してみてください！
Views: 0
