| name | field-lifecycle-thinking |
| description | schema への新フィールド追加、メタフィールド系（status, confirmed, locked 等）の追加、フィールドの寿命を考える必要があるタスク時にライフサイクル全体を辿る触媒として発火する |
Field Lifecycle Thinking — フィールドの寿命を辿る招待状
本スキルは規範ではない。「6 段階を全部チェックせよ」とは書かない。
新しいフィールドを追加するとき、その ライフサイクル全体 を辿って
立ち止まれる場所として置かれている。
6 段階は「立ち止まる場所の候補」であって、「埋める箱の一覧」ではない。
0. これは何か
新しいフィールドを schema に追加する場面は多い。status、confirmed、locked、reviewedAt、favorite — メタフィールド系の追加は特に頻繁である。
このとき、追加作業は局所的に見える: 「フィールドを定義し、セットする箇所を書き、表示する箇所を書く」。これで作業は完了したように見える。
ただし、フィールドには 寿命 がある。生まれて、保存されて、読まれて、変更されて、ときに削除される。寿命の各段階で、設計判断が必要になる。
寿命の中の 1〜2 段階だけを実装して残りを忘れると、フィールドは「動くが穴がある」状態になる。穴は当面は見えない。穴は時間が経って表面化する。過去のリファクタで、メタフィールドの統合を見落として構造的バグを生んだ事例 が、本触媒の由来である。
本スキルは、フィールドの寿命を 6 段階に分けて、各段階を立ち止まる場所として提供する。全段階を考える義務はない。ただし、あなたが「考えなかった段階」を意識的に選択することと、無自覚に通り過ぎることは違う。
1. なぜこの問いがメタ層にあるのか
新フィールド追加の作業は、目の前のタスク文脈では「特定の機能を実現するため」に行われる。例えば「ユーザーが完了マークを付けられるようにする」という機能要件があれば、completed というフィールドを追加する。
このとき、設計の重心は「機能要件をどう満たすか」に集まる。これは正しい — 機能要件を満たさない設計は、出発点として失格である。
ただし、機能要件を満たした瞬間、フィールド追加作業は完了判定されやすい。寿命の他の段階 — 既存フィールドとの関係、リセット経路、マイグレーション、UX 可視化 — は「後で考える」「scope 外」「明確な要件がないから保留」として、忘却の層に押し込まれる。
🌱 忘却が起きる構造
├─ 機能要件 X のためにフィールド F を追加する
├─ F の最小限の振る舞い（セット・読み取り・表示）を実装する
├─ X の要件が満たされた瞬間、F の追加は「完了」と感じる
├─ ただし F の寿命の他の段階は、要件 X の文脈外なので意識から外れる
└─ → 後で別の文脈で F を扱うとき、未設計の段階が穴として現れる
特に頻発する穴は「既存フィールドとの統合の見落とし」である。既に status が存在するのに confirmed を追加する、locked がすでにあるのに frozen を追加する。意味が重なるフィールドが並列に存在することで、どちらを真に受けるべきかが曖昧になる。これは構造的バグの温床である。
本触媒は、この忘却の層に対する立ち止まり場所を 6 つ提供する。
2. 寿命の 6 段階 — 立ち止まる場所の候補
以下の 6 段階を順番に辿る義務はない。タスクの性質に応じて、あなたが関係する段階だけを深く考えることは正当な判断である。ただし「関係する段階」と「関係しない段階」の区別を意識的に下すこと、それが本触媒の機能である。
段階 1 — 発生
このフィールドはどのタイミングで何によってセットされるか?
ユーザー操作? 自動処理? 別フィールドの変更に連動? 初期値は?
セット経路を意識的に列挙すると、「想定していなかったセット経路」が発見されることがある。
例えば「データインポート時の初期値」「マイグレーション時のデフォルト」「外部 API からのバルク投入」が、機能要件の議論には現れない。
これらを後で意識すると、「インポート時はどうする?」という問いが追加要件として浮上する。
段階 2 — 解除
ユーザーがこのフィールドをリセット / 取り消したい時の経路はあるか?
セットする経路は意識される。ただし「取り消す経路」は、機能要件の議論で抜け落ちることがある。
「完了マークを付ける」要件は「完了マークを外す」要件を含むとは限らない。
しかし完了マークを付けたユーザーは、間違って付けた場合に外したくなる。
取り消し経路を提供しないと、「フィールドは付けられるが取れない」という非対称が UX に現れる。
取り消し経路を意図的に提供しない判断もありうる（不可逆性が要件の場合）。ただし意図と無自覚は別である。
段階 3 — 永続化
どこに、どう保存されるか?
DB? ファイル? メモリ? 永続化粒度は?
永続化先によって、書き込み頻度・整合性保証・障害時の挙動が変わる。
「動く」だけでは永続化先の選択は決まらない。タスクの寿命 vs ユーザー要求の永続性によって判断が変わる。
特に「セッションをまたいで残るべきか」「永久に残るべきか」「ユーザーが明示的に消すまで残るか」は、ここで決める設計判断である。
段階 4 — マイグレーション
既存データへの適用戦略は? 自動 vs lazy?
新フィールドが追加される時点で、既存データには値がない。これにどう対処するか?
自動マイグレーション（全レコードに初期値を一括投入）は確実だが、全データを触るコストがある。
lazy マイグレーション（次回アクセス時に値を補完）は軽量だが、未アクセスのレコードが半永久的に未補完のまま残る。
どちらも正解になりうる。ただし「無自覚に lazy になっている」状態（明示判断がない）は穴になる。
マイグレーション戦略を文書化しないと、後でレコードのうち一部だけ未補完であることが構造的バグの原因になる。
段階 5 — 既存メタフィールドとの統合
同種の意味を持つ既存フィールドはあるか? 関係は (上位互換 / 補完 / 置換 / 廃止 のどれか)?
これは本触媒の最重要段階である。過去にこの段階の見落としで構造的バグが生まれた。
新フィールドを追加する前に、status、flag、confirmed、locked、done 等の既存メタフィールドと意味が重ならないかを確認する。
重なる場合、関係は 4 種類のうちどれか:
- 上位互換: 新フィールドは旧フィールドの情報を全て含む。旧フィールドは新フィールドから導出可能になる
- 補完: 新フィールドは旧フィールドが扱わない側面を扱う。両方が並列に存在する意味がある
- 置換: 新フィールドが旧フィールドを完全に置き換える。旧フィールドは廃止対象
- 廃止: 新フィールドの追加に伴い、旧フィールドが不要になる
この 4 分類のどれにも当てはまらず「なんとなく両方存在する」状態は、後で必ず構造的バグになる。
「重ならない」という結論も正当な判断。ただし結論を下す前に、本当に重ならないかは確認したい。
段階 6 — UX 可視化
ユーザーがこのフィールドの状態を確認できる経路はあるか?
フィールドの値は、表面に現れて初めてユーザーから見て存在する。
内部的にしか使われないフィールド（システム内部の状態管理）は UX 可視化が不要である。
ただしユーザーの操作と関連するフィールドは、可視化経路がないとユーザーが現在の状態を判断できない。
「フィールドはあるが、どこにも表示されない」状態は、ユーザーから見て「機能がない」と区別できない。
この問いは dual-axis-translation 触媒と接続する — 実装軸でセットされた値を、UX 軸でどう見せるか。
3. 領域横断性 — 他領域での同型の問い
「新しい変数を追加するとき、その寿命を辿る」という構造は、ソフトウェア固有ではない。
領域 1 — エンジン制御マップの新パラメータ追加
新しい補正パラメータを ECU マップに追加するとき、そのパラメータの寿命:
- 発生: どの運転条件で計算されるか?
- 解除: 異常検知時にリセットされるか?
- 永続化: EEPROM に保存されるか? RAM のみか?
- マイグレーション: 旧 ECU からアップデートする際、初期値をどう決めるか?
- 既存パラメータとの統合: 既存の補正値と意味が重ならないか?（最重要 — 補正の二重適用は危険）
- 可視化: 整備士が診断ツールで読み出せるか?
問い: 補正値同士の二重適用、あるいは打ち消し合いを起こさないか? 既存補正パラメータの意味との関係は?
領域 2 — 機械学習モデルの新特徴量追加
新しい特徴量をモデルに追加するとき:
- 発生: 何から計算されるか?
- 欠損時の扱い: 値が取れないレコードでどうするか?
- 永続化: 特徴量ストアに保存するか? オンザフライ計算か?
- マイグレーション: 過去データに対してどう生成するか?
- 既存特徴量との統合: 既存特徴量との相関は? 同じシグナルを別表現で持っていないか?
- 可視化: 特徴量重要度 / SHAP 値で確認できるか?
問い: 既存特徴量と相関が高い新特徴量を追加することで、モデルの解釈性は壊れないか?
領域 3 — データベースの新カラム追加
新しいカラムを既存テーブルに追加するとき:
- 発生: どの操作で書かれるか?
- 解除: NULL に戻る経路はあるか?
- 永続化: トランザクション境界での挙動は?
- マイグレーション: 既存行に対する DEFAULT 戦略は?
- 既存カラムとの統合: 既存トリガー / インデックス / 制約との関係は?
- 可視化: アプリケーション層で表示されるか?
問い: 既存トリガーが新カラムを認識せず、整合性が崩れる経路はないか?
領域 4 — 契約条項の改定
新しい条項を契約に追加するとき（フィールドの追加に類似する構造を持つ）:
- 発生: どの取引から適用されるか?
- 解除: 特定条件で無効化される経路はあるか?
- 永続化: 文書としてどう保管されるか?
- マイグレーション（経過措置）: 過去契約への遡及適用 / 経過措置の設計は?
- 既存条項との統合: 既存条項と矛盾する条項はないか? 上書き? 補完?
- 可視化: 当事者が条項の存在を認識できる経路は?
問い: 過去契約の経過措置を設計せずに新条項を追加すると、過去取引の解釈が宙に浮かないか?
4. 該当しないと判断する場合
「この場面では該当しない」と判断する自由は常にある。
ただし、判断したら、招待主が「ああ、そりゃしょうがないね」と納得する粒度の理由を残してほしい。
招待を断る理由を考えるのは面倒だ。それは意図された設計 — 受領のコストより拒否のコストを重くすることで、「拒否すれば楽」という構造を消す。これは 対称コスト設計 と 断りづらいバイアス付与メソッド の二層から成る (詳細: ~/.claude/skills/catalysts/README.md §3-1 / §3-2)。
なお、本触媒で多用されている「6 段階を全部チェックする義務はない」「立ち止まる場所の候補であって埋める箱の一覧ではない」「6 段階のうち一部だけが該当しない判断もありうる」といった redundant な明示は、断りづらいバイアス付与メソッド の具体的な実装である — 機械的に「該当」と読まれるのを構造的に予防している。
特に本触媒では、6 段階のうち一部だけが該当しない という判断もありうる。例えば:
- 「このフィールドは内部状態のみで、UX 可視化（段階 6）は scope 外」
- 「このフィールドは新規 schema で、マイグレーション（段階 4）は不要」
- 「このフィールドはセッションスコープのみで、永続化（段階 3）は不要」
このような部分的な「該当しない」も正当な判断。ただし、特に 段階 5（既存メタフィールドとの統合） だけは、「該当しない」と判断する前に念入りに確認したい。本触媒の最も頻発する穴がここにあるためである。
「面倒だから該当しないとした」だけは避けてほしい。
5. 適用タイミング
本触媒は以下の場面で発火する想定:
- 各種 schema（データモデル / レコード型 / DTO 等）への新フィールド追加
- メタフィールド系（status, confirmed, locked, frozen, archived 等）の追加
- 「フィールドの寿命」を考える必要があるタスク
- schema 変更を伴う設計判断
ただし発火するかどうかは読み手の判断に委ねられる。フィールド追加であっても、寿命の議論が不要な場合はある。
→ 関連
- 触媒型スキル全般の設計思想:
~/.claude/skills/catalysts/README.md
- 関連する触媒:
dual-axis-translation（段階 6 の UX 可視化と接続する）、subtraction-design（フィールドを足す前に不要化できないか問う）
