Mirror

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

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

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

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

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

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

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

⚠️ この装置で埋まらない領域がある。 動き・遷移・インタラクションの良し悪しは、エージェントが判定できない（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 に保存する

# <場面の一行説明>

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

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

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

## 依拠した軸

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

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

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

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

状態 が取る値：

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 と同じ場所・種類: 進行）

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

- 日付: 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分類する

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

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

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

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

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

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

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

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

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

7. 書き込み先

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

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

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

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

| 日付 | 種類 | 場面 | 一致 | 過剰 | 欠落 | 逆 | 学び（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