2026年10月9日、GitLabのイベント「GitLab Epic Tour Japan 2026」が開催されました。キーノートでは、AIエージェントによる開発の高速化と、組織のルールに沿った運用の両立を目指す「Governed Software Factory（統制されたソフトウェアファクトリー⁠）⁠」の構想が紹介されました。続くGitLabの機能説明とデモでは、仕様の検討から実装・テストへ作業をつなぐ仕組みのほか、AIの利用コストの管理、ビルドに使うパッケージの管理、脆弱性への対処などが取り上げられました。

本稿では、キーノートの模様を中心にレポートします[1]。

AIエージェントによる開発を支える4つの層

冒頭に登壇したGitLabのChief Product and Marketing Officer、Manav Khurana氏は、GitLabの登録ユーザー数が1年余り前の約5,000万人から7,000万人以上に増えたと紹介しました。新規顧客数についても、前年比で100%以上増えたと述べています。

続いて、Khurana氏はGitLabが選ばれる理由を3つ挙げました。まず、コードを置く環境や利用するAIモデルを、特定のクラウドやベンダーに縛られずに選べることです。次に、開発に必要なツールが一つのプラットフォームに統合され、ツール同士をつなぐ負担を減らせることです。そして、コーディングだけでなく、開発の各工程でAIの支援を受けられることです。

Khurana氏は、ソフトウェア開発に関わるすべてのチームが、信頼できるソフトウェアを速く届けられるようにすることを、GitLabのミッションとして説明しました。同氏は、GitLabが計画、コード管理、セキュリティなどを統合して工程間の連携を改善し、さらにエージェントを取り入れて開発を高速化してきたと振り返りました。

その先にあるのが、今回の構想「Governed Software Factory」です。アイデアから本番環境への反映までを数分で進めることを目指し、人とAIエージェントの権限や行動を管理しながら、組織のルールに沿って開発を進める基盤を描いています。

この構想の背景には、ツール同士をつなぐ作業を人が担っている開発現場の状況があります。計画、コード管理、セキュリティ検査、成果物の管理、ビルド、デプロイなどに別々のツールを使い、人が情報を転記し、前後の事情を説明して仕事をつないでいます。組織のルールをどの工程で適用するかも、人の判断に頼っています。Khurana氏は、こうした状況を「Shadow Software Factory」と呼んでいました。

Khurana氏は、人が中心となって開発を進める状況では機能していたこの仕組みも、エージェントが大量の作業を高速に進めると限界に突き当たると指摘しました。大量の要求を受けたシステムが負荷に耐えられず、開発の流れが止まってしまうためです。

課題は処理量だけではありません。エージェントの身元を検証できないことや、ポリシーが必ずしも守られないことも挙げました。具体例として、エージェントによるデータベースの削除や、トークンの大量消費によるコスト超過に言及しました。また、エージェントの実行内容をたどれるログなどの証跡が残らなければ、ルールを守っていたことを証明できないと説明しました。

Khurana氏は、これらをAIを支えるアーキテクチャの問題と捉え、開発基盤全体で解決する必要があると指摘しました。そのための開発基盤を、次の4つの層に分けて示しました。

• エージェント・オーケストレーション：適切な権限と情報のもとで、人とエージェントが目標の達成まで連携する仕組み
• データ＆コンテキスト：必要な情報を最初から渡し、情報探索の繰り返しやトークンの浪費、誤りを減らす仕組み
• DevOpsインフラストラクチャ：多数のエージェントによる同時アクセスや、大量のビルド・テストに耐える基盤
• ガバナンス＆セキュリティ：ポリシーと管理の一元化、エージェントの行動の追跡、増えるコードに対応するセキュリティ検査の自動化

Khurana氏は、現在のGitLabには、この構想を支える基盤の多くがすでに備わっていると説明しました。最近追加された機能も多く、今後も拡充を続けるとしています。

開発の各工程をエージェントでつなぐ

続いて登壇したのは、GitLab合同会社のソリューションアーキテクト本部長、藤田周氏です。

藤田氏はまず、GitLabの統合プラットフォームを振り返りました。チケットやコード、CI/CDなどの情報を一か所に集め、プロジェクトの進捗や開発生産性の可視化、脆弱性レポートの作成、監査に活用できると説明しました。

藤田氏は、この統合基盤にエージェントの実行機能を加え、CLIやカスタムフロー、コンテキストの活用へと広げてきたGitLabの歩みも紹介しました。そのうえで、先ほどの4層に沿って機能の説明に入りました。最初に取り上げたのは、エージェントによる作業の連携を扱う「エージェント・オーケストレーション」の層です。

AIエージェントの実行基盤となるGitLab Duo Agent Platformでは、コードレビューなどの一連の作業をエージェントが進める「フロー」を利用できます。藤田氏は、エージェントに与える権限を管理者が設定できると説明しました。エージェントの作業ログは、組織のルールを守っていたことを示す証拠としても使えるとのことでした。

例に挙げたのが、Code review flowです。AIが生成するコードの量が増えると、人によるレビューが追い付きにくくなります。Code review flowではマージリクエストの作成をきっかけに、エージェントがレビューを自動実行します。藤田氏は、数分でレビューを終えられるとして、人によるレビューを待つ時間を減らせると紹介しました。この例では1回あたりのコストは0.25ドルだったと述べています。

レビューなど個々の作業を速くしても、次の作業の依頼がメールに埋もれたり、引き継ぎに会議が必要になったりすれば、工程間の待ち時間は残ります。藤田氏は、こうした引き継ぎの停滞を、次に解決する課題として挙げました。

Slackでの議論を実装⁠・テストへ引き継ぐ

続いて、GitLab合同会社のシニアソリューションアーキテクト、佐々木直晴氏が、Slackでの議論を実装につなげるデモを行いました。題材は、グッズ販売サイトへのナイトモードの追加です。

デモではまず、Slack上でナイトモードの仕様を話し合いました。OSの設定に連動して自動的に切り替えるのか、利用者がスイッチで選ぶのかを検討し、手動で切り替える仕様に決めました。佐々木氏はそのスレッドの返信欄で@GitLabをメンションし、議論を踏まえてIssue（課題）を作成するよう依頼しました。

この呼び掛けに応じてIssueを作成するのが、Slack連携機能のGitLab for Slackです[3]。作成されたIssueには、機能の要件だけでなく、切り替え方式を決めた背景もまとまっていました。

次に佐々木氏が使ったのは、目標を渡すとエージェントがその達成に向けて作業を進めるGoal-driven flowsです。ターミナルで使うGitLab Duo CLIの/goalコマンド[2]で、Issueを基にナイトモードを実装し、ローカルで単体テストを実行するよう指示しました。テストに問題がなければ、アプリケーションを起動してブラウザーで開くところまでを目標に含めていました。

佐々木氏は、開発者のPC上でテストやアプリケーションの起動まで進められることを、CLIの強みとして挙げました。デモでは、エージェントが実装とともに新しいテストを追加し、既存のテストも実行しました。実行結果の画面には、全63件のテストが通過したと表示されていました。

佐々木氏はさらに、目標の設定次第では、変更をマージリクエストに反映し、CIの実行や失敗時の修正まで任せる使い方もできると説明しました。

チーム独自の手順をカスタムフローにする

佐々木氏は続いて、脆弱性に対応するために依存ライブラリを更新する場面を取り上げました。セキュリティスキャンやコードレビューに加え、これまで人が行っていた影響調査も自動化する狙いです。そのために使ったのが、チーム独自の手順を定義できるカスタムフローです。マージリクエストの作成などのイベントをきっかけに、決めておいた処理をAIに実行させられます。

手順はYAML形式で記述します。これを一から書く負担を減らすため、佐々木氏は自然言語から定義を生成するFlow Creatorを使いました[4]。GitLabのチャット画面でFlow Creatorを選び、日本語で要件を入力しました。依頼したのは、リリースノート、コード中の利用箇所、既存のテストなどを調べ、更新の影響とリスクを報告するフローの作成です。生成された定義を、カスタムフローの設定欄に貼り付けて登録しました。

次に佐々木氏は、JavaのテンプレートエンジンThymeleafを更新するマージリクエストを開きました。そのコメント欄で、先ほど登録したフロー用のアカウントを@付きでメンションしました。それに対して、フローを開始したという返信が付き、エージェントが変更内容と関連情報を調べ始めました。

調査結果のコメントには、影響を受けるコードの箇所や、確認すべき画面が挙げられていました。エージェントは、パッチバージョンの更新で、調べた範囲では破壊的変更の記載もなかったことから、リスクを「低」と評価しました。あわせて、CIでのビルド・テストや画面表示の確認を勧めていました。

AIの利用コストを抑え⁠、効果を確かめる

デモを受けて、藤田氏は「データ＆コンテキスト」の層に話を進めました。開発のさまざまな工程でAIが使われ、利用者も増えると、利用コストが膨らみます。その対策として挙げたのは、作業に適したモデルを選ぶこと、モデルに渡す情報を整えること、費用に見合う効果が得られているかを測ることの3点です。

モデルについては、GitLabがホストする高性能なモデルや、モデルの重みが公開されているオープンウェイトモデルに加え、BYOM（Bring Your Own Model）が紹介されました。BYOMでは、自社で運用するモデルや、自社で契約している外部サービスのモデルにGitLabのエージェントを接続します。

藤田氏は、オープンウェイトモデルをコスト効率を高めるための新たな選択肢として挙げました[5]。会場で示されたGitLabのベンチマークでは、MiniMax M3はGPT-5.5に近いタスク完了率を示し、AI利用の課金単位であるGitLabクレジットあたりのモデル呼び出し回数はGPT-5.5の約8倍でした。

次の対策は、モデルに渡す情報を整えることです。エージェントが必要な情報を見つけられないと、検索や推測を繰り返すうえ、不正確な回答を受けた利用者が依頼をやり直すこともあります。そのたびに処理が増え、費用もかさみます。藤田氏がこの無駄を減らす機能として紹介したのが、GitLab Orbitです。

Orbitは、コードやIssue、マージリクエスト、パイプラインなどの情報を、データ同士のつながりを表すグラフ構造で管理します。脆弱性やデプロイ、チームの情報も結び付け、エージェントの判断に必要な背景情報（コンテキスト）を提供します。この関係をたどって必要な情報を絞り込むことで、エージェントが大量のデータを読み込み、手掛かりを探す負担を減らす仕組みです。

スライドでは、GitLabのエージェントに加え、Claude CodeやCodexなどの外部エージェントにもコンテキストを提供する構成が示されました。藤田氏は、Claude CodeでOrbitの有無を比べ、必要なコンテキストを得るためのトークン消費量が4.5分の1になった検証結果も紹介しました[6]。

費用と効果を確認するための機能が、Duo Agent Platform Impact Analyticsです[7]。チーム、タスク、モデルごとの利用コストを、マージリクエストやレビューなどの開発状況とあわせて確認できます。藤田氏は、どの作業で費用がかかり、適切なモデルが使われているかを、実際のデータで確かめることが重要だと説明しました。

パッケージの安定供給と安全な取り込みを支える

続いて藤田氏は、エージェントの速度に対応できるビルド基盤の話に移りました。ソフトウェアの多くは、既存のパッケージやライブラリを組み合わせて作られます。コード生成を速めても、それらを取得して組み立てるビルドが失敗すれば、リリースは速まりません。ビルドの実行回数が増えれば、こうした失敗への対処に加え、取り込むパッケージの安全性を確認する負担も増えます。藤田氏は、人手だけで対応するのは難しくなると説明し、パッケージ管理のArtifact Central[8]と、依存パッケージの取得をポリシーで制御するDependency Firewall[9]を紹介しました。

Artifact Centralでは、複数のパッケージリポジトリを仮想リポジトリにまとめ、ビルド側の取得先を一つにできます。まとめる対象は、自社のパッケージを置くホスト型リポジトリや、外部のパッケージを取得・キャッシュするリモートリポジトリです。GitLabのCI/CDで生成して登録した成果物については、生成元のビルドも追跡できます。

パッケージの取得先を集約し⁠、利用状況を把握する

Artifact Centralのデモを担当したのは、GitLab合同会社のシニアソリューションアーキテクト、小松原つかさ氏です。

小松原氏が取り上げたのは、外部から依存パッケージを取得できず、Mavenのビルドに失敗した例です。複数のリポジトリを仮想リポジトリにまとめ、検索する順序を設定した後、Mavenの設定ファイルでパッケージの取得先を切り替えました。取得先をGitLab側でまとめて管理し、各チームが個別に設定を保守する負担を減らす狙いです。

キャッシュを使うと外部からの再ダウンロードが不要になり、ビルドを速め、配布サーバーやネットワークの障害の影響も抑えられます。録画デモでは、パイプラインの所要時間がキャッシュなしの8分28秒から、キャッシュありの3分9秒に短縮されていました。

小松原氏は続いて、パッケージに脆弱性が見つかった際に、影響を受けるプロジェクトを探すデモを行いました。GitLab Duoのチャットでパッケージの利用先を尋ねると、プロジェクト、利用バージョン、関連するパイプライン、担当者が示されました。回答によると、Orbitに該当する依存関係の情報が見つからず、コード検索で利用先を特定していました[10]。

組織のポリシーでパッケージの取り込みを制御する

Dependency Firewallでは、脆弱性や悪意のあるパッケージ、ライセンスなどに関するポリシーを設定し、ビルドに取り込むパッケージをチェックします。

パイプラインで利用する場合は、GitLab CLI（glab）のチェックを各パイプラインに組み込む必要があります。

小松原氏は、問題のあるパッケージを検出した際に、警告にとどめるか、取得をブロックするかを選ぶ設定画面を示しました。すぐに利用を止められない場合など、組織の事情に合わせて選べます。

複数のプロジェクトをまとめるGitLabのグループにポリシーを設定すると、配下のサブグループやプロジェクトにも適用されます。例外として扱うユーザーや認証用のトークンを指定する項目もありました。

続くデモでは、パッケージの取得がブロックされてパイプラインが失敗し、ジョブログに対象のパッケージと理由が表示されました。

ダッシュボードではチェック件数や防いだ問題の内訳を、監査ログでは取得を許可・ブロックした理由を確認できました。小松原氏は、大量のパイプラインが動くなかで、こうした記録を後から証拠として示せることが重要だと説明しました。

開発⁠・ビルド環境のシークレットを保護する

パッケージ管理のデモに先立ち、藤田氏は開発・ビルド環境にあるAPIキーなどの秘密情報（シークレット）の保護も取り上げていました。本番環境に比べ、開発者のPCやビルド環境ではシークレットの保護が見落とされがちだと指摘しました。強い権限を持つキーが、開発環境からエージェントを経由して広い範囲のCIジョブに渡るリスクもあります。その対策として紹介されたのが、シークレットを管理するGitLab Secrets Managerです[11]。

スライドでは、パイプラインと共通のID・権限を使い、ブランチや環境などに応じてシークレットの利用範囲を決める構成が示されていました。シークレットは、利用を宣言し、設定された条件を満たすジョブにだけ渡されます。読み出しの記録がパイプラインやジョブのIDと結び付くため、どのジョブがシークレットを使ったかも追跡できます。

藤田氏は、安全に保管するだけでなく、漏洩を早く見つけて対処することも重要だと説明しました。GitLabのシークレット検出機能などと組み合わせ、漏洩の検出から、値の更新（ローテーション）と保存、参照箇所を直すマージリクエストの作成までを進める例を示しました。

エージェント時代のセキュリティをどう確保するか

小松原氏によるパッケージ管理のデモが終わると、藤田氏はここまで紹介した機能を振り返り、Governed Software Factoryが目指すのは、AIによる開発の高速化とガバナンスの両立だと述べました。

最後に取り上げたのは、エージェント時代のセキュリティです。藤田氏は、日本国内でも深刻な機密情報漏洩が報じられていることに触れ、セキュリティインシデントが社会問題になりつつあると述べました。

藤田氏は、開発側では大量に生成されるコードのレビューが追い付かず、攻撃側ではAIによる脆弱性の発見や悪用が速まっていると説明しました。両方が同時に進むなか、人の手だけでは対応が難しくなると指摘しました。

スライドで示したGitLabの脆弱性情報（CVE）の公開件数は、2025年の181件に対し、2026年は登壇時点で317件でした。また、Verizonの調査を基に、悪用が確認されている脆弱性にパッチを適用するまでの日数（中央値）が、2025年レポートの32日から2026年レポートでは43日に延びたことも紹介しました。藤田氏は、脆弱性が多く見つかるようになっても、修正が追い付かなければ対抗できないと説明しました。

対策として挙げたのは、攻撃側と同等以上の能力を持つモデルを開発プロセスに取り込み、脆弱性の発見から修正までを速く回すことです。その具体策として、Anthropicとの提携を通じ、Claude Mythos 5および5.1を組み込んだGitLab Duo Agent Platformのセキュリティフローを紹介しました[12]。

さらに藤田氏は、AIエージェントにどこまで作業を任せられるかという問いに、社内でも向き合ってきたと話しました。その成果として紹介したのが、GitLab Security Standardです。ポリシー、証拠となる記録、責任の所在を共通の土台とし、エージェントに作業を任せるための対策を次の5項目に整理しています。

1. 認可：作業する人やエージェントの把握と、行動できる範囲の限定
2. 分離：作業環境を隔離し、取り込む情報や使うツールを制限して、問題の影響を作業の範囲内にとどめる対策
3. 検証：セキュリティ検査や承認の仕組みを、評価される側の人やエージェントによる変更・省略から守る対策
4. リリース：検証したものと同じ成果物のリリース
5. 対応：問題発生時の停止、経緯の追跡、復旧

藤田氏は、この枠組みを一度にすべて取り入れる必要はなく、組織の成熟度に合わせて段階的に取り入れられると説明しました。