なぜ「AIにたくさん読ませる」だけでは足りないのか ─ 出版現場の問いから生まれた「参照可能性」の実証（NLP2026）
RAG時代になって、文章の価値は少し変わった。
人間が「読む」ための文章と、AIが「参照する」ための文章は、同じではありません。
従来の自然言語処理では、分類精度や生成品質が重視されてきた。だが、検索拡張生成（RAG）が一般化した現在、言語資源には別の設計原理が必要になっている。
この問題を、日本語の構造化言語資源「嫉妬AI辞書」を用いて検討した。
結論から言えば、自由文の本文よりも、構造化されたメタデータのほうが、RAGにおける参照性能で大きく優位だった。
データセットと実験結果は GitHub / Hugging Face で公開しています。
この記事では、その問題意識と結果を、論文より少し平易に整理して紹介したいと思います。
最初に：この研究が「珍しい」のはなぜか
エンジニアの目線では、「RAGに構造化データが有効」という話は、直感と一致する部分があるかもしれない。
この研究が珍しいのは、出版業界の編集現場から生まれた問いであるという点。
2026年初頭、出版界では2つのAIプロジェクトが話題になっていた。
マガジンハウス「もしもし、ブルータス。」
45年分・全1040号のバックナンバーをGeminiに学習させた対話型AI。Ginza Sony Parkの電話ボックスで受話器を取ると「ブルータス」と会話できる。
ダイヤモンド社「ちきりんAI on LINE」
ベストセラー4冊・ブログ全文・X投稿・Voicy発言を読み込ませ、ちきりんのキャラクターを再現した有償チャットボット。2026年1月リリース。
どちらも「大量のコンテンツを読み込ませた」ことを最大の売りにしている。
これを見た多くの編集者はこう思う。
「やっぱり、量が大事なんだ」と。
残念だが、それは間違っている。
この記事はその間違いを、実験データで示すものです。
AIは「読んで」いない。「参照して」いるだけ
編集者の仕事は「大量に読んで、選んで、削る」こと。
書店に並ぶ本を読み、映画を観て、街を歩く。
大量のインプットから直感が磨かれ、企画が育まれる。
だから「AIにも大量に読ませれば賢くなる」と思うのは自然な発想だ。
しかしこの発想は、人間の学習モデルをAIに当てはめている。
ここが根本的な間違い。
今のAI（特にRAG）は、全文を「理解」しているのではない。
ユーザーの質問に対して、データベースから関連する断片を検索して、それを参照して、回答を生成している。
AIがやっているのは「読書」ではなく「索引引き」に近い。
このとき、全文テキストに含まれる物語的な修飾、文脈依存の表現、曖昧な代名詞──人間の読者にとっては味わい深い要素──は、少なくとも検索・参照の観点では、機械にとってノイズになりやすい。
「検索・参照の精度を上げたいとき、本文を丸ごとコピーして索引欄に貼り付ける編集者はいない」。しかしAIに対しては、まさにそれをやっている。
出版現場から生まれた問い
出版社の人間として、日々「新規読者開発をどうするか」という問いと向き合っている。
婦人公論.jpで連載中の『嫉妬マニア』（著者：斉藤ナミ氏）を眺めながら、ある仮説が浮かんだ。
「SEO：嫉妬と言えば斉藤ナミ」という戦略より、
「AI：その嫉妬を説明するなら斉藤ナミの記事を引用すると…」というAIの教科書を作る方がいいのではないか？
要は、コンテンツをAIに読ませるのではなく、AIに教え込む発想だ。
そのために「嫉妬AI辞書」の構築を始めた。各エピソードを構造化メタデータに変換していく地味な手作業。深夜と早朝の空いた時間で進めた。
作業を進めるうちに、ある仮説が閃いた。
「RAGで検索するとき、原文テキストをそのまま食わせるより、構造化データのほうが精度が高いのではないか？」
これを検証した結果が、言語処理学会NLP2026での論文発表につながった。
著者は59歳。エンジニアでも研究者でもない、出版社の新規事業開発だ。
これは感情分析の研究ではない
まず誤読を防いでおく。
この研究の目的は「嫉妬という感情を分類すること」ではない。
**「RAG時代に、AIが参照しやすい言語資源をどう設計するか」**という、設計原理の提案と実証だ。
「嫉妬」はあくまで実証の題材である。本質は言語資源の設計方法論にある。
データセット：嫉妬AI辞書（Jealousy AI Dictionary）
| 項目 | 内容 |
|---|---|
| 原典 | 婦人公論.jp 連載「嫉妬マニア」（著者：斉藤ナミ氏） |
| エピソード数 | 321件 |
| メタデータ項目数 | 25項目 |
| 評価クエリ数 | 400件（4種類 × 100件） |
| ライセンス | CC BY-NC-SA 4.0（学術・教育目的のみ） |
構造化メタデータの設計（実験に使用した9項目）
各エピソードに25項目のメタデータを付与し、検索に有効な9項目を連結した core_text を実験に使用した。
core_fields = [
"jealousy_direction", # 嫉妬の方向
"analysis_target", # 分析対象
"target_of_jealousy", # 嫉妬対象
"jealousy_vocabulary", # 嫉妬語彙
"jealousy_structure_category", # 嫉妬構造カテゴリ
"comparison_pair", # 比較の構図
"analysis_axis_distance", # 心理的距離
"analysis_axis_effort_intervention",# 努力介入可能性
"behavior_pattern", # 行動パターン
]
空欄はスキップする。欠損ではなく、意図的な設計判断だ。
不確実な情報を無理に埋めるより、確実な情報だけを出力するほうが参照精度が高まる。
補足：primary_emotion_vector について
これは本研究の主題ではなく、構造化設計の一例として参照されたい。
25項目のうちのひとつに、感情の混合状態をJSONで記述する primary_emotion_vector がある。
{"anger": 0.8, "sadness": 0.6, "desire_for_recognition": 0.9}
GoEmotionsに「jealousy（嫉妬）」が存在しないのは、複合感情の取り扱いが困難なためだ。英語では jealousy / envy / spite の区別が曖昧だが、日本語では明確に異なる。この項目はそのギャップを埋める設計上の選択であり、感情分類のためではなく、検索クエリと語彙マッチングするための構造化の一環として位置づけられる。
実験設計
4条件の比較
| 条件名 | 内容 |
|---|---|
core_text |
構造化メタデータのみ（9要素を連結・空欄スキップ） |
long_text_only |
本文のみ（構造化なし） |
core_plus_long |
構造化メタデータ + 本文 |
short_text |
短い要約文のみ |
タスクと評価指標
- タスク：Reference Retrieval（参照点回収）：クエリに対し正解エピソードを上位k件に返す
- 評価指標：Recall@10
- 検索モデル（論文）：TF-IDF + コサイン類似度（char 3-5gram）
- 追加実験：Dense Retrieval（multilingual-e5-large）
クエリ設計（400件）
| スタイル | 件数 | 概要 |
|---|---|---|
shorttext |
100 | 原文抜粋 |
comparison |
100 | 比較構図 |
distance_effort |
100 | 心理的距離・努力介入 |
behavior |
100 | 行動パターン |
結果
主結果（STRUCT クエリ, n=300 ／ TF-IDF）
| 条件 | Recall@10 |
|---|---|
core_text（構造化メタデータのみ） |
59.0% |
long_text_only（本文のみ） |
5.3% |
core_plus_long（メタデータ+本文） |
58.3% |
構造化メタデータのみは、本文のみに対して Recall@10 で 11.1倍の性能差（p < 0.001）。
behavior クエリ: core_text 65% vs long_text 4% → 16.3倍
comparison クエリ: core_text 61% vs long_text 5% → 12.2倍
distance_effort: core_text 51% vs long_text 7% → 7.3倍
重要な点として、本文を追加しても精度は向上しない（core_plus_long 58.3% ≈ core_text 59.0%）。
少なくとも今回の実験条件では、本文追加はノイズとして働いた。
追加実験：Dense Retrieval（multilingual-e5-large）
論文発表後、Dense Retrieval による追加実験を実施した。
| モデル | core_text | long_text_only |
|---|---|---|
| TF-IDF（全クエリ, n=400） | 69.25% | 29.0% |
| Dense-E5（全クエリ, n=400） | 53.0% | 24.0% |
Dense Retrieval でも core_text の優位性が再現された。
数字の読み方を整理しておく。 11.1倍は「構造クエリ（STRUCT）に絞った場合」の主結果。2.4倍・2.2倍は「全クエリ（short_text含む400件）」での追加比較だ。short_text（原文抜粋）はどの条件でも Recall@10=100% になるため、全クエリ集計では long_text_only の数字が底上げされる。条件の違いを踏まえて読んでほしい。
TF-IDF は語彙表面のマッチングに依存するため構造化語彙統制の効果が直接現れる（STRUCT条件で11.1倍）。Dense Retrieval は語彙に依存しない意味空間でのマッチングを行うため差は縮まるが、それでも約2.2倍の優位性が維持されている。少なくとも今回の実験条件では、「語彙統制によるノイズ排除」の効果が意味ベクトル空間においても有効だったと言える。
考察：なぜ構造化メタデータが強いのか
1. ノイズ排除
本文には、物語的な修飾・文脈依存の表現・曖昧な代名詞が多数含まれる。
これらが検索クエリとの無関係な語彙マッチングを引き起こし、精度を下げる。
2. 語彙一貫性
jealousy_structure_category に「承認競争型」「ゼロサムゲーム型」などの統制語彙を使用することでクエリとのマッチングが安定する。自由文では同じ概念が「嫉ましい」「悔しい」「羨ましい」など多様な表現で現れ、マッチングが分散する。
3. 情報密度の向上
空欄スキップにより、1エントリあたりの有意味情報密度が上がる。
「なし」「不明」などのパディングは、むしろ参照精度を下げる。
「量は質ではない。純度こそ質である」
321件という小規模データセットでも、少なくともこの実験条件では、構造化による純度向上で11倍の性能差を実現した。
編集者向けの言い換えをすると、こうなる。
例１）企画会議のシーン
新人編集者が「参考資料です」と100ページの資料をドンと置く。誰も読まない。ベテランはA4一枚に要点を絞って持ってくる。AIへ全文を食べさせるのは、新人がやっていることと同じだ。
例２）書棚の比喩
45年分の雑誌を倉庫にバラバラに積み上げて「この中から探して」と言うのがAIに全文食べさせること。各号ごとにテーマ・キーワード・掲載店名のカードを作って整理棚に並べてあるのが、構造化データの下準備だ。
なぜ出版業界にとって重大なのか
業界が陥りやすい失敗シナリオ
「もしもしブルータス」「ちきりんAI」はいずれもユーザー体験として優れたプロジェクトだ。電話ボックスでブルータスと話すという企画センス、ちきりんっぽいやりとりをAIで体験できる新しさ、それ自体は正当に評価される。
問題は、大量投入型のアプローチと参照性能は別問題であるという認識が共有されないまま、業界全体が「量＝正解」に倣ってしまうことだ。そのとき起きやすいシナリオを整理する。
- 成功事例を見て「ウチもやろうか」と動く
- 「全文を食わせればいいんだろう」と大量コンテンツをスキャン・投入する
- 精度が出ない
- 「それっぽい」語調や文体で誤魔化そうとする
- 読者（利用者）は前例がないため「すごいね」と盛り上がるが、一過性のイベントで終わる
AIが悪いのではない。設計が間違っている。
そしてもうひとつ危険なシナリオがある。
「全文じゃダメなのか。じゃあ構造化だ！」と、AIの仕組みを学ばないまま構造化に手を出す。
人間の読者向けの判断基準でメタデータを設計する。
精度が出ない。「構造化は意味がない」と結論づける。
正しい方向に向かったのに、やり方が間違っているせいで、正しい方向そのものが消える。
著作権問題との接続
この研究には、もうひとつの重要な含意がある。
海外では書籍のAIライセンス契約で巨額の取引が行われている。日本の出版社の多くはまだ気づいていない。書籍・記事の全文をAIに学習させることへの抵抗感は、著作権の文脈でも正当だ。
しかしここに逆転の発想がある。
「構造化データを作れば、全文を読ませなくてもAIに作品を理解させられる」
著作権法第30条の4（情報解析目的の著作物利用）の問題は根深い。
しかし、全文ではなく「構造化メタデータ」としてAIに参照させる設計が確立できれば、著作者の権利を守りながらAI時代のコンテンツ活用が可能になる。
これはエンジニアの問題ではなく、コンテンツ産業全体の設計問題だ。
「AIナレッジエンジニアリング」という新しい職能
編集者は「削る」プロだ。
しかし「人間の読者向けに削る」と「AIが参照しやすいよう削る」は、まったく別の判断基準が必要だ。
人間向け編集：美しい文章か。読者の心を掴むか。
↓（判断基準）人間の認知
AI向け設計：TF-IDFスコア。Dense Retrievalの埋め込み。チャンクサイズ。
↓（判断基準）検索アルゴリズム
逆に、エンジニアはアルゴリズムに詳しい。しかし、コンテンツのどの側面が構造化に値するのか、どのメタデータ項目が読者の「問い」に対応するのか──これはコンテンツの現場にいなければわからない。
両方の視点が要る。
私はこれを「AIナレッジエンジニアリング」と呼んでいる。
「テキストの手触り感覚」と「AIの仕組み」の両方を理解した上で、言語資源（データ）を設計する仕事。
本研究が提案する設計原理 「参照可能性（Referenceability）」 は、この仕事の核となる概念だ。AIが情報を参照しやすい形に言語資源を設計すること。「AIナレッジエンジニアリング」はその実務的な担い手の呼称であり、「参照可能性」がその設計思想の軸になる。
他ドメインへの一般化
「嫉妬」は特殊なテーマに見えるが、この設計原理は汎用的だ。
- HR領域：ハラスメント事例・離職リスクパターンの構造化
- メンタルヘルス：相談内容の感情ベクトル化
- 経営知識継承：CEOデジタルツインのための判断構造の記述
- 医療：患者の語りに潜むパターンの構造化
- 製造業：熟練工の暗黙知の言語資源化
あらゆる業界に「まだ誰も構造化していないデータ」が眠っている。
大規模言語モデルは一般的な知識は豊富だが、特定領域の深い構造化データが決定的に不足している。高品質な特定領域データの枯渇という、いわゆる「2026年問題」と呼ばれる課題だ。
現場の知識と、AIの設計原理を橋渡しできる人間が、今最も求められている。
論文・データセット
- 論文（NLP2026）：RAG時代の言語資源設計原理─構造化テキストによる「参照可能性」の実証
- GitHub：junikematsu/shitto-mania-dic
- Hugging Face：samuraijun/shitto-mania-dic
ライセンス：CC BY-NC-SA 4.0（学術・教育目的のみ、商用利用禁止）
まとめ
| 評価軸 | core_text | long_text_only | 倍率 |
|---|---|---|---|
| TF-IDF（STRUCT, n=300） | 59.0% | 5.3% | 11.1x |
| TF-IDF（全クエリ, n=400） | 69.25% | 29.0% | 2.4x |
| Dense-E5（全クエリ, n=400） | 53.0% | 24.0% | 2.2x |
主な知見：
- 構造化メタデータは TF-IDF 構造クエリで 11.1倍優位（p < 0.001）
- 本文追加による精度向上なし（core_plus_long ≈ core_text）
- Dense Retrieval でも core_text の優位性が再現（53% vs 24%）
- 空欄スキップ設計が有効（パディングはノイズ）
RAGの性能向上は、検索アルゴリズムの改善だけでなく、データ設計によっても大きく達成できる。
そしてデータ設計には、アルゴリズムの知識だけでなく、コンテンツの現場感覚が必要だ。
「AIにたくさん読ませる」のではなく、「AIの教科書を作る」。
この転換が、出版業界に限らず、あらゆるコンテンツ産業に求められている。
Citation
@inproceedings{ikematsu2026referenceability,
title={RAG時代の言語資源設計原理 ー構造化テキストによる「参照可能性」の実証},
author={池松 潤},
booktitle={言語処理学会第32回年次大会発表論文集},
year={2026},
url={https://anlp.jp/proceedings/annual_meeting/2026/pdf_dir/Q5-8.pdf}
}