otopublic.com

BEHIND

AIチームでブログ小説サイトを設計した(2)―― Obsidian と WordPress でデータを組んだ話

AIチームでブログ小説サイトを設計した(2)―― Obsidian と WordPress でデータを組んだ話

前回は「なぜAIチームで作るのか」「どんな役割分担にしたか」という話だった。

今回はもう少し地面に近い話をする。実際にどんな器にデータを入れたか、だ。

構想がいくら整っていても、置き場のないデータはすぐ散らかる。

だから最初にやったのは、「書く前に参照できるノート群」と「サイト側の骨格」を決めることだった。


Obsidian:書く前に参照する「世界の設計図」

物語を書くとき、AIに「書いてください」とだけ伝えても、毎回ゼロから始まる。

前回書いたキャラの口調、その街で起きた出来事、あるモチーフが最初に登場した回——

そういった文脈を毎回渡さないと、話が積み重ならない。

だからまず、書く前に参照するノート群を Obsidian に作った。

具体的には、世界観のルール・登場人物のプロフィール・場所の地図的なメモ・タイムライン・

物語同士が交差するシーンの記録、といったものだ。AIが下書きを書くとき、これらを渡す。

そうすることで、前回と矛盾しない続きが書けるようになる。

なかでも初日から決めたのが、references-private/ というフォルダを作ることだった。

物語にリアリティを持ち込みたいとき、現実の素材——実在する場所の空気感、

実際に体験した出来事の断片——を参照したくなる。

けれどそれをそのまま出すと、現実の場所や人が特定できてしまう。

だから「生の素材はここにだけ入れる」という場所を最初に確保した。

本文に出すときは必ず架空化の工程を通す、というルールとセットで。

「あとで整理しよう」と思っていると、書き進めるうちに境界線が曖昧になる。

自動化が進むほど、最初に壁を立てないと、壁のない場所から情報が漏れる。

これは設計の会議で出てきた判断の中で、地味だが一番効いていると感じているものだ。


WordPress:「あとで並べ替える」ために骨格を先に決めた

サイト側のデータ構造には、3種類の投稿タイプを用意した。

episode(各話) —— 物語の本文。1話ごとに1記事。

story(連載ページ) —— ある視点キャラクターが主役のシリーズをまとめるページ。

behind_note(この記事)—— 制作の裏側を記録するコーナー。いまあなたが読んでいるこれ。

3つを分けたのは、それぞれ「見せ方」が違うからだ。

各話は読み物として単体で成立する必要があり、連載ページは全体の地図として機能し、

裏側記事はエッセイとして読まれる。一つの型で全部まかなおうとすると、どこかで無理が出る。

分類軸も先に整えた。タクソノミーと呼ばれるしくみで、話を横断してたどれる軸を持たせた。

story_line(どの連載か)

character(誰が出るか)

location(どこを舞台にしているか)

motif(どんなテーマ・象徴が通っているか)

instrument(どんな楽器が登場するか)

これを最初に作っておくと、たとえば「あるキャラが出てくる話だけ並べる」という操作が

あとで一行で書けるようになる。ふつうのブログでタグを使って同じことをしようとすると、

記事の種類が増えるにつれてタグが混在して、「あの物語のキャラ」と「このブログのカテゴリ」が

同じタグ一覧に並んでしまう。それを避けたかった。

物語用の分類は、物語用の専用の軸で持つ。地味な設計判断だが、データが増えてきたとき、

この差は大きく効いてくるはずだ。


テーマ:見た目は最後ではなく、読む体験の設計だった

サイトのデザインはまだ仕上がっていないが、「読む体験」の方針だけは早い段階で決めた。

まず、色の正本を tokens.css に置くことにした。

フレームワーク側が色を管理するのではなく、プロジェクト固有のファイルが「この色はこれ」と

定義していて、それをサイト全体が参照する形だ。こうしておくと、「全体の配色を変えたい」

というときに一か所を直すだけで済む。後から迷子になりにくい。

表示モードは Light / Dark / System の3つを切り替えられるようにした。

音楽を聴くとき、夜に暗い画面で読むことが多い気がして。読者が選べることを最初から想定した。

本文の幅は 38rem、フォントは明朝体を基準にしている。

これは「音楽小説」というジャンルに合わせた判断だ。

ゴシック体で横広に読むより、縦に読み進める感覚——楽譜を目で追うような静けさ——が

この物語の空気には合う、という判断でそこに落ち着いた。


データを先に組む理由

構想の段階では「まず物語を書いてみてから考えよう」という誘惑がある。

実際、それで始めてもよかった。

ただ今回は複数のAIが書き手に加わる。それぞれが参照するデータが違えば、

物語は積み重なるどころか毎回ばらばらになる。

壁を後から作ろうとしても、すでに書かれた文章と矛盾したルールになりやすい。

器を先に作ることは、物語を縛ることではない。逆に、物語が広がれる地面を作ることだ。

次回は執筆の話に入る。

器が整ったところで、いよいよ最初の一話を書き始めた——そのプロセスを記録する。


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

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

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

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

Stories を読む →