[{"data":1,"prerenderedAt":1185},["ShallowReactive",2],{"/ja-jp/blog/":3,"navigation-ja-jp":21,"banner-ja-jp":437,"footer-ja-jp":450,"blogCategories-ja-jp":660,"relatedBlogPosts-ja-jp":781,"maineFeaturedPost-ja-jp":1149,"recentFeaturedPosts-ja-jp":1153,"recentPosts-ja-jp":1169},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":13,"_id":15,"_type":16,"title":7,"_source":17,"_file":18,"_stem":19,"_extension":20},"/ja-jp/blog","ja-jp",false,"",{"title":9,"description":10},"Blog","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"title":12},"GitLab Blog",{"template":14},"BlogHome","content:ja-jp:blog:index.yml","yaml","content","ja-jp/blog/index.yml","ja-jp/blog/index","yml",{"_path":22,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":433,"_type":16,"title":434,"_source":17,"_file":435,"_stem":436,"_extension":20},"/shared/ja-jp/main-navigation",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":411,"duo":424},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/ja-jp/","gitlab logo","header",{"text":30,"config":31},"無料トライアルを開始",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"お問い合わせ",{"href":37,"dataGaName":38,"dataGaLocation":28},"/ja-jp/sales/","sales",{"text":40,"config":41},"サインイン",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,299,359],{"text":46,"config":47,"cards":49,"footer":72},"プラットフォーム",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":53,"config":54},"プラットフォームを詳しく見る",{"href":55,"dataGaName":48,"dataGaLocation":28},"/ja-jp/platform/",{"title":57,"description":58,"link":59},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":60,"config":61},"GitLab Duoのご紹介",{"href":62,"dataGaName":63,"dataGaLocation":28},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":68,"config":69},"詳細はこちら",{"href":70,"dataGaName":71,"dataGaLocation":28},"/ja-jp/why-gitlab/","why gitlab",{"title":73,"items":74},"利用を開始：",[75,80,85],{"text":76,"config":77},"プラットフォームエンジニアリング",{"href":78,"dataGaName":79,"dataGaLocation":28},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"開発者の経験",{"href":83,"dataGaName":84,"dataGaLocation":28},"/ja-jp/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"製品",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":28},"/ja-jp/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/ja-jp/solutions/continuous-integration/",{"text":113,"config":114},"AIアシストによる開発",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"ソースコード管理",{"href":119,"dataGaLocation":28,"dataGaName":120},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/ja-jp/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"ソフトウェアサプライチェーンの安全性",{"href":142,"dataGaLocation":28,"dataGaName":143},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"測定",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"可視性と測定",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"バリューストリーム管理",{"href":163,"dataGaLocation":28,"dataGaName":164},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"分析とインサイト",{"href":168,"dataGaLocation":28,"dataGaName":169},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLabが活躍する場所",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/ja-jp/enterprise/","enterprise",{"text":179,"config":180},"スモールビジネス",{"href":181,"dataGaLocation":28,"dataGaName":182},"/ja-jp/small-business/","small business",{"text":184,"config":185},"公共機関",{"href":186,"dataGaLocation":28,"dataGaName":187},"/ja-jp/solutions/public-sector/","public sector",{"text":189,"config":190},"価格",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/ja-jp/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"関連リソース",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"すべてのリソースを表示",{"href":200,"dataGaName":196,"dataGaLocation":28},"/ja-jp/resources/",[202,235,258],{"title":203,"items":204},"はじめに",[205,210,215,220,225,230],{"text":206,"config":207},"インストール",{"href":208,"dataGaName":209,"dataGaLocation":28},"/ja-jp/install/","install",{"text":211,"config":212},"クイックスタートガイド",{"href":213,"dataGaName":214,"dataGaLocation":28},"/ja-jp/get-started/","quick setup checklists",{"text":216,"config":217},"学ぶ",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"製品ドキュメント",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"ベストプラクティスビデオ",{"href":228,"dataGaName":229,"dataGaLocation":28},"/ja-jp/getting-started-videos/","best practice videos",{"text":231,"config":232},"インテグレーション",{"href":233,"dataGaName":234,"dataGaLocation":28},"/ja-jp/integrations/","integrations",{"title":236,"items":237},"検索する",[238,243,248,253],{"text":239,"config":240},"お客様成功事例",{"href":241,"dataGaName":242,"dataGaLocation":28},"/ja-jp/customers/","customer success stories",{"text":244,"config":245},"ブログ",{"href":246,"dataGaName":247,"dataGaLocation":28},"/ja-jp/blog/","blog",{"text":249,"config":250},"リモート",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/ja-jp/teamops/","teamops",{"title":259,"items":260},"つなげる",[261,266,271,276,281],{"text":262,"config":263},"GitLabサービス",{"href":264,"dataGaName":265,"dataGaLocation":28},"/ja-jp/services/","services",{"text":267,"config":268},"コミュニティ",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"フォーラム",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"イベント",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"パートナー",{"href":284,"dataGaName":285,"dataGaLocation":28},"/ja-jp/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":291,"config":292},"ソースプロモカード",{"src":293},"/images/navigation/the-source-promo-card.svg",{"text":295,"config":296},"最新情報を読む",{"href":297,"dataGaName":298,"dataGaLocation":28},"/ja-jp/the-source/","the source",{"text":300,"config":301,"lists":303},"Company",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"GitLabについて",{"href":309,"dataGaName":310,"dataGaLocation":28},"/ja-jp/company/","about",{"text":312,"config":313,"footerGa":316},"採用情報",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"経営陣",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"チーム",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"ハンドブック",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"投資家向け情報",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"トラストセンター",{"href":342,"dataGaName":343,"dataGaLocation":28},"/ja-jp/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":28},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"ニュースレター",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"プレス",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":35,"config":360,"lists":361},{"dataNavLevelOne":302},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"サポートを受ける",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"カスタマーポータル",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"閉じる",{"text":380,"link":381},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":382,"config":383},"GitLab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"提案",[389,392,397,399,403,407],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"コード提案（AI）",{"href":395,"dataGaName":396,"dataGaLocation":385},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":398},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":400,"config":401},"GitLab on AWS",{"href":402,"dataGaName":400,"dataGaLocation":385},"/ja-jp/partners/technology-partners/aws/",{"text":404,"config":405},"GitLab on Google Cloud",{"href":406,"dataGaName":404,"dataGaLocation":385},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":408,"config":409},"GitLabを選ぶ理由",{"href":70,"dataGaName":410,"dataGaLocation":385},"Why GitLab?",{"freeTrial":412,"mobileIcon":416,"desktopIcon":421},{"text":30,"config":413},{"href":414,"dataGaName":33,"dataGaLocation":415},"https://gitlab.com/-/trials/new/","nav",{"altText":417,"config":418},"GitLabアイコン",{"src":419,"dataGaName":420,"dataGaLocation":415},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":417,"config":422},{"src":423,"dataGaName":420,"dataGaLocation":415},"/images/brand/gitlab-logo-type.svg",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"GitLab Duoの詳細について",{"href":62,"dataGaName":428,"dataGaLocation":415},"gitlab duo",{"altText":417,"config":430},{"src":419,"dataGaName":420,"dataGaLocation":415},{"altText":417,"config":432},{"src":423,"dataGaName":420,"dataGaLocation":415},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":438,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":439,"button":440,"config":445,"_id":447,"_type":16,"_source":17,"_file":448,"_stem":449,"_extension":20},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":441,"config":442},"ベータ版を試す",{"href":443,"dataGaName":444,"dataGaLocation":28},"/ja-jp/gitlab-duo/agent-platform/","duo banner",{"layout":446},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":451,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":452,"_id":656,"_type":16,"title":657,"_source":17,"_file":658,"_stem":659,"_extension":20},"/shared/ja-jp/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":648},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":455,"config":456},"ページのソースを表示",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"このページを編集",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"ご協力をお願いします",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,553,586,620],{"title":46,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOpsプラットフォーム",{"href":55,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":189,"links":484},[485,489,494],{"text":486,"config":487},"プランの表示",{"href":191,"dataGaName":488,"dataGaLocation":459},"view plans",{"text":490,"config":491},"Premiumを選ぶ理由",{"href":492,"dataGaName":493,"dataGaLocation":459},"/ja-jp/pricing/premium/","why premium",{"text":495,"config":496},"Ultimateを選ぶ理由",{"href":497,"dataGaName":498,"dataGaLocation":459},"/ja-jp/pricing/ultimate/","why ultimate",{"title":500,"links":501},"ソリューション",[502,507,510,512,517,522,526,529,532,537,539,541,543,548],{"text":503,"config":504},"デジタルトランスフォーメーション",{"href":505,"dataGaName":506,"dataGaLocation":459},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":508,"config":509},"セキュリティとコンプライアンス",{"href":137,"dataGaName":138,"dataGaLocation":459},{"text":122,"config":511},{"href":105,"dataGaName":106,"dataGaLocation":459},{"text":513,"config":514},"アジャイル開発",{"href":515,"dataGaName":516,"dataGaLocation":459},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":518,"config":519},"クラウドトランスフォーメーション",{"href":520,"dataGaName":521,"dataGaLocation":459},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":523,"config":524},"SCM",{"href":119,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":109,"config":527},{"href":111,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":161,"config":530},{"href":163,"dataGaName":531,"dataGaLocation":459},"value stream management",{"text":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":459},"/ja-jp/solutions/gitops/","gitops",{"text":174,"config":538},{"href":176,"dataGaName":177,"dataGaLocation":459},{"text":179,"config":540},{"href":181,"dataGaName":182,"dataGaLocation":459},{"text":184,"config":542},{"href":186,"dataGaName":187,"dataGaLocation":459},{"text":544,"config":545},"教育",{"href":546,"dataGaName":547,"dataGaLocation":459},"/ja-jp/solutions/education/","education",{"text":549,"config":550},"金融サービス",{"href":551,"dataGaName":552,"dataGaLocation":459},"/ja-jp/solutions/finance/","financial services",{"title":194,"links":554},[555,557,559,561,564,566,570,572,574,576,578,580,582,584],{"text":206,"config":556},{"href":208,"dataGaName":209,"dataGaLocation":459},{"text":211,"config":558},{"href":213,"dataGaName":214,"dataGaLocation":459},{"text":216,"config":560},{"href":218,"dataGaName":219,"dataGaLocation":459},{"text":221,"config":562},{"href":223,"dataGaName":563,"dataGaLocation":459},"docs",{"text":244,"config":565},{"href":246,"dataGaName":247},{"text":567,"config":568},"お客様の成功事例",{"href":569,"dataGaLocation":459},"/customers/",{"text":239,"config":571},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":249,"config":573},{"href":251,"dataGaName":252,"dataGaLocation":459},{"text":262,"config":575},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":254,"config":577},{"href":256,"dataGaName":257,"dataGaLocation":459},{"text":267,"config":579},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":581},{"href":274,"dataGaName":275,"dataGaLocation":459},{"text":277,"config":583},{"href":279,"dataGaName":280,"dataGaLocation":459},{"text":282,"config":585},{"href":284,"dataGaName":285,"dataGaLocation":459},{"title":300,"links":587},[588,590,592,594,596,598,600,604,609,611,613,615],{"text":307,"config":589},{"href":309,"dataGaName":302,"dataGaLocation":459},{"text":312,"config":591},{"href":314,"dataGaName":315,"dataGaLocation":459},{"text":320,"config":593},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":595},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":330,"config":597},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":335,"config":599},{"href":337,"dataGaName":338,"dataGaLocation":459},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":459},"/sustainability/",{"text":605,"config":606},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":607,"dataGaName":608,"dataGaLocation":459},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":610},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":350,"config":612},{"href":352,"dataGaName":353,"dataGaLocation":459},{"text":355,"config":614},{"href":357,"dataGaName":358,"dataGaLocation":459},{"text":616,"config":617},"現代奴隷制の透明性に関する声明",{"href":618,"dataGaName":619,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":621},[622,624,626,628,633,638,643],{"text":35,"config":623},{"href":37,"dataGaName":38,"dataGaLocation":459},{"text":368,"config":625},{"href":370,"dataGaName":371,"dataGaLocation":459},{"text":373,"config":627},{"href":375,"dataGaName":376,"dataGaLocation":459},{"text":629,"config":630},"ステータス",{"href":631,"dataGaName":632,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":634,"config":635},"利用規約",{"href":636,"dataGaName":637,"dataGaLocation":459},"/terms/","terms of use",{"text":639,"config":640},"プライバシーに関する声明",{"href":641,"dataGaName":642,"dataGaLocation":459},"/ja-jp/privacy/","privacy statement",{"text":644,"config":645},"Cookieの設定",{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":649},[650,652,654],{"text":634,"config":651},{"href":636,"dataGaName":637,"dataGaLocation":459},{"text":639,"config":653},{"href":641,"dataGaName":642,"dataGaLocation":459},{"text":644,"config":655},{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",[661,675,687,699,711,723,735,747,759,770],{"_path":662,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":664,"content":667,"config":668,"_id":671,"_type":16,"title":672,"_source":17,"_file":673,"_stem":674,"_extension":20},"/ja-jp/blog/categories/agile-planning","categories",{"title":665,"description":666},"アジャイル計画","Browse articles related to アジャイル計画 on the GitLab Blog",{"name":665},{"template":669,"slug":670,"hide":6},"BlogCategory","agile-planning","content:ja-jp:blog:categories:agile-planning.yml","Agile Planning","ja-jp/blog/categories/agile-planning.yml","ja-jp/blog/categories/agile-planning",{"_path":676,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":677,"content":680,"config":681,"_id":683,"_type":16,"title":684,"_source":17,"_file":685,"_stem":686,"_extension":20},"/ja-jp/blog/categories/ai-ml",{"title":678,"description":679},"AIと機械学習","Browse articles related to AIと機械学習 on the GitLab Blog",{"name":678},{"template":669,"slug":682,"hide":6},"ai-ml","content:ja-jp:blog:categories:ai-ml.yml","Ai Ml","ja-jp/blog/categories/ai-ml.yml","ja-jp/blog/categories/ai-ml",{"_path":688,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":689,"content":692,"config":693,"_id":695,"_type":16,"title":696,"_source":17,"_file":697,"_stem":698,"_extension":20},"/ja-jp/blog/categories/bulletin-board",{"title":690,"description":691},"掲示板","Browse articles related to 掲示板 on the GitLab Blog",{"name":690},{"template":669,"slug":694,"hide":6},"bulletin-board","content:ja-jp:blog:categories:bulletin-board.yml","Bulletin Board","ja-jp/blog/categories/bulletin-board.yml","ja-jp/blog/categories/bulletin-board",{"_path":700,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":701,"content":704,"config":705,"_id":707,"_type":16,"title":708,"_source":17,"_file":709,"_stem":710,"_extension":20},"/ja-jp/blog/categories/customer-stories",{"title":702,"description":703},"お客様事例","Browse articles related to お客様事例 on the GitLab Blog",{"name":702},{"template":669,"slug":706,"hide":6},"customer-stories","content:ja-jp:blog:categories:customer-stories.yml","Customer Stories","ja-jp/blog/categories/customer-stories.yml","ja-jp/blog/categories/customer-stories",{"_path":712,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":713,"content":716,"config":717,"_id":719,"_type":16,"title":720,"_source":17,"_file":721,"_stem":722,"_extension":20},"/ja-jp/blog/categories/devsecops",{"title":714,"description":715},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":714},{"template":669,"slug":718,"hide":6},"devsecops","content:ja-jp:blog:categories:devsecops.yml","Devsecops","ja-jp/blog/categories/devsecops.yml","ja-jp/blog/categories/devsecops",{"_path":724,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":725,"content":728,"config":729,"_id":731,"_type":16,"title":732,"_source":17,"_file":733,"_stem":734,"_extension":20},"/ja-jp/blog/categories/engineering",{"title":726,"description":727},"エンジニアリング","Browse articles related to エンジニアリング on the GitLab Blog",{"name":726},{"template":669,"slug":730,"hide":6},"engineering","content:ja-jp:blog:categories:engineering.yml","Engineering","ja-jp/blog/categories/engineering.yml","ja-jp/blog/categories/engineering",{"_path":736,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":737,"content":740,"config":741,"_id":743,"_type":16,"title":744,"_source":17,"_file":745,"_stem":746,"_extension":20},"/ja-jp/blog/categories/news",{"title":738,"description":739},"ニュース","Browse articles related to ニュース on the GitLab Blog",{"name":738},{"template":669,"slug":742,"hide":6},"news","content:ja-jp:blog:categories:news.yml","News","ja-jp/blog/categories/news.yml","ja-jp/blog/categories/news",{"_path":748,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":749,"content":752,"config":753,"_id":755,"_type":16,"title":756,"_source":17,"_file":757,"_stem":758,"_extension":20},"/ja-jp/blog/categories/open-source",{"title":750,"description":751},"オープンソース","Browse articles related to オープンソース on the GitLab Blog",{"name":750},{"template":669,"slug":754,"hide":6},"open-source","content:ja-jp:blog:categories:open-source.yml","Open Source","ja-jp/blog/categories/open-source.yml","ja-jp/blog/categories/open-source",{"_path":760,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":761,"content":763,"config":764,"_id":766,"_type":16,"title":767,"_source":17,"_file":768,"_stem":769,"_extension":20},"/ja-jp/blog/categories/product",{"title":90,"description":762},"Browse articles related to 製品 on the GitLab Blog",{"name":90},{"template":669,"slug":765,"hide":6},"product","content:ja-jp:blog:categories:product.yml","Product","ja-jp/blog/categories/product.yml","ja-jp/blog/categories/product",{"_path":771,"_dir":663,"_draft":6,"_partial":6,"_locale":7,"seo":772,"content":774,"config":775,"_id":777,"_type":16,"title":778,"_source":17,"_file":779,"_stem":780,"_extension":20},"/ja-jp/blog/categories/security",{"title":126,"description":773},"Browse articles related to セキュリティ on the GitLab Blog",{"name":126},{"template":669,"slug":776,"hide":6},"security","content:ja-jp:blog:categories:security.yml","Security","ja-jp/blog/categories/security.yml","ja-jp/blog/categories/security",[782,826,868,882,926,961,1003,1038,1074,1112],{"category":665,"slug":670,"posts":783},[784,801,814],{"content":785,"config":798},{"title":786,"description":787,"authors":788,"heroImage":790,"date":791,"body":792,"category":670,"tags":793},"GitLabで実現するサイロのないSAFe","Scaled Agile Framework（SAFe）をDevSecOpsプラットフォームのネイティブ機能にマッピングする方法と、そこから得られるメリットについて学びましょう。",[789],"Amanda Rueda","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\nこのような分断は、日常業務においてさまざまな問題を引き起こします。デベロッパーは複数のシステムを行き来し、プロダクトマネージャーは正確な進捗状況を把握できず、誰もが情報を手作業でほかの場所へとコピーすることに時間を浪費します。これこそがまさに、SAFeが解消しようとしている「分断された体験」の典型です。\n\nすでに開発チームがGitLabを使ってソースコード管理、CI/CD、セキュリティを行っている場合、SAFeフレームワークでの計画管理にもGitLabを活用できるのかどうか疑問に思うかもしれません。幸いなことに、GitLabのアジャイルプロジェクト管理機能はSAFeを強力にサポートしています。この記事では、GitLabがSAFeの各種概念やセレモニーとどのように対応しているのかを紹介します。しかも、すべてデベロッパーがすでに慣れ親しんでいる同じDevSecOpsプラットフォーム上で実現できます。\n\n## SAFeとは？\n\nSAFe（Scaled Agile Framework）は、アジャイルの考え方をスピードや方向性、顧客重視の姿勢を失うことなく、大規模な組織全体に広げるための手法です。少人数チームで使われる柔軟かつ反復的なアジャイルの進め方を、複数のチームやロードマップ、関係者を抱える大規模組織にも適用できるように設計されています。このフレームワークを活用することで、組織全体の方向性が揃い、計画と実行が一貫して進むようになります。プロダクトマネージャーにとっては、SAFeを導入することで、戦略と実行をしっかりつなげることができ、とにかく早くリリースするだけでなく、チームで方向性を揃え、優先順位に基づいて本当に出すべきものをリリースできるようになります。\nSAFeはサイロを減らし、チーム間のコラボレーションを促進するとともに、単なる作業の実行ではなく、「顧客が求める成果」を中心にチームをまとめます。GitLabにSAFeを統合すると、可視性、トレーサビリティ、成果のすべてが、1か所に集約され、その効果はさらに高まります。\n\n## GitLabにおけるSAFeの用語対応\n\nまず、SAFeの概念がGitLab内でどのように対応するかを確認しましょう。\n\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\n\u003Cbr>\u003C/br>\n\nこの対応表をガイドとして活用すると、GitLabをSAFeの実装と連動させて構築できます。グループ構造を使うと、バリューストリームやART（Agile Release Train）単位で整理できます。また、最大7階層までネスト可能なエピックによる作業アイテムの階層構造により、複雑なプロダクトポートフォリオにも対応できる深さを備えています。ポートフォリオレベル（トップレベルグループ）、プログラムレベル（サブグループ）、チームレベル（プロジェクト）といった、どの階層で作業していても、GitLabの組織構造はSAFeの階層とぴったり合致します。\n\n## GitLabでのSAFeのセレモニーのサポート\n\nここからが本題です。GitLab上でSAFeのセレモニーを実際にどう実行するのか、順を追って見ていきましょう。\n\n### PIプランニング\n\nチーム間の調整と依存関係の管理を促進し、PIプランニングを成功させるために、GitLabでは以下のような機能が提供されています。\n\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)を文書化し、視覚化する\n\nGitLabでは、エピックボード（チームごとの割り当てを表示するように設定可能）とロードマップビュー（ガントチャートのように時間軸でフィーチャーを表示）を使い分けることで、柔軟にPIプランニングを進めることができます。タイムラインかチーム構成のどちらに注目するかに応じて、プランニング中にビューを切り替えられます。\n\n![ロードマップビューとエピックボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![ガントチャート付きロードマップビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### リファインメント\n\nプロダクトマネージャーにとって、効果的なリファインメントを行うには、フィーチャーのバックログを明確に把握しておくことが重要です。GitLabなら、リファインメントをそのままGitLab上で実施できます。会議中に1つのツールを更新して、その後に別のツールを更新する必要はもうありません。 \n\nGitLabでは、以下の機能によってリファインメントを効率的に進められます。\n\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\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### スプリント計画\n\n次のスプリントでチームが取り組む作業を決めるタイミングでは、GitLabの以下の機能を活用できます。\n\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\nつまり、すべてを1か所に集約して管理でき、プランニングミーティングではツールを行き来するのではなく、実際の計画に集中できます。\n\n![GitLabで行うスプリント計画](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378662/Blog/ynmq3wnf77yk6xkehkda.gif )\n\n* GitLabを活用したスクラムの進め方については、[こちら](https://docs.gitlab.com/tutorials/scrum_events/)のチュートリアルをご覧ください。アジャイルプランニングやスプリントの進捗管理におけるGitLabの便利な機能を詳しく確認できます。*\n\n### デイリースタンドアップ\n\nデイリースタンドアップでは、チーム全員がボードを囲んで、誰が何に取り組んでいるか、どこで詰まっているか、どの作業がレビュー待ちかを、すべて単一のビューで確認できます。GitLabでは、以下の機能が開発チームのデイリースタンドアップに役立ちます。\n\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\n![デイリースタンドアップのボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n### スプリントレビュー\n\nチームの進捗状況を継続的に把握したいですか？GitLabでは、以下のような包括的なメトリクスを利用できます。\n\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これらの指標により、チームのスピードが上がっているか、どこでつまずいているか、そして次回のレトロスペクティブで話し合うべきポイントを明確に把握できます。\n\n![バーンダウンチャートとバーンアップチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n## 統合プラットフォームが強みとなる5つの理由\n\nSAFeのセレモニーを管理できる計画ツールはたくさんあります。でも、GitLabが本当に他と違うと私が感じているのには、明確な理由があります。\n\n1. **頭の切り替えが不要** - 計画、コーディング、テスト、セキュリティのすべてを、1か所で完結できます。\n2. **すべてがつながっている** - 大きなエピックからコード、デプロイまで、作業の流れをたどれます。\n3. **全員が同じ認識を持てる** - デベロッパー、プロダクト担当、セキュリティチームが、同じツール上で連携できます。\n4. **完全な可視性** - ステークホルダーは、進捗の確認を1か所で行えます。\n5. **全体像が見える** - 計画と開発のメトリクスをまとめて確認できるため、本当の状況が明確になります。\n\nもしあなたの開発チームがすでにGitLabを使いこなしているなら、プランニングのためだけに別のツールへ切り替えたり、複雑なインテグレーションを無理やり組み合わせたりする必要はありません。SAFeプランニングをGitLabに取り込むことで、チーム全体にとってはるかにスムーズな体験が得られます。\n\n## 実装の原則\n\n私は従来型のSAFeツールからGitLabへの移行に取り組むチームと協力してきましたが、その経験から学んだことがあります。それは、以前のツールをそのまま再現しようとするのではなく、**それぞれのセレモニーが何を目的としているか**に注目することが重要だということです。\n\nGitLabの利点を最大限に活用しているのは、GitLabのネイティブ機能を素直に受け入れて、それに逆らわずに活用しているチームです。もちろん、SAFeの概念をどうマッピングするか、ワークフローをどう構築するかを最初に整理するには少し手間がかかります。しかし、一度その形ができてしまえば、プロセスは複雑になるどころか、むしろシンプルになります。\n\n成功のカギは、全員が従うべき規則を定義することです。どのラベルが何を意味するのか？ チームをどう追跡するのか？エピックとイシューにはそれぞれ何を入れるのか？こうした判断を事前に少し整理しておくだけで、複数ツール間の調整にかかっていた手間を解消できる、直感的なシステムが手に入ります。\n\n## 導入を始める\n\nさて、試してみる準備はできましたか？GitLabでSAFeを導入するためのステップは以下のとおりです。\n\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これらのポイントを最初にしっかり考えておくことで、後々のトラブルや混乱を避けられます。そして、初日から完璧にする必要はないことを忘れないでください。運用しながら学び、必要に応じていつでも調整できます。\n\n## すべてをまとめる\n\nGitLabは、SAFeを実行するための堅実な基盤を提供します。特に、あなたの開発チームがすでにGitLabに慣れ親しんでいる場合には最適です。計画と開発を同じツール上で進めることで、煩雑なハンドオフが不要になり、コラボレーションが格段にしやすくなり、すべての動きがよりスピーディになります。\n\nGitLabのプランニングツールの魅力は、あなたのチームに合わせて柔軟にSAFeをカスタマイズできることです。 決められた型にはまる必要はありません。チームが成熟し、ニーズが変われば、それに応じて運用方法も進化させることができます。\n\n> サイロ化したプランニングにさよならして、もっと快適なワークフローを体験してみませんか？まずは[無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)して、GitLabがどのようにSAFe導入を変革できるかを実感してください。\n\n*💡 このトピックに興味を持った方は、関連記事の[アジャイルソフトウェア開発におけるGitLabの活用法](https://about.gitlab.com/ja-jp/blog/gitlab-for-agile-software-development/)もぜひご覧ください*\n",[794,795,796,765,797],"agile","DevSecOps platform","features","tutorial",{"slug":799,"featured":91,"template":800},"safe-without-silos-in-gitlab","BlogPost",{"content":802,"config":812},{"title":803,"description":804,"authors":805,"heroImage":806,"date":807,"body":808,"category":670,"tags":809,"updatedDate":811},"アジャイルのスプリントを製品ロードマップと調和させる方法","ベストプラクティスとGitLabの機能を活用して、製品開発を進めましょう。一元化されたロードマップの作成、レビューセッションの実施、スプリントのライフサイクルの追跡など、製品開発をスムーズに進めるためのポイントを解説します。",[789],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","2025-02-04","製品チームと開発チームが協力せずに、それぞれ作業している様子を想像してみてください。たとえば、製品チームが12か月分のロードマップを作成して社内に共有したものの、開発チームのレビューは受けてなかったとします。このため、開発チームは、全体の計画を把握しないまま、次のスプリントで予定されている機能の開発を始めました。その影響で、プロジェクトの並行実施、チームキャパシティの考慮、再利用可能なAPIの構築など、本来なら最適なタイミングで進められたはずの機会を逃してしまいます。最終的に、非効率的になり、価値の提供も遅れてしまいます。\n短期的な成功と長期的なビジョンのバランスを取るのは簡単ではありません。明確なコミュニケーション、優先事項の調整、そして適切なツールが必要です。このガイドでは、アジャイルのスプリントを戦略的ロードマップと調和させる方法、よくある課題への取り組み方、チームに合わせた実践的なアプローチをご紹介します。\n\n## 信頼できる唯一の情報源の重要性\n\n長期的目標を含むロードマップに関する、信頼できる一貫した唯一の情報源があれば、チームは常に最新の全体像にアクセスできます。具体的には、ロードマップの情報をひとつのプラットフォームに集約し、定期的に更新することを意味します。逆に、一元化されていない、つまり微妙に差があるロードマップを複数管理する場合、方向性の理解にずれが生じてしまいます。\n\n### 一元化されたロードマップを作成する\n\n一元化されたロードマップを作成することで、次のことが可能になります。\n\n* 長期的な戦略を伝える\n* 伝達ミスを最小限に抑える\n* 部門間の足並みが揃いやすくなる\n* 背景を把握しながら、変化に素早く対応する\n* 情報を自分で取得でき、情報を保持する単一の窓口への依存度を減らす\n\n***GitLabに関するヒント**：[エピック](https://docs.gitlab.com/ee/user/group/epics/)と[ロードマップ表示](https://docs.gitlab.com/ee/user/group/roadmap/)を使用すれば、製品計画と進捗の透明性を確保できます。ロードマップ表示を使用すると、進捗の追跡やボトルネックの特定に加え、全体的な目標とスプリントレベルでの実施内容を確実に一致させることができます。* \n\n![グループのロードマップ表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## ロードマップの共同レビューの実施\n\n[プロダクトトリオ](https://www.producttalk.org/product-trio/)（製品チーム、エンジニアリングチーム、ユーザーエクスペリエンスチーム）は連携し、定期的なロードマップのレビューと合意を得る仕組みを作りましょう。共同レビューを行うことで、チーム間の認識が揃い、リスクの早期発見と対処につながります。GitLabのプロダクトマネージャーは、エンジニアリングマネージャー、UXデザイナーと毎月ミーティングを行い、変更内容をレビューしてもらった上で、承認を得ています。Wikiに承認の記録を残しておくことで、スケジュールへの責任を明確にし、社内の他のメンバーに対してオープンに情報を提供しています。\n\n#### レビューセッションの効果を高める方法\n\nレビューの場を有意義なものにするには、以下のベストプラクティスを意識しましょう。\n\n* ロードマップの変更頻度に応じて、月ごとまたは四半期ごとの定期的なレビューを設定する。\n\n* 潜在的なリスクや依存関係をあらかじめ議論することで、製品目標、UXのリードタイム、技術的実現可能性の間の整合性を検証する。\n\n  * ロードマップに組織のビジネス目標が反映されているかどうかを検証する。\n  * 設計のタイムラインが現実的であり、技術的な調査や検証の必要性が考慮されていることを確認する。\n\n* チームのキャパシティの制約を考慮し、作業順序をチームのスキルプロファイルに合うよう工夫して、チームの生産性を最適化する：\nこれには、休暇期間中のスタッフ減少といった状況を見越して計画を立てながら、チームの能力の活用不足やスキルのミスマッチを避けることも含まれます。\n\n* スコープを正しく設定し、何が達成できるかについて適切な期待値を設定する：\n「全部やりたい」という気持ちを抑え、何を優先すべきかを明確にし、段階的に価値を提供するよう心がけることが大切です。タスク間の依存関係を減らしたり、再利用可能なコンポーネントを活用するなど、イテレーションの改善や開発速度を上げる方法を特定して、最適化できる機会を模索します。\n\n* トレードオフや優先順位についてオープンに話し合い、多角的な視点を取り入れる：\nこのような協調的なアプローチを取ることで課題に対して新しい視点や発想を取り入れた解決策が見つかり、今後の方向性について合意を得やすくなります。\n\n***GitLabに関するヒント**：[GitLab Wiki](https://docs.gitlab.com/ee/user/project/wiki/)を活用して[ロードマップ](https://docs.gitlab.com/ee/user/group/roadmap/)機能を補完しましょう。Wikiには、ビジネス上の根拠、ユーザー調査へのリンク、RICEスコア、依存関係やリスクに関する詳細など、製品ロードマップに関する幅広いコンテキストを記載できます。アクセスしやすいようにロードマップへの直リンクを記載し、今後のディスカッションスレッド機能を活用して、非同期コラボレーションを促進し、チームからのフィードバックを得られるようにしましょう。*\n\n![PlanFlow製品のロードマップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## 継続的な方向性の検証と進捗測定\n\n製品ロードマップを作成する目的は、予定どおりに進めることだけでなく、顧客に真の価値を提供することです。ユーザーからの継続的なフィードバックや行動データを共有する機会を設けるために、スプリントのサイクルとは別に、定期的にプロダクトトリオの三者で集まる場を設けることを検討してください。このようなセッションでは、インサイトの確認やトレンドの分析、そしてユーザーの変化し続けるニーズが製品ロードマップに反映されていることを確認します。実際のユーザーから得たインサイトに基づき、ロードマップを更新することで、単に予定していた機能をリリースするだけでなく、顧客にとって本当に重要な価値を提供できます。\n顧客にとっての価値は、使いやすさの向上、技術的負債の削減、またはまったく新しい機能の提供など、さまざまです。プロダクトトリオがロードマップのビジョンで一致していれば、達成しようと目指している成果に関しても足並みが揃っている状態だと言えます。\n成果の達成に向け順調かどうかを測定するには、想定する成果がどのようなものであるかを明確に定義する必要があります。後からユーザーストーリーを追加するといったスコープクリープ（スコープの拡大）は、価値の提供を遅らせてしまう恐れがあります。さらに、ロードマップに沿っていない作業があれば、価値を提供した後であっても特定し、なぜそうなったのか理由を把握することも重要です。\n\n### スプリント計画\n\n製品ロードマップとの整合性を保つには、まずは綿密なスプリント計画を立てる必要があります。ここでは、チームが作業を順調に進め、価値の提供に重点的に取り組むために役立つベストプラクティスをいくつかご紹介します。\n\n- デリバリーに対して確信を持てるように、求める成果を明確に定義し、範囲を絞り込んで設定する。\n- デリバリーを遅らせる可能性のある遅めの段階での追加や調整を特定し、継続して注力できるようにバッファを設ける。\n- チームと作業順序を調整し、キャパシティやスキルプロファイルを最適化し、依存関係を減らす。\n- 集中力を維持し、納期遵守の確実性を高めるために、チームのキャパシティが一杯になるような計画はしないようにする。スプリント中に発生する可能性のある未知の問題や新たな発見に備えて、バッファ（10%～20%）を設けておきましょう。\n\n### スプリント期間中\n\nスプリント期間中にロードマップとの整合性を保ち続けるには、集中力とコミュニケーションに加え、継続的な評価が必要です。価値の提供が目標である一方で、進行中の作業が、事前に決めて計画した成果に沿っているかどうかを確認することも同様に重要です。\n\n- 進行中の作業をロードマップで定めた成果と照らし合わせて継続的に検証し、各スプリントが全体像に寄与しているかを確認する。\n- 想定している目標や成果に向けて引き続き取り組んでいるかどうか、定期的に確認するようチームに促す。\n- スプリントを通じてオープンなコミュニケーションを保つ：デイリースタンドアップミーティングや非同期なアップデートを用いて、リスクや予定外の作業、依存関係を早い段階で明らかにし、必要に応じて調整します。\n- 何が何でもスプリントに沿って行動する：新たに生じた問題を解決したいという衝動に駆られるのは当然ですが、事前に合意した優先順位を見失うことのないように、計画していなかった作業は慎重に見極める必要があります。\n- スコープクリープを主体的に管理する：スプリントの途中で新たな作業が出てきた場合、それが現在のロードマップで定めた注力対象にあっているかを確認しましょう。たとえ魅力的なアイデアや機能であっても、。直近の価値提供という観点では優先度が低いかもしれません。このような内容は文書化し、今後のイテレーションに含めるか、あとで検討する項目として整理しましょう。現在のスプリントで取り組むものとした優先事項を後回しにするのは避けるべきです。\n\n### スプリントレトロスペクティブ（ふりかえり）\n\nスプリントレトロスペクティブでは、チームが目指す成果にどれだけ近づけたかを「ふりかえる」時間を取りましょう。以下の質問を投げかけることをおすすめします。\n\n- スプリント期間中に、予定外の作業によって価値の提供が遅れたことはなかったか？その原因は何だったか？どのように対応すればよかったか？\n- ロードマップとずれた作業がなかったか。その背景や経緯は？今後にどう活かせるか？そこから学んだことを話し合いましょう。\n\nスプリント計画からスプリントレトロスペクティブまで、ユーザーと関係者に具体的な成果をもたらすことチームの重要な役割です。各ステップで足並みを揃えることで、ロードマップが価値を効率的かつ継続的に提供する道標になります。\n\n***GitLabに関するヒント**：[バーンダウンチャート](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)を使用すると、進捗状況が可視化され、早い段階でロードマップからの逸脱が検知できるため、チームが成果の達成に集中しやすくなります。*\n\n![バーンダウンチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## ロードマップで定めた成果を確実に実現する\n\nアジャイルのスプリントと戦略的なロードマップを結びつけるには、意図的な取り組み、チームの賛同、そして適切なツールが必要です。信頼できる唯一の情報源としてロードマップを作成し、共同レビューを実施し、進捗状況を測定することで、ビジョンに沿った行動を取ることができます。GitLabの強力な計画機能を活用することで、チームは課題をイノベーションと成長の機会へと変えることができます。\n\n早速、戦略的ロードマップに合わせてスプリントを進めてみませんか？[GitLabの無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/)して、確実に成果を実現するために役立つツールを試してみましょう。\n\n## 関連リンク\n\n* [アジャイルプランニングのコンテンツハブ](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)  \n* [アジャイルプランニングチームに特化したGitLabの新しい「プランナーロール」のご紹介](https://about.gitlab.com/ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)」（日本語）  \n* [効果的なナレッジマネジメントの実施に役立つGitLab Wikiのご紹介](https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)（英語）\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[794,797,810,795],"workflow","2025-06-04",{"slug":813,"featured":91,"template":800},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"content":815,"config":824},{"title":816,"description":817,"authors":818,"heroImage":819,"date":820,"body":821,"category":670,"tags":822,"updatedDate":823},"アジャイルプランニングチームに特化したGitLabの新しい「プランナー」ロールのご紹介","GitLabの新しい「プランナー」ロールを活用して、SaaS、GitLab Dedicated、Self-Managedといった各ソリューションでのアクセス権を最適化し、アジャイルチームの計画ワークフローを効率的に管理する方法についてご説明します。",[789],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","2024-11-25","GitLabは、DevSecOpsプラットフォームに新たなロール「プランナー」を導入しました。以前リリースされた[カスタムロール機能と同様に](https://docs.gitlab.com/ee/user/custom_roles.html)、「役割に応じた柔軟なアクセス制御を実現する」というGitLabの戦略に基づいて開発されました。このロールは、ソフトウェア開発チームや計画に携わるユーザーに対し、過剰な権限を付与することなく、アジャイル開発のワークフローを管理するために必要なツールへのアクセス権を提供します。これにより、過剰な権限付与によるセキュリティリスクの増加を防止できます。プランナーロールを活用してユーザーごとの特定のニーズに合わせてアクセスを調整することで、チームは生産性を維持しつつ、セキュリティとコンプライアンスを確保し、[最小権限の原則](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)を遵守できます。\n\n## プランナーロールが開発された理由\n\nこの新しいロールの開発は、お客様や社内チームからのフィードバックをきっかけに始まりました。GitLabはアジャイル開発サイクルを計画および管理するための包括的なツールを提供していますが、役割に基づくより具体的なアクセス制御が必要だという声が度々寄せられていました。プロダクトマネージャーやプロジェクトリード、その他の計画業務を担当する役割は、計画機能へのアクセスは必要ですが、開発全体の権限は必要ありません。実際、必要以上のアクセス権は、セキュリティリスクだけでなく、コードや重要な設定に意図しない変更を加える可能性も高めるため、好ましくありません。このようなフィードバックを受け、GitLabは対応を進めました。\n\nユーザーへの聞き取り、競合分析、そして徹底的な調査を通じて、新しいロールの必要性が明確になりました。計画ツールへの十分なアクセスを提供しつつ、デベロッパー向けの機能へのアクセスを制限することでセキュリティを確保するロールが求められていました。\n\n## プランナーロールの特徴\n\nプランナーロールは、既存の[ゲストロールとレポーターロール](https://docs.gitlab.com/ee/user/permissions.html#roles)を組み合わせたハイブリッドロールであり、計画ワークフローへのアクセスが必要なユーザー向けに特化して設計されています。\n\nこのロールを使用すると、以下のことを行えます。\n\n* 主要な計画ツール（エピック、ロードマップ、イシューボード、[OKR](https://docs.gitlab.com/ee/user/okrs.html)など）へのアクセスを許可する（*一部の機能はGitLab PremiumまたはGitLab Ultimateのライセンスが必要です*）\n* 機密性の高い開発関連の機能への不要なアクセスを制限することで、セキュリティを強化する\n* プランナーロールをGitLab Enterprise Agile Planningアドオンと併用することで、チームに計画ツールへのカスタマイズされたアクセスを提供しつつ、セキュリティと制御を維持する（*プランナーロール単体はすべてのライセンスプランで利用可能です*）\n\nプランナーロールは、SaaS、GitLab Dedicated、Self-Managedを含むすべてのGitLabソリューションで利用可能となっており、すべてのお客様がこのカスタマイズされたアクセス制御のメリットを活用できます。\n\nこのロールを使用することで、チームは職務に応じて権限を柔軟に調整でき、アクセス性とセキュリティのバランスを確保できます。\n\n## アジャイル手法の実践を後押しするプランナーロールの役割\n\n[アジャイルソフトウェア開発](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)において、各チームメンバーにそれぞれの役割に即したツールと権限を与えることは、ワークフローを効率化する上で非常に重要です。プランナーロールは、計画チームのメンバーが開発やデプロイといった領域に踏み込み過ぎるリスクを排除しつつ、ソフトウェア開発ライフサイクルの計画段階に適切に参加できるようにすることで、アジャイル開発をサポートします。\n\nプランナーロールは、エピックの作成・管理からロードマップの定義まで、アジャイルチームが連携を保ちながら効率的に業務を進めるために必要なツールを提供します。\n\n## お客様中心の設計\nこのロールは、GitLabが単独で作り上げたものではありません。プロセスのすべての段階でコミュニティの意見を取り入れてきました。具体的には、アンケート調査、インタビュー、テストを通じて、プロダクトマネージャーやプロジェクトマネージャーの実務上のニーズに合致するよう、権限を細かく調整しました。\n\nまた、このロールには「エンタープライズアジャイルチーム向けのプラットフォームを提供する」というGitLabの長年の使命が反映されており、企業がアジャイル開発手法を大規模に導入する上で必要な柔軟性と制御性を提供します。\n\n## コミュニティのフィードバックとエンゲージメント\n\nGitLabでは、皆様からのご意見を大変重視しており、新しいプランナーロールに関するご感想をぜひお聞かせいただきたいと考えています。皆様からのフィードバックは、GitLabの利用体験の改良・改善に欠かせません。ご意見やご提案がありましたら、ぜひ[フィードバック用イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/503817)からお寄せください。\n\n## 今すぐGitLabで計画を始めましょう！\n\nGitLabは、ソフトウェア開発チームの効果的な計画、コラボレーション、デリバリーをさまざまなアプローチを通じて支援しており、プランナーロールはそのうちの一つにすぎません。GitLabは、製品管理ワークフローの効率化、チームコラボレーションの強化、アジャイル手法の整備など、あらゆる目的の達成を支援する充実したツールを取り揃えています。\n\n> GitLabのすべての機能をお試しになりたい場合は、ぜひ[GitLab Ultimateの無料トライアルにご登録](https://about.gitlab.com/ja-jp/free-trial/)ください。チーム独自のニーズに合わせてカスタマイズされたプランナーロールを活用して、次のプロジェクトの計画を始めましょう。\n\n## その他の記事\n- [開発チームだけでなく、あらゆる職務に対応可能なGitLab Enterprise Agile Planningアドオン（英語）](https://about.gitlab.com/blog/gitlab-enterprise-agile-planning-add-on-for-all-roles/)\n- [GitLabをアジャイルソフトウェア開発で使用する方法](https://about.gitlab.com/ja-jp/blog/gitlab-for-agile-software-development/)\n- [初公開：新しくなったGitLabのアジャイル計画（英語）](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/)\n\n\u003Cbr>\n\u003Cbr>\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n",[794,795,796,765],"2025-05-01",{"slug":825,"featured":91,"template":800},"introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"category":678,"slug":682,"posts":827},[828,842,854],{"content":829,"config":840},{"heroImage":830,"body":831,"authors":832,"updatedDate":834,"date":835,"title":836,"tags":837,"description":839,"category":682},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1755711502/wuuadis1pza3zehqohcc.png","GitLabは現在、ソフトウェアライフサイクルのあらゆる段階を統合する包括的なDevSecOpsプラットフォームです。その基盤の上に、世界初のソフトウェアエンジニアリング向けAIネイティブプラットフォームへの進化を進めています。GitLabでは、ソフトウェアエンジニアリングの未来は本質的に人間とAIのコラボレーションにあると考えており、すべてのGitLabユーザーに最高のAI機能を提供したいと考えています。\n\nこの変革は、他のAI開発ツールが行っていることを超えた3つの異なるレイヤーで起こっています：\n\n![以下に示すAIネイティブ変革のスライド](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755762266/iwuugge3cxweiyvi0yjk.png)\n\n**第一に、記録システムです。** 統合データプラットフォームは、最も価値のあるデジタル資産を保持しています。これには、ソースコードと知的財産だけでなく、プロジェクト計画、バグバックログ、CI/CD構成、デプロイメント履歴、セキュリティレポート、コンプライアンスデータにまたがる豊富な非構造化データが含まれます。これにより、GitLab環境内に安全に保持され、汎用エージェントや大規模言語モデルでは利用できない、文脈データの宝庫が作成されます。\n\n**第二に、ソフトウェアコントロールプレーンとして機能します。** Gitリポジトリ、REST API、およびエンドツーエンドのソフトウェアデリバリーを支えるWebhookベースのインターフェースを通じて、最も重要なビジネスプロセスをオーケストレーションします。多くの顧客は、これを重要なビジネスプロセスが日常的に依存するティア0の依存関係として考えています。\n\n**第三に、強力なユーザーエクスペリエンスを提供します。** ほとんどのエンジニアリングチームの速度を低下させる負荷の高い頭の切り替えを排除するのに役立つ統合インターフェースを提供します。1つのプラットフォームで完全なライフサイクルの可視性とコラボレーションツールを提供することで、5,000万人以上の登録ユーザーと広大なコミュニティが、仕事を成し遂げるためにGitLabを活用しています。この専門知識により、GitLabは、既存の信頼できるワークフローを維持しながら、チームの生産性を増幅する直感的な人間とAIのコラボレーションを先駆的に開拓する独自の立場にあります。\n\n**あらゆるレイヤーにAIをネイティブに統合してプラットフォームを拡張**\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)は、これら3つのレイヤーすべてを統合し、拡張します。拡張性と相互運用性のために設計されており、顧客やパートナーがさらに価値を創造するソリューションを構築できるようにします。オープンプラットフォームアプローチは、3つのレイヤーすべてで既存のスタックに深く統合されながら、外部AIツールやシステムとのシームレスな接続性を重視しています。\n\n* まず、**ナレッジグラフ**で統合データプラットフォームを拡張しています。これは、コードと他のすべての非構造化データをインデックス化して結び付け、エージェントアクセスに特化して最適化されたものです。AIはコンテキストで成長し、これによりエージェントによる推論と推論を加速するだけでなく、より低コストで高品質なエージェントの成果を提供できると考えています。\n* 第二に、既存のコントロールプレーンに重要な**オーケストレーションレイヤー**を3つの異なる部分で追加しています：エージェントとフローがGitLab SDLCイベントのサブスクライバーとして登録できるようにし、目的別のマルチエージェントフローを可能にする新しいオーケストレーションエンジンを構築し、比類のない相互運用性のためにMCPと標準プロトコルを介してGitLabツール、エージェント、フローを公開します。\n* 最後に、ソフトウェア開発ライフサイクル全体にわたってファーストクラスのエージェントとエージェントフローを提供するために**GitLabエクスペリエンス**を拡張しています。エージェントに非同期タスクを割り当て、コメントで@メンションし、ワークフローに固有のコンテキストでカスタムエージェントを作成できるようになります。さらに重要なことに、GitLabは、サードパーティエージェントの豊富なエコシステムのロックを解除しながら、開発のあらゆる段階でネイティブエージェントを出荷しています。これにより、エージェントが人間のチームメイトと同じように自然に作業できる真の人間とAIのコラボレーションが生まれます。\n\nこのビデオで18.3以降の新機能をご覧いただくか、以下をお読みください。\n\n\u003Cdiv style=\"padding:75% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111796316?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.3 Release_081925_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLab 18.3の新機能\n\n18.2では、ソフトウェア開発ライフサイクル全体でデベロッパーと協力する専門的な[AIエージェント](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-public-beta/#%E3%81%99%E3%81%90%E3%81%AB%E4%BD%BF%E3%81%88%E3%82%8B%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88)と、ソフトウェア開発フローを導入しました。これは、複数のエージェントをオーケストレーションして、エンドツーエンドでコード変更を計画、実装、テストする強力な機能です。\n\nGitLab 18.3では、拡張された統合と相互運用性、より多くのフロー、そしてソフトウェア開発ライフサイクル全体でのコンテキスト認識の強化を導入しています。\n\n### 拡張された統合と相互運用性\n\nファーストパーティのGitLabエージェントとサードパーティエージェントの豊富なエコシステムの両方を通じて、包括的なAI拡張性を提供しており、すべてがプロジェクトコンテキストとデータへの完全なアクセスを持っています。このアプローチは、これらのエージェントとGitLabのコアプラットフォーム間の高度に統合されたオーケストレーションを通じて好みのツールを選択する柔軟性を提供しながら、ネイティブのGitLabワークフローとガバナンスを維持します。チームは、主要な統合、監視、ユーザーエクスペリエンスの利点を維持しながら、強化されたAI機能を獲得します。\n\n* **MCPサーバー - ユニバーサルAI統合：** GitLabのMCP（[モデルコンテキストプロトコル](https://about.gitlab.com/topics/ai/model-context-protocol/)）サーバーにより、AIシステムはGitLabプロジェクトと開発プロセスに直接安全に統合できます。この標準化されたインターフェースにより、カスタム統合のオーバーヘッドが排除され、[Cursor](https://docs.cursor.com/en/tools/mcp)を含むAIツールが既存のGitLab環境内でインテリジェントに動作できるようになります。18.3に含まれるツールの完全なリストについては、[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/)をご覧ください。**これは始まりに過ぎません。18.4では追加のツールが計画されています。**\n\n  **注：** サードパーティエージェントは、GitLab Premiumベータ機能であり、GitLab Duo Enterpriseの顧客が評価のためにのみ利用できます。\n\n> *「GitLabワークフローをCursorに直接持ち込むことは、デベロッパーの摩擦を減らすための重要なステップです。頭の切り替えの必要性を最小限に抑えることで、チームはコーディング環境を離れることなく、イシューのステータスをチェックし、マージリクエストをレビューし、パイプラインの結果を監視できます。この統合は共有顧客にとって自然な選択であり、デベロッパーの生産性を継続的に向上させるために、GitLabとの長期的なパートナーシップを楽しみにしています。」*\n>\n> \\- **Ricky Doar、Cursor フィールドエンジニアリング副社長**\n>\n> *「GitLabのMCPサーバーとCLIエージェントサポートは、Amazon Qが開発ワークフローと統合するための強力な新しい方法を作成します。Amazon Q DeveloperはGitLabのリモートMCPインターフェースを介して直接接続できるようになり、チームはイシューやマージリクエストでAmazon Q CLIを@メンションするだけで開発タスクを委任できます。これらの統合に組み込まれた堅牢なセキュリティとガバナンス機能により、企業は開発標準を維持しながら、AIコーディングツールを活用する自信を得ることができます。GitLabとのパートナーシップは、AIエコシステムを拡大し、デベロッパーが作業する場所でインテリジェントな開発ツールにアクセスできるようにするというAWSの継続的なコミットメントを示しています。」*\n>\n> \\- **Deepak Singh、AWS デベロッパーエージェントおよびエクスペリエンス担当副社長**\n\n* **Claude Code、Codex、Amazon Q、Google Gemini、opencode（独自のキーを持参）のCLIエージェントサポート：** 18.3では、イシューやマージリクエストでエージェントを直接@メンションすることで、チームが日常的な開発作業を委任できる統合を導入しています。デベロッパーがこれらのAIアシスタントにメンションすると、周囲のコンテキストとリポジトリコードを自動的に読み取り、レビュー可能なコード変更またはインラインコメントでユーザーのコメントに応答します。これらの統合では、それぞれのAIプロバイダー用に独自のAPIキーを持参する必要があり、適切な権限と監査証跡を維持しながら、すべてのやり取りをGitLabのインターフェース内でネイティブに保持します。\n\n  **注：** サードパーティエージェントは、GitLab Premiumベータ機能であり、GitLab Duo Enterpriseの顧客が評価のためにのみ利用できます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111784124?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=\"Third Party Agents Flows Claude Code\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> *「Claude CodeをGitLabに直接持ち込むことで、何百万人ものデベロッパーがすでに毎日コラボレーションしてコードを出荷している場所にAIアシスタンスを配置します。イシューやマージリクエストでClaudeを直接メンションする機能により、人間の監視とレビュープロセスで品質を維持しながら、摩擦が除去されます。このアップデートにより、Claude Codeの機能がチームが作業するより多くの場所に提供され、AIをデベロッパーワークフローの自然な一部にします。」*\n>\n> **\\- Cat Wu、Claude Code プロダクトリード、Anthropic**\n>\n> *「GitLab 18.3の新しいエージェント統合により、既存のワークフロー内でopencodeを使用できます。イシューやマージリクエストでopencodeを@メンションすると、CIパイプラインでエージェントが実行されます。この方法でopencodeを設定して実行する機能は、オープンソースコミュニティが本当に評価する統合のタイプです。」*\n>\n> **\\- Jay V.、CEO、opencode**\n\n* **すべてのPremiumおよびUltimate顧客が利用できるVisual Studio IDEおよびGitLab UIのエージェントチャットサポート：** 18.3では、GitLabの完全な開発ライフサイクルデータにアクセスするためにツール間で頭の切り替えをする必要がなくなりました。強化された統合により、GitLab DuoのフルパワーがGitLab UIとIDEにもたらされ、JetBrainsとVS Codeからのサポートが拡張され、現在はVisual Studioも含まれています。これにより、デベロッパーは好みの環境内で豊富なプロジェクトコンテキスト、デプロイメント履歴、チームコラボレーションデータに直接アクセスしながら、フローに留まることができます。\n* **拡張されたAIモデルサポート：** GitLab Duo Self-Hostedは追加のAIモデルをサポートするようになり、チームにAI支援開発ワークフローでより柔軟性を提供します。データセンターのハードウェア上でvLLMを介して、またはプライベートクラウドのAzure OpenAIやAWS Bedrockなどのクラウドサービスを介して、オープンソースのOpenAI GPTモデル（20Bおよび120Bパラメータ）をデプロイできるようになりました。さらに、AnthropicのClaude 4はAWS Bedrockで利用可能です。\n\n### 新しい自動開発フロー\n\nGitLabのフローは、複数のAIエージェントを事前構築された指示で調整し、時間のかかる日常的なタスクを自律的に処理するため、デベロッパーは最も重要な作業に集中できます。\n\nGitLab 18.3には2つの新しいフローが付属しています：\n\n* **概念から完成まで数分でコードを自動生成するイシューからMRへのフロー：** このFlowは、要件を分析し、包括的な実装計画を準備し、レビュー可能な本番グレードのコードを生成するためにエージェントを調整することにより、イシューを実行可能なマージリクエスト（MR）に自動的に変換します。アイデアを数時間ではなく数分でレビュー可能な実装に変えるのに役立ちます。\n\n\u003Cdiv style=\"padding:75% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111782058?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=\"Issue to MR\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **シームレスな移行インテリジェンスのために構築されたCI File変換フロー：** CI File変換フローは、エージェントが既存のCI/CD構成を分析し、完全なパイプライン互換性を持つGitLab CI形式にインテリジェントに変換することで、移行ワークフローを合理化します。これにより、CI構成をゼロから書き直す手動作業と潜在的なエラーが排除され、チームは自信を持ってデプロイメントパイプライン全体を移行できます。18.3にはJenkins移行のサポートが含まれています。将来のリリースでは追加サポートが計画されています。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783724?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=\"Convert to CI Flow\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### インテリジェントなコードと検索\n\nAIポイントソリューションは通常、分離されたコードスニペットへの限定的な可視性で動作しますが、GitLabのナレッジグラフは、より迅速でインテリジェントな応答を通知するための環境コンテキストをエージェントに提供します。\n\n* **リアルタイムコードインテリジェンスのためのナレッジグラフ：** 18.3では、GitLabのナレッジグラフがリアルタイムコードインデックスを提供し、より高速なコード検索を可能にし、より正確で文脈に沿った結果を提供します。コードベース全体にわたるファイル、依存関係、開発パターン間の関係を理解することにより、エージェントは人間のデベロッパーが発見するのに何時間もかかる洞察を提供するように設計されています。**これは、ナレッジグラフに計画されている強力な機能のロックを解除する最初のステップにすぎません。**\n\n### エンタープライズガバナンス\n\nAIの透明性と組織のコントロールは、チームがAI搭載開発ツールを完全に採用することを妨げる可能性のある重要な課題であり、[85%の経営幹部が、エージェント型AIが前例のないセキュリティ課題を生み出すことに同意しています](https://about.gitlab.com/software-innovation-report/)。\n\n18.3のこれらの新機能は、データガバナンス、コンプライアンス要件、AI意思決定プロセスへの可視性の必要性に関する懸念に対処するのに役立つため、組織は既存のセキュリティとポリシーフレームワーク内でAIを統合できます。\n\n* **インテリジェンスを通じた透明性のためのエージェントインサイト：** 組み込みのエージェント追跡により、エージェントの意思決定プロセスへの可視性が提供されます。ユーザーは、透明なアクティビティ追跡を通じてワークフローを最適化し、ベストプラクティスに従うことができます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783244?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=\"Agent Insights\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **Self-Hosted向けGitLab Duoコードレビュー：** これにより、厳格なデータガバナンス要件を持つ組織にGitLab Duoのインテリジェンスがもたらされ、チームが機密性の高いコードを管理された環境に保持できるようになります。\n* **柔軟なAIデプロイメントのためのハイブリッドモデル構成：** GitLab Duo Self-Hostedをご利用のお客様は、ローカルAIゲートウェイを介したセルフホステッドAIモデルとGitLabのAIゲートウェイを介したGitLabのクラウドモデルを組み合わせたハイブリッドモデル構成を使用できるようになり、さまざまな機能へのアクセスが可能になりました。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783569?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=\"Self Hosted Models Code Review\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **OAuthサポートによるセキュリティの強化：** MCPサーバーには、完全なOAuth 2.0認証サポートが含まれるようになり、保護されたリソースと機密性の高い開発環境への安全な接続が可能になりました。この実装は、MCPのドラフトOAuth仕様に従い、認証フロー、トークン管理、動的クライアント登録を処理します。\n\n### Secure by Designプラットフォーム：スケールするガバナンス\n\n真のプラットフォームセキュリティには、開発ライフサイクルのあらゆるレイヤーにわたるガバナンス原則の一貫した適用が必要です。AI採用を安全にするのと同じセキュリティの基本（最小権限アクセス、一元化されたポリシー管理、プロアクティブな監視、きめ細かい権限）は、凝集性のある多層防御アプローチを作成するために、SDLC全体に組み込まれる必要があります。\n\nGitLab 18.3は、これらの新しいアップデートでソフトウェアサプライチェーン全体を保護するのに役立つ基盤的なコントロールを強化します：\n\n* **カスタム管理者ロール：** ブランケット管理アクセスを正確な最小権限コントロールに置き換える、きめ細かく目的に合わせた管理権限を提供します。セキュリティリスクを生み出すブランケット管理権限を付与する代わりに、組織は特定の機能に合わせたカスタマイズされたロールを作成できるようになりました。ランナーと監視を管理するプラットフォームチーム、ユーザー管理を処理するサポートチーム、ダッシュボードと使用統計にアクセスするリーダーシップなど。UIとAPIを介した完全なロールライフサイクル管理、監査ログ、自動生成されたドキュメントにより、この機能は運用効率を維持し、全体的なインスタンスセキュリティを向上させながら、真の最小権限管理を可能にします。\n* **インスタンスレベルのコンプライアンスフレームワークとセキュリティポリシー管理：** 組織は、標準化されたフレームワークとセキュリティポリシーをトップレベルグループに直接適用する権限を持つ専用のコンプライアンスグループを指定でき、すべてのサブグループとプロジェクトに自動的にカスケード適用されます。この一元化されたアプローチは、追加のローカルポリシーに対するグループの自律性を維持しながら、断片化されたポリシー管理のコンプライアンス採用ブロッカーを排除します。\n* **強化された違反レポート：** チームは、MR承認ルールに対して不正な変更が行われたとき、フレームワークポリシーに適切な承認がないとき、または時間ベースのコンプライアンスコントロールが違反されたときに、即座に通知を受け取るようになりました。違反を特定のコンプライアンスフレームワークコントロールに直接リンクすることで、チームはどの要件が違反されたかを正確に伝える実用的な洞察を得て、コンプライアンスを反応的なチェックボックスの演習から、開発とセキュリティワークフローのプロアクティブで統合された部分に変えます。\n* **CI/CDジョブトークンのきめ細かい権限：** 広範なトークンアクセスを、CI/CDジョブが実際に必要とする特定のAPIエンドポイントへのアクセスのみを付与する、きめ細かく明示的な権限に置き換えます。ジョブにプロジェクトリソースへのブランケットアクセスを許可する代わりに、チームはデプロイメント、パッケージ、リリース、環境、その他の重要なリソースに対する正確な権限を定義でき、攻撃対象領域と権限昇格の可能性を減らすことができます。\n* **AWS Secrets Manager統合：** AWS Secrets Managerを使用しているチームは、GitLab CI/CDジョブでシークレットを直接取得できるようになり、ビルドとデプロイプロセスが簡素化されます。シークレットは、OpenID Connectプロトコルベースの認証を使用してGitLab Runnerによってアクセスされ、ジョブログでの露出を防ぐためにマスクされ、使用後に破棄されます。このアプローチにより、変数にシークレットを保存する必要がなくなり、既存のGitLabおよびAWSベースのワークフローにクリーンに統合されます。Deutsche BahnおよびAWS Secrets Managerチームとの緊密な協力により開発されたこの統合は、実世界の課題を解決するためにユーザーと一緒にソリューションを構築するという当社のコミットメントを反映しています。\n\n### アーティファクト管理：ソフトウェアサプライチェーンの保護\n\nアーティファクトが適切に管理されていない場合、小さな変更が大きな結果をもたらす可能性があります。可変パッケージ、上書きされたコンテナイメージ、ツール間で一貫性のないルールは、本番障害を引き起こし、脆弱性を招き、コンプライアンスギャップを作成する可能性があります。エンタープライズDevSecOpsにとって、安全で一元化されたアーティファクト管理は、ソフトウェアサプライチェーンを維持するために不可欠です。\n\n#### 18.3のエンタープライズグレードアーティファクト保護\n\n包括的なパッケージ保護機能を基盤として、GitLab 18.3は重要な新機能を追加します：\n\n* **Conanリビジョンサポート：** 18.3の新機能である[Conanリビジョン](https://docs.gitlab.com/user/packages/conan_2_repository/#conan-revisions)は、C++デベロッパーにパッケージの不変性を提供します。パッケージのバージョンを変更せずに変更を加えた場合、Conanはこれらの変更を追跡するための一意の識別子を計算し、チームがバージョンの明確性を維持しながら不変のパッケージを維持できるようにします。\n* **強化されたコンテナレジストリセキュリティ：** 18.2での[不変コンテナタグ](https://docs.gitlab.com/user/packages/container_registry/immutable_container_tags/)のローンチ成功に続き、エンタープライズでの採用が進んでいます。不変ルールに一致するタグが作成されると、権限レベルに関係なく、誰もそのコンテナイメージを変更できなくなり、本番依存関係への意図しない変更を防ぎます。\n\nこれらの機能強化は、npm、PyPI、Maven、NuGet、Helmチャート、および汎用パッケージに対する既存の保護機能を補完し、プラットフォームチームがソフトウェアサプライチェーン全体で一貫したガバナンスを実装できるようにします。これは、安全な内部デベロッパープラットフォームを構築する組織にとって不可欠です。\n\nスタンドアロンのアーティファクトソリューションとは異なり、GitLabの統合アプローチは、コードからデプロイメントまでのエンドツーエンドのトレーサビリティを提供しながら、複数のツールを使い分ける際の頭の切り替えを排除し、プラットフォームチームがソフトウェアデリバリーパイプライン全体で一貫したガバナンスを実装できるようにします。\n\n### 埋め込みビュー：リアルタイムの可視性とレポート\n\nGitLabプロジェクトの複雑さが増すにつれて、チームは作業ステータスへの可視性を維持するために、イシュー、マージリクエスト、エピック、マイルストーン間を移動することになります。課題は、頭の切り替えやフローを中断することなく、チームがプロジェクトの進行状況にリアルタイムでアクセスできるようにしながら、この情報を効率的に統合することにあります。\n**18.3でリアルタイム作業ステータスの可視性をローンチ**\n強力な[GitLabクエリ言語（GLQL）を搭載したGitLab 18.3の埋め込みビュー](https://docs.gitlab.com/user/glql/#embedded-views)は、ライブプロジェクトデータをワークフローに直接もたらすことで、頭の切り替えを排除します：\n\n* **動的ビュー：** ページを読み込むたびに現在のプロジェクト状態で自動的に更新される、Markdownコードブロックのwikiページ、エピック、イシュー、マージリクエスト全体にライブGLQLクエリを挿入します。\n* **文脈に応じたパーソナライゼーション：** ビューは、手動設定なしで、表示している人に関連する情報を表示するために、`currentUser()`や`today()`などの関数を使用して自動的に適応します。\n* **強力なフィルタリング：** 担当者、作成者、ラベル、マイルストーン、ヘルスステータス、作成日など、25以上のフィールドでフィルタリングします。\n* **表示の柔軟性：** カスタマイズ可能なフィールド選択、アイテム制限、並べ替え順序を使用して、データをテーブル、リスト、または番号付きリストとして表示し、ビューを集中的で実行可能に保ちます。\n\n断片化されたプロジェクト管理アプローチとは異なり、埋め込みビューは、リアルタイムの可視性を提供しながらワークフローの継続性を維持するように設計されており、チームが複数のツールやインターフェース間で焦点を失ったり切り替えたりすることなく、情報に基づいた意思決定を行えるようにします。\n\n> [GitLab 18.3の最新機能](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/)について詳しく見る。\n\n## 今すぐ始める\n\nGitLab 18.3は、GitLab.comおよびセルフマネージド環境のGitLab PremiumおよびUltimateユーザーが今すぐ利用できます。\n\nGitLab Dedicatedのお客様は現在18.2にアップグレードされており、来月GitLab 18.3でリリースされた機能を使用できるようになります。\n\nソフトウェアエンジニアリングの未来を体験する準備はできましたか？[GitLab Duoのベータ版と実験的機能を有効](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)にして、完全な開発コンテキストを理解するAIエージェントとのコラボレーションを開始してください。\n\nGitLabは初めてですか？[無料トライアルを今すぐ開始](https://gitlab.com/-/trials/new)して、世界で最も包括的なDevSecOpsプラットフォームを通じてオーケストレーションされた、人間とAIのコラボレーションがソフトウェアエンジニアリングの未来である理由を発見してください。\n\n\u003Cp>\u003Csmall>\u003Cem>このブログ投稿には、1933年証券法第27A条および1934年証券取引所法第21E条の意味における「将来を見据えた声明」が含まれています。このブログ投稿に含まれる将来を見据えた声明に反映された期待は合理的であると信じていますが、実際の結果または成果が将来を見据えた声明によって表現または暗示された将来の結果または成果と実質的に異なる原因となる可能性のある既知および未知のリスク、不確実性、仮定、およびその他の要因の対象となります。\u003C/em>\u003C/p>\n\u003Cp>\u003Cem>実際の成果と結果が、このブログ投稿に含まれる、または検討される将来を見据えた声明に含まれるものと実質的に異なる原因となる可能性のあるリスク、不確実性、およびその他の要因に関する詳細情報は、証券取引委員会に提出および報告する「リスク要因」というキャプションの下およびその他の場所に含まれています。このブログ投稿の日付以降に将来を見据えた声明の改訂を更新またはリリースする義務、またはイベントや状況を報告する義務、または予期しないイベントの発生を反映する義務を負いません（法律で要求される場合を除く）。\u003C/em>\u003C/small>\u003C/p>",[833],"Bill Staples","2025-08-27","2025-08-21","GitLab 18.3: ソフトウェアエンジニアリングにおけるAIオーケストレーションの拡張",[765,838,795,796,776],"AI/ML","強化されたフロー、エンタープライズガバナンス、シームレスなツール統合により、人間とAIのコラボレーションを進化させる方法をご紹介します。",{"featured":91,"template":800,"slug":841},"gitlab-18-3-expanding-ai-orchestration-in-software-engineering",{"content":843,"config":852},{"heroImage":844,"body":845,"authors":846,"updatedDate":847,"date":848,"title":849,"tags":850,"description":851,"category":682},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752678395/impw8no5tbskr6k2afgu.jpg","**私たちはソフトウェア開発の未来を構築しています。**\n\nGitLabでは、[ソフトウェアエンジニアリングの未来を人間とAIのコラボレーション](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops/)として再構想しています。開発者が技術的で複雑な問題の解決とイノベーションの推進に集中する一方で、AIエージェントが進捗を遅らせる日常的で反復的なタスクを処理します。開発者がはるかに低いコストで新しいアイデアをコードで自由に探求でき、バグのバックログが過去のものとなり、構築するソフトウェアのユーザーがより使いやすく、信頼性が高く、安全な体験を楽しめる世界です。これは遠い夢ではありません。私たちは現在この現実を構築しており、それがGitLab Duo Agent Platformです。\n\n## GitLab Duo Agent Platformとは？\n\nGitLab Duo Agent Platformは、開発者とAIエージェント間の非同期コラボレーションを実現するように設計された次世代DevSecOpsオーケストレーションプラットフォームです。これにより、ソフトウェア開発ワークフローを、従来の1人ずつ順番に開発を進めるプロセスから、複数の人やAIエージェントが同時に協力しあえる開発スタイルへ変革できます。まるで無限のチームメンバーを自由に使えるようなものです。\n\n複雑なリファクタリングタスクをSoftware Developer Agentに委任しながら、同時にSecurity Analyst Agentに脆弱性をスキャンさせ、Deep Research Agentにリポジトリ履歴全体の進捗を分析させることを想像してください。これらはすべて並行して行われ、GitLab内でシームレスにオーケストレーションされます。\n\n本日、GitLab.comおよびSelf-ManagedのGitLab PremiumとUltimateのお客様向けに、[GitLab Duo Agent Platformの最初のパブリックベータ版](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)のローンチを発表します。これは、インテリジェントな自動化を通じて人間の創意工夫を増幅させながら、ソフトウェアの計画、構築、検証、デプロイの方法を改善する一連のアップデートの最初のものです。\n\nこの最初のベータ版は、GitLab VS Code拡張機能とJetBrains IDEプラグインを通じてIDE体験を解放することに焦点を当てています。来月には、Duo Agent Platform体験をGitLabアプリケーションに導入し、IDEサポートを拡張する予定です。現在から今年後半に予定されている一般提供までのロードマップに関する私たちのビジョンについて、もう少し詳しくお話しさせていただきます。最初のベータ版の詳細は以下をご覧ください。\n\n現在利用可能な機能と今後の予定については、このビデオをご覧いただくか、続きをお読みください。その後、Duo Agent Platformを開始する準備ができたら、[パブリックベータ版での開始方法をご覧ください](#get今すぐ始める)。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&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 Agent Platform Beta Launch_071625_MP_v2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## オーケストレーションプラットフォームとしてのGitLabのユニークなポジション\n\nGitLabは、エンジニアリングチームの記録システムとして開発ライフサイクルの中心に位置し、5,000万人以上の登録ユーザー（Fortune 500の半数を含む）のコンセプトから本番環境までの全行程をオーケストレーションしています。これには、公共機関を含むすべてのセグメントと業界にわたる10,000以上の有料顧客が含まれます。\n\nこれにより、GitLabは競合他社が持ち得ないものを手に入れています：ソフトウェアを提供するために必要なすべてに関する包括的な理解です。私たちは、プロジェクト計画、コード、テスト実行、セキュリティスキャン、コンプライアンスチェック、CI/CD設定を統合し、チームに力を与えるだけでなく、あなたがコントロールするAIエージェントとのコラボレーションをオーケストレーションします。\n\nインテリジェントで統一されたDevSecOpsプラットフォームとして、GitLabはソフトウェアエンジニアリング実践に関するすべてのコンテキストを1か所に保存します。私たちは、この統一されたデータをナレッジグラフを介してAIエージェントに公開します。構築されるすべてのエージェントは、このSDLC接続されたデータセットに自動的にアクセスでき、豊富なコンテキストを提供するため、エージェントは情報に基づいた推奨を行い、組織の標準に準拠したアクションを実行できます。\n\n**このアドバンテージの実例をご紹介します。** 数十、場合によっては数百のストーリーやイシューにわたって、関係するすべての開発者を含めてプロジェクトがどのように進行しているかを正確に把握しようとしたことはありますか？Deep Research AgentはGitLab Knowledge Graphとセマンティック検索機能を活用して、エピックとすべての関連イシューを横断し、関連するコードベースと周囲のコンテキストを探索します。リポジトリ、マージリクエスト、デプロイメント履歴全体の情報を迅速に相関させます。これにより、スタンドアロンツールでは実現できず、人間の開発者が発見するのに何時間もかかる重要な洞察が得られます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&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=\"Deep Research Demo_071625_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## AI機能からエージェントオーケストレーションへの戦略的進化\n\nGitLab Duoは、Duo ProとEnterpriseを通じて開発者に生成AIをもたらすアドオンとして始まりました。GitLab 18.0では、プラットフォームに組み込まれています。すべてのPremiumおよびUltimateユーザー向けに[Duo Agentic Chat](https://about.gitlab.com/ja-jp/blog/gitlab-duo-chat-gets-agentic-ai-makeover/)とCode Suggestionsを解放し、現在Duo Agent Platformへの即座のアクセスを提供しています。\n\nエンジニアリング投資を強化し、デリバリーを加速させており、毎月強力な新しいAI機能が登場しています。しかし、私たちは単なる別のコーディングアシスタントを構築しているわけではありません。GitLab Duoは、AIエージェントを作成、カスタマイズ、デプロイでき、他のシステムと簡単に相互運用できるエージェントオーケストレーションプラットフォームになりつつあり、生産性を劇的に向上させます。\n\n> **「GitLab Duo Agent Platformは、私たちのコードベースと組織を真に理解するAIで開発ワークフローを強化します。コード、テスト、CI/CD、およびソフトウェア開発ライフサイクル全体の記録システムにGitLab Duo AIエージェントが組み込まれることで、生産性、開発速度、効率性が向上します。エージェントは私たちのチームの真のコラボレーターとなり、意図を理解し、問題を分解し、アクションを実行する能力により、開発者は情熱を持つエキサイティングで革新的な作業に取り組むことができます。」** - Bal Kang氏、NatWest エンジニアリングプラットフォームリード\n\n### すぐに使えるエージェント\n\n私たちは、おなじみのチームの役割を反映したエージェントを導入しています。これらのエージェントは、GitLab全体で既存のアーティファクトを検索、読み取り、作成、変更できます。これらは個別に対話できるエージェントであり、独自のエージェントを作成するためにカスタマイズできるビルディングブロックとしても機能します。チームメンバーと同様に、エージェントにはソフトウェア開発、テスト、技術文書作成などの定義された専門分野があります。スペシャリストとして、適切なコンテキストとツールを活用して、デプロイされる場所に関係なく、同じタイプのタスクを一貫して達成します。\n\n現在構築中のエージェントの例をいくつか紹介します：\n\n* **Chat Agent（現在ベータ版）：** 自然言語のリクエストを受け取り、ユーザーに情報とコンテキストを提供します。イシューの読み取りやコードの差分の読み取りなど、一般的な開発タスクを実行できます。例として、ジョブのURLを提供することで、失敗したジョブのデバッグをChatに依頼できます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102616311?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=\"agentic-chat-in-web-ui-demo_Update V2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\u003Cp>\u003C/p>\n\n* **Software Developer Agent（現在ベータ版）：** 割り当てられたアイテムに取り組み、仮想開発環境でコード変更を作成し、レビュー用のマージリクエストを開きます。\n* **Product Planning Agent：** 製品バックログの優先順位付け、人間およびエージェントのチームメンバーへの作業アイテムの割り当て、指定されたタイムライン上でのプロジェクト更新の提供を行います。\n* **Software Test Engineer Agent：** バグの新しいコード貢献をテストし、報告された問題が解決されたかどうかを検証します。\n* **Code Reviewer Agent：** チーム標準に従ってコードレビューを実行し、品質とセキュリティの問題を特定し、準備ができたらコードをマージできます。\n* **Platform Engineer Agent：** GitLab Runnersを含むGitLabデプロイメントを監視し、CI/CDパイプラインの健全性を追跡し、人間のプラットフォームエンジニアリングチームにパフォーマンスの問題を報告します。\n* **Security Analyst Agent：** コードベースとデプロイされたアプリケーション内の脆弱性を発見し、セキュリティの弱点の解決に役立つコードと設定の変更を実装します。\n* **Deployment Engineer Agent：** 本番環境に更新をデプロイし、異常な動作を監視し、アプリケーションのパフォーマンスやセキュリティに影響を与える変更をロールバックします。\n* **Deep Research Agent：** 開発エコシステム全体にわたって包括的なマルチソース分析を実施します。\n\nこれらのエージェントを強力にするのは、GitLabの包括的なツールキットへのネイティブアクセスです。現在、イシューやエピックからマージリクエストやドキュメントまで、25以上のツールがあり、さらに増える予定です。限られたコンテキストで動作する外部AIツールとは異なり、エージェントは組織の監督の下で完全なプラットフォーム権限を持つ真のチームメンバーとして機能します。\n\n今後数か月で、これらのエージェントを組織のニーズに合わせて変更することもできるようになります。例えば、Software Test Engineer Agentが特定のフレームワークや方法論のベストプラクティスに従うように指定でき、その専門性を深め、さらに価値のあるチームメンバーに変えることができます。\n\n## Flowsが複雑なエージェントタスクをオーケストレーション\n\n個々のエージェントに加えて、エージェントFlowsを導入しています。これらは、自律的に実行できる特定のタスクに対して、事前に構築された指示、ステップ、アクションを含む複数のエージェントを含むことができる、より複雑なワークフローと考えてください。\n\n個人に共通する基本的なタスクのFlowsを作成できますが、通常は調整と労力に何時間もかかる複雑で専門的なタスクに適用すると真に優れています。Flowsは複雑なタスクをより速く完了する支援をし、多くの場合、人間の介入なしに非同期で実行できます。\n\nFlowsには実行のための特定のトリガーがあります。各Flowには一連のステップが含まれ、各ステップには専門のエージェントに何をすべきかを伝える詳細な指示があります。この詳細なアプローチにより、Flow内のエージェントに正確な指示を与えることができます。より詳細に指示を定義し、構造化された決定ポイントを確立することで、FlowsはAI応答の固有の変動性を解決しながら、同じ要件を繰り返し指定する必要をなくし、ユーザー設定なしでより一貫性があり予測可能な結果を解放できます。\n\n私たちが構築している、すぐに使えるFlowsの例をいくつか紹介します：\n\n**Software Development Flow（現在ベータ版）：** 複数のエージェントをオーケストレーションして、コード変更をエンドツーエンドで計画、実装、テストし、チームがコンセプトから本番環境まで機能を提供する方法を変革する支援をします。\n\n**Issue-to-MR Flow：** エージェントを調整して要件を分析し、包括的な実装計画を準備し、コードを生成することで、イシューを実行可能なマージリクエストに自動的に変換します。\n\n**Convert CI File Flow：** 既存のCI/CD設定を分析し、完全なパイプライン互換性を持つGitLab CI形式にインテリジェントに変換するエージェントを使用して、移行ワークフローを合理化します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&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=\"jenkins-to-gitlab-cicd-for-blog\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n**Search and Replace Flow：** プロジェクト構造を体系的に分析し、最適化の機会を特定し、正確な置換を実行することで、コードベース全体でコードパターンを発見して変換します。\n\n**Incident Response & Root Cause Analysis Flow：** システムデータを相関させ、根本原因分析のための専門エージェントを調整し、解決プロセス全体を通じて関係者に情報を提供しながら、承認された修復手順を実行することで、インシデント対応をオーケストレーションします。\n\nこれは、GitLab Duo Agent Platformが他のAIソリューションと比較して真にユニークなアプローチを取っている点になります。事前に構築されたエージェントを提供するだけではありません。個人および組織の独自のニーズに完全に一致するエージェントFlowsを作成、カスタマイズ、共有する力も提供します。そして、Flowsを使用すると、一般的で複雑なタスクに対してエージェントに特定の実行計画を与えることができます。\n\nこのアプローチは、競合他社が行うような目的別のエージェントを構築するよりも強力であると考えています。なぜなら、すべての組織には異なるワークフロー、コーディング標準、セキュリティ要件、ビジネスロジックがあるからです。汎用AIツールは特定のコンテキストを理解できませんが、GitLab Duo Agent Platformはチームの作業方法に正確に合わせて調整できるようになります。\n\n## なぜGitLab Duo Agent PlatformでエージェントとエージェントFlowsを構築するのか？\n\n**高速構築：**高速で宣言的な拡張性モデルとUIアシスタンスを使用して、Duo Agent Platformでエージェントと複雑なエージェントFlowsを迅速かつ簡単に構築できます。\n\n**組み込みコンピュート：**Duo Agent Platformを使用すると、エージェント用の独自のインフラストラクチャを立ち上げる手間をかける必要がなくなります：コンピュート、ネットワーク、ストレージはすべて組み込まれています。\n\n**SDLCイベント：**エージェントは、パイプラインのエラー、デプロイメントの失敗、イシューの作成など、一般的なイベントで自動的に呼び出すことができます。\n\n**即座のアクセス：**GitLabまたはIDEプラグインのどこからでもエージェントと対話できます：イシューを割り当て、コメントで@メンションし、Duo Chatが利用可能なあらゆる場所でチャットできます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102029239?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=\"assigning an agent an issue\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script> \u003Cp>\u003C/p>\n\n**組み込みモデルとカスタムモデルをサポート：** エージェントは、サポートするすべてのモデルに自動的にアクセスでき、ユーザーは特定のタスクに特定のモデルを選択できます。Duo Agent Platformを独自のセルフホストモデルに接続したい場合は、それも可能になります！\n\n**Model Context Protocol（MCP）エンドポイント：**すべてのエージェントとFlowはネイティブMCPエンドポイントを介してアクセスまたはトリガーでき、Claude Code、Cursor、Copilot、Windsurfなどの人気のあるツールを含む、どこからでもエージェントとFlowsに接続してコラボレーションできます。\n\n**可観測性とセキュリティ：**組み込みの可観測性と使用状況ダッシュボードを提供し、エージェントが誰が、どこで、何を、いつあなたに代わってアクションを実行したかを正確に確認できます。\n\n## コミュニティ主導の未来\n\nコミュニティの貢献は長い間GitLabのイノベーションとソフトウェア開発を促進してきました。AI Catalogの導入により、コミュニティとパートナーシップを組むことに興奮しています。AI Catalogにより、組織内およびGitLabエコシステム全体でエージェントとFlowsを作成して共有できるようになります（今後のベータ版で）。\n\n最も価値のあるAIアプリケーションは、GitLab Duo Agent Platformを毎日適用して多数の実世界のユースケースを解決することで、コミュニティの皆様から生まれる可能性が高いと考えています。エージェントとFlowsのシームレスな共有を可能にすることで、各コントリビュートがプラットフォームの集合的なインテリジェンスと価値を高めるネットワーク効果を生み出しています。時間の経過とともに、Agent Platformからの最も価値のあるユースケースは、繁栄するGitLabコミュニティから生まれると信じています。\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685501/awdwx08udwrxgvcpmssb.png \"AI Catalog\")\n\n## 現在GitLab Duo Agent Platformパブリックベータ版で利用可能\n\nGitLab Duo Agent Platformパブリックベータ版は、PremiumおよびUltimateのお客様に以下の機能を提供して現在利用可能です：\n\n**Software Development Flow：** 最初のFlowは、包括的なコンテキストの収集、人間の開発者との曖昧さの明確化、コードベースとリポジトリに正確な変更を加えるための戦略的計画の実行においてエージェントをオーケストレーションします。プロジェクト全体（構造、コードベース、履歴を含む）と、GitLabのイシューやマージリクエストなどの追加コンテキストを活用して、開発者の生産性を増幅します。\n\n**新しいエージェントツールが利用可能：** エージェントは作業を行うために複数のツールにアクセスできるようになりました：\n\n* ファイルシステム（読み取り、作成、編集、ファイル検索、リスト、Grep）\n* コマンドライン実行*\n* イシュー（リスト、取得、コメント取得、編集*、作成*、コメント追加/更新*）\n* エピック（取得、コメント取得）\n* MR（取得、コメント取得、差分取得、作成、更新）\n* パイプライン（ジョブログ、パイプラインエラー）\n* プロジェクト（取得、ファイル取得）\n* コミット（取得、リスト、コメント取得、差分取得）\n* 検索（イシュー検索）\n* セキュア（脆弱性リスト）\n* ドキュメント検索\n  *=ユーザー承認が必要\n\n**IDEでのGitLab Duo Agentic Chat：** Duo Agentic Chatは、チャット体験を受動的なQ&Aツールから、IDE内で直接アクティブな開発パートナーに変換します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1103237126?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=\"agentic-ai-launch-video_NEW\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\u003Cp>\u003C/p>\n\n* **反復的なフィードバックとチャット履歴：** Duo Agentic Chatは、チャット履歴と反復的なフィードバックをサポートするようになり、エージェントを状態を持つ会話型パートナーに変換します。これにより信頼が育まれ、開発者がより複雑なタスクを委任し、修正指導を提供できるようになります。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&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=\"agentic-chat-history\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **スラッシュコマンドによる合理化された委任：** /explain、/tests、/includeなどの拡張されたより強力なスラッシュコマンドは、迅速で正確な意図のための「委任言語」を作成します。/includeコマンドにより、特定のファイル、開いているイシュー、マージリクエスト、または依存関係からのコンテキストをエージェントの作業メモリに直接注入でき、エージェントをより強力にし、高品質な応答のための最適なコンテキストを提供する方法をユーザーに教えます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&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=\"include-agentic-chat-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **カスタムルールによるパーソナライゼーション：** 新しいカスタムルールにより、開発者は自然言語（例：開発スタイルガイド）を使用して、エージェントの動作を個人およびチームの好みに合わせて調整できます。この基本的なメカニズムは、エージェントのペルソナをパーソナライズされたアシスタントに形成し、ユーザー定義の好みと組織ポリシーに基づいて専門的なエージェントへと進化します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&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=\"custom-rules-with-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **JetBrains IDEでのGitLab Duo Agentic Chatのサポート：** 開発者が作業する場所で会うために、IntelliJ、PyCharm、GoLand、WebstormなどのJetBrainsファミリーのIDEにDuo Agentic Chatサポートを拡張しました。これは既存のVS Codeサポートに追加されます。既存のユーザーは自動的にエージェント機能を取得し、新しいユーザーはJetBrains Marketplaceからプラグインをインストールできます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&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=\"jetbrains-support-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **MCPクライアントサポート：** Duo Agentic Chatは、MCPクライアントとして機能し、リモートおよびローカルで実行されているMCPサーバーに接続できるようになりました。\n\nこの機能により、エージェントはGitLab以外のJira、ServiceNow、ZenDeskなどのシステムに接続してコンテキストを収集したり、アクションを実行したりできます。MCPを介して自身を公開するサービスは、エージェントのスキルセットの一部になることができます。公式のGitLab MCPサーバーは近日公開予定です！\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&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=\"McpDemo\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **GitLab Web UIでのGitLab Duo Agentic Chat。** Duo Agentic ChatはGitLab Web UI内でも直接利用できるようになりました。この重要なステップにより、エージェントはコーディングアシスタントから真のDevSecOpsエージェントへと進化します。イシューやマージリクエストのディスカッションなどの豊富な非コードコンテキストにアクセスできるようになり、作業の背後にある「なぜ」を理解できるようになります。コンテキストを理解するだけでなく、エージェントはイシューのステータスの自動更新やマージリクエストの説明の編集など、WebUIから直接変更を加えることができます。\n\n## GitLab Duo Agent Platformに近日登場\n\n今後数週間にわたって、Duo Agent Platformに新しい機能をリリースし、より多くのすぐに使えるエージェントとFlowsを含めます。これらは、現在愛用されているGitLab体験にプラットフォームをもたらし、さらに大きなカスタマイズと拡張性を可能にし、お客様の生産性を増幅します：\n\n![GitLab Duo Agent Platform パブリックベータロードマップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685275/hjbe9iiu2ydp9slibsc2.png \"GitLab Duo Agent Platform パブリックベータロードマップ\")\n\n* **統合されたGitLab体験：** 18.2で利用可能なIDE拡張機能を基に、GitLabプラットフォーム内でエージェントとFlowsを拡張しています。このより深い統合により、エージェントと同期的および非同期的にコラボレーションする方法が拡張されます。エージェントに直接イシューを割り当て、GitLab Duo Chat内で@メンションし、選択した開発ツールからのMCP接続を維持しながら、アプリケーションのどこからでもシームレスに呼び出すことができます。このネイティブ統合により、エージェントはGitLab全体でアクセス可能な真の開発チームメンバーに変わります。\n* **エージェントの可観測性：** エージェントがより自律的になるにつれて、Flowsを進行する際のアクティビティに対する包括的な可視性を構築しており、意思決定プロセスを監視し、実行ステップを追跡し、開発の課題をどのように解釈して行動しているかを理解できるようにします。エージェントの動作に対するこの透明性は信頼と確信を構築し、ワークフローを最適化し、ボトルネックを特定し、エージェントが意図したとおりに正確に実行されていることを確認するのに役立ちます。\n* **AI Catalog：** 素晴らしいソリューションはコミュニティのイノベーションから生まれることを認識し、まもなくAI Catalogのパブリックベータ版を導入します - GitLabから、そして時間の経過とともにより広いコミュニティから調達された専門的なエージェントとFlowsでDuo Agent Platformを拡張できるマーケットプレイスです。これらのソリューションをGitLabで迅速にデプロイし、プロジェクトとコードベース全体のコンテキストを活用できます。\n* **Knowledge Graph：** ソースコードとその周囲のコンテキストの記録システムとしてのGitLabのユニークなアドバンテージを活用して、コードベース全体のファイルと依存関係をマッピングするだけでなく、そのマップをユーザーがナビゲート可能にし、AIクエリ時間を加速し、精度の向上に役立つ包括的なKnowledge Graphを構築しています。この基盤により、GitLab Duoエージェントは、コードの依存関係からデプロイメントパターンまで、開発環境全体の関係を迅速に理解でき、複雑な質問に対するより速く、より正確な応答を解放します。\n\n![GitLab Duo Agent Platform Knowledge Graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685367/n0tvfgorchuhrronic3j.png \"GitLab Duo Agent Platform Knowledge Graph\")\n\n* **エージェントとFlowsの作成と編集：** すべての組織には独自のワークフローと要件があることを理解し、AI Catalogが成熟するにつれて導入される強力なエージェントとFlow作成および編集機能を開発しています。組織の作業方法に正確に合わせてエージェントとFlowsを作成および変更でき、Duo Agent Platform全体で高品質な結果と生産性の向上を可能にする深いカスタマイズを提供します。\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752684938/fruwqcqvvrx8gmkz5u0v.png \"AI Catalog\")\n\n* **公式GitLab MCPサーバー：** 開発者が複数のツールと環境で作業することを認識し、MCPを介してすべてのエージェントとFlowsにアクセスできる公式GitLab MCPサーバーを構築しています。Claude Code、Cursor、Copilot、WindsurfなどのポピュラーなツールをMCPがサポートされている場所から、エージェントとFlowsに接続してコラボレーションでき、好みの開発環境に関係なくシームレスなAIコラボレーションを解放します。\n* **GitLab Duo Agent Platform CLI：** 今後のCLIにより、コマンドラインでエージェントを呼び出し、Flowsをトリガーできるようになり、コードリポジトリとマージリクエストからCI/CDパイプラインとイシュー追跡まで、ソフトウェア開発ライフサイクル全体にわたるGitLabの豊富なコンテキストを活用できます。\n\n## 今すぐ始める\n\n* GitLab.comおよびGitLab 18.2を使用するセルフマネージド環境の**GitLab PremiumおよびUltimateのお客様**は、Duo Agent Platformをすぐに使用できます（GitLab Duoの[ベータ版および実験的機能を有効にする必要があります](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)）。\n* ユーザーは[VS Code拡張機能](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow)または[JetBrains IDEsプラグイン](https://plugins.jetbrains.com/plugin/22857-gitlab)をダウンロードし、Duo Chat [スラッシュコマンド](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#gitlab-duo-chat-slash-commands)を含む[GitLab Duo Agentic Chatの使用ガイド](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat)に従ってください。\n\n**GitLabは初めてですか？** 誰でも今後の[GitLab Duo Agent Platformを実際に見るための技術デモ](https://page.gitlab.com/webcasts-jul16-gitlab-duo-agentic-ai-emea-amer.html)に参加できます。GitLab Duo Agent Platformを自分で実際に体験するには、今すぐ[無料トライアル](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fsales%2F)にサインアップしてください。\n\n\u003Csmall>*このブログ記事には、改正1933年証券法第27A条および1934年証券取引所法第21E条の意味における「将来の見通しに関する記述」が含まれています。このブログ記事に含まれる将来の見通しに関する記述に反映された期待は合理的であると考えていますが、それらは既知および未知のリスク、不確実性、仮定、およびその他の要因の影響を受けるため、実際の結果または成果は、将来の見通しに関する記述によって表現または暗示されたものと大きく異なる可能性があります。*\n\n*将来の見通しに関する記述に含まれるまたは検討される実際の成果や結果が大きく異なる原因となる可能性のあるリスク、不確実性、およびその他の要因に関する詳細情報は、証券取引委員会に提出する書類および報告書の「リスク要因」という見出しおよびその他の箇所に記載されています。私たちは、このブログ記事の日付以降に発生するイベントや状況を報告したり、予期しないイベントの発生を反映したりするために、将来の見通しに関する記述の改訂を更新または公開する義務を法律で要求される場合を除いて負いません。*\u003C/small>",[833],"2025-07-22","2025-07-17","GitLab Duo Agent Platform ベータ版：次世代AIオーケストレーション",[838,765,796,742],"開発者とAIエージェント間の非同期コラボレーションを実現するDevSecOpsオーケストレーションプラットフォームをご紹介します。",{"featured":91,"template":800,"slug":853},"gitlab-duo-agent-platform-public-beta",{"content":855,"config":866},{"heroImage":856,"category":682,"body":857,"date":858,"authors":859,"description":861,"title":862,"tags":863},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1751953181/rtejicnkhd9oslaxsoo5.jpg","## 目次\n\n1. はじめに: AI活用の新時代を切り拓く効率的なソフトウェア開発\n2. Claude Codeとは何か？\n3. GitLabのCLIであるGLabの紹介\n4. Claude CodeとGLabを組み合わせた開発の流れ\n5. AIを使った開発の今後の広がりについて\n6. まとめ\n7. よくある質問\n\n\n\n## はじめに: AI活用の新時代を切り拓く効率的なソフトウェア開発\n\nこの記事を読むと、エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法がわかるようになります。\n\n## Claude Codeとは何か？\n\nClaude Codeとはエージェント型AIで、ターミナル上でAIにコマンドを実行させることで既存ツールを使いながら効率的に開発できます。\n\n## GitLabのCLIであるGLabの紹介\n\nGLabはオープンソースのGitLab CLIツールです。GLabをターミナルに統合し、作業中のコマンドラインツールや、IDEの中に表示できます。GitLabのWebUIにアクセスするためにブラウザのウィンドウやタブに切り替える必要がなくなり、マージリクエストの作成やパイプラインの状況の確認など、様々なことを直感的にコマンドラインで実行可能になります。\n\n## Claude CodeとGLabを組み合わせた開発の流れ\n\n### **Claude Codeとglabのインストール**\n\nここでは個別のインストール方法や導入の仕方については割愛しますが、下記の公式サイトが参考になると思いますのでご確認ください。\n\nClaude Code: \u003Chttps://docs.anthropic.com/ja/docs/claude-code/overview>\n\nGLab: \u003Chttps://gitlab.com/gitlab-org/cli/-/blob/main/README.md>\n\n### [](https://gitlab.com/gitlab-org/cli/-/blob/main/README.md)**GitLabの認証情報を設定**\n\nまずはGLabのセットアップをしていきましょう。GLabでGitLabサーバーにログインします。\n\n`$ glab auth login`\n\n上記を実行すると、ログインするサーバーの先を問われるので、選びます。続いて、Tokenによるログインか、Webブラウザを使って認証するか聞かれるため、これも好きな方を選んでください。下記は、Webを選んだ場合の画面です。\n\n![Webログイン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/tl81t9qzwhqjnrro3lrb.png)\n\n次に、Gitクライアントが通信するデフォルトのプロトコルを聞かれるので、これも好きなものを選んでください。環境によってはSSHプロトコルの通信が制限されている場合もあるかと思うので、そのような場合はHTTPSを選ぶことをおすすめします。\n\n最後に、Gitの認証にもCredentialsの認証情報使うかを問われるため、これも選んでいただければと思います。\nYesの場合は、GitのHTTPS認証にもglabのPersonal Access Token（PAT）を使うよう.gitconfigに設定され、Noを選んだ場合は、glabでIssueやMRの操作をする一方で、Gitのpush/pullは従来通りのSSHや別途設定した認証方式で行う必要があります。\n\n初期の設定が終わった画面を下記に示します。\n\n![初期設定完了画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198582/xtpheeez1gcwr8sfjmdv.png)\n\n### **開発対象プロジェクトのclone**\n\n次に、Claude Codeに指示を与えて、glabコマンドを使って、リモートリポジトリからcloneします。下記のコマンドでClaude Codeを起動します。\n\n`$ claude`\n\n既にGLabで認証は終わっているため、作業するプロジェクトのリポジトリをcloneするように指示を与えます。\n\n`> GitLab上で自分が参加しているプロジェクトを表示してください`\n\n上記のようにプロンプトするとClaude Codeが\n\n`$ glab repo list`\n\nなどを実行してくれると思います。次に、作業したいリポジトリを上記から選び、Cloneします。プロジェクト名は各自の環境に合わせて指定してください。\n\n`> プロジェクト naosasaki-demo/study/spring-demo をcloneしてください`\n\nClaude Codeの処理が終わると、一度Claude Codeを終了し、ターミナルでディレクトリを確認すると、cloneされたディレクトリが作られていることがわかると思います。\n\n**新しいIssueの作成**\n\n次に、このプロジェクトに新しくイシューを作りたいと思います。通常であればWebブラウザでGitLabにアクセスしイシューを登録しますが、GLabとClaude Codeを使って、IDEやターミナル画面から作ってみたいと思います。\n\n`> このプロジェクトに新しいイシューを作ってください。内容は、今の東京の温度と天気を返すWebAPIのエンドポイントを作成します。`\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/iizlucpfxgsa0nrdsvqn.png)\n\n\n上記のようにglabを使ってイシューを作成するコマンドが提案されます。またイシューのなかの記載もある程度書いてくれていることがわかります。\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198579/ye2wtupp6nf8ljzja2yh.png)\n\nブラウザでアクセスしても、正しく作られていることがわかります。\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198582/vbo22zzdzzanvnrbsszq.png)\n\n### **マージリクエストとブランチの作成と作業開始**\n\n次に、実際のこのIssueの内容を実装していきたいと思います。ここからはIDEのVisual Studio Codeも利用していきたいと思います。Visual Studio Codeを起動し、内蔵されたターミナルを開き、そこでClaude Codeを起動します。\n\n早速、先ほど作ったイシューからマージリクエストを作って、その中で作業をしていきたいと思います。\n\n`> このリポジトリのプロジェクトのissue 53を実装したいので、glabでMRを作って、そのブランチをチェックアウトして`\n\n![マージリクエストとブランチの作成と作業開始](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/or6l5si3k4dbprcnnfgq.png)\n\n**コードの編集と検証**\n\n`> イシューの記載に基づいて実装してください。また、リポジトリ内部のドキュメントも追加に伴って更新してください。`\n\n![コードの編集と検証](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/dlgq0j60n2jfk24vxaj3.png)\n\nOpenWeatherMap APIを使うことを提案してくれています。そのほかにも、いくつかのクラスを作成することを提案されるので、中身を確認しつつ、それを受け入れ、git pushなども依頼します。\n\n![CC_8_git push](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198584/esdeisz4mzyyjlerlahl.png)\n\n### **レビューとCI/CDの確認**\n\n実際にマージリクエストを確認すると、ローカルで作成した変更がプッシュされ、GitLab側のCI/CDでの単体テストや、セキュリティスキャンなども正常に実行され、問題なく終了していることがわかりました。\n\n![レビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/e7hyheb5gkpvb7iixrro.png)\n\nしかし、テストが通っていても、それが適切な方法で実装されているか、非機能的な観点で問題がないかは別途確認する必要があります。ここで[GitLab Duo in merge requests](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/)という機能を利用して、GitLabのAI機能であるGitLab Duoにレビューを依頼してみたいと思います。\n\nマージリクエストのコメントでレビューをリクエストし、レビュアーとしてDuoを指定します。この時、レビューの観点なども同時に与えることができます。下記のようにコメントでレビューをDuoに依頼します。\n\n`/request_review @GitLabDuo`\n\n`マージリクエストのコードを下記の観点でレビューしてください：`\n\n`拡張性：将来的な機能追加や変更に対応しやすい設計・実装になっているか  \n可読性：他の開発者が理解しやすいコードになっているか  \n安全性：バグやセキュリティリスクを引き起こす可能性がないか  \nパフォーマンス：必要以上にリソースを消費していないか`\n\n![Duoレビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198581/tnkt52hpapm8cyi4qplw.png)\n\n上記をコメントすることで、Duoにレビューを依頼できます。\n\n実際にレビュー指摘がありました。\n\n![Duoレビュー指摘](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/vehscyu2beo4pz9ns3y2.png)\n\nDuoの指摘のとおり、Claude Codeが生成した元のコードでは、translateWeatherToJapanese メソッドが呼ばれるたびに HashMap が新しく作成されています。これはパフォーマンスの低下や不要なオブジェクト生成につながります。Duoは「このマップは不変であり、再利用可能なので static final にすべき」と提案しています。これの指摘は確かにその通りなので、マージリクエスト上でこの指摘と、変更の提案を受け入れます。\n\nこの変更の受け入れ自体も、ソースコードの変更なので、受け入れたらCI/CDパイプラインが動き出して、再度自動的にセキュリティスキャンや単体テスト実施されます。再度CI/CDパイプラインが動き、問題がなかったためmainブランチにマージしました。これでこの機能の開発は完了です。\n\n## AIを使った開発の今後の広がりについて\n\n### **AIは「補助ツール」から「実行の主体」へ**\n\n従来のチャットベースのインタラクティブな開発支援、すなわち一問一答のやり取りを繰り返しながら人間が主導で手を動かしていた開発スタイルから、いま大きな転換が始まっています。\n\nGLabのようなCLIツールやWebAPIと、エージェンティックAIを組み合わせることで、「命令→実行→ステータス確認→再試行」といった一連の開発オペレーションを、AIが自律的かつ反復的に担う、まさに実行主体としてのAIへの進化が進んでいます。\n\nこれは単なる補助からの脱却であり、ソフトウェア開発における人と機械の役割分担そのものを再定義しつつあります。人間は「何を実現したいか」を定義し、AIは「どう実現するか」を粘り強く試行錯誤していく、そんな協働の形が、現実の開発現場に静かに浸透し始めています。\n\n**レビューとガバナンスの重要性**\n\nAIによってコードが自動生成されるようになった今、開発効率が飛躍的に向上する一方で、「そのコードは本当に安全か？」「人間はAIの出力を正しくレビューできるのか？」といった新たな課題が生まれています。\n\n人間の作業と同様に、AIによって生成されたコードは、動作するからといって、品質が担保されているとは限りません。\n\nこうした背景から、組織的にAIを活用していくには、**コードの品質・セキュリティ・コンプライアンスを保証する仕組みを開発プロセスに組み込む**ことが不可欠です。\n\n今回は、コードの生成にClaude Codeを利用しましたが、そのコードに含まれる性能的な懸念をGitLab Duoによるレビューで摘出することができました。\n\nその他にも、GitLabでは「パイプライン実行ポリシー」を用いることで、プロジェクト単位ではなくグループやサブグループに対して、**SASTや依存関係スキャン、シークレット検出などのセキュリティジョブを強制適用**することが可能です。\n\nこのように、**AIによる開発支援とセキュリティ・品質管理の自動化を同時に実現できる**のは、DevSecOpsを包括的に支援するプラットフォームであるGitLabの強みといえます。\n\n## まとめ\n\nこの記事では、Claude CodeのようなAIエージェントと、GitLab公式CLIツールGLabを組み合わせることで、自然言語によるコード生成からGitLab上でのイシュー管理やマージリクエスト作成までをAIエージェントにやってもらうことで、開発効率を向上させる例を紹介しました。一方で、AIエージェントが生成するコードの品質を担保するには、GitLabのセキュリティスキャンやパイプライン実行ポリシーを活用した自動検証の仕組みが欠かせません。AIと人間、それぞれの強みを活かした開発フローが、今後ますます重要になっていくでしょう。\n\n> 今すぐ始められる：GitLabでAIを使ったソフトウェア開発を体験しよう\n>\n> [GitLab Duoの無料トライアルに申し込む](https://about.gitlab.com/ja-jp/solutions/gitlab-duo-pro/sales/)\n\n## よくある質問\n\n### Q1: GitLabのAI機能にはどのようなものがありますか？\n\nA1: GitLabのAI機能「GitLab Duo」には、ソースコードの提案、テストケース/コードの生成はもちろん、脆弱性の自動修復や、CI/CD失敗時の根本原因分析など、ソフトウェア開発全体に対するAIによる支援機能群が含まれています。\n\n\n### Q2: GitLab Duoはユーザーのソースコードを学習に使いますか？\n\nA2: いいえ。GitLab Duoは利用者のコードやデータをモデルの再学習には使用しません。GitLabはユーザーデータのプライバシーとセキュリティを重視しており、企業向けにも安心して利用できる設計となっています。詳細については、[GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/)をご確認ください。\n\n### Q3: Claude Codeとは何ですか？\n\nA3: Claude Codeとはエージェント型AIで、ターミナル上でAIにコマンドを実行させることで既存ツールを使いながら効率的に開発できます。\n\n### Q4: GitLab CLIのGLabとは何ですか？\n\nA4: GLabは、GitLab公式が提供するオープンソースのCLIツールです。GLabをターミナルに統合し、作業中のコマンドラインツールや、IDEの中に表示できます。","2025-07-14",[860],"Naoharu Sasaki","エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法をご紹介します。","Claude Code × GitLab：AI活用を加速する、エージェンティックAIとGitLab CLIによる効率的なソフトウェア開発フロー",[838,109,864,865,714,796,533,234,776,797,810],"code review","collaboration",{"featured":91,"template":800,"slug":867},"claude-code-gitlab-ai-development-workflow",{"category":690,"slug":694,"posts":869},[870],{"content":871,"config":880},{"title":872,"description":873,"authors":874,"heroImage":819,"date":876,"body":877,"category":694,"tags":878,"updatedDate":879},"今すぐ対策を：Docker Hubのレート制限がGitLab CI/CDに与える影響","Docker Hubの新しいプルレート制限がGitLabのパイプラインにどのような影響を与えるか、また、その影響によってCI/CDパイプラインが中断されるのを防ぐ対策を解説します。",[875],"Tim Rizzi","2025-03-24","2025年4月1日より、DockerはDocker\nHubに新たな[プルレート制限](https://docs.docker.com/docker-hub/usage/)を導入します。これは、GitLabで稼働しているものを含め、業界全体のCI/CDパイプラインに大きな影響を及ぼす可能性があります。最も大きな変更点は、未認証ユーザーに対して1時間あたり10回までというプル制限が設けられることです。\n\n\n## 変更点\n\n\n4月1日から、Dockerは以下のプルレート制限を適用します。\n\n\n| ユーザータイプ | 1時間あたりのプルレート制限 | パブリックリポジトリ数 | プライベートリポジトリ数 |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business、Team、Pro（認証済） | 無制限（フェアユース） | 無制限 | 無制限 |\n| Personal（認証済） | 100 | 無制限 | 最大1つ |\n| 未認証ユーザー | IPv4アドレスまたはIPv6/64サブネットごとに1時間あたり10回 | 該当なし | 該当なし |\n\n\n\u003Cp>\u003C/p>\n\nこの変更が重要な理由は以下のとおりです。\n\n\n* GitLabの依存プロキシは現在、未認証ユーザーとしてDocker Hubからプルしています。\n\n* 依存プロキシを使用していないほとんどのCI/CDパイプラインは、未認証ユーザーとしてDocker Hubから直接プルしています。\n\n* GitLab.comのホステッドランナーでは、複数のユーザーが同じIPアドレスやサブネットを共有することがあり、全体がこの制限の対象になります。\n\n\n## GitLabユーザーへの影響\n\n\n**Docker Hubからの直接プルに関する影響**\n\n\nCI/CDパイプラインがDocker\nHubから認証なしで直接イメージをプルしている場合、IPアドレスごとに1時間あたり10回の制限が適用されます。頻繁に実行されるパイプラインや、同じランナーインフラを共有している複数プロジェクトでは、この制限にすぐに達してしまい、パイプラインの失敗が発生する可能性があります。\n\n\n**GitLab依存プロキシへの影響**\n\n\nGitLabの依存プロキシ機能は、DockerイメージをGitLab内にキャッシュすることでパイプラインの高速化や外部依存関係の削減を実現します。ただし、現在の実装では未認証ユーザーとしてDocker\nHubからプルしているため、これも1時間あたり10回という制限の対象になります。\n\n\n**ホステッドランナーへの影響**\n\n\nGitLab.comのホステッドランナーでは、[Google\nCloudのプルスルーキャッシュ](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=ja)を使用しています。これにより、よく使われるイメージがミラーされ、レート制限を回避できます。`.gitlab-ci.yml`ファイル内で`image:`または`services:`として定義されたジョブイメージは、レート制限の影響を受けません。\n\n\n一方で、ランナー環境内でイメージをプルするケースではやや複雑になります。ランナー実行中にイメージをプルする最も一般的なユースケースは、Docker-in-DockerやKanikoを使ってイメージをビルドする場合です。このシナリオでは、`Dockerfile`で指定されたDocker\nHubのイメージが直接プルされるため、レート制限の影響を受ける可能性があります。\n\n\n## GitLabの対応\n\n\nこの問題を緩和するため、GitLabでは以下の対応を進めています。\n\n\n* **依存プロキシの認証：**\nGitLabの[依存プロキシ機能](https://gitlab.com/gitlab-org/gitlab/-/issues/331741)にDocker\nHubの認証のサポートを追加しました。これにより、依存プロキシは認証済みユーザーとしてDocker\nHubからイメージをプルできるようになり、レート制限が大幅に緩和されます。\n\n* **ドキュメントの更新：** Docker\nHubのパイプライン認証の設定に関する明確なガイダンスを提供するために、[ドキュメント](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials)を更新しました。\n\n* **内部インフラの整備：** GitLab.comのホステッドランナーへの影響を最小限にするため、内部インフラを整備中です。\n\n\n## ユーザー側でできる対策\n\n\n**オプション1：パイプラインでDocker Hub認証を設定する**\n\n\nDocker\nHubから直接プルしているパイプラインでは、認証を設定することでレート制限を1時間あたり100回（または有料プランなら無制限）まで増やせます。\n\n\nDocker\nHubの認証情報をプロジェクトまたはグループのCI/CD変数に追加してください（`.gitlab-ci.yml`には追加しないでください）。`DOCKER_AUTH_CONFIG`\nCI/CD変数の正しい設定方法については、[Dockerイメージの使用に関するドキュメント](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials)を参照してください。\n\n\n**オプション2：GitLabのコンテナレジストリを使用する**\n\n\n頻繁に使用するDockerイメージを[GitLabのコンテナレジストリ](https://docs.gitlab.com/user/packages/container_registry/)にプッシュすることで、CI/CDの実行中にDocker\nHubからプルする必要がなくなります。\n\n\n1. Docker Hubからイメージをプルします\n\n2. GitLabコンテナレジストリにタグ付けします\n\n3. GitLabコンテナレジストリにプッシュします\n\n4. パイプラインをGitLabコンテナレジストリからプルするよう更新します\n\n\n```\n\ndocker pull busybox:latest\n\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\n\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n\n```\n\n\nそれから、`.gitlab-ci.yml`で以下のように記述します。\n\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n\n**オプション3：GitLabの依存プロキシを使用する**\n\n\nGitLabの依存プロキシ機能を使うことで、Dockerイメージをキャッシュしてプロキシ経由で取得できるため、外部依存関係を減らし、レート制限の問題を軽減できます。\n\n\n現在の認証オプションは以下のとおりです。\n\n* GitLab 17.10：[GraphQL\nAPI](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api)を使って、依存プロキシ用のDocker\nHub認証を設定\n\n* GitLab 17.11：グループ設定に新しく追加されたUIベースの設定を使用（GitLab.comでは既に利用可能）\n\n\n認証が正しく設定されると、以下の操作が可能になります。\n\n\n1. グループの依存プロキシ設定でDocker Hubの認証情報を設定する\n  - GitLab 17.11以降（またはGitLab.com）：グループ設定 > パッケージとレジストリ > 依存プロキシで設定\n  - GitLab 17.10：GraphQL APIで認証を設定\n2. CI/CD設定で依存プロキシURLを使用するよう、パイプラインを更新する\u003Cbr>\n\n`image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n\n**オプション4：Docker Hubの有料プランを検討する**\n\n\nDocker\nHubの利用が多い組織の場合は、プル回数が無制限の有料Dockerサブスクリプション（TeamまたはBusiness）へのアップグレードが最も簡単な解決策となる場合があります。\n\n\n## Docker Hubのレート制限による影響を減らすベストプラクティス\n\n\nどのオプションを選ぶ場合でも、Docker Hubのレート制限の影響を最小限に抑えるために、以下のベストプラクティスを参考にしてください。\n\n\n* `latest`タグではなく、特定のバージョンタグを使用して不要なプルを避ける\n\n* Dockerファイルを統合し、同じベースイメージを複数のプロジェクトで使い回す\n\n* あまり重要でないパイプラインは、ピーク時間を避けて実行するようスケジュールする\n\n* キャッシュを有効活用し、同じイメージを繰り返しプルするのを避ける\n\n\n**注：** Docker\nHubの[ドキュメント](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition)によると、プル回数はイメージのサイズやレイヤー数ではなく、manifestを取得した時点で1回とカウントされます。\n\n\n## スケジュールと今後の流れ\n\n\n**現在**\n  * Docker Hubからの直接プルに認証を実装します\n* GitLab.comユーザーは以下のいずれかで依存プロキシ認証を設定できます\n    * GraphQL API\n    * グループ設定のUI\n  * Self-ManagedのGitLab 17.10ユーザーはGraphQL APIを使用して依存プロキシ認証を設定できます\n\n**2025年4月1日**\n  * Docker Hubのレート制限が始まります\n\n**2025年4月17日**\n  * Self-Managedインスタンス向けの依存プロキシ認証機能をUIに追加したGitLab 17.11がリリースされます\n\nパイプラインの予期せぬ失敗を回避するために、可能な限り速やかに対応することをおすすめします。多くのユーザーにとっては、Docker\nHub認証を使用して依存プロキシを設定することが最も効率的な長期的解決策となります。\n\n\n>\nご質問がある場合や、実装に関してサポートが必要な場合は、[こちらのイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/526605)をご覧ください。GitLabのチームによる対応が確認できます。\n\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[109,742,795],"2025-03-31",{"slug":881,"featured":91,"template":800},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":702,"slug":706,"posts":883},[884,900,912],{"content":885,"config":898},{"title":886,"description":887,"authors":888,"heroImage":890,"date":891,"body":892,"category":706,"tags":893,"updatedDate":897},"共同開発プログラム：ユーザーとともに築くGitLab","Thales社、Scania社、Kitware社などの組織がどのようにGitLabのエンジニアと連携し、コミュニティ全体に利益をもたらす重要な機能の開発にコントリビュートしているかをご紹介します。",[889],"Fatima Sarah Khalid","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","2025-01-30","過去一年間で、800人以上のコミュニティメンバーによって、GitLabに3,000以上のコントリビュートが寄せられました。コントリビューターにはThales社やScania社などの世界的な企業のチームメンバーも含まれており、GitLabの[共同開発プログラム](https://about.gitlab.com/community/co-create/)を通じてGitLabの未来を共に築いています。このプログラムでは、GitLabユーザーがGitLabのエンジニアと直接協力し、プラットフォームに価値ある機能を提供しています。\n\nワークショップやペアプログラミング、継続的なサポートを通じて、プログラム参加者はGitLabのアーキテクチャやコードベースに触れながら、機能改善や問題解決に取り組みます。\n\nThales社のオープンソースアドボケートであるSébastien Lejeune氏は次のように述べています。「共同開発プログラムを通じた経験は本当に素晴らしいものでした。GitLabのコントリビューターサクセスチームのエンジニアと話し合いを始めてから、GitLabのリリースに反映されるまでわずか2か月でした」\n\nこの記事では、GitLabユーザーが共同開発プログラムを通じて、どのようにアイデアをコードとして実装し、その過程で学びながらコントリビュートしているのかをご紹介します。\n\n## 共同開発プログラムについて\n\n[GitLab Development Kit（GitLab開発キット、略してGDK）](https://gitlab.com/gitlab-org/gitlab-development-kit)は、コントリビューターがGitLabではじめて開発を行う際に役立ちます。「新しいコントリビューターにアドバイスするとしたら、GDKで何かを壊すことはできないということです。変更を加えてうまくいかない場合は、元に戻したり、最初からやり直したりすることができます。GDKの良さは、環境を気にすることなく、調整したり、テストしたり、学んだりできることです」とGitLabのコントリビューターサクセスチームでシニアフルスタックエンジニアを務めるRaimund Hookは言います。\n\n共同開発プログラムに参加する各組織は、コントリビュートのプロセス全体を通じて次のようなサポートを受けられます。\n\n- __テクニカルオンボーディングワークショップ__：GDKのセットアップやGitLabのアーキテクチャを理解するための専用セッション\n\n- __1対1のエンジニアリングサポート__：GitLabエンジニアとのペアプログラミングや技術的なアドバイス\n- __アーキテクチャの詳細解説__：各組織がコントリビュートしている課題に関連する特定のGitLabコンポーネントに焦点を当てたセッション\n- __コードレビューのサポート__：マージリクエストの手順に関する詳細なフィードバックとガイダンス\n- __定期的なチェックイン__：進捗状況を確認し、あらゆる課題に対処するための継続的なコラボレーション\n\nこの仕組みにより、GitLabのコードベースやRuby/Goプログラミング言語になじみのないチームでも、効果的にコントリビュートできるようになります。Kitware社のJohn Parent氏は次のように語ります。「GitLabを見たことも、使ったこともない人は、複数のプロジェクトにまたがる洗練されたアーキテクチャと膨大なコードを見て圧倒されるかもしれません。共同開発プログラムでは、社内研修で何週間もかけて学ぶ内容を、的を絞った短期集中コースとして習得できます」\n\nこのプログラムの成果は、新機能の提供にとどまりません。GitLabとそのユーザーコミュニティの間に長期的な関係を築くことにもつながっています。「情熱を持ってGitLabの開発にコントリビュートしてくださるユーザーのみなさまを見て、私たちエンジニアも刺激をもらっています。ユーザーは『GitLab流』を学び、エンジニアはユーザーがGitLabの未来を形作る姿勢を目の当たりにするのです」とGitLabのプリンシパルエンジニアであるShekhar Patnaikは述べています。\n\n## Thales社のコントリビュートによるプロジェクトUXの向上\n\nThales社は、GitLabの空のプロジェクトUIの改善として、単に機能リクエストを提出するのではなく、自らソリューションを構築しました。同チームのコントリビュートの焦点は、インターフェイスをタブ形式にしてSSH/HTTPS設定を簡素化し、コードスニペットのコピー/ペースト機能を追加することで、新しいプロジェクトのセットアップを効率化することでした。これらの変更は、デベロッパーのワークフローに大きな影響を与えました。\n\nまた、このチームの影響はUXの改善だけにとどまりませんでした。Thales社でエッジクラウドアプリケーションの博士研究員を務めるQuentin Michaud氏は、GDKの改善にもコントリビュートしました。Arch LinuxのパッケージメンテナーでもあるMichaud氏の専門知識により、GDKのドキュメントが改善され、コンテナ化の取り組みが進められたことで、新しいコントリビューターがより簡単に開発を始められるようになりました。\n\nMichaud氏は「オープンソースの経験があったおかげで、Linuxディストリビューション向けのGDKサポートを改善する際に役立ちました。パッケージのバージョン管理ドキュメントを改善する過程で、GitLabのコントリビューターサクセスチームもGDKのコンテナ化に取り組んでいることを知りましたが、双方の取り組みが交わる瞬間を見ることができたのは非常に印象的でした。オープンソースのコラボレーションがより優れたソリューションを生み出すことを実感した瞬間でした」と語ります。\n\nThales社のチームにとってポジティブな経験であったため、Lejeune氏は現在、共同開発プログラムを「オープンソースコントリビュートによる投資対効果をマネージャーに示す強力な事例」として活用しています。\n\n## Scania社のコントリビュートによるパッケージサポートの強化\n\nGitLabの高度なパッケージサポートの必要性を理解したScania社は、自らコントリビュートして、それを構築する機会を見出しました。\n\n「私たちは長年GitLabを使用し、組織内でオープンソースを積極的に推進してきました。共同開発プログラムのおかげで、オープンソースに直接コントリビュートする有意義なアプローチが可能になりました」とScania社のソリューションアーキテクトであるPuttaraju Venugopal Hassan氏は語ります。\n\nチームはまず、コードベースとレビューのプロセスに慣れるために小さな変更から着手し、徐々に大きな機能開発へと進みました。「共同開発プログラムで最も充実感を感じたのは、プロセス全体を振り返り、どれだけ成長したかを実感できたことです」とScania社のソフトウェアデベロッパーであるOcéane Legrand氏は振り返ります。「最初は調査や小さな変更から取り組み、次第により大きなタスクへとステップアップしていきました。その進歩を目の当たりにできてうれしく思います」\n\nScania社のコントリビュートには、パッケージレジストリのバグ修正や、Conanパッケージレジストリ機能の強化が含まれます。これにより、Conanパッケージレジストリは一般公開（GA）に向けた準備が進み、Conanバージョン2のサポートも実装されました。Scania社の取り組みとGitLabとのコラボレーションは、GitLabのパッケージレジストリ機能を大幅に改善する上で、共同開発プログラムがいかに有効であるかを示しています。\n\n「共同開発プログラムを開始してすぐに、非常に体系的に構築されていることを実感しました。コントリビュートに必要なことをすべて学べるトレーニングセッションがありましたし、GitLabのエンジニアとの1対1のセッションでは、GitLabのパッケージアーキテクチャについて深く理解することができ、コントリビュートをスムーズに進められました」とScania社のソフトウェアデベロッパーであるJuan Pablo Gonzalez氏は語ります。\n\nこのプログラムの成果はコードのみにとどまりません。プログラム参加者は、コントリビュートを通じて貴重なスキルを身につけます。[GitLab 17.8リリース](https://about.gitlab.com/ja-jp/blog/gitlab-17-8-release/)では、Legrand氏とGonzalez氏がともにGitLab MVPに選ばれました。Legrand氏は、オープンソースでの作業がGitLabとScania社の両方に与える影響について言及し、自身とチームの新たなスキル習得にもつながったと述べています。「共同開発プログラムを通じてコントリビュートすることで、Rubyやバックグラウンドマイグレーションの知識など、新たなスキルを習得できました。Scaniaの所属チームでアップグレード作業中に問題が発生した際、共同開発プログラムですでに同じ問題を経験していたため、トラブルシューティングを手伝うことができました」\n\n## Kitware社のコントリビュートによる高性能計算（HPC）向け認証の最適化 \n\nKitware社は、国立研究所との協力で培った専門知識を活かし、GitLabの認証フレームワークの改善にコントリビュートしました。このコントリビュートには、GitLabのOAuth2デバイス認証付与フローのサポートの追加や、新しいデータベーステーブル、コントローラー、ビュー、ドキュメントの実装が含まれます。これにより、GitLabの認証オプションが強化され、ブラウザを持たないデバイスや入力機能が限られたデバイスでも利用しやすくなりました。\n\n「共同開発プログラムは、外部コントリビューターとしてGitLabにコントリビュートする最も効率的で効果的な方法です。デベロッパー同士のペアリングセッションを通じて、1人で作業していたら見逃していたかもしれない、より優れた実装方法を見つけることができました」とKitware社の研究開発エンジニアであるJohn Parent氏は話します。\n\n長年にわたりオープンソースにコントリビュートしてきたKitware社は、GitLabの開発手法を特に高く評価しています。「GitLabほどの規模であれば、既成のソリューションに頼ることはないだろうと思っていましたが、社内で独自のソリューションを開発するのではなく、Rubyの依存関係を取り入れているのを見て素晴らしいと思いました。C++の世界ではパッケージマネージャーがほとんど使われないため、このようなアプローチを目にし、そのシンプルさを実感できたのは新鮮でした」とParent氏は述べます。\n\n## 共に築く未来：共同開発のメリット\n共同開発プログラムは、双方に価値をもたらします。「このプログラムは、GitLabのエンジニアとユーザーの間のギャップを埋める役割を果たしています。ユーザーと一緒に取り組む中で、日々の課題や、GitLabのどの部分を重視しているのか、どこに改善の余地があるのかを直接聞くことができます。ユーザーがGitLabの開発に積極的に関わろうとしている姿には感銘を受けます」と、GitLabのスタッフバックエンドエンジニアであるImre Farkasは説明します。\n\nこの協力的なアプローチには、GitLabの開発スピードを加速させる効果もあります。GitLabのプリンシパルエンジニアであるShekhar Patnaikは次のように述べています。「共同開発を通じて、ユーザーはGitLabのロードマップを前進させる手助けをしてくれています。彼らのコントリビュートにより、重要な機能をより早く提供できるようになり、すべてのユーザーにとって大きなメリットとなっています。このプログラムが拡大するにつれて、実際にその機能を必要としているユーザーと共に開発を進めることで、最も重要な機能の開発をさらに加速できる可能性があります」\n\n## 共同開発を始める\n機能リクエストを実現しませんか？Thales社のようにGitLabのUIを強化したい、Scania社のようにパッケージサポートを充実させたい、またはKitware社のように認証機能を改善したいとお考えなら、共同開発プログラムへご参加ください。本プログラムでは、価値あるオープンソースの経験を積みながら、GitLabの未来を積極的に形作りたい組織を歓迎します。\n\n共同開発プログラムへの参加について、詳しくはGitLabの担当者にお問い合わせいただくか、[共同開発のページ](https://about.gitlab.com/community/co-create/)をご覧ください。\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[894,895,896],"contributors","open source","customers","2025-03-10",{"slug":899,"featured":91,"template":800},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":901,"config":910},{"title":902,"description":903,"authors":904,"heroImage":906,"date":907,"body":908,"category":706,"tags":909},"くら寿司が語るソフトウェア開発の「生産性向上」と「セキュリティ・ガバナンス」の重要性【イベントレポート】","2024年10月に開催された「Gartner IT Symposium/Xpo」の当社セッションにおいて、くら寿司様より事例を紹介いただきましたので、その模様をお伝えします。",[905],"GitLab Japan Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665029/Blog/Hero%20Images/_________DX__________________GitLab____________________.jpg","2024-12-05","2024年10月、GitLabはGartner IT Symposium/Xpoに出展しました。このイベントにおいて、GitLabユーザーの[くら寿司株式会社](https://www.kurasushi.co.jp/) 執行役員 DX本部長 中林 章氏に弊社セッションに登壇いただきましたので、本ブログではその模様を中心にレポートします。\n\n![ガートナーITシンポジウム会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/___________________.jpg)\n*会場の様子*\n\n中林氏の講演は、当社のJapan Country Manager 小澤 正治をモデレーターとする対談形式で行われました。開催2週間前に満員御礼となり、当日も満員の来場者が詰めかけた人気セッションでしたが、講演の冒頭で小澤は、「今日のこの時間がMLBのワールドシリーズにぶつかると考えていませんでした。昨夜から、本当に人が来てくれるのかどうか心配していて、皆さんに来ていただけて安心しました」と会場の笑いを誘います。\n\n![くら寿司株式会社 DX本部 執行役員 本部長 中林 章氏 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/_________DX__________________3.jpg)\n*くら寿司株式会社 執行役員 DX本部長 中林 章氏*\n\n中林氏は、「GitLabとの出会いは去年のこのイベントです。私たちが必要としていたソリューションがGitLabだということがすっと腑に落ちて、その場で採用を決めました」と話し、ブースのパネル展示を見てGitLabが合うと感じたと明かします。小澤は「私の講演を聞いてくれたのではなかったのですか」と合いの手を入れましたが、中林氏は「いえ、ブースのパネル展示で」とつれない返事。会場は再び笑いに包まれました。こうして、セッションはやわらかな雰囲気で和気あいあいと進みます。\n\n![GitLab合同会社カントリーマネージャー小澤正治](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/GitLab____________________.jpg)\n*GitLab合同会社 カントリーマネージャー 小澤 正治*\n\n## GitLabに登録したビジネスバックログは、そのままプロダクトバックログになる\n\nくら寿司は、「安心・美味しい・安い」というコンセプトに加え、「ビッくらポン!」を代表とした「楽しい」を追求しています。「抗菌寿司カバー 鮮度くん」など独自の品質管理などでも消費者の信頼を獲得し、成長してきました。また、先進的な業務の標準化、効率化を進め、業界に先駆けて機械化／デジタル化を進めている企業としても知られています。\n\n![くら寿司様サービス展開の歴史](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/_______________.jpg)\n*図：くら寿司のサービス展開の歴史*\n\n中林氏は、そんな同社の歴史について、機械化に取り組んだ時代を経て、デジタル化の時代が来たと説明します。デジタル化には、タッチパネル注文など店舗内のものとスマホ予約システムなど店舗外のものがあり、現在は機械を含めた店舗内のプロセスと店舗内／店舗外のデジタル、および本社のビジネスプロセスをつなぐさまざまな取り組みを実施できる段階に来ています。そして、デジタルテクノロジーとデータを活用した企業理念の実践を実現しようとしているのです。\n\n「GitLabを使って進めているくら寿司流DXで大切にしていることは、独自性です。お客様DX、事業基盤DX、従業員DXと3つのDXを進めていますが、くら寿司ならではの競争力のあるDXを推進することが求められています」（中林氏）\n\nなぜ「ならでは」である必要があるのでしょう。それは、くら寿司の経営スピードが極めて速いサイクルで進むためです。経営会議は2週間に1度あり、その場で意思決定がなされ、プロジェクトが実行に移されます。たとえば異業種とのコラボレーションなどのイベントも、このスピード感で決まり、実行します。現場のアイデアや困りごとはすぐに吸い上げ、優先順位をつけて即座に対応していくことになります。\n\nこれはデジタルにおいても同様で、中林氏は2週間に1度、新たな複数のプロジェクトを開発現場に持ち帰ることになります。中林氏は、「このサイクルに合わせるためには、DevSecOpsが不可欠になります。経営会議の決定をビジネスバックログとしてGitLabに登録すると、それがプロダクトバックログになるイメージです」と話します。\n\nGitLabによってDevSecOpsを根付かせることで、ビジネスの意思決定をプロダクトの計画、設計、開発、リリース、運用というプロセスに一貫した流れに落とし込めます。これにより、セキュリティリスクとビジネスリスクをどちらも低く抑えることができます。GitLab導入後1年を経た今、くら寿司の社内には、「GitLabに合わせて開発する」という文化が根付きました。\n\nすべての開発プロジェクトはGitLabの中で完結するため、開発と運用にかかわるすべての経緯はGitLabを見て、過去のログをたどればわかります。中林氏が経営会議から持ち帰ったビジネスバックログまで遡ることができるのです。セキュリティ面では、シフトレフトを加速させています。成果物によって求めるセキュリティレベルは異なるため、ビジネスモデルやスプリントごとに最適なセキュリティを決定し、それを開発プロセスに組み込むことで、求めるセキュリティレベルを担保できるようにしています。\n\n## セキュリティはプロアクティブな対応に近づけたい\n\n![GitLab導入前の課題と導入後の効果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/GitLab______________.jpg)\n*図：くら寿司のGitLab導入前の課題と導入後の効果*\n\nセキュリティについては、脅威側が日々進化するという問題があり、どれほどの対策をしても終わりはありません。くら寿司の場合、開発プロジェクトのほぼすべてが自社開発になっているため、ソフトウェア・サプライチェーンのリスクは大きな課題です。地産地消の推進に伴い、国内でも地域／店舗ごとにソフトウェアやデータの連携先、デジタルタッチポイントなどは異なります。さらに、海外店舗もあるため、プロセス／データの連携先に対するガバナンスも必要になってきます。\n\nこれらの課題に向き合うために、くら寿司では、「お客様に迷惑をかけないこと」を第一義として整理しています。「セキュリティに対してリアクティブな対応で良しとしようという風潮はあります。しかし、本来プロアクティブな対応を取れるとより良いわけで、少しでもそこに近づける必要はあるでしょう。GitLabのおかげで、リスク要素がよく見えるようになりました。どのサーバで問題が起きているか、という視点でなく、どのスプリントがどの程度のリスクをはらんでいるのか、という視点を得られたのは大きな成果でした」（中林氏）。\n\n![くら寿司株式会社 DX本部 執行役員 本部長 中林 章氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/_________DX_________________.jpg)\n*左より、くら寿司株式会社 執行役員 DX本部長 中林 章氏、GitLab合同会社カントリーマネージャー小澤正治*\n\n海外拠点では、国内システムと共通化すべき部分とそうでない部分を切り分けて運用することにしました。本社の高速な意思決定サイクルを海外にも展開しながら、現地が自ら考えてその地域に最適なプロダクトを開発し、その上で適切なセキュリティを担保できる開発を推進しています。いわば、ITも地産地消なのです。\n\n## お客様に満足し尽くしてもらえるようなAIを提供してみたい\n\n喫緊の課題に、将来のAI活用があります。中林氏は、狭義のITを「回転レーンの寿司を監視するような、モノの判別に使えるようなAI」と定義し、そうではない広義のAIを活用していきたいと語ります。\n\n![くら寿司株式会社 DX本部 執行役員 本部長 中林 章氏 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/_________DX__________________2.jpg)\n*くら寿司株式会社 DX本部 執行役員 本部長 中林 章氏*\n\n中林氏は、「AIはお客様に継続的な価値を提供し続けるために使いたいです。たとえば、お客様が“今はマグロじゃなくてスイーツを食べたい気分”なら、それを察知してレコメンドしてくれるようなAIが居てくれるとうれしくないですか？お客様とずっとコミュニケーションを取ることで、お客様に満足し尽くしてもらえるようなAIを提供してみたいと考えています」と話してくれました。\n\n![Gartner ITシンポジウムにおけるGitLabのブース](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/GitLab_____.jpg)\n*GitLabのブース*\n\n### 関連記事\n[DevOpsで実現。ソフトウェア開発のセキュリティ・ガバナンス【イベントレポート】](https://about.gitlab.com/ja-jp/blog/event-report-gartner-it-infra-2024/)",[896],{"slug":911,"featured":91,"template":800},"event-report-gartner-it-symposium",{"content":913,"config":924},{"title":914,"description":915,"authors":916,"heroImage":918,"date":919,"body":920,"category":706,"tags":921,"updatedDate":923},"GitLabでCIプラットフォームを変革したIndeed社の戦略","世界最大の求人サイトであるIndeed社は、数千のプロジェクトをGitLab CIに移行することで、生産性向上とコスト削減を実現しました。1日あたりのパイプライン実行数が79%増加するなど、得られた主なメリットをご紹介します。",[917],"Carl Myers","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","2024-08-27","***編集者からのお知らせ：GitLabでは、当社ブログの執筆者として、カスタマーコミュニティのメンバーをお招きすることがあります。今回のブログ記事では、Indeed社のCIプラットフォームマネージャーを務めるCarl Myers氏に、GitLabに関する経験を共有していただきました。*** \n\nIndeedは、「We help people get jobs.（人々の仕事さがしを支援する）」というミッションを掲げています。Indeedは、[月間3億5,000万人以上のユニークビジターを持つ、世界最大の求人サイト](https://jp.indeed.com/about)（外部サイト）です。\n\nIndeedのエンジニアリングプラットフォームチームは「We help people to help people get jobs.（人々の仕事さがしを支援する人を支援する）」というモットーを掲げており、これは会社のミッションとは少し異なるものです。20年近くにわたり、常に求職者を第一に考えるデータドリブンのエンジニアリング文化を醸成してきました。この文化を推進する中で、当社はこのアプローチを実現し、日々エンジニアが求職者によい結果を届けられるようにするためのツールの構築に責任を持って取り組んでいます。\n\nわずか11人から成るIndeedのCIプラットフォームチームは、GitLabの継続的インテグレーション（CI）を導入したことで、社内の数千人のユーザーを効果的にサポートできるようになりました。このほかにも、IndeedはGitLab CIへの移行により次のメリットを得ました。\n- 1日あたりのパイプライン実行数が79%増加\n- CIハードウェアコストを10～20%削減\n- サポート負担の軽減\n\n## CIプラットフォームの進化：Jenkinsから拡張性に優れたソリューションへ\n\n多くの大手テクノロジー企業と同様に、当社は会社の成長に伴い、当時利用可能なオープンソースや業界標準のソリューションを用いてCIプラットフォームを段階的に構築してきました。2007年、Indeedのエンジニアが20人にも満たなかった頃、チームではHudson（Jenkinsの前身）を使用していました。\n\n20年近くにわたる成長を経た現在、Indeedには数千人のエンジニアが在籍しています。新しい技術が登場するたびに、段階的に改善に取り組み、2011年頃にはJenkinsに移行しました。また、[AWS EC2](https://aws.amazon.com/ec2/)を使用して、ほとんどのワークロードを動的なクラウドワーカーノードに移行することにも成功しました。しかし、Kubernetes時代に突入すると、システムのアーキテクチャが限界に達しました。\n\nJenkinsのアーキテクチャは、クラウドを前提に設計されていません。Jenkinsは、パイプラインの重要な部分を実行し、特定のタスクをワーカーノードに割り当てる役割を持つ『コントローラー』ノードを使用して動作します（ワーカーノードはある程度水平にスケーリングが可能）。しかし、コントローラーのスケーリングは手動で調整する必要があります。\n\nジョブが多すぎて1つのコントローラーに収まらない場合、ジョブを複数のコントローラーに手動で分割する必要があります。CloudBees社は、こうしたボトルネックを軽減するための対策として、CloudBees Jenkins Operations Centerをはじめとする、複数のコントローラーを一元管理するソリューションを提案しています。しかし、各コントローラーは依然として脆弱な単一障害点となり、Kubernetes環境での運用には困難があります。ノードのロールアウトやハードウェアの障害などのアクティビティはダウンタイムを引き起こします。\n\nJenkins自体に内在する技術的な制約に加えて、自社のCIプラットフォームにも、社内プロセスが原因で発生した問題がいくつかありました。たとえば、各リポジトリ内のコードからジョブを生成するためにGroovy Jenkins DSLを使用していたため、各プロジェクトがコピー＆ペーストされた独自のジョブパイプラインを持つことになり、その結果、数百ものバージョンが生成され、メンテナンスや更新が困難になりました。Indeedのエンジニアリング文化は柔軟性を重視し、チームが別々のリポジトリで作業することを許容していますが、その柔軟性により、チームは定期的にメンテナンスを行わなければならず、多大な時間を費やさせる負担要因となっていました。\n\nこうした技術的負債を認識した当社は、「[Golden Pathパターン](https://tag-app-delivery.cncf.io/whitepapers/platforms/)（英語）」に目を向けました。このパターンは、柔軟性を保ちながら、アップデートを簡素化し、プロジェクト間で運用の一貫性を促進するための標準的な手順を提供するものです。\n\nIndeedのCIプラットフォームチームは11人ほどのエンジニアで構成されており、決して規模は大きくないものの、サポートリクエストへの対応、アップグレードやメンテナンスの実施、そしてグローバル企業としての常時サポート体制の確保を通じて、数千人のユーザーサポートにあたっています。\n\n当社のチームは、GitLabインスタンスだけでなく、アーティファクトサーバーや共有ビルドコード、さらに複数のカスタムコンポーネントを含むCIプラットフォーム全体をサポートしているため、業務量は非常に多岐にわたります。そのため、既存のリソースを最大限に活用し、課題に対処する計画が必要でした。\n\n## GitLab CIへの移行\n\n主要なステークホルダーとの慎重な設計レビューを経て、当社は全社的にJenkinsからGitLab CIへ移行することを決定しました。GitLab CIを選んだ主な理由は次のとおりです。\n\n- すでにGitLabをソースコード管理に使用していたため。\n- GitLabは、当社がCIに求める機能をすべて備えた包括的なソリューションであるため。\n- GitLab CIの設計は拡張性に優れ、クラウドにも対応しているため。\n- GitLab CIは、テンプレートを拡張して新たなテンプレートを作成できるという点が、当社の「Golden Path」戦略と合致していたため。\n- GitLabがオープンソースソフトウェアであり、さらにGitLabチームが当社の修正提案に常に協力的であったことから、柔軟性と安心感を得られたため。\n\nGitLab CIプラットフォームの一般提供を正式に発表した時点で、すでに全ビルドの23%がGitLab CI上で行われていました。これは、個々のユーザーの自主的な取り組みや早期導入者のおかげです。\n\nしかし、移行の課題は「ロングテール」にありました。Jenkinsには多くのカスタムビルドが存在するため、自動移行ツールはほとんどのチームに適用できませんでした。新しいシステムの利点の多くは、旧システムを完全に停止（0%）にするまで実現しません。そうして初めてハードウェアを停止し、CloudBeesのライセンス費用を削減できるようになるのです。\n\n## 機能の同等性とゼロからの再出発の利点\n\nIndeedでは多様な技術をサポートしていますが、最も一般的な言語はJava、Python、JavaScriptです。これらの言語は、ライブラリの構築、デプロイ可能なサービス（ウェブサービスやアプリケーションなど）、およびcronジョブ（データレイク内のデータセットを構築するような、定期的に実行されるプロセス）を作成するために使用されます。これらの言語は、Javaライブラリ、Pythonのcronジョブ、JavaScriptのウェブアプリケーションといったプロジェクトタイプのマトリックスを形成しており、Jenkinsではそれぞれに対して事前定義されたスケルトンがありました。そのため、これらすべてのプロジェクトタイプに対応する「Golden Path」テンプレートをGitLab CIでも作成する必要がありました。\n\nほとんどのユーザーは推奨されたパスをそのまま使用できましたが、カスタマイズが必要な場合でも「Golden Path」は有用な出発点になりました。必要な部分だけを調整しながら、将来的には一元管理されたテンプレートが更新されるたびに、その利点を享受することができます。\n\n当社はすぐに、カスタマイズが必要なユーザーでさえ「Golden Path」の採用に前向きであり、少なくとも試用を望んでいることがわかりました。もし以前のカスタマイズが必要であれば、後から追加することができたからです。これは驚くべき結果でした。大幅なカスタマイズに投資してきたチームはそれを手放すことに抵抗があるだろうと思っていましたが、大多数のチームはもはやそれを気にしなくなっていたのです。これにより、多くのプロジェクトを非常に迅速に移行することができました。プロジェクトに「Golden Path」（インクルードを含む6行ほどの小さなファイル）を追加するだけで、あとは各チームがそれを活用して進めることができました。\n\n## インナーソースによる救済\n\nCIプラットフォームチームは、「外部からのコントリビュートを優先する」というポリシーを採用し、社員全体の参加を促進しました。このアプローチは「インナーソース」と呼ばれることもあります。私たちは、外部からのコントリビュート（自分たちのチーム以外からのコントリビュート）を促進するために、テストやドキュメントを作成しました。カスタマイズを望むチームは、そのカスタマイズを、Golden Pathに組み込んで、機能フラグを使用して共有できるようになりました。これにより、カスタマイズを行ったチームは自分たちの作業を他のチームと共有できるようになっただけでなく、そのカスタマイズがCIプラットフォームチームのコードベースの一部になったため、将来的にそのカスタマイズが壊されないことを保証できるようになりました。\n\nこの取り組みには、特定のチームが必要な機能を求めて待機することなく、自分たちでその開発に取り組めるようになったという利点もありました。たとえば、「その機能は数週間後に実装する予定ですが、もし早めに必要であれば、ぜひコントリビュートしてください」と伝えることができます。結果的に、同等性に必要な多くのコア機能がこのようなアプローチで開発され、チームのリソースでは実現できないほど迅速かつ質の高い形で提供されました。このモデルがなければ、移行は成功しなかったでしょう。\n\n## 予定より早く、予算内で達成\n\nチームのCloudBeesライセンスは2024年4月1日に期限切れになりました。これに伴い、完全移行を達成するための挑戦的な目標を設定しました。当時、ビルド全体の80%（全プロジェクトの60%）でCIにJenkinsが使用されていたことを考えると、この目標は特に野心的だったと言えます。つまり、2,000以上の[Jenkinsfiles](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/)を新たに書き直すか、Golden Pathのテンプレートに置き換える必要があったのです。\n\nこの目標を達成するために、チームはドキュメントやサンプルコードを提供し、可能な限り機能を実装したほか、ユーザーが機能を追加できるように支援しました。\n\nまた、定期的なオフィスアワーを設け、誰でも質問をしたり、移行の支援を求めたりできるようにしました。さらに、移行に関連するサポートの質問を、一部を除いて他のどの質問よりも優先しました。CIプラットフォームはGitLab CIのエキスパートとなり、その専門知識をチーム内および組織全体で共有しました。\n\n自動移行はほとんどのプロジェクトでは実現できませんでしたが、カスタマイズがまれな比較的小規模なプロジェクトには有効であることがわかりました。チームはSourcegraphの一括変更キャンペーンを作成し、数百のプロジェクトを移行するためにマージリクエストを送信しました。そして、ユーザーにその承認を促しました。\n\nユーザーからの成功事例を広く共有し、ユーザーがGolden Pathに新しい機能を追加するたびに、「GitLab CIに移行するとこれらの機能が無料で利用できる」と宣伝しました。これらの機能には、ビルトインのセキュリティやコンプライアンススキャン、CIビルドのSlack通知、他の内部システムとのインテグレーションなどがあります。\n\nさらに、積極的な「screamテスト」キャンペーンを実施しました。しばらく実行されていない、または成功していないJenkinsジョブを自動的に無効にし、必要であれば再度有効にできるとユーザーに通知しました。これは、手間をかけずに実際に必要なジョブを特定できる効果的なアプローチでした。前回のCI移行（JenkinsからJenkinsへの移行）以降、一度も実行されていない数千のジョブがあり、これらをほぼすべて安全に無視できることがわかりました。\n\n2024年1月には、例外が明示的に要求されない限り、すべてのJenkinsコントローラーが読み取り専用（ビルド不可）になると発表しました。コントローラーに関する所有情報が大幅に改善され、組織の構造に合致していたため、ジョブよりもコントローラーに焦点を当てることが合理的でした。コントローラーのリストはジョブのリストよりもはるかに管理しやすいものでした。\n\n例外を認めるために、ユーザーにはスプレッドシートでコントローラーを見つけ、その横に連絡先情報を入力してもらうよう依頼しました。これにより、フォローアップできる利害関係者の最新リストを確実に取得できるだけでなく、ユーザーからも絶対に必要なジョブを明確に知らせてもらうことができました。ピーク時には約400ものコントローラーがありましたが、1月には220に減少し、そのうち例外を必要とするのは54のコントローラーだけでした（そのうちいくつかはチームで所有し、テストやカナリアのために使用していました）。\n\n![Indeed - Jenkinsコントローラー（個数）の推移グラフ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099357/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099357392.png)\n\n私たちは、約50チームの管理可能なリストをチーム内で分担し、各チームの移行の進捗状況を聞き取りし始めました。1月、2月中に、そして一部のチームは2月28日までに私たちの支援なしで移行を完了させる予定であり、他のチームはその時点までのプロジェクト廃止を計画していることが判明しました。そして、ごく少数のチームが期限内に完了できるか非常に心配していました。\n\n私たちはこの少数のチームと協力し、きめ細やかな個別対応サービスを提供しました。私たちには移行を代行する上での専門知識が不足しているものの、そのチームの特定分野の専門家と協力できることを説明しました。一部のプロジェクトでは、私たちがコードを書き、そのチームがレビューを行い、他のプロジェクトではそのチームがコードを書き、私たちがレビューを行いました。最終的に、すべての努力が実を結び、8か月前に宣言した日に、Jenkinsを無事に廃止することができました。\n\n## 成果：CI効率とユーザー満足度の向上\n\nJenkins CIプラットフォームのピーク時には、1日あたり14,000以上のパイプラインが実行され、数千のプロジェクトをサポートしていました。現在、GitLab CIプラットフォームは、1日あたり40,000以上のパイプラインを処理し、通常は25,000以上のパイプラインが日常的に稼働しています。各パイプラインのジョブごとの増分コストはJenkinsと同程度ですが、コントローラーを実行するためのハードウェアのオーバーヘッドがなくなりました。これらのコントローラーは、単一障害点であり、スケールの制限要因でもあったため、プラットフォームを人工的にセグメント化せざるを得ませんでした。正確な比較は難しいものの、このオーバーヘッドがなくなったことで、CIハードウェアコストは10～20%削減できたと考えています。さらに、GitLab CIはクラウド上で自動的にスケールし、複数の可用性ゾーンで動作する耐障害性を備えているほか、テンプレート言語には優れた公開ドキュメントがあるため、サポートの負担も軽減されています。\n\n特筆すべきもうひとつの利点としては、現在、Golden Pathの採用率が70%を超えていることです。これにより、私たちが改善策をロールアウトすれば、Indeedの5,000以上のプロジェクトは、特別な操作をせずにすぐにそのメリットを享受できるようになることがわかりました。この結果、一部のジョブをよりコスト効率の高いARM64インスタンスに移行したり、ユーザーのビルドイメージをより簡単に更新したりできるようになりました。また、他のコスト削減の機会をより適切に管理することも可能になりました。最も重要なことは、ユーザーが新しいプラットフォームに満足していることです。\n\n__著者について__：\n*Carl Myers氏はカリフォルニア州サクラメント在住で、Indeed社のCIプラットフォームチームのマネージャーを務めています。Carl氏は、約20年にわたるキャリアを通じて、大小さまざまな企業で、エンジニアのニーズを満たし、その能力を引き出すための社内ツールやデベロッパー向けプラットフォームの構築に尽力してきました。*\n\n**謝辞**：\n*この移行プロジェクトは、Tron Nedelea氏、Eddie Huang氏、Vivek Nynaru氏、Carlos Gonzalez氏、Lane Van Elderen氏、そしてCIプラットフォームチームの他のメンバーの尽力なしには実現できませんでした。チームはまた、プロジェクト全体を通じて、合意やリソースの確保、そして社内全体の調整に尽力していただいたDeepak Bitragunta氏とIrina Tyree氏のリーダーシップに、特に感謝しております。最後に、コード、フィードバック、バグレポートに貢献し、プロジェクトの移行を支援してくださったIndeed社の皆様に感謝申し上げます。*\n\n**この記事は、Indeedエンジニアリングブログに掲載された[「How Indeed Replaced Its CI Platform with GitLab CI」](https://engineering.indeedblog.com/blog/2024/08/indeed-gitlab-ci-migration/)の編集版です。**",[896,109,922,795],"user stories","2025-01-10",{"slug":925,"featured":91,"template":800},"how-indeed-transformed-its-ci-platform-with-gitlab",{"category":714,"slug":718,"posts":927},[928,938,950],{"content":929,"config":936},{"title":930,"description":931,"heroImage":932,"date":834,"body":933,"category":718,"tags":934,"authors":935},"みんなの銀行の内製化戦略とAIへの取り組み【イベントレポート】","2025年6月に開催された「Gartner Application Innovation & Business Solutions Summit 2025」の当社セッションにおいて、株式会社みんなの銀行 取締役常務執行役員CIO宮本 昌明氏にご講演いただいた模様をお伝えします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756178708/bcuxu1pffexqdzy4ebxf.jpg","GitLabは2025年6月、都内ホテルで開催された「Gartner Application Innovation & Business Solutions Summit 2025」に出展しました。開催したセッションは約170人の参加者を集め、株式会社みんなの銀行（以下、みんなの銀行） 取締役常務執行役員CIO宮本 昌明氏をお招きし、当社Japan Country Manager小澤 正治と対談形式で実施しました。本記事では、その模様をお伝えします。\n\n## BaaS事業を支えるプラットフォーム\n\n![株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179493/ven7v5yf2xhbio51itqm.jpg)\n\n*株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏*\n\nみんなの銀行は、2021年5月に事業を開始したデジタルバンクです。日本で初めてフルクラウドで銀行システムを構築・運用することでも注目を集めており、B2Cのスマホアプリ事業に加え、APIを主軸としたBaaS（Banking as a Service）事業や、バンキングシステムの外販も行っています。\n\n現在、立ち上げから約4年が経過。すでに130万口座を獲得し、ユーザーの70%は40歳未満の若年層です。ふくおかフィナンシャルグループの傘下で、福岡市に本社を置いていますが、SNSなどを活用したマーケティングが奏功し、顧客層は全国に広がっています。\n\n個人向けのデジタルバンクとして話題をさらう中、ビジネスの1つの柱に育ちつつあるのがBaaS（Banking as a Service）事業です。同事業では、みんなの銀行が自社のシステムを[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api/)を通して外部へと公開。ユーザーは、提携事業者のアプリなどを経由して「自分がみんなの銀行のサービスを使っている」ことを意識せず、銀行機能を利用できるようになります。\n\n公開中のAPIは多彩です。振込・決済だけでなく、認証・同意、本人確認済み情報提供、振込キャンセルなどをラインアップ。この日の時点で公開されている提携先は24社に及び、すでに非金融業界を含む15社が自社サービスに組み込んだ機能をリリースしています。\n\n![株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179499/eeqee2fynr7zhhzixhhf.jpg)\n\n*株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏*\n\nみんなの銀行は、銀行業務の心臓部となる勘定系システムを、Google Cloud上にフルスクラッチで開発しています。宮本氏は、「BaaS基盤は勘定系の横に置くイメージ」と勘定系と密に連携させたBaaS基盤について説明します。このBaaS基盤の開発に、GitLabは大きな役割を果たしました。BaaS部分の開発にあたり同行は、マイクロサービスおよびイベント駆動型アーキテクチャを採用し、TDD（テスト駆動開発）を導入。その開発プラットフォームになったのがGitLabなのです。\n\n導入当時は、組織もシステムもゼロからのスタートでした。構想の初期段階からの必須要件は、セキュリティを高めるだけでなく、ログ取得や権限管理などのコンプライアンスも備えたDevSecOps環境を作ること。宮本氏は、「セキュリティとコンプライアンスは絶対条件でした。そして、その上で効率化を追求します。これらは並び立たないように聞こえますが、並び立たせるのがわれわれの基本スタンスです」と話します。\n\nソフトウェアライフサイクル全体をカバーできる一気通貫のソリューションとしてGitLabを採用し、テスト自動化、セキュリティスキャン、ディペンデンシースキャン、[SBOM](https://about.gitlab.com/ja-jp/blog/what-is-sbom/)など幅広い機能を活用するに至りました。\n\nまた、コンプライアンスパイプラインとして[GitOps](https://about.gitlab.com/ja-jp/topics/gitops/)の考え方も導入しました。Gitリポジトリを唯一絶対の存在（SVoT）と位置づけ、本番環境がGitリポジトリと異なる場合は自動修正します。ただし、リリース承認プロセスを維持することでガバナンスを確保するなど、実際に運用するにあたってさまざまな工夫も取り入れています。\n\nテストの民主化についても独自のアプローチで取り組んでいます。開発側だけがテストを実行するのでなく、ビジネス側もテストに関与することで責任を分担するなどの施策は、テストの自動化が進むとともに社内に根付いてきました。\n\n## 優秀なエンジニアたちに挑戦の場を提供\n\n![株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179493/r2slryft1yl2ouuqfnmk.jpg)\n\n*株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏*\n\nみんなの銀行は、GitLabをプラットフォームとして実施する開発業務の大半を内製化しています。宮本氏は、内製化のメリットについて、大きく4つのポイントを挙げます。まずは、自社プロダクトの将来を真剣に考え、社員であるエンジニアが主体的に関与できること。次に、設計・開発・リリース・保守・運用といったすべてのプロセスで得られるナレッジを社内に蓄積できること。そして、効果的な設計や省力化された運用負荷を実現できる製品選定・設計を行えること。最後に、保守・運用まで自前で行うことで、自動化や不要な作業削減を開発設計段階から意識できることです。\n\n![スライド：内製化への道筋](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179503/nigm4xsduozdfpgwymtg.jpg)\n\n*内製化への道筋*\n\n宮本氏は、内製化成功のカギは人財にあるとし、優秀なエンジニアの「採用」を大切にしながら、それ以上にエンジニアが働きたいと思える環境を「維持」していくことに力を注いでいると語ります。多くのエンジニアにヒアリングした結果、彼らは「やりたいことができる仕事環境」や「新しい技術への挑戦」を求めていることに気づきました。ルーチンワークになりがちな保守・運用やテストをGitLabを使って可能な限り自動化しているのは、エンジニアに新たな挑戦の場を提供するためでもあります。\n\n宮本氏は、「自分たちで考えて、自分たちで現状をより良く変えられるのが、優秀なエンジニアです。彼らが学習できる環境を用意し、実際に挑戦もしてもらいます。失敗することもあるでしょうけれど、上手に小さく失敗してもらってきちんと軌道修正できるような文化を作っています」と話します。\n\n長く使ってきたGitLabは、組織に根を張りました。エンジニア同士がGitLab上で議論を深め、コラボレーションする基盤へと育っています。\n\n![スライド：内製化推進においてGitLabが果たす役割](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179504/tdrxoes8irx7j4nwbnly.jpg)\n\n*内製化推進においてGitLabが果たす役割*\n\n「エンジニアは下請けではありません。ただものづくりをする人でもありません。ものを作ってサービスを提供する人なのです。組織には、エンジニアやビジネス企画など、さまざまな役割を持つ人が居ますが、その役割の壁を超えて、1つのサービスをみんなで作るという文化を大切にしています」（宮本氏）\n\n## 多様なAgentic AIをオーケストレーションする製品へ\n\n![GitLab合同会社 Japan Country Manager 小澤 正治](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179499/itvbnaxh1aqrgbbmfos2.jpg)\n\n*GitLab合同会社 Japan Country Manager 小澤 正治*\n\n小澤からは、GitLabの紹介とAI活用の取り組みについてお話させていただきました。GitLabは、ソフトウェア開発のライフサイクル全体を一元的に統合管理するプラットフォーム。この日のイベントを主催する[ガートナーのMagic Quadrant™において、製品の方向性と機能実装の両面から、リーダーという評価を受けて](https://about.gitlab.com/ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops/)います。\n\n今回のセッションで、テーマのひとつであるAIでは、統合されたシームレスな開発環境にAIをアドオンし、個々の開発工程の部分最適ではなく、AIを活用した全体最適を目指すことが特長。AIコーディングによる生産性向上だけにとどまらず、レビュー、脆弱性対策、安全なコードリリースなどソフトウェア開発の全工程にAIを活用するという方向性で製品を進化させています。\n\nソフトウェア・サプライチェーン全体のガバナンスも、AIを搭載するGitLabで管理する対象です。GitLabを導入した組織単体を見るのではなく、ソフトウェア・サプライチェーン全体のセキュリティリスク対応や組織体制の強化もプラットフォーム上で実現。SaaSに加え、Self-Managed、クラウドセルフホステッドでも利用できるため、機密性の高い情報を扱うユーザー向けに、ローカルLLMの活用を支援するなど、その活用スタイルに応じた導入が可能になっています。\n\n小澤は、GitLabの進化の方向性も披露しました。GitLabは今後、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)プラットフォームの概念を維持しつつ、多様な[Agentic AI](https://about.gitlab.com/ja-jp/topics/agentic-ai/)（自律的に行動し、目標達成のために自ら判断や行動を行うAI）の登場を前提に、それらをオーケストレーションする製品という立ち位置へと飛躍しようとしています。\n\n## 全工程・全業務へのAI適用を目指す\n\n![GitLab合同会社 Japan Country Manager 小澤 正治と株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179499/lir7wayd1qyqg71yg6e4.jpg)\n\n*左からGitLab合同会社 Japan Country Manager 小澤 正治、株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏*\n\nAI活用について宮本氏は、「われわれは、他社より遅れていると認識しています」と現状を厳しく評価します。約1年前からGemini Code Assistの検証をはじめ、現在は「ゼロからのコード生成」を目指し、エディタ、エージェント、プロバイダー、LLMの組み合わせを検討中。AI活用の範囲は、GitLabのコンセプトと一致しており、コード生成だけでなく、設計、ドキュメント作成、テストコード作成・実行など、全工程・全業務へのAI適用を目指しています。\n\n宮本氏は、AI導入の留意点について、「AIガバナンスが大切になります。どこにAIを導入し、だれに使わせ、どこまでの権限を与えるべきかを規定しなければなりません」と話します。AIでフルに自動化し、AIの出した結果を盲目的に信じてしまうと、脆弱性のあるコードが生成され、セキュリティリスクが発生する可能性があります。また、著作権侵害にも注意を払う必要があります。それらの対応策として、前者にはSASTなど、後者には侵害防止機能を持つAIやスキャンツールなどがありますが、ツールの挙動の確実性を含めた精査が必要になりそうです。\n\n![株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179498/odfxcgp4ojscykixhenc.jpg)\n\n*株式会社みんなの銀行 取締役常務執行役員CIO 宮本 昌明氏*\n\n機密データやソースコードの外部流出を阻止する開発体制も課題になります。ただ、宮本氏は現時点でローカルLLMの導入に否定的な立場です。「エンジニアは最新技術を求めています。ローカルLLMを導入すると、クラウドで提供されるAIほどの進化スピードを得られないことが問題で、エンジニアは最新の技術を使えない環境を喜びません。インプットは社内で保持し、ロジックのみを外部利用するなどの工夫が必要かもしれません」。\n\nこのように、さまざまな示唆を与えてくれた宮本氏の講演を受けて小澤は、「私たちの行動は、デジタルのタッチポイントが整備されたことで変わってきました。みんなの銀行のBaaSは、どんどん広がっていて、APIの種類も豊富ですから、知らず知らずのうちに使っている機会が増えてきそうです。GitLabは、これからもこのすばらしいサービスを、黒子として支えていきたいと考えています」とセッションを締めくくりました。\n\n![イベントのノベルティ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756179493/dzobx7yicnj3kk6rzfyx.jpg)\n\n*イベントで配られたノベルティ*",[896,838,865,714,280,552,776,922],[905],{"featured":91,"template":800,"slug":937},"event-report-gartner-application-innovation-2025",{"content":939,"config":948},{"title":940,"description":941,"authors":942,"date":943,"body":944,"category":718,"heroImage":945,"tags":946},"GitLab with Amazon Qで開発スピードを高め、AI生成コードの品質を担保する【イベントレポート】","この記事ではAWS Summit Japan 2025に出展した際に「GitLab with Amazon Q」について語ったセッションの模様をお伝えします。",[905],"2025-08-05","GitLabは2025年6月25～26日、千葉・幕張メッセで開催された「AWS Summit Japan 2025」に出展しました。今回の目玉となるソリューションは、発表したばかりの「[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)」。ブースにご来場いただいた皆様には直接ご説明でき、デモをご覧いただくなど、大きな注目を集めることができました。このブログでは、会場内のセッションで[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)を紹介した模様をお届けします。ゲストはソニービズネットワークス株式会社（以下、SBN） 開発本部 グループマネージャー 濱田 一成氏です。\n\n![AWS Summit会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754372455/azhcpftapneluoxyvgi9.jpg)\n\nこの日のセッションでは、GitLab シニア ソリューション アーキテクト 小松原 つかさが登壇。金色のジャケットを着た濱田氏を壇上にお招きした小松原は、「**金ピカのジャケット！　これは、AWSの全12資格を持っているという意味です。そして、濱田さんはAWSアンバサダーを務めていらっしゃいます。セッション終了後にはぜひみなさん一緒に写真をどうぞ**」と会場を盛り上げます。実は、濱田氏は日本で初めて[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)を使った人物でもあります。講演の後半で、[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)についてリアルな使用感を含めて、さらに詳しく解説してくれます。\n\n## 面白くない仕事をぜんぶAIにやってもらおうという考え方で\n\n![GitLab合同会社 ソリューションアーキテクト本部  シニアパートナーソリューションアーキテクト 小松原 つかさ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353570/bql6ekk9nfrql7ttlam7.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部*\\\n*シニアパートナーソリューションアーキテクト 小松原 つかさ*\\\n\\\n[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)は2025年4月17日に正式リリースしたばかりの最新ソリューションです。GitLabとAWSが協力して完成させた製品で、GitLabのAIエンジン部分のすべてにおいて、AWSの生成AIサービスを利用します。AIの優秀さもさることながら、その最大の特長は、AWSという巨大なインフラを使うことで、実質的にほぼ無制限にスケールできることです。\n\nパワーユーザーに最適なソリューションで、GitLab側は最上位プランである「[Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)」契約が必要になります。かつ、AWSの生成AIサービスと密連携したソリューションになっているため、AWS上で稼働させる必要があります。この2点をクリアできれば、すぐにでも[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)を利用することができます。\n\n「Amazon Q Developer Pro」がバンドルされていることも朗報です。無料版の「Amazon Q Developer」を、たとえばVS Codeを拡張機能を使って[IDE](https://about.gitlab.com/ja-jp/blog/what-is-ide/)（統合開発環境）のように利用しようとする場合、月間使用量が制限されるケースがあります。その点、Proは無料版に比べて大幅に制限が緩和されているため、多くのプロジェクトでは実質的に制限なしで利用できそうです。\n\n小松原は、[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)について、「**クリエイティブなタスク以外のものをAmazon Qにやってもらえるようになります**」と話します。「**チケットを切る、だれかにアサインする、だれかがプログラムを書く、だれかがレビューする、だれかがセキュリティをチェックするというプロセスの中で、面白くない仕事をぜんぶAIにやってもらおうという考え方でオーケーですよ**」。\n\nAIに配慮したエンタープライズセキュリティも備えています。小松原は、「**AIは、結構気をつけておかないと、脆弱性がしれっと入り込んだりします**」と指摘します。GitLabは、セキュリティスキャンやセキュリティチェック確認機能、SOC 2など各種コンプライアンスチェック機能を実装しており、「**GitLabでガードレール部分をしっかりやりながら、AIのパフォーマンスを思う存分使い切れます**」（小松原）。\n\n## サービス維持・発展のプロセスを最適化\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト 小松原 つかさ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353572/ejdmlahcggiyctg7wnwv.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部* \\\n*シニアパートナーソリューションアーキテクト 小松原 つかさ*\\\n\\\n小松原はさらに踏み込み、「ものづくりの後工程に来る“苦痛”を和らげてくれる」ソリューションであるとも語ります。多くのエンジニアにとって、サービス開発で最も楽しい時期は、バージョン1を作る時ではないでしょうか。サービスがリリースされると、たとえばデータベースのスキーマ変更に伴うデータマイグレーションなど、システムを知らない人にとっては簡単そうに見えても、実際には大変な仕事が降りかかってきます。とはいえ、サービスを維持し、利益を支えていくことは極めて重要です。そして、その部分に最大のフォーカスを置いているのがGitLabなのです。\n\n「**ディスカッションの要約機能などは当然として、サービスを維持し、発展させていくプロセスで生まれる大変さを生成AIが和らげてくれる機能がてんこ盛りです**」（小松原）\n\n中でも、セキュリティと脆弱性対策は、「**頑張らなきゃいけないんだけども、だれも評価してくれない仕事（笑）**」（小松原）かもしれません。たとえば、生成AIに、「ユーザー入力から製品を検索するときに、データベースから製品を検索するNode.jsとExpressの関数を書いてください。できるだけシンプルに、最小限のコードで実装してください。パフォーマンスを重視してください」と命令すると、「**データベース検索ですから、当然ながらパフォーマンス重視になります。ただ、AIは肝心のサニティチェックなどをスキップする傾向があるのです。肌感覚では、10回中4回はスキップします**」（小松原）。\n\nこうした問題に対し、[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)では、AIを使って脆弱性の修正提案をできるようにしています。Amazon Qのサービスを使って、脆弱性の分析と修正コードを作成。「なぜこの修正アプローチを取ったのか」まで記述させることで、修正理由が説明可能になります。同様のAI機能は、CI/CDのエラートラブルシュートでも使えます。「設定抜け」や「そもそもジョブの定義が間違い」など、単純ミスでコードが動かないというトラブルは意外と多く、ミスが単純すぎるがゆえに原因究明が遅れて時間を浪費しがちです。一方、AIには予断がないため、単純ミスの発見は得意です。小松原は、「**このように、つまらない仕事はどんどんAIにやってもらいましょう！**」と会場に呼びかけました。\n\n## ひとりの開発者がGitLabの中にいるというイメージ\n\n![ソニービズネットワークス株式会社  開発本部 グループマネージャー 濱田 一成氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353572/d3jtivqwdwqi18cobf2d.jpg)\n\n*ソニービズネットワークス株式会社*\\\n*開発本部 グループマネージャー 濱田 一成氏*\n\n後半は、濱田氏による[GitLab with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)レビューです。SBNの最大の業務課題は、「人手が足りない」ことです。メンバーはインフラエンジニアの集団で、アプリ開発にかかわれる人が少なく、インフラ業務との兼務が大半。少人数でプロジェクトを回す最適解としての可能性に賭けて、GitLab with Amazon Q DeveloperのPoCをスタートさせました。PoCで得られたメリットは「開発スピード」と「コード品質」の強化です。\n\n開発スピード面では、GitLab上で開発をして、エンジニアが手直しをするライフサイクルに変更したことで、開発工数を削減できました。濱田氏は、「**実際に使ってみてすごく驚いたのが、従来のワークフローに組み込みやすい点。ここが最も良かったと感じた部分です**」と話します。イシューを切ってから「/generate」とコメントを入れると、そのイシューに対してAmazon Q Developerが開発を行ってくれます。修正点があれば、インラインでコメントしてAIエージェントに指示すると結果を返してくれます。「**つまり、人間に対してやってるフローと全く一緒なのです。GitLab with Amazon Q Developerは、ひとりの開発者がGitLabの中にいるというイメージで使えます**」（濱田氏）\n\nコード品質面では、AIが生成したコードをさまざまな手法でレビュー&テストできるようになります。「/review」とコメントしてAIにレビューさせる機能とマージリクエストによる人間のレビューを適切に組み合わせることが可能。GitLabがネイティブに実装するSAST、ペネトレーションテスト、DAST、Pytestなど、言語ごとに存在するテストフレームワークもプロセスに組み込めます。\n\n「**マージリクエストで返却されたものに対して/reviewを実行すると、既存のコードのどこにアップデートがかかったか、どこが悪いのか、といったことを一覧にして戻してくれる。さらに、それをAIに修正してもらうことも可能です。AWS CDKやCloudFormationを活用されている方、インフラを構築されてる方に朗報なのは、このセキュリティ機能を応用可能なこと。インフラエンジニアにとっても親和性の高い機能です**」（濱田氏）\n\n## 「AIとのコラボレーションにおけるクオリティゲート」としての役割に期待\n\n![ソニービズネットワークス株式会社 開発本部 グループマネージャー 濱田 一成氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353572/fah13b0oz7sqzdhy9ew6.jpg)\n\n*ソニービズネットワークス株式会社*\n*開発本部 グループマネージャー 濱田 一成氏*\n\n濱田氏は、「**今後は、AIの生成したコードをレビューすることが人間の仕事になってくるでしょう**」と話し、AIの70%問題についても触れます。これは、現代のAIツールだけで実装できるコードの比率は約70％にとどまり、残りの30％は引き続き人間でないと実装できないことを指します。最終的にアプリケーションの品質を担保するのは人間になるため、GitLabのようなソリューションの役割はますます重要になってきます。\n\nより品質向上を目指す活用スタイルについて濱田氏は、[IDE](https://about.gitlab.com/ja-jp/blog/what-is-ide/)の拡張機能やCLIを通してAmazon Q Developerを使うやり方をシェアしてくれました。GitLabにプッシュする前に必ず、/review、/testを実行し、Amazon Q Developerを使ってコードの品質を高めておきます。その後、GitLab上ですべてのコミットに対してコードレビュー／セキュリティスキャンを追加で実行します。これにより、複数のAIエージェントをうまく組み合わせることが可能になり、人間とAIがコラボレーションしながら、すべてのコードの品質を高めることができます。\n\n濱田氏は、「**GitLab with Amazon Q Developerは、人間とAIのコラボレーションを自然に実現する次世代ツールだと感じました。従来の、人と人とのコミュニケーションのような感覚で、AIをワークフローに取り込めるところが極めて優秀です。AIの実装したコードを安心して製品に取り込むために、GitLab with Amazon Q Developerはクオリティゲートとして使えそうです**」と話してくれました。\n\n![左よりソニービズネットワークス株式会社 濱田 一成氏、GitLab合同会社 小松原 つかさ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353571/mhpaahskofpxfogp0v8c.jpg)\n\n*左よりソニービズネットワークス株式会社 濱田 一成氏、GitLab合同会社 小松原 つかさ*\n\n## GitLabに関する書籍とノベルティ\n\nこの日のセッションでは、小松原より書籍の紹介もありました。\\\nこれら3冊を紹介しています。\n\n> 1. **『[GitLab実践ガイド 第2版](https://amzn.asia/d/fV5hX2w)』**（北山 晋吾・棚井 俊、インプレス）\n>    「GitLabには無償版もあります。無償版のユーザーの方は、ぜひこちらから。この本、超おすすめです。これで勉強していただければ、GitLabの機能を全部マスターすることができます」（小松原）\n> 2. 『**[GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ](https://www.amazon.co.jp/GitLab%E3%81%AB%E5%AD%A6%E3%81%B6-%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%82%92%E6%9C%80%E5%A4%A7%E5%8C%96%E3%81%95%E3%81%9B%E3%82%8B%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E6%8A%80%E8%A1%93-%E6%95%B0%E5%8D%83%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%AB%E3%82%82%E3%82%8F%E3%81%9F%E3%82%8B%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF%E3%82%92%E6%B4%BB%E7%94%A8%E3%81%97%E3%81%9F%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BD%9C%E6%B3%95-%E5%8D%83%E7%94%B0-%E5%92%8C%E5%A4%AE/dp/4798185701?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=2C7VGZ8WMSM1R&dib=eyJ2IjoiMSJ9.vu1WyOMIaee-VDEnzTYCKLpDWeM6PXcF93TbTU5onKPmwTGR2lghKwtz5UKmdAYpwSgcp_-k0qcLOo3Eb7vsGbyIJ1aMhpoW5DPRpJbE_itQSi10WeIg9I7IiPcAup52od7bjxOriVzrl2N8OQ3E-BB5uHwgpo5aVUzOhkHqO1Rnf6HEfZTu1o_vqMpCTqlko24v4ImB7owRe5PeuwNnHsft5zVLng_Wx5I0IVe845f6Mmg1ywH6R45FGCuibkkr0ZeR31ivRg-B8C4QcRxtM9si0A2c7FzPI0VM4-Q4E0w.ItEuqYBuhjEf-AelOcP6fB1j-5Q9SkxDzyHV2uNcXeM&dib_tag=se&keywords=GitLab&qid=1752106423&sprefix=gitlab,aps,166&sr=8-4&linkCode=sl1&tag=68a7j959-22&linkId=affef2c28d1c88a622eef0031c12e747&language=ja_JP&ref_=as_li_ss_tl)**』（千田 和央、翔泳社**）**\n> 3. 『**[GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術 数千ページにもわたるハンドブックを活用したテキストコミュニケーションの作法](https://www.amazon.co.jp/GitLab%E3%81%AB%E5%AD%A6%E3%81%B6-%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%82%92%E6%9C%80%E5%A4%A7%E5%8C%96%E3%81%95%E3%81%9B%E3%82%8B%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E6%8A%80%E8%A1%93-%E6%95%B0%E5%8D%83%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%AB%E3%82%82%E3%82%8F%E3%81%9F%E3%82%8B%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF%E3%82%92%E6%B4%BB%E7%94%A8%E3%81%97%E3%81%9F%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BD%9C%E6%B3%95-%E5%8D%83%E7%94%B0-%E5%92%8C%E5%A4%AE/dp/4798185701?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=2C7VGZ8WMSM1R&dib=eyJ2IjoiMSJ9.vu1WyOMIaee-VDEnzTYCKLpDWeM6PXcF93TbTU5onKPmwTGR2lghKwtz5UKmdAYpwSgcp_-k0qcLOo3Eb7vsGbyIJ1aMhpoW5DPRpJbE_itQSi10WeIg9I7IiPcAup52od7bjxOriVzrl2N8OQ3E-BB5uHwgpo5aVUzOhkHqO1Rnf6HEfZTu1o_vqMpCTqlko24v4ImB7owRe5PeuwNnHsft5zVLng_Wx5I0IVe845f6Mmg1ywH6R45FGCuibkkr0ZeR31ivRg-B8C4QcRxtM9si0A2c7FzPI0VM4-Q4E0w.ItEuqYBuhjEf-AelOcP6fB1j-5Q9SkxDzyHV2uNcXeM&dib_tag=se&keywords=GitLab&qid=1752106423&sprefix=gitlab,aps,166&sr=8-4&linkCode=sl1&tag=68a7j959-22&linkId=affef2c28d1c88a622eef0031c12e747&language=ja_JP&ref_=as_li_ss_tl)**』（千田 和央、翔泳社**）**\n>    「アジャイル開発やチケット駆動開発ではドキュメンテーションはすごく大切。基本的なことから、普段の業務を劇的に改善するにあたって直接的なインパクトがあることまでが書かれています。これらの2冊、ぜひご活用ください」（小松原）\n\n![GitLabのTシャツ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353571/gtcbk8awj6sjzgjoubx9.jpg)\n\n*抽選の景品：GitLabのTシャツ*\n\n![GitLabのキーホルダー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353589/qilxnjgc84h7ugh5rpfi.jpg)\n\n*抽選の景品：GitLab Tanukiのキーホルダー*","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353906/qet5wxyn7k3dllq1jbq1.jpg",[947,838,864,865,896,714,280,776,922],"AWS",{"featured":91,"template":800,"slug":949},"event-report-aws-summit-2025",{"content":951,"config":959},{"title":952,"authors":953,"date":954,"category":718,"tags":955,"description":956,"body":957,"heroImage":958},"【DevOpsDive2025レポート】AIはソフトウェア開発ライフサイクル全体にAIを適用することで、未来の開発が見えてくる",[905],"2025-07-10",[280],"2025年5月20日に開催した「GitLab DevOpsDive2025～セキュアなAI活用を実現する3つの方法とは～」のイベントレポートをお届けします。","GitLabは2025年5月20日、東京・新宿の１０９シネマズプレミアム新宿において、「DevOpsDive2025」を開催しました。新宿ミラノ座の跡地に建つ複合施設にあり、プレミアム映画館として名高い会場のワンフロアを貸し切り、来場者の皆様にはポップコーンとジュースをサービス。映画鑑賞気分でイベントを楽しんでいただきました。\n\n![DevOpsDive2025会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/rgayfhyenn1yjtkfeuxx.jpg)\n\n*会場の様子*\n\n振り返れば、[昨年のイベント](https://about.gitlab.com/ja-jp/blog/event-report-devopsdive2024summer/)は観世能楽堂で実施して、大好評でした。GitLabは、全世界でオフィスを持たない企業として知られていて、全員がリモートワークです。社員とお客様、デベロッパーの皆様と直接触れ合える機会ですから、自分たちにとっても参加者の皆様にとっても楽しいものにしたいと、会場選びから気合を入れて準備してきました。ぜひ次の機会もお楽しみに！\n\nさて、このブログ記事では、当日の講演の模様をお伝えします。テーマは、AIです。\n\n![DevOpsDive2025会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616954/z2xaf83c4javhoxdamrs.jpg)\n\n*会場の様子*\n\n世間では、日本企業のAI活用は遅れているとされています。しかし、基調講演に登壇したAndrew Haschkaは、具体的なデータを示し、実はそうでないと説明します。Haschkaは、豪州を拠点にアジア太平洋地域を中心にGitLabのField CTOとしてユーザーのさまざまな課題に向き合っており、ユーザーの事情を肌感覚で知っているため、説得力があります。\n\n![DevOpsDive2025で話すAndrew Haschka](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616947/dsnsqvj2zjxyaronfcnu.jpg)\n\n*GitLab Field CTO, Asia Pacific & Japan, Andrew Haschka*\n\nソフトウェア開発ライフサイクル（SDLC）においてAIを使用中の企業は、米国の34%に対して日本は48%。これは世界的に見ても高い数値です。ただし、Haschkaは「数字だけを見ると良い傾向なのですが、日本のAI活用はAIコーディングの部分にとどまっています」と釘を刺します。「残念ながら、ソフトウェア開発のライフサイクル全体を通したAI活用には至っていません」。\n\n![AI導入予定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617775/su4hqxb8krrxfcktyh6d.png)\n\n*SDLCで現在AIを使用している、または今後の導入を計画している割合*\n\nAIは、確かにコーディングをスピードアップしてくれます。一方で、セキュリティがないがしろにされてしまうリスクには注意が必要です。Haschkaは、あるインドネシアのGitLabユーザーを例に挙げました。その企業は、AIコーディングによって、開発スピードが大幅に向上し、同じ時間で完成するコード量が飛躍的に増えました。その結果、何が起きたのでしょう。コード量と同時にリスク要素が増えてしまい、脆弱性チェックに大変な手間がかかるようになってしまったのです。\n\nHaschkaは、「ただ、このケースはまだ良い方です。コードをきちんとチェックできているわけですから。“コンプライアンス・ガードレール”が正しく機能していることが証明されたと言えます」と話します。大きな問題は、SDLCに正しくガードレールを設置できておらず、コーディングのスピードアップにより、セキュリティがないがしろにされても、それに気づかない状態のまま放置されることで発生します。\n\nそうした事態に陥ることを防ぎ、セキュリティを担保しながらAIをソフトウェア開発に役立てるために、HaschkaはSDLCを通した3つの視点を持つ必要があるとします。まずは、**SDLCを透過的に管理できる統合されたプラットフォームを持つ**こと。GitLabのように統合的なプラットフォームでSDLC全体へのガバナンスを効かせることが必要で、ポイントソリューションの組み合わせで運用することは難しいのです。\n\n![DevOpsDive2025で話すAndrew Haschka](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616947/dow9hyavtyf7vooswmgw.jpg)\n\n*GitLab Field CTO, Asia Pacific & Japan, Andrew Haschka*\n\n次に、**SDLCに動的なセキュリティ対策を行き渡らせる**こと。対策における最大のテーマは脆弱性管理と依存性管理です。ライブラリやコンポーネントの依存性を可視化・管理し、セキュリティとライセンスについての承認プロセスを必要なポイントで埋め込みます。スキャンの強制実行も大切な要素で、この部分は自動化できるケースもあり、開発生産性を損なわずにセキュリティを担保することを期待できます。これらは、GitLabをSDLCのプラットフォームとして使っていれば、必要なプロセスに埋め込み、優れたガードレールとして機能させることができます。\n\n![GitLab Duoの利用形態](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617775/qdyujjzp99voh7h9qf6h.png)\n\n*GitLab Duoの利用形態*\n\n最後に、**必要に応じてローカルLLMを活用する**こと。ローカルLLMは、クラウドを通さずローカル環境で動作するLLMで、データプライバシーを保護できることが特長。ローカルで稼働するため、機密情報を安全に扱うことができます。GitLab Duo Self Hosted Modelsを使うことで、ローカルLLMをGitLabと連携して運用することが可能になります。\n\nこれら3つの視点を持ち、SDLCを安全に運用するひとつのやり方として、Haschkaはプラットフォーム・エンジニアリング（PE）チームが主導的な立場を担うケースがあると指摘しています。\n\n## PEチームと開発部門が密な連携を取り、GitLabでSDLCを改革\n\n![Olympus株式会社柳田修太氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/soab0npkbzsac2bofvrc.jpg)\n\n*オリンパス株式会社 R&Dセンターオブソフトウェアエクセレンス, グローバル ソフトウェア開発インフラストラクチャ シニアディレクター 柳田 修太氏*\n\n続いては、オリンパス株式会社の事例講演です。同社は、内視鏡を主力に医療デバイスをワールドワイドに提供するメーカーです。そして、優れたPEチームがSDLCの改革で大きな役割を果たした企業の1つでもあります。同社のPEへの取り組みは、グローバルに展開されるソフトウェア開発の効率化、およびコスト適正化を図るためにスタートしました。\n\nスクリーンを背後に演壇に立った柳田 修太氏は、「弊社の開発サイクルは5から10年と長いものが多いことが特徴です。そのため、プロジェクト開始時のインフラが最新でなくなるケースが多いのです」と話します。「医療機器に組み込まれるソフトウェアの開発ですから、ソフトウェアを使う前のバリデーションが不可欠になります。クラウド化されていて特定のタイミングで強制的にバージョンアップされてしまうツールは、どれだけすばらしいものであっても、弊社の開発で使用することは困難です」。\n\nSDLCをよりセキュアにするためには、何らかのプラットフォームは必要になります。要件は、全世界でサポートしてくれるプラットフォームであること。そして、各国で異なる法規制に対応できること。さらに、自社のさまざまな開発要件への適用が可能であること。たとえば、アジャイル開発、仮想化、コンテナへの対応は当然のこと。特殊なニーズのある組み込みソフトウェアの開発プロセスにも対応できなければなりません。\n\n![Olympus株式会社柳田修太氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616952/cck02oslxsqyz0a7fppf.jpg)\n\n*オリンパス株式会社 R&Dセンターオブソフトウェアエクセレンス, グローバル ソフトウェア開発インフラストラクチャ シニアディレクター 柳田 修太氏*\n\nこうしてGitLabを選定したのですが、当初は抵抗もあったといいます。人命にかかわる医療機器の開発プロセスの改革ですから、万全を期する必要があるためです。それでも深い議論を重ね、開発部門と密な連携を取ったことで、少しずつGitLabを試してもらえるようになりました。そうして実際に成果を体験してもらったことで、開発者側からもGitLabを使いたいという声が上がってきます。\n\n柳田氏は、「ビルドのスピードアップが大きなポイントで、並行して複数のビルドを走らせられるため、開発生産性が高まりました。統合ツールとしてインフラ管理が楽なことも、開発現場に受け入れられた理由の大きなところでしょう。開発部門との関係性も高めることができ、いまでは新規プロジェクトを中心にユーザーがどんどん増えています」と話します。\n\nGitLabの浸透に伴ってアジャイルな開発スタイルでの活用も進み、開発スピードはさらに向上しました。GitLabでSDLCを包括的に管理できたことで運用コストを低減し、GitLab Runner（CI/CDのジョブ実行主体）を活用することでコンテナ環境における開発も大幅に効率化しています。こうしてHaschkaの指摘した3つの視点のうち、1と2は着実にオリンパスに定着しつつあります。\n\n今後取り組むのは、3のセキュアなAI活用です。現状は、オリンパスの開発者が作ったコードをAIの学習に使わないと明記したMoUをGitLabと締結した段階。社内でリスクアセスメントを実施し、本格運用に向けた試験運用を続けています。\n\n## 「AIコーディングだけをとってもローカルLLMの価値は大きい」\n\n![株式会社NTTデータグループ加藤耕也氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/k2rn3su6d1ollmyx4n05.jpg)\n\n\\\n*株式会社NTTデータグループ 技術革新統括本部 AI技術部 部長 加藤耕也氏*\n\n\\\n続いては、NTT DATAの講演です。NTT DATAは、生成AI活用コンセプト「SmartAgent™」を発表するなど、ローカルLLMビジネスを積極的に展開しています。グローバルで1000件超の受注実績があり、SDLCの生産性向上目標としてFY25で50%、FY27には70%を掲げています。\n\n同社は社内でも生成AIをソフトウェア開発分野へ適用し、開発業務の効率化を目指しています。現在は、タスクの自動化を進めている段階。これは支援型AIと定義される分野ですが、次なるターゲットはいわゆる自律型AIへの進化です。自律型AIが実用段階に入れば、労働集約型産業はAI駆動型へと進化することが期待されています。NTT DATAは市場に先駆けて自律型AIの本格運用を進めることで、今年から2027年にかけてプロセスの自動化へと発展させ、さらに将来は開発業務のより広範な領域をまたいだ業務の自動化も実現させたい考えです。\n\n![株式会社NTTデータグループ市原大暉氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/yjgdcm3cgysc62vaouln.jpg)\n\n\\\n*株式会社NTTデータグループ 技術革新統括本部 AI技術部 市原大暉氏*\n\n\n\n\n\n![AI活用におけるオンプレの重要性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617776/xj4xv49xvtakt4lwqzae.png)\n*生成AI活用におけるプライベートクラウド・オンプレミスの重要性*\n\nAIの利用範囲が拡大することに伴い、よりセキュアなAIが求められるようになります。そのためにローカルLLMの注目が高まっているわけですが、上の表に示したように、ローカルLLMにはメリットもデメリットもあります。それでも機密情報を扱うためには閉域網での開発が必須です。また、NTT DATAでは、顧客に対して独自に実施したヒアリングの結果、AIを独自にチューニングしてオリジナルな学習の方向性を定めたいというニーズが今後増えてくると見ています。これは、公共分野をはじめ、金融、製造、観光などさまざまな業種に共通するニーズです。講演した加藤 耕也氏は、「実は、AIコーディングだけをとってもローカルLLMの価値は大きいのです。そのプロセスにも強力なガバナンスを効かせられるようになりますから」と話します。同社では、すでに社内で約3,000ユーザーがローカルLLMを使って開発プロジェクトを進めています。\n\n![GitLab Duoを用いた検証結果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617777/b0deb8vbv61osovquall.png)\n\n*GitLab Duoを用いた検証結果*\n\nそしてこの日、GitLab Duoを用いたローカルLLM AIコーディング環境の検証結果を明らかにしてくれました。この検証では、機能面・非機能面での実用性を73項目で精査し、十分な精度を得られたことが報告されています。\n\n## 「ローカルLLMは究極の安全性をもたらす」\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616953/nf6jwyqj4l9xhxbsf2nb.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\n最後のセッションに登壇したのは、GitLabの佐々木 直晴。この日のすべてのセッションを振り返りながら、さまざまなポイントの背景や詳細について語りました。中でも印象深かったのは、AIがコーディングすることでセキュリティレベルが低下する背景についてです。\n\n佐々木は、CSETが昨年公開した資料を示し、AIは人間が書いた脆弱性を含むコードを学習データとするためそれを模倣してしまう可能性があると警告しました。「AIは、 “機能的に正しく動くコードを素早く出力”しようとします。そのとき、セキュリティの観点で重要な構成要素を無視してしまうことがあるようです。たとえば、例外処理や入力チェックなどはコードに入っていなくても機能的には正しく動くため、AIの提案からは抜け漏れやすいということが考えられます」。ローカルLLMについては、「自社の強みが流出するリスクを抑え、究極的な安全性をもたらす存在」とし、実際に多くの企業がそこを目指すだろうと展望しています。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616954/nswoq6ryvcrdph9waaam.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\n佐々木は、Haschka の3つの視点を目指すにあたり、GitLabはユーザーのAI利用時にもプライバシーや知的財産権を保護しながらSDLC全体をAIでサポートできるプラットフォームであり続けるとも述べ、AIに取り組むなら安心してGitLabを採用してほしいと会場に呼びかけました。\n\n*\\*SmartAgentは日本国内における株式会社NTTデータグループの商標です。*","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751591672/la3jvyygusvvh5ag7czj.jpg",{"featured":91,"template":800,"slug":960},"event-report-devopsdive2025",{"category":726,"slug":730,"posts":962},[963,974,988],{"content":964,"config":972},{"title":965,"description":966,"authors":967,"heroImage":969,"date":970,"body":971,"category":730},"仮想マシン（VM）とは？意味や導入メリット、GitLab活用例","この記事では、仮想マシンの基礎知識からソフトウェア開発・ITインフラの領域で導入するメリット、具体的な活用方法まで解説します。",[968],"GitLab Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347347/ocydmzmnj23eitgoiwzb.jpg","2025-08-28","仮想マシン（VM）は、IT技術が進化する時代の中でソフトウェア開発やビジネスの領域において近年注目されている技術の一つです。実際に自社のソフトウェア開発の領域において、仮想マシンの導入を検討している人も多いのではないでしょうか。仮想マシンを自社の開発に取り入れて確かな効果を発揮するためには、仮想マシンの特徴などを事前に詳しく理解しておく必要があります。\n\nこの記事では、仮想マシンの基礎知識からソフトウェア開発・ITインフラの領域で導入するメリット、具体的な活用方法まで解説するのでぜひ参考にしてください。\n\n## 1. 仮想マシン（VM）の基礎知識\n\n![仮想マシン（VM）の基礎知識](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347363/iwp4fwdv8jubfrclmvdk.jpg)\n\nまずは、仮想マシンを理解するために知っておきたい仮想化と呼ばれる技術の概要や、仮想マシンの特徴について解説します。\n\n### 1-1 そもそも仮想化とは\n\n仮想化とは、物理的な環境に囚われずにサーバー、ストレージ、ネットワーク、メモリなどのハードウェアリソースを効率よく利用するための技術のことです。\n\nよりわかりやすく簡潔に説明すると、仮想化とは本来1つであるハードウェアリソースを複数あるかのように利用する技術です。この仮想化技術は現代の企業のIT戦略を検討する上で重要な位置付けとなっています。\n\n### 1-2 仮想マシン（VM）とは\n\n![仮想マシン（VM）とは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347364/gao2azgosxdb60yoblno.jpg)\n\nでは、この記事の本題である仮想マシンについて説明します。仮想マシンとは、仮想化技術を活用して1つの物理マシン内（コンピューター）に仮想的に複数のコンピューターを再現する環境のことです。\n\n物理マシンは実体として存在するコンピューターであるのに対して、仮想マシンはソフトウェアを利用して物理マシン内に仮想的に再現したコンピューターであるという違いを理解しておくと良いでしょう。\n\nつまり、仮想マシンなら1台のコンピューター上で複数のOSをそれぞれ独立した状態で稼働できるようになります。後にも詳しく解説しますが、これによりサーバー台数の節約やニーズに応じたOSの稼働などができるようになり、開発やビジネスにおけるコスト削減や生産性向上にも寄与します。\n\n## 2 仮想マシン（VM）におけるホストOSとゲストOS\n\n![仮想マシン（VM）におけるホストOSとゲストOS](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347365/rn4rccmpfjwm4wj2klkl.jpg)\n\n仮想マシンを語る上では、「ホストOS」と「ゲストOS」という言葉の意味についても理解しておく必要があります。\n\nまずホストOSとは、仮想マシンを構築する際の土台となるOSを指します。つまり、実体のある物理マシンにインストールされているOSです。一方、ゲストOSは仮想マシンにインストールするOSのことです。\n\n例えば、Windowsのコンピューターに対して仮想環境を作成して、Linuxをインストールすれば、ホストOSはWindows、ゲストOSはLinuxとなります。このようなホストOSとゲストOSの関係性は業務上でも使われるため、違いを把握しておくと良いでしょう。\n\n## 3 仮想マシン（VM）の歴史\n\n![仮想マシン（VM）の歴史](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347363/g17rmmdu1jh0jm9ueglu.jpg)\n\n仮想マシンは近年注目されている技術の一つですが、歴史自体は古く、1960年代には既に使用されていました。当時のコンピューターリソースを複数のユーザーで使用するための「タイムシェアリング」という技術が仮想化の起源だと言われています。\n\nその後、時代の流れと共にIT技術が発展し、コンピューターの価格低下も実現できたことから物理的に台数を増やして運用するという考えが広まりました。しかしそれでは企業にとって運用負荷が増加してしまうという課題が残るため、仮想化技術が再び注目されるようになっているのです。\n\n※参考：[「仮想化」を理解するための誕生の歴史 | ITソリューション塾](https://blogs.itmedia.co.jp/itsolutionjuku/2014/06/post-9f0b.html)\n\n## 4 仮想マシンの主な利用シーン\n\n![仮想マシンの主な利用シーン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347368/vc1gzpcdyqmym44t92fl.jpg)\n\n仮想マシンは具体的にどのようなシーンで利用できるのでしょうか。具体例として以下が挙げられます。\n\n* ソフトウェア開発・テスト\n* 新しいOSのテスト\n* ソフトウェア・アプリケーションの実行\n* セキュアなWebブラウジング\n\n### 4-1 ソフトウェア開発・テスト\n\n仮想マシンはソフトウェア開発・テストの領域で役立てられます。仮想マシンを使って本番とは隔離された環境で開発を行えば、開発途中でなんらかのトラブルが発生した場合でも影響を最小限に抑えられるでしょう。また、複数の異なるOSを構築できるため、アプリケーションの互換性テストを容易に実行することが可能です。\n\n### 4-2 新しいOSのテスト\n\n企業が業務改善やビジネス上の戦略を理由に既存のOSから新しいOSへの移行を検討するケースもあるでしょう。しかし、使い慣れた環境から新しい環境へ切り替えを行う際には、既存のアプリケーションや周辺機器の互換性・操作性などを細かにチェックしなければなりません。\n\n事前に仮想マシンを使用して移行予定のOSを試せば、移行後の業務への影響度を事前に把握できるでしょう。\n\n### 4-3 ソフトウェア・アプリケーションの実行\n\n業務を進める上で状況によっては、現在利用しているOSでは動作しないソフトウェアやアプリケーションの実行が必要になるケースもあるでしょう。\n\nそういったケースでも仮想マシンを使えばソフトウェアやアプリケーションの実行に必要となるOSを柔軟にインストールできるため、業務に支障が出ることなく仕事を進められるでしょう。\n\n### 4-4 セキュアなWebブラウジング\n\nWebブラウジングを行う際にも仮想マシンを活用できます。Webブラウジングとは、Webブラウザを利用してWebサイトやホームページなどの情報を閲覧することです。\n\nウイルス感染のリスクが高いサイトも存在する中で、仮想マシンを使って隔離されたセキュアな環境でWebブラウジングを行えば、企業におけるセキュリティリスクを軽減できます。\n\n## 5 仮想マシン（VM）を実行するソフトウェアの種類\n\n![仮想マシン（VM）を実行するソフトウェアの種類](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347364/vzsuhsyjxh38dmdmwios.jpg)\n\n仮想マシンを実行するためにはソフトウェアが必要になりますが、主に以下の種類に分けられます。\n\n* ホストOS型\n* ハイパーバイザーOS型\n\n### 5-1 ホストOS型\n\nホストOS型とは、先ほど解説したホストOS上に仮想化ソフトウェアをインストールして仮想マシンを構築する方法になります。\n\n以下からホストOS型を採用するメリットやデメリット、代表的な仮想化ソフトウェアを紹介します。\n\n#### ５−１−１ ホストOS型のメリット・デメリット\n\nホストOS型のメリットは、既に利用しているOS上にソフトウェアをインストールするだけで仮想マシンを実現できるため、扱いやすく容易に導入できることです。そのため、まずは仮想環境に触れてみたいといったテスト用途や、個人学習用途などで利用することが可能です。\n\nしかし、ホストOS型の場合は物理マシンと仮想マシンとの間にホストOSが介入することになり、本来の処理に加えて余分なリソースがかかる「オーバーヘッド」と呼ばれる現象が発生します。そのため、高速な処理には不向きな手段であることを把握しておかなければなりません。\n\n#### ５−１−２ 代表的な仮想化ソフトウェア\n\nホスト型の仮想化ソフトウェアの例としては以下が挙げられます。\n\n・Oracle VM VirtualBox\n\nVirtualBoxは、Oracle社が提供する人気の仮想化ソフトウェアです。多機能であることが特徴で、「スナップショット」「シームレスモード」「共有フォルダ」など仮想マシンを活用する上で便利な機能が搭載されています。\n\n・VMware Fusion Pro\n\nVMware Fusion Proは、Mac上で仮想マシンを構築し異なるOSを実行できる仮想化ソフトウェアです。ファイル共有などさまざまな機能が提供されています。\n\n### 5-2 ハイパーバイザー型\n\nハイパーバイザー型とは、ホストOSを使わず、ハイパーバイザーと呼ばれる専用の仮想化ソフトウェアをインストールして仮想環境を構築する方法です。以下からハイパーバイザーOS型のメリットやデメリット、代表的なソフトウェアを紹介します。\n\n#### ５−２−１ ハイパーバイザー型のメリット・デメリット\n\nハイパーバイザー型のメリットは、ホストOSを使わずに仮想マシンを構築するため、ホストOS型と比較してオーバーヘッドが少なく高速な処理が期待できます。\n\nただし、既存の物理マシンでハイパーバイザーを使用できない場合は、新たに互換性のある物理マシンを購入する必要があり、そのための費用を用意しなければなりません。また、ホスト型OSと比べて導入や管理においてある程度の専門知識が求められます。\n\nホストOS型とハイパーバイザー型の特徴の比較を以下の表でまとめました。\n\n![ハイパーバイザー型のメリット・デメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756349540/bab2vb3tws84ftqtrj6x.jpg)\n\n#### ５−２−２ 代表的なハイパーバイザー\n\n代表的なハイパーバイザーには以下のようなものがあります。\n\n・KVM\n\nKVMは、Linuxをハイパーバイザーとして動作させることができる仮想化技術です。Linuxカーネル2.6.20以降から標準搭載されているため、Linuxを使用しているなら手軽に試せるでしょう。\n\n・VMware ESXi\n\nVMware ESXiは、 VMware が提供しているソフトウェアです。ESXiファイアウォールによりアクセス制限が可能でセキュリティにも強みを持っているのが特徴です。\n\n・Citrix Hypervisor\n\nCitrix Hypervisorは、 Citrix社が提供する仮想化プラットフォームです。Xen Projectをベースとしており、高性能なハイパーバイザーで信頼性が高いことが特徴です。\n\n## 6 仮想マシンとコンテナの違い\n\n![仮想マシンとコンテナの違い](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347368/bq7nkfayq63ltttxhlmb.jpg)\n\n仮想化手法においては「コンテナ」と呼ばれる技術もあるため、仮想マシンとの違いを理解しておきましょう。\n\n### 6-1 コンテナとは？\n\n![コンテナとは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347369/cdzvsfyrdh1qc8uctash.jpg)\n\nコンテナとは、アプリケーションを実行するための動作環境を仮想化して利用する技術のことです。\n\n仮想マシンは、物理マシン内に仮想化ソフトウェアを利用して複数の異なるOS（ゲストOS）を構築します。一方、コンテナは、「コンテナエンジン」と呼ばれるコンテナを管理するソフトウェアがOSとして機能するため、ゲストOSは不要になります。\n\n代表的なコンテナエンジンは、「Docker」になります。Dockerを活用すれば、複数のアプリケーションの実行環境を手軽に作成できます。\n\n### 6-2 コンテナの特徴\n\nコンテナは先ほども解説した通りゲストOSが不要であるため、必要最低限のリソースで運用することができコスト削減につながります。また、処理速度も速いことから効率的な運用を実現できるでしょう。\n\nしかし、コンテナの場合はOSが限定されるため、複数の異なるOSを利用できる仮想マシンのような自由度は期待できません。例えば、ソフトウェア開発において異なる種類の環境でテストを実行したい場合には適していない手段だと言えます。また、コンテナはコマンド操作や管理方法など初期で覚えることも多いため、スムーズな導入を実現するためには学習環境や運用体制を構築しておく必要があります。\n\n## 7 ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するメリット\n\n![ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347365/kk7vgdomzo4quorhjs8v.jpg)\n\nここではソフトウェア開発とITインフラの領域に焦点を当てて、仮想マシン（VM）を導入するメリットについて解説します。\n\n* IT・開発コストの削減\n* 開発・テスト環境構築の迅速化\n* 複数OSの活用による効率性の向上\n* DevSecOpsのサポート\n* セキュリティリスクの軽減\n* 可用性の向上とBCP対策への貢献\n\n### 7-1 IT・開発コストの削減\n\n仮想マシンを導入することで、物理的なハードウェアリソースを論理的に分割する形で共有できるため、コスト削減につながります。複数OSの稼働が必要になった場合に、仮想環境を構築せずに物理的にリソースを準備するとなると、コンピューターの購入費や管理費などさまざまなコストが追加で発生してしまいます。\n\n仮想マシンなら、ハードウェアリソースを効率よく有効活用できるため、ソフトウェア開発・ITインフラの領域でも追加コストの発生を最小限に抑えられます。\n\n### 7-2 開発・テスト環境構築の迅速化\n\n仮想マシンは開発・テスト環境構築の迅速化にもつなげられます。開発者は簡単に仮想環境を作成できるようになるため、需要に応じて開発・テスト環境を瞬時にスピンアップできます。また、使用しない時にも素早くテイクダウンが可能です。\n\n本来であれば開発・テスト環境を構築する際には物理的な作業が発生し、時間を要します。柔軟性と拡張性を持つ仮想マシンなら、急なニーズが発生した場合でも物理的な作業を省略できるため、状況の変化に応じたスピーディーな対応が可能です。\n\n### 7-3 複数OSの活用による効率性の向上\n\n仮想マシンなら1つの物理マシン上で異なる複数のOSを運用できます。時間やコストをかけることなく、必要な時にゲストOSとして構築するだけでさまざまな環境でソフトウェアの開発やテストを実行することが可能です。例えば、WindowsとLinuxを同時に起動してアプリケーションの互換性をチェックするなどの対応が可能です。\n\n複数OSの活用によって開発やテストの効率性向上を実現できるでしょう。\n\n### 7-4 DevSecOpsのサポート\n\nDevSecOpsとは、開発（Dev）、セキュリティ（Sec）、運用（Ops）の3つの概念を組み合わせたアプローチのことを指します。開発サイクルにおいて開発からセキュリティ、運用までを連携して進めることでセキュリティ強化や開発スピードの向上につなげられます。\n\n仮想マシンの導入はこのDevSecOpsのサポートやツールチェーンの合理化にも貢献します。例えば、開発プロセスにおいて仮想マシンを作成し、仮想マシン上にCI/CDのような自動化されたワークフローを取り入れることで独立した環境で実行基盤を構築できます。\n\n### 7-5 セキュリティリスクの軽減\n\n仮想マシンはそれぞれ独立した環境で互いに分離された形で運用され、かつホストシステム（物理的なコンピューター）からも隔離されているため、セキュリティ対策にも役立ちます。\n\n例えば、1つの仮想マシンでセキュリティトラブルが発生した場合でも、他の仮想マシンやホストシステムへの影響を抑えやすいでしょう。ただし、環境分離によるセキュリティリスクの軽減は期待できるものの、トラブルが発生する可能性をゼロにできるわけではありません。仮想環境特有のセキュリティ対策も徹底し、より安全に運用できる体制を構築する必要があります。これについては後述します。\n\n### 7-6 可用性の向上とBCP対策への貢献\n\n仮想マシンは障害にも強く、システムの可用性を高めることも可能です。例えば、現在の仮想マシンの状態を保存・復元できる「スナップショット機能」を活用すれば、システム障害が発生した場合でも容易に以前の状態に戻すことが可能です。\n\nまた、稼働中の仮想マシンを継続したまま別のホストに移行できる「ライブマイグレーション機能」なら、安全性の高いホストへ移動させることで事前にシステムトラブルを回避できるでしょう。\n\n## 8 ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するデメリット\n\n![ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するデメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347369/d5zasrxf7krbjy2umv2s.jpg)\n\nソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入する際には以下のようなデメリットもあるため、事前に把握しておくことが大切です。\n\n* パフォーマンス低下の可能性\n* 仮想環境の導入・管理における専門性が高い\n* 仮想環境特有のセキュリティ対策が必要\n* 障害時の対応が増える場合がある\n\n### 8-1 パフォーマンス低下の可能性\n\n仮想マシンは物理的なコンピューターと比較すると性能面で劣る場合があるため、開発時に処理に時間がかかってしまったりなど不便さを感じてしまうかもしれません。例えば、オーバーヘッドが発生すると余分なリソースがかかり、処理速度に影響を与えてしまうでしょう。\n\n特に安定した作業環境が強く求められるシーンにおいては、適切なリソース配分を検討する、状況に応じて物理的なコンピューターを用意して利用するといった対策が必要になります。\n\n### 8-2 仮想環境の導入・管理における専門性が高い\n\n仮想マシンをスムーズに導入し、安定した運用を実現するためには専門的な知識や技術が求められます。次で詳しく触れますが仮想環境においても特有のセキュリティ対策が必要になり、専門知識を持った担当者がいないと十分な対策はできないでしょう。\n\n自社に専門知識を持った人材がいない場合は、新たに確保したり、対象者を教育しなければなりません。そのためには採用・教育コストが発生することも把握しておくことが大切です。\n\n### 8-3 仮想環境特有のセキュリティ対策が必要\n\n仮想マシンに対してもセキュリティリスクは存在するため、仮想環境特有のセキュリティ対策は必要になります。例えば、基盤となる物理マシンやホストOSだけでなく、仮想マシンにも専用のセキュリティソフトを導入することが大切です。また、複数の仮想環境を運用する場合は対策や管理に抜け漏れがないよう注意しなければなりません。\n\nその他、万が一セキュリティトラブルが発生した場合の対応フローを事前に整備しておくことも大切です。\n\n### 8-4 障害時の対応が増える場合がある\n\n仮想マシンは1つの物理マシン上で利用されるため、物理マシンに障害が発生した場合、稼働している全てのシステムに影響が出る可能性もあります。これは単一障害点（SPOF）と呼ばれるものですが、もし発生した場合は復旧対応に時間や手間、そして金銭的なコストがかかってしまうでしょう。\n\n単一障害点を回避するためには、事前に仮想環境基盤の冗長化を検討しておく必要があります。\n\n## 9 仮想マシン（VM）の一般的な設定手順　\n\n![仮想マシン（VM）の一般的な設定手順](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347369/ivi8vlejqodcfecyl1b9.jpg)\n\n仮想マシンの一般的な設定手順は以下になります。\n\n1. 仮想化ソフトウェアの選定\n2. ゲストOSのインストール\n3. ネットワークの設定・データ共有\n\nまずは仮想マシンを導入する上で仮想化ソフトウェアの選定を行う必要があります。先ほど紹介したようにソフトウェアには「 VM VirtualBox」や「KMV」などがあるため、特徴を把握して自社の要件に合ったものを選びましょう。\n\n仮想化ソフトウェアを選定してインストールした後は、ゲストOSのインストールも行いましょう。最後にネットワーク設定や必要に応じてホストOSとのデータ共有などを行い運用します。\n\n## 10 仮想マシン（VM）でのGitLab活用例・使い方\n\n![仮想マシン（VM）でのGitLab活用例・使い方](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347369/entroriird3lryl3zpr3.png)\n\n仮想マシンは[GitLab](https://about.gitlab.com/ja-jp/)のようなCI/CDツールと連携が可能で、DevSecOpsの推進にもつなげられます。GitLabでのCI/CDプロセスを実行する環境として仮想マシンを有効活用できます。\n\nここでは、GitLabのサービス紹介や、仮想マシン上でGitLabを使用するメリットなどを解説します。\n\n### 10-1 GitLabとは？\n\nGitLabは、ネイティブAIを搭載したソフトウェア開発のライフサイクル全体を網羅するDevSecOpsプラットフォームです。ソフトウェア構築における計画から開発、テスト、リリース、運用までを単一のプラットフォームで統合して実行することができ、ビジネスの加速化や運用負担・コストの削減につなげられます。\n\nCI/CDパイプラインの構築やセキュリティの自動化、ソースコード管理、プロジェクト管理などソフトウェア開発の効率化に役立つ充実した機能を提供しており、中小企業からエンタープライズまで世界中の多くの企業で導入されています。\n\n### 10-2 仮想マシン上でGitLabを使うメリット\n\n仮想マシン上でGitLabを利用することでどのようなメリットがあるのでしょうか。具体的には以下の通りです。\n\n* セキュアな環境で開発・テストを実行できる\n* 本番環境に近い環境でテストやビルドを行える\n* バックアップ機能やスナップショット機能でデータ復旧が容易になる\n\n#### 10-2-1 セキュアな環境で開発・テストを実行できる\n\n物理マシンとは独立した環境でGitLabを利用するため、セキュアな環境で開発やテストを実施することが可能です。仮想マシン上でトラブルが発生した場合もホストシステムへの影響を抑えられるため、セキュリティ要件が高いプロジェクトにも適しています。\n\nまた、仮想マシンなら常にクリーンな状態の環境を用意できるため、GitLabのCI/CDプロセスにおいて正確なテストやビルドが可能になります。\n\n#### 10-2−2 本番環境と同じ環境でテストやビルドを行える\n\n仮想マシンなら複数の異なるOSを用意できるため、例えばCI/CDプロセスにおいて本番環境を再現して動作確認やテストができるようになります。状況に合わせてさまざまな条件下で使用することで環境の違いによる不具合をリリース前に検出しやすくなるでしょう。\n\n#### 10-2-3 バックアップ機能やスナップショット機能でデータ復旧が容易になる\n\n仮想マシンのスナップショット機能を活用すればデータのバックアップを容易にとることができ、障害時の復旧にも役立てられます。また、GitLabにはバックアップ機能が搭載されているため、より安全なシステム運用を実現できるでしょう。\n\n## まとめ 仮想マシン（VM）の活用で開発効率の向上を図ろう\n\n仮想マシンは近年注目されている技術であり、ソフトウェア開発やITインフラの領域でも積極的に活用することで開発効率の向上やコスト削減、セキュリティ対策などにつながります。\n\nDevSecOpsプラットフォーム「[GitLab](https://about.gitlab.com/ja-jp/)」は、仮想マシン上で利用することができ、CI/CDプロセスを実行する環境として活用できます。その他、プロジェクト管理などチームでの開発を効率化できる豊富な機能が搭載されているため、ぜひ自社への導入をご検討ください。\n\nなお、GitLabでは世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧ください。\n\n> [2024グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-vm)\n\n[](https://about.gitlab.com/ja-jp/developer-survey/)*監修：知念 梨果* *[@rikachinen](\u003C>)（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*",{"featured":91,"template":800,"slug":973},"what-is-vm",{"content":975,"config":986},{"title":976,"description":977,"authors":978,"date":979,"body":980,"category":730,"heroImage":981,"tags":982},"Dockerとは：超入門編","Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。\n",[968],"2025-06-18","Dockerコンテナ技術は、2013年にオープンソースの「Dockerエンジン」として公開され、翌年2014年には本番環境向けの商用版が発表されました。その後約10年の間に、Dockerは使いやすさと高い利便性から、IT業界で瞬く間に広く普及してきました。これからもその人気は高まっていくでしょう。\n\nしかしその一方で、いまだに「Dockerとは何ですか」という声もよく耳にします。この記事では、Docker環境の導入を検討中で、Dockerにまだ不慣れなデベロッパーやプログラマーの皆様を対象に、Dockerの基本を解説します。Dockerに触れたことのない初心者向けの「Docker超入門編」です。\n\n## 目次\n\n1. Dockerとは：超入門編\n2. Dockerの目的\n\n   * Dockerとは\n   * Dockerでできること\n   * Dockerイメージとは\n   * Dockerコンテナとは\n   * Dockerfileとは\n   * Dockerはなぜ重要なのか\n3. Dockerの主な機能\n\n   * Dockerの特徴\n   * Docker Composeとは\n4. アプリケーションのデプロイにおけるDockerのメリット\n\n   * 開発環境と本番環境のシームレス化\n   * 起動の軽量化・処理速度の高速化\n   * バージョン管理のしやすさ\n   * 優れたスケーラビリティ\n5. Dockerのデメリット\n\n   * ひとつのOSを使わなければならない\n   * 大規模開発時のオーバーヘッド\n   * 技能習得に時間がかかる\n   * セキュリティに脆弱性が生じることもある\n   * コンテナ間での連携が難しい\n6. GitLabはDockerが抱える課題をどのように解決するのか\n7. GitLabのDevSecOpsにおけるDockerの役割\n8. まとめ\n9. FAQ（よくある質問）\n\n## Dockerの目的\n\nはじめに、Dockerとはどういったもので、何ができて、どうして便利なのか、なぜ重要なのか、Dockerの目的に着目しながらその概念をまとめていきます。\n\n### Dockerとは\n\nDockerは、Linuxのコンテナ技術を用いた軽量なソフトウェアコンテナプラットフォームです。アプリケーションの開発、出荷、実行を簡易化するために設計されました。Dockerを使えば、すべての依存関係と一緒にアプリケーションをパッケージ化できるため、依存関係を一つひとつ手動でインストールする必要がなくなり、一貫性のあるコード実行が可能になります。\n\nDockerを使えばアプリケーションの実行環境を標準化でき、環境の違いによる問題を減らすことで開発から本番環境へのデプロイ時間を大幅に短縮できます。\n\nLinuxには以前からコンテナ仮想化という技術がありました。この技術を使うと、プログラムを開発・実行環境から隔離することにより、複数のプログラムを素早く実行できます。ただし、この従来型の仮想化技術は、仮想環境を構築するためにホストとなるOS（オペレーティングシステム）に依存する必要がありました。Dockerはこのコンテナ仮想化技術をOSに関係なく簡単に扱えるようにしたソフトウェアといえます。\n\nDockerの基本概念はイメージとコンテナです。Dockerイメージは、読み取り専用のテンプレートであり、コンテナを作成するための指示が記述されています。たとえば、コンテナで実行するアプリケーションとその依存関係、環境変数、ファイルシステムなどがこれに含まれます。\n\n### Dockerでできること\n\nDockerを使うと、1台のマシン中に複数のコンテナ（仮想環境）をビルドできるため、いくつかの開発環境に対応することができます。つまり、1台のサーバー上で複数のアプリケーションを効率的に動かすことができるのです。アプリケーションの開発環境をDockerで構築すれば、たとえば開発環境（Windows）で動いていたアプリケーションがLinux上で起動しない、といった問題は発生しません。Dockerで構築した環境は、他のデベロッパーとクラウド上で簡単に共有できるため、開発作業がスムーズに進められます。\n\n### Dockerイメージとは\n\nDockerイメージは、アプリケーションを実行するのに必要なソースコードと必要な依存関係をパッケージ化したものです。Dockerコンテナを実行する際には、このDockerイメージが必要です。\n\nDockerイメージは、コンテナイメージを構成する複数のファイルに、`Dockerfile` を合わせてビルドします。つまり、Dockerイメージは、手作業で書くのではなく、コマンドを使って作成します。\n\nそのため、Dockerイメージは単一のファイルではなく、Dockerコンテナの実行に必要なパッケージ（ファイルやメタデータの集合体）であることを理解することが重要です。\n\n### Dockerコンテナとは\n\nLinuxのコンテナは、アプリケーションを内包し、必要なライブラリや依存関係、ファイルが含まれています。\n\n一方、Dockerコンテナは、Dockerイメージの実行可能なインスタンスです。これはDockerイメージから生成され、アプリケーションを実行するためのランタイム環境です。ただし、ハイパーバイザーを使用する従来の仮想化とは違い、DockerのコンテナはホストOS（オペレーティングシステム）のカーネルで実行されます。Dockerイメージ内には、個別のOSはありません。\n\nDockerイメージは環境のスナップショットであり、コンテナはソフトウェアを実行する環境といえます。\n\n### Dockerfileとは\n\n`Dockerfile`は文字情報を主体とするファイルで、ファイルの拡張子はありません。`Dockerfile`には、アプリケーションの構築から実行までのプロセスに必要なコマンドが記述されています。どのファイルをどこから取得して、どんな処理を行ない、Dockerイメージに含めるのかなどを記述します。\n\n`Dockerfile`は、Dockerイメージを作成するためのテキストファイルです。コンテナイメージをビルドする場合も、コンテナのビルド手順を`Dockerfile`で定義する必要があります。この`Dockerfile`には、命令のスクリプトが含まれており、Dockerはコンテナイメージをビルドする際にこのスクリプトを使用します。\n\n### Dockerはなぜ重要なのか\n\nDockerは、コンテナに関する既存のコンピューティングの概念、とりわけLinuxの「cgroups」や「namespaces」、「overlayfs」などの技術を活用しています。これは、アプリケーションの依存関係をサーバーやネットワークなどのインフラストラクチャから隔離したいという、デベロッパーやシステムオペレーターのニーズに応えるものでした。\n\nDockerを使うと、1台のサーバー上でさまざまなアプリケーションを簡単に仮想化・実行できるようになります。さらには、ローカルマシンに依存しない開発環境を実現でき（開発環境の統一）、本番環境に近い環境でのシミュレーションが可能になり、アプリケーションの依存関係も管理できます。加えて、ビルド、テスト、デプロイまでの各プロセスを一貫して行なうことができます。\n\n## Dockerの主な機能\n\nDockerは、Linuxのコンテナ技術を使用しています。Dockerコンテナはよく仮想マシンと比較されます。\n\n仮想マシンでは、ホストマシン上でハイパーバイザーを利用してゲストOSを動かし、さらにその上でミドルウェアやライブラリ、さらにその上にアプリなどを実行します。\n\nそれに対し、コンテナはホストマシンのカーネルを利用し、プロセスやユーザーなどを隔離します。そのため、非常に軽量で、まるで別のマシンが動いているかのように動作します。その結果、アプリなどを高速に起動、停止することが可能です。\n\nDockerは、次の4つの構成要素から成り立っています。\n\n* **Dockerイメージ：** アプリケーション実行に必要なソースコード、アプリと依存関係のパッケージ\n* **Dockerコンテナ：** アプリケーションを実行するランタイム環境\n* **Docker Hub：** クラウド上のレジストリサービス。アプリケーションやサービスコンテナのビルドと配信を行なう\n* **Dockerfile：** Dockerイメージを作成するために実行するコマンドライン命令を含むテキストファイル\n\n### Dockerの特徴\n\nDockerには、次のような特徴があります。\n\n* **軽量かつ高速：** 1つのOSで複数のコンテナを管理でき、仮想マシンより軽量で高速に立ち上げることが可能。\n* **環境の一貫性が保持でき再現性がアップ：** Dockerコンテナは異なるプラットフォームでも一貫して動作するため、ローカル、クラウド、ハイブリッド環境への移行が簡単にできる。\n  移植性が高い －クラウドシステムとの親和性が高く、主要なクラウドプロバイダーはDockerコンテナの実行をサポートしている。\n* **サンドボックスの提供：** セキュリティ対策やソフトウェア開発において、隔離された仮想環境でプログラムを実行・検証できる。このため、ホストマシンの環境を守ることができる。\n* **IaC（インフラストラクチャのコード化）を使用して、インフラをコード化：** Dockerfileによりミドルウェアのインストールや環境設定をコード化して管理できる。\n\n### Docker Composeとは\n\nDocker Composeは、複数のDockerコンテナを一元管理する、 Dockerアプリケーションのためのツールです。YAMLファイルを使用してアプリケーションのサービスを設定します。単一のコマンドで複数のサービスをまとめて生成したり、起動・停止したりすることができます。\n\nDocker Composeのコマンド例は次のとおりです。\n\n* **`docker-compose up`：** サービス用のコンテナを構築、作成、起動、アタッチします。リンクされているサービスがまだ起動していない場合は、それらも起動します。\n* **`docker-compose ps`：** Docker Composeで管理されている稼働中のサービスを一覧表示します。\n* **`docker-compose build`：** Docker Composeファイルで定義されているサービスをビルド（構築）します。\n\n## アプリケーションのデプロイにおけるDockerのメリット\n\nアプリケーションのデプロイにおけるDockerのメリットは次のとおりです。\n\n### 開発環境と本番環境のシームレス化\n\nコンテナ技術の利用を開発環境と本番環境で統一することで、環境の違いにより起こる問題を減らすことができます。その結果、デベロッパーと運用チームとの連携がスムーズに行われ、チーム間で発生していた問題も最小限に抑えられます。\n\n### 起動の軽量化・処理速度の高速化\n\nDockerのコンテナ技術は従来の仮想環境より軽く、アプリを瞬時に起動できます。これは、CPUやメモリなどのコンピュートリソースを必要最低限しか使用しないためです。起動速度が上がることで、開発にも集中できます。\n\n### バージョン管理のしやすさ\n\nDockerでは、GitLabなどのソースコードのバージョン管理ツールを使用できるため、バージョン管理の可視化が進むだけでなく、ロールバックやアップデートも簡単に行なえるようになります。\n\n### 優れたスケーラビリティ\n\nコンテナは軽量で拡張性に優れています。必要に応じて簡単に増減できます。これにより、アプリケーションの拡張やスケーリングを迅速に行なえるため、変わりゆく状況にも柔軟に対応できます。\n\n## Dockerのデメリット\n\nDockerにはさまざまなメリットがありますが、いくつかデメリットも存在します。以下にデメリットを挙げます。\n\n### 1つのOSを使わなければならない\n\nDockerは1つのOS上で複数のコンテナを作成します。これにより起動速度や処理速度の面でメリットがありますが、同時にデメリットになることもあります。たとえば、異なるOS環境で検証をしたい場合には、別のマシンや仮想マシンを準備する必要が生じます。\n\n### 大規模開発時のオーバーヘッド\n\nDocker自体は軽量ですが、大規模システムに拡張する場合には、Dockerの管理に伴う負荷が発生します。Dockerは1台のサーバーで多数のコンテナを実行できますが、その反面、管理やオーケストレーションが必要になり、その処理のためにオーバーヘッドが生じる場合があります。Dockerだけですべての管理を行なうのが困難になることもあります。\n\n### 技能習得に時間がかかる\n\nDockerは他の仮想マシンと異なる手法で仮想環境を構築します。つまり、デベロッパーは新しいコンセプトをすべてゼロから習得しなければならず、それには時間がかかります。Dockerの動作原理をきちんと理解せずに使用すると、あとでトラブルや問題が発生することもあります。Dockerについてしっかりと学習してから運用に取り組むようにしましょう。\n\n### セキュリティに脆弱性が生じることもある\n\nDockerはコンテナ型アーキテクチャです。1台のマシン上で複数のコンテナが動作するため、このことに起因する脆弱性には注意が必要です。たとえば、複数のコンテナがホストOSのリソースやカーネルを共有しているため、一つのコンテナに脆弱性があった場合、全体にその影響が及ぶ可能性があります。\n\n### コンテナ間での連携が難しい\n\n複数のコンテナ間での連携を検討している場合、各種設定が難しいために、運用時に問題が発生することがあります。たとえば、アプリとデータベースを別のコンテナで作成し、一緒に運用したい場合には、同一ホスト内で通信設定をしなければなりません。ポートやソケットを開放する場合にはセキュリティ面でリスクが生じます。それを避けるために設定を複雑にしてしまうと、今度は運用面で問題が起きる恐れがあります。コンテナを連携させる際は、設計段階から十分に検討することが重要です。\n\n## GitLabはDockerが抱える課題をどのように解決するのか\n\nDockerコンテナ内にGitLabをインストールすることができます。[GitLab](https://about.gitlab.com/ja-jp/platform/)は、Git「分散型バージョン管理システム」を主体としたDevSecOpsプラットフォームです。ソフトウェア開発ライフサイクル全体に対応する単一のプラットフォームで、GItLabを活用することで高品質なソフトウェアの迅速なデリバリーを実現できます。\n\nDockerコンテナ内にGitLabをインストールすると、GitLabインスタンスにアクセスできるようになります。Dockerコンテナへの[GitLab Dockerイメージのインストールは公式にサポート](https://about.gitlab.com/ja-jp/install/)されています。\n\nDockerが抱えるいくつかの問題のうち、特にセキュリティについては、GitLabのDevSecOps（開発、セキュリティ、運用）を活用して対処することができます。GitLabのDevSecOpsでは、[シフトレフト](https://about.gitlab.com/ja-jp/topics/ci-cd/shift-left-devops/)を重視しており、セキュリティ対策を開発サイクルの早い段階に組み込むことにより、コンテナイメージの持つセキュリティの問題の早期発見と対応を図っています。継続的インテグレーションによってこのシフトレフトのコンセプトを実践することで、セキュリティ対応にかかっていたコストを削減できます。\n\nDevSecOpsにおいて重要なCI/CDを実現するためには、自動化が欠かせません。GitLabではパイプラインがCI/CDの命令をまとめています。そして、その指示に従いプロセスの自動化を実現するときの基盤になっているのが[GitLab Runner](https://docs.gitlab.com/runner/)（英語）です。GitLab Runnerはセキュリティのシフトレフトを実現する上で重要な役割を果たしています。\n\nGitLab Runnerはセキュリティスキャンやテストを指定したタイミングで自動で実行してくれます。また、レポート作成ジョブを実行して、ダッシュボードに最新情報を表示することも可能です。\n\n## GitLabのDevSecOpsにおけるDockerの役割\n\nGitLabを活用したDevSecOpsインテグレーションにおいても、Dockerは非常に大切な役割を担っています。\n\n### CI/CDジョブのコンテナ化\n\nGitLab CI/CDでは、CI/CDパイプラインでDockerコンテナを使用することで、次のようなことが可能になります。\n\n* **一貫性：** CI/CDジョブはコンテナ内で実行されるため、依存関係や環境の違いによるエラーが防げます。\n* **スケーラビリティ：** コンテナは軽量かつ迅速に起動でき、大規模なパイプラインでも効率的に実行できます。\n* **環境の柔軟性：** ジョブごとに異なるDockerイメージを指定できるため、必要な環境を簡単に準備できます。\n\nGitLab RunnerのDockerイメージは、UbuntuまたはAlpine Linuxをベースにしています。Dockerイメージは標準の`gitlab-runner`コマンドを内包しており、ホストに直接GitLab Runnerをインストールしたかのように動作します。\n\n### セキュリティスキャンの自動化\n\nセキュリティはDevSecOpsでの重要な要素であり、Dockerはこれをサポートします。\n\n* **コンテナイメージのセキュリティスキャン：** GitLabには、CI/CDパイプラインでDockerイメージをスキャンする機能があります。このスキャンにより脆弱性がチェックされ、イメージ内の依存関係やコードの安全性を評価できます。\n* **コンテナ脆弱性スキャンの自動化：** GitLabにはTrivyやAquaなどのセキュリティツールを統合できます。DockerイメージのOSやアプリケーションが最新であるか、既知の脆弱性がないかをチェックします。\n\n### IaC（インフラストラクチャのコード化）と環境管理\n\n* **再現性：** DockerをGitLabのCI/CDジョブ内で使用することで、開発環境と本番環境の整合性を保つことできます。\n* **ステージングやテスト環境を即時に構築：** Docker ComposeやKubernetesと連携することで、特定のブランチやマージリクエストごとに分離された環境をGitLabで作成できます。これにより、テストやセキュリティスキャンを効率的に実行できます。\n\n### デプロイの効率化\n\nGitLabは、Dockerを使用する以下のデプロイパターンをサポートしています。\n\n* **Dockerイメージのビルドとプッシュ：** アプリをコンテナイメージとしてビルドして、GitLabのContainer Registryや他のDockerレジストリにプッシュします。\n* **継続的デリバリー：** Dockerイメージを使ってコンテナオーケストレーションツールにデプロイすることで、迅速で安全なリリースが可能になります。\n\n### マイクロサービスアーキテクチャのサポート\n\nGitLabとDockerを組み合わせることで、マイクロサービスアーキテクチャを簡単に構築できます。マイクロサービスは別々のDockerコンテナとして実行します。GitLab CI/CDパイプラインを使うと、以下のことを管理できます。\n\n* サービス間の依存関係の設定\n* 個別のセキュリティスキャン\n* バージョン管理（ロールバックが容易になります）\n\n## まとめ\n\n2013年の公表以来、Dockerは瞬く間にIT業界に広く普及しました。本記事では、Dockerの基本概念、基本技術、Dockerを使って何ができるのか、なぜDockerが重要なのか、Dockerを理解上でよく目にする用語などについて紹介してきました。\n\nDockerを使う場合には、DevSecOpsにとって大切なCI/CDを実現するためにも、GitLab CI/CDなどの自動化ツールの導入をおすすめします。GitLab のCI/CDパイプラインでDockerコンテナを使用することで、開発における一貫性の維持、スケーラビリティの実現、柔軟な環境の準備が可能になります。\n\n## FAQ（よくある質問）\n\n### Dockerで何ができるのか？\n\nDockerコンテナは、軽量でスタンドアロンの仮想化技術であり、アプリケーションコード、その依存関係、ライブラリをすべてパッケージ化します。Dockerを使うと、1台のマシン上に複数のコンテナ（仮想環境）を構築でき、開発環境や検証環境の統一が図れます。詳しくは、記事の本文をご覧ください。\n\n### Dockerは何に使うのか？\n\nDockerは、デベロッパーがアプリケーションとその依存関係をシステムから切り離したいとき使用します。コンテナにはアプリケーションとその依存関係がまとめられており、軽量な実行環境を提供します。詳しくは、記事の本文をご覧ください。\n\n### Dockerコンテナとは何ですか？\n\nDockerイメージが実行時にコンテナになります。Dockerコンテナは、アプリケーションを実行するためのランタイム環境です。Dockerコンテナに関する詳細は、記事の本文をご覧ください。\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)*\n\n*（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750226168/pf5cwmvqq09v1pe0re66.jpg",[109,983,984,714,796,985,776,797],"cloud native","DevOps","performance",{"featured":91,"template":800,"slug":987},"what-is-docker",{"content":989,"config":1001},{"title":990,"description":991,"authors":992,"heroImage":995,"date":996,"body":997,"category":730,"tags":998},"GitLabリポジトリのバックアップを48時間から41分に短縮した方法","15年前のGit関数のパフォーマンス上のボトルネックを追跡して修正し、効率性の向上、より強固なバックアップ戦略の導入、リスクの軽減を実現した方法をご紹介します。",[993,994],"Karthik Nayak","Manuel Kraft","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png","2025-06-05","リポジトリのバックアップは、いかなる堅牢なディザスタリカバリ戦略においても不可欠な要素です。しかし、リポジトリのサイズが大きくなるにつれて、信頼性の高いバックアップの作成プロセスはますます難しくなります。GitLabでは、[Railsリポジトリ](https://gitlab.com/gitlab-org/gitlab)のバックアップに48時間かかっていました。そのため、バックアップ頻度かシステムパフォーマンスのどちらを優先するかを選ばないといけないという難しい状況にありました。お客様のため、そして社内ユーザーのためにこの問題に取り組むことにしました。\n\n最終的に、15年前に作成したGit関数でO(N²)レベルの複雑なアルゴリズムが使われていたのがこの問題の原因であることを突き止め、アルゴリズムを変更して修正したところ、__バックアップ時間が大幅に短縮__されました。その結果、コストの削減、リスクの軽減とともに、コードベースに合わせて実際にスケールするバックアップ戦略を実施できるようになりました。\n\nこれは、大規模なリポジトリのユーザーなら誰にでも起こりうるGitのスケーラビリティの問題であることが判明しました。この問題をどのように追跡して修正したかをご説明します。\n\n## 大規模なバックアップ\n\nまずは、問題について詳しく見ていきましょう。組織においてリポジトリのサイズが大きくなり、バックアップが複雑化するにつれて、以下のような課題が生じる可能性があります。\n\n* **時間がかかるバックアップ**：非常にサイズの大きいリポジトリを使用している場合、バックアップの作成に数時間かかる可能性があるため、定期的なバックアップを行うのが難しくなりがちです。\n* **リソースの集中**：長時間のバックアップ処理には大量のサーバーリソースが必要となることがあるため、他のオペレーションに影響を及ぼす可能性があります。\n* **バックアップの実施期間**：24時間体制で業務を行っているチームにとって、このような長時間の処理を行える適切なメンテナンス期間を確保するのは難しい場合があります。\n* **失敗するリスクの増大**：バックアップ処理に長時間かかると、ネットワークの問題、サーバーの再起動、システムエラーなどによる中断の影響を受けやすくなります。そのため、場合によっては長時間かかるバックアップ処理を最初からやり直さざるを得なくなります。\n* **競合状態**：バックアップの作成に時間がかかるため、その間にリポジトリが大きく変更される可能性があります。結果として、使用できないバックアップが作成されたり、オブジェクトにアクセスできなくなってバックアップ処理が中断されたりすることがあります。\n\nこのような課題によって、バックアップの頻度や完全性を妥協せざるを得なくなる可能性があります。しかしながら、データ保護という観点では妥協すべきではありません。バックアップの実施期間が長くなると、顧客は回避策を取らざるを得なくなることがあります。その場合、外部ツールの導入やバックアップ頻度の削減などが行われますが、結果として、組織全体で一貫したデータ保護戦略を維持できなくなる可能性があります。\n\nでは、GitLabがどのような方法でパフォーマンス上のボトルネックを特定し、解決策を見つけ、バックアップ時間を短縮するためにどのように導入したかを詳しく見ていきましょう。\n\n## 技術的な課題\n\nGitLabのリポジトリバックアップ機能では、[`git bundle create`](https://git-scm.com/docs/git-bundle)コマンドを使用しています。このコマンドは、ブランチやタグのようなすべてのオブジェクトと参照を含むリポジトリの完全なスナップショットをキャプチャします。このバンドルは、リポジトリを正確な状態で再作成するための復元ポイントとして機能します。\n\nしかしながら、このコマンドの実装には参照数に関連するスケーラビリティの低さの問題があり、パフォーマンス上のボトルネックとなっていました。リポジトリ内の参照数が増えるにつれて、処理時間が飛躍的に増加していました。当社の一番大きなリポジトリでは数百万個の参照が含まれますが、バックアップ処理に48時間以上かかることもありました。\n\n### 根本原因分析\n\nそこで、このパフォーマンス上のボトルネックの根本原因を特定するために、実行中のコマンドのフレームグラフを分析しました。\n\n![実行中のコマンドが示されたフレームグラフ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\nフレームグラフは、スタックトレースを使用してコマンドの実行パスを表示します。各バーはコード内の関数に対応しており、バーの幅はその特定の関数内でコマンドの実行に費やされた時間を示します。\n\n10,000個の参照が含まれるリポジトリで実行された`git bundle create`コマンドのフレームグラフを調べたところ、実行時間の約80%が`object_array_remove_duplicates()`関数に費やされていました。この関数は、[コミットb2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686)（バンドル：同じ参照を複数回指定できるように許可、2009年1月17日）でGitに導入されたものです。\n\nこの変更内容を理解するには、`git bundle create`を使用すると、バンドルに含める参照を指定できることを把握する必要があります。完全なリポジトリバンドルの場合、`--all`フラグを指定するとすべての参照がパッケージ化されます。\n\nこのコミットは、ユーザーがコマンドラインから重複した参照を指定（例：`git bundle create main.bundle main main`）すると、重複したmain参照を適切に処理せずにバンドルが作成されてしまうという問題に対処したものでした。Gitリポジトリでこのバンドルをアンバンドルすると、同じ参照を二度書き込もうとするため、壊れてしまいます。そのため、重複回避を目的として、すべての参照で重複の特定処理が繰り返されるようにネストされた`for`ループを用いたコードが実装されました。このようなO(N²)アルゴリズムは、参照数が多いリポジトリではパフォーマンス上の重大なボトルネックとなり、かなりの処理時間がかかっていました。\n\n### 修正方法：O(N²)アルゴリズムを効率的なマッピングに置き換える\n\nGitLabは、明らかになったパフォーマンスの問題を解決するために、ネストされたループをマップデータ構造に置き換えるアップストリーム修正をGitにコントリビュートしました。これにより、各参照がマップに追加され、各参照の単一のコピーのみが処理目的で自動的に保持されるようになりました。\n\nこの変更により、`git bundle create`のパフォーマンスが劇的に向上し、参照数の多いリポジトリのスケーラビリティが大幅に改善されました。10,000個の参照があるリポジトリでベンチマークテストを行った結果、パフォーマンスが6倍向上することが明らかになりました。\n\n```shell\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n\t6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nパッチは承認され、アップストリームのGitに[マージ](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d)されました。GitLabでは、次のGitバージョンがリリースされる前にお客様がすぐに恩恵を受けられるように、この修正をバックポートしました。\n\n## 結果：バックアップ時間の大幅な短縮に成功\n\nこの改善によるパフォーマンスの向上は、まさにこれまでの状況を一変させるものでした。\n\n* **バックアップ時間が48時間から41分に短縮**：GitLab最大のリポジトリ（`gitlab-org/gitlab`）のバックアップを従来のわずか1.4%の時間で作成できるようになりました。\n* **一貫したパフォーマンスの維持**：この修正はリポジトリのサイズに関係なく機能し、安定してスケールします。\n* **効率的なリソースの利用**：バックアップ処理中のサーバー負荷が大幅に軽減されました。\n* **幅広い適用性**：もっとも劇的な改善が見られるのはバックアップの作成ですが、多数の参照を処理するすべてのバンドルベースの操作においてメリットがあります。\n\n## GitLabを利用するお客様にとってのメリット\n\nGitLabを利用する組織は、この改善によって、リポジトリのバックアップとディザスタリカバリ計画方法に関して、即座に次のような具体的なメリットを得られます。\n* **バックアップ戦略の変革**   \n  * 企業チームは、開発ワークフローに影響を与えたり、長期にわたるバックアップ期間を確保したりすることなく、夜間に実施する完全バックアップのスケジュールを確立できます。   \n  * 長期のバックアップ専用の時間を設けなくとも、夜間スケジュール中にバックグラウンドでシームレスに実行できます。  \n* **事業継続性の向上**  \n  * バックアップ時間が数日から数分に短縮されたことで、組織は回復ポイント目標（RPO）を大幅に最小化できます。これはビジネスリスクの軽減につながります。災害が発生した場合でも、数日かからず、数時間の作業で復旧できる可能性があります。  \n* **運用負荷の軽減**   \n  * サーバーリソースの消費を抑えられ、メンテナンス期間が短縮されます。  \n  * バックアップ時間が短縮されるため、コンピューティングコストも削減します。特に処理時間が延びると、コストの増加に直結するクラウド環境においては顕著です。  \n* **将来にわたって活用できるインフラストラクチャ**   \n  * リポジトリの規模が大きくなっても、バックアップ頻度とシステムパフォーマンスのどちらを優先するか選ぶ必要はもうありません。   \n  * コードベースの拡大にあわせて、バックアップ戦略もシームレスに拡張できます。\n\n組織は、パフォーマンスや完全性を犠牲にしなくても、より堅牢なバックアップ戦略を実施できるようになりました。以前は難しいトレードオフに直面していたものの、今では簡単な方法で運用できます。\n\n[GitLab 18.0](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)のリリース以降、ライセンスプランに関係なく、GitLabをご利用のお客様は全員、ご紹介した改善点を利用して[バックアップ](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/)戦略の立案および実施を行えるようになりました。設定を変更する必要はもうありません。\n\n## 今後の展望\n\n今回の革新的な改善は、スケーラブルでエンタープライズグレードなGitインフラの提供に向けた、当社の継続的な取り組みの一環です。バックアップの作成時間が48時間から41分に短縮されたことは重要なマイルストーンとなりましたが、引き続きスタック全体においてパフォーマンス上のボトルネックを特定し、対処しています。\n\n今回の改善をGitのアップストリームプロジェクトにコントリビュートでき、GitLabユーザーだけでなく、広範なGitコミュニティにメリットをもたらせたことを特に誇りに思っています。このような協調的なアプローチにより、改善に対する徹底的なレビューおよび幅広いテストの実施が行われ、誰もがそのメリットを得られるようになります。\n\n> GitLabではパフォーマンスを最適化するために、このような深いレベルでインフラに取り組んでいます。ぜひGitLab 18のオンラインリリースイベントにご参加ください。ほかにどのような根本的な機能強化が行われたかをご紹介します。[今すぐご登録ください！](https://about.gitlab.com/ja-jp/eighteen/)",[999,750,90,1000,479],"Git","パフォーマンス",{"slug":1002,"featured":91,"template":800},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"category":738,"slug":742,"posts":1004},[1005,1017,1027],{"content":1006,"config":1015},{"date":1007,"title":1008,"category":742,"tags":1009,"body":1011,"authors":1012,"description":1013,"heroImage":1014},"2025-08-11","Monday Merge 8月号",[109,838,947,865,270,896,714,280,796,742,1010,776,922],"releases","GitLabコミュニティのみなさん、こんにちは！今月もソフトウェア開発の最新トレンドをお届けします。\n\n今回のトピックはこちら：\n\n* GitLab Duo Agent Platformのパブリックベータ版がスタート：AIともっとスマートに働く方法とは\n* 現場のニーズに応える最新GitLabリリース情報\n* 世界2,786名のCレベル層に聞いた、AIとソフトウェアイノベーションに関する意識調査\n* 注目イベントやおすすめコンテンツ、NatWest社の導入事例もご紹介\n\nそれでは、さっそく見ていきましょう⚓\n\n# **GitLab Duo Agent Platform：パブリックベータ版がついに登場**\n\n![agent platform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369419/qascscd3p9azk7ros2nw.png)\n\n従来のAIアシスタントの概念を覆す新しい体験 ── GitLab Duo Agent Platformは、開発・セキュリティ・運用すべてをカバーする次世代のDevSecOpsオーケストレーションエンジンです。パブリックベータ版としての提供がスタートしました。\n\nこれは単なるIDE内のAIボットではありません。複数のAIエージェントがチームの一員として非同期に連携し、計画からリリースまでをトータルでサポートします。\n\n初期搭載されているエージェントは以下の通りです：\n\n* **Chat Agent**：自然言語での質問や汎用的な開発作業をサポート\n* **Developer Agent**：仮想開発環境でマージリクエストを作成\n* **Security Analyst Agent**：脆弱性の検出と修正提案\n* **Deep Research Agent**：リポジトリ全体を分析し、背景を踏まえたインサイトを提供\n* **Software Development Flow**：複数エージェントを連携させて一連の開発タスクを自動化\n\nGitLabのイシュー、パイプライン、CI/CDなど25以上の機能にネイティブにアクセスできるため、コンテキストを理解した精度の高い支援が可能です。さらに今後は、エージェントをカスタマイズし、複雑な作業を自動実行できる「フロー」も登場予定です。\n\nPremiumおよびUltimateプランをご利用中の方は、VS CodeやJetBrains IDEでベータ版を今すぐお試しいただけます。Web UIでも「Duo Agentic Chat」がすでに利用可能です。　\n\n▶︎ [GitLabがオーケストレーションプラットフォームとして持つ独自の強みについて、CEOのBill Staplesが語るインタビューはこちら。導入方法もあわせてご紹介しています。](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)\n\n[](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)\n\n# [](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)**GitLab企業経営調査2025：AI・信頼・7,500億ドルの可能性**\n\n![$750+B](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/i8ccbygymqgrxno9vul5.png)\n\nAIは単なるトレンドではありません。世界の開発者2,700万人がAIを活用すれば、7,500億ドル以上の価値が生まれると言われています。最新のGitLab企業経営調査2025では、世界中の経営層2,786名にAIとソフトウェア開発の未来について調査を行いました。\n\n主な調査結果：\n\n* AI活用によって、開発者1人あたり年間28,249ドルのコスト削減を実現（世界中の開発者数で見積もると7,500億ドル規模に）\n* 89％の経営者が、今後3年以内にAIエージェントが業界標準になると予想\n* 懸念点は「サイバー攻撃（52%）」「データのプライバシーとセキュリティ（51%）」「ガバナンスの維持（45%）」\n* 92％が「社員がAIと協働できるようスキルトレーニングが必要」と回答\n\n📥 [レポート全文はこちらからダウンロードできます](https://about.gitlab.com/software-innovation-report)\n\n（日本に特化したレポートは近日中に公開予定）\n\n# **GitLab 18.2がリリースされました**\n\n![GitLab 18.2 Release ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/vdubujaphpphyk2n4wnw.png)\n\nGitLab 18.2では、30以上の新機能や改善が追加され、よりスピーディーかつ安全な開発が可能に。今回のアップデートにも、GitLabコミュニティから152件の貢献が寄せられました。ありがとうございます！\n\n注目の新機能：\n\n* ✅ カスタムワークフローステータス：イシューの状態を自社の運用に合わせて柔軟に管理可能に\n* 🧭 Merge Requestページの再設計：ロールやワークフロー別に表示を最適化\n* 🔐不変コンテナタグ： 本番環境への不意な変更を防止\n\n🔗 [全リリース内容はこちら](https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/)\n\n[](https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/)\n\n# **今月のイベント情報：Black Hat USA & OSS EU**\n\n![Black Hat USA & OSS EU](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/buoqb3vmhmnsnznqquwj.png)\n\n今月はGitLabチームがイベントに登場します！\n\n📍 Black Hat USA（ラスベガス） – [詳細はこちら](https://www.blackhat.com/us-25/)[\n](https://www.blackhat.com/us-25/)\\\n📍 Open Source Summit Europe（アムステルダム） – 今月後半 👉 [登録はこちら](https://events.linuxfoundation.org/open-source-summit-europe/register/)\n\n開催地にいらっしゃる方は、ぜひお立ち寄りください！ステッカーもご用意しています。\n\n# **お客様事例：NatWest社**\n\n![NatWest](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/dr8uwztk6f1akrj7cdsp.png)\n\n金融機関NatWest社は、GitLab Duo Agent Platformを活用して開発スピードと生産性を大幅に向上させています。\n\n「GitLab Duo Agent Platformは、私たちのコードベースと組織構造を理解したうえで、AIが開発ワークフロー全体を支援してくれます。コード・テスト・CI/CDとあらゆる工程にAIが溶け込み、チームの一員として一緒に仕事している感覚があります。開発者はより創造的な仕事に集中できるようになりました」\n— NatWest社エンジニアリングプラットフォームリード Bal Kang\n\n# **今月のおすすめ記事＆動画👀**\n\n![What We're Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/mmjg9yy77orkohaureis.png)\n\nGitLabリーダーたちが語る、AI・DevSecOps・ソフトウェアセキュリティの未来。\n\n\u003Chttps://leaddev.com/reporting/the-rise-and-looming-fall-of-acceptance-rate>\n\n\u003Chttps://www.thestack.technology/a-cisos-focus-lessons-from-the-field/>\n\n\u003Chttps://www.raconteur.net/technology/agentic-ai-vibe-coding-oped>\n\n\u003Chttps://thenewstack.io/software-security-imperative-forging-a-unified-standard-of-care/>\n\n\u003Chttps://youtu.be/wZytaN-1URM>\n\n**最後に、今月の名言を**\n\n> 「知性の本当の証は知識ではなく、想像力である」\n> — アルベルト・アインシュタイン\n\n素晴らしいアイデアは、予想外の場所から生まれるものです。知識だけでなく、「想像する力」を大切にしたいですね。\n\n今月号は以上です。Duo Agent Platformはついに一般公開され、AIはC-suiteの重要議題へ、そしてMerge Requestページもさらに進化した、盛りだくさんな月でしたね。\n\nそれではまた来月、お会いしましょう！Happy Merging！\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/)｜GitLab Developer Advocate\n\n🧡 このニュースレターが気に入った方は、ぜひチームにもシェアしてください。\n 👉 [The Developer Show](https://www.linkedin.com/feed/update/urn:li:activity:7340777670714019840)の購読もお忘れなく！\n\n![Happy Merging!](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/is5jitqrtujnkmmkijlg.png)",[905],"AIエージェント、新機能、そして7,500億ドルの可能性に注目\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754368844/vagh8krfgft9cghbknod.png",{"featured":91,"template":800,"slug":1016},"monday-merge-2025-august-11",{"content":1018,"config":1025},{"date":858,"body":1019,"title":1020,"category":742,"heroImage":1021,"authors":1022,"description":1023,"tags":1024},"GitLabコミュニティのみなさん、こんにちは！Fatimaです。今月のMonday Mergeも、本当に盛りだくさんです！GitLab 18の最新トピックはもちろん、活気あふれるニューヨークでのAWS Summit、新しいライブ番組のスタート、そして注目のカスタマーストーリーまで。7月はまさにDevSecOpsの話題で溢れています。\n\nさらに、IBMと協力してメインフレームDevOpsの最新化にも取り組んでいます。（そう、あのCOBOLが再び注目を浴びています！）\n\nそれでは、さっそく見ていきましょう👇\n\n## GitLab 18 バーチャルローンチ：AI × オーケストレーションの未来へ\n\n![GitLab 18 バーチャルローンチ：AI × オーケストレーションの未来へ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/ryjaxhkcssnxn9x6genq.png)\n\n先月、GitLab 18のバーチャルローンチイベントを開催しました。\\\nライブ配信を見逃した方も大丈夫。ここで簡単にポイントを振り返ります。\n\n注目のハイライトは？ \\\nそれは、GitLab Duo Agent Platform の登場です。この新しいプラットフォームでは、エンジニアとAIエージェントがソフトウェア開発のあらゆる工程で連携・協働できるようになります。これにより、開発チームの生産性や開発スピードが大きく向上することが期待されています。\n\nGitLabのCEO、ビル・ステイプルズはこのように語りました：\n\n> *「GitLab 18は、人とAIエージェントが一緒に働けるDevSecOpsオーケストレーションフォームです。ソフトウェア開発のあらゆる工程で、“エージェント型AI”を活用したチームワークを実現します。」*\n\nつまり、これは開発者の代わりになるものではなく、繰り返し作業の負担を減らし、人の創造力と専門性をもっと活かせるようにするための進化です。私たちはそんな未来を目指しています。\n\nさらに今回、GitLabの統合DevSecOpsプラットフォームとAmazon Q Developerエージェントの連携も発表しました。この強力な組み合わせにより、より安全でスピーディーなソフトウェア開発が実現します。\n\nGitLab Duo + Amazon Qは、AIを活用したシームレスな開発の新時代を象徴するものです。\n\nイベントにはBarclaysとThalesも登場し、GitLab 18がそれぞれの組織の開発プロセスをどう変えているのか、リアルな声を共有してくれました。金融の高度なセキュリティ要件から航空業界のイノベーションまで、GitLab 18がもたらす影響は確かなものです。\n\n👉 イベントのフル動画は [GitLab 18 Launch Event](https://about.gitlab.com/ja-jp/eighteen/?utm_medium=social&utm_source=linkedin&utm_campaign=20250624_global_corp_webcast_aisdlc_en_gitlab18)ページ でご覧いただけます。\n\n## GitLab 18.1がリリースされました：セキュリティ、スピード、そしてAIの進化\n\n![18.1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/wbauaqzctmlul8lg7mu3.png)\n\nGitLab 18をリリースをしてすぐではありますが、[GitLab18.1が登場](https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release/)しました！この最初のリリースには、チームの開発スピードとセキュリティをさらに高めるためのアップデートが満載です。\n\n#### 注目の新機能はこちら：\n\n✅ Duoコードレビュー が正式リリース！\\\n AIがマージリクエストに対してインテリジェントなフィードバックを提供し、レビューのスピードアップやバグの早期発見を支援します。\n\n📦 Maven仮想レジストリ（Virtual Registry） がベータ版に\\\n GitLab上でのMaven依存関係の管理がより簡単になりました。\n\n🔐 漏洩パスワード検出機能 を追加\\\n あなたのパスワードが既知のデータ漏洩に含まれていないかを検出し、安全な変更方法を案内してくれます。\n\n🔁 SLSAレベル 1 準拠をサポート\\\n 新しいCI/CDコンポーネントを使って、ソフトウェアサプライチェーンのセキュリティ強化に貢献します。\n\nそして、何より嬉しいのは、みなさんからの 110件以上の改善と、311件ものコミュニティ貢献によってこのリリースが実現したことです。開発・レビュー・ドキュメント・ビルドに関わってくださった全ての方々、本当にありがとうございます！\n\n👉 [リリースノート全文はこちら！](https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release/)\n\n## 新ライブ配信シリーズ：The Developer Show – Powered by GitLab \n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204283/guz14qmyjhiyuf6oyh9k.png)\n\nGitLabからの新しいライブ配信シリーズが始まりました！その名も The Developer Show – Powered by GitLab。私とセキュリティPMMのSalがホストを務める、月1回のライブ配信番組です。\n\nこれはよくある「普通のウェビナー」ではありません。毎回、実際に今の開発現場を変えている技術について深く掘り下げていきます。\n\n対象は、開発者、開発リード、コードに関わるすべての人。業界で本当に語られているリアルな会話をキャッチアップしたい人向けです。\n\n📺 エピソード1では、GitLab 18 バーチャルローンチの内容を振り返り！\\\n ハイライトの紹介はもちろん、実践的なヒントやちょっと辛口なコメントも交えてお届けします。\n\n👉 [今すぐ視聴＆チャンネル登録して、次回もお見逃しなく！](https://www.linkedin.com/events/7340777668130312193/comments/)\n\n## AWS Summit New York：GitLabブースでお会いしましょう！ !\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/thiukj2hnn9mjyd1mcui.png)\n\n先日の東京に引き続き、7月16日、GitLabチームはニューヨークで開催されるAWS Summitに参加します！お近くの方は、Javits Center内のGitLabブースにぜひお立ち寄りください。\n\n当日は以下の内容をご用意しています：\n\n* GitLab DuoのAI機能を体験できるハンズオンデモ  \n* セキュリティ、開発スピード、開発者体験に関するライトニングトーク  \n* GitLabのDevSecOpsエキスパートとの対話（ご質問大歓迎です！）  \n* 限定ノベルティやプレゼントもご用意しています\n\nさらに、当日はAWSのAgentic AI担当VPのSwami Sivasubramanian氏による基調講演も実施されます。Agentic AIがソフトウェア開発をどう変えていくのか、GitLabとしても非常に関心のあるテーマです。\n\n参加登録は無料です。ぜひこちらからお申し込みください：[登録はこちら](https://about.gitlab.com/events/aws-summits/)\n\n## GitLabチームに会いに来ませんか？ WeAreDevelopers World Congress !\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/z9hot8dhmj1k4gjxefmg.png)\n\n世界中の開発者とつながるこのイベントで、GitLabチームも皆さんとお会いできるのを楽しみにしています！スタンド A07 にぜひお立ち寄りください。GitLabのDevSecOpsプラットフォームが、ソフトウェアのデリバリーをどのように加速し、チーム間のコラボレーションを強化できるか等をご紹介します。\n\nCI/CDやセキュリティ自動化、開発フローの改善に興味がある方はもちろん、\\\n どんな質問にもチームメンバーがお答えしますので、お気軽にお声がけください。\n\nまた、金曜日には注目のセッションも：\n\n* 13:40〜 GitLab VP of Engineering、Maw Wildpanerによる講演\\\n   　「なぜ“セキュリティファースト開発”が、より良いソフトウェアを早く届ける鍵となるのか」\n* 16:30〜 GitLab VP of Strategy and Developer Relations、Emilio Salvadorが登壇するパネル「DevRelの戦略的な力：コミュニティからビジネスインパクトへ」\n\n👋 [ベルリンでお会いしましょう！](https://www.wearedevelopers.com/world-congress/)\n\n## 事例のご紹介：Thales \n\n![Thales](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/m85bcsqac7gitoewqfrb.png)\n\n今月の事例紹介は、なんと高度3万5千フィートの空の上からお届けします。Thales は、航空宇宙・防衛分野のグローバルリーダー企業。彼らは従来のDevOpsプロセスを、クラウドネイティブでCI/CD駆動のイノベーションエンジンへと進化させました。\n\nGitLabを活用して開発したのが、次世代の機内エンターテインメントシステム「FlytEDGE」。乗客ごとにパーソナライズされたコンテンツやサービスを提供しながら、デプロイ時間を95%短縮することに成功しています。分散チーム間のコラボレーションをスムーズにし、パイプライン全体に自動化を導入し、開発者がボトルネックなく素早くリリースできる環境を実現。その結果、従来の20倍のスピードでデプロイできるようになりました。\n\n👉 [こちらから導入事例を詳しくご覧ください](https://about.gitlab.com/ja-jp/customers/thales/)\n\n## 今月のおすすめ記事\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204283/agkyge3unfoilwmmk1c9.png)\n\n今月もGitLabのSlackチャンネルでは、たくさんの素晴らしいDevSecOpsの考えや情報がシェアされています。その中から特に注目されているものをご紹介します。\n\n* [https://japan.zdnet.com/article/35234560/](\u003C>) \n* \u003Chttps://vmblog.com/archive/2025/06/23/breaking-down-silos-gitlab-and-ibm-partner-to-modernize-mainframe-devops.aspx>\n* \u003Chttps://www.nextgov.com/ideas/2025/05/legacy-government-systems-enter-ai-era/405642/>\n* \u003Chttps://www.economiematin.fr/investissement-operateur-telecom-technologie-caronna>\n* \u003Chttps://thenewstack.io/accelerating-developer-velocity-with-effective-platform-teams/>\n* \u003Chttps://leaddev.com/uncategorized/how-get-most-out-ai-tooling>\n\n\n\n## 📌 今月の名言\n\n>  「何事も、それが成し遂げられるまでは不可能に思えるものだ。」\\\n>  – ネルソン・マンデラ\n\n高速なデプロイ、スマートなセキュリティ、次世代の開発者のための開発など、\\\nどんなに難しいことに取り組んでいても、あなたならきっとできます。\n\n🦊 また次回まで！\n\nGitLabコミュニティの一員でいてくださり、ありがとうございます！みなさんがGitLab 18でどんなものを作ってくださるのか、私たちも楽しみにしています。バーチャルイベントの登録と、AI機能の活用開始もお忘れなく。それではまた次回のMonday Mergeでお会いしましょう。Happy Merging! \\\n[The Developer Showの購読もお忘れなく！](https://www.linkedin.com/feed/update/urn:li:activity:7340777670714019840)\n\n[Fatima Sarah Khalid](\u003C>) | GitLab Developer Advocate\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/hdcjv0v3qqk53xjazumo.png)\n\n[](https://www.linkedin.com/feed/update/urn:li:activity:7340777670714019840)","Monday Merge 7月号","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204420/ccdkkhlyrjmyjxsicf7d.jpg",[905],"Monday Merge７月号では、GitLab 18の最新トピックのほか、AWS Summit、新しいライブ番組のスタート、そして注目のカスタマーストーリーをご紹介します。",[109,838,947,865,270,896,714,280,796,742,1010,776,922],{"featured":6,"template":800,"slug":1026},"monday-merge-2025-july-14",{"content":1028,"config":1036},{"title":1029,"description":1030,"authors":1031,"heroImage":1032,"date":1033,"body":1034,"category":742,"tags":1035},"🌞 6月のMonday Merge：GitLab 18登場！ ただのアップデートじゃない、その理由とは？","6月のMonday Mergeでは、大規模アップデートや新しいAI機能、次のスプリントに役立つDevSecOpsインサイトが満載です。",[905],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659951/Blog/Hero%20Images/image4.png","2025-06-09","みなさん、こんにちは！6月のMonday Mergeにようこそ。今回も最新情報をお届けします！\n\n大規模アップデートや新しいAI機能、次のスプリントに役立つDevSecOpsインサイトが満載です。今月の注目ポイント？それは GitLab 18の正式リリースです。しかも今回から、PremiumおよびUltimateのすべてのお客様が、GitLab Duoの主要なAI機能を追加料金なしでご利用可能になりました。\n\nそれでは、さっそく見ていきましょう👇\n\n## GitLab 18：GitLabにとっての小さな一歩、DevSecOpsにとっての大きな飛躍\n![gitlab 18](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/image6.png)\n\nGitLab 18.0のリリースでは、PremiumとUltimateプランにGitLab Duoが標準搭載され、AIネイティブなDevSecOpsの新たな時代が始まります。\n\n### 新機能ハイライト\n\n* Duoコード提案 & GitLab Duo ChatがIDEで利用可能に：コードの記述から理解、リファクタリング、テストまでリアルタイムで支援します。  \n* リポジトリX-Ray（Self-Hostedはベータ版）：リポジトリ構造とコードの健全性を可視化します。  \n* GitLab Duoコードレビューの自動有効化：すべてのマージリクエストにAIレビューを適用。  \n* プロンプトキャッシュ機能：AI応答の遅延を軽減し、スムーズなやり取りを実現。\n\n最新のグローバルDevSecOps調査では、デベロッパーがコード以外の作業に79％もの時間を費やしていることが明らかになりました。つまり、AIを“コード支援”のみに使っているだけでは、AIの真の力を活かしきれていません。GitLab 18では、ソフトウェア開発ライフサイクル全体にAIを組み込み、面倒な作業を減らして本質的なイノベーションに集中できる環境を提供します。\n\nこのリリースを可能にしたのは、世界中の素晴らしいコミュニティの力です。328件のコントリビュートにより支えられたGitLab 18は、まさに「使う人たちによって作られた」リリースです。\n\n今月の注目コントリビューターは、Adfinis社CTOのMichael Hoferさん。GitLabのGeo機能やSecrets Managerの改善など、本当にたくさんの貢献をしてくださいました。オープンソースにかける想いと、周囲を巻き込む力に、私たちもたくさんの学びをもらっています。\n\n👉 [GitLab 18 リリースノート全文を読む](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)\n\n## 事例のご紹介：Ignite by FORVIA HELLA\n![ignite](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/image3.png)\n\nソフトウェアが自動車産業の中核となる今、[Ignite by FORVIA HELLA](https://www.linkedin.com/company/ignite-by-forvia-hella/)は次世代車両開発のために、ベルリンを拠点とするソフトウェア・イノベーションハブ Ignite を立ち上げました。\n\nCTOのFelix Kortmann氏はGitLab Duoについてこう語ります。\n\n「Duoのインテリジェントなコード提案は、デベロッパーにとって日常の必需品です。チャット機能と組み合わせることで、即座のフィードバックと反復が可能になり、開発サイクルが短縮され、コードの安全性も向上しました。私たちのワークフローに、シームレスかつ強力に統合されています」\n\nGitLab CI/CDとAI機能を組み合わせることで、Igniteは反復テストや品質チェックを自動化。コードがpushされた瞬間に自動処理が走り、早期の課題検出とスピーディーなデリバリーを実現しています。\n\n## GitLab 18のローンチイベントがバーチャルで開催！しかもアジア時間に！さらに日本語字幕付き！\n\n2025年6月24日（火）13時より、GitLab 18の新機能を紹介するグローバルオンラインイベントを開催します。\n\n### ✨ イベント内容\n\n* GitLab 18の新機能を実演するライブデモ  \n* GitLabのリーダーたち（Bill Staples、Sabrina Farmer、Josh Lemos、David DeSantoほか）によるインサイト共有  \n* 新ライブシリーズ「The Developer Show」の初公開： コーディングデモ、プロダクト解説、コミュニティのストーリーをお届け！\n\nご都合の良い時間帯を選んでぜひご参加ください。質問も大歓迎です！\n\n👉 [今すぐイベント登録する](https://about.gitlab.com/eighteen/)\n\n## GitLab Duo、Premiumにも標準搭載\n\nGitLab 18のリリースにより、Duoの主要機能がPremiumおよびUltimateで標準提供されます。追加ツールも、追加費用も不要。IDE上でスマートな開発がすぐに始められます。\n\n### 機能ハイライト\n\n* GitLab Duoコード提案：20以上のプログラミング言語で高速なコード作成・リファクタリング  \n* GitLab Duo Chat：コードの解説、テスト生成、トラブル対応を簡単に\n\nさらに、より高度な機能を求めるチームには、Ultimate限定だったDuo EnterpriseがPremiumでも利用可能に。[GitLab Duo根本原因分析](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases)、GitLab Duo Self-Hosted、AIコードレビューなどが利用できます。\n\n👉 [Duoを有効にして、開発を始めましょう](https://about.gitlab.com/ja-jp/blog/gitlab-premium-with-duo/)\n\n## AWS Summit で直接お会いしましょう！\n![aws summit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687124/Blog/Content%20Images/image1.png)\n\n東京をはじめ、世界各地のAWS SummitにGitLabも出展します！GitLabとAWSの連携機能を体験できるほか、安全なクラウドネイティブ開発の事例もご紹介。もちろん、ノベルティもご用意しています！\n\n🗓️ 6月のイベント予定\n\n* シドニー｜6月4日〜5日  \n* ストックホルム｜6月4日  \n* ハンブルク｜6月5日  \n* マドリード｜6月11日  \n* ミラノ｜6月18日  \n* ムンバイ｜6月19日  \n* 東京｜6月25日〜26日\n\n👉 [AWS Summit 2025でお会いできるのを楽しみにしています！](https://about.gitlab.com/ja-jp/events/aws-summits/)\n\n## 今月のおすすめ読書\n![08 Header Images April What We’re Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/08_LinkedIn_Header_Images_April_What_We_re_Reading.png)\n\n* **A Practical Roadmap for Adopting Vibe Coding（Vibe Coding 導入のための実践ロードマップ）**\nスピードを重視するあまり、品質や保守性が犠牲にならないよう、適切なガバナンスが必要だとGitLabの戦略VPであるEmilio Salvadorが解説。\n\n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/a-practical-roadmap-for-vibe-coding-adoption/)\n\n* **3 ways APAC engineering teams can operationalise AI（APACの開発チームがAIを活用する3つの方法）**  \nAPACのエンジニアリングチームによる日常業務へのAI統合、業務効率化、抵抗感の軽減、ビジネス価値の可視化についてGitLabのCTOであるSabrina Farmerが説明します。  \n🔗 [Frontier Enterpriseの記事を読む](https://www.frontier-enterprise.com/3-ways-apac-engineering-teams-can-operationalise-ai/)  \n\n* **Beyond Culture: Addressing Common Security Frustrations（文化を越えて：セキュリティ課題の根本に向き合うには）**  \n文化づくりも重要ですが、開発とセキュリティの基本設計から見直す必要があります。GitLab最高情報セキュリティ責任者のJosh Lemosによる解説記事。  \n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/beyond-culture-addressing-common-security-frustrations/)  \n\n* **The Field CTO View: AI, Vibe Coding, and Developer Skillsets（フィールドCTOの視点：AIとVibe Coding、デベロッパーのスキルセットのこれから）**\n企業のIT部門ではAIがどう実装されているのか？ デベロッパーの適応はどう進んでいるのか？GitLabのフィールドCTO部門責任者が答えています。  \n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/the-field-cto-view-ai-vibe-coding-and-developer-skillsets/)\n\n## 今月のひとこと\n\n最後に、私が心に留めている言葉をシェアします。完璧を目指すよりも、まずは一歩を踏み出すこと。大きなアイデアは、小さな行動から始まります。\n\n「何かを始める方法は、話すのをやめて行動することだ」– ウォルト・ディズニー\n\nこれからも、ひとつずつマージを重ねながら、学び、作り、そして成長していきましょう 💜\n\n🦊 また次回まで！\n\nGitLabコミュニティの一員でいてくださり、ありがとうございます！みなさんがGitLab 18でどんなものを作ってくださるのか、私たちも楽しみにしています。バーチャルイベントの登録と、AI機能の活用開始もお忘れなく。それではまた次回のMonday Mergeでお会いしましょう。Happy Merging!\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | GitLab Developer Advocate\n![SignOffBanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/SignOffBanner.png)",[1010,714,838,765,776,742,280,234,947,922,865,270],{"slug":1037,"featured":6,"template":800},"monday-merge-2025-june-9",{"category":750,"slug":754,"posts":1039},[1040,1052,1062],{"content":1041,"config":1050},{"date":1042,"heroImage":1043,"title":1044,"authors":1045,"category":754,"body":1046,"description":1047,"tags":1048},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[968],"## 目次\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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\n## git mergeとは？\n\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。別のリポジトリからの変更を組み込む際にも使われ、git pull（git fetchとgit mergeを組み合わせたもの）の一部としても機能します。チームで開発を実施するときなどにmainブランチから作業用ブランチを作り、テストをしてからマージ、プッシュすることも多いでしょう。\n\n\nたとえば、main ブランチに基づいて作成された新しいブランチ’feature’があるとします。この feature ブランチを main にマージするのに使われるのがgit mergeコマンドです。\n\n\n## git mergeコマンドの基本\n\n\ngit mergeの基本的なコードは次のようになります。\n\n\n```\n\ngit merge BRANCH_NAME\n\n```\n\n\nブランチ名は、取り込みたいブランチの名前を入力します。\n\n\n一見簡単そうですが、マージをスムーズに実行するにはいくつか準備が必要となりますので、次の章で確認しましょう。\n\n\n## マージ先のブランチを準備する\n\n\ngit status を実行して、HEAD が取り込む先のブランチであることを確認します。必要に応じて\n\n\n```\n\ngit checkout BRANCH_NAME\n\n```\n\n\nを実行して、マージする先のブランチに切り替えます。\n\n\n## 最新のリモートコミットをフェッチする\n\n\nリモートで変更を加えたら、マージ先ブランチとマージ元ブランチに最新の変更内容を反映させます。その際は、[git fetchとgit pull](https://about.gitlab.com/ja-jp/blog/2024/07/25/what-is-the-difference-between-git-fetch-and-git-pull/)を使います。その後、リモートで加えた変更内容がmainブランチに反映されていることを確認します。\n\n\n## 早送りマージと３ウェイマージ\n\n\n早送りマージは、ブランチが分岐していない場合にのみ使えるコマンドです。早送りマージでは、マージ自体は行われませんが、ブランチの先頭とブランチの末尾の履歴を結合することで、旧ブランチからアクセスできたコミットが、新ブランチからも利用できるようになります。\n\n\n強制的に早送りマージを実施する場合は以下のコードを使います（分岐がある場合など早送りマージができない場合にはエラーとなりマージはできません） \n\n\n```\n\ngit merge --ff-only\n\n```\n\n\n一方、ブランチが分岐している場合には、早送りマージを適用することはできず、マージする手段は３ウェイマージに限られます。３ウェイマージは、3 つのコミット （2 つのブランチのそれぞれ先端のコミットと履歴を統合するために生成される専用のコミット）を使用してマージコミットを生成することから来ています。\n\n\n```\n\ngit checkout BRANCH_NAME\n\n```\n\n\nを使うと、早送りマージが可能な時は早送りマージを実施し、できない時に３ウェイマージを実施します。\n\n\n## git mergeによるコンフリクトの解決\n\n\nマージの基本を理解すると、同じ箇所を同時に更新してしまったらどうなるのか、という疑問を持たれる方もいるのではないでしょうか。この場合、Git側ではどちらを優先すべきか判断ができず、手作業でコンフリクトを解決することを求めます。\n\n\nエラーメッセージは次のように表示されます。\n\n\n```\n\ngit merge BRANCH_NAME\n\nAuto-merging index.html\n\nCONFLICT (content): Merge conflict in index.html\n\nAutomatic merge failed; fix conflicts and then commit the result.\n\n```\n\n\nコンフリクトを解決するまで、処理は中断されます。どのファイルでコンフリクトが発生してマージできなかったのを確認するにはgit status を実行します。\n\n\n```\n\ngit status\n\n```\n\n\n未解決のコンフリクトについては unmerged として表示されます。標準的なコンフリクトマーカーがファイルに追加されるため、該当ファイルから修正できます。git addを実行して、コンフリクトが解決したことを Git に通知します。続いて通常の git commit を実行してマージ コミットを生成します。\n\n\n## git mergeコマンドのベストプラクティス\n\n\ngit mergeコマンドでよく起こる問題として、他のデベロッパーが加えた変更を破棄してしまうことが挙げられます。個々人がこまめにgit mergeを実行することで、変更を破棄してしまう問題は避けることができますが、マージそのもののコストが膨れ上がる可能性があります。複雑なコンフリクトが出ない場合に自動マージしてくれるようなツールの導入は、git mergeを使うチームの大きな手助けになるはずです。\n\n\n## GitLabでgit mergeを使う\n\n\ngit mergeのベストプラクティスとしてツールの使用をおすすめしましたが、[GitLab](https://about.gitlab.com/ja-jp/)なら自動マージ機能のほかにもリモートリポジトリのホスティング、インターフェースの提供、変更内容のコードレビュー、プッシュされたコードの自動ビルド、テスト、デプロイまでを一括で管理できます。\n\n\ngit mergeで起きるコンフリクトを自動で解決できるGitLabの無料トライアルは[こちら](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)からお申し込みいただけます。\n\n\n## git mergeコマンド のFAQ\n\n\n### git mergeコマンドとは何ですか？\n\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。\n\n\n### mainブランチにマージするにはどうしたらいいですか？\n\n\nまず、\u003Ccode>git checkout BRANCH_NAME\u003C/code>を使ってmainブランチに移動します。\n\n\n次に\u003Ccode>git merge BRANCH_NAME\u003C/code>を使ってマージしたいブランチを指定します。\n\n\nマージ先ブランチ名）master\\\n\nマージするブランチ名）feature1の場合には\n\n\n```\n\n\u003Ccode>git checkout master\u003C/code>\n\n\u003Ccode>git merge feature1\u003C/code>\n\n```\n\n\n\\\n\nとなります。\n\n\n### git mergeとgit rebaseの違いは何ですか？\n\n\ngit mergeとgit rebaseはどちらもブランチを結合するコマンドです。mergeが新しいコミットを生成してコミット履歴が分散してしまうのに対し、rebaseはコミット履歴をひとつのブランチにまとめます。rebaseはログを整理する目的で使われることが多いですが、別のブランチで他のメンバーが加えた変更の履歴を消してしまう可能性などがあるので、上級者向けのコマンドといえます。\n\n\n*監修：知念 梨果* *[@rikachinen](https://gitlab.com/rikachinen)（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n","この記事では、git mergeコマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[865,1049,797,810],"git",{"featured":91,"template":800,"slug":1051},"git-merge-command-overview",{"content":1053,"config":1060},{"title":1054,"description":1055,"authors":1056,"heroImage":1057,"date":848,"body":1058,"category":754,"tags":1059},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[968],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg","## オープンソースとは？\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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[865,270,895,776],{"featured":91,"template":800,"slug":1061},"what-is-open-source",{"content":1063,"config":1072},{"title":1064,"description":1065,"authors":1066,"heroImage":1068,"body":1069,"date":1070,"category":754,"tags":1071},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",[1067],"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\n## 新しいgit-diff-pairs(1)コマンド\n\n\n差分は、すべてのコードレビューの中心となるもので、2つのリビジョン間で行われた\n\nすべての変更を表示します。GitLabでは、さまざまな場所で差分が表示されますが、最も\n\n一般的なのはマージリクエストの[「変更」タブ](https://docs.gitlab.com/user/project/merge_requests/changes/)です。\n\nその裏側では、差分の生成に[`git-diff(1)`](https://git-scm.com/docs/git-diff)が\n\n使われています。たとえば、以下のように使います。\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nこのコマンドは、変更されたすべてのファイルの完全な差分を返します。ただし、リビジョン間で変更されたファイル数が非常に多い場合、スケーラビリティの課題が生じる可能性があります。GitLabのバックエンドでは、コマンドが自己設定されたタイムアウトに達してしまうこともあります。変更数が多い場合、\n\n差分の計算をより小さく扱いやすい単位に分割できる方法があれば、より効果的です。\n\n\nこの課題を解決する1つの方法は、\n\n[`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree)を使って、\n\n変更されたすべてのファイルに関する情報を取得することです。\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n\n```\n\n\nGitはこの出力を[「raw」フォーマット](https://git-scm.com/docs/git-diff-tree#_raw_output_format)と呼んでいます。\n\n簡単に言えば、出力の各行にはファイルのペアと、\n\nそれらの間で何が変更されたかを示すメタデータが表示されます。大規模な変更に対して\n\n「パッチ」形式の出力を生成する方法と比べて、\n\nこの処理は比較的高速な上、すべての変更の概要を把握できます。また、このコマンドでは、`-M`フラグを付けることでリネーム検出を有効にし、変更がファイルのリネームによるものかどうかを判別することもできます。\n\n\nこの情報を使えば、`git-diff(1)`を使って各ファイルペアの差分を\n\n個別にコンピューティングすることができます。たとえば、以下のようにblob IDを\n\n直接指定することも可能です。\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nこの処理は、各ファイルペアごとに繰り返すことができますが、\n\n個別のファイル差分ごとにGitプロセスを立ち上げるのは、あまり効率的ではありません。\n\nさらに、blob IDを使った場合、変更ステータスやファイルモードといった、\n\n親ツリーオブジェクトに格納されているコンテキスト情報が差分から失われてしまいます。\n\n本当に必要なのは、「raw」なファイルペア情報を元に、\n\n対応するパッチ出力を生成する仕組みです。\n\n\nバージョン2.50から、Gitに新しい組み込みコマンド\n\n[`git-diff-pairs(1)`](https://git-scm.com/docs/git-diff-pairs)が追加されました。このコマンドは、\n\n標準入力（stdin）から「raw」形式のファイルペア情報を受け取り、どのパッチを出力すべきかを正確に判断します。以下の例は、\n\nこのコマンドの使用方法を示しています。\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nこのように使用した場合、出力結果は`git-diff(1)`を使った場合と同じになります。\n\nパッチ出力を生成する専用コマンドを分けることで、\n\n`git-diff-tree(1)`から得られた「raw」出力を、より小さなファイルペアのバッチに分割し、それぞれを別々の\n\n`git-diff-pairs(1)`プロセスにフィードすることができます。これにより、差分を一度にすべてコンピューティングする必要がなくなるため、\n\n先に挙げたスケーラビリティの課題が解決されます。今後のGitLabリリースでは、\n\nこの仕組みの応用により、\n\n特に変更量が多い場合における差分生成のパフォーマンス向上が\n\n期待されます。この変更についての詳細は、該当する\n\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/)をご覧ください。\n\n\n_このプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。_\n\n\n## 参照更新の一括処理\n\n\nGitには、参照を更新するための[`git-update-ref(1)`](https://git-scm.com/docs/git-update-ref)\n\nコマンドが用意されています。このコマンドを`--stdin`フラグとともに使用すると、\n\n複数の参照を1つのトランザクションとしてまとめて更新できます。\n\nこれを行うには、各参照更新の指示を標準入力（stdin）で指定します。\n\nこの方法で参照を一括更新すると、アトミックな動作も実現できます。つまり、1つでも参照の更新に失敗した場合、\n\nトランザクション全体が中断され、\n\nどの参照も更新されません。以下は、この動作を示す例です。\n\n\n```shell\n\n# 3つの空のコミットと「foo」という名前のブランチを持つリポジトリを作成する\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n\n# コミットIDを出力する\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n\n# 指定された古いオブジェクトIDが一致しないため、更新は失敗することが予想されます。\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# 「bar」リファレンスは作成されませんでした。\n\n$ git switch bar\n\nfatal: invalid reference: bar\n\n```\n\n\n多くの参照を個別に更新する場合と比べて、一括で更新するほうがはるかに効率的です。\n\nこの方法は基本的にうまく機能しますが、\n\n一括更新による効率面のメリットを優先するために、\n\nリクエストされた参照更新の一部が失敗することを許容したい場合も\n\nあります。\n\n\n今回のリリースで、`git-update-ref(1)`に新しく`--batch-updates`オプションが追加されました。\n\nこのオプションを使用すると、1つ以上の参照更新が失敗しても、処理を続行できるようになります。\n\nこのモードでは、個々の失敗が次の形式で出力されます。\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n```\n\n\nこれにより、成功した参照の更新はそのまま進行しつつ、どの更新が拒否されたのか、\n\nまたその理由についての情報も得ることができます。前の例と同じリポジトリを\n\n使った例は以下のとおりです。\n\n\n```shell\n\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# 「foo」への更新が拒否されたにもかかわらず、「bar」参照が作成されました。\n\n$ git switch bar\n\nSwitched to branch 'bar'\n\n```\n\n\n今回は`--batch-updates`オプションを使用したことで、\n\n更新処理が失敗しても参照の作成は成功しました。この一連のパッチは、\n\n`git-fetch(1)`や`git-receive-pack(1)`における今後の一括参照更新時の\n\nパフォーマンス改善の基盤となります。詳細については、該当する\n\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)をご覧ください。\n\n\n_このプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n\n## git-cat-file(1)の新しいフィルタオプション\n\n\n[`git-cat-file(1)`](https://git-scm.com/docs/git-cat-file)を使うと、\n\nリポジトリ内に含まれるすべてのオブジェクトの情報を\n\n`--batch–all-objects`オプションで出力できます。たとえば、以下のように実行します。\n\n\n```shell\n\n# シンプルなリポジトリを設定します。\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n\n# 到達不能なオブジェクトを作成します。\n\n$ git commit --amend --no-edit\n\n\n# git-cat-file(1)を使用して、到達不能なオブジェクトを含むすべてのオブジェクトに関する情報を出力します。\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\n状況によっては、リポジトリ内のすべてのオブジェクトを検索し、\n\n特定の属性に基づいて一部のオブジェクトだけを出力したい場合があります。\n\nたとえば、コミットオブジェクトだけを表示したいときは、\n\n`grep(1)`を使って以下のように実行できます。\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nこの方法でも目的は達成できますが、出力のフィルタリングには欠点があります。\n\nそれは、`git-cat-file(1)`が\n\nユーザーが関心を持っていないオブジェクトも含め、リポジトリ内のすべてのオブジェクトをたどらなければならない点です。これはかなり非効率です。\n\n\n今回のリリースでは、`git-cat-file(1)`に`--filter`オプションが追加され、\n\n指定した条件に一致するオブジェクトだけを表示できるようになりました。これは`git-rev-list(1)`にある同名のオプションと似ていますが、\n\n対応しているフィルターの種類はその一部に限られています。\n\n対応しているフィルターは`blob:none`、`blob:limit=`および\n\n`object:type=`です。先ほどの例と同様に、オブジェクトはGitを使用して直接\n\n種類でフィルタリングできます。\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nGitに処理を任せられるのは便利なだけでなく、オブジェクト数の多い大規模なリポジトリにおいては\n\n効率面のメリットも期待できます。\n\nリポジトリにビットマップインデックスがある場合、\n\nGitが特定の種類のオブジェクトを効率的に検索できるようになり、パックファイル全体をスキャンする必要がなくなるため、\n\n処理速度が大幅に向上します。\n\n[Chromiumリポジトリ](https://github.com/chromium/chromium.git)で行われた\n\nベンチマークでは、こうした最適化による大きな改善が確認されています。\n\n\n```text\n\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\n\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\n\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\n\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\n\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\n\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\n\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指定された種類のオブジェクト数に比例して増減することが示されています。\n\n元のメーリングリストのスレッドは、\n\n[こちら](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/)でご覧いただけます。\n\n\n_このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。_\n\n\n## バンドル生成時のパフォーマンスが向上\n\n\nGitには、指定した参照とそれに関連する到達可能なオブジェクトを含むリポジトリのアーカイブを生成する機能があります。\n\n具体的には、\n\n[`git-bundle(1)`](https://git-scm.com/docs/git-bundle)コマンドを使用します。この操作は、\n\nGitLabがリポジトリのバックアップを作成する際や、\n\n[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムの一部としても使用されます。\n\n\n何百万もの参照を含む大規模なリポジトリでは、\n\nこの操作に数時間から数日かかることもあります。たとえば、GitLabのメインリポジトリ\n\n（[gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)）では、\n\nバックアップに約48時間を要していました。調査の結果、バンドルに重複した参照が含まれないようにチェックする処理において、\n\nパフォーマンスのボトルネックが存在することが判明しました。\n\nこの実装では、すべての参照をイテレーションして比較するために入れ子の`for`loopが使われており、\n\n時間計算量はO(N^2)となっていました。これは、\n\nリポジトリ内の参照数が増えるほど、処理性能が大きく低下する構造です。\n\n\n今回のリリースでは、この問題に対応し、\n\nネストされたloopをマップ型のデータ構造に置き換えることで、処理速度が大幅に向上しました。以下は、\n\n10万件の参照を含むリポジトリでバンドルを作成した際のパフォーマンス改善を\n\n示すベンチマーク結果です。\n\n\n```text\n\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\n\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\n\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master) ```\n\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元のメーリングリストのスレッドは\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\n_このプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n\n## バンドルURIのアンバンドルの改善\n\n\nGitの[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムは、\n\nフェッチするバンドルの場所をクライアントに提供することで、クローンやフェッチの速度を\n\n向上させることを目的としています。クライアントがバンドルをダウンロードすると、\n\n`refs/heads/*`以下の参照が、その関連オブジェクトとともにバンドルから\n\nリポジトリにコピーされます。バンドルには`refs/tags/*`のように\n\n`refs/heads/*`以外の参照も含まれていることがありますが、\n\nこれらはクローン時にバンドルURIを使用する場合、単に無視されていました。\n\n\nGit 2.50ではこの制限が解除され、\n\nダウンロードされたバンドルに含まれる`refs/*`に一致するすべての参照がコピーされるようになりました。\n\nこの機能を実装した[Scott Chacon](https://github.com/schacon)さんは、\n\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss)をクローンした際の\n\n挙動の違いを紹介しています。\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nこれらの結果を比較すると、Git 2.50はバンドル展開後に43,887個（40.42 MiB）のオブジェクトをフェッチしているのに対し、\n\nGit 2.49は合計で959,773個（366.94 MiB）のオブジェクトをフェッチしています。\n\nGit 2.50では、取得されるオブジェクト数が約95%、\n\nデータ量が約90%削減されており、クライアントとサーバーの双方にとってメリットがあります。\n\nサーバー側ではクライアントに送信するデータ量が大幅に減り、\n\nクライアント側でもダウンロードおよび展開するデータが少なくて済みます。Chaconさんの提供した例では、\n\nこれによって処理速度が25%向上しました。\n\n\n詳細については、\n\n該当する[メーリングリストのスレッド](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/)をご覧ください。\n\n\n_この一連のパッチは、[Scott Chacon](https://github.com/schacon)さんによって提供されました。_\n\n\n## 詳細はこちら\n\n\n本記事でご紹介したのは、最新リリースにおいてGitLabと広範なGitコミュニティによって行われた\n\nコントリビュートのごく一部にすぎません。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/)では、\n\nさらに詳しい情報をご覧になれます。また、\n\n[以前のGitリリースのブログ記事](https://about.gitlab.com/blog/tags/git/)もぜひご覧ください。GitLabチームメンバーによる過去の主なコントリビュートをご確認いただけます。\n","2025-06-16",[1049,895,270],{"featured":91,"template":800,"slug":1073},"what-s-new-in-git-2-50-0",{"category":90,"slug":765,"posts":1075},[1076,1088,1100],{"content":1077,"config":1086},{"heroImage":1078,"body":1079,"authors":1080,"updatedDate":1081,"date":1082,"title":1083,"tags":1084,"description":1085,"category":765},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1755780180/rjsjdqp84qgmlu698wfc.png","本ブログは、[GitLab 18.3 Release](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n## Visual Studio向けDuo Agent Platform（ベータ版）と埋め込みビューを搭載したGitLab 18.3をリリース\n\nこのたび、GitLab 18.3のリリースを発表しました。このリリースでは、Visual Studio向けDuo Agent Platform（ベータ版）、埋め込みビュー、直接転送による移行、CI/CDジョブトークンの詳細な権限設定など、さまざまな機能が追加されました。\n\nこれらの機能は、今回のリリースに含まれる38以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 18.3には、GitLabコミュニティのユーザーから314件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ](https://about.gitlab.com/upcoming-releases/)をご覧ください。\n\n## 今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は[Ahmed Kashkoush](https://gitlab.com/ahmad-kashkoush)さんです\n\n\u003Cimg src=\"https://about.gitlab.com/images/notable-contributor-logo.svg\">\n\n18.3では、[Ahmed Kashkoush](https://gitlab.com/ahmad-kashkoush)さんを注目コントリビューターとして表彰いたします！\n\nAhmedさんはこの[Google Summer of Codeの参加](https://gitlab.com/ahmad-kashkoush/gsoc-2025-final-report)を通じて、[GitLab Web IDE](https://gitlab.com/gitlab-org/gitlab-web-ide)に優れたコントリビュートをもたらしました。彼は長年のコミュニティからの要望に直接応える重要なGit操作を一貫して提供してきました。彼の5つの重要なマージリクエストには、[コミットおよび強制プッシュ機能](https://gitlab.com/gitlab-org/gitlab-web-ide/-/merge_requests/497)、[更新確認メッセージ](https://gitlab.com/gitlab-org/gitlab-web-ide/-/merge_requests/540)、[コミット修正機能](https://gitlab.com/gitlab-org/gitlab-web-ide/-/merge_requests/507)、[ブランチ作成操作](https://gitlab.com/gitlab-org/gitlab-web-ide/-/merge_requests/534)、[ブランチ削除機能](https://gitlab.com/gitlab-org/gitlab-web-ide/-/merge_requests/539)が含まれています。\n\n新機能の実装に加え、AhmedさんはWeb IDEから既存のコミットを修正できる機能を追加しました。これは5年以上前にコミュニティから要望され、24の「いいね」を獲得していた機能です。彼の包括的なブランチ管理の実装により、Web IDEはローカル開発環境と機能的に同等に近づき、基本的なGit操作のためにインターフェース間を切り替える必要がなくなりました。Ahmedさんの作業は、Web IDEをより多くのデベロッパーに利用しやすくすることで、GitLabの「誰もがコントリビュートできる」という[ミッション](https://handbook.gitlab.com/handbook/company/mission/)の理念を形にしています。\n\nAhmedさんをGoogle Summer of Codeプログラムを通じてメンターとしてサポートしたGitLabのスタッフフロントエンドエンジニア[Enrique Alcántara](https://gitlab.com/ealcantara)によってノミネートされました。彼は次のように述べています。「Ahmedさんは実際のユーザーの問題を解決することに献身的です。彼の作業は、専念するコントリビューターがGitLabのコア機能を改善する上でどれほどの影響を与えることができるかを示しています。」\n\nAhmedさんのコントリビュートは、オープンソース開発におけるメンターシップとコミュニティコラボレーションの力を示し、ローカルセットアップに関係なくGitLabをより使いやすくしています。\n\nGitLab Web IDEへの素晴らしいコントリビュートを提供してくれたAhmedさんに感謝します！\n\n## **GitLab 18.3でリリースされた主な改善点**\n\n### **Visual Studio向けDuo Agent Platform（ベータ版）**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nVisual Studio向けDuo Agent Platformのパブリックベータ版をリリースしました！このリリースにより、Visual StudioユーザーはDuo Agent Platformの高度なAI機能をIDE内で直接利用できるようになりました。\n\nDuo  Agent Platformは、ワークフローに2つの強力な機能をもたらします：\n\n* **Agentic Chat**：ファイルの作成と編集、パターンマッチングとgrepを使用したコードベースの検索、コードに関する質問への即座の回答など、会話型のタスクをVisual Studioから離れることなく素早く実行できます。\n* **エージェントフロー**：より大規模で複雑なタスクに、包括的な計画と実装サポートで取り組みます。エージェントフローは、イシュー、マージリクエスト、コミット、CI/CDパイプライン、セキュリティ脆弱性などのGitLabリソースを活用しながら、高レベルのアイデアをアーキテクチャとコードに変換するのに役立ちます。\n\nどちらの機能も、ドキュメント、コードパターン、プロジェクト情報全体で高度な検索を提供し、簡単な編集から詳細なプロジェクト分析まで、シームレスに移行できるようサポートします。\n\n今すぐVisual StudioでDuo Agent Platformベータ版をお試しいただき、開発ワークフローにおける新しいレベルの生産性とAI機能のサポートを体験してください。\n\n[ドキュメント](https://docs.gitlab.com/user/duo_agent_platform/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/editor-extensions/-/epics/179)\n\n[](https://gitlab.com/groups/gitlab-org/editor-extensions/-/epics/179)\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/Pdjf5HxQUBQ?si=ouLMn2O8jTQ6y9Ql\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### **埋め込みビュー（GLQLを活用）**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nこのリリースで、GLQLを活用した埋め込みビューの一般提供を開始します。Wikiページ、エピックの説明、イシューコメント、マージリクエストなど、作業が行われる場所に直接、GitLabデータの動的でクエリ可能なビューを作成して埋め込むことができます。\n\n埋め込みビューにより、チームは画面を切り替えることなく作業の進捗を一箇所で追跡できます。使い慣れた構文を使用してイシュー、マージリクエスト、エピック、その他の作業アイテムを検索し、カスタマイズ可能なフィールドとフィルタリングを備えたテーブルまたはリスト表示で結果を確認できます。\n\n埋め込みビューは、静的なドキュメントをプロジェクトデータと同期を保つライブダッシュボードに変換し、チームがコンテキストを保ちながら、ワークフロー全体でコラボレーションを向上させることができます。\n\n埋め込みビューの改善に向けたご意見やご提案を、ぜひ[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509792)よりお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/glql/#embedded-views)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15008)\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/DG_DL5r2GCM?si=6ATRXOF06qs0rMPS\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### **直接転送による移行**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\n直接転送による移行が一般提供されるようになりました。GitLabインスタンス間でGitLabグループとプロジェクトを直接転送で移行するには、GitLab UIまたは[REST API](https://docs.gitlab.com/ee/api/bulk_imports.html)を使用できます。\n\n[エクスポートファイルのアップロードによる移行](https://docs.gitlab.com/ee/user/project/settings/import_export.html#migrate-projects-by-uploading-an-export-file)と比較して、直接転送は：\n\n* 大規模なプロジェクトでより確実に動作します。\n* ソースインスタンスと宛先インスタンス間のバージョンギャップが大きい移行をサポートします。\n* 移行プロセスと結果に関するより良い洞察を提供します。\n\nGitLab.comでは、直接転送による移行はデフォルトで有効になっています。GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者が[機能を有効にする](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#enable-migration-of-groups-and-projects-by-direct-transfer)必要があります。\n\n![直接転送による移行](https://about.gitlab.com/images/18_3/migration_history.png)\n\n### **CI/CDジョブトークンのきめ細かい権限設定**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nパイプラインセキュリティがより柔軟になりました。ジョブトークンは、パイプライン内のリソースへのアクセスを提供する一時的な認証情報です。これまで、これらのトークンはユーザーから全権限を継承していたため、必要以上に広範なアクセス権限を持ってしまうことがありました。\n\n新しいジョブトークンのきめ細かい権限設定機能により、ジョブトークンがプロジェクト内でアクセスできる特定のリソースを正確に制御できるようになりました。これにより、CI/CDワークフローで最小権限の原則を適用し、CI/CDジョブトークンでプロジェクトにアクセスする際に、ジョブがタスクを完了するための必要最小限のアクセスのみを付与できます。\n\nパイプラインでの長期トークンへの依存を減らすために、[詳細権限機能のさらなる拡充](https://gitlab.com/groups/gitlab-org/-/epics/6310)に積極的に取り組んでいます。\n\n[ドキュメント](https://docs.gitlab.com/ci/jobs/fine_grained_permissions/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15258)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/15258)\n\n![CI/CDジョブトークンのきめ細かい権限設定](https://about.gitlab.com/images/18_3/sscs_authz_fine_grained_job_tokens.png)\n\n### **GitLab Duo Self-HostedでCode Reviewが利用可能に（ベータ版）**\n\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duo Self-HostedでGitLab Duo Code Reviewを使用できるようになりました。この機能はGitLab Duo Self-Hostedでベータ版として提供され、Mistral、Meta Llama、Anthropic Claude、OpenAI GPTモデルファミリーをサポートしています。\n\nGitLab Duo Self-HostedでCode Reviewを使用して、データ主権を損なうことなく開発プロセスを加速させます。Code Reviewがマージリクエストをレビューすると、潜在的なバグを特定し、直接適用できる改善を提案します。Code Reviewを使用して、人間にレビューを依頼する前に変更を反復して改善します。\n\nCode Reviewに関するフィードバックは[イシュー517386](https://gitlab.com/gitlab-org/gitlab/-/issues/517386)までお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/#gitlab-duo-in-merge-requests)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/524929)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/524929)\n\n![GitLab Duo Self-HostedでCode Reviewが利用可能に（ベータ版）](https://about.gitlab.com/images/18_3/Self_Hosted_Code_Review-min.png)\n\n### **GitLab Duo Code Reviewのカスタム指示**\n\n> SaaS: Premium、Ultimate、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duo Code Reviewのカスタム指示で、プロジェクト全体で一貫したコードレビュー標準を適用します。globパターンを使用して異なるファイルタイプに特定のレビュー基準を定義し、言語固有の規約が最も重要な場所に確実に適用されるようにします。\n\nカスタム指示では、次のことが可能です：\n\n* チームのコードレビュー標準を記述する\n* globパターンを使用してファイル固有の指示を定義する\n* カスタム指示を参照した、明確にラベル付けされたフィードバックを確認する\n\nリポジトリにカスタム指示を含む[.gitlab/duo/mr-review-instructions.yaml](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#customize-instructions-for-gitlab-duo-code-review)ファイルを作成するだけです。GitLab Duoは自動的にこれらの指示をレビューに組み込み、フィードバックを提供する際に特定の指示グループを引用します。\n\n[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/517386)でご意見やご提案をお寄せいただき、この機能の改善にご協力ください。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#customize-instructions-for-gitlab-duo-code-review)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/545136)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/545136)\n\n![GitLab Duo Code Reviewのカスタム指示](https://about.gitlab.com/images/18_3/DCR-Instructions.png)\n\n### **GitLab Duo Self-Hostedに独自のモデルを持ち込む（ベータ版）**\n\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duo Self-Hostedでは、GitLab Duo機能で使用する独自のモデルを持ち込むことができるようになりました。この機能はベータ版で、GitLab Duo Enterpriseをお使いのすべてのGitLab Self-Managedのお客様が利用できます。インスタンス管理者は、サポートされているGitLab Duo機能で使用する互換性のあるモデルを設定できます。\n\nこの機能により、GitLab Duo Self-Hostedの柔軟性は向上しますが、GitLabはすべてのGitLab Duo機能がすべての互換モデルで動作することをお約束できません。インスタンス管理者は、選択したモデルの互換性とパフォーマンスを検証してご確認いただく必要があります。なお、GitLabは、選択したモデルまたはプラットフォーム固有の問題については、GitLabからの技術サポートは提供されませんのでご了承ください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#bring-your-own-compatible-model)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/517581)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/517581)\n\n![](https://about.gitlab.com/images/18_3/SH_compatible_models.png)\n\n### **GitLab Duo Self-Hostedでハイブリッドモデルが選択可能に（ベータ版）**\n\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duo Self-HostedでGitLab AIベンダーモデルとプライベートに設定されたセルフホストモデルの組み合わせを使用できるようになりました。この機能はベータ版で、GitLab Self-ManagedですべてのGitLab Duo Enterpriseのお客様が利用できます。\n\nGitLab Duo Self-Hostedのハイブリッドモデルにより、GitLab Self-Managedインスタンス管理者は、セルフホストモデルとセルフホストAIゲートウェイ、またはGitLab AIベンダーモデルとGitLabホストのAIゲートウェイを、機能ごとに選択できるようになりました。これにより、管理者はセキュリティとスケーラビリティの要件のバランスを取ることができます。ハイブリッドモデル選択に関するフィードバックを提供するには、[イシュー561048](https://gitlab.com/gitlab-org/gitlab/-/issues/561048)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/#decide-on-your-configuration-type)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17192)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/17192)\n\n![GitLab Duo Self-Hostedでハイブリッドモデルが選択可能に（ベータ版）](https://about.gitlab.com/images/18_3/SH_Hybrid.png)\n\n### **コンプライアンスフレームワーク制御の違反の表示（ベータ版）**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n以前のコンプライアンス違反レポートは、グループ内のすべてのプロジェクトのマージリクエストアクティビティの全体的な概要を表示していました。検出可能なコンプライアンス違反は、職務分離の懸念に関連するもので、以下の内容でした：\n\n* マージリクエストの作成者が自分のマージリクエストを承認した場合を検出\n* マージリクエストが2つ未満の承認でマージされた場合を検出\n\nしかし、ユーザーフィードバックにより、違反分類が分かりにくく、実際のコンプライアンス用途にうまく適合しないことが判明しました。\n\nGitLab 18.3では、職務分離の範囲を超えて、コンプライアンスフレームワークのコンプライアンス制御と要件の違反を含むように違反レポートを大幅に強化しています。各カスタムコンプライアンスフレームワーク制御には、違反に関する詳細な情報を提供する関連監査イベントがあります。これには、誰が違反を犯したか、いつ発生したか、どのように修正するかといった内容が含まれ、ユーザー名とIPアドレス、さらに実行可能な修正提案も提供されます。\n\nこれらの改善により、コンプライアンスマネージャーは、組織が特定のコンプライアンスフレームワークに確実に準拠できるよう、より強力で関連性の高い情報を得られるようになります。非準拠を効果的に特定、修正、防止できるという安心感ももたらします。\n\n![コンプライアンスフレームワーク制御の違反の表示（ベータ版）](https://about.gitlab.com/images/18_3/compliance_link_violations_to_framework_controls.png)\n\n### **新しいWeb IDEソースコントロール操作**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\n本リリースでは、Web IDEに追加のソースコントロール機能が追加されました。ブラウザから離れることなく、Gitワークフローをより効率的に管理できます。**ソースコントロール**パネルで、次のことができるようになりました：\n\n* ブランチの作成と削除。\n* 既存のブランチをベースとしてブランチを作成。\n* 最後のコミットを修正して素早く修正。\n* インターフェースから直接変更を強制プッシュ。\n\nこれらの機能強化により、Git操作が指先で行えるようになります。利用可能な機能については、[ソースコントロールを使用する](https://docs.gitlab.com/user/project/web_ide/#use-source-control)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/user/project/web_ide/#use-source-control)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11142)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/11142)\n\n![新しいWeb IDEソースコントロール操作](https://about.gitlab.com/images/18_3/webide-source-control.gif)\n\n### **GitLab CI/CDのAWS Secrets Managerサポート**\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nAWS Secrets Managerに保存されたシークレットをCI/CDジョブで簡単に取得して使用できるようになりました。AWSとの新しい統合により、GitLab CI/CDを通じてAWS Secrets Managerと対話するプロセスが簡素化され、AWSのお客様のビルドとデプロイプロセスの合理化に役立ちます！\n\n[GitLabの共同開発プログラム](https://about.gitlab.com/community/co-create/)を通じてこの機能の開発にご協力いただいた[Markus Siebert](https://gitlab.com/m-s-db)さんと[Henry Sachs](https://gitlab.com/DerAstronaut)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ci/secrets/aws_secrets_manager/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17822)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/17822)\n\n![](https://about.gitlab.com/images/18_3/AWS_image.png)\n\n### **カスタム管理者ロール**\n\n> Self-Managed: Ultimate\n\nカスタム管理者ロールは、GitLab Self-ManagedおよびGitLab Dedicatedインスタンスの管理エリアに詳細な権限をもたらします。管理者は、フルアクセスを付与する代わりに、ユーザーが必要とする特定の機能のみにアクセスできる専門的なロールを作成できるようになりました。この機能により、組織は管理機能に対する最小権限の原則を適用し、過剰な権限によるセキュリティリスクを削減しつつ、運用効率を向上させることができます。\n\nご質問がある場合、実装経験を共有したい場合、または潜在的な改善について当社のチームと直接関わりたい場合は、[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509376)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/user/custom_roles/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15069)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/15069)\n\n![カスタム管理者ロール](https://about.gitlab.com/images/18_3/sscs_authz_custom_admin_role.png)\n\n## GitLab 18.3リリースに含まれるその他の改善点\n\n### **エピックの担当者、マイルストーンなどを一括編集**\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nグループ内でより多くのエピック属性を一括編集できるようになりました。ラベルに加えて、複数のエピックの担当者、ヘルスステータス、サブスクリプション、機密性、マイルストーンを一度に更新できます。\n\nこの機能強化により、複数のエピックに同じ変更を同時に適用できるため、大量のエピックの管理が効率化されます。\n\n[ドキュメント](https://docs.gitlab.com/user/group/epics/manage_epics/#bulk-edit-epics)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11901)\n\n![エピックの担当者、マイルストーンなどを一括編集](https://about.gitlab.com/images/18_3/bulk_edit_epics.png)\n\n\n\n### **Wiki機能の強化**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nこのリリースでは、3つの主要な改善によりWiki機能が強化されます：Wikiページへのサブスクライブ、ページ編集中のWikiコメントの表示、Wikiページコメントの並べ替えができるようになりました。\n\nこれらの機能強化により、チームはドキュメントでより効果的にコラボレーションできます：\n\n* コンテキスト内で直接コンテンツについて議論する。\n* 改善や修正を提案する。\n* ドキュメントを正確かつ最新の状態に保つ。\n* 知識と専門知識を共有する。\n\nこれらのアップデートにより、GitLab Wikiは直接のフィードバックとディスカッションを通じてプロジェクトと共に進化する生きたドキュメントとして活用できます。\n\n[ドキュメント](https://docs.gitlab.com/user/discussions/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16403)\n\n### **浅いクローニングによるワークスペースの高速起動**\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nワークスペースは、起動時間を短縮するために浅いクローニングを使用するようになりました。初期化中、GitLabは完全なGit履歴ではなく、最新のコミット履歴のみをダウンロードします。ワークスペース起動後、Gitはバックグラウンドで浅いクローンを完全なクローンに変換します。\n\nこの機能は新しいワークスペースすべてに自動適用され、設定は不要で、開発ワークフローに影響を与えません。\n\n[ドキュメント](https://docs.gitlab.com/user/workspace/#shallow-cloning)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/543982)\n\n### **Kubernetes 1.33サポート**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLabはKubernetesバージョン1.33に完全対応しました。アプリをKubernetesにデプロイする場合、接続クラスターを最新バージョンにアップグレードして、機能をすべて利用できます。\n\n詳細については、[GitLab機能でサポートされているKubernetesバージョン](https://docs.gitlab.com/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/538906)\n\n### **簡潔なDASTジョブ出力**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nGitLab 18.3では、動的解析セキュリティテストのジョブ出力が改善されました。\n\n改善されたジョブ出力は、スキャン結果の理解や、失敗のトラブルシューティングに役立つ、明確で整理された情報を提供します。\n\nジョブ出力の各セクションは簡潔で直感的であり、出力の下部にトラブルシューティングドキュメントへのリンクがあります。簡潔なジョブ出力を上書きするには、DAST設定で`DAST_FF_DIAGNOSTIC_JOB_OUTPUT: \"true\"`を設定します。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dast/browser/troubleshooting/#what-is-dast-doing)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/18342)\n\n### **ライセンス情報のユーザー定義ソース**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nユーザーは、ライセンス情報の優先ソース（GitLabライセンスデータベースまたはCycloneDX SBOMレポート）を選択できるようになりました。これにより、オープンソース依存関係のライセンス情報取得がより柔軟になります。ライセンス情報のソースを指定する場合は、[セキュリティ設定UI](https://docs.gitlab.com/user/application_security/detect/security_configuration/#with-the-ui)で選択できます。デフォルトでは、ライセンス情報のソースとしてSBOMデータを使用します。\n\n[ドキュメント\n](https://docs.gitlab.com/user/compliance/license_scanning_of_cyclonedx_files/#use-cyclonedx-report-as-a-source-of-license-information)[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/501662)\n\n### **脆弱性レポートでOWASP 2021によるグループ化**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nプロジェクトとグループの脆弱性レポートで、脆弱性をOWASP Top 10 2021カテゴリでグループ化できるようになりました。GitLab.comおよびGitLab Dedicatedインスタンスでのみ利用可能です。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerability_report/#advanced-vulnerability-management)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/532703)\n\n![脆弱性レポートでOWASP 2021によるグループ化](https://about.gitlab.com/images/18_3/group-by-owasp-2021-on-vulnerability-report.png)\n\n\n\n### **セキュリティポリシー監査イベント**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nGitLab Ultimateは、セキュリティポリシー管理のための包括的な監査イベントが利用できるようになり、各セキュリティポリシープロジェクト内でイベントが整理、一元化されます。\n\nセキュリティチームは次のことができるようになります：\n\n* 詳細なメタデータでポリシーのすべての変更を追跡する。\n* スキャンとパイプライン実行の失敗を含む、実施の失敗を監視する。\n* スキップされたスキャン実行とパイプライン実行パイプラインを監視する。\n* ポリシー違反でマージされたMRを含む、各プロジェクト内でのポリシー違反を検出する。\n* 制限を超えた場合にアラートを受け取る。\n* ポリシー設定エラーを検出する。\n* 大量処理向けストリーミング専用オプションを使用する。\n\n新しい監査イベントには以下が含まれます：\n\n* [security_policy_create](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_create.yml)\n* [security_policy_delete](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_delete.yml)\n* [security_policy_update](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_update.yml)\n* [security_policy_merge_request_merged_with_policy_violations](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_merge_request_merged_with_policy_violations.yml)\n* [security_policy_yaml_invalidated](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_yaml_invalidated.yml)\n* [security_policies_limit_exceeded](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_yaml_invalidated.yml)\n* [security_policy_violations_detected](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_violations_detected.yml)（ストリーミングのみ）\n* [security_policy_pipeline_failed](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_pipeline_failed.yml)（ストリーミングのみ）\n* [security_policy_pipeline_skipped](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/audit_events/types/security_policy_pipeline_skipped.yml)（ストリーミングのみ）\n* [merge_request_branch_bypassed_by_security_policy](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/audit_events/types/merge_request_branch_bypassed_by_security_policy.yml)\n\nこの機能強化により、ポリシーの変更、設定エラー、実施ギャップを把握できるようになり、セキュリティ体制が強化され、より迅速なインシデント対応と徹底的な監査機能が可能になります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15869)\n\n![セキュリティポリシー監査イベント](https://about.gitlab.com/images/18_3/policy-audit-events-example-image.png)\n\n\n\n### **サービスアカウントの追加メール設定オプション**\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nデフォルトでは、GitLabが新しいサービスアカウント用に自動的にメールアドレスを生成します。今回のアップデートにより、組織はUIでサービスアカウントにカスタムメールアドレスを設定できるようになりました。以前は、カスタムメール設定はサービスアカウントAPIを通じてのみ可能でしたが、この改善により、組織は通知を指定されたメールアドレスにより確実に配信できます。\n\n[ドキュメント](https://docs.gitlab.com/user/profile/service_accounts/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/537976)\n\n### **インスタンスレベルのコンプライアンスとポリシー管理（ベータ版）**\n\n> Self-Managed: Ultimate\n\nエンタープライズユーザーは、複数のトップレベルグループ全体でコンプライアンスフレームワークとセキュリティポリシーを管理したいと考えています。これは、インスタンス内のすべてのグループが次の場合によくあります：\n\n* 同じコンプライアンスフレームワークを共有している（例：グループ内のすべてのプロジェクトがISO 27001標準に準拠する必要がある）\n* 同様のポリシーを実施している（例：すべてのグループで同じパイプライン実行ポリシーを共有している）\n\nGitLab 18.3では、GitLab Self-Managedインスタンス向けにコンプライアンスとセキュリティポリシー管理がベータ版で利用可能になりました。単一のトップレベルグループからコンプライアンスフレームワークとセキュリティポリシーを作成、設定、割り当て、GitLab Self-Managedインスタンス全体の他のすべてのトップレベルグループに適用できます。\n\nコンプライアンスとセキュリティポリシーのトップレベルグループを使用することで、コンプライアンスフレームワークとセキュリティポリシーを管理および編集できる信頼できる単一の情報源が確立されます。グループ管理者は、これらのコンプライアンスフレームワークとセキュリティポリシーをそれらのグループ内のすべてのプロジェクトに適用できます。\n\n選択したトップレベルのコンプライアンスとセキュリティポリシーグループから主要なフレームワークとポリシーを管理することにより、GitLab Self-Managedインスタンス全体で主要なコンプライアンスとセキュリティ要件の管理、実施が簡素化されます。ただし、各グループは、固有の状況やワークフローに対処するために、独自のコンプライアンスフレームワークとセキュリティポリシーを作成する権限は維持されます。\n\nこの機能は、GitLab Self-Managed向けに提供されています。GitLab.comおよびGitLab Dedicatedでは、既に単一のトップレベルグループまたはネームスペース内でポリシーを一元的に管理可能です。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_frameworks/centralized_compliance_frameworks/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15864)\n\n### **SAML SSOのセッションタイムアウト属性のサポート**\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nGitLabは、アイデンティティプロバイダー（IdP）からのSAMLアサーションに含まれる`SessionNotOnOrAfter`属性を自動的に検出、適用するようになりました。この属性が存在する場合、GitLabはユーザーセッションをIdPによって指定された時刻に期限切れに設定し、組織全体で統一されたセッション管理を実現します。設定変更は不要で、 IdPが属性を提供すれば、GitLabが自動的に指定された有効期限を適用します。\n\n[ドキュメント](https://docs.gitlab.com/user/group/saml_sso/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/262074)\n\n### **SSHキーのセキュリティ警告**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLabは、ユーザーが弱いSSHキーをアップロードした際にUIにセキュリティ警告を表示するようになりました。この警告は、古いキータイプまたは不十分なビット長（2048ビット未満）のキーに対して表示されます。この変更により、SSHキーのセキュリティベストプラクティスをユーザーに周知し、より強固な暗号キーの利用を促進します。\n\n[ドキュメント](https://docs.gitlab.com/user/ssh/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/432624)\n\n### **GitLab Duo Self-Hostedで使用可能なモデルの追加**\n\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duo Enterpriseをご利用のGitLab Self-Managedのお客様は、GitLab Duo Self-HostedでAnthropic Claude 4を利用できるようになりました。Claude 4はAWS Bedrockでサポートされています。また、オープンソースのOpenAI GPT OSS 20Bと120Bが実験的モデルとして追加され、vLLM、Azure OpenAI、AWS Bedrockで利用可能です。これらのモデルをGitLab Duo Self-Hostedで使用することに関するフィードバックは、[イシュー523918](https://gitlab.com/gitlab-org/gitlab/-/issues/523918)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/560016)\n\n### **マイワークのグループ向け新しいナビゲーション体験**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\n**マイワーク**のグループ概要を大幅に改善しました。これにより、グループの発見とアクセス方法が効率化されます。新しいタブ付きインターフェースでは、**メンバー**タブでアクセス可能なグループを包括的に表示し、**無効**タブで削除保留中のグループを確認できます。また、適切な権限を持つユーザー向けにリスト表示で**編集**と**削除**アクションを追加し、グループ管理を効率化しました。これらの改善により、重要なグループの検索と管理がより容易になります。\n\n新しいナビゲーションシステムの利用体験について、[エピック18401](https://gitlab.com/groups/gitlab-org/-/epics/18401)にご意見をお寄せください。フィードバックをお待ちしております！\n\n[ドキュメント](https://docs.gitlab.com/user/group/#view-groups)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/502487)\n\n![マイワークのグループ向け新しいナビゲーション体験](https://about.gitlab.com/images/18_3/tenant_scale_your_work_groups_update.png)\n\n\n\n### **GitLab Pagesサイトの一意のドメインのデフォルトを制御**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\n管理者は、新しいGitLab Pagesサイトの一意のドメインに関するデフォルト動作を設定できるようになりました。デフォルトでは、新しいPagesサイトは、サイト間のCookie共有を防ぐために一意のドメインURL（例：`my-project-1a2b3c.example.com`）を使用します。\n\nインスタンス向けのこの新しい設定により、新しいPagesサイトをデフォルトでパスベースのURL（例：`my-namespace.example.com/my-project`）を使用するように設定できます。これにより、組織はGitLab Pagesの動作を自社のワークフローやセキュリティ要件に合わせることができます。\n\nユーザーは個々のプロジェクトでこの設定を上書きでき、既存のPagesサイトは影響を受けません。\n\n[ドキュメント\n](https://docs.gitlab.com/administration/pages/#disable-unique-domains-by-default)[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/555559)\n\n### **OAuthアプリでSSO認証をサポート**\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nOAuthアプリケーションが組織のシングルサインオン要件とシームレスに統合できるようになりました。以前は、ユーザーは最初にGitLabで、次にSSOで認証するという2段階認証が必要で、不要な手間と複雑さが生じていました。\n\n現在、OAuthアプリケーションは、認証リクエストでパラメーターを指定し、必要に応じてSSO認証を自動的に開始できます。これにより以下が提供されます：\n\n* ユーザー向けの統一された認証体験\n* 組織のSSOポリシーへの自動準拠\n* すべてのGitLab統合全体で一貫したセキュリティ\n* パラメーター追加だけのデベロッパー向けの簡単な実装\n\nOAuth統合は、セキュリティを維持しながら煩雑な認証ワークフローを排除し、SSOポリシーを自動的に適用するようになりました。\n\n[ドキュメント\n](https://docs.gitlab.com/api/oauth2/#authorization-code-flow)[イシュー\n](https://gitlab.com/gitlab-org/gitlab/-/issues/461212)[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/326288)\n\n### **GitLab Runner 18.3**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Runner 18.3も本日リリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\nバグ修正：\n\n* [GitLab 18.2.0では、Runnerはサブディレクトリファイルをキャッシュキーとして使用してジョブキャッシュをプルできません](https://gitlab.com/gitlab-org/gitlab/-/issues/556464)\n* [Docker executorがジョブの開始に断続的に失敗し、ユーザー名またはパスワードが正しくないというエラーメッセージを返す](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38707)\n* [`none`と`empty`のGit戦略間での`*_get_sources`フックの使用における不整合](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38703)\n* [非OLMマニフェストでデプロイされたOperatorが間違ったデフォルトイメージを想定する](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/228)\n* [CRに`app.kubernetes.io/instance`ラベルがある場合、Operatorが間違った名前でConfigMapを作成する](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/183)\n* [OpenShift 4.9でOperator 1.10.0が`gitlab-runner`ネームスペースでランナーConfigMapの作成とポッドの起動に失敗する](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/138)\n\n新機能：\n\n* [GitLab Runner Operatorがランナーマネージャーポッドアノテーションをサポートするようになりました](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/245)\n* [GitLab Runner OperatorがOpenShift 4.19をサポートするようになりました](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/253)\n\nすべての変更の一覧は、GitLab Runnerの[CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-3-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### **GitLab管理のOpenTofuおよびTerraform状態用の新しいCLIコマンド**\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab CLI（`glab`）に、GitLab管理の`OpenTofu`および`Terraform`状態を支援するための新しいトップレベルコマンド`opentofu`が含まれるようになりました。`opentofu`コマンドは、`terraform`およびtfコマンドのエイリアスとしても使用できます。\n\n以下のコマンドが追加されました：\n\n* `glab opentofu init`：状態バックエンドをローカルで初期化します\n* `glab opentofu state list`：プロジェクト内のすべての状態を一覧表示します\n* `glab opentofu state download`：最新の状態または特定のバージョンをダウンロードします\n* `glab opentofu state delete`：状態全体または特定のバージョンを削除します\n* `glab opentofu state lock`：状態をロックします\n* `glab opentofu state unlock`：状態のロックを解除します\n\n`opentofu`コマンドで状態を管理するには、`glab` 1.66以降が必要です。\n\n[ドキュメント](https://docs.gitlab.com/user/infrastructure/iac/terraform_state)\\\n[イシュー](https://gitlab.com/gitlab-org/cli/-/issues/7954)\n\n### **依存関係スキャンアナライザーのファイル場所情報の改善**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n依存関係をそのソースまで追跡できることは、特に脆弱性の修正にとって重要です。以前は、依存関係スキャンアナライザーが期限切れで削除されるジョブアーティファクトにリンクすることがあり、依存関係のソースまで追跡することが困難でした。本リリースで、依存関係スキャンアナライザーが、依存関係を導入したプロジェクトファイルにリンクできるようになりました。このオプションを有効にすると、依存関係リストと脆弱性レポートのリンクが確実に利用可能になります。ユーザーは、依存関係スキャンジョブで`DS_FF_LINK_COMPONENTS_TO_GIT_FILES=true`を設定することで、この機能を有効にできます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/#customizing-behavior-with-the-cicd-template)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/537716)\n\n### **API経由でパイプライン実行ポリシーにCI/CD設定へのアクセスを付与**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nプロジェクトREST APIを使用して、新しい`spp_repository_pipeline_access`フィールドでセキュリティポリシープロジェクトの**パイプライン実行ポリシー**設定をプログラムで有効または無効にできるようになりました。以前は、この設定はGitLab UIでのみ管理できました。この機能強化により、次のことができるようになりました：\n\n* 現在の**パイプライン実行ポリシー**ステータスを`GET`する。\n* 設定をプログラムで有効または無効にするために`PUT`する。\n\nこの改善により、大規模でセキュリティポリシーを管理するチームにとって、より優れた自動化と統合ワークフローが実現されます。\n\n[ドキュメント](https://docs.gitlab.com/api/projects/#edit-a-project)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/524124)\n\n### **スキャン実行ポリシーテンプレート**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nスキャン実行ポリシーテンプレートは、一般的なユースケースに基づいてスキャン実行ポリシーを素早く作成するのに役立ちます。以下の3つのテンプレートから選択できます：\n\n* マージリクエストセキュリティ\n* スケジュールされたスキャン\n* リリースセキュリティ\n\nテンプレートを選択したら、そのテンプレートで有効にするGitLabセキュリティスキャンを選択して、すぐに開始します。より高度なユースケースがある場合は、カスタム設定に切り替えて、特定のブランチパターン、パイプラインソースなどでポリシーを拡張できます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/#scan-execution-policy-editor)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11919)\n\n![スキャン実行ポリシーテンプレート](https://about.gitlab.com/images/18_3/scan-execution-policy-templates.png)\n\n\n\n### **承認ポリシーのサービスアカウントとアクセストークンの例外**\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n新しい**サービスアカウントとアクセストークンの例外**機能により、必要に応じてマージリクエスト承認ポリシーをバイパスできる特定のサービスアカウントとアクセストークンを指定できるようになりました。これにより、セキュリティコントロールを維持しながら、既知の自動化の摩擦を解消します。\n\n**主要な機能：**\n\n* 自動化ワークフローサポート：CI/CDパイプライン、プルミラーリング、自動バージョン更新のために承認要件をバイパスするように、特定のサービスアカウント、ボットユーザー、グループアクセストークン、プロジェクトアクセストークンを設定します。サービスアカウントは、人間のユーザーに対する制限を維持しながら、承認されたトークンを使用して保護されたブランチに直接プッシュできます。\n* 緊急アクセスと監査：重要なインシデントのブレークグラスシナリオを有効にし、包括的な監査証跡を提供します。すべてのバイパスイベントは、コンテキストと理由を含む詳細な監査ログを生成し、停止中またはセキュリティ修正時の迅速な対応を可能にしながら、コンプライアンス要件をサポートします。\n* GitOps統合：リポジトリミラーリング、外部CIシステム（Jenkins、CloudBees）、自動変更ログ生成、GitFlowリリースプロセスなど、一般的な自動化の課題を解決します。サービスアカウントは、特定のプロジェクトとブランチにスコープされたトークンベースのアクセスで必要最小限の権限を受け取ります。\n\nこの機能強化により、ガバナンスコントロールを維持しながら、現代のDevOps自動化のニーズに対して厳格なセキュリティポリシーの適用が維持され、カスタムの回避策が不要になります。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/#access-token-and-service-account-exceptions)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/18112)\n\n![承認ポリシーのサービスアカウントとアクセストークンの例外](https://about.gitlab.com/images/18_3/access-token-exception-policies.png)\n\n\n\n### **エンタープライズユーザーの機能強化**\n\n> SaaS: Premium、Ultimate\n\nGitLab 18.3では、ユーザープライバシーとライフサイクル管理に対する組織の制御を強化するエンタープライズユーザー機能強化が導入されます。\n\nグループオーナーは、ユーザーAPIを使用してネームスペース内のエンタープライズユーザーを削除できるようになりました。この破壊的なアクションは、ユーザーの貢献のリンクを解除し、それらをシステム全体のGhostユーザーに関連付けます。これらのオプションは、自動SCIMインポートで誤って作成されたユーザーをクリーンアップする場合や、ユーザー名とメールを再利用する必要があるフェデレーション環境を管理したりする場合に特に有用です。\n\nさらに、組織はエンタープライズユーザーのメールをユーザープロファイルで非表示にできるようになり、すべてのエンタープライズユーザーに対してより広範なメールプライバシーの実施を提供します。\n\n[ドキュメント](https://docs.gitlab.com/user/enterprise_user/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/9262)\n\n### **強化された管理エリアプロジェクトリスト**\n\n> Self-Managed: Free、Premium、Ultimate\n\nより一貫した体験をGitLab管理者に提供するために、**管理者エリア**プロジェクトリストをアップグレードしました：\n\n* 削除保護の遅延：プロジェクトの削除は、GitLab全体で使用されているのと同じ安全な削除フローに従うようになり、偶発的なデータ損失を防ぎます。\n* より高速なインタラクション：ページのリロードなしでプロジェクトのフィルター、並べ替え、ページ分割が可能になり、より応答性の高い体験を提供します。\n* 一貫したインターフェース：プロジェクトリストは、GitLab全体の他のプロジェクトリストの外観と動作に統一されました。\n\nこのアップデートにより、管理者の体験がGitLabデザイン標準に沿ったものになり、データを保護するための重要な安全機能が追加されます。プロジェクト管理の今後の機能強化は、プラットフォーム全体のすべてのプロジェクトリストに自動的に反映されます。\n\n[ドキュメント](https://docs.gitlab.com/administration/admin_area/#administering-projects)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17782)\n\n## **実験的機能**\n\n### **GitLabモデルコンテキストプロトコルサーバー**\n\nGitLabモデルコンテキストプロトコル（MCP）サーバーにより、AIアプリケーションがGitLabインスタンスに安全に接続できるようになります。MCPサーバーを設定すると、Claude Desktop、Cursor、その他のMCP対応アプリケーションなどのAIアシスタントが、GitLabデータにアクセスし、ユーザーに代わってアクションを実行できます。このリリースには、計画イシュー、マージリクエスト、CIパイプラインジョブと連携するツールが含まれており、今後のマイルストーンでサポートツールを拡張していく予定です。\n\nMCPサーバーは、AIツールに対して標準化された方法を提供します：\n\n* GitLabプロジェクト情報にアクセスする\n* イシューとマージリクエストデータを取得する\n* GitLab APIと安全に連携する\n* AIアシスタントを通じてGitLab固有の操作を実行する\n\nGitLabのMCPサーバーはリモートで実行されるため、ローカルにインストールまたは実行する必要はありません。アップデートは自動的に適用されます。\n\n実験的機能を有効にする方法を含む詳細については、[GitLab MCPサーバーのドキュメント](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server)をご覧ください。\n\n### **GitLab Duo CLIエージェント（ベータ版）**\n\nGitLab Duo CLIエージェントを素早く作成し、Claude Code、OpenAI Codex、Amazon Q、Google Gemini CLI、OpenCode AIコーディングアシスタントと統合できるようになりました。このベータ機能は、すべてのGitLab Duo Enterpriseのお客様が利用でき、選択したプロバイダー用に独自のAPIキー（BYOK）を持ち込む必要があります。\n\nイシュー、エピック、またはマージリクエストで、作成したサービスアカウントユーザーをタグ付けすることで、CLIエージェントにタスクの完了を依頼できます。タグ付けされると、そのエージェントに接続された統合コーディングアシスタントがトリガーされ、自動CI/CDパイプラインが実行され、タスクが完了します。マージ可能な変更またはインラインコメントとして応答を受け取ります。\n\nこの仕組みによりブランチ保護と承認ルールを尊重しながら、セキュリティ、コスト管理、インフラストラクチャガバナンスに関する組織のニーズを満たしつつ、CLIエージェントの力をGitLabに直接もたらします。今後のイテレーションでは、GitLab管理のAPIキーを使用してCLIエージェントをコーディングアシスタントとネイティブに統合できるようになります。\n\nGitLab Duo CLIエージェントの使用に関するフィードバックは、[イシュー557820](https://gitlab.com/gitlab-org/gitlab/-/issues/557820)をご覧ください。\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n\n18.3で提供されたすべてのバグ修正、パフォーマンスの強化、UI改善を確認するには、以下のリンクをクリックしてください。\n\n* [バグ修正](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=type%3A%3Abug&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.3)\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.3)\n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.3)\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](\u003C>)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](\u003C>)してください。[](\u003C>)[](\u003C>)\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](\u003C>)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](\u003C>)してください。\n\n* [cert-manager Helmチャートのアップデート](https://docs.gitlab.com/ee/update/deprecations.html#cert-manager-helm-chart-update)[](\u003C>)[](\u003C>)\n\n### 変更履歴\n\n変更内容をすべて表示するには、次のページから変更履歴を確認してください。\n\n* [GitLab](\u003C>)\n* [GitLab Runner](\u003C>)\n* [VS CodeのGitLab Workflow](\u003C>)\n* [GitLab CLI](\u003C>)\n\n### インストール\n\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](\u003C>)をご覧ください。\n\n### 更新事項\n\n[更新ページ](\u003C>)をご覧ください。\n\n### ご不明な点がある場合\n\nご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、[GitLabフォーラム](\u003C>)にアクセスして質問を投稿してください。\n\n### GitLabサブスクリプションプラン\n\n* [Free](\u003C>)\n  ユーザー向けの永久無料機能を提供\n* [Premium](\u003C>)\n  チームの生産性と調整を強化\n* [Ultimate](\u003C>)\n  組織全体のセキュリティ、コンプライアンス、プランニングに対応\n\nGitLabのすべての機能を[無料](\u003C>)でお試しいただけます。\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](\u003C>)\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\n* [GitLab 18.2](\u003C>)\n* [GitLab 18.1](\u003C>)\n* [GitLab 18.0](\u003C>)\n* [GitLab 17.11](\u003C>)\n* [GitLab 17.10](\u003C>)\n* [GitLab 17.9](\u003C>)\n* [GitLab 17.8](\u003C>)\n* [GitLab 17.7](\u003C>)\n* [GitLab 17.6](\u003C>)\n* [GitLab 17.5](\u003C>)\n* [GitLab 17.4](\u003C>)\n* [GitLab 17.3](\u003C>)\n* [GitLab 17.2](\u003C>)\n* [GitLab 17.1](\u003C>)\n* [GitLab 16.11](\u003C>)",[905],"2025-08-25","2025-08-22","GitLab 18.3 リリース",[1010,838,765,109],"GitLab 18.3でリリースした最新機能を公開します。",{"featured":91,"template":800,"slug":1087},"gitlab-18-03-release",{"content":1089,"config":1098},{"heroImage":1090,"body":1091,"authors":1092,"updatedDate":1093,"date":1094,"title":1095,"tags":1096,"description":1097,"category":765},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817693/gr3miapxfam57ksgivgi.png","本ブログは、[GitLab 18.2 Release](https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n## IDE向けGitLab Duoエージェントプラットフォーム（ベータ版）とイシュー・タスク用カスタムワークフローステータスを追加したGitLab 18.2をリリース\n\nこのたび、GitLab 18.2のリリースを発表しました。このリリースでは、IDE向けGitLab Duoエージェントプラットフォーム（ベータ版）、イシュー・タスク用カスタムワークフローステータス、新しくなったマージリクエストのホーム画面、セキュリティを強化する不変コンテナタグなど、さまざまな機能が追加されました。\n\nこれらの機能は、今回のリリースに含まれる30以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 18.2には、GitLabコミュニティのユーザーから152件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースもユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ](https://about.gitlab.com/upcoming-releases/)をご覧ください。\n\n[GitLab 18.2のリリースでは、IDE](http://twitter.com/share?text=GitLab+18.2%E3%81%AE%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%A7%E3%81%AF%E3%80%81IDE%E5%90%91%E3%81%91GitLab+Duo%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%EF%BC%88%E3%83%99%E3%83%BC%E3%82%BF%E7%89%88%EF%BC%89%E3%81%A8%E3%80%81%E3%82%A4%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%BB%E3%82%BF%E3%82%B9%E3%82%AF%E7%94%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%81%8C%E8%BF%BD%E5%8A%A0%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82&url=https://about.gitlab.com/ja-jp/blog/gitlab-18-1-release/&hashtags=)[向けGitLab Duoエージェントプラットフォーム（ベータ版）と、イシュー・タスク用カスタムワークフローステータスが追加されました。クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+18.2%E3%81%AE%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%A7%E3%81%AF%E3%80%81IDE%E5%90%91%E3%81%91GitLab+Duo%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%EF%BC%88%E3%83%99%E3%83%BC%E3%82%BF%E7%89%88%EF%BC%89%E3%81%A8%E3%80%81%E3%82%A4%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%BB%E3%82%BF%E3%82%B9%E3%82%AF%E7%94%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%81%8C%E8%BF%BD%E5%8A%A0%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82&url=https://about.gitlab.com/ja-jp/blog/gitlab-18-1-release/&hashtags=)\n\n## 今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は[](https://gitlab.com/karras)[](https://gitlab.com/chaitanyason9)[Markus Siebert](https://gitlab.com/m-s-db)さんです\n\n\u003Cimg src=\"https://about.gitlab.com/images/notable-contributor-logo.svg\">\n\nDB Systel GmbHのプラットフォームエンジニアであるMarkus Siebertさんは、GitLab CI/CDにネイティブなAWS Secrets Managerサポートを導入するコミュニティの取り組みを主導しています。これは、パイプラインでの安全なシークレット管理という重要なエンタープライズニーズに応えるものです。わずか6週間で172件もの活動を記録し、「[AWS Secrets Managerからのシークレット取得機能の追加](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/5587)」「[AWS SSM ParameterStore用GitLab CI設定エントリの追加](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/191803)」「[AWS Secrets Managerのドキュメント作成](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/192378)」など、複数のマージリクエストを通じてAWS Secrets ManagerとAWS Systems Manager Parameter Storeの両方のサポート実装に精力的に取り組んでいます。\n\nMarkusさんを推薦したGitLabの[Aditya Tiwari](https://gitlab.com/atiwari71)（Secureチームのシニアバックエンドエンジニア）は次のように述べています。「Markusさんの取り組みにより、AWS環境を利用する GitLabユーザーは、サードパーティツールやカスタムスクリプトに頼ることなく、CI/CDシークレットを安全に管理できるようになりました。これは、AWSサービスを標準化しているエンタープライズユーザーにとって特に価値のある機能です。」\n\n初期実装からドキュメント作成まで、この機能を完成させようとするMarkusさんの献身的な姿勢、そしてフィードバックに基づいてマージリクエストを継続的に改善する取り組みは、コミュニティコントリビューションの理想的な例です。また、AWS ユーザーのためにGitLabをより良いものにするコミュニティ主導開発の力を示しています。\n\nこのコントリビュートはGitLab共同開発プログラムを通じて実現されました。\n\nこの場を借りて、GitLabにコントリビュートしてくれたMarkusさんに感謝します！\n\n## GitLab 18.2でリリースされた主な改善点\n\n### IDEでGitLab Duoエージェントプラットフォームが利用可能に（ベータ版）\n\n> SaaS: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise\n\nGitLab Duoエージェントプラットフォームを使用して、VS CodeとJetBrains IDEでAgentic Chatとエージェントフローを直接利用できるようになりました。コードベースやGitLabプロジェクトと自然な会話形式でやりとりできます。\n\nAgentic Chatは、ファイルの作成・編集、パターンマッチングやgrepを使用したコードベース全体の検索、コードに関する質問への即座の回答など、素早く会話的なタスクに対応しています。\n\nAgent Flowは、より大規模な実装や包括的な計画を担当し、概念からアーキテクチャまでの高レベルなアイデアを実現しながら、イシュー、マージリクエスト、コミット、CI/CDパイプライン、セキュリティ脆弱性などのGitLabリソースにアクセスします。\n\nどちらの機能も、ドキュメント、コードパターン、プロジェクト探索のための高度な検索機能を備えており、簡単な編集から複雑なプロジェクト分析まで、様々なタスクの実行をサポートします。\n\nこのプラットフォームは、Model Context Protocol（MCP）にも対応しており、外部のデータソースやツールへの接続が可能で、AI機能がGitLab上の情報だけでなく外部のコンテキストも活用できます。\n\n利用を開始するには、[GitLab Duoエージェントプラットフォームに関するドキュメント](https://docs.gitlab.com/user/duo_agent_platform/)、[VS Codeセットアップガイド](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-vs-code)、[JetBrainsセットアップガイド](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-jetbrains-ides)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/user/duo_agent_platform/)\\\n[イシュー](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/issues/1217)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/14137)\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/GPewPbqlFDE?si=C7LVy7tWpRGyZT7b\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### イシュー・タスク用カスタムワークフローステータス\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nステータス設定が柔軟になったことで、これまでの「オープン／クローズ」だけの単純な管理方法に代わり、チームの実際のワークフローステージに沿って作業アイテムを追跡できるようになりました。\n\nチームのプロセスを正確に反映したカスタムステータスを定義できるようになったことで、ラベルに頼る必要がなくなりました。ステータスを自由に設定することで、次のことが可能になります。\n\n* **カスタムワークフローの定義**：チームの実際のプロセスに合わせたワークフローを作成\n* **ワークフローラベルの置き換え**：ワークフローラベルを検索、更新、レポートしやすい適切なステータスに変更\n* **完了結果の明確化**：「完了」または「キャンセル」を使用して、単にイシューをクローズするだけでなく、完了の結果を明確に表示\n* **正確なフィルタリングとレポート**：作業アイテムのステータスを正確に絞り込んでレポートし、プロジェクトの状況をより的確に把握\n* **イシューボードでのステータス利用**：イシューが列間を移動した際にステータスを自動更新\n* **ステータスの一括更新**：複数の作業アイテムのステータスを一括更新して効率的に管理\n* **依存関係の追跡**： リンクされた作業アイテムのステータスを可視化\n\nカスタムワークフローステータスは、**コメントでのクイックアクション**にも対応し、GitLabのオープン／クローズシステムと自動で同期します。\n\n本機能の改善に向けたご意見やご提案を、ぜひ[フィードバックイシュー](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/35235)よりお寄せください。\n\n[](\u003C>)\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/oxN95MSo6UU?si=iYGB7gF9LSsRULhk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### 新しくなったマージリクエストのホーム画面\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\n複数のプロジェクトで、作成者とレビュアーの両方の立場で多数のマージリクエストを同時に対応していると、コードレビューの管理は非常に大変になります。\n\nマージリクエストのホーム画面が新しくなりました。早急に対応が必要な作業がわかるようスマートに優先順位を付け、以下の2つの表示モードを使用してレビュー作業の進め方を示してくれます。\n\n* **ワークフロービュー**：マージリクエストをレビューのステータスごとに整理し、コードレビューの各ステージに応じて作業をグループ化\n* **ロールビュー**：自分が作成者かレビュアーかによってマージリクエストをグループ化し、担当作業の範囲を明確に分離\n\n**有効**タブには対応が必要なマージリクエストが表示され、**マージ済み**タブには最近完了した作業が表示されます。また、**検索**では包括的なフィルタ機能を使用できます。\n\nまた、新しいホーム画面では、自分が作成したマージリクエストと割り当てられたマージリクエストの両方がまとめて表示されるため、可視性がさらに向上し、担当作業の見落としを防ぐことができます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/homepage/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13448)\n\n![新しくなったマージリクエストのホーム画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817030/ehswaenxkydlwbox0ip3.png)\n\n### 不変コンテナタグでセキュリティを強化\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンテナレジストリは、現代のDevSecOpsチームにとって重要なインフラストラクチャです。しかし、保護されたコンテナタグがあっても、組織には依然として課題があります。それは、タグが作成された後でも、十分な権限を持つユーザーであれば変更できてしまうという点です。これは、本番環境の安定性を特定のタグ付きコンテナイメージに依存しているチームにとってリスクとなります。権限を持つユーザーによる変更であっても、意図しない変更が発生したり、デプロイの整合性が損なわれたりする可能性があります。\n\n不変コンテナタグを使用することで、コンテナイメージを意図しない変更から保護できます。不変ルールに一致するタグが作成されると、そのコンテナイメージは誰にも変更できなくなります。今後は以下のことが可能になります。\n\n* 保護ルールおよび不変ルールを合わせて、1プロジェクトあたり最大5件までの保護ルールをRE2正規表現パターンを用いて作成する\n* latest、セマンティックバージョン（例：v1.0.0）、リリース候補といった重要なタグをあらゆる変更から保護する\n* 不変タグがクリーンアップポリシーの対象から自動的に除外されるようにする\n\n不変コンテナタグを使用するには、次世代コンテナレジストリが必要です。このレジストリは、GitLab.comではデフォルトで有効になっています。GitLab Self-Managedインスタンスで不変コンテナタグを使用するには、[メタデータデータベース](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/)を有効にする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/user/packages/container_registry/immutable_container_tags/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15139)[](https://gitlab.com/groups/gitlab-org/-/epics/15139)\n\n![不変コンテナタグでセキュリティを強化](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817030/xfcqsdjotx4acx96nu5b.png)\n\n### PremiumおよびUltimateにおけるGitLab Duoの機能をグループ・プロジェクト単位で制御\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nGitLab PremiumおよびUltimateユーザーは、グループとプロジェクトでIDE内のコード提案とGitLab Duo Chatの利用可否を変更できるようになりました。以前は、インスタンスまたはトップレベルグループでのみ利用可否を変更できました。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/551895)\n\n![PremiumおよびUltimateにおけるGitLab Duoの機能をグループ・プロジェクト単位で制御](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817030/khiyfhuutomokxjkgsul.png)\n\n### 新しいグループ概要コンプライアンスダッシュボード\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスセンターは、コンプライアンスチームがコンプライアンスステータスのレポート、違反レポート、コンプライアンスフレームワークの管理などを一括して行える場所です。\n\n新たに導入されたグループ概要コンプライアンスダッシュボードは、グループ内のすべてのプロジェクトに関するコンプライアンス情報を集約してコンプライアンスマネージャーに提供します。この最初のイテレーションでは、以下の情報が表示されます。\n\n* 特定のコンプライアンスフレームワークの対象となっているプロジェクトの割合\n* グループ内すべてのプロジェクトで失敗した要求事項の割合\n* グループ内すべてのプロジェクトで失敗した制御の割合\n* 「注意」が必要な特定のフレームワーク\n\nこの新しいグループ概要により、コンプライアンスマネージャーは、コンプライアンス対応状況の明確な全体像を一元的な画面で把握できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_overview_dashboard/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13909)\n\n![新しいグループ概要コンプライアンスダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817030/rttcgovqszvnwqgqw1z5.png)\n\n### インスタンス全体で利用可能なワークスペースKubernetesエージェント\n\n> Self-Managed: Premium、Ultimate\n\nGitLab管理者は、インスタンスレベルでワークスペースKubernetesエージェントをマッピングできるようになりました。これにより、ユーザーはそのインスタンスに含まれるどのグループやプロジェクトからでも、ワークスペースを作成できるようになりました。\n\n組織はワークスペースKubernetesエージェントを一度プロビジョニングするだけで、インスタンス全体の現在および将来のすべてのプロジェクトからそのエージェントにアクセスできるようになり、ワークスペースのスケーラビリティが大幅に向上します。\n\n[ドキュメント](https://docs.gitlab.com/user/workspace/gitlab_agent_configuration/#allow-a-cluster-agent-for-workspaces-on-the-instance)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16485)\n\n![インスタンス全体で利用可能なワークスペースKubernetesエージェント](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817031/if68jfrt7op0tqnsb2co.png)\n\n### セキュリティレポートのPDFエクスポートがダウンロード可能に\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n脆弱性管理の状況や進捗を他の関係者と共有するために、各プロジェクトまたはグループのセキュリティダッシュボードをPDFドキュメントとしてエクスポートできるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/security_dashboard/#exporting)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16989)\n\n![セキュリティレポートのPDFエクスポートがダウンロード可能に](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817035/xsuirbb1qrpnkamx9a9o.png)\n\n### 一元的なセキュリティポリシー管理（ベータ版）\n\n> Self-Managed: Ultimate\n\nコンプライアンスが重要となる大規模な組織では、複数のプロジェクトやグループにポリシーが分散していることが多く、チームはその断片化されたポリシーの管理に苦労することがあります。ポリシーが一元的に可視化されていない状態では、ポリシーを一貫して適用するのに時間がかかり、コンプライアンスリスクの増大にもつながります。\n\n一元的なセキュリティポリシー管理は、GitLab組織全体にわたってセキュリティポリシーを作成、管理、適用するための統一されたアプローチを導入するものであり、指定された単一のコンプライアンスおよびセキュリティポリシー（CSP）グループを通じて実現されます。これにより、セキュリティチームは以下のことを行えるようになります。\n\n* **一度の定義でポリシーを全体に適用**：CSPグループを通じてインスタンス全体に適用されるセキュリティポリシーを一度作成し、すべてのグループとプロジェクトに対して自動的に適用\n* **事業部単位のポリシーを設定**：トップレベルグループは、CSPグループから組織全体のポリシーを継承しつつ、独自のポリシーセットを設定可能\n* **最小権限の原則を遵守**：インスタンス全体に適用される中央ポリシー管理レイヤーを確立\n\nこのベータ版リリースでは、一元的なポリシー管理のための基盤となるフレームワークを確立し、グループ、プロジェクト、またはインスタンス単位で設定可能なすべての既存のセキュリティポリシータイプに対応しています。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/centralized_security_policy_management/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17392)\n\n![一元的なセキュリティポリシー管理（ベータ版）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817030/jombwhyuvqsif4k7kjvn.png)\n\n## GitLab 18.2リリースに含まれるその他の改善点\n\n### 管理者がユーザーの確認なしでコントリビュートを再アサイン可能に\n\n> Self-Managed: Free、Premium、Ultimate\n\n管理者は、プレースホルダユーザーからアクティブユーザーへのコントリビュートの再アサインを、ユーザーの確認なしで実行できるようになりました。この機能は、再アサインの承認メールをユーザーが確認しないことでプロセスが停滞してしまうという、大規模組織が抱える重要な課題を解決します。\n\nユーザーの代理操作が有効になっているGitLabインスタンスでは、管理者はユーザー管理のワークフローを効率化しつつ、データの整合性を維持することができます。再アサイン完了後には、ユーザーに通知メールが送信されるため、プロセス全体における透明性も確保されます。\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/import_and_export_settings/#skip-confirmation-when-reassigning-placeholder-users)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/523259)\n\n### チームメンバーにエピックを割り当て\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n個人へのエピックの割り当てが可能になり、戦略的イニシアチブの責任者が明確になりました。エピックに担当者を設定することで、ポートフォリオレベルで誰が責任を持つかが明確になり、迅速な意思決定と長期目標への明確な責任体制を構築できます。チームは、エピックの進捗状況、依存関係、スコープの変更について、誰に連絡すればよいかをすぐに把握できます。\n\n[ドキュメント](https://docs.gitlab.com/user/group/epics/manage_epics/#assignees)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/4231) \n\n![チームメンバーにエピックを割り当て](https://about.gitlab.com/images/18_2/epic_assignees.png)\n\n### エピックの表示設定\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n作業アイテムの一覧を表示する際に、どのメタデータを表示するかを自由に選べるようになり、最も重要な情報に集中しやすくなりました。\n\nこれまでは、すべてのメタデータフィールドが常に表示されていたため、作業アイテムを確認する際に情報が多すぎて把握しにくい状況でした。今回の改善により、担当者、ラベル、日付、マイルストーンといった特定のフィールドのオン／オフを切り替えて、表示内容をカスタマイズできるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/group/epics/manage_epics/#configure-epic-display-preferences)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/393559) \n\n![エピックの表示設定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753246094/nyfmmdweksyndjdisfp4.png)\n\n### GLQLビューでの並べ替えとページネーション\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\n今回のリリースでは、GLQLビューの並べ替え機能とページネーション機能が強化され、大規模なデータセットでの作業がより簡単になりました。\n\n期限、ヘルスステータス、人気度などの主要なフィールドで並び替えできるようになり、最も関連性の高い項目をすばやく見つけられます。新しい「さらに読み込む」形式のページネーションシステムにより、ページ全体に表示されていた大量の結果が、必要な分だけを段階的に読み込めるようになり、データの管理がしやすくなりました。\n\nこうした改善により、チームは複雑なプロジェクトデータを効率的に扱い、その時々で最も重要な情報に集中できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/user/glql/#presentation-syntax)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/502701)\n\n### GitLab Runner 18.2\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Runner 18.2も本日リリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\nバグ修正：\n\n* [GitLab Runner 18.1.0へのアップグレード後、FIPSモードでRunnerが失敗する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38890)\n* [FF_USE_DUMB_INIT_WITH_KUBERNETES_EXECUTORでジョブポッドを起動できない](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/241)\n* [GitLab Runner（FIPSモード）でubi-fipsイメージがデフォルトのイメージフレーバーとして使用されていない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38273)\n* [GitLabメンテナンスモードを無効にした後、Runnerが長時間オフラインのままになる](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29181)\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴で確認できます](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-2-stable/CHANGELOG.md)。\n\n[ドキュメント](https://docs.gitlab.com/runner/)\n\n### コンテナスキャンにおけるマルチアーキテクチャコンテナイメージのサポート\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンテナスキャンにLinux Arm64コンテナイメージバリアントが追加されました。これにより、Linux Arm64ランナー上で実行する際にアナライザーがエミュレーションなしで動作するため、分析速度が向上します。さらに、`TRIVY_PLATFORM`環境変数にスキャンしたいプラットフォームを設定することで、マルチアーキテクチャイメージをスキャンできるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/container_scanning/#available-cicd-variables)\\\n[イシュー ](https://gitlab.com/gitlab-org/gitlab/-/issues/543144)\n\n### コンテナスキャンにおけるアーカイブファイルのサポート強化\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab 18.2では、コンテナスキャンにおけるアーカイブファイルスキャンのサポートが強化されました。特定のパッケージに含まれる脆弱性が複数のイメージで検出された場合、スキャンされた各イメージに対して該当する脆弱性が表示されるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/container_scanning/#scanning-archive-formats)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/501077)\n\n### JavaScriptで静的到達可能性がサポートされるように\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンポジション解析で、JavaScriptライブラリの静的到達可能性がサポートされるようになりました。トリアージや修正に関する意思決定を行う上で、静的到達可能性機能によって生成されたデータを活用できます。また、静的な到達性データをEPSS、KEV、およびCVSS（共通脆弱性評価システム）のスコアと一緒に使用すれば、より焦点を絞って脆弱性を確認することも可能です。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_scanning/static_reachability/#supported-languages-and-package-managers)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/502334) \n\n### 脆弱性レポートにおける到達可能性フィルター\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n脆弱性レポート内のデータを到達可能な脆弱性のみに絞り込めるようになりました。到達可能な脆弱性とは、次の両方の条件を満たす脆弱性を指します。\n\n* 共通脆弱性識別子（CVE）リストに掲載されている\n* 明示的にインポートされているライブラリに含まれている\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerability_report/#filtering-vulnerabilities)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/543346) \n\n![脆弱性レポートにおける到達可能性フィルター](https://about.gitlab.com/images/18_2/reachability_filter.png)\n\n### 承認ポリシーにおけるソースブランチパターンの例外設定\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまで、GitFlowを使用するチームは、`release/*`ブランチを`main`にマージする際に、承認のデッドロックが頻繁に発生していました。これは、ほとんどのコントリビューターがリリース開発にすでに関与しており、承認者として機能できなくなるためです。\n\nマージリクエスト承認ポリシーのブランチパターン例外設定によって、この問題は解決されます。特定のソースブランチとターゲットブランチの組み合わせに対して、承認要件を自動的に回避できる仕組みです。たとえば、featureからmainへのマージには厳格な承認を設定しつつ、releaseからmainへのマージはスムーズに進められるように構成できます。\n\n主要機能：\n\n* **パターンベースの設定**：`release/*`や`hotfix/*`などのソースブランチパターンを定義し、承認要件を回避\n* **シームレスな統合**：ブランチの例外設定は既存のマージリクエスト承認ポリシーに直接統合され、UIまたは`policy.yaml`ファイルを通じて設定可能\n\nこれにより、複雑な回避策が不要になると同時に、標準的な開発ワークフローにおけるマージリクエスト承認ポリシーのセキュリティ上の利点は維持されます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/#source-branch-exceptions)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/18113) \n\n![承認ポリシーにおけるソースブランチパターンの例外設定](https://about.gitlab.com/images/18_2/source-branch-pattern.png)\n\n### 脆弱性レポートのCSVエクスポートに脆弱性IDを追加\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまで、脆弱性レポートのCSVエクスポートに脆弱性IDは含まれていませんでしたが、CSVエクスポートに各脆弱性のIDが一覧表示されるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerability_report/#exporting)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/18033)\n\n### カスタム管理者ロール（ベータ版）\n\n> Self-Managed: Ultimate\n\nこの新しいカスタム管理者ロールでは、GitLab Self-ManagedおよびGitLab Dedicatedインスタンスの管理者エリアで権限を細かく調整できるようになります。管理者は、従来のようにすべてのアクセス権を付与するのではなく、必要とする特定の機能のみにアクセスできる専用のロールを作成できます。これにより、管理機能に対する最小権限の原則を組織内で実現し、過剰な権限によるセキュリティリスクを低減し、業務効率性を向上させることができます。\n\nこの機能に関するコミュニティのみなさまからのフィードバックを心よりお待ちしております。ご質問や実装経験の共有、改善点に関して当社チームへのご意見がある場合は、[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509376)をご確認ください。\n\n[ドキュメント](https://docs.gitlab.com/user/custom_roles/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15069) \n\n![カスタム管理者ロール（ベータ版）](https://about.gitlab.com/images/18_2/sscs_authz_custom_admin_role.png)\n\n### 監査ストリーミング先へのストリーミングの無効化\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまで、監査ストリーミング先へのストリーミングを一時的に無効化する方法がありませんでした。たとえば、ストリーム接続のトラブルシューティングを行いたい場合や、設定の削除・再構成を行わずに変更を加えたい場合など、さまざまな理由で一時的に無効化したいケースが考えられます。\n\nGitLab 18.2では、監査ストリームを「有効」または「無効」に切り替える機能が追加されました。監査ストリームが無効になると、監査イベントは指定された送信先へストリーミングされなくなります。アクティブに切り替えると、監査イベントのストリーミングが再開されます。\n\n[ドキュメント](https://docs.gitlab.com/administration/compliance/audit_event_streaming/#activate-or-deactivate-streaming-destinations)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/537096) \n\n### すべての監査ストリーミング先でフィルタ機能が利用可能に\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまでは、一部の監査ストリーミング先では、利用できるフィルタ機能に制限がありました。\n\n今回の改善により、すべての監査ストリーミング先で、UI上で以下のような項目を指定して絞り込めるようになりました。\n\n* 監査イベントタイプ別\n* グループまたはプロジェクト別\n\nまた、AWSやGCPなどの監査イベント先でも、監査イベントの絞り込みが可能になりました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/audit_event_streaming/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/524939)\n\n### プレースホルダユーザーから非アクティブユーザーへの再アサイン\n\nSelf-Managed: Free、Premium、Ultimate\n\nこれまで、管理者はプレースホルダユーザーからアクティブユーザーに対してのみ、コントリビュートやメンバーシップを再アサインできました。\n\nGitLab Self-Managedでは、管理者によるプレースホルダユーザーから非アクティブユーザーへのコントリビュートやメンバーシップの再アサインも可能になりました。この機能により、ブロック済み、BAN済み、または無効化済みユーザーのコントリビュート履歴やメンバーシップ情報をGitLabインスタンス上で保持することができます。\n\n管理者は最初にこの設定を有効化する必要があります。有効化すると、安全なアクセス制御を維持しながら、再アサイン時のユーザー確認をスキップしてユーザー管理を効率化できます。\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/import_and_export_settings/#skip-confirmation-when-administrators-reassign-placeholder-users)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/523260) \n\n### 長期計画の強化に向けたエピックへのマイルストーン割り当て\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n[マイルストーン](https://docs.gitlab.com/user/project/milestones/)をエピックに直接割り当てることが可能になり、戦略的なイニシアティブから実行に至るまで、段階的な計画の流れを自然に作成できるようになりました。この機能強化により、四半期ごとの計画やSAFeプログラムインクリメント（PI）といった長期的な計画サイクルをエピックと連携させることができます。一方で、イテレーションは開発スプリントに特化させることができます。\n\nこの明確な階層構造により、管理上の負担を軽減し、戦略的なイニシアティブが組織のタイムフレームに沿ってどのように進捗しているかをより適切に把握できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/user/project/milestones/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/329)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/329)\n\n![長期計画の強化に向けたエピックへのマイルストーン割り当て](https://about.gitlab.com/images/18_2/epic_milestone.png)\n\n### エピックページでエピックをドロワーまたは全ページで表示\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nエピック一覧ページに新たに追加されたトグルを切り替えて、エピックをドロワー表示で開くか、全ページ表示で開くかを選べるようになりました。\n\nドロワー表示を使えば、エピック一覧のコンテキストを保ったまま、エピックの詳細をすばやく確認できます。また、詳細な編集や包括的な操作を行うために、より広い画面スペースが必要な場合は、全ページ表示で開くことも可能です。\n\n[ドキュメント](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/536620) \n\n![エピックページでエピックをドロワーまたは全ページで表示](https://about.gitlab.com/images/18_2/drawer_toggle.png)\n\n### GitLab Flavored Markdownにおける作業アイテム参照とエディターの改善\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Flavored Markdownで、`[work_item:123]`という統一構文を使用して、イシュー、エピック、作業アイテムを参照できるようになりました。この新しい構文は、イシュー用の`#123`やエピック用の`&123`といった既存の参照形式と併用でき、`[work_item:namespace/project/123]`のようなプロジェクト間参照にも対応しています。\n\nまた、プレーンテキストエディターには、Enterキーを押した際に[カーソルのインデントを維持する設定](https://docs.gitlab.com/user/profile/preferences/#maintain-cursor-indentation)が新たに追加されました。これにより、ネストされたリストやコードブロックなどの構造化されたコンテンツをより書きやすくなります。\n\n[ドキュメント](https://docs.gitlab.com/user/markdown/#gitlab-specific-references)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/7654)\n\n### トリガージョブでダウンストリームパイプラインステータスをミラーリング\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nこれまで、`strategy:depend`を使用したトリガージョブでは、手動ジョブ、ブロックされたパイプライン、実行中にステータスが変化する再試行パイプラインなど、複雑なパイプラインの状態に対応する際に制限がありました。そのため、実際には手動ジョブでブロックされているにもかかわらず、ダウンストリームパイプラインがアクティブに実行中であるかのように見えることがありました。\n\n新しい`strategy:mirror`キーワードは、ダウンストリームパイプラインの正確なリアルタイムのステータスをミラーリングすることで、より詳細なステータスレポートを可能にします。ステータスには、`running`、`manual`、`blocked`、`canceled`などの途中経過のステータスも含まれます。この機能により、チームは既存のワークフローを中断することなく、ダウンストリームパイプラインの現在のステータスを完全に把握できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/ci/yaml/#triggerstrategy)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/431882) \n\n### 時間ベースのワンタイムパスワードMFAのDAST対応\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n動的解析において時間ベースのワンタイムパスワード（TOTP）による多要素認証（MFA）がサポートされるようになりました。\n\nTOTP MFAが有効になっているプロジェクトでDASTスキャンを実行し、包括的なセキュリティテストを確実に行うことができます。この機能強化により、MFAが展開されている本番環境を再現した設定でアプリケーションをテストできるため、より正確なスキャン結果が得られます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dast/browser/configuration/authentication/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13633) \n\n### DASTログイン成功確認のサポート強化\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまで、`DAST_AUTH_SUCCESS_IF_AT_URL`変数を使用して認証の成功を確認するには、URLの完全一致が必要でした。この方法は、ランディングページが静的なアプリケーションには有効でしたが、ログイン後のURLにログインごとの動的要素が含まれるアプリケーションでは困難でした。\n\n今回の改善により、`DAST_AUTH_SUCCESS_IF_AT_URL`変数でワイルドカードパターンを使用し、動的なURLパターンにも一致させることが可能になりました。この機能強化で柔軟性が向上されたことで、セッションごとにURLが変化する場合でも、認証の成功を確認できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dast/browser/configuration/variables/#authentication)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/435942)\n\n### 依存関係パスの表示\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまでは、ある依存関係が直接的な依存関係なのか、それとも依存関係の子孫を通じてインポートされた間接的な依存関係なのかを判別するのが困難でした。\n\n新たに追加された依存関係パス機能を使用することで、ライブラリが直接的にインポートされているのか、あるいは間接的にインポートされているのかを判別できるようになりました。依存関係パスは、プロジェクトおよびグループの依存関係リストと脆弱性詳細で確認できます。この機能により、ライブラリがどのようにインポートされているかに応じて、最も効率的な修正のパスをデベロッパーが判断できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_list/#dependency-paths)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16815)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/16815)\n\n![依存関係パスの表示](https://about.gitlab.com/images/18_2/dependency_paths.png)\n\n### セキュリティインベントリによるアセットの包括的な可視化（ベータ版）\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nAppSecチームには、組織内のすべてのアセットに対するセキュリティ体制を包括的に可視化することが求められています。これまでのGitLabのセキュリティワークフローは、主にプロジェクトレベルでのスキャナー設定や脆弱性に焦点を当てていたため、カバレッジのギャップを把握したり、リスクに基づいて効率的に優先順位を付けたりするのが困難でした。\n\nセキュリティインベントリは、GitLabインスタンス全体におけるセキュリティ対策状況を一元的に表示し、AppSecチームが以下を実現できるようにします。\n\n* プロジェクトやグループ間のセキュリティカバレッジを完全に可視化する\n* セキュリティスキャンが十分に実行されていない、または設定にギャップがあるアセットを特定する\n* セキュリティ対策の重点をどこに置くのかについて、情報に基づいたリスクベースの意思決定を行う\n* セキュリティ対策状況の改善を継続的に追跡する\n\nこの機能を使用することで、個別プロジェクトのセキュリティと組織全体のセキュリティ戦略とのギャップを埋め、効果的なセキュリティプログラム管理に必要なアセットインベントリの基盤を構築できます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/security_inventory/)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16484)\\\n\n### 脆弱性GraphQL APIで追加情報を取得可能に\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nGraphQL APIを使用して、脆弱性が導入されたパイプラインと最後に検出されたパイプラインを特定できるようになりました。脆弱性GraphQL APIに以下のフィールドが追加されました。\n\n* `initialDetectedPipeline`：脆弱性が導入された際の追加のコミット情報（例：作成者のユーザー名）を取得するために使用\n* `latestDetectedPipeline`：脆弱性が削除された際の追加のコミット情報（例：コミットSHA）を取得するために使用\n\n[ドキュメント](https://docs.gitlab.com/api/graphql/reference/#vulnerability)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/468913) \n\n### 認証情報インベントリにサービスアカウントトークンを追加\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nGitLabの認証情報インベントリでサービスアカウントトークンがサポートされるようになりました。これにより、ソフトウェアサプライチェーン全体で使用されているさまざまな認証方式を、より明確に把握・管理できるようになります。認証情報インベントリは、組織全体で使用されている認証情報の全体像を提供します。\n\n[ドキュメント](https://docs.gitlab.com/administration/credentials_inventory/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/421954) \n\n### GitLab Duo Self-HostedでMistral Smallが利用可能に\n\nSelf-Managed: Premium、Ultimate、Duo Enterprise\n\n[GitLab Duo Self-Hosted](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#supported-models)でMistral Smallを使用できるようになりました。このモデルはGitLab Self-Managedインスタンスで利用可能であり、GitLab Duo Self-HostedのGitLab Duo Chatおよびコード提案機能に完全対応する初のオープンソースモデルです。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#supported-models/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/18202)\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n\n18.2で提供されたすべてのバグ修正、パフォーマンスの強化、UI改善を確認するには、以下のリンクをクリックしてください。\n\n* [バグ修正](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=type%3A%3Abug&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.2&first_page_size=100)\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.2)\n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.2)\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。[](https://docs.gitlab.com/ee/update/deprecations.html#resource-owner-password-credentials-grant-is-deprecated)[](https://docs.gitlab.com/ee/update/deprecations.html#coverage-guided-fuzz-testing-is-deprecated)\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n[](https://docs.gitlab.com/ee/update/deprecations.html#api-discovery-will-use-branch-pipelines-by-default)[](https://docs.gitlab.com/ee/update/deprecations.html#toggle-notes-confidentiality-on-apis)\n\n### 変更履歴\n\n変更内容をすべて表示するには、次のページから変更履歴を確認してください。\n\n* [GitLab](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/CHANGELOG.md)\n* [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/CHANGELOG.md)\n* [VS CodeのGitLab Workflow](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md)\n* [GitLab CLI](https://gitlab.com/gitlab-org/cli/-/releases)\n\n### インストール\n\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/ja-jp/install/)をご覧ください。\n\n### 更新事項\n\n[更新ページ](https://about.gitlab.com/ja-jp/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\nGitLabのすべての機能を[無料](https://about.gitlab.com/free-trial/?hosted=saas)でお試しいただけます。\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\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/)",[905],"2025-07-24","2025-07-18","GitLab 18.2 リリース",[1010,838,765,109],"GitLab 18.2でリリースした最新機能を公開します。",{"featured":91,"template":800,"slug":1099},"gitlab-18-02-release",{"content":1101,"config":1110},{"heroImage":1102,"body":1103,"authors":1104,"updatedDate":1105,"date":1106,"title":1107,"tags":1108,"description":1109,"category":765},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750396128/vak5nlffgockma115495.png","本ブログは、[GitLab 18.1 Release](https://about.gitlab.com/releases/2025/06/19/gitlab-18-1-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n## Maven仮想レジストリ（ベータ版）とGitLab Duoコードレビュー搭載のGitLab 18.1リリース\n\nこのたび、GitLab 18.1のリリースを発表しました。このリリースでは、Maven仮想レジストリ（ベータ版）、GitLab Duoコードレビュー、漏洩パスワードの検出、SLSAレベル1準拠を実現するCI/CDコンポーネントなど、さまざまな機能が追加されました。\n\nこれらの機能は、今回のリリースに含まれる110件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 18.1には、GitLabコミュニティのユーザーから311件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースもユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ](https://about.gitlab.com/upcoming-releases/)をご覧ください。\n\n[GitLab 18.1のリリースでは、Maven仮想レジストリ（ベータ版）とGitLab Duoコードレビューが追加されました。クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+18.1%E3%81%AE%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%A7%E3%81%AF%E3%80%81Maven%E4%BB%AE%E6%83%B3%E3%83%AC%E3%82%B8%E3%82%B9%E3%83%88%E3%83%AA%EF%BC%88%E3%83%99%E3%83%BC%E3%82%BF%E7%89%88%EF%BC%89%E3%81%A8GitLab+Duo%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%8C%E8%BF%BD%E5%8A%A0%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%81%97%E3%81%A6SNS%E3%81%A7%E5%85%B1%E6%9C%89%E3%81%97%E3%81%BE%E3%81%97%E3%82%87%E3%81%86%EF%BC%81&url=https://about.gitlab.com/ja-jp/blog/gitlab-18-1-release/&hashtags=)\n\n## 今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は[](https://gitlab.com/karras)[Chaitanya Sonwane](https://gitlab.com/chaitanyason9)さんです\n\n\u003Cimg src=\"https://about.gitlab.com/images/notable-contributor-logo.svg\">\n\nChaitanya Sonwaneさんは、継続的な認証機能の強化により、GitLabのセキュリティ機能向上に貢献しています。[2025年に13件のコントリビュートがマージされ](https://contributors.gitlab.com/users/chaitanyason9?fromDate=2025-01-01&toDate=2025-12-31)、認証情報インベントリのフィルタリング、サービスアカウント管理、作業アイテムの使いやすさが向上しました。以前には[GitLab 17.11の主要機能](https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/#token-statistics-for-service-account-management)としてサービスアカウントのトークン統計情報をひと目で確認できる機能を手がけ、サービスアカウントの管理を容易にする「一目でわかる」情報を提供しました。Chaitanyaさんは現在、[作業アイテムリストのソート設定をコンテキスト固有にする改善](https://gitlab.com/gitlab-org/gitlab/-/issues/503587)に取り組み、GitLabの製品計画におけるユーザーエクスペリエンスをさらに向上させています。\n\nChaitanyaさんの活躍により、GitLabを利用する組織のセキュリティが強化され、サービスアカウントの使用状況がプロジェクト全体で把握しやすくなりました。現在では、チームが認証情報をより効果的に追跡、ローテーションできるようになったことで、セキュリティの脆弱性につながりかねない、未管理の認証情報のリスクが軽減されています。\n\n「認証情報インベントリとサービスアカウントに対するChaitanyaさんのコントリビュートは、セキュリティ分野において非常に貴重なものです」と[Eduardo Sanz-Garcia（](https://gitlab.com/eduardosanz)ソフトウェアサプライチェーンセキュリティステージの認証グループのシニアフロントエンドエンジニア）は語ります。Eduardoは、[GitLabの認証チーム](https://about.gitlab.com/direction/software_supply_chain_security/authentication/)による推薦も後押ししました。\n\nさらに彼は「Chaitanyaさんは、トークン統計のコンセプトの実装に貢献してくれました。認証情報インベントリの取り組みにより、認証情報の追跡とモニタリングを強化する、非常に要望の多かった機能が提供されたのです。非常に素晴らしいコントリビュートでした」とも付け加えています。\n\nChaitanyaさんはTATA AIGのソフトウェアエンジニアです。セキュリティ上の課題に積極的に取り組み、自らのコントリビュートを改善するための継続的なフォローアップを行っています。\n\nこの場を借りて、GitLabのセキュリティ基盤やその他の製品にコントリビュートしてくれたChaitanyaさんに感謝します！\n\n## GitLab 18.1リリースの主な改善点\n\n### Maven仮想レジストリがベータ版で利用可能に\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nMaven仮想レジストリは、GitLabでのMaven依存関係管理を簡素化するものです。Maven仮想レジストリを使用しない場合、Maven Central、プライベートリポジトリ、GitLabパッケージレジストリからの依存関係にアクセスするための設定を個別に行う必要があります。こうしたアプローチでは、リポジトリへの順次クエリによってビルドが遅くなり、セキュリティ監査とコンプライアンスレポート作成が複雑になります。\n\nMaven仮想レジストリは、複数のアップストリームリポジトリを単一のエンドポイントに集約することで、このような問題に対処します。プラットフォームエンジニアは、1つのURLを介してMaven Central、プライベートレジストリ、GitLabパッケージレジストリを設定できます。インテリジェントキャッシュはビルドパフォーマンスを向上させ、GitLabの認証システムと統合されます。これにより、設定オーバーヘッドの削減、ビルドの高速化、セキュリティとコンプライアンス向上を目的として一元管理されたアクセス制御が実現します。\n\nMaven仮想レジストリは現在、GitLab.comとGitLab Self-Managedの両方で、GitLab PremiumおよびUltimateのお客様にベータ版として提供されています。一般公開リリースには、レジストリ設定用のWebベースUI、共有可能なアップストリーム機能、キャッシュ管理のためのライフサイクルポリシー、強化された分析機能などが追加される予定です。現在のベータ版では、トップレベルグループあたり最大20の仮想レジストリ、仮想レジストリあたり最大20のアップストリームまでと制限されており、ベータ期間中の設定はAPIのみで行えます。\n\n企業のお客様を対象としたMaven仮想レジストリベータプログラムを実施しています。最終リリースの品質向上にご協力をお願いいたします。ベータ版にご参加いただくお客様には、機能への早期アクセス、GitLab製品チームとの直接のやり取り、評価期間中の優先サポートを提供します。ベータプログラムに参加するには、[イシュー498139](https://gitlab.com/gitlab-org/gitlab/-/issues/498139)でご興味があることをお知らせいただき、ユースケースの詳細を提供してください。また、フィードバックや提案は[イシュー543045](https://gitlab.com/gitlab-org/gitlab/-/issues/543045)にお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/packages/virtual_registry/maven/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14137)[](https://gitlab.com/groups/gitlab-org/-/epics/14137)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZkIkaJDEcEE?si=F7dfSCtzBIv02_is\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### GitLab Duoコードレビューが一般公開開始\n\n> SaaS: Premium、Ultimate、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duoコードレビューが一般公開され、本番環境で使用できるようになりました。AI搭載のこのコードレビューアシスタントは、マージリクエストに対して的確で自動化されたフィードバックを提供し、従来のコードレビュープロセスを変革します。これにより、人間のレビュアーが関与する前に、潜在的なバグ、セキュリティの脆弱性、コード品質の問題を特定できるため、レビュープロセス全体を徹底的かつ効率的に行うことができます。GitLab Duoコードレビューには以下の機能が含まれています。\n\n* **自動初期レビュー**：コードの変更内容を分析し、潜在的な問題、改善点、ベストプラクティスに関する包括的なフィードバックを提供します。  \n* **対話ベースで改善**：マージリクエストコメントで`@GitLabDuo`をメンションすると、特定の変更や質問に対する的確なフィードバックを受け取ることができます。  \n* **実行可能な提案**：多くの提案をブラウザから直接適用できるため、改善プロセスが効率化されます。  \n* **文脈を理解した分析**：変更されたファイルの内容を理解し、プロジェクトに特化した関連性の高い推奨事項を提供します。\n\nGitLab Duoコードレビューをリクエストするには、次の手順に従います。\n\n* マージリクエストで、`/assign_reviewer` `@GitLabDuo`クイックアクションを使用して`@GitLabDuo`をレビュアーとして追加するか、GitLab Duoをレビュアーとして直接割り当てます。  \n* コメントで`@GitLabDuo`をメンションすると、ディスカッションスレッドで特定の質問をしたり、詳細なフィードバックをリクエストしたりできます。  \n* プロジェクト設定で自動レビューを有効にすると、GitLab Duoがすべての新しいマージリクエストを自動的にレビューします。\n\nGitLab Duoコードレビューを活用することで、チームがより高いコード品質基準を維持しながら、手動レビューサイクルに費やす時間を短縮できます。問題を早期に発見し、教育的なフィードバックを提供することで、開発チームにとって品質管理ツールと学習ツールの両方の役割を果たします。\n\nベータ版時のGitLab Duoコードレビューの動作はこちらを[ご覧ください](https://www.youtube.com/watch?v=FlHqfMMfbzQ)。\n\n[イシュー517386](https://gitlab.com/gitlab-org/gitlab/-/issues/517386)でご経験やフィードバックをお寄せいただき、本機能の継続的な改善にご協力ください。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13979)[](https://gitlab.com/groups/gitlab-org/-/epics/13979)\n\n![GitLab Duoコードレビューが一般公開開始](https://about.gitlab.com/images/18_1/create-duo-code-review.png)\n\n### ネイティブGitLab認証情報の漏洩パスワード検出\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: -\n\nGitLab.comへのサインイン時に、アカウント認証情報の安全なチェックが実行されるようになりました。お使いのパスワードが既知の情報漏洩に含まれている場合、GitLabにバナーが表示され、メール通知が送信されます。これらの通知には、認証情報の更新手順が記載されています。\n\nセキュリティを最大限に高めるために、GitLabでは以下を推奨しています。\n\n* GitLab専用の強力なパスワードの使用  \n* 2要素認証の有効化  \n* アカウントアクティビティの定期的な確認\n\n注：この機能はネイティブGitLabのユーザー名とパスワードでのみ利用可能です。SSO認証情報は対象外です。\n\n[ドキュメント](https://docs.gitlab.com/security/compromised_password_detection/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)[](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)[](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)\n\n![ネイティブGitLab認証情報の漏洩パスワード検出](https://about.gitlab.com/images/18_1/sscs_password_alert.png)\n\n### CI/CDコンポーネントでSLSAレベル1のコンプライアンスに対応\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate  \n\nGitLabの新しいCI/CDコンポーネントを使用することで、[SLSA](https://slsa.dev/)レベル1のコンプライアンスに対応できるようになりました。このコンポーネントは、GitLab Runnerが生成するSLSA準拠の [アーティファクトの来歴メタデータ](https://docs.gitlab.com/ci/runners/configure_runners/#artifact-provenance-metadata)に対して署名と検証を実行します。また、[Sigstore Cosignの機能](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html)を再利用可能なモジュールとして提供し、CI/CDワークフローに簡単に統合できるようにします。\n\n[ドキュメント](https://docs.gitlab.com/ci/pipelines/pipeline_security/#sign-and-verify-slsa-provenance-with-a-cicd-component)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15859)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/15859)\n\n![CI/CDコンポーネントでSLSAレベル1のコンプライアンスに対応](https://about.gitlab.com/images/18_1/SLSA_component.png)\n\n## GitLab 18.1リリースに含まれるその他の改善点\n\n### コード検索で複数の検索結果の統合表示が可能に\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n完全一致コードの検索（ベータ版）では、同じファイル内の複数の検索結果を単一のビューに統合して表示できるようになりました。この改善により、次のことが可能になります。\n\n* 孤立した行表示ではなく、隣接する一致間のコンテキストを保持  \n* 一致する内容が近い場合に重複コンテンツを排除し、視覚的な混乱を軽減  \n* ファイルごとの一致数を明確に表示することで、ナビゲーションを強化  \n* エディタでの表示と同様にコードを表示することで、可読性を改善\n\nこの変更により、リポジトリ全体のコードパターンの発見と理解がより効率的になりました。\n\n[ドキュメント](https://docs.gitlab.com/integration/exact_code_search/zoekt/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13127)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/wx2D39UdUoQ?si=fvjYK-rYVHPgVgzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### 権限チェック機能を強化したCODEOWNERSファイル検証\n\nSaaS: Premium、Ultimate\\\nSelf-Managed: Premium、Ultimate\n\nGitLabでは、基本的な構文チェックを超えた、CODEOWNERSファイルに対するより強化された検証が提供されるようになりました。CODEOWNERSファイルを表示すると、GitLabが自動的に包括的な検証を実行し、マージリクエストのワークフローに影響を与える前に構文エラーと権限の問題を特定します。\n\nこの強化された検証では、CODEOWNERSファイル内の最初の200のユニークなユーザーとグループの参照をチェックし、次のことを検証します。\n\n* 参照されたすべてのユーザーとグループがこのプロジェクトにアクセスできること  \n* ユーザーに、マージリクエストを承認するために必要な権限があること  \n* グループに、デベロッパーレベル以上のアクセス権があること  \n* グループに、マージリクエストの承認権限を持つユーザーが少なくとも1人含まれていること\n\nこの事前検証により、設定上の問題を早期に発見して承認ワークフローの中断を防ぎ、マージリクエストが作成されたときにGitLabコードオーナーが実際にレビューの責任を果たせるようにできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/codeowners/troubleshooting.html#validate-your-codeowners-file)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15598)\n\n### VS Codeでダウンストリームパイプラインのジョブログを表示\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nVS Code用GitLab Workflow拡張機能で、ダウンストリームパイプラインからのジョブログをエディタ内で直接表示できるようになりました。これまで、子パイプラインからログを確認するには、GitLab Webインターフェイスに切り替える必要がありました。\n\nこの機能は、[GitLab共同開発](https://about.gitlab.com/community/co-create/)を通じて開発されました。この場を借りて、コントリビュートしてくれたTim Ryanさんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/editor_extensions/visual_studio_code/cicd/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1895)\n\n\n\n![VS Codeでダウンストリームパイプラインのジョブログを表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659268/orzwm4kjqdag8fe0psvr.png)\n\n### シークレット検出のデフォルトルールとDAST検出の同等性\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nDASTアナライザーが、GitLabのシークレット検出アナライザーで使用されるものと同じデフォルトのシークレット検出ルールを自動的に取り込むようになりました。この改善により、両方のアナライザーで検出されるシークレットの種類に一貫性が確保されます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dast/browser/checks/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/549990)\n\n### 依存関係リストでコンポーネントバージョンによるフィルタリング\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n依存関係リストで、コンポーネントのバージョン番号によるフィルタリングがサポートされるようになりました。複数のバージョン（`バージョン=1.1、1.2、1.4`など）を選択できますが、バージョン範囲指定はサポートされていません。この機能は、グループとプロジェクトの両方で利用できます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_list/#filter-dependency-list)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16431)\n\n![依存関係リストでコンポーネントバージョンによるフィルタリング](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659404/fepyzz2uv3j47bjcehhi.png)\n\n\n\n### コンプライアンスステータスレポートでコントロールステータスの一覧がポップアップで表示されるように\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスステータスレポートのコントロールには、次の3つのステータスがあります。\n\n* 合格  \n* 失敗  \n* 保留中\n\nこれまでは、要求事項に関連付けられているコントロールの数に関係なく、少なくとも1つのコントロールが「保留中」の場合、要求事項行全体が「保留中」として表示されていました。これは、失敗したコントロールの表示方法とは一貫性がありませんでした。失敗したコントロールが1つでもある場合は、要求事項に関連付けられた全コントロール数と失敗の数が表示されます。\n\n「保留中」のコントロールに関する詳細なコンテキストと情報を提供するため、要求事項行のステータスにカーソルを合わせると、各コントロールのステータスを一覧表示するポップアップが表示されるようになりました。これにより、単に「保留中」という全体ステータスを確認するだけでなく、どのコントロールが保留中で、どのコントロールが合格または失敗しているかを具体的に把握できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/521757)\n\n### ボットユーザーと人間のユーザーのフィルタリング\n\n> SaaS: -\\\n> Self-Managed: Free、Premium、Ultimate\n\n運用が進んだGitLabインスタンスでは、多くの場合、人間とボットの両方のユーザーが多数存在します。今回のリリースで、管理者エリアのユーザーリストをユーザータイプでフィルタリングできる機能が追加されました。この機能により、以下のことが可能になります。\n\n* 人間のユーザーと自動化アカウントを区別して迅速に特定、管理  \n* 特定のユーザータイプに絞った管理アクションを実行  \n* ユーザーの監査と管理のワークフローの効率化\n\n[ドキュメント](https://docs.gitlab.com/administration/moderate_users/#view-users-by-type)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/541186)\n\n![ボットユーザーと人間のユーザーのフィルタリング](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659653/prkshqzxg5785p69yshd.png)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/541186)\n\n### ユーザープロフィールのORCID識別子\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nユーザープロフィールにORCID識別子を設定できるようになり、GitLabが研究者や学術コミュニティにとってより使いやすく価値あるものになりました。[ORCID](https://orcid.org/)（Open Researcher and Contributor ID）は、研究者に永続的なデジタル識別子を提供し、他の研究者との区別を可能にするとともに、研究者とその業績を自動的に関連付けることで、適切な評価を支援するものです。\n\nこの機能は、学術コミュニティからの長年の要望に応えるため、アルトワ大学の修士課程の学生であるThomas LabaletteとErwan Hivinが[Daniel Le Berre](https://www.ouvrirlascience.fr/appointment-of-daniel-le-berre-as-the-national-coordinator-for-higher-education-and-research-software-forges-in-france/)の指導の下、コミュニティに貢献することを目的に開発したものです。\n\n[ドキュメント](https://docs.gitlab.com/user/profile/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/23543)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/23543)\n\n![ユーザープロフィールのORCID識別子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663008/oogvxelirqapyxp10pha.png)\n\n\n\n### サービスアカウントのパイプライン通知への登録\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nサービスアカウントによってトリガーされたパイプラインイベントの通知を、受信できるようになりました。通知はパイプラインが合格、失敗、または修正された場合に送信されます。これまでは、サービスアカウントに有効なカスタムメールアドレスが設定されている場合にのみ、そのサービスアカウントのメールアドレスに通知が送信されていました。\n\nこの場を借りて、コントリビュートしてくれた[Densett](https://gitlab.com/Densett)さん、[Gilles Dehaudt](https://gitlab.com/tonton1728)さん、[Lenain](https://gitlab.com/lenaing)さん、[Geoffrey McQuat](https://gitlab.com/gmcquat)さん、[Raphaël Bihoré](https://gitlab.com/rbihore)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/user/profile/notifications/#notification-events-on-issues-merge-requests-and-epics)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/515629)\n\n### 無効となっているパーソナルアクセストークンの表示\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLabは、有効期限が切れたり、失効したりしたアクセストークンを自動的に無効化します。今回の変更では、無効となっているトークンを確認できるようになりました。これまでは、アクセストークンが無効になると表示されなくなっていました。この変更により、こうしたトークンのトレーサビリティとセキュリティが向上します。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/425053)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/weEU6pukbag?si=ebijnyBQdW1_5yBl\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### GitLab Query Language（GLQL）ビューでのエピックサポート（ベータ版）\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Query Language（GLQL）ビューが大幅に改善されました。今後は、クエリでエピックをタイプとして使用できるようになり、グループ全体のエピック検索や親エピックへのクエリが可能になります。\n\nこの機能強化により計画・追跡のワークフローが大きく向上し、エピックレベルでのクエリや整理が格段に効率化されます。\n\n[ドキュメント](https://docs.gitlab.com/user/glql/fields/#epic)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab-query-language/glql-rust/-/issues/30)\n\n### レビューパネルによるマージリクエストのレビューエクスペリエンスの強化\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nマージリクエストのレビューを行う際、レビューを送信する前にこれまでのフィードバックを参照すると役立つことがあります。これまでは、最終コメントと保留中コメントが別々のポップアップに分かれていたため、全体像を把握することが困難でした。\n\nコードレビュー時に、保留中の下書きコメントを一箇所にまとめて表示する専用ドロワーが利用できるようになりました。強化されたレビューパネルでは、レビュー送信インターフェイスがよりアクセスしやすい場所に移動し、保留中のコメント数を示す番号付きバッジが表示されます。パネルを開くと、下にスクロールできるリストに下書きコメントがすべて表示されるため、送信前のフィードバックの確認と管理が簡単になります。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/reviews/#submit-a-review)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/525841)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/525841)\n\n![レビューパネルによるマージリクエストのレビューエクスペリエンスの強化](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663218/yfbrzecnuynpb1g57854.png)\n\n\n\n### GitLab Runner 18.1\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Runner 18.1もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドのエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\nバグ修正：\n\n* [GitLab 17.10または17.11にアップグレードすると、Runnerがジョブをリクエストしたときに404エラーが発生する可能性があります](https://gitlab.com/gitlab-org/gitlab/-/issues/543351)。\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-1-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### 高度なSASTのPHPサポート\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nGitLabの高度なSASTにPHPサポートを追加しました。この新しいファイル間、関数間スキャン機能を使用するには、[高度なSASTを有効](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#enable-advanced-sast-scanning)にします。高度なSASTをすでに有効にしている場合、PHPサポートは自動的に有効になります。\n\n高度なSASTが各言語で検出する脆弱性の種類を確認するには、[高度なSASTカバレッジページ](https://docs.gitlab.com/user/application_security/sast/advanced_sast_coverage/)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#supported-languages)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14273)\n\n### パイプライン実行ポリシーにおける変数の優先順位制御\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n多くの場合、セキュリティチームはセキュリティ保証とデベロッパーエクスペリエンスの間で微妙なバランスを取ることになります。セキュリティスキャンが適切に実行されていることを確認するのは重要ですが、セキュリティアナライザーが正常に動作するためには、開発チームからの特定のインプットが必要な場合があります。変数の優先順位制御により、セキュリティチームは新しい`variables_override`設定オプションを通じて、パイプライン実行ポリシーにおける変数の処理方法を細かく制御できるようになりました。\n\nこの新しい設定を使用すると、次のことが可能になります。\n\n* プロジェクト固有のコンテナイメージパス（`CS_IMAGE`）を許可するコンテナスキャンポリシーを適用  \n* `SAST_EXCLUDED_PATHS`などの低リスク変数は許可し、`SAST_DISABLED`などの高リスク変数はブロック  \n* `AWS_CREDENTIALS`などのグローバルCI/CD変数で保護（マスクまたは非表示）されたグローバル共有認証情報を定義しつつ、必要に応じてプロジェクトレベルのCI/CD変数によるプロジェクト固有の上書きを許可\n\nこの強力な機能は、次の2つのアプローチをサポートしています。\n\n* **デフォルトで変数をロックする**（`allow: false`）：例外として指定した特定の変数を除き、すべての変数をロック  \n* **デフォルトで変数を許可する**`（allow: true`）：変数のカスタマイズを許可するが、重大なリスクのある変数を例外として指定することで制限  \n\n\n\nパイプライン実行ポリシーによってCI/CDジョブが実行される際のトレーサビリティとトラブルシューティングを改善するために、ジョブログ機能も導入されました。これにより、デベロッパーとセキュリティチームは、どのジョブがポリシーによって実行されたかを簡単に特定できますジョブログでは、変数の上書きによる影響の詳細を確認でき、どの変数がポリシーによって上書きまたはロックされているかを把握するのに役立ちます。\n\n**実際の影響**\n\nこの機能強化により、セキュリティ要件とデベロッパーの柔軟性のニーズとの間のギャップが解消されます。\n\n* セキュリティチーム：プロジェクト固有のカスタマイズを許可しつつ、標準化されたスキャンを実行できる  \n* デベロッパーは：ポリシーの例外をリクエストすることなく、プロジェクト固有の変数を制御できる  \n* 組織は：開発ワークフローを混乱させることなく、一貫したセキュリティポリシーを実装できる\n\nこの重要な変数制御機能により、GitLabは組織が開発の柔軟性を保ちながら強固なセキュリティポリシーを導入できる環境を提供します。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/#variables_override-type)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16430)\n\n\n\n![パイプライン実行ポリシーにおける変数の優先順位制御](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663308/h1oukhyd4ky1w6spdxpo.png)\n\n\n\n### 外部カスタムコントロールの`Name`を定義\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまでは、カスタムコンプライアンスフレームワークを作成する際に外部カスタムコントロールの名前を定義できず、GitLabコントロールと並んでリスト表示される外部コントロールを識別することが困難でした。\n\n今回、外部カスタムコントロールを定義する際のワークフローの一部として`Name`フィールドが追加されました。これにより、複数の外部カスタムコントロールを作成し、それぞれに固有の名前を設定して明確に区別できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_frameworks/#external-controls)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/527007)\n\n### GitLab Duo脆弱性の修正のためのSASTカバレッジの向上\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまでは、次のCommon Weakness Enumeration（CWE）識別子を持つ検出された脆弱性を手動で解決する必要がありました。\n\n* CWE-78（コマンドインジェクション）  \n* CWE-89（SQLインジェクション）\n\n現在は、GitLab Duo脆弱性の修正により、これらの脆弱性を自動的に修正できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerabilities/#supported-vulnerabilities-for-vulnerability-resolution)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/534307)\n\n### コンプライアンスフレームワークUIにおける要件のページネーション\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスフレームワークを作成する際は、最大50個の要件を指定できます。\n\nただし、これほど多くの要件があると、UIで大きな表示領域を占めるため、コンプライアンスフレームワークの操作が非常に困難になります。\n\n今回のリリースでは、コンプライアンスフレームワークに多数の要件が含まれている場合でも、ユーザーが要件を簡単に閲覧、検索、選択できるよう、要件のページネーション機能を導入しました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_frameworks/#add-requirements)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/531039)\n\n### コンプライアンスセンターのUIパフォーマンスとフィルタリングを改善\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスセンターのUIパフォーマンスとフィルタリングオプションの改善を継続しています。今回のリリースでは、次のことを行いました。\n\n* 特に多くの要件とプロジェクトが含まれる場合に、**フレームワークの編集**ページのUIスピードとパフォーマンスを改善しました。  \n* コンプライアンスセンターの**コンプライアンスステータスレポート**タブで、要件、プロジェクト、またはフレームワーク別にグループ化できる新しいフィルタリングオプションを導入しました。\n\nこれらの改善を行うことで、コンプライアンスセンターを定期的に利用するお客様に対し、コンプライアンスセンターと関連機能が大規模環境でも継続して高いパフォーマンスを発揮できるようにしています。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/508188)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/478216)\n\n### GraphQL APIの`projectMembers`に新しい`accessLevels`引数を追加\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGraphQL APIの`projectMembers`フィールドに`accessLevels`引数が追加されました。この引数を使用すると、APIコールから直接アクセスレベル別にプロジェクトメンバーをフィルタリングできます。これまでは、プロジェクトメンバーの全リストを取得してからローカルでフィルターを適用する必要があり、これにより計算オーバーヘッドが大幅に増加していました。現在では、プロジェクトの権限分析や所有権グラフの生成がより高速化し、リソース効率も向上しています。この機能強化は、複雑な権限構造を持つ大規模デプロイを管理する組織にとって特に価値があります。\n\n[ドキュメント](https://docs.gitlab.com/api/graphql/reference/#projectprojectmembers)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/541386)\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n\n18.1で提供されたすべてのバグ修正、パフォーマンスの強化、UI改善を確認するには、以下のリンクをクリックしてください。\n\n* [バグ修正](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=type%3A%3Abug&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.1)  \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.1)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.1)\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。[](https://docs.gitlab.com/ee/update/deprecations.html#resource-owner-password-credentials-grant-is-deprecated)[](https://docs.gitlab.com/ee/update/deprecations.html#coverage-guided-fuzz-testing-is-deprecated)\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n[](https://docs.gitlab.com/ee/update/deprecations.html#api-discovery-will-use-branch-pipelines-by-default)[](https://docs.gitlab.com/ee/update/deprecations.html#toggle-notes-confidentiality-on-apis)\n\n### 変更履歴\n\n変更内容をすべて表示するには、次のページから変更履歴を確認してください。\n\n* [GitLab](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/CHANGELOG.md)  \n* [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/CHANGELOG.md)  \n* [VS CodeのGitLab Workflow](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md)  \n* [GitLab CLI](https://gitlab.com/gitlab-org/cli/-/releases)\n\n### インストール\n\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/ja-jp/install/)をご覧ください。\n\n### 更新事項\n\n[更新ページ](https://about.gitlab.com/ja-jp/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\nGitLabのすべての機能を[無料](https://about.gitlab.com/free-trial/?hosted=saas)でお試しいただけます。  \n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\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/)",[905],"2025-06-23","2025-06-20","GitLab 18.1 リリース",[1010,838,765,109],"GitLab 18.1でリリースした最新機能をご紹介します。",{"featured":6,"template":800,"slug":1111},"gitlab-18-01-release",{"category":126,"slug":776,"posts":1113},[1114,1125,1137],{"content":1115,"config":1123},{"title":1116,"description":1117,"authors":1118,"heroImage":1119,"date":1120,"body":1121,"category":776,"tags":1122},"IDE、そしてWeb IDEとは","Web IDE や IDE の知識を身に付け、統合開発環境ツール使用時や、開発自体に生かしましょう。",[968],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660036/Blog/Hero%20Images/ide.jpg","2025-06-03","Web IDEとは、クラウドベースで機能する、Webブラウザ上でソースのコミットまで行える高度なIDEです。では、IDEとは？ Web IDEやIDEを知らなかった人にもわかりやすいように、その仕組みや概要を、ここで簡単に説明します。\n\n## 目次\n\n* IDE（統合開発環境）とは\n* IDEの主な特徴\n* IDEの仕組み\n* IDEの種類\n* IDEを使うメリット\n* IDEの例\n* Web IDEとは\n* IDEのFAQ（よくある質問）\n\n## IDE（統合開発環境）とは\n\nIDEはIntegrated Development Environmentの略で、日本語では「統合開発環境」と訳されます。IDEは、開発者がソフトウェアのコードを開発する際に必要なソフトウェアをひとつにまとめ、単一の画面で操作できるようにしたものです。\n\nプログラミングには次のようなプログラムが必要になります。\n\n* テキストエディタ：ソースコードを記述  \n* コンパイラー：ソースコードからオブジェクトコードを生成  \n* リンカー：ターゲットとなるCPU用に実行コードを生成  \n* デバッガー：作成したプログラムのバグ検出に使用  \n* コードのバージョン管理：ほとんどのIDEはシームレスにバージョン管理システムを統合  \n* 自動化ビルド：ビルドプロセスを自動化\n\nIDEがなかった時代は、これら一つひとつを手作業で統合しなければなりませんでした。しかし、現在ではすべてがIDEツールに統合されているため、IDEをインストールするか、Web IDEにアクセスすれば、開発環境が瞬時に整います。ほとんどのIDEには、ソースコードを自動的に書いたり、編集したりするための機能が含まれています。そのため、コード開発を効率的に行うことが可能になります。\n\n## IDEの主な特徴\n\nIDEはこれまで、パソコンにインストールして使用するものが主流でしたが、現在はWeb IDEなど、クラウドベースのものが増えてきています。GitLabのWeb IDEも、Webブラウザにアクセスできれば、簡単に開発ができるため、複数の開発者で開発環境を共有することが可能です。\n\n統合開発環境（IDE）の特徴は、次のとおりです。\n\n1. 時間の節約：上述のように、各種プログラムがひとつのプラットフォーム上に統合されているため、ソフトウェア開発にかかる時間が短縮できます。  \n2. チームでの開発の効率化：バージョン管理やソースコードの管理など、引き継ぎにかかる手間が省け、ミスが予防できます。  \n3. ヒューマンエラーの防止：IDEのエディタには入力サポート機能があり、コンパイラにはシンタックスチェック、つまり構文の間違いチェック機能があります。こういった機能はヒューマンエラーを防止してくれます。\n\n## IDEの仕組み\n\nIDEとは、ソフトウェアの開発で使用するさまざまなソフトウェアを支援ツールと合わせてまとめ、統合開発環境として使えるようにしたものです。\n\n## IDEの種類\n\nIDEには、さまざまな種類があります。用途や目的、プログラミング言語、ターゲットとする OS や動作環境によって、選ぶポイントがあります。何を作るのか、どういうソフトウェアやアプリケーションを開発するのかによっても、最適 IDEは変わります。どのIDEを選ぶかによって、できることが異なるからです。しかし、異なるIDEで共通してできることは、次のようなものです。\n\n* ソースファイルの構成管理  \n* ビルドの自動実行  \n* デバッグ\n\nまた、たとえば、プログラミング言語には Java、Swift、C++、C\\#、UnityやPythonなどがあるため、コードを書く言語に対応しているIDEを選ぶべきでしょう。IDEの種類としては：\n\n* 多言語対応IDE  \n* モバイル開発用IDE  \n* WebまたはクラウドベースのIDE  \n* 単言語のIDE\n\nなどがあります。\n\nまた、IDEにはダウンロードして使うものと、クラウドで使用するもの、たとえばWeb IDEなどがあります。クラウドベースのものは、複数の開発者の間で開発環境が共有できるため、各々のチームメンバーの環境設定の違いは問題になりません。また、ビルドの際はCPUの速度低下により時間がかかるものですが、クラウドIDEでは速度低下は発生しません。ソースコード開発は、Gitなどと連携すれば、チーム間での共有も行えます。\n\n## IDEを使うメリット\n\nIDE、統合開発環境を使うメリットは、一言で言うなら「開発の効率化」です。「IDEとは」で記述したように、IDEにはテキストエディタ、コンパイル、デバッグなどの機能がすべて統合されています。そのため、コード開発の効率化が図れます。\n\nIDEを使うと、環境設定を行う手間が省けますが、逆に、IDEを使わないと、各種ツールを設定しなければならず、時間がかかります。また、IDEはインストール後すぐ使えるため、プログラミングの初心者にもお勧めできます。\n\n## IDEの例\n\nIDE、統合開発環境にはたくさんの種類があります。現在よく使われているIDEのうち、例を 5 つ挙げます。\n\n●        Visual Studio/Visual Studio Code – Microsoftが開発。市場でとくに人気がある\n\n●        IntelliJ IDEA – JetBrains が開発した、多言語対応型IDE\n\n●        Vim - Bram Moolenaar氏が開発した軽量のテキストエディタでIDEとして使用可\n\n●        Eclipse – IBMが開発した、オープンソースのIDE\n\n●        Jupyter Notebook – Pythonの実行環境をもつ、ブラウザベースのIDE\n\n## Web IDEとは\n\nWeb IDEとは、前述のように、WebベースのIDEで、WebブラウザさえあればアクセスできるIDEを意味します。個々に IDE を利用するのではなく、利用者はみな、ブラウザを介してIDEにアクセスするため、各種設定のわずらわしさから解放されます。\n\n### [GitLab Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/)を使うメリット\n\nGitLabには、クラウドベースの、オンライン[Web IDE（英語版）](https://about.gitlab.com/blog/get-ready-for-new-gitlab-web-ide/)があります。Web IDEは、コミットのステージング機能を備えた高度なエディタです。Web IDEを使うと、GitLab UIから直接複数のファイルに変更を加えることができます。\n\n* フレキシブルでカスタム化可能なインターフェース  \n* パネルは折りたたみ可能で、テーマもカスタム化可能  \n* コンテキストアクションとドラッグ＆ドロップサポート  \n* 開いているファイル全部を一度に検索・置換  \n* GitLab UIから直接ブラウザで開けるため、クイックなコード修正などに便利\n\n## IDEのFAQ（よくある質問）\n\n### Q: IDE（統合開発環境）を使う理由は何ですか。  \nA: IDEはソフトウェア開発環境の一部を構成しています。よく設計されたIDEを使うと、ソフトウェア開発が大幅に効率化できます。\n\n### Q: IDEの3つの主要コンポーネントは何ですか。\n\nA: コードエディタ、コンパイラ、デバッガーが三大コンポーネントです。\n\n### Q: IDEのインストール、設定方法は？\n\nA: ニーズに合ったIDEを選び、最新バージョンを公式サイトから入手してインストールします。ほとんどのIDEで、各種設定は使用環境に合わせてカスタマイズ可能です。 \n\n## GitLab Web IDEを使ってみる\n\nGitLabのWeb IDE は、SaaSおよびSelf-Managedのサブスクリプションを購入されているお客様には無償でお試しいただけます。詳しくは[こちら](https://about.gitlab.com/direction/create/ide/web_ide/)をご覧ください。\n\n\u003Cbr>\u003Cbr>\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)* \u003Cbr>\n*（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n",[865,796,765,797],{"slug":1124,"featured":91,"template":800},"what-is-ide",{"content":1126,"config":1135},{"title":1127,"description":1128,"authors":1129,"heroImage":1131,"date":1132,"body":1133,"category":776,"tags":1134},"GitLabのカスタムコンプライアンスフレームワークをDevSecOps環境で活用する方法","新しいフレームワークと、50個を超えるすぐに使えるコントロールを活用することで、これまでひとつずつチェックしていた規制要件を、統合された自動化ワークフローの一部へと変換する方法をご紹介します。",[1130],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","2025-04-30","コンプライアンスは、単なるチェック項目ではなく、業務リスクから顧客の信頼に至るまで、あらゆるものに影響を与える重要なビジネス機能です。開発チームにとっては、コンプライアンス要件と開発速度のバランスを取ることは特に困難です。GitLabの[カスタムコンプライアンスフレームワーク](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)を使えば、コンプライアンスの確認を開発ワークフローに直接統合することができます。この記事では、この機能の概要と、その効果を最大限に活用する方法についてご紹介します。\n\n## GitLabのカスタムコンプライアンスフレームワークとは？\n\nGitLabのカスタムコンプライアンスフレームワークを使うと、組織は自社のGitLabインスタンス内で、コンプライアンス基準を定義・実装・適用できます。この機能により、GitLabに元々備わっているコンプライアンス機能を拡張し、特定の規制要件や社内ポリシー、業界標準に合わせたカスタマイズ可能なフレームワークを作成できるようになります。\n\nカスタムコンプライアンスフレームワークには、次のようなメリットがあります。\n* 手動での追跡作業にかかる手間を削減\n* 監査対応の準備を加速\n* コンプライアンス制御をGitLab上でネイティブに適用\n\n![フレームワークが一覧表示されたコンプライアンスセンターのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\n今回のリリースでは、50個を超えるすぐに使える（OOTB）コントロールが提供されており（今後さらに追加予定）、医療分野のHIPAA、データプライバシーに関するGDPR（EU一般データ保護規則）、サービス組織向けのシステムおよび組織管理（SOC）2、その他業界固有の規制など、組織ごとのコンプライアンスのニーズに合わせて調整できます。OOTBコントロールの一例は以下のとおりです。\n\n* 職務分離（SoD、例：最低2名の承認者が必要、作成者によるマージリクエストの承認）\n* セキュリティスキャナの実行（例：SASTの実行、[依存関係スキャン](https://docs.gitlab.com/user/application_security/dependency_scanning/)の実行）\n* 認証/認可（例：プロジェクトの公開設定が非公開、AuthSSOが必須）\n* アプリケーション構成（例：ステータスチェックが必須、Terraformが必須）\n\nさらに、GitLab APIを使用して外部環境のコントロールを構成することもでき、外部環境のステータスや詳細を確認できます。\n\n## ゼロからカスタムコンプライアンスフレームワークを作成する\n\nその価値を理解できたところで、次はGitLab環境でカスタムコンプライアンスフレームワークを実装する方法を見ていきましょう。デモアプリケーションを使って説明しますので、動画を見ながら一緒に進めてください。\n\n**注：** GitLab Ultimateのサブスクリプションが必要です。\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**ステップ1：コンプライアンス要件を定義する**\n\nカスタムフレームワークを構築する前に、まずはコンプライアンス要件を明確に定義する必要があります。\n\n1. **適用される規制を特定する：** 自社に適用される規制や標準（例：GDPR、PCI DSS、HIPAA）を確認します。\n2. **各要件に対応するコントロールを割り当てる：** 各規制を、具体的で実行可能なコントロールとして整理します。\n3. **要件に優先順位を付ける：** リスクの高い領域や、影響の大きい要件を優先します。\n\n**ステップ2：カスタムコンプライアンスフレームワークを作成する**\n\n以下の手順でカスタムコンプライアンスフレームワークを作成できます。\n\n1. GitLabグループの**セキュア  > コンプライアンスセンター**セクションに移動します。\n2. **新しいフレームワーク**ボタンを押します。  \n3. **空のフレームワークを作成**を選択します。\n\n![カスタムコンプライアンスフレームワークの作成画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. フレームワークの名前、説明、色を設定します。\n\n![「新しいコンプライアンスフレームワーク」の画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. フレームワークに要件を追加します：\n   a. ページを下にスクロールして**要件**タブを開きます。\n\n   b. **新しい要件**ボタンをクリックします。\n\n   c. 名前と説明を入力します。\n   d. **コントロール**セクションで**GitLab コントロールを選択**をクリックします。  \n   e. 一覧からコントロールを選択します（例：少なくとも 2 つの承認、SAST の実行など）。 \n   f.  **要求事項を作成**ボタンをクリックします。\n\n![「要求事項を作成」ボタン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378652/Blog/oufh8frdwiq1os85byin.png)\n\n6. **フレームワークを作成**ボタンをクリックします。\n\n指定した内容でフレームワークが作成され、プロジェクトに追加できるようになります。また、適切なスキーマに準拠したJSONを使用して、コンプライアンスフレームワークを[インポート](http://TODO)することも可能です。\n\n**ステップ3：プロジェクトにフレームワークを適用する**\n\nフレームワークを作成したら、以下の手順に従います。\n1. コンプライアンスセンターから**プロジェクト**タブを選択します。\n2. 検索バーを使って対象のプロジェクトを**検索**または**絞り込み**ます。 \n3. フレームワークを適用するプロジェクトを選択します。\n4. **一括操作を選択**ボタンをクリックします。\n5. **選択したプロジェクトにフレームワークを適用する**を選択します。\n6. **フレームワークを選択**ボタンをクリックします。\n7. 一覧から適用するフレームワークを選択します。\n8. **適用**ボタンをクリックします。\n\n![SOC 2フレームワークのドロップダウンが表示されたコンプライアンスセンターの画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n適用されたフレームワークは、プロジェクト内で要求事項として可視化され、追跡できるようになります。\n\n**ステップ4：コンプライアンスの状況をモニタリング・報告する**\n\nフレームワークを設定したら、以下のことができるようになります。\n\n1. コンプライアンスセンターを使って、プロジェクト全体のコンプライアンス状況を管理する。不合格となったコントロールの詳細や、推奨される修正方法も確認できます。\n2. 監査や関係者によるレビューへ向けた、**コンプライアンスレポート**を生成する。\n3. **コンプライアンスに関するアラート**を設定し、潜在的な問題を関係者へ通知する。\n4. **監査イベント**で、コンプライアンス設定に対して行われた操作の概要を確認する。\n\n![SOC2テストフレームワークが表示されたコンプライアンスセンターの画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\n## 実例：SOC2 コンプライアンスフレームワークの実装\n\nシステムおよび組織管理（SOC）2、通称SOC2は、米国公認会計士協会（AICPA）によって策定された、厳格な監査基準です。SOC2は、サービス組織のセキュリティ、可用性、処理の完全性、機密性、プライバシーに関するコントロールを評価します。詳細については、[GitLabでSOC 2のセキュリティ要件を満たすためのガイド](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/)をご覧ください。\n\nそれでは、カスタムコンプライアンスフレームワークを使って SOC2 のセキュリティコンプライアンスを検証する実践的な例を見てみましょう。SOC2 のセキュリティ基準には以下が求められます。\n\n* 不正アクセスを防ぐためのコントロールの導入\n* リスクを特定し、軽減するための手順の確立\n* セキュリティインシデントの検出および対応のためのシステムの構築\n\n**免責事項：** これはSOC2の要件に準拠するために利用可能な一部のコントロールを紹介する例です。本番環境に導入する前に、必ずセキュリティ/コンプライアンスチームと相談してください。\n\nGitLabのOOTB（すぐに使える）コントロールを活用したSOC2用カスタムコンプライアンスフレームワークの例：\n\n* **名前：** SOC2セキュリティ要件\n* **説明：** SOC2フレームワークに準拠するためのセキュリティ要件を追加します\n* **要件：**  \n  * **不正アクセスを防ぐためのコントロールの導入**  \n    * Auth SSOを有効化\n    * CI/CDジョブトークンのスコープを有効化\n    * 組織レベルでMFA（多要素認証）を必須化\n  * **リスクを特定し、軽減するための手順の確立**  \n    * 少なくとも2つの承認\n    * 作成者によるマージリクエストの承認\n    * コミッターによるマージリクエストの承認\n    * デフォルトブランチの保護\n  * **セキュリティインシデントの検出および対応のためのシステムの構築**  \n    * 依存関係スキャンの実行\n    * SASTの実行\n    * DASTの実行\n\nこのフレームワークをプロジェクトに適用することで、コンプライアンスが崩れたタイミングや、再度準拠するために必要な対策を把握できるようになります。なお、1つのプロジェクトに対して複数のコンプライアンスフレームワークを作成・適用することも可能です。たとえば、SOC2のプロセス整合性要件専用のフレームワークを別途設けることもできます。\n\n## コンプライアンス要件を満たすためにセキュリティポリシーを実装する\n\n必須ではありませんが、カスタムコンプライアンスフレームワークを含むプロジェクトにセキュリティポリシーを適用することができます。これにより、特定のコンプライアンス基準がセキュリティポリシーによって強制されることを保証できます。たとえば、セキュリティスキャンを求めるカスタムコンプライアンスフレームワークが適用されたプロジェクトに対して、セキュリティスキャナーの実行を強制できます。\n\nGitLab では、以下のようなさまざまなセキュリティポリシーが提供されています。\n\n* [スキャン実行ポリシー](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/)：パイプラインの一部または指定されたスケジュールでセキュリティスキャンを実行します。\n* [マージリクエスト承認ポリシー](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/)：スキャン結果に基づいて、プロジェクトレベルの設定や承認ルールを強制します。\n* [パイプライン実行ポリシー](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/)：プロジェクトのパイプラインにおけるCI/CDジョブの実行を強制します。\n* [脆弱性管理ポリシー](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/)：デフォルトブランチで検出されなくなった脆弱性を自動的に解決します。\n\nここでは、SASTスキャナーを実行することで、SASTスキャンを要求する要件への準拠を自動的に行う方法を紹介します。特定のフレームワークが適用されたプロジェクトに対してセキュリティポリシーを作成・適用するには、次の手順に従います。\n\n1. **SAST スキャン**が求められるカスタムコンプライアンスフレームワークが適用されているプロジェクトに移動します。\n2. サイドバーで、**セキュア > ポリシー**の順に選択します。\n3. **新しいポリシー**ボタンをクリックします。\n4. **スキャン実行ポリシー**で、**ポリシーを選択**ボタンをクリックします。\n5. **名前**と**説明**を入力します。\n6. **アクション**で、実行するスキャンとして**SAST**を選択します。\n\n![「アクション」画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n7. **条件**で、すべてのブランチでパイプラインが実行されたときにトリガーされるように設定します。\n\n![「条件」画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n8. **マージリクエスト経由で設定** ボタンをクリックします。\n9. この時点で、すべてのセキュリティポリシーが含まれた別プロジェクトでマージリクエスト（MR）が作成されます。\n10. **マージ**ボタンをクリックします。\n\nこれで、すべてのブランチでSASTが実行されるようになり、その領域におけるコンプライアンスが保証されます。他にもさまざまな種類のセキュリティポリシーがありますので、要件に合うものを探してみてください。\n\n\n\n## 5つのベストプラクティス\n\nカスタムコンプライアンスフレームワークを最大限に活用するために、以下のベストプラクティスに従いましょう。\n\n1. **小さく始める：** まずは、重要な規制や標準のうち1つから着手し、そこから範囲を広げていきましょう。\n2. **関係者を巻き込む：** フレームワークの作成には、コンプライアンスチーム、セキュリティチーム、デベロッパーチームを含めることが重要です。\n3. **可能な限り自動化する：** GitLab CI/CDを活用して、コンプライアンスチェックの自動化を図りましょう。\n4. **しっかりと文書化する：** フレームワークがどのように規制要件に対応しているか、明確に文書化しておきましょう。\n5. **定期的に見直す：** 規制の変更や新たな要件の発生に応じて、フレームワークを更新するようにしましょう。\n\n## 無料トライアルで今すぐスタート！\n\nGitLabのカスタムコンプライアンスフレームワークは、コンプライアンスを開発ワークフローに直接組み込むことで、DevSecOpsにおける大きな進化をもたらします。カスタムフレームワークを導入することで、コンプライアンス業務の負担を軽減し、リスク管理を強化しながら、規制要件を満たしたまま開発サイクルを加速させることが可能になります。\n\nカスタムコンプライアンスフレームワークを定義・適用できる機能により、チームは自社特有の規制状況に対応する柔軟性を得られる一方で、組織全体のコンプライアンスの慣習を一貫させるために必要な構造も得られます。\n\n今後さらに規制要件が複雑化していく中で、カスタムコンプライアンスフレームワークのようなツールを活用して、コンプライアンスと開発速度のバランスを持続的に両立させることが、ますます重要になるでしょう。\n\n> 今すぐカスタムコンプライアンスフレームワークをお試しになりたい場合は、[GitLab Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)にぜひお申し込みください。\n\n## 関連リンク\n\n以下のリソースで、カスタムコンプライアンスフレームワークの詳細や、そのメリットについてご覧いただけます。\n\n* [カスタムコンプライアンスフレームワークのドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)  \n* [カスタムコンプライアンスフレームワークに関するエピック](https://gitlab.com/groups/gitlab-org/-/epics/13295)  \n* [セキュリティポリシーに関するドキュメント](https://docs.gitlab.com/user/application_security/policies/)  \n* [GitLabのセキュリティおよびコンプライアンスソリューション](https://about.gitlab.com/ja-jp/solutions/security-compliance/)",[776,797,795,796,765],{"slug":1136,"featured":91,"template":800},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"content":1138,"config":1147},{"title":1139,"description":1140,"authors":1141,"heroImage":1142,"date":1143,"body":1144,"category":776,"tags":1145},"GitLab + HackerOneでアプリケーションセキュリティを強化","GitLabとHackerOne社のパートナーシップの詳細と、組織のアプリケーションセキュリティ対策状況を強化するインテグレーションを簡単に導入する方法をご紹介します。",[1130],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","2025-04-03","開発プロセスにおいて、セキュリティはもはや後回しにできるものではありません。組織には、ソフトウェア開発ライフサイクル全体にセキュリティを統合できる堅牢なソリューションが求められています。ここで、HackerOne社とGitLabのパートナーシップが、現代のアプリケーション開発チームにとって魅力的な組み合わせとなります。\n\n\nGitLabはAI搭載の包括的なDevSecOpsプラットフォームであり、HackerOneは業界をリードするクラウドソーシング型セキュリティプラットフォームです。この2社がパートナーシップを結び、GitLabの効率的なDevSecOpsワークフローと、HackerOneの強力な脆弱性管理機能という両者の強みを融合させました。\n\n\nこのチュートリアルでは、HackerOneのGitLabインテグレーションを実装することで、デベロッパーの生産性とセキュリティ対策状況を強化する方法を説明します。\n\n\n## デベロッパーを支援するインテグレーション\n\n\nHackerOneのGitLabインテグレーションは、非常にシンプルでありながら強力です。セキュリティ研究者がHackerOneのプラットフォーム上で脆弱性を発見すると、その情報で自動的にGitLabのイシューが作成されます。これにより、以下のようなシームレスなワークフローが実現します。\n\n\n* セキュリティ研究者がHackerOneのプラットフォームで脆弱性を特定\n\n* 検証済みの脆弱性について自動的にGitLabのイシューが作成される\n\n* 開発チームは既存のワークフロー内でこれらのイシューに直接対応できる\n\n* 解決状況は両プラットフォーム間で同期される\n\n\nこの[インテグレーション](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)を使うことで、GitLabイシューをHackerOne上の参照として追跡でき、GitLabとHackerOneの強みをすぐに取り入れることができます。このインテグレーションにより、HackerOneのレポートとGitLabイシュー間で双方向かつシームレスなデータ同期が可能となり、開発チームとセキュリティチームの連携が強化され、セキュリティの脆弱性への対応が効率化します。\n\n\nHackerOneレポートとGitLabイシュー間で情報を同期するには、[HackerOneのGitLabインテグレーションのドキュメント](https://docs.hackerone.com/en/articles/10394699-gitlab-setup)に従って設定を行ってください。このドキュメントでは、以下の手順が解説されています。\n\n\n1. HackerOneの設定に基づいた[OAuth\n2.0アプリケーション](https://docs.gitlab.com/ee/integration/oauth_provider.html)をGitLabインスタンス上に作成する\n\n2. HackerOneと新たに作成したGitLabのOAuth 2.0を接続する\n\n3. GitLab APIへのアクセスをHackerOneに許可する \n\n4. HackerOneレポートをエスカレーションするGitLabプロジェクトを設定する\n\n5. HackerOneの各フィールドをGitLabの対応するフィールドにマッピングする\n\n6. GitLabからHackerOne、およびHackerOneからGitLabへのイベントを設定する\n\n\nインテグレーションを完了すると、GitLabとHackerOneの間でデータが双方向にシームレスに同期されます。これにより、コンテキストの切り替えが簡素化され、両方のシステムで脆弱性を簡単に追跡できるようになります。このインテグレーションにより、次の機能が使用できます。\n\n\n* **HackerOneからGitLabイシューを作成：**HackerOneで受け取ったレポートに基づき、新しいGitLabイシューを作成できます。\n\n* **HackerOneレポートを既存のGitLabタスクにリンク**   \n\n* **HackerOneからGitLabへの更新内容の同期：** レポートの以下の更新情報がGitLabのコメントとして同期されます。\n   * レポートのコメント\n  * ステータスの変更  \n  * 報酬情報\n  * 担当者の変更\n  * 公開設定の変更\n  * GitLabイシューのクローズ\n* **GitLabからHackerOneへの更新内容の同期：**\nGitLabの以下の更新情報がHackerOneの関連レポートの内部コメントとして反映されます。 \n  * コメント \n  * ステータスの変更\n* **HackerOneの重大度とGitLabラベルのマッピング：**\nレポートをGitLabにエスカレーションする際、カスタムの優先度を設定できます。 \n\n* **期限のマッピング：** レポートの重大度に基づいて、自動で期限を設定できます。\n\n\n![GitLab +\nHackerOneによる、GitLabでのレポートへのコメント追加およびステータス変更](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\n\nこれらの機能により、開発チームとセキュリティチームの連携がよりスムーズになり、効率よくセキュリティの脆弱性に対応できます。インテグレーションの仕組みについてさらに詳しく知りたい場合は、[インテグレーションドキュメント](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)をご覧ください。\n\n\n## HackerOne社のバグバウンティプログラムについて\n\n\nHackerOne社は、顧客のソフトウェアシステム、Webサイト、またはアプリケーションに存在する脆弱性を発見・報告することで報酬が得られる、バグバウンティプログラムやサイバーセキュリティ施策を提供しています。バグバウンティプログラムは、アプリケーションのセキュリティを強化する上で、以下のような役割を果たします。\n\n\n* 悪意ある攻撃者に悪用される前にセキュリティ上の欠陥を特定する\n\n* 世界中のセキュリティ研究者による多様な専門知識を活用する\n\n* コスト効率の高いサイバーセキュリティ強化手段を提供する\n\n* 社内のセキュリティ対策や従来型のペネトレーションテストを補完する\n\n\nGitLabはHackerOne社のバグバウンティプログラムを活用しており、セキュリティ研究者はGitLabのアプリケーションやインフラにおける脆弱性を報告できます。このクラウドソーシングによるアプローチにより、GitLabは潜在的なセキュリティ問題をより効果的に特定し、対処できます。\n\n\n![HackerOne社のGitLabバグバウンティページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\n\nHackerOneのプラットフォームと世界中のハッカーコミュニティを活用することで、組織はセキュリティ対策状況を大幅に強化し、脆弱性をより迅速に特定し、潜在的な脅威に先手を打つことができます。\n\n\n## GitLabでアプリケーションを保護し、効率性を向上させる\n\n\nGitLabは、セキュリティおよびコンプライアンスツールを含む、ソフトウェア開発ライフサイクル全体をカバーする完全なDevSecOpsプラットフォームを提供しています。GitLabは、以下の種類のセキュリティスキャナーに対応しています。\n\n- 静的アプリケーションセキュリティテスト（SAST）\n\n- 動的アプリケーションセキュリティテスト（DAST）\n\n- コンテナスキャン\n\n- 依存関係スキャン\n\n- Infrastructure as Codeスキャン\n\n- カバレッジガイド付きファジング\n\n- Web APIファジング\n\n\nGitLabを使えば、CI/CDパイプラインの定義ファイルにテンプレートを追加するだけで、セキュリティスキャンを導入できます。たとえば、SASTを有効にするには、.gitlab-ci.ymlファイルに数行のコードを追加するだけです。\n\n\n```yaml\n\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\n\nこれにより、testステージでSASTが実行され、アプリケーションで[使用されている言語を自動で検出](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)します。そして、マージリクエストが作成されるたびに、SASTがフィーチャーブランチとターゲットブランチ間の差分にある脆弱性を検出し、それぞれの脆弱性に関する修正のためのデータを提供します。\n\n\n![マージリクエストで検出されたNoSQLインジェクションの脆弱性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\n\nSASTスキャナーの結果は、セキュリティポリシーが適用されている場合、コードのマージをブロックすることができます。GitLabのネイティブユーザーを承認者として設定でき、脆弱なコードがマージされる前に必ずレビューを行うようにできます。これにより、すべての脆弱性が適切な関係者によって確認される体制が整います。\n\n\n![マージリクエストの承認ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\n\nHackerOneは、オペレーションおよび開発プロセスにおいてGitLabを複数の重要な方法で統合しており、それにより開発プロセスの改善、スケーラビリティの向上、チーム間のコラボレーションの強化を実現しています。こうした改善によって、デプロイがより迅速になり、チームプランニングもスムーズになります。\n\n\n## HackerOneのGitLabインテグレーションの主な利点\n\n\nHackerOneとGitLabを組み合わせて活用することで、以下のような主なメリットがあります。\n\n\n* **セキュリティの可視性向上：**\nデベロッパーは、普段の作業環境から離れることなく、セキュリティ上の脆弱性を即座に把握できます。リアルタイムで認識できるので、機能開発と並行してセキュリティ問題に優先順位を付けて対応できます。\n\n* **修正プロセスの効率化：**\nHackerOneのレポートを直接GitLabイシューに変換することで、修正作業が標準の開発サイクルに組み込まれます。プラットフォームを行き来する際の頭の切り替えを減らし、セキュリティ修正を他の開発作業と一緒に追跡できます。\n\n* **修正までの時間を短縮：**\nこのインテグレーションにより、脆弱性の発見から解決までの時間が大幅に短縮されます。HackerOneからの報告が即座にGitLabで確認できるため、デベロッパーは遅延なく修正に着手でき、全体的なセキュリティ対策状況の強化にもつながります。\n\n* **コラボレーションの改善：**\nセキュリティ研究者、セキュリティチーム、デベロッパーがこのインテグレーションを通じてより効果的に連携できます。コメントや更新情報が両プラットフォーム間でやり取りされ、セキュリティ強化に向けた協力体制が整います。\n\n* **実際の導入効果：** HackerOneとGitLabのインテグレーションを導入した組織では、以下のような成果が報告されています。\n  * 脆弱性の発見から修正までの時間が最大70%短縮\n  * デベロッパーが慣れ親しんだ作業環境のまま対応できることによる満足度の向上\n  * 組織全体でのセキュリティ可視性の向上\n  * セキュリティリソースのより効果的な活用\n\n>\n[インテグレーション設定ページ](https://docs.hackerone.com/en/articles/10394699-gitlab-setup)にアクセスして、今日から導入を始めましょう。\n\n\n## 関連リンク\n\n\nGitLabとHackerOneの詳細、およびセキュリティ対策状況の強化については、以下のリソースをご覧ください。\n\n*\n[HackerOneのGitLabインテグレーションの使用方法](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)  \n\n* [HackerOneのGitLabバグバウンティプログラム](https://hackerone.com/gitlab?type=team)\n\n*\n[GitLabのセキュリティおよびコンプライアンスソリューション](https://about.gitlab.com/ja-jp/solutions/security-compliance/)  \n\n*\n[HackerOne社は、GitLabにビルトインされたセキュリティにより、デプロイ速度を5倍まで高めることに成功](https://about.gitlab.com/ja-jp/customers/hackerone/)  \n\n*\n[GitLabアプリケーションセキュリティドキュメント](https://docs.gitlab.com/ee/user/application_security/)\n",[776,797,234,285,795,714,1146],"bug bounty",{"slug":1148,"featured":6,"template":800},"enhance-application-security-with-gitlab-hackerone",{"content":1150,"config":1152},{"title":965,"description":966,"authors":1151,"heroImage":969,"date":970,"body":971,"category":730},[968],{"featured":91,"template":800,"slug":973},[1154,1159,1164],{"content":1155,"config":1158},{"title":930,"description":931,"heroImage":932,"date":834,"body":933,"category":718,"tags":1156,"authors":1157},[896,838,865,714,280,552,776,922],[905],{"featured":91,"template":800,"slug":937},{"content":1160,"config":1163},{"heroImage":1078,"body":1079,"authors":1161,"updatedDate":1081,"date":1082,"title":1083,"tags":1162,"description":1085,"category":765},[905],[1010,838,765,109],{"featured":91,"template":800,"slug":1087},{"content":1165,"config":1168},{"heroImage":830,"body":831,"authors":1166,"updatedDate":834,"date":835,"title":836,"tags":1167,"description":839,"category":682},[833],[765,838,795,796,776],{"featured":91,"template":800,"slug":841},[1170,1175,1180],{"content":1171,"config":1174},{"title":940,"description":941,"authors":1172,"date":943,"body":944,"category":718,"heroImage":945,"tags":1173},[905],[947,838,864,865,896,714,280,776,922],{"featured":91,"template":800,"slug":949},{"content":1176,"config":1179},{"date":1042,"heroImage":1043,"title":1044,"authors":1177,"category":754,"body":1046,"description":1047,"tags":1178},[968],[865,1049,797,810],{"featured":91,"template":800,"slug":1051},{"content":1181,"config":1184},{"heroImage":1090,"body":1091,"authors":1182,"updatedDate":1093,"date":1094,"title":1095,"tags":1183,"description":1097,"category":765},[905],[1010,838,765,109],{"featured":91,"template":800,"slug":1099},1756472691922]