otopublic.com

BEHIND

AIチームでブログ小説サイトを設計した(10)—— 調べないと使えない、という話

調べないと使えない、という話

物語の中に「本物の情報」を混ぜようとするとき、一番気をつけなければいけないのは、

AIが「もっともらしい嘘」を生成するリスクだ。


きっかけ:セリフに実在のエピソードを入れようとした

otopublicにはシーさんというキャラクターがいる。

音楽の歴史や文化を語る人で、彼のセリフが届くことで、読者はヒロの隣に座って一緒に「へえ」となる——そういう設計だ。

あるエピソードで、シーさんが実在のアーティストの話をする場面を作ることになった。

ヒロが練習していた曲を歌っているその人が、最初にギターを手に取ったのがいつか、どんなきっかけだったか——

そういう話を、シーさんが自然な語り口で伝える場面だ。

セリフの構造は設計できた。問題は、その中身だった。


問題:AIはもっともらしい嘘をつく

AIは、知らないことを「知らない」とは言わない。

それらしい話を組み立てて返してくる。

「12歳でギターを始めた」「誰かに教わった」——こういった断片的な情報は、

事実をもとにしている可能性もあるし、別の人物や出来事が混ざっている可能性もある。

特定の実在人物に関わる記述は、それが間違っていたとき、その人の名誉に関わる問題になる。

小説の中にフィクションとして書くならまだしも、「事実」として語り手のセリフに混ぜる場合、

裏を取っていない情報は使えない。

そのためにシーさんのセリフには、他のキャラクターより高い事実確認基準が設けられた。

「Geminiリサーチまたは正典で確認済みの内容のみ使う」というルールが、正典ファイルに明記されている。


対応:2つのAIで二重確認した

確認の依頼は2つのAIに出した。CodexとGeminiに、それぞれ独立してリサーチを依頼した。

返ってきた情報は詳細だった。

アーティストの幼少期の音楽体験、きっかけとなった出来事、ギターを習い始めた経緯——

それぞれが複数のソースを参照した形で返ってきた。

二つのAIが一致している項目は、比較的信頼できる。

一方にしか出てこない詳細、または表現に差がある部分は、使わないか、保険を入れて使うかの判断が必要だった。

最終的に整理されたのはこういう基準だ。

– 両AI一致 → 「〜という話があって」で本文に入れる

– 片方のみ・出典不明 → 「〜と言われています」で保険を入れるか、省く

– 年号・固有名詞の具体的な記述 → 特に慎重に扱う

リサーチ結果は references-private/ に格納した。

「一度調べたことを正典として持っておく」ことで、次に同じキャラクターが語る場面でも使い回せる。


結果:セリフに「保険の言い回し」が入った

確認が取れた内容は本文に入った。

ただし、どれも「事実として断言する」形ではなく、「という話があって」「と言われています」という語り口になっている。

これはシーさんのキャラクターとしても自然だった。

知識が豊富で、でも押しつけがましくない——その語り口に、保険の言い回しが溶け込んだ。

「〜という話があって。面白いでしょう」

そう言ってシーさんは黙る。ヒロが自分で受け取る余地が残る。

事実確認のための言い回しが、文体的にも正解だった。


ここまでで分かったこと

調べることは、遅くするためではなく、速くするためにある。

事実確認なしにセリフを書いて、後から誤りが見つかった場合、

修正はそのセリフだけでは済まない。正典ファイル、公開済み記事、関連する設定資料——

全部を見直すことになる。

最初に一度だけ調べて、正典に入れておく。

これが後の作業を速くする。

今日のセッションは、小説のエピソードを書く前に、設計と資料整備に時間をかけた一日だった。

Taylor Swiftのリサーチはその一例だ。

新しいキャラクターの設定を固め、複数エピソードの核を notes.md に書き込み、

公開スケジュールを組み直し——そうした下積みがあるから、執筆本番が速く動ける。

資料は、使うときより先に作る。それだけだ。


この記事はotopublicの制作過程を記録した「裏側」記事です。

物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、

AIへの指示文そのものは、方針により伏せています。

この記事の舞台となった物語

Stories を読む →