「AIにPDF図面を読ませる」を失敗させない設計　段階的解析Pipelineの作り方

記事内に広告が含まれています。

会社の図面PDFをAIに読ませようとして、期待した結果が一度で得られなかった経験はありませんか。

工学図面は、一般的な文章PDFとは情報の持ち方が異なります。図枠、表題欄、Revision欄、注記、機器記号、線種、端子、接続線、座標、複数View、Cross-referenceなどが組み合わさって意味を形成するため、文字だけを抽出しても設備構造や接続関係までは確定できません。

この記事では、「PDF全体を1回入力して完成した設備知識を出す」というワンショット方式を避け、原本固定、観測、分類、抽出、関係候補生成、照合、検証、統合を独立したTaskとして反復する設計を整理します。

内容は、DocLLM、MechVQA、IterCAD、GraphRAG関連研究から直接確認できる知見と、図面管理や設備情報構造化の実務から導いた設計提案を分けて記載しています。

工学図面はなぜ普通のPDFと違うのか

一般的な文章PDFでは、段落や見出しをReading orderに沿って取得すれば、文章の主要な意味をある程度維持できます。

一方、工学図面では、文字列の内容だけでなく、その文字がどの記号、線、端子、表、座標、Viewに対応しているかが重要です。

したがって、図面解析では「何という文字が書かれていたか」だけでなく、「どこにあり、何に付随し、どの線や記号と関係するか」をSource Pointerとして保持する必要があります。

1回の解析で完了させない理由

DocLLMは、企業文書の意味がText semanticsとSpatial layoutの交点に存在し、複雑なLayoutの視覚的な手掛かりが文書理解で重要であると説明しています。DocLLM自体は工学図面専用Modelではありませんが、文字列だけに変換すると位置関係を失うという点は、図面解析にも関係します。

MechVQAは、機械図面では高密度な寸法や注記、Domain knowledgeの不足、投影規則や幾何制約下での不安定なSpatial reasoningによって、一般的なMultimodal LLMが重要な手掛かりを見落とし、誤答しやすいと報告しています。

IterCADは、CAD生成と編集に関して、Open-loopのOne-shot生成と現実の反復的な設計作業の間に不一致があるとし、Multimodal agentと実行可能なCAD sandboxによるClosed-loopの複数Turn処理を提示しています。

これらの研究は、同じTaskや同じ図面種を扱っているわけではありません。しかし、次の共通した示唆があります。

• TextだけでなくLayoutや視覚情報を保持する
• 認識できたことと、そこから推論したことを分ける
• 一度の生成結果を完成品として扱わず、外部検証結果を次の処理へ戻す
• 高密度な図面では、重要な手掛かりの欠落を前提にする
• 最終回答だけでなく、根拠となるPage、Region、座標を残す

本記事のPipelineは上記論文の手順をそのまま実装したものではありません。各研究から確認できる知見を参考にし、工学図面の抽出、Revision管理、設備Graph構築へ適用するために再構成した設計案です。

研究から得られる知見と設計提案を分ける

右端の「設計提案」は、論文にそのまま記載された実装手順ではありません。研究結果を図面解析へ応用するための本記事上の提案です。

最初に決めるべき3つの境界

1. 原本の境界

同じDrawing numberでも、Revision、発行状態、保存場所、Scan版、CAD出力版が異なる可能性があります。

解析を開始する前に、どのFileとVersionを対象にしたかを固定します。解析後に同名Fileが差し替えられても、以前の解析結果が別内容へ誤って紐付かないようにします。

2. 権限の境界

図面そのものへのAccess権限と、抽出した設備情報へのAccess権限は分けて考える必要があります。

原本PDFを閲覧できない利用者が、抽出済みのEquipment Recordや接続情報を閲覧できる設計にすると、原本の機密情報が別の形で漏れる可能性があります。

3. 確定情報の境界

OCRが読んだ文字、AIが推論した接続、Validatorで確認した関係、人間が承認した正式情報は、同じ状態で保存してはいけません。

少なくとも、次の状態を区別します。

• Observed：Source上で直接観測した文字、記号、線、座標
• Candidate：観測結果から推論したEntityやRelation候補
• Confirmed：決定論的Checkまたは人間Reviewで確認した情報
• Conflict：複数Sourceまたは複数Extractorの結果が一致しない情報
• Unreadable：対象は存在するが品質不足で読めない情報
• Not present：確認範囲内に対象が存在しないことを検査した結果
• Not evaluated：まだ検査していない状態

Unknown、Unreadable、Not present、Not evaluatedは意味が異なります。これらを一つの空欄にすると、「存在しない」のか「まだ見ていない」のかを後から判別できません。

解析対象の分割軸

分割はToken数や画像サイズだけで決めず、図面の意味境界を優先します。

全体画像とRegion cropは競合しない

Page全体画像は、図面種、全体構成、主要Region、相対位置を把握するために使用します。Region cropは、小さな文字、端子番号、線の交差、Revision記載などを高い解像度で確認するために使用します。

どちらか一方に統一するのではなく、全体Contextと局所詳細をSource Pointerで関連付けます。

推奨する11段階の解析Pipeline

以下では、Stage 0からStage 10までの11段階に分けます。Stage番号は実行回数ではなく責務の違いを表します。同じStageを複数回反復する場合があります。

Stage 0：原本を固定する

解析の開始時点で、対象Fileを一意に識別します。

sourceId
fileId
fileName
drawingNumberCandidate
versionId
eTag
fileSize
contentHash
pageCount
createdAt
modifiedAt
sourceLocation
accessBoundary
ingestedAt

File nameやPathだけを識別子にすると、同名差し替え、移動、複製でSourceを誤る可能性があります。File ID、Version ID、Hashなど、利用可能な複数の識別情報を組み合わせます。

ハッシュ方式が異なる値を直接比較してはいけません。たとえばSHA-256とStorage側の別形式Hashは、同じ内容でも文字列として一致しません。Hash algorithmもRecordへ保存します。

Stage 1：PDFの品質を判定する

同じPDFでも、内部構造は異なります。

• CADから直接出力され、TextやVector lineを保持したPDF
• 図面をScanしたRaster PDF
• Text layer付きScan PDF
• 複数Pageで向きやPage sizeが混在したPDF
• 圧縮により細線や小文字が欠けたPDF
• Color layerやMarkupを含むPDF

最初から全Pageへ同じOCRを適用せず、PageごとにQuality profileを作成します。

Stage 2：Layout inventoryを作る

いきなり設備情報を抽出せず、最初にPage上のRegionを棚卸しします。

• Title block
• Revision table
• Approval block
• General notes
• Legend
• Drawing index
• Main drawing area
• Detail view
• Section view
• Terminal table
• Cable schedule
• Continuation reference
• Grid label

この段階では内容を確定せず、「どのPageのどの座標に、何の可能性があるRegionが存在するか」をInventoryとして登録します。

Stage 3：観測対象を独立して抽出する

文字、記号、線、表を一つのPromptでまとめて完成形へ変換すると、どの観測からどの推論が生まれたか分かりにくくなります。

この段階のRecordはRaw observationです。たとえば、線の近くに「52」という文字があっても、それを直ちにBreaker device numberやTerminal numberとして確定しません。

Stage 4：Domain別に正規化する

Raw observationを設備DomainのEntity候補へ変換します。

Domain ruleとAI推論を混在させず、どのRuleまたはModelで正規化したかを記録します。

Stage 5：Relation候補を生成する

Entityを抽出しただけでは、設備構造は完成しません。図面の価値はRelationにあります。

線が近接しているだけではConnectedToとは限りません。交差点に接続Dotがない、Jump表現がある、別Layerである、Leader lineであるなどの可能性を考慮します。

Stage 6：複数SourceでCross-checkする

図面内の複数Region、別Sheet、別Document、管理Metadataを照合します。

一致しない場合、AIに一方を選ばせて上書き統合せず、Conflictとして両方のSource Pointerを保存します。

Stage 7：ConflictとUnknownを登録する

不一致や読取不能は失敗として捨てず、Review対象として正式に記録します。

{
  "claimId": "CLM-...",
  "claimType": "ConnectedTo",
  "subject": "Terminal-A",
  "object": "Terminal-B",
  "status": "Conflict",
  "evidence": [
    {
      "sourceId": "SRC-...",
      "page": 4,
      "regionId": "REG-...",
      "boundingBox": [0.12, 0.20, 0.31, 0.28]
    }
  ],
  "conflictingEvidence": [
    {
      "sourceId": "SRC-...",
      "page": 7,
      "regionId": "REG-...",
      "boundingBox": [0.55, 0.61, 0.76, 0.69]
    }
  ],
  "reviewState": "Pending"
}

Productionでは、Evidenceに原本へのAccess制御を引き継がせます。利用者がEvidence元を閲覧できない場合に、切り抜き画像やOCR Textだけを無条件で表示しないようにします。

Stage 8：Knowledgeへ統合する

抽出結果を一つの巨大Markdownや一つの巨大JSONへ集約すると、部分更新、同時更新、差分確認、Rollbackが難しくなります。

そのため、Entity、Relation、Claim、Source、Revision、Review EventをAtomic Recordとして分離します。

推奨するRecordの単位

• Source Record
• Drawing Record
• Sheet Record
• Region Record
• Observation Record
• Equipment Record
• Terminal Record
• Cable Record
• Circuit Record
• Relation Record
• Claim Record
• Conflict Record
• Review Event
• Correction Event

図面向けSystem Links

Graphへ直接確定値を書かない

AIが生成したRelationを直ちにGraphの確定Edgeへすると、誤認識が設備構造全体へ伝播します。

Graphでは、Relation本体に加えて、Status、Evidence、Source version、生成方法、Validation結果、Review履歴を保持します。

Relation
  subject
  predicate
  object
  status
  confidence
  evidenceLinks
  sourceVersion
  generatedBy
  validatedBy
  reviewedBy
  createdAt
  supersededBy

Confidence scoreは参考値であり、正しさの保証ではありません。異なるModelのScoreを同じ尺度として直接比較できない場合もあります。

Stage 9：人間向けProjectionを生成する

Atomic RecordやGraphはAIやSystemには扱いやすくても、人間が確認するには不向きです。正本Recordとは別にHuman-readable Projectionを生成します。

• Equipment view
• Power path view
• Terminal and cable view
• Protection scope view
• Interlock view
• Revision comparison
• Conflict list
• Unreadable region queue
• Evidence view

Projectionは正本ではありません。Atomic RecordやGraphから再生成できる派生物として扱います。

HTMLへ表示Dataを直接埋め込む静的方式は、Snapshot reviewや監査に適します。最新Dataを取得するInteractive viewが必要な場合は、認証、権限継承、CSP、CORSを別途設計します。

Stage 10：問題箇所だけを再解析する

Targeted retryでは、PDF全体を最初から繰り返し入力しません。失敗したRegion、Object、Relationだけを選択します。

同じ画像と同じPromptを同じModelへ繰り返し送り、同じ結果が出たことだけで正しいと判定してはいけません。Retryでは、観測条件、Model、Extractor、Crop、Context、Promptのいずれかを変えます。

反復Loopと停止条件

解析は次のLoopとして扱います。

Observe
  → Extract
  → Normalize
  → Generate candidate links
  → Validate
  → Register uncertainty
  → Select next region or relation
  → Retry, Human review, or Stop

停止は「Agentが完了と回答した」ことではなく、できるだけ機械判定可能な条件で決めます。

終了条件

• 必須RegionがすべてProcessed、Unreadable、Not presentのいずれかになっている
• 必須Extractor Taskに未実行状態がない
• Schema validationを通過している
• Critical relationに未評価のCandidateがない
• Cross-page referenceに未解決項目がない、またはReview Queueへ登録されている
• Revision状態がConfirmedまたはConflictとして明示されている
• 全Confirmed ClaimにSource Pointerが存在する
• Retry上限に達した項目がHuman Reviewへ移送されている

停止してはいけない状態

• 必須Pageを取得できていない
• Page countが原本Metadataと一致しない
• Source ID、Version ID、Hashの対応が確認できない
• Title blockとFile nameのDrawing numberが競合したまま未登録
• 最新版かどうか不明な図面をAs-builtとして統合しようとしている
• 一部Pageだけを全Pageとして扱っている
• EvidenceのないCritical relationをConfirmedにしようとしている

複数AI ModelとExtractorの使い分け

複数Modelを使う目的は、同じ質問を複数回行って多数決することではありません。責務や観測条件を分け、誤りの相関を減らすことです。

多数決よりEvidenceを優先する

3つのModelが同じ誤認識をし、1つのModelだけが正しい場合もあります。多数決はSource evidenceの代わりにはなりません。

確定の優先順は、次のように設計します。

1. Source上で直接確認できるEvidence
2. 決定論的なGeometry、Topology、Schema check
3. 承認済みのDomain rule
4. 別SourceとのCross-check
5. 人間によるEngineering review
6. AI Model間の一致

AI Model間の一致は補助情報として利用し、それだけで正式確定しない方が安全です。

代表的な失敗パターンと対策

Revision管理は図面解析と分離できない

設備知識を作る前に、どのRevisionが有効かを確認する必要があります。古い図面から正確に抽出できても、それが現在の設備状態を表していなければ、運用上は誤った知識になります。

区別する状態の例

• Draft
• For review
• For approval
• Issued for construction
• As-built
• Superseded
• Obsolete
• Status unknown

File name、Folder name、Revision table、承認欄のいずれか一つだけで状態を確定せず、矛盾があればConflictとして扱います。

Revision比較で分ける対象

• 追加されたEntity
• 削除されたEntity
• 変更されたAttribute
• 追加または削除されたRelation
• NoteやSpecificationの変更
• Title blockだけの管理変更
• 読取精度差による見かけ上の変更

単純な画像差分だけでは、Scan位置のずれや圧縮差も変更として検出されます。画像差分、Vector差分、OCR差分、Entity差分、Relation差分を分離して評価します。

評価方法は単一の正答率にしない

図面解析は複数のTaskを含むため、一つの総合正答率だけでは改善箇所を特定できません。

Ground truthの作り方

すべての図面を最初から人手で正解化するのではなく、代表的な少数図面から始めます。

• 図面種別
• 年代
• CAD出力またはScan
• 解像度
• 言語
• 記号体系
• Revision状態
• Page密度

評価結果は図面種や品質Groupごとに分けます。高品質なOne-lineでの精度を、低品質ScanのTerminal drawingへそのまま適用できるとは限りません。

会社の図面をAIで扱う際のSecurity

技術的に解析できることと、会社の図面を外部AIへ入力してよいことは別問題です。

最小権限と最小入力

AIへ図面Library全体を渡すのではなく、Taskに必要なDrawing、Sheet、Regionだけを入力します。

ただし、最小入力によってCross-referenceやRevision Contextが失われる可能性があります。そのため、画像そのものを渡さない場合でも、Drawing set、Sheet relation、Source Pointerなどの参照情報は保持します。

原本を変更しない

OCR Text、Crop、Annotation、Entity Graph、HTML Projectionは、原本とは別のArtifactとして保存します。

原本PDFへAI解析用のMarkupを書き込むと、HashやVersionが変化し、原本性や監査性を損なう可能性があります。

GraphRAGを使えば自動的に解決するわけではない

GraphRAGは、EntityとRelationをGraphとして表現し、関連するNode、Edge、Path、Subgraphなどを検索へ利用する方法です。

しかし、元のGraphが誤っていれば、GraphRAGは誤った接続関係を効率よく取得してしまいます。GraphRAG導入前に、次の品質管理が必要です。

• Entity同定
• Duplicate統合
• Relation typeの定義
• Source provenance
• Revision分離
• Conflict保持
• Access control
• Correction反映

汎用的な「entity-relatedTo-entity」だけでは、電気系統、端子接続、保護範囲、Interlock、Revisionを区別できません。Domain relationを定義し、意味の異なるEdgeを分離します。

設備全体ではなく必要Subgraphを取得する

設備全体のGraphやMermaid codeを毎回すべてPromptへ入力すると、対象外の機器や工程がNoiseになる可能性があります。

実際の利用時には、対象Equipment、Trouble、Engineering concernを起点として、必要な範囲のSubgraphを取得します。

対象Equipment
  → 直接接続されたCableとTerminal
  → 上位のPower source
  → 関連するProtection device
  → 関連するControlとInterlock
  → 対応するDrawing、Sheet、Revision
  → 必要なEvidenceだけを取得

何Hopまで取得するかを固定するだけでなく、Relation typeやEngineering concernで範囲を制限します。

既存の図面運用知見との整合

• Whole drawing one-shotではなくTask Queueとして処理する
• Raw observationとEngineering interpretationを分離する
• EquipmentとConnectionを別Recordにする
• Draft、計画図、As-built、Supersededを混在させない
• 全Graphではなく必要なSubgraphを取得する
• Low-confidenceとConflictだけをTargeted retryする
• Original PDFは変更しない
• Source ID、Version、Hashを解析結果へ残す
• 確定できない値を補完しない
• AIの完了宣言ではなく検証条件で終了する

小さく始める実装例

最初からすべての図面種とRelationを対象にせず、1種類の図面と少数のFieldから始めます。

Step 1：対象を限定する

• One-line diagramのみ
• Title blockとRevision tableのみ
• Breaker、Transformer、Motorのみ
• Feeds relationのみ

Step 2：代表図面でGround truthを作る

高品質、低品質、旧版、新版、複数Sheetなど、条件の異なる代表図面を選びます。

Step 3：観測Recordを作る

Text、Symbol、Lineを別々に抽出し、PageとBounding boxを保存します。

Step 4：Candidate Relationを作る

ConfirmedではなくCandidateとしてFeeds関係を生成します。

Step 5：人間ReviewでCorrectionを蓄積する

Correctionを上書き結果だけで残さず、どのCandidateがなぜRejectまたは修正されたかをEventとして保存します。

Step 6：対象範囲を拡張する

安定した後に、Schematic、Terminal、Cable、Protection、Interlockへ段階的に広げます。

よくある選定ミス

1. 高性能なMultimodal LLMなら図面全部を理解できると考える

高性能なModelでも、高密度Annotation、細線、小文字、複数View、Domain rule、Revision差分を一度に完全には処理できない可能性があります。Model性能だけでなく、入力分割、Evidence管理、Validator、Retryが必要です。

2. OCR精度が高ければ接続も正しいと考える

OCRは文字認識の指標です。Line topology、Symbol、Terminal、Cross-referenceの精度とは別です。

3. Confidenceが高い結果を正解と扱う

ConfidenceはModelまたはExtractorの内部的な確信度であり、工学的な正しさを直接保証するものではありません。

4. すべてを一つのKnowledge fileへ集約する

大きなFileは部分更新、同時更新、Revision分離、差分検証が難しくなります。Atomic Recordと再生成可能なProjectionを分離します。

5. 最新らしいFileを自動的にAs-builtとする

更新日が新しいことと、設備の正式なAs-builtであることは同じではありません。Document status、承認、Revision、発行目的を確認します。

6. Graph化すれば元の誤りが解消すると考える

GraphはRelationを明示できますが、誤ったRelationを自動的に訂正する仕組みではありません。EvidenceとValidationが必要です。

参考論文・公開資料

• DocLLM: A Layout-Aware Generative Language Model for Multimodal Document Understanding
• MechVQA: Benchmarking and Enhancing Multimodal LLMs on Comprehensive Mechanical Drawing Understanding
• MechVQA公式Repository
• IterCAD: An Iterative Multimodal Agent for Visually-Grounded CAD Generation and Editing
• A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models
• Microsoft GraphRAG Documentation

こんな人におすすめ

• 工学図面や図面PDFをAIで構造化しようとしている
• 1回の解析では精度が安定しなかった経験がある
• OCR Textだけでは設備接続を再現できず困っている
• 図面からEquipment GraphやKnowledge Graphを作りたい
• RevisionやAs-builtを含めて設備Knowledgeを管理したい
• AIの見落としや誤認識を前提にWorkflowを設計したい
• 会社の機密図面を安全にAIで扱う方法を整理したい

よくある質問

Q. PDFを一気に読ませる方が早いのではないですか？

A. 概要確認や対象Pageの選定には、PDF全体を一度入力する方法が役立つ場合があります。しかし、重要なEquipment tag、Terminal、Connection、Revisionを確定する用途では、見落とし、過剰統合、Evidence位置の喪失を検出しにくくなります。

全体入力を禁止するのではなく、全体観測と詳細抽出の役割を分けることが重要です。

Q. 11段階を必ず順番どおり実行する必要がありますか？

A. 必ずしも直線的に1回ずつ実行する必要はありません。Stageは責務を分離するための区分です。Layout inventoryへ戻ったり、Relation検証後に別Regionを再抽出したりする反復を前提にしています。

Q. 高性能なVision Modelを1つ使えば十分ではないですか？

A. Modelが1つでも、観測、Domain解釈、Validationを別Taskとして実行できます。ただし、同じModelだけに依存すると誤りの傾向が共通になる可能性があります。Criticalな箇所では、別Extractor、決定論的Check、人間Reviewを組み合わせます。

Q. この設計は電気図面以外にも応用できますか？

A. 分割軸、Entity、Relation、Validatorを図面種に合わせて変更すれば、機械図面、建築図面、P&ID、配管図、計装Loop diagramなどにも応用できます。

ただし、記号体系、接続規則、Revision表現、必要なGround truthは図面種ごとに異なります。

Q. CADファイルがある場合もPDFから解析すべきですか？

A. CADファイルにObject、Layer、Block、Attribute、Connection等の構造情報が残っている場合は、その構造を優先的に利用できる可能性があります。PDFは人間向け表示や発行時点のEvidenceとして併用します。

ただし、CAD形式によって保持される情報は異なるため、CADなら常に接続関係を直接取得できるとは限りません。

Q. GraphRAGを導入すれば設備全体を理解できますか？

A. GraphRAGは、関連するEntityやSubgraphを検索して回答へ利用する仕組みです。元のEntity、Relation、Revision、Evidenceが正しいことを保証するものではありません。

先に図面構造化、Relation検証、Conflict管理、Access controlを設計する必要があります。

Q. AIが読めなかった値は人間が補完すればよいですか？

A. 人間が原本を確認して補完することはできます。ただし、AI出力を直接書き換えるだけでなく、誰が、どのSourceを見て、何を修正したかをCorrection Eventとして残す方が、再解析や監査に利用できます。

まとめ

• 工学図面の意味はTextだけでなく、Layout、Symbol、Line、座標、複数View、Cross-referenceの組み合わせで形成される
• PDF全体のOne-shot解析は概要把握には利用できるが、正式な設備Knowledgeの確定には不十分な可能性がある
• 原本、Observation、Candidate、Confirmed、Conflictを分離する
• Page全体Contextと高解像度Region cropを併用する
• Text、Symbol、Line、Tableを独立して抽出する
• EntityとRelationをEvidence付きのAtomic Recordとして保存する
• AIが生成したGraph Edgeを直ちに確定情報として扱わない
• 問題箇所だけをTargeted retryする
• AIの完了宣言ではなく、Schema、Evidence、Conflict、Retry状態で終了を判定する
• 原本PDFは変更せず、ProjectionやAnnotationを別Artifactとして管理する
• 図面の機密区分とAccess権限を抽出Dataにも引き継ぐ

重要なのは、最も高性能なAI Modelを探すことだけではありません。AIが見落とし、誤読し、過剰に関係を統合する可能性を前提に、原本、Evidence、検証、再試行、人間Reviewを含むWorkflowを設計することです。

工学図面をAI可読化する目的は、図面を一度だけ要約することではなく、原本へ戻れるEvidenceを維持しながら、設備、接続、Revision、Decisionを継続的に利用できるKnowledgeへ変換することにあります。

本記事の研究情報は2026年9月10日時点です。MechVQAとIterCADは2026年公開の研究であり、論文やRepositoryが更新される可能性があります。また、本記事のPipelineは設計提案であり、特定製品の性能や安全性を保証するものではありません。会社の図面をAIへ入力する場合は、所属組織の情報管理規程、契約条件、権限、機密区分を必ず確認してください。