比較
MapleSpire と Structurizr：企業規模のガバナンスに耐えるのはどちらか
Structurizr と MapleSpire はどちらも C4 モデルに基づき、図ではなく本物のモデルを扱います。両者の違いは、大きな組織にとって決定的な問いにあります。共有メタデータはどこにあり、誰がそれを最新に保てるのか、という点です。
アーキテクチャがコードであり、エンジニアリングチームが Git で書いてレビューする場合、Structurizr は真価を発揮します。MapleSpire が目指すのは統制されたリポジトリです。組織全体でタグとテクノロジーのカタログを一つにまとめ、権限を持つ人なら誰でもビジュアルに編集できます。
二つのモデリング思想
Structurizr は「Models as Code」のツールです。アーキテクチャはテキストの DSL で書かれ、Git でバージョン管理され、図を生成するサーバーへ送られます。ドキュメントでは、ソフトウェアシステムごとに一つの workspace を、それを構築するチームが持つことを推奨しています。
MapleSpire は共有のビジュアルモデルです。オブジェクト、リレーション、ビューはデータベースにあり、リアルタイムで共同編集でき、オフラインでも利用できます。タグとテクノロジーのカタログは組織レベルのエンティティであり、各ファイルにコピーされるテキストではありません。
どちらのアプローチも、一般論として優れているわけではありません。違いが表れるのは、チーム、システム、コントリビューターの数が増えたときです。
メタデータの付与：タグ、テクノロジー、バージョン、グループ
| メタデータ | Structurizr | MapleSpire |
|---|---|---|
| タグ | 要素ごとの自由テキスト（tags "A,B"）。スタイルはタグのテキストに紐づく | タグとタググループを組織で一度だけ定義し、ID で参照 |
| タグの名前変更・統合 | 各 workspace で検索と置換 | 名前変更、色変更、統合、アーカイブ：すべてのランドスケープに一括で反映 |
| テクノロジー | 自由テキスト（technology "Java"） | 管理カタログ：エイリアス、ライト／ダーク用アイコン、ドキュメントへのリンク |
| テクノロジーのライフサイクル | モデル化されない | 有効、非推奨、廃止、統合済み。新規追加は承認を経る |
| 使用バージョン | テキストや properties に自分で追記 | テクノロジーの利用ごとにバージョンを記録 |
| グループとドメイン | DSL で宣言するビジュアルなグループ | タグとテクノロジーを持てるグループ、階層的なドメイン |
| カスタムプロパティ | properties と perspectives（自由なキーと値の組） | モデルには組み込み予定、UI ではまだ編集不可 |
Structurizr では、tags、technology、properties、perspectives というキーワードで要素を記述します。これらは要素ごとに入力する自由な文字列です。archetypes が既定値を与え、スタイルはタグに紐づきますが、有効なタグやテクノロジーを定義する中央のレジストリはありません。
実際には「PostgreSQL」「Postgres」「postgresql 16」が別々の workspace に共存しえます。タグの名前を変えるには関係するすべてのリポジトリで検索と置換が必要で、組織が廃止したテクノロジーを誰かが使うことも止められません。
MapleSpire では、オブジェクトはタグのテキストを保存しません。組織で一度だけ定義されたタグへの参照を保存します。テクノロジーは、エイリアス、アイコン、ライフサイクルを備えた管理カタログから選びます。
責任者はどうなるのか
オーナーシップ（どのチームがその要素に責任を持つか）は、ガバナンスのプロセスが最初に求めるメタデータであることがよくあります。Structurizr では owner キーのような自由なプロパティに書くことになり、チームのディレクトリとは結びつきません。
MapleSpire はアクセス制御のためにすでにチームを管理しており、モデルにはオブジェクトに担当チームを割り当てる計画があります。ただし、この割り当てはまだ UI で提供していません。約束するより、はっきりそうお伝えします。
一度の更新で、全員に反映
企業全体のビューのために、Structurizr は三段階の方法を提案しています。ソフトウェアシステムを URL で共有する DSL カタログにまとめ、各チームの workspace でそのカタログを拡張し、全体のランドスケープを生成するというものです。このランドスケープは、管理者がすべての workspace を取得してジェネレーターを実行し、結果を公開して作ります。あくまでコピーなので、その後の変更を反映するには再生成が必要です。
MapleSpire では、タグとテクノロジーは組織のデータベースにあります。管理コンソールで行った変更は、公開の手順なしに、すべてのランドスケープへ即座に反映されます。ランドスケープの中では各オブジェクトが一度だけ存在し、すべての図がそれを参照します。
正確を期すために補足が二つあります。MapleSpire でも詳細なモデルはランドスケープごとに閉じており、組織全体で共有されるのはカタログだけです。また、テクノロジーの各利用は記録時のカタログのリビジョンを保持するため、カタログの変更が履歴を黙って書き換えることはありません。
アクセス制御と変更レビュー
Structurizr server のオープンソースのコアには、認証もロールベースのアクセス制御もありません。workspace は公開されます。ロール、SAML、LDAP、管理 API は、ライセンス付きのビルド済みバイナリに含まれます。その大きな強みは別のところにあります。モデルがコードなので、あらゆる変更をプルリクエスト、レビュー、CI での自動検証に通せるのです。
MapleSpire の AGPL-3.0 のコードには、組織のロール、ランドスケープごとに読み取りまたは書き込み権限を持つチーム、Google または Microsoft による OIDC シングルサインオン、管理操作の監査ログが含まれます。変更はドラフトで準備し、変更一覧を確認したうえで、競合を検出するマージで取り込みます。
現時点の制約：MapleSpire のドラフトには、マージ前の正式な承認ステップがまだありません。すべての変更に必須のレビューを求めるガバナンスであれば、現状では Structurizr のプルリクエストのフローの方が厳格です。
どちらがスケールするか
| 観点 | Structurizr | MapleSpire |
|---|---|---|
| チーム間で一貫した語彙 | 規律とレビュー次第 | 単一のカタログで強制 |
| 開発者以外のコントリビューター | DSL と Git の習得が必要 | ビジュアル、複数人、リアルタイムの編集 |
| 最新の全体像 | ランドスケープを必要に応じて再生成 | カタログはライブで共有、詳細モデルはランドスケープ単位 |
| 変更レビューの必須化 | プルリクエストと CI | ドラフトとマージ、正式な承認はまだない |
| アクセス制御と SSO | ライセンス付きバイナリ | オープンソースのコードに含まれる |
| 高可用性 | 選んだストレージとライセンス次第 | 同期は当面シングルインスタンスで動作 |
組織全体に同じ言葉（同じタグ、テクノロジー、バージョン）を話させ、Git を日常的に使わないアーキテクト、プロダクト責任者、チームにも参加してもらうことが課題なら、ガバナンスの面では MapleSpire の方がスケールします。
アーキテクチャがすでにコードとして管理され、コントリビューターが開発者で、ガバナンスがプルリクエストのレビューで回っているなら、Structurizr は今も優れた選択肢です。
移行するか、併用するか
MapleSpire は Structurizr DSL の workspace をインポートし、対応する C4 図を生成します。Structurizr DSL、Mermaid、JSON、CSV、SVG、PNG、Markdown へのエクスポートにも対応しているため、手元のファイルを手放すことなく、既存の workspace で MapleSpire を試せます。
出典
Structurizr に関する記述は、2026年10月12日に参照した公式ドキュメントに基づいています。ここで説明している MapleSpire の機能は、公開されているコードのものです。