<この記事のポイント>
「過去のPDF資産を作り直す予算も時間もない」――そんな現場のジレンマを、AIはどう解決できるでしょうか？ 本稿では、VDI 2770（文書管理） やiiRDS（インテリジェント情報配信） といった国際標準の考え方をベースに、AIを使って「汚れたPDF」を「検索可能な資産」へと変える実践的アプローチを検証します。 「Delivery（ただ配る）」から「Discovery（見つけさせる）」へ。既存資産を活かしたまま、次世代の情報体験へシフトする具体的な手法を紐解きます。
１．はじめに：連載リニューアルのお知らせ
本連載は今回より、タイトルを 『執筆時のAI活用で「価値あるトリセツ」を届ける ～AI時代の情報設計～』 へとリニューアルいたします。
これまでは「翻訳」の効率化を中心に扱ってきましたが、AI技術の進化は今や「言語の変換」を超え、「情報の構造化・検索・配信」 というドキュメントのライフサイクル全体を変えようとしています。 そこでこれからは、視座を一段上げ、「情報の設計（『探しやすさ』のデザイン）」 という広い視点から、AI活用を探求していきます。
リニューアル第一弾のテーマは、多くの現場が抱える最大のジレンマ――「過去の遺産（レガシーPDF）」 です。
【補足情報】
▼検証資料について 本記事の検証に使用した生成AIで読み込んだ入力資料など、資料編ページに掲載しております。ご自身で実際に試される際にご活用ください。（資料編ページはこちらへ）
▼使用した生成AIについて 検証にはGoogle Geminiを使用しています。（Geminiのページはこちらへ）
２．現状：Excel台帳と「現実」の乖離
膨大なPDFファイルを管理するために「Excelの管理台帳」を使っていたりはしませんか？ ファイル名、製品型番、改訂日などを手入力で管理する…しかし、こんな問題があったとしたら深刻です。
- 台帳への記入漏れがある。
- ファイル名が
final_v2.pdfのように適当で、中身を開かないと正体がわからない。 - そもそも、台帳にある情報（型番など）でしか検索できず、「エラーが出た時の対処法」といった『中身の情報』には辿り着けない。
「いつかCMSに入れて綺麗に作り直したい」 そう思っても、数千ファイルを移行する予算も時間もありません。では、諦めるしかないのでしょうか？ 答えは 「No」 です。PDFを「作り直す」必要はありません。「テキスト抽出」と「AI」 を使えば、今のPDFのままで、Excel台帳以上の検索性を手に入れることができます。
３．PDF資産化への「3つのハードル」
「PDFのままでいいなら、なぜわざわざテキストを抜かなければならないのか？」と思われるかもしれません。 それは、PDFという「画像の塊」を、AIが処理可能な「データ」として扱うためです。
しかし、ここで多くのプロジェクトが壁にぶつかります。 PDFからのテキスト抽出は、決して完璧ではありません。レイアウト崩れ、文字化け、ヘッダーの混入……。こうした「汚れたデータ」を前に、「これでは使い物にならない」と諦めてしまうケースが後を絶ちません。
もちろん、PDF活用における課題は無数にありますが、まずは 「着手する際に必ず直面する、労力がかかりがちな3つの課題」 に絞って、AIが解決の糸口になるか検証してみます。
今回は、あえてノイズ混じりの、PDFデータから抜き出した汚れたTEXTデータを使い、以下の3点を実験します。
実験①【ドキュメント仕分け】 表紙から「属性」を読み取れるか？（Excel入力の手間をゼロに）
まず必要なのは、ファイルの中身を精査することではなく、「それが何のマニュアルなのか」 を外側から特定することです。 Excel台帳には載っていない、あるいは間違っているかもしれない以下の情報を、AIは読み取れるでしょうか？
– 抽出対象： 製品型番、文書種別（取説/カタログ）、発行日、言語など。
– これができると…： ファイルを開かずに「SP-X100の、2025年版の、日本語マニュアル」だけを瞬時にフィルタリングできるようになります。
実験②【中身の特定】 回答と「オリジナル情報」を紐づけられるか？（PDFを開く手間をゼロに）
次に、マニュアルの中身です。ユーザーは答え（サマリ）を知りたいだけでなく、「本当に正確なのか元のページを確認したい（裏取り）」 というニーズを持っています。 崩れたテキストの中から、特定の情報を探し出し、さらにその「在処」を特定できるでしょうか？
– 抽出対象： 手順などの具体的なコンテンツ、およびその「ページ番号」。
– これができると…： 検索結果に「手順の要約」を表示しつつ、クリック一つで「PDFの該当ページ（オリジナル情報）」へ飛ぶ、信頼性の高い導線を作れます。
実験③【品質判断】 データ化の可否を「診断」できるか？（目視確認の手間をゼロに）
最後に、品質の問題です。文字化けがひどく、そもそもデータとして使えないレベルのPDFも混ざっているでしょう。これらを人間が一つひとつ開いて確認するのは、膨大な労力がかかります。 AIにこの「検品作業」を代行させることは可能でしょうか？
– 抽出対象： 文字化け箇所、重要情報の欠損有無。
– これができると…： 「AIが読めなかったファイル」だけを人間がチェックすれば良くなり、確認作業の工数を大幅に圧縮できます。
この3つの実験を通して、「汚れたデータ」という現実に対して、AIがどこまで実用的な解を出せるのかを確認していきます。
４．実証実験：AIで「3つの壁」を突破する
それでは、実際にAIを使って、崩れたテキストデータから価値を引き出せるか検証します。
実験①：【ドキュメント仕分け】表紙から「属性」を読み取れるか？
最初の実験は、Excel台帳の代替となる「自動属性抽出」です。 ファイルを開かずに中身を識別するためには、表紙にある情報（銘板）を正確にデジタル化する必要があります。ここで抽出する項目は、適当に決めたわけではありません。実は、製造業の国際標準である「VDI 2770」で定義された必須項目をベースにしています（詳しくは付録で解説）。
▼ AIへの指示（プロンプト例）
（実際のプロンプトはこちらへ）
「このテキストはマニュアルの冒頭部分です。ノイズを無視して、『製品型番』『文書の種類』『バージョン』 を特定し、JSON形式で整理してください」
＜コラム：怖くない！Excel管理表がそのままシステムに入る「JSON」超入門>
▼ 実験結果（AIの回答）
JSON
{
"DocumentType": "Instruction", // 文書種別：取扱説明書
"ProductVariant": ["SP-X100", "SP-X200"], // 製品型番：複数モデルも認識
"Language": "ja", // 言語
"Version": "2.0", // 版数
"DocumentId": "MAN-SPX-001-J" // 文書番号
}▼ 検証結果のポイント
- 「Excel台帳」が不要になる：
フッターなどのノイズ（汚れ）があっても、AIは文脈からMAN-SPX-001-Jという文書番号を特定できました。 - 「あいまい検索」が可能になる：
["SP-X100", "SP-X200"]と配列で構造化されたことで、どちらの型番で検索してもヒットするようになります。 - 多言語管理への布石：
Language: "ja"が自動判定されました。将来的に英語マニュアルとセットで管理する際、このタグが自動で付けば管理コストは大幅に下がります。
資料１：実験１のプロンプト詳細と結果
AIは、文脈から 「正しいメタデータ」 を付与できました。 これを検索システムに登録すれば、ファイル名が適当でも「SP-X100の説明書」が一発で見つかるようになります。しかし、ファイルが見つかっただけで満足できません。 ユーザーの目的は「説明書を読むこと」ではなく、「手順を知ること」だからです。次は、マニュアルの 「中身」 にメスを入れます。
実験②：【中身の特定】回答と「オリジナル情報」を紐づけられるか？
次に、マニュアルの中身です。 ここでは、単に質問に答えるだけでなく、ユーザーを 「回答（要約）」から「根拠（オリジナルPDF）」へ誘導できるかを検証します。 今回はその実証として、目次にある 「3. フィルターの交換」 という項目をターゲットに、AIが 「該当箇所の特定」 と 「情報の整形」 、そして 「ページ位置の特定」 を同時にこなせるかを実験します。
▼ AIへの指示（プロンプト例）
（実際のプロンプトはこちらへ）
「あなたは文書解析エンジンです。目次項目の『3. フィルターの交換』に該当するセクションを本文から特定してください。 ノイズを除去して読みやすい手順書として整形し、さらにユーザーが原文を確認できるよう 『元のページ番号』 を特定してください」
▼ 実験結果（AIの回答）
Markdown
### フィルター交換手順
1. **[フロントカバーを開ける]**
- 詳細: 本体前面のラッチを外し、手前に引いてカバーを開けます。
- ⚠️注意: 無理に引っ張らないでください。ヒンジが破損する恐れがあります。
（...中略...）
✅ Reference: Page 12-13 (PDF Link: manual.pdf#page=12)▼ 実験結果のポイント
- 構造の「再構築」:
元のPDFテキストでは表組みが崩れていましたが、AIは文脈を理解し、「手順」「作業内容」「注意点」という綺麗な構造に復元しました。 - 「行き先」の特定:
最も重要なのが、Reference: Page 12を特定できた点です。 AIが内容を理解した上で「この情報のソースは12ページにある」と突き止めたため、検索結果からPDFの12ページ目をダイレクトに開くリンク（#page=12）を自動生成できます。 - 「1月号の世界」への入り口（iiRDS/Schema.org化）:
この「情報を部品化してタグ付けする作業」は、1月号で解説した 「iiRDS」 を作成するプロセスそのものです。 PDFからこの「構造化データ」さえ抽出できれば、そこから Schema.org（構造化データ） を生成し、Google検索でリッチに表示させることも容易になります。 つまり、元がPDFであっても、最新のWeb標準技術（Discovery）の世界へ参加できる切符が手に入るのです。
（※【検索結果の進化】劇的ビフォーアフター：検索画面の景色を変える（1月号））
資料２：実験２のプロンプトと結果
【システム化への示唆】
この実験は、たった1つの章で行いましたが、原理は全章同じです。 目次データをリスト化し、AIにこの処理をループさせれば、「崩れたPDF」が「クリック一つで正解に飛べるリッチなマニュアル」へと、全自動で変換できる可能性 を示唆しています。
実験③：【品質判断】データ化の可否を「診断」できるか？
最後は、プロセスの効率化です。 「汚れたデータ」を扱う以上、文字化けや欠損は避けられません。これらを人間が全件チェックするのではなく、AI自身に「自分の手に負えるか」を判断させます。
PDFからテキストを抽出する際、避けて通れない問題が「データの汚れ」です。 文字化け、レイアウト崩れ、意味不明な記号の混入など、品質の低いデータをそのまま後工程に流せば、誤った検索結果やハルシネーションの原因となります。
かといって、抽出された全テキストをヒトが目視で確認していては、膨大な時間がかかり、デジタル化のメリットが失われてしまいます。 この確認作業を省力化するために、AIを 「品質管理のゲートキーパー（検品係）」 として活用できるか検証します。
▼ AIへの指示（要約版）
（実際のプロンプトはこちらへ）
「あなたはデータ品質管理のゲートキーパーです。このテキストデータが、マニュアルとして安全に利用できる状態か『診断』してください。もし、型番の誤読や安全警告の文字化けなど、致命的なノイズがある場合は、無理に処理せず 『利用不可（Discard）』 と判定してください」
▼ 実験結果（AIの回答）
JSON
{
"QualityScore": 1,
"Action": "Discard",
"Reason": "安全警告文において致命的な文字化けが発生しており、危険であるため破棄（要・再確認）を推奨"
}▼ 検証結果のポイント
- 「読めない」の判断：
AIは無理に情報を補完せず、品質リスク（文字化けによる安全情報の欠損など）を検知してDiscardを選択しました。 - 人海戦術からの脱却：
この仕組みを導入すれば、ヒトは「AIがNGを出したファイル」だけを確認すれば良くなります。数千ファイルの山を前にしても、確認工数を確認できることで、現実的な計画を立案できます。 - リスクの具体化:
単にNGを出すだけでなく、「なぜダメなのか」理由を言語化できるため、後でヒトが確認する際の手がかりになります。
資料３：実験３のプロンプトと結果
【提言：どのタイミングで導入すべきか？】
この「AI検品」を導入する最適なタイミングは、「テキスト抽出の直後」かつ「タグ付け（実験①）の前」 です。
- テキスト抽出: PDFからテキストを取り出す。
- AI検品（今回）: データの品質スコアを判定する。
- 合格: 次の「タグ付け・構造化」プロセスへ自動で進む。
- 不合格: エラーフォルダに隔離し、人間または高精度OCRで再処理する。
このフローを組むことで、人間は「AIが弾いたエラーファイル」の確認のみに集中できます。全件を目視確認する人海戦術から脱却し、品質と効率のバランスが取れた運用が可能になります。
５．まとめ：実験から「実用」へ
ここまでの3つの実験で、以下のことを確認できました。
- 【ドキュメント仕分け】 AIは、表紙情報からファイルを自動分類できる。
- 【中身の特定】 AIは、回答の根拠となる「元のページ」へ誘導できる。
- 【品質判断】 AIは、データの汚れを検知して「利用可否」を判断できる。
最後に、これら「3つの機能」をどのように組み立てれば、実際の業務フローとして機能するか？ その 実装について検討しておきます。
実装への提言：「全体」から「部分」へ
実際のシステム運用では、ファイル全体を一括処理するのではなく、段階的に解像度を上げていくアプローチが有効です。
Step 1. まず「ドキュメント仕分け」で整理する（実験①の活用） 最初に、ファイル全体レベルでの整理を行います。 表紙などの比較的きれいな情報を使って、属性（型番、言語、版数）を特定します。「中身が読めるか」は一旦置いておき、まずは 「ファイルサーバーのどこに何があるか」という地図を完成させます。
Step 2. 「中身」を読みながら「品質」をチェックする（実験②＋③の活用） 次に、ページ単位での詳細な取り込みを行いますが、ここで品質判断（実験③） を組み込みます。 AIに目次や本文を読み込ませる際（実験②）、同時に「このページは文字化けしていないか？」を診断させます。
- 読めるページ（合格）: そのまま構造化し、検索対象として登録。
- 読めないページ（不合格）: その部分だけをスキップし、改善リスト（要・再OCRなど）に回す。
このフローであれば、「1箇所の文字化けのせいで、マニュアル1冊すべてが検索できなくなる」という事態を回避できます。良質な部分は即座に資産化し、ダメな部分だけをピンポイントで修復する「改善ループ」が回せるようになります。もちろん、AIも完璧ではありません。最初は「合格」と判定されたデータに対しても、人間による抜き取り検査（サンプリングチェック）を行い、判定基準をチューニングしていく運用を行うことで精度向上を図ります。
未来への道筋：DeliveryからDiscoveryへ
このパイプラインを通ったPDFは、もはや「ファイルサーバーの肥やし」ではありません。
- 現在: ユーザーが必要な情報へ瞬時にアクセスできる 「Discovery（発見）」 の基盤となります。
- 未来: 1月号で紹介したような「リッチリザルト（検索結果での強調表示）」 も実現できます。将来的にRAG（検索拡張生成）やチャットボットを導入する際、この「構造化されたPDFデータ」は最強の学習素材としてそのまま転用できます。
1月号では「最初から綺麗なデータ」を使ってSchema.org化を行いました。 しかし今回の実験で、「過去のPDF」からスタートしても、AIによる構造化（実験②）を経由すれば、全く同じゴール（Discovery）に辿り着けることが確認できました。
「過去のデータは諦める」 その必要はありません。まずは手元のPDFの山に、AIを活用して整理してみることから始めませんか？ 作り直さなくても、既存の資産に「後付けの知能」を与えるだけで、未来への道筋は確かに開けています。
【今日からできるNext Action】
まずは手元にある「PDF」を一つ選んで、ChatGPTやGeminiにアップロードして、実験①のプロンプトをコピペして投げかけてみませんか。
【付録】 PDF管理の世界的標準「VDI 2770」とiiRDSの連携
本編の実験①で、AIに「文書種別」や「型番」を抽出させましたが、この項目選定は、国債標準規格を参考にしています。ドイツのエンジニアリング協会が策定した国際標準規格、「VDI 2770」 です。
■ VDI 2770とは？
簡単に言うと、「企業間でPDFマニュアルをやり取りするための標準ルール」 です。 ファイルの中身（PDF）はそのままでいいから、「外側に統一された名札（メタデータ）を付けよう」 と決めたのがVDI 2770です。
■ 技術資料：VDI 2770 と iiRDS のマッピング
本稿では、既存のPDF管理（Delivery）と、次世代の検索体験（Discovery）を繋ぐアプローチを紹介しました。この両者の関係性は、国際標準規格である VDI 2770 と iiRDS の対応関係を見るとより明確になります。
以下の表は、「左側（今のPDF）」 にある情報を、AIが 「右側（未来のデータベース）」 へどう橋渡ししたかを示す「翻訳リスト」です。
| 抽出項目（概念） | VDI 2770 (Delivery) | iiRDS (Discovery) | 備考 |
|---|---|---|---|
| 管理の粒度 | 文書ファイル (PDF) ファイル単位で管理 | トピック / チャンク 情報の部品単位で管理 | 実験②でPDFをチャンク化したことで、右側の世界へ移行しました。 |
| 対象製品 | ReferencedProduct(例: SP-X100) | ProductVariant(例: SP-X100) | どちらも必須項目。実験①で配列として抽出しました。 |
| 情報の種類 | DocumentClassification(例: Instruction) | InformationType(例: Usage instructions) | VDIは「文書の種類」、iiRDSは「トピックの役割」として定義します。 |
| 言語 | Language(例: ja, en) | Language(例: ja-JP) | 実験①で自動判定させた項目です。 |
| 識別子 (ID) | DocumentId(例: MAN-SPX-001) | Identity(例: GUID, IRI) | VDIは「ファイル名/管理番号」、iiRDSは「情報のユニークID」を指します。 |
| バージョン | DocumentVersion(例: 2.0) | ProductVersion(例: 2.0) | 製品のVerか、文書のVerかの違いはありますが、概念は共通です。 |
■ この表から読み取れること
- 実験①（ドキュメント仕分け）は、表の「左側（VDI 2770）」を作りました。
PDFという「ファイル」に対して、検索に必要なタグを付けました。 - 実験②（中身の特定）は、表の「右側（iiRDS）」への変換です。
「粒度」をファイルからトピック（手順）へと細かくし、情報種別をより具体的にしました。
つまり、AIを活用することで、手元のデータ形式（VDI 2770）から、理想のデータ形式（iiRDS）への変換（マッピング）を自動化したと言えます。
「ウチはPDFしかないから…」と悲観する必要はありません。そのPDFに、標準規格の考え方でタグを付けることこそが、デジタルトランスフォーメーション（DX）の第一歩なのです。
＜終わりー AI時代の情報設計：「作り直し」は不要！ PDFの山のままでいい。AIによる「自動仕分け」で実現する、検索可能な未来＞
