ゲームのシナリオ管理ツール比較：分岐が増えても壊れない

スプレッドシートで管理できる分岐の限界

Googleスプレッドシートや Excel を使ったシナリオ管理は、チームの誰もが開けるという点で導入コストが最も低い方法です。行にセリフ、列にキャラクター・条件・ジャンプ先ノードIDを並べ、VLOOKUP やフィルターで整合性を確認するやり方は、選択肢の数が一桁のうちは十分に動きます。

限界は「条件の重なり」が出始めたときです。「フラグAが立っていて、かつルートCを通った場合だけ出現するセリフ」を表現しようとすると、条件列が複数必要になり、セル参照が複雑に絡み合います。そのとき、どのセルがどのノードを参照しているかを人間が目で追うのが難しくなります。スプレッドシート管理の実用的な上限は、分岐の合流を含めないツリー換算でおよそ20〜30ノード前後です。それを超えたら別の手段を検討するタイミングと考えておくと判断が早まります。

スプレッドシートを使う際の運用上のコツとして、「ノードID」を必ず付けることが最重要です。行番号をIDとして使うと、行を挿入した瞬間に参照がすべてずれます。A001・B002のような文字列IDをあらかじめ割り振り、行の並び順とIDを切り離しておくだけで管理の寿命がかなり延びます。

ビジュアルノードエディターが得意なこと、苦手なこと

Twine・Articy:Draft・Yarn Spinnerのビジュアルエディターは、ノードをカードのように並べて矢印でつなぐUIを持っています。分岐の「形」を画面上で見られるため、ループや合流点を人間が直感的に把握できます。シナリオを書くだけでなく、構造を設計するフェーズに向いています。

Twine は無料でブラウザ上でも動き、HTML形式での出力ができます。規模の小さいゲームや一人開発ならここから始めるのが最も手早い選択肢です。ただし変数管理と表示ロジックがシナリオファイルと混在するため、プログラマーが別途エンジンに組み込む際に変換コストが生まれます。

Articy:Draft はキャラクター・場所・アイテムをエンティティとして管理し、シナリオの条件式にそれらを参照できる本格的なツールです。大規模なADVやRPGのシナリオに使われます。費用や学習コストについては公式サイトで最新の条件を確認してください。

Yarn Spinner はゲームエンジン（Unityなど）への組み込みを前提に設計されたスクリプト言語で、専用のビジュアルエディターも提供されています。テキストベースで書いて、ノードグラフで確認するという両面の使い方ができます。HTMLゲームや軽量なブラウザゲームへの適用は一手間かかりますが、シナリオファイル自体をバージョン管理システム（Gitなど）に乗せやすいのは大きな利点です。

専用スクリプト言語を選ぶべき条件

Ink（inkle studiosが開発）は、シナリオ専用のスクリプト言語として設計されており、分岐・条件分岐・変数・ウィーブ（ネストした選択肢）をテキストで記述できます。記法が直感的で、慣れると会話の流れを紙に書くような速さで分岐を書けます。

Inkの特徴はウィーブ構造にあります。一度分岐した選択肢が同じ箇所に合流するとき、ラベルを一箇所に書くだけで複数のパスを収束させられます。スプレッドシートで管理が破綻しやすい「合流」が、Inkでは文法として扱えるためミスが起きにくくなります。

専用スクリプト言語を選ぶべき判断基準を整理すると次のようになります。

• シナリオのノード数が50を超える、または今後超えると想定できる
• 条件フラグが複数絡み合うシーンがある
• シナリオファイルをプログラマーとライターが別々に編集する運用がある
• バージョン管理をしたい（テキストファイルはdiffが取りやすい）

逆に、10ノード以下の短いシナリオや、ゲームロジックとシナリオが分離しにくい構造であれば、専用言語の導入コストに見合わないことがあります。

ツールを選ぶ前にシナリオの「型」を決める

ツールを選ぶより先に、自分のシナリオがどの型に属するかを確認しておくと比較がしやすくなります。主な型は次の三つです。

線形＋選択肢型：基本的に一本道で、要所に選択肢があり結末が数種類。エンディング数が少ない。Twineかスプレッドシートで十分なことが多いです。

フラグ管理型：好感度・クリア済みクエスト・アイテム所持など複数の変数が積み重なり、その組み合わせで展開が変わる。変数の参照ミスが起きやすいため、Ink・Yarn Spinnerのような言語か、Articy:Draftのようなエンティティ管理が向いています。

大規模分岐型：プレイヤーの選択が世界観全体に影響し、ルートによってNPCの生死や地名まで変わる。チームでの制作が前提で、Articy:Draft や専用パイプラインの構築が現実的な選択肢になります。

型を決めると、「このツールで管理できる規模か」という問いに答えやすくなります。ツール自体の機能を比べる前に、自分が書こうとしているシナリオの構造を先に言語化する手順がおすすめです。

分岐が増えたときに崩壊しない運用の共通点

ツールが何であれ、分岐が増えても管理が崩れにくい運用には共通する習慣があります。

まず、ノードIDを早期に体系化することです。章・場所・キャラクターの頭文字でプレフィックスを付け、後から見ても何のシーンかわかるIDにします。「001」より「CH1_TOWN_KATE_01」のほうが、数百ノードになってからの検索に耐えます。

次に、未到達ノードのチェック手段を持つことです。書いたは良いが、いかなるフラグ条件でも到達できないシーンが発生するのはシナリオ管理の典型的な失敗です。ビジュアルエディターなら孤立したノードが視覚的に見つかります。スプレッドシートなら「どのノードからも参照されていない行」をフィルターで出す列を別途作ります。Inkなら公式の解析ツールが未到達パスを検出できます。

最後に、シナリオのスナップショットを定期的に残すことです。Gitを使う場合はコミットがそのまま履歴になります。そうでない場合は日付付きでファイルを保存し、「この選択肢を削除したらルートが崩れた」という巻き戻しに備えます。分岐が複雑になるほど、壊れてから直す時間より壊れる前に戻れる体制を作る時間のほうが短くて済みます。

次の行動

自分のシナリオが線形型・フラグ管理型・大規模分岐型のどれに近いかを先に決め、その型に合うツールを一つ選んで5ノード程度の試作から始めてください。まずTwineやInkを手元で動かしてみるだけでも、テキストとビジュアルのどちらが自分の思考に合うかが体感できます。ブラウザゲームとして完成したシナリオゲームは、HTMLまたはZIPファイルの形でアソバースに投稿・公開できます。

参考資料

• Twine 公式ドキュメント（itch.io / twinery.org）
• Ink 公式ドキュメント（inkle studios / GitHub: inkle/ink）
• Yarn Spinner 公式ドキュメント（yarnspinner.dev）
• Articy:Draft 公式サイト（articy.com）