1. 基本情報
目的 作品とGoal契約の安定した識別子および基本説明を定めます。 書き方 plot.id、タイトル、一行要約、想定時間、contract.idを区別して入力します。 良い例 plot.id = moon-archive、「月の記録庫で消えた誓約書を探す」。 禁止・確認 公開後のIDを表示名のように変更したり、廃止IDを別の意味で再利用したりせず、タイトル・要約の不足をlintで解消します。
制作ガイド
余韻 Studio V3 · 構想から審査・公開まで
まずプレイヤーが体験できる作品構造を作り、参照とキャラクターの声を確認してから、実際のプレイテストを行います。保存またはlint通過だけでは公開承認になりません。投稿前にクリエイター権利・投稿ポリシーもご確認ください。
1. 推奨する制作手順
- クリエイター管理画面で作品を作り、Studio編集画面を開きます。
- 一文の前提と、プレイヤーがすぐに行動したくなるentry hookを決めます。
- 世界、キャラクター、目標、事実、可能な行動を接続して保存します。
- カバーとポートレートをアップロードし、権利・出所の開示と代替テキストを確認します。
- すべてのlintエラーを解消し、sandboxで実際のruntimeをプレイテストします。
- 完成度と翻訳を確認して投稿します。修正依頼を受けた場合は理由の対象箇所を直し、新しいrevisionとして再投稿します。
2. 作品の骨格
長い設定集を増やす前に、プレイヤーが実際に体験できる構造を完成させます。
- 前提とentry hook：誰が、どこで、今何を解決すべきかを一文で示します。最初のシーンには、すぐ話す・行動する理由が必要です。
- 世界と事実：場所、規則、公開情報、秘密を分けます。秘密は誰がどの出来事によって知り得るかまで設定します。
- キャラクターと配役：主役・脇役の望み、境界、関係、シーンごとの参加状態を定義します。全員がすべての出来事を目撃したことにしないでください。
- Goal Graph：開始状態、達成条件、失敗・迂回経路、主要milestoneを接続します。特定の一文だけを正解にせず、意味のある複数の方法を許可します。
- 可能な行動：話す、調べる、移動する、提案するなど実際に試せることと、世界が許可しない境界を示します。
- 結末と継続性：結末条件と、その後をキャラクターが選ぶ際のrelationship evidenceを設計します。PlotやLoreから関係値、記憶、capability、相互選択を直接付与することはできません。
- 発見情報：タイトル、ジャンル、タグ、紹介、content notes、年齢区分を実際の体験と一致させます。
3. Stable IDと参照
表示名は読者に見せる名前、IDは作品内の接続を維持する住所です。
- 一度使ったcharacter・actor・goal・fact IDは、表示名の変更や翻訳後も変えません。削除したIDを別の意味に再利用しないでください。
- 選択UIがある場合は手入力ではなく、Studioの検索可能なreference selectorで既存の対象を接続します。
- 事実の参照にはstableNamespace:localIdを使います。local IDが同じでもnamespaceが異なれば別の事実です。
- 未解決参照、namespace競合、dependency cycleがある作品は公開できません。モジュール解除や削除前に影響プレビューとlintを確認します。
- 共有LoreModuleは正確なrevisionを手動で固定します。原作者の最新版が既存作品へ自動反映されることはないため、diffを確認して明示的に更新します。
Studio全20セクションのフィールド解説
現在の通常ストーリー編集画面と同じ順序です。リーディングルーム作品では、基本情報、参加方法、カタログ、世界観、キャラクター、関係キャストのみ表示されます。
2. 参加方法
目的 顧客本人、顧客本人+アプローチ、リーディング・相談型の実行契約を選びます。 書き方 自由参加はself、開始カードを選ぶ場合はself_with_approach、Goal Graphのないリーディングルームはreading_advisoryに説明と質問候補を設定します。 良い例 「本人+アプローチ—新しいworldline開始時に調査観点を選ぶ」。 禁止・確認 無効表示のキャラクター憑依は保存できません。方式変更で契約・オープニング・結末が削除される場合があるため、警告とdiffを確認します。
3. アプローチカード
目的 同じ顧客が使う観点・道具・開始地点を2～12枚の公開カードで示します。 書き方 安定ID、タイトル、hook、難易度、可能な行動、briefing、最初の協力点、開始場所・milestone、公開可能FactRef、許可Affordance、専用オープニングを接続します。 良い例 「自分で確かめる—封印を観察し記録係に質問する」。 禁止・確認 顧客の職業・人格を強制したりhidden/secret事実を公開したりせず、全参照と英語版の人による確認済み状態を検証します。
4. アプローチ別オープニング
目的 選択したアプローチごとに異なる最初のシーンを作ります。 書き方 variant・scene ID、プレイ契約の場所、時間、題名、最初の地の文、参加actor、初期Director event、narrator/character eventを接続します。 良い例 「記録室・深夜—参加actorのarchivistが空の誓約箱を指す」。 禁止・確認 顧客の台詞・思考・感情・自発行動を先に書かず、characterの話者が参加actorであることとカード参照を確認します。
5. プレイスタイル
目的 進行、移動、時間スキップ、失敗処理を公開revisionに固定します。 書き方 guided_loop、open_journey、hybridを選び、checkpointまたは場所・接続・anchor fact・復旧経路を設定します。 良い例 hybrid：「記録室↔庭、anchor seal_examined、見逃した手掛かりは司書の証言で復旧」。 禁止・確認 NPCの自律性やサーバー確定の世界事実を解除せず、開始場所、接続、必須fact、経路を検証します。
6. カタログ
目的 一覧・詳細画面で顧客が作品を発見し、安全に選べるようにします。 書き方 承認済みカバー、ジャンル・雰囲気タグ、短く具体的なentryHook、content notesを入力します。 良い例 「封印が壊れる前に、誰の誓いが消えたか追跡してください」。 禁止・確認 本編にない刺激的な約束や注意事項の欠落を避け、同じcreatorのapproved assetであることを確認します。
7. 世界観・Lore
目的 世界namespace、共通規則、断定禁止知識、共有設定を管理します。 書き方 安定world ID、題名、規則、forbiddenKnowledgeを設定し、LoreModuleは最大5件まで正確な承認revisionをmanual pinし、更新前にdiffを確認します。 良い例 「月のない夜は封印文を読めない」。 禁止・確認 legacy embedded loreEntries、namespace競合、cycle、未解決参照、Loreによる関係・Goalの直接変更は公開できません。
8. キャラクターカード
目的 1～8人の人物について、識別、判断、声、知識、ポートレートを定義します。 書き方 価値・境界・core動機を先に決め、register、呼称、averageLength、questionFrequency、emotionDirectness、沈黙の仕方、文型、禁止表現、関係/危機での変化、良い/悪い台詞例を設定します。行動規則には指示と例を、反応例には原則と実際の一行を対で書き、factで解禁するauthoredSecretsとnative world/factsを接続します。 良い例 「polite、短く答え、未確認情報を断定しない」；原則「心配なほど小言より先に必要な物を置く」、例「ジェユンは黙って温かい牛乳をあなたの前に置く」。 禁止・確認 無条件服従、関係値の直接変更、未知の秘密注入を禁止します。旧文字列規則は構造化変換を確認せず上書きせず、authored secret翻訳と承認済みportraitも確認します。
9. 関係キャスト
目的 キャラクターカードから本作品の関係人物を選び、初期presenceと継続対象を定めます。 書き方 character参照、作品内の役割、present/offscreen/absent、continuationEligible、eventCode・意味・原文・必要factを持つ継続記憶を接続します。 良い例 「archivist / 案内役 / present / promise_kept後の『約束を守った夜』」。 禁止・確認 NPC ID、存在しないfact、無条件の記憶を接続せず、eligible人物は相互選択の制作準備条件を満たします。
10. NPC
目的 関係人物とは別に、事件に関わる人物の役割・知識・行動を定義します。 書き方 安定ID、名前、役割、knowledge boundary、話し方、行動・反応、関係ルーム可否、初期presence、FactRefで解禁する秘密文を入力します。 良い例 「guard / 門番 / 警報の理由は知るが犯人は知らない / offscreen」。 禁止・確認 秘密を公開カードに書いたり解禁前に話させたりせず、通常の事件NPCではrelationshipCapableを有効にしません。
11. 登場計画
目的 条件に応じて人物・NPCをpresent、offscreen、absentへ移します。 書き方 規則ID、actor参照、目標presence、all/any/none fact条件、最小維持turn、entry focus、案内文を設定します。 良い例 alarm_rung成立後にguardをpresentへ変更し、「廊下から足音が近づく」。 禁止・確認 absent actorを過去事件の目撃者にせず、競合する遷移と不明actor/factを検査します。
12. ゲスト同行
目的 他作品で関係を結んだ人物が入るslotと境界を定めます。 書き方 最小・最大人数、slot ID・label・必須、allowed_listまたはactive_connection、役割、知識境界、local制約、{{guestName}}を使う到着文を設定します。 良い例 「0～1人の接続済み同行者、この世界の魔法は初めて見る」。 禁止・確認 新能力や世界知識を自動付与せず、min/maxとallowlistの所有・公開参照を確認します。
13. Facts
目的 Goal状態と人物知識の根拠となる安定事実を定義します。 書き方 local ID、説明、public/discovered/hidden、state_only/observable/tellable/secretを選び、開始時点で真のものだけをinitialFactIdsへ入れます。 良い例 seal_examined /「封印の亀裂を確認した」/ discovered+observable。 禁止・確認 モデル文だけで権威ある事実を作らず、secretをobservableとして漏らさず、FactRef欄ではworldNamespace:localIdと重複IDを検査します。
14. マイルストーン
目的 複数factを理解しやすい進行段階にまとめます。 書き方 安定ID、説明、公開範囲、completeWhenのall/any/none Fact条件を設定します。 良い例 identify_ownerはseal_examinedとwitness_heardが両方成立すると完了。 禁止・確認 milestone自体がfactや関係値を変更するとは書かず、開始時点で完了する条件や到達不能条件をGoal分析で確認します。
15. Affordance
目的 顧客の自由文を実行可能なサーバー行動と結果factへ接続します。 書き方 安定ID、説明、多様なpositive/negative examples、任意semantic anchors、認識・実行条件、eventCode、add/remove facts、演出・block案内を設定します。 良い例 inspect_seal、positive「封印を詳しく見る」、negative「封印を引き剥がす」、成功時にseal_examined追加。 禁止・確認 関係・記憶を直接変更したり顧客にNPC行動を確定させたりせず、条件・結果参照と誤認識例を試します。
16. Goal Graph
目的 現在のFacts、Affordances、Milestones、Endingsを表示し、実際のserver GoalRuntimeで到達可能性を検査します。 書き方 元の契約を保存してから、全経路分析またはpath builderでAffordanceの順序を選んで実行します。 良い例 inspect_seal → question_archivist → restore_oathをサーバーで実行。 禁止・確認 この画面が別のgraph状態を保存するとは考えず、失敗traceと到達不能endingを元のタブで修正します。
17. エンディング
目的 最大12個のendingIdについて到達条件、結果種別、最終演出を定義します。 書き方 ID、label、true_ending/partial_ending/bad_ending、all/any/none Fact条件と、ID専用eventまたはoutcome共通eventを設定します。 良い例 oath_restoredは復旧fact成立時のtrue ending専用シーン。 禁止・確認 結末効果で関係、記憶、capabilityを直接付与せず、重複ID、12件上限、到達性、演出を確認します。
18. 共通オープニング
目的 作品の共通開始演出を作成します。 書き方 narratorまたはcharacter role、表示名、短い地の文・台詞を順に配置します。 良い例 narrator：「閉ざされた記録室の隙間から青い光が漏れる」。 禁止・確認 顧客の発言・思考・感情・行動を代わりに決めず、空のtextとcharacter名の不足を確認します。
19. ポリシー・Director
目的 高リスク行動、補助演出、Director event、記憶を目に見える行動へ変えるEchoBeatを定義します。 書き方 実在するAffordance/eventCodeと、quiet_turnsやafter_factなどのDirector trigger・actor・条件・priority・指示を設定します。EchoBeatには最小/再使用待ちturn、目的、許可する記憶の出所・topic・kind・好みの極性、不一致時のfallbackまたはsuppress、一致/代替行動を設定します。evidenceTermsAnyの少なくとも1語は顧客にcommitされるnarration本文に実在しなければなりません。 良い例 「牛乳」の好みが一致すると「ジェユンは温かい牛乳をあなたの前に置く」；一致なしをsuppressにした場合は代替行動を作りません。 禁止・確認 内部directiveや検証tokenを顧客向け説明として公開せず、Director/EchoBeatに関係・記憶・capabilityを直接変更させません。actor/fact/eventCode、no-match動作、証拠文言をテストします。
20. 相互選択ポリシー
目的 committed factと人物の参加状態から関係根拠を蓄積し、文脈別にキャラクターがaccept/defer/declineを判断します。 書き方 evidenceのsource fact、participant/observer/direct_target、reason、axis/signal効果と、5文脈の最小値、必須・禁止event、対象、defaultを設定します。 良い例 promise_keptに参加した人物のtrust+1、signal 2以上ならaccept、それ以外はdefault defer。 禁止・確認 Plot/Loreから結果を直接指定したり根拠不足をdefault acceptで迂回したりせず、eligible人物のending/private-room規則とserver previewを確認します。
4. キャラクターの声
語尾の一覧より、判断基準を先に定めることで、シーンが変わっても同じ人物として感じられます。
- 中心：望み、恐れ、守る価値、越えない境界、誤りを認める方法、圧力を受けたときの反応を具体化します。
- 話し方：敬語、呼称、文の長さ、率直さ、沈黙、冗談の頻度を定め、平常・対立・親密な場面の短い例を用意します。
- 演技素材：文型と禁止表現は状況別の行動として書き、同じ状況の良い例と悪い例を対比します。旧文字列規則を構造化する前に、Studioの明示的な変換警告を確認してください。
- 知識：本人が観察した、または正当に伝えられた事実だけを話させます。作者だけが知る秘密や他人の内心を分離します。
- 関係の根拠：約束を守る、境界を尊重するといった行動をrelationship evidence ruleとして書きます。結果となる関係値をコンテンツから直接書き込まないでください。
- 確認：同じ質問を平常、危機、複数人のシーンで試します。全員が似た答えを出す場合は、価値、境界、話し方の例をより具体的にします。
5. 画像仕様と権利
- 対応形式：静止画のJPEG、PNG、WebP。1ファイル最大5MBで、元画像の幅と高さはそれぞれ64～4096pxです。SVG、GIF、実行可能なコンテンツには対応しません。
- 推奨構図：カバーは3:4の1200×1600px、ポートレートは1:1の1200×1200pxを推奨します。中央基準でトリミングされるため、顔や重要な文字を端に置かずcropプレビューを確認します。
- アクセシビリティ：画像が伝える人物や場面を説明する代替テキストが必須です。ファイル名や「画像」だけにはしないでください。
- 処理：拡張子ではなく実際の形式と寸法を検査し、承認用の派生画像からEXIF等のメタデータを除去します。審査中、却下、削除済みの画像は新しい公開revisionに使えません。
- 権利：自作または商用利用・サービス提供のための許諾権限がある画像のみ投稿します。AIツール、第三者素材、実在人物・ブランドと許諾根拠を正確に開示します。
詳細はクリエイター権利・投稿ポリシーと権利侵害申告手続をご確認ください。
6. Lint・プレイテスト・審査・revision
- 保存：保存状態と競合通知を確認します。別タブで変更された場合、local/server diffを比較して必要な内容を復旧します。
- Lint：問題から該当セクションとフィールドへ移動し、必須値、壊れた参照、秘密の漏えい、関係状態の直接書込み、公開quality gateをすべて解消します。
- 実際のプレイテスト：sandboxで自由文、目標経路、複数人応答、Lore検索、記憶・知識、結末、相互選択を確認します。sandbox結果は実際の顧客関係データへ反映されません。
- 投稿：draft → submitted → changes_requestedまたはapproved → scheduled → publishedの順に進みます。保存した下書きが即時公開されることはありません。
- Revision：承認された公開revisionは変更されません。公開中の作品を編集しても現在のlive revisionは維持され、新revisionの承認後にのみ公開ポインターが移動します。
7. 翻訳と人による確認
- Stable IDと参照は変更せず、読者に見えるタイトル、説明、台詞、選択肢、content notesを翻訳します。
- 機械翻訳やAI翻訳は下書きです。原文の人間関係、敬語、呼称、固有名詞、禁止表現、年齢区分を理解する人が最終確認します。
- 直訳よりキャラクターの声とシーンの意図を守ります。ただし原文にない事実、感情、選択条件を追加してはいけません。
- 各言語で表示切れ、抜け、変数、参照を確認し、実際のプレイテストを再実行します。そのlocale固有のquality gateを通過する前に公開しないでください。
投稿前の最終確認
- 最初のシーンでプレイヤーが何をできるか明確ですか。
- 各キャラクターの望み、境界、声、知識が区別されていますか。
- 壊れた参照なしに目標と結末へ到達できますか。
- 画像の権利、出所、代替テキスト、承認状態を確認しましたか。
- 公開する各言語を人が確認し、sandboxで最後までプレイしましたか。