Vendure Drift 運用 Runbook¶

この文書の役割¶

この runbook は、staging / production で Vendure の drift が疑われるときの初動・判断・復旧に絞った運用手順です。

この文書で扱う drift:

custom field の schema drift
Vendure core table / translation table の欠落
Vendure core join table の欠落
migration history drift
required baseline / policy seed / commercial rule の drift

次の内容は別文書を正とします。

migration の作成・レビュー・適用手順: Vendure Migration Runbook
custom field 追加時の設計指針: Vendure Development Guide
deploy 全体フロー: Deployment Guide

最初の判断表¶

症状	まず確認すること	次の標準アクション
staging / production の起動失敗、Sentry の `SchemaDrift` アラート	対象環境を特定し、`just vendure-drift-audit <env>` を実行	監査結果に応じて `sync` または migration 作成
`/health/ready` で `schemaDrift=fail`	readiness の出力と `just vendure-drift-audit <env>`	既存 migration で直るなら `sync`
PR CI で「custom field に対応する migration がない」	CI ログ	migration を追加し、ローカルで `migrate:run`
local 開発中に drift 警告	起動ログ	`pnpm exec nx run ritsubi-vendure-server:migrate:run`
React Dashboard の商品一覧が空、または GraphQL `products` だけ失敗	`featuredAsset` や `optionGroups` を含む Admin API query と core table / join table の有無	core schema drift とみなし targeted repair / migration

検知レイヤー¶

1. local 開発¶

development / test では、起動時 drift は既定で 警告ログのみ です。
local でも fail-fast にしたい場合は VENDURE_FAIL_ON_SCHEMA_DRIFT=true を使います。
まず使う復旧コマンドは pnpm exec nx run ritsubi-vendure-server:migrate:run です。

2. 起動時チェック¶

production / staging では drift 検知時に 起動を中断 します。
起動時チェックは custom field 列だけでなく、core translation table や core join table の欠落も runtime drift として扱います。
2026-04-15 以降の structural drift 監査は、Vendure / TypeORM の entity metadata から core table / translation table / join table の期待列を自動抽出します。
さらに 2026-04-15 以降は startup 時に Dashboard Admin API canary も実行し、featuredAsset / productVariants / customers / orders の relation 解決が失敗する machine は /health が 503 のまま traffic に乗りません。
典型的には Sentry と deploy / release のログで最初に気づきます。

3. readiness probe¶

GET /health/ready に schemaDrift が含まれます。
ここで見えるのは 起動時チェック結果の要約 です。
2026-04-15 以降は missingCount だけでなく issueCount / mismatchedCount / unexpectedCount も返します。deploy / canary 側の gate は issueCount を正本にしてください。

4. PR CI ガード¶

scripts/ci/vendure-data-guards.mjs が custom field 追加と migration の対応を確認します。
migration ファイルの品質チェックも同時に行います。

5. 環境監査 / 同期¶

just vendure-drift-audit staging|production で remote DB の drift を監査します。
just vendure-drift-sync staging で migration / baseline repair / cleanup をまとめて再同期します。 production の一括 sync は test customer / policy / commercial fixture 系上書きを防ぐため禁止です。
Fly release phase は 2026-04-15 以降、migration の直後に additive-only な structural repair も実行し、missing relation / join table を起動前に補修します。
structural repair の責務範囲 (2026-05-20 以降): 真の drift 判定の SSoT は detectRuntimeDrift (just vendure-drift-audit) であり、 structural repair はそこで救えない明示的補修 MANUAL_STRUCTURAL_REPAIR_QUERIES (apps/vendure-server/src/migration/safe-structural-repair.ts) だけを実行します。以前は TypeORM createSchemaBuilder().log() の upQueries も merge していましたが、これは entity と DB の cosmetic 差分 (例: ritsubi_consent_template.id を migration 1767955481928 で int serial 化したが entity が uuid 継承のまま) を「再構築すべき」と提案し続け、PK / FK の "already exists" noise を毎回 deploy 時に量産していたため、merge から外しました。新規 drift は detectRuntimeDrift が捕捉し、必要なら専用 migration を追加します。
vendure-drift-monitor.yml は定期監査を行い、workflow_dispatch で手動 audit / sync もできます。
標準 deploy workflow (_deploy-vendure-fly.yml) は deploy 後に drift audit と post-deploy-check.sh を実行します。sync が必要な場合は dedicated drift 導線で明示実行します。
Pre-deploy drift audit (2026-05-20 以降): _deploy-vendure-fly.yml は image build / push の前に target env の vendure-environment-drift.sh audit を必須実行し、drift があれば deploy を中止します。 schema / migration / structural drift は起動しても正常処理できない可能性があるため deploy 前に止めます。一方、required baseline / catalog / policy / commercial rule のような業務マスタ drift は Vendure 起動条件にしません。これらは起動停止で解決できず、service downtime を悪化させるため、structured log / Sentry / diagnostics で観測し、起動後に修復します。 emergency bypass は skip_pre_deploy_drift_audit: true を input に指定します。 just manual-deploy-vendure も同じ pre-deploy audit を実装しており、skip_drift_audit="true" で bypass できます。 drift がある場合の解消手順は次節「障害対応フロー」を参照してください。

正規コマンド¶

目的	推奨コマンド	備考
local で migration を適用	`pnpm exec nx run ritsubi-vendure-server:migrate:run`	開発時の基本導線
local で drift を fail-fast	`VENDURE_FAIL_ON_SCHEMA_DRIFT=true just vendure`	既定では警告継続
staging / production の admin API smoke	`just dashboard-admin-api-smoke staging` / `production`	Dashboard 依存 Admin API の auth / list / upload の最短確認
staging / production を監査	`just vendure-drift-audit staging` / `production`	読み取り中心の確認
staging / production を診断	`just vendure-diagnose-dashboard-products staging` / `production`	Dashboard 商品一覧の最短切り分け
migration だけ適用	`just vendure-drift-migrate staging` / `production`	影響を migration に限定したい場合
structural repair だけ適用	`just vendure-drift-repair-structural staging` / `production`	core / structural schema repair 向け
baseline repair だけ再同期	`just vendure-drift-sync-baseline staging`	baseline / policy / commercial rule の audit-driven 直列 sync。production は禁止
staging を再同期	`just vendure-drift-sync staging`	migration + baseline repair + cleanup の full sync。production は禁止
release contract を再実行	`just migrate-fly staging` / `production`	deploy 導線に沿った migration + structural repair

node dist/src/index.js migration は Fly の release command や詳細調査で使う実装寄りの導線です。日常運用では just レシピを優先してください。

どのコマンドを打つか迷ったら: audit の `▶ 推奨対応` を正本にする¶

2026-06-09 以降、just vendure-drift-audit <env> （および pre-deploy audit）は drift 検出時に、検出された repairPlan を環境制約込みで実行順のコマンド列に翻訳した処方ブロックを出力末尾に出します。

▶ 推奨対応 (production / この順で実行):
1. just vendure-drift-migrate production
     # missing expected migrations: 1780100500000_add_x
2. just vendure-drift-repair-structural production
     # structural columns missing: product.customFieldsFoo
✓ 自動解消・対応不要 (release-phase migration で解消):
- structuralSchema: ...

表示された順にそのまま実行してください。schema 系 (migrate → structural) を先に揃えてから data 系を直す順序になっています。
⚠ <layer>: 自動修復不可 と出た行は、その環境に自動 recipe が無い項目です（下記参照）。コメントの手順に従って手動対応します。
✓ 自動解消・対応不要 の項目は、release-phase migration が直後に解消するため deploy をそのまま進めて構いません（--allow-pending-migrations 経由の deploy）。
issue は出たが ▶ 推奨対応 が空で ℹ ...自動修復 recipe はありません と出た場合は、 config から外した custom field の残存列など benign な additive drift です。業務影響が無いことを確認のうえ放置可、必要なら専用 migration で DROP します。
--format json には同じ内容が remediation 配列として載るため、AI / 自動化が機械的に消費できます。

production の `requiredBaseline` drift には自動修復経路がない¶

requiredBaseline（country / zone / facet / tax / payment / shipping / channel の seed 期待値）の repair に使う seed-required-baseline は assertNotProduction で production 実行が禁止されています。したがって production で baseline drift が出た場合、vendure-drift-sync-baseline / vendure-drift-sync は使えません（recipe 自体が production 禁止）。

requiredBaseline drift は production 起動を止める条件ではありません。production DB で業務マスタが不足していても、起動停止では不足データは直らず、顧客影響だけが増えます。 runtime drift detection はこの種の drift を non-blocking operational drift として log / Sentry / /health/ready payload / just diagnostics に残し、service は起動継続します。

production baseline drift の標準対応:

backup を取得（just backup-postgres-production）。
drift の原因（多くは Vendure Dashboard 上で facet 値名・必須 policy 等を編集したこと）を特定し、Dashboard 側を期待値に戻すか、期待値の方をコードへ反映して migration / seed 定義を更新する。
seed 定義側を変えた場合は staging で just vendure-drift-sync-baseline staging で検証してから、production へは新コード deploy 経由で反映する。

staging では just vendure-drift-sync-baseline staging が baseline / policy / commercial rule をまとめて再同期します。

最短診断フロー¶

React Dashboard の商品一覧が空だが Sentry に何も出ていない場合¶

この症状は「商品が 0 件」ではなく、GraphQL が HTTP 200 + errors で失敗しているだけのことがあります。Sentry に event が無くても、まず次を短く確認します。

Admin API へ products を featuredAsset なし で投げる
ここで totalItems > 0 なら商品データ自体は存在する。
同じ query を featuredAsset { id preview } 付き で投げる
relation "asset_translation" does not exist が返れば、asset_translation 欠落が直接原因。
just dashboard-admin-api-smoke <env> を実行する
products / productVariants / customers / orders の read-only contract をまとめて確認できる。
failure 時は just dashboard-smoke-postdeploy <env> と just vendure-diagnose-dashboard-products <env> へそのまま進める。
just vendure-drift-audit <env> を実行する
2026-04-15 以降の audit は metadata 駆動で core translation / join table を自動検出するため、asset_translation や shared option group join table のような欠落も個別列挙なしで structural drift として検出する。
DB で translation table を最短確認する

SELECT table_name
FROM information_schema.tables
WHERE table_schema = 'public'
  AND table_name IN (
    'asset_translation',
    'product_translation',
    'collection_translation',
    'facet_translation',
    'facet_value_translation'
  )
ORDER BY table_name;

判断の要点¶

pnpm run migrate:production が No pending migrations でも、migration history が最新なだけで core schema が完全とは限らない。
React Dashboard の商品一覧不具合では、products query 本体より featuredAsset 解決を疑う方が早い。
optionGroups / options を読む query が relation "... does not exist" で落ちる場合は、 shared option group 用の core join table 欠落を最優先で疑う。
この系統は Sentry 未記録でも起こりうる。GraphQL errors を network response で直接見る。

障害対応フロー¶

A. staging / production で drift が疑われる場合¶

対象環境を決め、まず監査します。

just dashboard-admin-api-smoke production
just dashboard-admin-api-smoke staging
just vendure-diagnose-dashboard-products production
just vendure-drift-audit staging
just vendure-drift-audit production

監査結果を以下の観点で判断します。

監査結果	標準対応
`schema drift` / `structural schema drift` が出ており、対応 migration が repo に存在する	staging は `just vendure-drift-sync staging`、production は `just vendure-drift-migrate production` または targeted repair
`migration history table` / visibility rule drift / policy drift / commercial rule drift	staging は `just vendure-drift-sync staging`、production は対象を絞った repair / 手動補正
対応 migration 自体が repo に存在しない	migration を作成し、ローカル検証後に deploy

例外: - 影響が core table 1 個の欠落に限定され、原因がほぼ確定している場合（例: asset_translation 欠落で Dashboard featuredAsset だけ失敗）は、sync を即実行せず targeted repair / targeted migration を優先してよい。 - 理由: production で fixture 系 sync を許すと required baseline / policy / commercial rule に加え、 test customer の refresh が運用データを上書きし得るため。

既存 migration / seed の再同期で復旧できる場合は実行します。

just vendure-drift-migrate staging
just vendure-drift-repair-structural staging
just vendure-drift-sync-baseline staging
just vendure-drift-sync staging

just vendure-drift-migrate production
just vendure-drift-repair-structural production

vendure-drift-sync / vendure-drift-sync-baseline は shared env で policy / commercial-rule / test-customers の fixture seed repair を流さないようにしています。policy / commercial-rule の drift は seed repair を再実行せず、対象を絞った SQL / repair script か seed 定義の見直しで対応します。

ローカルや対象環境で原因が限定できている場合は、統合 sync ではなく targeted repair を優先して構いません。

pnpm exec nx run ritsubi-vendure-server:drift:repair:catalog
pnpm exec nx run ritsubi-vendure-server:drift:repair:required-baseline
pnpm exec nx run ritsubi-vendure-server:drift:repair:test-customers

重要: - DB を書き換える repair target は 並列実行しない でください。tsx の IPC pipe 競合や、baseline 未整備のまま policy/commercial を流す順序依存で false failure を起こします。 - 手動で個別 repair を打つときの staging 標準順序は catalog -> required-baseline -> test-customers です。policy / commercial は seed repair を実行しません。 - staging で迷う場合は individual repair を並べるのではなく、just vendure-drift-sync staging または pnpm exec nx run ritsubi-vendure-server:drift:sync を正本にしてください。production では一括 sync を使わず対象限定 repair にしてください。 - drift:repair:required-baseline は JP / Japan / product-label facet / tax / payment methods / default channel defaults の repair です。policy / commercial の drift は manual 対応に分離します。

復旧後は次を確認します。
just vendure-drift-audit <env> が pass する
/health/ready が正常に返る
deploy workflow を使った場合は drift audit と post-deploy-check が成功する
sync 後も fail する場合は、同じコマンドを繰り返さず、migration 不足または手動 drift を疑って migration 作成フローに切り替えます。

B. migration が repo にない場合¶

Vendure Migration Runbook に従って migration を作成します。
ローカルで検証します。

pnpm exec nx run ritsubi-vendure-server:migrate:run

変更を含めて deploy し、対象環境で再度 audit します。

C. PR CI で migration 不足を指摘された場合¶

CI エラーの対象 custom field を確認します。
対応 migration を追加します。
ローカルで migrate:run を通してから push します。

このケースでは、staging / production を触る前に repo の migration 定義を正しくする のが先です。

D. local 開発中の drift¶

まず local DB に migration を適用します。

pnpm exec nx run ritsubi-vendure-server:migrate:run

早めに気づきたい場合だけ、起動時に次を付けます。

VENDURE_FAIL_ON_SCHEMA_DRIFT=true just vendure

local schema を大きく作り直す必要がある場合は、migration runbook 側の reset / 初期化手順を参照してください。

監査と同期で何を見ているか¶

`vendure-drift-audit`¶

次をまとめて確認します。

custom field schema drift（missing / mismatched / unexpected）
metadata から自動抽出した core table / translation table / join table を含む structural schema drift
migration history table (vendure_migrations を正本とし、legacy migrations も互換吸収。row 数だけでなく applied / missing / unknown 名集合も監査）
required baseline / visibility rule / policy / commercial rule の不足
policy payload の空化や不整合

`vendure-drift-sync`¶

次を順番に実行します。

obsolete ACL schema の置換
migration 適用
structural schema repair
required baseline / policy sets / commercial rules の再同期
最後に drift audit を再実行

[!CAUTION] vendure-drift-sync production / vendure-drift-sync-baseline production は廃止しました。これらは migration だけでなく required baseline・visibility policy・commercial rule・test customer refresh を含み、production を fixture 側へ上書きし得るためです。症状が局所的な core schema 欠落なら vendure-drift-migrate production / vendure-drift-repair-structural production を使い、データ復旧は backup 後に対象を絞って実行してください。

既知のトラブル¶

required-baseline / policy drift を起動条件にして Vendure が起動しない¶

症状: deploy 後に Vendure が Runtime drift detected: required baseline drift: ... や policy drift: ... を出し、起動を中止します: production/staging 環境で destructive drift として process exit する。Fly では machine が restart loop し、/health/ready が 503 / timeout になる。Storefront / React Dashboard から Vendure API へ到達できず、 service downtime が拡大する。

原因: required baseline / catalog / policy / commercial rule は業務マスタ drift であり、 schema 破壊ではない。これを startup fail-closed に分類すると、不足データの修復には寄与せず、 deploy 復旧時に全リクエストを止めるだけになる。特に facet value / collection / policy seed は運用で意図的に削除されることがあり、seed 定義に残っていると repair / drift sync で復活し、次回起動時にまた不足扱いになる。

正しい扱い:

起動を止める: DB 接続不可、schema / structural column drift、missing expected migration、必須 secret 不足など、起動しても正常処理できないもの。
起動を止めない: required baseline、catalog、policy、commercial rule、default channel、 stock level、SMILE export settings、email partial template などの業務 baseline drift。
起動を止めない: drift check 自体の optional query / 業務監査 query の実装不備。DB 接続断 (ECONNREFUSED / ENOTFOUND / authentication failure 等) は起動停止対象だが、監査機能の不具合だけで commerce service を止めない。
non-blocking drift は structured log / Sentry / diagnostics に残し、起動後に targeted repair またはコード側の seed 定義見直しで解消する。

対処:

just env-status production --format json または just vendure-drift-audit production で drift の layer を確認する。
requiredBaseline / policySets / commercialRules だけなら rollback より起動継続を優先する。起動停止している場合は、runtime drift classification が業務 drift を startup blocker に誤分類していないか確認する。
意図的に削除した master が復活する場合は DB だけを消さず、以下の復活元からも外す。
apps/vendure-server/src/data/seeders/required-baseline.ts
apps/vendure-server/src/data/initial-data.ts
apps/vendure-server/src/data/seeders/policies.ts
production DB に残った不要 master は、参照関係を確認したうえで targeted SQL / repair script で削除する。一括 vendure-drift-sync は production では使わない。

`@vendure/cli migrate --generate` が `Paths must either both be absolute or both be relative` で落ちる¶

症状: pnpm migrate:generate (= pnpm exec tsx scripts/run-vendure-cli.ts migrate --generate ...) が ■ Analyzing project の段階で TypeScript 内部の Debug Failure: Paths must either both be absolute or both be relative を投げて止まる。

原因: @vendure/cli@3.6.3 が内部で使う ts-morph が、apps/vendure-server/tsconfig.json の paths + moduleResolution: "nodenext" の組み合わせ、および CLI が強制注入する compilerOptions.rootDir: './src'（相対パス）と絶対 tsConfigFilePath を比較する箇所で失敗する。TypeScript 6 + ts-morph 21 の組み合わせで顕在化する Vendure CLI 側の互換問題。

現状: pnpm migrate:generate（migrate:generate target）は CLI の analyzeProject を経由せず @vendure/core の generateMigration() を直接呼ぶ apps/vendure-server/scripts/generate-reviewed-migration.ts に置き換わっており、この CLI / ts-morph 問題は踏まない。さらに runner は tsx ではなく ts-node（scripts/run-local-ts-source.sh）に統一している。tsx(esbuild) は TypeORM entity の decorator metadata を emit できず、entity import 時に Reflect.getMetadata の TypeError で必ず失敗するためである。

drift 検出だけしたい場合: review / timestamp 正規化を伴わない薄いラッパー apps/vendure-server/scripts/generate-migration-direct.ts を、同じ ts-node runner で実行する（entity を読むため tsx 不可）。

DATABASE_URL=postgres://vendure:vendure_dev_password@localhost:5433/vendure_dev \
  pnpm -C apps/vendure-server exec bash ./scripts/run-local-ts-source.sh scripts/generate-migration-direct.ts drift_check

出力先は apps/vendure-server/src/migrations/<timestamp>-<name>.ts。
No schema drift detected. と出れば DB と Vendure entity 宣言は一致している。
DB port は docker port ritsubi-postgres-dev で確認。.env の DATABASE_URL が 5432 を指していても、ホスト側マップが 5433 のことがある。

用途は drift 検出に限定: AGENTS.md / vendure-migration-runbook.md のとおり migration は手書きが原則。このスクリプトは「現在の DB が entity と一致しているか」を読み取るための診断ツールとして使い、生成された migration を直接 commit しない。

Vendure Dashboard の Collection contents preview に更新が反映されない¶

症状: Collection 詳細で facet filter を編集・保存しても、contents プレビューに反映されない / 反映までラグがある。リロードすると正しい内容が出ることがある。

よくある誤診: 「Vendure を 3.6.x にアップグレードしたが migration を追加していないので index が欠けて遅い／プレビューが詰まっているのでは？」と疑いがち。generate-migration-direct.ts で drift check したところ Vendure core 側の schema drift は 0 件で、3.6.3 entity 宣言と DB は一致していた（2026-05-20 時点）。schema 起因ではない。

実際の候補:

Dashboard の React 側で filter args（containsAny 等）の boolean state が初回レンダリングで undefined のまま描画され、リロードで再描画される（前述「Vendure Dashboard の checkbox 表示が初回ロードで反転して見えることがある」と同じ系統）。
previewCollectionVariants の GraphQL query が古い variables のままキャッシュされ、保存後の refetch が走っていない。
Collection の filter 自体は保存できているが、applyCollectionFilters job が非同期に走るため、materialize 済みの collection_product_variants_product_variant が一時的に古いまま見えている（ただし preview は materialize を使わないので通常は当てはまらない）。

切り分け:

DevTools Network タブで保存後に previewCollectionVariants mutation/query が再送信されているか確認。
再送信されていない → Dashboard 側のキャッシュ・再 fetch トリガー不足（Vendure Dashboard 側のバグ）。
再送信されているのに古い → server 側の応答内容を確認。

運用: 当面は「保存後に Dashboard をリロード」で実害なし。schema/index 起因と決めつけて migration を書かない。

対応状況: 自前 plugin CollectionContentsSyncPlugin（packages/plugins/src/standard-extensions/collection-contents-sync/）で対処済み。EventBus.registerBlockingEventHandler を使い、Collection の filter を変更する updateCollection / createCollection mutation を、worker が CollectionModificationEvent を publish するまで return しないようブロックする。これにより Dashboard 側の onSuccess → startPolling → invalidate 時点で materialize は完了済みになり、<ContentsTable> への切替えで正しい contents が表示される。15s で timeout（log のみ、mutation 自体は成功扱い）。詳細は issue #685。

参考: facetValueCollectionFilter の SQL 構造と containsAny の意味は Vendure Development Guide を参照。

予防¶

Vendure upgrade や relation 追加時は、migration 追加だけで完了扱いにせず metadata 駆動の structural drift test と runbook を同時更新する。
deploy / release 導線では drift:audit -- --fail-on-drift を readiness contract と同じ重みで扱い、GraphQL smoke より先に通す。
local でも GraphQL error の再発を早く見つけたい作業では VENDURE_FAIL_ON_SCHEMA_DRIFT=true just vendure を使い、起動直後に fail-fast させる。
custom field や seed を変えるときは、必ず対応 migration を repo に含める
PR 前に local で migrate:run を通す
migration 作成・レビューは Vendure Migration Runbook を使う
設計判断は Vendure Development Guide を参照する

Legacy 残骸の retention¶

過去の機能移行に伴って残している「判定経路から外したが、DB / コードベースに意図的に残している artifact」の保持方針を、削除判断ができる粒度でここに集約する。判定には影響しないが、棚卸し対象として vendure-drift-audit が検出する。

Payment policy → `PaymentMethodCollectionAssignment` (PMCA) 移行の残骸¶

対象 prefix:
OBSOLETE_COLLECTION_METHOD_GROUP_PREFIX = [決済ポリシー：回収方法] （実 DB に残る legacy 名の正本。migration 1779800400000 / 1779804500000 が DELETE 対象とする pattern と一致）
OBSOLETE_POLICY_SEED_NAME_PREFIX = [seed]（旧 payment policy seeds）
旧 [policy:payment:collectionMethod] 英語形は実 DB に一度も生成されていない死定数だったため、定数ごと撤去済み。日本語 prefix 単体で LIKE する。
定義箇所: apps/vendure-server/src/data/seeders/policies.ts
検出箇所: apps/vendure-server/src/observability/runtime-drift.service.ts の loadObsoleteSeedArtifacts が policy_entity / resource_set_entity / subject_set_entity / customer_group から該当行をスキャンし、drift report の obsoleteNamedArtifacts に出す。
移行 migration:
apps/vendure-server/src/migrations/1779800400000_migrate_payment_policies_to_collection_assignments.ts
apps/vendure-server/src/migrations/1779804500000_repair_payment_collection_assignments_for_legacy_entity_tables.ts
保持方針:
現コードからは参照されず、判定経路にも影響しない。
撤去判断基準: production / staging の drift report で obsoleteNamedArtifacts が 2 リリースサイクル連続で 0 件であることを観測できたら、prefix 定数と検出ロジックを削除してよい。
撤去想定時期 marker: 2026-08-01 以降のリリースで判断（その時点で 2026-05-22 の PMCA 移行から 2 リリースサイクル相当が経過している想定）。実 release 番号は判断時に確認する。
それまでは drift detection 用に保持。手動削除は migration から行い、SQL の直叩きで消さない。
撤去手順（基準を満たしたら順番に実施）:
apps/vendure-server/src/data/seeders/policies.ts の OBSOLETE_POLICY_SEED_NAME_PREFIX / OBSOLETE_COLLECTION_METHOD_GROUP_PREFIX 定数を削除する。
apps/vendure-server/src/observability/runtime-drift.service.ts の loadObsoleteSeedArtifacts 内 LIKE 句から該当 prefix を削除する。
vendure-environment-drift.sh 系の repair plan / report key から obsoleteNamedArtifacts 系のキーを削除する（既に部分的に sunset 済みの周辺コードを参考にする）。
pnpm exec nx run ritsubi-vendure-server:typecheck と just vendure-drift-audit staging を実行し、drift report に該当行が出ないことを確認する。
削除を検討する判断材料:
just env-status <env> または drift report で obsoleteNamedArtifacts の件数が 0 になっているか
旧 group / 旧対象者条件を参照する未削除のコードが grep で 0 件か (rg "OBSOLETE_COLLECTION_METHOD_GROUP_PREFIX|決済ポリシー：回収方法"。 _JA suffix 付きの旧定数は 2026-05 で撤去済みなので grep 対象外)