原作と執筆システム
長く止まっていた小説を、AIと続きを書くための仕組みへ。連載の本文と、一話ごとに資料・設計・点検をつなぐ工程を見せます。
原作は『年50日働けばいいはずだった地方政治家、地元にダンジョンができたせいでサイドFIRE生活が終わる』。突然ダンジョンが生まれた町で、制度も前例もないまま現実を回す側の物語です。
多忙で10年以上断筆していても、書きたい物語はたまり続けた。小説の読み書きの経験を、AIへ資料を渡し、本文を点検する判断に使っています。本文は自作の執筆システムを使ってAIが執筆し、カクヨムでは「AI本文利用」と示しています。
展示で確認した公開範囲は、第1〜23話と掲示板回の24本、約13.2万字。連載開始は2026年6月6日、展示資料に記した最終公開日は8月30日です。最新の本文はカクヨムで読めます。
見ていられなくて、つい口が動いた。 「——今ここで決められることと、決められないことを、分けませんか」 しん、と会議室が静まった。
原作 第1話「俺のサイドFIREが消えた日」より
人物、場所、過去の出来事、作品の意図を、毎回すべて説明し直すのは難しい。人が確定した設定と本文を残し、今回の目的に必要な資料を選んで渡すようにしました。
この話に使う資料の束を「Context Pack」と呼んでいます。必ず使うこと、今回は使わないこと、すでに変更された設定も整理し、本文を書く前の前提を揃えます。
| 段階 | 文字量 | 役割 |
|---|---|---|
| 設定資料全体 | 約62万字 | 作品の設定を保持する |
| 今回使う素材 | 約1.6万字 | 必要な資料を選ぶ |
| 設計書・プロット | 約1.1万字 | 場面と進め方を決める |
| 原稿 | 約5,600字 | その設計から本文を書く |
手元PCのClaude Codeで作者本人が運用していた、2026年6月以降の執筆工程です。書き始める前の設計と、書いた後の点検を分けています。
作品と今回の話を特定し、資料の鮮度を確認。Context Packを作る。
場面の順番、視点、到達点を決める。展示した運用では人が設計を承認する。
初稿を書き、文字数などの機械検査と、設定・過去話との照合を行う。
指摘に応じて直し、整合性を確認。本文の確定と、設定への追加は人の承認を通す。
作者、利用者のAI、機械の検査、資料から証拠を取り出す処理を分けています。AIが文章と意味を扱い、機械が工程の状態や資料の鮮度を確認します。作品へ何を採用するか、基準を変えてよいかを決めるのは作者です。
これは前身の個人システムを整理した2026年8月22日の記録です。TSUZUKEEPの現在の提供機能や、すべての運用の既定値を示す一覧ではありません。
| 担当 | すること | 次へ渡すもの |
|---|---|---|
| 作者 | 目的・採否・品質基準を決める | 承認と、残す／直す理由 |
| 利用者のAI | 資料を解釈し、設計・本文・レビューを提案する | 作者が選べる案 |
| 機械の検査・記録 | 文字数などを数え、状態と資料の鮮度を確認する | 検査結果と保存した作業状態 |
| 資料の証拠抽出 | 設定・過去話から候補や食い違いを探す | 参照箇所と根拠。正本は変更しない |
展示した人間承認の運用例は、資料の採用→場面設計→設計の承認→本文→レビュー→修正→本文の確定、という順です。本文の確定と、新しい事実を設定へ入れる判断は分けます。
素材が古ければ資料の選択へ、場面の到達点が違えば設計へ戻ります。本文の問題なら下書き、指摘の根拠が違えばレビューを見直します。失格だった案も、原因をたどるために保存します。
資料や確定本文を変えたときには、その資料を使った案が古くなっていないかを確認します。解決が必要な指摘が残っている状態を、AIの「大丈夫です」という宣言だけで確定しません。そのために検査と作者の採否を別に置いています。
確定した本文は、次の話の資料になります。同じ設定と本文を、人物のデザインやマンガ・動画の材料にも使います。画像を作るときも、物語の中でその人物が何をするかから出発します。
自分用の執筆システムを検証した記録がFable、ほかの書き手もいつものAIで使える形へ作り直す取り組みがTSUZUKEEPです。このページの個人用システムと、開発中のサービスは使い方が異なります。
2026年9月23日の生成AIなんでも展示会 Vol.6の資料と、前後の制作記録をまとめています。制作や検証の時点は、各説明に記しています。
制作の展示室へ戻る