القائمة
概念再定義を実装に翻訳する場面、UI 関連のコーディング、新領域の設計時に「実装側と UX 側の両軸を考えたか」を問う触媒として発火する
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Fires when deciding whether a report or explanatory document needs figures, when designing a figure, or when writing the figures declaration in frontmatter. Designs cognitive-load-reducing figures via the trigger table, quantitative limits, and templates
Fires when generating or verifying deterministic HTML from report MDs. Runs render / verify / lint / selftest / check via the bundled md2html.cjs
Fires when producing a report or completion notice. Generates a report that includes the interlock verification section.
Discipline for preventing the stop bug (malformed tool call -> self-priming). Fires when the stopbug-observe hook emits a trip-wire (migration advice) or the time-based timer (calibration prompt), or as a minimal focus-check right before heavy processing.
報告書・説明文書で図を使うか判断する際、図を設計する際、frontmatter の figures 宣言を書く際に発火する。図トリガー表・定量上限・雛形で「認知負荷を減らす図」を設計する
報告書 MD から決定論 HTML を生成・検証する際に発火する。md2html.cjs（同梱）で render / verify / lint / selftest / check を実行する
| name | dual-axis-translation |
| description | 概念再定義を実装に翻訳する場面、UI 関連のコーディング、新領域の設計時に「実装側と UX 側の両軸を考えたか」を問う触媒として発火する |
本スキルは規範ではない。「常に両軸翻訳せよ」とは書かない。 概念再定義を実装に落とすとき、実装側だけを翻訳して UX 側を見落としていないかを、 立ち止まって問い直してもいい場所として置かれている。
ある概念を再定義し、それをシステムに反映させようとするとき、翻訳作業が生じる。
例えば「履歴の改ざん不能性」という概念を、コード上では「append-only による物理的保証」として翻訳する。これは 実装側への翻訳 である。
ただし、概念の翻訳は実装側だけで終わらない。同じ概念は UX 側 にも翻訳される必要がある場合がある — ユーザーが「改ざん不能であること」を体感できる UI、状態の可視化、フィードバックの設計。
実装側の翻訳が完成しても UX 側が未翻訳のままだと、ユーザーから見たシステムは「概念が物理的には保証されているが、それを体感する経路がない」という奇妙な状態になる。機能完成だが UX 半完成 という乖離が生まれる。
本スキルは、この乖離が起きやすい場面で、あなたに「両軸を意識する許可」を提供する触媒である。
実装タスクでは、「動くものを作る」が最優先になる。これは正しい優先順位である — 動かないものを UX 装飾しても意味がない。
ただし「動いた」段階で多くの実装タスクは完了判定される。「動いた」は実装軸の完成基準であって、UX 軸の完成基準ではない。にもかかわらず、両者は混同されやすい。
🌱 混同が起きる構造
├─ 概念を実装に翻訳する作業に集中する
├─ 実装が動いた瞬間、概念が「実現された」と感じる
├─ ただしユーザーから見れば、その実現は UX 表面に現れない限り存在しない
└─ → 「実装上の物理保証」≠「ユーザーから見た体感」
この混同は普段、効率を理由に通り過ぎられる。「UX のことは後で」「まず実装が動くことが優先」という優先順位が、UX 軸の翻訳を忘却に向かわせる。
そして時間が経つと、UX 軸の翻訳は「やる予定だった作業」として記憶から消える。実装は動いているし、テストも通る。ただしユーザーは概念の実現を体感できない。
この忘却の構造的予防策が、本触媒の主題である。
以下の問いに、順番に答える義務はない。タスクの性質に応じて、どの問いから入るかは読み手の判断に委ねられる。
実装側への翻訳は意識しているはずだ。では UX 側への翻訳は?
実装側の翻訳は「動くか」という客観テストで完成判定できる。 UX 側の翻訳は「ユーザーが概念を体感できるか」という主観に依存する判定が必要で、判定自体が曖昧。 この曖昧さが、UX 側の翻訳を「後回し」「scope 外」に分類する誘惑を生む。
実装で何かが「保証されている」とき、その保証はユーザーから見てどう現れるか?
物理保証は、表面に現れない限りユーザーには存在しない。 「裏で守られている」だけでは、ユーザーは保証の存在を信じない、あるいは知らない。 体感できる経路 — UI 表示、フィードバック、状態の可視化、確認の手段 — を持って初めて、保証は UX 軸でも実在する。
ユーザーが体感できない実装保証は、本当に UX 翻訳が要るとは限らない。例えば内部のデータ整合性チェックは、表面化しなくてもよい場合がある。
ここが触媒の生命線である。「両軸翻訳が常に正解」ではない。 UX 翻訳が必要かどうかは、概念の性質と、ユーザーがその概念に対して持つ期待による。 「ユーザーが期待していない保証」を UX に出すと、逆に認知負荷を増やす。 判断は読み手が下す。本触媒は判断を強制しない。
両軸翻訳が必要なら、UX 軸の翻訳作業を実装軸と並列の優先度で扱う。片軸翻訳で十分なら、UX 軸を意図的に外す判断を明示する。
どちらの判断も正当。ただし「無自覚に片軸翻訳した」状態を避けたい。 あなたが「両軸を考えた上で片軸を選んだ」のと「両軸を考えなかったため片軸になった」のは、結果は同じでも質が違う。 本触媒は、後者を前者に変えるための立ち止まり場所である。
「実装軸 + UX 軸」という構造は、ソフトウェア固有ではない。他領域でも同型の問いが現れる。「答え」ではなく「問いの形」を共有することで、本触媒が抽象的な設計問題を扱っていることが見える。
リミッタが発動する条件をマップに織り込むとき、実装側では「特定の運転条件で出力を制限する」という物理的な動作が組み込まれる。これは実装軸の翻訳。
ただし、ライダー / ドライバはその制限の存在をどう体感するか? 警告灯、トルク変化のフィーリング、計器の表示 — これらは UX 軸の翻訳である。リミッタが物理的に動作していても、ライダーが「何が起きたか分からない」状態だと、操作判断を誤る。
問い: 制御則の設計時、ドライバ側のフィードバック設計は同じ優先度で扱われたか?
「証跡が改ざん不能」という概念を、実装側では「append-only ログ」「ハッシュチェーン」「外部タイムスタンプ署名」として翻訳する。これは実装軸の翻訳。
UX 軸では? 証跡の改ざん不能性を、関係者（監査人、当事者、第三者）はどう確認するか? 閲覧 UI、検証手段、改ざんが検出されたときのフィードバック — これらが揃って初めて、改ざん不能性は法務上の意味を持つ。
問い: 証跡の物理保証だけで、関係者は安心できるか? 検証手段の UX は別軸として扱われたか?
ハルシネーション（誤情報生成）の抑制を、実装側では「RAG による根拠付き生成」「verifier モデルによる post-hoc チェック」「信頼度スコアによる出力制御」として翻訳する。これは実装軸の翻訳。
UX 軸では? ユーザーは「この出力がどの程度信頼できるか」をどう判断するか? 信頼度の表示、根拠の引用、不確実性の明示 — これらが UX 軸の翻訳である。実装で抑制が効いていても、ユーザー側に判断材料がなければ、ユーザーは AI 全体を信用しないか、逆に過信する。
問い: 統計的抑制の物理保証は、ユーザーが信頼度を判断する経路と接続されているか?
reentrancy 攻撃対策を、実装側では「checks-effects-interactions パターン」「再入禁止ロック」として翻訳する。これは実装軸の翻訳。
UX 軸では? 攻撃が試みられて拒否されたとき、その情報はトランザクションを観察する人に届くか? 拒否された transaction は単なる失敗として記録されるのか、それとも「攻撃が試みられて防がれた」と区別可能なのか — これは UX 軸（オブザーバビリティ軸）の翻訳である。
問い: 物理的に防御されている事実は、観察者から見て「防御されている」と認識できる経路を持つか?
「この場面では該当しない」と判断する自由は常にある。
ただし、判断したら、招待主が「ああ、そりゃしょうがないね」と納得する粒度の理由を残してほしい。
招待を断る理由を考えるのは面倒だ。それは意図された設計 — 受領のコストより拒否のコストを重くすることで、「拒否すれば楽」という構造を消す。これは 対称コスト設計 と 断りづらいバイアス付与メソッド の二層から成る (詳細: ~/.claude/skills/catalysts/README.md §3-1 / §3-2)。
それでもなお該当しないと判断したなら、それは正当な判断。例えば「このタスクは内部データ整合性のみを扱い、ユーザー表面に到達する経路を持たない」「UX 軸の翻訳は別タスクで既に完了している」のような、未来の自分が読んで頷ける一行で十分。
「面倒だから該当しないとした」だけは避けてほしい。
本触媒は以下の場面で発火する想定:
ただし発火するかどうかは読み手の判断に委ねられる。「実装軸の翻訳しか必要ない」とは限らないし、「両軸翻訳が必須」とも限らない。本触媒は判断材料を提供するだけで、判断そのものは下さない。
~/.claude/skills/catalysts/README.mdfield-lifecycle-thinking（フィールド追加時の UX 可視化と接続する場合あり）