GoogleのAIライティングツール「Fabula」CHI 2026でデモも初出は半年以上前

CHI 2026でのデモ

2026年4月15日、Google Researchの公式Xアカウントが以下のようにポストした。

Meet Fabula: an interactive AI writing tool helping authors structure & refine stories. Co-designed with 42 expert writers, the demo showcases how convergent iteration supports creativity.

バルセロナで開催中のCHI 2026（ACM Conference on Human Factors in Computing Systems）のGoogleブースで、
Piotr Mirowski氏によるデモ「Fabula: a Narrative Storytelling Sidekick」が10:30から実演された。

一見すると新発表に見えるが、Fabulaはこのタイミングで初めて世に出たわけではない。

半年以上前から存在していた

Fabulaの公開タイムラインを整理する。

時期	出来事
2025年5月17日	ロンドンのBattersea Arts CentreでのOpen Research Dayで、Google DeepMindのPiotr Mirowski氏がLLMを使った創作支援のデモを実施。劇作家Natalia Korczakowska氏との共同制作プロジェクトの文脈で紹介された
2025年9月頃	Mirowski氏がLinkedInで「Introducing Fabula」と題してプロトタイプを公式に紹介。研究プロトタイプとしてのアーリーアクセス募集が開始された
2025年12月頃	同じくLinkedInで「Announcing early access to Fabula」として、より広範なアーリーアクセスの告知が行われた
2026年4月15日	CHI 2026のGoogleブースでインタラクティブデモとして公開
2026年5月13日（予定）	英Anglia Ruskin大学でFabulaを使ったライティングワークショップを開催予定

つまり、Googleが「Meet Fabula」とポストした時点で、
初期発表から約7か月、アーリーアクセス告知からも約4か月が経過している。
CHI 2026での登場は学術カンファレンスでのデモ発表であり、一般公開（GA）を意味するものではない。

Fabulaとは何か

Fabulaは、Google DeepMindが開発したフィクション作家向けのAIライティングツール。
Geminiモデル上に構築されており、脚本家・劇作家を主なターゲットとしている。

特徴	内容
42人のプロ作家との共同設計	脚本家、劇作家、テレビ制作者、ナラトロジー（物語論）の専門家が参加
古典的なナラトロジー理論に基づく物語構造	シーンとビート（場面の最小単位）の階層構造でストーリーを管理
複数レベルでの修正	スクリプト全体からストーリープラン（構成表）の個別要素まで、粒度を変えて再生成・修正が可能
多様な執筆スタイルへの対応	即興型、設計型、ハイブリッド型など作家の創作プロセスに合わせたワークフロー

Fabulaは完成した物語を自動生成するツールではなく、
作家が物語を探索・構造化・推敲するプロセスを支援する「ナラトロジーの相棒」だ。

Dramatronからの系譜

FabulaはGoogle DeepMindにとって初のAI創作支援ツールではない。
前身にDramatronがある。

Dramatronは2022年にarXivプレプリントが公開され、2023年のCHI（CHI 2023）で正式に発表された。
論文タイトルは「Co-Writing Screenplays and Theatre Scripts with Language Models: An Evaluation by Industry Professionals」。
Piotr Mirowski氏とKory Mathewson氏が中心となって開発し、15人の映画・演劇プロフェッショナルとの共同執筆を通じて評価された。

Dramatronの特徴は「プロンプトチェーニング」と呼ばれる手法で、
タイトル → キャラクター → ストーリービート → ロケーション → ダイアログという順序で、
各段階の出力を次の生成の文脈として渡すことで、長文脚本の一貫性を確保していた。

graph TD
    A[ログライン<br/>1行の要約] --> B[タイトル生成]
    A --> C[キャラクター設定]
    C --> D[ストーリービート<br/>場面の骨格]
    D --> E[ロケーション描写]
    E --> F[ダイアログ生成]
    
    style A fill:#4a90d9,color:#fff
    style F fill:#e67e22,color:#fff

FabulaはDramatronの設計思想を受け継ぎつつ、以下の点で進化している。

	Dramatron	Fabula
基盤モデル	当時のLLM	Gemini
対象	脚本・戯曲	フィクション全般
設計参加者	15人	42人
アプローチ	プロンプトチェーニング	Convergent Iteration
設計思想	生成AI（Generative AI）	形成AI（Formative AI）
発表	CHI 2023	CHI 2026

Convergent IterationとFormative AI

Fabulaの設計で強調されているのがconvergent iteration（収束的反復）というアプローチ。

従来の生成AIツールは「プロンプトを入れたら結果が出る」という発散的なフローが中心だった。
Fabulaは作家がAIの出力を何度も絞り込み・修正していくプロセスを重視している。
ストーリー全体のプランからシーン単位のビートまで、
階層の異なるレベルで繰り返し再生成と取捨選択を行い、作品を「収束」させていく。

もう一つのキーワードがformative AI（形成的AI）。
生成AI（generative AI）が「AIが作る」ことに主眼を置くのに対して、
formative AIは「AIが人間の創作を形づくる手助けをする」という立場を取る。
Fabulaの場合、完成品を出力するのではなく、
作家が自分の物語を見つけ出すためのツールとして機能することを目指している。

CHI（HCIの最大学会）は人間とAIのインタラクションデザインを議論する場であり、
この区別を打ち出すにはちょうどいい舞台だった。

GAではない

2026年4月時点で、Fabulaは研究プロトタイプの段階にある。
アーリーアクセスは招待制で、一般公開やプロダクト化のアナウンスはない。

Google Researchの「Meet Fabula」というポストは、
学術カンファレンスのブースデモを告知するものであり、製品ローンチの発表ではなかった。
CHI 2026のプログラム上も「Interactive Demo」枠での登録で、
正式な査読付きフルペーパーとしての発表ではない。

Googleの創作支援AIとしては、画像・動画生成のFlowがプロダクトレベルで提供されているが、
テキスト創作の領域ではFabulaはまだ研究フェーズにとどまっている。
5月にはARUでのワークショップも控えており、研究コミュニティでの展開は続いているが、
Google Labsへの追加やプロダクト化の兆候は今のところない。

具体的に何をしてくれるのか

「創作プロセスを支援する」と言われても、
ChatGPTに「物語を書いて」と頼むのと何が違うのかがわかりにくい。
Mirowski氏自身がLinkedInで明言している。

Fabula is not a story generator — it is a tool to empower a writer as they go through the creative process of exploring their story

「ストーリージェネレーターではない」。
では実際に何をしてくれるのか。

ストーリープランとスクリプトの二層構造

Fabulaは物語を2つのレイヤーで管理する。

レイヤー	内容
ストーリープラン	シーンとビート（場面内の最小展開単位）で構成された構成表。キャラクター設定や物語のアーク（展開の流れ）もここに含まれる
スクリプト	ストーリープランに基づく実際のテキスト。ダイアログ、ト書き、描写など

ChatGPTやGeminiに「小説を書いて」と頼んだ場合、
フラットなテキストが一塊で返ってくる。
コンテキストウィンドウの制約もあり、長編で一貫性を保つのは難しい。

Fabulaはストーリープランという「骨格」を永続的に保持するため、
個別のシーンやビートを修正しても全体の整合性を維持できる構造になっている。
Nick Loweの古典的物語理論（The Classical Plot and the Invention of Western Narrative）が
この構造設計のベースにある。

粒度を変えた再生成

Fabulaの中核機能は、物語の異なるレベルで再生成と修正ができること。

graph TD
    A[ストーリー全体のアーク] --> B[シーン構成]
    B --> C[個別シーンのビート]
    C --> D[スクリプト<br/>ダイアログ・描写]
    
    A -.->|再生成| A
    B -.->|再生成| B
    C -.->|再生成| C
    D -.->|再生成| D
    
    style A fill:#4a90d9,color:#fff
    style D fill:#e67e22,color:#fff

あるシーンの結末だけを変えたければ、
そのシーンのビートだけを再生成し、前後のシーンはそのまま残せる。
キャラクター設定を変えた場合も、
影響を受けるビートやスクリプトだけを選択的に再生成できる。

ChatGPTで同じことをやろうとすると、
変更のたびに全文をプロンプトに入れ直すか、
手動で整合性を確認する必要がある。

収束的反復の実際のフロー

前述のconvergent iterationを具体的なワークフローとして見ると以下のようになる。

graph LR
    A[アイデア入力] --> B[AI: 複数の<br/>プラン候補を提示]
    B --> C[作家: 取捨選択<br/>と修正指示]
    C --> D[AI: 修正版を<br/>再生成]
    D --> E{納得？}
    E -->|No| C
    E -->|Yes| F[次のレイヤーへ]
    
    style A fill:#27ae60,color:#fff
    style F fill:#e67e22,color:#fff

1. 作家がログライン（1行の物語要約）やアイデアを入力
2. Fabulaが複数のストーリープラン候補を生成
3. 作家が気に入った要素を選び、修正を指示
4. Fabulaが修正を反映した新バージョンを生成
5. 納得するまでこのサイクルを繰り返す
6. ストーリープランが固まったらスクリプトレイヤーに進み、同じサイクルを回す

一般的な生成AIの「発散型」フロー（プロンプト→出力→別のプロンプト→別の出力）とは対照的に、
選択と修正を重ねて1つの作品に「収束」させていく。

ChatGPT / Geminiとの比較

	ChatGPT / Gemini直接利用	Fabula
物語の構造管理	なし（フラットなテキスト）	シーン・ビートの階層構造
部分修正	毎回プロンプトで指定	特定レイヤーだけ再生成可能
一貫性維持	コンテキストウィンドウに依存	ストーリープランが常に参照される
作家スタイル対応	なし	即興型・設計型・ハイブリッド
データの扱い	モデル学習に使われる可能性あり	Vertex AIガバナンス下で非学習

Fabulaはナラトロジー理論を組み込んだ専用の構造化エディタだ。
作家が書くプロセスの中で構造・展開・整合性の管理をAIに委ねる設計になっている。

ただし、UIのスクリーンショットも操作動画も一切公開されていない。
実際の使い勝手は招待制アーリーアクセスのユーザーにしかわからず、
劇作家Natalia Korczakowska氏がワルシャワでの公演（2025年9月初演「AlphaGo_Lee. Theory of Sacrifice」）の
準備でFabulaを試用したという事例が伝わっている程度だ。

---

ここまで整理して思ったのは、
このアーキテクチャなら自分でも近いものを組めそうだということ。

ストーリープランとスクリプトの二層構造、
各レイヤーでの再生成と収束的反復。
やっていることの本質は、構造化されたコンテキストをLLMに渡して部分的に再生成するパイプラインだ。
Dramatronのプロンプトチェーニングはまさにそれで、
ログライン→キャラクター→ビート→ダイアログの各段階を順に生成する仕組みは、
API呼び出しをチェーンするだけで再現できる。

Fabulaが進化させた「収束的反復」も、
候補の提示→ユーザー選択→差分再生成のループを回すUIを作れば、
裏側はモデルAPIの呼び出しとコンテキスト管理に帰着する。
ナラトロジー理論に基づくシーン/ビートの階層構造も、
JSONやYAMLで表現してプロンプトのシステムメッセージに含めれば足りる。

問題はモデル側にある。
FabulaはGemini上に構築されているが、
Geminiのコンテンツフィルタはフィクション執筆との相性が悪い。
暴力描写やダークなテーマを扱う物語で安全フィルタに引っかかり、
生成が拒否されるケースが報告されている。
プロの作家を対象にしたツールで、
物語のバトルシーンや葛藤の描写が書けないのは致命的だ。

LLMの安全フィルタの仕組みや各社の温度差については
別の記事で詳しく整理しているが、
Geminiは商用クラウドLLMの中でもフィルタが厳しい部類に入る。
創作支援ツールとしてこれがどこまで問題になるかは、
Fabulaが内部でどの程度フィルタを緩和しているかにもよるが、
公開情報からは判断できない。

自作するなら基盤モデルを選べる。
ClaudeはGeminiと比べてフィクションの暴力描写への耐性が高いし、
ローカルLLMを使えばフィルタ自体を制御できる。
「構造化されたナラティブエディタ」というアイデアだけを借りて、
モデルは自分で選ぶほうが実用的だろう。

自作するならこう組む

Fabulaのコアはストーリープランの永続管理、レイヤーごとの部分再生成、
候補提示→選択→再生成のループUIに分解できる。
いずれも既存のLLM APIとフロントエンドフレームワークで実現可能な範囲だ。

全体アーキテクチャ

graph TD
    UI[フロントエンド<br/>Next.js / Astro等] --> API[APIサーバー<br/>Node.js / Python]
    API --> LLM[LLMプロバイダー<br/>Claude / GPT / Gemini / ローカル]
    API --> DB[ストーリーDB<br/>SQLite / PostgreSQL]
    DB --> SP[ストーリープラン<br/>シーン・ビート構造]
    DB --> SC[スクリプト<br/>ダイアログ・描写]
    DB --> CH[キャラクター設定]
    DB --> HIS[生成履歴<br/>候補・選択ログ]

    UI -->|選択・修正指示| API
    API -->|候補を複数返す| UI

    style UI fill:#27ae60,color:#fff
    style LLM fill:#4a90d9,color:#fff
    style DB fill:#e67e22,color:#fff

ポイントは、LLMを直接叩くのではなく、
間にストーリープランのデータベースを置くこと。
LLMへのリクエストには常にストーリープランの該当部分を
コンテキストとして含めるので、
シーン単位の再生成でも全体の一貫性が崩れない。

生成履歴を残しておけば、
「3つ前の候補に戻してそこから分岐させる」
というブランチ的な操作も実装できる。

ストーリープランのデータモデル

ストーリープランはJSONやYAMLで表現する。
以下はシーンとビートの階層構造の例。

{
  "title": "作品タイトル",
  "logline": "1行の要約",
  "characters": [
    {
      "name": "主人公",
      "role": "protagonist",
      "description": "性格・背景",
      "arc": "変化の方向性"
    }
  ],
  "scenes": [
    {
      "id": "scene-1",
      "title": "冒頭",
      "setting": "場所・時間",
      "beats": [
        {
          "id": "beat-1-1",
          "type": "action",
          "content": "何が起きるか",
          "characters": ["主人公"],
          "locked": false
        },
        {
          "id": "beat-1-2",
          "type": "dialogue",
          "content": "会話の要旨",
          "characters": ["主人公", "相手"],
          "locked": true
        }
      ]
    }
  ]
}

locked: true のビートは再生成の対象から除外する。
作家が気に入った部分を固定し、
残りだけをAIに再生成させるための仕組みで、
これがconvergent iterationの「収束」を実現する鍵になる。

部分再生成のパイプライン

特定のシーンだけを再生成する場合のフローはこうなる。

graph TD
    A[ユーザー: シーン3を<br/>再生成したい] --> B[APIが該当シーンと<br/>前後のシーンを取得]
    B --> C[キャラクター設定と<br/>ログラインを付与]
    C --> D[ロック済みビートを<br/>制約条件に変換]
    D --> E[LLM APIに<br/>プロンプト送信]
    E --> F[候補を3つ生成<br/>temperature変えて]
    F --> G[ユーザーに候補提示]
    G --> H{採用？}
    H -->|選択して修正| I[修正指示を追加して再送]
    I --> E
    H -->|採用| J[ストーリープランを更新]
    J --> K[後続シーンの<br/>整合性チェック]

    style A fill:#27ae60,color:#fff
    style J fill:#e67e22,color:#fff

プロンプトに渡す情報はこのあたり。

• ログラインと全体のアーク
• 登場キャラクターの設定
• 前のシーンの最終ビート（文脈の接続）
• 次のシーンの冒頭ビート（着地点の制約）
• ロック済みビートの内容（変えてはいけない要素）
• ユーザーの修正指示

これだけの文脈を渡せば、
LLM側はシーン全体を見ていなくても
整合性のある出力を返せる。
コンテキストウィンドウのサイズ制約は
長編小説全体を一度に渡す場合に問題になるが、
シーン単位の再生成なら数千トークンで収まる。

基盤モデルの選定

Fabulaと違い、自作なら基盤モデルを自由に選べる。
フィクション執筆の観点で各モデルの特性を整理する。

モデル	フィルタ耐性	長文品質	コンテキスト長	コスト感
Claude Opus / Sonnet	高い。暴力・ダークテーマもフィクション文脈なら対応	文体の自然さに定評。日本語も強い	200K tokens	APIトークン課金
GPT-4o / Codex	中程度。system promptで調整可能	英語では最高クラス	128K tokens	APIトークン課金
Gemini Pro / Ultra	厳しめ。安全フィルタの緩和が難しい	長文の一貫性は高い	1M〜2M tokens	APIトークン課金
ローカルLLM（Llama等）	制限なし。フィルタ自体を外せる	モデルサイズに依存	モデル依存	GPU電気代のみ

フィクション執筆では
「フィルタに引っかからないこと」が最優先になる場面がある。
バトルシーン、犯罪描写、心理的に暗いテーマなど、
物語に必要な要素がモデルに拒否されると作業が止まる。

Claude（Anthropic）は
フィクションであることを明示すれば暴力的な描写にも対応する傾向がある。
system promptに「これは小説執筆のためのアシスタントです」と書けば
大抵のフィクション表現は通る。

OpenAIのGPT-4oやCodexは、
system promptでのロール設定による調整幅が比較的広い。
Responses APIを使えば
ストーリーの状態管理をAPI側に委ねることも可能で、
自前のDB管理を一部省略できる。

Geminiはコンテキストウィンドウの長さが圧倒的だが、
フィクション執筆の自由度ではハンデがある。
FabulaがGemini上で動いているということは、
Google内部でフィルタを調整している可能性が高いが、
外部のAPIユーザーが同じ恩恵を受けられるかは不明。

ローカルLLMはフィルタの制約が一切ない。
Llama 3やMistralなどの7B〜70Bモデルを
ollama等で動かせば、
モデルの応答制限に悩まされることはない。
ただし出力品質はパラメータ数に比例するため、
長編の一貫性やキャラクターの書き分けでは
クラウドAPIモデルに劣る場合がある。

実装の最小構成

実際に組むなら、最小構成はこのくらいになる。

graph LR
    A[最小構成] --> B[フロントエンド<br/>React / Svelte]
    A --> C[バックエンド<br/>Express / FastAPI]
    A --> D[DB<br/>SQLite]
    A --> E[LLM<br/>Claude API]

    B --> F[機能1<br/>ストーリープラン<br/>エディタ]
    B --> G[機能2<br/>候補の比較<br/>ビュー]
    B --> H[機能3<br/>スクリプト<br/>プレビュー]

    style A fill:#4a90d9,color:#fff

プロンプトエンジニアリングがこのシステムの肝で、
ナラトロジー理論の知識をプロンプトに埋め込む部分が
Fabulaの「42人の作家との共同設計」に相当する。
シーン構造のテンプレートや
ビートタイプの分類（action / dialogue / revelation / conflict等）を
system promptで定義し、
生成時にモデルがその構造に沿って出力するように制約する。

モデルの切り替えも難しくない。
各社のAPIはリクエスト形式が違うが、
LiteLLMやVercel AI SDKのようなラッパーを使えば
プロバイダーの差異を吸収できる。
シーンの性質に応じてモデルを使い分けることもできる。
ダークなシーンはClaudeに、
長い整合性チェックはGeminiの長大コンテキストに、
という戦略も取れる。

Fabulaは研究プロトタイプとして面白いが、
GA未到達で使えない以上、
同じ設計思想のツールを手元で動かすほうが早い。
必要な部品はすべて揃っている。