開けないDXFの原因をAIに聞いてみた｜8種類で試した結果

2026年11月13日

アイキャッチ：ファイルの先頭に余計な行（Content-Type）が入ったDXFの中身を示す図

結論：「中身が壊れているDXF」の原因は、AIに貼ればかなり当てられました。ただし、直せない壊れ方もあります

取引先から届いたDXFがCADで開けない。そんなとき、ファイルの中身をAIに貼って聞けば原因が分かるのか。わざと壊したDXFを8種類作り（壊し方は筆者だけが知っています）、Claudeに診断させました。

原因は、壊した7種類すべてで、2回中2回とも言い当てました。途中で切れている、先頭に余計な行がある、小数点がカンマになっている、行が1つ抜けている、区切り（ENDSEC）が抜けている、文字コードが食い違っている、DXFではなくログイン画面のHTMLが保存されていた。
直し方は、手作業なら通りました。AIの指示どおり直して、4種類（先頭の行・小数点・抜けた行・区切り）は読み込めました。
通らなかったこと：AIが勧めた「Pythonの修復読み込み（ezdxfのrecover）」は、2種類（行が抜けた・区切りが抜けた）では修復できず、途中で切れたファイルは読めても図形が0個でした。
試していないこと：AutoCAD・Jw_cad・FreeCADなど実際のCADで開けるか、図面が大きい場合、本物の取引先ファイル。

回数は「2回ずつ」なので、「成功率◯％」ではなく「この条件ではこうなった」という記録として読んでください。

この記事について（先にお断り）

筆者は商品開発の仕事を15年以上してきた者で、2D CAD「CADなんです」を自作して販売しています。記事の最後で触れるCADなんですは、筆者自身の製品です。

実験は、AI（Anthropic社のClaude）に実際に答えさせて記録しました。記事の文章もAIの助けを借りて下書きし、筆者が内容を確認して公開しています。使ったDXFはすべて、この実験のために筆者が作った架空の小さな図面です（他社や他人の図面、個人情報は使っていません）。

実験のやり方

日本語の画層名（外形・穴）と日本語の文字を含む、小さな図面（120×60の板に直径12の穴3つ）のDXFを、Pythonのezdxf（1.4.5）で作りました。
これを8通りに加工しました（下の表）。7通りは壊し、1通りは壊さない「対照」です。
Claudeに「取引先からDXFが届いたが開けない。中身を貼る。原因と直し方を教えてほしい」と、ファイルの中身を全部貼って聞きました。どこが壊れているかは伝えていません。同じ質問を2回ずつ（計16回）。
AIの答えと、実際の壊し方を照らして採点しました。

AIは claude -p（ツールなし＝ふつうにチャットへ貼るのと同じ条件）で動かしました。ファイルは約4万3千文字（途中で切れたものは約2万7千文字）で、1回の回答は8〜43秒でした。

実験結果① 原因は、7種類とも当たった

壊し方	AIの診断	2回中
E1 後半を失って途中で切れた	「ファイルが途中で切れている。ENTITIES（図形本体）もEOFも無い」。貼り付け時に切れただけの可能性も挙げ、末尾が `EOF` か確認する方法も示した	2回
E2 先頭に余計な1行（`Content-Type: application/dxf`）	「DXFの中身ではなくHTTPヘッダーが混ざっている」	2回
E3 小数点がカンマ（`120,0`）	「DXFの小数点はピリオド。ロケール（欧州系の設定）の影響」	2回
E4 行が1つ抜けた（2つ目の円のハンドル値）	「2つ目のCIRCLEのハンドル値が抜けて、以降が1行ずれた」。1回は、抜けた値が `8E` であることまで言い当てた（前後の値から）	2回
E5 日本語をcp932（Shift-JIS）で保存した	「文字コードの不整合。日本語がUTF-8として読めない」	2回
E6 区切り（ENDSEC）が1つ抜けた	「CLASSESセクションの終わりの `ENDSEC` が無い」。場所まで特定	2回
E7 中身がHTML（ダウンロード失敗）	「DXFではなくログイン画面のHTML。セッション切れで保存された」	2回

E7は、AIが「ファイルが壊れているのではなく、そもそもDXFが入っていない」と壊れていないことまで説明しました。取引先に再送を頼むときの言い方（「ログイン画面のHTMLが入っていた」）まで添えていました。

E5には注意があります。 筆者はファイルをUTF-8として読んで貼ったため、日本語の部分は文字化け（�のような表示）の状態でAIに渡っています。AIはそこから文字コードを疑いました。AI自身も「貼り付けの過程で化けただけの可能性もある」と書いていました。また、ezdxfの厳密な読み込みでは、このE5はエラーにならず読めました（ezdxfが日本語のコードページを推測して読むため）。「E5が実際のCADで開けなくなる」とまでは確認していません。

実験結果② 壊れていないファイルに、AIは「壊れている」と言わなかった

対照のE8は、何も壊していません。2回とも、AIは「ファイル自体は壊れていません」と答えました。「構造が整っていて、最後の EOF まで揃っている」という説明は、実際のとおりでした。

ただし、その後が推測だらけでした。「CADのバージョンが古いのでは」「日本語の文字コードのずれでは」「図面の表示範囲が未計算で何も見えないのでは」など、可能性を並べています。AI自身も「実際にCADで開けないので、内容から推測した候補」と断っていました。エラーメッセージを伝えずに聞くと、壊れていないファイルにも、原因の候補を並べて返す、ということです。この候補が当たっているかは確かめていません（推）。

実験結果③ 直し方：手作業は通った。「修復ライブラリ」は2種類で通らなかった

AIが示した直し方を、そのとおりにやってみました。

壊し方	AIの手作業の直し方	結果
E2 先頭の余計な行	1行目を消す	読めた（図形5個・円3個）
E3 小数点カンマ	正規表現で `120,0`→`120.0` に置換	読めた
E4 抜けた行	抜けた値 `8E` を戻す	読めた
E6 区切りが無い	`ENDSEC` を補う	読めた
E1 途中で切れた	（後半は無いので補えない。再送を依頼）	直せない（AIもそう答えた）

一方、AIはE1・E4・E6で、Pythonの修復読み込み（ezdxfの recover.readfile）も勧めていました。これを実際に試した結果です。

E1（途中で切れた）：エラーなしで読めたが、図形は0個。「直った」ように見えて、中身は空でした。
E4（行が抜けた）：エラーで読めませんでした。
E6（区切りが無い）：エラーで読めませんでした。

つまり、AIの「修復ライブラリで直せます」は、この2種類では当たっていません。E4には「ずれた箇所が1つだけで済むとは限らない」という注意をAIが添えていましたが、E6では「構造の壊れを再構築できる」という言い方でした。AIが勧めた直し方は、実行して確かめる前提で読んでください。（なお、E3の小数点カンマは、recoverでは読めるものの、数値が正しく直らない箇所が出ました。ここでは確認の範囲を、読めるかどうかに絞っています。）

実験結果④ 「それらしい原因」を信じすぎない

AIが貼り付けから診断できたのは、ファイルの中身が見えているからです。ファイルが大きいと、全文を貼れません（実験で使ったのは約4万3千文字）。大きな図面で同じように診断できるかは、試していません。
診断のあとに「バージョン」「フォント」「表示範囲」といった、関係のないかもしれない候補が付いてくることがありました。当たっているかは、エラーメッセージで絞り込むほうが確実です。

取引先DXFが開けないときの手順（実験から）

まず、ファイルをメモ帳で開く。 先頭が 0 と SECTION ではなく、<html> や Content-Type で始まっていたら、DXFではない（E7・E2）。取引先に再送を頼みます。
末尾を見る。 最後が EOF でなければ、途中で切れています（E1）。再送してもらいます。
AIに貼るなら、エラーメッセージも一緒に伝える。 壊れていないファイルにも候補を並べるので、メッセージで絞るほうが当たります。
AIの直し方は、元ファイルをコピーしてから試す。 手作業の直しは通りやすい一方、修復ライブラリは通らないことがありました。
機密の図面は、外部のAIに貼らない。 会社や取引先のルールが優先です。

試していないこと・限界

Claude 1種類。ChatGPTやGeminiは試していません。再実行は2回ずつです。
実際のCADで開いたわけではありません。「読めた」は、ezdxfの厳密読み込みが通った、という意味です（AutoCAD・Jw_cad・FreeCADでの確認は、していません）。
壊し方は筆者が考えた7種類だけ。実務で見る壊れ方（バージョン違い、DWGをDXFと言い張るファイルなど）は含みません。
AIが示したPythonスクリプト（E2・E3の自動化版）は、実行していません。確認したのは手作業の直し方です。