こんにちは、デラです。
生成AIを使って小説を作っていると、文章が形になる速さに驚きます。設定を伝えると、場面や会話が出てくる。頭の中でぼんやりしていた物語が、目の前に並んでいきます。
でも、そこから「一冊の本」として読める形にするまでには、想像以上の時間がかかりました。
特に苦労したのが、作中に登場する英語のログの見せ方です。
私が制作した小説『世界をデバッグするシステムエンジニア』では、主人公に、異世界の裏側で動くシステムのログが見えます。ログとは、ざっくり言えば「何が起きたかを記録したメモ」のようなもの。主人公はその記録を読み、世界で起きている問題の原因を探っていきます。
この仕掛けは、物語の面白さの中心にあります。一方で、AIが作った文章を読み返すと、ログの意味や見た目が、技術に詳しくない読者には伝わりにくい。画面にそれらしい英語が並んでいても、読者が「何が起きたのか」をつかめなければ、物語から置いていかれてしまいます。
今回は、このログをどう読者に届けようとしたのか。そして、なぜ推敲にこれほど時間がかかったのかを書いてみます。
AIはログを作ってくれる。でも、読みやすいとは限らない
この作品でログを使いたかったのは、主人公が「世界の不具合」を見つける過程を、読者にも一緒に追ってほしかったからです。
たとえば、巻末の解説には、こんなログが出てきます。
maintenance authority: not found作中では、「保守担当者の権限が見つからない」という意味です。世界の仕組みを直そうにも、必要な権限を持つ担当者が見当たらない。主人公が向き合う問題の一端を示しています。
システムに慣れていれば、英単語から大まかな意味を想像できるかもしれません。でも、小説を読む人が全員、普段からログに触れているわけではありません。
「英語の表示が出た」ことは分かる。でも、それが危険なのか、なぜ主人公が気にしているのかは分からない。そんな状態では、せっかく仕込んだ手がかりも、ただの難しい文字列になってしまいます。
AIは、ログらしい文を出すことはできます。ただ、私が最初に受け取った原稿では、専門外の人が初めて目にしたとき、どこでつまずくかや、本の中でどう見えるかまでは十分に考えられていませんでした。
もちろん、それはAIだけの問題ではありません。どういう読者に届けたいか、どこまで分かってほしいかを、私自身が決めて伝える必要がありました。
見た目を整えるだけでは、意味は伝わらない
ログを読みやすくしようと思うと、まず見た目が気になります。英数字の区切りや表示の長さを整え、周囲の文章と見分けやすくする。
ただ、表示をきれいに並べても、それだけで意味が伝わるわけではありません。
例えば、次は考え方を説明するための例です。実際の原稿の修正前後をそのまま引用したものではありません。
〔permission denied〕
透はログを見つめた。
これだけでは、英語に慣れていない読者は「何が拒否されたのか」が分からないかもしれません。そこで、直後に主人公の判断や行動を置きます。
〔permission denied〕
透は操作を止めた。この扉を開くための権限が、自分にはない。
「permission denied」は、作中では「その操作をする許可がない」という意味です。英語をすべて訳さなくても、主人公が何に困っているかが分かれば、読者は次の行動を追えます。
見た目を整えることと、意味を伝えること。その両方が必要でした。
説明を増やすと、今度は物語が止まってしまう
では、ログが出るたびに丁寧に説明すればいいのか。そうすると、別の問題が出てきます。
危険が迫っている場面で、英単語の意味やシステムの仕組みを長く解説すると、読者の関心が「次に何が起きるか」から離れてしまいます。説明としては親切でも、小説として読む勢いを止めてしまうかもしれません。
逆に、説明を削りすぎると、主人公だけが状況を理解したまま話が進んでしまう。
どこまで言葉にして、どこから先は読者に委ねるのか。このさじ加減が難しかったです。
私が考えたのは、読者にログの単語を全部覚えてもらうことではありません。その場面で大事な、次のことが伝わればよいのではないか、ということでした。
- 誰が、何に困っているのか
- いま何が危ないのか
- 主人公が、何を根拠に次の行動を選んだのか
ログの意味を完璧に理解することよりも、主人公と一緒に状況を追えること。そこを目指して、説明の置き方を見直しました。
本文と巻末に、説明を分けた
作品では、冒頭で透が最初のログをその場で読み解くようにしました。最初に読み方の手がかりを渡し、その後は、必要な意味を短い地の文や会話で受ける。
詳しく知りたい人のためには、巻末に「ログと用語のやさしい解説」を置いています。
たとえば、作中で使う WARN は警告、ERROR は失敗を表す言葉として説明しています。また、permission denied は「その操作をする許可がありません」と紹介しています。
本文では物語を追うために必要なことを伝え、巻末では立ち止まって確認できるようにする。こう分けることで、英語やプログラムに慣れていない人にも読み進めてもらいやすくしたいと考えました。
巻末の解説を読まなければ話が分からない、という形にはしたくありませんでした。知りたい人は確認できる。でも、物語を先へ読みたい人は、そのまま進める。その両方を大切にしたかったんです。
AIが書いた文章を、本にするまでの推敲
推敲では、ログの意味だけを直せば終わり、というわけにもいきませんでした。
ある場面で説明を足せば、別の場面では同じ説明がくどく感じられる。ログを短くすれば読みやすくなる一方、主人公がそこから何を読み取ったのか、根拠が薄くなることもあります。
場面単位では自然でも、章を続けて読むと説明が重なっていたり、表現の調子が似ていたりする。だから、直した場所だけでなく、その前後や、同じ用語が出てくる別の箇所も読み返しました。
AIに相談するときも、原稿全体をまとめて「読みやすくして」と頼むより、確認したいことを小さく分けるほうが判断しやすかったです。
たとえば、「このログの直後、専門知識がない読者は何に困るか」「説明を足すなら、どの一文が場面の流れを止めにくいか」といった具合です。
ただし、提案が自然な文章でも、そのまま採用できるとは限りません。透がその時点で知っていることに合っているか。緊迫した場面の雰囲気を壊していないか。この作品の言葉として違和感はないか。最後は自分で読み、残すかどうかを決めました。
AIが文章を出す時間よりも、それを読み、比べ、作品に合う形に直す時間のほうに、多くの手間がかかりました。
これからAIで小説を書く人に伝えたいこと
生成AIを使うと、書き出す前のハードルは下がります。構成に迷ったときも、別の見方をもらえるのは助かりました。
ただ、文章が出てきた時点で、読者に届く本が完成するわけではありません。
特に、専門用語や独自の設定が多い作品なら、自分にとって当たり前の言葉が、初めて読む人にも伝わるかを確かめる必要があります。説明を増やすだけでなく、どの場面で、どれくらい伝えるかを考えることも大切でした。
もしAIと原稿を作っていて、「文章はできたのに、なぜか読みにくい」と感じたら、まず一場面だけ選んでみてください。読者がその場で知る必要のあることを整理し、説明を足す場所と、思い切って削る場所を考える。そこから見えてくるものがあります。
文章ができた先に、もう一つの作業があった
AIと一緒に小説を作る前は、原稿が最後まで書ければ、本の完成はすぐそこだと思っていました。
実際には、そこから何度も読み返し、「この言葉で伝わるだろうか」と考える時間が待っていました。英語のログ一つを取っても、意味、見た目、説明、物語のテンポがつながっています。
手間はかかりました。でも、その時間があったからこそ、エンジニアではない読者にも、この世界を楽しんでもらうにはどうすればいいかを考えられたと思います。
AIが出した文章を、誰に届けるのか。どこで迷わず読めるようにするのか。そこを考えて手を入れることも、本を作る大切な時間でした。
小説の企画からKindle出版までの全体像は、生成AIで小説を書いてKindle出版するまで｜会社員の制作記にまとめています。
作品が気になった方は、『世界をデバッグするシステムエンジニア』のKindle版もご覧ください。
コメント