こんにちは、デラです。
会社員として働きながら、心のどこかでずっと、小説家にあこがれていました。こんな世界があったら面白い。この人を主人公にしたら、どんな話になるだろう。物語を思い浮かべるのは好きでしたが、その先にある「読んでもらえる一冊にする」というところまでは、なかなか想像がつきませんでした。
そんな私が、AIを使いながら『世界をデバッグするシステムエンジニア』という小説を作りました。最終推敲時にまとめた原稿は、空白を除いて約10万5千字。数字だけ見ると、よくそこまで書くことがあったなと思います。実際には、先へ進むのと同じくらい、書いたところに戻っていました。
この記事では、生成AIと企画を章立てに落とし、章ごとの原稿を推敲して、Kindleで一冊にするまでを振り返ります。英語のログを読みやすくする工夫や、長くなった章を分けた理由など、実際に手を入れた箇所も紹介します。
小説の企画 異世界で障害対応をする主人公
もしシステムエンジニアが剣と魔法の世界に迷い込んだら、魔法がうまく働かないとき、最初に何をするだろう。
いつからおかしいのか。毎回起きるのか。誰かが何かを変えたのか。異世界に来ても、目の前に記録が残っていれば、つい読んでしまうんじゃないか。そんな発想が、この小説の出発点です。
主人公の佐伯透は、深夜の障害対応中に異世界へ迷い込みます。剣の腕も魔法の才能もありませんが、彼には世界の裏側で流れるログが見えます。そこで、暴走する魔物や失敗する魔法を前に、観察して、原因を切り分けて、今できることから手をつけていきます。
この設定を考えるうちに、障害を直したあとのことも書きたくなりました。直った仕組みを、明日から誰が見ていくのか。主人公がその場を離れたあと、同じことが起きたらどうするのか。そこまで考える主人公なら、一冊つきあってみたいと思ったんです。
生成AIで小説を書く 企画と章立ての進め方
頭の中に面白そうな場面がいくつかあっても、その間をつなぐのは難しいものでした。次の場面に進んでほしいからといって、登場人物が都合よく動いてくれるわけではありません。書いてみると、どうしてこの人が主人公を信じるのか、どうして今それを決めるのかと、考えていなかったことが出てきます。
AIが身近になって変わったのは、そんな途中の状態でも、まず言葉にして検討できるようになったことです。企画を章立てに落とし、世界の仕組みや登場人物の設定を別に整理する。原稿は章ごとに扱い、読み返す段階では一冊につなぐ。作業を分けると、次に何を考えるかが見えてきました。
AIとの推敲でも、原稿全体を一度に「もっと面白く」と考えるより、問いを小さくすると判断しやすくなります。この場面の透は、何を根拠にそう判断できるのか。ここで出した情報を、後ろの章でも同じ意味で使っているか。問いが具体的になると、読み返す場所も、直す範囲も見えてきます。
それでも、文章として自然に読めることと、この小説の中でその人物がそう動くことには、距離があります。透が便利な能力で一気に解決できれば展開は早い。けれど、それで場面を通すたびに、観察して一つずつ原因を絞っていく、この主人公の面白さが薄くなる。どの案を残すか決めるときには、最初にこの人の何を書きたかったかに何度も戻りました。
AIとの推敲 英語ログの説明をどこまで入れるか
推敲で特に手がかかったのが、英語のログです。ログは、透がこの世界をどう見ているかを読者にも見せられる、大事な演出です。一方、英語やプログラムに慣れていない人が、そこでいちいち立ち止まるようでは、物語が先へ進みません。
説明を増やすと意味は伝わります。でも、危険が迫る場面でログの用語解説が続いたら、今度は場面の緊張が途切れてしまう。この調整には、どこまで本文で伝えるかを決める必要がありました。
そこで、冒頭では透が最初のログをその場で読み解くようにしました。その先では、誰が困っていて、何が危険で、透が次にどう動くのかを、短い地の文や会話で受ける。用語を詳しく知りたいときのために、巻末には解説を置きました。
たとえば権限が足りないことを知らせるログなら、英語の意味をその場で全部覚えなくても、「透の権限では今この操作ができない」とわかれば、次の行動についていけます。AIと文章を見直しながら、説明を足すたびに、これは読者が今知りたいことだろうか、と考えました。
約10万字の原稿を通して読む 章構成と伏線の見直し
終章の推敲には、別の難しさがありました。場面ごとに読むと収まりのいい締めくくりでも、続けて読むと、「世界はこういうものだ」と語るような文が何度も出てくる。制作メモにも、抽象的な結論が幕間の末尾に集中していたことが残っています。
そこで、いくつかの場面では、担当者同士の会話や手順書、椅子や茶菓子といった具体的なものに、場面の終わりを預けました。世界を直したあとの話なら、立派な結論を言うより、誰かが次の担当者のために手順を残す場面のほうが、その先も暮らしが続いていく感じが出ます。そういう箇所では、せっかく整えた一文にも手を入れました。
章の切り方も見直しました。後日談を足していくうちに、第5章が2万8千字を超えていました。どれも書きたかった場面ですが、山場を越えたあとも同じ章が続くと、読み終える場所が見えにくくなる。そこで、引き継ぎやその後の日常を扱う場面を「終章 保守担当の朝」に分けました。章ごとに作っていたときには気づきにくかった、一冊としての息継ぎです。
最後には伏線も一覧にしました。どこで出したか、この巻のどこで回収したか、次の巻へ持ち越すものは何か。気持ちよく書けた場面をまた開いて、別の章とのつながりを確認する。地味ですが、頭の中でつながっている話を、初めて読む人にも同じようにたどってもらうには、必要な作業でした。
会社員を続けながらKindle出版までたどり着いて
AIが身近になったことで、会社員としての日々の中にも、小説を書き進める入口ができました。設定を一つ言葉にする。ひと場面を読み返す。昨日足した説明を今日は短くする。そうやって作業を続けていたら、いつか書きたいと思っていた話が、誰かに読んでもらえる一冊になりました。
小説家にあこがれていた頃は、本ができた瞬間のことばかり想像していました。今振り返ると、印象に残っているのはむしろ、どうしても気になる箇所を開き直して、やっと「この人ならこう言う」と思えるところまでたどり着いた時間です。あのあこがれの中に、自分はこういう時間も欲しかったんだと思います。
異世界に放り出されたシステムエンジニアが、どうやって世界の不具合に向き合うのか。気になった方に、手に取っていただけたらうれしいです。
『世界をデバッグするシステムエンジニア』のKindle版
コメント