コード・Terraform・ダイアグラムを MCP で C4 モデルに変換
アーキテクチャドキュメントで一番難しいのは、箱を描くことではありません。ツールを開いた時点で、アーキテクチャはすでに存在している——しかも、互いに会話しない5つの場所に散らばって——ということです。
誰かが8ヶ月間メンテしてきた Structurizr DSL ファイル。十数個の README に散らばる Mermaid 図。どんな図よりも本物のインフラを正確に記述している Terraform モジュール。以前使っていたツールから書き出した PlantUML。そして、決して嘘をつかない唯一のソースであるコードベースそのもの。
土曜日には、2つの MCP サーバーとプロンプトひとつで Confluence スペースを Archyl に移行する方法を紹介しました。今日は同じトリックで、もっと大きな獲物を狙います。アーキテクチャそのもののインポートです。
2つの道——ソースごとに選ぶ
まずは組み込みの道から。リポジトリが Archyl に接続されているなら、AI Discovery がコードを解析し、完全な C4 モデル——システム、コンテナ、コンポーネント、リレーションシップ——を提案してくれます。あなたはレビューして承認するだけ。そして別の C4 ツールから来たなら、Structurizr DSL、LikeC4、IcePanel のエクスポートには、すでにワンクリックのインポーターがあります。どちらかが当てはまるなら、まずそこから始めましょう。
MCP の道はそれ以外のすべて、つまり Discovery には見えないソースのためにあります。diagrams-as-code のファイル、インフラ定義、誰かの wiki にあるアーキテクチャページ、あるいはプライベートサーバー上のリポジトリ。Archyl の MCP サーバーは C4 モデルの書き込み面をすべて公開しています——create_system、create_container、create_component、create_relationship、set_element_technologies、create_adr——だから、ソースを 読める エージェントなら誰でも、モデルを 書ける のです。
セットアップは土曜日と同じワンライナー：
claude mcp add --transport http archyl https://api.archyl.com/mcp \
--header "X-API-Key: your_api_key"
レシピ1 — Structurizr、Mermaid、PlantUML
diagrams-as-code は最も簡単な勝ち筋です。セマンティクスがすでに明示されているからです。標準的な workspace.dsl なら、上記のワンクリックのインポーターのほうが速い——エージェントが本領を発揮するのは、Mermaid と PlantUML（インポーターが存在しません）、インポーターがパースできない DSL の変種、あるいはすでにモデルを持つプロジェクトに 選択的に マージしたいときです。Claude Code でリポジトリを開いて：
このリポジトリのルートにある workspace.dsl を読んでください。
私の Archyl プロジェクト "Aurora Commerce" にモデルを再現してください：
- softwareSystem → create_system（外部のものは external_system として
マークする）
- container → 適切なシステムの下に create_container、technology
フィールドは維持する
- すべてのリレーションシップ → create_relationship に説明付きで
- DSL にないものは何も発明しないこと。マッピングできなかったものは
一覧にすること
その後、list_systems と list_containers でモデルを読み返し、
何も失われていないか確認できるようにサマリーを見せてください。
最後の読み返しステップは、習慣として残す価値があります。「うまくいったはず」と仮定する代わりに、エージェント自身がライブのモデルに対して自分のインポートを検証するのです。
レシピ2 — Terraform
あなたのインフラコードは、図が忘れてしまったことを知っています。エージェントを Terraform に向けて、適切な高度で仕事をさせましょう：
このリポジトリの infra/ を読んでください。デプロイメントレベルの
アーキテクチャを Archyl にモデル化してください：マネージドサービス
（RDS、SQS、S3、CloudFront...）はコンテナまたは外部システムに、
実際のサービスごとに1つ — リソースごとに1つではありません。
IAM ポリシー、セキュリティグループ、環境変数からリレーションシップを
つないでください。後でインポートしたレイヤーをフィルタできるよう、
作成したものすべてに "terraform" タグを付けてください。
「リソースごとに1つではない」という一文が、実際に仕事をしています。素朴なインポーターは400個の Terraform リソースを400個の箱に変えてしまいます。エージェントは、DB インスタンスとそのサブネットグループ、パラメータグループが Orders Database というひとつのコンテナであることを理解します。
レシピ3 — コードベースそのもの
DSL も図もなく、リポジトリも Archyl に接続されていない？ エージェントはすでにあなたのコードの中に座っています。ボトムアップでモデルを提案させましょう——デプロイマニフェストからサービスを、パッケージ構造からコンポーネントを、見つけた HTTP クライアントとキュープロデューサーからリレーションシップを。これは AI Discovery の仕事を手作業でやることであり、Discovery がソースに届かないときの正しいフォールバックです。
レシピ4 — wiki に閉じ込められた図
土曜日の記事の2つの MCP サーバーを組み合わせます。エージェントは Atlassian の MCP サーバー経由でアーキテクチャページを読み、そこに記述されたシステムとフローを抽出し、Archyl に書き込みます。イベントパイプラインを 説明していた wiki ページが、実際にナビゲートできるモデルになる——しかもページ自体も、リンクされたドキュメントとして一緒についてきます。
インポートは退屈な部分——本題はここから
インポートの翌日こそが、これをやった理由です。モデルは MCP 経由で入ったので、MCP 経由で届き続けます：
- エージェントはコーディング中にモデルをクエリします——「決済データベースと通信しているコンテナは？」はツールコール1回の距離です。
- 新しいサービスは、それを作った同じエージェントの手で追加されるので、モデルは朽ちていく代わりに現実を追いかけ続けます。
- ドリフトスコアリングとコンフォーマンスルールが、実際にシステムと一致するモデルに対して動きます。
締めくくりに、正直なルールをひとつ。エージェントが提案し、あなたがレビューする。 システムはひとつずつインポートし、サマリーを読み、そぐわないものは刈り込む——コードレビューと同じ規律です。最終的に手に入るモデルの質は、食べさせたソースの質まで。そして5つのソースのうちどれが真実を語っていたかを知っているのは、あなたです。
あなたのアーキテクチャはもう存在しています。描き直すのはやめて、インポートしましょう。ツールの完全な一覧は MCP サーバードキュメントにあります。