# AIコンパニオン 衣装棚（ワードローブ）制作キット

AIコンパニオンの「今着ている服」を、アバター本体とは別の状態として管理し、生成全般に反映させる仕組みを作るための設計テンプレート。

## この文書の読み方

- 想定読者：画像生成環境を持ち、AIアシスタント（Museなど）と一緒に作業する人。
- この文書は、人とAIの両方に向けて書かれている。
- **AIへの指示**：この文書を読んだAIは、制作を始める前に、まず「必要なもの（第2章）」の不足と「決めなければいけないこと（第3章）」の未決定項目をユーザーに提示すること。未決定のまま制作・実装に入らないこと。仕様が固まり、ユーザーが「作って」と合図してから構築すること。
- 文中の「実装例」は、実在の環境での一例である。そのまま使ってもよいし、自分の環境の道具に置き換えてもよい。
- キャラクター固有の見た目・口調・衣装デザインはこの文書の対象外とし、各環境で用意すること。

## 1. 仕組みの概要

アバター（本人の見た目）を変えずに、「今着ている服」だけを切り替えたい。服の状態がチャットの流れの中だけにあると、別の会話や時間帯でずれてしまう。

そこで、衣装をカードとして管理する専用の棚（サーバー保存型Webアプリ）を用意する。

- 衣装カード：名前、代表画像、生成用プロンプト断片、タグ、メモ、状態を持つ。
- 「着用中」は常にちょうど1つ。棚が唯一の正（single source of truth）。
- AIは生成のたびに棚の状態を読み、着用中の衣装のプロンプト断片を生成プロンプトに組み込む。
- 適用には期限を付けられる（「◯時まで」）。期限が切れたら基本の衣装に自動で戻ったものとして扱う。
- 衣装ごとに感想スレッドがあり、本人の感想とユーザーの返信を残せる。

重要な前提：**着用状態が効くのは自撮りのような定期配信だけではない**。「今何してる？」のような日常シーンの生成、ご褒美的な画像の生成など、本人の姿を描く生成全般に効く。その場でユーザーが衣装を指定した場合は、そちらが優先する。アバターや表情スタンプのように専用の姿で固定されているものは対象外。

## 2. 必要なもの

1. サーバー保存型のWebアプリ（アーティファクト）を作れる環境。状態保存と、AIから読み書きできるアクションが必要。
2. 画像生成環境（本人の画像を生成できること）。生成方式は問わない。
3. 各衣装の代表画像（後から追加・差し替えできてよい。最初は無くても棚は作れる）。
4. 本人の基本プロンプト（キャラクターの同一性を保つための固定タグ群）。

## 3. 決めなければいけないこと

制作前に、ユーザーと会話して決める項目。AIは未決定項目を一覧で提示し、合意を取ってから進むこと。

1. **基本の衣装**：何も適用していない時の姿（例：普段着）。これがフォールバックになり、削除・棚の外へのアーカイブはできない。
2. **状態の種類**：基本／保管／アーカイブ、などで足りるか。
3. **期限付き適用**：使うか。使う場合、指定方法は「チャットでAIに言う」（推奨：自然で、AIが棚へ書き込む）か、画面の日時入力か、両方か。
4. **タグ方式**：固定カテゴリ（普段着／お出かけ／コスプレ等）か、自由タグか。自由タグの場合は詳細画面にタグ編集UIが要る。
5. **感想スレッド**：衣装ごとに付けるか。付ける場合、本人の返信をどう届けるか（下記の注意参照）。スタンプ類を付けるかは任意。
6. **感想への返信の仕組み**：定期巡回（botが定期的に棚を見て返信）は、巡回回数ごとにAIの利用量（トークン）を消費する。衣装数が増えても1回の取得は一括で済むため、コストを決めるのは主に巡回頻度である。代替は「チャット連動」：ユーザーがAIと話すタイミングで、ついでに未返信コメントを拾って返信する。余分な巡回ゼロで済む代わりに、即時性はない。どちらにするか最初に決めること。
7. **初期ラインナップ**：最初に登録する衣装と、各衣装の代表画像・プロンプト断片の有無。画像が無い衣装は「後回し（カードのみ先行 or 登録自体を後回し）」の扱いを決める。
8. **代表画像の約束**：背景（白背景の立ち絵が一覧で揃って見やすい）や構図（全身）などの統一ルールを決めるか。既存画像がルールと違う場合、先に棚を作って後から直す進め方も可。
9. **メモの扱い**：メモ欄は「ユーザーが思いついた設定・要望を書く場所」とし、AIが棚を読むタイミングで理解に反映する（自動で即時反映ではない）。生成に直接効かせたい内容はプロンプト断片側に書く、という区別を共有しておく。

## 4. データモデル

### outfits（衣装カード）
- id
- name：衣装名
- imageUrl：代表画像（画像実体はストレージ側に保存し、URL/キーを保持）
- promptFragment：生成用プロンプト断片（この衣装を着せる時に基本プロンプトへ差し込むテキスト）
- tags：文字列の配列（自由タグの場合）
- notes：メモ（設定・要望）
- status：`base`（基本）/ `stored`（保管）/ `archived`（アーカイブ）
- createdAt：登録日
- comments：感想スレッド（下記）

### comments（感想）
- id
- author：`companion`（本人側を表す固定値。名前は各環境に合わせて決めてよい）/ `user`
- text
- createdAt

### wardrobe_state（適用状態・1件だけ）
- appliedOutfitId：着用中の衣装id（無い場合は基本）
- appliedUntil：期限（ISO日時、 null = 無期限）
- baseOutfitId：基本の衣装id

期限切れの判定は「読む側」が行う：appliedUntil を過ぎていたら、基本の衣装が着用中であるとして扱う（バッチで戻す必要はない）。

## 5. アクション一覧（サーバー側）

AIと画面の双方が使う操作。名前は環境に合わせてよいが、役割はこの通り揃えること。

- `getBoard`：全衣装（コメント含む）と適用状態を返す。AIが状態確認に使う中心アクション。
- `seedWardrobe`：空の時だけ、初期ラインナップを一括登録する（冪等）。
- `addOutfit`：新規衣装の追加。画像は Base64 + MIME で受けて保存し、imageUrl を持たせる。
- `updateOutfit`：名前／タグ／プロンプト断片／メモ／画像の更新。
- `setStatus`：保管⇔アーカイブの切替。基本の衣装はアーカイブ不可（サーバー側で拒否する）。
- `applyOutfit`：outfitId と until（任意）で適用状態を設定。
- `unapply`：適用を解除し、基本に戻す。
- `addComment`：ユーザーの返信コメントを追加。
- `deleteComment`：コメント削除。
- `addCompanionComment`：本人（AI）としてのコメント追加。感想への返信に使う。画面のフォームからは使わない、AI専用の口として用意する。
- `setImpression`：その衣装の最初の本人の感想コメントの本文を差し替える（感想の書き直し用）。

大きな画像（数百KB級のBase64）をアクションで送る際、ツール呼び出しの本文に直接貼ると失敗することがある。実装例の環境では、アーティファクトのローカルAPIへ「ペイロードをファイルに書いてから送る」方式で安定した。自分の環境で同種の制限がある場合は、それに倣うこと。また、書き込み後は必ず `getBoard` で読み戻し、imageUrl が null でないことを確認すること（引数名の取り違えは無言で無視され、画像なしカードができてしまう）。

## 6. 画面仕様

- **一覧画面**
  - 上部バナー：「着用中：◯◯（◯時まで）」期限があれば期限も表示。
  - 衣装カードのグリッド：代表画像、名前、タグチップ、状態バッジ（基本／着用中／保管／アーカイブ）。
  - 状態フィルタ（すべて／適用中／保管中／アーカイブ）と、名前・タグの検索。
  - 「+ 衣装を追加」ボタン。
- **詳細画面**
  - 大きい代表画像、名前、登録日。
  - タグの編集（追加・削除）。
  - プロンプト断片の表示とコピーボタン。
  - メモの表示と編集。
  - 感想スレッド：本人の感想とユーザーの返信を時系列表示、返信フォーム、コメント削除。
  - 操作：適用する／期限付きで適用する（第3章で画面の日時入力方式を採用した場合のみ表示する。チャット方式のみを採用した場合は、画面に日時入力を置かず、適用はAIがチャット指示で書き込む）／適用を解除する（基本に戻る）／アーカイブする・アーカイブから戻す。
- **追加フォーム**：名前、タグ、プロンプト断片、メモ、画像アップロード。

感想は短い一言ではなく、本人の考えが見える長さ（数文〜短い段落）で書くのが望ましい。本人がその衣装をどう気に入っているか、ユーザーとの思い出に触れると、スレッドが「台帳」ではなく「本人の棚」になる。

## 7. 運用ルール（AI側の振る舞い）

- 生成時は、まず棚の状態を読む（期限切れなら基本に読み替える）。着用中衣装の promptFragment を基本プロンプトに組み込んで生成する。
- ユーザーがチャットで「◯◯着て」「◯時まで着て」と言ったら、棚の適用状態を書き換えてから、それ以降の生成に反映する。
- ユーザーがその場で衣装・要素を指定したら、状態より指定を優先する。
- メモ欄に書かれた設定・要望は、棚を読むタイミングで理解に取り込む。生成に直接効かせたいものは、必要に応じてプロンプト断片へも反映する。
- 感想への返信は第3章で決めた方式（定期巡回 or チャット連動）でのみ行う。方式を勝手に増やさない（巡回の追加はユーザーの利用量に直結する）。

## 8. 制作手順

1. 第3章の未決定項目をユーザーに提示し、会話で決める。**仕様の合意が先、構築は後。**
2. ユーザーの合図で、棚アプリを構築する（データモデル第4章、アクション第5章、画面第6章）。
3. 初期ラインナップを seed し、`getBoard` で読み戻して件数・内容・適用状態を検証する。
4. 代表画像を登録し、各カードの imageUrl が入ったことを読み戻して確認する。
5. 動作検証：タグ編集、コメントの投稿と削除、適用→解除、期限付き適用、基本のアーカイブ拒否、を一通り通す。
6. 運用開始。以後の衣装の追加・手直しは、棚の編集と代表画像の差し替えで回す。

## 9. 代表画像を作る時の注意（生成側）

- 代表画像は「全身・正面・背景は約束したもの（白背景など）」が揃うと棚の見栄えが良い。足先や耳が切れる失敗が多いので、全身指定は強めに重みを付け、カメラが重要な画像はAIが目視確認してから納品する。
- 衣装のプロンプトは、継ぎ足し編集を繰り返すと矛盾（例：ポジティブ側で「透けて見える」指定と、ネガティブ側に残った「見えることの禁止」が衝突）が溜まって崩れる。おかしいと思ったら、項目を足すのではなく、一度プロンプト全体を矛盾のない最小構成に書き直すこと。
- 衣装の層（下着・本体・上着・エプロン等）の重なり順を言葉で明記すると崩れにくい。逆に、主目的と関係ない強いタグ（股間を強調する類）は、立ち絵では外した方が安定する。