AI司書を作ろうとして、結局「本の中身を知らないAI」にぶつかった話

「自然が美しい絵本を探したい」

そう思って、AIを使った絵本検索の仕組みを考えていました。

最近のLLMは、こちらの曖昧な言葉をかなり上手に受け取ってくれます。
「自然が美しい」と言えば、森、海、季節、草花、静けさ、余白、やさしい色合い……といった要素を、なんとなく汲み取ってくれる。

だったら、AI司書のようなものが作れるのではないか。

そんなことを考えました。

普通にLLMへ聞くと、存在しない本が出てくる

最初の問題は、LLMにそのまま本を聞くと、存在しない本を薦めてしまうことがある、という点でした。

たとえば、

「自然が美しい絵本を教えて」

と聞くと、いかにもありそうなタイトルや、もっともらしい著者名を出してくることがあります。
説明文も自然で、「ああ、良さそう」と思ってしまう。

でも、調べてみると存在しない。

これは本探しではかなり致命的です。
本を探している人にとって、「その本が実在するか」は最低条件だからです。

そこでまず考えたのは、LLMに本を直接答えさせるのではなく、外部の書籍データベースと連携することでした。

最初に考えた構成

最初に考えた構成は、かなりシンプルです。

Custom GPT
  ↓
Google Books API
  ↓
実在する本だけを候補として表示

Custom GPT側では、ユーザーの意図を解釈します。

たとえば「自然が美しい絵本」と言われたら、

• 絵本を探している

• 自然がテーマになっている

• 絵や雰囲気の美しさを重視している

• 静かで詩的なものを求めている可能性がある

と解釈する。

そのうえで、Google Books APIに投げる検索クエリを作ります。

たとえば、

絵本 自然
絵本 森
絵本 季節
自然 美しい 絵本

のように複数の検索語に分解して、実在する本を取得する。

そして、LLMはGoogle Books APIから返ってきた本だけを推薦する。
API結果にない本は絶対に出さない。

この構成なら、少なくとも「存在しない本を薦める」問題はかなり抑えられそうでした。

中継APIも検討した

途中で、中継APIを置く案も考えました。

Custom GPT
  ↓
中継API
  ↓
Google Books / openBD / NDL など

中継APIというのは、Custom GPTと書籍APIの間に置く、自分で制御できる処理場所です。

ここで、

• Google Booksの検索結果を整形する

• ISBNを正規化する

• 同じ本の別版をまとめる

• openBDやNDLで書誌情報を補完する

• 絵本っぽくない本を除外する

• APIキーを隠す

といった処理ができます。

最初は「できれば中継APIなしで、Custom GPT ActionsからGoogle Books APIを直接叩けると楽だな」と思っていました。

自分でWebサービスを作ると、チャット画面、ログイン、エラーハンドリング、変な入力への対応など、本題ではない部分が増えます。
それが嫌だったので、なるべくChatGPTの画面をそのまま使い、裏側のAPI連携だけで済ませたかった。

この方針自体は、今でも悪くないと思っています。

ただ、別の問題が見えてきました。

Google Booksの情報だけでは、本の雰囲気がわからない

Google Books APIからは、タイトル、著者、出版社、出版年、ISBN、説明文、カテゴリ、書影などが返ってきます。

存在確認には十分便利です。

でも、実際に見てみると、descriptionがかなり簡潔なことが多い。
本によっては説明文がほとんどなかったり、判断材料として弱かったりする。

ここで気づきました。

自分が探したいのは、単に「自然」という単語が含まれる本ではありませんでした。

探したかったのは、

• 自然の描写が美しい

• 絵に余白がある

• 静かな読後感がある

• 寝る前に読めそう

• 怖がりな子でも大丈夫

• 親が読んでもしみじみする

といった、本の雰囲気そのものです。

でも、そういう情報は、普通の書誌データにはあまり入っていません。

「自然が美しい絵本」を探すには、タイトルや短い説明文だけでは足りない。
絵を見たり、本文のリズムを読んだり、読後感を知ったりする必要があります。

つまり、AIはその絵本を読んでいなかった。

AI司書に必要なのは、会話力だけではなかった

LLMは、ユーザーの意図を把握するのは得意です。

「自然が美しい絵本」と言われたときに、それが単なる自然科学の本ではなく、情緒や絵の雰囲気を求めているのだろう、と推測することはできます。

でも、問題はその次です。

その意図に合う本を選ぶには、各本についての詳しい情報が必要です。

たとえば、1冊ごとにこんなメタデータがあれば、検索はかなりしやすくなります。

{
  "themes": ["自然", "森", "季節", "親子"],
  "visual_mood": ["静か", "やわらかい", "余白が多い"],
  "story_mood": ["穏やか", "安心感", "少し切ない"],
  "age_range": "3-5歳",
  "text_amount": "少なめ",
  "scary_level": 1,
  "bedtime_score": 5,
  "nature_score": 5
}

こういう情報があれば、

「自然が美しくて、寝る前に読める静かな絵本」

という検索にもかなり答えやすくなります。

でも、現実には、多くの本についてこのような詳細データはありません。

Google Booksのような書誌APIは、本が実在するかを確認するには便利です。
ただし、「その本がどんな読後感を持っているか」「絵がどんな雰囲気か」「怖がりな3歳に合うか」までは、十分にはわかりません。

本当に必要だったもの

今回考えてみて、AI司書に必要なのは、LLMそのものというより、各本についての詳細な意味データベースなのだと思いました。

たとえば、

• 書誌情報

• 公式紹介文

• 表紙画像

• 本文の一部

• 読書メモ

• レビュー

• 対象年齢

• 怖さ

• 静けさ

• 文章量

• 絵の雰囲気

• 読み聞かせしやすさ

こうした情報を本ごとに持っていて、それを検索できる状態にする。

そのうえでLLMが、

「この人は、自然科学の本ではなく、静かで美しい絵本を探しているのだな」

と意図を解釈し、データベースから合いそうな本を探す。

この形なら、かなり理想に近づきそうです。

逆に言うと、LLMだけでAI司書を作ろうとすると、どうしても限界があります。
LLMは会話がうまい。
でも、その本を実際に知っているわけではない。

いったん諦めた

というわけで、今回のAI司書づくりはいったん保留にしました。

理由はシンプルで、各本の詳細データが足りないからです。

最初は、Custom GPTとGoogle Books APIをつなげれば、そこそこ良いものができるのではないかと思っていました。

でも、実際には、

「存在する本だけを出す」

ところまではできても、

「その人の曖昧な感覚に合った本を選ぶ」

ところには、もう一段深いデータが必要でした。

特に絵本は、本文だけでなく、絵、余白、色、ページをめくるリズム、親子で読んだときの空気感まで含めて体験ができています。

その情報なしに、「自然が美しい絵本」を選ぶのは難しい。

でも方向性は見えた

ただ、諦めたと言っても、完全に無理だと思ったわけではありません。

むしろ、方向性は少し見えました。

AI司書を作るなら、いきなり巨大な検索サービスを作るより、まずは小さくて濃い絵本データベースを作るのがよさそうです。

たとえば、自分が読んだ絵本を100冊、300冊と登録していく。

そのたびに、

• どんなテーマか

• どんな絵か

• 何歳くらいに合いそうか

• 怖さはどのくらいか

• 寝る前に向いているか

• 親が読んでどう感じるか

をメモしていく。

そこにLLMを使ってタグを付ける。
検索するときには、ユーザーの曖昧な希望をLLMが解釈し、そのタグ付きデータベースから候補を探す。

それなら、Google Booksの短いdescriptionだけに頼るより、ずっと良い選書ができるかもしれません。

結論

今回わかったのは、AI司書の難しさは、AIの会話力ではなく、本のデータの薄さにある、ということでした。

LLMは、こちらの意図をかなり上手に汲み取ってくれます。
でも、その意図に合う本を選ぶには、その本について深く知っている必要があります。

本を読んでいないAIに、本当の意味で本を選ばせるのは難しい。

だから、AI司書を作るなら、まず必要なのは「賢いチャット画面」ではなく、「本ごとの豊かな記憶」なのかもしれません。

今回はいったん諦めました。
でも、もし次にやるなら、AI司書を作るのではなく、まずはAIが読める絵本メモ帳を作るところから始めたいと思います。