朝、レビュー依頼の通知が30件たまっている。中身を開くと、どれもエージェントが一晩で作った差分で、ひとつのPRに数百行、ファイルは20個に渡っている。書いた人間に「なぜここをこう直したのか」を聞こうとしても、書いたのは人間ではない。受託案件でこの状態に陥ると、レビューはただの渋滞ではなく、品質と説明責任の両方が同時に詰まる。
実装はもう律速ではなくなった。AIエージェントがコードを書く速度はとっくに人間のレビュー速度を追い越していて、ボトルネックは静かに「PRレビュー」へ移っている。ある国内の調査記事では、エージェント導入後にマージされたPR数が約2倍、PRサイズが2.5倍以上に膨らんだ一方で、レビューに費やす時間も同じだけ増えたと報告されている。速く書けるようになったぶん、読む側が崩れる。
そんな状況を背景に、ソース管理サービスそのものを「エージェント前提」で作り直す動きが出てきた。本記事では、その方向性を示す一例としてGitLabの新サービスに触れつつ、受託開発の現場でソース管理・レビュー・品質保証をどう再設計するかを、実務の手順に落として整理する。
「人間が手で触る前提」だったGitが限界に来ている
GitやGitHub、GitLabといったソース管理は、もともと人間がコードを手で書き、手でコミットすることを前提に設計されている。そこに毎秒のように差分を作るエージェントが並列で走り込むと、クローンやプッシュの負荷が想定外のかたちで跳ね上がる。
GitLabは2026年6月、ロンドンでのイベント「GitLab Transcend」で、AIエージェント向けの次世代Git互換ソース管理サービスを発表した。Publickeyの報道によると、このサービス（「Project Switch」と紹介されている）はGitプロトコルとの互換性を保ちながらバックエンドを再設計し、GitLabの発表によると最大で約50倍の高速化、ネットワークトラフィックを1/1000程度に削減、トークン消費を半分に抑えるとされる。ただし、この数値は同社の内部テストに基づく主張であり、現時点で詳細仕様は確定情報が少ない。受託の現場で採用を判断する材料というより、「ソース管理がエージェントを一級市民として扱い始めた」という方向性を読む材料として捉えるのが妥当だ。
押さえておきたいのは、ツールが速くなっても受託開発の責任構造は変わらないという点だ。最終的に「このコードを納品し、保守する」と顧客に約束するのは人間であり、エージェントが何を書いたかを説明できないなら、それは速さではなく負債になる。だからこそ、運用側の設計が問われる。
まずPRを「人間が読める単位」に割り直す
エージェントが律速を外した世界で、最初にやるべきはツールの導入ではなく、変更の粒度を強制することだ。1つのタスク＝1つの小さなPRに割り、1PRあたりの変更行数に上限を設ける。レビュアーが文脈を保ったまま読み切れる単位に収めるだけで、レビューの質は目に見えて戻る。
弊社が支援したある業務システムの受託案件（製造業向け、社名は伏せる）では、エージェントに開発を任せ始めた当初、1PRが平均600行を超え、レビューが1件あたり40分を要して滞留していた。そこでタスク分解の段階で「1機能=1PR、変更は原則200行まで、超える場合は設計レビューを別途」というルールを敷いた。結果、PR1件あたりのレビューは10分前後に収まり、滞留が解消した。重要なのは行数の数字そのものではなく、エージェントへの指示プロンプトの段階で「小さく刻め」を組み込んだことだ。レビューしやすいPRは、レビュー工程ではなく生成工程で作られる。
レビューの観点も整理しておきたい。AI生成コードは、人間が書いたコードより文脈の説明が薄いぶん、読み解きに時間がかかる傾向がある。そこで役割を分ける。
| 判断の種類 | 担当 | 内容 |
|---|---|---|
| Why / What | 人間のレビュアー | この変更は要件に合うか、設計判断は妥当か |
| How（規約・整形） | 自動ゲート | フォーマット、命名、静的解析、定型的な指摘 |
| 振る舞いの検証 | CI・テスト | テストが通るか、回帰がないか |
人間は「なぜ」と「何を」に集中し、「どう書くか」のチェックは自動ゲートとエージェントに任せる。この切り分けが、レビュー負荷を下げながら品質を保つ前提になる。テスト自動化を含む品質保証の組み立てについては、Playwrightを使ったAI主導のQA自動化で具体的な構成を扱っているので、CIゲートの中身を詰めるときの参考にしてほしい。
「誰が書いたか分からない差分」を本番に入れない仕組み
受託で一番怖いのは、出自の追えない変更が本番に紛れ込むことだ。エージェントが大量にコミットする時代には、コミットの主体と権限を明示的に設計しなければ、監査も説明責任も成り立たない。
最低限、次の3点は運用ルールとして固める。
| 論点 | 設計の指針 |
|---|---|
| コミット主体の識別 | エージェント実行は専用アカウント／ボット署名で記録し、人間のコミットと区別できるようにする |
| 権限の最小化 | エージェントはタスクに必要な範囲のみに書き込み権限を持たせ、保護ブランチへの直接プッシュは禁止 |
| マージの責任者 | エージェントの差分は必ず人間がレビュー・承認してからマージ。承認者をログに残す |
エージェントの差分が直接 main に入る経路は塞ぎ、保護ブランチへはレビュー承認を経たPRからしか入れない。これは新しい話ではなく、従来の受託でやってきた統制を、コミット主体が機械になった分だけ厳密にやり直すだけだ。秘匿情報の混入対策も同じ系統で、エージェントが生成したコードに認証情報やトークンが紛れ込む事故は現実に起きる。シークレットスキャンを開発フローに組み込む実装はGitHubシークレットスキャンMCPサーバーをSecOpsに統合する記事で、ソースコードと秘匿情報の監査の考え方はソースコードのシークレット監査で整理しているので、受託の引き渡し前チェックに組み込むとよい。
権限とシークレットの管理を開発フロー全体に織り込む設計については、GitLab 19のDeveloper FlowとSecrets ManagerでDevSecOpsを自動化する記事も合わせて読むと、ツール側でどこまで強制できるかの感覚がつかめる。
上流に自動ゲートを積み、人間のレビューを最後の砦にする
レビュー負荷を構造的に下げるには、PRがレビュアーの目に触れる前に、できるだけ多くの問題を自動で弾いておく。多段ゲートの考え方だ。
具体的には、エージェントがコードを生成する段階でテスト駆動のサイクルを回させ、コミット前に静的解析とフォーマットを通す。PRが上がった時点でCIがテスト・型チェック・セキュリティスキャンを実行し、ここを通過したものだけが人間のレビューに到達する。人間のレビューは「最初の防壁」ではなく「最後の砦」に位置づける。上流で何重もの自動ゲートをくぐらせたうえで、最終段で人間が要件適合と設計判断を見る、という順番が肝心だ。
ただし注意したいのは、AIによるレビュー指摘を鵜呑みにしないことだ。自動ゲートやAIレビューが出す指摘の中には的外れなものも混じる。受託では「AIが指摘したから直した／直さなかった」では顧客に説明できない。最終判断は人間が持ち、その判断の根拠を残す。これが、量産されるコードの中で説明責任を守る最後の安全装置になる。
顧客への説明責任という観点も忘れてはいけない。エージェントを使って開発していること、その成果物をどう検証しているかは、受託の契約・報告の中で透明にしておく。「速く安く作れます」だけを売りにすると、品質保証の工程を削った印象を与えかねない。むしろ「エージェントで生成量は増えるが、レビューと自動ゲートで品質をどう担保するか」をセットで提示できることが、これからの受託の差別化になる。
どこから着手するか
エージェントが量産するコードは、それ自体が問題なのではない。問題は、量産を前提にした受領・レビュー・監査の設計が追いついていないことにある。ツールが速くなる方向には今後も進むだろうが、受託開発で守るべきものは「納品物を説明でき、保守できる状態」であり、そこは変わらない。
最初の一歩としては、自社あるいは委託先の開発フローで「エージェントの差分が誰の承認を経て本番に入っているか」を一度たどってみることを勧めたい。そのうえで、PRの粒度ルールと自動ゲートのどちらが欠けているかを見極めれば、着手すべき箇所がはっきりする。
エージェント前提のソース管理・レビュー体制をどう組むか、既存の受託フローにどう織り込むかでお悩みでしたら、グリームハブのお問い合わせからご相談ください。現行のリポジトリ運用を拝見したうえで、レビューと品質保証の設計をご一緒に組み直します。
Sources
- GitLab、AIエージェント向けの次世代Git互換ソースコード管理サービス「Project Switch」発表。最大で50倍高速かつ半分のトークンで利用可能に － Publickey
- GitLab Announces New Capabilities to Give Enterprises Speed and Control at Agentic Scale － GitLab Investor Relations
- GitLab: Built for the agentic engineering era － GitLab Blog
- PRが3倍になったのにリリースが増えない — AI時代のボトルネック移動と処方箋 － Zenn
