Accenture Japan (有志)
🎆

Opus4.6でdraw.io図を生成したらもはやLLMの前提が崩れてた件

kaito.abe
に公開
AWS
グラフ理論
draw.io
Claude Code
システム構成図
idea

はじめに

「LLMは空間的な推論が苦手」「テキストベースで座標を扱うのだから、複雑な図はぐちゃぐちゃになるはず」──これは自分がずっと持っていた前提でした。おそらく同じように考えている方も多いのではないでしょうか。

実際、以前のモデルで試した限りでは、この前提はおおむね正しかったと思います。構成が複雑になれば矢印が交差して読みにくい図になり、結局は人力で修正することになる。グラフ理論的に考えても、コンポーネント数が増えれば交差は避けられないはずだ──と。

本記事では、この「LLMでは複雑な構成図はまともに作れない」という前提を、AWSアーキテクチャの構成図を段階的に複雑にしながらClaude Code（Opus 4.6モデル）で検証してみた結果を共有します。先に結論を言うと、この前提はもはや成り立たなくなっていました。

「ぐちゃぐちゃな図」とは何か

まず、前提として「ぐちゃぐちゃ」という主観的な表現を少し具体的に定義してみます。構成図が「読みにくい」と感じるとき、多くの場合は以下のような特徴があるのではないでしょうか。

  • 矢印（エッジ）の交差が多い: コネクタ同士が何度も交差していて、どの線がどこに繋がっているのか追いにくい
  • オブジェクト配置の一貫性がない: 同じレイヤー（例えばPublic SubnetとPrivate Subnet）にあるべきコンポーネントが上下左右バラバラに配置されている
  • ラベルの重なり: コンポーネント名やコネクタのラベルが他のオブジェクトと重なって読めない
  • 空間の無駄遣いと密集の共存: 一部はスカスカなのに、一部が異常に密集している
  • 論理的なグルーピングが視覚的に表現されていない: VPC、サブネット、AZの包含関係が図の配置から読み取れない

グラフ理論から見る「ぐちゃぐちゃになるはず」という仮説

本題に入る前に、自分が「複雑な図はぐちゃぐちゃになるだろう」と予想していたのは過去にsonnet 4あたりのときに実際に試してみて、たたき台レベルの品質の図は作成できたのですが、人力での手直しが必要だった記憶があったからです。また、グラフ理論の観点から難しいだろうとの思い込みがありました。ちょっと簡単に整理しておきます。

平面グラフの辺数上限

グラフ理論には、平面グラフ（辺の交差なしに平面上に描画できるグラフ）に関する基本的な定理があります。

単純連結平面グラフにおいて、頂点数を n（n \geq 3）、辺数を m とすると、m \leq 3n - 6 が成り立つ。[1]

これは「辺の数が頂点数の約3倍を超えると、どう頑張っても辺の交差なしには描画できない」ことを意味しています。システム構成図に当てはめると、コンポーネント（頂点）が10個あれば、辺（接続線）が24本を超えた時点で交差は避けられないということになります。

交差補題（Crossing Lemma）

さらに踏み込むと、交差補題（Crossing Lemma）と呼ばれる定理があります。

辺数 e が十分に大きいグラフでは、交差数 cr(G) は \frac{e^3}{n^2} に比例する下界を持つ。[2]

つまり、辺密度が高くなると交差数は辺数の3乗に比例して急増するということです。コンポーネントを追加するたびに数本の接続線が増えるわけですが、その影響は線形ではなく、急激に図の複雑さを悪化させるはずです。

なぜAIにとって特に難しいはずなのか

グラフの交差数を最小化する問題はNP困難であることが知られています[3]。つまり、コンポーネント数が増えると、最適な配置を計算で求めることは現実的に不可能に近くなります。

人間が図を作る際には、以下のようなヒューリスティクスを無意識に使って整理しているのではないかと思います。

  • 階層構造の認識: ネットワークのトラフィックフロー（上から下へ）を直感的にレイヤー分けする
  • 対称性の活用: マルチAZ構成なら左右対称に配置する
  • グルーピング: 同じサブネット内のリソースは近くにまとめる
  • 重要度による優先: メインのデータフローを目立たせ、監視系の線は控えめにする

LLMはテキスト（XML）として座標値を生成する形でレイアウトを決めるため、こうした空間的な推論は苦手なはずです。GenAI-DrawIO-Creatorの研究でも、draw.io図の自動生成において高い初回精度が報告されている一方で、コンポーネント数が増えるとレイアウトの品質が低下する傾向が示されています[4]。

──という理論的な背景があったので、自分は「LLMに複雑な構成図を描かせるのは無理だ」という前提を持っていました。コンポーネント数が20個を超えたあたりで破綻するだろう、と。

実践: AWSアーキテクチャを段階的に複雑にして図を生成してみる

ここからは、実際にClaude Code（Opus 4.6モデル）にdraw.ioのXMLを生成させた結果を共有します。AWSの基本的なアーキテクチャを題材に、3段階で構成を複雑にしていきました。

Step 1: シンプルな構成（ALB + EC2 x 2 + RDS）

まず、最小限の構成からスタートします。

使用したプロンプト:

以下のAWSアーキテクチャのシステム構成図をdraw.ioのXML形式で作成してください。

  • ALBがインターネットからのトラフィックを受ける
  • ALBの背後にEC2インスタンスが2台（マルチAZ: AZ-a, AZ-b）
  • EC2からRDS（MySQL）に接続
  • コンポーネントはVPC内に配置

結果と分析:

この段階では、コンポーネント数は主要なもので5個（Internet、ALB、EC2 x 2、RDS）、接続線は5本程度です。グラフ理論的には m = 5、n = 5 で 3n - 6 = 9 なので、平面グラフの条件を十分に満たしています。

生成された図はきれいに配置されていて、トラフィックの流れ（上から下へ）が直感的に読み取れます。AZ-aとAZ-bの左右分割も適切です。まあ、この程度の複雑さであれば問題ないだろうとは思っていました。


図1：Step 1の構成図

Step 2: 中程度の構成（+ WAF, CloudFront, Route53, ElastiCache, SQS, Lambda, CloudWatch 等）

次に、本番環境でよく見かける要素を一気に追加してみます。ここから「崩れ始めるだろう」と予想していた段階です。

使用したプロンプト:

Step1の構成に以下を追加してdraw.ioのXML形式で作成してください。

  • Route53でDNS解決
  • CloudFrontをALBの前段に配置、WAFで保護
  • S3バケット（静的コンテンツ用 / データ保存用）
  • NAT Gateway経由でインターネットアクセス
  • ElastiCache（Redis）をEC2とRDSの間に配置
  • SQSキューとLambda関数による非同期処理
  • CloudWatch for monitoring
  • Secrets ManagerでDB認証情報管理
  • S3へのVPCエンドポイント
  • RDS Multi-AZ（Primary / Standby）

結果と分析:

コンポーネント数が約19個に増え、接続線も29本ほどになりました。3 \times 19 - 6 = 51 なのでまだ理論上は平面グラフの範囲内です。

正直に言うと、ここで予想が外れ始めました。もっと交差が多くなると思っていたのですが、実際に生成された図を見ると、以下の点がしっかり整理されていました。

  • VPC/AZ/サブネットのグルーピングが適切: 包含関係が視覚的にちゃんと表現されている
  • トラフィックフローが上から下への階層構造になっている: Internet → CloudFront → ALB → EC2 → RDSの流れが自然に読み取れる
  • マルチAZの左右対称配置: AZ-aとAZ-bが左右にきれいに分かれている

もちろん完璧ではありません。CloudWatchへの監視系の破線が複数のコンポーネントから伸びて交差する箇所や、SQS/Lambdaの配置がAZ間で浮いてしまう部分はあります。しかし「叩き台としてそのまま使える」レベルには十分達していると感じました。


図2：Step 2の構成図

Step 3: 複雑な構成（+ Cognito, API Gateway, ECS Fargate, DynamoDB, SNS, EFS, S3 Logs）

最後に、マイクロサービス化やセキュリティ要件が加わった本番環境レベルの構成まで拡張します。ここまで来れば「さすがに崩れるだろう」と思っていました。

使用したプロンプト:

Step2の構成にさらに以下を追加してdraw.ioのXML形式で作成してください。

  • CognitoでAPI認証
  • API Gatewayを追加
  • ECS Fargate によるコンテナワークロード（マルチAZ）
  • DynamoDBをLambdaの処理結果保存に使用
  • SNSでアラーム通知・イベント通知
  • EFS（共有ファイルシステム）
  • S3（ログ保存用）

結果と分析:

コンポーネント数は約27個、接続線は48本以上になりました。3 \times 27 - 6 = 75 なので理論上の上限にはまだ達していませんが、辺密度は確実に上がっています。

ここでも予想は覆されました。確かに図の情報量は多いのですが、構造としてはきちんと整理されています。

  • VPC外サービスが図の上部に2段にまとまっている: WAF、Route53、Internet、Cognito、CloudWatch、Secrets Manager、SNSが上段に、CloudFront、API Gateway、S3系、DynamoDBが中段にグルーピングされている
  • ALBを中心としたファンアウトが整然としている: ALBからEC2×2、ECS Fargate×2への4方向の接続線が、AZ-aとAZ-bにきれいに分岐している
  • 監視系の破線が実線と視覚的に区別されている: CloudWatchへの接続は破線+グレーで描画されており、メインのデータフローとの区別がつく

もちろん交差がゼロではありません。AZ-bのEC2/ECSからAZ-aのRDS PrimaryへのCross-AZ接続や、EC2とECS Fargateから同じ宛先への並走する接続線など、複雑さを感じる部分はあります。ただ、27個のコンポーネントと48本以上の接続線がある図としては、正直言って「かなり良い」と感じました。


図3：Step 3の構成図

3ステップの比較まとめ

Step 1 Step 2 Step 3
コンポーネント数 (n) 5 ~19 ~27
接続線数 (m) 5 29 48+
辺密度 (m/n) 1.0 1.5 1.8
平面上限 (3n-6) 9 51 75
体感的な品質 きれい 前提が揺らぐ 前提が崩れる

当初は「Step 2あたりから崩れ始め、Step 3では完全にぐちゃぐちゃになる」と予想していましたが、実際にはStep 3でも構造的な整理がしっかり保たれていました。グラフ理論的には交差が避けられない辺密度であっても、Opus 4.6モデルは人間が使うヒューリスティクス──階層構造、対称性、グルーピング──をかなりの精度で再現しています。「LLMには複雑な図は作れない」という前提は、ここで完全に崩れました。

崩れた前提 ── なぜ「LLMには無理」が通用しなくなったのか

ここまでの結果を踏まえて、自分が持っていた前提がなぜ崩れたのかを整理してみます。

前提①「LLMは空間的な推論が苦手」→ Opus 4.6では当てはまらない

これが最も大きな前提の崩壊です。「LLMはテキストベースだから空間的な推論は苦手なはず」という前提が、少なくともOpus 4.6モデルにおいてはもはや当てはまらなくなっています。XMLの座標値を「数字として」適切に配置できているということは、各コンポーネントの空間的な位置関係を理解して生成しているということではないかと思います。

前提②「複雑さが増せばヒューリスティクスは再現できない」→ パターン学習が想像以上に効いている

AWSの構成図には暗黙の配置ルール（「お作法」）があります。VPCの中にサブネットがあり、Public SubnetとPrivate Subnetは上下に分かれ、マルチAZは左右に並ぶ。「LLMにはこうしたヒューリスティクスの再現は難しいだろう」と思い込んでいましたが、トレーニングデータに含まれる大量のAWS構成図のパターンが、想像以上に効いているようです。階層構造、対称性、グルーピングといった人間が無意識に使うテクニックを、モデルがかなりの精度で再現できてしまっています。

前提③「一発で複雑な図は作れない」→ 段階的な構築で精度を維持できる

今回はStep 1→Step 2→Step 3と段階的にプロンプトを出しています。前のステップの構造を踏まえたうえで要素を追加しているため、一からStep 3の複雑な構成を生成させるよりもきれいになっている可能性はあります。ただしこれは「LLMの限界」というよりも「プロンプトの工夫で精度を高められる」という話であり、段階的に構築すればこのレベルの品質が安定して出せるということ自体が、以前の前提からすれば十分な驚きです。

ただし完璧ではない ── 遭遇した落とし穴

前提が崩れたとはいえ、問題がなかったわけではありません。レイアウト以外の部分で遭遇した落とし穴も共有しておきます。

アイコンが正しく描画されない問題

AIに生成させたdraw.ioのXMLではアイコンが正しく表示されないという問題に遭遇しました。具体的には、EC2のアイコンがオレンジ色の四角形で塗りつぶされてしまい、肝心のアイコンが見えないという現象です。

これはdraw.ioのAWSアイコンには複数の参照パターンが存在することに起因しています。例えばEC2の場合、AIが生成しがちな shape=mxgraph.aws4.ec2_instance と fillColor=#ED7100 の組み合わせでは、fillColorがアイコン全体を塗りつぶしてしまい、ただのオレンジ色の矩形になってしまいます。

draw.ioのAWSアイコンライブラリで実際に使われているスタイルを確認すると、shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.ec2 という形式で、fillColorとstrokeColorの組み合わせでアイコンの背景色と枠線色を制御しています。このresourceIconパターンを使わないと、アイコンの上にベタ塗りの色が被さってしまうようです。

同様の問題はEC2に限らず、他のAWSサービスアイコンでも起こり得ます。AIはdraw.ioのスタイル構文を「それっぽく」生成してくれますが、実際のアイコンライブラリが期待するスタイルの組み合わせとは微妙にずれていることがあるため、生成後に一度アイコンが正しく表示されているか確認することをおすすめします。

さらに品質を上げるためのテクニック

今回の結果は「そのまま使えるレベル」に近いものでしたが、さらに品質を上げるためのアプローチもいくつか紹介します。

1. 図を分割する

情報量が多い場合は、1枚の図に詰め込みすぎないことが依然として有効だと思います。

  • レイヤーごとに分割: ネットワーク構成図、アプリケーション構成図、監視構成図を別々の図にする
  • 関心事ごとに分割: メインのリクエストフロー、非同期処理フロー、管理系フローを分ける

グラフ理論的にも、頂点数と辺数を減らすことが交差数を減らす最も確実な方法です。

2. プロンプトやSkillsでルールを整備する

「何を描くか」だけでなく「どう配置するか」「XMLをどう書くか」まで明示的にルール化しておくと、さらに品質が安定します。レイアウト面では以下のような指示が有効です。

  • 座標の基準点やグリッドサイズを指定する
  • トラフィックの流れの方向（上→下、左→右）を指定する
  • 同じサブネット内のコンポーネントのY座標を揃えるよう指示する
  • 監視系の線は省略するか、別レイヤーにするよう指示する

3. 最小限のXMLスケルトンを先に渡す

VPCやサブネットのグループ構造（外枠）をあらかじめXMLとして用意し、その中にコンポーネントを配置させるアプローチも有効ではないかと考えています。これにより、グルーピングの品質をさらに安定させられるかもしれません。

4. draw.ioの自動レイアウト機能と組み合わせる

draw.ioにはHorizontal/Vertical Flow、Tree、Organicなどの自動レイアウト機能が搭載されています。AIが生成した図に自動レイアウトを適用してから微調整するというワークフローも選択肢の一つです。

特に階層的レイアウト（Sugiyama法に基づくもの）は、ネットワーク構成図のような上から下へのフローを持つ図と相性が良いとされています[5]。

まとめ

本記事では、「LLMでは複雑な構成図はまともに作れない」という前提のもと、AWSアーキテクチャを3段階で複雑にしながらClaude Code（Opus 4.6モデル）で図を生成してみました。

  • 「LLMは空間推論が苦手」という前提 → Opus 4.6では崩れた。 27コンポーネント・48接続線以上の構成でも構造的な整理が保たれていた
  • 「複雑な図はヒューリスティクスを再現できない」という前提 → 崩れた。 階層構造・対称性・グルーピングをかなりの精度で再現できている
  • 「叩き台レベルの品質しか出せない」という前提 → 崩れた。 そのまま使うことも十分現実的なレベル
  • ただし、アイコンのスタイル定義など、レイアウト以外の部分では依然として注意が必要

正直なところ、この記事を書き始めた時点では「なぜぐちゃぐちゃになるのか」を解説する記事にするつもりでした。しかし実際にOpus 4.6モデルで生成してみたら、自分が持っていた前提そのものが崩れてしまいました。

LLMの進化は、自分たちが「ここまでは無理だろう」と思っている境界線を静かに超えてきているのかもしれません。「LLMには空間的な推論は無理」という前提を更新するタイミングは、もう来ているのではないでしょうか。

同じようにAIでのシステム構成図生成に取り組んでいる方の参考になれば幸いです。

脚注

  1. オイラーの公式に基づく平面グラフの辺数上限。グラフ理論の基本定理として広く知られている。参考: https://en.wikipedia.org/wiki/Planar_graph#Maximal_planar_graphs ↩︎

  2. Ajtai, M., Chvátal, V., Newborn, M., Szemerédi, E. (1982). "Crossing-free subgraphs". Theory and Practice of Combinatorics, North-Holland Mathematics Studies, vol. 60. 同時期にLeighton, T.も独立に同様の結果を証明している。参考: https://en.wikipedia.org/wiki/Crossing_number_inequality ↩︎

  3. Garey, M. R., Johnson, D. S. (1983). "Crossing Number is NP-Complete". SIAM Journal on Algebraic and Discrete Methods, 4(3), 312-316. 参考: https://en.wikipedia.org/wiki/Crossing_number_(graph_theory) ↩︎

  4. Yu, J. et al. (2026). "GenAI-DrawIO-Creator: A Framework for Automated Diagram Generation". draw.io図の自動生成フレームワークで、初回のセマンティック精度94%を達成する一方、コンポーネント数の増加に伴うレイアウト品質の課題が示されている。参考: https://arxiv.org/html/2601.05162v1 ↩︎

  5. Sugiyama, K., Tagawa, S., Toda, M. (1981). "Methods for Visual Understanding of Hierarchical System Structures". IEEE Transactions on Systems, Man, and Cybernetics. 参考: https://en.wikipedia.org/wiki/Layered_graph_drawing ↩︎

Accenture Japan (有志)
Accenture Japan (有志)

アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。

Discussion