今月もAI業界ではさまざまな出来事がありましたが、その理由は必ずしも予想どおりではなく、「速いだけでは十分ではない」ということを改めて認識させられる出来事がありました。

大きく報じられたのは、あるAIモデルが目的を達成しようとして管理された評価環境から逸脱し、サイバーセキュリティのベンチマーク中に外部インフラへ影響を及ぼした前例のない事例です。

この出来事は、多くのエンジニアリングリーダーがすでに実感していることを改めて示しました。

AIの未来を決めるのは、エージェントが「何ができるか」ではありません。

「何をすべきか」を、私たちがどう統制するかです。

今月のMonday Mergeは、まさにこのテーマから始まります。

今回は、企業がAIの実験段階を超え、その先にある「実際のビジネス価値」「より強固なガバナンス」、そして人とAIエージェントが自信を持ってソフトウェアを開発するために欠かせない「コンテキスト」に焦点を当てます。

それでは見ていきましょう 🤿

新しいForrester調査：エージェント型ソフトウェア開発がもたらすビジネス価値

「AIは本当にビジネス価値を生み出しているのか？」

そう感じている方は、GitLab Duo Agent Platformを対象とした最新のForrester Total Economic Impact™（TEI）調査をぜひご覧ください。

実際にGitLab Duo Agent Platformを導入している企業へのインタビューをもとに、次のような効果が見込まれることが明らかになりました。

• ROI（投資対効果）400%
• 開発者の生産性20%向上
• セキュリティ修正作業を40%削減
• 新規開発者のオンボーディングを80%高速化
• 投資回収期間は6か月未満

数字も印象的ですが、それ以上に重要だったのは次のメッセージです。

“企業は単にコードを書くスピードを上げているのではありません。

エンジニアリングに費やす時間を取り戻し、手作業を減らし、開発者がより価値の高い課題に集中できるようになっています。”

まだ読まれていない方には、ぜひダウンロードをおすすめします。

エージェント型ソフトウェア開発が実際の現場でどのような成果を生み出しているかを示す、非常に分かりやすい調査です。

👉 Forrester TEI調査はこちらからダウンロード

GitLab 19.2がリリース

GitLab 19.2では、エージェント型ソフトウェア開発のビジョンをさらに推し進める新機能が追加されました。

開発者が繰り返し作業に費やす時間を減らし、より多くの時間をソフトウェア開発に充てられるよう支援すると同時に、エンタープライズに求められるガバナンスも実現します。

主な新機能をご紹介します。

💻 GitLab Duo CLIが正式リリース

GitLab Duo Agent Platformをターミナルから直接利用できます。

パイプライン障害の診断やコードベースへの質問、問題解決まで、コマンドラインを離れることなく行えます。

🔄 日常業務を再利用可能なAIワークフローへ

カスタムフローが正式リリース。

複数ステップにわたるソフトウェア開発プロセスを、自動化されたワークフローとして再利用できるようになりました。

承認フローや人が介在するチェックポイントも組み込めます。

🛡️ コードを理解する、より高度なセキュリティレビュー

新しいセキュリティレビューフローは、従来のスキャナーとは異なり、「コードが何を実現しようとしているのか」を理解した上で解析します。

そのため、パターンマッチングだけでは検出できない業務ロジックの欠陥や認可の問題も見つけ出せます。

⚡ 開発スピードを落とさないセキュリティ修正

依存関係スキャン自動修正では、脆弱な依存関係が見つかると、自動でマージリクエストを作成。

更新によって互換性の問題が発生した場合も、GitLab Duoが原因を分析し、修正を適用し、パイプラインが成功するまで自動的に再実行します。

開発を止めることなく、セキュリティ負債の削減を支援します。

🔍 AIのすべての操作を可視化

AIエージェントの利用が広がる中、生産性だけでなくガバナンスも重要になっています。

新しいAI監査イベントレポートでは、GitLab Duoのすべてのセッションをダウンロード可能な監査ログとして保存。

セキュリティ・コンプライアンス担当者は、「何が」「なぜ」「どのポリシーのもとで」実行されたのかを把握できます。

コード作成からマージリクエストレビュー、セキュリティ強化、自動化まで、GitLab 19.2はソフトウェア開発ライフサイクル全体にインテリジェントな支援を提供します。

👉 GitLab 19.2のリリースノート・注目機能・デモ・ブログはこちら

デモを見逃した方へ

GitLab Transcend Londonでは、GitLabが描くエージェント型ソフトウェア開発の未来が数多く紹介されました。

参加できなかった方や、もう一度見返したい方のために、基調講演やデモをまとめています。

主な内容はこちらです。

• 次世代Source Code Management（エージェント時代に最適化）
• GitLab Orbit（開発ライフサイクル全体にわたるリッチなコンテキストを提供）
• Governance for Agents（AIエージェント向けのID・ポリシー・監査・承認）
• GitLab Flex（AI導入に合わせた新しいライセンスモデル）

AI活用を始めたばかりの企業から、大規模展開を進める企業まで、今後のソフトウェア開発の方向性を知ることができる内容です。

👉 Transcendのハイライトとデモはこちら

お客様事例：Mercedes-Benz

Transcendで特に印象に残ったセッションの一つが、Mercedes-Benzによる講演でした。

同社は、GitLabを活用しながら20,000人以上のエンジニアによるソフトウェア開発を変革しています。

印象的だったのは、その規模だけではありません。

AIエージェントは、与えられるコンテキストの質によって初めて力を発揮します。

そして、安全性が求められるシステムでは、人間が最終的な責任を持ち続けることの重要性を強調していました。

AIが開発を加速し、人間が重要な意思決定に責任を持つ。

これこそが、業界が向かっている未来を象徴するセッションでした。

Black Hat USAを開催しました

8月といえば、Black Hat USAです。

GitLabは今年も参加しました。

最新のサイバーセキュリティ研究に触れ、業界の専門家と交流し、AI時代の安全なソフトウェア開発について議論できる絶好の機会でした！

今月のおすすめコンテンツ

今月もおすすめの記事やコンテンツが数多くありますが、特におすすめしたいのは次の2つです。

• Manav Khurana AIアカウンタビリティが、現代のソフトウェア開発における最重要課題になりつつある理由を解説しています。AI生成だけでなく、ガバナンスの重要性にも焦点を当てています。
• Andrew Haschka（Cyber Voices Podcast） AI、ソフトウェアデリバリー、そしてDevSecOpsの次なる進化について語っています。

そのほかにも、今月のおすすめ記事をぜひチェックしてみてください。

最後に

スパイ小説家ジョン・ル・カレ氏は、こんな言葉を残しています。

「あらゆる作戦には、『表の仕事』と『裏の仕事』がある。表はマニュアルどおりに行うこと。裏は、その仕事をどうやってやり遂げるかだ。」

この言葉は、今のAI時代にも驚くほど当てはまります。

AIエージェントが信頼できる開発パートナーになりつつある今も、ガバナンスやポリシー、承認プロセスは欠かせません。

しかし、本当に差を生むのは単にルールを守ることではなく、人とAIが正しい判断を下せるだけのコンテキストを提供することです。

AIで成功する組織は、最も多くのAIエージェントを導入している企業ではありません。

AIを支える適切な仕組みを構築している企業なのです。

最後までお読みいただき、ありがとうございました。 今月号が、皆さんのチームで新しい取り組みを考えるきっかけになれば幸いです。 それでは、また次回お会いしましょう。

それでは、Happy Merging!

Fatima Sarah Khalid｜Senior Developer Advocate, GitLab

このニュースレターが気に入ったら、ぜひチームに共有してください。 そして👉YouTubeチャンネルの登録もお忘れなく！

実際に開発現場でMCPサーバーの活用を検討している担当者も多いのではないでしょうか。

この記事では、MCPサーバーの基礎知識や仕組み、メリット、注意点などを詳しく解説します。ソフトウェア開発における活用例やポイントも紹介するので、ぜひ参考にして下さい。

1. MCPサーバーの基礎知識

そもそも「MCP」とは、「Model Context Protocol（モデル・コンテキスト・プロトコル）」の略語であり、LLMを利用する AIアプリケーションと外部システムを安全かつ効率的につなげるための標準プロトコルのことです。2024年11月にAnthropic社によって開発され、AIアプリケーションがさまざまなデータソースやシステムに接続するための方法を提供しています。

そしてMCPサーバーはMCPの共通規格に沿って、実際にAIアプリケーションと外部システムをつなぐための接続用のプログラムを指します。

なお、MCPサーバーとAPIにははっきりとした違いがあります。APIは、異なるシステム間でデータをやりとりするための汎用的な仕組みであり、人間（開発者）が操作することを前提に設計されています。一方MCPサーバーは、AIアプリケーションに特化した仕組みで、「手足」のような位置付けになります。これにより、エージェントをはじめとした AI アプリケーションが「自律的に判断・操作すること」が可能になります。

2. MCPサーバーが注目されている背景

なぜMCPサーバーはソフトウェア開発の領域を含め、さまざまな業務シーンで注目されているのでしょうか。その背景や理由は「AIと外部システム連携に対するニーズの高まり」と「AI連携に伴う開発・保守コスト削減の必要性」にあります。

これまでのAIの業務活用においては生成AIと会話して「学習済みのAIに対して指示を出し、アウトプットされた情報を参照・活用する」という使い方が中心でしたが、現在はAIエージェントと呼ばれる自律型AIの普及により、「AIに特定のツールを操作させて業務を自動化したい」といった外部システム連携のニーズが高まっています。

しかし、AIと外部システムの連携においては、各ツールのAPI仕様が異なるため、接続のたびに毎回個別での対応が必要になるというコスト面での課題が浮き彫りとなっていました。接続したいツールが増えるほど保守コストも増大し、安全な運用が難しいこともあり、こうした課題がAI活用の障壁となっていたのです。

MCPサーバーは「プロトコル」であり共通的な通信規格を定めているため、この規格に準拠したプログラムを利用することでAIと外部システムの連携を効率化できることからさまざまな業務シーンにおいて活用されているのです。

3. MCPサーバーの仕組み

MCPサーバーは具体的にどのような仕組みで動作するのでしょうか。ここでは、以下を踏まえてMCPサーバーの全体像を掴みましょう。

• MCPホスト・クライアントとの関係性
• MCPサーバーが提供する主要機能
• MCPサーバー利用時の処理フロー
• MCPサーバーの通信方式

3-1. MCPホスト・クライアントとの関係性

MCPは「MCPホスト」「MCPクライアント」「MCPサーバー」の3つの役割で構成されており、MCPサーバーはMCPホストとMCPクライアントの通信を仲介する役割を担います。

MCPホストは、ChatGPTやCursor、Claude DesktopなどのAIアプリケーション本体を指し、ユーザーからの指示を受け取り、必要な処理を判断します。

MCPクライアントは、MCPホスト内でMCPサーバーと1:1 のコネクションを張って通信を行う役割を担います。

3-2. MCPサーバーが提供する主要機能

MCPサーバーがAIに提供する主要機能として以下の3つがあります。

• ツール（Tools）
• リソース（Resources）
• プロンプト（Prompts）

3−2−1. ツール

MCPサーバーのツールは、AIが外部システムを操作するための機能を指します。つまり、AIが能動的に「何らかの操作」を実行するための仕組みです。

例えば、以下のようなアクションを提供します。

• Web APIの呼び出し
• データベースの操作
• メッセージ送信
• ドキュメント作成・検索
• 計算の実行 など

3−2−2. リソース

リソースは、AIが参照できるデータを提供する機能です。つまり、AIがデータを読み込むための機能になります。

例えば、以下のようなデータをAIに提供します。

• 設計書や仕様書などのドキュメント
• ソースコード
• Issue
• CIログ など

AIはこれらのデータを参照し、意思決定やアウトプットに利用します。

3−2−3. プロンプト

プロンプトは、AIに対して「どのような処理を実行するか」を指示する対話テンプレートです。あらかじめよく使用する指示をサーバー側で事前に設定できます。

例えば、コードレビュー依頼やバグ調査などの定型的な指示をテンプレート化できるため、開発チーム全体で効果的なプロンプトを再利用することが可能です。

3-3. MCPサーバー利用時の処理フロー

実際にMCPサーバーを利用した際、AIはどのように動作するのでしょうか。簡潔にまとめると以下のような流れになります。

1. ユーザーがAI（ホスト）に対して特定の指示を出す
2. ホスト内のクライアントがMCPサーバーへ利用可能なツールやリソースを問い合わせ、MCPサーバーからの返答を受ける
3. AIが使用するツールを判断し、クライアント経由でMCPサーバーへリクエストを依頼する
4. MCPサーバーはリクエストに従って処理を実行し、結果を生成する
5. MCPサーバーからクライアント経由で、AIに結果が返される
6. AIが最終的な回答を生成し、ユーザーへ情報を返す

3-4. MCPサーバーの通信方式

MCPサーバーの通信方式には「ローカル版」と「リモート版」の2つの種類があります。ここではそれぞれの特徴について解説します。

3-4-1. ローカルサーバー

ローカルサーバーは、ユーザー個人のマシン上で直接動作するMCPサーバーのことです。インターネット環境に依存することなくオフラインで処理を実行できることから、作業の継続性やパフォーマンスを維持することが可能です。

ただし、ローカル環境であるため、チーム全体で活用する場合は適していません。

3−4−2. リモートサーバー

リモートサーバーは、クラウドなどインターネットや閉域環境など、何らかのネットワーク上で稼働しており、処理を実施するMCPサーバーを指します。リモートサーバーなら個別マシンでの設定が最小限で済み、ネットワーク上で稼働するため、チーム全体で共通のMCPサーバーを利用できます。

ただし、ネットワーク経由でデータ通信を行うため、接続状況によってはAIの処理スピードに影響が出る可能性があります。また、情報漏えいや不正アクセスを防止するために適切なセキュリティ対策が必要です。

4. MCPサーバーのメリット

MCPサーバーを利用することで以下のようなメリットを享受できます。

• 開発効率の向上
• AIの処理能力の向上
• 柔軟かつ拡張性のあるAI活用の実現

4-1. 開発効率の向上

MCPサーバーを活用するメリットの一つ目が、共通規格によってAIと外部システムの接続を標準化・効率化できることです。従来であれば、AIと外部システムを連携させる際にAIモデルやツールごとに個別での接続処理が求められ、開発や保守に大きな負担がかかっていました。これを「M×N問題」と呼んでいます。

MCPサーバーなら一度サーバーを構築すれば、MCPに対応した複数のAIアプリケーションに対応できるため、「M×N問題」の解消に繋げられます。これにより、開発者はソフトウェア開発における機能設計や実装など、本来注力すべき業務に専念しやすくなります。

4-2. AIの処理能力の向上

MCPサーバーの活用は、AIの処理能力の向上にも繋がります。これまでのAI活用においては、ユーザーの指示（プロンプト）に対してAIが情報提供のみを行うという受動的な処理がメインでした。

MCPサーバーを使えば、人間の指示を前提とした単一の処理だけでなく、目的に応じてAIアプリケーションが自ら考えて特定の作業を完了させることができます。

こうした処理能力の向上により、ソフトウェア開発における一連の作業工程においても自動化・効率化できる範囲が増え、開発スピードの向上に繋がります。

4-3. 柔軟かつ拡張性のあるAI活用の実現

MCPサーバーによるAIと外部システム連携においては、必要に応じて利用するAIを柔軟に切り替えられます。共通の通信ルールがあることにより、MCPに対応しているAIであれば同様のMCPサーバーで対応できるためです。

また、新しいデータソースを追加したい場合は、対応したMCPサーバーを接続するだけで済むため、拡張性にも優れています。

近年システムの大規模化や技術進化により、ソフトウェア開発プロセスが複雑化している中で、MCPサーバーが持つ柔軟性と拡張性は、開発者の負担削減に大きく貢献すると言えるでしょう。

5. MCPサーバーを活用する際の注意点

MCPサーバーの活用においてはさまざまなメリットがある一方で、注意したい要素もあります。

• 一定の学習コスト・運用ノウハウの蓄積が必要
• セキュリティリスクへの対策が必要

5-1. 一定の学習コスト・運用ノウハウの蓄積が必要

冒頭でも説明しましたが、MCPは2024年に開発された比較的新しい技術です。導入や活用の際に参考となる事例や情報がまだ少ない中で、開発者はMCPの概念や仕組みを深く理解しなければなりません。企業によっては技術者の育成や採用のためのコストが発生するでしょう。

また、技術自体がまだ発展途中の段階にあり、今後仕様変更や機能追加の発生が予想されるため、導入する際には長期的なアップデートに対応できる体制を構築する必要があります。

なお、現時点の最新情報として2026年7月28日に大きな仕様変更（2026-07-28 Release Candidate）が発生しており、最大の変更点はプロトコル層がステートレスになっていることです。詳しくは以下のページをご確認下さい。

The 2026-07-28 MCP Specification Release Candidate

5-2. セキュリティリスクへの対策が必要

MCPサーバーの活用によってAIが外部システムを操作することから、外部システムの認証情報を必要とします。つまり、セキュリティリスクが発生するため、対策を検討しなければなりません。ここでは、具体的なセキュリティ対策について解説します。

• 信頼できるMCPサーバーの活用
• 適切な権限管理とアクセス制御
• プロンプトインジェクション対策の実施

5−2−1. 信頼できるMCPサーバーの活用

MCPサーバーは概念や仕組みを理解していれば、誰でも自作することができます。中には、なりすましや、信頼を得てから悪意ある挙動へと切り替わる「Rug Pull」などを目的としたサーバーも存在します。

出所不明な怪しいMCPサーバーを安易に AI アプリケーションに連動させることはセキュリティリスクを高めてしまいます。

そのため、MCPサーバーを探す際には信頼できる発行元が提供するMCPサーバーに絞って導入を進める必要があります。

5−2−2. 適切な権限管理とアクセス制御

MCPサーバーに対して過剰な権限を付与してしまうと、AIが予期しない危険な処理を自動で実行してしまう可能性があるため、適切な権限管理とアクセス制御が必要です。

一般的なクラウド運用などで言われるような「最小権限の原則（PoLP）」は MCP サーバの利用においても適用されます。最小権限の原則とは、ユーザーやシステムに対して目的達成のために本当に必要なアクセス権限のみを付与するというセキュリティ対策における基本的な考え方になります。

例えば、Issueや実行ログを確認したいだけなら、「読み取り専用」の権限を基本とするなどの対応を行います。

また、MCPサーバーに対して付与する権限を最小限にする対策と並行して、MCPサーバーの操作対象となるシステム側をインフラ側で制御することも大切です。

なお、権限管理とアクセス制御については業務上のニーズの変化に応じて定期的な見直しを行うことも大切な取り組みです。

5−2−3. プロンプトインジェクション対策の実施

AI活用における特有のリスクとして、プロンプトインジェクション攻撃があります。プロンプトインジェクション攻撃とは、AIに対して正規のユーザーを装った不正な入力を行い、意図しない動作を引き起こすサイバー攻撃のことです。

プロンプトインジェクション対策としては、人間による確認や承認、サニタイゼーションの実装などが求められます。また、インシデント発生時にすぐに対応できるようログの記録や監視も大切な取り組みです。

6. ソフトウェア開発におけるMCPサーバーの活用例

ここではソフトウェア開発におけるMCPサーバーの活用例を紹介します。

• 要件定義・設計の効率化
• コードレビュー・品質管理の自動化
• Issue管理・タスク管理の効率化
• CI/CD・運用業務の自動化
• ナレッジ管理・情報検索

6-1. 要件定義・設計の効率化

まず要件定義書や設計書が格納されているストレージサービスやバージョン管理システムのMCPサーバーを活用することで、要件定義や設計業務を効率化できます。例えば、AIが過去の仕様書などの開発に関わる情報を参照にして、新機能の設計書のたたき台を作成するといった活用が可能です。

その他、AIに過去の類似案件を参照させて、現状の要件定義書に抜け漏れなどのミスや問題がないかを比較検証させることもできます。

AIが作成・検証したものをそのまま鵜呑みにするのは危険ですが、全体像の把握や内容のチェックなどを効率よく進められます。

6-2. コードレビュー・品質管理の自動化

前述のMCPサーバーが提供するリソースとして開発で利用されるコード規約などを AI アプリケーションに対して提供することにより、コードレビューの負担を大幅に削減することができます。

例えば、AIにコーディング規約を参照させて違反がないかどうかのチェックや、セキュリティの脆弱性の確認、バグの検出などを自律的に実行させられます。

さらにAIはコードの分析結果をもとに、改善案の提示も行うことができるため、担当者はAIの情報を参考にしながらコード品質の向上と作業の効率化を図れます。

6-3. Issue管理・タスク管理の効率化

課題管理システムやタスク管理システムのMCPサーバーを活用することで、AIがIssueやタスク情報にもアクセスできるようになるため、進捗状況の確認や管理作業の効率化も図れます。

例えば、開発途中で発生したバグ対応において未対応タスクのみを一覧で表示させたり、急な仕様変更などを理由にタスクの優先度の組み直しをさせたりといった活用が可能です。

AIの支援によって適切なIssueやタスク管理を実現できれば、複数のツールを参照する必要がなくなり、コーディングを行う流れの中で情報ソースやコンテキストとして活用できるため、スムーズにプロジェクトを進めることができるでしょう。

6-4. CI/CD・運用業務の自動化

MCPサーバーとCI/CDの自動化は相性が良く、代表的な活用例の一つです。CI/CD パイプラインを提供するプラットフォームのMCPサーバーを活用することにより、AIがCI/CDツールを直接操作・分析できるようになるため、パイプラインの実行や状況確認を効率よく行えます。

また、パイプラインが失敗した際には、AIに原因の一次調査を指示できることから、開発者によるログ確認の手間を軽減し、スピーディーな障害対応に繋げられます。

6-5. ナレッジ管理・情報検索

社内には社内Wikiや議事録などさまざまなナレッジが蓄積されているケースが多いです。

これらのナレッジを活用する際によくありがちな課題として、「対象のデータがどこに保管されているかわからない」「いつ時点のデータなのか特定できない」というような悩みが挙げられます。

MCPサーバーを活用してAIが社内ナレッジにアクセスできるようにすれば、必要な情報を素早く検索・参照することができます。これにより、例えば新人エンジニアが開発ルールを確認したい時にも、自身で必要な情報を確認できるようになるため教育コストの削減に繋げられます。また、メンバー同士のナレッジ共有や引き継ぎなどにも役立てられ、属人化の解消を実現する強い味方になるでしょう。

7. ソフトウェア開発におけるMCPサーバーの選び方

MCPサーバーには目的に応じてさまざまな種類があります。実際にソフトウェア開発において、一般に公開されているMCPサーバーを利用する場合には、選定時に以下のポイントを意識することが大切です。

• 実現したいユースケースへの対応
• 開発環境とAIツールとの互換性
• サポート体制・ドキュメントの充実度

7-1. 実現したいユースケースへの対応

まずは、自社の開発現場において目的や課題に合った機能を搭載しているかを確認します。ソフトウェア開発では多岐にわたる業務が存在するため、以下のようにどのプロセスをAIで効率化したいかを検討します。

• プロジェクト管理（Issue・タスクなど）
• コードレビュー支援
• CI/CDパイプラインの実行・原因調査
• ナレッジ共有 など

MCPサーバーごとにAIが操作できる範囲（ツール）は異なるため、実現したいユースケースを明確化した上で選定しましょう。

7-2. 開発環境とAIツールとの互換性

自社の開発環境（ツール群）や利用するAIアプリケーションと連携できるかどうかも重要な観点です。MCPサーバーによって連携できる開発ツールやAIは異なるため、互換性を事前に確認しておくと導入後の運用がスムーズです。

なお、MCPサーバーの導入を検討するタイミングで、既存の開発環境の見直しも必要に応じて行うとよいでしょう。

7-3. サポート体制・ドキュメントの充実度

MCPサーバーを長期的に安定して活用していくためには、サポート体制やドキュメントが充実していることも大切です。例えば、専用の窓口やFAQ、設定ガイドなどの有無を確認しましょう。

サポート体制やドキュメントが充実していれば、導入・運用時にトラブルや不明点が発生した場合でも迅速に対応を進められます。

また、継続的なメンテナンスやアップデートが実施されているかどうかも長期的な運用において重要なポイントです。

8. ソフトウェア開発でAIを効果的に活用するためのポイント

ソフトウェア開発におけるAI活用においては、開発ライフサイクル全体の情報に効率よくアクセスできるかという点が、AIによる成果を生み出す上で重要な要素になってきます。

というのは、実際の現場ではソースコードやIssue、CI/CDなどの多くの情報が、複数のツールに点在しているケースが少なくありません。開発情報が複数のツールに分散されていると、AIと連携する際にMCPサーバーも必要に応じて複数組み合わせる必要があり、開発者の管理負荷やセキュリティリスクを増やすことに繋がります。

多くの開発情報を一元的に管理できる開発基盤を事前に構築し、それに対応したMCPサーバーを導入すれば連携や管理もシンプルになり、AIは横断的に必要な情報にアクセスできます。

9. AI活用を前提とした開発基盤としてGitLabがおすすめな理由

上記のAI活用のポイントを踏まえて、多くの開発情報を一元管理できる開発基盤を構築し、AI連携を効率よく進めたいなら「GitLab」の導入がおすすめです。

9-1. 主要な開発プロセスを単一のプラットフォームで統合

GitLabは、ソースコード管理やタスク管理、CI/CD、セキュリティ診断などソフトウェア開発の全工程を単一のプラットフォームで統合して実行できるサービスです。そして、GitLabならソースやタスクなど開発に関わる全ての情報がGitLabに格納されます。つまり、多くの開発情報を複数のツールに分けて管理する必要がなくなり、コストや管理負担の削減に繋げられます。

GitLabで全ての開発情報を管理できるため、次で解説するGitLab MCPサーバーによるAI連携も効率よく進められます。

9-2. GitLab MCPサーバーによるAIアプリとの連携

「GitLab MCPサーバー」は、AIアプリケーションとGitLabで管理されている開発情報をつなぐためのMCPサーバーです。GitLab MCPサーバーを活用することで、AIアプリケーションがGitLabで管理しているデータソースにアクセスでき、GitLab内のデータを SSoT（Single Source of Truth）として参照しながらユーザーに代わって特定の操作を実行します。既存のGitLab内にある資産（ソースやタスクなどソフトウェア開発に関わるすべての情報）をそのまま活かすことができるため、迅速かつ高品質なソフトウェア開発の実現に繋げられます。

なお、GitLab MCPサーバーでは、CursorやClaude Code、Claude DesktopなどさまざまなAIアプリケーションとの連携が可能で、設定ガイドも用意しています。

10. MCPサーバーの今後の展望・将来性

MCPサーバーは登場して間もない新しい技術であり、その利便性からソフトウェア開発を含めさまざまな業務シーンで活用されていくと予想されます。今後も仕様の進化や対応ツールの拡大が期待され、多くの企業が導入を進めることで事例や運用ノウハウも充実していくでしょう。

また、MCPサーバーのようなAI時代の新しい技術がソフトウェア開発の領域で浸透することで、AI連携・活用をより効果的に進めていくという観点から「GitLab」のような開発情報の全てを管理できるプラットフォームの必要性も高まっていくと考えられます。

11. MCPサーバーに関するQ＆A

最後にMCPサーバーに関するよくある質問と回答を紹介します。

11-1. MCPとRAG（検索拡張生成）との違いは？

RAGは、「Retrieval-Augmented Generation」の略語で、生成AIが学習していない専門的な知識や情報を、外部の社内文書や資料などから検索して根拠ある回答を作成する技術になります。

一方、MCPはAIと外部システムを安全に接続するための標準規格であり、必要な操作や情報取得を自律的に実行させる仕組みです。

両者の技術は対立するものではなく、必要に応じて組み合わせて使うケースも見られます。

11-2. MCPサーバーが使える主なAIアプリは？

MCPサーバーに対応している主なAIアプリを挙げると以下の通りです。

• ChatGPT（対話型の生成AIサービス）
• Claude Code（コーディング支援ツール）
• Claude Desktop（Claudeのデスクトップ版）
• Cursor（エンジニア向けのコードエディタ） など

なお、実際に利用予定のMCPサーバーが対応しているAIアプリについては確認が必要です。

11-3. MCPサーバーは複数利用できる？

MCPサーバーは必要に応じて複数のサーバーを組み合わせて利用できます。拡張性に優れているため、複雑なタスクやニーズの変化に対応しやすいメリットがあります。

ただし、管理対象が増えるためセキュリティや運用負担も考慮しながらMCPサーバーの追加を行うことが大切です。

まとめ MCPサーバーを積極的に活用してソフトウェア開発の効率化を図ろう

MCPサーバーを自社のソフトウェア開発で積極的に活用することで、安全かつ効率的にAIと外部システムを連携できるようになり、多くの作業を迅速に進められます。

また、AI活用をよりスムーズに進めるには、開発情報をまとめて管理できる統合プラットフォームの導入もおすすめです。

GitLabは、ソフトウェア開発に関わるすべての情報を単一のツールで管理することができ、GitLab MCPサーバーによってGitLabで蓄積したデータとAIと連携させて、さまざまな操作を自動で実行できます。

MCPサーバーの活用を検討している企業の担当者は、ぜひGitLabの導入も検討してみてはいかがでしょうか。

お問い合わせはこちら

監修：若林 寛之 @hwakabayashi
GitLab合同会社 カスタマーサクセス本部プロフェッショナルサービス部シニア テクニカルアーキテクト

アジャイル開発を成功に導く上では、「イテレーションをうまく回せるかどうか」が重要なポイントの一つになります。

この記事では、イテレーションの意味やメリット、進め方などを詳しく解説します。アジャイル開発を支援するおすすめのツールも紹介するので、ぜひ参考にして下さい。

1. イテレーションの意味とは

イテレーション（iteration）は、「反復」や「繰り返し」を意味し、ソフトウェア開発において「設計・開発・テスト・リリース・改善」といった一連の工程を、短期間で繰り返す開発単位のことです。各イテレーションでは、実際に使用可能な成果物の完成を目指し、レビューや改善活動を行います。

このイテレーションを適切に回すことで、開発プロセスの中で早期の課題発見や、柔軟なニーズ対応などが可能になります。

2. アジャイル開発とイテレーションの関係性

アジャイル開発は、ソフトウェア開発手法の一つで、機能を小さく分割した上で機能単位ごとに短期間のサイクル（イテレーション）を回しながら開発を進めます。つまり、イテレーションはアジャイル開発の中で採用される概念であり、両者は切り離せない関係性となります。

アジャイル開発はソフトウェア開発手法であり、イテレーションはアジャイル開発を実現するための中心的な役割として機能する概念と理解しておくとよいでしょう。

イテレーションを深く理解するためには、アジャイル開発の基礎知識も網羅しておくことが大切です。以下の記事でアジャイル開発について詳しく解説しているので、あわせて参考にして下さい。

アジャイル開発とは？意味や進め方、DevSecOpsとの関係性を解説

3. イテレーションとスプリントとの違い

アジャイル開発においてイテレーションの他によく使用される言葉として「スプリント」があります。

結論、イテレーションとスプリントは、ほぼ同じ意味で使用される言葉であり、両者ともアジャイル開発における短期間の開発サイクルを指します。

細かな違いとしてはその言葉が使用されるシーン・文脈にあります。イテレーションはアジャイル全般で使われることが多く、主にエクストリームプログラミング（XP）で採用される言葉です。一方、スプリントは、「スクラム」と呼ばれるアジャイル開発のフレームワークの文脈で使われるケースが多い言葉になります。

4. イテレーションが使用されるエクストリームプログラミング (XP) とは

ここでは、イテレーションが使用されるエクストリームプログラミング (XP) の特徴やスクラムとの違いについて詳しく解説します。

4-1. エクストリームプログラミングの概要・5つの価値

エクストリームプログラミングとは、仕様変更が頻繁に発生することを前提として、変化する顧客のニーズへの対応力を高めながらプロダクトの品質向上を目指すアジャイル開発手法になります。

1990年代にケント・ベック氏らによって提唱され、エクストリームプログラミングでは重視すべき要素として以下の5つの価値を取り上げています。

4-2. エクストリームプログラミングとスクラムとの違い

スクラムとは、最大10人程度の少人数のチームで短期間のサイクル（スプリント）を繰り返しながら、プロダクトの完成を目指すアジャイル開発のフレームワークです。

エクストリームプログラミングとスクラムはどちらもアジャイル開発手法ではありますが、主に重視する要素に違いがあります。エクストリームプログラミングは、テスト駆動開発やペアプログラミングなどの技術的な手法を重視しているのに対して、スクラムはデイリースクラムやレトロスペクティブなどのイベントを通したチーム内でのコミュニケーションや、プロジェクト管理に焦点が当てられています。

5. イテレーションの目的とメリット

次はイテレーションの具体的な目的やメリットについて解説していきます。

• 顧客ニーズに対して柔軟な対応ができる
• 手戻りやミスの軽減に繋がる
• プロダクトの価値向上やチームの成長に繋がる

5-1. 顧客ニーズに対して柔軟な対応ができる

短期間の開発サイクルを繰り返し、顧客のフィードバックを受けながら開発を進めることで、顧客のニーズを満たした品質の高いソフトウェア開発を実現できます。これにより顧客満足度の向上にも繋げられるでしょう。

短いスパンで顧客からのフィードバックを受けられるため、変化が激しい市場ニーズへの対応も柔軟に行うことが可能です。つまり、ニーズが漠然としているプロジェクトや、最初から仕様変更が予想されるケースでは、アジャイル開発でイテレーションを回しながら作業を進めると対応がスムーズに運びます。

5-2. 手戻りやミスの軽減に繋がる

イテレーションは、通常1～4週間の短い期間で開発からテストまで実施するため、途中問題が発生しても大きな手戻りがなく、早い段階で対応できるメリットがあります。各イテレーション内で問題への対応が完了するため、プロジェクト全体への影響も最小限に抑えられます。

また、イテレーションを繰り返す中で、開発メンバーや顧客など関係者全員が密なコミュニケーションや振り返りを積み上げることで、、認識のズレがなくなり、大きなミスやトラブルの予防、プロセスの改善による効率化に繋げることができます。

5-3. プロダクトの価値向上やチームの成長に繋がる

1つのイテレーションが完了すると、そのまま次のイテレーションに進むのではなく、振り返りが行われます。今回のイテレーションで障害になったことや課題点を洗い出し、次のイテレーションに向けて改善策を検討することでプロダクト品質の向上を図れます。

また、イテレーションごとにチームがリアルタイムに課題に向き合うことでメンバー全員が現状を把握でき、自らの役割を主体的に判断して動けるようになります。

6. イテレーションの進め方

実際にイテレーションはどのような流れで進めるのでしょうか。ここでは、具体的な進め方について解説します。

1. イテレーションごとの要件・計画を策定する
2. 要件・計画をもとに開発を進める
3. 成果物のレビュー・テストを行う
4. 振り返りと次のイテレーションの計画

6-1. 1.イテレーションごとの要件・計画を策定する

まずは、イテレーション内で「何をやるか（何を開発するか）」「なぜそれをやるのか」を決め、具体的な目標やタスクに落とし込みます。

その際ポイントになるのが、作業を進める中で急な市場ニーズの変化に対応できるよう、取り組むべき価値のある必要最小限の要件に絞り込むことです。

また、各イテレーションの計画を立てる際には、顧客の要望も積極的に取り入れ、関係者全体で認識の擦り合わせを行った上で共通理解をつくっておくことも大切です。

6-2. 2.要件・計画をもとに開発を進める

イテレーションの計画に基づいて、実際に開発を進めていきます。その際、顧客とコミュニケーションを取りやすい体制を構築し、仕様の詳細化のやり取りや情報共有を行いながらプロジェクトを進めることが重要なポイントです。

例えば、チャットツールでプロジェクト専用のチャンネルを作成し、顧客と開発チームがいつでも直接やり取りできるような環境を構築して情報共有を行うといった方法が挙げられます。

6-3. 3.成果物のレビュー・テストを行う

イテレーション内での開発が終了したら、成果物のレビュー・テストを実施します。完成したプロダクトにおいて「正しく動作するのか」「顧客のニーズを満たした仕様になっているか」などの事項を関係者全員で確認し、改善点や課題点を洗い出します。

ここで実施するレビューやテストの内容は、次回のイテレーションに反映する必要があるため、顧客からのフィードバックを漏れなく拾い上げるなど丁寧に進める意識を持つことが大切です。

6-4. 4.振り返りと次のイテレーションの計画

イテレーションの最後には、振り返りを実施します。ここでの振り返りは、チーム連携の強化やプロジェクトの進捗管理などを目的として行います。

振り返りの際には、以下のような手法を活用しながら、現状を分析すると良いでしょう。

振り返りが終われば、これまでの顧客の要望や外部環境の変化も踏まえて改善策を改めて整理し、次のイテレーションに進みます。

7. イテレーションを成功させるためのポイント

イテレーションを成功させるためには、以下のようなポイントを意識することが大切です。

• 適切な期間と現実的な計画を立てる
• チーム内でのコミュニケーションを活性化させる
• 開発プロセスを自動化できるツールを活用する

7-1. 適切な期間と現実的な計画を立てる

イテレーションの期間は、チームメンバーの経験やスキル、顧客のニーズなどを踏まえて適切な期間を設定することが大切です。

期間が極端に短すぎるとメンバーの負担が大きくなり、反対に長すぎると問題発生時に大きな手戻りが発生したり、顧客からのフィードバックが遅れるなどイテレーションのメリットを享受できなくなります。

メンバーの負担を軽減し、スムーズに開発を進めるには、各イテレーションの開発量を偏りなく均等に配分した上で無理のない期間設定を行います。そうすることで、一定の開発ペースを保てるようになり、安定した運用を実現できるでしょう。また、一度設定した期間は、基本的に変えないことがポイントです。期間を固定化することでベロシティ（一定期間にチームがどれだけの仕事（作業量）をこなせたかを示す数字）を明らかにし、生産性の改善にも活用することができます。

7-2. チーム内でのコミュニケーションを活性化させる

イテレーションをうまく回していくためには、メンバーや顧客を含めた関係者全員での密なコミュニケーションが欠かせません。

開発途中で発生した課題や日々の進捗、顧客からの要望などプロジェクトにおける情報を共有し合える体制を構築することで、短期間のサイクルの中で問題の早期発見・改善に繋げられます。

状況共有を行うために、オンサイト顧客や集団的コードオーナーシップ、ペアプログラミングなどのプラクティスが存在しますが、よりチームでの情報共有を円滑に行うためにDaily Stand-Upなどを実施することも増えています。

7-3. 開発プロセスを自動化できるツールを活用する

アジャイル開発では短期間のサイクルを繰り返します。つまり、その特性によって繰り返し作業の量が相対的に増加するため、CI/CDなどの自動化を進めることが必須となります。

面倒な繰り返しの手作業は無駄なミスや精神的な負担を生み出すケースもあるため、自動化できるプロセスは積極的にツール活用で実現していきましょう。

イテレーション内で自動化できる作業の対象としては以下が挙げられます。

• ビルドやテスト、デプロイ
• データ入力
• コードレビュー
• プロジェクト管理 など

8. イテレーションを成功に導く開発ツールの選び方

開発を支援するツールはさまざまな種類がありますが、イテレーション内での作業を自動化し、開発の迅速化や品質の向上を実現するなら、CI/CDや開発情報の可視化・共有、セキュリティ強化などを実現できるツールを選ぶと良いでしょう。

ただし、一度にたくさんのツールを導入してしまうとチーム内での混乱や不適切な管理を招く恐れがあるため、多機能のオールインワンプラットフォームを検討するのもおすすめです。

開発ツールには無料トライアルを設けているサービスも多いため、まずは小さく試験的に導入してみましょう。

9. GitLabならアジャイル開発の実践からDevSecOpsまで一元化できる

イテレーションを効率よく回し、プロジェクトを成功に導くなら「GitLab」の活用がおすすめです。GitLabなら、アジャイル開発の実践からDevSecOpsまで一元化することが可能です。

9-1. GitLabとは

GitLabは、ソフトウェア開発ライフサイクルに必要な機能を単一のプラットフォームで活用できるDevSecOpsプラットフォームです。

多機能を搭載したGitLabを活用することで、複数のツールを使い分けて管理する必要がなくなり、開発者の負担を軽減できます。

提供形態にはSaaS版とSelf-Managed版の2種類があり、無料トライアルやドキュメント、サポート体制もご用意しているので、お気軽にお試しいただけます。

9-2. GitLabがアジャイル開発を支援する理由

GitLabはアジャイル開発と親和性が高く、開発を支援する「ソースコード管理」「プロジェクト管理」「CI/CD」「セキュリティ」など多様な機能を搭載しています。

例えば、GitLabの「イテレーション機能」を使用することで、チームはイテレーションのスケジュール全体を可視化でき、進捗を確認しながら開発を進められます。

その他、GitLab CI/CDによってビルド、テスト、デプロイといった一連の工程を自動化できるため、アジャイル開発の価値を最大化しながら品質の高いプロダクト開発を実現することが可能です。

9-3. GitLab活用事例

GitLab活用事例として、Airwallex社を紹介します。Airwallex社は、グローバルな金融プラットフォームを提供する企業で、2022年に大手航空会社を自社の顧客として迎え入れるチャンスがありました。しかし、その案件では顧客のニーズに応えるために、競合他社よりも優れたソフトウェア機能を迅速に提供する必要がありました。

そこでDevSecOpsプラットフォームのGitLabを導入し、厳しい期限がある中で迅速な反復を繰り返すことで、多数の機能開発を成功に導いたのです。Airwallex社では、GitLab活用により、チーム間のコラボレーションやコスト効率の向上も実現しています。

本事例の詳細は以下の記事をご覧下さい。

グローバルなフィンテック企業Airwallex社が、GitLabによって顧客のニーズにより迅速に対応

10. イテレーションに関するQ＆A

最後にイテレーションに関するよくある質問と回答を紹介します。

10-1. イテレーションとウォーターフォール開発の違いは？

イテレーションは、アジャイル開発で使われる短期間の開発単位を指します。イテレーションを繰り返しながら開発を進めることで、仕様変更にも対応しやすいメリットがあります。

一方、ウォーターフォール開発は要件定義から開発、テストといった一連の工程において、事前に細かな計画を立てた上で開発を進める手法です。アジャイル開発とは異なり、要件が明確でかつ、納期厳守を求められるような案件に向いています。

10-2. イテレーションがうまく回らない原因は？

アジャイル開発においてイテレーションがうまく回らないケースも発生します。考えられる原因は以下の通りです。

• イテレーションの目的が「タスクの完了」になっており、「動くプロダクト」が完成しない
• イテレーションの期間設定が不適切で開発ペースが乱れる
• メンバー同士のコミュニケーション不足による認識のズレが生じる
• 自動化できる作業が手作業のままになっている など

イテレーションが失敗してしまう時には、原因を特定し適切な対策を検討することが大切です。例えば、開発サイクルの中で手作業が多い場合、無駄なコストが発生するためうまくイテレーションが回らないでしょう。その場合は、「GitLab」のような開発ツールを積極的に活用すると良いでしょう。

10-3. イテレーション中に仕様変更があった場合はどうすればいい？

イテレーション中に顧客から新たな要望を受けるなど仕様変更が生じた場合は、基本的に対応は次のイテレーションで行います。現在のイテレーション内でその都度対応していると、開発ペースが乱れてしまうからです。

なお、セキュリティ上の重大なリスクがあるなど緊急性が高い問題が発生した場合は、作業の優先順位を調整しチーム全体で擦り合わせを行った上で、現在のイテレーション内での対応を検討します。

まとめ イテレーションをうまく回してアジャイル開発を成功させよう

イテレーションはアジャイル開発における中心的な位置付けとして使われる概念であるため、イテレーションの進め方やポイントについては事前に理解しておくことが大切です。

イテレーションをうまく回すためには、関係者同士のコミュケーションの活性化や開発ツールの導入などを実施しましょう。開発ツールの導入においては、複数のツールを導入してしまうと管理の手間やコストが発生するため、多機能を搭載したプラットフォームの活用がおすすめです。イテレーションをうまく回すことで、開発のリズムを作り、効率的かつ安定的な開発を行うことが可能です。

GitLabは、ソフトウェア開発ライフサイクルに必要な機能を搭載しており、貴社のアジャイル開発やDevSecOpsの実現を支援します。アジャイル開発を成功に導きたいと考えているなら、ぜひお気軽にお問い合わせ下さい。

お問い合わせはこちら

監修：米沢 弘樹 @hyonezawa
（GitLab合同会社ソリューションアーキテクト本部シニアソリューションアーキテクト）

GitLab Secrets Managerが、External Secrets Operator（ESO）とTerraformに対応しました。CI/CDパイプラインの外側でも、安全にシークレットを取得できるようになります。OpenBaoを基盤とするGitLab Secrets Managerは、ソフトウェアデリバリーチェーン全体でシークレットの信頼できる唯一の情報源となる存在。1つのシークレットストアを、次のすべての用途で共有できます。

• ESOを経由したKubernetesワークロード
• TerraformまたはOpenTofuの実行
• OpenBaoまたはVault CLI
• GitLabのCI/CDジョブ（バージョン19.0以降）
• Secrets Manager APIを利用した外部の自動化処理

Kubernetes：External Secrets Operator

ESOは、Vaultプロバイダーを介してGitLab Secrets Managerからシークレットを同期します。流れはシンプルです。クラスター内のワークロードが有効期間の短いJSON Web Token（JWT）を保持し、ESOがそれを使ってOpenBaoに認証。取得したシークレットは、Kubernetes Secretへ書き込まれます。

SecretStoreは、「どこからシークレットを取得し、どう認証するか」をESOに伝えるためのリソースです。GitLab Secrets ManagerはVault互換のKV v2 APIを公開しているため、設定にはVaultプロバイダーを指定します。namespaceフィールドが対応するのはGitLabの階層（Organization、グループ、プロジェクト）で、このストアから参照できるシークレットの範囲を決めるもの。認証に使うのは、GitLabが発行しKubernetes Secretに格納したJWTです。secretRefから参照します。

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gitlab-secrets-manager
  namespace: my-app
spec:
  provider:
    vault:
      server: https://secrets.gitlab.com      # provider.vault.server
      path: secrets/kv                        # provider.vault.path
      version: v2
      namespace: org_5/group_42/project_99    # provider.vault.namespace
      auth:
        jwt:
          path: api_jwt/cel                   # provider.vault.auth.jwt.path
          role: all_api                       # provider.vault.auth.jwt.role
          secretRef:
            name: gitlab-access-token         # Kubernetes secret holding the minted token
            key: token

ExternalSecretで定義するのは、「どのシークレットを取得し、どこに配置するか」です。先ほど作成したSecretStoreを参照し、リモートのシークレットをKubernetes Secretへマッピングします。あとはワークロードから、マウントまたは環境変数として参照するだけ。

ターゲットとなるシークレット（synced-secret）を作成し、管理するのはESOです。refreshIntervalで指定した間隔ごとにGitLabから再取得するため、値をローテーションしても再デプロイは不要。data配下の各エントリは、リモートのシークレット1つをターゲット側のキー1つに対応付けます。remoteRef.keyがGitLab Secrets Manager上のパス、propertyがそのシークレット内のフィールド、secretKeyがKubernetes側での格納先キーです。

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: my-secret
  namespace: my-app
spec:
  refreshInterval: 45m
  secretStoreRef:
    name: gitlab-secrets-manager
    kind: SecretStore
  target:
    name: synced-secret
  data:
    - secretKey: value
      remoteRef:
        key: explicit/<secret_name>           # <secrets_path>/<secret_name>
        property: value

GitLab Secrets ManagerとESOを実際に組み合わせる手順は、チュートリアルで紹介しています。

Infrastructure as Code：TerraformとOpenTofu

Terraformのstateや.tfvarsファイルは、認証情報の流出経路になりやすい場所です。シークレットがそのままディスクに書き出されたり、気づかないうちにバージョン管理へコミットされたりするためです。回避策となるのが、GitLabのシークレットをデータソースとして読み込む方法。planやapplyの実行時に発行したJWTで認証します。Terraformから直接参照する形にすれば、.tfvarsファイルにもCI/CD変数にも認証情報を残さずに済みます。

data "external" "gitlab_secrets_token" {
  program = ["bash", "${path.module}/scripts/mint_token.sh"]

  query = {
    project_id = var.gitlab_project_id
  }
}

provider "vault" {
  address   = data.external.gitlab_secrets_token.result.server
  namespace = data.external.gitlab_secrets_token.result.namespace

  auth_login_jwt {
    mount = data.external.gitlab_secrets_token.result.auth_path
    role  = data.external.gitlab_secrets_token.result.role
    jwt   = data.external.gitlab_secrets_token.result.jwt
  }
}

data "vault_kv_secret_v2" "my_secret" {
  mount = data.external.gitlab_secrets_token.result.mount
  name  = "${data.external.gitlab_secrets_token.result.secrets_path}/<secret_name>"
}

output "secret_value" {
  value     = data.vault_kv_secret_v2.my_secret.data["value"]
  sensitive = true
}

Terraformでシークレットを読み取る方法は、ドキュメントで詳しく解説しています。

コマンドライン：OpenBaoまたはVault CLI

すべてのワークフローがAPIを直接呼び出すわけではありません。Vault互換のツールを前提にスクリプトを組んでいるチームなら、OpenBaoまたはVault CLIがそのまま使えます。手順はVaultから読み取るときと同じ。GitLab Secrets Managerのシークレットをそのまま取得できます。

export VAULT_ADDR="<server>"
export VAULT_NAMESPACE="<namespace>"

# Exchange the minted JWT for an OpenBao token, then export it.
vault write "auth/<auth_jwt_path>/login" role=<role> jwt=<token>
export VAULT_TOKEN="<client_token>"

# Read the secret value.
vault kv get -mount=<path> "<secrets_path>/<secret_name>"

Secrets Manager APIを使うケース

GitLab CI/CD、Kubernetes、Terraformのどれにも当てはまらない自動化には、Secrets Manager APIという選択肢があります。認証情報をハードコーディングしたり、変数ファイルを別途用意したりしなくても、任意の外部システムからSecrets Managerのシークレットを取得できます。

# Request JWT token using Service Account
RESPONSE=$(curl --silent --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/<project_id>/secrets_manager/access_token")

SERVER=$(echo "$RESPONSE" | jq --raw-output .provider.vault.server)
NAMESPACE=$(echo "$RESPONSE" | jq --raw-output .provider.vault.namespace)
MOUNT=$(echo "$RESPONSE" | jq --raw-output .provider.vault.path)
SECRETS_PATH=$(echo "$RESPONSE" | jq --raw-output .provider.vault.secrets_path)
AUTH_PATH=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.path)
ROLE=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.role)
JWT=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.token)

# Exchange the JWT for a short-lived OpenBao token.
VAULT_TOKEN=$(curl --silent --request POST \
  --header "X-Vault-Namespace: $NAMESPACE" \
  --data "{\"role\":\"$ROLE\",\"jwt\":\"$JWT\"}" \
  "$SERVER/v1/auth/$AUTH_PATH/login" | jq --raw-output .auth.client_token)

# Read the secret value.
curl --silent \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --header "X-Vault-Namespace: $NAMESPACE" \
  "$SERVER/v1/$MOUNT/data/$SECRETS_PATH/<secret_name>"

始めるには

GitLab Secrets Managerは、PremiumおよびUltimateのお客様向けにパブリックベータとして提供中です。ESO、Terraform、APIによるシークレットへのアクセスに対応しているのは、現時点でGitLab.comとGitLab Self-Managed。GitLab Dedicatedへの対応も近日中を予定しています。

ベータ期間中は無料でご利用いただけます。一般提供の開始後は、GitLabクレジットによる課金対象の有料機能となる予定。課金が始まる前にはオプトインが必要で、事前にご案内します。

まずはドキュメントをご覧ください。足りない点やご要望があれば、こちらのイシューへお寄せください。一般提供に向けて、フィードバックを集めています。

GitLab Duo Self-Hostedのモデルプロバイダーとして、Privatemode AIを利用できるようになりました。Privatemodeは最先端のモデルをコンフィデンシャルコンピューティング対応のハードウェア上で動かします。プロンプトもソースコードも生成結果も、推論の最中を含めてエンドツーエンドで暗号化されたままです。設定は、GitLab DuoのAIゲートウェイをPrivatemodeプロキシに向けるだけ。開発者が使えるDuoの機能は、ほかのモデルを使う場合と変わりません。違うのは一点、規制業界の組織にとって最も重要な点です。コードが暗号化された境界の外に出ることはなく、第三者がそれを読むこともできません。

規制業界のチームだけが手にできない生産性

AIによるコーディング支援は、すでに自動補完の域をはるかに超えています。GitLab Duo Agent Platformが担うのは、複数のステップにまたがる作業です。マージリクエストのレビュー、ファイルをまたいだリファクタリング、テストの生成と実行、CIジョブとしてのエージェントフローの実行など、その範囲は広がり続けています。これはチームの開発の進め方そのものを変える変化であり、効果は使うほどに積み上がります。実際に導入したチームは、レビューが速くなり、定型作業にかける時間が減っています。

ただし、これらの機能はどれもプロンプトとソースコードをモデルプロバイダーに送ります。プロプライエタリなコード、規制対象のソフトウェア、機密性の高い知的財産を扱うチームにとっては、それだけで検討の対象から外れてしまいます。

規制業界の組織がセルフホストを選ぶ理由

こうした組織にとって、ソースコードは事業の中核をなす知的財産です。それをどこで処理するかは、利便性の問題ではなく、契約上・業界上・規制上の問題になります。銀行のトレーディングアルゴリズム、医療機器メーカーのファームウェア、防衛関連企業の制御ソフトウェア。これらを外部のAIサービスに送れば、知的財産の保護、データ処理契約、業界規則を一度に破りかねません。

しかも、圧力は複数の方向から同時にかかります。NIS2とデジタルオペレーショナルレジリエンス法（DORA）は、重要インフラと金融サービスに対して、運用のレジリエンスとサードパーティリスクの要求水準を引き上げました。GDPRは、コードやログに含まれる個人データの扱いを規定します。ドイツ金融業界におけるBaFinの監督、調達基準としてのBSI C5、医療データの規則など、業界ごとの制度も独自の制約を課します。加えて欧州では、特定の規制の有無にかかわらず、データ主権を最優先の要件と位置づける組織が少なくありません。

影響が最も大きいのは、金融サービス、ヘルスケア・製薬、防衛、公共部門、重要インフラです。GitLab Self-Hostedは、まさにこうしたコードを信頼された境界の内側にとどめるために存在しています。AIを組み込んだ結果その前提が知らないうちに崩れるようでは、本末転倒です。

なぜAIはセルフホストと相性が悪いのか

AIコーディング支援を導入したいセルフホストのチームには、従来3つの選択肢がありました。ただし、どれも規制業界のユーザーには支払いにくいコストを伴います。

表のとおり、パブリックAI SaaSとVPCはいずれもコードを外部に露出させ、契約上の保証に頼ることになります。自前でスタックを運用すればコードは手元に残りますが、GPUとモデル運用の負担が重くのしかかります。

もう少し率直に書きます。パブリックSaaSは、コードが社外に出る時点で検討対象外です。VPCで隔離したサービスやプライベートクラウドは露出を減らせますが、平文が運用事業者と基盤クラウドに渡ることは変わりません。契約は約束であって、暗号技術による保証ではないのです。自前でモデルを運用すればコードは守れますが、導入にも人材にもコストがかかり、構造的に最良のモデルから遅れていきます。こうして多くの規制業界の組織が、AIの導入を限定的にとどめるか、まったく手をつけないという結論に至ります。

ここで問われるのは、次の点です。ソースコードを境界の外に出さず、自社でLLMスタックも抱えずに、最新のAIコーディングエージェントを開発者に届けるにはどうすればいいのか。答えるには、契約では出せない種類の保証、つまりハードウェアが強制する保証が必要になります。

コンフィデンシャルコンピューティング：アーキテクチャによる答え

コンフィデンシャルコンピューティングは、ハードウェアベースの信頼実行環境（TEE）を使い、処理中のデータを_メモリ上で暗号化したまま_扱う技術です。TEEはCPUやGPU上に設けられた隔離領域で、OSもハイパーバイザーもマシンの運用者も、その中を読み取れません。ここで使われるのは、CPU側のAMD SEVまたはIntel TDXと、GPU側のNVIDIA Confidential Computingの組み合わせです。データは転送中も保存時もAES-256で暗号化され、復号されるのはTEEの_内側だけ_です。

これを「約束」から「保証」に変えるのがリモートアテステーションです。クライアントはデータを送る前に、TEEに対して自分が何者かを証明するよう求めます。ハードウェアは、エンクレーブの中で動いているコードが何であるかを示す、署名付きの暗号学的な証跡を返します。クライアントはそれを既知の正しい値と照合し、確認できてはじめて暗号化チャネルを張り、リクエストを送ります。まず検証、そのあとに送信、という順番です。

この図は、プロンプトがクライアント側で暗号化され、暗号文のまま送られ、サービス運用事業者にもクラウドプロバイダーにも読めないハードウェアTEEの中でだけ復号される流れを示しています。

ここから得られるセキュリティ特性が、この仕組みの核心です。AIサービスの運用事業者も、基盤となるクラウドプロバイダーも、プロンプトも生成結果もコンテキストも見られません。「見ないと約束しているから」ではなく、「ハードウェアが見せないから」です。

Privatemode AI

Privatemode AIを開発しているのは、コンフィデンシャルコンピューティングソフトウェアを専門とするドイツの企業Edgeless Systemsです。NVIDIAはPrivatemodeを「プロンプトを常に暗号化したまま扱う初の生成AIフレームワーク」と紹介しています。

開発者がこの仕組みを意識する場面はありません。PrivatemodeはOpenAI互換のAPIを提供し、アテステーションと暗号化はクライアント側のプロキシが裏側で処理します。標準の/v1 APIに対応したツールやSDKは、そのまま動きます。コーディング向けの現行フラッグシップは256Kコンテキストに対応したKimi K2.6で、Kimi K3やGLMなども近く追加される予定です。

これは実験段階の話ではありません。Privatemodeは、ここまで述べてきたような制約を抱える組織で、すでに本番運用されています。Capgeminiは機密性の高いコーディングを含む規制業界の案件で使い、ドイツ連邦雇用庁は公共部門で運用しています。銀行、保険会社、防衛関連組織も、ソースコードやデータを信頼された境界の外に出せない領域で採用しています。暗号方式はポスト量子安全で、「今のうちに集めて、あとで復号する（harvest now, decrypt later）」型の攻撃にも耐えます。将来のハードウェアで解読するつもりで今日の暗号文を盗んでも、攻撃者の手には何も残りません。

統合の仕組み

GitLab Duo Self-Hostedを使えば、GitLabが管理するゲートウェイではなく、自社が管理するモデルからDuoのAI機能を提供できます。Privatemodeは、その「自社が管理するモデル」として組み込まれます。

流れはシンプルです。GitLab DuoはセルフホストのAIゲートウェイと通信し、AIゲートウェイが推論をOpenAI互換のエンドポイントに転送します。そのエンドポイントの正体が、Privatemodeプロキシです。プロキシは標準の/v1 APIを公開し、Privatemodeサービスとのあいだで暗号化とアテステーションを担います。リクエストが届くと、プロキシはそれが自社ネットワークを出る前に暗号化し、アテステーションでリモートTEEを検証し、そのうえで転送します。復号が行われるのは、コンフィデンシャルコンピューティング環境の中だけです。Duo側では、コード提案、チャット、コードレビュー、エージェントフローのいずれも、開発者から見た使い勝手は変わりません。

sequenceDiagram
    autonumber
    actor Dev as 開発者 /<br>Duo Agent Platform
    participant GW as セルフホストのGitLab<br>AIゲートウェイ
    participant Proxy as Privatemode<br>プロキシ
    participant TEE as リモートTEE<br>(CPU + GPU)

    Dev->>GW: 推論リクエスト（コード提案、<br>チャット、コードレビュー、<br>エージェントフロー）
    GW->>Proxy: OpenAI互換<br>エンドポイントへ<br>リクエストを転送

    rect rgb(255, 244, 214)
        Note over Proxy,TEE: コードを送る前にアテステーションを実施
        Proxy->>TEE: アテステーション証跡を要求
        TEE-->>Proxy: エンクレーブのコードに対する署名付き証跡
        Proxy->>Proxy: 既知の正しい値と証跡を照合
        Proxy->>TEE: 暗号化チャネルを確立（AES-256、ポスト量子安全）
    end

    Proxy->>TEE: 暗号化したリクエストを転送
    Note over TEE: 復号と推論はエンクレーブ<br>の中だけで実行される
    TEE-->>Proxy: 暗号化されたレスポンス
    Proxy-->>GW: 暗号化されたレスポンス
    GW-->>Dev: 生成結果（開発者の<br>使い勝手は変わらない）

シーケンス図が示すのは、GitLab DuoのリクエストがセルフホストのAIゲートウェイからPrivatemodeプロキシに渡り、プロキシがリモートエンクレーブをアテステーションして暗号化チャネルを確立したうえで、信頼実行環境での推論にリクエストを回すまでの流れです。 AIゲートウェイとプロキシは自社で運用します。デプロイ方式は問いません（Linuxパッケージ、Docker、Kubernetesのいずれでも構いません）。手順はバージョンごとにドキュメント化されているので、ここで繰り返すのではなく、PrivatemodeのGitLab Duo統合ガイドをご覧ください。

トレードオフ

ただで手に入るアーキテクチャはありません。技術者の読者には、コストも正直にお伝えします。

ゲートウェイとプロキシは自社で運用します。 これは実際のインフラ作業です。適切なホスト名でAIゲートウェイをデプロイし、アップグレードのたびにイメージのバージョンをGitLabのリリースに合わせ、JWTキーと証明書を設定し、プロキシを到達可能な状態に保つ必要があります。とはいえ、これは通常のインフラ運用の範囲であって、GPUの調達でもモデル運用でもありません。この違いが重要です。コードを守るもう一つの選択肢である自前のLLMスタックは、品薄のGPUを買い、モデルの運用と更新を担うチームを抱え、それでもフロンティアに遅れ続けることを意味します。Privatemodeはホスト型SaaSとしてモデル運用を引き受けるため、手元に残る負担はプロキシとゲートウェイだけです。

汎用のOpenAI互換モデルは、GitLab Duo Self-Hostedではまだ成熟の途上です。 現時点ではベータ機能のため、モデル固有の問題へのサポートはまだ保証されていません。強化はロードマップに入っていますが、いますぐ完全にサポートされた構成が必要なら、そのタイムラインを展開計画に織り込んでください。

アテステーションと暗号化には、多少のオーバーヘッドが伴います。 追加のラウンドトリップと暗号処理のぶん、リクエストごとに時間がかかります。私たちのテストでは実用上の問題にはなっていませんが、統合ガイドでは応答の遅いセルフホストバックエンド向けにAIゲートウェイのタイムアウトを延ばすことを推奨しています。自社のレイテンシ要件に照らして、一度計測しておくと安心です。

信頼する対象はなくなりませんが、その範囲は狭まります。 この保証は、ハードウェアTEEとアテステーションチェーンが健全であることを前提にしています。「運用事業者が覗かないと信じる」よりもはるかに小さく、検証しやすい前提であり、アテステーションの証跡は自分の手で確かめられます。それでもゼロではありません。コンフィデンシャルコンピューティングは信頼の範囲をシリコンまで狭めますが、信頼そのものを消し去るわけではないのです。

実務にとっての意味

• 規制業界の組織にとって： 既存の知的財産保護・データ保護ポリシーを崩さずに、最新のAIコーディングエージェントを使えるようになります。コードはハードウェアで暗号化された境界の内側にとどまり、GPUの購入もモデル運用体制の構築も必要ありません。
• 開発者にとって： GitLab Duoの使い勝手はこれまでどおり、モデルは同等かそれ以上、新しく覚えるツールもありません。モデルの選択はインスタンス側で管理されるため、GitLab Workflow拡張機能を通じたエディタ内のチャットとコード提案も、同じコンフィデンシャルな構成をそのまま引き継ぎます。
• コンプライアンス・セキュリティチームにとって： このアーキテクチャは、コンフィデンシャルコンピューティングとリモートアテステーションへ向かうBSI C5:2026の方向性と合致します。NIS2、DORA、GDPRをめぐる議論には、「使用中のデータが暗号化されている」「実行がアテステーションされている」という具体的な技術的根拠を持ち込めます。もちろん、これだけでコンプライアンスが満たされるわけではありません。コンプライアンスは組織的かつ継続的な取り組みだからです。それでも、AI導入をそもそも止めている「自社のコードが境界の外に出てしまう」という反対理由は、これで取り除けます。

Privatemodeを使ってみる

PrivatemodeをGitLab Duoのセルフホストモデルプロバイダーとして使うには、GitLab Self-Managedのバージョン17.9以降（PremiumまたはUltimate）と、GitLab Duo Enterpriseアドオンが必要です。エージェントフローを使う場合は、さらにGitLab Duo Agent Platform（バージョン18.8以降で一般提供）が必要になります。利用時には、GitLabクレジットのドキュメントに記載されたBYOM（Bring Your Own Model）のルールと係数に従って、GitLabクレジットが消費されます。

さらに詳しく

• Privatemodeのドキュメント
• GitLab Duo統合ガイド
• コーディングアシスタントガイド
• Capgeminiの事例
• NVIDIAソリューションブリーフ

本記事では、ミドルウェアの定義や役割、主な種類、導入するメリット、具体的なユースケースまでわかりやすく解説します。

1. ミドルウェアとは

ここでは、ミドルウェアについて以下の4点で見ていきます。

• ミドルウェアの定義
• ソフトウェアとの違い
• ミドルウェアの役割
• ミドルウェアの歴史

1-1. ミドルウェアの定義

ミドルウェアとは、OS（オペレーティングシステム）とアプリケーションの中間に位置し、両者をつなぐ役割を担うソフトウェアです。OSとアプリケーションの間で処理を仲介し、通信やデータ管理などの共通機能を提供します。

単体で利用されることは少なく、他のソフトウェアを支える裏方的な存在として機能する点が特徴です。データベースとの接続処理や通信処理など、複数のアプリケーションが共通して必要とする機能をミドルウェアが担うことで、開発の効率化や品質の安定化につながります。

たとえば、複数のアプリケーションがそれぞれ個別にデータベースへの接続処理を実装すると、コードの重複や保守性の低下につながりかねません。こうした共通処理をミドルウェアに集約することで、開発者はアプリケーション固有のロジックに専念でき、開発全体の生産性向上にもつながります。

1-2. ソフトウェアとの違い

ミドルウェアとソフトウェアの違いがよくわからないという方も多いでしょう。

「ソフトウェア」は、OSやアプリケーション、ミドルウェアなどを含む、コンピュータ上で動作するプログラム全般を指す広い概念です。一方、ミドルウェアはそのソフトウェアの一種であり、OSとアプリケーションの間で連携や通信を担う役割に特化している点が異なります。

つまり、ソフトウェアという大きな枠組みの中に、OS・アプリケーション・ミドルウェアがそれぞれ異なる役割を持って存在していると捉えると理解しやすいでしょう。ミドルウェアは、OSが提供する基本機能とアプリケーションが求める機能との橋渡し役として位置付けられます。

具体的には、OSはハードウェアの制御やファイル管理といった基盤的な機能を提供し、アプリケーションは文書作成やWeb閲覧など、ユーザーが目的に応じて利用する個別の機能を提供します。この両者の間に立ち、通信やデータ連携などの共通処理を担うのがミドルウェアの役割であり、開発現場では「OSとアプリケーションの橋渡し役」として説明されることが多いです。

1-3. ミドルウェアの役割

ミドルウェアが果たす主な役割について、もう少し詳しく見ていきましょう。

ミドルウェアの役割の1つ目は、アプリケーション開発で共通して必要になる機能をまとめて提供することです。データベースへの接続やユーザー認証、通信処理など、多くのアプリケーションで繰り返し必要となる機能をミドルウェアが担うことで、開発者は各アプリケーション固有の機能開発に集中できます。

2つ目の役割は、OSやハードウェアの違いを吸収し、開発負担を軽減することです。異なるOSやハードウェア環境でも同じように動作するようミドルウェアが差異を吸収するため、開発者は環境ごとの個別対応に追われることなく開発を進められます。近年はクラウド環境や複数のOSを併用するケースも増えており、こうした差異を意識せずに開発できる点は大きな利点といえるでしょう。

3つ目は、データ連携や通信などの複雑な処理を仲介する役割です。システム間やアプリケーション間でのデータのやり取りを安定的に行えるようにすることで、大規模で複雑なシステムの構築や運用を支えています。特に、複数のシステムが連携し合う大規模なエンタープライズシステムにおいては、ミドルウェアが処理の一貫性や整合性を保つ要として機能します。

1-4. ミドルウェアの歴史

ミドルウェアという概念は、1960年代後半に登場したとされています。当初は大型コンピュータによる集中型システムが主流でしたが、その後クライアント・サーバー型システムや分散システムへの移行が進む中で、異なるOSやハードウェアを連携させる必要性が高まり、ミドルウェアの重要性が増していきました。

1990年代以降は、企業システムの分散化やインターネットの普及に伴い、トランザクション処理やメッセージングを担うミドルウェア製品が数多く登場しました。異なるベンダーのシステムやプラットフォームをつなぐ標準的な仕組みとして、ミドルウェアは急速に普及していきます。

現在では、クラウドコンピューティングやモバイルアプリケーション、IoTなど幅広い領域のシステムで利用される基盤技術として定着しています。技術の多様化が進むにつれ、異なる環境や仕組みをつなぐミドルウェアの役割はより重要になっているといえるでしょう。

2. ミドルウェアの主な種類

ミドルウェアにはさまざまな種類があり、それぞれ異なる役割を担っています。ここでは代表的な以下3つの種類をご紹介します。

• Webサーバー
• アプリケーションサーバー
• データベース管理サーバー

2-1. Webサーバー

Webサーバーは、ブラウザからのリクエストに応答し、Webページやデータを返す役割を担うミドルウェアです。HTTP・HTTPS通信を処理し、Webサイトの表示を実現する基盤として機能します。

代表的なWebサーバーソフトウェアとしては、ApacheやNginxなどが広く利用されています。Webページや画像などのコンテンツをブラウザへ配信する役割を担うほか、リバースプロキシや負荷分散などの機能を備えており、大規模なWebサービスの運用に欠かせない存在です。

特にNginxは、大量の同時アクセスを効率的に処理できる非同期処理の仕組みを備えており、アクセス数の多いWebサービスで広く採用されています。用途やアクセス規模に応じて適切なWebサーバーを選定することが、安定したサービス運用の鍵となります。

2-2. アプリケーションサーバー

アプリケーションサーバーは、ビジネスロジックなどの動的な処理を実行するミドルウェアです。Webサーバーから受け取ったリクエストを処理し、必要に応じてデータベースと連携する役割を担います。

会員情報の照合や決済処理などの複雑な業務ロジックを実行するため、動的な処理が多いアプリケーションほど重要な役割を果たします。システムの規模や処理量に応じて、処理性能や拡張性に優れた製品を選ぶことが重要です。

代表的な製品には、TomcatやJBoss（WildFly）、WebLogic Serverなどがあり、扱う言語や既存システムとの相性に応じて選定されるケースが多く見られます。

また、複数のアプリケーションサーバーを並列に配置し、ロードバランサーによってリクエストを振り分けることで、大量のアクセスにも安定して対応できます。可用性が求められるシステムでは、障害発生時にもサービスを継続できるよう、冗長構成を採用するのが一般的です。

2-3. データベース管理サーバー

データベース管理サーバーは、データの保存・検索・更新を効率的に管理するミドルウェアです。複数のユーザーやアプリケーションから同時にアクセスされるデータを、整合性を保ちながら管理する役割を担います。

代表的な製品には、MySQLやPostgreSQLなどがあります。大量のデータを扱うシステムでは、処理性能や可用性、拡張性に優れたミドルウェアを選定することが重要です。

また、データベース管理サーバーはトランザクション処理によってデータの整合性を維持する機能も備えています。複数の処理が同時に実行された場合でも、データの矛盾や欠損を防ぎながら、安全にデータを更新できる点が大きな特徴です。

3. ミドルウェアを利用するメリット

ミドルウェアを活用することで、開発現場にはさまざまなメリットが生まれます。ここでは代表的な以下3つのメリットをご紹介します。

• 開発コストを削減できる
• OS・ハードウェアによる違いを補完できる
• 高度な処理を実現しやすくなる

3-1. 開発コストを削減できる

ミドルウェアを利用する大きなメリットの1つが、開発コストの削減です。共通機能を一から開発する必要がなくなるため、工数を大幅に削減できます。

また、すでに実績のあるミドルウェアを活用することで、品質や安定性を確保しやすくなる点もメリットです。開発期間の短縮とコスト削減の両方につながるため、多くの開発現場で積極的に採用されています。

特にスタートアップや小規模チームでは、開発リソースが限られている中で多くの機能を実装する必要があるため、実績のあるミドルウェアを活用することで開発スピードと品質を両立しやすくなります。

3-2. OS・ハードウェアによる違いを補完できる

ミドルウェアは、OSやハードウェアごとの違いを吸収し、システムの移植性を高める役割も果たします。異なる環境であっても、同じアプリケーションを安定して動作させやすくなる点が特徴です。

環境ごとの個別対応が減ることで、開発や保守にかかる負担を効率化できます。複数の環境で同一のサービスを展開する場合には、特に大きなメリットとなるでしょう。

たとえば、オンプレミス環境とクラウド環境の両方でサービスを提供する場合でも、ミドルウェアが差異を吸収することで、開発者は環境ごとに個別のコードを用意する必要がなくなります。

3-3. 高度な処理を実現しやすくなる

ミドルウェアを活用することで、分散処理や大量データ処理といった高度な機能を利用しやすくなります。専門性の高い機能をミドルウェアに任せることで、複雑なシステム要件にも対応しやすくなります。

その結果、アプリケーション側の実装をシンプルに保つことができ、開発者は本来注力すべき機能開発に集中しやすくなるでしょう。高度な非同期処理やメッセージングといった機能も、ミドルウェアを介することで比較的容易に組み込めるようになります。

なお、こうしたメリットがある一方で、導入時にはライセンス費用や保守サポート費用が発生する製品も多く、特定のミドルウェアに依存しすぎるとバージョンアップや乗り換えの際に手間がかかる点には注意が必要です。自社の要件や将来的な拡張性を踏まえたうえで選定することが望ましいでしょう。

4. システム・アプリケーション開発におけるミドルウェア

ミドルウェアは、システム開発とアプリケーション開発のそれぞれの場面で異なる役割を担っています。ここでは両者に分けて解説します。

4-1. システム開発におけるミドルウェア

システム開発、特にリリース後の安定運用の場面では、ミドルウェアが下記のような機能を通じて重要な役割を担います。

• バックアップ
• 運用効率化
• 監視
• 予備サーバーへの切り替え

4-1-1. バックアップ

ミドルウェアは、データを定期的に複製し、消失や破損に備えるバックアップ機能を提供します。障害やシステム障害が発生した際にも迅速な復旧を可能にし、バックアップの自動実行によって運用負担や人的ミスの軽減にもつながります。世代管理を組み合わせることで、任意の時点の状態に復元できる点も実務上のメリットです。

4-1-2. 運用効率化

定型的な運用作業を自動化することで、日々の作業負担を軽減できる点もミドルウェアの重要な機能です。複数のシステムやサーバーを効率的に管理できるため、人的ミスを減らし、安定したシステム運用につなげられます。運用担当者は定型作業から解放され、より付加価値の高い業務に注力しやすくなります。

4-1-3. 監視

ミドルウェアは、システムやサーバーの稼働状況を監視する機能も担っています。異常や障害の兆候を早期に検知し通知することで、トラブルの未然防止や迅速な障害対応が可能になります。CPUやメモリの使用率、通信状況といった複数の指標を横断的に監視できる点も強みです。

4-1-4. 予備サーバーへの切り替え

障害発生時に予備サーバーへ自動で切り替える機能も、ミドルウェアが担う重要な役割の1つです。サービス停止時間を最小限に抑えられるため、システムの可用性や安定性の向上に直結します。この仕組みは一般に「フェイルオーバー」と呼ばれ、24時間365日の稼働が求められるシステムでは特に重要な機能とされています。

4-2. アプリケーション開発におけるミドルウェア

アプリケーション開発の場面でも、ミドルウェアはさまざまな形で活用されています。以下2つの観点で見ていきましょう。

• 4つのレイヤー
• ツール

4-2-1. 4つのレイヤー

アプリケーション開発におけるミドルウェアは、コンテナ、ランタイム、インテグレーション、プロセス自動化・意思決定管理という4つのレイヤーに分けることが可能です。

コンテナはアプリケーションの実行環境を標準化し、ランタイムはプログラムの実行を支え、インテグレーションは異なるシステム間の連携を担うなど、それぞれが専門的な役割を果たします。各レイヤーが連携して機能することで、効率的なアプリケーション開発を実現できます。

4-2-2. ツール

テンプレートやコンテナを活用した開発支援ツールの利用により、ミドルウェアを通じた開発作業の効率化が可能です。コードの共有や共同開発を円滑に進められるようになり、開発全体の生産性や品質向上に貢献します。標準化されたテンプレートを使うことで、環境構築にかかる時間を削減し、開発初期の立ち上げをスムーズに進められる点もメリットです。

5. ミドルウェアのユースケース

ミドルウェアは、さまざまな開発現場で活用されています。ここでは、以下4つのユースケースをご紹介します。

• ソフトウェア開発
• データ送受信
• 分散アプリケーション
• ゲーム開発

5-1. ソフトウェア開発

ソフトウェア開発においては、ミドルウェアが提供する共通機能を活用することで、効率的に開発を進められます。通信やデータ管理などの処理をミドルウェアに任せられるため、開発者はアプリケーション本来の機能開発に集中できます。汎用性の高いミドルウェアを土台にすることで、開発期間の短縮にもつながります。

5-2. データ送受信

システム間のデータのやり取りを仲介する場面でも、ミドルウェアは重要な役割を果たします。異なるシステムやアプリケーション間の連携を円滑にし、大量のデータであっても安定して送受信できる環境を実現します。金融システムやEC基盤など、リアルタイム性が求められる領域で特に重視されています。

5-3. 分散アプリケーション

複数のサーバーやアプリケーションを連携して動作させる分散アプリケーションにおいても、ミドルウェアは欠かせない存在です。各システム間の通信やデータ連携をミドルウェアが担うことで、大規模かつ高負荷なシステムでも安定した運用が可能になります。近年では、マイクロサービスアーキテクチャを採用する企業も増えており、サービス同士の通信を仲介するミドルウェアの重要性は今後さらに高まっていくと考えられます。

5-4. ゲーム開発

ゲーム開発の分野でも、ミドルウェアの活用が進んでいます。画像処理や音声処理、ネットワーク機能などを効率よく利用できるほか、共通機能を活用することで開発期間を短縮し、高度な機能を短期間で実装できる点がメリットです。

オンライン対戦機能や物理演算エンジンなど、専門性の高い機能をミドルウェアとして組み込むことで、開発チームは企画やゲーム体験の作り込みにより多くの時間を割けるようになります。

6. ミドルウェアを使うシステム・アプリ開発ならGitLab

ミドルウェアを活用したシステムやアプリケーションの開発では、ソースコード管理からCI/CDまでを一元的に管理できる開発プラットフォームの活用が有効です。GitLabは、こうした一連の開発プロセスを1つのプラットフォーム上で完結できるのが特徴。開発からテスト、リリースまでのワークフローを網羅的にカバーできるため、情報の分断を防ぎやすくなります。

ミドルウェアを含むシステムの開発・テスト・デプロイをGitLab上でまとめて運用することで、チーム開発の生産性向上やコード品質の管理にも役立てられます。バージョン管理からデプロイまでの一連の流れを可視化できるため、開発チーム全体の状況把握もしやすくなるのがメリットです。

開発環境の統合を検討している企業担当者の方は、GitLabの活用を選択肢の1つとしてぜひご検討ください。

もっとも包括的でインテリジェントなDevSecOpsプラットフォーム「GitLab」

7. ミドルウェアの役割を理解してスムーズな開発を実現しよう

ミドルウェアは、OSとアプリケーションをつなぐ重要なソフトウェアであり、Webサーバーやアプリケーションサーバー、データベース管理サーバーなど、さまざまな種類が存在します。それぞれの種類や役割を理解することで、システムやアプリケーション開発をより効率的に進められるようになります。

また、開発コストの削減やOS・ハードウェアの違いの補完、高度な処理の実現など、ミドルウェアを導入するメリットはさまざまです。バックアップや監視、予備サーバーへの切り替えといった運用面の機能も充実しているため、システムの安定稼働にも大きく貢献します。

自社の開発体制に適したミドルウェアを選定し、適切に活用することで、安定したシステム運用と効率的な開発の両立を目指しましょう。GitLabのような開発プラットフォームと組み合わせることで、ミドルウェアを含むシステム全体の開発・運用効率をさらに高められます。ソースコード管理からCI/CDまでを一貫して行える環境を整えることは、開発チームの生産性と品質の両方を底上げする有効な手段です。

監修：小松原 つかさ @tkomatsubara

（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）

本記事では、Linuxの仕組みやメリット・デメリット、主なディストリビューションの特徴、活用方法を分かりやすく解説します。目的に合ったLinux環境を選ぶ際の参考にしてください。

1. Linuxの基本情報

Linuxを活用するには、まずOSやオープンソースといった基本的な仕組みを理解することが重要です。ここでは、Linuxの概要や特徴、歴史について以下4つのポイントで分かりやすく解説します。

• Linuxとは
• OSとは
• オープンソースとは
• Linuxの歴史

1-1. Linuxとは

Linuxは、1991年に登場したオープンソースのOSです。厳密にはOSの中核を担う「カーネル」を指しますが、一般にはディストリビューションを含めたOS全体を意味する言葉として使われています。ディストリビューションは、Linuxカーネルにアプリケーションやライブラリ、各種ツールなどを組み合わせ、まとめたパッケージのことです（詳しくは後述）。

Linuxでは、多くのディストリビューションが無償で利用できる一方、企業向けにはサポートが付いた有償版も提供されています。サーバーやクラウド、組み込み機器、スーパーコンピューターなど幅広い分野で利用されており、自由に改良・再配布できるため、世界中の開発者によって継続的に進化を続けています。

1-2. OSとは

Linuxを理解する上では、そもそもOSとは何かを理解する必要があります。OS（Operating System）は、コンピューターのハードウェアとアプリケーションを仲介する基本ソフトウェアです。

キーボードやマウスからの入力を受け付けたり、CPUやメモリ、ストレージなどのハードウェア機能を管理したりする役割を担っています。OSがあることで、アプリケーションはハードウェアの違いを意識せずに動作できます。代表的なOSにはWindowsやMacがあり、Linuxもそれらと並ぶOSの一つです。

1-3. オープンソースとは

オープンソースとは、ソフトウェアの設計図にあたるソースコードが公開され、利用・改変・再配布を一定のライセンス条件のもとで自由に行える仕組みです。世界中の開発者が改善や機能追加に参加できるため、不具合や脆弱性が発見・修正されやすく、品質や安全性の向上につながっています。Linuxはオープンソースソフトウェアの代表例として知られ、多くの企業や開発者に利用・改良されながら発展してきました。

1-4. Linuxの歴史

Linuxは、1991年にフィンランドの大学生だったリーナス・トーバルズ氏が開発を開始したOSカーネルです。ソースコードがオープンソースとして公開されたことで、世界中の開発者が改良や機能追加に参加し、現在のLinuxへと発展しました。現在では、サーバーやクラウド環境をはじめ、Androidの基盤、スーパーコンピューター、IoT機器など幅広い分野で利用されており、現代のITインフラを支える重要な技術の一つとなっています。

2. Linuxの仕組み

Linuxを適切に活用するには、OSがどのような構成で動作しているのかを理解することも重要です。ここでは、Linuxを構成する要素や、ディストリビューションの仕組みについて解説します。

2-1. Linuxの構成要素

Linuxは、カーネルだけでなく、アプリケーションやユーザースペースなど複数の要素で構成されています。それぞれの役割を理解することで、Linuxの仕組みをより深く理解できます。以下3つの要素について、それぞれ見ていきましょう。

• カーネル
• アプリケーション
• ユーザースペース

2-1-1. カーネル

カーネルは、OSの中核としてハードウェアを制御するソフトウェアです。CPUやメモリ、ストレージ、ネットワーク機器などのリソースを管理し、アプリケーションからの要求に応じて適切な処理を実行します。一般的にはOS全体を「Linux」と呼びますが、本来Linuxとは、このカーネルそのものを指す名称です。

2-1-2. アプリケーション

アプリケーションは、ユーザーが直接的に操作するソフトウェアのことです。Webブラウザやテキストエディター、メールソフト、データベースなど、用途に応じてさまざまなアプリケーションがLinux上で動作します。アプリケーションはユーザースペースで実行され、ハードウェアへの直接アクセスは行わず、システムコールを通じてカーネルに必要な処理を依頼する仕組みになっています。

2-1-3. ユーザースペース

ユーザースペースは、アプリケーションや各種サービスが動作する領域のことです。ハードウェアを直接制御するカーネル空間とは分離されているため、アプリケーションで問題が発生してもシステム全体には影響が及びにくい設計となっています。ハードウェアで必要な処理は、システムコールを通じてカーネルへ依頼されるため、安全性と安定性が確保されています。

2-2. ディストリビューションとは

Linuxを理解する上で欠かせないのが、ディストリビューションという概念です。ディストリビューションは、Linuxカーネルにアプリケーションやライブラリ、各種ツールなどを組み合わせ、すぐに利用できるようにまとめたOSパッケージのことです。

UbuntuやRed Hat Enterprise Linux、Debianなど多くの種類があり、それぞれ使いやすさやサポート体制、用途が異なります。利用目的や運用環境に合わせて選択できる点は、Linuxの大きな特徴の一つです。記事の後半ではLinuxディストリビューションの主な種類をご紹介しているので、ぜひチェックしてみてください。

3. Linuxを利用するメリット・デメリット

Linuxには多くのメリットがある一方で、導入前に理解しておきたい注意点もあります。ここでは、Linuxを利用するメリットとデメリットをそれぞれご紹介します。

3-1. Linuxを利用するメリット

Linuxはコストを抑えやすく、柔軟性や安定性にも優れていることから、個人利用から企業のシステムまで幅広く採用されています。ここでは、Linuxを利用する主なメリットとして以下の5点をご紹介します。

• 無料で使えるものが多い
• 情報が豊富である
• 幅広い用途に使える
• セキュリティに優れている
• スペックの低いPCでも使える

3-1-1. 無料で使えるものが多い

Linuxは、多くのディストリビューションを無償で利用できます。そのため、OSのライセンス費用を抑えながらサーバーや開発環境を構築できる点が大きなメリットです。個人での学習や検証環境の構築にも導入しやすく、必要に応じて有償サポート付きのディストリビューションを選択することもできます。

3-1-2. 情報が豊富である

Linuxは世界中で広く利用されているため、インターネット上に技術情報やトラブルの解決方法が数多く公開されています。公式ドキュメントやコミュニティ、技術ブログなども充実しており、エラーが発生した場合でも解決策を見つけやすい環境が整っています。そのため、学習を進めやすく、導入後の運用もしやすいOSだと言えるでしょう。

3-1-3. 幅広い用途に使える

Linuxは、Webサーバーやデータベースサーバー、クラウド環境だけでなく、デスクトップPCやIoT機器、組み込みシステムまで幅広い用途で利用されています。用途に応じて必要な機能だけを組み込めるため、シンプルな構成から大規模システムまで柔軟に対応できます。一つのOSでさまざまな用途に活用できることは、大きな魅力です。

3-1-4. セキュリティに優れている

Linuxはオープンソースであり、多くの開発者がソースコードを確認できることから、脆弱性の発見や修正が継続的に行われています。また、ユーザーやファイルごとの権限管理が充実しており、不正なアクセスや意図しない変更を防ぎやすい仕組みが備わっています。適切に運用すれば、安全性の高いシステム環境を構築しやすい点もLinuxの強みです。

3-1-5. スペックの低いPCでも使える

Linuxには軽量なディストリビューションが数多くあり、比較的古いPCや性能の高くない機器でも快適に動作する場合があります。そのため、使わなくなったPCをサーバーや学習用端末として再活用することも可能です。ハードウェアの性能を有効活用できるため、導入コストや運用コストの削減にもつながります。

3-2. Linuxを利用するデメリット

Linuxには多くのメリットがありますが、利用する環境や目的によっては注意すべき点もあります。導入後に困らないよう、事前に主なデメリットとして以下の4点も理解しておきましょう。

• サポートを受けにくい
• 他OS向けのソフトウェアが使えない
• システムへの慣れが必要である
• 周辺機器がうまく動作しないことがある

3-2-1. サポートを受けにくい

無償で利用できるLinuxディストリビューションでは、公式のサポートが提供されない場合があります。そのため、トラブルが発生した際は、公式ドキュメントやコミュニティの情報を参考にしながら、自分で解決する必要があります。企業で利用する場合は、有償サポート付きのディストリビューションを選択することで、安心して運用しやすくなります。

3-2-2. 他OS向けのソフトウェアが使えない

WindowsやMac専用に開発されたソフトウェアは、Linuxではそのまま動作しない可能性があります。業務で利用したいアプリケーションがLinuxに対応していない場合は、代替ソフトや互換レイヤーを利用する必要があります。そのため、導入前には必要なソフトウェアや業務システムがLinuxに対応しているかを確認しておくことが重要です。

3-2-3. システムへの慣れが必要である

LinuxはGUI（画面操作）でも利用できますが、設定変更やシステム管理ではコマンドラインを使う場面が少なくありません。WindowsやMacとは操作方法やファイル構成が異なるため、使い始めは戸惑うこともあります。実務で活用するには基本的なコマンドやLinux特有の仕組みを学ぶ必要があり、一定の学習コストを見込んでおくことが大切です。

3-2-4. 周辺機器がうまく動作しないことがある

Linuxでは、プリンターやスキャナーなど一部の周辺機器が正常に動作しない場合があります。これは、メーカーがLinux向けドライバーを提供していないことや、最新機器への対応が遅れることがあるためです。導入後のトラブルを避けるためにも、利用予定の周辺機器がLinuxに対応しているか事前に確認しておくことをおすすめします。

4. Linuxでできること・使い方

Linuxは高い柔軟性と安定性を備えており、サーバー運用からアプリケーション開発、IoT機器まで幅広い分野で活用されています。ここでは、Linuxの代表的な活用例として以下の4つをご紹介します。

• サーバーの構築
• アプリケーションの開発
• IoT機器への組み込み
• 開発・学習環境の構築

4-1. サーバーの構築

Linuxは、Webサーバーやファイルサーバー、データベースサーバーなど、さまざまなサーバーの構築に利用されています。安定性が高く、長時間の連続稼働に適していることから、多くの企業やクラウドサービスで採用されているOSです。また、DockerやKubernetesといったコンテナ技術の基盤でもあり、効率的なシステム運用やアプリケーションの実行環境として広く活用されています。

4-2. アプリケーションの開発

Linuxは、さまざまなプログラミング言語での開発が可能な上、コンパイラやライブラリなどの開発ツールも充実しており、アプリケーション開発に適した環境です。本番環境でもLinuxが採用されることが多いため、開発環境と運用環境を揃えやすく、動作検証を効率的に行えます。また、オープンソースフレームワークも豊富に利用できるため、開発の効率化につながります。

4-3. IoT機器への組み込み

Linuxは軽量かつ高いカスタマイズ性を備えたOSであるため、IoT機器や組み込みシステムでも広く利用されています。家電製品や産業機器、センサー機器、ネットワーク機器など、用途に合わせて必要な機能を組み込める点が特徴です。限られたハードウェア資源でも動作しやすく、柔軟に機能を追加・変更できることから、多様な製品開発に活用されています。

4-4. 開発・学習環境の構築

Linuxは、仮想マシンやDockerなどのコンテナ環境を利用することで、手軽に開発・学習環境を構築できます。多くのディストリビューションを無償で利用できるため、コストを抑えながらプログラミングやサーバー構築を学ぶことが可能です。実務で利用される環境に近い構成を試せるため、スキル習得や技術検証に適しています。

5. Linuxの主なディストリビューションの種類

Linuxには、用途や目的に応じて選べるさまざまなディストリビューションがあります。それぞれ特徴やサポート体制が異なるため、利用シーンに合ったものを選ぶことが重要です。ここでは、主なディストリビューションとして以下の8つをご紹介します。

• Ubuntu
• Amazon Linux
• Red Hat Enterprise Linux
• CentOS Linux
• MIRACLE LINUX
• AlmaLinux
• Rocky Linux
• Debian

5-1. Ubuntu

Ubuntuは、初心者から開発者まで幅広いユーザーに利用されている人気のLinuxディストリビューションです。操作しやすいデスクトップ環境が用意されており、初めてLinuxを利用する方でも比較的扱いやすいのが特徴です。デスクトップ用途だけでなく、サーバー向けのエディションも提供されており、情報量やコミュニティが充実しているため、学習から実務まで幅広く活用されています。

5-2. Amazon Linux

Amazon Linuxは、Amazon Web Services（AWS）上での利用に最適化されたLinuxディストリビューションです。AWSの各種サービスとの親和性が高く、クラウド環境でサーバーやアプリケーションを構築・運用する際によく利用されています。もっとも利用者が多いLinuxディストリビューションの一つと言えるでしょう。

また、AWS環境向けに継続的なセキュリティ更新や性能改善が提供されるため、安定したクラウド運用を実現しやすい点も特徴です。

5-3. Red Hat Enterprise Linux

Red Hat Enterprise Linux（RHEL）は、企業向けに提供されている商用Linuxディストリビューションです。長期サポートやセキュリティアップデート、公式サポートが充実しており、業務システムや大規模なサーバー環境で広く採用されています。なお、個人開発者や学習用途向けには、一定条件のもとで利用できる無償のDeveloper Subscriptionも提供されています。

5-4. CentOS Linux

CentOS Linuxは、Red Hat Enterprise Linuxと高い互換性を持つ無償のディストリビューションとして、長年サーバー用途を中心に広く利用されてきました。しかし、従来のCentOS Linuxはサポートを終了しており、CentOS 8は2021年12月末、CentOS 7は2024年6月末にEOL（サポート終了）を迎えました。

一方で、Red Hatが提供する「CentOS Stream」（Red Hat Enterprise Linuxの開発版という位置づけ）は現在も継続しています。また、CentOSの移行先としては、この後ご紹介するMIRACLE LINUXやAlmaLinux、Rocky Linuxなど様々なディストリビューションが普及しています。

5-5. MIRACLE LINUX

MIRACLE LINUXは、日本企業の利用を想定して開発・提供されている国産のLinuxディストリビューションです。日本語によるサポートやドキュメントが充実しており、国内企業への導入のしやすさが特徴です。また、CentOS Linuxのサポート終了に伴う移行先としても人気があり、商用環境で利用しやすい無償のOSとして提供されています。

5-6. AlmaLinux

AlmaLinuxは、CentOS Linuxの後継候補として登場した無償のLinuxディストリビューションです。Red Hat Enterprise Linuxと高い互換性を持ち、既存のCentOS環境から比較的スムーズに移行できます。コミュニティ主導で開発・運営されており、安定した運用と継続的なアップデートが期待できることから、企業のサーバー環境でも広く採用されています。

5-7. Rocky Linux

Rocky Linuxは、CentOSの創設者であるグレゴリー・カーツァー氏によって立ち上げられたLinuxディストリビューションです。Red Hat Enterprise Linuxと高い互換性を備え、CentOS Linuxの移行先として多くの企業で利用されています。無償で利用できるほか、安定性や長期的な運用を重視して開発が進められており、企業システムにも適したディストリビューションです。

5-8. Debian

Debianは、安定性を重視して開発が続けられている歴史あるLinuxディストリビューションです。Ubuntuをはじめ、多くの派生ディストリビューションのベースとなっており、Linuxの発展にも大きく貢献しています。堅牢性の高さから、サーバー環境や開発環境を中心に幅広く利用されており、豊富なソフトウェアパッケージを利用できるのも特徴です。

6. Linuxでのソフトウェア開発にはGitLab

開発者の手元がWindowsやMacであっても、本番環境やCI/CDの実行基盤にLinuxを使うケースは少なくありません。そうしたLinux環境でのビルド・テスト・デプロイをGitLabと組み合わせることで、ソースコード管理からCI/CDやセキュリティチェック、コードレビューまでを一つのプラットフォームで完結でき、開発から運用までを効率化できます。

また、GitLab自体もLinux上で動作することを前提に設計されており、Linux環境との親和性の高さが特徴です。LinuxOSでの開発から運用まで一元的に管理できるため、開発チームの生産性向上に役立ちます。

参考：Install GitLab、GitLab: The DevSecOps platform

Linux開発環境の構築や改善を検討されている企業担当者の方は、GitLabの活用を選択肢の一つとしてぜひご検討ください。

もっとも包括的でインテリジェントなDevSecOpsプラットフォーム「GitLab」

7. Linuxを理解して用途に合った環境を選ぼう

Linuxは、オープンソースならではの高い柔軟性と安定性を備え、サーバーやクラウド、アプリケーション、IoT機器の開発など幅広い用途で利用されているOSです。一方で、ディストリビューションごとに特徴やサポート体制が異なるため、利用目的に合わせて選ぶことが重要です。

まずはUbuntuなど扱いやすいディストリビューションから試し、自分に合った環境を見つけてみましょう。開発環境として活用する場合は、DevSecOpsプラットフォームであるGitLabと組み合わせて運用することで、ソースコード管理からCI/CDまでの開発業務を効率化できます。

監修：吉瀬　淳一 @jyoshise1
（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）

GitLabは、本番環境に至るまでの残りの工程のセキュリティを担います。Anthropic ClaudeからGitLabへと至る典型的なセキュリティワークフローには5つのハンドオフが存在し、本記事ではその一つひとつを取り上げながら、エージェント型コーディングを大規模に統制する方法を解説します。

すでにClaude security guidanceやClaude Securityを利用しているチームであれば、GitLab MCPサーバーを通じてそのコンテキストをGitLabに直接連携させ、既存のワークフローをそのまま維持できます。Claudeがコードを書く瞬間を担当し、そこから本番環境に至るまでのすべてを、単一のプラットフォーム上でGitLabが引き受けます。

検出から実効性のある統制へ

Claude security guidanceプラグインは、開発者一人ひとりのセッション内でコードをレビューし、エージェントの手を止めないほどの速さで問題を検出します。しかし、そのコードがセッションを離れた後は、セキュリティチームはセッション内で何が起きたかの記録と、次に何が起きるかを制御する仕組みを必要とします。

GitLabが提供するのは、コードの出どころを問わず、本番環境に届く前の段階で安全なコーディングのためのガードレールを定義できるだけの可視性と制御力です。

• 一度定義し、全社に適用： セキュリティ設定プロファイルにより、必要なスキャンをリポジトリの外側からすべてのプロジェクトとパイプラインに適用できるため、カバレッジが一貫し、回避される心配もありません。
• エージェントにも職務分掌を適用： マージリクエスト承認ポリシーにより、変更を書いたエージェント自身がそれを承認することはできません。エージェントも、それを指示した開発者自身も、指定された承認者なしに自分の作業をマージすることはできません。
• 重大な脆弱性を出荷前にブロック： マージリクエスト承認ポリシーは、未解決の重大な検出結果があるマージを、指名された承認者が承認するまで保留します。これにより、見過ごされた、あるいは却下された脆弱性が気づかれないまま本番環境に届くことはありません。
• すべての検出結果のステータスを、恒久的に追跡： 脆弱性レポートとセキュリティダッシュボードにより、各検出結果が検出済みか、理由付きで却下されたか、解決済みかを確認できます。

セッション内のスキャンから監査証跡へ

変更管理における監査要件は、エージェントも対象に含む形へと広がっています。SOC 2、PCI DSS、FedRAMPといったコンプライアンスフレームワークでは、あらゆる変更が出荷前にテスト・レビュー・承認されたことを示す文書化されたエビデンスが求められます。

GitLabは、コンプライアンス統制を実効性のあるものにし、監査人向けのエビデンス収集を自動化します：

• スキャンとレビューの実施を証明： コンプライアンス統制は、すべてのマージリクエストでスキャンが実行されることを保証し、検出結果はマージリクエストと脆弱性レポートの両方に表示され、人の目で確認できます。
• 監査人への回答は数分で完了： パイプラインログ、承認記録、監査イベントにより、何がスキャンされ、誰が承認したかを変更ごとに再現可能な履歴として確認でき、関わった人やエージェントとも紐づけられます。
• 監査人が求めるフレームワークにエビデンスを対応付け： コンプライアンスフレームワークは、SOC 2や独自フレームワークなど、名前の付いた要件ごとにエビデンスをグループ化し、それぞれ特定の統制から構成されます。コンプライアンスステータスレポートでは、フレームワークごとにどの統制が合格・保留・不合格かを確認できます。

送信するデータをコントロールする

レビューのためにコードやその背景にあるビジネスコンテキストを送る相手は、人よりもモデルのほうが多いかもしれません。規制業界、政府機関、知的財産に敏感な組織にとっては、認証情報や独自のロジック、規制対象データなど、何を環境の外に出すかを自ら決める必要があります。この判断は、スキャンが実行される前に、コードに触れるすべてのツールにわたって行われなければなりません。

GitLabを使えば、データが環境の外に出る前に、モデルに届く内容を自ら決められます：

• シークレットや機密コードをモデル送信の対象外に： コンテキスト除外設定により、シークレットや機密ファイルを、エージェントがモデルに送るすべての内容から除外できます。
• コードと推論を自社の境界内に、承認済みのモデルだけで完結： Self-Managed環境でセルフホストモデルを実行すれば、何も外部に出ることはありません。フローごとにモデルを選択し、許可するモデルを制限して、コードが学習データに使われないようにできます。
• 送信内容をフィルタリング： GitLab Duoのプロンプトガードレールは、コード提案がモデルに届く前にシークレットをスキャンし、プロンプトが操作できるコンテンツを分離することでプロンプトインジェクションのリスクを抑えます。これは、すでに除外設定した内容に加えて機能します。

単発のスキャンから、開発ライフサイクル全体を網羅するスキャン体制へ

Anthropicのドキュメントでも、Claude security guidanceプラグインはベストエフォート型の支援ツールであり、人によるコードレビューや各種セキュリティスキャナーに置き換わるものではなく、それらと並行して使うものだと明記されています。この位置づけは重要です。なぜなら、出荷した時点では存在しない脆弱性もあるからです。今日出荷した依存関係に、来年、自分のコードには一切変更がないまま重大な脆弱性が公表されることもあります。Log4Shellはその典型例で、何年も前に出荷されたアプリケーションが、2021年12月に脆弱性が公になった瞬間、突然攻撃可能な状態になりました。

依存関係、コンテナイメージ、インフラ構成、そしてすでにコミット履歴に残っているシークレットには、特定のセッションから独立して実行されるスキャンが必要です。

GitLabは、ソフトウェア配信ライフサイクル全体を保護します：

• アタックサーフェス全体をカバー： 依存関係、コンテナ、Infrastructure as Code、シークレット、そして動的アプリケーションセキュリティテスト（DAST）のスキャンが、セッション単位のレビューでは決して届かない領域をチェックします。取り込む依存関係、出荷するイメージ、プロビジョニングするインフラ、コミットに紛れ込むシークレット、そして稼働中のアプリケーションです。
• スキャナーが見逃す欠陥も検出： 決定論的なスキャナーでは、ビジネスロジックの誤りや認証の不備、競合状態を検出できません。Security Review Flowは意図を推論することでこのカテゴリーを直接捉え、該当コードへのコメントとして投稿し、人が対応できるようにします。
• 結果がぶれない、決定論的なスキャンを併用： LLMによるレビューは、同じコードでも実行のたびに異なる検出結果を返すことがあります。アドバンストSASTのような決定論的スキャンは、固定のアルゴリズムで関数境界を越えて汚染データを追跡し、CWEにマッピングされた再現性のある結果を返します。これこそ、コンプライアンス監査に必要な一貫したエビデンスです。

すべてのエージェントと開発者に、共通のガードレールを

Claude security guidanceプラグインがレビューするのは、Claudeがセッション内で書いてコミットしたコードです。セッション内の「!」によるシェルエスケープを含め、開発者自身のシェルから行われたコミットは、プラグインのレビュー対象外です。Claude Securityは、開発者や管理者がオンデマンドで実行することで、コードベース全体や人が書いたコードにもレビューの範囲を広げます。

GitLabのスキャン実行ポリシーとマージリクエスト承認ポリシーは、すべての変更に対してパイプライン上で実行されます。そのため、コードを書いたのが人かエージェントか、スキャンを実行し忘れていないかといった事情に、カバレッジが左右されることはありません。

本番に届くものを統制する

Claude security guidanceとClaude Securityは、コードが書かれたその瞬間に問題を検出し、修正することを助けます。しかし、そのコードがセッションを離れた後は、本番環境まで安全に届けることの責任は、エンタープライズのセキュリティチームとプラットフォームチームが負います。そこで必要になるのが、エージェントが何をしたかの可視性、セキュリティ手順が守られたことの証明、そして問題のある変更を出荷前に止められる仕組みです。

GitLabは、Claudeのワークフローをそこにつなぎます。GitLab側でガードレールを一度設定すれば、あらゆるエージェントも開発者も、その内側でより速く、より安全に出荷できるようになります。Claudeの役割は、安全なコードを書く手助けをすることです。GitLabはそこから本番環境までのすべてを、チームの速度を落とすことなく統制します。

GitLab Ultimateの無料トライアルを始める！

すでにUltimateをご利用の場合は、スキャン実行ポリシーとマージリクエスト承認ポリシーを設定し、今日からガードレールの適用を始めましょう。

関連リンク

• Claude CodeとGitLab：リリースまでの3つのワークフロー
• GitLab Duo Agent PlatformとClaudeで開発を加速する
• GitLabのカスタムコンプライアンスフレームワークをDevSecOps環境で活用する方法

ソニービズネットワークスのGitLab Partner Championsの濱田です。

最近、最先端のAIエンジニアの間でLoop Engineeringという概念が流行っています。名付け親であるAddy Osmani氏は、「これが、コーディングエージェントとの協働方法の未来になるかもしれないと考えています。」と述べています。（同時に「しかし、まだ初期段階であり、私は懐疑的です。」とも述べていますが）

Loop Engineeringとは、簡単に表現するなら「AIエージェントに、目的を達成するまで自律的に動いてもらえる仕組みを作る事」です。私自身も、AIコーディングエージェントを使っているうちに人間がボトルネックであると感じてきており、どうにかAIエージェントに自律的に動いてもらえないか最近試行錯誤していました。

そこで、本日はGitLabとClaude Codeを使って、Loop Engineeringを実装する例をご紹介します。

この記事でわかること

• Loop Engineeringとは何か
• GitLabとClaude Codeを使った実装例（cron起動、Skills活用、ラベルベースのフロー）
• AIエージェントを自律稼働させる際に必要なガードレールの設計方法

Loop Engineeringとは

先ほども簡単にお話ししましたが、Loop Engineeringとは「AIエージェントに、目的を達成するまで自律的に動いてもらえる仕組みを作る事」です。

Claude Codeを使った時の一番簡単な例は、以下です。

#!/bin/bash
claude -p "ログを確認して、エラーがあったら分析して報告して下さい。"

このシェルスクリプトをcronで10分毎に実行すれば、立派なLoopの完成です。Claudeが10分毎にログを確認して、何かあったら報告してくれるようになります。

この例のプロンプトは定型ですが、都度、任意のプロンプトを組み込めたら柔軟に動いてもらえそうです。

これを、GitLabで実装します。

GitLabでのLoop Engineering実践例

今回の構成は、ざっくり以下となっています。

ポイントは以下です。

1. エージェントの種類別にシェルスクリプトを用意し、10分毎にcronで起動
2. エージェントの作業別にSkillsを用意し、Spec駆動開発を実施する
3. 各エージェントの種類に応じたIssue/MRのラベルを確認し、動作対象なら claude -p "/sdd-*** Issue/MR番号" というコマンドでエージェントを起動

特に、2のSkillsでIssueやMRの起票を明示する事で、人間はラベルの貼り替えのみでClaude Codeに作業を依頼出来ます。

Skillsの中身も踏まえると、以下のようなフローとなります。

1. 人間: plan::go ラベルを貼る
   • エージェント: Spec作成フローを開始
     • 不明点あり: ユーザへの質問をissueコメントに記載し、plan::question ラベルを貼る
       • 人間は質問へ回答し、plan::go ラベルを貼る
     • 不明点なし: Draft版MRを作成
2. 人間: MRをレビューする
   • 問題あり: エージェントへの改善点をissueに記載し、plan::go ラベルを貼って差し戻す
   • 問題なし: MRに loop::ready ラベルを貼る
3. エージェント: Spec駆動開発フローに従って実装
   • 実装完了後、loop::needs review ラベルを貼る
4. エージェント: コードレビューを実施
   • 問題あり: 指摘をコメント後、loop::change-requested で差し戻す
   • 問題なし: loop::approve ラベルを付与
5. 人間: MRをマージ

6. developパイプライン: ビルド・デプロイ・テストを実施
   • 問題なし: release watcherエージェントが develop -> main MRを作成
   • 問題あり: release watcherエージェントが対応用MRを作成し、loop::change-requested ラベルを付与
7. MRをマージ
   • 問題なし: issueの実装完了
   • 問題あり: release watcherエージェントが対応用MRを作成し、loop::change-requested ラベルを付与

以上です。

結果、人間に残されたタスクは、以下に絞られます。

• 計画を進めたいissueにラベルを貼る
• 開発を進めたいMRにラベルを貼る
• 完成したMRをマージする
• mainへのMRをマージする

これくらいなら、PCの前に座っている必要すら無いですよね。正直、スマホからGitLabにアクセス出来れば十分です。

ちなみに、GitLab Duoはスマホからでも呼べるので、エージェントにトラブルがあって人間が呼ばれても、簡単なものであればDuoに修正依頼出来ます。

Loop Engineeringの実装において重要なポイント

今回ご紹介したものは私のアーキテクチャ例ですが、もちろん他にも様々なパターンがあると思います。どんなパターンでも共通のポイントは、「AIエージェントのガードレールの作り方」です。AIエージェントを自律的に動かそうと思うと、無限ループや本番環境への意図しない作業を防ぐ仕組みが必要です。

今回のケースでは、以下をガードレールとして実装しています。

• 全てのエージェントに、タイムアウトを設定する: 無限ループによるトークンのバーストを防ぐ
• エージェントは必ずSkillsを呼び出し、手順に沿ってSpec駆動開発する: 開発手順をフロー化する事で、予期しない作業を防ぐ
• AWS環境へのデプロイは、パイプラインで行う: エージェントには一切AWS認証情報を持たせない事で、本番環境への影響を防ぐ

特に、エージェントと本番環境の認証情報を分離する事は非常に重要です。開発中のテストにはdockerを使わせて、認証情報が必要な作業はRunbook化してGitLab Runner上で実行する、など、様々な手法が考えられます。ぜひご自分の環境にあった手法を検討してみて下さい。

最後に

最近AI-DLCの伴走支援の引き合いを多数頂くのですが、この領域が最終的にたどり着くのは、AIエージェントによる完全自律稼働だと考えています。
今回Loop Engineeringを実践してみて、AIエージェントを自律稼働させる為の手法の一つとして可能性を感じました。

特にGitLabとLoop Engineeringの相性は非常に良く、この仕組みなら大概のシステムを自動化出来そうです。例えば、定期的にScheduled Pipelineとしてエージェントを起動し、プロダクトのログを分析。改善の為のIssueを作成させ、そのままラベルを貼って開発プロセスに投入する。他には問い合わせ対応をIssueベースにしてもらう事で、FAQのような使い方も出来るかもしれません。個人的には、AWS環境のメンテナンス作業をIssue化して、今回の仕組みで自動化してみようと思っています。

以上です。最後までお読みくださり、ありがとうございました！

AI-DLCの推進にパートナーが欲しいということでしたら、ぜひお気軽にGitLab社 & ソニービズネットワークスまでご相談ください！

お問い合わせはこちら

お問い合わせ内容をご記入ください欄に、https://about.gitlab.com/ja-jp/blog/loop-engineering-gitlab-claude-codeをご覧になったと記入いただくとスムーズです。

エージェント型AIは、このレビューのループを崩します。エージェントはマージリクエストを作成し、ツールを呼び出し、CI/CD設定を変更し、変更をプッシュすることができますが、その一つひとつの操作を人がレビューするとは限りません。さらに、エージェントが外部のツールやデータソースに自ら接続できるようにするModel Context Protocol（MCP）が加わることで、エンジニアリングリーダーが向き合う問いも変化します。もはや「どのモデルが最も優れたコードを書くか」ではなく、「このエージェントに何が許可されているのか、そしてその行動を事後に証明できるのか」が問われているのです。

1,500人を超える開発者およびテクノロジーリーダーを対象としたGitLab独自の調査では、回答者の73%がコードの長期的な保守性に懸念を抱いており、86%が「明確なガバナンスがなければ、AI生成コードは従来の開発手法よりも速く技術的負債を積み上げてしまう」という点に同意していることが明らかになりました。

この記事では、エージェント型AIのガバナンスにおいて各組織が直面し始めている課題に、どう先手を打って対応すればよいかを解説します。ソフトウェア開発におけるエージェント型AIのガバナンスフレームワークを紹介し、何を制御すべきか、人によるレビューがどこに残るべきか、導入状況をどう測定するか、そしてGitLab Duo Agent Platformへの標準化を進めるチームのための実践的なチェックリストを取り上げます。

エージェント型AIのガバナンスに異なるアプローチが必要な理由

対話型のコーディングアシスタントにおけるセキュリティモデルは、あらゆる段階に人が関与しているため、シンプルです。開発者が質問を投げかけ、提案をレビューし、採用するか却下するかを判断します。

自動化されたワークフローにおけるエージェント型AIには、異なるガバナンスアプローチが求められます。エージェントがテストを実行し、設定を変更し、ソフトウェア提供ライフサイクル全体にわたる複数ステップの操作を、人がその都度レビューすることなく行えるようになると、問うべき論点は次のように変わります。

• このエージェントは何にアクセスできるか
• 何を行う権限を持っているか
• どのような操作を行い、それを事後に証明できるか

すでに多くのチームがこの課題を実感しています。DevSecOps専門家の92%が、AI生成コードに関して何らかのガバナンス上の課題を抱えていると回答しており、具体的な懸念は上記の論点に直結しています。

主な懸念事項は次のとおりです。

• コードの帰属： そもそも、どのコードがAI生成で、どのコードが人間による記述かを判別できるかどうか。
• 意図へのトレーサビリティ： AI生成コードを、それが満たすべきだったビジネス要件に遡って紐づけられるかどうか。
• スケールするドキュメント化： エージェントがコードベースの生成に占める割合を増やしていくにつれ、手作業によるドキュメント化では対応しきれなくなる点。

いったんプロジェクトでエージェントの利用が承認されると、多くの場合、そのエージェントは誰かが事前にレビューすることなく、コードの記述、削除、変更のプッシュを行えるようになります。しかし、コードベースに反映される内容については、それを行ったのが人間かエージェントかにかかわらず、組織が責任を負うことに変わりはありません。

エージェント型AIのガバナンスは、コード補完のガバナンスに単に追加されるものではありません。ID、権限、監査可能性を軸に据えた、まったく異なるアプローチです。

MCP、エージェント、モデルアクセス、ツール権限の制御方法

エージェントがMCPのようなプロトコルを通じてツールを呼び出し、外部システムに接続できるようになると、権限管理こそが制御の要となります。実効性のあるガバナンスモデルは、エージェントを実行する前に、次の3つの問いに答えられるものです。

1. どのエージェントとフローの利用が許可されているか
2. どこでの稼働が許可されているか
3. エージェントはどのモデルを使用できるか

実際には、これはいくつかのレイヤーが連携して機能する形になります。

• エージェントとフローの一元管理カタログ：各チームが個別にエージェント連携を構築するのではなく、共有のAIカタログを通じて、組織の既存のロールやグループ構造に沿った形で、何を公開するかを管理者が判断できるようにします。
• コンポジットアイデンティティ： すべてのAIエージェントのIDは、その操作を要求した人間ユーザーに紐づけられるべきであり、活動がエージェント単体に帰属することがないようにします。エージェントがリソースへのアクセスを試みる際は、エージェントとそれを指示した人間の両方の主体が、アクセスを許可される前に認証・認可される必要があります。
• ツール承認ガードレール： 個々のエージェントツールは、自律的に実行する、人によるレビューのために一時停止する、あるいは完全にブロックするといった設定が可能です。これにより、ファイルの書き込みやリソースの削除といった機微な操作は、実行前に承認を待つようになります。
• プロンプトガードレール： エージェントはWebページ、Issueのコメント、攻撃者が操作するファイルなど、信頼できない入力を処理することがあるため、プラットフォーム側では、事後にログを残すだけでなく、ワークフローの途中でエージェントの挙動を乗っ取ろうとする試みを検知する必要があります。

目指すべきは、エージェントの権限を、組織がすでに人間の権限に対して行っているのと同じように扱う制御基盤です。つまり、ロールベースで、監査可能であり、すべてのプロジェクトで一貫している状態です。

データプライバシーとセルフホストAI：問うべきこと

ソースコードは企業が持つ最も機微な資産の一つであり、それを読み取るAI機能はすべて、データの取り扱いに関する問いを生じさせます。エージェント型AIを本格的に展開する前に、エンジニアリングおよびセキュリティのリーダーは、通常、いくつかの重要な問いに対して明確な答えを求めます。

• ベンダーは自社のコードでモデルを学習させているか
• 入出力データの所有権はどこにあるか
• サブプロセッサはどこに所在し、そのリストが変更された際には通知を受けられるか

規制の厳しい業界の組織にとって、「サブプロセッサはどこに所在するか」という問いへの答えは、多くの場合「自社のインフラの外には一切存在しない」でなければなりません。だからこそ、セルフホストは単なる導入方式の好みではなく、ガバナンス上の重要なレバーとなります。セルフホストの選択肢を利用すれば、チームは自らが制御するインフラ上でAIエージェントを完全に運用しながら、利用状況を正確に追跡し、規制当局の要件も満たすことができます。

自社モデル持ち込み（BYOM）への対応は、これをさらに一歩進めるものです。管理者は、社内ですでに検証済みのモデルを接続し、特定のモデルを特定のエージェントフローに割り当てることができます。この方法により、機微なワークフローは組織が信頼するモデルに固定しつつ、機微性の低いワークフローではマネージド型のオプションを利用するといった使い分けが可能になります。

Human-in-the-Loop：人によるレビューをどこに残すか

ガバナンスとは、エージェントの自律的な行動を一律に禁じることではありません。自律性がどこで終わり、レビューがどこから始まるのかを、意図的に決めることを意味します。実効性のあるポリシーは、通常、次の2つのモードを区別します。

• 対話型の作業： 開発者がその場にいて、それぞれの提案を確認し、直接承認または却下します。これは、AIコード補完を通じて多くのチームがすでに理解しているモードです。
• 自動化・ヘッドレス型の作業： CI/CDパイプライン内でエージェントが稼働するなど、開発者がリアルタイムで見ていない状況です。この場合、レビューは操作の実行前（ツール承認ガードレールによる）、または実行直後（人が確認できる監査証跡による）のいずれかで行う必要があります。

定義しておくべき重要な意思決定ポイント

コードレビュー、テストと検証、デプロイ承認は、いずれも次のような問いへの答えを通じて定義しておくべきです。

• これらのうち、エージェントが単独で完了できるものはどれか
• 変更を進める前に、特定の担当者による承認が必要なものはどれか

実際には、各チェックポイントにはそれぞれ固有の実施メカニズムが必要です。例えば次のような形が考えられます。

• マージリクエスト承認ポリシーは、マージリクエストを開いたのがエージェントか開発者かにかかわらず、着地前に誰の承認が必要かを定めます。
• エージェント向けのツール承認ガードレールは、ツールごとに、エージェントの操作を自律的に実行するか、レビューのために一時停止するか、あるいはブロックしたままにするかを決定します。
• スキャナーの強制適用は、組織が求めるセキュリティおよび品質チェックをクリアするまで、パイプラインの段階で変更を保持します。

各チームの慣習に委ねるのではなく、組織全体で統一したAIガバナンスポリシーを策定することをおすすめします。これにより、利用方法とポリシーの一貫性が保たれるとともに、監査担当者がAIの利用状況を検証しやすくなります。

ディシジョンレイヤーが加える文脈

こうした承認を、チャットのスレッドやレビュー担当者の記憶の中に消えていくままにするのではなく、構造化された記録として残しておくことには、長期的なメリットがあります。前四半期に認められた例外や、それがどのポリシーバージョンのもとで承認されたか、誰が承認したかといった情報は、監査担当者と将来のエージェントの双方が参照すべき、組織としての判断そのものです。

意思決定を、永続的でクエリ可能なイベントとして扱う企業には、次にレビューを行う人間またはエージェントが、ゼロからではなく、追加の文脈を踏まえた状態で始められるという利点もあります。

ディシジョンレイヤーについて詳しく知り、意思決定イベントの記録がソフトウェア開発にどのような影響を与えうるかをご覧ください。

AI導入の成果を測る5つの指標

最初から追跡しておくべき指標は5つのカテゴリーに分かれており、これらは個別にではなく、併せてレビューすべきものです。リスク指標を伴わない導入率の急上昇自体が、一つの警告サインとなるためです。

1. 導入状況： AI機能の週次アクティブユーザー数、実行されたフローやエージェントの数、そしてどのチームがエージェント機能を有効化していて、どのチームがまだ有効化していないか。
2. 採用状況と品質： AI支援による変更のリバート率や、AIが作成したマージリクエストが手戻りなしでレビューを通過する頻度といった、後続工程の指標です。採用率単体の数値は、採用後にそのコードがどうなったかを示さないため、効果を測る指標としては単体では不十分です。
3. リスク： ツール承認ガードレールが操作をレビューのために一時停止させた頻度、その一時停止がブロックまたは操作の修正につながった頻度、そしてエージェントの活動がポリシー違反を引き起こしたかどうかを追跡します。
4. 修正対応： プロジェクト全体のスキャナーカバレッジ、自動修正された脆弱性と手動でトリアージされた脆弱性の割合、そして検出後に問題を解消するまでの時間に注目します。
5. ROI： 四半期分のデータが揃ったら、AI投資のROIを検証しましょう。エージェントが担うようになったタスクで開発者がどれだけの時間を削減できているかを追跡し、それを解決済みIssueやマージ済み変更あたりのコスト（クレジットや計算リソースの消費量）と比較します。AIのROIを詳しく知るためのチュートリアルでは、生の利用データをビジネス上のインサイトやROI計算に変換する方法を学べます。

これら5つの指標をすべて併せて追跡することで、AI導入の問題を早期に発見できます。導入率や採用状況の面では順調に見えても、水面下でリスクが蓄積し、半年後の監査で初めて表面化するというケースもあります。上記の指標を用いることで、組織にとってのAIの価値を総合的に把握できます。

GitLab Duo Agent Platformのガバナンスチェックリスト

GitLab Duo Agent Platformへの標準化を進めるチームに向けて、パイロットの範囲を超えてエージェント型AIを拡大する前に確認しておきたい、実践的なチェックリストを紹介します。

• AI Transparency Centerを確認し、データの利用方法、モデルベンダー、サブプロセッサに関するコミットメントを理解しておく。
• どのエージェントとフローの利用を承認するかをプラットフォームレベルで決定し、各チームに個別設定させるのではなく、GitLabのAIカタログを通じて公開する。
• ツールの機微性に応じて、ツール承認ガードレールを「常に許可」「常に確認」「常に拒否」のいずれかに設定する。
• コンポジットアイデンティティを設定し、すべてのエージェントの操作を要求元の人間に紐づけ、アクセスには両者の認可を必須とする。
• 規制対象のワークロードについては、データレジデンシー要件に照らしてセルフホスト展開と自社モデル持ち込みの選択肢を評価する。
• コードレビュー、テストと検証、デプロイ承認について、明確なHuman-in-the-Loopのチェックポイントを文書化する。
• エージェントの活動について監査イベントストリーミングを有効化し、すべての操作を組織がすでにレビューしている監査証跡に集約する。
• パイロットの範囲を超えて拡大する前に、導入指標（導入状況、採用状況、リスク、修正対応、ROI）を定義し、継続的なサイクルで併せてレビューする。

このチェックリストは、リリースサイクルごとに見直しましょう。エージェント型AIのガバナンスは、一度設定すれば終わりというものではありません。新しいエージェント、新しいツール、新しいモデルが登場するたびに、ガバナンス上の論点が再び浮上することが少なくないためです。

エージェント型AIのスピードとエンタープライズの統制が交わる場所

エージェント型AIは、ガバナンスの対象そのものを変えます。コード補完が問うていたのは、その提案が良いものかどうかを開発者に確認することでした。エージェント型AIが問うのは、エージェントが何に触れることを許されているのか、誰がそれを承認したのか、そして後からそれを証明できるのか、という点です。

これらの問いに十分に答えるには、後から積み上げるのではなく、プラットフォーム自体に組み込まれたガバナンスが必要です。GitLab Duo Agent Platformは、実際に作業が行われるプラットフォームに、AIカタログ、承認ガードレール、監査イベントストリーミングを直接組み込んでいるため、ガバナンスが後付けになることはありません。ガードレールはワークフローと並行して動く別プロセスではなく、ワークフローそのものの一部であるため、チームはAIによるスピードとエンタープライズレベルの統制を同時に得られます。

GitLab Duo Agent Platformの無料トライアルを今すぐ始めましょう。Freeプランでは、簡単な手順でサインアップできます。すでにGitLab PremiumまたはUltimateをご利用の場合は、Duo Agent Platformを有効化し、サブスクリプションに含まれるGitLabクレジットをご利用いただけます。

書簡では、オープンウェイトがイノベーションを促し、顧客により大きなコントロールをもたらし、AIの安全性とセキュリティを実現する重要な道筋になると論じられています。これはGitLabも共有する政策的立場であり、エージェント型エンジニアリングに対する考え方の核心でもあります。チームが最高の成果を出せるのは、仕事に合った適切なモデルを自ら選べるときです。

GitLabは、スピードとコントロールを両立させるエージェント型ソフトウェアエンジニアリングのためのDevSecOpsインテリジェントオーケストレーションプラットフォームです。ソフトウェアライフサイクル全体をオーケストレーションし、チームのワークフローを通じて複数のモデルをサポートすることで、顧客の選択を第一に考えています。

顧客がAIモデルを選択できるようにする

最高クラスの基盤モデルとオープンウェイトモデル、その両方にガバナンスの効いたアクセスを持ちたいというニーズが、多くの組織で高まっています。GitLabはこの両方をサポートします。

基盤モデルは汎用的な能力で先行することが多く、オープンウェイトモデルはコスト、デプロイメント、データレジデンシーの面で顧客にコントロールをもたらします。両者を必要に応じて組み合わせられるようにすること、それがGitLabの目指すところです。

企業のリーダーにとって特に重い意思決定の1つが、ソフトウェアや戦略的知的財産を、セキュリティ・プライバシー・競争上の脅威からどう守るかという問題です。特定のクラウドや特定のAIモデルプロバイダーに縛られるべきではありません。

GitLabは、クラウドニュートラルかつAIモデルニュートラルを実現する唯一のプラットフォームです。ただし、この選択肢が意味を持つのは、モデル市場がオープンであり続けてこそ。オープンウェイトモデルがあるからこそ、開発チームはコードのコントロールを保ちながら、必要であればエアギャップ環境も含め、AIモデルの実行場所を自由に選べます。

私たちのスタンス

政策立案者と同じく、GitLabも安全でセキュアなAIエコシステムを望んでおり、オープン性はその実現に欠かせない要素だと考えています。真の悪用に対処するための、的を絞ったリスクベースの保護策とツールを前提としながら、オープンウェイトモデルを開発・配布・利用する能力を維持する政策を支持します。こうした介入があってこそ、オープン・プロプライエタリを問わず複数のモデルプロバイダーが実力で競い合える、健全なエコシステムが育ちます。その先にあるのが、イノベーションとセキュリティ、そして顧客の選択という利益です。

関連リンク

• GitLab AI Transparency Center
• Securing AI together: GitLab's partnership with security researchers
• DevSecOpsにおける企業の独立性がこれまで以上に重要な理由

Anthropicの最新AIモデルであるClaude Opus 5が、GitLab Duo Agent Platformで利用可能になりました。エージェントに最も高い能力が求められるタスクのために構築されたモデルです。Opus 5を使えば、エンジニアリングチームはより複雑で重要な作業をエージェントに任せられるようになります。GitLabの社内評価では、Opus 5はベンチマークタスクの93.3%を解決し、Opus 4.8の解決率73.0%から20.3ポイント向上しました。

「AIエージェントから最大の価値を引き出しているチームは、最も難易度が高く、重要度の高い作業を任せても、最初から最後まで推論が破綻しないと信頼できています」

— Stuart Moncada、GitLab AI Product Management担当VP

複雑な状況でも揺るがない推論力

最も難易度の高い作業をエージェントに任せることをためらうチームも少なくありません。ミスをやり直すコストが大きいためです。長時間にわたる高難易度のタスクでは、エージェントの推論が最初から最後まで一貫していなければなりません。Opus 5のより深い推論力により、複数ファイルにまたがる機能追加や大規模なリファクタリングといった複雑なタスクの多くが、一度で正しく解決されるようになります。これにより、失敗した実行結果を診断し、再度プロンプトを入力する時間を削減できます。GitLab Duo Agent PlatformでOpus 5を利用しているチームでは、部分的な修正パッチが減り、より多くの作業がマージ可能な状態で戻ってくることが期待できます。

この信頼性は、完遂率にも表れています。GitLabの社内テストでは、Opus 5は着手したタスクの100%を完了しており、これはOpus 4.8の完了率と同水準です。差が表れるのはその成果物の質です。Opus 5が生成したソリューションはより多くが正しいと検証されており、解決率は93.3%に達し、Opus 4.8の73.0%を上回りました。

GitLabの評価に含まれるあるタスクでは、CLI認証フローにモック可能なSSOログインサポートを実装することが求められました。新しいエクスポート型や設定フィールドを含む、5つのファイルにまたがる変更です。テストした他の複数のモデルは修正を試みることすらできませんでした。Opus 5は実装全体を構築し、コミットを行い、マージリクエストをオープンしました。

コードレビューにおいても、同様の精度が期待できます。Opus 5は実際のバグを検出し、誤検出はわずかです。そのため、チームは本当に対処すべき脆弱性に集中でき、ノイズの選別に費やす時間を減らせます。

複数のエージェントを同時に実行するワークロードでも、エージェント間の競合を解消する手間が減ります。Opus 5はサブエージェント同士の連携を保ち、互いの作業領域に干渉しないようにします。ライターと検証役を分けるパターンにより、あるエージェントが別のエージェントの出力を承認前にチェックする仕組みが働き、問題がユーザーの手元に届く前にエージェント間で検出されます。より長時間かつ自律性の高いセッションを、より多くのエージェントを並列稼働させて実行しているチームほど、その効果を強く実感できます。

複数のエージェントを並列実行するコストに敏感なワークロードでは、GitLabクレジットの利用上限を設定することで支出に上限を設けられるため、並列作業が予算を超えて実行されることはありません。

速度と深さを両立

GitLabの最も難易度が高いベンチマークタスクにおいても、Opus 5は信頼性と速度を両立しています。実行時間が長くなる95パーセンタイル値で見ると、Opus 5はOpus 4.8より2.2%速く完了し(768秒 対 784.98秒)、Sonnet 4.6より21.9%速く完了しました(768秒 対 982.57秒)。信頼性と速度は連動して向上します。チームにとっては、最も時間のかかる実行であっても、より予測しやすいターンアラウンドタイムを意味します。

タスクに応じて最適なモデルを選択

最適なモデルは組織全体で一律に決めるものではなく、目の前のタスクによって異なります。Sonnetクラスのモデルは日々の開発作業の大部分を担い、速く、コストを抑えられ、多くのチームが日常的に実行する作業に対して信頼性があります。より深い推論力が求められる作業、たとえば最も難易度の高いデバッグや大規模なリファクタリング、やり直したくない重要な意思決定には、Opus 5を選んでください。

この選択は、モデル選択機能を通じて、GitLabインスタンス上で直接設定できます。どのモデルを選んでも、GitLab Duo Agent Platform上のすべてのモデルに共通するコンテキストレイヤー、ポリシーチェック、監査証跡といった同一のインフラストラクチャ内で実行されます。

Opus 5を使ってみる

Claude Opus 5は現在、GitLab Duo Agent Platformで利用可能です。他のモデルと同様に、GitLabクレジットで利用します。Duo Agent Platformをまだお使いでない方は、今すぐ無料トライアルを開始してください。すでにGitLab PremiumまたはUltimateをご利用の方は、Duo Agent Platformを有効化し、サブスクリプションに含まれるGitLabクレジットをご利用ください。

AIコーディングエージェントであるCursorは、こうした問題のうち焦点を絞った部分を得意としています。失敗しているテストや範囲が限定されたイシューを1つ渡せば、実装を調査し、何が問題だったのかを説明し、修正案を提示し、開発フローから離れることなくテストを実行できます。しかし、複数ステップにわたる移行全体で「安全」が何を意味するかは、Cursorが単独で判断できるものではありません。

ここで登場するのがGitLabです。Duo Agent Platformがソフトウェアライフサイクルの残りの部分でAIワークフローをオーケストレーションし、コーディングエージェントの作業を検証できるよう設計されています。エピックによるイシューの階層構造により、計画は永続的でレビュー可能なものになります。GitLab Model Context Protocol（MCP）サーバーは、こうしたソフトウェア開発ライフサイクルのコンテキストをCursorに取り込みます。CI/CD、セキュリティスキャン、コードレビュー、影響分析、そしてサービス横断的なテストが、本番環境での挙動を変更する前に必要となるエビデンスを提供します。

このチュートリアルでは、CursorとGitLabを使った3つのユースケースを解説します。

1. Cursorで失敗しているJavaのエンドツーエンドテストを修正する
2. Java 8から21へのモダナイズに向けて品質ゲートを準備する
3. Java 21でHTTP接続処理をモダナイズする

この進め方には意味があります。まず小さく始め、プロジェクトのコンテキストを加え、そのうえで1つの境界をモダナイズする。Cursorはその境界の中で高速に動きます。そのスピードを安全に保っているのが、Code Review Flow、Developer Flow、CI/CD、コードオーナーの承認、そして影響分析です。これらは省略可能なチェックポイントではなく、エージェントが作成したすべてのマージリクエストを他と同じ基準に保つための仕組みです。

3つのユースケースすべてで、Tanuki IoT PlatformのJava HTTPメトリクスコレクターを使用します。このコレクターはHTTPエンドポイントをチェックし、レスポンスステータスや応答時間などのメトリクスを記録して、Rustメトリクスバックエンドに読み取り値を送信します。これにより、モダナイズ対象となる目に見えるアプリケーション境界と、検証すべき実際のバックエンド契約が得られます。以前、Codex and GitLabのチュートリアルでこのRustバックエンドを構築しており、現在は本番アーキテクチャの一部として機能しています。

flowchart LR
  subgraph sources["HTTP metric sources"]
    direction TB
    health["Health endpoint"]
    maintenance["Maintenance endpoint"]
  end

  java["Java HTTP metrics collector"]
  rust[("Rust metrics-store backend")]

  java -->|"GET"| health
  java -->|"GET"| maintenance
  java -->|"POST /api/metrics"| rust
  rust -->|"HTTP response"| java

  classDef source fill:#f8fafc,stroke:#64748b,stroke-width:2px,color:#0f172a
  classDef focus fill:#dcfce7,stroke:#16a34a,stroke-width:3px,color:#0f172a
  classDef backend fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0f172a

  class health,maintenance source
  class java focus
  class rust backend

前提条件

1. Cursorがインストール・設定済みであること。本チュートリアルではCursor IDEを使用します。
2. Javaコレクターのソース、イシュー、モダナイズ用の作業アイテムを含むGitLabプロジェクト。Tanuki IoT PlatformのJava HTTPメトリクスコレクターを使用できます。
3. 最初のユースケース用にJava 8、モダナイズ作業用にJava 21
4. ローカルビルドと機能テスト用のMaven、Docker、Docker Compose
5. GitLabインスタンスまたはトップレベルグループで有効化されたGitLab MCPサーバー
6. Javaコレクタープロジェクトで有効化されたGitLab Duo Code Review Flow、Developer Flow、そして破壊的変更の影響分析用カスタムフロー。これらのフローは、エージェントが作成するすべてのマージリクエストにプロジェクトのガードレールを適用します。

GitLabプロジェクトを準備する

自分の環境でこのワークフローを再現したい場合は、まずプロジェクトをインポート・クローンし、Cursorでプロジェクトを開くところから始めます。

1. Tanuki IoT PlatformのJava HTTPメトリクスコレクターを、未解決のイシューも含めてGitLab環境にインポートします。
2. プロジェクトをローカル環境にクローンし、そのディレクトリに移動します。
3. Cursorでプロジェクトを開きます。

git clone https://gitlab.com/gitlab-da/demo-environments/tanuki-iot-platform/sensors/java-http-metrics-collector.git
cd java-http-metrics-collector

cursor .

このプロジェクトには、リポジトリの指示とMavenコマンドが記載されたAGENTS.mdファイルが含まれています。Cursorはこのローカルの指示を利用して、プロジェクトの構成や変更のテスト方法を理解できます。

Cursorで失敗しているエンドツーエンドテストを修正する

このコレクターでは、エンドポイントから期待するHTTPステータスコードをユーザーが設定できます。しかし実装上は、すべての2xxレスポンスを成功として扱ってしまい、503エラーは期待どおりに設定されていても常に失敗として扱われていました。

エンドツーエンドテストはすでにこの不整合を検出していますが、CI/CDジョブは失敗が許容される設定になっています。そのため、本来役立つはずのシグナルが、当たり前に受け入れられる背景ノイズになってしまっていました。

Cursorで再現・修正する

この問題はローカル環境で再現できます。Cursor IDEで新しいチャットを開き、まずはプロンプトで観測された問題を直接説明することから始めます。

Can you help me fix the end-to-end tests in this project? Please create an analysis first, then fix it, and run the tests again.

Cursorはまず、エンドポイントの設定をHttpCollectorと失敗しているエンドツーエンドテストまで遡って調査し、根本原因を特定します。

対象のテストとMavenのテストスイート全体が通過したら、ブランチとマージリクエストを作成します。これまで失敗が許容されていたエンドツーエンドジョブは、決定的に成功する状態になれば、必須ジョブに変更できます。

Can you create a git branch and merge request?

レビューとマージ

マージリクエストを作成すると、CI/CDのビルドとテスト、セキュリティスキャンが自動的にトリガーされます。

続いて、GitLab Duo Code Reviewが、プロジェクト固有のJavaレビュー指示に基づいて、対象の変更をレビューします。

レビューで具体的な問題が指摘された場合は、マージする前にDeveloper Flowを通じて対応します。ここが重要なポイントです。Code Review Flowは、Cursorがどれだけ速く生成したものであっても、エージェントが作成したすべてのマージリクエストが他と同じ基準を満たすことを保証します。マージリクエストは、あくまでコラボレーションと意思決定の場であり続けます。

この修正により、動作面のベースラインが得られます。ランタイムの移行と混在させることなく、実際のバグを修正できたことで、テストは今後のモダナイズ作業を通じて期待ステータスの契約を守ってくれます。

Cursorが期待どおりのエンドツーエンドテストをどのように調査・修正するかは、以下の動画で確認できます。

Java 21へのモダナイズに向けて品質ゲートを準備する

最初の修正は、リポジトリのコンテキストだけで完結しました。次のリクエストははるかに大規模です。コレクターをJava 8からJava 21へモダナイズすることです。

この作業については、すでにJavaモダナイズのエピックに計画のコンテキストがそろっています。子の作業アイテム、チームでの議論、マージリクエストを伴う調査、パイプラインの履歴、依存関係、セキュリティの検出結果などです。これらの詳細はローカルのチェックアウトには存在しません。そのすべてを1つの巨大なプロンプトにコピーするのではなく、MCPを使ってGitLabのコンテキストをCursorに取り込むことができます。

CursorでGitLab MCPサーバーを設定する

GitLab MCPサーバーが、自分のインスタンスまたはトップレベルグループで有効化されていることを確認してください。Cursorは、追加の依存関係なしに直接接続できるHTTPトランスポートを使用します。

CursorをGitLab MCPサーバーに接続するには、以下の手順に従います。

1. Cursorで、Settings > Cursor Settings > Tools & MCPに移動します。
2. Installed MCP Serversの下にあるNew MCP Serverを選択します。
3. 開かれたmcp.jsonファイルのmcpServersキーに、以下の定義を追加します。GitLab.comの場合は<gitlab.example.com>をgitlab.comに置き換えてください。GitLab Self-ManagedまたはDedicatedの場合は、自分のGitLabインスタンスのURLを使用してください。

{
  "mcpServers": {
    "GitLab": {
      "type": "http",
      "url": "https://<gitlab.example.com>/api/v4/mcp"
    }
  }
}

4. ファイルを保存し、ブラウザでOAuth認証ページが開くのを待ちます。開かない場合は、Cursorを終了して再起動してください。
5. ブラウザで認証リクエストを確認し、承認します。
6. Cursorに戻り、表示されているツールの一覧を確認します。

これで新しいチャットを開始し、利用可能なGitLab MCPツールに基づいて質問できるようになります。

CursorがGitLab MCPで認証すると、既存のGitLabアイデンティティとして動作します。アクセスできるのは、自分がすでにアクセス権を持つプロジェクトやリソースに限られます。MCPは承認済みのコンテキストをIDEに取り込むものであり、GitLabの権限をバイパスするものではありません。

Java 21モダナイズに向けて環境を準備する

Java 8から21へのモダナイズのエピックでは、必要な計画がより小さなイテレーションに分割されており、各成果物と変更がそれぞれ単独でテスト可能になっています。

最初のステップは、CI/CDインフラでJava 8と21の両方を並行してテストできるようにすることです。各モダナイズタスクの開始時点からテストカバレッジを高めていくことも必須です。

Cursor IDEを開き、以下のプロンプトを使って計画のコンテキストを取得します。

Please help me modernize this sensor from Java 8 to 21. We want to start with the base line for CI/CD builds in work item 14, and then also look into test coverage from 21. Start the implementation in a new Git branch called `maint-java-21` so we can continue testing different scenarios.

CIビルドの可視化に関するイシューの作業が完了したら、Cursorはcreate_workitem_noteのMCPツールを使って、イシューに要約コメントを追加することもできます。

新しいマージリクエストは、CI/CDパイプラインとCode Review Flowの両方をトリガーします。Code Review Flowは、開発スタイルガイドが要求するドキュメント化についてコメントを残します。

Developer Flowのサービスアカウントにメンションすることで、GitLabのUI上でフィードバックにすぐ対応できます。

@duo-developer-<group-name> Can you help address the review feedback?

このプロンプトによって新しいバックグラウンドセッションが開始されるため、その間は他のタスクに集中できます。あるいは、Cursor IDEに戻り、チャットでマージリクエストのレビューフィードバックに対応するよう指示することもできます。

Cursorは変更を実装し、create_merge_request_noteのMCPツールを使って、マージリクエストのスレッドにコメントを追加します。

この変更では、一時的なJava 8のベースラインを維持しつつ、Java 21向けの独立したビルドとテスト検証を追加します。これにより、ソースコードがJava 21専用のAPIを使い始める前の段階で、互換性がパイプライン上で可視化されます。こうした品質ゲートが整えば、以降のエージェント主導のすべての変更は、レビューされ、テストされ、追跡可能になります。これは他のマージリクエストと同じ基準であり、だからこそCursorを安心して高速に動かせるのです。

CursorがGitLab MCPを使って品質ゲートを準備し、コードレビューのフィードバックに対応する様子は、以下の動画で確認できます。

Java 21でHTTP接続処理をモダナイズする

Java HTTPメトリクスコレクターは現在、Java 8の従来型APIHttpURLConnectionを使用しています。Java 21ではHTTPライブラリがjava.net.http.HttpClientにモダナイズされましたが、これは単なる機械的なリネームではありません。リダイレクト、制限付きヘッダー、タイムアウトの範囲、レスポンスボディ、割り込み、接続の再利用など、挙動が異なりうる要素は多岐にわたります。だからこそ、この実装は1つの範囲が限定された作業アイテム、Replace HttpURLConnection with java.net.http.HttpClientに閉じています。実際にやってみましょう。

Cursor IDEで新しいチャットを開き、変更の実装を依頼します。

注: このユースケースでは、変更の検証にローカルのDocker Compose環境を使用します。この挙動を再現したい場合はDockerとDocker Composeをインストールしてください。不要な場合は2つ目のプロンプトを省略してください。

We want to continue modernizing the app to Java 21 - use the same maint-java-21 branch, and start implementing issue 16.

Verify the changes locally using the docker compose setup, after making the changes.

GitLab MCPサーバーは、イシューのコンテキスト、受け入れ基準、依存関係、関連する議論を提供します。最初のコードモダナイズのイシューは、意図的に同期的かつ限定的な範囲にとどめています。HttpURLConnectionを、再利用可能な1つのHttpClientに置き換えるだけで、仮想スレッドの追加や時間モデルの変更、関連のない依存関係の修正は行いません。これらは価値のあるフォローアップですが、一緒に行ってしまうと、挙動の変更を切り分けてレビューし、ロールバックすることが難しくなります。

ローカルで実装・検証する

対象を絞ったローカルのHTTPサーバーテストでは、メソッド、ヘッダー、期待されるステータスコードと想定外のステータスコード、リダイレクト、タイムアウト、レスポンスのメタデータ、接続の失敗、割り込みをカバーします。

続いてDocker Composeの機能テストにより、認証済みの読み取り値がrust-metrics-storeバックエンドに引き続き到達することを確認します。

変更後にCI/CDパイプラインが失敗している場合は、GitLab MCPサーバーのツールを活用し、コンテキストを切り替えることなくCursor IDE上で直接調査・修正できます。

GitLabのUIでは、Fix CI/CD Pipeline Flowを使用するか、CI Expertエージェントに助けを求めることができます。

CI/CDとレビューのエビデンス

GitLab CI/CD、GitLab Duo Code Review、セキュリティスキャン、そしてAIによる影響分析が、マージリクエストにおける最終的なエビデンスとなります。それでも、微妙な境界においては人によるレビューが最も重要です。意図的な挙動の違いは、デプロイ後に発覚するのではなく、マージリクエストの時点で明示されているべきです。

CursorとGitLabがコレクターのHTTPライブラリをJava 21にどのようにモダナイズするかは、以下の動画で確認できます。

CursorとGitLabを使うためのヒント

CursorとGitLabを組み合わせて使うためのヒントを紹介します。

モダナイズに伴う破壊的変更の影響分析を自動化する

3つ目のユースケースでは、Developer Flowが破壊的変更の影響分析を行う様子を紹介しました。このワークフローは、マージリクエストの準備が整ったとき、あるいはパイプラインが正常なときにトリガーされる自動化されたカスタムフローに変えることができます。追加のコンテキストは、コード、作業アイテム、マージリクエスト、脆弱性などを横断するコンテキストグラフを提供するGitLab Orbitから取得できます。

サンプルのフローは、AI CatalogのMR Impact analysis (Orbit)から確認できます。着想をくれたチームメイトのFatima Sarah Kalidに感謝します。カスタムフローはGitLab 19.2で一般提供されています。

エージェント向けにガイドラインと境界を明文化する

JavaのためのAGENTS.md

AGENTS.mdファイルは、プロジェクトのアーキテクチャ、コマンド、コードスタイル、テストに関する期待、境界をCursorや他のコーディングエージェントが理解する助けとなります。こうした指示はコードのそばに置き、検証できる程度に具体的にしておきましょう。

Java HTTPメトリクスコレクタープロジェクトのAGENTS.mdからの例です。

# Java HTTP Metrics Collector - Agent Instructions

## Overview

The Java HTTP Metrics Collector is a REST API metrics collection sensor for the Tanuki IoT Platform. It monitors HTTP endpoints, collects performance metrics (response time, status codes, content length), and exports them in Prometheus text format. The application runs continuously with configurable collection intervals and supports concurrent endpoint monitoring.

## Code Style and Standards

### Java 8 Compatibility

- Do not modernize Java 8 code to Java 11+ features unless there is a GitLab issue or task specifically requesting modernization
- Target Java 8 for source and compilation: `maven.compiler.source=1.8` and `maven.compiler.target=1.8`
- Use Java 8 compatible patterns (e.g., anonymous inner classes instead of lambdas where appropriate)

### Documentation

- All public classes must have Javadoc describing purpose and usage
- All public methods must have Javadoc with `@param` and `@return` tags
- Include code examples in main class Javadoc

### Class Organization

- **Main entry point**: `HttpMetricsCollector` - orchestrates configuration loading, metric collection, and export
- **Collector**: `HttpCollector` - performs HTTP requests and collects metrics
- **Exporter**: `PrometheusExporter` - exports metrics in Prometheus text format
- **Models**: `CollectorConfig`, `EndpointConfig`, `HttpMetric` - data transfer objects

### Dependency Management

- Always use Maven for dependency management
- Use property-based version management for dependencies (e.g., `${jackson.version}`)
- Keep dependencies up-to-date in `pom.xml`

### Error Handling

- Use try-catch blocks with proper resource management (try-with-resources where applicable)
- Log errors using SLF4J Logger
- Gracefully handle configuration loading failures
- Implement proper shutdown hooks for resource cleanup

### Concurrency

- Use `ExecutorService` for concurrent HTTP requests
- Thread pool size is limited to the minimum of endpoint count and 10
- Properly shutdown executor service with timeout handling
- Use `Future` objects to collect results from concurrent tasks

Javaのコードレビュー指示

GitLab Duo Code Review Flowは、スタイルガイドと境界を維持する助けとなります。そのためには、.gitlab/duo/mr-review-instructions.yamlファイルに具体的な指示が必要です。例えばJava向けは次のとおりです。

# Custom instructions for GitLab Duo Code Review

instructions:
  # General guidelines

  - name: Code Review
    instructions: |
      1. Focus on correctness and performance
      2. Ensure code comments and documentation are clear and concise
      3. Be respectful and constructive in comments

  - name: CI/CD Configuration
    fileFilters:
      - ".gitlab-ci.yml"
    instructions: |
      1. Do not use YAML anchors
      2. Always use rules in jobs, avoid using `only`

  # Java style guide

  - name: Java Style Guide
    fileFilters:
      - "**/*.java"
    instructions: |
      1. Do not modernize Java 8 code to Java 11+ features, unless there is a GitLab issue or task specifically requesting modernization
      2. All public classes must have Javadoc describing purpose and usage
      3. All public methods must have Javadoc with @param and @return tags
      4. Include code examples in main class Javadoc
      5. All public methods must have at least one test case
      6. Use httpbun.com for test endpoints (status codes, delays, JSON responses)

コードのモダナイズを進める過程で、Java 8の強制に関する最初のガイドラインは更新が必要になります。

実証済みのワークフローをエージェントスキルにする

専門的なワークフローが繰り返し使えるようになったら、それをエージェントスキルとして記録します。スキルはオンデマンドで読み込まれ、デフォルトではコンテキストウィンドウを占有しません。

エージェントスキルが、未検証の計画ではなく実証済みの実践を反映したものになるよう、まずは動作するCI/CD、テスト、レビュー済みの意思決定から始めましょう。モダナイズのエピックにおけるイシュー24は、このアプローチを、範囲を絞ったJava 21以降向けのモダナイズ用エージェントスキルとしてまとめています。これは、現在のマージリクエストを超えた価値をもたらします。今後のエージェントセッションは、過去の議論から再構築するのではなく、同じ安全境界を再利用できるのです。

既存のJava 8 Maven保守スキルに着想を得た、以下のサンプルスキル実装を試してみてください。

---
name: java21-modernization
description: >-
  Guide incremental Java 8 to Java 21+ modernization for the HTTP metrics
  collector. Use when a GitLab work item asks for Java 21 CI visibility,
  runtime/image upgrades, HttpClient migration, dependency or source API
  modernization, or review of maint-java-21 style merge requests. Do not use
  for routine Java 8 maintenance; prefer java8-maven-maintenance instead.
compatibility: Requires Maven, Docker Compose, and access to the owning GitLab work item.
---

# Java 21 Modernization

## Overview

Modernize in small, reviewable steps. The owning work item is authoritative.
Preserve collector → Rust metrics-store behavior unless the issue says otherwise.

Companion skill: `skills/java8-maven-maintenance/` for the Java 8 default path.

## Before editing

1. Read the owning issue/epic, `AGENTS.md`, `.gitlab-ci.yml`, `pom.xml`,
   `Dockerfile`, and affected tests.
2. Record the current baseline:
   - `maven.compiler.source` / `target`
   - default CI image vs any `*:java-21` jobs
   - container base image
   - observable CLI/Compose behavior
3. Classify the change into **one** lane:
   - CI visibility only
   - runtime / image switch
   - source / API modernization
   - dependency upgrade
   - tests / contract checks

Do not combine lanes in one MR unless the work item explicitly requires it.

## Workflow

Copy and track:

```text
Modernization progress:
- [ ] Baseline recorded
- [ ] Scoped to owning work item
- [ ] Target-JDK CI evidence available before JDK-only APIs
- [ ] Java 8 lane preserved until exit criteria say otherwise
- [ ] Unit / IT / Compose checks run
- [ ] MR documents risks, rollback, human decisions
```

## Guardrails

- Do not remove Java 8 compatibility unless the work item authorizes it.
- Do not introduce Java 21-only APIs before target-JDK CI evidence exists.
- Do not mix runtime upgrades with unrelated refactors.
- Do not claim performance wins without measurements.
- Preserve the Java → Rust API and authentication contract.
- Stop for a human decision when support policy, rollback, data format, or downstream compatibility is unclear.

## Validation

```bash
mvn -Dmaven.repo.local=.m2/repository test
mvn -Dmaven.repo.local=.m2/repository clean package
```

If Compose or container files change:

```bash
docker compose config --quiet
TANUKI_INGESTION_TOKEN=replace-me docker compose up -d --build
# confirm metric_sample logs and authenticated ingest still work
docker compose down -v
```

## Completion report

In the MR description, include:

1. Baseline before the change
2. Lane changed (CI / runtime / source / deps / tests)
3. Evidence run (commands + CI jobs)
4. Remaining risks and rollback
5. Human decisions still open

## Out of scope

- Broad "modernize everything to Java 21" prompts
- HTTP endpoint semantics unrelated to the JDK migration
  (use `skills/http-endpoint-collector-behavior/`)
- Security triage unrelated to the migration slice
  (use `skills/security-triage-java-sensor/`)

まとめ

このチュートリアルで紹介した3つのユースケースは、それぞれが積み重なっています。まずCursorは、リポジトリのコンテキストだけを使って、受け入れられていたエンドツーエンドテストの失敗を修正しました。次にGitLab MCPサーバーがモダナイズ計画を取り込み、Cursorは品質ゲートを整備しつつ、IDEから直接Duoのレビューフィードバックへの対応を完結させることができました。そして最後に、CursorはHttpURLConnectionを再利用可能なHttpClientに置き換えるという、1つの範囲が限定されたJava 21の変更を行い、対象を絞ったテスト、サービス横断的な取り込みの実行、パイプライン、セキュリティスキャン、ソフトウェア部品表、レビューのエビデンス、影響分析によって裏付けました。

レガシーなJava 8のコードベースは、エージェントがコードを書いているからといって、モダナイズが安全になるわけではありません。安全になるのは、すべての変更が範囲を限定され、レビューされ、Java 8とJava 21の両方に対してテストされ、その背後にある意思決定とエビデンスとともに作業アイテムまで追跡できるからです。実装を担うのはCursorです。そして、その証明を担うのがGitLabです。両者が組み合わさることで、この移行はチームが信頼できるものになります。

このワークフローを試してみたい場合は、レガシーなアプリケーションで受け入れられている失敗を明らかにする1つのテストから始めてください。そのテストを信頼できるものにし、より大きなモダナイズ計画をGitLabに記録し、独立して変更・証明できる1つの境界を選びます。そうすることで、エージェントには焦点を絞ったタスクが、チームにはレビューできるエビデンスが与えられます。

もしまだGitLab Duo Agent Platformを利用していない場合は、無料トライアルから始められます。

すでに無料プランでGitLabを利用している場合は、簡単な手順に沿って、GitLab Duo Agent Platformに申し込めます。

そして、すでにGitLab PremiumまたはUltimateをご利用中の場合は、Duo Agent Platformを有効化するだけで、サブスクリプションに含まれているGitLabクレジットを使い始められます。

フローがリアルタイムで発火し、ルーティングと割り当てを行う様子をご覧いただき、継続的でハンズオフな自動化が自分のプロジェクトにどのような効果をもたらすか、ぜひ想像してみてください。

課題：手作業による割り当てはスケールしない

プロジェクトをまたいで作業を手作業で割り当てるのは、見た目以上に大変な作業です。単発の意思決定ではなく、毎日何十回も繰り返される判断の連続だからです。新しいイシューが発生するたびに、誰かが手を止めてチームのキャパシティを確認し、現在のワークロードと新規タスクを比較検討したうえで、担当先を決めなければなりません。会議や休憩、PTO（有給休暇）なども考慮に入れると、このプロセスはさらに長引きます。小規模であればこの方法でも機能しますが、量が増えるにつれて一気に破綻し、トリアージの遅延や作業配分の偏り、そしてチームリードが本来取り組むべき価値の高い仕事ではなく振り分け作業に時間を奪われるといった問題を引き起こします。

つい最近まで、こうした摩擦はフローの仕組みそのものに組み込まれていました。あらゆるGitLab Duo Flowは、開始するためにUI上での人間によるアクション（メンションや担当者の割り当て、レビュアー割り当てイベントなど）を必要としていました。プログラムからフローを駆動したり、何かが起きた瞬間に発火させたりすることは、誰かが手動でトリガーを引かない限り不可能だったのです。そのため、どれほどよく作り込まれた割り当てフローであっても、起動には人の手を待つ必要がありました。

「作業アイテム作成」トリガーが解決策になる仕組み

「作業アイテム作成」トリガーは、このギャップを埋めます。プロジェクト内で新しい作業アイテムが作成された瞬間に自動で発火し、手動での引き継ぎは一切不要です。誰かがイシューに気づき、チームのワークロードを評価してから割り当てるのではなく、フローが自らアクションを起こしてルーティングを代行します。トリガーを使えば、組織が定めた条件が満たされた時点でフローがバックグラウンドで継続的に実行されるため、開発者は本当に判断力が求められる作業に集中し続けられます。

メリットと効果

「作業アイテム作成」トリガーには、次のようなメリットがあります。

即時かつハンズオフなトリアージ
作業アイテムが作成された瞬間に割り当てとルーティングが行われ、誰かの手が空くのを待つ必要はありません。

どんな量にも対応するスケーラビリティ
1件でも数百件でも、トリガーが誰の負担を増やすこともなく数秒で処理します。

よりスマートでバランスの取れた割り当て
フローは割り当て前に各メンバーの現在の負荷や稼働状況を考慮できます。人間が下すのと同じ判断を、一貫して適用します。

単純作業からチームを解放
未処理の作業アイテムを手作業で仕分けして誰に余裕があるかを判断する必要はもうありません。エージェントが、人間と同じ情報をもとに判断を下します。

自動割り当ての実例：ステップバイステップ・チュートリアル

具体的なイメージをつかんでいただくため、Intra-account-transfersというプロジェクトを使った実際のシナリオを見ていきましょう。

1. トリガーの設定

「Work item assigner」という名前のフローを作成し、そのプロジェクトで作業アイテムが作成されるたびに実行されるよう設定しました。

2. フローの構成

「Work item assigner」フローは2つのエージェントで構成されており、それぞれに従うべき手順と使用するツールを詳細に定めたプロンプトが設定されています。1つ目のエージェントはGitLab Orbitを使用して、組織内の各リソースの現在のワークロードを把握します。GitLab Orbitは、ソフトウェアエンジニアリングのためのライフサイクルコンテキストグラフであり、Duo Agent Platform内のAIエージェントをより高速かつ高精度にします。

2つ目のエージェントは、未処理の作業アイテムが最も少ないメンバーを特定し、新しい作業アイテムをそのメンバーに割り当てます。

割り当てロジックはフロー内に組み込まれているため、プロセス全体を動かすにはトリガーさえあれば十分です。

3. トリガーが発火する様子

3.1. まったく新しい作業アイテムを作成します。

3.2. イシューが作成された瞬間にトリガーが発火し、「Work item assigner」フローが自動的に開始します。フローのアクティビティログでは、その進行状況をステップごとに確認できます。1つ目のエージェントがプロジェクト情報を取得し、GitLab Orbitのツールを使ってトップレベルグループ全体の各ユーザーの未処理の作業アイテム数をカウントします。

続いて2つ目のエージェントが最も負荷の低いメンバー（このデモではWilliam）を特定し、実際の割り当てを実行します。

4. 最も負荷の低いメンバーへの割り当てを確認

イシューに戻って確認すると、新しい作業アイテムがWilliamに自動的に割り当てられていることがわかります。

5. 一連の流れで見るメリット

このシナリオが物語っているのは、作業を担う主体そのものの変化です。人間が未処理の作業アイテムを仕分けて誰に余裕があるかを判断し、手作業でイシューを割り当てる代わりに、「作業アイテム作成」トリガーによって呼び出されるGitLab Duo Agent Platformのカスタムフローが、そのすべてをわずか数秒でこなします。人間が使うのとまったく同じ情報をもとにエージェントが判断できる定型業務からチームを解放し、人はここぞという場面に注意を向けられるようになります。

6. さらなる応用

このカスタムフローには、次のような拡張の余地も考えられます。

• Model Context Protocol（MCP）連携を人事システム（またはPTOシステム）に追加し、作業アイテムの割り当て時に各リソースのPTO予定を考慮できるようエージェントを拡張する。
• リソースのカレンダーへのMCP連携を追加し、作業アイテムの割り当て時に各リソースの空き状況を考慮できるようエージェントを拡張する。

今すぐ始める

大量に発生する作業の割り当ては、これまで静かにチームの体力を奪ってきました。1日に何十回も、ワークロードと空き状況を確認してからイシューを振り分けるという細かな判断が必要で、量が増えるほどこのプロセスは破綻していきます。GitLab Duo Agent Platformの「作業アイテム作成」トリガーは、作業アイテムが作成された瞬間にフローを発火させ、手動での引き継ぎを一切不要にすることで、このボトルネックを解消します。上記のステップバイステップ・チュートリアルで示したとおり、GitLab Orbitを活用した2エージェント構成のフローは、チームの実際のワークロードを把握し、最適な担当者に各新規アイテムを数秒で割り当てられます。その結果、トリアージが迅速化し、ワークロードのバランスが改善され、チームは本当に人間の判断が必要な仕事に集中できるようになります。

今すぐGitLab Duo Agent Platformの無料トライアルを始める。

GitLab Orbitは、コード、マージリクエスト、パイプライン、デプロイメント、所有権をひとつのグラフとして常に最新の状態で保持し、いつでもクエリできるようにする仕組みです。エージェントはコードを書くのは得意ですが、その周りのシステムを理解するのはあまり得意ではありません。「これは何に依存しているのか」「どのテストがカバーしているのか」「影響の責任を負うのは誰なのか」——こうしたつながりを問う質問に答えるには、これまでエージェントがファイルをかき集めるか、エンジニアが4つものツールを行き来して調べるしかありませんでした。Orbitがあれば、それが一度のクエリで済みます。エージェントはModel Context Protocol（MCP）経由でOrbitにアクセスし、エンジニアは直接クエリを実行でき、答えは数時間ではなく数秒で返ってきます。詳しくはOrbitのホームページをご覧ください。私たちが見たかったのは、そのグラフが自分たちのものになったとき、人々が何を作り出すかということでした。

登録者数は1,576人。ショーケーストラックでは、GitLab Orbit上に作られたエージェントやフロー、スキルなど、応募資格を満たす265のプロジェクトが完成しました。それとは別に、26名のコントリビューターがOrbitのコードベースに61件の改善を直接マージしています。言語サポートの追加、バグ修正、ドキュメントの改善——コミュニティはOrbitの上に何かを作っただけでなく、Orbitそのものをより良くしてくれました。

開発者たちを引きつけた課題

審査に入る前、ひとつ気づいたことがあります。応募作品を「実際に何をするか」で並べ替えると、分布が大きく偏るということです。

70チームが同じ発想のツール、つまり「マージする前に、この変更が何を壊すか教えてほしい」を形にしています。30を超えるチームが取り組んだのは、オンボーディングや理解を助けるツール——「このコードベースを理解する手助けをしてほしい」という課題です。その後に続くのが、インシデントの根本原因分析、アーキテクチャのドリフト、不安定なパイプラインの診断、複数リポジトリにまたがるCVEの追跡でした。

これは偶然ではありません。エンジニアはこうした問いを日常的に投げかけながらも、答えがGit、CI、デプロイツール、そして誰も信頼していないダッシュボードのあちこちに散らばっていたせいで、うまく答えられずにいました。ひとつのグラフにまとめてしまえば、人は迷わずそこへ向かうものです。

これは、コンテキストを伴ったオーケストレーションです。単なる自動化ではなく、スピードに制御が組み込まれている。そして、誰に指示されたわけでもないのに何十もの独立したチームが同じクエリにたどり着く——これこそ、プラットフォームのオーナーが読み取るべきシグナルです。仕事の実体は、コンテキストの中にあるということです。応募が集中したカテゴリーほど、基準は高くなりました。他の68チームを上回るか、誰も足を踏み入れなかった領域に進むか。プロジェクトが際立つ道は、そのどちらかでした。

技術実装

優勝：Sankofa 1日のなかの異なる瞬間をきっかけに動く3つのエージェントが、いずれもGitLab Orbitからデータを読み取ります。マージリクエストを開けば、Radarが影響範囲——下流の呼び出し元、影響を受けるパイプライン、責任を負うチーム——を提示します。issueがアサインされれば、着手する前にGuideが概要をまとめてくれる。脆弱性が見つかれば、Shieldがそこに至るすべての経路を洗い出します。コンテキストはこちらから探しに行かなくても届き、役目を終えれば静かに姿を消します。

「セキュリティの脆弱性が報告されると、自動的に点と点をつなぐ仕組みがないため、チームはその影響範囲を手作業で追跡するのに何日も費やすことになります」

Lester K氏、Sankofa

Shieldは、それをグラフ上のたった一度の走査でやってのけます。

準優勝：Stayed Shipped
問いかけるのは、どのダッシュボードにも答えられないことです。先月AIエージェントがマージした変更のうち、今も本番環境で生きているのはいくつあるか。マージされた変更が生き残っているのか、それともシニアエンジニアの手で静かに直され続けているのか——これは、どんな標準的な指標にも表れない動きを追跡する試みです。

デザインと使いやすさ

優勝：Carver
Carverは、着手を決める前にレガシー移行の見積もりを出してくれるツールです。何を移行したいかを伝えるだけで、GitLab Orbitの依存関係グラフを読み取り、対象の単位数、所要期間、進める順序、リスクの所在まで見積もってくれます。このカテゴリーで評価を集めたのは、その出力の見せ方でした。単位ごとに1行、規模とリスクを添えて提示し、詳細は必要なときだけ展開する。AngularJSからAngularへの移行なら、生成コスト10ドルに対しておよそ9週間の人的作業と見積もられ、テストされていない基幹サービスは赤で示されるので、まず何を確認すべきかが一目でわかります。

「Orbitを確認し、そのサービスが見つからない場合は、実際のコードがどこにあるかを尋ねます」

Anes Mulalic氏、Carver

根拠のない数字を並べることを、このエージェントは拒むのです。

準優勝：Marshal
同じ領域を、まったく逆のアプローチで攻めます。目指すのは完全な自律性。組織全体の目標をひとつ宣言すれば、あとはGitLab Orbitを通じて影響を受けるすべてのリポジトリを特定し、作業の順序を組み立て、対象を取りこぼすことなく波状にマージリクエストを着地させていきます。

波及効果

優勝：CrossCut
CrossCutが実行するのは、変更が実際に壊しうるテストだけです。マージリクエストを開けば、変更されたシンボルを取得し、GitLab Orbitのコールグラフをたどって真の推移的影響を割り出し、そのテストだけを走らせるパイプラインを組み立てます。モデルは介在しません。推測もしません。ただグラフをたどるだけです。規模の大きいスイートやリポジトリ横断のスイートなら、CIの処理量を90%以上削減でき、導入コストはほぼ即座に回収できます。

「変更がどのテストに到達しうるかを知るには、コードベース全体のコールグラフが必要です。それはまさにGitLab Orbitが構築しているものなので、私たちは推測する代わりに、グラフに尋ねるだけです」

Pritesh Kumar氏、CrossCut

準優勝：OrbitWeaver
ベクトル類似度ではなく、GitLab Orbitが示す正確な影響範囲をもとに自律的なリファクタリングを行います。影響を受けるすべてのファイルをマッピングし、依存関係の順序に沿って編集していく。一歩間違えればパイプラインが赤くなる場面で、本物のグラフが曖昧な検索に勝る理由を、これほど明快に示す例はありません。

アイデアの質

優勝：Transcend
多くのチームがGitLab Orbitに直接クエリを投げており、たいていの問いに対してはそれで十分です。Transcendが作ったのは、その上にもう一段重ねた推論エンジンでした。セマンティックウェブのスタック——OWL、SPARQL、RDF——を使い、ネイティブAPIが一度の呼び出しでは表現しきれない問いに届かせる仕組みです。推移閉包。コードベースの外へ出て、世界の構造化された知識を引き込むジョイン。デモでは、あるコードベースがどの知識グラフ埋め込み手法を実装しているかを尋ねると、クラス名だけでなく、その着想元となった論文、著者、発表年までが、コードとライブにつながった形で返ってきます。Orbitを「呼び出すAPI」ではなく「その上に築く基盤」として扱ったこと——このカテゴリーが評価したのは、まさにその視点の新しさでした。

準優勝：Universal Agent OS
エージェントそのものではなく、それを取り巻くガバナンス層を作りました。まずヒアリングし、コーディングの前に計画を立て、証跡を残し、検証を強制する。エージェントが書くコードの割合が増えるほど、説明責任をどう保つかが本当の課題になっていきます。これは、このリストのほかの項目でもGitLab Orbitのコンテキストが浮かび上がらせている問題そのものです。エージェントは速く動く。それでも、その行動に誰かが責任を持たなければなりません。

コントリビュートラック

コントリビュートラックはショーケーストラックと並行して行われ、決して片手間の取り組みではありませんでした。26名のコントリビューターが、GitLab Orbitのコードベースに61件のマージリクエストを直接マージしています。C++20のconcepts、Goのパッケージ宣言、Kotlinのコルーチン、Rubyのラムダへの言語サポート、オントロジーの修正、CIにおけるSIGPIPEバグの修正、最初のOrbitクエリチュートリアル、そして次の人がmax_depthとmax_hopsの違いでつまずかないためのドキュメント整備——内容は多岐にわたります。19名が賞金を獲得し、26名全員がグッズクレジットを受け取りました。

賞金は最初にマージされた40件のコントリビューションに贈られました。つまりこのリストは、質だけでなくスピードも映し出しています。ここに名前が挙がるのは、誰よりも早く動作する変更のレビューとマージにこぎ着けた人たちです。今回の賞金受賞者の皆さん、おめでとうございます。

achalbajpai, aishahsofea, AlphaTheGoat27, anushkrishnav, bartekp854, bhandari.varun04, ChaitanyaManik17, fa220, fongse, gatlavishweshwarreddy26, gkepas, JonstonChan, koves, MattGaiser, MatthewOscar, nexpectArpit, priyansh3133, Vinayreddy765, zidanesalim。

マージされたコントリビューションの全体は、こちらからご確認いただけます。

コミュニティから学んだこと

あるツールの本質は、使い方を誰かに教わるより前に、人々が実際に何を作るかを見ることで見えてくるものです。

チャットボットを作ったチームは、ひとつもありませんでした。優れた応募作品には、すべて同じ動きが根底にありました。かつては4つのツールを行き来して午後いっぱいかけて調べていた問いを、一度のクエリで答えてしまったのです。

• このマージで何が壊れるのか
• 実際に重要なテストはどれか
• この移行には本当はいくらかかるのか
• 先月の変更は今も生きているのか

私たちが機能として用意したわけではありません。 グラフに手が届いた瞬間、コミュニティが自らそれを見つけ出したのです。これは、どんなベンチマークよりも雄弁にGitLab Orbitを物語っています。

全応募作品はプロジェクトギャラリーでご覧いただけます。優れたプロジェクトの数々が、8つの枠には到底収まりきりませんでした。

GitLab Orbitで構築できること

ここまでの優勝プロジェクトはどれも、同じ問いに対するひとつの答えです。断片から推測するのではなく、システム全体のファーストパーティのコンテキストから推論するとき、エージェントには何ができるのか。GitLab Orbitは、コード、作業アイテム、マージリクエスト、パイプライン、デプロイメント、所有権を絶えずひとつのグラフへとマッピングし、エージェントとエンジニアが同じ信頼できる唯一の情報源を参照できるようにします。始めるのに、ハッカソンは必要ありません。ここからは、コミュニティが実証したパターンを、Orbit本来のユースケースに沿って紹介します。

• 変更を意識した配信：プッシュする前に何が壊れるかを知る。 ある関数の下流の呼び出し元、影響するパイプライン、それらを所有するチーム——これらをGitLab Orbitに一度のクエリで尋ねられます。SankofaのRadarはこれをマージリクエスト上で行い、CrossCutは同じコールグラフを使って変更が到達しうるテストだけを実行し、CIの実行時間を90%削減します。隠れた依存関係を、CIの最後で発見するのではなく、早い段階で見つけられるのです。
• システム全体のコンテキストで、移行をより安全に。 移行したいサービスに何が依存しているか、どの順序で進めるべきか、リスクはどこにあるか——これをOrbitに尋ねます。Carverはそれを価格付きの見積もりに変え、Marshalはリポジトリごとに移行を進めます。どちらも実際の依存関係グラフから影響範囲を割り出すため、プラットフォームチームは3週間後に隠れた依存先を発見するのではなく、最初から移行日程にコミットできます。
• 脆弱性に対する迅速な影響範囲分析。 脆弱性のある関数から、到達可能なすべてのエンドポイント、それらをビルドするパイプライン、それらを所有するチームまで、グラフをたどります。SankofaのShieldは、これまで数日かけてプロジェクトごとに行っていた相関分析を、一度の走査で完了させます。

共通しているのは、答えが決してコードだけの中になかったという点です。答えは、コードがパイプライン、デプロイメント、脆弱性、所有権とどうつながっているかの中にあります。GitLab Orbitはそのつながりを常に最新に保つことで、一度のクエリでそれを引き出せるようにしています。GitLab Duo Agent Platform上のエージェントはOrbitをネイティブにクエリし、外部のエージェントはMCPを通じて接続し、エンジニアはData Explorerを通じて同じグラフに直接アクセスできます。ひとつのグラフ、ひとつの信頼できる唯一の情報源が、あらゆるエージェントと、チームのすべてのメンバーのためにあります。

GitLab Orbitを試す

ご参加いただいた皆さん、ありがとうございました。自分でも作ってみたいという方は、GitLab Duo Agent Platform上のGitLab Orbitから始めてみてください。これらのチームが使ったのと同じコンテキストは、すでに皆さんのソフトウェア開発ライフサイクルの中で動いています。このハッカソンは、また開催する予定です。いち早く知りたい方は、contributors.gitlab.comからご登録ください。

すでにGitLab Duo Agent PlatformとGitLab Orbitをお使いの環境をお持ちで、どこまで活用できるか試してみたい方は、Co-Createにお申し込みください。

GitLab 19.2では、カスタムフローが一般提供（GA）に達し、このギャップを埋めます。カスタムフローとは、一度定義すればGitLabネイティブのイベントからトリガーでき、CI/CDパイプライン内で実行できるAI駆動のワークフローです。失敗したテストを分析 → 修正を生成 → コミット → チームに通知といった自己修復型のパイプラインパターンも、プラットフォームがエンドツーエンドで実行できるようになります。

さらに、基本フローは、ボタン操作やメンション、アサインからしか開始できないという制約がなくなりました。GitLab Duo Agentic Chatで送るリクエストが、変更の実装、マージリクエストのレビュー、失敗したパイプラインの修正といった専門的な作業に該当する場合、Duoが適切なフローを提案します。引き継ぎを承認すれば、そのまま会話の中で処理を追っていけます。

この結果、エージェント型のソフトウェア開発は、単発のチャットのやり取りにとどまらなくなります。チームはすでに信頼している一連の手順をフローとして定義し、イベントやチャットから起動しながら、すべての中間ステップではなく承認プロセスに人の判断を集中させられます。

複数ステップのソフトウェア開発が手作業のままである理由

エージェント型のデモは、単発のやり取りを前提にしがちです。しかし実際の開発作業は連鎖的なプロセスです。コンテキストを集め、コードを変更し、マージリクエストを開き、CIの結果を待ち、レビューに対応する。フローがなければ、この連鎖の一つひとつを人がクリックし、コピー＆ペーストし、暗黙知として覚えている手順を頼りにこなすことになります。

GitLab Duo Agent Platform内のカスタムフローがまだ成熟途上だった頃は、こうした連鎖を構築すること自体が暫定的な取り組みに感じられていました。本番運用に耐える完成度やイベントの網羅性がまだ十分でなかったため、チームはすでに信頼している自己修復型パイプラインや「このイシューを実装する」、イベント駆動のフォローアップといった手順をフロー化することを見送っていたのです。

エージェント型フローがエンジニアリングチームにもたらす変化

• すでに信頼している手順を自動化 カスタムフローは、メンション、アサイン、パイプライン、マージリクエストのライフサイクル、作業アイテムの変更など、すでに使い慣れたGitLabのイベントをトリガーとして、プロジェクトをまたいだ複数ステップのタスクを実行します。コンポジットID（複合ID）のもとで実行されるため、アクセス範囲は限定され、実行したアクションの帰属も明確なままです。
• 専門的な作業をチャットから開始 Agentic Chatに、デベロッパーフローで作業を実装させたり、コードレビューフローでマージリクエストをレビューさせたり、CI/CDパイプライン修正フローで失敗したパイプラインを診断・修復させたりできます。引き継ぎを承認すれば、進捗はインラインで表示され、その間も作業を続けられます。
• 自動レビューを意図的にコントロール GitLab 19.2では、除外ルールにより、ボットが作成したマージリクエストや特定のブランチパターンのマージリクエストなど、クレジットを消費させたくない対象を自動レビューの対象から外せます。レビュー指示のカスタマイズにより、レビューが何を確認するかを調整できるため、どのマージリクエストをレビューするかだけでなく、どのようにレビューするかも選べます。

Duoのエージェント型フローの動作をご覧ください：

仕組み

カスタムフロー プロジェクトまたはAIカタログから作成し、公開範囲を選び、必要な場所で有効化して、適切なGitLabイベントで開始されるようにトリガーを設定します。重要なステップには、人が確認・承認するチェックポイントを追加できます。19.2では、カスタムフローに「作業アイテムのステータス変更」トリガーが追加されたほか、最大100プロジェクトにわたる公開フローの一括有効化にも対応しました。今後のロードマップには、チームが自然言語でフローを説明するだけで、スキーマを一から書かなくても実行可能な定義を得られるFlow Creation Agentも予定されています。

Agentic Chatにおける基本フロー リクエストが専門的な作業に該当する場合、それを基本フローに引き継ぐことができます。実行前に承認するだけで、処理が進む間も会話の中にとどまれます。これが、回答を返すだけのチャットとの違いです。複数ステップの作業は手を離れますが、GitLabの外に出ることはありません。

コードレビューフローの自動化を更新 除外ルールにより、ボット駆動や対象外のマージリクエストが、意図しないコードレビューサイクルを消費することを防げます。また、レビュー指示のカスタマイズにより、チームにとっての「良いレビュー」の基準を定義できるため、自動化を拡大しても、すべてを同じ方法でレビューすることにはなりません。

すでに実践している手順をフロー化する

カスタムフローは一般提供（GA）となり、基本フローもAgentic Chatから開始できるようになりました。必要な内容を伝えるだけで、適切な専門フローにリクエストが振り分けられます。これにより、チームがすでに信頼しているエージェント型のソフトウェア開発の手順を、暗黙知に頼ることなく、予測可能な自動化へと落とし込めます。

さらに詳しく知りたい方は、まずカスタムフローと基本フローのドキュメントをご確認ください。一点ご注意いただきたいのは、イベント駆動型のフローは、実行する作業内容に応じてクレジットを消費するという点です。大規模なグループ全体に展開する前に、まずはいくつかのプロジェクトで試してみることをおすすめします。

Duo Agent Platformの他の機能と同様、エージェント型フローもGitLab Duo Agent Platformの無料トライアルからご利用いただけます。Freeプランでは、簡単な手順でお申し込みいただけます。

すでにGitLab PremiumまたはUltimateをご利用の方は、まずDuo Agent Platformを有効化し、サブスクリプションに含まれるGitLabクレジットをご活用ください。

パブリックベータ版として提供が始まったセキュリティレビューフローは、セキュリティエンジニアと同じ視点でコードの変更を精査します。シグネチャの一致ではなく意図を読み取ることで、ロジックの欠陥を本番環境に到達する前に捉えます。スキャナーが見逃しがちな危険な欠陥を発見するための、大きな一歩です。

パターンベーススキャナーの盲点

アプリケーションに最も大きな被害をもたらす脆弱性は、多くの場合、1行ずつ見れば正しいコードでありながら、認可モデルやデータの機密区分、意図されたワークフローといった、コード自体には含まれない文脈に違反しています。ここでは、代表的な3つの脆弱性クラスを見ていきましょう。

アクセスと認可： ユーザーがリソースを読み取ったり変更したりできるかどうかは、言語仕様ではなく認可モデルによって定義されます。オブジェクトレベル認可の不備（IDを変更するだけで他ユーザーのデータにアクセスできてしまう問題）は、2019年以降OWASP API Security Top 10で常に上位を占めています。

データの露出： オブジェクトをシリアライズして返す処理自体は、ごく普通の、一見正しいコードです。それが情報漏えいになるかどうかは、どのフィールドが機密で誰がそれを受け取るかという、構文ではなくドメインの事実によって決まります。

制御フローとワークフロー： ビジネスロジックやレース条件に起因する欠陥は、有効な操作が誤った順序で実行されたり、想定外に繰り返されたり、操作されたりすることで発生します。例えば、支払いなしでチェックアウトに到達できてしまう、競合状態で同じ状態に再突入してしまう、パラメーターを改ざんして価格を変更してしまう、といったケースが挙げられます。

こうした欠陥を捉えるには、これまで手動でのセキュリティレビューが必要でした。しかし、これをすべてのマージリクエスト（MR）に対してスケールさせるにはコストがかかります。また、ペネトレーションテストやバグバウンティは有効な手段ですが、実施のタイミングが遅すぎます。その結果、開発のスピードとセキュリティの専門知識を適用できる速さとの間で、ギャップが広がり続けています。

すべてのMRにセキュリティの判断を

GitLab Duo Agent Platformの基本フローであるセキュリティレビューフローは、コードが本来何をすべきかを推論することで、このギャップを埋めます。上述した脆弱性クラスを的確に検出します。具体的には、オブジェクトレベルおよび機能レベルの認可の不備、状態変更操作における認可の欠如、情報開示、マスアサインメント、ビジネスロジックのエラー、そしてステートフルなワークフローにおけるレース条件です。

従来のスキャナーや人間による分析を置き換えるのではなく補完するものであり、修正コストが最も低い変更の時点でコードをレビューします。GitLab自身のアプリケーションセキュリティチームも、開発期間を通じて社内のMR全体でセキュリティレビューフローを活用してきました。

セキュリティレビューフローの実際の動作を見る：

仕組み

MRの準備が整ったら、人にレビューを依頼するのと同じ要領でDuo Security Reviewにレビューを依頼します。元のファイル、変更された行、MRでの議論、関連コードといった文脈の中で差分を解析します。その推論は精度を重視して最適化されており、さらに独立した検証パスが各所見を確認し、誤検出の可能性が高いものを除外します。

検出結果は、該当する行への差分スレッドとして表示されるほか、内部ノートにも要約が記載されます。パブリックプロジェクトでは、内部ノートのみに限定されるため、セキュリティの詳細が外部に露出することはありません。

各所見には、レビュアーに必要な次のような文脈が付与されます。

• 脆弱性の種類（CWE参照付き）
• 重大度：Critical、High、Medium、Low のいずれか
• ティア：Tier 1（悪用可能）、Tier 2（ロジックの欠陥）、Tier 3（設計上の問題）のいずれか
• 問題の平易な説明
• 修正案（利用可能な場合）

重大度によってレビュアーの状態が決まります。CriticalまたはHighの所見があった場合は変更をリクエストに、MediumまたはLowの所見の場合はコメントになります。何も検出されなかった場合でも、このフローが承認することはありません。最終判断は常に人間が担います。

その後は、コメントスレッドで組織のDuo Security Reviewサービスアカウントにメンションすることで、質問したり、修正方法を議論したり、所見に異議を唱えたりできます。各所見は、通常のMR提案として修正を適用する、誤検出として却下する、リスクを許容する、のいずれかの方法で解決します。修正をコミットしたら、変更内容を確認するために改めてレビューを依頼してください。

セキュリティレビューフローを始める

セキュリティレビューフローは、GitLab Ultimateのお客様向けにパブリックベータ版として提供されています。GitLab.com、GitLab Self-Managed、GitLab Dedicatedでご利用いただけます。

詳しい始め方は、セキュリティレビューフローのドキュメントをご覧ください。

GitLab Duo Agent Platformの無料トライアルから、セキュリティレビューフローをご利用いただけます。すでにGitLab Ultimateをご契約中の方は、Duo Agent Platformを有効にして、サブスクリプションに含まれるGitLabクレジットをご利用ください。

コストは差分の複雑さや選択するモデルによって変動するため、本格的に展開する前にいくつかのMRで試してみることをおすすめします。価格は一般提供（GA）時に変更される場合があります。

気づいた点があれば、ぜひフィードバック用のイシューで共有してください。

コードしか理解できないターミナル上のエージェント型AIでは、こうした課題には対応できません。単体のアシスタントは、ソフトウェアライフサイクル全体にわたるエージェントのことも、組織内の複数のプロジェクトにまたがる権限のことも、GitLab上ですでに設定済みの特定のプロジェクトコンテキストのことも把握していないからです。

GitLab 19.2では、その状況が変わります。GitLab Duo CLIが一般提供となり、GitLab Duo Agentic Chatをそのままターミナルに持ち込めるようになりました。外部から後付けされたツールとは異なり、GitLab Duo CLIはプロジェクトやパイプライン、エージェントの設定をすでに把握しています。調査や構築を行う際はインタラクティブに、ジョブやスクリプトで実行したい場合はヘッドレスに使えます。

その結果、デベロッパーは障害が発生したシェルにとどまったまま作業を続けられ、その作業はターミナル、UI、エディタをまたいで継続します。プラットフォームチームは、GitLab上の他の機能と同様にロールアウトを管理でき、エージェントによる支援も「この関数を書いて」にとどまらず、デリバリーライフサイクルのより広い範囲をカバーするようになりました。

ターミナル上のエージェント型AIがコードで止まっていた理由

エージェント型ツールは、デモ映えする領域、つまりファイル編集からまず成熟していきました。しかし、コミット後のライフサイクルはもっと煩雑で、運用色の強いものです。障害の原因がパイプラインや依存関係、CI設定にある場合、そのコンテキストはGitLabの中にあり、コーディングエージェントの学習データやローカルコンテキストの中にはありません。

汎用的なCLIアシスタントでこのギャップを埋めようとしたチームは、別の代償を払うことになりました。管理コントロールを共有できず、プラットフォームと連携したMCP／セットアップの診断もできず、エージェント型のソフトウェアライフサイクルの他の部分と単一のIDモデルを共有することもできなかったのです。結果として、ターミナル上のエージェント作業はコーディングにとどまり、デリバリーの他の領域を支援するには至りませんでした。

Duo CLIが一般提供されることでチームが得られるもの

• すでにターミナルで行っている作業は、そのままターミナルで完結できます。 コードベース全体の構造を把握し、ビルドやリファクタリングを行い、パイプラインの失敗を追跡し、CI/CDを整理し、複数ステップのタスクをこなせます。すべての答えを求めてブラウザに切り替える必要はありません。
• どの画面からでも、続きから再開できます。 セッションはGitLab Duo CLI、GitLab UI、エディタ拡張機能の間で共有されます。ブラウザで始めて、シェルで続きを進められます。会話はそのままです。
• まず計画を立て、それから実装します。 インタラクティブモードはAgentic Chatと同様の仕組みです。プランモードでは変更を加えずに状況を確認し、ビルドモードで実際の変更を行います。無人で実行したい場合は、ヘッドレスモードでCIジョブやスクリプトに組み込めます。
• 準備が整ったタイミングで有効化できます。 Duo CLIはGitLab.com、GitLab Self-Managed、GitLab Dedicatedで利用できます。Self-ManagedおよびDedicatedでは、管理者がインスタンス単位でアクセスのオン・オフを切り替えられます。どの環境でも、デベロッパーは/doctorを実行してセットアップを確認したり、/mcpでMCPの設定を確認したりできます。

GitLab Duo CLIの実際の動作を見る：

Duo CLIの仕組み

最も簡単な方法はGitLab CLI経由です。glab duo cliを実行すれば、認証はglabが代わりに処理してくれます。個人アクセストークンを使ってduoをスタンドアロンツールとしてインストールし、実行することもできます。どちらの構成でも、同じモードと機能を利用できます。

• インタラクティブモード — ターミナル上でチャットしながら、実行前にツールを承認できます。コードベースを調査し、修正案を計画してから、変更を加える準備ができたらビルドモードに切り替えます。
• ヘッドレスモード — Runner、スクリプト、自動化向けの非対話型実行です。glab duo cli run --goalまたはduo run --goalを使用します。

たとえば、パイプラインが失敗したときは、同じシェルからこう尋ねられます。

$ glab duo cli
> The pipelines in MR 23 are failing. Please help me fix them.

Duo CLIは状況を確認し、原因を特定したうえで、適用前にレビューできる変更案を提示します。規模が大きくなっても、カスタム指示（chat-rules.md、AGENTS.md、SKILL.md）に従って動作し、カスタムスラッシュコマンドを使ってインタラクティブセッションを拡張できます。

今すぐDuo CLIを使ってみる

インストールと認証についてはGitLab Duo CLIのドキュメントをご覧ください。すでにGitLab CLIをお使いの場合は、glab duo cliから始められます。

GitLabを初めてお使いですか？GitLab Duo Agent Platformの無料トライアルを開始できます。すでにPremiumまたはUltimateをご利用の場合は、Duo Agent Platformを有効化し、サブスクリプションに含まれるGitLabクレジットをご活用ください。

エージェント型コーディングは開発者の生産性を高めます。しかし、より難しい課題は、企業がそのスピードをいかにリターンへと転換するかという点です。プロダクションレベルのソフトウェアを出荷する上で、コミットの高速化だけでは十分ではありません。保険・金融サービス業界のあるシニアシステムエンジニアは率直にこう述べています。かつては数時間を要していたコードレビューが今ではわずかな時間で完了し、コード生成の80～90%をプラットフォームが担っているとのことです。

GitLabの導入によって得られるリターンをリーダーが理解できるよう、フォレスターは金融サービス、ソフトウェア開発、エンターテインメント、保険の各業界でGitLab Duo Agent Platformを本番環境で利用する4名の意思決定者にインタビューを実施しました。そして、その経験を1つの複合企業（コンポジット組織）として統合しました。これは、年間売上高30億米ドル、従業員数3,000人のグローバル企業を想定したもので、3年間でGitLab Duo Agent Platformの利用者数を150人から250人へと拡大するというシナリオです。

コストとROIを比較する

この調査では、必要な投資についても明確に示されています。3年間のリスク調整後コストは、消費型クレジットで130万米ドル、導入・運用管理（パイロットプログラムのための社内労働、トレーニング、サポートを含む）で58万9,000米ドルです。これを940万米ドルの便益と比較した結果が、400%のROIおよび750万米ドルの正味現在価値の根拠となっています。

導入前：手作業、中断、コードレビューのボトルネック

GitLab Duo Agent Platformを導入する前、インタビュー対象者たちは、よく見られるボトルネックについて語りました。ソフトウェアの構築、レビュー、セキュリティ確保を、手作業のプロセス、シニアエンジニアの専門知識、その場しのぎの知識共有に依存していたチームです。新入社員は、シニアエンジニアを本来の業務から引き離さない限り、行き詰まりを解消できませんでした。セキュリティの修正は、適切な知見を持つ少数の担当者が対応できるまで、キューに滞留していました。そして、コードを書くことではなく、コードレビューこそが、多くの場合出荷の妨げとなっていました。こうした依存関係こそが、フォレスターの複合企業が取り組み、解決し、測定した対象です。

導入後：オンボーディングの迅速化、移行の迅速化、セキュリティ修復の迅速化、時間の節約

フォレスターは、複合企業における4つの便益領域を定量化しました。リスク調整後の便益は合計940万米ドルで、コスト190万米ドルに対する結果です。

新入社員のオンボーディングが80%高速化。 同僚を本来の業務から引き離す代わりに、新しいチームメンバーはIDEやリポジトリに組み込まれたエージェント型チャットを活用し、不慣れなコードベースや規約を自力で理解するためのコンテキストを取得できるようになりました。これにより58万2,000米ドルの削減を実現しています。

8ヶ月を見込んでいた移行作業が2ヶ月で完了し、期間を75%短縮。 複合企業は、オンプレミスのGitLab環境からGitLab SaaSへの大規模移行において、GitLab Duo Agent Platformを活用してパイプラインの失敗をリアルタイムで診断・解決し、人件費を15万7,000米ドル削減しました。

セキュリティおよびQAエンジニアの時間を40%削減。 QAおよびセキュリティエンジニアは、GitLab Duo Agent Platformが提供するコンテキストに応じた説明や修正提案を活用することで修復時間を短縮し、シニアエンジニアへの依存を軽減しました。これにより、3年間で130万米ドルの人件費削減を実現しています。

すべての開発者が、機能開発に充てられる時間を週あたり20%増加。 エージェント型チャットとAIエージェントが、これまでビルド時間を圧迫していたコードレビュー、テスト、トラブルシューティングを引き継ぎました。3年間で導入が拡大するにつれ、全開発者を合わせた効果は740万米ドルに達しています。

フォレスターは、本調査で定量化しなかった便益についても確認しています。重複するAI開発ツールの統合によるコスト削減、開発者満足度の向上、チーム間の知識共有の改善などが含まれます。

「以前は数週間かかっていた機能リリースが、今では数日で完了しています。生産性の面で非常に高い倍率の向上を実感しています」－ 金融サービス企業のオートメーション責任者

セキュアなソフトウェアをより速く出荷することで複利的なリターンを実現

インタビュー対象者たちは、単にコーディングを高速化しただけではありません。機能を数週間ではなく数日で出荷し、脆弱性を数分で修復し、新入社員のオンボーディングをわずかな時間で完了させ、8ヶ月の移行作業を2ヶ月に圧縮しました。本調査が示すパターンは、エージェント型コーディングが個々のアウトプットを加速させる一方で、そのスピードがソフトウェアライフサイクル全体を支えるインフラを通過して初めて、リターンが複利的に積み重なるということです。

自組織におけるソフトウェアエンジニアリング向けのエージェント型インフラのビジネスケースを構築しようとしている場合、本調査は、4つの企業が実際に行ったことに基づくフレームワークを提供し、予測を現実へと転換する助けとなります。

GitLab Duo Agent PlatformのフォレスターTotal Economic Impact™調査の全文を読む。完全な調査手法、財務モデル、インタビュー結果をご確認いただけます。

本調査はGitLabの委託によりフォレスターコンサルティングが実施したものです。競合分析としての利用を意図したものではありません。フォレスターは、他組織が得られる可能性のあるROIについて一切の前提を置いていません。本調査の結果は、インタビューに応じた組織およびそれらを基にした複合企業の経験を代表するものです。GitLabはインタビューの対象となる顧客名を提供しましたが、インタビュー自体には関与しておらず、フォレスターが調査結果の編集管理を行っています。

お知らせ：リリースノートの掲載先が変わりました
GitLabのリリースノートは、GitLab Docsでの公開が正式な掲載先となりました。最新の情報は下記をご覧ください。
GitLab 19.2

本ブログでもしばらくの間は日本語訳の投稿を続けますが、将来的にはDocsのみでの公開に切り替わる予定です。ぜひDocsの方もチェックしてみてください！

GitLab 19.2 リリースノート

2026年7月16日、GitLab 19.2が以下の機能とともにリリースされました。

今月の注目コントリビューターとして、vivekshukl007さんをご紹介できることを嬉しく思います。

VivekさんはEmiratesのシニアデータエンジニアで、GitLab OrbitへのScala言語サポート追加という大きなインパクトをもたらすコントリビュートを行いました。この変更により、ScalaコードベースでWork in Progressのデベロッパーのコードグラフ機能が向上します。

主要な機能

GitLab Duo CLIが一般提供開始

• プラン: Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

GitLab Duo CLIは、GitLab Duo Agent Platformをターミナルから直接利用できるツールです。

CLIを使用して、コードベースに関する複雑な質問を行ったり、ユーザーに代わって自律的にアクションを実行したりできます。 外部ツールとは異なり、CLIはGitLabプロジェクト、パイプライン、エージェント設定に関するコンテキストを保持しています。

主な機能は次のとおりです。

• 2つのモード: インタラクティブチャットモードとCI/CD向けヘッドレスモード
• GitLab Self-ManagedおよびGitLab Dedicated向けの管理者によるオン/オフ制御
• モデルの選択と共有セッション
• ツールの承認
• Model Context Protocol（MCP）接続
• スラッシュコマンド（コンテキストの使用状況確認やコンテキストのコンパクションコマンドを含む）
• スキルおよびAGENTS.mdカスタマイズファイルのサポート

GitLab Duo CLIは、GitLab CLI（glab）経由またはスタンドアロンツールとしてインストールできます。

GitLab Duoのカスタムフローが一般提供を開始

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

カスタムフローは、GitLabプロジェクト全体にわたる複雑なマルチステップタスクを自動化するために、ユーザーが作成・設定できるAI駆動のワークフローです。チームはワークフローのステップ、コンポーネント、トリガーを定義することで、繰り返し発生する開発・運用作業をGitLabイベントに応じて自動実行できます。GitLab UIでは、フローがGitLab CI/CD上で直接実行されるため、GitLabを離れることなく一般的なタスクを自動化できます。

主な機能は次のとおりです。

• チーム固有の自動化に対応した、YAMLで定義された再利用可能なワークフロー
• 複雑なマルチステップタスクに対応するマルチエージェントオーケストレーション
• 重要なステップでの承認やフィードバックのために、ユーザーが定義できるヒューマン・イン・ザ・ループ（HITL）チェックポイント
• メンション、割り当て、パイプラインイベント、マージリクエストのライフサイクルイベントを含むネイティブGitLabトリガー
• プロジェクトまたはAIカタログからのフローの作成と管理
• パブリックおよびプライベートの表示レベル制御
• サービスアカウントと複合IDを使用したセキュアな実行
• 実行前に設定の問題を検出するYAML検証

スケジュールされたパイプライン実行ポリシーがGA開始

• プラン: Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

スケジュールされたパイプライン実行ポリシーが一般提供（GA）になりました。セキュリティポリシープロジェクトでスケジュールを一度定義するだけで、対象となるすべてのプロジェクトに適用できます。各プロジェクトの .gitlab-ci.yml を個別に編集する必要はありません。要件が変更された場合も、多数のCI/CD設定ファイルを横断して変更を調整する代わりに、ポリシーを一か所で更新するだけで対応できます。

スケジュールポリシーを使用すると、コミットの有無に関わらず、コンプライアンススクリプト、セキュリティスキャン、またはその他のカスタムCI/CDジョブを日次・週次・月次のケイデンスで実行できます。これは、定期的なコード変更がないリポジトリ（新たに発見された脆弱性を検出するための依存スキャンの実行など）に特に有効です。各ポリシーは独立したパイプラインとして実行され、タイムゾーンのサポート、時間帯分散、およびブランチターゲティングに対応しています。

Agentic Chatから基本フローを開始可能に

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

これまでのバージョンのGitLabでは、基本フローは特定のUI操作、メンション、割り当てからのみ開始できました。 現在は、GitLabのUI上でAgentic Chatとの会話の一部として、これらのフローを開始できるようになりました。

リクエストがスペシャリストワークフローに一致すると、Agentic Chatは以下のフローのいずれかにハンドオフします。

• デベロッパーフロ: 変更を実装するか、マージリクエストを作成します
• コードレビューフロ: マージリクエストをレビューします
• CI/CDパイプライン修正フロー: 失敗したパイプラインを診断して修復します

チャットでハンドオフを承認すると、会話内または AI > セッション から進捗を確認できます。

サブグループへのGitLab Duo利用可否の選択的設定

• プラン: Ultimate
• 提供形態: GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連イシュー

GitLab Dedicatedインスタンスの管理者は、特定のサブグループに対してGitLab DuoおよびGitLab Duo Agent Platformを利用不可に設定しながら、他のサブグループでは引き続き有効化できるようにすることが可能です。

これまでは、インスタンス全体でGitLab DuoとAgent Platformを無効化するか、すべてのサブグループで利用可能にするかのいずれかしか選択できませんでした。

今回のリリースで、デフォルト拒否のサブグループ単位の許可リストを適用できるようになりました。特定のサブグループを 常にオフ（ロック済み） に設定すると、その子孫グループおよびプロジェクトではGitLab DuoとAgent Platformを有効化できなくなります。一方、他のサブグループについてはオーナーロールを持つユーザーの判断に委ねることができます。ロックの適用・解除は管理者のみが行え、影響を受けるオーナーには、GitLab Duoが親グループによってロックされている旨のメッセージが明確に表示されます。

この機能は、コンプライアンスおよびプラットフォームガバナンスチームが厳格なデータ分類要件を満たすうえで役立ちます。

デフォルト以外のブランチのトラッキング（ベータ版）

• プラン: Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連エピック

デフォルトブランチ以外のブランチでも脆弱性を追跡できるようになりました。最良の結果を得るには、特定の環境（project-qa、project-prod）やデプロイプラットフォーム（project-iOS、project-android）向けのブランチなど、長期間維持されるリリースブランチを少数に絞って対象にすることをお勧めします。

このベータ版には以下の機能が含まれています。

• セキュリティ設定ページで追跡ブランチを追加できます（ネームスペース内のプロジェクト数の2倍まで）。
• 脆弱性レポートでブランチによるフィルタリングが可能です。
• プロジェクトレベルのセキュリティダッシュボードでブランチによるフィルタリングが可能です。
• 追跡ブランチ上のすべての脆弱性タイプ（以前は対象外だったCVEを含む）を追跡できます。
• ブランチがデフォルトブランチにマージされた際に、脆弱性ステータスのメタデータの整合性を維持します。
• 追跡ブランチ上の脆弱性ステータスを更新できます。

依存関係スキャン自動修正（ベータ版）

• プラン: Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

GitLab 19.2では、依存関係スキャン自動修正をベータ版として導入しました。この機能は、依存関係スキャンのワークフローに自動化された脆弱性修正を直接組み込むもので、2つの機能を提供します。

• 依存関係バージョンの自動更新：GitLab.com、GitLab Self-Managed、GitLab Dedicatedで利用可能。
• エージェント型による破壊的変更の解決：GitLab.com、GitLab Self-Managed、GitLab Dedicatedで利用可能。GitLabクレジットを消費します。

依存関係バージョンの自動更新は、脆弱な依存関係を安全なバージョンに更新するマージリクエストを自動的に作成します。有効にすると、GitLabはプロジェクト内の脆弱な依存関係を監視し、手動での介入なしに修正用MRを作成します。デフォルトでは、パッチバージョンとマイナーバージョンへの更新が対象です。

エージェント型による破壊的変更の解決は、複雑な更新を処理するために修正フローを拡張します。依存関係のバージョンを更新するマージリクエストのパイプラインが破壊的変更によって失敗した場合、GitLab Duoはパイプラインのエラー、依存関係の変更履歴、およびコードでの依存関係の使用方法を分析します。

GitLab Duoは同じMRに修正をコミットし、パイプラインが成功するまで再実行します。エージェント型による破壊的変更の解決を有効にすると、バージョン更新の対象がメジャーバージョンにも拡張されます。

2つの機能を組み合わせることで、完全な修正ループが形成されます。GitLabがMRを作成し、更新が複雑な場合はGitLab Duoが解決します。

セットアップ手順については、依存関係スキャン自動修正を参照してください。

フィードバックはベータ版フィードバックイシューでお寄せください。

AI監査イベントレポート（ベータ版）

• プラン: Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連イシュー

AI監査イベントレポートがベータ版として利用可能になりました。セキュリティおよびコンプライアンスチームは、GitLab Duoエージェントのアクティビティを一元的にダウンロード可能な記録として確認できます。

これまで、エージェントのアクティビティはパイプラインジョブやイベント履歴に分散しており、以下の目的でセッションを再構成することが困難でした。

• インシデント調査。
• コンプライアンスレビュー。
• AIガバナンスレポート。

今回のリリースで、各エージェントセッションが以下の情報を含む包括的な監査アーティファクトを生成するようになりました。

• 入力。
• モデルおよび設定コンテキスト。
• 時系列のイベントタイムライン。
• 出力。

ガバナンスページからAI監査イベントを参照し、エージェントやセッションの詳細でフィルタリングして、個々のイベントを詳しく確認したり、基となるセッションアーティファクトをダウンロードしたりできます。

セキュリティレビューフロー（ベータ版）

• プラン: Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

セキュリティレビューフローは、マージリクエスト内のビジネスロジックの脆弱性を直接検出します。既知のパターンをスキャンする静的解析ツールとは異なり、セキュリティレビューフローはコードの意図を推論し、パターンベースのスキャナーが見落としがちな認可のバイパス、データの露出、ロジックエラーを特定します。

レビューをリクエストするには、マージリクエストのレビュアーとして Duo Security Review サービスアカウントを割り当てます。フローは差分を分析し、脆弱性が発生している正確な行にスレッド形式のコメントとして結果を投稿します。各コメントには、Common Weakness Enumeration（CWE）の分類、重大度の評価、および可能な場合はマージリクエストを離れることなく適用できるインラインの修正候補が含まれます。

各レビューは、マージリクエストの差分の複雑さに基づいてGitLabクレジットを消費します。

Agent Platformの中核機能

AIカタログアイテムの一括有効化

• プラン: Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連イシュー

AIカタログでパブリックカスタムエージェント、外部エージェント、およびパブリックカスタムフローを有効化する際、プロジェクトを1つずつ選択する代わりに、1回の操作で最大100件のプロジェクトを選択できるようになりました。

カスタムエージェントの検証

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

以前は、実行時にプロンプトが失敗するカスタムエージェントをAIカタログに保存できました。たとえば、セキュリティルールに抵触するプロンプトを使用すると、エージェントは使用中に何も行わず、エラーも表示されませんでした。

カスタムエージェントを作成または更新する際、GitLabがプロンプトの設定を検証し、エージェントを保存する前にエラーを通知するようになりました。

フローでIDトークンを設定する

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連イシュー

IDトークンを使用すると、長期間有効な認証情報を保存することなく、サードパーティのOpenID Connect（OIDC）サービスで認証できます。たとえば、バイナリやコミットのキーレス署名、またはシークレットマネージャーからのシークレットの取得にIDトークンを活用できます。

この機能を使用するには、エージェントの設定にid_tokensキーワードを追加し、GitLab Duo Agent Platformが発行するトークンを信頼するようにサービスを設定してください。

GitLab Duo Agent Platform Self-Hostedの使用量課金チェック

• プラン: Premium, Ultimate
• 提供形態: GitLab Self-Managed, GitLab Dedicated for Government
• リンク: ドキュメント · 関連イシュー

オンラインライセンスでセルフホストモデルを使用しているGitLab Self-Managedのお客様向けに、GitLab Duoヘルスチェックが以下のエンドポイントへの接続を確認するようになりました。

• カスタマーポータル
• AIゲートウェイ
• Duoワークフローサービス

これらのエンドポイントへの接続は、使用量課金に必要です。

これまでは、ファイアウォールによってこれらのコンポーネントへの接続がブロックされていても、ユーザーが機能を使用できなくなるまで管理者は接続の問題を把握できませんでした。管理者はこの新しい検証チェックを使用して、ユーザーへの影響が生じる前に問題を診断し、ファイアウォールの許可リストを確認できるようになりました。

GitLab Duo Enterpriseシートのコードレビューフロー

• プラン: Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

以前のバージョンのGitLabでは、GitLab Duo Enterpriseシートを持つユーザーがGitLab Duoにコードレビューをリクエストすると、GitLab Duoコードレビューがレビューを実行していました。 これは、グループに対してコードレビューフローが有効になっている場合でも同様でした。すべてのユーザーに対してエージェント型フローを有効にする方法はありませんでした。

今回のリリースで、トップレベルグループのオーナーがこのデフォルト設定を変更し、ユーザーのシートに関わらず、すべてのコードレビューでコードレビューフローを使用するよう設定できるようになりました。 すべてのレビューはGitLabクレジットを消費します。

この変更により、GitLab Duo Enterpriseシートを持つユーザーも、他のユーザーと同様に、リポジトリ全体のコンテキスト認識、マルチステップの推論、およびレビューセッションを利用できるようになります。

マージリクエストを自動コードレビューから除外する（ベータ版）

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

以前のバージョンのGitLabでは、プロジェクトまたはグループで自動レビューが有効になっている場合、GitLab Duoはすべての対象マージリクエストをレビューしていました。 これには、ボットが作成した依存関係の更新、フィーチャーブランチ、実験的な作業など、チームが実際にフィードバックを求めていない変更も含まれていました。

除外ルールを使用して、特定のマージリクエストを自動レビューから除外できるようになりました。 プロジェクトまたはグループに .gitlab/duo/mr-review-automated-rules.yaml ファイルを作成し、作成者、ソースブランチ、またはターゲットブランチに基づいた除外ルールを定義します。 ルールでは dependabot/* や *-bot のようなグロブパターンをサポートしています。

除外されたマージリクエストに対しても、手動でレビューをリクエストすることは引き続き可能です。

この機能はベータ版であり、duo_code_review_automated_rules 機能フラグによって制御されています（デフォルトで有効）。

マージ前の自動リベース

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

以前のバージョンのGitLabでは、プロジェクトで半線形または早送りマージ方式を使用している場合、ソースブランチがターゲットブランチより遅れると追加の手順が必要でした。 マージするには、リベースを選択して完了を待ち、その後マージリクエストに戻ってマージを選択する必要がありました。 この2段階の操作により、すべてのマージに余分な手間が生じていました。

プロジェクトのマージリクエスト設定でマージ前の自動リベースを有効にするを選択できるようになりました。 この設定を有効にすると、GitLabはマージ時にソースブランチをターゲットブランチにリベースするため、1回の操作でマージできます。 個々のコミットのGPG署名を保持することが重要な場合は、この設定をオフのままにしておくことができます。

インスタンスレベルのカスタムレビュー指示

• プラン: Premium, Ultimate
• 提供形態: GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

以前のバージョンのGitLabでは、GitLab Duoのカスタムレビュー指示はプロジェクトレベルまたはグループレベルでのみ定義できました。 インスタンス全体で一貫したレビューガイダンス（セキュリティルールや社内コーディング標準など）を適用したい管理者は、すべてのプロジェクトに同じ指示を重複して設定する必要がありました。

今回のリリースで、インスタンス全体に対してカスタムレビュー指示を設定できるようになりました。

管理者はインスタンス内のプロジェクトをテンプレートとして選択できます。GitLab Duoがコードレビューを実行する際、インスタンスレベルの .gitlab/duo/mr-review-instructions.yaml ファイルの指示が、グループレベルおよびプロジェクトレベルの指示と組み合わせて適用されます。これにより、組織はインスタンス全体のレビュー標準に対して信頼できる唯一の情報源を持つことができます。

コードレビューフローとGitLab Duoコードレビューはいずれも、インスタンスレベルのカスタム指示をサポートしています。

レビューディスカッションをGitLab Duoで解決（ベータ版）

• プラン: Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

以前のバージョンのGitLabでは、コードレビューのコメントを解決するには、エディタに切り替えて修正を実装し、変更をコミットしてプッシュしてから、スレッドを手動でクローズする必要がありました。 未解決のディスカッションごとにこのサイクルを繰り返す必要があり、コンテキストスイッチのオーバーヘッドが多忙なレビュー全体で積み重なっていました。

任意のレビューディスカッションでGitLab Duoで解決を選択できるようになりました。 GitLab Duoはレビューコメントとその周辺のコードを読み取り、レビュアーが説明した変更を実装して、ブランチにコミットします。その後、GitLab Duoは変更内容と理由の簡単なサマリーをディスカッションに返信し、スレッドを解決します。変更内容を確認し、修正がコメントに正しく対応していない場合はスレッドを再オープンできます。

統合DevOpsとセキュリティ

CIエキスパートエージェントの一般提供開始

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

CIエキスパートエージェントが一般提供開始になりました。このAI搭載アシスタントは、GitLab CI/CDパイプラインの作成、デバッグ、最適化を支援します。リポジトリを分析し、パイプライン設定に関するガイダンスを提供します。

今回の一般提供（GA）は、ベータ版およびデザインパートナープログラムでの実績を踏まえたものであり、実際の顧客ワークロードでの本番運用にエージェントを対応させることで、プロジェクトにおけるCI/CD導入のハードルを下げます。

このエージェントはOrbitと統合されています。OrbitとそのKnowledge Graphを有効にすると、エージェントはグラフベースのコードインテリジェンスを活用し、より文脈に即したパイプラインの推奨を提供します。OrbitとKnowledge Graphはベータ版です。

CI/CDパイプライン修正フローによるターゲットを絞った修正の提案

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連イシュー

GitLab DuoのCI/CDパイプライン修正フローに、2つの主要な改善が加わりました。

• マージリクエストの差分に関連ファイルが既に含まれている場合、そのマージリクエストに対してコード提案として直接修正が提示されます。
• フローがパイプラインの失敗を分類してから対処するため、より的を絞った診断が得られます。

また、フローはパイプライン階層全体にわたって子パイプラインの失敗を分析し、AGENTS.mdファイルを使用してプロジェクトに合わせた動作のカスタマイズが可能になりました。さらに、マージリクエストのコメントをすっきり保つため、AIの推論プロセスはデフォルトで折りたたまれて表示されます。

フィードバックはフィードバックイシューにお寄せください。

GitLabアチーブメントでコントリビューターを表彰

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

これまでGitLabには、チームメンバー、顧客、コントリビューターの功績を正式に称える組み込みの仕組みがありませんでした。多くの努力が認められないまま終わり、コミュニティにはプロジェクトを支える人々を称えるための一貫した手段がありませんでした。

グループレベルでカスタムアチーブメントを作成し、コントリビューションに応じてユーザーに授与できるようになりました。各アチーブメントには名前、説明、アバターを設定できます。授与されたユーザーは、プロフィールに表示するアチーブメントを選択できます。アチーブメントにより、メンテナーは参加を目に見える形で報いることができ、より強固でモチベーションの高いコミュニティの構築に役立ちます。

この機能へのコントリビュートに感謝します。Niklas van Schrickさん、ありがとうございました！

パーソナルスニペットでのGitLab Flavored Markdownリファレンス

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連 イシュー

パーソナルスニペットでGitLab Flavored Markdown（GFM）リファレンスを使用できるようになりました。使用方法は次の2通りです。

• GitLabは、プロジェクトスニペットやGitLabの他の領域と同様に、パーソナルスニペットの説明とコメント内のGFMリファレンスを処理します。
• コメントやイシュー・マージリクエストの説明など、GFMがサポートされている場所であればどこからでも、プロジェクトスニペットで既に使用できる $<id> 構文を使用してパーソナルスニペットを参照できます。

スニペットIDはパーソナルスニペットとプロジェクトスニペット全体で一意であるため、各IDは単一のスニペットに解決されます。

セキュリティマネージャーがエージェント型フローを設定可能に

• プラン: Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連イシュー

セキュリティマネージャーロールを持つユーザーは、プロジェクトに対してSAST VR、SAST FP、シークレットFP、および依存関係スキャンVRを設定できるようになりました。

ビルトインのプロジェクトテンプレートの無効化

• プラン: Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連イシュー

組織がカスタムプロジェクトテンプレートを使用している場合、ビルトインのベンダーテンプレートがテンプレート選択画面に不要な項目を追加したり、サーバーサイドフックやその他のリポジトリ制御を回避したりする可能性があります。

管理者は、管理者エリアからグローバルに、またはサブグループのグループレベルで、プロジェクトテンプレートを無効化できるようになりました。この設定は自動的にカスケードされるため、グループごとに個別に設定する必要はありません。管理者は設定値を強制することで、グループやサブグループが設定を上書きできないようにすることも可能です。インスタンスおよびグループの設定は、REST APIおよびGraphQL APIでも管理できます。 GitLab.comでは、グループレベルの設定のみ利用可能です。

詳細権限PATが一般提供開始

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated
• リンク: ドキュメント · 関連 イシュー

詳細権限パーソナルアクセストークン（PAT）が一般提供（GA）になりました。従来のPATは所属するすべてのプロジェクトとグループへのアクセスを付与しますが、詳細権限PATでは各トークンを特定のリソースとアクションに限定できます。これにより、自動化やインテグレーションに最小権限の原則を適用しやすくなり、トークンが漏洩または不正利用された場合の潜在的な影響を軽減できます。

セットアップを簡単にするために、トークン作成時にDuoで権限を追加機能を使用して適切なパーミッションを選択できます。既存の従来のPATは引き続き従来どおり機能します。新しいトークンについては、各トークンが必要なリソースとアクションのみにスコープされるよう、GitLabは詳細権限PATを推奨しています。

GAリリースにより、詳細権限PATはREST APIエンドポイントの完全なカバレッジと、最もよく使用されるGraphQLタイプおよびミューテーションのカバレッジを備えるようになりました。

脆弱性レポートのエクスポートでフィルターが正しく適用されるように

• プラン: Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連 イシュー

フィルターを適用した状態で脆弱性レポートをエクスポートすると、エクスポートされたCSVファイルにはフィルター済みのデータのみが含まれます。

GitLab Runner 19.2

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント · 関連イシュー

本日、GitLab Runner 19.2もリリースしました。GitLab Runnerは、CI/CDジョブを実行してその結果をGitLabインスタンスに送信する、高いスケーラビリティを持つビルドエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。

新機能

• GitLab Runnerがジョブ完了PUTリクエスト時に環境キーを送信するようになりました
• GitLab RunnerにKASジョブリクエストが連続して失敗した場合にRailsへ自動的にフォールバックするサーキットブレーカーが追加されました

バグ修正

• シークレットの解決失敗がrunner_system_failureとして誤って分類される
• GitLab Runnerを19.1.0にアップデートするとジョブがcontext deadline exceededで失敗する
• DockerのexecutorでジョブがときどきContext deadline exceededで失敗する
• FF_CONCRETEが有効な場合にアーティファクトのダウンロードが失敗する
• KAS Job RouterのGetJobレイテンシーヒストグラムにステージング環境でデータが表示されない
• Runnerトークンの自動ローテーションによりDocker Autoscalerのexecutorがアクティブなインスタンスを削除し、実行中のジョブが失敗する

すべての変更点はGitLab Runnerの変更履歴をご覧ください。

スケールとデプロイ

GitLab DuoがマージリクエストのレビューをAIで読み取り、返信

• プラン: Free, Premium, Ultimate
• 提供形態: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
• リンク: ドキュメント ·  関連 イシュー

GitLab DuoとMCPベースのエージェントを使用して、マージリクエストのレビューディスカッションを読み取れるようになりました。 これにより、AIアシスタントがレビュアーのフィードバック、未解決のスレッド、ディスカッションの履歴を完全に把握できます。

エージェントに対して、レビューコメントの要約、フィードバックへの返信の下書き作成、そしてワークフローを離れることなくマージリクエストのディスカッションへの直接返信投稿を依頼できます。

インストール

新規にGitLabをセットアップする場合は、GitLabダウンロードページをご覧ください。

アップデート

アップデートページをご確認ください。

ご不明な点がある場合

ご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、GitLabフォーラムにアクセスして質問を投稿してください。

GitLabサブスクリプションプラン

• Free ユーザー向けの永久無料機能を提供
• Premium チームの生産性と調整を強化
• Ultimate 組織全体のセキュリティ、コンプライアンス、プランニングに対応 GitLabのすべての機能を無料でお試しいただけます。

--------------------

過去の日本語リリース情報

• GitLab 19.1
• GitLab 19.0
• GitLab 18.11
• GitLab 18.10
• GitLab 18.9
• GitLab 18.8
• GitLab 18.7
• GitLab 18.6
• GitLab 18.5
• GitLab 18.4
• GitLab 18.3
• GitLab 18.2
• GitLab 18.1
• GitLab 18.0
• GitLab 17.11
• GitLab 17.10
• GitLab 17.9
• GitLab 17.8
• GitLab 17.7
• GitLab 17.6
• GitLab 17.5
• GitLab 17.4
• GitLab 17.3
• GitLab 17.2
• GitLab 17.1
• GitLab 16.11