食い
「鍵の設定を途中で変えたが、序盤の描写を直したか思い出せない」。長編でよく起きるこの手の困りごとは、意味を読まなくても、更新日時と本文の文字列を突き合わせれば見つかります。2026年8月、Plotoriaに伏線・時系列・設定の非AI整合チェックを続けて追加しました。どこまでを機械が数え、どこからを作者が読むのか、その線引きの話を書きます。
長編を書いていると、細部の食い違いが少しずつ溜まっていきます。
鍵の設定を第8話で変えたけれど、序盤の描写を直したかどうか思い出せない。伏線を回収したのに、管理側の状態は「未回収」のまま。回想として差し込んだ話が、いつの間にか本筋の何話目なのか分からなくなっている。
どれも、放っておくと後からたどれなくなります。かといって、全話を読み返して確かめるのは、書く時間を丸ごと持っていきます。
この夏、Plotoriaにはこの種の「突き合わせ」を助ける機能を、伏線・時系列・設定の順に足してきました。共通しているのは、AIを一度も呼ばないことです。
数えれば分かることと、意味を読まないと分からないこと
「本文の記述が設定と食い違っている」を直接判定するには、文章の意味を理解する必要があります。それはAIの仕事で、ここでは扱いません。
一方で、設定を書き換えたあと、その語を使っている既存の話に手を入れたかは、更新日時と文字列の照合だけで分かります。回収リンクがあるのに状態が未回収のままか、も、作者が登録した2つの情報を見比べるだけです。作中順を宣言してあれば、語り順との食い違いも計算で出ます。
これらは「数えれば分かる事実」です。AIに聞く必要がありません。しかも、AIを通さないので出力も費用も発生せず、結果が毎回同じで、判定の根拠がそのまま画面に出せます。
だから、意味の理解が要る部分はAI相談に任せたまま、機械的に確かめられる部分だけを切り出して、それぞれの作業画面に置くことにしました。
設定を書いたあと、どの話に響くか
設定・用語集のページに「設定の内容を書いたあと、まだ触っていない話」というカードを追加しました。
最近90日以内に内容を書いた設定・用語を拾い、その言葉が本文に出てくるのに、設定より前から本文を書き換えていない各話を並べます。「鍵の正式名称を第8話で変えた。『鍵』という語が出てくる第1話・第3話は、その変更より前に書いたきり」——これを一覧にします。
見ているのは「更新日時の前後」と「その言葉が本文にあるか」だけです。中身が食い違っているとは言いませんし、「直すべき」とも言いません。本文も設定も自動では書き換えません。
擬陽性を避けるために、いくつか黙る条件を入れました。見出し語だけで説明が空の設定は対象外（変わった中身がそもそも無い）。ピン留めやカテゴリ整理では出ない（本文を読み直す理由にならない）。設定を保存した24時間以内に触った話も出しません（「話を保存 → ついでに設定も直す」は同じ作業の流れなので）。改名した場合は旧表記も探して、「『魔導石』が古い本文に残っています」と添えます。
対象は直近90日ぶんだけなので、放っておけば自然に一覧から消えます。直すまで出し続ける催促にはしていません。各話には「AI相談で確かめる」を置いてありますが、押しても外部AIは呼ばず、その設定1件と話1件だけを下書きに載せた相談フォームが開くだけです。送るかどうかは作者が決めます。
伏線は、状態と繋がりの2系統で管理されている
Plotoriaの伏線には、状態（未回収／回収済など6種類）と、張る・回収の場所（どの章・どの話で仕込み、どこで回収したか）という2系統の情報があります。どちらも作者の手動管理です。だから、片方だけ更新して片方を忘れる、というのが自然に起きます。
伏線ページに、この2系統の食い違いを機械的に確かめるカードを足しました。見ているのは4種類です。
- 状態は「回収済」なのに、どの章・話で回収したかのリンクが無い
- 回収先の話は「完成」しているのに、伏線の状態は未回収のまま
- 語り順で、回収が張るより前に置かれている
- 作中順（作者が宣言した、物語内で起きた順）で、回収の出来事が張るより先に起きている
先の3種類は、伏線ページが元々読んでいるデータ（伏線・章・各話・リンク）だけで計算します。AI呼び出しも、DBの変更もありません。作中順を見る4つめだけは、作者が宣言した順序を読むために軽い問い合わせを1本足しています。
判定の形には気を使いました。「回収リンクが無い」のように不在を断定する検査は、データの取りこぼしがそのまま誤りになります。だからここは伏線とリンクを全件読み切ってから、行の有無だけで判定します。逆に「回収が張るより前」は、章リンクと話リンクが混在していると共通の物差しが無いので、そういう伏線には検査を掛けません。迷ったら黙る、を通しています。
同じ画面に「伏線マップ」も置きました。行が伏線、列が章のグリッドで、どのセルに「張る」「回収」があるかを1枚で見せます。これも配置を見せるだけで、良し悪しは判定しません。
「回想で先に見せているので、このままで良い」というケースは実際にあります。そのために、指摘は1件ずつ「確認済み」にできます。作品データは変えず、消えるのは表示だけ。あとから根拠のデータが変われば、新しい事実として出し直します。
いつ起きたか、なぜ起きたか
時系列と因果は、伏線とはまた別の切り口です。ここも「並べるところまで」を機械がやります。
時系列の下見は、各話に「作中時間」（物語の中でいつの話か）を作者が1行だけ書けるようにして、それを話数順＝読む順に並べた縦軸ビューです。構成ページの上のほうに置いてあります。
作中時間は自由記述です。「開幕から三日後」「帝国暦412年 春」「同じ日の夜」——作品ごとに暦が違うので、日付型にはしていません。だから並べ替えもしませんし、「時系列が逆」とも指摘しません。回想や叙述の入れ替えは正当な技法で、前後しているのが正しい作品は普通にあります。
作中順の宣言は、その一歩先です。作中で起きた順そのものを、作者が上下ボタンで並べてもらいます。宣言があれば、語り順（第何話か）と作中順の2本が揃って、推測なしで「どの話が回想／先出しとして差し込まれているか」が出せます。初回は語り順そのままから始めるので、どこを動かしたかが常に作者の判断として残ります。
出来事の繋がりは、「なぜこの展開になったか」の側です。各話の中に複数置ける「出来事」を、原因・動機・条件・妨げ・情報判明という有向リンクで繋ぎます。8月にはこれを左から右へ流れる図でも見られるようにして、さらに非AIの構造チェック（確定リンクの両端のどちらかが候補・破棄の出来事になっている、原因側が結果側より後の話にある）も足しました。
3つの責務は分けてあります。時系列は「いつ」、出来事の繋がりは「なぜ」、伏線は「読者へどこで提示し、どこで回収するか」。同じことを2箇所で管理しないようにしています。
本文からは、抜き出さないと決めた
これらの機能を作るとき、いちばん最初に決めたのは「本文から機械的に抜き出さない」ことでした。
本文から時間表現（「三日後」「かつて」）を正規表現で拾って作中時間を自動で埋める、という案は取っていません。本文から因果を推測して出来事リンクを引く、もしません。
理由は2つあります。1つは、当たった一部だけが正解のように見えてしまうこと。作中の暦も、因果の結び方も、作品ごとに違います。共通の物差しが無いものを機械が拾うと、外れた抽出が「整理」ではなく作者の記憶の汚染になります。
もう1つは、この画面が「作者が自分の物語を思い出すために読むもの」だからです。そこに機械の推測が混ざると、読む価値が落ちます。書いていない話は「未記入」と出すだけで、埋めません。
同じ理由で、指摘から状態やリンクを自動で書き換えるボタン、指摘から作中順を並べ替えるボタンは置いていません（作中順そのものは、構成ページの「作中で起きた順」で作者が上下ボタンで並べます）。整合チェックが出すのは突き合わせて分かる事実と、対象のカードへ戻る導線だけ。判断して直すのは、いつも作者です。
Plotoriaの今日の開発
2026年8月の開発では、非AIの整合チェックを続けて追加しました。
伏線の状態×リンクの整合チェックと伏線マップ、設定差分検知、各話の作中時間と時系列の下見、作中順の宣言と回想・先出しの表示、出来事の繋がりとその構造チェック。どれもAIを呼ばず、それぞれの作業画面に置いてあります。
投稿予定先を設定している作品では、投稿前チェックの末尾から、これら作品内に分散した確認場所へまとめて辿れるようにもしました。ここでも検査結果や件数は集約せず、「問題なし」とも判定しません。既存の画面へ戻る導線だけです。
デモ作品にも見本のデータを入れてあるので、ログインしてデモを開けば、それぞれのカードがどう見えるかを確かめられます。
伏線の張り方と回収の管理は伏線の張り方・回収のコツで、章立てと構成の考え方は小説のプロットの作り方で紹介しています。章の役割をAIなしで検査する話は「役割」はラベルではなく検査基準ににも書きました。今後検討していることはロードマップにまとめています。