PDFからベクタ線を取り出してJWWにするところまではできた。
ところが、図面に「2,590」と書いてある寸法をJw_cadで測ると、約2,587 mm。
そこで調べ始めたのは、PDFを作った側の「座標の丸め方」でした。
出力過程のクセと、論文で出会った幾何拘束。その両方から考え直し、最後はJw_cad上で2,590.000 mmに一致しました。
その先に見えてきたのが、公共工事の公告と一緒に、積算に使えるJWWを届ける構想です。
この記事は、前回の「老舗国産CAD、AIで再起動。Rust×iOS×C ABIでiPhoneへ」の続編です。
開発しているアプリはこちらです。
今回は、PDF→CAD変換で残った「数mmのズレ」を追い込み、最後にピッタリ合わせるまでの話です。そして、この変換技術を弊社の公共工事情報サービス Newsatsu と組み合わせると、積算の準備作業をどこまで減らせるのか。その構想まで書きます。
※対象寸法の一致は今回の確認結果です。出力特性の自動推定・図面間での再利用と、Newsatsu連携・JWW配布・数量プレビューは、今後の検証・サービス構想として記載しています。
「変換できた」と思った
PDFの線を取り出し、JWWの線分へ変換する。
最初は、ここまでできれば完成だと思っていました。
実際、画面で見る限りは重なっています。壁も、寸法線も、文字もある。拡大しても、それらしい図面になっています。
ところが、Jw_cadの測定コマンドで寸法を測った瞬間、問題が出ました。
PDFの記載寸法 2,590.00 mm
変換後の測定値 約2,586.57 mm
差 約3.43 mm
見た目では分からない。でもCADで測れば違う。
建築図面を編集・再利用する立場では、この3 mmを見過ごせない場面があります。
- 通り芯に壁が乗らない
- 柱と壁の端点が一致しない
- 910 mmモジュールの連鎖が崩れる
- 求積や寸法の合計に端数が出る
- 後工程の編集でズレが増幅する
閲覧だけでは気づかなくても、端点を合わせて編集する段階では、このズレが手直しの原因になります。
最初に疑ったのは、pt→mmの丸め誤差
PDFの標準ユーザー空間では、1単位は原則として1/72 inchです。Adobeの資料にも、デフォルトのユーザー空間では1 unit = 1/72 inchと説明されています。
参考：Adobe PDF coordinate systems — User space
したがって、縮尺1/100の図面なら実寸への換算係数は次の通りです。
1 pt = 25.4 / 72 mm
縮尺 1/100 の実寸換算係数
= 25.4 / 72 × 100
= 35.277777... mm/pt
「35.28くらいに丸めたからズレたのでは？」
最初はそう考えました。しかし、倍精度浮動小数点で計算しても説明がつきません。
問題のPDF内部には、対象付近で次の座標が入っていました。
始点：X = 433.5601 pt、Y = 200.8800 pt
終点：X = 434.5201 pt、Y = 274.2000 pt
ΔX = 0.9600 pt
ΔY = 73.3200 pt
斜距離 = 約73.3263 pt
垂直寸法なので、正式に比較すべきなのは斜距離ではなく、寸法軸への投影距離です。
垂直方向の投影距離
= 73.3200 × 35.277777...
= 約2,586.57 mm
記載寸法との差
= 2,590.00 - 2,586.57
= 約3.43 mm
つまり、変換処理が座標を間違えたのではありません。
PDF内部の座標を正しく読んでも、2,590 mmにはならない。
ここが最初の突破口でした。
PDFは「設計データ」ではなく「描画命令」だった
PDFは、紙面を同じように見せることに強い形式です。
一方、CADが必要とするのは、線の意味と設計上の正確な位置です。
この違いは大きいです。
PDFの中では、見た目が一本の線でも、実体はさまざまです。
- 中心線を持つStroke
- 細い長方形として塗られたFill
- 複数の短い線分に分割された点線
- Bézier曲線の制御点
- Form XObject内で変換された座標
- CTM（Current Transformation Matrix）で拡大・回転・移動された図形
- Excel罫線のように、線ではなく塗り潰し矩形として出力されたもの
ここで疑ったのが、PDFを作る途中で座標が一定の間隔へ丸められる「量子化」です。
たとえばGhostscriptの公式資料では、ベクタ出力も入力の描画命令を処理し、描画要素から出力を再構成する仕組みが説明されています。この仕組みを踏まえると、元CADの数値がそのまま保存されると決めつけず、出力後の座標を確かめる必要があると考えました。［Ghostscript公式資料「High Level Devices」冒頭の処理説明／公開日表示なし、2026年9月10日参照］
座標を直す前に、その座標が生まれた過程を調べる
「小数点以下を何桁にすれば合うのか」と考えていたときは、変換器の出口を見ていました。
しかし、元PDFの時点で座標が丸められていたら、出口の桁数を増やしても、失われた値は戻りません。
そこで、問いを一つ手前へ戻しました。
このPDFを作ったソフトやプリンタードライバーは、どんな規則で座標を出力したのだろう。
手掛かりは、0.12 ptという刻み
今回の解析資料では、複数の座標に約0.12 pt単位の刻みが見られました。
縮尺1/100の図面なら、この1刻みは実寸で次の大きさになります。
紙面上の刻み
= 0.12 × 25.4 / 72
= 約0.0423 mm
縮尺1/100での実寸の刻み
= 0.12 × 25.4 / 72 × 100
= 約4.23 mm
紙では約0.04 mm。それがCADの実寸では約4.23 mmになる。
今回の3.43 mmという差が、この大きさの中に入ります。
さらに、0.12 ptを1インチ当たりの刻み数へ換算すると、こうなります。
72 pt/inch ÷ 0.12 pt
= 600 回/inch
600 dpi相当の格子間隔です。
これは数値上の対応であり、今回のPDFが600 dpi設定のプリンタードライバーで作られたと特定できたわけではありません。それでも、出力時の座標格子を調べる具体的な手掛かりになります。
ベクタPDFでも、出力された座標が格子状に並ぶ可能性はある。ベクタであることと、元CADの座標精度を保っていることは、分けて考える必要がありました。
出力された数値から、生成規則を推定する
この先に考えているのは、ページ内の座標分布から、出力過程の特性を推定する処理です。
単純化すると、仮説となる量子化モデルは次のように書けます。
出力座標 q = b + h × round((u - b) / h)
u：丸め前の座標
h：座標の刻み幅
b：格子の原点のずれ
これは最近傍丸めを仮定した説明用のモデルです。実際には切捨て等の規則も候補になり、回転・拡大縮小・座標の平行移動がどの段階で入ったかも確認が必要です。
調べる対象は、単に「0.12で割り切れるか」だけではありません。
- 多数の端点が、同じ刻み幅と原点のずれで説明できるか。
- X方向とY方向で、その規則は共通か。
- 座標変換を考慮しても規則が残るか。
- 通り芯など、元の設計上の規則的な配置を拾っているだけではないか。
- 推定に使わなかった端点や寸法でも、その仮説が成り立つか。
プログラムのソースを見ず、出力されたデータから処理の特性を調べる。ここには、ブラックボックスをリバースエンジニアリングする面白さがあります。
ただし、ソフトウェアそのものを逆コンパイルしたわけではありません。特定のCADやPDF作成ソフトの内部アルゴリズムを解明したとも、まだ言えません。目指しているのは、そのPDFの座標を説明できる出力モデルをつくることです。
クセが分かっても、失われた座標は一意に戻らない
ここが、この話のもう一つの重要なところです。
仮に0.12 pt刻みの最近傍丸めだったとしても、出力された1座標に対応する元の値には幅があります。変換前後の座標系が同じなら、丸め誤差は1座標当たり最大で半刻みです。
1座標当たりの誤差上限（この丸めモデルの仮定内）
= 0.12 / 2 × 25.4 / 72 × 100
= 約2.12 mm
同じ軸上の2端点の差に含まれる誤差上限
= 0.12 × 25.4 / 72 × 100
= 約4.23 mm
量子化の規則を推定できれば、「元の点があり得る範囲」を絞れます。しかし、その範囲のどこが設計上の正解だったかは、座標だけでは決まりません。
そこで効いてくるのが、図面に残っている「2,590」という寸法、直交、平行、端点一致です。
出力のクセから誤差の範囲を知り、図面の寸法と関係から、その範囲内の幾何を決める。
この二つがつながったことで、単位換算の問題が、設計意図を復元する問題へ変わりました。
論文を読んで、問題の名前が変わった
ここまで来て、検索語を変えました。
それまでは、PDF coordinate accuracy、pt mm rounding error、PDF to CAD conversionと検索していました。
しかし、PDFの座標自体を正確に読んでも2,590 mmにならないのなら、これは「単位変換」の問題ではありません。
探すべきは、不完全な観測から、編集可能なCADと設計意図をどう復元するかでした。
そこで読んだ論文の中で、特に考え方を変えたのが次の3本です。
| 論文 | 着目した点 | 今回の実装への示唆 |
|---|---|---|
| Raster-To-Vector: Revisiting Floorplan Transformation（ICCV 2017） | 画像を単になぞらず、壁接合部などの構造を検出してベクタ平面図を組み立てる | 画素・描画命令の忠実な複写と、建築図面としての復元は別問題 |
| Vitruvion: A Generative Model of Parametric CAD Sketches（ICLR 2022／初稿2021年） | CADを線の集合ではなく、primitiveとconstraintから成るプログラムとして扱う | 寸法、直交、平行、端点一致を拘束グラフとして持たせる |
| DAVINCI: A Single-Stage Architecture for Constrained CAD Sketch Inference（2024） | ラスタ画像から幾何primitiveとconstraintを同時に推定し、誤差の連鎖を抑える | 線を起こした後に場当たり的に丸めるのではなく、幾何と拘束を同じ問題として評価する |
特にVitruvionの説明は刺さりました。
CADの本質は、線がどこに見えるかだけではない。線、円、点などのprimitiveと、「直交」「平行」「一致」「寸法」といったconstraintによって設計意図を表す——という考え方です。
Vitruvionでは、生成した幾何と拘束を、CAD側で解いて編集できる表現として扱います。ここから着想したのが、「座標の誤差を、寸法などの拘束と一緒に評価する」という方針でした。
これを今回のPDFへ置き換えると、こうなります。
PDF座標 = 観測値
寸法文字 = 設計意図の候補
直交・平行・端点一致 = 幾何拘束
JWW座標 = ソルバーで確定した結果
ここで、問題の名前が変わりました。
変更前：「PDF座標を何桁で丸めればよいか」
変更後：「PDFに失われた設計意図を、どの拘束から復元するか」
この瞬間、「3 mmの誤差を丸める」のではなく、「2,590 mmという設計意図を満たす幾何を解く」方へ進めました。
これらは、プリンタードライバーの丸め規則を特定する論文ではありません。参考にしたのは、幾何要素と拘束を組み合わせ、整合する図形を求める考え方です。論文のモデルをそのまま搭載するのではなく、PDFのベクタ、寸法文字、JWWの縮尺、建築図面の寸法配置へ応用しています。
寸法文字を、ただの文字から「拘束条件」へ
図面には「2,590」と書かれています。
人間はこれを見れば、「この二点間は2,590 mmであるべきだ」と理解します。しかし、単純なPDF変換器にとっては、ただの4文字です。
そこで、変換経路を次のように整理しました。
PDFの原始データ
↓
線・文字・塗り・変換行列を抽出
↓
寸法文字の候補を正規化
↓
寸法線・補助線・矢印・対象端点を関連付け
↓
拘束グラフを構築
↓
元図形からの移動量が最小になる補正案を計算
↓
PolicyGateで矛盾・過補正を検査
↓
利用者がプレビューして確定
↓
JWWへ保存
ポイントは、OCRやAIが読んだ数字を、そのまま図面へ書き込まないことです。
「2,590」という文字だけを信じて線を動かすと、別の寸法や直交条件を壊す可能性があります。敷地境界なら、寸法文字より測量座標を優先すべき場合もあります。
そのため幾何を3状態に分けました。
| 状態 | 内容 |
|---|---|
| raw | PDFから直接抽出した元座標 |
| proposed | 寸法拘束から計算した補正候補 |
| committed | 検査と利用者確認を通過した確定座標 |
拒否・競合・取消のときは、元データを変更しない設計にします。
斜めの線を測ってはいけない
今回の対象線には、X方向に0.9600 ptの傾きがありました。
ここで端点間の斜距離を使うと、約2,586.79 mmです。垂直方向へ投影すると、約2,586.57 mmです。
差は約0.22 mmしかありませんが、考え方として重要です。
measured = abs(dot(P2 - P1, normalized_dimension_axis))
寸法が縦方向なら縦へ、横方向なら横へ投影して比較します。
「少し傾いた寸法線の長さ」を設計寸法だと思い込むと、傾きを長さへ混ぜてしまいます。
1個の寸法で、図面全体を拡大してはいけない
2,586.57 mmを2,590 mmへ合わせる倍率は、約100.1326%です。
2,590.00 / 2,586.57
= 約1.001326
= 約100.1326%
では、図面全体を100.1326%に拡大すればよいのか。
答えは、原則として「いいえ」です。
1つの寸法だけで全体を拡大すると、正しかった別の寸法まで壊す可能性があります。
そこで、全体縮尺の誤差と局所的な量子化誤差を分けます。
全体補正を許可するのは、複数の高信頼寸法について、次の倍率が同じ方向に揃った場合だけです。
scale_ratio_i = stated_dimension_i / measured_dimension_i
倍率が揃わない、特定端点だけがずれている、全体を直すと他の寸法が悪化する——その場合は局所補正として扱います。
今回のような補正なら、二つの端点へ均等配分する案は次の通りです。
残差 約3.43 mm
端点ごとの移動 約3.43 / 2
約1.72 mm
ただし、片側が通り芯や他の確定点に拘束されているなら、固定側は動かしません。
AIに任せる部分と、コードで止める部分
前回の記事では、AIへ「実行してよいか」まで判断させて失敗し、決定論的なPolicyGateへ責務を移した話を書きました。
PDF→CADでも同じでした。
AIやOCRが得意なのは、候補を出すことです。
- この文字は寸法値らしい
- この線は寸法線らしい
- この二本は補助線らしい
- この端点の組が対象らしい
一方、次の判定はコードで行います。
- 他の高信頼寸法を悪化させないか
- 直交・平行・閉領域を壊さないか
- 移動量が推定量子化幅を大幅に超えていないか
- 全体縮尺補正と局所補正を混同していないか
- 保存後にJWWを再読込して同じ値になるか
- 信頼度不足なら自動確定せず、利用者へ確認を出す
結局、ここでも答えは同じでした。
確率で見つけ、決定論で検査し、人が確定する。
そして、最後は2,590.000mmになった
実装後、同じPDF、同じ対象寸法、同じ縮尺で再度JWWへ変換しました。
そしてJw_cadの測定コマンドで確認した結果が、これです。
PDFの記載寸法 2,590.00 mm
補正前の投影距離 約2,586.57 mm
検出した残差 約+3.43 mm
補正後のJWW測定値 2,590.000 mm
最後は、ピッタリ合いました。
ここで確認できたのは、今回の対象区間で記載寸法とJw_cadの測定表示が一致したことです。表示の一致は、全要素の座標や面積まで誤差ゼロになった証明ではありません。ほかの寸法・接続関係・保存後の再読込は、それぞれ別に検証します。
画面で見たときは、補正前と補正後の違いはほぼ分かりません。しかし測定コマンドの数字は、約2,586.57 mmから2,590.000 mmへ変わりました。
この「見た目は同じなのに、CADとしては違う」が、今回いちばん面白かったところです。
参考として、社内技術仕様書（2026年9月9日改訂、§25.9・§43等）に記録した別の評価と、今回の寸法確認を並べます。評価対象や指標は異なり、総合的な「変換成功率」を示す表ではありません。
| 項目 | 実測結果 |
|---|---|
| ベクタPDFの長い線（実PDF 4枚） | recall@0.5 = 0.935／precision = 0.78 |
| ベクタPDFの文字 | exact = 0.803 / CER = 0.096 |
| Excel印刷PDFの罫線 | 出力線275本／塗り潰し矩形275個（本数一致） |
| ベクタグラフの細切れ | 5,533 → 4,843（−12.5%） |
| 誤結合（上記の実図9枚の評価内） | 0 |
| 対象寸法のPDF座標値 | 約2,586.57 mm |
| 記載寸法との差 | 約+3.43 mm |
| 補正後のJw_cad測定値 | 2,590.000 mm |
ただし、1か所が合ったから「どんなPDFでも完全変換できる」とは言いません。
- 複数寸法が矛盾する図面
- OCRで寸法値を誤読した図面
- 寸法線と対象端点の対応が曖昧な図面
- スキャン画像しかない図面
- 測量座標を寸法文字より優先すべき敷地図
こうしたケースでは、自動補正せず、候補と理由を人へ返す必要があります。
今回証明できたのは、少なくとも「PDFだから3 mmのズレは仕方がない」という結論ではないことです。
PDF座標だけでは失われた寸法でも、図面内の設計意図を拘束として使えば、CAD上でピッタリ復元できる場合がある。
一つの図面で見つけた規則を、次の図面へ生かせるか
寸法が合ったところで、もう一つ可能性が見えてきました。
同じ出力条件で作られた図面なら、座標のクセも再利用できるのではないか。
ここからは、今後検証したい拡張です。量子化パラメータを図面間で再利用する処理と、その高速化効果は、まだ実測結果として示せる段階ではありません。
計算する範囲を絞れる可能性
出力モデルが分かれば、各端点に対して「この程度のずれなら生成過程で説明できる」という範囲を与えられます。
検証済みのモデルを初期値や候補の絞込みに使い、寸法と矛盾する部分や、関連する拘束の範囲へ詳しい計算を集中する。規則が合わないページは、通常の推定へ戻す。
この分担ができれば、図面ごとに候補探索を繰り返す負担を減らせる可能性があります。
ただし、「フィルターを通せば正解」「ソルバーが不要になる」という話ではありません。局所補正でもつながった図形へ影響が及ぶため、整合検査は必要です。処理時間は推定・補正・検証を含む全体で比較し、誤補正が増えていないことも測ります。
何十枚もの図面へ展開するなら
同じ物件の図面一式でも、用紙、出力倍率、作成ソフトの版、詳細図の貼り込み方が違うことがあります。同じ事務所が作ったという理由だけで、同じ補正はかけません。
考えているのは、推定した刻み幅や生成条件を記録し、次のページの座標分布・寸法で再確認してから使う仕組みです。
代表ページで特性を調べ、別ページで成り立つか検証し、条件が合う図面へ広げる。成り立たなければ、そのページでは再推定する。
これが成立すれば、何十枚、何百枚という図面一式に対して、毎回ゼロから解析する部分を減らせます。
一枚を直した経験が、次の一枚を確かめる手掛かりになる。
この蓄積を使う場所として考えているのが、Newsatsuです。
次は、公共工事の公告と一緒にJWWを届けたい
ここからは、この技術の使い道についてです。
弊社は、公共工事の入札公告・落札結果・建設会社情報をつなぐ Newsatsu（newsatsu.jp） も開発・運営しています。案件を探し、地域や工種を絞り、次の営業先や受注候補を見つけるサービスです。
そこで考えているのが、次の組み合わせです。
Newsatsuで、公告と同時に配布されるベクタPDF図面を取得し、JZ Draft AIの変換エンジンでJWW化して、案件ページからダウンロードできるようにする。
今回のサービスで対象にするのは、公告と同時に配布されるベクタPDFです。PDF内に残っている線や文字を直接取り出し、縮尺と寸法を照合してJWWへ再構成します。
案件を見つけた時点で、寸法の照合結果が付いたCADデータも手に入る。Jw_cadやiPhone／iPadのJZ Draft AIで開いて、そのまま拾い出しの準備へ進める。
対象寸法を一致させる技術に、出力特性の推定と再利用を組み合わせる。一枚の変換から、図面一式を扱うサービスへ広げる構想です。
積算の前にある「図面を使えるようにする作業」
たとえば、学校の改修工事を見つけた防水会社が、屋上の施工範囲を拾いたい場合を考えます。
手元のベクタPDFをいつものCADで使うために、図面を取り込み、線や文字へ変換し、基準寸法を選び、縮尺を確認する。利用するソフトによっては、拾う範囲を指定するための作図や手直しも必要になります。
ベクタ情報が残っているのなら、その情報をできるだけ生かして、この準備を済ませておきたい。今回の変換技術は、そこに使えます。
この準備を、同じ公告を検討する会社が、それぞれ行う。
共通部分を一度処理し、その検証結果ごと渡せれば、同じ図面を何度も下準備する時間を減らせるのではないか。
ここに、NewsatsuとJZ Draft AIを組み合わせる価値があると考えています。工数削減の効果は、今後、実際の積算担当者と測りたいところです。
「JWWをダウンロード」の先にある使い道
案件ページに設けたい入口は、シンプルです。
JWW（Jw_cadデータ）をダウンロード
原本PDF・縮尺の根拠・寸法照合結果を確認
提供するJWWでは、線・文字・下敷き画像を分けて扱えるようにします。文字を非表示にして図形を選ぶ、原本を重ねて変換結果を確認する、といった使い方を想定しています。これは変換後の整理であり、元のCADレイヤを完全に復元するという意味ではありません。
| 利用者 | 想定する使い道 | 数量として使う前の確認 |
|---|---|---|
| 建築・改修会社 | 対象範囲の面積、開口部の寸法・周長を拾う | 工事範囲、仕上げ区分、控除条件 |
| 防水・塗装会社 | 屋上や床の対象面積、端部の延長を拾う | 立上り、高さ、施工対象外の部分 |
| 設備・電気会社 | 図面上の配管・配線経路の平面長を拾う | 上下移動、系統、仕様、実施工経路 |
| 土木会社 | 寸法・座標を確認した区間の延長や平面範囲を拾う | 測量座標、勾配、断面、数量算出条件 |
ここで区別したいのは、幾何を測れることと、積算数量が確定することです。
床の閉領域が分かれば面積は計算できます。しかし、壁面積には高さや開口控除が必要です。配管の平面長が分かっても、立上りや立下りまで自動的に分かるわけではありません。
最初に目指すのは、正しく拾うための準備を短くし、測定根拠を確認しやすくすることです。
変換エンジンを、案件収集の後ろにつなぐ
サーバー側では、次の処理をバックグラウンドでつなぐ構想です。
- 案件にひも付く図面PDFについて、取得・加工・配布条件を確認する。
- 原本の版とページを記録し、ベクタ描画命令・文字・座標変換を解析する。
- JZ Draft AIの変換処理を使い、線・文字・縮尺候補を抽出する。
- 出力特性の推定・再利用を検証し、寸法の矛盾や対応不明の箇所を分ける。
- JWWと照合結果を保存し、条件を満たした図面を案件ページへ掲載する。
JWWに加え、元PDFのページ、単位、領域別の縮尺、照合した寸法、補正履歴、未確定の意味情報をJSONで保持する案です。JWWは普段のCAD作業へ、付随データはWeb表示や再検証へ使います。既存のJw_cadが、このJSONの意味情報をそのまま解釈するわけではありません。
Rustの共通処理を生かしつつ、iOS側のPDF・画像・OCR処理に依存する部分は、サーバーで動かせる形への切り出しと検証が必要です。アプリにある機能が、そのままサーバーで稼働するとは決めつけていません。
また、訂正図面が出たら旧版のJWWを現行版として出し続けないことも必要です。原本の更新と変換結果を対応付けるところまで含めて、サービスにしたいと考えています。
さらに、CADを開く前の「数量プレビュー」へ
もう一段先には、案件ページで対象範囲の概算面積や主要な部屋名、図面上の延長を確認できる表示を考えています。
たとえば、防水会社が案件を開いたときに、認識した屋上の範囲とその面積候補が見える。数値を選ぶと、根拠になった原図の範囲も確認できる。
これなら、CADを開く前に「自社で検討する規模の工事か」を判断する材料になります。
ただし、「延床面積」「壁面積」と名前を付けるには、線の位置だけでなく、階・部屋・高さ・開口・対象範囲の意味を正しく関連付ける必要があります。必要な情報がそろわない項目は、数値を推測して埋めず、未確定として表示する設計を考えています。
線を取り出す。寸法を確かめる。何の線かを関連付ける。その根拠から数量を出す。
JZ Draft AIで進めている、IRへ図面の意味を付加する仕組みも、この段階でつながってきます。
配るなら、「どこまで確かめたか」も一緒に配る
サービス化で大切にしたいのは、変換できたファイルの数より、利用者が安心して確認を進められることです。
ベクタがあることと、実寸が合うことを分けて確認する
対象のベクタPDFには、直接取り出せる幾何情報があります。社内技術資料でも、PDFベクタの直読、文字抽出、塗り潰し罫線の中心線化などを実装しています。
ただし、今回の3.43 mmが示したように、ベクタの座標を正確に取り出すだけでは、記載寸法と一致しない場合があります。だからこそ、ベクタ直読と寸法照合を組み合わせることが、このサービスの中心になります。
配布画面では、その検証結果も確認できるようにします。
| 表示項目 | 利用者へ伝えたいこと |
|---|---|
| 変換対象 | 公告に添付されたベクタPDFの対象ページ・領域 |
| 縮尺 | 確認済みの範囲、推定根拠、未確定の領域 |
| 寸法照合 | 照合件数、一致・不一致、補正前後の残差 |
| 要確認箇所 | 寸法の誤読候補、対応が曖昧な線、未抽出部分 |
| 原本情報 | 発注機関、元URL、図面の版、変換日時 |
ベクタ直読で保持した幾何と、寸法に基づいて補正した幾何を区別して記録します。1ページに異なる縮尺の詳細図がある場合も、領域ごとに区別します。
そして、自動処理では判断できない図面は、未照合として人へ返す。今回の寸法補正で重要だった考え方を、そのまま配布の仕組みにも持ち込みます。
公開図面の加工・再配布は、条件を確認してから
配布対象は、加工・再配布の条件を確認できた図面からにします。
デジタル庁の「公共データ利用規約（第1.0版）」は、適用対象となるコンテンツの商用利用・加工等を認める一方、出典と加工主体の表示、第三者の権利確認を求めています。ただし、この規約がすべての自治体・入札図面に一律適用されるわけではありません。［2024年7月5日制定、本文1・1.1・1.2・1.4］
発注機関ごとの利用条件と図面ごとの権利関係を確認し、「発注者が作成した原図」と「弊社が変換・補正した積算補助データ」を明確に区別します。免責文を付けるだけで、加工・配布の許諾に代えられるとは考えていません。
2,590 mmが合った。その先の時間を減らしたい
今回、最後にJw_cadが表示した数字は、2,590.000 mmでした。
この一致は、まず一つの図面、一つの対象区間で得られた結果です。複数の図面へ広げるには、合うケースだけでなく、矛盾して止めるべきケースも測る必要があります。
それでも、この技術の使い道は見えてきました。
公共工事を見つけたら、寸法の照合結果が付いたJWWも手に入り、いつものCADで拾い出しを始められる。
Newsatsuで工事を探し、JZ Draft AIの変換技術で図面を整え、各社が得意な積算や施工の検討へ進む。そんな流れをつくりたいと考えています。
最初は、小数点以下を何桁残すかを考えていました。そこから、座標が生まれた過程を調べ、論文の拘束表現を参考にし、図面の寸法と向き合うところまで進みました。
3.43 mmのズレを追いかけた先に、同じPDFを各社で変換し、縮尺を合わせ直す時間を減らす構想が見えてきました。
次に確かめたいのは、変換した線の精度と、それによって現場の担当者が何分早く仕事を進められるかです。
JZ Draft AIをApp Storeで見る
Newsatsuで公共工事を探す
参考資料
参照日：2026年9月10日。サービス連携部分は筆者の構想であり、各論文が本サービスの精度や実現性を検証したものではありません。
- 前編：老舗国産CAD、AIで再起動。Rust×iOS×C ABIでiPhoneへ：前回の開発経緯。
- PDF 32000-1:2008（Adobe公開版）：2008年、§8.3.2.3（ユーザー空間）、§8.3.3（座標変換）、§8.5（パス）。旧版だが、この記事で扱う基本座標系・描画仕様の根拠として採用。
- Ghostscript公式資料「High Level Devices」：冒頭のベクタ出力処理の説明。公開日表示なし、2026年9月10日参照。描画要素から出力を再構成する背景説明に採用。今回の0.12 ptや生成ソフトの特定根拠ではありません。
- Raster-to-Vector: Revisiting Floorplan Transformation：ICCV 2017、著者公開ページAbstract。接合部検出と整数計画による図面復元を参照。古い研究だが、認識候補と幾何整合を組み合わせる発想の出発点として採用。
- Vitruvion: A Generative Model of Parametric CAD Sketches：初稿2021年9月29日、改訂2022年4月28日、ICLR 2022、Abstract。幾何要素と拘束によるCAD表現を参照。
- DAVINCI: A Single-Stage Architecture for Constrained CAD Sketch Inference：2024年10月30日公開、BMVC 2024、Abstract。画像からの幾何・拘束の同時推定を参照。
- 公共データ利用規約（第1.0版）：デジタル庁、2024年7月5日制定、本文1・1.1・1.2・1.4。加工・商用利用、出典表示、第三者権利、適用除外を参照。
- Newsatsu：公式サービス概要。公開・更新日表示なし、参照日時点の情報。
- JZ Draft AI（App Store）：アプリ配布ページ。
- 社内技術資料：JZ_DRAFT_AI_TECHNICAL_SPEC_20260905.md（2026年9月9日改訂）、§25.8–25.9ほか。公開URLなし。表の評価値は社内評価であり、第三者評価ではありません。今回の2,590.000 mm一致は開発者による測定確認です。
- 社内解析・実装指示資料：PROMPT_DIMENSION_AWARE_PDF_TO_JWW_GEOMETRIC_RECONCILIATION_20260909(1).md、2026年9月9日、§5「PDF量子化の推定」。公開URLなし。約0.12 ptの観察と統計推定の方針を参照。生成ドライバーの特定や高速化の完了報告ではありません。
タグ候補
PDF
JWW
Rust
iOS
CAD