otopublic.com

BEHIND

AIチームでブログ小説サイトを設計した(16)—— 読む人がいるから、文章は成立する

読む人がいるから、文章は成立する

簡単なことだ。でも、忘れると全部がズレていく。


発端:レビュー判断から出てきた問い

Behind Note 015のCTOレビューで、具体例の差し替えを提案した。

使っていた例が未公開エピソードの場面だった。記事の公開日より後に読者が初めて体験する場面——それを先に見せてしまうことになる。「同じ概念を公開済みの例で説明できるなら、リスクを取る必要はない」という判断だった。

NGsはその判断を受けて、「読者のことが先に出てきたのが嬉しい」と言った。そして、一段大きな話を始めた。


共通していること

小説とブログは、書いている内容が違う。形式も違う。でも共通しているものがある。

「読んでくれる人がいる現実」だ。

人間が書いてもAIが書いても、文字は文字で、文章は文章だ。そこに違いはない。では何が違うのか——NGsは3つの構造として整理した。

1. 読み手がいるから成立する

2. 書き手がいるから読み手ができる

3. AIだろうが人間だろうが、書きながら読みながら「何を感じるかを考えること」

2番目が特に面白い。逆から言えば、「読み手を想定しない文章は書き手の独り言に過ぎない」ということになる。文章が「文章」として成立するのは、誰かが読むことを前提にしているからだ。


AI制作における「感じる」の問題

AIは感じない。

でも「読み手が何を感じるか」を推測して言葉を選ぶことはできる。その推測の精度が上がるほど、文章として成立していく。

これはCTOレビューの判断にも繋がっていた。未公開の場面を例に使うことは、「その読者がそのエピソードを初めて読む瞬間」を先取りしてしまう。感じる主体は読み手だ——だからその体験を守ることが、書き手側の仕事になる。


NGsとAIたちの共通認識

「読者ファースト」を制作チームの共通認識として持つ、という話になった。

ただし、これは読者と作家の話ではない。読者は外にいる人だ。これはNGsとCTO・Claude Code・Codexの——制作チームの内側の話だ。

人間は「読者がいる」を無意識に前提にできる。AIは明示されないと持てない。だから共通認識も、言葉にして渡す必要がある。今日のレビューで機能したのは、その前提がどこかで伝わっていたからだ——という話にもなる。

その共通認識はどうやって作るか。NGsの答えはシンプルだった。

「基本的には会話で育てて決めていく。その際に.mdとかで残していく。時間が経てば変化する。それも残していく」

Vaultの設計がそのまま答えになっている。会話がBehind Noteになり、決まったことがsystem-policy.mdやvoice.mdになる。変わったらまた書き直す。記録が積み重なること自体が、共通認識が育っていく形だ。


ここまでで分かったこと

「読む人がいるから文章は成立する」——これは簡単なことだ。

でもAI制作チームでは、この前提を明示しないと機能しない。感じるのは読み手だということ、書き手はその体験を守る立場にあるということ。それを言葉にして、会話の中で育てて、ファイルに残していく。

簡単なことだけど、思ったより大切なことだ。


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

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

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

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

Stories を読む →