導入：現場の「あの図どこ？」を解決するために
「マニュアルのどこかに配線図があったはずなんだけど、キーワード検索しても出てこないんだよ」
製造現場や保守メンテナンスの最前線で、このような問い合わせに時間を奪われていませんか？
システム開発の現場では、往々にして「すべての情報はデジタル化されているのだから、検索すれば見つかるはずだ」と考えがちです。しかし、現場の現実はもっとシビアです。特に製造業の技術マニュアルや保守手順書（PDF）において、最も重要な情報は「テキスト」ではなく「図解」に含まれていることが少なくありません。
部品の形状、取り付け位置の微妙なニュアンス、配線の色と順序。これらはテキストで表現しきれるものではなく、図を見て初めて理解できる情報です。従来のテキストベースのRAG（検索拡張生成）やFAQシステムでは、この「視覚情報」が完全にブラックボックス化しており、検索対象から漏れていました。
いわゆる「死蔵データ」です。
本記事では、この死蔵データを「マルチモーダルAI」の力を使って検索可能な資産に変えるための、具体的かつデータ処理パイプラインの構築手法について解説します。PoC（概念実証）に留まらない実用的なAI導入を目指し、実際にどのようにPDFから画像を切り出し、AIに理解させ、データベースに格納するかという、エンジニアリングの実践的なアプローチを紐解いていきます。
1. なぜ「テキスト検索」だけでは現場の課題が解決しないのか
テキスト情報と視覚情報の埋まらないギャップ
まず、多くのプロジェクトが直面する課題の本質を整理します。なぜ、高機能な全文検索エンジンを導入しても、現場のエンジニアは「必要な情報が見つからない」と嘆くのでしょうか。
それは、人間が情報を探索する際のメンタルモデルと、従来のテキスト検索システムの仕組みに大きな乖離があるからです。
例えば、保守員が目の前の破損した部品を見て、「この特殊な形状のコネクタの交換手順を知りたい」と考えたとします。頭の中にあるのは「L字型でピンが密集しているコネクタ」という視覚イメージです。しかし、マニュアル上の正式名称が「高密度D-sub 15ピンコネクタ（ライトアングル型）」だった場合、「L字型 コネクタ 密集」と検索しても、期待する結果はヒットしません。
さらに深刻なのは、トラブルシューティングの場面です。「LEDが赤く点滅して、その横のレバーが下がっている状態」といった複合的な状況は、テキストだけで的確な検索クエリを組み立てるのが非常に困難です。
ここで従来の技術的な限界が露呈します。マニュアルにはその状態を示した「図解」が存在するはずですが、一般的なOCR（光学文字認識）技術では、図の中にある文字情報は抽出できても、「LEDが光っている」「レバーが下がっている」といった状態や文脈（コンテキスト）まではデータ化できないケースが大半だからです。
マルチモーダルRAGがもたらす検索体験の変革
ここで解決策となるのが「マルチモーダルRAG」です。従来のRAGがテキストデータのみを知識源としていたのに対し、マルチモーダルRAGはテキストと画像（場合によっては図面データのメタ情報）を統合的に扱います。
最新のマルチモーダルAIモデルを活用することで、以下のような革新的な検索アプローチが可能になります。
画像で検索する（Image-to-Text/Image）:
現場で撮影した部品やエラー画面の写真をアップロードすると、AIがその視覚情報を解析し、マニュアル内の類似する図版や、その部品に関する記述ページを提示します。自然言語で画像を検索する（Text-to-Image/Text）:
「赤いランプが点灯している配線図」や「レバーが下向きの時の回路図」と入力すると、AIが図の内容を理解し、該当する図解そのものを検索結果として表示します。
これにより、現場の担当者は高度な言語化能力や正確な専門用語の知識に依存せず、直感的な検索が可能になります。これは単なる利便性の向上ではなく、情報のアクセシビリティを根本から変えるものです。
期待されるROI（工数削減効果）
AIはあくまでビジネス課題を解決するための手段であり、この技術の導入効果は、現場の工数削減として明確に現れます。多くの製造現場や保守チームでは、以下のような課題解決が報告されています。
- ベテランへの依存度低減: 若手エンジニアが画像検索を使って自力でマニュアルを特定できるようになり、ベテラン社員への問い合わせ時間が大幅に削減されます。
- 作業手戻りの防止: 正しい部品や手順を視覚的に確認してから作業に入れるため、誤った部品発注や手順ミスによる手戻りが減少します。
- ダウンタイムの短縮: トラブルシューティングにおいて、現象（画像）から解決策（マニュアル）へ最短距離で到達できるため、設備停止時間が短縮されます。
「図が見つからない」ために発生する確認電話、マニュアルの再送付、最悪の場合は誤った対応による二次被害。これら現場のロスを積み上げると、マルチモーダル化への投資対効果（ROI）は、業務効率化の観点から非常に高い水準になることが期待できます。
次章からは、このシステムを実現するための具体的なデータ処理フローについて解説します。
2. データソースの分解：PDFマニュアルからの構造化抽出
ドキュメントレイアウト解析（DLA）の重要性
ここからがエンジニアリングの本番です。多くのプロジェクトで最初につまずくのが、PDFという「非構造化データの塊」をどう処理するかという問題です。PDFは人間が見るために最適化されており、マシンが読むようには作られていません。
単にテキストを抽出するだけなら PyPDF2 などのライブラリで十分ですが、マルチモーダルRAGを構築するには、PDF内の「どこに図があり、どこに表があり、どこが本文か」を正確に識別する必要があります。これを「ドキュメントレイアウト解析（Document Layout Analysis: DLA）」と呼びます。
テキスト、表、画像の分離技術
実践的なアプローチとして、Unstructured ライブラリや、Azure AI Document Intelligence などのクラウドOCRサービスの活用が考えられます。特にオープンソースで構築する場合、Unstructured のパーティショニング機能は強力です。
具体的な処理フローは以下のようになります。
- 要素の検出: ページ内の要素を「Title」「NarrativeText」「Image」「Table」に分類します。
- 画像のクロッピング: 「Image」と判定された領域の座標情報を元に、元のPDFから画像データを切り出します。
- 解像度の確保: ここで注意が必要です。PDF埋め込み画像は往々にして解像度が低く、そのままではAIが認識できません。切り出し時にDPI（dots per inch）を指定して高解像度化するか、超解像（Super Resolution）AIを通して補正するプロセスを挟むことが、後の検索精度に直結します。
表（Table）データについても同様です。表は画像として扱うよりも、HTMLやMarkdown形式のテキストに変換して保持する方が、LLM（大規模言語モデル）が理解しやすくなります。
図解とキャプションの紐付け処理
もう一つの大きな課題は「コンテキストの喪失」です。マニュアルでは、図の下に「図1-2: 電源ユニットの接続図」といったキャプションが付いています。しかし、単純に要素分解すると、図は図、キャプションはただのテキストとして切り離されてしまいます。
これでは、図の意味が失われます。
対策として、座標情報を活用した「ヒューリスティックな紐付け」ルールを実装します。「画像要素の直下（または直上）にあるテキストブロックは、その画像のキャプションである可能性が高い」というロジックで、画像データとテキストメタデータを結合させます。この処理が甘いと、いくら高性能なAIモデルを使っても、「何の説明もない謎の図」が大量に生成されるだけになってしまいます。
3. 画像データの意味付け：Embeddingとキャプション生成
画像エンベディング（CLIP等）の仕組み
切り出した画像データを、どうやって検索可能にするか。ここには2つの主要な戦略があります。1つ目は「ベクトル化（Embedding）」です。
OpenAIのCLIP（Contrastive Language-Image Pre-Training）に代表されるマルチモーダルモデルを使用します。CLIPは、テキストと画像を同じベクトル空間にマッピングする能力を持っています。
例えば、「犬」というテキストのベクトルと、犬の画像のベクトルが、空間上で近くなるように学習されています。これを利用すれば、ユーザーが入力したテキストクエリをベクトル化し、それと距離が近い画像ベクトルを探すことで、画像検索が実現できます。
ただし、CLIPは一般的な物体認識には強いですが、製造業特有の「部品図面」や「回路図」のような専門的な画像に対しては、そのままでは精度が出ないことがあります。「丸い部品」とは認識できても、「型番X-99のガスケット」とは認識できない可能性があります。専門領域に特化させるためには、独自の画像とテキストのペアデータを用いてファインチューニングを施すアプローチも有効です。
VLM（視覚言語モデル）による説明文生成
そこで重要になるのが、2つ目の戦略、「VLM（Vision Language Model）による説明文生成（Image Captioning）」です。
OpenAIのChatGPTやAnthropicのClaude、あるいはLLaVAのような視覚言語モデルを使用して、切り出した画像に対して詳細な説明文を生成させます。
特に注意が必要なのはモデルの選定とライフサイクル管理です。AIモデルの進化と世代交代のスピードは非常に速く、かつて主流だったモデルが数ヶ月で非推奨や廃止となることは珍しくありません。
例えばOpenAI APIの環境では、GPT-4oやGPT-4.1といった旧モデルが廃止（2026年2月時点）され、より高度な画像理解や長い文脈の処理能力を備えたGPT-5.2（InstantおよびThinking）が新たな標準モデルへと移行しています。また、Anthropicの環境でも、長文コンテキスト推論やAdaptive Thinking（適応型思考）を備えたClaude Sonnet 4.6が主力としてリリースされるなど、常に最新動向をキャッチアップする必要があります。
システムに組み込む際は、突然のAPI提供終了によるシステム停止を防ぐため、常に各社の公式ドキュメントで「現在推奨されている最新モデル（Production-ready）」を確認し、迅速にモデルを切り替えられる設計にしておくことが重要です。
プロンプトの例としては、以下のような指示を与えます。
「この画像は産業機械の保守マニュアルの一部です。画像に描かれている部品の名称、形状の特徴、接続されている配線の色、および図中のテキスト（注釈）を詳細に説明してください。」
これにより、画像データは「リッチなテキスト情報」に変換されます。この生成されたテキストを従来のテキスト検索エンジン（またはテキストベクトル検索）にかけることで、CLIP単体では拾いきれなかった詳細な条件での検索が可能になります。
メタデータとしての「図番」「部品ID」付与
AIによる自動処理だけでなく、決定論的なメタデータの付与も忘れてはいけません。
前章で抽出したキャプションに含まれる「図番」や、本文中でその図が参照されている箇所の周辺テキストから抽出できる「部品ID」などを、画像のメタデータとして確実に保存します。現場では「図番 A-103 を見せて」という指名検索のニーズも根強いからです。
AIによる曖昧検索と、メタデータによる厳密検索。この両輪を回すためのデータ準備が、ここでの勝負所です。システム全体の検索精度を底上げするためには、こうした地道なメタデータ設計が大きな意味を持ちます。
4. データパイプラインの構築とインデックス設計
マルチモーダル対応ベクトルDBの選定
加工したデータを格納する器、すなわちベクトルデータベースの選定です。最近のベクトルDBはマルチモーダル対応が進んでいますが、以下の要件を満たすものを選ぶ必要があります。
- マルチベクトル対応: 1つのドキュメント（この場合は図解）に対して、画像のベクトル（CLIP等）と、説明文のベクトル（テキストEmbedding）の両方を保持できるか。
- メタデータフィルタリング: 「機種Aのマニュアルに限る」といった絞り込み検索が高速にできるか。
Weaviate、Qdrant、Milvusなどが有力な候補です。特にWeaviateは multi2vec-clip モジュールなどを標準で備えており、マルチモーダル検索の実装コストを下げてくれます。
ハイブリッド検索（キーワード×ベクトル）の実装
検索ロジックの設計においては、「ハイブリッド検索」が重要です。
- キーワード検索（BM25など）: 「型番」や「エラーコード」など、完全一致が求められるクエリに強い。
- ベクトル検索（Dense Retrieval）: 「〜のような形」「〜の配線方法」といった、意味的なクエリに強い。
これら2つのスコアを統合（RRF: Reciprocal Rank Fusionなどで再ランク付け）して結果を返します。
画像検索の場合、さらに「画像ベクトルによる検索」と「画像説明文（テキスト）のベクトル検索」を組み合わせることになります。製造業のマニュアル検索では、「画像説明文のテキストベクトル検索」が最も高いヒット率を出すと考えられます。画像そのもののベクトル検索は、補助的に使う（例えば、類似画像検索など）構成が、現時点での技術レベルでは実用的です。
データ更新の自動化フロー
システムは作って終わりではありません。マニュアルは改訂されます。
PDFが更新された際、差分のみを検知して処理するパイプラインが必要です。全件再処理はコストと時間がかかりすぎます。ファイルのハッシュ値を管理し、変更があったファイルのみ、再度「分解→Embedding→DB更新」を行うワークフローエンジン（AirflowやPrefectなど）を組み込みましょう。
また、古いバージョンの図解が検索結果に出てくると現場の混乱を招きます。メタデータに「バージョン情報」や「有効期限」を持たせ、検索時にフィルタリングする設計も必須です。
5. 検索精度の評価と継続的な改善サイクル
マルチモーダル検索の評価指標
構築したシステムの良し悪しをどう判断するか。テキスト検索なら正解文書が含まれているかどうかのRecall（再現率）で測れますが、画像検索はもっと主観的です。
現場のエンジニアと協力して作成する「ゴールデンデータセット」による評価が有効です。
- クエリ: 「電源ユニットの交換手順図」
- 正解画像: 図3-4、図3-5
このようなペアを50〜100件用意し、システムが正解画像を上位（例えばTop 5）に出せているかを Recall@5 などの指標で定量化します。ここで重要なのは、テキスト検索だけではヒットしなかったが、マルチモーダル化によってヒットするようになった件数を測定することです。これがそのまま、本プロジェクトの付加価値となります。
現場フィードバックのループ化
定量評価以上に大切なのが、ユーザーの行動ログです。
- 検索結果のクリック率（CTR）: 画像が表示されたとき、ユーザーはそれをクリックして拡大表示したか？
- 滞在時間: その図解が表示されたページをじっくり読んでいるか？
- 「役に立った」ボタン: シンプルですが、検索結果に対する明示的なフィードバックは貴重な教師データになります。
これらのシグナルを収集し、検索精度の悪いクエリ（＝結果がクリックされていないクエリ）を特定します。
「検索できない図」の特定と対策
運用を始めると、「どうしても検索に引っかからない図」が出てきます。多くの場合、原因は以下のいずれかです。
- 画像が不鮮明: OCRやVLMが誤認識している。
- 説明不足: 図の中にテキスト情報が一切なく、VLMも「四角い箱」としか認識できない。
こうしたケースを発見したら、人手でメタデータ（タグ付け）を補強するか、マニュアル自体の改善（図に注釈を入れるなど）をドキュメント制作部門にフィードバックします。AIシステムをきっかけに、元データの品質を上げていく。これこそがDXの本質的なサイクルと言えるでしょう。
まとめ：死蔵データを現場の武器に変える
PDFマニュアルの中に眠る「図解」や「画像」は、現場のエンジニアにとっては何よりも雄弁な解決策です。これを検索可能にすることは、単なるシステム導入を超えて、現場の技術伝承や業務効率化に直結する経営課題へのアプローチです。
本記事で解説したステップを振り返ります。
- データ分解: PDFから画像とテキストを構造的に切り出す。
- 意味付け: 画像をベクトル化し、さらにVLMで言語化して検索性を高める。
- 格納・検索: ハイブリッド検索対応のベクトルDBで、多様なクエリを受け止める。
- 評価・改善: 現場のフィードバックをループさせ、精度を磨き続ける。
道のりは平坦ではありません。特にPDFのレイアウト解析や画像のクレンジングには、試行錯誤が必要です。しかし、その先には「現場が本当に欲しかった検索体験」が待っています。
まずは手元のマニュアル1冊から、このパイプラインを試してみてください。画像が検索結果に現れた瞬間、現場の景色が変わるはずです。
以下の資料では、本記事で紹介したパイプライン構築に必要な「ライブラリ選定リスト」や「VLMプロンプトのテンプレート」をまとめています。具体的な実装に進む際の設計図としてお役立てください。
コメント