レビューリスト（ソースコード）Probe APIレビュー・チェックリスト0. 前提確認 このAPIは「状態を返す」or「その場でProbeを実行する」どちらか（実装/仕様/命名が一致） Startup / Readiness / Liveness の判定基準が混ざっていない（用途ごとに責務が明確）1. API仕様（ソースコード内の仕様書）1-1. ルート/入出力の一貫性 エンドポイント/HTTPメソッドが明記され、実装と一致 ステータスコード設計が明確（例：OK=200、NG=503 など） 成功時レスポンスのフィールド名・型・必須/任意が明確 失敗時レスポンス形式が統一（code/message/traceId など）1-2. 利用者視点の情報 それぞれのProbeが何を意味するか説明がある リクエスト/レスポンス例（成功/失敗）がある 認証要否・公開範囲（内部のみ等）が明記されている1-3. セキュリティ/情報漏えい レスポンスに内部情報（例外スタック、接続先の詳細、秘密情報）が出ない 監視APIが高負荷にならない（重い依存チェックを毎回叩かない等）2. ログ制御（環境変数 boolean）2-1. env設計 env名が一貫（例：PROBE_LOG_STARTUP_ENABLED / READINESS / _LIVENESS_） 未設定時のデフォルトが妥当（基本 false など） 全体ON/OFF＋個別overrideなど、運用のしやすさが考慮されている2-2. booleanパース Boolean(process.env.X) のような誤パースをしていない（"false"がtrueになる） true扱いの値が明確（例："true"/"1"/"yes"のみtrue） 想定外の値は警告 or 起動時に失敗など、方針が決まっている2-3. ログ内容 構造化ログ（probeType/result/durationMs/traceId等）になっていて検索しやすい 機微情報/PIIをログらない（トークン、接続情報、個人情報） 成功時ログの量が運用上許容される（readinessは高頻度になりがち）2-4. 実装の重複 probeごとのif分岐が散らばらず、shouldLog(probeType) 等に集約されている3. 実装品質（共通） タイムアウトがある（外部依存/DB/HTTP等） 並列呼び出し時に安全（共有リソース、キャッシュ、ロックの考慮） 結果が短時間で揺れない工夫（必要ならキャッシュ/連続失敗でNG等） テストがある