[{"data":1,"prerenderedAt":1184},["ShallowReactive",2],{"/ja-jp/blog/":3,"navigation-ja-jp":21,"banner-ja-jp":437,"footer-ja-jp":450,"blogCategories-ja-jp":659,"relatedBlogPosts-ja-jp":780,"maineFeaturedPost-ja-jp":1147,"recentFeaturedPosts-ja-jp":1152,"recentPosts-ja-jp":1168},{"_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","/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},"/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":291,"config":292},"ソースプロモカード",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.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},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":417,"config":422},{"src":423,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.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":655,"_type":16,"title":656,"_source":17,"_file":657,"_stem":658,"_extension":20},"/shared/ja-jp/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":647},"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,585,619],{"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,569,571,573,575,577,579,581,583],{"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":241,"dataGaLocation":459},{"text":239,"config":570},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":249,"config":572},{"href":251,"dataGaName":252,"dataGaLocation":459},{"text":262,"config":574},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":254,"config":576},{"href":256,"dataGaName":257,"dataGaLocation":459},{"text":267,"config":578},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":580},{"href":274,"dataGaName":275,"dataGaLocation":459},{"text":277,"config":582},{"href":279,"dataGaName":280,"dataGaLocation":459},{"text":282,"config":584},{"href":284,"dataGaName":285,"dataGaLocation":459},{"title":300,"links":586},[587,589,591,593,595,597,599,603,608,610,612,614],{"text":307,"config":588},{"href":309,"dataGaName":302,"dataGaLocation":459},{"text":312,"config":590},{"href":314,"dataGaName":315,"dataGaLocation":459},{"text":320,"config":592},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":594},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":330,"config":596},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":335,"config":598},{"href":337,"dataGaName":338,"dataGaLocation":459},{"text":600,"config":601},"Sustainability",{"href":602,"dataGaName":600,"dataGaLocation":459},"/sustainability/",{"text":604,"config":605},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":606,"dataGaName":607,"dataGaLocation":459},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":609},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":350,"config":611},{"href":352,"dataGaName":353,"dataGaLocation":459},{"text":355,"config":613},{"href":357,"dataGaName":358,"dataGaLocation":459},{"text":615,"config":616},"現代奴隷制の透明性に関する声明",{"href":617,"dataGaName":618,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":620},[621,623,625,627,632,637,642],{"text":35,"config":622},{"href":37,"dataGaName":38,"dataGaLocation":459},{"text":368,"config":624},{"href":370,"dataGaName":371,"dataGaLocation":459},{"text":373,"config":626},{"href":375,"dataGaName":376,"dataGaLocation":459},{"text":628,"config":629},"ステータス",{"href":630,"dataGaName":631,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":633,"config":634},"利用規約",{"href":635,"dataGaName":636,"dataGaLocation":459},"/terms/","terms of use",{"text":638,"config":639},"プライバシーに関する声明",{"href":640,"dataGaName":641,"dataGaLocation":459},"/ja-jp/privacy/","privacy statement",{"text":643,"config":644},"Cookieの設定",{"dataGaName":645,"dataGaLocation":459,"id":646,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":648},[649,651,653],{"text":633,"config":650},{"href":635,"dataGaName":636,"dataGaLocation":459},{"text":638,"config":652},{"href":640,"dataGaName":641,"dataGaLocation":459},{"text":643,"config":654},{"dataGaName":645,"dataGaLocation":459,"id":646,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",[660,674,686,698,710,722,734,746,758,769],{"_path":661,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":663,"content":666,"config":667,"_id":670,"_type":16,"title":671,"_source":17,"_file":672,"_stem":673,"_extension":20},"/ja-jp/blog/categories/agile-planning","categories",{"title":664,"description":665},"アジャイル計画","Browse articles related to アジャイル計画 on the GitLab Blog",{"name":664},{"template":668,"slug":669,"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":675,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":676,"content":679,"config":680,"_id":682,"_type":16,"title":683,"_source":17,"_file":684,"_stem":685,"_extension":20},"/ja-jp/blog/categories/ai-ml",{"title":677,"description":678},"AIと機械学習","Browse articles related to AIと機械学習 on the GitLab Blog",{"name":677},{"template":668,"slug":681,"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":687,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":688,"content":691,"config":692,"_id":694,"_type":16,"title":695,"_source":17,"_file":696,"_stem":697,"_extension":20},"/ja-jp/blog/categories/bulletin-board",{"title":689,"description":690},"掲示板","Browse articles related to 掲示板 on the GitLab Blog",{"name":689},{"template":668,"slug":693,"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":699,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":700,"content":703,"config":704,"_id":706,"_type":16,"title":707,"_source":17,"_file":708,"_stem":709,"_extension":20},"/ja-jp/blog/categories/customer-stories",{"title":701,"description":702},"お客様事例","Browse articles related to お客様事例 on the GitLab Blog",{"name":701},{"template":668,"slug":705,"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":711,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":712,"content":715,"config":716,"_id":718,"_type":16,"title":719,"_source":17,"_file":720,"_stem":721,"_extension":20},"/ja-jp/blog/categories/devsecops",{"title":713,"description":714},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":713},{"template":668,"slug":717,"hide":6},"devsecops","content:ja-jp:blog:categories:devsecops.yml","Devsecops","ja-jp/blog/categories/devsecops.yml","ja-jp/blog/categories/devsecops",{"_path":723,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":724,"content":727,"config":728,"_id":730,"_type":16,"title":731,"_source":17,"_file":732,"_stem":733,"_extension":20},"/ja-jp/blog/categories/engineering",{"title":725,"description":726},"エンジニアリング","Browse articles related to エンジニアリング on the GitLab Blog",{"name":725},{"template":668,"slug":729,"hide":6},"engineering","content:ja-jp:blog:categories:engineering.yml","Engineering","ja-jp/blog/categories/engineering.yml","ja-jp/blog/categories/engineering",{"_path":735,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":736,"content":739,"config":740,"_id":742,"_type":16,"title":743,"_source":17,"_file":744,"_stem":745,"_extension":20},"/ja-jp/blog/categories/news",{"title":737,"description":738},"ニュース","Browse articles related to ニュース on the GitLab Blog",{"name":737},{"template":668,"slug":741,"hide":6},"news","content:ja-jp:blog:categories:news.yml","News","ja-jp/blog/categories/news.yml","ja-jp/blog/categories/news",{"_path":747,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":748,"content":751,"config":752,"_id":754,"_type":16,"title":755,"_source":17,"_file":756,"_stem":757,"_extension":20},"/ja-jp/blog/categories/open-source",{"title":749,"description":750},"オープンソース","Browse articles related to オープンソース on the GitLab Blog",{"name":749},{"template":668,"slug":753,"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":759,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":760,"content":762,"config":763,"_id":765,"_type":16,"title":766,"_source":17,"_file":767,"_stem":768,"_extension":20},"/ja-jp/blog/categories/product",{"title":90,"description":761},"Browse articles related to 製品 on the GitLab Blog",{"name":90},{"template":668,"slug":764,"hide":6},"product","content:ja-jp:blog:categories:product.yml","Product","ja-jp/blog/categories/product.yml","ja-jp/blog/categories/product",{"_path":770,"_dir":662,"_draft":6,"_partial":6,"_locale":7,"seo":771,"content":773,"config":774,"_id":776,"_type":16,"title":777,"_source":17,"_file":778,"_stem":779,"_extension":20},"/ja-jp/blog/categories/security",{"title":126,"description":772},"Browse articles related to セキュリティ on the GitLab Blog",{"name":126},{"template":668,"slug":775,"hide":6},"security","content:ja-jp:blog:categories:security.yml","Security","ja-jp/blog/categories/security.yml","ja-jp/blog/categories/security",[781,825,865,879,922,960,998,1036,1073,1110],{"category":664,"slug":669,"posts":782},[783,800,813],{"content":784,"config":797},{"title":785,"description":786,"authors":787,"heroImage":789,"date":790,"body":791,"category":669,"tags":792},"GitLabで実現するサイロのないSAFe","Scaled Agile Framework（SAFe）をDevSecOpsプラットフォームのネイティブ機能にマッピングする方法と、そこから得られるメリットについて学びましょう。",[788],"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",[793,794,795,764,796],"agile","DevSecOps platform","features","tutorial",{"slug":798,"featured":91,"template":799},"safe-without-silos-in-gitlab","BlogPost",{"content":801,"config":811},{"title":802,"description":803,"authors":804,"heroImage":805,"date":806,"body":807,"category":669,"tags":808,"updatedDate":810},"アジャイルのスプリントを製品ロードマップと調和させる方法","ベストプラクティスとGitLabの機能を活用して、製品開発を進めましょう。一元化されたロードマップの作成、レビューセッションの実施、スプリントのライフサイクルの追跡など、製品開発をスムーズに進めるためのポイントを解説します。",[788],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[793,796,809,794],"workflow","2025-06-04",{"slug":812,"featured":91,"template":799},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"content":814,"config":823},{"title":815,"description":816,"authors":817,"heroImage":818,"date":819,"body":820,"category":669,"tags":821,"updatedDate":822},"アジャイルプランニングチームに特化したGitLabの新しい「プランナー」ロールのご紹介","GitLabの新しい「プランナー」ロールを活用して、SaaS、GitLab Dedicated、Self-Managedといった各ソリューションでのアクセス権を最適化し、アジャイルチームの計画ワークフローを効率的に管理する方法についてご説明します。",[788],"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",[793,794,795,764],"2025-05-01",{"slug":824,"featured":91,"template":799},"introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"category":677,"slug":681,"posts":826},[827,841,853],{"content":828,"config":839},{"heroImage":829,"body":830,"authors":831,"updatedDate":833,"date":834,"title":835,"tags":836,"description":838,"category":681},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662465/Blog/Hero%20Images/GitLab_Duo_Workflow_Unified_Data_Store__1_.png","[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)（現在ベータ版で提供中）は、AIエージェントがイシューやマージリクエストなどのGitLabリソースとやり取りできるフレームワークを提供し、コンセプトから完成まで複雑な多段階タスク実行を可能にします。Agent Platformは、コード生成、モダナイゼーション、セキュリティ脆弱性の修正、プロジェクト分析を支援する対話型（[エージェント型チャット](https://about.gitlab.com/ja-jp/blog/gitlab-duo-chat-gets-agentic-ai-makeover/)）と自動化型（[エージェントフロー](https://about.gitlab.com/ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/)）のエクスペリエンスを提供します。これらはすべてエンタープライズレベルのセキュリティとカスタマイズ可能な制御機能も備えています。\n\n「イシューからMR」は、適切にスコープが定義されたイシューを、ドラフトのマージリクエスト（MR）に変換するプロセスを効率化するエージェントフローです。このフローはイシューの説明と要件を分析し、イシューにリンクされたドラフトMRを開き、開発計画を作成し、実装案を提案します。これらすべてがGitLab UIから直接実行できます。\n\n## デベロッパーが直面する課題\n\nUIレイアウトの調整、コンポーネントのサイズ変更、ワークフローの微調整といった製品の小さな改善に、何時間もの設定作業は必要ないはずです。しかし、デベロッパーはこのようなイライラするサイクルに陥りがちです。適切なファイルを見つけるためにコードベースを探し回り、ブランチを作成し、複数のコンポーネントに散在する変更をまとめ、複雑なレビュープロセスを経る必要があります。そして、これらはすべて、ソリューションが実際に機能するかどうかを確認できる前の作業です。開発のオーバーヘッドにより、本来であれば素早い反復作業であるべきものが時間のかかるタスクに変わり、フィードバックループが遅くなり、シンプルな製品の改善が大掛かりな取り組みのように感じられてしまいます。\n\n## 「イシューからMRフロー」を使ってアプリケーションの更新を加速する方法\n\n「イシューからMRフロー」を使用する前に、以下の前提条件を満たす必要があります。\n\n前提条件：\n\n* 明確な要件と受け入れ基準が記載された既存のイシュー。これにより、達成しようとしていることをGitLab Duo Agent Platformがよく理解し、出力の品質を向上させることができます。\n* プロジェクトのソースコードを編集するフローのため、Developer以上の権限を持つプロジェクトアクセス。\n* グループまたはプロジェクトでGitLab Duo Agent Platformが有効になっており、「フロー」が許可されていること。これには、プロジェクトの**設定 > 一般 > GitLab Duo > フローの実行の許可**トグルを有効にしてください。GitLabは適切なガードレールの提供に取り組んでおり、エージェント型AI機能では機密性の高いプロジェクトを保護し、GitLab Duo Agent Platformがアクセスしてほしいプロジェクトのみを許可するため、これらのトグルを有効にする必要があります。\n\n上記のすべての前提条件を満たしたら、以下の手順に従ってイシューからMRフローを活用できます：\n\n1. GitLab Duo Agent Platformに実行してもらいたいことを説明するプロジェクトイシューを作成します。イシューの説明にできるだけ詳細を記載してください。イシューがすでに存在する場合は、**計画 > イシュー**に移動し、更新したい内容を説明しているイシューをクリックして開きます。イシューのスコープは明確かつ具体的に設定してください。\n\n2. イシューヘッダーの下にある**Duoでマージリクエストを生成**をクリックしてフローを開始します。\n\n3. イシューの実装に取り組むエージェントの進行状況を追跡したい場合は、**自動化 > エージェントセッション**に移動して、エージェントが計画を立てて、変更を提案している様子をライブセッションログで確認できます。\n\n4. パイプラインが完了すると、イシューのアクティビティにMRへのリンクが表示されます。これを開いて、サマリーとファイルレベルの変更を確認してください。\n\n5. GitLab Duo Agent Platformが提案した更新をローカルで検証したい場合は、ラップトップにブランチをプルし、アプリをビルド・実行し、更新が期待通りに動作することを確認できます。必要に応じてMRで編集を行い、通常のレビューを進めてください。\n\n6. 提案されたアプリケーションの更新にすべて満足したら、MRをメインブランチにマージします。\n\n## 「イシューからMRフロー」がアプリケーションの変更に効果的な理由\n\n「イシューからMRフロー」はコード変更を提案し、MRを直接更新するため、ファイルを探す時間が短縮され、結果の評価とレビューのみに集中できます。さらに、MRは自動的に元のイシューにリンクされ、レビュアーや関係者にとってコンテキストが明確に保たれます。また、エージェントセッションをモニタリングすることで、各ステップで何が起こっているかを把握できます。\n\n## GitLab Duo Agent Platformのメリット\n\nGitLab Duo Agent Platformは、**完全なプロジェクトコンテキスト**を提供する[エージェント型オーケストレーションレイヤー](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-public-beta/)で、プランニングからコーディング、ビルド、セキュリティ、デプロイ、監視まで含むため、エージェントは単なるコード編集だけでなく、ソフトウェア開発ライフサイクル（SDLC）全体をサポートできます。\n\n* 統合データモデル：GitLab DuoエージェントはGitLabの統合されたSDLCデータ上で動作し、コーディング以外のタスクを含めて、より質の高い意思決定とコラボレーションを可能にします。\n\n* セキュリティとコンプライアンスがビルトイン：GitLab Duoエージェントはエンタープライズのガードレール内で実行され、高度に規制された環境やオフライン/エアギャップ環境でも使用できます。\n\n* 相互運用性と拡張性：ベンダーやツール間でフローをオーケストレートします。[MCP](https://about.gitlab.com/topics/ai/model-context-protocol/)/A2A経由で外部データを接続し、より豊富なコンテキストを提供します。\n\n* コラボレーションのスケール：GitLab DuoエージェントはGitLab UIとIDEで動作し、複数の人間と複数のエージェント間のコラボレーションを可能にします。\n\n* 検索可能かつ共有可能：一元化されたAIカタログでエージェントとフローを検索・共有できます。\n\n## 今すぐ「イシューからMRフロー」を試してみましょう\n\nアプリケーションの更新、例えばUI調整のような小規模な作業では、「イシューからMRフロー」によって、明確に定義されたイシューからレビュー可能なMRまでを素早く作成できます。進行状況を監視でき、標準のワークフローで変更内容を検証・マージできます。チームはコンテキストを保ちつつ、引き継ぎ作業を削減できるので、単純作業ではなく品質に注力できるようになります。\n\nイシューからMRフローの動作を実際にご覧ください：\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/BrrMHN4gXF4?si=J7beTgWOLxvS4hOw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> [GitLab UltimateとDuo Enterpriseの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)で今すぐGitLab Duo Agent PlatformのイシューからMRフローを試してみましょう。\n\n\n",[832],"Cesar Saavedra","2025-09-05","2025-09-03","GitLab Duo Agent Platform：イシューからMRフロー",[837,764,795,796],"AI/ML","デベロッパーが数分でアイデアを実際のコードに変換。最新のエージェントフローでアプリケーションを素早く更新する方法をご紹介します。",{"featured":91,"template":799,"slug":840},"vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow",{"content":842,"config":851},{"heroImage":843,"body":844,"authors":845,"updatedDate":834,"date":847,"title":848,"tags":849,"description":850,"category":681},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098208/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098208185.jpg","人工知能（AI）は、あらゆる業界で働き方や問題解決の方法を変革しています。AIがビジネスプロセスや意思決定により深く統合されるにつれて、堅牢なAIガバナンスフレームワークの必要性がかつてないほど重要になっています。組織はAIの潜在的な機会と、AIシステムが安全で倫理的、かつ説明責任を持って構築されることを保証することの間でバランスを取らなければなりません。\n\n責任あるAI管理への取り組みの一環として、GitLabがISO/IEC 42001認証を取得したことを発表いたします。これは、組織内でAI管理システム（AIMS）を確立、実装、維持、継続的改善するための国際的に認められた初の標準です。\n\n認証の範囲には、当社の包括的なAI製品であるGitLab Duo、およびGitLab Duo Agent Platformとそのコンポーネントが含まれます。DevSecOpsのリーダーとして、GitLabは開発ライフサイクル全体にわたってAI駆動機能を提供しており、以下のような機能があります：\n\n* [GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-public-beta/)（パブリックベータ版、今年後半の一般提供を予定）：ソフトウェア開発ライフサイクル全体を通じて、デベロッパーと専門的なAIエージェント間の非同期コラボレーションを可能にし、線形開発プロセスを動的な並列ワークフローに変換しながら、GitLabの統一プラットフォーム内に保存されたすべてのソフトウェアエンジニアリングコンテキストへのアクセスをエージェントに提供します。\n\n* [コード提案](https://docs.gitlab.com/user/project/repository/code_suggestions/)（一般提供中）：コードブロックを予測的に補完し、関数ロジックを定義し、テストを生成し、正規表現パターンなどの一般的なコードを提案することで、デベロッパーがすでにコーディングを行っている同じ環境でフロー状態を維持できます。\n\n* [脆弱性の説明](https://docs.gitlab.com/user/application_security/vulnerabilities/#explaining-a-vulnerability)（一般提供中）：デベロッパーとセキュリティアナリストが脆弱性、その悪用方法、修正方法を理解するのに役立ちます。\n\n* [テスト生成](https://docs.gitlab.com/user/gitlab_duo/)（一般提供中）：選択したコードに対してテストを自動的に作成し、カバレッジを向上させ、手作業を削減します。\n\n## この認証がGitLabユーザーにもたらす価値\n\n**信頼性と透明性の向上：** 当社のAI機能は、AIガバナンスに関する国際的に認められた最高水準に従って構築・管理されており、信頼性と倫理的な実装をサポートします。\n\n**戦略的リスク管理：** 運用事業継続性リスク、技術的リスク、セキュリティとプライバシーリスク、より広範な社会的影響などの側面を考慮して、プラットフォーム内のAIコンポーネントに対するリスク評価とリスク対処戦略を実装しました。この積極的なアプローチにより、顧客データの保護が強化され、より信頼性の高いAI駆動機能が促進されます。\n\n**継続的改善：** ISO/IEC 42001フレームワークの下で、年次外部監視監査、定期的な内部評価、リーダーシップによるAIMS審査を通じて、品質と責任の基準を維持しながらAI機能を継続的に評価・向上させていきます。\n\n**規制との整合性：** EU AI法などのAI規制が世界的に進化し続ける中、この認証は新たな規制要件に対するGitLabの対応をサポートします。\n\nこの認証取得により、AI駆動DevSecOpsの信頼できるプラットフォームとしてのGitLabの地位がさらに確固たるものとなりました。今後も責任あるAIイノベーションの分野で業界をリードし続けます。\n\n## 詳細情報\n\n- [GitLabトラストセンター](https://trust.gitlab.com/)でISO/IEC 42001認証書をご覧ください。\n- [ハンドブックのAIMS](https://handbook.gitlab.com/handbook/security/isms/)をご覧ください。\n- [GitLab AI Transparency Center](https://about.gitlab.com/ja-jp/ai-transparency-center/)をご確認ください。\n- 詳しくは、[GitLab Duoのすべての機能](https://docs.gitlab.com/user/gitlab_duo/)のドキュメントをご確認ください。",[846],"Davoud Tu","2025-09-02","GitLabがAIガバナンスでISO/IEC 42001認証を取得",[741,837,764],"この新しいISO認証、関連するGitLab Duo機能、および責任あるAI開発への取り組みについて詳しく解説します。",{"featured":91,"template":799,"slug":852},"gitlab-achieves-iso-iec-42001-certification-for-ai-governance",{"content":854,"config":863},{"heroImage":855,"body":856,"authors":857,"updatedDate":834,"date":847,"title":859,"tags":860,"description":862,"category":681},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1756500636/wmey6kqzzuhirk88w2de.png","10年以上にわたり、GitLabは透明性、独立性、そしてデベロッパーファーストの姿勢を大切にしてきました。業界が進化する今日、これらの価値はこれまで以上に重要になっています。「開発インフラを最終的に管理するのは誰なのか？」「AIシステムでコードがどのように使用されているのか？」「ベンダーの優先事項が重要な要件から離れた場合はどうなるのか？」企業のリーダーたちはこのような重要な疑問を投げかけています。\n\n先月、[GitLab 18.3のリリースを発表](https://about.gitlab.com/ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/)しました。これは、AIネイティブなDevSecOpsプラットフォームの最新版です。GitLab Duo Agent Platformの一部であるエージェントインサイトは、エージェントの意思決定プロセスを可視化します。AIモデルサポートの拡張により、ベンダーロックインを回避できます。強化されたガバナンス管理により、複数の管轄区域にわたるコンプライアンスの実現を支援します。\n\nこれらは単なる機能ではありません。GitLabを定義する透明性、独立性、デベロッパーファーストのアプローチの実証なのです。この戦略が実際にどう機能するかをご紹介します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1115249475?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=\"Who is GitLab_Robin_090225_FINAL\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## DevSecOpsライフサイクル全体でのAI透明性\n\n**GitLabでは、10年間にわたる透明性への取り組みが、これらの懸念に直接対処しています。** 人工知能が開発ワークフローにますます統合される中、組織は自社のコードとデータがAI学習にどのように使用されているかを当然懸念しています。\n\n2024年4月に開始されたGitLab [AI Transparency Center](https://about.gitlab.com/ja-jp/ai-transparency-center/)は、データガバナンスの実践、プライバシー保護、倫理的AI原則について明確な文書を提供しています。データ使用ポリシーが不明確なAI機能を運用する可能性のあるプラットフォームとは異なり、GitLabは透明性を優先し、お客様が[自分たちのデータがどのように処理](https://docs.gitlab.com/user/gitlab_duo/data_usage/)、保存、保護されているかを正確に把握できるようにしています。お客様のデータでの学習は一切行いません。\n\n私たちのアプローチは、モデルの柔軟性とベンダーの独立性にも及んでいます。お客様を単一の大規模言語モデル（LLM）プロバイダーに限定し、追加のベンダー依存や潜在的な単一障害点を作り出すプラットフォームがある一方で、GitLabのAI機能は様々なモデルによって強化されています。このアプローチにより、幅広いユースケースをサポートし、お客様の戦略的優先事項に合わせた柔軟性を持ち合わせています。\n\nGitLab Duo Agent Platformの開発をさらに進める中で、データ制御と包括的な人間参加型制御の維持に焦点を当て続けています。また、GitLab Duo Self-Hostedは、エアギャップ環境へのデプロイオプション、ゼロデイデータ保持ポリシー、自社インフラ内ですべてのAIリクエストを処理する機能により、完全なデータ主権を提供します。\n\n2024年5月以降、私たちは業界をリードするコミットメントを含む[AI継続プラン](https://handbook.gitlab.com/handbook/product/ai/continuity-plan/)も維持しています。これは、プロバイダーが顧客データに関する実践を変更した場合、30日以内に新しいモデルを評価して移行する能力です。AIベンダーリスク管理に対するこの積極的なアプローチは、顧客管理への私たちの取り組みを反映しています。\n\n## デプロイの選択、クラウドプロバイダーの選択\n\n**DevSecOps環境をどこにどのようにデプロイするかを選択できるべきです。** GitLabは真のデプロイの柔軟性を実現します。組織は、オンプレミス導入、マルチテナントSaaS、または完全管理型のシングルテナントSaaSソリューションであるGitLab Dedicatedから選択でき、機能を犠牲にしたり、エコシステムロックインを促進する人為的な制限に直面することはありません。GitLabはクラウドニュートラルでもあり、お客様はビジネスニーズと環境に最適なクラウドプロバイダーを使用できます。\n\nこの柔軟性は、複雑な管轄要件や規制上の課題をナビゲートする際に、非常に価値があることが証明されています。欧州連合やその他の地域で見られるような新しいデータローカライゼーション法が登場した場合、GitLabを使用する組織は、エコシステムの依存関係に制約されることなく、デプロイ戦略を迅速に適応させることができます。\n\n調達とリスク管理の観点から、プラットフォームの独立性は契約交渉において重要な影響力も提供します。組織は、顧客のニーズよりもベンダーの利益を優先する制限的なライセンス契約に縛られることがありません。この独立性は、企業がAIスタックの管理者が誰なのかを警戒するようになる中で、特に重要になります。\n\n## セキュリティとコンプライアンス：組み込み型で常に優先事項\n\n**セキュリティとコンプライアンスは現在、開発機能と同様に重要であり、後付けではなく、プラットフォームに組み込まれているべきです。** GitLabの単一プラットフォームアプローチは、基本的なセキュリティとガバナンス機能を実現させるために、サードパーティのアドインに依存する断片化されたプラットフォームよりも大きな優位性を提供します。このアーキテクチャの違いは、潜在的な法的リスク、運用効率、規制コンプライアンスに重要な影響を与えます。チェーン内の追加ツールはそれぞれ、別の潜在的な障害点、交渉すべき別の利用規約セット、そして別のリスクの源となります。\n\nGitLabは、カスタムコンプライアンスフレームワーク、動的アプリケーションセキュリティテスト（DAST）、APIファズテスト、カバレッジガイドファズテスト、Infrastructure-as-Codeテストなど、包括的な組み込みセキュリティとコンプライアンス機能を提供します。これらの機能はプラットフォームにネイティブに統合されており、一貫したポリシー実施を提供し、複数のサードパーティツールの管理に伴うコンプライアンスの複雑さや追加コストを削減します。\n\nGitLabの[コンプライアンスセンター](https://docs.gitlab.com/user/compliance/compliance_center/)は、チームがコンプライアンス基準、遵守レポート、違反レポート、グループのコンプライアンスフレームワークを管理するための中央拠点を提供します。このコンプライアンス管理への統一されたアプローチは、監査証跡とコンプライアンス文書が重要な、高度に規制された業界で事業を行う組織にとって特に価値があります。\n\n## オープンソースコミュニティとの密接な関係の維持\n\n**最高のツールは、それを使用する人々によって形作られます。** オープンソースへの取り組みとコミュニティとの関わりは、GitLabの創設以来の中核となっています。例えば、私たちの[Co-Createプログラム](https://about.gitlab.com/community/co-create/)は、お客様がGitLabエンジニアと直接連携してGitLabプラットフォームへの機能、修正、改良をコントリビュートできる協力的な取り組みです。\n\n透明性という価値観は、私たちのビジネスの根幹であり続けています。この例として、お客様が私たちの開発進捗をフォローし、製品改善についてGitLabチームと直接議論に参加できる[オープンイシュートラッカー](https://gitlab.com/groups/gitlab-org/-/issues)があります。最近立ち上げた、[ヘルシーバックログイニシアチブ](https://about.gitlab.com/blog/inside-gitlabs-healthy-backlog-initiative/)では、私たちの開発計画をさらに詳しくお客様に公開し、いただいたフィードバックをもっとも効果的に活かせる部分に確実に反映させています。\n\n私たちのアプローチにより、組織は規制環境に必要なガバナンス、監査証跡、セキュリティ管理を維持しながら、オープンソースイノベーションに貢献し、その恩恵を受けることができます。\n\n## データガバナンス：自分のデータは自分で守る\n\n**データとその処理方法について、完全な管理権限を保持できます。** データガバナンスは、国や地域ごとの複雑なデータ保護法や、ソースコード、顧客インサイト、戦略的イニシアチブ、競争情報といった機密知的財産に対する管理への懸念の高まりを背景に、企業技術の意思決定においてますます重要な要因となっています。\n\nGitLabでは、プラットフォーム内のAI搭載機能へのアクセス権限を管理でき、単純なアクセス制御を超えて、規制フレームワークに合わせた暗号化基準と監査機能を包括します。また、お客様のコードとデータはAIモデルの学習に使用されることは一切ありません。\n\n## 選択は明確です\n\nGitLabは、AIネイティブなDevSecOpsプラットフォームイノベーションをリードし続けています。私たちの最新の[18.3リリース](https://about.gitlab.com/ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/)がそれを実証していますが、同時に常に私たちを導いてきた独立性と透明性へのコミットメントを堅持しています。\n\nお客様には選択肢があり、その選択は明確です：管理権の保持かベンダーロックインか。透明性か不確実性か。イノベーションへのコントリビュートか、より大きなエコシステムの気まぐれか。\n\nGitLabは、イノベーションと独立性のバランスを取る持続可能なデジタルトランスフォーメーションの基盤を提供し、お客様のビジネス価値の実現を支援します。\n\n[GitLab UltimateとGitLab Duoを今すぐ無料でお試しください。](https://about.gitlab.com/ja-jp/free-trial/)",[858],"Robin Schulman","DevSecOpsにおける企業の独立性がこれまで以上に重要な理由",[837,713,764,795,861],"open source","開発インフラを誰がコントロールしているのか、リーダーたちが疑問を持つ中、GitLabの独立性と透明性の優位性はかつてないほど注目されています。",{"featured":91,"template":799,"slug":864},"why-enterprise-independence-matters-more-than-ever-in-devsecops",{"category":689,"slug":693,"posts":866},[867],{"content":868,"config":877},{"title":869,"description":870,"authors":871,"heroImage":818,"date":873,"body":874,"category":693,"tags":875,"updatedDate":876},"今すぐ対策を：Docker Hubのレート制限がGitLab CI/CDに与える影響","Docker Hubの新しいプルレート制限がGitLabのパイプラインにどのような影響を与えるか、また、その影響によってCI/CDパイプラインが中断されるのを防ぐ対策を解説します。",[872],"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,741,794],"2025-03-31",{"slug":878,"featured":91,"template":799},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":701,"slug":705,"posts":880},[881,896,908],{"content":882,"config":894},{"title":883,"description":884,"authors":885,"heroImage":887,"date":888,"body":889,"category":705,"tags":890,"updatedDate":893},"共同開発プログラム：ユーザーとともに築くGitLab","Thales社、Scania社、Kitware社などの組織がどのようにGitLabのエンジニアと連携し、コミュニティ全体に利益をもたらす重要な機能の開発にコントリビュートしているかをご紹介します。",[886],"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",[891,861,892],"contributors","customers","2025-03-10",{"slug":895,"featured":91,"template":799},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":897,"config":906},{"title":898,"description":899,"authors":900,"heroImage":902,"date":903,"body":904,"category":705,"tags":905},"くら寿司が語るソフトウェア開発の「生産性向上」と「セキュリティ・ガバナンス」の重要性【イベントレポート】","2024年10月に開催された「Gartner IT Symposium/Xpo」の当社セッションにおいて、くら寿司様より事例を紹介いただきましたので、その模様をお伝えします。",[901],"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/)",[892],{"slug":907,"featured":91,"template":799},"event-report-gartner-it-symposium",{"content":909,"config":920},{"title":910,"description":911,"authors":912,"heroImage":914,"date":915,"body":916,"category":705,"tags":917,"updatedDate":919},"GitLabでCIプラットフォームを変革したIndeed社の戦略","世界最大の求人サイトであるIndeed社は、数千のプロジェクトをGitLab CIに移行することで、生産性向上とコスト削減を実現しました。1日あたりのパイプライン実行数が79%増加するなど、得られた主なメリットをご紹介します。",[913],"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/)の編集版です。**",[892,109,918,794],"user stories","2025-01-10",{"slug":921,"featured":91,"template":799},"how-indeed-transformed-its-ci-platform-with-gitlab",{"category":713,"slug":717,"posts":923},[924,936,948],{"content":925,"config":934},{"date":926,"authors":927,"title":928,"description":929,"heroImage":930,"category":717,"tags":931,"body":933},"2025-09-10",[901],"コード生成AIのリスクを管理し、ポテンシャルを最大限に引き出す【イベントレポート】","ガートナー セキュリティ＆リスク・マネジメントサミット2025で登壇したGitLab吉瀬 淳一のセッション内容をレポート。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480526/wk05yajf5e4bmwuygve7.jpg",[837,932,713,280,775],"code review","GitLabは2025年7月23～25日の3日間、都内ホテルで開催された「ガートナー セキュリティ ＆ リスク・マネジメント サミット2025」に出展しました。本記事では、GitLabシニア・ソリューション・アーキテクト 吉瀬 淳一が登壇したセッションの模様についてレポートします。\n\n![ガートナー セキュリティ ＆ リスク・マネジメント サミット2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480502/dy6lgmfb1oihyvrjcxqx.jpg)\n\n*会場の様子*\n\nこの日の講演は、コード生成AIの話が中心です。まずは会社の話から入ったのですが、吉瀬は比較的社歴の浅いエンジニアで、働き方の紹介もユニークでした。GitLabは、全世界の全従業員がリモートで働いていることで知られています。実際に、GitLab社員の多くは、お客様やパートナー様から「よく聞くけれど、本当にそうなの？」と尋ねられた経験をしています。\n\n吉瀬は、「GitLabには本社がありません。世界中のどこを探しても、オフィスすらありません。私の場合も、入社が決まると会社のPCが送られてきて、GitLabでの生活が始まりました。入社した当日から、いきなり1人ぼっちです」と話して、会場の空気を和ませました。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480501/glglfhj8thtnkdsgqn8j.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\n## セキュリティ対策の全体像とシフトレフトの重要性\n\nソフトウェア開発においてコード生成AIを活用する前に、プロジェクトにおいてセキュリティをどう担保するかについて決めていく必要があります。その際に、セキュリティ対策の全体像を分解し、企画、開発、運用という大きく3つのくくりで詳細を決めることが必要です。\n\n![企業が取り組むべきセキュリティ対策の全体像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757386735/vqy6xhnubpvwjnsfcxvc.png)\n\n*スライド：企業が取り組むべきセキュリティ対策の全体像*\\\n\\\n企画は、いわゆる統制やガバナンスのようなもの。企業全体、もしくはプロジェクト全体としてのルールを、ここで決めます。開発は、コードを生み出す段階での対策です。脆弱性検査の自動化やセキュアコーディングの標準化などがこれに当たります。運用におけるセキュリティ対策は、実行環境を守る手段を指します。エンドポイントセキュリティやネットワーク監視、ID管理、ログ管理などです。\n\nそして、これらの中で、最も課題が多いのは開発の部分になります。吉瀬は、「開発課題が大きい理由のひとつは、実際の開発を外部委託していることでしょう。委託先が何をやってるのか見えにくいのです。ただ、この部分の改革に取り組んでいかなければ、本当の意味でのセキュリティを守ることはできません」と話します。\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480501/eskdwrakqm2n7t2bsocq.jpg)\n\n*スライド：デジタル庁が提示する「セキュリティ・バイ・デザイン」の原則*\\\n\\\nそのためにも、シフトレフトが重要になります。開発の上流工程で対策を講じることで、デプロイ後に脆弱性が見つかって対応するなどの手戻りは大幅に低減します。さらに、品質の向上につながることも期待できます。実際に、デジタル庁が公開した『政府情報システムのためのセキュリティ・バイ・デザインガイドライン』でも、開発のなるべく早い段階にセキュリティを担保するプロセスを組み込み、問題点を潰していくことの重要性がうたわれています。\n\n「現在、多くの日本企業は“事故が起きてからどうするかを考える”というセキュリティ対策を重視する傾向があるようです。それももちろん大切なのですが、偏りすぎると問題です。開発から運用に至るプロセスは左から右へと図示されますが、左側の開発段階でもやれることは数多くあります。きちんとシフトレフトして、開発の上流工程も最適化する方向で考えるべきです」（吉瀬）\n\n## 生成AIを活用するエンジニアはすでに100%！？\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480501/ns3x4ai53zkqjkbrcn5z.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\nその最適化すべき“左側”で、生成AIは大きなムーブメントになっています。吉瀬は、「生成AIを活用しているエンジニアは、ほぼ100%と言ってもいいくらい」と話します。「ソフトウェア開発にAIを使っていると答えた組織の割合が78%という調査結果がありますが、よく見てください。 “組織”ですよ。個人のレベルになるとどうでしょう。組織としては、人が書いていると思っているけれど、実はその人がAIを使っているケースは多いでしょう。なにしろ、生産性が桁違いですから」。\n\n一方、GitLabの調査をまとめた『[2024グローバルDevSecOpsレポート](https://about.gitlab.com/ja-jp/developer-survey/)』によると、ソフトウェアエンジニアがコードを書く時間は、全就業時間の21%にとどまっています。残りの79%は脆弱性の対応やテスト、トラブルシューティング、打ち合わせなど。ここに、生成AIを導入してる企業の開発生産性が2割程度しか上がらない原因があります。全体の21%を占める部分の生産性が10倍になっても、残りの79%がボトルネックになり、全体的な生産性は上がらないのです。\n\n![スライド：AI生成コードの脆弱性とセキュリティリスクの急増](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757386736/syfahxrakeeqlpyurjlv.png)\n\n*スライド：AI生成コードの脆弱性とセキュリティリスクの急増*\\\n\\\nさらに、生成AIのはらむセキュリティリスクに注意が必要です。上図に示したように、懸念点は大きく3つ。まず、AIが生成するコードには脆弱性が含まれがちです。次に、エンジニアは脆弱性が含まれていることは認識できるものの、その発見や対処法に自信を持っていません。最後に、マネジメントは、社内でAIがどういう扱われ方をしていて、どんなリスクが発生しているかをつかみきれていません。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480496/zs5kufi2hwvlvchjhiws.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\nさらに問題を大きくしているのが、AIのサイロ化です。ソフトウェア開発プロセスでは、さまざまなツールが使用されます。そしていま、各ツールの裏でAIが動くようになりました。これらのAIが、IssueやEpic、マージリクエストの議論、過去の変更履歴といった開発の全体的なコンテキストを把握できないことが問題なのです。プロセスの中には、特定の脆弱性を修正する目的のIssueがあります。しかし、コード生成AIはその背景を知りません。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のAIは単にテストの成否だけを見ます。この状況では、「脆弱性を修正する」という本来の修正意図が反映されているかどうかを判断できません。“開発の文脈”を理解しないまま、各ツール上だけで動くAIが部分的な判断を下すことで、本質的な問題が見過ごされてしまうリスクが高まってしまうのです。\n\n## 単一のプラットフォームでソフトウェア開発ライフサイクル全体を管理する\n\nこうした状況を抜本的に解決するために、 GitLabは単一のプラットフォームでソフトウェア開発ライフサイクル全体を管理するというアプローチを採ります。企画、開発、運用にまたがるセキュリティ対策全体を鳥瞰する包括的な解決策であり、コードの脆弱性、開発者の信頼性、ガバナンスという3つの懸念点もクリアできます。\n\n![スライド：セキュアなAI活用を実現するDevSecOpsプラットフォーム](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757386735/rhpuem4bdeja6c2hr7iv.png)\n\n*スライド：セキュアなAI活用を実現するDevSecOpsプラットフォーム*\\\n\\\nGitLabのソリューションにおいて、生成AIを活用した開発プロジェクトのシフトレフトを支える中心になるのが、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)の[コードレビュー&修正支援機能](https://player.vimeo.com/video/929891003?badge=0&autopause=0&player_id=0&app_id=58479/)です。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)では、人間がレビューする前にAIがコードを自動チェックし、脆弱性を指摘します。さらに、脆弱性が生まれた原因と具体的な修正方法までAIが提案することで、脆弱性発生リスクを極小化することができます。開発段階において[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を利用することで、セキュアなコード開発を促進する体制が自然に生まれることになります。\n\nGitLab上でプロセスを整え、ルール化を徹底すれば、シフトレフトは自然に推進されます。たとえば、パイプラインポリシーを整備すれば、開発者のスキルや意識に依存しない一貫したセキュリティレベルを担保できます。コードのコミットをトリガーに多様なセキュリティスキャンを自動実行するなど、適切なタイミングでセキュリティスキャンするプロセスを組織に根付かせることもできます。開発プロセスを最適化し続けることで、問題を早期に発見し、対処できる強固な体制が生まれます。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480495/ocag236gff9qw5bvaoxx.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\nGitLabのAIはプラットフォームとしての強みを生かし、一貫したコンテキストにもとづいて全体に対する有益な示唆を与えてくれます。GitLabを単一データストアとして、開発の全工程のデータを一元管理しておけば、AIが“全体の文脈”を理解できます。コードの関連性を把握し、変更の影響範囲もスピーディに指摘してくれます。サイロ化されたツールでは不可能な、一貫性のある高度な支援が可能になるのです。\n\nさらに、GitLabのAIポリシーは、極めて透明性の高いものです。[GitLabのAIは、「顧客のデータを学習データとして利用しない」など、企業の知的財産を守る明確なポリシーを設けています](https://about.gitlab.com/ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops/#%E3%83%87%E3%83%BC%E3%82%BF%E3%82%AC%E3%83%90%E3%83%8A%E3%83%B3%E3%82%B9%EF%BC%9A%E8%87%AA%E5%88%86%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AF%E8%87%AA%E5%88%86%E3%81%A7%E5%AE%88%E3%82%8B)。ユーザーは、安心して最先端のAI技術を活用することも可能ですし、よりセキュアな環境を求める場合は、オンプレミス環境におけるローカルLLM運用にも対応しています。\n\n## 一貫したコンテキストの中でAIの力を最大限に生かす\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480495/nlqrw5sadygg4blh3ln3.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\nコード生成AIは、開発を加速させる強力な武器です。ただし、正しく活用すれば、であることに注意が必要です。コード生成AIのポテンシャルを最大限に引き出し、同時にリスクを管理するために必要な要素は、ここまで述べてきたとおりです。つまり、開発ライフサイクル全体を俯瞰し、一貫したルールとコンテキストのもとでAIを機能させる、GitLabのような統合プラットフォームが不可欠なのです。\n\n吉瀬は、「生成AIの時代は始まったばかりで、これからどんどん広まっていくでしょう。ひとりの開発者が生み出すコードの量は、これまでに比べると凄まじく増えます。生産性はどんどん高まります。すばらしいことです」と話します。\n\n「確かに、生成AIの書いたコードに脆弱性が大量に含まれているというリスクはありますが、生産性とリスクのバランスを考えると、AIを使わないという選択肢はありえません。だからこそ、コードのレビューや脆弱性の修正にもAIを使い、パイプラインポリシーのシフトレフトをきちんとやる必要があるのです。プラットフォームを統合して、一貫したコンテキストの中でAIの力を最大限に生かしていきましょう。これがGitLabからのメッセージです」（吉瀬）\n\n![イベントで配られたノベルティ（水筒）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480495/yibqr6h9osxu0nqyxxdu.jpg)\n\n*イベントで配られたノベルティ（水筒）*\n\n![イベントで配られたノベルティ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480495/kx2htmmgdnrwqsdctif5.jpg)\n\n*イベントで配られたノベルティ（スニーカー）*",{"featured":91,"template":799,"slug":935},"event-report-gartner-security-risk-management-2025",{"content":937,"config":946},{"title":938,"description":939,"heroImage":940,"date":941,"body":942,"category":717,"tags":943,"authors":945},"みんなの銀行の内製化戦略とAIへの取り組み【イベントレポート】","2025年6月に開催された「Gartner Application Innovation & Business Solutions Summit 2025」の当社セッションにおいて、株式会社みんなの銀行 取締役常務執行役員CIO宮本 昌明氏にご講演いただいた模様をお伝えします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756178708/bcuxu1pffexqdzy4ebxf.jpg","2025-08-27","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*イベントで配られたノベルティ*",[892,837,944,713,280,552,775,918],"collaboration",[901],{"featured":91,"template":799,"slug":947},"event-report-gartner-application-innovation-2025",{"content":949,"config":958},{"title":950,"description":951,"authors":952,"date":953,"body":954,"category":717,"heroImage":955,"tags":956},"GitLab with Amazon Qで開発スピードを高め、AI生成コードの品質を担保する【イベントレポート】","この記事ではAWS Summit Japan 2025に出展した際に「GitLab with Amazon Q」について語ったセッションの模様をお伝えします。",[901],"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",[957,837,932,944,892,713,280,775,918],"AWS",{"featured":91,"template":799,"slug":959},"event-report-aws-summit-2025",{"category":725,"slug":729,"posts":961},[962,976,987],{"content":963,"config":974},{"category":729,"body":964,"date":965,"authors":966,"heroImage":968,"title":969,"description":970,"tags":971},"近年ソフトウェア開発の領域では「プラットフォームエンジニアリング」と呼ばれる開発者の生産性向上に寄与するアプローチが注目されています。\n\n実際にプラットフォームエンジニアリングに興味はあるものの、意味や定義などを詳しく理解していない人も多いのではないでしょうか。\n\nこの記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。具体的な導入ステップや基盤構築に役立つおすすめのプラットフォームも紹介するのでぜひ参考にして下さい。\n\n## 1. プラットフォームエンジニアリングとは？\n\n![プラットフォームエンジニアリングとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508139/eui82g7mlcb2fr5vavir.jpg)\n\nまずはプラットフォームエンジニアリングの意味や特徴について解説します。\n\n### 1-1. プラットフォームエンジニアリングの意味・特徴\n\nプラットフォームエンジニアリングとは、企業内の開発者に対して適切なプラットフォーム（IDP）を整備し、ソフトウェア開発の効率化や生産性向上を実現するアプローチのことです。\n\n近年はIT技術の発展や消費者ニーズの多様化などを背景として将来の予測が難しい時代（VUCA時代）だと言われています。プラットフォームエンジニアリングは、VUCA時代において複雑化するビジネスニーズに対応するための新しいエンジニアリング手法として、ガートナー社が積極的に提案しているアプローチでもあります。\n\n### 1-2. IDP（内部開発者向けプラットフォーム）とは\n\nInternal Developer Platform（内部開発者向けプラットフォーム、以下IDP）とは、企業内の開発者が開発プロセスにおいて必要な機能やリソースを自ら取得して利用できるプラットフォームを指し、プラットフォームエンジニアリングの導入における重要な技術基盤に当たります。\n\nIDPを通してチームで共通して利用できるツールやリソースを開発者に提供することで、迅速なソフトウェアの構築やデプロイを実現できます。\n\nIDPの構築においては、自社の課題や目的に応じてさまざまなツールや技術を組み合わせて行いますが、[GitLab](https://about.gitlab.com/ja-jp/)のように単一のプラットフォームで開発プロセスにおける多くの作業を効率化できるサービスもあります。\n\n## 2. プラットフォームエンジニアリングが注目されている背景\n\n![プラットフォームエンジニアリングが注目されている背景](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/hvzgimgumavwq5mmfqlx.jpg)\n\nソフトウェア開発の領域でなぜプラットフォームエンジニアリングが注目されているのでしょうか。具体的な背景としては以下が挙げられます。\n\n* 開発環境の複雑化  \n* ビジネス環境の激化  \n* IT人材の不足\n\n### 2-1. 開発環境の複雑化\n\nプラットフォームエンジニアリングの必要性が高まっている背景の一つとしてまず挙げられるのが、開発環境の複雑化による開発者の認知負荷の増大にあります。\n\nソフトウェア開発における開発手法や技術は年々進化・発展し続けており、クラウドや生成AI、マイクロサービス、APIなどさまざまな技術が広く使われるようになっています。これらの技術活用によって柔軟なソフトウェア開発を実現できますが、その一方で管理すべきツールの種類が増え、かつ多様な技術を身につけなければならないという課題が発生します。\n\nそれにより、開発者は重要な開発作業や取り組み以外に自身のリソースを割く必要があり、それが結果としてチーム全体の生産性低下も招くことになります。\n\nつまり、ソフトウェア開発において効果的に最新技術を取り入れていくためには、開発者が本質的な業務に集中できる環境を構築しなければなりません。\n\n### 2-2. ビジネス環境の激化\n\n先ほども少し触れていますが、近年は[VUCA時代](https://www.nri.com/jp/knowledge/glossary/vuca.html)と呼ばれる将来の予測が難しい不確実な要素が多い時代です。\n\n市場が常に変化する中で社会や消費者にとって必要とされる価値あるソフトウェアを開発して競合と差別化を図るためには、多様な技術を活用したスケーラブルな開発が求められます。\n\nまた、自社の競争力を高めていくためには、アジャイル開発のようなスピード感のある開発手法を積極的に採用していく考えも大切です。\n\n開発者がセルフサービスで利用できるプラットフォームの提供は、柔軟かつ迅速なソフトウェア開発を実現する手段として有効なアプローチだと言えます。\n\n[アジャイル開発とは？意味や進め方、DevSecOpsとの関係性を解説](https://about.gitlab.com/ja-jp/blog/what-is-agile-development/)\n\n### 2-3. IT人材の不足\n\nソフトウェア開発の領域では、慢性的な人手不足が課題となっています。クラウドやAIなど高度な最新技術が次々と登場する一方で、それらを扱える専門知識を持った人材が業界全体で不足しているのです。\n\n実際に「[IT人材需給に関する調査](https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf)」を見てみると、2030年には最大で約79万人のIT人材が不足すると予測されています。\n\n![IT人材需給に関する調査](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/zv15e7qpd6cppogiogat.png)\n\n※引用元：[IT人材需給に関する調査](https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf)\n\nこのような背景の中で適切にソフトウェア開発を進めていくためには、プラットフォームエンジニアリングの導入を通じて開発者の負担削減や生産性向上を実現し、自社のリソースを上手に活用していく姿勢や工夫が求められると言えます。\n\n## 3. プラットフォームエンジニアリングとDevSecOps・SREとの関係性とは\n\n![プラットフォームエンジニアリングとDevSecOps・SREとの関係性とは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/psg7uvfabu13r50vbwzc.jpg)\n\nプラットフォームエンジニアリングを理解する上では、DevSecOpsやSREとの違いについても把握しておくことが大切です。\n\n### 3-1. DevSecOpsとの違い\n\nDevSecOpsとは、開発（Dev）、セキュリティ（Sec）、運用（Ops）の3つの領域を連携させて開発を進めるアプローチを指します。開発と運用を連携してリリースサイクルを短縮させる従来の「DevOps」の考え方に対して、セキュリティ（Sec）のプロセスも加えることでソフトウェアの安全性を確保しつつ、迅速なリリースが可能になります。\n\n一方、プラットフォームエンジニアリングはDevSecOpのようなワークフローを実現する上で土台となるプラットフォームを社内で整備する取り組みです。\n\nつまり、プラットフォームエンジニアリングとDevSecOpsは親和性が高く、プラットフォームエンジニアリングはDevSecOpsをサポートする役割を担っていると言えます。\n\n### 3-2. SREとの違い\n\nSREとは、「Site Reliability Engineering」の略語で直訳すると、「サイト信頼性エンジニアリング」になります。Google社によって提唱された概念であり、運用プロセスにおいて手間のかかるタスクを自動化してシステムの安定稼働を実現しつつ、新機能の追加や更新などを通してユーザー体験（UX）の向上を目指す取り組みを指します。\n\nプラットフォームエンジニアリングとSREは、いずれも開発と運用における効率性・信頼性向上に関わるものですが、それぞれ目的や焦点が異なります。\n\nプラットフォームエンジニアリングは、社内の開発者の生産性向上や利便性向上を目的としたアプローチであり、SREは主にシステムの信頼性と可用性、スケーラビリティの向上に焦点を当てた考え方になります。\n\n## 4. プラットフォームエンジニアリングの導入目的とメリット\n\n![プラットフォームエンジニアリングの導入目的とメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508134/m2jqfbt1sfjpjqh3dbih.jpg)\n\nプラットフォームエンジニアリングの導入目的やメリットは以下の通りです。\n\n* 開発プロセスの効率化  \n* 開発者の生産性向上  \n* プロダクトの品質向上  \n* セキュリティ・ガバナンスの維持と強化  \n* 人材不足の解消  \n* 新しいイノベーションの創出  \n* コスト削減\n\n### 4-1. 開発プロセスの効率化\n\nまずプラットフォームエンジニアリングの導入は、開発プロセスの効率化につなげられます。\n\nIDPにより開発者は開発に必要なリソースを必要な時に素早く取得して利用できるため、環境構築に手間と時間をかけることなく本質的な開発業務に集中することが可能です。\n\nアジャイル開発やDevSecOpsの手法を活用する際に、積極的にプラットフォームエンジニアリングの考え方も採用すれば、プロダクトや機能のリリース頻度・スピードが向上し、自社ビジネスの加速化に貢献できるでしょう。\n\n### 4-2. 開発者の生産性向上\n\nプラットフォームエンジニアリングでIDPを整備することで、チームで再利用可能なツールと機能を開発者に提供できるようになります。この仕組みにより、開発者それぞれで多数のツールを管理・運用する手間がなくなり、認知的負荷の軽減につなげられるでしょう。\n\nその結果、戦略立案や分析、新機能開発などより重要な業務にリソースを割けるようになり、生産性の最大化を図れるでしょう。\n\n### 4-3. プロダクトの品質向上\n\n顧客が満足するプロダクトを提供するためには、品質も担保しなければなりません。IDPに対してテストやレビュー、セキュリティスキャン、デプロイなどを自動化する仕組みを整備すれば、ヒューマンエラーの防止につなげられます。\n\nプラットフォームエンジニアリングの導入でテストやレビューなどを標準化することによって、開発者やプロジェクトごとの品質のバラつきを防止でき、自社で定義されたプラットフォームの基準に沿って開発と運用を進められます。\n\nつまり、プラットフォームエンジニアリングの導入は、開発効率や生産性の向上だけでなく、プロダクト品質や信頼性の向上にも寄与します。\n\n### 4-4. セキュリティ・ガバナンスの維持と強化\n\nプラットフォームエンジニアリングで自社に必要なセキュリティやガバナンスを定義し、それらを自社のプラットフォーム上に反映させて運用することも可能です。\n\n権限設定や監査ログ、セキュリティポリシー、脆弱性対応などをプラットフォーム上で集約して一元化することで管理や証跡の収集が容易になり、組織全体におけるセキュリティ・ガバナンスの維持と強化につなげられるでしょう。\n\nまた、標準化されたプラットフォームの整備によって、開発者の心理的な負担を軽減して安全に開発を進められます。\n\n### 4-5. 人材不足の解消\n\nプラットフォームエンジニアリングの導入は、開発プロセスの効率化や開発者の生産性向上に寄与するため、企業のリソースを最大限に活かしながらソフトウェア開発を進められます。\n\nまた、開発者のニーズにマッチしたプラットフォームを提供して働きやすい環境を構築することで、開発者体験（Developer Experience）の向上も実現できます。その結果、自社に対する開発者や求職者からのイメージも良くなり、優秀なエンジニアの獲得と定着を図れるでしょう。\n\n### 4-6. 新しいイノベーションの創出\n\n近年ソフトウェア開発の効率化や価値向上に役立つさまざまな最新技術が登場しています。しかし、複数の技術やツールを開発者個人で活用するには管理の負担が増えてしまい、実際の活用にはハードルが高いと言えます。\n\nプラットフォームエンジニアリングならさまざまな機能やツールが搭載されたプラットフォームをチームで利用できるため、開発者全員が最新技術に触れやすくなります。それをきっかけとして自社で新しいアイデアやイノベーションが生まれたり、より品質の高いプロダクトをリリースできたりする可能性が高まるでしょう。\n\n### 4-7. コスト削減\n\nプラットフォームエンジニアリングを取り入れることで、ツールや環境の共通化によるコスト削減にもつながります。例えば、ソフトウェア開発のプロセスにおいて複数のツールを活用している企業が、[GitLab](https://about.gitlab.com/ja-jp/)のようなさまざまなツールを単一のプラットフォームで利用できるサービスを導入すれば、ライセンス費用や管理コストの削減につなげられるでしょう。\n\nまた、CI/CDやセキュリティチェックなどをプラットフォーム上で自動化することで運用コストの削減も実現できます。\n\nワークフローの自動化や標準化により開発スピードが向上すれば、限られたリソースを効果的に活用できるため、長期的な人件費の最適化にもつながります。\n\n## 5. プラットフォームエンジニアリングの導入ステップ\n\n![プラットフォームエンジニアリングの導入ステップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/cep3gdqsqca4gb0ckt2w.jpg)\n\nここでは実際にプラットフォームエンジニアリングを導入する際の手順について見ていきましょう。\n\n1. 専門チームの組成  \n2. 開発課題の分析と目標設定  \n3. プラットフォームの構築・組織体制の変更  \n4. フィードバック・継続的なメンテナンス\n\n### 5-1. 専門チームの組成\n\nプラットフォームエンジニアリングを導入する際には、まず専門チームの組成から始めます。専門チームを社内に配置すれば、プラットフォームエンジニアリング導入の取り組みを推進できます。専門チームの主な役割としては以下が挙げられます。\n\n* 開発者のニーズ調査  \n* プラットフォームの設計・構築  \n* 社内でのプラットフォーム活用の浸透の実現  \n* プラットフォームの運用・定期的な改善 など\n\n実際のメンバー構成においては、開発者のさまざまなニーズを考慮したプラットフォームを導入するためにも、開発・運用・セキュリティなど多様なスキルセットを持つ人材や、それぞれの分野を専門とする人材を集めることがポイントです。\n\nまた、社内向けではあるものの、自社での活用を浸透させるためにはプラットフォームを一つのサービスとして捉え、ユーザーニーズを満たすという視点が重要になります。\n\n### 5-2. 開発課題の分析と目標設定\n\nプラットフォームエンジニアリングの専門チーム結成後は、現状の開発課題の把握と分析を実施します。課題の把握や分析においては、エンジニアとの個別面談やサーベイなどを通して行います。\n\nその中で、「複数のツールを管理するための負担がかかり過ぎている」「開発環境の構築から実際のリリースまで時間がかかっており、開発効率が悪い」などの課題が挙げられたなら、それらの課題を解決するためにどのようなプラットフォームを導入すれば良いのかを検討し、具体的な目標を設定します。\n\n例えば、開発者のツール管理の負担が主な課題としてあるなら、単一のプラットフォームで複数のツールや技術を活用できるIDPを整備するという方向性を定められるでしょう。\n\n### 5-3. プラットフォームの構築・組織体制の変更\n\nプラットフォームエンジニアリングの導入における目標や方向性が明確になった後は、実際に基盤となるプラットフォームの構築を行います。\n\n開発プロセスの課題解決につながるような機能やツールを搭載し、さまざまな手法で開発を進められるよう整備していきます。\n\nまた、プラットフォームを構築して実際に活用していく際には、これまでの開発プロセスに変化が生じるため、必要に応じて開発者間での認識の擦り合わせや組織体制の変更を行いましょう。\n\n### 5-4. フィードバック・継続的なメンテナンス\n\nプラットフォームエンジニアリングの基盤構築後は、実際にプラットフォームを運用し開発者に活用してもらいます。その中で開発者からフィードバックや要望があれば、機能追加や改善を柔軟に行っていきます。\n\nソフトウェア開発におけるツールや技術は進化し続けており、トレンドも常に移り変わるため、最新情報のキャッチアップや定期的なメンテナンスがプラットフォームエンジニアリングを成功させるための鍵となります。\n\n## 6. プラットフォームエンジニアリングの導入における注意点\n\n![プラットフォームエンジニアリングの導入における注意点](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/ew7szhpm1mnheubghlnk.jpg)\n\nプラットフォームエンジニアリングの導入においては以下のような注意点もあります。\n\n* プラットフォーム構築を目的としない  \n* 導入に効果が期待できるか見極める  \n* トップダウンでの導入は避ける  \n* 段階的に導入して小さく始める\n\n### 6-1. プラットフォーム構築を目的としない\n\nまずプラットフォームエンジニアリングの導入において、プラットフォーム構築そのものを目的として進めてしまうと失敗してしまう可能性が高まります。\n\n例えば、「最新技術だから」「高機能だから」というような考えだけで導入してしまうと、開発者ニーズにマッチしないプラットフォームを構築してしまうことになります。そうなると、社内での活用も浸透せず、誰にも使われないという結果を招いてしまうでしょう。\n\nそのため、開発者への調査を徹底して行い、どんな課題を解決したいのかを明確にした上でプラットフォームを構築する必要があります。\n\n### 6-2. 導入に効果が期待できるか見極める\n\nプラットフォームエンジニアリングの導入そのものが、実際に自社にとって効果が期待できるのかも見極めなければなりません。\n\n例えば、エンタープライズや中規模など大きめ組織で、かつ必要な人材が揃っているなら、専門チームの組成もスムーズに進み、実際のプラットフォーム構築によって開発の効率化やコスト削減などの効果が期待できる可能性が高いと言えます。\n\n一方、小規模な組織の場合で、かつ人手が足りない場合プラットフォーム構築や運用そのものに大きな負担がかかってしまい、逆効果になる可能性もあります。\n\nそのため、「プラットフォームエンジニアリングの導入や運用が自社で可能なのか」「実際にどのような効果が期待できるのか」をきちんと検討することが大切です。\n\n### 6-3. トップダウンでの導入は避ける\n\nプラットフォームエンジニアリングは開発者向けのアプローチであり、開発者がプラットフォームを問題なくセルフサービスで利用できるという要素が重要になります。\n\nそのため、トップダウンで現場の課題や開発者のニーズを無視して導入を進めてしまうと、新しいやり方に対して開発者から抵抗や反発を受ける可能性があります。\n\nスムーズな導入を実現するためには、経営層と開発者で双方向コミュニケーションをとり、開発者に選択の余地とアイデアを積極的に発信できる場を与える必要があります。\n\n### 6-4. 段階的に導入して小さく始める\n\n最初から全ての要件を満たした完璧なプラットフォームを構築して、運用しようとすると開発者が変化に対応しきれない可能性があります。また、時間をかけてプラットフォームを構築しているとトレンドに乗り遅れ、完成後には搭載した技術やツールが既に古いものになってしまっていたというケースも考えられます。\n\nそのため、まずは優先度の高い課題にフォーカスして、効果が期待できる機能から実装し段階的に運用するなど、アジャイル的な進め方がプラットフォームエンジニアリングの導入に求められると言えます。\n\n## 7. プラットフォームエンジニアリングの基盤構築に役立つツール・サービスの選び方\n\n![プラットフォームエンジニアリングの基盤構築に役立つツール・サービスの選び方](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508136/bdq3zpkcrz1ez00md2yr.jpg)\n\nプラットフォームエンジニアリングの導入においては、基盤構築に役立つサービスを積極的に活用すると効率的です。ここでは具体的な選び方を解説します。\n\n* 機能  \n* コスト  \n* サポート体制\n\n### 7-1. 機能\n\nプラットフォームエンジニアリングの導入を成功させるためには、開発者のニーズを満たし、かつ自社の課題を解決できる機能が搭載されたサービスを選ぶことが大切です。\n\n例えば、プラットフォームを構成する重要な要素として挙げられる機能は以下の通りです。\n\n* CI/CD（自動ビルド・テスト・デプロイ）  \n* ソースコード管理  \n* ドキュメント  \n* モニタリング  \n* API連携  \n* セキュリティ・ガバナンス など\n\nこのような機能が搭載されているサービスなら、開発者の生産性向上に貢献できるでしょう。\n\n### 7-2. コスト\n\nプラットフォームエンジニアリングの基盤構築となるサービスを選定する際には、コスト面も考慮することが大切です。\n\n組織の規模や導入形態などによってもコストが異なるため、ベンダーに問い合わせするなどして費用対効果が期待できるかしっかりチェックしておきましょう。\n\n無料トライアルを設けているサービスも多いため、まずは使用感を試してみてから導入を検討するのも良いでしょう。\n\n### 7-3. サポート体制\n\nプラットフォームエンジニアリングをスムーズに導入・運用していくためには、ツールやサービスを提供するベンダーのサポート体制をチェックしておく必要もあります。\n\n充実したサポート体制があれば、万が一トラブルや不明点が発生した場合でも、専任スタッフが迅速に対応してくれるでしょう。また、ベンダーがドキュメントやマニュアルなどを通して積極的にノウハウを公開していれば、トラブル時にも自社で解決しやすくなるでしょう。\n\n## 8. プラットフォームエンジニアリングの基盤構築なら「GitLab」\n\n![プラットフォームエンジニアリングの基盤構築なら「GitLab」](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/hy8mmygwnbm0ws0ejtik.png)\n\nプラットフォームエンジニアリングの基盤構築をスムーズに実現するなら「[GitLab](https://about.gitlab.com/ja-jp/)」の活用がおすすめです。ここでは、GitLabのサービス概要や強みについて紹介します。\n\n### 8-1. GitLabとは\n\nGitLabは、DevSecOpsワークフローを支援するAIを搭載したプラットフォームです。AIによるソースコード管理やセキュリティ対策、CI/CD、コンプライアンス管理など豊富な機能を単一のプラットフォームで活用でき、プラットフォームエンジニアリングの基盤構築に役立てられます。\n\n中小企業からエンタープライズまで多くの企業で導入されているプラットフォームで、高品質かつ迅速なソフトウェア開発を実現できます。\n\n### 8-2. GitLabが選ばれる理由\n\nGitLabの強みは、DevSecOpsツールチェーンの構築を単一のプラットフォームで実現できることです。これまで複数のツールを管理していた企業がGitLabを導入すれば、コスト削減や開発者の認知負荷の軽減につなげられ、プラットフォームエンジニアリングの運用をスムーズに行えるようになります。\n\nチーム全員で単一のプラットフォームを通して作業することで、メンバー間の連携や情報共有も容易に実施できます。また、サポート体制も充実しているため、導入と運用においても安心して進められるのも強みの一つです。\n\nGitLabを通してプラットフォームエンジニアリングを実現すれば、ソフトウェア開発のライフサイクル全体を効率化でき、競合との差別化につながる機能開発など本質的な作業に集中できるようになるでしょう。\n\n## 9. GitLabによるプラットフォームエンジニアリング実現のアプローチと活用例\n\n![GitLabによるプラットフォームエンジニアリング実現のアプローチと活用例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508136/gn4zixnirbsgrk1anwi8.jpg)\n\n実際にGitLabによるプラットフォームエンジニアリング実現のアプローチと活用例を紹介します。\n\n* 再利用可能なCI/CDコンポーネント  \n* セキュリティとコンプライアンス  \n* データ活用と分析  \n* コミュニケーションの効率化\n\n### 9-1. 再利用可能なCI/CDコンポーネント\n\nCI/CDコンポーネントは、再利用可能な単一のパイプライン構成ユニットのことで、この機能を使用すればCI/CDパイプラインの設定が容易になります。\n\nまた、再利用可能なCI/CDコンポーネントをリスト化して、各コンポーネントの情報を確認できる「[CI/CDカタログ](https://gitlab.com/explore/catalog)」も提供しています。コンポーネントが一元管理されているため、必要なものを必要な時に見つけ出して再利用できる仕様となっています。\n\nこれにより、開発者の作業効率向上や、組織全体でのスムーズなナレッジ共有を実現できるでしょう。\n\nCI/CDコンポーネントの詳細については以下のページをご覧下さい。\n\n[GitLab入門：CI/CDについて理解する](https://about.gitlab.com/ja-jp/blog/getting-started-with-gitlab-understanding-ci-cd/)\n\n### 9-2. セキュリティとコンプライアンス\n\nGitLabでは、ソフトウェア開発ライフサイクルの全てのステージに対応したセキュリティやコンプライアンス機能を搭載しています。\n\n開発を進める中で、セキュリティリスクなどの問題を早期に発見して対応できるため、トラブル発生時の対応コストを抑えたり、事態の深刻化を未然に防止したりすることが可能です。\n\n### 9-3. データ活用と分析\n\nGitLabでは、データ活用と分析による開発の効率性向上も実現できます。プロジェクトの運用状況などソフトウェア開発ライフサイクルにおけるさまざまなデータが一元管理されている仕組みとなっているため、関係者全員がスムーズに必要な情報にアクセスできます。\n\nまた、 プラットフォームに蓄積された主要なメトリクスを追跡して問題点を詳細に分析することで、迅速な改善や顧客価値の向上につなげられます。GitLabでは、DevOpsのパフォーマンスや健全性を示す[DORAメトリクス](https://docs.gitlab.com/user/analytics/dora_metrics/)の可視化・分析機能などを提供しています。\n\n### 9-4. コミュニケーションの効率化\n\nGitLabは統合型プラットフォームであり、全員が同じツールにアクセスして利用できるようになるため、開発者間でのコミュニケーションが効率化されます。\n\n誰もがアクセスしやすい共同ドキュメントの作成も可能であるため、別のツールに切り替えて作業する必要がなく、情報の共有や整理が容易になります。\n\nなお、プラットフォームエンジニアリングにおけるGitLab活用の詳細については以下のページをご覧下さい。\n\n> [プラットフォームエンジニアリングにおけるGitLabの活用](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)\n\n[](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)\n\n## まとめ： プラットフォームエンジニアリングの実現により開発品質の向上と効率化を図ろう\n\nプラットフォームエンジニアリングの導入は、ビジネス環境が激化している時代において重要視されているアプローチです。実際の導入においては、適切な専門チームの組成やツール・サービスの選定が大切なポイントとなってきます。\n\nプラットフォームエンジニアリングの基盤構築なら、ぜひ[GitLab](https://about.gitlab.com/ja-jp/)をご活用下さい。GitLabなら単一のプラットフォームで豊富な機能を利用できるため、開発者の認知負荷を軽減し、迅速かつ品質の高いソフトウェア開発を実現できます。\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-platform-engineering)\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)*\n\n*（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","2025-09-22",[967],"GitLab Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508254/duu6d4vclamtnnxjdaat.jpg","プラットフォームエンジニアリングとは？意味や導入メリットをわかりやすく解説","この記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。",[109,944,972,713,795,973,796,809],"DevOps","performance",{"featured":6,"template":799,"slug":975},"what-is-platform-engineering",{"content":977,"config":985},{"heroImage":978,"date":979,"authors":980,"category":729,"body":981,"tags":982,"title":983,"description":984},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988342/gqogwxai28zzwwuj2z3i.jpg","2025-09-16",[967],"ソフトウェア開発におけるプロジェクト管理を円滑に行うには「ガントチャート」の活用が役立ちます。実際に自社の開発プロジェクトにおいて複雑で多岐にわたるプロセス管理に課題を感じており、ガントチャートの活用を検討している人もいるのではないでしょうか。\nこの記事では、ガントチャートの役割や活用のメリット、具体的な作成方法などを解説します。ガントチャートの作成やプロジェクト管理におすすめのツールも紹介しているのでぜひ参考にして下さい。\n\n## 1. ガントチャートとは？意味やその役割\n\n![ガントチャートとは？意味やその役割](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988290/sjxtqobutpz8gwszlfaw.jpg)\n\nまずはガントチャートの意味や役割など基礎知識について解説します。\n\n### 1-1. ガントチャートの定義・意味\n\nガントチャート（Gantt Chart）とは、プロジェクトのスケジュール管理やタスク管理のために活用されるツールです。縦軸に各タスクと作業の開始日・終了日を示し、横軸に進捗を示す時間軸を配置することでプロジェクトの進捗状況やタスク間の依存関係、担当者を一目で把握できます。\nガントチャートはIT業界だけでなく、建設業などさまざまな業種・業界のプロジェクト管理に活用されています。\n\n### 1-2. ソフトウェア開発におけるガントチャートの役割\n\nソフトウェア開発では、要件定義からプログラミング、テスト、リリース、保守運用まで多岐にわたる工程を踏む必要があり、複数の人材や関係者がプロジェクトに参加します。\nその中でメンバーや関係者間の認識のズレを防止しつつ、プロジェクトを円滑に進めるにはガントチャートによる徹底したスケジュール管理とタスク管理が重要です。\nガントチャートはソフトウェア開発において、メンバー間のコミュニケーションの向上や適切な進捗管理の実現、リカバリー策の設計などの役割を担います。\n\n## 2. ガントチャートの歴史・誕生背景\n\n![ガントチャートの歴史・誕生背景](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988299/y4ewrmhuneplgjp1lbcg.jpg)\n\nガントチャートは、1896年にポーランドの経済学者であるKarol Adamiecki（カロル・アダミエツキ）氏によって最初に作成されたと言われています。\nその後、1910年代にHenry Gantt（ヘンリー・ガント）氏が独自のバージョンとしてガントチャートを考案しました。Henry Gantt氏は、工場で働く労働者が与えられたタスクを完了させるのにどのくらいの期間を要したかを現場の責任者が確認できるよう独自にガントチャートを考案したのです。\nさらに、Henry Gantt氏の死後、Wallace Clark（ウォーレス・クラーク）氏が、自身の著書でガントチャートの使い方やそのメリットを解説し、世界中に普及しました。\n\n## 3. ガントチャートの一般的な構成要素\n\nガントチャートを作成・活用する際には、構成要素について理解しておく必要があります。\n| 構成要素 | 詳細 |\n| :---- | :---- |\n| タスク | プロジェクトにおける各作業 |\n| タスクの期間 | 各作業の実施期間（開始日と終了日） |\n| タスクの担当者 | 各タスクの担当者の名前 |\n| タスクの依存関係 | タスク同士がどのような影響を与えるか |\n| タイムスケール | チャートの上部に示す時間軸（日・週など） |\n| マイルストーン | プロジェクトの重要な中間目標や節目 |\n| 進捗率 | タスクの完了率（%で表示） |\n一般的には上記のような要素で構成されますが、自社のプロジェクトの規模や内容によっても記載する要素は異なります。\n\n## 4. ガントチャートとWBS・バーチャート工程表との違い\n\n![ガントチャートとWBS・バーチャート工程表との違い](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988296/ymdhirenqdz60ohwb1ys.jpg)\n\nガントチャートと混同されやすい用語として「WBS」と「バーチャート工程表」があります。それぞれの違いについて詳しく解説します。\n\n### 4-1. ガントチャートとWBSとの違い\n\nWBSとは、「Work Breakdown Structure」の略語でプロジェクト全体の作業を段階的に細分化したリストのことです。「プロジェクトを達成するためには何をすべきか？」という点にフォーカスし、必要なタスクを整理するのが目的です。\n一方、ガントチャートは時間軸を活用してWBSで整理されたタスクの進捗状況の把握や全体のスケジュール管理を行うための表を指します。つまり、ガントチャートを作成する際にはWBSによるタスクの細分化が不可欠であり、両者は密接な関係にあります。\n\n### 4-2. ガントチャートとバーチャート工程表との違い\n\nバーチャート工程表とは、縦軸に作業項目、横軸に時間を示して、横棒（バー）を使って作業の実施時間を可視化した図表を指し、主に建設現場や製造業で使われています。\nバーチャート工程表は、各タスクに要する実施期間を明確にすることを目的としていますが、ガントチャートのようにタスク間の依存関係を管理するのには向いていないツールです。\nソフトウェア開発においては各タスクの依存関係や進捗状況の把握が重要になってくるため、バーチャート工程表ではなくガントチャートの活用を検討することが大切です。\n\n## 5. ガントチャートを活用するメリット\n\n![ガントチャートを活用するメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988290/cjpufbck1bqaqizhiotv.jpg)\n\nガントチャートを活用することでどのようなメリットがあるのでしょうか。具体的には以下が挙げられます。\n\n* プロジェクトの全体像を把握できる  \n* 専門知識がなくても扱える  \n* 関係者間の認識のズレを防止できる  \n* マイルストーンを管理・最適化が可能になる  \n* タスクの依存関係を確認できる  \n* プロジェクトにおけるリカバリー策を取りやすい\n\n### 5-1. プロジェクトの全体像を把握できる\n\nガントチャートを活用すれば、関係者全員がプロジェクト全体の計画を直感的に把握できます。マネージャーや責任者だけでなく、メンバー1人ひとりがプロジェクト計画や進捗状況を確認できるため、個々が担当するタスクに対して責任を持って作業に取り組むことが可能です。例えば、「自分が担当しているタスクが完了しなければ、次のタスクに移れない」とタスク同士の依存関係を事前に把握していれば、計画を意識しながら作業を進められるでしょう。\nプロジェクトマネージャーも、ガントチャートを見ながらプロジェクトが計画的に進んでいるか常に状況をチェックできるため、メンバーへの指示も出しやすくなるでしょう。\n\n### 5-2. 専門知識がなくても扱える\n\nガントチャートは図表の構成そのものがシンプルであり、難解な用語も使用しないためメンバーや関係者に専門知識がなくても直感的に理解できます。プロジェクトマネージャーがガントチャートを作成する際にも専門知識は不要であり、専用ツールを活用すれば時間と手間をかけることなくスムーズな作成・修正が可能です。\n誰もが見やすくわかりやすいガントチャートを作成すれば、開発メンバーも戸惑うことなく作業に集中できるようになるでしょう。\n\n### 5-3. 関係者間の認識のズレを防止できる\n\nガントチャートで全体のプロジェクト計画をメンバーや関係者間で共有すれば、認識のズレなく全員が同じ方向を向いて開発を進められます。\n例えば、開発側と顧客側で認識のズレがあると、本来必要のない機能の開発のために工数を割いてしまうということにもなりかねません。ガントチャートなら、必要なタスクを細分化してスケジュールとして可視化できるようになっているため、関係者全員が事前に擦り合わせした上で計画を実行することが可能です。\nまた、開発途中でなんらかの課題や変更が発生した場合でも随時状況を共有し、スケジュールを修正すれば問題なくプロジェクトを進められるでしょう。\n\n### 5-4. マイルストーンの管理・最適化が可能になる\n\nマイルストーンとは、プロジェクトにおける重要な中間目標地点を指す言葉です。全体のスケジュールを可視化できるガントチャートなら、プロジェクト計画において重要な要素となるマイルストーンの管理も行うことができます。\n例えば、ガントチャート上にマイルストーンを設置すれば、「この期間までにはこのタスクを完了している必要がある」と視覚的に把握できるため、メンバー間での認識の強化やプロジェクトの遅延防止につなげられるでしょう。\n\n### 5-5. タスクの依存関係を確認できる\n\nソフトウェア開発を進めるに当たり、タスクによっては前のタスクが完了していないと着手できないといった依存関係が発生するケースも少なくありません。\nガントチャートを作成する際に各タスクにおける依存関係をマッピングすれば、容易にタスク同士の関係性を把握でき、ボトルネックの可能性を事前に認識することが可能です。例えば、タスクの依存関係が集中するフェーズでは、他の担当者がフォローできる体制を整えておくなどの対策を検討できるでしょう。\nなお、ガントチャートで各タスクの依存関係を示す際には必要な機能が搭載されたツールを活用すると効率的です。\n\n### 5-6. プロジェクトにおけるリカバリー策を取りやすい\n\nソフトウェア開発においては必ず計画通りプロジェクトが進むというわけではなく、途中トラブルなどが発生するケースも多いです。\nガントチャートで全体のスケジュールやタスクを可視化しておけば、急なトラブルや仕様変更などが発生した場合でも、どのフェーズまで戻り、どのような作業が必要になるのか検討しやすくなります。このように迅速なリカバリー策を講じることで、顧客の要望に沿った開発を実現できるでしょう。\nなお、計画に変更が生じた場合はガントチャートの修正も忘れずに行うことが大切です。\n\n## 6. ガントチャートの注意点\n\n![ガントチャートの注意点](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988298/gzdswdhfx3mnedmvxv2v.jpg)\n\nガントチャートは、プロジェクト全体のスケジュールや各タスクの実施期間、進捗状況などを視覚的に確認できますが、作業工数における細かな情報については表示しないのが特徴です。例えば、「タスクAの実施期間は10日間」と表示されている場合でも、タスクAを完了させるために必要な細かな工数が見えないため、想定以上のコストがかかる場合があります。\nこのような事態を避けてプロジェクトを円滑に進めるためには、ガントチャートの活用と併せて工数管理表などのツールを導入し、別途で工数を管理する方法を検討することが大切です。\n\n## 7. ガントチャートの作り方\n\n![ガントチャートの作り方](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988291/j4iylagxbsfajpa3s6uw.jpg)\n\nここではガントチャートの作り方について解説していきます。\n\n### 7-1. WBSを作成する\n\nガントチャートを作成する際には、まずWBSを作成してプロジェクトに必要なタスクを洗い出していきます。\nWBSでタスクを細分化することによって、作業内容が明確になり全体のスケジュール管理がしやすくなります。WBS作成の土台となるのはプロジェクトの目標設定です。開発における最終成果物や成功の定義が明確であるほど、ゴールまでのプロセスを丁寧に考えることができます。必要なタスクの洗い出しにおいては、まずは大きなフェーズから書き出し、そこからさらに細分化していくというステップを踏むのがポイントです。そうすることで次で紹介するタスクの依存関係の整理がスムーズになります。\n\n### 7-2.タスク間の依存関係を整理する\n\nプロジェクト達成に必要なタスクを洗い出した後は、各タスクの依存関係を整理します。「タスクAの作業が完了しなければ、タスクBに進めない」という依存関係がある場合は、視覚化して整理しておくことが大切です。\n例えば、開発において設計が完了しないと次のプログラミングに着手できないというケースは依存関係に該当するため、関係性をきちんと整理しておきます。\n\n### 7-3.各タスクのスケジュールを設定する\n\n次に各タスクに費やす作業期間を検討し、開始日と終了日を設定します。タスクの作業期間はプロジェクトの規模やタスクの内容に応じて、日数や週数の単位で検討します。その際、タイトなスケジュールを組んでしまうとメンバーの負担増加や、プロダクトの品質低下を招く原因にもなるため、余裕を持たせた上で各タスクの作業期間を設定することが大切です。\nまた、タスク間で依存関係が発生するフェーズにおいては遅延の可能性も考慮しなければなりません。\n併せてマイルストーンの設定も行っておきます。プロジェクトの中間目標を認識した上でスケジュールを検討することで、各タスクにおいて適切な作業期間を設定できるでしょう。\n\n### 7-4.各タスクの担当者を割り当てする\n\n各タスクのスケジュール設定が完了した後は、担当者を割り振っていきます。担当者の選定においては、個人のスキルや経験などを考慮しながら行います。各タスクの割り振りを誤ってしまうと、プロジェクトの遅延やトラブルを招くため、プロジェクトマネージャーはメンバーの能力をよく理解した上で検討しなければなりません。\n各タスクの担当者が決定したらガントチャート上に担当者の名前を記載しておきます。そうすることで誰がどのタスクを担当するのかをメンバー全員が把握できるため、個々が自身のタスクにおいて責任感を持てるようになります。\n\n### 7-5.関係者への共有と更新\n\nガントチャートの作成が完了すれば、メンバーや顧客など関係者全員に共有します。その中で関係者からタスクの洗い出しや作業期間において指摘やフィードバックがあった場合は、修正を実施します。関係者全員で共通の認識がなく、懸念点を抱えたままプロジェクトがスタートしてしまうとスムーズに作業が進まないため、時間をかけて細かな擦り合わせをしておきましょう。\nまた、プロジェクト開始後にも定期的なミーティングを実施し、進捗状況や認識のズレがないかを確認します。繰り返しにはなりますが、仕様変更やトラブルの発生などによって計画が変更された場合は、ガントチャートの修正も忘れずに行うことが大切です。\n\n## 8. ガントチャートを作成する際のポイント\n\n![ガントチャートを作成する際のポイント](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988290/uz6tvvkkuepoghl2zo2k.jpg)\n\nガントチャートを作成する際には以下のポイントを意識することが大切です。\n\n* 視認性の高さを意識する  \n* 更新されることを前提に作成する\n\n### 8-1. 視認性の高さを意識する\n\nガントチャートはプロジェクトの関係者全員に共有するツールであるため、誰もが見やすい形で作成することが大切です。例えば、以下のような工夫が考えられます。\n\n* タスクの作業期間を示す横棒（バー）は、タスクのカテゴリ別に色分けする  \n* タスクの依存関係によりボトルネックが発生しそうなフェーズにはマークをつけておく  \n* マイルストーンにはわかりやすいアイコンを配置しておく など\n  視認性の高いガントチャートを作成するには、直感的なUIやレイアウト機能を備えた専用ツールを活用するのがおすすめです。\n\n### 8-2. 更新されることを前提に作成する\n\nガントチャートは事前に立てた計画通りに進行されるのが理想ですが、実際にはプロジェクトが開始されると仕様変更やトラブルが発生するケースも少なくありません。\nそのため、ガントチャートは「計画通りに進行させる」という前提ではなく、「更新されること」を前提として作成し柔軟性を持たせておく必要があります。例えば、バッファを含めて各タスクの作業期間を設定する、遅延が想定されるタスクにおいては別の担当者がフォローできるよう割り振りを工夫するなどの方法が挙げられます。\nプロジェクトの変更が発生した際に、同時に計画の変更もスムーズに行える体制を整えておくことで問題なく目標達成できるでしょう。\n\n## 9. ガントチャートと各開発手法との相性・使い方\n\n![ガントチャートと各開発手法との相性・使い方](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988297/gyoodojgd9rfatopq20e.jpg)\n\nソフトウェア開発においては、近年開発手法も変化してきているためガントチャートと各開発手法との相性も把握しておくことも大切です。\nソフトウェア開発の手法においてはこれまで「ウォーターフォール開発」が主流でした。ウォーターフォール開発は開発前に全ての機能計画を立ててから計画通りに作業を進める手法であるため、プロジェクト全体のスケジュール管理やタスク管理ができるガントチャートとの相性は良いと言えるでしょう。\nなお、近年変化が激化しているビジネス環境において、迅速に顧客や市場ニーズに対応するために「アジャイル開発」にも注目が集まっています。アジャイル開発はウォーターフォール開発のように全体のスケジュールを立ててから開発を進めるのではなく、機能単位ごとに実装とテストを繰り返し開発を進めていきます。そのため、アジャイル開発においてはガントチャートによるスケジュール管理は不向きだと捉えてしまうかもしれません。\nしかし、ガントチャートが持つ計画性はアジャイル開発にも工夫次第で組み合わせることも可能です。例えば、スプリントプラニングにガントチャートを取り入れれば、視覚的に各タスクの作業期間や依存関係を表現できます。\n\n## 10. ガントチャートを作成できるツール・サービス\n\n![ガントチャートを作成できるツール・サービス](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988291/fzynvxnilg3s0o3k9rf0.jpg)\n\nガントチャートを作成できるツール・サービスは以下の通りです。\n\n* エクセル・スプレッドシート  \n* プロジェクト管理ツール\n\n### 10-1. エクセル・スプレッドシート\n\nガントチャートは、エクセルやGoogleスプレッドシートを活用して自作で作成することが可能です。\nエクセルなら一般的にビジネスシーンで利用されることが多いツールであるため、操作に慣れている人であれば使いやすいでしょう。Googleスプレッドシートも、Googleアカウントを持っていれば手軽に利用できるツールです。\nただし、エクセルやGoogleスプレッドシートを活用してガントチャートを作成する場合は、さまざまな課題が発生するため後に詳しく解説します。\n\n### 10-2. プロジェクト管理ツール\n\nガントチャートを作成する方法としてプロジェクト管理ツールを活用する方法もあります。プロジェクト管理ツールは、複数のタスクやプロジェクトを管理でき、ガントチャートの作成も可能です。\nプロジェクト管理ツールなら、マイルストーン機能や依存関係の設定などさまざまな機能が搭載されており、ガントチャート作成における面倒な設定やレイアウト作成も不要です。ツール導入に当たりコストは発生しますが、プロジェクト管理における包括的なサポートを受けられるというメリットを考えると、高い費用対効果が期待できると言えるでしょう。\n\n## 11. エクセルなど自作でガントチャートを作成することの課題\n\n![エクセルなど自作でガントチャートを作成することの課題](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988291/njhjqwrqpccvuk0cocq1.jpg)\n\nここでは、先ほど紹介したエクセルやGoogleスプレッドシートを活用して自作で作成することの課題について解説します。\n\n* 作成や更新に時間がかかる  \n* 視認性が低い  \n* スケジュール共有に時間がかかる\n\n### 11-1. 作成や更新に時間がかかる\n\nエクセルやGoogleスプレッドシートでガントチャートを自作する場合、作成や更新に時間がかかってしまいます。作成においてはテンプレートを利用する方法もありますが、自社のプロジェクトに沿ってカスタマイズしたい場合は操作に慣れている必要があり、ある程度関数や条件付き書式などの知識も求められます。\nまた、スケジュールの変更が発生する度に手作業で更新しなければならないため時間と手間がかかり、誤操作や更新漏れも発生しやすいと言えるでしょう。\n特に、プロジェクトの規模が大きいほど更新や修正における負担が増し、重要な業務に注力できなくなる恐れがあります。\n\n### 11-2. 視認性が低い\n\nエクセルやGoogleスプレッドシートでガントチャートのレイアウト作成や調整を行う場合、視認性が低くなってしまう恐れがあります。例えば、見た目を調整しようと必要のない項目を増やしたり、無駄な色使いなどを行うとガントチャートの情報量が多くなりかえって見づらくなってしまうでしょう。\nガントチャートは一目で全体の計画や進捗状況が把握できるかというポイントが重要になってくるため、慣れていないとエクセルやGoogleスプレッドシートで表現するのが難しい可能性があります。特に大規模なプロジェクトの場合は自作で視認性の高いガントチャートを作成するのに適していないと言えるでしょう。\n\n### 11-3. スケジュール共有に時間がかかる\n\nエクセルやGoogleスプレッドシートの場合、リアルタイムでの情報共有が難しくなります。特にエクセルの場合、更新の度にクラウドサービスなど別の媒体を使って共有する必要があり手間がかかります。また、その際誤操作によってファイルが破損してしまう可能性もあるでしょう。\nこのような形で情報共有がスピーディーかつ、正確に行われないと関係者間で認識のズレが生じてしまい、プロジェクトが円滑に進まなくなる恐れがあります。情報共有の正確性や迅速化を目指すなら専用のプロジェクト管理ツールの導入を検討するのが良いでしょう。\n\n## 12. ガントチャートの作成・プロジェクト管理なら「GitLab」\n\n![ガントチャートの作成・プロジェクト管理なら「GitLab」](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988295/ldz4szcwrxwnpfl0bfnk.png)\n\nガントチャートの作成やプロジェクト管理を効率化するなら「[GitLab](https://about.gitlab.com/ja-jp/)」の導入がおすすめです。ここでは、GitLabの概要やプロジェクト管理機能の特徴について紹介します。\n\n### 12-1. GitLabとは\n\nGitLabは、AIを搭載したDevSecOpsプラットフォームです。AIによるソースコード管理やCI/CDによる開発プロセスの自動化、プロジェクト管理、セキュリティ強化など企業のソフトウェア開発を支援するさまざまな機能を提供しています。\nDevSecOpsとは、ソフトウェア開発における開発・セキュリティ・運用を掛け合わせたアプローチを指し、開発サイクル全体を効率化できるGitLabなら単一のプラットフォームでDevSecOpsを実現できます。GitLabは中小企業からエンタープライズまで世界中の多くの企業で導入されているプラットフォームです。\n\n### 12-2. GitLabのプロジェクト管理機能の特徴\n\n[GitLabのプロジェクト管理](https://about.gitlab.com/ja-jp/blog/getting-started-with-gitlab-mastering-project-management/)にはさまざまな機能が搭載されています。例えば、「ロードマップ」ならエピック（プロジェクトの大枠や目標）とマイルストーンをタイムライン形式（ガントチャート風）で視覚的に表示することが可能です。また、イシュー（タスク）の間に依存関係を設定することもできるため、事前に潜在的な障害を回避できます。\nその他にもアジャイル開発のプランニングに役立つ「イテレーション」や作業時間を測定できる「タイムトラッキング」などの機能があり、GitLabを導入することで自社のプロジェクト管理を円滑に進められます。\n\n## 13. ガントチャートを作成してプロジェクトを円滑に進めよう\n\nガントチャートを自社のソフトウェア開発に積極的に取り入れることで、全体のスケジュール管理やタスク管理がスムーズになり、プロジェクトの成功率を高められるでしょう。ガントチャートの作成はエクセルなどを利用して自作することも可能ですが、時間と手間がかかるためプロジェクト管理ツールを導入するのがおすすめです。\n[GitLab](https://about.gitlab.com/ja-jp/)なら、ソフトウェア開発におけるプロジェクト管理を効率化できる豊富な機能を揃えています。ガントチャートを作成して自社のプロジェクト管理を円滑に行いたいと考えている人は、ぜひ導入をご検討下さい。\nなお、[GitLab](https://about.gitlab.com/ja-jp/)では世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧ください。\n\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-gantt-chart)",[944,796,809,795],"ガントチャートとは？ソフトウェア開発における役割やメリット、作り方","ガントチャートとは何か、作り方やメリットを詳しく解説。プロジェクト管理に役立つおすすめツールも紹介します。",{"featured":6,"template":799,"slug":986},"what-is-gantt-chart",{"content":988,"config":996},{"title":989,"description":990,"authors":991,"heroImage":992,"date":993,"body":994,"category":729,"tags":995},"ローカルLLMとは？開発での活用メリットと注意点","ローカルLLMの意味やクラウドLLMとの違い、ソフトウェア開発における導入メリットなどを解説します。",[967],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577836/qjcz9aubvivrn4zy1kqr.jpg","2025-09-12","近年ソフトウェア開発の領域では、開発プロセスの効率化や生産性向上などを目的としてAIの活用が重要視されています。その中で企業のセキュリティ要件に対応しやすい「ローカルLLM」にも注目が集まっています。\n\n実際にソフトウェア開発におけるAI活用において、ローカルLLMの導入を検討している人も多いのではないでしょうか。\n\nこの記事では、ローカルLLMの意味やクラウドLLMとの違い、ソフトウェア開発における導入メリットなどを解説します。\n\n## 1 そもそもLLM（大規模言語モデル）とは？\n\n![そもそもLLM（大規模言語モデル）とは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577783/xdlztojxzueezzp0nnhh.jpg)\n\nローカルLLMについて触れる前にまずはLLM（大規模言語モデル）について理解しておきましょう。LLMとは、膨大なデータを学習し、人間のような自然な言語を使って文章の生成や理解ができる自然言語処理に特化した生成AIの一種です。後にも詳しく解説しますが、ソフトウェア開発の領域ではコードのレビューやドキュメント作成などに役立てられます。\n\nなお、LLMのような自然言語処理ができる言語モデルには「SLM（小規模言語モデル）」もあり、さらにLLMについて触れるなら「RAG（検索拡張生成）」についても理解しておく必要があります。以下でそれぞれの特徴やLLMとの違いについて解説します。\n\n### 1-1 SLM（小規模言語モデル）との違い\n\nSLMは、LLMと同じく自然言語処理が可能なAIモデルですが、「小規模言語モデル」という名前が示すようにLLMよりも小規模で軽量な言語モデルを指します。金融や医療、保険など特定の分野で活用されることが多く、軽量な処理のためリソース要件に制約がある環境でも利用しやすいです。\n\nLLMとSLMの違いを表でまとめると以下の通りです。\n\n|           | LLM（大規模言語モデル） | SLM（小規模言語モデル） |\n| --------- | ------------- | ------------- |\n| 規模（パラメータ） | 数百億〜数兆        | 数億〜数十億        |\n| 学習データ     | 幅広いタスクに対応     | 特定のタスクに特化     |\n| 必要リソース    | 高性能GPUなどが必要   | 軽量            |\n| 開発コスト     | 高い            | 低い            |\n| 処理速度      | 遅い            | 高速            |\n\n### 1-2 RAG（検索拡張生成）との違い\n\nRAGとは、「Retrieval-Augmented Generation」の略語であり、LLMの能力や回答精度を向上させるための技術を指します。具体的には、LLMと外部のデータベースを連携し、データベースから検索した情報を付加させる形で精度の高い回答を実現する手法です。\n\nLLMの場合は、学習された既存のデータだけを利用して文章を生成するため、適切な回答を得られない可能性があります。また、学習データが古くなると最新の情報が反映されないため、情報の正確性や信頼性に劣るケースも見られます。\n\nそこでRAGも活用すれば外部データと連携して回答を行えるようになるため、最新情報や必要な情報を反映させた正確かつ信頼性の高いアウトプットを得られます。つまり、RAGはLLM活用を後押しするような技術として位置付けられるでしょう。\n\n## 2 ローカルLLMとは？クラウドLLMとの違い\n\n![2 ローカルLLMとは？クラウドLLMとの違い](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577786/im83n2lheoasu6d1jix4.jpg)\n\nではここからはローカルLLMについて、クラウドLLMとの違いも踏まえながら解説していきます。\n\n### 2-1 ローカルLLMとは？\n\nローカルLLMとは、自社サーバーやユーザー個人のPC上などオンプレミス（ローカル）環境で動作する大規模言語モデルを指します。\n\nインターネット接続を必要としないのが大きな特徴で、機密情報を外部に送信することなくAIを活用できるため、企業のセキュリティ要件に対応しやすいです。また、オフライン環境で処理が完結することから、通信障害やネットワーク遅延などの影響を受けにくく、運用におけるリスクを軽減できます。\n\nさらに、ローカルLLMではモデルの再学習・微調整（ファインチューニング）も可能です。そのため、目的に応じて特定の業界やデータに特化させたモデルを構築できるなどカスタマイズ性が高いことも特徴の一つです。\n\n### 2-2 クラウドLLMとの違い\n\nクラウドLLMは、インターネットを介してベンダーのクラウドサーバー上で動作する大規模言語モデルを指します。ローカルLLMとは異なり、大前提として活用においてはインターネット接続が必須となります。\n\nクラウドであることから導入における初期費用を抑えられ、かつ高いスケーラビリティを持つものの、入力データは外部のサーバーに送信されるため、セキュリティが重視される業界やシーンにおいては懸念があると言えます。\n\nまた、ローカルLLMよりもカスタマイズ性は劣り、ベンダーのサービス範囲内となるため、自由度は高くはありません。\n\n## 3 ローカルLLMとクラウドLLMの比較表\n\n|           | ローカルLLM                             | クラウドLLM                                  |\n| --------- | ----------------------------------- | ---------------------------------------- |\n| 実行環境・接続要件 | ・自社サーバーやローカル端末で動作 ・インターネット接続不要      | ・ベンダーのクラウドサーバー上で動作 ・インターネット接続が必須         |\n| 処理速度・性能   | ・ハードウェアの性能に依存する ・ネットワーク遅延の影響を抑えられる  | ・高性能なサーバーの利用により処理速度が速い ・通信障害の影響を受ける場合がある |\n| コスト       | ・ハードウェアへの投資が必要 ・運用コストは維持費が中心で安定しやすい | ・従量課金が一般的 ・初期費用を抑えられる                    |\n| セキュリティ    | ・オンプレミス環境によりデータを外部に送信する必要がない        | ・データを外部に送信する必要があるため、懸念あり                 |\n| カスタマイズ性   | ・自社のニーズに合わせたモデルを構築しやすい              | ・ベンダーのサービス範囲内                            |\n| スケーラビリティ  | ・物理的なリソースを都度調整する必要がある ・クラウドより手間がかかる | ・柔軟にリソースを調整できる                           |\n\nローカルLLMとクラウドLLMの違いをまとめると上記の通りになります。ただし、OpenAIが提供している「gpt-oss」のように低スペックで動作するような効率性の良いLLMも登場してきています。そういった背景からコスト面などの違いにおいては2025年8月現在、少し状況が変わってきているとも言えるため、定期的な情報収集が必要です。\n\n## 4 ローカルLLMが注目されている背景\n\n![4 ローカルLLMが注目されている背景](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577785/fuhck2u8wdffx6rmk5nc.jpg)\n\nなぜソフトウェア開発やビジネスにおいて、ローカルLLMが注目されているのでしょうか。具体的な背景としては以下が挙げられます。\n\n* 生成AI活用に対する企業ニーズの増加  \n* セキュリティ意識の向上  \n* 技術的な進化\n\n### 4-1 生成AI活用に対する企業ニーズの増加\n\nソフトウェア開発の領域においては、多様化するニーズやビジネス環境の変化に対応するためにAI活用のニーズが高まっています。\n\n実際に[GitLab](https://about.gitlab.com/ja-jp/)が開催したイベント「[DevOpsDive2025](https://about.gitlab.com/ja-jp/blog/event-report-devopsdive2025/)」によると、ソフトウェア開発ライフサイクルにおいてAIを使用中の国内企業の割合は48%で、米国の38%よりも高い数値となっています。ただし、国内のAI活用はコーディングの範囲に留まっている状況で、開発プロセス全体を通した活用には至っていません。\n\nソフトウェア開発ライフサイクル全体にAI活用を行き渡らせるためには十分なセキュリティ対策が必要になり、その手段として有効なのがローカルLLMの活用です。ローカルLLMならオンプレミス環境により企業の機密情報を安全に扱いながらAIを利用できます。つまり、ローカルLLMはAI活用における重要なソフトウェア開発基盤の一つだと言えるでしょう。\n\n### 4-2 セキュリティ意識の向上\n\n近年ビジネスにおけるIT活用が浸透する中で、セキュリティインシデントも多く発生しており、ソフトウェア開発の領域においてもセキュリティ対策への重要性が高まっています。\n\nLLMをクラウドベースで利用する場合、企業の重要な機密情報を外部のクラウドサーバーへ送信する必要があることから、情報漏えいのリスクが高まります。\n\nローカルLLMなら機密性の高いソースコードや仕様書などを、安心して投入して自由にAIを活用することが可能です。\n\n### 4-3 技術的な進化\n\nローカルLLMが注目されている背景として、技術的な進歩も挙げられます。例えば、日本語特化型LLMの登場により、日本企業がローカルLLMを導入する際にも扱いが容易になり、実用性が高まっています。\n\nまた、先ほど少し触れたようにモデルの軽量化により低スペックで動作できるようなLLMも登場してきているため、以前よりローカルLLMをスムーズに導入できる環境が整ってきていると言えるでしょう。\n\n## 5 ソフトウェア開発におけるローカルLLMのメリット\n\n![5 ソフトウェア開発におけるローカルLLMのメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577783/kj2jyvoa0bv2n67kwmxu.jpg)\n\nソフトウェア開発におけるローカルLLM導入のメリットは以下の通りです。\n\n* 開発の効率性と生産性の向上  \n* セキュリティ・コンプライアンスの強化  \n* コストの最適化\n\n### 5-1 開発の効率性と生産性の向上\n\nローカルLLMはソフトウェア開発ライフサイクルにおけるさまざまなプロセスで活用できます。例えば、コード補助や自動レビュー生成、バグ修正、脆弱性修正補助などに使えば、ヒューマンエラーのリスクを軽減しながら迅速かつ品質の高いソフトウェア開発を実現することが可能です。\n\nローカルLLMの活用によって効率よく開発を進めることで、開発者はより価値の高い活動や業務に集中できるようになり、結果としてチーム全体のパフォーマンスを向上させられるでしょう。\n\n### 5-2 セキュリティ・コンプライアンスの強化\n\n繰り返しにはなりますが、ローカルLLMなら自社サーバーを利用するため外部にデータを送信する必要がなく、セキュリティやコンプライアンスの強化を図りながら生成AIを活用できます。セキュリティ要件の厳しいプロジェクトや業界でも活用しやすく、開発者の心理的ハードルも下げられ安全に作業を進められるでしょう。\n\nまた、ローカルLLMを通して潜在的な脆弱性を検出し、修正案の提案を受けることでコードの安全性向上にもつなげられます。\n\n### 5-3 コストの最適化\n\nローカルLLMの導入によりコストの最適化を図れるメリットもあります。クラウド型のLLMは初期費用を抑えられるものの、従量課金制を採用していることから利用量（トークン数）が増えると、コストが大幅に増えてしまう可能性もあります。\n\n一方、ローカルLLMは初期にハードウェア導入費用が発生しますが、一度構築してしまえば運用に必要な費用は基本的に維持費だけになるため、長期的な視点で考えるとコストの最適化を図れるでしょう。\n\n## 6 ローカルLLM導入におけるデメリット・課題\n\n![6 ローカルLLM導入におけるデメリット・課題](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577779/k5x3ndhan9varjcyvlqb.jpg)\n\nローカルLLMの導入においては以下のようなデメリットや課題もあるため、事前に把握しておく必要があります。\n\n* 専門知識の必要性  \n* 高額な初期導入コストの発生  \n* 不正確・不完全なデータを生成する可能性\n\n### 6-1 専門知識の必要性\n\nローカルLLMを導入するためには、オープンソースLLMを自社サーバーで実行できるよう環境の構築やモデルの最適化が必要になります。このプロセスにおいては、専門的な知識や技術が求められるため、社内で適切な人材を配置しなければなりません。基盤となるインフラ設計やファインチューニングなどさまざまな知識が必要になりますが、特にvLLMとHugging Faceなどでホストされているモデルに関する知識が重要です。\n\nまた、ローカルLLM導入後のメンテナンスやセキュリティ管理なども自社で対応しなければならないため、事前に社内で体制を整備しておきましょう。\n\n### 6-2 高額な初期導入コストの発生\n\nローカルLLMを導入する際には、高性能なハードウェアなどを確保する必要があるため、初期の導入コストが高額になりがちです。特に大規模なモデルを扱う場合は、計算能力の高い高価なGPUを用意しなければなりません。\n\nしかし先述したように一度導入してしまえばその後の運用コストは安定しやすいため、長期的な利用を前提とすればクラウドLLMよりも経済的な効果が期待できる可能性は高いと言えます。\n\nなお、NVIDIAと同等スペックのハードウェアを低価格で提供する動きが既にあるので、そのあたりも注視しておきたいところです。\n\n### 6-3 不正確・不完全なデータを生成する可能性\n\nローカルLLMを活用する際には、AIが必ずしも正しいデータを生成するとは限らないことを理解しておく必要があります。例えば、ソフトウェア開発において脆弱性の分析や修正をローカルLLMを通して自動化する場合、正しい結果がアウトプットされない可能性もあるため、AIからの修正案を検討するタイミングなどにおいては人間による二重チェックを積極的に行うことが大切です。\n\nなお、ローカルLLMのデータ品質を保つためには、定期的なモデルのアップデートが重要です。クラウドLLMのように自動で最新の状態にアップデートされるわけではないため、自社で再学習や調整作業を行わなければなりません。\n\n## 7 ソフトウェア開発におけるローカルLLMの活用例\n\n![7 ソフトウェア開発におけるローカルLLMの活用例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577784/ipjhxxa41aoymc7nvkbc.jpg)\n\nソフトウェア開発においては以下のようなプロセスにおいてローカルLLMを活用できます。\n\n* コード補完・レビュー  \n* ドキュメント作成・ナレッジ共有  \n* CI/CDパイプラインの作成\n\n### 7-1 コード補完・レビュー\n\nソフトウェア開発でローカルLLMを導入することで、オフラインでのコード補完・レビューが可能になります。コード補完ならコードを記述している際に、AIがコードの提案を行なってくれるため、開発者のコーディングスピードの向上が期待できます。\n\nまた、コードレビューの自動化により、開発者は効率的にコードの改善を実施でき、AIで一貫性のあるレビューを実現することでコード品質の向上につなげられるでしょう。\n\n### 7-2 ドキュメント作成・ナレッジ共有\n\nローカルLLMの活用は、ソフトウェア開発におけるドキュメント作成やナレッジ共有でも役立ちます。例えば、ドキュメント作成なら仕様書の初稿作成や内容のチェックをローカルLLMを通して行えば、作業の効率化につなげられます。\n\nまた、RAGと連携して社内ナレッジベースや文書を利用して社内Q&A検索などを構築すれば、開発チーム内でのナレッジ共有をスムーズに行えるでしょう。\n\n### 7-3 CI/CDパイプラインの作成\n\nソフトウェア開発でのローカルLLMの活用は、[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)パイプラインの作成やパイプライン実行時のエラー調査にも貢献できます。また、テストコード生成によってテスト作業の軽減化も支援することが可能です。\n\n[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)パイプラインの構築から実行におけるプロセスを効率化すれば、開発者はソフトウェアの開発作業に集中できるようになるため、リリース頻度やスピードの向上につなげられます。\n\n## 8 ローカルLLMの導入方法\n\n![8 ローカルLLMの導入方法](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577783/xpoecwmgfqwwyxis4rxj.jpg)\n\nでは実際にローカルLLMを導入するにはどのような手順を踏めば良いのかを解説します。\n\n1. 目的と要件の整理  \n2. 環境整備  \n3. 継続的な検証と改善\n\n### 8-1 1.目的と要件の整理\n\nまずはソフトウェア開発の領域において「なぜローカルLLMの導入が必要なのか？」という目的を明確化することが大切です。\n\n例えば、「クラウドからの移行によるコスト最適化を図りたい」「自社のセキュリティ要件にマッチした開発環境を構築したい」など目的を検討します。明確な目的がないと導入そのものが目的となってしまい、十分な効果を得られないためきちんと設定し、社内で共通の認識を持っておく必要があります。\n\nまた、ローカルLLMを導入して具体的にどのような成果を得たいのか定量的なKPIもあわせて設定しておくことで、導入後の効果検証や改善がしやすくなります。例えば、開発コストの削減量やパイプライン実行時間などの目標値の設定が考えられます。\n\n### 8-2 2.環境整備\n\n次にローカルLLMの実行に必要なモデルの選定や環境構築を行います。モデルの選定においては導入目的をもとに、求められる性能やリソース要件などを考慮して検討します。\n\nハードウェア環境においては、使用するモデルのサイズや用途、利用ユーザー数などに応じた要件を満たすことがポイントとなり、特にGPUの性能が重要です。ハードウェア環境が整った後は、ソフトウェア環境の設定を行い実際にモデルを実装していきます。\n\n### 8-3 3.継続的な検証と改善\n\nモデル実装後は、継続的なパフォーマンステストと改善を行います。具体的には、処理速度や回答精度、リソースの利用状況などを検証し、必要に応じて改善や調整を実施します。なお、実際の運用においてはまずは小規模なプロジェクトから開始し、検証結果の内容や利用ユーザーのフィードバックを取り入れながら徐々に拡大していくと良いでしょう。\n\nまた、長期的に安定して運用するためには、メンテナンスやアップデートをスムーズに行える体制づくりも必要です。\n\n## 9 ローカルLLMのおすすめモデル\n\n![9 ローカルLLMのおすすめモデル](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577779/z48qapdqnbbb67lotscz.jpg)\n\nローカルLLMの導入にあたっておすすめのモデルを紹介します。なお、ここで紹介するモデルは[GitLabのサポート対象](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#supported-models)です。\n\n* Mistral-Small-3.2-24B-Instruct-2506  \n* Codestral 22B  \n* Llama 3\n\n### 9-1Mixtral-8x7B-Instruct-v0.1\n\nMixtral 8x7Bは、Mistral AIが2023年12月にリリースした大規模言語モデルです。混合エキスパートモデル（MoE）を採用しているのが特徴で、学習・推論スピードに強みがあります。Mixtral 8x7Bならコード生成タスクでも高精度なアウトプットが期待でき、Duo Chatでも活用可能です。\n\n### 9-2 Codestral 22B\n\nMistral AIが2024年5月から公開しているCodestral 22Bは、コーディングに特化した大規模言語モデルです。PythonやJava、C、SQLなど人気のプログラミング言語を含め、80以上の言語に対応しています。コード自動補完など開発効率の向上を目的として活用できます。Chatには使えませんが、ソースコード生成処理として良い選択になります。この時にGitLabは、用途用途にモデルを切り替えられるメリットがあります。\n\n### 9-3 Llama3\n\nLlama3は、Meta社が2024年4月に公開したオープンソース大規模言語モデルです。Llama3には、「8B」と「70B」の2つのモデルが存在します。\n\nLlama3 8Bは、80億のパラメータを持つモデルで比較的コンパクトであることから、計算リソースが限られるシーンでの利用が向いています。一方、Llama3 70Bは、700億のパラメータを持つモデルであり、多様なタスクへの対応やパフォーマンス向上などを目的として活用できます。また、ライセンスフリーで利用可能なモデルの中では最高峰レベルの性能を誇るため、ハードウェアに予算が割けられる場合は70Bをおすすめします。\n\n## 10 ローカルLLM導入における注意点\n\n![10 ローカルLLM導入における注意点](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577779/twsdcll86zz9jgetvhq5.jpg)\n\nローカルLLMを導入する際には以下のような注意点があり、事前に必要な対策を検討しておくことが大切です。\n\n* 社内での周知・教育・活用定着を図る  \n* 社内でのセキュリティ設定・アクセス制御を徹底する  \n* モデルのライセンスを確認する\n\n### 10-1 社内での周知・教育・活用定着を図る\n\nローカルLLMを自社で導入した場合でも実際に開発者に使われないと意味がありません。導入目的の説明や操作マニュアル・ガイドラインの整備などを行い、利用の定着を図ることが大切です。社内におけるAI活用の利用状況を効率的にチェックするには、ツールの活用がおすすめです。\n\nGitLabのサービスの一つとして「[AI Impact Dashboard](https://docs.gitlab.com/user/analytics/ai_impact_analytics/)」があり、この機能を活用することで自社のAI導入における利用状況を可視化してROIのモニタリングが可能になります。\n\n### 10-2 社内でのセキュリティ設定・アクセス制御を徹底する\n\nローカルLLMは自社サーバーで運用しますが、社内でのセキュリティ対策は必須です。\n\n社内でのセキュリティ対策としてまず挙げられるのは、モデルに入力した機密データの管理の徹底です。LLMが出力するログにはソースコードなどの断片が出力されるケースもあるため、LLMを運用しているOSへのログインや物理アクセスの管理などを行わなければなりません。\n\nまた、実際にモデルを入手する際には改ざんされたモデルを利用しないようダウンロード元には十分注意しましょう。\n\n### 10-3 モデルのライセンスを確認する\n\nローカルLLMを導入する際に注意点したい要素として、モデルのライセンス条件があります。各モデルによって付与されているライセンスが異なり、商用利用や改変、再配布の可否などの条件が設定されています。\n\nライセンス違反にならないよう使用予定モデルのライセンス規約を丁寧に確認し、運用におけるリスクを取り除いておきましょう。\n\n## 11 GitLab Duo Self-HostedによるローカルLLM運用\n\n![11 GitLab Duo Self-HostedによるローカルLLM運用](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577779/lqeesn9igwma1rdxohdd.png)\n\n[GitLab Duo Self-Hosted](https://about.gitlab.com/ja-jp/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy/)を活用することで、ローカルLLMをGitLabと連携して運用できます。[GitLab](https://about.gitlab.com/ja-jp/)は、ソフトウェア開発ライフサイクル全体を効率化できるDevSecOpsプラットフォームです。\n\nここでは、GitLab Duo Self Hostedの特徴やローカルLLMとの連携で実現できることを紹介します。\n\n### 11-1 GitLab Duo Self-Hostedとは？概要と主な特徴\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、GitLabが提供するソフトウェア開発におけるワークフローを支援するAIソリューションです。 [Self-Hosted版](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/)ならGitLab Duoをオンプレミス環境で運用できるため、安全にAIを活用しながら開発を進められます。\n\nまた、Mistralなど主要なモデルをサポート対象としているため、自社のセキュリティやパフォーマンス要件に応じて柔軟にモデルを選定し、最適なソリューションを構築できます。\n\n### 11-2 ローカルLLMとGitLabの連携で実現できること\n\nローカルLLMとGitLabの連携により以下のようなことが可能になるため、ソフトウェア開発における生産性と品質向上を実現できます。\n\n* コード補完・レビュー支援（20以上の言語に対応）  \n* セキュリティ脆弱性検出・修正提案  \n* アクセス制御  \n* AI投資のROI測定  \n* CI/CDのyml生成・トラブルシュート、コードレビューの自動化 など\n\n## 12 ローカルLLMの将来性・今後の展望\n\n![12 ローカルLLMの将来性・今後の展望](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577779/ycesbwldjawmyowsncrw.jpg)\n\n結論から述べるとローカルLLMの需要は拡大し、今後もさまざまなシーンで広く活用されていくと言えます。\n\n一般社団法人 電子情報技術産業協会（JEITA）が発表した「生成AI市場の世界需要額見通し」によると、生成AI市場の世界需要額は年平均53.3%で成長しており、2030年には2,110億ドルに達すると言われています。これは、2023年の106億ドルから約20倍の需要額となる見込みです。\n\nローカルLLMは、厳しいセキュリティ要件にも対応できるなどソフトウェア開発やビジネスにおいて多くのメリットがある技術です。今後も低スペックで動作する高性能モデルの登場や、クラウドとのハイブリッド活用などさらなる技術の発展やアプローチによって、開発者にとって必要不可欠なソフトウェア開発基盤として機能していくでしょう。\n\n※出典：[JEITA、生成 AI 市場の世界需要額見通しを発表](https://www.jeita.or.jp/japanese/topics/2023/1221-2.pdf)\n\n## 13 ローカルLLMに関するQ＆A\n\n![13 ローカルLLMに関するQ＆A](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577779/a4v40ozyl3jquhqhpsav.jpg)\n\n最後にローカルLLMに関するQ＆Aを紹介します。\n\n### 13-1 ローカルLLM導入はどのようなチームに向いている？\n\nローカルLLM導入は以下のような条件に該当するチームに向いています。\n\n* プロジェクトや業界のセキュリティ要件が厳しい  \n* 機密性が高いソフトウェア開発をしている  \n* CやC++など高い技術力が求められる言語で開発しているが、人員集めに苦労している  \n* クラウドのAPI課金に対してコスト面で負担を感じている  \n* LLMをDevSecOpsに組み込みたい など\n\n### 13-2 ローカルLLM運用のための最低限のハードウェア条件は？\n\nGitLab Duo Self-Hostedをオンプレミスで実行する場合は以下の通りです。ただ実際の要件はモデルのサイズと使用目的などによって異なるため、参考程度として捉えてください。\n\n・GPU：1 x NVIDIA A100（40GB）\\\n・VRAM: 35GB以上\\\n・ストレージ：モデルサイズ分以上\n\n※参考：[ハードウェア要件 | GitLab Duo](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#hardware-requirements)\n\n### 13-3 ローカルLLMとクラウドLLMのハイブリッド活用例は？\n\nローカルLLMとクラウドLLMの使い分けやハイブリッド活用においては目的や要件によって判断する必要があります。\n\n例えば、機密性の高いソースコードに関する作業であり、かつ利用頻度も高い場合はローカルLLMで実行する必要があります。一方で機密性が低く、かつソースコードに関する作業頻度も低い場合は、クラウドLLMを利用すると良いでしょう。\n\n万が一クラウドLLMを運用中に障害が発生した時は、ローカルLLMを利用します。ただし、使用するモデルが異なるとアウトプットの質にも影響が出てくるため、可能な範囲でハイブリッド活用を検討します。\n\nなお、クラウドLLMは最新モデルを素早く利用できる利点と、モデルを動作するインフラの規模（GPUやVRAMなど）を気にする必要がないため、最新のクオリティでLLMを活用したいケースでの利用が向いているでしょう。\n\n## まとめ ローカルLLMを自社のソフトウェア開発に取り入れよう\n\nソフトウェア開発においてローカルLLMを採用することで、セキュリティ要件が厳しいケースにおいても安全に開発を進められます。実際の導入においては目的の明確化や自社ニーズ・リソースにマッチしたモデルの選定、適切な運用体制の構築が鍵となってきます。\n\nローカルLLMを自社の開発プロセスに導入するならぜひ「[GitLab Duo Self-Hosted](https://about.gitlab.com/ja-jp/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy/)」をご活用ください。GitLab Duo Self-Hostedならオンプレミス環境でさまざまなAI機能を活用して、高品質かつ迅速なソフトウェア開発を実現できます。\n\nなお、[GitLab](https://about.gitlab.com/ja-jp/)では世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧下さい。\n\n*監修：小松原つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)*\n\n*（GitLab合同会社ソリューションアーキテクト本部シニアパートナーソリューションアーキテクト）*",[837,713,795,796,775],{"featured":6,"template":799,"slug":997},"what-is-local-llm",{"category":737,"slug":741,"posts":999},[1000,1012,1024],{"content":1001,"config":1010},{"title":1002,"description":1003,"heroImage":1004,"authors":1005,"date":1007,"body":1008,"category":741,"tags":1009},"『2025年Gartner® Magic Quadrant™ for AI Code Assistants』でGitLabがリーダーの1社として評価されました","Gartner® Magic Quadrant™の同部門において、GitLabは2年連続でリーダーの1社に選出され、AIコードアシスタント技術における実行能力とビジョンの完全性が評価されました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757675943/q9kb7zfiw1cyxx9fcafp.png",[1006],"Manav Khurana","2025-09-17","『2025年Gartner® Magic Quadrant™ for AI Code Assistants』で、GitLabが再びリーダーの1社として評価されました。この評価は、私たちのAI戦略の重要な柱が認められたと認識させるものと考えています。インテリジェントなコード支援から始まり、チーム全体がソフトウェアを計画・構築・保護・デプロイする方法を変革する包括的なAIへと進化させていく戦略です。\n![『2025 Gartner® Magic Quadrant™ for AI Code Assistants』](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758121248/jfkmhddve6qvlg79xico.png)\n> [『2025 Gartner® Magic Quadrant™ for AI Code Assistants』レポートをダウンロードする](https://about.gitlab.com/ja-jp/gartner-mq-ai-code-assistants/)\n## AI機能からインテリジェントな協働へ\n\n今回のGartnerによる評価では、GitLab Duoの生成AIコード支援機能に重点が置かれたと考えております。GitLab DuoはGitLab DevSecOpsプラットフォームへのAI搭載機能として始まりましたが、現在のGitLab DevSecOpsプラットフォームにネイティブに構築されたエージェント型AIへの発展の基盤を築きました。\n\nGitLab Duo Agent Platformより、デベロッパーはソフトウェアライフサイクル全体にわたってタスクを自動化する複数のAIエージェントと連携できます。エージェントは相互に、そして人間と協力し、GitLabのナレッジグラフを活用してプロジェクト全体の文脈を把握して行動します。これにより、チームは可視性とコントロールを維持しながら、より迅速に作業を進められます。\n\n* **専門エージェント**が、コード生成、セキュリティ分析、調査などのタスクを並行して処理します。\n\n* **ナレッジグラフ**により、エージェントはコード、イシュー、パイプライン、コンプライアンスデータ全体にわたる統合された記録システムに接続されます。\n\n* **人間とエージェントの協働**は、自然言語チャットとカスタマイズ可能なワークフローにより実現され、レビューと監視が組み込まれています。\n\n* **外部ツールやシステムとの相互運用性**は、Model Context Protocol（MCP）とエージェント間フレームワークを通じてサポートされます。\n\nエージェント型AIが人間の指導の下で定型的な作業を処理することで、チームはより迅速に作業を進め、より価値の高いタスクに集中し、プロジェクトの安全性とコンプライアンスを維持できます。\n\n## 設計時からセキュリティを組み込み、実践では柔軟に対応\n\nGitLab Duo Agent Platformは、セキュリティとコンプライアンスを最優先に設計されています。エージェントはGitLabの信頼されるDevSecOps環境内で動作し、すべてのアクションは変更が行われる前に可視化・レビュー可能です。セキュアな統合により認証情報と機密データが安全に処理され、オープンスタンダードを通じた相互運用性により、組織をリスクにさらさずにエージェントを外部ツールに接続できます。\n\nこのプラットフォームを使えば、ガバナンスを損なうことなくAIで生産性を高められるため、チームは安心して導入できます。その仕組みは以下の通りです：\n\n* **デベロッパー**は、複雑で影響力の大きい作業に集中し続けながら、定型的なタスクをエージェント型AIに委ねることで、より迅速な結果だけでなく、既存のワークフローを通じて提供される詳細な文脈を得られます。\n\n* **エンジニアリングリーダー**は、設定された範囲内でエージェント型AIが安全に動作する中で、ライフサイクル全体にわたって作業の進捗を可視性できます。これにより、チームは重要なタスクに注力できるようになり、エージェント型AIが提供するコンテクストに応じたワークフローのガンダンスによって、オンボーディングを簡素化できます。\n\n* **IT組織**は、コーディングとセキュリティポリシーを適用しながら、AIモデルを柔軟に選択し、セキュアな相互運用性を確保するガバナンス機能を活用して、エージェント型AIの活動を制御できます。重要なのは、すべてのプロセスに人間の判断が介在するということです。\n\n## AI機能の新境地を切り開く\n\nGitLabは、Duoから始まったビジョンを継続的に発展させ、新しいエージェント型AI機能、高度なワークフロー、さらなるオーケストレーション機能でGitLab Duo Agent Platformを拡張し続けます。このイノベーションへの取り組みにより、お客様が知り、信頼するプラットフォーム上でチームの生産性を最大化できます。AI機能をDevSecOpsに統合し続ける、GitLabのロードマップの最新情報に今後もご注目ください。\n\n> [『2025 Gartner® Magic Quadrant™ for AI Code Assistants』レポートをダウンロード](https://about.gitlab.com/ja-jp/gartner-mq-ai-code-assistants/)して、[GitLab Duo Agent Platformを今すぐお試しください](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)\n\n*出典: Gartner, Magic Quadrant for AI Code Assistants, Philip Walsh, Haritha Khandabattu, Matt Brasier, Keith Holloway, Arun Batchu, 15 September 2025*\n\n*GARTNERは、Gartner, Inc.および/または米国とその他の国におけるその関連会社の商標およびサービスマークであり、MAGIC QUADRANTは、Gartner, Inc.および/またはその関連会社の登録商標であり、本書では許可を得て使用しています。All rights reserved.*\n\n*この図表は、Gartner, Inc.がリサーチの一部として公開したものであり、文書全体のコンテクストにおいて評価されるべきものです。オリジナルのGartnerドキュメントは、リクエストにより GitLabからご提供することが可能です。*\n\n*Gartnerは、Gartnerリサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティング又はその他の評価を得たベンダーのみを選択するようにテクノロジーユーザーに助言するものではありません。Gartnerリサーチの発行物は、Gartnerリサーチの見解を表したものであり、事実を表現したものではありません。Gartnerは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の責任を負うものではありません。*",[764,741,713],{"featured":91,"template":799,"slug":1011},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants",{"content":1013,"config":1022},{"heroImage":1014,"body":1015,"authors":1016,"updatedDate":1007,"date":1018,"title":1019,"tags":1020,"description":1021,"category":741},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1751568278/bots3gyfarx8qysbkw6c.png","この度、GitLabとAccentureがグローバル販売代理店契約を締結し、AccentureがGitLabの認定販売代理店およびプロフェッショナルサービスプロバイダーとして認定されたことを発表いたします。この契約により、AccentureはAWSマーケットプレースを含む複数の販売チャネルを通じて、GitLabの完全なDevSecOpsプラットフォームをお客様に直接提供することが可能になります。\n\n## 重要な節目\n\n今回の協業は、GitLabの包括的かつインテリジェントなDevSecOpsプラットフォームと、Accentureのデジタルトランスフォーメーションおよび実装サービスにおける豊富な専門知識を組み合わせることで、組織が大規模にセキュアなソフトウェアの構築とデリバリーを実現できるようにします。このグローバル販売代理店契約は、各地域の状況に合わせて容易に適応できるグローバルフレームワークを提供します。\n\n今回の協業では、まず以下の主要領域に注力します。\n\n1. **エンタープライズ規模のDevSecOps変革：** 組織の開発プラクティスのモダナイゼーションとソフトウェアデリバリーライフサイクルの効率化を支援\n2. **メインフレームモダナイゼーション：** レガシーシステムからの移行をサポート\n3. **GitLab Duo with Amazon Q：** エンドツーエンドのセキュリティとコンプライアンスを維持しながらベロシティの向上を求める組織に、AI主導のソフトウェア開発を提供\n\n## 今後の展望\n\n私たちは、両社のお客様がイノベーションを加速し、開発プロセスを効率化し、セキュリティ体制を強化することで、より効果的にビジネス目標を達成できるよう支援していくことを期待しています。\n\nGitLabとAccentureがお客様のビジネスをどのようにご支援できるか、詳しくは[パートナーサイト](https://about.gitlab.com/partners/channel-partners/#/2328213)をご覧いただくか、AccentureまたはGitLabの営業担当にお問い合わせください。",[1017],"GitLab","2025-09-15","GitLabとAccentureがグローバル販売代理店契約を発表",[741,764,713],"Accentureが包括的なDevSecOpsプラットフォームの提供を可能にする販売代理店契約を締結",{"featured":6,"template":799,"slug":1023},"gitlab-and-accenture-announce-global-reseller-agreement",{"content":1025,"config":1034},{"title":1026,"authors":1027,"heroImage":1028,"date":1029,"category":741,"tags":1030,"body":1032,"description":1033},"Monday Merge 9月号：より速いパイプライン、もっと賢いエージェント、そしてより大きな成果を！",[901],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1756904278/ov1n66vq8dnikcjyu0iw.png","2025-09-08",[837,109,944,270,892,713,280,795,741,1031,775,918],"releases","9月の始まりとともに、最新リリース、注目のホワイトペーパー、そして大規模なDevSecOpsの取り組み事例をお届けします👇\n\n## **GitLab 18.3 リリース！Duo AgentsのIDE対応、Embedded Viewsなど多くの新機能が登場**\n\n![GitLab 18.3 リリース](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756955192/hjiu0tadczplc14wsfbc.png)\n\n今回のリリースでは、セキュリティやコンプライアンスの強化から、開発ツール内でのAIアシストまで、プラットフォーム全体に渡る改善を実現しました。\n\n新機能はこちら：\n\n* Visual Studio向け Duo Agent Platform（ベータ）\\\n  開発者はVisual Studio内でGitLab Duo Agent ChatとAgent Flowsを直接利用可能に。IDEを離れることなく、質問、タスク自動化、アーキテクチャ設計、コード生成まで行えます。\n* 埋め込みビュー（一般提供）\\\n  エピック、Wiki、課題を動的でクエリ可能なダッシュボードに変換。GLQLでリアルタイムデータを活用し、チームの足並みを常に揃えられます。\n* CI/CDジョブトークンの細かな権限設定\\\n  最小権限の原則を適用し、ジョブトークンごとのアクセス範囲を正確に制御。\n* 直接転送によるマイグレーション（一般提供）\\\n  GitLabインスタンス間でのプロジェクト移行がよりスムーズで信頼性も向上。\n* Duo Self-Hosted のアップデート\\\n  ハイブリッドモデル選択のサポート、持ち込みモデルの柔軟性、コードレビュー用カスタム指示に対応。\n\nそのほかWeb IDE、コンプライアンス機能、管理者ロール、AWS Secrets ManagerとのCI/CD連携など、多数の改善が追加されています。\n\n💜 今回のリリースには 314件のコミュニティ貢献 が寄せられました！まさに「みんなが参加できる」ということを証明してくれました。\n\n👉 [18.3リリースノート全文はこちら](https://about.gitlab.com/ja-jp/blog/gitlab-18-03-release/)\n\n## **エージェント駆動のCIモダナイゼーション**\n\n**「よりスマートなパイプライン。より速い投資回収。」**\n\n![エージェント駆動のCIモダナイゼーション](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756955192/g0ayfgu2zudqn53so11z.png)\n\n企業がCI/CDパイプラインを最新化しようとする時、現実には「時間がかかる」「コストが高い」「スケールが難しい」といった課題が立ちはだかります。\n\nそこでGitLabの新ホワイトペーパーが提案するのが Agentic CI Modernization。GitLab Duo Agent Platformを活用することで、ラボテストでは以下の成果が示されています：\n\n⏱️ パイプライン変換が 81%高速化（240分 → 45分）\n💸 コンサル費用が 83%削減\n📉 モダナイゼーション期間が 2.5年 → 9か月に短縮\n\n従来のやり方はツール乱立やコンテキスト切り替え、コンサル依存の進め方で停滞しがちですが、エージェント型AIが状況を変えます。\n\nGitLab Duo Agentsはレガシーパイプラインを解析し、アーキテクチャや依存関係を理解したうえでGitLab CI設定を自動生成。これによりエラーを最大70%削減し、価値提供までのスピードを大幅に加速します。\n\nこのホワイトペーパーで語られる内容は単なる時間短縮の話ではありません。目指しているのは、プラットフォームエンジニアリングを大規模に実現し、開発者が共通のCI/CDコンポーネントをサービスとして利用できる環境をつくることです。\n\n👉 [ホワイトペーパーはこちらから](https://about.gitlab.com/the-source/ai/cicd-modernization-break-down-barriers-with-agentic-ai/)\n\n## **カスタマースポットライト：Deutsche Telekom**\n\n![カスタマースポットライト：Deutsche Telekom](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756955192/jp9ywqbc5k4i3jt66koc.png)\n\n18か月のリリースサイクルが、わずか3か月へ。分断されたツール群から、13,000人以上が使う統合されたGitLabプラットフォームへ。手作業のセキュリティチェックから、GitLab Ultimateによる完全統合スキャンへ。\n\n2億4,000万人以上のモバイル顧客を抱える通信大手Deutsche Telekom社。いまや単なるネットワークプロバイダーにとどまらず、DevSecOpsの先駆者へと変貌を遂げています。\n\nGitLabに集約したことで、同社IT部門はCI/CDの全社展開に成功し、“インナーソース”文化を育成。いまやアジャイルプログラムの75%がGitLabに依存しています。\n\n「セキュリティが1つのアプリに統合されていれば、すぐに問題箇所へ飛んで修正できます（中略）これによりセキュリティ対応の効率が大幅に向上しました。」\n\n— Thorsten Bastian, Business Owner IT, CI/CD Hub, Telekom IT\n\n👉 [ストーリー全文はこちら](https://about.gitlab.com/customers/deutsche-telekom/)\n\n## **ドキュメントが新しく生まれ変わりました**\n\n![ドキュメントが新しく生まれ変わりました](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756955192/osfy2yhgsrfj5tgmrydu.png)\n\n**新しい [docs.gitlab.com](http://docs.gitlab.com) にようこそ！**\nゼロから再構築し、わかりやすさ、スピード、使いやすさが大幅アップしました。\n\n新しくなったポイント：\n\n* どのデバイスでも快適に使える、モダンなインターフェース\n* 必要な情報にすぐたどり着けるスマート検索\n* より直感的なナビゲーションとアクセシビリティ向上\n\n[経験豊富なDevSecOpsプロから、これから始める方まで。新しいドキュメントはあなたの強い味方 →](https://docs.gitlab.com/)\n\n## **今月のイベントで会いましょう**\n\n![今月のイベントで会いましょう](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756955192/rmjcneaitcox1n2xiq1b.png)\n\n今月はサンパウロからシンガポールまで、GitLabが世界各地へ！ぜひブースに立ち寄って、ノベルティをゲットし、DevSecOpsの最新情報を語り合いましょう。\n\n🇧🇷 Google Cloud Summit Brazil 👉 [[登録はこちら](https://cloudonair.withgoogle.com/events/google-cloud-summit-brasil-2025)]\n🇸🇬 EPIC Conference Singapore 👉 [[登録はこちら](https://events.gitlab.com/e/event-epic-conference-singapore)]\n🇨🇭 Google Cloud Summit Switzerland 👉 [[登録はこちら](https://cloudonair.withgoogle.com/events/google-cloud-summit-switzerland-2025)]\n\nGitLab Duoを実際に体験し、新しいアイデアやインスピレーション、次の大きなデプロイ成功のヒントを持ち帰りませんか？\n\n## **今月のおすすめ記事**\n\n![今月のおすすめ記事](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756955489/ipkozh9ai6wbmhxmv3gn.png)\n\nエージェント型AIのブレークスルーから、大規模なソフトウェアのセキュリティ対策まで、今月の注目記事をご紹介します。\n\n* [](https://www.scworld.com/podcast-segment/14186-softwares-agentic-future-is-coming-how-cisos-can-prepare-today-josh-lemos-bh25-1)\u003Chttps://www.devopsdigest.com/gitlab-signs-strategic-collaboration-agreement-with-aws-to-deliver-secure-devsecops-to-gitlab>\n* [](https://thenewstack.io/how-intuitive-machines-used-devsecops-to-reach-the-moon/)\u003Chttps://thenewstack.io/how-intuitive-machines-used-devsecops-to-reach-the-moon/>\n* [](https://techvoices.com/video-podcasts/gitlabs-emilio-salvador-on-how-ai-agents-are-reshaping-software-development/)\u003Chttps://techvoices.com/video-podcasts/gitlabs-emilio-salvador-on-how-ai-agents-are-reshaping-software-development/>\n* [](https://techvoices.com/video-podcasts/gitlabs-emilio-salvador-on-how-ai-agents-are-reshaping-software-development/)\u003Chttps://techvoices.com/video-podcasts/gitlabs-emilio-salvador-on-how-ai-agents-are-reshaping-software-development/>\n* [](https://leaddev.com/technical-direction/are-you-ready-for-ai-agents)\u003Chttps://leaddev.com/technical-direction/are-you-ready-for-ai-agents>\n* [](https://leaddev.com/technical-direction/are-you-ready-for-ai-agents)\u003Chttps://leaddev.com/technical-direction/are-you-ready-for-ai-agents>\n* [](https://www.scworld.com/podcast-segment/14186-softwares-agentic-future-is-coming-how-cisos-can-prepare-today-josh-lemos-bh25-1)\u003Chttps://www.scworld.com/podcast-segment/14186-softwares-agentic-future-is-coming-how-cisos-can-prepare-today-josh-lemos-bh25-1>\n* [](https://www.devopsdigest.com/from-ai-risk-to-business-resilience-prompt-engineering-as-strategic-security-capability)\u003Chttps://www.devopsdigest.com/from-ai-risk-to-business-resilience-prompt-engineering-as-strategic-security-capability>\n* [](https://www.devopsdigest.com/from-ai-risk-to-business-resilience-prompt-engineering-as-strategic-security-capability)\u003Chttps://www.devopsdigest.com/from-ai-risk-to-business-resilience-prompt-engineering-as-strategic-security-capability>\n* [](https://www.scworld.com/podcast-segment/14186-softwares-agentic-future-is-coming-how-cisos-can-prepare-today-josh-lemos-bh25-1)\u003Chttps://www.scworld.com/podcast-segment/14186-softwares-agentic-future-is-coming-how-cisos-can-prepare-today-josh-lemos-bh25-1>\n\nそしてまだの方は、ぜひAIがソフトウェアイノベーションに与える影響に関するC-suiteレポート もチェックしてみてください。\n\n* [](https://about.gitlab.com/software-innovation-report/)\u003Chttps://about.gitlab.com/software-innovation-report/> \\\n  （日本に特化したレポートは近日中に公開予定）\n\n## **最後に、今月の名言を**\n\nパイプラインの最新化、ツール統合、エージェント型AIの導入。大きな変革はときにハードルが高く見えますが、すべては小さな一歩から始まります。\n\n> 「それが成し遂げられるまでは、いつも不可能に見えるものだ。」\n>  — ネルソン・マンデラ\n\n難しいパイプラインに直面したら、「不可能」とは「まだ実現していないだけ」と思い出してください。\n\n### **次回まで**\n\n今月も読んでいただきありがとうございました！感想やフィードバックはぜひXでのメンションやコメントでシェアしてください。お待ちしています。\n\nそれではまた来月、お会いしましょう！Happy Merging！\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/)｜Developer Advocate, GitLab\n\n🧡 このニュースレターが気に入った方は、ぜひチームにもシェアしてください。\n 👉 [The Developer Show](https://www.linkedin.com/feed/update/urn:li:activity:7340777670714019840)の購読もお忘れなく！\n\n![Fatima Sarah Khalid](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/is5jitqrtujnkmmkijlg.png)","9月号のMonday Mergeでは、最新リリース、注目のホワイトペーパー、そして大規模なDevSecOpsの取り組み事例をお届け。",{"featured":6,"template":799,"slug":1035},"monday-merge-2025-september-8",{"category":749,"slug":753,"posts":1037},[1038,1050,1061],{"content":1039,"config":1048},{"date":1040,"heroImage":1041,"title":1042,"authors":1043,"category":753,"body":1044,"description":1045,"tags":1046},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[967],"## 目次\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コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[944,1047,796,809],"git",{"featured":91,"template":799,"slug":1049},"git-merge-command-overview",{"content":1051,"config":1059},{"title":1052,"description":1053,"authors":1054,"heroImage":1055,"date":1056,"body":1057,"category":753,"tags":1058},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[967],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg","2025-07-17","## オープンソースとは？\n\nオープンソースとは、ソフトウェアのコードが公開され、誰もが利用、改良、再配布できるという仕組みのことを指します。「オープンソースソフトウェア」と同義で使用されることが多いです。\n\n## オープンソースソフトウェア（OSS）とは？\n\nオープンソースソフトウェアはOSSとも記述され、Open Source Softwareの略称です。一般的な商用ソフトウェアとは異なり、誰でも利用、改良、再配布ができるようソースコードが公開されています。これにより個人や企業のデベロッパーは、各々の環境に合わせてソフトウェアを自由に改変し、特定の用途や問題に最適化することが容易にできます。ただし、OSSによってはライセンス制約が存在する場合もあります。\n\nフリー（無料）ソフトと混同されることがありますが、フリーソフトのほとんどはソースコードが非公開です。よって、ソースコードが公開されているかどうかで、OSSかの判断をするのが一般的です。\n\n## オープンソースソフトウェアの基本原則\n\nオープンソフトウェアに明確な定義はありませんが、「ソースコードが公開されていること」以外にも広く認知されている要件があります。これら要件は、米国のOpen Source Initiative（OSI）という団体が提唱した以下10項目を指すのが一般的です。\n\n* 再配布の自由\n* ソースコードの配布\n* 派生ソフトウェアの配布許可\n* 作成者のオリジナルコードの完全性\n* 個人やグループに対する差別禁止\n* 使用分野に対する差別禁止\n* ライセンスの配布\n* 特定製品でのみ有効なライセンスの禁止\n* 他ソフトウェアを制限するライセンスの禁止\n* ライセンスの技術的中立\n\n要約するとOSSの基本原則は、ユーザーやデベロッパーに自由を提供し、協力的な環境を促進することと言えます。ただし、「自由」ではあるものの、ライセンスによって一定のルールは設定されています。例えば、GPLやMITライセンスは、OSSに付随するライセンスの利用や再配布、改変の範囲を規定し、自由利用を促進しつつも、デベロッパーやユーザーの権利を保護しています。OSS利用の際は、こういったライセンスルールを理解し、遵守することを忘れないようにしましょう。ライセンスについては後ほど詳しく解説します。\n\n## オープンソースソフトウェアの具体例\n\nどういったソフトウェアがOSSなのかと問われると、すぐには思いつかないかもしれません。実際に、どういったソフトが様々な分野で活躍しているのかいくつかご紹介しましょう。\n\n### WordPress\n\nWordPressという名前は、誰もが一度は聞いたことがあるでしょう。WordPressはウェブサイトを簡単に作成できるコンテンツ管理システム（CMS）で、世界中でもっとも利用されているCMSとなっています。ウェブサイトデベロッパーは自由にカスタマイズを行うことができ、また、活発なコミュニティで互いをサポートし合うことにより、新たな拡張機能の開発等に貢献しています。\n\n### GIMP\n\nGIMPは、イラストレーター、グラフィックデザイナー、フォトグラファー、サイエンティストなど画像を扱う専門家に人気の画像編集ソフトウェアです。ユーザーは無料でダウンロードして利用でき、WordPressと同じく活発なコミュニティが、日々のバグ修正や、新プラグインを開発をサポートしています。\n\n### Brave Browser\n\nBraveは、ユーザーのプライバシー保護を主眼としたウェブブラウザであり、広告やトラッキングを防止してくれます。さらに、独自の暗号通貨（BAT）や検索システムを開発しているなどの理由で、デベロッパー間では人気のブラウザの一つです。Braveもオープンソースであるため、個人が自由にブラウザ機能をカスタマイズしたり、新たに機能を追加したりすることができる仕様となっています。\n\n### GitLabのオープンソースプロジェクト\n\n[GitLabプラットフォーム](https://about.gitlab.com/ja-jp/)を利用して開発されているオープンソースプロジェクトをいくつかご紹介します。\n\n#### Drupal\n\nDrupalはWordPressと同様に、オープンソースのコンテンツ管理システム（CMS）です。堅牢性と拡張性の高さが評価されており、NASAや経済産業省といった政府機関や、Teslaなどの企業に採用されています。\n\n#### VLC\n\nWindowsやMacにとどまらず、LinuxやiOS等でも使うことできる、メディアプレイヤーです。多様な種類の音声や動画ファイルを再生でき、様々なファイル形式に対応しています。広告等、ユーザーにとって不要な機能が一切搭載されておらず、世界中で広く利用されています。\n\n#### LibreOffice\n\nMicrosoft Officeとよく比較されることがあるのが、LibreOfficeです。無料で利用することができ、様々なオフィスツールを提供することから、たくさんの企業や個人に使用されています。\n\n## オープンソース開発のメリットとデメリット\n\nOSSの開発には様々なメリットとデメリットがあります。開発手法についての議論は付きませんが、ここでは言及されることが多いポイントをいくつか挙げてみます。\n\n### メリット\n\n#### コミュニティによる自発的なサポートと開発\n\nオープンソース開発は通常、世界中のデベロッパーが参加した活発なコミュニティを形成しています。多種多様なバックグランドを持つ個々のユーザーたちがお互いにアイデアやフィードバック、サポートし合うことを基本とし、継続的な開発とサポートをしてくれます。\n\n#### 高い透明性に担保された信頼とセキュリティ\n\nOSSの信頼とセキュリティは、誰もがソースコードを参照できることで実現されています。\n\nまず、たくさんのデベロッパーの目に触れるため、脆弱性やバグが比較的早い段階で発見されます。これにより、セキュリティを高レベルに引き上げることができます。そして、ソースコードが公開されているため、不正な動作やバックドアの存在といったリスクを排除しやすく、ソフトウェアの信頼性を高めてくれます。\n\n#### 開発にかかる時間と費用の削減\n\nオープンソースソフトウェアは大抵が無料で、自由にソースコードを改変できます。よって、ライセンス料とスクラッチ開発が不要であり、個人や企業の費用と開発時間を大幅に削減してくれます。\n\n### デメリット\n\n#### 開発プロジェクトの継続性\n\nオープンソース開発は、有志が中心となって行われる場合が多いため、プロジェクトが遅延したり、突然中止となったりするリスクがあります。また、安定した開発スケジュールが維持されないこともあります。\n\nプロジェクトの多くは無償、スポンサー、寄付で成り立っていることが一般的なので、開発コアメンバーが抜けた、資金が枯渇してしまった、などの理由から開発自体が立ち行かなくなることもあります。\n\n#### 責任の所在が曖昧\n\nコミュニティ主導で開発が進められる場合、ユーザーにバグや他ソフトと統合できないといった問題が発生しても商用ソフトウェアとは異なり、自己解決しなくてはならないケースが通常です。迅速かつ的確なサポートが受けづらいケースも、発生することがあります。\n\n#### ライセンスの準拠で\n\n当然ながら、OSSにもライセンスが存在します。無条件に利用や再配布ができるわけではないので、しっかりとライセンスを理解した上で使用しなければいけません。ライセンス規約に違反してしまい、過去には訴訟に発展したケースもあるため、注意が必要です。詳しくは後ほど解説します。\n\n### オープンソースの課題とGitLabのアプローチ\n\nGitLabというプラットフォームが、OSSにおける課題に対してどう取り組んでいるかについて、いくつかご紹介しましょう。詳細を知りたい場合は、[オープンソースプロジェクト向けのGitLabソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を読んでみてください。\n\n#### 脆弱性の早期発見と修正\n\nオープンソースは、コードが公開されているため、悪意のある人物が脆弱性を発見してしまうリスクがあります。\n\n[DevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/topics/devsecops/)であるGitLabは、開発プロセス全体においてセキュリティを重要視しています。静的アプリケーションセキュリティテスト（SAST）や依存関係スキャンといった強力なツールが、早期の脆弱性発見と修正を実現する仕組みを実現します。\n\n#### サポートの補完\n\nOSSはコミュニティによるサポートが中心となり、的確なサポートや迅速な対応を受けられないケースが発生することがあります。\n\n[商用版GitLab](https://about.gitlab.com/ja-jp/pricing/)には、「GitLab Premium」「GitLab Ultimate」があり、公式サポートという選択肢が用意されています。また、コミュニティの結束を高める働きかけをすることで自発的サポートも促進しています。\n\n#### コミュニティの活性化\n\n活発なコミュニティなしに、OSSを成功させることはできませんが、これを維持するのは容易ではありません。\n\nGitLabは、[GitLabフォーラム](https://forum.gitlab.com/c/community/gitlab-for-open-source/49)を運営したり、[オープンソース団体向けプログラム](https://about.gitlab.com/ja-jp/solutions/open-source/join/)を実施、GitLabハッカソンやオンラインイベントを開催したりすることで、デベロッパー同士の繋がりを促進、コミュニティの活性化と拡大に貢献しています。\n\n## オープンソースのライセンスとその重要性\n\nオープンソースのライセンスは、ソフトウェアの利用、配布、変更等に関する権利と制限を明記したものであり、法的拘束力を持ちます。よって、ソフト利用者はこれをしっかりと理解した上で、トラブル回避をすることが望ましいといえます。\n\nまた、ソフトウェアデベロッパーがどのライセンス規約にするかを考える場合には、透明性を重視するのか、自由度を重視するのかなどにより選択するライセンスが異なってきます。ここでは、いくつか代表的なものをご紹介しましょう。\n\n以下に表としてまとめてみました。\n\n![オープンソース　ライセンスのタイプと代表例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720035/v9ld6h78ilk22x30nged.jpg)\n\n### コピーレフト\n\nコピーレフトライセンスは、元となるソフトウェアを再配布する時には、派生物も元OSSと同じ条件下で行う必要があるというものです。このタイプのライセンスは、非常に伝播性が強いのが特徴です。\n\nまたコピーレフトという言葉は、「コピーライト」をもじったものから誕生しました。\n\n### 準コピーレフト\n\nコピーレフトと比べ、伝播性が多少弱いのが準コピーレフトです。元のOSSのソースコードを再利用した時に、元のライセンスと同条件で再配布する必要があります。\n\n### 非コピーレフト\n\nパーミッシブライセンスとも呼ばれます。名前の通りですが、元のOSSと同条件のライセンスにする必要がありません。ソースコードの公開義務がないため、商用利用されることが多いです。\n\n## よくある質問\n\n### オープンソースソフトウェア（OSS）とは何ですか？\n\nOSSとは、ソースコードが公開され、誰でも自由に利用、修正、配布できるソフトウェアのことです。\n\n### OSSのセキュリティは安心ですか？\n\nOSSライセンスは、ソフトウェアの利用や再配布に関する自由と制約を明確に定義したものです。\n\n### OSSのライセンスにはどんな種類がありますか？\n\nライセンスにはGPL、MIT、Apache Licenseなど、異なる自由度や利用条件を持つものがあり、コピーレフト、準コピーレフト、非コピーレフトの３つに大別されます。\n\n### なぜ企業がOSSを採用するのですか？\n\nコスト削減、柔軟性、信頼性向上、技術コミュニティとの連携が理由となる場合が多いです。またGitLabでは、[オープンソースプロジェクト向けのソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を提供しています。ぜひご確認ください。\n\n*監修：佐々木 直晴* [@naosasaki](https://gitlab.com/naosasaki)*（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[944,270,861,775],{"featured":91,"template":799,"slug":1060},"what-is-open-source",{"content":1062,"config":1071},{"title":1063,"description":1064,"authors":1065,"heroImage":1067,"body":1068,"date":1069,"category":753,"tags":1070},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",[1066],"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",[1047,861,270],{"featured":91,"template":799,"slug":1072},"what-s-new-in-git-2-50-0",{"category":90,"slug":764,"posts":1074},[1075,1086,1098],{"content":1076,"config":1084},{"heroImage":1077,"body":1078,"authors":1079,"updatedDate":965,"date":1080,"title":1081,"tags":1082,"description":1083,"category":764},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758160154/ckr9nufkx3n2t0rp0iwd.png","本ブログは、[GitLab 18.4 Release](https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n## **GitLab Duo Model Selection（モデル選択）とGitLab Knowledge Graph（ナレッジグラフ）を搭載したGitLab 18.4をリリース**\n\nこのたび、GitLab 18.4のリリースを発表しました。このリリースでは、GitLab Duo Model Selectionの一般提供、GitLab Knowledge Graph、GitLab Duoでのエンドユーザーモデル選択機能の提供開始、さらにCI/CDジョブトークンによるGitプッシュリクエストの認証機能など、さまざまな機能が追加されました。\n\nこれらの機能は、今回のリリースに含まれる19項目の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 18.4には、GitLabコミュニティのユーザーから136件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ ](https://www.claudeusercontent.com/?errorReportingMode=parent#)をご覧ください。\n\n## **Q&A + コード: GitLab 18.4の詳細とコントリビューターコミュニティの発展**\n\n次回のGitLab Developer Showでは、GitLab 18.4の最新機能を詳しく解説し、活発なコントリビューターコミュニティの育成についてお話しします。ご質問やライブコードの実演をご覧いただきながら、GitLabとともに成長する方法を具体的にご紹介します。\n\n👉 [こちらから登録](https://www.linkedin.com/events/7373772262312906753/)\n\n**GitLab 18.4では、GitLab Duo Model SelectionとGitLab Duo Agent Platform（GitLab Duo Self-Hosted）が追加されました**\n\n[クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+18.4+released+with+GitLab+Duo+Model+Selection+and+GitLab+Knowledge+Graph&url=https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/&hashtags=)\n\n![notable-contributor-logo](https://about.gitlab.com/images/notable-contributor-logo.svg)\n\n## 今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は[Patrick Rice](https://gitlab.com/PatrickRice)さんです\n\nPatrick Riceさんは、コントリビューター、メンテナー、メンターとして、GitLabオープンソースコミュニティへの卓越したコントリビュートを継続されています。過去1年間でトップ5のコントリビューターとなったPatrickさんは、[GitLab Terraform Provider](https://gitlab.com/gitlab-org/terraform-provider-gitlab)および[Client-go](http://client-go)プロジェクトのメンテナンスを担当し、機能追加、リリース管理、イシューのトリアージ、コミュニティのオンボーディングに取り組まれています。コントリビューターからプロジェクトメンテナーへと成長を遂げられ、「誰もがコントリビュートできる」というGitLabのミッションを体現しています。\n\nPatrickさんの活動はコードのコントリビュートにとどまらず、コミュニティ構築とコーチングにまで及び、新しいコントリビューターの参加と成長をサポートしています。以前には、[17.11の注目コントリビューター賞](https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/#notable-contributor)を受賞したHeidi Berry氏をノミネート、支援しました。また、[GitLab for Education](https://about.gitlab.com/solutions/education/)チームと知見を共有し、学生にGitLabを学習してもらうことで次世代のデベロッパー育成にもコントリビュートしています。\n\n「Terraform ProviderとClient-goプロジェクトでの協力に、新しいコントリビューターの方々にぜひ参加してもらいたいと思います。私たちのコミュニティには、もっと多くの仲間が必要です。」とPatrickさんは言います。\n\nPatrickさんを今回の賞にノミネートした[Lee Tickett](https://gitlab.com/leetickett-gitlab)（GitLab Staff Fullstack Engineer）はPatricさんついて「PatrickさんはGitLabチームとお客様を継続的に支援し続けています。」と述べています。[Timo Furrer](https://gitlab.com/timofurrer)（GitLab Senior Backend Engineer）もノミネートを支援し、「Terraform ProviderとClient-goへの日々のコントリビュートに加え、GitLab Terraform Providerの可能性を実演することで、IaCジャーニーにおけるGitLabのお客様を直接支援しています」と付け加えました。\n\nPatrickさんはKinglandのエンタープライズアーキテクトで、[GitLab Community Core Team](https://about.gitlab.com/community/core-team/)のメンバーでもあります。今回が2回目の注目コントリビューター賞受賞で、[初回は2023年1月のGitLab 15.8](https://about.gitlab.com/releases/2023/01/22/gitlab-15-8-released/#mvp)でした。\n\n継続的なコントリビュートとGitLabのお客様へのサポート、そしてオープンソースコミュニティの成長へのご尽力に対し、Patrickさんに深く感謝いたします！\n\n## **GitLab 18.4でリリースされた主な改善点**\n\n### **GitLab Duo Model Selection（モデル選択）一般提供開始**\n\n> GitLab.com: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise\\\n> GitLab Dedicated: Ultimate、Duo Core、Duo Pro、Duo Enterprise\n\nGitLab Duo Model Selectionの一般提供を開始しました。開発ワークフローで使用するAIモデルの選択を組織がより細かく管理できるようになります。\n\nGitLab.comのトップレベルグループオーナー、Self-ManagedおよびDedicatedの管理者は、GitLabホスト型AIゲートウェイ経由でアクセスするGitLab Duo機能において、複数のGitLab AIモデルベンダーの中から特定のモデルを選択できるようになりました。\n\nGitLab.com上の複数ネームスペースに参加しているGitLabユーザーは、すべての開発コンテキストでAIモデル設定を統一するため、デフォルトのネームスペースの設定も可能です。GitLab Duo Model Selectionの詳細については、[ブログ記事](https://about.gitlab.com/blog/speed-meets-governance-model-selection-comes-to-gitlab-duo/)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/model_selection/#select-an-llm-for-a-feature)\\\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/18818)\n\n![model_selection_gtm](https://about.gitlab.com/images/18_4/model_selection_gtm.png)\n\n### **GitLab Knowledge Graph（ナレッジグラフ）**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nGitLab Knowledge Graphは、コードベース全体における豊富なコードインテリジェンス機能を提供します。デベロッパーはより多くのコンテキストを基にプロジェクトを理解、操作できるようになり、変更の計画立案、影響分析、GitLab Duoエージェントと連携した開発タスクの効率化が図れます。\n\nGitLab Duo Agent Platformでは、Knowledge Graphを活用してAIエージェントの精度を向上させます。コードベース全体のファイルと定義をマッピングすることで、Knowledge GraphはDuoエージェントがローカルワークスペース全体の構造を理解するための拡張コンテキストを提供し、複雑な質問に対してより迅速で正確な回答を返します。\n\nこの機能はベータ版です。[イシュー160](https://gitlab.com/gitlab-org/rust/knowledge-graph/-/issues/160)でフィードバックをお寄せください。\n\n[ドキュメント](https://gitlab-org.gitlab.io/rust/knowledge-graph/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17514)\n\n![KnowledgeGraph](https://about.gitlab.com/images/18_4/KnowledgeGraph.png)\n\n### **GitLab Duoでエンドユーザーによるモデル選択が可能に**\n\n> GitLab.com: Premium、Ultimate、Duo Core、Duo Pro、Duo Enterprise\n\nGitLab Duoでエンドユーザーがモデルを選択できる機能が、GitLab.comでパブリックベータ版として提供開始されました。ユーザーはGitLab UIから直接GitLab Duo Agentic Chatで使用したいモデルを選択できるようになり、ニーズに合わせたAIサポートを受けられます。\n\nGitLab.comのネームスペースオーナーが許可している場合、エンドユーザーはGitLab Duo Agentic Chatで利用できるGitLab AIベンダーのモデルから選択できます。ネームスペースオーナーは、これまで通りネームスペース設定で組織全体のモデルを指定することも、エンドユーザーによるモデル選択を許可することもできます。\n\n利用を開始するには、GitLab Duo Agentic Chatでモデルのドロップダウンメニューから、希望するモデルを選択してください。なお、モデルを変更すると新しい会話が開始され、選択した設定は今後のセッションでも保存されます。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/model_selection/#select-a-model-to-use-in-gitlab-duo-agentic-chat)\\\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/19251)\n\n![end_user_model_selection](https://about.gitlab.com/images/18_4/end_user_model_selection.png)\n\n### **CI/CDジョブトークンによるGitプッシュリクエストの認証**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nプロジェクトで生成されるCI/CDジョブトークンを使用して、プロジェクトリポジトリへのGitプッシュリクエストの認証が行えるようになりました。UIの「ジョブトークンの権限」設定、またはプロジェクトのREST APIエンドポイントの[`ci_push_repository_for_job_token_allowed`](https://docs.gitlab.com/api/projects/#edit-a-project)パラメータで有効化できます。\n\n[ドキュメント](https://docs.gitlab.com/ci/jobs/ci_job_token/#allow-git-push-requests-to-your-project-repository)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/389060)\n\n![job_token_push](https://about.gitlab.com/images/18_4/job_token_push.png)\n\n### **GitLab Duoのコンテキスト除外機能**\n\n> GitLab.com: Premium、Ultimate、Duo Pro、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\\\n> GitLab Dedicated: Ultimate、Duo Pro、Duo Enterprise\n\nGitLab Duoのコンテキスト除外機能を使うことで、GitLab Duoが参照するコンテキストから除外したいものを指定できます。パスワードファイルや設定ファイルなどの機密情報を保護したい場合に便利です。特定のファイル、ディレクトリ、ファイル形式、またはこれらを組み合わせた除外設定が可能です。\n\nこの機能は現在ベータ版です。[イシュー566244](https://gitlab.com/gitlab-org/gitlab/-/issues/566244)でGitLab Duoのコンテキスト除外機能についてフィードバックをお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/context/#exclude-context-from-gitlab-duo)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17124)\n\n![duo-context-exclusion](https://about.gitlab.com/images/18_4/duo-context-exclusion.png)\n\n### **GitLab DedicatedのAWSリージョンサポート拡大**\n\n> GitLab Dedicated: Ultimate\n\nGitLab DedicatedがすべてのAWSリージョンでのデプロイに対応し、プライマリ、セカンダリ、バックアップのデプロイ先として、[より多くのリージョン](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/#available-aws-regions)から選択できるようになりました。\n\nこの対応拡大は、GitLab Dedicatedの高可用性とディザスターリカバリー基準を満たすio2ディスクがAWSの全リージョンで利用可能になったことで実現しました。\n\n新しく対応したリージョンは、スイッチボードでGitLab Dedicatedインスタンスをプロビジョニングする際に選択できます。\n\n[ドキュメント](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/#available-aws-regions)\\\n[イシュー](https://about.gitlab.com/direction/gitlab_dedicated/#theme-global-availability)\n\n![switchboard-expanded-aws-regions](https://about.gitlab.com/images/18_4/switchboard-expanded-aws-regions.png)\n\n### **異なるブランチに対するCI/CDパイプラインシミュレーション**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nこれまで、パイプラインエディターの「検証」タブで変更内容を検証する際、デフォルトブランチでのシミュレーション実行のみに限定されていました。このリリースで機能を拡張し、任意のブランチを指定してパイプラインシミュレーションを実行できるようになりました。この改善により、パイプラインのテストと検証における柔軟性が大幅に向上し、安定ブランチや機能ブランチなど、さまざまなケースでパイプラインが想定通りに動作するかを確認できます。\n\n[ドキュメント](https://docs.gitlab.com/ci/pipeline_editor/#validate-cicd-configuration)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/482676)\n\n![branch_selector](https://about.gitlab.com/images/18_4/branch_selector.png)\n\n## GitLab 18.4リリースに含まれるその他の改善点\n\n### **イシューページの表示方法を設定する**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\n一覧ページの表示を自由にカスタマイズできるようになりました。必要なメタデータを選択し、作業項目をドロワーで開くか、フルページで開くかを選択できるため、重要な情報により集中できます。\n\nこれまでは、すべてのメタデータフィールドが常に表示されており、作業項目を確認する際に情報が多すぎると感じることがありました。今回のアップデートで、担当者、ラベル、日付、マイルストーンなどの各項目の表示・非表示を切り替えて、見やすいようにカスタマイズできるようになりました。\n\n新しい表示切替機能により、一覧のコンテキストを保ったままドロワーで詳細を素早く確認したり、詳細な編集や包括的なナビゲーションが必要な場合はフルページ表示に切り替えたりすることが可能です。\n\n[ドキュメント](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/570776)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/570776)\n\n![configure_how_to_view_issues_from_the_listing_page](https://about.gitlab.com/images/18_4/configure_how_to_view_issues_from_the_listing_page.png)\n\n\n\n### **イシューボードでエピック階層の完全表示が可能になりました**\n\n> GitLab.com: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nイシューボードにおいて、親エピックでフィルタリングした際に、子エピック内のすべてのイシューを表示できるようになりました。これにより、イシューページと同様の動作に統一され、子エピックにネストされたイシューを見落とすことなく、エピック階層全体の追跡と可視化が可能になります。プロジェクト管理ワークフローの効率性と信頼性が向上します。\n\n[ドキュメント](https://docs.gitlab.com/user/project/issue_board/#filter-issues)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/358416)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/358416)\n\n![issue_boards_complete_hierarchies](https://about.gitlab.com/images/18_4/issue_boards_complete_hierarchies.png)\n\n\n\n### **エンタープライズユーザーのプレースホルダー再割り当て時の確認がスキップ可能に**\n\n> GitLab.com: Premium、Ultimate\n\nグループのオーナーロールを持つユーザーは、そのグループ内のアクティブなエンタープライズユーザーにプレースホルダーを再割り当てする際、ユーザー確認をスキップできるようになりました。これにより、エンタープライズユーザーが再割り当て確認のために頻繁にメールを確認する必要がなくなります。設定された時間制限に達すると、それ以降のすべての新しい再割り当てに対して再びメール確認リクエストが送信されます。\n\nエンタープライズユーザーには再割り当て完了後に通知メールが送られるため、プロセス全体の透明性は維持されます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/import/#bypass-confirmation-when-reassigning-placeholder-users)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17871)\n\n### **CI/CDテンプレートを使用したOpenTofuモジュール・プロバイダーのGitLabコンテナレジストリへの公開**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nGitLabコンテナレジストリが、OpenTofuモジュールとプロバイダーをホストするためのメディアタイプに対応するようになりました。\n\n[OpenTofu CI/CDコンポーネント](https://gitlab.com/components/opentofu)のバージョン[3.1.0](https://gitlab.com/components/opentofu/-/releases/3.1.0)では、OCIフォーマットを使用してOpenTofuプロバイダーをGitLabレジストリにデプロイする新しい`provider-release`テンプレートが追加されました。これにより、プライベートOpenTofuプロバイダーをGitLabで直接ホストできるようになります。\n\nさらに、`module-release`テンプレートには新しい`type`入力が追加されました。`oci`に設定すると、OCIフォーマットを使用してOpenTofuモジュールをGitLabレジストリにデプロイできます。\n\n[ドキュメント](https://gitlab.com/components/opentofu#publish-providers-to-the-gitlab-oci-registry)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/562715)\n\n### **パイプラインのシークレット検出で特定ファイル・ディレクトリをデフォルトで除外**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\\\n\nパイプラインのシークレット検出で、シークレット情報を含む可能性の低い[特定のファイルタイプやディレクトリが](https://docs.gitlab.com/user/application_security/secret_detection/pipeline/#excluded-items)自動的にスキャン対象から除外されるようになりました。これにより、スキャンパフォーマンスが向上します。この機能はアナライザーの[バージョン7.11.0](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/releases/v7.11.0)でリリースされます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/secret_detection/pipeline/#excluded-items)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/560147)\n\n### **高度なSASTスキャンが大幅に高速化**\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\n\nマージリクエストやパイプラインでセキュリティスキャンを実行する際、スキャン時間の短縮は非常に重要です。GitLabは、高度なSASTのエンジンと検出ルールの両方に対し、継続的にパフォーマンスの改善に取り組んでいます。\n\n今回のリリースした改善により、ベンチマークテストと実際の環境でのテストにおいて、スキャン実行時間を最大78%短縮することができました。スキャン処理の中でもパフォーマンスが重要な部分にキャッシュ機能を追加したことで、大規模なリポジトリでのスキャンが大幅に高速化されます。\n\nこの改善は、高度なSASTアナライザーのバージョン2.9.6以降で自動的に有効になります。使用しているアナライザーのバージョンは、[スキャンジョブのログで確認](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#identify-the-gitlab-advanced-sast-analyzer-version)できます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16561)\n\n### **ジョブアーティファクトダウンロード権限をより細かく制御**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nGitLab 16.11では、`artifacts:access`キーワードが追加され、アーティファクトのダウンロード権限を以下のように設定できるようになりました：。\n\n* パイプラインにアクセスできるすべてのユーザー\n* デベロッパーロール以上のユーザーのみ\n* 誰でもダウンロード不可\n\n今回のリリースでは、新たに「メンテナーロール以上のユーザーのみ」という設定も追加され、ジョブアーティファクトのダウンロードをより細かく制御できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ci/yaml/#artifactsaccess)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/454398)\n\n### **グループ、アプリケーション単位での自動Duoコードレビュー**\n\n> GitLab.com: Premium、Ultimate、Duo Enterprise\n\nグループまたはアプリケーション設定から、複数プロジェクトで自動Duoコードレビューを有効にできるようになりました。従来のように特定プロジェクトを個別に有効化するのではなく、グループ内のすべてのプロジェクトでDuoコードレビューを迅速に有効化できます。\n\nこの機能は現在[GitLab.com](http://gitlab.com)で利用可能です。GitLab Self-Managedでの提供は今後のリリースで予定しています。本機能に関するフィードバックは[イシュー517386](https://www.claudeusercontent.com/?errorReportingMode=parent#)までお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#automatic-reviews-from-gitlab-duo-for-groups-and-applications)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/554070)\n\n### **エピック・イシューリストの親フィルター機能を強化**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate \n\nイシューページとエピックページの「エピック」フィルターを、より使いやすい「親」フィルターに変更しました。これまでエピックのみで絞り込みできていたところが、すべての親作業アイテムでのフィルタリングに対応します。親イシューで子タスクを簡単に見つけたり、親エピックでイシューを見つけたりできるようになり、イシューリストとエピックリストの両方で作業階層がより把握しやすくなりました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/issues/issue_work_items/#new-features)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/work_items/556200)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/work_items/556200)\n\n![enhanced_parent_filtering_for_better_work_item_retrieval](https://about.gitlab.com/images/18_4/enhanced_parent_filtering_for_better_work_item_retrieval.png)\n\n\n\n### **テキストエディターツールバー機能の統一**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nGitLabプレーンテキストエディタに、リッチテキストエディタと同じフォーマットオプションが追加されました。プレーンテキストエディタツールバーに「その他のオプション」メニューが追加され、以下の高度なフォーマットツールにアクセスできます：\n\n* コードブロック\n* 詳細ブロック\n* 水平線\n* Mermaid図\n* PlantUML図\n* 目次\n\n両エディタでボタン配置とセパレータが統一され、馴染みのあるフォーマットオプションへのアクセスを維持しながら、編集モード間の切り替えが簡単になりました。\n\n[ドキュメント](https://docs.gitlab.com/user/rich_text_editor/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/507377)\n\n### **GitLab Runner 18.4**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nGitLab Runner 18.4も本日リリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\nバグ修正：\n\n* [FIPS Runnerが、GitLab Runner 18.2.1でジョブの開始に失敗する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38963)\n* [OpenShift 4.16.27でOperator v1.37.0アップグレード後、カスタムConfigMapとセキュリティコンテキストの制約（SCC）を使用したRunnerで`chown`コマンドが失敗する](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/246)\n* [GitLab 17.2での早期削除により、GitLab 17.x.xリリースで`FF_RETRIEVE_POD_WARNING_EVENTS`を復元](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38851)\n* [ファイルシステム権限エラーによりすべてのGitLab Runnerジョブが失敗する](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/214)\n* [ビルドジョブが権限拒否エラーで散発的に失敗する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37464)\n* [GitLab Runner Helmチャートのアップグレードにより変数が破損する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/30851)\n* [`FF_USE_FASTZIP`を有効にしてもfastzipが有効にならない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28989)\n* [ワンタイムリクエストで作成されたSpotインスタンスを停止しようとした際にGitLab Runnerで`UnsupportedOperation`エラーが発生する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28865)\n* [Kubernetes環境にデプロイされた環境でGitLab Runnerのロングポーリングが適切に動作しない](https://gitlab.com/gitlab-org/gitlab/-/issues/331460)\n* [管理者がimage:kubernetes:userの値を上書きできるようにする](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38894)\n\nすべての変更の一覧は、GitLab Runnerの[CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-4-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### **運用コンテナスキャンの重大度しきい値設定**\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\n\n運用コンテナスキャン（OCS: Operational Container Scanning）で、特定の重大度レベル以上の脆弱性のみを返すよう設定できるようになりました。重大度しきい値を設定すると、選択した重大度を下回る脆弱性は、脆弱性レポート、APIペイロード、その他のレポートメカニズムに表示されなくなります。これにより、修正したい脆弱性に集中できます。\n\nこのフィルタリングを有効にするには、OCS設定で[`severity_threshold`を設定](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/#configure-trivy-severity-threshold-filter)します。\n\n[John Walsh](https://gitlab.com/mjohnw)さんによるコミュニティコントリビュートに心より感謝いたします。GitLabへのコントリビュートについて詳しく知りたい方は、[コミュニティコントリビュートプログラム](https://about.gitlab.com/community/contribute/)をご確認ください。\n\n[ドキュメント](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/#configure-trivy-severity-threshold-filter)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/559278)\n\n### **シークレット検出アナライザーのGitフェッチング改善**\n\n> GitLab.com: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\\\n> GitLab Dedicated: Ultimate\n\nシークレット検出アナライザーのバージョン[7.12.0](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/releases/v7.12.0)で、Gitコミットフェッチ方法に大幅な改善が追加されました。アナライザーは`SECRET_DETECTION_LOG_OPTIONS`から渡される`--depth`および`--since`オプションを解析し、スキャンするコミット数をより詳細に指定できるようになりました。また、コンテキストに基づいて適切なフェッチ戦略を選択し、浅い深さ設定でも数百万のコミットが不要にフェッチされる既知の問題を防止します。\n\nこの強化により、ジョブタイムアウトの削減、リソース消費の低下、より予測可能なスキャンパフォーマンスが実現されます。大規模リポジトリでのシークレット検出スキャンが高速化され、実際のフェッチ動作に合致するより明確なログが記録されます。\n\n[ドキュメント](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/#configure-trivy-severity-threshold-filter)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17315)\n\n### **脆弱性詳細での自動解決パイプラインID表示**\n\n> GitLab.com: Ultimate\\\n> Self-Managed: Ultimate\\\n> GitLab Dedicated: Ultimate\n\n自動解決後に再検出された脆弱性をトラブルシューティングする際、現在のパイプラインと脆弱性が解決された時のパイプラインを比較すると効果的です。\n\n脆弱性が自動解決された場合、脆弱性詳細ページの脆弱性ノートに、その解決が実行されたパイプラインIDが含まれるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/566392)\n\n### **GitLab Duo Self-Hostedでのサポートモデル追加**\n\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duo Enterpriseを利用するGitLab Self-Managedのお客様は、GitLab Duoでさらに多くのサポートモデルを利用できるようになりました。Azure OpenAIでOpenAI GPT-5のサポートが開始されました。また、オープンソースのOpenAI GPT OSS 20Bおよび120Bについても、vLLMとAzure OpenAIでサポートされます。これらのモデルをGitLab Duo Self-Hostedでご利用いただいた感想は、[イシュー523918](https://www.claudeusercontent.com/?errorReportingMode=parent#)までお寄せください。\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/16742)\n\n### **GitLab Duo Self-HostedでDuoコードレビューの一般提供開始**\n\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duo Self-HostedでのGitLab Duoコードレビューの一般提供が開始されました。データの管理権限を保持しながら開発プロセスを加速させます。コードレビューがマージリクエストをレビューする際、潜在的なバグを特定し、直接適用可能な改善案を提示します。人間によるレビューを依頼する前に、コードレビューを使用して変更を反復し、改善してください。この機能はMistral、Meta Llama、Anthropic Claude、OpenAI GPTの各モデルファミリーをサポートしています。\n\nコードレビューに関するフィードバックは、[イシュー517386](https://www.claudeusercontent.com/?errorReportingMode=parent#)までお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/#gitlab-duo-in-merge-requests)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/548975)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/548975)\n\n![Self_Hosted_Code_Review-min1](https://about.gitlab.com/images/18_4/Self_Hosted_Code_Review-min1.png)\n\n\n\n## 実験的機能\n\n### **GitLab Duo Self-HostedでGitLab Duo Agent Platformが利用可能に**\n\nGitLab Duo Self-Hostedをご利用のお客様は、GitLab Duo Agent Platformを実験的機能として利用できるようになりました。GitLab Duo Workflow Serviceが既存のセルフホスト型AIゲートウェイDockerイメージに統合され、AIエージェントとワークフロー自動化をサポートします。管理者は、すべてのエージェントで使用する単一のモデルを設定できます。\nGitLab Duo Agent Platformの機能の詳細については、[ブログ](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta/)をご覧ください。\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n\n18.4で提供されたすべてのバグ修正、パフォーマンスの強化、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.4)\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.4)\n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.4)\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n* [GitLabチャートにおけるBitnami PostgreSQLおよびRedisイメージ](https://docs.gitlab.com/ee/update/deprecations.html#bitnami-postgresql-and-redis-images-in-gitlab-chart)\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n* [GitLabチャートにおけるBitnami PostgreSQLおよびRedisイメージ](https://docs.gitlab.com/ee/update/deprecations.html#bitnami-postgresql-and-redis-images-in-gitlab-chart)[](https://docs.gitlab.com/ee/update/deprecations.html#bitnami-postgresql-and-redis-images-in-gitlab-chart)\n\n### GitLab 18.4へのアップグレードに関する重要なお知らせ\n\nGitLab Helmチャートのデフォルト設定では、PostgreSQLとRedisにのBitnamiのチャートとコンテナイメージを使用しています。Bitnamiは2025年9月29日をもって、[これらのイメージの無料提供を終了](https://github.com/bitnami/charts/issues/35164)することを発表しました。2025年8月28日からイメージを断続的に利用できなくなる期間が開始されています。\n\nGitLabチャートに含まれるBitnamiのPostgreSQLとRedisはでもおよびテスト目的のみでの使用を想定しているため、本番環境への影響はありません。一時的な解決策として、GitLabではチャート設定をBitnamiレガシーリポジトリに移行しました。ただし、パッチが適用されていないGitLabチャート環境（GitLab 17.11以前、GitLab 18.0.5、GitLab 18.1.4、GitLab 18.2.1以前）では、非推奨のBitnamiリポジトリからのイメージ取得を継続するため、9月29日以降にデプロイが失敗する可能性があります。断続的な停止期間中も同様にデプロイが失敗する可能性があります。\n\n影響を受けるGitLabチャート設定を使用する場合は、以下のいずれかの対応を行ってください：\n\n* サポート対象のGitLabリファレンスアーキテクチャへの移行\n* パッチ適用済みチャートバージョンへのアップグレード\n* チャート値でのレガシーリポジトリ設定（例：[マージリクエスト4421](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/4421)）\n\n現在、[代替案と今後の対応](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/6089)について検討中です。\n\n### 変更履歴\n\n変更内容をすべて表示するには、次のページから変更履歴を確認してください。\n\n* [](\u003C>)[GitLab](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/CHANGELOG.md)\n* [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/CHANGELOG.md)\n* [GitLab Workflow for VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md)\n* [GitLab CLI](https://gitlab.com/gitlab-org/cli/-/releases)\n\n### インストール\n\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/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.4](https://about.gitlab.com/ja-jp/blog/gitlab-18-04-release)\n* [GitLab 18.3](https://about.gitlab.com/ja-jp/blog/gitlab-18-03-release)\n* [](\u003C>)[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/)[](\u003C>)",[901],"2025-09-19","GitLab 18.4リリース",[1031,837,764,109],"GitLab 18.4でリリースした最新機能を公開します。",{"featured":91,"template":799,"slug":1085},"gitlab-18-04-release",{"content":1087,"config":1096},{"heroImage":1088,"body":1089,"authors":1090,"updatedDate":1091,"date":1092,"title":1093,"tags":1094,"description":1095,"category":764},"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### **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> 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> 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### **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> 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> 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ドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。[](\u003C>)\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\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* [](\u003C>)[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* [GitLab 18.4](https://about.gitlab.com/ja-jp/blog/gitlab-18-04-release)\n* [GitLab 18.3](https://about.gitlab.com/ja-jp/blog/gitlab-18-03-release)\n* [](\u003C>)[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/)[](\u003C>)",[901],"2025-08-25","2025-08-22","GitLab 18.3 リリース",[1031,837,764,109],"GitLab 18.3でリリースした最新機能を公開します。",{"featured":91,"template":799,"slug":1097},"gitlab-18-03-release",{"content":1099,"config":1108},{"heroImage":1100,"body":1101,"authors":1102,"updatedDate":1103,"date":1104,"title":1105,"tags":1106,"description":1107,"category":764},"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/)",[901],"2025-07-24","2025-07-18","GitLab 18.2 リリース",[1031,837,764,109],"GitLab 18.2でリリースした最新機能を公開します。",{"featured":91,"template":799,"slug":1109},"gitlab-18-02-release",{"category":126,"slug":775,"posts":1111},[1112,1124,1135],{"content":1113,"config":1122},{"title":1114,"description":1115,"authors":1116,"heroImage":1118,"date":1103,"body":1119,"category":775,"tags":1120},"ソフトウェアサプライチェーンのセキュリティガイド：組織が直面する課題とは","この新シリーズの第1部では、すべての開発チームが理解すべき、基本的な課題、実践的な解決策、そしてAIを含む新たなトレンドを探ります。",[1117],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097701/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%285%29_1iy516k40hwBDChKcUJ2zb_1750097700983.png","大抵の開発チームは、サプライチェーンセキュリティについて尋ねられると、脆弱性スキャンや依存関係の管理を挙げるでしょう。確かにそれらはサプライチェーンセキュリティの構成要素ではありますが、実際の課題のごく一部であり、その視点は非常に限定的で、危険です。\n\n**サプライチェーンセキュリティとは、単に依存関係をスキャンすることではありません。** コードの作成から本番環境へのデプロイまで、以下を含む一連のプロセス全体を対象としています。\n\n* **ソースセキュリティ**：コードリポジトリの保護、コントリビューターのアクセス管理、コードの整合性の確保  \n* **ビルドセキュリティ**：ビルド環境の保護、コンパイルやパッケージ化時の改ざん防止  \n* **アーティファクトセキュリティ**：コンテナやパッケージ、デプロイ用アーティファクトの整合性の確保  \n* **デプロイセキュリティ**：配信手段および実行環境の保護  \n* **ツールセキュリティ**：開発ツールやプラットフォーム自体の強化\n\nサプライチェーンセキュリティにおける「チェーン」とは、この一連の相互に連携したステップを指します。チェーンのどこかに脆弱性があると、ソフトウェアデリバリーのプロセス全体が危険にさらされてしまいます。\n\n[2020年に発生したSolarWinds攻撃](https://www.cisa.gov/news-events/news/joint-statement-federal-bureau-investigation-fbi-cybersecurity-and-infrastructure-security)は、その典型的な例です。これは史上最大級のサプライチェーン攻撃の一つであり、国家の支援を受けた攻撃者がSolarWindsのネットワーク管理ソフト「Orion」のビルドパイプラインを侵害しました。攻撃者は脆弱な依存関係を悪用したり、完成したアプリケーションをハッキングしたのではなく、コンパイルプロセスそのものに悪意あるコードを注入したのです。\n\nその結果は壊滅的でした。通常のソフトウェアアップデートを通じて、米国政府機関を含む18,000以上の組織が、気づかないうちにバックドア付きのソフトウェアをインストールしてしまいました。ソースコードには問題がなく、完成したアプリケーションも正規のものに見えましたが、ビルドプロセスが攻撃手段として利用されていたのです。この攻撃は数か月にわたって検出されず、サプライチェーンの脆弱性が従来のセキュリティ対策をいかに回避できるかを示す事例となりました。\n\n### 組織を脆弱にするよくある誤解\n\nサプライチェーンの脅威に対する認識は高まりつつありますが、多くの組織はいまだに危険にさらされています。というのも、「ソフトウェアサプライチェーンセキュリティとは何か」という根本的な理解に誤りがあるからです。こうした誤解が、重大な見落としを生んでしまいます。\n\n* ソフトウェアサプライチェーンセキュリティは依存関係スキャンだけだと考えている\n* オープンソースコンポーネントにばかり注目し、プロプライエタリコードのリスクを無視している\n* コード署名だけで十分に保護できると思っている\n* 安全なコーディング慣行さえ守っていれば、サプライチェーンのリスクはなくなると考えている\n* サプライチェーンセキュリティを、セキュリティチームだけの問題だと捉え、開発ワークフローの課題として見ていない\n\n![ソフトウェアサプライチェーンセキュリティ依存関係チャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200077/kqndvlxyvncshdiq0xea.png)\n\n## AIが新たな脅威に\n\n多くの組織が従来型のソフトウェアサプライチェーンセキュリティの課題に取り組んでいる中、人工知能（AI）はまったく新しい攻撃ベクトルを生み出し、既存のリスクをこれまでにない形で拡大させています。\n\n### AIによる攻撃：より巧妙に、より大規模に\n\n攻撃者はAIを使って脆弱性の発見を自動化し、デベロッパーを狙った巧妙なソーシャルエンジニアリング攻撃を作成し、公開されているコードベースを体系的に分析して弱点を探しています。かつては手作業でしか行えなかったことが、いまや正確かつ大規模に実行できるようになっています。\n\n### AI開発のサプライチェーンがもたらす新たなリスク\n\nAIは開発ライフサイクル全体を再構築していますが、それと同時に深刻なセキュリティの死角も生み出しています。\n\n* **モデルのサプライチェーン攻撃**：Hugging FaceやGitHubなどから提供される事前学習済みモデルには、バックドアや汚染されたトレーニングデータが含まれている恐れがあります。\n* **安全でないAI生成コード**：AIコードアシスタントを使うデベロッパーが、気づかないうちに脆弱なパターンや危険な依存関係を導入することがあります。\n* **危険にさらされたAIツールチェーン**：AIモデルの学習、デプロイ、管理に使われるインフラが、新たなアタックサーフェス（攻撃対象領域）となります。\n* **自動化された偵察**：AIにより、攻撃者はエコシステム全体をスキャンして、高リスクなサプライチェーンの標的を特定できます。\n* **シャドーAIと非公認ツール**：デベロッパーが、安全性が確認されていない外部AIツールを組み込んでしまうことがあります。\n\nその結果どうなるか？AIは単に新しい脆弱性をもたらすだけでなく、既存のリスクの規模と影響を増幅します。もはや、段階的な改善では追いつけません。脅威の状況は、現在のセキュリティ対策が対応できるスピードを上回る勢いで進化しています。\n\n![AIによる増幅効果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200139/xuxezxld6ztlvjocgjlx.png)\n\n## 多くの組織がいまだに苦戦している理由\n\nサプライチェーンセキュリティの重要性を理解している組織でさえ、効果的に対処できていないことがよくあります。統計は、「認識しているのに行動が伴わない」という深刻な傾向を明らかにしています。\n\n2021年に[コロニアル・パイプライン社が業務復旧のためにハッカーに440万ドルを支払った事件](https://www.cnn.com/2021/05/19/politics/colonial-pipeline-ransom/index.html)や、18,000もの組織が被害を受けたSolarWinds攻撃は、サプライチェーンの脆弱性が、重要インフラを停止させ、かつてない規模で機密データを危険にさらす可能性があることを世に知らしめました。\n\nそれにもかかわらず、多くの組織はいまだに従来どおりの運用を続けています。本質的な問いは、「組織がサプライチェーンセキュリティを重要だと考えているか」ではなく、「なぜそう考えていても、実効的な対策につながらないのか」という点です。\n\nその答えは、効果的な行動を妨げている4つの重要な障壁にあります。\n\n**1. 誤った「コスト優先」思考**\n\n組織はしばしば、「最も効果的な方法は何か？」ではなく、「コストがかからないのはどれか？」という観点で考えてしまいます。こうしたコスト第一の考え方は、後に高くつく問題を生み出すことになります。\n\n**2. スキル不足という現実**\n\nBSIMM（Building Security In Maturity Model）の調査によると、[組織にはデベロッパー100人あたり平均でセキュリティ専門家がわずか4人しかおらず](https://codific.com/bsimm-building-security-in-maturity-model-a-complete-guide/)、さらにISC2の調査では、[90%の組織が深刻なサイバーセキュリティ人材の不足を報告](https://www.isc2.org/Insights/2024/09/Employers-Must-Act-Cybersecurity-Workforce-Growth-Stalls-as-Skills-Gaps-Widen)しています。このような状況では、従来のアプローチをスケールさせることは数学的に不可能です。\n\n**3. 組織内のインセンティブの不一致**\n\nデベロッパーのOKR（Objective and Key Results）は機能の開発速度に重点が置かれる一方で、セキュリティチームはまったく異なる成果を指標にしています。経営陣が市場投入のスピードをセキュリティ対策状況よりも重視するような状況では、部門間の摩擦は避けられません。\n\n**4. 複雑すぎるツール環境**\n\n[一般的な企業では平均して45種類ものサイバーセキュリティツールを使っており](https://www.gartner.com/en/newsroom/press-releases/2025-03-03-gartner-identifiesthe-top-cybersecurity-trends-for-2025)、そのうちの[40%は誤検知](https://www.ponemon.org/news-updates/blog/security/new-ponemon-study-on-malware-detection-prevention-released.html)です。また、[インシデント対応には平均して19種類ものツールをまたいで調整を行う](https://newsroom.ibm.com/2020-06-30-IBM-Study-Security-Response-Planning-on-the-Rise-But-Containing-Attacks-Remains-an-Issue)必要があります。\n\nこうした障壁によって悪循環が生まれます。組織は脅威を認識し、セキュリティソリューションに投資はするものの、期待される効果が得られるような実装ができていないのです。\n\n## サプライチェーンの脆弱性がもたらす本当の代償\n\nサプライチェーン攻撃によって生じるリスクとコストは、初期の対処だけでは収まりません。こうした見えにくい追加的な負担を理解することで、予防が「望ましい」どころか、「ビジネスを継続するために不可欠」だということがわかります。\n\n**時間が最大の敵になる**\n\n* サプライチェーンの侵害を特定して封じ込めるまでの平均時間：[277日](https://keepnetlabs.com/blog/171-cyber-security-statistics-2024-s-updated-trends-and-data)\n* 顧客の信頼を回復するまでの期間：[2〜3年以上](https://www.bcg.com/publications/2024/rebuilding-corporate-trust)\n* 製品開発に充てるはずの工数が、セキュリティ対策に振り向けられる\n\n**評判へのダメージは拡大する一方** \n\n攻撃者にサプライチェーンを突破された場合、奪われるのはデータだけではありません。顧客との信頼関係という土台そのものが揺らいでしまいます。実際、侵害後には[顧客の解約率が平均で33%上昇](https://www.metacompliance.com/blog/data-breaches/5-damaging-consequences-of-a-data-breach)し、パートナーとの関係も再認証プロセスなどで多大なコストが発生します。さらに、「より安全だと見なされる」競合に見込み顧客が流れてしまい、競争力の低下にもつながります。\n\n**規制の現実が重くのしかかる** \n\n規制の状況は根本的に変化しています。[GDPR（EU一般データ保護規則）による罰金は、重大なデータ侵害の場合、平均して5,000万ドルを超えています](https://www.skillcast.com/blog/20-biggest-gdpr-fines)。EUの新しい[サイバーレジリエンス法](https://about.gitlab.com/blog/gitlab-supports-banks-in-navigating-regulatory-challenges/#european-cyber-resilience-act-\\(cra\\))では、サプライチェーンの透明性が義務づけられています。アメリカの連邦契約業者は、すべてのソフトウェア購入においてソフトウェア部品表（[SBOM](https://about.gitlab.com/ja-jp/blog/the-ultimate-guide-to-sboms/)）を提供しなければならず、この要件は民間企業の調達にも急速に広がりつつあります。\n\n**業務への混乱がさらに広がる** \n\n直接的なコストだけでなく、サプライチェーン攻撃は、攻撃対応中のプラットフォームのダウンタイム、テクノロジースタック全体にわたる緊急セキュリティ監査、顧客からの訴訟や規制当局の調査による法的コストなど、業務に深刻な混乱をもたらします。\n\n## 現在のアプローチの問題点\n\n多くの組織は、「セキュリティ対策をしていること」と「実際にセキュリティ効果があること」を混同しています。スキャナーを導入し、長大なレポートを作成して、各チームに手作業で対応させています。こうした取り組みはしばしば逆効果で、問題を解決するどころか、かえって新たな問題を生んでしまいます。\n\n### 大量のスキャンvs.実効性のある保護\n\n企業は[毎月1万件以上のセキュリティアラートを生成しており、中には1日15万件ものイベントを記録するケースもあります](https://www.securityweek.com/enterprises-generate-10000-security-events-day-average-report/)。しかし、これらの[63%](https://panther.com/blog/identifying-and-mitigating-false-positive-alerts)は誤検出や優先度の低いノイズにすぎません。結果として、セキュリティチームは処理しきれず、推進役ではなくボトルネックになってしまいます。\n\n### コラボレーションの崩壊\n\n最も安全な組織というのは、ツールをたくさん使っている組織ではなく、DevSecOps間の連携が強い組織です。しかし、現在のほとんどの体制では、この連携が難しくなっています。ワークフローが互換性のないツールで分断されているため、デベロッパーは自分の環境でセキュリティ結果を確認できず、リスクやビジネスへの影響もチーム間で共有できていません。\n\n## 今後に向けて\n\nこうした課題を理解することが、効果的なソフトウェアサプライチェーンセキュリティを構築するための第一歩です。成功している組織は、単にセキュリティツールを追加するのではなく、セキュリティを開発ワークフローにどのように統合するかを根本から見直しています。また、ソフトウエアデリバリーのプロセス全体を振り返り、プロセスの簡素化、ツールの削減、コラボレーションの改善にも取り組んでいます。\n\nGitLabでは、統合型DevSecOpsプラットフォームによって、セキュリティが開発ワークフローに直接組み込まれることで、こうした課題に対応できることを目の当たりにしてきました。このシリーズの次回の記事では、先進的な組織がどのようにして「デベロッパーにとって使いやすいソリューション」や「AIによる自動化」、そして「セキュリティをソフトウェア開発の自然な一部にできるプラットフォーム」を活用し、サプライチェーンセキュリティへの取り組みを根本から変えているのかをご紹介します。\n> GitLabのソフトウェアサプライチェーンのセキュリティ機能について詳しくは、[こちら](https://about.gitlab.com/ja-jp/solutions/supply-chain/)をご覧ください。",[126,90,1121],"チュートリアル",{"featured":91,"template":799,"slug":1123},"software-supply-chain-security-guide-why-organizations-struggle",{"content":1125,"config":1133},{"title":1126,"description":1127,"authors":1128,"heroImage":1129,"date":1130,"body":1131,"category":775,"tags":1132},"IDE、そしてWeb IDEとは","Web IDE や IDE の知識を身に付け、統合開発環境ツール使用時や、開発自体に生かしましょう。",[967],"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",[944,795,764,796],{"slug":1134,"featured":91,"template":799},"what-is-ide",{"content":1136,"config":1145},{"title":1137,"description":1138,"authors":1139,"heroImage":1141,"date":1142,"body":1143,"category":775,"tags":1144},"GitLabのカスタムコンプライアンスフレームワークをDevSecOps環境で活用する方法","新しいフレームワークと、50個を超えるすぐに使えるコントロールを活用することで、これまでひとつずつチェックしていた規制要件を、統合された自動化ワークフローの一部へと変換する方法をご紹介します。",[1140],"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/)",[775,796,794,795,764],{"slug":1146,"featured":91,"template":799},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"content":1148,"config":1151},{"heroImage":1077,"body":1078,"authors":1149,"updatedDate":965,"date":1080,"title":1081,"tags":1150,"description":1083,"category":764},[901],[1031,837,764,109],{"featured":91,"template":799,"slug":1085},[1153,1158,1163],{"content":1154,"config":1157},{"category":729,"body":964,"date":965,"authors":1155,"heroImage":968,"title":969,"description":970,"tags":1156},[967],[109,944,972,713,795,973,796,809],{"featured":6,"template":799,"slug":975},{"content":1159,"config":1162},{"title":1002,"description":1003,"heroImage":1004,"authors":1160,"date":1007,"body":1008,"category":741,"tags":1161},[1006],[764,741,713],{"featured":91,"template":799,"slug":1011},{"content":1164,"config":1167},{"heroImage":978,"date":979,"authors":1165,"category":729,"body":981,"tags":1166,"title":983,"description":984},[967],[944,796,809,795],{"featured":6,"template":799,"slug":986},[1169,1174,1179],{"content":1170,"config":1173},{"title":989,"description":990,"authors":1171,"heroImage":992,"date":993,"body":994,"category":729,"tags":1172},[967],[837,713,795,796,775],{"featured":6,"template":799,"slug":997},{"content":1175,"config":1178},{"date":926,"authors":1176,"title":928,"description":929,"heroImage":930,"category":717,"tags":1177,"body":933},[901],[837,932,713,280,775],{"featured":91,"template":799,"slug":935},{"content":1180,"config":1183},{"title":1026,"authors":1181,"heroImage":1028,"date":1029,"category":741,"tags":1182,"body":1032,"description":1033},[901],[837,109,944,270,892,713,280,795,741,1031,775,918],{"featured":6,"template":799,"slug":1035},1758747509457]