[{"data":1,"prerenderedAt":767},["ShallowReactive",2],{"/ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation":3,"navigation-ja-jp":44,"banner-ja-jp":443,"footer-ja-jp":453,"blog-post-authors-ja-jp-Sandra Gittlen":659,"blog-related-posts-ja-jp-ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation":675,"assessment-promotions-ja-jp":720,"next-steps-ja-jp":758},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":30,"isFeatured":12,"meta":31,"navigation":12,"path":32,"publishedDate":20,"seo":33,"stem":39,"tagSlugs":40,"__hash__":43},"blogPosts/ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","Ultimate Guide To Ci Cd Fundamentals To Advanced Implementation",[7],"sandra-gittlen",null,"devsecops",{"slug":11,"featured":12,"template":13},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",true,"BlogPost",{"heroImage":15,"body":16,"authors":17,"updatedDate":19,"date":20,"title":21,"tags":22,"description":29,"category":9},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","継続的インテグレーション／継続的デリバリー（[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)）によって、ソフトウェアチームがユーザー向けに価値を生み出す方法は大きく変わりました。手動によるデプロイやインテグレーションに煩わされていた時代は過ぎ去り、最新の開発においては自動化、信頼性、そしてスピードが求められています。\n\nCI/CDの本質は、開発環境から本番環境にいたるまでコードが自動的かつ信頼性高く実行され、リアルタイムでフィードバックを取り入れるシームレスなパイプラインを作成することです。[CI](https://about.gitlab.com/ja-jp/topics/ci-cd/benefits-continuous-integration/)の目的は、コードの変更を頻繁に共有リポジトリにマージし、自動的にテストし検証することで、問題解決に伴う余分なコストが生じる前にチームが問題を早期に発見できるようにすることです。[CD](https://about.gitlab.com/ja-jp/topics/ci-cd/#what-is-continuous-delivery-cd)はこれをさらに発展させ、デプロイプロセスを自動化することで、リリースを予測可能でストレスなく行えるようにします。\n\nソフトウェア開発において手作業のプロセスや複雑なツールチェーンに頼るのではなく、堅牢なCI/CDパイプラインを使用してソフトウェアをビルド、テスト、デプロイできます。また、AIによってプロセスの効率化をさらに進め、品質、コンプライアンス、セキュリティチェックの一貫性を保ちながら、CI/CDパイプラインを自動的に設計することが可能になります。\n\nこのガイドでは、基本原則からベストプラクティス、高度な戦略まで、最新のCI/CDパイプラインに関する内容を説明します。また、先進企業がCI/CDをどのように使用して効果的に成果をあげているかについても取り上げます。このガイドでご紹介する内容は、DevSecOps環境をスケールし、[アジャイル](https://about.gitlab.com/ja-jp/topics/ci-cd/continuous-integration-agile/)で自動化された効率的な方法でソフトウェアを開発し、デリバリーする上で役立ちます。\n\nご紹介する内容：\n- 継続的インテグレーションとは\n- 継続的なデリバリーとは\n- ソースコード管理とCI/CDの関係\n- 現代のソフトウェア開発においてCI/CDを利用するメリット\n  - CI/CDと従来の開発の主な相違点\n- CI/CDの基礎を理解する\n  - CI/CDパイプラインとは\n- CI/CDの実装と管理のベストプラクティス\n  - CIのベストプラクティス\n  - CDのベストプラクティス\n- CI/CDの開始方法\n- セキュリティ、コンプライアンス、CI/CD\n- CI/CDとクラウド\n- 高度なCI/CD\n  - CI/CDにおける再利用と自動化\n  - AIによるパイプラインのトラブルシューティング\n- GitLab CI/CDへの移行方法\n- 大手企業から学ぶ教訓\n- CI/CDのチュートリアル\n\n## 継続的インテグレーションとは\n\n[継続的インテグレーション](https://about.gitlab.com/ja-jp/topics/ci-cd/benefits-continuous-integration/)（CI）とは、すべてのコード変更を共有ソースコードリポジトリのmainブランチに早い段階で頻繁に統合し、コミットまたはマージ時に変更内容を自動的にテストし、自動的にビルドを開始する手法のことです。継続的インテグレーションを行うことで、チームはエラーやセキュリティの問題を開発プロセスの初期段階で簡単に特定し、修正できます。\n\n## 継続的デリバリーとは\n[継続的デリバリー](https://about.gitlab.com/ja-jp/topics/ci-cd/#what-is-continuous-delivery-cd)（CD）は、「*継続的デプロイ*」と呼ばれることもあります。継続的デリバリーを行うことで、組織はアプリケーションを自動的にデプロイできるため、デベロッパーがデプロイ状況のモニタリングと成功の確認に専念できる時間を増やすことができます。継続的デリバリーでは、DevSecOpsチームが事前にコードのリリース基準を設定します。その基準が満たされて検証が完了すると、本番環境にコードがデプロイされます。これにより組織は俊敏性を高め、新機能をもっと迅速にユーザーに提供できるようになります。\n\n## ソースコード管理とCI/CDの関係\n\nソースコード管理（[SCM](https://about.gitlab.com/ja-jp/solutions/source-code-management/)）とCI/CDは、現代のソフトウェア開発手法の基盤と言えます。[Git](https://about.gitlab.com/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/)のようなSCMシステムは、変更の追跡、コードの各バージョンの管理、チームメンバー間のコラボレーションをスムーズに連携させる一元的な仕組みになっています。デベロッパーは新機能やバグ修正に取り組む際に、メインコードベースからブランチを作成して変更を加え、[マージリクエスト経由で変更をマージ](https://docs.gitlab.com/ee/user/project/merge_requests/)します。このようなブランチ戦略により、複数のデベロッパーが互いのコードに干渉することなく同時に作業を進められるだけでなく、常に本番環境で使用可能なコードが含まれる、安定したmainブランチを維持できます。\n\nCI/CDは、SCMシステムで管理されているコードを取得し、変更がプッシュされるたびに自動的にビルド、テスト、および検証を行います。デベロッパーがコードの変更を提出すると、CI/CDシステムは自動的に最新のコードを取得し、既存のコードベースに追加して、一連の自動チェックを実行します。これには通常、コードのコンパイル、ユニットテストの実行、静的コード解析の実施、コードカバレッジのチェックが含まれます。これらのステップのいずれかが失敗すると、すぐにチームに通知されます。チームが迅速に問題に対処できるため、他のデベロッパーへの影響を最小限に抑え本番環境への問題流出も防ぐことができます。このようなソース管理と継続的インテグレーションの緊密な連携により、フィードバックループが自動化され、従来の手動テストでは発見が遅れがちだった問題も早期に捉えられるようになり、コードの品質を維持できます。\n\n## 現代のソフトウェア開発においてCI/CDを利用するメリット\n\n新機能やバグ修正の提供に伴う時間とリスクを大幅に削減する[CI/CDは、現代のソフトウェア開発に革新的なメリットをもたらします](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/)。継続的なフィードバックループにより、DevSecOpsチームには、変更がコードベース全体と照らし合わせて自動的に検証されることが保証されます。結果として、ソフトウェアの品質の向上、デリバリーの高速化の実現に加え、リリースの頻度も増加するため、ユーザーのニーズや市場の需要に素早く対応できるようになります。\n\n最も重要なメリットはおそらく、CI/CDによってソフトウェア開発チーム内でコラボレーションと透明性の文化が育まれることです。誰もがビルド、テスト、デプロイの状況をリアルタイムで確認できれば、デリバリープロセスにおけるボトルネックの特定や解決が容易になります。また、CI/CDによって実現される自動化により、デベロッパーの認知負荷が軽減されます。そのため、デプロイプロセスを手動で管理する必要がなくなり、コーディング作業に注力できるようになります。その結果、デベロッパーの満足度と生産性が向上するとともに、これまでソフトウェアのリリースプロセス全体において生じていたリスクも減少します。迅速なコードレビューがCI/CDプロセスの標準プロセスとなり、必要に応じて素早く変更をロールバックできることをチームが理解しているため、より自由に実験を行うことができ、イノベーションと継続的な改善が促進されます。\n\n> GitLab CI/CDの利用を開始しましょう。[GitLab Ultimate](https://about.gitlab.com/ja-jp/free-trial/devsecops/)に登録して、AI搭載のDevSecOpsプラットフォームを無料でお試しください。\n\n### CI/CDと従来の開発の主な相違点\n\nCI/CDは、以下のような点で従来のソフトウェア開発とは異なります。\n\n**頻繁なコードコミット**\n\n大抵の場合、デベロッパーは単独で作業することが多く、コードをメインコードベースにアップロードする頻度が低いことから、マージの競合を始めとして、時間のかかる問題が発生しがちです。CI/CDの場合、デベロッパーは一日の中で頻繁にコミットをプッシュするため、競合を早いうちに発見でき、コードベースを最新の状態に保つことができます。\n\n**リスクの低減**\n\n長いテストサイクルとリリース前に行う大規模なプランニング作業は、従来のソフトウェア開発の特徴と言えます。リスクを最小化する目的で行われるものの、結果として問題の発見と修正の迅速さが犠牲になることも少なくありません。CI/CDでは、簡単に元に戻せる小規模の変更を段階的に適用し、注意深くモニタリングする方法でリスクを管理します。\n\n**継続的に実施される自動テスト**\n\n従来のソフトウェア開発では、開発が完了したタイミングでテストを行います。しかし、このやり方だと、納期の遅れやコストのかかるバグ修正などの問題が生じます。 CI/CDでは、コードをコミットするたびに自動テストが実行され、開発工程全体を通じて継続的にテストが行われます。さらに、デベロッパーにはタイムリーにフィードバックが提供されるため、それをもとに素早く対処できます。\n\n**繰り返し頻繁に実施可能で、自動化されたデプロイプロセス**\n\nCI/CDでは、デプロイプロセスは自動化されるため、大規模なソフトウェアのロールアウトに伴うストレスと手間が軽減されます。複数の環境で同じデプロイプロセスを繰り返し実行できるため、作業時間の短縮に加え、エラーや不整合を削減できます。\n\n## CI/CDの基礎を理解する\n\nCI/CDは、スケーラブルで保守しやすいデリバリープロセスを構築するためのフレームワークとして機能します。そのため、DevSecOpsチームが核となる概念をしっかりと把握しておくことは非常に重要です。CI/CDの原則を十分に理解することで、チームは従来のアプローチに縛られずに、テクノロジーの進化に合わせて戦略と手法を適応させることができます。ここでは、基本的な内容をいくつかご紹介します。\n\n### CI/CDパイプラインとは\n\n[CI/CDパイプライン](https://about.gitlab.com/ja-jp/topics/ci-cd/cicd-pipeline/)とは、ビルド、テスト、デプロイなどの一連のステップから成り、ソフトウェアデリバリープロセスを自動化および効率化するものです。[各ステージは品質ゲートとして機能し](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/)、検証されていないコードが次のステージに進むことのないように防ぎます。初期ステージでは通常、コンパイルやユニットテストなどの基本的なチェックを行います。後のほうのステージではインテグレーションテストやパフォーマンステスト、コンプライアンステストに加え、さまざまな環境への段階的なデプロイを行う場合があります。\n\n本番環境へのデプロイ前などの重要なタイミングでは、手動による承認を必要とするようにパイプラインを設定できます。その一方で、ルーチンタスクは自動化し、変更の健全性に関するフィードバックを迅速にデベロッパーに提供することが可能です。このような体系的なアプローチにより、一貫性の保証、ヒューマンエラーの削減の実現に加え、コード変更が開発環境から本番環境にどのように移行したかを明確に追跡できます。最新のパイプラインはコードとして実装されることが多いため、アプリケーションコードと同様に、バージョン管理、テスト、保守を行えます。\n\nCI/CDに関連する重要な用語をご紹介します。\n\n- **コミット**：コードの変更\n- **ジョブ**：Runnerが実行すべき命令\n- **Runner**：個々のジョブを実行するエージェントやサーバーで、必要に応じて起動または停止できる\n- **ステージ**：「ビルド」や「デプロイ」といった特定のジョブステージを定義するキーワード。同じステージにあるジョブは同時に実行される。プロジェクトのルートレベルでバージョン管理されたYAMLファイル（`.gitlab-ci.yml`）を使用して、パイプラインの設定を行う\n\n![CI/CDパイプラインの図](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673928/Blog/Content%20Images/1690824533476.png)\n\n## CI/CDの実装と管理のベストプラクティス\nCI/CDの実装によりどれだけ成功を収められるかどうかは、どの[ベストプラクティス](https://about.gitlab.com/ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices/)を取り入れるかに大きく依存します。\n\n#### CIのベストプラクティス\n\n* コミットを早めかつ頻繁に行う\n* パイプラインステージを最適化する\n* ビルドを迅速かつシンプルに\n* 失敗を活かしてプロセスを改善する\n* 必ず本番環境を模したテスト環境を構築する\n\n#### CDのベストプラクティス\n\n* 現状からはじめる。いつでもイテレーションを行える\n* 最小限のツールで最適な継続的デリバリーを行えることを理解する\n* 問題やマージリクエストが制御不能ならないよう、何が起きているかを追跡する\n* 自動化によってユーザー受け入れテストとステージングを効率化する\n* 自動化を通じてリリースパイプラインを管理する\n\n> ### ブックマークに登録しましょう！\n>\n>ぜひ[「CI/CD入門」ウェビナー](https://www.youtube.com/watch?v=BhmF29sUc48)をご視聴ください。\n>\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/BhmF29sUc48?si=vGF8wNdhyQof9aFC\" 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>\u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n## CI/CDの開始方法\n\nCI/CDを導入する際は、まずはパイロットプロジェクトとして、シンプルながら代表的なプロジェクトを選定する必要があります。基本的なテスト要件を備えた、シンプルなアプリケーションが最適です。そうすれば、複雑なデプロイシナリオに対処せずに済み、パイプラインの仕組みを学ぶことに集中できます。まずは、コードが[バージョン管理](https://about.gitlab.com/ja-jp/topics/version-control/)されており、[基本的な自動テスト](https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci/)（ユニットテストだけでも十分です）が設定されているかどうかを確認してください。理解度が深まるにつれて徐々に拡張できるように、[最小限のパイプラインを作成する](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/)ことを目指します。\n\nGitLabでは、具体的には、プロジェクトのルートディレクトリに`.gitlab-ci.yml`ファイルを作成することから始めます。このYAMLファイルでは、パイプラインのステージ（ビルド、テスト、デプロイなどの基本的なもの）とジョブを定義します。\nシンプルなパイプラインの場合、\nビルドステージではコードをコンパイルしてアーティファクトを作成\nテストステージではユニットテストを実行\nデプロイステージではアプリケーションをステージング環境にプッシュする\nといった構成になります。\nGitLabはこのファイルを自動的に検出し、リポジトリに変更がプッシュされるたびにパイプラインの実行を開始します。GitLabプラットフォームには、パイプラインジョブを実行する[ビルトインのRunner](https://docs.gitlab.com/runner/)が用意されていますが、より細かく制御したい場合はご自身でRunnerを設定することも可能です。\n\n基本に慣れてきたら、少しずつより高度なコンポーネントをパイプラインに追加していきます。コード品質チェック、[セキュリティスキャン](https://docs.gitlab.com/ee/user/application_security/#security-scanning)、本番環境への自動デプロイなどを実装してみてもよいかもしれません。GitLabのDevSecOpsプラットフォームには、[コンプライアンス管理](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)、[デプロイ変数](https://about.gitlab.com/blog/demystifying-ci-cd-variables/)、手動での承認ゲートなど、パイプラインの成熟に伴って組み込むことができる機能が含まれます。パイプラインの実行時間に注意しつつ、可能であれば並行してジョブを実行できる箇所を探しましょう。必ず適切なエラー処理と通知を追加して、パイプラインが失敗した場合にチームメンバーに速やかに通知されるようにします。一般的な問題が生じたり、解決策が見つかったりしたら、文書化するようにしましょう。ドキュメントはチーム規模が拡大するにつれ非常に役に立ちます。\n\n> ### CI/CDの開始方法についてさらに詳しく知りたい場合は、[GitLab Universityで無料のCI/CDコース](https://university.gitlab.com/courses/gitlab-with-git-essentials-s2-jp)にご登録ください\n\n## セキュリティ、コンプライアンス、CI/CD\nCI/CDを利用する最大のメリットの1つは、ソフトウェア開発ライフサイクルの早い段階において頻繁にセキュリティとコンプライアンスのチェックを組み込めることです。GitLabでは、`.gitlab-ci.yml`での設定を用いて、最初のコードコミットから本番環境へのデプロイまで複数のステージでセキュリティスキャンを自動的にトリガーすることができます。GitLabプラットフォームのコンテナスキャン、依存関係スキャン、セキュリティスキャン機能（[動的アプリケーションセキュリティテスト](https://docs.gitlab.com/ee/user/application_security/dast/)および[高度なSAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/)）は、コードが変更されるたびに自動的に実行され、脆弱性、コンプライアンス違反、セキュリティの設定ミスの有無をチェックするように設定できます。また、GitLabプラットフォームのAPIを使用すると、[外部のセキュリティツールとの連携も可能です](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)。テストカバレッジ機能は、セキュリティテストが必要な基準を満たしているかを確認できます。\n\nGitLabのセキュリティテストレポートでは、調査結果に関する詳細情報を確認できるため、セキュリティ問題が本番環境に到達する前に素早く修正できます。プロジェクト全体における脆弱性は、セキュリティダッシュボードで一元的に確認でき、[セキュリティポリシーの適用](https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/)は、マージリクエストの承認とパイプラインゲートによって行えます。さらに、CI/CDプロセス全体で機密情報を保護するための多層的なシークレット管理、シークレットへのアクセスを追跡するための監査ログ、許可されたユーザのみが機密性の高い設定データを閲覧または変更できるようにするロールベースのアクセス制御（RBAC）などの機能も備えています。\n\nGitLabはソフトウェア部品表（[SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)）の生成もサポートしています。チームは、アプリケーション内のすべてのソフトウェアコンポーネント、依存関係、ライセンスの包括的なインベントリを生成して、脆弱性を迅速に特定して対応し、規制要件に準拠することが可能です。\n## CI/CDとクラウド\n\nGitLabのCI/CDプラットフォームは、[Amazon Web Services](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)や[Google Cloud Platform](https://about.gitlab.com/blog/provision-group-runners-with-google-cloud-platform-and-gitlab-ci/)、[Microsoft Azure](https://docs.gitlab.com/ee/install/azure/)などの主要クラウドプロバイダーとの強力なインテグレーションが可能なため、パイプラインから直接クラウドへのデプロイを自動化することができます。GitLabのクラウド連携機能を使用すれば、クラウドリソースの管理、アプリケーションのデプロイ、クラウドサービスのモニタリングをすべてGitLabインターフェイス内で行えます。GitLabに標準搭載されているクラウドデプロイテンプレートと[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/)機能により、クラウドデプロイの手間が大幅に軽減されるため、チームはインフラ管理よりもアプリケーション開発に注力できます。GitOpsを使用してITインフラストラクチャを自動化したい組織向けに、GitLabでは[Flux CDインテグレーションも提供しています](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/)。\n\nGitLabのクラウド機能は、基本的なデプロイの自動化にとどまりません。GitLabプラットフォームの[Kubernetesインテグレーション](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/)を使用すると、複数のクラウドプロバイダー間でコンテナオーケストレーションを管理できます。また、[クラウドネイティブのGitLabインストールオプション](https://about.gitlab.com/ja-jp/topics/ci-cd/cloud-native-continuous-integration/)が用意されているため、クラウド環境でプラットフォーム自体を実行することも可能です。GitLabのクラウドネイティブ機能により、チームはパイプライン実行用にクラウドリソースを動的にプロビジョニングする自動スケーリングランナーを実装して、コストとパフォーマンスを最適化できます。GitLabプラットフォームとクラウドプロバイダーのセキュリティサービスとのインテグレーションにより、デプロイプロセス全体を通してセキュリティとコンプライアンスの要件が確実に満たされます。\n\nGitLabはマルチクラウド環境向けには、基盤となるクラウドプロバイダーに関係なく一貫したワークフローとツールを提供します。開発環境、ステージング環境、本番環境でそれぞれ異なるクラウド設定を管理したい場合もGitLabの環境管理機能で対応可能です。GitLabプラットフォームによる[infrastructure as code](https://docs.gitlab.com/ee/user/infrastructure/iac/)のサポート、特にTerraformとのネイティブなインテグレーションにより、チームは、クラウドインフラストラクチャのプロビジョニングをバージョン管理し自動化できます。GitLabのモニタリングと可観測性の機能は、クラウドプロバイダーのメトリクスと連携しているため、ク\n\n## 高度なCI/CD\nCI/CDは、単純なビルドとデプロイのパイプラインからはるかに進化を遂げてきました。CI/CDを高度に実装する場合、自動テスト、セキュリティスキャン、インフラストラクチャのプロビジョニング、AI活用など、高度なオーケストレーションが必要となります。ここでは、アーキテクチャが複雑化していく中でも、エンジニアリングチームがパイプラインをスケールし、問題をトラブルシューティングする際に役立つ高度なCI/CD戦略をいくつかご紹介します。\n\n### CI/CDにおける再利用と自動化\n\nGitLabは、開発チームによるCI/CDパイプラインの作成・管理方法を2つの革新的な機能で一新しています。一つは「[CI/CDカタログ](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)」、もう一つは「[CI/CDステップ](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/)」（現在、実験段階にあるDevSecOps自動化のための新しいプログラミング言語）です。CI/CDカタログは、デベロッパーがCI/CDコンポーネントを検索、再利用、コントリビュートできる一元化されたプラットフォームです。コンポーネントは、CI/CDワークフローにおける「レゴブロック」のような再利用可能な単機能パーツとして、パイプライン設定を簡素化します。また、CI/CDステップは、デベロッパーがCI/CDジョブの入出力を設定できるようにすることで、複雑なワークフローをサポートします。DevSecOpsチームはCI/CDカタログとCI/CDステップを活用することで、CI/CDとそのコンポーネントを簡単に標準化すると同時に、CI/CDパイプラインの開発と保守のプロセスを簡素化できます。\n\n> 詳しくは、[CI/CDカタログのFAQ](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)と[CI/CDステップのドキュメント](https://docs.gitlab.com/ee/ci/steps/)をご覧ください。\n\n### AIによるパイプラインのトラブルシューティング\n\nCI/CDパイプラインが壊れることは実際にあり得ますが、問題を素早くトラブルシューティングすれば、影響を最小限にとどめられます。GitLabが提供するAI機能「GitLab Duo」の一つである「根本原因分析」は、これまでデベロッパーの経験や勘に頼っていた部分を自動化し、[CI/CDパイプラインで発生した失敗の根本原因を特定](https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/)します。GitLabでは、パイプラインが失敗すると、失敗した場所と原因を具体的に示す詳細なジョブログ、エラーメッセージ、実行トレースが提供されます。その後、根本原因分析により、AIを使用して修正を提案します。 以下の動画で、GitLab Duo根本原因分析機能の実際の動作をご覧ください。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n## GitLab CI/CDへの移行方法\n\nDevSecOpsプラットフォームとビルトインのCI/CDに移行する際は、既存のパイプライン設定や依存関係、デプロイプロセスを分析し、GitLabの対応する機能と構文にマッピングする体系的なアプローチを取る必要があります。移行プロセスを開始する際は、以下のガイドをご参照ください。\n\n* [BambooからGitLab CI/CDへの移行方法](https://about.gitlab.com/blog/migrating-from-bamboo-to-gitlab-cicd/)（英語）\n* [JenkinsからGitLabへ：CI/CD環境のモダナイズに関する完全ガイド](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)（英語）\n* [GitHubからGitLabへの簡単な移行方法](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)（英語）\n\n## 先進企業から学ぶ教訓\n\nGitLab に移行し、CI/CD の様々なメリットを実感している先進企業の事例をご紹介します。各社の事例をぜひご覧ください。\n\n- [ロッキード・マーティン社](https://about.gitlab.com/ja-jp/customers/lockheed-martin/)\n- [Indeed社](https://about.gitlab.com/ja-jp/blog/how-indeed-transformed-its-ci-platform-with-gitlab/)\n- [CARFAX社](https://about.gitlab.com/ja-jp/customers/carfax/)\n- [HackerOne社](https://about.gitlab.com/ja-jp/customers/hackerone/)\n- [Betstudios社](https://about.gitlab.com/blog/betstudios-cto-on-improving-ci-cd-capabilities-with-gitlab-premium/)\n- [タレス社とカルフール社](https://about.gitlab.com/blog/how-carrefour-and-thales-are-evolving-their-ci-cd-platforms/)\n\n## CI/CDのチュートリアル\n\n以下にご紹介する簡単なチュートリアルを行って、CI/CDのエキスパートになりましょう。\n\n* * [CI入門：ジョブを順番どおりに、並列に、または順不同で実行する方法](https://about.gitlab.com/ja-jp/blog/basics-of-gitlab-ci-updated/)\n* [初めてのGitLab CI/CDコンポーネントのセットアップ方法](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)（英語）\n* [モノレポ用にGitLab CI/CDパイプラインを簡単に構築する方法](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)（英語）\n* [子パイプラインの使用による5つの環境への継続的デプロイメント](https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/)（英語）\n* [CI/CDの自動化：GitLabグループ全体で「デプロイフリーズ」の影響を最大化する](https://about.gitlab.com/blog/ci-cd-automation-maximize-deploy-freeze-impact-across-gitlab-groups/)（英語）\n* [CI/CDテンプレートをCI/CDコンポーネントにリファクタリングする](https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component/)（英語）\n* [GitLab CI/CDでCosignを使ってコンテナイメージにビルドの来歴を付ける](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd/)（英語）\n\n> #### GitLab CI/CDの利用を開始しましょう。[GitLab Ultimateに登録](https://gitlab.com/-/trials/new)して、AI搭載のDevSecOpsプラットフォームを無料でお試しください。\n\n\u003Cbr>\u003Cbr>\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[18],"Sandra Gittlen","2026-03-03","2025-01-06","GitLab CI/CD完全ガイド【2026年版】：基礎から本番運用まで",[23,24,25,26,27,28],"CI/CD","DevSecOps","DevSecOps platform","tutorial","security","product","パイプラインの開発、デリバリー、セキュリティまでを自動化した継続的インテグレーションおよび継続的デプロイの最新手法をご紹介します。","yml",{},"/ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"ogTitle":34,"ogImage":15,"ogDescription":29,"ogSiteName":35,"noIndex":36,"ogType":37,"ogUrl":38,"title":21,"canonicalUrls":38,"description":29},"CI/CD完全ガイド：基礎から高度な実装まで","https://about.gitlab.com",false,"article","https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation","ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",[41,9,42,26,27,28],"cicd","devsecops-platform","PjjYCVSWjZsUiHYuGUxhaAaJHPQ2osqXI3sVaOcWPNc",{"data":45},{"logo":46,"freeTrial":51,"sales":56,"login":61,"items":66,"search":373,"minimal":406,"duo":423,"pricingDeployment":433},{"config":47},{"href":48,"dataGaName":49,"dataGaLocation":50},"/ja-jp/","gitlab logo","header",{"text":52,"config":53},"無料トライアルを開始",{"href":54,"dataGaName":55,"dataGaLocation":50},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":57,"config":58},"お問い合わせ",{"href":59,"dataGaName":60,"dataGaLocation":50},"/ja-jp/sales/","sales",{"text":62,"config":63},"サインイン",{"href":64,"dataGaName":65,"dataGaLocation":50},"https://gitlab.com/users/sign_in/","sign in",[67,94,189,194,295,355],{"text":68,"config":69,"cards":71},"プラットフォーム",{"dataNavLevelOne":70},"platform",[72,78,86],{"title":68,"description":73,"link":74},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":75,"config":76},"プラットフォームを詳しく見る",{"href":77,"dataGaName":70,"dataGaLocation":50},"/ja-jp/platform/",{"title":79,"description":80,"link":81},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":82,"config":83},"GitLab Duoのご紹介",{"href":84,"dataGaName":85,"dataGaLocation":50},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":87,"description":88,"link":89},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":90,"config":91},"詳細はこちら",{"href":92,"dataGaName":93,"dataGaLocation":50},"/ja-jp/why-gitlab/","why gitlab",{"text":95,"left":12,"config":96,"link":98,"lists":102,"footer":171},"製品",{"dataNavLevelOne":97},"solutions",{"text":99,"config":100},"すべてのソリューションを表示",{"href":101,"dataGaName":97,"dataGaLocation":50},"/ja-jp/solutions/",[103,127,149],{"title":104,"description":105,"link":106,"items":111},"自動化","CI/CDと自動化でデプロイを加速",{"config":107},{"icon":108,"href":109,"dataGaName":110,"dataGaLocation":50},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[112,115,118,123],{"text":23,"config":113},{"href":114,"dataGaLocation":50,"dataGaName":23},"/ja-jp/solutions/continuous-integration/",{"text":79,"config":116},{"href":84,"dataGaLocation":50,"dataGaName":117},"gitlab duo agent platform - product menu",{"text":119,"config":120},"ソースコード管理",{"href":121,"dataGaLocation":50,"dataGaName":122},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"自動化されたソフトウェアデリバリー",{"href":109,"dataGaLocation":50,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":50,"icon":134},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"Application Security Testing",{"href":132,"dataGaName":139,"dataGaLocation":50},"Application security testing",{"text":141,"config":142},"ソフトウェアサプライチェーンの安全性",{"href":143,"dataGaLocation":50,"dataGaName":144},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":146,"dataGaLocation":50},"/ja-jp/solutions/software-compliance/",{"title":150,"link":151,"items":156},"測定",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":50},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"可視性と測定",{"href":154,"dataGaLocation":50,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"バリューストリーム管理",{"href":164,"dataGaLocation":50,"dataGaName":165},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"分析とインサイト",{"href":169,"dataGaLocation":50,"dataGaName":170},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLabが活躍する場所",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":50,"dataGaName":178},"/ja-jp/enterprise/","enterprise",{"text":180,"config":181},"スモールビジネス",{"href":182,"dataGaLocation":50,"dataGaName":183},"/ja-jp/small-business/","small business",{"text":185,"config":186},"公共機関",{"href":187,"dataGaLocation":50,"dataGaName":188},"/ja-jp/solutions/public-sector/","public sector",{"text":190,"config":191},"価格",{"href":192,"dataGaName":193,"dataGaLocation":50,"dataNavLevelOne":193},"/ja-jp/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":282},"関連リソース",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"すべてのリソースを表示",{"href":201,"dataGaName":197,"dataGaLocation":50},"/ja-jp/resources/",[203,236,254],{"title":204,"items":205},"はじめに",[206,211,216,221,226,231],{"text":207,"config":208},"インストール",{"href":209,"dataGaName":210,"dataGaLocation":50},"/ja-jp/install/","install",{"text":212,"config":213},"クイックスタートガイド",{"href":214,"dataGaName":215,"dataGaLocation":50},"/ja-jp/get-started/","quick setup checklists",{"text":217,"config":218},"学ぶ",{"href":219,"dataGaLocation":50,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"製品ドキュメント",{"href":224,"dataGaName":225,"dataGaLocation":50},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"ベストプラクティスビデオ",{"href":229,"dataGaName":230,"dataGaLocation":50},"/ja-jp/getting-started-videos/","best practice videos",{"text":232,"config":233},"インテグレーション",{"href":234,"dataGaName":235,"dataGaLocation":50},"/ja-jp/integrations/","integrations",{"title":237,"items":238},"検索する",[239,244,249],{"text":240,"config":241},"お客様成功事例",{"href":242,"dataGaName":243,"dataGaLocation":50},"/ja-jp/customers/","customer success stories",{"text":245,"config":246},"ブログ",{"href":247,"dataGaName":248,"dataGaLocation":50},"/ja-jp/blog/","blog",{"text":250,"config":251},"リモート",{"href":252,"dataGaName":253,"dataGaLocation":50},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":255,"items":256},"つなげる",[257,262,267,272,277],{"text":258,"config":259},"GitLabサービス",{"href":260,"dataGaName":261,"dataGaLocation":50},"/ja-jp/services/","services",{"text":263,"config":264},"コミュニティ",{"href":265,"dataGaName":266,"dataGaLocation":50},"/community/","community",{"text":268,"config":269},"フォーラム",{"href":270,"dataGaName":271,"dataGaLocation":50},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"イベント",{"href":275,"dataGaName":276,"dataGaLocation":50},"/events/","events",{"text":278,"config":279},"パートナー",{"href":280,"dataGaName":281,"dataGaLocation":50},"/ja-jp/partners/","partners",{"backgroundColor":283,"textColor":284,"text":285,"image":286,"link":290},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":287,"config":288},"ソースプロモカード",{"src":289},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":291,"config":292},"最新情報を読む",{"href":293,"dataGaName":294,"dataGaLocation":50},"/ja-jp/the-source/","the source",{"text":296,"config":297,"lists":299},"会社情報",{"dataNavLevelOne":298},"company",[300],{"items":301},[302,307,313,315,320,325,330,335,340,345,350],{"text":303,"config":304},"GitLabについて",{"href":305,"dataGaName":306,"dataGaLocation":50},"/ja-jp/company/","about",{"text":308,"config":309,"footerGa":312},"採用情報",{"href":310,"dataGaName":311,"dataGaLocation":50},"/jobs/","jobs",{"dataGaName":311},{"text":273,"config":314},{"href":275,"dataGaName":276,"dataGaLocation":50},{"text":316,"config":317},"経営陣",{"href":318,"dataGaName":319,"dataGaLocation":50},"/company/team/e-group/","leadership",{"text":321,"config":322},"チーム",{"href":323,"dataGaName":324,"dataGaLocation":50},"/company/team/","team",{"text":326,"config":327},"ハンドブック",{"href":328,"dataGaName":329,"dataGaLocation":50},"https://handbook.gitlab.com/","handbook",{"text":331,"config":332},"投資家向け情報",{"href":333,"dataGaName":334,"dataGaLocation":50},"https://ir.gitlab.com/","investor relations",{"text":336,"config":337},"トラストセンター",{"href":338,"dataGaName":339,"dataGaLocation":50},"/ja-jp/security/","trust center",{"text":341,"config":342},"AI Transparency Center",{"href":343,"dataGaName":344,"dataGaLocation":50},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":346,"config":347},"ニュースレター",{"href":348,"dataGaName":349,"dataGaLocation":50},"/company/contact/#contact-forms","newsletter",{"text":351,"config":352},"プレス",{"href":353,"dataGaName":354,"dataGaLocation":50},"/press/","press",{"text":57,"config":356,"lists":357},{"dataNavLevelOne":298},[358],{"items":359},[360,363,368],{"text":57,"config":361},{"href":59,"dataGaName":362,"dataGaLocation":50},"talk to sales",{"text":364,"config":365},"サポートポータル",{"href":366,"dataGaName":367,"dataGaLocation":50},"https://support.gitlab.com","support portal",{"text":369,"config":370},"カスタマーポータル",{"href":371,"dataGaName":372,"dataGaLocation":50},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":374,"login":375,"suggestions":382},"閉じる",{"text":376,"link":377},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":378,"config":379},"GitLab.com",{"href":64,"dataGaName":380,"dataGaLocation":381},"search login","search",{"text":383,"default":384},"提案",[385,387,392,394,398,402],{"text":79,"config":386},{"href":84,"dataGaName":79,"dataGaLocation":381},{"text":388,"config":389},"コード提案（AI）",{"href":390,"dataGaName":391,"dataGaLocation":381},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":23,"config":393},{"href":114,"dataGaName":23,"dataGaLocation":381},{"text":395,"config":396},"GitLab on AWS",{"href":397,"dataGaName":395,"dataGaLocation":381},"/ja-jp/partners/technology-partners/aws/",{"text":399,"config":400},"GitLab on Google Cloud",{"href":401,"dataGaName":399,"dataGaLocation":381},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":403,"config":404},"GitLabを選ぶ理由",{"href":92,"dataGaName":405,"dataGaLocation":381},"Why GitLab?",{"freeTrial":407,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":52,"config":408},{"href":409,"dataGaName":55,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"GitLabアイコン",{"src":414,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":204,"config":420},{"href":421,"dataGaName":422,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/compare/gitlab-vs-github/","get started",{"freeTrial":424,"mobileIcon":429,"desktopIcon":431},{"text":425,"config":426},"GitLab Duoの詳細について",{"href":427,"dataGaName":428,"dataGaLocation":410},"/ja-jp/gitlab-duo/","gitlab duo",{"altText":412,"config":430},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":432},{"src":418,"dataGaName":415,"dataGaLocation":410},{"freeTrial":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"料金ページに戻る",{"href":192,"dataGaName":437,"dataGaLocation":410,"icon":438},"back to pricing","GoBack",{"altText":412,"config":440},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":442},{"src":418,"dataGaName":415,"dataGaLocation":410},{"title":444,"button":445,"config":450},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":446,"config":447},"GitLab Transcendを今すぐ視聴",{"href":448,"dataGaName":449,"dataGaLocation":50},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":451,"icon":452},"release","AiStar",{"data":454},{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":651},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":457,"config":458},"ページのソースを表示",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"このページを編集",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"ご協力をお願いします",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,555,585,620],{"title":68,"links":479,"subMenu":484},[480],{"text":481,"config":482},"DevSecOpsプラットフォーム",{"href":77,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":190,"links":486},[487,491,496],{"text":488,"config":489},"プランの表示",{"href":192,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Premiumを選ぶ理由",{"href":494,"dataGaName":495,"dataGaLocation":461},"/ja-jp/pricing/premium/","why premium",{"text":497,"config":498},"Ultimateを選ぶ理由",{"href":499,"dataGaName":500,"dataGaLocation":461},"/ja-jp/pricing/ultimate/","why ultimate",{"title":502,"links":503},"ソリューション",[504,509,512,514,519,524,528,531,534,539,541,543,545,550],{"text":505,"config":506},"デジタルトランスフォーメーション",{"href":507,"dataGaName":508,"dataGaLocation":461},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":510,"config":511},"セキュリティとコンプライアンス",{"href":132,"dataGaName":139,"dataGaLocation":461},{"text":124,"config":513},{"href":109,"dataGaName":110,"dataGaLocation":461},{"text":515,"config":516},"アジャイル開発",{"href":517,"dataGaName":518,"dataGaLocation":461},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"クラウドトランスフォーメーション",{"href":522,"dataGaName":523,"dataGaLocation":461},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":121,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":23,"config":529},{"href":114,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":162,"config":532},{"href":164,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/ja-jp/solutions/gitops/","gitops",{"text":175,"config":540},{"href":177,"dataGaName":178,"dataGaLocation":461},{"text":180,"config":542},{"href":182,"dataGaName":183,"dataGaLocation":461},{"text":185,"config":544},{"href":187,"dataGaName":188,"dataGaLocation":461},{"text":546,"config":547},"教育",{"href":548,"dataGaName":549,"dataGaLocation":461},"/ja-jp/solutions/education/","education",{"text":551,"config":552},"金融サービス",{"href":553,"dataGaName":554,"dataGaLocation":461},"/ja-jp/solutions/finance/","financial services",{"title":195,"links":556},[557,559,561,563,566,568,571,573,575,577,579,581,583],{"text":207,"config":558},{"href":209,"dataGaName":210,"dataGaLocation":461},{"text":212,"config":560},{"href":214,"dataGaName":215,"dataGaLocation":461},{"text":217,"config":562},{"href":219,"dataGaName":220,"dataGaLocation":461},{"text":222,"config":564},{"href":224,"dataGaName":565,"dataGaLocation":461},"docs",{"text":245,"config":567},{"href":247,"dataGaName":248},{"text":569,"config":570},"お客様の成功事例",{"href":242,"dataGaLocation":461},{"text":240,"config":572},{"href":242,"dataGaName":243,"dataGaLocation":461},{"text":250,"config":574},{"href":252,"dataGaName":253,"dataGaLocation":461},{"text":258,"config":576},{"href":260,"dataGaName":261,"dataGaLocation":461},{"text":263,"config":578},{"href":265,"dataGaName":266,"dataGaLocation":461},{"text":268,"config":580},{"href":270,"dataGaName":271,"dataGaLocation":461},{"text":273,"config":582},{"href":275,"dataGaName":276,"dataGaLocation":461},{"text":278,"config":584},{"href":280,"dataGaName":281,"dataGaLocation":461},{"title":586,"links":587},"Company",[588,590,592,594,596,598,600,604,609,611,613,615],{"text":303,"config":589},{"href":305,"dataGaName":298,"dataGaLocation":461},{"text":308,"config":591},{"href":310,"dataGaName":311,"dataGaLocation":461},{"text":316,"config":593},{"href":318,"dataGaName":319,"dataGaLocation":461},{"text":321,"config":595},{"href":323,"dataGaName":324,"dataGaLocation":461},{"text":326,"config":597},{"href":328,"dataGaName":329,"dataGaLocation":461},{"text":331,"config":599},{"href":333,"dataGaName":334,"dataGaLocation":461},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":461},"/sustainability/",{"text":605,"config":606},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":607,"dataGaName":608,"dataGaLocation":461},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":610},{"href":338,"dataGaName":339,"dataGaLocation":461},{"text":346,"config":612},{"href":348,"dataGaName":349,"dataGaLocation":461},{"text":351,"config":614},{"href":353,"dataGaName":354,"dataGaLocation":461},{"text":616,"config":617},"現代奴隷制の透明性に関する声明",{"href":618,"dataGaName":619,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":57,"links":621},[622,624,629,631,636,641,646],{"text":57,"config":623},{"href":59,"dataGaName":60,"dataGaLocation":461},{"text":625,"config":626},"サポートを受ける",{"href":627,"dataGaName":628,"dataGaLocation":461},"/support/","get help",{"text":369,"config":630},{"href":371,"dataGaName":372,"dataGaLocation":461},{"text":632,"config":633},"ステータス",{"href":634,"dataGaName":635,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":637,"config":638},"利用規約",{"href":639,"dataGaName":640,"dataGaLocation":461},"/terms/","terms of use",{"text":642,"config":643},"プライバシーに関する声明",{"href":644,"dataGaName":645,"dataGaLocation":461},"/ja-jp/privacy/","privacy statement",{"text":647,"config":648},"Cookieの設定",{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":461},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":461},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":12},[660],{"id":661,"title":18,"body":8,"config":662,"content":664,"description":8,"extension":30,"meta":670,"navigation":12,"path":671,"seo":672,"stem":673,"__hash__":674},"blogAuthors/en-us/blog/authors/sandra-gittlen.yml",{"template":663},"BlogAuthor",{"role":665,"name":18,"config":666},"Managing Editor, GitLab Blog",{"headshot":667,"linkedin":668,"ctfId":669},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659648/Blog/Author%20Headshots/Sgittlen-headshot.jpg","https://www.linkedin.com/in/sandra-gittlen-48557a294/","sgittlen",{},"/en-us/blog/authors/sandra-gittlen",{},"en-us/blog/authors/sandra-gittlen","Y1hpWIa-4iLRjGVQU7Rsuo7D3zGggeSoWHEaLRZQ104",[676,692,708],{"content":677,"config":690},{"heroImage":678,"body":679,"authors":680,"updatedDate":682,"date":683,"title":684,"tags":685,"description":689,"category":9},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1770082992/ll61ekf2lcgogkgay69j.jpg","*2026年2月5日追記：本文内に東レ様の事例を追加しました。*\n\n2025年11月に開催した年次イベント「GitLab Epic Tour Japan 2025」の模様をお伝えします。\n\n> 【期間限定！動画で見る】GitLab Epic Tour Japan 2025 オンデマンド配信は[こちら](https://www.event-site.info/gitlab-epic-conference-japan-2025/?r=eventreport)\n\nGitLabは2025年11月28日、都内で年次イベントで「GitLab Epic Tour Japan 2025 〜AI駆動ソフトウェア開発の攻めと守り〜」を開催しました。生成AIの登場により、ソフトウェア開発の現場は大きな変化にさらされることになりました。コード生成AIを活用して生産性向上を狙う「攻め」については、すでに多くの開発者が取り組んでいます。一方、AIが生成したコードの脆弱性をどうすべきかという「守り」の重要性が、かつてないほど高まっています。この日のイベントでは、AI時代の開発プラットフォームのあり方、そして日本企業が直面する課題への具体的な処方箋を示しました。本稿では、主要セッションの内容を中心に、イベントの全容をレポートします。\n\n## **「DevSecOps認知度30%」の数年後に、AI Native時代がやってきた**\n\n![「DevSecOps認知度30%」の数年後に、AI Native時代がやってきた](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770083035/sp4llxhmbx2kcawgexyp.jpg \"GitLab合同会社 Japan Country Manager 小澤 正治\")\n\nオープニングセッションでは、GitLab Japan Country manager小澤 正治がご挨拶させていただきました。小澤は2年半前の入社当時を振り返り、次のように語ります。\n\n「当時、経済産業省のレポートを読むと、国内の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の認知度はわずか30%でした。正直、どうしようかと震えていたのですが、状況は大きく変わりました。この変化にワクワクしています」\n\nこの2年半で、GitLab自身も大きく進化しました。当時は単に「[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/) Platform」でしたが、AI要素を付加した「AI Powered」が枕詞になりました。そして現在は、「AI Native [DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/) Platform」です。つまり、GitLabそのものがAIを中核に据えたプラットフォームへと成長したと言えます。\n\n![「DevSecOps認知度30%」の数年後に、AI Native時代がやってきた](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770083037/z1vvb6yuqznqlpe9nukf.jpg \"GitLab合同会社 Staff Regional Marketing Manager 川口 修平\")\n\n続いて登壇したStaff Regional Marketing Manager 川口 修平は、AI導入により開発者1人あたり年間120万円相当の工数を削減でき、その結果として日本の経済効果が約1兆6000億円に上るという試算を[紹介](https://japanese-developer-survey.about.gitlab-review.app/ja-jp/developer-survey/japan/)。ただし、AI活用に立ちはだかる困難を、「3つの壁」として提示しました。\n\nまずは、技術的負債の壁。レガシーコードやドキュメント不足が、AIのコンテキスト理解を妨げています。続いて、セキュリティリスクの壁。 AI生成コードの約45%に脆弱性が含まれるというデータがあり、インシデントを防ぐ防災に加えて、被害を最小限にする減災の考え方も不可欠になります。最後に、人材の壁。エンジニアの役割はコードを書くことから、AIの成果物が正しいかどうかを評価することへシフトします。\n\nこれらの課題を解決するカギになるのが、[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)（以下、DAP）です。開発サイクル上のすべての情報を単一データストアへと集約することで、AIがコンテキストを深く理解し、精度が高く、かつ自律的な支援が可能になります。\n\n## **「Prompt to Production」の危険性と、自律型AIエージェントの未来**\n\n![「Prompt to Production」の危険性と、自律型AIエージェントの未来](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770083038/ydpympgpv51g0tncpw7j.jpg \"GitLab CTO Asia Pacific & Japan Andrew Haschka\")\n\n続いて登壇したGitLab CTO Asia Pacific & Japan Andrew Haschka氏は、アジア太平洋地域のリーダーたちとの対話から得た知見をに基づき、AI活用の次のステージについて語りました。\n\nHaschkaは、「AIを正しく機能させるためには、開発の全工程を網羅した“信頼できる唯一の情報源”が不可欠です」と強調します。現在、多くの企業は開発現場にAIを導入していますが、その用途は「AIコーディング」に偏りすぎています。しかしながら、計画、テスト、セキュリティといった周辺プロセスにも、AIによる最適化の余地があるのです。\n\n「私は、ガバナンスがない状態で、バラバラのAIツールを使うことをPrompt to Productionと呼び、危険視しています。テストやセキュリティチェックをスキップし、プロンプトの結果をいきなり本番環境へ反映してしまうリスクがあるためです」（Haschka）\n\nこの問題を解決するのが、[DAP](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)と[Agentic Flows](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/)。人間がAIに質問して答えを得るチャットボット形式とは一線を画す概念で、1人の人間が多数のAIエージェントを指揮します。すると、エージェント同士が連携し、計画から実装、テストまでを自律的な流れとして実行することになります。\n\nHaschkaは、「GitLabのAIエージェントは、組織のポリシーというガードレールの下で動きます。だからこそ、リスクを最小限に抑えながらイノベーションを加速できるのです」と話します。「AIは、開発者のためにコードを書いてくれるだけでなく、チームメンバーとして一緒に働いてくれる存在になります」。\n\nAIツールをバラバラに使う段階は終わりました。すでに、統合プラットフォーム上でAIを“良き同僚”として迎え入れる環境は整っています。\n\n## **3つの壁を突破する具体的アプローチ**\n\n![3つの壁を突破する具体的アプローチ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770083038/gazgh2phoxeiglbzsutt.jpg \"GitLab合同会社 ソリューションアーキテクト 本部長 藤田 周\")\n\n続いて、ソリューションアーキテクト 本部長 藤田 周が登壇しました。藤田は、オープニングで提示された3つの壁に対する、より実践的で技術的な解決策を深掘りしました。\n\n技術的負債の壁は、リアーキテクチャで乗り越えます。古いシステムを単にクラウドに乗せ換える「リホスト」や、すべてを作り直す「リビルド」は、コストの面でも効果の面で現実的にならないケースが目につきます。そこで藤田は、生成AIを活用した「リアーキテクチャ」を提唱します。\n\n具体的には、まずレガシーコードをAIに読み込ませ、人間にとってもAIにとっても理解しやすい「マークダウン形式の設計書」を出力。ブラックボックス化した仕様を可視化した上で、モダンなコードとテストケースをAIに生成させるというアプローチを取ります。これにより、手のつけられなかった旧来のシステムが、最新のアーキテクチャ上で以前と同様の機能を提供してくれるようになります。\n\nセキュリティリスクの壁は、スピードがカギを握ることになります。巷間、「脆弱性が公開されてから攻撃が始まるまで、わずか15分」という数字が語られていますが、これは現実です。攻撃を受けてから人間が会議を開き、パッチ適用の計画を立てている間に、攻撃者はすでに侵入を開始しているのです。\n\n藤田はデモを通じて、GitLabの[Security Analyst Agent](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)がこのスピードに対抗できることを示しました。AIエージェントが膨大な脆弱性情報の中から誤検知を取り除き、自動で対応すべき優先順位を付け、さらに修正コードまで作成してくれます。人間はAIの提案を確認してマージボタンを押すだけです。藤田は、「精神論や手動チェックではもう守りきれないのです」と語りました。\n\n人材の壁をクリアする第一歩は、伴走支援のエコシステムを構成することです。エンジニアに求められるスキルセットが変化する中、何らかのツールを導入したり、担当者のスキルアップを図るだけでは、解決策になりません。藤田氏は、専門性の高いパートナー企業による伴走支援の重要性について話し、GitLabをプラットフォームとして開発プロセスを最適化すると同時に、優れたパートナー企業をプロセスに取り込み、さらに組織変革をセットで進めます。その際に、パートナー企業が組織変革についてもサポートしてくれれば理想でしょう。\n\n藤田は講演の中で、[DAP](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)による開発の自律化についても紹介しました。AIが先回りして動いてくれる一例が「Issue to MR」です。AIがイシューを読み、計画を立て、コードを書き、マージリクエストまで作成します。また、人間がレビューする前にAIがセキュリティや規約チェックを行う機能により、人間の負荷を劇的に下げることができます。これら一連の仕組みは、プロジェクト全体のコンテキストをAIが理解することで支えられています。\n\n## **4社の最新事例発表も実施**\n\n![4社の最新事例発表も実施](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770083239/nilg9jbd5b6p6epbybqw.jpg \"お客様の講演\")\n\nこの日のイベントでは、ピクシブ株式会社様、東レ株式会社様、日立グループ様（株式会社日立プラントサービス様、株式会社日立システムズ様）、株式会社みんなの銀行様（登壇順）の4社のユーザー企業様がご登壇され、それぞれの挑戦についてご共有いただきました。各社の取り組みについては、以下のリンクよりご覧ください。\n\n・[株式会社みんなの銀行様](https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-minna-no-ginko/)\n\n・[東レ株式会社様](https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-toray/)　**NEW！**\n\n・[ピクシブ株式会社様](https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-pixiv/)  **NEW!**\n\n・日立グループ様（株式会社日立プラントサービス様、株式会社日立システムズ様）**（近日公開予定）**\n\n## **次は1年後。きっと大きな変化が起きているはず**\n\n![次は1年後。きっと大きな変化が起きているはず](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770083054/p39lvxa768ifqlezd4jw.jpg \"会場の様子\")\n\nクロージングセッションに再登壇した小澤は、部分最適の罠について強調しました。AIを活用することで特定の作業やプロセスが高速化したとしても、それが故に別の場所にボトルネックが生まれることになっては意味がありません。全体最適を目指すことが大切で、そのためにGitLabが持つシングルデータストアという基盤が効いてくることになります。\n\nさらに、GitLabが講演した内容と発表された事例を総括し、「かつてDevOpsはSecurityを加えて[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)になりました。それがいまや完全に[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)として一体のものとして認識されています。その上で、AI活用が進んでいるのです」と話します。GitLabのAI Native DevSecOpsも、テクノロジーの通過点であり、さらに最適化された未来が待っているのでしょう。\n\n2026年の秋にもまた、GitLabは「Epic Tour Japan」を実施します。\n\n小澤は、「1年先は近いようで遠いです。いまはまだ読めない変化が起きているはずです。しかし、GitLabも世の中のニーズに合わせて柔軟に進化していきます。来年のこのイベントで、これから生まれる新しい事例を皆様にお伝えできることにワクワクしています」と結び、今年のEpic Tourは盛況のうちに幕を閉じました。",[681],"GitLab Japan Team","2026-02-17","2026-02-03","AI駆動ソフトウェア開発の攻めと守り【GitLab Epic Tour Japan 2025レポート】",[686,687,24,27,688],"AI/ML","customers","user stories","2025年11月に開催した年次イベント「GitLab Epic Tour Japan 2025」の模様をご紹介。",{"featured":12,"template":13,"slug":691},"event-report-epic-tokyo-2025",{"content":693,"config":706},{"heroImage":694,"body":695,"authors":696,"updatedDate":699,"date":700,"title":701,"tags":702,"description":705,"category":9},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1766026372/vmnafxuxmxwzevccjzjz.jpg","***編集部注：私たちは時折、パートナーコミュニティのメンバーにGitLabブログへの寄稿をお願いしています。今回は、サイオステクノロジー株式会社の西下容史氏に寄稿いただきました。***\\\n\\\n***当ブログは、GitLabを運用されている方を対象にしています。開発の中核を担うGitLabは、何らかの障害（例えばサーバーの停止やGitLab自体の停止など）が原因で止まってしまうと、開発業務に大きな影響が出てしまいます。このためGitLabには「止まらない仕組み」が求められています。***\\\n***このブログでは、GitLabの止まらない仕組みを、直感的なGUIが用意されたHAクラスター製品による冗長化構成で実現する方法が紹介されています。***\n\n## **開発を止めないために：GitLabの冗長化を考える**\n\n### GitLabの停止が開発チームに与える影響\n\nGitLabをSelf-Managed版で運用されている企業のインフラ担当者やDevOpsエンジニアの皆さん、GitLabの可用性について不安を感じたことはありませんか？\n\n特に金融系・公共系企業では、セキュリティやコンプライアンスの観点から自社環境でGitLabを運用するケースが増えています。しかし、GitLabが障害で停止してしまうと、開発チーム全体の業務が止まり、システムやサービスのリリースに遅れが発生するなど、ビジネスへの影響は計り知れません。\n\nバージョン管理、CI/CD、課題管理といった開発の中核を担うGitLabだからこそ、「止まらない仕組み」が求められています。\n\n### HAクラスター構成による高可用性の実現\n\nこのような課題に対する有効な解決策が、HAクラスター構成によるGitLabの冗長化です。稼働系と待機系のノードを用意し、障害発生時には自動的に切り替えることで、最小限のダウンタイムでサービスを継続できます。\n\n本記事では、世界で9万ライセンス以上の導入実績を持つHAクラスター製品「LifeKeeper for Linux」を使用した、GitLabの冗長化構成を具体的にご紹介します。Amazon EC2環境でのAZ跨ぎ構成を例に、データ共有の仕組み、障害監視とフェイルオーバーの自動化、そして直感的なGUI操作による管理方法まで、実際の検証結果に基づいて解説していきます。\n\n開発を止めないインフラ基盤の構築を検討されている方は、ぜひ最後までお読みください。\n\n## GitLabとは：開発基盤に求められる高可用性\n\nGitLabは、分散型バージョン管理システムの「Git」を利用したDevSecOpsプラットフォームであり、世界中で多くの企業に採用されています。ファイルのバージョン管理、課題管理、CI/CDパイプラインなど、ソフトウェア開発に必要な機能を統合的に提供します。\n\n## GitLabが停止したときの影響\n\n### GitLab停止時の影響範囲\n\nGitLabが停止すると、以下のような影響が即座に発生します：\n\n\\- **開発作業の停止**: コードのプッシュ・プル、マージリクエストのレビューができなくなる\n\n* **CI/CDの停止**: ビルド、テスト、デプロイといった自動化ワークフローが機能しなくなる\n* **コラボレーションの遮断**: 課題管理やプロジェクト管理機能が使えず、チーム間の連携が途絶える\n* **緊急対応の不可**: 本番環境のバグフィックスやセキュリティパッチ適用ができない\n\n停止時間が数時間に及べば開発計画が大幅に狂い、1日以上の停止は経営層への報告事項となる深刻なビジネスインパクトをもたらします。\n\n### Self-Managed版GitLabにおける冗長化の必要性\n\nGitLabには、SaaS版とSelf-Managed版の2つが提供されています。Self-Managed版は自社で用意した環境（IaaSやオンプレミス）にセットアップして利用するため、可用性の担保は利用者側の責任となります。\n\n特に開発チームの規模が大きい場合や、ミッションクリティカルなシステム開発を行っている場合は、障害発生を前提とした冗長化構成が不可欠です。予め待機系ノードを用意しておき、障害発生時には自動的に稼働系から待機系に切り替えることで、最小限のダウンタイムでの復旧が実現できます。\n\n## 冗長化を実現する技術要素\n\nGitLabの停止リスクに対する有効な解決策が、HAクラスター構成による冗長化です。ここでは、高可用性を実現するための技術要素と、その中核を担う「LifeKeeper for Linux」について解説します。\n\n### HAクラスター構成の基本的な考え方\n\nHAクラスター構成では、稼働系（Active）と待機系（Standby）の2つのノードを用意します。通常時は稼働系でGitLabが動作し、障害が発生した際には自動的に待機系へ切り替わることで、サービスの継続性を確保します。\n\nこの仕組みにより、ハードウェア障害やソフトウェア障害が発生しても、数分程度のダウンタイムでGitLabを復旧できます。重要なのは、待機系が常にスタンバイ状態にあり、稼働系のデータをリアルタイムで同期していることです。これにより、切り替え時にもデータの一貫性が保たれ、開発者は障害発生前とほぼ同じ状態で作業を継続できます。\n\n### LifeKeeper for Linuxとは\n\nLifeKeeper for Linuxは、サイオステクノロジーが提供するHAクラスター製品で、全世界で9万ライセンス以上の導入実績を持つ信頼性の高いソリューションです。Linux環境におけるアプリケーションの高可用性を実現するために設計されており、GitLabのような重要なDevSecOpsプラットフォームの保護に最適です。\n\nLifeKeeperの大きな特徴は、アプリケーションレベルでの可用性担保を実現できる点です。単にサーバーの冗長化を行うだけでなく、GitLabというアプリケーション自体を監視し、異常を検知した際には自動的にフェイルオーバーを実行します。\n\n### 冗長化構成を支える3つの技術要素\n\nLifeKeeperによる冗長化構成は、以下の3つの技術要素で構成されています。\n\n#### 1. データ同期とレプリケーション\n\nLifeKeeperの製品ラインナップである「DataKeeper」は、ローカルディスク（Amazon EC2環境ではEBS）をブロックレベルでリアルタイム同期します。これにより、共有ストレージを使用せずに論理的な共有ディスクを実現できます。稼働系で発生したデータの変更は即座に待機系へ反映されるため、フェイルオーバー時にもデータの整合性が保たれます。\n\n#### 2. 多層的な障害監視\n\nLifeKeeperは2種類の障害監視を並行して実行します。1つ目は、クラスターノード間の相互ハートビート通信によるノード自体の障害監視です。2つ目は、稼働系で動作するGitLabなどのソフトウェアの障害監視です。この多層的な監視により、ハードウェア障害とソフトウェア障害の両方を確実に検知できます。\n\n#### 3. 自動フェイルオーバー機能\n\n障害を検知すると、LifeKeeperは自動的にフェイルオーバーを実行します。待機系ノードでGitLabを起動し、アクセス経路を切り替えることで、サービスを継続します。この一連のプロセスは自動化されているため、深夜や休日に障害が発生した場合でも、管理者の手動介入なしに復旧が完了します。\n\n### 自動フェイルオーバーがもたらすメリット\n\n自動フェイルオーバーの最大のメリットは、復旧時間の短縮です。手動での復旧作業では、障害の検知、原因の特定、復旧手順の実行に多くの時間がかかりますが、自動フェイルオーバーであれば数分以内に復旧が完了します。\\\nまた、人的ミスのリスクも排除できます。緊急時の手動作業では、手順の誤りや設定ミスが発生しがちですが、事前に設定された自動プロセスであれば、確実かつ一貫した復旧が可能です。\\\nさらに、24時間365日の監視体制を人的リソースだけで維持するのは困難ですが、自動フェイルオーバーがあれば、深夜や休日でもシステムが自律的に障害対応を行います。これにより、運用担当者の負担を大幅に軽減できます。\n\n### クラウド環境での冗長化にも対応\n\nLifeKeeperは、Amazon EC2などのクラウド環境での冗長化にも対応しています。標準機能として「Recovery Kit for Route53」や「Recovery Kit for EC2」が提供されており、クラウド特有のネットワーク構成にも柔軟に対応できます。これにより、オンプレミス環境だけでなく、IaaSを利用したSelf-Managed版GitLabの冗長化も実現可能です。\n\n## GitLabのHAクラスター構成\n\nそれでは、LifeKeeper for Linuxを使ってどのようにGitLabを冗長化するのかを見てみましょう。\n\n今回当社では、Amazon EC2環境でAZを跨いだ冗長化構成を検証しました。下記の図は検証構成の概念図です。\n\n![GitLabのHAクラスター構成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767660747/qdiodwqpg0bgjreswrnf.jpg)\n\n管理クライアントからはRoute53による名前解決でActive側のクラスターノードへのアクセスを実現しています。LifeKeeper for Linuxの標準機能の「Recovery Kit for EC2」を使うことで、スクリプト開発を行わずにGUI上でクラスターのアクセス制御を容易に設定できます。\\\n\\[参考]\\\n今回の検証ではElastic IPによる制御による名前解決を使用しましたが、LifeKeeperは製品の標準機能で下記の方式に対応しています。\\\n[→『LifeKeeper』によるAmazon EC2の冗長化構成の例](https://bccs.sios.jp/usecases/aws.html)\n\n* Recovery Kit for Route53：Route53の名前解決およびクラスターの切り替わり時にAレコードを書き換えて、名前解決した実IPに向けて通信する方式  \n* Recovery Kit for EC2：\n\n\n  - Elastic IPをActiveノードのENIに割り当てることで、外部からActiveノードへの接続を可能にする方式\n  \n  - CIDRの外を指す仮想IPに向けて通信し、クラスターの切り替わり時にルートテーブルの送信先が仮想IPのターゲットを書き換えて通信する方式\n\n\n### データ共有\n\n前述の通り、クラスターノード間のデータ共有には「DataKeeper」を使用しています。本検証では、EBSをブロックレベルでリアルタイム同期することで、論理的な共有ディスクを実現しました。\n\n## 障害監視とフェイルオーバー\n\nLifeKeeperは下記の2種類の障害監視を並行して行っており、障害が検知されると自動的に待機系に切り替え（フェイルオーバー）て復旧を実現します。\n\n1. 相互のハートビート通信によるノードの障害の監視  \n2. Active側の監視対象のソフトウェアの障害の監視\n\n上記の2.については、今回の検証ではQSP（Quick Service Protection）という機能を使っています。QSPはserviceのstatus/stop/startを使って簡易的にソフトウェアを監視や切り替えて保護できる機能です。\\\n\\[参考]\\\n今回の検証ではソフトウェアの保護にQSPを使用しましたが、LifeKeeperは他に下記の2つの方式に対応しています。\n\n* Application Recovery Kit：SIOSが開発した制御スクリプトのラインナップを使う方式  \n* Generic ARK：ユーザーが開発した制御スクリプトをLifeKeeperに組み込んで使う方式\n\n## 直感的な操作を実現するWebGUI\n\nLifeKeeperには直感的な操作を実現するWebGUIが標準機能として提供されています。GitLabのプログラムやファイルシステムなど、各保護対象をクラスターリソースとして登録し、依存関係（起動や停止させる時に他のクラスターリソースを道連れにするかしないか）もツリー構造で直感的かつ効率的に設定できます。\n\n＜クラスターの切り替え前＞\n\n![直感的な操作を実現するWebGUI - クラスターの切り替え前](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767661178/riengalkhmlzhdy1dx4r.jpg)\n\n＜クラスターの切り替え後＞\n\n![直感的な操作を実現するWebGUI - クラスターの切り替え後](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767661364/fo4sjpey107bgsztwijp.jpg)\n\n手順の詳細はぜひ検証レポートをご覧ください。下記からダウンロード頂けます。\n\nhttps://mk.sios.jp/lifekeeper-gitlab-report_l\n\n## まとめとHAクラスター製品「LifeKeeper」について\n\nここまでご覧頂きました通り、開発の中核を担うGitLabには「止まらない仕組み」が求められています。このためには、GitLabの障害を自動的に検知・復旧し、安定した運用が求められます。こうした冗長化構成を、直感的なWebのGUI上で容易に構築できるのが「LifeKeeper」なのです。\n\n「LifeKeeper」は、サイオステクノロジーが提供する全世界で9万ライセンス以上の導入実績があるHAクラスター製品です。「LifeKeeper」を導入することで、アプリケーションレベルでの可用性担保の実現に加えて、データレプリケーション製品の「DataKeeper」と組み合わせることで共有ストレージを使用せずクラウド上でシステムを冗長化させ、システム全体の可用性が高められます。\\\n詳細情報は、\u003Chttps://bccs.sios.jp/lifekeeper/> をご覧ください。\n\n> ### *サイオステクノロジーについて*\n>\n> *サイオステクノロジーは、Linuxに代表されるオープンソースソフトウェアを活用したシステムインテグレーションを原点とし、自社開発ソフトウェアおよびSaaSの販売とサービスを行っています。直近では、クラウドをはじめとするDXの技術領域に注力し、AIの活用支援や次世代を支える製品とサービスを提供しています。これからも革新的なソフトウェア技術を追求し、世界のIT産業に影響力のある存在となって価値を創造し、社会の発展に貢献してまいります。*\\\n> *詳細情報は、\u003Chttps://sios.jp> をご覧ください。*",[697,698],"Tsukasa Komatsubara","Hiroshi Nishishita, SIOS Technology, Inc.","2026-01-07","2025-12-19","GitLabを少ない工数で冗長化して安定運用を実現する ～HAクラスターソフトウェア「LifeKeeper」による冗長化～",[703,235,281,704],"cloud native","production","この記事では、GitLabの止まらない仕組みを、直感的なGUIが用意されたHAクラスター製品による冗長化構成で実現する方法をご紹介します。",{"featured":36,"template":13,"slug":707},"gitlab-high-availability-with-lifekeeper-hacluster",{"content":709,"config":718},{"category":9,"body":710,"date":711,"authors":712,"heroImage":713,"title":714,"description":715,"tags":716},"GitLabは2025年10月、パシフィコ横浜で開催された「Gartner IT Symposium/Xpo™ 2025」に出展しました。初日のセッションでは、オリンパス株式会社R&Dセンターオブ ソフトウエアエクセレンス グローバルバイスプレジデント 児玉 達弘氏をお招きし、社 内のGitLab浸透とAI活用についてインタビュー形式でお話しいただきました。聞き手は当社カントリーマネージャー 小澤 正治が務めました。本記事では、その模様をお伝えします。 \n\n## AI導入を他業界より慎重に進めていたことが、むしろチャンスにつながった\n\n![AI導入を他業界より慎重に進めていたことが、むしろチャンスにつながった](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783041/pm0s0p6gfethidu8yb9k.jpg)\n\n*オリンパス株式会社 R&Dセンターオブソフトウエアエクセレンス グ ローバルバイスプレジデント 児玉 達弘氏*\n\n児玉氏は、モバイル業界や自動車業界で様々な開発をリードし、現在はオリンパスのグローバルなソフトウエア開発をリードする立場です。同社のグローバル拠点は約40あり、各国・地域で医療機器業界に特有の厳格な法規制を遵守して開発を進める必要があります。\n\nこういった厳しい規制により、医療機器業界は新しい技術を採用するにあたって他業界より慎重に対応しながら、時間をかけて導入をする必要があります。ソフトウエア開発におけるAI活用でも同様です。しかし、児玉氏は「AIでは、こういった状況がむしろチャンスにつながりました」と話します。\n\n![図：オリンパスにおけるAI活用](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765975635/m7lyrb00rw0zd0owaz6d.jpg)\n\n*図：オリンパスにおけるAI活用*\n\n現在は、同社R&Dのオペレーション領域をイノベーション、製品・サービス、R&D 開発支援、および業務効率改善という4つに切り分けてAI活用を加速。児玉氏のリードするR&D組織における開発支援では自社開発AIと市場にあるAI製品の双方を活用しています。児玉氏は、「社内でのAIへの注目度は高まっています。いまはトライ・アンド・エラーで進めています」と語ります。では、AIの採用が時間がかかったことが、なぜ同社にとってチャンスになるのでしょう。\n\n## グローバル標準開発基盤とAIをセットで導入\n\n![グローバル標準開発基盤とAIをセットで導入](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783041/bqhgg6aiar7a1zejrfza.jpg)\n\n*左からオリンパス株式会社 R&Dセンターオブソフトウエアエクセレンス グ ローバルバイスプレジデント 児玉 達弘氏、GitLab合同会社 Japan Country Manager 小澤 正治*\n\nオリンパスが最初に取り組んだのは、開発基盤の標準化です。開発のグローバル化が進む中、各国・地域で異なる開発基盤を運用していたため、コードやナレッジの共有が困難な状況にあり、その抜本的な改革が求められていました。標準開発基盤を導入することで、これらのアセットを容易に共有できるようになり、同時に重複するライセンスコストを削減できるというメリットもあります。\n\n児玉氏は、「生産性の高い開発基盤を利用できれば、優秀なエンジニアの確保にもつながります。これまでは、業界特有の法規制で身動きが取りづらく、実際に他業界と比べると遅れていましたが、一気に追いつきたいのです」と語ります。 \n\nそれに対して、小澤は「AIコーディングは数年前からエンジニアの生産性を高められるレベルに達したと話題になっていますが、AIコーディングそのものではなく、開発基盤を見直してその上でAIを活用するという思考に至った経緯はどこにあるのでしょう」と問いかけます。\n\n児玉氏によると、最も優先した事項は、世界中のエンジニアが同じ環境で開発できる基盤を整えることです。アセットやナレッジをスムーズに共有し、開発全体の効率性を高めるという命題がありました。実際に、力点を置いたのはそこなのですが、ちょうど同社が開発基盤の整備を進めていたタイミングで、AIツールが急速に普及しだしたという背景があります。 \n\n「これが極めて好都合だったのです。統一された基盤の上でAIを活用できるため、コーディングの生産性をさらに高めるための準備を一気に整えることができました。各国の医療法規制に対応することができ、さらにAI-Readyなグローバル標準開発基盤になります」（児玉氏） \n\n## インフラ専属チームを基盤にしたグローバルな開発組織へ\n\n![インフラ専属チームを基盤にしたグローバルな開発組織へ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783040/x48rxcdt7z7tpwpre8av.jpg)\n\n*左からオリンパス株式会社 R&Dセンターオブソフトウエアエクセレンス グ ローバルバイスプレジデント 児玉 達弘氏、GitLab合同会社 Japan Country Manager 小澤 正治*\n\n![図：3つの変革](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765805070/hd02ebw61fp0gwn78d0r.jpg)\n\n*図：3つの変革*\n\n開発基盤の刷新と同時に、組織変革も進めました。全世界の組織がかかわるため、さまざまな声が上がってくるものですが、まずはビジョンを示し、ロードマップを含めて丁寧に説明。ボトムアップ型の提案を受け入れながら、目指す世界観を共有して進めています。 \n\n児玉氏は「日本の組織は、インフラを重視しない傾向がありますよね（笑）。一方、欧米企業はインフラを非常に重視しています。私は欧米企業で働いた経験もあり、そういった思考を取り入れました。インフラ専任チームを主体とし、プラットフォームエンジニアリングに加えて、他の先進技術の組織を傘下に持つグローバル組織へと再編したのです。\n\n開発基盤の標準化は、オフショアパートナーの担当者からも好評でした。プラットフォームが統一されている方が働きやすいという評価です。「セキュリティおよびコンプライアンス面でも標準化した方が優れています。環境がバラバラなら1つずつ見なければなりませんが、環境が1つであれば、点で見れば、おおよそ全体を網羅することができますから」（児玉氏） \n\n## 開発基盤と親和性の高いAIを採用\n\n![開発基盤と親和性の高いAIを採用](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783038/hjimih3bw6v1jh5dfj1f.jpg)\n\n*GitLab合同会社 Japan Country Manager 小澤 正治*\n\nそして、開発基盤上にAIを導入しました。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)です。これにより、開発プロセスの生産性の向上、コーディングの効率化推進、および各開発拠点の生産性格差の是正を図ります。現在は、各国・地域でパイロット・プロジェクトを立ち上げながら、徐々に浸透させている段階です。 \n\n児玉氏は、「現場の担当者が実際に使ってみて、“すばらしい！”という声が出てくると、周りの部署は“いつから使えるの？”となります。興味のあるエンジニアにどんどん使ってもらうと、自然に皆の心が動いていくものです。すでに、基本的にはGitLabを使ってもらえる流れになっています」と話します。 \n\n小澤は、「安全性が強く求められ、規制の強い業界ですから、AI導入へのハードルは高かったのではありませんか」と問いかけます。\n\n> **なぜオリンパスはグローバル標準のAIとしてGitLab Duoを採用したのか** \n>\n> 開発基盤であるGitLabとの「親和性の高さ」が第一の理由です。GitLabと一体化した製品として設計されているため、開発者は作業の流れを止めることなく、自然な形でAIのサポートを受けられます。次に、セキュリティを最重要視する医療機器メーカーの 必須条件である「オンプレミス環境への対応」です。GitLab Duoなら管理された社内 環境で優れたAI機能を利用できます。最後に、「データの安全性」。GitLabが開発 コードなどの機密情報をAIの学習に利用しないことが契約書に明記されており、情報 漏洩のリスクなく安心して使えることが大きな決め手になりました。 \n\n## 近い将来、エンジニアにはより一層のヒューマンスキルが求められる\n\n![近い将来、エンジニアにはより一層のヒューマンスキルが求められる](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783040/dpzfx1lwihqolr0tbvaa.jpg)\n\n*オリンパス株式会社 R&Dセンターオブソフトウエアエクセレンス グ ローバルバイスプレジデント 児玉 達弘氏*\n\n児玉氏は今後も、[GitLabのカスタマーサクセス](https://about.gitlab.com/ja-jp/services/)チームとの連携を強化し、GitLabと[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)をオリンパスのグローバル標準開発基盤として、さらなる浸透を図ります。また、確実に進めていかなければならないのは、継続的に実施しなければならない法規制への対応です。児玉氏は、これらに加えて、新たな開発基盤を活用して仕事を進めるエンジニアの働き方を再定義する必要があると考えています。 \n\n実際に使ってみると、コーディング関連の作業はかなりAIにサポートしてもらえることがわかりました。そうなると、エンジニアの仕事は将来的に上流部分と成果物のチェックが主になります。人とAIの仕事の切り分けが進めば、「AIと一緒にどう働くのが効果的か」、「AIをどう働かせればいいのか」という命題に答えを出す必要が出てくるでしょう。\n\n児玉氏は、AIを活用して働く近い将来のエンジニア像について、次のように話してくれました。「AIは進化が非常に速いため、継続的に学び続ける意欲が不可欠です。その上で、AIだけでは解決できない複雑な問題に対応するための問題解決能力や、チームで協力して仕事を進めるコミュニケーション能力といったヒューマンスキルがより一層求められます。AIを正しく使い、AIに正しく行動させる倫理的な判断力も求められてくるのではないでしょうか」\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783046/imrebw0dspdmpap6ga2e.jpg)\n\n*ステージの様子*\n\n![＜ブースの様子＞](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783042/rtkszppq4jriueqcrxx4.jpg)\n*ブースの様子*\n\n![ノベルティの水筒](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783044/liwg8dkg1dlcxgu2co6b.jpg)\n*イベントで配られたノベルティ（水筒）*\n\n![ノベルティのステッカー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765783044/psnz3c5aqqk5kwxijrwa.jpg)\n*イベントで配られたノベルティ（ステッカー）*","2025-12-17",[681],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1765782992/oprjzjvey9xx4fvtdevb.jpg","GitLabとGitLab Duoをグローバル標準に、プラットフォーム・エンジニアリング領域で AI活用を加速するオリンパス【イベントレポート】","2025年10月に開催された「Gartner IT Symposium/Xpo™ 2025」の当社セッションにおいて、オリンパス株式会社R&Dセンターオブソフトウエアエクセレンスグローバルバイスプレジデント児玉達弘氏にご講演いただいた模様をお伝えします。",[686,717,687,24,276,688],"collaboration",{"featured":12,"template":13,"slug":719},"event-report-gartner-it-symposium-xpo-2025",{"promotions":721},[722,736,747],{"id":723,"categories":724,"header":726,"text":727,"button":728,"image":733},"ai-modernization",[725],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":729,"config":730},"Get your AI maturity score",{"href":731,"dataGaName":732,"dataGaLocation":248},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":734},{"src":735},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":737,"categories":738,"header":739,"text":727,"button":740,"image":744},"devops-modernization",[28,9],"Are you just managing tools or shipping innovation?",{"text":741,"config":742},"Get your DevOps maturity score",{"href":743,"dataGaName":732,"dataGaLocation":248},"/assessments/devops-modernization-assessment/",{"config":745},{"src":746},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":748,"categories":749,"header":750,"text":727,"button":751,"image":755},"security-modernization",[27],"Are you trading speed for security?",{"text":752,"config":753},"Get your security maturity score",{"href":754,"dataGaName":732,"dataGaLocation":248},"/assessments/security-modernization-assessment/",{"config":756},{"src":757},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":759,"blurb":760,"button":761,"secondaryButton":765},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":52,"config":762},{"href":763,"dataGaName":55,"dataGaLocation":764},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":57,"config":766},{"href":59,"dataGaName":60,"dataGaLocation":764},1772652133913]