[{"data":1,"prerenderedAt":810},["ShallowReactive",2],{"/ja-jp/blog/jenkins-to-gitlab-migration-made-easy":3,"navigation-ja-jp":40,"banner-ja-jp":450,"footer-ja-jp":460,"blog-post-authors-ja-jp-Fernando Diaz":693,"blog-related-posts-ja-jp-jenkins-to-gitlab-migration-made-easy":707,"blog-promotions-ja-jp":748,"next-steps-ja-jp":801},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":25,"externalUrl":26,"featured":14,"heroImage":19,"isFeatured":14,"meta":27,"navigation":14,"path":28,"publishedDate":20,"rawbody":29,"seo":30,"slug":13,"stem":35,"tagSlugs":36,"tags":38,"template":15,"updatedDate":24,"__hash__":39},"blogPosts/ja-jp/blog/jenkins-to-gitlab-migration-made-easy.yml","JenkinsからGitLabへのスムーズな移行",[7],"fernando-diaz",[9],"Fernando Diaz","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/ja-jp/ci/)を読んで理解を深める。\n- チュートリアルを活用し、最初の[GitLabパイプライン](https://docs.gitlab.com/ja-jp/ci/quick_start/)と、静的サイトをビルド、テスト、デプロイする[より複雑なパイプライン](https://docs.gitlab.com/ja-jp/ci/quick_start/tutorial/)を作成する。\n- [.gitlab-ci.ymlのキーワード参照](https://docs.gitlab.com/ja-jp/ci/yaml/)を確認する。\n- GitLabをセットアップし、適切に設定する。\n- GitLabインスタンスをテストする。\n\nGitLabの理解を深め、インスタンスの設定が完了したら、移行計画に沿ってJenkinsからGitLabへのプロジェクト移行を進めることができます。その際、GitLabインスタンスがGitLabのベストプラクティスや[リファレンスアーキテクチャ](https://docs.gitlab.com/ja-jp/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/ja-jp/user/project/import/github/)\n- [別のGitLabインスタンス](https://docs.gitlab.com/ja-jp/user/project/settings/import_export/)\n- [Bitbucket Cloud](https://docs.gitlab.com/ja-jp/user/project/import/bitbucket/)\n- [Bitbucket Server](https://docs.gitlab.com/ja-jp/user/project/import/bitbucket_server/)\n- [FogBugz](https://docs.gitlab.com/ja-jp/user/project/import/fogbugz/)\n- [Gitea](https://docs.gitlab.com/ja-jp/user/project/import/gitea/)\n- [Jira（イシューのみ）](https://docs.gitlab.com/ja-jp/user/project/import/jira/)\n- [manifestファイルによるリポジトリのインポート](https://docs.gitlab.com/ja-jp/user/project/import/manifest/)\n- [URLによるリポジトリのインポート](https://docs.gitlab.com/ja-jp/user/project/import/repo_by_url/)\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/ja-jp/user/project/import/)を参照してください。さらに、[グループやプロジェクトのインポートを自動化](https://docs.gitlab.com/ja-jp/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/ja-jp/user/project/import/github/#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/ja-jp/administration/settings/import_and_export_settings/#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/ja-jp/ci/migration/jenkins/#comparison-of-features-ad-concepts)もぜひご確認ください。\n\nJenkinsからGitLabへのマッピング方法を理解したところで、GitLabで同じ機能を持つパイプラインの作成を始めましょう。以下の手順でCI/CDを移行できます。\n\n##### 1. 先程GitLabに移行したリポジトリを開きます。\n- 左側のサイドバー上部で**検索または移動先…** を選択します。\n- プロジェクトを検索し、開きます。\n\n##### 2. [パイプラインエディタ](https://docs.gitlab.com/ja-jp/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/ja-jp/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/ja-jp/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/ja-jp/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/ja-jp/ci/migration/jenkins/)\n- [移行計画の立て方（英語）](https://docs.gitlab.com/ja-jp/ci/migration/plan_a_migration/)\n- [GitLabプロジェクトインポーター（英語）](https://docs.gitlab.com/ja-jp/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","devsecops",{"slug":13,"featured":14,"template":15},"jenkins-to-gitlab-migration-made-easy",true,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21,"updatedDate":24},"JenkinsからGitLabへ移行するメリットと簡単に行える移行手順を分かりやすく解説します。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","2024-02-01",[22,23],"CI/CD","DevSecOps","2025-04-15","yml",null,{},"/ja-jp/blog/jenkins-to-gitlab-migration-made-easy","seo:\n  title: JenkinsからGitLabへのスムーズな移行\n  description: JenkinsからGitLabへ移行するメリットと簡単に行える移行手順を分かりやすく解説します。\n  ogTitle: JenkinsからGitLabへのスムーズな移行\n  ogDescription: JenkinsからGitLabへ移行するメリットと簡単に行える移行手順を分かりやすく解説します。\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg\n  ogUrl: https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy\ncontent:\n  title: JenkinsからGitLabへのスムーズな移行\n  description: JenkinsからGitLabへ移行するメリットと簡単に行える移行手順を分かりやすく解説します。\n  authors:\n    - Fernando Diaz\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg\n  date: '2024-02-01'\n  body: >\n    GitLabは、最も包括的なAI搭載のDevSecOpsプラットフォームです。GitLabには、ソフトウェアの計画、開発、セキュリティ確保、迅速なリリースに必要な機能がすべて揃っています。\n\n\n    プラットフォームを活用することで、さまざまなツールの統合（DIY\n    DevOps）に苦労することなく、ソフトウェア開発ライフサイクル（SDLC）を実現できます。一方、Jenkinsはプラットフォームではないため、SDLCを実現させるには他のツールと組み合わせる必要があります。このようなDIY\n    DevOpsのアプローチではツールチェーンの複雑さが増し、以下のようなデメリットが生じます。\n\n\n    - ツールの統合やオーケストレーションに特別なサポートが必要\n\n    - 個々のツールの保守、アップグレード、セキュリティ対策の負担が大きい\n\n    - 組織における変革の進捗を正確に把握しづらい\n\n    - デベロッパーエクスペリエンスが悪化する\n\n    - 管理コスト、時間、予算がかかる\n\n    - 生産性が低下する\n\n    - 頭の切り替えが必要となり、コラボレーションの効率が下がる\n\n\n\n    ![Import project\n    selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\n    \"DIY DevOpsとDevSecOpsプラットフォームの比較\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    こうした理由から、Jenkinsを使用する多くのチームがDevSecOpsプラットフォームへの移行を検討しています。より強力で、信頼性と安全性の高いソリューションを求めているなら、GitLabが最適です。GitLabは無料で使い始められ、組織のニーズに応じたさまざまなサブスクリプションプランが用意されています。GitLab\n    のプランや機能の詳細については、[価格ページ](https://about.gitlab.com/ja-jp/pricing/)をご覧ください。\n\n\n    このブログ記事では、以下について学べます。\n\n    - 移行計画の立て方\n\n    - 他のソースコード管理（SCM）ツールからGitLabへリポジトリを移行する方法\n\n    - JenkinsからGitLabへCI/CDパイプラインを移行する方法\n\n    - 移行に関するその他の考慮事項\n\n\n    ### 移行計画を立てる\n\n\n    他のツールからGitLab\n    CI/CDへ移行を開始する前に、まず移行計画を立てる必要があります。移行計画は、期待値を明確にするための重要な技術的ステップです。CI/CDツールは、それぞれアプローチや構造、技術的な仕様が異なるため、単純にデータを1対1でマッピングできるわけではありません。適切な移行計画を立てることでもたらされるメリットを次に挙げます。\n\n\n    -\n    移行の目的を明確にして共有することで、なぜ移行が価値のある取り組みなのかをユーザーに理解してもらいやすくなります。作業が完了すればその価値は明らかになりますが、移行中の段階においても認識してもらうことが重要です。\n\n    - 関係する経営陣の支援や合意が得られ、移行の重要性や目的が全員に伝わりやすくなります。\n\n    - 移行後の環境の違いについて、ユーザーが理解を深める時間を確保できます。\n\n    - 移行の順序を決めたり、一部の移行を後回しにしたりすることで、未移行や部分的な移行状態が長引くのを防ぎます。\n\n    - GitLab CI/CDにより得られる改善点やメリットを文書化し、移行の一環として既存の実装を更新できます。\n\n\n    適切な移行計画を策定することで、業務への影響を最小限に抑えながら、GitLabへ徐々に移行できます。具体的には、JenkinsとGitLabを併用しつつ、一部のプロジェクトをGitLabに移し、Jenkinsの利用を徐々に減らしていくといった計画が考えられます。\n\n\n    ### 変更管理プロセスを定める\n\n\n    移行計画では、効果的な変更管理プロセスを定める必要があります。デベロッパー、IT運用担当者、クラウド管理者、セキュリティ担当者、品質エンジニアなどの関係者は、GitLabの使用経験がなく、なぜあなたや経営陣がこの移行を決定したのかを理解していないかもしれません。\n\n\n    この移行によって影響を受ける人々に、以下の点を理解してもらう必要があります。\n\n    - __なぜ__：この変更が行われるのか\n\n    - __何が__：移行後の状態として想定されているのか\n\n    - __どのように__：現在の状況から移行後の状態にするのか\n\n    - __どこで__：追加の情報やサポートを得られるのか\n\n\n    移行の影響を受ける各部門のへの影響を理解し、その変化を管理するには、以下の手順が必要です。\n\n\n    -\n    __現在の状況を分析する__：まず、現在のプロセスを文書化し、基準となる指標を収集します。次に、主要なチームメンバーへのインタビューを通じて、CI/CDにおいてうまく機能している点と機能していない点を特定します。課題を特定したら、定量的、定性的の両面から記録します。移行のビジョンと変更の理由を関係者に理解してもらう必要があるため、課題は明確に定義すればするほど、社内の合意を得やすくなります。\n\n    -\n    __ビジョンを確立する__：現在の課題を、定量的な基準値と定性的なチームメンバーのフィードバックで明確にしたら、次に将来のビジョンを共有します。ビジネスの成功指標と結びつけて、なぜこの移行が重要なのかを説明します。また、望ましい状態の具体的な例をライブデモや録画を通じて示し、現在の状況と比較します。さらに、このメッセージを定着させるために、チャットグループ、全社ミーティング、メール通知、GitLab上のバナーメッセージなど、複数のチャネルやメディアを活用して発信します。\n\n    - __従業員を教育する__：GitLabの専門家が実施する[GitLab\n    CI/CDトレーニング](https://university.gitlab.com/pages/ci-cd-training/)に投資し、[GitLab認定](https://levelup.gitlab.com/pages/certifications)を活用して、知識の習得度や定着度を測定します。\n\n    -\n    __ロードマップとリソースを共有する__：チームメンバーに対し、移行の予定タイムラインや、移行に役立つリソースを案内します。また、チャットグループ、Q&Aボード、GitLabインフルエンサーによるオフィスアワーなど、コミュニティのリソースも案内し、質問に対する回答やサポートを得られる環境を整えます。さらに、早期に移行したチームを対象とした報酬制度を導入して、移行体験を他のアプリケーショングループと共有してもらうのも効果的です。\n\n\n    移行の開始時にこれらの要素が揃っていれば、成功へ向けたしっかりとした基盤を築けます。\n\n\n    ### 移行目標を設定する\n\n    移行を実施する前に、目標とそれを達成する方法をしっかりと把握しておく必要があります。たとえば、以下のような質問に対する答えを用意しておくことが重要です。\n\n    - 移行のタイムラインはどのようになっているのか？\n\n    - 現在のJenkinsサーバーの構成はどうなっているか？\n\n    - 移行対象のプロジェクトはいくつあるか？\n\n    - パイプラインの複雑さはどの程度か？\n\n    - 外部依存関係、複数のパイプライントリガー、並列ビルドなどが必要か？\n\n    - コードのデプロイ方法とデプロイ先は？\n\n    - デプロイするコードのリリースやレビューのプロセスはどのようになっているか？\n\n    - Jenkinsに統合されているのか、それともJenkinsがトリガーする別のワークフローなのか？\n\n    - パイプラインの成功に必要なビルドアーティファクトやバイナリは何か？\n\n    - 現在Jenkinsのジョブで使用しているプラグインは何か？\n\n    - Jenkinsエージェントにインストールされているソフトウェアは何か？\n\n    - 現在使用しているSCMソリューションは何か？\n\n    - Jenkinsのジョブで共有ライブラリを使用しているか？\n\n    - Jenkinsで使用している認証方法は何か（Basic認証、LDAP/AD、SSOなど）？\n\n    - パイプラインからアクセスする必要がある他のプロジェクトはあるか？\n\n    - Jenkinsが外部サービスと連携する際に使用するアクセス用認証情報はあるか？\n\n\n    これらの質問に答えることで、移行の進め方、所要時間、どこから始めるべきかが明確になります。移行計画を立て、期待値や想定される課題をしっかり把握できたら、いよいよ移行プロセスの開始です。\n\n\n    ### 移行の前提要件\n\n    移行計画を作成し、移行に関するすべての期待事項を整理できたら、GitLabのセットアップを開始できます。移行の前に推奨される前提要件をいくつかご紹介します。\n\n    - GitLabに慣れる。[GitLab\n    CI/CDの主な機能](https://docs.gitlab.com/ja-jp/ci/)を読んで理解を深める。\n\n    -\n    チュートリアルを活用し、最初の[GitLabパイプライン](https://docs.gitlab.com/ja-jp/ci/quick_start/)と、静的サイトをビルド、テスト、デプロイする[より複雑なパイプライン](https://docs.gitlab.com/ja-jp/ci/quick_start/tutorial/)を作成する。\n\n    -\n    [.gitlab-ci.ymlのキーワード参照](https://docs.gitlab.com/ja-jp/ci/yaml/)を確認する。\n\n    - GitLabをセットアップし、適切に設定する。\n\n    - GitLabインスタンスをテストする。\n\n\n    GitLabの理解を深め、インスタンスの設定が完了したら、移行計画に沿ってJenkinsからGitLabへのプロジェクト移行を進めることができます。その際、GitLabインスタンスがGitLabのベストプラクティスや[リファレンスアーキテクチャ](https://docs.gitlab.com/ja-jp/administration/reference_architectures/)に従って適切に設定されていることを確認してください。\n\n\n    ### リポジトリをGitLabに移行する\n\n    Jenkinsの主な欠点の1つは、SCMソリューションがないことです。Jenkinsを使用している場合、別のSCMソリューションにコードを保存し、そこにJenkinsからアクセスする必要があります。一方、GitLabにはSCMが組み込まれているため、Jenkinsからの移行に伴い、従来使用していたSCMソリューションからも移行でき、さらなるコスト削減につながります。\n\n\n    GitLabには、リポジトリやそのメタデータを簡単にGitLabへと移行できるツールが用意されています。プロジェクトをGitLabへ移行する際に活用できるインポーターは以下のとおりです。\n\n\n    - [GitHub](https://docs.gitlab.com/ja-jp/user/project/import/github/)\n\n    -\n    [別のGitLabインスタンス](https://docs.gitlab.com/ja-jp/user/project/settings/import_export/)\n\n    - [Bitbucket\n    Cloud](https://docs.gitlab.com/ja-jp/user/project/import/bitbucket/)\n\n    - [Bitbucket\n    Server](https://docs.gitlab.com/ja-jp/user/project/import/bitbucket_server/)\n\n    - [FogBugz](https://docs.gitlab.com/ja-jp/user/project/import/fogbugz/)\n\n    - [Gitea](https://docs.gitlab.com/ja-jp/user/project/import/gitea/)\n\n    - [Jira（イシューのみ）](https://docs.gitlab.com/ja-jp/user/project/import/jira/)\n\n    -\n    [manifestファイルによるリポジトリのインポート](https://docs.gitlab.com/ja-jp/user/project/import/manifest/)\n\n    -\n    [URLによるリポジトリのインポート](https://docs.gitlab.com/ja-jp/user/project/import/repo_by_url/)\n\n\n\n    ![GitHub to GitLab Repo\n    Exporter](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\n    \"GitHubからGitLabへのリポジトリエクスポーター\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    各インポーターは、プロジェクトから異なる種類のデータをインポートします。インポーターによりGitLabへ移行できるデータの詳細については、[インポートとプロジェクトの移行に関するるドキュメント](https://docs.gitlab.com/ja-jp/user/project/import/)を参照してください。さらに、[グループやプロジェクトのインポートを自動化](https://docs.gitlab.com/ja-jp/user/project/import/#automate-group-and-project-import)したり、組織のニーズに合わせたカスタムソリューションを構築したりすることも可能です。\n\n\n    - [プロフェッショナルサービス](https://about.gitlab.com/ja-jp/services/)\n\n    -\n    [移行ユーティリティ](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n\n    -\n    [移行に関するよくある質問](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n\n    ### リポジトリを移行する方法\n\n    GitLabには組み込みのインポーターが用意されており、リポジトリの移行は簡単に行えます。例として、GitHubからGitLabへリポジトリをコピーし、[そのリソース](https://docs.gitlab.com/ja-jp/user/project/import/github/#imported-data)（イシュー、プルリクエスト、マイルストーンなど）も含めて移行する方法をご紹介します。別のGitHubからGitLabへリポジトリを移行するには、以下の手順に従ってください。\n\n\n    1. 左側のサイドバーの上部で、**新規作成**（+）を選択します。\n\n    2. 「GitLab」セクションで**新規プロジェクト/リポジトリ**を選択します。\n\n    3. **プロジェクトのインポート**を選択します。\n\n    ![Import project\n    selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\n    \"インポートするプロジェクトの選択\")\n\n    4. **GitHub**ボタンをクリックします。\n\n    - GitLab\n    Self-Managedを使用している場合は、[GitHubインポーターを有効にする](https://docs.gitlab.com/ja-jp/administration/settings/import_and_export_settings/#configure-allowed-import-sources)\n    必要があります。\n        - 他のインポーターも同様の方法で開始できます。\n    5. 次に、以下のいずれかの方法で認証します。\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のパーソナルアクセストークンを貼り付けます。\n    6. **認証**ボタンをクリックします。\n\n    7. 移行するアイテムを選択します。\n\n    8. 移行するプロジェクトと移行先を選択します。\n\n    9. **インポート**ボタンを押します。\n\n\n    これで、インポートされたプロジェクトがワークスペースに追加されます。GitHubからGitLabへの移行に関する詳しいガイドについては、こちらの動画をご覧ください。\n\n\n    \u003C!-- blank line -->\n\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\n    \u003C!-- blank line -->\n\n\n    リポジトリの移行が完了したら、JenkinsのパイプラインでGitLab内のJenkinsfileを活用できるように設定できます。これは、Jenkinsのパイプライン設定メニューから、新しくインポートしたプロジェクトのリポジトリURLを指定することで実行できます。\n\n\n\n    ![Jenkins Pipeline SCM\n    settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\n    \"JenkinsパイプラインのSCM設定\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    の方法は、移行の初期段階でもJenkinsの既存の機能を維持しながらGitLabと並行して使用できるため、CI/CD機能の移行作業中にサービスが中断されるのを防げます。\n\n\n    さらに、[GitLab\n    Jenkinsプラグイン](https://plugins.jenkins.io/gitlab-plugin/)を活用することで、移行をスムーズに進めることができます。このプラグインを使用すると、GitLabからJenkinsのビルドをトリガーしたり、ビルドのステータスを取得したりできるようになります。\n\n\n    ### CI/CDパイプラインを移行する\n\n    リポジトリの移行が完了したら、今度はJenkinsのパイプラインをGitLabへ移行できます。このプロセスは比較的シンプルですが、JenkinsとGitLabの両方の概念や構文を理解する必要があります。\n\n\n    Jenkinsには、パイプラインを定義するための構文として宣言型とスクリプト型の2種類があります。今回は、最も一般的に使用されている宣言型パイプラインからの移行方法を解説します。\n\n\n    ### パイプラインを段階的に移行する\n\n    このチュートリアルでは、Jenkinsfile（Groovy）とGitLab\n    CI/CDの設定ファイル（YAML）を比較しながら、Go言語で書かれたマイクロサービスをビルド、テスト、デプロイする方法を分析します。その後、GitLabでパイプラインを有効化し、実際の動作を確認します。このパイプラインは以下の処理を行います。\n\n\n    - **alpine**タグ付きのGo言語コンテナイメージを使用する\n\n    - Go言語のコードを実行可能なバイナリにビルドするジョブを実行する\n       - ビルドしたバイナリをアーティファクトとして保存する\n    - ユニットテストを実行するジョブを実行する\n\n    - stagingステージにデプロイするジョブを実行する\n       - コミットが**staging**ブランチに向けたものである場合のみ実行される\n       - **test**ステージが成功した後に開始される\n       - 以前のジョブで作成された実行可能なバイナリアーティファクトを使用する\n\n    以下に、JenkinsとGitLabのパイプライン定義とコメントを示します。実際のパイプラインの動作は[Meow\n    Migrationプロジェクト](https://gitlab.com/gitlab-da/projects/blogs/meow-migration)で確認できます。\n\n\n    では、Groovyで記述されたJenkinsfileを見ていきましょう。\n\n\n    ```shell\n\n    // 宣言型パイプラインの\n\n    // トップレベルを定義します。\n\n    pipeline {\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\n\n    では、同じ機能をGitLabで作成する方法について見ていきましょう。\n\n\n    ```text\n\n    # ジョブ内で明示的に定義されていない場合に\n\n    # デフォルトで使用するイメージを\n\n    # 指定します。\n\n    default:\n      image: alpine:latest\n\n    # 実行するステージの順序を定義します。\n\n    # 各ステージには複数のジョブを含めることができます。\n\n    stages:\n      - build\n      - test\n      - deploy\n\n    # ジョブ名を定義します。\n\n    create-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\n    unit-tests:\n      stage: test\n      image: golang:alpine\n      script:\n        - go test .\n     # ジョブの実行後に実行するコマンドを\n     # 定義します。\n     after_script:\n      - echo \"Tests Complete\"\n\n    staging-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\n    ご覧のとおり、JenkinsとGitLabの構文には多くの共通点があり、パイプラインの移行は比較的簡単です。ここでは基本的な例を紹介しましたが、両ツールの詳しい[機能や概念の比較](https://docs.gitlab.com/ja-jp/ci/migration/jenkins/#comparison-of-features-ad-concepts)もぜひご確認ください。\n\n\n    JenkinsからGitLabへのマッピング方法を理解したところで、GitLabで同じ機能を持つパイプラインの作成を始めましょう。以下の手順でCI/CDを移行できます。\n\n\n    ##### 1. 先程GitLabに移行したリポジトリを開きます。\n\n    - 左側のサイドバー上部で**検索または移動先…** を選択します。\n\n    - プロジェクトを検索し、開きます。\n\n\n    ##### 2. [パイプラインエディタ](https://docs.gitlab.com/ja-jp/ci/pipeline_editor/)を開きます。\n\n    - 左側のサイドバーから**ビルド > パイプラインエディタ**を選択します。\n\n\n    ![Pipeline editor\n    menu](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png\n    \"パイプラインエディタのメニュー\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    - **パイプラインの設定** ボタンをクリックします。\n\n\n\n    ![Configure pipeline\n    selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\n    \"「パイプラインの設定」を選択\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    ##### 3. [.gitlab-ci.yml](https://docs.gitlab.com/ja-jp/ci/yaml/)に入力します。\n\n    - GitLab CIのパイプラインコードを追加します。\n\n\n    ![Pipeline editor\n    input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png\n    \"パイプラインエディタへの入力\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    - 構文が正しいか検証します。\n\n\n\n    ![Pipeline syntax\n    validation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\n    \"パイプライン構文の検証\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    - パイプラインの構造を視覚化して確認します。\n\n\n\n    ![Pipeline\n    visualization](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\n    \"パイプラインの視覚化\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    ##### 4. ファイルをmainブランチにコミットします。\n\n    - コミットメッセージを追加します。\n\n    - ブランチがmainになっていることを確認します。\n\n    - 「変更をコミットする」ボタンをクリックします。\n\n\n\n    ![Commit changes\n    dialog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\n    \"「変更をコミットする」のダイアログ\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    ファイルがマージされると、定義されたパイプラインが実行されます。プロジェクトページの**ビルド >\n    パイプライン**から、実行中の[パイプラインを確認](https://docs.gitlab.com/ja-jp/ci/pipelines/#view-pipelines)できます。今回は**main**ブランチで実行されているため、**create-binary**とunit-testsのジョブのみが表示されます。**staging-deploy**のジョブは、stagingブランチでのみ実行されます。\n\n\n\n    ![Pipeline running on main\n    branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\n    \"mainブランチで実行中のパイプライン\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    stagingブランチを作成すると、以下のパイプラインが開始されるのを確認できます。\n\n\n\n    ![Pipeline running on staging\n    branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\n    \"stagingブランチで実行中のパイプライン\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    ジョブをクリックすると、その出力を確認できます。\n\n\n\n    ![create-binary job\n    output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\n    \"create-binaryジョブの出力\")\n\n\n    \u003Cp>\u003C/p>\n\n\n\n    ![unit-tests job output\n    input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\n    \"unit-testsジョブの出力\")\n\n\n    \u003Cp>\u003C/p>\n\n\n\n    ![staging-deploy job\n    output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\n    \"staging-deployジョブの出力\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    このように、create-binaryジョブで保存されたアーティファクトが、staging-deployジョブで使用されることが確認できます。これだけの手順で、JenkinsのパイプラインをスムーズにGitLabへ移行できます！\n\n\n    ### 移行に関するその他の考慮事項\n\n    デプロイプロセスをよりシンプルにするために役立つポイントとして、以下の点を考慮することをおすすめします。\n\n\n    -\n    タスクをそのまま1:1でGitLabのジョブに移行しようとしない：既存のパイプラインが何を行っているのか、どのような問題を解決しているのかを整理し、理解する時間を確保することが重要です。\n\n\n    - 一部のJenkinsジョブは複雑すぎてすぐにGitLabに移行できない場合がある：そのため、[GitLab\n    Jenkinsプラグイン](https://plugins.jenkins.io/gitlab-plugin/)を活用し、JenkinsのパイプラインをGitLabから直接起動し、結果を表示できるようにするとよいでしょう。これにより、一部の処理を徐々にGitLabに移行し、最終的にパイプライン全体をGitLabへ統合できます。\n\n\n    -\n    GitLabが提供する組み込みテンプレートを活用し、[セキュリティスキャナーやコード品質チェック](https://docs.gitlab.com/ja-jp/user/application_security/)を最初から導入する：これにより、セキュリティのシフトレフトを行い、漏洩のリスクを低減できます。\n\n    また、CI/CDの設定を過度に複雑にしないようにし、すべての機能を一度に活用しようとするのではなく、コードをモジュール化し、複数の小さなステップに分けて導入するようにしてください。\n\n\n    - モニタリングとガバナンスを最初から実装する。\n\n\n    - GitLab\n    Runner（Go）はJenkinsエージェント（Java）とは動作が異なる可能性があることを理解する：CPU使用率やメモリ消費量が異なる可能性があるため、時間をかけて比較しながら調整する必要があります。\n\n\n    - 自動スケーリングの導入を検討し、週末や業務時間外に不要なリソースをシャットダウンすることを検討する。\n\n\n    -\n    ジョブのコンテナ化を進め、アプリケーション開発をモダナイズする：現在ではJenkinsのジョブはコンテナ上ではなく、仮想マシン（VM）として動作するJenkinsエージェント上で実行されます。\n\n\n    このリストはすべての考慮事項を網羅しているわけではありませんが、移行を進めるうえで重要なポイントを押さえています。さらにサポートが必要な場合は、GitLabの[プロフェッショナルサービス](https://about.gitlab.com/ja-jp/get-help/)を活用し、移行プロセスをスムーズに進めることも可能です。\n\n\n    ### 関連リンク\n\n    ここまでお読みいただきありがとうございます！本ガイドが、JenkinsからGitLabへ移行するメリットと手順を理解する助けとなれば幸いです。まだ迷っている方は、ぜひ[GitLabの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)でDevSecOpsプラットフォームの価値を実感してください！\n\n\n    さらに詳しく知りたい方のために、GitLabの機能やDevSecOpsプラットフォームのメリット、Jenkinsからの移行に関する情報を学べるリソースをいくつかご紹介します。\n\n\n    - [Jenkinsからの移行（英語）](https://docs.gitlab.com/ja-jp/ci/migration/jenkins/)\n\n    -\n    [移行計画の立て方（英語）](https://docs.gitlab.com/ja-jp/ci/migration/plan_a_migration/)\n\n    - [GitLabプロジェクトインポーター（英語）](https://docs.gitlab.com/ja-jp/user/project/import/)\n\n    -\n    [チュートリアル：簡単にできるGitHubからGitLabへの移行（英語）](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n\n    -\n    [動画：簡単にできるGitHubからGitLabへの移行（英語）](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n\n    - [JenkinsからGitLabへ:\n    CI/CD環境をモダナイズするための究極ガイド（英語）](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n\n\n    \u003Cbr>\n\n    \u003Cbr>\n\n\n    *監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n\n    （GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\u003Cbr>\n  category: devsecops\n  tags:\n    - CI/CD\n    - DevSecOps\n  updatedDate: '2025-04-15'\nconfig:\n  slug: jenkins-to-gitlab-migration-made-easy\n  featured: true\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":31,"ogImage":19,"ogUrl":32,"ogSiteName":33,"ogType":34,"canonicalUrls":32},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",[37,11],"cicd",[22,23],"XvZKSGJlvYpUbPCpTiS4TW4kdY86KaBd6zqm8tlHDV4",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":370,"minimal":403,"duo":420,"switchNav":429,"pricingDeployment":440},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/ja-jp/","gitlab logo","header",{"text":48,"config":49},"無料トライアルを開始",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"お問い合わせ",{"href":55,"dataGaName":56,"dataGaLocation":46},"/ja-jp/sales/","sales",{"text":58,"config":59},"サインイン",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,186,191,292,352],{"text":64,"config":65,"cards":67},"プラットフォーム",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":71,"config":72},"プラットフォームを探索",{"href":73,"dataGaName":66,"dataGaLocation":46},"/ja-jp/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":78,"config":79},"GitLab Duoのご紹介",{"href":80,"dataGaName":81,"dataGaLocation":46},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":86,"config":87},"詳細はこちら",{"href":88,"dataGaName":89,"dataGaLocation":46},"/ja-jp/why-gitlab/","why gitlab",{"text":91,"left":14,"config":92,"link":94,"lists":98,"footer":168},"製品",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":46},"/ja-jp/solutions/",[99,123,146],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,111,114,119],{"text":22,"config":109},{"href":110,"dataGaLocation":46,"dataGaName":22},"/ja-jp/solutions/continuous-integration/",{"text":75,"config":112},{"href":80,"dataGaLocation":46,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"ソースコード管理",{"href":117,"dataGaLocation":46,"dataGaName":118},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":46,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":46,"icon":130},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"アプリケーションセキュリティテスト",{"href":128,"dataGaName":135,"dataGaLocation":46},"Application security testing",{"text":137,"config":138},"ソフトウェアサプライチェーンの安全性",{"href":139,"dataGaLocation":46,"dataGaName":140},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"ソフトウェアコンプライアンス",{"href":144,"dataGaName":145,"dataGaLocation":46},"/ja-jp/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"測定",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":46},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[154,158,163],{"text":155,"config":156},"可視性と測定",{"href":151,"dataGaLocation":46,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"バリューストリーム管理",{"href":161,"dataGaLocation":46,"dataGaName":162},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":164,"config":165},"分析とインサイト",{"href":166,"dataGaLocation":46,"dataGaName":167},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLabが活躍する場所",[171,176,181],{"text":172,"config":173},"大企業",{"href":174,"dataGaLocation":46,"dataGaName":175},"/ja-jp/enterprise/","enterprise",{"text":177,"config":178},"スモールビジネス",{"href":179,"dataGaLocation":46,"dataGaName":180},"/ja-jp/small-business/","small business",{"text":182,"config":183},"公共部門",{"href":184,"dataGaLocation":46,"dataGaName":185},"/ja-jp/solutions/public-sector/","public sector",{"text":187,"config":188},"価格",{"href":189,"dataGaName":190,"dataGaLocation":46,"dataNavLevelOne":190},"/ja-jp/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":279},"リソース",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"すべてのリソースを表示",{"href":198,"dataGaName":194,"dataGaLocation":46},"/ja-jp/resources/",[200,233,251],{"title":201,"items":202},"はじめに",[203,208,213,218,223,228],{"text":204,"config":205},"インストール",{"href":206,"dataGaName":207,"dataGaLocation":46},"/ja-jp/install/","install",{"text":209,"config":210},"クイックスタートガイド",{"href":211,"dataGaName":212,"dataGaLocation":46},"/ja-jp/get-started/","quick setup checklists",{"text":214,"config":215},"学ぶ",{"href":216,"dataGaLocation":46,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"製品ドキュメント",{"href":221,"dataGaName":222,"dataGaLocation":46},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":224,"config":225},"ベストプラクティスビデオ",{"href":226,"dataGaName":227,"dataGaLocation":46},"/ja-jp/getting-started-videos/","best practice videos",{"text":229,"config":230},"インテグレーション",{"href":231,"dataGaName":232,"dataGaLocation":46},"/ja-jp/integrations/","integrations",{"title":234,"items":235},"検索する",[236,241,246],{"text":237,"config":238},"お客様成功事例",{"href":239,"dataGaName":240,"dataGaLocation":46},"/ja-jp/customers/","customer success stories",{"text":242,"config":243},"ブログ",{"href":244,"dataGaName":245,"dataGaLocation":46},"/ja-jp/blog/","blog",{"text":247,"config":248},"リモート",{"href":249,"dataGaName":250,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":252,"items":253},"つなげる",[254,259,264,269,274],{"text":255,"config":256},"GitLabサービス",{"href":257,"dataGaName":258,"dataGaLocation":46},"/ja-jp/services/","services",{"text":260,"config":261},"コミュニティ",{"href":262,"dataGaName":263,"dataGaLocation":46},"/community/","community",{"text":265,"config":266},"フォーラム",{"href":267,"dataGaName":268,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"イベント",{"href":272,"dataGaName":273,"dataGaLocation":46},"/events/","events",{"text":275,"config":276},"パートナー",{"href":277,"dataGaName":278,"dataGaLocation":46},"/ja-jp/partners/","partners",{"background":280,"textColor":281,"text":282,"image":283,"link":287},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":284,"config":285},"ソースプロモカード",{"src":286},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":288,"config":289},"最新情報を読む",{"href":290,"dataGaName":291,"dataGaLocation":46},"/ja-jp/the-source/","the source",{"text":293,"config":294,"lists":296},"会社情報",{"dataNavLevelOne":295},"company",[297],{"items":298},[299,304,310,312,317,322,327,332,337,342,347],{"text":300,"config":301},"GitLabについて",{"href":302,"dataGaName":303,"dataGaLocation":46},"/ja-jp/company/","about",{"text":305,"config":306,"footerGa":309},"採用情報",{"href":307,"dataGaName":308,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":46},{"text":313,"config":314},"経営陣",{"href":315,"dataGaName":316,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":318,"config":319},"チーム",{"href":320,"dataGaName":321,"dataGaLocation":46},"/company/team/","team",{"text":323,"config":324},"ハンドブック",{"href":325,"dataGaName":326,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"投資家向け情報",{"href":330,"dataGaName":331,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"トラストセンター",{"href":335,"dataGaName":336,"dataGaLocation":46},"/ja-jp/security/","trust center",{"text":338,"config":339},"AI Transparency Center",{"href":340,"dataGaName":341,"dataGaLocation":46},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"ニュースレター",{"href":345,"dataGaName":346,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"プレス",{"href":350,"dataGaName":351,"dataGaLocation":46},"/press/","press",{"text":53,"config":353,"lists":354},{"dataNavLevelOne":295},[355],{"items":356},[357,360,365],{"text":53,"config":358},{"href":55,"dataGaName":359,"dataGaLocation":46},"talk to sales",{"text":361,"config":362},"サポートを受ける",{"href":363,"dataGaName":364,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":366,"config":367},"カスタマーポータル",{"href":368,"dataGaName":369,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":371,"login":372,"suggestions":379},"閉じる",{"text":373,"link":374},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":375,"config":376},"GitLab.com",{"href":60,"dataGaName":377,"dataGaLocation":378},"search login","search",{"text":380,"default":381},"提案",[382,384,389,391,395,399],{"text":75,"config":383},{"href":80,"dataGaName":75,"dataGaLocation":378},{"text":385,"config":386},"コード提案（AI）",{"href":387,"dataGaName":388,"dataGaLocation":378},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":22,"config":390},{"href":110,"dataGaName":22,"dataGaLocation":378},{"text":392,"config":393},"GitLab on AWS",{"href":394,"dataGaName":392,"dataGaLocation":378},"/ja-jp/partners/technology-partners/aws/",{"text":396,"config":397},"GitLab on Google Cloud",{"href":398,"dataGaName":396,"dataGaLocation":378},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":400,"config":401},"GitLabを選ぶ理由",{"href":88,"dataGaName":402,"dataGaLocation":378},"Why GitLab?",{"freeTrial":404,"mobileIcon":408,"desktopIcon":413,"secondaryButton":416},{"text":48,"config":405},{"href":406,"dataGaName":51,"dataGaLocation":407},"https://gitlab.com/-/trials/new/","nav",{"altText":409,"config":410},"GitLabアイコン",{"src":411,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":409,"config":414},{"src":415,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":201,"config":417},{"href":418,"dataGaName":419,"dataGaLocation":407},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":421,"mobileIcon":425,"desktopIcon":427},{"text":422,"config":423},"GitLab Duoの詳細について",{"href":80,"dataGaName":424,"dataGaLocation":407},"gitlab duo",{"altText":409,"config":426},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":428},{"src":415,"dataGaName":412,"dataGaLocation":407},{"button":430,"mobileIcon":435,"desktopIcon":437},{"text":431,"config":432},"/switch",{"href":433,"dataGaName":434,"dataGaLocation":407},"#contact","switch",{"altText":409,"config":436},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":438},{"src":439,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":441,"mobileIcon":446,"desktopIcon":448},{"text":442,"config":443},"料金ページに戻る",{"href":189,"dataGaName":444,"dataGaLocation":407,"icon":445},"back to pricing","GoBack",{"altText":409,"config":447},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":449},{"src":415,"dataGaName":412,"dataGaLocation":407},{"title":451,"button":452,"config":457},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":453,"config":454},"GitLab Transcendを今すぐ視聴",{"href":455,"dataGaName":456,"dataGaLocation":46},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":458,"icon":459,"disabled":14},"release","AiStar",{"data":461},{"text":462,"source":463,"edit":469,"contribute":474,"config":479,"items":484,"minimal":684},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":464,"config":465},"ページのソースを表示",{"href":466,"dataGaName":467,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":470,"config":471},"このページを編集",{"href":472,"dataGaName":473,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":475,"config":476},"ご協力をお願いします",{"href":477,"dataGaName":478,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":480,"facebook":481,"youtube":482,"linkedin":483},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[485,530,580,623,650],{"title":187,"links":486,"subMenu":501},[487,491,496],{"text":488,"config":489},"プランの表示",{"href":189,"dataGaName":490,"dataGaLocation":468},"view plans",{"text":492,"config":493},"Premiumを選ぶ理由",{"href":494,"dataGaName":495,"dataGaLocation":468},"/ja-jp/pricing/premium/","why premium",{"text":497,"config":498},"Ultimateを選ぶ理由",{"href":499,"dataGaName":500,"dataGaLocation":468},"/ja-jp/pricing/ultimate/","why ultimate",[502],{"title":53,"links":503},[504,506,508,510,515,520,525],{"text":53,"config":505},{"href":55,"dataGaName":56,"dataGaLocation":468},{"text":361,"config":507},{"href":363,"dataGaName":364,"dataGaLocation":468},{"text":366,"config":509},{"href":368,"dataGaName":369,"dataGaLocation":468},{"text":511,"config":512},"ステータス",{"href":513,"dataGaName":514,"dataGaLocation":468},"https://status.gitlab.com/","status",{"text":516,"config":517},"利用規約",{"href":518,"dataGaName":519,"dataGaLocation":468},"/terms/","terms of use",{"text":521,"config":522},"プライバシーに関する声明",{"href":523,"dataGaName":524,"dataGaLocation":468},"/ja-jp/privacy/","privacy statement",{"text":526,"config":527},"Cookie 優先設定",{"dataGaName":528,"dataGaLocation":468,"id":529,"isOneTrustButton":14},"cookie preferences","ot-sdk-btn",{"title":91,"links":531,"subMenu":540},[532,536],{"text":533,"config":534},"DevSecOpsプラットフォーム",{"href":73,"dataGaName":535,"dataGaLocation":468},"devsecops platform",{"text":537,"config":538},"AI支援開発",{"href":80,"dataGaName":539,"dataGaLocation":468},"ai-assisted development",[541],{"title":542,"links":543},"トピック",[544,547,552,557,562,565,570,575],{"text":22,"config":545},{"href":546,"dataGaName":37,"dataGaLocation":468},"/ja-jp/topics/ci-cd/",{"text":548,"config":549},"GitOps",{"href":550,"dataGaName":551,"dataGaLocation":468},"/ja-jp/topics/gitops/","gitops",{"text":553,"config":554},"DevOps",{"href":555,"dataGaName":556,"dataGaLocation":468},"/ja-jp/topics/devops/","devops",{"text":558,"config":559},"バージョン管理",{"href":560,"dataGaName":561,"dataGaLocation":468},"/ja-jp/topics/version-control/","version control",{"text":23,"config":563},{"href":564,"dataGaName":11,"dataGaLocation":468},"/ja-jp/topics/devsecops/",{"text":566,"config":567},"クラウドネイティブ",{"href":568,"dataGaName":569,"dataGaLocation":468},"/ja-jp/topics/cloud-native/","cloud native",{"text":571,"config":572},"コーディングのためのAI",{"href":573,"dataGaName":574,"dataGaLocation":468},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":576,"config":577},"エージェント型AI",{"href":578,"dataGaName":579,"dataGaLocation":468},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":581,"links":582},"ソリューション",[583,586,588,593,597,600,603,606,608,610,613,618],{"text":133,"config":584},{"href":128,"dataGaName":585,"dataGaLocation":468},"Application Security Testing",{"text":120,"config":587},{"href":105,"dataGaName":106,"dataGaLocation":468},{"text":589,"config":590},"アジャイル開発",{"href":591,"dataGaName":592,"dataGaLocation":468},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":594,"config":595},"SCM",{"href":117,"dataGaName":596,"dataGaLocation":468},"source code management",{"text":22,"config":598},{"href":110,"dataGaName":599,"dataGaLocation":468},"continuous integration & delivery",{"text":159,"config":601},{"href":161,"dataGaName":602,"dataGaLocation":468},"value stream management",{"text":548,"config":604},{"href":605,"dataGaName":551,"dataGaLocation":468},"/ja-jp/solutions/gitops/",{"text":172,"config":607},{"href":174,"dataGaName":175,"dataGaLocation":468},{"text":177,"config":609},{"href":179,"dataGaName":180,"dataGaLocation":468},{"text":611,"config":612},"公共機関",{"href":184,"dataGaName":185,"dataGaLocation":468},{"text":614,"config":615},"教育",{"href":616,"dataGaName":617,"dataGaLocation":468},"/ja-jp/solutions/education/","education",{"text":619,"config":620},"金融サービス",{"href":621,"dataGaName":622,"dataGaLocation":468},"/ja-jp/solutions/finance/","financial services",{"title":192,"links":624},[625,627,629,631,634,636,638,640,642,644,646,648],{"text":204,"config":626},{"href":206,"dataGaName":207,"dataGaLocation":468},{"text":209,"config":628},{"href":211,"dataGaName":212,"dataGaLocation":468},{"text":214,"config":630},{"href":216,"dataGaName":217,"dataGaLocation":468},{"text":219,"config":632},{"href":221,"dataGaName":633,"dataGaLocation":468},"docs",{"text":242,"config":635},{"href":244,"dataGaName":245,"dataGaLocation":468},{"text":237,"config":637},{"href":239,"dataGaName":240,"dataGaLocation":468},{"text":247,"config":639},{"href":249,"dataGaName":250,"dataGaLocation":468},{"text":255,"config":641},{"href":257,"dataGaName":258,"dataGaLocation":468},{"text":260,"config":643},{"href":262,"dataGaName":263,"dataGaLocation":468},{"text":265,"config":645},{"href":267,"dataGaName":268,"dataGaLocation":468},{"text":270,"config":647},{"href":272,"dataGaName":273,"dataGaLocation":468},{"text":275,"config":649},{"href":277,"dataGaName":278,"dataGaLocation":468},{"title":293,"links":651},[652,654,656,658,660,662,664,668,673,675,677,679],{"text":300,"config":653},{"href":302,"dataGaName":295,"dataGaLocation":468},{"text":305,"config":655},{"href":307,"dataGaName":308,"dataGaLocation":468},{"text":313,"config":657},{"href":315,"dataGaName":316,"dataGaLocation":468},{"text":318,"config":659},{"href":320,"dataGaName":321,"dataGaLocation":468},{"text":323,"config":661},{"href":325,"dataGaName":326,"dataGaLocation":468},{"text":328,"config":663},{"href":330,"dataGaName":331,"dataGaLocation":468},{"text":665,"config":666},"Sustainability",{"href":667,"dataGaName":665,"dataGaLocation":468},"/sustainability/",{"text":669,"config":670},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":671,"dataGaName":672,"dataGaLocation":468},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":674},{"href":335,"dataGaName":336,"dataGaLocation":468},{"text":343,"config":676},{"href":345,"dataGaName":346,"dataGaLocation":468},{"text":348,"config":678},{"href":350,"dataGaName":351,"dataGaLocation":468},{"text":680,"config":681},"現代奴隷制の透明性に関する声明",{"href":682,"dataGaName":683,"dataGaLocation":468},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":685},[686,688,691],{"text":516,"config":687},{"href":518,"dataGaName":519,"dataGaLocation":468},{"text":689,"config":690},"Cookieの設定",{"dataGaName":528,"dataGaLocation":468,"id":529,"isOneTrustButton":14},{"text":521,"config":692},{"href":523,"dataGaName":524,"dataGaLocation":468},[694],{"id":695,"title":9,"body":26,"config":696,"content":698,"description":26,"extension":25,"meta":702,"navigation":14,"path":703,"seo":704,"stem":705,"__hash__":706},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":697},"BlogAuthor",{"name":9,"config":699},{"headshot":700,"ctfId":701},"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",[708,724,737],{"content":709,"config":722},{"date":710,"authors":711,"heroImage":713,"title":714,"description":715,"body":716,"category":11,"tags":717},"2026-04-24",[712],"GitLab Japan Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776319994/uiregzmtojom32pmlq7y.jpg","開発基盤をGitLabに集約するSBI証券がAI時代に描く展望【GitLab Transcend Japan Fireside Chat】","2026年2月10日にGitLabが開催した「GitLab Transcend Japan」では、株式会社SBI証券 執行役員 IT企画部長 武藤恵慈氏にご登壇いただき、GitLab合同会社Head of Japan 小澤正治とのFireside Chat（対談）を行いました。その模様をレポートします。","2026年2月10日に[GitLabが開催した「GitLab Transcend Japan」](https://about.gitlab.com/ja-jp/blog/event-report-transcend-tokyo-2026/)では、株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈 氏にご登壇いただき、GitLab合同会社 Head of Japan 小澤 正治とのFireside Chat（対談）を行いました。その模様をレポートします。\n\n## AI時代、GitLabはエンタープライズ市場で輝く\n\n「GitLab Transcend Japan」では、国内の先進企業をゲストに招いたFireside Chat（炉端談義）を実施しました。ネット証券業界を牽引する株式会社SBI証券 執行役員IT企画部長 武藤 恵慈 氏とGitLab合同会社 Head of Japan 小澤 正治の対談形式です。\n\n対談に先立って、小澤は今回のイベントで発表された新しいAIのプラットフォームによる「インテリジェント・オーケストレーション」という新戦略を踏まえ、GitLabがエンタープライズ企業に提供できる本質的な価値として、3つのキーポイントを提示しました。\n\n![GitLab合同会社 Head of Japan 小澤 正治](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776320064/i7mwkbtxlh3lundhoojh.jpg \"GitLab合同会社 Head of Japan 小澤 正治\")\n\nまずは、フルコンテキストを保持できること。小澤は、「AIがシステムの状況を正しく理解し、的確に動くための必須条件は、ソフトウェア開発に関わるすべてのトランザクションデータを持っていることです」と語ります。企画から開発、運用までのあらゆる履歴を単一のプラットフォームで管理するGitLabの製品思想が、AI全盛の現在において最大の強みとして生きてきます。\n\n次に、Tech SaaSソリューションでありながらSelf-hostedの選択肢も提供していること。GitLabは、オンプレミス版の提供も引き続き重要な要素と位置づけており、金融機関をはじめとする高いセキュリティ要件や独自のガバナンスが求められるユーザー環境に合わせて、柔軟に活用できる点が強みになります。\n\n最後に、伴走サービスを提供できること。GitLabは日本にもプロフェッショナル・サービス・チームを置き、SBI証券様にもご利用いただいています。小澤は「テクノロジーは、導入して終わりではありません。それを組織にしっかりと定着させ、お客様と一緒になってTo-Be像＝あるべき姿を作り上げていくためには、伴走支援が有効になるケースが多いのです」と話しました。\n\n## SBI証券の開発基盤はシステム乱立状態から内製化へと大きく変わった\n\n対談の冒頭で武藤氏は、SBI証券のシステムの成り立ちと、これまでの歴史について会場にシェアしてくれました。SBI証券は、日本のネット証券業界でナンバーワンの座にあり、いまでも口座数や預り資産残高は飛躍的な成長を遂げています。しかし、創業以来約20年にわたるシステムの歴史は平坦なものではありませんでした。\n\n![株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776320066/ptnyonbnq4z1kha5znhu.jpg \"株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏\")\n\n武藤氏は、「以前は、大手ベンダーさんに大規模なシステムの構築を丸投げしていました。その後、協力していただくベンダーさんやパートナーさんが増え、結果として細かなシステムから大規模システムまでが乱立する状態になってしまったのです。10年前は、まさに“カオス”でしたね」と述懐します。「プログラミング言語も、採用しているプラットフォームもバラバラ。その時々で、最適なものを場当たり的に作っているような状態でした」。\n\n危機感を抱いた同社は、徐々にシステムの標準化に着手。さらに5年ほど前からはクラウドへの移行を強力に推進してきました。\n\n「証券会社として、日々新しいサービスを世に出し続けなければなりません。一方、その裏では老朽化したシステムの移行やリプレイスといった多数のプロジェクトが走っています。現在も、信じられないほど膨大な数の案件が並行して動いている状況です」（武藤氏）\n\n同社は、内製化も進めています。IT部門が自らの手でプロダクトを生み出すことで、変化対応力の高い強力なビジネスプラットフォームを作り上げたいという判断です。2025年、内製化をより強力に推進するにあたって、開発環境を統一し、エンジニアが本来の仕事である「コードを書くこと」に集中できる環境を整えるという大きな決断を下しました。GitLabの導入です。\n\n武藤氏は、「個人的には、システムにかかわる部分は基本的にすべてGitLabの中で一元管理したいと考えています。エンジニアは、コードを書きたいという思いが強いもの。そこを中心に開発サイクルを回せるようにしたかったのです」と話しています。\n\n## 「セキュリティ vs スピード」のジレンマを抱える中で、AIは“ガバナンスの番人”になれるか\n\n![写真左から株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏、GitLab合同会社 Head of Japan 小澤正治](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776320066/ggqhinnyx9bujia9zqct.jpg \"写真左から株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏、GitLab合同会社 Head of Japan 小澤正治\")\n\n証券システムには、「絶対にシステムを止めてはいけない」、「1円たりとも間違えてはならない」という絶対的な使命があります。一方でビジネス側からは「スピード」が求められます。これら相反する要求の間には、どうしてもギャップが生まれてしまいます。\n\n小澤は、「厳しいセキュリティとコンプライアンスが求められる中で、具体的にどのようにAIを活用されていく展望をお持ちでしょうか」と問いかけました。\n\n対して武藤氏は「お客様の資産を守ることが最も重要であり、セキュリティは絶対的なもの」と前置きした上で、現場のリアルな課題についてシェアしてくれました。「確実なシステムを作るために、開発の各フェーズでのチェックや承認を人の手で行っているのが現状です。しかし、個々の確認作業は待ち時間を生みます。さらに、セキュリティチェックがボトルネックになって開発効率を落とす要因になってしまっています」（武藤氏）\n\nコードを早く書くためのコーディングアシスタントとしてAI活用を進めつつ、武藤氏がAIに寄せる真の期待はこのリアルな課題の解決です。AIを「ガバナンスの番人」として機能させたいという展望です。\n\n「プロセスの正当性や、きちんとしたものができているかどうかのチェックを人手だけに頼るのではなく、AIの力を借りたいと考えています。人とAIが協調することで、スピード感を持って、堅実なシステムを生み出す仕組みを作り上げたいのです」（武藤氏）\n\n小澤は、「GitLabは開発効率を落とさずにセキュリティ要件を担保する仕組みづくりを支援できことを強みとしていますが、武藤さんの目から見ると、開発効率とセキュリティは両立できるものなのでしょうか」とさらに核心を突きます。\n\n武藤氏は、「できると思っています」と即答し、「そうしたギャップをうまく埋めてくれる存在がAIであり、GitLabのようなプラットフォームなのだと感じています」と話します。これまで、その解は“成熟したエンジニアを集めること”でした。優秀なメンバーがそろえば、短期間で安全なシステムを作れます。しかしながら、膨大な数の案件が並行して動いている状況において、すべてのプロジェクトをベテランで固めることは不可能です。品質を担保するためにすべてのプロジェクトに画一的かつ重厚なプロセスを適用すれば、開発効率は著しく低下します。そんなジレンマを抱えていた中で、AIが登場しました。\n\n「エンジニア個人の技術力に過度に頼らなくても、AIが品質やセキュリティのチェックをある程度担保してくれる。プロジェクトを効率的に進めるための的確なアドバイスをしてくれる。そうした視点でAIを活用できれば、両立は十分に可能になるでしょう」（武藤氏）\n\n## AIの活用でエンジニアは“本来の働き方”をできるようになる\n\n対談の終盤、テーマはIT人材の確保と定着へと移りました。現在、SBI証券には約300人の社員エンジニアが在籍し、多数のパートナー企業と協力して開発を進めています。内製化を推進する同社ですが、武藤氏は「チームの中でエンジニアを定着させるのはすごく難しいですし、新しい人材を採用するのも容易ではありません。身も蓋もない言い方をしてしまえば、当社のような事業会社のシステム部門は、就職市場でもいまいち人気がないんですよね……」と語り、聴講者の中に大きく頷く方々の姿も見られました。\n\nなぜ定着が難しいのでしょう。巨大な金融システムを安定稼働させるためには、詳細な確認作業や他部門との調整、各種書類作成などにも多くの時間を割くことになります。技術力を高めたいエンジニアにとって、こうした業務スタイルがフラストレーションの原因となるケースも出てきます。\n\n武藤氏は、「ルーティン作業やチェックをAIが担ってくれれば、人がやらなくても大丈夫な部分が圧倒的に増えます。そして、エンジニアはアーキテクチャの設計や、ビジネス側と連携したプロダクト創りそのものに使える時間を存分に確保できるようになるはずです」と語ります。AIが雑務を引き受けることで、エンジニアは本来のクリエイティブな業務に回帰できるのです。武藤氏は、この変化を起こすことができれば人材にとって魅力的な組織になれるとして、次のように語りました。\n\n「事業者側で主体的にビジネス価値を生むプロダクトを作る仕事は、本来エンジニアにとってやり甲斐があるはずなのです。AIの活用でそうした環境を整えることができれば、より多くの優秀なエンジニアが集まり、活躍できる組織になれます。人材獲得や定着の面でも、AIには大いに期待しています」",[718,719,23,273,622,720,721],"AI/ML","customers","security","user stories",{"featured":14,"template":15,"slug":723},"fireside-chat-transcend-tokyo-2026",{"content":725,"config":735},{"category":11,"date":726,"authors":727,"tags":728,"body":731,"title":732,"description":733,"heroImage":734},"2026-04-16",[712],[718,729,719,730,273,720,721],"collaboration","DevSecOps platform","2026年2月、GitLabは「Developers Summit 2026」に出展しました。本イベントにてスタッフ・リージョナル・マーケティングマネージャー川口 修平が、ピクシブ社のプロダクト開発ギルド Unit Leadのbash様と講演をおこないましたので、本記事にてその模様をレポートします。本講演ではピクシブ社がLLM利用率80％を実現した道筋について、川口がbash様からお話を伺いました。  \n\n![スタッフ・リージョナル・マーケティングマネージャー川口 修平](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/f5tilfouvx6il813daog.png \"スタッフ・リージョナル・マーケティングマネージャー川口 修平\")\n\n### ピクシブ社とは\n\n* 創作プラットフォーム「pixiv」を中核としてさまざまな創作活動を楽しむための事業を展開  \n* 社員数約400名で、そのうち開発者は約230名、エンジニアは約170名\n\n### GitLabとは\n\n* GitLabとは、AIネイティブDevSecOpsプラットフォーム  \n* GitLabは100ヵ国以上100,000以上の組織、5,000万以上のユーザーが利用\n\n![GitLabとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300556/x78nxrnwucp2aezdgiz4.png)\n\n### GitLab社とは\n\n* 2,000名以上の従業員（66ヵ国以上）  \n* オールリモート企業（世界中にオフィス無し）\n\n## Beyond the code時代へ ピクシブ社のなかで起きている変化とは？\n\nDevelopers Summit 2026のテーマは「Beyond the Code」です。LLMの性能向上により、ソフトウェア開発における定型作業の自動化など、バックオフィスやプロダクト開発の現場での、業務が最適化されています。\n\nそうしたなかで、ピクシブ社ではどのような変化が起きているか伺いました。\n\n「現在のエンジニアリングにおいて、単にコードを書き出す作業（タイピング）の価値よりも、その背後にある設計思想や『なぜそれを作るのか』という思考の価値がより高まっています。\n\n・背景をどう読み取り、なぜそのアプローチを選んだか\\\n・ほかにどんな選択肢があり、なぜそれをしなかったか\n\nという思考プロセスが、より重要になってきています。\n\nピクシブ社内にエンジニアギルドという組織があり、そこでそういったプロセスを大事にすることを2018年から行なってきました。少し先手を打てたかなというところがあり、これに沿って成果を上げようとしています。」\n\n## LLM利用率80％を実現！ピクシブが実践した「People・Process・Technology」三位一体の変革とは？\n\n![LLM利用率80％を実現！ピクシブが実践した「People・Process・Technology」三位一体の変革とは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/bf2q2iv8npbkrevn1nn5.jpg \"ピクシブ社プロダクト開発ギルドUnit Lead、bash氏\")\n\nピクシブ社のこうした変化は、まさに「Beyond the Code」を体現したものです。このような変化に対応する際に避けて通れないのが「自分たちがまず変わること」だと思います。\n\nけれど人は成功体験があったり確立されたプロセスがあったりすると、簡単に変わることはできません。そこで紹介したいのが、「People（人）、Process（プロセス）、Technology（テクノロジー）」というアプローチです。これは、まずTechnologyを抜本的に変え、それに合わせてProcessを整備し、それに応じてPeopleが変わっていくというアプローチになります。\n\n![「People（人）、Process（プロセス）、Technology（テクノロジー）」](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300553/ggrofuaaefmlz98fmf6h.png)\n\nGitLab社には、この変革実現アプローチでLLM時代に対応しているお客様が多くいらっしゃいます。ピクシブ社でも、同様のアプローチにてLLM利用率80％を達成されたとのことです。実際、どのようにして進められたのかをbash様に伺いました。\n\n### 3つの要素が螺旋形に絡み合いながら進化してきた\n\n「我々の変革は線形に進んできたわけではありません。それぞれの要素が螺旋形に絡み合いながら進化してきました。\n\nたとえば新しい技術を選定すると、人の行動が変わります。それに合わせて仕組みも変わってきて、そうこうしているうちに、次の新しい技術やバージョンが進展し、さらに変容するといった感じです。こういった相互作用を生み出しながら動いてきたのが実際のところです。\n\nこうした変革の成果として、LLM利用率80％・社内満足度90％・活用意欲向上95％を達成しました。」\n\n![3つの要素が螺旋形に絡み合いながら進化してきた](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300555/e5flajpmbn4jufsjgvkj.png)\n\nピクシブ社のLLM利用率80％という成果は、従業員各自が勝手にLLMを使ったというデータではありません。会社が決めたLLMを会社が決めたルールに沿って使った成果であり、そう考えるとLLM利用率80％というのは非常に素晴らしいです。\n\nここからはLLM利用率80％という成果を、People・Process・Technologyという3つの観点でどう達成されたかを伺います。\n\n### Technologyの変革 | GitLab Ultimate有償版の導入へ\n\n![Technologyの変革 | GitLab Ultimate有償版の導入へ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300553/pem3xgd49evviusemriy.png)\n\nまずはTechnologyの変革について、bash様に時系列で教えていただきました。\n\n「まず2013年にGitLabをGUI付きGitサーバーとして導入しました。2024年に大きな転換点がありGitLab Ultimateを導入し、SDLC（ソフトウェア開発ライフサイクル）をEnd to Endでカバーする基盤として本格的に整備を開始しています。\n\nまた、セキュリティスキャンや開発のバリューストリームの可視化などを実装し、それと両輪みたいなかたちでLLMの活用も開始しました。」\n\n#### GitLabを選定した理由\n\n次にGitLabを選定した理由について伺いました。\n\n「ツールチェーンvsプラットフォームがひとつの論点になりました。そのなかでツールチェーンと比べGitLabならコストを圧縮できるうえ、ライフサイクルを一貫して全体最適を狙いやすいという結論が出たのです。\n\nブラックボックス的なベンダーロックインにならないこともポイントでした。そのほか、セルフマネージメントで、必要に応じバッチをあてたりバージョンアップしたりできるという柔軟性も決め手になっています。」\n\n#### GitLab導入によるツールチェーンの解消\n\n![GitLab導入によるツールチェーンの解消](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776217764/k59vea5wbi5ck5uuf56g.png)\n\nGitLabを選定いただく理由として、ツールチェーン解消というポイントはよく挙げられます。そこで、ツールチェーンを運用するなかでの苦労について、bash様に伺いました。\n\n「エンジニア個人としては、ツール選びは楽しいですし自分にフィットする良いものを選びたいという気持ちはあります。そういったジレンマと戦う必要がある点が苦労ですね。\n\n組織レベルに引き上げて考えると、ツールチェーンに含まれるプロダクトはたくさんあります。これらをそれぞれで選定していると、契約上のスケールメリットが乏しくなるのです。小口契約ですと既成プランしか選択肢にならず、大口だとできるような大きな相談ができなくなりますからね。\n\nまた社内で使うツールのフラグメントがあると、メンバー異動が大変だったり、キャッチアップが難しかったり問題がどんどん出てきます。実用の苦労としては、個人・チームレベル・組織全体の最適が少しずつずれてくるという点がありますね。\n\nさらに、ツールチェーンでやるといろいろ選べるので、ところどころ入れ替えが難しい。意図せぬシャドーIT化だったり、外部ソリューションに頼るべきところを自分たちで作り込んでしまったりといった問題も発生します。」\n\n反対にプラットフォームのメリットについてうかがったところ、bash様は次のように話されました。\n\n「全体最適を追求しやすかったり、組織レベルでマクロの成果を見定めやすかったりする点が魅力ですね。ここで鍵となるのが人です。人をプラットフォームに寄せる必要が出てきて、ここが重要なポイントであり難しい点ですね。」\n\n#### GitLab Ultimateを導入しセキュリティ対策に着手した背景\n\n![GitLab Ultimateを導入しセキュリティ対策に着手した背景](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776217764/fq6ihuwnobueybhkxbro.png)\n\n次にGitLab Ultimate導入によるセキュリティ対策に着手した背景について、bash様に伺いました。\n\n「安全性・堅牢性を高めるためセキュリティが重要なのはもちろんですが、開発ライフサイクルとしても、インシデントはペースを乱す要素です。我々の開発体制は、運用とばらばらではありません。\n\nプロダクトを作って運用して、動かして維持してというのをホールチーム体制で続けているので、インシデントは開発時でも重要なイシューです。コードpush時のCIでは防げないサプライチェーンアタックや、外部要因で突然脆弱性が問題になることがあります。こういった問題を回避し、ホールチーム体制での開発継続性を大事にしたかったのです。」\n\n#### GitLab Ultimateを活用したピクシブのセキュリティ対策\n\nLLMの利用にあたって、セキュリティ脆弱性は重大な課題になります。IPAが毎年出しているレポートによれば、「2025年の企業におけるセキュリティ脅威 Top10」の第4位が「システムの脆弱性を悪用した攻撃」でした。またLLMが生成したコードについては、その45％に脆弱性が含まれているという調査もあります。\n\nこうしたなかで、ピクシブがどのようなセキュリティ対策を行っているか伺いました。\n\n![GitLab Ultimateを活用したピクシブのセキュリティ対策](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300558/zetxd9f9q7uwnfu05xe7.png)\n\n「いろいろあります。マージリクエストを実行する際、常に機械チェックをかけています。あとメインブランチを常にリリース可能な状態にしており、そこにあるソースコードに対し常にセキュリティスキャンをかけている状況です。ほかにもIaC構築や権限分離、レビュー・テスト・ライブラリ管理・アップデートなど、基本的な対策を忠実に行っています。\n\nただ、セキュリティは果てのない戦いなので、もう大丈夫とかもう十分な水準ということはありません。日々、改善し続けるためみんなで頑張っているという状況です。」\n\nピクシブが行っているのはリリース前のセキュリティスキャンだけ（DevOps+Sec）ではありません。開発サイクル全体でセキュリティスキャンが常に行われている状態（DevSecOps）です。\n\nこのように堅牢な体制があるからこそ、ピクシブでは自由にできる面もあるとのことでした。具体的に、どのようなことを自由に行えているのかbash様に伺いました。\n\n「たとえば開発者が自分にとって使いやすいIDEやツールを選べるように、複数の選択肢を設けています。また業務用PCも、ベンダーもスペックも自由にアレンジできる制度を長く運用している状況です。全体最適化を狙いつつ、各個人にあったツールを使っていこうという裁量の幅も設けています。」\n\n### Processの変革 |　①組織体制の整備\n\n![Processの変革 |　①組織体制の整備](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300559/ezjeke9kibifmm9znk29.png)\n\n次にProcessの変革についてbash様に伺いました。\n\n「まず組織体制の整備は欠かせません。LLM活用の取り組みは経営層と連携し、全社的に行わなければなかなか進まないと思います。各組織がそれぞれ単独で頑張っても難しいので、CTOの牽引力がキーとなり組織として横断的に推進する体制を整えました。\n\n開発サイクル全体でみるとCOE（Center of Excellence）を設置し、プロダクトを横断する関心事として進めています。LLMについては、組織の技術推進という文脈で専任部署が中心となって取り組みを進めた感じです。\n\nトップダウンでガイドラインを示し、LLMを活用しようというメッセージを出しました。一方で現場は自律的に、現場に即したものをどんどん活用し盛り上げています。トップダウンとボトムアップの両面から、推進しているという感じですね。」\n\n### Processの変革 |　②SDLCの整備\n\n「Processの変革について、2点目はSDLCの整備ということで、開発サイクルの健康診断を実施しました。パフォーマンスチューニングにプロファイリングが必要なように、『計測なくして改善なし』です。\n\nその結果、わかりやすいボトルネック工程があったわけでなく、複合的な問題が複数見つかりました。それに合わせた次の取り組みを考えていこうという状況です。」\n\nbash様がお話しされた「開発サイクルの健康診断」というキーワードは、まさにGitLabの特徴を表しています。GitLabは、開発サイクル全体のデータがひとつのプラットフォームに集約されるので、その一元化されたデータに基づいた生産性の可視化をすることができます。この可視化された生産性に基づいて開発サイクルの健康診断を実施されたとのことでした。\n\n### Processの変革 |　③評価制度の整備\n\n「Processの変革について、3つ目は評価制度の整備です。特に新しい評価制度を作ったわけでなく、生産性指標を評価に使うなという話はずっとしています。\n\nこれはよくあるアンチパターンとして、生産性指標を評価に用いることでうまくいかなくなるというのはよく聞いていました。うまくいかないことをペナルティと捉えてしまったりとか、『なぜそうなったか』を詰めたりするのは本当によくありません。\n\n生産性指標はあくまで改善のための情報であり、人を評価査定するための道具でないとはよく言っています。」\n\nProcessの変革について最後に、社内で好意的に受け止められたかをbash様に伺いました。\n\n「好意的というか『うまくいったらいいね』と、温かい目で見守ってくれた感じです。\n\n私としても、これがみんなの飛びつくような高関心領域になるとまで期待していません。ただ『ちょっと手間をかけるといっぱいいいことがある』という風に思ってもらえたら上々だな、と考えています。」\n\n### Peopleの変革 | ①Whole Teamカルチャー醸成\n\n最後にPeopleの変革についてbash様に伺いました。\n\n「ひとつ目は『Whole Team』カルチャーの醸成です。ひとつのチームとしてプロダクトに関する責任を持つことで、職種や役割を超えた相互支援ができます。\n\n品質・セキュリティ・パフォーマンスなど、推進担当の仕事にしてしまうのでなく、自分たちの仕事という意識をもつのです。そうしてCoEがそれを支援する、というのを前提にします。」\n\n### Peopleの変革 | ②LLMの性能を最大化する環境への配慮\n\n「次に、LLMを開発を支える強力なツールと捉え、性能を最大限に引き出せるよう、情報の整理の仕方（コンテキストの渡し方）を工夫することです。これまで人間が読むための情報としてまとめてきたコンテキストを、これからはLLMも読みやすくしなければならないという風に考え方を転換します。そうしてコンテキストを、LLMが処理できる組織知としての情報にするのです。」\n\n### Peopleの変革 | ③強い意志と責任感\n\n「3つ目は強い意志と責任感です。『LLMがこう出力したから』は理由になりません。自分の責任として『なぜ』を突き詰めるのです。\n\n前述したエンジニアギルドというところの活動で、『なぜそれをするのか』を考える習慣をエンジニア全員に頑張って根付かせてきました。こういった活動も役立っているなと思います。」\n\n### 採用について工夫していること\n\n入ってくる方にどういった素質があれば、ピクシブのこういった環境に適応できるのでしょうか。bash様に採用で重視する点を伺いました。\n\n「ミッションへのコミットメントをベースに、組織・事業・プロダクト・システムなどみんなで作っていくことについて大事にしていますね。」\n\n## ピクシブが目指すBeyond the code時代におけるあるべきエンジニア像とは？\n\n![ピクシブが目指すBeyond the code時代におけるあるべきエンジニア像とは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300556/y8ceh3zywuayp0bvhwmo.jpg)\n\n最後にピクシブが目指すBeyond the code時代におけるエンジニア像を伺いました。\n\n「エンジニアとはエンジニアリングを行う職種で、エンジニアリングとは、再現可能なプロセスを確立して継続することだと考えています。\n\n確かにコードを書ける能力は重要で、我々もエンジニアに求めるところです。エンジニア職といっても、インフラエンジニア、社内ライフエンジニア、開発エンジニアなどたくさんの役割がありますが、コードを通じて対話をする基礎能力は、どのエンジニアであれ役割であれ共通です。\n\nもちろん全員が常にコードを書くわけではありませんし、役割ごとに業務も違います。ただし問題をどう解釈しどんな手段で解決するか、という判断基準は共通であるべきです。なぜそれをしてなぜほかのやり方を取らなかったのか、を説明する責任はどのエンジニアにもあります。\n\nコードを書かないことの先にあるものを、今まで大事にしてきました。今後もそれを大事にして、まぐれ当たりでない再現可能なプロセスを積み重ねていく本質追求の姿勢が、エンジニアにとって重要だと考えます。」\n\n## まとめ\n\n本講演ではピクシブがLLM利用率を48％から80％へ、わずか1年で拡大させた変革の全体像をお話いただきました。ピクシブは、Technology、Process、Peopleという3つの要素を三位一体で変革してきたとのことです。\n\nTechnologyの変革ではツールチェーンをGitLabに統合し、プロセス全体にセキュリティを組み込むなどしてLLM活用の土台として整備しました。\n\nProcessの変革では経営と連携し、全社プロジェクトとしてCOEを立ち上げたとのことです。そうしてソフトウェア開発ライフサイクル全体を可視化し、守るべきガイドラインを示し、そのうえで評価制度を整備しました。\n\n最後にPeopleの変革では、Whole Teamカルチャーを醸成して、ひとつの目標を共有して全員で助け合う文化を根付かせたとのことです。そうしてLLMの性能を最大化するための配慮をしました。\n\nピクシブでは、この3つを変革することで、Beyond the code時代の変化に対応していったということです。今回のお話が皆様のヒントになれば幸いでございます。\n\n![ノベルティのシール](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/actim4eue89tuftgp1gj.jpg \"ノベルティのシール\")\n\n> 生産性のオーバーヘッドを極小化する開発支援ツール戦略を加速。[お客様事例：ピクシブ](https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-pixiv/)を読む","LLM利用率80%への道筋 ピクシブが実践した「People・Process・Technology」開発環境の三位一体の変革とは？","2026年2月、GitLabは「Developers Summit 2026」に出展しました。本イベントにてスタッフ・リージョナル・マーケティングマネージャー川口 修平が、ピクシブ社のプロダクト開発ギルド Unit Leadのbash様と講演をおこないましたので、本記事にてその模様をレポートします。本講演ではピクシブ社がLLM利用率80％を実現した道筋について、川口がbash様からお話を伺いました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776048599/gt0yoiimqorpdkne4kfm.jpg",{"featured":14,"template":15,"slug":736},"developers-summit-2026-spring-event-report",{"content":738,"config":746},{"heroImage":739,"body":740,"authors":741,"updatedDate":710,"date":742,"title":743,"tags":744,"description":745,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762140/zuh6yujweuoaixks5lul.jpg","2026年2月10日、GitLab は「GitLab Transcend Japan」を開催しました。本記事では、ビデオとセッションの模様を中心にレポートします。\n\n## **SaaSはAgentic AIの「主語」であるべき**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762586/uqq532hneioadonhyl6i.jpg \"GitLab合同会社 Head of Japan 小澤 正治\")\n\nGitLab は2026年2月10日、東京・六本木ヒルズクラブで「GitLab Transcend Japan」を開催しました。今回のイベントは、世界12都市で同日開催されたグローバルカンファレンスの一環で、GitLabを先進的に活用されている国内ユーザーの皆様の中から、グローバルで選定された方々を招待して実施しました。\n\nオープニングセッションには、GitLab Head of Japan 小澤 正治が登壇。小澤は、AIが急速に普及し「手段」として定着しつつある現状を踏まえ、Tech [SaaS](https://about.gitlab.com/ja-jp/blog/what-is-saas/)のあり方を再定義する必要性について以下のように語りました。\n\n「これからは、[Agentic AI](https://about.gitlab.com/ja-jp/topics/agentic-ai/)（自律型のAI）そのものを主語として考えるSaaSなのか、それともSaaSというプラットフォームを主語にして考えるAgentic AIなのか、この違いが問われる時代になります」\n\n統合プラットフォームであるGitLabは、ソフトウェア開発における複雑なワークフローをコントロールし、すべてのトランザクションをデータとして蓄積しています。そして、この膨大かつ正確なデータ群のおかげで、人やAIはコンテキスト（文脈）としてその全容を理解できるようになるのです。つまり、AIが精度の高い回答を提供してくれるか否かは、こうしたデータがそろっているかどうかが大きなカギになるわけです。「これこそ、GitLabが提供できる根源的な価値になります」（小澤）。\n\n小澤は、現在の日本企業を取り巻く環境について、3つの重要なトピックを挙げました。サイバーセキュリティと法規制、円安と輸出規制、および2025年の崖と人材不足です。\n\nサイバーセキュリティと法規制では、サイバー攻撃によるインシデントが多発する中、NIST（米国国立標準技術研究所）のガイドラインなど、国内外の法規制への対応が必須となっています。もはやセキュリティは「努力目標」ではなく「経営課題」と言える状況です。円安と輸出規制では、円安が輸出企業にとって追い風になる一方、欧州のサイバーレジリエンス法（CRA）やGDPRなどの規制をクリアしなければグローバル市場で戦えません。これらがビジネスのハードルになるケースが増えてきています。最後の2025年の崖と人材不足では、レガシーシステムのモダナイゼーションを推進できるIT人材の確保が多くの企業にとって悩みの種になっています。\n\nGitLabは、これらの課題に対しシングルプラットフォームという価値でこたえることができます。\n\n小澤は、「ソフトウェア開発のすべてをGitLab上で行うことで、データは単一のデータストアに蓄積されます。分断されたツール群では成し得ないこのデータとコンテキストの一元化こそが、AI活用における最大の武器になります。また、コンプライアンスやガバナンスに強制力を効かせながら、効率を下げずにソフトウェア開発することで、安心・安全なデリバリーが可能になるのです」と語りました。\n\n## **インテリジェント・オーケストレーションがソフトウェア開発の未来を切り拓く**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/aquhu0vpb07ibmortwhg.jpg \"会場の様子\")\n\n続いて、会場のスクリーンで全世界に向けたビデオが放映されました。GitLab CEO Bill Staplesをはじめとする経営陣、そして先進的なユーザー企業が登場し、AI時代の新たなソフトウェア開発戦略の発表の場です。\n\nStaplesは、「月曜の朝、コーヒーを片手にPCを開き、仕事をスタートさせます。しかし、実際にコードを書く時間はどれくらいあるでしょう？」と語りかけます。[25万人の開発者を対象とした調査](https://about.gitlab.com/ja-jp/developer-survey/japan/)によると、開発者が実際にコードを書いている時間は、1日平均でわずか52分に過ぎません。残りの時間は、会議、承認待ち、障害対応、およびその他の雑務に奪われているのです。\n\nこれがAIのパラドックスです。AIコーディングツールは、生産性10倍とうたいますが、それは業務全体のわずか10〜20%に過ぎないコーディング時間を短縮しているだけ。前後のプロセスにあるボトルネックが解消されない限り、ビジネス全体のデリバリー速度は劇的には向上しないのです。\n\nこの課題を解消するために、Staplesは「インテリジェント・オーケストレーション」という方向性を提唱します。これまでの開発は、人間がバケツリレーのように工程を渡していく「ステージベース」でした。これからは、AIエージェントが自律的にタスクを拾い、プロセス間を繋ぐ形へとシフトします。\n\n「人間はループの上に立ち、エージェントをオーケストレーション（指揮）する役割へと進化します」（Staples）と語ります。雑務から解放され、戦略や創造的な意思決定に集中する未来の姿がそこにあります。\n\n続いて、このビジョンを実践している企業として、サウスウエスト航空社のManaging Director、Grant Morris氏が登場しました。同社は、個別最適化されたツール群を捨て、GitLabでソフトウェア開発の全プロセスを統合。セキュリティとコンプライアンスを担保しながら開発者がビジネス価値の創出に集中できる環境を整備しています。\n\nAI活用についてGrant氏は、「セキュリティ修正や依存関係のアップデートなど、エンジニアが疲弊するルーティンワークをAIエージェントに任せています」と語ります。さらに将来は、「AIエージェントがバックグラウンドで常にコードを監視し、リファクタリング（ソフトウェアの内部コード構造を整理する作業）やアップグレードを自律的に提案してくれるようになるでしょう。つまり、技術的負債という概念自体が過去のものになります」と語りました。\n\n続いて登場したGitLab CPMOのManav Khuranaは、インテリジェント・オーケストレーションを実現するための製品戦略について解説しました。\n\nまずは、AIエージェントをGitLab内で機能させる基盤となるAgentic Coreの進化。リポジトリやイシューなどをAIがコンテキストとして理解できるように構造化する独自技術を提供します。汎用的なエージェントに加え、各社独自のノウハウを組み込んだCustom Agentsを作成・公開できるAI Catalogを用意し、JiraやSlackなど外部ツールからもコンテキストを取得するためにModel Context Protocol （MCP）にも対応します。\n\n既存機能の強化では、複雑なYAMLを書かずにAIと対話しながらパイプラインを構築できるAIファーストのCI/CDビルダーや、あらゆる成果物をGitLab内で一元管理し、AIエージェントが機密性の高い状態でも安全にアクセスできる仕組みを構築します。\n\nGitLabは、SaaSだけでなく、オンプレミス環境でも利用できます。AIもオンプレミスで利用できるよう、ガバナンスを効かせた状態でAIを活用できる環境も提供します。独自のAIモデルを持ち込むBYOM（Bring Your Own Model）や、インターネット遮断環境（エアギャップ）にも対応します。\n\nビデオの終盤には、Oracle Group VPであるVictor Restrepo氏が登場し、GitLabとの強力なパートナーシップについて語りました。Restrepo氏は、Oracle Cloud Infrastructure （OCI）のコストパフォーマンスとGitLabの効率性を組み合わせることでインフラコストを削減し、その分をイノベーション投資に回すクラウドエコノミクスの重要性を強調。「政府系クラウドや専用リージョンを持つOCI上でGitLabを稼働させれば、厳しい規制が課される業界でもセキュアにAIを活用できるようになります」とGitLabとの親和性についても語りました。\n\n## **コンテキストを理解し、自律的に動くAIエージェント**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/etl4f4uhcggrndlhwgr2.jpg \"GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一\")\n\nビデオで披露された最新機能について、次のセッションで実機デモを交えた解説が行われました。その際にも強調されたのは、コンテキストの重要性です。AIエージェントが的確な仕事をするためには、プロジェクトの全容を理解している必要があります。企画から監視までをシングルプラットフォームで管理しているGitLabだからこそ、AIは断片的な情報ではなく、プロジェクトの全履歴という文脈を理解した上で自律的に動くことができるのです。\n\nデモでは、まず[Duo Planner Agent](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/planner/)を紹介。「こんな感じの機能をリリースしたい」という人間からの曖昧な指示に対し、AIはバックログや現状のコードベースを分析し、数分で具体的なタスクへと分解し、実行計画を立案してくれます。[Duo CLI](https://docs.gitlab.com/ja-jp/cli/duo/cli/)のデモでは、ターミナル上での作業をAIが支援してくれる様子が披露されました。対話内容はWeb UIと同期されるため、開発者はツール間を行き来することなく、シームレスに作業を継続できます。\n\n[Foundational Flows](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/)のデモでは、CIパイプラインが失敗した際にワンクリックでAIがログを解析してくれました。原因の特定から修正コードの作成、そして修正用マージリクエストの作成まで、AIが自律的に支援してくれます。[Security Analyst Agent](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)も便利です。脆弱性が検出された際に、単に警告を出すだけではなく、AIエージェントが「なぜ危険なのか」を解説し、具体的な修正パッチを作成してくれます。\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/a9yas83dxdhjopxifx5z.jpg \"写真左から株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏、GitLab合同会社 Head of Japan 小澤正治\")\n\n最後のセッションには、国内の先進事例として、株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏をお招きし、小澤とのFireside Chatを実施しました。かつてはシステムや言語が乱立する課題を抱えていた同社は内製化へと大きく舵を切り、大規模かつ多数のプロジェクトを効率的に推進しています。詳細なセッション内容は、[開発基盤をGitLabに集約するSBI証券がAI時代に描く展望【GitLab Transcend Japan Fireside Chat】](https://about.gitlab.com/ja-jp/blog/fireside-chat-transcend-tokyo-2026/)で公開しています。\n\nこの日のイベントでは、Staplesの以下の発言が印象に残りました。\n\n「ソフトウェア開発は、コードを書くことから価値を創ることへと変化しています」\n\nGitLabは単なるツールから、人間とAIエージェントが協調して働くための基盤である「インテリジェント・オーケストレーション・プラットフォーム」へと進化します。AIのパラドックスを乗り越え、開発者が真のイノベーションに注力できる未来へ。「Transcend（=超越）」というイベント名にふさわしい、新たな時代が幕を開けます。",[712],"2026-03-10","AIのパラドックスを解くカギはインテリジェント・オーケストレーション【GitLab Transcend Japanレポート】",[718,22,719,23,273,720,721],"2026年2月10日に開催した「GitLab Transcend Japan」の模様をレポートします。\n",{"featured":14,"template":15,"slug":747},"event-report-transcend-tokyo-2026",{"promotions":749},[750,764,776,787],{"id":751,"categories":752,"header":754,"text":755,"button":756,"image":761},"ai-modernization",[753],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":757,"config":758},"Get your AI maturity score",{"href":759,"dataGaName":760,"dataGaLocation":245},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":762},{"src":763},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":765,"categories":766,"header":768,"text":755,"button":769,"image":773},"devops-modernization",[767,11],"product","Are you just managing tools or shipping innovation?",{"text":770,"config":771},"Get your DevOps maturity score",{"href":772,"dataGaName":760,"dataGaLocation":245},"/assessments/devops-modernization-assessment/",{"config":774},{"src":775},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":777,"categories":778,"header":779,"text":755,"button":780,"image":784},"security-modernization",[720],"Are you trading speed for security?",{"text":781,"config":782},"Get your security maturity score",{"href":783,"dataGaName":760,"dataGaLocation":245},"/assessments/security-modernization-assessment/",{"config":785},{"src":786},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":788,"paths":789,"header":792,"text":793,"button":794,"image":799},"github-azure-migration",[790,791],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":795,"config":796},"See how GitLab compares to GitHub",{"href":797,"dataGaName":798,"dataGaLocation":245},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":800},{"src":775},{"header":802,"blurb":803,"button":804,"secondaryButton":808},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":48,"config":805},{"href":806,"dataGaName":51,"dataGaLocation":807},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":53,"config":809},{"href":55,"dataGaName":56,"dataGaLocation":807},1777493638867]