プロンプトとスコープ
貴社のSaaSには多くのB2B API顧客が存在します。チームは2026年6月のIETFインターネットドラフト「A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs」を採用し、個別のリクエストまたはレスポンスメンバーに対する非推奨日（deprecation date）、サンセット日（sunset date）、および代替項目を記述するために application/deprecations+json を公開したいと考えています。これをプロダクト機能として実装すべきかを判断し、スコープ、顧客価値、互換性、ロールアウト、および成功指標を説明してください。なお、このドラフトは現在策定中であり、最終的なRFCではありません。
面接官がテストしているポイント
- プロトコル機能を顧客の課題、移行ワークフロー、およびビジネス価値に変換できるか。
- リソースレベルのレスポンスヘッダー（RFC 9745、RFC 8594）とフィールドレベルのマニフェストを区別できるか。
- 標準が未完成である期間において、コミットメント、互換性、およびガバナンスを管理できるか。
- 導入率、移行完了、および誤検知（false positive）に関する観測可能な指標を選択できるか。
回答前に明確にすべき質問
- 顧客は主にSDK、OpenAPIジェネレーター、直接のJSONパースのどれを使用していますか？
- 既に非推奨通知、バージョンポリシー、および担当者への通知メカニズムは存在しますか？
- 非推奨となるメンバーはレスポンスフィールドのみですか、それともリクエストフィールド、ネストされた配列、ポリモーフィックな構造も含まれますか？
- 目的は手動での移行支援ですか、それともCI/CDやSDKがリスクを自動的にブロックできるようにすることですか？
- 古いメンバーの提供維持を必要とする顧客、地域、またはコンプライアンス要件はどれで、その期間はどのくらいですか？
30秒の回答フレームワーク
課題から始めます。顧客はメンバーレベルの変更を発見するのに苦労しており、リソースレベルの Deprecation/Sunset ヘッダーでは個々のメンバーを特定できません。私の提案は、ドラフトを確定した標準として提示することなく、限定的かつオプトイン形式でフィールドレベルのライフサイクルシグナルのパイロットを実施することです。レスポンスメンバー、マニフェスト、ドキュメントへのリンク、代替フィールドから開始し、OpenAPI、アナウンス、リソースレベルヘッダーも維持します。発見率、移行期間、誤検知率、およびロールバック率を基に、拡張するかどうかを判断します。
ステップごとの詳細解説
1. 顧客のペインと境界を定義する
非推奨となったメンバーもしばらくの間レスポンスに残り続けることがよくあります。顧客はどのメンバーが影響を受けるのか、いつ非推奨が始まるのか、いつ削除が予定されているのか、そして何が代替となるのかを知る必要があります。マニフェストは発見とオーケストレーションに対処するものであり、現在の動作を変更するものではなく、バージョンポリシー、コントラクトテスト、または人によるコミュニケーションを代替することはできません。
2. 既存機能との関係を説明する
リソースレベルのヘッダーが引き続きデフォルトのチャネルとなります。フィールドレベルのマニフェストは Link を使用して検出できます。
Link: </.well-known/deprecations>; rel="deprecation"; type="application/deprecations+json"マニフェストの例：
{
"deprecations": [
{
"target": "response",
"selector": "$.customer.legacy_name",
"selectorType": "jsonpath",
"deprecation": "2026-09-01",
"sunset": "2027-03-01",
"replacement": "$.customer.display_name",
"info": "https://docs.example.com/migrations/customer-name"
}
]
}プロダクト設計では、フォーマット、発見、およびビジネスガバナンスを分離する必要があります。ドラフトが変更された場合でも、顧客には安定したドキュメントとOpenAPI記述が残ります。
3. 実用最小限の製品（MVP）を選択する
JSONレスポンスメンバー、1つのAPIバージョン、および明示的な日付から開始します。あらゆるJSONPath方言、リクエストボディのバリエーション、GraphQLの形状、バイナリプロトコル、または自動クライアント書き換えを約束してはなりません。マニフェストは読み取り専用かつキャッシュ可能に保ち、ソースドキュメントへのリンクと人による確認経路を用意します。
4. ロールアウトと移行を設計する
変更が登録された後、プラットフォームはマニフェストを生成し、日付の順序関係を検証します。ドキュメント、SDK変更履歴、および顧客通知を同時にリリースします。内部APIおよびデザインパートナーから開始し、その後セルフサービス顧客へと拡大します。バージョン履歴を保持し、誤検知や日付変更に備えてロールバックスイッチを用意します。
5. ガバナンス、リスク管理、および指標を設定する
ガバナンスでは、サンセット前にメンバーのオーナー、最小通知期間、利用可能な代替手段、および例外承認を必須とすべきです。マニフェスト発見率、影響を受ける呼び出しの特定、通知から移行までの期間の中央値、非推奨メンバーを依然として使用している呼び出し、誤検知率、サポートチケット、およびロールバックを追跡します。顧客がマニフェストをパースしない場合は、フォーマットを追加するのではなく、SDK、CLI、またはCIチェックに投資します。
6. 段階的な意思決定を行う
パイロットによって誤検知を抑制しつつ移行時間が大幅に短縮された場合は、リクエストメンバーやネストされた構造へと拡張します。価値が機械的なパースではなく主にドキュメントからもたらされている場合は、マニフェストを高度な機能として据え置き、OpenAPI、通知、およびバージョンポリシーの改善に注力します。外部向けのコミットメントにはすべて、ドラフトのステータスと互換性の保証範囲を明記します。
質の高い回答例
私はこれを構築しますが、確定した標準としてではなく、フィールドレベルのライフサイクルシグナルのパイロットとして位置付けます。顧客は現在でもリソースレベルの Deprecation および Sunset シグナルを受け取ることができますが、これらは特定のレスポンスメンバーを特定するものではありません。マニフェストを提供することで、対象メンバー、日程、代替項目、および移行リンクを自動化ツールに提供できます。
フェーズ1では、1つのJSONレスポンスモデルと、明示的な非推奨日およびサンセット日をサポートします。OpenAPI、ドキュメント、およびリソースレベルのヘッダーは互換性チャネルとして維持します。登録時に、プラットフォームはメンバーのオーナー、代替項目、および最小通知期間を検証します。社内APIおよびデザインパートナーから開始し、発見率、移行期間の中央値、非推奨メンバー呼び出しの割合、誤検知、およびロールバックを測定します。フォーマットは2026年6月のIETFドラフトに基づくため、ドキュメントには変更の可能性がある旨を明記し、機能の無効化またはダウングレード用のスイッチを用意する必要があります。
パイロットによって早期発見とサポートコストの削減が確認できれば、リクエストメンバーやより複雑な構造へと拡張します。顧客がパースではなくドキュメントに依存している場合は、投資先をSDK、CIチェック、および通知のオーケストレーションへとシフトします。成功とは、単にプロトコル名を追加することではなく、予期せぬ機能停止を減らし、移行を迅速化することです。
よくある間違い
- インターネットドラフトを承認済みのRFCと呼んだり、あらゆる環境での即時サポートを約束したりすること。
- 所有権、日付ポリシー、通知、およびロールバックを考慮せず、JSON構文のみを議論すること。
- レスポンスヘッダーが任意のネストされたメンバーを自動的に特定できると思い込むこと。
- パイロット、指標、および停止条件を提示せず、単にYes/Noの判断のみを下すこと。
- リクエストメンバー、配列インデックス、およびポリモーフィックな構造から生じる曖昧さを無視すること。
フォローアップの質問と回答
顧客がマニフェストをパースしない場合はどうしますか？
機械可読な補足情報として維持し、OpenAPI、移行ドキュメント、SDK変更履歴、Webhook、またはメール通知を継続します。強制的に導入させるのではなく、発見率を用いて実際の利用状況を測定します。
ドラフトの変更にはどのように対処しますか？
マニフェストジェネレーターを顧客APIから分離し、フォーマットバージョンを記録し、マニフェストの無効化やドキュメントおよびリソースレベルヘッダーへのフォールバックを可能にし、互換性ノートにドラフトステータスを明記します。
リクエストメンバーはいつサポートしますか？
レスポンスメンバーのパイロットでセレクター、日付、および移行ワークフローの安定性が実証され、リクエストメンバーに明確なバリデーションとロールバックのセマンティクスが確立された後に限られます。そうでない場合、誤検知が書き込みの失敗につながるおそれがあります。
プロダクトの価値をどのように証明しますか？
パイロットグループとコントロールグループを比較し、移行完了時間、非推奨メンバーの呼び出しシェア、サポートチケット、およびロールバック率を測定します。また、パーサーのカバレッジと誤検知も確認します。ドキュメントのページビュー数だけでは移行の成功を証明できません。