商談メモはなぜ CRM に入らないのか
営業の鈴木さんは、商談のあとにメモを書きます。「A社、来期の予算は300万くらい、決裁は部長、競合は B社が入っている」。このメモは人が読めば十分ですが、顧客管理システム（CRM）の「予算」「決裁者」「競合」の欄には自動では入りません。欄に入れるには、誰かが読み取って転記する必要があります。この「読み取って、形にそろえる」が、まさに生成AI が得意なことです。データの種類を知ると、AI に何を任せるべきかがはっきりします。
データは3種類
| 種類 | 形 | 例 | 得意なのは |
|---|---|---|---|
| 構造化データ | 行と列がはっきりした表 | 受注履歴、社員名簿、仕訳データ | 従来の IT システム。検索・集計・比較が速い |
| 非構造化データ | 決まった形がない | メール、チャット、Word、PDF、画像、音声、動画 | LLM。読んで意味を取る |
| 半構造化データ | 完全な表ではないが、タグやキーで部分的に整理されている | JSON、XML | AI と他システムの受け渡し |
半構造化データのたとえは名刺です。決まった表ではないが、「会社名」「氏名」「電話」という項目は読み取れます。JSON は「項目名: 値」の組み合わせでデータを書く形式で、AIエージェントの入力・出力の形として非常によく出てきます。
企業が持つデータの約 80% は非構造化データです。ここを扱えるようになったことが生成AI の最大の強みであり、AIエージェント導入の動機の中心です。
誰が処理するか：全部を AI に任せない
試験で問われるのは、「データが何種類あるか」ではなく、業務の流れのどこで、どの種類のデータが生まれ、どの仕組みが処理するかです。
- 構造化データ → API やワークフローの定型処理で取る。LLM に頼る必要はない。社員の所属部署や使っている OS は、人事システムから API で取ってプロンプトに添えればよく、RAG で検索させるものではない。
- 非構造化データ → LLM が読んで意味を取る。
- 半構造化データ → AI と外部システムの受け渡し口。
典型的な流れは 非構造化 → LLM → 半構造化 → API → 構造化 です。先の商談メモなら、メモ（非構造化）を LLM が読み、「予算: 300万、決裁者: 部長、競合: B社」という JSON（半構造化）にして、API で CRM の欄（構造化）に登録する、となります。
この分担にすると、精度・速度・コストのすべてが良くなります。表の検索を LLM にやらせるのは、電卓で済む計算を人に暗算させるようなものです。
メタデータとチャンキング：RAG の精度を決める裏方
メタデータは「データについてのデータ」です。文書に付ける属性情報で、カテゴリ、対応する OS、最終更新日などです。RAG で検索するとき、メタデータが整っていれば「Windows 向けの最新版だけ」と絞り込めます。整っていなければ、正しい情報があるのに古い版や別 OS の手順が返ってきます。ナレッジベースの品質は、中身の質だけでなくメタデータの設計で決まると覚えてください。試験では「非構造化データにメタデータは不要」という記述が誤りとして出ます。
チャンキングは、長い文書を意味のまとまりごとに区切る処理で、区切られた1つ1つをチャンクと呼びます。どのくらいの大きさで、どこで切るかは RAG の精度に直結する設計判断です（詳しくは次の節）。
過去のデータを全部直そうとしない
「AI を入れるから、過去10年分のファイルを全部整形しよう」は現実的ではありません。これから作る・更新するデータを AI が読める形で蓄積する運用を定着させる方が効きます。1つのセルには1つのデータ、表記をそろえる、ファイル名に日付と分類を入れる、文書にカテゴリを付ける。データの整備は導入の「準備」ではなく「導入の一部」です。データを記録のためではなく、AI が使う資産として設計します。
試験で問われる観点
- 3つのデータ（自由記述のクレームメール／月次売上の集計テーブル／AI が出力する JSON）を非構造化・構造化・半構造化に分類する。
- 構造化データの取得は API、非構造化データの理解は LLM。社員の所属や OS 環境は RAG ではなく API で取ってプロンプトに添える。
- 商談メモを CRM に登録する流れ: 非構造化 → LLM → JSON → API → 構造化。
- メタデータは RAG の検索精度を左右する。「不要」という記述は誤り。
- チャンキングの粒度は RAG の精度に直結する設計判断。