[{"data":1,"prerenderedAt":761},["ShallowReactive",2],{"/ja-jp/blog/jenkins-to-gitlab-migration-made-easy":3,"navigation-ja-jp":38,"banner-ja-jp":437,"footer-ja-jp":447,"blog-post-authors-ja-jp-Fernando Diaz":653,"blog-related-posts-ja-jp-jenkins-to-gitlab-migration-made-easy":667,"assessment-promotions-ja-jp":713,"next-steps-ja-jp":752},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":26,"isFeatured":12,"meta":27,"navigation":12,"path":28,"publishedDate":20,"seo":29,"stem":34,"tagSlugs":35,"__hash__":37},"blogPosts/ja-jp/blog/jenkins-to-gitlab-migration-made-easy.yml","Jenkins To Gitlab Migration Made Easy",[7],"fernando-diaz",null,"devsecops",{"slug":11,"featured":12,"template":13},"jenkins-to-gitlab-migration-made-easy",true,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22,"updatedDate":25},"JenkinsからGitLabへのスムーズな移行","JenkinsからGitLabへ移行するメリットと簡単に行える移行手順を分かりやすく解説します。",[18],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","2024-02-01","GitLabは、最も包括的なAI搭載のDevSecOpsプラットフォームです。GitLabには、ソフトウェアの計画、開発、セキュリティ確保、迅速なリリースに必要な機能がすべて揃っています。\n\nプラットフォームを活用することで、さまざまなツールの統合（DIY DevOps）に苦労することなく、ソフトウェア開発ライフサイクル（SDLC）を実現できます。一方、Jenkinsはプラットフォームではないため、SDLCを実現させるには他のツールと組み合わせる必要があります。このようなDIY DevOpsのアプローチではツールチェーンの複雑さが増し、以下のようなデメリットが生じます。\n\n- ツールの統合やオーケストレーションに特別なサポートが必要\n- 個々のツールの保守、アップグレード、セキュリティ対策の負担が大きい\n- 組織における変革の進捗を正確に把握しづらい\n- デベロッパーエクスペリエンスが悪化する\n- 管理コスト、時間、予算がかかる\n- 生産性が低下する\n- 頭の切り替えが必要となり、コラボレーションの効率が下がる\n\n\n![Import project selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png \"DIY DevOpsとDevSecOpsプラットフォームの比較\")\n\n\u003Cp>\u003C/p>\n\nこうした理由から、Jenkinsを使用する多くのチームがDevSecOpsプラットフォームへの移行を検討しています。より強力で、信頼性と安全性の高いソリューションを求めているなら、GitLabが最適です。GitLabは無料で使い始められ、組織のニーズに応じたさまざまなサブスクリプションプランが用意されています。GitLab のプランや機能の詳細については、[価格ページ](https://about.gitlab.com/ja-jp/pricing/)をご覧ください。\n\nこのブログ記事では、以下について学べます。\n- 移行計画の立て方\n- 他のソースコード管理（SCM）ツールからGitLabへリポジトリを移行する方法\n- JenkinsからGitLabへCI/CDパイプラインを移行する方法\n- 移行に関するその他の考慮事項\n\n### 移行計画を立てる\n\n他のツールからGitLab CI/CDへ移行を開始する前に、まず移行計画を立てる必要があります。移行計画は、期待値を明確にするための重要な技術的ステップです。CI/CDツールは、それぞれアプローチや構造、技術的な仕様が異なるため、単純にデータを1対1でマッピングできるわけではありません。適切な移行計画を立てることでもたらされるメリットを次に挙げます。\n\n- 移行の目的を明確にして共有することで、なぜ移行が価値のある取り組みなのかをユーザーに理解してもらいやすくなります。作業が完了すればその価値は明らかになりますが、移行中の段階においても認識してもらうことが重要です。\n- 関係する経営陣の支援や合意が得られ、移行の重要性や目的が全員に伝わりやすくなります。\n- 移行後の環境の違いについて、ユーザーが理解を深める時間を確保できます。\n- 移行の順序を決めたり、一部の移行を後回しにしたりすることで、未移行や部分的な移行状態が長引くのを防ぎます。\n- GitLab CI/CDにより得られる改善点やメリットを文書化し、移行の一環として既存の実装を更新できます。\n\n適切な移行計画を策定することで、業務への影響を最小限に抑えながら、GitLabへ徐々に移行できます。具体的には、JenkinsとGitLabを併用しつつ、一部のプロジェクトをGitLabに移し、Jenkinsの利用を徐々に減らしていくといった計画が考えられます。\n\n### 変更管理プロセスを定める\n\n移行計画では、効果的な変更管理プロセスを定める必要があります。デベロッパー、IT運用担当者、クラウド管理者、セキュリティ担当者、品質エンジニアなどの関係者は、GitLabの使用経験がなく、なぜあなたや経営陣がこの移行を決定したのかを理解していないかもしれません。\n\nこの移行によって影響を受ける人々に、以下の点を理解してもらう必要があります。\n- __なぜ__：この変更が行われるのか\n- __何が__：移行後の状態として想定されているのか\n- __どのように__：現在の状況から移行後の状態にするのか\n- __どこで__：追加の情報やサポートを得られるのか\n\n移行の影響を受ける各部門のへの影響を理解し、その変化を管理するには、以下の手順が必要です。\n\n- __現在の状況を分析する__：まず、現在のプロセスを文書化し、基準となる指標を収集します。次に、主要なチームメンバーへのインタビューを通じて、CI/CDにおいてうまく機能している点と機能していない点を特定します。課題を特定したら、定量的、定性的の両面から記録します。移行のビジョンと変更の理由を関係者に理解してもらう必要があるため、課題は明確に定義すればするほど、社内の合意を得やすくなります。\n- __ビジョンを確立する__：現在の課題を、定量的な基準値と定性的なチームメンバーのフィードバックで明確にしたら、次に将来のビジョンを共有します。ビジネスの成功指標と結びつけて、なぜこの移行が重要なのかを説明します。また、望ましい状態の具体的な例をライブデモや録画を通じて示し、現在の状況と比較します。さらに、このメッセージを定着させるために、チャットグループ、全社ミーティング、メール通知、GitLab上のバナーメッセージなど、複数のチャネルやメディアを活用して発信します。\n- __従業員を教育する__：GitLabの専門家が実施する[GitLab CI/CDトレーニング](https://university.gitlab.com/pages/ci-cd-training/)に投資し、[GitLab認定](https://levelup.gitlab.com/pages/certifications)を活用して、知識の習得度や定着度を測定します。\n- __ロードマップとリソースを共有する__：チームメンバーに対し、移行の予定タイムラインや、移行に役立つリソースを案内します。また、チャットグループ、Q&Aボード、GitLabインフルエンサーによるオフィスアワーなど、コミュニティのリソースも案内し、質問に対する回答やサポートを得られる環境を整えます。さらに、早期に移行したチームを対象とした報酬制度を導入して、移行体験を他のアプリケーショングループと共有してもらうのも効果的です。\n\n移行の開始時にこれらの要素が揃っていれば、成功へ向けたしっかりとした基盤を築けます。\n\n### 移行目標を設定する\n移行を実施する前に、目標とそれを達成する方法をしっかりと把握しておく必要があります。たとえば、以下のような質問に対する答えを用意しておくことが重要です。\n- 移行のタイムラインはどのようになっているのか？\n- 現在のJenkinsサーバーの構成はどうなっているか？\n- 移行対象のプロジェクトはいくつあるか？\n- パイプラインの複雑さはどの程度か？\n- 外部依存関係、複数のパイプライントリガー、並列ビルドなどが必要か？\n- コードのデプロイ方法とデプロイ先は？\n- デプロイするコードのリリースやレビューのプロセスはどのようになっているか？\n- Jenkinsに統合されているのか、それともJenkinsがトリガーする別のワークフローなのか？\n- パイプラインの成功に必要なビルドアーティファクトやバイナリは何か？\n- 現在Jenkinsのジョブで使用しているプラグインは何か？\n- Jenkinsエージェントにインストールされているソフトウェアは何か？\n- 現在使用しているSCMソリューションは何か？\n- Jenkinsのジョブで共有ライブラリを使用しているか？\n- Jenkinsで使用している認証方法は何か（Basic認証、LDAP/AD、SSOなど）？\n- パイプラインからアクセスする必要がある他のプロジェクトはあるか？\n- Jenkinsが外部サービスと連携する際に使用するアクセス用認証情報はあるか？\n\nこれらの質問に答えることで、移行の進め方、所要時間、どこから始めるべきかが明確になります。移行計画を立て、期待値や想定される課題をしっかり把握できたら、いよいよ移行プロセスの開始です。\n\n### 移行の前提要件\n移行計画を作成し、移行に関するすべての期待事項を整理できたら、GitLabのセットアップを開始できます。移行の前に推奨される前提要件をいくつかご紹介します。\n- GitLabに慣れる。[GitLab CI/CDの主な機能](https://docs.gitlab.com/ee/ci/index.html)を読んで理解を深める。\n- チュートリアルを活用し、最初の[GitLabパイプライン](https://docs.gitlab.com/ee/ci/quick_start/index.html)と、静的サイトをビルド、テスト、デプロイする[より複雑なパイプライン](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)を作成する。\n- [.gitlab-ci.ymlのキーワード参照](https://docs.gitlab.com/ee/ci/yaml/index.html)を確認する。\n- GitLabをセットアップし、適切に設定する。\n- GitLabインスタンスをテストする。\n\nGitLabの理解を深め、インスタンスの設定が完了したら、移行計画に沿ってJenkinsからGitLabへのプロジェクト移行を進めることができます。その際、GitLabインスタンスがGitLabのベストプラクティスや[リファレンスアーキテクチャ](https://docs.gitlab.com/ee/administration/reference_architectures/)に従って適切に設定されていることを確認してください。\n\n### リポジトリをGitLabに移行する\nJenkinsの主な欠点の1つは、SCMソリューションがないことです。Jenkinsを使用している場合、別のSCMソリューションにコードを保存し、そこにJenkinsからアクセスする必要があります。一方、GitLabにはSCMが組み込まれているため、Jenkinsからの移行に伴い、従来使用していたSCMソリューションからも移行でき、さらなるコスト削減につながります。\n\nGitLabには、リポジトリやそのメタデータを簡単にGitLabへと移行できるツールが用意されています。プロジェクトをGitLabへ移行する際に活用できるインポーターは以下のとおりです。\n\n- [GitHub](https://docs.gitlab.com/ee/user/project/import/github.html)\n- [別のGitLabインスタンス](https://docs.gitlab.com/ee/user/project/settings/import_export.html)\n- [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html)\n- [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html)\n- [FogBugz](https://docs.gitlab.com/ee/user/project/import/fogbugz.html)\n- [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html)\n- [Jira（イシューのみ）](https://docs.gitlab.com/ee/user/project/import/jira.html)\n- [manifestファイルによるリポジトリのインポート](https://docs.gitlab.com/ee/user/project/import/manifest.html)\n- [URLによるリポジトリのインポート](https://docs.gitlab.com/ee/user/project/import/repo_by_url.html)\n\n\n![GitHub to GitLab Repo Exporter](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png \"GitHubからGitLabへのリポジトリエクスポーター\")\n\n\u003Cp>\u003C/p>\n\n各インポーターは、プロジェクトから異なる種類のデータをインポートします。インポーターによりGitLabへ移行できるデータの詳細については、[インポートとプロジェクトの移行に関するるドキュメント](https://docs.gitlab.com/ee/user/project/import/)を参照してください。さらに、[グループやプロジェクトのインポートを自動化](https://docs.gitlab.com/ee/user/project/import/#automate-group-and-project-import)したり、組織のニーズに合わせたカスタムソリューションを構築したりすることも可能です。\n\n- [プロフェッショナルサービス](https://about.gitlab.com/ja-jp/services/)\n- [移行ユーティリティ](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n- [移行に関するよくある質問](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n### リポジトリを移行する方法\nGitLabには組み込みのインポーターが用意されており、リポジトリの移行は簡単に行えます。例として、GitHubからGitLabへリポジトリをコピーし、[そのリソース](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data)（イシュー、プルリクエスト、マイルストーンなど）も含めて移行する方法をご紹介します。別のGitHubからGitLabへリポジトリを移行するには、以下の手順に従ってください。\n\n1. 左側のサイドバーの上部で、**新規作成**（+）を選択します。\n2. 「GitLab」セクションで**新規プロジェクト/リポジトリ**を選択します。\n3. **プロジェクトのインポート**を選択します。\n![Import project selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png \"インポートするプロジェクトの選択\")\n4. **GitHub**ボタンをクリックします。\n- GitLab Self-Managedを使用している場合は、[GitHubインポーターを有効にする](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources) 必要があります。\n    - 他のインポーターも同様の方法で開始できます。\n5. 次に、以下のいずれかの方法で認証します。\n    - GitHub OAuthで認証する場合：**GitHubで認証**を選択します。\n    - GitHubのパーソナルアクセストークンを使う場合：\n       - [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new)にアクセスします。\n       - **ノート**フィールドにトークンの説明を入力します。\n       - リポジトリスコープを選択します。\n       - オプションとしてコラボレーターをインポートするには、**read:org**スコープを選択します。\n       - **トークンの生成**ボタンをクリックします。\n       - GitLabのインポートページの「パーソナルアクセストークン」フィールドに、GitHubのパーソナルアクセストークンを貼り付けます。\n6. **認証**ボタンをクリックします。\n7. 移行するアイテムを選択します。\n8. 移行するプロジェクトと移行先を選択します。\n9. **インポート**ボタンを押します。\n\nこれで、インポートされたプロジェクトがワークスペースに追加されます。GitHubからGitLabへの移行に関する詳しいガイドについては、こちらの動画をご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nリポジトリの移行が完了したら、JenkinsのパイプラインでGitLab内のJenkinsfileを活用できるように設定できます。これは、Jenkinsのパイプライン設定メニューから、新しくインポートしたプロジェクトのリポジトリURLを指定することで実行できます。\n\n\n![Jenkins Pipeline SCM settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png \"JenkinsパイプラインのSCM設定\")\n\n\u003Cp>\u003C/p>\n\nの方法は、移行の初期段階でもJenkinsの既存の機能を維持しながらGitLabと並行して使用できるため、CI/CD機能の移行作業中にサービスが中断されるのを防げます。\n\nさらに、[GitLab Jenkinsプラグイン](https://plugins.jenkins.io/gitlab-plugin/)を活用することで、移行をスムーズに進めることができます。このプラグインを使用すると、GitLabからJenkinsのビルドをトリガーしたり、ビルドのステータスを取得したりできるようになります。\n\n### CI/CDパイプラインを移行する\nリポジトリの移行が完了したら、今度はJenkinsのパイプラインをGitLabへ移行できます。このプロセスは比較的シンプルですが、JenkinsとGitLabの両方の概念や構文を理解する必要があります。\n\nJenkinsには、パイプラインを定義するための構文として宣言型とスクリプト型の2種類があります。今回は、最も一般的に使用されている宣言型パイプラインからの移行方法を解説します。\n\n### パイプラインを段階的に移行する\nこのチュートリアルでは、Jenkinsfile（Groovy）とGitLab CI/CDの設定ファイル（YAML）を比較しながら、Go言語で書かれたマイクロサービスをビルド、テスト、デプロイする方法を分析します。その後、GitLabでパイプラインを有効化し、実際の動作を確認します。このパイプラインは以下の処理を行います。\n\n- **alpine**タグ付きのGo言語コンテナイメージを使用する\n- Go言語のコードを実行可能なバイナリにビルドするジョブを実行する\n   - ビルドしたバイナリをアーティファクトとして保存する\n- ユニットテストを実行するジョブを実行する\n- stagingステージにデプロイするジョブを実行する\n   - コミットが**staging**ブランチに向けたものである場合のみ実行される\n   - **test**ステージが成功した後に開始される\n   - 以前のジョブで作成された実行可能なバイナリアーティファクトを使用する\n\n以下に、JenkinsとGitLabのパイプライン定義とコメントを示します。実際のパイプラインの動作は[Meow Migrationプロジェクト](https://gitlab.com/gitlab-da/projects/blogs/meow-migration)で確認できます。\n\nでは、Groovyで記述されたJenkinsfileを見ていきましょう。\n\n```shell\n// 宣言型パイプラインの\n// トップレベルを定義します。\npipeline {\n\n  // ジョブ内で明示的に定義されていない場合に\n  // デフォルトで使用するエージェントを\n  // 指定します。\n    agent any\n\n  // 数値順に実行される\n  // ステージを定義します。各ステージは\n  // 1つのジョブのみを実行します。\n    stages {\n\n    // ステージの名前を定義します。\n        stage('build') {\n      // このジョブで使用する\n      // コンテナイメージを定義し、\n      //デフォルトの'agent any'を上書きします。\n      // 実行にはJenkins Docker\n      // プラグインの設定が\n      // 必要です。\n            agent { docker 'golang:alpine' }\n\n      // ステージが実行される際に\n      // 実行する処理の順序を\n      // 定義します。\n            steps {\n                sh 'go build -o bin/meow-micro'\n                sh 'chmod +x bin/meow-micro'\n            }\n\n      // ステージ完了後に\n      // 実行する処理を定義します。\n            post {\n              always {\n\n        // 他のジョブで使用するために\n        // ステージアーティファクトを\n        // 保存します。\n                archiveArtifacts artifacts: 'bin/meow-micro'\n                onlyIfSuccessful: true\n              }\n            }\n        }\n\n    stage('test') {\n            agent { docker 'golang:alpine' }\n            steps {\n                sh 'go test .'\n            }\n        }\n\n        stage('deploy') {\n      // このジョブを\n      // 実行するための\n      // 条件を定義します。この場合、\n      // stagingブランチでのみ\n      // デプロイジョブが実行されます。\n            when {\n              branch 'staging'\n            }\n            steps {\n                echo 'Deploying meow-micro to staging'\n        // buildステージで保存した\n        // アーティファクトを使用します。\n                sh './bin/meow-micro'\n            }\n        }\n    }\n}\n```\n\nでは、同じ機能をGitLabで作成する方法について見ていきましょう。\n\n```text\n# ジョブ内で明示的に定義されていない場合に\n# デフォルトで使用するイメージを\n# 指定します。\ndefault:\n  image: alpine:latest\n\n# 実行するステージの順序を定義します。\n# 各ステージには複数のジョブを含めることができます。\nstages:\n  - build\n  - test\n  - deploy\n\n# ジョブ名を定義します。\ncreate-binary:\n # このジョブが実行されるステージを定義します。\n  stage: build\n # このジョブで使用するコンテナイメージを定義し、\n # デフォルトの設定を上書きします。\n  image: golang:alpine\n # ジョブ実行時に実行する\n # 一連の手順を定義します。\n  script:\n    - go build -o bin/meow-micro\n    - chmod +x bin/meow-micro\n # 他のジョブで使用するために\n # ジョブのアーティファクトを保存します。\n  artifacts:\n    paths:\n      - bin/meow-micro\n    expire_in: 1 week\n\nunit-tests:\n  stage: test\n  image: golang:alpine\n  script:\n    - go test .\n # ジョブの実行後に実行するコマンドを\n # 定義します。\n after_script:\n  - echo \"Tests Complete\"\n\nstaging-deploy:\n  stage: deploy\n # ジョブの実行前に実行するコマンドを\n # 定義します。\n  before_script:\n    - apk update\n  script:\n    - echo \"Deploying meow-micro to staging environment\"\n    - ./bin/meow-micro\n # このジョブが実行される\n # 条件を定義します。この\n # 場合、stagingブランチでのみ\n # staging-deployジョブが実行されます。\n  rules:\n    - if: $CI_COMMIT_BRANCH == 'staging'\n # buildジョブで保存されたアーティファクトを\n # このジョブで使用できるようにします。\n  artifacts:\n    paths:\n      - bin/meow-micro\n\n```\n\nご覧のとおり、JenkinsとGitLabの構文には多くの共通点があり、パイプラインの移行は比較的簡単です。ここでは基本的な例を紹介しましたが、両ツールの詳しい[機能や概念の比較](https://docs.gitlab.com/ee/ci/migration/jenkins.html#comparison-of-features-ad-concepts)もぜひご確認ください。\n\nJenkinsからGitLabへのマッピング方法を理解したところで、GitLabで同じ機能を持つパイプラインの作成を始めましょう。以下の手順でCI/CDを移行できます。\n\n##### 1. 先程GitLabに移行したリポジトリを開きます。\n- 左側のサイドバー上部で**検索または移動先…** を選択します。\n- プロジェクトを検索し、開きます。\n\n##### 2. [パイプラインエディタ](https://docs.gitlab.com/ee/ci/pipeline_editor/)を開きます。\n- 左側のサイドバーから**ビルド > パイプラインエディタ**を選択します。\n\n![Pipeline editor menu](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png \"パイプラインエディタのメニュー\")\n\n\u003Cp>\u003C/p>\n\n- **パイプラインの設定** ボタンをクリックします。\n\n\n![Configure pipeline selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png \"「パイプラインの設定」を選択\")\n\n\u003Cp>\u003C/p>\n\n##### 3. [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/)に入力します。\n- GitLab CIのパイプラインコードを追加します。\n\n![Pipeline editor input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png \"パイプラインエディタへの入力\")\n\n\u003Cp>\u003C/p>\n\n- 構文が正しいか検証します。\n\n\n![Pipeline syntax validation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png \"パイプライン構文の検証\")\n\n\u003Cp>\u003C/p>\n\n- パイプラインの構造を視覚化して確認します。\n\n\n![Pipeline visualization](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png \"パイプラインの視覚化\")\n\n\u003Cp>\u003C/p>\n\n##### 4. ファイルをmainブランチにコミットします。\n- コミットメッセージを追加します。\n- ブランチがmainになっていることを確認します。\n- 「変更をコミットする」ボタンをクリックします。\n\n\n![Commit changes dialog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png \"「変更をコミットする」のダイアログ\")\n\n\u003Cp>\u003C/p>\n\nファイルがマージされると、定義されたパイプラインが実行されます。プロジェクトページの**ビルド > パイプライン**から、実行中の[パイプラインを確認](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines)できます。今回は**main**ブランチで実行されているため、**create-binary**とunit-testsのジョブのみが表示されます。**staging-deploy**のジョブは、stagingブランチでのみ実行されます。\n\n\n![Pipeline running on main branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png \"mainブランチで実行中のパイプライン\")\n\n\u003Cp>\u003C/p>\n\nstagingブランチを作成すると、以下のパイプラインが開始されるのを確認できます。\n\n\n![Pipeline running on staging branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png \"stagingブランチで実行中のパイプライン\")\n\n\u003Cp>\u003C/p>\n\nジョブをクリックすると、その出力を確認できます。\n\n\n![create-binary job output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png \"create-binaryジョブの出力\")\n\n\u003Cp>\u003C/p>\n\n\n![unit-tests job output input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png \"unit-testsジョブの出力\")\n\n\u003Cp>\u003C/p>\n\n\n![staging-deploy job output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png \"staging-deployジョブの出力\")\n\n\u003Cp>\u003C/p>\n\nこのように、create-binaryジョブで保存されたアーティファクトが、staging-deployジョブで使用されることが確認できます。これだけの手順で、JenkinsのパイプラインをスムーズにGitLabへ移行できます！\n\n### 移行に関するその他の考慮事項\nデプロイプロセスをよりシンプルにするために役立つポイントとして、以下の点を考慮することをおすすめします。\n\n- タスクをそのまま1:1でGitLabのジョブに移行しようとしない：既存のパイプラインが何を行っているのか、どのような問題を解決しているのかを整理し、理解する時間を確保することが重要です。\n\n- 一部のJenkinsジョブは複雑すぎてすぐにGitLabに移行できない場合がある：そのため、[GitLab Jenkinsプラグイン](https://plugins.jenkins.io/gitlab-plugin/)を活用し、JenkinsのパイプラインをGitLabから直接起動し、結果を表示できるようにするとよいでしょう。これにより、一部の処理を徐々にGitLabに移行し、最終的にパイプライン全体をGitLabへ統合できます。\n\n- GitLabが提供する組み込みテンプレートを活用し、[セキュリティスキャナーやコード品質チェック](https://docs.gitlab.com/ee/user/application_security/)を最初から導入する：これにより、セキュリティのシフトレフトを行い、漏洩のリスクを低減できます。\nまた、CI/CDの設定を過度に複雑にしないようにし、すべての機能を一度に活用しようとするのではなく、コードをモジュール化し、複数の小さなステップに分けて導入するようにしてください。\n\n- モニタリングとガバナンスを最初から実装する。\n\n- GitLab Runner（Go）はJenkinsエージェント（Java）とは動作が異なる可能性があることを理解する：CPU使用率やメモリ消費量が異なる可能性があるため、時間をかけて比較しながら調整する必要があります。\n\n- 自動スケーリングの導入を検討し、週末や業務時間外に不要なリソースをシャットダウンすることを検討する。\n\n- ジョブのコンテナ化を進め、アプリケーション開発をモダナイズする：現在ではJenkinsのジョブはコンテナ上ではなく、仮想マシン（VM）として動作するJenkinsエージェント上で実行されます。\n\nこのリストはすべての考慮事項を網羅しているわけではありませんが、移行を進めるうえで重要なポイントを押さえています。さらにサポートが必要な場合は、GitLabの[プロフェッショナルサービス](https://about.gitlab.com/ja-jp/get-help/)を活用し、移行プロセスをスムーズに進めることも可能です。\n\n### 関連リンク\nここまでお読みいただきありがとうございます！本ガイドが、JenkinsからGitLabへ移行するメリットと手順を理解する助けとなれば幸いです。まだ迷っている方は、ぜひ[GitLabの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)でDevSecOpsプラットフォームの価値を実感してください！\n\nさらに詳しく知りたい方のために、GitLabの機能やDevSecOpsプラットフォームのメリット、Jenkinsからの移行に関する情報を学べるリソースをいくつかご紹介します。\n\n- [Jenkinsからの移行（英語）](https://docs.gitlab.com/ee/ci/migration/jenkins.html)\n- [移行計画の立て方（英語）](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html)\n- [GitLabプロジェクトインポーター（英語）](https://docs.gitlab.com/ee/user/project/import/)\n- [チュートリアル：簡単にできるGitHubからGitLabへの移行（英語）](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n- [動画：簡単にできるGitHubからGitLabへの移行（英語）](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n- [JenkinsからGitLabへ: CI/CD環境をモダナイズするための究極ガイド（英語）](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n\n\u003Cbr>\n\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\u003Cbr>\n",[23,24],"CI/CD","DevSecOps","2025-04-15","yml",{},"/ja-jp/blog/jenkins-to-gitlab-migration-made-easy",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":30,"ogImage":19,"ogUrl":31,"ogSiteName":32,"ogType":33,"canonicalUrls":31},false,"https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","https://about.gitlab.com","article","ja-jp/blog/jenkins-to-gitlab-migration-made-easy",[36,9],"cicd","jV7ojXazusiwEBdNVG50LQKx-JMwUW_BZG24cvZrxRw",{"data":39},{"logo":40,"freeTrial":45,"sales":50,"login":55,"items":60,"search":367,"minimal":400,"duo":417,"pricingDeployment":427},{"config":41},{"href":42,"dataGaName":43,"dataGaLocation":44},"/ja-jp/","gitlab logo","header",{"text":46,"config":47},"無料トライアルを開始",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":51,"config":52},"お問い合わせ",{"href":53,"dataGaName":54,"dataGaLocation":44},"/ja-jp/sales/","sales",{"text":56,"config":57},"サインイン",{"href":58,"dataGaName":59,"dataGaLocation":44},"https://gitlab.com/users/sign_in/","sign in",[61,88,183,188,289,349],{"text":62,"config":63,"cards":65},"プラットフォーム",{"dataNavLevelOne":64},"platform",[66,72,80],{"title":62,"description":67,"link":68},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":69,"config":70},"プラットフォームを詳しく見る",{"href":71,"dataGaName":64,"dataGaLocation":44},"/ja-jp/platform/",{"title":73,"description":74,"link":75},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":76,"config":77},"GitLab Duoのご紹介",{"href":78,"dataGaName":79,"dataGaLocation":44},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":81,"description":82,"link":83},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":84,"config":85},"詳細はこちら",{"href":86,"dataGaName":87,"dataGaLocation":44},"/ja-jp/why-gitlab/","why gitlab",{"text":89,"left":12,"config":90,"link":92,"lists":96,"footer":165},"製品",{"dataNavLevelOne":91},"solutions",{"text":93,"config":94},"すべてのソリューションを表示",{"href":95,"dataGaName":91,"dataGaLocation":44},"/ja-jp/solutions/",[97,121,143],{"title":98,"description":99,"link":100,"items":105},"自動化","CI/CDと自動化でデプロイを加速",{"config":101},{"icon":102,"href":103,"dataGaName":104,"dataGaLocation":44},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[106,109,112,117],{"text":23,"config":107},{"href":108,"dataGaLocation":44,"dataGaName":23},"/ja-jp/solutions/continuous-integration/",{"text":73,"config":110},{"href":78,"dataGaLocation":44,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"ソースコード管理",{"href":115,"dataGaLocation":44,"dataGaName":116},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":118,"config":119},"自動化されたソフトウェアデリバリー",{"href":103,"dataGaLocation":44,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":44,"icon":128},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Application Security Testing",{"href":126,"dataGaName":133,"dataGaLocation":44},"Application security testing",{"text":135,"config":136},"ソフトウェアサプライチェーンの安全性",{"href":137,"dataGaLocation":44,"dataGaName":138},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Software Compliance",{"href":142,"dataGaName":140,"dataGaLocation":44},"/ja-jp/solutions/software-compliance/",{"title":144,"link":145,"items":150},"測定",{"config":146},{"icon":147,"href":148,"dataGaName":149,"dataGaLocation":44},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[151,155,160],{"text":152,"config":153},"可視性と測定",{"href":148,"dataGaLocation":44,"dataGaName":154},"Visibility and Measurement",{"text":156,"config":157},"バリューストリーム管理",{"href":158,"dataGaLocation":44,"dataGaName":159},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":161,"config":162},"分析とインサイト",{"href":163,"dataGaLocation":44,"dataGaName":164},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":166,"items":167},"GitLabが活躍する場所",[168,173,178],{"text":169,"config":170},"Enterprise",{"href":171,"dataGaLocation":44,"dataGaName":172},"/ja-jp/enterprise/","enterprise",{"text":174,"config":175},"スモールビジネス",{"href":176,"dataGaLocation":44,"dataGaName":177},"/ja-jp/small-business/","small business",{"text":179,"config":180},"公共機関",{"href":181,"dataGaLocation":44,"dataGaName":182},"/ja-jp/solutions/public-sector/","public sector",{"text":184,"config":185},"価格",{"href":186,"dataGaName":187,"dataGaLocation":44,"dataNavLevelOne":187},"/ja-jp/pricing/","pricing",{"text":189,"config":190,"link":192,"lists":196,"feature":276},"関連リソース",{"dataNavLevelOne":191},"resources",{"text":193,"config":194},"すべてのリソースを表示",{"href":195,"dataGaName":191,"dataGaLocation":44},"/ja-jp/resources/",[197,230,248],{"title":198,"items":199},"はじめに",[200,205,210,215,220,225],{"text":201,"config":202},"インストール",{"href":203,"dataGaName":204,"dataGaLocation":44},"/ja-jp/install/","install",{"text":206,"config":207},"クイックスタートガイド",{"href":208,"dataGaName":209,"dataGaLocation":44},"/ja-jp/get-started/","quick setup checklists",{"text":211,"config":212},"学ぶ",{"href":213,"dataGaLocation":44,"dataGaName":214},"https://university.gitlab.com/","learn",{"text":216,"config":217},"製品ドキュメント",{"href":218,"dataGaName":219,"dataGaLocation":44},"https://docs.gitlab.com/","product documentation",{"text":221,"config":222},"ベストプラクティスビデオ",{"href":223,"dataGaName":224,"dataGaLocation":44},"/ja-jp/getting-started-videos/","best practice videos",{"text":226,"config":227},"インテグレーション",{"href":228,"dataGaName":229,"dataGaLocation":44},"/ja-jp/integrations/","integrations",{"title":231,"items":232},"検索する",[233,238,243],{"text":234,"config":235},"お客様成功事例",{"href":236,"dataGaName":237,"dataGaLocation":44},"/ja-jp/customers/","customer success stories",{"text":239,"config":240},"ブログ",{"href":241,"dataGaName":242,"dataGaLocation":44},"/ja-jp/blog/","blog",{"text":244,"config":245},"リモート",{"href":246,"dataGaName":247,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":249,"items":250},"つなげる",[251,256,261,266,271],{"text":252,"config":253},"GitLabサービス",{"href":254,"dataGaName":255,"dataGaLocation":44},"/ja-jp/services/","services",{"text":257,"config":258},"コミュニティ",{"href":259,"dataGaName":260,"dataGaLocation":44},"/community/","community",{"text":262,"config":263},"フォーラム",{"href":264,"dataGaName":265,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":267,"config":268},"イベント",{"href":269,"dataGaName":270,"dataGaLocation":44},"/events/","events",{"text":272,"config":273},"パートナー",{"href":274,"dataGaName":275,"dataGaLocation":44},"/ja-jp/partners/","partners",{"backgroundColor":277,"textColor":278,"text":279,"image":280,"link":284},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":281,"config":282},"ソースプロモカード",{"src":283},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":285,"config":286},"最新情報を読む",{"href":287,"dataGaName":288,"dataGaLocation":44},"/ja-jp/the-source/","the source",{"text":290,"config":291,"lists":293},"会社情報",{"dataNavLevelOne":292},"company",[294],{"items":295},[296,301,307,309,314,319,324,329,334,339,344],{"text":297,"config":298},"GitLabについて",{"href":299,"dataGaName":300,"dataGaLocation":44},"/ja-jp/company/","about",{"text":302,"config":303,"footerGa":306},"採用情報",{"href":304,"dataGaName":305,"dataGaLocation":44},"/jobs/","jobs",{"dataGaName":305},{"text":267,"config":308},{"href":269,"dataGaName":270,"dataGaLocation":44},{"text":310,"config":311},"経営陣",{"href":312,"dataGaName":313,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":315,"config":316},"チーム",{"href":317,"dataGaName":318,"dataGaLocation":44},"/company/team/","team",{"text":320,"config":321},"ハンドブック",{"href":322,"dataGaName":323,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":325,"config":326},"投資家向け情報",{"href":327,"dataGaName":328,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":330,"config":331},"トラストセンター",{"href":332,"dataGaName":333,"dataGaLocation":44},"/ja-jp/security/","trust center",{"text":335,"config":336},"AI Transparency Center",{"href":337,"dataGaName":338,"dataGaLocation":44},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":340,"config":341},"ニュースレター",{"href":342,"dataGaName":343,"dataGaLocation":44},"/company/contact/#contact-forms","newsletter",{"text":345,"config":346},"プレス",{"href":347,"dataGaName":348,"dataGaLocation":44},"/press/","press",{"text":51,"config":350,"lists":351},{"dataNavLevelOne":292},[352],{"items":353},[354,357,362],{"text":51,"config":355},{"href":53,"dataGaName":356,"dataGaLocation":44},"talk to sales",{"text":358,"config":359},"サポートポータル",{"href":360,"dataGaName":361,"dataGaLocation":44},"https://support.gitlab.com","support portal",{"text":363,"config":364},"カスタマーポータル",{"href":365,"dataGaName":366,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":368,"login":369,"suggestions":376},"閉じる",{"text":370,"link":371},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":372,"config":373},"GitLab.com",{"href":58,"dataGaName":374,"dataGaLocation":375},"search login","search",{"text":377,"default":378},"提案",[379,381,386,388,392,396],{"text":73,"config":380},{"href":78,"dataGaName":73,"dataGaLocation":375},{"text":382,"config":383},"コード提案（AI）",{"href":384,"dataGaName":385,"dataGaLocation":375},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":23,"config":387},{"href":108,"dataGaName":23,"dataGaLocation":375},{"text":389,"config":390},"GitLab on AWS",{"href":391,"dataGaName":389,"dataGaLocation":375},"/ja-jp/partners/technology-partners/aws/",{"text":393,"config":394},"GitLab on Google Cloud",{"href":395,"dataGaName":393,"dataGaLocation":375},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":397,"config":398},"GitLabを選ぶ理由",{"href":86,"dataGaName":399,"dataGaLocation":375},"Why GitLab?",{"freeTrial":401,"mobileIcon":405,"desktopIcon":410,"secondaryButton":413},{"text":46,"config":402},{"href":403,"dataGaName":49,"dataGaLocation":404},"https://gitlab.com/-/trials/new/","nav",{"altText":406,"config":407},"GitLabアイコン",{"src":408,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":406,"config":411},{"src":412,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":198,"config":414},{"href":415,"dataGaName":416,"dataGaLocation":404},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/compare/gitlab-vs-github/","get started",{"freeTrial":418,"mobileIcon":423,"desktopIcon":425},{"text":419,"config":420},"GitLab Duoの詳細について",{"href":421,"dataGaName":422,"dataGaLocation":404},"/ja-jp/gitlab-duo/","gitlab duo",{"altText":406,"config":424},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":426},{"src":412,"dataGaName":409,"dataGaLocation":404},{"freeTrial":428,"mobileIcon":433,"desktopIcon":435},{"text":429,"config":430},"料金ページに戻る",{"href":186,"dataGaName":431,"dataGaLocation":404,"icon":432},"back to pricing","GoBack",{"altText":406,"config":434},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":436},{"src":412,"dataGaName":409,"dataGaLocation":404},{"title":438,"button":439,"config":444},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":440,"config":441},"GitLab Transcendを今すぐ視聴",{"href":442,"dataGaName":443,"dataGaLocation":44},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":445,"icon":446},"release","AiStar",{"data":448},{"text":449,"source":450,"edit":456,"contribute":461,"config":466,"items":471,"minimal":645},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":451,"config":452},"ページのソースを表示",{"href":453,"dataGaName":454,"dataGaLocation":455},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":457,"config":458},"このページを編集",{"href":459,"dataGaName":460,"dataGaLocation":455},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":462,"config":463},"ご協力をお願いします",{"href":464,"dataGaName":465,"dataGaLocation":455},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":467,"facebook":468,"youtube":469,"linkedin":470},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[472,495,549,579,614],{"title":62,"links":473,"subMenu":478},[474],{"text":475,"config":476},"DevSecOpsプラットフォーム",{"href":71,"dataGaName":477,"dataGaLocation":455},"devsecops platform",[479],{"title":184,"links":480},[481,485,490],{"text":482,"config":483},"プランの表示",{"href":186,"dataGaName":484,"dataGaLocation":455},"view plans",{"text":486,"config":487},"Premiumを選ぶ理由",{"href":488,"dataGaName":489,"dataGaLocation":455},"/ja-jp/pricing/premium/","why premium",{"text":491,"config":492},"Ultimateを選ぶ理由",{"href":493,"dataGaName":494,"dataGaLocation":455},"/ja-jp/pricing/ultimate/","why ultimate",{"title":496,"links":497},"ソリューション",[498,503,506,508,513,518,522,525,528,533,535,537,539,544],{"text":499,"config":500},"デジタルトランスフォーメーション",{"href":501,"dataGaName":502,"dataGaLocation":455},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":504,"config":505},"セキュリティとコンプライアンス",{"href":126,"dataGaName":133,"dataGaLocation":455},{"text":118,"config":507},{"href":103,"dataGaName":104,"dataGaLocation":455},{"text":509,"config":510},"アジャイル開発",{"href":511,"dataGaName":512,"dataGaLocation":455},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":514,"config":515},"クラウドトランスフォーメーション",{"href":516,"dataGaName":517,"dataGaLocation":455},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":519,"config":520},"SCM",{"href":115,"dataGaName":521,"dataGaLocation":455},"source code management",{"text":23,"config":523},{"href":108,"dataGaName":524,"dataGaLocation":455},"continuous integration & delivery",{"text":156,"config":526},{"href":158,"dataGaName":527,"dataGaLocation":455},"value stream management",{"text":529,"config":530},"GitOps",{"href":531,"dataGaName":532,"dataGaLocation":455},"/ja-jp/solutions/gitops/","gitops",{"text":169,"config":534},{"href":171,"dataGaName":172,"dataGaLocation":455},{"text":174,"config":536},{"href":176,"dataGaName":177,"dataGaLocation":455},{"text":179,"config":538},{"href":181,"dataGaName":182,"dataGaLocation":455},{"text":540,"config":541},"教育",{"href":542,"dataGaName":543,"dataGaLocation":455},"/ja-jp/solutions/education/","education",{"text":545,"config":546},"金融サービス",{"href":547,"dataGaName":548,"dataGaLocation":455},"/ja-jp/solutions/finance/","financial services",{"title":189,"links":550},[551,553,555,557,560,562,565,567,569,571,573,575,577],{"text":201,"config":552},{"href":203,"dataGaName":204,"dataGaLocation":455},{"text":206,"config":554},{"href":208,"dataGaName":209,"dataGaLocation":455},{"text":211,"config":556},{"href":213,"dataGaName":214,"dataGaLocation":455},{"text":216,"config":558},{"href":218,"dataGaName":559,"dataGaLocation":455},"docs",{"text":239,"config":561},{"href":241,"dataGaName":242},{"text":563,"config":564},"お客様の成功事例",{"href":236,"dataGaLocation":455},{"text":234,"config":566},{"href":236,"dataGaName":237,"dataGaLocation":455},{"text":244,"config":568},{"href":246,"dataGaName":247,"dataGaLocation":455},{"text":252,"config":570},{"href":254,"dataGaName":255,"dataGaLocation":455},{"text":257,"config":572},{"href":259,"dataGaName":260,"dataGaLocation":455},{"text":262,"config":574},{"href":264,"dataGaName":265,"dataGaLocation":455},{"text":267,"config":576},{"href":269,"dataGaName":270,"dataGaLocation":455},{"text":272,"config":578},{"href":274,"dataGaName":275,"dataGaLocation":455},{"title":580,"links":581},"Company",[582,584,586,588,590,592,594,598,603,605,607,609],{"text":297,"config":583},{"href":299,"dataGaName":292,"dataGaLocation":455},{"text":302,"config":585},{"href":304,"dataGaName":305,"dataGaLocation":455},{"text":310,"config":587},{"href":312,"dataGaName":313,"dataGaLocation":455},{"text":315,"config":589},{"href":317,"dataGaName":318,"dataGaLocation":455},{"text":320,"config":591},{"href":322,"dataGaName":323,"dataGaLocation":455},{"text":325,"config":593},{"href":327,"dataGaName":328,"dataGaLocation":455},{"text":595,"config":596},"Sustainability",{"href":597,"dataGaName":595,"dataGaLocation":455},"/sustainability/",{"text":599,"config":600},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":601,"dataGaName":602,"dataGaLocation":455},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":330,"config":604},{"href":332,"dataGaName":333,"dataGaLocation":455},{"text":340,"config":606},{"href":342,"dataGaName":343,"dataGaLocation":455},{"text":345,"config":608},{"href":347,"dataGaName":348,"dataGaLocation":455},{"text":610,"config":611},"現代奴隷制の透明性に関する声明",{"href":612,"dataGaName":613,"dataGaLocation":455},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":51,"links":615},[616,618,623,625,630,635,640],{"text":51,"config":617},{"href":53,"dataGaName":54,"dataGaLocation":455},{"text":619,"config":620},"サポートを受ける",{"href":621,"dataGaName":622,"dataGaLocation":455},"/support/","get help",{"text":363,"config":624},{"href":365,"dataGaName":366,"dataGaLocation":455},{"text":626,"config":627},"ステータス",{"href":628,"dataGaName":629,"dataGaLocation":455},"https://status.gitlab.com/","status",{"text":631,"config":632},"利用規約",{"href":633,"dataGaName":634,"dataGaLocation":455},"/terms/","terms of use",{"text":636,"config":637},"プライバシーに関する声明",{"href":638,"dataGaName":639,"dataGaLocation":455},"/ja-jp/privacy/","privacy statement",{"text":641,"config":642},"Cookieの設定",{"dataGaName":643,"dataGaLocation":455,"id":644,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"items":646},[647,649,651],{"text":631,"config":648},{"href":633,"dataGaName":634,"dataGaLocation":455},{"text":636,"config":650},{"href":638,"dataGaName":639,"dataGaLocation":455},{"text":641,"config":652},{"dataGaName":643,"dataGaLocation":455,"id":644,"isOneTrustButton":12},[654],{"id":655,"title":18,"body":8,"config":656,"content":658,"description":8,"extension":26,"meta":662,"navigation":12,"path":663,"seo":664,"stem":665,"__hash__":666},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":657},"BlogAuthor",{"name":18,"config":659},{"headshot":660,"ctfId":661},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[668,685,701],{"content":669,"config":683},{"heroImage":670,"body":671,"authors":672,"updatedDate":674,"date":675,"title":676,"tags":677,"description":682,"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は盛況のうちに幕を閉じました。",[673],"GitLab Japan Team","2026-02-17","2026-02-03","AI駆動ソフトウェア開発の攻めと守り【GitLab Epic Tour Japan 2025レポート】",[678,679,24,680,681],"AI/ML","customers","security","user stories","2025年11月に開催した年次イベント「GitLab Epic Tour Japan 2025」の模様をご紹介。",{"featured":12,"template":13,"slug":684},"event-report-epic-tokyo-2025",{"content":686,"config":699},{"heroImage":687,"body":688,"authors":689,"updatedDate":692,"date":693,"title":694,"tags":695,"description":698,"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> をご覧ください。*",[690,691],"Tsukasa Komatsubara","Hiroshi Nishishita, SIOS Technology, Inc.","2026-01-07","2025-12-19","GitLabを少ない工数で冗長化して安定運用を実現する ～HAクラスターソフトウェア「LifeKeeper」による冗長化～",[696,229,275,697],"cloud native","production","この記事では、GitLabの止まらない仕組みを、直感的なGUIが用意されたHAクラスター製品による冗長化構成で実現する方法をご紹介します。",{"featured":30,"template":13,"slug":700},"gitlab-high-availability-with-lifekeeper-hacluster",{"content":702,"config":711},{"category":9,"body":703,"date":704,"authors":705,"heroImage":706,"title":707,"description":708,"tags":709},"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",[673],"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センターオブソフトウエアエクセレンスグローバルバイスプレジデント児玉達弘氏にご講演いただいた模様をお伝えします。",[678,710,679,24,270,681],"collaboration",{"featured":12,"template":13,"slug":712},"event-report-gartner-it-symposium-xpo-2025",{"promotions":714},[715,729,741],{"id":716,"categories":717,"header":719,"text":720,"button":721,"image":726},"ai-modernization",[718],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":722,"config":723},"Get your AI maturity score",{"href":724,"dataGaName":725,"dataGaLocation":242},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":727},{"src":728},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":730,"categories":731,"header":733,"text":720,"button":734,"image":738},"devops-modernization",[732,9],"product","Are you just managing tools or shipping innovation?",{"text":735,"config":736},"Get your DevOps maturity score",{"href":737,"dataGaName":725,"dataGaLocation":242},"/assessments/devops-modernization-assessment/",{"config":739},{"src":740},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":742,"categories":743,"header":744,"text":720,"button":745,"image":749},"security-modernization",[680],"Are you trading speed for security?",{"text":746,"config":747},"Get your security maturity score",{"href":748,"dataGaName":725,"dataGaLocation":242},"/assessments/security-modernization-assessment/",{"config":750},{"src":751},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":753,"blurb":754,"button":755,"secondaryButton":759},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":46,"config":756},{"href":757,"dataGaName":49,"dataGaLocation":758},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":51,"config":760},{"href":53,"dataGaName":54,"dataGaLocation":758},1772652104593]