LLM入門教材― 「意味の固定」がなぜ AI 活用の勝負所になるのか

Transcript

1. LLM 入門教材 ― DM 実務者向け（改訂版） — 1 — データマネジメント実務者のための LLM 入門教材 ― 「意味の固定」がなぜ AI 活用の勝負所になるのか ― ※ 本教材は LLM 初学者 × データマネジメント実務者を対象としています
2. LLM 入門教材 ― DM 実務者向け（改訂版） — 2 — はじめに：この教材の到達点 読み終えると次の 3 つができるようになります。 1. LLM が「何を学習して」「どう出力しているか」を、最低限の内部構造で説明できる。 2. トークン化・埋め込み（embedding）が、検索・データ基盤・ガバナンス設計とどうつながるかを説明できる。 3. 社内 AI 活用で重要になる「意味の固定（セマンティックレイヤー）」と、「操作・実行まで含む厳密性（オント ロジー）」が必要になる理由を、技術の流れ（1〜7 章）から説明できる。
3. LLM 入門教材 ― DM 実務者向け（改訂版） — 3 — 第 1 章 LLM とは何か：「次のトークンを当てる機械」 LLM（Large Language Model）は、ひとことで言えば「次のトークンを当てる確率モデル」です。入力された文 脈を受け取り、次に来そうなトークン（文字や単語のかけら）に確率を振り、1 個選び、また次…を繰り返して文章 を生成します。 スマホの予測変換を極限まで強化したもの、と考えると直感が合います。スマホは前後数語くらいですが、LLM はも っと長い文脈を使って「次」を決めます。 ここで初心者がつまずくのは、「内部では何が起きているのか」です。最低限の骨格はこうです。 ▶ 文字列 →（トークン化）→ トークン ID →（埋め込み）→ ベクトル列 →（Attention/FFN）→ 次トークン予測 用語をいったん「役割」で押さえます。 トークン化: 文章を"モデルが食べられる粒"に分解し、ID（整数）に置き換えること。 埋め込み（embedding）: トークン ID（離散）を、意味っぽい位置関係を持つベクトル（連続値）に変換 すること。 Attention（注意機構）: 「今この位置の出力を作るのに、文中のどこを強く参照するか」を重みづけする仕組 み。 FFN（Feed-Forward Network）: Attention で集めた情報を、層ごとに加工して表現を作り替える部 品。 Transformer: 上の Attention と FFN を、層として何段も積み上げた基本設計。2017 年にこの枠組みが確 立しました。 ▶ 重要な前提：LLM は「真偽判定機械」ではなく「続きをそれっぽく出す機械」です。だから社内利用で は、後半で扱う「意味の固定」や「根拠の足場」が必要になります。
4. LLM 入門教材 ― DM 実務者向け（改訂版） — 4 — 第 2 章 トークン：LLM が文章を「食べる」前の下ごしらえ 2.1 なぜトークン化が必要か LLM は数値しか扱えません。文字列はそのままでは処理できないため、必ず「区切って ID 化」します。テキストだけ でなく、画像や音声も最終的には"トークン列"的に扱われます（ここでは詳細省略）。 2.2 サブワード分割：単語より細かく、文字より賢く トークンは「単語」より細かいサブワード（語の一部）になることが多いです。未知語や日本語でも破綻しにくくする ためです。BPE や SentencePiece が代表例です。 tiktoken 等を使うと実際の分割を確認できます（運用上はコストや最大入力長に効きます）。 2.3 vocab（語彙表）と確率の誤解を解く ここは「ID」と「確率」がごちゃ混ぜになりやすいので、順番にほどきます。 まず、vocab（語彙表）は"辞書"です。辞書なので、「この文字の並びはこの ID」という対応が入っているだけ で、確率は持っていません。 LLM の内部処理を"やること"で言うと、だいたい次です。 1. 文章を ID 列にする — 文章 → トークン列 → トークン ID 列（ここで使う対応表が vocab） 2. ID をベクトルに置き換える — トークン ID → 埋め込みベクトル（ベクトルは「意味っぽい座標」） 3. 文脈でベクトルを更新する — Attention と FFN によって、各位置のベクトルが「文脈を踏まえた表現」に変換 される 4. 次に出す候補へ点数を付ける → 確率にする → 1 個選ぶ — 各トークン候補に「点数（logits）」をつけ、 softmax で確率分布にして、次の 1 トークンを選ぶ ▶ 確率が出てくるのは最後（次の 1 個を選ぶ瞬間）です。vocab は辞書であって、確率で動くものでは ありません。
5. LLM 入門教材 ― DM 実務者向け（改訂版） — 5 — 🔧 DM 実務者への接続 vocab は「コード表」、トークン ID は「コード値（整数）」に近いです。コード表が確率で揺れないのと同じで、 揺れるのは「どのコードを次に出すか（ランキング）」側です。
6. LLM 入門教材 ― DM 実務者向け（改訂版） — 6 — 第 3 章 埋め込み（embedding）：言葉に座標を与える 3.1 embedding とは何か embedding は「離散的な ID（トークン）を、連続値ベクトル空間の点に写像する」ことです。類似した語は近 く、無関係な語は遠くに置かれます。この"近さ"を使って検索や分類ができます。 3.2 「昔のベクトル」と「今の埋め込み」 「ベクトル＝古い／埋め込み＝新しい」ではありません。発想は同じで、性能と用途が増えた、が実態です。 3.3 静的 embedding → 文脈 embedding：進化で何が変わったか 初期の代表が Word2Vec です。これは「単語ごとに固定のベクトル」を学習します。なので「bank」はいつでも同じ 位置です。 一方、BERT 以降の流れでは「同じ単語でも、文脈によって表現（ベクトル）が変わる」のが重要になります。金 融の文脈の"bank"と、川の土手の文脈の"bank"は、別の意味として扱われやすくなります。 進化で変わったことを、実務向けに言い換えるとこうです。 静的 embedding: 同音異義語や多義語に弱い（曖昧さを内包したまま近傍検索になる） 文脈 embedding: 曖昧さが文脈でほどける（検索・抽出・要約の精度が上がる） 🔧 DM 実務者への接続 embedding は「新しいキー体系」ではなく"近さ（類似）で結合するための座標"です。DB の結合がキー一 致で厳密なのに対し、ベクトル検索は近傍で曖昧結合をします。したがって、しきい値・再ランキング・検証の設 計が必ず要ります。
7. LLM 入門教材 ― DM 実務者向け（改訂版） — 7 — 第 4 章 Transformer の心臓部：Attention と FFN 4.1 Attention：「どこを見るか」を決める Attention は「文脈中のどこを参照するか」を重みづけします。照応（それ／この／あれが何を指すか）や、依存 関係の解決に効きます。Transformer の基礎設計は 2017 年の論文で提示されました。 参照: Vaswani et al. (2017) "Attention Is All You Need" — arXiv:1706.03762 4.2 FFN：集めた情報を"加工"する Attention は、文中の情報を「集めて混ぜる」側の部品です。FFN は、混ぜたものを層ごとに加工し、表現を作り 替えます。ここでの非線形性の数学的な詳細は、初学者段階では「表現を変形して特徴を作る工程」くらいで十 分です。
8. LLM 入門教材 ― DM 実務者向け（改訂版） — 8 — 第 5 章 生成（GPT 系）と理解（BERT 系）の設計思想 5.1 BERT：穴埋めで文脈理解を鍛える BERT は文中の一部を隠して当てる（Masked LM）ことで文脈理解を鍛えます。分類・抽出・検索で強い理由 の一つです。 参照: Devlin et al. (2018) "BERT" — arXiv:1810.04805 5.2 GPT 系：次を予測し続けて生成が得意に GPT 系は次トークン予測を繰り返し、生成に強くなります。近年は指示追従やツール利用と組み合わさって「文章 生成」だけでなく「業務フローの一部」を担えるようになっています（ただし、そのときに"意味の固定"が問題になりま す）。
9. LLM 入門教材 ― DM 実務者向け（改訂版） — 9 — 第 6 章 誤読とハルシネーション：どこで起き、どう減らすか 6.1 誤読とハルシネーションは別物 誤読: 渡した情報を読み違える（参照の抜け、取り違え） ハルシネーション: 無い事実を作る（それっぽさで補完してしまう） 6.2 長文で誤読が増える理由（Lost in the Middle） 長い文脈では重要情報をうまく使えず性能が落ちる傾向が報告されています。つまり「長文をそのまま渡せば賢くな る」は成立しません。要約・分割・構造化が効きます。 参照: Liu et al. (2023) "Lost in the Middle" — arXiv:2307.03172 6.3 対策の方向性：モデルに気合い、ではなく"足場づくり" 対策は大きく 2 系統です。 入力側を整える: 短く・構造化・重要箇所の前置き 参照できる根拠を与える: 次章の RAG／さらに次の章のセマンティックレイヤー
10. LLM 入門教材 ― DM 実務者向け（改訂版） — 10 — 第 7 章 検索と RAG：LLM に「根拠の足場」を渡す この章の目的はシンプルです。LLM は"それっぽい続きを出す"ので、社内利用で必要なのは「根拠となる社内情報 に結びつける仕組み」です。それを実現する代表が RAG です。 7.1 まず用語：検索は「拾う→並べる→渡す」 検索はだいたい次の 3 つです。 拾う（retrieval）: 候補の文書（または断片）を集める 並べる（ranking）: 質問に近い順に並べる 渡す（grounding）: 上位の根拠を LLM に渡して回答させる ここで「拾う・並べる」に 2 つの流派があります。 7.2 キーワード検索（BM25）：透明で制御しやすい BM25 は、文書中の単語の出現状況などから関連度を計算する代表的手法です（雑に言うと"単語がどれだけ 重要か"でスコアを作る）。実装や運用の世界では Lucene/Elasticsearch 等で広く使われています。 強みは「なぜその文書が上位か」を説明しやすいことです（監査・説明責任に向きます）。 参照: Robertson & Zaragoza "BM25 and Beyond" 7.3 ベクトル検索：意味で拾えるが、設計が要る ベクトル検索は、質問文と文書断片を embedding して「近いもの」を拾います。類義語・言い換えに強い反面、 近さが直感に反することもあります。 大量データでは厳密な総当たりが重いので、近似近傍探索（ANN）を使います。HNSW はその代表的手法で す。 🔧 DM 実務者への接続 DB 実務者向けに言い換えると、「B-tree がスカラー検索（id = 123、日付がこの範囲 ）のインデックスな ら、HNSW はベクトル検索（この文章に意味が近い文章トップ 10）のインデックス」です。つまり、B-tree は “一致”を速くし、HNSW は“近さ（類似）”を速くします。 参照: Malkov & Yashunin (2016) "HNSW" — arXiv:1603.09320
11. LLM 入門教材 ― DM 実務者向け（改訂版） — 11 — 7.4 ハイブリッド検索：現実は"両方使う" 実務では、キーワード検索（透明性）とベクトル検索（柔軟性）を組み合わせることが多いです。結果の統合方 法の一つが RRF（Reciprocal Rank Fusion）で、別々のランキングをうまく混ぜます。 参照: Cormack et al. "Reciprocal Rank Fusion" 7.5 RAG（Retrieval-Augmented Generation）とは何か RAG は、モデル内部の暗黙知だけに頼らず、検索で引いた外部テキスト（明示知）を文脈として与え、生成を 「根拠付き」に寄せる考え方です。 参照: Lewis et al. (2020) "Retrieval-Augmented Generation" — arXiv:2005.11401 RAG の基本フローはこうです。 1. ユーザー質問 2. 検索（キーワード／ベクトル／ハイブリッド） 3. 上位の根拠断片をプロンプトに詰める 4. LLM が「根拠を参照しながら」生成する ここまでで"嘘は減る"方向に進みますが、次の限界が残ります。 ・根拠が複数あって定義が揺れている（例：営業利益の定義が部門で違う） ・根拠が文章で、システム操作（更新・承認・発注など）の契約になっていない ▶ この限界が第 8 章（意味の固定）と第 9 章（操作の厳密化）に繋がります。 7.6 GraphRAG：文書だけでなく「関係」を使って拾う 基本 RAG は"断片を拾う"ので関係に弱いです。GraphRAG は、文書からエンティティや関係を抽出してグラフを 作り、検索・要約に使うアプローチです。Microsoft Research が整理した GraphRAG の枠組みや実装が知ら れています。 「部署 A の施策が、どの KPI とどのデータ定義に依存するか」みたいな"関係を辿る"問いで効きやすい一方、グラフ
12. LLM 入門教材 ― DM 実務者向け（改訂版） — 12 — 構築の設計（粒度・正規化）が必要になります。 7.7 Self-RAG / Corrective RAG：検索結果を自己点検してやり直す RAG の失敗原因は「検索が外す」「根拠が足りない」「根拠の質が悪い」が多いです。また、GraphRAG で関係 性を拾っても検証をしないと意味がない。そこで、LLM 側が自己点検して、必要なら再検索・修正する系が出てき ます。 Self-RAG: 必要なときに検索し、生成した内容も自己批評して改善する方向性。 Corrective RAG（CRAG）: 検索結果の品質を見て、修正・追加検索などで補正する方向性。 ここまで来ると、「検索で根拠を拾う」だけでなく「根拠の扱い方を制御する」段階に入ります。
13. LLM 入門教材 ― DM 実務者向け（改訂版） — 13 — 第 8 章 セマンティックレイヤー：「定義に忠実な意味」を固定す る RAG で根拠を渡しても、社内では次が起きます。 ・根拠（文章）が複数あり、定義が揺れる ・指標・粒度・結合条件が暗黙で、部署や人で解釈が変わる ・LLM が"それっぽい統合"をしてしまい、監査不能になる だから必要なのがセマンティックレイヤー（意味の固定装置）です。これは「ビジネス指標・粒度・エンティティ関係・ 結合条件」を一箇所に宣言し、利用者やツールが共通参照できる状態を作ります。 dbt の Semantic Layer は、entities / dimensions / measures という要素で定義して、共通の意味でク エリできるようにします。 参照: dbt Semantic Models — docs.getdbt.com/docs/build/semantic-models LLM 視点で言うと、セマンティックレイヤーは「自由作文してよい領域」と「定義で拘束すべき領域」を分離する境 界線です。たとえば「売上」「粗利」「営業利益」を自然言語の曖昧さで扱うのではなく、「この定義（版）で、こう集 計する」という契約に落とします。 8.1 セマンティックレイヤーが LLM に効く理由（技術の流れで説明） 1〜7 章の流れで言い換えるとこうです。 ・LLM は次トークン予測で、尤もらしさに寄る（第 1 章） ・長文根拠を渡しても読み違え・抜けが起きうる（第 6 章） ・RAG で根拠を与えても、根拠が"文章"のままだと定義が揺れる（第 7 章） そこで「定義済みの指標・粒度・結合」をツールとして呼べる形にする。すると LLM は「SQL を自由生成」するより、 「定義済みのメトリクスを呼ぶ」方へ寄せられます。これはガバナンス・再現性・監査性の勝ち筋です。
14. LLM 入門教材 ― DM 実務者向け（改訂版） — 14 — 🔧 DM 実務者への接続 ここで重要なのは、回答品質そのものより「何を正とするか（定義・根拠・参照範囲）」を運用で固定できるか です。データマネジメントの主戦場がここにあります。
15. LLM 入門教材 ― DM 実務者向け（改訂版） — 15 — 第 9 章 オントロジー：AI が「出力」だけでなく「操作」する世界 のための厳密性 第 8 章で見たセマンティックレイヤーは、「売上はこの定義、粒度はこの単位、結合条件はこう」を機械実行可能な 形で固定する装置でした。これにより「LLM が正しく集計して正しく答える」が成立します。ただし、ここで固定される のは分析の世界 ― つまりデータを読んで集計して回答する、読み取り専用の領域です。 AI が「動かす」側に広がると、何が足りなくなるか AI 活用が「答えを返す」だけでなく、「発注する」「承認する」「設備を動かす」など現実世界を変更する行為（操 作）に広がると、セマンティックレイヤーだけでは足りなくなります。 操作には次のようなルールが伴うためです。 ・誰が（権限）/何の対象に（エンティティ間の関係）/どの条件で（制約・前提条件）/やり直せるか（履歴・ロ ールバック） これらは「用語・指標・計算定義」では表現しきれません。 ここで出てくるのがオントロジー オントロジーは、概念（クラス）・関係（プロパティ）・制約を形式的に定義する枠組みです。セマンティックレイヤー が「指標の辞書」だとすると、オントロジーは「世界の構造と規則の設計図」に近い位置づけです。W3C の OWL は、このための標準仕様です。 参照: W3C "OWL 2 Web Ontology Language" — w3.org/TR/owl2-overview 場面 必要な層 理由 「先月の売上は？」 セマンティックレイヤ ー 定義に従い集計して回答すればよい 「この部品を発注して」 オントロジー 部品→サプライヤー→契約→承認権限→在庫制約の関係が必 要 「契約 A の請求先を変更し て」 オントロジー 契約→当事者→請求先の関係＋変更権限＋履歴管理が必要 ▶ この整理が示すのは、AI が"読むだけ"なら RAG でも戦えるが、"動かす"ならオントロジー的な契約が 必要、ということです。
16. LLM 入門教材 ― DM 実務者向け（改訂版） — 16 — 9.1 企業事例（操作・現場連携型）：Toyota「O-Beya」 トヨタの「O-Beya」は、もともとの"Obeya（大部屋）"文化をデジタル化し、設計・意思決定を加速する取り組み として Microsoft 側から紹介されています。 参照: Microsoft News "トヨタ自動車、エンジニアの知見を AI エージェントで継承へ" Azure Cosmos DB の事例記事では、O-Beya での生成 AI 活用（複数エージェント、ベクトル検索、利用規 模など）も技術的に説明されています。 参照: Microsoft DevBlogs "How Toyota uses Azure Cosmos DB to power their multi-agent AI system" 🔧 DM 実務者への接続 「チャットで賢く答える」だけではなく、現場の意思決定・設計プロセスに入ると、参照・定義・権限・履歴がセット で要求されます。まさにデータマネジメントが前面に出る場面です。
17. LLM 入門教材 ― DM 実務者向け（改訂版） — 17 — 第 10 章 まとめ：データマネジメントはやることがそれなりにある データベース工学の言葉に翻訳すると、ここまでの結論はこうです。 ・トークン化は「コード化」そのもの（文字列→ID）。 ・埋め込みは「近さで結合するための座標」。キー一致ではなく近傍で曖昧結合する。 ・RAG は、LLM に"根拠の足場"を渡す仕組み。だが根拠が文章のままだと定義が揺れる。 ・セマンティックレイヤーは、指標・粒度・結合条件を契約として固定し、LLM を"定義に従わせる"ための中核。 ・AI が「出力」から「操作」に広がると、オントロジー的厳密性（対象・関係・制約・権限・履歴）が必要になる。 ※ただし、これはかなり一部の業界に一旦限るだろう（インフラ・金融・自動車・医療・大規模 SaaS など、プロダク トの不整合＝死みたいな業界） ★ 核心メッセージ LLM 活用の勝負所は「モデル選定」より「意味の固定・供給・検証（ガバナンス含む）」にあり。 付録 業界情報 1. “自律化”が前提になり、AI がワークフローの実行主体に寄っていく（＝オペレーティングモデルが変わる） 2. 汎用 AI から、業界データと業務手順まで統合した Vertical AI へ寄っていく（医療・建設・法務などの例を大量に 出してる） 3. 「ガバナンスが標準化して、説明可能性・倫理・監査が“企業品質”になる」という見立て 2025-2026 年における AI 業務機能と産業応用の網羅的調査報告書 https://jrmkt.com/all/ai_app/
18. LLM 入門教材 ― DM 実務者向け（改訂版） — 18 — 参考文献（主要） ・Transformer: Vaswani et al. "Attention Is All You Need" (2017) — arXiv:1706.03762 ・Subword: Sennrich et al. (2016), SentencePiece: Kudo & Richardson (2018) ・Word2Vec: Mikolov et al. (2013) — arXiv:1301.3781 ・BERT: Devlin et al. (2018) — arXiv:1810.04805 ・Lost in the Middle: Liu et al. (2023) — arXiv:2307.03172 ・HNSW: Malkov & Yashunin (2016) — arXiv:1603.09320 ・RAG: Lewis et al. (2020) — arXiv:2005.11401 ・GraphRAG: Microsoft Research ・Self-RAG / Corrective RAG ・BM25: Robertson & Zaragoza "BM25 and Beyond" ・RRF: Cormack et al. "Reciprocal Rank Fusion" ・dbt Semantic Layer — docs.getdbt.com/docs/build/semantic-models ・OWL 2: W3C — w3.org/TR/owl2-overview ・Palantir Ontology — palantir.com/docs/foundry/ontology/overview/ ・Toyota O-Beya — Microsoft News / Microsoft DevBlogs (Cosmos DB) ・直感 LLM ハンズオンで動かして学ぶ大規模言語モデル入門，Jay Alammar (著), Maarten Grootendorst (著), 中山 光樹 （翻訳） (著)，2025 — 本教材は 2026 年 2 月改訂版です —