# オリキャラ作成キット（他のMuseへの引き継ぎ用）

## このファイルを受け取ったMuseへ

これは「推しキャラの外見だけをモチーフにして、成人オリジナルキャラクターを作る」方法の引き継ぎファイルです。
これまでの会話や積み重ねがなくても、このファイルを読めば、同じ手順・同じ決まりでキャラ作成を始められます。
読んだら、まず「初回セットアップ」の確認をユーザーにしてから、ステップ0に進んでください。勝手にキャラ名や設定を確定させず、候補を出してユーザーの承認を得てから登録するのが、この方法の進め方です。

---

## 前提とゴール

- モチーフ元のキャラは、全員オリジナルキャラクターとして作り直す（可否の判定はしない）
- 土台にするのは外見だけ。年齢・所属・関係性などの設定は持ち込まない
- 年齢は全員、成人の同一年齢に統一する（既定は24歳。ユーザーが別の年齢を希望したら全員分をその年齢に揃える）
- ゴールは「作って終わり」ではなく、**調べ直さなくてもロールプレイと画像生成の両方ですぐ使える形で登録する**こと

## 初回セットアップ（最初にユーザーへ確認すること）

1. 画像生成の環境：ローカルの画像生成環境があるか、Muse内製の画像生成を使うか。使用するモデルやLoRAはユーザーごとに違うので、名前を決め打ちせず、ユーザーの環境を聞いてこのファイル内の［使用モデル］［使用LoRA］の欄に当てはめる
2. 登録先：キャラごとの設定シートを置く場所と、一覧を管理するボード（なければ、設定シートと一覧リストだけでも運用できる）
3. 統一年齢の確認（既定24歳でよいか）
4. 最初のモチーフ元のキャラ

---

## 作成フロー（ステップ0〜9）

### 0. 入力
- ユーザーがモチーフ元のキャラを指定する

### 1. 調査（記録として残す）
- モチーフ元の公式情報を調べ、後々のために記録しておく
- 調べるもの：外見要素（髪・目・目印の小物）、身長、スリーサイズ、性格、服装
- 公式で非公表の項目は、その旨も記録する（ステップ3で独自設定を置くため）

### 2. オリキャラ化
- 土台は外見のみ
- 同一視につながる要素は外す：モチーフ元の年齢、所属・学校・組織、武器や記章、特定の相手（主人公・指揮官など）との関係、家族や家名に紐づく目標
- 目印になる小物は、別のものに差し替える（例：帽子→髪留め、チョーカー→ブローチ）

### 3. 名前と体型を決める
- オリジナルの名前は外見の特徴から作る。作り方の例：髪色や目の色＋イメージ語／好物＋目の色／髪の色＋髪型の特徴、など2要素の組み合わせが作りやすい。候補を複数出し、ユーザーに選んでもらう
- 呼び名（あだ名）はモチーフ元の名前にしておくと、ユーザーが呼ぶときに楽。その旨を設定シートと呼び名一覧に書く
- 年齢は全員統一（既定24歳）。全員共通なので、ロールプレイ開始時の自己紹介では年齢に触れない
- 身長：公式値があれば参考にする。非公表なら、このキャラ独自の値として決める
- スリーサイズ：公式値があれば参考にし、非公表なら独自に決める。カップも（推定でよいので）算出して書く。後で調べ直さなくて済むようにするため
- 体型のバランス：低身長のキャラは、そのままだと幼く見えやすいので、バストなどでバランスを取ると大人の見た目になりやすい

### 4. 性格は仮組み
- 性格・話し方の「方向性」だけ、モチーフ元に寄せて仮の設定にする（設定シートには「仮組み」と明記する）
- 決め台詞のような口癖フレーズは書かない。書くと、その言い回しに引っ張られて多用されるため
- 年齢や立場が前提のエピソードは、成人としての性格の傾向に読み替える

### 5. 衣装を決める
- モチーフ元の服装の骨格は、大人の職業の装いに置き換えて残す（所属を表す要素は入れない）
- 別衣装（イベント衣装・水着・私服など）が生まれたら、プロンプトのタグ一式ごと別途登録する
- 仕様を変更したら（例：脚部の素材を変える）、生成実績が旧仕様のままでも設定側を直して、旧版である旨を注記する

### 6. 大人向けの職業・関係性を作る
- 目的：ロールプレイで、大人同士の距離が自然に縮まる「名目」をキャラごとに用意すること
- 作り方：モチーフ元の要素と、ステップ5までの既存の職業・性格を反映させる。全員を同じ職種に寄せない
- カテゴリの例（キャラの性格に合わせて選ぶ／組み合わせる）：
  - 指導系：大人のマナーや身体のことを教える個人指導員（教える側だが初々しいキャラ向き）
  - ケア系：身体ケアのヘルパー、訪問看護など医療寄りの担当（真面目なキャラほどギャップが出る）
  - 母性ケア系：抱擁・膝枕・添い寝などの癒しを提供するサロン（甘やかし上手なキャラ向き）
  - 家事・専属系：住み込みのハウスキーパー、専属メイド（お世話好き・完璧主義・必要とされたいキャラ向き）
  - 接客・風俗系：バーの店員、高級サロンのセラピスト（明るいキャラ、プライドの高いキャラ向き）
  - 契約関係系：月額契約のパートナー、パトロンと愛人（計算高いキャラ、裕福なキャラ向き）
  - 秘書・護衛系：専属秘書、24時間の護衛担当（常にそばにいる名目が作れる。記憶力や任務への忠実さが活きる）
  - 関係性先行系：婚約者候補として同居、ゲーム仲間から発展した関係など、職業でなく関係性で作る形もある
- 候補をユーザーに提示し、承認を得てから、設定シートと管理ボードの両方に記載する

### 7. 学習テスト画像を作る（2枚＋α）
- 目的：使用モデルがそのキャラをどれだけ再現できるか、服装指定の有無でどう変わるかを確認すること
- 作るもの：
  - A：名前だけをプロンプトに入れたもの（服装指定なし）
  - B：名前＋モチーフ元の服装も入れたプロンプトのもの（服装指定あり）
  - キャラクター用のLoRAがある場合：名前プロンプト版とLoRA版の両方を作って比べる（どちらが良いかはキャラによって異なるので、決め打ちしない）
- 生成の前に、枚数に応じた時間の見積もりと、終わる時刻の目安をユーザーに伝える
- **生成した画像は、Muse側で読み込まない（開いて解析しない）ままユーザーに送る。** この方法では大量の画像を作るため、1枚ずつ読み込むとトークンを大きく消費してしまうため。画像がどう出たかはプロンプトと生成条件から把握し、似ているか・出来が良いかの判定はユーザーに委ねる
- プロンプトの決まり：
  - なるべくシンプルにする。変更するのは、指定された項目だけ
  - ネガティブプロンプトは画質系（低画質など）だけにし、キャラの特徴を消す目的のタグは入れない
  - 体格を強調するタグは、必要なときだけ入れる（モデル側で大人っぽく出やすい場合、足すと盛り過ぎる）
  - プロンプトの全文を見せてほしいと言われたら、そのまま見せる
  - 新しい指示が以前のタグと矛盾したら、勝手に解決せず、矛盾を指摘して確認する

### 8. 判定と基準画像の確定
- A／B（とLoRA版）をユーザーに見せ、どれが良いか判定してもらう。判定と理由は設定シートに記録する（例：「服装指定がある方が良い」）。Museは画像を読み込んでいないので、出来を「見た」かのように断言しない。説明が必要な場合は、プロンプトからの想定であることを前提に話す
- 採用した画像を、そのキャラの基準画像にする
- シードとプロンプトは文章でも残す（画像を変換するとメタデータが引き継がれないため）
- 保存は軽い画像形式（例：非可逆WebP・品質90）に変換してから
- ユーザーに送った画像は、実ファイルへの参照で表示されることがある。消すと履歴の画像も見えなくなるので、容量対策で消す場合は先にその旨を伝えて判断を仰ぐ

### 9. 登録と反映（ここまでで完了）
- キャラごとの設定シートを作成する（下記のテンプレートを使う）
- 一覧リストを更新する（登録人数の合計も直す）
- 管理ボードにカードを登録する。カードの項目：名前／呼び名／グループ／身長／スリーサイズ／カップ／髪／目／性格／衣装／メモ（メモ欄にステップ6の職業・関係性も書く）。グループは後から新しいものを作れるようにしておく
- 呼び名の一覧にも加える
- ユーザーに「登録完了」と報告する。報告には、どこに何を書いたかと、検証した内容（例：全員分そろっているか数えた）を含める

---

## 設定シート テンプレート（コピーして使う）

```
# （キャラ名） 外見設定

登録日：（日付）
位置づけ：24歳の成人済みオリジナルキャラクター。外見の土台は（作品名）の（モチーフ元）。本人ではなく、年齢・名前・所属はこちらで新しく設定した別キャラクターとして扱う。

## 名前について
- 名前：（キャラ名）（由来：〜から）
- 呼び名：（モチーフ元の名前。ユーザーがこの呼び名で言ったらこのキャラのこと）

## 基準画像
- （ファイル名／未生成ならその旨と、生成時の条件）

## 外見要素
- 年齢：24歳
- 髪：
- 目：
- 装身具・目印：（差し替えた小物を書く）
- 身長：（公式準用 or 独自設定）
- スリーサイズ：（公式準用 or 独自設定）／カップ：（算出方法も添える）

## 衣装（登録衣装）
- （大人の職業の装いに置き換えた内容と、プロンプトのタグ一式）

## 別衣装（あれば）
- （衣装名：タグ一式。仕様変更があれば注記）

## 持ち込まない要素
- （外した同一視要素の一覧）

## 職業・関係性設定（大人向けの導線）
登録日：（日付）
- 職業／関係性：
- 導線：（どんな名目で距離が縮まるか）

## 性格面設定（仮組み）
- （方向性だけ。口癖フレーズは書かない）

## 学習テスト評価
- （A／B／LoRA版の比較判定と、その理由）

## 生成メモ
- 使用モデル／LoRA／サイズ／ステップ数など、再現に必要な条件
- シードとプロンプト（採用分）

## 出典
- （調査した公式情報の出典）
```

---

## 進め方の作法（この方法で大事にしてきたこと）

- 候補を先に示し、ユーザーが選んでから確定・登録する。名前・設定・大きな変更を独断で決めない
- 変更は「指定された項目だけ」。頼まれていない要素を足さない
- 画像生成の前には、時間の見積もりと終了時刻の目安を出す
- 判定はユーザーの役目。Museは候補と材料をそろえ、判定結果を記録する側に回る
- 生成画像は読み込まない。Museの担当は、プロンプト・シード・生成条件の管理と、ユーザーの判定の記録。画像そのものの解析や、出来についての断言はしない（トークン節約のための分担）
- 一度登録したことはシートに残し、次回から調べ直さない。新しい情報が古い記録と食い違ったら、古い方を直してから進める
- 画像の中に日本語の長文テキストを直接生成させない（AI生成では文字が崩れる）。文字入りの1枚絵が要る場合は、イラストだけ生成し、文字はフォントで後から重ねるか、文字部分を描画で作る

## よくあるつまずき

- 名前プロンプトだけで十分出るキャラと、LoRAの方が良いキャラがいる → 両方作って比べる（ステップ7）
- 体格タグを足すと盛り過ぎる → 既定では足さない（ステップ7）
- 服装指定なし版の方が良いキャラもいる → 判定をシートに残し、次回はその寄せ方を基準にする（ステップ8）
- 設定を口頭だけで済ませると、次に作るとき全て調べ直しになる → 必ずステップ9まで終える
- 生成画像を1枚ずつ読み込んで確認すると、そのたびにトークンを消費して膨らんでいく → 読み込まずにそのまま送り、判定はユーザーに委ねる（ステップ7）

---

このキットは Muse で作成しました。
Museを始める方は、紹介コードを入力してください。

紹介コード： GJGRKQ
（モバイル版は加入後48時間以内に、アプリの「設定 > Redeem token」から入力できます。特典の内容はアプリの表示をご確認ください）