Domain Canvas Skill：画面・業務概念・ER図を一つのモデルでつなぐ

更新の起点を一つにする

Domain Canvas Skillは、プロジェクトのコードや仕様を調べ、画面・業務オブジェクト・データ構造をmodel.jsonに整理し、そのモデルから閲覧用のHTMLを生成するための手順とPythonスクリプトをまとめたものです。単独のホスティングサービスではなく、Claude Codeで利用するプロジェクト内のスキルとして配布されています。

中心になるのは、画面、概念モデル、ER図を別々に保守せず、同じmodel.jsonを表示の元にする設計です。モデルを変更してHTMLを再生成すると、それぞれの表示が同じ更新済みデータを読みます。画面側の対応はbindings、概念やデータの関係はrelationshipsで表すため、関連する記述の整合確認は必要です。

概要と配布方法（README）

同じ対象を三つの問いで読む

ここでのドメインとは、顧客、申込、契約など、業務で意味を持つ対象とそのルールです。ER図は、それらに対応するデータの属性や関係を表します。ビューを切り替えると、同じ対象について確認する粒度が変わります。

Designビューは完成したUIを自動設計する機能ではありません。画面画像やローカルHTMLの試作があれば参照でき、なければ仮のプレビューを表示します。概念ビューには説明と関係、ERビューには属性やキーが出ます。現行のER表示では、業務上の関係だけを表すkind: domainの線は除外されます。

生成コード：表示と検証の実装

不動産CRMの例で、対応関係を追う

付属モデルには「顧客・物件・申込・契約・書類」の5オブジェクトと、「契約詳細・申込詳細・顧客詳細」の3画面、5つの関係が入っています。契約詳細画面は、契約を主対象、顧客と物件を文脈情報、書類を関連一覧として参照します。一画面と一テーブルを一対一で対応させるのではなく、画面の役割に沿って複数の対象を結びます。

たとえば契約詳細に「不足書類」を表示する変更を考えるなら、まずDesignで書類との対応を確認し、Conceptで契約と書類の意味を読み、ERでdocument.contract_idなどの属性を見る、という順で検討できます。この変更例は記事上の利用例であり、付属デモが不足書類を判定するわけではありません。

デモでは上部のDesign / Concept / ERで切り替え、ドラッグで移動、ホイールや＋・−で拡大縮小し、Fitで全体表示に戻せます。サンプルの画面部分は実アプリのスクリーンショットではなく仮表示です。

不動産CRMのサンプルモデル

確認済みの関係と推論を分ける

AIに整理を任せるときに重要なのは、もっともらしい線を増やすことより、その線を引く根拠を残すことです。スキルは、テーブルや外部キーならスキーマ・マイグレーション・ORM、業務上の意味なら仕様書、画面の存在ならルーターやコンポーネントなど、主張ごとに適切な資料を使うよう指示しています。

関係にはconfirmed（確認済み）とinferred（推論）を区別するconfidenceを持たせ、概念・ERビューでは推論の関係を破線で表示します。画面上で一緒に見えるだけでデータベースの関係を確定しない、というルールも明記されています。

ただし、confirmedという値自体はモデルに記入された判断です。生成スクリプトが根拠の内容を読んで正しさを証明するわけではありません。参照元と未解決の仮定は、生成物に添えるREADMEで確認できるようにします。

抽出と根拠のルール

導入して、小さな範囲から更新する

公開デモの閲覧にはインストール不要です。自分のプロジェクトでモデルを作る場合は、リポジトリ内の.claude/skills/domain-canvas/を、対象プロジェクトの同じ場所へコピーします。Claude Codeで次のように呼び出せます。

/domain-canvas contracts

contractsは対象範囲の指定例です。「契約まわりの画面・概念モデル・ER図を同じキャンバスにまとめて」と自然文で依頼する例もREADMEにあります。最初は契約詳細など、一つの機能に範囲を絞ると、資料と図を照合しやすくなります。

.domain-canvas/model.json

モデルの正本。変更はここに反映する。

.domain-canvas/index.html

モデルから生成される閲覧用キャンバス。

.domain-canvas/README.md

参照資料、未解決の仮定、更新コマンドの記録。

python .claude/skills/domain-canvas/scripts/generate_canvas.py \
  --model .domain-canvas/model.json \
  --out .domain-canvas/index.html

同梱の生成スクリプトは外部Pythonパッケージに依存しません。Python 3を用意し、上のコマンドでHTMLを再生成してブラウザで開きます。付属サンプルを試すときは入力をexample/model.json、出力をexample/index.htmlに置き換えます。

運用では、コードや仕様の変更をモデルへ反映し、再生成してレビューする工程を変更作業に含めます。生成HTMLを直接直すと次の生成で消えるため、モデル側を更新します。共有時はHTMLにモデルが埋め込まれることを踏まえ、内部構造や参照画像を渡してよい相手か確認してください。

スキル定義：導入後の作業手順

図の一致と、業務の正しさは別に確かめる

現行の生成スクリプトは必須のルート項目、エンティティ・画面IDの重複、関係の接続先、画面の参照先などを検査します。一方で、データベースの全制約や業務ルールとの一致まで自動検証するものではありません。

実際、付属例のdocument.contract_idはnullable: trueですが、契約と書類の関係には契約側の多重度1が記述されています。書類が契約に未紐付けでも存在できるのか、図が契約済みの書類だけを対象にするのかを確認しないと、読み方を確定できません。生成が成功することと、こうした意味の整合が取れることは別です。

また、閲覧用HTMLはモデルの直接編集や保存、コード・データベースへの変更の書き戻し、変更の常時監視を行いません。概念ビューで技術的な中間テーブルを省くなどの整理も、モデル作成側で考える必要があります。現行実装はConceptとERで同じエンティティ一覧を使います。

このスキルの使いどころは、説明のずれをレビュー可能にすることです。対象機能を一つ選び、根拠付きモデルを作り、業務側と開発側で未確定の関係を確かめる。その小さな運用が続けられるなら、画面とデータの対応を引き継ぐための共通資料になります。

生成コード：表示と検証の実装

出典・確認範囲

README、スキル定義、抽出ルール、サンプルモデル、生成コードを確認。付属サンプルでPython生成を実行し、5オブジェクト・3画面・5関係のHTML出力を確認しました。実プロジェクトでの抽出精度や手戻り削減効果は測定していません。リンク先のソースは確認時のコミットに固定しています。公開デモはその後更新される場合があります。

• 概要と配布方法（README）
• 生成コード：表示と検証の実装
• 不動産CRMのサンプルモデル
• 抽出と根拠のルール
• スキル定義：導入後の作業手順

GitHub commit: 914d68fe3f12