59歳エンジニアでもない私が言語処理学会に論文を出したハナシ─現場ノウハウをAIに活かす方法

同世代のnoteユーザーの方々へ捧げます

言語処理学会・第32回年次大会（NLP2026）に論文を出しました。
今年60歳。還暦を迎えます。
私は典型的な文系（マーケ系）であり、エンジニアでなければAI開発者でもありません。プログラミングを本格的に学んだこともない。論文を書いたのもこれが人生で初めてです。なぜこんなことが起きたのか。そして同世代のビジネスマンにとって、この経験がなぜ他人事ではないのか。順を追って書き残しておこうと思います。

言語処理学会・第32回年次大会（NLP2026）

言語資源・アノテーションと評価
2026年3月11日（水）9:30-11:00 Q会場
https://anlp.jp/proceedings/annual_meeting/2026/#Q5

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

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

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

1：出発点は「論文を書こう」ではなかった

最初に断っておくと、論文を書くために動き出したわけではありません。

出発点は、斎藤ナミさんの『嫉妬マニア』シリーズ。2年以上の時間をかけてお声がけして始まった連載で、もう１年になります。

普段使っている検索とAIは、もはや一体化している。であれば、嫉妬にまつわるエピソードが溢れる連載コンテンツを「AIに読ませたらどうなるか」という視点で考えていました。昨年の春で、嫉妬の日（4月10日）を過ぎた頃です。

出版に関わる人間として日々考えるのは「新規・読者開発をどうするか？」という「問い」です。

これほどシンプルで難しい問題はありません。
しかしこの考え方は出版業界では一般的になっていない。
あらゆる意味でとても古い業界だからです。

原稿をそのままデジタル化しても、検索にはほとんど引っかからない。RAG（検索拡張生成）が主流になりつつある中で、SEO（検索対応）延長の「AI対応」ではなく、「AIそのものに教え込む」必要があるのではないか？

で。こんな仮説を立てました。
▼
SEO：「嫉妬と言えば斉藤ナミ」
AI：「その嫉妬を説明するなら斉藤ナミの記事を引用すると…」

というように「AIが参考にする嫉妬そのものを教え込む」
つまり
「AIの教科書をつくる」方がいいのではないか？

そこで、サンプル文章にメタデータ（構造化する項目）の表を作るという作業を始めようと思ったのです。

「嫉妬AI辞書」

と呼ぶことにしました。

とはいえ、AIの中味（LLMとRAG。この2つは違う）をぜんぜん知らない。だから論文を読みまくりました。英語だし難しくて解らない。AIに翻訳して「高校生レベルに解説して」と頼んで、疑問を解いていきました。
これに2ヶ月ほどかかった。

そうするとAI開発の歴史を理解していない事がわかった。
というわけで、AIの歴史を論文で遡っていきました。
これに1ヶ月半ほどかかった。
このあとサムアルトマンの本を読んで理解が倍増しました。
私なりの「AIの相場観」が生まれました。

４ヶ月もすると、だんだん「AIに何を学ばせるべきか」解ってきた。

・嫉妬の発火点（なぜ嫉妬したのか？）
・誰に嫉妬しているのか？（方向性）
・感情の強度や文脈（構造化データ）

ひとつひとつのエピソードを、人間が読んで分類し、構造化していく。
最後の勝負は、地味な手作業が必要なことが解った。

これは業務ではなく、アイデアの延長でした。
だから作業は深夜と早朝です。
少なくとも最初はそうでした。
だけど、４ヶ月頑張っていると「重要な鍵」が見えてくるものがありました。

大事なのは「問い」である

AIの奴隷になるのではなく、AIに教える方法は無いか？

そのために、そのためにこそAIを使ったのです。
私は「AIの多頭使い」と呼んでますが、「自分の研究室スタッフを持つ」ということです。

2：「全文読むより、構造化データのほうが検索精度が高い」─11.1倍の衝撃

作業を進めるうちに、ある仮説が生まれました。
ほとんど閃きに近い。いや。単なる偶然かもしれない。

「RAGで検索するとき、原文テキストをそのまま食わせるより、構造化データのほうが精度が高いのではないか？」

これを検証するために実験を行いました。
でも、その実験の準備が大変だった。
この実験はPythonを使うのですが。。
しかしPythonなんて使ったことがなかった。
だからAIに使い方を教えてもらったのです。
幸いなことにGoogle ColabというクラウドのPythonがあります。
使い方を横でGeminiが丁寧に教えてくれます。
結果は別のAIで確認します。
そうやってクリアしていきました。

結果は・・・

11.1倍。
構造化データは全文テキストの11.1倍も正確に情報を引き当てた。

他の実験方法も試してみました。
同じような結果が出ました。

この数字を見たとき「なんじゃ？こりゃ」
「これは論文を出さねばならない」と思いました。

なぜならこのハナシを、出版界隈で話しても「は？何いってんの？オマエ」状態だったからです。

まぁ。仕事を四半世紀もしていれば、解ると思うけど、組織とはそんなものです。ココで叫んでも怒っても意味がありません。半世紀以上生きていて解るのは、組織には「コンセンサス重視」という病があるのです。その「病い」に自分が罹患しないことが「自分らしく生きるコツ」です。

「AIに全文をダラダラ読ませるよりも、短文を読ませるほうがいい」

これは、AIに書籍の全文を食べさせなくても良いという事。

でも出版業界にこのこと訴えても誰も理解できません。
そんなものです。

たとえば、直感的には、「ブルータスを45年分読ませたAIです」とか「ちきりんの本を4冊全部読み込ませました」とか。データ量が多いほど効果が高い気がするでしょ？でも違ったのですよ。

実験結果は違った。この事を誰に伝えるか？
だから論文を書きました。

でも、最初は本当か自身が持てませんでした。
だから、いろんな論文を調べました。
何度も、何度も確認をしました。
で。まだ誰も書いて無かった。
まぁニッチなハナシですから。

これは、学術的に言えば「言語資源の設計原理に関する証明」だったのです。
この事を殆どの出版関係者は知らない。
それでいいのです。
だから論文を書きました。
これをきっかけに、理解は広がるからです。

3. 何を証明したのか？
─「参照可能性」という新しい設計原理

論文の核心を説明します。

RAG時代のAIは、外部のデータベースから情報を「検索」して、それを元に回答を生成します。このとき、データベース側の情報がどう整理されているかで、AIの回答精度が決まる。

従来の発想では
「テキストは多いほうがいい」
「原文をそのまま入れればいい」
と考えられていました。

しかし実験は逆の結果を示した。

「量」は「質」ではない。
「質」は「純度」である。

テキストを「削る」ほうが、検索精度は上がるのです。

なぜか？

・全文テキストにはノイズ（雑音）が多い。
・物語的な修飾、文脈依存の表現、曖昧な代名詞。

つまり人間にとって理解できるこれらの要素は、機械（AI）にとっては検索精度を下げる雑音でしかないのです。

一方、短文（構造化メタデータ）は、「この嫉妬のエピソードは、職場の同僚間で、昇進をきっかけに、妬み２０％と嫉妬８０％で発生した」というように、検索に必要な情報だけを効率的に食べさせます。

この性質を「参照可能性（referenceability）」と名づけました。
※英語で理解しやすい方がいいから

だから、これは嫉妬の感情分析の研究ではないのです。
「AIが情報を参照しやすくするために、言語資源をどう設計すべきか」という、設計原理の提案をしました。

この原理はあらゆるジャンルに適用できる。

職場でのハラスメント防止や離職予防、メンタルヘルス相談の支援サポート、経営者の考え方や価値観をAIに引き継ぐ仕組みづくりなど、幅広い分野に応用できます。

「嫉妬」は特殊なテーマに見えるけど、ポイントはそこではありません。本質は、人間の複雑な感情や判断を、AIが正しく探し出せる形へ整理する方法を作り、実験で結果が出たことなのです。これは、目の前の事しか見えてない近視眼的な人には「は？何のこと？」状態にしか見えません。

4. エンジニアではない人間が、なぜ論文を書けたのか？

ここからが、同世代のビジネスパーソンに最も伝えたい部分です。
私がこの論文を書けた理由は3つあります。

第一：「現場の素材」を持っていたこと。
AI開発の研究者は、優れたアルゴリズムや大規模モデルを持っている。しかし、特定ドメインの深い知識と、そこから生まれる質の高いデータは持っていないことが多い。私には原著者の斉藤ナミさんの理解と協力、『嫉妬マニア』という素材と、現場で培った「テキストの手触り感覚」があった。これが資産となりました。

第二：AIを「共同研究者」として使ったこと。
論文執筆のプロセスでは、Claude（Anthropic）とChatGPT（OpenAI）とGemini（Google）を役割分担して使った。

ChatGPT─コード生成、データ処理を任せた。
Claude─論文の構造設計、論証の検証を任せた。
Gemini─人間に解りやすく説明させる。エンジニアでない私の作業を一つづつ丁寧に教えさせた。

論文を「AIに書かせた」のではない。

AIをチームの一員として配置し、それぞれの強みを活かして協力させました。エンジニアでもなく研究室も持たない私にとって、AIは「研究室そのもの」だったのです。

第三：「問い」の立て方が現場視点だったこと。

「RAGで検索精度を上げるにはどうすればいいか」
─この問いは、学術の世界から生まれたものではありません。

「コンテンツをAIにもっと食べてもらうにはどうすればいいか？」という、ビジネス現場から生まれた「問い」でした。

学術研究の世界では、現場発の「問い」は意外なほど存在しません。
そのため研究は「全体的」で「広範な」視点で実験される傾向があります。

研究者が思いつかない「鋭い角度」の「問い」が現場にあることは意外と知られていません。

「現場にこそ頭脳を」

これが、Googleでも実証されている、歴史が教えてくれる現実だと言うことを私は知っていました。そこが論文を書く勇気を与えてくれたのです。

5：もうすぐ引退を迎える同世代のあなたへ
─自分の足元にこそ「油田」がある

59歳の私が言語処理学会で論文発表できるなら、あなたにもできるはず。
これは励ましではなく、構造的な分析なのです。

あらゆる業界に「まだ誰も構造化していないデータ」が眠ってます。
例えば・・・
・不動産なら物件情報の文脈的な価値判断。
・医療なら患者の語りの中にあるパターン。
・製造業なら熟練工の暗黙知。
・飲食なら「おいしい」の裏にある多次元的な評価構造。

あなたのその業界で20年、30年と働いてきた人にしか見えない「油田」があります。

AIは、まさにこの油田を必要としているのです。

大規模言語モデルは一般的な知識は豊富だけど、特定領域の深い「構造化データ」つまり良質なデータが決定的に不足しています。

これは「2026年問題」と言われています。

必要なのは、プログラミングスキルではない。

論文の執筆技術でもない。

自分のノウハウ・データを、AIが参照しやすい形に構造化する「設計力」と『意志』が必要なのです。

これは、長年の現場経験を持つビジネスマンにしかない能力です。
だから難しく考えることはありません。

距離感の測り方、会議の空気の持って行き方、上司の思考様式の変え方、飲み会の上手な持って行き方、AIには出来ない事がまだまだ沢山あるのです。

あなたの能力は、まだ世の中の役に立ちます。

おわりに
─現場知識は学術の言葉に翻訳できる

この経験から得た学びは、「現場の知識を学術へ翻訳可能である」ということです。

長年の仕事で蓄積した直感や判断力は、学術的な文章に変換できる。
数学を文章で表現することができる。
そしてその難しい作業にAIは優秀なスタッフとして使える。

59歳（今年60歳・還暦）
エンジニアでもない私が論文を出せたのは、特別な才能があったからではない。「現場で培った知見」と「AIという新しい道具」の組み合わせが、学術論文という新しい出口を開いたのでした。
あと同時にプログラム・コードを書くという新しい世界が拓けました。

だから、あなたの人生にも、まだ誰も掘り当てていない油田があると思うのです。

最後に

斉藤ナミさんには、連載『嫉妬マニア』の研究利用許諾、全エピソードのラベル確認、メタデータのサンプル確認を通じアノテーション品質確認など多大なるご協力を頂きました。そして株式会社中央公論新社、婦人公論.jp川口編集長にはご理解ご協力を賜りました。改めて感謝します。

言語処理学会・第32回年次大会（NLP2026）

セッション：言語資源・アノテーションと評価
2026年3月11日（水）9:30-11:00 Q会場
https://anlp.jp/proceedings/annual_meeting/2026/#Q5

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

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