顧客プロフィール
中堅の精密部品メーカーに勤務する機械エンジニアは、製造に回す前の技術図面について、GD&T（幾何公差）の適合性レビューを担当しています。この役割は、仕入先から届く図面と社内設計の成果物の両方にまたがります。現場に渡るものはすべて、部品を切削する前に適用基準に照らして検証されなければなりません。回転部品、ギアトレイン、圧入式スリーブ接続を含むアセンブリは、特にレビューが難しい対象です。寸法の積み上がり、同軸度、振れ公差は、機能と耐用年数に直接影響します。
このチームは、多品種少量の環境で業務を行っており、図面品質は顧客や仕入先によって大きく異なります。明確な標準参照を伴う文書化された所見を出せる、一貫性があり追跡可能な監査プロセスは、仕入先監査や社内設計レビュー会議で判断を裏付けるために不可欠です。図面上の一般的なマーキングだけでは不十分で、品質チームは今や、各指摘が特定の条項と特定の形状に紐づいていることを求めています。
課題
既存のレビュー工程を拡張しにくくしていた構造的な問題は2つありました。
1つ目は参照のボトルネックです。会社が準拠するGD&T標準は、411ページに及ぶ技術ハンドブックです。レビュー中に、その分量の仕様詳細を作業記憶だけで保持できるエンジニアはいません。PDFを別ウィンドウで開き、手作業で検索する従来の方法は遅く、一貫性に欠け、監査記録も標準に裏付けられた所見というより判断の記録にとどまります。レビュー判断が仕入先の品質紛争を乗り切る必要がある場合、ページ参照のない指摘にはほとんど重みがありません。
2つ目は構造化データへのアクセスです。図面は独自形式のDWGファイルで届きました。GD&Tのロジックを適用する前に、エンジニアは図面の注記内容を構造化した表現として取得する必要がありました。具体的には、ペーパースペースのレイアウト、文字列、寸法注記、ブロック挿入、そしてGD&Tの幾何公差枠の候補です。複雑なアセンブリに対して、それをエンティティごとに手作業で行うのは現実的ではありません。スクリプトによる抽出工程がなければ、選択肢は目視確認しかありません。しかしそれでは、エンティティ単位の引用は生成できず、自動化もできず、図面が改訂された際に再現することもできません。
レビュー対象の図面は、ギアとスリーブを組み合わせた鋼製ボビンアセンブリで、両方の問題を同時に示していました。製造意図は読み取れるものの、現代的なGD&T完全性の基準でレビューされたことはありませんでした。すべてのギャップを特定し、それぞれに関連するハンドブック条項を引用し、修正指示とともに起票者へ返せる構造化レポートを作成するには、既存ツールでは支えられないワークフローが必要でした。
なぜ今なのか
仕入先品質要件は段階的に厳格化しており、社内の設計・製造性レビューのチェックリストも更新され、回転アセンブリや精密嵌合アセンブリをリリースする前に、基準参照枠、幾何公差枠、表面性状の指示、検査受入基準について明示的なGD&Tカバレッジを求めるようになっていました。
鋼製ボビンの図面は、その代表例でした。使える形状はあるものの、寸法記入は部分的で、製造メモは意図を示唆しているだけで、更新後の完全性基準は満たしていませんでした。一般的な指摘だけを付けて図面を返すやり方は、もはや許容されません。新しいプロセスでは、標準参照付きの項目別ギャップ提示が必要でした。ギア、スリーブ、ボビン本体からなる多部品の回転アセンブリを、411ページの参照資料に照らしながら、DWGから構造化データへの変換を挟んで手作業で行えば、図面1枚あたり丸1営業日近くかかります。チームが対応していたレビュー件数を考えると、そのペースは持続不可能でした。
energent.aiを選んだ理由
チームがenergent.aiに決める前に、いくつかの代替案を検討しました。
単体のPDF注釈ツールならハンドブック内の用語を見つけることはできても、標準参照を個々の図面エンティティに結び付けたり、構造化された監査レポートを出したりすることはできませんでした。スプレッドシートで版管理された図面チェックリストは一貫性を担保できますが、それでも人が図面と標準を別々のウィンドウで読みながら各行を埋める必要がありました。抽出と相互参照の作業を専門の製図担当者に委託すれば、図面ごとのリードタイムとコストは増える一方で、再現性は向上しません。
他のAIツールも評価しましたが、このレビュー工程には、1回のセッションでまとめて備わっているものが少ない機能が必要でした。つまり、DWG形式のバイナリCADファイルの取り込み、変換と抽出スクリプトの実行、CSVとJSONでの構造化出力、411ページの技術PDFの読み込みと処理、その文書全体にわたるハルシネーションリスクのないクエリ可能な参照の維持、そして引用可能なエンジニアリングレポートの生成です。しかも、環境間での手作業の受け渡しなしに、すべてを1つの一貫したセッションで完結させる必要がありました。
energent.aiが、文書分析と同じエージェントセッション内でPythonとbashスクリプトを実行できることが決め手でした。エージェントはDWGからDXFへの変換を実行し、出力に対して抽出スクリプトを走らせ、エンティティ単位の空間ハンドルを含む構造化テーブルを作成し、そのテーブルをハンドブック参照と組み合わせて、行単位で監査可能なレポートを作成できました。
エージェントはハルシネーションのリスクにも明示的に対応しました。411ページすべてを信頼できる作業記憶に読み込んだと主張するのではなく、文書の長さを考えるとそれは信頼できないと自ら指摘したうえで、ページ単位の意味ノート、概念インベントリ、CSV/JSONの読書ログからなる外部の構造化参照を構築しました。最終レポートのすべての主張は、元文書のページ範囲にたどることができました。この監査可能性は、あれば便利なものではなく、必須要件でした。
Workflow
このセッションでは、元のDWGファイルから最終的なエンジニアリングレポートまで、6段階のパイプラインを実行しました。
Step 1 — DWG to DXF conversion. エージェントはソースファイルに対してCAD変換スキルを実行し、AC1027形式の検証済みDXFを生成しました。これは変換後の整合性チェックで確認されています。ここで重要な構造上の事実が直ちに判明しました。図面の注記コンテンツはほぼすべて、モデル空間ではなく「lito」という名前のペーパー空間レイアウトに存在していたのです。モデル空間を対象にした単純な抽出では、ほぼ空のテーブルしか返らず、図面のGD&T関連コンテンツの大部分を見落としてしまうところでした。
Step 2 — Entity extraction to structured files. 抽出スクリプトが、ペーパー空間レイアウト内のすべてのエンティティを棚卸ししました。対象は、テキスト文字列、寸法注記、ブロック挿入、レイヤー、座標範囲です。出力はJSONの抽出サマリーとして書き出されました。これは図面の機械可読なマップであり、空間ハンドル付きで、下流のレポート内で参照による引用が可能でした。
Step 3 — GD&T candidate isolation. 2本目のスクリプトが、抽出済みエンティティからGD&T関連コンテンツをフィルタリングしました。対象は、公差指示、基準記号、材料条件修飾子、製造上の注記です。結果はGD&T候補の構造化CSVとして書き出され、エージェントはレビュー段階を通じてこれを照会しました。
Step 4 — Handbook reference build. エージェントは411ページのGD&Tハンドブックを、ページ単位の意味ノート、概念インベントリ、CSV/JSONの読書ログという3層の検索可能なレイヤーに処理しました。この設計は意図的なものでした。全文を作業コンテキストに保持しようとするのではなく、構造化された外部参照により、レビュー中にページ範囲の引用付きで概念レベルの検索が可能になりました。この知識ツリーは、今後の図面監査でも索引作成作業を繰り返すことなく再利用できます。
Step 5 — Cross-referenced engineering review. 図面テーブルとハンドブック参照の両方が利用可能になったことで、エージェントは詳細なMarkdown形式のエンジニアリングレポートを作成しました。各指摘には、図面上の位置を示すDXFエンティティハンドルと、標準の根拠となるページ範囲付きのハンドブック概念が引用されています。レポートは、確認済みの良好な実務と重大な不足点を分けて整理し、リリース前に必要なGD&Tの最小追加項目を列挙し、さらに記号や検査図に依存する条項については、元のPDF図版に対する視覚確認が必要であることを明示的にフラグ付けしました。
Step 6 — Deliverable packaging. 4つのファイルが生成されました。変換済みDXF、Markdownのエンジニアリングレビュー報告書、CSVのGD&T候補注釈テーブル、JSONの図面抽出サマリーです。各ファイルはそれぞれ異なる役割を担います。DXFは下流のCADツール向け、レポートは修正依頼向け、CSVとJSONは監査可能な証拠基盤です。
Results
エンジニアリングレビューでは、スチール製ボビンアセンブリ図面における6つの主要なGD&Tギャップが特定されました。
- 図面標準の宣言がない
- 基準参照方式が弱い、または曖昧
- 回転アセンブリに対する振れおよび同軸度管理がない
- 穴パターンに対する位置公差が指定されていない
- 圧入インターフェースの仕様が不十分
- ギア検査要件が合否基準なしで記載されている
7つ目の指摘である、合否基準のない動的バランス要件は、視覚確認ではなく構造化された候補テーブルから浮上しました。これは、純粋な目視レビューよりもエンティティレベルの抽出が有効であることを示しています。
各ギャップは、関連するハンドブック概念とページ範囲に相互参照されており、エンジニアは根拠のない意見の羅列ではなく、各修正依頼に対する文書的な基盤を得られました。レポートでは、図面が適切に行っていた点、つまり修正不要と確認された実務も特定しており、修正依頼は包括的な却下ではなく、焦点の定まった実行可能な内容になっています。
参照面では、411ページのハンドブックが永続的で検索可能な知識ツリーに変換されました。新しい図面ごとに手作業で検索する必要がある静的PDFではなく、チームは今や、エージェントが今後の監査で概念単位に照会できる構造化されたCSV/JSON参照を持っています。DWGの受領から構造化レポートまでの抽出・レビューのパイプラインは、どの図面にも再現可能であり、図面が改訂された際には再実行できます。
Proof
「予想していなかったのは、引用の品質でした。レポート内の各問題には、図面中の正確な注記を指すDXFハンドルと、要件を裏付けるハンドブックのページ範囲が付いていました。手作業で1回のレビューセッションの中でこれを作るのは無理です。すべてを手で突き合わせるだけで、ほぼ丸一日かかるでしょう。」 — Mechanical engineer, precision components manufacturing
エージェントの最終成果物一式には、確認済みの良好な実務、重大な不足点、エンティティハンドルによる図面位置参照、ハンドブックの概念およびページ範囲の引用、そしてリリース前に必要な最小追加項目を整理した完全なエンジニアリングレビュー報告書が含まれていました。GD&T候補CSVは、各指摘の基盤となる追跡可能な注釈インベントリとして機能しました。
Trust note
エージェントは、重要な境界を1つ明確にしています。GD&T記号、公差枠図、検査セットアップ図に依存する指摘は、元のPDF図版に対する視覚確認が必要です。読書ログと概念インベントリはGD&T要件について原理に基づく推論を可能にしますが、図版依存コンテンツに対する人間のレビューの代替にはなりません。このワークフローで作成されるエンジニアリングレポートは、完全な文書トレーサビリティを備えた一次監査として扱うべきであり、最終的なリリース承認ではありません。図面を作成者に戻す前、または製造承認する前に、資格を持つGD&T実務者が記号依存の指摘を確認すべきです。