生成AIによる産業革命とも呼べる嵐がネットもリアルも世界中を席巻しています。
私がWebディレクターとして仕事しているWeb制作業界はその最前線。
それっぽく見える程度のサイトでいいのなら、AIが10分で作ってくれるようになりました。
コーディングやデザインなどの従来は人間が担当していた制作工程の一部をAIが担うようになってきています。
一方で、私は「小説家になろう」で活動するなろう作者でもあります。
SNSの創作界隈においてはアンチ生成AI派による成果物叩きが活発ですが、小説もそう。
AI小説つまらない！
こんなポストを見かけたのは一度や二度ではありません。
しかし、AI小説は本当につまらないの？
Garbage in, Garbage out（ゴミを入れればゴミが出てくる）ってだけじゃね？
自分で検証すべく、生成AIに小説を書かせてみました。
結果は、
（条件付ながら）面白い！
読み出して止まらなくなって、40話一気に作ってしまいました。
つまらなかったら40話も作るわけありません。
この行為自体が「少なくとも私がAI小説を面白いと思った」証拠になるはずです。
本稿では、私がどのようにしてAIに小説を書かせたか。
マニュアル化したものと、それを作り上げるまでの経緯について記します。
結論：私のAI小説の作り方
基礎資料4点を用意する
用意するのは、次の資料です
- production_rules.md ― AIに守らせる制作ルール
- character.md ― キャラクター設定（テキスト）
- world.md ― 世界・舞台の設定
- キャラクタースタイルシート ― キャラクター設定（画像） ※小説だけなら必須ではない
これらを、
- ChatGPTならプロジェクトの情報源
- GeminiならGemini Notebookのソース
に参照資料として登録します。
役割はざっくり、
工程数を省略するため
毎回決まっているルール・作品設計・世界・キャラクターを毎回プロンプトに書くのはムダですよね？
先に登録しておけば、AIは作業のたびにこれらを参照すればすみます。
Web制作業界の方だと、こう思うかも。
サイト作るのと同じじゃん！
design.mdを用いたサイト制作手法がトレンドですしね。
似たようなものだと思います。
サイト制作にとどまらず、広範なプロジェクトに応用できるのではないでしょうか。
基礎資料の内容
production_rules.md
AIに小説を書かせる際の制作ルールをまとめたファイルです。
作品の基本構成、生成時の原則、避けるべき展開や表現などを定義します。
character.md
登場人物の性格・口調・役割・人間関係などをまとめたキャラクター設定です。
話数を重ねても、同じ人物が同じ人物として行動・会話するための基準になります。
world.md
会社や職場環境など、物語の舞台・世界観・共通前提をまとめたファイルです。
AIが話ごとに設定を作り直したり、過去の設定と矛盾したりするのを防ぎます。
キャラクタースタイルシート
登場人物を「同じ人物」として描き続けるための設定資料です。
名前、年齢、外見だけでなく、性格、口調、考え方、役割、他の人物との関係などをまとめます。画像生成も行うなら、正面・横・表情・衣装などのビジュアル資料もここに加えます。
GitHubで制作資料を一元管理する
必須ではありませんが、AIで作業するなら推奨します。
私は制作資料の正本をGitHubで管理しています。
ChatGPTやGeminiなど複数のAIを使う場合、それぞれに別々の設定資料を作ると、どれが最新版なのか分からなくなります。
そのため、
「GitHub＝制作資料の正本」と決めています。
ChatGPT：プラグインでGitHubと同期できます。
Gemini：GitHubリポジトリを直接インポート（同期ではないので、必要なら都度インポートが必要）。
先の資料4点のほか、管理用のrules.mdを置きます。
rules.mdの中にファイル命名規則や配置を記します。
実際に私が使用しているリポジトリの一部がこちらです。
先述の資料4点はreferenceの中に入れています。
colorful-works/
├─ rules.md
├─ reference/
│ ├─ characters/
│ ├─ world/
│ ├─ rules/
│ └─ history/
├─ novel/
├─ storyboard/
├─ manga/
├─ work-memo/
└─ docs/
作成手順
- AIに適当なプロットを作らせる
- AIにプロンプトとしてコンパイルさせる
- AIにプロンプトを投げる
これだけです
プロットもプロンプトも、ほとんど工夫していません。
作成話数が進むに従って細かい調整は入れましたが、基本的には「次の話のプロンプトよろしく」とChatGPTに投げてました。
少なくとも当時は、私がテーマや事件を考えていたわけではありません。
つまり、「神プロンプト」を作ったわけではありません。
私が工夫したのは作業工程全体の最適化です。
成果物：AI小説「からふるわーくす第11話」
※上掲手順で生成したほぼそのままです。当サイト掲載の11話とは内容が異なります。
AIの書いた小説を読む
① 状況提示
からふるわーくすのオフィスに、任野の弾んだ足音が響き渡った。
任野がデスクにドンと置いたのは、何十ページにも及ぶ立派な冊子だった。
小田は手元のマニュアル用ノートを置き、その資料をめくった。
見事な表紙、整然と並ぶ目次、豊富な三色刷りの図表、そして「AI活用による業務効率化」の文字。
任野が「お任せください！」と言わんばかりに胸を張る。
デスクの横を通りかかった小田も、「へえ、AIでここまで綺麗にフォーマットが組めるんだ……最近の技術は本当に凄いね」と、最初は感心したように頷いていた。
「……確認します」
いつの間にか資料を引き寄せていた言葉が、青みを帯びたアッシュグレーのショートボブを揺らし、静かにページを捲り始めた。
ピタ、と。
言葉のノートPCを叩く手が止まった。
その切れ長の目が、ディスプレイではなく紙の資料の一点に注がれている。
任野が覗き込む。
言葉は表情を一切変えないまま、感情を排した声で、資料の一部を淡々と読み上げ始めた。
しかし、全体を一本のシステムとして見たとき、決して両立し得ない致命的な矛盾が、立派な図表の裏側に大量に混在していた。
「で、でも……！」
任野が焦ったように、営業資料を抱え直しながら反論した。
「これ、最新のAIが綺麗にまとめたんですよ？ AIって、すごく頭が良いんじゃないんですか……？」
言葉がスマホをデスクに置き、淡々と言葉を返した。
「クライアントが入力した『欲しい機能』を、綺麗にカテゴリー分けして、見栄えの良い日本語のドキュメントに変換しただけです。AIは、要求同士の依存関係や、どちらを諦めるべきかという『優先順位』の意思決定までは行いません。入力されたものを、すべて全肯定して全部盛りしただけです」「利用者様にとっても、全部盛りは必ずしも幸せではありませんわ」
絵森が、ラベンダー色のスカートを揺らしながら、悲しげに画面を見つめた。
「機能が多すぎて迷路のようになったサイトは、どんなにデザインが美しくても、心が動きませんもの。これでは、誰も『ときめかない』システムになってしまいますわ……」
小田はついに、デスクの上の胃薬（胃苓湯）の瓶を掴み、よろよろとホワイトボードの前へと歩き出した。
「任野ちゃん。お客様は『完璧な仕様書ができた！』って大喜びなんだよね？」
「はい……『これでもう見積もりも開発もすぐいけるよね！』って……」
「よし、一旦、この『全部盛り仕様書』を人間の言葉に翻訳し直そう。このまま作ったら、誰も幸せにならないお化けシステムができちゃうからね」
小田はホワイトボードに、大きな3つの円を書き始めた。
「いい？ AIが作ってくれたこれは、要件定義書じゃないんだ。ただの『要件候補集』なんだよ」
「AIは矛盾を検知して『どちらにしますか？』と冷たく問いかけることはできますが、クライアントのビジネスモデルや熱量を見て『今回はこちらを優先すべきです』と背中を押すことはできません。それは、感情と背景を理解できる人間にしかできない領域です」
翌日、小田と任野は、ホワイトボードの図を綺麗にまとめた「1枚の提案書」を持ってクライアントの元へ向かった。
「ここまで網羅的に要望を出していただき、本当に助かりました！ おかげで、御社が将来的に目指したいグランドデザインが完全に共有できました！」
「ただ、これらをすべて同時に実現しようとすると、システムがケンカをしてしまい、一番大事な『ITが苦手な現場の方でも、迷わず簡単に運用できる』という軸がブレてしまいます。ですので、まずはこの『絶対必要』な最小限のコアから形にしませんか？ 残りのAI機能などは、サイトが育った次のフェーズの楽しみに取っておきましょう！」
「あ、本当だ……。AIが綺麗にまとめてくれたから完璧だと思い込んでいたけど、僕たち、全部欲張って自滅するところだったんですね。確かに、本当に今必要なのは、このシンプルな購入導線と、簡単な更新機能だけだ！」
オフィスに戻り、無事にスコープが確定した新しい案件の構成案を見ながら、小田は買ってきたばかりのメロンパンを嬉しそうに頬張っていた。
任野が、すっかり元気になった笑顔でタンブラーを傾ける。
言葉が、キーボードを小気味よく叩きながら言った。
絵森が優しく、ゆるふわの髪を揺らす。
小田はメロンパンを飲み込み、そっと自分の胃のあたりをさすった。
「AIが考える材料を大量に出してくれるから、私たちの仕事は格段に効率化された。でもね――」
私の方法のメリット
制作品質を安定させられることです
面白いと思うかは人それぞれでしょう。
ただ、最後まで読める水準にはなっているはずです。
40話作り通しても、この品質で安定して生成できました。
本編の前置：小説家になろう作者としての私
ここから記事本編となります。
まずは前置きを記させていただきます。
私は10年以上、小説家になろうで活動しています。
一応、日間総合ランキング8位まで上がったこともあります。
当サイトの「きもおた」はこの作品からとったもの。
そもそも私がサイトを始めたのは、なろうで掲載を取りさげた作品を置く小説サイトとしてです。
残念ながら書籍化をしたことはありません。
ただし小説家になろうどころか商業小説家を含めてすら滅多にない、ガチレアな経験をしたことがあります。
なろう小説が週刊誌およびYahoo!ニュースになったことがあります
ドヤ顔でなく泣き顔なのは、嬉しいどころか「人生終わった！」と思わされた経験のため。
だって、ニュース……これですよ？
一般人をつかまえて「日本のスノーデン」ときたものだ。
事前に取材ありましたから載るかもとは思ってましたが、まさかこんな書かれ方しようとは。
ただ、このニュースがきっかけで、文壇から絶賛されました。
暴露小説ではなく、ミステリとして。
そこから出版オファーもあったのですが……残念ながら頓挫し、現在に至ります。
なので、
あくまで私は「なろう作者」です、「小説家」ではありません
この点は強調しておきたいと思います。
制約：本稿で言うところの「AI小説の面白さ」
冒頭で、AI小説「面白い！」と書きました。
ただし、次の（）書きが気になったはずです。
手放しで「面白い」と思ったわけじゃありません
40話通して作らせましたし読みましたから、決してつまらなくはありません。
ただ、商業出版の「お仕事ものライトノベル」その他エンタメものと比較して面白いと思ったわけではありません。
あくまで、
私の目的においては「面白い」と思ったんです
私がAIに小説を書かせた本来の目的は、
さらに
プロジェクトマネジメントを楽しく勉強するため
でした。
私がWebディレクターを始めたのは今年3月。
幸いにして「能力」は早々に認めていただけました。
しかし絶望的に「経験」が足りませんでした。
そのため、欲しかったのは定型的な教科書じゃありません。
Web制作会社で実際に起こりそうなトラブルを物語として読み、「自分ならどうするか」を考える。
そのための疑似体験教材が欲しかったんです。
また1か月経った頃には4個のサイトを手がけていたのもあり、今後もWebディレクターとして食べていけそうな自信もつきました。
そのためプロジェクトマネージャ資格をとって箔をつけたいと思うようにもなりました。
この目的に限って言えば、AI小説は十分に面白いものでした。
実際、私は楽しみながら40話以上を読み、その過程でPMについて考え続けることができました。
さらにその疑似体験は、狙い通り実務にもフィードバックされました。
ただし、
他人に「私の小説です」と言って読ませたいかとなると、話は別です
AIが生成した小説には、私なら書き直す部分がかなりあります。
実際に私自身がリライトしたからふるわーくす第11話はこちら。
さすがにサイトにはそのまま載せたくありません。
リライトしてからアップしています。
手前味噌ながら、まったくの別物と思えるのではないでしょうか。
例えて言うなら、
私のリライトが90点とするなら、AIは70点
ただし、私の目的に限定するなら、AIに90点をあげていい。
また、気楽に読み流したい人にとってはやはり90点だったりするかもしれません。
目的や好みに応じて左右されるくらいの品質にはなってると思います。
では、私はどうやって小説40話をAIで作ったのでしょう。
ここからは、実際の制作記録を時系列で振り返ります
AI小説制作記録
ここからは時系列順に、どのようにしてシステムを作り、改善していったかについて記します。
スタートは勉強のための「漫画」を作りたかった
先にも記しましたが、私がAI小説を作り始めたのは、なろう作者としてではありません。
Webディレクターとしての勉強のためです
しかも、そもそもは漫画を作ろうとしていました。
それも明後日の方向から話が始まりました。
ちゃっぴー、漫画で覚えるNuxtとか作れない？
Nuxtは現在のWeb制作におけるモダンフレームワークの一つ。
AIとの相性が非常にいいのが特徴です。
一昔前まではWordPressが圧倒的主流で、このサイトもWordPressで作っています。
しかし最近はNuxtなどに乗りかえる制作会社が増えており、私の職場もその一つです。
私は上流工程なので必ずしもコーディングを覚える必要は無いのですが、できるに越したことはありません。
しかし、
素直にVueの本を読んだ方が早いと思います
で話が一旦終わりました。
結局はコーディングって、自分で書いたり使ったりしないと覚えられないので。
しかしはたとひらめく。
プロジェクトマネージャ試験（PM試験、高度情報処理技術者試験）の教材として漫画書かせてみるのはどうだろう？
ChatGPT君。
PM試験と物語形式は相性いいかもですね
「こういう状況ならどう考えるか」の引き出しをどれだけ持ってるかが勝負のところありますから
まさにその引き出しのストックがほしいんだ！
しかし漫画を作るとなると重い……そうだ！
PM試験のストック増やしたいだけなら小説でもいいんだ！
小説ならテキストだけだし、AIなら簡単に量産してくれそう。
小説を試作してみる
設定や内容について、ざっと壁打ち。
ChatGPT執事に命じます。
壁打ちの内容を反映して、Geminiに投げるプロンプト作って
なぜGeminiか？
あくまで私の感覚ですが、当時はこんな感じの印象だったからです。
- ChatGPT：割と正確だけど冗長でつまらない。はみ出そうとしない。よく言えば模範生。
- Gemini：ハルシネーション吐きまくりで文脈落としまくりだけど、奔放で発想力がすごい。
- RakutenAI：とにかくお堅い。吐き出させるよりチェック向け。
- Claude：この時点では使ったことないのでよくわからない。（現時点では、画像以外の創作と一番相性いい印象）
ChatGPTが作ったプロンプトは以下。
プロンプトを見る
> あなたは優秀な業務小説作家です。
>
> 以下の条件で、1話完結の短編小説を執筆してください。
>
> 【目的】
>
> この小説の目的は娯楽だけではありません。
>
> 読者がITプロジェクトマネージャ試験（PM）や実務で役立つ「疑似経験」を積むことです。
>
> ただし、試験対策本のような解説は不要です。
>
> 物語を通じて自然に学べることを重視してください。
>
> 【世界観】
>
> ・現代日本
> ・小規模～中規模のWeb制作会社またはシステム開発会社
> ・全員女性
> ・空気感は日常系・ゆるい職場コメディ
> ・恋愛要素不要
> ・ハーレム要素不要
> ・百合要素不要
> ・悪役不要
> ・読後感は明るめ
>
> 【主人公】
>
> ・中堅Webディレクター
> ・技術も少し分かる
> ・経験はあるが万能ではない
> ・現場感覚が強い
> ・毎回少し胃を痛める
>
> 【登場人物】
>
> ・営業担当
> ・デザイナー
> ・コーダー
> ・クライアント担当者
>
> など必要に応じて登場させる。
>
> 全員善意で行動していること。
>
> 悪意のある人物は出さない。
>
> 【重要】
>
> 問題は必ず「誰かが悪い」ではなく、
>
> ・認識のズレ
> ・情報不足
> ・前提の違い
> ・立場の違い
>
> から発生させること。
>
> 現実の仕事に近い内容を重視する。
>
> 【今回のテーマ生成】
>
> 以下からランダムに1つ以上選んで題材にする。
>
> ・要件定義
> ・認識合わせ
> ・スコープ管理
> ・リスク管理
> ・品質管理
> ・ベンダー調整
> ・ステークホルダー管理
> ・AI活用
> ・見積もり
> ・炎上回避
> ・担当者変更
> ・仕様追加
> ・情報共有不足
> ・レビュー不足
> ・運用設計
>
> 【禁止事項】
>
> ・都合の良い天才キャラ
> ・主人公だけが正しい展開
> ・説教
> ・PMBOKの用語解説
> ・試験問題の引用
> ・不自然な専門用語連発
>
> 【構成】
>
> 1. 日常業務
> 2. 小さな違和感
> 3. 問題発生
> 4. 調査・会話
> 5. 解決
> 6. 主人公が少し学ぶ
>
> という流れにする。
>
> 【文字数】
>
> 1500～3000文字程度。
>
> 【最後に追加】
>
> 物語終了後、
>
> 「今日の業務メモ」
>
> という見出しで、
>
> ・今回の本質的な問題
> ・PM視点で重要だった点
> ・実務で応用できる考え方
>
> を200～300文字で整理する。
>
> ただし解説本のような文章ではなく、主人公のメモとして書くこと。
ChatGPTが強調したのは、「PM試験を教えるな」と「現実的な仕事を描け」を強く指定する。
AIは放っておくと説教臭い教材か、無意味な美少女会話を始めますから
AIには共通あるいは個別に応じた「悪癖」と呼べる習性があります。
そのため、小説生成でも次の点が大事となります。
AIの行動は制約ルールで縛りつける
以下は、「からふるわーくす」にまで現在も続く生成ルールです。
具体的にどんな内容を生成ルールに組み込んでいるか、参考になりましたら。
「全員善意で行動していること」、「悪意のある人物は出さない」。
これは、
- 気持ち良く、心に負担をかけず、ゆるゆる読めること。
- 読み終えた後は気持ちよく「学べた！」と思いたいこと。
- 仕事絡みのトラブルは「善意の人」同士で生じるのが多いこと。
後に「キャラを無能にしないこと」も付け加えています。
- リアリティ面で首を傾げさせないため。
- 物語に深みがなくなるため。
- 特定キャラにヘイトを集めさせないため。
プロンプトをGeminiに投げて出てきた小説第一号がこちらです
AIの書いた小説を読む
## 『それは仕様か、それとも「やさしさ」か』### 1. 日常業務
「あー、初夏の風が心地いい。これで締切さえなければ最高なんだけどな」
中堅Webディレクターの五反田（ごたんだ）は、お気に入りのマグカップを片手にデスクに座った。窓の外からは爽やかな風が吹き込んでいるが、彼女の画面に映るタスク管理ツールは、少しだけ爽やかさとは程遠い状態だった。
勤務先である「カラフル・ワークス」は、総勢8名の小さなWeb制作会社だ。メンバーは全員女性。社内の空気はどちらかといえば、猫のいるカフェに近い。
「五反田さーん、今度リニューアルする『ひだまりベーカリー』さんの進捗、どんな感じですかー？」
ひょっこり顔を出したのは、営業担当の市ヶ谷（いちがや）。人当たりが良く、クライアントの懐に入るのが天才的に上手いが、技術的な細かい話になると途端に目が泳ぐタイプだ。
「デザインは校了したから、今週からコーダーの目黒さんが実装に入ってるよ。予定通り来月末の公開で進められそう」
「わぁ、さすがです！ 期待してますねー！」
市ヶ谷はニコニコしながら自分の席に戻っていった。ここまでは、いつも通りの平和な日常だった。
—
### 2. 小さな違和感
午後、コーディング担当の目黒からチャットが入った。
『五反田さん、ひだまりベーカリーさんの「お知らせページ」なんですけど、これって店舗ごとのカテゴリ絞り込み機能、いりますよね？』
五反田は首を傾げた。
要件定義のフェーズでは、お知らせは「全店共通のニュースを時系列で出すだけ」というシンプルな仕様で合意していたはずだ。予算もミニマムである。
『要件定義の段階では不要って話だったけど、何かあった？』
『あ、いえ、営業の市ヶ谷さんから共有された最新のパンフレットを見たら、「新店舗オープン！」って大々的に書かれてて。3店舗展開になるみたいなんです。そうなると、お客さんは「どこの店舗のニュースか」知りたいんじゃないかなって。WordPressのタグ機能を使えば、私の方でサクッと追加できますよ！』
目黒は非常に優秀で、常にユーザー目線で考えてくれる「いい子」だ。
（サクッと追加、か……）
五反田の胃のあたりが、わずかにキュッとした。善意からの提案なのは間違いない。ただ、こういう「ちょっとした親切」が、後からボディブローのように効いてくることを、彼女は経験上知っていた。
—
### 3. 問題発生
嫌な予感は的中する。翌日、市ヶ谷から「大変です！」とチャットが飛んできた。
「ひだまりベーカリーのオーナーさんから連絡があって……『店舗ごとにお知らせを絞り込める機能がつくんですよね？ 楽しみにしてます！』って言われちゃいました！」
「えっ？」五反田は目を見開いた。「市ヶ谷さん、それ確定を出したの？」
「いえ！ 私は言ってないんですけど、先週の打ち合わせの雑談で、オーナーさんが『店舗が増えるから、お知らせがごちゃ混ぜになると見にくいかも』ってポロッとおっしゃって。そこに同席してた目黒ちゃんが『あ、それならタグ機能とかで簡単に分けられますよ！』って答えてたんです。オーナーさんはそれを『やってくれるんだ』って受け取っちゃったみたいで……」
目黒の「サクッとできます」という技術的な見通しと、オーナーの「欲しい」という要望が、市ヶ谷のいないところで直結してしまっていたのだ。
しかも、オーナーはすっかりその気になり、すでに店舗別のニュース原稿を準備し始めているという。
—
### 4. 調査・会話
五反田は目黒と市ヶ谷を集めて、ミーティングスペースで話し合いを持った。二人とも「良かれと思って」動いた結果なので、すま痛そうな顔をしている。
「ごめんなさい、五反田さん。私、実装の手間だけで言えば1時間もかからないから、サービス精神のつもりで言っちゃって……」と目黒。
「私も、二人が直接話してる時に『それは別料金です』って水を差すようなことが言えなくて……」と市ヶ谷。
悪者は誰もいない。ただ「前提」がズレていた。
目黒は「プログラムを書く手間の少なさ」だけを見ていた。
市ヶ谷は「クライアントとの関係性を壊さないこと」を最優先にしていた。
「二人とも、責めてるわけじゃないから大丈夫。ただね、目黒さん。システム的には1時間で追加できても、運用するオーナーさん側の画面はどうなる？」
「えっ……あ」目黒がハッとした。
「これまでは『タイトルと本文を入力して公開』だったのが、『適切な店舗タグを選んでから公開』になるよね。もしタグを選び忘れたらどう表示される？ 過去の記事にも全部タグをつけ直さなきゃいけない？」
「あ、そっか……。マニュアルの修正も必要だし、オーナーさんはITがあまり得意じゃないから、投稿画面が複雑になると迷っちゃうかも……」
五反田は頷いた。
「そう。目黒さんの優しさは素敵だけど、仕様を追加するってことは、開発費だけじゃなくて『運用コスト』や『検証の手間』も増えるってことなんだよね。市ヶ谷さんも、その場の空気を壊したくないのは分かるけど、その『やさしさ』が結果的に予算やスケジュールの首を絞めることがあるの」
—
### 5. 解決
「じゃあ、オーナーさんにはお断りする方向で話してきます……！」
市ヶ谷が申し訳なさそうに立ち上がろうとしたが、五反田はそれを止めた。
「待って。オーナーさんはもう期待してるし、3店舗に増えるなら、実際にその機能はあった方が便利なのは確かだよ。だから、こういう提案に切り替えよう」
五反田はホワイトボードに、シンプルな構成案を書いた。
「今回は、当初の予算とスケジュールのまま進める。ただし、目黒さんが言ってくれた通りWordPressの標準機能で対応自体は可能だから、将来的に運用が落ち着いた段階で『フェーズ2』として有償で機能開放する。今回の納品時は、混乱を避けるためにあえて投稿画面からはその項目を隠しておく。これでどうかな？」
これなら、今回の納期（スケジュール）は守られ、追加の検証コストも発生しない。クライアントも「将来的に実現できる」という見通しが立ち、損はしない。
市ヶ谷の目が輝いた。
「それなら言えます！『今回は確実なオープンを最優先にするために、あえてシンプルにいきましょう。お店が落ち着いた秋頃に、第2ステップとして拡張できるように準備しておきますね！』って伝えます！」
「うん、お願い。目黒さんも、仕込みだけ裏でこっそりしておいてもらえる？」
「了解です！ 画面側の制御だけ入れて、いつでもオンにできるようにしておきます！」
—
### 6. 主人公が少し学ぶ
数日後、市ヶ谷から「オーナーさん、めちゃくちゃ納得して喜んでくれました！」との報告があった。
デスクでハーブティーを飲みながら、五反田はホッと胸をなでおろす。胃の痛みもすっかり消えていた。
「サクッとできます」という現場の善意は、プロジェクトを輝かせる武器にもなれば、コントロールを失う引き金にもなる。
（技術が分かるからこそ、工数だけじゃなくて、運用や全体のバランスを見なきゃいけないんだよね……。まあ、みんなが前向きだからこそ起きるトラブルだし、悪くないか）
窓から入る風は、やっぱり少しだけ心地よかった。
—
## 今日の業務メモ
**今回の本質的な問題**
開発担当の「技術的な手軽さ（工数の少なさ）」と、クライアントの「あったら便利（運用の考慮不足）」が、マネジメントを介さずに直結してしまい、実質的なスコープ肥大（仕様追加）が発生しかけたこと。
**PM視点で重要だった点**
メンバーの善意（サービス精神）を頭ごなしに否定せず、その変更がもたらす「運用の複雑化」や「マニュアル・検証への影響」という隠れたコストを可視化して納得させた点。
**実務で応用できる考え方**
要望を「やる・やらない」の二択で捉えず、「フェーズを分ける（今回は仕込みのみ、将来的に開放）」という代替案を提示すること。これにより、スケジュールと予算を守りつつ、クライアントの期待値もコントロールできる。
Geminiすごいぞ
ギリギリながら、読める小説にはなっている。
ケーススタディ教材として割り切るなら十分わかりやすい。
ChatGPT君の評価も同じ。
小説としては60点、PMケーススタディとしては85点
PM試験の疑似経験値を稼ぐ教材なら思った以上にアリ
これならいける！
だったら、
小説としても面白くしてやろうじゃないか！
ガチのADHDな私、思考エンジンが別方向へ回り始めます。
ガチでAI小説作りに取り組むことを決めました。
Web制作会社お仕事ものラノベ「からふるわーくす」制作開始です！
production_rules.mdを作る
Web制作会社で起こりうるトラブル事例を題材とした短編連作ですから、必然的に展開は固定されます。
案件→トラブル発生→対応→解決
大事なのは、
- どうトラブルを起こすか
- どう対応するか
この辺りのメカニズムをproduction_rules.mdに記述します。
また、NG表現・行為もあわせて組み込みます。
以下は、どんな作品を作るにしても組み込むことを推奨します
実在作品のオマージュ・パロディ・類型参照をキャラクター設計に使わない。
実在人物・団体・現実事件をモデルにした批判・風刺を行わない。
言うまでもなくリスク管理のためです。
character.mdを作る
お試しでは主人公キャラの特徴を最低限指定しただけでした。
ライトノベル形式ですと、何よりまずキャラ。
プロトタイプではキャラが弱いので読み進めさせる力が低く、読者の認知負荷が高い。
まずは連載形式を前提に登場人物を作ることにしました。
そこで、
character.mdを作り、記述すべき内容を検討します
キャラの人数を決めます。
物語テンプレートを動かすのに最低限必要なのはWEBディレクター・営業・コーダー、デザイナーの4人。
クライアントは全員MOBで、ここは男性もアリ。
必要なら後日社長や在宅勤務のスタッフを作ることで落ち着きました。
キャラを固めます。
からふるわーくすのトラブルは「4人の行動原理」の衝突やすれ違いによって生じます。
まず、その行動原理を象徴する「決めセリフ」を考えました。
- Webディレクター：「嫌な予感がする」
- 営業：「お任せください！」
- コーダー：「技術的には簡単です」
- デザイナー：「ときめきますわ！」
ここを起点として、それぞれのキャラを煮詰めました。
名前・年齢・呼称を考えます。
ネーミングは決めセリフや担当ベースのはずだったのですが、半分適当です。
- WEBディレクター：小田
- 営業：任野
- コーダー：言葉
- デザイナー：絵森
営業とデザイナーは「任せてください」と「デザイナー＝絵」から。
小田は「コーダー→コダ→小田」のつもりで提示したのですが、ChatGPTが勘違いしてWEBディレクターの名前にしてしまいした。
訂正を入力するのが面倒だったのでそのままにしました。
「小田」と名付けられるはずだったコーダーは、「コード→コド→ことは」で言葉にしました。
年齢を考えます。
年齢は小田を一番上で設定します。
地味に苦労したのが「呼称」です
何も設定しないと呼び捨てで呼んだりちゃん付けで呼んだり。
単純にチームメイトを「ちゃん」づけで呼ぶようにしたら、地の文まで「ちゃん」づけになったり。
年齢順を無視して「ちゃん」づけで呼んだり。
設定しても、その通りにしてくれなかったり。
現在は安定していますが、ところどころでこうした細かなチューニングが必要となります。
world.mdを作る
物語を動かすには舞台が必要です。
とはいえ、4人+αのWeb制作会社という条件さえあればいいので、production_rules.mdに入れてしまっても本来構わない。
別途マークダウンを用意したのは、私自身の気質によるものが大きいです。
QA(Quality Assurance)していて気になったこと。
からふるわーくすの人達って車で移動するの？電車で移動するの？
大都市と地方ではまるでライフスタイルが違います。
大都市圏でも、中心部か郊外かで異なります。
さらに「電車なら駅から何分の立地？」と疑問が続き。
他にも疑問が次々浮かび。
いちいち解決するのも手間なので、world.mdを作って世界観を固めました。
キャラクタースタイルシートを作る
小説だけなら参照画像はいらないのですが。
もともとは挿絵つきのライトノベル方式で考えていました。
そのため、画像スタイルシートを作成します。
character.mdの内容を元に、小田ちゃんの画像スタイルシート作って
できあがったキャラクタースタイルシートがこちら。
おおっ！
ごくごく普通のどこにでもいそうな女性社員。
胃薬常備で目の下に隈が常駐とか、そんな主役ヒロインいねーよ。
「美人に書くな」とも「性的記号を強調するな」とも命じました。
しかし漫画補正で、
かわいい！
他の3人も続けて作成。
キャラに愛着が湧いて、俄然やる気が出ました。
2度目のテスト
以上の参照資料をGeminiに入れて再テストしました。
期待した通り面白さが跳ね上がりました。
2度目のテスト生成はこちら。
営業担当がこの時点ではまだ「営業ちゃん」になっています。
AIの書いた小説を読む
### 1. 小田ちゃんの朝
五月の爽やかな風が吹き抜ける朝。Web制作会社「カラフル・ワークス」のディレクター、小田ちゃん（30歳前後）は、オフィスの最寄りにあるコンビニのチルド棚の前で、目を輝かせていた。
「これだ……今週の新作、『極・生クリーム溺れ祭パフェ〜ほろ苦カラメルを添えて〜』……！」
目の下にデフォルトで刻まれた薄い隈をさすりながら、小田ちゃんは愛おしそうにパフェをカゴに入れた。このあふれんばかりの生クリームの白さは、過酷なデスクワークを生き抜くための唯一の光であり、彼女の聖域だ。
今日もこれを楽しみに一日を乗り切ろう――そう心に誓って出社した。
オフィスに入ると、すでにメンバーが集まっていた。
「あ、小田さんおはようございます！ 今日も美味しそうなの買ってますね！」
人懐っこい笑顔で迎えてくれたのは、営業担当の営業ちゃん（26歳前後）。いつもスケジュール帳をパンパンにしながらも、持ち前のポジティブさで社内を明るくするムードメーカーだ。
小田ちゃんはパフェを冷蔵庫に大切に仕舞い、デスクについた。カフェラテを一口飲み、スケジュールを確認しようとしたその時、営業ちゃんがトコトコと嬉しそうに駆け寄ってきた。
「小田さん、大変です！ 嬉しいニュースですよ！」
営業ちゃんはキラキラした笑顔で胸を張った。
「現在制作中の『ハッピー・スイーツ工房』様のECサイトなんですけど、クライアントの社長様が『SNSでバズった時用に、AIが自動で次のおすすめ商品をレコメンドしてくれる超ハイテクなシステムを入れたいなー』ってポロッとおっしゃったんです。だから私、言っておきました！」
営業ちゃんは満面の笑みで親指を立てた。
「『大丈夫です！ お客様喜びます！』って！」
ぴくん、と小田ちゃんの眉が跳ねた。
「……営業ちゃん。それ、先方に実装するって約束しちゃったの？」
「はい！ だって、社長様がすっごくワクワクされてたので！ 私が話しておきますから、追加しちゃいましょう！」
その瞬間、小田ちゃんの脳裏に閃光が走る。
「……嫌な予感がする」
—
### 2. 平和な日常と、小さな違和感
「お疲れ様でーす！」
そこへ、エナジードリンクの缶を持った若手コーダーの言葉ちゃん（23歳前後）がふらりと現れた。コードに関しては天才的なスキルを持つが、空気を読む機能は未実装の天然系女子だ。
「あ、言葉ちゃん聞いて！」営業ちゃんが振り返る。「ハッピー・スイーツ工房様のサイトに、AIの自動商品レコメンド機能を追加したいんだけど、できる？」
言葉ちゃんは瞬きもせず、即座に笑顔で答えた。
「**『技術的には簡単です！』** 無料の外部AIのAPIをちょちょっと連携させて、おすすめ順に並べるスクリプトを書くだけなので、半日もあればコードは組めますよ！」
「ほら！ 言葉ちゃんもすぐできるって言ってます！ さすがカラフル・ワークスの天才コーダー！」
営業ちゃんがパチパチと手を叩いて喜ぶ。
小田ちゃんの胃が、きりきりと音を立てて主張を強め始めた。
（知ってた。言葉ちゃんが『技術的には簡単』って言う時は、コード以外のすべてが破綻する時のサインだってこと、私は知ってた……！）
「二人とも、ちょっとストップ」小田ちゃんは机を叩いて二人を止めた。
「言葉ちゃん、コードを書くのが半日なのは分かった。でも、そのAIが『次のおすすめ』を判断するための元データはどうするの？」
「え？」と言葉ちゃんは首を傾げた。「**『なぜですか？』** APIを繋げば、AIが勝手に良い感じに選んでくれるんじゃないんですか？」
「選ばないよ！ AIに学習させるための『過去の売上データ』とか『商品の詳細なカテゴリ情報』が大量にシステムに入っていないと、AIは何を基準にレコメンドしていいか分からなくてフリーズするか、全然関係ない商品を出しちゃうよ。でも、今回のクライアントって新規オープンのお店だから、最初はデータがほぼゼロだよね？」
言葉ちゃんは口をぽかんと開けた。「あ……ええと、データがないと、AIは何も学習できません。つまり、何もおすすめできません……ぽんこつになります」
そこへ、デザインの最終チェックをしていたデザイナーの絵森ちゃん（24歳前後）が、スケッチブックを抱えてのんびり会話に入ってきた。
「あー、じゃあデータが溜まるまでは、私が作った『今週のイチオシ！』っていう可愛い手動のバナーをランダムで表示させましょうか？ 動きがふわふわしてて可愛いですよ！ **『かわいいのでヨシ！』**」
「いや良くない！」小田ちゃんは思わず突っ込んだ。「絵森ちゃん、デザインは可愛いけど、それだと『AIの自動レコメンド』じゃなくて、ただの『手動のランダム表示』になっちゃうでしょ！ 社長様は『超ハイテクな自動システム』を楽しみにしてるんだから、それを出したら『話が違う』って大問題になるよ」
オフィスに、気まずい沈黙が流れた。
—
### 3. トラブル発生
「……あ、あの」営業ちゃんが冷や汗を流しながら、お気に入りのペンをカチカチと鳴らした。
「社長様、すでに『我が社のサイトには最新のAIレコメンドが乗るぞ！』って、出資者のステークホルダーの皆様に自慢しちゃったみたいです……」
「胃が痛い……」
小田ちゃんは思わず机に突っ伏した。
「AIを導入する」という言葉の響きだけで、全員が自分の都合の良いように解釈してしまっていたのだ。
営業ちゃんは「顧客のやりたいこと」を叶えるために引き受けた。
言葉ちゃんは「プログラムの実装難易度」だけで簡単だと言った。
絵森ちゃんは「可愛い代替案」で画面をハッピーにしようとした。
全員が悪意ゼロ、善意100%で動いている。誰も悪くない。
ただ、「AIを動かすための前提条件（データが必要）」という**要件定義**と**品質管理**の認識が、見事にズレていた。データがない状態でAIを積んでも、動かない粗悪品を納品することになり、会社の信用はガタ落ちになる。
「小田さん……ごめんなさい、私がお断りの連絡を入れてきます……！ お客様に怒られてきます！」
営業ちゃんが涙目で立ち上がろうとする。
「待って、営業ちゃん」小田ちゃんは顔を上げ、目の下の隈を鋭く光らせた。
「全員がハッピーになる着地点を考えよう。まだ打つ手はあるわ」
—
### 4. 会話と解決
小田ちゃんはホワイトボードの前に立ち、マーカーを走らせた。
「社長様が本当にやりたいのは、『最新技術を使って、出資者やお客様に未来感のあるアピールをすること』。そして『バズった時にお客様を逃さないこと』よね？」
三人がコクコクと頷く。
「だったら、今回は『AIの学習期間』としてステップを分けよう。最初の3ヶ月は、絵森ちゃんが言ってくれた『おすすめバナー』の仕組みをベースにしつつ、言葉ちゃんの技術で『ユーザーがどの商品を一緒に見ているか』のログデータを裏でしっかり蓄積する。そしてデータが1000件溜まった時点で、本物のAIレコメンド機能に自動で切り替わる『成長型AIシステム』として提案し直すのはどう？」
言葉ちゃんの目が輝いた。
「あ、それなら完璧です！ 最初のシステム側にはデータ蓄積の仕込みだけ入れておけばいいので、品質的にもバグが出なくて安全です！」
「『成長するECサイト』って、ストーリーがあってめっちゃ素敵です！ **『かわいいのでヨシ！』**」と絵森ちゃんも太鼓判を押す。
小田ちゃんは営業ちゃんに向き直った。
「営業ちゃん。先方にこう伝えて。『オープン直後はデータが白紙のため、AIが誤作動を起こすリスクがあります。お店のファンと一緒にAIを育てる“成長型システム”として、まずはデータを蓄積する第一段階からスタートしませんか？』って。これなら、追加の見積もりも『データ蓄積・分析費用』として正当に請求できるわ」
営業ちゃんはパッと表情を明るくした。
「それです！ お客様、絶対に『物語性があって素晴らしい！』って喜びます！ すぐにこの構成で追加提案書を作って、お客様にお話ししてきます！」
「うん、今度はちゃんと、持って行く前に私に見せてね」
「はーい！」
元気よく営業ちゃんが受話器を取るのを見届け、言葉ちゃんも「コード書きます！」と三画面のPCに向かって猛烈な勢いでキーボードを叩き始めた。オフィスはいつもの、賑やかで前向きな空気を取り戻していた。
—
### 5. 小田ちゃんの締め
夕暮れ時。オフィスに静けさが戻った頃、小田ちゃんはついに冷蔵庫から「極・生クリーム溺れ祭パフェ」を取り出した。
スプーンを深く突き刺し、クリームとカラメルを一緒に口に運ぶ。
口いっぱいに広がる濃厚な甘さと、それを引き締めるほろ苦さ。張り詰めていた胃の痛みが、ゆっくりと溶けていく。
「ふぅ……生き返る……」
メンバーの「簡単です」「喜びます」「ヨシ！」は、カラフル・ワークスを前進させる最高の原動力だ。けれど、言葉の表面だけをすくって進めば、中身のないシステムが出来上がってしまう。
技術のキラキラした部分だけでなく、それを動かすための「土台（データや運用）」が揃っているかを見極め、全員の視点を合わせるのが、自分の役割なのだ。
パフェの最後のひとくちを惜しみながら飲み込み、小田ちゃんは小さく息を吐いた。
「まあ、みんなのモチベーションが上がったから……結果的にヨシ、かな」
窓の外の夕焼けを見つめながら、小田ちゃんの隈は、ほんの少しだけ和らいでいた。
—
## 今日の業務メモ
**今回の本質的な問題**
「AI導入」という流行りのキーワード（仕様）に対し、それを稼働させるための前提条件（初期データの不足）や、品質の担保ができるかという「実現可能性（フィージビリティ）」の検証が抜けたまま、顧客と合意しかけたこと。
**PM視点で重要だった点**
現場の「技術的には可能」という言葉に惑わされず、初期リリース時の品質リスクを見抜き、顧客の要望を「フェーズ分け（データ蓄積→AI稼働）」という現実的なロードマップに再構築して、スコープと顧客の期待値をコントロールした点。
**実務で応用できる考え方**
新しい技術や機能の追加を求められた時は、単にコードが書けるか（工数）だけでなく、「それを動かすためのデータや運用が準備できるか（前提条件）」をセットで確認する。要件を満たせない場合は、段階的なリリース（ステップ論）でお茶を濁さず、価値ある形で着地させる提案を行う。
—
ChatGPT執事、開口一番。
キャラが動き始めてる！
もっとキャラや設定煮詰めれば、普通にお仕事ものライト文芸として成立しそうなのが怖い……
設計もQAも「人間」の役目
前項の続きですが、ここは大事なので項目分けします、
気をよくした私。
テスト小説のQAを行います。
営業ちゃんの、クライアントに向かって「お客様喜びます！」ってセリフは変じゃない？
この時点では、営業ちゃんの決めセリフを「お客様喜びます！」に設定していました。
Geminiはこの設定を機械的にあてはめたわけです。
もっと適切に使いやすいセリフはないか……そう考えて思いついたのが「お任せください！」。
営業ちゃんの名前も「任野」になりました。
絵森も「かわいければヨシ」に設定していました。
しかし言うまでもなく「仕事猫」のパロディ。
著作権はともかく、ミームをそのまま使うのは個人的に安っぽく思える。
絵森はどうして「美」や「かわいい」にこだわるのか？
考え抜いた末、なろう仲間の児童向けライトノベル作家が口癖のように繰り返してたワードを思い出す。
読者さんにどうやったらきゅんきゅんしてもらえるか、いつも考えてるんです
そうか！ 絵森はきゅんきゅんしたいんだ！
きゅんきゅんを言い換えると「ときめき」……
「ときめきますわ！」でいこう！
友人・このはなさくらさんの著作はこちら。
娘さんがいらっしゃる方はもちろん、おっさんでもきゅんきゅんできます。
ぜひ読んでみてください！
KADOKAWA
……というわけで。
こうやって小説のおかしな箇所をチェックし、ルール化して、mdにフィードバックします。
以降はひたすらずっと、この作業を繰り返します。
いま本記事を読まれているのがWeb制作業界の方でしたら、こう思うかも？
まんまQAじゃん！
その通り、QAです。
先述の通り、参照用のマークダウンを作成してAIに与えるのもそう。
つまり、
小説作成だろうとWeb制作だろうと同じです
アバウトにはAIがやってくれます。
自動化することもできます。
でもその結果を100％信じるのは事故の元であり劣化の元。
AIを過信も鵜呑みにもせず。
あくまで人間が設計し、チェックし、内容を詰めていきます。
立ちはだかった壁 ～設計とルールを作り込むばかりが正解ではない
設計とルールを作り込めば作り込むほどクォリティが上がる。
そう考えていた頃が私にもありました。
しかし、
現実は異なりました
作り込みにはまり込んだ私、どんどん設定を練っていきます。
例えば言葉。
エンジニアならキーボードはHHKBだよね！
アイテム
ってな具合に。
（私はREALFORCEの方ですが）
幾度かのテストを経て、ついに自信を持って生成できるだけの仕様書レベルに到達しました。
これならいける！
いよいよ本番、「正史第一号」と銘打って小説を生成しました。
その結果、
つまらない……
設計書通り。
破綻もしてない。
説明もわかりやすい。
小説としては完成しています。
ただ、つまらないんです。
キャラが死んでいて、一言で「無味乾燥」。
味のしないお煎餅をボリボリ囓ってる感覚になりました。
どうして？あれだけ設計詰めたのに？
原因を探るべく、ChatGPTとひたすら壁打ちを繰り返します。
その過程で、ふと思いつきました。
もしかしてルールが多くなりすぎたのでは？
Geminiが制約に縛られすぎて自由に書けなくなったのでは？
ありえそうです……
マークダウンを見返して、必ずしも創作に必要でない設定を削除します。
縛りすぎと思われる箇所も削除します。
削りに削って1/3くらいまで減らしました。
再テスト……
キャラ生き返ったあああああああああああああああ！
教訓として、次のことが言えそうです。
ここがサイト制作と違うところだと思います。
サイト制作の場合はdesign.mdやワイヤーフレームが緻密であればあるほど、意図通りの品質の高い成果物が出力されます。
設計そのものが正解だからです。
AIは指示を具体化し、参照資料を増やし、曖昧さを潰すほど安定する。
私自身、それで何度も生成品質を改善してきました。
だから創作も同じだと思ったのですが、そうなりませんでした。
冒頭に書いた言葉へ戻ります。
Garbage in, Garbage out.
設定不足はもちろんGarbageです。
しかし創作の場合、過度の制約もまたGarbageになり得ました。
Good Inputとは、たくさんのInputではない。
作品として絶対に守らせるものを決め、一方でAIが自由に動ける余白を残す。
創作においてはバランスこそがGood Inputといえそうです
AIへの要求水準がさらに高くなる
ついに、からふるわーくす正史1号が完成。
QAを繰り返して参照資料の調整を重ね、20話くらいにはすっかり安定して生成できるようになりました。
しかし……29話を読んで、ツッコミを入れます。
PM試験って本当にこんな問題・回答なの？
結局全員の希望に対処できるならステークホルダー管理の必要なくない？
教科書としては正しいし、きれいです
そしてPM試験の午後Ⅱはそういう世界です
この辺りで、勉強のためだった小説作りから目的が逸れていきます。
つまり、これまでの制作基準は「PM知識として正しいか」でした。
しかしこの辺りから「実際の仕事として腑に落ちるか」に変わっていきます。
試験直前期には、模範答案メモを別途作っておいた方がいいな……
本末転倒というか。
小説と試験対策を切り分けて考え始めました。
ある意味では、マスターの中に実務感覚が芽生え始めた証なのかもしれません
AIにミステリ作家を演じさせる
私はさらに物足りなくなりました。
改良を図るべく一計を案じます。
プロンプトの先頭に次の文言をつけて
「あなたはキャラクター小説を得意とするミステリ系エンタメ作家です」
「キャラクターの人格・口調・行動原理は設定資料を最優先」
「物語都合で性格や口調を変更してはいけません」
「PM解説を書け」ではなく「お仕事ミステリを書け」。
PM知識から事件を作るのではなく、PM知識が必要になる事件を先に作らせる。
ミステリですから、謎・解決に向けての伏線・論理的一貫性も必然的に用意することになります。
これによって読みやすさ・読み応えの点で改善が図れたように思います。
発想の転換も大事ということですね
Geminiが勝手に小説を爆誕させる
32話のことです。
私はプロットをペーストするのを忘れて「書いて」とだけ入れました。
すると……Geminiはゼロからまるまる1本生成しました。
しかも、
なんかすごく上手いの作ってきた
本筋と関係の無い結論部分がやたら冗長なので、ここでの掲載は見送りますが。
本筋そのものは大したレベル。
そのまま32話として採用とし、32話予定だったプロットは33話となりました。
それだけではありません。
何かの弾みでGeminiが勝手に番外編を書き出し、それもまたちゃんと小説になっていました。
参照資料を作り込んだら、ここまでいけるんだ……
もう、びっくりするやら感心するやらです。
最終回を迎える
33話を終え、ちょっと不安になります。
これ……いつ終わるの？
いくら脇道にそれようと、本来の目的はPM試験対策。
範囲が終わらないことに不安をおぼえます。
残す中核論点をリストアップします
OK！40話で最終回にしよう！ラスト2回はAI回にしよう！
40話を生成し終えた私、ほっと一言。
綺麗にまとまったねえ
40話作り通したことも、最終話の内容も。
最終話のテーマは「AI時代のWebディレクター」。
「AIは人間に取って代われるか」というテーマを真正面から採り上げています。
公開する日をお楽しみに！
後日談：商業AIによる再現性の難しさ
本来なら、ここまでの内容で記事を書いて公開するつもりでした。
現在は9月中旬、40話作り終えたのは6月中旬。
3ヶ月経ってますし、念のため記事を書く前に生成システムチェックを行います。
Gemini、これ書いて
いつも通りにプロンプトを投げました。
しかし……
何これ！つまらない！
明らかにわかるほどに。
私主観ですが、昔のGeminiと現在のGeminiの違いは、
- 昔：ハルシネーションも多いが、勝手に因果や展開を足した。
- 今：設定遵守・安全・整然だが、優等生的。
- 「劣化」ではなく、欲しかった暴走の仕方をしなくなったという話。
Geminiって夏前後にアップデート多かったじゃない？
オフィス用途向けに改善した結果、創作向けとしてはつまらなくなったのかなあ？
仮説としてはありえますねえ……
参照資料を重複記述とかムダな箇所を削って整理したのが悪かったのかも？というのも考えました。
そこで、
- 旧資料と新資料
- プロットA（ChatGPT）とプロットB（私が加筆）
- 私とChatGPTの40話作成当時の壁打ちログの要約をソースにいれる（Geminiのみ）
- Gemini・ChatGPT・Claudeそれぞれ生成。
この組合せを変えてテストしてみた結果、次のことがわかりました。
- 旧資料と新資料で完成度の差はわずか
- 壁打ちログの要約も影響度はわずか
- 事件と因果を私が加えたプロットBで、まともな小説が生成される
- 小説としての出来が一番良かったのはClaude
- Geminiは完成度が足りないどころか、技術的に危うい記述も散見された（過去40話で一度もなかったにもかかわらず。ChatGPT・Claudeともに指摘。私でもわかるミス）。
今回の比較結果だけで選ぶなら、今ですと生成担当にはClaudeを推奨します
まとめ
以上が、私がAIに小説を書かせてみた記録です。
小説本文込みではありますが、壁打ちの総量は推定100万～150万字にのぼりました。
最後まで読まれた方は肩透かしに思うかもですが、
スイッチポンで面白い小説ができるわけではありません
しかし、70点でいい場面もあります。
繰り返しますが、私の本来の目的であるPM試験対策としては十分でした。
自分で書くにしても、全てを自分で書く必要はなくなっています。
自分は設計者となって、AI小説を素材としたディレクションを行う。
ゼロから書き起こすよりはるかに楽に、自分の意図した方向へ作品を仕上げられます。
出版業界では、アマチュアを「小説家」と呼ばないのも「小説家」扱いしないのも常識と言っていいくらい。
ですので、私は「小説家」を名乗れませんし、名乗ろうとも思いません。
「AI小説家」を含めてです。
ですが「AI小説ディレクター」は名乗るかもしれません。
今回やったことの本質は小説執筆というよりディレクション。
いつもの仕事と大して変わりません。
タイトルに「Webディレクター」と銘打ったのはそのためです。
そして思います。
肩書がなんであれ、面白い成果物を生み出せるならそれでいい。
『小説家』を名乗れない身分のまま、それでも面白いと言われる小説を作れたらきっと面白いだろうなあ。
そんな夢想を抱きつつ、本記事を締め括らせていただきます
私はConoHa以外を勧めない。
2016年からずっとConoHaを使い倒してきました。知人に「一番いいサーバーは？」と聞かれたら、迷わずここを教えます。
レンタルサーバーナンバーワンを誇る高速環境であることはもちろん。私が「黒い画面って何？」というド素人からサイト制作のプロになれたのは、傍らにずっとこのはちゃんがいてくれたから。
私がConoHaを使い続ける、嘘偽りない理由です。
※ConoHaに初めて入会の方限定。
本CTAの画像もしくはボタンを押してWINGパック12か月以上を契約すると、最大5000円割引してもらえます。