東海地区で建築設計事務所を経営している建築士です。
ChatGPT/Claudeに業務をブッ込みまくる「コード書けない開発者」やってます。
▼ これまでのあらすじ（第1〜6話の超ザックリまとめ）
- 第1話：野良DXFを3秒で解析する爆速ツール
- 第2話：Google Maps上で「雨水の流下経路」を1クリック追跡
- 第3話：無料枠で200MB/500p専門書をMarkdown化
- 第4話：30年眠っていた国産CAD「Jw_cad」のバイナリを99.91%リバエンしたら、AIが図面を描き始めた話
- 第5話：Pythonで完動した30年もの国産CADパーサーを、こんどはRustで“育て直す”話（ロードマップ編）
- 第6話：当初12ヶ月計画が約24時間で19週間分進んだ話（実測ベンチ編、本日と同時公開）
…と、ずっと同じ流れで書き続けています。
そして今日。
**今回の記事は、本編（第6話）と並行して書いている、ちょっと毛色の違う「番外編」**です。
本編で「実測どうなった」を書くなら、こっちの記事は「そもそも何を作ってるのか、外から見てどう見えるのか」を整理する記事。
完全に自分の頭の整理でもあります。
🤔 「これ、思ったより世の中に存在していないのでは？」
開発を進めながら、最近こう感じるようになりました。
弊社、ずっと「やりたいことを限定して実装してるだけ」のつもりでした。
- 建築設計の効率化したい
- JWW（30年前の国産2D CAD）が読めるとAIが活きる
- AIに図面を編集してもらいたい
- 重い処理は Rust に逃がしたい
- 図面の編集履歴を残したい
- 社内の他言語ツールからも叩けるようにしたい
- ローカルAI（オンプレ推論サーバ）と繋ぎたい
…ただの自社業務改善のつもりだったんです。
でも先日、Claudeに
「弊社が今やってる開発って、外から見るとどう見える？」
と雑に聞いてみたら、（Claudeは調子いいこと言うので話半分ぐらいでいつも聞く様にしています）
「同じ構成、世界的にもあまり例が見当たらないかもしれません」
と返ってきて、ちょっとビビりました。
弊社は単に「実務に必要なものを順番に作ってるだけ」のつもりだったので。
この記事は、その**「珍しさ」を、自分の頭の整理を兼ねて棚卸し**した話です。
そこら辺、自分ではよくわからないので、Claudeと一緒に客観視してみました。
📍 第1章：まず、弊社が今いる場所を整理する
「珍しい」と言うなら、実装が動いてる証拠を先に出すのが筋なので、最新の実測値を並べておきます。
詳細は本編（第6話）に書くので、ここはざっくりだけ。
直近約24時間で起きたこと（2026年5月5日 夕方〜5月6日 夕方）
| 出来事 | 実績 |
|---|---|
| Pythonで動いていた既存資産を、Rust側のコア層に移植 | 99.79% byte-exact 一致（144,115 / 144,414件） |
| Pythonから Rust を呼ぶ実測速度 | Python 3.11ms → Rust 0.26ms（12.17×） |
| 同じIRを持ち回して複数回処理する場合 | さらに 12.88× 高速化 |
| 既存Pythonテスト群との互換性 | drop-in 19/19 full match |
| 統合テストハーネス | 539件中 536件PASS、リグレ ゼロ |
| 完全往復ループ（バイナリ→IR→編集→バイナリ） | end-to-end で 81,753 byte の JWW を出力成功 |
| 編集履歴データベース層（イベントログ） | 実装完了、100万OP実機ベンチで2.6分 |
| 他言語から叩けるサーバ層 | gRPCサーバ稼働、7サービス41 RPC配線済 |
| ローカルAI推論サーバとの接続 | 稼働中 |
| 全テスト件数 | 220 / 220 PASS |
| 当初12ヶ月計画のうち消化した分 | 約19週間分 |
| 累計セッション時間 | 約24時間 |
…と、**「目論見」じゃなくて「実測」**でこの数字が出てます。
詳細は本編（第6話）で書くので、ここはざっくりだけ。
弊社が今いる場所は、ざっくりこういう状態です：
「JWWを読んで、IRに変換して、AIが編集して、JWWに戻す」
「全編集を履歴として永久保存し、いつでも任意の時点に戻せる」
「全部 gRPC 経由で、他言語からも、ローカルAIからも、叩ける」
これが Python と Rust の両方で動き、互換性も実測で証明されている。
ここまで来てから、ふと**「これ、世の中にあるのか？」**と思って整理し始めたのが、今回の記事です。
🌳 第2章：要素を分解すると、それぞれは「普通」
最初に整理して安心したのは、
「弊社、別に魔法を使ってない」
という事実でした。
弊社が使ってる要素を分解すると、こうなります。
| 分類 | 世の中での扱い |
|---|---|
| Web業務システム | 大量にある |
| AIチャット | 大量にある |
| OCR | 多い |
| CADビューア | 多い |
| CAD変換ツール | 多い |
| BIM/CADソフト | 多い |
| Rust製サーバー | 多い |
| gRPC で他言語連携 | 多い（マイクロサービスの定番） |
| 中間表現（IR）でデータを表す発想 | 多い（コンパイラの世界では基礎） |
| バイナリリバースエンジニアリング | やってる人はいる |
| LLMにファイルを編集させる | 増えてきてる |
| event sourcing（履歴を全部残す設計） | 多い（決済・金融で定番） |
| ローカルAI（オンプレ推論サーバ）運用 | 増えてきてる |
| Python→Rust移植 | 増えてきてる |
…全部、それぞれは普通。
正直、この表を見たとき、
「あれ？じゃあ別に珍しくないのでは？」
と思いました。
🎯 第3章：でも組み合わせると、急に類例が消える
ところが、全部組み合わせるとどうなるかを整理してみたら、景色が変わりました。
弊社が今やってる組み合わせ：
| 要素 | 弊社の現状 |
|---|---|
| JWW互換 | 30年前の国産2D CADバイナリを、実務レベルで読める・書ける |
| byte-exact検証 | 全国の実物図面 14万件以上で 99.79% バイト一致を実測 |
| IR化 | AIが扱える中間表現に変換、proto で言語横断 |
| AI編集 | 図面を「線の集合」ではなく「意味の集合」として編集できる |
| event sourcing | 図面変更の全履歴を、append-only で記録 |
| replay / branch | 任意時点に戻せる、分岐できる |
| snapshot / GC | 何十年運用しても容量が爆発しない設計（実機ベンチ済） |
| Rust native化 | 実測 12〜13倍速、完全往復ループ閉鎖済み |
| gRPC server化 | 7サービス41 RPC、他言語から叩ける本番グレードサーバ稼働中 |
| ローカルAI接続 | クラウド外で完結する設計、推論サーバを gRPC 越しに proxy |
ここまで全部同時に揃ってる事例を、自分でも色々調べてみたんですが、
国内・海外問わず、私が見つけられた範囲では類例なし。
「JWWを読める」だけなら、いる。
「JWWに戻せる」だけなら、いる。
「AIに図面を編集させる」だけなら、いる。
「event sourcing でCADを管理する」だけなら、研究レベルで見たことはある。
「Rustで2D CADを書く」だけなら、いる。
「ローカルAIを社内運用する」だけなら、いる。
でも、これ全部 1つの基盤に乗せて、実務データで動いてるものは、自分で探した範囲では見つけられませんでした。
そして、もし本当に存在しないなら、この組み合わせ自体が地味に新規性のあるアーキテクチャになってるかもしれない、と。
🧬 第4章：特に「珍しいかも」と感じる6つのポイント
ここから、個別に何が珍しいのかを、自分なりに分解しました。
4-1. 30年前の国産2D CADにAIを乗せる、というアプローチ
私が見つけられた範囲では、世界のAI CAD研究は、
- 3D CAD（SolidWorks, Fusion 360 系）
- BIM（Revit, ArchiCAD 系）
- 点群（LiDAR データ）
- メッシュ
- Diffusionモデルによる図面生成
…のような、3D寄りまたは生成寄りが中心だと感じます。
一方で、日本の建築実務で何十年も中核を担ってきた JWW という2Dバイナリを、AI編集可能な構造に変換しようとしている事例は、私が探した範囲ではほぼ見当たりません。
これ、実は理由があると思っています。
JWWは、海外ではほぼ知名度がない。
でも国内では、フリーウェアとして圧倒的に普及している。
「世界規模で見るとマイナー、国内では絶対王者」というニッチ。
このニッチに、現代のAI技術と現代のRustエコシステムをぶつけるというアプローチを、フルスタックで実務レベルでやってる人は、たぶんあまりいない。
弊社がたまたまここに突っ込んでるのは、自社の30年蓄積を活用したいという、極めてローカルな動機だからです。
世界中誰もやらなくて、弊社だけやる理由がある、という珍しいポジションに居ることに、最近まで気付いていませんでした。
4-2. 「JWWに戻す」を、byte-exact レベルで成立させる
これは第4話・第5話でも書いた話ですが、改めて。
「JWWを読む」は、世の中に何人もチャレンジしてきた人がいます。
でも、
JWW → IR → AI編集 → JWWに復元 → byte一致
を実務レベルで成立させようとすると、急に難易度が跳ね上がります。
特に問題になるのは、
- 座標誤差（浮動小数点の丸め）
- レイヤ構造（任意の深さの入れ子）
- 寸法（テキスト + 線 + 矢印の意味的束）
- 文字（フォント・回転・配置の独自仕様）
- 古い図面（仕様が拡張される前の名残）
- 実務の癖（建築事務所ごとの暗黙ルール）
弊社は、全国の実物JWW 14万件以上で、99.79%のバイト一致を実測しました。
「ほぼ見た目が同じ」じゃなくて、「ほぼバイトが一致する」
このレベルで戻せると何が嬉しいかと言うと、
- AIが編集した図面を、他のCADソフトに渡しても全く違和感がない
- 既存の業務ワークフロー（保存・送信・印刷）を一切変えずに、AI編集だけ差し込める
- 改ざん検証が可能（バイト単位で diff が取れる）
これ、業務に投入する上で、地味に超重要です。
「速いけど見た目が変わる」では、現場では絶対に使われない。
4-3. CADの世界に「event sourcing」を持ち込んで、しかも実装まで届かせる
これが今回の番外編で一番強調したいポイントかもしれません。
普通のCADソフトは、「現在の状態」だけを保持しています。
ファイルを保存すると、その時点の状態が上書きされる。
でも弊社は、
- すべての編集を append-only ログに記録
- 任意の時点を replayで再現できる
- ある時点から branch を切って別バージョンを試せる
- 長期運用に耐えるよう snapshot + GC で容量制御
…という設計です。
これ、感覚的には、
「図面版 Git」
に近いです。
普通、ここで終わるんです。「設計思想としてはアリですね」で。
でも弊社の場合、今朝の時点でこれが全部動いています。
- イベントログ層は実装完了
- 100万 OPで200ブランチを作って、ガベージコレクションが実機で2.6分で完走
- 編集履歴の任意時点復元、ベンチで W17比 -88.5% 高速化
- 全テスト 220件 PASS
つまり、**「思想」じゃなくて「動くもの」**として存在している状態です。
なぜCADにこれが効くかと言うと、建築設計は、修正・補正・分岐の連続だからです。
- お客さんに3案出す（→ branch）
- 「やっぱり前のバージョンの間取りに戻したい」（→ replay）
- 「この変更、誰がいつなんで入れたの?」（→ ログ参照）
- 「過去10年の図面修正パターンをAIに学習させたい」（→ ログを学習データとして使う）
特に最後がデカい。過去の編集履歴そのものが、AIの学習データになる。
「使えば使うほど、AIが自社の設計判断を覚えていく」
この自己強化ループは、現在状態しか持たない普通のCADでは絶対に作れません。
「履歴を全部残す」という当たり前の決断が、AI時代では超強力な資産に変わる。
4-4. Python → Rust への“段階的”移植戦略
これは開発戦術の話です。
普通、新しいシステムを作る時は、
- 最初から Rust で書く（パフォーマンス重視派）
- ずっと Python で書く（生産性重視派）
の二択になりがちです。
弊社の選択は、第3の道でした。
1. Python で仕様を作る・実務データで叩いて壊す
2. 仕様が固まったところを Rust で固定化・高速化
3. Python と Rust を永久並走させる
これ、やってみてめちゃくちゃ強いです。
Python段階では：
- 試行錯誤の速度が圧倒的に速い
- 14万件の実務データで、想定外の壊れ方を全部発見できる
- 動的型のおかげで、IRスキーマの試行錯誤が早く回る
Rust段階では：
- Python段階で「動くと判明している仕様」だけを移植
- 静的型のおかげで、Claude Codeが書くコードのバグが激減
- 12〜13倍の速度と並列処理を獲得
そして両方が同じproto定義のIRを共有しているので、いつでも両者を行き来できる。
これは「Pythonで動くコードはRustでも書ける」という、ある意味当たり前の事実を、戦術として最大化したアプローチです。
「Python は仕様策定エンジン、Rust は仕様固定化エンジン」
この役割分担、AI時代に本当に効きます。Pythonで Claude が無限に試行錯誤して、決まったところから Rust に降ろしていく。
4-5. 「CADソフト」じゃなくて「設計情報基盤」を作っていた、という気付き
途中から気付いたことです。
弊社が作ってるのは、
「JWWを編集する道具」じゃなくて、「設計情報を、AIが意味付きで扱える空間」
なんだ、と。
つまり、
- 壁
- 部屋
- 寸法
- 建具
- 法規上の制約
- 部材間の関係性
これら全部を保持したまま、AIが編集できる空間を作ろうとしている。
普通の2D CADは、**「線の集合」を扱います。
弊社のシステムは、「意味の集合」**を扱います。
ここが根本的に違う。
「点と線」の世界から「壁と部屋と関係性」の世界へ。
そして、それをgRPCサーバ越しに他言語から叩けるようにすることで、
- Mac / Windows のデスクトップアプリから
- 社内Web UIから
- ローカルAI推論サーバから
- バッチスクリプトから
…何からでも、同じ「設計情報」にアクセスできるようになる。
これは**「CADソフト」というより、「BIMサーバ」や「設計情報の真実のソース（single source of truth）」に近い概念です。
そして、それを1人の建築士の作業環境で**動かしている、というのが妙な話。
4-6. ローカルAIをgRPC越しに繋いで、業務ループを閉じる
最後の項目は、今朝（W19）追加された要素です。
弊社のシステムは、ローカル（オンプレ）に推論サーバを持っています。
これ自体は珍しくないんですが、それをgRPCサービスの一部として正規に組み込んでいるところが、ちょっと珍しいかもしれません。
仕組みを抽象化すると、こうなります：
建築士 → デスクトップアプリ
→ 弊社のgRPCサーバ
→ ローカルAI推論サーバ（heavy reasoning / 画像解析 / embedding）
← gRPCサーバ
← デスクトップアプリ
つまり、AI推論をネットワーク越しのサービスとして抽象化しているので、
- AIをクラウドに変えても
- AIを別モデルに切り替えても
- AIを使わない経路に戻しても
業務側のコードは1行も変わらない。
これ、実は超重要です。なぜなら、
「AIモデルは流行り廃りが激しい。業務システムは10年20年使う。」
この時間軸の違いを吸収する層が必要で、それがgRPC抽象化です。
弊社は、「業務システムにAIを足した」んじゃなくて、「AIをサービス化して業務システムから抽象的に呼べるようにした」。
これが、地味だけど本質的な違いだと思っています。
🧭 第5章：3D AI CAD全盛の時代に、2Dを攻める意味（主観）
ここから先は完全に個人の感想ゾーンです。
世界では今、3D AI CADが大流行です。
- 自動間取り生成（Diffusionで間取り画像を生成）
- 3D化（2D図面から3Dモデルを起こす）
- BIMオートコンプリート
- 点群からの部屋認識
こういう研究、山ほどあります。
でも、ちょっと立ち止まって考えてほしいんです。
建築実務、まだ8割くらいは2Dです。
- 平面図
- 立面図
- 断面図
- 詳細図
- 配置図
- 設備図
…結局、最終成果物は2Dで、お客さんに渡すのも2Dで、役所に出すのも2D。
3Dは中間表現であって、実務の入出力は2Dなんです。
ということは、
「2Dの意味空間を完全制御できれば、3Dはその延長線上にある」
という考え方ができるはず。
世界が3Dに走っている間に、足元の2Dを完全制圧する。
これが意外と勝ち筋なんじゃないか、と弊社は勝手に思っています。
特にJWWのような国内圧倒的シェアの2Dフォーマットは、世界中の研究者が誰も触らないので、ガラパゴス的な独占ポジションを築けます。
これ、地方の中小設計事務所が世界で唯一の専門家になれる、超レアな分野かもしれません。
🤖 第6章：AI時代に変わったこと — 「何を作るべきか」だけが問題になった
最後に、これが今回一番伝えたいことかもしれません。
昔なら、こんなシステムを個人で作るのは不可能でした。
- バイナリリバースエンジニアリング
- 中間表現の設計
- Python実装
- Rust移植
- イベントソーシング設計
- gRPCサーバ実装
- ローカルAI連携
これ、専門の会社が10人くらいのチームで2年かける規模です。
でも今は、
- 実装速度 → Claude Codeが書く
- バグ修正 → Claude Codeが直す
- Rust移植 → Claude Codeが移植する
- 並列化 → Claude Codeが並列化する
- API設計 → Claude Codeが設計する
- ドキュメント → Claude Codeが書く
…全部 AI がやってくれる。
その代わり、人間の役割は何かというと、
「何を作るべきか」を決めること、ただ一つ。
弊社の場合、それは**「自社の30年蓄積を、AI時代に活かしたい」という業務側の目的意識**でした。
そしてもう一つ、人間にしかできないことが、業務知識。
- 建築確認申請のフロー
- JWWファイルの実務運用パターン
- 設計事務所での図面の使われ方
- 建築士の判断基準
これはClaude が訓練データから学んだ一般論ではなく、現場で20年やってきた人にしか分からない暗黙知です。
この暗黙知を Claude に翻訳して伝えるのが、今の弊社の主な仕事になっています。
「コード書けないオジサン」が、「業務知識をClaudeに翻訳する役」に変わった。
これが2026年5月の現実です。
🌅 まとめ：番外編として整理すると、こうなる
弊社が今作っているものは、
「JWW互換 AI-CADエンジン」
というより、
「AI時代の、建築設計情報の基盤」
に近づいている気がしています。
そして、この組み合わせ：
- JWW（30年前の国産2Dバイナリ）
- AI（LLM + VL）
- IR（言語横断の中間表現）
- Rust（高速化と安全性）
- event sourcing（図面版Git）
- gRPC（他言語連携）
- ローカルAI（オンプレ推論）
これら全部を統合した実装が動いている事例は、私が探した範囲では見つけられませんでした。
弊社がたまたま地方の小さな建築設計事務所として、自社業務改善の延長で踏み込んだら、誰もやってない領域に入っていた、という話です。
開発はまだ途中（R-5 GPUレンダ、R-6 GUI統合、R-7 CRDT が残っています）ですが、ここまでの段階で、
- JWW byte一致 99.79%
- 速度 12〜13倍
- イベントソーシング層 1Mオペで2.6分
- gRPCサーバ7サービス稼働
- 全220テスト緑
- 当初12ヶ月計画 → 約24時間で19週間分
…の実装が動いている、という地点に居ます。
「ただのCAD開発」だと思っていたら、いつの間にか「AI時代の設計情報基盤」を作っていた。
これが、今回の番外編で言いたいことの全てです。
本編（第6話）では、この実測値の詳細と、開発プロセスのリアルを書きます。
そちらと併せて読んでもらえると嬉しいです。
📦 おまけ：使った技術スタック（ぼかしver）
- Claude Code (Opus 4.7、1M context) ← 主力。設計から実装まで全部
- Python 3.11 ← 仕様策定 + 実験 + 業務既存資産
- Rust 安定版 ← 高速化 + 並列化 + サーバ実装
- Protocol Buffers ← Python ⇄ Rust の IR 互換レイヤ
- gRPC ← 他言語連携サーバ
- イベントソーシング自前実装 ← 図面版Git
- PyO3 + maturin ← Python から Rust を呼ぶ層
- ローカルAI推論サーバ ← heavy reasoning / 画像解析 / embedding（具体構成は伏せ）
- MacBook Air M5 ← 開発機
- Linux ARM64 サーバ ← ベンチ + 実運用環境
具体的な crate 名・サーバ実装・ポート構成・モデル名は、戦略上の理由で伏せます。
ただ、全部 OSS の組み合わせで実現可能な範囲の技術選定です。
🙏 最後に
東海地区の小さな建築設計事務所が、
1人の建築士と Claude Code だけで、
**世界に類例の少ないらしい「設計情報基盤」**を、
約24時間で19週間分作り進めています。
私自身、自分が何を作っているか、ちゃんと分かっていなかった節があります。
今回、Claudeと一緒に俯瞰してみて、ようやく**「これは普通じゃないかも」**と気付いた、というのが正直なところ。
何を作っているか分からないまま、結果として未踏領域に居る。
これもAI時代の、ちょっと変わった開発スタイルかもしれません。
次回（本編・第6話）は、この「珍しさ」を支える実測値の詳細を書きます。
お楽しみに。
タグ: Rust, Python, Claude, ClaudeCode, JWW, 建築, CAD, BIM, AI, 個人開発, gRPC, EventSourcing, リバースエンジニアリング