クラウドAIに際どい創作を頼んだら、内容が骨抜きにされて返ってきた……そんな経験はないでしょうか。「もっとハードボイルドに」と粘っても、最終的に出てくるのは当たり障りのない優等生的な文章ばかり。今回は、そのフラストレーションを出発点に、セーフティに邪魔されず思い通りの物語を書けるAIを、ローカル環境に自作した記録です。ただし先に言っておくと、これは一直線の成功譚ではありません。モデル選びでの空振り、検閲を外した先に待っていた別の問題、VRAMとの静かな消耗戦——地道な試行錯誤の連続でした。良かった点も悪かった点も含めて、そのまま書いていきます。
きっかけ：方向転換の経緯
もともとは、CursorやClaude Codeのような、ローカルのファイルを直接編集するタイプの「バイブコーディングツール」を開発していました。ところが途中で方向を変え、GeminiのGemのような「カスタムAIエージェントをローカルに再現し、ユーザーが与えたプロットから物語を生成する」仕組みの開発に切り替えることになりました。
きっかけは単純で、クラウドAIに創作を依頼するたびに、セーフティや利用規約の制約で「本当に書きたいもの」が書けないというフラストレーションが積み重なっていたためです。今回の記事は、そのフラストレーションをどうローカル環境で解消しようとしたか、という記録になります。
最初の壁：ひとつのモデルに全部やらせる限界
最初に組んだ構成は、単一のモデルに「物語生成」「英訳」「画像生成プロンプトへの変換」をまとめて任せるというものでした。しかし早い段階で限界が見えてきました。タスクを詰め込むほど出力が安定せず、物語としての質も頭打ちになっていく感触があったのです。
そこで踏み切ったのが、2段階のパイプライン化です。Stage1では物語生成に専念するモデルを、Stage2では英訳と構造化変換に専念する別のモデルを割り当て、役割そのものを分離しました。
これは単なる小手先の工夫ではなく、この記事全体の背骨になる設計思想だと考えています。「創作が得意なモデル」と「指示に忠実に構造変換するのが得意なモデル」は、そもそも求められる資質が違います。前者に必要なのは指示から”はみ出す”独創性で、後者に必要なのは”はみ出さない”忠実さです。ひとつのモデルにその両方を求めるのは、作家に校正者の仕事まで完璧にこなすよう求めるようなものだと感じています。この「餅は餅屋」の発想は、今回の物語生成パイプラインに限らず、AIエージェント設計全般に応用できる考え方だと思います。
モデル探しの旅、その1：ゴルゴ13を頼んだらアンパンマンが来た
Stage1（物語生成担当）のモデルを選ぶ過程は、ハードボイルドな成人向け作品を頼んだつもりが、牙を抜かれた児童向けアニメのような当たり障りのない展開しか返ってこない、という状況の繰り返しでした。
具体的には、あるモデル（Qwen3系）にStage1を任せたところ、同一のプロンプト指示にもかかわらず、出てくる描写は「手をつなぐ」「シャツ越しの鼓動を感じる」程度にとどまりました。一方で別のモデル（Gemma4系）に同じ指示を与えると、はっきりと踏み込んだ描写が返ってきました。これは「プロンプトの書き方が弱い」という問題ではなく、モデル自体が持つ表現の天井の違いだったと突き止めました。
ここでの教訓は、検閲やセーフティの強さはモデルによってまったく異なり、プロンプトの工夫だけではどうにもならない「地力の差」が存在するということです。
モデル探しの旅、その2：今度は平安貴族の歌合せ問題
検閲の緩いモデルにたどり着いても、それで解決とはなりませんでした。今度は、赤裸々な描写を求めているはずなのに、出てくるのは「二人は一つになった」「熱い夜が二人を包んでいった」といった、婉曲で詩的な表現ばかり——まるで平安貴族の歌合せのような雰囲気になってしまったのです。
この問題は、指示の作り方を「何が起きたかを名指しで書かせる（NAME）」形から、「その場で実際に起きていることを、具体的な動作や感覚として描写させる（DESCRIBE）」形に組み替えることで解決しました。検閲を外すこと自体は、望んだ出力を保証してくれるわけではない、という気づきがここでの収穫です。
検証のコツ：「同じ土俵」で比較しないと意味がない
候補モデルが3つ、4つと増えていく中で、比較のやり方そのものにも工夫が必要だと気づきました。毎回違うお題でモデルを試していると、出てきた差が「モデルの実力差」なのか「お題の難易度差」なのか区別がつかなくなるためです。
そこで、同一のキャラ設定・同一のシチュエーションを使った共通のテストプロンプトを全候補モデルに投げ、出てきた物語の質や癖だけを見比べる方法に切り替えました。条件を揃えたABテストです。この方法は、読者が自分で複数のモデルを試す際にもそのまま応用できると思います。
検閲外しの副作用：謎の「……」中毒事件
検閲の緩いモデルに乗り換えた先で、また別の壁にぶつかりました。今度はセリフが「……」（三点リーダー）まみれになり、感情表現が具体的な言葉ではなく記号の羅列に置き換わってしまう、という奇妙な癖です。
しかもこの症状は、系統の異なる複数のモデル（同じベースモデルの派生や、別の作者による派生）で共通して見られました。検閲解除の処理そのものが、こうした癖を副作用として持ち込みやすいのではないか、というのがここでの見立てです。
プロンプト側での是正を何度も試みましたが決定打にはならず、最終的に効いたのは「記号に頼らず、具体的な言葉と身体の動きで感情を描写せよ」という、シンプルな一言でした。それでも正直に書いておくと、一部のケースはプロンプトの言葉だけでは直りきりませんでした。指示文をどれだけ工夫しても、モデルの癖そのものを完全には矯正できないというのが、プロンプトエンジニアリングの限界だと感じています。その保険として、明らかに壊れた「……」の連鎖をコード側で機械的に検出し、修正する後処理を追加しました。プロンプトさえ頑張れば何でも解決する、というわけではありませんでした。
ローカルモデルとの戦い：トークン単位で壊れる出力ともぐらたたき
ローカル、特に量子化されたモデル特有の問題として、決められた出力フォーマットの一部が単発的に壊れる現象に何度も遭遇しました。見出しの1文字だけが別の単語にすり替わる、余計な文字が紛れ込む、指定した英単語が別の綴りに化ける、といった具合です。
中でも印象に残っているのは、1回の生成で2つの異なる壊れ方が同時に発生し、片方の壊れがもう片方の自動修復ロジックまで狂わせて、本来無関係のはずのページまで巻き込まれて消えてしまった、という連鎖的な不具合です。クラウドの最先端AIを使っている間は意識しなくてよかった「ランダムな細かい破損」に、ローカル運用では日常的に向き合う必要があります。だからこそ、多少の表記ゆれや破損があっても内容を救い出せる設計が重要になってきます。
ハードウェアのリアル：VRAMとの静かな戦い
華やかなチューニングの裏側で、常につきまとっていたのが地味だが切実なVRAMの問題です。モデルのサイズとグラフィックボードのVRAM容量がぎりぎりで収まりきらないと、あふれた分がCPU側にオフロードされ、生成速度が本来の1/50近くまで落ち込むことを実測で確認しました。
ローカルで理想のモデルが見つかっても、動かせるとは限らない——これが読者にとっていちばん気になる現実的な部分だと思います。量子化を強めて軽量なモデルを選ぶか、速度を犠牲にしてでも高品質な量子化を選ぶか、というトレードオフの判断も、この段階で必要になってきます。
自分の指示文がブーメランになった話
ここからは、少し自爆気味のエピソードです。出力フォーマットの説明のために、ルール文の中に「もっともらしい実例」を書いていたところ、モデルがそれを正解だと勘違いし、新しく書くべきストーリーの中にその実例をそのままコピーして出力してしまいました。
ここでの教訓は、ルール説明に使う例文は、あえて「絶対に本物のセリフには見えない、明らかにダミーだとわかるもの」にしておくべきだ、ということです。もっともらしい実例ほど、モデルに拾われるリスクがあります。
まさかの真犯人は自分だった：原因不明バグの正体
何度直しても再発する不可解なバグに、何日も悩まされた時期がありました。AI側のコードを疑い、プロンプトを疑い、モデルの癖を疑い……そのたびに対策を打っても直りませんでした。
最終的にたどり着いた真相は、AIの不具合ではなく、自分自身が使い回していた入力テンプレートの中身が、そもそも壊れていたというオチでした。「AIが変な出力をした」と思ったときは、まず自分の入力を疑ってみる価値がある、というのが正直な教訓です。
勘に頼らない：実データでチューニングする
セリフのリズムや「……」の使用頻度のようなものは、感覚だけで「多い／少ない」を判断しがちですが、それでは基準があいまいになります。そこで、実際に使われた本物のセリフ100行を測定し、基準値を作るところから始めました。
単に「プロンプトを書いて祈る」のではなく、実測に基づいてチューニングする、という姿勢がここでの狙いです。
たどり着いた場所：理想に近づいた物語生成システム
現時点での到達点は、次のようにまとまります。
- 複数の候補モデルを切り替えて比較できる仕組みを持ち、物語のクオリティを継続的にABテストできる状態になっている
- 出力の品質チェックと自動リトライの仕組みを持ち、壊れた出力を検知して自己修復する
- プロンプトだけに頼らず、コード側の機械的な後処理も組み合わせている
- クラウドAIのセーフティに阻まれることなく、思い通りの物語を安定して生成できるようになっている
クラウドAIのセーフティに創作を阻まれていると感じている方へ——ローカルであれば、それは可能です。ただし「モデルを1つダウンロードして終わり」ではなく、相応の試行錯誤が前提になることも、正直にお伝えしておきたいと思います。
まとめ
方向転換から始まり、単一モデルの限界と役割分担の発想、モデル探しの苦労と検証方法、検閲外しの副作用とプロンプトの限界、ローカル特有の不具合とハードウェアとの戦い、自分自身への疑い、データドリブンな改善、そして現在の到達点——ここまで振り返ってきました。
セーフティに縛られた創作に不満を感じているなら、ローカルという選択肢があります。ただしそれは銀の弾丸ではなく、根気強いチューニングが前提になる、というのが今回の記録から得た、いちばん正直な結論です。
