1. はじめに: AI活用の新時代を切り拓く効率的なソフトウェア開発
2. Claude Codeとは何か？
3. GitLabのCLIであるGLabの紹介
4. Claude CodeとGLabを組み合わせた開発の流れ
5. AIを使った開発の今後の広がりについて
6. まとめ
7. よくある質問

はじめに: AI活用の新時代を切り拓く効率的なソフトウェア開発

この記事を読むと、エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法がわかるようになります。

Claude Codeとは何か？

Claude Codeとはエージェント型AIで、ターミナル上でAIにコマンドを実行させることで既存ツールを使いながら効率的に開発できます。

GitLabのCLIであるGLabの紹介

GLabはオープンソースのGitLab CLIツールです。GLabをターミナルに統合し、作業中のコマンドラインツールや、IDEの中に表示できます。GitLabのWebUIにアクセスするためにブラウザのウィンドウやタブに切り替える必要がなくなり、マージリクエストの作成やパイプラインの状況の確認など、様々なことを直感的にコマンドラインで実行可能になります。

Claude CodeとGLabを組み合わせた開発の流れ

Claude Codeとglabのインストール

ここでは個別のインストール方法や導入の仕方については割愛しますが、下記の公式サイトが参考になると思いますのでご確認ください。

Claude Code: https://docs.anthropic.com/ja/docs/claude-code/overview

GLab: https://gitlab.com/gitlab-org/cli/-/blob/main/README.md

GitLabの認証情報を設定

まずはGLabのセットアップをしていきましょう。GLabでGitLabサーバーにログインします。

$ glab auth login

上記を実行すると、ログインするサーバーの先を問われるので、選びます。続いて、Tokenによるログインか、Webブラウザを使って認証するか聞かれるため、これも好きな方を選んでください。下記は、Webを選んだ場合の画面です。

次に、Gitクライアントが通信するデフォルトのプロトコルを聞かれるので、これも好きなものを選んでください。環境によってはSSHプロトコルの通信が制限されている場合もあるかと思うので、そのような場合はHTTPSを選ぶことをおすすめします。

最後に、Gitの認証にもCredentialsの認証情報使うかを問われるため、これも選んでいただければと思います。 Yesの場合は、GitのHTTPS認証にもglabのPersonal Access Token（PAT）を使うよう.gitconfigに設定され、Noを選んだ場合は、glabでIssueやMRの操作をする一方で、Gitのpush/pullは従来通りのSSHや別途設定した認証方式で行う必要があります。

初期の設定が終わった画面を下記に示します。

開発対象プロジェクトのclone

次に、Claude Codeに指示を与えて、glabコマンドを使って、リモートリポジトリからcloneします。下記のコマンドでClaude Codeを起動します。

$ claude

既にGLabで認証は終わっているため、作業するプロジェクトのリポジトリをcloneするように指示を与えます。

> GitLab上で自分が参加しているプロジェクトを表示してください

上記のようにプロンプトするとClaude Codeが

$ glab repo list

などを実行してくれると思います。次に、作業したいリポジトリを上記から選び、Cloneします。プロジェクト名は各自の環境に合わせて指定してください。

> プロジェクト naosasaki-demo/study/spring-demo をcloneしてください

Claude Codeの処理が終わると、一度Claude Codeを終了し、ターミナルでディレクトリを確認すると、cloneされたディレクトリが作られていることがわかると思います。

新しいIssueの作成

次に、このプロジェクトに新しくイシューを作りたいと思います。通常であればWebブラウザでGitLabにアクセスしイシューを登録しますが、GLabとClaude Codeを使って、IDEやターミナル画面から作ってみたいと思います。

> このプロジェクトに新しいイシューを作ってください。内容は、今の東京の温度と天気を返すWebAPIのエンドポイントを作成します。

上記のようにglabを使ってイシューを作成するコマンドが提案されます。またイシューのなかの記載もある程度書いてくれていることがわかります。

ブラウザでアクセスしても、正しく作られていることがわかります。

マージリクエストとブランチの作成と作業開始

次に、実際のこのIssueの内容を実装していきたいと思います。ここからはIDEのVisual Studio Codeも利用していきたいと思います。Visual Studio Codeを起動し、内蔵されたターミナルを開き、そこでClaude Codeを起動します。

早速、先ほど作ったイシューからマージリクエストを作って、その中で作業をしていきたいと思います。

> このリポジトリのプロジェクトのissue 53を実装したいので、glabでMRを作って、そのブランチをチェックアウトして

コードの編集と検証

> イシューの記載に基づいて実装してください。また、リポジトリ内部のドキュメントも追加に伴って更新してください。

OpenWeatherMap APIを使うことを提案してくれています。そのほかにも、いくつかのクラスを作成することを提案されるので、中身を確認しつつ、それを受け入れ、git pushなども依頼します。

レビューとCI/CDの確認

実際にマージリクエストを確認すると、ローカルで作成した変更がプッシュされ、GitLab側のCI/CDでの単体テストや、セキュリティスキャンなども正常に実行され、問題なく終了していることがわかりました。

しかし、テストが通っていても、それが適切な方法で実装されているか、非機能的な観点で問題がないかは別途確認する必要があります。ここでGitLab Duo in merge requestsという機能を利用して、GitLabのAI機能であるGitLab Duoにレビューを依頼してみたいと思います。

マージリクエストのコメントでレビューをリクエストし、レビュアーとしてDuoを指定します。この時、レビューの観点なども同時に与えることができます。下記のようにコメントでレビューをDuoに依頼します。

/request_review @GitLabDuo

マージリクエストのコードを下記の観点でレビューしてください：

拡張性：将来的な機能追加や変更に対応しやすい設計・実装になっているか  可読性：他の開発者が理解しやすいコードになっているか  安全性：バグやセキュリティリスクを引き起こす可能性がないか  パフォーマンス：必要以上にリソースを消費していないか

上記をコメントすることで、Duoにレビューを依頼できます。

実際にレビュー指摘がありました。

Duoの指摘のとおり、Claude Codeが生成した元のコードでは、translateWeatherToJapanese メソッドが呼ばれるたびに HashMap が新しく作成されています。これはパフォーマンスの低下や不要なオブジェクト生成につながります。Duoは「このマップは不変であり、再利用可能なので static final にすべき」と提案しています。これの指摘は確かにその通りなので、マージリクエスト上でこの指摘と、変更の提案を受け入れます。

この変更の受け入れ自体も、ソースコードの変更なので、受け入れたらCI/CDパイプラインが動き出して、再度自動的にセキュリティスキャンや単体テスト実施されます。再度CI/CDパイプラインが動き、問題がなかったためmainブランチにマージしました。これでこの機能の開発は完了です。

AIを使った開発の今後の広がりについて

AIは「補助ツール」から「実行の主体」へ

従来のチャットベースのインタラクティブな開発支援、すなわち一問一答のやり取りを繰り返しながら人間が主導で手を動かしていた開発スタイルから、いま大きな転換が始まっています。

GLabのようなCLIツールやWebAPIと、エージェンティックAIを組み合わせることで、「命令→実行→ステータス確認→再試行」といった一連の開発オペレーションを、AIが自律的かつ反復的に担う、まさに実行主体としてのAIへの進化が進んでいます。

これは単なる補助からの脱却であり、ソフトウェア開発における人と機械の役割分担そのものを再定義しつつあります。人間は「何を実現したいか」を定義し、AIは「どう実現するか」を粘り強く試行錯誤していく、そんな協働の形が、現実の開発現場に静かに浸透し始めています。

レビューとガバナンスの重要性

AIによってコードが自動生成されるようになった今、開発効率が飛躍的に向上する一方で、「そのコードは本当に安全か？」「人間はAIの出力を正しくレビューできるのか？」といった新たな課題が生まれています。

人間の作業と同様に、AIによって生成されたコードは、動作するからといって、品質が担保されているとは限りません。

こうした背景から、組織的にAIを活用していくには、コードの品質・セキュリティ・コンプライアンスを保証する仕組みを開発プロセスに組み込むことが不可欠です。

今回は、コードの生成にClaude Codeを利用しましたが、そのコードに含まれる性能的な懸念をGitLab Duoによるレビューで摘出することができました。

その他にも、GitLabでは「パイプライン実行ポリシー」を用いることで、プロジェクト単位ではなくグループやサブグループに対して、SASTや依存関係スキャン、シークレット検出などのセキュリティジョブを強制適用することが可能です。

このように、AIによる開発支援とセキュリティ・品質管理の自動化を同時に実現できるのは、DevSecOpsを包括的に支援するプラットフォームであるGitLabの強みといえます。

まとめ

この記事では、Claude CodeのようなAIエージェントと、GitLab公式CLIツールGLabを組み合わせることで、自然言語によるコード生成からGitLab上でのイシュー管理やマージリクエスト作成までをAIエージェントにやってもらうことで、開発効率を向上させる例を紹介しました。一方で、AIエージェントが生成するコードの品質を担保するには、GitLabのセキュリティスキャンやパイプライン実行ポリシーを活用した自動検証の仕組みが欠かせません。AIと人間、それぞれの強みを活かした開発フローが、今後ますます重要になっていくでしょう。

今すぐ始められる：GitLabでAIを使ったソフトウェア開発を体験しよう

GitLab Duoの60日間無料トライアルに申し込む

よくある質問

Q1: GitLabのAI機能にはどのようなものがありますか？

A1: GitLabのAI機能「GitLab Duo」には、ソースコードの提案、テストケース/コードの生成はもちろん、脆弱性の自動修復や、CI/CD失敗時の根本原因分析など、ソフトウェア開発全体に対するAIによる支援機能群が含まれています。

Q2: GitLab Duoはユーザーのソースコードを学習に使いますか？

A2: いいえ。GitLab Duoは利用者のコードやデータをモデルの再学習には使用しません。GitLabはユーザーデータのプライバシーとセキュリティを重視しており、企業向けにも安心して利用できる設計となっています。詳細については、GitLab AI Transparency Centerをご確認ください。

Q3: Claude Codeとは何ですか？

A3: Claude Codeとはエージェント型AIで、ターミナル上でAIにコマンドを実行させることで既存ツールを使いながら効率的に開発できます。

Q4: GitLab CLIのGLabとは何ですか？

A4: GLabは、GitLab公式が提供するオープンソースのCLIツールです。GLabをターミナルに統合し、作業中のコマンドラインツールや、IDEの中に表示できます。

さらに、IBMと協力してメインフレームDevOpsの最新化にも取り組んでいます。（そう、あのCOBOLが再び注目を浴びています！）

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

GitLab 18 バーチャルローンチ：AI × オーケストレーションの未来へ

先月、GitLab 18のバーチャルローンチイベントを開催しました。
ライブ配信を見逃した方も大丈夫。ここで簡単にポイントを振り返ります。

注目のハイライトは？
それは、GitLab Duo Agent Platform の登場です。この新しいプラットフォームでは、エンジニアとAIエージェントがソフトウェア開発のあらゆる工程で連携・協働できるようになります。これにより、開発チームの生産性や開発スピードが大きく向上することが期待されています。

GitLabのCEO、ビル・ステイプルズはこのように語りました：

「GitLab 18は、人とAIエージェントが一緒に働けるDevSecOpsオーケストレーションフォームです。ソフトウェア開発のあらゆる工程で、“エージェント型AI”を活用したチームワークを実現します。」

つまり、これは開発者の代わりになるものではなく、繰り返し作業の負担を減らし、人の創造力と専門性をもっと活かせるようにするための進化です。私たちはそんな未来を目指しています。

さらに今回、GitLabの統合DevSecOpsプラットフォームとAmazon Q Developerエージェントの連携も発表しました。この強力な組み合わせにより、より安全でスピーディーなソフトウェア開発が実現します。

GitLab Duo + Amazon Qは、AIを活用したシームレスな開発の新時代を象徴するものです。

イベントにはBarclaysとThalesも登場し、GitLab 18がそれぞれの組織の開発プロセスをどう変えているのか、リアルな声を共有してくれました。金融の高度なセキュリティ要件から航空業界のイノベーションまで、GitLab 18がもたらす影響は確かなものです。

👉 イベントのフル動画は GitLab 18 Launch Eventページ でご覧いただけます。

GitLab 18.1がリリースされました：セキュリティ、スピード、そしてAIの進化

GitLab 18をリリースをしてすぐではありますが、GitLab18.1が登場しました！この最初のリリースには、チームの開発スピードとセキュリティをさらに高めるためのアップデートが満載です。

注目の新機能はこちら：

✅ Duoコードレビュー が正式リリース！
AIがマージリクエストに対してインテリジェントなフィードバックを提供し、レビューのスピードアップやバグの早期発見を支援します。

📦 Maven仮想レジストリ（Virtual Registry） がベータ版に
GitLab上でのMaven依存関係の管理がより簡単になりました。

🔐 漏洩パスワード検出機能 を追加
あなたのパスワードが既知のデータ漏洩に含まれていないかを検出し、安全な変更方法を案内してくれます。

🔁 SLSAレベル 1 準拠をサポート
新しいCI/CDコンポーネントを使って、ソフトウェアサプライチェーンのセキュリティ強化に貢献します。

そして、何より嬉しいのは、みなさんからの 110件以上の改善と、311件ものコミュニティ貢献によってこのリリースが実現したことです。開発・レビュー・ドキュメント・ビルドに関わってくださった全ての方々、本当にありがとうございます！

👉 リリースノート全文はこちら！

新ライブ配信シリーズ：The Developer Show – Powered by GitLab

GitLabからの新しいライブ配信シリーズが始まりました！その名も The Developer Show – Powered by GitLab。私とセキュリティPMMのSalがホストを務める、月1回のライブ配信番組です。

これはよくある「普通のウェビナー」ではありません。毎回、実際に今の開発現場を変えている技術について深く掘り下げていきます。

対象は、開発者、開発リード、コードに関わるすべての人。業界で本当に語られているリアルな会話をキャッチアップしたい人向けです。

📺 エピソード1では、GitLab 18 バーチャルローンチの内容を振り返り！
ハイライトの紹介はもちろん、実践的なヒントやちょっと辛口なコメントも交えてお届けします。

👉 今すぐ視聴＆チャンネル登録して、次回もお見逃しなく！

AWS Summit New York：GitLabブースでお会いしましょう！ !

先日の東京に引き続き、7月16日、GitLabチームはニューヨークで開催されるAWS Summitに参加します！お近くの方は、Javits Center内のGitLabブースにぜひお立ち寄りください。

当日は以下の内容をご用意しています：

• GitLab DuoのAI機能を体験できるハンズオンデモ
• セキュリティ、開発スピード、開発者体験に関するライトニングトーク
• GitLabのDevSecOpsエキスパートとの対話（ご質問大歓迎です！）
• 限定ノベルティやプレゼントもご用意しています

さらに、当日はAWSのAgentic AI担当VPのSwami Sivasubramanian氏による基調講演も実施されます。Agentic AIがソフトウェア開発をどう変えていくのか、GitLabとしても非常に関心のあるテーマです。

参加登録は無料です。ぜひこちらからお申し込みください：登録はこちら

GitLabチームに会いに来ませんか？ WeAreDevelopers World Congress !

世界中の開発者とつながるこのイベントで、GitLabチームも皆さんとお会いできるのを楽しみにしています！スタンド A07 にぜひお立ち寄りください。GitLabのDevSecOpsプラットフォームが、ソフトウェアのデリバリーをどのように加速し、チーム間のコラボレーションを強化できるか等をご紹介します。

CI/CDやセキュリティ自動化、開発フローの改善に興味がある方はもちろん、
どんな質問にもチームメンバーがお答えしますので、お気軽にお声がけください。

また、金曜日には注目のセッションも：

• 13:40〜 GitLab VP of Engineering、Maw Wildpanerによる講演
  　「なぜ“セキュリティファースト開発”が、より良いソフトウェアを早く届ける鍵となるのか」
• 16:30〜 GitLab VP of Strategy and Developer Relations、Emilio Salvadorが登壇するパネル「DevRelの戦略的な力：コミュニティからビジネスインパクトへ」

👋 ベルリンでお会いしましょう！

事例のご紹介：Thales

今月の事例紹介は、なんと高度3万5千フィートの空の上からお届けします。Thales は、航空宇宙・防衛分野のグローバルリーダー企業。彼らは従来のDevOpsプロセスを、クラウドネイティブでCI/CD駆動のイノベーションエンジンへと進化させました。

GitLabを活用して開発したのが、次世代の機内エンターテインメントシステム「FlytEDGE」。乗客ごとにパーソナライズされたコンテンツやサービスを提供しながら、デプロイ時間を95%短縮することに成功しています。分散チーム間のコラボレーションをスムーズにし、パイプライン全体に自動化を導入し、開発者がボトルネックなく素早くリリースできる環境を実現。その結果、従来の20倍のスピードでデプロイできるようになりました。

👉 こちらから導入事例を詳しくご覧ください

今月のおすすめ記事

今月もGitLabのSlackチャンネルでは、たくさんの素晴らしいDevSecOpsの考えや情報がシェアされています。その中から特に注目されているものをご紹介します。

• https://japan.zdnet.com/article/35234560/
• https://vmblog.com/archive/2025/06/23/breaking-down-silos-gitlab-and-ibm-partner-to-modernize-mainframe-devops.aspx
• https://www.nextgov.com/ideas/2025/05/legacy-government-systems-enter-ai-era/405642/
• https://www.economiematin.fr/investissement-operateur-telecom-technologie-caronna
• https://thenewstack.io/accelerating-developer-velocity-with-effective-platform-teams/
• https://leaddev.com/uncategorized/how-get-most-out-ai-tooling

📌 今月の名言

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

高速なデプロイ、スマートなセキュリティ、次世代の開発者のための開発など、
どんなに難しいことに取り組んでいても、あなたならきっとできます。

🦊 また次回まで！

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

Fatima Sarah Khalid | GitLab Developer Advocate

会場の様子

振り返れば、昨年のイベントは観世能楽堂で実施して、大好評でした。GitLabは、全世界でオフィスを持たない企業として知られていて、全員がリモートワークです。社員とお客様、デベロッパーの皆様と直接触れ合える機会ですから、自分たちにとっても参加者の皆様にとっても楽しいものにしたいと、会場選びから気合を入れて準備してきました。ぜひ次の機会もお楽しみに！

さて、このブログ記事では、当日の講演の模様をお伝えします。テーマは、AIです。

会場の様子

世間では、日本企業のAI活用は遅れているとされています。しかし、基調講演に登壇したAndrew Haschkaは、具体的なデータを示し、実はそうでないと説明します。Haschkaは、豪州を拠点にアジア太平洋地域を中心にGitLabのField CTOとしてユーザーのさまざまな課題に向き合っており、ユーザーの事情を肌感覚で知っているため、説得力があります。

GitLab Field CTO, Asia Pacific & Japan, Andrew Haschka

ソフトウェア開発ライフサイクル（SDLC）においてAIを使用中の企業は、米国の34%に対して日本は48%。これは世界的に見ても高い数値です。ただし、Haschkaは「数字だけを見ると良い傾向なのですが、日本のAI活用はAIコーディングの部分にとどまっています」と釘を刺します。「残念ながら、ソフトウェア開発のライフサイクル全体を通したAI活用には至っていません」。

SDLCで現在AIを使用している、または今後の導入を計画している割合

AIは、確かにコーディングをスピードアップしてくれます。一方で、セキュリティがないがしろにされてしまうリスクには注意が必要です。Haschkaは、あるインドネシアのGitLabユーザーを例に挙げました。その企業は、AIコーディングによって、開発スピードが大幅に向上し、同じ時間で完成するコード量が飛躍的に増えました。その結果、何が起きたのでしょう。コード量と同時にリスク要素が増えてしまい、脆弱性チェックに大変な手間がかかるようになってしまったのです。

Haschkaは、「ただ、このケースはまだ良い方です。コードをきちんとチェックできているわけですから。“コンプライアンス・ガードレール”が正しく機能していることが証明されたと言えます」と話します。大きな問題は、SDLCに正しくガードレールを設置できておらず、コーディングのスピードアップにより、セキュリティがないがしろにされても、それに気づかない状態のまま放置されることで発生します。

そうした事態に陥ることを防ぎ、セキュリティを担保しながらAIをソフトウェア開発に役立てるために、HaschkaはSDLCを通した3つの視点を持つ必要があるとします。まずは、SDLCを透過的に管理できる統合されたプラットフォームを持つこと。GitLabのように統合的なプラットフォームでSDLC全体へのガバナンスを効かせることが必要で、ポイントソリューションの組み合わせで運用することは難しいのです。

GitLab Field CTO, Asia Pacific & Japan, Andrew Haschka

次に、SDLCに動的なセキュリティ対策を行き渡らせること。対策における最大のテーマは脆弱性管理と依存性管理です。ライブラリやコンポーネントの依存性を可視化・管理し、セキュリティとライセンスについての承認プロセスを必要なポイントで埋め込みます。スキャンの強制実行も大切な要素で、この部分は自動化できるケースもあり、開発生産性を損なわずにセキュリティを担保することを期待できます。これらは、GitLabをSDLCのプラットフォームとして使っていれば、必要なプロセスに埋め込み、優れたガードレールとして機能させることができます。

GitLab Duoの利用形態

最後に、必要に応じてローカルLLMを活用すること。ローカルLLMは、クラウドを通さずローカル環境で動作するLLMで、データプライバシーを保護できることが特長。ローカルで稼働するため、機密情報を安全に扱うことができます。GitLab Duo Self Hosted Modelsを使うことで、ローカルLLMをGitLabと連携して運用することが可能になります。

これら3つの視点を持ち、SDLCを安全に運用するひとつのやり方として、Haschkaはプラットフォーム・エンジニアリング（PE）チームが主導的な立場を担うケースがあると指摘しています。

PEチームと開発部門が密な連携を取り、GitLabでSDLCを改革

オリンパス株式会社 R&Dセンターオブソフトウェアエクセレンス, グローバル ソフトウェア開発インフラストラクチャ シニアディレクター 柳田 修太氏

続いては、オリンパス株式会社の事例講演です。同社は、内視鏡を主力に医療デバイスをワールドワイドに提供するメーカーです。そして、優れたPEチームがSDLCの改革で大きな役割を果たした企業の1つでもあります。同社のPEへの取り組みは、グローバルに展開されるソフトウェア開発の効率化、およびコスト適正化を図るためにスタートしました。

スクリーンを背後に演壇に立った柳田 修太氏は、「弊社の開発サイクルは5から10年と長いものが多いことが特徴です。そのため、プロジェクト開始時のインフラが最新でなくなるケースが多いのです」と話します。「医療機器に組み込まれるソフトウェアの開発ですから、ソフトウェアを使う前のバリデーションが不可欠になります。クラウド化されていて特定のタイミングで強制的にバージョンアップされてしまうツールは、どれだけすばらしいものであっても、弊社の開発で使用することは困難です」。

SDLCをよりセキュアにするためには、何らかのプラットフォームは必要になります。要件は、全世界でサポートしてくれるプラットフォームであること。そして、各国で異なる法規制に対応できること。さらに、自社のさまざまな開発要件への適用が可能であること。たとえば、アジャイル開発、仮想化、コンテナへの対応は当然のこと。特殊なニーズのある組み込みソフトウェアの開発プロセスにも対応できなければなりません。

オリンパス株式会社 R&Dセンターオブソフトウェアエクセレンス, グローバル ソフトウェア開発インフラストラクチャ シニアディレクター 柳田 修太氏

こうしてGitLabを選定したのですが、当初は抵抗もあったといいます。人命にかかわる医療機器の開発プロセスの改革ですから、万全を期する必要があるためです。それでも深い議論を重ね、開発部門と密な連携を取ったことで、少しずつGitLabを試してもらえるようになりました。そうして実際に成果を体験してもらったことで、開発者側からもGitLabを使いたいという声が上がってきます。

柳田氏は、「ビルドのスピードアップが大きなポイントで、並行して複数のビルドを走らせられるため、開発生産性が高まりました。統合ツールとしてインフラ管理が楽なことも、開発現場に受け入れられた理由の大きなところでしょう。開発部門との関係性も高めることができ、いまでは新規プロジェクトを中心にユーザーがどんどん増えています」と話します。

GitLabの浸透に伴ってアジャイルな開発スタイルでの活用も進み、開発スピードはさらに向上しました。GitLabでSDLCを包括的に管理できたことで運用コストを低減し、GitLab Runner（CI/CDのジョブ実行主体）を活用することでコンテナ環境における開発も大幅に効率化しています。こうしてHaschkaの指摘した3つの視点のうち、1と2は着実にオリンパスに定着しつつあります。

今後取り組むのは、3のセキュアなAI活用です。現状は、オリンパスの開発者が作ったコードをAIの学習に使わないと明記したMoUをGitLabと締結した段階。社内でリスクアセスメントを実施し、本格運用に向けた試験運用を続けています。

「AIコーディングだけをとってもローカルLLMの価値は大きい」

株式会社NTTデータグループ 技術革新統括本部 AI技術部 部長 加藤耕也氏

続いては、NTT DATAの講演です。NTT DATAは、生成AI活用コンセプト「SmartAgent™」を発表するなど、ローカルLLMビジネスを積極的に展開しています。グローバルで1000件超の受注実績があり、SDLCの生産性向上目標としてFY25で50%、FY27には70%を掲げています。

同社は社内でも生成AIをソフトウェア開発分野へ適用し、開発業務の効率化を目指しています。現在は、タスクの自動化を進めている段階。これは支援型AIと定義される分野ですが、次なるターゲットはいわゆる自律型AIへの進化です。自律型AIが実用段階に入れば、労働集約型産業はAI駆動型へと進化することが期待されています。NTT DATAは市場に先駆けて自律型AIの本格運用を進めることで、今年から2027年にかけてプロセスの自動化へと発展させ、さらに将来は開発業務のより広範な領域をまたいだ業務の自動化も実現させたい考えです。

株式会社NTTデータグループ 技術革新統括本部 AI技術部 市原大暉氏

生成AI活用におけるプライベートクラウド・オンプレミスの重要性

AIの利用範囲が拡大することに伴い、よりセキュアなAIが求められるようになります。そのためにローカルLLMの注目が高まっているわけですが、上の表に示したように、ローカルLLMにはメリットもデメリットもあります。それでも機密情報を扱うためには閉域網での開発が必須です。また、NTT DATAでは、顧客に対して独自に実施したヒアリングの結果、AIを独自にチューニングしてオリジナルな学習の方向性を定めたいというニーズが今後増えてくると見ています。これは、公共分野をはじめ、金融、製造、観光などさまざまな業種に共通するニーズです。講演した加藤 耕也氏は、「実は、AIコーディングだけをとってもローカルLLMの価値は大きいのです。そのプロセスにも強力なガバナンスを効かせられるようになりますから」と話します。同社では、すでに社内で約3,000ユーザーがローカルLLMを使って開発プロジェクトを進めています。

GitLab Duoを用いた検証結果

そしてこの日、GitLab Duoを用いたローカルLLM AIコーディング環境の検証結果を明らかにしてくれました。この検証では、機能面・非機能面での実用性を73項目で精査し、十分な精度を得られたことが報告されています。

「ローカルLLMは究極の安全性をもたらす」

GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴

最後のセッションに登壇したのは、GitLabの佐々木 直晴。この日のすべてのセッションを振り返りながら、さまざまなポイントの背景や詳細について語りました。中でも印象深かったのは、AIがコーディングすることでセキュリティレベルが低下する背景についてです。

佐々木は、CSETが昨年公開した資料を示し、AIは人間が書いた脆弱性を含むコードを学習データとするためそれを模倣してしまう可能性があると警告しました。「AIは、 “機能的に正しく動くコードを素早く出力”しようとします。そのとき、セキュリティの観点で重要な構成要素を無視してしまうことがあるようです。たとえば、例外処理や入力チェックなどはコードに入っていなくても機能的には正しく動くため、AIの提案からは抜け漏れやすいということが考えられます」。ローカルLLMについては、「自社の強みが流出するリスクを抑え、究極的な安全性をもたらす存在」とし、実際に多くの企業がそこを目指すだろうと展望しています。

GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴

佐々木は、Haschka の3つの視点を目指すにあたり、GitLabはユーザーのAI利用時にもプライバシーや知的財産権を保護しながらSDLC全体をAIでサポートできるプラットフォームであり続けるとも述べ、AIに取り組むなら安心してGitLabを採用してほしいと会場に呼びかけました。

*SmartAgentは日本国内における株式会社NTTデータグループの商標です。

AIエージェントの基礎知識と注目される理由

自律型AIは、人工知能の分野における大きな進化と言えるでしょう。従来の生成AIツールが常に人間からの指示を必要とするのに対し、AIエージェントは高度な言語モデルや自然言語処理を活用して、自律的に行動を起こします。自律型AIはリクエストを理解し、意思決定を行い、複数のステップからなる計画を実行して、目標を自ら達成できます。

このチュートリアルでは、GoogleのADKを使用します。ADKは、AIエージェントの開発とデプロイに対応した、柔軟でモジュール化されたフレームワークです。GeminiやGoogleのエコシステム向けに最適化されていますが、モデルやデプロイ方法に依存せず、他のフレームワークとの互換性も考慮して設計されています。

デモアプリの紹介：Canada City Advisor

デプロイプロセスを実演するための実用的な例として「Canada City Advisor」を使います。ユーザーの希望や条件に基づいて、理想的なカナダの都市を提案するAIエージェントです。

その仕組みは以下の通りです。

• ユーザーが予算条件やライフスタイルの希望を入力します。

• ルートエージェントが以下2つのサブエージェントを統括します。

  • 経済的な制約を評価する予算分析エージェント。カナダ住宅金融公社から取得したデータを使用します。
  • ユーザーの希望に合う都市を提案するライフスタイル分析エージェント。Open-Meteoから取得した適切な都市情報に基づく天気情報サービスも提供します。

• システムがユーザーに合った都市の候補を生成します。

異なる専門性を持つAIエージェントが連動して複雑な問題を解決するこのマルチエージェント構成により、自律型AIの強みが活かされます。サブエージェントは、ルートエージェントが予算やライフスタイルの分析が必要と判断したときにのみ呼び出されます。

前提条件

始める前に、以下のものが準備できていることを確認してください。

• 以下のAPIが有効になっているGoogle Cloudプロジェクト

  • Cloud Run API
  • Artifact Registry API
  • Vertex AI API

• ソースコード用のGitLabプロジェクト

• GitLabとGoogle Cloudの両方に対する適切な権限

ステップ1：ワークロードアイデンティティフェデレーションによるIAMインテグレーションを設定する

最初のステップでは、Workload Identity連携を使用して、GitLabとGoogle Cloudの間で安全なキーレス認証を確立します。これにより、サービスアカウントキーが不要となり、セキュリティが向上します。

GitLabプロジェクトでの手順は以下のとおりです。

1. 設定 > インテグレーション > Google Cloud IAMの順に移動します。

2. 以下の情報を入力します。

   • プロジェクトID：使用しているGoogle CloudプロジェクトのID
   • プロジェクト番号：Google Cloudコンソールで確認できるプロジェクト番号 Workload Identityプールの固有識別子
   • プロバイダーID：アイデンティティプロバイダーの固有識別子

GitLabがスクリプトを生成します。このスクリプトをコピーして、Google Cloud Shellで実行し、Workload Identity連携を作成します。

ステップ2：Google Artifact Registryのインテグレーションを設定する

次に、コンテナイメージを保存するGoogle Artifact Registryとの接続を設定します。

1. GitLabで、設定 > インテグレーション > Google Artifact Registryの順に移動します。

2. 以下の情報を入力します。

   • Google CloudプロジェクトID：ステップ1と同じプロジェクトID
   • リポジトリ名：既存のArtifact Registryリポジトリの名前
   • 場所：リポジトリが存在するリージョン

重要：リポジトリはすでにArtifact Registryに存在している必要があります。この設定操作では、GitLabが新しいリポジトリを自動で作成することはありません。

GitLabは、必要な権限を設定するためのコマンドを生成します。これをGoogle Cloud Shellで実行します。

さらに、Cloud Runへのデプロイのために、サービスプリンシパルに以下のロールを追加します。

• roles/run.admin
• roles/iam.serviceAccountUser
• roles/cloudbuild.builds.editor

以下のgcloudコマンドを使用して、これらのロールを追加できます。

GCP_PROJECT_ID="<your-project-id>" #replace

GCP_PROJECT_NUMBER="<your-project-number>" #replace

GCP_WORKLOAD_IDENTITY_POOL="<your-pool-id>" #replace


gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/run.admin'

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/iam.serviceAccountUser'

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/cloudbuild.builds.editor'

ステップ3：CI/CDパイプラインを作成する

ここからが本番です。デプロイ用のパイプラインを構築しましょう！GitLabのCI/CDコンポーネントを使用すると、非常に簡単に作成できます。

プロジェクトのルートに .gitlab-ci.yml ファイルを作成します。

stages:
  - build
  - test
  - upload
  - deploy

variables:
  GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA
  AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA

build:
  image: docker:24.0.5
  stage: build
  services:
    - docker:24.0.5-dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $GITLAB_IMAGE .
    - docker push $GITLAB_IMAGE

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/SAST.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml
  - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main
    inputs:
      stage: upload
      source: $GITLAB_IMAGE
      target: $AR_IMAGE
  - component: gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@main
    inputs:
      stage: deploy
      project_id: "<your-project-id>" #replace
      service: "canadian-city"
      region: "us-central1"
      image: $AR_IMAGE

このパイプラインは、以下の4つのステージで構成されています。

1. Build：AIエージェントを使用してDockerコンテナを作成します
2. Test：セキュリティスキャン（コンテナスキャン、依存関係スキャン、SAST）を実行します
3. Upload：コンテナをArtifact Registryにプッシュします
4. Deploy：Cloud Runにデプロイします

GitLabのCI/CDコンポーネントを使う大きなメリットは、いくつかのパラメーターを指定するだけで、認証やデプロイの複雑な処理をすべてコンポーネント側が自動で行ってくれる点です。

ステップ4：デプロイとテスト

すべての設定が完了したら、いよいよデプロイの実行です。

1. コードと .gitlab-ci.yml をGitLabリポジトリにコミットします。
2. パイプラインは自動的に実行されます。
3. GitLabのCI/CDインターフェースでパイプラインの進行状況を確認します。
4. 完了後、Google CloudコンソールでCloud RunのURLを確認できます。

各ステージが順番に実行される様子を確認できます。

• Buildステージでコンテナが作成されます。
• Testステージで包括的なセキュリティスキャンが実行されます。
• UploadステージでArtifact Registryにプッシュされます。
• DeployステージでCloud Runのサービスが作成または更新されます。

セキュリティ上のメリット

この手法には、以下のようなセキュリティ上の利点があります。

• 長期間有効な認証情報が不要：Workload identity連携により、サービスアカウントキーが不要になります。
• 自動セキュリティスキャン：すべてのデプロイで脆弱性がスキャンされます。
• 監査証跡：誰が何をいつデプロイしたのかを完全に可視化します。
• 最小権限の原則：きめ細かなIAMロールによりアクセスが制限されます。

まとめ

GitLabのセキュリティ機能とGoogle Cloudの強力なAIおよびサーバーレスプラットフォームを組み合わせることで、安全でスケーラブルなAIエージェントをデプロイできます。GitLabとGoogle Cloudのインテグレーションによって、従来こうしたデプロイに伴っていた複雑さの多くが解消されます。

このチュートリアルのサンプルコード 全文を使えば、 すぐに始められます。GitLabをまだご利用でない場合は、ぜひ無料トライアルでDevSecOpsプラットフォームをご体験ください。

監修：小松原 つかさ @tkomatsubara

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

出社後の流れが次のように変わることを想像してみてください。

• チームが取り組んでいるエピックに関する詳細な調査、過去1週間のすべてのコントリビュートに関する最新情報の収集、最近追加された機能に基づくリリース記事の提案、これらすべてのタスクを1体のAIエージェントに割り当てます。
• 同時に、別の複数のAIエージェントにいくつかのアクセシビリティバグの分析、およびそれらの修正に必要なコード変更を依頼します。
• さらに並行して、自分が加えた複雑なコード変更をチームメンバーに送信して正式なレビューを受ける前に、別のAIエージェントにレビュー・フィードバックを依頼します。
• 最後に、プロジェクト全体での調査が必要な新たな脆弱性についてセキュリティチームから通知があった場合は、セキュリティエージェントにその調査タスクを割り当てます。

これらのタスクはすべて同時に実行されます。その間、アーキテクチャに関する決定や、独創的な問題解決、戦略的な技術作業に専念できます。エージェントプラットフォームでは、5体、10体、さらには100体もの専門的なAIエージェントにタスクを委任できます。これらのAIエージェントはコードだけでなく、CIジョブログや計画作業アイテムなど、プロジェクトの全コンテキストに基づいてタスクを実行します。これまでやらざるを得なかった面倒な作業を自動化することで、やりがいのある作業に専念できるようになります。

このアプローチの目的は、デベロッパーを置き換えることではなく、日常的なタスクにより生じる業務の非効率性を解消し、人間の創造性と専門知識を活かせるようにすることです。 これこそが、GitLabがエージェントプラットフォームがもたらす未来です。

GitLab Duoエージェントプラットフォームとは？

エージェントプラットフォームは、チームの生産性とサイクルタイムの大幅な改善を支援するよう設計されており、ソフトウェア開発ライフサイクル全体にわたるエンジニアとAIエージェントの多対多のコラボレーションを実現します。

GitLabのセキュアな基盤上に構築されたエージェントプラットフォームは、カスタマイズおよび拡張が可能です。デベロッパーはエージェントプラットフォームを使用することで、ソフトウェア開発ライフサイクル全体のコンテキストを活用してソフトウェアエンジニアリングに関するあらゆる種類の問題に取り組むAIエージェントを構築できます。

専門的なAIエージェントとカスタムワークフローを備えたエージェントプラットフォームは、コード作成だけでなく、以下を含むほぼすべての作業をお手伝いできます。

• イシューの実装
• 大規模な移行や依存関係の更新
• ドキュメントやリリース記事の自動作成
• 破損したパイプラインの修復
• インシデント調査のサポート
• トピックに関するステータスや情報の詳しい調査
• バックログ管理
• 脆弱性の修正
• 特定のタイプのコード（データベースなど）のレビュー
• 既存のモジュールをベースとした社内ツールの迅速な構築
• その他多数

すぐに利用できるAIエージェントがあらかじめ用意されており、それらをカスタマイズまたは拡張することも可能です。現在、数十社のお客様の協力のもと、エージェントプラットフォームのベータテストを実施しています。ベータ版は、近日中にさらに多くの方々に公開される予定です。

以下の動画では、エージェントプラットフォームを実際に使用する様子をご覧いただけます。 <div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1095679084?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Agent Platform Demo Clip"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

ツールも、モデルも、エージェントも、自分で選べる

GitLabエージェントは、標準的なModel Context Protocol（MCP）とAgent2Agent（A2A）フレームワークを通じて、お好みのコード作成開発ツール（Cursor、Claude Code、Windsurf、OpenAI Codexなど）とシームレスに相互運用できます。これは、GitLabをオープンプラットフォームとして提供するという方針を反映しています。

エージェントプラットフォームは、技術スタック内のどの開発ツールからのコードのコントリビュートも受け入れます。それがデベロッパーによって記述されたものであれ、AIエージェントが生成したものであれ、関係ありません。つまり、エージェント機能を統合しても、これまで使い慣れたワークフローやツールは引き続きシームレスに動作します。

エージェントプラットフォームは、GitLabの選定基準を満たす承認済みの言語モデルであれば、どれでも利用できます。セキュリティ要件が厳しい組織向けに、完全にインターネットに接続されていない（エアギャップ）環境における承認済みのセルフホストモデルの実行もサポートしています。そのため、インフラ要件やセキュリティポリシーによって、自律型開発の実施を制限されることはありません。

コンテキストを把握して動く、GitLab Duoエージェント

単に便利なAIツールと本当にインテリジェントなAIエージェントの違いは、コンテキストを理解しているかどうかにあります。エージェントプラットフォームでは、AIエージェントは単独で動作しません。実際に開発作業が行われるプラットフォームに深く統合されています。

すべてのAIエージェントは、未解決のイシューとその履歴、イシューを解決したマージリクエスト、コードの構造と背後にある理論的根拠、CI/CDパイプラインの設定、セキュリティ検出、コンプライアンス要件、そしてこれらすべてのコンポーネントの複雑な関係など、プロジェクトの全体像を自動的に把握します。

AIエージェントもエンジニアと同様、安全なソフトウェアをよりスピーディーにリリースするために役立つコンテキストをすべて把握しています。AIエージェントは、コードに関する質問に答えるだけでなく、提案された変更がデプロイパイプラインにどのような影響を及ぼすかといったインサイトを提供したり、現行のコンプライアンス規則に基づいてセキュリティの改善を提案したりできます。GitLabのDevSecOpsプラットフォームで作業すればするほど、AIエージェントはより賢くなります。

エージェントがチームをスケールする際も、コントロールを維持

AIエージェントとの信頼関係の構築は、新しいチームメンバーとの信頼を築くことと本質的には変わりません。AIエージェントの仕事を見ながらアプローチを理解し、実際の遂行能力に応じて徐々にまかせる作業を増やしていく必要があります。

これこそが、当社のエージェント承認ワークフローの根底にある考え方です。AIエージェントは、コードや環境に変更を加える前に、イシューについて把握している内容、採用するアプローチ、実行しようとしている具体的なアクションなど、明確な計画を提示します。必要に応じて再検討もしくは承認するか、指示を出し直すことができます。時間が経つにつれ、AIエージェントが一貫して質の高い作業を行えるようになるため、複雑な作業や重要な業務は引き続き監視しつつ、日常的なタスクについてはAIエージェントにより大きな自律性を与えられるようになります。

コミュニティとカスタマイズ性のために構築されたプラットフォーム

GitLabは常にコミュニティのみなさまからのコントリビュートによって成長してきました。今年はお客様からのコントリビュートが過去最多を記録し、大きな節目の年となりました。オープンフレームワークアプローチを通じて、こうしたコラボレーションの輪にAIエージェントも加われるようになりました。

エージェントプラットフォームでは、GitLabが構築したAIエージェントを利用できるだけでなく、コミュニティ一人ひとりが、それぞれ固有のエンジニアリング上の課題を解決するために専用エージェントを作成できます。エージェントプラットフォームは、特定のコーディング標準の理解、カスタムツールチェーンとの統合、ドメイン固有のタスクの処理など、任せたい作業に応じた専用エージェントを構築するためのビルディングブロックを提供します。

このコミュニティ主導のモデルは、CI/CDカタログと同様、グローバルな連携を通じてGitLabコミュニティの力が発揮される好循環を生み出します。さまざまな実際のユースケースがイノベーションが促進し、企業からのフィードバックが信頼性とセキュリティを保証します。そして、共有されたソリューションはコミュニティ全体に利益をもたらします。GitLabを成功に導いてきたこの協調的なアプローチが、いま、自律型開発という領域にも適用されようとしています。

開始するには

GitLab 18のPremiumおよびUltimateのGitLab.comユーザーライセンスで利用可能になったGitLab Duo Agentic Chatを試された方は、AIエージェントを開発ワークフローに組み込むことで何が実現できるのか、その可能性をすでに実感されていることでしょう。

エージェントプラットフォームの機能や、GitLabが現在取り組んでいる内容については、GitLab 18のリリースイベントの録画ウェブキャストのデモをご覧ください。

エージェントプラットフォームをいち早く使ってみたい方は、エージェントプラットフォームのベータ版のウェイトリストにご登録ください。今年の夏には、さらに多くのチームにご利用いただけるようになる予定です。また、年内に予定されているGitLab 18のリリースを通じて、新たなエージェント機能も順次提供されます。一般公開は、今年の冬を予定しています。

免責事項：この発表には、今後の製品、機能、および機能性に関する情報が含まれています。本発表に含まれる情報は、情報提供のみを目的としている点にご留意ください。購入や計画の際に、この情報のみに依拠することはお控えください。すべてのプロジェクトと同様に、このプレゼンテーションおよびリンク先のページに記載されている項目は、変更または遅れる可能性があります。製品、機能および機能性の開発、リリース、タイミングは、GitLab Inc.の独自の裁量に委ねられます。

詳細はこちら

• バイブコーディングから自律型AIへ：技術リーダー向けのロードマップ
• 自律型AIとは
• DevOpsの自動化とAIエージェント
• AIにより強化されたソフトウェア開発：DevOps向けの自律型AI
• AI主導のコード開発：コードセキュリティの新たな時代

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合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）

新しいgit-diff-pairs(1)コマンド

差分は、すべてのコードレビューの中心となるもので、2つのリビジョン間で行われた すべての変更を表示します。GitLabでは、さまざまな場所で差分が表示されますが、最も 一般的なのはマージリクエストの「変更」タブです。 その裏側では、差分の生成にgit-diff(1)が 使われています。たとえば、以下のように使います。

$ git diff HEAD~1 HEAD

このコマンドは、変更されたすべてのファイルの完全な差分を返します。ただし、リビジョン間で変更されたファイル数が非常に多い場合、スケーラビリティの課題が生じる可能性があります。GitLabのバックエンドでは、コマンドが自己設定されたタイムアウトに達してしまうこともあります。変更数が多い場合、 差分の計算をより小さく扱いやすい単位に分割できる方法があれば、より効果的です。

この課題を解決する1つの方法は、 git-diff-tree(1)を使って、 変更されたすべてのファイルに関する情報を取得することです。

$ git diff-tree -r -M --abbrev HEAD~ HEAD
:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc
:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN

Gitはこの出力を「raw」フォーマットと呼んでいます。 簡単に言えば、出力の各行にはファイルのペアと、 それらの間で何が変更されたかを示すメタデータが表示されます。大規模な変更に対して 「パッチ」形式の出力を生成する方法と比べて、 この処理は比較的高速な上、すべての変更の概要を把握できます。また、このコマンドでは、-Mフラグを付けることでリネーム検出を有効にし、変更がファイルのリネームによるものかどうかを判別することもできます。

この情報を使えば、git-diff(1)を使って各ファイルペアの差分を 個別にコンピューティングすることができます。たとえば、以下のようにblob IDを 直接指定することも可能です。

$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f

この処理は、各ファイルペアごとに繰り返すことができますが、 個別のファイル差分ごとにGitプロセスを立ち上げるのは、あまり効率的ではありません。 さらに、blob IDを使った場合、変更ステータスやファイルモードといった、 親ツリーオブジェクトに格納されているコンテキスト情報が差分から失われてしまいます。 本当に必要なのは、「raw」なファイルペア情報を元に、 対応するパッチ出力を生成する仕組みです。

バージョン2.50から、Gitに新しい組み込みコマンド git-diff-pairs(1)が追加されました。このコマンドは、 標準入力（stdin）から「raw」形式のファイルペア情報を受け取り、どのパッチを出力すべきかを正確に判断します。以下の例は、 このコマンドの使用方法を示しています。

$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z

このように使用した場合、出力結果はgit-diff(1)を使った場合と同じになります。 パッチ出力を生成する専用コマンドを分けることで、 git-diff-tree(1)から得られた「raw」出力を、より小さなファイルペアのバッチに分割し、それぞれを別々の git-diff-pairs(1)プロセスにフィードすることができます。これにより、差分を一度にすべてコンピューティングする必要がなくなるため、 先に挙げたスケーラビリティの課題が解決されます。今後のGitLabリリースでは、 この仕組みの応用により、 特に変更量が多い場合における差分生成のパフォーマンス向上が 期待されます。この変更についての詳細は、該当する メーリングリストのスレッドをご覧ください。

このプロジェクトはJustin Toblerが主導しました。

参照更新の一括処理

Gitには、参照を更新するためのgit-update-ref(1) コマンドが用意されています。このコマンドを--stdinフラグとともに使用すると、 複数の参照を1つのトランザクションとしてまとめて更新できます。 これを行うには、各参照更新の指示を標準入力（stdin）で指定します。 この方法で参照を一括更新すると、アトミックな動作も実現できます。つまり、1つでも参照の更新に失敗した場合、 トランザクション全体が中断され、 どの参照も更新されません。以下は、この動作を示す例です。

# 3つの空のコミットと「foo」という名前のブランチを持つリポジトリを作成する
$ git init
$ git commit --allow-empty -m 1
$ git commit --allow-empty -m 2
$ git commit --allow-empty -m 3
$ git branch foo

# コミットIDを出力する
$ git rev-list HEAD
cf469bdf5436ea1ded57670b5f5a0797f72f1afc
5a74cd330f04b96ce0666af89682d4d7580c354c
5a6b339a8ebffde8c0590553045403dbda831518

# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。
# 指定された古いオブジェクトIDが一致しないため、更新は失敗することが予想されます。
$ git update-ref --stdin <<EOF
> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
fatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c

# 「bar」リファレンスは作成されませんでした。
$ git switch bar
fatal: invalid reference: bar

多くの参照を個別に更新する場合と比べて、一括で更新するほうがはるかに効率的です。 この方法は基本的にうまく機能しますが、 一括更新による効率面のメリットを優先するために、 リクエストされた参照更新の一部が失敗することを許容したい場合も あります。

今回のリリースで、git-update-ref(1)に新しく--batch-updatesオプションが追加されました。 このオプションを使用すると、1つ以上の参照更新が失敗しても、処理を続行できるようになります。 このモードでは、個々の失敗が次の形式で出力されます。

rejected SP (<old-oid> | <old-target>) SP (<new-oid> | <new-target>) SP <rejection-reason> LF

これにより、成功した参照の更新はそのまま進行しつつ、どの更新が拒否されたのか、 またその理由についての情報も得ることができます。前の例と同じリポジトリを 使った例は以下のとおりです。

# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。
$ git update-ref --stdin --batch-updates <<EOF
> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
rejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided

# 「foo」への更新が拒否されたにもかかわらず、「bar」参照が作成されました。
$ git switch bar
Switched to branch 'bar'

今回は--batch-updatesオプションを使用したことで、 更新処理が失敗しても参照の作成は成功しました。この一連のパッチは、 git-fetch(1)やgit-receive-pack(1)における今後の一括参照更新時の パフォーマンス改善の基盤となります。詳細については、該当する メーリングリストのスレッドをご覧ください。

このプロジェクトは、Karthik Nayakが主導しました。

git-cat-file(1)の新しいフィルタオプション

git-cat-file(1)を使うと、 リポジトリ内に含まれるすべてのオブジェクトの情報を --batch–all-objectsオプションで出力できます。たとえば、以下のように実行します。

# シンプルなリポジトリを設定します。
$ git init
$ echo foo >foo
$ git add foo
$ git commit -m init

# 到達不能なオブジェクトを作成します。
$ git commit --amend --no-edit

# git-cat-file(1)を使用して、到達不能なオブジェクトを含むすべてのオブジェクトに関する情報を出力します。
$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
tree 205f6b799e7d5c2524468ca006a0131aa57ecce7
blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99
commit c999f781fd7214b3caab82f560ffd079ddad0115

状況によっては、リポジトリ内のすべてのオブジェクトを検索し、 特定の属性に基づいて一部のオブジェクトだけを出力したい場合があります。 たとえば、コミットオブジェクトだけを表示したいときは、 grep(1)を使って以下のように実行できます。

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

この方法でも目的は達成できますが、出力のフィルタリングには欠点があります。 それは、git-cat-file(1)が ユーザーが関心を持っていないオブジェクトも含め、リポジトリ内のすべてのオブジェクトをたどらなければならない点です。これはかなり非効率です。

今回のリリースでは、git-cat-file(1)に--filterオプションが追加され、 指定した条件に一致するオブジェクトだけを表示できるようになりました。これはgit-rev-list(1)にある同名のオプションと似ていますが、 対応しているフィルターの種類はその一部に限られています。 対応しているフィルターはblob:none、blob:limit=および object:type=です。先ほどの例と同様に、オブジェクトはGitを使用して直接 種類でフィルタリングできます。

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

Gitに処理を任せられるのは便利なだけでなく、オブジェクト数の多い大規模なリポジトリにおいては 効率面のメリットも期待できます。 リポジトリにビットマップインデックスがある場合、 Gitが特定の種類のオブジェクトを効率的に検索できるようになり、パックファイル全体をスキャンする必要がなくなるため、 処理速度が大幅に向上します。 Chromiumリポジトリで行われた ベンチマークでは、こうした最適化による大きな改善が確認されています。

Benchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs
Benchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs
Benchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs
Benchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs
Benchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs
Benchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs
Summary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter ```

興味深いことに、これらの結果からは、処理時間がパックファイル内の総オブジェクト数ではなく、
指定された種類のオブジェクト数に比例して増減することが示されています。
元のメーリングリストのスレッドは、
[こちら](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/)でご覧いただけます。

_このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。_

## バンドル生成時のパフォーマンスが向上

Gitには、指定した参照とそれに関連する到達可能なオブジェクトを含むリポジトリのアーカイブを生成する機能があります。
具体的には、
[`git-bundle(1)`](https://git-scm.com/docs/git-bundle)コマンドを使用します。この操作は、
GitLabがリポジトリのバックアップを作成する際や、
[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムの一部としても使用されます。

何百万もの参照を含む大規模なリポジトリでは、
この操作に数時間から数日かかることもあります。たとえば、GitLabのメインリポジトリ
（[gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)）では、
バックアップに約48時間を要していました。調査の結果、バンドルに重複した参照が含まれないようにチェックする処理において、
パフォーマンスのボトルネックが存在することが判明しました。
この実装では、すべての参照をイテレーションして比較するために入れ子の`for`loopが使われており、
時間計算量はO(N^2)となっていました。これは、
リポジトリ内の参照数が増えるほど、処理性能が大きく低下する構造です。

今回のリリースでは、この問題に対応し、
ネストされたloopをマップ型のデータ構造に置き換えることで、処理速度が大幅に向上しました。以下は、
10万件の参照を含むリポジトリでバンドルを作成した際のパフォーマンス改善を
示すベンチマーク結果です。

```text
Benchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs
Benchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs
Summary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master) ```

詳しくは、
[GitLabがリポジトリのバックアップ時間を48時間から41分に短縮した方法](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)を紹介するブログ記事をご覧ください。
元のメーリングリストのスレッドは
[こちら](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/)でご覧いただけます。

_このプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_

## バンドルURIのアンバンドルの改善

Gitの[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムは、
フェッチするバンドルの場所をクライアントに提供することで、クローンやフェッチの速度を
向上させることを目的としています。クライアントがバンドルをダウンロードすると、
`refs/heads/*`以下の参照が、その関連オブジェクトとともにバンドルから
リポジトリにコピーされます。バンドルには`refs/tags/*`のように
`refs/heads/*`以外の参照も含まれていることがありますが、
これらはクローン時にバンドルURIを使用する場合、単に無視されていました。

Git 2.50ではこの制限が解除され、
ダウンロードされたバンドルに含まれる`refs/*`に一致するすべての参照がコピーされるようになりました。
この機能を実装した[Scott Chacon](https://github.com/schacon)さんは、
[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss)をクローンした際の
挙動の違いを紹介しています。

```shell
$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49
Cloning into 'gl2.49'...
remote: Enumerating objects: 1092703, done.
remote: Counting objects: 100% (973405/973405), done.
remote: Compressing objects: 100% (385827/385827), done.
remote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)
Receiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.
Resolving deltas: 100% (710976/710976), completed with 9081 local objects.
Checking objects: 100% (4194304/4194304), done.
Checking connectivity: 959668, done.
Updating files: 100% (59972/59972), done.

$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50
Cloning into 'gl-2.50'...
remote: Enumerating objects: 65538, done.
remote: Counting objects: 100% (56054/56054), done.
remote: Compressing objects: 100% (28950/28950), done.
remote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)
Receiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.
Resolving deltas: 100% (27401/27401), completed with 8564 local objects.
Updating files: 100% (59972/59972), done.

これらの結果を比較すると、Git 2.50はバンドル展開後に43,887個（40.42 MiB）のオブジェクトをフェッチしているのに対し、 Git 2.49は合計で959,773個（366.94 MiB）のオブジェクトをフェッチしています。 Git 2.50では、取得されるオブジェクト数が約95%、 データ量が約90%削減されており、クライアントとサーバーの双方にとってメリットがあります。 サーバー側ではクライアントに送信するデータ量が大幅に減り、 クライアント側でもダウンロードおよび展開するデータが少なくて済みます。Chaconさんの提供した例では、 これによって処理速度が25%向上しました。

詳細については、 該当するメーリングリストのスレッドをご覧ください。

この一連のパッチは、Scott Chaconさんによって提供されました。

詳細はこちら

本記事でご紹介したのは、最新リリースにおいてGitLabと広範なGitコミュニティによって行われた コントリビュートのごく一部にすぎません。Gitプロジェクトの公式リリースのお知らせでは、 さらに詳しい情報をご覧になれます。また、 以前のGitリリースのブログ記事もぜひご覧ください。GitLabチームメンバーによる過去の主なコントリビュートをご確認いただけます。

こんなとき、「コードレビューのフィードバックを理解し、変更を自動的に実装してくれるAIアシスタントがあればいいのに」と考えたことはないでしょうか？GitLab Duo with Amazon Qはまさにその機能を備えており、開発ワークフローに革新をもたらします。GitLabのDevSecOpsプラットフォームとAmazon Qの高度なAI機能がシームレスに統合し、レビューコメントを読み取り、それをコード変更に直接反映するインテリジェントなアシスタントが誕生しました。フィードバック対応をAIに任せて面倒な手作業から解放され、プロジェクトの全体像に集中しましょう。

GitLab Duo with Amazon Qの仕組み

レビュアーのコメントが含まれるマージリクエストを開くと、コード全体にフィードバックが分散して表示されます。この記事の前半で紹介した例では、フォームのラベルを変更してほしいというリクエストや、フィールドを横並びに表示するよう求める提案、特定のテキストを太字にしてほしいというメモなどが寄せられていました。各コメントは、通常手動で処理する必要があるタスクを表しています。

GitLab Duo with Amazon Qなら、コメントに「/q dev」というクイックアクションを入力するだけで操作は完了します。これによりAmazon Qはすべてのフィードバックを分析し、自動的にコードの変更を開始します。AIエージェントは各コメントの内容を理解し、リクエストされた変更をコードベースで直接実装します。

Amazon Qがフィードバックを処理すると、マージリクエストの「変更」タブにすべての更新内容が表示されます。すべての変更内容が明確に表示されるため、AIエージェントがフィードバックを正確に解釈し、それが実装されたかどうかを把握することが可能です。次に更新されたアプリケーションを実行し、フォームラベルの更新やフィールドの横並び表示、テキストの太字化、ボタンの青色変更など、すべての変更が正しく実装されているかを確認できます。

以下の動画で、コードレビューのフィードバックプロセスを実際にご覧ください。

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

コードレビューのフィードバックの処理はソフトウェア開発において必要な作業ですが、時間と手間がかかります。GitLab Duo with Amazon Qは、これまで手作業で行っていたプロセスを自動化されたワークフローへと進化させ、フィードバックの受け取りから変更実装までの時間を大幅に短縮します。こうした日常的な変更をAIに任せれば、デベロッパーは革新的な機能の構築や、複雑な問題の解決など、本当に重要なことに集中できるようになります。

GitLab Duo with Amazon Qの機能：

• 手動によるフィードバック実装の時間を大幅に削減
• コードレビューサイクルのスピードを加速
• フィードバック対応への一貫性を確保
• コメント確認とコード作成の頭の切り替え負担の軽減
• デプロイ時間を合理化して、機能をより迅速に提供

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

GitLab Duo with Amazon Qのリソース

• GitLab Duo with Amazon Q（AWS向けに最適化された自律型AI）の一般提供を開始
• GitLabとAWSのパートナーページ
• GitLab Duo with Amazon Qに関するドキュメント
• 自律型AIとは？
• 自律型AIに関するガイドとリソース

大規模アップデートや新しい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

最終的に、15年前に作成したGit関数でO(N²)レベルの複雑なアルゴリズムが使われていたのがこの問題の原因であることを突き止め、アルゴリズムを変更して修正したところ、__バックアップ時間が大幅に短縮__されました。その結果、コストの削減、リスクの軽減とともに、コードベースに合わせて実際にスケールするバックアップ戦略を実施できるようになりました。

これは、大規模なリポジトリのユーザーなら誰にでも起こりうるGitのスケーラビリティの問題であることが判明しました。この問題をどのように追跡して修正したかをご説明します。

大規模なバックアップ

まずは、問題について詳しく見ていきましょう。組織においてリポジトリのサイズが大きくなり、バックアップが複雑化するにつれて、以下のような課題が生じる可能性があります。

• 時間がかかるバックアップ：非常にサイズの大きいリポジトリを使用している場合、バックアップの作成に数時間かかる可能性があるため、定期的なバックアップを行うのが難しくなりがちです。
• リソースの集中：長時間のバックアップ処理には大量のサーバーリソースが必要となることがあるため、他のオペレーションに影響を及ぼす可能性があります。
• バックアップの実施期間：24時間体制で業務を行っているチームにとって、このような長時間の処理を行える適切なメンテナンス期間を確保するのは難しい場合があります。
• 失敗するリスクの増大：バックアップ処理に長時間かかると、ネットワークの問題、サーバーの再起動、システムエラーなどによる中断の影響を受けやすくなります。そのため、場合によっては長時間かかるバックアップ処理を最初からやり直さざるを得なくなります。
• 競合状態：バックアップの作成に時間がかかるため、その間にリポジトリが大きく変更される可能性があります。結果として、使用できないバックアップが作成されたり、オブジェクトにアクセスできなくなってバックアップ処理が中断されたりすることがあります。

このような課題によって、バックアップの頻度や完全性を妥協せざるを得なくなる可能性があります。しかしながら、データ保護という観点では妥協すべきではありません。バックアップの実施期間が長くなると、顧客は回避策を取らざるを得なくなることがあります。その場合、外部ツールの導入やバックアップ頻度の削減などが行われますが、結果として、組織全体で一貫したデータ保護戦略を維持できなくなる可能性があります。

では、GitLabがどのような方法でパフォーマンス上のボトルネックを特定し、解決策を見つけ、バックアップ時間を短縮するためにどのように導入したかを詳しく見ていきましょう。

技術的な課題

GitLabのリポジトリバックアップ機能では、git bundle createコマンドを使用しています。このコマンドは、ブランチやタグのようなすべてのオブジェクトと参照を含むリポジトリの完全なスナップショットをキャプチャします。このバンドルは、リポジトリを正確な状態で再作成するための復元ポイントとして機能します。

しかしながら、このコマンドの実装には参照数に関連するスケーラビリティの低さの問題があり、パフォーマンス上のボトルネックとなっていました。リポジトリ内の参照数が増えるにつれて、処理時間が飛躍的に増加していました。当社の一番大きなリポジトリでは数百万個の参照が含まれますが、バックアップ処理に48時間以上かかることもありました。

根本原因分析

そこで、このパフォーマンス上のボトルネックの根本原因を特定するために、実行中のコマンドのフレームグラフを分析しました。

フレームグラフは、スタックトレースを使用してコマンドの実行パスを表示します。各バーはコード内の関数に対応しており、バーの幅はその特定の関数内でコマンドの実行に費やされた時間を示します。

10,000個の参照が含まれるリポジトリで実行されたgit bundle createコマンドのフレームグラフを調べたところ、実行時間の約80%がobject_array_remove_duplicates()関数に費やされていました。この関数は、コミットb2a6d1c686（バンドル：同じ参照を複数回指定できるように許可、2009年1月17日）でGitに導入されたものです。

この変更内容を理解するには、git bundle createを使用すると、バンドルに含める参照を指定できることを把握する必要があります。完全なリポジトリバンドルの場合、--allフラグを指定するとすべての参照がパッケージ化されます。

このコミットは、ユーザーがコマンドラインから重複した参照を指定（例：git bundle create main.bundle main main）すると、重複したmain参照を適切に処理せずにバンドルが作成されてしまうという問題に対処したものでした。Gitリポジトリでこのバンドルをアンバンドルすると、同じ参照を二度書き込もうとするため、壊れてしまいます。そのため、重複回避を目的として、すべての参照で重複の特定処理が繰り返されるようにネストされたforループを用いたコードが実装されました。このようなO(N²)アルゴリズムは、参照数が多いリポジトリではパフォーマンス上の重大なボトルネックとなり、かなりの処理時間がかかっていました。

修正方法：O(N²)アルゴリズムを効率的なマッピングに置き換える

GitLabは、明らかになったパフォーマンスの問題を解決するために、ネストされたループをマップデータ構造に置き換えるアップストリーム修正をGitにコントリビュートしました。これにより、各参照がマップに追加され、各参照の単一のコピーのみが処理目的で自動的に保持されるようになりました。

この変更により、git bundle createのパフォーマンスが劇的に向上し、参照数の多いリポジトリのスケーラビリティが大幅に改善されました。10,000個の参照があるリポジトリでベンチマークテストを行った結果、パフォーマンスが6倍向上することが明らかになりました。

Benchmark 1: bundle (refcount = 100000, revision = master)
  Time (mean ± σ): 	14.653 s ±  0.203 s	[User: 13.940 s, System: 0.762 s]
  Range (min … max):   14.237 s … 14.920 s	10 runs

Benchmark 2: bundle (refcount = 100000, revision = HEAD)
  Time (mean ± σ):  	2.394 s ±  0.023 s	[User: 1.684 s, System: 0.798 s]
  Range (min … max):	2.364 s …  2.425 s	10 runs

Summary
  bundle (refcount = 100000, revision = HEAD) ran
	6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

パッチは承認され、アップストリームのGitにマージされました。GitLabでは、次のGitバージョンがリリースされる前にお客様がすぐに恩恵を受けられるように、この修正をバックポートしました。

結果：バックアップ時間の大幅な短縮に成功

この改善によるパフォーマンスの向上は、まさにこれまでの状況を一変させるものでした。

• バックアップ時間が48時間から41分に短縮：GitLab最大のリポジトリ（gitlab-org/gitlab）のバックアップを従来のわずか1.4%の時間で作成できるようになりました。
• 一貫したパフォーマンスの維持：この修正はリポジトリのサイズに関係なく機能し、安定してスケールします。
• 効率的なリソースの利用：バックアップ処理中のサーバー負荷が大幅に軽減されました。
• 幅広い適用性：もっとも劇的な改善が見られるのはバックアップの作成ですが、多数の参照を処理するすべてのバンドルベースの操作においてメリットがあります。

GitLabを利用するお客様にとってのメリット

GitLabを利用する組織は、この改善によって、リポジトリのバックアップとディザスタリカバリ計画方法に関して、即座に次のような具体的なメリットを得られます。

• バックアップ戦略の変革
  • 企業チームは、開発ワークフローに影響を与えたり、長期にわたるバックアップ期間を確保したりすることなく、夜間に実施する完全バックアップのスケジュールを確立できます。
  • 長期のバックアップ専用の時間を設けなくとも、夜間スケジュール中にバックグラウンドでシームレスに実行できます。
• 事業継続性の向上
  • バックアップ時間が数日から数分に短縮されたことで、組織は回復ポイント目標（RPO）を大幅に最小化できます。これはビジネスリスクの軽減につながります。災害が発生した場合でも、数日かからず、数時間の作業で復旧できる可能性があります。
• 運用負荷の軽減
  • サーバーリソースの消費を抑えられ、メンテナンス期間が短縮されます。
  • バックアップ時間が短縮されるため、コンピューティングコストも削減します。特に処理時間が延びると、コストの増加に直結するクラウド環境においては顕著です。
• 将来にわたって活用できるインフラストラクチャ
  • リポジトリの規模が大きくなっても、バックアップ頻度とシステムパフォーマンスのどちらを優先するか選ぶ必要はもうありません。
  • コードベースの拡大にあわせて、バックアップ戦略もシームレスに拡張できます。

組織は、パフォーマンスや完全性を犠牲にしなくても、より堅牢なバックアップ戦略を実施できるようになりました。以前は難しいトレードオフに直面していたものの、今では簡単な方法で運用できます。

GitLab 18.0のリリース以降、ライセンスプランに関係なく、GitLabをご利用のお客様は全員、ご紹介した改善点を利用してバックアップ戦略の立案および実施を行えるようになりました。設定を変更する必要はもうありません。

今後の展望

今回の革新的な改善は、スケーラブルでエンタープライズグレードなGitインフラの提供に向けた、当社の継続的な取り組みの一環です。バックアップの作成時間が48時間から41分に短縮されたことは重要なマイルストーンとなりましたが、引き続きスタック全体においてパフォーマンス上のボトルネックを特定し、対処しています。

今回の改善をGitのアップストリームプロジェクトにコントリビュートでき、GitLabユーザーだけでなく、広範なGitコミュニティにメリットをもたらせたことを特に誇りに思っています。このような協調的なアプローチにより、改善に対する徹底的なレビューおよび幅広いテストの実施が行われ、誰もがそのメリットを得られるようになります。

GitLabではパフォーマンスを最適化するために、このような深いレベルでインフラに取り組んでいます。ぜひGitLab 18のオンラインリリースイベントにご参加ください。ほかにどのような根本的な機能強化が行われたかをご紹介します。今すぐご登録ください！

目次

• 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