【Inkubus 3.4リリース】「1章7,000字で書いて」を無視するローカルLLM。AI小説の1章を1万字まで書かせる仕組みを作りました

Inkubusの新しいバージョン、3.4ができました。

今回は機能を1つに絞っています。1章を、指定した字数まで書かせる機能です。

ローカルLLMで小説を書いたことがある方なら、たぶん一度は見ています。「1章7,000字で」と頼んだのに、3,000字くらいで章が終わってしまうあれです。

発端は、購入してくださった方からのお問い合わせでした。同じ内容のものが3件。「1章の字数を7,000字にしても、3,000字くらいしか出ない」。

要望をくださった方、ありがとうございます。そして、それだけ長い章を書かせたくなるくらい使い込んでもらえているのが、素直にうれしかったです。

調べてみたら、アプリの不具合ではありませんでした。いまのローカルLLMそのものの限界です。なので、アプリの側で解決策を作りました。

今回はソフトが何であれローカルLLMで小説を書こうとしている人、書いている人にも参考になると思います。

Inkubusとは

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

Inkubusは、ローカルLLMに自由な題材の小説を書かせるブラウザアプリです。ロールと設定を決めて実行すると、あとは勝手に書きます。寝ているあいだに回して、朝に読む。そういう使い方を想定して作りました。

生成も保存も全部手元のPCで完結して、クラウドには送りません。だから題材の自由度が高く、ChatGPTやClaudeでは書きにくいエロ小説も扱えます。

基本の使い方は、こちらの動画(2分)にまとめてあります。

3.3までに入っている主な機能は、このあたりです。

• 夜間バッチ量産。ロールと制約を決めて回すだけで、朝にはライブラリに作品が並びます

• キャスト。キャラクターの画像から登場人物の描写を起こして、何度でも使い回せます。3.3では学生証も作れるようになりました

• 拡張。完成した1本を種に、続編とおまけを派生させられます

• ひらめき。作品案そのものをAIに出してもらう画面です

• 長編対応(2.9)。100章22万文字を実際に書き切っています

• 製本(3.0)。縦書きのEPUBにして、Kindleに出す準備までできます

• think OFFと検索キーワード(3.1)。生成時間がほぼ半分になる設定です

動かすのに用意するものは2つだけ。Node.jsとOllamaです。セットアップが済めば、インターネットにつながっていなくても動きます(OllamaをそのPCで動かしている場合)。

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

単品の販売記事はこちら

ここからv3.4の話です。

ローカルLLMは1回で出力する文字数に限界がある

まず何が起きていたか。

Inkubusは、1章の目安の字数をそのままモデルに伝えています。「約7,000字の本文」と。ところがモデルは、そこまで書かずに章を締めてしまいます。

Gemma 4で測ったところ、1回の返事はおおむね2,000〜3,000字でした。31bは長めに書くモデルで、4,000〜5,000字書くこともあります。それでも7,000字には届きません。

字数を指示しても、無視される

最初は、頼み方の問題だと思っていました。なので、アプリを通さずに素のプロンプトで試しています。

「7000文字の小説を書いてください」と頼むと、8本中8本が、書く前にこう返してきました。「一度の回答で7000字は困難です(通常2,000〜3,000字)」。

考える過程(think)をONにすると、その中身も見られます。そこには英語で「I cannot write 7,000 characters in a single response」と書いてありました。字数を指示しても、それを無視して途中で閉じてしまう。いまのローカルLLMモデルの限界です。

「出力の長さに制限はありません」と先に伝えても、4本中3本は断ってきました。制限の話を出すと、かえって断りを呼ぶようでした。

num_predictを大きくしても伸びない

よく言われる対策に、Ollamaのnum_predict(出力の上限)を大きくする方法もあります。

これも試しました。12bと26bで、num_predictを指定しない場合と16,384にした場合を3回ずつ。どの回も7,000字に届かず、全部モデル自身が書き終えて止まっています。上限で切れた回は1回もありませんでした。num_predictは「ここで打ち切る」という上限で、それ以上書かせる設定ではないからです。

(2026年9月に計測。手元のPCのOllama 0.34.4、コンテキストサイズ32,768)

調べてみると、これは論文でも扱われている既知の現象でした(LongWriterなど)。頼み方だけでは越えられない、という結論です。

分けて頼めば、長さは仕切り直される

ただ、ひとつ抜け道がありました。

返事を新しくすると、書く長さはそこで仕切り直されます。1回で7,000字は書けなくても、2,000字を何回かなら書ける。

なので3.4では、1章を何回かに分けて頼むことにしました。書き始め、続き、続き、締め。書き上がった回を順につないで、1つの章にします。

何回に分けるかは、先に決めていません。モデルごとの表も持っていません。1回書き終わるたびに、書けた字数を見てその場で決めます。モデルは増え続けるので、モデル名で決めるやり方はすぐ破綻するからです。

つないだあとの後始末もしています。「(つづく)」のようなラベルや、2回目以降に重なって出てくる章の見出しは、落としてから保存します。

解決作を簡単に言うと・・

簡単にいうと「最初から1チャットにつき3000文字ぐらいしか書けない」ことを前提に作る感じです。

また既存の動きには影響しないよう慎重につくっています。

実測

1章7,000字 × 3章で、分けない場合と比べました。

(2026年9月に計測。RunPodのRTX PRO 4500、think OFF、コンテキストサイズ32,768。字数は空白と改行を除いて数えています)

• 26bは、分けないと1,611〜2,057字。分けると6,927〜7,010字

• 12bは、分けないと2,014〜3,205字。分けると6,928〜7,509字

• 31bは、分けないと2,633〜4,309字。分けると6,910〜7,278字

どのモデルも、目安の9割を超えました。

その代わり、時間は長くなります。1章あたり約1.8〜4倍で、モデルによって違います。書く字数が増えるぶんがほとんどで、1秒あたりに書く速さはほとんど変わりませんでした。

この記事用に、1章1万字 × 3章も31bで書かせてみました。空白を除いて9,722字、10,112字、10,202字。どの章も目安の1万字にほぼ届いています。本文のリクエストは合計16回(分けずに書けば3回)で、全体で6分50秒でした(RunPodのRTX 5090)。

話が先へ進みすぎる問題

分けて書けるようになってから、もうひとつ問題が見つかりました。

1章を5〜6回に分けて書くと、あらすじの2章の出来事まで、1章で書いてしまうことがありました。3作品で試して、3作品ともです。1章が「勝って街の希望になる」だけのはずが、1章の終わりには敗北して捕まっている。そうなると後ろの章も連鎖して前倒しになり、最後の章では書くことがなくなって、結末を何度も書き直していました。

原因は頼み方でした。回ごとに「次の場面へ続く形で終えてください」と頼んでいたので、モデルは毎回、場面を1つ書き切って引きで終えます。回の数だけ、話が進んでいたんです。

なので回ごとに、この章で書くあらすじの範囲と、ここまでに書いた字数を伝えるようにしました。「この章で書くのはここまで」「次の章の出来事は次の章で書きます」「ここまで約3,500字書きました」。直したあとは、どの章もあらすじの自分の章に収まりました。

あらすじが薄いぶん、くどくなることがある

いまのあらすじは、1章あたり1〜2行しかありません。

12bや26bは、1回に書く量が少なくて、1章を5〜6回に分けて書きます。すると材料が足りなくなって、同じ描写の言い換えや、回の終わりの「彼女たちはまだ知らなかった」のような一文が増えます。くどく感じることがあります。

いまのところ、この機能を使うならGemma 4の31b(gemma4:31b-it-qat)がおすすめです。1回に書く量が多いので、1章7,000字なら3〜4回で書き終えます。あらすじにない、つなぎの場面を自分で足すので、いちばん自然に読めました。

31b以外で使うときは、制約の欄に章ごとのあらすじを自分で詳しく書いておくと、くどさが減るかもしれません(まだ試していません)。

今のところ1章7000文字ぐらいだとGemma4-31b-qatだと高品質な小説を書きます。1万文字になるとはやり、あらすじに対して1万文字はあらすじがおいつかないのでくどくなります。

使い方

新規実行画面で、1章あたりの字数を決めて、その下の「1章の字数を強制的に守らせる」にチェックを入れるだけです。既定はOFFで、OFFのときの生成はこれまでと何も変わりません。

分量の欄も変えました。これまでは本編の合計の字数しか打てませんでしたが、「章数 × 1章あたり = 本編」の形になっています。「1章7,000字 × 3章」も「10万字を30章で」も、考えた方をそのまま打てます。

書き上がった作品では、何回に分けて書いたかが見られます。小説ビューの統計の「詳細」に、章ごとの回数と、回ごとの字数が出ます。「本文に回の境目を表示する」にチェックを入れると、本文の中の境目に点線が出ます。

上の画像は、1章の1回目と2回目の境目です。1回目は勝利のあとの「嵐の前の静けさ」で終わって、2回目は「数日後」から始まっています。つなぎ目で話が途切れたり、同じ文が2回出たりはしていません。

他の作品の例

ただ強引にしているだけなので、素の1チャット＝１章に比べたら変になる確率は高いです。そこは認識しながら試してみてください。
フィードバックお待ちしております😊

仕組みと実測は、使い方サイトに図つきでまとめています。

入手について

この記事でInkubusを初めて知った方へ

単品で買えるのはInkubus 3.0です。小説を書かせて、製本して、Kindleに出す準備をするところまで入っています。この記事に書いた1章の字数の機能は入っていません。まず単品で触ってみたい方はこちらから。

3.0の記事は買い切りで、その版で固定です。3.4の機能は入りませんし、あとから足されることもありません。動かなくなるような不具合が見つかったときだけ、直したものに差し替えます。

3.4と、これから先はメンバーシップから

Inkubus 3.4は、noteのメンバーシップ「AI活用実践ラボ」限定で配布します。この記事の続きに本体のzipとアップデートの手順があります。

• 加入中はこの記事の続きから3.4本体を受け取れます。3.3以前の版もまとめて

• 今後の版も、出るたびに追加課金なしで受け取れます

• ネタ出しとプロット作りのMycelink、キャラクターの画像からComfyUI用のプロンプトを作るPixubusも、同じところから手に入ります

• メンバー限定の掲示板があります。要望や不具合はそこでも受け付けています

ツールはInkubusだけではありません。アイデアを広げてプロットにするMycelink、キャラクターや挿絵の画像を作るPixubus、本文を書いて本にするInkubus。3つで「思いついてから本にして世に出すまで」が繋がるように作っています。全部、あなたのパソコンの中だけで動きます。

Mycelinkで枝を広げたプロットをInkubusに貼れば本文になり、Pixubusで作ったキャラクターの絵はそのまま表紙や口絵に使えます。この流れをまるごと揃えられるのがメンバーシップです。

Pixubusは、キャラクターの画像からComfyUI用のプロンプトを起こして、そのまま画像生成までできるツールです。Inkubusと同じくローカルで動きます。

今回の機能は、購入者の方の要望から生まれました。要望や不具合は、この記事のコメント欄か、メンバーシップの掲示板までどうぞ。返信はベストエフォートです。

細かい変更は変更履歴の3.4.0に並べてあります → https://inkubus.pages.dev/help/changelog#v340

ここから下がメンバーシップ限定です。中身は次の3つ。

• Inkubus 3.4本体(zip)

• 3.3からのアップデート手順

• 画面つきの使い方と、作例の深掘り

Inkubus v3.4 ダウンロード