品質ゲート（Quality Gate）

品質ゲートとは、変更が次の段階（マージ、ステージングへのデプロイ、本番へのリリース）に進む前に満たさなければならない条件の集合です。各条件は測定可能で自動的にチェックされ、1 つでも失敗すればパイプラインは停止します。品質ゲートは「誰かが大丈夫そうだと思った」という判断を、明示的で合意済みの基準に置き換えます。

典型的なゲート条件

• ブロッキング対象のテスト（ユニット、API、E2E のスモークサブセット）がすべて成功する。
• 新規コードの行カバレッジまたは分岐カバレッジが、合意した値を下回らない。
• 静的解析や依存関係スキャンで、新たな Critical や High の指摘がない。
• 性能のしきい値を満たす。たとえば短い負荷テストで p95 レイテンシが 500 ms 未満である。
• ビルドが再現可能で、成果物（アーティファクト）が署名またはバージョン管理されている。

例

Jest のカバレッジゲートです。カバレッジがこれらの値を下回ると、jest --coverage は 0 以外の終了コードを返し、CI ジョブが失敗します。

// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      lines: 85,
    },
  },
};

これだけではジョブが失敗するにすぎません。このジョブをブランチ保護の必須ステータスチェックにすることで初めてゲートになり、成功するまでマージボタンが無効のままになります。SonarQube のようなツールは、複数の条件を 1 つの名前付きゲートにまとめ、単一の合否結果として提示します。

なぜ重要なのか

ゲートは「準備完了」の定義を可視化し、一貫したものにします。また、議論を適切なタイミングに移します。チームはリリースのたびではなく、しきい値を設定するときに一度だけ議論すれば済みます。

よくある間違い

• ごまかせる数値でゲートを設ける。 一律 90% のカバレッジルールは、何もアサーションせずにコードを実行するだけのテストを招きます。新規コードのカバレッジでゲートを設け、テストそのものもレビューしましょう。
• ゲートにフレーキーなチェックを入れる。 ランダムに失敗するゲートは回避されるようになります。ブロッキングには決定的なチェックだけを残し、それ以外はアラート付きの非ブロッキングとして実行します。
• ゲートが多すぎ、遅すぎる。 リリース直前にだけ 10 個の条件をチェックすると、誰も直す時間のない失敗の山ができます。軽いチェックはプルリクエストごとに早い段階で実行しましょう。
• 黙ってスキップできる。 ゲートをスキップできるなら、誰がなぜスキップしたかを記録しましょう。