Structurizr Cloud は 9 月 30 日に終了：まずモデルを取り出してください

Structurizr のクラウドサービスはサービス終了を迎えます。同社の end-of-life ページには "Structurizr cloud service (no replacement)" が、Lite、CLI、オンプレミス版と並んで掲載されており、いずれも新しい統合ツール群に置き換えられます。同社の end-of-life アナウンスによれば、ワークスペースは 2026 年 7 月 1 日に読み取り専用となり、残っていた月額サブスクリプションも同日に停止され、サービスは 2026 年 9 月 30 日に終了します。このアナウンスは Patreon の中にあるため、日付を前提に計画を立てる前に、ご自身で確認してください。

読み取り専用になったことが緊急事態なのではありません。緊急なのは、読み取り専用が覆い隠しているほうです。ワークスペースを取り出すために使うはずのツールが、閉じようとしているサービスの一部だということです。 ワークスペースエディターの DSL タブ、ダッシュボードのエクスポートリンク、Web API。これらはすべてクラウドサービスです。10 月 1 日には、クリックできるタブはもうありません。

つまり最初の判断は、どのツールに移るかではありません。ファイルを 1 つ自分のディスクに置くことです。それはワークスペースごとにコピー＆ペーストするだけの作業で、何のコミットメントも生みません。移行先を決めることは、そのどちらでもありません。

モデルを取り出す

この作業を最初にやってください。この下に書かれていることを読む前にです。

あなたのワークスペースは読み取り専用であって、見えなくなったわけではありません。Structurizr の クラウドサービス FAQ は、読み取り専用のワークスペースについてこう述べています。"You can still view the workspace content (via the UI and web API) but no changes can be made" — ワークスペースの内容は引き続き（UI と Web API 経由で）閲覧できますが、変更は一切行えません。以下の手順はすべて、今日なら動きます。

DSL で書いていて CLI で push していたなら、すでに終わっているかもしれません。 あなたの workspace.dsl は Git にあります。開いて、最新かどうか確認してください。注意すべき点が 1 つ。ブラウザの図エディターで手作業で調整したレイアウトは、クラウド側のコピーに存在していて、あなたの DSL にはありません。それが重要なら、ステップ 2 の JSON エクスポートも取っておいてください。

ブラウザで、あるいは Workspace API を通じて書いていたなら、あなたのモデルは Structurizr のデータベースの中にしか存在しません。 次の順番で進めてください。

  1. DSL。 Structurizr が既存ユーザーに対して示している方針は、DSL への変換です。同社の ワークスペースエディターのヘルプページより："A DSL representation of your workspace (excluding documentation) can be found on the DSL tab" — ワークスペースの DSL 表現（ドキュメントを除く）は DSL タブにあります。ワークスペースエディター自体は 2022 年 2 月に提供終了となりましたが、https://structurizr.com/workspace/XXXXX/workspace-editor という形式の URL では今も到達できます（XXXXX はあなたのワークスペース ID）。開いて、DSL タブをクリックし、すべてコピーして workspace.dsl として保存してください。

    彼らの文の括弧に注目してください。DSL 表現にはドキュメントが含まれません。 !docs と !adrs をリポジトリ内の Markdown ファイルに向けるのではなく、ワークスペースの中にドキュメントや ADR を書いていた場合、DSL タブはそれらを返してくれません。

  2. JSON。 Structurizr の 移行ガイダンスは、ページ上部の "export your workspaces" リンクを案内しています。これが workspace.json を生成します。すでに DSL を持っていても、これも取っておいてください。Structurizr 自身の playground と local の両方が受け付ける形式であり、local は workspace.dsl、workspace.json の順に探します。

  3. この 2 つのファイルが取りこぼすもの。 ワークスペース内に書いたドキュメント、アップロードした画像、ステータス履歴つきの決定記録。UI がまだ存在するうちに、UI でワークスペースを開いて、大事なものを Markdown にコピーしてください。

  4. 両方のファイルをリポジトリにコミットする。 ノート PC のフォルダーではありません。リポジトリです。それらが記述しているコードの隣、次の人が見つけられる場所に置いてください。

ワークスペースごとに繰り返してください。12 個あるなら、あとで戻ってこようと自分に約束するのではなく、一度に片づけてしまいましょう。

1 つ、確認できなかったことがあります。9 月 30 日にワークスペースのデータが削除されるのか、単に到達不能になるだけなのかについて、Structurizr が公表しているものを私は見つけられませんでした。 10 月に返してもらえると決めてかからないでください。返してもらえないと決めてかかるのも同様です。とにかくファイルを取ってください。

どこに置くか

正直な選択肢が 4 つあります。それぞれ向いているチームが異なり、そのうち 3 つは archyl ではありません。

選択肢 1：Structurizr 自身のツール群

これは、どのベンダーのブログが言うよりも多くのチームにとって正解であり、真っ先に見積もるべき選択肢です。

Structurizr がなくなるわけではありません。なくなるのはクラウドサービスです。同社の EOL ページは、旧製品を新製品に対応づけています。Lite は local に、CLI は pull / push / export に、オンプレミス版は server に置き換わります。今日 Lite や CLI を使っているなら、あなたの前にも移行が待っています。ただし、はるかに小さいものです。

  • local はドキュメントでこう説明されています。"the free and open source local command provides a way to view diagrams and modify their layout" — 無料でオープンソースの local コマンドは、図を閲覧しレイアウトを変更する手段を提供します。自分のマシン上で、localhost にバインドして動きます。同社の クイックスタートはコマンド 2 つです。docker pull structurizr/structurizr、続いて docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local。workspace.dsl を置いたディレクトリを指定して、http://localhost:8080 を開き、ファイルを編集して、ブラウザを更新します。
  • playground は、たまにしか使わない場合の同社の提案です。workspace.dsl か workspace.json をアップロードして、図を眺めて、タブを閉じる。
  • server は、クラウドサービスがあなたのために果たしていた役割、つまりワークスペースをより広い相手に公開する役割を引き継ぐものです。ソースからビルドすれば無料で使えるオープンコアがあり、ファイルシステムストレージ、Lucene 検索を備え、認証はありません。ビルド済みバイナリはこれに SAML、ロールベースのアクセス制御、プライベート共有トークン、S3 および Azure Blob ストレージ、Elasticsearch、管理 API を追加し、ライセンスが必要になります。ユニークユーザー 1〜20 人で月額 £300、21〜50 人で £600、51〜100 人で £900、年間一括請求です。同社のユニークユーザーの定義は、iframe や埋め込み画像経由も含めて図を閲覧する人すべてを数えるもので、編集者だけではありません。

向いているチーム： モデルがすでに Git 上の DSL で、読み手はエンジニアで、クラウドサービスの主な用途がレンダリングだったチーム。DSL はそのままの形で残せますし、私たち自身のインポーターが落としてしまう deployment ビューや dynamic ビューも残ります。しかもそのツール群は、C4 モデルを考案した本人が書いています。それがあなたなら、ここで読むのをやめて、Docker コマンドを実行しに行ってください。

向いていないチーム： サーバーを自分で運用することなく、100 人の非エンジニアに図を見てもらう必要があるチーム。そして、閲覧者 20 人に月 £300 という条件が、編集者単位の SaaS 価格より悪く見えるチーム。そしてもう 1 つ、この記事の残り全体が乗っている論点があります。セルフホスティングはあなたのモデルを保存しますが、維持はしません。クラウドで古びていったワークスペースは、local でも同じように古びます。コードが変わったときに DSL を回し直す人はいないのです。

選択肢 2：DSL をリポジトリに置いたまま、ツールへの支払いをやめる

もっとも過小評価されている選択肢であり、もっとも安い選択肢です。

workspace.dsl を Git に置き、他のものと同じようにプルリクエストでレビューし、誰かが本当に図を必要としたときにその都度レンダリングする。local はそれをコンテナの中でレンダリングします。playground も同じです。Structurizr の構文からも完全に離れたいのであれば、LikeC4 は MIT ライセンスで、リポジトリ内の .c4 ファイルとして記述し、Vite プラグイン、React コンポーネント、Web Components を通じて公開できます。つまり、すでに運用しているドキュメントサイトに図を埋め込めます。

向いているチーム： 図の読み手が DSL を読める一握りのエンジニアで、「これ、どのくらいの頻度で誰かが開くのか？」への正直な答えが「オンボーディングのときと障害対応のとき」であるチーム。使っていたものは何も失わず、継続コストはゼロになります。

向いていないチーム： リポジトリをクローンしない人たちに図を読まれている場合すべて。そしてそれは、クラウドサービスに料金を払っていたのなら、まさにその料金を払っていた理由かもしれません。

選択肢 3：別のホスト型 C4 ツール

クラウドサービスがあなたにとって実際に仕事をしていたのなら、別のホスト型ツールで置き換えるのは妥当な判断です。そして、1 つだけでなく複数を見るべきです。

IcePanel がもっとも近い代替です。ビジュアル志向の C4 ツールで、ホスト型サービスを持ち、無料プランは編集者 5 人、閲覧者は無制限、モデルオブジェクトは最大 100 個まで。有料プランは年間一括請求で編集者 1 人あたり月額 $40 からです。同社自身の Structurizr との比較記事には "model objects can be imported from Structurizr, Backstage, and a REST API" — モデルオブジェクトは Structurizr、Backstage、REST API からインポートできる、とあります。私がたどり着けたページには、受け付けるファイル形式が明記されているものを見つけられませんでした。ですから決める前に、上のセクションで取り出したまさにそのファイルをアップロードして、何が残るか確認してください。この助言は、この記事に出てくるすべてのツールに当てはまります。私たちのものも含めて。

向いているチーム： ドラッグ＆ドロップのエディターが欲しく、閲覧者がエンジニアではないチーム。

向いていないチーム： モデルがテキストであるからこそ Structurizr に移ったチーム。クラウドの終了から逃れるために architecture-as-code を手放すのは奇妙な取引で、変更を差分で見たくなった最初の瞬間にそれを実感することになります。

選択肢 4：archyl

私たちは Structurizr DSL のインポーターを作りました。ですからこれは私がもっともよく知っている選択肢であり、あなたがもっとも懐疑的に読むべき選択肢です。

持ってくるのは workspace.dsl であって、workspace.json ではありません。 archyl は Structurizr DSL のテキストをパースします。ワークスペース JSON の経路はありません。エクスポートリンクから JSON しか得られなかった場合は、試す前に下のセクションを読んでください。

プロジェクトを開き、インポートモーダルで Structurizr DSL を選び、.dsl ファイルをアップロードするか貼り付けます。取り込まれるもの：トップレベルの person と softwareSystem、ネストされた container と component、名前と説明、コンテナ・コンポーネント・リレーションシップに付いたテクノロジー文字列、カンマ区切りのタグ、どの深さにあっても group:<name> タグに平坦化される group ブロック、そして要素の本体の中を含めファイルのどこで宣言されていてもリレーションシップ。コンテナとリレーションシップの型は、あなたのテクノロジー文字列とラベル文字列から推論されます。外部システムは External System または External タグから拾われます。インポーターは Simon Brown 自身の Big Bank サンプルワークスペースに対してテストされています。

取り込まれないもの。こちらのほうが重要です。

  • レイアウトとスタイルのすべて。 views、configuration、styles ブロックはスキップされます。代わりに archyl が自動レイアウトを行います。手動レイアウトは Structurizr が売りにしているものの 1 つですから、これはあなたの旧ツールがもっとも得意としていたもので、それを手放すことになります。
  • !docs と !adrs。 ディレクティブはスキップされます。archyl には ADR とドキュメントの機能がありますが、Structurizr インポーターがそれを埋めることはありません。
  • !include。 複数ファイルに分かれたワークスペースは、インポート前に 1 つに平坦化する必要があります。そうしないと、include された内容は単に存在しません。
  • デプロイメント環境、deployment node、infrastructure node。 インポートされません。

インポーターは、そのほとんどをインポート結果画面に警告リストとして、ソースファイル自身の用語で返します。

line 42: 'views' block is not supported and was skipped
line 7: directive '!docs' is not supported and was skipped

これについて注意が 2 つあります。信頼できるリストは、私たちを持ち上げるリストより価値があるからです。1 つめ。デプロイメント環境とノードはスキップされます。archyl が扱うのは静的な構造であって、デプロイメントのトポロジーではないからです。パーサーは警告リストに行番号付きで名前を出すので、deploymentEnvironment "Live" ブロックは、あとから気づくものではなく、読める 1 行として届きます。2 つめ。警告が伝えるのはパーサーが拒否したものだけであって、それ以外のインポートが完璧だったことを伝えるものではありません。あとでモデルを読み返してください。

local を動かすのではなく、これに対価を払う唯一の論拠： archyl はモデルをリポジトリに対して再検証し、そのずれをスコア化します。したがって、コードと一致しなくなったモデルは、黙って間違いになるのではなく、自分でそう言います。それが ドリフトスコアで、決定論的であり、AI 呼び出しなしで動きます。クラウドが読み取り専用になった日に、あなたの Structurizr ワークスペースが正確で最新だったのなら、これは必要ありませんし、私は売り込もうとも思いません。18 か月古いままだったのなら、問題は最初からツールではなかったのであり、置き場所を変えても直りません。

私たちの不利になる 2 点。 無料の Developer プランは 1 プロジェクトを 100 モデルオブジェクトに制限するので、50 個のシステムとそのコンテナを持つワークスペースは収まりません。そして archyl はクラウドファーストで、セルフホスティングは Custom ティアのみです。Structurizr がクラウドサービスを閉じる理由として、日付を伝えているのと同じ アナウンスの中で挙げていたのは、エンジニアリングチームがアーキテクチャ図をクラウドに公開することに消極的で、利用が着実に減っていたということでした。それがあなたのセキュリティチームに当てはまるなら、選択肢 1 のほうが私たちより適していますし、それを調達プロセスの中で 2 週間かけて発見すべきではありません。

手元に JSON ファイルしかない場合

ダッシュボードのエクスポートリンクが渡してくるのは workspace.json で、たいていの人が最終的に手にするのはこのファイルです。どこで使えるか：

  • Structurizr local と playground はそのまま読みます。 変換は不要です。
  • archyl は読みません。 代わりに DSL タブから DSL を取ってください。しかも 9 月 30 日より前にです。ワークスペースが Workspace API 経由で書かれていて、DSL タブから使えるものが得られない場合、代替が 2 つあります。リポジトリを接続して AI ディスカバリーにコードからモデルを提案させるか、コーディングエージェントを JSON に向けて、MCP サーバー経由でモデルを書かせるかです。後者の手順は こちらの記事にあります。
  • それ以外のどこか： 移行したあとではなく、移行する前に聞いてください。

選び方、ひとつの段落で

モデルがすでに Git 上の DSL で、読み手がエンジニアなら、local を動かして、浮いたお金は他に使ってください。共有できてアクセス制御されたインスタンスが必要で、ライセンス費用を負担できるなら、server がクラウドサービスの役割にもっとも近いものです。ビジュアルエディターと非技術者の閲覧者が欲しいなら、IcePanel を見てください。いま書き出したワークスペースがすでに古くなっていて、しかも古いのは手作業での更新が誰かの 4 番目の優先事項だったからだとしたら、置き換えるべきなのはツールではありません。そして、まさにそれが archyl の主張です。

どれを選ぶにせよ、まずファイルを取り出してください。タブはサービスと一緒に消えます。

仕組みについてさらに詳しくは、Structurizr、LikeC4、IcePanel プロジェクトのインポート、Structurizr 移行ページ、2026 年の C4 ツール比較をどうぞ。モデルそのものが初めてなら、C4 モデルとアーキテクチャドリフトから始めてください。