AIの構造化データとは？図面・帳票を「AIが使える形」に変える全手法

はじめに：「とりあえずAIに食わせたい」が、なぜうまくいかないのか

「社内に何万枚もある図面や帳票を、AIに読ませて検索・分析できるようにしたい」――情シス・DX推進のご担当者から、いま最も多くいただくご相談のひとつです。ところが、いざPDFやスキャン画像をそのままAIに渡してみると、「なんとなくそれっぽい答えは返るが、肝心なところで間違える」「同じ部品番号を聞いても回答がブレる」といった壁に必ずぶつかります。

その原因の多くは、AIの賢さ不足ではなく、データが「構造化」されていないことにあります。本記事のキーワードである「AIの構造化データ」とは、ざっくり言えば「AIが意味と関係を取り違えずに扱える形に整えられたデータ」のことです。紙図面のスキャン画像はその対極にある「非構造化データ」の代表例であり、ここをどう構造化するかが、AI活用の成否を分けます。

本記事では、まずあらゆる社内データに通じる「AIの構造化データ」の基本を整理したうえで、数あるデータの中でももっとも構造化の難易度が高い「図面・帳票」を代表例として、具体的な実装まで一気通貫で掘り下げます。「いちばん難しいケース」を理解しておけば、契約書・報告書・点検記録といった他のデータへの応用は、ぐっと楽になるからです。

構成としては、前半で情シス・DX推進のご担当者に向けて「構造化データとは何か」「図面はどんな形に整理されるのか」を図解で平易に整理し、後半でAI開発・データエンジニアに向けて「具体的なデータ形式」「実装フロー」「現場のハマりどころ」まで踏み込みます。内容は、社内で実施した調査メモ（査読論文・業界標準・産業実装事例を一次資料で突き合わせ、各主張を敵対的に検証したもの）に基づいており、裏が取れていない点は「未確認」と明記します。煽りではなく、判断材料としてお使いいただける形を最優先にしました。

本記事で扱う論点は次の通りです。

• そもそも構造化データ・半構造化データ・非構造化データは何が違うのか
• 図面・帳票を構造化する「3階層モデル（幾何→意味→関係）」とは
• 構造化された図面が最終的に落ち着く「グラフ／ネットリスト」という形
• 「構造化すれば常にAIに効く」という思い込みの落とし穴（重要）
• スキャン画像から構造化データを取り出す実装フローと、現場の勘所

1. 基礎知識：構造化・半構造化・非構造化データの違い

まず土台を揃えます。データは「どれだけ決まった形に収まっているか」で、おおまかに3種類に分けられます。図面を例にすると、その違いがはっきりします。

ポイントは、同じ「図面」でも、形式によって構造化の度合いがまったく違うということです。すでにCADデータ（半構造化）として持っているなら活用への距離は近く、紙図面のスキャン画像（非構造化）として眠っているなら、まず構造化という一段階が必要になります。本記事が主に扱うのは、いちばんハードルが高い「非構造化のスキャン画像を、どう構造化するか」です。

この3分類は、もちろん図面に限った話ではありません。たとえば顧客マスタや売上テーブルは構造化データ、WordやPDFの報告書・契約書、議事録は非構造化データ、見出しやタグを持つHTML・XML、JSON、各種ログは半構造化データにあたります。AI活用でつまずく多くのケースは、結局のところ「手元にある非構造化データを、AIが扱える構造へどう持ち上げるか」という共通の課題に行き着きます。だからこそ、もっとも難しい図面を題材に「構造化とは何をすることか」を理解しておくと、他のデータにも応用が利くのです。

そして注意したいのが、非構造化＝悪、構造化＝善、という単純な話ではない点です。後半（第4章）で詳しく述べますが、「構造化さえすればAIに効く」とは限りません。まずは「構造化とは、AIが意味と関係を取り違えずに扱える形に整えること」という定義だけ押さえてください。

もう少し補足すると、構造化の度合いは「白か黒か」の二択ではなく、グラデーションで捉えるのが実態に近いです。たとえばWordの文書やHTMLは、見出しや段落といったタグである程度の構造を持つ「半構造化」に位置づけられます。図面でいえば、レイヤ情報や図形要素を保持するDXFは、ピクセルの塊であるスキャン画像よりもずっと構造に近い場所にあります。「自社のデータが、このグラデーションのどこにあるのか」を見極めることが、AI活用の第一歩です。すでに構造化に近い場所にあるデータを優先的に活用し、非構造化のスキャン画像は「構造化のコストに見合うタスクがあるか」を見てから着手する――この順序を踏むだけで、投資対効果は大きく変わります。

2. 図面・帳票を構造化する「3階層モデル」

では、非構造化の図面を構造化するとは、具体的に何をすることなのでしょうか。複数の研究を突き合わせると、図面の構造化は「幾何（ジオメトリ）→ 意味（セマンティクス）→ 関係（トポロジー）」の3階層として捉えると、見通しがよくなります。これは1枚の図面を「線の集まり」から「意味の通じるデータ」へと持ち上げていく、段階のモデルです。

各層をもう少しかみ砕くと、次のようになります。

• ① ジオメトリ（幾何）：座標を持つ図形要素そのもの。線分・円・円弧・ポリライン・点といった「形」だけのデータで、まだ意味はありません。
• ② セマンティクス（意味）：その図形が「何なのか」というラベル付け。たとえば「この円は穴」「この線は寸法線」「この記号は弁（バルブ）」のように、各要素へ意味属性（公差・寸法値など）を与えます。
• ③ トポロジー（関係）：要素同士のつながり、すなわちグラフ構造です。「この配管とこのポンプが接続している」「この寸法はこの辺を指している」といった関係を表します。

この3階層は、複数の査読論文で実際のパイプライン段階として登場します。たとえばP&ID（配管計装図）を対象としたKim et al.（2022, Oxford JCDE）は「物体認識 → トポロジー再構成 → デジタルP&ID生成」の3段で処理し、機械部品図を対象としたZhang et al.（2023, arXiv:2212.00290）は「ベクタ化 → 連結性グラフの構築 → GCN（グラフ畳み込み）による各要素の意味分類」として、この3層を明示的に分離しています。建築のフロアプランでも、VectorGraphNET（arXiv:2410.01336）やGSDiff（arXiv:2408.16258）が壁やジャンクションをノードとするグラフ表現を採用しており、ドメインを越えて同じ発想が使われていることが分かります。

興味深いのは、この「生のデータ → 意味 → 関係」という積み上げが、図面に限らない普遍的なパターンだという点です。文章であれば「文字 → 固有表現（人名・地名などの意味づけ）→ 文と文の関係」、音声であれば「波形 → 発話内容 → 話者間の関係」というように、モダリティが変わっても同じ三段で整理できます。図面の構造化を考えることは、実は「非構造化データを、AIが推論できる形へ持ち上げる」という、データ活用全般に通じる型を学ぶことでもあるのです。だからこそ、ここで身につけた考え方は、契約書・報告書・点検記録といった他の社内文書のAI活用にもそのまま応用できます。

ただし、ここで2点だけ正確に補足します。第一に、概念の積み上げ順（幾何→意味→関係）と、実装の処理順は別物です。実装では「幾何 → 関係（まず線や点をつなぐ）→ 意味（つながり方から何かを推定する）」という順序を取るケースが多く、図1の⚠で示した通りです。第二に、「3階層」を業界公認の統一フレームワークとして命名・提唱した一次文献は、今回の調査では確認できませんでした。各研究がドメインごとに実装している共通パターンを帰納的に整理したもの、という位置づけで捉えるのが正確です。「3層に分けて考えると見通しがよい」という整理の有用性は高い一方、「これが唯一の業界標準だ」と過度に権威付けはしない、というのが誠実なスタンスです。

3. 構造化された図面は「グラフ／ネットリスト」に落ちる

3階層で整理した図面は、最終的にどんなデータの形になるのでしょうか。結論から言うと、多くの場合「ノード（記号・部品）＋エッジ（接続関係）からなる、属性付きの有向グラフ」、電気回路でいうネットリストに相当する構造へ落ち着きます。ノードは「クラス＋幾何＋意味属性」を持ち、エッジは「クラス付きの接続関係」を持ちます。これは業界標準・産業実装・複数論文がよく一致する、確度の高い見立てです。

3階層のそれぞれに、対応する代表的なデータ形式があります。エンジニアの方は、ここが実装の設計図になります。

さらに、図面の種類によって「落ちやすい主形式」が変わります。自社が扱う図面がどれに近いかを見ると、目指すべきデータ形式が見えてきます。

このグラフ化は机上の理論ではありません。P&IDの分野にはDEXPIという標準データ交換フォーマットがあり、そこからグラフDB（Neo4j）へ格納する流れは産業実装として定着しています。Microsoftのエンジニアリングブログ（ISE）によるP&IDデジタル化の実装記録、AWSが提供するP&IDデジタル化ソリューション、研究用のPID2Graphデータセットなどが、いずれも「図面＝属性付きグラフ」という同じ定式化を採用しています。Stürmer et al.（2025, arXiv:2411.13929）も、図面は「属性付き有向グラフ、またはリレーショナルな構造化データで表現できる」と明記しています。

4. 重要：「構造化すれば常にAIに効く」は誤り

定義レベルでは、構造化の有利さは支持されています。「A Survey on Knowledge-Oriented RAG」（arXiv:2503.10677, 2025）は、知識を「非構造（プレーンテキスト）＜半構造（HTML）＜構造化（グラフ）」という構造化度合いで整理し、ナレッジグラフは「構造性により効率的な検索を、意味的な関係により高度な理解・推論を可能にする」と述べています。ただしこれは「構造が処理に有利に働きうる」という性質（アフォーダンス）の記述であって、「常に性能が上がる」という主張ではありません。

むしろ性能面では、条件を間違えると逆効果になります。ICLR 2026に採択されたGraphRAG-Bench（arXiv:2506.05690）の実測では、単純なファクト検索タスクで、素朴なRAG（basic RAG）が60.92%だったのに対し、グラフを使うMS-GraphRAGは49.29%と、むしろ下回りました。グラフ構造は単純なクエリに対しては冗長でノイズを注入し、回答品質を「下げて」しまうのです。論文は、グラフが明確に効くのは複雑なマルチホップ推論・文脈をまたぐ要約・創造的な生成に限定される、と整理しています（「AIが自ら検索し直す」マルチホップ型RAGの実装は、DeepSeek-R1×Difyで作る自己反省型RAGの記事で具体的に解説しています）。

独立した別の検証（arXiv:2502.11371）でも、Natural Questionsで13.4%、time-sensitive（時系列に敏感）な設問で16.6%、グラフ利用によって性能が低下したと報告されています。つまり、「とりあえずグラフ化」はコストをかけて精度を下げる結果にもなりうる、ということです。

これを図面の文脈に引き直すと、判断はより具体的になります。「この図番の部品の材質は？」のように、1か所を引いて終わる問い合わせが業務の大半を占めるなら、表題欄やBOMをテキスト・テーブルとして抽出し、ベクトル検索や全文検索で引ければ十分です（この素朴なベクトル検索の精度自体を底上げする手法は、Contextual Retrieval構築マニュアルにまとめています）。わざわざ全図面をグラフDBに展開しても、検索のノイズと構築・運用コストが増えるだけのことが多いのです。一方で、「ある機器を交換したとき、配管でつながる下流のどの工程・どの図面に影響が及ぶか」のように関係をたどって初めて答えが出る問いが中心なら、トポロジーまで構造化したグラフが本領を発揮します（質問を分解して複数回検索する手法はAgent RAG×Difyの実装ガイドもあわせてご覧ください）。「どんな問いに答えたいか」を先に決め、それに必要な階層までを構造化する――この順番を逆にしないことが、費用対効果を守る最大のコツです。

正しい使い分けは、次のように整理できます。

補足として、表形式データの世界でも「最新・複雑＝最強」とは限らない、という似た教訓があります。表データの予測では、長くXGBoostなどの勾配ブースティング木が深層モデルを上回ると報告されてきました（Shwartz-Ziv & Armon, arXiv:2106.03253, 2022）。ただし2024年以降はTabPFN／TabPFN V2（Nature 2024）が小〜中規模データで調整済みXGBoostに匹敵・凌駕しており、「XGBoostが常に最強」も、もはや現在形の普遍法則ではありません。技術選定は「流行りの構造に寄せる」のではなく、タスクとデータ規模で都度判断するのが鉄則です。

裏を返せば、AI構造化の成否は「どのデータを・どの階層まで・どの形式で構造化するか」という最初の見極めでほぼ決まります。ここは一度設計を誤ると、コストをかけたのに精度がかえって落ちる――という事態を招きかねない領域です。判断には、「自社が答えたい問い（業務）」と「データの特性」の両面を読む目利きが要ります。次章では実装の具体を解説しますが、もし「自社のデータをどう構造化すべきか」で迷う場合は、最初の見極めだけでも外部の知見を借りるのが、遠回りに見えていちばんの近道です（記事末でその選択肢にも触れます）。

5. 実装：スキャン画像から構造化データを取り出すフローと勘所

ここからはエンジニア向けに、非構造化のスキャン画像を構造化データへ変換する全体フローを具体化します。大きくは「前処理 → 要素抽出 → 構造化 → 格納 → 検証」の流れです。

5.1 抽出対象ごとの手法とツール

図面の中には性質の違う情報が混在しているため、抽出対象ごとに手法を使い分けます。1つのモデルで全部を取ろうとせず、適材適所で組み合わせるのが定石です。

5.2 現実的な選択肢（コスト・難易度順）

すべてを自前のYOLO学習やOpenCVパイプラインで組むのは重いため、実務では次の3択から、図面の量・種類・定型度に応じて選ぶのが現実的です。

1. マルチモーダルLLM（Claude／GPT-4o Vision等）で「画像→JSON抽出」：少量・多品種・非定形に強く、立ち上がりが速い。プロンプトで出力スキーマ（JSON）を定義し、表題欄や注記を一気に構造化できます。ただし数値の取り違えは起こりうるため、後述の人間／ルールによる検証が前提です。
2. クラウドDocument AI（Azure／Google／AWS）：表題欄や表（BOM）の抽出が安定しており、大量・定型の図面に向きます。
3. 専用CADベクタ変換サービス（ラスタ→ベクタ）：最終的にCAD（DXF）として復元・再利用したい場合の選択肢です。

5.3 現場のハマりどころ（実体験ベースの注意点）

ここが、PoCと本番運用を分ける部分です。きれいなサンプルでは動いても、現物の図面では次の壁に必ず当たります。

• 手書き・かすれ・青焼き図面はOCR精度が落ちる：前処理の作り込み、あるいは人手補正を前提に設計します。「全自動で100%」を初期目標に置かないことが、プロジェクトを止めないコツです。
• 寸法の100%自動抽出は困難：現実解は「AI抽出 ＋ 人によるチェック」の半自動です。全自動を狙うより、AIが下処理して人が確認する設計のほうが、結果的に早く・正確に回ります（この「AIの下書きを人が修正する」運用設計＝Human-in-the-Loopの具体パターンは、Human-in-the-Loop活用事例9選で詳しく解説しています）。
• 縮尺・単位（mm／inch）の取り違えは致命的：1か所の単位ミスが製造ミスに直結します。抽出値に対する単位・縮尺の検証ルールは必須です（図4の⑤）。
• 紙図面スキャン特有の劣化への耐性は、実運用レベルでは未保証：かすれ・線のモアレ・細線の消失といった劣化に対し、「どんな原図でも安定して動く」とは現時点で保証できません。対象図面のサンプルで歩留まりを必ず先に測ってから、適用範囲を決めてください。

6. まとめ：構造化は「目的」ではなく「タスクに合わせた手段」

本記事の要点を、改めて整理します。

• 構造化データとは「AIが意味と関係を取り違えずに扱える形」。紙図面のスキャン画像は非構造化、CADは半構造化、図番・BOMは構造化と、同じ図面でも度合いが違う。
• 図面の構造化は「幾何 → 意味 → 関係」の3階層で捉えると見通しがよい。ただし実装の処理順は逆になりやすく、また「3階層」は便利な整理であって業界公認の命名フレームワークではない。
• 構造化された図面は、最終的に「ノード＋エッジの属性付きグラフ（ネットリスト相当）」に落ちる。DEXPI→Neo4jなど産業実装でも定着している、確度の高い見立て。
• 「構造化すれば常にAIに効く」は誤り。効果はタスク依存。多段推論・要約にはグラフが効くが、単純検索ではプレーンテキスト＋ベクトル検索のほうが上回ることが実測で示されている。
• 実装は「前処理 → 抽出 → 構造化 → 格納 → 検証」。全自動100%を狙わず「AI抽出＋人チェック」の半自動を現実解に。単位・縮尺の検証は必須。

非構造化のままでは活かせなかった図面・帳票が、目的に合った構造へ整えられた瞬間に、検索・推論・分析の対象に変わります。大切なのは「流行りの構造に寄せる」ことではなく、自社のデータと、やりたいタスクに合わせて、構造化のレベルと形式を選ぶことです。そこを設計できれば、AIは「なんとなく答えるツール」から「意図を正しく汲んでタスクを遂行するパートナー」へと進化します。

最後に、実務で迷ったときの優先順位を一言で。まずは「すでに構造化に近いデータ（図番・BOM・CAD）」から着手し、非構造化のスキャン画像は「構造化コストに見合うタスクがあるか」を見てから取りかかる。そしてグラフ化のような重い構造化は、関係をたどる問いが本当に必要になってから判断する。この2つの順序を守るだけで、無駄な投資を避けながら、着実にAI活用の成果を積み上げられます。

構造化したデータを、実際の製造現場でどう成果につなげるかは、製造業のAI活用事例8選もあわせてご覧いただくと、全体像がつかみやすくなります。

図面・帳票のAI構造化を、自社で進めたい方へ

参考文献・出典

• Kim et al. 2022, Oxford JCDE 9(4):1298 ― P&IDの3段パイプライン（物体認識→トポロジー再構成→デジタルP&ID生成）
• Zhang et al. 2023, arXiv:2212.00290 ― 機械部品図の3層分離（ベクタ化→連結性グラフ→GCNによる意味分類）
• Stürmer et al. 2025, arXiv:2411.13929 ― 図面の属性付き有向グラフ／リレーショナル構造化表現
• Mani et al. CVPRW 2020（C3.ai）― エンジニアリング図面のディープラーニング＋グラフによる自動デジタル化
• VectorGraphNET, arXiv:2410.01336 ／ GSDiff, arXiv:2408.16258 ― 建築フロアプランのグラフ表現
• A Survey on Knowledge-Oriented RAG, arXiv:2503.10677（2025）― 知識の構造化度合いの整理
• GraphRAG-Bench, arXiv:2506.05690（ICLR 2026採択）― グラフが有害になる条件の実測
• 独立裏付け, arXiv:2502.11371 ― グラフ利用による性能低下（NQ −13.4%、time-sensitive −16.6%）
• Shwartz-Ziv & Armon, arXiv:2106.03253（2022）― 表データでのXGBoost優位（時点依存）
• TabPFN / TabPFN V2, Nature 2024 ― 表データ基盤モデルのXGBoostへの匹敵・凌駕
• 業界標準 DEXPI（P&IDの標準データ交換フォーマット）／ Microsoft ISE devblog（P&IDデジタル化）／ AWS P&ID digitization solution ― 産業実装事例

※本記事は、社内で実施した調査（5観点のWeb探索→一次資料22件→主張93件抽出→上位25主張を3票の敵対的検証）に基づき、裏が取れた主張のみを記載しています。具体的なROI数値や、フォーマット粒度（JSON／Markdown／テーブル等のどれが「AIフレンドリー」か）の直接実証は本調査の対象外であり、断定を避けています。