半構造化データとは｜非構造化データをAIで分析できる形にする

社内データのAI活用を調べはじめると、次のような道筋をたどることになります。

まずBIやデータ分析の文脈で、「構造化データ」と「非構造化データ」という区分に出会います。企業が持つ情報の大半は非構造化データだと知り、自社もその側に資産が偏っていることに気づく段階です。そこから活用方法を調べていくうちに行き当たるのが、「半構造化データ」という第三の言葉です。

ところが、ここで手が止まります。
JSONやXMLといったファイル形式の例は出てくるものの、それが自社の議事録PDFや問い合わせ履歴や社内Wikiとどう関係するのかが結びつきません。
「結局、半構造化データとは何なのか」「うちのデータはどれに当たるのか」。
構造化と非構造化の中間、という以上の説明が見つからないまま、検討が止まってしまいます。

本記事では、半構造化データの定義と3つの違い、AI活用への接続、運用で問題になる論点、そして自社のファイル群から始める手順までを扱います。

半構造化データとは、非構造化データにキーを付けて分析できるようにしたもの

半構造化データとは

半構造化データとは、決まった表の形は持たないものの、どの部分が何を指すかを示すキーやラベルが付いているデータのことです。準構造化データと呼ばれることもあります。

たとえば、会議の議事録が1本あるとします。
本文はただの文章の並びで、どこに何が書いてあるかは読まないと分かりません。
この議事録の冒頭に、次のような行を付けたとします。

日付: 2026-07-15
顧客名: 株式会社サンプル
案件: 基幹システム更改
文書種別: 議事録
決定事項: あり

本文は1文字も変えておらず、付け足したのは、この文書が何なのかを示す数行だけです。
それでもこの議事録は、「株式会社サンプルの、7月の、決定事項が書かれている議事録」として機械的に取り出せるようになり、日付で並べ替えることも、決定事項があるものだけを数えることもできます。

文章はそのままで、そこに意味の目印が付いている状態。これが半構造化データです。

半構造化データと、構造化データ・非構造化データの違い

3つを分けているのは、項目の決まりごとがどこにあるかという1点です。

構造化データは、項目の決まりごとが表で決まっています。
売上管理の表であれば、日付・商品名・金額という列があらかじめ用意されていて、行が増えても列は変わりません。

非構造化データには、その決まりごとがありません。
議事録のPDFも、問い合わせのメールも、通話の録音も、中身は読んでみるまで分かりません。

半構造化データは、決まりごとがデータ1件ずつの中に入っている状態です。
先ほどの議事録でいえば、「顧客名」という項目名が、議事録ファイルそのものの中に書かれています。表の列として外から与えられているわけではありません。

ここで押さえておきたいのが、構造化データと非構造化データのあいだにあるというより、非構造化データに項目の決まりごとを持たせて、構造化データと同じように扱えるようにした状態だということです。

関連記事：構造化データと非構造化データの違い｜AI活用における差と統合に向けた動き

半構造化データが注目されている背景

半構造化データという概念そのものは、以前からありました。
注目が集まっているのは、非構造化データの用途が「貯める」から「AIに探させて答えさせる」に移ったためです。

貯めておくだけなら、目印は要りません。
人が探すときは、フォルダをたどり、ファイル名を眺め、中身を開いて確かめられます。
一方でAIに探させるとなると、どの文書が何なのかを機械が判別できる形になっていないと、候補を絞り込めません。ここで、文書に目印を付ける作業が必要になります。

今後、構造化データのような数字を扱う仕組みと、文書などの非構造化データを扱う仕組みを別々に構築するのではなく、1つにまとめて管理する方法が重要だとされています。（出典: Gartner Data & Analytics Summit 2026の発表内容）

そのなかで半構造化データは、まとめ方の現実的な着地点にあたります。

半構造化データの2つの特徴

人が読めるファイル形式で書かれている

半構造化データを表すファイル形式の代表が、JSONとXMLです。

JSONは、キーと値を対にして並べる書き方で、実際には次のように見えます。

{
  "顧客名": "株式会社サンプル",
  "文書種別": "議事録",
  "日付": "2026-07-15",
  "決定事項あり": true
}

XMLは、同じ内容を項目名で囲んで表します。

<議事録>
  <顧客名>株式会社サンプル</顧客名>
  <日付>2026-07-15</日付>
  <決定事項あり>true</決定事項あり>
</議事録>

プログラムを書いたことがなくても、何が書いてあるかは読み取れるかと思います。

この性質は、実務では見た目以上に大事になります。
付けたキーが正しいかどうかを、担当者が目で確かめられるためです。

データベースに入ってしまうと専門のツールがないと中身を見られませんが、半構造化データならテキストファイルを開けば見ることができます。
業務を分かっている人が「この顧客名は間違っている」と気づける状態を保てるわけです。

後から項目を足せる

半構造化データは、1件ごとに違う項目を持てます。

表形式でこれをやろうとすると手間がかかります。
1,000行ある問い合わせ管理の表に「対応部署」という列を足せば、その列は全1,000行に発生し、過去分は空欄のまま残ります。集計のたびに、その扱いを決めることになるわけです。

半構造化データの場合、途中から次のように書けます。

{"日付": "2026-06-01", "内容": "請求書の再発行依頼"}
{"日付": "2026-07-20", "内容": "納期の確認", "対応部署": "営業2課"}

7月の1件だけが「対応部署」を持っていて、6月の1件は持っていません。
項目の定義がデータの側にあるため、揃っていなくても成立します。

分析の切り口は、業務が変われば変わります。
先に項目をすべて決めきらなくても始められることが、AI活用の場面で意味を持ってきます。

半構造化データのAI活用における3つの価値

AI活用の文脈では、非構造化データの統合、RAGの精度改善、タグを軸にした分析が、それぞれ別のテーマとして語られます。
ただしこの3つは、「非構造化データを半構造化する」という一本の線でつながっています。

部門ごとに分かれた非構造化データを横断して扱える

営業部の議事録、サポート部門の問い合わせ履歴、開発部の仕様書。
この3つは、置き場所も書式も担当者も別々になっています。

AIに「この顧客との過去のやり取りを整理して」と聞いたときに答えが返ってこないのは、この3つを結ぶ手がかりがないためです。同じ顧客の話であることを、機械が判別できません。

ここで、3つの文書群に共通のキーを持たせます。
まずは顧客名、案件名、日付から。
書式も置き場所もそのままにして、それが何についての文書なのかを示す情報だけを揃えていきます。

こうすると、部門をまたいだ絞り込みができるようになります。
ファイルを1か所に集めなくても、同じキーで指せる状態になっていれば、AIは横断して候補を拾えます。

RAGで探し当てる精度が上がる

RAGは、AIが回答する前に社内の資料を検索し、見つかった文書を読ませたうえで答えを作らせる仕組みです。
文書はそのままでは長すぎるため、一定の長さに切り分けてから検索します。
この切り分けた断片が、チャンクと呼ばれるものです。
（参考: AI活用のための社内データ検索｜RAGの精度を上げる検索方法）

RAGの精度は、この検索がどれだけ当たるかで決まります。
そして、検索が外れる典型的な場面が、似た言い回しの文書が大量にあるときです。

社内文書は、まさにこの状態です。
提案書はテンプレートを使い回すことがあり、その場合は顧客が違っても文面がほぼ同じになりますし、月次の定例議事録も、書き出しから議題の並びまで似た形になります。
文章の意味だけで検索したのでは、どの顧客の、いつの文書なのかを区別できません。

断片であるチャンクにキーを付けておくと、この区別がつきます。
その差を測ったのが、バージニア工科大学などの研究チームが2026年に公開した検証です。
チャンクにメタデータ、つまりそのデータが何であるかを説明する情報を一緒に持たせた場合と、持たせない場合とを比べています。

答えの根拠になる部分が上位5件のなかに入っていた質問の割合は、メタデータなしで27〜33%、ありで55〜65%でした。
（出典: arXiv:2601.11863（メタデータと検索精度の関係を測った研究）、書式の決まった文書を集めた検証、ECIR 2026）

この検証で使われたのは米国企業の年次報告書ですが、書式が決まっていて言い回しが似通うという条件は、日本企業の提案書や定例議事録にも当てはまります。

分析したい切り口に合わせてタグを変えられる

表形式のデータで分析の切り口を変えるには、列を設計し直すことになります。
一方、半構造化データの場合は、タグを足すだけで済みます。

【例】既存のデータに後からタグを足して分析に転用する

• 問い合わせ履歴に「解約につながったか」のタグを付け、解約の理由を集計する

もともと問い合わせ対応の記録として溜めていたデータが、作り直すことなく、タグを1つ足すだけで解約分析の材料になります。
同じデータに、後から違う切り口を重ねられるという点が、半構造化データの実務上の価値です。

半構造化データの活用で押さえておく3つのこと

どのタグを付けるかで、返ってくる答えが変わる

半構造化データの話は「文書にタグを付ける」で終わりがちですが、実際に精度を左右するのはどのタグを付けたかです。

当社が社内の文書をAIから引けるようにした実験でも、ここが最も時間のかかる部分でした。

最初に付けたのは、「誰の、どの案件の資料か」「提案書か、議事録か、契約書か」「今も生きている情報か、古いか」という3種類のタグでした。
資料を整理するなら自然に思いつく分類です。

この状態でAIに「勝ってきた提案の共通点は」と聞いたところ、提案書を種類でかき集めて「提案書が何件あります」という答えが返ってきました。
間違ってはいませんが、業務では使えません。

そこで、「意思決定を含むか」「案件のどのフェーズか」「その案件は受注できたのか」というタグを足しました。
すると、受注まで進んでいて、かつ意思決定が残っている案件だけを拾い、そこから共通点を並べられるようになりました。

該当記事: データレイクハウスを自分で作って分かった、AI-Ready化の本当の難所

この2つの違いは、タグの数ではありません。
最初のタグは資料の整理のために作られていて、AIに投げたい問いから作られていなかったという点です。

つまり、順序が逆でした。
タグを先に決めて後から使い道を考えるのではなく、AIに何を答えさせたいかを先に決めて、その答えを出すために要るタグを逆算します。
「勝ちパターンを知りたい」のであれば意思決定と結果のタグが要り、「この案件は今どうなっているか」を知りたいのであればフェーズと最終更新のタグが要ります。

タグが増えたときに、誰がどう管理するかを決めておく

AIで回答してほしい内容が増えればタグは増えていきます。

増えること自体は問題ありません。
支障が出るのは、同じ意味のタグが違う名前で並びはじめたときです。

営業部が「顧客名」で登録し、開発部が「取引先」で登録し、別の担当者が「クライアント」で登録すると、絞り込みが当たらなくなります。
人が見れば同じものだと分かりますが、機械にとっては別の項目だからです。
タグを付けたのに検索の精度が上がらない、という状態はここから生まれます。

そのため、タグが数十種類になるあたりで、次の2つを決めておくことになります。

• どのタグが正式なもので、それぞれどんな値を取ってよいかを1か所にまとめておくこと

• 新しいタグを追加してよいのは誰か、その判断を誰が承認するかを決めておくこと

前者にあたるのは、データカタログです。
社内に散らばっているデータについての説明情報を一箇所に集めて、どこに何のデータがあるかを検索・発見できるようにする仕組みを指します。
関連記事：データカタログとは｜メタデータとの違いとAI活用への影響

後者にあたるのが、データオーナーとデータスチュワードという役割の設計になります
関連記事： AI活用をデータガバナンスで止めないために｜データオーナーとデータスチュワード

すでに使っている文書管理やファイル共有の仕組みに、タグを管理する機能が備わっていることがあります。
作りはじめる前に、手元にあるもので足りないかも確かめておきたいところです。

半構造化しても、アクセス制御は別に必要になる

部門をまたいで文書を横断できるようにすると、見えてはいけないものも横断できるようになります。

役員報酬の議事録、評価の記録、限られた関係者だけで進めている案件の資料。
いずれも元のフォルダでは閲覧範囲が絞られていますが、AIが検索する仕組みを別に作ると、その絞り込みが引き継がれないことがあります。
一般社員の質問に対して、権限のない文書を根拠にした回答が返る状態です。

この制御も、文書にキーを1本足すことで実現されています。

Azure AI Searchが示している方式では、各文書に「閲覧できるグループのID」を持つ項目を1つ足したうえで、その項目を絞り込みには使えるけれども検索結果としては返さない設定にします。
権限の情報そのものを利用者に見せないためです。

検索するときは質問者が所属するグループのIDを渡し、一致する文書だけに絞る、という流れになります（出典: Azure AI Searchで文書ごとの閲覧権限を絞り込む方式の解説、Microsoft Learn）。
なお同ドキュメントは、これが唯一の方法ではなく、標準の仕組みを使えない場合の方式だと断っています。

やっていることは、これまで述べてきた半構造化と同じです。
AI活用のためのタグと、アクセス制御のためのタグは、同じ設計の中にあります。

そのため、タグを設計する段階で、閲覧範囲を示す項目もあわせて決めておくのが順当です。
後から足すこともできますが、その時点で溜まっている文書すべてに遡って値を入れることになります。

自社のデータを半構造化する3つの手順

半構造化データを活用する準備として、いきなりデータレイクハウスを構築し、パイプラインを組んでから始める、という必要はありません。
いま社内にあるファイル群から始められます。

手順1｜答えさせたい問いから、キーを逆算する

最初にやるのは、タグの一覧を作ることではなく、AIに答えさせたい問いを3つ書き出すことです。

「A社との過去のやり取りで、何が決まっているか」「先月の問い合わせで、同じ原因のものはいくつあったか」「この提案は、過去のどの案件に似ているか」。
実際に業務で聞きたいことを、そのままの言葉で書き出してみます。

次に、その問いに答えるために何が分かっている必要があるかを、1問ずつ書き下します。
「A社との過去のやり取りで何が決まっているか」に答えるには、顧客名と、日付と、その文書に決定事項が含まれているかどうかが分かっていれば足ります。3つです。

この作業を3問分やると、同じ項目が繰り返し現れます。
とくに顧客名と日付は、ほぼどの問いにも必要になるはずです。
複数の問いに共通して出てきたもの、それが最初に用意すべきキーになります。

完璧な一覧を先に作ろうとすると、この段階で止まります。
使われないタグを大量に用意するより、問いに答えられる状態を先に作るほうが早く、次に何が足りないかも見えてきます。

手順2｜メタデータを付ける

キーが決まったら、実際に文書へ値を入れていきます。
ここも、専用の仕組みを新しく用意する前に、いま使っているファイル置き場の機能を見ます。

たとえばGoogleドライブには、ファイルに項目を持たせる機能があります。
分類ラベルと呼ばれるもので、「組織のドライブのファイルとGmailのメールを整理、検索してポリシーを適用するためのメタデータ」と説明されています。

持たせられるのは単純なタグだけではありません。
選択フィールド、日付、数値、人物といった項目を設定でき、ユーザーはその項目を基にコンテンツを検索できます（出典: 分類ラベルの管理者としての作業を開始する）。

「契約状況」と「期限」のラベル項目を使えば、金曜日までに署名が必要な契約書をドライブで検索できる、という例を挙げています。
これは、契約書という非構造化データに2つのキーを与えて、期日で絞り込める状態にしたということです。

対象は、いきなり全社に広げず、手順1で書き出した3つの問いに関係するフォルダから始めます。

なお、値を入れる作業そのものは、生成AIで自動化できる範囲が広がっています。
文書を読ませて顧客名や文書種別を判定させる処理であれば、すでに実用になる水準です。
一方で、業界特有の分類や、決定事項として拾ってよいかどうかの判断には、業務を分かっている人の確認が残ります。

手順3｜ファイル形式を変換する

キーの設計と付与ができたら、最後がファイル形式の扱いです。

PDFやWordのままでは、本文とキーが同じファイルの中に混ざっています。
一方、AIが扱いやすいのは、本文とキーが分かれている形です。
先に示したJSONのように、キーと値を並べた部分と、本文の部分を分けて持たせます。

ここで、元のファイルを作り替える必要はありません。むしろ作り替えないほうが安全です。
契約書や議事録の置き場所を動かしたり階層を組み替えたりすると、社員がこれまでどおりの場所に資料を探しに行けなくなります。

代わりに取れるのが、元のファイルはそのままにして、その文書が何なのかを説明した別のファイルを1枚作る方法です。
説明ファイル側にキーと要点を持たせ、本体へのリンクを添えておけば、AIはまず説明ファイルを読んで候補を絞り、必要な原本だけを読みに行きます。
日常業務のフォルダには手を加えず、AIが読むための情報だけを別に足していく形になります。

ここまでを1業務分やり終えると、AIの答えが変わったかどうかが見えてきます。
そこで答えきれなかった問いこそが、次に足すキーの候補です。
手順1に戻り、また少しずつ広げていくことになります。

まとめ

半構造化データとは、決まった表の形は持たないものの、どの部分が何を指すかを示すキーが付いているデータです。

議事録に顧客名と日付と文書種別を与えるだけで、その議事録は絞り込み、数え、比較できる対象になります。
非構造化データにキーと意味づけを与えれば、構造化データと同じように分析できる、というのが本記事の中心にある考え方です。

今後のAI活用において、非構造化データをどう扱うかの重要性は増す一方です。
そのなかで、非構造化データを半構造化データにして構造化データと同じように分析させるという進め方は、主流になっていくと見ています。

自社の文書・議事録・問い合わせ履歴を思い浮かべながら、これはどんなキーを付ければ分析できるデータになるかを考えるきっかけになれば幸いです。
データがAIから使える状態とは何かをより広く整理したい場合は、AI-Ready Dataとは｜ビッグデータとの違いと、満たすべき6つの条件もあわせてご覧ください。