テキスト、画像、音声、動画、PDF――企業が蓄積するデータの8割以上は非構造化データと言われます。LLMとRAG(検索拡張生成)の時代になり、これらを「埋もれた資産」ではなく「活用可能な資産」に変える必要性が一気に高まりました。本記事では、非構造化データの保存(オブジェクトストレージ)、検索(全文検索エンジン)、活用(ベクトルDB)の3層を組み合わせた統合設計を、アーキテクチャとコード例付きで解説します。
非構造化データとは
非構造化データとは、リレーショナルDBのような固定スキーマに当てはめにくいデータ形式全般を指します。テキスト文書、メール本文、議事録、契約書PDF、製品画像、コンタクトセンターの音声、製造ラインの監視映像など、ビジネスの現場で日々生み出される情報の多くがこれに該当します。
構造化データと違い、非構造化データはそのままではSQLでクエリできません。メタデータを付与し、全文検索インデックスを作り、場合によっては埋め込み(Embedding)ベクトルに変換することで初めて活用可能になります。データレイクやレイクハウスの設計が土台になります。
保存設計――オブジェクトストレージの活用
非構造化データの保存先はオブジェクトストレージ(S3、Cloud Storage、ADLS)が第一選択です。容量無制限、低コスト、耐久性11-9’s(99.999999999%)といった特性が、大量の非構造化データの格納に最適です。重要なのはパス設計で、あとから検索・管理しやすいルールを決めておきます。
# S3バケットのパス設計例
s3://company-unstructured-data/
├── raw/ # 生データ
│ ├── documents/
│ │ └── dt=2026-04-15/tenant_id=acme/doc_001.pdf
│ ├── images/
│ │ └── product_id=12345/2026/04/image_001.jpg
│ └── audio/
│ └── dt=2026-04-15/agent_id=007/call_001.wav
├── processed/ # 前処理済み(テキスト抽出後等)
└── embeddings/ # 埋め込みベクトル
パスにはパーティション情報(日付、テナント、製品ID等)を含めることで、後工程でAthenaやSpark等からのフィルタリングが効率化されます。メタデータはDWHの専用テーブルで管理し、実データのパスをポインタとして保持するのがベストプラクティスです。データ基盤全体像の中でも、この構成は広く採用されています。
検索設計――全文検索エンジンの活用
非構造化データのうち、テキストコンテンツに対しては全文検索エンジンを活用するのが定石です。ElasticsearchとOpenSearchが代表的な選択肢で、どちらを選ぶかは以下の観点で判断します。
| 観点 | Elasticsearch | OpenSearch |
|---|---|---|
| ライセンス | Elastic License 2.0(商用制限あり) | Apache 2.0(完全OSS) |
| 開発主体 | Elastic社 | AWS+コミュニティ |
| マネージドサービス | Elastic Cloud | Amazon OpenSearch Service |
| 機械学習機能 | 豊富(有償) | 基本機能あり |
| セキュリティ | X-Pack(有償) | 標準付属 |
| バージョン | 8系以降 | 2系以降(ESからフォーク) |
AWS環境であればOpenSearch、商用サポートや最新機能を重視するならElasticsearchが素直な選択です。日本語の全文検索ではkuromoji、sudachi等のアナライザー設定が重要で、形態素解析の精度が検索体験を大きく左右します。
ベクトルDB――AI/LLM時代の非構造化データ活用
従来の全文検索は「キーワード一致」でしたが、LLMの時代には「意味的類似性」での検索が求められます。これを実現するのがベクトルDBです。テキストや画像を埋め込みモデルで高次元ベクトルに変換し、類似度で検索します。RAG(検索拡張生成)の中核を担う技術として、近年急速に採用が広がっています。
# Pineconeへの埋め込み格納例
from openai import OpenAI
from pinecone import Pinecone
openai_client = OpenAI()
pc = Pinecone(api_key="your-key")
index = pc.Index("company-docs")
def embed_and_upsert(doc_id: str, text: str, metadata: dict):
response = openai_client.embeddings.create(
model="text-embedding-3-small",
input=text
)
vector = response.data[0].embedding
index.upsert(vectors=[(doc_id, vector, metadata)])
| ベクトルDB | 形態 | 強み | 向いているケース |
|---|---|---|---|
| Pinecone | マネージド | 高速、運用不要 | 高速立ち上げ、中〜大規模 |
| Weaviate | OSS/クラウド | ハイブリッド検索、モジュール豊富 | 柔軟な検索要件 |
| Qdrant | OSS/クラウド | Rust製で高速、フィルタ強い | オンプレ、低遅延要求 |
| Milvus | OSS | 大規模分散対応 | 数十億ベクトル超 |
| pgvector | Postgres拡張 | 既存DB統合 | 小〜中規模、Postgres既存 |
小規模ならpgvectorで始め、規模拡大に応じて専用ベクトルDBに移行するのが合理的です。医療データ基盤のような機密性の高い環境では、オンプレ対応のQdrantやWeaviateが選ばれる傾向があります。
統合アーキテクチャ設計
これら3層を組み合わせた統合アーキテクチャを設計します。S3を実データの正本として、全文検索用のElasticsearchインデックスとベクトルDB用の埋め込みを並行生成する構成が基本形です。
【S3 + Elasticsearch + ベクトルDBの統合構成】
[ソースシステム]
|
v
[S3 raw zone] --> 実データの正本
|
v
[前処理パイプライン(Spark/Glue)]
|
+--> テキスト抽出(PDF/OCR)
|
+--> 埋め込み生成(OpenAI/Bedrock)
|
v
+----+------+-------+
| | |
v v v
[ES index] [Vec DB] [DWH(metadata)]
| | |
+--------+--------+
|
v
[検索API / RAG]
|
v
[アプリ / BI / LLM]
※ S3が原本、下流は目的別に最適化された索引
この構成の利点は、S3が「唯一の正本」として機能し、索引は再生成可能という点です。スキーマ変更や埋め込みモデルの更新があっても、S3から再構築できます。Spark入門と組み合わせた前処理パイプラインが現実的な選択です。
ユースケース別設計パターン
非構造化データ活用の代表的なユースケースを、設計パターンと併せて整理します。第一が「社内ナレッジ検索」で、社内文書・Wiki・チャット履歴をRAGで検索する用途です。ベクトルDB+LLMが主役で、小〜中規模ならpgvector+OpenAI、スケールするならPinecone+Bedrockが選択されます。
第二が「コールセンター分析」で、通話録音をテキスト化し、感情分析と要約を行って品質管理に活用します。S3にwavを格納、Whisperで文字起こし、テキストをElasticsearchとベクトルDBに格納する構成です。第三が「製品画像検索」で、類似製品画像をベクトル検索で抽出する用途です。CLIPなどのマルチモーダル埋め込みモデルが活躍します。第四が「契約書レビュー自動化」で、過去契約のPDFをベクトル化し、新規契約との差分・リスクを抽出するユースケースです。法務部門のDX施策として注目されています。
まとめ
非構造化データの活用基盤は、オブジェクトストレージ・全文検索エンジン・ベクトルDBの3層構成で設計するのが基本です。S3を原本に据え、目的別に索引を再生成できる構成にすることで、将来の要件変化にも柔軟に対応できます。LLMとRAG時代のデータ基盤として、非構造化データ戦略を明確に持つことが、これからの競争力を左右します。スケーリング戦略の観点も忘れずに検討しましょう。
よくある質問(FAQ)
Q. 非構造化データはDWHに入れるべきですか?
メタデータ(ファイル名・サイズ・作成日等)はDWHで管理し、実データ本体はオブジェクトストレージに保存するのがベストプラクティスです。DWHは構造化クエリに最適化されており、大量のバイナリデータ格納には向きません。
Q. ベクトルDBはどんな場面で必要ですか?
テキスト・画像の類似検索、RAG(検索拡張生成)によるLLM活用、レコメンデーションなど、「意味的な類似性」での検索が必要な場面で必要です。キーワード一致では拾えない類似コンテンツの発見に威力を発揮します。
Q. 非構造化データの管理で最初にやるべきことは?
データの棚卸し(種類・量・用途の把握)と、メタデータの付与ルール策定から始めましょう。データカタログへの登録も重要で、どこに何があるかを組織全体で把握できる状態を作ることが最優先の施策です。