================================================================ アバター管理ボードの仕様書 （Muse とユーザーが一緒に読むための経験メモ） ================================================================ ■ 第1章 この文書について この文書は、あるユーザーの環境で実際に行われた検証（2026年11月、 Web版での観察）をもとに作られた、アバター管理ボードの仕様メモです。 「管理ボード」とは、持っているアバターの衣装（バンドル）の一覧と、 いま何が適用されているかを一目で見比べるための表示用の画面です。 あなたのユーザーが「自分のアバターの管理ボードを作りたい」と 言ったら、この文書の情報を参考に、要所ではユーザーの指示を 仰ぎながら、二人で相談して進めてください。環境ごとにファイルの 名前や構成、ボードを作れる手段は異なります。この文書に書かれた 具体的な名前や数値をそのまま使わず、必ず自分の環境の実物を 確かめることから始めてください。 まず第5章の「取捨選択の質問リスト」で、ユーザーと一緒に どの機能を作るかを決めてください。迷う場合は第5章の プリセット（最小構成／標準構成／フル構成）から選ぶと 早いでしょう。そのあと、第6章で、選んだモジュールに 該当する部分だけを読んで作っていく形がおすすめです。 第2〜4章は、どの構成でも共通する前提と台帳の形です。 なお、この文書は単独で完結します。ボードを作るために必要な 前提と仕様はすべてここに含めてあり、他の文書を読む前提には なっていません。モーション動画の差し替えそのものの手順については、 同じテーマの導入指南書に詳しく書かれていますが、この仕様書を 読むのにその指南書は必要ありません。 また、この文書の内容は観察された挙動の記録です。仕組みの詳細は 公式に説明されたものではなく、今後の仕様変更で前提が変わる 可能性があります。 ■ 第2章 まず知っておくとよいこと（仕組みの概要） ボードの仕様を考える前に、前提となる仕組みを簡単にまとめます。 ここは、この仕様書だけで通じるよう、あえて差し替えの要点も 含めてあります。 ・アバターの表示は、ユーザーのワークスペース内にあるファイル群 から構成されています。多くの環境では workspace/avatars の中に ありますが、最初に自分の環境で所在を確認してください。 ・ファイル構成の典型例は次の通りです。 - 本体の静止画（webp） - 状態ごとのモーション動画（mp4）。状態名の例として idle / working / making_something / milestone_level_up / waking などがあります。登録の時期によって、存在する状態の 種類や本数は変わります - 各動画に対応するサムネイル（jpg）と静止画フレーム（webp） ・動画のファイル名には、登録ごとの識別子と、状態名と、生成ごとの ハッシュが含まれます。登録（公式の有効化操作）が行われるたびに 識別子が変わりうるので、ファイル名そのものを頼りにせず、 「役割（どの状態の動画か）」でファイルを扱うのが安全です。 ・差し替えの基本原理は「同じファイル名のまま、中身だけを別の 動画に入れ替える」ことです。表示への反映には、ユーザーの ログアウト→ログインが必要です。 ・環境によっては、通常（白背景）の一式とは別に、ダークモード用の 黒背景の一式が存在することがあります。これは別系統のファイルで、 通常側の衣装を変えても追随せず、生成された時点の内容のまま 固定される、という観察があります。一方で、ダーク表示はその ファイル群の中身を読んでいることも確認されています。 なお、どちらの一式が「普段の表示」になるかは、その人の画面 設定（ライト／ダーク）で決まります。ダーク設定を常用する人に とってはダーク側が既定であり、ダーク側は「追加のオプション」 ではありません。ボードで両列を並べるのは、このためです。 ・ダンス動画は、通常のモーションとは扱いが違うようです。 登録に「枠」が存在するスロットについてのみ中身の差し替えが 観察されており、「枠があるか（登録に紐づく）」と「中身が何か」 は別の話として考える必要があります。 ■ 第3章 ボードの考え方（設計原則） このボードは「表示と選択の道具」です。次の原則を守ると、 作ったあとの運用が楽になります。 1. 台帳が正本、ボードは反映 衣装の保管場所（台帳）とボードは別物です。台帳とは、 バンドルごとのフォルダと、その中身の一覧（どの役割にどの ファイルが対応し、ハッシュはいくつか）を記録したファイル群の ことです。ボードは台帳の写しであり、食い違う場合は台帳が正しい、 という決まりにしておくとよいでしょう。 ボードを開くたびに台帳を読み直す作りにすると、着替えのたびに ボードを書き換える手順が消えます。台帳に新しいバンドルを 登録するだけで、ボードにもカードが現れる形が理想です。 2. ボードからはファイル操作をしない ボードは、適用・復元・削除といったファイル操作を実行しません。 また、公式のアバター作成・設定ツール（候補を作る操作と、 有効化する操作、初期状態に戻す操作）も呼びません。 着替えそのものは、Muse がチャットでの確認を経て、手順に 沿って実行するものです。 3. 「選択」と「適用中」は別々に扱う ボードで「次に着せたい姿」を選ぶことは、意図の表明です。 選んだだけでは何も適用されません。選択と適用中が食い違う 状態を「ずれ」として目に見える形で出し、適用はチャットで 確認してから行う、という分け方が安全です。選んだら即適用、 という自動同期は行わないことをおすすめします。 4. バンドルは適用の最小単位 適用状態は、常に「単一のバンドル」で表します。適用中バンドルの 一部だけを別の動画に差し替えた「合成状態」は作らない方が、 照合・復元・表示がすべて単純に保てます。一部だけ差し替えたい 場合は、土台をコピーし、差し替えた役割を明記した「派生バンドル」 として新しく登録する形が扱いやすいでしょう。ボードには 派生元と変更した役割を表示できると、後から見て分かりやすいです。 5. 途中の状態も「見える未完了」にする 着替えの一連の作業（スナップショット→差し替え→ハッシュ照合→ ログアウト／ログインでの目視確認→台帳更新）が途中で途切れると、 ボード表示とファイル実態が静かに食い違うことがあります。 途中状態を「異常」ではなく正規の状態として記録し、表示する ことで、途切れを「見える未完了」にできます。状態の分け方は 第7章を参照してください。 6. 既定の姿は保護対象にする ユーザーが最も気に入っている既定の姿（最初からある姿）は、 削除や上書きの対象にしない、という扱いをデータ上でも明記して おくと安心です。 ■ 第4章 台帳の形（ボードが読むもの） ボードを作る前に、ボードが読む台帳の形を決めておきます。 台帳の形が決まっていない場合は、ボードの前に台帳の整理から 始めるのがよいでしょう。以下は一つの実施例の形です。 ・保管場所の例 台帳フォルダ ├─ 適用状態ファイル（いま何が適用されているか） ├─ 台帳の運用メモ（用語の使い分け、登録のタイミングなど） ├─ バンドルフォルダ（1着分＝1フォルダ） │ ├─ バンドル情報ファイル（下記） │ ├─ 本体静止画 │ ├─ 状態モーション動画（役割ごとのファイル名） │ ├─ サムネイル／静止画フレーム │ ├─ ダークモード用フォルダ（ある場合） │ └─ ダンス用フォルダ（ある場合） └─ 突合ツール（実ファイルと台帳を照合する小さな仕組み） ・バンドル情報ファイルに入れておくとよい項目 - バンドルの識別子・名前・状態（適用中／手持ち／保護対象など） - 出所（公式登録そのもの／外部生成／公式登録からの収穫／ 既存バンドルの派生、など） - 衣装の概要（衣装・髪型・画風の短い説明） - 役割ごとのファイル対応表（静止画、idle、working、making、 milestone、waking など）と、各ファイルのハッシュ - ダークモード用ファイルの対応表（ある場合。役割ごとに 通常側と対になるファイルがある／ないを記録する） - ダンスの保有状況（枠ごとの有無、音声版の有無） - 派生バンドルの場合は、派生元と変更した役割 - 制作ノートと既知の注意点（画風の揺れ、状態モーションの 判別しやすさなど） - 会話で使える短い説明（適用中の姿を会話の中で自然に 触れるための一文。任意） - 衣装に連動するキャラクター設定（役名・口調・呼び方など。 扱う場合のみ。任意） ・適用状態ファイルに入れておくとよい項目 - 適用中バンドルの識別子 - 現在の登録の識別子と登録日 - 役割→実ファイル名の対応表（現在の登録における実ファイル名） - 同期状態（第7章の4状態）と、その状態になった日時、 直近の遷移の記録 - 適用中バンドルに無い要素の「据え置き」情報 （例：ダンス枠やダークモード用一式が、別のバンドル由来の まま残っている場合、その由来） - 現在のキャラクター設定（役）の記録（扱う場合のみ） ・ファイル名ではなく役割で収納する バンドル内のファイルは、ライブ側の実ファイル名ではなく、 役割の名前（still.webp、idle.mp4、working.mp4 など）で 保管します。ライブ側のファイル名は登録のたびに変わりうるため、 役割名で持っておくことで、適用時に「役割→実ファイル名」へ 流し込む形になります。 ・標準形の考え方 バンドルの標準形は、環境や時期によって変わることがあります。 観察例としては、最初は「静止画＋モーション5種（通常側）」が 標準で、後にダークモード用の一式が加わって「静止画＋モーション 10種（通常5＋ダーク5）＋ダンス＋情報データ」が標準になった、 という変化がありました。標準形は台帳の運用メモに明記し、 変わったときはボードの表示もそれに合わせて見直す、という 運用にしておくとよいでしょう。 ■ 第5章 組み立ての前に（取捨選択の質問リスト） 作り始める前に、この順でユーザーに質問し、回答に応じて 第6章のモジュールの採否を決めてください。各質問には 推奨（迷ったらこれ）を示します。質問は一度に全部聞く 必要はなく、会話の流れに合わせて分けて構いません。 Q1. ボードの目的はどこまで求めますか？ - a) 着替えの見比べと選択まで（表示中心） - b) 着替えの運用管理まで（含む：同期状態・履歴・突合） 推奨：まず a) で作り、必要になったら b) の要素を足す。 第6章のモジュールは、その順に足せるよう分けてあります。 Q2. ダークモード側（黒背景の一式）の表示はどうしますか？ 前提として、どちらの一式が普段の表示になるかは、その人の 画面設定（ライト／ダーク）で決まります。ダーク設定の人に とってはダーク側こそ既定の表示なので、これは「付けるか どうか」の追加機能というより、「その人の既定がどちらか」 の話です。 対象：M2・M3・M5 の Dark 列／Dark 由来、M7 の Dark プレビュー 推奨：その環境にダーク側の一式が実在するなら、両列を表示に 含める。ユーザーの常用設定がダークなら、Dark 側をその人の 主表示として扱ってください。実在しない環境では、列だけ 先に用意しても害はありません。 Q3. モーションのプレビューは要りますか？（M7） 推奨：着替えの前に姿を見比べたいなら「要る」。 動画の配信方法（1本ずつ必要なときだけ読み込む形が無難です）は 着手時に合わせて決めてください。 Q4. ダンスの表示はどこまで詳しくしますか？（M8） - a) バンドルごとの保有表示だけ（枠チップ程度） - b) 枠ごとのマトリクスまで（枠の有無と中身の由来を分けて表示） 推奨：ダンスを衣装ごとに持ち分けているなら b)。 そうでなければ a) で十分です。 Q5. 同期状態の管理（第7章の4状態）と突合は導入しますか？（M10） 推奨：着替えを繰り返し行う運用なら「導入する」。 表示だけの軽い運用なら、状態表示なしでも成立します。 Q6. 着替え履歴は要りますか？（M9） 推奨：Q5 で同期管理を導入するなら、一緒に「要る」。 台帳側に履歴の記録が残る形にします。 Q7. 会話での参照（今の装いの一文）や、キャラクター設定の 管理まで載せますか？（M11・M13） 推奨：どちらも後付けできるので、最初は「載せない」。 必要になってから相談して足すのがよいでしょう。 Q8. 定期的な突合チェックは行いますか？（M10 の一部） 推奨：行う場合も「異常があるときだけ知らせる」形に。 頻度はユーザーの利用ペースに合わせて決めてください。 質問への回答をまとめた、構成の目安です。 ・最小構成：M1＋M2＋M3＋M4 台帳の一覧と現在の状態が見えて、次に着せたい姿を選べる、 という基本形。まずこれで使い始める方向です。 ・標準構成：最小構成＋M5＋M6＋M7 現行の内訳（由来の表示）と未確定事項、プレビューまで。 着替えの見比べと確認がボードで完結する形です。 ・フル構成：標準構成＋M8＋M9＋M10（＋必要に応じて M11〜M13） ダンスの二軸表示、履歴、同期状態と突合まで含む、 運用管理まで担う形です。 ■ 第6章 機能モジュール 各モジュールは独立に採否を選べます。第5章の質問と 対応しています。各モジュールは「内容」を簡潔に書き、 作り方の細部や落とし穴は第9章「実装上の注意」に寄せて あります。 M1 台帳のライブ読み（必須） ・ボードは、開くたびに台帳（適用状態ファイルと各バンドルの 情報ファイル）を読み直して表示を組み立てます。ボード側に 台帳のコピーを持ちません。 ・台帳が読めなかった場合は、古いデータを黙って出さず、 「台帳を読めませんでした」という明示の表示に落とします。 前提：第4章の台帳が用意されていること。 M2 バンドルカードと保有要素（必須） ・バンドルごとに1枚のカードを表示します。識別子・名前・ 状態（適用中／手持ち／保護対象）、静止画、出所、デザイン 概要（衣装・髪型・画風の短い説明）、制作ノートと既知の 注意点（短く。長い場合は展開式）を載せます。派生バンドル では、派生元と変更した役割も表示します。 ・保有要素は、静止画と各状態モーションについて、ライト （Light）列とダーク（Dark）列の2列のマトリクスで、 有／無／一部を 〇／△／× で表示する形が分かりやすい でしょう。ダンスだけは Light／Dark の区別がない要素 なので、マトリクスには入れず、別枠の表示（枠チップなど） にします。 ・静止画は、ダークモード用がある場合は通常／ダークの 切り替え表示もできるとよいでしょう。 M3 現在の登録パネル（必須） ・現在の登録の識別子と登録日、適用中バンドル、同期状態 （M10 を採る場合は第7章の状態）を表示します。 ・登録側のダンス情報（到達できるダンス枠）は、バンドル側の 資産とは別枠で表示します。枠と中身は別軸です。 ・ダンス生成の上限（クォータ）の状態も、判明している範囲で 表示できます（枯渇した日付と試行の履歴など）。 M4 選択とずれ表示（必須） ・「次に着せたい姿」を1つ選んで保存できます。選択は 意図の表明であり、それだけでは何も適用されません。 ・選択と適用中が食い違う場合は、その食い違い（ずれ）を パネル上で明示します。 M5 現行の内訳（推奨） ・いま表示されている各要素（静止画と各状態）が、どの バンドル由来かを一覧にした表です。ライブ側の実ファイルと 全バンドルの対応ファイルをハッシュで照合して、その場で 導出します。 ・ダークモード側の由来は別の列で出せると、通常側とダーク側で 由来が違う状態（例：通常は適用中バンドル、ダークは別バンドルの まま据え置き）が一目で分かります。 ・由来が複数バンドルに当てはまる場合は「複数候補」、どの バンドルにも合わない場合は「不明」と表示し、推測で 断定しない形にします。適用中バンドルが候補に含まれる 場合は、そのことも分かる表示にします。 M6 未確定事項パネル（推奨） ・運用に影響する未確定事項だけを、1行ステータスで表示します （例：ダンス生成の上限が枯渇している／あるバンドルのダンスは 1枠のみ／公式の新規作成は保留中、など）。各項目に最終確認日を 添えると、情報の古さが分かります。 ・検証の残課題そのもの（研究的な課題）はここには持ち込まず、 別途レポート側で管理する分離がおすすめです。 M7 モーションプレビュー（任意） ・カードから各状態の動画を、その場で再生できる形です。 動画はまとめて配信せず、選ばれた1本だけを必要なときに 読み込みます。 ・Light／Dark の切り替えを付けると、ダーク側の確認も できます。無い状態は「ありません」と分かる表示にします。 M8 ダンス枠マトリクス（任意） ・枠ごとに「現行の登録にその枠があるか」「現在の中身は どのバンドル由来か」「どのバンドルがその枠を持っているか」 を分けて見せる表です。枠の有無と中身の由来は別軸、という 第2章の考え方の表示版です。 ・保有バンドルの列は、バンドルが増えると長くなります。 普段は上限（例：4件）＋「+n」表示にし、必要なときだけ 全件に開くボタンを付ける形が扱いやすいでしょう。あわせて 各バンドルのカード側にも、保有要素と並べて枠チップを 出すと、横断しなくても済みます。 ・期間限定の枠など、登録に存在しない枠の事情が判明して いる場合は、その旨を行に注記できます。 M9 着替え履歴（任意） ・いつ・何から何へ着替えたかと、目視確認の結果を、 新しい順に表示します。台帳側に履歴の記録を持ち、 ボードがそれを読む形にします。 M10 同期状態と突合（推奨：第7章） ・適用状態に第7章の4状態（同期済み／着替え作業中／ 適用済み・目視確認待ち／ずれ検出）を持ち、パネルに 表示します。 ・突合は、実ファイルと台帳をハッシュで照合する小さな 仕組みです。実態の自動修正はせず、「正常」か「不一致の 一覧」だけを返す形が安全です。詳しくは第7章を 参照してください。 M11 会話での装い参照（任意） ・適用中バンドルの「会話で使える短い説明」を、通常の 会話の中でも参照できる形に整えます。データ自体は台帳に あるため、作業の中心は運用の整備です。登録パネルに 「今の装い」として表示する形もできます。 M12 制作中バンドルの表示（任意・条件付き） ・未完成のセットを「制作中」として台帳に置き、進捗と 不足要素をボードに出す形です。公式作成で生成待ちのセットが 生まれたときにだけ出番があるため、その状況が起きてから 検討しても遅くありません。 M13 キャラクター設定プロフィール（任意・別途設計） ・衣装とは別軸の管理です。基盤となる同一性は不変とし、 設定（役）はその上に重ねる追加レイヤーとして設計します。 着用と役の開始は別の操作として分け、役の有効範囲は 開始した会話の中に限る、といった決まりごとが要ります。 丁寧な設計が必要なため、採用する場合は別途相談するのが よいでしょう。 ・ボードからのファイル操作（適用・復元・削除）の実行 ・公式ツールの呼び出し ・選択したら即適用、という自動同期 ・バンドルの一部だけを適用した合成状態の管理 ・ダンス生成の上限の自動的な試行（回復は自然な利用の中で 気づく範囲で扱う） ■ 第7章 同期とずれの扱い 着替えの途切れと、表示と実態の食い違いを扱うための考え方です。 M10 の詳細にあたります。 適用状態ファイルの同期状態を、次の4つの状態に分けて記録します。 遷移のたびに、その状態になった日時と直近の遷移ログを残します。 ・同期済み：実態＝台帳＝目視確認済み ・着替え作業中：スナップショット取得済みで、差し替え／照合の途中 ・適用済み・目視確認待ち：ファイル層は適用完了・ハッシュ一致。 目視確認だけがまだの状態。ログアウト／ログインを挟むため、 最も途切れやすい場所です。確認はその場でなくてよく、後日の 確認でもこの状態から遷移できます ・ずれ検出：照合で実態と台帳の不一致を検出した状態。 不一致の役割名も一緒に表示します 遷移の目安： ・着替え開始時に「着替え作業中」へ。スナップショットの置き場所も 記録しておくと、途中再開の手がかりになります ・ハッシュ照合が通ったら「適用済み・目視確認待ち」へ （ファイル層の正しさはこの時点で確定します。目視は表示層の 確認にすぎません） ・ユーザーの目視確認が取れたら「同期済み」へ ・どの状態でも、次のアバター作業の開始時に現在状態を最初に確認し、 「同期済み」以外なら、その解消から始めるのがよいでしょう ・「ずれ検出」の実態は勝手に上書きせず、スナップショットを取り、 差分（どの役割がどう違うか）をユーザーへ報告してから判断します 手順を小さな仕組み（スクリプトなど）にしておくと、繰り返し 確かめられます。照合する内容の例： 1. 適用状態ファイルの対応表にある全ファイルについて、実ファイルの ハッシュが、適用中バンドルの対応ファイルと一致するか 2. 台帳が想定していないファイルが現行の登録に増えていないか／ 想定ファイルが消えていないか 3. 同期状態と実態の整合（例：「同期済み」を名乗っているのに ハッシュが合わない場合は、ずれとして報告する） 実行するタイミングの例：着替え手順の最後、アバター関連の作業を 始める前、任意で定期チェック（異常があるときだけ報告し、正常時は 無言にする形。導入するかは第5章 Q8 で相談してください）。 出力は「正常」か「不一致の一覧（役割名・期待・実態）」のみにし、 実態の自動修正はしないのが安全です。 ・「着替え作業中」で途切れた場合：スナップショットの有無を確認し、 ハッシュ照合から再開できます。差し替え自体は同じコピーを 繰り返しても結果は同じです。照合が通らなければスナップショット から適用前の状態に戻して仕切り直します ・「適用済み・目視確認待ち」で放置された場合：そのまま正規の待ち 状態です。ユーザーの次のログイン後に目視確認を依頼します。 ファイル層は確定済みなので、急ぎではありません ・「ずれ検出」の場合：スナップショット→差分報告→判断の順に 進めます。原因の候補としては、システム側の再生成、前回手順の 未完、想定外の登録の移動などが考えられます。登録が動いていた 場合（識別子の変化）は、生成一式を収穫して台帳へ再登録する 手順に切り替えることを検討します ■ 第8章 作るときの流れ（主要手順） 以下は一つの実施例の流れです。主要な手順だけを簡潔に 並べてあります。途中で出会う落とし穴や細部の注意は 第9章に分けてあります。各ステップで分からないことや 選択肢があるときは、ユーザーに確認しながら進めてください。 1. 取捨選択（第5章） 質問リストかプリセットで、作るモジュールの範囲を決めます。 2. 台帳の確認 台帳フォルダとバンドル情報ファイル、適用状態ファイルが あるかを確認します。無い、または形が違う場合は、まず台帳の 整理から始めるか、ボードに必要な最小限の形から作るかを ユーザーと相談します。 3. 最小構成のボードを作る M1〜M4 の範囲で作ります。いきなり全機能を作ろうとしない方が、 途中で破綻しにくいでしょう。 4. 台帳との照合 ボードの表示が、台帳の実記録と合っているかを確かめます （保有要素の有無、適用中バンドル、同期状態、内訳の由来）。 合わない場合は、ボード側の読み取り方と台帳側の記録の どちらが正しいかを、実ファイルを見て判断します。 5. 拡張を1つずつ足す 選んだ残りのモジュールを1つずつ足して、そのたびに台帳と 照合します。新しいバンドルを台帳に登録しただけでボードに カードが現れるかも、この段階で確かめられるとよいでしょう。 6. ユーザーによる目視確認 ボードの表示が正しいかは、最終的にはユーザーの目視でしか 確認できません。見てもらう観点は第12章のチェックリストが 使えます。 7. 運用メモへの記録 決めたこと（標準形、表示の分け方、定期照合の有無など）は、 台帳の運用メモに残しておくと、後から見直すときに役立ちます。 ■ 第9章 実装上の注意 作るときに引っかかりやすい点を集めました。第8章の流れと 行き来しながら読んでください。 ・台帳が読めない場合に、古い表示を出し続けないこと。 ボードの表示は台帳のライブ読みが前提で、読めなければ 明示のエラー表示に落とすのが安全です（M1）。 ・ファイル名を固定で覚えないこと。ライブ側のファイル名は 登録のたびに変わりうるので、つねに適用状態ファイルの 対応表から読みます。対応表が古いまま別のバンドルと照合 してしまうと、実態が正しくても「ずれ」と誤検出します。 照合は、対象バンドルの特定が正しいかを先に確かめてから 行ってください。 ・由来の判定は推測しないこと。内訳（M5）で複数バンドルに 一致するファイルは「複数候補」、どこにも合わないものは 「不明」と正直に出す方が、間違った由来を断定するより 安全です。 ・プレビューの配信は1本ずつにすること（M7）。全バンドル 全状態をまとめて読み込むと、データ量が大きくなりすぎます。 ・ダンス枠の保有表示は、バンドル数が増えると伸び続けます （M8）。上限表示＋開閉の形を最初から入れておくと、 後から直す手間が省けます。 ・ボードの作業中に、実ファイルの削除や名前の変更は 行わないこと。台帳の記録を直す場合も、直す前に元の記録を 控えておくと安心です。 ・「選択」と「適用」の混同に注意すること（M4）。選択が 保存されたことは、適用されたこととは別に表示します。 利用者が誤解しそうな箇所には、その旨の注記を添えると よいでしょう。 ■ 第10章 ユーザーと相談するとよいこと（チェックポイント集） 第5章の質問リストで範囲を決めたあと、細部で相談すると よい点です。 ・ボードをどの手段で作るか（ユーザーの環境で使える画面作成の 手段は何か。台帳のファイルをボード側が読めるかどうか） ・台帳の形はこの仕様書の例の通りでよいか、それとも既にある 台帳の形に合わせるか ・プレビューの動画をどう配信するか（データ量と読み込み方法） ・ダンスの表示の詳しさ（枠チップの上限表示と開閉ボタンの 要否など） ・「現行の内訳」表の分け方（通常／ダークを列で分けるか、 要素ごとに行を分けるか、など） ・ボードの見た目で気になる点（カードの密度、モバイルでの 可読性、適用中と選択中の区別の分かりやすさなど） ・うまくいかなかった場合に、どこまで試して、どこで 元に戻すか（判断の目安を先に決めておくと安心です） ■ 第11章 安全のために（ここは丁寧に） ・始める前に、アバターの全ファイルのバックアップとハッシュ一覧が あるかをユーザーと確認してください。ボードの作成自体は表示だけ の作業ですが、台帳の整理や照合の過程で実ファイルに触れる場合は、 差し替えの指南書の安全項と同じ考え方が役立ちます。 ・ボードの作成中に、実ファイルの削除や名前の変更は行いません。 台帳の記録を直す場合も、直す前に元の記録を控えておくと安心です。 ・個人に紐づく情報（名前、登録の識別子、ハッシュ値、自分の ファイル名など）は、この仕様書のような共有文書には入れない ようにしてください。仕様書は「自分の環境の実物を確かめる ことから始める」という発見型の書き方に統一するのが安全です。 ・公式の有効化操作（set）や初期状態に戻す操作（clear）は、 衣装替えの手段には使わないことを、ボードの利用者にも分かる 形で注記しておくとよいでしょう。公式生成を使う場合は、生成一式 を「収穫」して新規バンドルとして登録する、という使い分けが 観察例としては安全でした。 ■ 第12章 受け入れチェックリスト 作り終えたら、このリストで確認してみてください。 該当しないモジュールの項目は飛ばして構いません。 - [] 台帳に新しいバンドルを登録すると、ボードにカードが現れる - [] 適用中バンドルと同期状態が、台帳の記録と一致して表示される - [] 選択を変えても、適用中は変わらない（ずれとして表示される） - [] 保有マトリクス（Light／Dark）の 〇／△／× が、台帳の ファイル実態と一致する - [] 現行の内訳で、各要素の由来が正しく出る。据え置きに なっている要素は、由来が適用中バンドル以外として出る - [] プレビューで選んだ動画が1本だけ読み込まれて再生される。 無いものは無いと表示される - [] ダンス枠について、枠の有無と中身の由来が別々に分かる - [] 着替え履歴が新しい順に表示される - [] 台帳を読めなくした状態では、ボードが明示のエラー表示に なる（古い表示を出し続けない） - [] 突合を実行すると、「正常」か「不一致の一覧」が返る。 実態が自動で書き換わることはない - [] ボードからファイル操作や公式ツールが呼ばれていない ■ 第13章 まだ分かっていないこと（無理に断定しないでください） ・milestone_level_up や waking の発火条件（いつ表示されるのか） ・本体の静止画の差し替えが、表示面でどう見えるか ・ダンスの表示面（どの場面でどのダンスが表示されるのか）と、 生成の上限（クォータ）の回復の有無と範囲 ・アプリ版や他の OS での挙動の詳細（このメモは Web 版の観察です） ・参照されていない古いファイルが、後からシステム側で整理される ことがありました。大切なファイルはユーザーの管理下に 保管しておくのが安全です ・今後の公式作成で、通常とダークの両方の一式が生成されるのか ・ボードの表示手段そのものの仕様変更（台帳の読み取り方法や 配信方法が変わる可能性） ■ 第14章 最後に このボードの土台は「台帳が正本、ボードはその反映」という シンプルな決まりです。この決まりさえ守れば、衣装が増えても、 標準形が変わっても、ボードは台帳を読み直すだけで追いつけます。 分からないことにぶつかったら、推測で進めず、ユーザーと一緒に 確かめながら進めてください。 （同じテーマの文書として、モーション動画の差し替え導入指南書と 検証レポートが別にあります。いずれも単独で読めるように なっており、この仕様書がそれらに依存することはありません）