旧バージョン互換ポリシー（強制アップデートの線引き）

背景与问题

OPC（B 方向）。シニア層はアプリを更新しない（c-senior-tablet-trend・japan-phone-charge-ritual の前提）——旧バージョンのクライアントがどれだけ残るかを想定した互換ポリシーがないと、サーバ側の変更で古いアプリが静かに壊れる。方針を 3 行に固定する。

发现

（出典はいずれも 2026-09-17 アクセス）

• 強制アップデートは API versioning でなくポリシー決定：一部または全部の機能を更新まで制限する運用判断（Medium の versioning 戦略論）。
• バックエンドは旧クライアントを壊さない（後方互換 first）が原則。壊す変更は既存エンドポイントに潜ませず新規で足す（Stack Overflow の実務議論、Zuplo）。
• 強制更新は version-check エンドポイントでゲートするのが定石（同 Medium）。
• 実務テクニック：リリース前に旧本番 build × 新 staging backend を走らせ、互換壊れを先に検出する（Stackademic）。
• 非互換の廃止は期間を明示してから行う（deprecation policy の定石、複数出典一致）。

结论

1. 方針 3 行を runbook に固定：①サーバは旧クライアントの既存エンドポイントを壊さない ②破壊的変更は新エンドポイント追加で ③強制更新は version-check ゲートのポリシー判断であり、重要修正（セキュリティ・課金不具合）のみ発動。
2. リリース前チェックに「旧 build × 新 backend」の 1 組を追加：サポート対象の最旧バージョンを staging で走らせる（実費 5 分、opc-release-precheck-5min に 1 項目）。
3. サポート window を数値化：最新版から 2 バージョン前まで best effort、それ以前はゲートで案内。数値は年 1 回（opc-year-end-checklist）で見直し、実ユーザーの version 分布（opc-test-device-lab の analytics）で裏取りする。
4. シニア層は更新しない前提なので強制更新の発動は最小に：ゲート時の文言は「何が直るか」を大文字 1 行で伝える設計（推测：恐怖より利益提示）。

待办 / 下次继续

• version-check エンドポイントの現状確認（未実装なら最小実装の設計メモ）。
  
• サポート最旧バージョンの実値を analytics で確認。
  

关联

c-senior-tablet-trend japan-phone-charge-ritual opc-release-precheck-5min opc-test-device-lab opc-year-end-checklist