Maven仮想レジストリ（ベータ版）とGitLab Duoコードレビュー搭載のGitLab 18.1リリース

このたび、GitLab 18.1のリリースを発表しました。このリリースでは、Maven仮想レジストリ（ベータ版）、GitLab Duoコードレビュー、漏洩パスワードの検出、SLSAレベル1準拠を実現するCI/CDコンポーネントなど、さまざまな機能が追加されました。

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

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

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

GitLab 18.1のリリースでは、Maven仮想レジストリ（ベータ版）とGitLab Duoコードレビューが追加されました。クリックしてSNSで共有しましょう！

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

<img src="https://about.gitlab.com/images/notable-contributor-logo.svg">

Chaitanya Sonwaneさんは、継続的な認証機能の強化により、GitLabのセキュリティ機能向上に貢献しています。2025年に13件のコントリビュートがマージされ、認証情報インベントリのフィルタリング、サービスアカウント管理、作業アイテムの使いやすさが向上しました。以前にはGitLab 17.11の主要機能としてサービスアカウントのトークン統計情報をひと目で確認できる機能を手がけ、サービスアカウントの管理を容易にする「一目でわかる」情報を提供しました。Chaitanyaさんは現在、作業アイテムリストのソート設定をコンテキスト固有にする改善に取り組み、GitLabの製品計画におけるユーザーエクスペリエンスをさらに向上させています。

Chaitanyaさんの活躍により、GitLabを利用する組織のセキュリティが強化され、サービスアカウントの使用状況がプロジェクト全体で把握しやすくなりました。現在では、チームが認証情報をより効果的に追跡、ローテーションできるようになったことで、セキュリティの脆弱性につながりかねない、未管理の認証情報のリスクが軽減されています。

「認証情報インベントリとサービスアカウントに対するChaitanyaさんのコントリビュートは、セキュリティ分野において非常に貴重なものです」とEduardo Sanz-Garcia（ソフトウェアサプライチェーンセキュリティステージの認証グループのシニアフロントエンドエンジニア）は語ります。Eduardoは、GitLabの認証チームによる推薦も後押ししました。

さらに彼は「Chaitanyaさんは、トークン統計のコンセプトの実装に貢献してくれました。認証情報インベントリの取り組みにより、認証情報の追跡とモニタリングを強化する、非常に要望の多かった機能が提供されたのです。非常に素晴らしいコントリビュートでした」とも付け加えています。

ChaitanyaさんはTATA AIGのソフトウェアエンジニアです。セキュリティ上の課題に積極的に取り組み、自らのコントリビュートを改善するための継続的なフォローアップを行っています。

この場を借りて、GitLabのセキュリティ基盤やその他の製品にコントリビュートしてくれたChaitanyaさんに感謝します！

GitLab 18.1リリースの主な改善点

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

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

Maven仮想レジストリは、GitLabでのMaven依存関係管理を簡素化するものです。Maven仮想レジストリを使用しない場合、Maven Central、プライベートリポジトリ、GitLabパッケージレジストリからの依存関係にアクセスするための設定を個別に行う必要があります。こうしたアプローチでは、リポジトリへの順次クエリによってビルドが遅くなり、セキュリティ監査とコンプライアンスレポート作成が複雑になります。

Maven仮想レジストリは、複数のアップストリームリポジトリを単一のエンドポイントに集約することで、このような問題に対処します。プラットフォームエンジニアは、1つのURLを介してMaven Central、プライベートレジストリ、GitLabパッケージレジストリを設定できます。インテリジェントキャッシュはビルドパフォーマンスを向上させ、GitLabの認証システムと統合されます。これにより、設定オーバーヘッドの削減、ビルドの高速化、セキュリティとコンプライアンス向上を目的として一元管理されたアクセス制御が実現します。

Maven仮想レジストリは現在、GitLab.comとGitLab Self-Managedの両方で、GitLab PremiumおよびUltimateのお客様にベータ版として提供されています。一般公開リリースには、レジストリ設定用のWebベースUI、共有可能なアップストリーム機能、キャッシュ管理のためのライフサイクルポリシー、強化された分析機能などが追加される予定です。現在のベータ版では、トップレベルグループあたり最大20の仮想レジストリ、仮想レジストリあたり最大20のアップストリームまでと制限されており、ベータ期間中の設定はAPIのみで行えます。

企業のお客様を対象としたMaven仮想レジストリベータプログラムを実施しています。最終リリースの品質向上にご協力をお願いいたします。ベータ版にご参加いただくお客様には、機能への早期アクセス、GitLab製品チームとの直接のやり取り、評価期間中の優先サポートを提供します。ベータプログラムに参加するには、イシュー498139でご興味があることをお知らせいただき、ユースケースの詳細を提供してください。また、フィードバックや提案はイシュー543045にお寄せください。

ドキュメント
エピック

<!-- blank line -->

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

GitLab Duoコードレビューが一般公開開始

SaaS: Premium、Ultimate、Duo Enterprise
Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duoコードレビューが一般公開され、本番環境で使用できるようになりました。AI搭載のこのコードレビューアシスタントは、マージリクエストに対して的確で自動化されたフィードバックを提供し、従来のコードレビュープロセスを変革します。これにより、人間のレビュアーが関与する前に、潜在的なバグ、セキュリティの脆弱性、コード品質の問題を特定できるため、レビュープロセス全体を徹底的かつ効率的に行うことができます。GitLab Duoコードレビューには以下の機能が含まれています。

• 自動初期レビュー：コードの変更内容を分析し、潜在的な問題、改善点、ベストプラクティスに関する包括的なフィードバックを提供します。
• 対話ベースで改善：マージリクエストコメントで@GitLabDuoをメンションすると、特定の変更や質問に対する的確なフィードバックを受け取ることができます。
• 実行可能な提案：多くの提案をブラウザから直接適用できるため、改善プロセスが効率化されます。
• 文脈を理解した分析：変更されたファイルの内容を理解し、プロジェクトに特化した関連性の高い推奨事項を提供します。

GitLab Duoコードレビューをリクエストするには、次の手順に従います。

• マージリクエストで、/assign_reviewer @GitLabDuoクイックアクションを使用して@GitLabDuoをレビュアーとして追加するか、GitLab Duoをレビュアーとして直接割り当てます。
• コメントで@GitLabDuoをメンションすると、ディスカッションスレッドで特定の質問をしたり、詳細なフィードバックをリクエストしたりできます。
• プロジェクト設定で自動レビューを有効にすると、GitLab Duoがすべての新しいマージリクエストを自動的にレビューします。

GitLab Duoコードレビューを活用することで、チームがより高いコード品質基準を維持しながら、手動レビューサイクルに費やす時間を短縮できます。問題を早期に発見し、教育的なフィードバックを提供することで、開発チームにとって品質管理ツールと学習ツールの両方の役割を果たします。

ベータ版時のGitLab Duoコードレビューの動作はこちらをご覧ください。

イシュー517386でご経験やフィードバックをお寄せいただき、本機能の継続的な改善にご協力ください。

ドキュメント
エピック

ネイティブGitLab認証情報の漏洩パスワード検出

SaaS: Free、Premium、Ultimate
Self-Managed: -

GitLab.comへのサインイン時に、アカウント認証情報の安全なチェックが実行されるようになりました。お使いのパスワードが既知の情報漏洩に含まれている場合、GitLabにバナーが表示され、メール通知が送信されます。これらの通知には、認証情報の更新手順が記載されています。

セキュリティを最大限に高めるために、GitLabでは以下を推奨しています。

• GitLab専用の強力なパスワードの使用
• 2要素認証の有効化
• アカウントアクティビティの定期的な確認

注：この機能はネイティブGitLabのユーザー名とパスワードでのみ利用可能です。SSO認証情報は対象外です。

ドキュメント
イシュー

CI/CDコンポーネントでSLSAレベル1のコンプライアンスに対応

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLabの新しいCI/CDコンポーネントを使用することで、SLSAレベル1のコンプライアンスに対応できるようになりました。このコンポーネントは、GitLab Runnerが生成するSLSA準拠の アーティファクトの来歴メタデータに対して署名と検証を実行します。また、Sigstore Cosignの機能を再利用可能なモジュールとして提供し、CI/CDワークフローに簡単に統合できるようにします。

ドキュメント
エピック

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

コード検索で複数の検索結果の統合表示が可能に

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

完全一致コードの検索（ベータ版）では、同じファイル内の複数の検索結果を単一のビューに統合して表示できるようになりました。この改善により、次のことが可能になります。

• 孤立した行表示ではなく、隣接する一致間のコンテキストを保持
• 一致する内容が近い場合に重複コンテンツを排除し、視覚的な混乱を軽減
• ファイルごとの一致数を明確に表示することで、ナビゲーションを強化
• エディタでの表示と同様にコードを表示することで、可読性を改善

この変更により、リポジトリ全体のコードパターンの発見と理解がより効率的になりました。

ドキュメント
エピック

<!-- blank line -->

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

権限チェック機能を強化したCODEOWNERSファイル検証

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

GitLabでは、基本的な構文チェックを超えた、CODEOWNERSファイルに対するより強化された検証が提供されるようになりました。CODEOWNERSファイルを表示すると、GitLabが自動的に包括的な検証を実行し、マージリクエストのワークフローに影響を与える前に構文エラーと権限の問題を特定します。

この強化された検証では、CODEOWNERSファイル内の最初の200のユニークなユーザーとグループの参照をチェックし、次のことを検証します。

• 参照されたすべてのユーザーとグループがこのプロジェクトにアクセスできること
• ユーザーに、マージリクエストを承認するために必要な権限があること
• グループに、デベロッパーレベル以上のアクセス権があること
• グループに、マージリクエストの承認権限を持つユーザーが少なくとも1人含まれていること

この事前検証により、設定上の問題を早期に発見して承認ワークフローの中断を防ぎ、マージリクエストが作成されたときにGitLabコードオーナーが実際にレビューの責任を果たせるようにできます。

ドキュメント
エピック

VS Codeでダウンストリームパイプラインのジョブログを表示

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

VS Code用GitLab Workflow拡張機能で、ダウンストリームパイプラインからのジョブログをエディタ内で直接表示できるようになりました。これまで、子パイプラインからログを確認するには、GitLab Webインターフェイスに切り替える必要がありました。

この機能は、GitLab共同開発を通じて開発されました。この場を借りて、コントリビュートしてくれたTim Ryanさんに感謝します！

ドキュメント
イシュー

シークレット検出のデフォルトルールとDAST検出の同等性

SaaS: Ultimate
Self-Managed: Ultimate

DASTアナライザーが、GitLabのシークレット検出アナライザーで使用されるものと同じデフォルトのシークレット検出ルールを自動的に取り込むようになりました。この改善により、両方のアナライザーで検出されるシークレットの種類に一貫性が確保されます。

ドキュメント
イシュー

依存関係リストでコンポーネントバージョンによるフィルタリング

SaaS: Ultimate
Self-Managed: Ultimate

依存関係リストで、コンポーネントのバージョン番号によるフィルタリングがサポートされるようになりました。複数のバージョン（バージョン=1.1、1.2、1.4など）を選択できますが、バージョン範囲指定はサポートされていません。この機能は、グループとプロジェクトの両方で利用できます。

ドキュメント
エピック

コンプライアンスステータスレポートでコントロールステータスの一覧がポップアップで表示されるように

SaaS: Ultimate
Self-Managed: Ultimate

コンプライアンスステータスレポートのコントロールには、次の3つのステータスがあります。

• 合格
• 失敗
• 保留中

これまでは、要求事項に関連付けられているコントロールの数に関係なく、少なくとも1つのコントロールが「保留中」の場合、要求事項行全体が「保留中」として表示されていました。これは、失敗したコントロールの表示方法とは一貫性がありませんでした。失敗したコントロールが1つでもある場合は、要求事項に関連付けられた全コントロール数と失敗の数が表示されます。

「保留中」のコントロールに関する詳細なコンテキストと情報を提供するため、要求事項行のステータスにカーソルを合わせると、各コントロールのステータスを一覧表示するポップアップが表示されるようになりました。これにより、単に「保留中」という全体ステータスを確認するだけでなく、どのコントロールが保留中で、どのコントロールが合格または失敗しているかを具体的に把握できるようになりました。

ドキュメント
イシュー

ボットユーザーと人間のユーザーのフィルタリング

SaaS: -
Self-Managed: Free、Premium、Ultimate

運用が進んだGitLabインスタンスでは、多くの場合、人間とボットの両方のユーザーが多数存在します。今回のリリースで、管理者エリアのユーザーリストをユーザータイプでフィルタリングできる機能が追加されました。この機能により、以下のことが可能になります。

• 人間のユーザーと自動化アカウントを区別して迅速に特定、管理
• 特定のユーザータイプに絞った管理アクションを実行
• ユーザーの監査と管理のワークフローの効率化

ドキュメント
イシュー

ユーザープロフィールのORCID識別子

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

ユーザープロフィールにORCID識別子を設定できるようになり、GitLabが研究者や学術コミュニティにとってより使いやすく価値あるものになりました。ORCID（Open Researcher and Contributor ID）は、研究者に永続的なデジタル識別子を提供し、他の研究者との区別を可能にするとともに、研究者とその業績を自動的に関連付けることで、適切な評価を支援するものです。

この機能は、学術コミュニティからの長年の要望に応えるため、アルトワ大学の修士課程の学生であるThomas LabaletteとErwan HivinがDaniel Le Berreの指導の下、コミュニティに貢献することを目的に開発したものです。

ドキュメント
イシュー

サービスアカウントのパイプライン通知への登録

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

サービスアカウントによってトリガーされたパイプラインイベントの通知を、受信できるようになりました。通知はパイプラインが合格、失敗、または修正された場合に送信されます。これまでは、サービスアカウントに有効なカスタムメールアドレスが設定されている場合にのみ、そのサービスアカウントのメールアドレスに通知が送信されていました。

この場を借りて、コントリビュートしてくれたDensettさん、Gilles Dehaudtさん、Lenainさん、Geoffrey McQuatさん、Raphaël Bihoréさんに感謝します！

ドキュメント
イシュー

無効となっているパーソナルアクセストークンの表示

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLabは、有効期限が切れたり、失効したりしたアクセストークンを自動的に無効化します。今回の変更では、無効となっているトークンを確認できるようになりました。これまでは、アクセストークンが無効になると表示されなくなっていました。この変更により、こうしたトークンのトレーサビリティとセキュリティが向上します。

ドキュメント
イシュー

<!-- blank line -->

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

GitLab Query Language（GLQL）ビューでのエピックサポート（ベータ版）

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLab Query Language（GLQL）ビューが大幅に改善されました。今後は、クエリでエピックをタイプとして使用できるようになり、グループ全体のエピック検索や親エピックへのクエリが可能になります。

この機能強化により計画・追跡のワークフローが大きく向上し、エピックレベルでのクエリや整理が格段に効率化されます。

ドキュメント
イシュー

レビューパネルによるマージリクエストのレビューエクスペリエンスの強化

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

マージリクエストのレビューを行う際、レビューを送信する前にこれまでのフィードバックを参照すると役立つことがあります。これまでは、最終コメントと保留中コメントが別々のポップアップに分かれていたため、全体像を把握することが困難でした。

コードレビュー時に、保留中の下書きコメントを一箇所にまとめて表示する専用ドロワーが利用できるようになりました。強化されたレビューパネルでは、レビュー送信インターフェイスがよりアクセスしやすい場所に移動し、保留中のコメント数を示す番号付きバッジが表示されます。パネルを開くと、下にスクロールできるリストに下書きコメントがすべて表示されるため、送信前のフィードバックの確認と管理が簡単になります。

ドキュメント
イシュー

GitLab Runner 18.1

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

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

バグ修正：

• GitLab 17.10または17.11にアップグレードすると、Runnerがジョブをリクエストしたときに404エラーが発生する可能性があります。

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

ドキュメント

高度なSASTのPHPサポート

SaaS: Ultimate
Self-Managed: Ultimate

GitLabの高度なSASTにPHPサポートを追加しました。この新しいファイル間、関数間スキャン機能を使用するには、高度なSASTを有効にします。高度なSASTをすでに有効にしている場合、PHPサポートは自動的に有効になります。

高度なSASTが各言語で検出する脆弱性の種類を確認するには、高度なSASTカバレッジページを参照してください。

ドキュメント
エピック

パイプライン実行ポリシーにおける変数の優先順位制御

SaaS: Ultimate
Self-Managed: Ultimate

多くの場合、セキュリティチームはセキュリティ保証とデベロッパーエクスペリエンスの間で微妙なバランスを取ることになります。セキュリティスキャンが適切に実行されていることを確認するのは重要ですが、セキュリティアナライザーが正常に動作するためには、開発チームからの特定のインプットが必要な場合があります。変数の優先順位制御により、セキュリティチームは新しいvariables_override設定オプションを通じて、パイプライン実行ポリシーにおける変数の処理方法を細かく制御できるようになりました。

この新しい設定を使用すると、次のことが可能になります。

• プロジェクト固有のコンテナイメージパス（CS_IMAGE）を許可するコンテナスキャンポリシーを適用
• SAST_EXCLUDED_PATHSなどの低リスク変数は許可し、SAST_DISABLEDなどの高リスク変数はブロック
• AWS_CREDENTIALSなどのグローバルCI/CD変数で保護（マスクまたは非表示）されたグローバル共有認証情報を定義しつつ、必要に応じてプロジェクトレベルのCI/CD変数によるプロジェクト固有の上書きを許可

この強力な機能は、次の2つのアプローチをサポートしています。

• デフォルトで変数をロックする（allow: false）：例外として指定した特定の変数を除き、すべての変数をロック
• デフォルトで変数を許可する（allow: true）：変数のカスタマイズを許可するが、重大なリスクのある変数を例外として指定することで制限

パイプライン実行ポリシーによってCI/CDジョブが実行される際のトレーサビリティとトラブルシューティングを改善するために、ジョブログ機能も導入されました。これにより、デベロッパーとセキュリティチームは、どのジョブがポリシーによって実行されたかを簡単に特定できますジョブログでは、変数の上書きによる影響の詳細を確認でき、どの変数がポリシーによって上書きまたはロックされているかを把握するのに役立ちます。

実際の影響

この機能強化により、セキュリティ要件とデベロッパーの柔軟性のニーズとの間のギャップが解消されます。

• セキュリティチーム：プロジェクト固有のカスタマイズを許可しつつ、標準化されたスキャンを実行できる
• デベロッパーは：ポリシーの例外をリクエストすることなく、プロジェクト固有の変数を制御できる
• 組織は：開発ワークフローを混乱させることなく、一貫したセキュリティポリシーを実装できる

この重要な変数制御機能により、GitLabは組織が開発の柔軟性を保ちながら強固なセキュリティポリシーを導入できる環境を提供します。

ドキュメント
エピック

外部カスタムコントロールのNameを定義

SaaS: Ultimate
Self-Managed: Ultimate

これまでは、カスタムコンプライアンスフレームワークを作成する際に外部カスタムコントロールの名前を定義できず、GitLabコントロールと並んでリスト表示される外部コントロールを識別することが困難でした。

今回、外部カスタムコントロールを定義する際のワークフローの一部としてNameフィールドが追加されました。これにより、複数の外部カスタムコントロールを作成し、それぞれに固有の名前を設定して明確に区別できるようになりました。

ドキュメント
イシュー

GitLab Duo脆弱性の修正のためのSASTカバレッジの向上

SaaS: Ultimate
Self-Managed: Ultimate

これまでは、次のCommon Weakness Enumeration（CWE）識別子を持つ検出された脆弱性を手動で解決する必要がありました。

• CWE-78（コマンドインジェクション）
• CWE-89（SQLインジェクション）

現在は、GitLab Duo脆弱性の修正により、これらの脆弱性を自動的に修正できるようになりました。

ドキュメント
イシュー

コンプライアンスフレームワークUIにおける要件のページネーション

SaaS: Ultimate
Self-Managed: Ultimate

コンプライアンスフレームワークを作成する際は、最大50個の要件を指定できます。

ただし、これほど多くの要件があると、UIで大きな表示領域を占めるため、コンプライアンスフレームワークの操作が非常に困難になります。

今回のリリースでは、コンプライアンスフレームワークに多数の要件が含まれている場合でも、ユーザーが要件を簡単に閲覧、検索、選択できるよう、要件のページネーション機能を導入しました。

ドキュメント
イシュー

コンプライアンスセンターのUIパフォーマンスとフィルタリングを改善

SaaS: Ultimate
Self-Managed: Ultimate

コンプライアンスセンターのUIパフォーマンスとフィルタリングオプションの改善を継続しています。今回のリリースでは、次のことを行いました。

• 特に多くの要件とプロジェクトが含まれる場合に、フレームワークの編集ページのUIスピードとパフォーマンスを改善しました。
• コンプライアンスセンターのコンプライアンスステータスレポートタブで、要件、プロジェクト、またはフレームワーク別にグループ化できる新しいフィルタリングオプションを導入しました。

これらの改善を行うことで、コンプライアンスセンターを定期的に利用するお客様に対し、コンプライアンスセンターと関連機能が大規模環境でも継続して高いパフォーマンスを発揮できるようにしています。

ドキュメント
イシュー
イシュー

GraphQL APIのprojectMembersに新しいaccessLevels引数を追加

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GraphQL APIのprojectMembersフィールドにaccessLevels引数が追加されました。この引数を使用すると、APIコールから直接アクセスレベル別にプロジェクトメンバーをフィルタリングできます。これまでは、プロジェクトメンバーの全リストを取得してからローカルでフィルターを適用する必要があり、これにより計算オーバーヘッドが大幅に増加していました。現在では、プロジェクトの権限分析や所有権グラフの生成がより高速化し、リソース効率も向上しています。この機能強化は、複雑な権限構造を持つ大規模デプロイを管理する組織にとって特に価値があります。

ドキュメント
イシュー

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

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

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

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

非推奨事項

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

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

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

変更履歴

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

• GitLab
• GitLab Runner
• VS CodeのGitLab Workflow
• GitLab CLI

インストール

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

更新事項

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

ご不明な点がある場合

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

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

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

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

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

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

• 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

現代におけるメインフレーム開発の課題

ミッションクリティカルなワークロードにIBM Zシステムを使用するエンタープライズ組織は、従来のDevSecOpsツールでは対応できない課題に直面しています。クラウドネイティブチームは、モダンなCI/CDパイプライン、協調的な開発、自動化されたテストの恩恵を受けています。一方、メインフレームチームは取り残されることが多く、コストのかかる非効率性と運用サイロにつながる時代遅れのツールに縛られています。

チームはSSH接続や手動ファイル転送などの回避策に頼ることが多く、これらはセキュリティの脆弱性や監査の困難さを生み出します。コンプライアンス要件が厳格な場合、これらの即席のソリューションは受け入れられないリスクとなります。同時に、組織は高価な並行ツールチェーンを維持しており、レガシーメインフレーム開発ツールは、モダンな代替品と比較して限られた機能しか提供しないにもかかわらず、プレミアムライセンスコストがかかっています。

この断片化は2つの問題を生み出します：配信サイクルの遅延と、モダンな開発体験を期待する開発者の採用の困難さです。

「GitLab Ultimate for IBM Zは、長年の業界課題に対処する重要な一歩を表しています。IDCの調査によると、メインフレーム開発者は、配信の非効率性につながり、新しい人材を引き付けることを困難にするレガシーツールで作業することが多いことが示されています。このソリューションにより、モダンなDevSecOps機能と統一されたワークフローがメインフレームに直接もたらされます。これにより、開発者はより協調的かつ効率的に作業できるようになり、組織はイノベーションを加速し、メインフレーム開発をより広範なデジタルトランスフォーメーション戦略に統合することができます。」 \

• Katie Norton、IDC DevSecOpsおよびソフトウェアサプライチェーンセキュリティ リサーチマネージャー

統一された開発環境

真のモダナイゼーションとは、単にメインフレーム開発を更新することではありません。それは、メインフレーム、クラウドネイティブ、Web、モバイル開発チームがシームレスに協力できる統一プラットフォームを作成することを意味します。

GitLab Ultimate for IBM Zにより、開発者はz/OS、クラウド、またはオンプレミスインフラストラクチャにデプロイする場合でも、一貫したワークフローを使用できます。知識はサイロ化されるのではなく、チーム間で共有されます。レガシーシステムは動作を継続しながら、チームは独自のペースでモダンなプラクティスを採用できるため、組織はビジネスの中断なく段階的にモダナイズできます。

組織がハイブリッドクラウド戦略を追求する中、GitLabはメインフレームとクラウドネイティブ環境にまたがるアプリケーションの基盤を提供します。

GitLab Ultimate for IBM Zとは？

GitLab Ultimate for IBM Zは、ネイティブz/OSランナーサポートを提供し、メインフレームインフラストラクチャ上で直接シームレスなCI/CDパイプライン実行を可能にします。このGitLab認定ソリューションは、エンタープライズアプリケーションが要求するセキュリティと信頼性を維持しながら、複雑な回避策の必要性を排除するのに役立ちます。

GitLabの包括的なDevSecOpsプラットフォームとIBMの深いメインフレーム専門知識の組み合わせにより、市場で独自のものが生まれます：エンタープライズレガシーシステムとクラウドネイティブイノベーションの間の真の架け橋を提供する認定ソリューションです。

GitLab Ultimate for IBM Zの機能

GitLab Ultimate for IBM Zは、重要なビジネスシステムを維持しながらメインフレーム開発をモダナイズするために必要なツールをエンタープライズチームに提供します。

ネイティブz/OSランナーサポートは、リモート接続に関連するセキュリティリスクとスケーラビリティのボトルネックを排除し、メインフレームコードが存在する場所で直接実行されるCI/CDパイプラインを通じて配信を加速します。

統一されたソースコード管理は、高価なレガシーライブラリマネージャーをGitLabの検索可能でバージョン管理されたリポジトリシステムに置き換えることで、ツールチェーンをモダナイズし、ライセンスコストとメンテナンスのオーバーヘッドを削減するのに役立ちます。

IBM Developer for z/OS Enterprise Edition (IDzEE)とのシームレスな統合は、依存関係ベースのビルド、自動コードスキャン、および使い慣れた開発環境内の包括的なデバッグツールを通じて、より高速なソフトウェアリリースを実現し、品質とセキュリティの両方を向上させます。

メインフレームと分散環境全体のエンドツーエンドの可視性は、計画から本番までの包括的なプロジェクト管理を提供し、モダンな次世代開発ツールを通じて人材を維持するのに役立つ自動化されたDevOpsワークフローを可能にします。

今すぐメインフレーム開発環境をモダナイズ

GitLab Ultimate for IBM Zは、メインフレーム開発体験を変革する準備ができている組織向けに、現在利用可能です。詳細については、GitLabとIBMのパートナーシップページをご覧ください。

しかしその一方で、いまだに「Dockerとは何ですか」という声もよく耳にします。この記事では、Docker環境の導入を検討中で、Dockerにまだ不慣れなデベロッパーやプログラマーの皆様を対象に、Dockerの基本を解説します。Dockerに触れたことのない初心者向けの「Docker超入門編」です。

目次

1. Dockerとは：超入門編

2. Dockerの目的

   • Dockerとは
   • Dockerでできること
   • Dockerイメージとは
   • Dockerコンテナとは
   • Dockerfileとは
   • Dockerはなぜ重要なのか

3. Dockerの主な機能

   • Dockerの特徴
   • Docker Composeとは

4. アプリケーションのデプロイにおけるDockerのメリット

   • 開発環境と本番環境のシームレス化
   • 起動の軽量化・処理速度の高速化
   • バージョン管理のしやすさ
   • 優れたスケーラビリティ

5. Dockerのデメリット

   • ひとつのOSを使わなければならない
   • 大規模開発時のオーバーヘッド
   • 技能習得に時間がかかる
   • セキュリティに脆弱性が生じることもある
   • コンテナ間での連携が難しい

6. GitLabはDockerが抱える課題をどのように解決するのか

7. GitLabのDevSecOpsにおけるDockerの役割

8. まとめ

9. FAQ（よくある質問）

Dockerの目的

はじめに、Dockerとはどういったもので、何ができて、どうして便利なのか、なぜ重要なのか、Dockerの目的に着目しながらその概念をまとめていきます。

Dockerとは

Dockerは、Linuxのコンテナ技術を用いた軽量なソフトウェアコンテナプラットフォームです。アプリケーションの開発、出荷、実行を簡易化するために設計されました。Dockerを使えば、すべての依存関係と一緒にアプリケーションをパッケージ化できるため、依存関係を一つひとつ手動でインストールする必要がなくなり、一貫性のあるコード実行が可能になります。

Dockerを使えばアプリケーションの実行環境を標準化でき、環境の違いによる問題を減らすことで開発から本番環境へのデプロイ時間を大幅に短縮できます。

Linuxには以前からコンテナ仮想化という技術がありました。この技術を使うと、プログラムを開発・実行環境から隔離することにより、複数のプログラムを素早く実行できます。ただし、この従来型の仮想化技術は、仮想環境を構築するためにホストとなるOS（オペレーティングシステム）に依存する必要がありました。Dockerはこのコンテナ仮想化技術をOSに関係なく簡単に扱えるようにしたソフトウェアといえます。

Dockerの基本概念はイメージとコンテナです。Dockerイメージは、読み取り専用のテンプレートであり、コンテナを作成するための指示が記述されています。たとえば、コンテナで実行するアプリケーションとその依存関係、環境変数、ファイルシステムなどがこれに含まれます。

Dockerでできること

Dockerを使うと、1台のマシン中に複数のコンテナ（仮想環境）をビルドできるため、いくつかの開発環境に対応することができます。つまり、1台のサーバー上で複数のアプリケーションを効率的に動かすことができるのです。アプリケーションの開発環境をDockerで構築すれば、たとえば開発環境（Windows）で動いていたアプリケーションがLinux上で起動しない、といった問題は発生しません。Dockerで構築した環境は、他のデベロッパーとクラウド上で簡単に共有できるため、開発作業がスムーズに進められます。

Dockerイメージとは

Dockerイメージは、アプリケーションを実行するのに必要なソースコードと必要な依存関係をパッケージ化したものです。Dockerコンテナを実行する際には、このDockerイメージが必要です。

Dockerイメージは、コンテナイメージを構成する複数のファイルに、Dockerfile を合わせてビルドします。つまり、Dockerイメージは、手作業で書くのではなく、コマンドを使って作成します。

そのため、Dockerイメージは単一のファイルではなく、Dockerコンテナの実行に必要なパッケージ（ファイルやメタデータの集合体）であることを理解することが重要です。

Dockerコンテナとは

Linuxのコンテナは、アプリケーションを内包し、必要なライブラリや依存関係、ファイルが含まれています。

一方、Dockerコンテナは、Dockerイメージの実行可能なインスタンスです。これはDockerイメージから生成され、アプリケーションを実行するためのランタイム環境です。ただし、ハイパーバイザーを使用する従来の仮想化とは違い、DockerのコンテナはホストOS（オペレーティングシステム）のカーネルで実行されます。Dockerイメージ内には、個別のOSはありません。

Dockerイメージは環境のスナップショットであり、コンテナはソフトウェアを実行する環境といえます。

Dockerfileとは

Dockerfileは文字情報を主体とするファイルで、ファイルの拡張子はありません。Dockerfileには、アプリケーションの構築から実行までのプロセスに必要なコマンドが記述されています。どのファイルをどこから取得して、どんな処理を行ない、Dockerイメージに含めるのかなどを記述します。

Dockerfileは、Dockerイメージを作成するためのテキストファイルです。コンテナイメージをビルドする場合も、コンテナのビルド手順をDockerfileで定義する必要があります。このDockerfileには、命令のスクリプトが含まれており、Dockerはコンテナイメージをビルドする際にこのスクリプトを使用します。

Dockerはなぜ重要なのか

Dockerは、コンテナに関する既存のコンピューティングの概念、とりわけLinuxの「cgroups」や「namespaces」、「overlayfs」などの技術を活用しています。これは、アプリケーションの依存関係をサーバーやネットワークなどのインフラストラクチャから隔離したいという、デベロッパーやシステムオペレーターのニーズに応えるものでした。

Dockerを使うと、1台のサーバー上でさまざまなアプリケーションを簡単に仮想化・実行できるようになります。さらには、ローカルマシンに依存しない開発環境を実現でき（開発環境の統一）、本番環境に近い環境でのシミュレーションが可能になり、アプリケーションの依存関係も管理できます。加えて、ビルド、テスト、デプロイまでの各プロセスを一貫して行なうことができます。

Dockerの主な機能

Dockerは、Linuxのコンテナ技術を使用しています。Dockerコンテナはよく仮想マシンと比較されます。

仮想マシンでは、ホストマシン上でハイパーバイザーを利用してゲストOSを動かし、さらにその上でミドルウェアやライブラリ、さらにその上にアプリなどを実行します。

それに対し、コンテナはホストマシンのカーネルを利用し、プロセスやユーザーなどを隔離します。そのため、非常に軽量で、まるで別のマシンが動いているかのように動作します。その結果、アプリなどを高速に起動、停止することが可能です。

Dockerは、次の4つの構成要素から成り立っています。

• Dockerイメージ： アプリケーション実行に必要なソースコード、アプリと依存関係のパッケージ
• Dockerコンテナ： アプリケーションを実行するランタイム環境
• Docker Hub： クラウド上のレジストリサービス。アプリケーションやサービスコンテナのビルドと配信を行なう
• Dockerfile： Dockerイメージを作成するために実行するコマンドライン命令を含むテキストファイル

Dockerの特徴

Dockerには、次のような特徴があります。

• 軽量かつ高速： 1つのOSで複数のコンテナを管理でき、仮想マシンより軽量で高速に立ち上げることが可能。
• 環境の一貫性が保持でき再現性がアップ： Dockerコンテナは異なるプラットフォームでも一貫して動作するため、ローカル、クラウド、ハイブリッド環境への移行が簡単にできる。 移植性が高い －クラウドシステムとの親和性が高く、主要なクラウドプロバイダーはDockerコンテナの実行をサポートしている。
• サンドボックスの提供： セキュリティ対策やソフトウェア開発において、隔離された仮想環境でプログラムを実行・検証できる。このため、ホストマシンの環境を守ることができる。
• IaC（インフラストラクチャのコード化）を使用して、インフラをコード化： Dockerfileによりミドルウェアのインストールや環境設定をコード化して管理できる。

Docker Composeとは

Docker Composeは、複数のDockerコンテナを一元管理する、 Dockerアプリケーションのためのツールです。YAMLファイルを使用してアプリケーションのサービスを設定します。単一のコマンドで複数のサービスをまとめて生成したり、起動・停止したりすることができます。

Docker Composeのコマンド例は次のとおりです。

• docker-compose up： サービス用のコンテナを構築、作成、起動、アタッチします。リンクされているサービスがまだ起動していない場合は、それらも起動します。
• docker-compose ps： Docker Composeで管理されている稼働中のサービスを一覧表示します。
• docker-compose build： Docker Composeファイルで定義されているサービスをビルド（構築）します。

アプリケーションのデプロイにおけるDockerのメリット

アプリケーションのデプロイにおけるDockerのメリットは次のとおりです。

開発環境と本番環境のシームレス化

コンテナ技術の利用を開発環境と本番環境で統一することで、環境の違いにより起こる問題を減らすことができます。その結果、デベロッパーと運用チームとの連携がスムーズに行われ、チーム間で発生していた問題も最小限に抑えられます。

起動の軽量化・処理速度の高速化

Dockerのコンテナ技術は従来の仮想環境より軽く、アプリを瞬時に起動できます。これは、CPUやメモリなどのコンピュートリソースを必要最低限しか使用しないためです。起動速度が上がることで、開発にも集中できます。

バージョン管理のしやすさ

Dockerでは、GitLabなどのソースコードのバージョン管理ツールを使用できるため、バージョン管理の可視化が進むだけでなく、ロールバックやアップデートも簡単に行なえるようになります。

優れたスケーラビリティ

コンテナは軽量で拡張性に優れています。必要に応じて簡単に増減できます。これにより、アプリケーションの拡張やスケーリングを迅速に行なえるため、変わりゆく状況にも柔軟に対応できます。

Dockerのデメリット

Dockerにはさまざまなメリットがありますが、いくつかデメリットも存在します。以下にデメリットを挙げます。

1つのOSを使わなければならない

Dockerは1つのOS上で複数のコンテナを作成します。これにより起動速度や処理速度の面でメリットがありますが、同時にデメリットになることもあります。たとえば、異なるOS環境で検証をしたい場合には、別のマシンや仮想マシンを準備する必要が生じます。

大規模開発時のオーバーヘッド

Docker自体は軽量ですが、大規模システムに拡張する場合には、Dockerの管理に伴う負荷が発生します。Dockerは1台のサーバーで多数のコンテナを実行できますが、その反面、管理やオーケストレーションが必要になり、その処理のためにオーバーヘッドが生じる場合があります。Dockerだけですべての管理を行なうのが困難になることもあります。

技能習得に時間がかかる

Dockerは他の仮想マシンと異なる手法で仮想環境を構築します。つまり、デベロッパーは新しいコンセプトをすべてゼロから習得しなければならず、それには時間がかかります。Dockerの動作原理をきちんと理解せずに使用すると、あとでトラブルや問題が発生することもあります。Dockerについてしっかりと学習してから運用に取り組むようにしましょう。

セキュリティに脆弱性が生じることもある

Dockerはコンテナ型アーキテクチャです。1台のマシン上で複数のコンテナが動作するため、このことに起因する脆弱性には注意が必要です。たとえば、複数のコンテナがホストOSのリソースやカーネルを共有しているため、一つのコンテナに脆弱性があった場合、全体にその影響が及ぶ可能性があります。

コンテナ間での連携が難しい

複数のコンテナ間での連携を検討している場合、各種設定が難しいために、運用時に問題が発生することがあります。たとえば、アプリとデータベースを別のコンテナで作成し、一緒に運用したい場合には、同一ホスト内で通信設定をしなければなりません。ポートやソケットを開放する場合にはセキュリティ面でリスクが生じます。それを避けるために設定を複雑にしてしまうと、今度は運用面で問題が起きる恐れがあります。コンテナを連携させる際は、設計段階から十分に検討することが重要です。

GitLabはDockerが抱える課題をどのように解決するのか

Dockerコンテナ内にGitLabをインストールすることができます。GitLabは、Git「分散型バージョン管理システム」を主体としたDevSecOpsプラットフォームです。ソフトウェア開発ライフサイクル全体に対応する単一のプラットフォームで、GItLabを活用することで高品質なソフトウェアの迅速なデリバリーを実現できます。

Dockerコンテナ内にGitLabをインストールすると、GitLabインスタンスにアクセスできるようになります。DockerコンテナへのGitLab Dockerイメージのインストールは公式にサポートされています。

Dockerが抱えるいくつかの問題のうち、特にセキュリティについては、GitLabのDevSecOps（開発、セキュリティ、運用）を活用して対処することができます。GitLabのDevSecOpsでは、シフトレフトを重視しており、セキュリティ対策を開発サイクルの早い段階に組み込むことにより、コンテナイメージの持つセキュリティの問題の早期発見と対応を図っています。継続的インテグレーションによってこのシフトレフトのコンセプトを実践することで、セキュリティ対応にかかっていたコストを削減できます。

DevSecOpsにおいて重要なCI/CDを実現するためには、自動化が欠かせません。GitLabではパイプラインがCI/CDの命令をまとめています。そして、その指示に従いプロセスの自動化を実現するときの基盤になっているのがGitLab Runner（英語）です。GitLab Runnerはセキュリティのシフトレフトを実現する上で重要な役割を果たしています。

GitLab Runnerはセキュリティスキャンやテストを指定したタイミングで自動で実行してくれます。また、レポート作成ジョブを実行して、ダッシュボードに最新情報を表示することも可能です。

GitLabのDevSecOpsにおけるDockerの役割

GitLabを活用したDevSecOpsインテグレーションにおいても、Dockerは非常に大切な役割を担っています。

CI/CDジョブのコンテナ化

GitLab CI/CDでは、CI/CDパイプラインでDockerコンテナを使用することで、次のようなことが可能になります。

• 一貫性： CI/CDジョブはコンテナ内で実行されるため、依存関係や環境の違いによるエラーが防げます。
• スケーラビリティ： コンテナは軽量かつ迅速に起動でき、大規模なパイプラインでも効率的に実行できます。
• 環境の柔軟性： ジョブごとに異なるDockerイメージを指定できるため、必要な環境を簡単に準備できます。

GitLab RunnerのDockerイメージは、UbuntuまたはAlpine Linuxをベースにしています。Dockerイメージは標準のgitlab-runnerコマンドを内包しており、ホストに直接GitLab Runnerをインストールしたかのように動作します。

セキュリティスキャンの自動化

セキュリティはDevSecOpsでの重要な要素であり、Dockerはこれをサポートします。

• コンテナイメージのセキュリティスキャン： GitLabには、CI/CDパイプラインでDockerイメージをスキャンする機能があります。このスキャンにより脆弱性がチェックされ、イメージ内の依存関係やコードの安全性を評価できます。
• コンテナ脆弱性スキャンの自動化： GitLabにはTrivyやAquaなどのセキュリティツールを統合できます。DockerイメージのOSやアプリケーションが最新であるか、既知の脆弱性がないかをチェックします。

IaC（インフラストラクチャのコード化）と環境管理

• 再現性： DockerをGitLabのCI/CDジョブ内で使用することで、開発環境と本番環境の整合性を保つことできます。
• ステージングやテスト環境を即時に構築： Docker ComposeやKubernetesと連携することで、特定のブランチやマージリクエストごとに分離された環境をGitLabで作成できます。これにより、テストやセキュリティスキャンを効率的に実行できます。

デプロイの効率化

GitLabは、Dockerを使用する以下のデプロイパターンをサポートしています。

• Dockerイメージのビルドとプッシュ： アプリをコンテナイメージとしてビルドして、GitLabのContainer Registryや他のDockerレジストリにプッシュします。
• 継続的デリバリー： Dockerイメージを使ってコンテナオーケストレーションツールにデプロイすることで、迅速で安全なリリースが可能になります。

マイクロサービスアーキテクチャのサポート

GitLabとDockerを組み合わせることで、マイクロサービスアーキテクチャを簡単に構築できます。マイクロサービスは別々のDockerコンテナとして実行します。GitLab CI/CDパイプラインを使うと、以下のことを管理できます。

• サービス間の依存関係の設定
• 個別のセキュリティスキャン
• バージョン管理（ロールバックが容易になります）

まとめ

2013年の公表以来、Dockerは瞬く間にIT業界に広く普及しました。本記事では、Dockerの基本概念、基本技術、Dockerを使って何ができるのか、なぜDockerが重要なのか、Dockerを理解上でよく目にする用語などについて紹介してきました。

Dockerを使う場合には、DevSecOpsにとって大切なCI/CDを実現するためにも、GitLab CI/CDなどの自動化ツールの導入をおすすめします。GitLab のCI/CDパイプラインでDockerコンテナを使用することで、開発における一貫性の維持、スケーラビリティの実現、柔軟な環境の準備が可能になります。

FAQ（よくある質問）

Dockerで何ができるのか？

Dockerコンテナは、軽量でスタンドアロンの仮想化技術であり、アプリケーションコード、その依存関係、ライブラリをすべてパッケージ化します。Dockerを使うと、1台のマシン上に複数のコンテナ（仮想環境）を構築でき、開発環境や検証環境の統一が図れます。詳しくは、記事の本文をご覧ください。

Dockerは何に使うのか？

Dockerは、デベロッパーがアプリケーションとその依存関係をシステムから切り離したいとき使用します。コンテナにはアプリケーションとその依存関係がまとめられており、軽量な実行環境を提供します。詳しくは、記事の本文をご覧ください。

Dockerコンテナとは何ですか？

Dockerイメージが実行時にコンテナになります。Dockerコンテナは、アプリケーションを実行するためのランタイム環境です。Dockerコンテナに関する詳細は、記事の本文をご覧ください。

監修：川瀬 洋平 @ykawase

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

大規模アップデートや新しいAI機能、次のスプリントに役立つDevSecOpsインサイトが満載です。今月の注目ポイント？それは GitLab 18の正式リリースです。しかも今回から、PremiumおよびUltimateのすべてのお客様が、GitLab Duoの主要なAI機能を追加料金なしでご利用可能になりました。

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

GitLab 18：GitLabにとっての小さな一歩、DevSecOpsにとっての大きな飛躍

GitLab 18.0のリリースでは、PremiumとUltimateプランにGitLab Duoが標準搭載され、AIネイティブなDevSecOpsの新たな時代が始まります。

新機能ハイライト

• Duoコード提案 & GitLab Duo ChatがIDEで利用可能に：コードの記述から理解、リファクタリング、テストまでリアルタイムで支援します。
• リポジトリX-Ray（Self-Hostedはベータ版）：リポジトリ構造とコードの健全性を可視化します。
• GitLab Duoコードレビューの自動有効化：すべてのマージリクエストにAIレビューを適用。
• プロンプトキャッシュ機能：AI応答の遅延を軽減し、スムーズなやり取りを実現。

最新のグローバルDevSecOps調査では、デベロッパーがコード以外の作業に79％もの時間を費やしていることが明らかになりました。つまり、AIを“コード支援”のみに使っているだけでは、AIの真の力を活かしきれていません。GitLab 18では、ソフトウェア開発ライフサイクル全体にAIを組み込み、面倒な作業を減らして本質的なイノベーションに集中できる環境を提供します。

このリリースを可能にしたのは、世界中の素晴らしいコミュニティの力です。328件のコントリビュートにより支えられたGitLab 18は、まさに「使う人たちによって作られた」リリースです。

今月の注目コントリビューターは、Adfinis社CTOのMichael Hoferさん。GitLabのGeo機能やSecrets Managerの改善など、本当にたくさんの貢献をしてくださいました。オープンソースにかける想いと、周囲を巻き込む力に、私たちもたくさんの学びをもらっています。

👉 GitLab 18 リリースノート全文を読む

事例のご紹介：Ignite by FORVIA HELLA

ソフトウェアが自動車産業の中核となる今、Ignite by FORVIA HELLAは次世代車両開発のために、ベルリンを拠点とするソフトウェア・イノベーションハブ Ignite を立ち上げました。

CTOのFelix Kortmann氏はGitLab Duoについてこう語ります。

「Duoのインテリジェントなコード提案は、デベロッパーにとって日常の必需品です。チャット機能と組み合わせることで、即座のフィードバックと反復が可能になり、開発サイクルが短縮され、コードの安全性も向上しました。私たちのワークフローに、シームレスかつ強力に統合されています」

GitLab CI/CDとAI機能を組み合わせることで、Igniteは反復テストや品質チェックを自動化。コードがpushされた瞬間に自動処理が走り、早期の課題検出とスピーディーなデリバリーを実現しています。

GitLab 18のローンチイベントがバーチャルで開催！しかもアジア時間に！さらに日本語字幕付き！

2025年6月24日（火）13時より、GitLab 18の新機能を紹介するグローバルオンラインイベントを開催します。

✨ イベント内容

• GitLab 18の新機能を実演するライブデモ
• GitLabのリーダーたち（Bill Staples、Sabrina Farmer、Josh Lemos、David DeSantoほか）によるインサイト共有
• 新ライブシリーズ「The Developer Show」の初公開： コーディングデモ、プロダクト解説、コミュニティのストーリーをお届け！

ご都合の良い時間帯を選んでぜひご参加ください。質問も大歓迎です！

👉 今すぐイベント登録する

GitLab Duo、Premiumにも標準搭載

GitLab 18のリリースにより、Duoの主要機能がPremiumおよびUltimateで標準提供されます。追加ツールも、追加費用も不要。IDE上でスマートな開発がすぐに始められます。

機能ハイライト

• GitLab Duoコード提案：20以上のプログラミング言語で高速なコード作成・リファクタリング
• GitLab Duo Chat：コードの解説、テスト生成、トラブル対応を簡単に

さらに、より高度な機能を求めるチームには、Ultimate限定だったDuo EnterpriseがPremiumでも利用可能に。GitLab Duo根本原因分析、GitLab Duo Self-Hosted、AIコードレビューなどが利用できます。

👉 Duoを有効にして、開発を始めましょう

AWS Summit で直接お会いしましょう！

東京をはじめ、世界各地のAWS SummitにGitLabも出展します！GitLabとAWSの連携機能を体験できるほか、安全なクラウドネイティブ開発の事例もご紹介。もちろん、ノベルティもご用意しています！

🗓️ 6月のイベント予定

• シドニー｜6月4日〜5日
• ストックホルム｜6月4日
• ハンブルク｜6月5日
• マドリード｜6月11日
• ミラノ｜6月18日
• ムンバイ｜6月19日
• 東京｜6月25日〜26日

👉 AWS Summit 2025でお会いできるのを楽しみにしています！

今月のおすすめ読書

• A Practical Roadmap for Adopting Vibe Coding（Vibe Coding 導入のための実践ロードマップ） スピードを重視するあまり、品質や保守性が犠牲にならないよう、適切なガバナンスが必要だとGitLabの戦略VPであるEmilio Salvadorが解説。

🔗 The New Stackの記事を読む（英語）

• 3 ways APAC engineering teams can operationalise AI（APACの開発チームがAIを活用する3つの方法）
  APACのエンジニアリングチームによる日常業務へのAI統合、業務効率化、抵抗感の軽減、ビジネス価値の可視化についてGitLabのCTOであるSabrina Farmerが説明します。
  🔗 Frontier Enterpriseの記事を読む

• Beyond Culture: Addressing Common Security Frustrations（文化を越えて：セキュリティ課題の根本に向き合うには）
  文化づくりも重要ですが、開発とセキュリティの基本設計から見直す必要があります。GitLab最高情報セキュリティ責任者のJosh Lemosによる解説記事。
  🔗 The New Stackの記事を読む（英語）

• The Field CTO View: AI, Vibe Coding, and Developer Skillsets（フィールドCTOの視点：AIとVibe Coding、デベロッパーのスキルセットのこれから） 企業のIT部門ではAIがどう実装されているのか？ デベロッパーの適応はどう進んでいるのか？GitLabのフィールドCTO部門責任者が答えています。
  🔗 The New Stackの記事を読む（英語）

今月のひとこと

最後に、私が心に留めている言葉をシェアします。完璧を目指すよりも、まずは一歩を踏み出すこと。大きなアイデアは、小さな行動から始まります。

「何かを始める方法は、話すのをやめて行動することだ」– ウォルト・ディズニー

これからも、ひとつずつマージを重ねながら、学び、作り、そして成長していきましょう 💜

🦊 また次回まで！

GitLabコミュニティの一員でいてくださり、ありがとうございます！みなさんがGitLab 18でどんなものを作ってくださるのか、私たちも楽しみにしています。バーチャルイベントの登録と、AI機能の活用開始もお忘れなく。それではまた次回のMonday Mergeでお会いしましょう。Happy Merging!

Fatima Sarah Khalid | GitLab Developer Advocate

目次

• IDE（統合開発環境）とは
• IDEの主な特徴
• IDEの仕組み
• IDEの種類
• IDEを使うメリット
• IDEの例
• Web IDEとは
• IDEのFAQ（よくある質問）

IDE（統合開発環境）とは

IDEはIntegrated Development Environmentの略で、日本語では「統合開発環境」と訳されます。IDEは、開発者がソフトウェアのコードを開発する際に必要なソフトウェアをひとつにまとめ、単一の画面で操作できるようにしたものです。

プログラミングには次のようなプログラムが必要になります。

• テキストエディタ：ソースコードを記述
• コンパイラー：ソースコードからオブジェクトコードを生成
• リンカー：ターゲットとなるCPU用に実行コードを生成
• デバッガー：作成したプログラムのバグ検出に使用
• コードのバージョン管理：ほとんどのIDEはシームレスにバージョン管理システムを統合
• 自動化ビルド：ビルドプロセスを自動化

IDEがなかった時代は、これら一つひとつを手作業で統合しなければなりませんでした。しかし、現在ではすべてがIDEツールに統合されているため、IDEをインストールするか、Web IDEにアクセスすれば、開発環境が瞬時に整います。ほとんどのIDEには、ソースコードを自動的に書いたり、編集したりするための機能が含まれています。そのため、コード開発を効率的に行うことが可能になります。

IDEの主な特徴

IDEはこれまで、パソコンにインストールして使用するものが主流でしたが、現在はWeb IDEなど、クラウドベースのものが増えてきています。GitLabのWeb IDEも、Webブラウザにアクセスできれば、簡単に開発ができるため、複数の開発者で開発環境を共有することが可能です。

統合開発環境（IDE）の特徴は、次のとおりです。

1. 時間の節約：上述のように、各種プログラムがひとつのプラットフォーム上に統合されているため、ソフトウェア開発にかかる時間が短縮できます。
2. チームでの開発の効率化：バージョン管理やソースコードの管理など、引き継ぎにかかる手間が省け、ミスが予防できます。
3. ヒューマンエラーの防止：IDEのエディタには入力サポート機能があり、コンパイラにはシンタックスチェック、つまり構文の間違いチェック機能があります。こういった機能はヒューマンエラーを防止してくれます。

IDEの仕組み

IDEとは、ソフトウェアの開発で使用するさまざまなソフトウェアを支援ツールと合わせてまとめ、統合開発環境として使えるようにしたものです。

IDEの種類

IDEには、さまざまな種類があります。用途や目的、プログラミング言語、ターゲットとする OS や動作環境によって、選ぶポイントがあります。何を作るのか、どういうソフトウェアやアプリケーションを開発するのかによっても、最適 IDEは変わります。どのIDEを選ぶかによって、できることが異なるからです。しかし、異なるIDEで共通してできることは、次のようなものです。

• ソースファイルの構成管理
• ビルドの自動実行
• デバッグ

また、たとえば、プログラミング言語には Java、Swift、C++、C#、UnityやPythonなどがあるため、コードを書く言語に対応しているIDEを選ぶべきでしょう。IDEの種類としては：

• 多言語対応IDE
• モバイル開発用IDE
• WebまたはクラウドベースのIDE
• 単言語のIDE

などがあります。

また、IDEにはダウンロードして使うものと、クラウドで使用するもの、たとえばWeb IDEなどがあります。クラウドベースのものは、複数の開発者の間で開発環境が共有できるため、各々のチームメンバーの環境設定の違いは問題になりません。また、ビルドの際はCPUの速度低下により時間がかかるものですが、クラウドIDEでは速度低下は発生しません。ソースコード開発は、Gitなどと連携すれば、チーム間での共有も行えます。

IDEを使うメリット

IDE、統合開発環境を使うメリットは、一言で言うなら「開発の効率化」です。「IDEとは」で記述したように、IDEにはテキストエディタ、コンパイル、デバッグなどの機能がすべて統合されています。そのため、コード開発の効率化が図れます。

IDEを使うと、環境設定を行う手間が省けますが、逆に、IDEを使わないと、各種ツールを設定しなければならず、時間がかかります。また、IDEはインストール後すぐ使えるため、プログラミングの初心者にもお勧めできます。

IDEの例

IDE、統合開発環境にはたくさんの種類があります。現在よく使われているIDEのうち、例を 5 つ挙げます。

● Visual Studio/Visual Studio Code – Microsoftが開発。市場でとくに人気がある

● IntelliJ IDEA – JetBrains が開発した、多言語対応型IDE

● Vim - Bram Moolenaar氏が開発した軽量のテキストエディタでIDEとして使用可

● Eclipse – IBMが開発した、オープンソースのIDE

● Jupyter Notebook – Pythonの実行環境をもつ、ブラウザベースのIDE

Web IDEとは

Web IDEとは、前述のように、WebベースのIDEで、WebブラウザさえあればアクセスできるIDEを意味します。個々に IDE を利用するのではなく、利用者はみな、ブラウザを介してIDEにアクセスするため、各種設定のわずらわしさから解放されます。

GitLab Web IDEを使うメリット

GitLabには、クラウドベースの、オンラインWeb IDE（英語版）があります。Web IDEは、コミットのステージング機能を備えた高度なエディタです。Web IDEを使うと、GitLab UIから直接複数のファイルに変更を加えることができます。

• フレキシブルでカスタム化可能なインターフェース
• パネルは折りたたみ可能で、テーマもカスタム化可能
• コンテキストアクションとドラッグ＆ドロップサポート
• 開いているファイル全部を一度に検索・置換
• GitLab UIから直接ブラウザで開けるため、クイックなコード修正などに便利

IDEのFAQ（よくある質問）

Q: IDE（統合開発環境）を使う理由は何ですか。

A: IDEはソフトウェア開発環境の一部を構成しています。よく設計されたIDEを使うと、ソフトウェア開発が大幅に効率化できます。

Q: IDEの3つの主要コンポーネントは何ですか。

A: コードエディタ、コンパイラ、デバッガーが三大コンポーネントです。

Q: IDEのインストール、設定方法は？

A: ニーズに合ったIDEを選び、最新バージョンを公式サイトから入手してインストールします。ほとんどのIDEで、各種設定は使用環境に合わせてカスタマイズ可能です。

GitLab Web IDEを使ってみる

GitLabのWeb IDE は、SaaSおよびSelf-Managedのサブスクリプションを購入されているお客様には無償でお試しいただけます。詳しくはこちらをご覧ください。

<br><br> 監修：知念 梨果 @rikachinen <br> （GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）

そこでおすすめなのが、GitLab Duo with Amazon Qです。AWSユーザー向けにソフトウェア開発ライフサイクル全体にわたって自律型AIを提供するGitLab Duo with Amazon Qを使用すれば、レビュープロセスを変革できます。このAI搭載ソリューションは、チームメンバーがこれまで費やしていたほんの一部の時間で、包括的なコードレビューを実行できます。GitLab Duo with Amazon Qは高度な自律型AI機能を活用することで、必要な品質や徹底性を犠牲にすることなく、レビューワークフロー全体を効率化します。たとえるなら、瞬時にコードを分析して実用的なフィードバックを提供できる非常に熟練したレビュアーがいて、いつでも対応可能な状態のようなものです。

仕組み：コードレビューの開始

では、GitLab Duo with Amazon Qが実際にどのように機能するかをご説明します。ある機能に関する作業が終わり、ちょうど複数のコード更新を含むマージリクエストを作成したところだとします。コードレビューの開始方法は非常に簡単です。チームメンバーに連絡して対応可能かどうかの返答を待つ代わりに、コメントセクションに「/q review」というシンプルなコマンドを入力するだけです。これだけでAIによるコードレビューがトリガーされます。

コマンドが入力されると、Amazon Q Servicesはすぐにコード変更の分析を開始します。レビューを実行中である旨の確認メッセージが表示され、数秒のうちにAIが更新内容のすべての行を調査し、さまざまな側面から潜在的な問題がないかをチェックします。 レビューが完了すると、バグの検出、可読性の改善、構文エラー、チームのコーディング標準への準拠など、すべての基準を網羅した包括的なフィードバックが表示されます。AIによって問題が特定されるだけでなく、修正のためのコンテキストと修正案も提供されるため、対応が必要な箇所とその理由を簡単に把握できます。

この自律型AIアプローチの優れた点は、コードレビューの面倒な作業をAIにまかせられるため、デベロッパーが最も重要な作業である「優れたソフトウェアの開発」に集中できることです。時間を無駄に費やすことなく、バグ検出精度の向上、コーディング標準の順守、コード品質の向上など、徹底したコードレビューのメリットを享受できます。さらに、レビューの待ち時間がなくなるため、デプロイまでの時間が大幅に短縮され、チーム全体の生産性が向上します。

GitLab Duo with Amazon Qの導入メリット

GitLab Duo with Amazon Qを使用することで、以下のように開発プロセスを変革できます。

• 品質を妥協しない、迅速なコードレビュー
• コードベース全体にわたってコーディング標準を一貫して適用
• 本番環境に到達する前に問題を修正できるよう、即座にフィードバックを提供
• デプロイまでの時間が短縮されるため、より迅速に機能をリリース可能
• レビューを何度も行わずに済むため、本質的な問題解決に集中できる時間が増加

以下の動画では、GitLab Duo with Amazon Qを使用してコードレビュープロセスに変革をもたらす方法についてご紹介しています。ぜひこの革新的な機能に関する動画をご覧ください。

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

GitLab Duo with Amazon Qの詳細については、 お近くで開催されるAWS Summit にご参加いただくか GitLab担当者にお問い合わせください.

また、自律型AIの今後の計画などについてご紹介するGitLab 18オンラインリリースイベントにもぜひご参加ください。ご登録はこちら

「GitLabは、オールインワンソリューションの中でももっともオールインワンであり、一度の購入で標準化を目指す企業に適している」- Forrester Wave™: DevOps Platforms（2025年第2四半期）

この評価には、GitLabに日々寄せられているお客様の声が反映されています。つまり、お客様は安全なソフトウェアをより迅速に提供する必要がありますが、既存のソリューションでは、速度、セキュリティ、またはシンプルさのいずれかを妥協せざるを得ないということです。GitLabはこの3つすべてを妥協せずに実現できます。さらに、5月にリリースしたGitLab 18.0では、テスト生成、コード提案、コードリファクタリングなどのネイティブAIのGitLab Duo機能をGitLab PremiumとGitLab Ultimateに導入しました。追加費用なしで直接ご利用いただけます。

今すぐレポートを読む

エンタープライズレベルの制御を行い、AI変革の最前線に立ち続ける

DevSecOpsは急速に進化しており、AIはその変化の最前線に立っています。しかしながら、多くのAIツールでは、最先端の機能、またはエンタープライズレベルのセキュリティのどちらかを選ばざるを得ません。

Forrester社は、AIの導入とAIリスクの軽減の両方の基準において、GitLabに5点（最上位の評価）を付けました。セキュリティを維持する革新的なAI機能の開発に注力していることが、お客様だけでなく、多くの方々に認められていることを嬉しく思います。

この2つの強みは、以下を含むGitLab DuoのAI機能群にも反映されています。

• GitLab Duo Workflow（非公開ベータ版）：開発、セキュリティ、およびオペレーションにわたる複雑なタスクを処理する自律型AIエージェント。エンタープライズレベルのガードレールと監査証跡を提供します。
• GitLab Duo Agentic Chat：コードの説明からテスト作成まで、あらゆる場面で文脈を理解する会話型AIアシスト機能を提供します。知的財産の保護とプライバシー管理機能も組み込まれています。
• GitLab Duoコード提案：コードブロックの予測補完、関数ロジックの定義、テスト生成、正規表現パターンのような一般的なコードの提案を行うAIアシスト機能です。
• ネイティブAIのGitLab Duo脆弱性の修正：自動説明機能やマージリクエストの自動生成を活用して脆弱性を特定し修正することで、開発プロセスを効率化します。

より少ないリソースでより多くのことを実現

DevSecOpsチームが求めているのは、ソフトウェアデリバリーライフサイクル（SDLC）の一部だけを支援するようなツールやインテグレーションではないという声を、私たちははっきりと受け取っています。SDLC全体をカバーする、シームレスで統合されたデベロッパーエクスペリエンスが必要なのです。

以下の基準でGitLabが獲得したスコアは、当社の顧客重視の戦略を裏付けるものであると考えています。

• ゼロデイエクスペリエンス：Forrester社は、GitLabの「強力なゼロデイエクスペリエンス」について、「すべてがすぐに使える状態」であること、そして豊富な移行ツールとチュートリアルが用意されていることを評価しています。
• デベロッパー向けツール：Forrester社は、AWSユーザー向けの自律型AIであるGitLab Duo with Amazon Q、クラウド開発環境、統合デベロッパープラットフォーム、ドキュメント用Wikiなどを例として挙げています。
• プロジェクト計画と連携：Forrester社は、GitLabの「強力なコンプライアンスセンター」の存在に加え、トップダウンおよびボトムアップでの連携を促進するツールがあることに注目しています。
• パイプラインセキュリティ：Forrester社は、パイプラインセキュリティの基準においてもGitLabに最上位のスコアを付けました。
• ビルドの自動化と継続的インテグレーション：Forrester社は、マルチステージのビルドパイプラインと強力なセルフホスティングのサポートを備えたビルドの自動化と継続的インテグレーションについて言及しています。

レポートを読む

2025年第2四半期の『Forrester Wave™: DevOps Platforms』でリーダーの1社として評価されたことは、SDLC全体にわたり信頼できる唯一の情報源を提供する、当社のプラットフォームの幅広い機能と奥深さを物語っています。複数のツールやインテグレーションを使い分ける必要はもうありません。GitLabなら、シームレスで統合されたエクスペリエンスをとおして、生産性の向上、摩擦の軽減を実現します。今回の評価は、GitLabチームの努力、GitLabのオープンソースコミュニティからの多大な貢献、お客様からの貴重なフィードバック、そしてソフトウェア開発の未来を形作るという当社の熱意を反映していると考えております。

今すぐレポートを読む

Forrester社がリサーチに関する発行物に掲載されている特定の企業、製品、ブランド、サービスを推奨することはありません。また、当該発行物に記載されている評価に基づいて、特定の企業やブランドの製品またはサービスを選択するよう個人に助言することもありません。情報は、利用可能な最適なリソースに基づいて示されます。意見はその時点での判断によるものであり、変更される可能性があります。詳細については、Forrester社の客観性に関するこちらのページをご覧ください。

<center><i>DevSecOpsプロセスに複数のツールを統合するのがどれほど難しいか</i></center>

<br></br>

幸いなことに、これには解決策があります。ソフトウェア開発に対する統一されたアプローチを提供する包括的なDevSecOpsプラットフォームです。

このようなプラットフォームは、クラウドベースおよびDevSecOps環境で運用を行う組織向けに構築されており、コード管理、CI/CDプロセス、タスク管理、セキュリティからAI主導の自動化まで、すべてのソフトウェア開発ステージを単一プラットフォームに統合します。すべてのソフトウェア開発ワークフローを統一されたインターフェイスに一元化できるため、開発チームと運用チームの作業やコミュニケーションが効率化され、運用面の複雑さや混乱を最小限に抑えられます。

さらに、デベロッパーエクスペリエンスも大幅に向上します。エンジニアは最新の開発ニーズに特化して設計された製品で作業することになるため、満足度が高まります。

以降のセクションでは、プロジェクトやタスクの管理、セキュリティやコンプライアンスの確保、AI搭載の開発ツールの導入など、チームがよく直面する課題を解決するためにGitLabがどのように役立つかをご紹介します。GitLabなら、単一の統合プラットフォーム内ですべてを行えます。

統合されたアジャイルプロジェクト管理

GitLabでは、CI/CDなどソフトウェア開発ライフサイクルの全ステージにわたって、プロジェクトとタスクの管理が完全に統合されている包括的なソリューションが提供されているため、リアルタイムで開発の進捗状況を追跡できます。イシューとエピックは自動化プロセスに直接紐づけられるため、計画から本番環境へのデプロイまでのシームレスなフローが実現されます。このアプローチにより、チーム間の透明性が高まり、遅延の発生が減り、すべてのステークホルダーがリアルタイムで開発状況を明確に把握できるようになります。

ビルトインのセキュリティ

GitLabでは、包括的なセキュリティ機能を統合すること（セキュリティを最優先）を非常に重視しています。GitLabプラットフォームには、以下を含むさまざまな自動セキュリティスキャナーが組み込まれています。

• 依存関係スキャン
• 静的アプリケーションセキュリティテスト（SAST）
• 動的アプリケーションセキュリティテスト（DAST）
• シークレット検出
• コンテナスキャン

<center><i>さまざまな開発ステージでCI/CDプロセスに統合されているセキュリティスキャン機能</i></center>

<br></br>

これらのセキュリティチェックは、CI/CDパイプラインを含むソフトウェア開発ライフサイクルの全ステージに直接組み込まれており、開発サイクルの早い段階で潜在的なセキュリティ上の問題についてデベロッパーに即座にフィードバックを提供します。

コンプライアンスと規制要件

効率性や優れたユーザーエクスペリエンスの確保に加え、多くの組織（特に金融機関や大企業など規制の厳しい業界の組織）は、厳格なセキュリティおよびコンプライアンス基準にプロセスが準拠していることを確認する必要があります。こういった組織では、特定のコードブランチ（mainブランチや保護ブランチなど）でCI/CDパイプラインが実行されるたびにセキュリティスキャナーが実行されるようにしたり、mainブランチにコードをマージする前に特定の承認を必須としたりするなど、さまざまなプロジェクトにポリシーを適用する機能が必要です。

GitLabでは、コンプライアンスフレームワークという機能があるため、このようなポリシーを簡単に適用できます。構造化されたポリシーを定義し、特定のプロジェクトに対して適用できる機能です。これにより、シームレスで効率的なデベロッパーワークフローを維持しつつ、規制やセキュリティ要件へのコンプライアンスを自動的に実現できます。

AI搭載の開発支援

GitLab Duoは、すべての開発ステージにわたってAI主導のアシスタンスを提供します。そのため、いちいち外部ツールに切り替える必要性がなくなります。すべてのリクエストは、プロジェクトとコードベース全体のコンテキストを把握したAI搭載機能によって処理されるため、より効率的かつスマートに作業を進められます。

例を挙げると、AIは以下のようなタスクを実行できます。

• タスクの説明の自動生成
• イシューディスカッションのスマートな要約によるデベロッパーの貴重な時間の節約
• 高度なコードレビュー機能
• コードの改善および最適化の提案
• 自動テスト生成
• セキュリティの脆弱性の検出と修正
• 失敗したCIパイプラインの根本原因分析によるトラブルシューティング
• プライバシーとデータセキュリティ

公共機関や金融機関を始めとする規制の厳しい組織のニーズを理解しているGitLabは、セキュアな環境でAIモデルを実行できるよう独自のソリューションを提供しています。GitLab Duoセルフホストモデルを採用すると、各組織はデータプライバシー、セキュリティ、および大規模言語モデル（LLM）の独自インフラへのデプロイを完全に制御しつつ、以下を実現できます。

• データプライバシーの保護
• 規制要件へのコンプライアンス
• 最高レベルのセキュリティ
• 外部ネットワークの利用やリスクなしでAIのメリットを活用

まとめ

組織がプロセスの効率化、セキュリティの強化、イノベーションの加速を実現するためには、包括的なDevSecOpsプラットフォームが必要です。ビルトインのセキュリティ機能とAI搭載の自動化を備え、開発、セキュリティ、運用に不可欠なすべてのツールが統合された単一アプリケーションであるGitLabなら、まさにそれらを実現できます。

実際にGitLabがどのように動作するかをご覧になりたい方は、ぜひ以下のインタラクティブなデモをチェックしてみてください。

• GitLab Duoが搭載されたGitLab PremiumとUltimate – AI搭載の開発支援を体験しましょう

• CI/CDパイプラインへのセキュリティ実装 – 統合されたセキュリティスキャンによってソフトウェアをどのように保護できるかをご覧ください

• コンプライアンスフレームワーク – GitLabを使用して全プロジェクトにポリシーを適用してガバナンスを向上させる方法をご紹介します

GitLab 18オンラインリリースイベントに参加して、自律型AIが担う役割など、DevSecOpsプラットフォームの未来について学びましょう。今すぐご登録ください！

こうした高度な開発支援を実現するのが、次世代のGitLab Duo Chat「GitLab Duo Agentic Chat」です。これは、AIネイティブな開発支援の大きな進化形であり、現在は実験的なリリースとしてGitLabプラットフォームに新たに追加された機能です。 GitLab Duo Agentic Chatは、VS CodeでGitLab Workflow拡張機能をお使いのGitLab.comユーザーであれば利用できます。

Agentic Chatは、従来の対話型AIによるチャット体験を、ユーザーに代わってアクションを実行するチャット体験に変革します。複雑な問題を細かいタスクに分割し、自律的に完了することができます。Agentic Chatは、提供されたコンテキストに基づいて質問に答えるだけでなく、以下のようなことができます。

• 質問に答えるために必要な情報を自律的に判断する
• 複数の情報源から必要な情報を取得するための一連の操作を実行する
• プロジェクト全体から得られる分析結果を組み合わせて、包括的な回答を作成する
• ソリューションを実装するためにファイルを作成、編集する

これらすべての作業が、人間のデベロッパーが常に状況を把握できる状態で行われます。

Agentic Chatは、現在プライベートベータ版のDuo Workflowアーキテクチャ上に構築されています。このアーキテクチャは、与えられた質問に適したコンテキストを見つけたり、ファイルを編集したりするなど、特定のタスクを担うエージェントとツールで構成されています。

GitLab Duo Agentic Chatのユースケース

ここでは、Agentic Chatの実際の活用例と一般的なユースケースをご紹介します。

• 新しいプロジェクトにすばやくオンボーディング：新しいコードベースに慣れる作業をAIが支援することで、より迅速にプロジェクトに参加できます。

• 担当業務にすぐに着手：イシューの説明が不明確でも、Agentic Chatが要件と既存の実装との関連性を示してくれるため、すぐに担当作業に取りかかることができます。

• 変更の実装支援：変更作業が必要になった際には、Agentic Chatがプロジェクト全体にわたって複数のファイルを作成、編集し、実装を支援します。

• リリース時の検証：リリースの段階では、Agentic Chatがマージリクエストと元のイシューやタスクを照らし合わせて、ソリューションが本当に要件を満たしているかを検証する手助けをします。

<center><i>コードの編集を行う Agentic Chat</i></center>

学習からリリースまで：4ステップの開発ワークフロー

GitLabエンジニアリングチームの実際のシナリオを通じて、Agentic Chatが開発体験をどのように変革するかをご紹介します。あなたはチームの新メンバーとして、イシューを割り当てられましたが、コードベースについてはまだ何も知らないとします。 それでは、以下のデモ動画に従って体験してみましょう。

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

ステップ1：プロジェクトを理解する

ファイルやドキュメントを自分で探し回る代わりに、Agentic Chatに以下のように質問してみましょう。

このプロジェクトは初めてです。構造を読んで説明してもらえますか？

Agentic Chatは、以下の方法でプロジェクトの全体像をわかりやすく示してくれます。

• ディレクトリ構造の探索
• READMEファイルやドキュメントの読み取り
• 主要なコンポーネントやアプリケーションの特定

ステップ2：担当タスクを理解する

次に、あなたが担当するタスクの内容を把握する必要があります。以下のように質問してみましょう。

イシュー1119を担当することになりました。このタスクの内容を説明してもらえますか？特に、リファクタリングが必要な箇所はどこですか？

Agentic Chatは、以下の方法でタスクの説明とリファクタリングの提案を行ってくれます。

• リモートのGitLabサーバーからイシューの詳細を取得し、分析
• 関連するプロジェクトファイルの調査
• 変更が必要な箇所の特定

ステップ3：ソリューションを実装する

手動で作業する代わりに、以下のようにリクエストできます。

その編集を行ってもらえますか？ステップ1、2、3から始めてください。

Agentic Chatは以下のアクションを実行します。

• 必要に応じて新しいディレクトリやファイルを作成
• 複数の場所にまたがってコードを抽出、リファクタリング
• 変更されたすべてのファイル間で一貫性を維持
• 行ったすべての変更の要約を報告

ステップ4：作業の完了を確認する

マージリクエストを作成したら、最後に作業の完了を確認します。

このマージリクエストはイシュー1119を完全に解決していますか？

Agentic Chatは、マージリクエストと元のイシューの内容を分析し、すべての要件が満たされているかどうかを検証してくれます。

フィードバックをお待ちしています

GitLab Duo Agentic Chatは現在、VS Codeの実験的機能として、GitLab Duo ProおよびEnterpriseユーザーの皆様にご利用いただけます。前提要件や設定手順については、セットアップドキュメントをご確認ください。

実験的な機能であるAgentic Chatにはいくつかの既知の制限があります。これには、複数のAPIコールによる応答時間の遅延、文脈理解による検索ではなくキーワードベースの検索の実行、新しいローカルフォルダやGitLab以外のプロジェクトに対するサポートの制限などが含まれます。現在GitLabは、これらの事項の改善に積極的に取り組んでいます。 皆さまからのフィードバックは、改善の優先順位を決め、Agentic Chatを一般公開へと導く上で非常に重要です。ぜひ、こちらのイシューで皆さまの体験を共有してください。

今後の取り組み

GitLabは、Agentic Chatの改善と一般公開へ向けた開発を全力で進めています。主な取り組みとして、応答速度の改善のほか、現在のGitLab Duo Chatで利用可能な各種機能をAgentic Chatでも使えるようにする作業があります。これには、セルフホストモデルのGitLab Duoとの統合や、VS Codeに加えてJetBrainsやVisual Studioをサポートする機能拡張が含まれます。Duo Chatをこの新しいアーキテクチャに切り替えた後は、GitLab Webアプリケーション内のチャットにもAgentic Chatを導入する予定です。 また、GitLabアーティファクトの編集、カスタムモデルコンテキストプロトコル（MCP）サーバーからのコンテキストの取得、ターミナルで実行できるコマンドの提供など、多くの新機能の追加も予定しています。

まだGitLabをご利用でなくても、自律型の開発支援を今すぐ体験していただけます。GitLab UltimateとGitLab Duo Enterpriseの無料トライアルで、Agentic Chatを今すぐお試しください。AIを活用した開発の未来を一緒に形作りましょう。VS Codeでのセットアップ手順は、こちらからご確認いただけます。

免責事項：このブログには、今後の製品、機能、および機能性に関する情報が含まれています。本ブログ記事に含まれる情報は、情報提供のみを目的としている点にご留意ください。購入や計画の判断材料として使用することはお控えください。すべてのプロジェクトと同様に、このブログおよびリンク先のページに記載されている項目は、変更または遅延される場合があります。製品、機能、機能性の開発、リリース、およびタイミングに関する決定権は、GitLabに帰属します。

関連リンク

• GitLab Duo Workflow：自律型AIに対するエンタープライズレベルの可視性と管理
• 自律型AIとは？
• 自律型AIに関するガイドとリソース（英語）

1.はじめに<br> 2.はしがき<br> 3.Redmine<br> 本書で扱うRedmine<br> Redmineのインストール<br> セットアップ<br> 初期設定<br> GitLabのマニュアルの確認<br> GitLab側の設定<br> 実際に使用している様子<br> GitLabのコミット時に「#2」を指定している様子<br> 本インテグレーションのポイント<br> ご注意<br>

4.Backlog<br> 本書で扱うBacklog<br> Backlogの利用開始<br> ユーザ登録 <br> 初期設定<br> GitLabのマニュアルの確認<br> GitLab側の設定<br> GitLabのイシュー機能を非表示 <br> 実際に使用している様子 <br> GitLabのコミット時に「キー情報」を指定している様子 <br> 本インテグレーションのポイント<br> ご注意 <br>

5.Jira<br> 本書で扱うJiraと2つのユースケース <br> Jiraの利用開始<br> ユーザ登録 <br> 初期設定 <br> GitLabのマニュアルの確認 <br> ユースケース1. Jira Issue Integration <br> GitLab側の設定 <br> GitLabのイシュー機能を非表示 <br> 実際に使用している様子 <br> GitLabのコミット時に「URL情報」を指定している様子 <br> 本インテグレーションJira Issueのポイント <br> ご注意 <br> ユースケース2. Jira development panel Integration <br> Jira側の設定 <br> 実際に使用している様子 <br>

1.はじめに

本書は、GitLabのフリー版をお使いの皆様に、無料で実現できる他社製品とのインテグレーション方法について詳しく説明したものです。

ぜひ実際に手を動かして、セットアップしてみてください。
いずれもプロジェクト単位なので、他のGitLab上のプロジェクトに影響を与えることはありません。

2.はしがき

• 本書に登場する会社名および商品名は各社の商標または登録商標です。

• なお、本書ではⓇ、TM マークを明記しておりません。

• 本書で前提としている各製品等のバージョンは以下となります。

  GitLab.com および GitLab Community Edition/Enterprise Edition Free版 17.10

3.Redmine

本書で扱うRedmine

Redmineとは、https://www.redmine.org/ で提供されている、無料のプロジェクト管理ツールです。非常に人気が高いOSSプロダクトです。

引用元: https://www.redmine.org/

2025/04/01時点で、最新のものは、 6.0.4となっています。

引用元: https://www.redmine.org/

Redmineのインストール

セットアップ

本書では、Dockerをつかってインストールします。

以下のファイルを作成： docker-compose.yml

version: '3.1'

services:

  redmine:
    image: redmine
    restart: always
    ports:
      - 80:3000
    environment:
      REDMINE_DB_MYSQL: db
      REDMINE_DB_PASSWORD: example
      REDMINE_SECRET_KEY_BASE: supersecretkey

  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: example
      MYSQL_DATABASE: redmine

その後、以下のコマンドでインスタンスを起動します。

sudo docker compose up \-d

初期設定

Redmine側でプロジェクトや、イシューを作成できるよう、トラッカー等の設定をおこないます。一通りセットアップを完了します。

引用元: https://www.redmine.org/

仮に以下の内容で準備が完了したとします。

GitLabのマニュアルの確認

以下のURLで、GitLabとRedmineの設定方法についてのガイドが記載されています。

Redmine | GitLab Docs

GitLab側の設定

（*上記では、「新しいイシューのURL」を指定していますが、本機能はもう動作しません。UI上は入力チェック機能が動作するため、なにか適当な文字列を指定すればよいです。プロジェクトのURL、イシューのURLを指定し、「テスト設定」を押下して動作を確認します）

上記の「プロジェクトのURL」は、GitLabのメニューの以下の部分に表示されます。

実際に使用している様子

Redmine側で、以下のようにイシューを作成します。

引用元: https://www.redmine.org/

引用元: https://www.redmine.org/

GitLabのコミット時に「#2」を指定している様子

コミットした後、以下のようにリンクが作成されます。

上記で「Issue in Redmine」をクリックすると、以下の画面に遷移します。

引用元: https://www.redmine.org/

本インテグレーションのポイント

GitLabとRedmineのインテグレーションを実現すると、以下のような内容が実現できます。

1. Redmine側でイシューを作成
2. GitLab側でソースコード等へ修正を加え、コミット時に、Redmine側でのチケット番号を指定すると、URLとして保存される
3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのRedmineのチケットURLへ飛ぶことができる

ポイントとして、

• GitLab側から、Redmine側へ直接「書き込み」は行わない
• あくまでもリンクをつなげることで、GitLab ⇔ Redmine間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ

の2点が価値ポイントとなります。

ご注意

本機能を有効にすると、GitLab側の「イシュー」機能が利用できなくなります。

4.Backlog

本書で扱うBacklog

Backlogとは、株式会社ヌーラボ社から提供されている、製品です。ここでは、GitLabとのインテグレーション方法について解説します。

引用元: https://backlog.com/ja/

Backlogの利用開始

ユーザ登録

Backlogの契約がまだで、テスト的に利用したい場合は、Free版が提供されているようなので、それを利用するのものオススメです。

初期設定

Backlog側でプロジェクトの作成をおこないます。Backlogの場合、プロジェクトを作成すれば、すぐに使えるようになっています。

引用元: https://backlog.com/ja/

GitLabのマニュアルの確認

以下のURLで、GitLabとBacklogについては、汎用的な接続インターフェースで設定します。
この設定をした場合、GitLabの既存の「イシュー」機能も「存続」します。そのため、特に併用の必要がない場合は、GitLab側の「イシュー」を非表示することをおすすめします。

Custom issue tracker | GitLab Docs

GitLab側の設定

Backlogの場合、イシューのURLの部分に少し注意が必要です。上記では、プロジェクトIDは「PAGE1」ですが、イシューを参照したときのURLは、(イシュー番号が6の場合)「https://tsukasano.backlog.com/view/PAFE1-6」となります。そのため、分かりづらいですが、上記の「イシューのURL」のように、「:id」を含める部分については注意が必要です。不明であれば、一旦、Backlog側でイシューを開き、そのURLの構成を確認するとよいでしょう。

（* 上記では、「新しいイシューのURL」を指定していますが、本機能はもう動作しません。UI上は入力チェック機能が動作するため、なにか適当な文字列を指定すればよいです。プロジェクトのURL、イシューのURLを指定し、「テスト設定」を押下して動作を確認します）

上記の「プロジェクトのURL」は、GitLabのメニューの以下の部分に表示されます。

GitLabのイシュー機能を非表示

Backlogをメインとして使う場合、GitLabの「設定」ー「一般」ー「可視性、プロジェクトの機能、権限」より、「イシュー」をOffにします。

その後、[変更を保存]ボタンを押して、設定を反映します。
そうすると、以下のようにメニューの表示が変わります。

実際に使用している様子

Backlog側で、以下のようにイシューを作成します。 引用元: https://backlog.com/ja/

この時、上の図の矢印アイコンをクリックすると、課題名とキーが含まれた「キー情報」がクリップボードにコピーされます。

GitLabのコミット時に「キー情報」を指定している様子

コミットした後、以下のようにリンクが作成されます。

上記で「Issue in Custom issue tracker」をクリックすると、以下の画面に遷移します。

引用元: https://backlog.com/ja/

本インテグレーションのポイント

GitLabとBacklogのインテグレーションを実現すると、以下のような内容が実現できます。

1. Backlog側でイシューを作成
2. GitLab側でソースコード等へ修正を加え、コミット時に、Backlog側でのチケット番号を指定すると、URLとして保存される(Backlog側のUIから、チケット情報をコピーするとよいでしょう)
3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのBacklogのチケットURLへ飛ぶことができる

ポイントとして、

• GitLab側から、Backlog側へ直接「書き込み」は行わない
• あくまでもリンクをつなげることで、GitLab ⇔ Backlog間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ

の2点が価値ポイントとなります。

ご注意

本機能を有効にすると、GitLab側の「イシュー」機能は残りますので、特別な理由がない限り、GitLab側の「イシュー」機能は停止するとよいでしょう。

5.Jira

本書で扱うJiraと2つのユースケース

Jiraとは、アトラシアン社から提供されている、製品です。ここでは、GitLabとのインテグレーション方法について解説します。

ここで扱うユースケースは、2つあります。このJiraの場合だけ、少し特殊なのが面白いところです。
「Jira Issue」と「Jira development panel」Integrationです。

引用元: https://www.atlassian.com/software/jira

Jiraの利用開始

ユーザ登録

Jiraの契約がまだで、テスト的に利用したい場合は、Free版が提供されているようなので、それを利用するのものオススメです。

初期設定

Jira側でプロジェクトの作成をおこないます。Jiraの場合、プロジェクトを作成すれば、すぐに使えるようになっています。 引用元: https://www.atlassian.com/software/jira

GitLabのマニュアルの確認

以下のURLで、GitLabとJiraについては、専用のインターフェースで設定します。Jiraの場合は他のプロダクトと比較して、よりレベルの高いインテグレーションが可能になっています。

Jira | GitLab Docs

GitLabとJiraのインテグレーションは、以下の2箇所あります。

• Jira イシュー … チケット機能です
• Jira デベロップメントパネル … GitLab内のブランチ情報などをJiraに連携します

それぞれ、GitLabとどう関係するのかは、以下のURLをご参考ください。

Jira | GitLab Docs

例)

(以下続く)

ユースケース1. Jira Issue Integration

以下のURLにアクセスして、Jira側でAPIトークンを取得します。
https://id.atlassian.com/manage-profile/security/api-tokens

その時のユーザは、Jiraの管理者である必要があります。このユーザをつかって、GitLab側でのコミット情報をJira側にも書き込みます。

GitLab側の設定

ここでは、Web URLをつかって、インテグレーションをおこないます。

以下の部分はデフォルトでチェックされていますので、そのままにします。これにより、Jira側へコメントが自動書き込みされます。

GitLab Premium版以上を使うと、GitLabの「イシュー」画面から透過的にJiraのイシューを見ることができますが、本書はGitLabフリー版を前提としていますので、GitLabの「イシュー」機能を非表示にします。

GitLabのイシュー機能を非表示

Jiraをメインとして使う場合、GitLabの「設定」ー「一般」ー「可視性、プロジェクトの機能、権限」より、「イシュー」をOffにします。

その後、[変更を保存]ボタンを押して、設定を反映します。

そうすると、以下のようにメニューの表示が変わります。

実際に使用している様子

Jira側で、以下のようにイシューを作成します。

この時、上の図のクリップアイコンをクリックすると、このチケットへのURLがクリップボードにコピーされます。

GitLabのコミット時に「URL情報」を指定している様子

コミットした後、以下のようにリンクが作成されます。

一方、キー番号のみを記述すると以下にになります。

上記で「Issue in Jira issue」をクリックすると、以下の画面に遷移します。

このように、コメントが記入されますので、URLよりも、キーを指定することをおすすめします。

本インテグレーション（Jira Issue）のポイント

GitLabとJira Issueのインテグレーションを実現すると、以下のような内容が実現できます。

1. Jira側でイシューを作成
2. GitLab側でソースコード等へ修正を加え、コミット時に、Jira側でのチケット番号を指定すると、URLとして保存される
3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのJiraのチケットURLへ飛ぶことができる
4. さらに、そのJiraのチケットに、コミット時のコメントが記載される

ポイントとして、

• GitLab側から、Jira Issue側へ直接「書き込み」を行う
• チケットへのURLを貼ると、「書き込み」は行われない
• これにより、GitLab ⇔ Jira間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ

の3点が価値ポイントとなります。

ご注意

GitLab Free版を使う場合

本機能を有効にすると、GitLab側の「イシュー」機能は残りますので、特別な理由がない限り、GitLab側の「イシュー」機能は停止するとよいでしょう。

ご参考 GitLab Premium以上をご利用するとGitLabの「イシュー」から、JiraのIssueが見えるようになります。

Jira issues integration | GitLab Docs

また、GitLab Ultimateをご利用すると、GitLab側でセキュリティスキャンを行ったのち、脆弱性がみつかった際、その脆弱性をJira側へ新規のチケットとして起票する、という機能が利用可能です。

Jira issues integration | GitLab Docs

ユースケース2. Jira development panel Integration

このユースケースを使用する際、Jira側でどの「Jira」を使っているのかが重要になります。Atlassian社が提供するクラウドサービスを使っている場合、「GitLab for Jira Cloud app」(GitLab製)を使います。一方、オンプレミス版の「Jira Data Center or Jira Server」を使っている場合は、「Jira DVCS connector」（Atlassian社製）を使います。

本書では、クラウドサービスのJiraを使っている、という前提で解説します。

Jira側の設定

Jiraの画面で、「アプリ」ー「その他のアプリを探す」をクリックします。

引用元: https://www.atlassian.com/software/jira

ここで、GitLab製のこの「GitLab for Jira Cloud」Appをインストールします。

引用元: https://www.atlassian.com/software/jira

引用元: https://www.atlassian.com/software/jira

これで無事インストールが完了です。

完了すると、次のポップアップが表示されますので、「Get started」をクリックします。

引用元: https://www.atlassian.com/software/jira

すると、次の画面が表示されますので、GitLab.comを選択した状態で、認証を完了させます。

引用元: https://www.atlassian.com/software/jira

引用元: https://www.atlassian.com/software/jira

次に、このAppを有効にするGitLab側のグループを選択する画面になります。ここで、任意のグループを選択します。

引用元: https://www.atlassian.com/software/jira

ここで選択できるのは、プロジェクトではなく、グループです。

引用元: https://www.atlassian.com/software/jira

無事完了すると、次の画面になります。

引用元: https://www.atlassian.com/software/jira

実際に使用している様子

では、実際になにがどう見えるのか実践してみます。

Jira側で、なにか適当なイシューを作成するなり、見つけてみましょう。そのキーが「KAN-14」だとします。 引用元: https://www.atlassian.com/software/jira

ここで、GitLab側でなにか適当に変更して、コミットする際のダイアログボックス画面で以下のように入力します。

Jira側にもどって、該当チケットを見てみます。

赤矢印のところに、GitLab側のレポジトリ情報が連携されていることがわかります。

引用元: https://www.atlassian.com/software/jira

以下のように、コミット情報等も連携されていることがわかります。

引用元: https://www.atlassian.com/software/jira

また、「すべての開発情報を表示」をクリックすると、以下のような画面も表示されます。 引用元: https://www.atlassian.com/software/jira

参考までに、この時点でこのAppをアンインストールすると、以下のように、開発情報は表示されなくなります。 引用元: https://www.atlassian.com/software/jira

Jira側からブランチを作成することも可能です。
引用元: https://www.atlassian.com/software/jira

また、以下は他のチケットですが、一度コミット時にJiraとの紐づけを行っておくと、そのブランチに対してビルドしたり、デプロイしたりした履歴が、以下のようにJira側にも反映されます。

引用元: https://www.atlassian.com/software/jira

引用元: https://www.atlassian.com/software/jira

このように、Jiraのチケットから、「最終的にいまどこまで進んだ？」みたいな内容まで確認できるようになります。

以前の記事で、GitLab CI/CDについて取り上げました。今回はCI/CD変数の世界をさらに深く掘り下げ、その力を最大限に引き出す方法について説明します。

CI/CD変数とは

CI/CD変数とは、GitLab環境内においてさまざまなレベル（プロジェクト、グループ、インスタンスなど）で定義できる動的なキーと値のペアのことです。.gitlab-ci.ymlファイルで使用できる値のプレースホルダーとして機能するため、パイプラインをカスタマイズしたり、機密情報を安全に保存したりできるほか、CI/CD設定を管理しやすくなります。

CI/CD変数が重要な理由

CI/CD変数の使用には、以下のような多くのメリットがあります。

• 柔軟性 - 主要なCI/CDスクリプトに手を加えることなく、さまざまな環境、設定、またはデプロイ対象にパイプラインを簡単に適応させられます。
• セキュリティ - API キー、パスワード、トークンのような機密情報を安全に保存して、コード内で直接公開されることのないようにします。
• 保守性 - 変数の値を一元化することで、CI/CDの設定がきれいに整理された状態に保たれるため、更新や修正作業を簡単に行えます。
• 再利用性 - 一度定義した変数は複数のプロジェクトで再利用できるため、重複が減り、一貫性を保ちやすくなります。

CI/CD変数のスコープ：プロジェクト、グループ、インスタンス

GitLabでは、次のようなさまざまなスコープでCI/CD変数を定義し、その可視性と有効範囲を制御できます。

• プロジェクトレベルの変数 - 単一のプロジェクト専用の変数で、次のようなプロジェクト固有の設定を保存するのに適しています。

  • デプロイURL：ステージング環境や本番環境向けのURLをそれぞれ定義します。
  • データベース認証情報：テストやデプロイ用のデータベース接続情報を保存します。
  • 機能フラグ：パイプラインのさまざまな段階で機能を有効または無効にします。
  • 例："MyWebApp"というプロジェクトがあり、本番環境へのデプロイURLを保存したいとします。その場合、プロジェクトレベルでDPROD_DEPLOY_URLという名前の変数を作成し、https://mywebapp.comという値を格納します。

• グループレベルの変数 - グループレベルの変数を作成すると、GitLabグループ内の全プロジェクトで共有されます。次のような複数のプロジェクトに共通する設定がある場合に便利です。

  • 共有サービスのAPIキー：グループ内の複数のプロジェクトで使用されるサービス（AWS、Google Cloud、Docker Hubなど）のAPIキーを保存します。
  • グローバル構成設定：グループ内の全プロジェクトに適用される共通の設定パラメータを定義します。
  • 例：「Web Apps」というグループがあり、Docker Hub用にAPIキーを保存したいとします。その場合は、グループレベルでDOCKER_HUB_API_KEYという名前の変数を作成し、対応するAPIキーの値を格納します。

• インスタンスレベルの変数 - GitLabインスタンスの全プロジェクトで利用可能な変数です。通常は、次のような組織全体に適用するグローバル設定がある場合に使用します。

  • デフォルトのRunner登録トークン：新規Runnerの登録時にデフォルトのトークンを提供します。
  • ライセンス情報：GitLabの機能やサードパーティツールのライセンスキー情報を保存します。
  • グローバル環境設定：全プロジェクトで利用可能な環境変数を定義します。
  • 例：GitLabインスタンス上の全プロジェクトにおいて、デフォルトのDockerイメージを設定したいとします。その場合、インスタンスレベルでDEFAULT_DOCKER_IMAGEという名前の変数を作成し、ubuntu:latestという値を格納します。

CI/CD変数を定義する

CI/CD変数は以下の手順で定義できます。

1. プロジェクト、グループ、またはインスタンスで、設定 > CI/CDボタンの順にクリックします。
2. 変数セクションに移動します。
3. 変数を追加をクリックします。
4. キー（例：API_KEY）と値を入力します。
5. 機密情報を扱う場合は、必要に応じて変数を保護ボックスをオンにします。オンにすると、保護ブランチまたは保護タグで実行されているパイプラインでのみ、変数が利用可能になります。
6. 必要に応じて、変数をマスクボタンをオンにすると、ジョブログで変数の値が非表示になります。これにより、誤って公開されるのを防げます。
7. 変数を保存をクリックします。

CI/CD変数を使用する

.gitlab-ci.ymlファイルでCI/CD変数を使用する方法は簡単です。変数名の前にプレフィックスとして$を付けるだけです。

deploy_job:
  script:
    - echo "Deploying to production..."
    - curl -H "Authorization: Bearer $API_KEY" https://api.example.com/deploy

定義済みのCI/CD変数

GitLabでは、パイプラインでご利用いただけるように、定義済みのCI/CD変数を一式ご用意しています。これらの変数は、現在のパイプラインやジョブ、プロジェクトなどに関する情報を提供します。

その中でも、使用されることの多い定義済み変数をいくつかご紹介します。

• $CI_COMMIT_SHA：現在のパイプラインのコミットSHA。
• $CI_PROJECT_DIR：プロジェクトの複製先のディレクトリ。
• $CI_PIPELINE_ID：現在のパイプラインのID。
• $CI_ENVIRONMENT_NAME：デプロイ先の環境名（該当する場合）。

ベストプラクティス

• 機密性の高い変数は安全に管理する：APIキーやパスワード、その他の機密情報を扱う場合は、保護およびマスクされた変数を使用しましょう。
• 値のハードコーディングは行わない：設定値を保存する際は変数を使用しましょう。そうすることで、パイプラインの柔軟性と保守性が高まります。
• 変数を整理する：変数をわかりやすい名前を付けて、関連する変数をまとめると、うまく整理できます。
• 適切なスコープを選ぶ：希望する変数の用途と可視性に基づいて、適切なスコープ（プロジェクト、グループ、またはインスタンス）を選びましょう。

変数の力を最大限に活用する

CI/CD変数は、GitLabパイプラインをカスタマイズし、保護するための強力なツールです。変数を使いこなし、各スコープを理解することで、より柔軟で保守しやすく、効率的なワークフローを作成できます。

開発プロジェクトにおいて、GitLabの機能を活用していただくために必要な情報をお届けしました。ご紹介した情報がお役に立てば幸いです。

Duo Enterpriseが搭載されたGitLab Ultimateの60日間無料トライアルに今すぐ申し込んで、CI/CD変数を早速ご利用ください。

「GitLab入門」シリーズ

「GitLab入門」シリーズのその他の記事もぜひご覧ください。

• ユーザーの管理方法
• GitLabへのプロジェクトのインポート方法
• プロジェクト管理を極める
• gitlab-triage gemを使ったアジャイルワークフローの自動化
• CI/CDについて理解する

GitLab 18.0をリリース：GitLab DuoがPremiumとUltimateで利用可能に

このたび、GitLab 18.0のリリースを発表しました。このリリースでは、GitLab PremiumとGitLab UltimateにGitLab Duoが搭載され、GitLab Duoコードレビューによる自動レビュー、コンテキストをより考慮したコードレビュー、GitLab Duo Self-Hostedで利用可能なリポジトリX-Rayなど、さまざまな新機能が追加されました。

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

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

GitLab 18の新機能を活用することで、開発からリリースまでの全工程でAIの力を活用しつつ、開発者のスピードを落とさずにセキュリティを強化できます。これらがすべて、一つのプラットフォームで実現します。新機能については、GitLab 18のオンラインリリースイベント「The next step in intelligent DevSecOps（知的進化する次世代のDevSecOps）」で詳しくご紹介いたします。ご参加をお待ちしています。

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

GitLab 18.0では、PremiumおよびUltimate向けのGitLab Duoが追加されました。 クリックしてSNSで共有しましょう！

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

<img src="https://about.gitlab.com/images/notable-contributor-logo.svg">

トップコントリビューターであり、コミュニティリーダーでもあるMichael Hoferさんは、GitLabのオープンソースミッションを推進しています。今年だけで50件以上のコントリビュートを行い、その活動はOpenBaoに基づくGitLabのGeo機能やシークレットマネージャーの強化に大きく貢献しました。また、4月のハッカソンではトップの成績を収め、他のコントリビューターを支援しながらコミュニティプロジェクトも率いています。

「GitLabには誰もがコントリビュートできる環境があるので、とても感謝しています！」とMichaelさんは言います。「素晴らしいチームで、一緒に取り組んでいてとても楽しいです。特に、OpenBaoやSLSAのようなオープンソースイニシアチブで協力する際は、みんな本当に頼りになります。」

Michaelさんは、ミッションクリティカルなオープンソースワークロードの計画、構築、運用に特化した国際的なITサービスプロバイダーであるAdfinis社のCTOを務めています。Michaelさんは、組織間での協力を促進し、オープンソースソリューションの普及に情熱を注いでいます。

最近、Adfinis社はGitLabの共同開発プログラムに参加しました。このプログラムでは、組織がGitLabの製品チームおよびエンジニアリングチームと協力して、GitLabの構築に取り組んでいます。「共同開発プログラムを、すべての組織に強くお勧めしたいです」とMichaelさんは話します。「PodmanのルートレスビルドやGlimmerの構文ハイライトに加え、その他多くの素晴らしいコントリビュートを生み出しました。」

GitLabのエンジニアリングマネージャーであり、今回Michaelさんを推薦したLucie Zhaoは次のように話します。「GeoチームはMichaelさんとの共同作業に大きなやりがいと楽しみを感じています。Michaelさんは、ここ数件のマイルストーンでの素晴らしいコントリビュートにより、チーム内で最も知られたコミュニティコントリビューターとなりました。」

GitLabチームメンバーのLee Tickett、Chloe Fons、Alex Scheelも、Michaelさんの推薦を支持しました。Alexは次のように述べています。「MichaelさんのOpenBaoでのリーダーシップにより、お客様向けのシークレット管理ソリューションを効果的に共同開発することができました。また、透明性も確保され、GitLabの価値観に沿って進められました。」

GitLabの共同開発に取り組んでくださっているMichaelさんとAdfinisチームのみなさま、ありがとうございます！ <br> <br> <br>

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

GitLab DuoがGitLab PremiumおよびGitLab Ultimateで利用可能に

SaaS: Premium、Ultimate、Duo Pro、Duo Enterprise
Self-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise

このリリースから、GitLab PremiumとGitLab UltimateでGitLab Duoが利用可能になりました。両プランにAI機能が標準搭載されます。

GitLabのAIネイティブ機能には、IDE内のコード提案とチャット機能があります。開発チームは、これらの機能を使用して次の作業を効率化できます。

• コードを分析し、理解し、説明する
• より迅速に安全なコードを記述する
• コード品質を維持するためのテストを素早く生成する
• パフォーマンス向上や特定のライブラリの利用に合わせてコードを簡単にリファクタリングする

ドキュメント
イシュー

<img src="https://about.gitlab.com/images/18_0/Premium_Duo.png">

GitLab Duo Self-HostedでリポジトリX-Rayが利用可能に

SaaS: - <br> Self-Managed: Premium、Ultimate、Duo Enterprise

GitLab Duo Self-Hostedで、コード提案と併せてリポジトリX-Rayを使用できるようになりました。この機能は、GitLab Duo Self-Hostedではベータ版として提供され、GitLab Self-Managedインスタンスでは一般提供されています。

ドキュメント
エピック

<img src="https://about.gitlab.com/images/17_11/eclipse-beta.png">

GitLab Duoコードレビューによる自動レビュー

SaaS: Premium、Ultimate、Duo Enterprise<br> Self-Managed: Premium、Ultimate、Duo Enterprise

Duoコードレビューは、コードレビューのプロセスで効果的なフィードバックを提供しますが、これまでは各マージリクエストごとに手動でレビューをリクエストする必要がありました。

今回、プロジェクトのマージリクエスト設定を変更することで、Duoコードレビューを自動的に実行できるようになりました。自動レビュー機能を有効にすると、以下の場合を除き、すべてのマージリクエストに対してDuoコードレビューが自動でレビューを行います。

• マージリクエストがドラフトとしてマークされている場合
• マージリクエストに変更が含まれていない場合

自動レビュー機能により、プロジェクト内のすべてのコードが確実にレビューされ、コードベース全体のコード品質が継続的に改善されます。

ドキュメント
イシュー

<img src="https://about.gitlab.com/images/18_0/create-auto-dcr.png">

コード提案にプロンプトキャッシュを導入

SaaS: Premium、Ultimate、Duo Pro、Duo Enterprise
Self-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise

コード提案にプロンプトキャッシュ機能が追加されました。この機能により、キャッシュされたプロンプトや入力データの再処理が不要になるため、コード補完の待機時間が大幅に短縮されます。キャッシュデータは永続ストレージに保存されることはなく、必要に応じてGitLab Duoの設定でプロンプトキャッシュを無効にすることも可能です。

ドキュメント
エピック

<img src="https://about.gitlab.com/images/18_0/prompt-cache.png">

コンテキストをより考慮したコードレビュー

SaaS: Premium、Ultimate、Duo Enterprise<br> Self-Managed: Premium、Ultimate、Duo Enterprise

コードレビューがより広範なコンテキスト情報を活用できるようになり、分析結果の精度が向上しました。主な改善点は以下のとおりです。

• マージリクエストのタイトルと説明を含めることで、変更の目的をより正確に把握できるようになりました。
• すべての差分を一度に分析することで、ファイル間の関連性を認識し、誤検出を削減します。
• 変更されたファイル全体の内容を読み込み、修正が既存のコードパターンにどのように適合するかを理解できるようになりました。

これらの機能強化により、不正確な提案が減少し、より関連性が高く高品質なコードレビューが可能になりました。

ドキュメント
イシュー
イシュー

イシュー

<img src="https://about.gitlab.com/images/18_0/create-dcr-improved-context.png">

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

グループとプレースホルダーユーザーの削除

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLab 18.0では、トップレベルグループを削除すると、そのグループに関連付けられたプレースホルダーユーザーも同時に削除されるようになりました。プレースホルダーユーザーが他のプロジェクトに関連付けられている場合は、トップレベルグループからのみ削除され、他のプロジェクトには残ります。これにより、他のプロジェクトの履歴や属性を損なうことなく、不要なプレースホルダーユーザーを整理できるようになりました。

ドキュメント
イシュー

Slackアプリ用GitLabで複数のワークスペースに対応

SaaS: -<br> Self-Managed: Free、Premium、Ultimate

GitLab Self-ManagedおよびGitLab Dedicatedのお客様向けに、GitLab for Slackアプリで複数のワークスペースを利用できるようになりました。この機能により、複数のSlackワークスペースを持つ組織でも、すべてのワークスペースでGitLabとの連携をスムーズに維持できます。複数のワークスペースを有効にするには、GitLab for Slackアプリを非公開配布アプリとして設定してください。

ドキュメント
イシュー

GitLab Pagesテンプレートの改善

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLabでは、人気の高い静的サイトジェネレーター用のテンプレートを提供しています。スコアリングフレームワークでテンプレートを精査し、最も人気のあるものだけを厳選しました。

GitLab Pagesで利用可能なテンプレートが改良されたことにより、ウェブサイト制作の工程がよりスムーズになりました。テンプレートを活用すれば、技術的な専門知識が限られていてもプロ並みのサイトを立ち上げることができます。改善されたテンプレートは最新のレスポンシブデザインに対応しており、カスタム開発作業の必要もありません。

ドキュメント
エピック

ワークスペースの共有Kubernetesネームスペース

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

共有のKubernetesネームスペースにGitLabワークスペースを作成できるようになりました。これにより、ワークスペースごとに新しいネームスペースを作成する必要がなくなり、エージェントに上位のClusterRole権限を付与する必要もなくなります。この機能により、セキュリテイが厳しい環境または制約のある環境でもワークスペースをより容易に導入できるようになり、よりスムーズにスケールできるようになります。

共有のネームスペースを有効にするには、エージェント設定ファイルのshared_namespaceフィールドを設定し、すべてのワークスペースで使用したいKubernetesネームスペースを指定してください。

この機能は、GitLabの共同開発プログラムを通じて開発され、6人のコミュニティメンバーの協力によって実現しました。皆さまのコントリビュートに感謝します！

ドキュメント
エピック

<iframe width="560" height="315" src="https://www.youtube.com/embed/CXakdRuoGgU?si=indgAnCrTuIhUhcM" 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>

GitLab Runner 18.0

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

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

新機能：

• GitLab Runnerビルドエラー分類にConfigurationErrorとExitCodeInvalidConfigurationを新たに追加
• Cloud Storageへのキャッシュアップロードに失敗した場合に、よりわかりやすいクラウドプロバイダーエラーメッセージを表示するよう改善

バグ修正：

• GitLab Runnerが、許可されていない場合でもキャッシュされたイメージを使用できてしまう

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

ドキュメント

Kubernetes用ダッシュボードのポッド状態表示を改善

SaaS: Free、Premium、Ultimate<br> Self-Managed: Free、Premium、Ultimate

Kubernetes用のダッシュボードを使用すると、デプロイされたアプリケーションをモニタリングできます。これまでCrashLoopBackOffやImagePullBackOffなどのコンテナエラーがあるポッドは「保留中」または「実行中」というステータスで表示されていたため、kubectlを使用せずに問題のあるデプロイメントを特定するのが困難でした。

GitLab 18.0からは、UI上のエラー表示がkubectl出力と同様に、特定のコンテナのステータスを示すようになりました。これにより、GitLabインターフェイスだけで失敗したポッドをすばやく特定し、トラブルシューティングを行えるようになりました。

ドキュメント
イシュー

<img src="https://about.gitlab.com/images/18_0/deploy-improve-pod-status-visualizations.png">

セキュリティスキャナーがMRパイプラインに対応

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

マージリクエスト（MR）パイプラインでアプリケーションセキュリティテスト（AST）スキャナーを実行できるようになりました。パイプラインへの影響を最小限に抑えるため、この機能はオプトインで制御可能です。

これまでは、スキャナーを有効にする際に使用するCI/CDテンプレートのエディション（StableかLatest）によって、デフォルトの動作が異なっていました。

• Stableのテンプレートでは、スキャンジョブはブランチパイプラインでのみ実行され、MRパイプラインでは実行されませんでした。
• Latestのテンプレートでは、MRが開いている場合はMRパイプラインでスキャンジョブが実行され、関連するMRがない場合はブランチパイプラインで実行されており、この動作を制御することはできませんでした。

今回、新しいオプションとしてAST_ENABLE_MR_PIPELINESが追加され、MRパイプラインでジョブを実行するかどうかを制御できるようになりました。StableテンプレートとLatestテンプレートのデフォルトの動作は変わりません。

具体例：

• Stableテンプレートでは引き続き、デフォルトでブランチパイプラインでスキャンジョブを実行しますが、AST_ENABLE_MR_PIPELINES: "true"を設定すると、MRが開いている場合にMRパイプラインを使用できます。
• Latestテンプレートでは引き続き、MRが開いている場合はデフォルトでMRパイプラインでスキャンジョブを実行しますが、AST_ENABLE_MR_PIPELINES: "false"を設定すると、代わりにブランチパイプラインを使用できます。

今回の改善は、API Discovery（API-Discovery.gitlab-ci.yml）を除くすべてのセキュリティスキャンテンプレートに適用されます。API Discoveryは現在、MRパイプラインがデフォルトですが、GitLab 18.0では他のStableテンプレートと同様に、デフォルトでブランチパイプラインを使用するように変更されました。

ドキュメント
イシュー

JiraインテグレーションAPIを使用して脆弱性からJiraのイシューを作成する設定が可能に

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

これまでは、脆弱性からJiraのイシューを作成する設定は、プロジェクト設定ページからしか行えませんでした。

今回の更新により、プロジェクト統合APIからも設定できるようになり、セットアップの自動化が可能になりました。

ドキュメント
イシュー

再検出された脆弱性のトレーサビリティの向上

SaaS: Ultimate
Self-Managed: Ultimate

これまで、解決済みの脆弱性が再検出されてステータスが変更された場合、脆弱性の詳細にはいつ、なぜステータスが変更されたかを示す情報が含まれていませんでした。

解決済みの脆弱性が新しいスキャンで再び検出されてステータスが変更された場合、GitLabはその脆弱性の履歴にシステムメモを自動的に追加するようになりました。これにより、ユーザーは脆弱性のステータスが変更された経緯を明確に把握できるようになります。

ドキュメント
イシュー

コンプライアンスプロジェクトレポートでアーカイブされたプロジェクトの表示とフィルタリングが可能に

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

コンプライアンスプロジェクトレポートでは、グループまたはサブグループ内の各プロジェクトに適用されているコンプライアンスフレームワークを確認することができます。

ただし、これまでのレポートでは、プロジェクトがアーカイブされているかどうかを表示する機能がなく、アクティブなプロジェクトとアーカイブ済みプロジェクトの両方のコンプライアンス管理に必要な情報が十分ではありませんでした。

そこで今回、プロジェクトがアーカイブされているかどうかを示すインジケータが追加されました。これにより、コンプライアンスフレームワークを確認する際に、プロジェクトがアクティブかアーカイブ済みかを問わず、コンプライアンス状況をより明確に把握できるようになりました。

この機能には以下が含まれます。

• コンプライアンスプロジェクトレポートの各プロジェクトに、アーカイブ済みかどうかを示すステータスバッジを表示
• アーカイブ済み、アーカイブされていない、すべてのプロジェクトを切り替えるフィルター

ドキュメント
イシュー

GitLabユーザー名を使用したLDAP認証

SaaS: -<br> Self-Managed: Premium、Ultimate

LDAPユーザーは、GitLabユーザー名を使用してリクエストを認証できるようになりました。これまでは、GitLabユーザー名がLDAPユーザー名と一致しない場合、GitLabは認証エラーを返していました。今回の変更により、承認ワークフローに影響を与えることなく、GitLabシステムとLDAPシステムで異なるユーザー名の命名規則を採用できるようになりました。

ドキュメント
イシュー

カスタムロールの新しい権限

SaaS: Ultimate
Self-Managed: Ultimate

保護環境を管理する権限をカスタムロールに設定できるようになりました。カスタムロールを使用すれば、ユーザーに対して、タスクの完了に必要な特定の権限のみを付与できます。これによりグループのニーズに合わせてロールを定義できるため、オーナーまたはメンテナーロールが必要なユーザー数を減らすことができます。

ドキュメント
エピック

ユーザーネームスペースのプロジェクトにも削除保留機能を追加

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

ユーザーネームスペース（個人プロジェクト）のプロジェクトでも、プロジェクト削除保留機能が利用できるようになりました。誤削除からデータを守るこの安全機能は、これまではグループプロジェクトでしか利用できませんでした。今回の更新により、ユーザーネームスペースでプロジェクトを削除しても、すぐに完全に削除されるのではなく、インスタンスの設定期間（GitLab.comでは7日間）は「削除保留中」の状態になります。これにより、期間内であれば、必要に応じてプロジェクトを元に戻すことが可能になりました。

ユーザーの皆さまがより安心して個人プロジェクトを管理できるよう設計された保護機能です。

ドキュメント
イシュー

破壊的な変更を伴うGitLabチャート9.0のリリース

SaaS: -<br> Self-Managed: Free、Premium、Ultimate

• 破壊的な変更：PostgreSQL 14と15のサポートが削除されました。GitLabチャート9.0にアップグレードする前に、PostgreSQL 16にアップグレードされていることを確認してください。
• 破壊的な変更：バンドルのPrometheusチャートが15.3から27.11に更新されました。Prometheusチャートのアップグレードに伴い、Prometheusバージョンも2.38から3.0に更新されました。このアップグレードを実行するには、手動での設定が必要です。Alertmanager、Node Exporter、Pushgatewayのいずれかが有効になっている場合は、Helm値も更新する必要があります。詳細については、移行ガイドを参照してください。
• 破壊的な変更：デフォルトのNGINXコントローラーイメージがバージョン1.3.1から1.11.2に更新されました。GitLab NGINXチャートを使用し、独自のNGINX用RBACルールを設定している場合は、新しいRBACルールが必要となります。詳細については、アップグレードガイドを参照してください。

ドキュメント
イシュー

GitLab Dedicated向けに内部リリース機能を提供開始

SaaS: -<br> Self-Managed: Ultimate

GitLab Dedicatedを選択される組織の多くは、厳格なセキュリティ要件やコンプライアンス義務を満たすために、開発環境における最高レベルの保護を必要としています。このたび、「内部リリース」という新しいプライベートリリース機能の提供を開始しました。致命的な脆弱性が一般に公開される前にGitLab Dedicatedインスタンスに修正を適用できるようになり、GitLab Dedicatedのお客様をリスクから保護します。この新機能は、GitLab.comでの対応と並行し、GitLabで発見された致命的な脆弱性に対して即時の保護を提供するものです。この新しいプロセスは、お客様側での操作は必要ありません。

ドキュメント
エピック

グループとプロジェクトのREST APIに新しいアクティブパラメータを追加

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

グループとプロジェクトのREST APIに新しいアクティブパラメータが追加されました。これにより、ステータスに基づいたグループのフィルタリングが簡素化されます。trueに設定すると、アーカイブされていないグループ、または削除マークが付いていないプロジェクトのみが返されます。falseに設定すると、アーカイブされたグループ、または削除マークが付いているプロジェクトのみが返されます。パラメータを指定しない場合、フィルタリングは適用されません。この機能強化により、簡単なAPIコールで特定のステータスを持つグループやプロジェクトだけを選び出せるようになり、作業プロセス全体をより効率的に管理できるようになります。

このパラメータをプロジェクトAPIに追加してくれた@dagaranupamさんに感謝します！

ドキュメント
イシュー
イシュー

GitLab.comでのコントリビュートの再アサイン時にEnterpriseユーザーのみを表示

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

今回のリリースでは、プレースホルダーユーザーマッピング体験を向上させました。具体的には、ユーザー選択ドロップダウンの表示範囲を、トップレベルグループに関連付けられたEnterpriseユーザーに絞り込むように改善しました。これまで、GitLab.comへのインポート後にユーザーのコントリビュートを再アサインすると、プラットフォーム上のすべてのアクティブユーザーがドロップダウンリストに表示されていました。この仕様では、特にSCIMプロビジョニングでユーザー名が変更されている場合などは、正しいユーザーを特定するのが困難でした。今回の変更により、トップレベルグループでEnterpriseユーザー機能が有効になっている場合、ドロップダウンリストには組織が要求したユーザーのみが表示されるようになり、ユーザーの再アサイン時に発生するエラーの可能性が大幅に低減されます。同様の絞り込みがCSVベースの再アサインにも適用されるため、組織外のユーザーへの誤ったアサインを防ぐことができます。

ドキュメント
イシュー

GitLabクエリ言語ビューの機能強化

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

GitLabクエリ言語（GLQL）ビューが大幅に改善されました。新しく追加された機能は以下のとおりです。

• すべての日付型で>=および<=の条件指定が可能に
• ビューの「ビューアクション」ドロップダウンが追加
• 「再読み込み」アクションが利用可能に
• フィールドエイリアス対応
• GLQLテーブルの列でカスタム名にエイリアス設定が可能に

この機能強化およびGLQLビュー全般に関するフィードバックは、イシュー509791からお寄せください。

ドキュメント
エピック

マージリクエストからワークスペースを作成

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

新しい「ワークスペースで開く」オプションを使用して、マージリクエストから直接ワークスペースを作成できるようになりました。この機能は、マージリクエストのブランチとコンテキストを使用してワークスペースを自動的に構成し、以下のことを可能にするものです。

• 完全に設定された環境でコード変更をレビュー
• マージリクエストブランチでテストを実行し、機能を検証
• ローカル環境の設定なしでマージリクエストに修正を追加

ドキュメント
イシュー

ファイルをターゲットとするオープンマージリクエストの表示

SaaS: Free、Premium、Ultimate<br> Self-Managed: Free、Premium、Ultimate

これまでは、コードファイルを編集する際に、他のブランチで同じファイルを変更している可能性のあるユーザーの動向を把握することはできませんでした。このため、マージの競合や作業の重複、非効率的なコラボレーションが生じていました。

今回の変更により、リポジトリで表示しているファイルを変更しているすべてのオープンマージリクエストを簡単に特定できるようになりました。この機能は次のような場面で役立ちます。

• マージコンフリクトを事前に特定する
• すでに進行中の作業の重複を回避する
• 進行中の変更を可視化してコラボレーションを強化する

ファイルを変更しているオープンマージリクエストの数がバッジに表示され、その上にカーソルを合わせると、該当するマージリクエストのリストがポップオーバーで表示されます。

ドキュメント
イシュー

<img src="https://about.gitlab.com/images/18_0/mr-open-workspace.png">

新しい「CI/CDの分析」表示機能の限定提供を開始

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

「CI/CDの分析」のデザインが改良され、開発チームがパイプラインのパフォーマンスと信頼性を新しい方法で分析、監視、最適化できるようになりました。デベロッパーは、GitLabの操作画面に表示される直感的なグラフによってパフォーマンスの傾向や信頼性に関するメトリクスを確認できます。これらの分析情報をプロジェクトリポジトリに埋め込むことで、デベロッパーの作業の流れを中断させる頭の切り替えが不要になります。そして、チームは、生産性を低下させるパイプラインのボトルネックを特定して対処することができます。この機能強化により、開発サイクルの高速化、コラボレーションの向上が実現されるだけでなく、具体的な分析結果に基づき、GitLabのCI/CD環境を最適化するための信頼できる材料を得ることができます。

ドキュメント
イシュー

<iframe width="560" height="315" src="https://www.youtube.com/embed/78Nxbem9OAk?si=KTKVK7EsiW9E4Zxm" 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>

イベントデータ収集

SaaS: -<br> Self-Managed: Free、Premium、Ultimate

GitLab 18.0では、GitLab Self-ManagedおよびGitLab Dedicatedインスタンスからイベントレベルの製品使用状況データの収集が有効にされます。集計データとは異なり、イベントレベルのデータは製品利用の実態をより正確に把握するための情報源となります。これにより、プラットフォーム上のユーザーエクスペリエンスを向上させ、機能の利用率を高めることができます。データ共有設定を調整する方法の詳細については、ドキュメントを参照してください。

ドキュメント
イシュー

脆弱性レポートからイシューへ脆弱性を一括追加

SaaS: Ultimate
Self-Managed: Ultimate

今回リリースでは、脆弱性レポートから新規または既存のGitLabイシューに複数の脆弱性を一括追加できるようになりました。これにより、複数のイシューと脆弱性を関連付けることが可能になります。さらに、関連する脆弱性がイシューページに表示されるようになりました。

ドキュメント
エピック

ライセンス承認ルールからパッケージを除外

SaaS: Ultimate
Self-Managed: Ultimate

マージリクエスト承認ポリシーに追加されたライセンス承認ポリシーの新機能により、法務チームやコンプライアンスチームは、特定のライセンスを使用できるパッケージをより細かく制御できるようになりました。これにより、組織のポリシーによって通常ブロックされるライセンスを使用している場合でも、事前に承認されたパッケージの例外を作成できるようになります。

これまでのライセンス承認ポリシーでは、AGPL-3.0などのライセンスをブロックした場合、組織内のすべてのパッケージでそのライセンスがブロックされていました。これにより、次のような場面で問題が発生していました。

• 法務チームが、通常は制限されているライセンスであっても特定のパッケージを事前に承認している場合
• 数百件ものプロジェクトで同じパッケージを使用する必要がある場合
• チームごとに異なるライセンスの例外が必要な場合

今回のリリースでは、厳格なライセンスガバナンスを維持しつつ必要な例外を許可できるようになり、承認のボトルネックや手作業でのレビューを大幅に削減できます。たとえば、以下のような設定が可能です。

• パッケージURL（PURL）形式を使用して、ライセンス承認ルールにパッケージ固有の例外を定義
• 通常は制限されているライセンスでも、特定のパッケージ（またはパッケージのバージョン）に限って使用を許可
• 特定のパッケージ（またはパッケージのバージョン）に対し、一般的に許可されているライセンスの使用をブロック

例外を追加するには、ライセンス承認ポリシーの作成または編集時に次のワークフローに従ってください。

1. グループでセキュリティ > ポリシーに移動します。

2. ライセンス承認ポリシーを作成または編集します。

3. ビジュアルエディタで新しいパッケージ例外オプションを見つけるか、YAMLモードで構成します。

4. ライセンスに対して、許可リストまたは拒否リストを選択します。

5. ポリシーに特定のライセンスを追加します。

6. ライセンスごとにPURL形式でパッケージ例外を定義します。

例：pkg:npm/@angular/animation@12.3.1

7. ライセンスルールにこれらのパッケージを含めるか除外するかを指定します。

これらの設定後は、ポリシーが定義された例外を適切に処理しながらライセンスルールを適用するため、組織全体でライセンスコンプライアンスをきめ細かく制御できるようになります。

ドキュメント
エピック

<img src="https://about.gitlab.com/images/18_0/license-exceptions-mr-approval-policy.png">

ユーザー招待機能の無効化

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

グループやプロジェクトにメンバーを招待する機能を制限できるようになりました。

• GitLab.comでは、Enterpriseユーザーを持つグループのオーナーがこの制限を設定でき、設定はトップレベルグループ内のサブグループやプロジェクトに適用されます。この招待制限が設定されると、どのユーザーも新しいメンバーを招待することはできません。
• GitLab Self-Managedの場合、この制限設定は管理者によって行われ、インスタンス全体に適用されます。その後も、管理者は引き続きユーザーを直接招待できます。

この機能は、組織がメンバーシップアクセスを厳格に管理したい場合に便利です。

ドキュメント
イシュー

<img src="https://about.gitlab.com/images/18_0/disable_invitations.png">

ジョブトークンのきめ細かい権限管理がベータ版として登場

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

パイプラインセキュリティがさらに柔軟になりました。ジョブトークンはパイプライン内でリソースにアクセスするための一時的な認証情報です。トークンはこれまで、ユーザーから完全な権限を継承していたため、不必要に広範なアクセスが付与される事態が数多く発生していました。

新しく追加されたジョブトークンのきめ細かい権限ベータ機能により、プロジェクト内でジョブトークンがアクセスできる特定のリソースを正確に制御できるようになりました。これにより、CI/CDワークフローで最小権限の原則を実装し、各ジョブに対してタスクの実行に必要な最小アクセス権のみを設定できるようになります。

この機能について、コミュニティからのフィードバックをぜひお寄せください。ご質問や実装経験の共有、改善点に関して当社チームへのご意見がある場合は、フィードバックイシューをご確認ください。

ドキュメント
エピック

<img src="https://about.gitlab.com/images/18_0/sscs-authz-fine-grained-job-tokens.png">

ユーザーセッション最大長の制限

SaaS: -<br> Self-Managed: Free、Premium、Ultimate

管理者は、ユーザーセッションの最大有効期間を「最初のサインイン」から計算するか、または「最後のアクティビティー」から計算するかを選択できるになりました。ユーザーにはセッションが終了することが通知されますが、セッションの有効期限を変更したり、セッションを延長したりすることはできません。この機能はデフォルトで無効になっています。

この場を借りて、コントリビュートしてくれたJohn Parentさんに感謝します！

ドキュメント
イシュー

SAML証明書のSHA256サポート

SaaS: Premium、Ultimate
Self-Managed: Premium、Ultimate

GitLabは、グループSAML認証におけるSHA1およびSHA256の証明書フィンガープリントを自動的に検出し、サポートするようになりました。これにより、既存のSHA1フィンガープリントとの下位互換性が維持されるほか、より安全なSHA256フィンガープリントのサポートが追加されます。今回のアップグレードは、SHA256をデフォルト設定とする次世代ruby-saml 2.xに対応するための必須の対応となります。

ドキュメント
イシュー

すべてのユーザーが利用できる削除保留機能

SaaS: Free、Premium、Ultimate
Self-Managed: Free、Premium、Ultimate

プロジェクトとグループの削除保留機能が、Freeプランを含むすべてのGitLabユーザーに提供されるようになりました。この重要なセキュリティ機能は、削除されたグループやプロジェクトが完全に削除される前に、猶予期間（GitLab.comでは7日間）を設けるものです。この機能により、誤って削除した場合でも複雑な手順を踏まずに簡単に復元できるようになります。

データ保護を基盤機能として組み込むことで、大切なデータを消失リスクから守ります。

ドキュメント
イシュー
エピック

<img src="https://about.gitlab.com/images/18_0/tenant_scale_deletion_protcection_all_tiers.png">

グループ、プロジェクト、ユーザーAPIのレート制限

SaaS: Free、Premium、Ultimate Self-Managed: -

すべてのユーザーに対してプラットフォームの安定性とパフォーマンスを向上させることを目的として、プロジェクト、グループ、ユーザーごとにAPIレート制限を追加しました。今回の変更は、当社のサービスに影響を与えているAPI通信の増加に対応するものです。

この制限は平均的な使用パターンに基づいて慎重に設定されており、ほとんどのユースケースにおいて十分な容量を提供するよう設計されています。制限を超えると、「429 Too Many Requests」（リクエスト過多）という応答が返されます。

特定のレート制限と実装情報の詳細については、関連のブログ記事をご覧ください。

ドキュメント
イシュー

<br> <br>

実験的な機能

スケジュールされたパイプライン実行ポリシー

この実験的機能を有効にすると、カスタマイズされたCI/CDジョブやスクリプトを使い、定期スケジュールでパイプライン実行ポリシーをトリガーできます。主な特徴は以下のとおりです。

• スケジュールされたパイプラインでは、コンプライアンススクリプト、GitLabまたはサードパーティ製のセキュリティスキャン、その他のカスタムCI/CDジョブを強制実行できます。
• セキュリティおよびコンプライアンス要件を確実に満たすためのツールとして、スケジュールされたパイプラインを実行して日次、週次、月次のスケジュールでジョブを実行することができます。
• スケジュールされたパイプラインは、プロジェクトの.gitlab-ci.ymlファイルにジョブをインジェクトしたり強制したりせず、ダウンストリームのプロジェクトパイプラインに影響を与えません。
• 代わりに、これらのパイプラインを使用して、デフォルトブランチを定期的に対象とし、依存関係やプロジェクト構成、その他の要件を確認するといったアクションを実行できます。

実験を有効にするにはpolicy.ymlファイルを作成するか、セキュリティポリシープロジェクトの既存のpolicy.ymlファイルを変更してexperiments属性を追加します。有効にすると、パイプライン実行ポリシーを設定できるようになります。このポリシーには、パイプライン実行ポリシーが適用されているすべてのプロジェクトでカスタムCI/CDジョブを実行するスケジュールが含まれます。

トリガーされるパイプライン実行ポリシーは複数作成できますが、セキュリティポリシープロジェクトごとに設定できるスケジュールされたパイプライン実行ポリシーは1件のみです。

詳細については、スケジュールされたパイプライン実行ポリシーを参照してください。

<br> <br>

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

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

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

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

<br> <br>

非推奨事項

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

• リソースオーナーパスワード認証方式を非推奨化

• cert-manager Helm チャートをアップデート

• カバレッジガイド付きファズテストを非推奨化

<br> <br>

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

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

• APIディスカバリーはデフォルトでブランチパイプラインを使用するように
• アプリケーションセキュリティテスト（AST）アナライザーのメジャーバージョンをアップデート
• 「今後」および「開始済み」マイルストーンフィルタの動作を変更
• CI/CDジョブトークン - 「認証されたグループとプロジェクト」許可リストの強制適用
• CI/CDジョブトークン - 「プロジェクトからのアクセス制限」設定を削除
• DASTのdast_devtools_api_timeoutのデフォルト値引き下げ
• 依存関係プロキシトークンのスコープ強制
• Terraform CI/CD テンプレートを非推奨化
• ライセンスメタデータ形式 V1 を非推奨化
• GraphQL APIのNamespaceProjectSortEnumにおけるSTORAGE列挙型を非推奨化
• GraphQL APIのProjectMonthlyUsageType におけるnameフィールドを非推奨化
• GitLab NGINXチャートコントローラーイメージv1.3.1のフォールバックサポート
• Gitalyストレージを設定するためのgit_data_dirs
• 従来のWeb IDEを非推奨化
• スキャン実行ポリシーごとに許可されるアクションの数を制限
• スキャン実行ポリシーにおけるscanアクションを制限
• Prometheusサブチャートのメジャーアップデート
• GitLab.comでの脆弱性データ保持期間の新しい制限
• PostgreSQL 14および15はサポートされなくなります
• Raspberry Pi 32 ビットパッケージを非推奨化
• allowed_pull_policies に含まれないコンテナイメージのプルポリシーを拒否
• duoProAssignedUsersCount GraphQL フィールドを削除
• GraphQL フィールドadd_on_purchaseをadd_on_purchasesに置き換え
• ネームスペースのGraphQL フィールドadd_on_purchaseをadd_on_purchasesに置き換え
• SUSE Linux Enterprise Server 15 SP2をサポート
• ciJobTokenScopeRemoveProjectのGraphQL 引数directionを非推奨化
• APIでの注釈の機密性切り替え

変更履歴

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

• GitLab
• GitLab Runner
• VS CodeのGitLabワークフロー
• GitLab CLI

インストール

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

更新事項

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

ご不明な点がある場合

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

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

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

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

<br> <br>

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

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

• 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

すべての開発チームにAIを

人工知能（AI）は今や、デベロッパーエクスペリエンスの中核をなしています。AIは、コードベースの分析、入力中リアルタイムでの提案の提供、プロジェクトのコンテキストに基づいた関数やメソッドの作成、繰り返しの作業の軽減、コードレビューの自動化など、さまざまな方法でコーディングを強化します。

この数年間、当社ではこうした生成AIやエージェント型AIの機能をGitLabプラットフォームに統合するためにGitLab Duoを開発してきました。GitLabが実施したグローバルDevSecOps調査によると、デベロッパーはコード作成以外のタスクに作業時間の79%を費やしています。コード作成はソフトウェアライフサイクルの始まりに過ぎないため、当社ではソフトウェア開発ライフサイクル全体をとおしてAIを統合する戦略を採用してきました。

本リリースではこの戦略をさらに進め、デベロッパーのみなさまが追加料金なしでAIの恩恵を受けられるように、GitLab PremiumおよびUltimateプランにGitLab Duoの基本機能を追加しました。

PremiumとUltimateでChatとコード提案をご利用いただけるようになったことで、すべてのソフトウェアエンジニアが、さまざまなツールやライセンス、そして管理体制を必要とせずに、IDE内でワークフローを高速化できます。既存のPremiumおよびUltimateのお客様は全員、GitLab 18.0へのアップグレード後にすぐにChatとコード提案をご利用いただけるようになります。また、この機能強化は新規のお客様には標準機能として提供されます。

「GitLabはすでに、分散されたツールチェーンへの依存を排除し、これにより連携していないソリューションにかかるコストを削減し、ワークフローを効率化する上で重要な役割を果たしています。GitLab PremiumにGitLab Duoを追加することで、さらなる効率化とコスト削減が期待できます。日常的なコーディング作業にかかる時間が削減されるため、デベロッパーは真のビジネス価値を生み出す複雑な課題に、より多くの時間を費やせるようになります。」

• McKenzie Intelligence Services社、最高技術責任者、Andrei Nita氏

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab Premium with Duo Core"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<br></br>

本リリースから、PremiumおよびUltimateのお客様は、以下のAIネイティブ機能をご利用いただけます。

GitLab Duoコード提案

• コメントから完全な関数やコードブロックを生成
• 入力時にAIによる的確なコード補完を実行
• 20以上のプログラミング言語をサポート
• 主要なIDE各種で利用可能

コード提案機能については、こちらの操作ガイドをご覧ください（ツアーを開始するには以下の画像をクリックしてください）。

<a href="https://gitlab.navattic.com/code-suggestions"><img src="//images.ctfassets.net/r9o86ar0p03f/4nclgZ2JUeQ0hR4wjOS30P/ba948ae1a0dce0cff4469ca06490efb1/Screenshot_2024-08-27_at_9.24.32_AM.png" alt="GitLab Duo Code Suggestions cover image"></a>

詳細については、コード提案のドキュメントでもご確認いただけます。

GitLab Duo Chat

• 馴染みのないコードを分かりやすく解説し、複雑な機能の理解をサポート
• 既存のコードをリファクタリングして品質と保守性を向上
• バグを早期に発見できるように、包括的なテストケースを自動作成
• ワークフロー内でコードの問題を直接修正

詳細については、Duo Chatのドキュメントをご覧ください。

「私たちGitLabユーザーにとって、GitLab Duoのインテリジェントなコード提案は、デベロッパーの日常業務を支える資産となっています。Chat機能と組み合わせることで、即時にフィードバックを得て改善できるため、開発サイクルが加速し、より安全なコードベースが実現できています。ワークフローにシームレスに統合された強力な機能です。」

• Ignite by FORVIA HELLA社、最高技術責任者、Felix Kortmann氏

GitLab Premiumのお客様もGitLab Duo Enterpriseをご利用可能に

多くのお客様からのご要望に応え、GitLab Premiumをご利用のお客様は、GitLab UltimateにアップグレードすることなくAI機能をフル搭載したGitLab Duo Enterpriseをご購入いただけるようになりました。Premiumのお客様は、ソフトウェア開発ライフサイクル全体にシームレスに統合された、充実したAI機能をご活用いただけます。

Duo Enterprise のパワフルな機能ラインナップは次のとおりです。

• GitLab Duo根本原因分析：CI/CDパイプラインの失敗を迅速に解決して、パイプラインを健全に保ちます。
• GitLab Duoコードレビュー：GitLab Duoをコードレビュアーとして活用することで、マージリクエストのレビューを高速化します。
• 高度なチャット：会話の内容を要約し、コード変更を理解できるように支援するほか、複雑な設定のサポートを提供します。
• GitLab Duo Self-Hosted：使用が許可されたAIモデルを社内でホスティングすることで、インターネット未接続（エアギャップ）環境やオフライン環境でもGitLab Duoを活用できます。

GitLab Duo Enterpriseの提供と並行して、今GitLab Premiumの価値向上に向けた投資も強化しています。GitLab 17のリリース以降、以下を含む100件を超える機能や改善を実装してきました。

• CI/CDカタログ：デベロッパーが既存のCI/CDコンポーネントや設定を共有、検索、再利用できる一覧ページ
• アーティファクトレジストリ：デベロッパーにアーティファクトへの安全なアクセスを提供するとともに、CI/CDパイプラインとのシームレスな統合を実現
• リモート開発：デベロッパーがオンデマンドのクラウドベースの開発環境で作業できるように支援する機能

GitLab Premiumの詳細はこちらをご覧ください。

GitLab Duo：組織の現在のステージに対応するAI

GitLabは、ProからEnterpriseまで多彩なDuoサービスをご用意しており、お客様のAI導入段階に最適なソリューションをお選びいただけます。チームのAI活用レベルが高まるにつれて、より多くの機能を活用して、安全なソフトウェアをより迅速にビルド、テスト、デプロイすることができます。

GitLab UltimateおよびPremiumの既存のお客様がGitLab Duoを使い始めるには

GitLab 18.0以降、UltimateとPremiumの既存のお客様は、コード提案とChatがデフォルトではオフになっていますが、以下の手順で簡単に有効にできます。

GitLab PremiumおよびUltimateでGitLab Duoを利用する手順：

1. GitLab PremiumまたはUltimateを利用中であることを確認します。いずれも導入していない場合は、無料トライアルを開始できます。
2. 組織の設定で、GitLab Duoを有効にします。
3. ローカルIDEを使用している場合は、対応するGitLabエディタ拡張機能をインストールします。
4. サポートされているローカルIDEまたはGitLab Web IDEで、コード提案やChatの利用を開始します。

注：新規ユーザーまたはトライアル中の場合、GitLabのAI機能が自動的に有効になります。

AIネイティブ開発にはDevSecOpsプラットフォームが不可欠

今やAIによって、デベロッパーエクスペリエンスは根本から再構築されつつあります。これからの組織では、ソフトウェア開発に携わる人員が単に増えるだけではなく、AIによって本番環境向けコードの量も増えることになります。そのため、GitLabの存在価値がはかつてないほど高まっています。

当社では、この新時代に向け、GitLab Duoを備えたGitLab PremiumおよびUltimateを構築しました。これによりチームは、あらゆるコードを安全に一元管理できる環境を構築できます。組織全体でAIがコードを生成する環境下で、GitLabが司令塔としての役割を担います。セキュリティスキャンやコンプライアンスチェック、パイプライン管理のために別々のツールを導入する必要はありません。組織の成長に合わせてスケールする単一の統合プラットフォームで、各コードが本番環境へのリリース前に基準を満たしているかを確認できます。AIによって開発速度が加速する中、GitLabを使えば全工程を通じて一貫性のあるコントロール、セキュリティ、品質を保てます。

チームの生産性を向上させるGitLab Duoの活用方法については、GitLab Premiumのページをご覧ください。すでにGitLabをご利用の場合は、GitLab担当者にご連絡いただき、デモンストレーションをご予約ください。また、2025年6月24日にGitLab 18バーチャルリリースイベントを開催します。AIとともに進化するソフトウェア開発の未来像を探る機会となりますので、ぜひご参加ください。

本ブログは、Unlocking AI for every GitLab Premium and Ultimate customerの抄訳です。内容に相違がある場合は、原文が優先されます。

5月がやってきて、勢いも加速中！RSACでの学びから、GitLab Duo with Amazon Q の一般提供開始、GitLab 17.11、そしてシーメンス社の素晴らしいカスタマーストーリーまで、今月のMonday Mergeはイノベーションとインサイト、インスピレーションが満載です。

さっそく見ていきましょう！

🗞️ RSAカンファレンス2025 特別レポート

先週のサンフランシスコは、霧とコーヒーだけでなく、サイバーセキュリティの熱気にも包まれていました。RSAカンファレンス2025では業界のトップが集結し、GitLabもブース#4324で参加しました。イベントでは、AIアシスタント、組み込み型セキュリティ、透明性の高いDevSecOpsの実践などを通して、「協業こそがセキュリティの鍵」という明確なメッセージが示されていました。

🤝 GitLab Duo with Amazon Q：ついに一般提供開始、とっても便利です！

新しいAIコンビにご注目を！GitLab Duo with Amazon Qが一般提供となり、AWSでの開発のあり方が大きく変わります。コードを書くとき、マージリクエストのレビュー時、そして古いJavaの更新（リファクタリング戦士たち、ありがとう！）も、AIアシスタントが重荷を引き受けます。

GitLabに組み込まれたAmazon Qを使えば、/q devや/q transformのような直感的なプロンプトで、課題から実装までを数分で完了できます。Volkswagen Digital Solutions社やAvaility社のような早期導入企業は、すでにワークフローの高速化や複雑な環境のモダナイゼーションに活用中です。

🔗 GitLab Duo with Amazon Qの詳細を見る

🔗 アイデアを数分でコードに変える方法（英語）

🚀 GitLab 17.11：コンプライアンス、カスタマイズ、さらなるAIの進化

今月のリリースでは60以上の機能改善があり、セキュリティ管理の強化、柔軟性の向上、AIを使った精密なワークフローの高速化を実現。規制のある環境での運用から、カスタムプロセスの拡張、AIアシスタントの活用まで、GitLab 17.11は必要な管理機能、ダッシュボード、統合機能を提供します。

✨ 主なハイライト

• カスタムコンプライアンスフレームワーク：要件定義、50以上のコントロールとのマッピング、詳細なレポートの生成

• Duo Self-Hosted新機能（ベータ）：根本原因分析、AIによる要約、脆弱性インサイトなど

• Eclipseプラグイン（ベータ）：DuoがEclipseに対応し、さらに統合されたコーディング体験が可能に

• パッケージとタグの保護：重要な資産を万全に保護

• カスタムフィールドとイシュー画面の改善：構造化されたメタデータの追加、タスクの整理、管理効率向上

• CI/CDパイプライン入力：動的なコンテンツを柔軟かつ安全に注入

🎉 さらに、GitLabコミュニティによる284件の貢献に感謝します！Mavenパッケージ保護やDuo、CI/CD改善など、世界中のコントリビューターの創造力と献身が反映されています。みなさんの協力がなくては実現できませんでした 🙌

🔗 17.11のリリースノートを見る

☁️ AWSサミットで直接お会いしましょう！

GitLabはAWSサミットのグローバルスポンサーとして、各地にDevSecOpsを届けます。
ぜひブースにお立ち寄りください：

• ライトニングトークやハンズオンデモ
• GitLabのAI・セキュリティ専門家との対話
• AWS上での開発をより高速・安全に進めるヒント

📍AWS Summit Japan 2025（2025年6月25日、26日）、その他開催地をみる

🏗️ 事例のご紹介：シーメンス社がGitLabで協業をスケール

世界有数のエンジニアリング企業が、開発者の協業の在り方を見直すとどうなるか？ それを体現しているのが、シーメンス社の驚くべきDevSecOpsストーリーです。

2014年、組み込みLinux開発において、より良い協業方法を模索していた小さな先進的チームから全ては始まりました。今では、シーメンス社の75,000人以上の開発者がGitLabを中心となるプラットフォームとして利用し、1日あたり20万件以上のビルドを実施。GitLab導入は単なる技術的な実装にとどまらず、チームをつなげ、インナーソース文化を育み、企業全体のイノベーションを促進しました。

さらに、シーメンス社はGitLabのユーザーであると同時に構築者でもあります。300以上のマージリクエスト、12件のMVP受賞を誇り、プラットフォームの進化にも貢献しながら、自社のDevOps力も強化しています。

現在はAIアシスタントを自社モデルで活用し、マージリクエストを強化する独自の「CodeAI」ボットを導入。AIを“代替”ではなく“創造性と協業の鍵”として未来に備えています。

🔗 シーメンス社のストーリー全文を読む（ドイツ語）

📚 おすすめ読みもの：AI、リスク、そしてGitLabリーダーたちの見解

• AIアシスタント：開発者の可能性をスケールさせる
  Emilio Salvadorが語る、「未来のソフトウェア開発は一人ではできない」理由。専任のAIアシスタントは新しいチームメイトと語ります。

🔗 続きを読む（英語）

• リスクインテリジェンスをソフトウェアサプライチェーンに組み込む
  Lee Fausが、リスク対策を単なる後付けではなく、パイプライン全体に組み込む方法を解説します。

🔗 続きを読む（英語）

• セキュリティ対策を公開するメリットとデメリット
  Josh LemosがTinesで、透明性のあるセキュリティ、AIの脅威、コーヒーチャットの重要性について語ります。

🔗 続きを読む（英語）

• エンジニアリングチームにAIを導入する3つの方法
  Sabrina Farmerが、AIをチームの味方にするステップバイステップガイドを紹介します。

🔗 続きを読む（英語）

• 精密にGo-To-Market戦略を進めるには
  Brian RobinsがGitLabの、市場戦略、「Ultimate」が成長を牽引する理由、そして財務の“人間らしさ”について語ります。

🔗 続きを読む（英語）

💬 本日のインスピレーション

「セキュリティとは、新たな技術的フロンティアへ安全に渡るための架け橋である。」<br>– Magda Chelly

AIアシスタント、コンプライアンス管理、コラボレーションのワークフローなど、新たなフロンティアへ進んでいく中で、セキュリティは単なるチェックポイントではなく、イノベーションを可能にする土台だということを忘れずに。架け橋を丁寧に築き、自信を持って渡り、素晴らしいものを創り出していきましょう。

それでは、次回まで、好奇心を持ち続け、つながりを大切にし、Happy Merging！

Fatima Sarah Khalid | GitLab Developer Advocate

P.S. DevSecOpsの最新情報を逃さないように、ぜひ来月も読んでくださいね！

自律型AIは、高度な言語モデルや自然言語処理を活用して、自律的に行動を起こすタイプの人工知能です。従来の生成AIツールが常に人間からの指示を必要とするのに対し、自律型AIはリクエストを理解し、意思決定を行い、目標達成のために複数ステップにわたる計画を実行できます。複雑なタスクを管理可能なステップに分解し、課題に直面した際には適応学習を通じてアプローチを柔軟に変えることができます。

自律型AIの詳細はこちら

自律型AIに関するインサイト

• 新たに登場し、ソフトウェア開発に変革をもたらす自律型AIのトレンド：自律型AIによって、個別にコーディングを行う開発プロセスを、セキュリティを維持しながら生産性を向上させるインテリジェントなワークフローへとどのように変えられるかを説明します。
• デベロッパーの可能性を大きく解放する自律型AI：自律型AIは、コード補完の枠を超え、複雑なタスクに主体的に挑むパートナーへと進化しつつあり、ソフトウェア開発を大きく変革しようとしています。
• 自律型AI、GitLab Duoセルフホストモデルなど：2025年のAIトレンド：オンプレミスでのモデル展開から、インテリジェントで適応性の高いAIエージェントまで、ソフトウェア開発における主要なAIトレンドをご紹介します。
• 自律型AIによってプラットフォームエンジニアリングの可能性を引き出す方法：自律型AIによって複雑なワークフローを自動化し、標準化を大規模に実施することで、どのようにプラットフォームエンジニアリングをレベルアップできるかを説明します。

自律型AIを導入するためのベストプラクティス

• AIエージェント向けに効果的なガードレールを実装する：コンプライアンス制御やインフラ保護からユーザーアクセス管理まで、DevSecOps環境においてAIエージェント向けに実装すべきセキュリティガードレールをご紹介します。

GitLabが提供する自律型AI機能

GitLab Duo with Amazon Q

• GitLab Duo with Amazon Q（AWS向けに最適化された自律型AI）の一般提供を開始：AIを搭載した包括的なDevSecOpsプラットフォームと業界最高水準のクラウドコンピューティング機能の組み合わせにより、開発サイクルの高速化、自動化の推進、そしてコード品質の向上を可能にします。
• DevSecOps + 自律型AI：AWSインスタンスのGitLab Self-Managed Ultimateで利用可能に：AWSインスタンスのGitLab Self-Managed Ultimateで、DevSecOps向けに強化されたAI搭載エージェントを使い始めましょう。GitLab DuoとAmazon Qの両方のメリットを得られます。
• GitLab Duo with Amazon Qパートナーページ

以下の動画で、GitLab Duo with Amazon Qを実際に使用する様子をご覧いただけます。

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Technical Demo: GitLab Duo with Amazon Q"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

ガイド付きツアー

以下の画像をクリックすると、GitLab Duo with Amazon Qのツアーが開始されます。

GitLab Duo with Amazon Qのチュートリアル

• GitLab Duo + Amazon Q：数分でアイデアをもとにコードを作成：新たに追加されたGitLab Duo with Amazon Qは、イシューの説明文を分析し、完全に動作するコードの自動生成を通じてソリューションを提供することで、開発ワークフローを加速します。

GitLab Duo Workflow

• GitLab Duo Workflow：安全な自律型AIソフトウェア開発の未来
• GitLab Duo Workflow：自律型AIに対するエンタープライズレベルの可視性と管理：安全で自律的かつコンテキスト認識型のAIエージェントに複雑なタスクを任せることで、デベロッパーは革新的なソフトウェアの迅速なリリースに専念できます。現在、限定公開のベータ版のウェイトリスト受付中です。
• GitLab Duo Workflow
• GitLab Duo Workflowのドキュメント

以下の動画では、GitLab Duo Workflowに関する詳細をご紹介しています。

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

ガイド付きツアー

以下の画像をクリックすると、GitLab Duo Workflowのツアーが開始されます。

GitLab Duo Workflowのチュートリアルとユースケース

• GitLab Duo Workflowを使ってJavaScriptコードをTypeScriptにリファクタリングする

• 面倒なコーディング作業をGitLab Duo Workflowで自動化：自律型AIを導入すると、これまで繰り返しの作業に費やしていた時間が削減されるため、革新的なソリューションの開発や次の重要な製品のリリースに注力できるようになります。

• GitLab Duo Workflowを活用してアプリケーションの品質保証を向上：自律型AIを使用してJavaアプリケーションに単体テストを追加する方法をステップ別にご説明します（チュートリアル動画を含む）。

• GitLab Duo Workflowを使って複雑な課題を解決：GitLabカスタマーサクセスマネジメントチームが、パッケージレジストリにおけるHelmチャートの制限への対処など、実際の問題解決においてどのように自律型AIを活用しているかをご紹介します。

GitLab Universityでさらに詳しく学ぶ

• GitLab Duo入門コース
• GitLab Duo Enterpriseを体系的に学ぶコース

その他のAI関連リソース

• 2024年グローバルDevSecOps調査：DevSecOpsにおけるAI導入のトレンドと進化
• DevOpsにおけるAIの役割
• GitLabによるAIと機械学習関連の最新記事
• GitLab Duo

GitLabのカスタムコンプライアンスフレームワークとは？

GitLabのカスタムコンプライアンスフレームワークを使うと、組織は自社のGitLabインスタンス内で、コンプライアンス基準を定義・実装・適用できます。この機能により、GitLabに元々備わっているコンプライアンス機能を拡張し、特定の規制要件や社内ポリシー、業界標準に合わせたカスタマイズ可能なフレームワークを作成できるようになります。

カスタムコンプライアンスフレームワークには、次のようなメリットがあります。

• 手動での追跡作業にかかる手間を削減
• 監査対応の準備を加速
• コンプライアンス制御をGitLab上でネイティブに適用

今回のリリースでは、50個を超えるすぐに使える（OOTB）コントロールが提供されており（今後さらに追加予定）、医療分野のHIPAA、データプライバシーに関するGDPR（EU一般データ保護規則）、サービス組織向けのシステムおよび組織管理（SOC）2、その他業界固有の規制など、組織ごとのコンプライアンスのニーズに合わせて調整できます。OOTBコントロールの一例は以下のとおりです。

• 職務分離（SoD、例：最低2名の承認者が必要、作成者によるマージリクエストの承認）
• セキュリティスキャナの実行（例：SASTの実行、依存関係スキャンの実行）
• 認証/認可（例：プロジェクトの公開設定が非公開、AuthSSOが必須）
• アプリケーション構成（例：ステータスチェックが必須、Terraformが必須）

さらに、GitLab APIを使用して外部環境のコントロールを構成することもでき、外部環境のステータスや詳細を確認できます。

ゼロからカスタムコンプライアンスフレームワークを作成する

その価値を理解できたところで、次はGitLab環境でカスタムコンプライアンスフレームワークを実装する方法を見ていきましょう。デモアプリケーションを使って説明しますので、動画を見ながら一緒に進めてください。

注： GitLab Ultimateのサブスクリプションが必要です。

<!-- TODO: EMBED_YT_VIDEO -->

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB" title="Adhering to compliance requirements with built-in compliance controls " frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

ステップ1：コンプライアンス要件を定義する

カスタムフレームワークを構築する前に、まずはコンプライアンス要件を明確に定義する必要があります。

1. 適用される規制を特定する： 自社に適用される規制や標準（例：GDPR、PCI DSS、HIPAA）を確認します。
2. 各要件に対応するコントロールを割り当てる： 各規制を、具体的で実行可能なコントロールとして整理します。
3. 要件に優先順位を付ける： リスクの高い領域や、影響の大きい要件を優先します。

ステップ2：カスタムコンプライアンスフレームワークを作成する

以下の手順でカスタムコンプライアンスフレームワークを作成できます。

1. GitLabグループのセキュア > コンプライアンスセンターセクションに移動します。
2. 新しいフレームワークボタンを押します。
3. 空のフレームワークを作成を選択します。

4. フレームワークの名前、説明、色を設定します。

5. フレームワークに要件を追加します： a. ページを下にスクロールして要件タブを開きます。

   b. 新しい要件ボタンをクリックします。

   c. 名前と説明を入力します。 d. コントロールセクションでGitLab コントロールを選択をクリックします。
   e. 一覧からコントロールを選択します（例：少なくとも 2 つの承認、SAST の実行など）。 f. 要求事項を作成ボタンをクリックします。


6. フレームワークを作成ボタンをクリックします。

指定した内容でフレームワークが作成され、プロジェクトに追加できるようになります。また、適切なスキーマに準拠したJSONを使用して、コンプライアンスフレームワークをインポートすることも可能です。

ステップ3：プロジェクトにフレームワークを適用する

フレームワークを作成したら、以下の手順に従います。

1. コンプライアンスセンターからプロジェクトタブを選択します。
2. 検索バーを使って対象のプロジェクトを検索または絞り込みます。
3. フレームワークを適用するプロジェクトを選択します。
4. 一括操作を選択ボタンをクリックします。
5. 選択したプロジェクトにフレームワークを適用するを選択します。
6. フレームワークを選択ボタンをクリックします。
7. 一覧から適用するフレームワークを選択します。
8. 適用ボタンをクリックします。

適用されたフレームワークは、プロジェクト内で要求事項として可視化され、追跡できるようになります。

ステップ4：コンプライアンスの状況をモニタリング・報告する

フレームワークを設定したら、以下のことができるようになります。

1. コンプライアンスセンターを使って、プロジェクト全体のコンプライアンス状況を管理する。不合格となったコントロールの詳細や、推奨される修正方法も確認できます。
2. 監査や関係者によるレビューへ向けた、コンプライアンスレポートを生成する。
3. コンプライアンスに関するアラートを設定し、潜在的な問題を関係者へ通知する。
4. 監査イベントで、コンプライアンス設定に対して行われた操作の概要を確認する。

実例：SOC2 コンプライアンスフレームワークの実装

システムおよび組織管理（SOC）2、通称SOC2は、米国公認会計士協会（AICPA）によって策定された、厳格な監査基準です。SOC2は、サービス組織のセキュリティ、可用性、処理の完全性、機密性、プライバシーに関するコントロールを評価します。詳細については、GitLabでSOC 2のセキュリティ要件を満たすためのガイドをご覧ください。

それでは、カスタムコンプライアンスフレームワークを使って SOC2 のセキュリティコンプライアンスを検証する実践的な例を見てみましょう。SOC2 のセキュリティ基準には以下が求められます。

• 不正アクセスを防ぐためのコントロールの導入
• リスクを特定し、軽減するための手順の確立
• セキュリティインシデントの検出および対応のためのシステムの構築

免責事項： これはSOC2の要件に準拠するために利用可能な一部のコントロールを紹介する例です。本番環境に導入する前に、必ずセキュリティ/コンプライアンスチームと相談してください。

GitLabのOOTB（すぐに使える）コントロールを活用したSOC2用カスタムコンプライアンスフレームワークの例：

• 名前： SOC2セキュリティ要件
• 説明： SOC2フレームワークに準拠するためのセキュリティ要件を追加します
• 要件：
  • 不正アクセスを防ぐためのコントロールの導入
    • Auth SSOを有効化
    • CI/CDジョブトークンのスコープを有効化
    • 組織レベルでMFA（多要素認証）を必須化
  • リスクを特定し、軽減するための手順の確立
    • 少なくとも2つの承認
    • 作成者によるマージリクエストの承認
    • コミッターによるマージリクエストの承認
    • デフォルトブランチの保護
  • セキュリティインシデントの検出および対応のためのシステムの構築
    • 依存関係スキャンの実行
    • SASTの実行
    • DASTの実行

このフレームワークをプロジェクトに適用することで、コンプライアンスが崩れたタイミングや、再度準拠するために必要な対策を把握できるようになります。なお、1つのプロジェクトに対して複数のコンプライアンスフレームワークを作成・適用することも可能です。たとえば、SOC2のプロセス整合性要件専用のフレームワークを別途設けることもできます。

コンプライアンス要件を満たすためにセキュリティポリシーを実装する

必須ではありませんが、カスタムコンプライアンスフレームワークを含むプロジェクトにセキュリティポリシーを適用することができます。これにより、特定のコンプライアンス基準がセキュリティポリシーによって強制されることを保証できます。たとえば、セキュリティスキャンを求めるカスタムコンプライアンスフレームワークが適用されたプロジェクトに対して、セキュリティスキャナーの実行を強制できます。

GitLab では、以下のようなさまざまなセキュリティポリシーが提供されています。

• スキャン実行ポリシー：パイプラインの一部または指定されたスケジュールでセキュリティスキャンを実行します。
• マージリクエスト承認ポリシー：スキャン結果に基づいて、プロジェクトレベルの設定や承認ルールを強制します。
• パイプライン実行ポリシー：プロジェクトのパイプラインにおけるCI/CDジョブの実行を強制します。
• 脆弱性管理ポリシー：デフォルトブランチで検出されなくなった脆弱性を自動的に解決します。

ここでは、SASTスキャナーを実行することで、SASTスキャンを要求する要件への準拠を自動的に行う方法を紹介します。特定のフレームワークが適用されたプロジェクトに対してセキュリティポリシーを作成・適用するには、次の手順に従います。

1. SAST スキャンが求められるカスタムコンプライアンスフレームワークが適用されているプロジェクトに移動します。
2. サイドバーで、セキュア > ポリシーの順に選択します。
3. 新しいポリシーボタンをクリックします。
4. スキャン実行ポリシーで、ポリシーを選択ボタンをクリックします。
5. 名前と説明を入力します。
6. アクションで、実行するスキャンとしてSASTを選択します。

7. 条件で、すべてのブランチでパイプラインが実行されたときにトリガーされるように設定します。

8. マージリクエスト経由で設定 ボタンをクリックします。
9. この時点で、すべてのセキュリティポリシーが含まれた別プロジェクトでマージリクエスト（MR）が作成されます。
10. マージボタンをクリックします。

これで、すべてのブランチでSASTが実行されるようになり、その領域におけるコンプライアンスが保証されます。他にもさまざまな種類のセキュリティポリシーがありますので、要件に合うものを探してみてください。

5つのベストプラクティス

カスタムコンプライアンスフレームワークを最大限に活用するために、以下のベストプラクティスに従いましょう。

1. 小さく始める： まずは、重要な規制や標準のうち1つから着手し、そこから範囲を広げていきましょう。
2. 関係者を巻き込む： フレームワークの作成には、コンプライアンスチーム、セキュリティチーム、デベロッパーチームを含めることが重要です。
3. 可能な限り自動化する： GitLab CI/CDを活用して、コンプライアンスチェックの自動化を図りましょう。
4. しっかりと文書化する： フレームワークがどのように規制要件に対応しているか、明確に文書化しておきましょう。
5. 定期的に見直す： 規制の変更や新たな要件の発生に応じて、フレームワークを更新するようにしましょう。

無料トライアルで今すぐスタート！

GitLabのカスタムコンプライアンスフレームワークは、コンプライアンスを開発ワークフローに直接組み込むことで、DevSecOpsにおける大きな進化をもたらします。カスタムフレームワークを導入することで、コンプライアンス業務の負担を軽減し、リスク管理を強化しながら、規制要件を満たしたまま開発サイクルを加速させることが可能になります。

カスタムコンプライアンスフレームワークを定義・適用できる機能により、チームは自社特有の規制状況に対応する柔軟性を得られる一方で、組織全体のコンプライアンスの慣習を一貫させるために必要な構造も得られます。

今後さらに規制要件が複雑化していく中で、カスタムコンプライアンスフレームワークのようなツールを活用して、コンプライアンスと開発速度のバランスを持続的に両立させることが、ますます重要になるでしょう。

今すぐカスタムコンプライアンスフレームワークをお試しになりたい場合は、GitLab Ultimateの60日間無料トライアルにぜひお申し込みください。

関連リンク

以下のリソースで、カスタムコンプライアンスフレームワークの詳細や、そのメリットについてご覧いただけます。

• カスタムコンプライアンスフレームワークのドキュメント
• カスタムコンプライアンスフレームワークに関するエピック
• セキュリティポリシーに関するドキュメント
• GitLabのセキュリティおよびコンプライアンスソリューション

ここで力を発揮するのが、自律型AI機能です。 GitLab Duo with Amazon Qは、AIを搭載した包括的なDevSecOpsプラットフォームと、クラウドコンピューティングにおける豊富な機能を組み合わせたもので、アプリケーション開発のプロセスを、慣れ親しんだGitLabのワークフロー内で大幅に加速できるよう設計されています。この強力なインテグレーションはアイデア段階からデプロイまでの流れを効率化し、イシューの説明だけをもとに実装案を提案します。これまで数日かかっていた作業が、数分で完了するようになります。

イシューが動作するコードへ変わる仕組み

この自律型AI機能が実際にどう動くのか、流れを見てみましょう。あなたはデベロッパーとして、住宅ローン計算機アプリを作成するタスクを任されたとします。GitLab Duo with Amazon Qを使用して、以下の手順で作業を進めます。

1. **詳細な要件を記載したイシューを作成する：**まず、通常のGitLabイシューを作成します。説明には、サービスが満たす必要がある要件をできるだけ詳細に記載します。これがソリューションの設計図となります。

2. クイックアクションでAmazon Qを呼び出す： イシューを作成したら、コメント欄に「/q dev」というクイックアクションを追加するだけで、Amazon Qを呼び出すことができます。ここからがマジックの始まりです。

3. **AIが実装を生成する：**GitLab Duo with Amazon Qは、作成したイシューの説明文とソースコードのコンテキストを分析し、指定されたすべての要件を満たすコードを自律的に生成します。 さらに、生成されたコードはマージリクエストとして自動的にコミットされ、すぐにレビュー可能な状態になります。

4. **生成されたアプリケーションをレビューする：**マージリクエストに移動して、生成されたコードをレビューします。 すべての要件が満たされていることを確認し、必要に応じて調整を行います。

5. **提案されたアプリケーションをテストする：**最後に、アプリケーションが正常に動作することを確認します。 最小限の労力で、元の要件を実装した、動作するコードが完成します。

開発プロセスを変革

GitLab Duo with Amazon Qは、インテリジェントな自動化によって複雑なデベロッパータスクにかかる時間を大幅に短縮し、このプロセス全体を根本から変革します。自律型AIアプローチを活用することで、アイデア段階からデプロイまでのプロセスを加速し、開発チームはより戦略的な業務に集中できるようになります。

GitLab DuoとAmazon Qを使用すれば、手動でコードを書く負担を減らしながら、より迅速かつ効率的にソフトウェアを開発できます。このインテグレーションによって、以下のようなメリットが得られます。

• 要件に基づく自動実装で、貴重な開発時間を節約
• どのプロジェクトでも、コード生成の一貫性を維持
• 要件を動作するコードに変換する際の認知負荷を軽減
• 実装上のボトルネックを排除し、リリースサイクルを加速
• ボイラープレートコードの記述ではなく、レビューや最適化に専門知識を活用

GitLab Duo with Amazon Qの動作を実際にご覧になりますか？デモ動画で、開発ワークフローを変革する方法をご覧ください。

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/jxxzNst3jpo?si=j_LQdZhUnwqoQEst" title="GitLab Duo with Amazon Q demo video for dev workflow" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line ->

GitLab Duo with Amazon Qの詳細については、お近くで開催されるAWSサミットにご参加いただくか、GitLab担当者にお問い合わせください。

GitLab Duo with Amazon Q関連リソース

• GitLab Duo with Amazon Q（AWS向けに最適化された自律型AI）の一般提供を開始
• GitLabとAWSのパートナーページ
• GitLab Duo with Amazon Qに関するドキュメント

1. Kubernetesとは？その読み方と用途
2. Kubernetes（K8s）の基本用語解説

• コンテナ、Pod、Node、クラスター
• Dockerとの違い

3. Kubernetesの主な特徴

• デプロイの自動化
• ハイブリッド / マルチクラウドに対応
• 拡張性とプラグインアーキテクチャ
• ローリングアップデートとロールバック
• 柔軟なスケーラビリティ
• リリース後のアプリケーション監視

4. Kubernetesの利点とは

• 生産性の向上
• 自己修復機能により障害に耐性
• 高い可用性を担保
• オンプレミスでも、クラウドでも運用可能
• 大量のコンテナを一括管理
• DevSecOpsとの親和性が高い
• クラウドネイティブなワークロードを安全に保つ

5. GitLabでKubernetesを統合する
6. Kubernetes（K8s）のよくある質問

• KubernetesとDockerの違いは何ですか？
• Kubernetesで何ができますか？
• Kubernetesコンテナとは何ですか？
• Kubernetesの読み方は？

Kubernetesとは？その読み方と用途

Kubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と発音します。ギリシャ語のκυβερνήτηςに由来し、「統治者」や「パイロット」といった意味を持ちます。また、K8sと表記されることもあります。

Kubernetesは、一言で表せばソフトウェア開発においてコンテナを操作・管理するもので、コンテナオーケストレーションの役割を果たすオープンソースソフトウェアとして開発されました。Kubernetesは、クラウドネイティブのプログラムの開発に使用します。これを使用することでマイクロサービスアーキテクチャが可能になり、プログラムの開発が高速化できます。
では、Kubernetesについて、もう少し掘り下げて見ていきましょう。

Kubernetes（K8s）の基本用語解説

コンテナ、Pod、Node、クラスター

Kubernetesは、コンテナをオーケストレーションするためのツールです。オーケストレーションとは、複数のコンピュータシステムやアプリケーション、サービスなどを調整して管理し、頻繁に繰り返される大規模なワークフローやプロセスを実行できるようにすることを指します。では、コンテナとは何でしょう。ソフトウェア開発におけるコンテナ化とは、ソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することを意味します。コンテナは、完全に機能するポータブルなコンピューティング環境です。また、このコンテナを複数まとめたものがPod、PodをまとめたものがNode、Nodeをまとめたものがクラスタと呼ばれます（以下の図を参照）。

Kubernetesにおけるコンテナとクラスタの関係を示した図

Dockerとの違い

Kuberunetesはコンテナオーケストレーションツールですが、Dockerはコンテナ化ツールの1つです。Dockerはアプリケーションのコンテナ化を行なうとき使用するプラットフォームです。仮想マシンよりも軽量で高速であることや、環境構築が簡単なことから、コンテナ化の主流ツールになっています。

Kubernetesの主な特徴

Kubernetesは、前述したようにコンテナを管理するコンテナオーケストレーションツールで、代表的な機能としては次のようなものが挙げられます。

デプロイの自動化

Kubernetesは、アプリケーションのデプロイ時に、新しいコンテナの作成や既存コンテナの削除を自動で実施します。また、新しく作成したコンテナにも自動でリソースを適用します。

ハイブリッド / マルチクラウドに対応

クラウドプロバイダーに依存することなく、オンプレミス環境や様々なクラウドサービス（AWS、Azureなど）上で動作します。よって、ハイブリッドクラウドやマルチクラウド環境を簡単に構築、管理することができます。

拡張性とプラグインアーキテクチャ

多様なプラグインや拡張機能が利用できます。例えば、CustomResourceDefinitions（CRD）を使って新規にリソースタイプやロジックを追加したり、CNI（Container Network Interface）やCSI（Container Storage Interface）といったプラグインでネットワークやストレージのカスタマイズが可能です。

ローリングアップデートとロールバック

Kubernetesでは、アプリケーションのバージョンを更新する際、ローリングアップデートがそのデフォルトとなります。また、ビルトインでロールバック機構もあります。このため、ライブトラフィックに影響を与えず、ダウンタイムゼロでデプロイを実現できます。

柔軟なスケーラビリティ

Kubernetesは、大量のコンテナを効率的に管理するためのもので、システムのスケーラビリティが向上できます。スケーラビリティとは、どのくらいシステムの拡張ができるかを示す特性で、Kubernetesではコンテナ化されたアプリケーションの数を増減することでスケーリングします。

リリース後のアプリケーション監視

PrometheusやGrafanaといった監視ツールを使用することで、アプリケーション固有のメトリクスが監視できます。リリース後のパフォーマンス低下や不具合発見といった事象がアラートされるため、問題に迅速に対処できます。

Kubernetesの利点とは

Kubernetesには次のような7つのメリットがあります。

生産性の向上

一つ目のメリットは、アプリケーション開発で生産性が向上できる点にあります。従来の仮想化では、アプリケーションごとにゲストOSを用意する必要がありましたが、Kubernetesでは、アプリケーションを直接コンテナエンジン上にデプロイできるため、サーバーのリソース使用量が抑えられます。

自己修復機能により障害に耐性

Kubernetesには、PodやNodeに障害が起きた場合、最初の定義（マニフェスト）の状態まで自動修復する機能が備わっています。

高い可用性を担保

Kubernetesは、複数のNodeの集まりであるクラスターを構成します。あるクラスターで障害が発生した場合、障害が起きたコンテナを自動で再起動させます。また、他のNodeでコンテナを起動させ、処理を引き継ぐ動作も継続できるため、高い可用性が担保できます。

オンプレミスでも、クラウドでも運用可能

Kubernetesは、オンプレミスでも、プライベートクラウド、パブリッククラウドでも利用できます。つまり、自社サーバーでも、クラウドを使っても、どんな環境でも運用可能です。

大量のコンテナの一括管理

Kubernetesでは、大量のコンテナが一括で管理・運用できます。また、設定ファイルを複数のコンテナ間で共有することによって、設定変更時も正確かつ大量に設定を反映させることが可能です。

DevSecOpsとの親和性が高い

DevSecOpsとは、開発と運用を統合するDevOpsにセキュリティを加え、運用を視野に入れながら開発とセキュリティを同時に進め、安心・安全なソフトウェアを迅速にリリースするというコンセプトです。Kubernetesにはアプリケーションの開発と運用の双方に必要とされる機能が多く搭載されているため、DevSecOpsとの親和性が非常に高いという特長があります。

クラウドネイティブなワークロードを安全に保つ

Kubernetesは、クラウドネイティブアーキテクチャに基づいており、クラウドネイティブな情報セキュリティに関するベストプラクティスについて、CNCF（Cloud Native Computing Foundation）からのアドバイスを活用しています。

たとえばKubernetesには、APIやセキュリティコントロールが含まれており、情報セキュリティを管理するポリシーを定義する手段も備わっています。クラウドの利用などでセキュリティ面において懸念が生じても、Kubernetesならユーザーごとにアクセス制限を設定でき、不正アクセスが防止できるため安心です。

また、Pod Security Standardによりセキュリティに3つのポリシーが定義されています。非常に緩いものから非常に厳しいものまで累積的に定義できます。

GitLabでKubernetesを統合する

KubernetesクラスターとGitLabを接続すると、アプリの開発・デプロイ・管理・監視ができます。
GitLabをKubernetesと連携させる、またはKubernetes内で動作させるには、3つの異なる方法があります。単独で使用することも、組み合わせて使用することもできます。

• GitLabからKubernetesにソフトウェアをデプロイする
• Kubernetesを使用してGitLabインスタンスに紐づいたRunnerを管理する
• GitLabのアプリケーションとサービスをKubernetesクラスター上で実行する

さらに詳しい情報やお問い合わせはこちらをご覧ください。

Kubernetes （K8s）のよくある質問

KubernetesとDockerの違いは何ですか？

Dockerはコンテナ化ツールのひとつで、アプリケーションコンテナを構築し、アプリケーションの開発・配布・実行をします。Kubernetesは、より大規模に複数のマイクロサービスを管理するのに使われます。
また、Kubernetesはクラスターで実行され、Dockerはノードで実行されます。Kubernetesの使用目的はコンテナ管理ですが、Dockerの使用目的の一つは、アプリケーションをコンテナに分離することになります。

Kubernetesで何ができますか？

Kubernetesでできることの代表例には下記のようなものが挙げられます。

• 大量のコンテナの一括管理
• 起動を含めた動作の高速化・軽量化
• 自動デプロイ
• 自己修復機能により障害に耐性
• 高い可用性を担保
• オンプレミスでも、クラウドでも運用可能
• DevSecOpsとの親和性が高い
• クラウドネイティブなワークロードを安全に保つ

Kubernetesコンテナとは何ですか？

ソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することをコンテナ化と言います。Kubernetesコンテナは、完全に機能するポータブルなコンピューティング環境で、さまざまなプラットフォームでデプロイ可能なプログラムとしてマイクロサービスアーキテクチャを可能にします（リンクは英語版です）。

Kubernetesの読み方は？

Kubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と読み、「K8s（ケーエイツ）」と略されます。

CI/CDとは

• **継続的インテグレーション（CI）**は、デベロッパーがコード変更を頻繁に（1日に数回が理想とされる）共有リポジトリに統合する開発手法です。各統合は自動化されたビルドとテストのプロセスによって検証されるため、早い段階で問題を検出できます。
• **継続的デリバリー（CD）**はCIを拡張した開発手法で、リリースパイプラインを自動化することで、コードを常にデプロイ可能な状態に保ちます。アプリケーションをさまざまな環境（stagingステージ、本番環境など）に自動的に、またはワンクリックでデプロイできます。
• 継続的デプロイはさらにもう一歩踏み込み、本番環境に成功したビルドをすべてデプロイする手法です。継続的デプロイは、自動化されたテストとデプロイのプロセスに十分な信頼性がある場合にのみ、有効です。

GitLab CI/CDが選ばれる理由

GitLab CI/CDは、GitLabに組み込まれた強力な統合システムです。これを利用することで、ソフトウェア開発ライフサイクル全体をシームレスに自動化できます。GitLab CI/CDによって、以下のことを実現できます。

• あらゆるプロセスの自動化：アプリケーションのビルド、テスト、デプロイを簡単に行えます。
• バグの早期発見：問題が本番環境に到達する前に検出し、修正できます。
• フィードバックループの高速化：コード変更に関するフィードバックを即座に受け取れます。
• コラボレーションの向上：自動化されたワークフローによって、より効果的に共同作業を行えます。
• デリバリーの高速化：ソフトウェアをより迅速かつ頻繁にリリースできます。
• リスクの低減：デプロイ時のエラーやロールバックを最小限に抑えられます。

GitLab CI/CDの構成要素

• .gitlab-ci.yml：プロジェクトのルートディレクトリにあるYAMLファイルです。ステージやジョブ、Runnerなど、CI/CDパイプラインの構成を定義します。
• GitLab Runner：任意のインフラストラクチャ（物理マシン、仮想マシン、Dockerコンテナ、Kubernetesクラスターなど）上でCI/CDジョブを実行するエージェントです。
• ステージ：ジョブ（ビルド、テスト、デプロイなど）の実行順序を定義します。
• ジョブ：ステージ内の個々の作業単位（コードのコンパイル、テストの実行、stagingステージへのデプロイなど）を指します。

GitLab CIの設定

GitLab CIは簡単に使い始められます。以下は.gitlab-ci.ymlファイルの基本的な設定例です。

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "アプリケーションをビルド中..."

test_job:
  stage: test
  script:
    - echo "テストを実行中..."

deploy_job:
  stage: deploy
  script:
    - echo "本番環境へデプロイ中..."
  environment:
    name: production

この設定では、「build」「test」「deploy」の3つのステージを定義しています。それぞれのステージには、単純なスクリプトを実行するジョブが含まれています。

CI/CDの設定例

次に、より実践的な例をいくつか見てみましょう。

Node.jsアプリケーションのビルドとデプロイ

以下のパイプライン定義では、npmを使用してNode.jsアプリケーションのビルドおよびテストを行い、dplを用いてアプリケーションをHerokuにデプロイする方法を説明しています。パイプラインのdeployステージでは、GitLab CI/CD変数を使用しています。デベロッパーは機密情報（認証情報など）をこの変数に格納して、CI/CDプロセスで安全に使用できます。この例では、Herokuにデプロイする際にdplツールが使用するAPIキーが、$HEROKU_API_KEYという名前の変数キーに格納されます。

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:latest
  script:
    - npm install
    - npm run build

test:
  stage: test
  image: node:latest
  script:
    - npm run test

deploy:
  stage: deploy
  image: ruby:latest
  script:
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY

異なる環境へのデプロイ（stagingステージや本番環境）

GitLabではさらに、CI/CDを使用した環境という機能もご用意しています。この機能を使用すると、CI/CDから対象のインフラストラクチャへのデプロイを追跡できます。以下の例では、パイプラインにおいてstagingステージと本番環境の環境プロパティを持つステージが追加されます。deploy_stagingステージでは必ず指定したスクリプトが実行される一方、deploy_productionステージでは手動による承認が必要となります。これは誤って本番環境へのデプロイが行われるのを防ぐためです。

stages:
  - build
  - test
  - deploy_staging
  - deploy_production

build:
  # ...

test:
  # ...

deploy_staging:
  stage: deploy_staging
  script:
    - echo "stagingステージへのデプロイ中..."
  environment:
    name: staging

deploy_production:
  stage: deploy_production
  script:
    - echo "本番環境へのデプロイ中..."
  environment:
    name: production
  when: manual  # 手動による承認が必要

GitLab Auto DevOps

GitLab Auto DevOpsは、アプリケーションを自動的にビルド、テスト、デプロイするためのあらかじめ定義された設定を提供することで、CI/CDを簡素化します。ベストプラクティスと業界標準に基づいてワークフローを効率化する仕組みです。

Auto DevOpsを有効にする方法：

1. プロジェクトの設定 > CI/CD > 一般パイプラインの順にアクセスします。
2. Auto DevOpsオプションを有効にします。

Auto DevOpsを有効にすると、プロジェクトの言語とフレームワークが自動的に検出され、必要なビルド、テスト、デプロイのステージが設定されます。そのため、.gitlab-ci.ymlファイルを作成する必要すらありません。

CI/CDカタログ

CI/CDカタログには、CI/CDワークフローを拡張するために使用可能な、公開済みのCI/CDコンポーネントをまとめたプロジェクトが一覧で記載されています。誰でもコンポーネント用のプロジェクトを作成してCI/CDカタログに追加したり、既存プロジェクトへのコントリビュートを通じて公開コンポーネントを改善したりできます。これらのコンポーネントは、GitLab.comのCI/CDカタログに掲載されています。

チュートリアル：初めてのGitLab CI/CDコンポーネントの設定方法

CIテンプレート

さらに、独自のCIテンプレートを作成して、複数のプロジェクトに対するCI/CDの設定を標準化し、再利用することもできます。これにより、一貫性が高まり、重複が生じにくくなります。

CIテンプレートの作成方法：

1. 専用のプロジェクトまたはリポジトリに.gitlab-ci.ymlファイルを作成します。
2. テンプレートでCI/CD設定を定義します。
3. プロジェクトの.gitlab-ci.ymlファイルで、includeキーワードを使用してテンプレートをインクルードします。

開発ワークフローをレベルアップ

GitLab CI/CDは、開発ワークフローに変革をもたらせる強力なツールです。CI/CDの概念を理解して、パイプラインを設定し、Auto DevOpsやCI/CDカタログ、CIテンプレートなどの機能を活用すれば、ソフトウェア開発ライフサイクル全体を自動化し、高品質なソフトウェアをより迅速かつ効率的に提供できます。

さらに詳しく知りたい場合は、GitLab Universityのコースに登録するか、GitLab Ultimateの60日間無料トライアルを今すぐお試しください。

「GitLab入門」シリーズ

「GitLab入門」シリーズのその他の記事もぜひご覧ください。

• ユーザーの管理方法
• GitLabへのプロジェクトのインポート方法
• プロジェクト管理を極める
• gitlab-triage gemを使ったアジャイルワークフローの自動化

デプロイスケジュール

GitLab.com

GitLab.comでは破壊的な変更が以下の3つの期間にのみデプロイされる予定です。

• 2025年4月21～23日
• 2025年4月28～30日
• 2025年5月5～7日

その他にも多くの変更が、今月いっぱい実装される予定です。各期間中にデプロイされる影響度の高い変更については、こちらの破壊的な変更に関するドキュメントで詳細をご覧いただけます。

注：例外的な状況が生じた場合は、破壊的な変更が上記の期間をわずかに前後する可能性があります。

GitLab Self-Managed

GitLab 18.0は5月15日から提供開始されます。リリーススケジュールの詳細については、こちらをご覧ください。

GitLab Dedicated

GitLab 18.0へのアップグレードは、2025年6月24日から29日までのメンテナンス期間中に行われます。詳細およびご自身の地域のメンテナンス期間については、こちらをご覧ください。

また、18.0へのアップグレードに先立ち、導入される変更点がお客様の環境に及ぼす影響を評価し、必要な対応を計画する上で役立つカスタムツールとリソースをご用意しました。影響を緩和するためのツールとリソースに関する情報はこちらでご確認いただけます。

18.0で削除される予定の全項目の一覧については、非推奨機能のページをご覧ください。今後の予定に加え、デプロイ方法に基づき今年予定されているリリースに向け準備する方法については、本ページでご紹介していますのでぜひ最後までお読みください。

破壊的な変更

影響度：高

1. CI/CDジョブトークン - 「プロジェクトからのアクセスを制限」設定の削除

GitLab.com | Self-Managed | Dedicated

GitLab 14.4ではセキュリティ強化の目的で、プロジェクトのCI/CDジョブトークン（CI_JOB_TOKEN）からのアクセスを制限する設定を追加しました。この設定は当初、CI_JOB_TOKENアクセスを制限という名前でしたが、よりわかりやすくするために、GitLab 16.3でこのプロジェクトからのアクセスを制限という名称に変更されました。

GitLab 15.9では、**認証されたグループとプロジェクト**という別の設定を新たに追加しました。この設定は、許可リストを使用してプロジェクトへのジョブトークンでのアクセスを制御します。新たに追加されたこの設定は、元の設定よりも大幅に改善されています。最初のイテレーションはGitLab 16.0で非推奨となっており、GitLab 18.0で削除される予定です。

すべての新規プロジェクトでは、このプロジェクトからのアクセスを制限設定はデフォルトで無効になります。GitLab 16.0以降のバージョンでは、この設定が無効になったプロジェクトで再度有効にすることはできません。代わりに、認証されたグループとプロジェクト設定を使用して、プロジェクトへのジョブトークンでのアクセスを制御してください。

• 非推奨通知
• GitLab Detectiveによる検証を実施可能

2. CI/CDジョブトークン - 認証されたグループとプロジェクトの許可リストの強制適用

GitLab.com | Self-Managed | Dedicated

GitLab 15.9で**認証されたグループとプロジェクトの設定（GitLab 16.3でこのプロジェクトへのアクセスを制限**に名称が変更）が導入されたことで、プロジェクトへのCI/CDジョブトークンでのアクセスを管理できるようになりました。このプロジェクトと許可リストに含まれるすべてのグループおよびプロジェクトのみに設定されている場合、許可リストに追加されたグループまたはプロジェクトのみがジョブトークンを使用してプロジェクトにアクセスできます。

• GitLab 15.9より前のバージョンでは、デフォルトでは許可リストは無効になっており（すべてのグループとプロジェクトアクセス設定が選択されていた）、どのプロジェクトからもジョブトークンでアクセスできるようになっていました。
• GitLab 17.6以降のバージョンでは、GitLab Self-ManagedおよびDedicatedインスタンスの管理者は、プロジェクトメンテナーがすべてのグループとプロジェクトを選べないように設定して、すべてのプロジェクトに対してより安全性の高い設定を強制できるようになりました。この変更により、プロジェクト間でのセキュリティレベルをさらに強化できます。
• GitLab 18.0では、この設定がデフォルトで有効になります。GitLab.comでは、プロジェクトの認証ログに基づいて、プロジェクトの許可リストが自動的に作成されます。
• GitLab.comでのこの変更に備えて、クロスプロジェクトの認証にジョブトークンを使用しているプロジェクトメンテナーは、担当するプロジェクトにおいて認証されたグループとプロジェクトの許可リストを入力する必要があります。完了後、このプロジェクトと許可リストに含まれるすべてのグループとプロジェクトのみに設定を変更してください。GitLab 18.0より前のバージョンのプロジェクトの認証ログに基づき許可リストの作成を自動化するには、ご用意している移行ツールのご利用をおすすめします。
• Self-Managedユーザーは18.0へのアップグレードを完了する前に、許可リストの入力を完了する必要があります。
• Dedicatedユーザーは、お客様固有のインスタンスに適した計画を立ててください。GitLabアカウントチームがお手伝いいたします。

• 非推奨通知
• ドキュメント
• GitLab Detectiveによる検証を実施可能

3. 依存プロキシへのトークンスコープの強制適用

GitLab.com | Self-Managed | Dedicated

コンテナの依存プロキシは、パーソナルやプロジェクト、グループアクセストークンを用いた**docker loginおよびdocker pull**リクエストを受け取った場合、そのスコープを検証せずにリクエストを受け入れます。

GitLab 18.0では、依存プロキシでの認証の際に**read_registryおよびwrite_registry**スコープが必要となります。この変更の適用後に、これらのスコープを持たないトークンによる認証リクエストが行われた場合、拒否されます。

そのため、アップグレードする前に、必要なスコープを持つアクセストークンを新たに作成し、作成したトークンを使用してワークフローの変数とスクリプトを更新してください。

また、Dependency Token Checkerをご利用いただくことも可能です。コミュニティが開発したスクリプトで、トークンの表示および自動でのローテーションを行えます。

• 非推奨通知

影響度：中

1. GitLab.comでの脆弱性に関する新しいデータ保持制限

GitLab.com - Ultimateプランのお客様のみ

GitLab 18.1から、システムのパフォーマンスと信頼性の向上の目的で、GitLab.comでUltimateプランをご利用のお客様を対象に、6か月間にわたり段階的に新しいデータ保持制限を導入します。データ保持制限は、脆弱性データの保存期間に影響します。

12か月以上前に検出されたもので更新されていない脆弱性は、自動的にコールドストレージアーカイブに移動されます。コールドストレージアーカイブのデータに関する詳細は以下のとおりです。

• GitLab UIからアクセスおよびダウンロード可能
• 3年間保持される
• 3年後に完全に削除される

• 非推奨通知
• ドキュメント

2. allowed_pull_policiesにないコンテナイメージのプルポリシーを拒否

GitLab.com | Self-Managed | Dedicated

設定済みのプルポリシーはすべて、Runnerの**config.tomlファイル内のallowed_pull_policies設定に含まれていなければなりません。含まれていない場合、incompatible pull policy**エラーにより、ジョブの実行が失敗します。

現在の実装では、複数のプルポリシーが定義されている場合、少なくとも1つのプルポリシーが**allowed-pull-policies**の設定内容と一致すれば、ほかのポリシーが含まれていなくても、ジョブの実行は成功します。

GitLab 18.0では、**allowed-pull-policiesに含まれるプルポリシーと一致するものがない場合にのみ、ジョブが失敗します。ただし、これまでの動作とは異なり、allowed-pull-policies**に含まれるプルポリシーだけをジョブが使用するようになります。この違いにより、現在成功しているジョブがGitLab 18.0では失敗する可能性があります。

• 非推奨通知
• ドキュメント

3. PostgreSQL 14と15がサポート対象外に

Self-Managed

GitLabは、PostgreSQLの年間アップグレードスケジュールに従っています。

そのため、GitLab 18.0でPostgreSQL 14と15はサポート対象外となる予定です。GitLab 18.0で必要となるPostgreSQLの最小バージョンは、PostgreSQL 16です。

PostgreSQL 14と15は、GitLab 17の全リリースサイクルでサポートされます。PostgreSQL 16は、GitLab 18.0より前のバージョンにアップグレードしたインスタンスでもサポートされます。

この変更に備えて、PostgreSQLクラスターを使用していないインスタンス（Omnibus Linuxパッケージがインストールされた単一のPostgreSQLインスタンスを実行中の場合など）では、GitLab 17.11へのアップグレード時にPostgreSQLをバージョン16に自動的にアップグレードしようと試行します。PostgreSQLクラスターを使用している場合、またはこのような自動アップグレードを希望しない場合、GitLab 18.0にアップグレードするには、事前にPostgreSQL 16に手動でアップグレードする必要があります。その際、アップグレードを行えるように十分なディスク容量があることを確認してください。

• 非推奨通知
• ドキュメント
• 移行に関するガイドライン

4. Terraform CI/CDテンプレートの非推奨化

Self-Managed

Terraform CI/CDテンプレートは非推奨化されており、GitLab 18.0で削除される予定です。影響を受けるテンプレートは以下のとおりです。

• Terraform.gitlab-ci.yml
• Terraform.latest.gitlab-ci.yml
• Terraform/Base.gitlab-ci.yml
• Terraform/Base.latest.gitlab-ci.yml

これにより、GitLabはジョブイメージの**terraform**バイナリをBSLライセンスのもとで提供されているバージョンに更新することができなくなります。

引き続きTerraformを使用するには、テンプレートとTerraformイメージを複製し、適宜保持してください。カスタムビルドイメージへの移行手順の詳細についてはこちらでご確認いただけます。

また、代替案として、GitLab.comで新しいOpenTofu CI/CDコンポーネントの使用、またはGitLab Self-Managedで新しいOpenTofu CI/CDテンプレートの使用をおすすめします。 CI/CDコンポーネントはGitLab Self-Managedではまだ利用できませんが、イシュー#415638において、この機能の追加が提案されています。GitLab Self-ManagedでCI/CDコンポーネントが利用可能になると、OpenTofu CI/CDテンプレートは削除される予定です。

新しいOpenTofu CI/CDコンポーネントの詳細についてはこちらをお読みください。

• 非推奨通知

5. Prometheusサブチャートのメジャーアップデート

Self-Managed

GitLab 18.0とGitLabチャート9.0で、Prometheusサブチャートのバージョンが15.3から27.3にアップデートされます。

このアップデートに伴い、デフォルトではPrometheus 3が付属するようになります。

アップグレードを実行するには、手動での設定が必要です。Alertmanager、Node Exporter、Pushgatewayのいずれかが有効になっている場合は、Helm値も更新する必要があります。

詳細については、移行ガイドを参照してください。

• 非推奨通知

影響度：低

1. SUSE Linux Enterprise Server 15 SP2パッケージのビルド終了

Self-Managed

SUSE Linux Enterprise Server (SLES) 15 SP2の長期サービスおよびサポート（LTSS）の提供は、2024年12月に終了しました。

これに伴い、Linuxパッケージインストール用のSLES SP2の配布を終了します。引き続きサポートをご利用いただくには、SLES 15 SP6にアップグレードする必要があります。

• 非推奨通知

2. Gitalyレートリミッターの削除

Self-Managed

以前、GitalyではRPCベースのレート制限がサポートされていました。この機能では期待する結果が得られなかったため、GitLabでは非推奨となります。詳細については、非推奨化に関するイシューをご覧ください。

（非推奨となる）レートリミッターを設定している場合は、エラーは返されず、単に設定が無視されます。

代わりに、並行処理リミッターのご利用をおすすめします。

• 非推奨通知

3. NGINXコントローラーイメージ1.3.1のサポートの非推奨化

Self-Managed

デフォルトのNGINXコントローラーイメージが1.11.2に更新されます。新しいバージョンでは、新たなRBACルールが必要となります。ユーザーによっては、独自のRBACルールを管理するためにnginx-ingress.rbac.create: falseを設定しています。

これらのユーザーは、1.11.2以降のバージョンに移行する前に、RBACルールを追加する必要があります。そのため、このHelm値が上記のように設定されている場合にのみ、1.3.1をデプロイするフォールバックメカニズムを実装しました。また、nginx-ingress.controller.image.disableFallbackも追加しました。デフォルトではfalseに設定されています。独自のRBACを管理しているユーザーは、新しいRBACルールが適用されていることを確認してから、この値をtrueに設定することで、デプロイ環境で1.11.2も使用できるようになります。

なお、バージョン17.5では、1.3.1のイメージのサポートとフォールバックメカニズムを非推奨とする予定です。これにより、1.3.1のサポートが完全に終了となり、多数のセキュリティ上のメリットを得られる1.11.2のみを使用できるようになります。

非推奨通知

4. アプリケーションセキュリティテストアナライザーのメジャーバージョンをアップデート

GitLab.com | Self-Managed | Dedicated

GitLab 18.0のリリースに合わせて、アプリケーションセキュリティテストステージで使用されるアナライザーのバージョンが大幅に更新されます。

デフォルトで含まれているテンプレートを使用していない場合、または利用するアナライザーのバージョンを固定している場合は、CI/CDジョブの定義を更新して、固定したバージョンを削除するか、最新のメジャーバージョンに更新する必要があります。

GitLab 17.0～17.11をお使いの場合は、GitLab 18.0のリリースまで、通常どおりアナライザーのアップデートをご利用いただけます。GitLab 18.0以降のバージョンでは、新たに修正されたバグや機能はすべて、新しいメジャーバージョンのアナライザーでのみリリースされます。

GitLabのメンテナンスポリシーに基づき、バグ修正や新機能を非推奨バージョンに実装することはありません。セキュリティパッチは、必要に応じて最新の3つのマイナーリリースにバックポートされます。

• 非推奨通知

5. API Discoveryにおいてデフォルトでブランチパイプラインを利用するように

GitLab.com | Self-Managed | Dedicated

GitLab 18.0では、API DiscoveryのCI/CDテンプレート（API-Discovery.gitlab-ci.yml）のデフォルトの動作が更新されます。

このテンプレートはGitLab 18.0より前のバージョンでは、MRが開いているときに、デフォルトでマージリクエストパイプラインを実行するように設定されていました。

GitLab 18.0からは、ほかのASTスキャナーのStableテンプレートエディションの動作に合わせて、このテンプレートの動作を変更します。

• デフォルトでは、本テンプレートはブランチパイプラインでスキャンジョブを実行するようになります。
• CI/CD変数のAST_ENABLE_MR_PIPELINES: trueを設定すると、MRが開いているときに代わりにMRパイプラインを使用できます。この新しい変数の実装状況は、イシュー#410880で追跡されています。

• 非推奨通知

6. DASTのDAST_DEVTOOLS_API_TIMEOUTのデフォルト値を低めに変更予定

GitLab.com | Self-Managed | Dedicated

DAST_DEVTOOLS_API_TIMEOUTは、DASTスキャンがブラウザからの応答を待つ時間を指定する環境変数です。GitLab 18.0より前のバージョンでは、この変数の値は45秒に固定されていました。GitLab 18.0から、DAST_DEVTOOLS_API_TIMEOUT環境変数に動的な値が設定されます。この値は、他のタイムアウト設定をもとに算出されます。

多くの場合、45秒という値は多くのスキャナー機能のタイムアウト値よりも高いものでした。動的に値を算出することで、__DAST_DEVTOOLS_API_TIMEOUT__変数をよりさまざまな状況で適用できるようになり、使いやすくなります。

• 非推奨通知

影響を制御するためのツールとリソース

予定されている変更点がご利用のGitLabインスタンスに及ぼす影響を把握できるように専用ツールを開発しました。GitLab 18.0にスムーズに移行できるように、ご自身にどのような影響があるかを見極めてから、ドキュメントに記載されている影響を軽減するためのステップをご確認いただくことをおすすめします。

• 非推奨機能の高度な検索：このツールはGitLabのAdvanced Search APIを使って、GitLabのグループやプロジェクト全体で、非推奨に関連する文字列を検索します。手動でチェックすべきファイルがあれば、それも報告します。注：誤検出が生じる可能性もあります。
• 依存関係スキャンビルドサポート検出ヘルパー：このツールは、依存関係スキャンの3つの非推奨事項（1、2、および3。すべて19.0に延期）の影響を受けるプロジェクトを特定します。APIを使用して、関連するファイルとCIジョブ名をスキャンします。
• GitLab Detective（Self-Managedでのみ利用可能）：実験的なツールで、インストールされているGitLabに既知の問題がないか自動的にチェックします。設定ファイルやデータベースの値を調べて、複雑な確認作業を行います。注：必ずGitLabノード上で直接実行してください。

また、GitLab Universityでは、これらの変更点に備え、計画および影響を緩和するための対応を行う上で役立つミニコース（15分以内）を公開しました。ぜひこちらから学習を開始してください。

有料プランをご利用の方で、ご紹介した変更点についてご質問がある場合や、サポートをお求めの場合は、GitLabサポートポータルでサポートチケットを作成してください。

Gitlab.comのFreeプランをご利用の場合は、GitLabドキュメントやGitLabコミュニティフォーラム、Stack Overflowなどのコミュニティソースを通じて追加サポートを受けられます。