
図が重要な理由
- コードベースのフロー制御を理解したいとき
- 入力から出力までのデータリネージを追跡する必要があるとき
- 他のメンバーのオンボーディングやシステムのドキュメント化をするとき
検討すべき2つの側面
- 目的: マッピングするのはロジック、データフロー、インフラ、それとも別のもの?
- 形式: さっと作れるもの(Mermaidのダイアグラムなど)にする? それともフォーマルなもの(UMLなど)にする?
プロンプトの作り方
- フロー: 「リクエストがコントローラからデータベースまでどう流れるか見せて」
- データリネージ: 「この変数がどこで入って最終的にどこに行くか追って」
- 構造: 「このサービスのコンポーネントレベルのビューを見せて」
Mermaid を使う
- ロジックや処理の流れには
flowchart
- やり取りには
sequenceDiagram
- オブジェクト構造には
classDiagram
- シンプルな有向グラフには
graph TD
- Extensions タブを開く
- Mermaid を検索
- インストール

ダイアグラム戦略
- 関数・ルート・プロセスのどれかを1つ選ぶ
- その部分をMermaidで図解するようにCursorに頼む
- いくつかできたら、まとめて統合してもらう
推奨フロー
- 詳細な低レベルのダイアグラムから始める
- それを中レベルのビューに要約する
- 望む抽象度に達するまで繰り返す
- 最後に、単一のダイアグラムやシステムマップにまとめるようにCursorに頼む
重要なポイント
- フロー、ロジック、データを理解するために図を使う
- 小さなプロンプトから始めて、そこから図を広げていく
- Cursor では Mermaid が最も扱いやすいフォーマット
- C4 モデルと同様に、低レイヤーから始めて上位へ抽象化していく
- Cursor なら図の生成・ブラッシュアップ・統合までスムーズにできる