Ti Metadata

ti-metadata — メタデータ設定スキル（PSA/IMA 整合カスタマイズ）

概要

PSA/IMA（Salesforce マネージドパッケージ）のカスタマイズ（メタデータ編集）を、AI が PSA/IMA の現状と整合性を保って設定するためのスキル。中核は実組織の現状を真実の源にした差分方式で、知識層（参照系）の「describe → 生成器 → 配布スキル」パターンを write/config 側へ延長したもの。

業務データ（トランザクション・マスタ）のレコード作成・更新を伴う工程を含む場合は、書込直前に ti-reference の書込前構造ゲート references/write-index.md を発火点で読む（auto_create シームの二重計上回避）。メタデータ定義（項目・オブジェクト・レイアウト等）やカスタムメタデータ（__mdt）のレコード配備自体は本ゲートの射程外（CMDT は設定レコードで DML 不可・auto_create シーム非該当）。

そのセッションで最初に TI のスキルを使うときは、依頼の内容を問わず ti-core references/version-freshness.md を読み、同梱の版と公開されている最新版を照合する（1 セッション 1 回。古ければ本題の前に 1 行告げ、そのうえで本題は進める）。

製品の操作手順・可否・理由を書こうとした瞬間／既存の挙動を「不具合」と書こうとした瞬間／カスタマイズの対象範囲を自分で数え上げようとした瞬間は、ti-core references/knowledge-lookup.md を読み、その作法でナレッジを引く [REQUIRED]。 本スキルは実組織のメタデータを読むことを正規の手順にしている。だからこそ、読めたメタデータだけを材料に「標準はこうなっている」「これは仕様どおりでない」と書いてしまいやすい。 メタデータは「何がどうなっているか」を示すが、「そうあるべきか」は示さない。標準の意図はナレッジにある。

前提・インストール・クイックスタートは同梱の README.md を参照。 本スキルは sf CLI v2＋Python3＋認証済み org があれば容れ物に依存せず単体で機能する。

種別ごとのオーサリング手順と確定した癖は references/metadata-type-recipes.md、共有モデル設定（SharingRules／OWD）は references/sharing-model.md。 本ファイルは全種別に共通する規律（安全弁・プリフライト・中核ループ・整合ルール）を持つ。

対象メタデータ:

org カテゴリと安全弁 [REQUIRED]

開発・検証 org は 3 カテゴリに分けて扱う。「sandbox/scratch で開発・本番直書き禁止」という二分は、PSA/IMA 整合検証の実態（PSA/IMA 導入済み org がトライアルしか無いことがある）に合わないため改めた。

安全弁:

1. PSA/IMA 整合検証は導入済みトライアル org（保護カテゴリ）で行う。トライアル org は本番ライセンスを持たず sandbox を作成できないため、create-sandbox は保護 org に対しては使えない（本番／sandbox ライセンス org でのみ有効）。整合検証はトライアル org 直接で行い、着手前に対象メタデータを retrieve バックアップして失効・破壊に備える。

2. 本デプロイ前に必ず checkonly（validation）を先行（--dry-run）。ただし --dry-run 単体では Apex テストが走らない。Apex を含む deploy では --test-level RunLocalTests を明示する。

3. 本番 org への本デプロイは承認ゲート必須（承認者の明示承認。tb_mdconfig.py は --approved-by で承認者を記録）。保護（トライアル）org への deploy も確認ゲート（--confirm）対象。組織に本番変更管理ルールがあればそれに従う。

4. マネージドパッケージ改変不可境界を尊重。tb_PSA__／tb_IMA__ 名前空間の管理対象コンポーネント本体は変更できない。許される拡張は「管理対象オブジェクトへのカスタム項目追加」「権限セットでの FLS・参照付与」「レイアウト追加」「管理対象オブジェクトへの入力規則追加」等。

5. Apex は本番で 75% カバレッジ必須。トリガーはテストクラス同梱必須。sandbox/scratch では緩いが、本番展開を見据えて常にテストを書く。テストレベルは保護org検証では RunSpecifiedTests --tests {自テスト} で自テストのみ実行＝サブスクライバ org に同梱される標準ボイラープレート（Communities/Site の *ControllerTest 等）の不安定さを巻き込まない。本番では org 全体 75% を満たすため RunLocalTests（サブスクライバ全テスト）を使う。管理対象オブジェクトのトリガは新規 insert がVR・必須マスタ依存で困難なため、テストは @isTest(SeeAllData=true) で既存レコードを update して被覆する（テスト内 DML はテスト終了時に自動ロールバック＝実データ非改変）。

6. FlexiPage の「割当（Activation）」は AI が設定する（基本）。ただし管理対象オブジェクトでは特に、実行前に必ずユーザー（依頼者・管理者）の確認を求める [REQUIRED]。FlexiPage は「作成（deploy 可）」と「割当（どの画面に出すか）」が分離し、割当は flexipage-meta.xml 単独では完結しない（UI Activation か CustomApplication／プロファイルの actionOverride／profileActionOverride 経由）。管理対象オブジェクトの既存アプリ・割当を上書きする変更は改変不可境界・既存運用に触れるため、AI が割当案を用意したうえで、deploy 前に必ずユーザー確認を取る（無確認で割当を確定しない）。作成のみのデプロイは確認ゲート（--confirm / 本番承認）の通常ゲートで足りる。割当の実機検証で確定: (a) App単位割当＝新規／自前のサブスクライバ CustomApplication の actionOverrides（type=Flexipage・content=ページ名・pageOrSobjectType=対象オブジェクト・formFactor Large/Small）で管理対象オブジェクトにサブスクライバ FlexiPage を割当でき、実deployで永続する。(b) Org-default 割当（オブジェクト既定ページ＝全アプリ共通）はサブスクライバ側メタデータでは不可（管理オブジェクトの object-meta.xml 部分 deploy が「label 必須」で完全なオブジェクト定義を要求＝改変不可境界に阻まれる）。したがって割当は App 単位が現実解。既存アプリの割当を上書きしない安全策＝専用の新規アプリに割当を作る（既存運用ゼロ影響）。

7. Flow オーバーライド（isOverridable）は置換型・全置換のため、本番展開はドリフト監視とセットでのみ可 [REQUIRED]。パッケージが isOverridable=true で開放した record-triggered before-save flow をサブスクライバ Flow で差し替えるカスタマイズは、実機で置換型（Active なオーバーライドがあると管理 Flow は実行されずオーバーライドのみが走る）かつ全置換（元 Flow の全分岐を再現しないと未再現ケースに値が入らない）と確定した。ゆえにベンダー（パッケージ提供側）が標準 Flow に新ケース／新ロジックを追加・変更しても、顧客 org のオーバーライドはサイレントに古いロジックで動き続ける（＝全置換ドリフト）。集計軸の取り違えは予実・ロールアップ・帳票の誤集計に直結するため、全置換型オーバーライドはドリフト検知（オーバーライド Flow vs 最新標準 Flow の差分監視）とセットでなければ本番展開不可とする。あわせて、(a) オーバーライドの有効化は §安全弁6（割当＝管理対象では実行前に必ずユーザー確認）と同様に扱う（挙動を直接変えるため影響が大きい）、(b) 本番での Flow 有効化経路は検証 org（status=Active deploy で完結）と異なりうる（本番は非アクティブ配備＋別途有効化の既知事象）ため本番展開前に実機確認する、(c) オーバーライドの無効化は FlowDefinition activeVersionNumber=0 の単独 deploy で完結し管理 Flow が自動復帰する（オーバーライド本体・<overriddenFlow> 宣言は残置のまま＝ロールバックが軽量）。詳細手順は references/metadata-type-recipes.md §Flow オーバーライド。

8. 共有モデル設定（SharingRules／OWD）はアドバイザリー専用・衝突検知つき追記・checkonly 先行・承認必須の最上位ブラストレンジ [REQUIRED]。共有ルール／OWD の設定は他のメタデータ種別と異なり、org 全ユーザ・全オブジェクトのレコード可視範囲を変える（本人権限で読むだけの参照系・入力支援の実行時スコープを大きく超える）。ゆえに (a) 導入セットアップ（アドバイザリー）専用とし、参照系・レポート実行時経路とは物理的に別経路にする、(b) 外部書込は都度承認必須＋checkonly（--dry-run）を必ず先行（ただし checkonly が担保するのはメタデータ妥当性のみで、本デプロイで走る org 全体の共有再計算の実行影響＝可視範囲の実変化・再計算時間・ロック sharing operation already in progress は担保しない。加えて実機検証で、既存 owner rule と (sharedFrom,sharedTo) が衝突する追記が既存の access を silent 縮小（Edit→Read）しても checkonly は success を返し捕捉しないと確定。承認提示に付与一覧＋高ボリュームobjへの付与警告＋メンテ枠推奨＋衝突プリチェックが検出した access 差分（特に downgrade）を含める）、(c) 衝突検知つき追記（「追記のみ＝権限単調増加＝安全」は成立しない・実機検証で反証）＋additive＝SharingRules コンテナ deploy は additive（省いたルールを消さない・実機検証で確定＝REPLACE ではない）。deploy 前に必ず retrieve→merge（削除回避のためではなく衝突検知＋源泉一元化のため。単体ファイルをorgへ直接deployしない＝既存を反映しないと衝突を検知できない）、(d) OWD 変更は共有ルール1本より桁違いのブラスト（当該objの全レコード既定可視性をorg全体で変える）＝射程に含めるなら現行OWD retrieve＋差分＋承認＋復元ランブック必須。詳細は references/sharing-model.md。

カスタマイズ着手プリフライト [REQUIRED]

メタデータ＝カスタマイズ（入力規則の追加・項目の非表示・トリガ／Flow オーバーライド・共有ルール等）に着手する前に、本プリフライトを必ず一度走らせてから §中核ループ（差分方式）に入る。目的は 2 つ。(1) その変更が PSA/IMA の既存機能とバッティングしないか・どんなリスクがあるかを、着手のたびに一貫した観点で洗い出すこと。(2) 将来のバージョンアップで壊れにくい疎結合な設計へ寄せること。 個々の判断材料は本スキルの §org カテゴリと安全弁（安全弁1〜8）・§PSA/IMA 整合ルール・references/sharing-model.md に既にある。本節はそれらを廃止せず「いつ・どれを適用するか」に束ねる統合フロントエンドである（既存の安全弁・整合ルールの置き換えではない）。

手順

0. 対象がパッケージ側のものだったとき、迂回策を考える前に references/metadata-type-recipes.md §PSA/IMAのコンポーネントへ、購読側からできること を見る [REQUIRED]。 「パッケージが提供しているものだから変えられない」で迂回すると、購読側から手を入れられる範囲を使い残したまま、重い代替設計に進むことになる。逆に、足せても後から消せない型があるので、可否と取り消し可否をここで対にして確かめる。
1. 対象を確定する（オブジェクト・項目・メタデータ種別・変更の中身）。
2. 下記 6 軸ルーブリックで評価する。機械で確定できる軸は describe／retrieve で事実を取り（中核ループの「現状を真実の源に」を着手前へ前倒し）、意味判定が要る軸は依頼者（管理者）へ確認する。
3. リスクレベルとゲートを決める。中・高リスクなら §疎結合設計原則 に照らして代替案を用意し、そちらを既定案にする。
4. 判定結果（軸別の所見・リスクレベル・影響一覧・差分）を、deploy 前の確認／承認提示に載せる（§安全弁3、共有ルール／OWD は §安全弁8）。

6 軸ルーブリック

リスクレベルとゲート

二層で扱う（references/sharing-model.md のアドバイザリー分界・知識層 gate_policy と同型）。名前空間判別・既存 VR/トリガ/Flow/共有ルールの列挙・内部識別子リークは機械が確定できる（HARD）。一方、発火の意味的衝突（軸2）・自動処理経路に載るかの断定（軸3）・非表示にして業務が回るかの断定（軸5）・「機能が無い」の断定は、標準挙動と機械判別できないため 示唆（ADVISORY）止まりとし、最終判定は依頼者（管理者）に返す。

疎結合設計原則（P1〜P8）[REQUIRED]

将来のバージョンアップ（PSA/IMA の更新＝管理側 VR・トリガ・Flow・項目の差し替え）で壊れにくいカスタマイズにするための設計方針。プリフライトで中・高リスクが出たら、これに沿った代替を既定案にする。各原則に「なぜバージョンアップに強いか」を添える。

• P1 拡張のみ・本体非改変（additive） — 管理本体を書き換えないためベンダー更新と競合しない（§安全弁4）。
• P2 サブスクライバ項目のみに依存 — トリガ／VR／Flow は無印（サブスクライバ）項目だけを読み書きする。管理項目の意味・存在はバージョンアップで変わりうるため、そこに依存しないほど壊れにくい（§PSA/IMA 整合ルールの「サブスクライバ・トリガは管理項目・管理ロジックに依存しない」を全種別へ一般化）。
• P3 追加型を選び置換型を避ける — Flow オーバーライドは置換型・全置換＝現行標準ロジックへの強結合＝ドリフト源（§安全弁7）。可能なら「サブスクライバ項目を更新する before トリガ＋その後に評価されるサブスクライバ VR」のような追加型の拡張点を優先する（§PSA/IMA 整合ルール before→VR 順）。
• P4 正規システム更新に触れない設計 — VR やロジックを PSA/IMA 自動書込の経路に載せない。人手入力だけをゲートし、システム書込は許可リストで通す（集計・再同期・作成済フラグ・auto_create シームを壊さない）。
• P5 機構と権限の分離 — 実効担保は権限／FLS で行い、解除できる主体を権限側で固定する（機構だけでなく「誰が変えられるか」を分離）。
• P6 置換型・管理依存はドリフト監視とセット — 置換型オーバーライドや管理側に依存する拡張は、オーバーライド vs 最新標準の差分検知を必ず添える。監視なしの本番展開は不可（§安全弁7）。
• P7 契約面に依存・内部依存を排除 — 依存先は参照系（知識層）に収録された標準オブジェクト／項目／挙動の**文書化された意味（契約面）**に限る。未文書の内部挙動・発火順・実装詳細に依存しない。契約面はバージョンアップでも維持されやすい。
• P8 冪等・retrieve→merge・源泉一元化 — 実 org を真実の源にし、追記は retrieve→merge で衝突検知したうえで行う（§中核ループ（差分方式）・references/sharing-model.md と同型）。再実行で壊れない。

アップグレード再検証 [REQUIRED]

ベータとして先行提供している機能です。 記述が変わることがあります。扱いは ti-core の references/beta-status.md を参照してください。ベータなのは本節が扱うアップグレード再検証だけで、差分方式のメタデータ設定は正式提供です。

PSA/IMA のバージョンアップ後は、既存カスタマイズの回帰を再判定する（予防が §疎結合設計原則、検知が本節）。(a) 全カスタマイズ対象を checkonly で再検証（依存先の消失・改変で deploy 妥当性が崩れていないか）、(b) 置換型オーバーライドの ドリフト差分を再取得（オーバーライド Flow vs 更新後の最新標準 Flow・§安全弁7）、(c) プリフライト 6 軸のうち軸2・軸3・軸5 を再判定（新設 VR／新たに依存が生じた項目／新たに自動処理が触れる項目の出現を検出）。3 点を回帰ゲートとして本番反映前に通す。疎結合設計が「壊れにくくする」予防側、本フックが「壊れていないか確かめる」検知側。

中核ループ（差分方式）[REQUIRED]

着手前に §カスタマイズ着手プリフライト（6 軸ルーブリック→リスクレベル→ゲート）を必ず一度通し、中・高リスクは §疎結合設計原則 で代替を用意してから本ループに入る [REQUIRED]。

すべての種別で共通。「現状前提」を diff で機械的に担保する。スクリプトは --json 出力を解析して成功判定・差分件数判定を行う（目視依存にしない）。

1. retrieve（現状取得・バックアップ）: 対象範囲を実組織から取得。複数型を一括で引くときは manifest を使う。

   sf project retrieve start --metadata "CustomField:tb_PSA__tb_SalesOrder__c.MyField__c" --target-org <org> --json
   

2. author（オーサリング）: 目標メタデータを生成。名前空間・型・参照先は知識層（describe）と整合させる。サブスクライバ追加項目は名前空間なし（API 名そのまま）。型別詳細は各 generating-* スキルに委譲。コンポーネント名・テンプレート名・要素構成を推測で書かない＝特に FlexiPage は、その org で有効な既存ページを 1 本 retrieve して正しい名前を確認してから書く。これは中核ループの「現状を真実の源に」を author 段階に適用したもの。

3. diff（差分）: ローカル（オーサリング後）と org 現状を比較する。

   • 使い捨て org（source-tracking 有効）: sf project deploy preview を使う。
   • 保護（トライアル）org: deploy preview は NonSourceTrackedOrgError で不可。代わりに checkonly の componentSuccesses（created / changed フラグ）を差分プレビューとして読む＋必要なら別ディレクトリへ retrieve → diff -r で確認。

4. checkonly（検証デプロイ）: validate-only。job-id を保持する。

   sf project deploy start --dry-run --source-dir force-app --target-org <org> --wait 30 --json
   # CLI の「update available」警告が stdout に混じることがある。--json は stdout のみ解析（2>/dev/null か stderr 分離）
   

5. deploy（本デプロイ）: 検証成功後にデプロイ。本番は承認後。

   • Apex を含まない変更（項目／VR／権限セット等）は通常 deploy。

     sf project deploy start --source-dir force-app --target-org <alias> --json
     

   • quick deploy（sf project deploy quick --job-id）はテストを実行した検証ジョブにしか使えない。Apex 無しの checkonly はテスト 0 件で CannotQuickDeployError（Source validate did not run tests）になる。Apex（トリガ＋テスト）を --test-level RunSpecifiedTests で検証したジョブは quick deploy が成立する＝quick はテストを再実行せず（numberTestsCompleted=0 で実証）、本番投入時のテスト二重実行を避けられる。Apex を含まない種別は quick 不可で通常 deploy になる。
   • CLI finalize メッセージ欠落バグ（必ず job-id で実ステータス確認）: sf CLI 2.93.7 は deploy 完了直前に MetadataTransferError: Missing message metadata.transfer:Finalizing for locale en_US. を投げて exit 1 になることがある。これは finalize 工程のローカライズメッセージ欠落による表示バグで、サーバー側のデプロイは成功している。exit 1 を即「失敗」と判定せず、エラー JSON の data.id の job-id で sf project deploy report --job-id <id> --target-org <org> --json を実行し status/numberComponentErrors で実判定する。

6. verify（突合）: 別ディレクトリへ再 retrieve し目標と差分 0 を確認（force-app を上書きしない）。または SOQL で実在確認する。

   • FieldDefinition（Tooling）は作成直後の項目を返さないことがある。項目の実在は CustomField（Tooling, TableEnumOrId/DeveloperName） か FieldPermissions で確認する。VR は ValidationRule（Tooling, Active）、権限セット FLS は FieldPermissions で確認。

7. 記録（設計書・仕様書の出力）[REQUIRED]: 配備が成功したら、加えたカスタマイズの設計書（何を・どこに・なぜ加えたか）と仕様書（どこをどう変えられるか）を出力する。カスタマイズを1件加える／変更するたびに出す（references/customization-design-doc.md）。あわせて意味付けの記録ペイロード（対象・意図・author・確信度）を ti-spec-view の記録プロトコルへ渡す（意味付けの蓄積は同スキルが持つ＝二重ホームにしない）。これを省くと、AI が加えたカスタマイズがそのままブラックボックスになる。 配備を伴わない経路にも及ぶ [REQUIRED]。本手順の出力トリガは手順6の直後に置いているが、AI が配備しないカスタマイズも記録の対象である。共有モデル設定（§安全弁8＝アドバイザリー専用でデプロイは利用者側）のように AI の手が配備まで届かない種別でも、設計として確定した内容は同じ形で出力する（references/customization-design-doc.md の射程は共有ルール／OWD を含む）。**起点は「配備が成功したこと」ではなく「加えるカスタマイズの内容が確定したこと」**で、配備の事実の欄は利用者側が適用した時点で埋める。ti-spec-view へ渡す記録ペイロードだけは配備の確認後に渡す（未適用のものを org の現状として蓄積しない）。

デプロイ順序（依存解決）: カスタムオブジェクト／項目／入力規則 → 権限セット → Apex → Flow(Draft) → Flow 有効化。順序違反は FLS・参照エラーの主因。VR が数式で参照する項目は同一 deploy 単位に同梱する（INVALID_CROSS_REFERENCE_KEY 回避）。カスタム項目は権限セット（または現在プロファイル）に FLS を入れないと誰にも見えないため、項目と権限セットを同梱する。

PSA/IMA 整合ルール [REQUIRED]

• 標準/カスタム判別: API 名の名前空間接頭辞（tb_PSA__／tb_IMA__＝管理対象、無印＝サブスクライバ追加）で判別。知識層の判別ロジックを流用。
• 改変不可: 管理対象コンポーネント本体（管理対象の標準項目・既存 VR・既存トリガ等）は変更不可。拡張のみ可。
• 管理対象オブジェクトへの拡張: 項目追加・FLS 付与・VR 追加・サブスクライバ承認プロセス追加・サブスクライバ FlexiPage 作成・サブスクライバ ReportType 追加（管理対象を baseObject に）・サブスクライバ Apex トリガ追加は実証済（管理側の承認プロセス・record page・ReportType・トリガと共存できる）。ただしオブジェクトごとにマネージャビリティが異なりうるため、新オブジェクトでは最小コンポーネントの checkonly で先に判定する。
• 管理トリガとサブスクライバ・トリガの共存: 管理対象オブジェクトに管理トリガがあってもサブスクライバ・トリガを追加できる。両者の発火順序は保証されないため、サブスクライバ・トリガは管理項目・管理ロジックに依存せずサブスクライバ項目のみを操作する設計にする（衝突回避）。before トリガでサブスクライバ項目を更新すると、その後に評価されるサブスクライバ VR を満たす方向に使える（before→VR 順）。
• FlexiPage の割当は別工程・要確認・App単位が現実解: サブスクライバ FlexiPage は作成こそデプロイできるが、割当（Activation）は flexipage-meta.xml 単独では完結せず CustomApplication の actionOverrides（App単位）経由。App単位割当は新規／自前サブスクライバアプリで実deploy可・永続を実証／Org-default（オブジェクト既定・全アプリ共通）は管理オブジェクトでは不可（object-meta.xml 部分deployが label 必須＝改変不可境界）。管理対象オブジェクトの既存割当・管理アプリを上書きする変更は慎重に扱い、§安全弁 6 のとおり AI が割当案を用意して deploy 前に必ずユーザー確認を取る（安全策＝専用の新規アプリに割当を作り既存運用に触れない）。
• Flow オーバーライド（isOverridable）は置換型・全置換: パッケージが isOverridable=true で開放した Flow のみオーバーライド可。サブスクライバ Flow に <overriddenFlow>{名前空間付きの管理 Flow 名}</overriddenFlow> を置き、object/trigger/processType を元と同一にする。Active なオーバーライドがあると管理 Flow は実行されない（置換型）ため、元の全分岐を再現したうえで変更箇所だけ差し替える（全置換）。本体は改変しないが、ベンダーが標準 Flow を更新してもオーバーライドは追従しない（全置換ドリフト）ので本番展開はドリフト監視とセット必須（§安全弁7）。オーバーライドは生成元パッケージを問わず同オブジェクトの全レコードに効くため、他パッケージ由来レコードへの波及も確認する。
• VR/トリガ整合: 入力規則・トリガを追加するとき、既存の PSA/IMA サーバー側 VR・トリガと発火条件・順序が衝突しないか確認する。PSA と IMA は双方向にオブジェクトを後付け拡張するため、片方のパッケージのメタデータだけで「VR/トリガは全部こうだ」と結論せず、両パッケージを数え上げて整合確認する（両パッケージ併存環境の判断完全性）。
• 主従・参照制約: カスタム項目で参照（Lookup/MD）を張るとき、参照先の到達可能性・削除挙動を describe で確認。
• 型ごとの癖は実機で確かめる: 型ごとの API 上の癖は、確定として書く前に作業 org で実機検証する。

効率化スクリプト

scripts/tb_mdconfig.py が中核ループ（sandbox 作成／retrieve／diff／checkonly／quick deploy／deploy／verify）を sf CLI v2 上でラップする。

• --json 出力を解析し、成功/失敗・差分件数を機械判定する。
• 本番（PROD_ALIAS_HINTS）への deploy は --approved-by 必須＋承認ログ。NoTestRun は本番で拒否。
• 保護（PROTECTED_ALIAS_HINTS）への deploy は --confirm 確認フラグ対象。自組織の検証 org の alias を PROTECTED_ALIAS_HINTS に追加して使う（スクリプト冒頭の定数）。
• verify は別ディレクトリへ retrieve し目標と差分 0 を確認（ローカル目標を上書きしない）。
• diff は非トラッキング org で失敗したとき retrieve→ローカル diff フォールバックを案内する。
• quick はテスト実行済み検証ジョブ専用。Apex 無しの変更は deploy を使う（失敗時に案内）。

共有モデル設定の author 段（CSV→SharingRules XML 生成・衝突プリチェック）は scripts/tb_sharing.py。使い方は references/sharing-model.md。

参照

関連スキル

PSA/IMA 双方の VR・トリガ整合確認（両パッケージ併存環境の判断完全性）は §PSA/IMA 整合ルール に内蔵。本番 org 書込の承認は §org カテゴリと安全弁 3 に従う（組織の本番変更管理ルールがあればそれを優先）。

実証済みの型（一覧）

カスタム項目・権限セット・入力規則／承認プロセス／FlexiPage 作成／レポートタイプ／Apex トリガー＋テスト／FlexiPage の App 単位割当／リストビュー＋ReportFolder＋Report 本体〔標準レポートタイプのみ〕／FlexiPage のプロファイル単位割当＋既存 unmanaged アプリ上書き境界／Flow オーバーライド〔isOverridable・置換型・全置換〕／LWC＋StaticResource〔管理対象レコードページ配置・$Resource 参照・@AuraEnabled 業務 Apex 配備〕／Visualforce ページ（描画面VF）＋非トリガ Apex クラス〔VF カスタムコントローラ・quick deploy〕／カスタムメタデータ〔型＋レコード・型→レコード 2 段配備・xmlns:xsd 宣言必須・レコードはメタデータ API 配備のみ〕／共有ルール〔SharingRules 2 型＝所有者ベース／条件ベース・衝突検知つき追記（owner rule は (sharedFrom,sharedTo) で一意化＝衝突追記が既存 access を silent 縮小しうる／criteria rule は (sharedTo,field,value) で一意化されず並存＝実効UNION／deploy は additive＝省略は削除しない・削除は destructiveChanges／挿入は XSD グルーピング遵守／checkonly は access 変化非捕捉）・アドバイザリー専用ブラストレンジ〕。

各種別の確定した癖は references/metadata-type-recipes.md、共有モデル設定は references/sharing-model.md。

残る要実機確認

• トライアル org で sandbox 作成可否（保護 org 直接運用の前提では着手不要）。
• Report 本体（カスタムレポートタイプ参照）の Metadata 配置: invalid report type＝Metadata 配置不可と確定。代替は UI 作成、または将来 API 仕様変更時に再検証。ReportType 自体は Metadata 配置可。
• 既存アプリ割当上書きの境界続き: サブスクライバ自身の unmanaged アプリ上書きは技術的に可能と確認（高影響で無確認 deploy 禁止）。管理（installed）アプリ本体の割当改変は改変不可境界の別ケースで未検証。
• Apex トリガーの本番カバレッジ運用（RunLocalTests で org 全体 75%・既存サブスクライバテストの健全性）は保護org では RunSpecifiedTests で代替検証済。本番投入時に org 全体カバレッジ（RunLocalTests・75%以上）と既存サブスクライバテストの健全性を実機確認する（本番展開前の必須ゲート）。
• Flow オーバーライドの本番 active 化経路: 検証 org は status=Active deploy で有効化が完結したが、本番は Flow が非アクティブ配備＋別途有効化（Tooling REST PATCH 等）になりうる。本番投入時に有効化経路を実機確認する（本番展開前の必須ゲート・§安全弁7-b）。
• 全置換ドリフト監視の方式: 全置換型オーバーライドはベンダーの標準 Flow 更新に追従しない。オーバーライド Flow vs 最新標準 Flow の差分検知をどの仕組みに載せるか未確定。本番展開のブロッカー条件（§安全弁7）のため、本番展開前に方式を確定する。
• 部分オーバーライドの可否: 全置換で実証済。分岐を減らした最小オーバーライドが成立するかは未検証（置換型ゆえ実用上は全分岐再現が正）。
• @AuraEnabled 業務ロジック Apex の本番 75% カバレッジ: 配備・稼働は実証済（保護 org は 0% でも稼働）。本番 75% カバレッジを満たすテスト実体は帳票実装（ti-report）側の責務で、本番投入時に組織全体 75%（管理パッケージ Apex は分母除外・各トリガ >0%）を実機確認する。
• 共有ルール（共有モデル設定）の本番展開ゲート: 設定内容の妥当性は checkonly（メタデータ検証）＋author 段の衝突プリチェックで担保するが、本デプロイで走る共有再計算の実行影響（可視範囲の実変化・所要時間・ロック競合）は checkonly では見えないため、本番展開はメンテナンス枠・付与一覧の承認提示・復元ランブックとセットで行う。
• owner rule の全社員宛（共有先＝全内部ユーザ）の冪等・重複挙動: 全社員宛 owner rule は <group> を持たず冪等判定 regex が一致しないため、再実行時に同一 owner rule が重複追記されうる。precheck 側でも direction=same は表示から除外するため重複が表面化しない。同一ファイル内に同キー owner rule が複数本並ぶ deploy を SF がどう扱うか（エラー or last-wins）は未実測＝本番展開前に実機確認する。
• プリフライト軸3・軸5 の自動化可否: 「PSA/IMA の自動処理が読む／書く項目」（軸3）・「非表示項目の下流依存＝Flow／VR／Apex／ロールアップ／人手入力工程」（軸5）を describe だけで機械抽出できるか、人手棚卸しが要るかは未確定。現状は ADVISORY（人手判定）へ倒している。参照系（知識層）の意味定義との連携でどこまで機械化できるかを実機確認する。
• auto_create／集計が依存する項目のマスタ一覧（軸3・P4 の判定材料）: 源泉再同期・集計ハブ・作成済フラグ・auto_create シームが読む／書く項目の網羅一覧は未整備。参照系（知識層）の意味定義側と連携して棚卸しする範囲を確定する。
• アップグレード再検証の実行トリガ: PSA/IMA バージョンアップ後の回帰ゲートを、バージョンアップ通知をどう起点に自動発火させるかは未確定。上記の全置換ドリフト監視の方式と同じ仕組みに載せる想定で、本番展開前に方式を確定する。

変更履歴

• v3.9.0（2026-09-09）: 設計書の版の作法（上書きしない・自己完結・変更履歴）を ti-core references/deliverable-versioning.md へ寄せ、references/customization-design-doc.md は参照だけを持つ形にした（帳票側と同じ 1 行を別々に持っていた重複の解消）。
• v3.8.0（2026-09-07）: 使わなくなった項目を廃止する手順を追加（references/metadata-type-recipes.md §使わなくなった項目を廃止する）。本スキルはカスタマイズを足す手順しか持たず、引くときの手順が無かった。廃止は削除ではない（消さずに見えなくすれば、既存の参照を壊さずに新しく使い始める人だけを止められる）ことを起点に、段階A（見えなくする・既存の計算に影響なし・単独で先行できる）と段階B（参照を切る・代替と同時にしか打てない）へ分けた。自分で作った項目と PSA/IMA が提供している項目では打てる手がまるごと変わるため、プリフライト軸1（改変不可境界）を分岐条件に置き、提供元の項目では「完全に見えなくする」ところまで届かないこと・届かないぶんを迂回のカスタマイズで埋めないことを明記した。軸5（項目非表示の下流依存）から本節を辿れるようにした。
• v3.6.0: 製品知識の引き当て（knowledge-lookup）の発火点を追加。 本スキルは実組織のメタデータを読むことを正規の手順にしているため、読めたメタデータだけを材料に「標準はこうなっている」「これは仕様どおりでない」と書く事故が起きやすい。メタデータは「何がどうなっているか」を示すが「そうあるべきか」は示さない、という区別を §概要 の発火点に明記した。
• v3.5.0（2026-08-30）: レポートの説明文の型（references/report-description.md）への参照を SKILL.md に置いた。 型そのものは前版で新設されていたが SKILL.md からの参照が無く、レポートを作る・直す側（本スキル）から入ったときに発火しない状態だった（型は書く側で使うものなので、この経路が本命）。§参照 の表と対象メタデータ表の種別7の2箇所から辿れるようにした。あわせて型の側の良い例が必須要素3（開き方）を欠いていたのを是正した。
• v3.4.0（2026-08-29）: パッケージ側のコンポーネントに手を入れる前に、購読側からできることを確かめる手順をプリフライトの手順0へ置いた。 「パッケージが提供しているものだから変えられない」で迂回すると、購読側から手を入れられる範囲（ラベル・項目セット・レコードタイプ・同梱の接続設定）を使い残したまま重い代替設計へ進む。逆に足せても後から消せない型があるため、可否と取り消し可否を対で確かめる形にした。あわせて references/metadata-type-recipes.md へ集計に載らない金額を載せる3層の切り分け（前提スイッチ／マスタの予備枠／源泉の追加）を追加し、カスタマイズに入る前に上2層で済まないかを確かめる形にした。
• v3.3.0（2026-08-24）: ラベル・選択リスト値の翻訳（CustomObjectTranslation）を対象メタデータへ追加（種別17）。管理対象パッケージのオブジェクト名・項目ラベル・選択リスト値のラベルは購読org側の翻訳で上書きでき、値（API値）を変えずに画面表示だけを業務の言葉へ寄せられる。頻出のカスタマイズでありながら手順が無く、可否の判断から毎回やり直しになっていた。手順と確定した癖は references/metadata-type-recipes.md §ラベル・選択リスト値の翻訳。
• v3.2.0（2026-08-15）: 中核ループ手順7（記録）の適用境界を拡張。AI が配備しない種別（共有モデル設定＝アドバイザリー専用でデプロイは利用者側）でも、設計として確定した時点で設計書・仕様書を出すことを明示し、出力の起点を「配備の成功」から「カスタマイズの内容の確定」へ言い直した。ti-spec-view へ渡す記録ペイロードだけは配備の確認後（未適用のものを組織の現状として蓄積しないため）。
• v3.1.0（2026-08-05）: カスタマイズ設計書・仕様書の出力サイクルを追加（references/customization-design-doc.md）。これまで設計書・仕様書の継続修正サイクルは帳票（ti-report）にしか無く、メタデータ＝カスタマイズ全般では、AI が加えたカスタマイズがそのままブラックボックスになる状態だった。中核ループに手順7（記録＝設計書・仕様書の出力）を [REQUIRED] で追加し、配備のたびに「何を・どこに・なぜ加えたか」と「どこをどう変えられるか」を出す。生成元は既存の retrieve／diff とプリフライト6軸の判定結果で、新しい取得経路は要らない。意味付けの蓄積は ti-spec-view の記録プロトコル、往復の機構は ti-core の仕様往復プロトコルへ委譲し二重ホームにしない。
• v3.0.0（2026-07-25）: 顧客提供版化＋構造の薄化。(1) 単一の大型 SKILL.md（535 行）を、全種別に共通する規律（安全弁・プリフライト・疎結合設計原則・アップグレード再検証・中核ループ・PSA/IMA 整合ルール）と、種別ごとの手順・確定した癖（references/metadata-type-recipes.md）・共有モデル設定（references/sharing-model.md）へ分割し、他スキルと同じ「薄い SKILL.md＋references/」構造へ揃えた。(2) 検証時の実行トレース（デプロイジョブ ID・検証時の投入コンポーネント名・件数）と開発時の実施順に由来する内部の通し番号を除去し、型レベルの確定事項のみを残す顧客提供版とした。(3) Flow オーバーライドの説明を特定の標準 Flow の事例記述から、型としての手順・注意点へ一般化。(4) スクリプトの保護 org 判定ヒント定数を汎用値へ変更（PROTECTED_ALIAS_HINTS＝trial／uat／sit。自組織の検証 org alias を各自で追加する運用は不変）。手順・安全弁・整合ルール・確定した癖の内容そのものは不変（削除したのは provenance と内部識別子のみ）。
• v2.3.0（2026-07-21）: カスタマイズ着手プリフライト（競合・リスク診断 6 軸ルーブリック）・疎結合設計原則（P1〜P8）・アップグレード再検証を追加。散在していた安全弁・整合ルール・共有モデル設定の競合回避／リスク／ドリフト知見を、着手のたびに一貫して引き当てる統合フロントエンドへ再編成（既存節は不変で本節はその適用入口）。
• v2.2.0（2026-07-17）: 共有モデル設定（SharingRules／OWD）を追加。PSA 標準の共有機構（レコード可視範囲＝個人→チーム→全社）の導入セットアップ支援をアドバイザリー専用で追加。安全弁8（アドバイザリー専用・衝突検知つき追記・checkonly 先行・OWD 桁違いブラスト）と author 段スクリプト scripts/tb_sharing.py（CSV→SharingRules XML 生成器＋可視範囲ポリシー翻訳器＋衝突プリチェック）、scripts/tb_mdconfig.py の sharing-precheck／sharing-deploy を追加。
• v2.1.0（2026-07-15）: 対象メタデータを 8 型から 14 型へ拡張（Flow オーバーライド／LWC・静的リソース／Visualforce ページ＋非トリガ Apex クラス／カスタムメタデータ）。安全弁7（Flow 全置換ドリフトの本番展開ブロッカー化）を追加。
• v2.0.0（2026-07-14）: スキル名を ti-metadata へ改称。対象メタデータ型・内容は不変。
• v1.8.0（2026-06-18）: 容れ物非依存・自己完結化。同梱 README.md（前提・インストール・クイックスタート）を新設。
• v1.0.0（2026-06-17）: 初版。中核ループ（差分方式）・カスタム項目／権限セット／入力規則・PSA/IMA 整合ルールを定義。