Claude Codeで配管図の材料拾いを自動化した話

配管図から管材を手で拾う作業をClaude Codeで自動化した。座標だけの暗闇との格闘記録。

配管図を広げて、管番号を1本ずつ目で追う。口径、管種、延長。図面の端から端まで確認して、Excelに手で入力していく。

水道工事の書類を作ってると、この「材料拾い」という作業が何度もやってくる。何十本もある管を1本ずつ図面から読み取って、リストにまとめる。間違えたら数量が合わない。地味で、手間で、でも絶対に必要な作業。

これをAIにやらせたい。そう思って始めたことが、思った以上に大ごとになった。

PDFからの読み取りは、もうできてた

実はこの時点で、配管図のPDFから管材を読み取るスキルはすでに作ってあった。Claudeの画像認識を使って、PDFの配管図を読ませてCSVに起こす仕組み。

動いてはいた。ただ、PDFは画像ベースだから、どうしてもOCRの読み間違いが起きる。管のシンボルマークの横にある小さい数字とか、90°回転した文字とか。精度に限界があった。

ChatGPTに「簡単にできるよ」と言われた

あるとき、ChatGPTに水道工事の数量計算をAIで自動化できないか聞いてみた。

チャッピーが出してきた構成案はこうだった。

「作業時間：半日〜1日 → 10〜15分」という威勢のいい話。

ここで初めて「ezdxf」というPythonのライブラリの名前が出てきた。CADのDXFファイルを読み込んで、管の長さや管種、継手の情報を取得できるという。

ほんまかいな、と思いつつ、Claude.aiに検証してもらった。

Claude.aiの返事は冷静だった。「チャッピーの提案は全体の流れとしては正しいけど、一番難しい『CADから条件を正確に読み取る』部分を簡単に書きすぎてる。ここが全体の8割くらいの難しさ」と。

でもDXFにはテキストデータがそのまま入ってるから、PDFのOCRと違って読み間違いは起きない。それだけで十分やる価値がある。

チャッピーに騙された、、、とはこの時点ではまだ思ってなかった。

DXFの中を覗いてみたら

DXFファイルをClaude.aiに読ませてみた。

レイヤーは分かれてる。ブロックも認識できる。文字も読める。

正直、この時点では「なんだ、いけるやん」と思ってた。

ところが、そこから先で世界が変わった。

DXFの中身を詳しく見ていくと、そこには図面の「絵」はなかった。あるのはXY座標のポイントだけ。ブロックの挿入点、文字の配置座標。視覚情報がない。

暗闇の中で座標だけを頼りに世界を把握しろと言われてるようなものだった。

正直、呆然とした。こんなに違うのかと。

人間が配管図を見ると、管がどう繋がっていて、どの管にどの番号がついてるか、一目でわかる。でもDXFのデータとしては、それは「座標(1234.5, 678.9)にブロックAが挿入されてる」「座標(1240.1, 680.2)にテキスト"φ200"がある」という数値の羅列でしかない。

チャッピーに騙された、と気付いたのはこのときだった。「簡単にできる」は大嘘やん。

でもそこから「じゃあ座標をもとに想像で補ってもらえばいいやん」とひらめいた瞬間は、ちょっとうれしかった。

暴走気味の新人に仕事を教える

Claude.aiに「DXFからデータを取って」と雑に投げてみた。

ここで少し補足しておくと、この開発では Claude.aiとClaude Codeの2つを使い分けていた。Claude.aiは相談相手で、Claude Codeが実際にコードを書いて実行する作業者。非エンジニアの自分にとっては、Claude.aiに相談してClaude Codeへの指示を組み立ててもらうという使い方がしっくりきた。以降、チャット画面に出てくるClaudeは「Claude.ai」と書く。

Claude Codeはそれなりの答えを返してきた。座標の近いものを紐づけて、管番号と管材をマッチングさせて。その場の計算で、なんとか正解っぽいものを出してきた。

でもそれを見て怖くなった。

この場当たり的なやり方を次の工事でもやらせたら、えらいことになる。今回の図面でたまたま合ってただけで、管の向きが違う図面や、ブロックの構造が違う図面が来たら全部崩れる。

ここから、自分が見えている世界をClaude.aiに教え込む方向に切り替えた。

配管図のブロックは、挿入点の座標と回転・反転の情報だけじゃない。ブロックの中身を開いて、その大きさを測って、起点からどう配置されてるかを考えてもらう必要がある。

「管種のシンボルマークのブロックと管種の意味を持つブロックを二つセットにして、一つの管を表してるの。シンボルマークは管種によって受け側の表記が違う。その部分だけで一つのブロック。それに45°に曲がったブロックを足して45°曲管を表してるんです」

こういう説明を、その場その場で必死にやっていた。当時は整理された考えで教えたわけじゃない。目の前の問題に対して、自分が知ってることを言葉にして伝えて、Claude.aiに理解してもらおうとしてただけ。

ezdxfをインストールできない問題

技術的な壁もあった。Claude.aiのCowork環境ではネットワーク制限があって、ezdxfをpip installできなかった。

じゃあどうしたか。自分のPCで `pip download ezdxf` を実行して、必要なファイル5つを手動でCoworkにアップロードした。非エンジニアがターミナルでコマンドを打って、ライブラリのファイルを手動で持ち込む。力業だった。

でもCoworkだとセッションが切れるたびにezdxfを再インストールしないといけない。コンテキスト圧縮もかかって、Claudeが文脈を見失う。

「昨日作成してくれたスキルなのですが、Pythonでつかうezdxfを毎回インストールしなければならないのと、今後新たな工事の時には修正が必須の現状であり、スキル完成までに幾度も圧縮がかかったことからClaude Codeでの運用を行った方が良いのではないかと思いました。」

とチャットの続きで宣言。Claude Codeに移行した。ここからv3、本格的な開発が始まった。

3日間で3バージョン、20時間超の格闘

Claude Codeでの開発は、文字通りの格闘だった。

• 3月9日：v1完成（テキスト座標ベース。管材45件抽出）

• 3月10日：v2完成（引出線マッチング導入。52/52完全一致）

• 3月11日〜：v3開発開始（GXシンボルチェーン方式。ここからが本番）

v3だけで6セッション、20時間超。コンテキスト圧縮は合計14回。

テスト用に用意した配管図は4枚。元は3枚だったけど、2枚目が上下2段構造だったので分割して4枚にした。全部同じ工事のもの。

1枚目のDXFでは、うまく動いた。管番号も管材も、きれいに一致した。

ところが2枚目に取りかかると、管の向き（受口の方向）が1枚目と逆だった。ライナーの位置が全部ズレて、正しい場所に配置されない。

ここからがこの開発の一番の山場だった。

Claude Codeが補正値で力技の辻褄合わせを始めた。chain - 0.25、chain + 0.75、min(c1, c2) + 0.5。パターンを変えるたびに、テスト1は通るけどテスト2が壊れる。その逆もある。堂々巡り。

Claude Codeが何をやっているのか、自分には直接は見えない。でもClaude.aiに相談すれば、Claude Codeの処理を噛み砕いて説明してくれる。Claude.aiという「通訳」がいたから、非エンジニアの自分でもClaude Codeと一緒に開発を進められた。

「この(chain - 0.25)とかは何を行っているのですか？」とClaude.aiで聞いた。
「無理矢理補正値で当てはめている気がします」とClaude.aiに伝えた。

何か根本的に違う。その直感は正しかった。

結局、自分が現場で当たり前に知っていたルールをClaude.aiに伝えたら、堂々巡りは一発で解けた。

最終的に、配管図から読み取れるデータはほぼ全て自動で抽出できるようになった。

• 管番号

• 継手番号

• 管種・管材名

• 口径

• 延長

• ライナーの有無と位置

• 施工日

手で拾ったら何時間もかかる作業が、コマンド一つで終わる。

最後に行った4枚全てを纏めて出力するセッションは1分で終わった。「inputに有る配管図を読み込んでCSVを出力してください」の一言で、4ファイル完了。最初のセッションが2日間かかったことを思うと、ちょっと感慨深い。

振り返って思うこと

暴走気味の新人を育ててる気分だった。言ったことは覚えてるし、計算も速い。でも自分で勝手に解釈して突っ走る。それを止めて、考え方から教え直す。

手のかかる新人だった。でも、こいつに教えてるつもりで、気づいたら自分も一緒に賢くなってた。それに気付いたとき口元がにやけた。

「考え方を教えてあげる必要があるんですね。その辺りも今後伝えられるよう頑張る！」

開発中に自分が書いたこの言葉が、たぶんこの経験で一番大事な気づきだった。

AIはコードを書くのは速い。でも「なぜそうなるか」の物理ルールは、現場で書類を作ってる人間にしかわからない。プログラミングの知識がなくても、業務知識がAIを導く武器になるんじゃないかと思う。そしてClaude Codeの敷居が高くても、Claude.aiが間に入ってくれれば、非エンジニアでも一緒に開発ができた。少なくとも自分はそうだった。

回り道だったかもしれない。でもこの過程で、AIが見ている世界が少し覗けた気がした。座標だけの暗闇の中で、どうやって図面を「理解」するのか。それを教えるために、自分自身が図面をどう見ているのかを言語化しなきゃいけなかった。

考えてみたら、それは自分の仕事を初めて言語化した経験でもあった。

同じ立場の人へ

もしあなたが非エンジニアで、AIを使って業務を改善したいと思ってるなら。

まずは、自分の業務で「手間だな」と思ってることを1つ選んで、AIに「これ、自動化できる？」と聞いてみてほしい。ChatGPTでもClaudeでも何でもいい。

楽観的すぎる答えが返ってくるかもしれない。でもそれがAIと付き合うきっかけになると思う。

使用ツール: Claude.ai、Claude Code、ezdxf（Pythonライブラリ）
開発期間: 約2週間（2026年3月9日〜17日）
総セッション時間: 20時間超（うちSession 5が11時間）
コンテキスト圧縮: 合計14回（初心者の失敗、非推奨です）

ここから先は、この開発で実際にぶつかった壁とその解決の詳細を書いている。ライナー問題の全貌と「受口は左にきます」の一言がすべてを変えた瞬間。乗り越えた先にも待っていた管番号・継手番号の格闘。Claude.aiがClaude Codeとの間をどう取り持ってくれたか。たぶんAIを使い書類作成を行う際、躓いた問題を乗り越える一助になると思います。