【GitLab Epic Tour Japan 2026】AIエージェント時代に「スピードと統制」を両立する「Governed Software Factory」とは

「Opening Remarks & GitLab とGitLab Duo Agent Platform のビジョンについて」ーー
エージェント時代に必要なのは「Governed Software Factory」(Manav Khurana氏)

1年でアカウント数は5,000万から7,000万へ

Khurana氏はまず、Epic Tourを始めた理由を「AIによってソフトウェアエンジニアリングが非常に速いペースで変化している」ためだと説明しました。コミュニティが互いに学び、GitLabの最新の取り組みと市場の方向性を知る場として位置づけています。

同氏によれば、GitLabのアカウント数は約1年前の約5,000万から7,000万に増加しました。前四半期には新規顧客数が前年比で倍増し、今四半期はさらに伸びが加速しているといいます。顧客はソフトウェア、政府・公共、製造、運輸、自動車など、あらゆる業種に広がっています。

GitLabが選ばれる3つの理由

同氏は、企業がGitLabを選ぶ理由として次の3点を挙げました。

1. クラウド・モデルに中立：最重要資産であるコードを自社環境、シングルテナント、マルチテナントのいずれにも置け、どのベンダーのモデルも選べる
2. 単一の統合プラットフォーム：開発ライフサイクル全体で複数ツールをつなぎ合わせる必要がなく、摩擦が少ない
3. 全工程でのエージェント支援：コーディングだけでなく、ライフサイクルのあらゆる作業にAIが関わる

これらは、「あらゆるチーム、あらゆるツールが、想像のスピードで“信頼できる”ソフトウェアを出荷できるようにする」という同社のミッションの一部だと位置づけました。

統合プラットフォームから「統制されたファクトリー」へ

GitLabはこのミッションを段階的に進めてきました。第1段階は、計画、ソース管理、CI/CD、セキュリティ、アーティファクトを1つにまとめたDevSecOpsプラットフォームです。第2段階は約2年前の「インテリジェント・オーケストレーション」で、プラットフォーム内でエージェント支援を使えるようにしました。いずれも数週間の開発サイクルから日数を削ることに貢献したといいます。

そして現在目指しているのが、アイデアから本番まで「分単位」で到達できる「Governed Software Factory」です。

人間向けの「シャドー・ソフトウェアファクトリー」は破綻する

同氏は、多くの企業が意識しないまま「シャドー・ソフトウェアファクトリー」を抱えていると指摘しました。計画、ソース管理、スキャン、アーティファクト、パイプライン、デプロイにそれぞれ別のツールを使い、チームが手作業でコンテキストやポリシーを受け渡している状態です。どのポリシーをどこで適用するかも人の判断に頼っています。

この仕組みは人間だけが開発していた時代には機能しました。しかしエージェントは規則やポリシーに従うとは限らず、しかも機械のスピードで動きます。その結果、次のような問題が起きていると同氏は述べました。

• 信頼性：大量のリクエストでツールの一部が負荷に耐えられず止まると、ファクトリー全体が止まる。検証可能なIDを持たないエージェントが、データベースを削除するなどの事故も起きている
• コスト：トークンを繰り返し消費し、想定外のコスト超過を招く
• セキュリティ：ポリシーに従わないエージェントが、自社や他社の環境で侵害を引き起こす
• コンプライアンス：エージェントが証跡を残さなければ、準拠を証明できない

同氏は「これはAIの問題ではなく、AIを支えるアーキテクチャの根本的な問題だ」と強調しました。

Governed Software Factoryの4レイヤー

GitLabはこの課題に、得意とする「プラットフォームファースト」の手法で取り組みます。目指すのは「スピードか統制か」ではなく「スピードと統制の両立」です。Governed Software Factoryは次の4つの技術レイヤーで構成されます。

同氏は、GitLabの利用者はすでに多くの基盤コンポーネントを手にしており、新機能も続々と登場していると述べて、講演を藤田氏に引き継ぎました。

「Product UpdateとRoad Mapについて」
ーー4レイヤーを製品で具体化する(藤田 周氏)

年間340〜350の新機能、19系はエージェント活用を本格化

藤田氏は冒頭、GitLabが一貫してDevSecOpsプラットフォームを提供してきたことを振り返りました。チケット管理、ソース管理、マージリクエストを通じたCI/CD、セキュリティスキャンといった開発の成果物は、すべて単一のデータストアに集約されます。そのため、進捗や開発生産性の可視化、脆弱性レポートやSBOMなど規制対応に必要な情報も一元的に得られます。

GitLabは毎月第3木曜日に新バージョンをリリースしています。講演時点の最新版は19.4で、翌週木曜日に19.5が公開予定です。1リリースあたりの新機能・改善は25〜30件程度、年間では340〜350件にのぼるといいます。昨年の18系ではDuo Agent Platformを立ち上げ、今年の19系ではDuo CLIやフローなどを加えてエージェント活用を本格化させています。

エージェント・オーケストレーション：
Code Review Flowは1回0.25ドル

Duo Agent Platformは今年1月に一般提供(GA)となりました。ライフサイクル全体でエージェントやエージェントフローを利用でき、それらはGitLabのデータ、コンテキスト、イベントとネイティブに統合されています。管理者はエージェントに与える権限を制御でき、実行内容はすべて監査ログに残ります。

代表例として紹介されたのが「Code Review Flow」です。エージェントが大量のコードを生成するようになると、人がすべてをレビューするのは不可能になります。Code Review Flowを有効にすると、マージリクエストが作成されるたびに自動でレビューが始まり、数分で完了します。シニアエンジニアに依頼すれば数時間から数日かかることもあった作業で、コストは1回あたり0.25ドルだと説明しました。

次のボトルネックは「ステージ間の引き継ぎ」

ただし藤田氏は、各ステージでの作業が速くなっても、ステージ間の引き継ぎと待ち時間が次の大きな課題になると指摘しました。依頼が誰かのメールボックスで眠ったり、会議待ちになったりする時間です。これを解消する機能として、Slack連携と、目標を与えて自律的に作業させる仕組みが紹介されました。

デモ1：Slackの議論から実装・テストまで

シニアソリューションアーキテクトの佐々木氏によるデモでは、ECサイト風のアプリにナイトモードを追加する場面を取り上げました。

1. Slack上で「OS連動にするか、トグルで切り替えるか」を議論し、結論が出たところでGitLabにメンションしてイシュー化を依頼する。イシューには決定事項だけでなく、切り替え方式や議論の経緯も残る
2. GitLabのCLIツール(Claude CodeやCodex CLIに相当するもの)で/goalコマンドを使い、「ナイトモードのイシューを実装し、ローカルで単体テストを実施し、問題なければアプリを起動してブラウザで開く」という最終目標を指示する
3. CLIが自律的にTODOを立て、新規テストの作成と既存テストの実行を行い、すべて通過したうえでアプリを起動する

佐々木氏は、目標を「マージリクエストにプッシュしてCIを回し、失敗したら直すまで」と設定することも可能だと補足しました。

デモ2：自然言語で作る「ライブラリ更新の影響調査フロー」

2つ目のデモはカスタムフローです。これはマージリクエストやCIの失敗といったGitLabのイベントに連動してAIが処理を行う仕組みで、利用者が自由に作成できます。壊れたパイプラインの自動修正や、Jenkinsの設定をGitLab CIに変換するフローは標準で提供されています。

自作するにはYAMLで処理を記述する必要がありますが、エージェントの「Flow Creator」を使えば自然言語の指示からYAMLを生成できます。デモでは「ライブラリのバージョンアップを含むマージリクエストが作られたら、リリースノートを調べて影響範囲、再テストの観点、総合的なリスクを判断する」と日本語で指示し、生成されたYAMLをそのまま設定に貼り付けました。

その後、あるライブラリを3.1.3から3.1.5に上げるだけのマージリクエストでこのフローを呼び出しました。フローはインターネット上のリリースノートを読み、更新内容、影響を受けるアプリのコードと呼び出し箇所、推奨される再テストと確認すべき画面を提示しました。総合判定は「リスク低」で、パッチバージョンの更新であり破壊的変更が見当たらないことを理由に挙げています。

佐々木氏は、セキュリティスキャンだけでは抜けていた「影響調査」の工程も自動化でき、マシンスピードでの脆弱性対応に近づけると説明しました。

データ・コンテキスト：AIコストを制御する3つの方法

エージェントの活用範囲や利用者が広がり、自動化が進むほど、AIのコストは確実に増えていきます。藤田氏は、顧客から「コストをどう制御するのか」「その投資は本当に成果につながるのか」と頻繁に問われるとして、3つの方法を紹介しました。

1. タスクに合ったモデルを使う

Duo Agent Platformは、次のような複数のモデル調達経路に対応しています。

• エアギャップ環境でのセルフホストモデル
• 顧客が契約するクラウド(Amazon Bedrock、Google Vertex AIなど)上のモデルの持ち込み
• フロンティアモデル(各社の最新モデルを、通常はリリース当日から利用可能)
• 新たな選択肢として、GitLabが管理するオープンウェイトモデル

オープンウェイトモデルの狙いはコスト効率です。GitLabはフロンティアモデルだけでなくオープンウェイトモデルでも適切に動作するよう最適化を進めており、あるモデルはフロンティアモデルと同等の性能を約5分の1のコストで示したと紹介されました。管理者は、どのタスクにどのモデルを使うかを個別に設定できます。

2. コンテキストの問題を解消する

エージェントの働きは、持っているコンテキストの質で決まります。不完全なコンテキストは不正確な結果を生み、やり直しのたびに裏側で何度も情報を取りに行くことでトークンが浪費されます。

この課題に向けてGitLabが発表したのが、ナレッジグラフ機能「Orbit」です。OrbitはGitLab上のデータを関係性とともに提供し、GitLab Duoだけでなく、Claude CodeやCodexなど他のエージェントからも利用できるといいます。同じタスクをOrbitありとなしで比較した検証では、なしの場合に比べてトークン消費とコストが大幅に下がったと説明されました。Orbitは現在ベータ版として提供されています。

3. きちんと測定する

AIの導入・利用状況、本当に価値が出ているか、メンバーの利用量、タスクごとの予算といった点を、感覚ではなくデータで確認する必要があります。そのための機能として、Duo Agent Platformの分析ダッシュボードが紹介されました。グループと期間を絞り込み、どこにいくら使っているか、どのタスクが実際に使われているか、各タスクに適切なモデルが使われているかを把握できます。

DevOpsインフラ：ビルドの約半分は初回で失敗している

今日のソフトウェアの大半は、1,000を超えるオープンソースのパッケージやライブラリを組み合わせて作られています。藤田氏によれば、こうしたビルドを組み立てるパイプラインの約半分が初回実行で失敗しています。原因は、必要なパッケージが見つからない、バージョンの不整合、その時点でリポジトリが応答しないといったものです。

人間のスピードであれば、失敗のたびに手作業で修正しても回りました。しかしマシンスケールで開発が進むと、手作業での対応は追いつかなくなります。

そこでGitLabが紹介したのが、エンタープライズ向けのアーティファクト管理製品「Artifact Center」です。MavenやnpmなどのパッケージやコンテナイメージをGitLab上で管理し、コードやCI/CDと同じプラットフォームに統合します。目標は、すべてのビルドを初回で成功させることです。現在はベータ版です。

ソースコード、パイプライン、アーティファクトが1つにつながることで、例えば新たな脆弱性が公表された際に、該当パッケージを使っているリポジトリをすぐに特定できるといいます。

セキュリティ・コンプライアンス：依存関係とシークレットを守る

Dependency Firewall：ビルドに入れてよいものを制御

これまでは、ビルドに何が入るかを人が確認し、安全なものを選ぶことで対応してきました。しかしエージェントがマシンスピードでビルドを重ねる中、取り込まれる依存パッケージの安全性を人手で検証するのは現実的ではありません。

そこでGitLabはArtifact Centerに加えて「Dependency Firewall」を開発しました。ビルドに何を入れてよいか、何を入れてはいけないかをポリシーとして定義し、すべてのコンポーネントをスキャンしてポリシーを確実に適用します。GitLabはソースコードだけでなく、依存関係の利用に対しても制御レイヤーとして機能するようになります。Dependency FirewallはArtifact Centerと組み合わせるほか、JFrog ArtifactoryやSonatype Nexusなど他のアーティファクト管理ツールとも併用できます。

Secret Manager：漏洩の検出からローテーションまで

本番環境のシークレット保護は整ってきた一方で、ローカルPCやビルドパイプラインなどビルド環境のシークレットは注目されてこなかったと藤田氏は指摘します。いまやエージェントもそこに容易にアクセスできます。最近のサプライチェーン攻撃の多くは、コードそのものよりシークレットを狙っています。

GitLabは約2年前からシークレット検出を標準機能として提供してきました。これに新しい「Secret Manager」を組み合わせ、検出から修正までを1つの流れにしました。漏洩したトークンが見つかると「Fix with AI」ボタンが表示され、クリックするとエージェントがシークレットをローテーションし、新しい値をSecret Managerに格納します。さらに、コードがSecret Managerを参照するよう修正するマージリクエストまで作成します。操作は監査ログに記録されます。Secret Managerは現在ベータ版で、今月中にGAとなる予定です。

デモ3：「正しく集め、危ないものを止める」

続いて、ソリューションアーキテクトによるデモが行われました。担当者は、今後パッチの公開が急増すれば攻撃者はそのパッチに悪意あるコードを仕込もうとすると指摘し、Artifact CenterとDependency Firewallの重要性を強調しました。

Artifact Centerのデモでは、まずネットワークエラーでパイプラインが失敗する場面をDuoに分析させました。続いて次のリポジトリ構成を紹介しました。

各チームのpom.xmlには仮想リポジトリを1つ記述するだけで済み、参照先はサーバー側で一元管理されます。キャッシュ機能により、初回8分かかったビルドが2回目は3分で完了した例も示されました。

さらにOrbitと組み合わせ、チャットで「脆弱性のあるLog4jのバージョンをどのプロジェクトが使っているか」と尋ねると、該当プロジェクトとチームの一覧が得られる様子も紹介されました。

Dependency Firewallのデモでは、悪意あるパッケージ、既知の脆弱性、ライセンスを対象に「警告」または「強制(ブロック)」のポリシーを作成しました。脆弱性があっても業務上やむを得ないものを許可したり、特定のライセンスを例外扱いしたりする細かな設定も可能です。ポリシーはプロジェクト単位ではなくグループ単位で定義でき、組織全体に一括適用できます。

ブロックされたCIジョブには、ライセンス違反か脆弱性かといった理由が明示されます。ダッシュボードの例では、チェック済みパッケージ2,148件のうち、脆弱性52件、悪意あるパッケージ3件、使用禁止ライセンス2件をブロックしていました。何をなぜブロックしたかはすべて記録されるため、監査時にすぐ提示できるといいます。

「AIにはAIで」：Anthropicとの提携強化を発表

藤田氏は講演の締めくくりに、AI時代のセキュリティに話を戻しました。国内で大規模な顧客情報流出のニュースが続くなか、セキュリティ侵害はもはや社会問題になりつつあると述べています。

同氏が示したのは、両側から加速する構図です。開発側ではコーディングAIによってコードが非常に速いペースで生まれ、従来のセキュリティ対応は追いつけていません。攻撃側も同じようにAIモデルを使って脆弱性を見つけ、悪用しています。その板挟みのなかで、人間のスピードで対抗するのは難しくなっていると指摘しました。

これは感覚ではなく数字にも表れているといいます。紹介されたデータでは、ある集計で2022年に年間1,440件だった件数が、直近90日間だけで3,600件に達していました。一方で脆弱性の修正にかかる日数の中央値は、以前の32日から43日に延びています。見つかる数が増えるほど、直すスピードは落ちているのです。

同氏は「AIにはAIで対抗するしかない」と述べ、脆弱性の発見から修正までを高速に回し続ける必要性を訴えました。そのうえで本日の発表として、Anthropicとの提携をさらに進め、GitLab上で「Claude Mythos 5.1」を組み合わせた新しいセキュリティフローを提供すると明らかにしました。サイバーセキュリティ分野で高い能力を示すモデルを使い、攻撃側より早く脆弱性を見つけて修正できるようにする狙いです。

あわせて、「エージェントをどこまで信頼して任せてよいか」という問いに対する同社の答えとして、AIセキュリティのフレームワークも紹介されました。ポリシー、可視性、オーナーシップを土台とし、その上に5つの柱を置く構成で、今週から一般に公開されているといいます。

まとめ

藤田氏は、複数ツールをつなぎ合わせた従来のツールチェーンから、エンタープライズ品質の統制を備えたGoverned Software Factoryへ移行することで、開発スピードを上げながら適切なレベルの統制も実現できると総括しました。「スピードか統制か」ではなく、その両方を手にするという主張は、基調講演から一貫しています。

今回のEpic Tourでは、GitLabを活用して変革を進める顧客企業の事例セッションも、昨年の4社から倍増の8社が登壇しました。エージェントの導入が「試す」段階から「任せる」段階に移りつつあるいま、その前提となる統制の仕組みをプラットフォームとしてどう用意するかが、GitLabの今後の焦点になりそうです。