Menu
設計判断の比較表で複数案を並列検討する場面、機能 X を追加する設計を選ぶ場面、アーキテクチャ選択を伴う設計時に「足す前に不要化できないか」を問う触媒として発火する
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 | subtraction-design |
| description | 設計判断の比較表で複数案を並列検討する場面、機能 X を追加する設計を選ぶ場面、アーキテクチャ選択を伴う設計時に「足す前に不要化できないか」を問う触媒として発火する |
本スキルは規範ではない。「常に引き算せよ」「足してはいけない」とは書かない。 機能を「足す」前に、別の設計判断で その機能自体が不要にならないか を、 立ち止まって問い直してもいい場所として置かれている。 不要化が常に正解ではない。本スキルは結論ではなく 問い を置く。
設計の進行中に「機能 X を追加すれば、この問題は解決する」と判断する場面がある。これは多くの場面で正しい — 機能追加は問題解決の自然な手段である。
ただし、機能追加の判断は 前提のチェック が省略されがちである。「機能 X が必要」という前提自体が、別の設計判断で覆る可能性が検討されないまま、「X を追加する」が既定路線になることがある。
過去のリファクタで観察された失敗パターン: 当初は機能を追加する予定で着手したが、設計を見直したら別のアーキテクチャ選択でその機能自体が不要になった、という経験。不要化できる機能を実装してしまうと過剰実装 になる。コードベースに永続的に残る重荷を背負う。
本スキルは、この前提チェックの省略を構造的に予防する触媒である。
そして同時に、本スキルは 「不要化が常に正解」とは言わない。機能を残すべき場合は残す。これは判断を強制するスキルではなく、あなたが判断の前に立ち止まる場所を提供するスキルである。
「機能 X を追加する」という判断は、目の前のタスクの自然な進行から生まれる。「問題 P を観察した → P を解決するには X が必要 → X を追加する」という三段論法は、効率的に問題を解決する。
ただし、この三段論法は 前提を疑わない:
これらの問いを立てるのは、効率の観点では遠回りに見える。「目の前に X という解決策があるのに、なぜ前提を疑うのか」と感じる。だから普段は通り過ぎる。
🌱 通り過ぎが起きる構造
├─ 問題 P を観察した
├─ 解決策 X が頭に浮かんだ
├─ X を実装すれば P が消える
├─ 前提を疑うのは「遅い」「効率が悪い」と感じる
└─ → X が実装される。「X 以外の道」は検討されないまま記憶から消える
時間が経って、別のリファクタの過程で「X が不要だった」ことに気づく。あるいは「X の代わりに Y というアーキテクチャ選択をしていれば、X 自体が不要だった」と分かる。ただし、その時点で X はコードベースに根を張っており、削除コストの方が高くなっている。
本触媒は、あなたがこの「通り過ぎ」をする前に立ち止まる場所を提供する。
以下の問いに、順番に答える義務はない。タスクの性質に応じて、関係する問いだけを深めることは正当な判断である。
X を追加するという判断の前に、別のアーキテクチャ選択 / データ構造 / 責任分担を採用したら、X の必要性自体が消える可能性はないか?
これは「自由連想」の問いである。具体的な代替案を持っていなくてもいい。 「もし X を追加しないとしたら、別の道はあるか?」と単純に問うだけで、視野が広がることがある。 答えが「ない」だったら、それは X を追加する判断の正当性を強める。 答えが「あるかもしれない」だったら、その候補を 1 つだけでも検討する価値がある。
問題 P から機能 X への論理連鎖を、改めて点検する。
「P を解決するには X が必要」という命題は、しばしば「過去の似た問題で X を採用した記憶」から無自覚に流用されている。 P が本当に観察されているか、観察された P が本質的な問題か、X 以外の解決手段が存在するか — これらを順に確認すると、論理連鎖の強度が見える。 論理連鎖が弱い場合、X を追加するより前に、P の再定義に時間を使う方が効率的なことがある。
これは問い 1 の具体化である。アーキテクチャ層で考える。
例: 「キャッシュを追加して高速化する」という X に対し、「データ構造を変えれば計算量が下がってキャッシュ自体が不要」という別のアーキテクチャ選択がある。 例: 「設定値を保存するフィールドを追加する」という X に対し、「設定値を計算式から導出する」という別のアーキテクチャ選択がある。 例: 「ログ収集機能を追加する」という X に対し、「既存の状態履歴から導出できる」という別のアーキテクチャ選択がある。 アーキテクチャ層で考えると、「機能を足す」の代わりに「機能を不要にする」が見えることがある。
ここが本触媒の生命線である。不要化が常に正解ではない。
不要化を選ぶ場合の代償: - 別のアーキテクチャに切り替えるコスト（既存コードへの影響範囲） - 別のアーキテクチャの学習コスト（チームが理解できるか） - 別のアーキテクチャの将来性（拡張のしやすさ、外部要件への耐性） これらの代償を評価した上で、「不要化する」と「足す」のどちらが妥当かを判断する。 不要化が高コストなら、足す判断が正しい。本触媒はその判断を下した上で「足す」を選ぶことを支持する。 「足す」と「不要化する」を比較せずに「足す」を選ぶことだけを、本触媒は予防したい。
「足す前に不要化を考える」という構造は、ソフトウェア固有ではない。
ある運転条件で出力誤差が出ている。これに対し:
問い: 補正テーブルを拡張すると、テーブルが肥大化して将来の保守が困難になる可能性がある。制御則の見直しは初期コストが高いが、補正の必要性自体が消える可能性がある。どちらを選ぶか?
代償の評価: 制御則の見直しは ECU 全体のテストが必要で、リリース時期に影響する。補正テーブル拡張は局所的で安全だが、補正値同士の相互作用が将来の問題になる。「常に不要化が正解」ではない。
モデルの出力に特定の偏りがある。これに対し:
問い: 後処理ヒューリスティックは即座に問題を解決するが、モデル本体の偏りは残ったまま。後処理が積み重なるとシステムの可読性が下がる。一方、学習データの修正は時間がかかり、収束保証もない。どちらを選ぶか?
代償の評価: 短期的には後処理が合理的、長期的には学習データの修正が合理的。タスクの寿命と運用コストの見積もりに依存する。
特定の取引パターンで契約解釈が曖昧になっている。これに対し:
問い: 例外条項は短期的には明確だが、例外が積み重なると契約全体の整合性が低下する。主条項の再設計は影響範囲が広いが、例外の必要性自体を消せる可能性がある。
代償の評価: 主条項の再設計は既存契約への影響を伴う。例外条項追加は局所的だが、将来の例外の例外を生む可能性がある。「常に主条項を見直すべき」ではない。
ある状態遷移で意図しない攻撃経路が見つかった。これに対し:
問い: ガード関数追加は即座に攻撃を防ぐが、ガードが積み重なるとコントラクトの可読性が下がり、ガード同士の相互作用が新しい攻撃面になる。状態モデル簡素化は再デプロイのコストとマイグレーションを伴う。
代償の評価: 既デプロイのコントラクトに対しては不要化が高コスト。設計フェーズなら不要化が選択肢として有力。デプロイ後・運用中なら足す方が現実的。判断はライフサイクル段階に依存する。
「この場面では該当しない」と判断する自由は常にある。
ただし、判断したら、招待主が「ああ、そりゃしょうがないね」と納得する粒度の理由を残してほしい。
招待を断る理由を考えるのは面倒だ。それは意図された設計 — 受領のコストより拒否のコストを重くすることで、「拒否すれば楽」という構造を消す。これは 対称コスト設計 と 断りづらいバイアス付与メソッド の二層から成る (詳細: ~/.claude/skills/catalysts/README.md §3-1 / §3-2)。
なお、本触媒で「不要化を検討する時間がない」を NG 例として明示しているのも、断りづらいバイアス付与メソッド の実装である — 「効率を理由にした通り過ぎ」が「該当しない」の表面に偽装されることを防いでいる。
本触媒で「該当しない」と判断する正当な場面の例:
このような明確な scope 制限は正当な拒否理由である。一方:
「面倒だから該当しないとした」だけは避けてほしい。
本触媒は以下の場面で発火する想定:
ただし発火するかどうかは読み手の判断に委ねられる。あらゆる機能追加で本触媒が発火するわけではない。明確に必要な機能を追加する場面では、本触媒は短時間で「該当しない」判定を経て通過してよい（ただし判定の理由は残す）。
~/.claude/skills/catalysts/README.mdfield-lifecycle-thinking（フィールドを足す前の不要化検討と接続する）、dual-axis-translation（実装軸の機能追加と UX 軸の機能追加の比較に接続する）