こんにちは。土木設計歴30年、AI土木研究室です。
図面はきれいに描けている。印刷しても問題ない。それなのに、SXF形式に変換して電子納品チェックシステムにかけた途端、レイヤ名のエラーが何十行も並ぶ——。電子納品の直前にこれをやると、まる一日が飛びます。
しかも今回は、ルールそのものが変わりました。国土交通省は令和7年12月に「CAD製図基準」を改定し、レイヤ名の階層構造を作り直しています。令和8年4月1日以降に契約を締結する工事・業務から適用されます（受発注者協議の上、令和8年3月31日以前に契約を締結している工事・業務でも適用できるとされています）。
この記事では、SXF変換でレイヤが崩れる原因を仕組みから整理し、改定後の新ルールと、変換前にやっておくべき確認手順をまとめます。原典であるCAD製図基準（令和7年12月）と、CAD製図基準に関する運用ガイドライン（令和7年12月）に当たって書いています。
SXF変換でレイヤが崩れる根本原因｜SXFは「変換の仕方」を決めていない
まず押さえておきたいのが、SXFという形式の立ち位置です。運用ガイドラインには、こう書かれています。
SXF形式はCADデータ交換のためのフォーマットであって、CADソフトの独自機能に依存するSXF変換機能や表示機能を規定しているものではない、と。だから同じCADデータでも、A社のCADソフト上での表示とB社のCADソフト上での表示が異なるおそれがある、と明記されています。
ここが肝心なところです。SXFが決めているのは「受け渡すデータの形」であって、「お使いのCADソフトがどう書き出すか」までは決めていません。つまり、変換で何が落ちるかはソフト任せということです。基準は「変換する際のデータ欠落や、CADソフトによる表現の違いがあるおそれがある」と、欠落が起こりうることを前提にした書き方をしています。
だから「変換すれば済む」ではなく、「変換したら必ず見て確かめる」が正しい運用になります。この前提が共有できていないと、納品直前の手戻りが毎回発生します。
なお、CAD製図基準が対象とするファイル形式はSXF(P21)形式です。これをZIP方式で圧縮し、拡張子を「P2Z」としたSXF(P2Z)形式も対象に含まれます。バージョンとレベルは、SXF Ver.2.0 レベル2以上が対象とされています。
【令和7年12月改定】CAD製図基準のレイヤ名は3階層に変わった
今回の改定で最も実務に効くのが、レイヤ名称の規定変更です。
従来（平成29年3月版）は、第3階層に「作図要素」の名称が工種ごとに定められていました。令和7年12月の改定では、この第3階層の作図要素の規定を廃止し、従来の第4階層だったユーザ定義領域を第3階層に繰り上げています。結果、レイヤ名は次の3階層になりました。
責任主体 － 図面オブジェクト － ユーザ定義領域
責任主体 ： 半角英大文字1文字
S=測量 / D=設計 / C=施工 / M=維持管理
図面オブジェクト： 半角英大文字3文字（TTL, BGD, BMK …）
ユーザ定義領域 ： 全角文字なら最大125文字以下
半角英数字なら最大250文字以下（全角1文字=半角2文字）
※省略可能
※レイヤ名の文字数合計は、半角256文字以下基準に載っている名称例がわかりやすいので、そのまま引きます。
（名称例1）D-STR ← ユーザ定義領域は省略できる
（名称例2）D-BMK-道路中心線、D-BMK-構造物中心線
（名称例3）D-STR-A1橋台、D-STR-P1橋脚
（名称例4）D-STR-STR1、D-STR-STR1-A1橋台
（名称例5）C-BMK-BMKZ-KMPOST改定の狙いは解説にはっきり書かれています。従来のレイヤ名だけでは、道路中心線と構造物中心線、下部工番号の異なる橋脚や橋台といった図形要素が同一レイヤに混在してしまい、構造物単位での抽出や全体像の把握が難しかった。ユーザ定義領域を第3階層に上げ、日本語を含む全角文字で自由に名前を付けられるようにすることで、そこを分けられるようにした、というわけです。
実務者として素直にありがたい改定だと思います。「D-STR-A1橋台」と「D-STR-P1橋脚」が分けられるのは、後工程での作業効率がまるで違います。
過去のレイヤ名は使えなくなるのか
ここが気になるところですが、解説には「作図要素をユーザ定義領域とみなすことで改定後においても使用可能」と書かれています。平成29年3月版で定められていたレイヤ名や、「道路工事完成図等作成要領」に示されているレイヤ名がこれに当たります。上の名称例4・名称例5がその例です。
つまり、既存のテンプレートを全部作り直さなければならない、という話ではありません。ただし、新しく作る図面でユーザ定義領域を活かすなら、社内のレイヤ命名ルールは見直しておく価値があります。
図面オブジェクトは全工種統一で10種類
第2階層の図面オブジェクトは、全工種統一して利用可となるよう変更されました。内容は次の10種類です。
- TTL（図枠）：外枠、表題欄、罫線、文字、縦断図の帯枠
- BGD（背景）：主計曲線、現況地物、既設構造物 等
- BMK（基準）：基準点、測量ポイント、中心線、幅杭 等
- STR（主構造物）：当該図面であらわす構造物
- BYP（副構造物）：主構造物から派生する構造物
- MTR（材料表）：切盛土、コンクリート、鉄筋加工、数量
- DCR（説明・着色）：ハッチ、シンボル、塗りつぶし、記号 等
- DOC（文章）：文章（説明事項、指示事項、参照事項 等）
- SUV（測量）：地形図等の改変しない測量成果データ
- ORD（発注用）：発注図に作図する注記、旗上げ等
このうちORDには注意が必要です。発注用レイヤは責任主体が「C」固定、図面オブジェクトが「ORD」固定で、発注図専用です。受注者は使用しません。工事完成図を作成する際には削除し、発注用レイヤは残さないものとする、と明記されています。発注図に含まれる図面オブジェクトを工事完成図に流用する場合は、所定のレイヤに移動します。
レイヤ名でエラーになる典型パターンと直し方
電子納品チェックシステムでレイヤ関係のエラーが出るとき、原因はだいたい決まっています。基準の規定に照らして、確認すべき点を整理します。
- 責任主体が1文字になっていない：S・D・C・Mのいずれか半角英大文字1文字です。設計段階の成果なら「D」。責任主体は、該当するレイヤを修正したときのみ変更する、という運用が基準に書かれています。
- 図面オブジェクトが3文字の規定値になっていない：上の10種類以外は使えません。作業用に「TEMP」「補助」といったレイヤを作ったまま納品すると、ここで引っかかります。
- 区切り文字が違う：階層をつなぐのはハイフン（－）です。アンダースコアや全角ハイフンで作ってしまうケースが典型です。
- 文字数オーバー：レイヤ名の合計は半角256文字以下。ユーザ定義領域に日本語で長い説明を入れると、全角1文字＝半角2文字で計算されるため意外と早く上限に届きます。
- 使えない文字を使っている：責任主体と図面オブジェクトは半角英大文字のみ。ユーザ定義領域は半角英数字と全角文字が使えますが、使用可能な全角文字は「土木設計業務等の電子納品要領」等の「使用文字」の規定に従います。
もうひとつ、実務で効く注意点がガイドラインに書かれています。SXFビューア等によるレイヤ名称の確認は、文字数等の簡易なチェックのみである、という点です。したがって、SXFビューア等でエラーにならないレイヤ名であっても、電子納品チェックシステムではエラーになる場合があります。その場合は修正が必要です。
「ビューアで見たけど何も出なかったから大丈夫」は通用しない、ということです。チェックは必ず両方かけてください。
そもそもレイヤ設計が崩れていると、命名を直すだけでは追いつきません。図面を描き始める前のレイヤ設計については、土木CAD図面のレイヤー管理ベストプラクティスで整理していますので、あわせてご覧ください。
レイヤ以外で崩れるところ｜色・線・文字の3点
SXF変換で問題になるのはレイヤだけではありません。CAD製図基準は、色・線・文字についても規定を置いています。目視確認の項目にもこの3つが入っています。
色は16色が基本
CADデータ作成に用いる色は、原則として黒、赤、緑、青、黄、マジェンタ、シアン、白、牡丹、茶、橙、薄緑、明青、青紫、明灰、暗灰の16色を基本とする、と規定されています。CADソフト側で自由に色を作って割り当てていると、変換後に近い色へ寄せられて意図と変わることがあります。
線は細線・太線・極太線の3種類
線の太さは細線・太線・極太線の3種類を使用し、その比率は1:2:4とされています。実際の数値は、図面の大きさや種類により0.13、0.18、0.25、0.35、0.5、0.7、1、1.4、2mmの中から選択することが原則です。
ただし解説には、これらは紙に出力する場合の規定値であり、実際に出図される線の太さは出力装置により異なるため近似値としてよい、と書かれています。画面上の見た目ではなく、用紙に出力した場合を対象にした規定だという点は押さえておきたいところです。
線種は、実線・破線・一点鎖線・二点鎖線の線種グループがあり、JIS Z 8312:1999に定義されている15種類の線種を使用することが原則です。
文字はフォントの選び方で化ける
文字の高さは1.8、2.5、3.5、5、7、10、14、20mmから選択することが原則です。単位（m2、m3）等を入力する際に高さを変える必要が生じる場合は、これ以外も使用できるとされています。
文字化けの直接の原因になるのがフォントです。解説には、CADで文字を書く場合はCADソフトウェアの機能とフォントに依存するため、CADソフトウェア固有の文字や機種依存文字は使用せず、アウトラインフォント又は製図に用いる文字に類似した文字を使用する、と書かれています。丸数字やローマ数字を注記に使っていると、ここで事故が起きます。
また、CADで縦書きをする場合は、文字列として入力するとともに全角文字を用いることが原則とされています。
SXF変換前にやっておく準備｜ファイルサイズと図面構成
変換してから慌てないために、作図の段階でやっておくことがあります。ガイドラインが具体的に注意を促しているのが、ファイルサイズです。
基本的に、SXF(P21)形式のファイルサイズが30MBを超えないようデータ量を軽減するようにしてください、と書かれています。そのための対応策も示されています。
- 地形図がショートベクトルで構成され要素数が膨大になる場合：修正の必要がない住宅図などの地形データは、ラスタファイルのまま1レイヤに分類して使用し、ファイルサイズの軽減を図る。ガイドラインには、平面図で地形図をラスタ化し背景を削除したところ48,672,857バイトが29,792,846バイトに減少した、という例が示されています。
- 複数枚の図面データの貼り合わせ：複数枚の図面データを貼り合わせて1枚の図面データを作成することは、行わないでくださいと明記されています。
- 柱状図のハッチング等が多数の要素で作図されている場合：模様が1つであればラスタ画像に変換して対応できます。ただし添付できるラスタファイルの枚数はSXFのバージョンによって異なります。
- 圧縮形式の活用：SXF(P2Z)形式を用いることでファイルサイズの軽減が図れます。
ラスタの扱いはバージョン差が大きい部分です。SXF Ver.2.0 レベル2では、1枚のCADデータに添付できるラスタファイルは1枚のTIFF形式のファイルのみ。SXF Ver.3.0 レベル2以上では、JPEG・TIFF形式のファイルを複数枚（9枚まで）添付できます。お使いのCADソフトが対応しているバージョンを、事前に確認しておいてください。
座標の扱いも令和7年12月改定で追記されました。地形データを含む図面（位置図、平面図等）には、測量座標系（平面直角座標系）を設定することを標準とする、という規定です。3次元モデルや点群データ等との連携を見据えた改定と説明されています。部分図を利用する場合は、部分図座標系に実寸で定義し、用紙に配置することが原則です。
なお、公共測量作業規程の大縮尺地形図図式に則った地形図等を背景図として利用する場合は、同図式による線種・線幅・線色・フォント等の記載内容を変更せずに利用し、SUVレイヤに作図します。この地形図は本基準の対象外という扱いです。触らないのが正解です。
確認は2段構え｜SXFビューア等の目視確認と電子納品チェックシステム
ガイドラインが定めるCADデータの確認手順は、はっきり2段構えです。SXFビューア等を利用した目視確認を行い、その後、電子納品チェックシステムによる確認を行う。この順番です。
ここでいう「SXFビューア等」には定義があります。SXF表示機能及び確認機能要件書（案）（令和7年12月）に従って開発され、（一社）オープンCADフォーマット評議会（OCF）のSXF確認機能検定に合格したSXFビューア又はCADソフトのことです。手元のCADソフトで開いて見た、では要件を満たしません。検定に合格したソフトを使ってください、と書かれています。
目視確認の項目は、ガイドラインにア）～サ）で列挙されています。そのまま確認リストとして使えます。
ア）作図されている内容（データ欠落・文字化け等）
イ）適切なレイヤに作図（レイヤの内容確認）
ウ）紙図面との整合（印刷時の見え方とデータとの同一性確認）
エ）図面の大きさ（設定確認）
オ）図面の正位（設定確認）
カ）輪郭線の余白（設定確認）
キ）表題欄（記載事項等内容確認）
ク）尺度（共通仕様書に示す縮尺）
ケ）色
コ）線
サ）文字
※ケ）～サ）は、CAD製図基準と大きくかけはなれていないことを目視確認するア）に「データ欠落・文字化け等」が真っ先に挙がっているのが象徴的です。変換で落ちることを前提に、落ちていないかを人が見る——これがこの手順の設計思想です。
発注者側は、受け取ったCADデータが事前に確認した内容と同じであることを、抜き取りにより確認するとされています。なお、CADデータに作図されている内容そのものについては、従来どおり照査要領等に従って確認する、という整理です。SXFの確認は書式の確認であって、設計内容の照査を代替するものではありません。
2段目の電子納品チェックシステムでは、ファイル名・管理項目・管理ファイル（XML）の文法に加えて、ファイル形式、レイヤ名称、SXFのバージョン、SAFファイル名、ラスタファイルなどが自動チェックされます。この工程を仕組みとして定着させる話は、電子納品チェックを自動化する方法でまとめています。
着手時の事前協議で決めておくこと
30年やってきて確信しているのは、電子納品の失敗はほぼ全部、着手時の決めごと不足に帰着するということです。ガイドラインも、業務着手時に受発注者間で事前協議を行う事項を明示しています。
- ア）新規レイヤ、作業レイヤの取扱い等、CADデータの作成方法に関する事項
- イ）業務途中における中間成果品の取扱いに関する事項
- ウ）作図するSXFのバージョン（Ver.2.0、Ver.3.0、Ver.3.1）
- エ）その他（業務中の受渡し図面ファイル形式など）
ガイドラインの巻末には、CADデータに関する事前協議チェックシートが掲載されています。自社で一から作る必要はありません。
特にウ）のSXFバージョンは、後から変えると効く範囲が広い項目です。ラスタの枚数制限も、SAFファイルの有無も、ここで決まります。最初の打合せで確定させてください。
また、設計図面を業務の途中で利用する場合について、ガイドラインは基本的にCADデータでの授受は行わず、紙やPDFデータ等で管理してくださいとしています。やむを得ずCADデータを授受する場合、改定履歴は最終納品段階の「Z」ではなく、途中成果の履歴（Z以外）を使うこと、とされています。中間成果に「Z」を付けてしまうと、どれが最終版かわからなくなるためです。
ちなみにCADデータのファイル名は、図面番号（半角数字3文字）、ライフサイクル（S/D/C/M）、整理番号、図面種類（平面図ならPL等の半角英大文字2文字）、改定履歴、ユーザ定義領域（52文字以下）、拡張子（P21またはP2Z）で構成され、文字数合計は64文字以下です。基準に示されている例は「001D0PL1-○○区間平面図.P21」という形です。
ベース図の持ち方やレイアウトの組み方を最初に決めておくという話は、外部参照とペーパー空間の運用術でも書きました。SXF変換の問題は、突き詰めると図面管理の設計をいつ決めたかという問題です。
まとめ｜SXF変換は「落ちる前提」で組み立てる
要点を整理します。
- SXFは変換機能や表示機能を規定していない。だからデータ欠落や表示の違いが起こりうる。これは基準の側が前提にしていることです。
- 令和7年12月改定でレイヤ名が3階層になった。第3階層の作図要素が廃止され、ユーザ定義領域が第3階層へ。令和8年4月1日以降に契約を締結する工事・業務から適用されます。
- 過去のレイヤ名も、作図要素をユーザ定義領域とみなすことで引き続き使用可能。テンプレートの全面作り直しは不要です。
- 図面オブジェクトは全工種統一の10種類。ORDは発注図専用で、工事完成図には残しません。
- 崩れるのはレイヤだけではない。色（16色）、線（細線・太線・極太線）、文字（アウトラインフォント、機種依存文字を使わない）も確認対象です。
- ファイルサイズは30MBを超えないよう軽減する。地形図のラスタ化、貼り合わせをしない、P2Z形式の活用。
- 確認は2段構え。OCFのSXF確認機能検定に合格したSXFビューア等で目視確認し、その後に電子納品チェックシステムをかける。ビューアのレイヤ名チェックは簡易なものなので、これだけでは足りません。
- 着手時に事前協議で決める。特にSXFのバージョンは後から変えにくい項目です。
電子納品でいちばんもったいないのは、中身は正しいのに書式で跳ね返されて時間を取られることです。着手時に決めるべきことを決め、変換後に見るべきところを見る。それだけで、納品前の一日は取り戻せます。
なお、本記事は令和7年12月版の基準・ガイドラインに基づいて書いています。運用の細部は発注機関によって異なる場合がありますので、実際の適用にあたっては担当業務の共通仕様書と特記仕様書、そして受発注者協議の内容をご確認ください。
出典
- 国土交通省「CAD製図基準」令和7年12月（本編・解説）
https://www.cals-ed.go.jp/cri_point/ - 国土交通省「CAD製図基準に関する運用ガイドライン」令和7年12月
https://www.cals-ed.go.jp/cri_guideline/ - 国土交通省「CAD製図基準改定の主なポイント」令和7年12月
https://www.cals-ed.go.jp/mg/wp-content/uploads/CAD_point_202512.pdf
著者：AI土木研究室 / 土木設計歴30年。建設コンサルタントとしてインフラ整備に携わりながら、AI・自動化ツールの研究開発を行う。AI土木研究室（doboku-ai.jp）運営。
コメント