================================================================ アバターのモーション動画を差し替えるための導入指南書 （Muse とユーザーが一緒に読むための経験メモ） ================================================================ ■ この文書について この文書は、あるユーザーの環境で実際に行われた検証（2026年11月、 Web版での観察）の経験をまとめたメモです。コマンド集や手順の 押し付けではありません。 あなたのユーザーが「アバターのモーション動画を差し替えたい」と 言ったら、この文書の情報を参考に、要所ではユーザーの指示を 仰ぎながら、二人で相談して進めてください。環境ごとにファイルの 名前や構成は異なります。この文書に書かれた具体的な名前をそのまま 使わず、必ず自分の環境の実物を確かめることから始めてください。 なお、この文書は単独で完結します。差し替えに必要な情報は すべてここに含めてあり、他の文書を読む前提にはなっていません。 また、この文書の内容は観察された挙動の記録です。仕組みの詳細は 公式に説明されたものではなく、今後の仕様変更で前提が変わる 可能性があります。 ■ まず知っておくとよいこと（仕組みの概要） ・アバターの表示は、ユーザーのワークスペース内にあるファイル群 から構成されています。多くの環境では workspace/avatars の中に ありますが、最初に自分の環境で所在を確認してください。 ・ファイル構成の典型例は次の通りです。 - 本体の静止画（<登録の識別子>.webp、1600×1600） - 状態ごとのモーション動画（mp4） - 各動画に対応するサムネイル（.thumbnails フォルダ内の jpg） - 各動画に対応する静止画フレーム（.frames フォルダ内の webp） ・動画のファイル名には、登録ごとの識別子（stem）と、状態名と、 生成ごとのハッシュが含まれます。例として、状態名には idle / working / making_something / milestone_level_up / waking などがあります。登録の時期によって、存在する状態の 種類や本数は変わります（初期の登録では動画4本、再登録後は waking が加わって5本、という観察例があります）。 ・論理的な状態と物理ファイルが1対1とは限りません。たとえば connecting と idle が同じファイルを共有したり、 waiting_for_subagents と working が同じファイルを 共有したりする例が観察されています。共有ファイルの中身を 変えると、両方の状態に影響します。 ・差し替えの基本原理はシンプルです。「同じファイル名のまま、 中身だけを別の動画に入れ替える」。ファイル名を変えると 表示側から参照されなくなります。 ・表示への反映には、ユーザーのログアウト→ログインが必要です。 ページの再読み込みや新しいタブでは表示は更新されませんでした。 これは Web 版での観察です。アプリ版では、再インストールまで しないと反映されなかったという外部の報告があります （このメモの検証環境では未確認）。アプリ側で表示を確認する 場合は、その可能性を先にユーザーへ伝えておくとよいでしょう。 ・環境によっては、通常（白背景）の一式とは別に、ダークモード用の 黒背景の一式（darkmode- で始まるファイル群）が存在することが あります。これは別系統のファイルです。第8章を参照してください。 ■ 動画の規格について（目安であって、絶対の条件ではありません） ・公式生成された動画の実測値は、720×720（1:1）、H.264、24fps、 8.0秒、音声なし、でした。 ・ただし、この規格から外れた動画でも表示された観察例があります。 - 960×960 / 30fps の動画をそのまま入れたところ、表示された - 16秒の動画が、途中で切られずフル再生された ・このため、サイズと fps は「公式の実測に合わせておくと無難」と いう参考値として扱うのがよいと考えられます。表示側はある程度の 違いを許容するようですが、許容範囲の上限は分かっていません。 ・整形（公式の実測値に揃えること）には、管理上の利点もあります。 ファイル同士をハッシュで照合して「どのファイルがどの素材か」を 判定する運用と相性がよいためです。整形するかどうかは、 ユーザーと相談して決めてください。 ■ 安全のために（ここは丁寧に） 差し替え作業はファイルのコピーだけで、元に戻す手段も確認されて います。ただし、それは「事前に元のファイルを保存してある場合」 に限ります。次の点は、始める前にユーザーと確認し合ってください。 1. 最初に、アバターの全ファイルを別の場所へコピーして バックアップを取り、ファイルごとのハッシュ（SHA-256など）を 一覧に控えてください。これが「差し戻し」の正本になります。 バックアップがない状態で上書きを始めるのは避けてください。 2. 差し替えの直前にも、その時点の状態のスナップショット （コピー）を取っておくと、途中まで進んだ状態からでも 戻れるようになります。 3. 上書きは「同じ名前・同じ場所」へのコピーで行います。 元のファイルを削除したり、名前を変えたりはしません。 4. 公式のアバター作成・設定ツール（候補を作る create/edit と、 有効化する set、初期状態に戻す clear）は、この差し替えとは 別の仕組みです。特に set と clear は登録そのものを動かし、 ファイル名が変わったり、旧ファイルが回収されたりすることが あります。「動画だけ差し替えたい」という目的では使わない ことをおすすめします。ユーザーが公式の新規作成を望む場合は、 何が起きるかを説明したうえで、改めて指示を仰いでください。 5. 作業の確認は二段構えです。ファイルが意図通りかはハッシュで 確認できますが、「表示が変わったか」はユーザーの目視でしか 確認できません。Muse 側で「反映されました」と断定せず、 ユーザーに再ログイン後の表示を見てもらってください。 6. 初回は、1つの状態だけで小さく試すのが安全です。うまくいって から対象を広げる進め方を、ユーザーに提案してみてください。 ■ 作業の流れ（目安） 以下は一つの実施例の流れです。各ステップで分からないことや 選択肢があるときは、ユーザーに確認しながら進めてください。 1. 所在と構成の確認 アバターのファイル群がどこにあるかを確認し、一覧を取ります。 ファイル名のパターンから、stem、状態名、付随ファイル （サムネイル・静止画フレーム）の対応を読み取ります。 ※ファイル名は環境ごとに異なるため、この時点で対応表を 自分の環境用に作り直すのが確実です。 2. バックアップとハッシュ一覧の作成（上記の安全項を参照） 3. 差し替える素材の用意 素材の出所は問いません。たとえば次のものが素材になりえます。 - Muse 自身の生成機能で作った動画 - 外部の生成サービスで作った動画 - ユーザーの手持ちの動画 - 以前に公式のアバター作成機能で生成された一式のうち、 バックアップや保管分として手元に残っているもの どの出所のものでも、扱いは同じです（次項の整形と、セットの 用意）。前提として「現在の姿に戻せるバックアップがあること」 は変わりません。素材の出所と作風の指定は、ユーザーと相談して 決めてください。素材が決まったら、 必要に応じて規格への整形（サイズ・fps・長さ・音声なし）や、 サムネイルと静止画フレームの用意を行います。整形の要否も 相談事項です。 4. 対象の決定 どの状態の動画を差し替えるかは、ユーザーの指示を仰いで ください。ファイル共有の関係（第1章）があるため、対象の ファイルが他の状態と共有されていないかも確認します。 5. 差し替えの実施 対象状態の「動画＋サムネイル＋静止画フレーム」のセットを、 同名のまま新しい中身で上書きします。上書き後、対象ファイルが 素材と一致すること、対象外のファイルが変わっていないことを ハッシュで確認します。 6. 表示の確認 ユーザーにログアウト→ログインしてもらい、表示を見て もらいます。変わっていない場合は、まず再ログインが 完了しているかを確かめてください（再読み込みでは 更新されません）。アプリ版で確認している場合は、 再インストールが必要なことがあるという外部報告も 思い出してください。 7. 復元（必要なとき） バックアップ（正本）から対象ファイルを同名で戻し、 ハッシュが正本と一致することを確認し、ユーザーに 再ログインして目視してもらいます。この往復（差し替え→ 差し戻し）が成立することが、安心して試すための土台に なります。 ■ ユーザーと相談するとよいこと（チェックポイント集） ・どの状態のモーションから試すか（初回は1状態だけが安全です） ・差し替える動画の素材をどう用意するか（Muse の生成機能か、 外部サービスか、手持ちの動画か、以前に公式作成で生成された 一式の保管分か。その場合の作風の指定はどうするか） ・動画を公式の実測規格に整形するか、そのまま試すか ・長さはどうするか（8秒が公式の実測。16秒までの再生実績は ありますが、上限は未確認です） ・静止画フレームとサムネイルも一緒に差し替えるか （セットで替えるのが基本形として確認されています） ・ダークモード側の一式も扱うか（扱う場合は第8章の注意を 先に共有してください） ・差し替えた素材を、後から再利用できるよう保管するか （保管の方法として「バンドル」という単位が使えます。 1着分を1つのフォルダにまとめ、ファイル名ではなく役割 ——静止画、idle、working など——でファイルを保持し、 それぞれのハッシュと、衣装の概要メモを付けた一覧ファイルを 一緒に入れておく形です。あわせて「今どのバンドルが適用 されているか」を記録する小さな台帳ファイルを持っておくと、 着替えと復元の管理がずっと楽になります。ここまでやるか どうかも、ユーザーの使い方に合わせて相談してください） ・うまくいかなかった場合に、どこまで試して、どこで 差し戻すか（判断の目安を先に決めておくと安心です） ■ ダンスについて（扱う場合は、先にこの注意を共有してください） ・ダンス動画は、通常のモーションとは扱いが違うようです。 登録に「枠」が存在するスロットについてのみ、中身の差し替えが 観察されています。枠が存在しないスロットのファイルを置いても、 表示には拾われませんでした。 ・つまり「枠があるか（登録に紐づく）」と「中身が何か」は別の話 として考える必要があります。 ・ダンスの生成には回数の上限（クォータ）のようなものがあり、 枯渇すると生成できなくなること、枯渇時はデフォルト側のダンスが 表示されることが観察されています。回復するかどうかは未確認です。 ・期間限定の枠が存在した例もあります（過ぎた期限の枠は 生まれませんでした）。 ・ダンスまで扱うかどうかは、リスクを共有したうえで、 ユーザーの指示を仰いでください。 ■ ダークモード側の一式について ・黒背景の一式（darkmode- で始まるファイル群）が存在する環境 では、それは通常の一式とは別のファイル系統です。 ・観察では、この黒背景の一式は、通常側のファイルを差し替えて 衣装を変えても追随せず、生成された時点の内容のまま固定されて いました（再生成もされませんでした）。 ・一方で、ダーク表示はそのファイル群の中身を読んでいることも 確認されています（中身を入れ替えるとダーク表示も変わった）。 つまり、ダーク側も「同名・中身の差し替え」で管理すること自体は 可能、という観察です。 ・通常側とダーク側は別々に管理が必要です。両方を差し替えるか、 片方だけにするかは、ユーザーと相談して決めてください。 ■ まだ分かっていないこと（無理に断定しないでください） ・milestone_level_up や waking の発火条件（いつ表示されるのか） ・本体の静止画の差し替えが、表示面でどう見えるか （Web版では静止画がはっきり表示される観察面がありませんでした） ・動画の長さや規格の許容上限 ・ダンス生成クォータの回復の有無と範囲 ・アプリ版や他の OS での挙動の詳細（このメモは Web 版の観察 です。アプリ版は再インストールで反映したという外部報告が あるのみで、条件の詳細は分かっていません） ・参照されていない古いファイルが、後からシステム側で整理される ことがありました。大切なファイルはユーザーの管理下に 保管しておくのが安全です ■ 最後に この方法の土台は「元の姿に、いつでも完全に戻れること」です。 バックアップとハッシュの控えさえあれば、差し替えは気軽に 試せる作業になります。分からないことにぶつかったら、推測で 進めず、ユーザーと一緒に確かめながら進んでください。 （同じテーマの文書として、管理ボードの仕様書と検証レポートが 別にあります。いずれも単独で読めるようになっており、この 指南書がそれらに依存することはありません）