💨

AIが生成した大量の文書を読むのに疲れたのでD2で図にしてもらったら革命が起きた

に公開
AI
Claude Code
Vibe Coding
Codex
tech

はじめに：文字の海で溺れる開発者たち

最近、AIが生成する技術文書の量がとんでもないことになっていませんか？

ChatGPTに「このシステムの設計について詳しく説明して」と聞くと、確かに詳細で正確な文書が返ってくる。でも、その結果がA4用紙で10枚分の文字の羅列だったりして、読むだけで疲れ果ててしまう。

特に複雑なドメインモデルやアーキテクチャの説明において、「テキストだけ」の限界を感じることが増えました。そんな時に出会ったのがD2という革命的なダイアグラム作成ツールです。

この記事では、D2を使ってAI生成ドキュメントを直感的で理解しやすい図表に変換する方法と、その劇的な効果について解説します。

D2とは何か？なぜ革命的なのか

D2は、terrastruct社が開発したテキストベースのダイアグラム作成ツールです。PlantUMLやMermaidを使ったことがある方なら、その進化版だと考えてください。

D2の特徴

1. 直感的な構文

# これだけで関係性を表現できる
ユーザー -> 注文管理システム: 注文作成
注文管理システム -> 在庫管理: 在庫確認
注文管理システム -> 決済システム: 決済処理

2. 美しいビジュアル
D2で生成される図は、PowerPointで手作りしたような洗練された見た目になります。

3. 柔軟性

  • フローチャート
  • アーキテクチャ図
  • ER図
  • UMLクラス図
  • ネットワーク図
  • マインドマップ

すべてが同じ構文で作成可能です。

D2の3つの圧倒的な強み

1. 学習コストの低さ

従来のダイアグラムツールは習得に時間がかかりました。D2の構文は自然言語に近く、5分で基本をマスターできます。

# 矢印と文字だけで関係性を表現
API Gateway -> User Service
API Gateway -> Order Service  
API Gateway -> Payment Service

User Service -> Database
Order Service -> Database
Payment Service -> External Payment API

2. バージョン管理との親和性

テキストベースなので、Gitで管理できます。差分も一目瞭然。

git diff architecture.d2

コードレビューで図の変更理由も追跡可能になります。

3. AIとの相性の良さ

これが最大の革命ポイント。AIにD2の構文で図を生成してもらえるのです。

従来のやり方：

  1. AIに説明文を書いてもらう
  2. 人間が読んで理解する
  3. 手動で図を作成する

D2 + AIのやり方：

  1. AIにD2構文で図を直接生成してもらう
  2. 即座に視覚化
  3. 必要に応じて微調整

実例1：ECサイトのドメインモデリング

実際のプロジェクトで試してみました。ECサイトの要件をAIに投げて、D2で図にしてもらった例です。

プロンプト例

ECサイトのドメインモデルをD2の構文で作成してください。
ユーザー、商品、注文、決済の関係性を含めて。

AI生成のD2コード

# ECサイト ドメインモデル

direction: right

ユーザー: {
  shape: class
  属性: |md
    - ユーザーID
    - 名前
    - メールアドレス
    - パスワード
  |
}

商品: {
  shape: class
  属性: |md
    - 商品ID
    - 商品名
    - 価格
    - 在庫数量
  |
}

注文: {
  shape: class
  属性: |md
    - 注文ID
    - 注文日時
    - 合計金額
    - ステータス
  |
}

決済: {
  shape: class
  属性: |md
    - 決済ID
    - 決済方法
    - 決済日時
    - 金額
  |
}

カート: {
  shape: class
  属性: |md
    - カートID
    - 作成日時
  |
}

# 関係性
ユーザー -> カート: "1:1"
ユーザー -> 注文: "1:*"
カート -> 商品: "*:*"
注文 -> 商品: "*:*"
注文 -> 決済: "1:1"

この図を見た瞬間、チーム全員が「あ、こういうことか！」と理解できました。30ページの要件定義書よりも、この1枚の図の方が遥かに価値があったのです。

実例2：マイクロサービスアーキテクチャ

次は、より複雑なシステムアーキテクチャの例です。

D2で表現したマイクロサービス構成

# マイクロサービス アーキテクチャ

direction: down

クライアント: {
  shape: rectangle
  style.fill: "#e1f5fe"
}

API Gateway: {
  shape: rectangle  
  style.fill: "#f3e5f5"
}

認証サービス: {
  shape: rectangle
  style.fill: "#fff3e0"
}

ユーザーサービス: {
  shape: rectangle
  style.fill: "#fff3e0"
}

注文サービス: {
  shape: rectangle
  style.fill: "#fff3e0"
}

商品サービス: {
  shape: rectangle
  style.fill: "#fff3e0"
}

決済サービス: {
  shape: rectangle
  style.fill: "#fff3e0"
}

# データベース層
認証DB: {
  shape: cylinder
  style.fill: "#e8f5e8"
}

ユーザーDB: {
  shape: cylinder
  style.fill: "#e8f5e8"
}

注文DB: {
  shape: cylinder
  style.fill: "#e8f5e8"
}

商品DB: {
  shape: cylinder
  style.fill: "#e8f5e8"
}

# 外部API
決済API: {
  shape: cloud
  style.fill: "#ffebee"
}

# 接続関係
クライアント -> API Gateway

API Gateway -> 認証サービス
API Gateway -> ユーザーサービス
API Gateway -> 注文サービス
API Gateway -> 商品サービス

注文サービス -> 決済サービス
決済サービス -> 決済API

認証サービス -> 認証DB
ユーザーサービス -> ユーザーDB
注文サービス -> 注文DB
商品サービス -> 商品DB

# サービス間通信
注文サービス -> ユーザーサービス: "ユーザー情報取得"
注文サービス -> 商品サービス: "在庫確認"

このアーキテクチャ図により、新しいチームメンバーも即座にシステム全体を把握できるようになりました。

実例3：データフロー図

データの流れを表現するのもD2の得意分野です。

# データ処理パイプライン

direction: right

外部API: {
  shape: cloud
  style.fill: "#bbdefb"
}

データ取得: {
  shape: rectangle
  style.fill: "#c8e6c9"
}

データ変換: {
  shape: rectangle  
  style.fill: "#ffe0b2"
}

データ検証: {
  shape: diamond
  style.fill: "#f8bbd9"
}

データ保存: {
  shape: rectangle
  style.fill: "#d1c4e9"
}

エラーログ: {
  shape: rectangle
  style.fill: "#ffcdd2"
}

データベース: {
  shape: cylinder
  style.fill: "#e0f2f1"
}

# フロー
外部API -> データ取得: "JSON"
データ取得 -> データ変換: "Raw Data"
データ変換 -> データ検証: "Normalized Data"
データ検証 -> データ保存: "Valid Data"
データ検証 -> エラーログ: "Invalid Data"
データ保存 -> データベース: "Processed Data"

AIとD2の組み合わせがもたらす革命

Before（AI生成文書のみ）

  • 理解に時間がかかる
  • 認識の齟齬が発生しやすい
  • レビューが困難
  • 属人的な解釈になりがち

After（AI + D2）

  • 瞬間的な理解
  • 共通認識の醸成
  • 効率的なレビュー
  • 客観的な情報共有

実際の開発プロセスの変化

設計フェーズ：

  1. 要件をAIに投げる
  2. D2構文で図を生成してもらう
  3. チームでレビュー・修正
  4. 即座に更新版を可視化

実装フェーズ：

  1. 図を見ながらコーディング
  2. 変更があれば図も同時更新
  3. 常に最新の設計書が手元にある

保守フェーズ：

  1. 新機能追加時に図を確認
  2. 影響範囲を視覚的に把握
  3. 安全な変更が可能

D2導入の実践的なアドバイス

1. 段階的導入

いきなり全てをD2化する必要はありません。

Step 1: 小さなフローチャートから開始
Step 2: ドメインモデルに拡張
Step 3: アーキテクチャ図に適用

2. チーム内でのテンプレート化

よく使う図のパターンをテンプレート化しておくと効率的です。

# アーキテクチャ図 テンプレート
direction: down

# フロントエンド層
frontend: {
  shape: rectangle
  style.fill: "#e1f5fe"
}

# API層  
api: {
  shape: rectangle
  style.fill: "#f3e5f5"
}

# ビジネスロジック層
business: {
  shape: rectangle
  style.fill: "#fff3e0"
}

# データ層
data: {
  shape: cylinder
  style.fill: "#e8f5e8"
}

frontend -> api
api -> business
business -> data

3. AIとの効果的な協働方法

良いプロンプトの例：

以下の要件をD2の構文でシステム構成図として表現してください。
- 要件: [具体的な要件]
- 含めるコンポーネント: [A, B, C]
- 関係性: [具体的な関係性]
- 色分け: [役割ごとに色分け]

導入時の注意点とベストプラクティス

注意点

  1. 過度な詳細化を避ける
    図が複雑になりすぎると、本来の目的である「理解しやすさ」が損なわれます。

  2. ツールへの依存
    D2は素晴らしいツールですが、図にできない情報もあります。補完的な文書も必要です。

  3. チーム内での統一
    記法やスタイルをチーム内で統一しないと、かえって混乱を招きます。

ベストプラクティス

  1. 目的を明確にする
    何のための図なのかを明確にしてから作成する

  2. 定期的な更新
    コードと同様に、図も生きたドキュメントとして維持する

  3. レビュープロセスの確立
    図の変更もコードレビューと同様にチェックする

まとめ：図解化がもたらした開発体験の革命

文字の海で溺れていた私たちが、図という救命ボートを手に入れました。AIが生成する大量の情報を、D2という魔法の杖で美しい図に変換する。これこそが、現代の開発者に必要なスキルかもしれません。

皆さんも、次回AIに設計について質問する際は、ぜひ「D2の構文で図にして」と追加してみてください。きっと新しい世界が開けるはずです。

参考リンク

Discussion