非構造化データをAIが使えるようになる4つの方法｜統合管理のための3レイヤー

AI時代に必要なデータの意義と知識を紹介する連載、なぜAIの話は、いつも「データ」の話になるのか。

前回の連載：第3回では、売上や顧客数、在庫といった、表形式の数値データ——構造化データを整える4つの定石を見てきました。 本回は、第3回(構造化データの打ち手)に続く「打ち手編2本目」にあたります。

前回の記事：AIが使えるデータ基盤の作り方｜構造化データを整える4つの定石

「『A社の売上が30%下がった』はDWHを見れば分かるが、『なぜ下がったのか』は商談の議事録やメールの中にあって、AIにはまったく見えていない」。
「契約書も提案書もマニュアルも、結局は個人のフォルダや共有ドライブにバラバラに置かれたまま」。
「社内Wikiや過去の提案書を、AIにまとめて読ませることはできないのか」。

実は、企業が持つ情報の約9割は、契約書、議事録、メール、提案書、マニュアル、コールセンターの録音、設備の写真といった、表形式に収まらないデータだと言われています。表に収まる構造化データは、全体の1割ほどに過ぎません。

残り9割の表に収まらないデータを総称して、非構造化データと呼びます(出典: 企業が持つ情報の90%は非構造化データ — Box Japan(IDC白書を引用))。
構造化データを整えただけでは、この9割の知識には手が届かない。
これが、第3回の整備が一段落した会社が次に直面する壁です。

本記事でお伝えしたいことは、大きく2点です。
1つは、社内の文書をAIに使わせる手段も、4つに整理されること。
もう1つは、構造化データと非構造化データを横断的にAIに参照させるための「統合管理」は、すべてを1箇所のシステムに集約することではないということです。

それでは、非構造化データをAIが使えるようになる方法を解説していきます。

構造化と非構造化は、何を補い合うのか

まず、構造化データと非構造化データが、それぞれ何を答えてくれて、何には答えられないかを、整理しておきたいと思います。

構造化データが得意なのは、「何が・いくつ・いつ起きたか」を答えることです。
受注金額が先月いくらだったか、ある顧客が過去1年で何回購入したか、在庫が今いくつあるか。事象を数えて、比較して、推移を追いかける——ここは構造化データが力を発揮する領域です。
一方で答えられないのは、「なぜそうなったのか」「どんな経緯でそうなったのか」という、事象の裏側にある文脈です。

たとえば「A社の売上が今四半期、30%下がっています」。
これは第3回で整えたDWHを見れば、AIに尋ねた瞬間にグラフ付きで返ってきます。
けれど、経営の方が本当に知りたいのは、「なぜ下がったのか」「自社の値上げが響いたのか、競合の動きか、先方の事業環境が変わったのか」「来期も続くと見ておくべきか」のはずです。
これらは、表のなかには書かれていません。たいていは、商談議事録の「先方からのコメント」欄に、あるいは担当営業が経営層に送ったメールに、「先方は今期から購買方針を変更した」と記されています。
これらはすべて、表には収まらない非構造化データです。

つまり、構造化データと非構造化データは、対立する2種類のデータではなく、「何が起きたか」と「なぜ起きたか」を補い合うペアです(出典: Structured vs Unstructured Data — Databricks Blog)。

AIに本当に役立つ示唆を出させようと思えば、DWHの数字(売上推移、購入頻度、商品構成)と、文書側の保管庫に収まった議事録やメール(先方コメント、担当営業の所感)の両方を、同じ瞬間に参照できなければなりません。
だからこそ、構造化データを整えた次は、文書のなかの知識をAIが扱える状態にし、最後に両者を「つなぐ」仕組みを用意する必要があるのです。

非構造化データをAIが使えるようになる4つの方法

文書をAIに使わせるための方法は、現在、大きく4つに整理できます。
RAG、AI抽出、ナレッジグラフ、マルチモーダルです。
技術名はどれもなじみが薄いかもしれませんが、それぞれが何をするのかの概念を記載します。
第3回と同じく、「何をするか」「なぜ必要か」「社内で決めることと外注できることの切り分け」という並びで、1つずつ見ていきます。

RAG——文書から答えを引き出す

まず1つ目は、近年もっとも採用が広がっている方法、RAG(Retrieval-Augmented Generation、検索拡張生成)です。
日本語で言えば、AIに答えさせる前に、関連する社内文書を検索してきて手渡す仕組み、と言うのが近いかと思います。

仕組みは、3つの段階に分かれます。
まず、社内の文書(マニュアル、議事録、過去の提案書、社内Wikiなど)を、AIが意味を捉えやすい単位に細かく区切ります(これをチャンク化と呼びます)。
次に、それぞれの区切りを、意味の近さを数値で表せる形に変換します(これをベクトル化と呼び、変換後のものを保管する専用の保管庫をベクトルデータベースと呼びます)。
そして、ユーザーから質問が来ると、その質問もベクトル化したうえで、ベクトルデータベースから意味の近い文書だけを引っぱり出し、それをAIに「これを読んだうえで答えてください」と一緒に渡します。
AIは渡された文書を読みながら、出典付きで答えを返してくれる(出典: What Is RAG? — Atlan)——これがRAGです。

RAGが経営にとって嬉しい理由は、2つあります。
1つは、社内の文書をAIに「学習させる」必要がないこと。
AIに自社データを覚え込ませようとすると追加学習の費用や時間が大きくのしかかりますが、RAGは学習ではなく「その都度参照」の仕組みなので、文書を追加・削除しても保管庫の中身を入れ替えるだけで済みます。

もう1つは、AIの「もっともらしい嘘」(ハルシネーション)を抑えられること。
AIは何の根拠もなく答えを作ることがありますが、RAGでは答えと一緒に「どの文書のどこを参照したか」が返ってきます。
経営判断に使う場面では、この出典の有無が決定的に重要になります。

なお、文書を保管するベクトルデータベースには、SaaS型のPineconeやWeaviate、既存のPostgreSQLに追加できるpgvector、オープンソースのQdrantやMilvusなど複数の選択肢があり、規模・既存環境・予算に応じて選べる状態になっています(出典: ベクトルデータベース完全ガイド — renue)。
製品の優劣はここでは扱いませんが、いずれも「文書を意味の近さで検索できるようにする保管庫」だと捉えていただければ十分です。

外注と社内の切り分けは、こう整理できます。
ベクトルデータベースの選定、チャンク化、AIに渡す部分の実装といった技術はすべて外注に任せられます。国内のSI事業者やクラウドベンダーが構築支援メニューを揃えています。

社内で握っておきたいのは、「どの文書を、どの順で、どれくらいの頻度で更新しながらAIに使わせるか」という対象選定と運用ルールです。

AI抽出——文書から「表」を取り出す

2つ目は、RAGとは方向が違う方法、AI抽出です。
RAGが「文書のまま検索して引き出す」のに対し、AI抽出は「文書のなかから欲しい項目だけを取り出して、表(=構造化データ)に変える」という発想に立ちます。

たとえば、契約書を1,000本抱えている会社を想像してみてください。
「契約期間が来年3月までに切れる契約のうち、月額10万円以上のものはどれか」という質問に答えるためには、本来は1本ずつ契約書をPDFで開いて、契約期間と月額金額を読み取って、Excelに転記して……という作業が要ります。

AI抽出は、ここをLLMにやらせる仕組みです。
「この契約書から、契約相手・契約期間・月額金額・自動更新条項の有無を取り出して、表にしてください」とLLMに指示すれば、1,000本分の表が一気に出来上がります(出典: LLMを用いて長文ドキュメントを速く・安く・安全に構造化する試み — LayerX エンジニアブログ、Google製LangExtract入門 — Zenn)。

経営として押さえておきたいのは、AI抽出で取り出した結果は、そのまま第3回で整えたDWHに追加できる、という点です。

契約書から取り出した「契約相手・期間・金額」の表は、立派な構造化データですから、第3回でお話ししたデータ統合・セマンティックレイヤー・品質管理・履歴設計の打ち手が、そのまま適用できます。
これまで「文書のなかに眠っていて、AIにも経営の数字にもならなかった情報」が、AI抽出を経由することで第3回の基盤に組み込まれる。
AI抽出は、非構造化データと構造化データの世界をつなぐ橋として機能する、と捉えていただくと近いかと思います。

なお、長文の契約書は意味のあるまとまり(章・条)ごとに区切ってからLLMに渡すと抽出精度と費用の両方を抑えられる、といった実装上の工夫も、国内のSaaS企業から公開されています(出典: LayerX エンジニアブログ)。

外注と社内の切り分けは、こうなります。
LLMへの指示の出し方、抽出結果の検証、抽出ミスをどう減らすか——こうした技術的な作りこみは外注に任せられます。

一方で社内で決める必要があるのは、「どの項目を抽出するか」という抽出の設計図(これを抽出スキーマと呼びます)です。
「契約期間と金額さえあれば良いのか、自動更新条項やSLA条項も要るのか」「議事録から取り出すなら、決定事項、宿題、参加者、誰が何を発言したか、のどこまで要るのか」——これは業務の使いみちが分かっていないと決められないことで、外部のベンダーには判断のしようがありません。
抽出スキーマは社内で決め、技術実装は外注、という分担が自然な切り分けです。

ナレッジグラフ——文書どうしの関係を整理する

3つ目は、文書のなかに散らばっている人や会社、案件といった登場人物を、「関係性」のかたちで結び直す方法——ナレッジグラフです。

RAGは文書から答えを引き出す方法、AI抽出は文書から表を取り出す方法でした。
これに対してナレッジグラフは、「誰が、何と、どんな関係にあるか」を、点と線で表したネットワークとして整理します。

たとえば、社内に過去5年分の商談議事録があったとして、そこからLLMにエンティティ(人物、会社、案件、商品)と関係(担当した、提案した、競合になった、参照した)を自動で抽出させると、「営業担当のBさんは、C社のDさんと、過去3つの案件で接点があった」「製品Eは、過去にF業界で提案され、3社で採用された」といった関係性のネットワークが出来上がります。

なぜ関係性のかたちにするのか。
それは、関係性を辿らないと答えられない問いが経営の現場にあるからです。
「うちのキーパーソンであるBさんは、競合のC社とも過去にどこかで関わっていなかったか」「製品Eの過去の採用社のうち、F業界以外で類似条件の見込み客はいないか」。
こうした問いは、文書を1本ずつRAGで検索しても答えが出てきません。文書群を貫く「関係性」がないと辿れない問いだからです。

外注と社内の切り分けは、こうです。
エンティティと関係を自動抽出してグラフ化する仕組みの構築は、外注に任せられます。
一方、社内で決める必要があるのは、「何を重要な関係として扱うか」の定義です。
営業の現場で大事なのは「人と人のつながり」ですし、製造の現場で大事なのは「部品と完成品の構成関係」かもしれません。
何を辿りたいかは業務によって違いますから、ここは社内で決めるしかありません。

ナレッジグラフは導入の負担が4つの方法のなかでは最も大きいので、RAGで効果が見えてきて、関係性で辿りたい問いが具体的に積み上がってきた段階で、初めて検討する、という順番でかまわないかと思います。

マルチモーダル——音声・画像・動画をAIの入口に流し込む

4つ目は、これまで「文字化されていなかったために、AIには見えなかった」情報——音声、画像、動画——をAIの入口に流し込む方法、マルチモーダルです。

ここ1〜2年で大きく変わったのは、GPT-4o、Gemini、Claudeといった主要なAIモデルが、画像も音声も「そのまま」処理できるようになったことです。
少し前までは、商談録音から議事録を作るのに、音声認識ソフトでテキスト化したうえで別のAIに要約させる、という二段構えが必要でした。
いまは録音ファイルをAIに渡せば、その場で議事録の下書きが返ってきます。
設備の写真を渡して「これは何という型番で、過去の不具合報告はあるか」と尋ねれば、画像を読み取ったうえでマニュアルや報告書と突き合わせた答えが返ってきます(出典: マルチモーダルAIとは?GPT-4o・Gemini・Claudeの違い・活用事例(2026年版) — renue)。

ただし、ここを誤解しないでいただきたいのは、マルチモーダルの打ち手は「AIに音声や画像を渡す」だけでは成立しない、という点です。
AIにファイルを投げ込めば答えが返ってくるのは、あくまで点の体験で、業務として回るためには、その前後の段取りを整える必要があります。

1つ目は、取り込みの仕組みを作ること。
会議録音、顧客との通話、現場撮影、コールセンターの応対——どこから音声・画像を取るのかを決め、自動でストレージに集まる経路を整えます。
たとえば、Web会議の録音はクラウドストレージに自動保存し、現場端末で撮った写真は撮影と同時に業務システム(設備管理や案件管理)に紐づけて取り込む、といった具合です。
ここを整えないと、せっかくAIが処理できる状態にあっても、毎回人が手でファイルをアップロードする運用になります。

2つ目は、メタデータの付与です。
録音日時、参加者、案件ID、撮影場所、機器ID、現場担当者——こうした「いつ・どこで・誰の・何の」情報を、データに付随させて保存します。
これがあると、後でRAGや横断検索の対象にしたときに、AIが「この録音はどの案件の、いつの会議か」を理解しながら答えてくれます。
後ほど統合管理の章で扱うメタデータカタログとも、ここで地続きになります。

3つ目は、業務システムへの戻しです。
生成された議事録の下書きを案件管理システムの該当案件に自動投稿する、点検記録を設備管理システムに自動転記する、FAQの更新候補をナレッジベースに上げる——AIの出力を業務システムに戻して、初めて現場が回り始めます。
AIに渡すところで止まると、「便利そうだが結局使わない」になりがちです。

外注と社内の切り分けは、こうです。
モデルの選定、API連携、取り込みパイプラインの構築、業務システムへの戻しの実装——技術部分はすべて外注に任せられます。
社内で決める必要があるのは、「どの音声・画像を業務に組み込むか」の優先順位、「録音同意・保存期間・アクセス権限」の運用ルール、そして「個人情報や機微情報がモデルに渡るリスクをどう抑えるか」の方針です。

統合管理は単に「1箇所に集めること」ではない

構造化データを整える4つの定石(第3回)と、非構造化データを扱う4つの方法(本記事の前半)が出揃いました。
両方を持っていれば、AIに「何が」と「なぜ」の両方を答えさせる土台はできます。
では、構造化データと非構造化データを、どう繋げばよいのか。

この問いによく返ってくるのが、「全社データレイクを作って全部1箇所に集めればいい」「DWHに文書もまるごと放り込めばいい」という答えです。
耳触りは良いのですが、これは半分くらい誤解だと考えています。

まず、構造化と非構造化は、保管する仕組み自体が違います。
構造化データはDWHで効率よく扱えますが、議事録や契約書をDWHに入れても、DWHは表の検索しかできないので文書としての検索性能は出ません。
非構造化データはベクトルデータベース(意味の近さで検索する保管庫)に入れたほうがAIから扱いやすい。
性質が違うものを無理に1つの箱に押し込めても、結局はどちらの良さも出ません。

そして、全部を1箇所に集めようとすると、コストとセキュリティの負担が一気に重くなります。
営業情報、人事情報、財務情報、個人情報、契約書原本……これらはもともと別々のシステムで別々のアクセス権限で運用されています。
これらを1つの箱に集約しようとすると、移行作業に加えて「誰がどこまで見られるか」の権限設計が極端に複雑になります。

では、どうするか。統合管理の本来の意味は、「すべてを物理的に1箇所に集めること」ではなく、「バラバラの場所にあるデータを、AIや人が必要なときに横断的に参照できる状態にすること」です。
実現に必要なのは、3つのレイヤーです。

レイヤー1：共通ID——同じ「もの」に同じ番号を振る

最初のレイヤーは、データを繋ぐためのもっとも基礎的な部品、共通IDです。

たとえば、社内には「A社」というお客様のデータが、複数のシステムに散らばっています。
営業のSalesforceでは取引先ID「ACC-1234」、経理の会計ソフトでは取引先コード「000567」、ECシステムでは顧客番号「U-9821」。
同じA社なのに、システムごとに番号も呼び方も違う。これでは、AIに「A社の全体像を見せて」と頼んでも、システムをまたいで同じ会社だと認識できません。

ここを揃えるのが、共通IDです。
社内のどのシステムでも、A社には同じ「会社マスターID」を割り振る。
営業の議事録に登場するA社、経理の入金履歴のA社、ECの購買履歴のA社、コールセンター録音のA社——すべてが同じ会社マスターIDで紐づくようにします。
顧客だけでなく、商品、契約、案件、社員といった主要な「もの」について、社内で共通のIDを設計し、各システムに浸透させる作業が、ここに含まれます(出典: 異なるデータIDの統合・統一化に関する調査研究 最終報告書 — デジタル庁(2023年3月))。

一見地味な作業に見えますが、後から手を入れるとたいへん重くなる種類のものです。
各システムが独自IDで動き始めて何年も経ってから「共通IDを通そう」とすると、過去データの突合と移行で大きなコストが発生します。
共通ID設計は、DWHを作るタイミングと、できれば同じ時期に手をつけるのが、もっとも効率的です。

レイヤー2：メタデータカタログ——「どこに何があるか」の辞書

次のレイヤーは、社内に散らばるデータの「目次」を作るレイヤー、メタデータカタログです。

メタデータとは、平たく言えば「データに関するデータ」、つまり「この表は何の表か」「この列は何を意味するか」「この文書はどの部署のものか」「最終更新はいつか」といった、データそのものを説明する情報のことです。
これを社内全体で一元的に管理する仕組みが、メタデータカタログ(あるいはデータカタログ)です(出典: メタデータ管理とは — NTTドコモビジネスX)。

なぜ、これが必要なのか。
社内のデータをAIに扱わせようとすると、AIはまず「どこに、何の、どんな意味のデータがあるか」を知らなければなりません。
営業のDWHに「顧客テーブル」があり、契約管理システムに「契約テーブル」があり、ベクトルデータベースに「議事録チャンク」があり、ストレージに「契約書PDF」がある——これらの場所と意味を、AIが質問のたびに探し回るのは効率が悪すぎます。
あらかじめ「どこに、何が、どういう意味であるか」を整理しておく辞書があれば、AIは質問を受けた瞬間にその辞書を引いて、必要なデータがある場所に直接アクセスできます。

ここで特筆しておきたいのは、メタデータカタログの位置づけ自体が、AIエージェントの普及を受けて変わってきていることです。
Googleは、これまでDataplexと呼んでいたメタデータ管理サービスを、Google Cloud Next '26で「Knowledge Catalog」へとリブランドしました。
役割の説明も、「社内のデータがどこに何があるか一覧できる帳簿」から、「AIエージェントが仕事をする前に、データの意味を確認しに来る辞書」へと変化しています(出典: Dataplex から Knowledge Catalog へ — Zenn(SoftBank Tech)、Google Cloud Next '26 Dataplex が Knowledge Catalog にリブランド — iret.media)。

データカタログが「人がデータを探すための仕組み」から「AIがデータを使うための仕組み」へ移ってきている——この変化は、今後のデータ整備の優先順位を考えるうえで、押さえておく価値があります。

レイヤー3：横断参照——必要なときに横串で取りに行く

3つ目のレイヤーは、共通IDで紐づき、メタデータカタログで意味づけられたデータを、必要なときにAIが横断的に「取りに行ける」状態にする仕組みです。

これを横断参照、あるいは技術用語では論理データ統合やデータ仮想化と呼ぶこともあります(出典: AI・データ利活用を加速する「論理データ統合」 — ビジネス+IT)。

冒頭の「A社の売上はなぜ下がったのか」に、もう一度戻ってみます。
AIがこの問いに答えるには、DWHから「A社の売上推移」を、ベクトルデータベースから「A社との直近商談の議事録チャンク」を、ストレージから「A社の最新契約書」を、それぞれ取りに行って組み合わせて読む必要があります。

横断参照の仕組みがあると、AIは共通IDで「これはすべて同じA社のデータだ」と認識し、メタデータカタログで「この情報はどこにある何か」を知って、各保管庫からデータを引き出し、ひとつの回答にまとめてくれます。

つまり、データは物理的にはそれぞれの保管場所にあるが、論理的にはAIから「ひとつの統合されたデータ」のように見える——これが統合管理です。
各部門のシステムは従来どおりに動かしながら、AIから見ると「全社のデータが揃って見えている」状態を保てます。

どこから手をつけるか

4つの方法と統合管理の3レイヤーが並ぶと、「全部やらないといけないのか」と気が遠くなるかもしれませんが、全部を同時に始める必要はありません。

まず、RAGから始める

4つの方法のうち、最初に着手する価値が高いのは、ほとんどの会社にとってRAGです。

理由のひとつは、効果が見えやすいこと。
「探す時間」「聞き合わせる時間」が減るのは現場の体感としてすぐに伝わるので、経営層への説明材料も得やすい打ち手です。

そしてもうひとつは、対象を「頻繁に参照される文書」に絞れば小さく始められること。
全社の全文書を一気にRAG化するのではなく、社員からの問い合わせがいちばん多い人事制度・経費精算ルール・製品マニュアル・過去の提案書あたりから乗せ、効果を見て範囲を広げる——この段階を踏めば、初期投資も人的負担も抑えられます。

並行して、共通IDの整備を進める

RAGの導入と並行して、できれば同じタイミングで手をつけておきたいのが、共通IDの整備です。

理由は単純で、後からやろうとすると重い、ということに尽きます。
各システムが独自IDで何年も動いてから「揃えよう」とすると、過去データの突合と移行で、別件の予算規模の話になりかねません。
DWHの構築・拡張のタイミングと、共通ID設計のタイミングを揃えるのが、もっとも効率の良い進め方です。

効果を確かめて、AI抽出・ナレッジグラフ・マルチモーダルへ広げる

RAGで効果と運用の感覚をつかんだら、次はAI抽出に広げるのが自然な順番です。
AI抽出の結果は第3回で整えたDWHにそのまま追加できますから、構造化データの基盤強化にも直接つながります。

ナレッジグラフは、関係性で辿りたい問いが具体的に積み上がってきた段階で検討すれば十分で、すべての中堅企業がいきなり最初に着手する打ち手ではありません。

マルチモーダルは、商談録音や現場画像といった、特定業務で大きな効果が見込める場面から導入するのが現実的です。
先の3つの「入口」を広げる打ち手なので、いずれかで運用が回り始めた後に、対象を増やす形で組み合わせるのがやりやすいかと思います。

まとめ——文書のなかの知識を、AIに届ける

社内の知識の大半は、表ではなく文書のなかにあります。
そして、構造化データと非構造化データを共通IDでつなぎ、AIが横断的に参照できる状態を作ることが、統合管理の本来の姿です。

次回の第5回では、ここまで揃えた構造化・非構造化のデータを、どこまでAIに使わせていいのか、どこからは止めるべきか——ガバナンスとセキュリティの論点を取り上げます。

「文書をAIに渡せる」ようになると必ず出てくる「機微な文書はどうするのか」「社外秘の議事録は」「個人情報を含むメールは」という問いに、正面から向き合う予定です。

本記事までで整えた打ち手を、安心して運用に乗せるための土台のお話となります。

連載：なぜAIの話は、いつも「データ」の話になるのか

第1回：なぜAIの話がデータの話になるのか
第2回：AIで成果を出すためのデータ整理
第3回：AIが使えるデータ基盤の作り方
第4回：非構造化データをAIが使えるようになる方法
第5回：整ったデータを安心してAIに渡すための4つの打ち手
第6回：整えたデータを保ち続ける組織のつくり方
第7回：データとAIが生み出す企業の成長サイクル