KUCHIKIGAOKA UNIVERSITY 朽木ヶ丘大学で怪異と生きる ← 小説に戻る

PRODUCTION CASE STUDY / AI小説の制作工程・開発者ノート

AIに作らせた作品ではなく、
AIと何度も作り直した作品。

執筆・制作：tatsutatsu-A

『朽木ヶ丘大学で怪異と生きる』は、AIを初稿生成だけに使った作品ではありません。 人間が方針を決め、AIが提案・執筆・点検し、人間が採用・却下・再指示する。 その往復を本文、Web、ビジュアル、音楽まで広げて完成させた、全36話の制作プロジェクトです。

第一話から読む 制作工程を見る

本ページは「AIがすべて自動で作った」という紹介ではなく、実制作で何が機能し、何が難しかったかを記録する技術記事です。

PROJECT SNAPSHOT

36全話・完結
557,318完成稿文字数
100+編集・確認・再評価
92.4最終総合平均 / 100
Final gate: A「完成でよい」完成を妨げる明確な問題：0件

CORE PRINCIPLE

AIの役割は「最終決定者」ではなく、執筆・編集・レビュー・実装を高速に往復する制作環境。作品の方向を決めること、何を残すかを選ぶこと、そして最後に修正を止めることは人間側の仕事としました。

THE WORK / 作品について

怪異を倒す話だけではなく、
「自分が自分であること」を扱う。

現代日本の大学を舞台にした、怪異・ホラー・恋愛・コメディを含む全36話の物語です。完成稿は実ファイルの文字列カウントで557,318文字。

全体を通して扱うのは、記憶、夢、他者からの認識、自分が自分であること、人間を「役割」や「器」として扱うことへの拒否、そして明日も生きること。怪異の仕組みと人物関係の両方に、同じテーマが繰り返し形を変えて現れます。

記憶夢認識自己同一性役割と人間性明日

KEYWORD CLOUD

55万字の本文に、何が繰り返し現れたか。

TOP 100 WORDS

完成稿から一般語を除外し、人物名・場所・能力・テーマに関係する語を中心に出現回数で可視化しました。大きい文字ほど本文中で多く現れます。

完成稿本文の上位100語を出現頻度に応じた文字サイズで配置したワードクラウド
頻出語は作品の価値を直接示すものではありませんが、人物・モチーフ・舞台語彙がどの程度本文を占めるかを見る補助資料になります。

PRODUCTION FLOW / 制作フロー

生成 → 評価 → 指示 → 再生成では終わらない。

AIに文章を出させるだけなら一方向です。この制作では、判断を人間側へ戻すループを明示的に作りました。

01人間が方針を決めるテーマ、着地点、残す要素、禁止事項を指定
02AIが作る・調べる初稿、改稿、矛盾確認、候補提示、実装
03人間が判定する採用 / 却下 / 部分採用 / 再検討 / 巻き戻し
04完成条件で止める「別案がある」ではなく「直す必要があるか」で判断

HUMAN

人間が担当したこと

  • 作品テーマと各話の着地点を決める
  • 後続話を壊さない修正範囲を指定する
  • AI案を採用・却下・部分採用する
  • 「好みの別案」と「修正必須」を区別する
  • 必要なら以前の版へ戻す
  • 最終的に制作を終了する判断を行う

AI

AIを使ったこと

  • 初稿作成、場面改稿、ホラー描写強化
  • 会話・口調・説明量の調整
  • 設定、時系列、伏線、話間接続の確認
  • 重複表現、能力使用、役割説明の反復検出
  • 商業作品を想定した採点と再評価
  • HTML / CSS / JavaScript、画像、BGM制作支援

AI-ASSISTED WRITING / 本文制作

一話ずつ直し、全話へ戻って確認する。

長編では「一箇所だけ良くする」修正が、後の話の整合を壊すことがあります。そのため修正単位と横断チェックを分けました。

01

Draft

初稿を作り、場面の目的・怪異ギミック・人物の役割を固める。

02

Episode edit

1話ずつ、場面を壊さない範囲で会話、恐怖、説明量、テンポを調整。

03

Cross-episode QA

時系列、伏線、人物設定、能力、既出説明、前後話の因果を横断確認。

04

Regression check

今回の改善で、以前に直した問題や後続話が再び壊れていないかを確認。

05

Zero-base review

過去の点数や「前より良い」を捨て、その版だけを最初から評価。

06

Completion gate

改善案探しを停止し、完成を妨げる問題だけを検査して終了判定。

QUALITY CONTROL / ゼロベース採点

「前より良くなった」は、点数の理由にしない。

修正履歴を知ったまま評価すると、努力量や改善幅に引っ張られて点数が上がりやすくなります。そこで過去の採点を参照せず、その版だけを全話読み直す評価を繰り返しました。

92.4/ 100

FINAL AVERAGE

最終完成稿・総合平均

全36話を、コメディ・恋愛・恐怖・総合の4項目で評価。ここでの数字は「文学の絶対点」ではなく、改稿の優先順位、退行の発見、完成度の確認に使う品質管理指標です。

SCORE HEATMAP

全36話の評価分布

36 EPISODES × 4 AXES
全36話のコメディ・恋愛・恐怖・総合点を色の濃淡で示した採点ヒートマップ
各話を同じ尺度で並べることで、強みの偏りや章ごとの傾向を一覧化。画像を開くと原寸で確認できます。

FINAL COMPLETION GATE

最後は、AIにも
「改善案を探させない」。

FINALA完成でよい

文章は、探せば永遠に別案を作れます。「修正できる場所がある＝未完成」にすると、AI制作は終わりません。そこで最終段階だけは、改善提案そのものを禁止しました。

CHECK ONLY

  • 設定矛盾
  • 時系列矛盾
  • 重要伏線の未回収
  • 因果関係の欠落
  • キャラクター設定との矛盾
  • 明確な説明重複
  • 構成を壊すテンポ問題
  • メタ表現
  • 後の話と両立しない描写
  • 重大な設定穴
完成を妨げる明確な問題 0 件

この判定をもって本文制作を終了。

Stop rule: 「もっと良くできるか」ではなく、「完成を妨げる問題が残っているか」で終わりを決める。

VISUAL PRODUCTION / ビジュアル制作

キャラクターの設定を、
Web上の「見える差」まで落とし込む。

主要人物の正面立ち絵、能力使用時のポーズ、背景画像までAIを活用して制作。服装・能力・身長差・背景透過などを個別に調整し、作品本文と同じ世界観へ揃えました。

キャラクターデザイン

正面立ち絵を基準に、主要5人は身長差も意識して表示。透羽・千燈・小毬・依澄は、能力や個性が伝わるポーズ画像も別に制作しています。

heightoutfitposealpha

背景画像

大学廊下、階段、研究会室、神社跡、図書館地下、地下水路、教室、学食、ファミリーレストラン、祭りなどを制作。最終的には、必要な解像度を確保するため1背景ずつ元解像度で生成しています。

day / nightADVworld building

MAIN CAST / RELATIVE HEIGHT

主要5人・正面立ち絵

CHARACTER LINE-UP
鵺代玄兎 正面立ち絵
鵺代玄兎180 cm
鷺宮透羽 正面立ち絵
鷺宮透羽165 cm
緋鴉千燈 正面立ち絵
緋鴉千燈166 cm
白狼院小毬 正面立ち絵
白狼院小毬155 cm
蝶ヶ森依澄 正面立ち絵
蝶ヶ森依澄160 cm
正面立ち絵はPNG全体の高さをそのまま揃えず、透明余白を除いた人物の縦方向サイズを基準に正規化。鵺代玄兎180cmを基準として、設定身長の比率が画面上でも反映されるよう自動計算しています。

POSE STUDY / ABILITY VISUAL

能力・戦闘ポーズ

4 VARIATIONS
鷺宮透羽 能力使用ポーズ
鷺宮透羽水術
緋鴉千燈 戦闘ポーズ
緋鴉千燈吸血種 / 戦闘
白狼院小毬 能力使用ポーズ
白狼院小毬匂い
蝶ヶ森依澄 能力使用ポーズ
蝶ヶ森依澄夢

SUPPORTING CAST

周辺キャラクター

木崎 正面立ち絵
木崎
久住教授 正面立ち絵
久住教授
ユン 正面立ち絵
ユン

WEB / AUDIO / DATA

読むサイト自体も、作品の一部として作る。

公式サイトもAIを使いながらHTML / CSS / JavaScriptで制作。本文データ、表示情報、読み上げ辞書を分離し、静的サイトとしてCloudflare Pagesへ配置できる構成にしています。

HTML5semantic markup
CSS3responsive UI
Vanilla JSreader / audio
JSONepisodes / dictionary
Cloudflare Pagesstatic deploy
Browser TTSdevice voices

READ ALOUD

読み上げ機能

  • 日本語音声読み上げ
  • 再生位置の保持
  • 読み上げ中の行ハイライト
  • BGMとの同時再生
  • BGM / 読み上げの個別音量
  • iPhoneでの再生問題への対応

BGM

閲覧用BGM

  • 複数曲の切り替え
  • 順番 / ランダム再生
  • 個別音量調整
  • 読み上げとの併用を前提に設計

DATA MODEL

本文と管理情報を分離

episodes.json に話数・章・タイトル・本文ファイルを持たせ、本文TXTから表示管理を切り離しています。

PRONUNCIATION

読み上げ辞書

speech_dictionary.json は92エントリ。人物名、地名、術式名などを、画面表示を変えず読み上げ時だけ変換します。

episodes.json章 / タイトル / ファイル
Novel ReaderHTML + CSS + JavaScript
speech_dictionary.json表示はそのまま / 読みだけ変換
実ファイルに近いデータ構造を見る

episodes.json

{
  "id": "ep19",
  "chapter": "第二章",
  "title": "第十九話_大学の怪異が、みんな同じ方角を向いている",
  "file": "19_第十九話_大学の怪異が、みんな同じ方角を向いている.txt"
}

speech_dictionary.json

{
  "text": "朽木ヶ丘大学",
  "reading": "くちきがおかだいがく",
  "type": "地名・施設"
}

WHAT DID NOT WORK / AI制作の難所

AIは速い。でも、放っておくと終わらない。

長期プロジェクトで目立ったのは、生成能力そのものより、整合・評価・停止条件の難しさでした。

起きたこと制作ルール
修正案を探そうと思えば、永遠に探せる「別案」と「修正必須」を分離し、最終段階は改善提案を禁止
直した箇所を、後の修正で再び壊す1話ずつ修正し、毎回後続話への影響を確認
一話の改善で、後続話との因果が崩れる場面の着地点・設定・伏線の変更禁止条件を先に指定
「前より良い」で採点がインフレする過去評価を参照しないゼロベース採点
説明を足しすぎ、同じ役割を何度も説明する説明重複・能力使用・役割説明を全話横断で検出
AI案を全部入れると、作品の癖が消える採用 / 却下 / 部分採用 / 巻き戻しを人間が明示
長期化すると、どれが正しい版か分からなくなるZIP名に日時を入れ、最新版と過去版を追跡

ZIP-BASED VERSIONING / 版管理

Gitではない。でも「戻れる」ことが重要だった。

小説本文、JSON、辞書、HTMLなどをZIP単位でまとめ、最新版をAIへ渡し、確認・編集後に新しいZIPを受け取る運用を続けました。

INPUTnovels_YYYYMMDD_HHMM.zip現時点の正本
AI SESSION確認 / 編集 / 評価指示された範囲だけを変更
OUTPUTnovels_NEWDATE_TIME.zip新しい正本候補
✓版を残す
✓差分を意識する
✓問題時に戻れる
✓日時で追跡する

Gitそのものではなく、ブランチ・コミット・自動差分の機能もありません。ただし「正本を固定し、変更後の版を別に残し、巻き戻せる」という最低限の安全網として機能しました。

TAKEAWAY / 制作から得たこと

AI制作で大事だったのは、
「生成の上手さ」より「判断の仕組み」だった。

AIは、初稿、編集、レビュー、コード、画像、音楽を一本の制作工程につなげる力があります。一方で、長編になるほど「何を変えないか」「どこで止めるか」「どの版を正とするか」が品質を左右します。

この作品でAIに任せたのは作業の速度と検討量。人間側に残したのは、テーマ、好み、優先順位、採否、そして完成の判断です。その分担が、約55万字の本文と周辺制作を最後まで一つの作品としてまとめるための中心になりました。

作品を読む