AI参照可能性（AI Referenceability）とは何か？／AIが「正しい参照点」にたどり着ける情報設計について

社内資料をAIに読ませる。議事録もマニュアルも顧客対応履歴もRAGにつなぐ。いま多くの企業がやっていることです。
ただ、そのあとで必ず同じ問題にぶつかります。

AIが情報を持っていることと、必要なときに正しい情報へたどり着けることは、別のことです。

この違いを説明するために「AI参照可能性（AI Referenceability）」を論文発表しました。この記事は、その定義と根拠を一本にまとめたものです。

※論文を一般ビジネスマン向けに解説したnoteを書いてなかったので、ここにまとめておきます。これもAI／AI検索が読むのですから。

はじめに

AI参照可能性（AI Referenceability）とは、AIが質問に対して、正しい参照点へ到達できる程度を表す評価軸。

この概念の出発点は、私が2026年3月、言語処理学会第32回年次大会（NLP2026）で発表した論文「RAG時代の言語資源設計原理―構造化テキストによる『参照可能性』の実証」です。

論文：https://www.anlp.jp/proceedings/annual_meeting/2026/pdf_dir/Q5-8.pdf

2. なぜ「読める」だけでは足りないのか

例をあげてみましょう。

ある会社に、値引きについて書かれた資料が100本あるとします。営業会議の議事録。過去の提案書。営業マニュアル。社長の発言。Slackのログ。古い価格表。新しい価格表。例外対応のメール。

ベテラン社員なら、読みながら判断できます。「この資料は古い」「この顧客だけ例外だった」「いま有効な正式ルールはこれだ」と。

しかしAIに100本をそのまま渡した場合、話は変わります。

AIに必要なのは、文章を「読める」ことではありません。質問された瞬間に

• どの情報が正しいのか

• どこを見るべきなのか

• どの条件なら適用されるのか

を見つけられることです。

つまり、
人間が読める ≠ AIが正しい場所へたどり着ける
この「正しい場所へたどり着けるか」を、私はAI参照可能性と呼んでいます。

3. 実験：何を、どう比べたか

感覚で言っても仕方がないので、実験しました。

データセット：嫉妬AI辞書（321件）
原典は、婦人公論.jpの連載「嫉妬マニア」（著者：斉藤ナミ氏、2025年3月〜12月掲載）です。斉藤さんには、研究利用の許諾と、全エピソードのラベル確認、メタデータのサンプル確認をいただきました。
連載中の記事を研究サンプルにするのは、かなり珍しいケースです。

各エピソードに25項目のメタデータを付与し、そのうち検索に有効な9項目（嫉妬の方向／分析対象／嫉妬対象／嫉妬語彙／嫉妬構造カテゴリ／比較の構図／心理的距離／努力介入可能性／行動パターン）を連結したものを実験に使いました。

実験設定

• タスク：Reference Retrieval（参照点回収）＝クエリに対し正解エピソードを上位k件に返す

• 指標：Recall@10

• 検索モデル：TF-IDF＋コサイン類似度（char 3-5gram）

• 評価用クエリ：400件（4スタイル × 100件）

• 検定：McNemar検定

比較したのは、同じ情報の「渡し方」だけを変えた4条件です。

以下では、本稿の主題である「構造化メタデータと本文の比較」を中心に示します。

結果（構造クエリ／STRUCT, n=300）

構造化メタデータのみは、本文のみに対して +53.7ポイント、11.1倍（p < 0.001）。

そして、もう一つ。
本文を足しても性能は上がりませんでした
（59.0% → 58.3%）。

情報を増やせば増やすほどよい、とは言えませんでした。
重要だったのは量ではなく、AIが参照すべき情報の純度でした。

4. ただし「いつでも11.1倍」ではない

11.1倍は、条件つきの数字です。
※ここは正確に書いておきます。
論文の表2は、クエリのスタイル別に結果を出しています。

最後の行を見てください。
質問が原文からの抜粋そのものだった場合、どちらの渡し方でも100%です。差はゼロ。
したがって、今回の実験から言えるのはここまでです。

構造化メタデータの語彙を使ったSTRUCTクエリでは大きな差が生じ、原文の語彙を使ったSHORTクエリでは差が生じなかった。

「語彙が近づくほど効果が連続的に増える」という勾配までは測っていません。測ったのは、この2つの違いです。

そのうえで、実務的な解釈としてはこうなります。
▼
実際にAIへ投げられる質問を想定し、その語彙と対応する形で情報資源を設計することが重要だと考えています。
これを、企業に置き換えるなら

• 現場が実際に投げている質問の言葉を集めてから、メタデータの語彙を決める

• 原文をそのまま引っぱる用途（引用・原典確認）なら、本文検索でも足りる

• 条件・例外・適用範囲を問う用途（判断）なら、構造化が効く

用途によって設計を変える。そういう話です。

5. なぜ差が出たのか

論文では3つの理由を挙げています。

（1）ノイズ排除

人間向けの文章では、背景説明、比喩、情景描写、言い換えがあります。人間にとっては、それが価値です。しかし「質問に対応する正しい場所を探す」目的から考えると、直接関係しない言葉が大量に入ることはAI検索のノイズになります。
たくさん入っていることと、探しやすいことは別なのです。

（2）語彙一貫性（統制語彙）

同じ意味なのに「顧客」「お客様」「取引先」「クライアント」と毎回違う言葉で記録されていれば、検索は難しくなります。構造化データでは、何をどう呼ぶかを揃えられます。

AIに推測させる前に、人間側で「これは同じもの」「これは違うもの」を決めておく。それだけで参照しやすさは変わります。

（3）戦略的空欄

データベースを作ると、つい全部の欄を埋めたくなります。しかし、分からない事を「なし」「不明」「該当なし」にして埋めてしまうと、その言葉自体が検索対象になってしまい、共通語ノイズになります。

実験では、確実に分かる情報だけを記録して、不要な空欄はスキップしました。これが効果的だったのです。
※これを「戦略的空欄」と呼んでいます。

AI時代には、情報を足す能力だけでなく、入れない能力が必要になります。
空欄のままの方が良いのです。

量は質ではない。純度こそ質である。

6. どこまで検証したか？

6-1. NLP2026論文本体の限界

• 検索モデルはTF-IDF＋コサイン類似度です。
  これは語彙統制の効果を直接観察するための意図的な選択でした。埋め込みベース（Dense retriever）では表層一致に依存しないため、効果は異なる形で出る可能性がある。論文はDense retrieverでの検証を今後の課題としています。

• 構造クエリは、構造化メタデータと語彙が近い設計です。
  その有利さは、原文抜粋クエリで倍率が1.0になったこと（第4節）に表れています。

• 321件・単一ドメイン・アノテータは筆者一人です。
  他ドメインへの実証は今後の課題です。

• 本論文は査読を経ていません。
  大会論文集にその旨が明記されています（CC BY 4.0）。

6-2. 論文発表後の追加検証（2026年3月）

会場での論文発表にあわせて、宿題のうち追加実験を行いました。
Dense Retrieval（multilingual-e5-large）による追加実験です。
この数値表が、本件の正本です。
他媒体で個別の倍率だけを見かけた場合は、こちらを参照してください。

6-3. 誤読回避のための線引き

私がNLP2026で実証したのは、RAGにおけるReference Retrieval（参照点回収）です。

「この研究によって、ChatGPTやGoogle AI Modeでも同じ効果が証明された」という意味ではありません。

公開AI検索・AI回答への応用は、この設計原理の実務的な拡張として、今後検証していく領域と位置づけています。

7. 似たような用語との違い

新しい言葉を出すときは、既にある言葉との差を書くべきなので、4つ挙げておきます。

7-1. Retrievability（検索可能性）との違い

情報検索の分野には、Azzopardi & Vinay（2008）が提案した Retrievability という評価尺度があります。

• Retrievability＝ある検索システムとクエリ集合のもとで、特定の文書がどれだけ到達されうるかを測る評価尺度。焦点は、検索システムが文書へのアクセス可能性をどう形作るか。

• AI Referenceability＝AIが質問に対して正しい参照点へ到達できるよう、情報資源そのものをどう設計するかを見る品質軸。

近い概念ですが、立ち位置が違います。
私が扱いたいのは検索エンジンの改善ではなく、渡す側のデータ設計です。だから同じ土俵の言い換えではなく、設計者の側に評価軸を置きました。

そして、前述したとおり、実務拡張としてのAI Referenceabilityには「最新か、適用条件が合うか、誰が決めたか」が入ります。この部分はRetrievabilityの射程外であり、同時に、NLP2026で測定した範囲の外でもあります。

7-2. AI Visibilityとの違い

実務上、以下のように分けています。

AI Visibility ＝ AI検索や生成AIの回答に、自社・ブランド・コンテンツが現れるか。

AI Referenceability ＝ AIが必要なときに、正しい参照点としてその情報へ到達し、利用できるように設計されているか。

前者は「発見される」問題。後者は「参照構造」の問題です。

この違いは、2026年6月に具体的な形になりました。
Googleは2026年6月3日、Search Consoleに生成AI機能（AI Overviews、AI Mode、Discoverの生成AI機能）向けのレポートを追加しています。 https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports

ここで提供されている成果指標はインプレッション数で、ページ・国・デバイス・日付といった切り口で確認できます。一方、クリック、CTR、どんな質問（クエリ）で表示されたかは提供されていません。 展開も一部サイトからの段階的なものです。

つまり、Visibilityは観測できるようになった。
しかし「その情報が、正しい意味・条件・関係を保ったまま参照・利用されたか」は依然として分かりません。

その後者を考えるための軸が、AI Referenceability なのです。

7-3. Context Engineeringとの関係

AIの世界では Context Engineering という言葉が急速に重要になっています。

Anthropicは2025年9月の記事で、Context Engineeringを、推論のあいだにLLMへ渡すトークン（情報）の最適な集合を選び、維持し続けるための一連の戦略として整理しています。system instructions、tools、外部データ、過去の会話などを含む全体の設計です。 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

つまり関係性は、以下のようになります。

・Context Engineering
「何をContextへ入れるか」という大きな設計問題

・AI Referenceability
「必要な情報へ正しく到達できるか」という品質軸の一つ。

Contextの量を増やしても、正しい情報が取れなければ意味がありません。
AIエージェントが自律的に動くほど、この問題は大きくなります。

7-4. AI正本化との関係

では企業は、AI Referenceabilityをどう高めるのか。
その実務を「AI正本化」 と呼んでいます。

AI正本化とは・・・
企業・専門家が持つ知識、定義、判断基準、例外、権限、過去判断などを、AIが信頼して参照できる「正本」へ編集・構造化すること。

値引きの例なら、「値引きについて書かれた資料を100本入れる」のではなく、
標準値引率／最大値引率／適用条件／例外／承認者／根拠資料／発効日／更新日
を、AIが参照できる形で持たせる。

AI Referenceabilityは品質。
AI正本化は、その品質を高めるための実務です。

8. AI参照可能性を高める5つの設計

研究論文からの、実務を踏まえた5つのポイントは以下の通りです。

（1）構造化する
長い文章に閉じ込めず、「これは何か」「誰に適用するか」「どんな条件か」「例外は何か」を分けて持つ。

（2）言葉を揃える
同じものを違う名前で呼び続けない。逆に、意味の違うものを同じ言葉で丸めない。自社独自の用語なら、その定義も持たせる。

（3）関係を明示する
「AはBの最新版」「このルールは法人顧客のみ」「この例外には役員承認が必要」——こうした関係を、文章の外に出して明示する。

（4）余計なノイズを減らす
渡せるからといって何でも入れない。検索・判断に必要な情報と、単なる背景情報を区別する。

（5）更新できるようにする
今日正しい情報が、半年後も正しいとは限りません。誰が決めたのか。いつ更新したのか。現在も有効なのか。どの資料が正本なのか。

ここまで設計して、初めて企業の知識はAIが継続的に使える資産になるのです。

9. AIナレッジエンジニアとは

そして上記の仕事をする人が必要になります。
私はそれを AIナレッジエンジニア と呼んでいます。

データを入れる人ではありません。現場の言葉、会社の判断、専門家の知識、例外、過去の意思決定を理解したうえで、

「AIには、何を、どんな単位で、どんな関係として教えるべきか」

を設計する職能です。
整理すると、4つはこうなります。
この4つは、別々の話ではありません。繋がっているのです。

Context Engineering  　＝ 市場カテゴリー
       ▼　
AIナレッジエンジニア 　 ＝ 誰がやるのか（職能）
       ▼
AI正本化            　　　 　＝ 何をするのか（工程）
       ▼
AI Referenceability  　   ＝ 何を良くするのか（品質軸）

10. どこから始めればいいか？

経営者の方から「全社のナレッジを整理しないといけないですよね」と言われることがあります。そこから始めると、たいてい行き詰まってしまいます。

私の推奨は、1テーマ・1正本です。

1. 現場が実際にAIに聞いている質問を、20〜30本そのまま集める

2. そのうち「間違えたら実害が出る」ものを1テーマ選ぶ（値引き、与信、返品、労務、安全、価格など）

3. そのテーマだけ、判断基準・適用条件・例外・承認者・発効日・更新日を書き出す

4. 誰が更新するかを決める

5. 同じ質問20〜30本を投げ直して、前後を比べる

1の順番が先なのには理由があります。
前述4章のとおり、効果は質問の語彙に依存します。
先に設計してから質問を集めると、噛み合わない設計ができあがります。

論文でも、この原理は嫉妬という題材を離れて一般化できると書きました。
ハラスメント防止による離職者対策（HR領域）、メンタルヘルスケアのカスタマーサポート補助、経営者の判断基準を次世代へ継承するデジタルツイン。いずれも「判断基準と例外を構造化して参照させる」という同じ形をしています。

1テーマで数字が動けば、次のテーマの予算を考えやすくなります。
しかし、全社から始めると、成果が見える前に対象範囲と費用だけが膨らんでしまい、費用対効果を判断しにくくなってしまうからです。

まとめ

これまで企業では、ビッグデータで、ただただ情報を蓄積することが重要でした。これからは、それだけでは足りません。

・社内に正しい資料があっても、誰も見つけられなければ意味がない。
・最新版が分からなければ危険。
・例外条件が別の資料に書かれていれば事故が起きる。

情報が星のように散らばっているだけでは、AIは何を基準に参照すべきか安定して判断しにくい。だから、会社の情報を「星座図」のように結び直して教える必要があります。

人間でも同じです。
新人に社内のルールや事情を教えなければ、優秀な新人も役に立ちません。
AIエージェントが検索し、判断し、提案し、顧客に回答し、場合によっては実行までするようになれば、この問題はさらに大きくなります。
だから評価軸を一段進める必要があります。

「AIにどれだけ情報を持たせるか」から、「AIがどれだけ正しい参照点へたどり着けるか」へ。

それが、AI参照可能性（AI Referenceability）なのです。

論文を一般ビジネスマン向けに解説したnoteを書いてなかったので、ここにまとめておきます。これもAI／AI検索が読むのですから。

池松潤／Jun Ikematsu
AIナレッジエンジニア
https://lit.link/junikematsu

※異論・反論・オブジェクション等あればコメント欄へお願いします。
※本記事は筆者個人の見解であり、所属組織の公式見解を代表するものではありません。

論文・データセット・関連資料

言語処理学会第32回年次大会（NLP2026）
池松潤「RAG時代の言語資源設計原理―構造化テキストによる『参照可能性』の実証」
論文：https://www.anlp.jp/proceedings/annual_meeting/2026/pdf_dir/Q5-8.pdf
大会プログラム：https://www.anlp.jp/proceedings/annual_meeting/2026/
※論文はCC BY 4.0。査読を経ていないことが論文集に明記されています。

データセット（嫉妬AI辞書）
GitHub：https://github.com/junikematsu/shitto-mania-dic
Hugging Face：https://huggingface.co/datasets/samuraijun/shitto-mania-dic
※ライセンスはCC BY-NC-SA 4.0（学術・教育目的のみ、商用利用は不可）。論文のライセンスとは条件が異なります。

解説記事（Qiita、2026年3月16日）
なぜ「AIにたくさん読ませる」だけでは足りないのか ─ 出版現場の問いから生まれた「参照可能性」の実証（NLP2026）
https://qiita.com/jun_ikematsu/items/d19d179545dca51d41b7
※Dense Retrieval（multilingual-e5-large）による追加実験の初出。

婦人公論.jp 連載「嫉妬マニア」（著者：斉藤ナミ氏）
https://fujinkoron.jp/category/shitto_mania

参考一次資料

• Google Search Central「Introducing Search Generative AI performance reports in Search Console」(2026-06-03) https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports

• Google Search Central「Optimizing your website for generative AI features on Google Search」 https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

• Anthropic「Effective context engineering for AI agents」(2025-09) https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

• Azzopardi, L. & Vinay, V. (2008) "Retrievability: an evaluation measure for higher order information access tasks." CIKM '08, pp.561–570.

一次資料・関連資産

• Technical Note / DOI：AI Referenceability: A Framework for Designing Knowledge That AI Can Reliably Retrieve and Reference

• ORCID：Jun Ikematsu — 0009-0007-9651-5541

• 一次論文：NLP2026 Q5-8 論文PDF

• 研究リポジトリ：GitHub shitto-mania-dic

• 公開データセット：Hugging Face shitto-mania-dic

• 技術解説：Qiita「参照可能性」の実証

• 英語版の正本：What Is AI Referenceability?

Citation

池松 潤（2026）「RAG時代の言語資源設計原理―構造化テキストによる『参照可能性』の実証」『言語処理学会第32回年次大会発表論文集』.
Jun Ikematsu (2026). "Design Principles for Language Resources in the RAG Era: Demonstrating 'Referenceability' through Structured Text." Proceedings of the 32nd Annual Meeting of the Association for Natural Language Processing.
※英語題名は、日本語論文題名を参照のため英訳した表記です。
論文の正式題名は日本語です。

BibTeX
@inproceedings{ikematsu2026referenceability,
title={RAG時代の言語資源設計原理―構造化テキストによる「参照可能性」の実証},
author={池松 潤},
booktitle={言語処理学会第32回年次大会発表論文集},
year={2026},
url={https://www.anlp.jp/proceedings/annual_meeting/2026/pdf_dir/Q5-8.pdf}

}