ローコード開発ツール
Commonweal（コモンウィール）は、実装から機能設計書・ER 図を自動抽出して「生きた設計書」に資産化し、さらに 業務データ辞書（データディクショナリ）と業務概念モデル（EDM＝概念データモデル）で 「業務の意味」＝ビジネスメタデータまで管理する、設計情報管理プラットフォーム。 実装と直結したデータカタログ／データガバナンス基盤として、人が読める形と AI が読める形の両方で提供します。
それは、実装と切り離された場所に「書き写された文書」だからです。書き写した瞬間から、実装と離れはじめます。
リリースのたびに乖離が広がる Excel 設計書。「最新はどれか」を確かめる調査に、改修コストの多くが消えていく。
仕様の本当の意味は担当者の頭の中にある。異動と退職のたびに、組織は自分のシステムを少しずつ理解できなくなっていく。
AI にシステム改修を任せたい。しかし古い設計書を読ませれば、AI は古い前提のままコードを書く。AI 活用の土台が、ない。
Commonweal は、動いているシステムの設定・SQL・スクリプト・ストアドプロシージャを解析し、
画面ビジュアル・設定情報・依存関係まで含む設計書一式をワンクリックで自動生成します。
実装が変われば、次の生成で設計書も変わる。もう乖離しません。
ただし、実装がすべてを語るわけではありません。「なぜこの項目はこう扱うのか」という
業務上の定義・ビジネスルール・暗黙知は、コードのどこにも現れない。Commonweal はその置き場所として
業務データ辞書（データドメイン）と業務概念モデル（EDM）を用意しました。
実装から生まれる「What」と、人が定義し育てる「Why」——二つが揃ってはじめて、設計情報は完成します。
何を作るかを構想する「設計」は、これからも人が担う創造的な仕事です。
Commonweal が置き換えるのは設計という行為ではなく、作った後に文書を書き写し、保守し続ける作業。
記録を機械に任せることで、人は設計と判断に集中できます。
こうして集まった設計情報は、誰かの成果物ではなく組織の共有財（コモン）。
機能・テーブル・業務の意味・概念モデルが相互リンクされ、新任者も、監査人も、
そして AI も——同じ共有地から汲むことができます。
これは絵に描いたモックではなく、Commonweal が生産管理システム（機能 125・項目 1,615・データドメイン 133）から 実際に自動生成した設計情報です。クリックして、そのまま触ってみてください。
画像をクリックしても、その画面の実物が開きます。すべて相互リンクで辿れます。
画面ビジュアル・全設定・依存関係を機能ごとに文書化。HTML と Markdown の両形式で出力します。
ER 図と DDL を自動生成。テーブルから使用機能・EDM への逆リンク、主キー欠落などの整合性チェック付き。ER 図はそのまま編集できるファイル形式でも同梱します。
「この項目は業務上なにを意味するか」——業務概念の単位（データドメイン）ごとに業務的定義・ビジネスルール・暗黙知・責任部門を管理。実装と直結したデータディクショナリとして、物理項目と自動照合し、未登録には候補をサジェスト。
ER 図ツールで描いた概念データモデルを取り込み、業務データ辞書・物理テーブル・機能とリンクした「意味の地図」として出力。全社レベルのエンタープライズデータモデル（EDM）を、実装と結んだまま維持できます。
SQL・JavaScript・ストアドプロシージャを解析し、機能 × テーブルの読み書きを網羅。影響調査が「検索」で終わります。
全成果物を生成 AI・LLM が読みやすい Markdown でも出力。RAG の知識ソースにも、MCP 連携による直接参照（対応予定）にも。差分設計書で変更も追跡できます。
実装から生成できるのは「いま、何がどう動いているか」まで。 「なぜそうなのか」という業務の知は、人が定義してはじめて資産になります。 Commonweal の中核は、その上流設計の知を管理する二つの器です。
「これは『納期』ですよね。変更があったから更新しておきましたよ」
「いや、うちでは最初に回答した納期を『納期』と呼んでいます」
製造業の会議室で、何度も交わされてきたやり取りです。同じ会社の、同じシステムの、同じカラムの中に、 業務上の意味が複数混ざっている ── この状態で集計した「納期遵守率」はノイズです。 BI ツールできれいなダッシュボードになるほど、むしろ害が大きい。意味のある数字に見えてしまうからです。
「顧客納期」「引当可能在庫」——同じ言葉でも、部署が違えば意味が違う。 業務概念の単位（データドメイン）ごとに、業務的定義・ビジネスルール・運用上の暗黙知・責任部門を記録します。 物理項目と自動照合されるため、辞書は常に「読まれる場所」へ接続されます。 実装には決して現れない、Why の正本です。
個々のシステムより一段上の層で、業務の概念と関係を一枚の地図に描く。 人が ER 図ツールで描いた概念データモデルを取り込み、業務データ辞書・物理テーブル・機能へ相互リンクします。 システムの領域を超えて、複数システム・複数部門をまたぐ エンタープライズデータモデル（EDM）——「企業の知」の背骨になります。
業務概念と物理項目は 1:N ── だから物理項目のそばに意味の置き場は作れません。データドメインは EDM・業務システム・物理DB の3層を貫く接続軸。 EDM 側は人が意味を確定し、物理側は別名で自動名寄せ。守るべき規律はただ一つ、どの属性・どの項目からも意味の定義へ「遡る道が一本道」であること。 過去のビジネス用語集が失敗したのは、参照が多かったからではなく、この道が曖昧だったからです。
辞書も EDM も、放っておけば腐ります。だからこの構造では、腐り始めた瞬間にそれが画面に現れます。 まだ意味の書かれていない項目は「次に意味を書くべきもの」として一覧に表出。 複数のドメインに一致した項目 ── 一本道が破れた箇所 ── は警告に。 警告をつぶし切った状態が、辞書と実装が一致した状態です。 腐敗を防ぐのは点検の根性ではなく、隠れる場所をなくす構造です。
この二つは自動生成物ではなく、人が育てる業務知。だから Commonweal は 「実装から設計書を出力するツール」にとどまりません。生成された What と、人が育てた Why を ひとつの共有地で束ねる——システム領域を超えた、企業の知の管理基盤です。
そして、すべての定義を書き終えてから始めるものではありません。一つ書けば、その概念については 言い合いが参照に変わり、AI に渡せる文脈が一つ増える ── 効果は定義一つ単位で積み上がります。 冒頭のやり取りは、辞書のある世界ではこう変わります。 「辞書を見ましょう。顧客納期 ── 責任部門は営業部。納期遵守率の基準は初回回答納期、とあります」。 言い合いが、参照に変わる。
AI がシステムを安全に触るには、「いまの実装の正しい説明」と「業務の意味」の両方が必要です。 Commonweal の成果物には meta/ ディレクトリが同梱され、機能一覧・ER・業務データ辞書・ マトリクスが構造化された Markdown として出力されます。
たとえば「最近の受注傾向を調べて、気になる動きがあれば教えて」と頼んだとき。 定義を持たない AI は取引先を伝票コードのまま数え、減少が複数のコードに散らばって埋もれ、 「大きな変化はありません」という誤った安心を返します。 辞書に「取引先は最終需要家の単位で捉える。B 商事経由の受注は実質 C 社の需要」という定義と暗黙知があれば、 答えは変わります ──「C 社の需要が 3 カ月連続で減少。競合切替の可能性。早めの訪問を」。
業務データを何百万レコード読ませても、商流の実態や言葉の解釈は表面に出てきません。 行データを渡すより、業務概念の定義を渡すほうが、文脈の純度がはるかに高いのです。 RAG（検索拡張生成）の知識ソースとして辞書を検索させても、生成 AI・LLM に Markdown ごと渡しても構いません。 AI エージェントは meta/ の Markdown を通じて辞書を参照し、最新の実装と業務の意味に基づいて 分析・開発・保守を行えます。TALON の MCP 連携でも、接続時に設計書 Markdown を受け渡す方式への対応を進めています。 業務データ辞書に蓄えた定義と暗黙知が、生成 AI のガードレール ── LLM のハルシネーションを抑える業務コンテキストになります。
meta/ ├─ INDEX.md # まず読む順（AI 向け案内） ├─ FunctionList.md # 全機能と参照テーブル ├─ ER.md # 物理スキーマ（テーブル/列/FK） ├─ Domains.md # 業務データ辞書（データドメイン） ├─ DomainMatrix.md # 機能×物理×意味マトリクス ├─ FunctionTree.md # メニュー階層 └─ EDM.md # 業務概念モデル $ AI エージェント → 設計書 Markdown を直接参照（MCP 連携: 対応予定）
ローコード基盤 TALON で開発しているチームにも、そうでない組織にも。
TALON で開発しているなら、機能設計書・画面ビジュアル・依存関係・ER 図まで、 納品ドキュメント一式がワンクリックで手に入ります。無償版はこの用途なら追加費用ゼロ。 改修のたびに再生成するだけで、設計書が実装と乖離しなくなります。
TALON で開発していなくても、全機能版は既存システムのデータベースに向けて使えます。 物理スキーマの文書化・業務データ辞書（データディクショナリ）による意味付け・ 概念データモデル（EDM）・AI への提供——実装と直結したデータカタログ／メタデータ管理として、 組織のデータに「意味の共有地」をつくる基盤になります。 TALON はランタイムとして動作するだけで、開発ツールとして使う必要はありません。
1 ソースで 3 エディション。ライセンスキーを置くだけで切り替わります。
※ 機能設計書本体の情報量は、全エディション同一です。エディションで変わるのは、ER図・辞書・EDM・マトリクスなど周辺成果物の出力だけ。
※ 業務データ辞書・EDM の管理画面は全エディションで利用できます（登録した内容が設計書出力に現れるのは全機能版）。
※ ライセンスが未配置・期限切れの場合は、自動的に無償版として動作します。
※ すべてのエディションの実行環境として TALON（別途ライセンス）が必要です。
TALON をお持ちでない場合は、ランタイムを含めた構成をご提案しますので
お問い合わせください。
| 実行環境 | TALON 5.1 以上 ※Commonweal の実行エンジンとして必要です。TALON をローコード開発ツールとして使っていない組織でも、業務データ辞書・EDM・物理DB文書化の用途でご利用いただけます |
|---|---|
| 対応データベース | Oracle / PostgreSQL / SQL Server / MySQL |
| 出力形式 | HTML / Markdown / A5:SQL Mk-2（.a5er）/ DDL（.sql）— ZIP 一括ダウンロード |
| 出力言語 | 日本語 / 英語 |
| セキュリティ | オンプレミス内で完結。設計情報を外部サービスへ送信しません |
いいえ。Commonweal が自動化するのは、完成した実装を設計書に書き写し、変更のたびに追随させ続ける「記録」の作業です。設計そのものは、これからも人の仕事です——何を作るかを構想する設計はもちろん、業務データ辞書に定義・ルール・暗黙知を書き込むことも、業務概念モデル（EDM／概念データモデル）を描くことも、人が行う上流の設計行為そのものです。Commonweal はその設計の置き場になり、実装と自動で突き合わせて腐らせずに保ちます。書き写しの時間を無くして、設計の時間を増やす——そのための道具です。
いいえ。自動生成は二本柱の片方です。もう一方の柱が、業務データ辞書（データドメイン）と概念データモデル（EDM）による「業務の意味」＝ビジネスメタデータの管理。項目の業務的定義・ビジネスルール・暗黙知といった、実装のどこにも現れない上流の知を人が定義し、物理項目・機能と相互リンクして育てていきます。実装由来の What と人が育てる Why を一つの共有地で束ねることで、個々のシステムを超えた企業の知の管理基盤になります。
Commonweal の業務データ辞書は、データガバナンス領域でいう「ビジネスグロッサリー」「データディクショナリ」に相当します——業務概念の単位（データドメイン）ごとに、業務的定義・別名・算出ルール・責任部門を管理する仕組みです。決定的な違いは、辞書が動いているシステムと直結していること。物理DB・画面項目と出力のたびに自動照合され、実装とのズレは警告として表面化します。「作った後に腐っていく用語集」ではなく、腐敗が隠れられない辞書です。
現場の有識者です。顧客納期の定義は営業が、原価の計算ルールは経理が、在庫の引当ロジックは生産管理が書く。IT 部門は書く場所（一覧・別名登録・物理マッピング・EDM 整備）を整え、定義の標準化・重複統制・網羅性というメタデータ管理のガバナンスを受け持ちます。意味は現場が育て、ガバナンスは IT が利かせる ── そして初版は必ず人が書き、AI は後から参照する側に回ります。
意味が変わるときは構造も一緒に動くことが多く、新しい項目が物理側に現れれば「未紐付き」の警告として表出し、定義を見直す合図になります。さらに辞書の全文はいつでも AI 向けの Markdown として生成できるため、AI 自身を点検役に回せます ── 定義同士の矛盾・用語の揺れ・実装と食い違う記述を「劣化が疑われるリスト」として挙げさせる。人が数百の定義を通読し続けるのは現実的ではありませんが、AI なら毎晩でも読めます。兆候は機械が指し、疑いは AI が挙げ、意味を確定するのは人 ── この役割分担で鮮度を保ちます。
成果物一式が構造化された Markdown（meta/ ディレクトリ）で出力されるので、そのまま生成 AI・LLM に渡せます。RAG（検索拡張生成）の知識ソースとして業務データ辞書を検索させれば、業務用語の定義・ビジネスルール・暗黙知という純度の高いコンテキストだけを LLM に渡せ、行データを大量に読ませるよりトークン量も抑えられます。MCP 連携による直接参照にも対応予定です。
いいえ。一つ書けば、その概念については言い合いが参照に変わり、AI に渡せる文脈が一つ増えます。効果は定義一つ単位で積み上がるので、重要な業務概念から小さく始めて、徐々に広げていくのがおすすめです。まだ定義のない項目は「次に意味を書くべきもの」として一覧に表出するため、広げる順番も迷いません。
はい。全機能版は、既存システムのデータベースに接続して「物理DBの文書化＋業務データ辞書＋概念データモデル（EDM）＋AI 連携」のデータガバナンス基盤としてご利用いただけます。TALON は実行エンジンとして動作するだけで、ローコード開発ツールとして使う必要はありません。ランタイムを含めた構成はお問い合わせください。
はい。まず、紐づけの母集団が「業務で実際に使っているテーブル」に自動で絞られます。Commonweal は接続先のカタログを総なめにするのではなく、TALON 機能が参照しているテーブルだけを対象に抽出するため、数千テーブル規模の Salesforce や SAP でも対象は業務で使う数十〜数百に収まります。それでも残る大量の管理項目（更新日時・更新者などのシステム列）には「照合除外」を用意しています——抽出された一覧をチェックして一気に除外できるほか、ALL キーワードで「全テーブルの同名列を串刺しで」「テーブル丸ごと」「全接続先まとめて」といった一括除外もできます。意味を書くべき項目だけが残るので、辞書づくりは最初から本丸に集中できます。
Commonweal 無償版自体にライセンス費用はかかりません。実行環境である TALON をすでにお使いであれば、追加費用ゼロで今日から機能設計書の自動生成をお使いいただけます。
ありません。生成はすべてお客様の環境内で完結し、成果物は ZIP ファイルとしてダウンロードされます。AI 連携も、お客様が選んだ AI にお客様の管理下で渡す設計です。
ライセンスキーのファイルを 1 つ配置するだけです。再インストールも再起動も不要で、次回の出力から反映されます。
設計知を、囲い込みから共有地へ。実装から「生きた設計書」を自動生成する設計情報管理プラットフォーム（コモンウィール）。
詳しく見る 30日間無償ローコード開発ツール「TALON」を、クラウドまたはお手元の環境で実際に試せます。
申し込む 活用例顧客管理・生産管理・IoT分析まで。ノンプログラミング開発だから実現できる活用例をご紹介。
見てみる パートナーTALONでビジネスを始めませんか？ 販売・構築パートナーを募集しています。
制度を知る 解説動画TALONをもっと分かりやすく。機能や開発の流れを動画でご覧いただけます。
動画を見る 無料セミナーTALONを検討している企業様へ。実際に操作しながら学べる無料セミナーを毎月開催しています。
日程を見る