AI が構成図を描き、人が 1 か所だけ直す。
その直しが、次の生成で壊れません。
構成が変わった → 図を直すのが面倒 → 直さない → 図が嘘になる → 誰も図を見なくなる。
既存の作図ソフトは「1 枚目を描く道具」として完成しています。そこを競っても勝ち目はありません。 zumen が向き合うのは、白紙から描く面倒ではなく、更新されないまま腐ることです。
サーバやネットワークだけではありません。
路線図・停車駅案内・列車運行図表、間取りと躯体の伏図、配管の系統と受変電、
歯周チャート、釣りの仕掛け、舞台照明の仕込図、中古車の査定図、相続関係説明図、
コンテナ船の積付図、花火の保安距離 ——
「何がどこへ繋がるか」「どの順で流れるか」「何がどこにあるか」を表す図なら、
同じ書き方で描けます。
下の 93 枚はすべて、同じ 11 語の語彙で書いたものです。
業界ごとの図形は 1 つも足していません。専門性は形ではなく符号
(C1 G1 2"-CS-101 LBS-1)で
表されているからです。
建築の図は、通り芯と寸法が入ります。壁は塗り潰し、建具は開き勝手まで描きます
── 寸法が無い図では、何も建てられません。
4 枚とも、下のような文章から そのまま出たものです。手で位置を直してはいません。
交差 0・箱の重なり 0・消えたラベル 0。
描いてある構成は例のために組んだもので、実在のものではありません。
正本は examples/gallery/
に入っているので、同じものを手元で出せます。
version: 1
title: オンプレのサーバ構成
nodes:
- id: httpd
type: server
label: Apache httpd
technology: 2.4 / mod_php
- id: db
type: database
label: MariaDB
edges:
- from: httpd
to: db
Git で差分が読めます。誰が何を足したか、レビューで分かります。
type は形になるので、白黒で印刷しても、縮小しても見分けが付きます
── 円柱はデータベース、六角形はキャッシュ、雲は外の世界。
version: 1
kind: placement
# 1 px = 15 mm。間仕切 105・外壁 180
scale: { mm: 15 }
wall: { mm: 105, outer: 180 }
north: up
grid:
x:
- { id: X1, at: 40 }
- { id: X2, at: 240 }
y:
- { id: Y1, at: 40 }
- { id: Y2, at: 320 }
nodes:
- id: ldk
label: LDK
technology: 16 畳
at: { x: 40, y: 40 }
size: { w: 320, h: 280 }
openings:
- { kind: window, side: top, at: 0.25, width: 90 }
- { kind: door, side: bottom, at: 0.83, width: 70 }
寸法は通り芯からしか出しません。部屋の箱から出すと、
壁の厚みをどちらに数えるかで値が変わり、現場で食い違います
── 実物の図面が通り芯を基準にしているのは、そこを一意にするためです。
scale が無ければ、寸法の数値を出しません。
知らない縮尺で数値を書くより、出さないほうがましだからです。
人の手直しは正本の pins にしか書かれず、AI はそこを書けません。
道具の側で閉じてあるので、規約や注意書きに頼りません。
本物の AI で 10 回試して、10 回とも手直しは消えませんでした。
{ "mcpServers": { "zumen": {
"command": "node",
"args": ["<zumen の場所>/src/mcp.ts"] } } }
MCP の口が 9 つ。サーバ構成を把握しているエージェントに、直接描かせられます。
描いたあと zumen_inspect を叩けば、線の交差・箱の重なり・
置けずに消えたラベル・投影して読める大きさか・
人がまだ見ていないかが返ります。
開けていない口もあります ── 競合の決着、pins の書き換え、
「見た」の印。開けた瞬間、AI が自分の絵を自分で承認できてしまうからです。
Rust があれば pnpm app でそのまま立ちます。
MCP サーバだけなら Node だけで動きます(殻は要りません)。