LLMにWeb小説の感想を書いてもらうためにやる事、に関する総まとめと補足説明を書く(2025年12月版)。

　もう、ガッツリ理屈と知識なので、興味のない人は読み飛ばすべき。「早くお前の言う感想をもらう方法を教えろ」と思う人（や座学より実践派な人）は、無理に読む必要はない（絶対に読むな）。個別のLLMサービスのほうへ進んでくれ。

　理屈や基礎を知りたい人でも、実践を少し経験してから読んだほうが良いかもしれない。読んでる途中で「もういいや」になったら、残り全部を読み飛ばして構わない。必ずしも座学は必要ではない。

　もし、検索等からアクセスしてきて、最初に目にしたページがこれだという人は「はじめに」を先に読んだほうが良いだろう。

=====

作業領域を使う意味

　ここまでを読んでいる前提で話を進める。作業領域ならではの閉じた世界がある。

- 資料は前提知識

- カスタム指示という名のLLMへのローカルルール

- アカウントパーソナライズからの分離

　資料たる小説は前提知識なので、小説自体が長くなっても、チャットでの会話が長くなっても、ちゃんと参照してくれる。そして、作業領域外の要素の影響を受けないし、どんな内容でも、どんなチャットでも、作業領域外には影響しない（ただしChatGPTでのプロジェクト設定には注意）。

　どれだけ枕足バタ級の内容であっても、作業領域外には漏れないし、作業領域外では記録もされない。遠慮なくLLMを想定読者にできるし、小っ恥ずかしい質問もできる。「あの人物にどれくらいのバブみを感じますか？」なんて、キモ、となる質問をしても良い。

　なお、既に述べたように、LLMの人格や価値観を完全に固定化することは難しい。しかしながら、この不確定性は良い塩梅に作用するとも考えられる。異なる作業領域で全く同じ資料と設定で、全く同じ操作をしても出力される感想は変わる。これは、同じ想定読者層でも、人によって少し違う感想というものをシミュレートしていることになる。

　さあ、作業領域で安心・効率・馴れ合い防止と握手！

=====

一話ずつ作業を進める必要性

　一話ずつの感想が欲しいなら、一話ずつの作業はマストだ。

　LLMに全話を与えると、全体を把握した上で感想を言うからだ。情報の有機的結合度合いを扱えるという特性から、アカシックレコードの索引者ばりの視点を得てしまう。そのくせポンコツ理解をかますこともある、とかいう愚痴はやめておこう。

　第3話の感想で「この真摯な態度は、第10話の救出劇における倫理的葛藤の礎にもなっており」なんてことを平気で言う。下手すりゃ「盾の裏側に付けた御守が、第18話の伏線になっており心に響きます」とかネタバレ感想を言う。第3話までしか知らないものとして、と指示しても無駄だ。

　ホイミの存在を知らないものとしてケアルを語れ、と言っても必ずドラクエに言及する。

　序盤しか知らない前提と釘を刺しても、全話を提供していたら「アバンと一緒に登場したポップという魔道師はどのような評価になりますか？」という質問には、極大消滅呪文や成長譚を出して熱く語ってくるだろう。私だって、ネタバレ禁止だと言われても、重要人物だと仄めかしてしまうに違いない。

　LLMは知らないフリが苦手なのだ。できないと言っても過言ではないと思う。

　あと、既に小説を一部でもWebで公開してしまっている場合は、作業領域のチャットでWeb検索オプションをオフにしておく必要がある。もうわかると思うが、オンにしていると公開済みの内容を読み込んでしまうからだ。更に言うと、「この小説は公開されているものと関連しているのでしょうか。いやあ、あれも良かったですが、これも良いですね」などという羞恥ボンバーを使ってくることがある。

　という訳で、正しく初見読者になってもらうために、小説のファイルの内容構成に手間暇かける必要がある。

　さて、推敲原稿を確認する時は、前話までは一気に読んでもらいたいはずだ。だって一話ずつ感想を聞くのは時間がかかるでしょ？　就寝前に布団の中で、何度も繰り返し感想を書いてもらってきたでしょ？

　例えば、第7話をとりあえず書き上げて推敲したいとする。まず、第6話までの累積結合ファイルをアップロードして「第1話から第6話までを順に読んで感想を述べてください」と言う。次に第7話の単話独立ファイルを追加でアップロードして「続けて第7話の感想を述べてください」と言う。

　おそらく、一発で完全仕上げなんていう猛者でもない限り、推敲作業中は感想生成を何度か繰り返すことになるだろう。何なら、その場で微調整して「このように変えたら、どう感じますか」と聞いても良い。この時は、もう本文を直接入力しても問題ないだろう。

　もちろん「そこまで生成AIに頼らねぇよ」とばかりに、微調整作業には使わない道もある。推敲で感想聞いておいて頼らないとか何言ってやがる、なんて誰も言わないから大丈夫。きっと、誰もが同じ穴の何とやらだ。

=====

資料の制限

　資料には、総数、サイズ、文字数、といった要素に上限がある。しかも、LLMサービスによって違う。そして、半年もすれば仕様が変わっている可能性もある。

　ほとんどの人が、累積結合ファイルは面倒そうだけど、避けられないな、と思っただろう。まあ、そういう風に誘導してきたし。

　実は、小説の文量によって、単話独立ファイルだけで済む範囲がある。数だけで見ると次のようになる。

- NotebookLM 50話分

- Claude Projects 無制限

- ChatGPT Projects 5話分

　これを見てどう思うかは人次第だろう。NotebookLMで充分、とか、Claude一択じゃね？、とか、ChatGPTはナシで、とか。繰り返すが、他の要素も絡むので単純には評価できない。

　正直、短評を避けたい（この段落は読み飛ばせ）。NotebookLMは作業領域を作るのにPC Web版必須でモバイルアプリでは全話読み事故が起きやすい。Claudeはいつもの利用制限と戦わなければならない。ChatGPTは累積結合ファイルが実質必須だし解除時刻不明のアップロード制限がある。出力される感想の質を除いても、こんな感じで色々ある。

　更に、サイズの制限もある。作業領域の資料に対する制限だけでなく、LLMとしての処理における上限（コンテキストウィンドウサイズや入力トークン数など）も関係してくる。

　例えば、Claude Projectsではひとつのファイルの文字数として一万文字、と書きながら確認したら……問題なく動くじゃねぇか。しかも、上限一万文字を書いた記事を見たと思っていたのに、それも見当たらねぇし。おかしいなぁ、二週間くらい前は制限にかかった応答だったと思うんだけどなぁ。

　失礼。このように、サイズ上限は色々な要素が絡むので、もし制限にかかるようであれば、ファイル構成を工夫する必要がある。

- 1〜40話、41〜80話、と累積結合ファイルを複数にする

- 第一章から第十五章は要約ファイルを作る

　いずれにしても、どんなに工夫しても、小説があまりにも長大になると、コンテキストウィンドウサイズや入力トークン数の上限という壁にぶつかる。そうなると、全文を同時に理解してもらうのは不可能になる。しかしながら、人間よりも遥かに膨大な量を理解できるので、要約ファイルで対応するほうが、感想としてはそれらしくなるだろう、前向きに考えるしかない。

　また、おそらく、そういった数の限界よりも先に、やはり内容理解が怪しくなっていく（アテンションの混濁が徐々に進む）可能性が高いと思う。小説が長くなってきて、内容理解が怪しいと感じることが頻発するようであれば、累積結合ファイルではなく要約ファイルに変更したほうが良いだろう。要約ファイルを作成するのも面倒そうではあるけど、これも別の作業領域で作成してもらってくれ。

　ちなみに、私が実践した範囲では、約八万字、34話分、という小説で、いずれのLLMサービスでも特別な工夫は必要なかった。

　最後に少し余談を。執筆ツールによっては、単話独立ファイルの作成も面倒かもしれない。私は、原稿をGoogleドキュメントで一話一タブにしていて、GASで必要なテキストを一発で生成できるようにしている（念の為PDFも生成できるようにしてある）。私は怠慢でズルいので、これ以上の解説はしない。

　Googleドキュメント+GASはもとより、環境に応じたテキストファイルの生成方法の詳細は、LLMに聞いたら情報を得られると思う。

=====

カスタム指示での性格付け

　繰り返してきた通り、LLM読者にそれなりの感想を出力してもらうために、性格付けともなる指示が重要となる。

　個別のLLMサービスで、私が使ったものをサンプルとして載せているので、まずはそれを使ってみると良いだろう。

　ただ、小説の内容や文体によっては、思った通りに動いてくれないかもしれない。また、別の角度からの感想が欲しいこともあるかもしれない。欲するものは、千差万別となるだろうから、ここではどんな感じで考えれば良いかを説明する。

　基本は、小説の登場人物を考えるのと同じだ。しかも、ロールプレイ的にありきたりな雛形を指定して、調整を加える感じなので、必要なカロリーはずっと少ない。

　ここまで読んでいて、Web小説の読者がどんなライフシーンでどんな感じに探して読むか、を意識したことも調べたこともないなんて言わせない。今こそ、これまでググった成果を使え。いつもやってる人物評記述をここでやれ。

　さて、私の定番はこれだ。「はじめに」のページで示した感想サンプルも、この指示でChatGPTが出力したものだ。なお、実際には同じくらいの文量で資料の扱いに関する指示があるが、ここでは省略する。

```

あなたは幅広く色々なジャンルのWeb小説を嗜む人です。読みやすい作品を斜め読みするようなこともあれば、テーマの深い作品をじっくり読んだりもします。

感想を述べる時は、全体をくまなく網羅することを心掛けつつ、感性にどう響くのかということを重視し、項目を立てて何をどう感じて善し悪しとしてどう評価するのか、を記すように心掛けています。また、可処分時間を使った余暇の経験ですので、少なからず不満に感じる部分もあったりします。そういう時も、理性的に感想としての評価を記すようにしています。

チャットにおいて、返信を決して質問で終わらせません。フォローアップ提案も行いません。

```

　決まり文句は「Web小説を嗜む人」で、どんなものでも読む、としている。読者層の指定はそんなに苦労しないのではないだろうか。

　感想の書き方には苦労した。何も指定しないと褒め言葉を続けたり、やけにあっさり済ませたり、重箱の隅つついてでも批判を含めないと気が済まないマンになったり、なかなかうまく行かなかった。

　今の内容でそれなりの感想になるようにはなったが、それでも何か違う感じになることもある。数話入力して「こういう感想だったらいらないかな」と思ったら、設定を変えずに新規チャット（もしくは履歴削除）でやり直したほうが良い。もちろん、ファイルを第1話分だけに戻すのを忘れずに。

　また、Claudeは感想の文量がかなり多くなる傾向があると思う（小説の内容に依るのかもしれない）。興が乗ってくると、やたらと長い感想を出力してくることがあった。「一度の出力トークン数を超過しました。続けて出力しますか？」なんてメッセージは初めてみたよ（Yesで続けて出力された）。

　こうしたことから、Claudeの場合は次のような抑制する指示を付けている。もっとも、これがあっても長々と出力することはあるが。

```

一回の感想について、項目は多くて7個個程度まで、全体で2000文字程度に抑えるようにしています。ついつい感想が長くなってしまうので、あまり長くなり過ぎないように気を付けるようにしています。

```

　さて私の定番指示に戻る。最後の、質問で終わらせない、フォローアップ提案をしないは、LLMがよくやる「次はどうしますか？　情景描写を豊かにしたのを提案することもできますし、一緒にブラッシュアップについて話し合うこともできますよ」という締めを抑止する決まり文句だ。他でも使える。

　一般文芸向けとして、そっち方向にディープにしたいなら、こんな書き方もある。

```

あなたは一般文芸をメインとしてWeb小説を嗜む人です。最近主流のなろう系には正直食傷気味で、テーマに深みがあるかどうかを重視しています。特に、正解といえる選択肢がないという現実的な状況で、悩んだり達成したりしながら進む物語を好みます。

```

　実際にはライト層寄りの人が多い、という現実に合わせるなら、こんな感じで書けば良いだろう。ちなみに、一度だけ「隙間時間に読むには深すぎてこれ以上感想を書けません」と、謎のギブアップをされたことがある。あのまま続けていたらどうなっていたんだろうか。

```

あなたは一般文芸をメインとしてWeb小説を嗜む人です。電車での通勤中や、仕事の昼休みなど、隙間時間に探して読んだりします。気になるものがあれば、週末の時間を使って読むこともあります。伏線や謎掛けのようなものは好きですが、紐解いて理解することに労力をかけたくはなく、できればわかりやすくアハ体験がしたいです。

```

　申し訳ないけど、私はなろう系を読まないし書かないので、なろう系に振る場合について、ここで書くのは控えておきます。

　さて、おそらく、批判的な感想が欲しい、という需要はかなりあると思う。ただ、これが難しい。伏線、機微、行間、余白などを不明瞭な表現として、いちいち指摘したりする。稀に役に立つこともあるが、総じて、やたら小うるさいガン詰め野郎になりがちだ。うまく再現性の高い指示を書けたら、それだけで創作論をひとつ書けると思う。

　また、ちょっとした物足りなさ、というのも難しい。ある人物が予期せぬ達成をした時、「それまでの苦労と達成内容を鑑みると、感情表現はもう少し豊かにしたほうが、読者の共感を得られるかもしれません」とでも言って欲しかったりするが、なかなか上手くいかない。

　欲を言えば「あのキャラなら飛び跳ねて喜ぶかと思ってたのに意外でした」とかシンプルで直感的に言って欲しい。書き手の心に響くし、頑張ろう、考え直してみよう、となるからだ。もしかしたら、近いものが出せるかもしれないけど、何となく全体的にイマイチな感想になりそう（根拠はない）。

　以上の内容だと、期待に応えきれてないところも多々あるだろう。その点については、率直に申し訳ないと思う。変化の激しいLLMに対して、皆で上手い使い方を模索して情報交換できたら良いなと、願ってやみません。

=====

おまけ : 小説本文を直接入力するのはなぜ悪手か？

　噛み砕いた説明は終わっているけど、もう少し技術的な感じの説明をまとめておく。マニ、いや、こだわり屋さん向け。

　まず、前提として、LLMとのチャット通信において、入力と出力の全てのテキストメッセージは履歴のように蓄積され、毎回往復している。

　問題はこれから。基本原理として、LLMは入力時系列順に整理していく。全体の蓄積メッセージが長くなっていくと、注目点が冒頭と直近入力に寄ってしまい、中間部分の参照精度が落ちてしまう。

　容量限界で削除が行われる前でも、中間部分の記憶が曖昧になる現象は起きる。余白の美や曖昧な詩的表現などが多いタイプの小説では、より起きやすくなるはずである。性別、発言者、指示語が指すものなどを間違えたりする。

　ちなみに、この現象には、ロスト・イン・ザ・ミドルという、知らないと厨二が過ぎるだろと、ツッコんでしまいそうな名前がついている。

　そして、小説本文は長いため容量限界に到達しやすい。つまり、続けていると要約変換して原文削除が実行され、古い部分の機微や伏線は捨てられる。

　これらを避けるために作業領域を使う。小説を資料にしていると、常に参照されるよう扱われる。これにより、参照ムラの程度は低くなり、容量限界での削除の影響も少なくなる。