📘 DFDのトップダウン分解の完全ガイド

DOT Edit DOT in VPasCode

digraph DFD {
    graph [rankdir = LR]
    node [shape = box, style = "filled", fillcolor = "#E1F5FE"]
    edge [color = "#555555", arrowsize = 0.8]
}

✅ 完了（レンダリング済み）：

DOT Edit DOT in VPasCode

digraph DFD {
    graph [rankdir = LR]
    node [style = "filled", fillcolor = "#E1F5FE", shape = box]
    Customer;
    // ...プロセス、データストア、境界、エッジなど
}

5. トップダウン分解プロセス（ステップバイステップ）

このオンライン注文プロセスシステムはその手法を示している。各レベルで完全で実行可能なGraphvizコードが得られる。

ステップ1 — コンテキスト図の作成（レベル0）

全体のシステムを1つのプロセスとして始め、外部世界とのすべての相互作用を特定する。データストアも内部の詳細も含めない。

DOT Edit DOT in VPasCode

digraph DFD {
    // --- グラフスタイルおよび図のタイトル ---
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.6
        ranksep = 0.9
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "オンライン注文処理システム - コンテキスト（レベル0）"
    ]
    node [ fontname = "Helvetica,Arial,sans-serif", fontsize = 11, penwidth = 1.5 ]
    edge [ fontname = "Helvetica,Arial,sans-serif", fontsize = 9,
           color = "#555555", arrowsize = 0.8 ]

    // 外部エンティティ
    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    Customer; PaymentGateway; Warehouse; Courier;

    // 単一のシステムプロセス
    node [shape = circle, style = "filled", fillcolor = "#E8F5E9",
          color = "#388E3C", fixedsize = true, width = 1.6]
    System [label="0.0nオンライン注文n処理システム"];

    // データフロー（双方向でデータがやり取りされる場合）
    Customer -> System [label="注文＆nアカウント"];
    System -> Customer [label="確認＆n領収書"];
    System -> PaymentGateway [label="支払いnリクエスト"];
    PaymentGateway -> System [label="支払いnステータス"];
    Warehouse -> System [label="在庫n確認"];
    System -> Courier [label="配送nリクエスト", dir=both];
}

解釈：コンテキスト図は次の問いに答えます「このシステムの境界はどこで、誰とやり取りしているのか？」それは外部エンティティとそのデータフローを示していますが、内部構造はすべて隠蔽しています。システムが外部エンティティを表示していますが、すべての内部構造は隠されています。システムがCustomerから注文を受け、PaymentGatewayを通じて請求を行い、Warehouseと照合して在庫を確認し、Courier.

ステップ2 — 以下の構成要素に分解するレベル1（主要プロセス）

単一のコンテキストプロセスを主要な機能に分解し、共有データストアを追加する。プロセスとストアを「」で囲む。破線で囲まれたラウンドシステム境界.

DOT

VPasCodeでDOTを編集する

DOT Edit DOT in VPasCode

digraph DFD {
    // --- グラフスタイルと図のタイトル ---
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.5
        ranksep = 0.8
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "オンライン注文プロセスシステム - レベル1"
    ]
    node [ fontname = "Helvetica,Arial,sans-serif", fontsize = 11, penwidth = 1.5 ]
    edge [ fontname = "Helvetica,Arial,sans-serif", fontsize = 9,
           color = "#555555", arrowsize = 0.8 ]

    // 外部エンティティ
    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    Customer; PaymentGateway; Warehouse; Courier;

    // --- システム境界コンテナ ---
    subgraph cluster_SystemBoundary {
        label = "オンライン注文プロセスシステム";
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        // プロセス（緑の円）
        node [shape = circle, style = "filled", fillcolor = "#E8F5E9",
              color = "#388E3C", fixedsize = true, width = 1.3]
        P1 [label="1.0n注文を提出"];
        P2 [label="2.0n支払いを処理"];
        P3 [label="3.0n在庫を確認"];
        P4 [label="4.0n注文を発送"];

        // データストア（黄色のレコード）
        node [shape = record, style = "filled", fillcolor = "#FFF9C4",
              color = "#FBC02D", fixedsize = false]
        OrderDS    [label="{ D1 | 注文 }"];
        ProductDS  [label="{ D2 | 商品n在庫 }"];
        ShippingDS [label="{ D3 | 発送 }"];
    }

    // --- データフロー：外部エンティティ ---
    Customer -> P1 [label="注文とnアカウント情報"];
    P1 -> Customer [label="注文n確認"];
    P2 -> PaymentGateway [label="支払いnリクエスト"];
    PaymentGateway -> P2 [label="支払いnステータス"];
    Warehouse -> P3 [label="在庫nあり"];
    Courier -> P4 [label="配送nステータス", dir=both];

    // --- プロセス間パイプライン ---
    P1 -> P2 [label="注文n合計"];
    P2 -> P3 [label="支払い済みn注文"];
    P3 -> P4 [label="検証済みn注文"];

    // --- プロセスとデータストアの間 ---
    P1 -> OrderDS [label="注文をn作成"];                     // 書き込み専用
    P3 -> ProductDS [label="在庫をn更新", dir=both];         // 読み取り・書き込み
    P4 -> ShippingDS [label="発送をn作成"];               // 書き込み専用
    OrderDS -> P3 [label="注文n詳細"];                    // 読み取り専用
    ShippingDS -> P4 [label="発送nラベル"];                // 読み取り専用
}

VPasCodeでDOTを編集する

解釈：

線形チェーン「P1 → P2 → P3 → P4」は、順序付きパイプライン注文は支払いの前、在庫確認の前、発送の前に行われることを示している。
そして決済ゲートウェイ 交換は二つの一方通行の矢印を使用する（支払いリクエスト 外部向け、 支払い状態 内部向け）。
データストア 状態として機能する： P1 書き込み 注文、 P3 読み取りおよび更新 在庫（dir=両方向), P4 書き込み 出荷。
P3 → ProductDS使用するdir=both— 一方のエッジ、二つではない — プロセスが在庫を読み取り、更新するためである。

ステップ3 — ドリルダウン：レベル2（一つのプロセスに焦点を当てる）

レベル1のプロセスを選択して分解するその一つだけ。表示する親プロセス境界（ピンク）に表示することで文脈を保持し、さらにサブプロセス、サブストア、フローを含める。

DOT

VPasCodeでDOTを編集する

DOT Edit DOT in VPasCode

digraph DFD {
    // --- グラフスタイルおよび図のタイトル ---
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.5
        ranksep = 0.8
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "支払いプロセス（レベル2）- オンライン注文プロセスシステム"
    ]
    node [ fontname = "Helvetica,Arial,sans-serif", fontsize = 11, penwidth = 1.5 ]
    edge [ fontname = "Helvetica,Arial,sans-serif", fontsize = 9,
           color = "#555555", arrowsize = 0.8 ]

    // 外部エンティティ
    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    Customer; PaymentGateway;

    // --- システム境界（このサブプロセス）---
    subgraph cluster_SystemBoundary {
        label = "2.0 支払いプロセス";
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        // サブプロセス（緑の円）
        node [shape = circle, style = "filled", fillcolor = "#E8F5E9",
              color = "#388E3C", fixedsize = true, width = 1.3]
        P21 [label="2.1n合計を計算"];
        P22 [label="2.2n支払いを検証"];
        P23 [label="2.3n支払いを承認"];
        P24 [label="2.4n注文を確認"];

        // サブデータストア（黄色のレコード）
        node [shape = record, style = "filled", fillcolor = "#FFF9C4",
              color = "#FBC02D", fixedsize = false]
        CartDS   [label="{ D1 | カート/n注文品目 }"];
        PromoDS  [label="{ D2 | キャンペーン }"];
        PaymentDS [label="{ D3 | 支払いn取引 }"];
        OrderDS  [label="{ D4 | 注文 }"];

        // 親プロセス（ピンク） - 上位レベルからの文脈
        node [shape = circle, style = "filled", fillcolor = "#FCE4EC",
              color = "#C2185B", fixedsize = true, width = 1.4]
        P1 [label="1.0n注文を確定n（親）"];
        P3 [label="3.0n在庫を確認n（親）"];
    }

    // 親プロセス／顧客からのフロー（サブプロセスへ）
    P1 -> P21 [label="注文n品目"];
    P1 -> P22 [label="支払いn方法"];
    Customer -> P22 [label="支払いn詳細"];

    // サブプロセスの連鎖
    P21 -> P22 [label="合計とn割引"];
    P22 -> P23 [label="検証済みn支払い"];
    P23 -> P24 [label="承認済みn支払い"];

    // 外部ゲートウェイとの連携
    P23 -> PaymentGateway [label="承認nリクエスト"];
    PaymentGateway -> P23 [label="承認／n却下"];

    // 親プロセス／顧客への出力
    P24 -> P3 [label="支払い済みn注文"];
    P24 -> Customer [label="支払いn領収書"];

    // データストアへのアクセス
    P21 -> CartDS [label="品目をn読み取り", dir=both];
    P22 -> PromoDS [label="キャンペーンをn検証"];
    P23 -> PaymentDS [label="取引をn記録", dir=both];
    P24 -> OrderDS [label="ステータスをn更新"];
}

VPasCodeでDOTを編集する

解釈（vs. レベル1):

2.1 合計金額の計算は純粋な計算 — カート内の商品を読み取り、金額を算出する。ストア以外の外部I/Oは一切ない。
2.3 支払いの承認は唯一外部とのやり取りを行う唯一のステップ決済ゲートウェイ — 資金の移動が明確に分離されている。
この注文ストアが再び現れるのは、2.4注文ステータスを更新する（当初は1.0レベル1で作成された）。
このチェーン2.1 → 2.2 → 2.3 → 2.4は順次検証パイプラインを3.0（ピンクの親プロセス）。
親プロセス 1.0 および 3.0はピンクで描かれる外側境界線の外側にあり、フローの発生点と終了点を固定する。

ステップ 4 — 再び詳細を確認する：レベル-3（再帰的に繰り返す）

まだ複雑すぎる任意のサブプロセスに対して、同じ手法を繰り返す。我々は2.2 支払いの検証.

DOT Edit DOT in VPasCode

digraph DFD {
    // --- グラフスタイルおよび図のタイトル ---
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.5
        ranksep = 0.8
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "支払いの検証（レベル-3）- オンライン注文プロセスシステム"
    ]
    node [ fontname = "Helvetica,Arial,sans-serif", fontsize = 11, penwidth = 1.5 ]
    edge [ fontname = "Helvetica,Arial,sans-serif", fontsize = 9,
           color = "#555555", arrowsize = 0.8 ]

    // 外部エンティティ
    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    カスタマー;

    // --- システム境界（このリーフレベルのサブプロセス）---
    subgraph cluster_SystemBoundary {
        label = "2.2 支払いの検証";
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        // リーフプロセス（緑の円）
        node [shape = circle, style = "filled", fillcolor = "#E8F5E9",
              color = "#388E3C", fixedsize = true, width = 1.3]
        P221 [label="2.2.1n確認nカード/支払いn詳細"];
        P222 [label="2.2.2n不正nチェック"];
        P223 [label="2.2.3nプロモーションnコードの検証"];
        P224 [label="2.2.4n最終n金額の計算"];

        // リーフデータストア（黄色のレコード）
        node [shape = record, style = "filled", fillcolor = "#FFF9C4",
              color = "#FBC02D", fixedsize = false]
        CardDS  [label="{ D1 | カードnレジストリ }"];
        FraudDS [label="{ D2 | 不正nルール }"];
        PromoDS [label="{ D3 | プロモーション }"];
        CartDS  [label="{ D4 | カート/n注文アイテム }"];

        // 親プロセス（ピンク）
        node [shape = circle, style = "filled", fillcolor = "#FCE4EC",
              color = "#C2185B", fixedsize = true, width = 1.4]
        P21 [label="2.1n合計金額のn計算n（親）"];
        P23 [label="2.3n支払いのn承認n（親）"];
    }

    // 入力
    P21 -> P221 [label="合計金額 &n日付"];
    カスタマー -> P221 [label="支払いn詳細"];

    // 順次検証、並列分岐あり
    P221 -> P222 [label="確認済みn詳細"];
    P222 -> P223 [label="不正フラグなしn（並列）"];

    // 最終計算への入力
    P21 -> P223 [label="プロモーションnコード"];
    P221 -> P224 [label="支払いn合計"];
    P223 -> P224 [label="割引n適用済"];

    // 親への出力
    P224 -> P23 [label="検証済み &n割引済みn合計"];

    // データストアへのアクセス
    P221 -> CardDS [label="カードn確認"];
    P222 -> FraudDS [label="ルールnチェック"];
    P223 -> PromoDS [label="照会n＆適用"];
    P224 -> CartDS [label="アイテムn読み取り", dir=both];
}

解釈：

2.2.1 カードの検証はゲート— これは不正検査が開始される前に成功しなければならない。
2.2.2 (不正)かつ2.2.3 (プロモーション)は並列：両方ともルールを読み込み、最終計算にデータを供給する。「(並列)」ラベルがこれを示している。
2.2.4 最終金額の計算はファンインポイント—それは結合する 支払い合計 + 割引親に送出される検証済み出力へと統合する2.3.
カード登録および不正規則はレベル2では見えない詳細レベルのストアであり、分解を進めるにつれて自然に新しいストアが現れる。

ステップ5 — プロセスが「原始的」になったら停止する

各プロセスがを記述するまで分解を続ける単一で明確かつ実装可能なアクション深さに固定はない。プロセスが1つの関数または1つの意思決定に明確に対応する時点で停止する。上記のレベル2.2.1～2.2.4はすでに原始的である。

6. 最良の実践法とよくある落とし穴

✅ 最良の実践法

プロセスを階層的に番号付けする (2.2.4) これにより、どの図もツリー内で自己位置特定可能になる。
親プロセスを境界に描く（ピンク）これにより、フローが文脈を保持する — 入出力を孤立させない。
1つの双方向エッジを使用する (dir=both) を、2つの別々の矢印ではなく双方向のやり取りに使用する。ごちゃごちゃを減らす。
ラベルは説明的だが、簡潔に保つ（「支払い承認」、ではなく「AP」）
一度に1つのプロセスを分解する— 各レベルは独自の図である。複数のレベルを1つの図に詰め込まない。
図のバランスを取る— 親レベルの入力/出力は、子要素の入力/出力の合計と等しくなければならない（バランスルール）。
常に要素を宣言する— 要素を宣言しないスタイル専用のテンプレートは、空のキャンバスを描画する。すべてのDFDは必須である。スタイルを適用し、次に宣言し、最後に接続する.
データストアの名前は一意に子図の中で、しかし自己完結性のためにローカルに再番号付け（D1、D2…）する。

❌ 一般的な落とし穴

孤立したプロセス— 入力も出力もないプロセス。すべてのプロセスは何かを変換する。
バランスの欠如 — レベル1にフローが現れるが、そのレベル2の子供のいずれもそれが生成／消費していない。
過度な詳細 — レベル0のコンテキスト図でデータストアを公開している（それらは下位レベルでのみ適切）。
制御フローの思考 — DFDにループや判断記号を含めている；それはフローチャートに残すように。DFDはデータを示すものであり、順序ではない。
二つの平行な矢印 一つであるべきものを dir=both エッジ — 重複線の混雑を引き起こす。
間違ったストアアクセス方向 — ストアをとしてラベル付けしている読み取り専用 実際には書き込みが行われている（またはその逆）場合。
スタイルテンプレートを図と誤認している — ノードとエッジを宣言することを忘れるとうまくいかず、空白のグラフになる。

7. 上位から下位への検証チェックリスト

図を提示する前に、次を確認する：

✅ すべてのプロセスに1つ以上の入力と1つ以上の出力がある。
✅ すべてのフローのラベルは名詞（「注文の詳細」）、動詞ではない。
✅ すべてのデータストアは読み込まれるおよび ある時点で書き込まれる（明確に外部参照データである場合を除く）。
✅ レベルの境界バランス：子は親が交換した内容を正確に消費および生産する。
✅ 外部エンティティは境界の端にのみ現れ、境界内部には決して現れない。
✅ dir=both は双方向の交換に使用される；それ以外は片方向の矢印。
✅ ピンク色の親プロセス参照は、分解されているレベルを正しく示している。
✅ コードは実際のノード、エッジ、境界を宣言している——単なるスタイルルールではない。

8. 上位から下位への分解プロセスの要約

上位から下位へのDFD分解は、抽象から詳細へ:

コンテキスト（L0） — 1つのボックス、すべての境界および外部エンティティ。
システム（L1） — 主要なプロセス、ストア、およびデータパイプライン。
サブダイアグラム（L2、L3…） — 一度に一つのプロセスに再帰的にズームインし、親コンテキストを可視化したまま、ローカルストアを番号付けする。

各レベルは異なる質問に答えます： L0は「システムのフットプリントは何か？」と尋ね、L1は「主要なデータフローは何か？」と尋ね、L2以降は「このデータはどのように正確に変換されるか？」と尋ねる。

その オンライン注文プロセス 例は、完全なチェーンを 完全で実行可能なGraphvizコード — 4エンティティの コンテキストダイアグラム、4ステップの 検証ルーチン (2.2.1 → 2.2.4）。 番号の根元を整理することにより, フローのバランスを取ることにより、一貫性のある 色の凡例（青いボックス、緑の円、黄色のレコード、ピンクの親参照、破線のグレー境界）、そして常にすべてのノード／エッジを明示的に宣言する、どんなに大きなシステムでもナビゲート可能で曖昧さがなくなります——そしてすべての図が実際に描画されます。

9. ツール：Visual Paradigm AIを用いたDFDのトップダウン分解

Visual Paradigm AIは、AIチャットボットをモデリングツール内に直接搭載。すべてのレベルを手で描くのではなく、会話形式で全体の分解を進め、その後結果を微調整できます。このガイドで紹介するアプローチを実際に使う方法を以下に示します。

9.1 DFD作業のコア機能

このVP AIチャットボットはテキストとコードのアシスタント対話形式で一緒に作業できるアシスタントです。DFDのトップダウン分解において、以下のことができます：

機能	あなたにできる事
図のコードを生成	指定されたプロセスの説明に対して、Graphviz（DOT）を生成する——1レベルずつ
添付された画像を分析	アップロードした手書きまたは既存のDFD画像を読み取り、構造化されたモデルに変換する
段階的に改善する	フィードバック（「2.2にズームする」、「失敗の分岐を追加する」など）をもとに図を再生成する
解釈を説明する	各エンティティ、プロセス、ストア、フローの意味を順に説明する
構文を検証する	レンダリングする前にDOTが構造的に健全であるか確認する
戦略／チャート出力を行う	DFDを補完するための支援チャートやフレームワーク（例：スイムレーン、組織構造）を生成する

📌 注記： Visual Paradigmはさまざまな図式記法をサポートしています。スタート／エンドイベント、ゲートウェイ、スイムレーンを必要とするビジネスプロセスモデリングには BPMN を推奨します。一方、このガイドで示すように厳密なデータフローモデリングには GraphvizベースのDFD を使用してください。

9.2 実例対話 — オンライン注文プロセスの分解

ここでは、私たちが歩いたステップを反映した現実的なチャットセッションを示します。各プロンプトが1段階深くズームしていることに注目してください。まさにトップダウンアプローチです。

プロンプト1 — コンテキスト図の作成：

「オンライン注文プロセスシステムのコンテキスト図（レベル0）を作成する。外部エンティティ：顧客、決済ゲートウェイ、倉庫、配達業者。」

VP AIが応答するレベル0のDFDを提示する——中心となる1つのプロセス、4つの外部エンティティ、およびそれらのフロー——を図に配置する。

プロンプト2 — 詳細度を追加する：

「今、これをレベル1のDFDに分解してください。プロセスとして：1.0 注文の作成、2.0 支払い処理、3.0 在庫確認、4.0 注文の出荷。注文、製品在庫、出荷のデータストアを追加してください。」

VP AIが返すプロセスが順次連結されたレベル1の図、ストアが接続され、外部エンティティのフローが保持されたもの——ガイドのステップ2で見たパイプライン。

プロンプト3 — 1つのプロセスにズームインする：

「2.0 支払い処理にズームインしてください。2.1 合計金額の計算、2.2 支払いの検証、2.3 支払いの承認、2.4 注文の確認を含むレベル2のサブ図を作成してください。1.0と3.0は親参照として保持してください。」

VP AIが生成するレベル2のサブ図：サブプロセス、ローカルストア（D1–D4）、決済ゲートウェイとのやり取り、1.0と3.0のピンク色の親参照——ステップ3と一致する。

プロンプト4 — もう一度詳細に掘り下げる：

「2.2 支払いの検証をレベル3の図として掘り下げる：2.2.1 カードの確認、2.2.2 フェイク検出の確認、2.2.3 プロモーションの検証、2.2.4 最終金額の計算。カード登録、フェイクルール、プロモーション、カートアイテムのストアを追加してください。」

VP AIが生成するファンイン計算（2.2.4）と並列のフェイク/プロモーションの分岐を備えたレベル3のリーフ図——まさにステップ4と一致する。

プロンプト5 — 異常処理を追加する：

「失敗パスを追加する：もし2.2.2 フェイク検出が取引を警告した場合、顧客に戻るキャンセル通知プロセスにルーティングする。」

VP AIが最適化する拒否分岐を図に追加し、フローを自動的に再調整する。

9.3 効果的なプロンプトパターン

信頼性が高く、メソドロジーに沿った結果を得るためにこれらのパターンを使用する：

目的	例のプロンプト
1レベルさらに詳細に分解する	“ズームインして 3.0 在庫確認をレベル2のサブダイアグラムとして。”
番号を指定する	“番号付きのプロセスを使用して 2.1, 2.2, 2.3.”
親コンテキストを保持する	“保持して 1.0 と 3.0 を境界上の親参照として。”
データストアを追加	「ストアを含める：D1 カートアイテム, D2 プロモーション.”
双方向のフローを表示	「使用する：dir=bothプロセス↔ストアの読み取りおよび書き込みに使用。」
レベルをバランスさせる	「入力と出力が親レベルと一致していることを確認してください。」
失敗パスを追加	「例外が発生した場合に、例外ブランチを追加する：支払いが拒否されたとき.”
深さを制限する	「基本的なプロセスまでで停止する——単一で実装可能なアクションまで。」

9.4 分析用画像のアップロード

手書きまたはレガシーデータフローダイアグラムをお持ちで、デジタル化したい場合：

画像を添付してくださいチャットに添付してください（スクリーンショット、写真、または既存のDFDのエクスポート）。
尋ねる：「このDFD画像を分析して、編集可能な構造化モデルに変換してください。」
VP AIが画像を検査します（形状、ラベル、矢印を読み取り）エンティティ、プロセス、ストア、フローを編集可能な図として再構成します。

📌 AIは画像のコンテンツ— 四角形、円、レコード、およびそれらのラベル — を適切な記法で再現します。これは、ざっくりとしたスケッチから、きれいな階層構造のモデルへと素早く移行する方法であり、その後さらに分解できます。

9.5 アーティファクトワークフローによる反復

VP AIは、生成された各図を アーティファクトとして保存し、精緻化中に参照できます：

「レベル2のアーティファクトを精緻化して、不正拒否の分岐を追加する。」— 既に生成された特定の図を対象とし特定の既に生成された図再生成するのではなく。
「コンテキスト図を再生成するが、倉庫エンティティを除外する。」— スコープが変更されたときにアーティファクトを置き換えます。
「バランスを調整するために、レベル2とレベル3のアーティファクトを比較してください。」— 親子のフロー整合性を確認する。

アーティファクトが会話の状態を保持しているため、以前の意思決定を失うことなく、段階的に精緻化を重ねていくことができます。これがトップダウン分解の本質です。

9.6 推奨されるワークフローチェックリスト

段階	アクション
1. スキャフォールディング	まず、コンテキスト図（レベル0）のプロンプトを提示する。
2. レベル1を設定する	ストアと境界を含む主要プロセスの分解を求める。
3. 詳細化する	一度に一つのプロセスに注目する。親の参照を維持する。
4. 精緻化する	例外パス、バランス調整、ストアの修正を要求する。
5. 検証する	AIにDOT構文を確認してもらう；セクション7のチェックリストを確認する。
6. ドキュメント	各レベルに併記する解釈ナラティブを要求する。

9.7 例の出力 — VP AIにレベル1のコード生成を依頼する

チャットボットからの典型的な応答は、ステップ2の分解は、以前に見た完全で実行可能なDOT:

DOT

VPasCodeでDOTを編集する

DOT Edit DOT in VPasCode

digraph DFD {
    graph [
        rankdir = LR, splines = true, overlap = false,
        nodesep = 0.5, ranksep = 0.8,
        fontname = "Helvetica,Arial,sans-serif", fontsize = 12,
        label = "オンライン注文プロセスシステム - レベル1"
    ]
    node [ fontname = "Helvetica,Arial,sans-serif", fontsize = 11, penwidth = 1.5 ]
    edge [ fontname = "Helvetica,Arial,sans-serif", fontsize = 9,
           color = "#555555", arrowsize = 0.8 ]

    // 外部エンティティ
    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    Customer; PaymentGateway; Warehouse; Courier;

    subgraph cluster_SystemBoundary {
        label = "オンライン注文プロセスシステム";
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        node [shape = circle, style = "filled", fillcolor = "#E8F5E9",
              color = "#388E3C", fixedsize = true, width = 1.3]
        P1 [label="1.0n注文n作成"];
        P2 [label="2.0n支払いn処理"];
        P3 [label="3.0n在庫n確認"];
        P4 [label="4.0n注文n発送"];

        node [shape = record, style = "filled", fillcolor = "#FFF9C4",
              color = "#FBC02D", fixedsize = false]
        OrderDS    [label="{ D1 | 注文 }"];
        ProductDS  [label="{ D2 | 商品n在庫 }"];
        ShippingDS [label="{ D3 | 発送 }"];
    }

    // フロー
    Customer -> P1 [label="注文＆nアカウント情報"];
    P1 -> Customer [label="注文n確認"];
    P2 -> PaymentGateway [label="支払いnリクエスト"];
    PaymentGateway -> P2 [label="支払いnステータス"];
    Warehouse -> P3 [label="在庫n確認"];
    Courier -> P4 [label="配送nステータス", dir=both];

    P1 -> P2 [label="注文n合計"];
    P2 -> P3 [label="支払い済みn注文"];
    P3 -> P4 [label="検証済みn注文"];

    P1 -> OrderDS [label="注文n作成"];
    P3 -> ProductDS [label="在庫n更新", dir=both];
    P4 -> ShippingDS [label="発送n作成"];
    OrderDS -> P3 [label="注文n詳細"];
    ShippingDS -> P4 [label="発送nラベル"];
}