AIチームでブログ小説サイトを設計した（1）―― 構想とチーム編成
音楽をテーマにしたブログ小説サイト「otopublic（音パブリック）」を立ち上げようとしている。
ふつうのブログと違うのは、書き手が一人の人間ではなく、複数のAIで組んだ「編集部」だということだ。
このサイトでは、まだ一文字も小説を書いていない。
だがその前に、けっこう長い「設計の会議」があった。この記事は、その会議の記録だ。
何を作ろうとしているのか、そして なぜその形に落ち着いたのか を残しておきたい。
なぜ「AIチーム」なのか
最初の発想はシンプルだった。
「同じ時間軸の上で、複数の物語が走っていて、ときどき交差する音楽小説を書きたい」。
ギタリストの話、リスナーの話、機材好きの話。立場の違う登場人物たちが、同じ街、同じライブハウス、
同じ一曲のまわりですれ違う。読者は入口を選べる。自分に近いキャラから入って、いつのまにか
別の物語と地続きだったことに気づく——そういう体験を作りたかった。
これを一人で全部書くと、どうしても語り口が均一になる。
そこで、物語ごとに違うAIを「作家」として立てることにした。
– ある物語は、内面描写の得意なAIに
– ある物語は、会話のテンポがいいAIに
– ある物語は、調べ物と質感づくりが得意なAIに
文体の癖がそれぞれ違うこと自体を、群像劇の強みに変えてしまおう、という賭けだ。
役割を「会社」に見立てた
ただ、作家が3人いて勝手に書くと、世界観もタイムラインもすぐ破綻する。
そこで役割を会社のように整理した。
– 人間（プロデューサー） —— 最終決定権。公開していいかどうかを最後に判断する人。
– CTO —— 全体を統括し、物語同士の整合性を見て、交差シーンを設計し、品質をレビューする。
– 作家たち —— それぞれの物語の初稿を書く。文体は意図的に揃えない。
– システム担当 —— サイトやデータ構造、自動化のしくみを作る裏方。
おもしろいのは、ある一人（一体）の働き者が 作家とシステム担当の二役を兼ねていることだ。
書くAIであり、作るAIでもある。これも実験の一部になった。
ここで大事にしたのは、「自動で全部書かせる」ことではなく、
AIと壁打ちしながら人間が決めていくという姿勢だ。最後の責任は人間が持つ。
設計はAI同士の「壁打ち」で決まった
この設計、実は人間が一人で決めたものではない。
たたき台を一つのAIが出し、それを別のAIがレビューし、さらに別のAIが穴を指摘する——
という往復を何度も回して固めていった。会議の議事録がそのまま設計図になっていった感覚に近い。
その過程で、最初の案から明確に変わった「効いた判断」がいくつかある。
判断1：「公開してはいけない情報」を初日から隔離する
物語に現実の手ざわりを混ぜたい。実在の出来事やモノを、フィクションの中にそっと織り込む。
ただしそのまま出すと、実在の場所や人が特定できてしまう危険がある。
そこで、世界観を管理するノート群の中に 「非公開専用の置き場」 を最初から作った。
実在の参照はそこにだけ置き、本文に出すときは必ず——
実在の要素を3つ以上に分解して、別々のジャンル・地域の要素と掛け合わせて合成する
というルールを通す。元が一つに特定できない状態にしてから物語に入れる。
さらに公開前のチェックリストも用意して、毎回それを通してから出すことにした。
このあたりは「あとで付ければいい」と思いがちだが、
自動化を進めるほど、最初に壁を作っておかないと事故る。だから初日に入れた。
判断2：分類は「タグ」ではなく専用のしくみで持つ
「このキャラが出てくる話の一覧」「このモチーフが響く回」——
こういう切り口で後から物語をたどれるようにしたい。
ふつうのブログのカテゴリやタグでやると、雑記記事とすぐ混ざってしまう。
そこで登場人物・場所・モチーフ・楽器・どの連載か、を それぞれ専用の分類軸として持たせた。
データの持ち方を最初に決めておくと、あとで「あの人が出る話だけ並べる」が一行で書ける。
判断3：制作の裏側そのものを、第2のコンテンツにする
そして——いまあなたが読んでいるこの記事が、その判断の産物だ。
otopublic には2本の柱がある。
ひとつは音楽小説そのもの。もうひとつが、この「AI制作の裏側」を見せる記事群だ。
小説はまだ無くても、作っている過程は今日から書ける。
「AIチームで小説を作るって、実際どうやるの?」に興味がある人が先に集まってくれれば、
小説が始まるころには、もう読者がいる。そういう狙いだ。
ただしルールは決めてある。小説本文には制作の説明を一切混ぜない。
AIの話はこの裏側コーナーでだけする。物語は、あくまで物語として読んでほしいから。
なぜこの組み合わせなのか
「なぜこの道具とこの体制なのか」を整理しておきたい。
なぜ1つのAIに任せなかったのか。
1つのAIだけに書かせると、全キャラの語り口が均一になる——群像劇の最大の弱点だ。
Claude Codeは内省・心理描写が長い文脈でも崩れない。Codex-Writerは会話テンポが速く構造的だ。Geminiはウェブの情報を直接引けるリサーチ力がある。
それぞれの「癖」を文体の多様性として使うという逆転の発想がこの体制の核心だ。
ただしバラバラに書かせれば世界観はすぐ破綻する——だから「CTO」という整合役が必要になった。
なぜObsidianを選んだのか。
決め手は「ローカルのマークダウンファイルである」という一点だ。
AIはファイルを直接読み書きできる。クラウドサービスならAPIの追加連携が必要だが、Obsidianならそれがない。Gitがそのまま使えるので「昨日のキャラ設定に戻りたい」が git revert で済む。
AIが参照するノート群には、シンプルなテキストファイルが最も摩擦が少なかった。
なぜSuperpowersを入れたのか。
Claude Codeはデフォルトだと毎回「まず探索してから」という曖昧な進め方になりやすい。Superpowersというスキルプラグインを入れると、「新機能の前にブレインストーミング」「バグ修正の前に体系的なデバッグ」「完了主張の前に検証コマンド実行」という構造化された行動パターンが強制される。
毎回スキルを読み込んで従うという「手順の強制」——CTOがいい加減な判断をしないために、このレールが必要だった。
なぜ人間が「プロデューサー」の役割を持ち続けるのか。
「この描写は実在の誰かを傷つけないか」「このタイトルは本当にこの物語に合っているか」——こういう問いには、AIは文脈の外側から判断できない。
最終的な公開の判断は人間が持つ。これは制約ではなく、このプロジェクトの質の保証として設計した。
AIが提案し、人間が決める。その往復が、どちらかだけより良いものを生む、という仮説のもとで動いている。
何ができたか
会議のあと、最初の土台を実際に組んだ。
– 世界観を管理するノート群 —— 登場人物・場所・モチーフ・タイムライン・交差の記録、
そして前述の非公開置き場と公開前チェックリスト。物語を書き始める前の「設定の器」。
– サイト側のデータ構造 —— 小説の各話・連載・この裏側記事、という3種類の入れ物と、
それらを横断する分類軸。将来の自動化に備えた接続点も仕込んである。
派手な見た目はまだない。デザインもこれからだ。
でも「複数のAIで、矛盾なく、安全に物語を増やしていける器」は組み上がった。
ここまでで分かったこと
一人で書くより、明らかに手数は増える。
たたき台を作り、別の視点でレビューし、穴を埋め、また回す。会議は長い。
それでも、違う癖を持つ何人かで一つの世界を組むという体験は、
一人の執筆では出てこない発見をくれた。意見が割れた場所こそ、あとで効く設計になった。
次は、器を実際にどう組んだかを話す。
Obsidian と WordPress でデータをどんな形に入れたか——設計が地面に降りてくる話だ。
この記事はotopublicの制作過程を記録した「裏側」記事です。
物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、
AIへの指示文そのものは、方針により伏せています。