東海地区で建築設計事務所を経営している建築士です。
ChatGPT/Claudeに業務をブッ込みまくる「コード書けない開発者」やってます。
▼ 前回までのあらすじ
- 第1話：【建築士×ChatGPT】野良DXFを3秒で解析する爆速ツール
- 第2話：【建築士×GIS】Google Maps上で「雨水の流下経路」を1クリック追跡
- 第3話：【建築士×Gemini】無料枠で200MB/500p専門書をMarkdown化
- 第4話：【建築士×Claude】30年眠っていた国産CAD「Jw_cad」のバイナリを99.91%リバエンしたら、AIが図面を描き始めた話 ←これの続編
前回、Pythonで JWW バイナリの 99.91% リバエンに到達しました。
JWW ⇄ IR(JSON) ⇄ AI ⇄ JWW の翻訳ループが、バイト完全一致で閉じてる、と。
普通はここで「完成」で終わりです。
弊社は終わりませんでした。
「これ、Rustで作り直そう。」
…はい。コード書けないオジサンが、社内で動いてる Pythonコード を、1人 + Claude Code で Rustに全面移植する話です。
🤔 第1章：完動してるPythonを、なぜ Rust に書き直すのか
普通、こういうことはやりません。動いてるコードを別言語に書き換えるのは、エンジニア界では「やってはいけないこと」の代表格として有名です（the worst strategic mistake）。
でも弊社は踏み込みました。理由はこれです。
理由1：Python版がデカくなりすぎた
前回の段階で、JWW関連だけで 数万行のPython が動いてます。
そのうえに、
- 天空率の自動図面生成（前回第7章）
- 建築確認申請の自動チェック
- 指摘メール↔図面修正のFT用データ生成
- 過去案件の差分解析（数十万件レベル）
を全部 Python に乗せると、いよいよ重い。
1ファイル何百MB の JWW 群を回すと、1晩で終わらないバッチが出てきました。
理由2：型がないと AI が暴れる
これ、地味だけど超重要です。
LLMコーディングをやってる人は気付いてると思いますが、Pythonの動的型は AI に書かせたコードのバグを生みやすい。
「dict のキーがある時はこの型、ない時は None」みたいな多態を、Claudeが時々間違えます。
Rustの型システムはコンパイル時にこれを完全にブロックしてくれます。
Claudeが書いたコードを Claude 自身がレビューする時の補助輪として、cargo check がめちゃくちゃ効くんです。
理由3：重量バッチに、もう一段の馬力が要る
JWW 数十万件を、
- 一晩で全件パースして
- IRに変換して
- 何かしらの分析を回して
- 図面プレビューを画像に書き出す
…をやろうとすると、現時点のPython実装では一晩で終わらないケースが出始めました。
GIL の影響なのか、I/Oなのか、ホットスポットがどこかも、正直まだ完全には切り分けられていません。
ここは断言を避けます。
Rust版の R-0（PoC フェーズ）で Python 版と同条件のベンチを取って、本当に Rust に乗せ替える価値がある領域がどこかを切り分ける予定です。
記事の続編で、実測値とともに答え合わせします。
理由4：過去資産（30年蓄積したJWW）を、未来100年使う
これがいちばん大きい理由です。
弊社のJWW資産（前回第8章）は 数十年もの間、業務の中核であり続けます。
そのバイナリを翻訳する装置を、Pythonインタプリタに永久依存させていいのか？
答えはノーです。
弊社の30年資産には、OSと一緒に老けない、低レイヤに近い実装が必要。
「翻訳機」を、もう一段、機関車にする。
これが今回のテーマです。
🌉 第2章：それでも Python は残す（永久並走）
「Rustに移すなら、Pythonは消すんでしょ？」
消しません。一生並走させます。
ここ、世間のRustポーティング記事と決定的に違うところなので、しっかり書きます。
並走の役割分担
| 用途 | 言語 |
|---|---|
| インタラクティブな実験 / 単発スクリプト | Python |
| 小規模な日常業務（数件〜数十件のJWW処理） | Python |
| 既存の社内Web UI（Flask） | Python |
| 大規模バッチ（数万件〜数十万件） | Rust |
| GPU/並列が効く重量タスク | Rust |
| 長時間動かすサーバー / 常駐プロセス | Rust |
つまり、
- 使い慣れてて軽い → Python
- クソ重いやつ → Rust
という素直な使い分けです。
両方を同じデータ（Protocol Buffersで定義したIR）の上で動かすので、シームレスに行き来できます。
Python が Rust を呼べるようにする
これも重要。社内には既存のPython資産が大量にあります。
だから、Pythonから直接 Rust の高速パーサーを呼べるようにします。
# 社内の既存スクリプト（Python）
# 中身は Rust だが、Python から見ると普通のモジュール
import jww_core_py as jc
ir = jc.parse_jww("plan_v23.jww") # ← 中身はRust、爆速
これで「Pythonの可読性」と「Rustの速さ」を両取りします。
具体的にどうやってバインディングを作ってるかは伏せますが、Pythonから見たら 100% Pythonに見えるようにラッピングしてます。
IR は両言語で共有
Python版IR の JSON と、Rust版IR の バイナリ（Protocol Buffers）は、
スキーマレベルで完全に一致しています。
// 概念図（実際のフィールドは伏せます）
message IrEntity {
string id = 1;
string layer_id = 2;
oneof kind {
Line line = 10;
Text text = 11;
Arc arc = 12;
// ...
}
}
Python が書き出した IR を Rust が読める。Rust が書き出した IR を Python が読める。完全互換。
これにより、「言語の選択」を「処理の選択」に格下げできます。
重い処理だけ Rust に逃がして、それ以外は Python のまま。
しかもデータは両方が同じものを共有する。
🗺️ 第3章：当初「12ヶ月ロードマップ」を、1人 + AI で回したら、走り出した瞬間に予定が崩れた
「Rustへの全面移植」って、普通だと専任チームを組んで取り組む規模の案件です。
弊社の肌感だと、
- エンジニア5〜10人
- 期間 1〜2年
- 数千万円
くらいのリソースが要る印象でした（あくまで建築設計事務所の社長視点で見積もったオーダー感です）。
弊社の体制：
- 代表（建築士、コード書けない）1人
- Claude Code (Opus 4.7、1Mコンテキスト)
…完。
これでやります。
工数試算（当初の見立て）
設計・実装・テスト・ドキュメントぜんぶ Claude が書いて、
代表は設計判断 + ライブラリ採択承認 + 週次レビューだけ。
| 項目 | 当初の見立て |
|---|---|
| Claude Code セッション数 | 150〜200セッション |
| 代表の累計工数 | 約70時間（月6時間ペース、既存業務の隙間） |
| 期間 | 約12ヶ月（〜2027年2月） |
| 外部人件費 | 0円（Claude Code Maxプランの中で完結） |
これでも普通の建築設計事務所が回せる体力で済む計算でした。
社員を雇う必要がない。これが2026年のソフトウェア開発の現実です。
…と、ここまでは走る前の見立て。
実際に走り出したら、これが想像よりさらに崩れました（後述）。
Phase 構成（当初予定）
12ヶ月を R-0 から R-7 までの8フェーズに分けてます。
ざっくり言うと：
| 段階 | やること（イメージ） | 当初予定期間 |
|---|---|---|
| R-0 | PoC、ベンチ、ライブラリ選定 | 2〜4週 |
| R-1 | コア層（パーサー / IR / 基本変換） | 8週 |
| R-2 | Pythonバインディング（Pythonから呼べるように） | 4週 |
| R-3 | 編集履歴データベース層 | 4週 |
| R-4 | サーバー層（gRPCで他言語からも叩ける） | 4週 |
| R-5 | GPUレンダ層（バッチで何百枚も画像化） | 8週 |
| R-6 | デスクトップビューア（GUI統合） | 8週 |
| R-7 | 多人数編集対応（CRDT） | 4週 |
各 Phase の終わりには 完了報告（RESULT.md） をClaudeが書いて、Dropbox経由で代表に届きます。
代表はそれを週末に読んで「OK」「ここ修正」「次行こう」を返すだけ。
実装・テスト・ドキュメントの初稿作成を、Claudeが大きく肩代わりしてくれる。
代表は方向決めとレビューに集中できる。
もちろん最終確認は人間（代表）の責任で、Claudeの出力をそのまま本番投入することはないです。
公式ドキュメントも、モデル切替時の挙動差や手動検証の重要性を強調しています。
ただ「初稿の95%が AI から出てくる」という事実は、確実に地方の中小企業がAI開発に参入できる時代の象徴になりつつあると感じます。
走り出して、見立てが崩れた話
ここからが今回の本記事を書いてる時点で起きてることです。
弊社、上のロードマップを引いてから、実際に Phase R-0 / R-1 に着手したのが本記事執筆当日の夕方でした。
その日の深夜時点で、R-1 W7（当初予定 2026年6月23日完了）まで完走してました。
時系列で並べると、こうです。
| イベント | 当初予定 | 実績 |
|---|---|---|
| R-0 W2（PoC） | 2026-05-13〜19 | 着手当日に完了 |
| R-1 W3〜W7（コア層の前半） | 2026-05-20〜06-23（約5週間） | 同じ日の深夜に完走 |
| 経過時間 | 約6週間分 | 数時間 |
数字だけ見ると、当初の40〜50倍速で走ったことになります。
もちろんこの倍率は前半フェーズに偏った数字で、
- コア層は既存Python資産の翻訳が中心だから速く出せた
- 後半（GPUレンダ、GUI統合、CRDT）は新規設計と実機検証が増えるので、ここまで速くは進めない
…のは目に見えています。
それを差し引いても、当初の見立てが甘すぎたのは確実なので、Phase設計を改修しました。
改修後ロードマップ（保守的に引き直した最新版）
| 期間 | 完了予定の Phase |
|---|---|
| 〜2026/05/10（今週末） | R-1 完走（コア層クローズ） |
| 〜2026/05/17 | R-2 完了（PyO3 → 既存Python資産が即高速化）★業務即効 |
| 〜2026/05/末 | R-3 完了（編集履歴データベース） |
| 〜2026/06/中旬 | R-4 完了（gRPCサーバー） |
| 〜2026/07/中旬 | R-5 完了（GPUレンダ・実機検証込み） |
| 〜2026/08/中旬 | R-6 完了（デスクトップGUI統合） |
| 〜2026/09/初 | R-7 完了（CRDT） |
当初2027年2月予定の全Phase完了が、2026年9月初に着地する見込み。
約5ヶ月の前倒し。
これもまだ皮算用なので、実際にこの通りいくかは別問題です。
特に R-5（GPU）と R-6（GUI）はMac実機での目視確認が必須で、代表のレビュー帯域がボトルネックになることが目に見えています。
ここで詰まるはずです。綺麗に飛ばせる前提では引いてません。
ただ、それでも社員を1人も雇わずに、5ヶ月前倒しで全Phase完了が射程に入ったというのは、率直に言って自分でも信じられない速さです。
「コード書けないオジサン」が、Claudeと夕飯のあと一緒に座って、半週間分のロードマップを1晩で消化する。
これがいまの2026年5月のリアルです。
📚 第4章：「編集履歴」を Append-only で永久保存する
ここからは、Rust版で初めて実現する新機能の話です。
図面の編集履歴って、いま、どうなってる？
普通の建築設計事務所だと、こんな感じ：
plan_v01.jww
plan_v02.jww
plan_v03_松丸さん指摘反映.jww ← ファイル名で版管理（雑）
plan_v03_松丸さん指摘反映_修正.jww
plan_v03_最終.jww
plan_v03_最終_FIX.jww ← もうカオス
plan_v03_最終_FIX_提出版.jww
Git以前の世界ですね。
で、半年後に「この線、いつ誰がなんで足したの？」って聞かれても、もう誰も覚えてない。
Rust版で何をするか
全編集を、append-only（追記のみ）で永久保存します。
イメージ：
[append-only log]
2026-04-15 10:23:11 patch:0001 add line E-1234 layer=外壁
2026-04-15 10:23:14 patch:0002 modify dim E-1235 text=2400
2026-04-15 10:25:01 patch:0003 delete E-1100
2026-04-15 13:48:22 patch:0042 ai_revision: claude opus 4.7
rationale: 「掃き出し窓を採光基準に合わせて拡張」
changes: [E-0457, E-0458, E-0512]
...
これがあると、
- 「いつ・誰が・なぜ・どこを変えた」が永久に追える
-
任意の時点に戻せる（Gitの
checkout相当） - AIの提案 vs 人間の判断 を全部記録できる
- 過去の修正パターンが、そのまま FT用データになる
最後の項目が一番デカいです。
「指摘メール → AIが提案したパッチ → 人間がOK/NGを判断 → 最終図面」
このループ全体が、勝手に学習データとして蓄積されていく。
つまり使えば使うほど、AIが弊社の設計判断を学ぶ。
実装の中身は競争力に直結するため、保存形式・差分の持ち方・スナップショット条件・ガベージコレクション戦略といった具体は本記事では伏せます。
言えるのは、JWWという独特なバイナリの差分を何十年単位でファイル容量を爆発させずに保持する仕掛けが入っている、ということだけ。
構想としては、Gitに近い思想を、CAD図面というドメインに合わせて作り直したもの、と考えてもらえれば近いです。
🎨 第5章：GPU で図面を「バッチ」で描く
弊社の蔵書（過去案件）は十数万JWW、約1TB。
これを「全件、PNGプレビュー画像に変換」したいとします。
Pythonの matplotlib でこれをやると、1晩で終わりません。
Rust + GPU で何が変わるか
最近の Rust エコシステムには、OS横断で GPU を叩ける描画フレームワークがあります（具体的なライブラリ名は伏せ）。
これを使うと、
- Mac の Metal
- Linux/Windows の Vulkan
- DGX Spark の GB10 GPU
これら全部に同じコードで対応できる。
弊社の主力環境（Mac + DGX Spark）の両方でコードを使い回せるのがデカい。
「ダーティ矩形」で描画コストを最小化
JWW を 1ファイル丸ごと再描画するのは、時間の無駄です。
編集された矩形（dirty rect）だけを再描画して、それ以外はキャッシュを使い回す。
ゲームエンジンのテクニックを、CADビューアに持ち込みます。
これにより、目論見ベース（まだ実測前です）でも以下くらいの差を見込んでます。
| 用途 | Python版（実績） | Rust版（目論見） |
|---|---|---|
| 1ファイルのプレビュー画像生成 | 数秒〜数十秒 | 1秒未満を目指す |
| 100ファイルのPNG一括化 | 数分〜十数分 | 数十秒〜1分台を目指す |
| 数万ファイルの一括プレビュー | 無理（一晩で終わらない） | 数時間に収める想定 |
| インタラクティブ編集中の再描画 | カクつく | 滑らかさを目標 |
R-0/R-5 のベンチが取れたら、実測値で書き直した続編を上げます。
目論見と現実のギャップこそ、後から振り返って一番面白くなる場所だと思ってるので。
🔀 第6章：CRDT で「複数人 × AI」が同じ図面を編集する未来
ここは最終フェーズ（R-7）の話で、現時点ではまだ着手前です。
でも、設計はもう終わってるので構想を書きます。
問題：図面の同時編集って、どうやる？
たとえば、こんなシーン：
- 代表が現場で iPad で図面に指摘を書き込んでる
- 設計士Aが事務所のMacで平面図を修正してる
- Claudeがバックグラウンドで天空率を再計算してパッチを当てようとしてる
3者が、同時に、同じ図面を、編集する。
これ、Google Docs ならできますよね。
でも建築のCAD図面では、普通は無理です。「ファイルロック」「あとがちで上書き」になる。
CRDT を導入する
CRDT（Conflict-free Replicated Data Type）は、Google Docs や Figma のような共同編集を実現する代表的な考え方の一つです。
（実際の Google Docs / Figma の中身は OT (Operational Transformation) など他方式を使っているケースもあり、断定はしません。あくまで「同じ問題領域で広く議論されている方式」の代表選手、くらいの理解です。）
操作の順序が前後しても、最終的に全員の状態が一致するという、不思議なデータ構造。
これを JWW のIR に適用します。
仕組みの詳細は伏せますが、ポイントは：
「Aが線を引く」と「Claudeが寸法を直す」が、ネットワーク的に前後しても、必ず同じ最終図面に収束する。
これが入ると、
- iPad で指摘を書き込んだ瞬間、Mac側にリアルタイム反映
- Claudeの提案が、設計士の手元にPRみたいに飛んでくる
- 全員の編集が、第4章のappend-onlyログに刻まれる
要するに**「図面の Google Docs 化」**です。
建築CAD界隈で、実装に成功してる例は少ないと思います（少なくとも国産2D CADの世界では聞かない）。
🤝 第7章：Claude Codeとの「ペア開発」、本気の手触り
ここからは技術論じゃなくて、1人 + AI で 12ヶ月の大規模開発を回す現実の話です。
代表（人間）の仕事
- 何を作るかの方向決め
- ライブラリ選定の最終承認（「これ使っていい？」に Yes/No）
- 週末に RESULT.md を読んで、次のフェーズを承認
- コーヒーを淹れる（重要）
…ほぼこれだけです。
実装、テスト、ドキュメント、デバッグ、リファクタは全部 Claude。
Claude（AI）の仕事
- 設計（CLAUDE.mdに従って自律的に決める）
- 実装（数千行を一晩で書く）
- テスト（テストコードまで自分で書く）
- 失敗時の自力リカバリ（3回までは自分で直す）
- 完了報告書（RESULT.md）の起票
引き継ぎプロンプト = AIへの遺言
各セッションは独立しています。Claudeは前回の会話を覚えていません。
だから、「引き継ぎプロンプト」というドキュメントを1個用意しておいて、
新セッション起動時にこれをペーストするだけ。
[引き継ぎドキュメント全文をペースト]
今回は R-3 W15（編集履歴ログ層の実装）を進めて。
このプロンプトには、
- 必読のドキュメント順序
- 触っていい / 絶対に触っちゃダメなフォルダ
- 完了時にやること（RESULT.md起票、ntfy通知 等）
- 困った時の対処法
…が全部書いてある。
これを最初に貼るだけで、Claude が**「2人目の自分」みたいに**作業を引き継いでくれます。
AIにとって最も重要なのは、コードでもライブラリでもなく、「ちゃんとした引き継ぎドキュメント」である。
これ、今回の最大の発見かもしれません。
副作用：書類が綺麗になる
代表はドキュメント書くのが昔から大嫌いでした。
でも、Claudeに毎回引き継がせるためには、明文化されたルールが要るんです。
結果、
- CLAUDE.md（プロジェクト規約）
- 引き継ぎプロンプト
- フェーズ別 RESULT.md
- データ配置ガイド
…の整理がガッツリ進みました。
AIに引き継ぐ ≒ 自分の頭の中を文書化する。
経営の継承にも効きそうです。これも別記事で書きたい。
🌅 終章：建築設計事務所が「ソフトウェア会社」になる
前回（第4話）の終わりに、こう書きました。
過去の遺産を、未来の油田に変える。
今回は、その油田から原油を汲み上げる装置を、自分で作る話でした。
- Python版でポンプの試作品を作って、99.91% RT を達成（前回）
- Rust版で製油プラントを組む（今回 / 12ヶ月計画）
1人 + AI で、製油プラントが組める時代。
地方の中小建築設計事務所が、ソフトウェア会社のような技術スタックを持ち始めてる。
これは弊社が異常なんじゃなくて、2026年以降、地方中小企業にも現実的な選択肢になりつつある姿だと感じています。
「コード書けないオジサン」が、Claudeと一緒に、自社専用のソフトウェアを内製する。
しかも、自社の業務知識という他社が持ってないデータをAIに食わせて、独自の競争力にする。
これ、全国津々浦々の中小企業がやれる話です。
弊社が変わってる訳じゃない。先に始めただけ。
次回は、Rust移植の Phase R-2（Pythonバインディング層）あたりが完走したあとに、
「実測ベンチ：Python vs Rust の桁違い世界」と「Append-onlyログが業務をどう変えたか」を書こうと思ってます。
このペースなら、おそらく初夏〜夏ごろには書けるはずです。
📦 おまけ：使った技術スタック（ぼかしver）
- Claude Code (Opus 4.7、1M context) ← 主力。設計から実装まで全部
- Rust 安定版 + cargo workspace ← マルチクレート構成
- Protocol Buffers ← Python ⇄ Rust の IR 互換レイヤ
- Pythonバインディング層 ← 既存Python資産から呼べるように
- GPU描画フレームワーク ← Mac Metal / Linux Vulkan 横断
- GUI統合層 ← Rust製コアを既存GUIフレームワークに乗せる
- CRDT実装 ← R-7で導入予定
- DGX Spark (GB10) ← Linux側のベンチ + バッチ実行環境
- MacBook Air M5 ← 開発機（Metal でGPUデバッグ）
- caffeinate -dims ← Macで長時間ビルドするときの友（マジで重要）
具体的なクレート名・ライブラリ名・PhaseごとのAPI設計は、戦略上の理由で伏せます。
ただ、全部 OSS の組み合わせで実現可能な範囲の技術選定です。
🙏 最後に
東海地区の小さな建築設計事務所が、
1人の建築士と Claude Code だけで、
自社の30年蓄積を未来100年使い切るための装置を、
当初12ヶ月予定 → 9月初完了見込みで作っています。
「読めない技術」を「読める技術」に変える（前回）
「読めるけど遅い」を「読めて速い」に変える（今回）
過去の遺産を、未来の油田に変える。そして油田から原油を汲み上げる装置も、自分で作る。
それが、地方の建築設計屋がClaudeとやってることです。
次回もお楽しみに。
タグ: Rust, Python, Claude, ClaudeCode, JWW, 建築, リバースエンジニアリング, 個人開発, AI, BIM