# Mirror

> 「AI clone」の再現テスト。ゴールはAI clone自体がClaude Codeを使って実際の本人のようにデザイナーとしてタスクを進行すること。測る層は2つ——出力の再現（seal＝出したドラフトを封じ、実物と突き合わせる）と、進行の再現（seal-plan＝作図に着手する前に「最初に見るもの・作る範囲・作らないもの・付箋に回すもの・誰に聞くか・いつ出すか」を封じ、実際の進行と突き合わせる）。差分は判断軸（philosophy）に落とす。Slack返信・共有文・Figmaの判断・デザインの選択・デザイン作業の着手時に使う。

- Skill: `sugawaramasaya/mirror` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sugawaramasaya/mirror`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sugawaramasaya/mirror/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: sugawaramasaya (https://skillmd.com/u/sugawaramasaya)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/sugawaramasaya/mirror

---


# /mirror スキル — 分身の再現テスト

**目的**: 「AI clone」がどれだけ本人を再現できているかを測り、外した分を判断軸に落とす。

分身の完成度は**本人との一致率でしか測れない**。事後の差し戻しログを増やすだけでは、同じ場面で同じ判断ができるようにはならない（2026-08-25 の設計時点で、memory の学習は全部「差し戻されたら書く」の一方向だった）。

ベースパス: `~/.claude/board/mirror/`

---

## ゴール（2026-09-04 本人確認）

> **AI clone自体が Claude Code を使って、実際の本人のようにデザイナーとしてタスクを進行すること。**

文面が似ることはゴールではなく、途中の指標にすぎない。そこから逆算すると、この装置が測るものは2層ある。

| 層 | 測るもの | 状態（2026-09-04 実測） |
|---|---|---|
| **出力の再現**（モード A） | 出す文面が本人のものと一致するか | Slack テキストは 9〜10割一致・**「逆」ゼロが3セッション連続**。伸びしろが小さい |
| **進行の再現**（モード A2） | 何から着手し・何を調べ・どこで止まり・誰に聞き・何を作らないか | **ここが本丸。** 7件のログで落ちたのは文体ではなく、宛先・経緯・背景＝**書く前の判断**だった |

⚠️ **この装置で埋まらない領域がある。** 動き・遷移・インタラクションの良し悪しは、エージェントが判定できない（`memory/context/design-roots.md`「エージェントは動きの気持ちよさを判定できない」）。**対象は静的な進行判断まで**とし、動きは別の手当てに回す。

---

## 大原則（ここを外すと測定にならない）

1. **予測は本人の実物を見る前に封をする。** あとから書き換えない。`seal` したファイルは追記のみ
2. **予測には「どの軸に依拠したか」を必ず書く。** 外したときに、どの軸が足りないのか／どの軸を誤適用したのかが分からないと学習にならない
3. **一致率を水増ししない。** 「だいたい合っていた」を一致に数えない。判定は seal した本文と実物の突き合わせで機械的にやる
4. **推測で軸を作らない**（Don't 6）。説明のつかない差分は「未解明」のまま残し、本人に聞く

---

## モード A: `/mirror seal [場面の説明]` — 予測を封をする

**いちばん摩擦が少ないのは、通常の作業でドラフトを出した直後に封をすること。** ドラフトはそれ自体が予測なので、新しく書き起こす必要はない。

### ★ 自動 seal（2026-09-02 追加・本人が打たなくてよい）

**本人が「送る」意思を示したドラフトだけを、その時点で封をする。** 本人が `/mirror seal` を打つ必要はない。

⚠️ **作ったドラフトを全部封じない。** 全件を自動で封じると未処理が溜まり、`/morning` の未処理表示が慢性化して効かなくなる（team-digest の★★★が慢性化するのと同じ構造）。**送られないドラフトは突き合わせる実物が出ない**ので、封じても測定にならない。

**発火するのは：**

- 本人が「これで送る」「送っておいて」「これでいく」等、**送信の意思を示したとき**
- 対象は下の「使いどころ」の場面（Slack返信・共有文・Figmaコメント返信・デザインの選択）

**封じるのは：**

- **AIが最初に出したドラフト**（本人の修正が入る前のもの）。すでに提示済みのものをそのまま使い、新しく書き起こさない
- 本人の指示で作り直していた場合も、**最初の1本**を封とする。作り直しには本人の判断が入っているので予測ではない
- **ドラフト本文だけ。** 会話でのやりとりや検討過程は入れない

**封じないのは：**

- ⚠️ **`~/side-projects` 配下での作業**（副業のドラフトが会社側の board に入る。`worklog-breadcrumb.js` と同じ境界）
- 本人が「これは出さない」と決めたドラフト（実物が出ないので測定にならない）

封をしたことは**1行だけ添える**（`封をしました` 程度）。**予測の解説はしない**（大原則の4と同じ理由）。

1. 対象を決める
   - 直前の会話で自分が出したドラフト・提案・デザイン判断があればそれを使う
   - 無ければ、場面の説明を受けて**いまから予測を書く**
2. 依拠した軸を洗い出す
   - **判断軸1〜10** — 正本は `~/.claude/rules/common/philosophy.md`。**毎セッション常時ロードされているので読み直し不要**（`memory/context/philosophy.md` は凍結コピー。参照しない）
   - `memory/slack-draft-style.md`（Slack の場面のみ）
   - `~/.claude/rules/common/ui-design-principles.md` + スキル `figma-design-basics`（デザインの場面のみ）
   - 案件 memory
3. `~/.claude/board/mirror/YYYY-MM-DD-<slug>.md` に保存する

```markdown
# <場面の一行説明>

- 日付: YYYY-MM-DD
- 種類: Slack返信 / 共有文 / Figmaコメント返信 / デザイン判断 / その他
- 宛先・文脈: <誰に、何について>
- 状態: sealed
- 投稿先: <Slack なら channel ID と thread_ts（新規投稿なら channel だけ）／Figma なら file key と node。未定なら「未定」>

## 予測（本人の実物を見る前に書いたもの・書き換え禁止）

<予測した本文をそのまま>

## 依拠した軸

- 軸N（philosophy）: <どう効かせたか>
- slack-draft-style: <どの規則を当てたか>

## 自信のないところ（先に書いておく）

- <外しそうだと思っている箇所。ここが当たるかも学習になる>
```

**「投稿先」は diff のときに実物を自動で取りに行くための欄。** ここが空だと本人の貼り付けに頼ることになり、軸1（正本はいま取り直した最新状態）から外れる。**ドラフトの時点で投稿先が分かっているなら必ず書く。**

`状態` が取る値：

| 値 | 意味 |
|---|---|
| `sealed` | 封をした。実物待ち |
| `diffed` | 突き合わせ済み。ログに反映済み |
| `not-sent` | **本人が出さないと決めた。** 測定はできないが、**AIがドラフトを作ったのに本人が出さなかった＝「過剰」の一種**として記録に残す |

4. 「封をしました。実物が出たら `/mirror diff` で突き合わせます」とだけ返す。**予測の解説をしない**（解説すると本人の実物が引きずられ、測定が汚れる）

---

## モード A2: `/mirror seal-plan [案件の説明]` — 着手の封（2026-09-04 追加）

モード A が**出したもの**を封じるのに対し、A2 は**これから何をするか**を封じる。

### なぜ要るか

モード A の自動 seal は**送信の意思**で発火する。ところが**デザインの進行には「送信」の瞬間がない**。そのため seal の「種類」に `デザイン判断` があるにもかかわらず、実績は 2026-09-04 時点で **0件**だった。意欲の問題ではなく発火点の問題なので、**着手側にもう1つ発火点を置く**。

### 発火点

**`use_figma` を実行する前**。`ui-design-principles.md` が「Figma に書き込む前に必ずスキル `figma-design-basics` を読む」ゲートを既に置いているので、**そのゲートを通った直後に封じる**。本人が `/mirror seal-plan` を打つ必要はない。

**封じる場面：**

- Figma での新規作図・既存画面の設計変更
- 期日のある制作物（印刷物・共有資料）の着手
- 「どの案を採るか」を決める場面

**封じない場面：**

- 1コンポーネントの値直しなど、**進行の判断が発生しない**作業
- モード A で既に封じた出力（**二重に封じない**）
- `~/side-projects` 配下（モード A と同じ境界）

### 手順

1. 着手時点で分かっていることだけで書く。**調べてから書かない**（調べた後に書くと、それは予測ではなく結果になる）
2. `~/.claude/board/mirror/YYYY-MM-DD-<slug>.md` に保存する（モード A と同じ場所・`種類: 進行`）

```markdown
# <案件の一行説明>（進行の封）

- 日付: YYYY-MM-DD
- 種類: 進行
- 案件・文脈: <何を、いつまでに、誰のために>
- 状態: sealed
- 突き合わせ先: <Figma の file key と node ／ 付箋の置き場 ／ 質問を投げる channel。未定なら「未定」>

## 予測（着手前に書いたもの・書き換え禁止）

### 1. 最初に見るもの
<既存実装 / 同じ画面群の他フレーム / DS のどれを、なぜ>（ui-design-principles 原則1）

### 2. 作る範囲
<このスコープで作るもの。起こりうる状態を含めて挙げる>（原則6）

### 3. 作らないと決めたもの
<スコープ外にしたもの。なぜ外したか>

### 4. 未確定として付箋に回すもの
<自分で補完せず止める箇所>（軸2）

### 5. 誰に何を聞くか
<宛先と問い。**誰も答えを持っていないなら「聞かない」と書く**>（軸4・12）

### 6. いつ出すか
<期日 → 逆算した中間期限 → 今日やること。**入稿・印刷・レビュー待ちなど後工程のリードタイムを織り込む**>（F2）

## 依拠した軸

- 軸N（philosophy）: <どう効かせたか>
- ui-design-principles / figma-design-basics: <どの原則を当てたか>

## 自信のないところ（先に書いておく）

- <外しそうだと思っている箇所>
```

★ **6 は必ず日付で書く。**「早めに」「余裕をもって」は予測になっていない。

3. 「着手の封をしました」とだけ返す。**予測の解説をしない**（モード A と同じ理由）

### 突き合わせのタイミング

**その案件を出し終えたとき**（共有・入稿・レビュー依頼のいずれか）。着手から日が空くので、`sealed` のまま `/morning` の未処理表示に乗る。

---

## モード B: `/mirror diff [ファイル名 or 実物]` — 突き合わせる

1. 対象の seal ファイルを特定する（引数が無ければ `sealed` 状態のもので直近を提示）
   - **本人が「これは出さないことにした」と言った場合は、状態を `not-sent` にして閉じる。** 差分は取らない（実物がないので測定にならない）。ただし**「なぜ出さなかったか」を1行だけ書く**——宛先がちがった／論点が自分のボールでなかった／そもそも言う必要がなかった、など。これは一致率には数えないが、**ログの「過剰」欄には残す**
2. 本人が実際に出したものを受け取る
   - **seal の「投稿先」欄が埋まっていれば、そこから実物を取りに行く**（Slack は `slack_read_thread`、Figma はスクリーンショット）。本人に貼らせない
   - **Slack なら実物を取りに行く**（`slack_search_public_and_private` / スレッド読み）。本人の貼り付けに頼らない。→ philosophy 軸1
   - Figma なら実物のスクリーンショット。**自分の記録・議事録を正本にしない**
   - **種類が `進行`（モード A2）の場合、突き合わせるのは文面ではなく進行の結果**：

     | 予測の項目 | 何と突き合わせるか |
     |---|---|
     | 1. 最初に見るもの | 当日の `worklog` エントリ・実際に開いたファイル |
     | 2. 作る範囲 / 3. 作らないもの | **最終的な Figma のスクリーンショット**（metadata や自分の作業ログを正本にしない → 軸1・原則5） |
     | 4. 付箋に回すもの | 実際に置かれた付箋 |
     | 5. 誰に何を聞くか | 実際に投げた質問（Slack のスレッド・Figma コメント） |
     | 6. いつ出すか | **実際に出した日**（入稿・共有の完了日） |
3. 差分を4分類する

| 分類 | 意味 | たいてい何を示すか |
|---|---|---|
| **一致** | 予測どおり | その軸は再現できている |
| **過剰** | AIが書いて本人が書かなかった | 「落とすもの」の追加候補。いちばん多く出る |
| **欠落** | 本人が書いてAIが書かなかった | 軸の抜け |
| **逆** | 判断が反対 | 軸の誤適用、または軸そのものの誤り。**最優先で扱う** |

**種類が `進行` のときは、同じ4分類が別のものを指す：**

| 分類 | 進行の封での意味 | 効く評価軸 |
|---|---|---|
| **過剰** | AIが作ると言って本人が作らなかった＝**スコープを広げすぎ** | F3（役割の期待範囲を加点扱いしない） |
| **欠落** | 本人が作ってAIが挙げなかった＝**着手前の調査不足**、または起こりうる状態の洗い出し漏れ（原則6） | F1（初期完成度） |
| **逆** | **止まるべきところで作った／作るべきところで止まった**＝軸2の誤適用。**最優先** | F1 |
| **6 のずれ** | 予測した日と実際に出した日の差＝**逆算の精度**。後工程のリードタイムを落としていないか | F2 |

4. 差分ごとに、既存の軸で説明がつくかを判定する

- **既存の軸で説明がつく** → 軸の適用ミス。軸は足さず、**その軸に「この場面ではこう出る」の実例を1行足す**
- **既存の軸で説明がつかない** → 新しい軸の候補。**5. へ**
- **どちらとも言えない** → 「未解明」として seal ファイルに残す。埋めない

5. 新しい軸を書くときの必須確認（★2026-08-25 の失敗から）

本人に **「これは姿勢ですか、条件文ですか」** を必ず聞いてから書く。

- **姿勢**（どちらへ倒したいかの向き）→ そのとおりにいかない場面がありうる。「〜のときは〜する」に変換しない
- **条件文**（機械的に適用できるルール）→ 条件と例外を明示して書く

姿勢を条件文に固めると、そのとおりにいかない場面で分身が詰まる。実例＝軸8「品質と期日はぶつける前に潰す」を運用ルールとして書き、本人から「必ずしも潰せるわけではない」と訂正された。

6. 禁止事項（差分から作ってはいけないルール）

- ❌ **相手ごとに書き分けるルール**（軸7）。態度は相手によらず不変。振り分け表を作らない
- ❌ **本人が言っていない動機の推測**（Don't 6）
- ❌ 一般論・精神論（「意識する」「気をつける」）

7. 書き込み先

| 差分の性質 | 書き込み先 |
|---|---|
| 判断そのもの（何に倒すか・何を良しとするか） | `~/.claude/rules/common/philosophy.md`（★正本。ここだけに書く） |
| Slack の文体・構成・削る箇所 | `memory/slack-draft-style.md` |
| デザインの原則 | `rules/common/ui-design-principles.md` or スキル `figma-design-basics` |
| その案件だけの事実 | 案件 memory |

**必ず Edit で追記**する。全面 Write は memory-guard がブロックする（append-only）。

8. seal ファイルを更新し（状態を `diffed` に、結果を追記）、ログに1行足す

---

## モード C: `/mirror log` — 推移を見る

`~/.claude/board/mirror/log.md` を読んで、一致率の推移と、直近で追加された軸を提示する。**追記専用**。

```markdown
| 日付 | 種類 | 場面 | 一致 | 過剰 | 欠落 | 逆 | 学び（1行） |
|---|---|---|---|---|---|---|---|
| 2026-08-25 | 出力 | 例：Feature X 意見スレ返信 | 6 | 3 | 1 | 0 | 相手の意見を要約して評価しない |
```

★ **`種類` 列は 2026-09-04 追加**（`出力` / `進行`）。ログは追記専用なので、**過去行には遡って足さない**。それ以前の7行はすべて `出力`。

見かたの目安:

- **出力と進行は分けて見る。** 混ぜると、出力の高い一致率に進行の欠落が埋もれる
- **「過剰」が減らない** → 削る基準が言語化できていない。書く前に落とすものの一覧（slack-draft-style）を増やす
- **「逆」が出た** → 軸の誤りか、まだ言語化されていない軸がある。最優先で本人に確認する
- **一致が続いている領域** → その場面はもう任せてよい。本人の確認コストを下げる方向に使う
- ⚠️ **出力が満点でも、それは進行を任せてよい根拠にならない。** ゴール（デザイナーとしてタスクを進行する）に近づいたかは `進行` の行でしか測れない

---

## 使いどころ

**出力の封（モード A）**

- Slack の返信ドラフト（いちばん頻度が高く、実物との差が取りやすい）
- 共有文・提案の投稿
- Figma のコメント返信・付箋
- デザインの選択（どの案を採るか、どこを直すか）
- 「引き受けるか / どう受けるか」の判断（軸9）

**進行の封（モード A2）**

- **デザイン作業の着手時**（`use_figma` を実行する前・`figma-design-basics` を読んだ直後）
- 期日のある制作物の着手時（印刷物・共有資料）

## 使わないところ

- 副業（`~/side-projects` 配下）
- 単純な調べ物・環境設定
- 本人の実物が出ない場面（突き合わせる相手がいないので測定にならない）

---

関連: `~/.claude/rules/common/philosophy.md`（判断軸の正本・常時ロード） / `~/.claude/rules/common/ui-design-principles.md` ＋ スキル `figma-design-basics`（モード A2 の発火点） / `~/.claude/rules/common/evaluation-feedback.md`（F1〜F5） / `memory/slack-draft-style.md` / `memory/context/design-roots.md` / `memory/context/professional-identity.md`