交通インフラのCAD監査担当者が、energent.aiを使って12,349個のプリミティブを含むDXF敷地計画図の6種類のオブジェクトを分類した方法

顧客プロフィール

この顧客は、交通インフラコンサルティングに所属するCAD技術者、または都市計画の専門家です。通常は20〜100人規模の企業に在籍し、バスターミナル、鉄道駅、ジャンクションハブなどの交通施設に関する敷地計画図書を管理しています。日々の業務には、数量調書、許認可申請、施工会社への引き渡し資料に使われるCAD図面の保守と監査が含まれます。

この規模の企業では、DXFファイルを意味的に解析する専用ソフトウェアがないことがほとんどです。技術者はAutoCADまたは互換ビューア上で、レイヤーの表示切り替えやブロック属性ダイアログを使いながら、手作業でオブジェクト数を集計します。図面が整然としていて、家具や車両の種類ごとに名前付きの再利用可能なブロック挿入が使われていれば、集計は面倒でも何とか対応できます。しかし、ジオメトリが分解されていたり、部門ごとにブロック命名規則が不統一だったりすると、監査は誤りやすい作業になり、丸一日かかっても最終数値が正しいか確信できないことがあります。

課題

監査対象の図面は、バスターミナルの地上レイアウトを示す複数ゾーンのDXF敷地計画図でした。そこには少なくとも6つの機能カテゴリにまたがるオブジェクトが含まれていました。たとえば、駐車エリアの黄色い車、フードコート区画の椅子とテーブル、車両ベイのバス、そして図面右側にある植栽レイヤーには、大きな樹木と小さな低木が分かれて配置されていました。

表面的には、これは標準的な数量拾いに見えます。実際には、図面には2つの構造上の問題があり、単純なブロック数カウントでは信頼できませんでした。

第一に、駐車区画の黄色い車両は、再利用可能なブロック挿入として配置されるのではなく、分解されていました。整然とした図面であれば33個の車両シンボルで済むところが、この図面では vehiculos レイヤー上に7,504個の線エンティティ、4,778個の円弧エンティティ、67個の円エンティティとして存在しており、合計12,349個のプリミティブに分散していました。数えるべきブロック参照はなく、アナリストは幾何学的な代理指標、具体的には67個の車輪円マーカーから車両数を推定し、図面境界で欠けている、または一部だけ表示されている車両に対する補正係数を適用する必要がありました。

第二に、ターミナル区画の家具および人のアクティビティを示すシンボルには、信頼できる命名規則がありませんでした。最初の分類では、ブロック A$C206D7EC0 の60個を椅子候補、ブロック A$C05075C2A の11個をテーブル候補として識別しました。しかし、どちらの数も誤りでした。目視確認の結果、前者は piso レイヤー上に配置されたドア、または床の開き方向を示すシンボルであり、後者は人物シンボルでした。どちらも家具ではありませんでした。本当のダイニングチェアは別のブロック（0Q62D、mobiliario レイヤー上）で、合計36個ありました。本当のテーブル状家具候補は、人型シンボルとドアシンボルを除外した後で、わずか4個でした。

このような誤分類が1件でもあると、完全な再確認サイクルが必要になります。つまり、ブロックIDの特定、レイヤーの確認、文脈内でのジオメトリ確認、集計の更新、監査出力の再生成です。これらのサイクルを手作業で回す、つまりフィルターダイアログを読み込み、選択セットを再生成し、サブ図面をエクスポートする、といった反復的なCAD作業は、最終結果の妥当性が保証されないまま何時間も消費してしまいます。

なぜ今なのか

交通インフラ案件では、段階的な文書化要件が課されます。バスターミナルが基本設計から実施設計へ進むにつれ、設計チームはコスト見積担当者へ、また公共資金が関わる場合は承認機関へ、検証済みの数量一覧を提出しなければなりません。ドアを椅子として数える、植栽を構造化された駐車区画と混同する、といったオブジェクト種別の誤分類は、材料見積、避難計算、プロジェクト予算に下流の誤差を生みます。

このケースでは、監査は文書引き渡しの前提条件でした。図面は複数の専門分野の寄与を経て進化しており、その結果としてレイヤー名が不統一になり、車両ジオメトリが分解された状態になっていました。技術者は、ファイルを凍結して施工用に発行する前に、信頼できる最終集計を必要としていました。

なぜenergent.aiなのか

技術者にとって、代替手段は限られていました。AutoCADでの手作業によるブロック数カウントには、レイヤーフィルターの設定、カウントコマンドの実行、各結果の手動確認が必要で、A$C206D7EC0 のような意味のないハッシュ文字列のブロックIDが相手では、拡張性に乏しい作業です。DXF解析ライブラリを使って独自のPythonスクリプトを書く方法も技術的には可能でしたが、チームにはそのための開発時間がなく、しかも一度きりのツールになってしまい、対話的な再分類ループもありませんでした。

energent.aiは別のモデルを提供しました。DXFファイルを直接読み込み、Pythonとbashコマンドを実行してジオメトリを解析し、フィルタリング済みの監査DXFファイルを出力し、平易な言葉で分類ロジックを修正しながら反復できる対話型エージェントです。アナリストはコードを書く必要がありませんでした。集計が誤っていれば、修正は一文で済みます。たとえば「それは椅子ではなくドアのシンボルです」と伝えるだけで、エージェントが再分類を実行し、誤集計されたブロックを除外し、同じセッション内で修正版の監査ファイルを生成しました。

特に重要なのは、energent.aiが中間出力ファイル、つまりオブジェクトカテゴリごとのDXFを生成し、技術者が既存のCADビューアで開いて数値を受け入れる前に目視確認できる点です。これにより、単独スクリプトやBIダッシュボードでは再現できない形で、自動解析と人による承認の間のループが閉じられました。

ワークフロー

ステップ1 — ファイルのアップロードとレイヤー確認。 技術者はバスターミナルのDXFをアップロードしました。エージェントはレイヤー名（vehiculos、mobiliario、piso、BUSES、vegetacion）とブロックIDをスキャンし、レイヤーごとの異なるエンティティ種別と件数の暫定一覧を作成しました。

ステップ2 — 車両の抽出。 アナリストは、左上の駐車区画にある黄色い車の数を求めました。エージェントは、vehiculos レイヤーにはブロック挿入がなく、合計12,349個のプリミティブからなる線、円弧、円のジオメトリのみが含まれていることを特定しました。67個の円エンティティを車輪マーカーとして抽出し、車1台につき車輪円2個という前提のもと、図面端の部分的なマーカー1個を考慮して33台と推定しました。専用の監査DXFを生成して目視確認を可能にし、この推定値はブロック数ではなくジオメトリ由来であることを明示しました。

ステップ3 — 家具分類、初回。 エージェントは、中央左のターミナル区画にある家具候補ブロックを識別し、あるブロック60個を椅子、別のブロック11個をテーブルとして返しました。アナリストが監査DXFを確認して分類を修正したところ、60個のブロックは piso レイヤー上のドア、または床の開き方向シンボルであり、11個のブロックは人物図形でした。どちらも家具集計に含めるべきではありませんでした。

ステップ4 — 家具の再分類、修正版。 形状と文脈に基づく修正を適用し、エージェントは再分類を実行しました。mobiliario レイヤー上のブロック 0Q62D を36個のダイニングチェアとして維持し、ドアおよび人物図形をすべて除外した後、4個のテーブル状家具候補（ブロック dfy と SofaA2C）を特定しました。ダイニングチェア、テーブル候補、そして除外した両カテゴリそれぞれについて個別の監査DXFを生成し、アナリストが各除外を独立して確認できるようにしました。

ステップ5 — バスと植栽。 エージェントは BUSES レイヤー上で41個のバスシンボルを識別し、図面右側では5個の大きな樹木ブロックと46個の小さな低木シンボルを区別し、カテゴリごとに名前付きの監査DXFを生成しました。

ステップ6 — 最終監査パック。 エージェントは完全な最終集計表をまとめ、属性付きの全図面DXFを生成し、プロジェクト文書パッケージにそのまま組み込める平易なMarkdown要約を作成しました。

Results

監査の結果、ブロック命名規則が信頼できず、かつ完全に分解されたオブジェクト種別が1つ含まれる図面において、6つのオブジェクトカテゴリの検証済み件数が算出されました。

当初の誤分類3件は修正されました。最初はターミナル列の椅子としてタグ付けされていた60個のドア／床スイング記号、最初はテーブルとしてタグ付けされていた11個の人物記号、そして最初のパスで車両レイヤーと混同されていた植生記号です。各修正サイクルに要したのは、手作業での全面再確認ではなく、1回の対話のやり取りだけでした。

エージェントは、各オブジェクトカテゴリごとに1つ、さらに除外検証用ファイルを2つ加えた計11個の監査用DXFファイルを、完全なMarkdownサマリーとともに生成しました。これにより、本来であれば手作業の集計スプレッドシートになっていたものが、チームの誰でも開いて検証できる、追跡可能なファイル単位の監査証跡に置き換わりました。

Proof

「この図面は3つの専門分野をまたいで手が入っていて、ブロック名は完全に不透明でした。A$C206D7EC0 がドア記号だなんて、1つずつ開いて確認しない限り分かりようがありませんでした。energent.ai が提供してくれたのは、『これはおかしい』と言って、レイヤーマネージャーでもう1時間費やす代わりに、数秒で修正済みファイルを返してもらえる能力でした。」 — CAD technician, transportation infrastructure consultancy

エージェントが作成した成果物である bus_terminal_dxf_tldr.md のMarkdownサマリーと、カテゴリ別監査DXF一式は、任意のDXF対応ビューアで開いて元図面と照合できます。属性付きの全図面DXFには監査の来歴がファイル内に直接埋め込まれており、出力はプロジェクト記録として追跡可能です。

Trust note

黄色い車の33台という件数は、ブロック数の確定値ではなく、幾何学的推定値です。車両は再利用可能な挿入ではなく分解されたプリミティブとして描かれていたため、この件数は、各車が67個の円マーカー合計に対してちょうど2つの車輪円マーカーを寄与するという前提に基づいています。この数値を正式な数量調書や規制当局への提出に用いる前には、分離した車両監査DXFを元図面と目視で照合する必要があります。同様に、テーブルに類する家具候補は、除外フィルタリング後に残った幾何形状を表しています。件数を最終値として扱う前に、各インスタンスが建築意図に合致するかをドメイン専門家が確認すべきです。energent.ai の出力は監査サイクルを加速し、手作業の集計手法では見落とされがちな誤分類を表面化させますが、曖昧な分類に対する技術者の承認に取って代わるものではありません。