その社内文書、AIが読めません。標準化という次の宿題
Markdownで蓄積した社内文書が、なぜ生成AIには「読めるけれど使えない」のか。人間向けの自由記述と機械可読な構造の断絶を、schema.orgなどの公開標準を手がかりに解説します。
その社内文書、AIが読めません。
何年もかけて社内Wikiやマニュアル、議事録をMarkdownでせっせと貯めてきた。ところが、いざ生成AIに「これを読んで答えて」と渡してみると、驚くほど的外れな回答が返ってくる——そんな経験はないでしょうか。
貯めてきたのは間違いなく会社の資産のはずです。しかし、AI活用という新しい使い方の前では、その資産がまったく機能しないという現実に、多くの現場が直面し始めています。
貯めた文書がAIに刺さらない
議事録、営業マニュアル、過去の見積り根拠、トラブル対応の記録。これらをMarkdownやWikiにコツコツ蓄積してきた中小企業は少なくありません。紙よりずっと検索性が高く、担当者が変わっても引き継げる。そう信じて積み上げてきたはずです。
ところが生成AIに「この商品の過去のクレーム対応方針は?」と聞かせても、関係ない文書を拾ってきたり、古い方針と新しい方針を混同して答えたりすることがあります。人間ならタイトルや文脈から「これは去年の話だな」「これは例外対応のメモだな」と瞬時に判断できますが、AIにはその判断材料が文書のどこにも書かれていないのです。
つまり、文書の量や丁寧さの問題ではありません。せっかく蓄積した知識が、AIから見ると「読めるけれど使えない」状態になっている。これは資産のはずだったものが、静かに負債へと変わりつつあるサインです。
人間が読む文書と、機械が使う知識の断絶
なぜこんなことが起きるのでしょうか。原因はフォーマットではなく、構造にあります。
人間向けの文書は、前後の文脈や暗黙の了解を頼りに書かれています。「この件については前回の議事録の通り」「例の案件のことです」——こうした書き方は人間同士なら十分通じます。しかし機械にとっては、「前回の議事録」がどの文書を指すのか、「例の案件」がどの顧客のどの取引を指すのかという参照関係が、文章のどこにも明示的に記されていません。
さらに厄介なのは、同じ内容について書かれた複数の文書が、更新日も出典もばらばらなまま社内に散在しているケースです。人間なら「新しい方が正しいだろう」と経験で補正できますが、メタデータ(更新日や出典の情報)が付与されていない文書群では、多くの生成AI・RAG(検索拡張生成)構成が新旧の優先順位づけに苦労します。結果として、古い情報と新しい情報を同等に「それらしい根拠」として扱い、誤った回答を自信満々に生成してしまうことが少なくありません。もちろんこれはモデルやリランキングの仕組み次第で改善の余地がありますが、根本的にはメタデータの有無が判断材料になっている点は変わりません。
これは書き方が下手だからではありません。人間向けの自由記述と、機械が意味の関係を辿れる構造化された知識との間には、そもそも埋まっていない溝があるのです。AIに読ませるということは、この溝を誰かが埋めてやる必要がある、ということに他なりません。
schema.orgという「共通の語彙」という補助線
この溝を埋める手がかりとして、ウェブの世界で長年使われてきた標準があります。それがschema.org(https://schema.org/)です。これは2011年にGoogle・Microsoft・Yahoo・Yandexが共同で立ち上げた、機械が意味を理解できるようにするための語彙標準で、JSON-LDなどの形式で実装されます。
schema.orgの語彙を使うと、ある情報が「いつ作られたものか」「誰が書いたものか」「何についての情報か」「他のどの情報と関連しているか」といった意味と関係性を、あらかじめ決められたプロパティ名で本文とは別にタグ付けできます。これによってAIや検索エンジンは、文章を読み解いて推測するのではなく、構造そのものから正確に意味を取り出せるようになります。
Googleも検索において構造化データを重視しており、正しくマークアップされたページはリッチリザルトなどの形で優先的に扱われることを、公式のSearch Centralドキュメントで説明しています(https://developers.google.com/search/docs/appearance/structured-data)。つまりこれは特定の一社だけの主張ではなく、複数の検索エンジンやAIが共通して参照する土台になっているということです。
重要なのは、これが単なる技術仕様の話ではなく、「信頼できる引用」を成立させるための基盤だという点です。出典が明示され、更新日時が構造として埋め込まれ、関連情報へのつながりが機械可読な形で示されていれば、AIはどの情報が最新で、どの情報を根拠にすべきかを判断しやすくなります。逆に言えば、標準化されていない文書の山は、どれだけ内容が正しくてもAIにとっては「根拠として引用しにくい情報」のまま埋もれ続けるということです。
schema.orgが示すこの方向性は、特定の業界や大企業だけの話ではありません。社内の知識をAIに使わせたいと考えるあらゆる組織にとって、意味と関係性を機械に伝えるための共通言語をどう整えるか、という共通の宿題を突きつけているのです。
中小企業がいま整えるべきこと
とはいえ、社内の文書を一斉に構造化し直すような大工事は、多くの中小企業にとって現実的ではありません。むしろ優先すべきは、全体を作り直すことではなく、AI活用で最初に触れることになる文書から手を付けることです。
具体的には、次の3点を最初の投資対象として見極めることをおすすめします。
第一に、頻繁にAIに参照させたい文書——顧客対応マニュアルやFAQなど——には、作成日・更新日・担当部署・関連文書へのリンクといった最低限の属性を、本文とは別に明記するルールを作ることです。これだけでもAIが情報の新旧を誤認するリスクは下がります。
第二に、同じテーマについて複数のバージョンが社内に残っている場合は、どれが正であるかを一つに絞り、古いものは「廃止」として明示的にマークすることです。曖昧な複数の答えを残したまま放置することが、AIの誤答を生む大きな要因になります。
第三に、これから新しく導入するナレッジ管理ツールやAI活用サービスを選ぶ際は、「構造化された形式(schema.orgやJSON-LDなど)での出力・入力に対応しているか」を選定基準に加えることです。ツールが標準的な形式を扱える設計になっているかどうかで、後から文書を構造化し直す手戻りをどれだけ避けられるかが変わってきます。
貯めてきた文書を捨てる必要はありません。ただし、それをAI時代の資産として活かすには、書き方そのものに「機械にも伝わる構造」という一手間を加える判断が、今まさに求められています。