GitLab

『2025年Gartner® Magic Quadrant™ for DevOps Platforms』でGitLabが3年連続でリーダーの1社として評価されました

2025-09-25T00:00:00.000Z

『2025年Gartner® Magic Quadrant™ for DevOps Platforms』で、GitLabが3年連続でリーダーの1社として評価されました。この評価は、実行能力とビジョンの完全性に基づくものです。

この評価は、ソフトウェア開発にとって重要な転換期において、当社の包括的なプラットフォーム戦略が認められた証であると認識させるものと考えています。組織は、セキュリティ、コンプライアンス、運用の卓越性を維持しながら、AI機能の導入を急速に進めています。成功するには、チームの協働と価値提供の方法を変革する統合プラットフォームアプローチが不可欠です。

お客様がアジャイルソフトウェアの提供、クラウドネイティブアプリケーションの構築、エンジニアリングプラットフォームの開発のいずれに取り組んでいても、GitLabはお客様がAIエージェントと連携して、安全で信頼性の高いソフトウェアをより迅速に提供できるよう支援します。

詳しくはレポートをダウンロードしてご覧ください

より迅速な価値実現

私たちのミッションは、世界を動かすソフトウェアの開発に誰もが貢献し、共創できるようにすることです。私たちのイノベーション戦略の急速なペースは、まだ道半ばであることを示しています。150か月以上にわたり毎月新しいソリューションをお客様に提供し続けておりますが、この伝統は今後も続きます。

業界をリードする立場として、お客様がこれらの新機能をビジネス価値に変換できるよう、引き続き支援に注力して行きます。

テクノロジーエコシステム全体でAI機能によるイノベーションが加速している現在、統合プラットフォームアプローチでお客様の最も困難なエンジニアリング課題に取り組むことが、これまで以上に重要になっていると確信しています。このアプローチにより、組織はインテグレーションの負荷を軽減し、セキュリティギャップを解消し、既存のソフトウェアデリバリーワークフローを中断することなくイノベーションを導入できます。

以下に例をご紹介します：

エージェント型AIでリリースを加速： 分散化されたツールチェーンは、コードレビューやテストを遅らせます。GitLab Duoのエージェントとフローは、プラットフォーム全体のコンテキストでコードレビュー、テスト生成、脆弱性トリアージなどのタスクを自動化し、チームのサイクルタイムを短縮し、品質向上を支援します。
最初からセキュアに構築： 多くの組織はセキュリティを後回しにし、コストのかかる手戻りやコンプライアンスギャップを招いています。GitLabは、スキャン、ポリシー適用、コンプライアンスチェックを日常のワークフローに組み込み、デベロッパーの作業を遅らせることなく、早期にリスクを発見します。
柔軟なデプロイ： 厳格な規制や運用上の制約があるチームには、マルチテナントSaaS以外のデプロイオプションが必要です。GitLabは、SaaS、Self-Managed、オフライン環境、FedRAMP Moderate認定環境をサポートし、競合他社では実現できない領域でもお客様が管理を維持できるようにします。
一貫したイノベーションの提供： ツールの分散化により、新機能の導入はリスクが高く、破壊的になります。GitLabの月次リリースでは、GitLab Duo Agent Platform、拡張されたAIガバナンス、クラウド統合などの新機能を提供し、チームはツールの入れ替えをせずに導入できます。

最も重要なお客様のユースケース

GitLabは以下のイノベーション領域をサポートします：

クラウドネイティブデリバリーとエンタープライズスケールのための統合ツールセット
高度な計画ツールと包括的なセキュリティ機能
プログレッシブデリバリーのためのパッケージ管理と機能フラグ
ライフサイクル全体の可視化と改善のためのバリューストリームメトリクス
日常業務に直接組み込まれたAIネイティブなワークフロー

この汎用性は実際の顧客価値につながっています。NatWestのエンジニアリングプラットフォームリードであるBal Kang氏は次のように説明しています：

「コード、テスト、CI/CD、ソフトウェア開発ライフサイクル全体の記録システムにGitLab DuoのAIエージェントが組み込まれることで、生産性、ベロシティ、効率性が向上しました。AIエージェントは意図を理解し、問題を分解し、アクションを実行します。まさにチームにとっての真の協働者となっています。」

統合プラットフォームへの転換は、組織がソフトウェア開発にアプローチする方法の根本的な変化を表しています。これが、最近Gartner®が私たちを『2025年Magic Quadrant™ for AI Code Assistants』でもリーダーの1社として評価した理由だと考えています。

企業がデベロッパーの生産性を安全に最大化し、イノベーションを加速させようとする中、包括的なプラットフォームアプローチの必要性は、かつてないほど緊急になっています。

詳しくはレポートをダウンロードしてご覧ください

この図表は、Gartner Inc.がリサーチの一部として公開したものであり、文書全体のコンテクストにおいて評価されるべきものです。オリジナルのGartnerドキュメントは、リクエストによりGitLab からご提供することが可能です。

Gartnerは、Gartnerリサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティング又はその他の評価を得たベンダーのみを選択するようにテクノロジーユーザーに助言するものではありません。Gartnerリサーチの発行物は、Gartnerリサーチの見解を表したものであり、事実を表現したものではありません。Gartnerは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の責任を負うものではありません。

出典: Gartner, Magic Quadrant for DevOps Platforms, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, September 22, 2025

ロードマップとは？意味やソフトウェア開発における必要性、作り方

2025-09-25T00:00:00.000Z

ソフトウェア開発のプロジェクト管理を適切に行うためには、ロードマップの作成と活用が大切です。実際にロードマップを作成しようとしているものの、具体的な作り方を理解していない人もいるのではないでしょうか。

この記事では、ソフトウェア開発におけるロードマップの必要性やメリット、作成方法を解説します。ロードマップの作成に役立つおすすめのツールも紹介するので、ぜひ参考にして下さい。

1. ロードマップとは？

ロードマップとは、プロジェクトや事業戦略において設定した目標やゴールまでの道筋を、時系列で視覚化した工程表のことです。より簡潔に説明すると、目標達成のために「いつまでに具体的に何をするのか？」という情報を表でまとめて関係者全員に共有する形で活用します。

ロードマップはビジネスやIT領域において重要な役割を持っており、積極的に活用することで関係者間での連携や課題把握が容易になるため、効率的にプロジェクトを進められます。

2. ロードマップの主な種類

ロードマップは大まかに以下の2つの種類に分けられます。ここでは、それぞれの特徴について解説します。

プロジェクトロードマップ
プロダクトロードマップ

2-1. プロジェクトロードマップ

プロジェクトロードマップは、プロジェクトを円滑に進めるために全体像を管理する目的で活用されるロードマップです。具体的には、プロジェクトの目標や実施するタスクの内容などを記載して作成します。

ロードマップの基本的なフォーマットであり、多くの場合ロードマップと呼ぶ場合は、このプロジェクトロードマップのことを指しているという認識で問題ないでしょう。

2-2. プロダクトロードマップ

プロダクトロードマップとは、特定の製品やサービスに関する目標や戦略、スケジュール計画などが記載されたロードマップのことを指します。具体的にどのようなプロダクトを開発するのかといった方向性や搭載すべき機能、リリース予定日などを整理して活用します。プロダクトロードマップは、製品開発に関係する人間だけでなく、マーケティング部門などにも共有されるツールです。

プロジェクトロードマップは、プロジェクト全体の管理に活用されるのに対して、プロダクトロードマップは製品開発に焦点を絞ったロードマップであるという違いを理解しておくと良いでしょう。

3. ロードマップとマイルストーンとの違い

ロードマップを正しく理解するためには、マイルストーンとの違いも把握しておくことが大切です。マイルストーンとは、プロジェクトにおける重要な中間目標や通過点、イベントを指します。

例えば、ソフトウェア開発においては実装やテスト完了などのタイミングでマイルストーンが設置されます。

対してロードマップはプロジェクトの全体の計画を示すものになります。ロードマップの中にマイルストーンを設置することで、目標に対して作業が順調に進んでいるかどうかをより把握しやすくなります。特にプロジェクト期間が長期に及ぶ場合は進捗把握が難しくなるため、適切なフェーズでマイルストーンを設置しておくことが大切です。

4 ロードマップとガントチャートの違いと併用可否について

ガントチャートとは、プロジェクトにおける細かなタスクや期日を管理して、日々の進捗を確認するためのツールです。一方、ロードマップは、プロジェクトの全体の計画を示すものであり、日々の細かなタスク管理には向いていません。

しかし、ロードマップを作成する際にガントチャートの要素を取り入れる、つまりガントチャートをロードマップのフォーマットとして活用することで全体の計画だけでなく、日々の細かなタスク管理もできるようになるため、より綿密に計画を進められるでしょう。

ガントチャートについては以下の記事で詳しく解説しているので、ぜひあわせてご覧下さい。

ガントチャートとは？ソフトウェア開発における役割やメリット、作り方

5. ソフトウェア開発におけるロードマップの必要性・目的

ソフトウェア開発においては、プロジェクト完了までに要件定義や基本設計、開発、テストなどさまざまな工程を踏む必要があり、開発エンジニアだけなく顧客など、プロジェクトに関与する人間もさまざまです。

問題なくプロダクトをリリース・納品するためには関係者全員で計画を共有し、同じ方向を向いてプロジェクトを進めなければなりません。

ロードマップを作成すれば一目で全体の計画を把握できるため、関係者間での情報共有が容易になり、スムーズにプロジェクトを進められます。また、急なトラブルが発生した場合でも事前に計画を立てておけば柔軟に対応することができるため、ロードマップはソフトウェア開発の領域において重要なツールのひとつだと言えます。

6. ソフトウェア開発においてロードマップがもたらすメリットと効果

ここでは、ソフトウェア開発においてロードマップがもたらす具体的なメリットと効果について解説します。

プロジェクト全体を可視化できる
チーム間の共通認識が生まれる
進捗や課題を把握しやすくなる
開発関係者のモチベーションの維持につながる

6-1. プロジェクト全体を可視化できる

ロードマップならプロジェクト全体を可視化できるため、進むべき道のりや目標が明確になり、無駄のないスムーズなスケジュール進行ができます。「◯月◯日までにクライアントにシステムを納品する」というように具体的な期限も設定されるため、それに向けた優先順位や行動計画が立てやすくなり、効率よく開発を進められるでしょう。

また、ロードマップでプロジェクトの全体を可視化しておくことで、遅延やリソース不足などのリスクが発生する可能性があるフェーズを事前に予測できるため、必要な対策を早期に検討することも可能です。

6-2. チーム間の共通認識が生まれる

ロードマップを作成すれば、関係者間での情報共有が容易になります。プロジェクトを進行する上で関係者間で認識の違いがあると、失敗を招く場合があります。例えば、本来必要のない作業が計画に含まれていると、納期遅延が発生してしまうでしょう。

ロードマップを作成して事前に必要な情報を開発チームや顧客との間で共有しておけば、全員が共通の認識のもとでプロジェクトを進行できるため、方向性がズレることなくタスクを着実に進められるでしょう。また、開発メンバーそれぞれが目標達成のために何をすべきか自分の役割を把握できるでしょう。

6-3. 進捗や課題を把握しやすくなる

ロードマップによって全体のスケジュール計画を示すことで、プロジェクトの進捗管理もしやすくなります。明確な目標があれば、「現状目標に向かってどのくらい作業が進んでいるか」という達成度合いを把握できるため、その中で課題があれば必要に応じて計画を修正したりなどの対応が可能になります。

ガントチャート風に作成すれば、より細かなタスクの進捗を把握できるため、プロジェクトの遅延防止につながります。

6-4. 開発関係者のモチベーションの維持につながる

ロードマップによって明確な最終目標やマイルストーンが設定されることで、開発メンバーのモチベーション維持や向上にもつなげられます。

ロードマップがない場合、どの方向に向かって何をすべきかが不明瞭であるため、必要のないタスクが発生したりなどのトラブルが生まれる可能性が高まります。その結果、メンバーのモチベーションが低下してしまい、プロジェクト進行に悪影響を及ぼしてしまうでしょう。

ロードマップを活用すればメンバー間の認識のズレも防止でき、互いに情報共有しながら協力的にプロジェクトを進められます。

7. ロードマップの作成ステップ

ここでは、実際のロードマップの作成方法について解説します。

目標設定
現状把握
リスク対策
マイルストーンの設定
スケジュール計画表の作成
関係者への共有と改善

7-1. 目標設定

まずは目標設定を行い、プロジェクトとして進むべき方向性を明確化します。目標設定においては、関係者全員が理解できるよう具体性を持たせることが大切です。また、目標達成のハードルが高い場合、メンバーのモチベーション低下を招いてしまう原因にもなるため、実現可能な目標を設定しましょう。

例えば、ソフトウェア開発において顧客にプロダクトを納品するなら、具体的な納品日を目標として設定すると良いでしょう。

7-2. 現状把握

目標設定が完了したら、現状抱えている課題を洗い出します。例えば、顧客にプロダクトを予定通り納品するに当たり、「開発リソースは足りているか？」「メンバー構成に問題はないか？」などの現状の状態をチェックしていきます。開発メンバーや顧客に対してもヒアリングを行い、プロジェクト開始前に懸念点がないか確認しておくと良いでしょう。

現状課題があるのにもかかわらずプロジェクトが開始されると、進行中にトラブルが発生してしまう可能性が高くなるため、現状把握を徹底して行い事前に課題を解消しておきましょう。

7-3. リスク対策

プロジェクト開始前には進行中に想定されるリスクについても洗い出し、必要な対策を検討しておく必要があります。例えば、市場の変化や顧客の要望により急な仕様変更が発生したり、タスクの依存関係からスケジュールに影響が出たりする可能性もあります。

そういったリスクが実際に起こった時にどのような対策を講じるのかを事前に検討しておくことで柔軟かつ迅速に対応できるため、プロジェクト進行における安定性を高められるでしょう。

7-4. マイルストーンの設定

マイルストーンは先ほど説明した通り、プロジェクトにおける中間目標を指します。最終的な目標だけでなく、中間目標であるマイルストーンを設定することで進捗管理がしやすくなります。また、長期に及ぶプロジェクトであっても、中間目標があることで着実に作業が進んでいることを実感できるため、メンバーのモチベーションも保ちやすくなるでしょう。

なお、マイルストーンを設定する際にも実現可能かどうかという視点を持って検討することが大切です。

7-5. スケジュール計画表の作成

最終目標やマイルストーンなどの情報を実際にスケジュールに組み込んでいきます。スケジュールを作成する際には、ガントチャートや計画表、フローチャートなどのフォーマットを利用します。

ソフトウェア開発ならタスクの細かな期日や依存関係を把握できるガントチャートの利用がおすすめです。ガントチャートを作成する際にはWBS（Work Breakdown Structure）についても理解しておく必要があります。

WBSとは、プロジェクトを達成するためにどのようなタスクが必要なのかを整理したリストを指します。WBSによって細分化されたタスクを利用してガントチャートを作成するため、両者は密接な関係にあります。

7-6. 関係者への共有と改善

ロードマップが無事完成したらプロジェクトにおける関係者全員に共有します。その際、開発メンバーや顧客から計画や内容の修正案が出た場合は、必要に応じてブラッシュアップします。

また、プロジェクトは関係者全員が同じ認識を持って進めなければならないため、丁寧に擦り合わせを行いメンバーの意見をきちんと反映する意識を持つことが大切です。

8. ロードマップ作成時の注意点

ロードマップは以下のようなポイントを意識して作成しましょう。

見やすさを意識して作成する
計画の実現性を意識する
定期的な見直しを実施する

8-1. 見やすさを意識して作成する

ロードマップは関係者全員に共有するものであるため、誰もが見やすいように視認性の高さを意識することが大切です。

例えば、レイアウトを工夫したり、重要なマイルストーンにはアイコンを適宜活用したりすると良いでしょう。

ロードマップに情報を詰め込み過ぎるとかえって見づらくなり、重要なポイントを見逃してしまう可能性もあるため記載する情報を絞ってから作成しましょう。

8-2. 計画の実現性を意識する

ロードマップを作成する際には、設定した目標や計画が実際に実現可能なのかも精査しなければなりません。

例えば、ソフトウェア開発なら設定した納期は現実的であるか？現状のエンジニアのスキルや人数でタスクを完了させられるのか？などの実現性を細かにチェックします。

また、計画を立てる際に開発メンバーや顧客の要望に答え過ぎると全体の方向性がブレたり、実現不可能な計画になってしまったりする可能性があるため注意が必要です。関係者の声はきちんと拾い上げつつも、その情報を実際に計画に反映するかどうかはきちんと検討しなければなりません。

8-3. 定期的な見直しを実施する

ロードマップは一度作成して終わりではなく、定期的な見直しが必要です。例えば、アジャイル開発ならスプリント終了時に現状把握と必要に応じてロードマップの修正を行います。

また、プロジェクト進行中にリソース不足から作業の遅延が発生したり、情勢の変化によって新たなニーズが生まれたりした場合なども、変化に合わせて柔軟に更新する必要があります。

9. ロードマップの作成手段

ロードマップを作成する手段としては、エクセルやパワーポイント、専用ツールが挙げられます。ここでは、それぞれの特徴について解説します。

9-1. エクセル・パワーポイント

エクセル・パワーポイントはロードマップの作成に使用することができます。エクセルやパワーポイントはビジネスで日常的に使用されるツールでもあるため、使い慣れていれば手軽にロードマップを作成できるでしょう。また、自社で既にMicrosoft Officeを導入しているのであれば、ツール導入の手間を省略できます。

エクセルならセル・列の自由編集、グラフやチャートの挿入、条件付き書式などを活用して自社のプロジェクトに応じて自由にカスタマイズすることが可能です。

パワーポイントなら図形を使ってより視覚的にロードマップを表現できるため、関係者にわかりやすい形で計画を共有したい場合に役立つでしょう。

9-2. 専用ツール

ロードマップにおいては、専用のプロジェクト管理ツールなどを活用して作成することも可能です。専用ツールならマイルストーン機能やタスクの依存関係の設定など、豊富な機能が搭載されているため、視認性の高いロードマップを作成できるでしょう。関係者全員がツールにアクセスすれば情報共有もスムーズに行えるため、認識のズレの防止にもつながります。

また、直感的に作成できるツールであれば専門知識も不要でロードマップ作成に慣れていない人でも簡単に作成することが可能です。プロジェクト管理ツールの導入においてはコストが発生しますが、ロードマップ作成や共有を効率化できることを考えると高い費用対効果が期待できるでしょう。

プロジェクト管理ツールの選び方については次で詳しく解説します。

10. プロジェクト管理ツール・サービスの選び方

プロジェクト管理ツール・サービスを選ぶ際には以下の観点を意識しましょう。

機能
操作性
価格
サポート体制

10-1. 機能

プロジェクト管理ツールを選ぶ際には、まず目的に応じて自社がほしい機能を洗い出しましょう。例えば、目的別の機能を整理すると以下のようになります。

機能	目的
情報共有機能チャット機能	・コミュニケーションや情報共有を円滑に行いたい・一つのプラットフォームで情報共有したい
マイルストーン	・目標管理を適切に行いたい・プロジェクトの進捗状況を把握したい
タスク管理機能	・タスクを可視化したい・大量のタスクを整理したい
工数管理機能	・タスクの依存関係を整理したい・タスクの細かな進捗を管理したい

自社の目的に応じた機能が搭載されたツールを選ぶことで、スムーズな運用につながるでしょう。

10-2. 操作性

プロジェクト管理ツールを導入する際には、操作性もチェックしておきましょう。直感的に操作できる誰でも扱いやすいツールであれば、プロジェクトマネージャーだけでなく、エンジニアにとってもストレスなく利用できるでしょう。

また、実際の操作において学習コストがかかってしまうと、それだけロードマップ作成にも時間がかかってしまうことになるため、手軽に作成できるようなツールを選ぶことが大切です。無料トライアルを提供しているツールであれば事前に使用感もチェックできます。

10-3. 価格

プロジェクト管理ツールの導入においては、自社の予算を考慮してコスト面も確認しておくことが大切です。プロジェクト管理ツールにはクラウド型とオンプレミス型の導入形態があり、それぞれコスト感が異なります。

クラウド型はインターネット経由でサービスを利用する形態のことで、自社でサーバーの設置などが不要であるため初期費用を抑えられます。一方、オンプレミス型は自社でサーバーなどのITインフラを用意して導入する形態です。オンプレミスの場合はクラウド型と比較して初期費用が高くなる傾向があります。

また、自社が求める機能や利用人数などプランに応じて料金が異なるため、あわせてチェックしておきましょう。

10-4. サポート体制

プロジェクト管理ツールをスムーズに導入・運用するためにも、サポート体制が充実しているかどうかも確認しておきましょう。

サポート体制やドキュメントが充実しているツールであれば、トラブルや不明点が発生した場合でも問題なく解決できるでしょう。

サポート窓口への連絡方法や営業時間、応答までの時間などを事前に確認しておくことで不安のない導入を実現できます。

11. ロードマップの作成・活用なら「GitLab」がおすすめ

ソフトウェア開発におけるロードマップの作成・活用なら「GitLab」がおすすめです。ここでは、GitLabの特徴やロードマップ機能について紹介します。

11-1. GitLabとは

GitLabは、AIを搭載したDevSecOpsプラットフォームです。計画から開発、セキュリティ、運用までソフトウェア開発のライフサイクル全体を効率化する単一のプラットフォームで、高品質なソフトウェア開発を実現できます。

CI/CDパイプラインの構築や実施も容易に行えるため、ビルドやデプロイの自動化も可能です。近年ビジネス環境の変化が激化しており、開発・セキュリティ・運用の3つの要素を統合した「DevSecOps」のアプローチに注目が集まっている中で、GitLabは中小企業からエンタープライズまで世界中の多くの企業で導入されているプラットフォームです。

11-2. GitLabのロードマップ機能の特徴

GitLabではソフトウェア開発におけるプロジェクト管理にも適しています。ロードマップ機能では、エピック（プロジェクトの大枠や目標）とマイルストーンをタイムライン形式（ガントチャート風）で視覚的に表示することが可能であるため、最終的な目標を意識しつつマイルストーン達成に向けた進捗を把握できます。

また、イシュー（タスク）の整理やタスク同士の依存関係の設定、担当者の振り分け、作業時間の測定も行えるため、タスクの見落としの防止や潜在的な障害の回避にもつなげられます。

その他にもスプリントを設定できる機能もあるため、アジャイル開発を計画的に進めたいシーンでもGitLabを活用できます。

12. ロードマップ作成に関するよくある質問

最後にロードマップ作成に関するよくある質問とその回答を紹介します。

12-1. 作成手段は専用ツールとエクセルどちらが良い？

エクセルの場合は操作に慣れていれば手軽に作成できるメリットはありますが、リアルタイムでの情報共有が難しいというデメリットもあります。例えば、何らかの要因によりスケジュールに変更があり、ロードマップを更新した際にはクラウドサービスなどの媒体を使って共有しなければならず手間がかかります。

一方、GitLabのような専用のツールなら単一のプラットフォームでロードマップの作成から更新、共有までが可能になるため、正確かつ迅速な情報共有が可能になります。また、プロジェクト管理に役立つさまざまな機能が搭載されており、包括的なサポートを受けられるという観点から考えても専用ツールの導入はプロジェクト開発を円滑に進める上で効果的な手段であると言えます。

12-2. 開発においてロードマップには誰が関与する必要がある？

ロードマップにおいては、プロジェクトマネージャーやリーダー、開発エンジニア、経営層、顧客などを含めて関係者全員が関与しなければなりません。ロードマップを通して目標やマイルストーンなど必要な情報を全員が把握しておくことで、無駄のないスケジュール進行が可能になり、プロジェクトを成功に導けるでしょう。繰り返しにはなりますが、ロードマップを関係者全体に対して正確に共有するには、専用ツールの導入がおすすめです。

12-3. ロードマップの作成が失敗する原因は？

ロードマップの作成や活用が失敗してしまう主な原因は以下の通りです。

プロジェクトマネージャーだけで作成して関係者間で入念な擦り合わせができていない
エクセルで作成しており、更新の際に情報共有に時間がかかっている
定期的な確認や見直しができておらず、ロードマップ自体が機能しなくなっている
盛り込む情報が多く、メンバーがわかりづらいなど

上記のようなことがあるとロードマップを作成しても有効活用できないため、関係者間での入念な擦り合わせや専用ツールの積極的な活用、定期的なアップデートなどを行うことが大切です。

まとめロードマップはソフトウェア開発に必須！専用ツールの活用で効率よく作成しよう

ソフトウェア開発におけるプロジェクトを成功させるためには、ロードマップの作成は必須です。ロードマップ作成においては、ガントチャートの要素を取り入れることで、より綿密なプロジェクト管理を実現できるでしょう。

AIを搭載したDevSecOpsプラットフォーム「GitLab」なら、プロジェクト管理やロードマップ作成に役立つ豊富な機能を搭載しています。自社のソフトウェア開発におけるプロジェクト管理を適切に行うなら、ぜひGitLabの導入をご検討下さい。

なお、GitLabでは世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧下さい。

2024グローバルDevSecOpsレポートはこちら

GitLab 18.4: 自動化と分析を活用したAIネイティブ開発

2025-09-23T00:00:00.000Z

デベロッパーならご存知のとおり、現代の開発はコードを書くだけではありません。ソフトウェア開発ライフサイクル全体にわたって変更を管理することが求められます。

GitLab 18.3では、真の人間とAIのコラボレーションの基盤を築きました。Claude Code、Codex CLI、Amazon Q CLI、Gemini CLIなどの主要なAIツールをGitLabにネイティブ統合として導入し、Cursorとの提携によるGitLab Model Context Protocol（MCP）サーバーの初回プレビューを提供しました。また、「イシューからMRフロー」と「Jenkinsフロー向けのConvert CIファイル」という2つの新しいフローを提供し、チームが日常的な問題に取り組めるようにしました。

GitLab 18.4では、カスタムエージェントの構築と共有機能の拡張、Agentic Chatによる効果的なコラボレーション、Knowledge Graphを使用したコードベースのナビゲーション、パイプライン修正フローによるパイプラインの継続的な正常稼働をサポートしつつ、AI使用に対するセキュリティとガバナンスも強化しています。

GitLab 18.4リリースの最新機能についてのご質問がある方は、Developer Showにご参加ください。LinkedInでライブ配信を9月23日午前10時（太平洋時間）に行います。見逃した方は、その後すぐにオンデマンドでご覧いただけます！

エクスペリエンスを構築する

まずはAI Catalogから始めましょう。優先順位を明確にし、ルーティン作業を自動化し、構築に集中できるようにする専門エージェントのライブラリです。

専門エージェントライブラリとしてのAI Catalog（試験版）

GitLab 18.4では、GitLab Duo AI Catalogを導入します。これは、組織全体でカスタム構築されたエージェントを作成、共有、コラボレーションできる中央ライブラリです。すべてのチームには「独自のやり方」があります。カスタムエージェントの作成は、組織における「正しいやり方」を他のエンジニアに教えるようなものです。

例えば、カスタム製品計画エージェントは、ラベリング標準に従って特定の形式でバグを報告できます。テクニカルライターエージェントは、規約に従って簡潔なドキュメントを作成できます。セキュリティエージェントは、すべてのMRでセキュリティとコンプライアンスの基準が満たされていることを確認できます。これらのエージェントは、切り離されたツールとして機能するのではなく、GitLab内の自然な作業の流れの一部となり、確立されたプロセスを妨げることなくタスクの加速をサポートします。

注意： この機能は現在GitLab.comでのみ試験版として利用可能です。Self-Managedのお客様への提供は、来月の18.5リリースで予定しています。

フローに集中する

GitLab Duo Agentic Chatにより、エージェントとのシームレスなコラボレーションが可能になります。

エージェントとのコラボレーションを効率化するよりスマートなAgentic Chat（ベータ版）

GitLab Duo Agent Platformの中心となるAgentic Chatは、AIエージェントとのシームレスなコラボレーションを実現します。GitLab 18.4でのAgentic Chatの最新アップデートは、チャット体験を向上させ、セッションの管理方法と表示方法を拡張しました。

カスタムエージェントとのチャット

まずは新しく作成したカスタムエージェントから始めましょう。設計が完了したら、Agentic Chatを通じてすぐにそのエージェントを活用できます。例えば、新しいエージェントに「タスクのリストを教えて」と尋ねれば、その日の優先事項から取り掛かることができます。さらに、新しいエージェントとの新しい会話を開始したり、コンテキストを失うことなく以前のエージェントとの会話を再開できる機能の追加されました。
ユーザーモデル選択

以前のリリースでは、ネームスペースレベルでモデルを選択できましたが、18.4では特定のチャットセッションに対してユーザーレベルでモデルを選択できるようになりました。これにより、どのLLMがそのタスクに適しているかを決定したり、異なるLLMを試して、タスクに最適な回答を提供するものを確認したりできます。
フォーマットとビジュアルデザインの改善

GitLab Duo Agentic Chatの新しいビジュアルデザインを気に入っていただけることを願っています。ツール呼び出しの承認処理も改善され、より快適なエクスペリエンスを提供します。
Agentic Chatを通じて利用可能なエージェントセッション

セッション機能が、Agentic Chatの中心的な機能として強化されました。エージェントが実行する処理やワークフローは、すべてAgentic Chatのセッション概要画面で確認できます。各セッション内では、ジョブログ、ユーザー情報、ツールのメタデータなどの詳細情報が表示され、エージェントが人間の代わりにどのような作業をどのように進めているのかを明確に把握できます。

注意： Agentic Chatのセッション機能は、現在GitLab.comでのみ利用可能です。Self-Managedのお客様への提供は、来月の18.5アップデートで予定しています。

コードベースの力を解き放つ

エージェントにとって、コンテキストこそが鍵です。Knowledge Graphを使用すると、エージェントにより多くのコンテキストを提供できるため、より速く推論し、より良い結果が得られます。

GitLab Knowledge Graphのご紹介（ベータ版）

18.4のGitLab Knowledge Graphは、デベロッパーとエージェントが複雑なコードベースを理解し、ナビゲートする方法を変革します。Knowledge Graphは、プロジェクト全体の接続されたマップを提供し、ソフトウェア開発ライフサイクル全体でファイル、ルート、参照をリンクします。定義へ移動、コードベース検索、チャット内クエリによる参照追跡などのツールを活用することで、デベロッパーは「すべてのルートファイルを表示」や「この変更が他に与える影響は？」といった的確な質問をできるようになります。

このより深いコンテキストにより、チームはより速く、より自信を持って作業を進められます。新しいコントリビューターのオンボーディング、プロジェクト全体での詳細な調査の実施、変更が依存コードに与える影響の調査など、すべてが効率化されます。GitLabのエコシステムが多いほど、Knowledge Graphはより強力になり、人間とAIエージェントの両方に、正確性、スピード、プロジェクト全体の認識を持って構築するための基盤を提供します。今後のリリースでは、プラン、MR、セキュリティ脆弱性など、すべてのGitLabデータをKnowledge Graphに統合していく予定です。今回のKnowledge Graphリリースはローカルコードのインデックス作成に焦点を当てており、gkg CLIがコードベースをRAG用のライブで埋め込み可能なグラフデータベースに変換します。シンプルなワンラインスクリプトでインストールし、ローカルリポジトリを解析し、MCPを介して接続してワークスペースにクエリを実行できます。Knowledge Graphプロジェクの展望は2つあります：デベロッパーが今すぐローカルで実行できる活気あるコミュニティエディションの構築と、それがGitLab.comおよびSelf-Managedインスタンスに完全統合されるKnowledge Graphサービスの基盤となることです。

パイプラインメンテナンスを自動化する

パイプライン修正フローでパイプラインの失敗をより速く修正し、作業に集中できます。

ビジネスを考慮したパイプライン修正フロー

パイプラインを正常に保つことはベロシティの維持にとって重要ですが、従来のアプローチはビジネスへの影響を考慮せずに技術的なトラブルシューティングのみに焦点を当てています。パイプライン修正フローは、技術的分析と戦略的コンテキストを組み合わせることで、この課題に対処します。例えば、顧客向けサービスのデプロイパイプラインの失敗の修正を、夜間のテストジョブよりも自動的に優先したり、実験的な機能ブランチとは異なる方法で優先度の高いリリースブランチのビルド問題にフラグを立てたりできます。

ビジネス認識型の障害検出は、さまざまなワークフローやデプロイターゲットの重要性を理解しながら、パイプラインの実行を監視します。
コンテキストに基づく根本原因分析は、ビジネス要件、最近の変更、プロジェクト間の依存関係と共に障害ログを分析し、根本的な原因を特定します。
戦略的な修正の優先順位付けは、ビジネスへの影響、期限、リソース割り当ての優先順位を考慮しながら適切な修正を生成します。
ワークフロー統合型の解決は、適切なレビュープロセスを維持しながら修正を含むマージリクエストを自動的に作成し、優先順位決定のためのビジネスコンテキストを提供します。

このフローは、戦略的な整合性を保ちながらパイプラインを正常に保ち、自動修正が単に技術的な問題を解決するだけでなく、ビジネス目標をサポートできるようにします。

AI環境をカスタマイズする

自動化は、背後にあるモデルを信頼できる場合にのみ機能します。そのため、18.4では、モデル選択やGitLab管理キーなどのガバナンス機能を提供しています。

機能パフォーマンスを最適化するGitLab Duoモデル選択

モデル選択が一般提供開始となり、GitLab Duoを支える大規模言語モデル（LLM）を直接制御できるようになりました。選択したモデルを、組織全体に適用したり、機能ごとにカスタマイズすることもできます。ガバナンス、コンプライアンス、セキュリティ要件を考慮しながら、ネームスペースやツール全体で一貫性を確保できるようにするデフォルト設定が可能です。

GitLab Duo Self-Hostedを使用しているお客様には、新たに追加されたGPT OSSとGPT-5のサポートにより、AIを活用した開発ワークフローに柔軟性がさらに加わります。

注意： GitLab Duo Self-HostedはGitLab.comのお客様はご利用できません。また、GPTモデルはGitLab.comではサポートされていません。

機密コンテキストを保護する

ガバナンスとともに、データ保護も提供され、AIがアクセスできる情報・できない情報を細かく制御できます。

詳細なデータ保護のためのGitLab Duoのコンテキスト除外機能

AIエージェントがアクセスできる情報を細かく制御する必要があることは言うまでもありません。18.4のGitLab Duoのコンテキスト除外機能は、特定のファイルまたはファイルパスをAIアクセスから除外できるプロジェクトレベルの設定を提供します。機能には以下が含まれます：

ファイル固有の除外により、パスワード設定、シークレット、独自のアルゴリズムなどの機密ファイルを保護できます。
パスベースのルールにより、ディレクトリ構造やファイル命名規則に基づいて除外パターンを作成できます。
柔軟な設定により、開発ワークフローの効率を維持しながら、プロジェクトレベルで除外を適用できます。
監査の可視性により、除外されたコンテンツを追跡し、データガバナンスポリシーへの準拠をサポートします。

GitLab Duoのコンテキスト除外機能は、エージェント型AIで開発を加速しながら、機密データを保護します。

新しいMCPツールでAI機能を拡張する

拡張されたMCPツールにより、GitLab環境をより広範なインテリジェントエージェントのエコシステムと接続し、その機能をさらに拡張します。

GitLab MCPサーバーの新ツール

18.3で導入された初期のMCPサーバーを拡張して、GitLab 18.4では、MCPツール（MCPクライアントがGitLabとやり取りする方法を定義する機能）を追加しています。これらの新しいツールは統合の可能性を拡張し、ファーストパーティとサードパーティの両方のAIエージェントが、既存のセキュリティと権限モデルを遵守しながら、プロジェクトデータへのアクセス、コード操作の実行、リポジトリ全体での検索など、より豊富なタスクを実行できるようにします。18.4の新機能を含むMCPツールの完全なリストは、MCPサーバードキュメントをご覧ください。

インテリジェントなソフトウェア開発の未来を体験する

GitLab Duo Agent Platformにより、エンジニアは単一スレッドで一度に1つのイシューに取り組む作業から、チームメイトのように機能する非同期エージェントとのマルチスレッドコラボレーションに移行し、より速く作業を完了できるようになります。私たちは、お客様の独立性と選択への要望に応えるユニークなビジョンを市場に提供しています。お好みのクラウド環境で、最適なLLMとAIツールを使用して実行し、設定したセキュリティとコンプライアンスのガードレール内で作業できます。

このイノベーションの重要な部分として、GitLab 18.4は単なるソフトウェアアップグレード以上のものであると言えるでしょう。デベロッパーの日常体験をよりスムーズで、スマートで、安全なものにすることを目的としています。再利用可能なエージェントからビジネス認識型のパイプライン修正まで、すべての機能はチームがスピード、セキュリティ、制御のバランスを保ちながら作業に集中できるように設計されています。これらの機能が実際にどのように機能するかの詳細については、デモ動画をご覧ください。

GitLab PremiumおよびUltimateをご利用中のお客様は、GitLab.comとSelf-Managed環境で、これらの機能を今すぐご利用いただけます。GitLab Dedicatedのお客様への提供は来月を予定しています。

GitLab Duo Agent Platformのベータ版と試験的機能を今すぐ有効にして、フルコンテキストAIがチームのソフトウェア構築方法をどのように変革できるかをぜひ体験してください。GitLabが初めての方は、無料トライアルを開始できます。　開発の未来がなぜAIを活用し、安全で、世界で最も包括的なDevSecOpsプラットフォームを通じてオーケストレーションされるのかを体験してください。

GitLabを最新の状態に保つ

最新の機能、セキュリティアップデート、パフォーマンス改善を確実に受け取るために、GitLabインスタンスを最新の状態に保つことをお勧めします。アップグレードの計画や完了に役立つ以下のリソースをご確認ください：

アップグレードパスツール – 現在のバージョンを入力して、インスタンスの正確なアップグレード手順を確認
アップグレードドキュメント – サポートされている各バージョンの詳細なガイド（要件、ステップバイステップの手順、ベストプラクティスを含む）

定期的にアップグレードすることで、チームが最新のGitLab機能を活用し、安全でサポートされた状態を維持できます。

手間をかけたくない組織には、GitLabのマネージドメンテナンスサービスをご検討ください。マネージドメンテナンスにより、GitLabの専門スタッフがSelf-Managedインスタンスを確実にアップグレードし、安全に保ち、DevSecOpsをリードする準備を整えている間、チームはイノベーションに集中できます。詳細については、担当営業にお問い合わせください。

このブログ投稿には、1933年証券法第27A条（改正後）および1934年証券取引所法第21E条の意味における「将来予想に関する記述」が含まれています。これらの記述に反映されている期待が合理的であると考えていますが、実際の結果または成果が大きく異なる可能性がある既知および未知のリスク、不確実性、仮定、その他の要因の影響を受けます。これらのリスクやその他の要因に関する詳細は、SECへの提出書類の「リスク要因」というタイトルの下に含まれています。法律で義務付けられている場合を除き、このブログ投稿の日付以降、これらの記述を更新または改訂する義務を負いません。

プラットフォームエンジニアリングとは？意味や導入メリットをわかりやすく解説

2025-09-22T00:00:00.000Z

近年ソフトウェア開発の領域では「プラットフォームエンジニアリング」と呼ばれる開発者の生産性向上に寄与するアプローチが注目されています。

実際にプラットフォームエンジニアリングに興味はあるものの、意味や定義などを詳しく理解していない人も多いのではないでしょうか。

この記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。具体的な導入ステップや基盤構築に役立つおすすめのプラットフォームも紹介するのでぜひ参考にして下さい。

1. プラットフォームエンジニアリングとは？

まずはプラットフォームエンジニアリングの意味や特徴について解説します。

1-1. プラットフォームエンジニアリングの意味・特徴

プラットフォームエンジニアリングとは、企業内の開発者に対して適切なプラットフォーム（IDP）を整備し、ソフトウェア開発の効率化や生産性向上を実現するアプローチのことです。

近年はIT技術の発展や消費者ニーズの多様化などを背景として将来の予測が難しい時代（VUCA時代）だと言われています。プラットフォームエンジニアリングは、VUCA時代において複雑化するビジネスニーズに対応するための新しいエンジニアリング手法として、ガートナー社が積極的に提案しているアプローチでもあります。

1-2. IDP（内部開発者向けプラットフォーム）とは

Internal Developer Platform（内部開発者向けプラットフォーム、以下IDP）とは、企業内の開発者が開発プロセスにおいて必要な機能やリソースを自ら取得して利用できるプラットフォームを指し、プラットフォームエンジニアリングの導入における重要な技術基盤に当たります。

IDPを通してチームで共通して利用できるツールやリソースを開発者に提供することで、迅速なソフトウェアの構築やデプロイを実現できます。

IDPの構築においては、自社の課題や目的に応じてさまざまなツールや技術を組み合わせて行いますが、GitLabのように単一のプラットフォームで開発プロセスにおける多くの作業を効率化できるサービスもあります。

2. プラットフォームエンジニアリングが注目されている背景

ソフトウェア開発の領域でなぜプラットフォームエンジニアリングが注目されているのでしょうか。具体的な背景としては以下が挙げられます。

開発環境の複雑化
ビジネス環境の激化
IT人材の不足

2-1. 開発環境の複雑化

プラットフォームエンジニアリングの必要性が高まっている背景の一つとしてまず挙げられるのが、開発環境の複雑化による開発者の認知負荷の増大にあります。

ソフトウェア開発における開発手法や技術は年々進化・発展し続けており、クラウドや生成AI、マイクロサービス、APIなどさまざまな技術が広く使われるようになっています。これらの技術活用によって柔軟なソフトウェア開発を実現できますが、その一方で管理すべきツールの種類が増え、かつ多様な技術を身につけなければならないという課題が発生します。

それにより、開発者は重要な開発作業や取り組み以外に自身のリソースを割く必要があり、それが結果としてチーム全体の生産性低下も招くことになります。

つまり、ソフトウェア開発において効果的に最新技術を取り入れていくためには、開発者が本質的な業務に集中できる環境を構築しなければなりません。

2-2. ビジネス環境の激化

先ほども少し触れていますが、近年はVUCA時代と呼ばれる将来の予測が難しい不確実な要素が多い時代です。

市場が常に変化する中で社会や消費者にとって必要とされる価値あるソフトウェアを開発して競合と差別化を図るためには、多様な技術を活用したスケーラブルな開発が求められます。

また、自社の競争力を高めていくためには、アジャイル開発のようなスピード感のある開発手法を積極的に採用していく考えも大切です。

開発者がセルフサービスで利用できるプラットフォームの提供は、柔軟かつ迅速なソフトウェア開発を実現する手段として有効なアプローチだと言えます。

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

2-3. IT人材の不足

ソフトウェア開発の領域では、慢性的な人手不足が課題となっています。クラウドやAIなど高度な最新技術が次々と登場する一方で、それらを扱える専門知識を持った人材が業界全体で不足しているのです。

実際に「IT人材需給に関する調査」を見てみると、2030年には最大で約79万人のIT人材が不足すると予測されています。

※引用元：IT人材需給に関する調査

このような背景の中で適切にソフトウェア開発を進めていくためには、プラットフォームエンジニアリングの導入を通じて開発者の負担削減や生産性向上を実現し、自社のリソースを上手に活用していく姿勢や工夫が求められると言えます。

3. プラットフォームエンジニアリングとDevSecOps・SREとの関係性とは

プラットフォームエンジニアリングを理解する上では、DevSecOpsやSREとの違いについても把握しておくことが大切です。

3-1. DevSecOpsとの違い

DevSecOpsとは、開発（Dev）、セキュリティ（Sec）、運用（Ops）の3つの領域を連携させて開発を進めるアプローチを指します。開発と運用を連携してリリースサイクルを短縮させる従来の「DevOps」の考え方に対して、セキュリティ（Sec）のプロセスも加えることでソフトウェアの安全性を確保しつつ、迅速なリリースが可能になります。

一方、プラットフォームエンジニアリングはDevSecOpのようなワークフローを実現する上で土台となるプラットフォームを社内で整備する取り組みです。

つまり、プラットフォームエンジニアリングとDevSecOpsは親和性が高く、プラットフォームエンジニアリングはDevSecOpsをサポートする役割を担っていると言えます。

3-2. SREとの違い

SREとは、「Site Reliability Engineering」の略語で直訳すると、「サイト信頼性エンジニアリング」になります。Google社によって提唱された概念であり、運用プロセスにおいて手間のかかるタスクを自動化してシステムの安定稼働を実現しつつ、新機能の追加や更新などを通してユーザー体験（UX）の向上を目指す取り組みを指します。

プラットフォームエンジニアリングとSREは、いずれも開発と運用における効率性・信頼性向上に関わるものですが、それぞれ目的や焦点が異なります。

プラットフォームエンジニアリングは、社内の開発者の生産性向上や利便性向上を目的としたアプローチであり、SREは主にシステムの信頼性と可用性、スケーラビリティの向上に焦点を当てた考え方になります。

4. プラットフォームエンジニアリングの導入目的とメリット

プラットフォームエンジニアリングの導入目的やメリットは以下の通りです。

開発プロセスの効率化
開発者の生産性向上
プロダクトの品質向上
セキュリティ・ガバナンスの維持と強化
人材不足の解消
新しいイノベーションの創出
コスト削減

4-1. 開発プロセスの効率化

まずプラットフォームエンジニアリングの導入は、開発プロセスの効率化につなげられます。

IDPにより開発者は開発に必要なリソースを必要な時に素早く取得して利用できるため、環境構築に手間と時間をかけることなく本質的な開発業務に集中することが可能です。

アジャイル開発やDevSecOpsの手法を活用する際に、積極的にプラットフォームエンジニアリングの考え方も採用すれば、プロダクトや機能のリリース頻度・スピードが向上し、自社ビジネスの加速化に貢献できるでしょう。

4-2. 開発者の生産性向上

プラットフォームエンジニアリングでIDPを整備することで、チームで再利用可能なツールと機能を開発者に提供できるようになります。この仕組みにより、開発者それぞれで多数のツールを管理・運用する手間がなくなり、認知的負荷の軽減につなげられるでしょう。

その結果、戦略立案や分析、新機能開発などより重要な業務にリソースを割けるようになり、生産性の最大化を図れるでしょう。

4-3. プロダクトの品質向上

顧客が満足するプロダクトを提供するためには、品質も担保しなければなりません。IDPに対してテストやレビュー、セキュリティスキャン、デプロイなどを自動化する仕組みを整備すれば、ヒューマンエラーの防止につなげられます。

プラットフォームエンジニアリングの導入でテストやレビューなどを標準化することによって、開発者やプロジェクトごとの品質のバラつきを防止でき、自社で定義されたプラットフォームの基準に沿って開発と運用を進められます。

つまり、プラットフォームエンジニアリングの導入は、開発効率や生産性の向上だけでなく、プロダクト品質や信頼性の向上にも寄与します。

4-4. セキュリティ・ガバナンスの維持と強化

プラットフォームエンジニアリングで自社に必要なセキュリティやガバナンスを定義し、それらを自社のプラットフォーム上に反映させて運用することも可能です。

権限設定や監査ログ、セキュリティポリシー、脆弱性対応などをプラットフォーム上で集約して一元化することで管理や証跡の収集が容易になり、組織全体におけるセキュリティ・ガバナンスの維持と強化につなげられるでしょう。

また、標準化されたプラットフォームの整備によって、開発者の心理的な負担を軽減して安全に開発を進められます。

4-5. 人材不足の解消

プラットフォームエンジニアリングの導入は、開発プロセスの効率化や開発者の生産性向上に寄与するため、企業のリソースを最大限に活かしながらソフトウェア開発を進められます。

また、開発者のニーズにマッチしたプラットフォームを提供して働きやすい環境を構築することで、開発者体験（Developer Experience）の向上も実現できます。その結果、自社に対する開発者や求職者からのイメージも良くなり、優秀なエンジニアの獲得と定着を図れるでしょう。

4-6. 新しいイノベーションの創出

近年ソフトウェア開発の効率化や価値向上に役立つさまざまな最新技術が登場しています。しかし、複数の技術やツールを開発者個人で活用するには管理の負担が増えてしまい、実際の活用にはハードルが高いと言えます。

プラットフォームエンジニアリングならさまざまな機能やツールが搭載されたプラットフォームをチームで利用できるため、開発者全員が最新技術に触れやすくなります。それをきっかけとして自社で新しいアイデアやイノベーションが生まれたり、より品質の高いプロダクトをリリースできたりする可能性が高まるでしょう。

4-7. コスト削減

プラットフォームエンジニアリングを取り入れることで、ツールや環境の共通化によるコスト削減にもつながります。例えば、ソフトウェア開発のプロセスにおいて複数のツールを活用している企業が、GitLabのようなさまざまなツールを単一のプラットフォームで利用できるサービスを導入すれば、ライセンス費用や管理コストの削減につなげられるでしょう。

また、CI/CDやセキュリティチェックなどをプラットフォーム上で自動化することで運用コストの削減も実現できます。

ワークフローの自動化や標準化により開発スピードが向上すれば、限られたリソースを効果的に活用できるため、長期的な人件費の最適化にもつながります。

5. プラットフォームエンジニアリングの導入ステップ

ここでは実際にプラットフォームエンジニアリングを導入する際の手順について見ていきましょう。

専門チームの組成
開発課題の分析と目標設定
プラットフォームの構築・組織体制の変更
フィードバック・継続的なメンテナンス

5-1. 専門チームの組成

プラットフォームエンジニアリングを導入する際には、まず専門チームの組成から始めます。専門チームを社内に配置すれば、プラットフォームエンジニアリング導入の取り組みを推進できます。専門チームの主な役割としては以下が挙げられます。

開発者のニーズ調査
プラットフォームの設計・構築
社内でのプラットフォーム活用の浸透の実現
プラットフォームの運用・定期的な改善など

実際のメンバー構成においては、開発者のさまざまなニーズを考慮したプラットフォームを導入するためにも、開発・運用・セキュリティなど多様なスキルセットを持つ人材や、それぞれの分野を専門とする人材を集めることがポイントです。

また、社内向けではあるものの、自社での活用を浸透させるためにはプラットフォームを一つのサービスとして捉え、ユーザーニーズを満たすという視点が重要になります。

5-2. 開発課題の分析と目標設定

プラットフォームエンジニアリングの専門チーム結成後は、現状の開発課題の把握と分析を実施します。課題の把握や分析においては、エンジニアとの個別面談やサーベイなどを通して行います。

その中で、「複数のツールを管理するための負担がかかり過ぎている」「開発環境の構築から実際のリリースまで時間がかかっており、開発効率が悪い」などの課題が挙げられたなら、それらの課題を解決するためにどのようなプラットフォームを導入すれば良いのかを検討し、具体的な目標を設定します。

例えば、開発者のツール管理の負担が主な課題としてあるなら、単一のプラットフォームで複数のツールや技術を活用できるIDPを整備するという方向性を定められるでしょう。

5-3. プラットフォームの構築・組織体制の変更

プラットフォームエンジニアリングの導入における目標や方向性が明確になった後は、実際に基盤となるプラットフォームの構築を行います。

開発プロセスの課題解決につながるような機能やツールを搭載し、さまざまな手法で開発を進められるよう整備していきます。

また、プラットフォームを構築して実際に活用していく際には、これまでの開発プロセスに変化が生じるため、必要に応じて開発者間での認識の擦り合わせや組織体制の変更を行いましょう。

5-4. フィードバック・継続的なメンテナンス

プラットフォームエンジニアリングの基盤構築後は、実際にプラットフォームを運用し開発者に活用してもらいます。その中で開発者からフィードバックや要望があれば、機能追加や改善を柔軟に行っていきます。

ソフトウェア開発におけるツールや技術は進化し続けており、トレンドも常に移り変わるため、最新情報のキャッチアップや定期的なメンテナンスがプラットフォームエンジニアリングを成功させるための鍵となります。

6. プラットフォームエンジニアリングの導入における注意点

プラットフォームエンジニアリングの導入においては以下のような注意点もあります。

プラットフォーム構築を目的としない
導入に効果が期待できるか見極める
トップダウンでの導入は避ける
段階的に導入して小さく始める

6-1. プラットフォーム構築を目的としない

まずプラットフォームエンジニアリングの導入において、プラットフォーム構築そのものを目的として進めてしまうと失敗してしまう可能性が高まります。

例えば、「最新技術だから」「高機能だから」というような考えだけで導入してしまうと、開発者ニーズにマッチしないプラットフォームを構築してしまうことになります。そうなると、社内での活用も浸透せず、誰にも使われないという結果を招いてしまうでしょう。

そのため、開発者への調査を徹底して行い、どんな課題を解決したいのかを明確にした上でプラットフォームを構築する必要があります。

6-2. 導入に効果が期待できるか見極める

プラットフォームエンジニアリングの導入そのものが、実際に自社にとって効果が期待できるのかも見極めなければなりません。

例えば、エンタープライズや中規模など大きめ組織で、かつ必要な人材が揃っているなら、専門チームの組成もスムーズに進み、実際のプラットフォーム構築によって開発の効率化やコスト削減などの効果が期待できる可能性が高いと言えます。

一方、小規模な組織の場合で、かつ人手が足りない場合プラットフォーム構築や運用そのものに大きな負担がかかってしまい、逆効果になる可能性もあります。

そのため、「プラットフォームエンジニアリングの導入や運用が自社で可能なのか」「実際にどのような効果が期待できるのか」をきちんと検討することが大切です。

6-3. トップダウンでの導入は避ける

プラットフォームエンジニアリングは開発者向けのアプローチであり、開発者がプラットフォームを問題なくセルフサービスで利用できるという要素が重要になります。

そのため、トップダウンで現場の課題や開発者のニーズを無視して導入を進めてしまうと、新しいやり方に対して開発者から抵抗や反発を受ける可能性があります。

スムーズな導入を実現するためには、経営層と開発者で双方向コミュニケーションをとり、開発者に選択の余地とアイデアを積極的に発信できる場を与える必要があります。

6-4. 段階的に導入して小さく始める

最初から全ての要件を満たした完璧なプラットフォームを構築して、運用しようとすると開発者が変化に対応しきれない可能性があります。また、時間をかけてプラットフォームを構築しているとトレンドに乗り遅れ、完成後には搭載した技術やツールが既に古いものになってしまっていたというケースも考えられます。

そのため、まずは優先度の高い課題にフォーカスして、効果が期待できる機能から実装し段階的に運用するなど、アジャイル的な進め方がプラットフォームエンジニアリングの導入に求められると言えます。

7. プラットフォームエンジニアリングの基盤構築に役立つツール・サービスの選び方

プラットフォームエンジニアリングの導入においては、基盤構築に役立つサービスを積極的に活用すると効率的です。ここでは具体的な選び方を解説します。

機能
コスト
サポート体制

7-1. 機能

プラットフォームエンジニアリングの導入を成功させるためには、開発者のニーズを満たし、かつ自社の課題を解決できる機能が搭載されたサービスを選ぶことが大切です。

例えば、プラットフォームを構成する重要な要素として挙げられる機能は以下の通りです。

CI/CD（自動ビルド・テスト・デプロイ）
ソースコード管理
ドキュメント
モニタリング
API連携
セキュリティ・ガバナンスなど

このような機能が搭載されているサービスなら、開発者の生産性向上に貢献できるでしょう。

7-2. コスト

プラットフォームエンジニアリングの基盤構築となるサービスを選定する際には、コスト面も考慮することが大切です。

組織の規模や導入形態などによってもコストが異なるため、ベンダーに問い合わせするなどして費用対効果が期待できるかしっかりチェックしておきましょう。

無料トライアルを設けているサービスも多いため、まずは使用感を試してみてから導入を検討するのも良いでしょう。

7-3. サポート体制

プラットフォームエンジニアリングをスムーズに導入・運用していくためには、ツールやサービスを提供するベンダーのサポート体制をチェックしておく必要もあります。

充実したサポート体制があれば、万が一トラブルや不明点が発生した場合でも、専任スタッフが迅速に対応してくれるでしょう。また、ベンダーがドキュメントやマニュアルなどを通して積極的にノウハウを公開していれば、トラブル時にも自社で解決しやすくなるでしょう。

8. プラットフォームエンジニアリングの基盤構築なら「GitLab」

プラットフォームエンジニアリングの基盤構築をスムーズに実現するなら「GitLab」の活用がおすすめです。ここでは、GitLabのサービス概要や強みについて紹介します。

8-1. GitLabとは

GitLabは、DevSecOpsワークフローを支援するAIを搭載したプラットフォームです。AIによるソースコード管理やセキュリティ対策、CI/CD、コンプライアンス管理など豊富な機能を単一のプラットフォームで活用でき、プラットフォームエンジニアリングの基盤構築に役立てられます。

中小企業からエンタープライズまで多くの企業で導入されているプラットフォームで、高品質かつ迅速なソフトウェア開発を実現できます。

8-2. GitLabが選ばれる理由

GitLabの強みは、DevSecOpsツールチェーンの構築を単一のプラットフォームで実現できることです。これまで複数のツールを管理していた企業がGitLabを導入すれば、コスト削減や開発者の認知負荷の軽減につなげられ、プラットフォームエンジニアリングの運用をスムーズに行えるようになります。

チーム全員で単一のプラットフォームを通して作業することで、メンバー間の連携や情報共有も容易に実施できます。また、サポート体制も充実しているため、導入と運用においても安心して進められるのも強みの一つです。

GitLabを通してプラットフォームエンジニアリングを実現すれば、ソフトウェア開発のライフサイクル全体を効率化でき、競合との差別化につながる機能開発など本質的な作業に集中できるようになるでしょう。

9. GitLabによるプラットフォームエンジニアリング実現のアプローチと活用例

実際にGitLabによるプラットフォームエンジニアリング実現のアプローチと活用例を紹介します。

再利用可能なCI/CDコンポーネント
セキュリティとコンプライアンス
データ活用と分析
コミュニケーションの効率化

9-1. 再利用可能なCI/CDコンポーネント

CI/CDコンポーネントは、再利用可能な単一のパイプライン構成ユニットのことで、この機能を使用すればCI/CDパイプラインの設定が容易になります。

また、再利用可能なCI/CDコンポーネントをリスト化して、各コンポーネントの情報を確認できる「CI/CDカタログ」も提供しています。コンポーネントが一元管理されているため、必要なものを必要な時に見つけ出して再利用できる仕様となっています。

これにより、開発者の作業効率向上や、組織全体でのスムーズなナレッジ共有を実現できるでしょう。

CI/CDコンポーネントの詳細については以下のページをご覧下さい。

GitLab入門：CI/CDについて理解する

9-2. セキュリティとコンプライアンス

GitLabでは、ソフトウェア開発ライフサイクルの全てのステージに対応したセキュリティやコンプライアンス機能を搭載しています。

開発を進める中で、セキュリティリスクなどの問題を早期に発見して対応できるため、トラブル発生時の対応コストを抑えたり、事態の深刻化を未然に防止したりすることが可能です。

9-3. データ活用と分析

GitLabでは、データ活用と分析による開発の効率性向上も実現できます。プロジェクトの運用状況などソフトウェア開発ライフサイクルにおけるさまざまなデータが一元管理されている仕組みとなっているため、関係者全員がスムーズに必要な情報にアクセスできます。

また、プラットフォームに蓄積された主要なメトリクスを追跡して問題点を詳細に分析することで、迅速な改善や顧客価値の向上につなげられます。GitLabでは、DevOpsのパフォーマンスや健全性を示すDORAメトリクスの可視化・分析機能などを提供しています。

9-4. コミュニケーションの効率化

GitLabは統合型プラットフォームであり、全員が同じツールにアクセスして利用できるようになるため、開発者間でのコミュニケーションが効率化されます。

誰もがアクセスしやすい共同ドキュメントの作成も可能であるため、別のツールに切り替えて作業する必要がなく、情報の共有や整理が容易になります。

なお、プラットフォームエンジニアリングにおけるGitLab活用の詳細については以下のページをご覧下さい。

プラットフォームエンジニアリングにおけるGitLabの活用

まとめ：プラットフォームエンジニアリングの実現により開発品質の向上と効率化を図ろう

プラットフォームエンジニアリングの導入は、ビジネス環境が激化している時代において重要視されているアプローチです。実際の導入においては、適切な専門チームの組成やツール・サービスの選定が大切なポイントとなってきます。

プラットフォームエンジニアリングの基盤構築なら、ぜひGitLabをご活用下さい。GitLabなら単一のプラットフォームで豊富な機能を利用できるため、開発者の認知負荷を軽減し、迅速かつ品質の高いソフトウェア開発を実現できます。

2024グローバルDevSecOpsレポートはこちら

監修：川瀬洋平 @ykawase

（GitLab合同会社カスタマーサクセス本部シニアカスタマーサクセスマネージャー）

GitLab 18.4リリース

2025-09-19T00:00:00.000Z

本ブログは、GitLab 18.4 Releaseの抄訳です。内容に相違がある場合は、原文が優先されます。

GitLab Duo Model Selection（モデル選択）とGitLab Knowledge Graph（ナレッジグラフ）を搭載したGitLab 18.4をリリース

9月23日の新機能: GitLab Duo AI Catalogを導入しました。これは、チームが組織全体でカスタムビルドしたエージェントを作成、共有、協働できる集約ハブです。

このたび、GitLab 18.4のリリースを発表しました。このリリースでは、GitLab Duo Model Selectionの一般提供、GitLab Knowledge Graph、GitLab Duoでのエンドユーザーモデル選択機能の提供開始、さらにCI/CDジョブトークンによるGitプッシュリクエストの認証機能、Duo AI Catalogなど、さまざまな機能が追加されました。

これらの機能は、今回のリリースに含まれる19項目の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。

GitLab 18.4には、GitLabコミュニティのユーザーから136件ものコントリビュートがありました。ありがとうございました！GitLabは誰もがコントリビュートできるプラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。

来月のリリースで予定されている内容を先取りするには、今後のリリースページをご覧ください。

Q&A + コード: GitLab 18.4の詳細とコントリビューターコミュニティの発展

次回のGitLab Developer Showでは、GitLab 18.4の最新機能を詳しく解説し、活発なコントリビューターコミュニティの育成についてお話しします。ご質問やライブコードの実演をご覧いただきながら、GitLabとともに成長する方法を具体的にご紹介します。

👉 こちらから登録

GitLab 18.4では、GitLab Duo Model SelectionとGitLab Duo Agent Platform（GitLab Duo Self-Hosted）が追加されました

クリックしてSNSで共有しましょう！

今月の注目コントリビューターはPatrick Riceさんです

Patrick Riceさんは、コントリビューター、メンテナー、メンターとして、GitLabオープンソースコミュニティへの卓越したコントリビュートを継続されています。過去1年間でトップ5のコントリビューターとなったPatrickさんは、GitLab Terraform ProviderおよびClient-goプロジェクトのメンテナンスを担当し、機能追加、リリース管理、イシューのトリアージ、コミュニティのオンボーディングに取り組まれています。コントリビューターからプロジェクトメンテナーへと成長を遂げられ、「誰もがコントリビュートできる」というGitLabのミッションを体現しています。

Patrickさんの活動はコードのコントリビュートにとどまらず、コミュニティ構築とコーチングにまで及び、新しいコントリビューターの参加と成長をサポートしています。以前には、17.11の注目コントリビューター賞を受賞したHeidi Berry氏をノミネート、支援しました。また、GitLab for Educationチームと知見を共有し、学生にGitLabを学習してもらうことで次世代のデベロッパー育成にもコントリビュートしています。

「Terraform ProviderとClient-goプロジェクトでの協力に、新しいコントリビューターの方々にぜひ参加してもらいたいと思います。私たちのコミュニティには、もっと多くの仲間が必要です。」とPatrickさんは言います。

Patrickさんを今回の賞にノミネートしたLee Tickett（GitLab Staff Fullstack Engineer）はPatricさんついて「PatrickさんはGitLabチームとお客様を継続的に支援し続けています。」と述べています。Timo Furrer（GitLab Senior Backend Engineer）もノミネートを支援し、「Terraform ProviderとClient-goへの日々のコントリビュートに加え、GitLab Terraform Providerの可能性を実演することで、IaCジャーニーにおけるGitLabのお客様を直接支援しています」と付け加えました。

PatrickさんはKinglandのエンタープライズアーキテクトで、GitLab Community Core Teamのメンバーでもあります。今回が2回目の注目コントリビューター賞受賞で、初回は2023年1月のGitLab 15.8でした。

継続的なコントリビュートとGitLabのお客様へのサポート、そしてオープンソースコミュニティの成長へのご尽力に対し、Patrickさんに深く感謝いたします！

GitLab 18.4でリリースされた主な改善点

GitLab Duo Model Selection（モデル選択）一般提供開始

GitLab.com: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise
Self-Managed: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise
GitLab Dedicated: Ultimate、Duo Core、Duo Pro、Duo Enterprise

GitLab Duo Model Selectionの一般提供を開始しました。開発ワークフローで使用するAIモデルの選択を組織がより細かく管理できるようになります。

GitLab.comのトップレベルグループオーナー、Self-ManagedおよびDedicatedの管理者は、GitLabホスト型AIゲートウェイ経由でアクセスするGitLab Duo機能において、複数のGitLab AIモデルベンダーの中から特定のモデルを選択できるようになりました。

GitLab.com上の複数ネームスペースに参加しているGitLabユーザーは、すべての開発コンテキストでAIモデル設定を統一するため、デフォルトのネームスペースの設定も可能です。GitLab Duo Model Selectionの詳細については、ブログ記事をご覧ください。

ドキュメント
 イシュー

GitLab Knowledge Graph（ナレッジグラフ）

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate

GitLab Knowledge Graphは、コードベース全体における豊富なコードインテリジェンス機能を提供します。デベロッパーはより多くのコンテキストを基にプロジェクトを理解、操作できるようになり、変更の計画立案、影響分析、GitLab Duoエージェントと連携した開発タスクの効率化が図れます。

GitLab Duo Agent Platformでは、Knowledge Graphを活用してAIエージェントの精度を向上させます。コードベース全体のファイルと定義をマッピングすることで、Knowledge GraphはDuoエージェントがローカルワークスペース全体の構造を理解するための拡張コンテキストを提供し、複雑な質問に対してより迅速で正確な回答を返します。

この機能はベータ版です。イシュー160でフィードバックをお寄せください。

ドキュメント
 エピック

GitLab Duoでエンドユーザーによるモデル選択が可能に

GitLab.com: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise

GitLab Duoでエンドユーザーがモデルを選択できる機能が、GitLab.comでパブリックベータ版として提供開始されました。ユーザーはGitLab UIから直接GitLab Duo Agentic Chatで使用したいモデルを選択できるようになり、ニーズに合わせたAIサポートを受けられます。

GitLab.comのネームスペースオーナーが許可している場合、エンドユーザーはGitLab Duo Agentic Chatで利用できるGitLab AIベンダーのモデルから選択できます。ネームスペースオーナーは、これまで通りネームスペース設定で組織全体のモデルを指定することも、エンドユーザーによるモデル選択を許可することもできます。

利用を開始するには、GitLab Duo Agentic Chatでモデルのドロップダウンメニューから、希望するモデルを選択してください。なお、モデルを変更すると新しい会話が開始され、選択した設定は今後のセッションでも保存されます。

ドキュメント
 イシュー

CI/CDジョブトークンによるGitプッシュリクエストの認証

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate

プロジェクトで生成されるCI/CDジョブトークンを使用して、プロジェクトリポジトリへのGitプッシュリクエストの認証が行えるようになりました。UIの「ジョブトークンの権限」設定、またはプロジェクトのREST APIエンドポイントのci_push_repository_for_job_token_allowedパラメータで有効化できます。

ドキュメント
 イシュー

GitLab Duoのコンテキスト除外機能

GitLab.com: Premium、Ultimate、Duo Pro、Duo Enterprise
Self-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise
GitLab Dedicated: Ultimate、Duo Pro、Duo Enterprise

GitLab Duoのコンテキスト除外機能を使うことで、GitLab Duoが参照するコンテキストから除外したいものを指定できます。パスワードファイルや設定ファイルなどの機密情報を保護したい場合に便利です。特定のファイル、ディレクトリ、ファイル形式、またはこれらを組み合わせた除外設定が可能です。

この機能は現在ベータ版です。イシュー566244でGitLab Duoのコンテキスト除外機能についてフィードバックをお寄せください。

ドキュメント
 エピック

GitLab DedicatedのAWSリージョンサポート拡大

GitLab Dedicated: Ultimate

GitLab DedicatedがすべてのAWSリージョンでのデプロイに対応し、プライマリ、セカンダリ、バックアップのデプロイ先として、より多くのリージョンから選択できるようになりました。

この対応拡大は、GitLab Dedicatedの高可用性とディザスターリカバリー基準を満たすio2ディスクがAWSの全リージョンで利用可能になったことで実現しました。

新しく対応したリージョンは、スイッチボードでGitLab Dedicatedインスタンスをプロビジョニングする際に選択できます。

ドキュメント
 イシュー

異なるブランチに対するCI/CDパイプラインシミュレーション

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate

これまで、パイプラインエディターの「検証」タブで変更内容を検証する際、デフォルトブランチでのシミュレーション実行のみに限定されていました。このリリースで機能を拡張し、任意のブランチを指定してパイプラインシミュレーションを実行できるようになりました。この改善により、パイプラインのテストと検証における柔軟性が大幅に向上し、安定ブランチや機能ブランチなど、さまざまなケースでパイプラインが想定通りに動作するかを確認できます。

ドキュメント
 イシュー

GitLab 18.4リリースに含まれるその他の改善点

イシューページの表示方法を設定する

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

一覧ページの表示を自由にカスタマイズできるようになりました。必要なメタデータを選択し、作業項目をドロワーで開くか、フルページで開くかを選択できるため、重要な情報により集中できます。

これまでは、すべてのメタデータフィールドが常に表示されており、作業項目を確認する際に情報が多すぎると感じることがありました。今回のアップデートで、担当者、ラベル、日付、マイルストーンなどの各項目の表示・非表示を切り替えて、見やすいようにカスタマイズできるようになりました。

新しい表示切替機能により、一覧のコンテキストを保ったままドロワーで詳細を素早く確認したり、詳細な編集や包括的なナビゲーションが必要な場合はフルページ表示に切り替えたりすることが可能です。

ドキュメント
 イシュー

イシューボードでエピック階層の完全表示が可能になりました

GitLab.com: Premium、Ultimate
Self-Managed: Premium、Ultimate

イシューボードにおいて、親エピックでフィルタリングした際に、子エピック内のすべてのイシューを表示できるようになりました。これにより、イシューページと同様の動作に統一され、子エピックにネストされたイシューを見落とすことなく、エピック階層全体の追跡と可視化が可能になります。プロジェクト管理ワークフローの効率性と信頼性が向上します。

ドキュメント
 イシュー

エンタープライズユーザーのプレースホルダー再割り当て時の確認がスキップ可能に

GitLab.com: Premium、Ultimate

グループのオーナーロールを持つユーザーは、そのグループ内のアクティブなエンタープライズユーザーにプレースホルダーを再割り当てする際、ユーザー確認をスキップできるようになりました。これにより、エンタープライズユーザーが再割り当て確認のために頻繁にメールを確認する必要がなくなります。設定された時間制限に達すると、それ以降のすべての新しい再割り当てに対して再びメール確認リクエストが送信されます。

エンタープライズユーザーには再割り当て完了後に通知メールが送られるため、プロセス全体の透明性は維持されます。

ドキュメント
 エピック

CI/CDテンプレートを使用したOpenTofuモジュール・プロバイダーのGitLabコンテナレジストリへの公開

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate

GitLabコンテナレジストリが、OpenTofuモジュールとプロバイダーをホストするためのメディアタイプに対応するようになりました。

OpenTofu CI/CDコンポーネントのバージョン3.1.0では、OCIフォーマットを使用してOpenTofuプロバイダーをGitLabレジストリにデプロイする新しいprovider-releaseテンプレートが追加されました。これにより、プライベートOpenTofuプロバイダーをGitLabで直接ホストできるようになります。

さらに、module-releaseテンプレートには新しいtype入力が追加されました。ociに設定すると、OCIフォーマットを使用してOpenTofuモジュールをGitLabレジストリにデプロイできます。

ドキュメント
 イシュー

パイプラインのシークレット検出で特定ファイル・ディレクトリをデフォルトで除外

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate\

パイプラインのシークレット検出で、シークレット情報を含む可能性の低い特定のファイルタイプやディレクトリが自動的にスキャン対象から除外されるようになりました。これにより、スキャンパフォーマンスが向上します。この機能はアナライザーのバージョン7.11.0でリリースされます。

ドキュメント
 イシュー

高度なSASTスキャンが大幅に高速化

GitLab.com: Ultimate
Self-Managed: Ultimate
GitLab Dedicated: Ultimate

マージリクエストやパイプラインでセキュリティスキャンを実行する際、スキャン時間の短縮は非常に重要です。GitLabは、高度なSASTのエンジンと検出ルールの両方に対し、継続的にパフォーマンスの改善に取り組んでいます。

今回のリリースした改善により、ベンチマークテストと実際の環境でのテストにおいて、スキャン実行時間を最大78%短縮することができました。スキャン処理の中でもパフォーマンスが重要な部分にキャッシュ機能を追加したことで、大規模なリポジトリでのスキャンが大幅に高速化されます。

この改善は、高度なSASTアナライザーのバージョン2.9.6以降で自動的に有効になります。使用しているアナライザーのバージョンは、スキャンジョブのログで確認できます。

ドキュメント
 エピック

ジョブアーティファクトダウンロード権限をより細かく制御

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate

GitLab 16.11では、artifacts:accessキーワードが追加され、アーティファクトのダウンロード権限を以下のように設定できるようになりました：。

パイプラインにアクセスできるすべてのユーザー
デベロッパーロール以上のユーザーのみ
誰でもダウンロード不可

今回のリリースでは、新たに「メンテナーロール以上のユーザーのみ」という設定も追加され、ジョブアーティファクトのダウンロードをより細かく制御できるようになりました。

ドキュメント
 イシュー

グループ、アプリケーション単位での自動Duoコードレビュー

GitLab.com: Premium、Ultimate、Duo Enterprise

グループまたはアプリケーション設定から、複数プロジェクトで自動Duoコードレビューを有効にできるようになりました。従来のように特定プロジェクトを個別に有効化するのではなく、グループ内のすべてのプロジェクトでDuoコードレビューを迅速に有効化できます。

この機能は現在GitLab.comで利用可能です。GitLab Self-Managedでの提供は今後のリリースで予定しています。本機能に関するフィードバックはイシュー517386までお寄せください。

ドキュメント
 イシュー

エピック・イシューリストの親フィルター機能を強化

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

イシューページとエピックページの「エピック」フィルターを、より使いやすい「親」フィルターに変更しました。これまでエピックのみで絞り込みできていたところが、すべての親作業アイテムでのフィルタリングに対応します。親イシューで子タスクを簡単に見つけたり、親エピックでイシューを見つけたりできるようになり、イシューリストとエピックリストの両方で作業階層がより把握しやすくなりました。

ドキュメント
 イシュー

テキストエディターツールバー機能の統一

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate

GitLabプレーンテキストエディタに、リッチテキストエディタと同じフォーマットオプションが追加されました。プレーンテキストエディタツールバーに「その他のオプション」メニューが追加され、以下の高度なフォーマットツールにアクセスできます：

コードブロック
詳細ブロック
水平線
Mermaid図
PlantUML図
目次

両エディタでボタン配置とセパレータが統一され、馴染みのあるフォーマットオプションへのアクセスを維持しながら、編集モード間の切り替えが簡単になりました。

ドキュメント
 イシュー

GitLab Runner 18.4

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate

GitLab Runner 18.4も本日リリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。

バグ修正：

すべての変更の一覧は、GitLab RunnerのCHANGELOGで確認できます。

ドキュメント

運用コンテナスキャンの重大度しきい値設定

GitLab.com: Ultimate
Self-Managed: Ultimate
GitLab Dedicated: Ultimate

運用コンテナスキャン（OCS: Operational Container Scanning）で、特定の重大度レベル以上の脆弱性のみを返すよう設定できるようになりました。重大度しきい値を設定すると、選択した重大度を下回る脆弱性は、脆弱性レポート、APIペイロード、その他のレポートメカニズムに表示されなくなります。これにより、修正したい脆弱性に集中できます。

このフィルタリングを有効にするには、OCS設定でseverity_thresholdを設定します。

John Walshさんによるコミュニティコントリビュートに心より感謝いたします。GitLabへのコントリビュートについて詳しく知りたい方は、コミュニティコントリビュートプログラムをご確認ください。

ドキュメント
 イシュー

シークレット検出アナライザーのGitフェッチング改善

GitLab.com: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate
GitLab Dedicated: Ultimate

シークレット検出アナライザーのバージョン7.12.0で、Gitコミットフェッチ方法に大幅な改善が追加されました。アナライザーはSECRET_DETECTION_LOG_OPTIONSから渡される--depthおよび--sinceオプションを解析し、スキャンするコミット数をより詳細に指定できるようになりました。また、コンテキストに基づいて適切なフェッチ戦略を選択し、浅い深さ設定でも数百万のコミットが不要にフェッチされる既知の問題を防止します。

この強化により、ジョブタイムアウトの削減、リソース消費の低下、より予測可能なスキャンパフォーマンスが実現されます。大規模リポジトリでのシークレット検出スキャンが高速化され、実際のフェッチ動作に合致するより明確なログが記録されます。

ドキュメント
 エピック

脆弱性詳細での自動解決パイプラインID表示

GitLab.com: Ultimate
Self-Managed: Ultimate
GitLab Dedicated: Ultimate

自動解決後に再検出された脆弱性をトラブルシューティングする際、現在のパイプラインと脆弱性が解決された時のパイプラインを比較すると効果的です。

脆弱性が自動解決された場合、脆弱性詳細ページの脆弱性ノートに、その解決が実行されたパイプラインIDが含まれるようになりました。

ドキュメント
 イシュー

GitLab Duo Self-Hostedでのサポートモデル追加

Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Enterpriseを利用するGitLab Self-Managedのお客様は、GitLab Duoでさらに多くのサポートモデルを利用できるようになりました。Azure OpenAIでOpenAI GPT-5のサポートが開始されました。また、オープンソースのOpenAI GPT OSS 20Bおよび120Bについても、vLLMとAzure OpenAIでサポートされます。これらのモデルをGitLab Duo Self-Hostedでご利用いただいた感想は、イシュー523918までお寄せください。

ドキュメント
 エピック

GitLab Duo Self-HostedでDuoコードレビューの一般提供開始

Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Self-HostedでのGitLab Duoコードレビューの一般提供が開始されました。データの管理権限を保持しながら開発プロセスを加速させます。コードレビューがマージリクエストをレビューする際、潜在的なバグを特定し、直接適用可能な改善案を提示します。人間によるレビューを依頼する前に、コードレビューを使用して変更を反復し、改善してください。この機能はMistral、Meta Llama、Anthropic Claude、OpenAI GPTの各モデルファミリーをサポートしています。

コードレビューに関するフィードバックは、イシュー517386までお寄せください。

ドキュメント
 イシュー

実験的機能

GitLab Duo AI Catalog

GitLab Duo AI Catalogは、複雑なタスクを実行するAIエージェントを発見・管理できる一元化されたハブです。マージリクエストの作成や技術的な質問への回答などに対応します。

このカタログでは次のことができます：

GitLabチームとコミュニティが作成したエージェントを閲覧する
プロジェクト用の独自のエージェントを作成する
GitLab Duo Chat（エージェント型）を通じてプロジェクト間で共有する

これは実験的機能であり、global_ai_catalogフィーチャーフラグによって制御されています：

GitLab.comの場合： グループでの利用をご希望の場合は、サポートまでお問い合わせください。
GitLab Self-Managedの場合： 管理パネルで有効にするか、RailsコンソールでFeature.enable(:global_ai_catalog)を使用してください。

本機能に関するフィードバックは、こちらのイシューまでお寄せください。

GitLab Duo Self-HostedでGitLab Duo Agent Platformが利用可能に

GitLab Duo Self-Hostedをご利用のお客様は、GitLab Duo Agent Platformを実験的機能として利用できるようになりました。GitLab Duo Workflow Serviceが既存のセルフホスト型AIゲートウェイDockerイメージに統合され、AIエージェントとワークフロー自動化をサポートします。管理者は、すべてのエージェントで使用する単一のモデルを設定できます。 GitLab Duo Agent Platformの機能の詳細については、ブログをご覧ください。

バグ修正、パフォーマンスの改善、UIの改善

GitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。

18.4で提供されたすべてのバグ修正、パフォーマンスの強化、UI改善を確認するには、以下のリンクをクリックしてください。

非推奨事項

新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、GitLabドキュメントで確認できます。今後の破壊的な変更について通知を受け取るには、破壊的な変更のRSSフィードにサブスクライブしてください。

GitLabチャートにおけるBitnami PostgreSQLおよびRedisイメージ

削除された機能と破壊的な変更

削除されたすべての機能の一覧は、GitLabドキュメントで確認できます。今後の破壊的な変更について通知を受け取るには、破壊的な変更のRSSフィードにサブスクライブしてください。

GitLabチャートにおけるBitnami PostgreSQLおよびRedisイメージ

GitLab 18.4へのアップグレードに関する重要なお知らせ

GitLab Helmチャートのデフォルト設定では、PostgreSQLとRedisにのBitnamiのチャートとコンテナイメージを使用しています。Bitnamiは2025年9月29日をもって、これらのイメージの無料提供を終了することを発表しました。2025年8月28日からイメージを断続的に利用できなくなる期間が開始されています。

GitLabチャートに含まれるBitnamiのPostgreSQLとRedisはでもおよびテスト目的のみでの使用を想定しているため、本番環境への影響はありません。一時的な解決策として、GitLabではチャート設定をBitnamiレガシーリポジトリに移行しました。ただし、パッチが適用されていないGitLabチャート環境（GitLab 17.11以前、GitLab 18.0.5、GitLab 18.1.4、GitLab 18.2.1以前）では、非推奨のBitnamiリポジトリからのイメージ取得を継続するため、9月29日以降にデプロイが失敗する可能性があります。断続的な停止期間中も同様にデプロイが失敗する可能性があります。

影響を受けるGitLabチャート設定を使用する場合は、以下のいずれかの対応を行ってください：

サポート対象のGitLabリファレンスアーキテクチャへの移行
パッチ適用済みチャートバージョンへのアップグレード
チャート値でのレガシーリポジトリ設定（例：マージリクエスト4421）

現在、代替案と今後の対応について検討中です。

変更履歴

変更内容をすべて表示するには、次のページから変更履歴を確認してください。

インストール

GitLabを新規にインストールする場合は、GitLabのダウンロードページをご覧ください。

更新事項

更新ページをご覧ください。

ご不明な点がある場合

ご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、GitLabフォーラムにアクセスして質問を投稿してください。

GitLabサブスクリプションプラン

Free ユーザー向けの永久無料機能を提供
Premium チームの生産性と調整を強化
Ultimate 組織全体のセキュリティ、コンプライアンス、プランニングに対応

GitLabのすべての機能を無料でお試しいただけます。

監修：ソリスジェレズ / Jerez Solis @jerezs （GitLab合同会社ソリューションアーキテクト本部ソリューションアーキテクト）

過去の日本語リリース情報

『2025年Gartner® Magic Quadrant™ for AI Code Assistants』でGitLabがリーダーの1社として評価されました

2025-09-17T00:00:00.000Z

『2025年Gartner® Magic Quadrant™ for AI Code Assistants』で、GitLabが再びリーダーの1社として評価されました。この評価は、私たちのAI戦略の重要な柱が認められたと認識させるものと考えています。インテリジェントなコード支援から始まり、チーム全体がソフトウェアを計画・構築・保護・デプロイする方法を変革する包括的なAIへと進化させていく戦略です。

『2025 Gartner® Magic Quadrant™ for AI Code Assistants』レポートをダウンロードする

AI機能からインテリジェントな協働へ

今回のGartnerによる評価では、GitLab Duoの生成AIコード支援機能に重点が置かれたと考えております。GitLab DuoはGitLab DevSecOpsプラットフォームへのAI搭載機能として始まりましたが、現在のGitLab DevSecOpsプラットフォームにネイティブに構築されたエージェント型AIへの発展の基盤を築きました。

GitLab Duo Agent Platformより、デベロッパーはソフトウェアライフサイクル全体にわたってタスクを自動化する複数のAIエージェントと連携できます。エージェントは相互に、そして人間と協力し、GitLabのナレッジグラフを活用してプロジェクト全体の文脈を把握して行動します。これにより、チームは可視性とコントロールを維持しながら、より迅速に作業を進められます。

専門エージェントが、コード生成、セキュリティ分析、調査などのタスクを並行して処理します。
ナレッジグラフにより、エージェントはコード、イシュー、パイプライン、コンプライアンスデータ全体にわたる統合された記録システムに接続されます。
人間とエージェントの協働は、自然言語チャットとカスタマイズ可能なワークフローにより実現され、レビューと監視が組み込まれています。
外部ツールやシステムとの相互運用性は、Model Context Protocol（MCP）とエージェント間フレームワークを通じてサポートされます。

エージェント型AIが人間の指導の下で定型的な作業を処理することで、チームはより迅速に作業を進め、より価値の高いタスクに集中し、プロジェクトの安全性とコンプライアンスを維持できます。

設計時からセキュリティを組み込み、実践では柔軟に対応

GitLab Duo Agent Platformは、セキュリティとコンプライアンスを最優先に設計されています。エージェントはGitLabの信頼されるDevSecOps環境内で動作し、すべてのアクションは変更が行われる前に可視化・レビュー可能です。セキュアな統合により認証情報と機密データが安全に処理され、オープンスタンダードを通じた相互運用性により、組織をリスクにさらさずにエージェントを外部ツールに接続できます。

このプラットフォームを使えば、ガバナンスを損なうことなくAIで生産性を高められるため、チームは安心して導入できます。その仕組みは以下の通りです：

デベロッパーは、複雑で影響力の大きい作業に集中し続けながら、定型的なタスクをエージェント型AIに委ねることで、より迅速な結果だけでなく、既存のワークフローを通じて提供される詳細な文脈を得られます。
エンジニアリングリーダーは、設定された範囲内でエージェント型AIが安全に動作する中で、ライフサイクル全体にわたって作業の進捗を可視性できます。これにより、チームは重要なタスクに注力できるようになり、エージェント型AIが提供するコンテクストに応じたワークフローのガンダンスによって、オンボーディングを簡素化できます。
IT組織は、コーディングとセキュリティポリシーを適用しながら、AIモデルを柔軟に選択し、セキュアな相互運用性を確保するガバナンス機能を活用して、エージェント型AIの活動を制御できます。重要なのは、すべてのプロセスに人間の判断が介在するということです。

AI機能の新境地を切り開く

GitLabは、Duoから始まったビジョンを継続的に発展させ、新しいエージェント型AI機能、高度なワークフロー、さらなるオーケストレーション機能でGitLab Duo Agent Platformを拡張し続けます。このイノベーションへの取り組みにより、お客様が知り、信頼するプラットフォーム上でチームの生産性を最大化できます。AI機能をDevSecOpsに統合し続ける、GitLabのロードマップの最新情報に今後もご注目ください。

『2025 Gartner® Magic Quadrant™ for AI Code Assistants』レポートをダウンロードして、GitLab Duo Agent Platformを今すぐお試しください

出典: Gartner, Magic Quadrant for AI Code Assistants, Philip Walsh, Haritha Khandabattu, Matt Brasier, Keith Holloway, Arun Batchu, 15 September 2025

この図表は、Gartner, Inc.がリサーチの一部として公開したものであり、文書全体のコンテクストにおいて評価されるべきものです。オリジナルのGartnerドキュメントは、リクエストにより GitLabからご提供することが可能です。

GitLab Duo Agent PlatformがDataOpsを変革する方法

2025-09-16T00:00:00.000Z

dbtモデルの手動作成は、データエンジニアにとって何時間も取られる単調な作業です。特に大きなビジネス変換がない場合、エンジニアのデータ業務の中でも最もやりがいを感じにくい部分と言えるでしょう。

しかし、このプロセス全体を自動化できるとしたらどうでしょうか？本ブログでは、GitLab Duo Agent Platformを使用して、適切な構造、テスト、ドキュメントを含む包括的なdbtモデルをわずか数分で生成する方法を詳しく解説します。

何を構築するのか

マーケティングチームは、広告投資を効果的に管理・最適化したいと考えています。広告プラットフォームの一つがRedditであるため、Reddit Ads APIからエンタープライズデータプラットフォームSnowflakeにデータを抽出しています。GitLabでは、3つのストレージレイヤーがあります：

rawレイヤー - 外部ソースからの未処理データの最初の着陸地点。ビジネス用途に準備されていない
prepレイヤー - ソースモデルを含む最初の変換レイヤー。まだ一般的なビジネス用途には準備されていない
prodレイヤー - ビジネス用途とTableauレポート用に準備された最終変換データ

この実践ガイドでは、データは既に抽出ツールFivetranによってrawレイヤーに配置されており、prepレイヤーからprodレイヤーまでデータを処理するdbtモデルを生成します。

一行のdbtコードを自分で書くことなく、このガイドを最後まで進めると以下が完成します：

prepレイヤーのソースモデル
prodレイヤーのワークスペースモデル
Reddit Adsデータセットのすべての13テーブル（112列を含む）の完全なdbt構成
結果を検証するテストクエリ

プロセス全体は10分以内で完了します。手動では通常数時間かかる作業です。以下の手順に従ってください：

1. データ構造の準備

GitLab Duoがモデルを生成する前に、完全なテーブル構造を理解する必要があります。そこで重要になるのが、Snowflakeの情報スキーマに対してクエリを実行することです。現在、GitLab DuoをModel Context Protocol（MCP）経由でSnowflakeインスタンスに接続する方法を検討中です：


SELECT 
    table_name,
    column_name,
    data_type,
    is_nullable,
    CASE 
        WHEN is_nullable = 'NO' THEN 'PRIMARY_KEY'
        ELSE NULL 
    END as key_type
FROM raw.information_schema.columns

WHERE table_schema = 'REDDIT_ADS'

ORDER BY table_name, ordinal_position;

このクエリは以下を取得します：

すべてのテーブル名と列名
適切なモデル構造のためのデータ型
NULL制約
主キーの識別（このデータセットでは非NULL列）

ポイント： Reddit Adsデータセットでは、すべての非NULL列が主キーとして機能するパターンになっています。実際にad_groupなどのテーブルを確認したところ、このテーブルには2つの非NULL列（account_idとid）があり、両方とも主キーとしてマークされています。このクエリを実行すると112行のメタデータが返されたため、それらをCSVファイルとしてエクスポートしてモデル生成に使用しました。この手動ステップは現在は問題なく機能していますが、MCPを介してデータプラットフォームとGitLab Duoの直接統合を調査して、このプロセスの完全自動化を目指して取り組んでいます。

2. GitLab Duoのセットアップ

GitLab Duoと対話する方法は2つあります：

Web UIチャット機能
Visual Studio Codeプラグイン

dbtモデルをローカルで実行してテストできるため、VS Codeプラグインを選択しました。

3. 「効果的な」プロンプトの入力

すべてのdbtコードを生成するために使用した実際のプロンプトは以下の通りです：


Create dbt models for all the tables in the file structure.csv.（structure.csvファイル内のすべてのテーブルに対してdbtモデルを作成してください）


I want to have the source models created, with a filter that dedupes the data based on the primary key. Create these in a new folder reddit_ads.（主キーに基づいてデータの重複を除去するフィルターを使用してソースモデルを作成したいです。これらを新しいフォルダーreddit_adsに作成してください。）

I want to have workspace models created and store these in the workspace_marketing schema.（ワークスペースモデルを作成し、これらをworkspace_marketingスキーマに保存してください。）


Take this MR as example: [I've referenced to previous source implementation]. Here is the same done for Source A, but now it needs to be done for Reddit Ads. 

（このMRを例として参考にしてください： [以前のソース実装を参照]。これはSource Aで実施した内容ですが、同様の処理をReddit Adsに対して行う必要があります。）


Please check the dbt style guide when creating the code: https://handbook.gitlab.com/handbook/enterprise-data/platform/dbt-guide/（コードを作成する際は、dbtスタイルガイドをチェックしてください）

このプロンプトが効果的だった理由：

ソースモデルとワークスペースモデル両方の明確な仕様
以前の類似マージリクエストからの参考例
コードの品質と一貫性を確保するためのスタイルガイド参照
適切な構成管理のための特定のスキーマ指定

4. GitLab Duoのプロセス

プロンプトを送信した後、GitLab Duoが作業を開始しました。生成プロセス全体は数分かかり、その間にGitLab Duoは以下を行いました：

CSV入力ファイルを読み取り分析
メタデータからテーブル構造を調査
コーディング標準についてdbtスタイルガイドを参照
適切な構造化のために類似のマージリクエストを考慮
すべての13テーブルのソースモデルを生成
すべての13テーブルのワークスペースモデルを作成
dbtサポートファイルを生成：
- sources.yml構成
- テストとドキュメントを含むschema.ymlファイル
- スキーマ参照でdbt_project.ymlを更新

結果

出力は素晴らしいものでした：

変更ファイル1個： dbt_project.yml（reddit_adsスキーマ構成を追加）
新しいファイル29個：
- dbtモデル26個（ソース13個 + ワークスペース13個）
- YAMLファイル3個
900行近くのコードが自動生成
主キー列の一意制約を含む組み込みデータテスト
すべてのモデルと列の汎用説明
ソースモデルの適切な重複除去ロジック
GitLab dbtスタイルガイドに従ったクリーンで一貫したコード構造


transform/snowflake-dbt/

├── dbt_project.yml                                                    [MODIFIED]（変更）

└── models/
    ├── sources/
    │   └── reddit_ads/
    │       ├── reddit_ads_ad_group_source.sql                        [NEW]（新規）
    │       ├── reddit_ads_ad_source.sql                              [NEW]
    │       ├── reddit_ads_business_account_source.sql                [NEW]
    │       ├── reddit_ads_campaign_source.sql                        [NEW]
    │       ├── reddit_ads_custom_audience_history_source.sql         [NEW]
    │       ├── reddit_ads_geolocation_source.sql                     [NEW]
    │       ├── reddit_ads_interest_source.sql                        [NEW]
    │       ├── reddit_ads_targeting_community_source.sql             [NEW]
    │       ├── reddit_ads_targeting_custom_audience_source.sql       [NEW]
    │       ├── reddit_ads_targeting_device_source.sql                [NEW]
    │       ├── reddit_ads_targeting_geolocation_source.sql           [NEW]
    │       ├── reddit_ads_targeting_interest_source.sql              [NEW]
    │       ├── reddit_ads_time_zone_source.sql                       [NEW]
    │       ├── schema.yml                                            [NEW]
    │       └── sources.yml                                           [NEW]
    └── workspaces/
        └── workspace_marketing/
            └── reddit_ads/
                ├── schema.yml                                        [NEW]
                ├── wk_reddit_ads_ad.sql                              [NEW]
                ├── wk_reddit_ads_ad_group.sql                        [NEW]
                ├── wk_reddit_ads_business_account.sql                [NEW]
                ├── wk_reddit_ads_campaign.sql                        [NEW]
                ├── wk_reddit_ads_custom_audience_history.sql         [NEW]
                ├── wk_reddit_ads_geolocation.sql                     [NEW]
                ├── wk_reddit_ads_interest.sql                        [NEW]
                ├── wk_reddit_ads_targeting_community.sql             [NEW]
                ├── wk_reddit_ads_targeting_custom_audience.sql       [NEW]
                ├── wk_reddit_ads_targeting_device.sql                [NEW]
                ├── wk_reddit_ads_targeting_geolocation.sql           [NEW]
                ├── wk_reddit_ads_targeting_interest.sql              [NEW]
                └── wk_reddit_ads_time_zone.sql                       [NEW]

生成されたコードのサンプル

生成されたコード品質の例をご紹介します。time_zoneテーブルについて、GitLab Duoは以下を作成しました：

Prepレイヤーソースモデル


WITH source AS (
  SELECT *
  FROM {{ source('reddit_ads','time_zone') }}
  QUALIFY ROW_NUMBER() OVER (PARTITION BY id ORDER BY _fivetran_synced DESC) = 1
),


renamed AS (
  SELECT
    id::VARCHAR                               AS time_zone_id,
    code::VARCHAR                             AS time_zone_code,
    dst_offset::NUMBER                        AS time_zone_dst_offset,
    is_dst_active::BOOLEAN                    AS is_time_zone_dst_active,
    name::VARCHAR                             AS time_zone_name,
    offset::NUMBER                            AS time_zone_offset,
    _fivetran_synced::TIMESTAMP               AS fivetran_synced_at
  FROM source
)


SELECT * FROM renamed

Schema.yml


models:
  - name: reddit_ads_time_zone_source
    description: Time zone data from Reddit Ads system（Reddit Adsシステムからのタイムゾーンデータ）
    columns:
      - name: time_zone_id
        description: Time zone data from Reddit Ads system（タイムゾーンレコードの一意識別子）
        data_tests:
          - unique
          - not_null
      - name: time_zone_code
        description: Code for the time zone（タイムゾーンのコード）
      - name: time_zone_dst_offset
        description: Daylight saving time offset for the time zone（タイムゾーンの夏時間オフセット）
      - name: is_time_zone_dst_active
        description: Flag indicating if daylight saving time is active（夏時間がアクティブかどうかを示すフラグ）
      - name: time_zone_name
        description: Name of the time zone（タイムゾーンの名前）
      - name: time_zone_offset
        description: Offset for the time zone（タイムゾーンのオフセット）
      - name: fivetran_synced_at
        description: Timestamp when the record was last synced by Fivetran（レコードがFivetranによって最後に同期されたタイムスタンプ）

Source.yml


sources:
  - name: reddit_ads
    database: RAW
    schema: reddit_ads
    loaded_at_field: _fivetran_synced
    loader: fivetran
    description: Reddit Ads data

    quoting:
      database: true
      schema: false
      identifier: false

    tables:
      - name: time_zone

ワークスペースモデル


WITH source AS (
  SELECT *
  FROM {{ ref('reddit_ads_time_zone_source') }}
)


SELECT * FROM source

5. 品質検証

コードに問題がないことを確認し、MRにプッシュしてCIテストパイプラインを実行し、コードのテストと結果検証を行いました。GitLab Duoに検証クエリの作成を依頼しました：


Create a test query to test the row counts between the raw layer and the workspace layer. Keep in mind that we do deduplication, so we can compare both using distinct on the primary keys.（rawレイヤーとworkspaceレイヤー間の行数をテストするクエリを作成してください。重複除去を実施しているため、主キーに対してdistinctを使用して比較できます。）

AIが生成した包括的な検証クエリには、以下が含まれています：

rawレイヤーとワークスペースレイヤー間の行数を比較
重複除去ロジックに対応
全13テーブルをテスト
データ保持率を算出

生成されたSQLテストクエリ


-- Reddit Ads Row Count Validation Test（Reddit Ads行数検証テスト）

-- Compares distinct counts between RAW layer and WORKSPACE_MARKETING layer（RAWレイヤーとWORKSPACE_MARKETINGレイヤー間の一意カウントを比較）

-- Accounts for deduplication logic in source models（ソースモデルの重複除去ロジックを考慮）


WITH raw_counts AS (
  -- Single primary key tables（単一主キーテーブル）
  SELECT 'ad' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.AD
  
  UNION ALL
  
  SELECT 'business_account' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.BUSINESS_ACCOUNT
  
  UNION ALL
  
  SELECT 'campaign' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.CAMPAIGN
  
  UNION ALL
  
  SELECT 'custom_audience_history' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.CUSTOM_AUDIENCE_HISTORY
  
  UNION ALL
  
  SELECT 'geolocation' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.GEOLOCATION
  
  UNION ALL
  
  SELECT 'interest' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.INTEREST
  
  UNION ALL
  
  SELECT 'time_zone' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.TIME_ZONE
  
  -- Composite primary key tables（複合主キーテーブル）
  UNION ALL
  
  SELECT 'ad_group' AS table_name, COUNT(DISTINCT CONCAT(account_id, '|', id)) AS raw_count
  FROM RAW.REDDIT_ADS.AD_GROUP
  
  UNION ALL
  
  SELECT 'targeting_community' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', community_id)) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_COMMUNITY
  
  UNION ALL
  
  SELECT 'targeting_custom_audience' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', custom_audience_id)) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_CUSTOM_AUDIENCE
  
  UNION ALL
  
  SELECT 'targeting_device' AS table_name, COUNT(DISTINCT _fivetran_id) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_DEVICE
  
  UNION ALL
  
  SELECT 'targeting_geolocation' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', geolocation_id)) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_GEOLOCATION
  
  UNION ALL
  
  SELECT 'targeting_interest' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', interest_id)) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_INTEREST
),


workspace_counts AS (
  -- Workspace layer counts using primary keys from schema.yml（schema.ymlの主キーを使用したワークスペースレイヤーカウント）
  SELECT 'ad' AS table_name, COUNT(DISTINCT ad_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_AD
  
  UNION ALL
  
  SELECT 'business_account' AS table_name, COUNT(DISTINCT business_account_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_BUSINESS_ACCOUNT
  
  UNION ALL
  
  SELECT 'campaign' AS table_name, COUNT(DISTINCT campaign_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_CAMPAIGN
  
  UNION ALL
  
  SELECT 'custom_audience_history' AS table_name, COUNT(DISTINCT custom_audience_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_CUSTOM_AUDIENCE_HISTORY
  
  UNION ALL
  
  SELECT 'geolocation' AS table_name, COUNT(DISTINCT geolocation_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_GEOLOCATION
  
  UNION ALL
  
  SELECT 'interest' AS table_name, COUNT(DISTINCT interest_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_INTEREST
  
  UNION ALL
  
  SELECT 'time_zone' AS table_name, COUNT(DISTINCT time_zone_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TIME_ZONE
  
  -- Composite primary key tables（複合主キーテーブル）
  UNION ALL
  
  SELECT 'ad_group' AS table_name, COUNT(DISTINCT CONCAT(ad_group_account_id, '|', ad_group_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_AD_GROUP
  
  UNION ALL
  
  SELECT 'targeting_community' AS table_name, COUNT(DISTINCT CONCAT(targeting_community_ad_group_id, '|', targeting_community_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_COMMUNITY
  
  UNION ALL
  
  SELECT 'targeting_custom_audience' AS table_name, COUNT(DISTINCT CONCAT(targeting_custom_audience_ad_group_id, '|', targeting_custom_audience_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_CUSTOM_AUDIENCE
  
  UNION ALL
  
  SELECT 'targeting_device' AS table_name, COUNT(DISTINCT targeting_device_fivetran_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_DEVICE
  
  UNION ALL
  
  SELECT 'targeting_geolocation' AS table_name, COUNT(DISTINCT CONCAT(targeting_geolocation_ad_group_id, '|', targeting_geolocation_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_GEOLOCATION
  
  UNION ALL
  
  SELECT 'targeting_interest' AS table_name, COUNT(DISTINCT CONCAT(targeting_interest_ad_group_id, '|', targeting_interest_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_INTEREST
)


-- Final comparison with validation results（検証結果との最終比較）

SELECT 
  r.table_name,
  r.raw_count,
  w.workspace_count,
  r.raw_count - w.workspace_count AS count_difference,
  CASE 
    WHEN r.raw_count = w.workspace_count THEN '✅ PASS（成功）'
    WHEN r.raw_count > w.workspace_count THEN '⚠️ RAW > WORKSPACE (Expected due to deduplication 重複除去のため正常)'
    ELSE '❌ FAIL（失敗） - WORKSPACE > RAW (Unexpected 異常)'
  END AS validation_status,
  ROUND((w.workspace_count::FLOAT / r.raw_count::FLOAT) * 100, 2) AS data_retention_percentage
FROM raw_counts r

JOIN workspace_counts w ON r.table_name = w.table_name

ORDER BY r.table_name;

このクエリを実行した結果：

重複除去後の行数に差異なし
全テーブルで100%のデータ保持
すべてのテストが正常に完了

結論：大幅な時間短縮

従来のアプローチ： 手動コーディング、テスト、デバッグで6-8時間
GitLab Duoを活用： 生成 + レビュー時間で6-8分

開発効率が60倍に向上（6-8時間から6-8分へ）し、高品質なコードを確保できます。

成功のためのベストプラクティス

本事例から得られた主要な推奨事項：

メタデータの準備

データ型や制約を含む完全なテーブル構造を抽出する
主キーと関係を事前に特定する
クリーンで適切にフォーマットされたCSV入力ファイルをエクスポートする

注： GitLab DuoをMCP経由で（メタ）データに接続することで、この手動ステップを省略できる可能性があります。

明確なコンテキストの提供

可能な限り既存のMR例を参照例として示す
コーディング標準とスタイルガイドを明示する
フォルダー構造と命名規則について明確に指定する

徹底的な検証

データ整合性を確認する検証クエリを必ず作成する
マージ前にローカルでテストする
CI/CDパイプラインを実行して問題を検出する

AIを活用したフォローアップ作業

テストクエリを自動生成する
ドキュメントテンプレートを作成する
検証スクリプトを構築する

今後の展開

本ガイドでは、GitLab DuoをはじめとするAI搭載開発ツールがデータエンジニアリングワークフローをいかに変革しているかを示しました。テスト、ドキュメント、適切な構造を含む数百行の本番対応コードを数分で生成できる能力は、反復的な開発タスクへのアプローチの根本的な転換を表しています。

AIにdbtモデル作成の反復作業を委ねることで、データエンジニアはデータモデリング戦略、パフォーマンス最適化、ビジネスロジック実装などといった、より価値の高い業務に専念できます。

ぜひお試しください 小さなデータセットから着手し、メタデータを慎重に準備することで、GitLab Duoが何時間の作業をわずか数分の自動生成に変える様子を実感できます。

GitLab Duo Agent Platformを今すぐお試しください。

さらに読む

ガントチャートとは？ソフトウェア開発における役割やメリット、作り方

2025-09-16T00:00:00.000Z

ソフトウェア開発におけるプロジェクト管理を円滑に行うには「ガントチャート」の活用が役立ちます。実際に自社の開発プロジェクトにおいて複雑で多岐にわたるプロセス管理に課題を感じており、ガントチャートの活用を検討している人もいるのではないでしょうか。この記事では、ガントチャートの役割や活用のメリット、具体的な作成方法などを解説します。ガントチャートの作成やプロジェクト管理におすすめのツールも紹介しているのでぜひ参考にして下さい。

1. ガントチャートとは？意味やその役割

まずはガントチャートの意味や役割など基礎知識について解説します。

1-1. ガントチャートの定義・意味

ガントチャート（Gantt Chart）とは、プロジェクトのスケジュール管理やタスク管理のために活用されるツールです。縦軸に各タスクと作業の開始日・終了日を示し、横軸に進捗を示す時間軸を配置することでプロジェクトの進捗状況やタスク間の依存関係、担当者を一目で把握できます。ガントチャートはIT業界だけでなく、建設業などさまざまな業種・業界のプロジェクト管理に活用されています。

1-2. ソフトウェア開発におけるガントチャートの役割

ソフトウェア開発では、要件定義からプログラミング、テスト、リリース、保守運用まで多岐にわたる工程を踏む必要があり、複数の人材や関係者がプロジェクトに参加します。その中でメンバーや関係者間の認識のズレを防止しつつ、プロジェクトを円滑に進めるにはガントチャートによる徹底したスケジュール管理とタスク管理が重要です。ガントチャートはソフトウェア開発において、メンバー間のコミュニケーションの向上や適切な進捗管理の実現、リカバリー策の設計などの役割を担います。

2. ガントチャートの歴史・誕生背景

ガントチャートは、1896年にポーランドの経済学者であるKarol Adamiecki（カロル・アダミエツキ）氏によって最初に作成されたと言われています。その後、1910年代にHenry Gantt（ヘンリー・ガント）氏が独自のバージョンとしてガントチャートを考案しました。Henry Gantt氏は、工場で働く労働者が与えられたタスクを完了させるのにどのくらいの期間を要したかを現場の責任者が確認できるよう独自にガントチャートを考案したのです。さらに、Henry Gantt氏の死後、Wallace Clark（ウォーレス・クラーク）氏が、自身の著書でガントチャートの使い方やそのメリットを解説し、世界中に普及しました。

3. ガントチャートの一般的な構成要素

ガントチャートを作成・活用する際には、構成要素について理解しておく必要があります。

構成要素	詳細
タスク	プロジェクトにおける各作業
タスクの期間	各作業の実施期間（開始日と終了日）
タスクの担当者	各タスクの担当者の名前
タスクの依存関係	タスク同士がどのような影響を与えるか
タイムスケール	チャートの上部に示す時間軸（日・週など）
マイルストーン	プロジェクトの重要な中間目標や節目
進捗率	タスクの完了率（%で表示）
一般的には上記のような要素で構成されますが、自社のプロジェクトの規模や内容によっても記載する要素は異なります。

4. ガントチャートとWBS・バーチャート工程表との違い

ガントチャートと混同されやすい用語として「WBS」と「バーチャート工程表」があります。それぞれの違いについて詳しく解説します。

4-1. ガントチャートとWBSとの違い

WBSとは、「Work Breakdown Structure」の略語でプロジェクト全体の作業を段階的に細分化したリストのことです。「プロジェクトを達成するためには何をすべきか？」という点にフォーカスし、必要なタスクを整理するのが目的です。一方、ガントチャートは時間軸を活用してWBSで整理されたタスクの進捗状況の把握や全体のスケジュール管理を行うための表を指します。つまり、ガントチャートを作成する際にはWBSによるタスクの細分化が不可欠であり、両者は密接な関係にあります。

4-2. ガントチャートとバーチャート工程表との違い

バーチャート工程表とは、縦軸に作業項目、横軸に時間を示して、横棒（バー）を使って作業の実施時間を可視化した図表を指し、主に建設現場や製造業で使われています。バーチャート工程表は、各タスクに要する実施期間を明確にすることを目的としていますが、ガントチャートのようにタスク間の依存関係を管理するのには向いていないツールです。ソフトウェア開発においては各タスクの依存関係や進捗状況の把握が重要になってくるため、バーチャート工程表ではなくガントチャートの活用を検討することが大切です。

5. ガントチャートを活用するメリット

ガントチャートを活用することでどのようなメリットがあるのでしょうか。具体的には以下が挙げられます。

プロジェクトの全体像を把握できる
専門知識がなくても扱える
関係者間の認識のズレを防止できる
マイルストーンを管理・最適化が可能になる
タスクの依存関係を確認できる
プロジェクトにおけるリカバリー策を取りやすい

5-1. プロジェクトの全体像を把握できる

ガントチャートを活用すれば、関係者全員がプロジェクト全体の計画を直感的に把握できます。マネージャーや責任者だけでなく、メンバー1人ひとりがプロジェクト計画や進捗状況を確認できるため、個々が担当するタスクに対して責任を持って作業に取り組むことが可能です。例えば、「自分が担当しているタスクが完了しなければ、次のタスクに移れない」とタスク同士の依存関係を事前に把握していれば、計画を意識しながら作業を進められるでしょう。プロジェクトマネージャーも、ガントチャートを見ながらプロジェクトが計画的に進んでいるか常に状況をチェックできるため、メンバーへの指示も出しやすくなるでしょう。

5-2. 専門知識がなくても扱える

ガントチャートは図表の構成そのものがシンプルであり、難解な用語も使用しないためメンバーや関係者に専門知識がなくても直感的に理解できます。プロジェクトマネージャーがガントチャートを作成する際にも専門知識は不要であり、専用ツールを活用すれば時間と手間をかけることなくスムーズな作成・修正が可能です。誰もが見やすくわかりやすいガントチャートを作成すれば、開発メンバーも戸惑うことなく作業に集中できるようになるでしょう。

5-3. 関係者間の認識のズレを防止できる

ガントチャートで全体のプロジェクト計画をメンバーや関係者間で共有すれば、認識のズレなく全員が同じ方向を向いて開発を進められます。例えば、開発側と顧客側で認識のズレがあると、本来必要のない機能の開発のために工数を割いてしまうということにもなりかねません。ガントチャートなら、必要なタスクを細分化してスケジュールとして可視化できるようになっているため、関係者全員が事前に擦り合わせした上で計画を実行することが可能です。また、開発途中でなんらかの課題や変更が発生した場合でも随時状況を共有し、スケジュールを修正すれば問題なくプロジェクトを進められるでしょう。

5-4. マイルストーンの管理・最適化が可能になる

マイルストーンとは、プロジェクトにおける重要な中間目標地点を指す言葉です。全体のスケジュールを可視化できるガントチャートなら、プロジェクト計画において重要な要素となるマイルストーンの管理も行うことができます。例えば、ガントチャート上にマイルストーンを設置すれば、「この期間までにはこのタスクを完了している必要がある」と視覚的に把握できるため、メンバー間での認識の強化やプロジェクトの遅延防止につなげられるでしょう。

5-5. タスクの依存関係を確認できる

ソフトウェア開発を進めるに当たり、タスクによっては前のタスクが完了していないと着手できないといった依存関係が発生するケースも少なくありません。ガントチャートを作成する際に各タスクにおける依存関係をマッピングすれば、容易にタスク同士の関係性を把握でき、ボトルネックの可能性を事前に認識することが可能です。例えば、タスクの依存関係が集中するフェーズでは、他の担当者がフォローできる体制を整えておくなどの対策を検討できるでしょう。なお、ガントチャートで各タスクの依存関係を示す際には必要な機能が搭載されたツールを活用すると効率的です。

5-6. プロジェクトにおけるリカバリー策を取りやすい

ソフトウェア開発においては必ず計画通りプロジェクトが進むというわけではなく、途中トラブルなどが発生するケースも多いです。ガントチャートで全体のスケジュールやタスクを可視化しておけば、急なトラブルや仕様変更などが発生した場合でも、どのフェーズまで戻り、どのような作業が必要になるのか検討しやすくなります。このように迅速なリカバリー策を講じることで、顧客の要望に沿った開発を実現できるでしょう。なお、計画に変更が生じた場合はガントチャートの修正も忘れずに行うことが大切です。

6. ガントチャートの注意点

ガントチャートは、プロジェクト全体のスケジュールや各タスクの実施期間、進捗状況などを視覚的に確認できますが、作業工数における細かな情報については表示しないのが特徴です。例えば、「タスクAの実施期間は10日間」と表示されている場合でも、タスクAを完了させるために必要な細かな工数が見えないため、想定以上のコストがかかる場合があります。このような事態を避けてプロジェクトを円滑に進めるためには、ガントチャートの活用と併せて工数管理表などのツールを導入し、別途で工数を管理する方法を検討することが大切です。

7. ガントチャートの作り方

ここではガントチャートの作り方について解説していきます。

7-1. WBSを作成する

ガントチャートを作成する際には、まずWBSを作成してプロジェクトに必要なタスクを洗い出していきます。 WBSでタスクを細分化することによって、作業内容が明確になり全体のスケジュール管理がしやすくなります。WBS作成の土台となるのはプロジェクトの目標設定です。開発における最終成果物や成功の定義が明確であるほど、ゴールまでのプロセスを丁寧に考えることができます。必要なタスクの洗い出しにおいては、まずは大きなフェーズから書き出し、そこからさらに細分化していくというステップを踏むのがポイントです。そうすることで次で紹介するタスクの依存関係の整理がスムーズになります。

7-2.タスク間の依存関係を整理する

プロジェクト達成に必要なタスクを洗い出した後は、各タスクの依存関係を整理します。「タスクAの作業が完了しなければ、タスクBに進めない」という依存関係がある場合は、視覚化して整理しておくことが大切です。例えば、開発において設計が完了しないと次のプログラミングに着手できないというケースは依存関係に該当するため、関係性をきちんと整理しておきます。

7-3.各タスクのスケジュールを設定する

次に各タスクに費やす作業期間を検討し、開始日と終了日を設定します。タスクの作業期間はプロジェクトの規模やタスクの内容に応じて、日数や週数の単位で検討します。その際、タイトなスケジュールを組んでしまうとメンバーの負担増加や、プロダクトの品質低下を招く原因にもなるため、余裕を持たせた上で各タスクの作業期間を設定することが大切です。また、タスク間で依存関係が発生するフェーズにおいては遅延の可能性も考慮しなければなりません。併せてマイルストーンの設定も行っておきます。プロジェクトの中間目標を認識した上でスケジュールを検討することで、各タスクにおいて適切な作業期間を設定できるでしょう。

7-4.各タスクの担当者を割り当てする

各タスクのスケジュール設定が完了した後は、担当者を割り振っていきます。担当者の選定においては、個人のスキルや経験などを考慮しながら行います。各タスクの割り振りを誤ってしまうと、プロジェクトの遅延やトラブルを招くため、プロジェクトマネージャーはメンバーの能力をよく理解した上で検討しなければなりません。各タスクの担当者が決定したらガントチャート上に担当者の名前を記載しておきます。そうすることで誰がどのタスクを担当するのかをメンバー全員が把握できるため、個々が自身のタスクにおいて責任感を持てるようになります。

7-5.関係者への共有と更新

ガントチャートの作成が完了すれば、メンバーや顧客など関係者全員に共有します。その中で関係者からタスクの洗い出しや作業期間において指摘やフィードバックがあった場合は、修正を実施します。関係者全員で共通の認識がなく、懸念点を抱えたままプロジェクトがスタートしてしまうとスムーズに作業が進まないため、時間をかけて細かな擦り合わせをしておきましょう。また、プロジェクト開始後にも定期的なミーティングを実施し、進捗状況や認識のズレがないかを確認します。繰り返しにはなりますが、仕様変更やトラブルの発生などによって計画が変更された場合は、ガントチャートの修正も忘れずに行うことが大切です。

8. ガントチャートを作成する際のポイント

ガントチャートを作成する際には以下のポイントを意識することが大切です。

視認性の高さを意識する
更新されることを前提に作成する

8-1. 視認性の高さを意識する

ガントチャートはプロジェクトの関係者全員に共有するツールであるため、誰もが見やすい形で作成することが大切です。例えば、以下のような工夫が考えられます。

タスクの作業期間を示す横棒（バー）は、タスクのカテゴリ別に色分けする
タスクの依存関係によりボトルネックが発生しそうなフェーズにはマークをつけておく
マイルストーンにはわかりやすいアイコンを配置しておくなど視認性の高いガントチャートを作成するには、直感的なUIやレイアウト機能を備えた専用ツールを活用するのがおすすめです。

8-2. 更新されることを前提に作成する

ガントチャートは事前に立てた計画通りに進行されるのが理想ですが、実際にはプロジェクトが開始されると仕様変更やトラブルが発生するケースも少なくありません。そのため、ガントチャートは「計画通りに進行させる」という前提ではなく、「更新されること」を前提として作成し柔軟性を持たせておく必要があります。例えば、バッファを含めて各タスクの作業期間を設定する、遅延が想定されるタスクにおいては別の担当者がフォローできるよう割り振りを工夫するなどの方法が挙げられます。プロジェクトの変更が発生した際に、同時に計画の変更もスムーズに行える体制を整えておくことで問題なく目標達成できるでしょう。

9. ガントチャートと各開発手法との相性・使い方

ソフトウェア開発においては、近年開発手法も変化してきているためガントチャートと各開発手法との相性も把握しておくことも大切です。ソフトウェア開発の手法においてはこれまで「ウォーターフォール開発」が主流でした。ウォーターフォール開発は開発前に全ての機能計画を立ててから計画通りに作業を進める手法であるため、プロジェクト全体のスケジュール管理やタスク管理ができるガントチャートとの相性は良いと言えるでしょう。なお、近年変化が激化しているビジネス環境において、迅速に顧客や市場ニーズに対応するために「アジャイル開発」にも注目が集まっています。アジャイル開発はウォーターフォール開発のように全体のスケジュールを立ててから開発を進めるのではなく、機能単位ごとに実装とテストを繰り返し開発を進めていきます。そのため、アジャイル開発においてはガントチャートによるスケジュール管理は不向きだと捉えてしまうかもしれません。しかし、ガントチャートが持つ計画性はアジャイル開発にも工夫次第で組み合わせることも可能です。例えば、スプリントプラニングにガントチャートを取り入れれば、視覚的に各タスクの作業期間や依存関係を表現できます。

10. ガントチャートを作成できるツール・サービス

ガントチャートを作成できるツール・サービスは以下の通りです。

エクセル・スプレッドシート
プロジェクト管理ツール

10-1. エクセル・スプレッドシート

ガントチャートは、エクセルやGoogleスプレッドシートを活用して自作で作成することが可能です。エクセルなら一般的にビジネスシーンで利用されることが多いツールであるため、操作に慣れている人であれば使いやすいでしょう。Googleスプレッドシートも、Googleアカウントを持っていれば手軽に利用できるツールです。ただし、エクセルやGoogleスプレッドシートを活用してガントチャートを作成する場合は、さまざまな課題が発生するため後に詳しく解説します。

10-2. プロジェクト管理ツール

ガントチャートを作成する方法としてプロジェクト管理ツールを活用する方法もあります。プロジェクト管理ツールは、複数のタスクやプロジェクトを管理でき、ガントチャートの作成も可能です。プロジェクト管理ツールなら、マイルストーン機能や依存関係の設定などさまざまな機能が搭載されており、ガントチャート作成における面倒な設定やレイアウト作成も不要です。ツール導入に当たりコストは発生しますが、プロジェクト管理における包括的なサポートを受けられるというメリットを考えると、高い費用対効果が期待できると言えるでしょう。

11. エクセルなど自作でガントチャートを作成することの課題

ここでは、先ほど紹介したエクセルやGoogleスプレッドシートを活用して自作で作成することの課題について解説します。

作成や更新に時間がかかる
視認性が低い
スケジュール共有に時間がかかる

11-1. 作成や更新に時間がかかる

エクセルやGoogleスプレッドシートでガントチャートを自作する場合、作成や更新に時間がかかってしまいます。作成においてはテンプレートを利用する方法もありますが、自社のプロジェクトに沿ってカスタマイズしたい場合は操作に慣れている必要があり、ある程度関数や条件付き書式などの知識も求められます。また、スケジュールの変更が発生する度に手作業で更新しなければならないため時間と手間がかかり、誤操作や更新漏れも発生しやすいと言えるでしょう。特に、プロジェクトの規模が大きいほど更新や修正における負担が増し、重要な業務に注力できなくなる恐れがあります。

11-2. 視認性が低い

エクセルやGoogleスプレッドシートでガントチャートのレイアウト作成や調整を行う場合、視認性が低くなってしまう恐れがあります。例えば、見た目を調整しようと必要のない項目を増やしたり、無駄な色使いなどを行うとガントチャートの情報量が多くなりかえって見づらくなってしまうでしょう。ガントチャートは一目で全体の計画や進捗状況が把握できるかというポイントが重要になってくるため、慣れていないとエクセルやGoogleスプレッドシートで表現するのが難しい可能性があります。特に大規模なプロジェクトの場合は自作で視認性の高いガントチャートを作成するのに適していないと言えるでしょう。

11-3. スケジュール共有に時間がかかる

エクセルやGoogleスプレッドシートの場合、リアルタイムでの情報共有が難しくなります。特にエクセルの場合、更新の度にクラウドサービスなど別の媒体を使って共有する必要があり手間がかかります。また、その際誤操作によってファイルが破損してしまう可能性もあるでしょう。このような形で情報共有がスピーディーかつ、正確に行われないと関係者間で認識のズレが生じてしまい、プロジェクトが円滑に進まなくなる恐れがあります。情報共有の正確性や迅速化を目指すなら専用のプロジェクト管理ツールの導入を検討するのが良いでしょう。

12. ガントチャートの作成・プロジェクト管理なら「GitLab」

ガントチャートの作成やプロジェクト管理を効率化するなら「GitLab」の導入がおすすめです。ここでは、GitLabの概要やプロジェクト管理機能の特徴について紹介します。

12-1. GitLabとは

GitLabは、AIを搭載したDevSecOpsプラットフォームです。AIによるソースコード管理やCI/CDによる開発プロセスの自動化、プロジェクト管理、セキュリティ強化など企業のソフトウェア開発を支援するさまざまな機能を提供しています。 DevSecOpsとは、ソフトウェア開発における開発・セキュリティ・運用を掛け合わせたアプローチを指し、開発サイクル全体を効率化できるGitLabなら単一のプラットフォームでDevSecOpsを実現できます。GitLabは中小企業からエンタープライズまで世界中の多くの企業で導入されているプラットフォームです。

12-2. GitLabのプロジェクト管理機能の特徴

GitLabのプロジェクト管理にはさまざまな機能が搭載されています。例えば、「ロードマップ」ならエピック（プロジェクトの大枠や目標）とマイルストーンをタイムライン形式（ガントチャート風）で視覚的に表示することが可能です。また、イシュー（タスク）の間に依存関係を設定することもできるため、事前に潜在的な障害を回避できます。その他にもアジャイル開発のプランニングに役立つ「イテレーション」や作業時間を測定できる「タイムトラッキング」などの機能があり、GitLabを導入することで自社のプロジェクト管理を円滑に進められます。

13. ガントチャートを作成してプロジェクトを円滑に進めよう

ガントチャートを自社のソフトウェア開発に積極的に取り入れることで、全体のスケジュール管理やタスク管理がスムーズになり、プロジェクトの成功率を高められるでしょう。ガントチャートの作成はエクセルなどを利用して自作することも可能ですが、時間と手間がかかるためプロジェクト管理ツールを導入するのがおすすめです。 GitLabなら、ソフトウェア開発におけるプロジェクト管理を効率化できる豊富な機能を揃えています。ガントチャートを作成して自社のプロジェクト管理を円滑に行いたいと考えている人は、ぜひ導入をご検討下さい。なお、GitLabでは世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧ください。

2024グローバルDevSecOpsレポートはこちら

GitLabとAccentureがグローバル販売代理店契約を発表

2025-09-15T00:00:00.000Z

この度、GitLabとAccentureがグローバル販売代理店契約を締結し、AccentureがGitLabの認定販売代理店およびプロフェッショナルサービスプロバイダーとして認定されたことを発表いたします。この契約により、AccentureはAWSマーケットプレースを含む複数の販売チャネルを通じて、GitLabの完全なDevSecOpsプラットフォームをお客様に直接提供することが可能になります。

重要な節目

今回の協業は、GitLabの包括的かつインテリジェントなDevSecOpsプラットフォームと、Accentureのデジタルトランスフォーメーションおよび実装サービスにおける豊富な専門知識を組み合わせることで、組織が大規模にセキュアなソフトウェアの構築とデリバリーを実現できるようにします。このグローバル販売代理店契約は、各地域の状況に合わせて容易に適応できるグローバルフレームワークを提供します。

今回の協業では、まず以下の主要領域に注力します。

エンタープライズ規模のDevSecOps変革： 組織の開発プラクティスのモダナイゼーションとソフトウェアデリバリーライフサイクルの効率化を支援
メインフレームモダナイゼーション： レガシーシステムからの移行をサポート
GitLab Duo with Amazon Q： エンドツーエンドのセキュリティとコンプライアンスを維持しながらベロシティの向上を求める組織に、AI主導のソフトウェア開発を提供

今後の展望

私たちは、両社のお客様がイノベーションを加速し、開発プロセスを効率化し、セキュリティ体制を強化することで、より効果的にビジネス目標を達成できるよう支援していくことを期待しています。

GitLabとAccentureがお客様のビジネスをどのようにご支援できるか、詳しくはパートナーサイトをご覧いただくか、AccentureまたはGitLabの営業担当にお問い合わせください。

ローカルLLMとは？開発での活用メリットと注意点

2025-09-12T00:00:00.000Z

近年ソフトウェア開発の領域では、開発プロセスの効率化や生産性向上などを目的としてAIの活用が重要視されています。その中で企業のセキュリティ要件に対応しやすい「ローカルLLM」にも注目が集まっています。

実際にソフトウェア開発におけるAI活用において、ローカルLLMの導入を検討している人も多いのではないでしょうか。

この記事では、ローカルLLMの意味やクラウドLLMとの違い、ソフトウェア開発における導入メリットなどを解説します。

1 そもそもLLM（大規模言語モデル）とは？

ローカルLLMについて触れる前にまずはLLM（大規模言語モデル）について理解しておきましょう。LLMとは、膨大なデータを学習し、人間のような自然な言語を使って文章の生成や理解ができる自然言語処理に特化した生成AIの一種です。後にも詳しく解説しますが、ソフトウェア開発の領域ではコードのレビューやドキュメント作成などに役立てられます。

なお、LLMのような自然言語処理ができる言語モデルには「SLM（小規模言語モデル）」もあり、さらにLLMについて触れるなら「RAG（検索拡張生成）」についても理解しておく必要があります。以下でそれぞれの特徴やLLMとの違いについて解説します。

1-1 SLM（小規模言語モデル）との違い

SLMは、LLMと同じく自然言語処理が可能なAIモデルですが、「小規模言語モデル」という名前が示すようにLLMよりも小規模で軽量な言語モデルを指します。金融や医療、保険など特定の分野で活用されることが多く、軽量な処理のためリソース要件に制約がある環境でも利用しやすいです。

LLMとSLMの違いを表でまとめると以下の通りです。

	LLM（大規模言語モデル）	SLM（小規模言語モデル）
規模（パラメータ）	数百億〜数兆	数億〜数十億
学習データ	幅広いタスクに対応	特定のタスクに特化
必要リソース	高性能GPUなどが必要	軽量
開発コスト	高い	低い
処理速度	遅い	高速

1-2 RAG（検索拡張生成）との違い

RAGとは、「Retrieval-Augmented Generation」の略語であり、LLMの能力や回答精度を向上させるための技術を指します。具体的には、LLMと外部のデータベースを連携し、データベースから検索した情報を付加させる形で精度の高い回答を実現する手法です。

LLMの場合は、学習された既存のデータだけを利用して文章を生成するため、適切な回答を得られない可能性があります。また、学習データが古くなると最新の情報が反映されないため、情報の正確性や信頼性に劣るケースも見られます。

そこでRAGも活用すれば外部データと連携して回答を行えるようになるため、最新情報や必要な情報を反映させた正確かつ信頼性の高いアウトプットを得られます。つまり、RAGはLLM活用を後押しするような技術として位置付けられるでしょう。

2 ローカルLLMとは？クラウドLLMとの違い

ではここからはローカルLLMについて、クラウドLLMとの違いも踏まえながら解説していきます。

2-1 ローカルLLMとは？

ローカルLLMとは、自社サーバーやユーザー個人のPC上などオンプレミス（ローカル）環境で動作する大規模言語モデルを指します。

インターネット接続を必要としないのが大きな特徴で、機密情報を外部に送信することなくAIを活用できるため、企業のセキュリティ要件に対応しやすいです。また、オフライン環境で処理が完結することから、通信障害やネットワーク遅延などの影響を受けにくく、運用におけるリスクを軽減できます。

さらに、ローカルLLMではモデルの再学習・微調整（ファインチューニング）も可能です。そのため、目的に応じて特定の業界やデータに特化させたモデルを構築できるなどカスタマイズ性が高いことも特徴の一つです。

2-2 クラウドLLMとの違い

クラウドLLMは、インターネットを介してベンダーのクラウドサーバー上で動作する大規模言語モデルを指します。ローカルLLMとは異なり、大前提として活用においてはインターネット接続が必須となります。

クラウドであることから導入における初期費用を抑えられ、かつ高いスケーラビリティを持つものの、入力データは外部のサーバーに送信されるため、セキュリティが重視される業界やシーンにおいては懸念があると言えます。

また、ローカルLLMよりもカスタマイズ性は劣り、ベンダーのサービス範囲内となるため、自由度は高くはありません。

3 ローカルLLMとクラウドLLMの比較表

	ローカルLLM	クラウドLLM
実行環境・接続要件	・自社サーバーやローカル端末で動作・インターネット接続不要	・ベンダーのクラウドサーバー上で動作・インターネット接続が必須
処理速度・性能	・ハードウェアの性能に依存する・ネットワーク遅延の影響を抑えられる	・高性能なサーバーの利用により処理速度が速い・通信障害の影響を受ける場合がある
コスト	・ハードウェアへの投資が必要・運用コストは維持費が中心で安定しやすい	・従量課金が一般的・初期費用を抑えられる
セキュリティ	・オンプレミス環境によりデータを外部に送信する必要がない	・データを外部に送信する必要があるため、懸念あり
カスタマイズ性	・自社のニーズに合わせたモデルを構築しやすい	・ベンダーのサービス範囲内
スケーラビリティ	・物理的なリソースを都度調整する必要がある・クラウドより手間がかかる	・柔軟にリソースを調整できる

ローカルLLMとクラウドLLMの違いをまとめると上記の通りになります。ただし、OpenAIが提供している「gpt-oss」のように低スペックで動作するような効率性の良いLLMも登場してきています。そういった背景からコスト面などの違いにおいては2025年8月現在、少し状況が変わってきているとも言えるため、定期的な情報収集が必要です。

4 ローカルLLMが注目されている背景

なぜソフトウェア開発やビジネスにおいて、ローカルLLMが注目されているのでしょうか。具体的な背景としては以下が挙げられます。

生成AI活用に対する企業ニーズの増加
セキュリティ意識の向上
技術的な進化

4-1 生成AI活用に対する企業ニーズの増加

ソフトウェア開発の領域においては、多様化するニーズやビジネス環境の変化に対応するためにAI活用のニーズが高まっています。

実際にGitLabが開催したイベント「DevOpsDive2025」によると、ソフトウェア開発ライフサイクルにおいてAIを使用中の国内企業の割合は48%で、米国の38%よりも高い数値となっています。ただし、国内のAI活用はコーディングの範囲に留まっている状況で、開発プロセス全体を通した活用には至っていません。

ソフトウェア開発ライフサイクル全体にAI活用を行き渡らせるためには十分なセキュリティ対策が必要になり、その手段として有効なのがローカルLLMの活用です。ローカルLLMならオンプレミス環境により企業の機密情報を安全に扱いながらAIを利用できます。つまり、ローカルLLMはAI活用における重要なソフトウェア開発基盤の一つだと言えるでしょう。

4-2 セキュリティ意識の向上

近年ビジネスにおけるIT活用が浸透する中で、セキュリティインシデントも多く発生しており、ソフトウェア開発の領域においてもセキュリティ対策への重要性が高まっています。

LLMをクラウドベースで利用する場合、企業の重要な機密情報を外部のクラウドサーバーへ送信する必要があることから、情報漏えいのリスクが高まります。

ローカルLLMなら機密性の高いソースコードや仕様書などを、安心して投入して自由にAIを活用することが可能です。

4-3 技術的な進化

ローカルLLMが注目されている背景として、技術的な進歩も挙げられます。例えば、日本語特化型LLMの登場により、日本企業がローカルLLMを導入する際にも扱いが容易になり、実用性が高まっています。

また、先ほど少し触れたようにモデルの軽量化により低スペックで動作できるようなLLMも登場してきているため、以前よりローカルLLMをスムーズに導入できる環境が整ってきていると言えるでしょう。

5 ソフトウェア開発におけるローカルLLMのメリット

ソフトウェア開発におけるローカルLLM導入のメリットは以下の通りです。

開発の効率性と生産性の向上
セキュリティ・コンプライアンスの強化
コストの最適化

5-1 開発の効率性と生産性の向上

ローカルLLMはソフトウェア開発ライフサイクルにおけるさまざまなプロセスで活用できます。例えば、コード補助や自動レビュー生成、バグ修正、脆弱性修正補助などに使えば、ヒューマンエラーのリスクを軽減しながら迅速かつ品質の高いソフトウェア開発を実現することが可能です。

ローカルLLMの活用によって効率よく開発を進めることで、開発者はより価値の高い活動や業務に集中できるようになり、結果としてチーム全体のパフォーマンスを向上させられるでしょう。

5-2 セキュリティ・コンプライアンスの強化

繰り返しにはなりますが、ローカルLLMなら自社サーバーを利用するため外部にデータを送信する必要がなく、セキュリティやコンプライアンスの強化を図りながら生成AIを活用できます。セキュリティ要件の厳しいプロジェクトや業界でも活用しやすく、開発者の心理的ハードルも下げられ安全に作業を進められるでしょう。

また、ローカルLLMを通して潜在的な脆弱性を検出し、修正案の提案を受けることでコードの安全性向上にもつなげられます。

5-3 コストの最適化

ローカルLLMの導入によりコストの最適化を図れるメリットもあります。クラウド型のLLMは初期費用を抑えられるものの、従量課金制を採用していることから利用量（トークン数）が増えると、コストが大幅に増えてしまう可能性もあります。

一方、ローカルLLMは初期にハードウェア導入費用が発生しますが、一度構築してしまえば運用に必要な費用は基本的に維持費だけになるため、長期的な視点で考えるとコストの最適化を図れるでしょう。

6 ローカルLLM導入におけるデメリット・課題

ローカルLLMの導入においては以下のようなデメリットや課題もあるため、事前に把握しておく必要があります。

専門知識の必要性
高額な初期導入コストの発生
不正確・不完全なデータを生成する可能性

6-1 専門知識の必要性

ローカルLLMを導入するためには、オープンソースLLMを自社サーバーで実行できるよう環境の構築やモデルの最適化が必要になります。このプロセスにおいては、専門的な知識や技術が求められるため、社内で適切な人材を配置しなければなりません。基盤となるインフラ設計やファインチューニングなどさまざまな知識が必要になりますが、特にvLLMとHugging Faceなどでホストされているモデルに関する知識が重要です。

また、ローカルLLM導入後のメンテナンスやセキュリティ管理なども自社で対応しなければならないため、事前に社内で体制を整備しておきましょう。

6-2 高額な初期導入コストの発生

ローカルLLMを導入する際には、高性能なハードウェアなどを確保する必要があるため、初期の導入コストが高額になりがちです。特に大規模なモデルを扱う場合は、計算能力の高い高価なGPUを用意しなければなりません。

しかし先述したように一度導入してしまえばその後の運用コストは安定しやすいため、長期的な利用を前提とすればクラウドLLMよりも経済的な効果が期待できる可能性は高いと言えます。

なお、NVIDIAと同等スペックのハードウェアを低価格で提供する動きが既にあるので、そのあたりも注視しておきたいところです。

6-3 不正確・不完全なデータを生成する可能性

ローカルLLMを活用する際には、AIが必ずしも正しいデータを生成するとは限らないことを理解しておく必要があります。例えば、ソフトウェア開発において脆弱性の分析や修正をローカルLLMを通して自動化する場合、正しい結果がアウトプットされない可能性もあるため、AIからの修正案を検討するタイミングなどにおいては人間による二重チェックを積極的に行うことが大切です。

なお、ローカルLLMのデータ品質を保つためには、定期的なモデルのアップデートが重要です。クラウドLLMのように自動で最新の状態にアップデートされるわけではないため、自社で再学習や調整作業を行わなければなりません。

7 ソフトウェア開発におけるローカルLLMの活用例

ソフトウェア開発においては以下のようなプロセスにおいてローカルLLMを活用できます。

コード補完・レビュー
ドキュメント作成・ナレッジ共有
CI/CDパイプラインの作成

7-1 コード補完・レビュー

ソフトウェア開発でローカルLLMを導入することで、オフラインでのコード補完・レビューが可能になります。コード補完ならコードを記述している際に、AIがコードの提案を行なってくれるため、開発者のコーディングスピードの向上が期待できます。

また、コードレビューの自動化により、開発者は効率的にコードの改善を実施でき、AIで一貫性のあるレビューを実現することでコード品質の向上につなげられるでしょう。

7-2 ドキュメント作成・ナレッジ共有

ローカルLLMの活用は、ソフトウェア開発におけるドキュメント作成やナレッジ共有でも役立ちます。例えば、ドキュメント作成なら仕様書の初稿作成や内容のチェックをローカルLLMを通して行えば、作業の効率化につなげられます。

また、RAGと連携して社内ナレッジベースや文書を利用して社内Q&A検索などを構築すれば、開発チーム内でのナレッジ共有をスムーズに行えるでしょう。

7-3 CI/CDパイプラインの作成

ソフトウェア開発でのローカルLLMの活用は、CI/CDパイプラインの作成やパイプライン実行時のエラー調査にも貢献できます。また、テストコード生成によってテスト作業の軽減化も支援することが可能です。

CI/CDパイプラインの構築から実行におけるプロセスを効率化すれば、開発者はソフトウェアの開発作業に集中できるようになるため、リリース頻度やスピードの向上につなげられます。

8 ローカルLLMの導入方法

では実際にローカルLLMを導入するにはどのような手順を踏めば良いのかを解説します。

目的と要件の整理
環境整備
継続的な検証と改善

8-1 1.目的と要件の整理

まずはソフトウェア開発の領域において「なぜローカルLLMの導入が必要なのか？」という目的を明確化することが大切です。

例えば、「クラウドからの移行によるコスト最適化を図りたい」「自社のセキュリティ要件にマッチした開発環境を構築したい」など目的を検討します。明確な目的がないと導入そのものが目的となってしまい、十分な効果を得られないためきちんと設定し、社内で共通の認識を持っておく必要があります。

また、ローカルLLMを導入して具体的にどのような成果を得たいのか定量的なKPIもあわせて設定しておくことで、導入後の効果検証や改善がしやすくなります。例えば、開発コストの削減量やパイプライン実行時間などの目標値の設定が考えられます。

8-2 2.環境整備

次にローカルLLMの実行に必要なモデルの選定や環境構築を行います。モデルの選定においては導入目的をもとに、求められる性能やリソース要件などを考慮して検討します。

ハードウェア環境においては、使用するモデルのサイズや用途、利用ユーザー数などに応じた要件を満たすことがポイントとなり、特にGPUの性能が重要です。ハードウェア環境が整った後は、ソフトウェア環境の設定を行い実際にモデルを実装していきます。

8-3 3.継続的な検証と改善

モデル実装後は、継続的なパフォーマンステストと改善を行います。具体的には、処理速度や回答精度、リソースの利用状況などを検証し、必要に応じて改善や調整を実施します。なお、実際の運用においてはまずは小規模なプロジェクトから開始し、検証結果の内容や利用ユーザーのフィードバックを取り入れながら徐々に拡大していくと良いでしょう。

また、長期的に安定して運用するためには、メンテナンスやアップデートをスムーズに行える体制づくりも必要です。

9 ローカルLLMのおすすめモデル

ローカルLLMの導入にあたっておすすめのモデルを紹介します。なお、ここで紹介するモデルはGitLabのサポート対象です。

Mistral-Small-3.2-24B-Instruct-2506
Codestral 22B
Llama 3

9-1Mixtral-8x7B-Instruct-v0.1

Mixtral 8x7Bは、Mistral AIが2023年12月にリリースした大規模言語モデルです。混合エキスパートモデル（MoE）を採用しているのが特徴で、学習・推論スピードに強みがあります。Mixtral 8x7Bならコード生成タスクでも高精度なアウトプットが期待でき、Duo Chatでも活用可能です。

9-2 Codestral 22B

Mistral AIが2024年5月から公開しているCodestral 22Bは、コーディングに特化した大規模言語モデルです。PythonやJava、C、SQLなど人気のプログラミング言語を含め、80以上の言語に対応しています。コード自動補完など開発効率の向上を目的として活用できます。Chatには使えませんが、ソースコード生成処理として良い選択になります。この時にGitLabは、用途用途にモデルを切り替えられるメリットがあります。

9-3 Llama3

Llama3は、Meta社が2024年4月に公開したオープンソース大規模言語モデルです。Llama3には、「8B」と「70B」の2つのモデルが存在します。

Llama3 8Bは、80億のパラメータを持つモデルで比較的コンパクトであることから、計算リソースが限られるシーンでの利用が向いています。一方、Llama3 70Bは、700億のパラメータを持つモデルであり、多様なタスクへの対応やパフォーマンス向上などを目的として活用できます。また、ライセンスフリーで利用可能なモデルの中では最高峰レベルの性能を誇るため、ハードウェアに予算が割けられる場合は70Bをおすすめします。

10 ローカルLLM導入における注意点

ローカルLLMを導入する際には以下のような注意点があり、事前に必要な対策を検討しておくことが大切です。

社内での周知・教育・活用定着を図る
社内でのセキュリティ設定・アクセス制御を徹底する
モデルのライセンスを確認する

10-1 社内での周知・教育・活用定着を図る

ローカルLLMを自社で導入した場合でも実際に開発者に使われないと意味がありません。導入目的の説明や操作マニュアル・ガイドラインの整備などを行い、利用の定着を図ることが大切です。社内におけるAI活用の利用状況を効率的にチェックするには、ツールの活用がおすすめです。

GitLabのサービスの一つとして「AI Impact Dashboard」があり、この機能を活用することで自社のAI導入における利用状況を可視化してROIのモニタリングが可能になります。

10-2 社内でのセキュリティ設定・アクセス制御を徹底する

ローカルLLMは自社サーバーで運用しますが、社内でのセキュリティ対策は必須です。

社内でのセキュリティ対策としてまず挙げられるのは、モデルに入力した機密データの管理の徹底です。LLMが出力するログにはソースコードなどの断片が出力されるケースもあるため、LLMを運用しているOSへのログインや物理アクセスの管理などを行わなければなりません。

また、実際にモデルを入手する際には改ざんされたモデルを利用しないようダウンロード元には十分注意しましょう。

10-3 モデルのライセンスを確認する

ローカルLLMを導入する際に注意点したい要素として、モデルのライセンス条件があります。各モデルによって付与されているライセンスが異なり、商用利用や改変、再配布の可否などの条件が設定されています。

ライセンス違反にならないよう使用予定モデルのライセンス規約を丁寧に確認し、運用におけるリスクを取り除いておきましょう。

11 GitLab Duo Self-HostedによるローカルLLM運用

GitLab Duo Self-Hostedを活用することで、ローカルLLMをGitLabと連携して運用できます。GitLabは、ソフトウェア開発ライフサイクル全体を効率化できるDevSecOpsプラットフォームです。

ここでは、GitLab Duo Self Hostedの特徴やローカルLLMとの連携で実現できることを紹介します。

11-1 GitLab Duo Self-Hostedとは？概要と主な特徴

GitLab Duoは、GitLabが提供するソフトウェア開発におけるワークフローを支援するAIソリューションです。 Self-Hosted版ならGitLab Duoをオンプレミス環境で運用できるため、安全にAIを活用しながら開発を進められます。

また、Mistralなど主要なモデルをサポート対象としているため、自社のセキュリティやパフォーマンス要件に応じて柔軟にモデルを選定し、最適なソリューションを構築できます。

11-2 ローカルLLMとGitLabの連携で実現できること

ローカルLLMとGitLabの連携により以下のようなことが可能になるため、ソフトウェア開発における生産性と品質向上を実現できます。

コード補完・レビュー支援（20以上の言語に対応）
セキュリティ脆弱性検出・修正提案
アクセス制御
AI投資のROI測定
CI/CDのyml生成・トラブルシュート、コードレビューの自動化など

12 ローカルLLMの将来性・今後の展望

結論から述べるとローカルLLMの需要は拡大し、今後もさまざまなシーンで広く活用されていくと言えます。

一般社団法人電子情報技術産業協会（JEITA）が発表した「生成AI市場の世界需要額見通し」によると、生成AI市場の世界需要額は年平均53.3%で成長しており、2030年には2,110億ドルに達すると言われています。これは、2023年の106億ドルから約20倍の需要額となる見込みです。

ローカルLLMは、厳しいセキュリティ要件にも対応できるなどソフトウェア開発やビジネスにおいて多くのメリットがある技術です。今後も低スペックで動作する高性能モデルの登場や、クラウドとのハイブリッド活用などさらなる技術の発展やアプローチによって、開発者にとって必要不可欠なソフトウェア開発基盤として機能していくでしょう。

※出典：JEITA、生成 AI 市場の世界需要額見通しを発表

13 ローカルLLMに関するQ＆A

最後にローカルLLMに関するQ＆Aを紹介します。

13-1 ローカルLLM導入はどのようなチームに向いている？

ローカルLLM導入は以下のような条件に該当するチームに向いています。

プロジェクトや業界のセキュリティ要件が厳しい
機密性が高いソフトウェア開発をしている
CやC++など高い技術力が求められる言語で開発しているが、人員集めに苦労している
クラウドのAPI課金に対してコスト面で負担を感じている
LLMをDevSecOpsに組み込みたいなど

13-2 ローカルLLM運用のための最低限のハードウェア条件は？

GitLab Duo Self-Hostedをオンプレミスで実行する場合は以下の通りです。ただ実際の要件はモデルのサイズと使用目的などによって異なるため、参考程度として捉えてください。

・GPU：1 x NVIDIA A100（40GB）
・VRAM: 35GB以上
・ストレージ：モデルサイズ分以上

※参考：ハードウェア要件 | GitLab Duo

13-3 ローカルLLMとクラウドLLMのハイブリッド活用例は？

ローカルLLMとクラウドLLMの使い分けやハイブリッド活用においては目的や要件によって判断する必要があります。

例えば、機密性の高いソースコードに関する作業であり、かつ利用頻度も高い場合はローカルLLMで実行する必要があります。一方で機密性が低く、かつソースコードに関する作業頻度も低い場合は、クラウドLLMを利用すると良いでしょう。

万が一クラウドLLMを運用中に障害が発生した時は、ローカルLLMを利用します。ただし、使用するモデルが異なるとアウトプットの質にも影響が出てくるため、可能な範囲でハイブリッド活用を検討します。

なお、クラウドLLMは最新モデルを素早く利用できる利点と、モデルを動作するインフラの規模（GPUやVRAMなど）を気にする必要がないため、最新のクオリティでLLMを活用したいケースでの利用が向いているでしょう。

まとめローカルLLMを自社のソフトウェア開発に取り入れよう

ソフトウェア開発においてローカルLLMを採用することで、セキュリティ要件が厳しいケースにおいても安全に開発を進められます。実際の導入においては目的の明確化や自社ニーズ・リソースにマッチしたモデルの選定、適切な運用体制の構築が鍵となってきます。

ローカルLLMを自社の開発プロセスに導入するならぜひ「GitLab Duo Self-Hosted」をご活用ください。GitLab Duo Self-Hostedならオンプレミス環境でさまざまなAI機能を活用して、高品質かつ迅速なソフトウェア開発を実現できます。

監修：小松原つかさ @tkomatsubara

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

コード生成AIのリスクを管理し、ポテンシャルを最大限に引き出す【イベントレポート】

2025-09-10T00:00:00.000Z

GitLabは2025年7月23～25日の3日間、都内ホテルで開催された「ガートナーセキュリティ＆リスク・マネジメントサミット2025」に出展しました。本記事では、GitLabシニア・ソリューション・アーキテクト吉瀬淳一が登壇したセッションの模様についてレポートします。

会場の様子

この日の講演は、コード生成AIの話が中心です。まずは会社の話から入ったのですが、吉瀬は比較的社歴の浅いエンジニアで、働き方の紹介もユニークでした。GitLabは、全世界の全従業員がリモートで働いていることで知られています。実際に、GitLab社員の多くは、お客様やパートナー様から「よく聞くけれど、本当にそうなの？」と尋ねられた経験をしています。

吉瀬は、「GitLabには本社がありません。世界中のどこを探しても、オフィスすらありません。私の場合も、入社が決まると会社のPCが送られてきて、GitLabでの生活が始まりました。入社した当日から、いきなり1人ぼっちです」と話して、会場の空気を和ませました。

GitLab合同会社ソリューションアーキテクト本部シニアソリューションアーキテクト吉瀬淳一

セキュリティ対策の全体像とシフトレフトの重要性

ソフトウェア開発においてコード生成AIを活用する前に、プロジェクトにおいてセキュリティをどう担保するかについて決めていく必要があります。その際に、セキュリティ対策の全体像を分解し、企画、開発、運用という大きく3つのくくりで詳細を決めることが必要です。

スライド：企業が取り組むべきセキュリティ対策の全体像

企画は、いわゆる統制やガバナンスのようなもの。企業全体、もしくはプロジェクト全体としてのルールを、ここで決めます。開発は、コードを生み出す段階での対策です。脆弱性検査の自動化やセキュアコーディングの標準化などがこれに当たります。運用におけるセキュリティ対策は、実行環境を守る手段を指します。エンドポイントセキュリティやネットワーク監視、ID管理、ログ管理などです。

そして、これらの中で、最も課題が多いのは開発の部分になります。吉瀬は、「開発課題が大きい理由のひとつは、実際の開発を外部委託していることでしょう。委託先が何をやってるのか見えにくいのです。ただ、この部分の改革に取り組んでいかなければ、本当の意味でのセキュリティを守ることはできません」と話します。

スライド：デジタル庁が提示する「セキュリティ・バイ・デザイン」の原則

そのためにも、シフトレフトが重要になります。開発の上流工程で対策を講じることで、デプロイ後に脆弱性が見つかって対応するなどの手戻りは大幅に低減します。さらに、品質の向上につながることも期待できます。実際に、デジタル庁が公開した『政府情報システムのためのセキュリティ・バイ・デザインガイドライン』でも、開発のなるべく早い段階にセキュリティを担保するプロセスを組み込み、問題点を潰していくことの重要性がうたわれています。

「現在、多くの日本企業は“事故が起きてからどうするかを考える”というセキュリティ対策を重視する傾向があるようです。それももちろん大切なのですが、偏りすぎると問題です。開発から運用に至るプロセスは左から右へと図示されますが、左側の開発段階でもやれることは数多くあります。きちんとシフトレフトして、開発の上流工程も最適化する方向で考えるべきです」（吉瀬）

生成AIを活用するエンジニアはすでに100%！？

GitLab合同会社ソリューションアーキテクト本部シニアソリューションアーキテクト吉瀬淳一

その最適化すべき“左側”で、生成AIは大きなムーブメントになっています。吉瀬は、「生成AIを活用しているエンジニアは、ほぼ100%と言ってもいいくらい」と話します。「ソフトウェア開発にAIを使っていると答えた組織の割合が78%という調査結果がありますが、よく見てください。 “組織”ですよ。個人のレベルになるとどうでしょう。組織としては、人が書いていると思っているけれど、実はその人がAIを使っているケースは多いでしょう。なにしろ、生産性が桁違いですから」。

一方、GitLabの調査をまとめた『2024グローバルDevSecOpsレポート』によると、ソフトウェアエンジニアがコードを書く時間は、全就業時間の21%にとどまっています。残りの79%は脆弱性の対応やテスト、トラブルシューティング、打ち合わせなど。ここに、生成AIを導入してる企業の開発生産性が2割程度しか上がらない原因があります。全体の21%を占める部分の生産性が10倍になっても、残りの79%がボトルネックになり、全体的な生産性は上がらないのです。

スライド：AI生成コードの脆弱性とセキュリティリスクの急増

さらに、生成AIのはらむセキュリティリスクに注意が必要です。上図に示したように、懸念点は大きく3つ。まず、AIが生成するコードには脆弱性が含まれがちです。次に、エンジニアは脆弱性が含まれていることは認識できるものの、その発見や対処法に自信を持っていません。最後に、マネジメントは、社内でAIがどういう扱われ方をしていて、どんなリスクが発生しているかをつかみきれていません。

GitLab合同会社ソリューションアーキテクト本部シニアソリューションアーキテクト吉瀬淳一

さらに問題を大きくしているのが、AIのサイロ化です。ソフトウェア開発プロセスでは、さまざまなツールが使用されます。そしていま、各ツールの裏でAIが動くようになりました。これらのAIが、IssueやEpic、マージリクエストの議論、過去の変更履歴といった開発の全体的なコンテキストを把握できないことが問題なのです。プロセスの中には、特定の脆弱性を修正する目的のIssueがあります。しかし、コード生成AIはその背景を知りません。CI/CDのAIは単にテストの成否だけを見ます。この状況では、「脆弱性を修正する」という本来の修正意図が反映されているかどうかを判断できません。“開発の文脈”を理解しないまま、各ツール上だけで動くAIが部分的な判断を下すことで、本質的な問題が見過ごされてしまうリスクが高まってしまうのです。

単一のプラットフォームでソフトウェア開発ライフサイクル全体を管理する

こうした状況を抜本的に解決するために、 GitLabは単一のプラットフォームでソフトウェア開発ライフサイクル全体を管理するというアプローチを採ります。企画、開発、運用にまたがるセキュリティ対策全体を鳥瞰する包括的な解決策であり、コードの脆弱性、開発者の信頼性、ガバナンスという3つの懸念点もクリアできます。

スライド：セキュアなAI活用を実現するDevSecOpsプラットフォーム

GitLabのソリューションにおいて、生成AIを活用した開発プロジェクトのシフトレフトを支える中心になるのが、GitLab Duoのコードレビュー&修正支援機能です。GitLab Duoでは、人間がレビューする前にAIがコードを自動チェックし、脆弱性を指摘します。さらに、脆弱性が生まれた原因と具体的な修正方法までAIが提案することで、脆弱性発生リスクを極小化することができます。開発段階においてGitLab Duoを利用することで、セキュアなコード開発を促進する体制が自然に生まれることになります。

GitLab上でプロセスを整え、ルール化を徹底すれば、シフトレフトは自然に推進されます。たとえば、パイプラインポリシーを整備すれば、開発者のスキルや意識に依存しない一貫したセキュリティレベルを担保できます。コードのコミットをトリガーに多様なセキュリティスキャンを自動実行するなど、適切なタイミングでセキュリティスキャンするプロセスを組織に根付かせることもできます。開発プロセスを最適化し続けることで、問題を早期に発見し、対処できる強固な体制が生まれます。

GitLab合同会社ソリューションアーキテクト本部シニアソリューションアーキテクト吉瀬淳一

GitLabのAIはプラットフォームとしての強みを生かし、一貫したコンテキストにもとづいて全体に対する有益な示唆を与えてくれます。GitLabを単一データストアとして、開発の全工程のデータを一元管理しておけば、AIが“全体の文脈”を理解できます。コードの関連性を把握し、変更の影響範囲もスピーディに指摘してくれます。サイロ化されたツールでは不可能な、一貫性のある高度な支援が可能になるのです。

さらに、GitLabのAIポリシーは、極めて透明性の高いものです。GitLabのAIは、「顧客のデータを学習データとして利用しない」など、企業の知的財産を守る明確なポリシーを設けています。ユーザーは、安心して最先端のAI技術を活用することも可能ですし、よりセキュアな環境を求める場合は、オンプレミス環境におけるローカルLLM運用にも対応しています。

一貫したコンテキストの中でAIの力を最大限に生かす

GitLab合同会社ソリューションアーキテクト本部シニアソリューションアーキテクト吉瀬淳一

コード生成AIは、開発を加速させる強力な武器です。ただし、正しく活用すれば、であることに注意が必要です。コード生成AIのポテンシャルを最大限に引き出し、同時にリスクを管理するために必要な要素は、ここまで述べてきたとおりです。つまり、開発ライフサイクル全体を俯瞰し、一貫したルールとコンテキストのもとでAIを機能させる、GitLabのような統合プラットフォームが不可欠なのです。

吉瀬は、「生成AIの時代は始まったばかりで、これからどんどん広まっていくでしょう。ひとりの開発者が生み出すコードの量は、これまでに比べると凄まじく増えます。生産性はどんどん高まります。すばらしいことです」と話します。

「確かに、生成AIの書いたコードに脆弱性が大量に含まれているというリスクはありますが、生産性とリスクのバランスを考えると、AIを使わないという選択肢はありえません。だからこそ、コードのレビューや脆弱性の修正にもAIを使い、パイプラインポリシーのシフトレフトをきちんとやる必要があるのです。プラットフォームを統合して、一貫したコンテキストの中でAIの力を最大限に生かしていきましょう。これがGitLabからのメッセージです」（吉瀬）

イベントで配られたノベルティ（水筒）

イベントで配られたノベルティ（スニーカー）

Monday Merge 9月号：より速いパイプライン、もっと賢いエージェント、そしてより大きな成果を！

2025-09-08T00:00:00.000Z

9月の始まりとともに、最新リリース、注目のホワイトペーパー、そして大規模なDevSecOpsの取り組み事例をお届けします👇

GitLab 18.3 リリース！Duo AgentsのIDE対応、Embedded Viewsなど多くの新機能が登場

今回のリリースでは、セキュリティやコンプライアンスの強化から、開発ツール内でのAIアシストまで、プラットフォーム全体に渡る改善を実現しました。

新機能はこちら：

Visual Studio向け Duo Agent Platform（ベータ）
開発者はVisual Studio内でGitLab Duo Agent ChatとAgent Flowsを直接利用可能に。IDEを離れることなく、質問、タスク自動化、アーキテクチャ設計、コード生成まで行えます。
埋め込みビュー（一般提供）
エピック、Wiki、課題を動的でクエリ可能なダッシュボードに変換。GLQLでリアルタイムデータを活用し、チームの足並みを常に揃えられます。
CI/CDジョブトークンの細かな権限設定
最小権限の原則を適用し、ジョブトークンごとのアクセス範囲を正確に制御。
直接転送によるマイグレーション（一般提供）
GitLabインスタンス間でのプロジェクト移行がよりスムーズで信頼性も向上。
Duo Self-Hosted のアップデート
ハイブリッドモデル選択のサポート、持ち込みモデルの柔軟性、コードレビュー用カスタム指示に対応。

そのほかWeb IDE、コンプライアンス機能、管理者ロール、AWS Secrets ManagerとのCI/CD連携など、多数の改善が追加されています。

💜 今回のリリースには 314件のコミュニティ貢献が寄せられました！まさに「みんなが参加できる」ということを証明してくれました。

👉 18.3リリースノート全文はこちら

エージェント駆動のCIモダナイゼーション

「よりスマートなパイプライン。より速い投資回収。」

企業がCI/CDパイプラインを最新化しようとする時、現実には「時間がかかる」「コストが高い」「スケールが難しい」といった課題が立ちはだかります。

そこでGitLabの新ホワイトペーパーが提案するのが Agentic CI Modernization。GitLab Duo Agent Platformを活用することで、ラボテストでは以下の成果が示されています：

⏱️ パイプライン変換が 81%高速化（240分 → 45分） 💸 コンサル費用が 83%削減 📉 モダナイゼーション期間が 2.5年 → 9か月に短縮

従来のやり方はツール乱立やコンテキスト切り替え、コンサル依存の進め方で停滞しがちですが、エージェント型AIが状況を変えます。

GitLab Duo Agentsはレガシーパイプラインを解析し、アーキテクチャや依存関係を理解したうえでGitLab CI設定を自動生成。これによりエラーを最大70%削減し、価値提供までのスピードを大幅に加速します。

このホワイトペーパーで語られる内容は単なる時間短縮の話ではありません。目指しているのは、プラットフォームエンジニアリングを大規模に実現し、開発者が共通のCI/CDコンポーネントをサービスとして利用できる環境をつくることです。

👉 ホワイトペーパーはこちらから

カスタマースポットライト：Deutsche Telekom

18か月のリリースサイクルが、わずか3か月へ。分断されたツール群から、13,000人以上が使う統合されたGitLabプラットフォームへ。手作業のセキュリティチェックから、GitLab Ultimateによる完全統合スキャンへ。

2億4,000万人以上のモバイル顧客を抱える通信大手Deutsche Telekom社。いまや単なるネットワークプロバイダーにとどまらず、DevSecOpsの先駆者へと変貌を遂げています。

GitLabに集約したことで、同社IT部門はCI/CDの全社展開に成功し、“インナーソース”文化を育成。いまやアジャイルプログラムの75%がGitLabに依存しています。

「セキュリティが1つのアプリに統合されていれば、すぐに問題箇所へ飛んで修正できます（中略）これによりセキュリティ対応の効率が大幅に向上しました。」

— Thorsten Bastian, Business Owner IT, CI/CD Hub, Telekom IT

👉 ストーリー全文はこちら

ドキュメントが新しく生まれ変わりました

新しい docs.gitlab.com にようこそ！ ゼロから再構築し、わかりやすさ、スピード、使いやすさが大幅アップしました。

新しくなったポイント：

どのデバイスでも快適に使える、モダンなインターフェース
必要な情報にすぐたどり着けるスマート検索
より直感的なナビゲーションとアクセシビリティ向上

経験豊富なDevSecOpsプロから、これから始める方まで。新しいドキュメントはあなたの強い味方 →

今月のイベントで会いましょう

今月はサンパウロからシンガポールまで、GitLabが世界各地へ！ぜひブースに立ち寄って、ノベルティをゲットし、DevSecOpsの最新情報を語り合いましょう。

🇧🇷 Google Cloud Summit Brazil 👉 [登録はこちら] 🇸🇬 EPIC Conference Singapore 👉 [登録はこちら] 🇨🇭 Google Cloud Summit Switzerland 👉 [登録はこちら]

GitLab Duoを実際に体験し、新しいアイデアやインスピレーション、次の大きなデプロイ成功のヒントを持ち帰りませんか？

今月のおすすめ記事

エージェント型AIのブレークスルーから、大規模なソフトウェアのセキュリティ対策まで、今月の注目記事をご紹介します。

そしてまだの方は、ぜひAIがソフトウェアイノベーションに与える影響に関するC-suiteレポートもチェックしてみてください。

https://about.gitlab.com/software-innovation-report/
（日本に特化したレポートは近日中に公開予定）

最後に、今月の名言を

パイプラインの最新化、ツール統合、エージェント型AIの導入。大きな変革はときにハードルが高く見えますが、すべては小さな一歩から始まります。

「それが成し遂げられるまでは、いつも不可能に見えるものだ。」 — ネルソン・マンデラ

難しいパイプラインに直面したら、「不可能」とは「まだ実現していないだけ」と思い出してください。

次回まで

今月も読んでいただきありがとうございました！感想やフィードバックはぜひXでのメンションやコメントでシェアしてください。お待ちしています。

それではまた来月、お会いしましょう！Happy Merging！

Fatima Sarah Khalid｜Developer Advocate, GitLab

🧡 このニュースレターが気に入った方は、ぜひチームにもシェアしてください。 👉 The Developer Showの購読もお忘れなく！

GitLab Duo Agent Platform：イシューからMRフロー

2025-09-03T00:00:00.000Z

GitLab Duo Agent Platform（現在ベータ版で提供中）は、AIエージェントがイシューやマージリクエストなどのGitLabリソースとやり取りできるフレームワークを提供し、コンセプトから完成まで複雑な多段階タスク実行を可能にします。Agent Platformは、コード生成、モダナイゼーション、セキュリティ脆弱性の修正、プロジェクト分析を支援する対話型（エージェント型チャット）と自動化型（エージェントフロー）のエクスペリエンスを提供します。これらはすべてエンタープライズレベルのセキュリティとカスタマイズ可能な制御機能も備えています。

「イシューからMR」は、適切にスコープが定義されたイシューを、ドラフトのマージリクエスト（MR）に変換するプロセスを効率化するエージェントフローです。このフローはイシューの説明と要件を分析し、イシューにリンクされたドラフトMRを開き、開発計画を作成し、実装案を提案します。これらすべてがGitLab UIから直接実行できます。

デベロッパーが直面する課題

UIレイアウトの調整、コンポーネントのサイズ変更、ワークフローの微調整といった製品の小さな改善に、何時間もの設定作業は必要ないはずです。しかし、デベロッパーはこのようなイライラするサイクルに陥りがちです。適切なファイルを見つけるためにコードベースを探し回り、ブランチを作成し、複数のコンポーネントに散在する変更をまとめ、複雑なレビュープロセスを経る必要があります。そして、これらはすべて、ソリューションが実際に機能するかどうかを確認できる前の作業です。開発のオーバーヘッドにより、本来であれば素早い反復作業であるべきものが時間のかかるタスクに変わり、フィードバックループが遅くなり、シンプルな製品の改善が大掛かりな取り組みのように感じられてしまいます。

「イシューからMRフロー」を使ってアプリケーションの更新を加速する方法

「イシューからMRフロー」を使用する前に、以下の前提条件を満たす必要があります。

前提条件：

明確な要件と受け入れ基準が記載された既存のイシュー。これにより、達成しようとしていることをGitLab Duo Agent Platformがよく理解し、出力の品質を向上させることができます。
プロジェクトのソースコードを編集するフローのため、Developer以上の権限を持つプロジェクトアクセス。
グループまたはプロジェクトでGitLab Duo Agent Platformが有効になっており、「フロー」が許可されていること。これには、プロジェクトの設定 > 一般 > GitLab Duo > フローの実行の許可トグルを有効にしてください。GitLabは適切なガードレールの提供に取り組んでおり、エージェント型AI機能では機密性の高いプロジェクトを保護し、GitLab Duo Agent Platformがアクセスしてほしいプロジェクトのみを許可するため、これらのトグルを有効にする必要があります。

上記のすべての前提条件を満たしたら、以下の手順に従ってイシューからMRフローを活用できます：

GitLab Duo Agent Platformに実行してもらいたいことを説明するプロジェクトイシューを作成します。イシューの説明にできるだけ詳細を記載してください。イシューがすでに存在する場合は、計画 > イシューに移動し、更新したい内容を説明しているイシューをクリックして開きます。イシューのスコープは明確かつ具体的に設定してください。
イシューヘッダーの下にあるDuoでマージリクエストを生成をクリックしてフローを開始します。
イシューの実装に取り組むエージェントの進行状況を追跡したい場合は、自動化 > エージェントセッションに移動して、エージェントが計画を立てて、変更を提案している様子をライブセッションログで確認できます。
パイプラインが完了すると、イシューのアクティビティにMRへのリンクが表示されます。これを開いて、サマリーとファイルレベルの変更を確認してください。
GitLab Duo Agent Platformが提案した更新をローカルで検証したい場合は、ラップトップにブランチをプルし、アプリをビルド・実行し、更新が期待通りに動作することを確認できます。必要に応じてMRで編集を行い、通常のレビューを進めてください。
提案されたアプリケーションの更新にすべて満足したら、MRをメインブランチにマージします。

「イシューからMRフロー」がアプリケーションの変更に効果的な理由

「イシューからMRフロー」はコード変更を提案し、MRを直接更新するため、ファイルを探す時間が短縮され、結果の評価とレビューのみに集中できます。さらに、MRは自動的に元のイシューにリンクされ、レビュアーや関係者にとってコンテキストが明確に保たれます。また、エージェントセッションをモニタリングすることで、各ステップで何が起こっているかを把握できます。

GitLab Duo Agent Platformのメリット

GitLab Duo Agent Platformは、完全なプロジェクトコンテキストを提供するエージェント型オーケストレーションレイヤーで、プランニングからコーディング、ビルド、セキュリティ、デプロイ、監視まで含むため、エージェントは単なるコード編集だけでなく、ソフトウェア開発ライフサイクル（SDLC）全体をサポートできます。

統合データモデル：GitLab DuoエージェントはGitLabの統合されたSDLCデータ上で動作し、コーディング以外のタスクを含めて、より質の高い意思決定とコラボレーションを可能にします。
セキュリティとコンプライアンスがビルトイン：GitLab Duoエージェントはエンタープライズのガードレール内で実行され、高度に規制された環境やオフライン/エアギャップ環境でも使用できます。
相互運用性と拡張性：ベンダーやツール間でフローをオーケストレートします。MCP/A2A経由で外部データを接続し、より豊富なコンテキストを提供します。
コラボレーションのスケール：GitLab DuoエージェントはGitLab UIとIDEで動作し、複数の人間と複数のエージェント間のコラボレーションを可能にします。
検索可能かつ共有可能：一元化されたAIカタログでエージェントとフローを検索・共有できます。

今すぐ「イシューからMRフロー」を試してみましょう

アプリケーションの更新、例えばUI調整のような小規模な作業では、「イシューからMRフロー」によって、明確に定義されたイシューからレビュー可能なMRまでを素早く作成できます。進行状況を監視でき、標準のワークフローで変更内容を検証・マージできます。チームはコンテキストを保ちつつ、引き継ぎ作業を削減できるので、単純作業ではなく品質に注力できるようになります。

イシューからMRフローの動作を実際にご覧ください：

GitLab UltimateとDuo Enterpriseの無料トライアルで今すぐGitLab Duo Agent PlatformのイシューからMRフローを試してみましょう。

GitLabがAIガバナンスでISO/IEC 42001認証を取得

2025-09-02T00:00:00.000Z

人工知能（AI）は、あらゆる業界で働き方や問題解決の方法を変革しています。AIがビジネスプロセスや意思決定により深く統合されるにつれて、堅牢なAIガバナンスフレームワークの必要性がかつてないほど重要になっています。組織はAIの潜在的な機会と、AIシステムが安全で倫理的、かつ説明責任を持って構築されることを保証することの間でバランスを取らなければなりません。

責任あるAI管理への取り組みの一環として、GitLabがISO/IEC 42001認証を取得したことを発表いたします。これは、組織内でAI管理システム（AIMS）を確立、実装、維持、継続的改善するための国際的に認められた初の標準です。

認証の範囲には、当社の包括的なAI製品であるGitLab Duo、およびGitLab Duo Agent Platformとそのコンポーネントが含まれます。DevSecOpsのリーダーとして、GitLabは開発ライフサイクル全体にわたってAI駆動機能を提供しており、以下のような機能があります：

GitLab Duo Agent Platform（パブリックベータ版、今年後半の一般提供を予定）：ソフトウェア開発ライフサイクル全体を通じて、デベロッパーと専門的なAIエージェント間の非同期コラボレーションを可能にし、線形開発プロセスを動的な並列ワークフローに変換しながら、GitLabの統一プラットフォーム内に保存されたすべてのソフトウェアエンジニアリングコンテキストへのアクセスをエージェントに提供します。
コード提案（一般提供中）：コードブロックを予測的に補完し、関数ロジックを定義し、テストを生成し、正規表現パターンなどの一般的なコードを提案することで、デベロッパーがすでにコーディングを行っている同じ環境でフロー状態を維持できます。
脆弱性の説明（一般提供中）：デベロッパーとセキュリティアナリストが脆弱性、その悪用方法、修正方法を理解するのに役立ちます。
テスト生成（一般提供中）：選択したコードに対してテストを自動的に作成し、カバレッジを向上させ、手作業を削減します。

この認証がGitLabユーザーにもたらす価値

信頼性と透明性の向上： 当社のAI機能は、AIガバナンスに関する国際的に認められた最高水準に従って構築・管理されており、信頼性と倫理的な実装をサポートします。

戦略的リスク管理： 運用事業継続性リスク、技術的リスク、セキュリティとプライバシーリスク、より広範な社会的影響などの側面を考慮して、プラットフォーム内のAIコンポーネントに対するリスク評価とリスク対処戦略を実装しました。この積極的なアプローチにより、顧客データの保護が強化され、より信頼性の高いAI駆動機能が促進されます。

継続的改善： ISO/IEC 42001フレームワークの下で、年次外部監視監査、定期的な内部評価、リーダーシップによるAIMS審査を通じて、品質と責任の基準を維持しながらAI機能を継続的に評価・向上させていきます。

規制との整合性： EU AI法などのAI規制が世界的に進化し続ける中、この認証は新たな規制要件に対するGitLabの対応をサポートします。

この認証取得により、AI駆動DevSecOpsの信頼できるプラットフォームとしてのGitLabの地位がさらに確固たるものとなりました。今後も責任あるAIイノベーションの分野で業界をリードし続けます。

詳細情報

GitLabトラストセンターでISO/IEC 42001認証書をご覧ください。
ハンドブックのAIMSをご覧ください。
GitLab AI Transparency Centerをご確認ください。
詳しくは、GitLab Duoのすべての機能のドキュメントをご確認ください。

DevSecOpsにおける企業の独立性がこれまで以上に重要な理由

2025-09-02T00:00:00.000Z

10年以上にわたり、GitLabは透明性、独立性、そしてデベロッパーファーストの姿勢を大切にしてきました。業界が進化する今日、これらの価値はこれまで以上に重要になっています。「開発インフラを最終的に管理するのは誰なのか？」「AIシステムでコードがどのように使用されているのか？」「ベンダーの優先事項が重要な要件から離れた場合はどうなるのか？」企業のリーダーたちはこのような重要な疑問を投げかけています。

先月、GitLab 18.3のリリースを発表しました。これは、AIネイティブなDevSecOpsプラットフォームの最新版です。GitLab Duo Agent Platformの一部であるエージェントインサイトは、エージェントの意思決定プロセスを可視化します。AIモデルサポートの拡張により、ベンダーロックインを回避できます。強化されたガバナンス管理により、複数の管轄区域にわたるコンプライアンスの実現を支援します。

これらは単なる機能ではありません。GitLabを定義する透明性、独立性、デベロッパーファーストのアプローチの実証なのです。この戦略が実際にどう機能するかをご紹介します。

DevSecOpsライフサイクル全体でのAI透明性

GitLabでは、10年間にわたる透明性への取り組みが、これらの懸念に直接対処しています。 人工知能が開発ワークフローにますます統合される中、組織は自社のコードとデータがAI学習にどのように使用されているかを当然懸念しています。

2024年4月に開始されたGitLab AI Transparency Centerは、データガバナンスの実践、プライバシー保護、倫理的AI原則について明確な文書を提供しています。データ使用ポリシーが不明確なAI機能を運用する可能性のあるプラットフォームとは異なり、GitLabは透明性を優先し、お客様が自分たちのデータがどのように処理、保存、保護されているかを正確に把握できるようにしています。お客様のデータでの学習は一切行いません。

私たちのアプローチは、モデルの柔軟性とベンダーの独立性にも及んでいます。お客様を単一の大規模言語モデル（LLM）プロバイダーに限定し、追加のベンダー依存や潜在的な単一障害点を作り出すプラットフォームがある一方で、GitLabのAI機能は様々なモデルによって強化されています。このアプローチにより、幅広いユースケースをサポートし、お客様の戦略的優先事項に合わせた柔軟性を持ち合わせています。

GitLab Duo Agent Platformの開発をさらに進める中で、データ制御と包括的な人間参加型制御の維持に焦点を当て続けています。また、GitLab Duo Self-Hostedは、エアギャップ環境へのデプロイオプション、ゼロデイデータ保持ポリシー、自社インフラ内ですべてのAIリクエストを処理する機能により、完全なデータ主権を提供します。

2024年5月以降、私たちは業界をリードするコミットメントを含むAI継続プランも維持しています。これは、プロバイダーが顧客データに関する実践を変更した場合、30日以内に新しいモデルを評価して移行する能力です。AIベンダーリスク管理に対するこの積極的なアプローチは、顧客管理への私たちの取り組みを反映しています。

デプロイの選択、クラウドプロバイダーの選択

DevSecOps環境をどこにどのようにデプロイするかを選択できるべきです。 GitLabは真のデプロイの柔軟性を実現します。組織は、オンプレミス導入、マルチテナントSaaS、または完全管理型のシングルテナントSaaSソリューションであるGitLab Dedicatedから選択でき、機能を犠牲にしたり、エコシステムロックインを促進する人為的な制限に直面することはありません。GitLabはクラウドニュートラルでもあり、お客様はビジネスニーズと環境に最適なクラウドプロバイダーを使用できます。

この柔軟性は、複雑な管轄要件や規制上の課題をナビゲートする際に、非常に価値があることが証明されています。欧州連合やその他の地域で見られるような新しいデータローカライゼーション法が登場した場合、GitLabを使用する組織は、エコシステムの依存関係に制約されることなく、デプロイ戦略を迅速に適応させることができます。

調達とリスク管理の観点から、プラットフォームの独立性は契約交渉において重要な影響力も提供します。組織は、顧客のニーズよりもベンダーの利益を優先する制限的なライセンス契約に縛られることがありません。この独立性は、企業がAIスタックの管理者が誰なのかを警戒するようになる中で、特に重要になります。

セキュリティとコンプライアンス：組み込み型で常に優先事項

セキュリティとコンプライアンスは現在、開発機能と同様に重要であり、後付けではなく、プラットフォームに組み込まれているべきです。 GitLabの単一プラットフォームアプローチは、基本的なセキュリティとガバナンス機能を実現させるために、サードパーティのアドインに依存する断片化されたプラットフォームよりも大きな優位性を提供します。このアーキテクチャの違いは、潜在的な法的リスク、運用効率、規制コンプライアンスに重要な影響を与えます。チェーン内の追加ツールはそれぞれ、別の潜在的な障害点、交渉すべき別の利用規約セット、そして別のリスクの源となります。

GitLabは、カスタムコンプライアンスフレームワーク、動的アプリケーションセキュリティテスト（DAST）、APIファズテスト、カバレッジガイドファズテスト、Infrastructure-as-Codeテストなど、包括的な組み込みセキュリティとコンプライアンス機能を提供します。これらの機能はプラットフォームにネイティブに統合されており、一貫したポリシー実施を提供し、複数のサードパーティツールの管理に伴うコンプライアンスの複雑さや追加コストを削減します。

GitLabのコンプライアンスセンターは、チームがコンプライアンス基準、遵守レポート、違反レポート、グループのコンプライアンスフレームワークを管理するための中央拠点を提供します。このコンプライアンス管理への統一されたアプローチは、監査証跡とコンプライアンス文書が重要な、高度に規制された業界で事業を行う組織にとって特に価値があります。

オープンソースコミュニティとの密接な関係の維持

最高のツールは、それを使用する人々によって形作られます。 オープンソースへの取り組みとコミュニティとの関わりは、GitLabの創設以来の中核となっています。例えば、私たちのCo-Createプログラムは、お客様がGitLabエンジニアと直接連携してGitLabプラットフォームへの機能、修正、改良をコントリビュートできる協力的な取り組みです。

透明性という価値観は、私たちのビジネスの根幹であり続けています。この例として、お客様が私たちの開発進捗をフォローし、製品改善についてGitLabチームと直接議論に参加できるオープンイシュートラッカーがあります。最近立ち上げた、ヘルシーバックログイニシアチブでは、私たちの開発計画をさらに詳しくお客様に公開し、いただいたフィードバックをもっとも効果的に活かせる部分に確実に反映させています。

私たちのアプローチにより、組織は規制環境に必要なガバナンス、監査証跡、セキュリティ管理を維持しながら、オープンソースイノベーションに貢献し、その恩恵を受けることができます。

データガバナンス：自分のデータは自分で守る

データとその処理方法について、完全な管理権限を保持できます。 データガバナンスは、国や地域ごとの複雑なデータ保護法や、ソースコード、顧客インサイト、戦略的イニシアチブ、競争情報といった機密知的財産に対する管理への懸念の高まりを背景に、企業技術の意思決定においてますます重要な要因となっています。

GitLabでは、プラットフォーム内のAI搭載機能へのアクセス権限を管理でき、単純なアクセス制御を超えて、規制フレームワークに合わせた暗号化基準と監査機能を包括します。また、お客様のコードとデータはAIモデルの学習に使用されることは一切ありません。

選択は明確です

GitLabは、AIネイティブなDevSecOpsプラットフォームイノベーションをリードし続けています。私たちの最新の18.3リリースがそれを実証していますが、同時に常に私たちを導いてきた独立性と透明性へのコミットメントを堅持しています。

お客様には選択肢があり、その選択は明確です：管理権の保持かベンダーロックインか。透明性か不確実性か。イノベーションへのコントリビュートか、より大きなエコシステムの気まぐれか。

GitLabは、イノベーションと独立性のバランスを取る持続可能なデジタルトランスフォーメーションの基盤を提供し、お客様のビジネス価値の実現を支援します。

GitLab UltimateとGitLab Duoを今すぐ無料でお試しください。

仮想マシン（VM）とは？意味や導入メリット、GitLab活用例

2025-08-28T00:00:00.000Z

仮想マシン（VM）は、IT技術が進化する時代の中でソフトウェア開発やビジネスの領域において近年注目されている技術の一つです。実際に自社のソフトウェア開発の領域において、仮想マシンの導入を検討している人も多いのではないでしょうか。仮想マシンを自社の開発に取り入れて確かな効果を発揮するためには、仮想マシンの特徴などを事前に詳しく理解しておく必要があります。

この記事では、仮想マシンの基礎知識からソフトウェア開発・ITインフラの領域で導入するメリット、具体的な活用方法まで解説するのでぜひ参考にしてください。

1. 仮想マシン（VM）の基礎知識

まずは、仮想マシンを理解するために知っておきたい仮想化と呼ばれる技術の概要や、仮想マシンの特徴について解説します。

1-1 そもそも仮想化とは

仮想化とは、物理的な環境に囚われずにサーバー、ストレージ、ネットワーク、メモリなどのハードウェアリソースを効率よく利用するための技術のことです。

よりわかりやすく簡潔に説明すると、仮想化とは本来1つであるハードウェアリソースを複数あるかのように利用する技術です。この仮想化技術は現代の企業のIT戦略を検討する上で重要な位置付けとなっています。

1-2 仮想マシン（VM）とは

では、この記事の本題である仮想マシンについて説明します。仮想マシンとは、仮想化技術を活用して1つの物理マシン内（コンピューター）に仮想的に複数のコンピューターを再現する環境のことです。

物理マシンは実体として存在するコンピューターであるのに対して、仮想マシンはソフトウェアを利用して物理マシン内に仮想的に再現したコンピューターであるという違いを理解しておくと良いでしょう。

つまり、仮想マシンなら1台のコンピューター上で複数のOSをそれぞれ独立した状態で稼働できるようになります。後にも詳しく解説しますが、これによりサーバー台数の節約やニーズに応じたOSの稼働などができるようになり、開発やビジネスにおけるコスト削減や生産性向上にも寄与します。

2 仮想マシン（VM）におけるホストOSとゲストOS

仮想マシンを語る上では、「ホストOS」と「ゲストOS」という言葉の意味についても理解しておく必要があります。

まずホストOSとは、仮想マシンを構築する際の土台となるOSを指します。つまり、実体のある物理マシンにインストールされているOSです。一方、ゲストOSは仮想マシンにインストールするOSのことです。

例えば、Windowsのコンピューターに対して仮想環境を作成して、Linuxをインストールすれば、ホストOSはWindows、ゲストOSはLinuxとなります。このようなホストOSとゲストOSの関係性は業務上でも使われるため、違いを把握しておくと良いでしょう。

3 仮想マシン（VM）の歴史

仮想マシンは近年注目されている技術の一つですが、歴史自体は古く、1960年代には既に使用されていました。当時のコンピューターリソースを複数のユーザーで使用するための「タイムシェアリング」という技術が仮想化の起源だと言われています。

その後、時代の流れと共にIT技術が発展し、コンピューターの価格低下も実現できたことから物理的に台数を増やして運用するという考えが広まりました。しかしそれでは企業にとって運用負荷が増加してしまうという課題が残るため、仮想化技術が再び注目されるようになっているのです。

※参考：「仮想化」を理解するための誕生の歴史 | ITソリューション塾

4 仮想マシンの主な利用シーン

仮想マシンは具体的にどのようなシーンで利用できるのでしょうか。具体例として以下が挙げられます。

ソフトウェア開発・テスト
新しいOSのテスト
ソフトウェア・アプリケーションの実行
セキュアなWebブラウジング

4-1 ソフトウェア開発・テスト

仮想マシンはソフトウェア開発・テストの領域で役立てられます。仮想マシンを使って本番とは隔離された環境で開発を行えば、開発途中でなんらかのトラブルが発生した場合でも影響を最小限に抑えられるでしょう。また、複数の異なるOSを構築できるため、アプリケーションの互換性テストを容易に実行することが可能です。

4-2 新しいOSのテスト

企業が業務改善やビジネス上の戦略を理由に既存のOSから新しいOSへの移行を検討するケースもあるでしょう。しかし、使い慣れた環境から新しい環境へ切り替えを行う際には、既存のアプリケーションや周辺機器の互換性・操作性などを細かにチェックしなければなりません。

事前に仮想マシンを使用して移行予定のOSを試せば、移行後の業務への影響度を事前に把握できるでしょう。

4-3 ソフトウェア・アプリケーションの実行

業務を進める上で状況によっては、現在利用しているOSでは動作しないソフトウェアやアプリケーションの実行が必要になるケースもあるでしょう。

そういったケースでも仮想マシンを使えばソフトウェアやアプリケーションの実行に必要となるOSを柔軟にインストールできるため、業務に支障が出ることなく仕事を進められるでしょう。

4-4 セキュアなWebブラウジング

Webブラウジングを行う際にも仮想マシンを活用できます。Webブラウジングとは、Webブラウザを利用してWebサイトやホームページなどの情報を閲覧することです。

ウイルス感染のリスクが高いサイトも存在する中で、仮想マシンを使って隔離されたセキュアな環境でWebブラウジングを行えば、企業におけるセキュリティリスクを軽減できます。

5 仮想マシン（VM）を実行するソフトウェアの種類

仮想マシンを実行するためにはソフトウェアが必要になりますが、主に以下の種類に分けられます。

ホストOS型
ハイパーバイザーOS型

5-1 ホストOS型

ホストOS型とは、先ほど解説したホストOS上に仮想化ソフトウェアをインストールして仮想マシンを構築する方法になります。

以下からホストOS型を採用するメリットやデメリット、代表的な仮想化ソフトウェアを紹介します。

５−１−１ホストOS型のメリット・デメリット

ホストOS型のメリットは、既に利用しているOS上にソフトウェアをインストールするだけで仮想マシンを実現できるため、扱いやすく容易に導入できることです。そのため、まずは仮想環境に触れてみたいといったテスト用途や、個人学習用途などで利用することが可能です。

しかし、ホストOS型の場合は物理マシンと仮想マシンとの間にホストOSが介入することになり、本来の処理に加えて余分なリソースがかかる「オーバーヘッド」と呼ばれる現象が発生します。そのため、高速な処理には不向きな手段であることを把握しておかなければなりません。

５−１−２代表的な仮想化ソフトウェア

ホスト型の仮想化ソフトウェアの例としては以下が挙げられます。

・Oracle VM VirtualBox

VirtualBoxは、Oracle社が提供する人気の仮想化ソフトウェアです。多機能であることが特徴で、「スナップショット」「シームレスモード」「共有フォルダ」など仮想マシンを活用する上で便利な機能が搭載されています。

・VMware Fusion Pro

VMware Fusion Proは、Mac上で仮想マシンを構築し異なるOSを実行できる仮想化ソフトウェアです。ファイル共有などさまざまな機能が提供されています。

5-2 ハイパーバイザー型

ハイパーバイザー型とは、ホストOSを使わず、ハイパーバイザーと呼ばれる専用の仮想化ソフトウェアをインストールして仮想環境を構築する方法です。以下からハイパーバイザーOS型のメリットやデメリット、代表的なソフトウェアを紹介します。

５−２−１ハイパーバイザー型のメリット・デメリット

ハイパーバイザー型のメリットは、ホストOSを使わずに仮想マシンを構築するため、ホストOS型と比較してオーバーヘッドが少なく高速な処理が期待できます。

ただし、既存の物理マシンでハイパーバイザーを使用できない場合は、新たに互換性のある物理マシンを購入する必要があり、そのための費用を用意しなければなりません。また、ホスト型OSと比べて導入や管理においてある程度の専門知識が求められます。

ホストOS型とハイパーバイザー型の特徴の比較を以下の表でまとめました。

５−２−２代表的なハイパーバイザー

代表的なハイパーバイザーには以下のようなものがあります。

・KVM

KVMは、Linuxをハイパーバイザーとして動作させることができる仮想化技術です。Linuxカーネル2.6.20以降から標準搭載されているため、Linuxを使用しているなら手軽に試せるでしょう。

・VMware ESXi

VMware ESXiは、 VMware が提供しているソフトウェアです。ESXiファイアウォールによりアクセス制限が可能でセキュリティにも強みを持っているのが特徴です。

・Citrix Hypervisor

Citrix Hypervisorは、 Citrix社が提供する仮想化プラットフォームです。Xen Projectをベースとしており、高性能なハイパーバイザーで信頼性が高いことが特徴です。

6 仮想マシンとコンテナの違い

仮想化手法においては「コンテナ」と呼ばれる技術もあるため、仮想マシンとの違いを理解しておきましょう。

6-1 コンテナとは？

コンテナとは、アプリケーションを実行するための動作環境を仮想化して利用する技術のことです。

仮想マシンは、物理マシン内に仮想化ソフトウェアを利用して複数の異なるOS（ゲストOS）を構築します。一方、コンテナは、「コンテナエンジン」と呼ばれるコンテナを管理するソフトウェアがOSとして機能するため、ゲストOSは不要になります。

代表的なコンテナエンジンは、「Docker」になります。Dockerを活用すれば、複数のアプリケーションの実行環境を手軽に作成できます。

6-2 コンテナの特徴

コンテナは先ほども解説した通りゲストOSが不要であるため、必要最低限のリソースで運用することができコスト削減につながります。また、処理速度も速いことから効率的な運用を実現できるでしょう。

しかし、コンテナの場合はOSが限定されるため、複数の異なるOSを利用できる仮想マシンのような自由度は期待できません。例えば、ソフトウェア開発において異なる種類の環境でテストを実行したい場合には適していない手段だと言えます。また、コンテナはコマンド操作や管理方法など初期で覚えることも多いため、スムーズな導入を実現するためには学習環境や運用体制を構築しておく必要があります。

7 ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するメリット

ここではソフトウェア開発とITインフラの領域に焦点を当てて、仮想マシン（VM）を導入するメリットについて解説します。

IT・開発コストの削減
開発・テスト環境構築の迅速化
複数OSの活用による効率性の向上
DevSecOpsのサポート
セキュリティリスクの軽減
可用性の向上とBCP対策への貢献

7-1 IT・開発コストの削減

仮想マシンを導入することで、物理的なハードウェアリソースを論理的に分割する形で共有できるため、コスト削減につながります。複数OSの稼働が必要になった場合に、仮想環境を構築せずに物理的にリソースを準備するとなると、コンピューターの購入費や管理費などさまざまなコストが追加で発生してしまいます。

仮想マシンなら、ハードウェアリソースを効率よく有効活用できるため、ソフトウェア開発・ITインフラの領域でも追加コストの発生を最小限に抑えられます。

7-2 開発・テスト環境構築の迅速化

仮想マシンは開発・テスト環境構築の迅速化にもつなげられます。開発者は簡単に仮想環境を作成できるようになるため、需要に応じて開発・テスト環境を瞬時にスピンアップできます。また、使用しない時にも素早くテイクダウンが可能です。

本来であれば開発・テスト環境を構築する際には物理的な作業が発生し、時間を要します。柔軟性と拡張性を持つ仮想マシンなら、急なニーズが発生した場合でも物理的な作業を省略できるため、状況の変化に応じたスピーディーな対応が可能です。

7-3 複数OSの活用による効率性の向上

仮想マシンなら1つの物理マシン上で異なる複数のOSを運用できます。時間やコストをかけることなく、必要な時にゲストOSとして構築するだけでさまざまな環境でソフトウェアの開発やテストを実行することが可能です。例えば、WindowsとLinuxを同時に起動してアプリケーションの互換性をチェックするなどの対応が可能です。

複数OSの活用によって開発やテストの効率性向上を実現できるでしょう。

7-4 DevSecOpsのサポート

DevSecOpsとは、開発（Dev）、セキュリティ（Sec）、運用（Ops）の3つの概念を組み合わせたアプローチのことを指します。開発サイクルにおいて開発からセキュリティ、運用までを連携して進めることでセキュリティ強化や開発スピードの向上につなげられます。

仮想マシンの導入はこのDevSecOpsのサポートやツールチェーンの合理化にも貢献します。例えば、開発プロセスにおいて仮想マシンを作成し、仮想マシン上にCI/CDのような自動化されたワークフローを取り入れることで独立した環境で実行基盤を構築できます。

7-5 セキュリティリスクの軽減

仮想マシンはそれぞれ独立した環境で互いに分離された形で運用され、かつホストシステム（物理的なコンピューター）からも隔離されているため、セキュリティ対策にも役立ちます。

例えば、1つの仮想マシンでセキュリティトラブルが発生した場合でも、他の仮想マシンやホストシステムへの影響を抑えやすいでしょう。ただし、環境分離によるセキュリティリスクの軽減は期待できるものの、トラブルが発生する可能性をゼロにできるわけではありません。仮想環境特有のセキュリティ対策も徹底し、より安全に運用できる体制を構築する必要があります。これについては後述します。

7-6 可用性の向上とBCP対策への貢献

仮想マシンは障害にも強く、システムの可用性を高めることも可能です。例えば、現在の仮想マシンの状態を保存・復元できる「スナップショット機能」を活用すれば、システム障害が発生した場合でも容易に以前の状態に戻すことが可能です。

また、稼働中の仮想マシンを継続したまま別のホストに移行できる「ライブマイグレーション機能」なら、安全性の高いホストへ移動させることで事前にシステムトラブルを回避できるでしょう。

8 ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するデメリット

ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入する際には以下のようなデメリットもあるため、事前に把握しておくことが大切です。

パフォーマンス低下の可能性
仮想環境の導入・管理における専門性が高い
仮想環境特有のセキュリティ対策が必要
障害時の対応が増える場合がある

8-1 パフォーマンス低下の可能性

仮想マシンは物理的なコンピューターと比較すると性能面で劣る場合があるため、開発時に処理に時間がかかってしまったりなど不便さを感じてしまうかもしれません。例えば、オーバーヘッドが発生すると余分なリソースがかかり、処理速度に影響を与えてしまうでしょう。

特に安定した作業環境が強く求められるシーンにおいては、適切なリソース配分を検討する、状況に応じて物理的なコンピューターを用意して利用するといった対策が必要になります。

8-2 仮想環境の導入・管理における専門性が高い

仮想マシンをスムーズに導入し、安定した運用を実現するためには専門的な知識や技術が求められます。次で詳しく触れますが仮想環境においても特有のセキュリティ対策が必要になり、専門知識を持った担当者がいないと十分な対策はできないでしょう。

自社に専門知識を持った人材がいない場合は、新たに確保したり、対象者を教育しなければなりません。そのためには採用・教育コストが発生することも把握しておくことが大切です。

8-3 仮想環境特有のセキュリティ対策が必要

仮想マシンに対してもセキュリティリスクは存在するため、仮想環境特有のセキュリティ対策は必要になります。例えば、基盤となる物理マシンやホストOSだけでなく、仮想マシンにも専用のセキュリティソフトを導入することが大切です。また、複数の仮想環境を運用する場合は対策や管理に抜け漏れがないよう注意しなければなりません。

その他、万が一セキュリティトラブルが発生した場合の対応フローを事前に整備しておくことも大切です。

8-4 障害時の対応が増える場合がある

仮想マシンは1つの物理マシン上で利用されるため、物理マシンに障害が発生した場合、稼働している全てのシステムに影響が出る可能性もあります。これは単一障害点（SPOF）と呼ばれるものですが、もし発生した場合は復旧対応に時間や手間、そして金銭的なコストがかかってしまうでしょう。

単一障害点を回避するためには、事前に仮想環境基盤の冗長化を検討しておく必要があります。

9 仮想マシン（VM）の一般的な設定手順

仮想マシンの一般的な設定手順は以下になります。

仮想化ソフトウェアの選定
ゲストOSのインストール
ネットワークの設定・データ共有

まずは仮想マシンを導入する上で仮想化ソフトウェアの選定を行う必要があります。先ほど紹介したようにソフトウェアには「 VM VirtualBox」や「KMV」などがあるため、特徴を把握して自社の要件に合ったものを選びましょう。

仮想化ソフトウェアを選定してインストールした後は、ゲストOSのインストールも行いましょう。最後にネットワーク設定や必要に応じてホストOSとのデータ共有などを行い運用します。

10 仮想マシン（VM）でのGitLab活用例・使い方

仮想マシンはGitLabのようなCI/CDツールと連携が可能で、DevSecOpsの推進にもつなげられます。GitLabでのCI/CDプロセスを実行する環境として仮想マシンを有効活用できます。

ここでは、GitLabのサービス紹介や、仮想マシン上でGitLabを使用するメリットなどを解説します。

10-1 GitLabとは？

GitLabは、ネイティブAIを搭載したソフトウェア開発のライフサイクル全体を網羅するDevSecOpsプラットフォームです。ソフトウェア構築における計画から開発、テスト、リリース、運用までを単一のプラットフォームで統合して実行することができ、ビジネスの加速化や運用負担・コストの削減につなげられます。

CI/CDパイプラインの構築やセキュリティの自動化、ソースコード管理、プロジェクト管理などソフトウェア開発の効率化に役立つ充実した機能を提供しており、中小企業からエンタープライズまで世界中の多くの企業で導入されています。

10-2 仮想マシン上でGitLabを使うメリット

仮想マシン上でGitLabを利用することでどのようなメリットがあるのでしょうか。具体的には以下の通りです。

セキュアな環境で開発・テストを実行できる
本番環境に近い環境でテストやビルドを行える
バックアップ機能やスナップショット機能でデータ復旧が容易になる

10-2-1 セキュアな環境で開発・テストを実行できる

物理マシンとは独立した環境でGitLabを利用するため、セキュアな環境で開発やテストを実施することが可能です。仮想マシン上でトラブルが発生した場合もホストシステムへの影響を抑えられるため、セキュリティ要件が高いプロジェクトにも適しています。

また、仮想マシンなら常にクリーンな状態の環境を用意できるため、GitLabのCI/CDプロセスにおいて正確なテストやビルドが可能になります。

10-2−2 本番環境と同じ環境でテストやビルドを行える

仮想マシンなら複数の異なるOSを用意できるため、例えばCI/CDプロセスにおいて本番環境を再現して動作確認やテストができるようになります。状況に合わせてさまざまな条件下で使用することで環境の違いによる不具合をリリース前に検出しやすくなるでしょう。

10-2-3 バックアップ機能やスナップショット機能でデータ復旧が容易になる

仮想マシンのスナップショット機能を活用すればデータのバックアップを容易にとることができ、障害時の復旧にも役立てられます。また、GitLabにはバックアップ機能が搭載されているため、より安全なシステム運用を実現できるでしょう。

まとめ仮想マシン（VM）の活用で開発効率の向上を図ろう

仮想マシンは近年注目されている技術であり、ソフトウェア開発やITインフラの領域でも積極的に活用することで開発効率の向上やコスト削減、セキュリティ対策などにつながります。

DevSecOpsプラットフォーム「GitLab」は、仮想マシン上で利用することができ、CI/CDプロセスを実行する環境として活用できます。その他、プロジェクト管理などチームでの開発を効率化できる豊富な機能が搭載されているため、ぜひ自社への導入をご検討ください。

より効率的な開発環境をお探しの方は

VMの設定や管理に時間を取られることなく、すぐに開発を始めたい方にはGitLab Workspacesという選択肢があります。k8sベースの開発環境で、複雑な仮想マシンの構築作業を省略できます。

▶︎ GitLab Workspaces について詳しく：https://docs.gitlab.com/user/workspace/ 詳しくは、当社GitLabの営業チームまでお気軽にお問い合わせください。

なお、GitLabでは世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧ください。

2024グローバルDevSecOpsレポートはこちら

監修：知念梨果 @rikachinen（GitLab合同会社カスタマーサクセス本部カスタマーサクセスエンジニア）

みんなの銀行の内製化戦略とAIへの取り組み【イベントレポート】

2025-08-27T00:00:00.000Z

GitLabは2025年6月、都内ホテルで開催された「Gartner Application Innovation & Business Solutions Summit 2025」に出展しました。開催したセッションは約170人の参加者を集め、株式会社みんなの銀行（以下、みんなの銀行）取締役常務執行役員CIO宮本昌明氏をお招きし、当社Japan Country Manager小澤正治と対談形式で実施しました。本記事では、その模様をお伝えします。

BaaS事業を支えるプラットフォーム

株式会社みんなの銀行取締役常務執行役員CIO 宮本昌明氏

みんなの銀行は、2021年5月に事業を開始したデジタルバンクです。日本で初めてフルクラウドで銀行システムを構築・運用することでも注目を集めており、B2Cのスマホアプリ事業に加え、APIを主軸としたBaaS（Banking as a Service）事業や、バンキングシステムの外販も行っています。

現在、立ち上げから約4年が経過。すでに130万口座を獲得し、ユーザーの70%は40歳未満の若年層です。ふくおかフィナンシャルグループの傘下で、福岡市に本社を置いていますが、SNSなどを活用したマーケティングが奏功し、顧客層は全国に広がっています。

個人向けのデジタルバンクとして話題をさらう中、ビジネスの1つの柱に育ちつつあるのがBaaS（Banking as a Service）事業です。同事業では、みんなの銀行が自社のシステムをAPIを通して外部へと公開。ユーザーは、提携事業者のアプリなどを経由して「自分がみんなの銀行のサービスを使っている」ことを意識せず、銀行機能を利用できるようになります。

公開中のAPIは多彩です。振込・決済だけでなく、認証・同意、本人確認済み情報提供、振込キャンセルなどをラインアップ。この日の時点で公開されている提携先は24社に及び、すでに非金融業界を含む15社が自社サービスに組み込んだ機能をリリースしています。

株式会社みんなの銀行取締役常務執行役員CIO 宮本昌明氏

みんなの銀行は、銀行業務の心臓部となる勘定系システムを、Google Cloud上にフルスクラッチで開発しています。宮本氏は、「BaaS基盤は勘定系の横に置くイメージ」と勘定系と密に連携させたBaaS基盤について説明します。このBaaS基盤の開発に、GitLabは大きな役割を果たしました。BaaS部分の開発にあたり同行は、マイクロサービスおよびイベント駆動型アーキテクチャを採用し、TDD（テスト駆動開発）を導入。その開発プラットフォームになったのがGitLabなのです。

導入当時は、組織もシステムもゼロからのスタートでした。構想の初期段階からの必須要件は、セキュリティを高めるだけでなく、ログ取得や権限管理などのコンプライアンスも備えたDevSecOps環境を作ること。宮本氏は、「セキュリティとコンプライアンスは絶対条件でした。そして、その上で効率化を追求します。これらは並び立たないように聞こえますが、並び立たせるのがわれわれの基本スタンスです」と話します。

ソフトウェアライフサイクル全体をカバーできる一気通貫のソリューションとしてGitLabを採用し、テスト自動化、セキュリティスキャン、ディペンデンシースキャン、SBOMなど幅広い機能を活用するに至りました。

また、コンプライアンスパイプラインとしてGitOpsの考え方も導入しました。Gitリポジトリを唯一絶対の存在（SVoT）と位置づけ、本番環境がGitリポジトリと異なる場合は自動修正します。ただし、リリース承認プロセスを維持することでガバナンスを確保するなど、実際に運用するにあたってさまざまな工夫も取り入れています。

テストの民主化についても独自のアプローチで取り組んでいます。開発側だけがテストを実行するのでなく、ビジネス側もテストに関与することで責任を分担するなどの施策は、テストの自動化が進むとともに社内に根付いてきました。

優秀なエンジニアたちに挑戦の場を提供

株式会社みんなの銀行取締役常務執行役員CIO 宮本昌明氏

みんなの銀行は、GitLabをプラットフォームとして実施する開発業務の大半を内製化しています。宮本氏は、内製化のメリットについて、大きく4つのポイントを挙げます。まずは、自社プロダクトの将来を真剣に考え、社員であるエンジニアが主体的に関与できること。次に、設計・開発・リリース・保守・運用といったすべてのプロセスで得られるナレッジを社内に蓄積できること。そして、効果的な設計や省力化された運用負荷を実現できる製品選定・設計を行えること。最後に、保守・運用まで自前で行うことで、自動化や不要な作業削減を開発設計段階から意識できることです。

内製化への道筋

宮本氏は、内製化成功のカギは人財にあるとし、優秀なエンジニアの「採用」を大切にしながら、それ以上にエンジニアが働きたいと思える環境を「維持」していくことに力を注いでいると語ります。多くのエンジニアにヒアリングした結果、彼らは「やりたいことができる仕事環境」や「新しい技術への挑戦」を求めていることに気づきました。ルーチンワークになりがちな保守・運用やテストをGitLabを使って可能な限り自動化しているのは、エンジニアに新たな挑戦の場を提供するためでもあります。

宮本氏は、「自分たちで考えて、自分たちで現状をより良く変えられるのが、優秀なエンジニアです。彼らが学習できる環境を用意し、実際に挑戦もしてもらいます。失敗することもあるでしょうけれど、上手に小さく失敗してもらってきちんと軌道修正できるような文化を作っています」と話します。

長く使ってきたGitLabは、組織に根を張りました。エンジニア同士がGitLab上で議論を深め、コラボレーションする基盤へと育っています。

内製化推進においてGitLabが果たす役割

「エンジニアは下請けではありません。ただものづくりをする人でもありません。ものを作ってサービスを提供する人なのです。組織には、エンジニアやビジネス企画など、さまざまな役割を持つ人が居ますが、その役割の壁を超えて、1つのサービスをみんなで作るという文化を大切にしています」（宮本氏）

多様なAgentic AIをオーケストレーションする製品へ

GitLab合同会社 Japan Country Manager 小澤正治

小澤からは、GitLabの紹介とAI活用の取り組みについてお話させていただきました。GitLabは、ソフトウェア開発のライフサイクル全体を一元的に統合管理するプラットフォーム。この日のイベントを主催するガートナーのMagic Quadrant™において、製品の方向性と機能実装の両面から、リーダーという評価を受けています。

今回のセッションで、テーマのひとつであるAIでは、統合されたシームレスな開発環境にAIをアドオンし、個々の開発工程の部分最適ではなく、AIを活用した全体最適を目指すことが特長。AIコーディングによる生産性向上だけにとどまらず、レビュー、脆弱性対策、安全なコードリリースなどソフトウェア開発の全工程にAIを活用するという方向性で製品を進化させています。

ソフトウェア・サプライチェーン全体のガバナンスも、AIを搭載するGitLabで管理する対象です。GitLabを導入した組織単体を見るのではなく、ソフトウェア・サプライチェーン全体のセキュリティリスク対応や組織体制の強化もプラットフォーム上で実現。SaaSに加え、Self-Managed、クラウドセルフホステッドでも利用できるため、機密性の高い情報を扱うユーザー向けに、ローカルLLMの活用を支援するなど、その活用スタイルに応じた導入が可能になっています。

小澤は、GitLabの進化の方向性も披露しました。GitLabは今後、DevSecOpsプラットフォームの概念を維持しつつ、多様なAgentic AI（自律的に行動し、目標達成のために自ら判断や行動を行うAI）の登場を前提に、それらをオーケストレーションする製品という立ち位置へと飛躍しようとしています。

全工程・全業務へのAI適用を目指す

左からGitLab合同会社 Japan Country Manager 小澤正治、株式会社みんなの銀行取締役常務執行役員CIO 宮本昌明氏

AI活用について宮本氏は、「われわれは、他社より遅れていると認識しています」と現状を厳しく評価します。約1年前からGemini Code Assistの検証をはじめ、現在は「ゼロからのコード生成」を目指し、エディタ、エージェント、プロバイダー、LLMの組み合わせを検討中。AI活用の範囲は、GitLabのコンセプトと一致しており、コード生成だけでなく、設計、ドキュメント作成、テストコード作成・実行など、全工程・全業務へのAI適用を目指しています。

宮本氏は、AI導入の留意点について、「AIガバナンスが大切になります。どこにAIを導入し、だれに使わせ、どこまでの権限を与えるべきかを規定しなければなりません」と話します。AIでフルに自動化し、AIの出した結果を盲目的に信じてしまうと、脆弱性のあるコードが生成され、セキュリティリスクが発生する可能性があります。また、著作権侵害にも注意を払う必要があります。それらの対応策として、前者にはSASTなど、後者には侵害防止機能を持つAIやスキャンツールなどがありますが、ツールの挙動の確実性を含めた精査が必要になりそうです。

株式会社みんなの銀行取締役常務執行役員CIO 宮本昌明氏

機密データやソースコードの外部流出を阻止する開発体制も課題になります。ただ、宮本氏は現時点でローカルLLMの導入に否定的な立場です。「エンジニアは最新技術を求めています。ローカルLLMを導入すると、クラウドで提供されるAIほどの進化スピードを得られないことが問題で、エンジニアは最新の技術を使えない環境を喜びません。インプットは社内で保持し、ロジックのみを外部利用するなどの工夫が必要かもしれません」。

このように、さまざまな示唆を与えてくれた宮本氏の講演を受けて小澤は、「私たちの行動は、デジタルのタッチポイントが整備されたことで変わってきました。みんなの銀行のBaaSは、どんどん広がっていて、APIの種類も豊富ですから、知らず知らずのうちに使っている機会が増えてきそうです。GitLabは、これからもこのすばらしいサービスを、黒子として支えていきたいと考えています」とセッションを締めくくりました。

イベントで配られたノベルティ

GitLab 18.3 リリース

2025-08-22T00:00:00.000Z

本ブログは、GitLab 18.3 Releaseの抄訳です。内容に相違がある場合は、原文が優先されます。

Visual Studio向けDuo Agent Platform（ベータ版）と埋め込みビューを搭載したGitLab 18.3をリリース

このたび、GitLab 18.3のリリースを発表しました。このリリースでは、Visual Studio向けDuo Agent Platform（ベータ版）、埋め込みビュー、直接転送による移行、CI/CDジョブトークンの詳細な権限設定など、さまざまな機能が追加されました。

これらの機能は、今回のリリースに含まれる38以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。

GitLab 18.3には、GitLabコミュニティのユーザーから314件ものコントリビュートがありました。ありがとうございました！GitLabは誰もがコントリビュートできるプラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。

来月のリリースで予定されている内容を先取りするには、今後のリリースページをご覧ください。

今月の注目コントリビューターはAhmed Kashkoushさんです

18.3では、Ahmed Kashkoushさんを注目コントリビューターとして表彰いたします！

AhmedさんはこのGoogle Summer of Codeの参加を通じて、GitLab Web IDEに優れたコントリビュートをもたらしました。彼は長年のコミュニティからの要望に直接応える重要なGit操作を一貫して提供してきました。彼の5つの重要なマージリクエストには、コミットおよび強制プッシュ機能、更新確認メッセージ、コミット修正機能、ブランチ作成操作、ブランチ削除機能が含まれています。

新機能の実装に加え、AhmedさんはWeb IDEから既存のコミットを修正できる機能を追加しました。これは5年以上前にコミュニティから要望され、24の「いいね」を獲得していた機能です。彼の包括的なブランチ管理の実装により、Web IDEはローカル開発環境と機能的に同等に近づき、基本的なGit操作のためにインターフェース間を切り替える必要がなくなりました。Ahmedさんの作業は、Web IDEをより多くのデベロッパーに利用しやすくすることで、GitLabの「誰もがコントリビュートできる」というミッションの理念を形にしています。

AhmedさんをGoogle Summer of Codeプログラムを通じてメンターとしてサポートしたGitLabのスタッフフロントエンドエンジニアEnrique Alcántaraによってノミネートされました。彼は次のように述べています。「Ahmedさんは実際のユーザーの問題を解決することに献身的です。彼の作業は、専念するコントリビューターがGitLabのコア機能を改善する上でどれほどの影響を与えることができるかを示しています。」

Ahmedさんのコントリビュートは、オープンソース開発におけるメンターシップとコミュニティコラボレーションの力を示し、ローカルセットアップに関係なくGitLabをより使いやすくしています。

GitLab Web IDEへの素晴らしいコントリビュートを提供してくれたAhmedさんに感謝します！

GitLab 18.3でリリースされた主な改善点

Visual Studio向けDuo Agent Platform（ベータ版）

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

Visual Studio向けDuo Agent Platformのパブリックベータ版をリリースしました！このリリースにより、Visual StudioユーザーはDuo Agent Platformの高度なAI機能をIDE内で直接利用できるようになりました。

Duo Agent Platformは、ワークフローに2つの強力な機能をもたらします：

Agentic Chat：ファイルの作成と編集、パターンマッチングとgrepを使用したコードベースの検索、コードに関する質問への即座の回答など、会話型のタスクをVisual Studioから離れることなく素早く実行できます。
エージェントフロー：より大規模で複雑なタスクに、包括的な計画と実装サポートで取り組みます。エージェントフローは、イシュー、マージリクエスト、コミット、CI/CDパイプライン、セキュリティ脆弱性などのGitLabリソースを活用しながら、高レベルのアイデアをアーキテクチャとコードに変換するのに役立ちます。

どちらの機能も、ドキュメント、コードパターン、プロジェクト情報全体で高度な検索を提供し、簡単な編集から詳細なプロジェクト分析まで、シームレスに移行できるようサポートします。

今すぐVisual StudioでDuo Agent Platformベータ版をお試しいただき、開発ワークフローにおける新しいレベルの生産性とAI機能のサポートを体験してください。

ドキュメント
 エピック

埋め込みビュー（GLQLを活用）

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

このリリースで、GLQLを活用した埋め込みビューの一般提供を開始します。Wikiページ、エピックの説明、イシューコメント、マージリクエストなど、作業が行われる場所に直接、GitLabデータの動的でクエリ可能なビューを作成して埋め込むことができます。

埋め込みビューにより、チームは画面を切り替えることなく作業の進捗を一箇所で追跡できます。使い慣れた構文を使用してイシュー、マージリクエスト、エピック、その他の作業アイテムを検索し、カスタマイズ可能なフィールドとフィルタリングを備えたテーブルまたはリスト表示で結果を確認できます。

埋め込みビューは、静的なドキュメントをプロジェクトデータと同期を保つライブダッシュボードに変換し、チームがコンテキストを保ちながら、ワークフロー全体でコラボレーションを向上させることができます。

埋め込みビューの改善に向けたご意見やご提案を、ぜひフィードバックイシューよりお寄せください。

ドキュメント
 エピック

直接転送による移行

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

直接転送による移行が一般提供されるようになりました。GitLabインスタンス間でGitLabグループとプロジェクトを直接転送で移行するには、GitLab UIまたはREST APIを使用できます。

エクスポートファイルのアップロードによる移行と比較して、直接転送は：

大規模なプロジェクトでより確実に動作します。
ソースインスタンスと宛先インスタンス間のバージョンギャップが大きい移行をサポートします。
移行プロセスと結果に関するより良い洞察を提供します。

GitLab.comでは、直接転送による移行はデフォルトで有効になっています。GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者が機能を有効にする必要があります。

CI/CDジョブトークンのきめ細かい権限設定

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

パイプラインセキュリティがより柔軟になりました。ジョブトークンは、パイプライン内のリソースへのアクセスを提供する一時的な認証情報です。これまで、これらのトークンはユーザーから全権限を継承していたため、必要以上に広範なアクセス権限を持ってしまうことがありました。

新しいジョブトークンのきめ細かい権限設定機能により、ジョブトークンがプロジェクト内でアクセスできる特定のリソースを正確に制御できるようになりました。これにより、CI/CDワークフローで最小権限の原則を適用し、CI/CDジョブトークンでプロジェクトにアクセスする際に、ジョブがタスクを完了するための必要最小限のアクセスのみを付与できます。

パイプラインでの長期トークンへの依存を減らすために、詳細権限機能のさらなる拡充に積極的に取り組んでいます。

ドキュメント
 エピック

GitLab Duo Self-HostedでCode Reviewが利用可能に（ベータ版）

Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Self-HostedでGitLab Duo Code Reviewを使用できるようになりました。この機能はGitLab Duo Self-Hostedでベータ版として提供され、Mistral、Meta Llama、Anthropic Claude、OpenAI GPTモデルファミリーをサポートしています。

GitLab Duo Self-HostedでCode Reviewを使用して、データ主権を損なうことなく開発プロセスを加速させます。Code Reviewがマージリクエストをレビューすると、潜在的なバグを特定し、直接適用できる改善を提案します。Code Reviewを使用して、人間にレビューを依頼する前に変更を反復して改善します。

Code Reviewに関するフィードバックはイシュー517386までお寄せください。

ドキュメント
 イシュー

GitLab Duo Code Reviewのカスタム指示

SaaS: Premium、Ultimate、Duo Enterprise
Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Code Reviewのカスタム指示で、プロジェクト全体で一貫したコードレビュー標準を適用します。globパターンを使用して異なるファイルタイプに特定のレビュー基準を定義し、言語固有の規約が最も重要な場所に確実に適用されるようにします。

カスタム指示では、次のことが可能です：

チームのコードレビュー標準を記述する
globパターンを使用してファイル固有の指示を定義する
カスタム指示を参照した、明確にラベル付けされたフィードバックを確認する

リポジトリにカスタム指示を含む.gitlab/duo/mr-review-instructions.yamlファイルを作成するだけです。GitLab Duoは自動的にこれらの指示をレビューに組み込み、フィードバックを提供する際に特定の指示グループを引用します。

フィードバックイシューでご意見やご提案をお寄せいただき、この機能の改善にご協力ください。

ドキュメント
 イシュー

GitLab Duo Self-Hostedに独自のモデルを持ち込む（ベータ版）

Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Self-Hostedでは、GitLab Duo機能で使用する独自のモデルを持ち込むことができるようになりました。この機能はベータ版で、GitLab Duo Enterpriseをお使いのすべてのGitLab Self-Managedのお客様が利用できます。インスタンス管理者は、サポートされているGitLab Duo機能で使用する互換性のあるモデルを設定できます。

この機能により、GitLab Duo Self-Hostedの柔軟性は向上しますが、GitLabはすべてのGitLab Duo機能がすべての互換モデルで動作することをお約束できません。インスタンス管理者は、選択したモデルの互換性とパフォーマンスを検証してご確認いただく必要があります。なお、GitLabは、選択したモデルまたはプラットフォーム固有の問題については、GitLabからの技術サポートは提供されませんのでご了承ください。

ドキュメント
 イシュー

GitLab Duo Self-Hostedでハイブリッドモデルが選択可能に（ベータ版）

Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Self-HostedでGitLab AIベンダーモデルとプライベートに設定されたセルフホストモデルの組み合わせを使用できるようになりました。この機能はベータ版で、GitLab Self-ManagedですべてのGitLab Duo Enterpriseのお客様が利用できます。

GitLab Duo Self-Hostedのハイブリッドモデルにより、GitLab Self-Managedインスタンス管理者は、セルフホストモデルとセルフホストAIゲートウェイ、またはGitLab AIベンダーモデルとGitLabホストのAIゲートウェイを、機能ごとに選択できるようになりました。これにより、管理者はセキュリティとスケーラビリティの要件のバランスを取ることができます。ハイブリッドモデル選択に関するフィードバックを提供するには、イシュー561048をご覧ください。

ドキュメント
 エピック

コンプライアンスフレームワーク制御の違反の表示（ベータ版）

SaaS: Ultimate
Self-Managed: Ultimate

以前のコンプライアンス違反レポートは、グループ内のすべてのプロジェクトのマージリクエストアクティビティの全体的な概要を表示していました。検出可能なコンプライアンス違反は、職務分離の懸念に関連するもので、以下の内容でした：

マージリクエストの作成者が自分のマージリクエストを承認した場合を検出
マージリクエストが2つ未満の承認でマージされた場合を検出

しかし、ユーザーフィードバックにより、違反分類が分かりにくく、実際のコンプライアンス用途にうまく適合しないことが判明しました。

GitLab 18.3では、職務分離の範囲を超えて、コンプライアンスフレームワークのコンプライアンス制御と要件の違反を含むように違反レポートを大幅に強化しています。各カスタムコンプライアンスフレームワーク制御には、違反に関する詳細な情報を提供する関連監査イベントがあります。これには、誰が違反を犯したか、いつ発生したか、どのように修正するかといった内容が含まれ、ユーザー名とIPアドレス、さらに実行可能な修正提案も提供されます。

これらの改善により、コンプライアンスマネージャーは、組織が特定のコンプライアンスフレームワークに確実に準拠できるよう、より強力で関連性の高い情報を得られるようになります。非準拠を効果的に特定、修正、防止できるという安心感ももたらします。

新しいWeb IDEソースコントロール操作

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

本リリースでは、Web IDEに追加のソースコントロール機能が追加されました。ブラウザから離れることなく、Gitワークフローをより効率的に管理できます。ソースコントロールパネルで、次のことができるようになりました：

ブランチの作成と削除。
既存のブランチをベースとしてブランチを作成。
最後のコミットを修正して素早く修正。
インターフェースから直接変更を強制プッシュ。

これらの機能強化により、Git操作が指先で行えるようになります。利用可能な機能については、ソースコントロールを使用するをご覧ください。

ドキュメント
 エピック

GitLab CI/CDのAWS Secrets Managerサポート

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

AWS Secrets Managerに保存されたシークレットをCI/CDジョブで簡単に取得して使用できるようになりました。AWSとの新しい統合により、GitLab CI/CDを通じてAWS Secrets Managerと対話するプロセスが簡素化され、AWSのお客様のビルドとデプロイプロセスの合理化に役立ちます！

GitLabの共同開発プログラムを通じてこの機能の開発にご協力いただいたMarkus SiebertさんとHenry Sachsさんに感謝します！

ドキュメント
 エピック

カスタム管理者ロール

Self-Managed: Ultimate

カスタム管理者ロールは、GitLab Self-ManagedおよびGitLab Dedicatedインスタンスの管理エリアに詳細な権限をもたらします。管理者は、フルアクセスを付与する代わりに、ユーザーが必要とする特定の機能のみにアクセスできる専門的なロールを作成できるようになりました。この機能により、組織は管理機能に対する最小権限の原則を適用し、過剰な権限によるセキュリティリスクを削減しつつ、運用効率を向上させることができます。

ご質問がある場合、実装経験を共有したい場合、または潜在的な改善について当社のチームと直接関わりたい場合は、フィードバックイシューをご覧ください。

ドキュメント
 エピック

GitLab 18.3リリースに含まれるその他の改善点

エピックの担当者、マイルストーンなどを一括編集

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

グループ内でより多くのエピック属性を一括編集できるようになりました。ラベルに加えて、複数のエピックの担当者、ヘルスステータス、サブスクリプション、機密性、マイルストーンを一度に更新できます。

この機能強化により、複数のエピックに同じ変更を同時に適用できるため、大量のエピックの管理が効率化されます。

ドキュメント
 エピック

Wiki機能の強化

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

このリリースでは、3つの主要な改善によりWiki機能が強化されます：Wikiページへのサブスクライブ、ページ編集中のWikiコメントの表示、Wikiページコメントの並べ替えができるようになりました。

これらの機能強化により、チームはドキュメントでより効果的にコラボレーションできます：

コンテキスト内で直接コンテンツについて議論する。
改善や修正を提案する。
ドキュメントを正確かつ最新の状態に保つ。
知識と専門知識を共有する。

これらのアップデートにより、GitLab Wikiは直接のフィードバックとディスカッションを通じてプロジェクトと共に進化する生きたドキュメントとして活用できます。

ドキュメント
 エピック

浅いクローニングによるワークスペースの高速起動

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

ワークスペースは、起動時間を短縮するために浅いクローニングを使用するようになりました。初期化中、GitLabは完全なGit履歴ではなく、最新のコミット履歴のみをダウンロードします。ワークスペース起動後、Gitはバックグラウンドで浅いクローンを完全なクローンに変換します。

この機能は新しいワークスペースすべてに自動適用され、設定は不要で、開発ワークフローに影響を与えません。

ドキュメント
 イシュー

Kubernetes 1.33サポート

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLabはKubernetesバージョン1.33に完全対応しました。アプリをKubernetesにデプロイする場合、接続クラスターを最新バージョンにアップグレードして、機能をすべて利用できます。

詳細については、GitLab機能でサポートされているKubernetesバージョンをご覧ください。

ドキュメント
 イシュー

簡潔なDASTジョブ出力

SaaS: Ultimate
Self-Managed: Ultimate

GitLab 18.3では、動的解析セキュリティテストのジョブ出力が改善されました。

改善されたジョブ出力は、スキャン結果の理解や、失敗のトラブルシューティングに役立つ、明確で整理された情報を提供します。

ジョブ出力の各セクションは簡潔で直感的であり、出力の下部にトラブルシューティングドキュメントへのリンクがあります。簡潔なジョブ出力を上書きするには、DAST設定でDAST_FF_DIAGNOSTIC_JOB_OUTPUT: "true"を設定します。

ドキュメント
 エピック

ライセンス情報のユーザー定義ソース

SaaS: Ultimate
Self-Managed: Ultimate

ユーザーは、ライセンス情報の優先ソース（GitLabライセンスデータベースまたはCycloneDX SBOMレポート）を選択できるようになりました。これにより、オープンソース依存関係のライセンス情報取得がより柔軟になります。ライセンス情報のソースを指定する場合は、セキュリティ設定UIで選択できます。デフォルトでは、ライセンス情報のソースとしてSBOMデータを使用します。

ドキュメントイシュー

脆弱性レポートでOWASP 2021によるグループ化

SaaS: Ultimate
Self-Managed: Ultimate

プロジェクトとグループの脆弱性レポートで、脆弱性をOWASP Top 10 2021カテゴリでグループ化できるようになりました。GitLab.comおよびGitLab Dedicatedインスタンスでのみ利用可能です。

ドキュメント
 イシュー

セキュリティポリシー監査イベント

SaaS: Ultimate
Self-Managed: Ultimate

GitLab Ultimateは、セキュリティポリシー管理のための包括的な監査イベントが利用できるようになり、各セキュリティポリシープロジェクト内でイベントが整理、一元化されます。

セキュリティチームは次のことができるようになります：

詳細なメタデータでポリシーのすべての変更を追跡する。
スキャンとパイプライン実行の失敗を含む、実施の失敗を監視する。
スキップされたスキャン実行とパイプライン実行パイプラインを監視する。
ポリシー違反でマージされたMRを含む、各プロジェクト内でのポリシー違反を検出する。
制限を超えた場合にアラートを受け取る。
ポリシー設定エラーを検出する。
大量処理向けストリーミング専用オプションを使用する。

新しい監査イベントには以下が含まれます：

security_policy_create
security_policy_delete
security_policy_update
security_policy_merge_request_merged_with_policy_violations
security_policy_yaml_invalidated
security_policies_limit_exceeded
security_policy_violations_detected（ストリーミングのみ）
security_policy_pipeline_failed（ストリーミングのみ）
security_policy_pipeline_skipped（ストリーミングのみ）
merge_request_branch_bypassed_by_security_policy

この機能強化により、ポリシーの変更、設定エラー、実施ギャップを把握できるようになり、セキュリティ体制が強化され、より迅速なインシデント対応と徹底的な監査機能が可能になります。

ドキュメント
 エピック

サービスアカウントの追加メール設定オプション

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

デフォルトでは、GitLabが新しいサービスアカウント用に自動的にメールアドレスを生成します。今回のアップデートにより、組織はUIでサービスアカウントにカスタムメールアドレスを設定できるようになりました。以前は、カスタムメール設定はサービスアカウントAPIを通じてのみ可能でしたが、この改善により、組織は通知を指定されたメールアドレスにより確実に配信できます。

ドキュメント
 イシュー

インスタンスレベルのコンプライアンスとポリシー管理（ベータ版）

Self-Managed: Ultimate

エンタープライズユーザーは、複数のトップレベルグループ全体でコンプライアンスフレームワークとセキュリティポリシーを管理したいと考えています。これは、インスタンス内のすべてのグループが次の場合によくあります：

同じコンプライアンスフレームワークを共有している（例：グループ内のすべてのプロジェクトがISO 27001標準に準拠する必要がある）
同様のポリシーを実施している（例：すべてのグループで同じパイプライン実行ポリシーを共有している）

GitLab 18.3では、GitLab Self-Managedインスタンス向けにコンプライアンスとセキュリティポリシー管理がベータ版で利用可能になりました。単一のトップレベルグループからコンプライアンスフレームワークとセキュリティポリシーを作成、設定、割り当て、GitLab Self-Managedインスタンス全体の他のすべてのトップレベルグループに適用できます。

コンプライアンスとセキュリティポリシーのトップレベルグループを使用することで、コンプライアンスフレームワークとセキュリティポリシーを管理および編集できる信頼できる単一の情報源が確立されます。グループ管理者は、これらのコンプライアンスフレームワークとセキュリティポリシーをそれらのグループ内のすべてのプロジェクトに適用できます。

選択したトップレベルのコンプライアンスとセキュリティポリシーグループから主要なフレームワークとポリシーを管理することにより、GitLab Self-Managedインスタンス全体で主要なコンプライアンスとセキュリティ要件の管理、実施が簡素化されます。ただし、各グループは、固有の状況やワークフローに対処するために、独自のコンプライアンスフレームワークとセキュリティポリシーを作成する権限は維持されます。

この機能は、GitLab Self-Managed向けに提供されています。GitLab.comおよびGitLab Dedicatedでは、既に単一のトップレベルグループまたはネームスペース内でポリシーを一元的に管理可能です。

ドキュメント
 エピック

SAML SSOのセッションタイムアウト属性のサポート

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

GitLabは、アイデンティティプロバイダー（IdP）からのSAMLアサーションに含まれるSessionNotOnOrAfter属性を自動的に検出、適用するようになりました。この属性が存在する場合、GitLabはユーザーセッションをIdPによって指定された時刻に期限切れに設定し、組織全体で統一されたセッション管理を実現します。設定変更は不要で、 IdPが属性を提供すれば、GitLabが自動的に指定された有効期限を適用します。

ドキュメント
 イシュー

SSHキーのセキュリティ警告

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLabは、ユーザーが弱いSSHキーをアップロードした際にUIにセキュリティ警告を表示するようになりました。この警告は、古いキータイプまたは不十分なビット長（2048ビット未満）のキーに対して表示されます。この変更により、SSHキーのセキュリティベストプラクティスをユーザーに周知し、より強固な暗号キーの利用を促進します。

ドキュメント
 イシュー

GitLab Duo Self-Hostedで使用可能なモデルの追加

Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Enterpriseをご利用のGitLab Self-Managedのお客様は、GitLab Duo Self-HostedでAnthropic Claude 4を利用できるようになりました。Claude 4はAWS Bedrockでサポートされています。また、オープンソースのOpenAI GPT OSS 20Bと120Bが実験的モデルとして追加され、vLLM、Azure OpenAI、AWS Bedrockで利用可能です。これらのモデルをGitLab Duo Self-Hostedで使用することに関するフィードバックは、イシュー523918をご覧ください。

ドキュメント
 イシュー

マイワークのグループ向け新しいナビゲーション体験

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

マイワークのグループ概要を大幅に改善しました。これにより、グループの発見とアクセス方法が効率化されます。新しいタブ付きインターフェースでは、メンバータブでアクセス可能なグループを包括的に表示し、無効タブで削除保留中のグループを確認できます。また、適切な権限を持つユーザー向けにリスト表示で編集と削除アクションを追加し、グループ管理を効率化しました。これらの改善により、重要なグループの検索と管理がより容易になります。

新しいナビゲーションシステムの利用体験について、エピック18401にご意見をお寄せください。フィードバックをお待ちしております！

ドキュメント
 イシュー

GitLab Pagesサイトの一意のドメインのデフォルトを制御

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

管理者は、新しいGitLab Pagesサイトの一意のドメインに関するデフォルト動作を設定できるようになりました。デフォルトでは、新しいPagesサイトは、サイト間のCookie共有を防ぐために一意のドメインURL（例：my-project-1a2b3c.example.com）を使用します。

インスタンス向けのこの新しい設定により、新しいPagesサイトをデフォルトでパスベースのURL（例：my-namespace.example.com/my-project）を使用するように設定できます。これにより、組織はGitLab Pagesの動作を自社のワークフローやセキュリティ要件に合わせることができます。

ユーザーは個々のプロジェクトでこの設定を上書きでき、既存のPagesサイトは影響を受けません。

ドキュメントイシュー

OAuthアプリでSSO認証をサポート

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

OAuthアプリケーションが組織のシングルサインオン要件とシームレスに統合できるようになりました。以前は、ユーザーは最初にGitLabで、次にSSOで認証するという2段階認証が必要で、不要な手間と複雑さが生じていました。

現在、OAuthアプリケーションは、認証リクエストでパラメーターを指定し、必要に応じてSSO認証を自動的に開始できます。これにより以下が提供されます：

ユーザー向けの統一された認証体験
組織のSSOポリシーへの自動準拠
すべてのGitLab統合全体で一貫したセキュリティ
パラメーター追加だけのデベロッパー向けの簡単な実装

OAuth統合は、セキュリティを維持しながら煩雑な認証ワークフローを排除し、SSOポリシーを自動的に適用するようになりました。

ドキュメントイシューイシュー

GitLab Runner 18.3

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLab Runner 18.3も本日リリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。

バグ修正：

新機能：

すべての変更の一覧は、GitLab RunnerのCHANGELOGで確認できます。

ドキュメント

GitLab管理のOpenTofuおよびTerraform状態用の新しいCLIコマンド

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLab CLI（glab）に、GitLab管理のOpenTofuおよびTerraform状態を支援するための新しいトップレベルコマンドopentofuが含まれるようになりました。opentofuコマンドは、terraformおよびtfコマンドのエイリアスとしても使用できます。

以下のコマンドが追加されました：

glab opentofu init：状態バックエンドをローカルで初期化します
glab opentofu state list：プロジェクト内のすべての状態を一覧表示します
glab opentofu state download：最新の状態または特定のバージョンをダウンロードします
glab opentofu state delete：状態全体または特定のバージョンを削除します
glab opentofu state lock：状態をロックします
glab opentofu state unlock：状態のロックを解除します

opentofuコマンドで状態を管理するには、glab 1.66以降が必要です。

ドキュメント
 イシュー

依存関係スキャンアナライザーのファイル場所情報の改善

SaaS: Ultimate
Self-Managed: Ultimate

依存関係をそのソースまで追跡できることは、特に脆弱性の修正にとって重要です。以前は、依存関係スキャンアナライザーが期限切れで削除されるジョブアーティファクトにリンクすることがあり、依存関係のソースまで追跡することが困難でした。本リリースで、依存関係スキャンアナライザーが、依存関係を導入したプロジェクトファイルにリンクできるようになりました。このオプションを有効にすると、依存関係リストと脆弱性レポートのリンクが確実に利用可能になります。ユーザーは、依存関係スキャンジョブでDS_FF_LINK_COMPONENTS_TO_GIT_FILES=trueを設定することで、この機能を有効にできます。

ドキュメント
 イシュー

API経由でパイプライン実行ポリシーにCI/CD設定へのアクセスを付与

SaaS: Ultimate
Self-Managed: Ultimate

プロジェクトREST APIを使用して、新しいspp_repository_pipeline_accessフィールドでセキュリティポリシープロジェクトのパイプライン実行ポリシー設定をプログラムで有効または無効にできるようになりました。以前は、この設定はGitLab UIでのみ管理できました。この機能強化により、次のことができるようになりました：

現在のパイプライン実行ポリシーステータスをGETする。
設定をプログラムで有効または無効にするためにPUTする。

この改善により、大規模でセキュリティポリシーを管理するチームにとって、より優れた自動化と統合ワークフローが実現されます。

ドキュメント
 イシュー

スキャン実行ポリシーテンプレート

SaaS: Ultimate
Self-Managed: Ultimate

スキャン実行ポリシーテンプレートは、一般的なユースケースに基づいてスキャン実行ポリシーを素早く作成するのに役立ちます。以下の3つのテンプレートから選択できます：

マージリクエストセキュリティ
スケジュールされたスキャン
リリースセキュリティ

テンプレートを選択したら、そのテンプレートで有効にするGitLabセキュリティスキャンを選択して、すぐに開始します。より高度なユースケースがある場合は、カスタム設定に切り替えて、特定のブランチパターン、パイプラインソースなどでポリシーを拡張できます。

ドキュメント
 エピック

承認ポリシーのサービスアカウントとアクセストークンの例外

SaaS: Ultimate
Self-Managed: Ultimate

新しいサービスアカウントとアクセストークンの例外機能により、必要に応じてマージリクエスト承認ポリシーをバイパスできる特定のサービスアカウントとアクセストークンを指定できるようになりました。これにより、セキュリティコントロールを維持しながら、既知の自動化の摩擦を解消します。

主要な機能：

自動化ワークフローサポート：CI/CDパイプライン、プルミラーリング、自動バージョン更新のために承認要件をバイパスするように、特定のサービスアカウント、ボットユーザー、グループアクセストークン、プロジェクトアクセストークンを設定します。サービスアカウントは、人間のユーザーに対する制限を維持しながら、承認されたトークンを使用して保護されたブランチに直接プッシュできます。
緊急アクセスと監査：重要なインシデントのブレークグラスシナリオを有効にし、包括的な監査証跡を提供します。すべてのバイパスイベントは、コンテキストと理由を含む詳細な監査ログを生成し、停止中またはセキュリティ修正時の迅速な対応を可能にしながら、コンプライアンス要件をサポートします。
GitOps統合：リポジトリミラーリング、外部CIシステム（Jenkins、CloudBees）、自動変更ログ生成、GitFlowリリースプロセスなど、一般的な自動化の課題を解決します。サービスアカウントは、特定のプロジェクトとブランチにスコープされたトークンベースのアクセスで必要最小限の権限を受け取ります。

この機能強化により、ガバナンスコントロールを維持しながら、現代のDevOps自動化のニーズに対して厳格なセキュリティポリシーの適用が維持され、カスタムの回避策が不要になります。

ドキュメント
 エピック

エンタープライズユーザーの機能強化

SaaS: Premium、Ultimate

GitLab 18.3では、ユーザープライバシーとライフサイクル管理に対する組織の制御を強化するエンタープライズユーザー機能強化が導入されます。

グループオーナーは、ユーザーAPIを使用してネームスペース内のエンタープライズユーザーを削除できるようになりました。この破壊的なアクションは、ユーザーの貢献のリンクを解除し、それらをシステム全体のGhostユーザーに関連付けます。これらのオプションは、自動SCIMインポートで誤って作成されたユーザーをクリーンアップする場合や、ユーザー名とメールを再利用する必要があるフェデレーション環境を管理したりする場合に特に有用です。

さらに、組織はエンタープライズユーザーのメールをユーザープロファイルで非表示にできるようになり、すべてのエンタープライズユーザーに対してより広範なメールプライバシーの実施を提供します。

ドキュメント
 エピック

強化された管理エリアプロジェクトリスト

Self-Managed: Free、Premium、Ultimate

より一貫した体験をGitLab管理者に提供するために、管理者エリアプロジェクトリストをアップグレードしました：

削除保護の遅延：プロジェクトの削除は、GitLab全体で使用されているのと同じ安全な削除フローに従うようになり、偶発的なデータ損失を防ぎます。
より高速なインタラクション：ページのリロードなしでプロジェクトのフィルター、並べ替え、ページ分割が可能になり、より応答性の高い体験を提供します。
一貫したインターフェース：プロジェクトリストは、GitLab全体の他のプロジェクトリストの外観と動作に統一されました。

このアップデートにより、管理者の体験がGitLabデザイン標準に沿ったものになり、データを保護するための重要な安全機能が追加されます。プロジェクト管理の今後の機能強化は、プラットフォーム全体のすべてのプロジェクトリストに自動的に反映されます。

ドキュメント
 エピック

実験的機能

GitLabモデルコンテキストプロトコルサーバー

GitLabモデルコンテキストプロトコル（MCP）サーバーにより、AIアプリケーションがGitLabインスタンスに安全に接続できるようになります。MCPサーバーを設定すると、Claude Desktop、Cursor、その他のMCP対応アプリケーションなどのAIアシスタントが、GitLabデータにアクセスし、ユーザーに代わってアクションを実行できます。このリリースには、計画イシュー、マージリクエスト、CIパイプラインジョブと連携するツールが含まれており、今後のマイルストーンでサポートツールを拡張していく予定です。

MCPサーバーは、AIツールに対して標準化された方法を提供します：

GitLabプロジェクト情報にアクセスする
イシューとマージリクエストデータを取得する
GitLab APIと安全に連携する
AIアシスタントを通じてGitLab固有の操作を実行する

GitLabのMCPサーバーはリモートで実行されるため、ローカルにインストールまたは実行する必要はありません。アップデートは自動的に適用されます。

実験的機能を有効にする方法を含む詳細については、GitLab MCPサーバーのドキュメントをご覧ください。

GitLab Duo CLIエージェント（ベータ版）

GitLab Duo CLIエージェントを素早く作成し、Claude Code、OpenAI Codex、Amazon Q、Google Gemini CLI、OpenCode AIコーディングアシスタントと統合できるようになりました。このベータ機能は、すべてのGitLab Duo Enterpriseのお客様が利用でき、選択したプロバイダー用に独自のAPIキー（BYOK）を持ち込む必要があります。

イシュー、エピック、またはマージリクエストで、作成したサービスアカウントユーザーをタグ付けすることで、CLIエージェントにタスクの完了を依頼できます。タグ付けされると、そのエージェントに接続された統合コーディングアシスタントがトリガーされ、自動CI/CDパイプラインが実行され、タスクが完了します。マージ可能な変更またはインラインコメントとして応答を受け取ります。

この仕組みによりブランチ保護と承認ルールを尊重しながら、セキュリティ、コスト管理、インフラストラクチャガバナンスに関する組織のニーズを満たしつつ、CLIエージェントの力をGitLabに直接もたらします。今後のイテレーションでは、GitLab管理のAPIキーを使用してCLIエージェントをコーディングアシスタントとネイティブに統合できるようになります。

GitLab Duo CLIエージェントの使用に関するフィードバックは、イシュー557820をご覧ください。

バグ修正、パフォーマンスの改善、UIの改善

18.3で提供されたすべてのバグ修正、パフォーマンスの強化、UI改善を確認するには、以下のリンクをクリックしてください。

非推奨事項

削除された機能と破壊的な変更

cert-manager Helmチャートのアップデート

変更履歴

変更内容をすべて表示するには、次のページから変更履歴を確認してください。

インストール

GitLabを新規にインストールする場合は、GitLabのダウンロードページをご覧ください。

更新事項

更新ページをご覧ください。

ご不明な点がある場合

ご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、GitLabフォーラムにアクセスして質問を投稿してください。

GitLabサブスクリプションプラン

Free ユーザー向けの永久無料機能を提供
Premium チームの生産性と調整を強化
Ultimate 組織全体のセキュリティ、コンプライアンス、プランニングに対応

GitLabのすべての機能を無料でお試しいただけます。

監修：ソリスジェレズ / Jerez Solis @jerezs （GitLab合同会社ソリューションアーキテクト本部ソリューションアーキテクト）

過去の日本語リリース情報

GitLab 18.3: ソフトウェアエンジニアリングにおけるAIオーケストレーションの拡張

2025-08-21T00:00:00.000Z

GitLabは現在、ソフトウェアライフサイクルのあらゆる段階を統合する包括的なDevSecOpsプラットフォームです。その基盤の上に、世界初のソフトウェアエンジニアリング向けAIネイティブプラットフォームへの進化を進めています。GitLabでは、ソフトウェアエンジニアリングの未来は本質的に人間とAIのコラボレーションにあると考えており、すべてのGitLabユーザーに最高のAI機能を提供したいと考えています。

この変革は、他のAI開発ツールが行っていることを超えた3つの異なるレイヤーで起こっています：

第一に、記録システムです。 統合データプラットフォームは、最も価値のあるデジタル資産を保持しています。これには、ソースコードと知的財産だけでなく、プロジェクト計画、バグバックログ、CI/CD構成、デプロイメント履歴、セキュリティレポート、コンプライアンスデータにまたがる豊富な非構造化データが含まれます。これにより、GitLab環境内に安全に保持され、汎用エージェントや大規模言語モデルでは利用できない、文脈データの宝庫が作成されます。

第二に、ソフトウェアコントロールプレーンとして機能します。 Gitリポジトリ、REST API、およびエンドツーエンドのソフトウェアデリバリーを支えるWebhookベースのインターフェースを通じて、最も重要なビジネスプロセスをオーケストレーションします。多くの顧客は、これを重要なビジネスプロセスが日常的に依存するティア0の依存関係として考えています。

第三に、強力なユーザーエクスペリエンスを提供します。 ほとんどのエンジニアリングチームの速度を低下させる負荷の高い頭の切り替えを排除するのに役立つ統合インターフェースを提供します。1つのプラットフォームで完全なライフサイクルの可視性とコラボレーションツールを提供することで、5,000万人以上の登録ユーザーと広大なコミュニティが、仕事を成し遂げるためにGitLabを活用しています。この専門知識により、GitLabは、既存の信頼できるワークフローを維持しながら、チームの生産性を増幅する直感的な人間とAIのコラボレーションを先駆的に開拓する独自の立場にあります。

あらゆるレイヤーにAIをネイティブに統合してプラットフォームを拡張

GitLab Duo Agent Platformは、これら3つのレイヤーすべてを統合し、拡張します。拡張性と相互運用性のために設計されており、顧客やパートナーがさらに価値を創造するソリューションを構築できるようにします。オープンプラットフォームアプローチは、3つのレイヤーすべてで既存のスタックに深く統合されながら、外部AIツールやシステムとのシームレスな接続性を重視しています。

まず、ナレッジグラフで統合データプラットフォームを拡張しています。これは、コードと他のすべての非構造化データをインデックス化して結び付け、エージェントアクセスに特化して最適化されたものです。AIはコンテキストで成長し、これによりエージェントによる推論と推論を加速するだけでなく、より低コストで高品質なエージェントの成果を提供できると考えています。
第二に、既存のコントロールプレーンに重要なオーケストレーションレイヤーを3つの異なる部分で追加しています：エージェントとフローがGitLab SDLCイベントのサブスクライバーとして登録できるようにし、目的別のマルチエージェントフローを可能にする新しいオーケストレーションエンジンを構築し、比類のない相互運用性のためにMCPと標準プロトコルを介してGitLabツール、エージェント、フローを公開します。
最後に、ソフトウェア開発ライフサイクル全体にわたってファーストクラスのエージェントとエージェントフローを提供するためにGitLabエクスペリエンスを拡張しています。エージェントに非同期タスクを割り当て、コメントで@メンションし、ワークフローに固有のコンテキストでカスタムエージェントを作成できるようになります。さらに重要なことに、GitLabは、サードパーティエージェントの豊富なエコシステムのロックを解除しながら、開発のあらゆる段階でネイティブエージェントを出荷しています。これにより、エージェントが人間のチームメイトと同じように自然に作業できる真の人間とAIのコラボレーションが生まれます。

このビデオで18.3以降の新機能をご覧いただくか、以下をお読みください。

GitLab 18.3の新機能

18.2では、ソフトウェア開発ライフサイクル全体でデベロッパーと協力する専門的なAIエージェントと、ソフトウェア開発フローを導入しました。これは、複数のエージェントをオーケストレーションして、エンドツーエンドでコード変更を計画、実装、テストする強力な機能です。

GitLab 18.3では、拡張された統合と相互運用性、より多くのフロー、そしてソフトウェア開発ライフサイクル全体でのコンテキスト認識の強化を導入しています。

拡張された統合と相互運用性

ファーストパーティのGitLabエージェントとサードパーティエージェントの豊富なエコシステムの両方を通じて、包括的なAI拡張性を提供しており、すべてがプロジェクトコンテキストとデータへの完全なアクセスを持っています。このアプローチは、これらのエージェントとGitLabのコアプラットフォーム間の高度に統合されたオーケストレーションを通じて好みのツールを選択する柔軟性を提供しながら、ネイティブのGitLabワークフローとガバナンスを維持します。チームは、主要な統合、監視、ユーザーエクスペリエンスの利点を維持しながら、強化されたAI機能を獲得します。

MCPサーバー - ユニバーサルAI統合： GitLabのMCP（モデルコンテキストプロトコル）サーバーにより、AIシステムはGitLabプロジェクトと開発プロセスに直接安全に統合できます。この標準化されたインターフェースにより、カスタム統合のオーバーヘッドが排除され、Cursorを含むAIツールが既存のGitLab環境内でインテリジェントに動作できるようになります。18.3に含まれるツールの完全なリストについては、ドキュメントをご覧ください。これは始まりに過ぎません。18.4では追加のツールが計画されています。

注：サードパーティエージェントは、GitLab Premiumベータ機能であり、GitLab Duo Enterpriseの顧客が評価のためにのみ利用できます。

「GitLabワークフローをCursorに直接持ち込むことは、デベロッパーの摩擦を減らすための重要なステップです。頭の切り替えの必要性を最小限に抑えることで、チームはコーディング環境を離れることなく、イシューのステータスをチェックし、マージリクエストをレビューし、パイプラインの結果を監視できます。この統合は共有顧客にとって自然な選択であり、デベロッパーの生産性を継続的に向上させるために、GitLabとの長期的なパートナーシップを楽しみにしています。」

- Ricky Doar、Cursor フィールドエンジニアリング副社長

「GitLabのMCPサーバーとCLIエージェントサポートは、Amazon Qが開発ワークフローと統合するための強力な新しい方法を作成します。Amazon Q DeveloperはGitLabのリモートMCPインターフェースを介して直接接続できるようになり、チームはイシューやマージリクエストでAmazon Q CLIを@メンションするだけで開発タスクを委任できます。これらの統合に組み込まれた堅牢なセキュリティとガバナンス機能により、企業は開発標準を維持しながら、AIコーディングツールを活用する自信を得ることができます。GitLabとのパートナーシップは、AIエコシステムを拡大し、デベロッパーが作業する場所でインテリジェントな開発ツールにアクセスできるようにするというAWSの継続的なコミットメントを示しています。」

- Deepak Singh、AWS デベロッパーエージェントおよびエクスペリエンス担当副社長

Claude Code、Codex、Amazon Q、Google Gemini、opencode（独自のキーを持参）のCLIエージェントサポート： 18.3では、イシューやマージリクエストでエージェントを直接@メンションすることで、チームが日常的な開発作業を委任できる統合を導入しています。デベロッパーがこれらのAIアシスタントにメンションすると、周囲のコンテキストとリポジトリコードを自動的に読み取り、レビュー可能なコード変更またはインラインコメントでユーザーのコメントに応答します。これらの統合では、それぞれのAIプロバイダー用に独自のAPIキーを持参する必要があり、適切な権限と監査証跡を維持しながら、すべてのやり取りをGitLabのインターフェース内でネイティブに保持します。

注：サードパーティエージェントは、GitLab Premiumベータ機能であり、GitLab Duo Enterpriseの顧客が評価のためにのみ利用できます。

「Claude CodeをGitLabに直接持ち込むことで、何百万人ものデベロッパーがすでに毎日コラボレーションしてコードを出荷している場所にAIアシスタンスを配置します。イシューやマージリクエストでClaudeを直接メンションする機能により、人間の監視とレビュープロセスで品質を維持しながら、摩擦が除去されます。このアップデートにより、Claude Codeの機能がチームが作業するより多くの場所に提供され、AIをデベロッパーワークフローの自然な一部にします。」

- Cat Wu、Claude Code プロダクトリード、Anthropic

「GitLab 18.3の新しいエージェント統合により、既存のワークフロー内でopencodeを使用できます。イシューやマージリクエストでopencodeを@メンションすると、CIパイプラインでエージェントが実行されます。この方法でopencodeを設定して実行する機能は、オープンソースコミュニティが本当に評価する統合のタイプです。」

- Jay V.、CEO、opencode

すべてのPremiumおよびUltimate顧客が利用できるVisual Studio IDEおよびGitLab UIのエージェントチャットサポート： 18.3では、GitLabの完全な開発ライフサイクルデータにアクセスするためにツール間で頭の切り替えをする必要がなくなりました。強化された統合により、GitLab DuoのフルパワーがGitLab UIとIDEにもたらされ、JetBrainsとVS Codeからのサポートが拡張され、現在はVisual Studioも含まれています。これにより、デベロッパーは好みの環境内で豊富なプロジェクトコンテキスト、デプロイメント履歴、チームコラボレーションデータに直接アクセスしながら、フローに留まることができます。
拡張されたAIモデルサポート： GitLab Duo Self-Hostedは追加のAIモデルをサポートするようになり、チームにAI支援開発ワークフローでより柔軟性を提供します。データセンターのハードウェア上でvLLMを介して、またはプライベートクラウドのAzure OpenAIやAWS Bedrockなどのクラウドサービスを介して、オープンソースのOpenAI GPTモデル（20Bおよび120Bパラメータ）をデプロイできるようになりました。さらに、AnthropicのClaude 4はAWS Bedrockで利用可能です。

新しい自動開発フロー

GitLabのフローは、複数のAIエージェントを事前構築された指示で調整し、時間のかかる日常的なタスクを自律的に処理するため、デベロッパーは最も重要な作業に集中できます。

GitLab 18.3には2つの新しいフローが付属しています：

概念から完成まで数分でコードを自動生成するイシューからMRへのフロー： このFlowは、要件を分析し、包括的な実装計画を準備し、レビュー可能な本番グレードのコードを生成するためにエージェントを調整することにより、イシューを実行可能なマージリクエスト（MR）に自動的に変換します。アイデアを数時間ではなく数分でレビュー可能な実装に変えるのに役立ちます。

シームレスな移行インテリジェンスのために構築されたCI File変換フロー： CI File変換フローは、エージェントが既存のCI/CD構成を分析し、完全なパイプライン互換性を持つGitLab CI形式にインテリジェントに変換することで、移行ワークフローを合理化します。これにより、CI構成をゼロから書き直す手動作業と潜在的なエラーが排除され、チームは自信を持ってデプロイメントパイプライン全体を移行できます。18.3にはJenkins移行のサポートが含まれています。将来のリリースでは追加サポートが計画されています。

インテリジェントなコードと検索

AIポイントソリューションは通常、分離されたコードスニペットへの限定的な可視性で動作しますが、GitLabのナレッジグラフは、より迅速でインテリジェントな応答を通知するための環境コンテキストをエージェントに提供します。

リアルタイムコードインテリジェンスのためのナレッジグラフ： 18.3では、GitLabのナレッジグラフがリアルタイムコードインデックスを提供し、より高速なコード検索を可能にし、より正確で文脈に沿った結果を提供します。コードベース全体にわたるファイル、依存関係、開発パターン間の関係を理解することにより、エージェントは人間のデベロッパーが発見するのに何時間もかかる洞察を提供するように設計されています。これは、ナレッジグラフに計画されている強力な機能のロックを解除する最初のステップにすぎません。

エンタープライズガバナンス

AIの透明性と組織のコントロールは、チームがAI搭載開発ツールを完全に採用することを妨げる可能性のある重要な課題であり、85%の経営幹部が、エージェント型AIが前例のないセキュリティ課題を生み出すことに同意しています。

18.3のこれらの新機能は、データガバナンス、コンプライアンス要件、AI意思決定プロセスへの可視性の必要性に関する懸念に対処するのに役立つため、組織は既存のセキュリティとポリシーフレームワーク内でAIを統合できます。

インテリジェンスを通じた透明性のためのエージェントインサイト： 組み込みのエージェント追跡により、エージェントの意思決定プロセスへの可視性が提供されます。ユーザーは、透明なアクティビティ追跡を通じてワークフローを最適化し、ベストプラクティスに従うことができます。

Self-Hosted向けGitLab Duoコードレビュー： これにより、厳格なデータガバナンス要件を持つ組織にGitLab Duoのインテリジェンスがもたらされ、チームが機密性の高いコードを管理された環境に保持できるようになります。
柔軟なAIデプロイメントのためのハイブリッドモデル構成： GitLab Duo Self-Hostedをご利用のお客様は、ローカルAIゲートウェイを介したセルフホステッドAIモデルとGitLabのAIゲートウェイを介したGitLabのクラウドモデルを組み合わせたハイブリッドモデル構成を使用できるようになり、さまざまな機能へのアクセスが可能になりました。

OAuthサポートによるセキュリティの強化： MCPサーバーには、完全なOAuth 2.0認証サポートが含まれるようになり、保護されたリソースと機密性の高い開発環境への安全な接続が可能になりました。この実装は、MCPのドラフトOAuth仕様に従い、認証フロー、トークン管理、動的クライアント登録を処理します。

Secure by Designプラットフォーム：スケールするガバナンス

真のプラットフォームセキュリティには、開発ライフサイクルのあらゆるレイヤーにわたるガバナンス原則の一貫した適用が必要です。AI採用を安全にするのと同じセキュリティの基本（最小権限アクセス、一元化されたポリシー管理、プロアクティブな監視、きめ細かい権限）は、凝集性のある多層防御アプローチを作成するために、SDLC全体に組み込まれる必要があります。

GitLab 18.3は、これらの新しいアップデートでソフトウェアサプライチェーン全体を保護するのに役立つ基盤的なコントロールを強化します：

カスタム管理者ロール： ブランケット管理アクセスを正確な最小権限コントロールに置き換える、きめ細かく目的に合わせた管理権限を提供します。セキュリティリスクを生み出すブランケット管理権限を付与する代わりに、組織は特定の機能に合わせたカスタマイズされたロールを作成できるようになりました。ランナーと監視を管理するプラットフォームチーム、ユーザー管理を処理するサポートチーム、ダッシュボードと使用統計にアクセスするリーダーシップなど。UIとAPIを介した完全なロールライフサイクル管理、監査ログ、自動生成されたドキュメントにより、この機能は運用効率を維持し、全体的なインスタンスセキュリティを向上させながら、真の最小権限管理を可能にします。
インスタンスレベルのコンプライアンスフレームワークとセキュリティポリシー管理： 組織は、標準化されたフレームワークとセキュリティポリシーをトップレベルグループに直接適用する権限を持つ専用のコンプライアンスグループを指定でき、すべてのサブグループとプロジェクトに自動的にカスケード適用されます。この一元化されたアプローチは、追加のローカルポリシーに対するグループの自律性を維持しながら、断片化されたポリシー管理のコンプライアンス採用ブロッカーを排除します。
強化された違反レポート： チームは、MR承認ルールに対して不正な変更が行われたとき、フレームワークポリシーに適切な承認がないとき、または時間ベースのコンプライアンスコントロールが違反されたときに、即座に通知を受け取るようになりました。違反を特定のコンプライアンスフレームワークコントロールに直接リンクすることで、チームはどの要件が違反されたかを正確に伝える実用的な洞察を得て、コンプライアンスを反応的なチェックボックスの演習から、開発とセキュリティワークフローのプロアクティブで統合された部分に変えます。
CI/CDジョブトークンのきめ細かい権限： 広範なトークンアクセスを、CI/CDジョブが実際に必要とする特定のAPIエンドポイントへのアクセスのみを付与する、きめ細かく明示的な権限に置き換えます。ジョブにプロジェクトリソースへのブランケットアクセスを許可する代わりに、チームはデプロイメント、パッケージ、リリース、環境、その他の重要なリソースに対する正確な権限を定義でき、攻撃対象領域と権限昇格の可能性を減らすことができます。
AWS Secrets Manager統合： AWS Secrets Managerを使用しているチームは、GitLab CI/CDジョブでシークレットを直接取得できるようになり、ビルドとデプロイプロセスが簡素化されます。シークレットは、OpenID Connectプロトコルベースの認証を使用してGitLab Runnerによってアクセスされ、ジョブログでの露出を防ぐためにマスクされ、使用後に破棄されます。このアプローチにより、変数にシークレットを保存する必要がなくなり、既存のGitLabおよびAWSベースのワークフローにクリーンに統合されます。Deutsche BahnおよびAWS Secrets Managerチームとの緊密な協力により開発されたこの統合は、実世界の課題を解決するためにユーザーと一緒にソリューションを構築するという当社のコミットメントを反映しています。

アーティファクト管理：ソフトウェアサプライチェーンの保護

アーティファクトが適切に管理されていない場合、小さな変更が大きな結果をもたらす可能性があります。可変パッケージ、上書きされたコンテナイメージ、ツール間で一貫性のないルールは、本番障害を引き起こし、脆弱性を招き、コンプライアンスギャップを作成する可能性があります。エンタープライズDevSecOpsにとって、安全で一元化されたアーティファクト管理は、ソフトウェアサプライチェーンを維持するために不可欠です。

18.3のエンタープライズグレードアーティファクト保護

包括的なパッケージ保護機能を基盤として、GitLab 18.3は重要な新機能を追加します：

Conanリビジョンサポート： 18.3の新機能であるConanリビジョンは、C++デベロッパーにパッケージの不変性を提供します。パッケージのバージョンを変更せずに変更を加えた場合、Conanはこれらの変更を追跡するための一意の識別子を計算し、チームがバージョンの明確性を維持しながら不変のパッケージを維持できるようにします。
強化されたコンテナレジストリセキュリティ： 18.2での不変コンテナタグのローンチ成功に続き、エンタープライズでの採用が進んでいます。不変ルールに一致するタグが作成されると、権限レベルに関係なく、誰もそのコンテナイメージを変更できなくなり、本番依存関係への意図しない変更を防ぎます。

これらの機能強化は、npm、PyPI、Maven、NuGet、Helmチャート、および汎用パッケージに対する既存の保護機能を補完し、プラットフォームチームがソフトウェアサプライチェーン全体で一貫したガバナンスを実装できるようにします。これは、安全な内部デベロッパープラットフォームを構築する組織にとって不可欠です。

スタンドアロンのアーティファクトソリューションとは異なり、GitLabの統合アプローチは、コードからデプロイメントまでのエンドツーエンドのトレーサビリティを提供しながら、複数のツールを使い分ける際の頭の切り替えを排除し、プラットフォームチームがソフトウェアデリバリーパイプライン全体で一貫したガバナンスを実装できるようにします。

埋め込みビュー：リアルタイムの可視性とレポート

GitLabプロジェクトの複雑さが増すにつれて、チームは作業ステータスへの可視性を維持するために、イシュー、マージリクエスト、エピック、マイルストーン間を移動することになります。課題は、頭の切り替えやフローを中断することなく、チームがプロジェクトの進行状況にリアルタイムでアクセスできるようにしながら、この情報を効率的に統合することにあります。 18.3でリアルタイム作業ステータスの可視性をローンチ 強力なGitLabクエリ言語（GLQL）を搭載したGitLab 18.3の埋め込みビューは、ライブプロジェクトデータをワークフローに直接もたらすことで、頭の切り替えを排除します：

動的ビュー： ページを読み込むたびに現在のプロジェクト状態で自動的に更新される、Markdownコードブロックのwikiページ、エピック、イシュー、マージリクエスト全体にライブGLQLクエリを挿入します。
文脈に応じたパーソナライゼーション： ビューは、手動設定なしで、表示している人に関連する情報を表示するために、currentUser()やtoday()などの関数を使用して自動的に適応します。
強力なフィルタリング： 担当者、作成者、ラベル、マイルストーン、ヘルスステータス、作成日など、25以上のフィールドでフィルタリングします。
表示の柔軟性： カスタマイズ可能なフィールド選択、アイテム制限、並べ替え順序を使用して、データをテーブル、リスト、または番号付きリストとして表示し、ビューを集中的で実行可能に保ちます。

断片化されたプロジェクト管理アプローチとは異なり、埋め込みビューは、リアルタイムの可視性を提供しながらワークフローの継続性を維持するように設計されており、チームが複数のツールやインターフェース間で焦点を失ったり切り替えたりすることなく、情報に基づいた意思決定を行えるようにします。

GitLab 18.3の最新機能について詳しく見る。

今すぐ始める

GitLab 18.3は、GitLab.comおよびセルフマネージド環境のGitLab PremiumおよびUltimateユーザーが今すぐ利用できます。

GitLab Dedicatedのお客様は現在18.2にアップグレードされており、来月GitLab 18.3でリリースされた機能を使用できるようになります。

ソフトウェアエンジニアリングの未来を体験する準備はできましたか？GitLab Duoのベータ版と実験的機能を有効にして、完全な開発コンテキストを理解するAIエージェントとのコラボレーションを開始してください。

GitLabは初めてですか？無料トライアルを今すぐ開始して、世界で最も包括的なDevSecOpsプラットフォームを通じてオーケストレーションされた、人間とAIのコラボレーションがソフトウェアエンジニアリングの未来である理由を発見してください。

このブログ投稿には、1933年証券法第27A条および1934年証券取引所法第21E条の意味における「将来を見据えた声明」が含まれています。このブログ投稿に含まれる将来を見据えた声明に反映された期待は合理的であると信じていますが、実際の結果または成果が将来を見据えた声明によって表現または暗示された将来の結果または成果と実質的に異なる原因となる可能性のある既知および未知のリスク、不確実性、仮定、およびその他の要因の対象となります。

実際の成果と結果が、このブログ投稿に含まれる、または検討される将来を見据えた声明に含まれるものと実質的に異なる原因となる可能性のあるリスク、不確実性、およびその他の要因に関する詳細情報は、証券取引委員会に提出および報告する「リスク要因」というキャプションの下およびその他の場所に含まれています。このブログ投稿の日付以降に将来を見据えた声明の改訂を更新またはリリースする義務、またはイベントや状況を報告する義務、または予期しないイベントの発生を反映する義務を負いません（法律で要求される場合を除く）。

Monday Merge 8月号

2025-08-11T00:00:00.000Z

GitLabコミュニティのみなさん、こんにちは！今月もソフトウェア開発の最新トレンドをお届けします。

今回のトピックはこちら：

GitLab Duo Agent Platformのパブリックベータ版がスタート：AIともっとスマートに働く方法とは
現場のニーズに応える最新GitLabリリース情報
世界2,786名のCレベル層に聞いた、AIとソフトウェアイノベーションに関する意識調査
注目イベントやおすすめコンテンツ、NatWest社の導入事例もご紹介

それでは、さっそく見ていきましょう⚓

GitLab Duo Agent Platform：パブリックベータ版がついに登場

従来のAIアシスタントの概念を覆す新しい体験 ── GitLab Duo Agent Platformは、開発・セキュリティ・運用すべてをカバーする次世代のDevSecOpsオーケストレーションエンジンです。パブリックベータ版としての提供がスタートしました。

これは単なるIDE内のAIボットではありません。複数のAIエージェントがチームの一員として非同期に連携し、計画からリリースまでをトータルでサポートします。

初期搭載されているエージェントは以下の通りです：

Chat Agent：自然言語での質問や汎用的な開発作業をサポート
Developer Agent：仮想開発環境でマージリクエストを作成
Security Analyst Agent：脆弱性の検出と修正提案
Deep Research Agent：リポジトリ全体を分析し、背景を踏まえたインサイトを提供
Software Development Flow：複数エージェントを連携させて一連の開発タスクを自動化

GitLabのイシュー、パイプライン、CI/CDなど25以上の機能にネイティブにアクセスできるため、コンテキストを理解した精度の高い支援が可能です。さらに今後は、エージェントをカスタマイズし、複雑な作業を自動実行できる「フロー」も登場予定です。

PremiumおよびUltimateプランをご利用中の方は、VS CodeやJetBrains IDEでベータ版を今すぐお試しいただけます。Web UIでも「Duo Agentic Chat」がすでに利用可能です。

▶︎ GitLabがオーケストレーションプラットフォームとして持つ独自の強みについて、CEOのBill Staplesが語るインタビューはこちら。導入方法もあわせてご紹介しています。

GitLab企業経営調査2025：AI・信頼・7,500億ドルの可能性

AIは単なるトレンドではありません。世界の開発者2,700万人がAIを活用すれば、7,500億ドル以上の価値が生まれると言われています。最新のGitLab企業経営調査2025では、世界中の経営層2,786名にAIとソフトウェア開発の未来について調査を行いました。

主な調査結果：

AI活用によって、開発者1人あたり年間28,249ドルのコスト削減を実現（世界中の開発者数で見積もると7,500億ドル規模に）
89％の経営者が、今後3年以内にAIエージェントが業界標準になると予想
懸念点は「サイバー攻撃（52%）」「データのプライバシーとセキュリティ（51%）」「ガバナンスの維持（45%）」
92％が「社員がAIと協働できるようスキルトレーニングが必要」と回答

📥 レポート全文はこちらからダウンロードできます

（日本に特化したレポートは近日中に公開予定）

GitLab 18.2がリリースされました

GitLab 18.2では、30以上の新機能や改善が追加され、よりスピーディーかつ安全な開発が可能に。今回のアップデートにも、GitLabコミュニティから152件の貢献が寄せられました。ありがとうございます！

注目の新機能：

✅ カスタムワークフローステータス：イシューの状態を自社の運用に合わせて柔軟に管理可能に
🧭 Merge Requestページの再設計：ロールやワークフロー別に表示を最適化
🔐不変コンテナタグ：本番環境への不意な変更を防止

🔗 全リリース内容はこちら

今月のイベント情報：Black Hat USA & OSS EU

今月はGitLabチームがイベントに登場します！

📍 Black Hat USA（ラスベガス） – 詳細はこちら
📍 Open Source Summit Europe（アムステルダム） – 今月後半 👉 登録はこちら

開催地にいらっしゃる方は、ぜひお立ち寄りください！ステッカーもご用意しています。

お客様事例：NatWest社

金融機関NatWest社は、GitLab Duo Agent Platformを活用して開発スピードと生産性を大幅に向上させています。

「GitLab Duo Agent Platformは、私たちのコードベースと組織構造を理解したうえで、AIが開発ワークフロー全体を支援してくれます。コード・テスト・CI/CDとあらゆる工程にAIが溶け込み、チームの一員として一緒に仕事している感覚があります。開発者はより創造的な仕事に集中できるようになりました」 — NatWest社エンジニアリングプラットフォームリード Bal Kang

今月のおすすめ記事＆動画👀

GitLabリーダーたちが語る、AI・DevSecOps・ソフトウェアセキュリティの未来。

https://leaddev.com/reporting/the-rise-and-looming-fall-of-acceptance-rate

https://www.thestack.technology/a-cisos-focus-lessons-from-the-field/

https://www.raconteur.net/technology/agentic-ai-vibe-coding-oped

https://thenewstack.io/software-security-imperative-forging-a-unified-standard-of-care/

https://youtu.be/wZytaN-1URM

最後に、今月の名言を

「知性の本当の証は知識ではなく、想像力である」 — アルベルト・アインシュタイン

素晴らしいアイデアは、予想外の場所から生まれるものです。知識だけでなく、「想像する力」を大切にしたいですね。

今月号は以上です。Duo Agent Platformはついに一般公開され、AIはC-suiteの重要議題へ、そしてMerge Requestページもさらに進化した、盛りだくさんな月でしたね。

それではまた来月、お会いしましょう！Happy Merging！

Fatima Sarah Khalid｜GitLab Developer Advocate

🧡 このニュースレターが気に入った方は、ぜひチームにもシェアしてください。 👉 The Developer Showの購読もお忘れなく！

GitLab

『2025年Gartner® Magic Quadrant™ for DevOps Platforms』でGitLabが3年連続でリーダーの1社として評価されました

より迅速な価値実現

最も重要なお客様のユースケース

ロードマップとは？意味やソフトウェア開発における必要性、作り方

1. ロードマップとは？

2. ロードマップの主な種類

2-1. プロジェクトロードマップ

2-2. プロダクトロードマップ

3. ロードマップとマイルストーンとの違い

4 ロードマップとガントチャートの違いと併用可否について

5. ソフトウェア開発におけるロードマップの必要性・目的

6. ソフトウェア開発においてロードマップがもたらすメリットと効果

6-1. プロジェクト全体を可視化できる

6-2. チーム間の共通認識が生まれる

6-3. 進捗や課題を把握しやすくなる

6-4. 開発関係者のモチベーションの維持につながる

7. ロードマップの作成ステップ

7-1. 目標設定

7-2. 現状把握

7-3. リスク対策

7-4. マイルストーンの設定

7-5. スケジュール計画表の作成

7-6. 関係者への共有と改善

8. ロードマップ作成時の注意点

8-1. 見やすさを意識して作成する

8-2. 計画の実現性を意識する

8-3. 定期的な見直しを実施する

9. ロードマップの作成手段

9-1. エクセル・パワーポイント

9-2. 専用ツール

10. プロジェクト管理ツール・サービスの選び方

10-1. 機能

10-2. 操作性

10-3. 価格

10-4. サポート体制

11. ロードマップの作成・活用なら「GitLab」がおすすめ

11-1. GitLabとは

11-2. GitLabのロードマップ機能の特徴

12. ロードマップ作成に関するよくある質問

12-1. 作成手段は専用ツールとエクセルどちらが良い？

12-2. 開発においてロードマップには誰が関与する必要がある？

12-3. ロードマップの作成が失敗する原因は？

まとめ ロードマップはソフトウェア開発に必須！専用ツールの活用で効率よく作成しよう

GitLab 18.4: 自動化と分析を活用したAIネイティブ開発

エクスペリエンスを構築する

専門エージェントライブラリとしてのAI Catalog（試験版）

フローに集中する

エージェントとのコラボレーションを効率化するよりスマートなAgentic Chat（ベータ版）

コードベースの力を解き放つ

GitLab Knowledge Graphのご紹介（ベータ版）

パイプラインメンテナンスを自動化する

ビジネスを考慮したパイプライン修正フロー

AI環境をカスタマイズする

機能パフォーマンスを最適化するGitLab Duoモデル選択

機密コンテキストを保護する

詳細なデータ保護のためのGitLab Duoのコンテキスト除外機能

新しいMCPツールでAI機能を拡張する

GitLab MCPサーバーの新ツール

インテリジェントなソフトウェア開発の未来を体験する

GitLabを最新の状態に保つ

プラットフォームエンジニアリングとは？意味や導入メリットをわかりやすく解説

1. プラットフォームエンジニアリングとは？

1-1. プラットフォームエンジニアリングの意味・特徴

1-2. IDP（内部開発者向けプラットフォーム）とは

2. プラットフォームエンジニアリングが注目されている背景

2-1. 開発環境の複雑化

2-2. ビジネス環境の激化

2-3. IT人材の不足

3. プラットフォームエンジニアリングとDevSecOps・SREとの関係性とは

3-1. DevSecOpsとの違い

3-2. SREとの違い

4. プラットフォームエンジニアリングの導入目的とメリット

4-1. 開発プロセスの効率化

4-2. 開発者の生産性向上

4-3. プロダクトの品質向上

4-4. セキュリティ・ガバナンスの維持と強化

4-5. 人材不足の解消

4-6. 新しいイノベーションの創出

4-7. コスト削減

まとめロードマップはソフトウェア開発に必須！専用ツールの活用で効率よく作成しよう

まとめ：プラットフォームエンジニアリングの実現により開発品質の向上と効率化を図ろう