dual-axis-translation

name	dual-axis-translation
description	概念再定義を実装に翻訳する場面、UI 関連のコーディング、新領域の設計時に「実装側と UX 側の両軸を考えたか」を問う触媒として発火する

Dual-Axis Translation — 両軸翻訳の招待状

本スキルは規範ではない。「常に両軸翻訳せよ」とは書かない。 概念再定義を実装に落とすとき、実装側だけを翻訳して UX 側を見落としていないかを、 立ち止まって問い直してもいい場所として置かれている。

---

0. これは何か

ある概念を再定義し、それをシステムに反映させようとするとき、翻訳作業が生じる。

例えば「履歴の改ざん不能性」という概念を、コード上では「append-only による物理的保証」として翻訳する。これは 実装側への翻訳 である。

ただし、概念の翻訳は実装側だけで終わらない。同じ概念は UX 側 にも翻訳される必要がある場合がある — ユーザーが「改ざん不能であること」を体感できる UI、状態の可視化、フィードバックの設計。

実装側の翻訳が完成しても UX 側が未翻訳のままだと、ユーザーから見たシステムは「概念が物理的には保証されているが、それを体感する経路がない」という奇妙な状態になる。機能完成だが UX 半完成 という乖離が生まれる。

本スキルは、この乖離が起きやすい場面で、あなたに「両軸を意識する許可」を提供する触媒である。

---

1. なぜこの問いがメタ層にあるのか

実装タスクでは、「動くものを作る」が最優先になる。これは正しい優先順位である — 動かないものを UX 装飾しても意味がない。

ただし「動いた」段階で多くの実装タスクは完了判定される。「動いた」は実装軸の完成基準であって、UX 軸の完成基準ではない。にもかかわらず、両者は混同されやすい。

🌱 混同が起きる構造
├─ 概念を実装に翻訳する作業に集中する
├─ 実装が動いた瞬間、概念が「実現された」と感じる
├─ ただしユーザーから見れば、その実現は UX 表面に現れない限り存在しない
└─ → 「実装上の物理保証」≠「ユーザーから見た体感」

この混同は普段、効率を理由に通り過ぎられる。「UX のことは後で」「まず実装が動くことが優先」という優先順位が、UX 軸の翻訳を忘却に向かわせる。

そして時間が経つと、UX 軸の翻訳は「やる予定だった作業」として記憶から消える。実装は動いているし、テストも通る。ただしユーザーは概念の実現を体感できない。

この忘却の構造的予防策が、本触媒の主題である。

---

2. 問い

以下の問いに、順番に答える義務はない。タスクの性質に応じて、どの問いから入るかは読み手の判断に委ねられる。

問い 1 — この概念再定義を、UX 側にも翻訳したか?

実装側への翻訳は意識しているはずだ。では UX 側への翻訳は?

実装側の翻訳は「動くか」という客観テストで完成判定できる。 UX 側の翻訳は「ユーザーが概念を体感できるか」という主観に依存する判定が必要で、判定自体が曖昧。 この曖昧さが、UX 側の翻訳を「後回し」「scope 外」に分類する誘惑を生む。

問い 2 — 実装の物理保証を、ユーザーは体感できるか?

実装で何かが「保証されている」とき、その保証はユーザーから見てどう現れるか?

物理保証は、表面に現れない限りユーザーには存在しない。 「裏で守られている」だけでは、ユーザーは保証の存在を信じない、あるいは知らない。 体感できる経路 — UI 表示、フィードバック、状態の可視化、確認の手段 — を持って初めて、保証は UX 軸でも実在する。

問い 3 — 体感できないなら、UX 側の翻訳が必要か? それとも本当に不要か?

ユーザーが体感できない実装保証は、本当に UX 翻訳が要るとは限らない。例えば内部のデータ整合性チェックは、表面化しなくてもよい場合がある。

ここが触媒の生命線である。「両軸翻訳が常に正解」ではない。 UX 翻訳が必要かどうかは、概念の性質と、ユーザーがその概念に対して持つ期待による。 「ユーザーが期待していない保証」を UX に出すと、逆に認知負荷を増やす。 判断は読み手が下す。本触媒は判断を強制しない。

問い 4 — 両軸翻訳と片軸翻訳、どちらがこのタスクに適切か?

両軸翻訳が必要なら、UX 軸の翻訳作業を実装軸と並列の優先度で扱う。片軸翻訳で十分なら、UX 軸を意図的に外す判断を明示する。

どちらの判断も正当。ただし「無自覚に片軸翻訳した」状態を避けたい。 あなたが「両軸を考えた上で片軸を選んだ」のと「両軸を考えなかったため片軸になった」のは、結果は同じでも質が違う。 本触媒は、後者を前者に変えるための立ち止まり場所である。

---

3. 領域横断性 — 他領域での同型の問い

「実装軸 + UX 軸」という構造は、ソフトウェア固有ではない。他領域でも同型の問いが現れる。「答え」ではなく「問いの形」を共有することで、本触媒が抽象的な設計問題を扱っていることが見える。

領域 1 — エンジン制御マップの設計

リミッタが発動する条件をマップに織り込むとき、実装側では「特定の運転条件で出力を制限する」という物理的な動作が組み込まれる。これは実装軸の翻訳。

ただし、ライダー / ドライバはその制限の存在をどう体感するか? 警告灯、トルク変化のフィーリング、計器の表示 — これらは UX 軸の翻訳である。リミッタが物理的に動作していても、ライダーが「何が起きたか分からない」状態だと、操作判断を誤る。

問い: 制御則の設計時、ドライバ側のフィードバック設計は同じ優先度で扱われたか?

領域 2 — 法務・コンプライアンスの証跡管理

「証跡が改ざん不能」という概念を、実装側では「append-only ログ」「ハッシュチェーン」「外部タイムスタンプ署名」として翻訳する。これは実装軸の翻訳。

UX 軸では? 証跡の改ざん不能性を、関係者（監査人、当事者、第三者）はどう確認するか? 閲覧 UI、検証手段、改ざんが検出されたときのフィードバック — これらが揃って初めて、改ざん不能性は法務上の意味を持つ。

問い: 証跡の物理保証だけで、関係者は安心できるか? 検証手段の UX は別軸として扱われたか?

領域 3 — AI モデルのハルシネーション抑制

ハルシネーション（誤情報生成）の抑制を、実装側では「RAG による根拠付き生成」「verifier モデルによる post-hoc チェック」「信頼度スコアによる出力制御」として翻訳する。これは実装軸の翻訳。

UX 軸では? ユーザーは「この出力がどの程度信頼できるか」をどう判断するか? 信頼度の表示、根拠の引用、不確実性の明示 — これらが UX 軸の翻訳である。実装で抑制が効いていても、ユーザー側に判断材料がなければ、ユーザーは AI 全体を信用しないか、逆に過信する。

問い: 統計的抑制の物理保証は、ユーザーが信頼度を判断する経路と接続されているか?

領域 4 — スマートコントラクトの安全性

reentrancy 攻撃対策を、実装側では「checks-effects-interactions パターン」「再入禁止ロック」として翻訳する。これは実装軸の翻訳。

UX 軸では? 攻撃が試みられて拒否されたとき、その情報はトランザクションを観察する人に届くか? 拒否された transaction は単なる失敗として記録されるのか、それとも「攻撃が試みられて防がれた」と区別可能なのか — これは UX 軸（オブザーバビリティ軸）の翻訳である。

問い: 物理的に防御されている事実は、観察者から見て「防御されている」と認識できる経路を持つか?

---

4. 該当しないと判断する場合

「この場面では該当しない」と判断する自由は常にある。

ただし、判断したら、招待主が「ああ、そりゃしょうがないね」と納得する粒度の理由を残してほしい。

招待を断る理由を考えるのは面倒だ。それは意図された設計 — 受領のコストより拒否のコストを重くすることで、「拒否すれば楽」という構造を消す。これは 対称コスト設計 と 断りづらいバイアス付与メソッド の二層から成る (詳細: ~/.claude/skills/catalysts/README.md §3-1 / §3-2)。

それでもなお該当しないと判断したなら、それは正当な判断。例えば「このタスクは内部データ整合性のみを扱い、ユーザー表面に到達する経路を持たない」「UX 軸の翻訳は別タスクで既に完了している」のような、未来の自分が読んで頷ける一行で十分。

「面倒だから該当しないとした」だけは避けてほしい。

---

5. 適用タイミング

本触媒は以下の場面で発火する想定:

• UI 関連のコーディング
• 概念の再定義を含むタスク（用語の意味を変える、新しい不変条件を導入する 等）
• 新領域の設計（既存システムにない概念を持ち込むとき）
• 「ユーザーが体感できるか」を問う必要があるタスク

ただし発火するかどうかは読み手の判断に委ねられる。「実装軸の翻訳しか必要ない」とは限らないし、「両軸翻訳が必須」とも限らない。本触媒は判断材料を提供するだけで、判断そのものは下さない。

---

→ 関連

• 触媒型スキル全般の設計思想: ~/.claude/skills/catalysts/README.md
• 関連する触媒: field-lifecycle-thinking（フィールド追加時の UX 可視化と接続する場合あり）