AI生成コードベースにおけるセキュリティ、パフォーマンス、信頼性

AI生成コードに期待すべきこと

「AI生成コード」は、チームやツール次第で非常に幅のある意味を持ちます。ある場合は既存モジュール内の数行のオートコンプリートかもしれませんし、別の場合はプロンプトから生成されたエンドポイント全体、データモデル、マイグレーション、テストスタブ、あるいは大規模なリファクタまでありえます。品質を判断する前に、リポジトリ内で何がAI生成に該当するかを書き出してください：スニペット、関数全体、新サービス、インフラコード、あるいは「AI支援」リライトなど。

重要な前提：AIの出力は下書きであり保証ではありません。読みやすくてもエッジケースを見落としたり、ライブラリを誤用したり、認証チェックを抜かしたり、微妙な性能ボトルネックを導入したりします。速いジュニアのチームメンバーからのコードだと考えて扱ってください：有用な加速効果がある一方で、レビュー、テスト、明確な受け入れ基準が必要です。

「vibe-coding」ワークフロー（例：Koder.aiのようなプラットフォームでチャットプロンプトから機能全体を生成する—フロントエンドはReact、バックエンドはGo+PostgreSQL、あるいはFlutterのモバイルアプリなど）を使っている場合、このマインドセットはさらに重要です。生成される範囲が大きくなるほど、「コンパイルする」以外に何をもって“完了”とするかを定義する必要があります。

明確な基準が必要な理由

セキュリティ、パフォーマンス、信頼性は、あなたが求めて検証しないかぎり生成コードに自動的に現れることはありません。AIは尤もらしさや一般的なパターンを最適化する傾向があり、あなたの脅威モデル、トラフィック形状、障害モード、コンプライアンス要件までは考慮しません。明確な基準がないと、チームはハッピーパスのデモでは動くものをマージしてしまい、本番トラフィックや敵対的入力で失敗することがよくあります。

三つの柱（および重なり）

• セキュリティ：誤用を防ぐこと—入力検証、正しい認証/認可、安全なデフォルト、シークレットやデータの慎重な扱い。
• パフォーマンス：想定スケールでの効率—予測可能なレイテンシ、不必要なI/Oの回避、リソース使用の管理。
• 信頼性：時間を通じた正確さ—部分的な障害の処理、リトライ、冪等性、依存が遅い/落ちたときの妥当な振る舞い。

実際にはこれらは重なります。たとえばレート制限はセキュリティと信頼性の両方を改善しますし、キャッシュはパフォーマンスを上げますがユーザー間でデータを漏らすとセキュリティを損ないます。厳格なタイムアウトは信頼性を高めますが、新しいエラーパスを生じさせ、それらも保護する必要があります。

このセクションは基礎的な心構えを設定します：AIはコードを書く速度を上げますが、「本番対応」はあなたが定義し継続的に検証する品質基準です。

生成コードにおける一般的なリスクパターン

AI生成コードは整って自信に満ちた見た目をしがちですが、最も頻繁に問題になるのは様式的な問題ではなく判断の欠如です。モデルはコンパイルし基本テストを通るもっともらしい実装を出すことができますが、あなたのシステムが依存する文脈を静かに見落とすことがあります。

注意すべき典型的なリスク領域

レビューで繰り返し現れるカテゴリ：

• 入力処理：検証の欠如、不安全なパース、クライアント提供のIDを信頼する、SQL/JSON/HTML文字列を直接構築する。
• 認証と認可：「ログイン済み」と「許可されている」を混同する、ロールチェックを省く、あるエンドポイントではチェックしているが他ではしていない。
• エラー処理：内部詳細をエラーメッセージで漏らす、例外を握りつぶす、部分失敗で成功を返す、広範なcatchブロックで問題を隠す。
• 同時実行と状態：レースコンディション、スレッド安全でないキャッシュ、安直なロックによるデッドロック、単一リクエスト実行という誤った前提。

見落とされがちな「知られざる前提」

生成コードは隠れた前提を持つことがあります：常にUTCのタイムゾーン、IDは常に数値、リクエストは常に正しく形成される、ネットワーク呼び出しは常に速い、リトライは常に安全など。また部分実装を含むこともあります—ステブされたセキュリティチェック、TODOパス、失敗時に閉じないフォールバックでデフォルトデータを返すなど。

文脈なしにパターンをコピーする危険

別の場所で正しいパターンを借用してしまい、ここでは不適切になることがあります：ハッシュヘルパーを正しいパラメータで使っていない、出力文脈に合わないジェネリックなサニタイザを適用している、負荷を意図せず増幅するリトライループを採用している等。

所有権は移転しない

コードが生成されたとしても、実行結果の責任は人間に残ります。AIの出力は草案として扱い、脅威モデル、エッジケース、影響については人間が責任を持ってください。

シンプルな脅威モデルから始める

AI生成コードは自信満々に見えるため、「何を守るのか、誰から守るのか？」という基本の問いを飛ばしがちです。短く平易な脅威モデルを習慣にすることで、コードが確定する前にセキュリティ判断を明示できます。

資産、アクター、信頼境界を定義する

まず、漏洩や改ざんが起きたときに害がある資産を名前で挙げます：

• データ：顧客のPII、認証トークン、APIキー、請求情報
• 金銭移動：支払い、返金、クレジット、支払い処理
• 管理アクション：ユーザーのロール変更、フィーチャーフラグ、データエクスポート
• 稼働性：リクエストを提供し続ける能力

次にアクターを列挙します：一般ユーザー、管理者、サポート、外部サービス、攻撃者（クレデンシャルスタッフィング、詐欺師、ボット）

最後に信頼境界を描写します：ブラウザ ↔ バックエンド、バックエンド ↔ データベース、バックエンド ↔ サードパーティAPI、内部サービス ↔ 公開インターネット。AIがこれらの境界を越える「簡易」なショートカット（例：公開エンドポイントからの直接DBアクセス）を提案したら即座にフラグを立ててください。

コーディング前に使えるライトウェイトなチェックリスト

短くて実際に使えることが重要です：

1. この機能で悪意ある利用者ができる最悪のことは何か？
2. どの入力が信頼境界を横切るか（フォーム、Webhook、ヘッダー、ファイル）？
3. 何が認可（特に管理・金銭行為）を必要とするか？
4. 何をログ・アラートするべきか（認証失敗、高価値アクション）？
5. 安全な失敗モードは何か（デフォルトは拒否、レート制限、ロールバック）？

レビュワーが見える場所に決定を記録する

PR説明に回答を残すか、選択が長期的なら簡単なADR（アーキテクチャ決定記録）を作成してください（例：トークン形式、Webhook検証方式）。将来のレビュワーは、AI生成の変更が元の意図に合致しているか、どのリスクが意図的に受け入れられたかを確認できます。

コードレビューのためのセキュリティチェックリスト

AI生成コードは見た目は一貫していても、デフォルト、エラー処理、アクセス制御にセキュリティ上の落とし穴を隠していることがあります。レビュー時には様式より「攻撃者が何をできるか」に焦点を当ててください。

多くの問題を捕まえるクイックチェック

• 安全なデフォルトを確認：deny-by-default、最小権限、露出の最小化
• 入力検証と出力エンコーディングの確認（該当箇所）
• シークレットがハードコーディングされていないか（環境変数／シークレットマネージャ経由でロードすること）
• 安全なエラーメッセージ（スタックトレースや機密データを返さない）
• 認可はサーバー側で検証されているか（UIだけでは不十分）

差分でレビュワーが見るべきポイント

信頼境界。 データがどこから入るか（HTTPリクエスト、Webhook、キュー、ファイル）を特定し、境界で検証が行われていることを確認してください。出力に対しては文脈適切なエンコーディング（HTML、SQL、シェル、ログなど）を確認します。

認証 vs 認可。 AIコードは「isLoggedIn」チェックを含むことが多いが、リソースレベルの強制を見落としがちです。敏感な操作は「誰が」「どのオブジェクトに対して」行えるかを必ず検証してください（例：URL内のuserIdが存在するだけでなく権限があるか）。

シークレットと設定。 APIキー、トークン、接続文字列がソース、サンプル設定、ログ、テストに含まれていないことを確認してください。また「デバッグモード」がデフォルトで有効になっていないかもチェックします。

エラー処理とログ。 失敗が生の例外、スタックトレース、SQLエラー、内部IDを返さないこと。ログは有用である一方、資格情報やアクセストークン、個人データを漏らさないこと。

レビュワーの小さな習慣が役立つ

リスクの高い経路については「ネガティブテストを1つ」要求してください（未承認アクセス、無効入力、期限切れトークンなど）。コードがその方法でテストできないなら、セキュリティ境界があいまいであるサインです。

依存性とサプライチェーンの安全性

AI生成コードは“問題を解く”ためにパッケージを追加しがちで、それが攻撃面、メンテナンスコスト、トランジティブ依存性を増やします。

出荷するものを固定する

依存選択は意図的に行ってください。

• バージョンをピン（ロックファイルをチェックイン）してビルドを再現可能にする
• 信頼できる少数のレジストリを優先し（可能なら内部にミラー）、
• 新しいパッケージは変更要求のように扱う：なぜ必要か、誰がメンテしているか、ライセンス、セキュリティの歴史を確認する

単純なルールが有効です：新しい依存はPRの説明で短い正当化を必須にする。AIがライブラリを提案したら、標準ライブラリや既存の承認済みパッケージで十分かを問ってください。

CIスキャンを追加し、次に何をするか定義する

自動スキャンは発見後のアクションが定義されていないと役に立ちません。以下を追加してください：

• SCA（ソフトウェア構成解析）で既知の脆弱な依存を検出
• シークレットスキャンで生成されたコードや設定内の鍵／トークン漏洩を発見

その上で取り扱いルールを定義します：どの深刻度がマージをブロックするか、どれがチケット化してタイムボックスで対応できるか、誰が例外を承認するか。これらを貢献ガイド（例：/docs/contributing）に記載しリンクしてください。

トランジティブリスクと依存膨張を監視する

多くのインシデントは間接的に引き込まれるトランジティブ依存から発生します。PRでロックファイルの差分をレビューし、定期的に未使用パッケージを削除してください—AIは「念のため」ヘルパーをimportして使わないことがよくあります。

更新プロセスをドキュメント化する

更新方法（自動のバンプPR、スケジュールされた更新、手動など）と承認者を明記してください。オーナーシップを明確にすると脆弱なパッケージの放置を防げます。

パフォーマンス：良い状態の定義

パフォーマンスは「アプリが速く感じる」ことではなく、実際の利用方法とコストに合った測定可能な目標の集合です。AI生成コードはテストを通り見た目も綺麗でも、CPUを無駄に使ったり、DBを過剰に叩いたり、不要なメモリアロケーションをしたりします。

明確なパフォーマンス目標を設定する

何かをチューニングする前に「良い」を数値で定義してください。典型的な目標：

• 応答時間：主要エンドポイントやユーザーアクションのp95／p99レイテンシ
• スループット：期待ピーク時のリクエスト/秒やジョブ/分
• リソース使用：ロード時のCPU／メモリ／ディスクI/O／ネットワークI/O
• コスト：1,000リクエストやジョブ、アクティブユーザー当たりのクラウド費用

これらは単一の合成ベンチではなく、現実的なワークロード（ハッピーパス＋一般的なスパイク）に紐づけてください。

ボトルネックが隠れやすい場所を知る

AI生成コードでは効率性の問題が予測可能な場所に現れます：

• データベース呼び出し：チャッティなアクセス、インデックス不足、繰り返しクエリ
• N+1クエリ：ループ内で関連データを1行ずつ取得する
• ファイルやJSONパース：大きなペイロードを繰り返しパースする、重いライブラリを使う
• タイトなループ：反復ごとの不要な処理、適切でないデータ構造、過剰なアロケーション

生成コードは「構造上正しい」ことが多いが「効率的である」ことはデフォルトではありません。モデルは可読で汎用的なアプローチ（追加の抽象化、繰り返しの変換、無制限ページング）を選びがちです。

最適化前にプロファイルする

推測で変更を加えないでください。本番に近い環境でプロファイリングと計測を始めます：

• アプリケーションプロファイラ（CPU/メモリ）とDBクエリトレースを使う
• レイテンシのパーセンタイルと最も遅いエンドポイントを収集し、上位2–3のホットスポットを特定する
• 変更は一度に一つ行い、再測定して効果を確認する

改善の前後で目標に対する効果を示せなければ、それは最適化ではなく単なる変更です。

実用的なパフォーマンスガードレール

生成コードは「動くが密かに時間と金を食う」ことがよくあります：余計なDBラウンドトリップ、意図しないN+1、大規模データに対する無制限ループ、止まらないリトライ等。ガードレールはパフォーマンスをデフォルトにします。

キャッシュは撤去計画を付けて使う

キャッシュは遅い経路を隠せますが、永遠に古いデータを返す危険もあります。キャッシュは明確な無効化戦略（TTL、イベントベースの無効化、バージョン化キー）のある場合のみ利用してください。更新方法が説明できないならキャッシュしないでください。

待機は意図的に設定する

タイムアウト、リトライ、バックオフは意図的に設定してください（無限待ちではないこと）。外部呼び出し—HTTP、DB、キュー、サードパーティAPI—には必ず：

• 適切なタイムアウト
• 限定されたリトライ回数
• ジッター付き指数的バックオフ
• 明確な失敗モード（フォールバック、部分応答、即時エラー）

これにより負荷下で資源を占有する「遅い失敗」を防げます。

非同期境界を尊重する

非同期コードパスでブロッキング呼び出しを避け、スレッド使用量を確認してください。一般的な問題点は同期的なファイル読み込み、イベントループ上でのCPU重い処理、非同期ハンドラ内でのブロッキングライブラリ使用です。重い計算が必要な場合はワーカープールやバックグラウンドジョブ、別サービスへオフロードしてください。

早い段階から大データに備える

バッチ処理やページネーションを設計段階で取り入れてください。コレクションを返すエンドポイントはリミットとカーソルをサポートし、バックグラウンドジョブはチャンク処理を行うべきです。クエリがユーザーデータで成長する可能性があるなら、その前提で設計してください。

リグレッションを出荷前に検出する

CIにパフォーマンステストを追加して出荷前に回帰を捕まえてください。小さくても意味のあるテスト：いくつかのホットエンドポイント、代表的なデータセット、閾値（レイテンシパーセンタイル、メモリ、クエリ数）。失敗はテスト失敗として扱い、再実行して通るまで放置しないでください。

信頼性：実際の条件下での正確さ

信頼性は単に「クラッシュしない」ことではありません。AI生成コードにとっては、システムが乱雑な入力、断続的な障害、実際のユーザー行動下で正しい結果を出し、出せない場合は制御された失敗を返すことです。

事前に信頼性の成果を定義する

実装の詳細をレビューする前に、重要パスごとに「正しい」とは何か合意してください：

• 正しい結果：正しいデータが書き込まれ、正しい応答が返り、沈黙の切り捨てや丸め誤差がないこと
• 優雅な失敗：明確なエラーメッセージ、安全なデフォルト、障害時に状態を壊さないこと
• 予測可能な回復：リトライ、リプレイ、再起動が重複やドリフトを生まないこと

これらの成果は、見た目はもっともらしいがエッジケースを隠しているAI書きのロジックを審査する標準をレビュワーに与えます。

リトライ可能な操作は冪等性を持たせる

AI生成ハンドラは「ただ実行して200を返す」ことが多く、支払い処理、ジョブ処理、Webhook受信ではリトライが通常です。

コードが冪等性をサポートしているか確認してください：

• 安定した冪等キー（リクエストID、イベントID、payment intent ID）
• 「既に処理済み」の記録の永続化
• 重複配信時に安全に振る舞う（二重課金、二重メール、重複行を作らない）

トランザクションと整合性を明示する

フローがDB、キュー、キャッシュに触れる場合、整合性ルールがコード上に明示されていることを確認してください—暗黙の前提に頼らないこと。

見るべき点：

• 複数書き込みが成功/失敗を共にする必要があるときのDBトランザクション
• "状態を書き込む" と "イベントを公開する" の明確な順序（アウトボックスパターンを検討）
• キャッシュ無効化が更新漏れに耐えられること

サービス間の部分失敗を扱う

分散システムは部分的に壊れます。コードが「DB書き込みは成功したがイベント公開が失敗した」や「リモート側は成功していたがタイムアウトした」などのシナリオを扱えることを確認してください。

無限リトライやサイレントな無視よりも、タイムアウト、限定リトライ、補償アクションを優先し、これらのケースをテストで検証することを明記してください（/blog/testing-strategy-that-catches-ai-mistakes を参照）。

AIのミスを捕まえるテスト戦略

AI生成コードは「完成した」ように見えてもギャップを隠します：エッジケースの欠如、入力に関する楽観的仮定、未走査のエラーパス。良いテスト戦略はすべてをテストすることではなく、驚くべき壊れ方をする箇所をテストすることです。

レイヤードされたテストセットを作る

まずロジックのユニットテスト、次に実際のシステムがモックと違う振る舞いをする統合テストを追加します。

• ロジックのユニットテスト、データベース／キュー／外部APIについては統合テスト
• 現実的なフィクスチャを使い、バグを隠す脆いモックは避ける

統合テストはAI生成のグルーコードが最も失敗する場所です：誤ったSQL前提、間違ったリトライ振る舞い、モデリングされていないAPI応答など。

意図的に「不幸なパス」をテストする

AIコードは失敗処理を過小指定しがちです。ネガティブテストを加えて、システムが安全かつ予測可能に応答することを証明してください。

• 無効入力、認証失敗、タイムアウト、空状態などのネガティブテストを含める

これらのテストは重要な成果を検証すること（正しいHTTPステータス、エラーメッセージにデータ漏洩がない、冪等なリトライ、優雅なフォールバック）に重点を置いてください。

入力が重いコードには生成的テストを使う

コンポーネントが入力をパースし、クエリを組み立て、ユーザーデータを変換する場合、従来の例では稀な組合せを見逃します。

• 該当箇所にはプロパティベーステストやファズテストを追加する

プロパティベーステストは境界バグ（長さ制限、エンコーディング問題、予期せぬnull）を捕まえるのに特に有効です。

カバレッジ：床を設定し、リスクに集中する

カバレッジは最低ラインとして有用ですが到達点ではありません。

• 最低カバレッジ目標を定めつつ、高リスクパスを優先する

認証／認可の判断、データ検証、金銭／クレジット、削除フロー、リトライ／タイムアウト論理の周辺を優先してテストしてください。高リスクが分からない場合は、公開エンドポイントからDB書き込みまでのリクエストパスをトレースし、その経路の分岐をテストしてください。

オブザーバビリティとインシデント準備

AI生成コードは「終わっている」ように見えても運用が難しいことがあります。本番でチームが痛い目を見る最短の道は可視性の欠如です。オブザーバビリティは驚くべきインシデントを日常的な修復に変えます。

実用的なログ

構造化ログを必須にしてください。プレーンテキストはローカル開発では問題ありませんが、複数サービスやデプロイが絡むとスケールしません。

必須事項：

• リクエストID（サービス間で伝搬し、すべてのログ行に含める）
• キーとなるコンテキスト項目：ユーザー/アカウントID（適切な範囲で）、エンドポイント、メソッド、ステータスコード、レイテンシ、エラー種別
• 一貫した重大度レベル（debug/info/warn/error）とその意味

目標は単一のリクエストIDで「どこで何が起きたか」を推測せずに答えられることです。

実際の障害に対応するメトリクス

ログは「なぜ」を説明し、メトリクスは「いつ」劣化が始まったかを教えます。以下を追加してください：

• エンドポイントやジョブ種別ごとのレイテンシ（p50/p95/p99）
• エラー率（5xx、リトライ、タイムアウト、失敗したジョブ）
• 飽和度：CPU、メモリ、スレッド／ワーカープール使用率
• キュー深度／バックログ（非同期処理）

AI生成コードは隠れた非効率（余分なクエリ、無制限ループ、チャッティなネットワーク呼び出し）を導入しがちです。飽和度とキュー深度で早期検出できます。

実際に役立つアラート設計

アラートはグラフだけでなく意思決定につながるべきです。ユーザー影響と結びつかないノイジーな閾値（例：CPU > 70%）は避けてください。

良いアラート設計：

• SLOに近いシグナル：「p95レイテンシ > X が10分続く」や「エラー率 > Y%」
• 明確なオーナーシップ：誰がページを受けるか vs 誰が通知を受けるか
• プレイブックリンク：最初の確認手順とランブックへの短いリンクを含める

ステージングや計画的演習でアラートをテストしてください。アラートが実際に発火して対応可能か検証できなければ、それはアラートではなく願望です。

ランブック：未来の自分に感謝されるもの

重要パスごとに軽量のランブックを書いてください：

• まず何を確認するか（ダッシュボード、最近のデプロイ、依存性の状況）
• 緩和方法（機能フラグオフ、スケールアップ、バックグラウンドジョブの無効化）
• ロールバック方法（正確なコマンド／プロセス、アーティファクトの所在）
• 誰に通知するか（オンコール、プロダクトオーナー、インシデントチャネル）

ランブックはコードやプロセスに近い場所（リポジトリ内や内部ドキュメント、/blog/ へのリンクやCI/CDパイプラインからの参照）に置き、システム変更時に更新されるようにしてください。

安全で再現性のあるリリースのためのCI/CD制御

AI生成コードはスループットを上げますが、同時にばらつきも高めます：小さな変更がセキュリティ問題や性能低下、微妙な正確性のバグを導入することがあります。規律あるCI/CDはそのばらつきを管理可能にします。

生成とデプロイを素早く行えるツール（Koder.aiのように組み込みのデプロイ／ホスティング、カスタムドメイン、スナップショット／ロールバックを持つプラットフォーム）を使う場合、CI/CDのゲートやロールバック手順も同様に迅速かつ標準化されているべきです—速さが安全性を損なわないように。

すべての変更に「品質ゲート」を適用する

パイプラインをマージ／リリースの最低ラインとみなし、"クイックフィックス"の例外を作らないでください。典型的なゲート：

• フォーマット＋リンティング：差分を読みやすくし一般的なミスを防ぐ
• ユニット＋統合テスト：明確な合格基準（フレークなテストは不可）
• セキュリティチェック：SAST、シークレットスキャン、依存脆弱性スキャン
• ビルド再現性：ツールバージョンの固定、依存のロック、決定論的なビルド成果物

重要なチェックはブロッキングにしてください。ノイズが多ければチューニングを行い、無視しないでください。

一度に全部ではなく段階的に出す

リスクの高い変更は制御されたロールアウトを好みます：

• 機能フラグでリスクの高い挙動変更を制御
• カナリアリリースでトラフィックの一部にのみ展開
• ブルー/グリーンデプロイが使えるプラットフォームでは利用

エラー率やレイテンシ、飽和度に基づく自動ロールバックトリガーを定義し、ユーザーが影響を感じる前にロールアウトを停止できるようにしてください。

ロールバックを平凡にし、訓練する

ロールバック計画は迅速でなければ意味がありません。DBマイグレーションは可能なら可逆にし、一方通行のスキーマ変更を避けるか、テスト済みのフォワードフィックス計画を用意してください。安全な環境で定期的に「ロールバックドリル」を実施してください。

何が変わったか、誰が承認したかを追跡する

意図、リスク、テストノートをキャプチャするPRテンプレートを必須にしてください。リリース用の軽量な変更ログを維持し、承認ルールを明確に（例：通常変更はレビュワー1名、セキュリティ感度の高い領域は2名）。詳細なレビューワークフローは /blog/code-review-checklist を参照してください。

「本番対応」の実用的定義

AI生成コードの「本番対応」は「私のマシンで動く」という意味ではありません。チームが実際のトラフィック、障害、締切の下で安全に運用・変更・信頼できることを意味します。

交渉不可事項（最低ライン）

AI生成の機能を出荷する前に、以下の4点は満たされている必要があります：

• セキュリティレビュー完了：脅威モデルの前提が記録され、リスクある入力が特定され、認可・データアクセス・シークレットの扱いを人がレビューしていること
• 意味あるテストが通っていること：コア挙動についてユニット＋統合カバレッジ、かつ最も起こりうる誤用について最低1つのネガティブテストがあること
• 監視が整備されていること：エラー、レイテンシ、稼働に関する主要指標、ログ、アラートがあること
• ロールバック可能であること：機能フラグや既知の良好ビルドにより迅速に戻せること（ヒーロー的対応が不要）

オーナーシップ：誰がページを持つか

AIはコードを書けますが所有はできません。生成コンポーネントごとに明確なオーナーを割り当ててください：

• サービス／チームオーナー：修正、オンコール、ハードニング後のフォローアップに責任を持つ
• 依存オーナー：ライブラリ更新、アドバイザリのレビュー、サードパーティパッケージの信頼の維持に責任を持つ

所有者が不明確なら、本番対応とは言えません。

今日チームが採用できる軽量チェックリスト

短く実用的であることが重要です：

1. 入力は検証されているか；authzは明示されているか；コードやログにシークレットがないか
2. 失敗モードが文書化されているか（タイムアウト、リトライ、制限）および安全なデフォルトが設定されているか
3. テストはハッピーパスとエッジケースをカバーし、CIがグリーンであるか
4. エラー率、レイテンシ、飽和度のダッシュボード／アラートがあるか
5. 依存はピンされレビュー済みか；アップグレードパスが明記されているか

最初の30日：ベースライン → 測定 → 強化

• 1–7日目： セキュリティスキャンのベースライン結果、パフォーマンス予算、信頼性SLOを定義
• 8–21日目： 欠けているテスト、重要なアラート、依存のピンを追加
• 22–30日目： CI/CDゲートを強化（テスト、重大脆弱性、監視欠如でブロック）、再測定して改善を継続

この定義により「本番対応」が具体化し、議論を減らし驚きを減らせます。