なぜ「AIにたくさん読ませる」は間違いなのか？─ 編集者が知るとその後が変わる実験結果

出版界のあらゆる編集者へ捧げます

出版界で今、2つのAIプロジェクトが話題になっている。

マガジンハウスの「もしもし、ブルータス。」
──45年分・全1040号のバックナンバーをスキャンしてGoogle Geminiに学習させた対話型AI。Ginza Sony Parkに置かれた電話ボックスで、受話器を取ると「ブルータス」と会話ができるというプロジェクトだ。

ダイヤモンド社の「ちきりんAI on LINE」
──ベストセラー4冊、ブログ全文、Xの投稿、Voicyでの発言を読み込ませて、ちきりんのキャラクターを再現した有償チャットボット。2026年1月にリリースされ、大きな反響を呼んだ。

どちらも出版社が主導している。
どちらも「大量のコンテンツを読み込ませた」ことを最大の売りにしている。

これを見て、多くの編集者はこう思ったはずだ。

「やっぱり、量が大事なんだ」と。

残念だが、それは間違っている。
そしてこの間違いを放置するとこの重大なミスは「何を引き起こすか？」
その答えを書き残しておく。

※この話しの経緯は前回noteに書きました。

※本記事は筆者個人の見解であり、所属組織の公式見解を代表するものではありません。

０：サクッと動画で

1：なぜ編集者は「量＝正解」と信じてしまうのか？

編集者の仕事は「大量に読んで、選んで、削る」こと。
書店に並ぶ本を読み、映画を観て、街を歩く。
大量のインプットから直感が磨かれ、企画が育まれる。
インプットが無ければアウトプットは生まれない。

だから「AIにも大量に読ませれば賢くなる」と思うのは自然な発想だ。
例えば、45年分のブルータスを全部食わせれば、ブルータスの「人格」が再現されるはずだ、と。
ちきりんの著作を沢山読ませれば、ちきりんの「思考」が再現されるはずだ、と。

しかしこの発想は、人間の学習モデルをAIに当てはめている。
ここが根本的な間違いだ。

AIは「読んで」いない。「参照して」いるだけだ。

今のAI（特にRAG＝検索拡張生成と呼ばれる仕組み）は、全文を「理解」しているのではない。ユーザーの質問に対して、データベースの中から関連する断片を「検索」して、それを「参照」して、回答を生成している。

つまりAIがやっているのは「読書」ではなく「索引引き」に近い。

このとき、全文テキストに含まれる物語的な修飾、文脈依存の表現、曖昧な代名詞──人間の読者にとっては味わい深い要素──は、機械にとってはノイズでしかない。

「検索」・「参照」の精度を上げたいときに、本文を丸ごとコピーして索引欄に貼り付ける編集者はいないだろう。しかしAIに対しては、まさにそれをやっている。

編集者は、構造化データに関してどこまで理解しているだろうか？

誤解しないでほしい。

「もしもし、ブルータス。」も「ちきりんAI」も、体験は素晴らしい。 電話ボックスでブルータスと話せるという企画のセンスは見事だし、ちきりんっぽいやりとりをAIで体験できるのは新しいユーザー体験である事に間違いない。

問題は、これを見た出版業界が「大量のコンテンツをAIに食わせるのが正解だ」と思い込むこと。ここが危険なのだ。

その理由は３つある。（noteに書いてきた）

①：海外では巨額でコンテンツ・ライセンス契約が行われている。しかも紙の書籍はAI企業にパクられまくっている。その事を知っている日本の作家・著者は限りなく少ない。

②：アンソロピックは紙の書籍を200万冊をスキャンしてた。しかも海賊版からデータを買ってた。ここに日本の紙の書籍は大量に入っていた。

③：書籍・記事は全文をAIに読ませなくても内容を理解させる事が可能である。むしろ適切な構造化データを作らず、全文を読み込ませる方がAIにはゴミデータにしか見えない。

詳細を順を追って説明したい。
お付き合い頂きたい。

2. 実験結果：構造化データは全文の11.1倍

言語処理学会・第32回年次大会（NLP2026）で論文を発表した。

婦人公論.jpの連載『嫉妬マニア』（斉藤ナミ・著）の記事を構造化データにして「全文テキストをそのまま食わせた場合」と「構造化されたメタデータを食わせた場合」で、AIの検索精度を比較する実験を行った。

RAG時代の言語資源設計原理─構造化テキストによる「参照可能性」の実証

GitHub：shitto-mania-dic
HuggingFace：samuraijun/shitto-mania-dic

結果は11.1倍。

構造化データは、全文テキストの11.1倍正確に情報を引き当てた。 追加で行った実験手法（Dense Retrieval）でも同様の傾向が確認された。

これはあらゆるジャンルのコンテンツに当てはまる原理である。

編集者にわかる言葉で言い換えるとこうなる。

例１）企画会議のシーン
新人編集者が企画会議で「参考資料です」と100ページの資料をドンと置く。誰も読まない。ベテランはA4一枚に要点を絞って持ってくる。AIへ全文食べさせるのは、新人がやっていることと同じだ。

例２）書棚の比喩
45年分の雑誌を倉庫にバラバラに積み上げて「この中から探して」と言うのがAIに全文食べさせること。
各号ごとにテーマ・キーワード・掲載店名のカードを作って、整理棚に並べてあるのが、構造化データをAIに食べさせるための下準備である。

どっちが、解りやすいか。

3. なぜ「削る」方が精度が上がるのか？
─ 編集者の直感は正しい。しかし「AIが読者だったら？」ココが理解されているだろうか？

「テキストを削ることで本質が残る」。 この直感は正しい。
編集者が毎日やっている作業と本質は同じだ。

冗長な原稿を削り、構造を整え、読者が必要な情報にたどり着くようにする。 ある意味で、それは編集の核心だろう。

しかし、ここに罠がある。

編集者が「削る」のは、人間の読者に向けてだ。
何が美しい文章か。
何が読者の心を掴むか。
その判断基準は「人間の認知」を基準としている。

AIに対して「削る」には、まったく別の判断基準が必要だ。
TF-IDFスコアリング
Dense Retrievalの埋め込み
チャンクサイズの設計
これらは編集の直感ではない。

では、逆にエンジニアならどうか？
アルゴリズムには詳しい。
しかしコンテンツのどの側面が構造化に値するのか。
どのメタデータ項目が読者の「問い」に対応するのか。
これはコンテンツの現場にいなければわからない。

つまり、両方の視点が要る。

私はこれを「AI・ナレッジエンジニアリング」と呼んでいる。

AI・ナレッジエンジニアの仕事とは・・・
「テキストの手触り感覚」と「AIの仕組み」の両方を理解した上で、「言語資源」（データ）を設計する仕事である。

この原理を「参照可能性（referenceability）」と名づけた。
AIが情報を参照しやすい形に言語資源を設計すること。
この設計には、編集者の目とエンジニアの目の両方が必要なのだ。

4：AIを学ばない編集者が「間違ったAI編集」をする

いま出版業界で、起きつつあることを整理する。

このシナリオの最も危険な点は、上記④を過去の基準で考えること。

AIが悪いのではない。
食わせ方が間違っている。
そもそもAIの良さを理解していない。

ついでに言うと、もうひとつ同じくらいヤバいシナリオがある。

これが最悪のシナリオだ。
正しい方向に向かったのに、やり方が間違っているせいで、正しい方向そのものが無いものになる。本来のAIの良さや、性能を引き出す事をしない。
それは、最後に伝える重要な問題に繋がる。
もう少しなので、最後までお付き合い頂きたい。

おわりに ─「AIの教科書」を作れるのは誰か？

AIの中身を作るのはエンジニアの仕事だ。
コンテンツを作るのは編集者の仕事だ。

しかし「AIに何を食わせ、どう構造化するか」は、どちらか一方にはできない。

編集者の手触り感覚と、AIの検索の仕組み。 この2つの目を持った人間が、これからの出版には必要になりつつある。

それをAIナレッジエンジニアと呼んでいる。

AIに全文をダラダラ読ませるよりも、AIの教科書を作る。 その教科書は、人間が何十年もかけて蓄積してきた現場の知恵を、AIが参照しやすい形に翻訳したものだ。

この翻訳ができる人間が、出版の現場にはまだほとんどいない。

だから私は論文を書いた。 11.1倍という実験結果を引っさげて、言語処理学会の場で発表した。

量が質ではない。
質は純度である。

テキストを「削る」ほうが、AIの検索・参照精度は上がるのだ。

ということは、AIに書籍や記事の全文を読ませなくて良いのだ。
つまり「AIに書籍や記事の全文を読ませなくても」作品を、AIに理解してもらえる事につながる。

第30条の4
AIへの著作権問題は根深い。

この課題をクリアできる。
前述のAI企業に丸パクリされていた事も対応できるようになる。

だから、これを読んだ編集者は、（優れた）構造化データを作れば「AIに書籍や記事の全文を読ませなくてもいい」のだと、芥川賞作家・直木賞作家に伝えてほしい。

解決策はココにあるのだと。

言語処理学会・第32回年次大会（NLP2026）論文：
RAG時代の言語資源設計原理─構造化テキストによる「参照可能性」の実証

GitHub：shitto-mania-dic
HuggingFace：samuraijun/shitto-mania-dic

#AI
#生成AI
#RAG
#出版
#編集者
#構造化データ
#言語資源
#自然言語処理
#NLP2026
#参照可能性