# Ti Metadata

> AI が PSA/IMA と整合してメタデータ＝カスタマイズ（カスタム項目・権限セット・入力規則・承認プロセス・FlexiPage・レポートタイプ・リストビュー・Apexトリガー・Flow オーバーライド・Lightning Web コンポーネント・静的リソース・Visualforce ページ・非トリガ Apex クラス・カスタムメタデータ・共有ルール(SharingRules)/OWD＝共有モデル設定・ラベル/選択リスト値の翻訳 等）を差分方式で設定する手順とスクリプト。着手前の競合・リスク診断プリフライト（6軸ルーブリック）・疎結合設計原則（P1〜P8）・アップグレード再検証・カスタマイズ設計書／仕様書の出力サイクルを内蔵

- Skill: `tsubaiso/ti-metadata` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add tsubaiso/ti-metadata`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tsubaiso/ti-metadata/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tsubaiso (https://skillmd.com/u/tsubaiso)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tsubaiso/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`。** 本ファイルは全種別に共通する規律（安全弁・プリフライト・中核ループ・整合ルール）を持つ。

対象メタデータ:

| # | 種別 | メタデータ型 | 状態 | リスク |
|---|---|---|---|---|
| 1 | カスタム項目 | `CustomField` | **実証済** | 低 |
| 2 | 権限セット／グループ | `PermissionSet` / `PermissionSetGroup` | **実証済** | 低 |
| 3 | 入力規則（管理対象オブジェクト含む） | `ValidationRule` | **実証済** | 低 |
| 4 | カスタムオブジェクト | `CustomObject` | 項目と同型 | 低〜中 |
| 5 | 承認プロセス（＋最終承認アクション） | `ApprovalProcess` / `WorkflowFieldUpdate` | **実証済** | 低〜中（active=true 配備可） |
| 6 | Lightning Page（record page）＋割当 | `FlexiPage` / `CustomApplication`（actionOverrides / profileActionOverrides） | **実証済**（作成／App単位割当／プロファイル単位割当） | 中（作成可・**割当はApp単位／プロファイル単位で可／org-defaultは管理オブジェクト不可**） |
| 7 | レポートタイプ／リストビュー／レポート（**説明文の型は `references/report-description.md`**） | `ReportType` / `ListView` / `Report` | **実証済**（Report本体は標準RTのみ可） | 中 |
| 8 | Apex トリガー | `ApexTrigger`（＋テストクラス） | **実証済** | 高（テストカバレッジ要件・quick deploy 可） |
| 9 | Flow（`isOverridable` オーバーライド） | `Flow` / `FlowDefinition` | **実証済** | 高（**置換型・全置換**。全置換ドリフトは本番展開ブロッカー＝§安全弁7） |
| 10 | Lightning Web コンポーネント | `LightningComponentBundle` | **実証済** | 中（`isExposed`＋`lightning__RecordPage`＋`targetConfigs objects`で管理対象レコードページ配置可・可視化はFlexiPage割当ゲート） |
| 11 | 静的リソース | `StaticResource` | **実証済** | 低（配備＋テンプレの`{!$Resource.名}`参照可） |
| 12 | Visualforce ページ（描画面VF） | `ApexPage` | **実証済** | 中（管理対象オブジェクトのカスタムコントローラVFページを配備可・描画/PDFの起点） |
| 13 | 非トリガ Apex クラス（`@AuraEnabled`・VFコントローラ等の業務ロジック） | `ApexClass` | **実証済** | 高（テストクラス同梱・本番75%カバレッジは本番投入前ゲート） |
| 14 | カスタムメタデータ（型＋レコード） | `CustomObject`(`__mdt`) / `CustomMetadata` | **実証済** | 中（型→レコードの2段配備・レコードはメタデータAPI配備のみ＝DML insert不可） |
| 15 | 共有ルール（レコード可視範囲） | `SharingRules`（`sharingOwnerRules` / `sharingCriteriaRules`） | **実証済**（アドバイザリー専用） | **高・ブラストレンジ**（org全ユーザ・全レコードの可視範囲を変える・§安全弁8） |
| 16 | 組織の共有設定（OWD） | `CustomObject`（`sharingModel` / `externalSharingModel`） | 射程判断は導入時 | 高（当該オブジェクト全レコードの既定可視性をorg全体で変える・桁違いブラスト・§安全弁8） |
| 17 | ラベル・選択リスト値の翻訳（管理対象含む） | `CustomObjectTranslation` | **実証済** | 低（表示のみ・値は不変） |

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

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

| カテゴリ | 実体 | 書込ルール |
|---|---|---|
| **本番** | 顧客本番 org（alias に prod/production/本番 等） | 本番デプロイ承認ルール（承認者の明示承認）必須。checkonly→deploy。`NoTestRun` 不可 |
| **保護（トライアル・検証）** | PSA/IMA 導入済みトライアル org（検証 org） | **PSA/IMA 整合検証ができる唯一の org であることが多い**。破壊すると再取得困難・失効も近い。全 deploy を checkonly 先行＋確認ゲート（`--confirm`）対象。**着手前に対象範囲を retrieve バックアップ** |
| **使い捨て（sandbox・scratch）** | sandbox / scratch | 自由に deploy 可。ただし PSA/IMA 未導入の scratch では整合検証が限定的（DevHub からの scratch は素の Dev Edition） |

安全弁:

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 軸ルーブリック

| 軸 | 問い | 主な破壊シナリオ | 機械／人手 |
|---|---|---|---|
| **軸1 改変不可境界** | 対象は管理対象（`tb_PSA__`／`tb_IMA__`）か、サブスクライバ追加（無印）か | 管理本体（標準項目・既存 VR・既存トリガ）の改変は不可。拡張のみ可（§安全弁4・§PSA/IMA 整合ルール） | 機械（名前空間接頭辞）＋人手（拡張で代替できるか） |
| **軸2 サーバー側ロジック発火競合** | 同一オブジェクトの既存 VR／トリガ／Flow と、追加物の発火条件・順序が衝突しないか | 追加 VR が正当な保存をブロック／トリガ発火順が保証されず管理項目に依存して破綻 | 機械（**PSA・IMA 両パッケージを数え上げ**列挙）＋人手（意味的な衝突・順序依存） |
| **軸3 正規システム更新の巻き込み** | 対象の項目／オブジェクトを、PSA/IMA の自動処理が読む／書くか | 源泉との再同期（削除→再作成）、集計ハブの自動更新、作成済フラグ、自動作成（auto_create）シーム（二重計上）を、追加 VR や項目非表示が阻害する | 人手＋参照系（知識層）の意味定義（依存項目の棚卸し） |
| **軸4 可視性・共有ブラスト** | 共有ルール／OWD／FLS が、他ユーザーのレコード可視範囲を変えるか | 追記のみでも既存 access を silent に縮小（Edit→Read）／OWD は当該オブジェクト全レコードを org 全体で変える | 機械（`references/sharing-model.md` の衝突プリチェック）＋人手（付与範囲の承認） |
| **軸5 項目非表示の下流依存** | 非表示にする項目を、Flow／VR／Apex／ロールアップ／人手入力の工程が必要とするか | システムが埋める必須項目や、下流の自動作成に要る入力欄を隠すと工程が壊れる。**非表示はセキュリティではない**（FLS を外しても管理側ロジックは書き続ける）。使わなくなった項目を消さずに見えなくする手順は `references/metadata-type-recipes.md §使わなくなった項目を廃止する` | 機械（参照元・数式・ロールアップ依存の抽出）＋人手（隠して業務が回るか） |
| **軸6 割当・上書きの既存運用干渉** | FlexiPage 割当・ページ／アプリ上書きが、既存の管理アプリ・運用に触れるか | 既存割当の上書きで現行運用が変わる | 機械（既存割当の retrieve）＋人手（要ユーザー確認・§安全弁6） |

### リスクレベルとゲート

| レベル | 目安 | ゲート |
|---|---|---|
| **低** | サブスクライバ項目のみ・自動処理経路に載らない・発火競合なし・影響が局所 | 通常の checkonly 先行＋確認ゲート |
| **中** | 管理対象への拡張だが自動処理非依存／局所的な発火競合の恐れ | 着手前 retrieve バックアップ＋checkonly＋ユーザー確認 |
| **高** | 自動処理経路に載る／置換型（全置換）／共有ルール・OWD／下流依存項目の非表示 | 上記＋承認提示（影響一覧・差分・縮小＝downgrade 警告）＋ドリフト監視必須（§安全弁7）。**まず §疎結合設計原則 に照らして代替案を提示し既定にする** |
| **却下** | 管理本体の改変・回復不能な破壊 | 実行しない（拡張での代替を設計する） |

> 二層で扱う（`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 を使う。
   ```bash
   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 を保持する。
   ```bash
   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**。
     ```bash
     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`。

## 参照

| ファイル | 内容 |
|---|---|
| `references/metadata-type-recipes.md` | 種別ごとのオーサリング手順と確定した癖（対象メタデータ 14 型のうちカスタムオブジェクトはカスタム項目と同型のため節を持たない）＋**PSA/IMAのコンポーネントへ購読側からできること**（ラベル・項目セット・レコードタイプ・同梱接続設定）＋**集計に載らない金額を載せる3層の切り分け**（前提スイッチ／マスタの予備枠／源泉の追加）＋**使わなくなった項目を廃止する**（消さずに見えなくする段階A／参照を切る段階B・自分の項目と提供元の項目で打てる手が変わる） |
| `references/report-description.md` | レポートの説明文（description）の型＝5要素と優先順位・**開き方は例外がないときも1文書く**・255文字上限での落とし方・レポート定義から機械的に取る場所・説明文の不備を検知する3パターン |
| `references/sharing-model.md` | 共有モデル設定（SharingRules／OWD）＝アドバイザリー専用・衝突検知つき追記 |
| `references/customization-design-doc.md` | カスタマイズ設計書（現状の可視化）・カスタマイズ仕様書（指示記入式）の出力フォーマットと継続修正サイクル（カスタマイズのブラックボックス化解消） |

## 関連スキル

| スキル | 役割 |
|---|---|
| `deploying-metadata` | デプロイ順序・dry-run/quick deploy・scratch/sandbox 管理・失敗パターン |
| `generating-custom-field` | カスタム項目メタデータのオーサリング詳細 |
| `generating-custom-object` | カスタムオブジェクトのオーサリング詳細 |
| `generating-apex` | Apex トリガー＋テストクラスのオーサリング |

> 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 整合ルールを定義。