連携プロトコル（エージェント連携・認証・RPC 規格など）に破壊的な新リビジョンが出たとき、公表内容の大きさだけで着手を決めない。次の3点を順に確認し、どれかが未成立なら「様子見しつつ将来必須の項目だけ先行対応」に倒す。

判断軸

1. 自実装が使っている機能面が改訂に含まれるか: 廃止・非推奨になる機能を実際に使っているかをコードで確認する。使っていない機能の非推奨は影響ゼロで、リリース記事の「破壊的変更」の総量とは無関係。実装側がすでに新方式（例: 状態を持たない構成）に寄っていれば、見出しが大きい改訂でも実害が出ないことがある。
2. クライアント側に旧リビジョンへのフォールバックがあるか: 規格側が「新クライアントは旧サーバー検出時に旧手順へ退避する」と明記し、それが公式実装に入っているなら、既存サーバーは期限に追われない。逆にフォールバックが規定されていなければ、クライアント更新日が実質の期限になる。
3. 公式SDKが安定版で対応済みか: 対応版が beta / RC 段階なら本番実装は乗せない。安定版が出るまで待ち、旧メジャーのサポート期間（「安定版後 N ヶ月は修正継続」等）を移行猶予として見積もる。

先行対応すべき例外

上記で「様子見」と判断した場合でも、規格文に「今は SHOULD だが将来 MUST に引き上げる予定」と明記された項目は先に潰す。実装コストが小さく、引き上げ時に慌てて対応する方が高くつく。とくに認証・認可まわりの追加パラメータやメタデータのフラグはこの型になりやすい。

落とし穴

• リリース記事やまとめブログの「壊れるもの一覧」は全実装の総和であって、自分の実装の影響範囲ではない。必ず自コードの使用状況と突き合わせる。
• 公式パッケージが分割・改名される改訂では、パッケージレジストリの既定タグがまだ旧メジャーを指していることがある。既定タグだけを見て「まだ対応版がない」と判断せず、新パッケージ名とプレリリースタグの両方を確認する。

確認方法

仕様本文（一次情報）で自分が使っている機能の必須・非推奨・削除の別を確認し、公式SDKのリリースノートで安定版時期と旧メジャーのサポート期間を確認する。その上で、対応が必要な項目・将来必須になる項目・影響なしの項目に三分して記録し、期限のあるものだけを着手対象にする。