キャンバス・ノードリファレンス
Fish_In_the_Canvas
Canvas Starter Guide v2.15.3
初めてキャンバスを使用するクリエイター向けに、ノード構造を解説したガイドです。各ノードの役割や記述内容、内部での動作について解説します。
⚠️ これは公式ドキュメントではありません。
冷凍ツナ（Frozen_Tuna）が実際にキャンバスを使って制作しながらまとめた、非公式のファンメイドガイドです。StoryEngineが作成・確認・承認したものではなく、プラットフォームとは一切関係ありません。
プラットフォームの内部仕様には意図的に非公開の部分があり、一部は推測で、一部は単純に間違っています。数値は予告なく変わります。キャンバスを開いたまま参照し、このガイドの内容と実際のキャンバスに相違がある場合は、必ずキャンバス側の仕様を優先してください。
プラットフォームの内部仕様には意図的に非公開の部分があり、一部は推測で、一部は単純に間違っています。数値は予告なく変わります。キャンバスを開いたまま参照し、このガイドの内容と実際のキャンバスに相違がある場合は、必ずキャンバス側の仕様を優先してください。
貼り付ける前にトークン数を数えたい？このガイドにはトークン制限がたくさん出てきます——コアコンテキストは2,000、プリセットノートは500など——が、キャンバスは入力中に数を表示してくれません。便利な代用ツール：Tiktokenizer（o200k_baseエンコーディング）。テキストを貼り付けると、リアルタイムでトークン数を数えてくれます。
なぜo200k_baseか：StoryEngineのクリエイターは、トークン化の方式がGPT-4o基準だと案内されています——これはトークンの数え方についての説明であって、内部でどのモデルが動いているかを述べたものではない点に注意。o200k_baseはGPT-4oのトークナイザーなので、数はおおむね一致するはずです。完全一致ではなく、近い目安として扱ってください——キャンバスと並べて検証したわけではなく、特にCJK（日中韓）テキストはトークナイザーによって差が出やすいです。重要な場面ではキャンバス自身のカウンターを信じましょう。（アヤイヤオさんからの情報。）
なぜo200k_baseか：StoryEngineのクリエイターは、トークン化の方式がGPT-4o基準だと案内されています——これはトークンの数え方についての説明であって、内部でどのモデルが動いているかを述べたものではない点に注意。o200k_baseはGPT-4oのトークナイザーなので、数はおおむね一致するはずです。完全一致ではなく、近い目安として扱ってください——キャンバスと並べて検証したわけではなく、特にCJK（日中韓）テキストはトークナイザーによって差が出やすいです。重要な場面ではキャンバス自身のカウンターを信じましょう。（アヤイヤオさんからの情報。）
キャンバスとは？
キャンバスは、ストーリーチャットを構成するノード（ブロック）を配置してつなぐ作業場です。各ノードには決まった役割があり、それらを配線してデータの流れを作ります。
最小構成
ストーリー + キャラクター + ユーザー
この3つをつなげばチャットは動きます。それ以外はすべて追加機能です。
データの流れ
ノードの中身がAIに渡る
キャンバスは「AIに何を渡すか」を構造化するツールです。ノードに書いた内容はコンパイルされ、AIのコンテキストに入ります。
ノードのつなぎ方：線をドラッグせず、ポートをクリック。どのノードにも側面にラベル付きの入力ポートが並んでいて——これはストーリーノードだけでなく、すべてのノードで同じように動きます。ポートをクリックまたはタップすると、そのスロットに接続できるノードの一覧が出て、選ぶと自動でつながります。画像ポートも同じで、感情画像・状況画像のポートをタップすると、接続できる画像ノードがタグ付きで一覧表示されます。線を手でドラッグするのはモバイルでは大変なので、端末を問わずこちらの方が速いことが多いです。
2つのモデル — メインとサブ
StoryEngineは内部で2つのAIモデルが連携して動作します。
ユーザー入力
チャット欄に入力されたテキスト。
サブモデル
全ストーリーの検索を担当——それだけではありません。主な役割は「全ストーリー」欄（ストーリーノードとキャラクターノードにある3万トークンのテキスト欄で、大量の世界観・キャラクター情報が入る）の意味ベース検索で、今の場面に関係するチャンクを取り出します。システム内で唯一、完全一致ではなく「意味」で動く部分です（内部方式は非公開）。
サブモデルは記憶——進行中の会話の要約と管理も担っていると考えられており、これによって古いコンテキストが使える状態に保たれます。（詳細設定の情報管理・長期記憶トグルがオフにするのは、この仕組みです。）さらに変数の管理にも関わっていると報告されています——ここは見落としやすく、新しいクリエイターがつまずくポイントなので、知っておく価値があります。（アヤイヤオさんからの報告。変数管理の部分は未確認で、本ガイドの「2つのモデル」では変数の更新指示はメインモデルの出力として説明しています。）
サブモデルは記憶——進行中の会話の要約と管理も担っていると考えられており、これによって古いコンテキストが使える状態に保たれます。（詳細設定の情報管理・長期記憶トグルがオフにするのは、この仕組みです。）さらに変数の管理にも関わっていると報告されています——ここは見落としやすく、新しいクリエイターがつまずくポイントなので、知っておく価値があります。（アヤイヤオさんからの報告。変数管理の部分は未確認で、本ガイドの「2つのモデル」では変数の更新指示はメインモデルの出力として説明しています。）
マクロプロンプト
（ロアブック）
（ロアブック）
これはサブモデルではなく、別系統の直接ルートです。マクロプロンプト（ロアブック）のエントリーはキーワード一致でメインコンテキストに直接注入されます。登録キーワードがユーザー入力に現れると、一致したエントリーが追加されます——間にモデルが読み直したり加工したりはせず、ルールベースのトリガーです。
同時に最大5件まで注入 優先度の高いエントリーが枠を取ります。
メインモデル
生成を担当。常に固定で受け取るもの：ストーリーのコアコンテキスト + プロローグ + キャラクターのコアコンテキスト。
サブモデルが取り出した全ストーリーのチャンクと、キーワード一致したマクロプロンプトのエントリーがその上に加わり、その組み合わせから応答が生成されます。
画像タグの出力 smile angry や変数の更新指示も、メインモデルの仕事です。
サブモデルが取り出した全ストーリーのチャンクと、キーワード一致したマクロプロンプトのエントリーがその上に加わり、その組み合わせから応答が生成されます。
画像タグの出力 smile angry や変数の更新指示も、メインモデルの仕事です。
出力
物語のテキスト + 画像タグ → 画面に表示。
2つの異なる検索経路 — 混同しないこと
全ストーリーはサブモデル経由：意味ベースの検索で、必要な場面でだけ取り出されます。意味で一致します。
マクロプロンプトはサブモデルを経由しません：キーワード完全一致で直接注入。特定の語が出たときに作動し、それ以上あいまいなことはしません。
そしてこの2つとは別に、コアコンテキストは毎ターンメインモデルに注入されます——絶対に守らせたいルールはここに書きます。
全ストーリーはサブモデル経由：意味ベースの検索で、必要な場面でだけ取り出されます。意味で一致します。
マクロプロンプトはサブモデルを経由しません：キーワード完全一致で直接注入。特定の語が出たときに作動し、それ以上あいまいなことはしません。
そしてこの2つとは別に、コアコンテキストは毎ターンメインモデルに注入されます——絶対に守らせたいルールはここに書きます。
ストーリーノード
キャンバスの中心となるノード。キャラクター・マクロプロンプト・アチーブメントの各ノードはすべてここにつながり、まとめてコンパイルされます。ここに書いた内容は最優先で、最初にメインモデルに届きます。
ストーリーノードは複数作れます——章立てやシナリオ分岐に便利です。開始場面として提示したいノードすべてでスタートノード：はいをオンにすると、読者がどこから始めるかを選べます。
実際に入力するフィールド：
| Field | Description |
|---|---|
| スタートノード | このノードを選択可能な開始地点として指定します。冒頭で提示したいストーリーノードごとにオンにします——「はい」が複数あると、チャット開始前に読者がどの開始状況から始めるかを選びます。同じ物語に複数のルートを用意する方法なので、1つに限られると思い込まないでください。 |
| コアコンテキスト （基本2,000トークン） |
絶対ルールを書く場所。AIが常に従うべき指示——SYSTEM_LAYER / WORLD_LAYER / DIRECTIVE など。メインモデルは何よりも先にここを読みます。 予算は初期状態で2,000トークンで、詳細設定のトグルをオンにすると増えます。3,800と表示されているキャンバスは、+1,800分のトグルがオンになっている状態です。 |
| 全ストーリー （30,000トークン） |
サブモデルが検索する場所。世界観の知識、場所の詳細、場面ごとの設定——大量の情報はここに入れます。コアコンテキストと違い、常時注入されるわけではありません。サブモデルが場面に応じて取り出します。内部の検索方式は非公開です。 |
| プロローグメッセージ （700トークン） |
チャット開始画面に表示される冒頭シーン——入室時にユーザーが最初に目にするものです。ただし読者向けだけではありません：AIもこれを読み、確定した開始状況として扱います——どのキャラクターがその場にいるか、すでに何が動き出しているか、初手からマクロを作動させるべきか、など。ですから単なる挨拶ではなく、物語を方向づける「場面」として書きましょう。 その実用的な使い方：スタートガイドは300トークンしかなく、手狭になりがちです。初手の設定がそこに収まらないとき、クリエイターはあふれた分をここに仕込むことがよくあります——AIはどのみちこれを読むので、ヒントや初期状態の一部をプロローグメッセージに織り込むわけです。 |
| スタートガイド （300トークン） |
最初のターンの扱いをAIにだけ指示する内容。「次のターンはこう始めろ」「変数の初期値はこれ」など。ユーザーには表示されません。 |
| 制作者からのお知らせ （500文字） |
制作者から読者へのメモ。この物語がどのモデル向けに調整されているか、どのモデルだと不調かを書くのによく使われます——読者は自分でモデルを選べるので、書いておく価値があります。 |
制作のコツ — 応答内の要約ブロックと、その位置が重要な理由。
よくあるパターンとして、コアコンテキストからモデルに指示して、各応答の末尾に現在の状態を要約したコードブロック——ステータス、関係値、各キャラクターの考えなど——を出させる方法があります。これはステータスビューノード（別途の横パネル）ではありません。このブロックは、あなたがコアコンテキストで指示したために、モデルが自分の出力の一部として書くものです。
言語モデルは上から下へ書くので、そのブロックをどこに置くかで、何を参照できるかが決まります。
応答の末尾（一般的な選択）：ブロックに到達する頃には場面はすでに書き終わっているので、値はすぐ上の文章から導かれます。状態が物語に従う——数値は「今起きたこと」を表します。
冒頭：文章が存在する前にブロックが確定するので、数値が先に来て、物語がそれに合わせて書かれます。どちらも間違いではなく、単に向きが逆なだけです。自分がどちらを求めているかを知っておく価値があります。
よくあるパターンとして、コアコンテキストからモデルに指示して、各応答の末尾に現在の状態を要約したコードブロック——ステータス、関係値、各キャラクターの考えなど——を出させる方法があります。これはステータスビューノード（別途の横パネル）ではありません。このブロックは、あなたがコアコンテキストで指示したために、モデルが自分の出力の一部として書くものです。
言語モデルは上から下へ書くので、そのブロックをどこに置くかで、何を参照できるかが決まります。
応答の末尾（一般的な選択）：ブロックに到達する頃には場面はすでに書き終わっているので、値はすぐ上の文章から導かれます。状態が物語に従う——数値は「今起きたこと」を表します。
冒頭：文章が存在する前にブロックが確定するので、数値が先に来て、物語がそれに合わせて書かれます。どちらも間違いではなく、単に向きが逆なだけです。自分がどちらを求めているかを知っておく価値があります。
内心の一文は二役をこなします。要約ブロック内の「キャラクターが考えていること」の行は、読者には内面描写として読まれます——しかし機能的には、次のターンの方向を左右します。応答の最後にキャラクターが抱いた考えが、次の応答が書かれる際のコンテキストになります。単なる味付けではなく、物語の舵取りをする要素として扱いましょう：扉を閉じる考えは次の展開を狭め、扉を開く考えは広げます。
↓ では、なぜスタートノードに「いいえ」があるのか？
「いいえ」に設定したノードは使われないわけではなく——チャットの途中で到達する分岐の行き先だからです。 下のシナリオ分岐を参照。
「いいえ」に設定したノードは使われないわけではなく——チャットの途中で到達する分岐の行き先だからです。 下のシナリオ分岐を参照。
キャラクターノード
NPC1体につき1ノード。外見、性格、口調、人間関係——キャラクターに関する情報はすべてここに入ります。ストーリーノードにつなぐと、メインモデルがそのキャラクターを認識します。
口調はキャラクターノードの中に直接書きます。以前は専用のテキストノードがありましたが、今は統合されています。
| Field | Description |
|---|---|
| 名前 （100文字） |
キャラクターの表示名。ラテン文字以外でも問題ありません。 |
| コアコンテキスト （300トークン） |
重要情報パネルに表示されます。名前・年齢・性別など、必須の属性だけに絞りましょう。予算は意図的に小さいので、ここでのトークンの使い方が重要です。 |
| 詳細説明 / 全ストーリー （30,000トークン） |
ストーリーノードと同じくサブモデルが検索する場所ですが、内部的には別扱いされていると考えられています（正確な挙動は非公開）。キャラクター関連の内容だけに絞りましょう——性格、口調、行動、背景設定、人間関係。 |
| キャラクタープレビューに表示 | 詳細ページのプレビュー欄にこのキャラクターを表示するか。プレイ中に発見させたいキャラクターは、通常オフにしておきます。 |
| title | 自分用の整理コードラベル。例：KMR |
キャラクターが20人を超えると、全員が同時に読み込まれるわけではありません。1つのセッションで自動的に読み込まれるのは最大20人まで。21人以上いる場合、1セッションにつき20人だけがランダムに読み込まれます——つまり、当てにしていたキャラクターがそのセッションにいない、ということが起こり得ます。
読者側の対処が、ユーザーノートメニューにあるキャラクター情報を常時ロードです。読者は特定のキャラクターを毎回読み込むよう固定できます（最大50人）。作者として知っておくべき2点：これを切り替えるのは読者であって作者ではないこと——そして固定した各キャラクターは、名前の横に表示されるトークン数のぶんだけ読者自身のトークン予算（ユーザーノートやペルソナと共有の2,000）を消費すること。大人数のキャストでこれに頼ると、読者のトークンを静かに消費します。
実用的な結論：20人以下で物語を語れるなら、そうするのが得策です——ランダム読み込みの問題を丸ごと回避できます。20人を超えるなら、要となる数人を固定するよう読者を導くことを想定しておきましょう。
読者側の対処が、ユーザーノートメニューにあるキャラクター情報を常時ロードです。読者は特定のキャラクターを毎回読み込むよう固定できます（最大50人）。作者として知っておくべき2点：これを切り替えるのは読者であって作者ではないこと——そして固定した各キャラクターは、名前の横に表示されるトークン数のぶんだけ読者自身のトークン予算（ユーザーノートやペルソナと共有の2,000）を消費すること。大人数のキャストでこれに頼ると、読者のトークンを静かに消費します。
実用的な結論：20人以下で物語を語れるなら、そうするのが得策です——ランダム読み込みの問題を丸ごと回避できます。20人を超えるなら、要となる数人を固定するよう読者を導くことを想定しておきましょう。
マクロプロンプト（ロアブック）
キーワードで反応する注入メモです。マクロプロンプトノードにエントリーを書いておくと、登録キーワードがユーザー入力に現れたとき、その内容がメインコンテキストへ直接注入されます——間にサブモデルが読んだり加工したりはしません。これは類似検索ではなくキーワード完全一致で、トリガーワードが現れたときに反応するだけで、それ以上あいまいなことはしません。
常に存在するストーリーノードやキャラクターノードと違い、マクロプロンプトは状況に応じて動的に注入されます。
1ターンに注入されるのは最大5件です。それを超えると、優先度の高いものが枠を取ります。重要なルールほど高く設定しましょう。
1つのエントリーの構成：
| Field | Description |
|---|---|
| トリガーワード （最大5個） |
このエントリーを呼び出すキーワード。1つずつ追加し、それぞれがチップになります。 |
| 常時 | キーワードを完全に無視して、毎ターンこのエントリーを注入します。使いすぎ注意——5枠のうち1つを恒久的に占有します。 |
| プロンプトテキスト （300トークン） |
エントリーが呼び出されたときに実際に注入される内容。 |
| 優先度 | 値が高いほど5枠を先に取ります。OOCやシステムルールは通常99〜100あたりに設定します。 |
| 持続ターン | 注入が何ターン持続するか。通常は1。 |
マクロプロンプトノードは複数作って用途で分けてもかまいません——OOCルール用、世界観用、画像ルール用など。1つの巨大な塊よりずっと管理しやすくなります。
トリガーワードは、普通の文章と被らない語を選びましょう。一致は文字通りに行われるため、ありふれた語をトリガーにすると、そのエントリーが意図しない場面で何度も作動してしまいます——読者や物語が自然に口にする言葉と重なるキーワードは誤爆し、場面を崩しかねません。日常語より、独特なトークン（造語や珍しい複合語）を選びましょう。（まさにこれで絡まってしまった、アヤイヤオさんからの情報。）
キーワードのもう一つの使い方：読者が切り替える「モード」。上のAlwaysの挙動とは別物で——こちらは、読者が特定のキーワードを入力するまでエントリーはオフのままで、入力するとオンになります。よくあるやり方は、!free modeのような独特なトリガーにモード用のプロンプトを入れておくこと。これはプリセットノートと役割が重なり、どちらも有効で、選択は好みの問題です。実際の違いは消費するトークン量と、優先順位のどこに入るかです：プリセットノートは読者自身の予算を使い、優先順位の最下部で読まれます。一方マクロエントリーはあなたのノードの予算を使い、優先度を好きなように設定できます。（スクリーンショットとこの提案はMukmulさんより。）
画像ノード
キャラクターに表示される画像セットを管理します。各画像はタグに紐づいており、メインモデルのタグ出力によってどの画像を表示するかが決まります。画像ノードはキャラクターノードにつなぎます。
ファイル名がそのままタグです。別途タグ欄に入力するのではなく、ファイルの名前がそのままタグになります。アップロード前に、それを踏まえて命名しましょう。
イメージタグを分類
StoryEngineの画像は、プロンプトの延長ではなく独立したモジュールとして動作します。そのためAIがどの画像がどの場面に合うかを判断できるよう、タグをカテゴリーに分類し、説明を自分で書く必要があります。
トップメニューのキャンバス → イメージタグを分類にあります。
カテゴリーの説明は25トークン未満に収める必要があります。長すぎる説明は正しく機能しません。
手順：
| Step | What to do |
|---|---|
| 1. カテゴリーを作る | 名前を入力して追加します。例：Emotions Locations Activities |
| 2. 説明を書く | 25トークン未満で、そのカテゴリーがいつ・どんな状況で当てはまるかを書きます。AIはこれを読んでどの画像を使うか判断します。 |
| 3. タグを割り当てる | 画像ノードのタグを、対応するカテゴリーに追加します。例：Emotions → smile angry sad |
カテゴリーの説明は、AIが読む「生きた指示」です。短く、あいまいさなく——「感情を表現するときに使う」くらいがちょうどいい塩梅です。カテゴリーの質が高いほど、画像が正確に当たります。
変数ノード
チャットを通して追跡する値を保存します。ブール値・数値・文字列に対応。変数は、トリガーノードに読まれて条件判定に使われるか、カスタムのステータスビューに表示されます。
基本パターン：変数は普通、トリガーを通しません。変数ノードをアップデートルールノードと組にして、ストーリーノードに直接ぶら下げます。トリガーとアチーブメントは、変数をマイルストーンのイベントにしたいときだけ足す追加の枝です。
| Field | Description |
|---|---|
| 変数名 （100文字） |
変数の識別子。 var_という接頭辞を付けると、ステータスビューのHTMLパネルから {{var_NAME}}として読めます。接頭辞が厳密に必須なのはステータスビュー表示のときだけで——なくてもトリガーやアチーブメントの配線は動きます。ただし、それだけではありません（下の注記を参照）。習慣として付けておく価値があります。 |
| 変数タイプ | ブール値 数値 文字列 |
| 初期値 | 開始時の状態。ブール値は「いいえ」、数値は0、文字列は空がデフォルト。 |
| title | 内部整理用のコードラベル。関連するトリガーやアチーブメントと同じラベルにしておくと、後で対応関係が分かりやすくなります。例：A1 |
変数名は、互いにはっきり区別できるものにしましょう。見た目が似た名前は混ざることがあります——ある変数向けの更新が別の変数に当たったり、値が知らないうちに入れ替わったり。隣の変数と見間違えようのない名前を付ければ（affection / affection2のような紛らわしい形ではなく、一目で違うと分かる名前で）、この問題は起きません。
var_接頭辞は、そもそもどこから来たのか。公式ドキュメントには記載がなく、古いビルドでは使われていませんでした——比較的最近になって導入されたようです。調べてみると、この接頭辞は、キャンバスが大きく複雑になるにつれてコンパイル中に変数データが混ざるのを防ぐために存在しているようです。つまり上と同じ「衝突」の問題を、命名規則で対処したものです。付けなくても動作はしますが、付けることが推奨されます。（公式に確認された情報ではなく、確定的な答えは運営への問い合わせが必要です。アヤイヤオさんの指摘により、一緒に確認しました。）トリガーノード
変数が条件を満たしたときにアチーブメントを作動させます。ストーリーノードと変数ノードを入力に取り、条件が満たされると、つながったアチーブメントノードに信号を送ります。トリガーが必要なのは、アチーブメントを解除させたいときだけです。ただ値を追跡するだけの変数には要りません。
イベントシステムの組み立て方：ストーリーノード + 変数ノード + トリガーノード + アップデートルールノード、そして必要に応じてアチーブメントノード。下の流れは、アチーブメントまで到達する枝です。
Story node
+
Variable node
→
Trigger node
→
Achievement (optional)
| Field | Description |
|---|---|
| 監視する変数 | このトリガーが監視する変数。つながった変数ノードの名前と一致する必要があります。 |
| 値 | 監視中の変数がこの値になるとトリガーが引かれます。ブール値なら通常はい。 |
| title | 対になる変数・アチーブメントと同じラベルを使います。例：A1 |
アチーブメントノード
トリガーが引かれたときに読者へ表示されるマイルストーンです。アチーブメントノードをストーリーノードに戻してつなぐと、獲得されたことに物語自身が反応できます。
| Field | Description |
|---|---|
| アチーブメント画像 | 解除時に表示される任意の画像。クリックまたはドラッグ＆ドロップで設定します。 |
| アチーブメント名 （100文字） |
読者に表示される名前。 |
| 説明 | アチーブメント獲得時に表示されるフレーバーテキスト。 |
| 表示優先度 | 数字が大きいほどアチーブメント一覧の先頭に出ます。物語上重要な解除を上に置くのに便利。 |
| 非公開アチーブメント | 獲得するまで名前と説明の両方を隠します。ネタバレになるものにおすすめ。 |
セットになる変数・トリガー・アチーブメントには同じtitleラベル（A1, A2, A3…）を付けましょう。キャンバスが混み合ってくると、これが「構造を一目で読めるか」「配線をたどって探す羽目になるか」の分かれ目になります。
シナリオ分岐 — 1つの物語に複数のルート
この手法は私が見つけたものではなく、ㅇㅅㅇㅇㄴㄷさんからの報告によるものです。ありがとうございます。（以前のエラーで英語ハンドルが消えたため、ページには韓国語ハンドルが表示されています。）
スタートノード：いいえに設定したストーリーノードは、余り物ではありません——チャットの途中で到達する「行き先」です。そこにトリガーを配線すると、トリガーが引かれたときに物語がそのノードへ引き継がれます。実際の結果はノベルゲーム風のルート選択：1つの作品の中に複数の異なる道が入っている状態です。
Variable
+
Update Rule
→
Trigger
→
Story node (Is Start: No)
アチーブメントですでに使っているのと同じ鎖ですが、1点だけ違います：終端がアチーブメントノードではなく、ストーリーノードになっていることです。
実際の流れ：
| Step | What happens |
|---|---|
| 1. 選択肢を提示 | 冒頭のシナリオで、読者が選べる手段を用意します。特定のキーワードを入力させる指示、キャラクターからの問いかけ、プロローグに書いたメニューなど——物語に合う方法で。これを動かすのは読者の入力なので、見つけられる形にしておく必要があります。 |
| 2. 変数を更新 | アップデートルールが入力を捉え、対応する値を変数に書き込みます。スクショでは文字列で——part1がwaitから始まり、選択されるとP1に変わります。 |
| 3. トリガーが作動 | その変数を監視しているトリガーが値を検知して反応します。アチーブメントのときとまったく同じです。 |
| 4. ルートが開く | トリガーの先にあるストーリーノードが引き継ぎ、チャットは元のノードではなくそのノードのコンテキストから続きます。これが分岐です。 |
ルートごとに専用の変数とトリガーを用意し、アチーブメントと同じ要領で対になるラベル（P1, P2…）を付けましょう。分岐のあるキャンバスはすぐ混み合うので、ラベルこそが可読性を保つ鍵です。
このセクションは本ガイドの他の部分より新しく、検証が浅いです——繰り返し組んだ結果ではなく、1件の報告に基づいています。試してみて挙動が違ったら、ぜひ教えてください。
プリセットノート — 読者が切り替えるプロンプトモジュール
プリセットノートは、あなたが書き、読者がオンにする任意のプロンプトブロックです。それぞれにアイコン、タイトル、読者に見える短い説明、そして有効化時に注入されるプロンプトテキストがあります。物語に対する「読者が選ぶ」修飾——追加モード、内容の強調、トーンの変化など——だと考えてください。あなたが強制するのではなく、読者が選ぶものです。
重要な落とし穴：プリセットノートは、読者が他のことにも必要とするトークン予算を消費します。読者には2,000トークンの枠があり、これはユーザーノートとユーザーペルソナで共有されます。プリセットノートをオンにすると、同じ枠から引かれます。2,000を超えると、追加600トークンごとに利用料が10%上がります。
つまり重いプリセットノートは、読者自身のノートやペルソナの場所を奪うだけでなく——読者をより多くの支払いへ押しやる可能性があるのです。（予算の数値はㅇㅅㅇㅇㄴㄷさんの報告によるもの。このセクションが最初に誤った数値で公開された後、確認してくれました。）
つまり重いプリセットノートは、読者自身のノートやペルソナの場所を奪うだけでなく——読者をより多くの支払いへ押しやる可能性があるのです。（予算の数値はㅇㅅㅇㅇㄴㄷさんの報告によるもの。このセクションが最初に誤った数値で公開された後、確認してくれました。）
計算例、下のスクショの2つのノートで。Sweat Overdriveは368トークン、Event Overlordは408。両方オンにすると、読者が自分のペルソナやノートを1文字も書かないうちに共有の2,000のうち776が消えます。さらに数個足すか、詳細なペルソナを持つ読者だと、より高い料金の領域に入ります。プリセットノートに入れるトークンは、どれも読者に支払わせる可能性のあるトークンです。
ここから2つの帰結が生まれ、どちらも制作時に重要です：
| Consequence | What it means for you |
|---|---|
| 全部同時には使えない | プリセットノートは最大10個まで定義できますが、読者が全部を同時にオンにはできません——消費するたびに有限の予算から引かれるので、枠が尽きます。全部オンにする前提の積み重ねではなく、選択肢として設計しましょう。 |
| 1つ1つを軽く保つ | 重いプリセットノート（実物は約370〜410トークン）は、それだけで共有の2,000のかなりの部分を食います。いくつも重なると、読者は自分のペルソナを1文字書く前に予算のかなりを使ってしまいます。大きくせざるを得ないなら、その価値に見合うものにしましょう。 |
| Field | Description |
|---|---|
| アイコン | 読者の一覧でノートの横に表示される小さな絵文字。 |
| タイトル | 切り替え一覧で読者に見えるノートの名前。 |
| 説明 | このノートをオンにすると何が起きるかを説明する短い一文——読者が判断するために表示されます。 |
| プロンプト （500トークン） |
ノートがオンのときにコンテキストへ注入されるテキスト。これが実際に読者のトークンを消費します。 |
| 優先度 | オンになっているノート間での並び順の値。 |
プリセットノートの入力は優先順位の最下部に来ます——コアの指示やキャラクターデータより先ではなく、後に読まれます。なのでプリセットノートは物語を「後押し」しますが、上位に設定したルールを上書きはしません。書くときはこれを念頭に：コアコンテキストと矛盾させるのではなく、追加として表現しましょう。
その他のノード
基本が整うと出会う補助ノードたち。あえて軽めに扱っています——クリックして何が起きるか見るのが、一番の学び方です。
Update Rule
変数のマイルストーン
変数が通過するマイルストーンを定義します。変数をいつ・どんな条件で・どれだけ更新するかをAIに指示します。ストーリーノードから変数ノードと組で使い、ステータスビューと併用されることが多いです。予算は400トークン。例：好感度、疲労度、位置。
Status View
カスタムHTMLパネル
HTML/CSS/JSで書くステータスパネル。
{{var_NAME}}構文で変数の現在値を読めます。ここに表示されるのはvar_接頭辞の付いた変数だけです。一部の物語が各応答の末尾に出力する要約コードブロックと混同しないこと——あれはコアコンテキストの指示によってモデルが書くもので、ストーリーノードの項で扱っています。
Background Image
場面の背景
ストーリーノードにつないで、チャットの背後の背景を設定します。押して確かめてみてください。
注釈ノード
自分用のメモ
キャンバス上の付箋——ただそれだけ。ポートがなく、何にも接続されず、AIが読むこともありません。キャンバスに自分用のコメントを残すためだけのものです（400文字）。
これは、かつてのテキストノードの成れの果てです。以前のテキストノードにはポートがあり、キャラクターノードのシステム部分（口調など）につながっていました。その役割は今やキャラクターノード自体に統合され、残ったノードはこの「メモ専用」の注釈ノードに転用されました。接続できたテキストノードを覚えているなら、その行き先がこれです。
これは、かつてのテキストノードの成れの果てです。以前のテキストノードにはポートがあり、キャラクターノードのシステム部分（口調など）につながっていました。その役割は今やキャラクターノード自体に統合され、残ったノードはこの「メモ専用」の注釈ノードに転用されました。接続できたテキストノードを覚えているなら、その行き先がこれです。
ここに載っていないものは、本当に触ってみる価値があります。キャンバス上で開いて壊れるものは何もなく、韓国のクリエイターが知っていることの半分は、まさにこうやって学ばれました。
詳細設定
StoryEngineの組み込み動作の一部をオフにするパネルです。各トグルはデフォルトでOFF、OFFはその機能が使われている状態を意味します。ONにすると、名前の機能が無効化されます。文字通りに読んでください——「Xをオフにする」がONなら、Xは今オフです。
公式ではなく、コミュニティの知見です。各スイッチが内部で何を取り除くのか、プラットフォームは完全には文書化しておらず、一部は意図的に非公開です。以下は韓国のクリエイターが実使用からつなぎ合わせた内容です。抜けがある前提で読んでください。
これが、キャンバスごとにコアコンテキストの予算が違う理由です。基準は2,000トークン。3,800と表示されるスクショは、単に+1,800分のトグルがオンなだけです。あなたの数値はオンにしたものによって完全に変わります——なので、ネットで見かけた1つの数値を「本当の上限」だと思わないでください。
以下のボーナスはすべて1トグルずつ計測しました。ボーナスのある7つを全部オンにすると+5,500増え、コアコンテキストは2,000から7,500トークン——デフォルトの約4倍になります。旧式画像タグ付けを使用は予算をまったく変えません。プロンプトを取り除くのではなく方式を入れ替えるだけだからです。
以下のボーナスはすべて1トグルずつ計測しました。ボーナスのある7つを全部オンにすると+5,500増え、コアコンテキストは2,000から7,500トークン——デフォルトの約4倍になります。旧式画像タグ付けを使用は予算をまったく変えません。プロンプトを取り除くのではなく方式を入れ替えるだけだからです。
| Toggle | What switching it ON does |
|---|---|
| 情報管理をオフにする +800 | システムが会話メモリを自動管理するのを止めます。実際には古いコンテキストを保持しておく検索も無効化され、こちらの方が影響が大きいです。読者はチャット途中で長期記憶の問題に当たりがちです。オフにする理由がはっきり分からないなら、触らないでおきましょう。 |
| 長期記憶をオフにする +1,200 | ストーリー要約を使わず、直近のメッセージだけでチャットが続きます。注意：観察できる症状は上の情報管理と大きく重なり、外から見て2つをきれいに区別できたことがありません。独立したものではなく、関連するものとして扱ってください。 |
| マクロプロンプトをオフにする +1,200 | マクロプロンプトを無効化します——つまりマクロプロンプトがまったく働かなくなります。上の2つと違い、これは曖昧さがありません。 |
| コンテンツポリシーをオフにする +800 | StoryEngineのデフォルトのコンテンツ管理と安全ガイドラインを無効化します。概念的には下のナラティブ指示を短縮と対になり——どちらも運営が用意した基盤プロンプトを取り除きます。このセットで最大のトークン還元。 どちらにしてもプラットフォームの規約は適用されます。このトグルが変えるのはプロンプトであって、あなたの義務ではありません——地域ごとのタイトル制限、利用規約、公開作品のモデレーションはすべて有効なままです。 |
| ナラティブ指示を短縮 +500 | ナラティブエンジンのプロンプトの短縮版を使います。この運営デフォルトはプロット構成や物語全般の姿勢を担い、あえて汎用的に作られています——多くのクリエイターにはそれで十分。ただし自分で緻密なコアロジックを書くなら、その汎用レイヤーが邪魔になります。作り込んだカスタムプロンプトを扱うクリエイターがよくオンにします。 |
| 感情画像をオフにする +500 | キャラクターの会話中の感情画像キューを止めます。通常、やり取りの中で感情が検出されるたびに、キャラクタープロフィール領域が画像を呼び出します。その検出は計算負荷が高く、感情ごとの立ち絵が要らないクリエイターは、その理由だけでオフにすることも多いです。 |
| 状況画像をオフにする +500 | キャラクターの感情ではなく、ナレーション中の状況画像キューに同じ考えを適用したものです。 |
| 旧式画像タグ付けを使用 変化なし | やめましょう。説明を手入力する旧式のタグ付け方式に戻ります。出力の質も精度も落ちます。本当の代償は、失敗が説明不能になること——完全に正しく見える呼び出しでも動かず、理由を教えてくれるものが何もありません。これはオフのままに。 |
公開設定 — キャンバスの外のページ
これらのフィールドはキャンバスの外にあり、AIには一切影響しません。いわば店頭——読者が「開始」を押す前に見る部分です。ほとんどのクリエイターはキャンバスの作業が終わるまでこのページを完全に無視するので、ここでも最後に置いています。
以下の数値——特にファイルサイズ——はプラットフォームによってわりと頻繁に変わります。「最終確認時点」の値として扱い、絶対のルールとは思わないでください。訂正は大歓迎です。
| Field | What to know |
|---|---|
| タイトル | 作品名。ローカライズを予定しているなら：韓国（KR）側では、タイトルに露骨・下品な表現は認められていません。翻訳しても通用するものを選びましょう。 |
| 概要 | 40文字制限。要約ではなく、一行のフック（引き）です。物語が実際どうなったか分かってから、最後に書くのが一番楽です。 |
| 詳細説明 | 最小限のMarkdownに対応：太字、多少の文字サイズ調整、簡単な表、外部ホスティングの画像。フルのMarkdownは期待しないでください——凝ったものは表示されません。画像は外部でホスティングしてリンクする必要があります。 |
| タグ | 対応言語すべてのタグを一度に全部入れてかまいません。プラットフォームが閲覧者の言語に合うタグだけを自動で表示するので、全言語で付けても損はありません。やっておきましょう。 |
| サムネイル | 4:5比率。WebPは最大5 MBまでアップロード可能（2026年半ばの更新で、旧来の約2〜3 MBの上限から引き上げ）。GIFは最終確認時点で約10 MB。プラットフォーム自身の注意書きに注目：高容量・多フレームの画像は、メイン画面に表示される縮小サムネイルで画質が落ちることがあります。理由不明でアップロードが失敗したら、まず容量を確認。 |
| イントロ動画 | MP4、最大200MB、2分の厳格な上限。長さに融通はききません——アップロード前にカットしましょう。 |
| 共同制作人員追加 | 他のクリエイターのStoryEngineアカウントのメールを入力して、作品に参加させます。相手にキャンバスへのアクセスを与えるかを制御でき、収益は10%刻みで分配できます。 |
| クリエイター設定 | どの共同制作者を代表クリエイターとして表示するかを選びます。クリエイターのニックネームまたはOIDを入力。 |
| StoryEngineオリジナル | StoryEngineに独占提供する作品向けの、任意の独占指定です。条件は2026年半ばに全面改定されました——精算率に%ポイントのボーナスが付くという古い説明を読んだことがあるなら、それはもう当てはまりません。以下の文面は英語圏のクリエイターが照合し、同一だと確認されたので、韓国限定ではありません。 有効化：初回公開の前、または公開後6時間以内にオンにします。月2作品までで、コラボ作品は全参加者それぞれの月上限に数えられます。 報酬：率のボーナスではなく、固定のマイルストーンで支払われます——1万チャット達成で10万ウォン、さらに5万で20万ウォン、作品の保存された収益分配率に従って分けられます。集計されるのは有効化後のチャットだけなので、有効化が遅れるとそれ以前の分はすべて失われます。 180日間ロック：作品の削除、非公開化、Originalの解除、他所へのアップロードができません。Originalが有効な間は共同制作者と収益分配率も変更できません——それらは有効化前に確定させておきましょう。 抜け道を狙わないこと。運営チームははっきり明言しています——他所で先に公開して時間差でここに上げる、あるいは同じビルドを別名で上げ直す、といった裏技は、例外なくBANになります。 |
サムネイル・タイトル・タグのコンテンツ規則は地域ごとに異なり、うっかり違反しやすいものです。
これは本当によくつまずくポイントです：作品がメインページ露出を制限されたり、フラグを立てられたりして、しかも制作者はそんな規則があると知らなかった、というパターン。プラットフォームは地域ごとに異なる法的環境のもとで運営されているため、正確な規則はどこでも同じではありません。もっとも大切な習慣は、公開前に自分の地域の活動ガイドラインを読むこと——以下の要約はあくまで出発点であり、最新の公式文書の代わりにはなりません。
— 韓国（KR）—
RPLAYの活動ガイドラインに基づきます。以下のいずれかに該当するサムネイルはメインページ露出が制限されます：
タイトルとハッシュタグにも、それぞれ制限ワードや必須タグのリストがあります（特定の露骨な語はメインページ露出を制限し、特定の特殊設定・アイデンティティ表現のタグは必須）。具体的な内容は最新のガイドライン本文を確認してください——リストは変わります。
— 日本（JP）—
（昨年）問い合わせた際の回答は、基準は出版物の検閲基準に準じる、というものでした。これはKRとは異なる基準で、その後変わっている可能性もあります。KRの規則がそのまま当てはまると考えず、公開前に現行の出版基準に照らして直接確認するのが安全です。
— 英語圏（EN）—
ここにも、適用される法律やプラットフォーム規則がほぼ間違いなく存在します。本ガイドでは詳細を明記していないので、公開前に自分の地域の規則を確認してください——「前回は消されなかった」は規則ではありません。
自分のアカウントを超えて、これが重要な理由：ある地域で法に触れるコンテンツはプラットフォーム自体を法的リスクにさらします。だからこそこうした地域規則が存在し、運用されているのです。規則を守ることは、みんなが公開している場を守ることでもあります。これらの詳細は「最終確認時点」のものであり、公式文書ではありません——迷ったら、プラットフォームの現行ガイドラインが優先します。
これは本当によくつまずくポイントです：作品がメインページ露出を制限されたり、フラグを立てられたりして、しかも制作者はそんな規則があると知らなかった、というパターン。プラットフォームは地域ごとに異なる法的環境のもとで運営されているため、正確な規則はどこでも同じではありません。もっとも大切な習慣は、公開前に自分の地域の活動ガイドラインを読むこと——以下の要約はあくまで出発点であり、最新の公式文書の代わりにはなりません。
— 韓国（KR）—
RPLAYの活動ガイドラインに基づきます。以下のいずれかに該当するサムネイルはメインページ露出が制限されます：
- サムネイルは上半身中心で構成すること。
- 性器・陰毛・肛門の露出は不可。
- 実写画像での乳首の露出は不可。
- 精液または精液を連想させる液体の表現は不可。
- 直接的な性行為を描写・連想させる画像は不可（モザイクの有無を問わず）。
- ディルド／性器の形をした自慰器具は不可。
- 著作権を侵害する画像、過度に刺激的・不快・差別的な画像は不可。
タイトルとハッシュタグにも、それぞれ制限ワードや必須タグのリストがあります（特定の露骨な語はメインページ露出を制限し、特定の特殊設定・アイデンティティ表現のタグは必須）。具体的な内容は最新のガイドライン本文を確認してください——リストは変わります。
— 日本（JP）—
（昨年）問い合わせた際の回答は、基準は出版物の検閲基準に準じる、というものでした。これはKRとは異なる基準で、その後変わっている可能性もあります。KRの規則がそのまま当てはまると考えず、公開前に現行の出版基準に照らして直接確認するのが安全です。
— 英語圏（EN）—
ここにも、適用される法律やプラットフォーム規則がほぼ間違いなく存在します。本ガイドでは詳細を明記していないので、公開前に自分の地域の規則を確認してください——「前回は消されなかった」は規則ではありません。
自分のアカウントを超えて、これが重要な理由：ある地域で法に触れるコンテンツはプラットフォーム自体を法的リスクにさらします。だからこそこうした地域規則が存在し、運用されているのです。規則を守ることは、みんなが公開している場を守ることでもあります。これらの詳細は「最終確認時点」のものであり、公式文書ではありません——迷ったら、プラットフォームの現行ガイドラインが優先します。
はい、このOriginalの条件はあなたにも同じです。マイルストーンの金額はウォン（KRW）で表記されており、韓国外のクリエイターには違うものが見えるのでは、という疑問は当然です。違いません。英語圏で活動するクリエイターScootさんが自分のアカウントでパネルを確認したところ、文面は同一でした——同じ対象条件、同じ6時間の有効化枠、同じ月2作品の上限、同じウォンのマイルストーン、同じ180日ロック。許可を得て共有しています。ありがとうございます。
これが何であるかを正確に言うと：会社からの公式発表ではなく、クリエイター同士の相互確認です。パネルが地域を問わず同じだという良い証拠ですが、あなたのアカウントで違いを見つけたら、ぜひ教えてください。
これが何であるかを正確に言うと：会社からの公式発表ではなく、クリエイター同士の相互確認です。パネルが地域を問わず同じだという良い証拠ですが、あなたのアカウントで違いを見つけたら、ぜひ教えてください。
多言語での公開——公開前に必ず読んでください。ローカライズしたテキストは、実際にアップロードボタンを押すまで反映されません。気づかないうちに中途保存の状態が生まれやすいので、すべての言語をアップロードして確認するまでは公開設定をPrivateにしておき、全部そろってから公開に切り替えましょう。
最近のパッチで、その「中途保存」状態が目に見えるようになりました。各言語は独立したキャンバスを持ち、コンパイルも別々に行われますが、言語タブに小さなステータスバッジが付くようになりました：オレンジの(!)はその言語のキャンバスに未保存の変更がありコンパイルが必要なこと、赤の(!)はエラーがあることを示します。以前はこうした表示が一切なく、自分で覚えておくしかありませんでした。今は、タブにオレンジの印が付いていれば、その言語版はまだ完全に保存されていないということ。ある言語が反映済みだと当てにする前に、すべてのバッジを消しておきましょう。（情報提供：トリ（STORY ENGINE）さん。）
同じバッジが、クリエイターの作品一覧にも表示されるようになりました（ごく最近の追加で、同じ日の少し前まではありませんでした）。おかげで、各キャンバスを開かなくてもどの作品に対応が必要かが分かります：作品の横のオレンジの(!)はコンパイルが必要、赤の(!)はエラーがあることを示します。色の意味はタブと同じで、一段上の階層に出るようになっただけです。
韓国のクリエイターの一般的なやり方：付けられる言語すべてでタグを付ける、上限が変わっても後で壊れないようサムネイルは表記された上限より余裕を持たせる、そして共同制作者の収益分配は公開後ではなく公開前に確定させる。
ツアーは以上です。ここに間違いがあったら——プラットフォームは動くので、いくつかは必ずあります——ぜひ教えてください：GitHubでissueを開く。訂正も計測も、クレジット付きで次のバージョンに直接反映します。
英語で書くのが苦手ですか？自分の言語でissueを開いて、どの言語かを書いてください——韓国語・英語・日本語・スペイン語ならどれでも大丈夫で、書かれた言語で返せるよう最善を尽くします。ざっくりした機械翻訳でも全然かまいません。言語のせいで報告をあきらめられるより、報告があるほうがずっといいので。
さあ、キャンバスを開いて、いろいろ押してみましょう。
英語で書くのが苦手ですか？自分の言語でissueを開いて、どの言語かを書いてください——韓国語・英語・日本語・スペイン語ならどれでも大丈夫で、書かれた言語で返せるよう最善を尽くします。ざっくりした機械翻訳でも全然かまいません。言語のせいで報告をあきらめられるより、報告があるほうがずっといいので。
さあ、キャンバスを開いて、いろいろ押してみましょう。
協力してくれた方々
このガイドの正確な部分の多くは、他のクリエイターが時間を割いて訂正・検証・翻訳してくれたおかげです。感謝を込めてお名前を記します：
| ㅇㅅㅇㅇㄴㄷ | シナリオ分岐の手法。読者のトークン予算（ペルソナと共有の2,000）の訂正。 |
| Scoot | StoryEngine Originalの条件を英語圏から照合。 |
| アヤイヤオ | サブモデルの記憶・変数の役割、トークン計測ツール、プロローグメッセージがAIにも読まれる点、ポート接続の一覧が全ノード共通である点、被りにくいトリガーワードの助言。 |
| yatoming | 日本語版の表現をネイティブ校正。 |
| 夢見月ひいな | Originalのロック期間が90日から180日に変わったことを指摘。 |
| Mukmul | Alwaysトグルと、マクロのキーワードをモード切り替えに使う例のスクリーンショット。 |
| NAFE | 20人以上のキャストを持つ作品から、キャラクター情報を常時ロードのスクリーンショット提供。 |
| トリ（STORY ENGINE） | 言語タブの新しいコンパイル状態バッジを指摘。（名前に反して、公式アカウントではありません。） |
報告したのに載っていない、または表記を変えてほしい場合は教えてください——抜けているのは単なる見落としで、他意はありません。