← 기사 목록
日本語https://zenn.dev/topics/ai/feed

Google DeepMindのFabulaを参考に、小説執筆サービスへ「作品を理解するAI」を組み込んだ話

원문 사이트로 이동 ↗

추출된 키워드

26개
Fabula·5NovelCraft·5作品を理解するAI·5Google DeepMind·5AIナレッジエンジン·4Gemini·4Gemini 3.1 Pro Preview·4構造化データ·4小説執筆サービス·4文脈設計·3AIチャット·3embedding検索·3構造化出力·3LLM·3RAG·3Supabase·2knowledge_entries·2knowledge_jobs·2knowledge_usage_counters·2ナラトロジー·2story plan·2script·2AIライティング支援プロトタイプ·2Google at CHI 2026·2v0.18.0·2Gemini thinking·1

원문

9,146자
Google DeepMindのFabulaを参考に、小説執筆サービスへ「作品を理解するAI」を組み込んだ話

Google DeepMindのFabulaを参考に、小説執筆サービスへ「作品を理解するAI」を組み込んだ話

はじめに

現在、NovelCraftという小説執筆サービスをベータ提供しています。

小説の本文を書くエディタに、キャラクター管理、ノート管理、AIチャット、画像生成、エクスポートなどを組み合わせた、創作向けのWebアプリです。

今回、Google DeepMindのFabulaを調べていて、かなり強く衝撃を受けました。
コツコツやっていたサービスを大手が掻っ攫っていくという恐怖とともに、AIと執筆において構造化データを持つことの重要さを感じていたので、方向性が正しかったと背中を押された気持ちになったためです。

Fabulaは、ひとことで言うと「AIに物語を丸投げするツール」ではなく、「作家が物語を組み立てる過程を支援するAIツール」です。

この考え方が、いま作っているNovelCraftとかなり相性がよいと感じました。

そこで、v0.18.0では、Fabulaの思想を参考にしながら、既存の小説執筆サービスに「作品を理解するAI」の仕組みを組み込みました。

この記事では、以下について書きます。

  • Fabulaとは何か
  • 何が面白いと感じたか
  • NovelCraftの既存機能をどう活かしたか
  • 実装したAIナレッジエンジンの構成
  • 実際に使ってみてどうだったか

Fabulaとは

Fabulaは、Google DeepMindが発表している、脚本家・劇作家向けのAIライティング支援プロトタイプです。

Google at CHI 2026のページでは、Fabulaは「authors structure & refine stories」を助けるインタラクティブなAI writing toolとして紹介されています。

また、紹介文では「Co-designed with 42 expert writers」「convergent iteration supports creativity」と説明されています。

重要なのは、Fabulaが「完成原稿をAIが自動生成するツール」ではない点です。

公開されている紹介では、Fabulaは以下のような方向性のツールとして説明されています。

  • 作家が物語構造を確認・修正・反復できる
  • story planとscriptを行き来しながら更新できる
  • 古典的なナラトロジー、つまり物語構造の理論を活用する
  • AIは作家を置き換えるのではなく、創作プロセスを支援する

個人的に一番面白かったのは、「AIが文章を書く」よりも「AIが物語の構造を保持する」ことに価値を置いている点です。

小説や脚本は、単に文章がうまいだけでは成立しません。

  • 以前出した伏線が残っているか
  • キャラクターの行動が設定と矛盾していないか
  • この話で何が進んだのか
  • 次にどの要素を回収できそうか
  • 読者に提示した順番と、作中で実際に起きた順番がどう違うか

こうした情報を人間はかなり自然に扱っていますが、LLMにそのまま長い本文を投げるだけでは、なかなか安定しません。

だからこそ、Fabulaが「構造」と「本文」を分けて扱っているらしい点が、かなり示唆的でした。

NovelCraftでやりたかったこと

NovelCraftにも、すでに創作のための構造化データがいくつかあります。

  • 小説設定
  • 章・話
  • 本文
  • キャラクター
  • ノート
  • タイムライン
  • 人物相関
  • AIチャット

ただ、これまでのAI機能は、どちらかというと「その場の入力に対して答える」ものでした。

もちろん、キャラクターやノートを文脈として渡す仕組みは入れていました。

しかし、物語全体を継続的に理解するという意味では、まだ弱い。

たとえば、ユーザーが第5話まで書いていたとしても、AIに「次の展開を考えて」と聞くとき、AIがどこまで過去の話を理解しているかは、プロンプトに詰め込めた情報に依存します。

これは小説執筆支援としては物足りない。

そこで今回やりたかったのは、以下です。

保存された本文や設定から、AIが参照しやすい作品ナレッジを生成し、以後のAI提案に使えるようにする。

要するに、LLMに毎回すべてを読ませるのではなく、作品の進行に合わせて「AI用の読書メモ」を作っていくイメージです。

実装したもの

v0.18.0では、AIナレッジエンジンのPhase 1として、以下を入れました。

BASIC / PRO向けの軽量コンテキスト注入

まず、AIチャットのリクエスト時に、BASIC / PROユーザーであればサーバー側で作品データを取得し、軽量な文脈を組み立ててGeminiへ渡すようにしました。

対象にしたのは、主に以下です。

  • 小説タイトル
  • あらすじ
  • 現在の話
  • 主要なキャラクター
  • ノート
  • ユーザーの相談内容

ここはRAGというより、既存の構造化データを整理してプロンプトに入れる処理です。

FREEでは従来どおり、入力内容中心で回答します。

PRO向けのナレッジ生成

PROでは、保存された話からナレッジを生成するAPIを追加しました。

保存後に非同期で 

/api/knowledge
を呼び、以下のような情報を生成して保存します。
  • 要約
  • キーワード
  • 未回収要素
  • 守るべき制約
  • 次に書けそうな候補
  • 矛盾候補
  • キャラクター状態

保存先はSupabaseの 

knowledge_entries
です。

あわせて、生成履歴を 

knowledge_jobs
、日次の生成回数を 
knowledge_usage_counters
に分けて持つようにしました。

Geminiの構造化出力を使う

ナレッジ生成では、Geminiの構造化出力を使っています。

単純に「この話を要約して」と投げるのではなく、返してほしいJSON構造を指定して、AIが後で再利用しやすい形にしています。

これはかなり効きました。

自然文の要約だけだと、あとから「未回収要素だけ」「キャラクター状態だけ」を取り出しにくいです。

最初から構造化して保存しておくことで、AIチャットに渡すときにも使いやすくなります。

PRO向けの簡易RAG

PROユーザーのAIチャットでは、保存済みナレッジを追加で取得し、軽量コンテキストに混ぜて渡すようにしました。

現時点ではembedding検索ではなく、キーワードや現在の話、作品IDを使った簡易スコアリングです。

ここはまだPhase 1です。

ただ、初期実装としては十分に効果が見えました。

既存機能をどう活かしたか

今回よかったのは、すでにNovelCraft側に小説用のデータ構造があったことです。

新しく「AI用の設定画面」を作ったわけではありません。

ユーザーが普段どおりに書いている本文、キャラクター、ノートをそのまま使っています。

つまり、ユーザーに追加作業をさせずに、AI側の理解だけを少しずつ深める設計です。

この方向は、Fabulaから受けた影響が大きいです。

AIにプロンプトを書くことをユーザーに求めるのではなく、創作の過程で生まれた構造をAIが利用する。

このほうが、小説執筆ツールとして自然です。

ナレッジ確認UI

最初の実装では、ナレッジが生成されているか分かりにくい問題がありました。

実際にテストしていても、「動いているのか？」という状態になりました。

そこで、PRO向けに「ナレッジ確認」ビューを追加しました。

ここでは、全エピソードを話順に表示し、それぞれについて以下を見られるようにしています。

  • ナレッジ生成済みか
  • 生成日時
  • 要約
  • 未回収要素
  • 次に書けそうな候補
  • 守るべき制約
  • キャラクター状態
  • 生成 / 更新ボタン

これによって、AIが裏で何を理解しているのかをユーザーが確認できるようになりました。

AI機能は、裏で勝手に賢くなっているだけだと不安になります。

「いまAIが何を参照しているのか」をある程度見せることは、執筆支援ツールではかなり重要だと感じました。

実装してみて分かったこと

1. 文章生成より、文脈設計のほうが効く

モデルを強くすること自体も効果はあります。

今回はPRO向けにGemini 3.1 Pro Previewも使っています。

ただ、それ以上に効いたのは、AIに渡す文脈を整えることでした。

小説の相談では、「この話の中で何が未回収か」「このキャラクターは今どういう状態か」が重要です。

そこをナレッジとして渡せると、回答の具体性が上がります。

2. 保存後の非同期処理は必須

ナレッジ生成を保存時に同期で待つと、執筆体験が重くなります。

小説執筆では、保存の軽さがかなり大事です。

そのため、保存UIは待たせず、保存後にバックグラウンドで生成する形にしました。

これは正解でした。

3. 可視化しないと検証できない

ナレッジ生成は、裏側だけ作ってもユーザーには分かりません。

テスト中も、最初は「生成されているのか」「参照されているのか」が分かりにくい状態でした。

最終的に、ナレッジ確認ビューと生成 / 更新ボタンを入れたことで、かなり検証しやすくなりました。

実装後の効果

実際にPROユーザーとして試すと、AIチャットの回答に、保存済みナレッジの内容が反映されるようになりました。

たとえば、過去の話で出した未回収要素を踏まえて「次の話で描くべき展開」を提案させると、本文中の要素を拾った提案が返ってきます。

これは、単なる「続きを書いて」よりもだいぶ使いやすいです。

また、BASICでも軽量コンテキストが入るため、キャラクター設定や作品情報を明確に書いている場合は、AIがそれを踏まえてくれる感触があります。

もちろん、まだ完璧ではありません。

現在のRAGはembedding検索ではなく簡易スコアリングですし、ナレッジの粒度や更新タイミングも改善余地があります。

それでも、「小説執筆サービスの中にAIが常駐している」感覚に一歩近づきました。

今後やりたいこと

今回の実装はPhase 1です。

今後は、以下を検討しています。

  • embedding検索によるナレッジ取得
  • 伏線、制約、キャラクター状態の差分管理
  • 話順と作中時系列の分離
  • ナレッジの編集・固定
  • AIが参照したナレッジの表示
  • 長編作品での検索精度改善

特に、Fabulaで示されている「story plan」と「script」の双方向性は、まだ十分には実装できていません。

NovelCraftでは、章・話・ノート・キャラクターという既存構造があるので、ここをより物語構造として扱えるようにしたいです。

まとめ

Fabulaを見て、AI小説執筆支援の方向性は「AIに全部書かせる」ではなく、「人間が作った物語構造をAIが理解して支援する」方向だと改めて感じました。

今回NovelCraftに入れたAIナレッジエンジンは、その第一歩です。

まだ荒いところはありますが、本文、キャラクター、ノート、保存履歴といった既存データをAIが参照できる形に変換することで、AIの提案はかなり変わります。

AIライティングツールを作るうえで、モデル選定と同じくらい、あるいはそれ以上に大事なのは「作品の文脈をどう持つか」だと思います。

Fabulaはその点で非常に示唆的でした。

NovelCraftでも、引き続き「作家の代わりに書くAI」ではなく、「作家が書き続けるためのAI」を目指して改善していきます。

参考

サイト