「品質ゲート」とは、作業が先に進む前に必ず通過しなければならないチェックのことです。ゲートにより、「十分に品質が確保されて出荷可能」という判断が主観的なものではなく、システムが毎回同じように強制するルールへと変わります。
ブロッキング型とアドバイザリー型
すべてのゲートはどちらか一方であり、その違いが設計の核心です：
- ブロッキング型— 失敗するとタスクが停止します。作業が通過するか、人間が上書きするまで先に進むことはありません。
- アドバイザリー型— 失敗しても結果は指摘事項としてプルリクエストに添付されるだけで、タスクは続行されます。
まずはアドバイザリー型から始めましょう。実際の作業でゲートが何を検知するかを1〜2週間観察し、条件を満たしたものをブロッキング型に昇格させてください。何も調整せずに初日からブロッキング型に設定すると、開発者がそれを回避する方法を学ぶだけになりがちです。
ゲートでチェックできる項目
ゲートは検証ステージの上に位置し、以下の項目をカバーできます：
- 自社のテストスイートが通過すること
- カバレッジの閾値
- リンティングおよび静的解析
- セキュリティスキャン
- 実行中のプレビュー環境でのブラウザテスト
- pull requestに添付される外部プロバイダーからの証拠
最も有用なゲートはほとんどの場合、既存のテストスイートです。なぜなら、それにはすでにチームが重要と判断した要件が反映されているからです。
ゲートが作業を停止できるタイミング
ゲートは検証中に実行され、開発エージェントの作業が完了した後、レビュー前に適用されます。ブロッキング型で失敗すると、タスクは再作業として戻され、却下されるだけのpull requestが生成されるのを防ぎます。
この順序は意図的なものです。実行中に失敗する方が、画面で失敗するよりもコストが低いからです。
ポリシー
ゲートはポリシー」にグループ化され、これをプロジェクトに直接適用します。ポリシーとは、ブロッキング型／アドバイザリー型の設定を含む名付けられたゲートの集合であり、本番サービス向けに標準的なポリシーを設定し、内部ツールには緩やかなポリシーを適用できます。
ポリシーにはバージョン管理がされています。変更を公開しても、新しいゲートが厳しすぎると判断された場合は以前のバージョンにロールバックできます。
オーバーライド
ブロッキング型ゲートは、権限を持つ人間がオーバーライドできます。オーバーライドの記録（誰が、いつ、何に対して行ったか）も残されます。
この記録こそが重要なのです。オーバーライドできないゲートは回避手段が生まれ、誰でも無言でオーバーライドできるゲートはゲートとは言えません。痕跡が残るオーバーライドであれば、実用的かつ説明責任が果たせます。
ゲートが行わないこと
ゲートは属性をチェックします。作業が正しい問題を解決しているかどうかは判断しません。それは仕様」に記載された受入基準やレビューの役割です。
すべてのゲートを通過しても、間違った変更である可能性があります。