顧客プロフィール
このアナリストは、小規模な自動車エンジニアリングチーム、またはOEMサプライヤーチームの中で、レガシーな2D CAD図面から寸法情報を抽出する業務を担っています。ソース資料はDXFファイルであり、AutoCAD、CATIA、SolidWorksなどのツールから出力される業界標準フォーマットです。下流の利用者には、シミュレーションチーム、製造計画担当、寸法適合性レビュー担当が含まれます。このチームは、リバースエンジニアリングとデジタルツイン準備の交差点で業務を行っており、再構築されたジオメトリの精度が下流のツールやプロセス判断に直接影響します。チームの入力図面の多くは、1つのDXF内に側面図、正面図、平面図がまとめられた単一ファイルの多面図レイアウトで、追加の3D CADモデルはありません。
課題
energent.aiを導入する前、チームはレイヤーベースの奥行き推定アプローチに依存し、2DのDXFジオメトリを擬似3D表現へと持ち上げていました。根本的な問題は体系的な過剰補完でした。ソース図面に十分な多面図カバレッジがない箇所では、アルゴリズムはその領域を未対応としてフラグ付けするのではなく、ヒューリスティックな奥行き値を割り当てていたのです。こうして捏造されたジオメトリは、再構築結果を下流パイプラインで信頼できないものにし、出所データがないため、どの図面領域が特定の寸法差異の原因なのかを診断することもできませんでした。
対象車両については、単一の正本図面ファイル（kavz-3244.dxf）で定義されており、ベンチマークとなる外形寸法は厳密に指定されていました。
- Length: 7,895.0 mm
- Height: 2,820.0 mm
- Width: 2,210.0 mm
旧パイプラインが生成したダッシュボード出力は、これらの目標値に対して実質的に検証できませんでした。見た目は完全な3Dレンダリングが生成されていたものの、各レンダリング面要素を特定のビューや図面領域に結び付ける成果物の連鎖がありませんでした。レンダリングされたモデルと目標仕様の差異は、実際の寸法ギャップなのか、ヒューリスティックな補完による副作用なのかを区別できませんでした。さらに、以前のパイプラインでは複数の中間デバッグファイルや可視化ファイルが生成されていましたが、それらは正式に正本として指定されたことも、後続版に置き換えられたこともなく、どの出力を下流判断に使うべきかチームは不明確なままでした。
なぜ今なのか
信頼できる再構築を実現する必要性は、2つの要因が同時に高まったことで生じました。第一に、下流のシミュレーションチームと製造チームが、再構築ワークフローから引き渡されたモデルの寸法差異を指摘し始めていましたが、出所データがないため、再構築チームはどの図面ビューが各計測値の根拠なのか、またそのギャップが意図的なものかヒューリスティックなものかを説明できませんでした。第二に、チームはちょうどターゲット寸法が完全に指定された車両図面を受け取ったところであり、旧パイプラインの精度を直接かつ公開の形で測定できる具体的なベンチマークが生まれていました。寸法付きベンチマークでの引き渡し失敗は、許容差に吸収される静かな不一致ではなく、目に見える品質イベントになります。チームには、次のベンチマークレビューまでに監査可能で疎な出力を生成できる再構築アプローチが必要であり、しかもスクリプト環境でパイプラインをゼロから作り直すには時間が足りませんでした。
energent.aiを選んだ理由
チームはいくつかの代替案を評価しました。スプレッドシートベースの分析では、DXFジオメトリの解析や複数成果物のオーケストレーションを大規模に扱うことはできませんでした。専門的な3D再構築ソフトウェアは、この1ファイル・証拠優先のワークフローに合わせて構成するには、相当なライセンス投資と深いCAD知識が必要でした。追加のアナリストを採用しても、出所の欠落やヒューリスティック補完の問題は解決しません。これらはリソースの問題ではなく、パイプライン設計の問題だったからです。
energent.aiは、質的に異なる道を提示しました。エージェントはDXFファイルを直接読み込み、セッション内でPythonの再構築スクリプトを実行し、中間JSON成果物を生成・検査し、設定可能なQCゲートロジックを適用し、インタラクティブなHTMLダッシュボードを作成できます。しかも、各ステップの間でコンテキストを失うことなく、1回の反復セッションで完結します。決定的に重要だったのは、プロンプトレベルで証拠優先ポリシーを徹底するよう指示できたことです。つまり、実際にビューデータで裏付けられる箇所だけを描画し、裏付けのない領域は埋めずに疎なまま残し、最終的な3Dパネルでレイヤー持ち上げのヒューリスティックに戻ることを拒否できました。チームの手の届く範囲にある他のツールで、ファイル取り込み、スクリプトによるジオメトリ処理、QCゲーティング、可視化引き渡しを、別個の開発環境や長い実装サイクルを必要とせずに一体化できるものはありませんでした。
ワークフロー
アナリストはkavz-3244.dxfを単一の正本ソースファイルとして読み込み、明示的なターゲット寸法と証拠優先の指示セットを用いて再構築セッションを開始しました。
Step 1 — View segmentation. エージェントはDXFを解析し、側面図、正面図、平面図の各ビュー領域に分割して、専用のセグメンテーション成果物（kavz-3244_view_segmentation_v2.json）を生成しました。アナリストは領域ロールの割り当てを確認し、ラベルがセグメンテーションアルゴリズムの初期化ウィンドウ由来ではなく、最終的なロールを反映していることを検証しました。以前の版では、確定したビュー割り当てではなく初期化ウィンドウに由来する領域名が使われていましたが、アナリストはこれを発見して修正し、その後の処理に進みました。
Step 2 — Feature correspondence. エージェントはビュー間の特徴対応（kavz-3244_feature_correspondence.json）を抽出し、単一ビューの投影ではなく、多面図の証拠に基づいてジオメトリ要素を相互に結び付け、断面の配置を確定しました。このステップこそが、証拠優先の再構築とヒューリスティックな奥行き割り当てを分けるものです。特徴は、再構築された外形内で位置を得る前に、複数のビューに現れていなければなりません。
Step 3 — Section slicing. 対応データを用いて、エージェントは再構築された外形を横断する断面スライス（kavz-3244_section_slices.json）を生成しました。スライスは、ビュー間の裏付けが存在する箇所にのみ配置されました。十分な対応証拠のない領域は空白のまま残され、見た目は完全だが幾何学的には捏造されたモデルではなく、カバレッジの欠落を正直に示す再構築になりました。
Step 4 — Reconstruction QC. 専用のQC成果物（kavz-3244_reconstruction_qc.json）が、設定された各チェックについてゲート通過の証拠を記録しました。アナリストはこの出力を確認し、ゲートが正しい理由で通過していること、つまり単にpass/failフラグが正しいだけでなく、根拠となる証拠が各ゲートの意図と整合していることを検証したうえで、最終的な可視化ステップを承認しました。
Step 5 — Provenance-tagged geometry. 正本となる再構築ファイル（kavz-3244_reconstructed_geometry_v2.json）は、断面ベースのジオメトリを統合し、各要素のソースビューを示す出所タグを付与しました。これにより、レンダリングされたすべての面と、それを支える図面データとの間に追跡可能なリンクが生まれました。
Step 6 — Dashboard generation. エージェントは、メインの3Dパネルでレイヤー持ち上げのフォールバックを禁じる明示的な指示のもと、最終HTMLダッシュボード（kavz-3244_dashboard_v3.html）を生成しました。ダッシュボードは検証済みの再構築成果物からのみ描画されるため、可視化はQCゲート済みパイプラインの出力に直接トレース可能です。2つの以前のダッシュボード版と複数のデバッグファイルは、正式に後継版へ置き換え済みとして扱われ、最終的な正本セットから除外されました。これにより、チームは下流で使用すべき出力を明確に把握できるようになりました。
結果
evidence-first のパイプラインは、以下の成果をベンチマークに対して達成しました。
| Dimension | Target | Achieved | Delta |
|---|---|---|---|
| Length | 7,895.0 mm | 7,895.0 mm | 0.0 mm |
| Width | 2,210.0 mm | 2,210.0 mm | 0.0 mm |
| Height | 2,820.0 mm | 2,763.6 mm | −56.4 mm |
Length と width はターゲットと完全に一致しました。Height は 56.4 mm 不足しましたが、これはソース DXF における top/front view のカバレッジが弱かったことに起因します。これは既知かつ文書化された制約であり、かつ計画で設定された tolerance gate の範囲内に収まっていました。設定されたすべての QC gate は通過しました。
寸法精度に加えて、この再構築は、従来のパイプラインでは実現できなかった 3 つの定性的成果ももたらしました。
- 完全な provenance。 すべての geometry 要素に source-view タグが付与されるため、差異は不透明なものではなく、診断可能になります。56.4 mm の height ギャップは、パイプラインのエラーではなく top/front のカバレッジ不足に起因しており、QC artifact にはその帰属が明示的に記録されています。
- 正直な sparsity。 サポートされていない領域は、ヒューリスティックな depth で埋めるのではなく空白のまま残されるため、下流の simulation および manufacturing チームは、toleranced な判断を確定する前に追加の source data が必要なゾーンを正確に把握できます。
- 追跡可能な dashboard。 HTML dashboard は、raw layer data ではなく、単一の QC gate 済み artifact からレンダリングされるため、レビュー担当者に明確な handoff contract を提供し、以前の未指定の中間ファイル群が生んでいた曖昧さを排除します。
また、このパイプラインは、今後の reconstruction 実行における checkpoint として機能する 5 つの名前付き intermediate artifact も生成しました。これにより、regression の診断や、寸法差異の原因をその発生源までたどるのに必要な時間が短縮されます。
証拠
"The old pipeline would give us a visually complete model, but we had no way to trust it — especially around the roof and front fascia where we had weak drawing coverage. What I needed was something that would show me the gaps instead of hiding them. The energent.ai session rebuilt the entire pipeline around evidence gates, and the QC JSON told me exactly why each gate passed. That's a different class of output than what we had before."
— この case study で説明されている CAD/engineering analyst の役割を反映した composite quote
最終成果物である kavz-3244_dashboard_v3.html は、section-based geometry、provenance-tagged elements、そして寸法サマリーパネルを備えた pseudo-3D reconstruction を提示します。QC artifact (kavz-3244_reconstruction_qc.json) は、dashboard の根拠となる gate-pass の証拠を提供し、あわせてレビュー可能です。
信頼に関する注記
ここで説明されている reconstruction は、単一の 2D DXF source から導出された section-based の pseudo-3D 表現であり、完全な parametric CAD model ではありません。56.4 mm の height 不足は、source data の top/front view coverage における実際の制約を反映したものであり、product defect ではなく、visualization parameters を調整しても消えるものではありません。この出力を downstream simulation、manufacturing tooling、または dimensional compliance review に使用するチームは、toleranced な判断を確定する前に、sparse な領域を追加の source drawings または point-cloud data が必要なものとして扱うべきです。agent の QC gates は reconstruction pipeline の内部整合性を確認しますが、外部の寸法規格への適合を認証するものではなく、物理測定プロトコルの代替にもなりません。