【Inkubus 2.9.2リリース】ローカルLLMで100章22万文字、ライトノベル2冊分を書き切れるようになりました！(Gemma4 26B-MoE think問題対応 / あらすじのバグ修正)

v2.9の次はv3.0正式版を出す予定でしたが 😅
100章25万文字への挑戦で問題が2つ出たので、先に改善版を出します。

Inkubus 2.9.2ができました。100章22万文字を実際に書き切ったバージョンです。

長い作品でだけ壊れていた2点を潰しました。この版で100章を通しで走らせて、空っぽの章ゼロ、あらすじも100章ぶんちゃんと書かれた状態で完走しています。章数を増やしたときに「なんか変だな」となっていたところが、まとめて直りました。

1件目はバグ。作品のあらすじが章数についてこず、章が多いほど1行が痩せていました。50章の作品で1行10数字です。長編を書いた人だけの話ではなく、普通の分量でも起きていました。

2件目は改善。Gemma 4の26b MoE版で、本文が0字のまま完成してしまう章が出ていました。空だったら書き直させるようにしています。これはInkubusに限った話ではないので、ローカルLLMで文章をつくっている方にも使える対策だと思います。

変更履歴はこちらにまとめてあります。

2.9.2が効く人

大きな機能は2.9で入れたので、2.9.2は修正だけの版です。誰にとっても急ぎのアップデート、というわけではありません。先に書いておくと、次のどちらかに当てはまる方には、はっきり効きます。

• Inkubusで10章以上の中〜長編を書く方

• InkubusでGemma 4の26b MoE版(gemma4:26b-a4b-it-qat)を使う方

既定の4章前後で楽しんでいる方は、急いで入れ替えなくても困りません。次の版のタイミングでまとめて上げれば十分です。そのうえで後半には、この版で100章25万文字に挑んだ顛末を書きました。アップデートを急がない方にも、読み物として楽しんでもらえると思います。

Inkubusと、この記事の前提

はじめての方もいると思うので、先に少しだけ。

Inkubusは、ローカルLLMに小説を書かせるツールです。ロールと設定を決めて実行すると、あとは勝手に書きます。寝ているあいだに回して、朝に読む。そういう使い方を想定しています。ローカルLLMのメリットを活かした、検閲なしの(エロ)小説を書くことを目的にしていますが、ライトノベルや投稿サイト向けの作品など、汎用的な用途にもそのまま使えます。手元のGPUとOllamaだけで動くので、書いたものが外に出ることはありません。今回のように、借りたGPUを指定して回すこともできます。

どんな動きをするのかは、この動画(2分)を見てもらうのが早いです。

もうひとつ前提を。私はGemma 4をメインに検証しています。日本語の質と、手元で動く現実性の兼ね合いで、いまはこれが本命だと思っているからです。この記事に出てくる数字も、断りがなければGemma 4のものです。

そのGemma 4にも種類があって、この記事には2つ出てきます。ひとつはGemma 4 31b-qat(タグでいうと「gemma4:31b-it-qat」)。Inkubusの推奨モデルで、日本語の質はこちらが上です。同じ31bでもqatが付く版と付かない版があり、別物です。Inkubusが推奨しているのはqat版のほうなので、この記事でも必ずqatを付けて書きます。もうひとつはGemma 4 26b MoE(タグでいうと「gemma4:26b-a4b-it-qat」)。質で少し落ちる代わりに、手元のGPUでも速く動きます。

長くなるので、以降は31b-qat、26b MoEと略します。31b-qatと書いたらGemma 4 31b-qatのことです。

Inkubusがどういうツールなのかは、2.9のリリース記事に動画つきでまとめてあります。

必要な環境や動かすまでの手順は、使い方サイトのクイックスタートが最短です → https://inkubus.pages.dev/help/quickstart

単品購入版(2.7)はこちらの記事から →

使い方サイトはこちら。

影響が大きいのは1件目のバグなので、そちらから詳しく書きます。その前に、そもそも100章がどれくらいの量なのかを押さえておきます。

100章って、どれくらいの量なのか

アプリの数字で見ると

Inkubusは1作品を最大100章まで書かせられます。1章2,500字が目安なので、仕様の上では100章で25万字。これが上限です。

ただし、25万字はあくまで計算上の数字で、実際には引き算が2つ要ります。

ひとつはGPU。Inkubusは前の章を全部読ませてから次の章を書かせるので、必要なコンテキストが章数に比例して増えます。100章だと256Kです。

ここで意外な話をひとつ。今回使った31b-qat(4bit量子化)のモデルサイズは約20GBです。ところがコンテキストを256Kまで増やすと、読ませた文章を覚えておくためのメモリがモデルとは別に必要になって、VRAMの要求は合計48GBまで膨らみました。モデル本体より、コンテキストのほうが食うんです。

つまり256Kは、VRAM 32GBのRTX 5090ですら1枚ではあふれます。これが100章25万文字の壁です。今回は速度が欲しかったので全部VRAMに載せる前提で組み、RunPodでRTX 5090x3を借りました。

(あふれたぶんはCPUとメインメモリが肩代わりするので、遅くてよければVRAMが小さくても動きはします)

もうひとつは字数。指示した分をきっちり書いてくれるとは限りません。26b MoEは1章あたり平均1,781字で、指示の68%でした。31b-qatはもう少し素直で88%。この時点で、25万字ちょうどは無理そうだと分かります。

今回はこの25万字を目標に走らせて、22万字まで届きました。上限には少し足りませんが、アプリで狙える範囲のいちばん上まで行けた数字です。

現実の小説に例えると

とはいえ「22万字」と言われても、量の実感は湧きにくいと思います。現実の本に置き換えてみます。

400字詰めの原稿用紙なら、約560枚です。手書きで積み上げたら、と考えると気が遠くなる枚数です。

文庫本だと、1ページ600字として約370ページ。厚めの文庫がまるごと1冊できる分量です。

そして看板にしたライトノベル換算。ライトノベルはだいたい1冊10〜12万字なので、22万字はちょうど2冊分にあたります。シリーズものの1巻と2巻が同時にできあがった、と思ってもらうのが近いです。

1章2,500字という単位のほうも、本に置くとつかみやすくなります。文庫本で4ページ強。小説投稿サイトの連載1話分くらいの長さです。それが100話ぶん続く連載を、一晩かけずに書き切る。今回やったのは、そういうことです。

この長さが、短い作品では表に出なかった問題を引きずり出しました。さきほどの2件です。順に書きます。

バグ:あらすじが章数についてこない

50章の作品を書かせたら、あらすじが1行十数字しかありませんでした。9万字近い作品の紹介文が、十数字です。

1章のあらすじは「真由の平穏な日常。」の9文字です。

短い作品なら、こうはなりませんでした。同じ頃に書かせた8章の作品だと、1行ずつちゃんと中身があります。

最初は出力の頭打ちを疑いました。どこかに4,000字くらいの制限があるんだろう、と。違いました。犯人はInkubus自身が書いていた指示です。

Inkubusはプロンプトであらすじを「全体で300〜600字程度」と指示していました。章数に関係なく、ずっとこの固定値です。50章分の要点を600字に押し込もうとして、1行あたりがどんどん痩せていく。31b-qatでも同じ症状が出たので、モデルのせいではありませんでした。

おもしろいのは、モデルが指示を守っていなかったことです。50章のときの実際のあらすじは939字で、指示した上限の600字を超えています。それでも50章に配れば1行18字。指示が実態から離れすぎていて、モデルが多めに書いてもまだ足りていませんでした。

気になったので、手元にある226作品全部のあらすじを測ってみました。1行あたりの字数を、章数の帯ごとに出してみます。

4章の作品で105字。5〜8章で62字。9〜16章で45字。46〜50章まで行くと10〜11字。

見てほしいのは9〜16章のところです。ここに114作品、全体のちょうど半分がいます。つまり長編を書いた人だけの問題ではなくて、ごく普通の分量でも、あらすじは既に半分近くまで圧縮されていました。私も気づいていませんでした。

直し方は単純で、指示する字数を章数に連動させました。約600字を下限にして、1章あたり150字。50章なら約7,500字、100章なら約15,000字です。100章でもコンテキストの1割ほどなので、本文を圧迫はしません。

図にするとこういうことです。あらすじの紙の大きさを、本の厚さに合わせました。

修正後に同じ50章で測ったら、あらすじは3,452字でした。指示した7,500字には届いていません。ただ1行あたりで見ると18字が69字になったので、3.7倍です。あらすじとして読めるものになりました。実際の画面がこちらです。

改善:Gemma 4 26b-a4bで0字の章が出る

もう1件は、Gemma 4の26b MoE版、タグでいうと「gemma4:26b-a4b-it-qat」で起きていた話です。

先に書いておくと、ここから先はInkubusに固有の話ではありません。考えてから書くタイプのモデルに長い文章を書かせると、誰の環境でも起こりうることでした。ローカルLLMで文章をつくっている方にも、そのまま当てはまると思います。

検証は26bで回していました

Inkubusが推奨しているのは31b-qatのほうです。日本語の質はこちらが上で、本番もこれで書かせます。それでもこの改善を26bのために入れたのは、100章という長さのせいでした。

100章の検証は、1本回すだけで何時間もかかります。何度も試せる速さがないと、そもそも検証になりません。

私の開発機はGeForce RTX 5070 Tiで、VRAMは16GBです。この環境で31b-qatを動かすと約4字/秒まで落ちます。載り切らないぶんをCPUが肩代わりするからです。6万字書かせるだけで4時間かかる計算になります。

同じGPUで26b MoEに30章書かせたときは、約6万字で19.6分でした。ならすと50字/秒。4時間が19分です。

なので長い作品の検証は26bで回していて、そこで0字の章に出くわしました。推奨しているモデルの話ではありませんが、検証に使う以上、転ばれると困ります。

4章が0字のまま「完成」していた

50章のうち4章が、本文0字のまま完成扱いになっていました。8%です。エラーではありません。

生成の記録を見ると、すぐ分かりました。正常な章は平均36.7秒かかっているのに、0字の章は4〜12秒で終わっています。モデルが何も書かずに応答を閉じて、Inkubusがそれをそのまま保存していました。空かどうかを見るコードが、そもそも無かったんです。

トークンの会計にも、気になる数字が出ていました。このrunでは、出力トークンの3分の1(約3.9万トークン)が1文字の本文にもなっていません。日本語なら1字あたり1トークンを切るのが普通なのに、26bは1.34でした。

疑ったのは思考(thinking)です。このモデルは書く前に考えるタイプで、考えている中身もトークンとして出てきます。ただInkubusはそれを読んでいませんでした。捨てているなら会計が合いません。

そこで、思考が何字来ているのかをログに出すようにして、もう一度回しました。当たりでした。

タイトルを1行つけるのに、思考が7,035字。出てきた本文は79字です。89倍考えてから、1行書いている。著者名にいたっては思考3,832字で本文11字でした。30章ぶんを合計すると思考が約15万8千字、本文が約5万7千字。出した文字の73%が思考です。トークンに直すと約3.9万で、消えていた分とちょうど合いました。

0字の章の正体も分かりました。あれは正常終了ですらありません。思考だけ延々と吐いたあと、終了の合図が来ないまま通信が切れています。ログにはこう出ます。

[ollama 💭] thinking 4234字(本文 0字)
[ollama ✗] stream ended without done marker after 16539ms (0 chars)

考えているうちに力尽きた、ように見えます。考えた中身は捨てられるので、こちらには0字だけが残る。

ちなみに、考えるのは26bだけではありません。あとで出てくる100章の生成は31b-qatですが、こちらも毎章3,000字ほど考えてから書いています。

違うのは量です。26bのほうがよけいに考えて、そのぶん本文が短く締まります。

字数の上限は設定していないので、思考が本文の枠を食いつぶしているわけではありません。枠そのものが無いからです。因果はまだ分かっていません。

空だったら、もう一度書かせる

原因がモデルの側にある以上、Inkubusにできるのは、転んだら起こすことだけです。

章の本文が0字だったら、同じ指示で最大2回まで生成し直すようにしました。それでも空なら、その作品は失敗として扱います。空の章が完成扱いで残ることは無くなりました。再試行中は画面にもそう出ます。事故から復活までの流れは、この図のとおりです。

初戦から仕事をしました。24章が空になって1回目で復活。26章は1回目も空で、2回目にようやく1,728字が返ってきています。リトライを2回にしておいて助かりました。1回で諦める設計なら、26章は空のまま完成していたことになります。

50章を通したときは、空応答が54回の試行のうち6回。そのすべてが再試行で復活しました。

Inkubusを使っていない方にも、ここは同じことが言えます。考えてから書くモデルに長い文章を書かせるなら、返ってきた本文が空でないかを毎回見て、空なら投げ直す。それだけで防げます。

厄介なのは、エラーが飛んでこないことでした。APIとしては成功で返ってくるので、気づくのは仕上がりを読んだときになります。50章のうち4章が空でも、最後まで走り切ってしまいます。

100章25万文字への挑戦 🔥

ここまでは50章の話でした。直すものは直したので、本題に行きます。

100章。25万文字。Inkubusの上限いっぱいであると同時にGemma4の256Kコンテキストの上限とほぼイコールです。

正直、走らせるまでは半信半疑でした。50章で0字の章が出るくらいですから、その倍で何が起きるか分かりません。後半になるほど読ませる文章が増えるので、どこかで速度が落ちて止まるかもしれない。話の筋が保たなくなるかもしれない。やってみないと分からないことばかりでした。

まず環境です。冒頭に書いたとおり、手元のGPUには載りません。RunPodでRTX 5090を3枚借りました。モデルは31b-qat、コンテキストは256Kです。

借りかたと料金の話は、別の記事に書きました。

冒頭に書いた48GBは計算ではなく、この画面の実測です。3枚合わせて48GB、1枚あたり15〜17GBでした。

走り出すと、これが速い。55章まで36分。12万2千字です。この時点で、すでにライトノベル1冊ぶんを超えています。

空で終わった章はゼロ。1章あたり平均2,234字で、指示した2,550字の88%でした。26bの68%と比べると、だいぶ素直に書いてくれます。

あらすじの新しい指示も、ここで初めて100章分の仕事をしました。指示は約15,000字。返ってきたのは4,973字なので、満額には遠いです。ただ1行あたりでは50字ありました。600字固定だった頃の8倍以上です。

100章目まで、ちゃんと1行ずつ書かれています。

ここまでは順調でした。半分を超えて、このままいけると思っていました。

56章で、画面が止まった

事故はここで起きました。56章に入ったところで、進捗が動かなくなったんです。

サーバーのログを見ると、56章の依頼を送ったきり応答がありません。ところがRunPod側のOllamaはログを吐き続けています。向こうは書いているのに、こちらには1バイトも届いていない。インターネット越しに長くつなぎっぱなしにしていると、たまにこういう静かな切れ方をします。25分待ちましたが、何も来ませんでした。

12万2千字を書いたところで通信が死んだわけです。ここで全部消えていたら、この記事は書いていません。

助かったのは、章ごとに保存する設計でした。Inkubusは1章書き終えるたびにデータベースへ保存します。切れた時点で1章から55章、12万2千字はもう手元にある。失うのは受信の途中だった56章、それも書きかけの1章分だけです。

そしてここで出番が来たのが「章の執筆再開」でした。2.9で長編対応の柱として入れた機能で、止まった作品を未完了の章から書き直せます。完成済みの章はそのまま残して、続きだけを書かせる。長編は生成時間が長いぶん、途中で何かが起きる確率も上がります。だから「事故ってもやり直しにならない」仕組みを先に用意しておいたのですが、それがこんなに早く、こんなに派手な形で役に立つとは思いませんでした。

もし同じ状況になったら、やることは2つだけです。

まず、小説ビューで「強制停止」を押します。応答が来ないまま固まっている作品は、これで正式に停止中になります。次に「続きから再開」を押す。すると次のダイアログが出るので、「最後まで生成」を選べば、止まった章から書き直しが始まります。

画面は8章の作品での例ですが、出るものは同じです。再開の前に、モデルや章数などの設定を確認できます。

私の場合もこの2操作だけでした。56章は2,720字で書き直され、57章、58章と何事もなかったように進んでいきました。復旧に使った操作は、ボタン2つ。時間にして10秒ほどです。25分固まっていた画面が、それで動き出しました。

再開が内部で何をしているのかは、この図のとおりです。完成済みの章の本文を、要約せずに全文読ませてから、未完了の章の続きを書かせます。完成した章は書き直されません。だから伏線や文体が途切れずにつながります。

詳しい使い方は、使い方サイトの再開のページにまとめてあります → https://inkubus.pages.dev/help/resume

夜のあいだに回すものですから、「ネットワークが一度も切れないことを祈る」設計では困ります。切れても失わない、続きから戻れる。そちら側に倒してあります。それが今回、いちばん派手な形で確かめられました。

この「続きから再開」は2.9で入れた機能で、今回の2.9.2とは別の話です。ただ長編を回すなら、空の章を勝手に書き直すのと、切れたところから戻れるのは、組で効きます。

100章、書き切りました

完走です。100章、本編223,260字。総計228,581字。

目標の25万字には届きませんでしたが、22万字。ライトノベル2冊分と言っていたのは、だいたいそのとおりの量になりました。ローカルLLMが一晩どころか、2時間足らずで2冊分を書いたわけです。

空で終わった章はゼロ。1章あたり平均2,233字で、いちばん短い章が1,827字、長い章で2,859字でした。最後まで書く量が落ちていません。

生成時間は1時間15分。ただし途中の25分は応答を待っていただけなので、最初にボタンを押してから完成までは1時間44分かかっています。

速度は前半50章が58.2字/秒、後半50章が46.3字/秒でした。2割ほど落ちています。章が進むほど読ませる量が増えるので、後半ほど遅くなります。それでも落ち方はゆるやかで、どこかで急に崩れることはありませんでした。

目標の25万字に届かなかったのは、1章2,500字の目安に対して実際が2,233字だったからです。1章267字の差が、100章ぶん積み上がりました。残りは1章あたり267字ぶんの話なので、そう遠くはありません。ただ今回は、22万字を2時間かからずに書き切ったという事実のほうが、私には驚きでした。

ついでに分かったこともあります。22万字の作品を1ページに全部ぶら下げても、Chromeは普通に動きました。さすがに操作は少し重くなりますが、読めなくなるほどではありません。

ダウンロードしてメモ帳で開くと、文字数のカウンタが225,993を指しました。

残る課題

物語そのものは、こちらの意図どおりに書いてくれました。ただ、モデル自身が立てたあらすじのとおりには書いていません。

Inkubusは本文を書く前に、章ごとのあらすじを作らせます。20章くらいの作品なら、11章のあらすじに書いたことが、ちゃんと11章の本文になります。

100章では、そうなりませんでした。37章のあらすじは「コスメティックルージュが罠にかかる」。ところが本文の37章では、彼女はもう敵の本拠地にいて、辱めを受けています。予定より先に進んでいる。

破綻はしていません。前後のつながりは取れていて、読めば話は通ります。ただ後半のあらすじは、設計図としてはもう当てになりません。

ここは制御の仕組みが要りそうです。ローカルLLMで長編を書かせるのは、なかなか奥が深いです。

入手について

Inkubus 2.9.2は、noteのメンバーシップ「AI活用実践ラボ」限定で配布します。次の正式販売版はv3.0を予定していて、2.9系はその前にメンバーの方へ先に触ってもらう版、という位置づけです。

メンバーシップは月500円です。入るとできることを並べておきます。

• この記事の続きが読めます。2.9.2本体のzipと、アップデートの手順です

• 過去のメンバー限定記事も全部読めます。Inkubusは2.8(ベンチマーク)からこの形で先行配布していて、2.9(長編対応)のzipもメンバー限定記事に付いています

• ツール以外のメンバー限定記事も読めます。ローカルLLMの検証や、AIツールを実際に売ってみた実績の話など、このアカウントで試したことの中身側です

単品購入でお使い希望の方は、2.7が最新の正式配布版です。こちらは引き続きこの記事から。

🟥 ここからメンバーシップ限定

ダウンロード