プロンプトから生きたドキュメントへ：Visual Paradigm の AI 搭載 C4 ワークフローのマスター

はじめに

現代のソフトウェア工学において、アーキテクチャ設計と技術ドキュメントの間のギャップは、プロジェクトが勢いを失う要因となることがよくあります。図面は古びたスクリーンショットになり、ドキュメントは現実から乖離し、新しいチームメンバーのオンボーディングは、レガシーな成果物を解読する退屈な作業になってしまいます。

Visual Paradigm の AI 搭載エコシステムは、チームが技術ドキュメントを作成・維持する方法を変革することで、この課題に対処します。会話型図面作成、構造化された C4 モデリング、集中型アセットパイプライン、そして生きたドキュメントを一つのシームレスなワークフローに統合することで、アーキテクチャとドキュメントが単一の真実の源として共に進化することを保証します。

このガイドでは、AI を用いた初期ブレインストーミングから自己更新型の生きたドキュメントの公開に至るまで、この完全なワークフローを包括的かつ段階的に解説します。広範な PlantUML の例とベストプラクティスも含まれています。

パート 1：主要概念とエコシステムの概要

4 つの柱

Visual Paradigm のエコシステムは、クローズドループワークフローを構築するために連携する 4 つの相互接続された AI 柱で構成されています：

OpenDocs パイプライン

パイプラインは、Visual Paradigm エコシステム内のすべての 5 つの実行環境を接続する、安全なクラウドホスト型の中央トランジットハブとして機能します。これにより、チームは手動でのファイル転送やスクリーンショットなしで、多様なソースからの成果物を直接統一された技術ドキュメントにストリーミングできます。

主要な特徴:

• クラウドホスト型リポジトリ：あらゆるデバイスから成果物にアクセス可能

• バージョン管理対応: コミットノート付きの自動リビジョン追跡

• 編集可能性が維持される: 図は静的画像ではなく、ソースモデルにリンクされたまま

• ロールベースのアクセス制御: プロジェクト、チーム、またはアーティファクトごとに権限を設定可能

• AI統合: AI生成およびAIによる洗練された図のネイティブサポート

5つの実行環境:

C4モデル

Simon Brownによって作成されたC4モデルは、4つのレベルにわたってソフトウェアアーキテクチャを可視化するための階層的アプローチです：

動的ビュー（シーケンス、デプロイ）は静的構造を補完し、実行時の動作とインフラストラクチャを示します。

パート2：段階的なワークフローガイド

ステップ1：AIチャットボットによるアイデア出し

目標：あいまいなアイデアを数秒で視覚的なプロトタイプに変換する。

ワークフロー:

1. AIチャットボットにアクセスVisual Paradigmワークスペース経由で、またはchat.visual-paradigm.com

2. 自然言語で AI にプロンプトを入力するシステムまたはシナリオを説明する:

   "ECM プラットフォーム用の C4 システムコンテキスト図を生成する"
   「マイクロサービス認証フローのシーケンス図を作成する」
   「フードデリバリーアプリのユースケース図を表示する」
   

3. 反復的にレビューして改善するフォローアップコマンドを使用する:

   • 「パスワードをリセットできる管理者アクターを追加する」

   • 「OTP 検証に失敗した場合、リトライループを挿入する（最大 3 回）」

   • 「並行メッセージを表示する：支払い成功後、顧客に通知し、在庫を同時に更新する」

4. パイプラインにエクスポート: エクスポートアイコンをクリック → 選択OpenDocs パイプラインに送信

5. メタデータを追加: バージョン識別のために「基本認証フロー草案 – 2026 年第 2 四半期」などの説明的コメントを含める

💡 プロのヒント: 初期段階の概念に対してチャットボットを使用して迅速に反復する。図が安定したら、セマンティック検証と自動同期のためにデスクトップに移行する。

C4 コンテキスト図の PlantUML 例

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

title システムコンテキスト図 - EC プラットフォーム

Person(customer, "顧客", "製品を閲覧・購入する買い物客")
Person(admin, "管理者", "製品、注文、ユーザーを管理する")

System(ecommerce, "EC プラットフォーム", "製品カタログ、ショッピングカート、注文、支払いを処理するオンライン小売システム")

System_Ext(payment, "決済ゲートウェイ", "クレジットカード決済を処理する")
System_Ext(inventory, "在庫システム", "在庫レベルと納品を管理する")
System_Ext(shipment, "配送サービス", "注文の配送と追跡を処理する")

Rel(customer, ecommerce, "製品を閲覧、検索、購入する")
Rel(admin, ecommerce, "製品、注文、ユーザーを管理する")
Rel(ecommerce, payment, "HTTPS を経由して支払いを処理する", "HTTPS")
Rel(ecommerce, inventory, "在庫を確認/更新する", "API")
Rel(ecommerce, shipment, "配送をリクエストする", "API")

@enduml

VPasCode で Plantuml を編集

シーケンス図の PlantUML 例

@startuml
title シーケンス図 - 2 要素認証付きユーザーログイン

actor "ユーザー" as user
participant "Web ブラウザ" as browser
participant "認証サービス" as auth
participant "SMS ゲートウェイ" as sms
database "ユーザーデータベース" as db

user -> browser: 認証情報を入力
activate browser
browser -> auth: 認証 (ユーザー名，パスワード)
activate auth
auth -> db: 認証情報を検証
activate db
db --> auth: 有効
deactivate db

alt 2FA 有効
    auth -> sms: OTP をリクエスト
    activate sms
    sms --> user: OTP を送信
    deactivate sms
    user -> auth: OTP を入力
    
    alt OTP 有効
        auth --> browser: 成功 + トークン
        browser --> user: ダッシュボードにリダイレクト
    else OTP 無効 (最大 3 回)
        auth --> browser: エラー (無効な OTP)
        browser --> user: エラーを表示
        note right: リトライループを実装
    end
else 2FA 無効
    auth --> browser: 成功 + トークン
    browser --> user: ダッシュボードにリダイレクト
end

deactivate auth
deactivate browser
@enduml

VPasCode で Plantuml を編集

ステップ 2: C4-PlantUML Studio による構造化された改善

目標: AIによって生成されたスケッチを、完全で規格準拠のC4モデルへと進化させます。

ワークフロー:

1. C4アーキテクチャガイドを起動するWebアプリメニューから

2. 問題文を定義する – AIアシストを使用して完全な説明を生成する:

   • プロジェクト名

   • システムの目的

   • 主要なユーザー

   • 主要な統合

3. 各C4レイヤーを段階的に生成する:

   • レベル1 – システムコンテキスト: システムの境界、外部ユーザー、および依存システムを入力する

   • レベル2 – コンテナ: デプロイ可能なアプリケーション、データベース、および外部サービスを構成する

   • レベル3 – コンポーネント: 内部コードモジュールとその相互作用を洗練させる

   • レベル4 – コード（オプション）: 実際のコード構造にマッピングする

4. 補完ビューを追加する:

   • ダイナミック/シーケンス図: ランタイムの相互作用を示す

   • デプロイメント図: ソフトウェアをインフラストラクチャにマッピングする

   • ランドスケープ図: システムをより広範な企業コンテキストで示す

5. ストリームからパイプラインへ：クリック ストリーム構造をパイプラインへ 階層モデルブロック全体をエクスポートする

🎯 使用例：多層の明確さが不可欠なアーキテクチャレビューボード、オンボーディングドキュメント、ステークホルダー向けプレゼンテーションに最適です。

C4 コンテナ図の例 (PlantUML)

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

title コンテナ図 - 倉庫管理システム

Person(staff, "倉庫スタッフ", "注文のピッキング、梱包、出荷")
Person(manager, "倉庫マネージャー", "オペレーションと分析を監督")
Person(logistics, "物流チーム", "入出庫荷役を管理")

System_Boundary(wms, "倉庫管理システム") {
    Container(webapp, "Web アプリケーション", "React", "倉庫スタッフ向けの UI を提供")
    Container(api, "REST API", "Spring Boot", "ビジネスロジックとオーケストレーションを処理")
    Container(storage, "ストレージ最適化サービス", "Spring Boot", "アイテムの配置と検索を管理")
    Container(analytics, "分析サービス", "Python", "レポートとインサイトを生成")
    ContainerDb(db, "在庫データベース", "PostgreSQL", "在庫、注文、場所を保存")
    ContainerDb(cache, "Redis キャッシュ", "Redis", "頻繁にアクセスされるデータをキャッシュ")
}

System_Ext(erp, "ERP システム", "財務と調達を管理")
System_Ext(oms, "注文管理システム", "注文ライフサイクルを処理")

Rel(staff, webapp, "使用")
Rel(manager, webapp, "使用")
Rel(logistics, webapp, "使用")

Rel(webapp, api, "呼び出し", "REST")
Rel(api, storage, "呼び出し", "gRPC")
Rel(api, analytics, "呼び出し", "REST")
Rel(api, db, "読み取り/書き込み", "JDBC")
Rel(api, cache, "読み取り/書き込み", "Redis プロトコル")

Rel(api, erp, "データを同期", "REST")
Rel(api, oms, "注文ステータスを更新", "REST")

@enduml

VPasCode で Plantuml を編集

コンポーネント図の例 (PlantUML)

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml

title コンポーネント図 - ストレージ最適化サービス

Container_Boundary(storage, "ストレージ最適化サービス") {
    Component(analysis, "ストレージ分析エンジン", "アイテムの移動パターンを分析し、配置を最適化")
    Component(size, "アイテムサイズ計算機", "配置のためのアイテムの寸法と重量を計算")
    Component(frequency, "アイテム頻度サービス", "アイテムの速度と人気を追跡")
    Component(replenishment, "補充サービス", "補充トリガーとアラートを管理")
    
    ComponentDb(location, "場所データベース", "アイテムの場所とストレージ容量を追跡")
}

System_Ext(api, "REST API (WMS)", "オペレーションのためにストレージサービスを呼び出し")

Rel(api, analysis, "配置最適化を要求")
Rel(analysis, size, "使用")
Rel(analysis, frequency, "使用")
Rel(analysis, location, "読み取り/書き込み")
Rel(size, location, "更新")
Rel(frequency, location, "更新")
Rel(replenishment, location, "読み取り/書き込み")

@enduml

VPasCode で Plantuml を編集

デプロイメント図の例 (PlantUML)

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Deployment.puml

title デプロイメント図 - 倉庫管理システム

Deployment_Node(aws, "AWS クラウド") {
    Deployment_Node(vpc, "VPC") {
        Deployment_Node(public_subnet, "パブリックサブネット") {
            Deployment_Node(lb, "ロードバランサー", "AWS ALB") {
                Container(webapp, "Web アプリケーション", "S3 にホストされた React アプリ")
            }
        }
        
        Deployment_Node(private_subnet, "プライベートサブネット") {
            Deployment_Node(backend_asg, "バックエンドオートスケーリンググループ") {
                Deployment_Node(backend_vm, "バックエンドサーバー VM", "EC2 - t3.large") {
                    Container(api, "REST API", "Spring Boot コンテナ")
                    Container(storage, "ストレージ最適化", "Spring Boot コンテナ")
                }
            }
            
            Deployment_Node(db_subnet, "データベースサブネット") {
                Deployment_Node(db_cluster, "データベースクラスター", "RDS PostgreSQL - db.r5.large") {
                    ContainerDb(master, "プライマリデータベース")
                    ContainerDb(standby, "スタンバイレプリカ")
                }
                
                Deployment_Node(cache_cluster, "キャッシュクラスター", "ElastiCache Redis - cache.r5.large") {
                    ContainerDb(cache, "Redis キャッシュ")
                }
            }
        }
    }
}

Rel(webapp, lb, "提供")
Rel(lb, api, "ルーティング", "HTTPS")
Rel(api, storage, "呼び出し", "gRPC")
Rel(api, master, "読み取り/書き込み", "JDBC")
Rel(api, cache, "読み取り/書き込み", "Redis プロトコル")
Rel(master, standby, "レプリケート")

@enduml

VPasCode で Plantuml を編集

ステップ 3：関係の洗練と強化

目標：初期の C4 モデルを、適切な関係を持つ正確で保守可能なアーキテクチャに変換します。

主要な関係パターン:

AI による提案された改善点:

• 共通性の抽出: 冗長な手順の特定 → «include» 関係の提案

• 条件付きロジックの分岐: 「if-then」シナリオの検出 → «extend» 関係の提案

• アクターの一般化: 重複する責任の発見 →階層構造の提案

• 複雑性の分解: 過度に大きなユースケースの特定 → サブ図への分割

重要な洞察: AI は矢印の描画やパターンの特定という機械的な作業を排除し、あなたのドメイン知識が関係性が実際のビジネスに合致していることを保証します。

改善された関係を含むユースケース図の例

@startuml
title 改善されたユースケース図 - GourmetReserve レストランアプリ

左から右の方向
actor "Diner" as diner
actor "Manager" as manager

rectangle "GourmetReserve システム" {
    usecase "Book a Table" as book
    usecase "Pre-order Meal" as preorder
    usecase "Cancel Reservation" as cancel
    usecase "Manage Reservations" as manage
    
    usecase "Authenticate User" as auth
    usecase "Process Payment" as payment
    usecase "Apply Discount Coupon" as discount
    usecase "Handle Waitlist" as waitlist
    
    ' Include relationships (mandatory)
    book ..> auth : <<include>>
    preorder ..> auth : <<include>>
    cancel ..> auth : <<include>>
    manage ..> auth : <<include>>
    
    book ..> payment : <<include>>
    preorder ..> payment : <<include>>
    
    ' Extend relationships (optional/conditional)
    book <.. discount : <<extend>>n(プロモコードを入力)
    book <.. waitlist : <<extend>>n(テーブル利用不可)
}

diner --> book
diner --> preorder
diner --> cancel
manager --> manage

@enduml

VPasCode で Plantuml を編集

ステップ 4: OpenDocs – 生きたドキュメントハブ

目標：ソースモデルが変更されると図が自動的に更新される、生きたドキュメントをコンパイルして公開します。

ワークフロー:

1. 技術マニュアルを開く OpenDocs ドキュメントエディタで

2. カーソルを配置 希望する挿入位置に

3. パイプラインアーティファクトを挿入:

   • ツールバー → 挿入 → パイプライン（左側のサイドバー）

   • 共有されたチームコレクションを閲覧

   • コメント、日付、またはソースプラットフォームでフィルタリング

4. インラインレンダリング：図は即座にフル解像度で表示され、インタラクティブな機能を備えています

5. 周囲のコンテキストを入力 ライブプレビュー付きの Markdown を使用して：

   • リッチテキスト編集

   • 表、コードブロック、階層フォルダ

   • 図は常にインタラクティブなままです

6. 更新を管理:

   • 浮動表示のリビジョンインジケーター (🔄)は、埋め込まれた図の隣に、より新しいパイプラインバージョンが存在する場合に表示されます

   • インジケーターをクリックすると、時系列のタイムスタンプ、コミットノート、およびソースプラットフォームを並べて表示できます

   • バージョンを切り替えて、マスタードキュメントを即座に更新

   • 過去のバージョンは監査証跡やロールバックシナリオのために引き続きアクセス可能です

💡 重要な概念: 画像が静止スナップショットとなる標準的なテキストプラットフォームとは異なり、OpenDocs の埋め込みビジュアルはライブベクターとして維持されます。ユーザーはドキュメント内の要素を直接クリックして、ソースモデルを開き、それを更新することができます。

OpenDocs コンテンツ構造の例

📁 プロジェクトドキュメンテーション
├── 📄 01 - エグゼクティブサマリー
│   └── [システムコンテキスト図付き AI 生成ステークホルダーサマリー]
├── 📄 02 - アーキテクチャ概要
│   ├── [C4 コンテキスト図 - ライブ]
│   ├── [C4 コンテナ図 - ライブ]
│   └── 技術スタックの決定
├── 📄 03 - 詳細設計
│   ├── [コンポーネント図 - ライブ]
│   ├── [シーケンス図 - ライブ]
│   └── API 仕様
├── 📄 04 - デプロイメントアーキテクチャ
│   ├── [デプロイメント図 - ライブ]
│   └── インフラストラクチャ要件
└── 📄 05 - 品質保証
    ├── [AI 生成器からのテストケース]
    └── カバレッジ指標

ステップ 5: 品質保証とテスト

目標: モデルから追跡可能なテストケースを自動的に生成します。

AI 生成テスト資産:

AI 生成テストケースの例:

TC-001 – ハッピーパス – 保証金不要
優先度: 高
事前条件: ダイナーログイン済み（ゴールド会員）、テーブル利用可能、非ピーク時間、人数 4 名
手順:
  1. テーブル検索 → スロット選択
  2. サマリー確認（保証金表示なし）
  3. 予約確認
期待される結果: 予約確定、確認メール送信、支払い画面なし
追跡: メインフローステップ 1–7、意思決定テーブルルール R1

TC-002 – 保証金必要 – 支払い失敗
優先度: 高
事前条件: 人数 10 名、ピーク時間、ゴールド会員ではない、有効なカードだが残高不足
手順:
  1. スロット選択 → 支払いへ進む
  2. カード入力 → 送信
期待される結果: エラーメッセージ「支払い拒否」、予約作成されず、スロット選択画面へ戻る
追跡: 意思決定テーブルルール R5、例外フロー 4b

ステップ 6: 同期と継続的な更新

目標: すべてのアーティファクトにわたって単一の真実の源を維持する。

クローズドループワークフロー:

双方向同期の利点:

• デスクトップでクラスを更新 → OpenDocs で自動的に更新される

• チャットボットでプロンプトを洗練 → 変更を Studios にプッシュ

• 単一アカウント同期

• バージョン履歴と完全なトレーサビリティ

• 手動のやり直しゼロ

パート 3：ガイドラインとベストプラクティス

1. AI チャットボットのベストプラクティス

効果的なプロンプト作成テクニック:

反復的洗練コマンド:

"OTP 検証が失敗した場合、リトライループを追加する（最大 3 回）"
"ユーザーが 2FA を有効にしている場合のみ、2 段階認証ステップを挿入する（opt フラグメントを使用）"
"並列メッセージを表示：支払い成功後、顧客に通知し、在庫を同時に更新する"
"PaymentGateway のライフラインを変更し、30 秒後にタイムアウトを表示する"
"OrderService に自己メッセージを追加し、PaymentGateway を呼び出す前に合計を計算する"

2. C4 モデリングのベストプラクティス

レイヤー固有のガイドライン:

一般的なC4の原則:

• 各レベルは、単に詳細を増やすだけでなく、異なる視点を提供すべきである

• 図は、最小限のテキストで自己完結し、説明不要であるべきである

• すべてのレベルで用語の一貫性を維持する

• 色分けを使用して、システムコンポーネントと外部コンポーネントを区別する

3. パイプラインのベストプラクティス

メタデータ管理:

バージョン管理:

• ドキュメントの差し替え前に改訂内容をレビューする

• 監査証跡のために過去のバージョンへのアクセスを維持する

• 改訂インジケーター（🔄）を使用して、古くなった図を特定する

• 可能であればバッチ更新を行い、ドキュメントの一貫性を保つ

4. OpenDocsのベストプラクティス

ドキュメント構造:

JIT（ジャストインタイム）埋め込みパス:

1. アドホック埋め込み: ドキュメントページ内で直接「挿入」>「図」をクリックする

2. AI駆動生成: テキストの叙述内に図を作成するために自然言語を使用する

3. 中央アセットパイプライン: デスクトップ/オンラインからパイプラインへプッシュし、ドキュメントへプルする

5. 品質保証のベストプラクティス

トレーサビリティ要件:

テストカバレッジ指標:

• プロジェクトダッシュボードを通じて完全性を監視する

• カバレッジを追跡する対象: ユースケース、意思決定表、シナリオ（ハッピーパス、代替案、例外、境界ケース）

• 残りのテストケースのリスクに基づく優先順位付け

6. 報告および文書化のベストプラクティス

AI生成レポート構造:

パート4：エンドツーエンドのワークフロー例

シナリオ：倉庫管理システムの構築

ステップ1：AIチャットボット – 着想

プロンプト：「ERPおよび注文管理と統合される倉庫管理システムのC4システムコンテキスト図を作成してください」

出力: ユーザー（倉庫スタッフ、マネージャー、物流）および外部システム（ERP、OMS）を示す初期のコンテキスト図。

ステップ2：C4-PlantUMLスタジオ – ガイド付きリファインメント

• AIアシストで問題文を定義する

• コンテナ図の生成：Webアプリ（React）、ストレージ最適化サービス（Spring Boot）、在庫データベース（PostgreSQL）

• コンポーネント図の生成：ストレージ分析エンジン、アイテムサイズ計算機、アイテム頻度サービス、補充サービス

• デプロイメント図の生成：EC2、RDS、ElastiCacheを備えたAWSアーキテクチャ

• 動的ビューの追加：在庫移動追跡用のシーケンス図

ステップ3：関係のリファインメント
AIが特定し、提案します：

• «include» → すべてのユースケースでユーザー認証を行う

• «include» → テーブル予約と事前注文の食事の支払い処理を行う

• «extend» → 割引クーポンを適用する（プロモーションコードの有無に依存）

• «extend» → ウェイトリストを処理する（テーブルの空き状況に依存）

ステップ4：OpenDocs – ライブドキュメンテーション

• すべてのパイプライン成果物をドキュメントページに挿入する

• 埋め込まれたライブ図を備えたMarkdown解説を書く

• ユースケースおよび意思決定テーブルから自動的に生成されたテストケースを追加する

• 安全な共有リンクを通じてステークホルダーポータルに公開する

ステップ5：同期

• 2週間後、エンジニアリングチームがストレージ最適化アルゴリズムを変更する

• アーキテクトがVP Desktopで図を編集する

• OpenDocsが同期変更を制作チームにフラグ付けする

• チームは手動フォーマットを崩すことなく、新しいリビジョンに切り替える

• すべての利害関係者が更新されたドキュメントを即座に確認できる

パート5：要約と主要なポイント

バリュー・プロポジション

Visual ParadigmのAIエコシステムは、断片的な「コンセプトからドキュメントへ」のワークフローを、視覚モデルとドキュメントが単一の真実源として一体的に進化する統合された自動化パイプラインへと変革します。

主要なメリット:

最終ワークフローの要約

クイックリファレンス：どのタスクにどのツールを

付録：PlantUMLコードスニペットクイックリファレンス

C4 コンテキスト

!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml
Person(user, "ユーザー", "説明")
System(system, "システム名", "説明")
System_Ext(external, "外部システム", "説明")
Rel(user, system, "使用する", "プロトコル")

VPasCodeでPlantumlを編集

C4 コンテナ

!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
Container(container, "コンテナ名", "技術", "説明")
ContainerDb(db, "データベース", "PostgreSQL", "データを保存")

VPasCodeでPlantumlを編集

C4 コンポーネント

!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml
Component(component, "コンポーネント名", "説明")

VPasCode で Plantuml を編集

C4 デプロイメント

!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Deployment.puml
Deployment_Node(node, "ノード名", "技術")

VPasCode で Plantuml を編集

シーケンス図

actor "アクター名" as actor
participant "参加者" as participant
actor -> participant: メッセージ
activate participant
participant --> actor: 返答
deactivate participant

VPasCode で Plantuml を編集

ユースケース図

actor "ユーザー" as user
usecase "ユースケース" as uc
user --> uc
uc ..> included : <<include>>
uc <.. extended : <<extend>>

VPasCode で Plantuml を編集

結論

Visual Paradigm の AI 搭載エコシステムは、技術チームが複雑性を管理する方法において画期的な前進を意味します。AI 駆動のアイデア出し、構造化された C4 モデリング、そして生きたドキュメントを単一のパイプラインに統合することで、設計とドキュメントの間の従来の摩擦を解消します。

新しいマイクロサービスアーキテクチャのブレインストーミングを行ったり、エンタープライズレベルのデプロイ戦略を洗練させたり、オンボーディングドキュメントが最新の状態を保つことを確認したりする場合でも、このワークフローにより、視覚モデルとテキスト説明が同期され、正確でアクセス可能に保たれます。迅速なアイデア出しには AI チャットボットから始め、構造化された洗練には C4-PlantUML Studio を使用し、変化するアーキテクチャと自動的に同期する生きたドキュメントを実現する OpenDocs でループを完了します。