AIが書くコードは誰が止めるのか｜GitLab 19.2の検収6ゲート

AI開発会社へ聞くべき最初の質問は「何倍速く作れますか」ではない。「そのAIが間違えたとき、誰が、どの証拠を見て、本番反映を止められますか」だ。

GitLabは2026年7月16日、GitLab 19.2を公開した。脆弱な依存関係を検知し、更新とビルド修正をマージリクエストとして提案するDependency Scanning Auto-Remediation、従来のパターン検査では見つけにくい認可・業務ロジック・競合状態などを確認するSecurity Review Flowは、いずれもパブリックベータとして発表された。

注目すべきは「AIが修正できる」ことだけではない。GitLabは、変更が既存の承認ゲートと監査証跡を通ること、Security Review Flowが自ら承認せず、人が最終判断することも明示した。さらに短命・ジョブ限定トークン、AI操作の監査イベント、グループ単位のレビュー指示、MCPアクセス制御を挙げている。

これはGitLabを使えば安全が保証されるという意味ではない。むしろ、AIが作る変更量が増えるほど、要求、権限、品質、人間承認、証跡、復旧を発注条件にしなければならないことを示す市場シグナルだ。本記事では、AI駆動開発を外注・内製する中堅企業の経営者向けに、製品を問わず使える「検収6ゲート」を示す。

この記事の要点

• GitLab 19.2では、AIによる依存関係修正とSecurity Review Flowはパブリックベータ、Duo CLIとCustom Flowsは一般提供として発表された。
• AIによるセキュリティレビューは、静的解析、人のレビュー、テストを置き換える保証ではない。GitLab自身もSecurity Review Flowは自動承認せず、最終判断を人が行うとしている。
• 「コード生成速度」だけを成果にすると、レビュー待ち、脆弱性、誤った依存関係、権限過大、説明不能、復旧不能が下流へ積み上がる。
• 発注前に、要求・権限・品質・人間承認・証跡・復旧の6ゲートを契約と検収票へ入れる。
• 各ゲートには提出証拠と停止条件を置き、AIが自己採点した結果だけを検収証拠にしない。

GitLab 19.2で確認できること

公式発表の範囲を、一般提供・ベータ・導入側の判断に分ける。

「搭載されている」と「自社で有効にし、正しく設定し、監査できる」は別の状態だ。ベータ機能は仕様や提供条件が変わりうる。発注側は、ベンダーのデモで機能を見るだけでなく、契約対象のプラン・版・設定・運用証拠を確認する必要がある。

AI開発でボトルネックはどこへ移るのか

AIは、コード作成、テスト案、設定変更、依存関係更新の速度を上げる。しかしソフトウェア開発の完了条件は「差分ができた」ではない。要求を満たし、意図しない権限や欠陥を増やさず、承認され、追跡でき、失敗時に戻せて初めて本番へ出せる。

生成量が増えると、下流では次の滞留が起きる。

1. レビュー待ち: 人が読める量を超える差分が短時間で届く
2. 検証不足: AIが書いたテストが、AIの誤解をそのまま正解として固定する
3. 依存関係膨張: 実在性、保守状況、ライセンスを確認せずパッケージが増える
4. 権限膨張: テストを通すためにAPI、クラウド、DBの権限を広げる
5. 証跡欠落: 誰の指示で、どのモデル・ツールが何を変えたか説明できない
6. 復旧遅延: 小さな変更が大量に混ざり、原因と安全な戻し先を特定できない

GitHubの公式ガイドも、AI生成コードについて、コンパイル・テスト・静的解析、要求と意図の確認、依存関係、幻覚したAPIやパッケージ、人による協働レビューを挙げている。NISTのSSDFは、安全な開発慣行を調達者と開発者の共通言語にできるとしている。AI開発は別世界の工程ではなく、既存の安全な開発工程へAI固有の証跡と権限管理を足すべきものだ。

AI開発の検収6ゲート

6ゲートは、特定のGitホスティング製品やAIモデルに依存しない。各ゲートで、発注側が受け取る証拠と、通過させない停止条件を決める。

ゲート1：要求

AIは曖昧な指示にも、それらしい完成物を返す。「顧客管理画面を作る」だけでは、閲覧範囲、削除、監査、同時更新、個人情報、性能の受入条件がない。コードの量やテストの本数が増えても、要求が抜けていれば速く間違える。

発注時には、要求ID、受入条件、対応テスト、結果、証拠URLを一行で追える表を提出させる。AIが生成した仕様でも、人が業務・法務・セキュリティの観点から承認する。

ゲート2：権限

コーディングエージェントは、ファイル編集だけでなく、シェル実行、パッケージ導入、ネットワーク接続、クラウド操作、MCP経由のツール利用まで行う場合がある。便利さのために長期APIキーや管理者権限を渡すと、誤操作・プロンプトインジェクション・資格情報漏えいの被害範囲が広がる。

権限表には、主体、対象、読取/書込、環境、期限、承認者、ログを記載する。短命・ジョブ限定トークンは良い設計要素だが、それだけでアクセス先や操作範囲が適切とは限らない。MCPの公式セキュリティガイドも、短命トークン、トークン検証、対象リソースの確認を推奨している。

ゲート3：品質

AIレビューと決定論的な検査を組み合わせる。ユニット・統合・E2Eテスト、静的解析、依存関係スキャン、秘密情報検知、ライセンス確認、性能・障害試験を、変更リスクに応じて実施する。

危険な兆候は「テストを通すために失敗テストを削除する」「型やLintを無効化する」「知らないパッケージを追加する」「セキュリティ所見を誤検知として一括除外する」ことだ。AIが作ったコードを別のAIが高得点と評価しても、独立した証拠にはならない。重大機能では業務担当・開発者・セキュリティ担当の少なくとも二つの視点を入れる。

ゲート4：人間承認

AIが差分を作り、AIがレビューし、AIが本番反映する一本線を作らない。少なくとも、本番へ出る変更には作成主体から独立した承認者を置く。高リスク変更では、二者承認、時間帯制限、段階リリースを使う。

GitLab 19.2の公式発表がSecurity Review Flowは自ら承認しないと明示している点は重要だ。検収票では「人が見ました」ではなく、承認者、時刻、確認した証拠、残した例外を記録する。

ゲート5：証跡

監査ログは事故後だけのものではない。どのプロンプト・要求・モデル・ツール・権限・外部接続が変更へ影響したかを追えれば、品質低下や費用増の原因を比較できる。

ただし、プロンプト全文に機密や個人情報が含まれる場合がある。何でも永久保存するのではなく、保存対象、マスキング、閲覧権限、保存期間を決める。証跡と秘密保持を両立させる設計が必要だ。

ゲート6：復旧

AIの変更は小さく分け、リリース単位を追跡する。一度に大量の機能を生成して本番へ出すと、どの差分が障害原因か切り分けられない。段階リリース、Feature Flag、DB移行の後方互換、バックアップ、切り戻し試験を完了条件にする。

復旧目標は「戻せます」ではなく、誰が、何分以内に、どの状態へ戻し、データ整合性をどう確認するかで書く。

6ゲート48点の発注前スコア

各ゲートを4項目、0・1・2点で評価する。合計48点で、判定は次の通りとする。

• 40〜48点: 限定範囲で発注・継続候補
• 32〜39点: 不足証拠を条件化してから進む
• 24〜31点: 有償の発見・設計工程へ戻す
• 0〜23点: 本番開発の発注を停止する

各ゲートの4項目は「責任者」「基準」「証拠」「停止条件」。どれか一つでも0点なら、合計点が高くてもそのゲートは未通過とする。特に次の4つは強制停止条件だ。

• AIまたは変更作成者が単独で本番承認できる
• 本番・顧客データへ期限のない管理者権限がある
• 重大なテスト失敗・セキュリティ所見を未解決のまま出荷する
• バックアップまたは切り戻し手順を試していない

AI駆動開発の見積もりをどう読むかでは、生産性向上分を見積もり・契約へどう反映するかを扱っている。本記事の6ゲートは、その速さを品質と説明責任の条件へ変えるための検収側の道具だ。

AI開発の「速さ」ではなく、止められる検収条件を先に作りませんか

GXOでは、AI駆動開発を発注する企業向けに、RFP、見積もり、権限表、CI/CD、検収、契約上の責任分界を第三者として確認します。特定の開発会社やAIツールを売る前提ではなく、6ゲートと停止条件を先に作ります。

AI開発の発注条件を相談する → GXO お問い合わせ

RFPへ追加する質問14項目

1. AIを使う工程、モデル、ツール、外部サービスを列挙できますか
2. AI生成物を識別し、変更履歴へ残せますか
3. 要求・受入条件・テストを追跡する表を提出できますか
4. AIがアクセスするリポジトリ、MCP、API、クラウド権限は何ですか
5. 認証情報は短命・環境別・最小権限ですか
6. AIが新しい依存関係を追加するとき、実在性・保守・ライセンスを誰が確認しますか
7. AIが生成したテストとは独立したテストを用意しますか
8. 認可・業務ロジック・競合状態をどうレビューしますか
9. AIまたは変更作成者が単独で承認・本番反映できますか
10. セキュリティ所見の例外は誰が期限付きで承認しますか
11. AI支援操作のログを何日保存し、誰が閲覧できますか
12. モデル・プロンプト・ツール更新時に回帰試験しますか
13. 本番障害時の停止、切り戻し、データ復旧を何分で行いますか
14. 契約終了時にソース、設定、テスト、SBOM、ログ、運用手順を引き渡しますか

「当社のAIが自動で確認します」だけでは回答にならない。設定画面、ルール、実行結果、サンプル監査ログ、切り戻し記録など、人が検証できる証拠を要求する。セキュリティ・バイ・デザインで開発会社を選ぶ基準も、提案段階の確認に使える。

AI開発のKPIは生成量ではなく流量と損失で測る

AIの導入効果を「生成コード行数」「AI利用者数」だけで測ると、不要な変更を増やすほど高評価になる。経営向けには次の指標を組み合わせる。

DevSecOpsの基礎から整える場合は中堅企業のDevOps・CI/CD導入ガイドを参照し、ツール導入より先に変更単位、承認、リリース、復旧を標準化する。

30日で最低限の統制を作る

1週目：AI利用箇所と権限を棚卸し

開発者個人のIDE、CLI、CI、クラウドエージェント、コードレビュー、MCPを一覧にする。会社契約だけでなく、個人アカウントや無償版も対象にする。

2週目：高リスク変更を定義

認証、決済、個人情報、権限、インフラ、DB移行、外部公開APIを高リスクと定義し、人の二者承認や追加テストを必須にする。

3週目：証拠と停止条件をCI/CDへ入れる

テスト、静的解析、依存関係、秘密情報、承認、デプロイを一つの変更単位へひも付ける。失敗した検査を迂回できる権限も限定する。

4週目：復旧訓練をする

AIが作った変更を含むリリースを想定し、停止・切り戻し・データ整合性確認を実施する。復旧できなければ、生成速度を上げる前にリリース単位を小さくする。

よくある質問（FAQ）

GitLab 19.2を導入すればAI生成コードは安全になりますか

安全が保証されるわけではありません。製品は承認、監査、スキャン、権限制御を支援しますが、対象範囲、設定、例外、人の判断、復旧は導入企業が設計します。ベータ機能は提供条件の変更も考慮します。

AIによるコードレビューがあれば人のレビューは不要ですか

不要にはなりません。AIレビューは見落としを減らす補助になりますが、要求、業務ロジック、許容リスク、法務・契約、例外判断は人が確認します。GitLabのSecurity Review Flowも最終承認は人が行うとしています。

AIが作ったテストがすべて通れば検収できますか

できません。AIが要求を誤解していれば、その誤解に合うテストを作る可能性があります。受入条件との対応、独立したレビュー、統合・障害・セキュリティ試験が必要です。

6ゲートは小規模開発にも必要ですか

必要ですが、証拠の重さをリスクに合わせます。小規模な社内ツールでも要求、最小権限、人間承認、切り戻しは残し、高リスク機能だけ追加レビューを厚くします。

ベンダーがAIの利用方法を企業秘密として開示しない場合はどうしますか

プロンプトや内部ノウハウの全文開示ではなく、利用工程、データ送信先、権限、モデル変更、検査、承認、成果物の再現に必要な情報を要求します。検収とリスク判断に必要な情報まで非開示なら、責任分界を契約できません。

GXOはどこまで確認できますか

提案・見積もり段階の6ゲート採点、RFP・契約条件、権限表、CI/CD・テスト証拠、検収、切り戻し計画を確認できます。実装が始まった案件のセカンドオピニオンにも対応します。

出典・確認日

• GitLab公式「GitLab 19.2 Brings Governed Agentic Automation」
• GitLab公式「What's new in GitLab 19.2」
• NIST「Secure Software Development Framework」
• NIST NCCoE「DevSecOps Practices―AIを含む参照モデル」
• GitHub Docs「Review AI-generated code」
• OWASP Cheat Sheet「Secure Coding with AI」
• MCP公式「Security Best Practices」

最終確認日：2026年7月27日。GitLabのベータ/一般提供区分、機能、プラン、設定は変更されうるため、導入・見積もり時に公式リリースノートと契約プランを再確認する。各機能を安全性の保証として扱わない。

まとめ

GitLab 19.2が示したのは、AIがコードを書き、脆弱性修正やレビューまで支援する未来だけではない。AIが増やす変更を、既存の承認、監査、短命権限、人の最終判断へ通す必要性だ。

AI開発の発注で「3倍速い」「半分の工数」だけを比較すると、下流のレビュー、障害、セキュリティ、説明責任を発注側が引き受ける。要求・権限・品質・人間承認・証跡・復旧の6ゲートを先に置けば、速度を否定せず、速度が生むリスクを検収可能な条件へ変えられる。

AI駆動開発の6ゲート診断を相談する → GXO お問い合わせ