目次
はじめに
「AIにアーキテクチャ図を描かせてみたけど、なんかイマイチ…」そう感じて、結局PowerPointを自分で開いた経験はありませんか？
SEやコンサルとして日々の業務をこなす中で、アーキテクチャ構成図の作成は避けて通れない作業のひとつです。「どうせ作るならAIに任せたい」——その発想は正解です。でも、ただ「図を作って」と投げるだけでは、AIは期待に応えてくれません。
実は、結果を左右するのはAIエンジンの違いよりも、プロンプトの設計力かもしれない。
そこで今回は、その仮説を実際に検証してみました。ChatGPTとClaudeという二大AIを使い、7種類のプロンプトパターンでアーキテクチャ図を生成。出力のクオリティ、表現の正確さ、実務での使いやすさを徹底的に比べています。
この記事を読み終えるころには、
・どのAIが構成図生成に向いているのか
・どんなプロンプトを書けば「使える図」が出てくるのか
・明日の業務からすぐに試せる最適解
が、はっきり見えているはずです。
「AIに図を描かせる」を、運任せから再現性のあるスキルへ。さっそく比較結果を見ていきましょう。
結論
今回比較したのは以下のパターンで、結論は「パターン4」が一番高品質な回答を得ました。
※筆者の好み・偏見を含む。
| パターン | 内容 |
|---|---|
| 1 | mermaid形式指定 |
| 2 | plantUML形式指定 |
| 3 | AI側でプロンプト出力（出力形式の指定なし） |
| 4 | AI側でプロンプト出力（出力形式の指定なし＆絶対に高品質な回答を促す） |
| 5 | AI側でプロンプト出力（出力形式の指定なし＆C4モデルのContainerレベルを指定） |
| 6 | AI側でプロンプト出力（plantuml形式指定＆絶対に高品質な回答を促す) |
| 7 | AI側でプロンプト出力（mermaid形式指定＆絶対に高品質な回答を促す） |
※上記プロンプトを「ChatGPT（GPT-5.3）」と「Claude（Sonet4.6）」で比較した。
実施内容
まず今回用意したプロンプトは以下の通りです。これをC
プロンプト①
以下の情報で、アーキテクチャ構成図をmermaid形式で出力してください。
【環境】
・インターネット環境
・自社環境
・お客様AWS環境
・お客様オンプレ環境
【環境情報】
・お客様オンプレ環境とお客様AWS環境は、ダイレクトコネクトで接続されている
・お客様オンプレ環境⇒インターネットはアクセス可能だが、逆はアクセス不可
・インターネット環境にはGithubが存在し、そこでソース管理を行っている。
・ソースはJavaを利用している。
・デプロイするには、インターネット環境⇒自社環境へcloneし、ビルドしたものをお客様AWS環境へコピーし、
その後お客様AWS環境上のkubernetes環境へデプロイする。デプロイが完了すれば、お客様オンプレ環境からGithubへアクセスし
ソースを取得したのちに、オンプレkubernetesへデプロイする。
・デプロイは、専用PCでkubectlコマンドにて実施している。プロンプト②
以下の情報で、アーキテクチャ構成図をplantUML形式で出力してください。
【環境】
・インターネット環境
・自社環境
・お客様AWS環境
・お客様オンプレ環境
【環境情報】
・お客様オンプレ環境とお客様AWS環境は、ダイレクトコネクトで接続されている
・お客様オンプレ環境⇒インターネットはアクセス可能だが、逆はアクセス不可
・インターネット環境にはGithubが存在し、そこでソース管理を行っている。
・ソースはJavaを利用している。
・デプロイするには、インターネット環境⇒自社環境へcloneし、ビルドしたものをお客様AWS環境へコピーし、
その後お客様AWS環境上のkubernetes環境へデプロイする。デプロイが完了すれば、お客様オンプレ環境からGithubへアクセスし
ソースを取得したのちに、オンプレkubernetesへデプロイする。
・デプロイは、専用PCでkubectlコマンドにて実施している。プロンプト③
以下の情報で、アーキテクチャ構成図をAIに出力してもらいたいと思っています。
高品質な回答を得るためのプロンプトを考えてください。
【環境】
・インターネット環境
・自社環境
・お客様AWS環境
・お客様オンプレ環境
【環境情報】
・お客様オンプレ環境とお客様AWS環境は、ダイレクトコネクトで接続されている
・お客様オンプレ環境⇒インターネットはアクセス可能だが、逆はアクセス不可
・インターネット環境にはGithubが存在し、そこでソース管理を行っている。
・ソースはJavaを利用している。
・デプロイするには、インターネット環境⇒自社環境へcloneし、ビルドしたものをお客様AWS環境へコピーし、
その後お客様AWS環境上のkubernetes環境へデプロイする。デプロイが完了すれば、お客様オンプレ環境からGithubへアクセスし
ソースを取得したのちに、オンプレkubernetesへデプロイする。
・デプロイは、専用PCでkubectlコマンドにて実施している。プロンプト④
以下の情報で、アーキテクチャ構成図をAIに出力してもらいたいと思っています。
高品質な回答を得るためのプロンプトを考えてください。
絶対に高品質な回答を得るように集中してください。時間がかかっても大丈夫なので品質に注力してください。
【環境】
・インターネット環境
・自社環境
・お客様AWS環境
・お客様オンプレ環境
【環境情報】
・お客様オンプレ環境とお客様AWS環境は、ダイレクトコネクトで接続されている
・お客様オンプレ環境⇒インターネットはアクセス可能だが、逆はアクセス不可
・インターネット環境にはGithubが存在し、そこでソース管理を行っている。
・ソースはJavaを利用している。
・デプロイするには、インターネット環境⇒自社環境へcloneし、ビルドしたものをお客様AWS環境へコピーし、
その後お客様AWS環境上のkubernetes環境へデプロイする。デプロイが完了すれば、お客様オンプレ環境からGithubへアクセスし
ソースを取得したのちに、オンプレkubernetesへデプロイする。
・デプロイは、専用PCでkubectlコマンドにて実施している。プロンプト⑤
以下の情報で、アーキテクチャ構成図をAIに出力してもらいたいと思っています。
高品質な回答を得るためのプロンプトを考えてください。
C4モデルのContainerレベルで構成図を作成してほしいです。
【環境】
・インターネット環境
・自社環境
・お客様AWS環境
・お客様オンプレ環境
【環境情報】
・お客様オンプレ環境とお客様AWS環境は、ダイレクトコネクトで接続されている
・お客様オンプレ環境⇒インターネットはアクセス可能だが、逆はアクセス不可
・インターネット環境にはGithubが存在し、そこでソース管理を行っている。
・ソースはJavaを利用している。
・デプロイするには、インターネット環境⇒自社環境へcloneし、ビルドしたものをお客様AWS環境へコピーし、
その後お客様AWS環境上のkubernetes環境へデプロイする。デプロイが完了すれば、お客様オンプレ環境からGithubへアクセスし
ソースを取得したのちに、オンプレkubernetesへデプロイする。
・デプロイは、専用PCでkubectlコマンドにて実施している。プロンプト⑥
以下の情報で、アーキテクチャ構成図をAIに出力してもらいたいと思っています。
高品質な回答を得るためのプロンプトを考えてください。
絶対に高品質な回答を得るように集中してください。時間がかかっても大丈夫なので品質に注力してください。
mermaid形式で出力してください
【環境】
・インターネット環境
・自社環境
・お客様AWS環境
・お客様オンプレ環境
【環境情報】
・お客様オンプレ環境とお客様AWS環境は、ダイレクトコネクトで接続されている
・お客様オンプレ環境⇒インターネットはアクセス可能だが、逆はアクセス不可
・インターネット環境にはGithubが存在し、そこでソース管理を行っている。
・ソースはJavaを利用している。
・デプロイするには、インターネット環境⇒自社環境へcloneし、ビルドしたものをお客様AWS環境へコピーし、
その後お客様AWS環境上のkubernetes環境へデプロイする。デプロイが完了すれば、お客様オンプレ環境からGithubへアクセスし
ソースを取得したのちに、オンプレkubernetesへデプロイする。
・デプロイは、専用PCでkubectlコマンドにて実施している。プロンプト⑦
以下の情報で、アーキテクチャ構成図をAIに出力してもらいたいと思っています。
高品質な回答を得るためのプロンプトを考えてください。
絶対に高品質な回答を得るように集中してください。時間がかかっても大丈夫なので品質に注力してください。
plantUML形式で出力してください
【環境】
・インターネット環境
・自社環境
・お客様AWS環境
・お客様オンプレ環境
【環境情報】
・お客様オンプレ環境とお客様AWS環境は、ダイレクトコネクトで接続されている
・お客様オンプレ環境⇒インターネットはアクセス可能だが、逆はアクセス不可
・インターネット環境にはGithubが存在し、そこでソース管理を行っている。
・ソースはJavaを利用している。
・デプロイするには、インターネット環境⇒自社環境へcloneし、ビルドしたものをお客様AWS環境へコピーし、
その後お客様AWS環境上のkubernetes環境へデプロイする。デプロイが完了すれば、お客様オンプレ環境からGithubへアクセスし
ソースを取得したのちに、オンプレkubernetesへデプロイする。
・デプロイは、専用PCでkubectlコマンドにて実施している。結果
まずは出力してみた感想をここに述べます。
■ChatGPT
| パターン | 出力結果（感想含む） |
|---|---|
| 1 | △ シンプルで粒度浅めのものが出力されている。間違ってはいないが、改行がイマイチだったり、”想定”という文言が含まれていたりする。（指示文の情報が不足しているのも原因ではあるが、、） |
| 2 | △ シンプルすぎる。視覚的には色付けされているためわかりやすいが、もう少し情報を増やしてほしいとの感想。 |
| 3 | 〇 英語の記載が多く日本語向けではなかったが、粒度は悪くない。個人的には「お客様AWS環境」は上部に記載し、「お客様オンプレ環境」は下に表現してほしいところなので、配置はイマイチ |
| 4 | 〇 悪くはないが、配置がイマイチなのと、意味のないオブジェクト(例：worker nodeなど)が存在する点がイマイチ |
| 5 | 〇 悪くはないが、改行や日本語の表現がイマイチ。 |
| 6 | △ 図のバランスがイマイチ。 |
| 7 | 〇 悪くない。色付けされているため、責務や分類がわかりやすいが、英語で記載されてしまっている。 |
■Claude
| パターン | 出力結果（感想含む） |
|---|---|
| 1 | 〇 シンプル。間違ってはいないが、改行がイマイチだったりする。 |
| 2 | 〇 悪くないが、凡例がイマイチすぎる。”凡例”とそもそも書いていないし、少し間違っている |
| 3 | 〇 悪くないが、AWS Direct Connectがどこを指している？といった具合にイマイチな部分が存在。 |
| 4 | ◎ 一番良い。図としての収まり、記載の粒度なども結構良いと思う一方で、もう少し色の数を減らして凡例をシンプルにする余地はあると思う。 |
| 5 | △ あまりよくない。色の表現もわかりにくく、凡例の大きさも常識的ではないと感じる。 |
| 6 | 〇 シンプルではあるが、必要な情報を捉えている印象。 |
| 7 | 〇 ふつうに良いと思うが、縦長のバランス感が少しイマイチ |
※AIへプロンプトを投げる前に必ず新たなチャットを開いています。
※すべての出力結果の図は下記に示します。
ChatGPT①
ChatGPT②
ChatGPT③
ChatGPT④
出力前プロンプト例
あなたは「クラウド・ネットワーク・セキュリティを横断的に理解しているシニアアーキテクト」です。
以下の要件をもとに、**実務レベルでそのまま設計レビューに使える高品質なアーキテクチャ構成図**を作成してください。
# ■最重要要件（必ず守ること）
- Mermaid形式で出力すること
- そのままレンダリング可能な完全なコードで出力すること
- 図は「ネットワーク境界」「通信方向」「データフロー」が一目で分かること
- 抽象図は禁止。実務で使える粒度で具体的に表現すること
# ■図の表現ルール
- 環境ごとにサブグラフで明確に分離すること
- インターネット環境
- 自社環境
- お客様AWS環境
- お客様オンプレ環境
- 通信はすべて矢印で方向を明示すること
- 通信プロトコル・用途（例：HTTPS, kubectl, git clone 等）をラベルに記載
- 信頼境界（Trust Boundary）を明確にする
- Kubernetesは「Cluster」と「Node（必要に応じて）」を表現する
- AWSはVPC単位で表現すること
- Direct Connectは専用線として明示する
# ■必須で含める要素
- GitHub（ソース管理）
- 自社環境のビルド環境
- デプロイ用PC（kubectl実行端末）
- お客様AWS環境
- VPC
- Kubernetesクラスター
- お客様オンプレ環境
- Kubernetesクラスター
- Direct Connect接続
- ソースコードの流れ
- ビルド成果物の流れ
- デプロイ経路
# ■前提条件（厳密に反映すること）
- お客様オンプレ環境とAWS環境はDirect Connectで接続されている
- オンプレ → インターネットは可能だが、インターネット → オンプレは不可
- GitHubはインターネット上に存在する
- ソースはJava
- デプロイフロー：
1. GitHub → 自社環境へclone
2. 自社環境でビルド
3. 成果物をAWS環境へコピー
4. AWS上のKubernetesへkubectlでデプロイ
5. その後、オンプレ環境からGitHubへアクセスしソース取得
6. オンプレKubernetesへデプロイ
# ■追加で考慮すること（重要）
- セキュリティ観点（アクセス制御の制約を図で表現）
- ネットワーク的に不可能な通信は絶対に描かない
- 実際にあり得る運用にすること（ファイル転送経路など）
# ■出力形式
1. Mermaidコード
2. 図の補足説明（簡潔に）
3. 設計上のポイント（3〜5点）
# ■禁止事項
- 抽象的な表現（例：「サーバー」だけなど）
- 通信方向が不明な図
- 現実的でない構成ChatGPT⑤
出力前プロンプト例
あなたは「クラウド・ネットワーク・Kubernetes・セキュリティを横断的に理解しているシニアアーキテクト」です。
以下の要件をもとに、設計レビューにそのまま提出できるレベルのC4モデル（Containerレベル）構成図を作成してください。
■出力要件（最重要）
Mermaid形式で出力すること
そのままレンダリング可能な完全なコードを出力すること
C4モデルのContainerレベルとして表現すること
各コンテナに以下を明記すること
名前
技術スタック（例：Java, Kubernetes, GitHub など）
役割（簡潔に）
システム境界（Environment単位）を明確に分離すること
通信方向（矢印）を必ず明示すること
ネットワーク制約・セキュリティ制約を正しく反映すること
■表現ルール
以下の4つの環境を明確に分離すること
インターネット環境
自社環境
お客様AWS環境
お客様オンプレ環境
各環境は「境界（Boundary）」として表現すること
Kubernetesは「クラスタ」と「その中のアプリケーションコンテナ」を分けて表現すること
デプロイ用PC（kubectl実行端末）は独立したコンテナとして表現すること
GitHubはSaaSとして外部コンテナ扱いにすること
■前提条件（必ず反映）
お客様オンプレ環境とお客様AWS環境はDirect Connectで接続されている
お客様オンプレ環境はアウトバウンドのみ許可（インターネット→オンプレは不可）
インターネット環境にはGitHubが存在し、ソース管理を行う
ソースコードはJava
■デプロイフロー（必ず図に反映）
以下の流れを矢印で明確に表現すること：
① インターネット環境（GitHub）
↓ clone
② 自社環境でビルド
↓ 成果物コピー
③ お客様AWS環境へ配置
↓ kubectl
④ AWS上のKubernetesへデプロイ
その後：
⑤ お客様オンプレ環境からGitHubへアクセスしソース取得
↓
⑥ オンプレKubernetesへデプロイ
■追加で考慮すべきこと（重要）
通信プロトコル（HTTPS / SSH / kubectl など）を可能な範囲で記載
セキュリティ的に不自然な通信は避ける
コンテナ間の責務を曖昧にしない
実務でレビュー指摘されない粒度で記述する
■出力形式
Mermaidコードのみを出力（説明文は不要）ChatGPT⑥
ChatGPT⑦
Claude①
Claude②
Claude③
Claude④
Claude⑤
Claude⑥
Claude⑦
気づき
■プロンプト出力
・出力されたプロンプトは、コピー＆ペーストしやすい場合とそうでない場合があり、再現性にばらつきがある
・Mermaid形式のコードが期待どおり出力されないケースがあり、実務での安定運用には注意が必要
■ 図の出力品質
・ChatGPTは形式を指定しない場合、Mermaid形式を自動推奨する傾向がある
・Claudeは指示なしで凡例の追加・色付けを自律的に実施してくれた。有料ツールとしての品質の高さを実感
・AIにプロンプトを考えさせる場合、提供した情報をもとにAIが勝手に情報を補完するため、一見それらしいが正確ではない情報が混入するリスクがある。生成結果の内容確認は必須
・図のレイアウトは指定しないと収まりが悪くなりやすい。要素の配置位置まで明示的に指示するのが望ましい
※ただし実運用では、まず出力させてから結果を見てプロンプトを改善する反復アプローチが現実的で効果的
まとめ
今回の検証でもっとも大きな気づきは、「AIにプロンプトを考えてもらう＝正解」ではない、ということです。むしろ、人間側がプロンプトの意図や構造を理解した上で設計することが、高品質な出力への近道だと実感しました。
また、ChatGPTとClaudeでここまで出力に差が出るとは予想以上でした。同じプロンプトでもエンジンが変わるだけで図のスタイルや情報の解釈が大きく異なり、「何を使うか」と「どう頼むか」の両方が成果を左右することが明確になりました。
日常業務の中でこれほど体系的にAIを比較する機会はなかなかありません。その意味で今回は非常に貴重な経験でした。と同時に、ユースケースごとに最適なAI・最適なプロンプトを使い分けていくことの難しさと奥深さも痛感しています。
AIを「なんとなく使う」から**「意図を持って使いこなす」**へ——この記事がその一歩を踏み出すきっかけになれば幸いです。
コメント