時間軸は2本ある
crossoverアークを書き始めると、すぐ問題が出てきた。
同じ場所、同じ午後を描いているのに、時間をどう管理すればいいのかが分からなかった。
発端：2本の時間軸という問題
otopublicには、時間軸が2本ある。
ひとつは現実世界の時間軸——記事が公開される日、サイトが動いている現在。
もうひとつは物語内の時間軸——登場人物たちが生きている、梅雨から夏休みへの時間。
この2本は、完全に切り離して扱う必要がある。story-01の第1話が公開されたのは6月7日だが、物語の中のヒロは「梅雨の日」にいる。Behind Notes が「現実」を記録するのに対して、小説本文は「物語時間」の中だけで動く。この分離が崩れると、どちらがどちらなのかわからなくなる。
解決策は設計として最初から持っていた——Behind Notes と小説本文を完全に切り分け、同じサイトに載せながら別物として扱う、という方針だ。
問題が本格化したのは、crossoverアークに入ってからだった。
物語内の時間軸：crossoverという難問
story-01のヒロと、story-02の奏が、同じ日の午後に同じ店にいる。
どちらの主人公も同じ場面にいる。でも視点が違う。ヒロから見た午後と、奏から見た午後は、同じ出来事を別の角度から描く。このとき、2本のストーリーの「時間」をどうやって整合させるか。
最初の発想は「分単位で管理する」だった。14時に○○が起きて、14時15分に□□が起きる、という形で時刻を揃えれば、どちらのエピソードを書いても矛盾が出ないはずだ——。
転換：「いつ」より「何が起点か」
ここでCTOから別の見方が出た。
「時刻を管理するのではなく、何が次の場面を始めるかを管理する方が整合性を取りやすいのでは」
実際に書いていた経験と照らすと、これは正しかった。ep007（story-02）の最後の行は「ミキの声がした。」という一文で閉じている。この一文がep008（story-02）の起点になる。時刻は書かれていない。でも「何がトリガーになってどう動いたか」という連鎖は保たれる。
分単位の数字を揃えると、答え合わせが必要になる。起点を持っておけば、数字なしで因果の順序が担保できる。
発展：因果アンカーという考え方
NGsはここからさらに一歩進めた。
「ポイントを管理する考え方だね」と言って、具体例を出した。
story-01 ep002で、ヒロはギターを抱えてけんじの店に入っていく。同じ日、story-02 ep001で、奏は店の外からその少年が入っていくのを目で追っている。
原因はヒロが店に入ったこと、結果は奏の心が動いたこと。 この2点は、どちらのPOVからも観察できる。
行動ベースのアンカー（「ヒロが入った」）だと、story-01の視点に依存する。因果ベースにすれば——「誰かが店に入った（原因）、それを見た誰かの中で何かが動いた（結果）」——どちらのストーリーも同じ2点を参照して書ける。
story-01はその原因の内側から、story-02はその結果を外側から受け取る。どちらを先に読んでも成立して、両方読んだときに「あの日のことだったんだ」とつながる体験が生まれる。
深化：存在には必ず表と裏がある
さらに議論は進んだ。
「2つ以上のアンカーがあれば安定する。原因と結果、光と影みたいに」
1点では位置しか決まらない。2点で線になり、3点で面になる。アンカーが複数あると、片方が曖昧になっても別のアンカーで整合性を担保できる。
そしてもう一歩。
「必ず誰か（何か）があれば、最低でもその周りでは別の事が起きてる。やる側と見てる側でも同じ」
これは、アンカーを「設計して作る」ものではないということだ。存在するものを定義すれば、表裏は自動的に生まれる。
ヒロが店に入るという行為が存在する——その瞬間、「入った側」と「見ていた側」が同時に生まれる。crossoverの設計で「どこを共有シーンにするか」を考える必要はない。「誰かが何かをする瞬間」を定義すれば、もうそこには複数の視点がある。
表と裏、やる側と見てる側。それが自然にアンカーになる。
ここまでで分かったこと
時間軸の管理には、2つの問題があった。
現実時間と物語時間の切り離しは、Behind Notes と小説本文の分離として設計段階から持っていた問題だ。こちらは解決している。
物語内のcrossover管理は、書いてみて初めて出てきた問題だった。最初は「分単位で時刻を揃える」を考えた。実際に書くと、時刻より因果の連鎖を共有するアンカーポイントを持っておく方が整合性を取りやすいことが分かった。
どちらのPOVからも観察できる「原因」と「結果」を定義して、両ストーリーがそこを参照する。アンカーを設計するのではなく、「誰かが何かをする瞬間」を定義すれば、表裏は自動的に生まれる。
そしてこの議論には、もうひとつの側面がある。
人間の作家は、場面の共有情報を無意識に補完する。 「誰かがいれば、その周りで何かが起きている」を説明なしで処理できる。でもAIは、明示されていないことは補完しない——あるいは、間違って補完する。
今回 world/timeline.md に書いた「story-01 ep008とstory-02 ep007は同日同場所」という記述は、物語の整合性管理であると同時に、AIへの作業指示でもあった。それがないと、story-01を書くAIとstory-02を書くAIは「同じ場面を共有している」と認識できない。
従来のPC作業で「細部まで説明しないと動かない」のと同じ構造だ。物語の場合、その「細部」が時刻ではなく「誰が何をする瞬間か」という因果の形をしている——それがこの議論で見えてきたことだった。
アンカーポイントは、crossoverの整合性を担保する設計であり、AIが複数のストーリーを矛盾なく書くための共通言語でもある。
この記事はotopublicの制作過程を記録した「裏側」記事です。
物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、
AIへの指示文そのものは、方針により伏せています。