AIチームでブログ小説サイトを設計した（3）―― 最初の一話ができるまで
設計の話（Part 1）と、実装の話（Part 2）を経て、いよいよ最初の一話を書いた。
このシリーズ第3回は、「書く」プロセスそのものの記録だ。
準備：設定を「決める」前の問い
最初に手が止まったのは、意外なところだった。「主人公は何の楽器を弾くのか」という点だ。
AIに案を出させると、複数の選択肢がそれなりの理由つきで並ぶ。エレキ、アコギ、ベース……。
でも、この段階で人間がやることは「選ぶ」のではなく、何が問いとして正しいか確かめることだ。
「父のお古のギター」という設定から先に決まっていた。
お古、というのは重要な条件で——アコースティックか、エレキか、で使える描写がまったく違う。
アンプなしでそのまま鳴る楽器か、繋いで初めて鳴る楽器か。
日常の場所に「ただそこにある」という存在感は、アコギの方が自然に出る。
アコギに決まったのは、技術的な理由よりも先に「父の部屋の隅に立てかけてある」という絵が
先に見えたからだった。AIはその判断を推薦したが、最後は「この絵の方が信じられる」という
人間の直感で確定した。
もうひとつ、決まるのに時間がかかったのが主人公の動機だった。
「なぜ弾こうと思ったのか」。これが弱いと、一話が成立しない。
「父への反発」「部活のオーディション」「好きな子に見せたい」——どれも物語的には使える。
でも、今回の物語には合わなかった。外側の動機を入れると、音楽への向き合い方が変わってしまう。
残ったのは、「ギター弾けたらどんな気分だろう？」という純粋な好奇心だった。
理由がない、という意味ではない。ただ、理由を説明しきらない。
そのくらいの純粋さが、一話目の語り手には必要だと判断した。
リサーチ：Gemini に頼んだこと
設定が固まると、次の壁に当たった。技術的なリアリティだ。
主人公のヒロは「父のお古のアコギ」を弾こうとして、うまく鳴らせない。
この「うまく鳴らせない」を、どう描写するか。
「音が出ない」では大雑把すぎる。「自分に才能がない」と思い込ませるリアリティには、
具体的な「どんな音がするのか」が必要だ。
ここでGeminiにリサーチを依頼した。
知りたかったのは主に2つ。
ひとつは、長年放置されたアコースティックギターはどんな状態になるか——弦の劣化、ネックの反り、
弦高の高さが初心者の演奏感にどう影響するか。
もうひとつは、ギターを初めて触った人が感じる最初の摩擦——何が難しく、何で諦めるのか、
という心理的なプロセス。
返ってきた素材は、技術的な記述として精度が高かった。ブランド名、年代別の素材の傾向、
弦ゲージの数値……詳細すぎるほど詳細なメモが揃った。
ただ、ここで大事なことがある。リサーチ素材はそのままでは使えない。
実在のブランド名や固有の数値を物語に持ち込むと、整合性の検証コストが跳ね上がる。
「その型番は当時存在したか」「そのブランドのギターをそう描写して問題ないか」——
確認しきれない細部が増えると、物語の土台そのものが揺らぐ。
だから技術的な事実は「素材」として参照するに留め、物語に入れるときは架空化・抽象化する。
「死んだ弦の音」という質感は使うが、そこに型番は必要ない。
リサーチの目的は、書き手が嘘をつかないための理解であって、取材した事実を並べることではない。
執筆：ヒロが語るということ
リサーチが終わって、いざ書き始めると、最初の稿はすぐに問題が分かった。
文章が「観察している」のだ。
主人公のヒロが、まるで自分の手元を外から見ているような文章になっていた。
「弦に触れると、思ったよりも硬かった」——これは事実の記述であって、ヒロの体験ではない。
ヒロという一人称の語り手は、内省的で、言い切らない。独白が多い。
その口調から出てくる言葉は、整っていない方がいい。
何度か書き直す中で、「ぼよん」という音が出てきた。
技術的な正しさからいうと、ギターの弦の音をそう形容するのはかなり粗い。
でも、ギターを初めて触った16歳が弦を弾いて「これが音楽か……？」と思う瞬間の
戸惑いは、「ぼよん」の方がずっと正確だ。
テンプレートではない言葉を探す作業は、AI同士のやりとりでは出てこない。
「ヒロならどう感じるか」「ヒロの語彙にこの言葉はあるか」という問いを繰り返す中で、
初めて出てくる。
稿が進んだところで、一行が「入っていた」。
ヒロが父のギターを手に取る場面に、それが前から置いてあった理由を示す一文が入っていた。
これは意図して仕込んだわけではなかった。描写の流れで自然に書かれた一行が、
後から読むと ep002 以降への伏線として機能していた。
物語を書いていると、こういうことが起きる。
設計段階で想定していなかったことが、執筆の中から出てくる。
AIと人間が往復する中でも、それは起きた。
その一行は、当然、抜かずに残した。
ここまでで分かったこと
「設計を決める」と「書く」は、まったく別の作業だ。
設計フェーズでは「何を作るか」を決める判断の速度が大事だった。
でも執筆フェーズで大事なのは、違和感に気づく速度だ。
「この文章はヒロの声か？」「この描写は技術的に嘘をついていないか？」「この言葉は整いすぎていないか？」
AIは初稿を速く出す。でも「これはヒロではない」と判断するのは、今のところ人間の役割だ。
その往復を何度もやって、ep001 は最終稿に近づいた。
次は ep001 を実際に読んでもらいながら、公開に向けた調整に入る。
整合性チェックと、公開前レビューの話は、また別の回に記録する。
この記事はotopublicの制作過程を記録した「裏側」記事です。
物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、
AIへの指示文そのものは、方針により伏せています。