ファイル変換でナレッジグラフを構築：文書を構造化データに変換する

ナレッジグラフは、学術的な好奇心から検索エンジン、レコメンデーションシステム、エンタープライズデータプラットフォームの中核要素へと進化しました。その力は、エンティティ、リレーションシップ、属性を機械可読かつリンクされた形式（主に RDF（Resource Description Framework）や JSON‑LD）で表現できる点にあります。しかし、ナレッジグラフに供給される情報のほとんどは、PDF の研究論文、Word の契約書、Excel の在庫表、レガシーなアーカイブといった非構造化または半構造化ファイルに格納されています。意味や出所、法的コンプライアンスを失わずにこれらのファイルを構造化トリプルに変換することは、決して簡単なエンジニアリング課題ではありません。

本稿では、日常のオフィス文書をナレッジグラフ対応データへ変換する完全な本番レディワークフローを解説します。目的、準備、実際の変換手法、バリデーション、プライバシー保護、そして最終的にグラフストアへインジェストする方法を網羅します。ガイダンスは意図的にプラットフォーム非依存にしていますが、必要に応じて最初のフォーマット間変換ステップを手軽に行えるプライバシー重視のツールとして convertise.app を参照します。

ナレッジグラフ構築においてファイル変換が重要な理由

ナレッジグラフは、投入されるデータの質に依存します。ソースが乱雑な PDF、スキャン画像、または結合セルが多いスプレッドシートである場合、下流の抽出プロセスは失敗するか、ノイズの多いトリプルを生成し、クエリ精度を低下させます。適切なファイル変換は以下の2つの重要な目的を果たします。

  1. 入力の正規化 – PDF を検索可能でテキストリッチな形式（例：PDF‑A → プレーンテキストまたは HTML）に変換することで OCR のボトルネックを排除します。同様に、レガシーな Office バイナリファイル（.doc、.xls）をオープン XML 版（.docx、.xlsx）に変換すれば、パーサーは見出し、表、メタデータを確実に検出できます。
  2. コンテキストメタデータの保存 – 作成者、作成日、バージョン、さらにはカスタムプロパティまで保持できる変換ツールを使用すれば、生成された RDF に自動的に出所情報が付与されます。ナレッジグラフにおいて出所は一次クラス市民であり、信頼スコア、監査トレイル、GDPR などの規制遵守を支援します。

変換が高精度で行われれば、下流のセマンティック抽出段階は「何を」読むかではなく「何が書かれているか」に集中できます。

セマンティックターゲットの理解：RDF、JSON‑LD、CSV

変換キャンペーンを始める前に、ターゲットとなるシリアライズ形式を定義してください。形式ごとに強みがあります。

  • RDF/Turtle – 複雑な語彙、カスタムオントロジーが必要な場合や、明示的な subject‑predicate‑object トリプルが求められるときに最適です。SPARQL クエリの共通言語です。
  • JSON‑LD – JSON 互換の表現で、リンクドデータコンテキストを直接埋め込めます。開発者に優しく、Web API と相性が良く、リッチスニペットを提供する検索エンジンでも採用が進んでいます。
  • CSV – ナレッジグラフが表形式データ（例：商品カタログ）から構築される場合、整然とした CSV を OpenRefine や W3C の CSV on the Web 仕様を用いて RDF にマップできます。

選択した形式が変換経路を決定します。たとえば、化学化合物の表を含む PDF はまず CSV に変換し、そこから RDF にマッピングするのが最適です。契約書の Word 文書は、当事者、日付、義務といった要素を別エンティティとして保持したまま直接 RDF または JSON‑LD に出力する方が適しています。

セマンティック抽出のためのソースファイル準備

生のファイルは抽出エラーの原因になる障害を隠していることが多く、体系的な準備フェーズは大きなリターンをもたらします。

  1. エンコーディングの早期検出 – テキストファイルは UTF‑8、UTF‑16、またはレガシーな Windows‑1252 である可能性があります。Python の chardet などのツールでエンコーディングを特定し、変換前に UTF‑8 に再エンコードしてください。これにより RDF リテラルの文字化けを防げます。
  2. 改行コードの正規化 – CR、LF、CRLF が混在すると、特に CSV 生成時に行単位処理を行うパーサーが破綻します。dos2unix などで全て LF（\n）に統一しましょう。
  3. 埋め込みメディアの分離 – PDF には重要データ（チャート、署名）を含む画像が埋め込まれていることがあります。pdfimages やクラウドサービスで画像を先に抽出し、foaf:Image や schema:ImageObject でグラフにリンクさせます。
  4. 複雑レイアウトの平坦化 – 複数ページに跨る表、結合セル、入れ子リストは平坦化が必要です。PDF 用 Tabula や Word 用 pandoc で表を CSV にエクスポートし、列ヘッダーは保持します。
  5. ライセンスと権限の検証 – コンテンツの再利用権があるか確認してください。サードパーティ文書の場合、元のライセンス URL を dcterms:license トリプルとしてソースエンティティに付与します。

これらの事前チェックが完了すれば、ファイルは決定論的に変換できる状態になります。

文書を構造化フォーマットへ変換する

以下では、最も一般的な 3 つのソースファミリーに対する具体的な変換パイプラインを示します。

1. PDF → Text/HTML → RDF または JSON‑LD

  • ステップ 1 – テキスト抽出: 視覚的階層（見出し、リスト、表）を保持した PDF‑to‑HTML コンバータを使用します。オープンソースの pdf2htmlEX は CSS クラスを保持しつつ論理構造を残します。
  • ステップ 2 – セマンティック注釈: Apache Tika とカスタム正規表現パターンを組み合わせたルールベースエンジンで、見出しを schema:Article のセクション、表を schema:Table、インライン引用を schema:CreativeWork とタグ付けします。
  • ステップ 3 – RDF 生成: 注釈付き HTML を XSLT もしくは Python スクリプトで DOM を走査し、各セクションに URI（_:section1 など）を付与してトリプルを出力します。表行の典型的なトリプルは次の通りです。
:compound123 a chem:Compound ;
    chem:hasName "Acetaminophen" ;
    chem:hasMolecularWeight "151.16"^^xsd:float ;
    dcterms:source <file:///documents/report.pdf#page12> .
  • ステップ 4 – JSON‑LD パッケージ化: 下流コンシューマが JSON‑LD を好む場合、同一 RDF グラフを公開コンテキストでシリアライズし、chem: プレフィックスを公開オントロジーにマッピングします。

2. Word (.docx) → Structured XML → RDF/JSON‑LD

  • ステップ 1 – OOXML 抽出: .docx は ZIP アーカイブであり、document.xml が本文です。解凍して XML ライブラリで解析します。Word のスタイル階層（Heading1、Heading2）はナレッジグラフのセクションにそのままマッピングできます。
  • ステップ 2 – 表の正規化: <w:tbl> 要素を抽出し CSV 行に変換、列ヘッダーに基づいて schema:Product や schema:Event エンティティを生成するマッピングスクリプトへ流します。
  • ステップ 3 – カスタムプロパティの保持: docProps/custom.xml に格納されたカスタムメタデータを取得し、dcterms:description またはドメイン固有の述語として付与します。
  • ステップ 4 – RDF 発行: Jinja2 などのテンプレートエンジンで XML ツリーを Turtle に変換します。各段落は schema:Paragraph、テキストは schema:text リテラルとして、見出しは schema:headline になります。

3. Spreadsheet (XLSX/CSV) → CSV → RDF via Mapping Files

  • ステップ 1 – 統一 CSV エクスポート: XLSX については xlsx2csv や pandas を使い、シートごとに別々の CSV にフラット化し、セルタイプ（日付、数値）は ISO‑8601 文字列または xsd データ型に変換します。
  • ステップ 2 – マッピング仕様 – YAML または RML で列と RDF 述語の対応を宣言します。例：
mapping:
  - source: product_id
    predicate: schema:productID
  - source: price_usd
    predicate: schema:price
    datatype: xsd:decimal
  - source: release_date
    predicate: schema:datePublished
    datatype: xsd:date
  • ステップ 3 – 変換エンジン – rmlmapper-java などの RML プロセッサでマッピングを実行し、Triple Store へ直接ロード可能な Turtle ストリームを生成します。

コンテキスト、オントロジー整合性、URI の保持

構文的に正しい RDF でも意味が曖昧なトリプルは実用価値が低いです。意味を失わないために次のプラクティスを守りましょう。

  • 安定した URI – DOI、ISBN、もしくは「文書ハッシュ＋セクション番号」の組み合わせなど、変更されない属性から識別子を生成します。後から名前が変わるファイル名は使用しないでください。
  • オントロジーの再利用 – 新しい述語を作る前に、Schema.org、FOAF、DC、あるいはドメイン固有のオントロジー（例：bio:Gene）を検索します。既存語彙の再利用は相互運用性を高め、下流マッピング作業を削減します。
  • ソースへのリンク付与 – 常に dcterms:source トリプルで元ファイルまたはページ／セクションを指し示します。監査や利用者が情報の出所を検証する際に必須です。
  • バージョン付与 – ソース文書がバージョン管理下にある場合、schema:version トリプルで Git コミットハッシュやリビジョン番号を記録します。

大規模コーパスの取り扱い：バッチ変換戦略

エンタープライズ環境では、数千件の PDF やスプレッドシートを毎晩処理する必要があります。スケールアウトするためのオーケストレーションは次の通りです。

  1. チャンク化 – ワークロードを 500〜1,000 ファイル単位のバッチに分割し、RabbitMQ や AWS SQS といったメッセージキューで変換ジョブをワーカーノードに配送します。
  2. ステートレスワーカー – 各ワーカーはストレージ（例：S3）からファイルを取得し、コンテナ化されたツールチェーン（pandoc、pdf2htmlEX、カスタムスクリプト）で変換、結果の RDF をトリプルストアエンドポイントへプッシュします。
  3. 冪等性 – 同一ファイルに対して再実行しても同一 RDF が生成されるよう設計します。ソースファイルのハッシュと生成グラフのハッシュを保存し、一致すれば再インジェストをスキップします。
  4. 監視とリトライ – Prometheus メトリクスで変換成功率を追跡。失敗ジョブは指数バックオフでリトライし、永続的な失敗は手動レビュー用にログに残します。
  5. convertise.app の活用 – 特にツールチェーンでサポートされていないレガシーフォーマット（例：古い CorelDRAW を SVG に変換）をワンオフで処理したいときは、convertise.app がコード不要でプライバシーを重視した橋渡しを提供します。

品質保証：バリデーション、SHACL、そして自動テスト

変換後は構文的およびセマンティックな正しさを検証します。

  • 構文チェック – rapper（Redland ライブラリ）などのパーサーで RDF を通し、Turtle や JSON‑LD の文法エラーを捕捉します。
  • 形状制約（SHACL） – 期待されるグラフ構造を表す SHACL シェイプを定義します。製品カタログの場合、schema:price は decimal、schema:productID は空文字列でない文字列、schema:availability はあらかじめ定義した語彙のいずれかであることを要求できます。
  • SPARQL 適合テスト – 重要なトリプルが存在するか確認する ASK クエリを書き、CI パイプラインで自動実行します（例：すべての schema:Person が schema:name を持つか）。
  • ラウンドトリップテスト – RDF を人間可読形式（例：CSV）に戻し、元ソースと diff ツールで比較します。小さな差異は空白除去ミスや数値の丸め誤差を示すことが多いです。

プライバシー、ライセンス、倫理的考慮事項

個人情報を含むファイルを変換する際は、GDPR、CCPA などの法規制に対応しなければなりません。

  • データ最小化 – ナレッジグラフで必要なフィールドだけを抽出します。PDF にフルアドレスが含まれていても、グラフで必要なのは市区町村と国だけであれば、通り名は除外してください。
  • 疑似匿名化 – メールアドレスや電話番号といった直接識別子は、別途保管したソルトでハッシュ化し置き換えます。マッピングファイルは安全なボールトに保存し、監査時のみ参照できるようにします。
  • ライセンス伝搬 – 元文書のライセンス URL を dcterms:license トリプルで付与します。Creative Commons などのオープンライセンスの場合、派生エンティティすべてに同ライセンス情報を伝搬させます。
  • 保持ポリシー – 変換後の RDF の保存期間を決定し、特に機密契約書に対しては自動的に期限切れ削除を実装します。

知識グラフストアへのインジェスト

クリーンな RDF が得られたら、最後にグラフデータベースへロードします。ネイティブトリプルストア（Blazegraph、GraphDB）とプロパティグラフシステム（Neo4j の RDF プラグイン）では若干手順が異なります。

  1. バルクロード – 多くのストアは INSERT DATA の一括実行や、Turtle/NT ファイルを直接読み込むバルクローダーを提供します。データは論理的なネームドグラフ（例：graph:finance、graph:research）に分割し、細かなアクセス制御を可能にします。
  2. ストリーミングインジェスト – 継続的パイプラインの場合、各バッチ完了時に SPARQL 1.1 UPDATE の INSERT 文でリアルタイムにトリプルを追加します。Kafka コネクタは多くのストアで利用可能で、リアルタイムストリーミングを実現します。
  3. インデックス設定 – 検索対象となるリテラル（タイトル、要旨）に全文検索インデックスを有効化します。一部ストアは schema:geo のようなジオインデックスもサポートし、住所情報がある場合に有効です。
  4. クエリ検証 – ロード後、実務で想定されるベンチマーククエリを実行し、応答時間と結果の完全性を確認します（例：「2020 年以降に署名された、上場企業が相手方の契約をすべて取得」）。

実践例：年次報告書をナレッジグラフに変換する手順

シナリオ：金融アナリストが過去 10 年分の企業年次報告書（PDF）から「純利益」の全出現箇所をクエリで取得したい。

  1. PDF 収集 – 年度別に S3 バケットに保存し、キー名に年度を付与。
  2. 事前処理 – pdfinfo で全ファイルが PDF/A‑1b（保存形式）であることを確認。pdf2htmlEX で視覚階層を保持した HTML に変換。
  3. 表抽出 – HTML 内でクラス table を持ち、かつ「Profit」という文字列を含む表を検出し、tabula-java で CSV にエクスポート。
  4. RDF マッピング – RML マッピングを作成し、schema:FinancialStatement エンティティを年度ごとに生成。各行から schema:Revenue、schema:NetProfit、schema:OperatingExpense を生成し、数値は xsd:decimal にキャスト。
  5. 出所情報付与 – prov:wasGeneratedBy で変換スクリプトのバージョンと S3 の PDF URI を指す prov:Activity をリンク。
  6. バリデーション – schema:NetProfit が全ての schema:FinancialStatement に必ず存在することを要求する SHACL シェイプを実行。欠損があれば手動レビュー用ログに記録。
  7. インジェスト – Turtle を GraphDB のネームドグラフ graph:annual_reports にロードし、schema:financialMetric リテラルに全文検索インデックスを作成。
  8. クエリ実行 – 以下の SPARQL で純利益の一覧を取得：
SELECT ?year ?netProfit WHERE {
  GRAPH <graph:annual_reports> {
    ?stmt a schema:FinancialStatement ;
          schema:year ?year ;
          schema:NetProfit ?netProfit .
  }
}
ORDER BY ?year

アナリストは PDF を個別に開く手間なく、整然とした純利益リストを取得できます。

ファイル → グラフ変換のベストプラクティスチェックリスト

  • ターゲットシリアライズの決定（RDF/Turtle、JSON‑LD、CSV）を事前に確定する。
  • エンコーディングと改行コードを正規化し、隠れ文字の破損を防止。
  • 埋め込みメディアは別ファイルで抽出し、適切な述語でリンク付け。
  • 中間ステップはオープンフォーマット（HTML、CSV）を利用し、パイプラインの透明性を確保。
  • 元メタデータ（作成者、作成日、ライセンス）を出所トリプルとして保持。
  • 不変属性から安定した URI を生成し、名前が変わっても一貫性を保つ。
  • 新規述語を作る前に既存オントロジーを検索し、再利用を徹底。
  • SHACL と SPARQL ASK で自動テストを組み込み、構文・意味の両面を検証。
  • 個人データはデータ最小化と疑似匿名化でプライバシーに配慮。
  • 生成エンティティにライセンス情報を付与し、派生物の法的扱いを明示。
  • 大規模コーパスはバッチ化し、冪等性を確保したワーカーで処理。
  • 変換成功率を監視し、失敗はリトライ＋ログで対処。
  • convertise.app を活用して、ツールチェーンにないレガシーフォーマットのワンオフ変換を迅速に実施。

結論

日常のオフィス文書をナレッジグラフ対応データへ変換するプロセスは、ファイルフォーマットの取り扱いとセマンティックウェブのベストプラクティスを融合させた体系的作業です。エンコーディング正規化、構造手掛かり抽出、出所情報保持、SHACL による検証という「最初の品質ゲート」を設けることで、ノイズの多い PDF やスプレッドシートをクリーンでクエリ可能なグラフへと転換できます。

この投資は、下流の分析を高速化し、コンプライアンス監査に透明な出所情報を提供し、検索・レコメンデーション・AI モデルといった様々なユースケースで同一の構造化データを再利用できるようにします。未構造化文書の量が増え続ける中、ファイル変換によるナレッジグラフ化の技術は、データエンジニア、アーカイブ管理者、そしてあらゆるデータ価値を引き出したい組織にとって必須スキルとなるでしょう。