ソニービズネットワークス株式会社所属のエンジニア、濱田 一成です。先日、GitLab 様との共同企画でAWS様の作成したマルチアカウントIaC・CI/CDワークショップを、GitLabを用いた構成にリファクタリングしました。本記事は、そのワークショップの解説記事です。

従来の構成

元のワークショップはAWSサービスのみでCI/CDパイプラインを構成しています。このワークショップは手軽に継続的インテグレーションを体験出来ることから、非常に高い評価を得ていました。しかし現在AWS CodeCommitは新規顧客の受け入れを停止しており、元ワークショップも新たなお客様のご利用が出来なくなっていました。

リファクタリング後の構成

そこで今回、AWS CodeCommitをGitLabに置き換え、CI/CDを体験するワークショップとしてリファクタリングを行いました。本ワークショップのAWS CDKコードをご利用頂く事で、GitLabをソースリポジトリとして組み込んだCI/CDパイプラインを体験頂けます。

ワークショップのポイント：AWS CodeConnections

AWS CodeConnectionsは、AWSと様々なコードリポジトリを接続するサービスです。本サービスを利用する事で、SaaS版GitLabはもちろん、セルフホスティング版のGitLabも、AWS上に構築したCI/CDパイプラインに組み込むことが出来るようになります。今回のワークショップではVPC内にGitLabサーバを構築し、インターネット経由でAWS CodeConnectionsと接続します。

プライベートネットワーク接続にも対応している

今回のワークショップではインターネット経由でGitLabと接続していますが、もちろん閉域に閉じることも可能です。AWS CodeConnectionsを作成する時に、オプションでVPCを指定する事が出来ます。こちらを指定すると、AWS CodeConnectionsとGitLab間の通信専用のENIが作成されます。AWS CodeConnectionsは、このENIを経由してGitLabと通信する事で、閉域網内での利用を実現しています。

ワークショップ手順解説

従来のワークショップとの差分は、【Lab 1：CI/CDパイプライン環境のセットアップ】のうち、【手順5. GitLabをデプロイする】のみです。そこで今回は本セクションについて重点的に解説します。

前提事項：GitLab用公開ドメインを用意する

本ワークショップでは、GitLabと同じアカウントのRoute53にホストされている公開ドメインが必要です。

AWS CodeConnectionsの要件として、GitLabとの通信はTLS暗号化が必須となっています。GitLabはデフォルトでLet’s Encryptと統合していますが、GitLabのインストール中に指定したURLの名前解決を行えないとLet’s Encryptの設定が失敗してしまいます。その為、今回はCDKのデプロイプロセスの中にレコード登録を組み込んでいます。

ちなみに、このAWS CodeConnectionsのTLS要件はプライベート接続でも同様に求められます。その場合、CodeConnectionsの設定作成時にプライベート証明書をアップロードする必要があります。

手順1. インフラ CI/CDのセットアップに必要なアセットのダウンロード

本Labの実施に必要なコード一式を、gitコマンドでダウンロードしてください。

git clone 


https://github.com/issei-hamada/goverment-cloud-iac-cicd-with-gitlab.git

手順2. アセットの確認

ダウンロードしたプロジェクトの配下に、以下ディレクトリがあることを確認します。

• artifact-repository

• gitlab

• cicd-pipeline

• cdk-role

後の手順で、ディレクトリ毎に作業します。

手順3. パッケージのインストール

Node.jsの必要なライブラリをインストールします。

# ディレクトリ移動 


cd goverment-cloud-iac-cicd-with-gitlab 


# package.json に登録されているものをインストール


npm ci

手順4. artifact-repositoryをデプロイする

以下コマンドを順に実行し、artifact-repositoryをデプロイします。

# ディレクトリ移動


cd artifact-repository


# 対象アカウントに CDK で必要なリソースを作成


npx cdk bootstrap


# デプロイ


npx cdk deploy

AWS CodeArtifactの役割

AWS CodeArtifactとは、ソフトウェア開発で使用するパッケージを安全に保存、公開、共有するためのフルマネージド型のアーティファクトリポジトリサービスです。ここで言う「パッケージ」とは、HTTPリクエストを手軽に実装するための、pythonで言う「requests」、JavaScriptで言う「Axios」のようなパッケージ（ライブラリとも表現する事がありますね）を指します。例えばpythonでソフトウェアを開発する際、pipの参照先をCodeArtifact に設定する事で、開発者全員が予めCodeArtifactに登録されたパッケージを利用出来るようになります。

ソフトウェア開発におけるパッケージ管理のセキュリティ・コンプライアンスを強化する事がAWS CodeArtifactの役割です。

手順5. GitLabをデプロイする

ここからが、アップデート後のコアとなる手順です。AWSにGitLabをデプロイしていきます。

5-1. デプロイパラメータを設定する

まずは、デプロイ時に利用する必須パラメータを設定します。gitlab/parameter.tsファイルを修正して下さい。

基本的にデフォルト値は設定されていますが、★の付いているホストゾーンID・ドメイン名のみ個別に設定が必要です。

次に、ユーザデータ（gitlab/lib/sh/gitlab-install.sh）内のURLを書き換える必要があります。16行目のhttps://gitlab.example.comを、GitLabの接続URLに書き換えて下さい。

EXTERNAL_URL="https://gitlab.example.com" apt-get install -y gitlab-ee

GitLabはデフォルトでLet’s Encryptと連携しています。こちらを記述する事で、インストール後、指定のドメインにhttpsアクセス可能な状態で起動します。

5-2. GitLab Stackをデプロイする

初めてCDKを実行する場合は、gitlabディレクトリへ移動し、CDKをbootstrapします。

# リポジトリ移動


cd gitlab


# CDK 用リソース作成


npx cdk bootstrap

次に、GitLab EC2インスタンスをデプロイします。

# デプロイ


npx cdk deploy

• EC2 のキーペアについて

本ワークショップではCDKを使ってキーペアを生成しています。CDKでは秘密鍵をAWS Systems Manager Parameter Storeに保存する仕様になっています。インスタンス起動時点でセッションマネージャを利用出来る設定にはなっていますが、必要に応じて/ec2/keypair/GitLabから取得し、ファイルを生成してください。

これでインスタンスのデプロイは完了です。GitLabのインストールも自動で行われますが、CDKのデプロイ完了から10~15分程度かかります。ブラウザから設定したURLにアクセスし、ログインページが表示されるまでお待ちください。

5-3. GitLabへログイン

ログインページが表示されれば、GitLabのインストールは完了です。OSログインして初期パスワードを確認します。

1. EC2コンソールにてGitLabインスタンスを選択し、「接続」から「セッションマネージャ」でEC2に接続します。

2. 以下のcatコマンドを実行します。

   $sudo cat /etc/gitlab/initial_root_password
   # WARNING: This value is valid only in the following conditions
   # 1. If provided manually (either via `GITLAB_ROOT_PASSWORD` environment variable or via `gitlab_rails['initial_root_password']` setting in `gitlab.rb`, it was provided before database was seeded for the first time (usually, the first reconfigure run).
   # 2. Password hasn't been changed manually, either via UI or via command line.
   #
   # If the password shown here doesn't work, you must reset the admin password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.
   Password: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   # NOTE: This file will be automatically deleted in the first reconfigure run after 24 hours.
   

3. Passwordの値が、GitLab rootユーザの初期パスワードです。これをコピーしておきます。

4. ブラウザからGitLabへアクセスし、ユーザ名：root / パスワード：前項で取得したパスワードを使って、ログインします。

ブラウザからアプリケーションにログイン出来れば、本手順は完了です。

5-4. GitLabグループ作成

GitLabではグループにプロジェクト（いわゆるリポジトリ）を紐づけて管理する為、まずはグループを作成します。

1. ログイン後のトップページにて、左メニューの「Group」を選択

   

2. 画面中央右の「New group」を押下

   

3. 「Create group」を押下

   

4. 「Group name」を入力し、「Create group」を押下

   

今回は、「development-group」として下さい。

これでグループ作成は完了です。

5-5. ワークショップ用プロジェクト作成

次は、前段で作成したグループに紐づくプロジェクトを作成していきます。

1. GitLabコンソール左メニュー右上の「＋」アイコンをクリックし、「New project/repository」をクリック

   

2. 「Create blank project」をクリック

   

3. プロジェクト名を入力し、「Create project」を押下

   Project URLで、name spaceに 5-4 で作成したグループ名が入力されている事を確認します。また、本 workshop ではプロジェクト名を「cicd-workshop」として下さい。

   

以上でプロジェクトの作成が完了し、リポジトリのクローンやプッシュが可能な状態になりました。次は、GitLabとAWSの接続設定に必要な認証情報を払い出します。

5-6. パーソナルアクセストークンを払い出す

GitLabと外部リソースを連携する際、パーソナルアクセストークン（PAT（という認証情報を利用します。今回はAWSとGitLabを連携する為に必要です。

1. 左メニュー右上のユーザアイコンをクリックし、「Edit profile」をクリック

   

2. 左メニューの「Access tokens」をクリック

   

3. 右上の「Add new token」ボタンを押下

   

4. 「Select scope」にて「api」と「admin_mode」にチェックを入れ、「Create token」ボタンを押下

   token name には、任意の値を入れて下さい。

   

5. 「Your token」に表示されているトークンをコピーし、控える

   

以上でPATの払い出しが完了し、GitLabとAWSを連携する準備が出来ました。

補足：パーソナルアクセストークンの有効期間について

PATの有効期間については、AWS CodeConnectionsとの接続設定を作成する時に有効であればよいです。接続設定を作成した後は、PATを削除しても問題ありません。

GitLabとAWS CodeConnectionsの連携設定を作成すると、GitLabのApplicationsに以下のようなアプリが作成されます。

PATは、このアプリをGitLab側に作成する為だけに必要な認証情報なのです。

手順6. AWS CodeConnectionsを作成する

ここからAWSの作業に戻ります。AWS CodeConnectionsを作成し、GitLab側で認証します。

6-1. 「接続」を作成

1. AWSコンソールの検索窓にて「CodePipeline」と入力し、サービスページへ移動

2. 左メニューの「設定」プルダウンから、「接続」を選択

3. 右上の「接続を作成」ボタンを押下

   

4. 「プロバイダーを選択する」にて「GitLab Self Managed」を選択し、接続設定を入力後、「GitLab Self Managedに接続」ボタンを押下

   • 接続名：任意の値
   • URL：作成した GitLab の URL を入力
   • 「VPCを使用」にはチェックを入れない

   → プライベートサブネット内にあるGitLabと接続する時のオプション

   

これでAWS CodeConnectionsの「接続」を作成できました。現時点では、接続ステータスは「保留中」で問題ありません。次の手順で承認作業を行います。

6-2. GitLabにてAWS CodeConnectionsの接続を承認する

1. 先ほど作成した「接続」の、右上「保留中の接続を更新」ボタンを押下

   

2. ポップアップウィンドウが開く。テキストボックスに個人用アクセストークンを入力し、「続行」ボタンを押下

   

3. GitLabの認証画面が開く。「Authorize ~」ボタンを押下

   この時、作業しているブラウザからGitLabに接続できる必要があります。ワークショップ環境であれば問題ありませんが、社内環境と接続する際はご注意下さい。

   

4. 「ホストインスタンスでのインストールの確認」にて、「続行」を押下

   

5. 「接続」のステータスが「利用可能」になったら完了

   

6. 「接続設定」に記載されているARNを控える

以上でAWS CodeConnectionsの設定は完了です。これでAWS CodePipelineのソースリポジトリとしてGitLabを指定出来るようになりました。次の手順では、実際にAWS CodePipelineをデプロイしてCI/CDパイプラインを動かせるようにしていきます。

補足：AWS CodeConnectionsから参照出来るGitLabプロジェクトの制御方法

AWS CodePipelineでソースとして指定できるプロジェクトは「3. GitLab の認証画面が開く。「Authorize ~」ボタンを押下」手順を実行する際に、GitLabへログインしていたユーザによって決まります。スクリーンショットではAdministratorになっていますが、実際の構築では各々のユーザ名になります。PATを払い出す際に「admin_mode」にチェックを入れても、全てのプロジェクトを参照できるようになるわけではありません

手順7. cicd-pipeline をデプロイする

AWS CodeConnectionsをソースに指定し、CI/CDパイプラインをデプロイします。基本的に元のワークショップと変わらないのですが、2つだけパラメータを追加しています。

7-1. デプロイパラメータを設定する

cicd-pipeline/parameter.tsに、先ほどメモしたAWS CodeConnectionsのARNとソースとして指定したいGitLabのプロジェクト名を入力します。

// CodeConnections parameters



codeConnectionArn: 'arn:aws:codeconnections:ap-northeast-1:xxxxxxxxxxxx:connection/xxxxxxxxxxxx',



gitlabTargetProject: 'development-group/cicd-workshop',

7-2. デプロイする

初めて CDK を実行する場合は、対象のディレクトリへ移動し、CDK を bootstrap します。これは対象のアカウントとリージョンの組み合わせで初めて CDK を実行するときに必要です。

# リポジトリ移動


cd cicd-pipeline


# CDK用リソースを作成


npx cdk bootstrap --profile cicd


# デプロイ


npx cdk deploy --profile cicd

以上でCI/CDパイプラインのデプロイは完了です。

手順8. cdk-roleをデプロイする

最後に、パイプライン内で利用するIAMロールを作成します。本ワークショップはマルチアカウントを想定している為、アカウントを跨いでCDKを実行する際にこのIAMロールを利用します。デプロイ手順は、以下コマンドを順に実行するだけです。

# リポジトリ移動


cd cdk-role


# CDK用リソースを作成


npx cdk bootstrap --profile cicd


# デプロイ


npx cdk deploy --profile cicd

コマンドが正常に完了すれば、CI/CDパイプラインに関するリソースのデプロイは完了です。

手順9. CDKコードを GitLabにpushする

ここまでの手順で、GitLabとAWS上に作成したCI/CDパイプラインの連携設定が完了しました。あとはGitLabにブランチを作成し、コードをプッシュすれば各環境にコードがデプロイされます。

1. GitLabプロジェクトに develop/staging/production ブランチを作成する

2. feature ブランチを作成し、開発/検証/本番環境へデプロイするCDKコードを push する

3. develop -> staging -> production ブランチとマージしていくことで各環境にコードがデプロイされることを確認

Lab 2：ソース管理 以降の手順については、従来のワークショップの手順と同一です。手順内のAWS CodeCommitを適宜GitLabに読み替えて実施して下さい。

終わりに

AWS CodeConnectionsさえ作ってしまえば、GitLabとAWSを簡単に連携出来るようになります。本ワークショップではシングルアカウントを想定して解説しましたが、Resource Access Managerを使う事でマルチアカウントにも対応可能です。AWSとGitLabを組み合わせたCI/CDパイプラインのご相談があれば、ソニービズネットワークスまでご相談下さい。

以上、ソニービズネットワークスのAWS Ambassador、濱田 一成がお送りしました。

謝辞：本ブログは、Amazon Web Services, Inc. 社作成のワークショップ「マルチアカウント IaC・CI/CD ワークショップ 」を元に、GitLab版の作成依頼をGitLab Japanからソニービズネットワークス社濱田様にご依頼をして作成いただいたものになります。

ソニービズネットワークス社は、ソニーグループの法人向けICTソリューション事業を展開しています。高品質な法人向けインターネット接続サービス「NUROアクセス」を主力に、クラウドサービス、セキュリティ、AIサービスなど、ビジネスに必要なインフラとシステムをワンストップで提供し、企業の成長と効率化を支援しています。この度、GitLabのオフィシャルリセールパートナーとなりました。

今回のリリースの核となるのは、GitLab全体の使いやすさを大幅に改善すること、そしてAIをユーザーエクスペリエンスに自然に統合することです。新しいパネルベースのUIにより、データをコンテキスト内で確認しやすくなり、GitLab Duo Chatをプラットフォーム全体で必要な場所に常時表示できるようになりました。そして、専用のエージェントが脆弱性のトリアージとバックログ管理に対応し、主要なAIツールがこれまで以上にシームレスにエージェント型ワークフローと統合されます。また、業界をリードするセキュリティ機能を拡張し、悪用可能な脆弱性と理論上の脆弱性の識別、有効な認証情報と期限切れの認証情報の区別、変更されたコードのみのスキャンによるデベロッパーのフローの維持をサポートします。

18.5の新機能

18.5は今年最大のリリースです。リリース紹介動画をご覧いただき、詳細については記事本文をお読みください。

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1128975773?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab_18.5 Release_101925_MP_v2"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

GitLab Duoへのクイックアクセスを備えた最新のユーザーエクスペリエンス

GitLab 18.5では、新しいパネルベースのレイアウトにより、より使いやすく直感的なインターフェースでGitLabのユーザーエクスペリエンスが向上します。

パネルは情報を並べて表示し、より文脈に沿った作業を可能にします。イシューリストでイシューをクリックすると、そのサイドパネルに詳細が表示されます。次に、インターフェースの右側にGitLab Duo Chatパネルをオンデマンドアシスタントとして開くことができ、GitLab体験のどこからでも、コンテキストに応じた質問や指示でエージェントを活用できます。その他の細かいながらも使いやすさを重視した改善には、アクセシビリティ向上のためのグローバル検索ボックスの上部中央への移動、マイイシュー、マージリクエスト、To-Do、ユーザーアイコンなどのグローバルナビゲーション要素の右上への移動などがあります。左側のナビゲーションメニューは折りたたみと展開が可能で、柔軟なサイドバー管理を実現します。

パネルUIは、GitLab 18.5では「デフォルトでオフ」となり、ユーザーアイコンの下にあるオプトイントグルで利用できます。この機能を有効または無効にする方法の詳細については、こちらのドキュメントを参照してください。改善点やバグがあれば、ぜひフィードバックをお寄せください。エンジニアチームが注意深く対応します。私たちのチームと同じようにこの体験を気に入っていただければ、このトグルは18.6で削除され、パネルUIがすべてのユーザーエクスペリエンスで標準になる予定です。

GitLab Duo Agent Platformのアップデート

Security Analyst Agent（セキュリティ分析エージェント）：手動の脆弱性トリアージをAI駆動の自動化に変革

GitLab Duoセキュリティ分析エージェントは、AI搭載の分析により脆弱性管理ワークフローを自動化し、何時間もかかる手動トリアージをAI駆動の高度な自動化に変革します。GitLab Duo Agentic Chatで利用できるVulnerability Management Tools（脆弱性管理ツール）を基盤として、セキュリティ分析エージェントは複数のツールを連携させ、セキュリティポリシーを適用しながら、繰り返しのワークフロー用のカスタムフローを自動的に作成します。

セキュリティチームは、CVEの詳細、静的到達可能性分析、コードフロー情報を含む充実した脆弱性データにアクセスでき、誤検知の却下、脅威の確認、深刻度レベルの調整、修復用のリンクイシューの作成など、すべてを会話型AIを通じて実行できます。このエージェントは、脆弱性ダッシュボードでの繰り返しのクリック作業を削減し、カスタムスクリプトを簡単な自然言語コマンドに置き換えます。

たとえば、セキュリティスキャンで数十件の脆弱性が検出された場合、「reachable=FALSEの脆弱性を却下し、クリティカルな調査結果のイシューを作成する」とプロンプトするだけです。セキュリティ分析エージェントは到達可能性データを分析とセキュリティポリシーの適用を行い、一括操作を瞬時に完了します。これにより、本来であれば何時間もかかる作業を削減できます。

個別の脆弱性管理ツールは特定のタスクのためにAgentic Chatから直接アクセスできますが、セキュリティ分析エージェントはこれらのツールを状況に応じて適切に統制し、複雑な多段階ワークフローを自動化します。脆弱性管理ツールはGitLab Self-ManagedおよびGitLab.comインスタンスのAgentic Chatで利用でき、セキュリティ分析エージェントは18.5ではGitLab.comのみで利用できます。Self-ManagedおよびDedicated環境での提供は、次回のリリースで予定されています。 デモ動画をご覧ください：

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1128975984?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="18.5 Security Demo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

GitLab Duo Planner：バックログの混沌を戦略的な明確さに変える

複雑なソフトウェアデリバリーを管理するには、複数の計画タスクを絶えず行き来する必要があります。GitLab Duo Plannerは、チームが日々直面する現実の計画課題に対応します。Duo Plannerは、イシュー、エピック、マージリクエストの管理方法を含むプロジェクトコンテキストを認識するチームメイトとして機能します。一般的なAIアシスタントとは異なり、GitLabの計画ワークフローの深い知識とアジャイルおよび優先順位付けフレームワークを組み合わせて構築されており、労力、リスク、戦略的整合性のバランスを取るのに役立ちます。

GitLab Duo Plannerは、漠然としたアイデアを構造化された計画階層に変換できます。さらに、古いバックログアイテムの特定や、経営陣向けの更新のドラフト作成も可能です。たとえば、数か月にわたって蓄積された何百ものイシューを含むバックログを整理する場合、「古いバックログアイテムを特定し、優先順位を提案する」とプロンプトするだけです。数秒で構造化された要約が表示され、その要約では、更新されていないイシュー、情報不足のアイテム、重複作業が明示され、ラベルとマイルストーンに基づく推奨優先順位と具体的なアクションが提案されます。

複雑なロードマップを管理するチームにとって、Plannerは何時間もの手動分析とタスクの行き来を排除し、プロダクトマネージャーとエンジニアリングリーダーがより迅速で情報に基づいた意思決定を行えるようサポートします。18.5の時点で、GitLab Duo Plannerは現在「読み取り専用」であり、分析、計画、提案はできますが、まだ何かを変更する直接的なアクションは実行できません。詳細については、ドキュメントを参照してください。

拡張可能なエージェントカタログ：人気のAIツールをネイティブGitLabエージェントとして利用可能に

GitLab 18.5では、主要なAIエージェントをAIカタログに直接導入し、Claude、OpenAI Codex、Google Gemini CLI、Amazon Q Developer、OpenCodeなどの外部ツールがネイティブGitLabエージェントとして利用できるようになりました。ユーザーは、GitLabの組み込みエージェントと同じカタログインターフェースから、これらのエージェントを検出、設定、デプロイでき、組織全体のカタログで主要エージェントが自動的に同期されます。

ポイントアンドクリックでカタログから直感的に操作できる一方、GitLabの認証・監査システムを通じてエンタープライズグレードのセキュリティも確保されています。これにより、面倒なエージェントの手動設定が不要になります。

GitLab Duo Enterpriseサブスクリプションでは、ClaudeとCodexが標準で利用可能になりました。個別のAPIキーや追加料金の設定は不要で、既存のサブスクリプションだけで使えます。

なお、他のエージェントについては統合の最終調整中のため、別途サブスクリプションや設定が必要になる場合があります。

セルフホスト対応GitLab Duo Agent Platform（ベータ版）：AI能力を犠牲にせずにデータ主権要件に対応

GitLab 18.5では、GitLab Duo Agent Platformのセルフホスト機能が実験的機能からベータ版に移行し、規制産業やデータ主権要件に不可欠な、組織が独自のインフラストラクチャ内でAIエージェントとフローを完全に実行できるようになりました。ベータ版リリースには、改善されたタイムアウト設定とAIゲートウェイ設定が含まれており、チームはコードレビュー、バグ修正、機能実装にAIエージェントを使用しながら、機密コードを企業レベルのセキュリティで保護できます。

よりスマートで高速なセキュリティ：実際のリスクを優先し、デベロッパーのワークフローを維持

GitLab 18.5では、新しいアプリケーションセキュリティ機能を導入しました。チームは悪用可能なリスクに焦点を絞り、ノイズを減らしながら、ソフトウェアサプライチェーンセキュリティを強化できます。

これらのアップデートは、セキュリティを開発プロセスに直接組み込むという当社の継続的な取り組みの一環です。デベロッパーの作業フローを妨げることなく、高い精度、迅速性、そして有益なインサイトを提供します。

静的到達可能性分析

今年は37,000を超える新しいCVEが発行され、セキュリティチームは膨大な数の脆弱性の中から、どれが本当に悪用可能かを見極めることに苦労しています。限定提供中の静的到達可能性分析は、脆弱なコードが依存関係に存在するだけでなく、アプリケーションで実際に呼び出されているかどうかを特定できます。これにより、ライブラリレベルで正確に脆弱性を評価できます。

最近リリースされたExploit Prediction Scoring System（EPSS）およびKnown Exploited Vulnerability（KEV）データと組み合わせることで、セキュリティチームは脆弱性のトリアージを効果的に加速できます。実際のリスクを優先して対応することで、全体的なサプライチェーンセキュリティの強化につながります。18.5では、既存のPython、JavaScript、TypeScriptのサポートに加えて、Javaのサポートを追加しています。

シークレット有効性チェック

静的到達可能性分析がチームがオープンソース依存関係から悪用可能な脆弱性を優先するのに役立つのと同様に、シークレット有効性チェックは露出したシークレットに同じインサイトをもたらします。現在、GitLab.comとGitLab Self-Managedでベータ版として利用可能です。GitLabが発行するセキュリティトークンの場合、漏洩した認証情報またはAPIキーが有効かどうかを手動で確認する代わりに、GitLabは脆弱性レポートで有効なシークレットと期限切れのシークレットを自動的に区別します。これにより、セキュリティチームと開発チームは、本当に対処すべきリスクに絞って修復作業を進められます。AWSおよびGCPが発行するシークレットのサポートは、今後のリリースで予定されています。

高度なSASTのカスタムルール

高度なSASTは、社内セキュリティリサーチチームの情報に基づくルールで実行され、すぐに使える精度を最大化するように設計されています。ただし、一部のチームは、特定の組織に合わせてSASTエンジンを調整するための追加の柔軟性を必要としていました。高度なSASTのカスタムルール機能を使えば、AppSecチームはGitLabの標準ルールに加えて、組織独自のセキュリティルールを設定できます。たとえば、社内で禁止されている関数の使用を検出するなど、組織特有のセキュリティ要件に対応したパターンベースの検出ルールを定義できます。カスタマイズは、他のSASTルールセット設定と同様に、シンプルなTOMLファイルを通じて管理されます。これらのルールは汚染分析をサポートしませんが、組織に正確なSAST結果を達成するための柔軟性を高めます。

高度なSASTでCおよびC++言語をサポート

高度なSASTの対応言語を拡大し、組み込みシステムソフトウェア開発で広く使用されているCおよびC++がサポートされるようになりました。スキャンを有効にするには、プロジェクトはコンパイラコマンドとビルド中に使用されるインクルードパスをキャプチャするコンパイルデータベースを生成する必要があります。これにより、スキャナーがソースファイルを正確に解析および分析し、開発プロセスで実際の脆弱性を特定するのに役立つ正確でコンテキストを認識した結果を提供できます。CおよびC++の実装要件には特定の設定が必要であり、ドキュメントに記載されています。高度なSASTにおけるCおよびC++サポートは現在ベータ版で利用可能です。

差分ベースのSASTスキャン

従来のSASTスキャンは、コミットごとにコードベース全体を再分析していました。その結果、パイプラインが遅くなり、デベロッパーのワークフローが中断されます。デベロッパーエクスペリエンスは、アプリケーションセキュリティテストの導入を左右する重要な要素です。

差分ベースのSASTスキャンは、この課題を解決します。マージリクエストで変更されたコードのみに焦点を当てることでスキャン時間を短縮します。同時に、冗長な分析を減らし、デベロッパーの作業に関連する結果だけを表示するようにします。実際のコード変更に合わせたスキャンにより、GitLabは強固なセキュリティカバレッジを保ちつつ、より高速で焦点を絞ったフィードバックを提供し、デベロッパーのワークフローを妨げません。

API設定の簡素化

API駆動型ワークフローは、強力で柔軟性がありますが、チームが日常的に繰り返すタスクには、かえって手間がかかることがあります。新しいMaven Virtual Registryインターフェースにより、これらのオペレーションにUIレイヤーが追加されます。

Maven Virtual Registryインターフェース

Maven Virtual Registryを管理するための新しいWebベースのインターフェースにより、複雑なAPI設定が視覚的にシンプルになり、パッケージ管理者とプラットフォームエンジニアにとってより直感的な体験が提供されます。

これまで、チームは仮想レジストリをAPIコールのみで設定および維持していたため、日常的なメンテナンスに時間がかかり、専門的なプラットフォーム知識が必要でした。新しいインターフェースにより、この障壁が取り除かれ、日常的なタスクをより高速かつ簡単にします。

このアップデートにより、次のことが可能になります：

• 依存関係の設定を簡素化するための仮想レジストリの作成
• パフォーマンスとコンプライアンスを向上させるためのアップストリームの作成と順序付け
• UI内での古いキャッシュエントリの直接参照とクリア

この視覚的な操作画面により、運用オーバーヘッドを削減できます。また、開発チームは依存関係の解決方法をより明確に把握でき、ビルドパフォーマンスとセキュリティポリシーに関して適切な判断を下せるようになります。

デモをご覧ください：

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/CiOZJPhAvaI?si=cYaoR_OIgqFKbyM2" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

<p></p>

エンタープライズのお客様には、Maven Virtual Registryベータプログラムに参加し、最終リリースの形成にフィードバックを共有していただくことをお勧めします。

ワークフローに適応するAI

このリリースは、単なる新機能の追加ではありません。ユーザーに選択肢とコントロールを提供します。解説動画はこちら：

<p></p>

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1128992281?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="18.5-tech-demo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

GitLab PremiumおよびUltimateユーザーは、GitLab.comとSelf-Managed環境で今日からこれらの機能を使用できます。GitLab Dedicatedのお客様への提供は来月を予定しています。

GitLab Duo Agent Platformは現在ベータ版です。ベータ版および実験的機能を有効にして、フルコンテキストAIがチームのソフトウェア構築方法をどのように変革できるかを体験してください。

GitLabは初めてですか？無料トライアルを開始して、AIを活用した安全な開発が、世界で最も包括的なDevSecOpsプラットフォームで実現できる理由をご覧ください。

*注意： ベータ版のプラットフォーム機能は、GitLabベータプログラムの一部として利用できます。ベータ期間中は無料で使用でき、一般提供時には、GitLab Duo Agent Platformの有料アドオンオプションとして利用できるようになります。*

GitLabの最新情報を入手

最新の機能、セキュリティアップデート、パフォーマンス改善を確実に入手するために、GitLabインスタンスを最新の状態に保つことをお勧めします。次のリソースは、アップグレードの計画と完了に役立ちます：

• Upgrade Path Tool — 現在のバージョンを入力すると、インスタンスの正確なアップグレード手順が表示されます
• Upgrade Documentation — サポートされている各バージョンの詳細ガイド（要件、ステップバイステップの手順、ベストプラクティスを含む）

定期的にアップグレードすることで、チームは最新のGitLab機能を活用でき、セキュリティとサポートも確保されます。

アップグレード作業を任せたい場合は、GitLabのManaged Maintenanceサービスをご検討ください。Managed Maintenanceを利用すると、GitLabのエキスパートがSelf-Managedインスタンスのアップグレード、セキュリティの確保、DevSecOps体制の準備を確実に行うため、チームは本来の開発業務に集中できます。詳細については、アカウントマネージャーにお問い合わせください。

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

GitLab Duo Planner Agent（ベータ版）とGitLab Duo Security Analyst Agent（ベータ版）を搭載したGitLab 18.5をリリース

このたび、GitLab 18.5のリリースを発表しました。このリリースでは、GitLab Duo Planner Agent（ベータ版）、GitLab Duo Security Analyst Agent（ベータ版）、Maven仮想レジストリUI（ベータ版）、パーソナルホーム画面など、さまざまな機能が追加されました。

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

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

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

10月28日午前10時（太平洋時間）に開催されるGitLab Developer Showにぜひご参加ください。GitLab 18.5の最新機能を詳しく解説し、活発なコントリビューターコミュニティの育成についてお話しします。実際の機能デモをご覧いただき、リアルタイムでご質問いただけるほか、チームから直接インサイトを得て、GitLabとともに成長する方法を具体的にご紹介します。

今すぐ参加登録

GitLab 18.5では、GitLab Duo Planner Agent（ベータ版）とGitLab Duo Security Analyst Agent（ベータ版）を提供開始しました。

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

今月の注目コントリビューターはJose Gabriel Companioni Benitezさんです

Joseさんはブログ記事「How GitLab Can Boost Your Professional Career」の中で次のように述べています。「プロフェッショナルとしての成長という観点から見て、GitLabが提供する最大の利点は、オープンソースであることです。GitLabにとって、誰もがコントリビュートできることは重要であり、そのため、コントリビューターのオンボーディングプロセスに真剣に取り組んでいます。」

9月に初めてコントリビュートし、10月には注目コントリビューターとなったJoseさんの歩みは、GitLabコラボレーティブコミュニティの力を示すものです。コミュニティオフィスアワー、Discordでのディスカッション、ペアリングセッションへの積極的な参加を通じて、Joseさんはドキュメント、コード、コミュニティサポートにわたる多様なコントリビュートを行うレベル3コントリビューターへと急速に成長できる、協力的な環境を見つけました。

GitLabコミュニティは、コントリビューター同士が支え合い、ともに成長する歓迎の場を提供しています。オープンソースの旅を始めたばかりの方も、スキルを深めたい方も、私たちのコミュニティが皆様の成功をサポートします。

コントリビュートについて詳しくは、GitLab Contributor Platformをご覧ください。

Joseさん、素晴らしい活動をありがとうございます！🚀

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

GitLab Duo Planner：プロダクトマネージャーのための専任エージェント兼チームメイト（ベータ版）

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

GitLab Duo Plannerは、GitLab内でプロダクトマネージャーを直接サポートするために開発されたGitLab Duoエージェントです。手作業でアップデートを追いかけたり、作業の優先順位を付けたり、計画データを要約したりする代わりに、GitLab Duo Plannerがバックログの分析、RICEやMoSCoWなどのフレームワークの適用、本当に注意が必要な項目の抽出をサポートします。計画ワークフローを理解し、より良い意思決定を迅速に行えるよう能動的に支援してくれるチームメイトとして機能します。

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

ドキュメント
イシュー

Security Analyst Agent（セキュリティ分析エージェント）（ベータ版）をGitLab Duoエージェントカタログ向けにリリース

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

GitLab Duo Agent Platformのエージェントを使用すると、GitLab内でタスクを実行したり、複雑な質問に回答したりすることが可能です。ユーザーは、マージリクエストの作成やコードレビューなどの特定のタスクを実行するカスタムエージェントを作成することも、AIカタログを使用してGitLabエージェントを探すこともできます。

GitLab 18.5では、GitLabセキュリティ分析エージェントをベータ版機能としてAIカタログでリリースしました。プロジェクトでGitLabセキュリティ分析エージェントを使用するには、GitLab Duo Agentic Chatでエージェントを選択して有効化します。このエージェントは次のタスクを実行できます：

• 特定のプロジェクト内のすべての脆弱性をリスト表示
• CVEデータやEPSSスコアを含む詳細な脆弱性情報を取得
• 脆弱性を確認または却下
• 脆弱性の重大度レベルを更新
• 脆弱性ステータスをdetected（検出済み）に戻す
• 脆弱性イシューを作成、または脆弱性を既存のイシューにリンク

GitLabセキュリティ分析エージェントを使用することで、AI駆動の自動化や優れた分析により、面倒なセキュリティワークフローを効率化できます。これにより、エンジニアは本当に対応すべき脅威に集中でき、反復的な評価やドキュメント作成といったタスクはGitLabセキュリティ分析エージェントが処理します。

なお、GitLab Duo Chatを使用するGitLabセキュリティ分析エージェントは、GitLab Duoアドオンを持つUltimateのお客様のみご利用いただけます。

この機能はベータ版です。イシュー576916でフィードバックをお待ちしております。

ドキュメント
エピック

Maven仮想レジストリがベータ版として利用可能に

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

GitLab 18.5では、Maven仮想レジストリを管理するのための包括的なWebベースインターフェースを導入しました。これまで、プラットフォームエンジニアはAPI経由でのみ仮想レジストリの構成・管理が可能で、日常的なメンテナンスタスクが煩雑で専門知識が必要でした。

このWebベースのアプローチにより、プラットフォームエンジニアリングチームの運用オーバーヘッドが大幅に削減されます。古いキャッシュエントリのクリア、パフォーマンス最適化のためのアップストリームの並べ替え、接続テストなどの一般的なタスクが、ポイント&クリック操作だけで実行できるようになりました。開発チームは依存関係の構成をより明確に把握できるようになり、ビルドパフォーマンスとセキュリティポリシーについて、より適切な議論が可能になります。

Maven仮想レジストリは、GitLab PremiumおよびUltimateをご利用のお客様向けにベータ版として提供されています。現在のベータ版の制限には、トップレベルグループあたり最大20の仮想レジストリ、仮想レジストリあたり最大20のアップストリームという制限があります。

PremiumおよびUltimateをご利用のお客様には、Maven仮想レジストリベータプログラムにご参加いただき、正式リリースに向けたフィードバックにご協力いただければ幸いです。イシュー543045でフィードバックやご提案をお寄せください。

ドキュメント
エピック

<figure class="video_container">

<iframe src="https://www.youtube.com/embed/CiOZJPhAvaI?si=_ojZqyuQyCJIaKBg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> </figure> <!-- blank line -->

新しいパーソナルホーム画面で作業を再開

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

重要なGitLabアクティビティーをすべて1か所に集約した新しいパーソナルホーム画面にアクセスできるようになりました。中断した作業を簡単に再開できます。このホーム画面では、To-Doアイテム、アサインされたイシュー、マージリクエスト、レビュー依頼、最近表示したコンテンツをまとめて確認でき、GitLabの豊富な機能の中から必要なものをすぐに見つけられるため、優先すべき作業に集中できます。

ドキュメント
エピック

VS CodeおよびJetBrains IDEでGitLab Duo Agentic Chatのモデル選択が可能に

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

VS CodeおよびJetBrains IDEで利用可能なGitLab Duo Chatで、お好みのAIモデルを簡単に選択できるようになりました。GitLab Duo Chatパネルのドロップダウンリストから、Claude、GPT、その他のサポート対象モデルを選択できます。利用可能なモデルは組織の管理者が管理しており、ワークフローに適したモデルを使用できます。

ドキュメント
エピック

GitLab Duo Agentic ChatのモデルオプションとしてGPT-5が利用可能に

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

OpenAI GPT-5が、GitLab Duo Agent Platformのモデル選択肢として、GitLab AIベンダーモデルに追加されました。GitLab.comのトップレベルグループのオーナー、およびSelf-ManagedとDedicatedのインスタンス管理者が設定を行うことで、エンドユーザーはGitLab Duo機能でGPT-5を使用できるようになります。トップレベルオーナーと管理者は、ネームスペースまたはインスタンスの設定から組織全体のモデル設定を引き続き管理できます。また、エンドユーザーが利用可能なすべてのGitLab AIベンダーモデルから自由に選択できるよう許可することも可能です。

GPT-5の使用を開始するには、GitLab Duo Chatのモデルドロップダウンリストからお好みのモデルを選択してください。

ドキュメント
エピック

インスタンス全体のコンプライアンスおよびセキュリティポリシー管理

Self-Managed: Ultimate
GitLab Dedicated: Ultimate

エンタープライズユーザーは、複数のトップレベルグループにまたがってコンプライアンスフレームワークとセキュリティポリシーを管理したいと考えています。これは、インスタンス内のすべてのグループが次のような場合によく見られます：

• 同じコンプライアンスフレームワークを共有している。例：グループ内のすべてのプロジェクトがISO 27001基準に準拠する必要がある場合。
• 類似のセキュリティポリシーを適用している。例：すべてのグループが同じパイプライン実行ポリシーを共有している場合。

GitLab 18.5では、GitLab Self-ManagedおよびDedicatedのインスタンス全体でセキュリティポリシーとコンプライアンスフレームワークの管理を一元化するための、コンプライアンスおよびセキュリティポリシーグループを導入しました。このリリースにより、単一のトップレベルグループからコンプライアンスフレームワークとセキュリティポリシーを作成・設定して割り当て、インスタンス全体の他のすべてのトップレベルグループに適用できるようになりました。

コンプライアンスおよびセキュリティポリシーグループを使用すると、コンプライアンスフレームワークとセキュリティポリシーを管理・編集できる単一の信頼できる情報源を持つことができます。その後、グループ内のセキュリティおよびコンプライアンス担当ユーザーは、インスタンス全体のすべてのプロジェクトにコンプライアンスフレームワークとセキュリティポリシーを適用できます。

コンプライアンスおよびセキュリティポリシーグループにより、インスタンス全体でコンプライアンスとセキュリティのニーズを管理・適用することが容易になります。ただし、各グループは、そのグループ固有の状況やワークフローに対処するために、独自のコンプライアンスフレームワークとセキュリティポリシーを作成する機能を引き続き保持します。

この機能は、GitLab Self-ManagedおよびDedicatedをご利用のお客様向けです。GitLab.comをご利用のお客様は、セキュリティポリシープロジェクトを使用して、単一のトップレベルグループまたはネームスペース内でフレームワークとポリシーを一元管理できます。

コンプライアンスフレームワークとセキュリティポリシーのコンプライアンスおよびセキュリティポリシーグループについての詳細は、ドキュメントをご覧ください。

ドキュメント
エピック

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/TrQCeWsdj1A?si=4EPMy8Ipb0Amon0a" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> </figure> <!-- blank line -->

DAST認証スクリプト

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

CI/CD構成にスクリプトを追加して、DAST認証ワークフローを自動化できるようになりました。認証スクリプトにより、時間ベースのワンタイムパスワード（OTP MFA）のサポートを含む、複雑な認証フローを自動化できます。

この機能強化により、チームは重要なセキュリティコントロールを維持しながら、徹底した自動化されたセキュリティスキャンを実施できるようになりました。実際の認証シナリオをサポートすることで、スクリプトは作業の負担を軽減し、本番環境のソフトウェアに対する正確なセキュリティ評価を実現します。

ドキュメント
エピック

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/EIAPBbFJuuk?si=pVutmmNQdnYRdlbE" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> </figure> <!-- blank line -->

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

イシューとタスクのステータスライフサイクルを設定

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

これまで、イシューとタスクは同じステータス設定を共有する必要がありました。今回のリリースでは、ステータスライフサイクルの設定機能を追加し、プロジェクト内でイシューとタスクそれぞれに異なるワークフローを定義できるようになりました。ワークフロー内にステータスマッピングが組み込まれているため、作業アイテムのタイプを変更する際、一括編集なしでイシューやタスクを新しいステータスに自動的に移行できます。

ユースケースや改善案をフィードバックイシューでお寄せいただき、本機能の向上にご協力ください。

ドキュメント
イシュー

イシューで子タスクの完了状況を確認

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

子アイテムウィジェットから、イシューの進捗状況を直接確認できるようになりました。ステータスを一目で把握できます。この改善により、作業の進行中に発生する可能性があるボトルネックをリアルタイムで可視化し、スプリント期限に影響が出る前にリスクのあるアイテムを素早く特定して調整できます。

ドキュメント
イシュー

environment deployment_tierで変数展開に対応

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

environment:deployment_tierフィールドでCI/CD変数が使用できるようになり、パイプラインの条件に応じてデプロイ層を動的に設定できるようになりました。

ドキュメント
イシュー

高度なSASTでC/C++に対応

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

GitLab高度なSASTにC/C++のベータサポートを追加しました。

この新しいクロスファイル、クロスファンクションスキャン機能を利用するには、C/C++サポートを有効化してください。

本機能についてのご意見・ご質問、または開発チームとの意見交換は、フィードバックイシューをご覧ください。

ドキュメント
エピック

依存関係スキャンが限定提供で利用可能に

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

GitLab 18.5では、依存関係スキャンアナライザーと連携する新しい依存関係スキャンテンプレートをリリースしました。このアナライザーは、すべてのコンポーネントの脆弱性を含む依存関係スキャンレポートを生成します。スキャン実行ポリシー（SEP）とパイプライン実行ポリシー（PEP）が新しいテンプレートに対応しています。

新しいテンプレートを使用するには、Jobs/Dependency-Scanning.v2.gitlab-ci.ymlをインポートしてください。

この機能はGitLab.comとSelf-Managedインスタンスで利用できますが、Self-Managedの公式サポートはまだ開始されていないため、限定提供となっています。GitLab.comユーザーはすぐにご利用いただけます。

本機能についてのご意見・ご質問、または開発チームとの意見交換は、フィードバックイシューをご覧ください。

ドキュメント
エピック

シークレット有効性チェックがベータ版に

GitLab.com: Ultimate
Self-Managed: Ultimate

パイプラインシークレット検出は、プロジェクト内に露出したパスワードやAPIキーなどの認証情報を警告します。しかし、GitLab 18.5以前は、検出された各シークレットが実際に有効なトークンかどうかを手動で確認する必要があり、効果的なトリアージが困難で時間がかかっていました。

有効性チェックがベータ版となり、有効化すると検出されたGitLabシークレットのステータスが表示されるようになりました。有効なシークレットは正当なアクティビティーになりすますために悪用される可能性があり、できるだけ早急にローテーションする必要があります。有効性チェックの動作については、有効性チェックプレイリストをご覧ください。

ドキュメント
エピック

マージリクエスト承認ポリシーの例外設定

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

重大な状況が発生した場合に、特定のユーザー、グループ、ロール、またはカスタムロールがマージリクエスト承認ポリシーをバイパスできるように指定可能になりました。この機能により、包括的な監査証跡とガバナンス管理を保ちながら、緊急時には柔軟に対応できるようになります。

説明責任を伴う緊急バイパス: 指定されたユーザーは、重大なインシデント、セキュリティホットフィックス、緊急の本番環境の問題が発生した際に承認要件をバイパスできます。緊急時には、権限のある担当者が変更を即座にマージまたはプッシュでき、同時にシステムがコンプライアンスレビュー用の詳細な理由と監査情報を記録します。

主な機能：

• 文書化されたバイパスプロセス: 権限のあるユーザーがポリシーバイパスを実行する際、直感的なモーダルインターフェースで詳細な理由の入力を求められます。これにより、すべての例外が適切なコンテキストと共に記録されます。
• 包括的な監査統合: すべてのバイパスについて、ユーザーID、ポリシーコンテキスト、理由、タイムスタンプを含む詳細な監査イベントが生成され、例外の使用パターンを完全に可視化できます。
• 柔軟な設定: YAMLまたはUI設定でポリシー例外の権限を定義でき、個別ユーザー、GitLabグループ、標準ロール、カスタムロールに対応しています。
• Gitベースのプッシュ例外: 事前承認されたポリシー例外を持つユーザーは、プッシュバイパスオプションsecurity_policy.bypass_reasonを指定して直接プッシュできます。

この機能により、緊急時にセキュリティポリシーを完全に無効化する必要がなくなり、組織のガバナンスと監査要件を維持しつつ、緊急変更には管理された方法で対応できるようになります。

ドキュメント
エピック

パイプラインのセキュリティタブでセキュリティ検出のステータスを更新

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

以前は、パイプラインのセキュリティタブで脆弱性を却下しても、リストから即座に削除されませんでした。

パイプラインページのセキュリティタブのステータス更新が、変更後すぐに反映されるようになりました。

ドキュメント
イシュー

外部コントロールステータスのリクエストを制御

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

GitLabでコンプライアンスフレームワークを作成する際、要件に外部コントロールを関連付けることができます。

デフォルトでは、GitLabはコンプライアンススキャン中に12時間ごとに外部システムへ外部コントロールのステータスを自動的にリクエストし、コントロールステータスを’pending’（保留中）に設定します。その後、外部システムは外部コントロールAPIを使用してステータスを’pass’（合格）または’fail’（不合格）に更新する仕組みです。

GitLab 18.5では、外部コントロールを設定する際にPing enabled設定をオフにすることで、この12時間ごとの自動pingを無効化できるようになりました。12時間pingを無効にした場合：

• GitLabは外部システムへステータス更新を自動的にリクエストしません
• 外部コントロールにはコンプライアンスフレームワークUIでDisabled（無効）バッジが表示されます
• 外部コントロールAPIを使用して、外部コントロールステータスの更新タイミングを完全に制御できます

これにより、システムが外部コントロールステータスをpendingにリセットすることを防ぎ、ステータス更新のタイミングを完全に管理できます。

ドキュメント
イシュー

依存関係リストにアクティブな脆弱性のみを表示

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

以前は、依存関係リストに一部の却下済み脆弱性が含まれていました。

依存関係リストの脆弱性をより実用的に表示するため、プロジェクトの依存関係リストには、detected（検出済み）およびconfirmed（確認済み）のアクティブな脆弱性のみが表示されるようになりました。

ドキュメント
イシュー

GitLab Duo Chat（クラシック）でCodestralに対応

Self-Managed: Premium、Ultimate、Duo Enterprise

Gitlab Duo Self-Hostedのクラシック版Duo ChatでMistral Codestralが使用できるようになりました。このモデルは、GitLab Self-ManagedインスタンスでGitlab Duo Self-Hostedをご利用のお客様が使用できます。

ドキュメント
イシュー

GitLab Duo Self-Hosted用のGitLab Duo Agent PlatformでGPT OSSモデルに対応

Self-Managed: Premium、Ultimate、Duo Enterprise

Gitlab Duo Self-HostedのGitLab Duo Agent PlatformでGPT OSSモデルが使用できるようになりました。

グループとプロジェクトの非アクティブアイテム管理を改善

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

非アクティブタブで、GitLab全体のすべての非アクティブアイテムが統一された場所に一貫して表示されるようになりました。これには、アーカイブされたプロジェクト、削除保留中のプロジェクト、削除保留中のグループが含まれます。このタブは、グループ概要ページに加え、マイワーク、プロジェクトを探す、管理エリア全体のグループとプロジェクトリストで利用できます。適切な権限を持つすべてのユーザーが非アクティブアイテムを表示でき、グループオーナー、プロジェクトオーナー、メンテナーのみがさらなる操作を実行できます。この更新の一環として、プロジェクトとグループREST API、GraphQL APIで新しいactiveパラメータが利用可能になりました。

非アクティブコンテンツの管理は、GitLabインスタンスを維持する上で重要です。この更新により、アーカイブされたコンテンツや削除保留中のコンテンツの検索と復元が容易になり、GitLabリソースをより適切に管理しながら、貴重な作業を誤って失うリスクを軽減できます。アクティブコンテンツと非アクティブコンテンツを明確に分離することで、GitLabのすべてのエリアでグループやプロジェクトを閲覧する際の検索体験がより焦点を絞ったものになります。

ドキュメント
エピック

プレーンテキストエディタでMarkdownテーブルをフォーマット

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

整列されていないMarkdownテーブルは、正しくレンダリングされても、読みにくく編集しにくいものです。

プレーンテキストエディタのツールバーにある新しいテーブルの再フォーマット機能で、ワンクリックでテーブルの列を再整列でき、整列設定とインデントが保持されます。使用方法：

1. Wikiページ、イシュー、マージリクエスト内の任意のMarkdownテーブルを選択
2. その他のオプションメニューからテーブルの再フォーマットを選択

これにより、複雑なテーブルを扱う際のドキュメンテーション保守が高速化され、コラボレーションが容易になります。

ドキュメント
マージリクエスト

GitLab Runner 18.5

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

GitLab Runner 18.5も本日リリースしました。GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送り返す高度にスケーラブルなビルドエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。

バグ修正:

• Runnerオペレーターを1.39から1.41に更新した後、バニラKubernetesでRunner更新が失敗する
• 一部のコンテナラベルに重複したプレフィックスがある

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

ドキュメント
イシュー

マージリクエストでの高度なSAST差分ベーススキャン

GitLab.com: Ultimate
Self-Managed: Ultimate\

GitLab高度SASTで、マージリクエスト内のコード変更のみを分析する差分ベーススキャンを実行できるようになりました。リポジトリ全体のスキャンと比較してスキャン時間が大幅に短縮されます。コードベース全体ではなくGit差分のみをスキャンすることで、開発ワークフローにセキュリティテストをよりシームレスに統合でき、速度が落ちたり、マージリクエストの手間が増えたりすることもありません。

このパフォーマンス改善をデフォルトで有効にする作業を進めています。進捗はイシュー546359で追跡されています。

ドキュメント
エピック

高度なSASTのカスタマイズ可能な検出ロジック

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

GitLab高度なSASTで、組織固有のセキュリティ要件とコーディングパターンに合わせたカスタムセキュリティ検出ルールを作成できるようになりました。この機能により、セキュリティチームは事前定義されたルールセットを超えてカスタム脆弱性パターンを定義でき、アプリケーション固有のセキュリティ問題を検出できます。

詳細については、ルールセットのカスタマイズをご覧ください。

ドキュメント
エピック

シークレットプッシュ保護とパイプラインシークレット検出のルールカバレッジを拡大

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

GitLabパイプラインシークレット検出に新しいルールが追加されました。一部の既存ルールも、品質向上と誤検出削減のために更新されました。これらの変更は、シークレットアナライザーのバージョン7.15.0でリリースされています。

ドキュメント
イシュー

静的到達可能性が限定提供で利用可能に、実験的なJavaサポートを追加

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

GitLab 18.5では、静的到達可能性の限定提供サポートをリリースしました。このリリースでは、JS/TSカバレッジサポートの改善、バグ修正、実験的なJavaサポートの提供に重点を置いています。静的到達可能性は、プロジェクトのソースコードをスキャンして使用中のオープンソース依存関係を特定することで、ソフトウェア構成分析（SCA）の結果を強化します。静的到達可能性が生成するデータは、トリアージや修正の意思決定に活用できます。また、CVSSやEPSSスコア、KEVインジケーターと組み合わせて、特定された脆弱性をより焦点を絞って表示することもできます。

本機能についてのご意見・ご質問、または開発チームとの意見交換は、フィードバックイシューをご覧ください。

ドキュメント
エピック

脆弱性APIから元の重大度を公開

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

脆弱性GraphQL APIで、脆弱性の元の重大度が取得できるようになりました。これにより、重大度の上書きが適用される前の脆弱性の重大度を判断できます。

ドキュメント
イシュー

マージリクエスト承認ポリシーのタイムウィンドウ

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

セキュリティ脆弱性の比較においてさらなる柔軟性を提供するため、マージリクエスト承認ポリシーにタイムウィンドウを導入しました。最新のベースラインのセキュリティレポートがまだ利用できない場合、この新しいポリシー設定により、指定した期間内であれば以前に完了したセキュリティレポートを使用できます。

開発チームは、非常に忙しいプロジェクトなどでベースラインのセキュリティスキャンが停滞したり時間がかかりすぎたりしている場合に、不要な遅延を回避できるようになりました。タイムウィンドウを設定することで、新しい脆弱性を導入しないマージリクエストは、最新のパイプラインの完了を待たずに進行でき、ワークフローの効率が向上します。

この機能を使用するには、マージリクエスト承認ポリシーを作成または編集し、承認ポリシー設定でsecurity_report_time_windowパラメータ（分単位）を指定してください。

システムは、指定されたタイムウィンドウ内に作成されたセキュリティレポートを使用して最新のパイプラインと比較し、新しい脆弱性が導入されていない場合により迅速な承認を可能にします。

ドキュメント
イシュー

GitLab Duo Agentic Chatの新しい脆弱性管理機能

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

GitLab Duo Agentic Chatは、GitLab Duo Chatの強化版です。GitLabプロジェクト全体の複数のソースから情報を検索、取得、統合して、より徹底的で関連性の高い回答を提供します。プロジェクトの検索、ファイルの読み取りとリスト表示、GitLab Duo Chatに提供されたプロンプトに基づくファイルの自律的な作成と変更など、いくつかのユースケースがあります。

GitLab 18.5では、Agentic Chatのユースケースが拡張され、セキュリティスキャナーからの脆弱性管理が含まれるようになりました。Agentic Chatに脆弱性管理ツールを追加することで、AIを活用した自動化とインテリジェントな分析により面倒なセキュリティワークフローが変革され、セキュリティ専門家が自然言語コマンドで脆弱性を効率的にトリアージ、管理、修正できるようになります。これにより、脆弱性ダッシュボードを手動でクリックする何時間もの作業が不要になり、以前はカスタムスクリプトや面倒な手動作業が必要だった複雑な一括操作が効率化されます。

GitLab Duo Chatに追加された新しい脆弱性管理ツールにより、GitLab Duoをご利用のUltimateユーザーは次のことができます：

• 特定のプロジェクト内のすべての脆弱性をリスト表示
• CVEデータやEPSSスコアを含む詳細な脆弱性情報を取得
• 脆弱性の確認と却下
• 脆弱性の重大度レベルを更新
• 脆弱性のステータスをdetected（検出済み）に戻す
• 脆弱性イシューの作成、または既存のイシューへの脆弱性のリンク

これらのツールは、セキュリティワークフローを反応的な手動トリアージからインテリジェントな修正へと変革し、エンジニアが真の脅威に集中できるようにし、AIが繰り返しの評価とドキュメント作成を処理します。GitLab Duo Chatを使用した脆弱性管理は、GitLab Duoアドオンをお持ちのUltimateのお客様のみが利用できます。

ドキュメント
エピック

CLIエージェントの追加トリガー

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

追加のイベントでCLIエージェントをトリガーできるようになり、プロジェクト全体でエージェントがアクションを実行する場所とタイミングについて、より柔軟な制御が可能になりました。既存のメンショントリガーに加えて、次のトリガーが使用できます：

• 割り当て: マージリクエストまたはイシューが割り当てられたときにエージェントをトリガー
• レビュアーを割り当て: マージリクエストにレビュアーが追加されたときにエージェントをトリガー

ドキュメント
イシュー

管理エリアのグループリストを強化

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

管理エリアのグループリストをアップグレードし、GitLab管理者により一貫した体験を提供します：

• 遅延削除保護: グループの削除がGitLab全体で使用されている同じ安全な削除フローに従うようになり、偶発的なデータ損失を防ぎます
• 高速な操作: ページのリロードなしでグループのフィルタリング、ソート、ページネーションを実行でき、よりスムーズな操作を実現
• 一貫したインターフェース: グループリストがGitLab全体の他のグループリストの外観と動作に一致するようになりました

この更新により、管理者の体験がGitLabのデザイン標準に沿ったものになり、データを保護する重要な安全機能が追加されます。グループ管理の今後の機能強化は、プラットフォーム全体のすべてのグループリストに自動的に反映されます。

ドキュメント
エピック

GitLab Duo Self-Hosted用のGitLab Duo Agent Platformがベータ版に

Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Agent PlatformがGitLab Duo Self-Hostedでベータ版になりました。この機能は、すべてのSelf-Managed GitLab Duo Enterpriseのお客様にご利用いただけます。AWS BedrockまたはAzure OpenAIを使用しているSelf-Managedインスタンス管理者は、GitLab Duo Agent Platformで使用するためにAnthropic ClaudeまたはOpenAI GPTモデルを設定できます。Self-Hosted管理者は、Gitlab Duo Agent Platformで使用する互換性のあるモデルを設定することもできます。

ドキュメント
イシュー

グループの更新されたナビゲーション体験

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

グループ一覧の表示を改良し、GitLab全体でより統一感のある使いやすい操作性を提供します。これらの改善により、グループやプロジェクトの閲覧が簡単になり、必要な情報をひと目で確認できるようになります：

• より豊富なプロジェクト情報: プロジェクトにスター、フォーク、イシュー、マージリクエスト、関連する日付が表示され、アクティビティーの完全な概要を一目で確認できます
• 効率化されたアクション: アクションメニューで概要から直接グループやプロジェクトを編集または削除できます。アーカイブされたアイテムや削除保留中のアイテムは、非アクティブタブに表示されます
• 一貫した体験: グループ概要がGitLab全体の他のグループとプロジェクトリストの外観と動作に一致し、より直感的な体験を実現します

これらの機能強化により、より多くの情報や操作をすぐに利用できるようになり、効率が向上します。さらに、この更新は、一括編集や高度なフィルタリングオプションなど、今後追加される機能の土台にもなります。

ドキュメント
エピック

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

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

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

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

非推奨

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

• GitLab Duo Self-Hostedにおける初期Mistralモデルの非推奨化\
• 高度な検索でのOpenSearch 1.xのサポート

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

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

• GitLab Duo Self-Hostedにおける初期Mistralモデルの非推奨化
• 高度な検索でのOpenSearch 1.xのサポート

変更履歴

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

• GitLab
• GitLab Runner
• GitLab Workflow for VS Code
• GitLab CLI

インストール

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

更新事項

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

ご不明な点がある場合

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

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

• Free

  ユーザー向けの永久無料機能を提供

• Premium

  チームの生産性と調整を強化

• Ultimate

  組織全体のセキュリティ、コンプライアンス、プランニングに対応

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

--------------------

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

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

• GitLab 18.5
• GitLab 18.4
• GitLab 18.3
• GitLab 18.2
• GitLab 18.1
• GitLab 18.0
• GitLab 17.11
• GitLab 17.10
• GitLab 17.9
• GitLab 17.8
• GitLab 17.7
• GitLab 17.6
• GitLab 17.5
• GitLab 17.4
• GitLab 17.3
• GitLab 17.2
• GitLab 17.1
• GitLab 16.11

目次

• SaaSとは？
• ソフトウェア利用モデルの比較
• SaaSのメリット
• SaaSのデメリット
• SaaSとPaaS・IaaSの違いとは？
• SaaSを選ぶ際のポイント
• 代表的なSaaSと主な機能
• GitLabはソフトウェア開発にどのように貢献するのか？
• SaaSやGitLabに関するFAQ

SaaSとは？仕組みやクラウドとの違い

SaaSは「Software as a Service」の略称で、読み方は「サース」もしくは「サーズ」です。日本語にすると「サービスとしてのソフトウェア」となります。

SaaSは、サービス提供会社（ベンダー）のサーバーで提供されているソフトウェアを、インターネットなどのネットワークを介して利用できるサービスのことです。自身のパソコンや自社サーバーにソフトウェアをインストールしなくても、インターネット経由で最新のサービスを利用できます。

SaaSの例としてよく挙げられるのがGoogleが提供しているGoogleドキュメントやGoogleスプレッドシート、Googleドライブなどです。特定のソフトウェアやアプリをインストールしなくても、これらの機能をオンライン上で自由に利用できます。

弊社が提供しているソフトウェア開発プラットフォーム「GitLab」も、ソフトウェア開発に関するSaaSの代表格の1つです。

SaaSの仕組み

一般的なソフトウェアは自社のサーバーやパソコンなどにインストールして利用しますが、SaaSの場合には、サービス提供会社のサーバーにてソフトウェアが起動しています。インターネットを介してサービス提供会社のサーバーに接続し、そこでソフトウェアを利用する、というのがSaaSの主な仕組みです。

提供会社がソフトウェアを頻繁にアップデートしているため、最新のサービスがどこからでも、どのデバイスからでも利用できます。

SaaSとクラウドサービスの違い

よく似た言葉に「クラウドサービス」があります。同様の意味合いで使われる用語ですが、クラウドサービスはアプリに限定されないより広範な概念です。後に説明するPaaSやIaaSなどもクラウドサービスに当てはまります。クラウドサービスの1つがSaaSだと考えるとよいでしょう。

ソフトウェア利用モデルの比較

企業がソフトウェアを利用する方法は主に以下の3つです。

• オンプレミス型
• インストール型
• SaaS

それぞれの特徴について簡単に説明します。

オンプレミス型

オンプレミス型とは、自社のサーバーにソフトウェアを組み入れ、自社独自のシステムを構築する方法です。思い通りにカスタマイズできる、情報漏洩のリスクが少ないなどのメリットがありますが、一方で構築までに時間と費用がかかる、保守が正しくできないとセキュリティリスクが高まるなどのデメリットもあります。

インストール型

インストール型は、ソフトウェアを利用予定のパソコンにインストールすることで、そのパソコンでのみ機能が使えるようにする方法です。オンプレミス型に比べると低価格で利用できる、導入に時間がかからないなどのメリットがありますが、一方で機能の拡張が難しい、アップデートのし忘れによるセキュリティ脆弱性リスクが高いなどのデメリットがあります。

SaaS

昨今の主流となっているSaaSは、運営会社が管理しているサービスにインターネットを介してアクセスし、オンライン上で利用する方法です。 より最先端の機能を利用したい、セキュリティに配慮したソフトウェアを利用したい、料金を安く抑えたいなどのニーズの増加により、オンプレミス型やインストール型ではなく、SaaSを利用する企業が増えています。

SaaSのメリット

SaaSには、オンプレミス型やインストール型にはない数々のメリットがあります。

最新の機能を利用できる

サービス提供会社が自社のサーバー内でソフトウェアのアップデートを行い、そのサービスをインターネットを経由して利用するため、常に最新の機能やデザインを利用できます。

利用開始までの時間が短い

SaaSはインターネット上で契約と支払いを済ませたら、即座に利用が可能です。最低利用期間が定められているSaaSが多いものの、解約手続きも比較的簡単です。

導入費用を抑制できる

多くのSaaSは初期導入費用が無料、もしくはオンプレミス型と比べて安い傾向にあります。 初期投資で大きな資金を準備することが難しい企業にとっては、毎月支払いのSaaSの料金プランは大きな魅力といえます。

セキュリティ対策に強い

SaaSはサービス提供会社がソフトウェアに対してセキュリティ対策を実施します。自社でセキュリティ対策を行う必要がないため、人件費や労力を削減できるとともに、高い安全性が確保されたソフトウェアを使い続けることが可能です。

場所を選ばない

SaaSはインターネットさえ使えれば、どこにいても、どのデバイスからでも同様のサービスやデータにアクセスできます。急な出張が入り自身のパソコンを利用できない場合でも、別のパソコンを使ってログインすることで、普段と同じデータにアクセスできます。 昨今拡大しているリモートワークとも相性のよいモデルとして需要が高まっています。

複数人での利用に強い

SaaSは複数人による利用に優れています。元となるデータがクラウドサーバー上に保存されているため、複数人がそのデータに直接アクセスし、同時並行で作業を進められます。

例えば、ソフトウェア開発に関するSaaSを利用すれば、複数のデベロッパーが同時に作業を行い、それぞれの作業を即座に反映させることが可能です。

SaaSのデメリット

多くのメリットがあるSaaSですが、もちろんいくつかのデメリットもあります。SaaSを利用する際には、これらのデメリットについてもよく理解し、事前に対策を練るようにしてください。

ソフトウェアアップデートによる急な仕様の変更

SaaSは、サービス提供会社によって常にアップデートが行われています。方向性の転換により、操作画面の機能やデザインが急に変更になったり、これまで頻繁に使っていたシステムがなくなったりすることがあります。以前のバージョンが使いやすかったと感じても、自社の判断によって戻すことはできません。

継続的な出費が発生する

初回導入時には比較的予算が抑えられるSaaSですが、月額・年額の継続費用が発生し、長期利用ではコストが高くなる場合があります。

ログイン情報の漏洩によるセキュリティリスク

サービスにアクセスするためのログイン情報が漏れた場合、他者にアクセスされる可能性が生じます。二段階認証プロセスを利用することで不正なアクセスは防げるものの、ログイン情報の管理については慎重に実施する必要があります。

ネットワーク環境の影響を受ける

SaaSは、インターネットが利用できない場所では利用できません。停電やネットワークエラーによってインターネットが使えない場合、SaaSにアクセスできなくなり、作業が一時中断してしまう可能性があります。

SaaS側の不具合やメンテナンス

SaaSが何らかの不具合に直面した場合、もしくは大規模なシステムアップデートのため長期に及ぶメンテナンスが必要になった場合には、サービスが一時的に利用できなくなる可能性があります。 利用予定のSaaSが頻繁なメンテナンスを実施していないか、メンテナンスの場合には代替機能が利用できるかどうかを事前にチェックするとよいでしょう。

SaaSとPasS・IaaSの違いとは？サービス内容も紹介

SaaSとよく比較される用語に「PaaS」と「IaaS」があります。自社に最適な機能を選ぶうえで、これらの違いを理解することは非常に重要です。

PaaSとは

PaaSは「Platform as a Service」の略称で、「パース」と読みます。名称からもわかる通り、PaaSは主にクラウド上で利用できるプラットフォームを指します。PaaSの提供範囲は主にプラットフォームのため、ソフトウェアやアプリは含みません。 例えばPaaSは、システムやアプリケーションを開発するためのプラットフォームをクラウド上で提供します。複数のデベロッパーが同時にアクセスし、協力体制のもとでアプリケーション開発などを進める場合に役立ちます。

IaaSとは

IaaSは「Infrastructure as a Service」の略称で、「イーアス」や「アイアース」と読みます。IaaSがクラウド上で提供するのはサーバーやネットワークなどのインフラ基盤のみです。ソフトウェアやプラットフォームなど、事前に構築されたシステムや枠組みがないため、より自由な開発環境を整えたい企業に向いています。ただし、開発環境の構築も含めて自社で実施するだけの人材力やスキルが必要とされます。

SaaS・PaaS・IaaSの比較

SaaSとPaaS、IaaSの各サービス内容をまとめると、以下のようになります。 表1　SaaS・PaaS・IaaSが網羅するサービスの比較

SaaSはすべてを網羅しているとはいえ、ミドルウェアやOSの使い勝手や機能に関してはPaaSがより優れています。IaaSは質の高いインフラ基盤を比較的安価に導入できる方法として、SaaSやPaaSとは差別化できます。

それぞれの特徴をよく理解した上で、自社に最適なサービスを導入することが重要です。

SaaSを選ぶ際のポイント

自社の現状や課題に合ったSaaSを利用することで、業務効率化やコスト削減を実現することができます。一方で、自社に合わないSaaSを選んでしまうと、不慣れな作業によって時間がかかったり、せっかく購入したにも関わらず活用されなかったりする場合があります。 そのため、SaaSを導入する際には以下のポイントをよく確認するようにしてください。

機能性

SaaSの機能は事務系やコミュニケーション系、ソフトウェア開発系など多岐にわたります。自社で解決したい課題をリストアップするとともに、どの機能を備えたSaaSが最適かをよく検討するようにしてください。 また、用途だけでなく、機能や操作画面の使い勝手も確認するとよいでしょう。例えば、日本語に最適化されていないSaaSでは、言語の違いによりスムーズに利用できない可能性があります。

ミスマッチを防ぐためにも、まずは無料トライアルを提供しているSaaSを選び、試してみることをおすすめします。

コストや料金体系

SaaSは初期費用が比較的安く設定されているのが特徴です。ただし、毎月もしくは毎年費用が発生するため、長期的にみると大きな費用負担になる場合があります。多くのSaaSは1ユーザーごとの料金設定のため、大勢で利用した場合にはコストが大きくなります。

また、SaaSは最低利用期間や解約までに必要な月数などが設定されている場合がほとんどです。解約しやすいのがSaaSの特徴の1つですが、場合によっては解約時にも費用が発生する点にも注意が必要です。

セキュリティ

SaaSでは、システム利用やデータの保管はすべてサービス提供会社のサーバー内で行われるため、自社でセキュリティ対策を実施する必要はありません。ただし、提供会社側でセキュリティ問題が発生した場合には、重要なデータが消去もしくは漏洩する可能性があります。

SaaSを利用する際には、セキュリティ対策の充実度をしっかりと確認するようにしてください。

サポート体制

SaaSは様々な機能が随時追加されるため、機能やデザインなどに関して、サポートの助けが必要になることが多々あります。特に緊急性のある案件に関係するSaaSにおいては、電話対応や24時間のチャットサポートに対応しているかは重要です。また、海外発のSaaSを利用する際には、日本語サポートにも対応しているかを確認するようにしてください。

代表的なSaaSと主な機能

企業が導入を検討すべきおすすめのSaaSを紹介します。

オフィス業務に強い「Google WorkSpace」

「Google Workspace」は、Google社が提供する有料オンラインアプリケーションセットです。GoogleドキュメントやGoogleスプレッドシート、Googleドライブ、Gmailなど、オフィス作業や業務効率化に役立つ数々のツールが利用できます。データはすべてGoogleのサーバー内に保管され、Googleが常に最新のセキュリティ対策を行っているため、安心して利用できます。

利用には一定の費用が掛かりますが、様々な便利機能を安心して利用したい企業におすすめです。

気軽なチャット機能が人気「ChatWork」

多くの企業が導入しているチャット型のコミュニケーションツールが「ChatWork」です。メールでのやりとりでは、文章を作成したり回答を得たりするのに時間がかかりますが、ChatWorkのチャットであれば時間を大幅に削減できます。

チャットデータはすべてChatWorkが管理するサーバー内に保管されているため、パソコンやスマホ、タブレットなど、デバイスを選ばずに利用できます。日本企業が開発したSaaSのため、日本人が使いやすいように設計・最適化されているのも大きな魅力といえます。

フリープランは無料で利用できますが、ビジネス用途であれば高いセキュリティ性能を備えたエンタープライズプランがおすすめです。現在社内でのやりとりでメールを利用している、社員間のコミュニケーションを促進するツールを探している企業に最適です。

オンラインミーティングの大改革を果たした「Zoom」

ミーティングや営業のあり方を大きく変えたことで知られるのが「Zoom」です。インターネットを利用したオンラインミーティングが実施でき、異なる場所や出張時・在宅ワークなどでのミーティング参加が可能となりました。

また、Zoomは営業向けにも様々な便利機能を追加しており、録画機能や自動文字起こし、資料の共有、スケジュール管理など、1つのツールで多様な課題を解決できます。

無料のベーシックプランでもオンラインミーティング機能は利用できますが、長時間のミーティングを開催したい、より便利な機能を利用したいという方は、有料のビジネスプランがおすすめです。

アプリケーション開発に最適な「GitLab」

アプリケーション・ソフトウェア開発におすすめのSaaSが、弊社が提供する「GitLab」です。AI搭載のDevSecOpsプラットフォームで、開発効率化やセキュリティに優れています。

複数のデベロッパーが同時並行で作業できるマルチテナント環境を提供するとともに、AIを含めた様々な便利アプリにより開発を効率化できます。

ビジネス目的であれば、より多くの機能が利用でき、かつセキュリティも充実している「Premium」や「Ultimate」などの有料プランがおすすめです。60日間の無料トライアルもあるため、まずはお気軽にお問い合わせください。

また、より迅速に開発を進めたい方向けに、シングルテナント型SaaSで提供される「GitLab Dedicated」サービスもあります。GitLabチームがプラットフォーム管理やデプロイを担当するため、必要な作業が大幅に削減され、重要なタスクに注力可能です。

GitLabはソフトウェア開発にどのように貢献するのか？

GitLabは、クラウド上で機能するソフトウェアアプリケーション開発プラットフォームです。企業は開発、保護、そしてデプロイの複雑化に効果的に対応でき、結果としてサイクルタイムを1/7に短縮できる可能性があります。 デベロッパーの生産性が向上するとともに、メンテナンスに必要な時間を削減できるため、多くの時間をより重要な作業に費やすことが可能です。スピーディで効率的な開発を行うことで、他社と差別化できます。

従来からDevSecOpsプラットフォームの開発に専念してきたGitLabでは、特にセキュリティ分野において優位性を持ちます。GitLabのセキュリティ対策チームが常に最新のセキュリティ対策を研究し、ツールに導入しているため、弊社SaaSを利用する際には、すでに最新の対策が施されている状態です。これにより、開発したソフトウェアの安全を確保します。

SaaSやGitLabに関するFAQ

SaaSやGitLabに関するFAQについて以下にまとめてあります。ぜひ参考にしてください。

GitLabではどのようなSaaS開発環境やオプションが可能か？

GitLabでは、GitLabプラットフォームが自由に使えるマルチテナントSaaSと、デプロイや管理をGitLab側で担当するシングルテナントSaaSのGitLab Dedicatedのどちらかをお選びいただけます。また、GitLabではオンプレミスにも対応しています。
SaaSによるソフトウェア開発が初めてで管理や操作に不安が残る方には、GitLab Dedicatedをおすすめします。ぜひご検討ください。

開発分野のSaaSに限定した場合、オンプレミスと比べてどのようなメリットがあるか？

オンプレミス型の開発環境の場合、セキュリティやガバナンス対策を自社ですべて実施する必要があります。人材を保守や運用、調査などに回す必要があるため、大きな人的コストがかかるのと同時に、開発速度も遅くなります。

SaaSによる開発環境では、セキュリティやガバナンスをGitLabが調査、適用するため、保守運用にかかる時間を大幅に削減できます。昨今は必要なセキュリティ対策やガバナンス対策が頻繁に変化する時代です。SaaSによる開発環境を利用することで、それらの心配をする必要がなくなり、重要な作業に集中できます。

その他のSaaS開発環境と比較した際のGitLabの強みとは

GitLabは、ソフトウェア開発のライフサイクル全体に対応するDevSecOpsプラットフォームです。Fortune100企業の50％強が利用し、登録ユーザー数は2024年時点で約3,000万人を超えています。

GitLabは迅速かつ効率的なソフトウェアデリバリーを実現する包括的なプラットフォームとして常に進化を遂げてきました。また、早くからセキュリティやコンプライアンスを重要な軸として位置づけ、プラットフォーム内に機能を組み入れてきた歴史があります。

昨今はセキュリティに配慮しつつ、ガバナンスやコンプライアンスを順守しながらソフトウェア開発を進めていく必要があります。しかしながら、優秀なデベロッパーが保守運用に時間をとられ、何よりも重要な開発作業に時間を割けない問題が多くの企業で発生しています。GitLabプラットフォームを利用することで、デベロッパーがセキュリティ対策やエラー修正にかける時間を大幅に削減できます。

GitLabは、設立当初から、リモートワーク、オープンソース、DevSecOps、イテレーションへの確固たる信念を持ち続けてきました。GitLabは新しいイノベーションを模索し続けます。より優れた開発プラットフォームを模索している企業様に、GitLabは最先端・最高品質のサービスを提供いたします。

金融業界のリーダーたちによる最新の経営層インサイト、ドイツ鉄道社（Deutsche Bahn）の変革ストーリー、そして世界各地で開催されるイベント情報もお届けします。

さらに、今月のおすすめ記事や、少し前向きになれるインスピレーションもお届けします。

それでは、さっそく見ていきましょう👇

GitLab 18.4：AIネイティブ開発をさらに拡張

失敗したデプロイを何時間も追跡したことがあるなら、現代の開発はコードを書くことと同じくらい「複雑さの管理」が重要だと感じたことがあるはずです。GitLab 18.4では、DevSecOpsのライフサイクル全体にAIを組み込むことで、その課題をより簡単に解決できるようになりました。

新機能：

• GitLab Duo AI Catalog（AIカタログ） – 組織内でカスタムエージェントを定義、作成、共有可能。可視性の設定で、安全に実験し、非公開にするものと広く再利用できるものを選べます。これにより、エージェント管理を一元化し、Duo Agent Platformの基盤として統合・協調された知能のハブを構築できます。
• スマートなエージェント型チャット – AIエージェントとリアルタイムで協働できます。新しいセッションビューでエージェントのアクティビティ、ログ、コンテキストを確認できるため、AIがどのように作業を前進させているかを常に把握できます。
• 強化されたGitLab Knowledge Graph（ナレッジグラフ） – コードベースをより深いコンテキストで検索可能。ルートファイルから依存関係の影響まで、オンボーディングが容易になり、デバッグが迅速化し、調査が正確になります — 人間にもAIエージェントにも有効です。
• ビジネスに配慮したパイプライン自動化 – パイプラインは現代のソフトウェアデリバリーの心臓部です。今では、エラーを修正するだけでなく、ビジネスへの影響や優先度を理解した上で修正を提案・実行できる自動化が可能です。
• ガバナンスとセキュリティ – GitLab Duoのコンテキスト除外機能、拡張されたModel Context Protocol（MCP）ツール、GitLab管理キー、一般提供が開始したGitLab Duoモデル選択により、企業はAIの展開方法やアクセス可能なデータを制御可能です。イノベーションの速度を落とすことなく、安全に導入できます。

これらの機能により、GitLab 18.4は単なるアップグレードではなく、AIとの協働をより速く、コンテキストを理解し、コントロールできる形で実現する革新的な一歩となります。

🔗 18.4リリースノート全文はこちら

金融業界の経営層インサイト：7,500億ドルを超えるチャンス

最新のGitLab金融業界経営調査では、AIが業界にどれほどの影響を与えているかが明らかになりました。

銀行、保険、資本市場の経営者は、AI搭載のソフトウェア革新に大きなチャンスを感じています：

• AIによるソフトウェア革新で得られる世界規模の潜在価値：7,500億ドル以上
• 金融サービス業界の95%の経営者が、ソフトウェア革新を現在のコアビジネスにおける優先事項と認識
• 過去1年間で、AI投資によるビジネス成長を経験したと答えた経営者は93%
• 93%の経営者が、エージェント型AIが3年以内にソフトウェア開発の業界標準になると予測

金融リーダーからのメッセージは明確です。AIの潜在力を最大限に引き出すには、技術だけでなく、信頼性、ガバナンス、スキル向上が不可欠です。

🔗 レポート全文はこちら

今後のイベント：10月の予定

10月はGitLabチームにとって盛りだくさんの月です。参加予定のイベントはこちら：

• Cloud & AI Infrastructure Expo, シンガポール (10/8–9) – Tech Week Singaporeの一環として、6つの主要テックイベントが一堂に会しました。GitLabブースでは、最新のDevSecOpsとAIに関する情報で盛り上がりました。
• GitLab DACH Roadshow, ミュンヘン (10/14) – エンジニアリングリーダーやDevSecOps専門家と共に、実際の顧客事例、ハンズオンワークショップ、ネットワーキングを体験。参加無料（ランチ付き）。
• Gartner IT Symposium/Xpo, オーランド (10/20–23) – 年間最大規模のテックイベントの1つ。GitLabがどのようにAIネイティブDevSecOpsの変革を推進しているかを紹介。
• GitLab DACH Roadshow, デュッセルドルフ (10/28) – コミュニティとの交流、インサイトの共有、そして技術的な課題へのサポートを行います。

参加予定の方は、ぜひブースにお立ち寄りください！

🔗 世界各地のイベント情報はこちら

GitLabハッカソン：貢献・協働・創造

10月1日〜8日にかけてGitLabハッカソンが開催されました。

ハッカソンは1週間のオンラインイベントで、誰でもGitLabプロジェクトにコントリビュートできます。楽しみながらインパクトを生み出すことが目的です。

参加のメリット：

• 🏆 賞品獲得、プロファイル実績のアンロック、GitLabスキル向上
• 💻 コーディング、ドキュメント作成、翻訳、UXデザインなどの実践経験
• 🌍 DevSecOpsに熱意を持つ世界中のオープンソースコミュニティと協働

初めてのマージリクエストでも100回目でも、誰でも参加可能です。今後も開催予定ですので、学び、作り、つながるチャンスをお見逃しなく。

🔗 ハッカソン登録はこちら

事例のご紹介：ドイツ鉄道社（Deutsche Bahn）

今月は、ドイツの国営鉄道でありヨーロッパ最大級の鉄道事業者であるドイツ鉄道社、　Deutsche Bahnをフィーチャー。約34万人の従業員と年間20億人の乗客を抱える同社は、デジタル成長のためにDevSecOpsを統合する単一プラットフォームを必要としていました。

GitLab Premiumを導入したことで、ソフトウェア開発と運用が大きく変革：

• 📈 継続的デプロイの成功率91%
• 📈 35のDevSecOpsチーム間のコラボレーション向上
• 📈 コンプライアンスの簡略化とシステム信頼性向上

さらに、インフラコストを10〜20%削減し、2,300万人のユニークユーザー向けの世界クラスの予約システムを構築しました。

Martin Ortmann氏（プロダクトオーナー）のコメント：

「共同作業ができるプラットフォームのおかげで、学びや議論が活発になり、大きな成果につながっています。GitLabは私たちの協働と成功に欠かせない存在です。」

まさに、1つのDevSecOpsプラットフォームに統合した成果が、その背景にあります。

🔗 Deutsche Bahnのケーススタディ全文はこちら

今月のおすすめ記事 📚

今月のおすすめは、次の戦略セッションに役立つインサイト満載の記事です。

https://thenewstack.io/sustainable-scale-how-to-grow-engineering-teams-strategically/

https://social-www.forbes.com/councils/forbestechcouncil/2025/09/09/softwares-agentic-future-is-less-than-3-years-away-cisos-must-prepare-now/?

https://www.washingtontechnology.com/opinion/2025/09/bridging-gap-legacy-systems-secure-ai-innovation/407991/

https://vmblog.com/archive/2025/09/09/authorization-systems-aren-t-built-for-ai-agents-here-s-how-to-adapt.aspx

最後に、今月の名言を

ヘンリー・フォード（フォード・モーターの創設者）はこう言いました：

「皆が一緒に前進すれば、成功は自然についてくる」

GitLabもまさにこれを目指しています！ チームが一緒に、より速く、安全に、成功を手にできるよう支援することが私たちの使命です。

今月もお読みいただきありがとうございます。それでは次回まで、Happy Merging!

Fatima Sarah Khalid | Developer Advocate, GitLab

このニュースレターが役立ったら、ぜひチームにもシェアしてください。 そして忘れずに👉 YouTubeチャンネルもご登録を！

他のベンダーがクラウド専用のアーキテクチャへの移行を強制する一方で、GitLabはお客様のビジネスニーズに合った導入選択肢をサポートし続けることに引き続きコミットしています。機密性の高い政府データを管理する場合でも、エアギャップ環境で運用する場合でも、単に自社管理型による管理性を好む場合でも、GitLabはすべての組織に同じアプローチが適用できるわけではないことを理解しています。

クラウドがすべての組織にとって最適解とは限らない

Data Centerの導入に多額の投資を行ってきた多くの企業にとって、特にServer製品が廃止された後にData Centerに移行した企業にとって、今回の発表は単なる製品のサポート終了以上の意味を持ちます。これは、お客様中心のアーキテクチャ選択からの根本的な転換を示すシグナルであり、企業を困難な立場に追い込むものです。つまり、自社のニーズに合わない導入モデルを受け入れるか、要件を尊重するベンダーを見つけるかの選択を迫られるのです。

自己管理型の導入を必要とする組織の多くは、世界の重要なインフラや機密データを担う組織です。患者データを保護する医療システム、数兆ドルの資産を管理する金融機関、国家安全保障を守る政府機関、そしてエアギャップ環境で運用する防衛関連企業などです。

これらの組織は、利便性のために自己管理型の導入を選択しているのではありません。クラウド専用のアーキテクチャでは単純に対応できないコンプライアンス、セキュリティ、データ主権性の要件を満たすために選択しているのです。インターネットアクセスが制限されている、またはまったくない完全に閉鎖された環境で運用している組織は例外ではありません。むしろ、さまざまな業界のエンタープライズ顧客層の重要な一部を占めているのです。

強制的なクラウド移行の真の代償は金額以上のもの

クラウド専用ベンダー強制移行を「アップグレード」として位置づける一方で、実際には組織は単純な財務コストを超えた重大な課題に直面しています。

• 統合機能の喪失: レガシーシステムとの長年のカスタム統合、綿密に作り上げたワークフロー、企業固有の自動化プロセスがすべて使えなくなります。レガシーシステムとの深い統合を持つ組織では、クラウド移行が技術的に実行不可能であることがよくあります。

• 規制上の制約: 厳密な規制対象業界の組織にとって、クラウド移行は複雑であるだけでなく、多くの場合許可されていません。データレジデンシー要件、エアギャップ環境、厳格な規制フレームワークは、ベンダーの都合に合わせて妥協されることはありません。多くのクラウド専用アプローチにおけるシングルテナントソリューションの欠如は、克服できないコンプライアンス上の障壁を生み出します。

• 生産性への影響: クラウド専用アーキテクチャでは、複数の製品を使い分ける必要性がよくあります。つまり、計画、コード管理、CI/CD、ドキュメント用に別々のツールが必要になります。その結果、ツール間の切り替えや、統合の維持と言った負担が増え、潜在的な障害リスクも高まります。GitLabの調査によると、デベロッパーの30%が、業務時間の少なくとも50%をDevSecOpsツールチェーンの維持や統合に費やしています。断片化されたアーキテクチャは、この課題を解決するどころか、むしろ悪化させているのです。

GitLabは選択肢、コミットメント、統合を提供

エンタープライズのお客様には、信頼できるテクノロジーパートナーが必要です。そのため、GitLabはさまざまな導入形態のサポートにコミットしています。コンプライアンス対応でオンプレミス環境が必要な場合も、柔軟性のためにハイブリッド環境が必要な場合も、利便性のためにクラウドが必要な場合も、選択肢はお客様にあります。このコミットメントは、ワークフローのあらゆる段階で開発者をサポートするAIソリューションであるGitLab Duoにも受け継がれています。

GitLabが提供するのは導入の柔軟性だけではありません。他のベンダーが製品を断片化されたツールチェーンに組み合わせることを強制する可能性がある一方で、GitLabは 包括的なAIネイティブDevSecOpsプラットフォーム ですべてを提供します。ソースコード管理、CI/CD、セキュリティスキャン、アジャイル計画、ドキュメントのすべてが、1つのアプリケーションと1つのベンダー関係で完結できます。

これは理論的な話ではありません。AirbusとIron Mountainが既存の断片化されたツールチェーンを評価した際、共通して浮かび上がった課題を特定しました。それは、貧弱なユーザーエクスペリエンス、組み込みのセキュリティスキャンやレビューアプリなどの機能の欠如、プラグインのトラブルシューティングによる管理の複雑さです。これらは些細な問題ではありません。現代のソフトウェア開発における大きな障壁なのです。

移行への道のりは、想像以上にシンプル

GitLabは、他のベンダーからの移行を支援した数千社におよぶ組織の実績があり、スムーズな移行を実現するためのツールとノウハウを構築してきました。

• 自動化された移行ツール: Bitbucket Serverインポーターは、リポジトリ、プルリクエスト、コメント、さらにはラージファイルストレージ(LFS)オブジェクトも移行します。Jiraについては、組み込みインポーターが課題、説明、ラベルを処理し、複雑な移行にはプロフェッショナルサービスも利用できます。

• 大規模での実証済み実績: 13,000件のプルリクエスト、10,000個のブランチ、7,000個のタグを持つ500 GiBのリポジトリは、並列処理を使用してBitbucketからGitLabへの移行にわずか8時間しかかかりません。

• 即効性のあるROI: GitLabが委託したForrester ConsultingのTotal Economic Impact™調査では、GitLab Ultimateへの投資がこれらのメリットを実際の収益効果に変換することが確認されています。3年間で483%のROI、セキュリティ関連業務の時間を5分の1に短縮、ソフトウェアツールチェーンコストを25%削減という成果を実現しています。

統合DevSecOpsプラットフォームへの移行を開始しましょう

先進的な組織は、ベンダーが指定する期限を待たず、慎重に移行する時間がある今、代替案を評価しています。自社の投資を保護し、約束を果たしてくれるプラットフォームに移行するのです。

組織が自社管理型の導入に投資するのは、制御、コンプライアンス、カスタマイズが必要だからです。ベンダーがこれらの機能を廃止してしまうと、単に機能を削除するだけでなく、自社のビジネス要件に合致する環境を選択する基本的な能力を奪うことになります。

現代のDevSecOpsプラットフォームは、導入ニーズを尊重しながら、ツールチェーンを統合し、セキュリティやデータ主権を犠牲にすることなくソフトウェア開発を加速する完全な機能を提供すべきです。

営業チームにお問い合わせいただき、移行オプションについてご相談いただくか、包括的な移行リソースをご覧いただき、数千の組織がすでにどのように移行を実現したかをご確認ください。

また、GitLab Duo Enterpriseを含むGitLab Ultimateの30日間無料トライアルをお試しいただき、統合DevSecOpsプラットフォームがあなたの組織にもたらす価値をぜひ体験してください。

• AIプラットフォームとは
• AIプラットフォームの種類
• AIプラットフォームの主な機能
• AI開発環境とは
• GitLabではどのようにAIを活用してDevSecOpsプラットフォームを強化しているのか
• GitLabなどのAIプラットフォームを使用するメリット
• AIプラットフォームの課題やデメリット
• GitLabはどのようにAIプラットフォームのデメリットを克服しているのか
• FAQ（よくある質問）

AIプラットフォームとは

AIプラットフォームとは、人工知能（AI）の開発・運用を行なう際の基盤を提供するシステムのことで、開発や実行に必要な機能やデータがひとつになっています。具体的には、機械学習（ML）や深層学習（ディープラーニング）モデルを構築、開発、評価、実装、実行するための統合テクノロジーです。AIプラットフォームを正しく使えば、手作業でするより、より高速に、より高い精度で開発を進めることができます。

AIプラットフォームはAIの機能を構築し、モデルを訓練・評価し、実用化するまでをトータルでサポートする環境とも言えます。AIを使った開発を行なう際は、まずAIが動作する環境を整え、AIに学習データを読み込んでモデルを構築します。一般的なAI開発アプリケーションの場合、AIプラットフォームを活用することで、AI開発プロセスにおけるモデル開発の工程を簡略化できます。AIプラットフォームに既にAIの動作環境が整っているため、AIを構築する手間が省略できるからです。開発工程の難度が下がれば、AI開発のコストを抑えられます。

AIプラットフォームの種類

AIプラットフォームには、PaaS系の総合型AIプラットフォームと、特化型AIプラットフォームの2種類があります。

PaaS（Platform as a Service）系の統合型AIプラットフォームは、AI開発に必要な環境がすべてクラウドに揃っているサービスです。アプリケーションを稼働するためのネットワーク、ハードウェア、OS、ミドルウェアなどのプラットフォームに加え、膨大な量のデータを学習したAIモデルが用意されています。

特化型AIプラットフォームは、特定の業界や機能に特化したAIプラットフォームです。汎用性は高くありませんが、得意な領域では特定のタスクを効果的に処理できます。つまり、開発できるAIの種類は少なくなりますが、より高精度なAIを効率よく開発できます。

AIプラットフォームの主な機能

AIプラットフォームには、AI開発をサポートする機能が備わっています。主なAIプラットフォームには以下の機能が含まれます。

• データ収集

AIを優れたものとするには、良質な学習データの収集が欠かせません。AIプラットフォームのデータ収集機能を活用すれば、データを無駄なく効率的に収集できます。

• データ処理

収集したデータは、AIに適した形式に変換・加工しなければなりません。AIプラットフォームの機能を使えば、データの分割や正規化などの処理作業も効率よく進められます。

• モデル構築

AIモデルとは、AIでデータを処理するときのパターンのことで、データ解析を行なう方法のひとつです。AIモデルの種類には、「回帰モデル」や「分類モデル」などさまざまな種類があります。AIモデルではまず仮のモデルを構築し、想定しているものが実現可能かどうかを実際のデータを使って検証します。アルゴリズムの選択もこの段階で実施されます。

• 再学習

AIプラットフォームでは、継続的な運用に向けた再学習やデータの見直しを行ないます。最新の学習データやフィードバックを取り込むことで、AIの精度が高まります。再学習には、モデルの再学習、デプロイ、パラメータの調整、監視などが含まれます。

AI開発環境とは

近年、AI（人工知能）の発展は目覚ましく、AIをビジネスで活用したいと考えている企業も増加しています。ただし、AI開発には専門知識が必要で、適切な開発環境も整える必要があります。

AI開発環境とは、AIモデルの設計・開発・テストを行なうためのインフラとツールが整った作業環境を指します。AI開発を進めるには、プログラミングスキルやデータ分析スキルといった専門知識に加え、ハードウェア・ソフトウェアの環境整備が必要です。機械学習（ML）アルゴリズムや深層学習（ディープラーニング）モデル、環境を構築するためのフレームワークやライブラリも不可欠です。

GitLabではどのようにAIを活用してDevSecOpsプラットフォームを強化しているのか

GitLabでは、AI機能を活用してDevSecOps（開発・セキュリティ・運用の統合）を強化しています。GitLab Duoは、現在利用できるAI搭載プラットフォームの中で最も包括的なDevSecOpsプラットフォームです。GitLabは、ソフトウェアの開発、セキュリティ、デプロイなど、DevSecOpsライフサイクル全般にわたってチームをサポートします。 強力なAIを搭載した包括的なDevSecOpsプラットフォームが、コードレビューやテスト自動化の支援、セキュリティ脆弱性の予測や対策の提案、プロジェクト管理の効率化などをサポートするため、イシュー管理、バージョン管理、コードレビュー、継続的インテグレーション / 継続的デリバリ (CI/CD)、モニタリングが、ひとつのアプリケーションで完結します。開発から運用までのプロセスを迅速かつ安全に進められます。

GitLabなどのAIプラットフォームを使用するメリット

AIプラットフォームを使用するメリットとして、以下が挙げられます。

• コストの縮減

AIプラットフォームを導入すれば、すべてを自社開発した場合と比べて開発期間が短縮でき、コストを抑えることができます。AIの開発には、サーバーやOSといったさまざまなリソースが必要ですが、AIプラットフォームにはAI開発の基盤となるシステムが備わっているため、ノーコードで開発でき、コーダーなどの人件費も節約できます。それにより、求められる機能を備えたAIを、低コストで効率よく開発できます。

• システム開発の高速化

既存の機能や環境、AIモデルを利用することで、システム構築のスピードが上がります。ゼロからシステムを構築する場合、AIが動作できる環境を整え、それからAIに学習データを読み込ませてモデルを構築する工程が必要になりますが、AIプラットフォームを使えば、この工程を省略できます。

• AI専門エンジニアが不要な場合も

AIプラットフォームなら、前述のようにノーコードでAIを導入できる環境が整っているため、プログラミングの知識がなくてもAI開発ができる場合があります。プログラミング言語を習得する必要性が減ってきているのです。GitLab Duoは、コードの理解からセキュリティ脆弱性の修正まで、最適なAIモデルが単一のプラットフォームに統合されています。エンジニアでなくてもAI開発に取り組めるようになります。

• 小規模なAI開発から始められる AIプラットフォームはさまざまな規模のAI開発に対応しているため、規模の小さいAIから開発を始め、規模を大きくしていくことができます。これにより、AI開発は大企業だけではなく、中小企業やスタートアップでも取り組めるようになりました。
• DevSecOps（開発・セキュリティ・運用）におけるエラーの早期発見と対策

GitLabのAIプラットフォームなら、DevSecOpsチームはAI開発を加速できます。このAIプラットフォームは、チームが問題を早期に発見して修正できるよう設計されているため、問題が複雑化する前に対応でき、後から大きなコストがかかる事態を防ぐことができます。

AIプラットフォームの課題やデメリット

AIをソフトウェア開発プロセスに統合するメリットは数多くありますが、AIプラットフォームにはデメリットもあります。導入を検討する際は、次のような点を考慮する必要があります。

• 開発や運用に専門知識やスキルが求められる場合がある

  AIプラットフォームの中にはコーディングの知識が必要なものもあります。こうした知識や技術が必要になる場合、導入コストが高くなることがあります。

• 機能確認を怠ると導入に失敗する場合もある

  どんなAIを開発したいのか、どのくらいのデータを扱うのかなどを事前に確認せずにAIプラットフォームを選択してしまうと、導入に失敗する恐れがあります。事前調査を怠らず、しっかりと目的に合ったAIプラットフォームを選択しましょう。

• データ品質とデータセキュリティの問題

  AIプラットフォームを利用する際には、データの品質やセキュリティに関する技術的な課題が生じる場合があります。データの品質ならびにセキュリティ要件を担保するためには、データの検証やクレンジング、アクセス制御の厳格化、プライバシー保護の強化などが求められます。

  GitLab Duoなら、AIを活用した機能を利用できるユーザー、プロジェクト、グループを自由に設定できます。また、プロプライエタリコードやデータがAIモデルのトレーニングに使用されることはないため、情報の機密性を保つことができます。

AIプラットフォームのデメリット克服のためのGitLabの取り組み

GitLabでは、AIプラットフォームのデメリットを克服するために、データの品質やセキュリティ、ユーザーのプライバシー保護を強化しています。

ソフトウェア開発におけるAIの有効性は、コード生成といった生産性メトリクスだけでなく、コード品質、保守、テスト、セキュリティに対してAIがもたらす影響も考慮して測定すべきです。また、コーディングプロセスにAIを統合することで、ソフトウェアデベロッパーが戦略的タスクにかけられる時間が増え、認知負荷が軽減され、より優れた価値を提供できるようにもなります。

• データ品質管理

  GitLabでは、データの品質管理に自動データ検証を取り入れ、トレーニングデータや運用データに不正確な情報やバイアスが含まれるリスクを減らし、AIモデルの精度向上を図っています。また、継続的インテグレーション/継続的デリバリー（CI/CD）の導入により、データの一貫性と品質を維持しています。

• セキュリティ対策

  GitLabでは、AIモデルとデータのセキュリティ監視を実施し、AIモデルやデータストレージへの脅威をリアルタイムで検出し、リスクに迅速に対応しています。また、データアクセスについては、ユーザーやチームごとにアクセス制御を行ない、内部からのデータ漏えいリスクを軽減しています。

• 自動化とコラボレーション支援

  GitLabのAIツールは、反復的な作業を自動化し、デベロッパーの生産性向上を図ることにより、コラボレーションを促進します。この効率化により、エラーや不整合の発生を抑え、チーム全体でのスムーズな開発体制が可能になります。

GitLabは、上記のような取り組みにより、AIプラットフォームのデメリットを最低限に抑え、デベロッパーにとって安全で信頼性の高い環境を提供しています。

まとめ

AIは現在、ソフトウェア開発において広く使用されています。この記事では、AIプラットフォームのメリットやデメリットなども採り上げ、問題を認識しつつ、イノベーションが促進される環境作りを担うAIプラットフォームについて解説してきました。専門知識や開発経験があまりなくても、AIプラットフォームを使えば、AIの開発・運用がスムーズに行なえます。

FAQ（よくある質問）

1. AI開発環境であるAIプラットフォームについて分かりやすく説明してください。 AIプラットフォームとは、人工知能（AI）の開発・運用を行なう際の基盤を提供するシステムのことで、開発や実行に必要な機能やデータがひとつになったものです。具体的には、機械学習（ML）や深層学習（ディープラーニング）モデルを構築、開発、評価、実装、実行するための統合テクノロジーです。

2. AIプラットフォームには何種類ありますか。

   AIプラットフォームには、大きく分けて2つの種類があります。「PaaS系の総合型AIプラットフォーム」と「特化型AIプラットフォーム」です。詳しくは、本記事の「AIプラットフォームの種類」をご覧ください。

3. AIプラットフォームはどう機能しますか。

   AIプラットフォームには、AI開発を支援するための機能がいくつか備わっています。データ収集、データ処理、モデル構築、再学習の4つが主要機能といえます。詳しくは本記事の「AIプラットフォームの主な機能」をご覧ください。

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

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

<p></p>

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

より迅速な価値実現

私たちのミッションは、世界を動かすソフトウェアの開発に誰もが貢献し、共創できるようにすることです。私たちのイノベーション戦略の急速なペースは、まだ道半ばであることを示しています。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は、Gartner, Inc.および/または米国とその他の国におけるその関連会社の商標およびサービスマークであり、MAGIC QUADRANTは、Gartner, Inc.および/またはその関連会社の登録商標であり、本書では許可を得て使用しています。All rights reserved.

この図表は、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

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

1. ロードマップとは？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.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使用に対するセキュリティとガバナンスも強化しています。

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1120293274?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="18.4 Release video placeholder"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

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サービスの基盤となることです。

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1121017374?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="18.4 Knowledge Graph Demo"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

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

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

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

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

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

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

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

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1120288083?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="A day in the life with GitLab Duo Agent Platform"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<p></p>

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への提出書類の「リスク要因」というタイトルの下に含まれています。法律で義務付けられている場合を除き、このブログ投稿の日付以降、これらの記述を更新または改訂する義務を負いません。

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

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

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. プラットフォームエンジニアリングの導入ステップ

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

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

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なら単一のプラットフォームで豊富な機能を利用できるため、開発者の認知負荷を軽減し、迅速かつ品質の高いソフトウェア開発を実現できます。

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

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

監修：川瀬 洋平 @ykawase

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

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と連携して動作します。

バグ修正：

• FIPS Runnerが、GitLab Runner 18.2.1でジョブの開始に失敗する
• OpenShift 4.16.27でOperator v1.37.0アップグレード後、カスタムConfigMapとセキュリティコンテキストの制約（SCC）を使用したRunnerでchownコマンドが失敗する
• GitLab 17.2での早期削除により、GitLab 17.x.xリリースでFF_RETRIEVE_POD_WARNING_EVENTSを復元
• ファイルシステム権限エラーによりすべてのGitLab Runnerジョブが失敗する
• ビルドジョブが権限拒否エラーで散発的に失敗する
• GitLab Runner Helmチャートのアップグレードにより変数が破損する
• FF_USE_FASTZIPを有効にしてもfastzipが有効にならない
• ワンタイムリクエストで作成されたSpotインスタンスを停止しようとした際にGitLab RunnerでUnsupportedOperationエラーが発生する
• Kubernetes環境にデプロイされた環境でGitLab Runnerのロングポーリングが適切に動作しない
• 管理者がimage:kubernetes:userの値を上書きできるようにする

すべての変更の一覧は、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改善を確認するには、以下のリンクをクリックしてください。

• バグ修正
• パフォーマンスの改善
• 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 Runner
• GitLab Workflow for VS Code
• GitLab CLI

インストール

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

更新事項

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

ご不明な点がある場合

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

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

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

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

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

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

• GitLab 18.5
• GitLab 18.4
• GitLab 18.3
• GitLab 18.2
• GitLab 18.1
• GitLab 18.0
• GitLab 17.11
• GitLab 17.10
• GitLab 17.9
• GitLab 17.8
• GitLab 17.7
• GitLab 17.6
• GitLab 17.5
• GitLab 17.4
• GitLab 17.3
• GitLab 17.2
• GitLab 17.1
• GitLab 16.11

『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は、Gartner, Inc.および/または米国とその他の国におけるその関連会社の商標およびサービスマークであり、MAGIC QUADRANTは、Gartner, Inc.および/またはその関連会社の登録商標であり、本書では許可を得て使用しています。All rights reserved.

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

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

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

何を構築するのか

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

1. rawレイヤー - 外部ソースからの未処理データの最初の着陸地点。ビジネス用途に準備されていない

2. prepレイヤー - ソースモデルを含む最初の変換レイヤー。まだ一般的なビジネス用途には準備されていない

3. 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つあります：

1. Web UIチャット機能

2. 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は以下を行いました：

1. CSV入力ファイルを読み取り分析

2. メタデータからテーブル構造を調査

3. コーディング標準についてdbtスタイルガイドを参照

4. 適切な構造化のために類似のマージリクエストを考慮

5. すべての13テーブルのソースモデルを生成

6. すべての13テーブルのワークスペースモデルを作成

7. 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テーブルをテスト

• データ保持率を算出

<details>

<summary>生成されたSQLテストクエリ</summary>

-- 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;

</details>

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

• 重複除去後の行数に差異なし

• 全テーブルで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を今すぐお試しください。

さらに読む

• GitLab 18.3: ソフトウェアエンジニアリングにおけるAIオーケストレーションの拡張

• GitLab Duo Agent Platform ベータ版：次世代AIオーケストレーション

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

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

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

今後の展望

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

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

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

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

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

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

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

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

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

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

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の違いをまとめると上記の通りになります。ただし、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を導入するにはどのような手順を踏めば良いのかを解説します。

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

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機能を活用して、高品質かつ迅速なソフトウェア開発を実現できます。

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

監修：小松原つかさ @tkomatsubara

（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からのメッセージです」（吉瀬）

イベントで配られたノベルティ（水筒）

イベントで配られたノベルティ（スニーカー）

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のブレークスルーから、大規模なソフトウェアのセキュリティ対策まで、今月の注目記事をご紹介します。

• https://www.devopsdigest.com/gitlab-signs-strategic-collaboration-agreement-with-aws-to-deliver-secure-devsecops-to-gitlab
• https://thenewstack.io/how-intuitive-machines-used-devsecops-to-reach-the-moon/
• https://techvoices.com/video-podcasts/gitlabs-emilio-salvador-on-how-ai-agents-are-reshaping-software-development/
• https://techvoices.com/video-podcasts/gitlabs-emilio-salvador-on-how-ai-agents-are-reshaping-software-development/
• https://leaddev.com/technical-direction/are-you-ready-for-ai-agents
• https://leaddev.com/technical-direction/are-you-ready-for-ai-agents
• https://www.scworld.com/podcast-segment/14186-softwares-agentic-future-is-coming-how-cisos-can-prepare-today-josh-lemos-bh25-1
• https://www.devopsdigest.com/from-ai-risk-to-business-resilience-prompt-engineering-as-strategic-security-capability
• https://www.devopsdigest.com/from-ai-risk-to-business-resilience-prompt-engineering-as-strategic-security-capability
• https://www.scworld.com/podcast-segment/14186-softwares-agentic-future-is-coming-how-cisos-can-prepare-today-josh-lemos-bh25-1

そしてまだの方は、ぜひAIがソフトウェアイノベーションに与える影響に関するC-suiteレポート もチェックしてみてください。

• https://about.gitlab.com/software-innovation-report/ 
  （日本に特化したレポートは近日中に公開予定）

最後に、今月の名言を

パイプラインの最新化、ツール統合、エージェント型AIの導入。大きな変革はときにハードルが高く見えますが、すべては小さな一歩から始まります。

「それが成し遂げられるまでは、いつも不可能に見えるものだ。」 — ネルソン・マンデラ

難しいパイプラインに直面したら、「不可能」とは「まだ実現していないだけ」と思い出してください。

次回まで

今月も読んでいただきありがとうございました！感想やフィードバックはぜひXでのメンションやコメントでシェアしてください。お待ちしています。

それではまた来月、お会いしましょう！Happy Merging！

Fatima Sarah Khalid｜Developer Advocate, GitLab

🧡 このニュースレターが気に入った方は、ぜひチームにもシェアしてください。 👉 The Developer Showの購読もお忘れなく！

「イシューから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フローを活用できます：

1. GitLab Duo Agent Platformに実行してもらいたいことを説明するプロジェクトイシューを作成します。イシューの説明にできるだけ詳細を記載してください。イシューがすでに存在する場合は、計画 > イシューに移動し、更新したい内容を説明しているイシューをクリックして開きます。イシューのスコープは明確かつ具体的に設定してください。

2. イシューヘッダーの下にあるDuoでマージリクエストを生成をクリックしてフローを開始します。

3. イシューの実装に取り組むエージェントの進行状況を追跡したい場合は、自動化 > エージェントセッションに移動して、エージェントが計画を立てて、変更を提案している様子をライブセッションログで確認できます。

4. パイプラインが完了すると、イシューのアクティビティにMRへのリンクが表示されます。これを開いて、サマリーとファイルレベルの変更を確認してください。

5. GitLab Duo Agent Platformが提案した更新をローカルで検証したい場合は、ラップトップにブランチをプルし、アプリをビルド・実行し、更新が期待通りに動作することを確認できます。必要に応じてMRで編集を行い、通常のレビューを進めてください。

6. 提案されたアプリケーションの更新にすべて満足したら、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フローの動作を実際にご覧ください：

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/BrrMHN4gXF4?si=J7beTgWOLxvS4hOw" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

GitLab UltimateとDuo Enterpriseの無料トライアルで今すぐGitLab Duo Agent PlatformのイシューからMRフローを試してみましょう。