東海地区で建築設計事務所を経営している建築士です。
ChatGPT/Claudeに業務をブッ込みまくる「コード書けない開発者」やってます。

▼ 前回までのあらすじ

DXFパース、GIS、専門書のMarkdown化と来て、毎回「コード書けないオジサン」がAIに無茶振りしてきました。

今回は、ついにラスボスです。

Jw_cad（ジェイダブリューキャド）。

日本の建築実務者なら誰でも知ってる、あのフリーで30年動き続けてる国産2D CAD。
あいつのバイナリフォーマット、丸裸にしました。

🏗️ 第1章：なぜ今さらJWWに手を出したのか

弊社、建築設計を本業でやってます。
1物件あたりJWWファイルが何十バージョンも動くのが普通です。

「上の住宅、軒高3mじゃ高度斜線アウトです」
「2階の窓、採光が足りません」
→ JWW修正 → 再申請 → JWW修正 → ...

これ、全部AIにやらせたいじゃないですか。

ところが世の中を見渡すと、

AutoCADは公式SDKがある（DXF/DWG）
BIM（Revit/ArchiCAD）はAPIが整ってる
海外のAI×CAD界隈はArchCAD-400Kみたいな大規模データセットまで出てる

で、Jw_cadは？

仕様書はある。公式の jwdatafmt.txt。
…ただのテキストメモで、しかも歯抜け。

OSSパーサーは？GitHubで「JWW parser」って検索しても、出てくるのはJWT（JSON Web Token）ばっかり。
JWWはJSON Web Tokenじゃないんですよ！

Jw_cadは日本国内でAutoCADに次ぐシェアを持つとされる無料2D CAD（窓の杜ほか各種解説より）、建築設計の現場では実質定番。
海外シェアはほぼゼロ。だから世界のAI研究はほぼスルーしてる。

ちょっと歴史を振り返る（出典付き）

ここ、若い人にはピンとこないと思うので、Jw_cadの歴史的ポジションをデータで並べます。

年	出来事	出典
1991	DOS版Jw_cad、清水治郎・田中善文氏らがNIFTY-Serve建築フォーラム(FARCHI)で公開	Wikipedia
1993末	「建築知識」別冊Jw_cad特集号 4万部出荷	Wikipedia
1994	日本パソコンソフトウェア協会で「フリーソフト検討委員会」開催（商用CADベンダーが Jw_cadの普及に警戒）	Wikipedia
1997.7	Windows版 Ver0.01 配布開始	Wikipedia
2000年代	中小設計事務所〜大手まで建築設計の事実上の標準ツールに定着	株式会社キャパ
2026.1	Ver10.02 リリース（30年以上メンテ継続中）	公式

要するに、

建築知識の特集号で4万部、商用CADベンダーが業界団体で警戒会議を開くレベル。
DOS時代から30年以上、日本の建築設計事務所の標準ツールとして君臨し続けている。

商用CADは有料 + Windows必須 + 機能てんこ盛りで、中小には荷が重かった。
そこにフリー + 軽快 + 日本語完璧のJw_cadが来て、気がついたら業界中に広まってた——というのが90年代〜00年代に実務やってた人の肌感覚です。

つまりこういうことです。

日本の建築実務に蓄積された30年分・数百万・数千万ファイルのJWW図面が、AI時代に取り残されている。

弊社1社だけでも、サーバーに十数万ファイル / 1TB弱の歴代JWWが眠ってます。
これ、絶対に宝の山でしょ。

🌪️ 第2章：世界のCAD vs 孤島の国産CAD

ざっくり整理しときます（2026年現在）。

プレイヤー	フォーマット	AI対応状況
Autodesk (AutoCAD)	DXF/DWG	Copilot系・LLM連携あり
Dassault (SolidWorks)	SLDPRT	生成AI機能搭載
Siemens (Solid Edge)	par/asm	図面ビュー80%自動生成
Bentley	DGN	BIM連携
Jw_cad（日本）	JWW	なし

世界はAI x CADで「3Dモデルから2D図面を80%自動生成」みたいな次元に入ってるのに、Jw_cadは「外部変形をPythonで書いてみる」で止まってる。

別に国産CADを馬鹿にしたいわけじゃありません。むしろ逆で、

完全無料
30年メンテされ続けてる
動作が爆速
日本の建築設計文化に最適化されてる

こんなソフトはJw_cad以外に存在しません。愛してます。

ただね、AI時代に「フォーマットがブラックボックス」だと、未来の自動化に乗れないんですよ。
じゃあ誰がやるの？

→ オジサンがClaudeに頼んでやらせます。

⚙️ 第3章：JWWバイナリ完全リバエンの旅（地獄）

3-1. まず「マジックナンバー」を見る

with open("plan.jww", "rb") as f:
    print(f.read(8))  # → b'JwwData.'

うんうん、ここまでは余裕。次の4バイトがバージョン（700 = Ver7.02）。
さあ、ここから地獄の入り口です。

3-2. 正体は MFC CArchive シリアライズ

JWWは、Visual C++のMFC CArchiveでオブジェクトを直列化したバイナリです。
…と書くとかっこいいですが、要は

Microsoftが90年代に作った独自オブジェクト保存形式

です。仕様はMFC TN002に書いてあります。

ポイントは2つ：

クラス初出時：FFFF + schema(WORD) + namelen(WORD) + classname を吐く
既出クラス：WORD(0x8000 | classIndex) で参照（圧縮）

つまり、ファイル中盤で 81 00 というバイト列に出くわしたとき、それは「クラスID=1のオブジェクトが始まるよ」という意味なんです。
気付くまで3週間かかりました。

3-3. CData基底クラスは15バイト固定

DWORD m_lGroup       // 曲線属性 (4)
BYTE  m_nPenStyle    // 線種     (1)
WORD  m_nPenColor    // 線色     (2)
WORD  m_nPenWidth    // 線幅     (2)  ← Ver3.51以降
WORD  m_nLayer       // レイヤ   (2)
WORD  m_nGLayer      // Gレイヤ  (2)
WORD  m_sFlg         // 属性Flg  (2)
                    -----------
                     合計 15 bytes

これが全エンティティの先頭にくっついてる共通ヘッダ。
線分も、テキストも、円も、全員これを背負ってる。

3-4. エンティティ別バイト構造

CData(15) のあとに、型ごとの本体が続きます。

型	クラス	本体サイズ	中身
線分	CDataSen	+32 (double×4)	始点(x,y) → 終点(x,y)
テキスト	CDataMoji	可変	座標+ﾌｫﾝﾄ+文字列(CString)
円・弧	CDataEnko	+60	中心+半径+角度+扁平率
点	CDataTen	+20〜	座標+種別
Solid（塗り）	CDataSolid	+64〜	4頂点+色
ブロック参照	CDataBlock	+44	挿入点+回転+倍率+ID
寸法	CDataSunpou	234B SXF拡張あり	引出線+寸法値+補助点

3-5. 一番苦しんだやつ — CDataSunpou（寸法）

寸法線、これマジで地獄でした。

最初は「親CDataの先のWORDがSXFモード判定」と思ってたんですが、全然違った。

正解：

親CDataの flags & 0x2000 == 0x2000  →  SXF拡張234バイト追加

親のflagsの上位ビットでスイッチが入るんです。
しかも実データの99%でこのフラグが立ってて、234バイトのスロット領域はほぼゼロ埋め。
「なんで使ってないのに常に予約してるんや…！」

ユーザーが手作りした最小寸法サンプル（dim_real.jww、18,110バイト）を1バイトずつ目視で追ってようやく確定。
弊社の本番ファイル（90万バイト超）でもバイト完全一致のラウンドトリップ達成。

3-6. もう一個の魔境 — CDataList（図形登録）

「図形登録」（Ctrl+B）で作られる入れ子コンテナ。
148バイトの最小サンプル block1.jww を作って解析した結果：

[NewClassTag] FF FF + schema(0x02bc) + "CDataList"
[CData      ] 15バイト共通ヘッダ
[meta       ] 12バイト（先頭8固定 + 後ろDWORDがJw_cad発番のユニークID）
[CString    ] "<名前>@@SfigorgFlag@@<ver>" のSJIS or Unicode
[子リスト   ] 再帰的にCArchive
[画像      ] (任意) 128B固定パス + DWORDサイズ + gzipストリーム

弊社の共通テンプレート7件にはJPEG画像がgzip圧縮で埋め込まれてることまで判明。
こういうの、普通のCAD屋は一生気付かない。

📊 第4章：実測 99.91% — ベンチマークぶん回した結果

完成した jww_full_parser.py（約1,300行）でテスト。

環境	サンプル	結果
Windows社内アーカイブ	約7,000 JWW	OK 99.9%（PARTIAL 2件 / EXCEPT 4件のみ）= 99.91%
Spark本番ストレージ	十数万 JWW (1TB弱)	CDataHensuu出現0件、副CDataList nested 0件

PARTIAL 2件は末尾の未知PIDが1個漏れるだけ（実害なし）、EXCEPT 4件はそもそも拡張子を間違えてjww保存されたJWC形式のファイルでした。

※ 検証対象は弊社が業務で扱った Ver7.x 系中心の実JWWアーカイブです。
Ver10系・特殊データ・他社固有データでは別途検証が要ります。

つまり、

弊社データセット上では、JWWパーサは実用段階に到達しています。

公開情報を見る限り、実務規模でここまで検証されたPython製のJWWパーサーは見当たらないところまで来ました。

⚖️ Jw_cad利用規約と本記事の立ち位置（重要）

ここ、正直に書いておきます。

Jw_cad には公式の利用規約（Jw_win.txt 同梱、公式HP 配布版に常時添付）があり、要点はこうです：

Copyright (C) 1997-2026 Jiro Shimizu & Yoshifumi Tanaka

プログラム本体の改変・修正版配布は禁止

会社・雑誌等への寄稿は事前に相談

サンプルデータ・動作画面を有償配布する場合は事前相談

CADソフトの紹介で使用する場合、規約内容を併記して配布

弊社の活動が規約と抵触するか？

弊社のやってること	規約への該当
Jw_cad本体の改変	してない（解析対象は出力された`.jww`ファイルのみ）
修正版Jw_cadの配布	してない
Pythonパーサ・ライターの開発	規約は本体改変・配布を禁止しているのみで、第三者ファイルフォーマット実装を禁じていない
動作画面の引用	本記事には未掲載

つまり、規約上の地雷は踏んでないと考えています。

補足： ファイルフォーマットのリバースエンジニアリング自体は、
文化庁資料でも著作権法30条の4（調査解析目的の非享受利用）
に該当し得ると整理されています。
ただし公開範囲・公開方法は別問題なので、本記事は仕様の核心部分・writer実装の詳細は伏せ、
思想・成果・安全設計の話に絞っています。

🌟 第5章：まさかの「3D機能」まで完全解明

ここからが今回イチの新発見です。

Jw_cadには**ほとんど誰も使ってない「3D機能」**ってのがあります。
平面図に「高さラベル」を貼ると、3Dビューワで立ち上がるやつ。

これ、仕様書にも書いてない。ググっても使い方の解説しか出てこない。
でも、データを目視で追ってたら、ある特殊なパターンを発見してしまったんです。

3D高さラベルの正体

flags(m_sFlg) = 0x8000   # ← これが3D識別マーカー！
moji_shu      = 0        # （普通の文字は1）
pen_color     = 5        # 青固定
text          = "10 , 0" # 「上端m , 下端m」

普通のテキストとビット1個違いだけで「これは3D高さや」とJw_cadが判別してる。

配置ルールも逆解析

図形	高さラベル位置	個数	angle
多角形	各頂点	頂点数	入線方向+180°
円	中心	1個	0

しかもバイナリの書き出し順序まで関係してて、Sen → Moji → Enko の順でクラス初出にしないと3D変換が走らない。
こんなのドキュメントどこにも書いてない。

結果：Claudeが3Dタワー描けるようになった

w = JwwSmartWriter("3d-01.jww")
w.add_3d_polygon([(0,0),(10,0),(10,10),(0,10)], top=10, bottom=0)  # 壁
w.add_3d_circle(20, 0, 3, top=15, bottom=0)                        # 円柱
w.save("claude_tower.jww")

これ書いて保存して、Jw_cadの3Dビューを開いたら…ちゃんと立体物が立ち上がりました。
夜中に1人で「やった！！！！」って叫んだのは内緒です。

🔄 第6章：JWW ⇄ IR ⇄ AI ⇄ JWW — 「翻訳機」の話

ここ、本記事で一番大事なところなので、ちょっと丁寧に書きます。

なぜ「IR」を挟むのか

率直に言って、LLMにバイナリは絶対に触らせちゃダメです。

「AIに直接JWWを書かせよう！」って最初はやってみたんですよ。
結果は地獄。1バイトでもズレたらJw_cadが起動時にクラッシュします。
LLMは確率的に文字を吐くので、"JwwData." の '.' を ',' にする事故が1万回に1回起きる。
本番で使えません。

そこでIR (Intermediate Representation = 中間表現) という「人間にもAIにも読めるJSON」を間に挟みます。

[JWWバイナリ] ⇄ from_jww/to_jww ⇄ [IR (JSON)] ⇄ AI編集
   ^機械語           翻訳機           ^高級言語

要は「アセンブリ言語 vs Python」の関係。
バイナリは機械が読む。AIにはJSONでしゃべらせる。
これが、弊社のJWW自動化の根幹アーキテクチャです。

IRの中身（実物）

jww_full_parser.py でJWWを読むと、こんなJSONになります：

{
  "drawing_meta": {
    "scale": 100,
    "paper_size": "A3",
    "writing_layer": {"group": 0, "layer": 3}
  },
  "layers": [
    {"id": "L-00-03", "group": 0, "layer": 3, "name": "外壁", "scale": 100},
    {"id": "L-00-04", "group": 0, "layer": 4, "name": "建具", "scale": 100}
  ],
  "entities": [
    {"kind": "line", "id": "E-0042", "layer_id": "L-00-03",
     "x1": 0, "y1": 0, "x2": 4550, "y2": 0, "pen_color": 1},

    {"kind": "line", "id": "E-0043", "layer_id": "L-00-03",
     "x1": 4550, "y1": 0, "x2": 4550, "y2": 7280, "pen_color": 1,
     "extrude_top": 2.7, "extrude_bottom": 0},

    {"kind": "dim", "id": "E-0099", "layer_id": "L-00-08",
     "p1": [0, -500], "p2": [4550, -500], "text": "4550"},

    {"kind": "text", "id": "E-0150", "layer_id": "L-00-09",
     "x": 1000, "y": 8000, "text": "1階平面図", "size": 5.0},

    {"kind": "block_ref", "id": "E-0200", "block_name": "block_3",
     "insert": [3000, 4000], "rotation": 90, "scale_x": 1.0, "scale_y": 1.0}
  ],
  "drafting_objects": [
    {"kind": "hatch_area", "lines": ["E-0301","E-0302",...],
     "spacing": 0.475, "angle": 45.0}
  ]
}

これならAIに見せても怖くない。
LLMがちょっと変なこと書いても、JSONバリデータが弾いてバイナリにまで波及しない。

JWW → IR の変換

イメージはこんな感じ：

ir = jww_to_ir("plan_v23.jww")
# → 線分: 1247本 / 寸法: 149件 / レイヤ: 16枚

内製パーサーで、バイナリの全エンティティ + 3D高さ情報 + ハッチ領域の自動認識まで全部JSONにします。

AIがIRを編集する（ここが本題）

たとえばClaudeにこう言うわけです。

「2階南面の掃き出し窓W1800を、避難上有効を満たすためにW2400に拡張して」

Claudeが返してくるのは、IRに対するパッチ（差分）：

{
  "ops": [
    {"op": "modify", "id": "E-0457", "set": {"x2": 8400}},
    {"op": "modify", "id": "E-0458", "set": {"x1": 8400}},
    {"op": "modify", "id": "E-0512", "set": {"text": "2400", "p2": [8400, -500]}},
    {"op": "add", "kind": "line", "layer_id": "L-00-03",
     "x1": 6000, "y1": 1500, "x2": 8400, "y2": 1500, "pen_color": 1}
  ],
  "rationale": "建具W1800→W2400に拡張。寸法線とサッシ枠線を連動修正。"
}

これをパッチ適用エンジンに食わせると、JSONレベルで安全に編集されます。
バイナリの破壊リスクゼロ。

IR → JWW に書き戻す

ir_to_jww(ir_new, "plan_v24.jww", template="plan_v23.jww")

内製ライターで、JSONを正確なJWWバイナリに復元します。
テンプレート方式（pass-through）で、触ってないエンティティは1バイトも変わらない。
触ったエンティティだけ正しく置き換わる。

ラウンドトリップ検証（3段階の品質保証）

弊社は JWW → IR → JWW のRTを3段階で評価してます。

段階	何を見るか	なぜ必要か
① バイト一致	出力JWWが入力と1バイトでも違わないか	副本管理・差分管理で同一性が崩れないため
② 意味一致	エンティティ数・座標・属性が論理的に等価か	バイト差はあるが図面として同じを保証
③ 視覚一致	Jw_cadで開いて目視・PNG diff	人間が見て同じことの最終チェック

実測（①バイト一致）：

検証ファイル	サイズ	結果
dim_real.jww（最小寸法）	18,110B	バイト完全一致
block1.jww（最小ブロック）	148B	バイト完全一致
本番物件サンプル	904,981B	バイト完全一致（dim 130件 + List 2件）
MASTERPIECE_pagoda.jww	大型	バイト完全一致

JWW→IR→AI編集→JWW のループが、バイト精度で閉じている。

これが、AI図面自動化の最低限の品質保証です。
学術界のCAD生成は「視覚的に近ければOK」が主流ですが、建築設計の図面副本管理ではバイト一致まで要求される——この差が、研究と実務の決定的な分かれ目です。

パイプライン全体図

┌─────────────────────────────────────────────────┐
│ [指摘メール] ＋ [現行JWW]                        │
│        │              │                          │
│        ↓              ↓ パーサー層               │
│ [指示テキスト]   [IR (JSON)]                     │
│        │              │                          │
│        └──────┬───────┘                          │
│               ↓                                  │
│         [Claude / FT済オープンモデル]            │
│               ↓ ← パッチ生成                      │
│         [IR Patch (JSON)]                        │
│               ↓ パッチ適用エンジン               │
│         [新IR]                                   │
│               ↓ ライター層                       │
│         [新JWW]                                  │
│               ↓ Jw_cadで開いて目視               │
│         [副本との差分検証]                        │
│               ↓                                  │
│         [失敗ならFTペア生成 → 次回学習]           │
└─────────────────────────────────────────────────┘

コード規模感

層	役割
パーサー層	JWW読み（バイナリ→IR）
ライター層	JWW書き（IR→バイナリ）
IR定義・差分・パッチ層	中間表現の操作
高次認識層	ハッチ・通り芯・3D高さ等の意味解釈
検証・サンドボックス層	安全実行とラウンドトリップ品質保証
合計	数万行規模、ぜんぶClaudeに書いてもらった

筆者は今でも for ループの書き方を時々ググってます。

📚 コラム：世界の論文と並べてみたら（弊社IR vs 学術界）

「IR挟むのなんて、世界の研究者はとっくにやってんじゃないの？」
そう思って論文を漁ったので、さらっと比較しときます。

学術界の最新CAD×LLM (2024-2025) ざっくり整理

研究	カンファ	やってること	IRの形
Text2CAD	NeurIPS 2024	テキスト→3Dパラメトリック生成	sketch-and-extrude シーケンス
CADFusion	ICML 2025	LLM+ビジュアルフィードバック2段階学習	コマンド列
CAD-Llama	CVPR 2025	LLMでパラメトリック3D生成	自然言語的トークン
CAD-Coder	MIT 2025	CadQueryコード出力	Python code
Drawing2CAD	2025	ベクター図面→CAD、dual-decoder	vector primitive
CAD2Program	2024	2D図面→3Dパラメトリック	テキスト記述
CadVLM	2024	視覚+言語でCADスケッチ生成	スケッチ列
ArchCAD-400K	2025	建築CAD大規模データセット	DXF+アノテーション

そして決定打。**2025年5月のサーベイ論文**にこう書いてある：

"Nearly all approaches utilize LLMs to generate intermediate representations rather than directly outputting 3D CAD models or 2D CAD drawings."
（ほぼ全アプローチがLLMにIRを生成させ、CADを直接吐かせない）

"Common intermediate formats including executable code—such as Python scripts, and parametric data—often structured as JSON files."
（主要IRはPythonスクリプトとJSON）

…世界の研究者と方向性は完全に一致してました。ホッとしました。

じゃあ弊社の独自性はどこ？

観点	学術界の主流	弊社
対象CAD	海外プロ向け3D（Fusion360, Onshape）	JWW (日本2D) ←公開研究では未開拓
IR内容	sketch-and-extrude（3Dの作成手順）	2D全エンティティ + 寸法 + ハッチ + 3D高さ + ブロック + レイヤ + 印刷色 ←実務統合型
データ規模	ArchCAD-400K = 5,538図面	164,188 JWW ←弊社1社で30倍
ユースケース	text-to-CAD（ゼロから生成）	既存図面の編集パッチ ←実務寄り
品質基準	視覚的に「それっぽい」	バイト完全一致RT必須（実務副本管理）
データ性質	synthetic / 公開データセット	指摘メール↔修正の実ペア ←公開データセットには存在しない

要するに、学術界は「3D CAD + 海外フォーマット + ゼロ生成」で攻めてて、
弊社は「2D JWW + 日本実務 + 編集パッチ」で学術界が誰もやらない隙間を埋めてる感じ。

一致してて嬉しかったこと

「IRはJSON/Python code」で世界共通結論 → 弊社の方向性は正しかった
「LLMに直接バイナリ書かせない」も世界共通 → 一人で気付いた弊社えらい
「視覚フィードバックループ」（CADFusion方式）も弊社で実装中（生成→Jw_cadで開く→差分→再学習）

違ってて面白かったこと

学術界のIRは**生成プロセス（どう作ったか）を残す。弊社IRは結果（何があるか）**を残す
- 学術: 「半径10mmの円を中心(0,0)に押し出して厚さ5mmの円柱」
- 弊社: 「kind=line, x1=0, y1=0, x2=4550, y2=0」
- 理由: 弊社は既存図面の編集が主目的なので、過去の作成手順は不要。LLMに見せるのは「現状」だけでいい
学術界の「バイト一致」は誰も気にしてない（3Dなら見た目で合えばOK）
- 弊社は建築設計の正式な図面副本を扱うため、1バイトでも違うと副本管理・差分管理上の同一性確認が困難になる
- これがバイト完全一致RTにこだわる理由

結論

学術界の最先端は「IRを介す」ことに収束しつつある（2025年5月サーベイ時点）。
弊社は同じ結論に、論文を読まずに実務側からたどり着いた。
しかも対象が JWW という、公開研究では手薄な領域。

論文1本書ける気がしてきました（書く時間ない）。
研究者の方、共同研究のお声がけ歓迎です。

🌞 第7章：今まさに作ってる「天空率図面の完全自動生成」

ここまでが基盤の話。
実は今、この基盤の上で動かしてる本番案件があるので、書いちゃいます。

天空率って知ってます？

建築実務者じゃない方向けに30秒で説明：

「うちの建物が空をどれだけ覆ってるか」を計算して、
斜線制限よりも「空の見え方」で建ぺいOK/NGを判断する制度（建築基準法施行令135条の5〜11）

道路斜線・隣地斜線・北側斜線がアウトでも、
「この建物のせいで失われる空の量は、斜線通りに建てた建物より少ないですよ」
と数値で証明できれば建築OKになる、設計者の最後の救済措置。

ただし計算が狂気的に面倒で、

算定位置を何十箇所も選定
各位置から半球を正射影して天空図を描く
計画建物の頂点を全部投影して三角形分割
適合建築物（斜線通り建てた仮想建物）と数値比較
これを4方向 × 数十位置 × 種別ごとにやる

普通は専用ソフト（10万円〜数十万円）使うか、
建築士が3日くらい徹夜して図面起こします。

じゃあAIにやらせる

「現状の図面一式（PDF）と配置図JWW」だけ与えて、
17ページ構成の天空率図面一式を全部自動生成するパイプライン、作りました。

実証物件：某住宅案件A（取引先ハウスメーカー様、案件詳細は伏せます）

パイプラインの大枠はこんな流れです（個別モジュール名は伏せます）：

[配置図JWW]
    ↓ 抽出層
[敷地ポリゴン + 建物ポリゴン + 道路境界 + 道路幅員 (JSON)]
    ↓ 計算層（建築基準法施行令135条の5準拠）
[天空率の正射影方式による数値計算]
    ↓ 適合建築物層
[道路斜線/隣地斜線/北側斜線の適合多面体生成]
    ↓ 図面合成層 (第6章のIR層を経由)
[20 JWW + 20 PNG 一式 (17ページ相当)]

法令準拠の計算エンジン

設計のポイントだけ：

天空率 (Sky Factor) は、建築基準法施行令第135条の5 〜第135条の11 に基づき、
半球を地表面に正射影した面積比で定義される。
（立体角方式 = sr/2π とは値が異なる点に注意）

弊社実装ではモンテカルロ系のサンプリング法と三角形分割法を併用し、
サンプル数を上げると誤差±0.1%程度まで収束。

天空率をWEB検索させて基本事項を学び、Claudeと一緒に実装しました。
正射影方式と立体角方式の違いとか、普通の人は一生気にしない話を延々と詰めてます。

誤差検証: サンプル数を増やすと誤差は±0.1%程度に収束。
某住宅案件Aの最不利差は+1.73%なので、サンプリング誤差より十分大きい余裕があります。
ただし丸め規則・適合多面体の離散化精度は専用ソフト（ADS-LAX等）との突合が今後の課題です。

某住宅案件A 実測値（具体数値はダミー化しています）

入力イメージ：

項目	値
敷地形状	多角形 / おおむね150m²前後
建物	多頂点L字 / おおむね50m²前後
道路境界	複数辺、道路幅員4m前後
隣地境界	1辺
建物高さ	7m弱

これを食わせると、自動で天空率が出ます（数値はイメージ、桁感を伝える目的）：

種別	計画(%)	適合(%)	差(%)	判定
道路斜線(東)	約92	約90	+1〜2	OK ★最厳
道路斜線(南)	約93	約90	+3前後	OK
道路斜線(西)	約96	約90	+6前後	OK
北側斜線	約83	約78	+5前後	OK
隣地斜線(北)	約97	約89	+8前後	OK

全箇所適合。設計通り建ててOKです。

出力される図面（20枚）

パイプラインを1回叩くと、出力フォルダに作図・検算支援として実用圏のJWW + PNGが20枚吐かれます（最終提出図面は人間の目視＋専用ソフトでの再検証が必須）：

01_詳細配置図.jww
02_立面図.jww（北/南/東/西の4面、L字建物投影）
03_アイソノメ図.jww（計画L字 + 3道路斜線適合多面体）
04_求積図.jww（5頂点ペンタゴン扇形分割 + L字建蔽率）
05_計算結果一覧表.jww（全34算定位置）
06-08_道路斜線断面図_南/西/東.jww
09_隣地斜線断面図_北.jww
10_北側斜線断面図.jww
11-15_最不利天空図.jww（各種別5枚）
16-17c_天空図一覧シート（種別5枚）

これ、人間の建築士が3日かけて作るやつです。
弊社のパイプラインだと約30秒。

今後の精度向上方針

完璧というわけではなく、継続的に精度向上中です。
特に「PDF原本に書かれている計画建物の細かな頂点情報（軒先・屋根勾配・基礎ライン等）をIRに自動反映する」工程は次フェーズの課題。
ここが解決すると、

どんな物件でも、配置図JWW1枚から、作図・検算用の天空率図面17ページが30秒で出てくる世界。
（最終提出図面は人間が目視＋専用ソフトで再検証、というワークフロー）

弊社が今マジでそこに向かってる話でした。

なぜこれが第6章（IR）の上にしか乗らないか

天空率図面って、**「計算」+「図面」**の両方なんです。

計算だけなら：Pythonで書ける
図面だけなら：JWWで描ける
でも「計算結果を、Jw_cadのバイナリに、寸法と注釈つきで埋め込む」ができない

ここで第6章のIR層が効いてきます。

# 計算エンジンが出した結果を、IRに変換
ir["entities"].append({
    "kind": "dim",
    "p1": [0, -500], "p2": [4550, -500],
    "text": "天空率 92.116% > 90.390% OK"
})

# IR → JWW で書き出すだけ
ir_to_jww(ir, "output.jww")

バイナリの心配ゼロで、計算結果が図面化される。
これが「翻訳機を作っておいた」ことの本当の意味です。

💎 第8章：過去のJWW図面は「宝物」になる

ここからが本記事で一番伝えたいことです。

あなたの会社のサーバーにあるJWW、捨てないで

中小工務店・設計事務所の倉庫NASに眠ってる、

20年前の在来工法平面図
図面の修正履歴ぜんぶ
建築設計の指摘メール ↔ 図面修正の対応
物件ごとの「なぜこの寸法にしたか」のメモ

これ、公開データには存在しない、業界固有の暗黙知です。
ArchCAD-400Kは40万チャンク・5,538図面で「大規模」と言われてます。
弊社1社で十数万ファイル規模。日本の中小建築会社の合計を考えたら、ざっくり桁が3つは違う。

なぜ宝物なのか

LLM時代の学習データの価値は、こう変わってます：

種類	価値
Web上のテキスト	だいたい学習済み（飽和）
GitHubのコード	だいたい学習済み（飽和）
業界固有の暗黙知 × 修正履歴	超レア・超高価値

「指摘メール → 図面のここをこう直した」というペアは、人間の建築士の脳内にしかない知識を機械可読にしたものです。
これがあれば、AIは「図面を描く」だけでなく「設計判断する」ことを学べる。

弊社が今やってること

過去案件の指摘メールと図面修正の因果連鎖を構造化
図面差分を修正テキストとペアリングして学習データ化
中規模オープンモデルにこれを食わせてFine-tune
Spark DGX（128GBユニファイドメモリのCUDAマシン）で全部ローカル処理

生データを1バイトも外に出さない、完全社内クローズドAI。
これが地方の建築設計屋がやってる話。狂ってますよね。

🔮 第9章：昔ながらのCADの未来予想

「もう3D BIMの時代だよ、2D CADはオワコン」という声、わかります。
でも現実は…

2D製図の世界では「Jw_cadとAutoCADの併存がしばらく続く」

これが2026年の業界コンセンサス。
特に建築設計・既存改修・小規模リフォームは2Dが死ぬほど現役。

つまりこういう未来になります：

短期（〜2027）

中小工務店向け「JWW読めるAIアシスタント」が乱立
「建築設計支援ボット」が登場（弊社で作ってます）
既存JWW資産のOCR的解析サービスが立ち上がる

中期（〜2030）

JWW → BIM自動変換が実用レベルに（壁・建具・スラブ自動認識）
古い手書き図面・PDF・JWWを横断する「図面検索エンジン」
設計事務所の過去図面が業務改善の重要な学習資源として再評価される時代へ

長期（〜2035）

「図面を描く」職能が消滅、建築士は「指示を出す」職能に
Jw_cadの新規利用者は減るが、過去資産の活用価値は爆増
30年蓄積したJWWを廃棄せず活かしきった会社が勝ち組になる

…と、ここまで書いて読み返すと完全にポジショントークですが、
実際そう思ってます。過去の遺産は、AI時代の油田です。

⚡ 第10章：今回の新発見の手触り

弊社のリバエン旅で、公開情報では見当たらない発見が大小7つほどありました。

カテゴリだけ書くと：

寸法エンティティの拡張仕様判定の方法
3D機能の識別マーカー仕様
ブロック登録コンテナのメタ情報構造
各種テーブル（レイヤ・色・線種など）の物理レイアウト
エンティティ追加時のID整合性ルール
仕様書記載と実データの乖離（幽霊仕様の存在）

バイト単位の具体仕様は本記事では伏せます。
ただし、Jw_cad公式ドキュメントには載っていない挙動が実用上のカギになっている、という事実だけお伝えしておきます。

🎯 終章：「読めない」を「読める」にする話

毎回シリーズで書いてることですが、

AIに業務を任せる第一歩は、「データを読めるようにする」こと。

DXFが読めなければ自動チェックできない（第1話）。
標高データが読めなければ雨水経路は引けない（第2話）。
専門書が読めなければ構造計算ツールは作れない（第3話）。

そして今回。JWWが読めなければ、日本の建築AIは始まらない。

世の中のAIサービスは「英語の論文」「米国の判例」「GitHubのコード」みたいな読めるデータから先に賢くなりました。
日本の建築業界は、肝心の図面が読めないバイナリで30年閉じ込められてた。

その鍵を1つ作った話でした。

📦 おまけ：使った技術スタック

Claude Code (Opus 4.7 1M context) ← 主力。バイナリリバエンの相棒
paramiko ← Windows ↔ DGX Spark のSSH橋渡し
Cython ← jww_full_parserをCで再ビルド（10倍速）
Jw_cad本体 ← 動作確認の絶対基準
MFC TN002仕様書 ← 90年代Microsoftの遺産
JinkiKeikaku/JwwExchange ← C++参考実装に大感謝（Unlicense / パブリックドメイン同等）。バイナリ構造の理解で何度も助けられました。作者のJinkiKeikaku氏に深謝

🙏 最後に

東海地区の小さな建築設計事務所が、Spark DGX 1台と、社内に20年分の図面と、AIに無茶振りしまくる社長で、ここまで来ました。

「読めない技術」を「読める技術」に変える。
過去の遺産を、未来の油田に変える。

それが、地方の建築設計屋がClaudeとやってることです。

次回もお楽しみに。

タグ: Python, JwCAD, JWW, 建築, リバースエンジニアリング, バイナリ解析, Claude, AI, 個人開発, BIM