risky-changes

リスクの高い変更

あるフィルターはすべてのテストに合格したものの、本番データでは機能の約99％を無効化していました。テストではコードが正しく動作するかを確認します。調査と本番での測定では、変更が有用かどうかを確認します。

このプロセスを適用するケース

誤りの影響が大きい、または顧客の目に触れる変更に適用してください。

• 公開 API のフィールド、フィルター、レスポンスの整形
• 上流データの破棄、変換、並べ替え
• 請求、価格設定、上限、クォータ
• デフォルト値、しきい値、プロバイダーへのリクエストパラメーター
• 外部データやユーザーの行動に関する、未検証の想定

該当するか判断に迷う場合は、このプロセスを適用してください。

1. 想定を特定する

変更が依存する想定を列挙します。根拠があるものと、まだ検証されていないものを明記してください。

2. 実装前に調査する

利用可能な調査ツールと信頼できる情報源を活用します。それぞれの疑問を個別に調べ、少なくとも次の点を確認してください。

• 有力な製品では、この設計上の判断をどのように扱っていますか？
• 実際のデータはどのようなものですか？頻度、形状、エッジケースを確認します。
• ユーザーやエージェントは、実際に何を必要としていますか？

証拠が想定と矛盾する場合は、コーディングの前に設計を見直してください。調査できない場合や結論が出ない場合は、その不足を明記し、想定を検証済みとして扱わないでください。重要な想定が未検証のままリリースしてはいけません。

3. 実際の動作を測定する

実際のエンドポイントまたはプロバイダーに対して、現実的なケースを10～20件以上実行します。

• 実際の利用状況をもとにケースを作成し、トピック、パラメーター、言語、境界条件を変えます。
• 各ケースについて、速度、品質、精度、新しい動作が発生する頻度のベンチマークを定義します。
• 可能な限り具体的な数値を使います。主観的な品質については、基準に基づくブラインド評価を行います。
• 変更前と変更後の両方を測定できる場合は、比較します。
• 本番環境の読み取り専用分析も測定に含まれます。

ケースと結果をプロジェクトの evals フォルダーに保存してください。例：docs/evals/YYYY-MM-DD-<endpoint>-<focus>.md。必要に応じてフォルダーを作成してください。この記録がなければ、変更は検証済みとは言えません。ユニットテストで本番測定を代替することはできません。

4. リリース前にプロダクトオーナーの承認を得る

顧客に表示される内容や顧客が支払う金額に影響する判断は、裏付けとなる調査結果や測定結果とともに提示してください。そのような判断について、プロダクトオーナーの承認を得てください。計画やコードのデフォルト設定に埋もれさせてはいけません。リリースする動作を実際に対象としている既存の承認は有効です。

5. デプロイ後に検証する

1日以内に、読み取り専用の本番分析またはライブスイープを通じて、実際のトラフィック上で変更を測定してください。期待と異なる結果があれば、直ちに報告してください。