【Power Apps】データフロー図・ロジックフロー図を生成AI(Claude)で作成

添付した2つのyamlファイルをソースに、時間をかけてよいので網羅的かつ完璧なデータフロー図をMermaidで作成してください。
 作成においては、以下を順守にすること。

■ルール
・適切な文字・オブジェクトの色分けを行い視覚的に優れた図であること
・線が交差しすぎないようにオブジェクトの配置を工夫すること
・プロセスの名称は日本語であること

■DFD（データフロー図）とは
「DFD（データフロー図）」とは、システムにおけるデータの流れを表した図のことです。データの流れを書くことでシステムの機能を洗い出します。
コンピュータ上のシステムの設計に使えるのはもちろん、業務フロー分析にも使うことができます。視覚的にシステムをとらえることができることからシステム構築を行うSEと構築を依頼した顧客が、お互いの認識合わせにこの図を使うことにも有効です。
■DFD（データフロー図）で使う記号
DFDで使う記号は、「データフロー」「プロセス」「データストア」「源泉と吸収」の4つです。DFDには提唱者ごとに記号の表現方法が異なります。今回はデマルコ式を採用してください。
・データフロー
データフローは、データの流れを表す矢印です。プロセス、データストア、源泉と吸収の要素間のデータの流れを表します。矢印には必ず名前をつける必要があります。
・プロセス
プロセスはデータの加工を行うものです。デマルコ式では円で、ゲイン・サーソン式では角の丸い長方形で描きます。
プロセスは記号の内側に名前を記載します。見る人が概要をすぐに理解できるような名前がいいです。また、DFDではプロセス個別の番号をつけます。DFDを階層で記載したときに、プロセスの番号から階層ごとの図の関係性がわかるようになります。
・データストア
データストアは一時的なデータの保管場所です。データストアの例として、ファイルやデータベースなどがあります。デマルコ式では二重線で表現します。
データストアに名前をつける際は、見た人がすぐに理解できるものにするといいです。ほかのシステムのデータベース名と名前が被ると将来問題が起きるのではないかという不安から、一意性のある通し番号を名前にしようという考えもあるかと思います。
しかし、DFDの「直感的でわかりやすい」というメリットを失う恐れがあるので理解しやすい名前にすることがいいとされています。
・源泉と吸収
源泉と吸収は、対象システムの外側の人や組織のことです。データをシステムに渡してくるもの（源泉）、データをシステムから受け取るもの（吸収）を表します。デマルコ式では名前をつけた長方形で表現します。
源泉と吸収は、対象システムとデータをやり取りする外部要因なので内容について書く必要はありません。注目する必要があるのは対象システムに入ってくるデータです。源泉と吸収についてはシステムへの理解を深めるために記載しているものと考えるといいです。
■DFDのルール
DFDの書き方にはいくつかのルールがあります。以下がそのルールです。
・プロセスには入力と出力のデータフローがどちらも必要
プロセスは入力したデータを加工して出力するものです。ですので、必ずデータの入力と出力が少なくともひとつずつ必要になります。入力はひとつで出力は複数あるという場合もありますし、逆に入力が複数で出力はひとつという場合もあります。
・データストアには入力と出力のデータフローがどちらも必要
データは使わなければ保存する意味がないため、データストアには入力と出力のデータフローがどちらも必要になります。
・データフローにはすべてに名前をつける
DFDは「どんなデータ」をやり取りするのか表す図なので、すべてのデータフローに「どんなデータ」かという名前をつける必要があります。名前がつけにくいデータフローはデータのまとまりとしてはいまいちであることが多いです。その場合はデータフローを分割するか、分割できない場合はデータフロー自体を削除することも検討します。
・データフローに処理を書き込まない
データフローに「〇〇する」といった処理を書いてしまうことがあります。これは処理の流れを表す図である「フローチャート」の書き方が混ざっている可能性があります。
DFDは処理の流れについては書かず、データの流れのみを書く図です。「〇〇する」という動詞が名前になっているデータフローは誤りですので検討し直しましょう。
プロセスには、入力データと出力データの処理の内容がイメージできる名前をつける
プロセスには入力データと出力データが必ずひとつ以上あるので、プロセスに名前をつける場合は、入力データと出力データのどちらもイメージできるような名前にすると、見た人が直感的にシステムをイメージしやすくなってわかりやすい図になります。
・処理の実行順序について書かない
DFDは「どこ」と「どこ」がデータをやり取りするのか明確にするための図なので、「いつ」データをやり取りするのかについては言及しません。処理の実行順序について描きたい場合は、フローチャートやシーケンス図など処理の流れを表現する図を別に作ることをおすすめします。
・DFDのレイヤーとコンテキストダイアグラム
DFDを書くときは、構築するシステムをひとつの大きなプロセスとして、外部システムや操作者とどんなデータをやり取りをするかを記載するところから始めます。このシステムの全体を捉えた最上層のDFDを「コンテキストダイアグラム」といいます。
このコンテキストダイアグラムをより詳細にするため、段階的に下層のDFDを作成していきます。下層のDFDは上位のDFDのプロセスごとにひとつ作成されます。
このとき、ひとつのレイヤー（層）ごとにプロセスは7個以下に抑えて記載すると良いです。数を絞ることでDFDが見づらくならず、見るとすぐ直感的に理解できる図になります。
また、レイヤー分けをする場合、0、1、2といった番号をプロセスに割り振ります。下層のDFDは上層の番号を継承し、0.1、0.2といった番号を記載しておくと、上位と下位といったレイヤーの関係性がわかりやすくなります。

添付した2つのyamlファイルをソースに、時間をかけてよいので網羅的かつ完璧なロジックフロー図をMermaidで作成してください。 作成においては、以下を順守にすること。
■ルール
・適切な文字・オブジェクトの色分けを行い視覚的に優れた図であること
・線が交差しすぎないようにオブジェクトの配置を工夫すること
・プロセスの名称は日本語であること
・Mermaidの最新バージョンの構文を使用すること（flowchart の使用）。
・クラス定義とスタイル適用が複雑すぎる場合は、基本的な構造を優先すること。
・ノードの形状指定が必要ない場合は省略可能であること。
・複雑な接続表現（& を使用した複数ノードの接続など）がエラーの原因となる可能性があるため、必要に応じて単純化すること。
・サブグラフの表現方法が正しいことを確認すること。
・Mermaidの構文エラーが発生した場合、段階的に簡略化して問題を特定する方法を提案すること。
・可能な限り内容を保持しつつ、Mermaidの制約内で表現する方法を考えること。