くまがいブログ

図面提出準備を作り直して、最初に決めるべきだったのは「何を提出対象の正本にするか」でした。OCRの精度を詰める前にここを決めたことで、後段の処理が整理できました。

当初はPDFとDXFを1対1で扱っていましたが、実際にはPDFだけの案件もあれば、1つのDXFに複数図種が入っている案件もあります。

そこで、PDFを提出対象の正本とし、DXFは必要な図種を生成する材料として扱う構成に変えました。

従来の図面整理では、ファイル名や案件区分などから処理方法を判断していました。

主に扱う図種は、平面図・衛生設備図・電気設備図・排水設備図・展開図1・展開図2です。

DXFについても、以前は図種ごとにそれぞれ別ファイルを用意する運用でした。平面図用、衛生設備図用、電気設備図用……というように、提出対象に合わせて複数のDXFを準備する必要がありました。

さらに、ファイル名から図種や対応関係を判断していたため、ファイル名の指定を間違えると処理結果に影響するという弱点がありました。PDFについても出力順を前提にした処理があり、並び順を意識する必要がありました。

このリスクは実際に表面化しており、ファイル名間違い、DXFの取り違え、PDF順番の誤りが起きていました。特にDXFを図種ごとに変換・準備する作業は、取り違えないよう毎回かなり気を使っていました。作業者が正しい順番・名前・DXF構成を守り続ける前提そのものが、負担とミスの発生源になっていました。

既存VBAへ条件分岐を追加していくこともできますが、案件区分・命名規則・ファイル順への依存が増えるほど、例外対応が増えていきます。

実際に必要なのは「どの案件区分から来たか」ではなく、このファイルが何の図面で、提出対象なのかです。

そこで、ファイル内部から図種を判定し、後段では共通のDrawingKindへ正規化する方向へ設計を変えました。

以前は、1件の提出準備について次のような作業をしていました。

PDFを6枚出力
↓
PDFの順番を確認
↓
図種ごとのDXFを複数用意
↓
ファイル名や対応関係を確認
↓
既存ツールで処理
↓
処理結果を確認
↓
レビュー用フォルダへ保存

現在は次の流れです。

PDFを6枚出力
↓
統合DXFを1つ置く
↓
VBSをダブルクリック
↓
自動処理を待つ
↓
OUTPUTを確認
↓
レビュー用フォルダへ保存

比較範囲を、元データを用意してから、処理完了を待ち、結果を確認してレビュー用フォルダへ保存するまでに揃えると、以前は1件あたり約5分、現在は約2分です。現在の約2分は、自動処理が約1分、人が行う準備・確認・保存が約1分という内訳です。

1日2〜3件、多い日には5件程度発生する作業なので、1件あたり約3分の短縮でも継続すると差が積み上がります。

そこで、注意喚起を増やすより、間違えやすい操作そのものを減らすことにしました。

PDFはタイトル文字を通常のテキスト抽出で取得できないケースがあったため、タイトル欄だけOCRします。

一方、DXFにはTEXT / MTEXTなどの文字データがあるため、OCRせず内部情報を直接読みます。

取得経路は違っても、後段では共通の図種IDへ変換します。

厨房配置平面図 → PLAN
厨房衛生設備図 → SANITARY
厨房電気設備図 → ELECTRICAL
厨房排水設備図 → DRAINAGE
厨房展開図1 → ELEVATION_1
厨房展開図2 → ELEVATION_2

初期PoCではPDFとDXFを1対1でペアにしていました。

しかし、統合DXFにはPDFに存在しない図種まで含まれる場合があります。

そこで、PDFに存在する図種だけを提出対象とし、DXFはその図種だけ生成するように変更しました。

PDF: 平面 / 衛生 / 電気
統合DXF: 平面 / 衛生 / 電気 / 排水 / 展開1 / 展開2
↓
生成DXF: 平面 / 衛生 / 電気

PDFのみは許容します。一方、対応PDFのないDXFだけのデータは自動提出せず、REVIEW / BLOCKEDで止めます。

Analyze
↓
Validation
↓
Dry Run
↓
Execute
↓
Verify

未知タイトル、重複、不整合、DXF単独などは実ファイル操作へ流さないようにしました。

固定ROI OCRを復旧した正常系テストでは、6図種すべてをPDFから判定し、同一の統合DXFを参照して提出対象を組み立てられました。

PASS
Rows=6
AUTO=6
REVIEW=0
ERROR=0

このテストでは、平面・衛生・電気・排水・展開1・展開2の6種類をそれぞれ正しく判定しています。

最初の設計では、同じ店舗・Revision・図種のPDFとDXFをペアにする前提でした。

しかし実運用では、DXFが統合ファイルになっているケースがあり、この前提では提出対象を正しく表現できませんでした。

ファイルが存在することと、提出すべきことは別です。

そこで「存在確認」から「提出対象の正本は何か」へ問題設定を変えました。

• PDFを提出対象の正本にする
• PDFとDXFで最も信頼できる情報取得方法を使い分ける
• 後段だけDrawingKindで共通化する
• 不確実なケースはREVIEW / BLOCKEDで止める
• 実ファイル操作前にDry Runを挟む

• PDFとDXFが必ず1対1で存在すると仮定する
• PDFとDXFを同じ解析方式へ無理に揃える
• 案件区分ごとの条件分岐を増やし続ける
• 判定できないケースを推測で自動処理する

最大限自動化することより、提出対象の根拠を一つにし、不確実な状態では止まれることを優先しました。

PDFのタイトルから図種を判定し、PDFに存在する図種だけを提出対象にできます。DXFは図種ごとに用意せず、統合DXF1本から必要なものだけ生成します。

以前に起きていたファイル名間違い、DXFの取り違え、PDF順番の誤りには、確認作業を増やさず、間違えやすい操作を減らす方向で対処しました。

• PDFのみの案件は正常ケースとして扱う
• DXF単独や不整合は自動処理を止める
• 実処理前に出力計画を確認する

• 最新版の異常系テスト
• 実運用でのREVIEW発生率
• 想定外の図面名称が出た場合のルール
• 継続運用後の平均処理時間・REVIEW件数・手戻り件数の実測

• OCR候補や実装方法の比較
• VBAコードの初稿・修正案
• DXF解析ロジックの整理
• エラー原因の切り分け
• テスト観点の整理

• PDFを提出対象の正本にすること
• PDFとDXFの責務分離
• 自動処理を止める条件
• 実際の図面を使った受入判断
• 現場運用として必要なフォルダ・命名ルール

AIにコード生成を任せても、業務上の正本と停止条件は自分で決める必要がありました。

1. データが複数あるときは、先に正本を決める
   • 同じ情報を複数ソースから判断させるより、責任を一つへ集約した方が後段が単純になります。
2. 取得方法は形式ごとに最適化し、後段で共通化する
   • 入力形式まで無理に統一する必要はありません。
3. 成功条件と停止条件をセットで決める
   • 不確実な状態を推測で処理しないことが、実運用では重要でした。

次は、PDFから図種をどう判定したか。避けていたOCRを実際に試した話です。

PDFを正本に決めたことで、OCRとDXF処理の役割が整理できました。ファイルの存在より、実際に提出する図面かどうかを基準にしたのが今回の土台です。

その結果、図種別DXFの準備や並び順の確認を減らし、1件あたりの準備時間も約5分から約2分になりました。