[{"data":1,"prerenderedAt":4046},["ShallowReactive",2],{"/ja-jp/blog/archive/":3,"navigation-ja-jp":21,"banner-ja-jp":437,"footer-ja-jp":450,"archivePosts-ja-jp":660},{"_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/archive","blog",false,"",{"title":9,"description":10},"GitLab Blog Archives","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"header":12},"Blog Archive",{"template":14},"BlogArchive","content:ja-jp:blog:archive:index.yml","yaml","content","ja-jp/blog/archive/index.yml","ja-jp/blog/archive/index","yml",{"_path":22,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":24,"_id":433,"_type":16,"title":434,"_source":17,"_file":435,"_stem":436,"_extension":20},"/shared/ja-jp/main-navigation","ja-jp",{"logo":25,"freeTrial":30,"sales":35,"login":40,"items":45,"search":377,"minimal":411,"duo":424},{"config":26},{"href":27,"dataGaName":28,"dataGaLocation":29},"/ja-jp/","gitlab logo","header",{"text":31,"config":32},"無料トライアルを開始",{"href":33,"dataGaName":34,"dataGaLocation":29},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":36,"config":37},"お問い合わせ",{"href":38,"dataGaName":39,"dataGaLocation":29},"/ja-jp/sales/","sales",{"text":41,"config":42},"サインイン",{"href":43,"dataGaName":44,"dataGaLocation":29},"https://gitlab.com/users/sign_in/","sign in",[46,90,189,194,299,359],{"text":47,"config":48,"cards":50,"footer":73},"プラットフォーム",{"dataNavLevelOne":49},"platform",[51,57,65],{"title":47,"description":52,"link":53},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":54,"config":55},"プラットフォームを詳しく見る",{"href":56,"dataGaName":49,"dataGaLocation":29},"/ja-jp/platform/",{"title":58,"description":59,"link":60},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":61,"config":62},"GitLab Duoのご紹介",{"href":63,"dataGaName":64,"dataGaLocation":29},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":66,"description":67,"link":68},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":69,"config":70},"詳細はこちら",{"href":71,"dataGaName":72,"dataGaLocation":29},"/ja-jp/why-gitlab/","why gitlab",{"title":74,"items":75},"利用を開始：",[76,81,86],{"text":77,"config":78},"プラットフォームエンジニアリング",{"href":79,"dataGaName":80,"dataGaLocation":29},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":82,"config":83},"開発者の経験",{"href":84,"dataGaName":85,"dataGaLocation":29},"/ja-jp/developer-experience/","Developer experience",{"text":87,"config":88},"MLOps",{"href":89,"dataGaName":87,"dataGaLocation":29},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":91,"left":92,"config":93,"link":95,"lists":99,"footer":171},"製品",true,{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"すべてのソリューションを表示",{"href":98,"dataGaName":94,"dataGaLocation":29},"/ja-jp/solutions/",[100,126,149],{"title":101,"description":102,"link":103,"items":108},"自動化","CI/CDと自動化でデプロイを加速",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":29},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[109,113,117,122],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":29,"dataGaName":110},"/ja-jp/solutions/continuous-integration/",{"text":114,"config":115},"AIアシストによる開発",{"href":63,"dataGaLocation":29,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"ソースコード管理",{"href":120,"dataGaLocation":29,"dataGaName":121},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"自動化されたソフトウェアデリバリー",{"href":106,"dataGaLocation":29,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":29,"icon":133},"/ja-jp/solutions/security-compliance/","security and compliance","ShieldCheckLight",[135,140,145],{"text":136,"config":137},"Application Security Testing",{"href":138,"dataGaName":139,"dataGaLocation":29},"/solutions/application-security-testing/","Application security testing",{"text":141,"config":142},"ソフトウェアサプライチェーンの安全性",{"href":143,"dataGaLocation":29,"dataGaName":144},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":146,"dataGaLocation":29},"/solutions/software-compliance/",{"title":150,"link":151,"items":156},"測定",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":29},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"可視性と測定",{"href":154,"dataGaLocation":29,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"バリューストリーム管理",{"href":164,"dataGaLocation":29,"dataGaName":165},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"分析とインサイト",{"href":169,"dataGaLocation":29,"dataGaName":170},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLabが活躍する場所",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":29,"dataGaName":178},"/ja-jp/enterprise/","enterprise",{"text":180,"config":181},"スモールビジネス",{"href":182,"dataGaLocation":29,"dataGaName":183},"/ja-jp/small-business/","small business",{"text":185,"config":186},"公共機関",{"href":187,"dataGaLocation":29,"dataGaName":188},"/ja-jp/solutions/public-sector/","public sector",{"text":190,"config":191},"価格",{"href":192,"dataGaName":193,"dataGaLocation":29,"dataNavLevelOne":193},"/ja-jp/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":286},"関連リソース",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"すべてのリソースを表示",{"href":201,"dataGaName":197,"dataGaLocation":29},"/ja-jp/resources/",[203,236,258],{"title":204,"items":205},"はじめに",[206,211,216,221,226,231],{"text":207,"config":208},"インストール",{"href":209,"dataGaName":210,"dataGaLocation":29},"/ja-jp/install/","install",{"text":212,"config":213},"クイックスタートガイド",{"href":214,"dataGaName":215,"dataGaLocation":29},"/ja-jp/get-started/","quick setup checklists",{"text":217,"config":218},"学ぶ",{"href":219,"dataGaLocation":29,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"製品ドキュメント",{"href":224,"dataGaName":225,"dataGaLocation":29},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"ベストプラクティスビデオ",{"href":229,"dataGaName":230,"dataGaLocation":29},"/ja-jp/getting-started-videos/","best practice videos",{"text":232,"config":233},"インテグレーション",{"href":234,"dataGaName":235,"dataGaLocation":29},"/ja-jp/integrations/","integrations",{"title":237,"items":238},"検索する",[239,244,248,253],{"text":240,"config":241},"お客様成功事例",{"href":242,"dataGaName":243,"dataGaLocation":29},"/ja-jp/customers/","customer success stories",{"text":245,"config":246},"ブログ",{"href":247,"dataGaName":5,"dataGaLocation":29},"/ja-jp/blog/",{"text":249,"config":250},"リモート",{"href":251,"dataGaName":252,"dataGaLocation":29},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":29},"/ja-jp/teamops/","teamops",{"title":259,"items":260},"つなげる",[261,266,271,276,281],{"text":262,"config":263},"GitLabサービス",{"href":264,"dataGaName":265,"dataGaLocation":29},"/ja-jp/services/","services",{"text":267,"config":268},"コミュニティ",{"href":269,"dataGaName":270,"dataGaLocation":29},"/community/","community",{"text":272,"config":273},"フォーラム",{"href":274,"dataGaName":275,"dataGaLocation":29},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"イベント",{"href":279,"dataGaName":280,"dataGaLocation":29},"/events/","events",{"text":282,"config":283},"パートナー",{"href":284,"dataGaName":285,"dataGaLocation":29},"/ja-jp/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":291,"config":292},"ソースプロモカード",{"src":293},"/images/navigation/the-source-promo-card.svg",{"text":295,"config":296},"最新情報を読む",{"href":297,"dataGaName":298,"dataGaLocation":29},"/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":29},"/ja-jp/company/","about",{"text":312,"config":313,"footerGa":316},"採用情報",{"href":314,"dataGaName":315,"dataGaLocation":29},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":29},{"text":320,"config":321},"経営陣",{"href":322,"dataGaName":323,"dataGaLocation":29},"/company/team/e-group/","leadership",{"text":325,"config":326},"チーム",{"href":327,"dataGaName":328,"dataGaLocation":29},"/company/team/","team",{"text":330,"config":331},"ハンドブック",{"href":332,"dataGaName":333,"dataGaLocation":29},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"投資家向け情報",{"href":337,"dataGaName":338,"dataGaLocation":29},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"トラストセンター",{"href":342,"dataGaName":343,"dataGaLocation":29},"/ja-jp/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":29},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"ニュースレター",{"href":352,"dataGaName":353,"dataGaLocation":29},"/company/contact/","newsletter",{"text":355,"config":356},"プレス",{"href":357,"dataGaName":358,"dataGaLocation":29},"/press/","press",{"text":36,"config":360,"lists":361},{"dataNavLevelOne":302},[362],{"items":363},[364,367,372],{"text":36,"config":365},{"href":38,"dataGaName":366,"dataGaLocation":29},"talk to sales",{"text":368,"config":369},"サポートを受ける",{"href":370,"dataGaName":371,"dataGaLocation":29},"/support/","get help",{"text":373,"config":374},"カスタマーポータル",{"href":375,"dataGaName":376,"dataGaLocation":29},"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":43,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"提案",[389,392,397,399,403,407],{"text":58,"config":390},{"href":63,"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":110,"config":398},{"href":112,"dataGaName":110,"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":71,"dataGaName":410,"dataGaLocation":385},"Why GitLab?",{"freeTrial":412,"mobileIcon":416,"desktopIcon":421},{"text":31,"config":413},{"href":414,"dataGaName":34,"dataGaLocation":415},"https://gitlab.com/-/trials/new/","nav",{"altText":417,"config":418},"GitLabアイコン",{"src":419,"dataGaName":420,"dataGaLocation":415},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":417,"config":422},{"src":423,"dataGaName":420,"dataGaLocation":415},"/images/brand/gitlab-logo-type.svg",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"GitLab Duoの詳細について",{"href":63,"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":23,"_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":29},"/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":23,"_draft":6,"_partial":6,"_locale":7,"data":452,"_id":656,"_type":16,"title":657,"_source":17,"_file":658,"_stem":659,"_extension":20},"/shared/ja-jp/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":648},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":455,"config":456},"ページのソースを表示",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"このページを編集",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"ご協力をお願いします",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,553,586,620],{"title":47,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOpsプラットフォーム",{"href":56,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":190,"links":484},[485,489,494],{"text":486,"config":487},"プランの表示",{"href":192,"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":138,"dataGaName":139,"dataGaLocation":459},{"text":123,"config":511},{"href":106,"dataGaName":107,"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":120,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":110,"config":527},{"href":112,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":162,"config":530},{"href":164,"dataGaName":531,"dataGaLocation":459},"value stream management",{"text":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":459},"/ja-jp/solutions/gitops/","gitops",{"text":175,"config":538},{"href":177,"dataGaName":178,"dataGaLocation":459},{"text":180,"config":540},{"href":182,"dataGaName":183,"dataGaLocation":459},{"text":185,"config":542},{"href":187,"dataGaName":188,"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":195,"links":554},[555,557,559,561,564,566,570,572,574,576,578,580,582,584],{"text":207,"config":556},{"href":209,"dataGaName":210,"dataGaLocation":459},{"text":212,"config":558},{"href":214,"dataGaName":215,"dataGaLocation":459},{"text":217,"config":560},{"href":219,"dataGaName":220,"dataGaLocation":459},{"text":222,"config":562},{"href":224,"dataGaName":563,"dataGaLocation":459},"docs",{"text":245,"config":565},{"href":247,"dataGaName":5},{"text":567,"config":568},"お客様の成功事例",{"href":569,"dataGaLocation":459},"/customers/",{"text":240,"config":571},{"href":242,"dataGaName":243,"dataGaLocation":459},{"text":249,"config":573},{"href":251,"dataGaName":252,"dataGaLocation":459},{"text":262,"config":575},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":254,"config":577},{"href":256,"dataGaName":257,"dataGaLocation":459},{"text":267,"config":579},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":581},{"href":274,"dataGaName":275,"dataGaLocation":459},{"text":277,"config":583},{"href":279,"dataGaName":280,"dataGaLocation":459},{"text":282,"config":585},{"href":284,"dataGaName":285,"dataGaLocation":459},{"title":300,"links":587},[588,590,592,594,596,598,600,604,609,611,613,615],{"text":307,"config":589},{"href":309,"dataGaName":302,"dataGaLocation":459},{"text":312,"config":591},{"href":314,"dataGaName":315,"dataGaLocation":459},{"text":320,"config":593},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":595},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":330,"config":597},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":335,"config":599},{"href":337,"dataGaName":338,"dataGaLocation":459},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":459},"/sustainability/",{"text":605,"config":606},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":607,"dataGaName":608,"dataGaLocation":459},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":610},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":350,"config":612},{"href":352,"dataGaName":353,"dataGaLocation":459},{"text":355,"config":614},{"href":357,"dataGaName":358,"dataGaLocation":459},{"text":616,"config":617},"現代奴隷制の透明性に関する声明",{"href":618,"dataGaName":619,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":36,"links":621},[622,624,626,628,633,638,643],{"text":36,"config":623},{"href":38,"dataGaName":39,"dataGaLocation":459},{"text":368,"config":625},{"href":370,"dataGaName":371,"dataGaLocation":459},{"text":373,"config":627},{"href":375,"dataGaName":376,"dataGaLocation":459},{"text":629,"config":630},"ステータス",{"href":631,"dataGaName":632,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":634,"config":635},"利用規約",{"href":636,"dataGaName":637,"dataGaLocation":459},"/terms/","terms of use",{"text":639,"config":640},"プライバシーに関する声明",{"href":641,"dataGaName":642,"dataGaLocation":459},"/ja-jp/privacy/","privacy statement",{"text":644,"config":645},"Cookieの設定",{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":92},"cookie preferences","ot-sdk-btn",{"items":649},[650,652,654],{"text":634,"config":651},{"href":636,"dataGaName":637,"dataGaLocation":459},{"text":639,"config":653},{"href":641,"dataGaName":642,"dataGaLocation":459},{"text":644,"config":655},{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":92},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",[661,687,709,729,750,773,794,813,832,851,871,891,911,931,951,973,992,1011,1029,1047,1067,1083,1101,1121,1140,1158,1176,1198,1216,1237,1257,1281,1300,1317,1337,1355,1375,1397,1418,1438,1457,1476,1497,1517,1536,1555,1573,1595,1615,1633,1653,1673,1692,1713,1732,1750,1770,1789,1811,1831,1850,1868,1887,1906,1926,1944,1966,1986,2006,2026,2046,2065,2084,2103,2123,2143,2166,2188,2208,2228,2247,2266,2286,2306,2326,2346,2364,2386,2405,2424,2444,2464,2483,2501,2520,2540,2559,2579,2599,2619,2638,2657,2678,2697,2716,2736,2755,2772,2791,2810,2829,2850,2870,2890,2911,2931,2951,2971,2991,3012,3031,3050,3070,3091,3110,3129,3148,3167,3187,3206,3225,3244,3265,3287,3306,3325,3343,3364,3382,3403,3424,3443,3462,3480,3499,3520,3538,3559,3579,3599,3618,3637,3657,3678,3698,3719,3740,3759,3778,3800,3820,3841,3862,3883,3903,3924,3943,3963,3986,4006,4027],{"_path":662,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":663,"content":668,"config":680,"_id":683,"_type":16,"title":684,"_source":17,"_file":685,"_stem":686,"_extension":20},"/ja-jp/blog/what-is-gantt-chart",{"config":664,"ogImage":665,"title":666,"description":667},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988342/gqogwxai28zzwwuj2z3i.jpg","ガントチャートとは？ソフト開発における役割やメリット、作り方","ガントチャートとは何か、作り方やメリットを詳しく解説。プロジェクト管理に役立つおすすめツールも紹介します。",{"heroImage":665,"date":669,"authors":670,"category":672,"body":673,"tags":674,"title":679,"description":667},"2025-09-16",[671],"GitLab Team","engineering","ソフトウェア開発におけるプロジェクト管理を円滑に行うには「ガントチャート」の活用が役立ちます。実際に自社の開発プロジェクトにおいて複雑で多岐にわたるプロセス管理に課題を感じており、ガントチャートの活用を検討している人もいるのではないでしょうか。\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)",[675,676,677,678],"collaboration","tutorial","workflow","features","ガントチャートとは？ソフトウェア開発における役割やメリット、作り方",{"featured":6,"template":681,"slug":682},"BlogPost","what-is-gantt-chart","content:ja-jp:blog:what-is-gantt-chart.yml","What Is Gantt Chart","ja-jp/blog/what-is-gantt-chart.yml","ja-jp/blog/what-is-gantt-chart",{"_path":688,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":689,"content":692,"config":703,"_id":705,"_type":16,"title":706,"_source":17,"_file":707,"_stem":708,"_extension":20},"/ja-jp/blog/gitlab-and-accenture-announce-global-reseller-agreement",{"noIndex":6,"title":690,"description":691},"GitLabとAccentureがグローバル販売代理店契約を発表","Accentureが包括的なDevSecOpsプラットフォームの提供を可能にする販売代理店契約を締結",{"heroImage":693,"body":694,"authors":695,"updatedDate":697,"date":698,"title":690,"tags":699,"description":691,"category":700},"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の営業担当にお問い合わせください。",[696],"GitLab","2025-09-17","2025-09-15",[700,701,702],"news","product","DevSecOps",{"featured":6,"template":681,"slug":704},"gitlab-and-accenture-announce-global-reseller-agreement","content:ja-jp:blog:gitlab-and-accenture-announce-global-reseller-agreement.yml","Gitlab And Accenture Announce Global Reseller Agreement","ja-jp/blog/gitlab-and-accenture-announce-global-reseller-agreement.yml","ja-jp/blog/gitlab-and-accenture-announce-global-reseller-agreement",{"_path":710,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":711,"content":716,"config":723,"_id":725,"_type":16,"title":726,"_source":17,"_file":727,"_stem":728,"_extension":20},"/ja-jp/blog/what-is-local-llm",{"config":712,"title":713,"description":714,"ogImage":715},{"noIndex":6},"ローカルLLMとは？開発での活用メリットと注意点","ローカルLLMの意味やクラウドLLMとの違い、ソフトウェア開発における導入メリットなどを解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577836/qjcz9aubvivrn4zy1kqr.jpg",{"title":713,"description":714,"authors":717,"heroImage":715,"date":718,"body":719,"category":672,"tags":720},[671],"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合同会社ソリューションアーキテクト本部シニアパートナーソリューションアーキテクト）*",[721,702,678,676,722],"AI/ML","security",{"featured":6,"template":681,"slug":724},"what-is-local-llm","content:ja-jp:blog:what-is-local-llm.yml","What Is Local Llm","ja-jp/blog/what-is-local-llm.yml","ja-jp/blog/what-is-local-llm",{"_path":730,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":731,"content":735,"config":744,"_id":746,"_type":16,"title":747,"_source":17,"_file":748,"_stem":749,"_extension":20},"/ja-jp/blog/event-report-gartner-security-risk-management-2025",{"noIndex":6,"title":732,"ogTitle":732,"description":733,"ogImage":734},"コード生成AIのリスク管理とポテンシャル最大化【レポート】","ガートナー セキュリティ＆リスク・マネジメントサミット2025で登壇したGitLab吉瀬 淳一のセッション内容をレポート。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480526/wk05yajf5e4bmwuygve7.jpg",{"date":736,"authors":737,"title":739,"description":733,"heroImage":734,"category":740,"tags":741,"body":743},"2025-09-10",[738],"GitLab Japan Team","コード生成AIのリスクを管理し、ポテンシャルを最大限に引き出す【イベントレポート】","devsecops",[721,742,702,280,722],"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":92,"template":681,"slug":745},"event-report-gartner-security-risk-management-2025","content:ja-jp:blog:event-report-gartner-security-risk-management-2025.yml","Event Report Gartner Security Risk Management 2025","ja-jp/blog/event-report-gartner-security-risk-management-2025.yml","ja-jp/blog/event-report-gartner-security-risk-management-2025",{"_path":751,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":752,"content":757,"config":767,"_id":769,"_type":16,"title":770,"_source":17,"_file":771,"_stem":772,"_extension":20},"/ja-jp/blog/monday-merge-2025-september-8",{"config":753,"title":754,"ogImage":755,"description":756},{"noIndex":6},"Monday Merge 9月号","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756904278/ov1n66vq8dnikcjyu0iw.png","最新リリース、注目のホワイトペーパー、そして大規模なDevSecOpsの取り組み事例をお届け。",{"title":758,"authors":759,"heroImage":755,"date":760,"category":700,"tags":761,"body":765,"description":766},"Monday Merge 9月号：より速いパイプライン、もっと賢いエージェント、そしてより大きな成果を！",[738],"2025-09-08",[721,110,675,270,762,702,280,678,700,763,722,764],"customers","releases","user stories","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":681,"slug":768},"monday-merge-2025-september-8","content:ja-jp:blog:monday-merge-2025-september-8.yml","Monday Merge 2025 September 8","ja-jp/blog/monday-merge-2025-september-8.yml","ja-jp/blog/monday-merge-2025-september-8",{"_path":774,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":775,"content":779,"config":788,"_id":790,"_type":16,"title":791,"_source":17,"_file":792,"_stem":793,"_extension":20},"/ja-jp/blog/vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow",{"config":776,"title":777,"description":778},{"noIndex":6},"GitLab Duo Agent Platform：イシューからMRフロー","デベロッパーが数分でアイデアを実際のコードに変換。最新のエージェントフローでアプリケーションを素早く更新する方法をご紹介します。",{"heroImage":780,"body":781,"authors":782,"updatedDate":784,"date":785,"title":777,"tags":786,"description":778,"category":787},"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",[783],"Cesar Saavedra","2025-09-05","2025-09-03",[721,701,678,676],"ai-ml",{"featured":92,"template":681,"slug":789},"vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow","content:ja-jp:blog:vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow.yml","Vibe Coding With Gitlab Duo Agent Platform Issue To Mr Flow","ja-jp/blog/vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow.yml","ja-jp/blog/vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow",{"_path":795,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":796,"content":800,"config":807,"_id":809,"_type":16,"title":810,"_source":17,"_file":811,"_stem":812,"_extension":20},"/ja-jp/blog/gitlab-achieves-iso-iec-42001-certification-for-ai-governance",{"config":797,"title":798,"description":799},{"noIndex":6},"GitLabがAIガバナンスでISO/IEC 42001認証を取得","この新しいISO認証、関連するGitLab Duo機能、および責任あるAI開発への取り組みについて詳しく解説します。",{"heroImage":801,"body":802,"authors":803,"updatedDate":785,"date":805,"title":798,"tags":806,"description":799,"category":787},"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/)のドキュメントをご確認ください。",[804],"Davoud Tu","2025-09-02",[700,721,701],{"featured":92,"template":681,"slug":808},"gitlab-achieves-iso-iec-42001-certification-for-ai-governance","content:ja-jp:blog:gitlab-achieves-iso-iec-42001-certification-for-ai-governance.yml","Gitlab Achieves Iso Iec 42001 Certification For Ai Governance","ja-jp/blog/gitlab-achieves-iso-iec-42001-certification-for-ai-governance.yml","ja-jp/blog/gitlab-achieves-iso-iec-42001-certification-for-ai-governance",{"_path":814,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":815,"content":819,"config":826,"_id":828,"_type":16,"title":829,"_source":17,"_file":830,"_stem":831,"_extension":20},"/ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"config":816,"title":817,"description":818},{"noIndex":6},"DevSecOpsにおける企業の独立性がこれまで以上に重要な理由","開発インフラを誰がコントロールしているのか、リーダーたちが疑問を持つ中、GitLabの独立性と透明性の優位性はかつてないほど注目されています。",{"heroImage":820,"body":821,"authors":822,"updatedDate":785,"date":805,"title":817,"tags":824,"description":818,"category":787},"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/)",[823],"Robin Schulman",[721,702,701,678,825],"open source",{"featured":92,"template":681,"slug":827},"why-enterprise-independence-matters-more-than-ever-in-devsecops","content:ja-jp:blog:why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","Why Enterprise Independence Matters More Than Ever In Devsecops","ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"_path":833,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":834,"content":839,"config":845,"_id":847,"_type":16,"title":848,"_source":17,"_file":849,"_stem":850,"_extension":20},"/ja-jp/blog/what-is-vm",{"config":835,"title":836,"ogTitle":836,"description":837,"ogDescription":837,"ogImage":838},{"noIndex":6},"仮想マシン(VM)とは？意味や導入メリット","VM（仮想マシン）の基礎知識から開発・インフラでの導入メリット、具体的な活用方法まで詳しく解説","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347347/ocydmzmnj23eitgoiwzb.jpg",{"title":840,"description":841,"authors":842,"heroImage":838,"date":843,"body":844,"category":672},"仮想マシン（VM）とは？意味や導入メリット、GitLab活用例","この記事では、仮想マシンの基礎知識からソフトウェア開発・ITインフラの領域で導入するメリット、具体的な活用方法まで解説します。",[671],"2025-08-28","仮想マシン（VM）は、IT技術が進化する時代の中でソフトウェア開発やビジネスの領域において近年注目されている技術の一つです。実際に自社のソフトウェア開発の領域において、仮想マシンの導入を検討している人も多いのではないでしょうか。仮想マシンを自社の開発に取り入れて確かな効果を発揮するためには、仮想マシンの特徴などを事前に詳しく理解しておく必要があります。\n\nこの記事では、仮想マシンの基礎知識からソフトウェア開発・ITインフラの領域で導入するメリット、具体的な活用方法まで解説するのでぜひ参考にしてください。\n\n## 1. 仮想マシン（VM）の基礎知識\n\n![仮想マシン（VM）の基礎知識](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347363/iwp4fwdv8jubfrclmvdk.jpg)\n\nまずは、仮想マシンを理解するために知っておきたい仮想化と呼ばれる技術の概要や、仮想マシンの特徴について解説します。\n\n### 1-1 そもそも仮想化とは\n\n仮想化とは、物理的な環境に囚われずにサーバー、ストレージ、ネットワーク、メモリなどのハードウェアリソースを効率よく利用するための技術のことです。\n\nよりわかりやすく簡潔に説明すると、仮想化とは本来1つであるハードウェアリソースを複数あるかのように利用する技術です。この仮想化技術は現代の企業のIT戦略を検討する上で重要な位置付けとなっています。\n\n### 1-2 仮想マシン（VM）とは\n\n![仮想マシン（VM）とは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347364/gao2azgosxdb60yoblno.jpg)\n\nでは、この記事の本題である仮想マシンについて説明します。仮想マシンとは、仮想化技術を活用して1つの物理マシン内（コンピューター）に仮想的に複数のコンピューターを再現する環境のことです。\n\n物理マシンは実体として存在するコンピューターであるのに対して、仮想マシンはソフトウェアを利用して物理マシン内に仮想的に再現したコンピューターであるという違いを理解しておくと良いでしょう。\n\nつまり、仮想マシンなら1台のコンピューター上で複数のOSをそれぞれ独立した状態で稼働できるようになります。後にも詳しく解説しますが、これによりサーバー台数の節約やニーズに応じたOSの稼働などができるようになり、開発やビジネスにおけるコスト削減や生産性向上にも寄与します。\n\n## 2 仮想マシン（VM）におけるホストOSとゲストOS\n\n![仮想マシン（VM）におけるホストOSとゲストOS](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347365/rn4rccmpfjwm4wj2klkl.jpg)\n\n仮想マシンを語る上では、「ホストOS」と「ゲストOS」という言葉の意味についても理解しておく必要があります。\n\nまずホストOSとは、仮想マシンを構築する際の土台となるOSを指します。つまり、実体のある物理マシンにインストールされているOSです。一方、ゲストOSは仮想マシンにインストールするOSのことです。\n\n例えば、Windowsのコンピューターに対して仮想環境を作成して、Linuxをインストールすれば、ホストOSはWindows、ゲストOSはLinuxとなります。このようなホストOSとゲストOSの関係性は業務上でも使われるため、違いを把握しておくと良いでしょう。\n\n## 3 仮想マシン（VM）の歴史\n\n![仮想マシン（VM）の歴史](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347363/g17rmmdu1jh0jm9ueglu.jpg)\n\n仮想マシンは近年注目されている技術の一つですが、歴史自体は古く、1960年代には既に使用されていました。当時のコンピューターリソースを複数のユーザーで使用するための「タイムシェアリング」という技術が仮想化の起源だと言われています。\n\nその後、時代の流れと共にIT技術が発展し、コンピューターの価格低下も実現できたことから物理的に台数を増やして運用するという考えが広まりました。しかしそれでは企業にとって運用負荷が増加してしまうという課題が残るため、仮想化技術が再び注目されるようになっているのです。\n\n※参考：[「仮想化」を理解するための誕生の歴史 | ITソリューション塾](https://blogs.itmedia.co.jp/itsolutionjuku/2014/06/post-9f0b.html)\n\n## 4 仮想マシンの主な利用シーン\n\n![仮想マシンの主な利用シーン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347368/vc1gzpcdyqmym44t92fl.jpg)\n\n仮想マシンは具体的にどのようなシーンで利用できるのでしょうか。具体例として以下が挙げられます。\n\n* ソフトウェア開発・テスト\n* 新しいOSのテスト\n* ソフトウェア・アプリケーションの実行\n* セキュアなWebブラウジング\n\n### 4-1 ソフトウェア開発・テスト\n\n仮想マシンはソフトウェア開発・テストの領域で役立てられます。仮想マシンを使って本番とは隔離された環境で開発を行えば、開発途中でなんらかのトラブルが発生した場合でも影響を最小限に抑えられるでしょう。また、複数の異なるOSを構築できるため、アプリケーションの互換性テストを容易に実行することが可能です。\n\n### 4-2 新しいOSのテスト\n\n企業が業務改善やビジネス上の戦略を理由に既存のOSから新しいOSへの移行を検討するケースもあるでしょう。しかし、使い慣れた環境から新しい環境へ切り替えを行う際には、既存のアプリケーションや周辺機器の互換性・操作性などを細かにチェックしなければなりません。\n\n事前に仮想マシンを使用して移行予定のOSを試せば、移行後の業務への影響度を事前に把握できるでしょう。\n\n### 4-3 ソフトウェア・アプリケーションの実行\n\n業務を進める上で状況によっては、現在利用しているOSでは動作しないソフトウェアやアプリケーションの実行が必要になるケースもあるでしょう。\n\nそういったケースでも仮想マシンを使えばソフトウェアやアプリケーションの実行に必要となるOSを柔軟にインストールできるため、業務に支障が出ることなく仕事を進められるでしょう。\n\n### 4-4 セキュアなWebブラウジング\n\nWebブラウジングを行う際にも仮想マシンを活用できます。Webブラウジングとは、Webブラウザを利用してWebサイトやホームページなどの情報を閲覧することです。\n\nウイルス感染のリスクが高いサイトも存在する中で、仮想マシンを使って隔離されたセキュアな環境でWebブラウジングを行えば、企業におけるセキュリティリスクを軽減できます。\n\n## 5 仮想マシン（VM）を実行するソフトウェアの種類\n\n![仮想マシン（VM）を実行するソフトウェアの種類](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347364/vzsuhsyjxh38dmdmwios.jpg)\n\n仮想マシンを実行するためにはソフトウェアが必要になりますが、主に以下の種類に分けられます。\n\n* ホストOS型\n* ハイパーバイザーOS型\n\n### 5-1 ホストOS型\n\nホストOS型とは、先ほど解説したホストOS上に仮想化ソフトウェアをインストールして仮想マシンを構築する方法になります。\n\n以下からホストOS型を採用するメリットやデメリット、代表的な仮想化ソフトウェアを紹介します。\n\n#### ５−１−１ ホストOS型のメリット・デメリット\n\nホストOS型のメリットは、既に利用しているOS上にソフトウェアをインストールするだけで仮想マシンを実現できるため、扱いやすく容易に導入できることです。そのため、まずは仮想環境に触れてみたいといったテスト用途や、個人学習用途などで利用することが可能です。\n\nしかし、ホストOS型の場合は物理マシンと仮想マシンとの間にホストOSが介入することになり、本来の処理に加えて余分なリソースがかかる「オーバーヘッド」と呼ばれる現象が発生します。そのため、高速な処理には不向きな手段であることを把握しておかなければなりません。\n\n#### ５−１−２ 代表的な仮想化ソフトウェア\n\nホスト型の仮想化ソフトウェアの例としては以下が挙げられます。\n\n・Oracle VM VirtualBox\n\nVirtualBoxは、Oracle社が提供する人気の仮想化ソフトウェアです。多機能であることが特徴で、「スナップショット」「シームレスモード」「共有フォルダ」など仮想マシンを活用する上で便利な機能が搭載されています。\n\n・VMware Fusion Pro\n\nVMware Fusion Proは、Mac上で仮想マシンを構築し異なるOSを実行できる仮想化ソフトウェアです。ファイル共有などさまざまな機能が提供されています。\n\n### 5-2 ハイパーバイザー型\n\nハイパーバイザー型とは、ホストOSを使わず、ハイパーバイザーと呼ばれる専用の仮想化ソフトウェアをインストールして仮想環境を構築する方法です。以下からハイパーバイザーOS型のメリットやデメリット、代表的なソフトウェアを紹介します。\n\n#### ５−２−１ ハイパーバイザー型のメリット・デメリット\n\nハイパーバイザー型のメリットは、ホストOSを使わずに仮想マシンを構築するため、ホストOS型と比較してオーバーヘッドが少なく高速な処理が期待できます。\n\nただし、既存の物理マシンでハイパーバイザーを使用できない場合は、新たに互換性のある物理マシンを購入する必要があり、そのための費用を用意しなければなりません。また、ホスト型OSと比べて導入や管理においてある程度の専門知識が求められます。\n\nホストOS型とハイパーバイザー型の特徴の比較を以下の表でまとめました。\n\n![ハイパーバイザー型のメリット・デメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756349540/bab2vb3tws84ftqtrj6x.jpg)\n\n#### ５−２−２ 代表的なハイパーバイザー\n\n代表的なハイパーバイザーには以下のようなものがあります。\n\n・KVM\n\nKVMは、Linuxをハイパーバイザーとして動作させることができる仮想化技術です。Linuxカーネル2.6.20以降から標準搭載されているため、Linuxを使用しているなら手軽に試せるでしょう。\n\n・VMware ESXi\n\nVMware ESXiは、 VMware が提供しているソフトウェアです。ESXiファイアウォールによりアクセス制限が可能でセキュリティにも強みを持っているのが特徴です。\n\n・Citrix Hypervisor\n\nCitrix Hypervisorは、 Citrix社が提供する仮想化プラットフォームです。Xen Projectをベースとしており、高性能なハイパーバイザーで信頼性が高いことが特徴です。\n\n## 6 仮想マシンとコンテナの違い\n\n![仮想マシンとコンテナの違い](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347368/bq7nkfayq63ltttxhlmb.jpg)\n\n仮想化手法においては「コンテナ」と呼ばれる技術もあるため、仮想マシンとの違いを理解しておきましょう。\n\n### 6-1 コンテナとは？\n\n![コンテナとは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347369/cdzvsfyrdh1qc8uctash.jpg)\n\nコンテナとは、アプリケーションを実行するための動作環境を仮想化して利用する技術のことです。\n\n仮想マシンは、物理マシン内に仮想化ソフトウェアを利用して複数の異なるOS（ゲストOS）を構築します。一方、コンテナは、「コンテナエンジン」と呼ばれるコンテナを管理するソフトウェアがOSとして機能するため、ゲストOSは不要になります。\n\n代表的なコンテナエンジンは、「Docker」になります。Dockerを活用すれば、複数のアプリケーションの実行環境を手軽に作成できます。\n\n### 6-2 コンテナの特徴\n\nコンテナは先ほども解説した通りゲストOSが不要であるため、必要最低限のリソースで運用することができコスト削減につながります。また、処理速度も速いことから効率的な運用を実現できるでしょう。\n\nしかし、コンテナの場合はOSが限定されるため、複数の異なるOSを利用できる仮想マシンのような自由度は期待できません。例えば、ソフトウェア開発において異なる種類の環境でテストを実行したい場合には適していない手段だと言えます。また、コンテナはコマンド操作や管理方法など初期で覚えることも多いため、スムーズな導入を実現するためには学習環境や運用体制を構築しておく必要があります。\n\n## 7 ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するメリット\n\n![ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347365/kk7vgdomzo4quorhjs8v.jpg)\n\nここではソフトウェア開発とITインフラの領域に焦点を当てて、仮想マシン（VM）を導入するメリットについて解説します。\n\n* IT・開発コストの削減\n* 開発・テスト環境構築の迅速化\n* 複数OSの活用による効率性の向上\n* DevSecOpsのサポート\n* セキュリティリスクの軽減\n* 可用性の向上とBCP対策への貢献\n\n### 7-1 IT・開発コストの削減\n\n仮想マシンを導入することで、物理的なハードウェアリソースを論理的に分割する形で共有できるため、コスト削減につながります。複数OSの稼働が必要になった場合に、仮想環境を構築せずに物理的にリソースを準備するとなると、コンピューターの購入費や管理費などさまざまなコストが追加で発生してしまいます。\n\n仮想マシンなら、ハードウェアリソースを効率よく有効活用できるため、ソフトウェア開発・ITインフラの領域でも追加コストの発生を最小限に抑えられます。\n\n### 7-2 開発・テスト環境構築の迅速化\n\n仮想マシンは開発・テスト環境構築の迅速化にもつなげられます。開発者は簡単に仮想環境を作成できるようになるため、需要に応じて開発・テスト環境を瞬時にスピンアップできます。また、使用しない時にも素早くテイクダウンが可能です。\n\n本来であれば開発・テスト環境を構築する際には物理的な作業が発生し、時間を要します。柔軟性と拡張性を持つ仮想マシンなら、急なニーズが発生した場合でも物理的な作業を省略できるため、状況の変化に応じたスピーディーな対応が可能です。\n\n### 7-3 複数OSの活用による効率性の向上\n\n仮想マシンなら1つの物理マシン上で異なる複数のOSを運用できます。時間やコストをかけることなく、必要な時にゲストOSとして構築するだけでさまざまな環境でソフトウェアの開発やテストを実行することが可能です。例えば、WindowsとLinuxを同時に起動してアプリケーションの互換性をチェックするなどの対応が可能です。\n\n複数OSの活用によって開発やテストの効率性向上を実現できるでしょう。\n\n### 7-4 DevSecOpsのサポート\n\nDevSecOpsとは、開発（Dev）、セキュリティ（Sec）、運用（Ops）の3つの概念を組み合わせたアプローチのことを指します。開発サイクルにおいて開発からセキュリティ、運用までを連携して進めることでセキュリティ強化や開発スピードの向上につなげられます。\n\n仮想マシンの導入はこのDevSecOpsのサポートやツールチェーンの合理化にも貢献します。例えば、開発プロセスにおいて仮想マシンを作成し、仮想マシン上にCI/CDのような自動化されたワークフローを取り入れることで独立した環境で実行基盤を構築できます。\n\n### 7-5 セキュリティリスクの軽減\n\n仮想マシンはそれぞれ独立した環境で互いに分離された形で運用され、かつホストシステム（物理的なコンピューター）からも隔離されているため、セキュリティ対策にも役立ちます。\n\n例えば、1つの仮想マシンでセキュリティトラブルが発生した場合でも、他の仮想マシンやホストシステムへの影響を抑えやすいでしょう。ただし、環境分離によるセキュリティリスクの軽減は期待できるものの、トラブルが発生する可能性をゼロにできるわけではありません。仮想環境特有のセキュリティ対策も徹底し、より安全に運用できる体制を構築する必要があります。これについては後述します。\n\n### 7-6 可用性の向上とBCP対策への貢献\n\n仮想マシンは障害にも強く、システムの可用性を高めることも可能です。例えば、現在の仮想マシンの状態を保存・復元できる「スナップショット機能」を活用すれば、システム障害が発生した場合でも容易に以前の状態に戻すことが可能です。\n\nまた、稼働中の仮想マシンを継続したまま別のホストに移行できる「ライブマイグレーション機能」なら、安全性の高いホストへ移動させることで事前にシステムトラブルを回避できるでしょう。\n\n## 8 ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するデメリット\n\n![ソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入するデメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347369/d5zasrxf7krbjy2umv2s.jpg)\n\nソフトウェア開発・ITインフラの領域で仮想マシン（VM）を導入する際には以下のようなデメリットもあるため、事前に把握しておくことが大切です。\n\n* パフォーマンス低下の可能性\n* 仮想環境の導入・管理における専門性が高い\n* 仮想環境特有のセキュリティ対策が必要\n* 障害時の対応が増える場合がある\n\n### 8-1 パフォーマンス低下の可能性\n\n仮想マシンは物理的なコンピューターと比較すると性能面で劣る場合があるため、開発時に処理に時間がかかってしまったりなど不便さを感じてしまうかもしれません。例えば、オーバーヘッドが発生すると余分なリソースがかかり、処理速度に影響を与えてしまうでしょう。\n\n特に安定した作業環境が強く求められるシーンにおいては、適切なリソース配分を検討する、状況に応じて物理的なコンピューターを用意して利用するといった対策が必要になります。\n\n### 8-2 仮想環境の導入・管理における専門性が高い\n\n仮想マシンをスムーズに導入し、安定した運用を実現するためには専門的な知識や技術が求められます。次で詳しく触れますが仮想環境においても特有のセキュリティ対策が必要になり、専門知識を持った担当者がいないと十分な対策はできないでしょう。\n\n自社に専門知識を持った人材がいない場合は、新たに確保したり、対象者を教育しなければなりません。そのためには採用・教育コストが発生することも把握しておくことが大切です。\n\n### 8-3 仮想環境特有のセキュリティ対策が必要\n\n仮想マシンに対してもセキュリティリスクは存在するため、仮想環境特有のセキュリティ対策は必要になります。例えば、基盤となる物理マシンやホストOSだけでなく、仮想マシンにも専用のセキュリティソフトを導入することが大切です。また、複数の仮想環境を運用する場合は対策や管理に抜け漏れがないよう注意しなければなりません。\n\nその他、万が一セキュリティトラブルが発生した場合の対応フローを事前に整備しておくことも大切です。\n\n### 8-4 障害時の対応が増える場合がある\n\n仮想マシンは1つの物理マシン上で利用されるため、物理マシンに障害が発生した場合、稼働している全てのシステムに影響が出る可能性もあります。これは単一障害点（SPOF）と呼ばれるものですが、もし発生した場合は復旧対応に時間や手間、そして金銭的なコストがかかってしまうでしょう。\n\n単一障害点を回避するためには、事前に仮想環境基盤の冗長化を検討しておく必要があります。\n\n## 9 仮想マシン（VM）の一般的な設定手順　\n\n![仮想マシン（VM）の一般的な設定手順](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347369/ivi8vlejqodcfecyl1b9.jpg)\n\n仮想マシンの一般的な設定手順は以下になります。\n\n1. 仮想化ソフトウェアの選定\n2. ゲストOSのインストール\n3. ネットワークの設定・データ共有\n\nまずは仮想マシンを導入する上で仮想化ソフトウェアの選定を行う必要があります。先ほど紹介したようにソフトウェアには「 VM VirtualBox」や「KMV」などがあるため、特徴を把握して自社の要件に合ったものを選びましょう。\n\n仮想化ソフトウェアを選定してインストールした後は、ゲストOSのインストールも行いましょう。最後にネットワーク設定や必要に応じてホストOSとのデータ共有などを行い運用します。\n\n## 10 仮想マシン（VM）でのGitLab活用例・使い方\n\n![仮想マシン（VM）でのGitLab活用例・使い方](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347369/entroriird3lryl3zpr3.png)\n\n仮想マシンは[GitLab](https://about.gitlab.com/ja-jp/)のようなCI/CDツールと連携が可能で、DevSecOpsの推進にもつなげられます。GitLabでのCI/CDプロセスを実行する環境として仮想マシンを有効活用できます。\n\nここでは、GitLabのサービス紹介や、仮想マシン上でGitLabを使用するメリットなどを解説します。\n\n### 10-1 GitLabとは？\n\nGitLabは、ネイティブAIを搭載したソフトウェア開発のライフサイクル全体を網羅するDevSecOpsプラットフォームです。ソフトウェア構築における計画から開発、テスト、リリース、運用までを単一のプラットフォームで統合して実行することができ、ビジネスの加速化や運用負担・コストの削減につなげられます。\n\nCI/CDパイプラインの構築やセキュリティの自動化、ソースコード管理、プロジェクト管理などソフトウェア開発の効率化に役立つ充実した機能を提供しており、中小企業からエンタープライズまで世界中の多くの企業で導入されています。\n\n### 10-2 仮想マシン上でGitLabを使うメリット\n\n仮想マシン上でGitLabを利用することでどのようなメリットがあるのでしょうか。具体的には以下の通りです。\n\n* セキュアな環境で開発・テストを実行できる\n* 本番環境に近い環境でテストやビルドを行える\n* バックアップ機能やスナップショット機能でデータ復旧が容易になる\n\n#### 10-2-1 セキュアな環境で開発・テストを実行できる\n\n物理マシンとは独立した環境でGitLabを利用するため、セキュアな環境で開発やテストを実施することが可能です。仮想マシン上でトラブルが発生した場合もホストシステムへの影響を抑えられるため、セキュリティ要件が高いプロジェクトにも適しています。\n\nまた、仮想マシンなら常にクリーンな状態の環境を用意できるため、GitLabのCI/CDプロセスにおいて正確なテストやビルドが可能になります。\n\n#### 10-2−2 本番環境と同じ環境でテストやビルドを行える\n\n仮想マシンなら複数の異なるOSを用意できるため、例えばCI/CDプロセスにおいて本番環境を再現して動作確認やテストができるようになります。状況に合わせてさまざまな条件下で使用することで環境の違いによる不具合をリリース前に検出しやすくなるでしょう。\n\n#### 10-2-3 バックアップ機能やスナップショット機能でデータ復旧が容易になる\n\n仮想マシンのスナップショット機能を活用すればデータのバックアップを容易にとることができ、障害時の復旧にも役立てられます。また、GitLabにはバックアップ機能が搭載されているため、より安全なシステム運用を実現できるでしょう。\n\n## まとめ 仮想マシン（VM）の活用で開発効率の向上を図ろう\n\n仮想マシンは近年注目されている技術であり、ソフトウェア開発やITインフラの領域でも積極的に活用することで開発効率の向上やコスト削減、セキュリティ対策などにつながります。\n\nDevSecOpsプラットフォーム「[GitLab](https://about.gitlab.com/ja-jp/)」は、仮想マシン上で利用することができ、CI/CDプロセスを実行する環境として活用できます。その他、プロジェクト管理などチームでの開発を効率化できる豊富な機能が搭載されているため、ぜひ自社への導入をご検討ください。\n\n### より効率的な開発環境をお探しの方は\n\nVMの設定や管理に時間を取られることなく、すぐに開発を始めたい方には[GitLab Workspaces](https://docs.gitlab.com/user/workspace/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-vm)という選択肢があります。k8sベースの開発環境で、複雑な仮想マシンの構築作業を省略できます。\n\n> ▶︎ GitLab Workspaces について詳しく：[https://docs.gitlab.com/user/workspace/](https://docs.gitlab.com/user/workspace/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-vm)\n> 詳しくは、[当社GitLabの営業チームまでお気軽にお問い合わせ](https://about.gitlab.com/ja-jp/sales/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-vm)ください。\n\nなお、GitLabでは世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧ください。\n\n> [2024グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-vm)\n\n[](https://about.gitlab.com/ja-jp/developer-survey/)*監修：知念 梨果* *[@rikachinen](\u003C>)（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*",{"featured":92,"template":681,"slug":846},"what-is-vm","content:ja-jp:blog:what-is-vm.yml","What Is Vm","ja-jp/blog/what-is-vm.yml","ja-jp/blog/what-is-vm",{"_path":852,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":853,"content":859,"config":865,"_id":867,"_type":16,"title":868,"_source":17,"_file":869,"_stem":870,"_extension":20},"/ja-jp/blog/event-report-gartner-application-innovation-2025",{"config":854,"ogImage":855,"title":856,"description":857,"ogDescription":858},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1756178708/bcuxu1pffexqdzy4ebxf.jpg","みんなの銀行の内製化戦略とAIへの取り組み【イベントレポート】","2025年6月開催「Gartner Application Innovation & Business Solutions Summit 2025」の当社セッションにおいて、株式会社みんなの銀行取締役常務執行役員CIO宮本 昌明氏にご講演いただいた模様をご紹介。","Gartner Summit 2025でみんなの銀行取締役常務執行役員CIO宮本昌明氏が講演した内容を紹介。",{"title":856,"description":860,"heroImage":855,"date":861,"body":862,"category":740,"tags":863,"authors":864},"2025年6月に開催された「Gartner Application Innovation & Business Solutions Summit 2025」の当社セッションにおいて、株式会社みんなの銀行 取締役常務執行役員CIO宮本 昌明氏にご講演いただいた模様をお伝えします。","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*イベントで配られたノベルティ*",[762,721,675,702,280,552,722,764],[738],{"featured":92,"template":681,"slug":866},"event-report-gartner-application-innovation-2025","content:ja-jp:blog:event-report-gartner-application-innovation-2025.yml","Event Report Gartner Application Innovation 2025","ja-jp/blog/event-report-gartner-application-innovation-2025.yml","ja-jp/blog/event-report-gartner-application-innovation-2025",{"_path":872,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":873,"content":878,"config":885,"_id":887,"_type":16,"title":888,"_source":17,"_file":889,"_stem":890,"_extension":20},"/ja-jp/blog/gitlab-18-03-release",{"config":874,"ogImage":875,"title":876,"description":877},{"noIndex":92},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1755780180/rjsjdqp84qgmlu698wfc.png","GitLab 18.3 リリース","GitLab 18.3でリリースした最新機能をご紹介します。",{"heroImage":875,"body":879,"authors":880,"updatedDate":881,"date":882,"title":876,"tags":883,"description":884,"category":701},"本ブログは、[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\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>)",[738],"2025-08-25","2025-08-22",[763,721,701,110],"GitLab 18.3でリリースした最新機能を公開します。",{"featured":92,"template":681,"slug":886},"gitlab-18-03-release","content:ja-jp:blog:gitlab-18-03-release.yml","Gitlab 18 03 Release","ja-jp/blog/gitlab-18-03-release.yml","ja-jp/blog/gitlab-18-03-release",{"_path":892,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":893,"content":897,"config":905,"_id":907,"_type":16,"title":908,"_source":17,"_file":909,"_stem":910,"_extension":20},"/ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering",{"config":894,"title":895,"description":896},{"noIndex":6},"GitLab 18.3: ソフトウェアエンジニアリングにおけるAIオーケストレーションの拡張","強化されたフロー、エンタープライズガバナンス、シームレスなツール統合により、人間とAIのコラボレーションを進化させる方法をご紹介します。",{"heroImage":898,"body":899,"authors":900,"updatedDate":861,"date":902,"title":895,"tags":903,"description":896,"category":787},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1755711502/wuuadis1pza3zehqohcc.png","GitLabは現在、ソフトウェアライフサイクルのあらゆる段階を統合する包括的なDevSecOpsプラットフォームです。その基盤の上に、世界初のソフトウェアエンジニアリング向けAIネイティブプラットフォームへの進化を進めています。GitLabでは、ソフトウェアエンジニアリングの未来は本質的に人間とAIのコラボレーションにあると考えており、すべてのGitLabユーザーに最高のAI機能を提供したいと考えています。\n\nこの変革は、他のAI開発ツールが行っていることを超えた3つの異なるレイヤーで起こっています：\n\n![以下に示すAIネイティブ変革のスライド](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755762266/iwuugge3cxweiyvi0yjk.png)\n\n**第一に、記録システムです。** 統合データプラットフォームは、最も価値のあるデジタル資産を保持しています。これには、ソースコードと知的財産だけでなく、プロジェクト計画、バグバックログ、CI/CD構成、デプロイメント履歴、セキュリティレポート、コンプライアンスデータにまたがる豊富な非構造化データが含まれます。これにより、GitLab環境内に安全に保持され、汎用エージェントや大規模言語モデルでは利用できない、文脈データの宝庫が作成されます。\n\n**第二に、ソフトウェアコントロールプレーンとして機能します。** Gitリポジトリ、REST API、およびエンドツーエンドのソフトウェアデリバリーを支えるWebhookベースのインターフェースを通じて、最も重要なビジネスプロセスをオーケストレーションします。多くの顧客は、これを重要なビジネスプロセスが日常的に依存するティア0の依存関係として考えています。\n\n**第三に、強力なユーザーエクスペリエンスを提供します。** ほとんどのエンジニアリングチームの速度を低下させる負荷の高い頭の切り替えを排除するのに役立つ統合インターフェースを提供します。1つのプラットフォームで完全なライフサイクルの可視性とコラボレーションツールを提供することで、5,000万人以上の登録ユーザーと広大なコミュニティが、仕事を成し遂げるためにGitLabを活用しています。この専門知識により、GitLabは、既存の信頼できるワークフローを維持しながら、チームの生産性を増幅する直感的な人間とAIのコラボレーションを先駆的に開拓する独自の立場にあります。\n\n**あらゆるレイヤーにAIをネイティブに統合してプラットフォームを拡張**\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)は、これら3つのレイヤーすべてを統合し、拡張します。拡張性と相互運用性のために設計されており、顧客やパートナーがさらに価値を創造するソリューションを構築できるようにします。オープンプラットフォームアプローチは、3つのレイヤーすべてで既存のスタックに深く統合されながら、外部AIツールやシステムとのシームレスな接続性を重視しています。\n\n* まず、**ナレッジグラフ**で統合データプラットフォームを拡張しています。これは、コードと他のすべての非構造化データをインデックス化して結び付け、エージェントアクセスに特化して最適化されたものです。AIはコンテキストで成長し、これによりエージェントによる推論と推論を加速するだけでなく、より低コストで高品質なエージェントの成果を提供できると考えています。\n* 第二に、既存のコントロールプレーンに重要な**オーケストレーションレイヤー**を3つの異なる部分で追加しています：エージェントとフローがGitLab SDLCイベントのサブスクライバーとして登録できるようにし、目的別のマルチエージェントフローを可能にする新しいオーケストレーションエンジンを構築し、比類のない相互運用性のためにMCPと標準プロトコルを介してGitLabツール、エージェント、フローを公開します。\n* 最後に、ソフトウェア開発ライフサイクル全体にわたってファーストクラスのエージェントとエージェントフローを提供するために**GitLabエクスペリエンス**を拡張しています。エージェントに非同期タスクを割り当て、コメントで@メンションし、ワークフローに固有のコンテキストでカスタムエージェントを作成できるようになります。さらに重要なことに、GitLabは、サードパーティエージェントの豊富なエコシステムのロックを解除しながら、開発のあらゆる段階でネイティブエージェントを出荷しています。これにより、エージェントが人間のチームメイトと同じように自然に作業できる真の人間とAIのコラボレーションが生まれます。\n\nこのビデオで18.3以降の新機能をご覧いただくか、以下をお読みください。\n\n\u003Cdiv style=\"padding:75% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111796316?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab_18.3 Release_081925_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLab 18.3の新機能\n\n18.2では、ソフトウェア開発ライフサイクル全体でデベロッパーと協力する専門的な[AIエージェント](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-public-beta/#%E3%81%99%E3%81%90%E3%81%AB%E4%BD%BF%E3%81%88%E3%82%8B%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88)と、ソフトウェア開発フローを導入しました。これは、複数のエージェントをオーケストレーションして、エンドツーエンドでコード変更を計画、実装、テストする強力な機能です。\n\nGitLab 18.3では、拡張された統合と相互運用性、より多くのフロー、そしてソフトウェア開発ライフサイクル全体でのコンテキスト認識の強化を導入しています。\n\n### 拡張された統合と相互運用性\n\nファーストパーティのGitLabエージェントとサードパーティエージェントの豊富なエコシステムの両方を通じて、包括的なAI拡張性を提供しており、すべてがプロジェクトコンテキストとデータへの完全なアクセスを持っています。このアプローチは、これらのエージェントとGitLabのコアプラットフォーム間の高度に統合されたオーケストレーションを通じて好みのツールを選択する柔軟性を提供しながら、ネイティブのGitLabワークフローとガバナンスを維持します。チームは、主要な統合、監視、ユーザーエクスペリエンスの利点を維持しながら、強化されたAI機能を獲得します。\n\n* **MCPサーバー - ユニバーサルAI統合：** GitLabのMCP（[モデルコンテキストプロトコル](https://about.gitlab.com/topics/ai/model-context-protocol/)）サーバーにより、AIシステムはGitLabプロジェクトと開発プロセスに直接安全に統合できます。この標準化されたインターフェースにより、カスタム統合のオーバーヘッドが排除され、[Cursor](https://docs.cursor.com/en/tools/mcp)を含むAIツールが既存のGitLab環境内でインテリジェントに動作できるようになります。18.3に含まれるツールの完全なリストについては、[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/)をご覧ください。**これは始まりに過ぎません。18.4では追加のツールが計画されています。**\n\n  **注：** サードパーティエージェントは、GitLab Premiumベータ機能であり、GitLab Duo Enterpriseの顧客が評価のためにのみ利用できます。\n\n> *「GitLabワークフローをCursorに直接持ち込むことは、デベロッパーの摩擦を減らすための重要なステップです。頭の切り替えの必要性を最小限に抑えることで、チームはコーディング環境を離れることなく、イシューのステータスをチェックし、マージリクエストをレビューし、パイプラインの結果を監視できます。この統合は共有顧客にとって自然な選択であり、デベロッパーの生産性を継続的に向上させるために、GitLabとの長期的なパートナーシップを楽しみにしています。」*\n>\n> \\- **Ricky Doar、Cursor フィールドエンジニアリング副社長**\n>\n> *「GitLabのMCPサーバーとCLIエージェントサポートは、Amazon Qが開発ワークフローと統合するための強力な新しい方法を作成します。Amazon Q DeveloperはGitLabのリモートMCPインターフェースを介して直接接続できるようになり、チームはイシューやマージリクエストでAmazon Q CLIを@メンションするだけで開発タスクを委任できます。これらの統合に組み込まれた堅牢なセキュリティとガバナンス機能により、企業は開発標準を維持しながら、AIコーディングツールを活用する自信を得ることができます。GitLabとのパートナーシップは、AIエコシステムを拡大し、デベロッパーが作業する場所でインテリジェントな開発ツールにアクセスできるようにするというAWSの継続的なコミットメントを示しています。」*\n>\n> \\- **Deepak Singh、AWS デベロッパーエージェントおよびエクスペリエンス担当副社長**\n\n* **Claude Code、Codex、Amazon Q、Google Gemini、opencode（独自のキーを持参）のCLIエージェントサポート：** 18.3では、イシューやマージリクエストでエージェントを直接@メンションすることで、チームが日常的な開発作業を委任できる統合を導入しています。デベロッパーがこれらのAIアシスタントにメンションすると、周囲のコンテキストとリポジトリコードを自動的に読み取り、レビュー可能なコード変更またはインラインコメントでユーザーのコメントに応答します。これらの統合では、それぞれのAIプロバイダー用に独自のAPIキーを持参する必要があり、適切な権限と監査証跡を維持しながら、すべてのやり取りをGitLabのインターフェース内でネイティブに保持します。\n\n  **注：** サードパーティエージェントは、GitLab Premiumベータ機能であり、GitLab Duo Enterpriseの顧客が評価のためにのみ利用できます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111784124?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Third Party Agents Flows Claude Code\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> *「Claude CodeをGitLabに直接持ち込むことで、何百万人ものデベロッパーがすでに毎日コラボレーションしてコードを出荷している場所にAIアシスタンスを配置します。イシューやマージリクエストでClaudeを直接メンションする機能により、人間の監視とレビュープロセスで品質を維持しながら、摩擦が除去されます。このアップデートにより、Claude Codeの機能がチームが作業するより多くの場所に提供され、AIをデベロッパーワークフローの自然な一部にします。」*\n>\n> **\\- Cat Wu、Claude Code プロダクトリード、Anthropic**\n>\n> *「GitLab 18.3の新しいエージェント統合により、既存のワークフロー内でopencodeを使用できます。イシューやマージリクエストでopencodeを@メンションすると、CIパイプラインでエージェントが実行されます。この方法でopencodeを設定して実行する機能は、オープンソースコミュニティが本当に評価する統合のタイプです。」*\n>\n> **\\- Jay V.、CEO、opencode**\n\n* **すべてのPremiumおよびUltimate顧客が利用できるVisual Studio IDEおよびGitLab UIのエージェントチャットサポート：** 18.3では、GitLabの完全な開発ライフサイクルデータにアクセスするためにツール間で頭の切り替えをする必要がなくなりました。強化された統合により、GitLab DuoのフルパワーがGitLab UIとIDEにもたらされ、JetBrainsとVS Codeからのサポートが拡張され、現在はVisual Studioも含まれています。これにより、デベロッパーは好みの環境内で豊富なプロジェクトコンテキスト、デプロイメント履歴、チームコラボレーションデータに直接アクセスしながら、フローに留まることができます。\n* **拡張されたAIモデルサポート：** GitLab Duo Self-Hostedは追加のAIモデルをサポートするようになり、チームにAI支援開発ワークフローでより柔軟性を提供します。データセンターのハードウェア上でvLLMを介して、またはプライベートクラウドのAzure OpenAIやAWS Bedrockなどのクラウドサービスを介して、オープンソースのOpenAI GPTモデル（20Bおよび120Bパラメータ）をデプロイできるようになりました。さらに、AnthropicのClaude 4はAWS Bedrockで利用可能です。\n\n### 新しい自動開発フロー\n\nGitLabのフローは、複数のAIエージェントを事前構築された指示で調整し、時間のかかる日常的なタスクを自律的に処理するため、デベロッパーは最も重要な作業に集中できます。\n\nGitLab 18.3には2つの新しいフローが付属しています：\n\n* **概念から完成まで数分でコードを自動生成するイシューからMRへのフロー：** このFlowは、要件を分析し、包括的な実装計画を準備し、レビュー可能な本番グレードのコードを生成するためにエージェントを調整することにより、イシューを実行可能なマージリクエスト（MR）に自動的に変換します。アイデアを数時間ではなく数分でレビュー可能な実装に変えるのに役立ちます。\n\n\u003Cdiv style=\"padding:75% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111782058?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Issue to MR\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **シームレスな移行インテリジェンスのために構築されたCI File変換フロー：** CI File変換フローは、エージェントが既存のCI/CD構成を分析し、完全なパイプライン互換性を持つGitLab CI形式にインテリジェントに変換することで、移行ワークフローを合理化します。これにより、CI構成をゼロから書き直す手動作業と潜在的なエラーが排除され、チームは自信を持ってデプロイメントパイプライン全体を移行できます。18.3にはJenkins移行のサポートが含まれています。将来のリリースでは追加サポートが計画されています。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783724?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Convert to CI Flow\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### インテリジェントなコードと検索\n\nAIポイントソリューションは通常、分離されたコードスニペットへの限定的な可視性で動作しますが、GitLabのナレッジグラフは、より迅速でインテリジェントな応答を通知するための環境コンテキストをエージェントに提供します。\n\n* **リアルタイムコードインテリジェンスのためのナレッジグラフ：** 18.3では、GitLabのナレッジグラフがリアルタイムコードインデックスを提供し、より高速なコード検索を可能にし、より正確で文脈に沿った結果を提供します。コードベース全体にわたるファイル、依存関係、開発パターン間の関係を理解することにより、エージェントは人間のデベロッパーが発見するのに何時間もかかる洞察を提供するように設計されています。**これは、ナレッジグラフに計画されている強力な機能のロックを解除する最初のステップにすぎません。**\n\n### エンタープライズガバナンス\n\nAIの透明性と組織のコントロールは、チームがAI搭載開発ツールを完全に採用することを妨げる可能性のある重要な課題であり、[85%の経営幹部が、エージェント型AIが前例のないセキュリティ課題を生み出すことに同意しています](https://about.gitlab.com/software-innovation-report/)。\n\n18.3のこれらの新機能は、データガバナンス、コンプライアンス要件、AI意思決定プロセスへの可視性の必要性に関する懸念に対処するのに役立つため、組織は既存のセキュリティとポリシーフレームワーク内でAIを統合できます。\n\n* **インテリジェンスを通じた透明性のためのエージェントインサイト：** 組み込みのエージェント追跡により、エージェントの意思決定プロセスへの可視性が提供されます。ユーザーは、透明なアクティビティ追跡を通じてワークフローを最適化し、ベストプラクティスに従うことができます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783244?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agent Insights\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **Self-Hosted向けGitLab Duoコードレビュー：** これにより、厳格なデータガバナンス要件を持つ組織にGitLab Duoのインテリジェンスがもたらされ、チームが機密性の高いコードを管理された環境に保持できるようになります。\n* **柔軟なAIデプロイメントのためのハイブリッドモデル構成：** GitLab Duo Self-Hostedをご利用のお客様は、ローカルAIゲートウェイを介したセルフホステッドAIモデルとGitLabのAIゲートウェイを介したGitLabのクラウドモデルを組み合わせたハイブリッドモデル構成を使用できるようになり、さまざまな機能へのアクセスが可能になりました。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783569?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Self Hosted Models Code Review\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **OAuthサポートによるセキュリティの強化：** MCPサーバーには、完全なOAuth 2.0認証サポートが含まれるようになり、保護されたリソースと機密性の高い開発環境への安全な接続が可能になりました。この実装は、MCPのドラフトOAuth仕様に従い、認証フロー、トークン管理、動的クライアント登録を処理します。\n\n### Secure by Designプラットフォーム：スケールするガバナンス\n\n真のプラットフォームセキュリティには、開発ライフサイクルのあらゆるレイヤーにわたるガバナンス原則の一貫した適用が必要です。AI採用を安全にするのと同じセキュリティの基本（最小権限アクセス、一元化されたポリシー管理、プロアクティブな監視、きめ細かい権限）は、凝集性のある多層防御アプローチを作成するために、SDLC全体に組み込まれる必要があります。\n\nGitLab 18.3は、これらの新しいアップデートでソフトウェアサプライチェーン全体を保護するのに役立つ基盤的なコントロールを強化します：\n\n* **カスタム管理者ロール：** ブランケット管理アクセスを正確な最小権限コントロールに置き換える、きめ細かく目的に合わせた管理権限を提供します。セキュリティリスクを生み出すブランケット管理権限を付与する代わりに、組織は特定の機能に合わせたカスタマイズされたロールを作成できるようになりました。ランナーと監視を管理するプラットフォームチーム、ユーザー管理を処理するサポートチーム、ダッシュボードと使用統計にアクセスするリーダーシップなど。UIとAPIを介した完全なロールライフサイクル管理、監査ログ、自動生成されたドキュメントにより、この機能は運用効率を維持し、全体的なインスタンスセキュリティを向上させながら、真の最小権限管理を可能にします。\n* **インスタンスレベルのコンプライアンスフレームワークとセキュリティポリシー管理：** 組織は、標準化されたフレームワークとセキュリティポリシーをトップレベルグループに直接適用する権限を持つ専用のコンプライアンスグループを指定でき、すべてのサブグループとプロジェクトに自動的にカスケード適用されます。この一元化されたアプローチは、追加のローカルポリシーに対するグループの自律性を維持しながら、断片化されたポリシー管理のコンプライアンス採用ブロッカーを排除します。\n* **強化された違反レポート：** チームは、MR承認ルールに対して不正な変更が行われたとき、フレームワークポリシーに適切な承認がないとき、または時間ベースのコンプライアンスコントロールが違反されたときに、即座に通知を受け取るようになりました。違反を特定のコンプライアンスフレームワークコントロールに直接リンクすることで、チームはどの要件が違反されたかを正確に伝える実用的な洞察を得て、コンプライアンスを反応的なチェックボックスの演習から、開発とセキュリティワークフローのプロアクティブで統合された部分に変えます。\n* **CI/CDジョブトークンのきめ細かい権限：** 広範なトークンアクセスを、CI/CDジョブが実際に必要とする特定のAPIエンドポイントへのアクセスのみを付与する、きめ細かく明示的な権限に置き換えます。ジョブにプロジェクトリソースへのブランケットアクセスを許可する代わりに、チームはデプロイメント、パッケージ、リリース、環境、その他の重要なリソースに対する正確な権限を定義でき、攻撃対象領域と権限昇格の可能性を減らすことができます。\n* **AWS Secrets Manager統合：** AWS Secrets Managerを使用しているチームは、GitLab CI/CDジョブでシークレットを直接取得できるようになり、ビルドとデプロイプロセスが簡素化されます。シークレットは、OpenID Connectプロトコルベースの認証を使用してGitLab Runnerによってアクセスされ、ジョブログでの露出を防ぐためにマスクされ、使用後に破棄されます。このアプローチにより、変数にシークレットを保存する必要がなくなり、既存のGitLabおよびAWSベースのワークフローにクリーンに統合されます。Deutsche BahnおよびAWS Secrets Managerチームとの緊密な協力により開発されたこの統合は、実世界の課題を解決するためにユーザーと一緒にソリューションを構築するという当社のコミットメントを反映しています。\n\n### アーティファクト管理：ソフトウェアサプライチェーンの保護\n\nアーティファクトが適切に管理されていない場合、小さな変更が大きな結果をもたらす可能性があります。可変パッケージ、上書きされたコンテナイメージ、ツール間で一貫性のないルールは、本番障害を引き起こし、脆弱性を招き、コンプライアンスギャップを作成する可能性があります。エンタープライズDevSecOpsにとって、安全で一元化されたアーティファクト管理は、ソフトウェアサプライチェーンを維持するために不可欠です。\n\n#### 18.3のエンタープライズグレードアーティファクト保護\n\n包括的なパッケージ保護機能を基盤として、GitLab 18.3は重要な新機能を追加します：\n\n* **Conanリビジョンサポート：** 18.3の新機能である[Conanリビジョン](https://docs.gitlab.com/user/packages/conan_2_repository/#conan-revisions)は、C++デベロッパーにパッケージの不変性を提供します。パッケージのバージョンを変更せずに変更を加えた場合、Conanはこれらの変更を追跡するための一意の識別子を計算し、チームがバージョンの明確性を維持しながら不変のパッケージを維持できるようにします。\n* **強化されたコンテナレジストリセキュリティ：** 18.2での[不変コンテナタグ](https://docs.gitlab.com/user/packages/container_registry/immutable_container_tags/)のローンチ成功に続き、エンタープライズでの採用が進んでいます。不変ルールに一致するタグが作成されると、権限レベルに関係なく、誰もそのコンテナイメージを変更できなくなり、本番依存関係への意図しない変更を防ぎます。\n\nこれらの機能強化は、npm、PyPI、Maven、NuGet、Helmチャート、および汎用パッケージに対する既存の保護機能を補完し、プラットフォームチームがソフトウェアサプライチェーン全体で一貫したガバナンスを実装できるようにします。これは、安全な内部デベロッパープラットフォームを構築する組織にとって不可欠です。\n\nスタンドアロンのアーティファクトソリューションとは異なり、GitLabの統合アプローチは、コードからデプロイメントまでのエンドツーエンドのトレーサビリティを提供しながら、複数のツールを使い分ける際の頭の切り替えを排除し、プラットフォームチームがソフトウェアデリバリーパイプライン全体で一貫したガバナンスを実装できるようにします。\n\n### 埋め込みビュー：リアルタイムの可視性とレポート\n\nGitLabプロジェクトの複雑さが増すにつれて、チームは作業ステータスへの可視性を維持するために、イシュー、マージリクエスト、エピック、マイルストーン間を移動することになります。課題は、頭の切り替えやフローを中断することなく、チームがプロジェクトの進行状況にリアルタイムでアクセスできるようにしながら、この情報を効率的に統合することにあります。\n**18.3でリアルタイム作業ステータスの可視性をローンチ**\n強力な[GitLabクエリ言語（GLQL）を搭載したGitLab 18.3の埋め込みビュー](https://docs.gitlab.com/user/glql/#embedded-views)は、ライブプロジェクトデータをワークフローに直接もたらすことで、頭の切り替えを排除します：\n\n* **動的ビュー：** ページを読み込むたびに現在のプロジェクト状態で自動的に更新される、Markdownコードブロックのwikiページ、エピック、イシュー、マージリクエスト全体にライブGLQLクエリを挿入します。\n* **文脈に応じたパーソナライゼーション：** ビューは、手動設定なしで、表示している人に関連する情報を表示するために、`currentUser()`や`today()`などの関数を使用して自動的に適応します。\n* **強力なフィルタリング：** 担当者、作成者、ラベル、マイルストーン、ヘルスステータス、作成日など、25以上のフィールドでフィルタリングします。\n* **表示の柔軟性：** カスタマイズ可能なフィールド選択、アイテム制限、並べ替え順序を使用して、データをテーブル、リスト、または番号付きリストとして表示し、ビューを集中的で実行可能に保ちます。\n\n断片化されたプロジェクト管理アプローチとは異なり、埋め込みビューは、リアルタイムの可視性を提供しながらワークフローの継続性を維持するように設計されており、チームが複数のツールやインターフェース間で焦点を失ったり切り替えたりすることなく、情報に基づいた意思決定を行えるようにします。\n\n> [GitLab 18.3の最新機能](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/)について詳しく見る。\n\n## 今すぐ始める\n\nGitLab 18.3は、GitLab.comおよびセルフマネージド環境のGitLab PremiumおよびUltimateユーザーが今すぐ利用できます。\n\nGitLab Dedicatedのお客様は現在18.2にアップグレードされており、来月GitLab 18.3でリリースされた機能を使用できるようになります。\n\nソフトウェアエンジニアリングの未来を体験する準備はできましたか？[GitLab Duoのベータ版と実験的機能を有効](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)にして、完全な開発コンテキストを理解するAIエージェントとのコラボレーションを開始してください。\n\nGitLabは初めてですか？[無料トライアルを今すぐ開始](https://gitlab.com/-/trials/new)して、世界で最も包括的なDevSecOpsプラットフォームを通じてオーケストレーションされた、人間とAIのコラボレーションがソフトウェアエンジニアリングの未来である理由を発見してください。\n\n\u003Cp>\u003Csmall>\u003Cem>このブログ投稿には、1933年証券法第27A条および1934年証券取引所法第21E条の意味における「将来を見据えた声明」が含まれています。このブログ投稿に含まれる将来を見据えた声明に反映された期待は合理的であると信じていますが、実際の結果または成果が将来を見据えた声明によって表現または暗示された将来の結果または成果と実質的に異なる原因となる可能性のある既知および未知のリスク、不確実性、仮定、およびその他の要因の対象となります。\u003C/em>\u003C/p>\n\u003Cp>\u003Cem>実際の成果と結果が、このブログ投稿に含まれる、または検討される将来を見据えた声明に含まれるものと実質的に異なる原因となる可能性のあるリスク、不確実性、およびその他の要因に関する詳細情報は、証券取引委員会に提出および報告する「リスク要因」というキャプションの下およびその他の場所に含まれています。このブログ投稿の日付以降に将来を見据えた声明の改訂を更新またはリリースする義務、またはイベントや状況を報告する義務、または予期しないイベントの発生を反映する義務を負いません（法律で要求される場合を除く）。\u003C/em>\u003C/small>\u003C/p>",[901],"Bill Staples","2025-08-21",[701,721,904,678,722],"DevSecOps platform",{"featured":92,"template":681,"slug":906},"gitlab-18-3-expanding-ai-orchestration-in-software-engineering","content:ja-jp:blog:gitlab-18-3-expanding-ai-orchestration-in-software-engineering.yml","Gitlab 18 3 Expanding Ai Orchestration In Software Engineering","ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering.yml","ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering",{"_path":912,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":913,"content":917,"config":925,"_id":927,"_type":16,"title":928,"_source":17,"_file":929,"_stem":930,"_extension":20},"/ja-jp/blog/monday-merge-2025-august-11",{"config":914,"title":915,"description":916},{"noIndex":6},"Monday Merge 8月号","Monday Merge8月号では、",{"date":918,"title":915,"category":700,"tags":919,"body":921,"authors":922,"description":923,"heroImage":924},"2025-08-11",[110,721,920,675,270,762,702,280,678,700,763,722,764],"AWS","GitLabコミュニティのみなさん、こんにちは！今月もソフトウェア開発の最新トレンドをお届けします。\n\n今回のトピックはこちら：\n\n* GitLab Duo Agent Platformのパブリックベータ版がスタート：AIともっとスマートに働く方法とは\n* 現場のニーズに応える最新GitLabリリース情報\n* 世界2,786名のCレベル層に聞いた、AIとソフトウェアイノベーションに関する意識調査\n* 注目イベントやおすすめコンテンツ、NatWest社の導入事例もご紹介\n\nそれでは、さっそく見ていきましょう⚓\n\n# **GitLab Duo Agent Platform：パブリックベータ版がついに登場**\n\n![agent platform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369419/qascscd3p9azk7ros2nw.png)\n\n従来のAIアシスタントの概念を覆す新しい体験 ── GitLab Duo Agent Platformは、開発・セキュリティ・運用すべてをカバーする次世代のDevSecOpsオーケストレーションエンジンです。パブリックベータ版としての提供がスタートしました。\n\nこれは単なるIDE内のAIボットではありません。複数のAIエージェントがチームの一員として非同期に連携し、計画からリリースまでをトータルでサポートします。\n\n初期搭載されているエージェントは以下の通りです：\n\n* **Chat Agent**：自然言語での質問や汎用的な開発作業をサポート\n* **Developer Agent**：仮想開発環境でマージリクエストを作成\n* **Security Analyst Agent**：脆弱性の検出と修正提案\n* **Deep Research Agent**：リポジトリ全体を分析し、背景を踏まえたインサイトを提供\n* **Software Development Flow**：複数エージェントを連携させて一連の開発タスクを自動化\n\nGitLabのイシュー、パイプライン、CI/CDなど25以上の機能にネイティブにアクセスできるため、コンテキストを理解した精度の高い支援が可能です。さらに今後は、エージェントをカスタマイズし、複雑な作業を自動実行できる「フロー」も登場予定です。\n\nPremiumおよびUltimateプランをご利用中の方は、VS CodeやJetBrains IDEでベータ版を今すぐお試しいただけます。Web UIでも「Duo Agentic Chat」がすでに利用可能です。　\n\n▶︎ [GitLabがオーケストレーションプラットフォームとして持つ独自の強みについて、CEOのBill Staplesが語るインタビューはこちら。導入方法もあわせてご紹介しています。](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)\n\n[](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)\n\n# [](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)**GitLab企業経営調査2025：AI・信頼・7,500億ドルの可能性**\n\n![$750+B](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/i8ccbygymqgrxno9vul5.png)\n\nAIは単なるトレンドではありません。世界の開発者2,700万人がAIを活用すれば、7,500億ドル以上の価値が生まれると言われています。最新のGitLab企業経営調査2025では、世界中の経営層2,786名にAIとソフトウェア開発の未来について調査を行いました。\n\n主な調査結果：\n\n* AI活用によって、開発者1人あたり年間28,249ドルのコスト削減を実現（世界中の開発者数で見積もると7,500億ドル規模に）\n* 89％の経営者が、今後3年以内にAIエージェントが業界標準になると予想\n* 懸念点は「サイバー攻撃（52%）」「データのプライバシーとセキュリティ（51%）」「ガバナンスの維持（45%）」\n* 92％が「社員がAIと協働できるようスキルトレーニングが必要」と回答\n\n📥 [レポート全文はこちらからダウンロードできます](https://about.gitlab.com/software-innovation-report)\n\n（日本に特化したレポートは近日中に公開予定）\n\n# **GitLab 18.2がリリースされました**\n\n![GitLab 18.2 Release ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/vdubujaphpphyk2n4wnw.png)\n\nGitLab 18.2では、30以上の新機能や改善が追加され、よりスピーディーかつ安全な開発が可能に。今回のアップデートにも、GitLabコミュニティから152件の貢献が寄せられました。ありがとうございます！\n\n注目の新機能：\n\n* ✅ カスタムワークフローステータス：イシューの状態を自社の運用に合わせて柔軟に管理可能に\n* 🧭 Merge Requestページの再設計：ロールやワークフロー別に表示を最適化\n* 🔐不変コンテナタグ： 本番環境への不意な変更を防止\n\n🔗 [全リリース内容はこちら](https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/)\n\n[](https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/)\n\n# **今月のイベント情報：Black Hat USA & OSS EU**\n\n![Black Hat USA & OSS EU](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/buoqb3vmhmnsnznqquwj.png)\n\n今月はGitLabチームがイベントに登場します！\n\n📍 Black Hat USA（ラスベガス） – [詳細はこちら](https://www.blackhat.com/us-25/)[\n](https://www.blackhat.com/us-25/)\\\n📍 Open Source Summit Europe（アムステルダム） – 今月後半 👉 [登録はこちら](https://events.linuxfoundation.org/open-source-summit-europe/register/)\n\n開催地にいらっしゃる方は、ぜひお立ち寄りください！ステッカーもご用意しています。\n\n# **お客様事例：NatWest社**\n\n![NatWest](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/dr8uwztk6f1akrj7cdsp.png)\n\n金融機関NatWest社は、GitLab Duo Agent Platformを活用して開発スピードと生産性を大幅に向上させています。\n\n「GitLab Duo Agent Platformは、私たちのコードベースと組織構造を理解したうえで、AIが開発ワークフロー全体を支援してくれます。コード・テスト・CI/CDとあらゆる工程にAIが溶け込み、チームの一員として一緒に仕事している感覚があります。開発者はより創造的な仕事に集中できるようになりました」\n— NatWest社エンジニアリングプラットフォームリード Bal Kang\n\n# **今月のおすすめ記事＆動画👀**\n\n![What We're Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/mmjg9yy77orkohaureis.png)\n\nGitLabリーダーたちが語る、AI・DevSecOps・ソフトウェアセキュリティの未来。\n\n\u003Chttps://leaddev.com/reporting/the-rise-and-looming-fall-of-acceptance-rate>\n\n\u003Chttps://www.thestack.technology/a-cisos-focus-lessons-from-the-field/>\n\n\u003Chttps://www.raconteur.net/technology/agentic-ai-vibe-coding-oped>\n\n\u003Chttps://thenewstack.io/software-security-imperative-forging-a-unified-standard-of-care/>\n\n\u003Chttps://youtu.be/wZytaN-1URM>\n\n**最後に、今月の名言を**\n\n> 「知性の本当の証は知識ではなく、想像力である」\n> — アルベルト・アインシュタイン\n\n素晴らしいアイデアは、予想外の場所から生まれるものです。知識だけでなく、「想像する力」を大切にしたいですね。\n\n今月号は以上です。Duo Agent Platformはついに一般公開され、AIはC-suiteの重要議題へ、そしてMerge Requestページもさらに進化した、盛りだくさんな月でしたね。\n\nそれではまた来月、お会いしましょう！Happy Merging！\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/)｜GitLab Developer Advocate\n\n🧡 このニュースレターが気に入った方は、ぜひチームにもシェアしてください。\n 👉 [The Developer Show](https://www.linkedin.com/feed/update/urn:li:activity:7340777670714019840)の購読もお忘れなく！\n\n![Happy Merging!](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/is5jitqrtujnkmmkijlg.png)",[738],"AIエージェント、新機能、そして7,500億ドルの可能性に注目\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754368844/vagh8krfgft9cghbknod.png",{"featured":92,"template":681,"slug":926},"monday-merge-2025-august-11","content:ja-jp:blog:monday-merge-2025-august-11.yml","Monday Merge 2025 August 11","ja-jp/blog/monday-merge-2025-august-11.yml","ja-jp/blog/monday-merge-2025-august-11",{"_path":932,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":933,"content":938,"config":945,"_id":947,"_type":16,"title":948,"_source":17,"_file":949,"_stem":950,"_extension":20},"/ja-jp/blog/event-report-aws-summit-2025",{"config":934,"ogImage":935,"title":936,"description":937},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1754353906/qet5wxyn7k3dllq1jbq1.jpg","【イベントレポート】AWS Summit Japan 2025","GitLab with Amazon Qの実用レビュー。AWS Summit Japan 2025セッション報告",{"title":939,"description":940,"authors":941,"date":942,"body":943,"category":740,"heroImage":935,"tags":944},"GitLab with Amazon Qで開発スピードを高め、AI生成コードの品質を担保する【イベントレポート】","この記事ではAWS Summit Japan 2025に出展した際に「GitLab with Amazon Q」について語ったセッションの模様をお伝えします。",[738],"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のキーホルダー*",[920,721,742,675,762,702,280,722,764],{"featured":92,"template":681,"slug":946},"event-report-aws-summit-2025","content:ja-jp:blog:event-report-aws-summit-2025.yml","Event Report Aws Summit 2025","ja-jp/blog/event-report-aws-summit-2025.yml","ja-jp/blog/event-report-aws-summit-2025",{"_path":952,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":953,"content":958,"config":967,"_id":969,"_type":16,"title":970,"_source":17,"_file":971,"_stem":972,"_extension":20},"/ja-jp/blog/git-merge-command-overview",{"config":954,"title":955,"description":956,"ogImage":957},{"noIndex":6},"git mergeコマンドの基本を徹底解説 | GitLab","git merge コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg",{"date":959,"heroImage":957,"title":960,"authors":961,"category":962,"body":963,"description":964,"tags":965},"2025-08-04","git mergeコマンドの基本を徹底解説",[671],"open-source","## 目次\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コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[675,966,676,677],"git",{"featured":92,"template":681,"slug":968},"git-merge-command-overview","content:ja-jp:blog:git-merge-command-overview.yml","Git Merge Command Overview","ja-jp/blog/git-merge-command-overview.yml","ja-jp/blog/git-merge-command-overview",{"_path":974,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":975,"content":978,"config":986,"_id":988,"_type":16,"title":989,"_source":17,"_file":990,"_stem":991,"_extension":20},"/ja-jp/blog/software-supply-chain-security-guide-why-organizations-struggle",{"noIndex":6,"title":976,"description":977},"ソフトウェアサプライチェーンのセキュリティガイド：組織が直面する課題とは","この新シリーズの第1部では、すべての開発チームが理解すべき、基本的な課題、実践的な解決策、そしてAIを含む新たなトレンドを探ります。",{"title":976,"description":977,"authors":979,"heroImage":981,"date":982,"body":983,"category":722,"tags":984},[980],"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","2025-07-24","大抵の開発チームは、サプライチェーンセキュリティについて尋ねられると、脆弱性スキャンや依存関係の管理を挙げるでしょう。確かにそれらはサプライチェーンセキュリティの構成要素ではありますが、実際の課題のごく一部であり、その視点は非常に限定的で、危険です。\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/)をご覧ください。",[127,91,985],"チュートリアル",{"featured":92,"template":681,"slug":987},"software-supply-chain-security-guide-why-organizations-struggle","content:ja-jp:blog:software-supply-chain-security-guide-why-organizations-struggle.yml","Software Supply Chain Security Guide Why Organizations Struggle","ja-jp/blog/software-supply-chain-security-guide-why-organizations-struggle.yml","ja-jp/blog/software-supply-chain-security-guide-why-organizations-struggle",{"_path":993,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":994,"content":999,"config":1005,"_id":1007,"_type":16,"title":1008,"_source":17,"_file":1009,"_stem":1010,"_extension":20},"/ja-jp/blog/gitlab-18-02-release",{"noIndex":6,"ogImage":995,"title":996,"description":997,"config":998},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752817693/gr3miapxfam57ksgivgi.png","GitLab 18.2 リリース","GitLab 18.2でリリースした最新機能をご紹介します。",{"noIndex":92},{"heroImage":995,"body":1000,"authors":1001,"updatedDate":982,"date":1002,"title":996,"tags":1003,"description":1004,"category":701},"本ブログは、[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/)",[738],"2025-07-18",[763,721,701,110],"GitLab 18.2でリリースした最新機能を公開します。",{"featured":92,"template":681,"slug":1006},"gitlab-18-02-release","content:ja-jp:blog:gitlab-18-02-release.yml","Gitlab 18 02 Release","ja-jp/blog/gitlab-18-02-release.yml","ja-jp/blog/gitlab-18-02-release",{"_path":1012,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1013,"content":1017,"config":1023,"_id":1025,"_type":16,"title":1026,"_source":17,"_file":1027,"_stem":1028,"_extension":20},"/ja-jp/blog/gitlab-duo-agent-platform-public-beta",{"noIndex":6,"title":1014,"description":1015,"ogImage":1016},"GitLab Duo Agent Platform ベータ版：次世代AIオーケストレーション","開発者とAIエージェント間の非同期コラボレーションを実現するDevSecOpsオーケストレーションプラットフォームをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752678395/impw8no5tbskr6k2afgu.jpg",{"heroImage":1016,"body":1018,"authors":1019,"updatedDate":1020,"date":1021,"title":1014,"tags":1022,"description":1015,"category":787},"**私たちはソフトウェア開発の未来を構築しています。**\n\nGitLabでは、[ソフトウェアエンジニアリングの未来を人間とAIのコラボレーション](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops/)として再構想しています。開発者が技術的で複雑な問題の解決とイノベーションの推進に集中する一方で、AIエージェントが進捗を遅らせる日常的で反復的なタスクを処理します。開発者がはるかに低いコストで新しいアイデアをコードで自由に探求でき、バグのバックログが過去のものとなり、構築するソフトウェアのユーザーがより使いやすく、信頼性が高く、安全な体験を楽しめる世界です。これは遠い夢ではありません。私たちは現在この現実を構築しており、それがGitLab Duo Agent Platformです。\n\n## GitLab Duo Agent Platformとは？\n\nGitLab Duo Agent Platformは、開発者とAIエージェント間の非同期コラボレーションを実現するように設計された次世代DevSecOpsオーケストレーションプラットフォームです。これにより、ソフトウェア開発ワークフローを、従来の1人ずつ順番に開発を進めるプロセスから、複数の人やAIエージェントが同時に協力しあえる開発スタイルへ変革できます。まるで無限のチームメンバーを自由に使えるようなものです。\n\n複雑なリファクタリングタスクをSoftware Developer Agentに委任しながら、同時にSecurity Analyst Agentに脆弱性をスキャンさせ、Deep Research Agentにリポジトリ履歴全体の進捗を分析させることを想像してください。これらはすべて並行して行われ、GitLab内でシームレスにオーケストレーションされます。\n\n本日、GitLab.comおよびSelf-ManagedのGitLab PremiumとUltimateのお客様向けに、[GitLab Duo Agent Platformの最初のパブリックベータ版](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)のローンチを発表します。これは、インテリジェントな自動化を通じて人間の創意工夫を増幅させながら、ソフトウェアの計画、構築、検証、デプロイの方法を改善する一連のアップデートの最初のものです。\n\nこの最初のベータ版は、GitLab VS Code拡張機能とJetBrains IDEプラグインを通じてIDE体験を解放することに焦点を当てています。来月には、Duo Agent Platform体験をGitLabアプリケーションに導入し、IDEサポートを拡張する予定です。現在から今年後半に予定されている一般提供までのロードマップに関する私たちのビジョンについて、もう少し詳しくお話しさせていただきます。最初のベータ版の詳細は以下をご覧ください。\n\n現在利用可能な機能と今後の予定については、このビデオをご覧いただくか、続きをお読みください。その後、Duo Agent Platformを開始する準備ができたら、[パブリックベータ版での開始方法をご覧ください](#get今すぐ始める)。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Agent Platform Beta Launch_071625_MP_v2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## オーケストレーションプラットフォームとしてのGitLabのユニークなポジション\n\nGitLabは、エンジニアリングチームの記録システムとして開発ライフサイクルの中心に位置し、5,000万人以上の登録ユーザー（Fortune 500の半数を含む）のコンセプトから本番環境までの全行程をオーケストレーションしています。これには、公共機関を含むすべてのセグメントと業界にわたる10,000以上の有料顧客が含まれます。\n\nこれにより、GitLabは競合他社が持ち得ないものを手に入れています：ソフトウェアを提供するために必要なすべてに関する包括的な理解です。私たちは、プロジェクト計画、コード、テスト実行、セキュリティスキャン、コンプライアンスチェック、CI/CD設定を統合し、チームに力を与えるだけでなく、あなたがコントロールするAIエージェントとのコラボレーションをオーケストレーションします。\n\nインテリジェントで統一されたDevSecOpsプラットフォームとして、GitLabはソフトウェアエンジニアリング実践に関するすべてのコンテキストを1か所に保存します。私たちは、この統一されたデータをナレッジグラフを介してAIエージェントに公開します。構築されるすべてのエージェントは、このSDLC接続されたデータセットに自動的にアクセスでき、豊富なコンテキストを提供するため、エージェントは情報に基づいた推奨を行い、組織の標準に準拠したアクションを実行できます。\n\n**このアドバンテージの実例をご紹介します。** 数十、場合によっては数百のストーリーやイシューにわたって、関係するすべての開発者を含めてプロジェクトがどのように進行しているかを正確に把握しようとしたことはありますか？Deep Research AgentはGitLab Knowledge Graphとセマンティック検索機能を活用して、エピックとすべての関連イシューを横断し、関連するコードベースと周囲のコンテキストを探索します。リポジトリ、マージリクエスト、デプロイメント履歴全体の情報を迅速に相関させます。これにより、スタンドアロンツールでは実現できず、人間の開発者が発見するのに何時間もかかる重要な洞察が得られます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Deep Research Demo_071625_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## AI機能からエージェントオーケストレーションへの戦略的進化\n\nGitLab Duoは、Duo ProとEnterpriseを通じて開発者に生成AIをもたらすアドオンとして始まりました。GitLab 18.0では、プラットフォームに組み込まれています。すべてのPremiumおよびUltimateユーザー向けに[Duo Agentic Chat](https://about.gitlab.com/ja-jp/blog/gitlab-duo-chat-gets-agentic-ai-makeover/)とCode Suggestionsを解放し、現在Duo Agent Platformへの即座のアクセスを提供しています。\n\nエンジニアリング投資を強化し、デリバリーを加速させており、毎月強力な新しいAI機能が登場しています。しかし、私たちは単なる別のコーディングアシスタントを構築しているわけではありません。GitLab Duoは、AIエージェントを作成、カスタマイズ、デプロイでき、他のシステムと簡単に相互運用できるエージェントオーケストレーションプラットフォームになりつつあり、生産性を劇的に向上させます。\n\n> **「GitLab Duo Agent Platformは、私たちのコードベースと組織を真に理解するAIで開発ワークフローを強化します。コード、テスト、CI/CD、およびソフトウェア開発ライフサイクル全体の記録システムにGitLab Duo AIエージェントが組み込まれることで、生産性、開発速度、効率性が向上します。エージェントは私たちのチームの真のコラボレーターとなり、意図を理解し、問題を分解し、アクションを実行する能力により、開発者は情熱を持つエキサイティングで革新的な作業に取り組むことができます。」** - Bal Kang氏、NatWest エンジニアリングプラットフォームリード\n\n### すぐに使えるエージェント\n\n私たちは、おなじみのチームの役割を反映したエージェントを導入しています。これらのエージェントは、GitLab全体で既存のアーティファクトを検索、読み取り、作成、変更できます。これらは個別に対話できるエージェントであり、独自のエージェントを作成するためにカスタマイズできるビルディングブロックとしても機能します。チームメンバーと同様に、エージェントにはソフトウェア開発、テスト、技術文書作成などの定義された専門分野があります。スペシャリストとして、適切なコンテキストとツールを活用して、デプロイされる場所に関係なく、同じタイプのタスクを一貫して達成します。\n\n現在構築中のエージェントの例をいくつか紹介します：\n\n* **Chat Agent（現在ベータ版）：** 自然言語のリクエストを受け取り、ユーザーに情報とコンテキストを提供します。イシューの読み取りやコードの差分の読み取りなど、一般的な開発タスクを実行できます。例として、ジョブのURLを提供することで、失敗したジョブのデバッグをChatに依頼できます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102616311?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-in-web-ui-demo_Update V2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\u003Cp>\u003C/p>\n\n* **Software Developer Agent（現在ベータ版）：** 割り当てられたアイテムに取り組み、仮想開発環境でコード変更を作成し、レビュー用のマージリクエストを開きます。\n* **Product Planning Agent：** 製品バックログの優先順位付け、人間およびエージェントのチームメンバーへの作業アイテムの割り当て、指定されたタイムライン上でのプロジェクト更新の提供を行います。\n* **Software Test Engineer Agent：** バグの新しいコード貢献をテストし、報告された問題が解決されたかどうかを検証します。\n* **Code Reviewer Agent：** チーム標準に従ってコードレビューを実行し、品質とセキュリティの問題を特定し、準備ができたらコードをマージできます。\n* **Platform Engineer Agent：** GitLab Runnersを含むGitLabデプロイメントを監視し、CI/CDパイプラインの健全性を追跡し、人間のプラットフォームエンジニアリングチームにパフォーマンスの問題を報告します。\n* **Security Analyst Agent：** コードベースとデプロイされたアプリケーション内の脆弱性を発見し、セキュリティの弱点の解決に役立つコードと設定の変更を実装します。\n* **Deployment Engineer Agent：** 本番環境に更新をデプロイし、異常な動作を監視し、アプリケーションのパフォーマンスやセキュリティに影響を与える変更をロールバックします。\n* **Deep Research Agent：** 開発エコシステム全体にわたって包括的なマルチソース分析を実施します。\n\nこれらのエージェントを強力にするのは、GitLabの包括的なツールキットへのネイティブアクセスです。現在、イシューやエピックからマージリクエストやドキュメントまで、25以上のツールがあり、さらに増える予定です。限られたコンテキストで動作する外部AIツールとは異なり、エージェントは組織の監督の下で完全なプラットフォーム権限を持つ真のチームメンバーとして機能します。\n\n今後数か月で、これらのエージェントを組織のニーズに合わせて変更することもできるようになります。例えば、Software Test Engineer Agentが特定のフレームワークや方法論のベストプラクティスに従うように指定でき、その専門性を深め、さらに価値のあるチームメンバーに変えることができます。\n\n## Flowsが複雑なエージェントタスクをオーケストレーション\n\n個々のエージェントに加えて、エージェントFlowsを導入しています。これらは、自律的に実行できる特定のタスクに対して、事前に構築された指示、ステップ、アクションを含む複数のエージェントを含むことができる、より複雑なワークフローと考えてください。\n\n個人に共通する基本的なタスクのFlowsを作成できますが、通常は調整と労力に何時間もかかる複雑で専門的なタスクに適用すると真に優れています。Flowsは複雑なタスクをより速く完了する支援をし、多くの場合、人間の介入なしに非同期で実行できます。\n\nFlowsには実行のための特定のトリガーがあります。各Flowには一連のステップが含まれ、各ステップには専門のエージェントに何をすべきかを伝える詳細な指示があります。この詳細なアプローチにより、Flow内のエージェントに正確な指示を与えることができます。より詳細に指示を定義し、構造化された決定ポイントを確立することで、FlowsはAI応答の固有の変動性を解決しながら、同じ要件を繰り返し指定する必要をなくし、ユーザー設定なしでより一貫性があり予測可能な結果を解放できます。\n\n私たちが構築している、すぐに使えるFlowsの例をいくつか紹介します：\n\n**Software Development Flow（現在ベータ版）：** 複数のエージェントをオーケストレーションして、コード変更をエンドツーエンドで計画、実装、テストし、チームがコンセプトから本番環境まで機能を提供する方法を変革する支援をします。\n\n**Issue-to-MR Flow：** エージェントを調整して要件を分析し、包括的な実装計画を準備し、コードを生成することで、イシューを実行可能なマージリクエストに自動的に変換します。\n\n**Convert CI File Flow：** 既存のCI/CD設定を分析し、完全なパイプライン互換性を持つGitLab CI形式にインテリジェントに変換するエージェントを使用して、移行ワークフローを合理化します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jenkins-to-gitlab-cicd-for-blog\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n**Search and Replace Flow：** プロジェクト構造を体系的に分析し、最適化の機会を特定し、正確な置換を実行することで、コードベース全体でコードパターンを発見して変換します。\n\n**Incident Response & Root Cause Analysis Flow：** システムデータを相関させ、根本原因分析のための専門エージェントを調整し、解決プロセス全体を通じて関係者に情報を提供しながら、承認された修復手順を実行することで、インシデント対応をオーケストレーションします。\n\nこれは、GitLab Duo Agent Platformが他のAIソリューションと比較して真にユニークなアプローチを取っている点になります。事前に構築されたエージェントを提供するだけではありません。個人および組織の独自のニーズに完全に一致するエージェントFlowsを作成、カスタマイズ、共有する力も提供します。そして、Flowsを使用すると、一般的で複雑なタスクに対してエージェントに特定の実行計画を与えることができます。\n\nこのアプローチは、競合他社が行うような目的別のエージェントを構築するよりも強力であると考えています。なぜなら、すべての組織には異なるワークフロー、コーディング標準、セキュリティ要件、ビジネスロジックがあるからです。汎用AIツールは特定のコンテキストを理解できませんが、GitLab Duo Agent Platformはチームの作業方法に正確に合わせて調整できるようになります。\n\n## なぜGitLab Duo Agent PlatformでエージェントとエージェントFlowsを構築するのか？\n\n**高速構築：**高速で宣言的な拡張性モデルとUIアシスタンスを使用して、Duo Agent Platformでエージェントと複雑なエージェントFlowsを迅速かつ簡単に構築できます。\n\n**組み込みコンピュート：**Duo Agent Platformを使用すると、エージェント用の独自のインフラストラクチャを立ち上げる手間をかける必要がなくなります：コンピュート、ネットワーク、ストレージはすべて組み込まれています。\n\n**SDLCイベント：**エージェントは、パイプラインのエラー、デプロイメントの失敗、イシューの作成など、一般的なイベントで自動的に呼び出すことができます。\n\n**即座のアクセス：**GitLabまたはIDEプラグインのどこからでもエージェントと対話できます：イシューを割り当て、コメントで@メンションし、Duo Chatが利用可能なあらゆる場所でチャットできます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102029239?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"assigning an agent an issue\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script> \u003Cp>\u003C/p>\n\n**組み込みモデルとカスタムモデルをサポート：** エージェントは、サポートするすべてのモデルに自動的にアクセスでき、ユーザーは特定のタスクに特定のモデルを選択できます。Duo Agent Platformを独自のセルフホストモデルに接続したい場合は、それも可能になります！\n\n**Model Context Protocol（MCP）エンドポイント：**すべてのエージェントとFlowはネイティブMCPエンドポイントを介してアクセスまたはトリガーでき、Claude Code、Cursor、Copilot、Windsurfなどの人気のあるツールを含む、どこからでもエージェントとFlowsに接続してコラボレーションできます。\n\n**可観測性とセキュリティ：**組み込みの可観測性と使用状況ダッシュボードを提供し、エージェントが誰が、どこで、何を、いつあなたに代わってアクションを実行したかを正確に確認できます。\n\n## コミュニティ主導の未来\n\nコミュニティの貢献は長い間GitLabのイノベーションとソフトウェア開発を促進してきました。AI Catalogの導入により、コミュニティとパートナーシップを組むことに興奮しています。AI Catalogにより、組織内およびGitLabエコシステム全体でエージェントとFlowsを作成して共有できるようになります（今後のベータ版で）。\n\n最も価値のあるAIアプリケーションは、GitLab Duo Agent Platformを毎日適用して多数の実世界のユースケースを解決することで、コミュニティの皆様から生まれる可能性が高いと考えています。エージェントとFlowsのシームレスな共有を可能にすることで、各コントリビュートがプラットフォームの集合的なインテリジェンスと価値を高めるネットワーク効果を生み出しています。時間の経過とともに、Agent Platformからの最も価値のあるユースケースは、繁栄するGitLabコミュニティから生まれると信じています。\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685501/awdwx08udwrxgvcpmssb.png \"AI Catalog\")\n\n## 現在GitLab Duo Agent Platformパブリックベータ版で利用可能\n\nGitLab Duo Agent Platformパブリックベータ版は、PremiumおよびUltimateのお客様に以下の機能を提供して現在利用可能です：\n\n**Software Development Flow：** 最初のFlowは、包括的なコンテキストの収集、人間の開発者との曖昧さの明確化、コードベースとリポジトリに正確な変更を加えるための戦略的計画の実行においてエージェントをオーケストレーションします。プロジェクト全体（構造、コードベース、履歴を含む）と、GitLabのイシューやマージリクエストなどの追加コンテキストを活用して、開発者の生産性を増幅します。\n\n**新しいエージェントツールが利用可能：** エージェントは作業を行うために複数のツールにアクセスできるようになりました：\n\n* ファイルシステム（読み取り、作成、編集、ファイル検索、リスト、Grep）\n* コマンドライン実行*\n* イシュー（リスト、取得、コメント取得、編集*、作成*、コメント追加/更新*）\n* エピック（取得、コメント取得）\n* MR（取得、コメント取得、差分取得、作成、更新）\n* パイプライン（ジョブログ、パイプラインエラー）\n* プロジェクト（取得、ファイル取得）\n* コミット（取得、リスト、コメント取得、差分取得）\n* 検索（イシュー検索）\n* セキュア（脆弱性リスト）\n* ドキュメント検索\n  *=ユーザー承認が必要\n\n**IDEでのGitLab Duo Agentic Chat：** Duo Agentic Chatは、チャット体験を受動的なQ&Aツールから、IDE内で直接アクティブな開発パートナーに変換します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1103237126?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-ai-launch-video_NEW\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\u003Cp>\u003C/p>\n\n* **反復的なフィードバックとチャット履歴：** Duo Agentic Chatは、チャット履歴と反復的なフィードバックをサポートするようになり、エージェントを状態を持つ会話型パートナーに変換します。これにより信頼が育まれ、開発者がより複雑なタスクを委任し、修正指導を提供できるようになります。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-history\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **スラッシュコマンドによる合理化された委任：** /explain、/tests、/includeなどの拡張されたより強力なスラッシュコマンドは、迅速で正確な意図のための「委任言語」を作成します。/includeコマンドにより、特定のファイル、開いているイシュー、マージリクエスト、または依存関係からのコンテキストをエージェントの作業メモリに直接注入でき、エージェントをより強力にし、高品質な応答のための最適なコンテキストを提供する方法をユーザーに教えます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"include-agentic-chat-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **カスタムルールによるパーソナライゼーション：** 新しいカスタムルールにより、開発者は自然言語（例：開発スタイルガイド）を使用して、エージェントの動作を個人およびチームの好みに合わせて調整できます。この基本的なメカニズムは、エージェントのペルソナをパーソナライズされたアシスタントに形成し、ユーザー定義の好みと組織ポリシーに基づいて専門的なエージェントへと進化します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"custom-rules-with-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **JetBrains IDEでのGitLab Duo Agentic Chatのサポート：** 開発者が作業する場所で会うために、IntelliJ、PyCharm、GoLand、WebstormなどのJetBrainsファミリーのIDEにDuo Agentic Chatサポートを拡張しました。これは既存のVS Codeサポートに追加されます。既存のユーザーは自動的にエージェント機能を取得し、新しいユーザーはJetBrains Marketplaceからプラグインをインストールできます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jetbrains-support-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **MCPクライアントサポート：** Duo Agentic Chatは、MCPクライアントとして機能し、リモートおよびローカルで実行されているMCPサーバーに接続できるようになりました。\n\nこの機能により、エージェントはGitLab以外のJira、ServiceNow、ZenDeskなどのシステムに接続してコンテキストを収集したり、アクションを実行したりできます。MCPを介して自身を公開するサービスは、エージェントのスキルセットの一部になることができます。公式のGitLab MCPサーバーは近日公開予定です！\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"McpDemo\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **GitLab Web UIでのGitLab Duo Agentic Chat。** Duo Agentic ChatはGitLab Web UI内でも直接利用できるようになりました。この重要なステップにより、エージェントはコーディングアシスタントから真のDevSecOpsエージェントへと進化します。イシューやマージリクエストのディスカッションなどの豊富な非コードコンテキストにアクセスできるようになり、作業の背後にある「なぜ」を理解できるようになります。コンテキストを理解するだけでなく、エージェントはイシューのステータスの自動更新やマージリクエストの説明の編集など、WebUIから直接変更を加えることができます。\n\n## GitLab Duo Agent Platformに近日登場\n\n今後数週間にわたって、Duo Agent Platformに新しい機能をリリースし、より多くのすぐに使えるエージェントとFlowsを含めます。これらは、現在愛用されているGitLab体験にプラットフォームをもたらし、さらに大きなカスタマイズと拡張性を可能にし、お客様の生産性を増幅します：\n\n![GitLab Duo Agent Platform パブリックベータロードマップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685275/hjbe9iiu2ydp9slibsc2.png \"GitLab Duo Agent Platform パブリックベータロードマップ\")\n\n* **統合されたGitLab体験：** 18.2で利用可能なIDE拡張機能を基に、GitLabプラットフォーム内でエージェントとFlowsを拡張しています。このより深い統合により、エージェントと同期的および非同期的にコラボレーションする方法が拡張されます。エージェントに直接イシューを割り当て、GitLab Duo Chat内で@メンションし、選択した開発ツールからのMCP接続を維持しながら、アプリケーションのどこからでもシームレスに呼び出すことができます。このネイティブ統合により、エージェントはGitLab全体でアクセス可能な真の開発チームメンバーに変わります。\n* **エージェントの可観測性：** エージェントがより自律的になるにつれて、Flowsを進行する際のアクティビティに対する包括的な可視性を構築しており、意思決定プロセスを監視し、実行ステップを追跡し、開発の課題をどのように解釈して行動しているかを理解できるようにします。エージェントの動作に対するこの透明性は信頼と確信を構築し、ワークフローを最適化し、ボトルネックを特定し、エージェントが意図したとおりに正確に実行されていることを確認するのに役立ちます。\n* **AI Catalog：** 素晴らしいソリューションはコミュニティのイノベーションから生まれることを認識し、まもなくAI Catalogのパブリックベータ版を導入します - GitLabから、そして時間の経過とともにより広いコミュニティから調達された専門的なエージェントとFlowsでDuo Agent Platformを拡張できるマーケットプレイスです。これらのソリューションをGitLabで迅速にデプロイし、プロジェクトとコードベース全体のコンテキストを活用できます。\n* **Knowledge Graph：** ソースコードとその周囲のコンテキストの記録システムとしてのGitLabのユニークなアドバンテージを活用して、コードベース全体のファイルと依存関係をマッピングするだけでなく、そのマップをユーザーがナビゲート可能にし、AIクエリ時間を加速し、精度の向上に役立つ包括的なKnowledge Graphを構築しています。この基盤により、GitLab Duoエージェントは、コードの依存関係からデプロイメントパターンまで、開発環境全体の関係を迅速に理解でき、複雑な質問に対するより速く、より正確な応答を解放します。\n\n![GitLab Duo Agent Platform Knowledge Graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685367/n0tvfgorchuhrronic3j.png \"GitLab Duo Agent Platform Knowledge Graph\")\n\n* **エージェントとFlowsの作成と編集：** すべての組織には独自のワークフローと要件があることを理解し、AI Catalogが成熟するにつれて導入される強力なエージェントとFlow作成および編集機能を開発しています。組織の作業方法に正確に合わせてエージェントとFlowsを作成および変更でき、Duo Agent Platform全体で高品質な結果と生産性の向上を可能にする深いカスタマイズを提供します。\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752684938/fruwqcqvvrx8gmkz5u0v.png \"AI Catalog\")\n\n* **公式GitLab MCPサーバー：** 開発者が複数のツールと環境で作業することを認識し、MCPを介してすべてのエージェントとFlowsにアクセスできる公式GitLab MCPサーバーを構築しています。Claude Code、Cursor、Copilot、WindsurfなどのポピュラーなツールをMCPがサポートされている場所から、エージェントとFlowsに接続してコラボレーションでき、好みの開発環境に関係なくシームレスなAIコラボレーションを解放します。\n* **GitLab Duo Agent Platform CLI：** 今後のCLIにより、コマンドラインでエージェントを呼び出し、Flowsをトリガーできるようになり、コードリポジトリとマージリクエストからCI/CDパイプラインとイシュー追跡まで、ソフトウェア開発ライフサイクル全体にわたるGitLabの豊富なコンテキストを活用できます。\n\n## 今すぐ始める\n\n* GitLab.comおよびGitLab 18.2を使用するセルフマネージド環境の**GitLab PremiumおよびUltimateのお客様**は、Duo Agent Platformをすぐに使用できます（GitLab Duoの[ベータ版および実験的機能を有効にする必要があります](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)）。\n* ユーザーは[VS Code拡張機能](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow)または[JetBrains IDEsプラグイン](https://plugins.jetbrains.com/plugin/22857-gitlab)をダウンロードし、Duo Chat [スラッシュコマンド](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#gitlab-duo-chat-slash-commands)を含む[GitLab Duo Agentic Chatの使用ガイド](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat)に従ってください。\n\n**GitLabは初めてですか？** 誰でも今後の[GitLab Duo Agent Platformを実際に見るための技術デモ](https://page.gitlab.com/webcasts-jul16-gitlab-duo-agentic-ai-emea-amer.html)に参加できます。GitLab Duo Agent Platformを自分で実際に体験するには、今すぐ[無料トライアル](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fsales%2F)にサインアップしてください。\n\n\u003Csmall>*このブログ記事には、改正1933年証券法第27A条および1934年証券取引所法第21E条の意味における「将来の見通しに関する記述」が含まれています。このブログ記事に含まれる将来の見通しに関する記述に反映された期待は合理的であると考えていますが、それらは既知および未知のリスク、不確実性、仮定、およびその他の要因の影響を受けるため、実際の結果または成果は、将来の見通しに関する記述によって表現または暗示されたものと大きく異なる可能性があります。*\n\n*将来の見通しに関する記述に含まれるまたは検討される実際の成果や結果が大きく異なる原因となる可能性のあるリスク、不確実性、およびその他の要因に関する詳細情報は、証券取引委員会に提出する書類および報告書の「リスク要因」という見出しおよびその他の箇所に記載されています。私たちは、このブログ記事の日付以降に発生するイベントや状況を報告したり、予期しないイベントの発生を反映したりするために、将来の見通しに関する記述の改訂を更新または公開する義務を法律で要求される場合を除いて負いません。*\u003C/small>",[901],"2025-07-22","2025-07-17",[721,701,678,700],{"featured":92,"template":681,"slug":1024},"gitlab-duo-agent-platform-public-beta","content:ja-jp:blog:gitlab-duo-agent-platform-public-beta.yml","Gitlab Duo Agent Platform Public Beta","ja-jp/blog/gitlab-duo-agent-platform-public-beta.yml","ja-jp/blog/gitlab-duo-agent-platform-public-beta",{"_path":1030,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1031,"content":1037,"config":1041,"_id":1043,"_type":16,"title":1044,"_source":17,"_file":1045,"_stem":1046,"_extension":20},"/ja-jp/blog/what-is-open-source",{"noIndex":6,"title":1032,"ogTitle":1033,"description":1034,"ogImage":1035,"ogDescription":1036},"オープンソースソフトウェア（OSS）とは？詳しく解説​ | GitLab","オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。読んで、理解を深めましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",{"title":1033,"description":1036,"authors":1038,"heroImage":1035,"date":1021,"body":1039,"category":962,"tags":1040},[671],"## オープンソースとは？\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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[675,270,825,722],{"featured":92,"template":681,"slug":1042},"what-is-open-source","content:ja-jp:blog:what-is-open-source.yml","What Is Open Source","ja-jp/blog/what-is-open-source.yml","ja-jp/blog/what-is-open-source",{"_path":1048,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1049,"content":1053,"config":1061,"_id":1063,"_type":16,"title":1064,"_source":17,"_file":1065,"_stem":1066,"_extension":20},"/ja-jp/blog/claude-code-gitlab-ai-development-workflow",{"noIndex":6,"title":1050,"description":1051,"ogImage":1052},"エージェンティックAI Claude CodeとGitLab CLIの開発フロー","Claude CodeとGLabを組み合わせてローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIのコード補助を活かした開発フローを構築する方法を紹介","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751953181/rtejicnkhd9oslaxsoo5.jpg",{"heroImage":1052,"category":787,"body":1054,"date":1055,"authors":1056,"description":1058,"title":1059,"tags":1060},"## 目次\n\n1. はじめに: AI活用の新時代を切り拓く効率的なソフトウェア開発\n2. Claude Codeとは何か？\n3. GitLabのCLIであるGLabの紹介\n4. Claude CodeとGLabを組み合わせた開発の流れ\n5. AIを使った開発の今後の広がりについて\n6. まとめ\n7. よくある質問\n\n\n\n## はじめに: AI活用の新時代を切り拓く効率的なソフトウェア開発\n\nこの記事を読むと、エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法がわかるようになります。\n\n## Claude Codeとは何か？\n\nClaude Codeとはエージェント型AIで、ターミナル上でAIにコマンドを実行させることで既存ツールを使いながら効率的に開発できます。\n\n## GitLabのCLIであるGLabの紹介\n\nGLabはオープンソースのGitLab CLIツールです。GLabをターミナルに統合し、作業中のコマンドラインツールや、IDEの中に表示できます。GitLabのWebUIにアクセスするためにブラウザのウィンドウやタブに切り替える必要がなくなり、マージリクエストの作成やパイプラインの状況の確認など、様々なことを直感的にコマンドラインで実行可能になります。\n\n## Claude CodeとGLabを組み合わせた開発の流れ\n\n### **Claude Codeとglabのインストール**\n\nここでは個別のインストール方法や導入の仕方については割愛しますが、下記の公式サイトが参考になると思いますのでご確認ください。\n\nClaude Code: \u003Chttps://docs.anthropic.com/ja/docs/claude-code/overview>\n\nGLab: \u003Chttps://gitlab.com/gitlab-org/cli/-/blob/main/README.md>\n\n### [](https://gitlab.com/gitlab-org/cli/-/blob/main/README.md)**GitLabの認証情報を設定**\n\nまずはGLabのセットアップをしていきましょう。GLabでGitLabサーバーにログインします。\n\n`$ glab auth login`\n\n上記を実行すると、ログインするサーバーの先を問われるので、選びます。続いて、Tokenによるログインか、Webブラウザを使って認証するか聞かれるため、これも好きな方を選んでください。下記は、Webを選んだ場合の画面です。\n\n![Webログイン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/tl81t9qzwhqjnrro3lrb.png)\n\n次に、Gitクライアントが通信するデフォルトのプロトコルを聞かれるので、これも好きなものを選んでください。環境によってはSSHプロトコルの通信が制限されている場合もあるかと思うので、そのような場合はHTTPSを選ぶことをおすすめします。\n\n最後に、Gitの認証にもCredentialsの認証情報使うかを問われるため、これも選んでいただければと思います。\nYesの場合は、GitのHTTPS認証にもglabのPersonal Access Token（PAT）を使うよう.gitconfigに設定され、Noを選んだ場合は、glabでIssueやMRの操作をする一方で、Gitのpush/pullは従来通りのSSHや別途設定した認証方式で行う必要があります。\n\n初期の設定が終わった画面を下記に示します。\n\n![初期設定完了画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198582/xtpheeez1gcwr8sfjmdv.png)\n\n### **開発対象プロジェクトのclone**\n\n次に、Claude Codeに指示を与えて、glabコマンドを使って、リモートリポジトリからcloneします。下記のコマンドでClaude Codeを起動します。\n\n`$ claude`\n\n既にGLabで認証は終わっているため、作業するプロジェクトのリポジトリをcloneするように指示を与えます。\n\n`> GitLab上で自分が参加しているプロジェクトを表示してください`\n\n上記のようにプロンプトするとClaude Codeが\n\n`$ glab repo list`\n\nなどを実行してくれると思います。次に、作業したいリポジトリを上記から選び、Cloneします。プロジェクト名は各自の環境に合わせて指定してください。\n\n`> プロジェクト naosasaki-demo/study/spring-demo をcloneしてください`\n\nClaude Codeの処理が終わると、一度Claude Codeを終了し、ターミナルでディレクトリを確認すると、cloneされたディレクトリが作られていることがわかると思います。\n\n**新しいIssueの作成**\n\n次に、このプロジェクトに新しくイシューを作りたいと思います。通常であればWebブラウザでGitLabにアクセスしイシューを登録しますが、GLabとClaude Codeを使って、IDEやターミナル画面から作ってみたいと思います。\n\n`> このプロジェクトに新しいイシューを作ってください。内容は、今の東京の温度と天気を返すWebAPIのエンドポイントを作成します。`\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/iizlucpfxgsa0nrdsvqn.png)\n\n\n上記のようにglabを使ってイシューを作成するコマンドが提案されます。またイシューのなかの記載もある程度書いてくれていることがわかります。\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198579/ye2wtupp6nf8ljzja2yh.png)\n\nブラウザでアクセスしても、正しく作られていることがわかります。\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198582/vbo22zzdzzanvnrbsszq.png)\n\n### **マージリクエストとブランチの作成と作業開始**\n\n次に、実際のこのIssueの内容を実装していきたいと思います。ここからはIDEのVisual Studio Codeも利用していきたいと思います。Visual Studio Codeを起動し、内蔵されたターミナルを開き、そこでClaude Codeを起動します。\n\n早速、先ほど作ったイシューからマージリクエストを作って、その中で作業をしていきたいと思います。\n\n`> このリポジトリのプロジェクトのissue 53を実装したいので、glabでMRを作って、そのブランチをチェックアウトして`\n\n![マージリクエストとブランチの作成と作業開始](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/or6l5si3k4dbprcnnfgq.png)\n\n**コードの編集と検証**\n\n`> イシューの記載に基づいて実装してください。また、リポジトリ内部のドキュメントも追加に伴って更新してください。`\n\n![コードの編集と検証](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/dlgq0j60n2jfk24vxaj3.png)\n\nOpenWeatherMap APIを使うことを提案してくれています。そのほかにも、いくつかのクラスを作成することを提案されるので、中身を確認しつつ、それを受け入れ、git pushなども依頼します。\n\n![CC_8_git push](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198584/esdeisz4mzyyjlerlahl.png)\n\n### **レビューとCI/CDの確認**\n\n実際にマージリクエストを確認すると、ローカルで作成した変更がプッシュされ、GitLab側のCI/CDでの単体テストや、セキュリティスキャンなども正常に実行され、問題なく終了していることがわかりました。\n\n![レビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/e7hyheb5gkpvb7iixrro.png)\n\nしかし、テストが通っていても、それが適切な方法で実装されているか、非機能的な観点で問題がないかは別途確認する必要があります。ここで[GitLab Duo in merge requests](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/)という機能を利用して、GitLabのAI機能であるGitLab Duoにレビューを依頼してみたいと思います。\n\nマージリクエストのコメントでレビューをリクエストし、レビュアーとしてDuoを指定します。この時、レビューの観点なども同時に与えることができます。下記のようにコメントでレビューをDuoに依頼します。\n\n`/request_review @GitLabDuo`\n\n`マージリクエストのコードを下記の観点でレビューしてください：`\n\n`拡張性：将来的な機能追加や変更に対応しやすい設計・実装になっているか  \n可読性：他の開発者が理解しやすいコードになっているか  \n安全性：バグやセキュリティリスクを引き起こす可能性がないか  \nパフォーマンス：必要以上にリソースを消費していないか`\n\n![Duoレビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198581/tnkt52hpapm8cyi4qplw.png)\n\n上記をコメントすることで、Duoにレビューを依頼できます。\n\n実際にレビュー指摘がありました。\n\n![Duoレビュー指摘](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/vehscyu2beo4pz9ns3y2.png)\n\nDuoの指摘のとおり、Claude Codeが生成した元のコードでは、translateWeatherToJapanese メソッドが呼ばれるたびに HashMap が新しく作成されています。これはパフォーマンスの低下や不要なオブジェクト生成につながります。Duoは「このマップは不変であり、再利用可能なので static final にすべき」と提案しています。これの指摘は確かにその通りなので、マージリクエスト上でこの指摘と、変更の提案を受け入れます。\n\nこの変更の受け入れ自体も、ソースコードの変更なので、受け入れたらCI/CDパイプラインが動き出して、再度自動的にセキュリティスキャンや単体テスト実施されます。再度CI/CDパイプラインが動き、問題がなかったためmainブランチにマージしました。これでこの機能の開発は完了です。\n\n## AIを使った開発の今後の広がりについて\n\n### **AIは「補助ツール」から「実行の主体」へ**\n\n従来のチャットベースのインタラクティブな開発支援、すなわち一問一答のやり取りを繰り返しながら人間が主導で手を動かしていた開発スタイルから、いま大きな転換が始まっています。\n\nGLabのようなCLIツールやWebAPIと、エージェンティックAIを組み合わせることで、「命令→実行→ステータス確認→再試行」といった一連の開発オペレーションを、AIが自律的かつ反復的に担う、まさに実行主体としてのAIへの進化が進んでいます。\n\nこれは単なる補助からの脱却であり、ソフトウェア開発における人と機械の役割分担そのものを再定義しつつあります。人間は「何を実現したいか」を定義し、AIは「どう実現するか」を粘り強く試行錯誤していく、そんな協働の形が、現実の開発現場に静かに浸透し始めています。\n\n**レビューとガバナンスの重要性**\n\nAIによってコードが自動生成されるようになった今、開発効率が飛躍的に向上する一方で、「そのコードは本当に安全か？」「人間はAIの出力を正しくレビューできるのか？」といった新たな課題が生まれています。\n\n人間の作業と同様に、AIによって生成されたコードは、動作するからといって、品質が担保されているとは限りません。\n\nこうした背景から、組織的にAIを活用していくには、**コードの品質・セキュリティ・コンプライアンスを保証する仕組みを開発プロセスに組み込む**ことが不可欠です。\n\n今回は、コードの生成にClaude Codeを利用しましたが、そのコードに含まれる性能的な懸念をGitLab Duoによるレビューで摘出することができました。\n\nその他にも、GitLabでは「パイプライン実行ポリシー」を用いることで、プロジェクト単位ではなくグループやサブグループに対して、**SASTや依存関係スキャン、シークレット検出などのセキュリティジョブを強制適用**することが可能です。\n\nこのように、**AIによる開発支援とセキュリティ・品質管理の自動化を同時に実現できる**のは、DevSecOpsを包括的に支援するプラットフォームであるGitLabの強みといえます。\n\n## まとめ\n\nこの記事では、Claude CodeのようなAIエージェントと、GitLab公式CLIツールGLabを組み合わせることで、自然言語によるコード生成からGitLab上でのイシュー管理やマージリクエスト作成までをAIエージェントにやってもらうことで、開発効率を向上させる例を紹介しました。一方で、AIエージェントが生成するコードの品質を担保するには、GitLabのセキュリティスキャンやパイプライン実行ポリシーを活用した自動検証の仕組みが欠かせません。AIと人間、それぞれの強みを活かした開発フローが、今後ますます重要になっていくでしょう。\n\n> 今すぐ始められる：GitLabでAIを使ったソフトウェア開発を体験しよう\n>\n> [GitLab Duoの無料トライアルに申し込む](https://about.gitlab.com/ja-jp/solutions/gitlab-duo-pro/sales/)\n\n## よくある質問\n\n### Q1: GitLabのAI機能にはどのようなものがありますか？\n\nA1: GitLabのAI機能「GitLab Duo」には、ソースコードの提案、テストケース/コードの生成はもちろん、脆弱性の自動修復や、CI/CD失敗時の根本原因分析など、ソフトウェア開発全体に対するAIによる支援機能群が含まれています。\n\n\n### Q2: GitLab Duoはユーザーのソースコードを学習に使いますか？\n\nA2: いいえ。GitLab Duoは利用者のコードやデータをモデルの再学習には使用しません。GitLabはユーザーデータのプライバシーとセキュリティを重視しており、企業向けにも安心して利用できる設計となっています。詳細については、[GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/)をご確認ください。\n\n### Q3: Claude Codeとは何ですか？\n\nA3: Claude Codeとはエージェント型AIで、ターミナル上でAIにコマンドを実行させることで既存ツールを使いながら効率的に開発できます。\n\n### Q4: GitLab CLIのGLabとは何ですか？\n\nA4: GLabは、GitLab公式が提供するオープンソースのCLIツールです。GLabをターミナルに統合し、作業中のコマンドラインツールや、IDEの中に表示できます。","2025-07-14",[1057],"Naoharu Sasaki","エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法をご紹介します。","Claude Code × GitLab：AI活用を加速する、エージェンティックAIとGitLab CLIによる効率的なソフトウェア開発フロー",[721,110,742,675,702,678,533,235,722,676,677],{"featured":92,"template":681,"slug":1062},"claude-code-gitlab-ai-development-workflow","content:ja-jp:blog:claude-code-gitlab-ai-development-workflow.yml","Claude Code Gitlab Ai Development Workflow","ja-jp/blog/claude-code-gitlab-ai-development-workflow.yml","ja-jp/blog/claude-code-gitlab-ai-development-workflow",{"_path":1068,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1069,"content":1073,"config":1077,"_id":1079,"_type":16,"title":1080,"_source":17,"_file":1081,"_stem":1082,"_extension":20},"/ja-jp/blog/monday-merge-2025-july-14",{"noIndex":6,"ogImage":1070,"title":1071,"description":1072},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204420/ccdkkhlyrjmyjxsicf7d.jpg","Monday Merge 7月号","Monday Merge７月号では、GitLab 18の最新トピックのほか、AWS Summit、新しいライブ番組のスタート、そして注目のカスタマーストーリーをご紹介します。",{"date":1055,"body":1074,"title":1071,"category":700,"heroImage":1070,"authors":1075,"description":1072,"tags":1076},"GitLabコミュニティのみなさん、こんにちは！Fatimaです。今月のMonday Mergeも、本当に盛りだくさんです！GitLab 18の最新トピックはもちろん、活気あふれるニューヨークでのAWS Summit、新しいライブ番組のスタート、そして注目のカスタマーストーリーまで。7月はまさにDevSecOpsの話題で溢れています。\n\nさらに、IBMと協力してメインフレームDevOpsの最新化にも取り組んでいます。（そう、あのCOBOLが再び注目を浴びています！）\n\nそれでは、さっそく見ていきましょう👇\n\n## GitLab 18 バーチャルローンチ：AI × オーケストレーションの未来へ\n\n![GitLab 18 バーチャルローンチ：AI × オーケストレーションの未来へ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/ryjaxhkcssnxn9x6genq.png)\n\n先月、GitLab 18のバーチャルローンチイベントを開催しました。\\\nライブ配信を見逃した方も大丈夫。ここで簡単にポイントを振り返ります。\n\n注目のハイライトは？ \\\nそれは、GitLab Duo Agent Platform の登場です。この新しいプラットフォームでは、エンジニアとAIエージェントがソフトウェア開発のあらゆる工程で連携・協働できるようになります。これにより、開発チームの生産性や開発スピードが大きく向上することが期待されています。\n\nGitLabのCEO、ビル・ステイプルズはこのように語りました：\n\n> *「GitLab 18は、人とAIエージェントが一緒に働けるDevSecOpsオーケストレーションフォームです。ソフトウェア開発のあらゆる工程で、“エージェント型AI”を活用したチームワークを実現します。」*\n\nつまり、これは開発者の代わりになるものではなく、繰り返し作業の負担を減らし、人の創造力と専門性をもっと活かせるようにするための進化です。私たちはそんな未来を目指しています。\n\nさらに今回、GitLabの統合DevSecOpsプラットフォームとAmazon Q Developerエージェントの連携も発表しました。この強力な組み合わせにより、より安全でスピーディーなソフトウェア開発が実現します。\n\nGitLab Duo + Amazon Qは、AIを活用したシームレスな開発の新時代を象徴するものです。\n\nイベントにはBarclaysとThalesも登場し、GitLab 18がそれぞれの組織の開発プロセスをどう変えているのか、リアルな声を共有してくれました。金融の高度なセキュリティ要件から航空業界のイノベーションまで、GitLab 18がもたらす影響は確かなものです。\n\n👉 イベントのフル動画は [GitLab 18 Launch Event](https://about.gitlab.com/ja-jp/eighteen/?utm_medium=social&utm_source=linkedin&utm_campaign=20250624_global_corp_webcast_aisdlc_en_gitlab18)ページ でご覧いただけます。\n\n## GitLab 18.1がリリースされました：セキュリティ、スピード、そしてAIの進化\n\n![18.1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/wbauaqzctmlul8lg7mu3.png)\n\nGitLab 18をリリースをしてすぐではありますが、[GitLab18.1が登場](https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release/)しました！この最初のリリースには、チームの開発スピードとセキュリティをさらに高めるためのアップデートが満載です。\n\n#### 注目の新機能はこちら：\n\n✅ Duoコードレビュー が正式リリース！\\\n AIがマージリクエストに対してインテリジェントなフィードバックを提供し、レビューのスピードアップやバグの早期発見を支援します。\n\n📦 Maven仮想レジストリ（Virtual Registry） がベータ版に\\\n GitLab上でのMaven依存関係の管理がより簡単になりました。\n\n🔐 漏洩パスワード検出機能 を追加\\\n あなたのパスワードが既知のデータ漏洩に含まれていないかを検出し、安全な変更方法を案内してくれます。\n\n🔁 SLSAレベル 1 準拠をサポート\\\n 新しいCI/CDコンポーネントを使って、ソフトウェアサプライチェーンのセキュリティ強化に貢献します。\n\nそして、何より嬉しいのは、みなさんからの 110件以上の改善と、311件ものコミュニティ貢献によってこのリリースが実現したことです。開発・レビュー・ドキュメント・ビルドに関わってくださった全ての方々、本当にありがとうございます！\n\n👉 [リリースノート全文はこちら！](https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release/)\n\n## 新ライブ配信シリーズ：The Developer Show – Powered by GitLab \n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204283/guz14qmyjhiyuf6oyh9k.png)\n\nGitLabからの新しいライブ配信シリーズが始まりました！その名も The Developer Show – Powered by GitLab。私とセキュリティPMMのSalがホストを務める、月1回のライブ配信番組です。\n\nこれはよくある「普通のウェビナー」ではありません。毎回、実際に今の開発現場を変えている技術について深く掘り下げていきます。\n\n対象は、開発者、開発リード、コードに関わるすべての人。業界で本当に語られているリアルな会話をキャッチアップしたい人向けです。\n\n📺 エピソード1では、GitLab 18 バーチャルローンチの内容を振り返り！\\\n ハイライトの紹介はもちろん、実践的なヒントやちょっと辛口なコメントも交えてお届けします。\n\n👉 [今すぐ視聴＆チャンネル登録して、次回もお見逃しなく！](https://www.linkedin.com/events/7340777668130312193/comments/)\n\n## AWS Summit New York：GitLabブースでお会いしましょう！ !\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/thiukj2hnn9mjyd1mcui.png)\n\n先日の東京に引き続き、7月16日、GitLabチームはニューヨークで開催されるAWS Summitに参加します！お近くの方は、Javits Center内のGitLabブースにぜひお立ち寄りください。\n\n当日は以下の内容をご用意しています：\n\n* GitLab DuoのAI機能を体験できるハンズオンデモ  \n* セキュリティ、開発スピード、開発者体験に関するライトニングトーク  \n* GitLabのDevSecOpsエキスパートとの対話（ご質問大歓迎です！）  \n* 限定ノベルティやプレゼントもご用意しています\n\nさらに、当日はAWSのAgentic AI担当VPのSwami Sivasubramanian氏による基調講演も実施されます。Agentic AIがソフトウェア開発をどう変えていくのか、GitLabとしても非常に関心のあるテーマです。\n\n参加登録は無料です。ぜひこちらからお申し込みください：[登録はこちら](https://about.gitlab.com/events/aws-summits/)\n\n## GitLabチームに会いに来ませんか？ WeAreDevelopers World Congress !\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/z9hot8dhmj1k4gjxefmg.png)\n\n世界中の開発者とつながるこのイベントで、GitLabチームも皆さんとお会いできるのを楽しみにしています！スタンド A07 にぜひお立ち寄りください。GitLabのDevSecOpsプラットフォームが、ソフトウェアのデリバリーをどのように加速し、チーム間のコラボレーションを強化できるか等をご紹介します。\n\nCI/CDやセキュリティ自動化、開発フローの改善に興味がある方はもちろん、\\\n どんな質問にもチームメンバーがお答えしますので、お気軽にお声がけください。\n\nまた、金曜日には注目のセッションも：\n\n* 13:40〜 GitLab VP of Engineering、Maw Wildpanerによる講演\\\n   　「なぜ“セキュリティファースト開発”が、より良いソフトウェアを早く届ける鍵となるのか」\n* 16:30〜 GitLab VP of Strategy and Developer Relations、Emilio Salvadorが登壇するパネル「DevRelの戦略的な力：コミュニティからビジネスインパクトへ」\n\n👋 [ベルリンでお会いしましょう！](https://www.wearedevelopers.com/world-congress/)\n\n## 事例のご紹介：Thales \n\n![Thales](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/m85bcsqac7gitoewqfrb.png)\n\n今月の事例紹介は、なんと高度3万5千フィートの空の上からお届けします。Thales は、航空宇宙・防衛分野のグローバルリーダー企業。彼らは従来のDevOpsプロセスを、クラウドネイティブでCI/CD駆動のイノベーションエンジンへと進化させました。\n\nGitLabを活用して開発したのが、次世代の機内エンターテインメントシステム「FlytEDGE」。乗客ごとにパーソナライズされたコンテンツやサービスを提供しながら、デプロイ時間を95%短縮することに成功しています。分散チーム間のコラボレーションをスムーズにし、パイプライン全体に自動化を導入し、開発者がボトルネックなく素早くリリースできる環境を実現。その結果、従来の20倍のスピードでデプロイできるようになりました。\n\n👉 [こちらから導入事例を詳しくご覧ください](https://about.gitlab.com/ja-jp/customers/thales/)\n\n## 今月のおすすめ記事\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204283/agkyge3unfoilwmmk1c9.png)\n\n今月もGitLabのSlackチャンネルでは、たくさんの素晴らしいDevSecOpsの考えや情報がシェアされています。その中から特に注目されているものをご紹介します。\n\n* [https://japan.zdnet.com/article/35234560/](\u003C>) \n* \u003Chttps://vmblog.com/archive/2025/06/23/breaking-down-silos-gitlab-and-ibm-partner-to-modernize-mainframe-devops.aspx>\n* \u003Chttps://www.nextgov.com/ideas/2025/05/legacy-government-systems-enter-ai-era/405642/>\n* \u003Chttps://www.economiematin.fr/investissement-operateur-telecom-technologie-caronna>\n* \u003Chttps://thenewstack.io/accelerating-developer-velocity-with-effective-platform-teams/>\n* \u003Chttps://leaddev.com/uncategorized/how-get-most-out-ai-tooling>\n\n\n\n## 📌 今月の名言\n\n>  「何事も、それが成し遂げられるまでは不可能に思えるものだ。」\\\n>  – ネルソン・マンデラ\n\n高速なデプロイ、スマートなセキュリティ、次世代の開発者のための開発など、\\\nどんなに難しいことに取り組んでいても、あなたならきっとできます。\n\n🦊 また次回まで！\n\nGitLabコミュニティの一員でいてくださり、ありがとうございます！みなさんがGitLab 18でどんなものを作ってくださるのか、私たちも楽しみにしています。バーチャルイベントの登録と、AI機能の活用開始もお忘れなく。それではまた次回のMonday Mergeでお会いしましょう。Happy Merging! \\\n[The Developer Showの購読もお忘れなく！](https://www.linkedin.com/feed/update/urn:li:activity:7340777670714019840)\n\n[Fatima Sarah Khalid](\u003C>) | GitLab Developer Advocate\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204279/hdcjv0v3qqk53xjazumo.png)\n\n[](https://www.linkedin.com/feed/update/urn:li:activity:7340777670714019840)",[738],[110,721,920,675,270,762,702,280,678,700,763,722,764],{"featured":6,"template":681,"slug":1078},"monday-merge-2025-july-14","content:ja-jp:blog:monday-merge-2025-july-14.yml","Monday Merge 2025 July 14","ja-jp/blog/monday-merge-2025-july-14.yml","ja-jp/blog/monday-merge-2025-july-14",{"_path":1084,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1085,"content":1089,"config":1095,"_id":1097,"_type":16,"title":1098,"_source":17,"_file":1099,"_stem":1100,"_extension":20},"/ja-jp/blog/event-report-devopsdive2025",{"noIndex":6,"title":1086,"description":1087,"ogDescription":1087,"ogTitle":1086,"ogImage":1088},"GitLab DevOpsDive2025イベントレポート","2025年5月20日に開催した「GitLab DevOpsDive2025～セキュアなAI活用を実現する3つの方法とは～」のイベントレポートをお届けします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751591672/la3jvyygusvvh5ag7czj.jpg",{"title":1090,"authors":1091,"date":1092,"category":740,"tags":1093,"description":1087,"body":1094,"heroImage":1088},"【DevOpsDive2025レポート】AIはソフトウェア開発ライフサイクル全体にAIを適用することで、未来の開発が見えてくる",[738],"2025-07-10",[280],"GitLabは2025年5月20日、東京・新宿の１０９シネマズプレミアム新宿において、「DevOpsDive2025」を開催しました。新宿ミラノ座の跡地に建つ複合施設にあり、プレミアム映画館として名高い会場のワンフロアを貸し切り、来場者の皆様にはポップコーンとジュースをサービス。映画鑑賞気分でイベントを楽しんでいただきました。\n\n![DevOpsDive2025会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/rgayfhyenn1yjtkfeuxx.jpg)\n\n*会場の様子*\n\n振り返れば、[昨年のイベント](https://about.gitlab.com/ja-jp/blog/event-report-devopsdive2024summer/)は観世能楽堂で実施して、大好評でした。GitLabは、全世界でオフィスを持たない企業として知られていて、全員がリモートワークです。社員とお客様、デベロッパーの皆様と直接触れ合える機会ですから、自分たちにとっても参加者の皆様にとっても楽しいものにしたいと、会場選びから気合を入れて準備してきました。ぜひ次の機会もお楽しみに！\n\nさて、このブログ記事では、当日の講演の模様をお伝えします。テーマは、AIです。\n\n![DevOpsDive2025会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616954/z2xaf83c4javhoxdamrs.jpg)\n\n*会場の様子*\n\n世間では、日本企業のAI活用は遅れているとされています。しかし、基調講演に登壇したAndrew Haschkaは、具体的なデータを示し、実はそうでないと説明します。Haschkaは、豪州を拠点にアジア太平洋地域を中心にGitLabのField CTOとしてユーザーのさまざまな課題に向き合っており、ユーザーの事情を肌感覚で知っているため、説得力があります。\n\n![DevOpsDive2025で話すAndrew Haschka](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616947/dsnsqvj2zjxyaronfcnu.jpg)\n\n*GitLab Field CTO, Asia Pacific & Japan, Andrew Haschka*\n\nソフトウェア開発ライフサイクル（SDLC）においてAIを使用中の企業は、米国の34%に対して日本は48%。これは世界的に見ても高い数値です。ただし、Haschkaは「数字だけを見ると良い傾向なのですが、日本のAI活用はAIコーディングの部分にとどまっています」と釘を刺します。「残念ながら、ソフトウェア開発のライフサイクル全体を通したAI活用には至っていません」。\n\n![AI導入予定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617775/su4hqxb8krrxfcktyh6d.png)\n\n*SDLCで現在AIを使用している、または今後の導入を計画している割合*\n\nAIは、確かにコーディングをスピードアップしてくれます。一方で、セキュリティがないがしろにされてしまうリスクには注意が必要です。Haschkaは、あるインドネシアのGitLabユーザーを例に挙げました。その企業は、AIコーディングによって、開発スピードが大幅に向上し、同じ時間で完成するコード量が飛躍的に増えました。その結果、何が起きたのでしょう。コード量と同時にリスク要素が増えてしまい、脆弱性チェックに大変な手間がかかるようになってしまったのです。\n\nHaschkaは、「ただ、このケースはまだ良い方です。コードをきちんとチェックできているわけですから。“コンプライアンス・ガードレール”が正しく機能していることが証明されたと言えます」と話します。大きな問題は、SDLCに正しくガードレールを設置できておらず、コーディングのスピードアップにより、セキュリティがないがしろにされても、それに気づかない状態のまま放置されることで発生します。\n\nそうした事態に陥ることを防ぎ、セキュリティを担保しながらAIをソフトウェア開発に役立てるために、HaschkaはSDLCを通した3つの視点を持つ必要があるとします。まずは、**SDLCを透過的に管理できる統合されたプラットフォームを持つ**こと。GitLabのように統合的なプラットフォームでSDLC全体へのガバナンスを効かせることが必要で、ポイントソリューションの組み合わせで運用することは難しいのです。\n\n![DevOpsDive2025で話すAndrew Haschka](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616947/dow9hyavtyf7vooswmgw.jpg)\n\n*GitLab Field CTO, Asia Pacific & Japan, Andrew Haschka*\n\n次に、**SDLCに動的なセキュリティ対策を行き渡らせる**こと。対策における最大のテーマは脆弱性管理と依存性管理です。ライブラリやコンポーネントの依存性を可視化・管理し、セキュリティとライセンスについての承認プロセスを必要なポイントで埋め込みます。スキャンの強制実行も大切な要素で、この部分は自動化できるケースもあり、開発生産性を損なわずにセキュリティを担保することを期待できます。これらは、GitLabをSDLCのプラットフォームとして使っていれば、必要なプロセスに埋め込み、優れたガードレールとして機能させることができます。\n\n![GitLab Duoの利用形態](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617775/qdyujjzp99voh7h9qf6h.png)\n\n*GitLab Duoの利用形態*\n\n最後に、**必要に応じて[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)を活用する**こと。[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)は、クラウドを通さずローカル環境で動作するLLMで、データプライバシーを保護できることが特長。ローカルで稼働するため、機密情報を安全に扱うことができます。GitLab Duo Self Hosted Modelsを使うことで、[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)をGitLabと連携して運用することが可能になります。\n\nこれら3つの視点を持ち、SDLCを安全に運用するひとつのやり方として、Haschkaはプラットフォーム・エンジニアリング（PE）チームが主導的な立場を担うケースがあると指摘しています。\n\n## PEチームと開発部門が密な連携を取り、GitLabでSDLCを改革\n\n![Olympus株式会社柳田修太氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/soab0npkbzsac2bofvrc.jpg)\n\n*オリンパス株式会社 R&Dセンターオブソフトウェアエクセレンス, グローバル ソフトウェア開発インフラストラクチャ シニアディレクター 柳田 修太氏*\n\n続いては、オリンパス株式会社の事例講演です。同社は、内視鏡を主力に医療デバイスをワールドワイドに提供するメーカーです。そして、優れたPEチームがSDLCの改革で大きな役割を果たした企業の1つでもあります。同社のPEへの取り組みは、グローバルに展開されるソフトウェア開発の効率化、およびコスト適正化を図るためにスタートしました。\n\nスクリーンを背後に演壇に立った柳田 修太氏は、「弊社の開発サイクルは5から10年と長いものが多いことが特徴です。そのため、プロジェクト開始時のインフラが最新でなくなるケースが多いのです」と話します。「医療機器に組み込まれるソフトウェアの開発ですから、ソフトウェアを使う前のバリデーションが不可欠になります。クラウド化されていて特定のタイミングで強制的にバージョンアップされてしまうツールは、どれだけすばらしいものであっても、弊社の開発で使用することは困難です」。\n\nSDLCをよりセキュアにするためには、何らかのプラットフォームは必要になります。要件は、全世界でサポートしてくれるプラットフォームであること。そして、各国で異なる法規制に対応できること。さらに、自社のさまざまな開発要件への適用が可能であること。たとえば、アジャイル開発、仮想化、コンテナへの対応は当然のこと。特殊なニーズのある組み込みソフトウェアの開発プロセスにも対応できなければなりません。\n\n![Olympus株式会社柳田修太氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616952/cck02oslxsqyz0a7fppf.jpg)\n\n*オリンパス株式会社 R&Dセンターオブソフトウェアエクセレンス, グローバル ソフトウェア開発インフラストラクチャ シニアディレクター 柳田 修太氏*\n\nこうしてGitLabを選定したのですが、当初は抵抗もあったといいます。人命にかかわる医療機器の開発プロセスの改革ですから、万全を期する必要があるためです。それでも深い議論を重ね、開発部門と密な連携を取ったことで、少しずつGitLabを試してもらえるようになりました。そうして実際に成果を体験してもらったことで、開発者側からもGitLabを使いたいという声が上がってきます。\n\n柳田氏は、「ビルドのスピードアップが大きなポイントで、並行して複数のビルドを走らせられるため、開発生産性が高まりました。統合ツールとしてインフラ管理が楽なことも、開発現場に受け入れられた理由の大きなところでしょう。開発部門との関係性も高めることができ、いまでは新規プロジェクトを中心にユーザーがどんどん増えています」と話します。\n\nGitLabの浸透に伴ってアジャイルな開発スタイルでの活用も進み、開発スピードはさらに向上しました。GitLabでSDLCを包括的に管理できたことで運用コストを低減し、GitLab Runner（CI/CDのジョブ実行主体）を活用することでコンテナ環境における開発も大幅に効率化しています。こうしてHaschkaの指摘した3つの視点のうち、1と2は着実にオリンパスに定着しつつあります。\n\n今後取り組むのは、3のセキュアなAI活用です。現状は、オリンパスの開発者が作ったコードをAIの学習に使わないと明記したMoUをGitLabと締結した段階。社内でリスクアセスメントを実施し、本格運用に向けた試験運用を続けています。\n\n## 「AIコーディングだけをとってもローカルLLMの価値は大きい」\n\n![株式会社NTTデータグループ加藤耕也氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/k2rn3su6d1ollmyx4n05.jpg)\n\n\\\n*株式会社NTTデータグループ 技術革新統括本部 AI技術部 部長 加藤耕也氏*\n\n\\\n続いては、NTT DATAの講演です。NTT DATAは、生成AI活用コンセプト「SmartAgent™」を発表するなど、[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)ビジネスを積極的に展開しています。グローバルで1000件超の受注実績があり、SDLCの生産性向上目標としてFY25で50%、FY27には70%を掲げています。\n\n同社は社内でも生成AIをソフトウェア開発分野へ適用し、開発業務の効率化を目指しています。現在は、タスクの自動化を進めている段階。これは支援型AIと定義される分野ですが、次なるターゲットはいわゆる自律型AIへの進化です。自律型AIが実用段階に入れば、労働集約型産業はAI駆動型へと進化することが期待されています。NTT DATAは市場に先駆けて自律型AIの本格運用を進めることで、今年から2027年にかけてプロセスの自動化へと発展させ、さらに将来は開発業務のより広範な領域をまたいだ業務の自動化も実現させたい考えです。\n\n![株式会社NTTデータグループ市原大暉氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/yjgdcm3cgysc62vaouln.jpg)\n\n\\\n*株式会社NTTデータグループ 技術革新統括本部 AI技術部 市原大暉氏*\n\n![AI活用におけるオンプレの重要性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617776/xj4xv49xvtakt4lwqzae.png)\n*生成AI活用におけるプライベートクラウド・オンプレミスの重要性*\n\nAIの利用範囲が拡大することに伴い、よりセキュアなAIが求められるようになります。そのために[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)の注目が高まっているわけですが、上の表に示したように、[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)にはメリットもデメリットもあります。それでも機密情報を扱うためには閉域網での開発が必須です。また、NTT DATAでは、顧客に対して独自に実施したヒアリングの結果、AIを独自にチューニングしてオリジナルな学習の方向性を定めたいというニーズが今後増えてくると見ています。これは、公共分野をはじめ、金融、製造、観光などさまざまな業種に共通するニーズです。講演した加藤 耕也氏は、「実は、AIコーディングだけをとっても[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)の価値は大きいのです。そのプロセスにも強力なガバナンスを効かせられるようになりますから」と話します。同社では、すでに社内で約3,000ユーザーが[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)を使って開発プロジェクトを進めています。\n\n![GitLab Duoを用いた検証結果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617777/b0deb8vbv61osovquall.png)\n\n*GitLab Duoを用いた検証結果*\n\nそしてこの日、GitLab Duoを用いた[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/) AIコーディング環境の検証結果を明らかにしてくれました。この検証では、機能面・非機能面での実用性を73項目で精査し、十分な精度を得られたことが報告されています。\n\n## 「ローカルLLMは究極の安全性をもたらす」\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616953/nf6jwyqj4l9xhxbsf2nb.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\n最後のセッションに登壇したのは、GitLabの佐々木 直晴。この日のすべてのセッションを振り返りながら、さまざまなポイントの背景や詳細について語りました。中でも印象深かったのは、AIがコーディングすることでセキュリティレベルが低下する背景についてです。\n\n佐々木は、CSETが昨年公開した資料を示し、AIは人間が書いた脆弱性を含むコードを学習データとするためそれを模倣してしまう可能性があると警告しました。「AIは、 “機能的に正しく動くコードを素早く出力”しようとします。そのとき、セキュリティの観点で重要な構成要素を無視してしまうことがあるようです。たとえば、例外処理や入力チェックなどはコードに入っていなくても機能的には正しく動くため、AIの提案からは抜け漏れやすいということが考えられます」。[ローカルLLM](https://about.gitlab.com/ja-jp/blog/what-is-local-llm/)については、「自社の強みが流出するリスクを抑え、究極的な安全性をもたらす存在」とし、実際に多くの企業がそこを目指すだろうと展望しています。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616954/nswoq6ryvcrdph9waaam.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\n佐々木は、Haschka の3つの視点を目指すにあたり、GitLabはユーザーのAI利用時にもプライバシーや知的財産権を保護しながらSDLC全体をAIでサポートできるプラットフォームであり続けるとも述べ、AIに取り組むなら安心してGitLabを採用してほしいと会場に呼びかけました。\n\n*\\*SmartAgentは日本国内における株式会社NTTデータグループの商標です。*",{"featured":92,"template":681,"slug":1096},"event-report-devopsdive2025","content:ja-jp:blog:event-report-devopsdive2025.yml","Event Report Devopsdive2025","ja-jp/blog/event-report-devopsdive2025.yml","ja-jp/blog/event-report-devopsdive2025",{"_path":1102,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1103,"content":1107,"config":1115,"_id":1117,"_type":16,"title":1118,"_source":17,"_file":1119,"_stem":1120,"_extension":20},"/ja-jp/blog/fast-and-secure-ai-agent-deployment-to-google-cloud-with-gitlab",{"noIndex":6,"title":1104,"description":1105,"ogImage":1106},"GitLabで自律型AIをGoogle Cloudに安全・高速デプロイ","デモアプリ付きの詳細なガイドに従って、自律型AIの使い方を、GitLabのネイティブインテグレーションやCI/CDコンポーネントとあわせて学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749670563/Blog/Hero%20Images/cloudcomputing.jpg",{"title":1104,"description":1105,"authors":1108,"heroImage":1110,"date":1111,"body":1112,"category":787,"tags":1113},[1109],"Regnard Raquedan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670563/Blog/Hero%20Images/cloudcomputing.jpg","2025-07-07","[自律型AI](https://about.gitlab.com/ja-jp/topics/agentic-ai/)の登場により、インテリジェントなアプリケーションの構築方法は大きく変わりつつありますが、\n\nAIエージェントを安全かつ効率的にデプロイするのは簡単ではありません。\n\nこのチュートリアルでは、\n\nGoogleのAgent Development Kit（[ADK](https://cloud.google.com/vertex-ai/generative-ai/docs/agent-development-kit/quickstart)）で構築したAIエージェントを、\n\n[GitLabのネイティブインテグレーション](https://cloud.google.com/blog/topics/partners/understand-the-google-cloud-gitlab-integration)と[CI/CDコンポーネント](https://docs.gitlab.com/ci/components/)を使って\n\nCloud Runにデプロイする方法を\n\n学びます。\n\n\n## AIエージェントの基礎知識と注目される理由\n\n\n自律型AIは、人工知能の分野における大きな進化と言えるでしょう。従来の生成AIツールが常に人間からの指示を必要とするのに対し、AIエージェントは高度な言語モデルや自然言語処理を活用して、自律的に行動を起こします。自律型AIはリクエストを理解し、意思決定を行い、複数のステップからなる計画を実行して、目標を自ら達成できます。\n\n\nこのチュートリアルでは、GoogleのADKを使用します。ADKは、AIエージェントの開発とデプロイに対応した、柔軟でモジュール化されたフレームワークです。GeminiやGoogleのエコシステム向けに最適化されていますが、モデルやデプロイ方法に依存せず、他のフレームワークとの互換性も考慮して設計されています。\n\n\n## デモアプリの紹介：Canada City Advisor\n\n\nデプロイプロセスを実演するための実用的な例として「Canada City Advisor」を使います。ユーザーの希望や条件に基づいて、理想的なカナダの都市を提案するAIエージェントです。\n\n\nその仕組みは以下の通りです。\n\n\n* ユーザーが予算条件やライフスタイルの希望を入力します。\n\n* ルートエージェントが以下2つのサブエージェントを統括します。\n\n  * 経済的な制約を評価する予算分析エージェント。カナダ住宅金融公社から取得したデータを使用します。\n  * ユーザーの希望に合う都市を提案するライフスタイル分析エージェント。[Open-Meteo](https://open-meteo.com/)から取得した適切な都市情報に基づく天気情報サービスも提供します。\n* システムがユーザーに合った都市の候補を生成します。\n\n\n異なる専門性を持つAIエージェントが連動して複雑な問題を解決するこのマルチエージェント構成により、自律型AIの強みが活かされます。サブエージェントは、ルートエージェントが予算やライフスタイルの分析が必要と判断したときにのみ呼び出されます。\n\n\n![自律型AIを活用したデモアプリ開発のマルチエージェント構成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751576568/obgxpxvlnxtzifddrrz1.png)\n\n\n## 前提条件\n\n\n始める前に、以下のものが準備できていることを確認してください。\n\n\n* 以下のAPIが有効になっているGoogle Cloudプロジェクト\n\n  * Cloud Run API  \n  * Artifact Registry API  \n  * Vertex AI API  \n* ソースコード用のGitLabプロジェクト\n\n* GitLabとGoogle Cloudの両方に対する適切な権限\n\n\n**ステップ1：ワークロードアイデンティティフェデレーションによるIAMインテグレーションを設定する**\n\n\n最初のステップでは、[Workload Identity連携](https://cloud.google.com/iam/docs/workload-identity-federation)を使用して、GitLabとGoogle Cloudの間で安全なキーレス認証を確立します。これにより、サービスアカウントキーが不要となり、セキュリティが向上します。\n\n\nGitLabプロジェクトでの手順は以下のとおりです。\n\n\n1. **設定 > インテグレーション > Google Cloud IAM**の順に移動します。\n\n2. 以下の情報を入力します。\n\n   * **プロジェクトID**：使用しているGoogle CloudプロジェクトのID\n   * **プロジェクト番号**：Google Cloudコンソールで確認できるプロジェクト番号\n     Workload Identityプールの固有識別子\n   * **プロバイダーID**：アイデンティティプロバイダーの固有識別子\n\nGitLabがスクリプトを生成します。このスクリプトをコピーして、Google Cloud Shellで実行し、Workload Identity連携を作成します。\n\n\n**ステップ2：Google Artifact Registryのインテグレーションを設定する**\n\n\n次に、コンテナイメージを保存するGoogle Artifact Registryとの接続を設定します。\n\n\n1. GitLabで、**設定 > インテグレーション > Google Artifact Registry**の順に移動します。\n\n2. 以下の情報を入力します。\n\n   * **Google CloudプロジェクトID**：ステップ1と同じプロジェクトID\n   * **リポジトリ名**：既存のArtifact Registryリポジトリの名前\n   * **場所**：リポジトリが存在するリージョン\n\n**重要**：リポジトリはすでにArtifact Registryに存在している必要があります。この設定操作では、GitLabが新しいリポジトリを自動で作成することはありません。\n\n\nGitLabは、必要な権限を設定するためのコマンドを生成します。これをGoogle Cloud Shellで実行します。\n\n\nさらに、Cloud Runへのデプロイのために、サービスプリンシパルに以下のロールを追加します。\n\n\n* `roles/run.admin`\n\n* `roles/iam.serviceAccountUser`\n\n* `roles/cloudbuild.builds.editor`\n\n\n以下のgcloudコマンドを使用して、これらのロールを追加できます。\n\n\n```shell\n\nGCP_PROJECT_ID=\"\u003Cyour-project-id>\" #replace\n\n\nGCP_PROJECT_NUMBER=\"\u003Cyour-project-number>\" #replace\n\n\nGCP_WORKLOAD_IDENTITY_POOL=\"\u003Cyour-pool-id>\" #replace\n\n\n\ngcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \\\n  --member=\"principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true\" \\\n  --role='roles/run.admin'\n\ngcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \\\n  --member=\"principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true\" \\\n  --role='roles/iam.serviceAccountUser'\n\ngcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \\\n  --member=\"principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true\" \\\n  --role='roles/cloudbuild.builds.editor'\n```\n\n\n**ステップ3：CI/CDパイプラインを作成する**\n\n\nここからが本番です。デプロイ用のパイプラインを構築しましょう！GitLabのCI/CDコンポーネントを使用すると、非常に簡単に作成できます。\n\n\nプロジェクトのルートに `.gitlab-ci.yml` ファイルを作成します。\n\n\n```unset\n\nstages:\n  - build\n  - test\n  - upload\n  - deploy\n\nvariables:\n  GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA\n  AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA\n\nbuild:\n  image: docker:24.0.5\n  stage: build\n  services:\n    - docker:24.0.5-dind\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker build -t $GITLAB_IMAGE .\n    - docker push $GITLAB_IMAGE\n\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.gitlab-ci.yml\n  - template: Jobs/SAST.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml\n  - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main\n    inputs:\n      stage: upload\n      source: $GITLAB_IMAGE\n      target: $AR_IMAGE\n  - component: gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@main\n    inputs:\n      stage: deploy\n      project_id: \"\u003Cyour-project-id>\" #replace\n      service: \"canadian-city\"\n      region: \"us-central1\"\n      image: $AR_IMAGE\n```\n\n\nこのパイプラインは、以下の4つのステージで構成されています。\n\n\n1. **Build**：AIエージェントを使用してDockerコンテナを作成します\n\n2. **Test**：セキュリティスキャン（コンテナスキャン、依存関係スキャン、SAST）を実行します\n\n3. **Upload**：コンテナをArtifact Registryにプッシュします\n\n4. **Deploy**：Cloud Runにデプロイします\n\n\n[GitLabのCI/CDコンポーネント](https://docs.gitlab.com/ci/components/)を使う大きなメリットは、いくつかのパラメーターを指定するだけで、認証やデプロイの複雑な処理をすべてコンポーネント側が自動で行ってくれる点です。\n\n\n**ステップ4：デプロイとテスト**\n\n\nすべての設定が完了したら、いよいよデプロイの実行です。\n\n\n1. コードと `.gitlab-ci.yml` をGitLabリポジトリにコミットします。\n\n2. パイプラインは自動的に実行されます。\n\n3. GitLabのCI/CDインターフェースでパイプラインの進行状況を確認します。\n\n4. 完了後、Google CloudコンソールでCloud RunのURLを確認できます。\n\n\n各ステージが順番に実行される様子を確認できます。\n\n\n* Buildステージでコンテナが作成されます。\n\n* Testステージで包括的なセキュリティスキャンが実行されます。\n\n* UploadステージでArtifact Registryにプッシュされます。\n\n* DeployステージでCloud Runのサービスが作成または更新されます。\n\n\n## セキュリティ上のメリット\n\n\nこの手法には、以下のようなセキュリティ上の利点があります。\n\n\n* **長期間有効な認証情報が不要**：Workload identity連携により、サービスアカウントキーが不要になります。\n\n* **自動セキュリティスキャン**：すべてのデプロイで脆弱性がスキャンされます。\n\n* **監査証跡**：誰が何をいつデプロイしたのかを完全に可視化します。\n\n* **最小権限の原則**：きめ細かなIAMロールによりアクセスが制限されます。\n\n\n## まとめ\n\n\nGitLabのセキュリティ機能とGoogle Cloudの強力なAIおよびサーバーレスプラットフォームを組み合わせることで、安全でスケーラブルなAIエージェントをデプロイできます。GitLabとGoogle Cloudのインテグレーションによって、従来こうしたデプロイに伴っていた複雑さの多くが解消されます。\n\n\n> このチュートリアルの[サンプルコード\n\n> 全文](https://gitlab.com/gitlab-partners-public/google-cloud/demos/ai-agent-deployment)を使えば、\n\n> すぐに始められます。GitLabをまだご利用でない場合は、ぜひ[無料トライアル](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)でDevSecOpsプラットフォームをご体験ください。\n\n\n\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)*\n\n\n*（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[1114],"google",{"featured":6,"template":681,"slug":1116},"fast-and-secure-ai-agent-deployment-to-google-cloud-with-gitlab","content:ja-jp:blog:fast-and-secure-ai-agent-deployment-to-google-cloud-with-gitlab.yml","Fast And Secure Ai Agent Deployment To Google Cloud With Gitlab","ja-jp/blog/fast-and-secure-ai-agent-deployment-to-google-cloud-with-gitlab.yml","ja-jp/blog/fast-and-secure-ai-agent-deployment-to-google-cloud-with-gitlab",{"_path":1122,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1123,"content":1126,"config":1134,"_id":1136,"_type":16,"title":1137,"_source":17,"_file":1138,"_stem":1139,"_extension":20},"/ja-jp/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"noIndex":6,"title":1124,"description":1125},"GitLab Duoエージェントプラットフォーム","GitLab Duoエージェントプラットフォームは自律型AIを活用し、ソフトウェア開発ライフサイクルにわたる人間とAIエージェントのコラボレーションを実現。",{"heroImage":1127,"title":1128,"description":1129,"authors":1130,"date":1131,"body":1132,"category":787,"tags":1133},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750687578/esmflevxk5bf3eezjhwk.png","GitLab Duo Agent Platform","GitLab Duo Agent Platformは自律型AIを活用し、ソフトウェア開発ライフサイクルにわたる人間とAIエージェントのコラボレーションを実現。",[901],"2025-06-24","GitLab Duo Workflowの進化版である「GitLab Duo Agent Platform」をご紹介します。この革新的なプラットフォームを導入すると、ソフトウェア開発ライフサイクル全体をとおして自律型機能を利用できます。これにより、チームは複数のAIエージェントと並行して作業を進められます。\n\n出社後の流れが次のように変わることを想像してみてください。\n\n* チームが取り組んでいるエピックに関する詳細な調査、過去1週間のすべてのコントリビュートに関する最新情報の収集、最近追加された機能に基づくリリース記事の提案、これらすべてのタスクを1体のAIエージェントに割り当てます。\n* 同時に、別の複数のAIエージェントにいくつかのアクセシビリティバグの分析、およびそれらの修正に必要なコード変更を依頼します。\n* さらに並行して、自分が加えた複雑なコード変更をチームメンバーに送信して正式なレビューを受ける前に、別のAIエージェントにレビュー・フィードバックを依頼します。\n* 最後に、プロジェクト全体での調査が必要な新たな脆弱性についてセキュリティチームから通知があった場合は、セキュリティエージェントにその調査タスクを割り当てます。\n\nこれらのタスクはすべて同時に実行されます。その間、アーキテクチャに関する決定や、独創的な問題解決、戦略的な技術作業に専念できます。Agent Platformでは、5体、10体、さらには100体もの専門的なAIエージェントにタスクを委任できます。これらのAIエージェントはコードだけでなく、CIジョブログや計画作業アイテムなど、プロジェクトの全コンテキストに基づいてタスクを実行します。これまでやらざるを得なかった面倒な作業を自動化することで、やりがいのある作業に専念できるようになります。\n\n**このアプローチの目的は、デベロッパーを置き換えることではなく、日常的なタスクにより生じる業務の非効率性を解消し、人間の創造性と専門知識を活かせるようにすることです。** これこそが、GitLab Duo Agent Platformがもたらす未来です。\n\n## GitLab Duo Agent Platformとは？\n\nAgent Platformは、チームの生産性とサイクルタイムの大幅な改善を支援するよう設計されており、ソフトウェア開発ライフサイクル全体にわたるエンジニアと[AIエージェント](https://about.gitlab.com/ja-jp/topics/agentic-ai/)の多対多のコラボレーションを実現します。\n\nGitLabのセキュアな基盤上に構築されたAgent Platformは、カスタマイズおよび拡張が可能です。デベロッパーはAgent Platformを使用することで、ソフトウェア開発ライフサイクル全体のコンテキストを活用してソフトウェアエンジニアリングに関するあらゆる種類の問題に取り組むAIエージェントを構築できます。\n\n専門的なAIエージェントとカスタムワークフローを備えたAgent Platformは、コード作成だけでなく、以下を含むほぼすべての作業をお手伝いできます。\n\n* イシューの実装\n* 大規模な移行や依存関係の更新\n* ドキュメントやリリース記事の自動作成\n* 破損したパイプラインの修復\n* インシデント調査のサポート\n* トピックに関するステータスや情報の詳しい調査\n* バックログ管理\n* 脆弱性の修正\n* 特定のタイプのコード（データベースなど）のレビュー\n* 既存のモジュールをベースとした社内ツールの迅速な構築\n* その他多数\n\nすぐに利用できるAIエージェントがあらかじめ用意されており、それらをカスタマイズまたは拡張することも可能です。現在、数十社のお客様の協力のもと、Agent Platformのベータテストを実施しています。ベータ版は、近日中にさらに多くの方々に公開される予定です。\n\n以下の動画では、Agent Platformを実際に使用する様子をご覧いただけます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1095679084?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agent Platform Demo Clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## ツールも、モデルも、エージェントも、自分で選べる\n\nGitLabエージェントは、標準的なModel Context Protocol（MCP）とAgent2Agent（A2A）フレームワークを通じて、お好みのコード作成開発ツール（Cursor、Claude Code、Windsurf、OpenAI Codexなど）とシームレスに相互運用できます。これは、GitLabをオープンプラットフォームとして提供するという方針を反映しています。\n\nAgent Platformは、技術スタック内のどの開発ツールからのコードのコントリビュートも受け入れます。それがデベロッパーによって記述されたものであれ、AIエージェントが生成したものであれ、関係ありません。つまり、エージェント機能を統合しても、これまで使い慣れたワークフローやツールは引き続きシームレスに動作します。\n\nAgent Platformは、[GitLabの選定基準を満たす](https://about.gitlab.com/ja-jp/ai-transparency-center/#ai-continuity-plan)承認済みの言語モデルであれば、どれでも利用できます。セキュリティ要件が厳しい組織向けに、完全にインターネットに接続されていない（エアギャップ）環境における承認済みのセルフホストモデルの実行もサポートしています。そのため、インフラ要件やセキュリティポリシーによって、自律型開発の実施を制限されることはありません。\n\n## コンテキストを把握して動く、GitLab Duoエージェント\n\n単に便利なAIツールと本当にインテリジェントなAIエージェントの違いは、コンテキストを理解しているかどうかにあります。Agent Platformでは、AIエージェントは単独で動作しません。実際に開発作業が行われるプラットフォームに深く統合されています。\n\nすべてのAIエージェントは、未解決のイシューとその履歴、イシューを解決したマージリクエスト、コードの構造と背後にある理論的根拠、CI/CDパイプラインの設定、セキュリティ検出、コンプライアンス要件、そしてこれらすべてのコンポーネントの複雑な関係など、プロジェクトの全体像を自動的に把握します。\n\nAIエージェントもエンジニアと同様、安全なソフトウェアをよりスピーディーにリリースするために役立つコンテキストをすべて把握しています。AIエージェントは、コードに関する質問に答えるだけでなく、提案された変更がデプロイパイプラインにどのような影響を及ぼすかといったインサイトを提供したり、現行のコンプライアンス規則に基づいてセキュリティの改善を提案したりできます。GitLabのDevSecOpsプラットフォームで作業すればするほど、AIエージェントはより賢くなります。\n\n## エージェントがチームをスケールする際も、コントロールを維持\n\nAIエージェントとの信頼関係の構築は、新しいチームメンバーとの信頼を築くことと本質的には変わりません。AIエージェントの仕事を見ながらアプローチを理解し、実際の遂行能力に応じて徐々にまかせる作業を増やしていく必要があります。\n\nこれこそが、当社のエージェント承認ワークフローの根底にある考え方です。AIエージェントは、コードや環境に変更を加える前に、イシューについて把握している内容、採用するアプローチ、実行しようとしている具体的なアクションなど、明確な計画を提示します。必要に応じて再検討もしくは承認するか、指示を出し直すことができます。時間が経つにつれ、AIエージェントが一貫して質の高い作業を行えるようになるため、複雑な作業や重要な業務は引き続き監視しつつ、日常的なタスクについてはAIエージェントにより大きな自律性を与えられるようになります。\n\n## コミュニティとカスタマイズ性のために構築されたプラットフォーム\n\nGitLabは常にコミュニティのみなさまからのコントリビュートによって成長してきました。今年はお客様からのコントリビュートが過去最多を記録し、大きな節目の年となりました。オープンフレームワークアプローチを通じて、こうしたコラボレーションの輪にAIエージェントも加われるようになりました。\n\nAgent Platformでは、GitLabが構築したAIエージェントを利用できるだけでなく、コミュニティ一人ひとりが、それぞれ固有のエンジニアリング上の課題を解決するために専用エージェントを作成できます。エージェントプラットフォームは、特定のコーディング標準の理解、カスタムツールチェーンとの統合、ドメイン固有のタスクの処理など、任せたい作業に応じた専用エージェントを構築するためのビルディングブロックを提供します。\n\nこのコミュニティ主導のモデルは、[CI/CDカタログ](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)と同様、グローバルな連携を通じてGitLabコミュニティの力が発揮される好循環を生み出します。さまざまな実際のユースケースがイノベーションが促進し、企業からのフィードバックが信頼性とセキュリティを保証します。そして、共有されたソリューションはコミュニティ全体に利益をもたらします。GitLabを成功に導いてきたこの協調的なアプローチが、いま、自律型開発という領域にも適用されようとしています。\n\n## 開始するには\n\nGitLab 18のPremiumおよびUltimateのGitLab.comユーザーライセンスで利用可能になった[GitLab Duo Agentic Chat](https://about.gitlab.com/ja-jp/blog/gitlab-duo-chat-gets-agentic-ai-makeover/)を試された方は、AIエージェントを開発ワークフローに組み込むことで何が実現できるのか、その可能性をすでに実感されていることでしょう。\n\nエージェントプラットフォームの機能や、GitLabが現在取り組んでいる内容については、[GitLab 18のリリースイベントの録画ウェブキャストのデモ](https://about.gitlab.com/ja-jp/eighteen/)をご覧ください。\n\nエージェントプラットフォームをいち早く使ってみたい方は、[Agent Platformベータ版のウェイトリスト](https://about.gitlab.com/gitlab-duo/agent-platform/)にご登録ください。今年の夏には、さらに多くのチームにご利用いただけるようになる予定です。また、年内に予定されているGitLab 18のリリースを通じて、新たなエージェント機能も順次提供されます。一般公開は、今年の冬を予定しています。\n\n*免責事項：この発表には、今後の製品、機能、および機能性に関する情報が含まれています。本発表に含まれる情報は、情報提供のみを目的としている点にご留意ください。購入や計画の際に、この情報のみに依拠することはお控えください。すべてのプロジェクトと同様に、このプレゼンテーションおよびリンク先のページに記載されている項目は、変更または遅れる可能性があります。製品、機能および機能性の開発、リリース、タイミングは、GitLab Inc.の独自の裁量に委ねられます。*\n\n## 詳細はこちら\n\n* [バイブコーディングから自律型AIへ：技術リーダー向けのロードマップ](https://about.gitlab.com/the-source/ai/from-vibe-coding-to-agentic-ai-a-roadmap-for-technical-leaders/)\n* [自律型AIとは](https://about.gitlab.com/ja-jp/topics/agentic-ai/)\n* [DevOpsの自動化とAIエージェント](https://about.gitlab.com/topics/agentic-ai/devops-automation-ai-agents/)\n* [AIにより強化されたソフトウェア開発：DevOps向けの自律型AI](https://about.gitlab.com/topics/agentic-ai/ai-augmented-software-development/)\n* [AI主導のコード開発：コードセキュリティの新たな時代](https://about.gitlab.com/topics/agentic-ai/ai-code-analysis/)",[702],{"featured":92,"template":681,"slug":1135},"gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops","content:ja-jp:blog:gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops.yml","Gitlab Duo Agent Platform What Is Next For Intelligent Devsecops","ja-jp/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops.yml","ja-jp/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"_path":1141,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1142,"content":1145,"config":1152,"_id":1154,"_type":16,"title":1155,"_source":17,"_file":1156,"_stem":1157,"_extension":20},"/ja-jp/blog/gitlab-18-01-release",{"noIndex":6,"title":1143,"description":1144},"GitLab 18.1 リリース","GitLab 18.1でリリースした最新機能をご紹介します。",{"heroImage":1146,"body":1147,"authors":1148,"updatedDate":1149,"date":1150,"title":1143,"tags":1151,"description":1144,"category":701},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750396128/vak5nlffgockma115495.png","本ブログは、[GitLab 18.1 Release](https://about.gitlab.com/releases/2025/06/19/gitlab-18-1-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n## Maven仮想レジストリ（ベータ版）とGitLab Duoコードレビュー搭載のGitLab 18.1リリース\n\nこのたび、GitLab 18.1のリリースを発表しました。このリリースでは、Maven仮想レジストリ（ベータ版）、GitLab Duoコードレビュー、漏洩パスワードの検出、SLSAレベル1準拠を実現するCI/CDコンポーネントなど、さまざまな機能が追加されました。\n\nこれらの機能は、今回のリリースに含まれる110件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 18.1には、GitLabコミュニティのユーザーから311件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースもユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ](https://about.gitlab.com/upcoming-releases/)をご覧ください。\n\n[GitLab 18.1のリリースでは、Maven仮想レジストリ（ベータ版）とGitLab Duoコードレビューが追加されました。クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+18.1%E3%81%AE%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%A7%E3%81%AF%E3%80%81Maven%E4%BB%AE%E6%83%B3%E3%83%AC%E3%82%B8%E3%82%B9%E3%83%88%E3%83%AA%EF%BC%88%E3%83%99%E3%83%BC%E3%82%BF%E7%89%88%EF%BC%89%E3%81%A8GitLab+Duo%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%8C%E8%BF%BD%E5%8A%A0%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%81%97%E3%81%A6SNS%E3%81%A7%E5%85%B1%E6%9C%89%E3%81%97%E3%81%BE%E3%81%97%E3%82%87%E3%81%86%EF%BC%81&url=https://about.gitlab.com/ja-jp/blog/gitlab-18-1-release/&hashtags=)\n\n## 今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は[](https://gitlab.com/karras)[Chaitanya Sonwane](https://gitlab.com/chaitanyason9)さんです\n\n\u003Cimg src=\"https://about.gitlab.com/images/notable-contributor-logo.svg\">\n\nChaitanya Sonwaneさんは、継続的な認証機能の強化により、GitLabのセキュリティ機能向上に貢献しています。[2025年に13件のコントリビュートがマージされ](https://contributors.gitlab.com/users/chaitanyason9?fromDate=2025-01-01&toDate=2025-12-31)、認証情報インベントリのフィルタリング、サービスアカウント管理、作業アイテムの使いやすさが向上しました。以前には[GitLab 17.11の主要機能](https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/#token-statistics-for-service-account-management)としてサービスアカウントのトークン統計情報をひと目で確認できる機能を手がけ、サービスアカウントの管理を容易にする「一目でわかる」情報を提供しました。Chaitanyaさんは現在、[作業アイテムリストのソート設定をコンテキスト固有にする改善](https://gitlab.com/gitlab-org/gitlab/-/issues/503587)に取り組み、GitLabの製品計画におけるユーザーエクスペリエンスをさらに向上させています。\n\nChaitanyaさんの活躍により、GitLabを利用する組織のセキュリティが強化され、サービスアカウントの使用状況がプロジェクト全体で把握しやすくなりました。現在では、チームが認証情報をより効果的に追跡、ローテーションできるようになったことで、セキュリティの脆弱性につながりかねない、未管理の認証情報のリスクが軽減されています。\n\n「認証情報インベントリとサービスアカウントに対するChaitanyaさんのコントリビュートは、セキュリティ分野において非常に貴重なものです」と[Eduardo Sanz-Garcia（](https://gitlab.com/eduardosanz)ソフトウェアサプライチェーンセキュリティステージの認証グループのシニアフロントエンドエンジニア）は語ります。Eduardoは、[GitLabの認証チーム](https://about.gitlab.com/direction/software_supply_chain_security/authentication/)による推薦も後押ししました。\n\nさらに彼は「Chaitanyaさんは、トークン統計のコンセプトの実装に貢献してくれました。認証情報インベントリの取り組みにより、認証情報の追跡とモニタリングを強化する、非常に要望の多かった機能が提供されたのです。非常に素晴らしいコントリビュートでした」とも付け加えています。\n\nChaitanyaさんはTATA AIGのソフトウェアエンジニアです。セキュリティ上の課題に積極的に取り組み、自らのコントリビュートを改善するための継続的なフォローアップを行っています。\n\nこの場を借りて、GitLabのセキュリティ基盤やその他の製品にコントリビュートしてくれたChaitanyaさんに感謝します！\n\n## GitLab 18.1リリースの主な改善点\n\n### Maven仮想レジストリがベータ版で利用可能に\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nMaven仮想レジストリは、GitLabでのMaven依存関係管理を簡素化するものです。Maven仮想レジストリを使用しない場合、Maven Central、プライベートリポジトリ、GitLabパッケージレジストリからの依存関係にアクセスするための設定を個別に行う必要があります。こうしたアプローチでは、リポジトリへの順次クエリによってビルドが遅くなり、セキュリティ監査とコンプライアンスレポート作成が複雑になります。\n\nMaven仮想レジストリは、複数のアップストリームリポジトリを単一のエンドポイントに集約することで、このような問題に対処します。プラットフォームエンジニアは、1つのURLを介してMaven Central、プライベートレジストリ、GitLabパッケージレジストリを設定できます。インテリジェントキャッシュはビルドパフォーマンスを向上させ、GitLabの認証システムと統合されます。これにより、設定オーバーヘッドの削減、ビルドの高速化、セキュリティとコンプライアンス向上を目的として一元管理されたアクセス制御が実現します。\n\nMaven仮想レジストリは現在、GitLab.comとGitLab Self-Managedの両方で、GitLab PremiumおよびUltimateのお客様にベータ版として提供されています。一般公開リリースには、レジストリ設定用のWebベースUI、共有可能なアップストリーム機能、キャッシュ管理のためのライフサイクルポリシー、強化された分析機能などが追加される予定です。現在のベータ版では、トップレベルグループあたり最大20の仮想レジストリ、仮想レジストリあたり最大20のアップストリームまでと制限されており、ベータ期間中の設定はAPIのみで行えます。\n\n企業のお客様を対象としたMaven仮想レジストリベータプログラムを実施しています。最終リリースの品質向上にご協力をお願いいたします。ベータ版にご参加いただくお客様には、機能への早期アクセス、GitLab製品チームとの直接のやり取り、評価期間中の優先サポートを提供します。ベータプログラムに参加するには、[イシュー498139](https://gitlab.com/gitlab-org/gitlab/-/issues/498139)でご興味があることをお知らせいただき、ユースケースの詳細を提供してください。また、フィードバックや提案は[イシュー543045](https://gitlab.com/gitlab-org/gitlab/-/issues/543045)にお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/packages/virtual_registry/maven/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14137)[](https://gitlab.com/groups/gitlab-org/-/epics/14137)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZkIkaJDEcEE?si=F7dfSCtzBIv02_is\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### GitLab Duoコードレビューが一般公開開始\n\n> SaaS: Premium、Ultimate、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duoコードレビューが一般公開され、本番環境で使用できるようになりました。AI搭載のこのコードレビューアシスタントは、マージリクエストに対して的確で自動化されたフィードバックを提供し、従来のコードレビュープロセスを変革します。これにより、人間のレビュアーが関与する前に、潜在的なバグ、セキュリティの脆弱性、コード品質の問題を特定できるため、レビュープロセス全体を徹底的かつ効率的に行うことができます。GitLab Duoコードレビューには以下の機能が含まれています。\n\n* **自動初期レビュー**：コードの変更内容を分析し、潜在的な問題、改善点、ベストプラクティスに関する包括的なフィードバックを提供します。  \n* **対話ベースで改善**：マージリクエストコメントで`@GitLabDuo`をメンションすると、特定の変更や質問に対する的確なフィードバックを受け取ることができます。  \n* **実行可能な提案**：多くの提案をブラウザから直接適用できるため、改善プロセスが効率化されます。  \n* **文脈を理解した分析**：変更されたファイルの内容を理解し、プロジェクトに特化した関連性の高い推奨事項を提供します。\n\nGitLab Duoコードレビューをリクエストするには、次の手順に従います。\n\n* マージリクエストで、`/assign_reviewer` `@GitLabDuo`クイックアクションを使用して`@GitLabDuo`をレビュアーとして追加するか、GitLab Duoをレビュアーとして直接割り当てます。  \n* コメントで`@GitLabDuo`をメンションすると、ディスカッションスレッドで特定の質問をしたり、詳細なフィードバックをリクエストしたりできます。  \n* プロジェクト設定で自動レビューを有効にすると、GitLab Duoがすべての新しいマージリクエストを自動的にレビューします。\n\nGitLab Duoコードレビューを活用することで、チームがより高いコード品質基準を維持しながら、手動レビューサイクルに費やす時間を短縮できます。問題を早期に発見し、教育的なフィードバックを提供することで、開発チームにとって品質管理ツールと学習ツールの両方の役割を果たします。\n\nベータ版時のGitLab Duoコードレビューの動作はこちらを[ご覧ください](https://www.youtube.com/watch?v=FlHqfMMfbzQ)。\n\n[イシュー517386](https://gitlab.com/gitlab-org/gitlab/-/issues/517386)でご経験やフィードバックをお寄せいただき、本機能の継続的な改善にご協力ください。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13979)[](https://gitlab.com/groups/gitlab-org/-/epics/13979)\n\n![GitLab Duoコードレビューが一般公開開始](https://about.gitlab.com/images/18_1/create-duo-code-review.png)\n\n### ネイティブGitLab認証情報の漏洩パスワード検出\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: -\n\nGitLab.comへのサインイン時に、アカウント認証情報の安全なチェックが実行されるようになりました。お使いのパスワードが既知の情報漏洩に含まれている場合、GitLabにバナーが表示され、メール通知が送信されます。これらの通知には、認証情報の更新手順が記載されています。\n\nセキュリティを最大限に高めるために、GitLabでは以下を推奨しています。\n\n* GitLab専用の強力なパスワードの使用  \n* 2要素認証の有効化  \n* アカウントアクティビティの定期的な確認\n\n注：この機能はネイティブGitLabのユーザー名とパスワードでのみ利用可能です。SSO認証情報は対象外です。\n\n[ドキュメント](https://docs.gitlab.com/security/compromised_password_detection/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)[](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)[](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)\n\n![ネイティブGitLab認証情報の漏洩パスワード検出](https://about.gitlab.com/images/18_1/sscs_password_alert.png)\n\n### CI/CDコンポーネントでSLSAレベル1のコンプライアンスに対応\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate  \n\nGitLabの新しいCI/CDコンポーネントを使用することで、[SLSA](https://slsa.dev/)レベル1のコンプライアンスに対応できるようになりました。このコンポーネントは、GitLab Runnerが生成するSLSA準拠の [アーティファクトの来歴メタデータ](https://docs.gitlab.com/ci/runners/configure_runners/#artifact-provenance-metadata)に対して署名と検証を実行します。また、[Sigstore Cosignの機能](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html)を再利用可能なモジュールとして提供し、CI/CDワークフローに簡単に統合できるようにします。\n\n[ドキュメント](https://docs.gitlab.com/ci/pipelines/pipeline_security/#sign-and-verify-slsa-provenance-with-a-cicd-component)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15859)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/15859)\n\n![CI/CDコンポーネントでSLSAレベル1のコンプライアンスに対応](https://about.gitlab.com/images/18_1/SLSA_component.png)\n\n## GitLab 18.1リリースに含まれるその他の改善点\n\n### コード検索で複数の検索結果の統合表示が可能に\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n完全一致コードの検索（ベータ版）では、同じファイル内の複数の検索結果を単一のビューに統合して表示できるようになりました。この改善により、次のことが可能になります。\n\n* 孤立した行表示ではなく、隣接する一致間のコンテキストを保持  \n* 一致する内容が近い場合に重複コンテンツを排除し、視覚的な混乱を軽減  \n* ファイルごとの一致数を明確に表示することで、ナビゲーションを強化  \n* エディタでの表示と同様にコードを表示することで、可読性を改善\n\nこの変更により、リポジトリ全体のコードパターンの発見と理解がより効率的になりました。\n\n[ドキュメント](https://docs.gitlab.com/integration/exact_code_search/zoekt/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13127)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/wx2D39UdUoQ?si=fvjYK-rYVHPgVgzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### 権限チェック機能を強化したCODEOWNERSファイル検証\n\nSaaS: Premium、Ultimate\\\nSelf-Managed: Premium、Ultimate\n\nGitLabでは、基本的な構文チェックを超えた、CODEOWNERSファイルに対するより強化された検証が提供されるようになりました。CODEOWNERSファイルを表示すると、GitLabが自動的に包括的な検証を実行し、マージリクエストのワークフローに影響を与える前に構文エラーと権限の問題を特定します。\n\nこの強化された検証では、CODEOWNERSファイル内の最初の200のユニークなユーザーとグループの参照をチェックし、次のことを検証します。\n\n* 参照されたすべてのユーザーとグループがこのプロジェクトにアクセスできること  \n* ユーザーに、マージリクエストを承認するために必要な権限があること  \n* グループに、デベロッパーレベル以上のアクセス権があること  \n* グループに、マージリクエストの承認権限を持つユーザーが少なくとも1人含まれていること\n\nこの事前検証により、設定上の問題を早期に発見して承認ワークフローの中断を防ぎ、マージリクエストが作成されたときにGitLabコードオーナーが実際にレビューの責任を果たせるようにできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/codeowners/troubleshooting.html#validate-your-codeowners-file)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15598)\n\n### VS Codeでダウンストリームパイプラインのジョブログを表示\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nVS Code用GitLab Workflow拡張機能で、ダウンストリームパイプラインからのジョブログをエディタ内で直接表示できるようになりました。これまで、子パイプラインからログを確認するには、GitLab Webインターフェイスに切り替える必要がありました。\n\nこの機能は、[GitLab共同開発](https://about.gitlab.com/community/co-create/)を通じて開発されました。この場を借りて、コントリビュートしてくれたTim Ryanさんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/editor_extensions/visual_studio_code/cicd/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1895)\n\n\n\n![VS Codeでダウンストリームパイプラインのジョブログを表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659268/orzwm4kjqdag8fe0psvr.png)\n\n### シークレット検出のデフォルトルールとDAST検出の同等性\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nDASTアナライザーが、GitLabのシークレット検出アナライザーで使用されるものと同じデフォルトのシークレット検出ルールを自動的に取り込むようになりました。この改善により、両方のアナライザーで検出されるシークレットの種類に一貫性が確保されます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dast/browser/checks/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/549990)\n\n### 依存関係リストでコンポーネントバージョンによるフィルタリング\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n依存関係リストで、コンポーネントのバージョン番号によるフィルタリングがサポートされるようになりました。複数のバージョン（`バージョン=1.1、1.2、1.4`など）を選択できますが、バージョン範囲指定はサポートされていません。この機能は、グループとプロジェクトの両方で利用できます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_list/#filter-dependency-list)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16431)\n\n![依存関係リストでコンポーネントバージョンによるフィルタリング](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659404/fepyzz2uv3j47bjcehhi.png)\n\n\n\n### コンプライアンスステータスレポートでコントロールステータスの一覧がポップアップで表示されるように\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスステータスレポートのコントロールには、次の3つのステータスがあります。\n\n* 合格  \n* 失敗  \n* 保留中\n\nこれまでは、要求事項に関連付けられているコントロールの数に関係なく、少なくとも1つのコントロールが「保留中」の場合、要求事項行全体が「保留中」として表示されていました。これは、失敗したコントロールの表示方法とは一貫性がありませんでした。失敗したコントロールが1つでもある場合は、要求事項に関連付けられた全コントロール数と失敗の数が表示されます。\n\n「保留中」のコントロールに関する詳細なコンテキストと情報を提供するため、要求事項行のステータスにカーソルを合わせると、各コントロールのステータスを一覧表示するポップアップが表示されるようになりました。これにより、単に「保留中」という全体ステータスを確認するだけでなく、どのコントロールが保留中で、どのコントロールが合格または失敗しているかを具体的に把握できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/521757)\n\n### ボットユーザーと人間のユーザーのフィルタリング\n\n> SaaS: -\\\n> Self-Managed: Free、Premium、Ultimate\n\n運用が進んだGitLabインスタンスでは、多くの場合、人間とボットの両方のユーザーが多数存在します。今回のリリースで、管理者エリアのユーザーリストをユーザータイプでフィルタリングできる機能が追加されました。この機能により、以下のことが可能になります。\n\n* 人間のユーザーと自動化アカウントを区別して迅速に特定、管理  \n* 特定のユーザータイプに絞った管理アクションを実行  \n* ユーザーの監査と管理のワークフローの効率化\n\n[ドキュメント](https://docs.gitlab.com/administration/moderate_users/#view-users-by-type)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/541186)\n\n![ボットユーザーと人間のユーザーのフィルタリング](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659653/prkshqzxg5785p69yshd.png)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/541186)\n\n### ユーザープロフィールのORCID識別子\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nユーザープロフィールにORCID識別子を設定できるようになり、GitLabが研究者や学術コミュニティにとってより使いやすく価値あるものになりました。[ORCID](https://orcid.org/)（Open Researcher and Contributor ID）は、研究者に永続的なデジタル識別子を提供し、他の研究者との区別を可能にするとともに、研究者とその業績を自動的に関連付けることで、適切な評価を支援するものです。\n\nこの機能は、学術コミュニティからの長年の要望に応えるため、アルトワ大学の修士課程の学生であるThomas LabaletteとErwan Hivinが[Daniel Le Berre](https://www.ouvrirlascience.fr/appointment-of-daniel-le-berre-as-the-national-coordinator-for-higher-education-and-research-software-forges-in-france/)の指導の下、コミュニティに貢献することを目的に開発したものです。\n\n[ドキュメント](https://docs.gitlab.com/user/profile/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/23543)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/23543)\n\n![ユーザープロフィールのORCID識別子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663008/oogvxelirqapyxp10pha.png)\n\n\n\n### サービスアカウントのパイプライン通知への登録\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nサービスアカウントによってトリガーされたパイプラインイベントの通知を、受信できるようになりました。通知はパイプラインが合格、失敗、または修正された場合に送信されます。これまでは、サービスアカウントに有効なカスタムメールアドレスが設定されている場合にのみ、そのサービスアカウントのメールアドレスに通知が送信されていました。\n\nこの場を借りて、コントリビュートしてくれた[Densett](https://gitlab.com/Densett)さん、[Gilles Dehaudt](https://gitlab.com/tonton1728)さん、[Lenain](https://gitlab.com/lenaing)さん、[Geoffrey McQuat](https://gitlab.com/gmcquat)さん、[Raphaël Bihoré](https://gitlab.com/rbihore)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/user/profile/notifications/#notification-events-on-issues-merge-requests-and-epics)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/515629)\n\n### 無効となっているパーソナルアクセストークンの表示\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLabは、有効期限が切れたり、失効したりしたアクセストークンを自動的に無効化します。今回の変更では、無効となっているトークンを確認できるようになりました。これまでは、アクセストークンが無効になると表示されなくなっていました。この変更により、こうしたトークンのトレーサビリティとセキュリティが向上します。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/425053)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/weEU6pukbag?si=ebijnyBQdW1_5yBl\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### GitLab Query Language（GLQL）ビューでのエピックサポート（ベータ版）\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Query Language（GLQL）ビューが大幅に改善されました。今後は、クエリでエピックをタイプとして使用できるようになり、グループ全体のエピック検索や親エピックへのクエリが可能になります。\n\nこの機能強化により計画・追跡のワークフローが大きく向上し、エピックレベルでのクエリや整理が格段に効率化されます。\n\n[ドキュメント](https://docs.gitlab.com/user/glql/fields/#epic)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab-query-language/glql-rust/-/issues/30)\n\n### レビューパネルによるマージリクエストのレビューエクスペリエンスの強化\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nマージリクエストのレビューを行う際、レビューを送信する前にこれまでのフィードバックを参照すると役立つことがあります。これまでは、最終コメントと保留中コメントが別々のポップアップに分かれていたため、全体像を把握することが困難でした。\n\nコードレビュー時に、保留中の下書きコメントを一箇所にまとめて表示する専用ドロワーが利用できるようになりました。強化されたレビューパネルでは、レビュー送信インターフェイスがよりアクセスしやすい場所に移動し、保留中のコメント数を示す番号付きバッジが表示されます。パネルを開くと、下にスクロールできるリストに下書きコメントがすべて表示されるため、送信前のフィードバックの確認と管理が簡単になります。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/reviews/#submit-a-review)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/525841)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/525841)\n\n![レビューパネルによるマージリクエストのレビューエクスペリエンスの強化](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663218/yfbrzecnuynpb1g57854.png)\n\n\n\n### GitLab Runner 18.1\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Runner 18.1もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドのエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\nバグ修正：\n\n* [GitLab 17.10または17.11にアップグレードすると、Runnerがジョブをリクエストしたときに404エラーが発生する可能性があります](https://gitlab.com/gitlab-org/gitlab/-/issues/543351)。\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-1-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### 高度なSASTのPHPサポート\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nGitLabの高度なSASTにPHPサポートを追加しました。この新しいファイル間、関数間スキャン機能を使用するには、[高度なSASTを有効](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#enable-advanced-sast-scanning)にします。高度なSASTをすでに有効にしている場合、PHPサポートは自動的に有効になります。\n\n高度なSASTが各言語で検出する脆弱性の種類を確認するには、[高度なSASTカバレッジページ](https://docs.gitlab.com/user/application_security/sast/advanced_sast_coverage/)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#supported-languages)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14273)\n\n### パイプライン実行ポリシーにおける変数の優先順位制御\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n多くの場合、セキュリティチームはセキュリティ保証とデベロッパーエクスペリエンスの間で微妙なバランスを取ることになります。セキュリティスキャンが適切に実行されていることを確認するのは重要ですが、セキュリティアナライザーが正常に動作するためには、開発チームからの特定のインプットが必要な場合があります。変数の優先順位制御により、セキュリティチームは新しい`variables_override`設定オプションを通じて、パイプライン実行ポリシーにおける変数の処理方法を細かく制御できるようになりました。\n\nこの新しい設定を使用すると、次のことが可能になります。\n\n* プロジェクト固有のコンテナイメージパス（`CS_IMAGE`）を許可するコンテナスキャンポリシーを適用  \n* `SAST_EXCLUDED_PATHS`などの低リスク変数は許可し、`SAST_DISABLED`などの高リスク変数はブロック  \n* `AWS_CREDENTIALS`などのグローバルCI/CD変数で保護（マスクまたは非表示）されたグローバル共有認証情報を定義しつつ、必要に応じてプロジェクトレベルのCI/CD変数によるプロジェクト固有の上書きを許可\n\nこの強力な機能は、次の2つのアプローチをサポートしています。\n\n* **デフォルトで変数をロックする**（`allow: false`）：例外として指定した特定の変数を除き、すべての変数をロック  \n* **デフォルトで変数を許可する**`（allow: true`）：変数のカスタマイズを許可するが、重大なリスクのある変数を例外として指定することで制限  \n\n\n\nパイプライン実行ポリシーによってCI/CDジョブが実行される際のトレーサビリティとトラブルシューティングを改善するために、ジョブログ機能も導入されました。これにより、デベロッパーとセキュリティチームは、どのジョブがポリシーによって実行されたかを簡単に特定できますジョブログでは、変数の上書きによる影響の詳細を確認でき、どの変数がポリシーによって上書きまたはロックされているかを把握するのに役立ちます。\n\n**実際の影響**\n\nこの機能強化により、セキュリティ要件とデベロッパーの柔軟性のニーズとの間のギャップが解消されます。\n\n* セキュリティチーム：プロジェクト固有のカスタマイズを許可しつつ、標準化されたスキャンを実行できる  \n* デベロッパーは：ポリシーの例外をリクエストすることなく、プロジェクト固有の変数を制御できる  \n* 組織は：開発ワークフローを混乱させることなく、一貫したセキュリティポリシーを実装できる\n\nこの重要な変数制御機能により、GitLabは組織が開発の柔軟性を保ちながら強固なセキュリティポリシーを導入できる環境を提供します。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/#variables_override-type)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16430)\n\n\n\n![パイプライン実行ポリシーにおける変数の優先順位制御](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663308/h1oukhyd4ky1w6spdxpo.png)\n\n\n\n### 外部カスタムコントロールの`Name`を定義\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまでは、カスタムコンプライアンスフレームワークを作成する際に外部カスタムコントロールの名前を定義できず、GitLabコントロールと並んでリスト表示される外部コントロールを識別することが困難でした。\n\n今回、外部カスタムコントロールを定義する際のワークフローの一部として`Name`フィールドが追加されました。これにより、複数の外部カスタムコントロールを作成し、それぞれに固有の名前を設定して明確に区別できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_frameworks/#external-controls)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/527007)\n\n### GitLab Duo脆弱性の修正のためのSASTカバレッジの向上\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまでは、次のCommon Weakness Enumeration（CWE）識別子を持つ検出された脆弱性を手動で解決する必要がありました。\n\n* CWE-78（コマンドインジェクション）  \n* CWE-89（SQLインジェクション）\n\n現在は、GitLab Duo脆弱性の修正により、これらの脆弱性を自動的に修正できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerabilities/#supported-vulnerabilities-for-vulnerability-resolution)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/534307)\n\n### コンプライアンスフレームワークUIにおける要件のページネーション\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスフレームワークを作成する際は、最大50個の要件を指定できます。\n\nただし、これほど多くの要件があると、UIで大きな表示領域を占めるため、コンプライアンスフレームワークの操作が非常に困難になります。\n\n今回のリリースでは、コンプライアンスフレームワークに多数の要件が含まれている場合でも、ユーザーが要件を簡単に閲覧、検索、選択できるよう、要件のページネーション機能を導入しました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_frameworks/#add-requirements)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/531039)\n\n### コンプライアンスセンターのUIパフォーマンスとフィルタリングを改善\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスセンターのUIパフォーマンスとフィルタリングオプションの改善を継続しています。今回のリリースでは、次のことを行いました。\n\n* 特に多くの要件とプロジェクトが含まれる場合に、**フレームワークの編集**ページのUIスピードとパフォーマンスを改善しました。  \n* コンプライアンスセンターの**コンプライアンスステータスレポート**タブで、要件、プロジェクト、またはフレームワーク別にグループ化できる新しいフィルタリングオプションを導入しました。\n\nこれらの改善を行うことで、コンプライアンスセンターを定期的に利用するお客様に対し、コンプライアンスセンターと関連機能が大規模環境でも継続して高いパフォーマンスを発揮できるようにしています。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/508188)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/478216)\n\n### GraphQL APIの`projectMembers`に新しい`accessLevels`引数を追加\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGraphQL APIの`projectMembers`フィールドに`accessLevels`引数が追加されました。この引数を使用すると、APIコールから直接アクセスレベル別にプロジェクトメンバーをフィルタリングできます。これまでは、プロジェクトメンバーの全リストを取得してからローカルでフィルターを適用する必要があり、これにより計算オーバーヘッドが大幅に増加していました。現在では、プロジェクトの権限分析や所有権グラフの生成がより高速化し、リソース効率も向上しています。この機能強化は、複雑な権限構造を持つ大規模デプロイを管理する組織にとって特に価値があります。\n\n[ドキュメント](https://docs.gitlab.com/api/graphql/reference/#projectprojectmembers)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/541386)\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n\n18.1で提供されたすべてのバグ修正、パフォーマンスの強化、UI改善を確認するには、以下のリンクをクリックしてください。\n\n* [バグ修正](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=type%3A%3Abug&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.1)  \n* [パフォーマンスの改善](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=bug%3A%3Aperformance&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.1)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.1)\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。[](https://docs.gitlab.com/ee/update/deprecations.html#resource-owner-password-credentials-grant-is-deprecated)[](https://docs.gitlab.com/ee/update/deprecations.html#coverage-guided-fuzz-testing-is-deprecated)\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n[](https://docs.gitlab.com/ee/update/deprecations.html#api-discovery-will-use-branch-pipelines-by-default)[](https://docs.gitlab.com/ee/update/deprecations.html#toggle-notes-confidentiality-on-apis)\n\n### 変更履歴\n\n変更内容をすべて表示するには、次のページから変更履歴を確認してください。\n\n* [GitLab](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/CHANGELOG.md)  \n* [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/CHANGELOG.md)  \n* [VS CodeのGitLab Workflow](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md)  \n* [GitLab CLI](https://gitlab.com/gitlab-org/cli/-/releases)\n\n### インストール\n\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/ja-jp/install/)をご覧ください。\n\n### 更新事項\n\n[更新ページ](https://about.gitlab.com/ja-jp/update/)をご覧ください。\n\n### ご不明な点がある場合\n\nご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、[GitLabフォーラム](https://forum.gitlab.com/)にアクセスして質問を投稿してください。\n\n### GitLabサブスクリプションプラン\n\n* [Free](https://about.gitlab.com/pricing/)\\\n  ユーザー向けの永久無料機能を提供  \n* [Premium](https://about.gitlab.com/pricing/premium/)\\\n  チームの生産性と調整を強化  \n* [Ultimate](https://about.gitlab.com/pricing/ultimate/)\\\n  組織全体のセキュリティ、コンプライアンス、プランニングに対応\n\nGitLabのすべての機能を[無料](https://about.gitlab.com/free-trial/?hosted=saas)でお試しいただけます。  \n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\n* [GitLab 18.1](https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release)\n* [GitLab 18.0](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)\n* [GitLab 17.11](https://about.gitlab.com/ja-jp/blog/gitlab-17-11-release/)\n* [GitLab 17.10](https://about.gitlab.com/ja-jp/blog/gitlab-17-10-release/)\n* [GitLab 17.9](https://about.gitlab.com/ja-jp/blog/gitlab-17-9-release/)\n* [GitLab 17.8](https://about.gitlab.com/ja-jp/blog/gitlab-17-8-release/)\n* [GitLab 17.7](https://about.gitlab.com/ja-jp/blog/gitlab-17-7-release/)\n* [GitLab 17.6](https://about.gitlab.com/ja-jp/blog/gitlab-17-6-release/)\n* [GitLab 17.5](https://about.gitlab.com/ja-jp/blog/gitlab-17-5-released/)  \n* [GitLab 17.4](https://about.gitlab.com/ja-jp/blog/gitlab-17-4-released/)  \n* [GitLab 17.3](https://about.gitlab.com/ja-jp/blog/gitlab-17-3-released/)  \n* [GitLab 17.2](https://about.gitlab.com/ja-jp/blog/gitlab-17-2-released/)  \n* [GitLab 17.1](https://about.gitlab.com/ja-jp/blog/gitlab-17-1-released/)  \n* [GitLab 16.11](https://about.gitlab.com/ja-jp/blog/gitlab-16-11-released/)",[738],"2025-06-23","2025-06-20",[763,721,701,110],{"featured":6,"template":681,"slug":1153},"gitlab-18-01-release","content:ja-jp:blog:gitlab-18-01-release.yml","Gitlab 18 01 Release","ja-jp/blog/gitlab-18-01-release.yml","ja-jp/blog/gitlab-18-01-release",{"_path":1159,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1160,"content":1163,"config":1170,"_id":1172,"_type":16,"title":1173,"_source":17,"_file":1174,"_stem":1175,"_extension":20},"/ja-jp/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":1161,"title":1162},"GitLabとIBMの新しいソリューションは、シームレスな統合、CI/CDランナーサポート、エンドツーエンドの可視性、およびコスト効率により、メインフレームとクラウドネイティブ開発を橋渡しします。","GitLab Ultimate for IBM Z：メインフレーム向けモダンDevSecOps",{"title":1162,"description":1161,"body":1164,"category":701,"tags":1165,"authors":1166,"heroImage":1169,"date":1150},"GitLabとIBMは、エンタープライズ開発における根本的な断絶を解決するためにパートナーシップを結びました。それは、メインフレーム開発者が分散環境の開発者と同じモダンなツール、ワークフロー、コラボレーション機能を使用できるようにすることです。GitLab Ultimate for IBM Zは、GitLab認定の統合DevSecOpsソリューションであり、メインフレーム環境に特化して設計されています。このソリューションにより、組織は時代遅れのレガシーライブラリマネージャーからのシームレスな移行を促進し、メインフレーム開発ワークフローをモダナイズできます。IBM z/OS上でネイティブに実行されるCI/CDパイプラインにより、お客様はイノベーションの加速と運用コストの削減を実現できます。\n\n## 現代におけるメインフレーム開発の課題\n\nミッションクリティカルなワークロードにIBM Zシステムを使用するエンタープライズ組織は、従来のDevSecOpsツールでは対応できない課題に直面しています。クラウドネイティブチームは、モダンな[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプライン、協調的な開発、自動化されたテストの恩恵を受けています。一方、メインフレームチームは取り残されることが多く、コストのかかる非効率性と運用サイロにつながる時代遅れのツールに縛られています。\n\nチームはSSH接続や手動ファイル転送などの回避策に頼ることが多く、これらはセキュリティの脆弱性や監査の困難さを生み出します。コンプライアンス要件が厳格な場合、これらの即席のソリューションは受け入れられないリスクとなります。同時に、組織は高価な並行ツールチェーンを維持しており、レガシーメインフレーム開発ツールは、モダンな代替品と比較して限られた機能しか提供しないにもかかわらず、プレミアムライセンスコストがかかっています。\n\nこの断片化は2つの問題を生み出します：配信サイクルの遅延と、モダンな開発体験を期待する開発者の採用の困難さです。\n\n> **「GitLab Ultimate for IBM Zは、長年の業界課題に対処する重要な一歩を表しています。IDCの調査によると、メインフレーム開発者は、配信の非効率性につながり、新しい人材を引き付けることを困難にするレガシーツールで作業することが多いことが示されています。このソリューションにより、モダンなDevSecOps機能と統一されたワークフローがメインフレームに直接もたらされます。これにより、開発者はより協調的かつ効率的に作業できるようになり、組織はイノベーションを加速し、メインフレーム開発をより広範なデジタルトランスフォーメーション戦略に統合することができます。」** \\\n> - Katie Norton、IDC DevSecOpsおよびソフトウェアサプライチェーンセキュリティ リサーチマネージャー\n\n## 統一された開発環境\n\n真のモダナイゼーションとは、単にメインフレーム開発を更新することではありません。それは、メインフレーム、クラウドネイティブ、Web、モバイル開発チームがシームレスに協力できる統一プラットフォームを作成することを意味します。\n\nGitLab Ultimate for IBM Zにより、開発者はz/OS、クラウド、またはオンプレミスインフラストラクチャにデプロイする場合でも、一貫したワークフローを使用できます。知識はサイロ化されるのではなく、チーム間で共有されます。レガシーシステムは動作を継続しながら、チームは独自のペースでモダンなプラクティスを採用できるため、組織はビジネスの中断なく段階的にモダナイズできます。\n\n組織がハイブリッドクラウド戦略を追求する中、GitLabはメインフレームとクラウドネイティブ環境にまたがるアプリケーションの基盤を提供します。\n\n## GitLab Ultimate for IBM Zとは？\n\nGitLab Ultimate for IBM Zは、ネイティブz/OSランナーサポートを提供し、メインフレームインフラストラクチャ上で直接シームレスなCI/CDパイプライン実行を可能にします。このGitLab認定ソリューションは、エンタープライズアプリケーションが要求するセキュリティと信頼性を維持しながら、複雑な回避策の必要性を排除するのに役立ちます。\n\nGitLabの包括的なDevSecOpsプラットフォームとIBMの深いメインフレーム専門知識の組み合わせにより、市場で独自のものが生まれます：エンタープライズレガシーシステムとクラウドネイティブイノベーションの間の真の架け橋を提供する認定ソリューションです。\n\n## GitLab Ultimate for IBM Zの機能\n\nGitLab Ultimate for IBM Zは、重要なビジネスシステムを維持しながらメインフレーム開発をモダナイズするために必要なツールをエンタープライズチームに提供します。\n\n**ネイティブz/OSランナーサポート**は、リモート接続に関連するセキュリティリスクとスケーラビリティのボトルネックを排除し、メインフレームコードが存在する場所で直接実行されるCI/CDパイプラインを通じて配信を加速します。\n\n**統一されたソースコード管理**は、高価なレガシーライブラリマネージャーをGitLabの検索可能でバージョン管理されたリポジトリシステムに置き換えることで、ツールチェーンをモダナイズし、ライセンスコストとメンテナンスのオーバーヘッドを削減するのに役立ちます。\n\n**IBM Developer for z/OS Enterprise Edition (IDzEE)とのシームレスな統合**は、依存関係ベースのビルド、自動コードスキャン、および使い慣れた開発環境内の包括的なデバッグツールを通じて、より高速なソフトウェアリリースを実現し、品質とセキュリティの両方を向上させます。\n\n**メインフレームと分散環境全体のエンドツーエンドの可視性**は、計画から本番までの包括的なプロジェクト管理を提供し、モダンな次世代開発ツールを通じて人材を維持するのに役立つ自動化されたDevOpsワークフローを可能にします。\n\n## 今すぐメインフレーム開発環境をモダナイズ\n\nGitLab Ultimate for IBM Zは、メインフレーム開発体験を変革する準備ができている組織向けに、現在利用可能です。詳細については、[GitLabとIBMのパートナーシップページ](https://about.gitlab.com/partners/technology-partners/ibm/)をご覧ください。",[285,701,110,702],[1167,1168],"Mike Flouton","Andy Bradfield","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png",{"featured":92,"template":681,"slug":1171},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes","content:ja-jp:blog:gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","Gitlab Ultimate For Ibm Z Modern Devsecops For Mainframes","ja-jp/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","ja-jp/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"_path":1177,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1178,"content":1181,"config":1192,"_id":1194,"_type":16,"title":1195,"_source":17,"_file":1196,"_stem":1197,"_extension":20},"/ja-jp/blog/what-is-docker",{"noIndex":6,"description":1179,"title":1180},"Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。","Dockerとは：GitLabとの統合とコンテナについての入門編 | GitLab",{"title":1182,"description":1183,"authors":1184,"date":1185,"body":1186,"category":672,"heroImage":1187,"tags":1188},"Dockerとは：超入門編","Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。\n",[671],"2025-06-18","Dockerコンテナ技術は、2013年にオープンソースの「Dockerエンジン」として公開され、翌年2014年には本番環境向けの商用版が発表されました。その後約10年の間に、Dockerは使いやすさと高い利便性から、IT業界で瞬く間に広く普及してきました。これからもその人気は高まっていくでしょう。\n\nしかしその一方で、いまだに「Dockerとは何ですか」という声もよく耳にします。この記事では、Docker環境の導入を検討中で、Dockerにまだ不慣れなデベロッパーやプログラマーの皆様を対象に、Dockerの基本を解説します。Dockerに触れたことのない初心者向けの「Docker超入門編」です。\n\n## 目次\n\n1. Dockerとは：超入門編\n2. Dockerの目的\n\n   * Dockerとは\n   * Dockerでできること\n   * Dockerイメージとは\n   * Dockerコンテナとは\n   * Dockerfileとは\n   * Dockerはなぜ重要なのか\n3. Dockerの主な機能\n\n   * Dockerの特徴\n   * Docker Composeとは\n4. アプリケーションのデプロイにおけるDockerのメリット\n\n   * 開発環境と本番環境のシームレス化\n   * 起動の軽量化・処理速度の高速化\n   * バージョン管理のしやすさ\n   * 優れたスケーラビリティ\n5. Dockerのデメリット\n\n   * ひとつのOSを使わなければならない\n   * 大規模開発時のオーバーヘッド\n   * 技能習得に時間がかかる\n   * セキュリティに脆弱性が生じることもある\n   * コンテナ間での連携が難しい\n6. GitLabはDockerが抱える課題をどのように解決するのか\n7. GitLabのDevSecOpsにおけるDockerの役割\n8. まとめ\n9. FAQ（よくある質問）\n\n## Dockerの目的\n\nはじめに、Dockerとはどういったもので、何ができて、どうして便利なのか、なぜ重要なのか、Dockerの目的に着目しながらその概念をまとめていきます。\n\n### Dockerとは\n\nDockerは、Linuxのコンテナ技術を用いた軽量なソフトウェアコンテナプラットフォームです。アプリケーションの開発、出荷、実行を簡易化するために設計されました。Dockerを使えば、すべての依存関係と一緒にアプリケーションをパッケージ化できるため、依存関係を一つひとつ手動でインストールする必要がなくなり、一貫性のあるコード実行が可能になります。\n\nDockerを使えばアプリケーションの実行環境を標準化でき、環境の違いによる問題を減らすことで開発から本番環境へのデプロイ時間を大幅に短縮できます。\n\nLinuxには以前からコンテナ仮想化という技術がありました。この技術を使うと、プログラムを開発・実行環境から隔離することにより、複数のプログラムを素早く実行できます。ただし、この従来型の仮想化技術は、仮想環境を構築するためにホストとなるOS（オペレーティングシステム）に依存する必要がありました。Dockerはこのコンテナ仮想化技術をOSに関係なく簡単に扱えるようにしたソフトウェアといえます。\n\nDockerの基本概念はイメージとコンテナです。Dockerイメージは、読み取り専用のテンプレートであり、コンテナを作成するための指示が記述されています。たとえば、コンテナで実行するアプリケーションとその依存関係、環境変数、ファイルシステムなどがこれに含まれます。\n\n### Dockerでできること\n\nDockerを使うと、1台のマシン中に複数のコンテナ（仮想環境）をビルドできるため、いくつかの開発環境に対応することができます。つまり、1台のサーバー上で複数のアプリケーションを効率的に動かすことができるのです。アプリケーションの開発環境をDockerで構築すれば、たとえば開発環境（Windows）で動いていたアプリケーションがLinux上で起動しない、といった問題は発生しません。Dockerで構築した環境は、他のデベロッパーとクラウド上で簡単に共有できるため、開発作業がスムーズに進められます。\n\n### Dockerイメージとは\n\nDockerイメージは、アプリケーションを実行するのに必要なソースコードと必要な依存関係をパッケージ化したものです。Dockerコンテナを実行する際には、このDockerイメージが必要です。\n\nDockerイメージは、コンテナイメージを構成する複数のファイルに、`Dockerfile` を合わせてビルドします。つまり、Dockerイメージは、手作業で書くのではなく、コマンドを使って作成します。\n\nそのため、Dockerイメージは単一のファイルではなく、Dockerコンテナの実行に必要なパッケージ（ファイルやメタデータの集合体）であることを理解することが重要です。\n\n### Dockerコンテナとは\n\nLinuxのコンテナは、アプリケーションを内包し、必要なライブラリや依存関係、ファイルが含まれています。\n\n一方、Dockerコンテナは、Dockerイメージの実行可能なインスタンスです。これはDockerイメージから生成され、アプリケーションを実行するためのランタイム環境です。ただし、ハイパーバイザーを使用する従来の仮想化とは違い、DockerのコンテナはホストOS（オペレーティングシステム）のカーネルで実行されます。Dockerイメージ内には、個別のOSはありません。\n\nDockerイメージは環境のスナップショットであり、コンテナはソフトウェアを実行する環境といえます。\n\n### Dockerfileとは\n\n`Dockerfile`は文字情報を主体とするファイルで、ファイルの拡張子はありません。`Dockerfile`には、アプリケーションの構築から実行までのプロセスに必要なコマンドが記述されています。どのファイルをどこから取得して、どんな処理を行ない、Dockerイメージに含めるのかなどを記述します。\n\n`Dockerfile`は、Dockerイメージを作成するためのテキストファイルです。コンテナイメージをビルドする場合も、コンテナのビルド手順を`Dockerfile`で定義する必要があります。この`Dockerfile`には、命令のスクリプトが含まれており、Dockerはコンテナイメージをビルドする際にこのスクリプトを使用します。\n\n### Dockerはなぜ重要なのか\n\nDockerは、コンテナに関する既存のコンピューティングの概念、とりわけLinuxの「cgroups」や「namespaces」、「overlayfs」などの技術を活用しています。これは、アプリケーションの依存関係をサーバーやネットワークなどのインフラストラクチャから隔離したいという、デベロッパーやシステムオペレーターのニーズに応えるものでした。\n\nDockerを使うと、1台のサーバー上でさまざまなアプリケーションを簡単に仮想化・実行できるようになります。さらには、ローカルマシンに依存しない開発環境を実現でき（開発環境の統一）、本番環境に近い環境でのシミュレーションが可能になり、アプリケーションの依存関係も管理できます。加えて、ビルド、テスト、デプロイまでの各プロセスを一貫して行なうことができます。\n\n## Dockerの主な機能\n\nDockerは、Linuxのコンテナ技術を使用しています。Dockerコンテナはよく仮想マシンと比較されます。\n\n仮想マシンでは、ホストマシン上でハイパーバイザーを利用してゲストOSを動かし、さらにその上でミドルウェアやライブラリ、さらにその上にアプリなどを実行します。\n\nそれに対し、コンテナはホストマシンのカーネルを利用し、プロセスやユーザーなどを隔離します。そのため、非常に軽量で、まるで別のマシンが動いているかのように動作します。その結果、アプリなどを高速に起動、停止することが可能です。\n\nDockerは、次の4つの構成要素から成り立っています。\n\n* **Dockerイメージ：** アプリケーション実行に必要なソースコード、アプリと依存関係のパッケージ\n* **Dockerコンテナ：** アプリケーションを実行するランタイム環境\n* **Docker Hub：** クラウド上のレジストリサービス。アプリケーションやサービスコンテナのビルドと配信を行なう\n* **Dockerfile：** Dockerイメージを作成するために実行するコマンドライン命令を含むテキストファイル\n\n### Dockerの特徴\n\nDockerには、次のような特徴があります。\n\n* **軽量かつ高速：** 1つのOSで複数のコンテナを管理でき、仮想マシンより軽量で高速に立ち上げることが可能。\n* **環境の一貫性が保持でき再現性がアップ：** Dockerコンテナは異なるプラットフォームでも一貫して動作するため、ローカル、クラウド、ハイブリッド環境への移行が簡単にできる。\n  移植性が高い －クラウドシステムとの親和性が高く、主要なクラウドプロバイダーはDockerコンテナの実行をサポートしている。\n* **サンドボックスの提供：** セキュリティ対策やソフトウェア開発において、隔離された仮想環境でプログラムを実行・検証できる。このため、ホストマシンの環境を守ることができる。\n* **IaC（インフラストラクチャのコード化）を使用して、インフラをコード化：** Dockerfileによりミドルウェアのインストールや環境設定をコード化して管理できる。\n\n### Docker Composeとは\n\nDocker Composeは、複数のDockerコンテナを一元管理する、 Dockerアプリケーションのためのツールです。YAMLファイルを使用してアプリケーションのサービスを設定します。単一のコマンドで複数のサービスをまとめて生成したり、起動・停止したりすることができます。\n\nDocker Composeのコマンド例は次のとおりです。\n\n* **`docker-compose up`：** サービス用のコンテナを構築、作成、起動、アタッチします。リンクされているサービスがまだ起動していない場合は、それらも起動します。\n* **`docker-compose ps`：** Docker Composeで管理されている稼働中のサービスを一覧表示します。\n* **`docker-compose build`：** Docker Composeファイルで定義されているサービスをビルド（構築）します。\n\n## アプリケーションのデプロイにおけるDockerのメリット\n\nアプリケーションのデプロイにおけるDockerのメリットは次のとおりです。\n\n### 開発環境と本番環境のシームレス化\n\nコンテナ技術の利用を開発環境と本番環境で統一することで、環境の違いにより起こる問題を減らすことができます。その結果、デベロッパーと運用チームとの連携がスムーズに行われ、チーム間で発生していた問題も最小限に抑えられます。\n\n### 起動の軽量化・処理速度の高速化\n\nDockerのコンテナ技術は従来の仮想環境より軽く、アプリを瞬時に起動できます。これは、CPUやメモリなどのコンピュートリソースを必要最低限しか使用しないためです。起動速度が上がることで、開発にも集中できます。\n\n### バージョン管理のしやすさ\n\nDockerでは、GitLabなどのソースコードのバージョン管理ツールを使用できるため、バージョン管理の可視化が進むだけでなく、ロールバックやアップデートも簡単に行なえるようになります。\n\n### 優れたスケーラビリティ\n\nコンテナは軽量で拡張性に優れています。必要に応じて簡単に増減できます。これにより、アプリケーションの拡張やスケーリングを迅速に行なえるため、変わりゆく状況にも柔軟に対応できます。\n\n## Dockerのデメリット\n\nDockerにはさまざまなメリットがありますが、いくつかデメリットも存在します。以下にデメリットを挙げます。\n\n### 1つのOSを使わなければならない\n\nDockerは1つのOS上で複数のコンテナを作成します。これにより起動速度や処理速度の面でメリットがありますが、同時にデメリットになることもあります。たとえば、異なるOS環境で検証をしたい場合には、別のマシンや仮想マシンを準備する必要が生じます。\n\n### 大規模開発時のオーバーヘッド\n\nDocker自体は軽量ですが、大規模システムに拡張する場合には、Dockerの管理に伴う負荷が発生します。Dockerは1台のサーバーで多数のコンテナを実行できますが、その反面、管理やオーケストレーションが必要になり、その処理のためにオーバーヘッドが生じる場合があります。Dockerだけですべての管理を行なうのが困難になることもあります。\n\n### 技能習得に時間がかかる\n\nDockerは他の仮想マシンと異なる手法で仮想環境を構築します。つまり、デベロッパーは新しいコンセプトをすべてゼロから習得しなければならず、それには時間がかかります。Dockerの動作原理をきちんと理解せずに使用すると、あとでトラブルや問題が発生することもあります。Dockerについてしっかりと学習してから運用に取り組むようにしましょう。\n\n### セキュリティに脆弱性が生じることもある\n\nDockerはコンテナ型アーキテクチャです。1台のマシン上で複数のコンテナが動作するため、このことに起因する脆弱性には注意が必要です。たとえば、複数のコンテナがホストOSのリソースやカーネルを共有しているため、一つのコンテナに脆弱性があった場合、全体にその影響が及ぶ可能性があります。\n\n### コンテナ間での連携が難しい\n\n複数のコンテナ間での連携を検討している場合、各種設定が難しいために、運用時に問題が発生することがあります。たとえば、アプリとデータベースを別のコンテナで作成し、一緒に運用したい場合には、同一ホスト内で通信設定をしなければなりません。ポートやソケットを開放する場合にはセキュリティ面でリスクが生じます。それを避けるために設定を複雑にしてしまうと、今度は運用面で問題が起きる恐れがあります。コンテナを連携させる際は、設計段階から十分に検討することが重要です。\n\n## GitLabはDockerが抱える課題をどのように解決するのか\n\nDockerコンテナ内にGitLabをインストールすることができます。[GitLab](https://about.gitlab.com/ja-jp/platform/)は、Git「分散型バージョン管理システム」を主体としたDevSecOpsプラットフォームです。ソフトウェア開発ライフサイクル全体に対応する単一のプラットフォームで、GItLabを活用することで高品質なソフトウェアの迅速なデリバリーを実現できます。\n\nDockerコンテナ内にGitLabをインストールすると、GitLabインスタンスにアクセスできるようになります。Dockerコンテナへの[GitLab Dockerイメージのインストールは公式にサポート](https://about.gitlab.com/ja-jp/install/)されています。\n\nDockerが抱えるいくつかの問題のうち、特にセキュリティについては、GitLabのDevSecOps（開発、セキュリティ、運用）を活用して対処することができます。GitLabのDevSecOpsでは、[シフトレフト](https://about.gitlab.com/ja-jp/topics/ci-cd/shift-left-devops/)を重視しており、セキュリティ対策を開発サイクルの早い段階に組み込むことにより、コンテナイメージの持つセキュリティの問題の早期発見と対応を図っています。継続的インテグレーションによってこのシフトレフトのコンセプトを実践することで、セキュリティ対応にかかっていたコストを削減できます。\n\nDevSecOpsにおいて重要なCI/CDを実現するためには、自動化が欠かせません。GitLabではパイプラインがCI/CDの命令をまとめています。そして、その指示に従いプロセスの自動化を実現するときの基盤になっているのが[GitLab Runner](https://docs.gitlab.com/runner/)（英語）です。GitLab Runnerはセキュリティのシフトレフトを実現する上で重要な役割を果たしています。\n\nGitLab Runnerはセキュリティスキャンやテストを指定したタイミングで自動で実行してくれます。また、レポート作成ジョブを実行して、ダッシュボードに最新情報を表示することも可能です。\n\n## GitLabのDevSecOpsにおけるDockerの役割\n\nGitLabを活用したDevSecOpsインテグレーションにおいても、Dockerは非常に大切な役割を担っています。\n\n### CI/CDジョブのコンテナ化\n\nGitLab CI/CDでは、CI/CDパイプラインでDockerコンテナを使用することで、次のようなことが可能になります。\n\n* **一貫性：** CI/CDジョブはコンテナ内で実行されるため、依存関係や環境の違いによるエラーが防げます。\n* **スケーラビリティ：** コンテナは軽量かつ迅速に起動でき、大規模なパイプラインでも効率的に実行できます。\n* **環境の柔軟性：** ジョブごとに異なるDockerイメージを指定できるため、必要な環境を簡単に準備できます。\n\nGitLab RunnerのDockerイメージは、UbuntuまたはAlpine Linuxをベースにしています。Dockerイメージは標準の`gitlab-runner`コマンドを内包しており、ホストに直接GitLab Runnerをインストールしたかのように動作します。\n\n### セキュリティスキャンの自動化\n\nセキュリティはDevSecOpsでの重要な要素であり、Dockerはこれをサポートします。\n\n* **コンテナイメージのセキュリティスキャン：** GitLabには、CI/CDパイプラインでDockerイメージをスキャンする機能があります。このスキャンにより脆弱性がチェックされ、イメージ内の依存関係やコードの安全性を評価できます。\n* **コンテナ脆弱性スキャンの自動化：** GitLabにはTrivyやAquaなどのセキュリティツールを統合できます。DockerイメージのOSやアプリケーションが最新であるか、既知の脆弱性がないかをチェックします。\n\n### IaC（インフラストラクチャのコード化）と環境管理\n\n* **再現性：** DockerをGitLabのCI/CDジョブ内で使用することで、開発環境と本番環境の整合性を保つことできます。\n* **ステージングやテスト環境を即時に構築：** Docker ComposeやKubernetesと連携することで、特定のブランチやマージリクエストごとに分離された環境をGitLabで作成できます。これにより、テストやセキュリティスキャンを効率的に実行できます。\n\n### デプロイの効率化\n\nGitLabは、Dockerを使用する以下のデプロイパターンをサポートしています。\n\n* **Dockerイメージのビルドとプッシュ：** アプリをコンテナイメージとしてビルドして、GitLabのContainer Registryや他のDockerレジストリにプッシュします。\n* **継続的デリバリー：** Dockerイメージを使ってコンテナオーケストレーションツールにデプロイすることで、迅速で安全なリリースが可能になります。\n\n### マイクロサービスアーキテクチャのサポート\n\nGitLabとDockerを組み合わせることで、マイクロサービスアーキテクチャを簡単に構築できます。マイクロサービスは別々のDockerコンテナとして実行します。GitLab CI/CDパイプラインを使うと、以下のことを管理できます。\n\n* サービス間の依存関係の設定\n* 個別のセキュリティスキャン\n* バージョン管理（ロールバックが容易になります）\n\n## まとめ\n\n2013年の公表以来、Dockerは瞬く間にIT業界に広く普及しました。本記事では、Dockerの基本概念、基本技術、Dockerを使って何ができるのか、なぜDockerが重要なのか、Dockerを理解上でよく目にする用語などについて紹介してきました。\n\nDockerを使う場合には、DevSecOpsにとって大切なCI/CDを実現するためにも、GitLab CI/CDなどの自動化ツールの導入をおすすめします。GitLab のCI/CDパイプラインでDockerコンテナを使用することで、開発における一貫性の維持、スケーラビリティの実現、柔軟な環境の準備が可能になります。\n\n## FAQ（よくある質問）\n\n### Dockerで何ができるのか？\n\nDockerコンテナは、軽量でスタンドアロンの仮想化技術であり、アプリケーションコード、その依存関係、ライブラリをすべてパッケージ化します。Dockerを使うと、1台のマシン上に複数のコンテナ（仮想環境）を構築でき、開発環境や検証環境の統一が図れます。詳しくは、記事の本文をご覧ください。\n\n### Dockerは何に使うのか？\n\nDockerは、デベロッパーがアプリケーションとその依存関係をシステムから切り離したいとき使用します。コンテナにはアプリケーションとその依存関係がまとめられており、軽量な実行環境を提供します。詳しくは、記事の本文をご覧ください。\n\n### Dockerコンテナとは何ですか？\n\nDockerイメージが実行時にコンテナになります。Dockerコンテナは、アプリケーションを実行するためのランタイム環境です。Dockerコンテナに関する詳細は、記事の本文をご覧ください。\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)*\n\n*（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750226168/pf5cwmvqq09v1pe0re66.jpg",[110,1189,1190,702,678,1191,722,676],"cloud native","DevOps","performance",{"featured":92,"template":681,"slug":1193},"what-is-docker","content:ja-jp:blog:what-is-docker.yml","What Is Docker","ja-jp/blog/what-is-docker.yml","ja-jp/blog/what-is-docker",{"_path":1199,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1200,"content":1203,"config":1210,"_id":1212,"_type":16,"title":1213,"_source":17,"_file":1214,"_stem":1215,"_extension":20},"/ja-jp/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":1201,"description":1202},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",{"title":1201,"description":1202,"authors":1204,"heroImage":1206,"body":1207,"date":1208,"category":962,"tags":1209},[1205],"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",[966,825,270],{"featured":92,"template":681,"slug":1211},"what-s-new-in-git-2-50-0","content:ja-jp:blog:what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0","ja-jp/blog/what-s-new-in-git-2-50-0.yml","ja-jp/blog/what-s-new-in-git-2-50-0",{"_path":1217,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1218,"content":1226,"config":1231,"_id":1233,"_type":16,"title":1234,"_source":17,"_file":1235,"_stem":1236,"_extension":20},"/ja-jp/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"ogTitle":1219,"schema":1220,"ogImage":1221,"ogDescription":1222,"ogSiteName":1223,"noIndex":6,"ogType":1224,"ogUrl":1225,"title":1219,"canonicalUrls":1225,"description":1222},"コードレビューをスピードアップ：AIによるフィードバックの実装","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"コードレビューをスピードアップ：AIによるフィードバックの実装\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-06-10\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659604/Blog/Hero%20Images/Screenshot_2024-11-27_at_4.55.28_PM.png","AI搭載のGitLab Duo with Amazon Qでコードレビューのフィードバック実装を自動化し、面倒な手作業をスムーズにする方法をご紹介します。","https://about.gitlab.com","記事","https://about.gitlab.com/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"heroImage":1221,"body":1227,"authors":1228,"updatedDate":697,"date":1229,"title":1219,"tags":1230,"description":1222,"category":787},"マージリクエストを送信したと思ったら、コードレビューのコメントが次々と届き始める—そんな経験はありませんか？ラベルを更新したい、横並びレイアウトで表示したい、太字書式を適用したい、さらにはボタンの色を変更したい。気がつけば、新機能の開発とは直接関係のない、重要なフィードバックの対応に何時間も費やしていることがあるかもしれません。どんなデベロッパーでも経験したことのある、時間のかかる面倒なプロセスです。\n\nこんなとき、「コードレビューのフィードバックを理解し、変更を自動的に実装してくれるAIアシスタントがあればいいのに」と考えたことはないでしょうか？[GitLab Duo with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)はまさにその機能を備えており、開発ワークフローに革新をもたらします。GitLabのDevSecOpsプラットフォームとAmazon Qの高度なAI機能がシームレスに統合し、レビューコメントを読み取り、それをコード変更に直接反映するインテリジェントなアシスタントが誕生しました。フィードバック対応をAIに任せて面倒な手作業から解放され、プロジェクトの全体像に集中しましょう。\n\n## GitLab Duo with Amazon Qの仕組み\n\nレビュアーのコメントが含まれるマージリクエストを開くと、コード全体にフィードバックが分散して表示されます。この記事の前半で紹介した例では、フォームのラベルを変更してほしいというリクエストや、フィールドを横並びに表示するよう求める提案、特定のテキストを太字にしてほしいというメモなどが寄せられていました。各コメントは、通常手動で処理する必要があるタスクを表しています。\n\n![マージリクエストに対するフィードバック](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673634/Blog/Content%20Images/1-show-comment.png)\n\nGitLab Duo with Amazon Qなら、コメントに「/q dev」というクイックアクションを入力するだけで操作は完了します。これによりAmazon Qはすべてのフィードバックを分析し、自動的にコードの変更を開始します。AIエージェントは各コメントの内容を理解し、リクエストされた変更をコードベースで直接実装します。\n\n![/q dev関数がAmazon Qにフィードバックの分析を促す](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673634/Blog/Content%20Images/2-invoke-q-dev.png)\n\nAmazon Qがフィードバックを処理すると、マージリクエストの「変更」タブにすべての更新内容が表示されます。すべての変更内容が明確に表示されるため、AIエージェントがフィードバックを正確に解釈し、それが実装されたかどうかを把握することが可能です。次に更新されたアプリケーションを実行し、フォームラベルの更新やフィールドの横並び表示、テキストの太字化、ボタンの青色変更など、すべての変更が正しく実装されているかを確認できます。\n\n以下の動画で、コードレビューのフィードバックプロセスを実際にご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/31E9X9BrK5s?si=ThFywR34V3Bfj1Z-\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\u003C!-- blank line -->\n\nコードレビューのフィードバックの処理はソフトウェア開発において必要な作業ですが、時間と手間がかかります。GitLab Duo with Amazon Qは、これまで手作業で行っていたプロセスを自動化されたワークフローへと進化させ、フィードバックの受け取りから変更実装までの時間を大幅に短縮します。こうした日常的な変更をAIに任せれば、デベロッパーは革新的な機能の構築や、複雑な問題の解決など、本当に重要なことに集中できるようになります。\n\nGitLab Duo with Amazon Qの機能：\n- 手動によるフィードバック実装の時間を大幅に削減\n- コードレビューサイクルのスピードを加速\n- フィードバック対応への一貫性を確保\n- コメント確認とコード作成の頭の切り替え負担の軽減\n- デプロイ時間を合理化して、機能をより迅速に提供\n\n> #### GitLab Duo with Amazon Qについて、詳しくは[お近くで開催されるAWS Summit](https://about.gitlab.com/ja-jp/events/aws-summits/)にご参加いただくか、[GitLab担当者にお問い合わせください](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)。\n\n## GitLab Duo with Amazon Qのリソース\n\n- [GitLab Duo with Amazon Q（AWS向けに最適化された自律型AI）の一般提供を開始](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n- [GitLabとAWSのパートナーページ](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)\n- [GitLab Duo with Amazon Qに関するドキュメント](https://docs.gitlab.com/user/duo_amazon_q/)\n- [自律型AIとは？](https://about.gitlab.com/ja-jp/topics/agentic-ai/)\n- [自律型AIに関するガイドとリソース](https://about.gitlab.com/ja-jp/blog/agentic-ai-guides-and-resources/)",[783],"2025-06-10",[920],{"slug":1232,"featured":6,"template":681},"speed-up-code-reviews-let-ai-handle-the-feedback-implementation","content:ja-jp:blog:speed-up-code-reviews-let-ai-handle-the-feedback-implementation.yml","Speed Up Code Reviews Let Ai Handle The Feedback Implementation","ja-jp/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation.yml","ja-jp/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"_path":1238,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1239,"content":1246,"config":1251,"_id":1253,"_type":16,"title":1254,"_source":17,"_file":1255,"_stem":1256,"_extension":20},"/ja-jp/blog/monday-merge-2025-june-9",{"title":1240,"description":1241,"ogTitle":1240,"ogDescription":1241,"noIndex":6,"ogImage":1242,"ogUrl":1243,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1243,"schema":1245},"🌞 6月のMonday Merge：GitLab 18登場！ ただのアップデートじゃない、その理由とは？","6月のMonday Mergeでは、大規模アップデートや新しいAI機能、次のスプリントに役立つDevSecOpsインサイトが満載です。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659951/Blog/Hero%20Images/image4.png","https://about.gitlab.com/blog/monday-merge-2025-june-9","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"🌞 6月のMonday Merge：GitLab 18登場！ ただのアップデートじゃない、その理由とは？\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-06-09\",\n      }",{"title":1240,"description":1241,"authors":1247,"heroImage":1242,"date":1248,"body":1249,"category":700,"tags":1250},[738],"2025-06-09","みなさん、こんにちは！6月のMonday Mergeにようこそ。今回も最新情報をお届けします！\n\n大規模アップデートや新しいAI機能、次のスプリントに役立つDevSecOpsインサイトが満載です。今月の注目ポイント？それは GitLab 18の正式リリースです。しかも今回から、PremiumおよびUltimateのすべてのお客様が、GitLab Duoの主要なAI機能を追加料金なしでご利用可能になりました。\n\nそれでは、さっそく見ていきましょう👇\n\n## GitLab 18：GitLabにとっての小さな一歩、DevSecOpsにとっての大きな飛躍\n![gitlab 18](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/image6.png)\n\nGitLab 18.0のリリースでは、PremiumとUltimateプランにGitLab Duoが標準搭載され、AIネイティブなDevSecOpsの新たな時代が始まります。\n\n### 新機能ハイライト\n\n* Duoコード提案 & GitLab Duo ChatがIDEで利用可能に：コードの記述から理解、リファクタリング、テストまでリアルタイムで支援します。  \n* リポジトリX-Ray（Self-Hostedはベータ版）：リポジトリ構造とコードの健全性を可視化します。  \n* GitLab Duoコードレビューの自動有効化：すべてのマージリクエストにAIレビューを適用。  \n* プロンプトキャッシュ機能：AI応答の遅延を軽減し、スムーズなやり取りを実現。\n\n最新のグローバルDevSecOps調査では、デベロッパーがコード以外の作業に79％もの時間を費やしていることが明らかになりました。つまり、AIを“コード支援”のみに使っているだけでは、AIの真の力を活かしきれていません。GitLab 18では、ソフトウェア開発ライフサイクル全体にAIを組み込み、面倒な作業を減らして本質的なイノベーションに集中できる環境を提供します。\n\nこのリリースを可能にしたのは、世界中の素晴らしいコミュニティの力です。328件のコントリビュートにより支えられたGitLab 18は、まさに「使う人たちによって作られた」リリースです。\n\n今月の注目コントリビューターは、Adfinis社CTOのMichael Hoferさん。GitLabのGeo機能やSecrets Managerの改善など、本当にたくさんの貢献をしてくださいました。オープンソースにかける想いと、周囲を巻き込む力に、私たちもたくさんの学びをもらっています。\n\n👉 [GitLab 18 リリースノート全文を読む](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)\n\n## 事例のご紹介：Ignite by FORVIA HELLA\n![ignite](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/image3.png)\n\nソフトウェアが自動車産業の中核となる今、[Ignite by FORVIA HELLA](https://www.linkedin.com/company/ignite-by-forvia-hella/)は次世代車両開発のために、ベルリンを拠点とするソフトウェア・イノベーションハブ Ignite を立ち上げました。\n\nCTOのFelix Kortmann氏はGitLab Duoについてこう語ります。\n\n「Duoのインテリジェントなコード提案は、デベロッパーにとって日常の必需品です。チャット機能と組み合わせることで、即座のフィードバックと反復が可能になり、開発サイクルが短縮され、コードの安全性も向上しました。私たちのワークフローに、シームレスかつ強力に統合されています」\n\nGitLab CI/CDとAI機能を組み合わせることで、Igniteは反復テストや品質チェックを自動化。コードがpushされた瞬間に自動処理が走り、早期の課題検出とスピーディーなデリバリーを実現しています。\n\n## GitLab 18のローンチイベントがバーチャルで開催！しかもアジア時間に！さらに日本語字幕付き！\n\n2025年6月24日（火）13時より、GitLab 18の新機能を紹介するグローバルオンラインイベントを開催します。\n\n### ✨ イベント内容\n\n* GitLab 18の新機能を実演するライブデモ  \n* GitLabのリーダーたち（Bill Staples、Sabrina Farmer、Josh Lemos、David DeSantoほか）によるインサイト共有  \n* 新ライブシリーズ「The Developer Show」の初公開： コーディングデモ、プロダクト解説、コミュニティのストーリーをお届け！\n\nご都合の良い時間帯を選んでぜひご参加ください。質問も大歓迎です！\n\n👉 [今すぐイベント登録する](https://about.gitlab.com/eighteen/)\n\n## GitLab Duo、Premiumにも標準搭載\n\nGitLab 18のリリースにより、Duoの主要機能がPremiumおよびUltimateで標準提供されます。追加ツールも、追加費用も不要。IDE上でスマートな開発がすぐに始められます。\n\n### 機能ハイライト\n\n* GitLab Duoコード提案：20以上のプログラミング言語で高速なコード作成・リファクタリング  \n* GitLab Duo Chat：コードの解説、テスト生成、トラブル対応を簡単に\n\nさらに、より高度な機能を求めるチームには、Ultimate限定だったDuo EnterpriseがPremiumでも利用可能に。[GitLab Duo根本原因分析](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases)、GitLab Duo Self-Hosted、AIコードレビューなどが利用できます。\n\n👉 [Duoを有効にして、開発を始めましょう](https://about.gitlab.com/ja-jp/blog/gitlab-premium-with-duo/)\n\n## AWS Summit で直接お会いしましょう！\n![aws summit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687124/Blog/Content%20Images/image1.png)\n\n東京をはじめ、世界各地のAWS SummitにGitLabも出展します！GitLabとAWSの連携機能を体験できるほか、安全なクラウドネイティブ開発の事例もご紹介。もちろん、ノベルティもご用意しています！\n\n🗓️ 6月のイベント予定\n\n* シドニー｜6月4日〜5日  \n* ストックホルム｜6月4日  \n* ハンブルク｜6月5日  \n* マドリード｜6月11日  \n* ミラノ｜6月18日  \n* ムンバイ｜6月19日  \n* 東京｜6月25日〜26日\n\n👉 [AWS Summit 2025でお会いできるのを楽しみにしています！](https://about.gitlab.com/ja-jp/events/aws-summits/)\n\n## 今月のおすすめ読書\n![08 Header Images April What We’re Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/08_LinkedIn_Header_Images_April_What_We_re_Reading.png)\n\n* **A Practical Roadmap for Adopting Vibe Coding（Vibe Coding 導入のための実践ロードマップ）**\nスピードを重視するあまり、品質や保守性が犠牲にならないよう、適切なガバナンスが必要だとGitLabの戦略VPであるEmilio Salvadorが解説。\n\n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/a-practical-roadmap-for-vibe-coding-adoption/)\n\n* **3 ways APAC engineering teams can operationalise AI（APACの開発チームがAIを活用する3つの方法）**  \nAPACのエンジニアリングチームによる日常業務へのAI統合、業務効率化、抵抗感の軽減、ビジネス価値の可視化についてGitLabのCTOであるSabrina Farmerが説明します。  \n🔗 [Frontier Enterpriseの記事を読む](https://www.frontier-enterprise.com/3-ways-apac-engineering-teams-can-operationalise-ai/)  \n\n* **Beyond Culture: Addressing Common Security Frustrations（文化を越えて：セキュリティ課題の根本に向き合うには）**  \n文化づくりも重要ですが、開発とセキュリティの基本設計から見直す必要があります。GitLab最高情報セキュリティ責任者のJosh Lemosによる解説記事。  \n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/beyond-culture-addressing-common-security-frustrations/)  \n\n* **The Field CTO View: AI, Vibe Coding, and Developer Skillsets（フィールドCTOの視点：AIとVibe Coding、デベロッパーのスキルセットのこれから）**\n企業のIT部門ではAIがどう実装されているのか？ デベロッパーの適応はどう進んでいるのか？GitLabのフィールドCTO部門責任者が答えています。  \n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/the-field-cto-view-ai-vibe-coding-and-developer-skillsets/)\n\n## 今月のひとこと\n\n最後に、私が心に留めている言葉をシェアします。完璧を目指すよりも、まずは一歩を踏み出すこと。大きなアイデアは、小さな行動から始まります。\n\n「何かを始める方法は、話すのをやめて行動することだ」– ウォルト・ディズニー\n\nこれからも、ひとつずつマージを重ねながら、学び、作り、そして成長していきましょう 💜\n\n🦊 また次回まで！\n\nGitLabコミュニティの一員でいてくださり、ありがとうございます！みなさんがGitLab 18でどんなものを作ってくださるのか、私たちも楽しみにしています。バーチャルイベントの登録と、AI機能の活用開始もお忘れなく。それではまた次回のMonday Mergeでお会いしましょう。Happy Merging!\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | GitLab Developer Advocate\n![SignOffBanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/SignOffBanner.png)",[763,702,721,701,722,700,280,235,920,764,675,270],{"slug":1252,"featured":6,"template":681},"monday-merge-2025-june-9","content:ja-jp:blog:monday-merge-2025-june-9.yml","Monday Merge 2025 June 9","ja-jp/blog/monday-merge-2025-june-9.yml","ja-jp/blog/monday-merge-2025-june-9",{"_path":1258,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1259,"content":1265,"config":1275,"_id":1277,"_type":16,"title":1278,"_source":17,"_file":1279,"_stem":1280,"_extension":20},"/ja-jp/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"title":1260,"description":1261,"ogTitle":1260,"ogDescription":1261,"noIndex":6,"ogImage":1262,"ogUrl":1263,"ogSiteName":1223,"ogType":1224,"canonicalUrls":1263,"schema":1264},"GitLabリポジトリのバックアップを48時間から41分に短縮した方法","15年前のGit関数のパフォーマンス上のボトルネックを追跡して修正し、効率性の向上、より強固なバックアップ戦略の導入、リスクの軽減を実現した方法をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png","https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabリポジトリのバックアップを48時間から41分に短縮した方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Karthik Nayak\"},{\"@type\":\"Person\",\"name\":\"Manuel Kraft\"}],\n        \"datePublished\": \"2025-06-05\",\n      }",{"title":1260,"description":1261,"authors":1266,"heroImage":1262,"date":1269,"body":1270,"category":672,"tags":1271},[1267,1268],"Karthik Nayak","Manuel Kraft","2025-06-05","リポジトリのバックアップは、いかなる堅牢なディザスタリカバリ戦略においても不可欠な要素です。しかし、リポジトリのサイズが大きくなるにつれて、信頼性の高いバックアップの作成プロセスはますます難しくなります。GitLabでは、[Railsリポジトリ](https://gitlab.com/gitlab-org/gitlab)のバックアップに48時間かかっていました。そのため、バックアップ頻度かシステムパフォーマンスのどちらを優先するかを選ばないといけないという難しい状況にありました。お客様のため、そして社内ユーザーのためにこの問題に取り組むことにしました。\n\n最終的に、15年前に作成したGit関数でO(N²)レベルの複雑なアルゴリズムが使われていたのがこの問題の原因であることを突き止め、アルゴリズムを変更して修正したところ、__バックアップ時間が大幅に短縮__されました。その結果、コストの削減、リスクの軽減とともに、コードベースに合わせて実際にスケールするバックアップ戦略を実施できるようになりました。\n\nこれは、大規模なリポジトリのユーザーなら誰にでも起こりうるGitのスケーラビリティの問題であることが判明しました。この問題をどのように追跡して修正したかをご説明します。\n\n## 大規模なバックアップ\n\nまずは、問題について詳しく見ていきましょう。組織においてリポジトリのサイズが大きくなり、バックアップが複雑化するにつれて、以下のような課題が生じる可能性があります。\n\n* **時間がかかるバックアップ**：非常にサイズの大きいリポジトリを使用している場合、バックアップの作成に数時間かかる可能性があるため、定期的なバックアップを行うのが難しくなりがちです。\n* **リソースの集中**：長時間のバックアップ処理には大量のサーバーリソースが必要となることがあるため、他のオペレーションに影響を及ぼす可能性があります。\n* **バックアップの実施期間**：24時間体制で業務を行っているチームにとって、このような長時間の処理を行える適切なメンテナンス期間を確保するのは難しい場合があります。\n* **失敗するリスクの増大**：バックアップ処理に長時間かかると、ネットワークの問題、サーバーの再起動、システムエラーなどによる中断の影響を受けやすくなります。そのため、場合によっては長時間かかるバックアップ処理を最初からやり直さざるを得なくなります。\n* **競合状態**：バックアップの作成に時間がかかるため、その間にリポジトリが大きく変更される可能性があります。結果として、使用できないバックアップが作成されたり、オブジェクトにアクセスできなくなってバックアップ処理が中断されたりすることがあります。\n\nこのような課題によって、バックアップの頻度や完全性を妥協せざるを得なくなる可能性があります。しかしながら、データ保護という観点では妥協すべきではありません。バックアップの実施期間が長くなると、顧客は回避策を取らざるを得なくなることがあります。その場合、外部ツールの導入やバックアップ頻度の削減などが行われますが、結果として、組織全体で一貫したデータ保護戦略を維持できなくなる可能性があります。\n\nでは、GitLabがどのような方法でパフォーマンス上のボトルネックを特定し、解決策を見つけ、バックアップ時間を短縮するためにどのように導入したかを詳しく見ていきましょう。\n\n## 技術的な課題\n\nGitLabのリポジトリバックアップ機能では、[`git bundle create`](https://git-scm.com/docs/git-bundle)コマンドを使用しています。このコマンドは、ブランチやタグのようなすべてのオブジェクトと参照を含むリポジトリの完全なスナップショットをキャプチャします。このバンドルは、リポジトリを正確な状態で再作成するための復元ポイントとして機能します。\n\nしかしながら、このコマンドの実装には参照数に関連するスケーラビリティの低さの問題があり、パフォーマンス上のボトルネックとなっていました。リポジトリ内の参照数が増えるにつれて、処理時間が飛躍的に増加していました。当社の一番大きなリポジトリでは数百万個の参照が含まれますが、バックアップ処理に48時間以上かかることもありました。\n\n### 根本原因分析\n\nそこで、このパフォーマンス上のボトルネックの根本原因を特定するために、実行中のコマンドのフレームグラフを分析しました。\n\n![実行中のコマンドが示されたフレームグラフ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\nフレームグラフは、スタックトレースを使用してコマンドの実行パスを表示します。各バーはコード内の関数に対応しており、バーの幅はその特定の関数内でコマンドの実行に費やされた時間を示します。\n\n10,000個の参照が含まれるリポジトリで実行された`git bundle create`コマンドのフレームグラフを調べたところ、実行時間の約80%が`object_array_remove_duplicates()`関数に費やされていました。この関数は、[コミットb2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686)（バンドル：同じ参照を複数回指定できるように許可、2009年1月17日）でGitに導入されたものです。\n\nこの変更内容を理解するには、`git bundle create`を使用すると、バンドルに含める参照を指定できることを把握する必要があります。完全なリポジトリバンドルの場合、`--all`フラグを指定するとすべての参照がパッケージ化されます。\n\nこのコミットは、ユーザーがコマンドラインから重複した参照を指定（例：`git bundle create main.bundle main main`）すると、重複したmain参照を適切に処理せずにバンドルが作成されてしまうという問題に対処したものでした。Gitリポジトリでこのバンドルをアンバンドルすると、同じ参照を二度書き込もうとするため、壊れてしまいます。そのため、重複回避を目的として、すべての参照で重複の特定処理が繰り返されるようにネストされた`for`ループを用いたコードが実装されました。このようなO(N²)アルゴリズムは、参照数が多いリポジトリではパフォーマンス上の重大なボトルネックとなり、かなりの処理時間がかかっていました。\n\n### 修正方法：O(N²)アルゴリズムを効率的なマッピングに置き換える\n\nGitLabは、明らかになったパフォーマンスの問題を解決するために、ネストされたループをマップデータ構造に置き換えるアップストリーム修正をGitにコントリビュートしました。これにより、各参照がマップに追加され、各参照の単一のコピーのみが処理目的で自動的に保持されるようになりました。\n\nこの変更により、`git bundle create`のパフォーマンスが劇的に向上し、参照数の多いリポジトリのスケーラビリティが大幅に改善されました。10,000個の参照があるリポジトリでベンチマークテストを行った結果、パフォーマンスが6倍向上することが明らかになりました。\n\n```shell\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n\t6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nパッチは承認され、アップストリームのGitに[マージ](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d)されました。GitLabでは、次のGitバージョンがリリースされる前にお客様がすぐに恩恵を受けられるように、この修正をバックポートしました。\n\n## 結果：バックアップ時間の大幅な短縮に成功\n\nこの改善によるパフォーマンスの向上は、まさにこれまでの状況を一変させるものでした。\n\n* **バックアップ時間が48時間から41分に短縮**：GitLab最大のリポジトリ（`gitlab-org/gitlab`）のバックアップを従来のわずか1.4%の時間で作成できるようになりました。\n* **一貫したパフォーマンスの維持**：この修正はリポジトリのサイズに関係なく機能し、安定してスケールします。\n* **効率的なリソースの利用**：バックアップ処理中のサーバー負荷が大幅に軽減されました。\n* **幅広い適用性**：もっとも劇的な改善が見られるのはバックアップの作成ですが、多数の参照を処理するすべてのバンドルベースの操作においてメリットがあります。\n\n## GitLabを利用するお客様にとってのメリット\n\nGitLabを利用する組織は、この改善によって、リポジトリのバックアップとディザスタリカバリ計画方法に関して、即座に次のような具体的なメリットを得られます。\n* **バックアップ戦略の変革**   \n  * 企業チームは、開発ワークフローに影響を与えたり、長期にわたるバックアップ期間を確保したりすることなく、夜間に実施する完全バックアップのスケジュールを確立できます。   \n  * 長期のバックアップ専用の時間を設けなくとも、夜間スケジュール中にバックグラウンドでシームレスに実行できます。  \n* **事業継続性の向上**  \n  * バックアップ時間が数日から数分に短縮されたことで、組織は回復ポイント目標（RPO）を大幅に最小化できます。これはビジネスリスクの軽減につながります。災害が発生した場合でも、数日かからず、数時間の作業で復旧できる可能性があります。  \n* **運用負荷の軽減**   \n  * サーバーリソースの消費を抑えられ、メンテナンス期間が短縮されます。  \n  * バックアップ時間が短縮されるため、コンピューティングコストも削減します。特に処理時間が延びると、コストの増加に直結するクラウド環境においては顕著です。  \n* **将来にわたって活用できるインフラストラクチャ**   \n  * リポジトリの規模が大きくなっても、バックアップ頻度とシステムパフォーマンスのどちらを優先するか選ぶ必要はもうありません。   \n  * コードベースの拡大にあわせて、バックアップ戦略もシームレスに拡張できます。\n\n組織は、パフォーマンスや完全性を犠牲にしなくても、より堅牢なバックアップ戦略を実施できるようになりました。以前は難しいトレードオフに直面していたものの、今では簡単な方法で運用できます。\n\n[GitLab 18.0](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)のリリース以降、ライセンスプランに関係なく、GitLabをご利用のお客様は全員、ご紹介した改善点を利用して[バックアップ](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/)戦略の立案および実施を行えるようになりました。設定を変更する必要はもうありません。\n\n## 今後の展望\n\n今回の革新的な改善は、スケーラブルでエンタープライズグレードなGitインフラの提供に向けた、当社の継続的な取り組みの一環です。バックアップの作成時間が48時間から41分に短縮されたことは重要なマイルストーンとなりましたが、引き続きスタック全体においてパフォーマンス上のボトルネックを特定し、対処しています。\n\n今回の改善をGitのアップストリームプロジェクトにコントリビュートでき、GitLabユーザーだけでなく、広範なGitコミュニティにメリットをもたらせたことを特に誇りに思っています。このような協調的なアプローチにより、改善に対する徹底的なレビューおよび幅広いテストの実施が行われ、誰もがそのメリットを得られるようになります。\n\n> GitLabではパフォーマンスを最適化するために、このような深いレベルでインフラに取り組んでいます。ぜひGitLab 18のオンラインリリースイベントにご参加ください。ほかにどのような根本的な機能強化が行われたかをご紹介します。[今すぐご登録ください！](https://about.gitlab.com/ja-jp/eighteen/)",[1272,1273,91,1274,479],"Git","オープンソース","パフォーマンス",{"slug":1276,"featured":92,"template":681},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes","content:ja-jp:blog:how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.yml","How We Decreased Gitlab Repo Backup Times From 48 Hours To 41 Minutes","ja-jp/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.yml","ja-jp/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"_path":1282,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1283,"content":1289,"config":1294,"_id":1296,"_type":16,"title":1297,"_source":17,"_file":1298,"_stem":1299,"_extension":20},"/ja-jp/blog/what-is-ide",{"title":1284,"description":1285,"ogTitle":1284,"ogDescription":1285,"noIndex":6,"ogImage":1286,"ogUrl":1287,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1287,"schema":1288},"IDE、そしてWeb IDEとは","Web IDE や IDE の知識を身に付け、統合開発環境ツール使用時や、開発自体に生かしましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660036/Blog/Hero%20Images/ide.jpg","https://about.gitlab.com/blog/what-is-ide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"IDE、そしてWeb IDEとは\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2025-06-03\",\n      }",{"title":1284,"description":1285,"authors":1290,"heroImage":1286,"date":1291,"body":1292,"category":722,"tags":1293},[671],"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",[675,678,701,676],{"slug":1295,"featured":92,"template":681},"what-is-ide","content:ja-jp:blog:what-is-ide.yml","What Is Ide","ja-jp/blog/what-is-ide.yml","ja-jp/blog/what-is-ide",{"_path":1301,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1302,"content":1305,"config":1311,"_id":1313,"_type":16,"title":1314,"_source":17,"_file":1315,"_stem":1316,"_extension":20},"/ja-jp/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"noIndex":6,"title":1303,"description":1304},"GitLab DuoとAmazon Qでコードレビューを加速","AI搭載エージェントを使用して、コードレビューを最適化しましょう。自動的にマージリクエストを分析し、バグや可読性、コーディング標準に関する包括的なフィードバックを得られます。",{"heroImage":1306,"body":1307,"authors":1308,"updatedDate":1131,"date":1309,"title":1303,"tags":1310,"description":1304,"category":787},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1750096976/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750096975734.png","コードレビューは、バグの検出、コードの可読性の向上、コーディング標準の順守の徹底に不可欠ですが、その一方でワークフローにおける大きなボトルネックになることもあります。迅速に機能をリリースしようとする際に、複数のチームメンバーによるコードレビューの完了を待つのは歯がゆいものです。多くのやり取りが発生するディスカッション、スケジュールの衝突、チーム全体の合意形成にかかる時間などによって、本来は簡単なレビューが数日から数週間に及ぶことがあります。\n\nそこでおすすめなのが、[GitLab Duo with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)です。AWSユーザー向けにソフトウェア開発ライフサイクル全体にわたって自律型AIを提供するGitLab Duo with Amazon Qを使用すれば、レビュープロセスを変革できます。このAI搭載ソリューションは、チームメンバーがこれまで費やしていたほんの一部の時間で、包括的なコードレビューを実行できます。GitLab Duo with Amazon Qは高度な自律型AI機能を活用することで、必要な品質や徹底性を犠牲にすることなく、レビューワークフロー全体を効率化します。たとえるなら、瞬時にコードを分析して実用的なフィードバックを提供できる非常に熟練したレビュアーがいて、いつでも対応可能な状態のようなものです。\n\n## 仕組み：コードレビューの開始\n\nでは、GitLab Duo with Amazon Qが実際にどのように機能するかをご説明します。ある機能に関する作業が終わり、ちょうど複数のコード更新を含むマージリクエストを作成したところだとします。コードレビューの開始方法は非常に簡単です。チームメンバーに連絡して対応可能かどうかの返答を待つ代わりに、コメントセクションに「/q review」というシンプルなコマンドを入力するだけです。これだけでAIによるコードレビューがトリガーされます。\n\n\n![GitLab Duo with Amazon Qを使用したコードレビューがトリガーされている様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097002/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097002096.png)\n\n\nコマンドが入力されると、Amazon Q Servicesはすぐにコード変更の分析を開始します。レビューを実行中である旨の確認メッセージが表示され、数秒のうちにAIが更新内容のすべての行を調査し、さまざまな側面から潜在的な問題がないかをチェックします。\nレビューが完了すると、バグの検出、可読性の改善、構文エラー、チームのコーディング標準への準拠など、すべての基準を網羅した包括的なフィードバックが表示されます。AIによって問題が特定されるだけでなく、修正のためのコンテキストと修正案も提供されるため、対応が必要な箇所とその理由を簡単に把握できます。\n\nこの自律型AIアプローチの優れた点は、コードレビューの面倒な作業をAIにまかせられるため、デベロッパーが最も重要な作業である「優れたソフトウェアの開発」に集中できることです。時間を無駄に費やすことなく、バグ検出精度の向上、コーディング標準の順守、コード品質の向上など、徹底したコードレビューのメリットを享受できます。さらに、レビューの待ち時間がなくなるため、デプロイまでの時間が大幅に短縮され、チーム全体の生産性が向上します。\n\n## GitLab Duo with Amazon Qの導入メリット\n\nGitLab Duo with Amazon Qを使用することで、以下のように開発プロセスを変革できます。\n- 品質を妥協しない、迅速なコードレビュー\n- コードベース全体にわたってコーディング標準を一貫して適用\n- 本番環境に到達する前に問題を修正できるよう、即座にフィードバックを提供\n- デプロイまでの時間が短縮されるため、より迅速に機能をリリース可能\n- レビューを何度も行わずに済むため、本質的な問題解決に集中できる時間が増加\n\n以下の動画では、GitLab Duo with Amazon Qを使用してコードレビュープロセスに変革をもたらす方法についてご紹介しています。ぜひこの革新的な機能に関する動画をご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> GitLab Duo with Amazon Qの詳細については、 [お近くで開催されるAWS Summit](https://about.gitlab.com/events/aws-summits/) にご参加いただくか [GitLab担当者にお問い合わせ](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)ください.\n>\n> また、自律型AIの今後の計画などについてご紹介するGitLab 18オンラインリリースイベントにもぜひご参加ください。[ご登録はこちら](https://about.gitlab.com/ja-jp/eighteen/)",[783],"2025-06-02",[721,904,742,701,678,285,920,676],{"featured":92,"template":681,"slug":1312},"accelerate-code-reviews-with-gitlab-duo-and-amazon-q","content:ja-jp:blog:accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","Accelerate Code Reviews With Gitlab Duo And Amazon Q","ja-jp/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","ja-jp/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"_path":1318,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1319,"content":1325,"config":1331,"_id":1333,"_type":16,"title":1334,"_source":17,"_file":1335,"_stem":1336,"_extension":20},"/ja-jp/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"title":1320,"description":1321,"ogTitle":1320,"ogDescription":1321,"noIndex":6,"ogImage":1322,"ogUrl":1323,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1323,"schema":1324},"2025年第2四半期の『Forrester Wave™: DevOps Platforms』でGitLabがリーダーの1社に位置付け","Forrester社は、GitLabプラットフォームを「オールインワンソリューションの中でももっともオールインワン」と称し、「一度の購入で標準化を目指す企業に適している」と付け加えています。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2025年第2四半期の『Forrester Wave™: DevOps Platforms』でGitLabがリーダーの1社に位置付け\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2025-06-02\",\n      }",{"title":1320,"description":1321,"authors":1326,"heroImage":1322,"date":1309,"body":1328,"category":701,"tags":1329},[1327],"Dave Steer","DevSecOpsプラットフォームの選択は、企業が下すテクノロジー上の意思決定のうち、もっとも重要なもののひとつです。そのため、GitLabが[**2025年第2四半期の『Forrester Wave™: DevOps Platforms』でリーダーの1社として位置付け**](https://about.gitlab.com/forrester-wave-devops-platform/)されたことを大変光栄に思います。GitLabは、ゼロデイ体験、デベロッパー向けツール、ビルドの自動化と継続的インテグレーション、デプロイの自動化、AIリスクの軽減、AIの導入、組み込み型のセキュリティツール、プラットフォームの一貫性など、お客様がもっとも重視する基準において最上位のスコアを獲得しました。\n\n***「GitLabは、オールインワンソリューションの中でももっともオールインワンであり、一度の購入で標準化を目指す企業に適している」-*** Forrester Wave™: DevOps Platforms（2025年第2四半期）\n\nこの評価には、GitLabに日々寄せられているお客様の声が反映されています。つまり、お客様は安全なソフトウェアをより迅速に提供する必要がありますが、既存のソリューションでは、速度、セキュリティ、またはシンプルさのいずれかを妥協せざるを得ないということです。GitLabはこの3つすべてを妥協せずに実現できます。さらに、5月にリリースした[GitLab 18.0](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)では、テスト生成、コード提案、コードリファクタリングなどの[ネイティブAIのGitLab Duo機能](https://about.gitlab.com/ja-jp/blog/gitlab-premium-with-duo/)をGitLab PremiumとGitLab Ultimateに導入しました。追加費用なしで直接ご利用いただけます。\n\n> [今すぐレポートを読む](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n![『Forrester Wave™: DevOps Platforms』（2025年第2四半期）の画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673518/Blog/Content%20Images/Image_DevOps-Platforms-Q2-2025.png)\n\n## エンタープライズレベルの制御を行い、AI変革の最前線に立ち続ける\n\nDevSecOpsは急速に進化しており、AIはその変化の最前線に立っています。しかしながら、多くのAIツールでは、最先端の機能、またはエンタープライズレベルのセキュリティのどちらかを選ばざるを得ません。\n\nForrester社は、**AIの導入**と**AIリスクの軽減**の両方の基準において、GitLabに5点（最上位の評価）を付けました。セキュリティを維持する革新的なAI機能の開発に注力していることが、お客様だけでなく、多くの方々に認められていることを嬉しく思います。\n\nこの2つの強みは、以下を含むGitLab DuoのAI機能群にも反映されています。\n\n* GitLab Duo Workflow（非公開ベータ版）：開発、セキュリティ、およびオペレーションにわたる複雑なタスクを処理する自律型AIエージェント。エンタープライズレベルのガードレールと監査証跡を提供します。  \n* GitLab Duo Agentic Chat：コードの説明からテスト作成まで、あらゆる場面で文脈を理解する会話型AIアシスト機能を提供します。知的財産の保護とプライバシー管理機能も組み込まれています。  \n* GitLab Duoコード提案：コードブロックの予測補完、関数ロジックの定義、テスト生成、正規表現パターンのような一般的なコードの提案を行うAIアシスト機能です。  \n* ネイティブAIのGitLab Duo脆弱性の修正：自動説明機能やマージリクエストの自動生成を活用して脆弱性を特定し修正することで、開発プロセスを効率化します。\n\n## より少ないリソースでより多くのことを実現\n\nDevSecOpsチームが求めているのは、ソフトウェアデリバリーライフサイクル（SDLC）の一部だけを支援するようなツールやインテグレーションではないという声を、私たちははっきりと受け取っています。SDLC全体をカバーする、シームレスで統合されたデベロッパーエクスペリエンスが必要なのです。\n\n以下の基準でGitLabが獲得したスコアは、当社の顧客重視の戦略を裏付けるものであると考えています。\n\n* **ゼロデイエクスペリエンス**：Forrester社は、GitLabの「強力なゼロデイエクスペリエンス」について、「すべてがすぐに使える状態」であること、そして豊富な移行ツールとチュートリアルが用意されていることを評価しています。 \n* **デベロッパー向けツール**：Forrester社は、AWSユーザー向けの自律型AIである[GitLab Duo with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)、クラウド開発環境、統合デベロッパープラットフォーム、ドキュメント用Wikiなどを例として挙げています。  \n* **プロジェクト計画と連携**：Forrester社は、GitLabの「強力なコンプライアンスセンター」の存在に加え、トップダウンおよびボトムアップでの連携を促進するツールがあることに注目しています。  \n* **パイプラインセキュリティ**：Forrester社は、パイプラインセキュリティの基準においてもGitLabに最上位のスコアを付けました。  \n* **ビルドの自動化と継続的インテグレーション**：Forrester社は、マルチステージのビルドパイプラインと強力なセルフホスティングのサポートを備えたビルドの自動化と継続的インテグレーションについて言及しています。\n\n## レポートを読む\n\n2025年第2四半期の『Forrester Wave™: DevOps Platforms』でリーダーの1社として評価されたことは、SDLC全体にわたり信頼できる唯一の情報源を提供する、当社のプラットフォームの幅広い機能と奥深さを物語っています。複数のツールやインテグレーションを使い分ける必要はもうありません。GitLabなら、シームレスで統合されたエクスペリエンスをとおして、生産性の向上、摩擦の軽減を実現します。今回の評価は、GitLabチームの努力、GitLabのオープンソースコミュニティからの多大な貢献、お客様からの貴重なフィードバック、そしてソフトウェア開発の未来を形作るという当社の熱意を反映していると考えております。\n\n> #### [今すぐレポートを読む](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n*Forrester社がリサーチに関する発行物に掲載されている特定の企業、製品、ブランド、サービスを推奨することはありません。また、当該発行物に記載されている評価に基づいて、特定の企業やブランドの製品またはサービスを選択するよう個人に助言することもありません。情報は、利用可能な最適なリソースに基づいて示されます。意見はその時点での判断によるものであり、変更される可能性があります。詳細については、Forrester社の客観性に関する[こちらのページ](https://www.forrester.com/about-us/objectivity/)をご覧ください。*",[1330,701,700,904],"research",{"slug":1332,"featured":92,"template":681},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","content:ja-jp:blog:gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","Gitlab Named A Leader In The Forrester Wave Devops Platforms Q2 2025","ja-jp/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","ja-jp/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"_path":1338,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1339,"content":1345,"config":1349,"_id":1351,"_type":16,"title":1352,"_source":17,"_file":1353,"_stem":1354,"_extension":20},"/ja-jp/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"title":1340,"description":1341,"ogTitle":1340,"ogDescription":1341,"noIndex":6,"ogImage":1342,"ogUrl":1343,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1343,"schema":1344},"統合されたDevSecOpsプラットフォームへの移行を組織が進めている理由","各種ツールの統合、セキュリティの強化、AIの活用を通じてソフトウェア開発の効率化を実現する、GitLabの包括的な統合DevSecOpsプラットフォームについてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","https://about.gitlab.com/blog/why-are-organizations-moving-to-a-unified-devsecops-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"統合されたDevSecOpsプラットフォームへの移行を組織が進めている理由\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2025-06-02\",\n      }",{"title":1340,"description":1341,"authors":1346,"heroImage":1342,"date":1309,"body":1347,"category":740,"tags":1348},[980],"今日の最新のソフトウェア開発を取り巻く環境では、多くの組織がクラウドに移行し、DevSecOpsプロセスの導入を進めています。しかしながら、このような移行プロセスには、最新の開発方法に合わせて設計されていないツールやレガシーシステムの増加という大きな課題が伴います。そのため、組織はタスク管理、CI/CD、セキュリティ、モニタリングなど、さまざまな用途のツール向けのインテグレーションを作成して、これらのシステムをDevSecOpsに適応させる必要があります。結果として、複雑な運用プロセス、高い保守コスト、開発チームと運用チーム間のコラボレーションへの悪影響といった新たな問題が生じます。さらに、デベロッパーは、計画から本番環境へのデプロイまでの1つの開発フローを完了するために、常に複数のツール間を切り替える必要があり、不満を抱えることになります。\n\n![DevSecOpsプロセスに複数のツールを統合する難しさと、その際に生じる運用コスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>DevSecOpsプロセスに複数のツールを統合するのがどれほど難しいか\u003C/i>\u003C/center> \n\n\u003Cbr>\u003C/br>\n\n幸いなことに、これには解決策があります。ソフトウェア開発に対する統一されたアプローチを提供する包括的なDevSecOpsプラットフォームです。\n\nこのようなプラットフォームは、クラウドベースおよびDevSecOps環境で運用を行う組織向けに構築されており、コード管理、CI/CDプロセス、タスク管理、セキュリティからAI主導の自動化まで、すべてのソフトウェア開発ステージを単一プラットフォームに統合します。すべてのソフトウェア開発ワークフローを統一されたインターフェイスに一元化できるため、開発チームと運用チームの作業やコミュニケーションが効率化され、運用面の複雑さや混乱を最小限に抑えられます。\n\nさらに、デベロッパーエクスペリエンスも大幅に向上します。エンジニアは最新の開発ニーズに特化して設計された製品で作業することになるため、満足度が高まります。\n\n以降のセクションでは、プロジェクトやタスクの管理、セキュリティやコンプライアンスの確保、AI搭載の開発ツールの導入など、チームがよく直面する課題を解決するためにGitLabがどのように役立つかをご紹介します。GitLabなら、単一の統合プラットフォーム内ですべてを行えます。\n\n## 統合されたアジャイルプロジェクト管理\n\nGitLabでは、CI/CDなどソフトウェア開発ライフサイクルの全ステージにわたって、プロジェクトとタスクの管理が完全に統合されている包括的なソリューションが提供されているため、リアルタイムで開発の進捗状況を追跡できます。イシューとエピックは自動化プロセスに直接紐づけられるため、計画から本番環境へのデプロイまでのシームレスなフローが実現されます。このアプローチにより、チーム間の透明性が高まり、遅延の発生が減り、すべてのステークホルダーがリアルタイムで開発状況を明確に把握できるようになります。\n\n![イシューとエピックは自動化プロセスに直接紐づけられるため、計画から本番環境へのデプロイまでのシームレスなフローが実現されます。](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## ビルトインのセキュリティ\nGitLabでは、包括的なセキュリティ機能を統合すること（セキュリティを最優先）を非常に重視しています。GitLabプラットフォームには、以下を含むさまざまな自動セキュリティスキャナーが組み込まれています。\n\n- [依存関係スキャン](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n- [静的アプリケーションセキュリティテスト（SAST）](https://docs.gitlab.com/user/application_security/sast/)\n- [動的アプリケーションセキュリティテスト（DAST）](https://docs.gitlab.com/user/application_security/dast/)\n- [シークレット検出](https://docs.gitlab.com/user/application_security/secret_detection/)\n- [コンテナスキャン](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![さまざまな開発ステージでCI/CDプロセスに統合されているセキュリティスキャン機能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>さまざまな開発ステージでCI/CDプロセスに統合されているセキュリティスキャン機能\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nこれらのセキュリティチェックは、CI/CDパイプラインを含むソフトウェア開発ライフサイクルの全ステージに直接組み込まれており、開発サイクルの早い段階で潜在的なセキュリティ上の問題についてデベロッパーに即座にフィードバックを提供します。\n\n## コンプライアンスと規制要件\n\n効率性や優れたユーザーエクスペリエンスの確保に加え、多くの組織（特に金融機関や大企業など規制の厳しい業界の組織）は、厳格なセキュリティおよびコンプライアンス基準にプロセスが準拠していることを確認する必要があります。こういった組織では、特定のコードブランチ（mainブランチや保護ブランチなど）でCI/CDパイプラインが実行されるたびにセキュリティスキャナーが実行されるようにしたり、mainブランチにコードをマージする前に特定の承認を必須としたりするなど、さまざまなプロジェクトにポリシーを適用する機能が必要です。\n\nGitLabでは、[コンプライアンスフレームワーク](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)という機能があるため、このようなポリシーを簡単に適用できます。構造化されたポリシーを定義し、特定のプロジェクトに対して適用できる機能です。これにより、シームレスで効率的なデベロッパーワークフローを維持しつつ、規制やセキュリティ要件へのコンプライアンスを自動的に実現できます。\n\n## AI搭載の開発支援\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、すべての開発ステージにわたってAI主導のアシスタンスを提供します。そのため、いちいち外部ツールに切り替える必要性がなくなります。すべてのリクエストは、プロジェクトとコードベース全体のコンテキストを把握したAI搭載機能によって処理されるため、より効率的かつスマートに作業を進められます。\n\n例を挙げると、AIは以下のようなタスクを実行できます。\n- タスクの説明の自動生成\n- イシューディスカッションのスマートな要約によるデベロッパーの貴重な時間の節約\n- 高度なコードレビュー機能\n- コードの改善および最適化の提案\n- 自動テスト生成\n- セキュリティの脆弱性の検出と修正\n- 失敗したCIパイプラインの根本原因分析によるトラブルシューティング\n- プライバシーとデータセキュリティ\n\n公共機関や金融機関を始めとする規制の厳しい組織のニーズを理解しているGitLabは、セキュアな環境でAIモデルを実行できるよう独自のソリューションを提供しています。GitLab Duoセルフホストモデルを採用すると、各組織はデータプライバシー、セキュリティ、および大規模言語モデル（[LLM](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/)）の独自インフラへのデプロイを完全に制御しつつ、以下を実現できます。\n- データプライバシーの保護\n- 規制要件へのコンプライアンス\n- 最高レベルのセキュリティ\n- 外部ネットワークの利用やリスクなしでAIのメリットを活用\n\n## まとめ\n\n組織がプロセスの効率化、セキュリティの強化、イノベーションの加速を実現するためには、包括的なDevSecOpsプラットフォームが必要です。ビルトインのセキュリティ機能とAI搭載の自動化を備え、開発、セキュリティ、運用に不可欠なすべてのツールが統合された単一アプリケーションであるGitLabなら、まさにそれらを実現できます。\n\n実際にGitLabがどのように動作するかをご覧になりたい方は、ぜひ以下のインタラクティブなデモをチェックしてみてください。\n\n- [GitLab Duoが搭載されたGitLab PremiumとUltimate](https://gitlab.navattic.com/gitlab-premium-with-duo) – AI搭載の開発支援を体験しましょう\n\n- [CI/CDパイプラインへのセキュリティ実装](https://gitlab.navattic.com/gitlab-scans) – 統合されたセキュリティスキャンによってソフトウェアをどのように保護できるかをご覧ください\n\n- [コンプライアンスフレームワーク](https://gitlab.navattic.com/compliance) – GitLabを使用して全プロジェクトにポリシーを適用してガバナンスを向上させる方法をご紹介します\n\n> GitLab 18オンラインリリースイベントに参加して、自律型AIが担う役割など、DevSecOpsプラットフォームの未来について学びましょう。[今すぐご登録ください！](https://about.gitlab.com/ja-jp/eighteen/)",[702,904,701],{"slug":1350,"featured":6,"template":681},"why-are-organizations-moving-to-a-unified-devsecops-platform","content:ja-jp:blog:why-are-organizations-moving-to-a-unified-devsecops-platform.yml","Why Are Organizations Moving To A Unified Devsecops Platform","ja-jp/blog/why-are-organizations-moving-to-a-unified-devsecops-platform.yml","ja-jp/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"_path":1356,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1357,"content":1363,"config":1369,"_id":1371,"_type":16,"title":1372,"_source":17,"_file":1373,"_stem":1374,"_extension":20},"/ja-jp/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"title":1358,"description":1359,"ogTitle":1358,"ogDescription":1359,"noIndex":6,"ogImage":1360,"ogUrl":1361,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1361,"schema":1362},"GitLab Duo Chatが自律型AIでさらに進化","実験的なリリースとして提供が開始された新しいGitLab Duo Chatは、デベロッパーがプロジェクトに参加したり、担当作業を理解したり、変更を実装したりする際に役立ちます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png","https://about.gitlab.com/blog/gitlab-duo-chat-gets-agentic-ai-makeover","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Chatが自律型AIでさらに進化\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Torsten Linz\"}],\n        \"datePublished\": \"2025-05-29\",\n      }",{"title":1358,"description":1359,"authors":1364,"heroImage":1360,"date":1366,"body":1367,"category":787,"tags":1368,"updatedDate":1269},[1365],"Torsten Linz","2025-05-29","生成AIのチャットアシスタントは、ソフトウェア開発の現場で一般的に使われるようになり、コードの作成や修正をサポートします。もしそのチャットアシスタントが、コードだけでなく開発プロセス全体のアーティファクトを理解できたとしたらどうでしょうか？コードを書く前にイシューやプロジェクトドキュメントの確認を手伝い、CI/CDパイプラインやマージリクエストにアクセスして、コーディング作業を適切に完了できるように支援してくれるとしたらどうでしょうか？\n\n\n**こうした高度な開発支援を実現するのが、次世代のGitLab Duo Chat「GitLab Duo Agentic\nChat」です。これは、AIネイティブな開発支援の大きな進化形であり、現在は[実験的なリリース](https://docs.gitlab.com/policy/development_stages_support/#experiment)としてGitLabプラットフォームに新たに追加された機能です。**\nGitLab Duo Agentic Chatは、VS CodeでGitLab\nWorkflow拡張機能をお使いのGitLab.comユーザーであれば利用できます。\n\n\nAgentic\nChatは、従来の対話型AIによるチャット体験を、ユーザーに代わってアクションを実行するチャット体験に変革します。複雑な問題を細かいタスクに分割し、自律的に完了することができます。Agentic\nChatは、提供されたコンテキストに基づいて質問に答えるだけでなく、以下のようなことができます。\n\n\n* 質問に答えるために必要な情報を**自律的に判断する**\n\n* 複数の情報源から必要な情報を取得するための**一連の操作を実行する** \n\n* プロジェクト全体から得られる分析結果を組み合わせて、**包括的な回答を作成する**\n\n* ソリューションを実装するために**ファイルを作成、編集する**\n\n\nこれらすべての作業が、人間のデベロッパーが常に状況を把握できる状態で行われます。\n\n\nAgentic\nChatは、[現在プライベートベータ版](https://about.gitlab.com/ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)のDuo\nWorkflowアーキテクチャ上に構築されています。このアーキテクチャは、与えられた質問に適したコンテキストを見つけたり、ファイルを編集したりするなど、特定のタスクを担うエージェントとツールで構成されています。\n\n\n**GitLab Duo Agentic Chatのユースケース**\n\n\nここでは、Agentic Chatの実際の活用例と一般的なユースケースをご紹介します。\n\n\n* __新しいプロジェクトにすばやくオンボーディング__：新しいコードベースに慣れる作業をAIが支援することで、より迅速にプロジェクトに参加できます。\n\n\n* __担当業務にすぐに着手__：イシューの説明が不明確でも、Agentic\nChatが要件と既存の実装との関連性を示してくれるため、すぐに担当作業に取りかかることができます。\n\n\n* __変更の実装支援__：変更作業が必要になった際には、Agentic\nChatがプロジェクト全体にわたって複数のファイルを作成、編集し、実装を支援します。\n\n\n* __リリース時の検証__：リリースの段階では、Agentic\nChatがマージリクエストと元のイシューやタスクを照らし合わせて、ソリューションが本当に要件を満たしているかを検証する手助けをします。\n\n\n![agentic chat -\n例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099210/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099210429.png)\n\n\n\u003Ccenter>\u003Ci>コードの編集を行う Agentic Chat\u003C/i>\u003C/center>\n\n\n## 学習からリリースまで：4ステップの開発ワークフロー\n\n\nGitLabエンジニアリングチームの実際のシナリオを通じて、Agentic\nChatが開発体験をどのように変革するかをご紹介します。あなたはチームの新メンバーとして、イシューを割り当てられましたが、コードベースについてはまだ何も知らないとします。\nそれでは、以下のデモ動画に従って体験してみましょう。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/uG9-QLAJrrg?si=kaOhYylMIaWkIuG8j\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n**ステップ1：プロジェクトを理解する**\n\n\nファイルやドキュメントを自分で探し回る代わりに、Agentic Chatに以下のように質問してみましょう。\n\n\n```unset\n\nこのプロジェクトは初めてです。構造を読んで説明してもらえますか？\n\n```\n\n\nAgentic Chatは、以下の方法でプロジェクトの全体像をわかりやすく示してくれます。\n\n- ディレクトリ構造の探索\n\n- READMEファイルやドキュメントの読み取り\n\n- 主要なコンポーネントやアプリケーションの特定\n\n\n**ステップ2：担当タスクを理解する**\n\n\n次に、あなたが担当するタスクの内容を把握する必要があります。以下のように質問してみましょう。\n\n\n```unset\n\nイシュー1119を担当することになりました。このタスクの内容を説明してもらえますか？特に、リファクタリングが必要な箇所はどこですか？\n\n```\n\n\nAgentic Chatは、以下の方法でタスクの説明とリファクタリングの提案を行ってくれます。\n\n- リモートのGitLabサーバーからイシューの詳細を取得し、分析\n\n- 関連するプロジェクトファイルの調査\n\n- 変更が必要な箇所の特定\n\n\n**ステップ3：ソリューションを実装する**\n\n\n手動で作業する代わりに、以下のようにリクエストできます。\n\n\n```unset\n\nその編集を行ってもらえますか？ステップ1、2、3から始めてください。\n\n```\n\n\nAgentic Chatは以下のアクションを実行します。\n\n- 必要に応じて新しいディレクトリやファイルを作成\n\n- 複数の場所にまたがってコードを抽出、リファクタリング\n\n- 変更されたすべてのファイル間で一貫性を維持\n\n- 行ったすべての変更の要約を報告\n\n\n**ステップ4：作業の完了を確認する**\n\n\nマージリクエストを作成したら、最後に作業の完了を確認します。\n\n\n```unset\n\nこのマージリクエストはイシュー1119を完全に解決していますか？\n\n```\n\n\nAgentic Chatは、マージリクエストと元のイシューの内容を分析し、すべての要件が満たされているかどうかを検証してくれます。\n\n\n## フィードバックをお待ちしています\n\n\nGitLab Duo Agentic Chatは現在、VS Codeの実験的機能として、GitLab Duo\nProおよびEnterpriseユーザーの皆様にご利用いただけます。前提要件や設定手順については、[セットアップドキュメント](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/)をご確認ください。\n\n\n実験的な機能であるAgentic\nChatにはいくつかの既知の制限があります。これには、複数のAPIコールによる応答時間の遅延、文脈理解による検索ではなくキーワードベースの検索の実行、新しいローカルフォルダやGitLab以外のプロジェクトに対するサポートの制限などが含まれます。現在GitLabは、これらの事項の改善に積極的に取り組んでいます。\n**皆さまからのフィードバックは、改善の優先順位を決め、Agentic\nChatを一般公開へと導く上で非常に重要です。ぜひ、[こちらのイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/542198)で皆さまの体験を共有してください。**\n\n\n## 今後の取り組み\n\n\nGitLabは、Agentic Chatの改善と一般公開へ向けた開発を全力で進めています。主な取り組みとして、応答速度の改善のほか、現在のGitLab\nDuo Chatで利用可能な各種機能をAgentic Chatでも使えるようにする作業があります。これには、セルフホストモデルのGitLab\nDuoとの統合や、VS Codeに加えてJetBrainsやVisual Studioをサポートする機能拡張が含まれます。Duo\nChatをこの新しいアーキテクチャに切り替えた後は、GitLab Webアプリケーション内のチャットにもAgentic Chatを導入する予定です。\nまた、GitLabアーティファクトの編集、カスタムモデルコンテキストプロトコル（MCP）サーバーからのコンテキストの取得、ターミナルで実行できるコマンドの提供など、多くの新機能の追加も予定しています。\n\n\n> まだGitLabをご利用でなくても、自律型の開発支援を今すぐ体験していただけます。[GitLab UltimateとGitLab Duo\nEnterpriseの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)で、Agentic\nChatを今すぐお試しください。AIを活用した開発の未来を一緒に形作りましょう。VS\nCodeでのセットアップ手順は、[こちら](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-vs-code)からご確認いただけます。\n\n\n***免責事項：このブログには、今後の製品、機能、および機能性に関する情報が含まれています。本ブログ記事に含まれる情報は、情報提供のみを目的としている点にご留意ください。購入や計画の判断材料として使用することはお控えください。すべてのプロジェクトと同様に、このブログおよびリンク先のページに記載されている項目は、変更または遅延される場合があります。製品、機能、機能性の開発、リリース、およびタイミングに関する決定権は、GitLabに帰属します。***\n\n\n## 関連リンク\n\n\n- [GitLab Duo\nWorkflow：自律型AIに対するエンタープライズレベルの可視性と管理](https://about.gitlab.com/ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n\n- [自律型AIとは？](https://about.gitlab.com/ja-jp/topics/agentic-ai/)\n\n-\n[自律型AIに関するガイドとリソース](https://about.gitlab.com/blog/agentic-ai-guides-and-resources/)（英語）\n",[721,700,678,904,701,676],{"slug":1370,"featured":92,"template":681},"gitlab-duo-chat-gets-agentic-ai-makeover","content:ja-jp:blog:gitlab-duo-chat-gets-agentic-ai-makeover.yml","Gitlab Duo Chat Gets Agentic Ai Makeover","ja-jp/blog/gitlab-duo-chat-gets-agentic-ai-makeover.yml","ja-jp/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"_path":1376,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1377,"content":1383,"config":1391,"_id":1393,"_type":16,"title":1394,"_source":17,"_file":1395,"_stem":1396,"_extension":20},"/ja-jp/blog/gitlab-free-tier-integration-guide",{"title":1378,"description":1379,"ogTitle":1378,"ogDescription":1379,"noIndex":6,"ogImage":1380,"ogUrl":1381,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1381,"schema":1382},"フリー版のGitLabでできる Integration Guide 〜どんどんつなげよう、GitLabの輪〜","この記事ではGitLabのフリー版をご利用の方が無料で実現できる、他社製品とのインテグレーション方法について、詳しくご説明します。\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659791/Blog/Hero%20Images/%E3%83%95%E3%83%AA%E3%83%BC%E7%89%88%E3%81%AEGitLab%E3%81%A7%E3%81%A7%E3%81%8D%E3%82%8B6.png","https://about.gitlab.com/blog/gitlab-free-tier-integration-guide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"フリー版のGitLabでできる Integration Guide 〜どんどんつなげよう、GitLabの輪〜\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"}],\n        \"datePublished\": \"2025-05-28\",\n      }",{"title":1378,"description":1379,"authors":1384,"heroImage":1380,"date":1386,"body":1387,"category":962,"tags":1388},[1385],"Tsukasa Komatsubara","2025-05-28","## 目次\n\n__1.はじめに__\u003Cbr>\n__2.はしがき__\u003Cbr>\n__3.Redmine__\u003Cbr>\n  本書で扱うRedmine\u003Cbr>\n  Redmineのインストール\u003Cbr>\n      セットアップ\u003Cbr>\n      初期設定\u003Cbr>\n  GitLabのマニュアルの確認\u003Cbr>\n  GitLab側の設定\u003Cbr>\n  実際に使用している様子\u003Cbr>\n  GitLabのコミット時に「#2」を指定している様子\u003Cbr>\n  本インテグレーションのポイント\u003Cbr>\n  ご注意\u003Cbr>\n\n__4.Backlog__\u003Cbr>\n  本書で扱うBacklog\u003Cbr>\n      Backlogの利用開始\u003Cbr>\t\n      ユーザ登録\t\u003Cbr>\n  初期設定\u003Cbr>\n  GitLabのマニュアルの確認\u003Cbr>\n  GitLab側の設定\u003Cbr>\n      GitLabのイシュー機能を非表示\t\u003Cbr>\n  実際に使用している様子\t\u003Cbr>\n  GitLabのコミット時に「キー情報」を指定している様子\t\u003Cbr>\n  本インテグレーションのポイント\u003Cbr>\t\n  ご注意\t\u003Cbr>\n\n__5.Jira__\u003Cbr>\n  本書で扱うJiraと2つのユースケース\t\u003Cbr>\n  Jiraの利用開始\u003Cbr>\t\n      ユーザ登録\t\u003Cbr>\n      初期設定\t\u003Cbr>\n  GitLabのマニュアルの確認\t\u003Cbr>\n  ユースケース1. Jira Issue Integration\t\u003Cbr>\n  GitLab側の設定\t\u003Cbr>\n  GitLabのイシュー機能を非表示\t\u003Cbr>\n  実際に使用している様子\t\u003Cbr>\n  GitLabのコミット時に「URL情報」を指定している様子\t\u003Cbr>\n  本インテグレーションJira Issueのポイント\t\u003Cbr>\n  ご注意\t\u003Cbr>\n  ユースケース2. Jira development panel Integration\t\u003Cbr>\n  Jira側の設定\t\u003Cbr>\n  実際に使用している様子\t\u003Cbr>\n\n## 1.はじめに\n\n本書は、GitLabのフリー版をお使いの皆様に、無料で実現できる他社製品とのインテグレーション方法について詳しく説明したものです。  \n\nぜひ実際に手を動かして、セットアップしてみてください。  \nいずれもプロジェクト単位なので、他のGitLab上のプロジェクトに影響を与えることはありません。\n\n## 2.はしがき\n\n- 本書に登場する会社名および商品名は各社の商標または登録商標です。  \n- なお、本書ではⓇ、TM マークを明記しておりません。\n- 本書で前提としている各製品等のバージョンは以下となります。\n\n  GitLab.com および GitLab Community Edition/Enterprise Edition Free版 17.10\n\n## 3.Redmine\n\n### 本書で扱うRedmine\n\nRedmineとは、[https://www.redmine.org/](https://www.redmine.org/) で提供されている、無料のプロジェクト管理ツールです。非常に人気が高いOSSプロダクトです。\n\n![フリー版のGitLabでできる6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%E3%83%95%E3%83%AA%E3%83%BC%E7%89%88%E3%81%AEGitLab%E3%81%A7%E3%81%A7%E3%81%8D%E3%82%8B6.png)\n\n*引用元: https://www.redmine.org/*\n\n2025/04/01時点で、最新のものは、 [6.0.4](https://www.redmine.org/projects/redmine/wiki/Download)となっています。\n\n![フリー版のGitLabでできる26](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__26.png)\n*引用元: https://www.redmine.org/*\n\n### Redmineのインストール\n\n#### セットアップ\n\n本書では、Dockerをつかってインストールします。\n\n以下のファイルを作成： docker-compose.yml\n\n```\nversion: '3.1'\n\nservices:\n\n  redmine:\n    image: redmine\n    restart: always\n    ports:\n      - 80:3000\n    environment:\n      REDMINE_DB_MYSQL: db\n      REDMINE_DB_PASSWORD: example\n      REDMINE_SECRET_KEY_BASE: supersecretkey\n\n  db:\n    image: mysql:8.0\n    restart: always\n    environment:\n      MYSQL_ROOT_PASSWORD: example\n      MYSQL_DATABASE: redmine\n\n```\n\nその後、以下のコマンドでインスタンスを起動します。\n\n```\nsudo docker compose up \\-d\n```\n\n#### 初期設定\n\nRedmine側でプロジェクトや、イシューを作成できるよう、トラッカー等の設定をおこないます。一通りセットアップを完了します。\n\n![フリー版のGitLabでできる37](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__37.png)\n*引用元: https://www.redmine.org/*\n\n仮に以下の内容で準備が完了したとします。\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| URL | [http://my-redmine.samurai-tanuki.com/](http://my-redmine.samurai-tanuki.com/) |\n| 作成したプロジェクト | sample-project-1 |\n\n### GitLabのマニュアルの確認\n\n以下のURLで、GitLabとRedmineの設定方法についてのガイドが記載されています。\n\n[Redmine | GitLab Docs](https://docs.gitlab.com/user/project/integrations/redmine/) \n\n### GitLab側の設定\n\n![フリー版のGitLabでできる20](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__20.png)\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| プロジェクトのURL | http://my-redmine.samurai-tanuki.com/projects/sample-project-1 |\n| イシューのURL | http://my-redmine.samurai-tanuki.com/issues/:id |\n| 新しいイシューのURL | http://my-redmine.samurai-tanuki.com/projects/sample-project-1/issues/new |\n\n（*上記では、「新しいイシューのURL」を指定していますが、本機能はもう動作しません。UI上は入力チェック機能が動作するため、なにか適当な文字列を指定すればよいです。プロジェクトのURL、イシューのURLを指定し、「テスト設定」を押下して動作を確認します）\n\n上記の「プロジェクトのURL」は、GitLabのメニューの以下の部分に表示されます。\n\n![フリー版のGitLabでできる15](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__15.png)\n\n### 実際に使用している様子\n\nRedmine側で、以下のようにイシューを作成します。\n\n![フリー版のGitLabでできる11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__11.png)\n\n*引用元: https://www.redmine.org/*\n\n![フリー版のGitLabでできる12](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__12.png)\n*引用元: https://www.redmine.org/*\n\n### GitLabのコミット時に「#2」を指定している様子\n\n![フリー版のGitLabでできる16](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__16.png)\n\nコミットした後、以下のようにリンクが作成されます。\n\n![フリー版のGitLabでできる34](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__34.png)\n\n上記で「Issue in Redmine」をクリックすると、以下の画面に遷移します。\n\n![フリー版のGitLabでできる12](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__12.png)\n*引用元: https://www.redmine.org/*\n\n### 本インテグレーションのポイント\n\nGitLabとRedmineのインテグレーションを実現すると、以下のような内容が実現できます。\n\n1. Redmine側でイシューを作成  \n2. GitLab側でソースコード等へ修正を加え、コミット時に、Redmine側でのチケット番号を指定すると、URLとして保存される  \n3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのRedmineのチケットURLへ飛ぶことができる\n\nポイントとして、\n\n* GitLab側から、Redmine側へ直接「書き込み」は行わない  \n* あくまでもリンクをつなげることで、GitLab ⇔ Redmine間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ\n\nの2点が価値ポイントとなります。\n\n### ご注意\n\n本機能を有効にすると、GitLab側の「イシュー」機能が利用できなくなります。\n\n## 4.Backlog\n\n### 本書で扱うBacklog\n\nBacklogとは、株式会社ヌーラボ社から提供されている、製品です。ここでは、GitLabとのインテグレーション方法について解説します。\n\n![フリー版のGitLabでできる31](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__31.png)\n*引用元: https://backlog.com/ja/*\n\n### Backlogの利用開始\n\n#### ユーザ登録 \n\nBacklogの契約がまだで、テスト的に利用したい場合は、Free版が提供されているようなので、それを利用するのものオススメです。\n\n### 初期設定\n\nBacklog側でプロジェクトの作成をおこないます。Backlogの場合、プロジェクトを作成すれば、すぐに使えるようになっています。\n\n![フリー版のGitLabでできる44](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__44.png)\n\n*引用元: https://backlog.com/ja/*\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| URL | https://tsukasano.backlog.com/ |\n| 作成したプロジェクト | sample-project-1 |\n\n### GitLabのマニュアルの確認\n\n以下のURLで、GitLabとBacklogについては、汎用的な接続インターフェースで設定します。  \nこの設定をした場合、GitLabの既存の「イシュー」機能も「存続」します。そのため、特に併用の必要がない場合は、GitLab側の「イシュー」を非表示することをおすすめします。\n\n[Custom issue tracker | GitLab Docs](https://docs.gitlab.com/user/project/integrations/custom_issue_tracker/)\n\n### GitLab側の設定\n\n![フリー版のGitLabでできる35](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__35.png)\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| プロジェクトのURL | https://tsukasano.backlog.com/projects/PAFE1 |\n| イシューのURL | https://tsukasano.backlog.com/view/PAFE1-:id |\n| 新しいイシューのURL | https://tsukasano.backlog.com/add/PAFE1 |\n\nBacklogの場合、イシューのURLの部分に少し注意が必要です。上記では、プロジェクトIDは「PAGE1」ですが、イシューを参照したときのURLは、(イシュー番号が6の場合)「https://tsukasano.backlog.com/view/PAFE1-6」となります。そのため、分かりづらいですが、上記の「イシューのURL」のように、「:id」を含める部分については注意が必要です。不明であれば、一旦、Backlog側でイシューを開き、そのURLの構成を確認するとよいでしょう。\n\n（* 上記では、「新しいイシューのURL」を指定していますが、本機能はもう動作しません。UI上は入力チェック機能が動作するため、なにか適当な文字列を指定すればよいです。プロジェクトのURL、イシューのURLを指定し、「テスト設定」を押下して動作を確認します）\n\n上記の「プロジェクトのURL」は、GitLabのメニューの以下の部分に表示されます。\n\n![フリー版のGitLabでできる50](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__50.png)\n\n#### GitLabのイシュー機能を非表示\n\nBacklogをメインとして使う場合、GitLabの「設定」ー「一般」ー「可視性、プロジェクトの機能、権限」より、「イシュー」をOffにします。\n\n![フリー版のGitLabでできる17](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__17.png)\n\nその後、[変更を保存]ボタンを押して、設定を反映します。  \n![フリー版のGitLabでできる8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__8.png)\nそうすると、以下のようにメニューの表示が変わります。\n\n![フリー版のGitLabでできる50](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__50.png)\n\n### 実際に使用している様子\n\nBacklog側で、以下のようにイシューを作成します。\n![フリー版のGitLabでできる23](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__23.png)\n*引用元: https://backlog.com/ja/*\n\nこの時、上の図の矢印アイコンをクリックすると、課題名とキーが含まれた「キー情報」がクリップボードにコピーされます。\n\n### GitLabのコミット時に「キー情報」を指定している様子\n![フリー版47](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/image47.png)\n\nコミットした後、以下のようにリンクが作成されます。\n\n![フリー版のGitLabでできる10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__10.png)\n\n上記で「Issue in Custom issue tracker」をクリックすると、以下の画面に遷移します。\n\n![フリー版のGitLabでできる45](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__45.png)\n*引用元: https://backlog.com/ja/*\n\n### 本インテグレーションのポイント\n\nGitLabとBacklogのインテグレーションを実現すると、以下のような内容が実現できます。\n\n1. Backlog側でイシューを作成  \n2. GitLab側でソースコード等へ修正を加え、コミット時に、Backlog側でのチケット番号を指定すると、URLとして保存される(Backlog側のUIから、チケット情報をコピーするとよいでしょう)  \n3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのBacklogのチケットURLへ飛ぶことができる\n\nポイントとして、\n\n* GitLab側から、Backlog側へ直接「書き込み」は行わない  \n* あくまでもリンクをつなげることで、GitLab ⇔ Backlog間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ\n\nの2点が価値ポイントとなります。\n\n### ご注意\n\n本機能を有効にすると、GitLab側の「イシュー」機能は残りますので、特別な理由がない限り、GitLab側の「イシュー」機能は停止するとよいでしょう。\n\n## 5.Jira\n\n### 本書で扱うJiraと2つのユースケース\n\nJiraとは、アトラシアン社から提供されている、製品です。ここでは、GitLabとのインテグレーション方法について解説します。\n\nここで扱うユースケースは、2つあります。このJiraの場合だけ、少し特殊なのが面白いところです。  \n「Jira Issue」と「Jira development panel」Integrationです。\n\n![フリー版のGitLabでできる3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__3.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n### Jiraの利用開始\n\n#### ユーザ登録\n\nJiraの契約がまだで、テスト的に利用したい場合は、Free版が提供されているようなので、それを利用するのものオススメです。\n\n#### 初期設定\n\nJira側でプロジェクトの作成をおこないます。Jiraの場合、プロジェクトを作成すれば、すぐに使えるようになっています。\n![フリー版のGitLabでできる5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__5.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| URL | https://gitlab-tsukasa.atlassian.net/jira/software/projects/KAN/boards/1 |\n| 作成したプロジェクト | KAN |\n\n### GitLabのマニュアルの確認\n\n以下のURLで、GitLabとJiraについては、専用のインターフェースで設定します。Jiraの場合は他のプロダクトと比較して、よりレベルの高いインテグレーションが可能になっています。\n\n[Jira | GitLab Docs](https://docs.gitlab.com/integration/jira/)\n\nGitLabとJiraのインテグレーションは、以下の2箇所あります。\n\n* Jira イシュー … チケット機能です  \n* Jira デベロップメントパネル … GitLab内のブランチ情報などをJiraに連携します\n\nそれぞれ、GitLabとどう関係するのかは、以下のURLをご参考ください。\n\n[Jira | GitLab Docs](https://docs.gitlab.com/integration/jira/#feature-availability)\n\n例)  \n![フリー版のGitLabでできる52](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__52.png)\n\n(以下続く)\n\n### ユースケース1. Jira Issue Integration\n\n以下のURLにアクセスして、Jira側でAPIトークンを取得します。  \n[https://id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens)\n\nその時のユーザは、Jiraの管理者である必要があります。このユーザをつかって、GitLab側でのコミット情報をJira側にも書き込みます。\n\n#### GitLab側の設定\n\n![フリー版のGitLabでできる41](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__41.png)\nここでは、Web URLをつかって、インテグレーションをおこないます。\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| Web URL | https://gitlab-tsukasa.atlassian.net |\n\n以下の部分はデフォルトでチェックされていますので、そのままにします。これにより、Jira側へコメントが自動書き込みされます。\n![フリー版のGitLabでできる51](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__51.png)\n\nGitLab Premium版以上を使うと、GitLabの「イシュー」画面から透過的にJiraのイシューを見ることができますが、本書はGitLabフリー版を前提としていますので、GitLabの「イシュー」機能を非表示にします。\n\n#### GitLabのイシュー機能を非表示\n\nJiraをメインとして使う場合、GitLabの「設定」ー「一般」ー「可視性、プロジェクトの機能、権限」より、「イシュー」をOffにします。\n![フリー版のGitLabでできる17](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176161/Blog/upmcvbthskxusvq6qf38.png)\n\nその後、[変更を保存]ボタンを押して、設定を反映します。\n\n![フリー版のGitLabでできる8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__8.png)\n\nそうすると、以下のようにメニューの表示が変わります。\n\n![フリー版のGitLabでできる39](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__39.png)\n\n#### 実際に使用している様子\n\nJira側で、以下のようにイシューを作成します。\n\n![フリー版のGitLabでできる43](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__43.png)\n\nこの時、上の図のクリップアイコンをクリックすると、このチケットへのURLがクリップボードにコピーされます。\n\n#### GitLabのコミット時に「URL情報」を指定している様子\n![フリー版33](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/image33.png)\nコミットした後、以下のようにリンクが作成されます。\n![フリー版のGitLabでできる27](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__27.png)\n\n一方、キー番号のみを記述すると以下にになります。\n\n![フリー版のGitLabでできる40](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__40.png)\n\n![フリー版のGitLabでできる1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__1.png)\n上記で「Issue in Jira issue」をクリックすると、以下の画面に遷移します。\n\n![フリー版のGitLabでできる24](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__24.png)\n\nこのように、コメントが記入されますので、URLよりも、キーを指定することをおすすめします。\n\n#### 本インテグレーション（Jira Issue）のポイント \n\nGitLabとJira Issueのインテグレーションを実現すると、以下のような内容が実現できます。\n\n1. Jira側でイシューを作成  \n2. GitLab側でソースコード等へ修正を加え、コミット時に、Jira側でのチケット番号を指定すると、URLとして保存される  \n3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのJiraのチケットURLへ飛ぶことができる  \n4. さらに、そのJiraのチケットに、コミット時のコメントが記載される\n\nポイントとして、\n\n* GitLab側から、Jira Issue側へ直接「書き込み」を行う  \n* チケットへのURLを貼ると、「書き込み」は行われない  \n* これにより、GitLab ⇔ Jira間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ\n\nの3点が価値ポイントとなります。\n\n#### ご注意\n\n__GitLab Free版を使う場合__\n\n本機能を有効にすると、GitLab側の「イシュー」機能は残りますので、特別な理由がない限り、GitLab側の「イシュー」機能は停止するとよいでしょう。\n\n__ご参考__\nGitLab Premium以上をご利用するとGitLabの「イシュー」から、JiraのIssueが見えるようになります。\n\n[Jira issues integration | GitLab Docs](https://docs.gitlab.com/integration/jira/configure/#view-jira-issues)\n\nまた、GitLab Ultimateをご利用すると、GitLab側でセキュリティスキャンを行ったのち、脆弱性がみつかった際、その脆弱性をJira側へ新規のチケットとして起票する、という機能が利用可能です。\n\n[Jira issues integration | GitLab Docs](https://docs.gitlab.com/integration/jira/configure/#create-a-jira-issue-for-a-vulnerability)  \n\n### ユースケース2. Jira development panel Integration\n\nこのユースケースを使用する際、Jira側でどの「Jira」を使っているのかが重要になります。Atlassian社が提供するクラウドサービスを使っている場合、「GitLab for Jira Cloud app」(GitLab製)を使います。一方、オンプレミス版の「Jira Data Center or Jira Server」を使っている場合は、「Jira DVCS connector」（Atlassian社製）を使います。\n\n本書では、クラウドサービスのJiraを使っている、という前提で解説します。\n\n#### Jira側の設定\n\nJiraの画面で、「アプリ」ー「その他のアプリを探す」をクリックします。\n\n![フリー版のGitLabでできる14](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__14.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nここで、GitLab製のこの「GitLab for Jira Cloud」Appをインストールします。\n\n![フリー版のGitLabでできる7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__7.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n![フリー版のGitLabでできる2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__2.png)\n\n![フリー版のGitLabでできる48](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__48.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nこれで無事インストールが完了です。\n\n完了すると、次のポップアップが表示されますので、「Get started」をクリックします。\n\n![フリー版のGitLabでできる30](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__30.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nすると、次の画面が表示されますので、GitLab.comを選択した状態で、認証を完了させます。\n\n![フリー版のGitLabでできる18](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__18.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n![フリー版のGitLabでできる4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__4.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n次に、このAppを有効にするGitLab側のグループを選択する画面になります。ここで、任意のグループを選択します。\n\n![フリー版のGitLabでできる32](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__32.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nここで選択できるのは、プロジェクトではなく、グループです。\n\n![フリー版のGitLabでできる49](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__49.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n無事完了すると、次の画面になります。\n\n![フリー版のGitLabでできる53](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__53.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n#### 実際に使用している様子\n\nでは、実際になにがどう見えるのか実践してみます。\n\nJira側で、なにか適当なイシューを作成するなり、見つけてみましょう。そのキーが「KAN-14」だとします。\n![フリー版のGitLabでできる25](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__25.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nここで、GitLab側でなにか適当に変更して、コミットする際のダイアログボックス画面で以下のように入力します。\n\n![フリー版のGitLabでできる21](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__21.png)\n\nJira側にもどって、該当チケットを見てみます。\n\n赤矢印のところに、GitLab側のレポジトリ情報が連携されていることがわかります。\n\n![フリー版のGitLabでできる19](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__19.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n以下のように、コミット情報等も連携されていることがわかります。\n\n![フリー版のGitLabでできる28](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__28.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nまた、「すべての開発情報を表示」をクリックすると、以下のような画面も表示されます。\n![フリー版のGitLabでできる29](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__29.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n参考までに、この時点でこのAppをアンインストールすると、以下のように、開発情報は表示されなくなります。\n![フリー版のGitLabでできる42](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__42.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nJira側からブランチを作成することも可能です。  \n![フリー版のGitLabでできる22](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__22.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nまた、以下は他のチケットですが、一度コミット時にJiraとの紐づけを行っておくと、そのブランチに対してビルドしたり、デプロイしたりした履歴が、以下のようにJira側にも反映されます。\n\n![フリー版のGitLabでできる36](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__36.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n![フリー版のGitLabでできる38](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__38.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nこのように、Jiraのチケットから、「最終的にいまどこまで進んだ？」みたいな内容まで確認できるようになります。  \n",[235,1389,110,675,825,676,677,1390],"agile","embedded DevOps",{"slug":1392,"featured":92,"template":681},"gitlab-free-tier-integration-guide","content:ja-jp:blog:gitlab-free-tier-integration-guide.yml","Gitlab Free Tier Integration Guide","ja-jp/blog/gitlab-free-tier-integration-guide.yml","ja-jp/blog/gitlab-free-tier-integration-guide",{"_path":1398,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1399,"content":1405,"config":1412,"_id":1414,"_type":16,"title":1415,"_source":17,"_file":1416,"_stem":1417,"_extension":20},"/ja-jp/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"title":1400,"description":1401,"ogTitle":1400,"ogDescription":1401,"noIndex":6,"ogImage":1402,"ogUrl":1403,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1403,"schema":1404},"GitLab入門：CI/CD変数を使用する","CI/CD変数の概要、DevSecOpsにおいてCI/CD変数が重要な理由、活用するためのベストプラクティスについてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659525/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25.png","https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab入門：CI/CD変数を使用する\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2025-05-27\",\n      }",{"title":1400,"description":1401,"authors":1406,"heroImage":1402,"date":1407,"body":1408,"category":701,"tags":1409},[671],"2025-05-27","*「GitLab入門」シリーズへようこそ。このシリーズでは新たにGitLabを使い始める方向けに、GitLab\nDevSecOpsプラットフォームに慣れ親しむために役立つ内容をお届けします。*\n\n\n以前の記事で、[GitLab\nCI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/)について取り上げました。今回は**CI/CD変数**の世界をさらに深く掘り下げ、その力を最大限に引き出す方法について説明します。\n\n\n### CI/CD変数とは\n\n\nCI/CD変数とは、GitLab環境内においてさまざまなレベル（プロジェクト、グループ、インスタンスなど）で定義できる動的なキーと値のペアのことです。`.gitlab-ci.yml`ファイルで使用できる値のプレースホルダーとして機能するため、パイプラインをカスタマイズしたり、機密情報を安全に保存したりできるほか、CI/CD設定を管理しやすくなります。\n\n\n### CI/CD変数が重要な理由\n\n\nCI/CD変数の使用には、以下のような多くのメリットがあります。\n\n\n* **柔軟性** -\n主要なCI/CDスクリプトに手を加えることなく、さまざまな環境、設定、またはデプロイ対象にパイプラインを簡単に適応させられます。  \n * **セキュリティ** - API キー、パスワード、トークンのような機密情報を安全に保存して、コード内で直接公開されることのないようにします。  \n* **保守性** - 変数の値を一元化することで、CI/CDの設定がきれいに整理された状態に保たれるため、更新や修正作業を簡単に行えます。  \n\n* **再利用性** - 一度定義した変数は複数のプロジェクトで再利用できるため、重複が減り、一貫性を保ちやすくなります。\n\n\n### CI/CD変数のスコープ：プロジェクト、グループ、インスタンス\n\n\nGitLabでは、次のようなさまざまなスコープでCI/CD変数を定義し、その可視性と有効範囲を制御できます。\n\n\n* **プロジェクトレベルの変数** - 単一のプロジェクト専用の変数で、次のようなプロジェクト固有の設定を保存するのに適しています。\n  * デプロイURL：ステージング環境や本番環境向けのURLをそれぞれ定義します。  \n  * データベース認証情報：テストやデプロイ用のデータベース接続情報を保存します。  \n  * 機能フラグ：パイプラインのさまざまな段階で機能を有効または無効にします。  \n  * 例：\"MyWebApp\"というプロジェクトがあり、本番環境へのデプロイURLを保存したいとします。その場合、プロジェクトレベルで`DPROD_DEPLOY_URL`という名前の変数を作成し、`https://mywebapp.com`という値を格納します。  \n* **グループレベルの変数** -\nグループレベルの変数を作成すると、GitLabグループ内の全プロジェクトで共有されます。次のような複数のプロジェクトに共通する設定がある場合に便利です。\n\n  * 共有サービスのAPIキー：グループ内の複数のプロジェクトで使用されるサービス（AWS、Google Cloud、Docker Hubなど）のAPIキーを保存します。  \n  * グローバル構成設定：グループ内の全プロジェクトに適用される共通の設定パラメータを定義します。  \n  * 例：「Web Apps」というグループがあり、Docker Hub用にAPIキーを保存したいとします。その場合は、グループレベルで`DOCKER_HUB_API_KEY`という名前の変数を作成し、対応するAPIキーの値を格納します。  \n* **インスタンスレベルの変数** -\nGitLabインスタンスの全プロジェクトで利用可能な変数です。通常は、次のような組織全体に適用するグローバル設定がある場合に使用します。\n\n  * デフォルトのRunner登録トークン：新規[Runner](https://docs.gitlab.com/runner/)の登録時にデフォルトのトークンを提供します。  \n  * ライセンス情報：GitLabの機能やサードパーティツールのライセンスキー情報を保存します。  \n  * グローバル環境設定：全プロジェクトで利用可能な環境変数を定義します。  \n  * 例：GitLabインスタンス上の全プロジェクトにおいて、デフォルトのDockerイメージを設定したいとします。その場合、インスタンスレベルで`DEFAULT_DOCKER_IMAGE`という名前の変数を作成し、`ubuntu:latest`という値を格納します。\n\n### CI/CD変数を定義する\n\n\nCI/CD変数は以下の手順で定義できます。\n\n\n1. プロジェクト、グループ、またはインスタンスで、**設定 > CI/CD**ボタンの順にクリックします。  \n\n2. **変数**セクションに移動します。  \n\n3. **変数を追加**をクリックします。  \n\n4. **キー**（例：`API_KEY`）と**値**を入力します。  \n\n5.\n機密情報を扱う場合は、必要に応じて**変数を保護**ボックスをオンにします。オンにすると、保護ブランチまたは保護タグで実行されているパイプラインでのみ、変数が利用可能になります。  \n\n6. 必要に応じて、**変数をマスク**ボタンをオンにすると、ジョブログで変数の値が非表示になります。これにより、誤って公開されるのを防げます。  \n\n7. **変数を保存**をクリックします。\n\n\n### CI/CD変数を使用する\n\n\n`.gitlab-ci.yml`ファイルでCI/CD変数を使用する方法は簡単です。変数名の前にプレフィックスとして`$`を付けるだけです。\n\n\n```yaml\n\ndeploy_job:\n  script:\n    - echo \"Deploying to production...\"\n    - curl -H \"Authorization: Bearer $API_KEY\" https://api.example.com/deploy\n```\n\n\n### 定義済みのCI/CD変数\n\n\nGitLabでは、パイプラインでご利用いただけるように、[定義済みのCI/CD変数](https://docs.gitlab.com/ci/variables/predefined_variables/)を一式ご用意しています。これらの変数は、現在のパイプラインやジョブ、プロジェクトなどに関する情報を提供します。\n\n\nその中でも、使用されることの多い定義済み変数をいくつかご紹介します。\n\n\n* `$CI_COMMIT_SHA`：現在のパイプラインのコミットSHA。  \n\n* `$CI_PROJECT_DIR`：プロジェクトの複製先のディレクトリ。  \n\n* `$CI_PIPELINE_ID`：現在のパイプラインのID。  \n\n* `$CI_ENVIRONMENT_NAME`：デプロイ先の環境名（該当する場合）。\n\n\n### ベストプラクティス\n\n\n* 機密性の高い変数は安全に管理する：APIキーやパスワード、その他の機密情報を扱う場合は、保護およびマスクされた変数を使用しましょう。  \n\n* 値のハードコーディングは行わない：設定値を保存する際は変数を使用しましょう。そうすることで、パイプラインの柔軟性と保守性が高まります。  \n\n* 変数を整理する：変数をわかりやすい名前を付けて、関連する変数をまとめると、うまく整理できます。  \n\n* 適切なスコープを選ぶ：希望する変数の用途と可視性に基づいて、適切なスコープ（プロジェクト、グループ、またはインスタンス）を選びましょう。\n\n\n### 変数の力を最大限に活用する\n\n\nCI/CD変数は、GitLabパイプラインをカスタマイズし、保護するための強力なツールです。変数を使いこなし、各スコープを理解することで、より柔軟で保守しやすく、効率的なワークフローを作成できます。\n\n\n開発プロジェクトにおいて、GitLabの機能を活用していただくために必要な情報をお届けしました。ご紹介した情報がお役に立てば幸いです。\n\n\n> [Duo Enterpriseが搭載されたGitLab\nUltimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)に今すぐ申し込んで、CI/CD変数を早速ご利用ください。\n\n\n## 「GitLab入門」シリーズ\n\n「GitLab入門」シリーズのその他の記事もぜひご覧ください。\n\n\n-\n[ユーザーの管理方法](https://about.gitlab.com/ja-jp/blog/getting-started-with-gitlab-how-to-manage-users/)\n\n- \n[GitLabへのプロジェクトのインポート方法](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n\n-\n[プロジェクト管理を極める](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n\n- [gitlab-triage\ngemを使ったアジャイルワークフローの自動化](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n\n-\n[CI/CDについて理解する](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/)\n",[701,676,1410,1411,110,678],"CI","CD",{"slug":1413,"featured":92,"template":681},"getting-started-with-gitlab-working-with-ci-cd-variables","content:ja-jp:blog:getting-started-with-gitlab-working-with-ci-cd-variables.yml","Getting Started With Gitlab Working With Ci Cd Variables","ja-jp/blog/getting-started-with-gitlab-working-with-ci-cd-variables.yml","ja-jp/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"_path":1419,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1420,"content":1426,"config":1432,"_id":1434,"_type":16,"title":1435,"_source":17,"_file":1436,"_stem":1437,"_extension":20},"/ja-jp/blog/gitlab-18-0-release",{"ogTitle":1421,"schema":1422,"ogImage":1423,"ogDescription":1424,"ogSiteName":1223,"noIndex":6,"ogType":1244,"ogUrl":1425,"title":1421,"canonicalUrls":1425,"description":1424},"GitLab 18.0 リリース","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 18.0 リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-05-15\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662010/Blog/Hero%20Images/product-gl18-blog-release-cover-18-0-0750-1800x945-fy26.png","GitLab 18.0でリリースした最新機能をご紹介します。","https://about.gitlab.com/blog/gitlab-18-0-release",{"heroImage":1423,"body":1427,"authors":1428,"updatedDate":1429,"date":1430,"title":1421,"tags":1431,"description":1424,"category":701},"本ブログは、[GitLab 18.0 Release](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n## GitLab 18.0をリリース：GitLab DuoがPremiumとUltimateで利用可能に\n\nこのたび、GitLab 18.0のリリースを発表しました。このリリースでは、GitLab PremiumとGitLab UltimateにGitLab Duoが搭載され、GitLab Duoコードレビューによる自動レビュー、コンテキストをより考慮したコードレビュー、GitLab Duo Self-Hostedで利用可能なリポジトリX-Rayなど、さまざまな新機能が追加されました。  \n\nこれらの機能は、今回のリリースに含まれる30件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 18.0には、GitLabコミュニティのユーザーから328件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\nGitLab 18の新機能を活用することで、開発からリリースまでの全工程でAIの力を活用しつつ、開発者のスピードを落とさずにセキュリティを強化できます。これらがすべて、一つのプラットフォームで実現します。新機能については、[GitLab 18のオンラインリリースイベント「The next step in intelligent DevSecOps（知的進化する次世代のDevSecOps）」](https://about.gitlab.com/eighteen/)で詳しくご紹介いたします。ご参加をお待ちしています。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ](https://about.gitlab.com/upcoming-releases/)をご覧ください。\n\n[GitLab 18.0では、PremiumおよびUltimate向けのGitLab Duoが追加されました。 クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+18.0%E3%81%AE%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%A7%E3%81%AF%E3%80%81Premium%E3%81%8A%E3%82%88%E3%81%B3Ultimate%E5%90%91%E3%81%91%E3%81%AEGitLab+Duo%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-0-release/&hashtags=)\n\n## 今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は[Michael Hofer](https://gitlab.com/karras)さんです\n\n\u003Cimg src=\"https://about.gitlab.com/images/notable-contributor-logo.svg\">\n\nトップコントリビューターであり、コミュニティリーダーでもあるMichael Hoferさんは、GitLabの[オープンソース](https://about.gitlab.com/ja-jp/blog/what-is-open-source/)ミッションを推進しています。今年だけで[50件以上のコントリビュート](https://contributors.gitlab.com/users/karras?fromDate=2025-01-01&toDate=2025-05-12)を行い、その活動はOpenBaoに基づくGitLabのGeo機能やシークレットマネージャーの強化に大きく貢献しました。また、[4月のハッカソン](https://contributors.gitlab.com/hackathon?hackathonName=2025_04)ではトップの成績を収め、他のコントリビューターを支援しながらコミュニティプロジェクトも率いています。\n\n「GitLabには誰もがコントリビュートできる環境があるので、とても感謝しています！」とMichaelさんは言います。「素晴らしいチームで、一緒に取り組んでいてとても楽しいです。特に、OpenBaoやSLSAのような[オープンソース](https://about.gitlab.com/ja-jp/blog/what-is-open-source/)イニシアチブで協力する際は、みんな本当に頼りになります。」\n\nMichaelさんは、ミッションクリティカルな[オープンソース](https://about.gitlab.com/ja-jp/blog/what-is-open-source/)ワークロードの計画、構築、運用に特化した国際的なITサービスプロバイダーである[Adfinis社](https://adfinis.com/en/)のCTOを務めています。Michaelさんは、組織間での協力を促進し、[オープンソース](https://about.gitlab.com/ja-jp/blog/what-is-open-source/)ソリューションの普及に情熱を注いでいます。\n\n最近、Adfinis社はGitLabの[共同開発プログラム](https://about.gitlab.com/community/co-create/)に参加しました。このプログラムでは、組織がGitLabの製品チームおよびエンジニアリングチームと協力して、GitLabの構築に取り組んでいます。「共同開発プログラムを、すべての組織に強くお勧めしたいです」とMichaelさんは話します。「PodmanのルートレスビルドやGlimmerの構文ハイライトに加え、その他多くの素晴らしいコントリビュートを生み出しました。」\n\nGitLabのエンジニアリングマネージャーであり、今回Michaelさんを推薦した[Lucie Zhao](https://gitlab.com/luciezhao)は次のように話します。「GeoチームはMichaelさんとの共同作業に大きなやりがいと楽しみを感じています。Michaelさんは、ここ数件のマイルストーンでの素晴らしいコントリビュートにより、チーム内で最も知られたコミュニティコントリビューターとなりました。」\n\nGitLabチームメンバーの[Lee Tickett](https://gitlab.com/leetickett-gitlab)、[Chloe Fons](https://gitlab.com/c_fons)、[Alex Scheel](https://gitlab.com/cipherboy-gitlab)も、Michaelさんの推薦を支持しました。Alexは次のように述べています。「MichaelさんのOpenBaoでのリーダーシップにより、お客様向けのシークレット管理ソリューションを効果的に共同開発することができました。また、透明性も確保され、GitLabの価値観に沿って進められました。」\n\nGitLabの共同開発に取り組んでくださっているMichaelさんとAdfinisチームのみなさま、ありがとうございます！\n\u003Cbr>\n\u003Cbr>\n\u003Cbr>\n\n## GitLab 18.0でリリースされた主な改善点\n\n### GitLab DuoがGitLab PremiumおよびGitLab Ultimateで利用可能に\n\n> SaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise  \n\nこのリリースから、GitLab PremiumとGitLab UltimateでGitLab Duoが利用可能になりました。両プランにAI機能が標準搭載されます。\n\nGitLabのAIネイティブ機能には、IDE内のコード提案とチャット機能があります。開発チームは、これらの機能を使用して次の作業を効率化できます。\n\n* コードを分析し、理解し、説明する\n* より迅速に安全なコードを記述する\n* コード品質を維持するためのテストを素早く生成する\n* パフォーマンス向上や特定のライブラリの利用に合わせてコードを簡単にリファクタリングする\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/#summary-of-gitlab-duo-features)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/538857)  \n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/Premium_Duo.png\">\n\n### GitLab Duo Self-HostedでリポジトリX-Rayが利用可能に\n\n> SaaS: - \u003Cbr>\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duo Self-Hostedで、コード提案と併せてリポジトリX-Rayを使用できるようになりました。この機能は、GitLab Duo Self-Hostedではベータ版として提供され、GitLab Self-Managedインスタンスでは一般提供されています。\n\n[ドキュメント](https://docs.gitlab.com/user/project/repository/code_suggestions/repository_xray/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17756)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/eclipse-beta.png\">\n\n### GitLab Duoコードレビューによる自動レビュー\n\n> SaaS: Premium、Ultimate、Duo Enterprise\u003Cbr>\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nDuoコードレビューは、コードレビューのプロセスで効果的なフィードバックを提供しますが、これまでは各マージリクエストごとに手動でレビューをリクエストする必要がありました。\n\n今回、プロジェクトのマージリクエスト設定を変更することで、Duoコードレビューを自動的に実行できるようになりました。自動レビュー機能を有効にすると、以下の場合を除き、すべてのマージリクエストに対してDuoコードレビューが自動でレビューを行います。\n\n* マージリクエストがドラフトとしてマークされている場合  \n* マージリクエストに変更が含まれていない場合\n\n自動レビュー機能により、プロジェクト内のすべてのコードが確実にレビューされ、コードベース全体のコード品質が継続的に改善されます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#automatic-reviews-from-gitlab-duo)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/506537)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/create-auto-dcr.png\">\n\n### コード提案にプロンプトキャッシュを導入\n\n> SaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise  \n\nコード提案にプロンプトキャッシュ機能が追加されました。この機能により、キャッシュされたプロンプトや入力データの再処理が不要になるため、コード補完の待機時間が大幅に短縮されます。キャッシュデータは永続ストレージに保存されることはなく、必要に応じてGitLab Duoの設定でプロンプトキャッシュを無効にすることも可能です。\n\n[ドキュメント](https://docs.gitlab.com/user/project/repository/code_suggestions/#prompt-caching)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17489)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/prompt-cache.png\">\n\n### コンテキストをより考慮したコードレビュー\n\n> SaaS: Premium、Ultimate、Duo Enterprise\u003Cbr>\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nコードレビューがより広範なコンテキスト情報を活用できるようになり、分析結果の精度が向上しました。主な改善点は以下のとおりです。\n\n* マージリクエストのタイトルと説明を含めることで、変更の目的をより正確に把握できるようになりました。  \n* すべての差分を一度に分析することで、ファイル間の関連性を認識し、誤検出を削減します。  \n* 変更されたファイル全体の内容を読み込み、修正が既存のコードパターンにどのように適合するかを理解できるようになりました。\n\nこれらの機能強化により、不正確な提案が減少し、より関連性が高く高品質なコードレビューが可能になりました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/466684)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/510266) \n\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/532653)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/create-dcr-improved-context.png\">\n\n## GitLab 18.0のリリースに含まれるその他の改善点\n\n### グループとプレースホルダーユーザーの削除\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab 18.0では、トップレベルグループを削除すると、そのグループに関連付けられたプレースホルダーユーザーも同時に削除されるようになりました。プレースホルダーユーザーが他のプロジェクトに関連付けられている場合は、トップレベルグループからのみ削除され、他のプロジェクトには残ります。これにより、他のプロジェクトの履歴や属性を損なうことなく、不要なプレースホルダーユーザーを整理できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/import/#placeholder-user-deletion)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/473256)\n\n### Slackアプリ用GitLabで複数のワークスペースに対応\n\n> SaaS: -\u003Cbr>\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Self-ManagedおよびGitLab Dedicatedのお客様向けに、GitLab for Slackアプリで複数のワークスペースを利用できるようになりました。この機能により、複数のSlackワークスペースを持つ組織でも、すべてのワークスペースでGitLabとの連携をスムーズに維持できます。複数のワークスペースを有効にするには、GitLab for Slackアプリを[非公開配布アプリ](https://api.slack.com/distribution#unlisted-distributed-apps)として設定してください。\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/slack_app/#enable-support-for-multiple-workspaces)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/424190)\n\n### GitLab Pagesテンプレートの改善\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLabでは、[人気の高い静的サイトジェネレーター用のテンプレート](https://gitlab.com/pages)を提供しています。スコアリングフレームワークでテンプレートを精査し、最も人気のあるものだけを厳選しました。\n\nGitLab Pagesで利用可能なテンプレートが改良されたことにより、ウェブサイト制作の工程がよりスムーズになりました。テンプレートを活用すれば、技術的な専門知識が限られていてもプロ並みのサイトを立ち上げることができます。改善されたテンプレートは最新のレスポンシブデザインに対応しており、カスタム開発作業の必要もありません。\n\n[ドキュメント](https://docs.gitlab.com/user/project/pages/getting_started/pages_new_project_template/#project-templates)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13847)\n\n### ワークスペースの共有Kubernetesネームスペース\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n共有のKubernetesネームスペースにGitLabワークスペースを作成できるようになりました。これにより、ワークスペースごとに新しいネームスペースを作成する必要がなくなり、エージェントに上位のClusterRole権限を付与する必要もなくなります。この機能により、セキュリテイが厳しい環境または制約のある環境でもワークスペースをより容易に導入できるようになり、よりスムーズにスケールできるようになります。\n\n共有のネームスペースを有効にするには、エージェント設定ファイルの`shared_namespace`フィールドを設定し、すべてのワークスペースで使用したいKubernetesネームスペースを指定してください。\n\nこの機能は、[GitLabの共同開発プログラム](https://about.gitlab.com/community/co-create/)を通じて開発され、6人のコミュニティメンバーの協力によって実現しました。皆さまのコントリビュートに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/user/workspace/settings/#shared_namespace)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12327)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/CXakdRuoGgU?si=indgAnCrTuIhUhcM\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### GitLab Runner 18.0\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Runner 18.0もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドのエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\n新機能：\n\n* [GitLab Runnerビルドエラー分類に`ConfigurationError`と`ExitCodeInvalidConfiguration`を新たに追加](https://gitlab.com/gitlab-org/gitlab/-/issues/514297)  \n* [Cloud Storageへのキャッシュアップロードに失敗した場合に、よりわかりやすいクラウドプロバイダーエラーメッセージを表示するよう改善](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/5527)\n\nバグ修正：\n\n* [GitLab Runnerが、許可されていない場合でもキャッシュされたイメージを使用できてしまう](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38706)\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-0-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner/)\n\n### Kubernetes用ダッシュボードのポッド状態表示を改善\n\n> SaaS: Free、Premium、Ultimate\u003Cbr>\n> Self-Managed: Free、Premium、Ultimate\n\nKubernetes用のダッシュボードを使用すると、デプロイされたアプリケーションをモニタリングできます。これまで`CrashLoopBackOff`や`ImagePullBackOff`などのコンテナエラーがあるポッドは「保留中」または「実行中」というステータスで表示されていたため、`kubectl`を使用せずに問題のあるデプロイメントを特定するのが困難でした。\n\nGitLab 18.0からは、UI上のエラー表示が`kubectl`出力と同様に、特定のコンテナのステータスを示すようになりました。これにより、GitLabインターフェイスだけで失敗したポッドをすばやく特定し、トラブルシューティングを行えるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ci/environments/kubernetes_dashboard/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/525081)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/deploy-improve-pod-status-visualizations.png\">\n\n### セキュリティスキャナーがMRパイプラインに対応\n\nSaaS: Free、Premium、Ultimate\\\nSelf-Managed: Free、Premium、Ultimate\n\n[マージリクエスト（MR）パイプライン](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/)で[アプリケーションセキュリティテスト（AST）スキャナー](https://docs.gitlab.com/user/application_security/detect/)を実行できるようになりました。パイプラインへの影響を最小限に抑えるため、この機能はオプトインで制御可能です。\n\nこれまでは、スキャナーを有効にする際に使用する[CI/CDテンプレートのエディション（StableかLatest）](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions)によって、デフォルトの動作が異なっていました。\n\n* Stableのテンプレートでは、スキャンジョブはブランチパイプラインでのみ実行され、MRパイプラインでは実行されませんでした。  \n* Latestのテンプレートでは、MRが開いている場合はMRパイプラインでスキャンジョブが実行され、関連するMRがない場合はブランチパイプラインで実行されており、この動作を制御することはできませんでした。\n\n今回、新しいオプションとして`AST_ENABLE_MR_PIPELINESが追加され`、MRパイプラインでジョブを実行するかどうかを制御できるようになりました。StableテンプレートとLatestテンプレートのデフォルトの動作は変わりません。\n\n具体例：\n\n* Stableテンプレートでは引き続き、デフォルトでブランチパイプラインでスキャンジョブを実行しますが、`AST_ENABLE_MR_PIPELINES: \"true\"`を設定すると、MRが開いている場合にMRパイプラインを使用できます。  \n* Latestテンプレートでは引き続き、MRが開いている場合はデフォルトでMRパイプラインでスキャンジョブを実行しますが、`AST_ENABLE_MR_PIPELINES: \"false\"`を設定すると、代わりにブランチパイプラインを使用できます。\n\n今回の改善は、API Discovery（`API-Discovery.gitlab-ci.yml`）を除くすべてのセキュリティスキャンテンプレートに適用されます。API Discoveryは現在、MRパイプラインがデフォルトですが、GitLab 18.0では他のStableテンプレートと同様に、デフォルトでブランチパイプラインを使用するように変更されました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#use-security-scanning-tools-with-merge-request-pipelines)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/410880)\n\n### JiraインテグレーションAPIを使用して脆弱性からJiraのイシューを作成する設定が可能に\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nこれまでは、[脆弱性からJiraのイシューを作成](https://docs.gitlab.com/integration/jira/configure/#create-a-jira-issue-for-a-vulnerability)する設定は、プロジェクト設定ページからしか行えませんでした。\n\n今回の更新により、プロジェクト統合APIからも設定できるようになり、セットアップの自動化が可能になりました。\n\n[ドキュメント](https://docs.gitlab.com/api/project_integrations/#jira-issues)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/454574)\n\n### 再検出された脆弱性のトレーサビリティの向上\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまで、解決済みの脆弱性が再検出されてステータスが変更された場合、脆弱性の詳細にはいつ、なぜステータスが変更されたかを示す情報が含まれていませんでした。\n\n解決済みの脆弱性が新しいスキャンで再び検出されてステータスが変更された場合、GitLabはその脆弱性の履歴にシステムメモを自動的に追加するようになりました。これにより、ユーザーは脆弱性のステータスが変更された経緯を明確に把握できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerabilities/#vulnerability-status-values)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/523452)\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[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_projects_report/#filter-the-compliance-projects-report)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/500520)\n\n### GitLabユーザー名を使用したLDAP認証\n\n> SaaS: -\u003Cbr>\n> Self-Managed: Premium、Ultimate\n\nLDAPユーザーは、GitLabユーザー名を使用してリクエストを認証できるようになりました。これまでは、GitLabユーザー名がLDAPユーザー名と一致しない場合、GitLabは認証エラーを返していました。今回の変更により、承認ワークフローに影響を与えることなく、GitLabシステムとLDAPシステムで異なるユーザー名の命名規則を採用できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/administration/auth/ldap/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/215357)\n\n### カスタムロールの新しい権限\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n[保護環境を管理](https://gitlab.com/gitlab-org/gitlab/-/issues/471385)する権限をカスタムロールに設定できるようになりました。カスタムロールを使用すれば、ユーザーに対して、タスクの完了に必要な特定の権限のみを付与できます。これによりグループのニーズに合わせてロールを定義できるため、オーナーまたはメンテナーロールが必要なユーザー数を減らすことができます。\n\n[ドキュメント](https://docs.gitlab.com/user/custom_roles/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14746)\n\n### ユーザーネームスペースのプロジェクトにも削除保留機能を追加\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nユーザーネームスペース（個人プロジェクト）のプロジェクトでも、プロジェクト削除保留機能が利用できるようになりました。誤削除からデータを守るこの安全機能は、これまではグループプロジェクトでしか利用できませんでした。今回の更新により、ユーザーネームスペースでプロジェクトを削除しても、すぐに完全に削除されるのではなく、インスタンスの設定期間（GitLab.comでは7日間）は「削除保留中」の状態になります。これにより、期間内であれば、必要に応じてプロジェクトを元に戻すことが可能になりました。\n\nユーザーの皆さまがより安心して個人プロジェクトを管理できるよう設計された保護機能です。\n\n[ドキュメント](https://docs.gitlab.com/user/project/working_with_projects/#delayed-project-deletion)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/536244)\n\n### 破壊的な変更を伴うGitLabチャート9.0のリリース\n\n> SaaS: -\u003Cbr>\n> Self-Managed: Free、Premium、Ultimate\n\n* [破壊的な変更](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)：PostgreSQL 14と15のサポートが削除されました。GitLabチャート9.0にアップグレードする前に、PostgreSQL 16にアップグレードされていることを確認してください。  \n* [破壊的な変更](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)：バンドルのPrometheusチャートが15.3から27.11に更新されました。Prometheusチャートのアップグレードに伴い、Prometheusバージョンも2.38から3.0に更新されました。このアップグレードを実行するには、手動での設定が必要です。Alertmanager、Node Exporter、Pushgatewayのいずれかが有効になっている場合は、Helm値も更新する必要があります。詳細については、[移行ガイド](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade)を参照してください。  \n* [破壊的な変更](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)：デフォルトのNGINXコントローラーイメージがバージョン1.3.1から1.11.2に更新されました。GitLab NGINXチャートを使用し、独自のNGINX用RBACルールを設定している場合は、新しいRBACルールが必要となります。詳細については、[アップグレードガイド](https://docs.gitlab.com/charts/releases/8_0/#upgrade-to-86x-851-843-836)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/charts/releases/9_0/)\\\n[イシュー](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5927)\n\n### GitLab Dedicated向けに内部リリース機能を提供開始\n\n> SaaS: -\u003Cbr>\n> Self-Managed: Ultimate\n\nGitLab Dedicatedを選択される組織の多くは、厳格なセキュリティ要件やコンプライアンス義務を満たすために、開発環境における最高レベルの保護を必要としています。このたび、「内部リリース」という新しいプライベートリリース機能の提供を開始しました。致命的な脆弱性が一般に公開される前にGitLab Dedicatedインスタンスに修正を適用できるようになり、GitLab Dedicatedのお客様をリスクから保護します。この新機能は、GitLab.comでの対応と並行し、GitLabで発見された致命的な脆弱性に対して即時の保護を提供するものです。この新しいプロセスは、お客様側での操作は必要ありません。\n\n[ドキュメント](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/)\\\n[エピック](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1201)\n\n### グループとプロジェクトのREST APIに新しい`アクティブ`パラメータを追加\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nグループとプロジェクトのREST APIに新しい`アクティブ`パラメータが追加されました。これにより、ステータスに基づいたグループのフィルタリングが簡素化されます。`true`に設定すると、アーカイブされていないグループ、または削除マークが付いていないプロジェクトのみが返されます。`false`に設定すると、アーカイブされたグループ、または削除マークが付いているプロジェクトのみが返されます。パラメータを指定しない場合、フィルタリングは適用されません。この機能強化により、簡単なAPIコールで特定のステータスを持つグループやプロジェクトだけを選び出せるようになり、作業プロセス全体をより効率的に管理できるようになります。\n\nこのパラメータをプロジェクトAPIに追加してくれた[@dagaranupam](https://gitlab.com/dagaranupam)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/api/projects/#list-projects)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/526206)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/526205)\n\n### GitLab.comでのコントリビュートの再アサイン時にEnterpriseユーザーのみを表示\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n今回のリリースでは、プレースホルダーユーザーマッピング体験を向上させました。具体的には、ユーザー選択ドロップダウンの表示範囲を、トップレベルグループに関連付けられた[Enterpriseユーザー](https://docs.gitlab.com/user/enterprise_user/)に絞り込むように改善しました。これまで、GitLab.comへのインポート後にユーザーのコントリビュートを再アサインすると、プラットフォーム上のすべてのアクティブユーザーがドロップダウンリストに表示されていました。この仕様では、特にSCIMプロビジョニングでユーザー名が変更されている場合などは、正しいユーザーを特定するのが困難でした。今回の変更により、トップレベルグループでEnterpriseユーザー機能が有効になっている場合、ドロップダウンリストには組織が要求したユーザーのみが表示されるようになり、ユーザーの再アサイン時に発生するエラーの可能性が大幅に低減されます。同様の絞り込みがCSVベースの再アサインにも適用されるため、組織外のユーザーへの誤ったアサインを防ぐことができます。\n\n[ドキュメント](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#user-contribution-and-membership-mapping)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/510673)\n\n### GitLabクエリ言語ビューの機能強化\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLabクエリ言語（GLQL）ビューが大幅に改善されました。新しく追加された機能は以下のとおりです。\n\n* すべての日付型で`>=`および`\u003C=`の条件指定が可能に  \n* ビューの「ビューアクション」ドロップダウンが追加  \n* 「**再読み込み**」アクションが利用可能に  \n* フィールドエイリアス対応  \n* GLQLテーブルの列でカスタム名にエイリアス設定が可能に\n\nこの機能強化およびGLQLビュー全般に関するフィードバックは、[イシュー509791](https://gitlab.com/gitlab-org/gitlab/-/issues/509791)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/glql/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15008)\n\n### マージリクエストからワークスペースを作成\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n新しい「**ワークスペースで開く**」オプションを使用して、マージリクエストから直接ワークスペースを作成できるようになりました。この機能は、マージリクエストのブランチとコンテキストを使用してワークスペースを自動的に構成し、以下のことを可能にするものです。\n\n* 完全に設定された環境でコード変更をレビュー  \n* マージリクエストブランチでテストを実行し、機能を検証  \n* ローカル環境の設定なしでマージリクエストに修正を追加\n\n[ドキュメント](https://docs.gitlab.com/user/workspace/configuration/#create-a-workspace)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/426568)\n\n### ファイルをターゲットとするオープンマージリクエストの表示\n\n> SaaS: Free、Premium、Ultimate\u003Cbr> \n> Self-Managed: Free、Premium、Ultimate\n>\n> これまでは、コードファイルを編集する際に、他のブランチで同じファイルを変更している可能性のあるユーザーの動向を把握することはできませんでした。このため、マージの競合や作業の重複、非効率的なコラボレーションが生じていました。\n\n今回の変更により、リポジトリで表示しているファイルを変更しているすべてのオープンマージリクエストを簡単に特定できるようになりました。この機能は次のような場面で役立ちます。\n\n* マージコンフリクトを事前に特定する  \n* すでに進行中の作業の重複を回避する  \n* 進行中の変更を可視化してコラボレーションを強化する\n\nファイルを変更しているオープンマージリクエストの数がバッジに表示され、その上にカーソルを合わせると、該当するマージリクエストのリストがポップオーバーで表示されます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/repository/files/#view-open-merge-requests-for-a-file)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/448868)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/mr-open-workspace.png\">\n\n### 新しい「CI/CDの分析」表示機能の限定提供を開始\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\n「CI/CDの分析」のデザインが改良され、開発チームがパイプラインのパフォーマンスと信頼性を新しい方法で分析、監視、最適化できるようになりました。デベロッパーは、GitLabの操作画面に表示される直感的なグラフによってパフォーマンスの傾向や信頼性に関するメトリクスを確認できます。これらの分析情報をプロジェクトリポジトリに埋め込むことで、デベロッパーの作業の流れを中断させる頭の切り替えが不要になります。そして、チームは、生産性を低下させるパイプラインのボトルネックを特定して対処することができます。この機能強化により、開発サイクルの高速化、コラボレーションの向上が実現されるだけでなく、具体的な分析結果に基づき、GitLabのCI/CD環境を最適化するための信頼できる材料を得ることができます。\n\n[ドキュメント](https://docs.gitlab.com/user/analytics/ci_cd_analytics/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/444468)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/78Nxbem9OAk?si=KTKVK7EsiW9E4Zxm\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### イベントデータ収集\n\n> SaaS: -\u003Cbr>\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab 18.0では、GitLab Self-ManagedおよびGitLab Dedicatedインスタンスからイベントレベルの製品使用状況データの収集が有効にされます。集計データとは異なり、イベントレベルのデータは製品利用の実態をより正確に把握するための情報源となります。これにより、プラットフォーム上のユーザーエクスペリエンスを向上させ、機能の利用率を高めることができます。データ共有設定を調整する方法の詳細については、ドキュメントを参照してください。\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/event_data/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/510333)\n\n### 脆弱性レポートからイシューへ脆弱性を一括追加\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n今回リリースでは、脆弱性レポートから新規または既存のGitLabイシューに複数の脆弱性を一括追加できるようになりました。これにより、複数のイシューと脆弱性を関連付けることが可能になります。さらに、関連する脆弱性がイシューページに表示されるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerability_report/#add-vulnerabilities-to-an-existing-issue)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13216)\n\n### ライセンス承認ルールからパッケージを除外\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nマージリクエスト承認ポリシーに追加されたライセンス承認ポリシーの新機能により、法務チームやコンプライアンスチームは、特定のライセンスを使用できるパッケージをより細かく制御できるようになりました。これにより、組織のポリシーによって通常ブロックされるライセンスを使用している場合でも、事前に承認されたパッケージの例外を作成できるようになります。\n\nこれまでのライセンス承認ポリシーでは、AGPL-3.0などのライセンスをブロックした場合、組織内のすべてのパッケージでそのライセンスがブロックされていました。これにより、次のような場面で問題が発生していました。\n\n* 法務チームが、通常は制限されているライセンスであっても特定のパッケージを事前に承認している場合  \n* 数百件ものプロジェクトで同じパッケージを使用する必要がある場合  \n* チームごとに異なるライセンスの例外が必要な場合\n\n今回のリリースでは、厳格なライセンスガバナンスを維持しつつ必要な例外を許可できるようになり、承認のボトルネックや手作業でのレビューを大幅に削減できます。たとえば、以下のような設定が可能です。\n\n* パッケージURL（PURL）形式を使用して、ライセンス承認ルールにパッケージ固有の例外を定義  \n* 通常は制限されているライセンスでも、特定のパッケージ（またはパッケージのバージョン）に限って使用を許可  \n* 特定のパッケージ（またはパッケージのバージョン）に対し、一般的に許可されているライセンスの使用をブロック\n\n例外を追加するには、ライセンス承認ポリシーの作成または編集時に次のワークフローに従ってください。\n\n1. グループで**セキュリティ** > **ポリシー**に移動します。  \n2. ライセンス承認ポリシーを作成または編集します。  \n3. ビジュアルエディタで新しいパッケージ例外オプションを見つけるか、YAMLモードで構成します。  \n4. ライセンスに対して、許可リストまたは拒否リストを選択します。  \n5. ポリシーに特定のライセンスを追加します。\n6. ライセンスごとにPURL形式でパッケージ例外を定義します。\n\n例：`pkg:npm/@angular/animation@12.3.1`\n\n7. ライセンスルールにこれらのパッケージを含めるか除外するかを指定します。\n\nこれらの設定後は、ポリシーが定義された例外を適切に処理しながらライセンスルールを適用するため、組織全体でライセンスコンプライアンスをきめ細かく制御できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/#license_finding-rule-type)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/10203)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/license-exceptions-mr-approval-policy.png\">\n\n### ユーザー招待機能の無効化\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nグループやプロジェクトにメンバーを招待する機能を制限できるようになりました。\n\n* GitLab.comでは、Enterpriseユーザーを持つグループのオーナーがこの制限を設定でき、設定はトップレベルグループ内のサブグループやプロジェクトに適用されます。この招待制限が設定されると、どのユーザーも新しいメンバーを招待することはできません。  \n* GitLab Self-Managedの場合、この制限設定は管理者によって行われ、インスタンス全体に適用されます。その後も、管理者は引き続きユーザーを直接招待できます。\n\nこの機能は、組織がメンバーシップアクセスを厳格に管理したい場合に便利です。\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/visibility_and_access_controls/#disable-user-invitations)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/19618)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/disable_invitations.png\">\n\n### ジョブトークンのきめ細かい権限管理がベータ版として登場\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nパイプラインセキュリティがさらに柔軟になりました。ジョブトークンはパイプライン内でリソースにアクセスするための一時的な認証情報です。トークンはこれまで、ユーザーから完全な権限を継承していたため、不必要に広範なアクセスが付与される事態が数多く発生していました。\n\n新しく追加された[ジョブトークンのきめ細かい権限](https://docs.gitlab.com/ci/jobs/fine_grained_permissions/)ベータ機能により、プロジェクト内でジョブトークンがアクセスできる特定のリソースを正確に制御できるようになりました。これにより、CI/CDワークフローで最小権限の原則を実装し、各ジョブに対してタスクの実行に必要な最小アクセス権のみを設定できるようになります。\n\nこの機能について、コミュニティからのフィードバックをぜひお寄せください。ご質問や実装経験の共有、改善点に関して当社チームへのご意見がある場合は、[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/519575)をご確認ください。\n\n[ドキュメント](https://docs.gitlab.com/ci/jobs/fine_grained_permissions/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16199)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/sscs-authz-fine-grained-job-tokens.png\">\n\n### ユーザーセッション最大長の制限\n\n> SaaS: -\u003Cbr>\n> Self-Managed: Free、Premium、Ultimate\n\n管理者は、ユーザーセッションの最大有効期間を「最初のサインイン」から計算するか、または「最後のアクティビティー」から計算するかを選択できるになりました。ユーザーにはセッションが終了することが通知されますが、セッションの有効期限を変更したり、セッションを延長したりすることはできません。この機能はデフォルトで無効になっています。\n\nこの場を借りて、コントリビュートしてくれた[John Parent](https://gitlab.kitware.com/john.parent)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/account_and_limit_settings/#set-sessions-to-expire-from-creation-date)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/395038)\n\n### SAML証明書のSHA256サポート\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nGitLabは、グループSAML認証におけるSHA1およびSHA256の証明書フィンガープリントを自動的に検出し、サポートするようになりました。これにより、既存のSHA1フィンガープリントとの下位互換性が維持されるほか、より安全なSHA256フィンガープリントのサポートが追加されます。今回のアップグレードは、SHA256をデフォルト設定とする次世代ruby-saml 2.xに対応するための必須の対応となります。\n\n[ドキュメント](https://docs.gitlab.com/integration/saml/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/524624)\n\n### すべてのユーザーが利用できる削除保留機能\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nプロジェクトとグループの削除保留機能が、Freeプランを含むすべてのGitLabユーザーに提供されるようになりました。この重要なセキュリティ機能は、削除されたグループやプロジェクトが完全に削除される前に、猶予期間（GitLab.comでは7日間）を設けるものです。この機能により、誤って削除した場合でも複雑な手順を踏まずに簡単に復元できるようになります。\n\nデータ保護を基盤機能として組み込むことで、大切なデータを消失リスクから守ります。\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/visibility_and_access_controls/#deletion-protection)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/526405)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17208)\n\n\u003Cimg src=\"https://about.gitlab.com/images/18_0/tenant_scale_deletion_protcection_all_tiers.png\">\n\n### グループ、プロジェクト、ユーザーAPIのレート制限\n\n> SaaS: Free、Premium、Ultimate\n> Self-Managed: -\n\nすべてのユーザーに対してプラットフォームの安定性とパフォーマンスを向上させることを目的として、プロジェクト、グループ、ユーザーごとにAPIレート制限を追加しました。今回の変更は、当社のサービスに影響を与えているAPI通信の増加に対応するものです。\n\nこの制限は平均的な使用パターンに基づいて慎重に設定されており、ほとんどのユースケースにおいて十分な容量を提供するよう設計されています。制限を超えると、「429 Too Many Requests」（リクエスト過多）という応答が返されます。\n\n特定のレート制限と実装情報の詳細については、[関連のブログ記事をご覧ください](https://about.gitlab.com/blog/rate-limitations-announced-for-projects-groups-and-users-apis/)。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_com/#rate-limits-on-gitlabcom)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/461316)\n\n\u003Cbr>\n\u003Cbr>\n\n## 実験的な機能\n\n### スケジュールされたパイプライン実行ポリシー\n\nこの実験的機能を有効にすると、カスタマイズされたCI/CDジョブやスクリプトを使い、定期スケジュールでパイプライン実行ポリシーをトリガーできます。主な特徴は以下のとおりです。\n\n* スケジュールされたパイプラインでは、コンプライアンススクリプト、GitLabまたはサードパーティ製のセキュリティスキャン、その他のカスタムCI/CDジョブを強制実行できます。  \n* セキュリティおよびコンプライアンス要件を確実に満たすためのツールとして、スケジュールされたパイプラインを実行して日次、週次、月次のスケジュールでジョブを実行することができます。  \n* スケジュールされたパイプラインは、プロジェクトの`.gitlab-ci.yml`ファイルにジョブをインジェクトしたり強制したりせず、ダウンストリームのプロジェクトパイプラインに影響を与えません。  \n* 代わりに、これらのパイプラインを使用して、デフォルトブランチを定期的に対象とし、依存関係やプロジェクト構成、その他の要件を確認するといったアクションを実行できます。\n\n実験を有効にするには`policy.yml`ファイルを作成するか、セキュリティポリシープロジェクトの既存の`policy.yml`ファイルを変更して`experiments`属性を追加します。有効にすると、パイプライン実行ポリシーを設定できるようになります。このポリシーには、パイプライン実行ポリシーが適用されているすべてのプロジェクトでカスタムCI/CDジョブを実行するスケジュールが含まれます。\n\nトリガーされるパイプライン実行ポリシーは複数作成できますが、セキュリティポリシープロジェクトごとに設定できるスケジュールされたパイプライン実行ポリシーは1件のみです。\n\n詳細については、[スケジュールされたパイプライン実行ポリシー](https://docs.gitlab.com/user/application_security/policies/scheduled_pipeline_execution_policies/)を参照してください。\n\n\u003Cbr>\n\u003Cbr>\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n\n18.0で提供されたすべてのバグ修正、パフォーマンスの強化、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.0)  \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.0)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.0)\n\n\u003Cbr>\n\u003Cbr>\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#resource-owner-password-credentials-grant-is-deprecated)\n* [cert-manager Helm チャートをアップデート](https://docs.gitlab.com/ee/update/deprecations.html#cert-manager-helm-chart-update)\n* [カバレッジガイド付きファズテストを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#coverage-guided-fuzz-testing-is-deprecated)\n\n\u003Cbr>\n\u003Cbr>\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n* [APIディスカバリーはデフォルトでブランチパイプラインを使用するように](https://docs.gitlab.com/ee/update/deprecations.html#api-discovery-will-use-branch-pipelines-by-default)  \n* [アプリケーションセキュリティテスト（AST）アナライザーのメジャーバージョンをアップデート](https://docs.gitlab.com/ee/update/deprecations.html#application-security-testing-analyzers-major-version-update)  \n* [「今後」および「開始済み」マイルストーンフィルタの動作を変更](https://docs.gitlab.com/ee/update/deprecations.html#behavior-change-for-upcoming-and-started-milestone-filters)  \n* [CI/CDジョブトークン - 「認証されたグループとプロジェクト」許可リストの強制適用](https://docs.gitlab.com/ee/update/deprecations.html#cicd-job-token-authorized-groups-and-projects-allowlist-enforcement)  \n* [CI/CDジョブトークン - 「プロジェクトからのアクセス制限」設定を削除](https://docs.gitlab.com/ee/update/deprecations.html#cicd-job-token-limit-access-from-your-project-setting-removal)  \n* [DASTのdast_devtools_api_timeoutのデフォルト値引き下げ](https://docs.gitlab.com/ee/update/deprecations.html#dast-dast_devtools_api_timeout-will-have-a-lower-default-value)  \n* [依存関係プロキシトークンのスコープ強制](https://docs.gitlab.com/ee/update/deprecations.html#dependency-proxy-token-scope-enforcement)  \n* [Terraform CI/CD テンプレートを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#deprecate-terraform-cicd-templates)  \n* [ライセンスメタデータ形式 V1 を非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#deprecate-license-metadata-format-v1)  \n* [GraphQL APIのNamespaceProjectSortEnumにおけるSTORAGE列挙型を非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#deprecation-of-storage-enum-in-namespaceprojectsortenum-graphql-api)  \n* [GraphQL APIのProjectMonthlyUsageType におけるnameフィールドを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#deprecation-of-name-field-in-projectmonthlyusagetype-graphql-api)  \n* [GitLab NGINXチャートコントローラーイメージv1.3.1のフォールバックサポート](https://docs.gitlab.com/ee/update/deprecations.html#fallback-support-for-gitlab-nginx-chart-controller-image-v131)  \n* [Gitalyストレージを設定するためのgit_data_dirs](https://docs.gitlab.com/ee/update/deprecations.html#git_data_dirs-for-configuring-gitaly-storages)  \n* [従来のWeb IDEを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#legacy-web-ide-is-deprecated)  \n* [スキャン実行ポリシーごとに許可されるアクションの数を制限](https://docs.gitlab.com/ee/update/deprecations.html#limit-number-of-scan-execution-policy-actions-allowed-per-policy)  \n* [スキャン実行ポリシーにおけるscanアクションを制限](https://docs.gitlab.com/ee/update/deprecations.html#limited-scan-actions-in-a-scan-execution-policy)  \n* [Prometheusサブチャートのメジャーアップデート](https://docs.gitlab.com/ee/update/deprecations.html#major-update-of-the-prometheus-subchart)  \n* [GitLab.comでの脆弱性データ保持期間の新しい制限](https://docs.gitlab.com/ee/update/deprecations.html#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)  \n* [PostgreSQL 14および15はサポートされなくなります](https://docs.gitlab.com/ee/update/deprecations.html#postgresql-14-and-15-no-longer-supported)  \n* [Raspberry Pi 32 ビットパッケージを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#raspberry-pi-32-bit-packages-are-deprecated)  \n* [allowed_pull_policies に含まれないコンテナイメージのプルポリシーを拒否](https://docs.gitlab.com/ee/update/deprecations.html#reject-container-image-pull-policies-not-in-allowed_pull_policies)  \n* [duoProAssignedUsersCount GraphQL フィールドを削除](https://docs.gitlab.com/ee/update/deprecations.html#remove-duoproassigneduserscount-graphql-field)  \n* [GraphQL フィールドadd_on_purchaseをadd_on_purchasesに置き換え](https://docs.gitlab.com/ee/update/deprecations.html#replace-add_on_purchase-graphql-field-with-add_on_purchases)  \n* ネームスペース[のGraphQL フィールドadd_on_purchaseをadd_on_purchasesに置き換え](https://docs.gitlab.com/ee/update/deprecations.html#replace-namespace-add_on_purchase-graphql-field-with-add_on_purchases)  \n* [SUSE Linux Enterprise Server 15 SP2をサポート](https://docs.gitlab.com/ee/update/deprecations.html#support-for-suse-linux-enterprise-server-15-sp2)  \n* [ciJobTokenScopeRemoveProjectのGraphQL 引数directionを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#the-direction-graphql-argument-for-cijobtokenscoperemoveproject-is-deprecated)  \n* [APIでの注釈の機密性切り替え](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ワークフロー](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/ja-jp/free-trial/) でお試しいただけます。  \n\n\u003Cbr>\n\u003Cbr>\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\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/)",[738],"2025-05-19","2025-05-15",[721,763,701,110],{"slug":1433,"featured":92,"template":681},"gitlab-18-0-release","content:ja-jp:blog:gitlab-18-0-release.yml","Gitlab 18 0 Release","ja-jp/blog/gitlab-18-0-release.yml","ja-jp/blog/gitlab-18-0-release",{"_path":1439,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1440,"content":1446,"config":1451,"_id":1453,"_type":16,"title":1454,"_source":17,"_file":1455,"_stem":1456,"_extension":20},"/ja-jp/blog/gitlab-premium-with-duo",{"title":1441,"description":1442,"ogTitle":1441,"ogDescription":1442,"noIndex":6,"ogImage":1443,"ogUrl":1444,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1444,"schema":1445},"GitLab PremiumおよびUltimateのすべてのユーザーにAIの恩恵を","このたび、GitLab PremiumおよびUltimateで「GitLab Duo」の基本機能を追加料金なしでご利用いただけるようになりました。この機能により、ソフトウェア開発ライフサイクル全体をとおしてコードの作成・理解を支援するAI機能をご活用いただけます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660188/Blog/Hero%20Images/blog-premium-with-duo-cover-0756-fy26-v2-1800x945.png","https://about.gitlab.com/blog/gitlab-premium-with-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab PremiumおよびUltimateのすべてのユーザーにAIの恩恵を\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2025-05-15\",\n      }",{"title":1441,"description":1442,"authors":1447,"heroImage":1443,"date":1430,"body":1449,"category":701,"tags":1450,"updatedDate":1429},[1448],"David DeSanto, Chief Product Officer, GitLab","GitLab 18.0をリリースしました。このリリースでは、DevSecOpsの中核となるワークフロー、セキュリティとコンプライアンスの向上、そしてAI技術における革新的な進化と未来像が凝縮されています。**本リリースに合わせて、GitLab PremiumおよびUltimateで、GitLab Duoの基本的なAI機能を追加料金なしでご利用いただけるようになりました。** PremiumおよびUltimateのお客様は全員、サポートされているソースコードエディタやIDEから直接、GitLab Duoコード提案とGitLab Duo Chatをすぐにご利用いただけます。\n\n## すべての開発チームにAIを\n\n人工知能（AI）は今や、デベロッパーエクスペリエンスの中核をなしています。AIは、コードベースの分析、入力中リアルタイムでの提案の提供、プロジェクトのコンテキストに基づいた関数やメソッドの作成、繰り返しの作業の軽減、コードレビューの自動化など、さまざまな方法でコーディングを強化します。\n\nこの数年間、当社ではこうした生成AIやエージェント型AIの機能をGitLabプラットフォームに統合するために[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を開発してきました。GitLabが実施した[グローバルDevSecOps調査](https://about.gitlab.com/ja-jp/developer-survey/)によると、デベロッパーはコード作成以外のタスクに作業時間の79%を費やしています。コード作成はソフトウェアライフサイクルの始まりに過ぎないため、当社ではソフトウェア開発ライフサイクル全体をとおしてAIを統合する戦略を採用してきました。\n\n本リリースではこの戦略をさらに進め、デベロッパーのみなさまが追加料金なしでAIの恩恵を受けられるように、GitLab PremiumおよびUltimateプランにGitLab Duoの基本機能を追加しました。\n\nPremiumとUltimateでChatとコード提案をご利用いただけるようになったことで、すべてのソフトウェアエンジニアが、さまざまなツールやライセンス、そして管理体制を必要とせずに、IDE内でワークフローを高速化できます。既存のPremiumおよびUltimateのお客様は全員、GitLab 18.0へのアップグレード後にすぐにChatとコード提案をご利用いただけるようになります。また、この機能強化は新規のお客様には標準機能として提供されます。\n\n> **「GitLabはすでに、分散されたツールチェーンへの依存を排除し、これにより連携していないソリューションにかかるコストを削減し、ワークフローを効率化する上で重要な役割を果たしています。GitLab PremiumにGitLab Duoを追加することで、さらなる効率化とコスト削減が期待できます。日常的なコーディング作業にかかる時間が削減されるため、デベロッパーは真のビジネス価値を生み出す複雑な課題に、より多くの時間を費やせるようになります。」**\n>\n>- McKenzie Intelligence Services社、最高技術責任者、Andrei Nita氏\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Premium with Duo Core\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cbr>\u003C/br>\n\n本リリースから、PremiumおよびUltimateのお客様は、以下のAIネイティブ機能をご利用いただけます。\n\n#### GitLab Duoコード提案\n\n* コメントから完全な関数やコードブロックを生成 \n* 入力時にAIによる的確なコード補完を実行\n* 20以上のプログラミング言語をサポート\n* 主要なIDE各種で利用可能\n\nコード提案機能については、こちらの操作ガイドをご覧ください（ツアーを開始するには以下の画像をクリックしてください）。\n\n\u003Ca href=\"https://gitlab.navattic.com/code-suggestions\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175911/Blog/b5gdnls7jdyrpeyjby5j.png\" alt=\"GitLab Duo Code Suggestions cover image\">\u003C/a>\n\n詳細については、[コード提案のドキュメント](https://docs.gitlab.com/user/project/repository/code_suggestions/)でもご確認いただけます。\n\n#### GitLab Duo Chat\n\n* 馴染みのないコードを分かりやすく解説し、複雑な機能の理解をサポート\n* 既存のコードをリファクタリングして品質と保守性を向上\n* バグを早期に発見できるように、包括的なテストケースを自動作成\n* ワークフロー内でコードの問題を直接修正\n\n![ChatによるAPIエンドポイントの説明](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Duo_Chat_-_gif_-_API_endpoint_explanation__3_.gif)\n\n詳細については、[Duo Chatのドキュメント](https://docs.gitlab.com/user/gitlab_duo_chat/)をご覧ください。\n\n> **「私たちGitLabユーザーにとって、GitLab Duoのインテリジェントなコード提案は、デベロッパーの日常業務を支える資産となっています。Chat機能と組み合わせることで、即時にフィードバックを得て改善できるため、開発サイクルが加速し、より安全なコードベースが実現できています。ワークフローにシームレスに統合された強力な機能です。」**\n>\n>- Ignite by FORVIA HELLA社、最高技術責任者、Felix Kortmann氏\n\n## GitLab Premiumのお客様もGitLab Duo Enterpriseをご利用可能に\n\n多くのお客様からのご要望に応え、[GitLab Premium](https://about.gitlab.com/ja-jp/pricing/premium/)をご利用のお客様は、GitLab UltimateにアップグレードすることなくAI機能をフル搭載したGitLab Duo Enterpriseをご購入いただけるようになりました。Premiumのお客様は、ソフトウェア開発ライフサイクル全体にシームレスに統合された、充実したAI機能をご活用いただけます。\n\nDuo Enterprise のパワフルな機能ラインナップは次のとおりです。\n\n* [GitLab Duo根本原因分析](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases)：CI/CDパイプラインの失敗を迅速に解決して、パイプラインを健全に保ちます。  \n* [GitLab Duoコードレビュー](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code)：GitLab Duoをコードレビュアーとして活用することで、マージリクエストのレビューを高速化します。  \n* [高度なチャット](https://docs.gitlab.com/user/gitlab_duo_chat/)：会話の内容を要約し、コード変更を理解できるように支援するほか、複雑な設定のサポートを提供します。  \n* [GitLab Duo Self-Hosted](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/)：使用が許可されたAIモデルを社内でホスティングすることで、インターネット未接続（エアギャップ）環境やオフライン環境でもGitLab Duoを活用できます。\n\nGitLab Duo Enterpriseの提供と並行して、今GitLab Premiumの価値向上に向けた投資も強化しています。GitLab 17のリリース以降、以下を含む[100件を超える機能や改善を実装してきました](https://gitlab.com/gitlab-org/gitlab/-/releases)。\n\n* [CI/CDカタログ](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)：デベロッパーが既存のCI/CDコンポーネントや設定を共有、検索、再利用できる一覧ページ  \n* [アーティファクトレジストリ](https://docs.gitlab.com/user/packages/virtual_registry/)：デベロッパーにアーティファクトへの安全なアクセスを提供するとともに、CI/CDパイプラインとのシームレスな統合を実現  \n* [リモート開発](https://docs.gitlab.com/user/project/remote_development/)：デベロッパーがオンデマンドのクラウドベースの開発環境で作業できるように支援する機能\n\n> [GitLab Premiumの詳細はこちらをご覧ください。](https://about.gitlab.com/ja-jp/pricing/premium/)\n\n## GitLab Duo：組織の現在のステージに対応するAI\n\nGitLabは、ProからEnterpriseまで多彩なDuoサービスをご用意しており、お客様のAI導入段階に最適なソリューションをお選びいただけます。チームのAI活用レベルが高まるにつれて、より多くの機能を活用して、安全なソフトウェアをより迅速にビルド、テスト、デプロイすることができます。\n\n![GitLab Duoプランの主な機能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Screenshot_2025-05-14_at_8.50.34_AM.png)\n\n## GitLab UltimateおよびPremiumの既存のお客様がGitLab Duoを使い始めるには\n\nGitLab 18.0以降、UltimateとPremiumの既存のお客様は、コード提案とChatがデフォルトではオフになっていますが、以下の手順で簡単に有効にできます。\n\nGitLab PremiumおよびUltimateでGitLab Duoを利用する手順：\n\n1. GitLab PremiumまたはUltimateを利用中であることを確認します。いずれも導入していない場合は、無料トライアルを開始できます。  \n2. 組織の設定で、GitLab Duoを有効にします。  \n3. ローカルIDEを使用している場合は、対応するGitLab[エディタ拡張機能](https://docs.gitlab.com/editor_extensions/#available-extensions)をインストールします。  \n4. サポートされているローカルIDEまたはGitLab Web IDEで、コード提案やChatの利用を開始します。\n\n**注**：新規ユーザーまたはトライアル中の場合、GitLabのAI機能が自動的に有効になります。\n\n## AIネイティブ開発にはDevSecOpsプラットフォームが不可欠\n\n今やAIによって、デベロッパーエクスペリエンスは根本から再構築されつつあります。これからの組織では、ソフトウェア開発に携わる人員が単に増えるだけではなく、AIによって本番環境向けコードの量も増えることになります。**そのため、GitLabの存在価値がはかつてないほど高まっています。** \n\n当社では、この新時代に向け、GitLab Duoを備えたGitLab PremiumおよびUltimateを構築しました。これによりチームは、あらゆるコードを安全に一元管理できる環境を構築できます。組織全体でAIがコードを生成する環境下で、GitLabが司令塔としての役割を担います。セキュリティスキャンやコンプライアンスチェック、パイプライン管理のために別々のツールを導入する必要はありません。組織の成長に合わせてスケールする単一の統合プラットフォームで、各コードが本番環境へのリリース前に基準を満たしているかを確認できます。AIによって開発速度が加速する中、GitLabを使えば全工程を通じて一貫性のあるコントロール、セキュリティ、品質を保てます。\n\n> チームの生産性を向上させるGitLab Duoの活用方法については、[GitLab Premiumのページをご覧ください](https://about.gitlab.com/ja-jp/pricing/premium/)。すでにGitLabをご利用の場合は、GitLab担当者にご連絡いただき、デモンストレーションをご予約ください。また、2025年6月24日に[GitLab 18バーチャルリリースイベント](https://about.gitlab.com/eighteen/)を開催します。AIとともに進化するソフトウェア開発の未来像を探る機会となりますので、ぜひご参加ください。\n\n*本ブログは、[Unlocking AI for every GitLab Premium and Ultimate customer](https://about.gitlab.com/blog/gitlab-premium-with-duo/)の抄訳です。内容に相違がある場合は、原文が優先されます。*",[721,904,700,678,701],{"slug":1452,"featured":92,"template":681},"gitlab-premium-with-duo","content:ja-jp:blog:gitlab-premium-with-duo.yml","Gitlab Premium With Duo","ja-jp/blog/gitlab-premium-with-duo.yml","ja-jp/blog/gitlab-premium-with-duo",{"_path":1458,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1459,"content":1465,"config":1470,"_id":1472,"_type":16,"title":1473,"_source":17,"_file":1474,"_stem":1475,"_extension":20},"/ja-jp/blog/monday-merge-2025-may-9",{"title":1460,"description":1461,"ogTitle":1460,"ogDescription":1461,"noIndex":6,"ogImage":1462,"ogUrl":1463,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1463,"schema":1464},"🌞 5月のMonday Merge：RSAでの発見、AIアシスタント、 さらに広がるDevSecOpsの世界！","5月のMonday Mergeでは、ARSACでの学びから、GitLab Duo with Amazon Q の一般提供開始、GitLab 17.11、そしてシーメンス社の事例をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662427/Blog/Hero%20Images/image1.png","https://about.gitlab.com/blog/monday-merge-2025-may-9","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"🌞 5月のMonday Merge：RSAでの発見、AIアシスタント、 さらに広がるDevSecOpsの世界！\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-05-09\",\n      }",{"title":1460,"description":1461,"authors":1466,"heroImage":1462,"date":1467,"body":1468,"category":700,"tags":1469},[738],"2025-05-09","GitLabコミュニティのみなさん、こんにちは！\n\n5月がやってきて、勢いも加速中！RSACでの学びから、GitLab Duo with Amazon Q の一般提供開始、GitLab 17.11、そしてシーメンス社の素晴らしいカスタマーストーリーまで、今月のMonday Mergeはイノベーションとインサイト、インスピレーションが満載です。\n\nさっそく見ていきましょう！\n\n## 🗞️ RSAカンファレンス2025 特別レポート\n\n![monday merge may fatima](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687422/Blog/Content%20Images/image8.png)\n\n先週のサンフランシスコは、霧とコーヒーだけでなく、サイバーセキュリティの熱気にも包まれていました。RSAカンファレンス2025では業界のトップが集結し、GitLabもブース\\#4324で参加しました。イベントでは、AIアシスタント、組み込み型セキュリティ、透明性の高いDevSecOpsの実践などを通して、「協業こそがセキュリティの鍵」という明確なメッセージが示されていました。\n\n## 🤝 GitLab Duo with Amazon Q：ついに一般提供開始、とっても便利です！\n![monday merge may gitlab duo with amazon q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687422/Blog/Content%20Images/image3.png)\n\n新しいAIコンビにご注目を！GitLab Duo with Amazon Qが一般提供となり、AWSでの開発のあり方が大きく変わります。コードを書くとき、マージリクエストのレビュー時、そして古いJavaの更新（リファクタリング戦士たち、ありがとう！）も、AIアシスタントが重荷を引き受けます。\n\nGitLabに組み込まれたAmazon Qを使えば、`/q dev`や`/q transform`のような直感的なプロンプトで、課題から実装までを数分で完了できます。Volkswagen Digital Solutions社やAvaility社のような早期導入企業は、すでにワークフローの高速化や複雑な環境のモダナイゼーションに活用中です。\n\n🔗 [GitLab Duo with Amazon Qの詳細を見る](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n\n🔗 [アイデアを数分でコードに変える方法（英語）](https://about.gitlab.com/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes/)\n\n## 🚀 GitLab 17.11：コンプライアンス、カスタマイズ、さらなるAIの進化\n![monday merge may GitLab release 17.11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687423/Blog/Content%20Images/image2.png)\n\n今月のリリースでは60以上の機能改善があり、セキュリティ管理の強化、柔軟性の向上、AIを使った精密なワークフローの高速化を実現。規制のある環境での運用から、カスタムプロセスの拡張、AIアシスタントの活用まで、GitLab 17.11は必要な管理機能、ダッシュボード、統合機能を提供します。\n\n### ✨ 主なハイライト\n\n* **カスタムコンプライアンスフレームワーク**：要件定義、50以上のコントロールとのマッピング、詳細なレポートの生成\n\n* **Duo Self-Hosted新機能（ベータ）**：根本原因分析、AIによる要約、脆弱性インサイトなど\n\n* **Eclipseプラグイン（ベータ）**：DuoがEclipseに対応し、さらに統合されたコーディング体験が可能に\n\n* **パッケージとタグの保護**：重要な資産を万全に保護\n\n* **カスタムフィールドとイシュー画面の改善**：構造化されたメタデータの追加、タスクの整理、管理効率向上\n\n* **CI/CDパイプライン入力**：動的なコンテンツを柔軟かつ安全に注入\n\n🎉 さらに、GitLabコミュニティによる284件の貢献に感謝します！Mavenパッケージ保護やDuo、CI/CD改善など、世界中のコントリビューターの創造力と献身が反映されています。みなさんの協力がなくては実現できませんでした 🙌\n\n🔗 [17.11のリリースノートを見る](https://about.gitlab.com/ja-jp/blog/gitlab-17-11-release/)\n\n## ☁️ AWSサミットで直接お会いしましょう！\n\n![monday merge may aws summit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687423/Blog/Content%20Images/image4.png)\nGitLabはAWSサミットのグローバルスポンサーとして、各地にDevSecOpsを届けます。  \nぜひブースにお立ち寄りください：\n\n* ライトニングトークやハンズオンデモ  \n* GitLabのAI・セキュリティ専門家との対話  \n* AWS上での開発をより高速・安全に進めるヒント\n\n📍[AWS Summit Japan 2025](https://aws.amazon.com/jp/summits/japan/)（2025年6月25日、26日）、[その他開催地をみる](https://about.gitlab.com/events/aws-summits/)\n\n## 🏗️ 事例のご紹介：シーメンス社がGitLabで協業をスケール\n![monday merge may siemens 事例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687423/Blog/Content%20Images/image6.png)\n\n世界有数のエンジニアリング企業が、開発者の協業の在り方を見直すとどうなるか？ それを体現しているのが、シーメンス社の驚くべきDevSecOpsストーリーです。\n\n2014年、組み込みLinux開発において、より良い協業方法を模索していた小さな先進的チームから全ては始まりました。今では、シーメンス社の75,000人以上の開発者がGitLabを中心となるプラットフォームとして利用し、1日あたり20万件以上のビルドを実施。GitLab導入は単なる技術的な実装にとどまらず、チームをつなげ、インナーソース文化を育み、企業全体のイノベーションを促進しました。\n\nさらに、シーメンス社はGitLabのユーザーであると同時に構築者でもあります。300以上のマージリクエスト、12件のMVP受賞を誇り、プラットフォームの進化にも貢献しながら、自社のDevOps力も強化しています。\n\n現在はAIアシスタントを自社モデルで活用し、マージリクエストを強化する独自の「CodeAI」ボットを導入。AIを“代替”ではなく“創造性と協業の鍵”として未来に備えています。\n\n🔗 [シーメンス社のストーリー全文を読む（ドイツ語）](https://www.computerwoche.de/article/3963808/eine-neue-ara-der-entwicklerzusammenarbeit.html)\n\n## 📚 おすすめ読みもの：AI、リスク、そしてGitLabリーダーたちの見解\n\n![08 Header Images April What We’re Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/08_LinkedIn_Header_Images_April_What_We_re_Reading.png)\n\n* **AIアシスタント：開発者の可能性をスケールさせる**  \nEmilio Salvadorが語る、「未来のソフトウェア開発は一人ではできない」理由。専任のAIアシスタントは新しいチームメイトと語ります。\n\n🔗 [続きを読む（英語）](https://about.gitlab.com/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)\n\n* **リスクインテリジェンスをソフトウェアサプライチェーンに組み込む**  \n[Lee Faus](https://www.linkedin.com/in/leefaus/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)が、リスク対策を単なる後付けではなく、パイプライン全体に組み込む方法を解説します。\n\n🔗 [続きを読む（英語）](https://about.gitlab.com/the-source/security/embedding-risk-intelligence-into-your-software-supply-chain/)\n\n* **セキュリティ対策を公開するメリットとデメリット**  \n[Josh Lemos](https://www.linkedin.com/in/joshlemos/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)が[Tines](https://www.linkedin.com/company/tines-io/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)で、透明性のあるセキュリティ、AIの脅威、コーヒーチャットの重要性について語ります。\n\n🔗 [続きを読む（英語）](https://www.tines.com/blog/gitlab-josh-lemos/)\n\n* **エンジニアリングチームにAIを導入する3つの方法**  \n[Sabrina Farmer](https://www.linkedin.com/in/sabrinafarmer/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)が、AIをチームの味方にするステップバイステップガイドを紹介します。\n\n🔗 [続きを読む（英語）](https://www.forbes.com/councils/forbestechcouncil/2025/04/25/three-ways-to-operationalize-ai-for-engineering-teams/)\n\n* **精密にGo-To-Market戦略を進めるには**  \n[Brian Robins](https://www.linkedin.com/in/brian-robins-5254864/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)がGitLabの、市場戦略、「Ultimate」が成長を牽引する理由、そして財務の“人間らしさ”について語ります。\n\n🔗 [続きを読む（英語）](https://cfothoughtleader.com/cfopodcasts/1083-navigating-the-go-to-market-roadmap-with-precision-brian-robins-cfo-gitlab/)\n\n## 💬 本日のインスピレーション\n\n> 「セキュリティとは、新たな技術的フロンティアへ安全に渡るための架け橋である。」\u003Cbr>– Magda Chelly\n\nAIアシスタント、コンプライアンス管理、コラボレーションのワークフローなど、新たなフロンティアへ進んでいく中で、セキュリティは単なるチェックポイントではなく、イノベーションを可能にする土台だということを忘れずに。架け橋を丁寧に築き、自信を持って渡り、素晴らしいものを創り出していきましょう。\n\nそれでは、次回まで、好奇心を持ち続け、つながりを大切にし、Happy Merging！\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | GitLab Developer Advocate\n![SignOffBanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/SignOffBanner.png)\n\nP.S. DevSecOpsの最新情報を逃さないように、ぜひ来月も読んでくださいね！\n",[763,702,721,701,722,700,280,235,920,764,675,270],{"slug":1471,"featured":92,"template":681},"monday-merge-2025-may-9","content:ja-jp:blog:monday-merge-2025-may-9.yml","Monday Merge 2025 May 9","ja-jp/blog/monday-merge-2025-may-9.yml","ja-jp/blog/monday-merge-2025-may-9",{"_path":1477,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1478,"content":1484,"config":1491,"_id":1493,"_type":16,"title":1494,"_source":17,"_file":1495,"_stem":1496,"_extension":20},"/ja-jp/blog/agentic-ai-guides-and-resources",{"ogTitle":1479,"schema":1480,"ogImage":1481,"ogDescription":1482,"ogSiteName":1223,"noIndex":6,"ogType":1244,"ogUrl":1483,"title":1479,"canonicalUrls":1483,"description":1482},"エージェント型AIに関するガイドとリソース","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"自律型AIに関するガイドとリソース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-05-07\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658912/Blog/Hero%20Images/blog-image-template-1800x945__20_.png","エージェント型AIの概要・仕組みからDevSecOps環境向上の理由、導入ベストプラクティスまで解説します。","https://about.gitlab.com/blog/agentic-ai-guides-and-resources",{"heroImage":1481,"body":1485,"authors":1486,"updatedDate":1487,"date":1488,"title":1479,"tags":1489,"description":1490,"category":787},"## エージェント型AIの定義\n\nエージェント型AIは、高度な言語モデルや自然言語処理を活用して、自律的に行動できる人工知能です。従来の生成AIツールが常に人間からの指示を必要とするのに対し、エージェント型AIはリクエストを理解して意思決定を行い、目標達成に向けて複数の段階から成る計画を実行できます。複雑なタスクを管理可能な手順に分解し、課題に直面した際には適応学習を通じてアプローチを柔軟に変えることができます。\n\n[エージェント型AIの詳細はこちら](https://about.gitlab.com/ja-jp/topics/agentic-ai/)\n\n## エージェントAIに関するインサイト\n\n* [GitLab Duo Agent Platform パブリックベータ版：次世代AI統合機能とその他](https://about.gitlab.com/the-source/ai/emerging-agentic-ai-trends-reshaping-software-development/)：デベロッパーとAIエージェント間の非同期コラボレーションを実現するために設計されたDevSecOps統合プラットフォームをご紹介します。\n* [GitLab Duo Agent Platform：次世代DevSecOpsプラットフォームの可能性](https://about.gitlab.com/ja-jp/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)：GitLab Duo Agent Platformは、人間とAIエージェントによる共同作業を実現するDevSecOps統合プラットフォームです。ソフトウェア開発の各段階でエージェント型AIを活用し、効果的な連携を促進します。\n* [感覚的コーディングからエージェント型AIへ：技術リーダー向けロードマップ](https://about.gitlab.com/ja-jp/the-source/ai/ai-trends-for-2025-agentic-ai-self-hosted-models-and-more/)：感覚的コーディングとエージェント型AIを開発プロセスに取り入れ、コード品質とセキュリティを確保しながら生産性を向上させる実践的な方法を紹介します。\n* [エージェント型AIが切り拓くソフトウェア開発の新潮流](https://about.gitlab.com/the-source/ai/how-agentic-ai-unlocks-platform-engineering-potential/)：エージェント型AIによって、従来の個人作業中心のコーディングが、セキュリティを維持しながら生産性を飛躍的に高めるスマートなワークフローへと進化する過程を探ります。\n* [エージェント型AIで開発者の力を最大限に引き出す](https://about.gitlab.com/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)：エージェント型AIがソフトウェア開発を変革する様子を解説します。コード補完の枠を超えて、複雑なタスクに自ら取り組むAIパートナーの実現について探ります。\n* [エージェント型AI、オンプレミス型モデルなど：2025年のAI動向](https://about.gitlab.com/the-source/ai/ai-trends-for-2025-agentic-ai-self-hosted-models-and-more/)：ソフトウェア開発分野における重要なAI動向をご紹介。オンプレミス環境でのモデル運用から、学習・適応機能を持つAIエージェントまで、最新トレンドを網羅します。\n* [エージェント型AIでプラットフォームエンジニアリングを飛躍させる](https://about.gitlab.com/the-source/ai/how-agentic-ai-unlocks-platform-engineering-potential/)：複雑なワークフローの自動化と標準化の拡張により、エージェント型AIがプラットフォームエンジニアリングの可能性をどのように広げるかを解説します。\n\n## エージェント型AIエコシステム\n\n* [AI駆動型コード解析：コードセキュリティの新領域](https://about.gitlab.com/topics/agentic-ai/ai-code-analysis/)\n* [DevOps自動化とAIエージェント](https://about.gitlab.com/topics/agentic-ai/devops-automation-ai-agents/)\n* [AI強化型ソフトウェア開発：DevOps向けエージェント型AI](https://about.gitlab.com/topics/agentic-ai/ai-augmented-software-development/)\n\n## エージェント型AIを導入するためのベストプラクティス\n\n* [AIエージェント向けに効果的なガードレールを実装する](https://about.gitlab.com/the-source/ai/implementing-effective-guardrails-for-ai-agents/)：コンプライアンス制御からインフラ保護、ユーザーアクセス管理まで、DevSecOps環境においてAIエージェント向けに実装すべきセキュリティガードレールをご紹介します。\n\n## GitLabが提供するエージェント型AI機能\n\n### GitLab Duo with Amazon Q\n\n* [GitLab Duo with Amazon Q：AWS向けに最適化されたエージェント型AIの一般提供を開始](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)：AIを搭載した包括的なDevSecOpsプラットフォームと業界最高水準のクラウドコンピューティング機能の組み合わせにより、開発サイクルの高速化、自動化の推進、そしてコード品質の向上を可能にします。\n* [DevSecOps + エージェント型AI：AWS上のGitLab Self-Managed Ultimateで利用可能に](https://about.gitlab.com/blog/devsecops-agentic-ai-now-on-gitlab-self-managed-ultimate-on-aws/)：AWS上のGitLab Self-Managed Ultimateインスタンスで、DevSecOps向けに強化されたAI搭載エージェントを使い始めましょう。GitLab DuoとAmazon Qの両方のメリットを得られます。\n* [GitLab Duo with Amazon Qパートナーページ](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)\n\n以下の動画で、GitLab Duo with Amazon Qを実際に使用する様子をご覧いただけます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Technical Demo: GitLab Duo with Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n#### ガイド付きツアー\n\n以下の画像をクリックすると、GitLab Duo with Amazon Qのツアーが開始されます。\n\n[![GitLab Duo with Amazon Qのインタラクティブなツアー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673568/Blog/Content%20Images/Screenshot_2025-05-07_at_7.24.45_AM.png)](https://gitlab.navattic.com/duo-with-q)\n\n#### GitLab Duo with Amazon Qのチュートリアル\n\n* [AI駆動のテスト生成でアプリケーション品質を向上](https://about.gitlab.com/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes/)：GitLab Duo with Amazon Q が包括的な単体テストを自動生成してQAプロセスをどのように改善するかをご紹介します。\n* [GitLab Duo + Amazon Q：アイデアを数分でコードに変換](https://about.gitlab.com/ja-jp/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes/)：新しいGitLab Duo with Amazon Qの統合機能がイシューの説明を分析し、実装可能なコードソリューションを自動生成して、開発ワークフローを加速します。\n* [GitLab Duo and Amazon Qでコードレビューを加速](https://about.gitlab.com/ja-jp/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q/)：AI駆動のエージェントを使用してマージリクエストを自動分析し、バグ、可読性、コーディング標準について包括的なフィードバックを提供し、コードレビューを最適化します。\n* [コードレビューを高速化：AIにフィードバックの実装を任せる](https://about.gitlab.com/ja-jp/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation/)： GitLab Duo with Amazon QがAIを通じてコードレビューフィードバックの実装をどのように自動化し、時間のかかる手動プロセスを効率的なワークフローに変革するかをご紹介します。\n\n[](https://about.gitlab.com/ja-jp/gitlab-duo/)\n\n### GitLab Duo Agent Platform\n\n* [GitLab Duo Chatがエージェント型AIで生まれ変わる](https://about.gitlab.com/ja-jp/blog/gitlab-duo-chat-gets-agentic-ai-makeover/)：現在実験的リリース段階にある新しいDuo Chat機能は、デベロッパーのプロジェクトへのオンボーディング、割り当ての理解、変更の実装などをサポートします。GitLab Duo Agent Platformの実際の動作をご覧ください。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1095679084?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agent Platform Demo Clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n#### GitLab Agent Platform（およびDuo Workflow）のチュートリアルとユースケース\n\n* [GitLab Duo Agent Platformで学習を加速する](https://about.gitlab.com/blog/accelerate-learning-with-gitlab-duo-agent-platform/)：エージェント型AIがわずか数時間ではなく数分で包括的なgRPCドキュメントの生成をどのように支援したかを学びましょう。\n* [GitLabでGoogle Cloudへ高速かつ安全なAIエージェントをデプロイする](https://about.gitlab.com/ja-jp/blog/fast-and-secure-ai-agent-deployment-to-google-cloud-with-gitlab/)\n* [GitLab Duo Workflowを使ってJavaScriptコードをTypeScriptにリファクタリングする](https://about.gitlab.com/blog/refactoring-javascript-to-typescript-with-gitlab-duo-workflow/)\n* [面倒なコーディング作業をGitLab Duo Workflowで自動化](https://about.gitlab.com/blog/automate-tedious-coding-tasks-with-gitlab-duo-workflow/)：エージェント型AIを導入すると、これまで反復作業に費やしていた時間が削減されるため、革新的なソリューションの開発や次の重要な製品のリリースに注力できるようになります。\n* [GitLab Duo Workflowを使用してアプリケーションの品質保証を強化](https://about.gitlab.com/ja-jp/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance/)：エージェント型AIを使用してJavaアプリケーションに単体テストを追加する方法をステップ別にご説明します（チュートリアル動画あり）。\n* [GitLab Duo Workflowを使って複雑な課題を解決](https://about.gitlab.com/blog/solving-complex-challenges-with-gitlab-duo-workflow/)：GitLabカスタマーサクセスマネジメントチームが、パッケージレジストリにおけるHelmチャート制限への対処など、実際の問題解決においてどのようにエージェント型AIを活用しているかをご紹介します。\n* [Web UIでGitLab Duo Agentic Chatを始める](https://about.gitlab.com/blog/get-started-with-gitlab-duo-agentic-chat-in-the-web-ui/)：複雑な問題を分解し、複数のソースにわたって操作を実行することでタスクを自動化する新しいGitLab Duo AI機能について学びます。\n* [デベロッパーのより高い効率を実現するGitLab Duo Agentic Chatのカスタムルール](https://about.gitlab.com/blog/custom-rules-duo-agentic-chat-deep-dive/)：AIがコードベースを理解し、規約に従い、最小限のレビューサイクルで本番環境対応のコードを生成する方法をご紹介します。\n\n## **GitLab Universityでさらに詳しく学ぶ**\n\n* [GitLab Duo入門コース](https://university.gitlab.com/pages/ai)\n* [GitLab Duo Enterpriseを体系的に学ぶコース](https://university.gitlab.com/learning-paths/gitlab-duo-enterprise-learning-path)\n\n## その他のAI関連リソース\n\n* [2024 Global DevSecOps Survey: Navigating AI maturity in DevSecOps](https://about.gitlab.com/ja-jp/developer-survey/2024/ai/)\n* [DevOpsにおけるAIの役割](https://about.gitlab.com/ja-jp/topics/devops/the-role-of-ai-in-devops/)\n* [GitLabによるAIと機械学習関連の最新記事\n  ](https://about.gitlab.com/ja-jp/blog/categories/ai-ml/)\n* [GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)",[696],"2025-09-01","2025-05-07",[721,904,676],"概要から仕組み、DevSecOps環境をレベルアップする理由、導入時のベストプラクティスまで、エージェント型AIについて押さえておくべきポイントをご紹介します。",{"slug":1492,"featured":92,"template":681},"agentic-ai-guides-and-resources","content:ja-jp:blog:agentic-ai-guides-and-resources.yml","Agentic Ai Guides And Resources","ja-jp/blog/agentic-ai-guides-and-resources.yml","ja-jp/blog/agentic-ai-guides-and-resources",{"_path":1498,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1499,"content":1505,"config":1511,"_id":1513,"_type":16,"title":1514,"_source":17,"_file":1515,"_stem":1516,"_extension":20},"/ja-jp/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":1500,"description":1501,"ogTitle":1500,"ogDescription":1501,"noIndex":6,"ogImage":1502,"ogUrl":1503,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1503,"schema":1504},"GitLabのカスタムコンプライアンスフレームワークをDevSecOps環境で活用する方法","新しいフレームワークと、50個を超えるすぐに使えるコントロールを活用することで、これまでひとつずつチェックしていた規制要件を、統合された自動化ワークフローの一部へと変換する方法をご紹介します。","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","https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabのカスタムコンプライアンスフレームワークをDevSecOps環境で活用する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-30\",\n      }",{"title":1500,"description":1501,"authors":1506,"heroImage":1502,"date":1508,"body":1509,"category":722,"tags":1510},[1507],"Fernando Diaz","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/)",[722,676,904,678,701],{"slug":1512,"featured":92,"template":681},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","content:ja-jp:blog:how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","How To Use Gitlabs Custom Compliance Frameworks In Your Devsecops","ja-jp/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","ja-jp/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"_path":1518,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1519,"content":1525,"config":1530,"_id":1532,"_type":16,"title":1533,"_source":17,"_file":1534,"_stem":1535,"_extension":20},"/ja-jp/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes",{"title":1520,"description":1521,"ogTitle":1520,"ogDescription":1521,"noIndex":6,"ogImage":1522,"ogUrl":1523,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1523,"schema":1524},"GitLab Duo + Amazon Q：アイデアを数分でコードに変換","新しいGitLab Duo with Amazon Qのインテグレーションは、イシューの説明を分析して、動作するコードソリューションを自動で生成することで、開発ワークフローを加速します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097127/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750097126673.png","https://about.gitlab.com/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo + Amazon Q：アイデアを数分でコードに変換\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-04-28\",\n      }",{"title":1520,"description":1521,"authors":1526,"heroImage":1522,"date":1527,"body":1528,"category":787,"tags":1529},[783],"2025-04-28","複雑なイシューを動作するコードに変えるのに、何日も、あるいは何週間もかかった経験はありませんか？きっと誰もが一度は経験していることです。しっかりしたアイデアと明確な要件をもとに始めたはずなのに、そこからデプロイ可能なコードにたどり着くまでの道のりは、イライラするほど長く感じることがあります。実装の細かい部分に足を取られ、生産性が落ちてしまい、本来もっとスムーズに進むはずのプロジェクトが、なかなか進まなくなってしまうのです。\n\nここで力を発揮するのが、[自律型AI](https://about.gitlab.com/ja-jp/topics/agentic-ai/)機能です。 [GitLab Duo with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)は、AIを搭載した包括的なDevSecOpsプラットフォームと、クラウドコンピューティングにおける豊富な機能を組み合わせたもので、アプリケーション開発のプロセスを、慣れ親しんだGitLabのワークフロー内で大幅に加速できるよう設計されています。この強力なインテグレーションはアイデア段階からデプロイまでの流れを効率化し、イシューの説明だけをもとに実装案を提案します。これまで数日かかっていた作業が、数分で完了するようになります。\n\n## イシューが動作するコードへ変わる仕組み\n\nこの自律型AI機能が実際にどう動くのか、流れを見てみましょう。あなたはデベロッパーとして、住宅ローン計算機アプリを作成するタスクを任されたとします。GitLab Duo with Amazon Qを使用して、以下の手順で作業を進めます。\n\n1. **詳細な要件を記載したイシューを作成する：**まず、通常の[GitLabイシュー](https://docs.gitlab.com/user/project/issues/)を作成します。説明には、サービスが満たす必要がある要件をできるだけ詳細に記載します。これがソリューションの設計図となります。\n\n2. **クイックアクションでAmazon Qを呼び出す：** イシューを作成したら、コメント欄に「/q dev」というクイックアクションを追加するだけで、Amazon Qを呼び出すことができます。ここからがマジックの始まりです。\n\n3. **AIが実装を生成する：**GitLab Duo with Amazon Qは、作成したイシューの説明文とソースコードのコンテキストを分析し、指定されたすべての要件を満たすコードを自律的に生成します。 さらに、生成されたコードはマージリクエストとして自動的にコミットされ、すぐにレビュー可能な状態になります。\n\n![GitLab Duo  with Amazon Qのアクティビティポップアップのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097156/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097156018.png)\n\n4. **生成されたアプリケーションをレビューする：**マージリクエストに移動して、生成されたコードをレビューします。 すべての要件が満たされていることを確認し、必要に応じて調整を行います。\n\n5. **提案されたアプリケーションをテストする：**最後に、アプリケーションが正常に動作することを確認します。 最小限の労力で、元の要件を実装した、動作するコードが完成します。\n\n## 開発プロセスを変革\n\nGitLab Duo with Amazon Qは、インテリジェントな自動化によって複雑なデベロッパータスクにかかる時間を大幅に短縮し、このプロセス全体を根本から変革します。自律型AIアプローチを活用することで、アイデア段階からデプロイまでのプロセスを加速し、開発チームはより戦略的な業務に集中できるようになります。\n\nGitLab DuoとAmazon Qを使用すれば、手動でコードを書く負担を減らしながら、より迅速かつ効率的にソフトウェアを開発できます。このインテグレーションによって、以下のようなメリットが得られます。\n\n* 要件に基づく自動実装で、**貴重な開発時間を節約**\n* どのプロジェクトでも、コード生成の**一貫性を維持** \n* 要件を動作するコードに変換する際の**認知負荷を軽減**\n* 実装上のボトルネックを排除し、**リリースサイクルを加速**\n* ボイラープレートコードの記述ではなく、レビューや最適化に**専門知識を活用**\n\nGitLab Duo with Amazon Qの動作を実際にご覧になりますか？デモ動画で、開発ワークフローを変革する方法をご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jxxzNst3jpo?si=j_LQdZhUnwqoQEst\" title=\"GitLab Duo with Amazon Q demo video for dev workflow\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n> GitLab Duo with Amazon Qの詳細については、[お近くで開催されるAWSサミット](https://about.gitlab.com/ja-jp/events/aws-summits/)にご参加いただくか、[GitLab担当者にお問い合わせ](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)ください。\n\n## GitLab Duo with Amazon Q関連リソース\n\n- [GitLab Duo with Amazon Q（AWS向けに最適化された自律型AI）の一般提供を開始](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n- [GitLabとAWSのパートナーページ](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)\n- [GitLab Duo with Amazon Qに関するドキュメント](https://docs.gitlab.com/user/duo_amazon_q/)",[721,920,676,904,701,235],{"slug":1531,"featured":92,"template":681},"gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes","content:ja-jp:blog:gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes.yml","Gitlab Duo Amazon Q Transform Ideas Into Code In Minutes","ja-jp/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes.yml","ja-jp/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes",{"_path":1537,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1538,"content":1544,"config":1549,"_id":1551,"_type":16,"title":1552,"_source":17,"_file":1553,"_stem":1554,"_extension":20},"/ja-jp/blog/what-is-kubernetes",{"title":1539,"description":1540,"ogTitle":1539,"ogDescription":1540,"noIndex":6,"ogImage":1541,"ogUrl":1542,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1542,"schema":1543},"Kubernetes（K8s）とは？その仕組みから利点、使い方まで","Kubernetes（K8s）とは？Kubernetes の読み方から覚えておきたい用語、仕組みやその利点について学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687485/Blog/Hero%20Images/kubernetes.jpg","https://about.gitlab.com/blog/what-is-kubernetes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes（K8s）とは？その仕組みから利点、使い方まで\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-28\",\n      }",{"title":1539,"description":1540,"authors":1545,"heroImage":1541,"date":1527,"body":1546,"category":672,"tags":1547},[738,696],"## 目次\n\n1. Kubernetesとは？その読み方と用途\n2. Kubernetes（K8s）の基本用語解説\n  - コンテナ、Pod、Node、クラスター\n  - Dockerとの違い\n3. Kubernetesの主な特徴\n  - デプロイの自動化\n  - ハイブリッド / マルチクラウドに対応\n  - 拡張性とプラグインアーキテクチャ\n  - ローリングアップデートとロールバック\n  - 柔軟なスケーラビリティ\n  - リリース後のアプリケーション監視\n4. Kubernetesの利点とは\n  - 生産性の向上\n  - 自己修復機能により障害に耐性\n  - 高い可用性を担保\n  - オンプレミスでも、クラウドでも運用可能\n  - 大量のコンテナを一括管理\n  - DevSecOpsとの親和性が高い\n  - クラウドネイティブなワークロードを安全に保つ\n5. GitLabでKubernetesを統合する\n6. Kubernetes（K8s）のよくある質問\n  - KubernetesとDockerの違いは何ですか？\n  - Kubernetesで何ができますか？\n  - Kubernetesコンテナとは何ですか？\n  - Kubernetesの読み方は？\n\n## Kubernetesとは？その読み方と用途\n\nKubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と発音します。ギリシャ語のκυβερνήτηςに由来し、「統治者」や「パイロット」といった意味を持ちます。また、K8sと表記されることもあります。  \n\nKubernetesは、一言で表せばソフトウェア開発においてコンテナを操作・管理するもので、コンテナオーケストレーションの役割を果たすオープンソースソフトウェアとして開発されました。Kubernetesは、クラウドネイティブのプログラムの開発に使用します。これを使用することで[マイクロサービス](https://about.gitlab.com/ja-jp/topics/microservices/)アーキテクチャが可能になり、プログラムの開発が高速化できます。  \nでは、Kubernetesについて、もう少し掘り下げて見ていきましょう。\n\n## Kubernetes（K8s）の基本用語解説\n\n### コンテナ、Pod、Node、クラスター\n\nKubernetesは、コンテナをオーケストレーションするためのツールです。オーケストレーションとは、複数のコンピュータシステムやアプリケーション、サービスなどを調整して管理し、頻繁に繰り返される大規模なワークフローやプロセスを実行できるようにすることを指します。では、コンテナとは何でしょう。ソフトウェア開発におけるコンテナ化とは、ソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することを意味します。コンテナは、完全に機能するポータブルなコンピューティング環境です。また、このコンテナを複数まとめたものがPod、PodをまとめたものがNode、Nodeをまとめたものがクラスタと呼ばれます（以下の図を参照）。\n\n![kubernetesとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687494/Blog/Content%20Images/kubernetes-diagram.svg)\n\n*Kubernetesにおけるコンテナとクラスタの関係を示した図*\n### Dockerとの違い\n\nKuberunetesはコンテナオーケストレーションツールですが、Dockerはコンテナ化ツールの1つです。Dockerはアプリケーションのコンテナ化を行なうとき使用するプラットフォームです。仮想マシンよりも軽量で高速であることや、環境構築が簡単なことから、コンテナ化の主流ツールになっています。\n\n## Kubernetesの主な特徴\n\nKubernetesは、前述したようにコンテナを管理するコンテナオーケストレーションツールで、代表的な機能としては次のようなものが挙げられます。\n\n### デプロイの自動化\n\nKubernetesは、アプリケーションのデプロイ時に、新しいコンテナの作成や既存コンテナの削除を自動で実施します。また、新しく作成したコンテナにも自動でリソースを適用します。\n\n### ハイブリッド / マルチクラウドに対応\n\nクラウドプロバイダーに依存することなく、オンプレミス環境や様々なクラウドサービス（AWS、Azureなど）上で動作します。よって、ハイブリッドクラウドやマルチクラウド環境を簡単に構築、管理することができます。\n\n### 拡張性とプラグインアーキテクチャ\n\n多様なプラグインや拡張機能が利用できます。例えば、CustomResourceDefinitions（CRD）を使って新規にリソースタイプやロジックを追加したり、CNI（Container Network Interface）やCSI（Container Storage Interface）といったプラグインでネットワークやストレージのカスタマイズが可能です。\n\n### ローリングアップデートとロールバック\n\nKubernetesでは、アプリケーションのバージョンを更新する際、ローリングアップデートがそのデフォルトとなります。また、ビルトインでロールバック機構もあります。このため、ライブトラフィックに影響を与えず、ダウンタイムゼロでデプロイを実現できます。\n\n### 柔軟なスケーラビリティ\n\nKubernetesは、大量のコンテナを効率的に管理するためのもので、システムのスケーラビリティが向上できます。スケーラビリティとは、どのくらいシステムの拡張ができるかを示す特性で、Kubernetesではコンテナ化されたアプリケーションの数を増減することでスケーリングします。\n\n### リリース後のアプリケーション監視\n\nPrometheusやGrafanaといった監視ツールを使用することで、アプリケーション固有のメトリクスが監視できます。リリース後のパフォーマンス低下や不具合発見といった事象がアラートされるため、問題に迅速に対処できます。\n\n## Kubernetesの利点とは\n\nKubernetesには次のような7つのメリットがあります。\n\n### 生産性の向上\n\n一つ目のメリットは、アプリケーション開発で生産性が向上できる点にあります。従来の仮想化では、アプリケーションごとにゲストOSを用意する必要がありましたが、Kubernetesでは、アプリケーションを直接コンテナエンジン上にデプロイできるため、サーバーのリソース使用量が抑えられます。\n\n### 自己修復機能により障害に耐性\n\nKubernetesには、PodやNodeに障害が起きた場合、最初の定義（マニフェスト）の状態まで自動修復する機能が備わっています。\n\n### 高い可用性を担保\n\nKubernetesは、複数のNodeの集まりであるクラスターを構成します。あるクラスターで障害が発生した場合、障害が起きたコンテナを自動で再起動させます。また、他のNodeでコンテナを起動させ、処理を引き継ぐ動作も継続できるため、高い可用性が担保できます。\n\n### オンプレミスでも、クラウドでも運用可能\n\nKubernetesは、オンプレミスでも、プライベートクラウド、パブリッククラウドでも利用できます。つまり、自社サーバーでも、クラウドを使っても、どんな環境でも運用可能です。\n\n### 大量のコンテナの一括管理\n\nKubernetesでは、大量のコンテナが一括で管理・運用できます。また、設定ファイルを複数のコンテナ間で共有することによって、設定変更時も正確かつ大量に設定を反映させることが可能です。\n\n### DevSecOpsとの親和性が高い\nDevSecOpsとは、開発と運用を統合するDevOpsにセキュリティを加え、運用を視野に入れながら開発とセキュリティを同時に進め、安心・安全なソフトウェアを迅速にリリースするというコンセプトです。Kubernetesにはアプリケーションの開発と運用の双方に必要とされる機能が多く搭載されているため、DevSecOpsとの親和性が非常に高いという特長があります。\n\n### クラウドネイティブなワークロードを安全に保つ\n\nKubernetesは、クラウドネイティブアーキテクチャに基づいており、クラウドネイティブな情報セキュリティに関するベストプラクティスについて、CNCF（Cloud Native Computing Foundation）からのアドバイスを活用しています。\n\nたとえばKubernetesには、APIやセキュリティコントロールが含まれており、情報セキュリティを管理するポリシーを定義する手段も備わっています。クラウドの利用などでセキュリティ面において懸念が生じても、Kubernetesならユーザーごとにアクセス制限を設定でき、不正アクセスが防止できるため安心です。\n\nまた、Pod Security Standardによりセキュリティに3つのポリシーが定義されています。非常に緩いものから非常に厳しいものまで累積的に定義できます。\n\n## GitLabでKubernetesを統合する\n\nKubernetesクラスターとGitLabを接続すると、アプリの開発・デプロイ・管理・監視ができます。  \nGitLabをKubernetesと連携させる、またはKubernetes内で動作させるには、3つの異なる方法があります。単独で使用することも、組み合わせて使用することもできます。\n\n* GitLabからKubernetesにソフトウェアをデプロイする  \n* Kubernetesを使用してGitLabインスタンスに紐づいたRunnerを管理する  \n* GitLabのアプリケーションとサービスをKubernetesクラスター上で実行する\n\nさらに詳しい情報やお問い合わせは[こちら](https://about.gitlab.com/ja-jp/solutions/kubernetes/)をご覧ください。\n\n## Kubernetes （K8s）のよくある質問\n\n### KubernetesとDockerの違いは何ですか？\n\nDockerはコンテナ化ツールのひとつで、アプリケーションコンテナを構築し、アプリケーションの開発・配布・実行をします。Kubernetesは、より大規模に複数のマイクロサービスを管理するのに使われます。  \nまた、Kubernetesはクラスターで実行され、Dockerはノードで実行されます。Kubernetesの使用目的はコンテナ管理ですが、Dockerの使用目的の一つは、アプリケーションをコンテナに分離することになります。\n\n### Kubernetesで何ができますか？\n\nKubernetesでできることの代表例には下記のようなものが挙げられます。\n\n* 大量のコンテナの一括管理\n* 起動を含めた動作の高速化・軽量化  \n* 自動デプロイ  \n* 自己修復機能により障害に耐性\n* 高い可用性を担保\n* オンプレミスでも、クラウドでも運用可能\n* DevSecOpsとの親和性が高い\n* クラウドネイティブなワークロードを安全に保つ\n\n### Kubernetesコンテナとは何ですか？\n\nソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することをコンテナ化と言います。Kubernetesコンテナは、完全に機能するポータブルなコンピューティング環境で、さまざまなプラットフォームでデプロイ可能なプログラムとして[マイクロサービス](https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture/)アーキテクチャを可能にします（リンクは英語版です）。\n\n### Kubernetesの読み方は？\n\nKubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と読み、「K8s（ケーエイツ）」と略されます。\n",[1548,1189,1190,110,533,825,722,1191,677],"kubernetes",{"slug":1550,"featured":92,"template":681},"what-is-kubernetes","content:ja-jp:blog:what-is-kubernetes.yml","What Is Kubernetes","ja-jp/blog/what-is-kubernetes.yml","ja-jp/blog/what-is-kubernetes",{"_path":1556,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1557,"content":1562,"config":1567,"_id":1569,"_type":16,"title":1570,"_source":17,"_file":1571,"_stem":1572,"_extension":20},"/ja-jp/blog/getting-started-with-gitlab-understanding-ci-cd",{"title":1558,"description":1559,"ogTitle":1558,"ogDescription":1559,"noIndex":6,"ogImage":1402,"ogUrl":1560,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1560,"schema":1561},"GitLab入門：CI/CDについて理解する","この初心者向けガイドでは、継続的インテグレーション（CI）／継続的デリバリー（CD）の基本（CI/CDコンポーネントの概要や作成方法など）を解説します。","https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab入門：CI/CDについて理解する\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-25\",\n      }",{"title":1558,"description":1559,"authors":1563,"heroImage":1402,"date":1564,"body":1565,"category":701,"tags":1566},[696],"2025-04-25","すべてのコード変更が自動的にビルドおよびテストされ、そのうえでユーザーにデプロイされる。そんなワークフローを想像してみてください。それを可能にするのが、[継続的インテグレーション／継続的デリバリー（CI/CD）](https://about.gitlab.com/ja-jp/topics/ci-cd/)です。CI/CDは、バグの早期発見、コード品質の確保、および迅速かつ頻繁なソフトウェアデリバリーの実現に役立ちます。\n\n\n### CI/CDとは\n\n\n*\n**継続的インテグレーション（CI）**は、デベロッパーがコード変更を頻繁に（1日に数回が理想とされる）共有リポジトリに統合する開発手法です。各統合は自動化されたビルドとテストのプロセスによって検証されるため、早い段階で問題を検出できます。\n\n*\n**継続的デリバリー（CD）**はCIを拡張した開発手法で、リリースパイプラインを自動化することで、コードを*常に*デプロイ可能な状態に保ちます。アプリケーションをさまざまな環境（stagingステージ、本番環境など）に自動的に、またはワンクリックでデプロイできます。\n\n*\n**継続的デプロイ**はさらにもう一歩踏み込み、本番環境に*成功したビルドをすべて*デプロイする手法です。継続的デプロイは、自動化されたテストとデプロイのプロセスに十分な信頼性がある場合にのみ、有効です。\n\n\n### GitLab CI/CDが選ばれる理由\n\n\nGitLab\nCI/CDは、GitLabに組み込まれた強力な統合システムです。これを利用することで、ソフトウェア開発ライフサイクル全体をシームレスに自動化できます。GitLab\nCI/CDによって、以下のことを実現できます。\n\n\n* **あらゆるプロセスの自動化**：アプリケーションのビルド、テスト、デプロイを簡単に行えます。\n\n* **バグの早期発見**：問題が本番環境に到達する前に検出し、修正できます。\n\n* **フィードバックループの高速化**：コード変更に関するフィードバックを即座に受け取れます。\n\n* **コラボレーションの向上**：自動化されたワークフローによって、より効果的に共同作業を行えます。\n\n* **デリバリーの高速化**：ソフトウェアをより迅速かつ頻繁にリリースできます。\n\n* **リスクの低減**：デプロイ時のエラーやロールバックを最小限に抑えられます。\n\n\n### GitLab CI/CDの構成要素\n\n\n*\n`.gitlab-ci.yml`：プロジェクトのルートディレクトリにある[YAMLファイル](https://docs.gitlab.com/ee/ci/yaml/)です。ステージやジョブ、Runnerなど、CI/CDパイプラインの構成を定義します。\n\n* [**GitLab\nRunner**](https://docs.gitlab.com/runner/)：任意のインフラストラクチャ（物理マシン、仮想マシン、Dockerコンテナ、Kubernetesクラスターなど）上でCI/CDジョブを実行するエージェントです。\n\n*\n[**ステージ**](https://docs.gitlab.com/ee/ci/yaml/#stages)：ジョブ（ビルド、テスト、デプロイなど）の実行順序を定義します。\n\n*\n[**ジョブ**](https://docs.gitlab.com/ee/ci/yaml/#job-keywords)：ステージ内の個々の作業単位（コードのコンパイル、テストの実行、stagingステージへのデプロイなど）を指します。\n\n\n### GitLab CIの設定\n\n\nGitLab CIは簡単に使い始められます。以下は`.gitlab-ci.yml`ファイルの基本的な設定例です。\n\n\n```yaml\n\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"アプリケーションをビルド中...\"\n\ntest_job:\n  stage: test\n  script:\n    - echo \"テストを実行中...\"\n\ndeploy_job:\n  stage: deploy\n  script:\n    - echo \"本番環境へデプロイ中...\"\n  environment:\n    name: production\n\n```\n\n\nこの設定では、「build」「test」「deploy」の3つのステージを定義しています。それぞれのステージには、単純なスクリプトを実行するジョブが含まれています。\n\n\n### CI/CDの設定例\n\n\n次に、より実践的な例をいくつか見てみましょう。\n\n\n**Node.jsアプリケーションのビルドとデプロイ**\n\n\n以下のパイプライン定義では、npmを使用してNode.jsアプリケーションのビルドおよびテストを行い、[dpl](https://docs.gitlab.com/ci/examples/deployment/)を用いてアプリケーションをHerokuにデプロイする方法を説明しています。パイプラインのdeployステージでは、[GitLab\nCI/CD変数](https://docs.gitlab.com/ci/variables/)を使用しています。デベロッパーは機密情報（認証情報など）をこの変数に格納して、CI/CDプロセスで安全に使用できます。この例では、Herokuにデプロイする際にdplツールが使用するAPIキーが、`$HEROKU_API_KEY`という名前の変数キーに格納されます。\n\n\n```yaml\n\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild:\n  stage: build\n  image: node:latest\n  script:\n    - npm install\n    - npm run build\n\ntest:\n  stage: test\n  image: node:latest\n  script:\n    - npm run test\n\ndeploy:\n  stage: deploy\n  image: ruby:latest\n  script:\n    - gem install dpl\n    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY\n\n```\n\n\n**異なる環境へのデプロイ（stagingステージや本番環境）**\n\n\nGitLabではさらに、CI/CDを使用した[環境](https://docs.gitlab.com/ci/environments/)という機能もご用意しています。この機能を使用すると、CI/CDから対象のインフラストラクチャへのデプロイを追跡できます。以下の例では、パイプラインにおいてstagingステージと本番環境の環境プロパティを持つステージが追加されます。deploy_stagingステージでは必ず指定したスクリプトが実行される一方、deploy_productionステージでは手動による承認が必要となります。これは誤って本番環境へのデプロイが行われるのを防ぐためです。\n\n\n```yaml\n\n\nstages:\n  - build\n  - test\n  - deploy_staging\n  - deploy_production\n\nbuild:\n  # ...\n\ntest:\n  # ...\n\ndeploy_staging:\n  stage: deploy_staging\n  script:\n    - echo \"stagingステージへのデプロイ中...\"\n  environment:\n    name: staging\n\ndeploy_production:\n  stage: deploy_production\n  script:\n    - echo \"本番環境へのデプロイ中...\"\n  environment:\n    name: production\n  when: manual  # 手動による承認が必要\n\n```\n\n\n### GitLab Auto DevOps\n\n\n[GitLab Auto\nDevOps](https://docs.gitlab.com/ee/topics/autodevops/)は、アプリケーションを自動的にビルド、テスト、デプロイするためのあらかじめ定義された設定を提供することで、CI/CDを簡素化します。ベストプラクティスと業界標準に基づいてワークフローを効率化する仕組みです。\n\n\nAuto DevOpsを有効にする方法：\n\n\n1. プロジェクトの**設定 > CI/CD > 一般パイプライン**の順にアクセスします。\n\n2. **Auto DevOps**オプションを有効にします。\n\n\nAuto\nDevOpsを有効にすると、プロジェクトの言語とフレームワークが自動的に検出され、必要なビルド、テスト、デプロイのステージが設定されます。そのため、`.gitlab-ci.yml`ファイルを作成する必要すらありません。\n\n\n### CI/CDカタログ\n\n\n[CI/CDカタログ](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)には、CI/CDワークフローを拡張するために使用可能な、公開済みの[CI/CDコンポーネント](https://docs.gitlab.com/ee/ci/components/)をまとめたプロジェクトが一覧で記載されています。誰でもコンポーネント用のプロジェクトを作成してCI/CDカタログに追加したり、既存プロジェクトへのコントリビュートを通じて公開コンポーネントを改善したりできます。これらのコンポーネントは、GitLab.comの[CI/CDカタログ](https://gitlab.com/explore/catalog)に掲載されています。\n\n\n> [チュートリアル：初めてのGitLab\nCI/CDコンポーネントの設定方法](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n\n\n### CIテンプレート\n\n\nさらに、独自の[CIテンプレート](https://docs.gitlab.com/ee/ci/examples/)を作成して、複数のプロジェクトに対するCI/CDの設定を標準化し、再利用することもできます。これにより、一貫性が高まり、重複が生じにくくなります。\n\n\nCIテンプレートの作成方法：\n\n\n1. 専用のプロジェクトまたはリポジトリに`.gitlab-ci.yml`ファイルを作成します。\n\n2. テンプレートでCI/CD設定を定義します。\n\n3. プロジェクトの`.gitlab-ci.yml`ファイルで、`include`キーワードを使用してテンプレートをインクルードします。\n\n\n## 開発ワークフローをレベルアップ\n\n\nGitLab CI/CDは、開発ワークフローに変革をもたらせる強力なツールです。CI/CDの概念を理解して、パイプラインを設定し、Auto\nDevOpsやCI/CDカタログ、CIテンプレートなどの機能を活用すれば、ソフトウェア開発ライフサイクル全体を自動化し、高品質なソフトウェアをより迅速かつ効率的に提供できます。\n\n\n> さらに詳しく知りたい場合は、[GitLab\nUniversityのコースに登録](https://university.gitlab.com/)するか、[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)を今すぐお試しください。\n\n\n## 「GitLab入門」シリーズ\n\n\n「GitLab入門」シリーズのその他の記事もぜひご覧ください。\n\n\n-\n[ユーザーの管理方法](https://about.gitlab.com/ja-jp/blog/getting-started-with-gitlab-how-to-manage-users/)\n\n- \n[GitLabへのプロジェクトのインポート方法](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n\n-\n[プロジェクト管理を極める](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n\n- [gitlab-triage\ngemを使ったアジャイルワークフローの自動化](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n",[110,1410,1411,904,701,676],{"slug":1568,"featured":92,"template":681},"getting-started-with-gitlab-understanding-ci-cd","content:ja-jp:blog:getting-started-with-gitlab-understanding-ci-cd.yml","Getting Started With Gitlab Understanding Ci Cd","ja-jp/blog/getting-started-with-gitlab-understanding-ci-cd.yml","ja-jp/blog/getting-started-with-gitlab-understanding-ci-cd",{"_path":1574,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1575,"content":1581,"config":1589,"_id":1591,"_type":16,"title":1592,"_source":17,"_file":1593,"_stem":1594,"_extension":20},"/ja-jp/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"title":1576,"description":1577,"ogTitle":1576,"ogDescription":1577,"noIndex":6,"ogImage":1578,"ogUrl":1579,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1579,"schema":1580},"GitLab 18.0における破壊的な変更に関するガイド","次期メジャーリリースで予定されている機能の削除に備えましょう。GitLab 18.0にスムーズに移行できるように、ご自身にどのような影響があるかを見極め、ドキュメントに記載されている影響を軽減するためのステップをご確認ください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","https://about.gitlab.com/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 18.0における破壊的な変更に関するガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Martin Brümmer\"},{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"},{\"@type\":\"Person\",\"name\":\"Sam Wiskow\"}],\n        \"datePublished\": \"2025-04-18\",\n      }",{"title":1576,"description":1577,"authors":1582,"heroImage":1578,"date":1586,"body":1587,"category":701,"tags":1588},[1583,1584,1585],"Martin Brümmer","Fabian Zimmer","Sam Wiskow","2025-04-18","次のメジャーリリースであるGitLab 18.0では、DevSecOpsによるイノベーションの限界を打ち破る新機能が多数提供されます。一方で、GitLabからいくつかの非推奨機能が削除される予定です。このページでは、予定されている破壊的な変更についてご留意いただきたい点と、その影響を軽減する方法をご紹介します。\n\n## デプロイスケジュール\n\n### GitLab.com\n\nGitLab.comでは破壊的な変更が以下の3つの期間にのみデプロイされる予定です。\n\n- 2025年4月21～23日  \n- 2025年4月28～30日  \n- 2025年5月5～7日\n\nその他にも多くの変更が、今月いっぱい実装される予定です。各期間中にデプロイされる影響度の高い変更については、[こちらの破壊的な変更に関するドキュメント](https://docs.gitlab.com/update/breaking_windows/)で詳細をご覧いただけます。\n\n***注**：例外的な状況が生じた場合は、破壊的な変更が上記の期間をわずかに前後する可能性があります。*\n\n### GitLab Self-Managed\n\nGitLab 18.0は5月15日から提供開始されます。リリーススケジュールの詳細については、[こちら](https://about.gitlab.com/releases/)をご覧ください。\n\n### GitLab Dedicated\n\nGitLab 18.0へのアップグレードは、2025年6月24日から29日までのメンテナンス期間中に行われます。詳細およびご自身の地域のメンテナンス期間については、[こちら](https://docs.gitlab.com/administration/dedicated/maintenance/#release-rollout-schedule)をご覧ください。\n\nまた、18.0へのアップグレードに先立ち、導入される変更点がお客様の環境に及ぼす影響を評価し、必要な対応を計画する上で役立つカスタムツールとリソースをご用意しました。[影響を緩和するためのツールとリソースに関する情報はこちら](#tools-and-resources-to-manage-your-impact)でご確認いただけます。\n\n18.0で削除される予定の全項目の一覧については、[非推奨機能のページ](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=18.0)をご覧ください。今後の予定に加え、デプロイ方法に基づき今年予定されているリリースに向け準備する方法については、本ページでご紹介していますのでぜひ最後までお読みください。\n\n## 破壊的な変更\n\n### 影響度：高\n\n**1. CI/CDジョブトークン - 「プロジェクトからのアクセスを制限」設定の削除**\n\nGitLab.com | Self-Managed | Dedicated\n\nGitLab 14.4ではセキュリティ強化の目的で、**[プロジェクトのCI/CDジョブトークン（CI_JOB_TOKEN）*からの*アクセスを制限](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access)**する設定を追加しました。この設定は当初、**CI_JOB_TOKENアクセスを制限**という名前でしたが、よりわかりやすくするために、GitLab 16.3で**このプロジェクト*からの*アクセスを制限**という名称に変更されました。\n\nGitLab 15.9では、**[認証されたグループとプロジェクト](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-group-or-project-to-the-job-token-allowlist)**という別の設定を新たに追加しました。この設定は、許可リストを使用してプロジェクトへのジョブトークンでのアクセスを制御します。新たに追加されたこの設定は、元の設定よりも大幅に改善されています。最初のイテレーションはGitLab 16.0で非推奨となっており、GitLab 18.0で削除される予定です。\n\nすべての新規プロジェクトでは、**このプロジェクト*からの*アクセスを制限**設定はデフォルトで無効になります。GitLab 16.0以降のバージョンでは、この設定が無効になったプロジェクトで再度有効にすることはできません。代わりに、**認証されたグループとプロジェクト**設定を使用して、プロジェクトへのジョブトークンでのアクセスを制御してください。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#cicd-job-token---limit-access-from-your-project-setting-removal)\n- [GitLab Detectiveによる検証を実施可能](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**2. CI/CDジョブトークン - 認証されたグループとプロジェクトの許可リストの強制適用**\n\nGitLab.com | Self-Managed | Dedicated\n\nGitLab 15.9で**[認証されたグループとプロジェクトの設定](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)**（GitLab 16.3で**このプロジェクトへのアクセスを制限**に名称が変更）が導入されたことで、プロジェクトへのCI/CDジョブトークンでのアクセスを管理できるようになりました。**このプロジェクトと許可リストに含まれるすべてのグループおよびプロジェクトのみ**に設定されている場合、許可リストに追加されたグループまたはプロジェクトのみがジョブトークンを使用してプロジェクトにアクセスできます。\n\n* **GitLab 15.9より前のバージョン**では、デフォルトでは許可リストは無効になっており（[**すべてのグループとプロジェクト**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-any-project-to-access-your-project)アクセス設定が選択されていた）、どのプロジェクトからもジョブトークンでアクセスできるようになっていました。   \n* **GitLab 17.6以降のバージョン**では、GitLab Self-ManagedおよびDedicatedインスタンスの管理者は、プロジェクトメンテナーが**すべてのグループとプロジェクト**を選べないように設定して、[**すべてのプロジェクトに対してより安全性の高い設定を強制**](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions)できるようになりました。この変更により、プロジェクト間でのセキュリティレベルをさらに強化できます。   \n* GitLab 18.0では、この設定がデフォルトで有効になります。GitLab.comでは、プロジェクトの認証ログに基づいて、プロジェクトの許可リストが自動的に作成されます。   \n* **GitLab.com**でのこの変更に備えて、クロスプロジェクトの認証にジョブトークンを使用しているプロジェクトメンテナーは、担当するプロジェクトにおいて**認証されたグループとプロジェクト**の許可リストを入力する必要があります。完了後、**このプロジェクトと許可リストに含まれるすべてのグループとプロジェクトのみ**に設定を変更してください。GitLab 18.0より前のバージョンのプロジェクトの[認証ログ](https://docs.gitlab.com/ci/jobs/ci_job_token/#job-token-authentication-log)に基づき許可リストの作成を***自動化***するには、ご用意している[移行ツール](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist)のご利用をおすすめします。   \n* **Self-Managedユーザー**は18.0へのアップグレードを完了する前に、許可リストの入力を完了する必要があります。   \n* **Dedicatedユーザー**は、お客様固有のインスタンスに適した計画を立ててください。GitLabアカウントチームがお手伝いいたします。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#cicd-job-token---authorized-groups-and-projects-allowlist-enforcement)\n- [ドキュメント](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-gr)\n- [GitLab Detectiveによる検証を実施可能](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**3. 依存プロキシへのトークンスコープの強制適用**\n\nGitLab.com | Self-Managed | Dedicated\n\nコンテナの依存プロキシは、**パーソナルやプロジェクト、グループ**アクセストークンを用いた**`docker login`**および**`docker pull`**リクエストを受け取った場合、そのスコープを検証せずにリクエストを受け入れます。\n\nGitLab 18.0では、依存プロキシでの認証の際に**`read_registry`**および**`write_registry`**スコープが必要となります。この変更の適用後に、これらのスコープを持たないトークンによる認証リクエストが行われた場合、**拒否**されます。\n\nそのため、アップグレードする前に、[**必要なスコープ**](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy-for-container-images)を持つアクセストークンを新たに作成し、作成したトークンを使用してワークフローの変数とスクリプトを更新してください。\n\nまた、[**Dependency Token Checker**](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/dependancy-token-checker/)をご利用いただくことも可能です。コミュニティが開発したスクリプトで、トークンの表示および自動でのローテーションを行えます。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#dependency-proxy-token-scope-enforcement)\n\n### 影響度：中\n\n**1. GitLab.comでの脆弱性に関する新しいデータ保持制限**\n\nGitLab.com - **Ultimateプランのお客様のみ**\n\nGitLab 18.1から、システムのパフォーマンスと信頼性の向上の目的で、GitLab.comで**Ultimate**プランをご利用のお客様を対象に、6か月間にわたり段階的に**新しいデータ保持制限**を導入します。データ保持制限は、脆弱性データの保存期間に影響します。\n\n12か月以上前に検出されたもので更新されていない脆弱性は、自動的にコールドストレージアーカイブに移動されます。コールドストレージアーカイブのデータに関する詳細は以下のとおりです。\n\n* GitLab UIからアクセスおよびダウンロード可能  \n* 3年間保持される  \n* 3年後に完全に削除される \n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n- [ドキュメント](https://handbook.gitlab.com/handbook/security/records-retention-deletion/)\n\n**2. `allowed_pull_policies`にないコンテナイメージのプルポリシーを拒否**\n\nGitLab.com | Self-Managed | Dedicated  \n\n設定済みのプルポリシーはすべて、Runnerの**`config.toml`**ファイル内の[**allowed_pull_policies設定**](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)に含まれていなければなりません。含まれていない場合、**`incompatible pull policy`**エラーにより、ジョブの実行が失敗します。\n\n現在の実装では、複数のプルポリシーが定義されている場合、少なくとも1つのプルポリシーが**`allowed-pull-policies`**の設定内容と一致すれば、ほかのポリシーが含まれていなくても、ジョブの実行は成功します。\n\nGitLab 18.0では、**`allowed-pull-policies`**に含まれるプルポリシーと一致するものがない場合にのみ、ジョブが失敗します。ただし、これまでの動作とは異なり、**`allowed-pull-policies`**に含まれるプルポリシーだけをジョブが使用するようになります。この違いにより、現在成功しているジョブがGitLab 18.0では失敗する可能性があります。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#reject-container-image-pull-policies-not-in-allowed_pull_policies)\n- [ドキュメント](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)\n\n**3. PostgreSQL 14と15がサポート対象外に**\n\nSelf-Managed \n\nGitLabは、[**PostgreSQLの年間アップグレードスケジュール**](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/)に従っています。\n\nそのため、GitLab 18.0でPostgreSQL 14と15はサポート対象外となる予定です。GitLab 18.0で必要となるPostgreSQLの最小バージョンは、PostgreSQL 16です。\n\nPostgreSQL 14と15は、GitLab 17の全リリースサイクルでサポートされます。PostgreSQL 16は、GitLab 18.0より前のバージョンにアップグレードしたインスタンスでもサポートされます。\n\nこの変更に備えて、[**PostgreSQLクラスター**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/)を使用していないインスタンス（Omnibus Linuxパッケージがインストールされた単一のPostgreSQLインスタンスを実行中の場合など）では、GitLab 17.11へのアップグレード時にPostgreSQLをバージョン16に自動的にアップグレードしようと試行します。[**PostgreSQLクラスター**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/)を使用している場合、または[**このような自動アップグレードを希望しない**](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades)場合、GitLab 18.0にアップグレードするには、事前に[**PostgreSQL 16に手動でアップグレード**](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)する必要があります。その際、アップグレードを行えるように十分なディスク容量があることを確認してください。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)\n- [ドキュメント](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n- [移行に関するガイドライン](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions/)\n\n**4. Terraform CI/CDテンプレートの非推奨化**\n\nSelf-Managed\n\nTerraform CI/CDテンプレートは非推奨化されており、GitLab 18.0で削除される予定です。影響を受けるテンプレートは以下のとおりです。\n\n* `Terraform.gitlab-ci.yml`  \n* `Terraform.latest.gitlab-ci.yml`  \n* `Terraform/Base.gitlab-ci.yml`  \n* `Terraform/Base.latest.gitlab-ci.yml`\n\nこれにより、GitLabはジョブイメージの**`terraform`**バイナリをBSLライセンスのもとで提供されているバージョンに更新することができなくなります。\n\n引き続きTerraformを使用するには、テンプレートと[**Terraformイメージ**](https://gitlab.com/gitlab-org/terraform-images)を複製し、適宜保持してください。カスタムビルドイメージへの[**移行手順の詳細についてはこちら**](https://gitlab.com/gitlab-org/terraform-images)でご確認いただけます。\n\n**また、代替案として、GitLab.comで新しいOpenTofu CI/CDコンポーネントの使用、またはGitLab Self-Managedで新しいOpenTofu CI/CDテンプレートの使用をおすすめします。** CI/CDコンポーネントはGitLab Self-Managedではまだ利用できませんが、[**イシュー#415638**](https://gitlab.com/gitlab-org/gitlab/-/issues/415638)において、この機能の追加が提案されています。GitLab Self-ManagedでCI/CDコンポーネントが利用可能になると、OpenTofu CI/CDテンプレートは削除される予定です。\n\n新しい[OpenTofu CI/CDコンポーネントの詳細についてはこちら](https://gitlab.com/components/opentofu)をお読みください。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#deprecate-terraform-cicd-templates)\n\n**5. Prometheusサブチャートのメジャーアップデート**\n\nSelf-Managed\n\nGitLab 18.0とGitLabチャート9.0で、Prometheusサブチャートのバージョンが15.3から27.3にアップデートされます。\n\nこのアップデートに伴い、デフォルトではPrometheus 3が付属するようになります。\n\nアップグレードを実行するには、手動での設定が必要です。Alertmanager、Node Exporter、Pushgatewayのいずれかが有効になっている場合は、Helm値も更新する必要があります。\n\n詳細については、[**移行ガイド**](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade)を参照してください。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)\n\n### 影響度：低\n\n**1. SUSE Linux Enterprise Server 15 SP2パッケージのビルド終了**\n\nSelf-Managed\n\nSUSE Linux Enterprise Server (SLES) 15 SP2の長期サービスおよびサポート（LTSS）の提供は、2024年12月に終了しました。\n\nこれに伴い、Linuxパッケージインストール用のSLES SP2の配布を終了します。引き続きサポートをご利用いただくには、SLES 15 SP6にアップグレードする必要があります。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#support-for-suse-linux-enterprise-server-15-sp2)\n\n**2. Gitalyレートリミッターの削除**\n\nSelf-Managed\n\n以前、Gitalyでは[**RPCベースのレート制限**](https://gitlab.com/gitlab-org/gitaly/-/blob/4b7ea24f6172a03e7989879200b47b6fd0e2d059/doc/backpressure.md#L55-55)がサポートされていました。この機能では期待する結果が得られなかったため、GitLabでは非推奨となります。詳細については、非推奨化に関するイシューをご覧ください。\n\n（非推奨となる）レートリミッターを設定している場合は、エラーは返されず、単に設定が無視されます。\n\n代わりに、[**並行処理リミッター**](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/)のご利用をおすすめします。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#gitaly-rate-limiting)\n\n**3. NGINXコントローラーイメージ1.3.1のサポートの非推奨化**\n\nSelf-Managed\n\nデフォルトのNGINXコントローラーイメージが1.11.2に更新されます。新しいバージョンでは、新たなRBACルールが必要となります。ユーザーによっては、独自のRBACルールを管理するために**nginx-ingress.rbac.create: false**を設定しています。\n\nこれらのユーザーは、1.11.2以降のバージョンに移行する前に、RBACルールを追加する必要があります。そのため、このHelm値が上記のように設定されている場合にのみ、1.3.1をデプロイするフォールバックメカニズムを実装しました。また、**nginx-ingress.controller.image.disableFallback**も追加しました。デフォルトではfalseに設定されています。独自のRBACを管理しているユーザーは、新しいRBACルールが適用されていることを確認してから、この値をtrueに設定することで、デプロイ環境で1.11.2も使用できるようになります。\n\nなお、バージョン17.5では、1.3.1のイメージのサポートとフォールバックメカニズムを非推奨とする予定です。これにより、1.3.1のサポートが完全に終了となり、多数のセキュリティ上のメリットを得られる1.11.2のみを使用できるようになります。\n\n[非推奨通知](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)\n\n**4. アプリケーションセキュリティテストアナライザーのメジャーバージョンをアップデート**\n\nGitLab.com | Self-Managed | Dedicated\n\nGitLab 18.0のリリースに合わせて、アプリケーションセキュリティテストステージで使用されるアナライザーのバージョンが大幅に更新されます。\n\nデフォルトで含まれているテンプレートを使用していない場合、または利用するアナライザーのバージョンを固定している場合は、CI/CDジョブの定義を更新して、固定したバージョンを削除するか、最新のメジャーバージョンに更新する必要があります。\n\nGitLab 17.0～17.11をお使いの場合は、GitLab 18.0のリリースまで、通常どおりアナライザーのアップデートをご利用いただけます。GitLab 18.0以降のバージョンでは、新たに修正されたバグや機能はすべて、新しいメジャーバージョンのアナライザーでのみリリースされます。\n\nGitLabのメンテナンスポリシーに基づき、バグ修正や新機能を非推奨バージョンに実装することはありません。セキュリティパッチは、必要に応じて最新の3つのマイナーリリースにバックポートされます。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#application-security-testing-analyzers-major-version-update)\n\n**5. API Discoveryにおいてデフォルトでブランチパイプラインを利用するように**\n\nGitLab.com | Self-Managed | Dedicated\n\nGitLab 18.0では、API DiscoveryのCI/CDテンプレート（**API-Discovery.gitlab-ci.yml**）のデフォルトの動作が更新されます。\n\nこのテンプレートはGitLab 18.0より前のバージョンでは、MRが開いているときに、デフォルトで[**マージリクエストパイプライン**](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/)を実行するように設定されていました。\n\nGitLab 18.0からは、ほかのASTスキャナーの[**Stableテンプレートエディション**](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions)の動作に合わせて、このテンプレートの動作を変更します。\n\n* デフォルトでは、本テンプレートはブランチパイプラインでスキャンジョブを実行するようになります。  \n* CI/CD変数の**AST_ENABLE_MR_PIPELINES: true**を設定すると、MRが開いているときに代わりにMRパイプラインを使用できます。この新しい変数の実装状況は、[**イシュー#410880**](https://gitlab.com/gitlab-org/gitlab/-/issues/410880)で追跡されています。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#api-discovery-will-use-branch-pipelines-by-default)\n\n**6. DASTのDAST_DEVTOOLS_API_TIMEOUTのデフォルト値を低めに変更予定**\n\nGitLab.com | Self-Managed | Dedicated\n\n**DAST_DEVTOOLS_API_TIMEOUT**は、DASTスキャンがブラウザからの応答を待つ時間を指定する環境変数です。GitLab 18.0より前のバージョンでは、この変数の値は45秒に固定されていました。GitLab 18.0から、**DAST_DEVTOOLS_API_TIMEOUT**環境変数に動的な値が設定されます。この値は、他のタイムアウト設定をもとに算出されます。\n\n多くの場合、45秒という値は多くのスキャナー機能のタイムアウト値よりも高いものでした。動的に値を算出することで、__DAST_DEVTOOLS_API_TIMEOUT__変数をよりさまざまな状況で適用できるようになり、使いやすくなります。\n\n- [非推奨通知](https://docs.gitlab.com/update/deprecations/#dast-dast_devtools_api_timeout-will-have-a-lower-default-value) \n\n## 影響を制御するためのツールとリソース\n\n予定されている変更点がご利用のGitLabインスタンスに及ぼす影響を把握できるように専用ツールを開発しました。GitLab 18.0にスムーズに移行できるように、ご自身にどのような影響があるかを見極めてから、ドキュメントに記載されている影響を軽減するためのステップをご確認いただくことをおすすめします。\n\n* [非推奨機能の高度な検索](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/deprecation-migration-tools/advanced-search-deprecations)：このツールはGitLabのAdvanced Search APIを使って、GitLabのグループやプロジェクト全体で、非推奨に関連する文字列を検索します。手動でチェックすべきファイルがあれば、それも報告します。*__注__：誤検出が生じる可能性もあります。*  \n* [依存関係スキャンビルドサポート検出ヘルパー](https://gitlab.com/security-products/tooling/build-support-detection-helper)：このツールは、依存関係スキャンの3つの非推奨事項（[1](https://docs.gitlab.com/update/deprecations/#dependency-scanning-for-javascript-vendored-libraries)、[2](https://docs.gitlab.com/update/deprecations/#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner)、および[3](https://docs.gitlab.com/update/deprecations/#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects)。すべて19.0に延期）の影響を受けるプロジェクトを特定します。APIを使用して、関連するファイルとCIジョブ名をスキャンします。\n* [GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)（Self-Managedでのみ利用可能）：実験的なツールで、インストールされているGitLabに既知の問題がないか自動的にチェックします。設定ファイルやデータベースの値を調べて、複雑な確認作業を行います。**注**：必ずGitLabノード上で直接実行してください。\n\nまた、GitLab Universityでは、これらの変更点に備え、計画および影響を緩和するための対応を行う上で役立つミニコース（15分以内）を公開しました。[ぜひこちらから学習を開始してください](https://university.gitlab.com/catalog?query=18.0)。\n\n有料プランをご利用の方で、ご紹介した変更点についてご質問がある場合や、サポートをお求めの場合は、GitLabサポートポータルで[サポートチケットを作成](https://about.gitlab.com/support/portal/)してください。\n\n[Gitlab.comのFreeプランをご利用](https://about.gitlab.com/support/statement-of-support/#free-users)の場合は、[GitLabドキュメント](https://docs.gitlab.com/)や[GitLabコミュニティフォーラム](https://forum.gitlab.com/)、[Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab)などのコミュニティソースを通じて追加サポートを受けられます。\n",[701,904],{"slug":1590,"featured":6,"template":681},"a-guide-to-the-breaking-changes-in-gitlab-18-0","content:ja-jp:blog:a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","A Guide To The Breaking Changes In Gitlab 18 0","ja-jp/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","ja-jp/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"_path":1596,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1597,"content":1603,"config":1609,"_id":1611,"_type":16,"title":1612,"_source":17,"_file":1613,"_stem":1614,"_extension":20},"/ja-jp/blog/gitlab-17-11-release",{"title":1598,"description":1599,"ogTitle":1598,"ogDescription":1599,"noIndex":6,"ogImage":1600,"ogUrl":1601,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1601,"schema":1602},"GitLab 17.11リリース","GitLab 17.11でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662237/Blog/Hero%20Images/product-gl17-blog-release-cover-17-11-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-11-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.11リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-04-17\",\n      }",{"title":1598,"description":1599,"authors":1604,"heroImage":1600,"date":1605,"body":1606,"category":701,"tags":1607,"updatedDate":1608},[738],"2025-04-17","## カスタムコンプライアンスフレームワークを搭載したGitLab 17.11をリリース\n\nこのたび、GitLab 17.11をリリースしました。このリリースでは、GitLab Duo Self-Hostedに複数のDuo機能が追加されたほか、カスタムコンプライアンスフレームワーク、サービスアカウントUI、CI/CDパイプライン入力など、さまざまな機能が追加されました！\n\nこれらの機能は、今回のリリースに含まれる60件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 17.11には、GitLabコミュニティのユーザーから284件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ](https://about.gitlab.com/upcoming-releases/)をご覧ください。\n\n[GitLab 17.11では、カスタムコンプライアンスフレームワークが搭載されました。 クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+17.11%E3%81%A7%E3%81%AF%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%82%B3%E3%83%B3%E3%83%97%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%82%B9%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%8C%E6%90%AD%E8%BC%89%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-17-11-release/&hashtags=)\n\n## 今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は[Heidi Berry](https://gitlab.com/heidi.berry)さんです\n\nGitLab 17.11の注目コントリビューターは、[Heidi Berry](https://gitlab.com/heidi.berry)さんに決まりました！\n\nHeidiさんは、[GitLab Terraformプロバイダー](https://gitlab.com/gitlab-org/terraform-provider-gitlab)や[client-go](https://gitlab.com/gitlab-org/api/client-go)プロジェクトのコントリビューターとして活躍してきました。ここ数回のリリースにわたり、[グループSAMLリンクでカスタムロールを使用する機能](https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/merge_requests/1949)、[グループ単位でのブランチ保護のデフォルト設定](https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/merge_requests/2113)、[サービスアカウントトークンの自動ローテーション](https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/merge_requests/2206)など、要望の多かった機能を継続的に実装してきました。\n\n機能開発にとどまらず、Heidiさんはメンテナンス活動にも積極的に取り組んでおり、[イシューバックログの整理](https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/issues/1035#note_2305643918)、[古いテストの可読性向上](https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/merge_requests/2298)、[よりわかりやすい例を用いたドキュメントの改善](https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/merge_requests/2201)など、多岐にわたる活動を行っています。特にclient-goはTerraformプロバイダーやglabを含む多くのプロジェクトでGitLabとの連携に使われているため、このライブラリへのコントリビュートは非常に価値の高いものです。\n\nHeidiさんはこう語っています。「オープンソースへのコントリビュートに興味のある方には、client-goやterraform-provider-gitlabがおすすめです。スタートにぴったりの優れたドキュメントが用意されていますし、助けてくれるメンテナーもいます。私はこれらのプロジェクトを通して、Go言語を実践的に学ぶことができました。」\n\nHeidiさんは、GitLabコミュニティのコアチームメンバーであり、Kingland社のエンタープライズアーキテクトである、同じくコミュニティコントリビューターの[Patrick Rice](https://gitlab.com/PatrickRice)さんにより推薦されました。Patrickさんは次のように語っています。「17のリリースサイクルを通して100件を超えるマージ済みのコントリビュートと、多くのイシューへのコメントを行ってきたHeidiさんは、GitLabおよびTerraformにとって非常に大きな力となっています。本当にありがとうございます！」\n\nGitLabのDeploy::Environmentsチームのシニアバックエンドエンジニア、[Timo Furrer](https://gitlab.com/timofurrer)も次のように話しています。「Heidiさんの仕事は本当に素晴らしいです。常に一歩先を行き、client-goに必要なSDKコードを実装してくれています。コードのコントリビュートだけでなく、イシューのトリアージにも関わってくれています。これは本当に大きな助けになっていて、こうした支えがあるからこそ、コミュニティ主導のプロジェクトは成り立っていると感じます。」\n\nHeidiさんは、The Co-operative Group社のリードソフトウェアエンジニアとして、デベロッパーエクスペリエンスをより効率的かつ安全に、そして可能な限りスムーズにするために取り組んでいます。\n\nこの場を借りて、GitLabに多大なるコントリビュートをしてくださったHeidiさんに心より感謝します！\n\n\u003Cbr>\n\u003Cbr>\n\u003Cbr>\n\n## GitLab 17.11でリリースされた主な改善点\n\n### 要件やコンプライアンスコントロールでコンプライアンスフレームワークのカスタマイズが可能に\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nこれまで、GitLabのコンプライアンスフレームワークは、特定のコンプライアンス要件や追加の監査が必要なプロジェクトを識別するラベルとして作成されていました。このラベルは、スコープ指定として利用でき、グループ内のすべてのプロジェクトに対してセキュリティポリシーを適用することができました。\n\n今回のリリースでは、コンプライアンスマネージャーがGitLab上でより詳細なコンプライアンスのモニタリングを行えるようにする「要件」を新機能として導入しました。\n\n「要件」は、カスタムコンプライアンスフレームワークの一部として、組織が準拠すべきさまざまなコンプライアンス基準、法律、規制などから、具体的な要件を定義できる機能です。\n\nさらに、コンプライアンスコントロール（従来の「コンプライアンスチェック」）の数を、5種類から50種類以上へと大幅に増やしました！標準搭載された約50種類のコントロールは、定義したコンプライアンス要件に対応付けることができます。\n\nこれらのコントロールは、プロジェクト、セキュリティ、マージリクエストの設定をGitLabインスタンス全体で確認し、SOC2、NIST、ISO 27001、GitLab CISベンチマークといった、さまざまなコンプライアンス基準や法規制への準拠をサポートします。\n\nこうしたコントロールへの準拠状況は、基準遵守レポートに反映されます。このレポートは、要件と、それに対してマッピングされたコントロールの関係を考慮して新たに設計し直されています。\n\nまた、標準搭載のコントロールを増やしただけでなく、GitLabの外部に存在する項目、プログラム、システムなどに対して、要件を外部コントロールとしてマッピングできるようになりました。これにより、GitLabのコンプライアンスセンターを信頼できる唯一の情報源として使用して、より包括的なコンプライアンス管理が可能となります。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)\n\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13295)\n\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13658)\n\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16620)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/custom_compliance_frameworks.png\">\n\n### GitLab Eclipseプラグインがベータ版として利用可能に\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nGitLab Eclipseプラグインのベータ版をリリースしました。このプラグインは現在[Eclipse マーケットプレース](https://marketplace.eclipse.org/content/gitlab-eclipse)で入手可能です。この強力な新プラグインにより、GitLabのDuo機能をEclipse IDEに直接統合でき、Duo ChatやAIによるコード提案をスムーズに利用できるようになります。\n\n現在ベータ版のため、認証オプションの拡充やユーザーエクスペリエンスの最終調整など、機能改善を積極的に進めています。皆様のフィードバックは非常に貴重です。ぜひ、[イシュー162](https://gitlab.com/gitlab-org/editor-extensions/gitlab-eclipse-plugin/-/issues/162)にコメントを追加して、GitLab Eclipseプラグインをより良いものにするためのフィードバックをお聞かせください。\n\n[ドキュメント](https://docs.gitlab.com/editor_extensions/eclipse/setup/)\n[エピック](https://gitlab.com/groups/gitlab-org/editor-extensions/-/epics/89)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/eclipse-beta.png\">\n\n### GitLab Duo Self-Hostedで、さらに多くのGitLab Duo機能が利用可能に\n\nSaaS: -\nSelf-Managed: Ultimate、Duo Enterprise\n\nGitLab Self-Managedインスタンスで、GitLab Duo Self-Hostedを使用してさらに多くの[GitLab Duo](https://about.gitlab.com/gitlab-duo/)機能を利用できるようになりました。以下の機能がベータ版として利用できます。\n\n* [根本原因分析](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#troubleshoot-failed-cicd-jobs-with-root-cause-analysis)\n* [脆弱性の説明](https://docs.gitlab.com/user/application_security/vulnerabilities/#explaining-a-vulnerability)\n* [脆弱性の修正](https://docs.gitlab.com/user/application_security/vulnerabilities/#vulnerability-resolution)\n* [AIインパクトダッシュボード](https://docs.gitlab.com/user/analytics/ai_impact_analytics/)\n* [ディスカッションサマリー](https://docs.gitlab.com/user/discussions/#summarize-issue-discussions-with-duo-chat)\n* [マージリクエストのコミットメッセージ](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#generate-a-merge-commit-message)\n* [マージリクエストサマリー](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#generate-a-description-by-summarizing-code-changes)\n* [CLI用GitLab Duo](https://docs.gitlab.com/editor_extensions/gitlab_cli/#gitlab-duo-for-the-cli)\n\n[コードレビューサマリー](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#summarize-a-code-review)も、実験的にGitLab Duo Self-Hostedで利用可能です。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/#supported-gitlab-duo-features)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17072)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/ResizedExpandedDuoFeaturesImage.jpg\">\n\n### Self-Managedインスタンス向けWeb IDEで拡張機能マーケットプレイスが利用可能に\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nSelf-Managedユーザー向けのWeb IDEに拡張機能マーケットプレースが登場しました。拡張機能マーケットプレースでは、サードパーティの拡張機能を検索、インストール、管理できるため、快適な開発環境で効率的に作業できるようになります。\n\nデフォルトでは、GitLabインスタンスはOpen VSX拡張機能レジストリを使用するように構成されています。この機能を有効化するには、[デフォルトの拡張機能レジストリを使って有効にする](https://docs.gitlab.com/administration/settings/vscode_extension_marketplace/#enable-with-default-extension-registry)手順を参照してください。\n\nまた、独自のレジストリやカスタムレジストリを使用したい場合は、[カスタム拡張レジストリを接続することも可能です](https://docs.gitlab.com/administration/settings/vscode_extension_marketplace/#customize-extension-registry)。これにより、利用可能な拡張機能の管理にさらなる柔軟性が生まれます。\n\n拡張機能マーケットプレースを有効にした後でも、各ユーザーは個別に利用を有効化する必要があります。有効化は、[環境設定](https://gitlab.com/-/profile/preferences)の「インテグレーション」セクションで行えます。\n\nなお、一部の拡張機能はローカルの実行環境を必要とし、Web専用バージョンでは使用できないものがあります。それでも、数千種類の中から自由に拡張機能を選び、生産性向上やワークフローのカスタマイズに活用できます。\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/vscode_extension_marketplace/)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11770)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/extension-marketplace-sm.png\">\n\n### GitLab Duo with Amazon Qの一般提供を開始\n\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate\n\nGitLab Duo with Amazon Qの一般提供を開始しました。GitLab Duo with Amazon Qは、AIを搭載したGitLabの包括的なDevSecOpsプラットフォームと自律型Amazon Q AIアシスタントを一つの統合ソリューションとして提供する共同サービスです。GitLab Duo with Amazon Qは開発ワークフローに直接AIアシスタントを組み込むことで、デベロッパーが作業環境を行き来する必要がなくなり、結果として主要タスクのスピードアップを実現します。これらのAIアシスタントはGitLab DevSecOpsプラットフォーム内で高度な知能を持つパートナーとして機能し、コード生成、テスト、レビュー、Javaモダナイゼーションなどの時間のかかる作業を自動化します。これにより、チームはセキュリティと品質基準を維持しながら、より革新的な業務に集中できるようになります。\n\nGitLab Duo with Amazon Qは開発チームに次のような大きなメリットをもたらします：\n\n* アイデアからコードまでの機能開発を効率化：`/q dev`コマンドを使えば、イシューの説明文から数分でマージ可能なコードを直接生成できます。\n* 手間なくレガシーコードを最新化：`/q transform`コマンドでJavaコードの最新化プロセス全体を自動化します。\n* 品質を落とさずコードレビューを迅速化：`/q review`コマンドを使用すれば、マージリクエスト内で即座にコード品質とセキュリティに関する的確なフィードバックが得られます。\n* 安心してリリースするためのテスト自動化：`/q test`コマンドで、アプリケーションのロジックを理解した包括的な単体テストを生成します。\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/Duo_Q1.png\">\n\n[ドキュメント](https://docs.gitlab.com/user/duo_amazon_q/)\n\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16879)\n\n### 保護されたコンテナタグによるセキュリティ強化\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nコンテナレジストリは、現代のDevSecOpsチームにとって重要なインフラストラクチャです。これまで、GitLabのデベロッパー権限以上のユーザーであれば、どのコンテナタグにもプッシュおよび削除が可能であり、本番環境で使用される重要なコンテナイメージが誤って変更されたり、不正に変更されたりするリスクがありました。\n今回導入された、保護されたコンテナタグにより、特定のコンテナタグをプッシュまたは削除できるユーザーを細かく制御できるようになりました。具体的には、以下のことが可能です。\n\n* プロジェクトごとに最大5件の保護ルールを作成\n* `latest`、セマンティックバージョン（例：`v1.0.0`）、安定版タグ（例：`main-stable`）のようなタグを、RE2正規表現パターンで保護\n* プッシュ操作と削除操作をメンテナー、オーナー、または管理者に制限\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/protected_container_tags/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/523893)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/Xo5n-lZSSRg?si=_JP6dL_s04fwp60V\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### 保護されたMavenパッケージでレジストリを安全に\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n本リリースでは、Mavenの保護パッケージが新たにサポートされました。この機能は、GitLabパッケージレジストリのセキュリティと安定性を強化することを目的として設計されました。パッケージの誤った変更は、開発プロセス全体に大きな影響を及ぼす可能性があります。保護パッケージ機能を使うことで、意図せぬ変更を防いで重要な依存関係を守ることができます。\n\nGitLab 17.11では、保護ルールを作成してMavenパッケージを保護できるようになりました。保護ルールの条件に合致したパッケージは、許可された特定のユーザーのみが新しいバージョンをプッシュできます。パッケージ保護ルールによって、意図しない上書きの防止、規制要件へのコンプライアンス強化、手動モニタリングの必要性の軽減を実現できます。\n\nこのMavenパッケージの[保護機能](https://gitlab.com/groups/gitlab-org/-/epics/5574)やその他のパッケージフォーマットへの対応は、`gerardo-navarro`さんとSiemens社チームによるコミュニティからのコントリビュートによって実現しました。この場を借りて、GitLabに多大なるコントリビュートをしてくださったGerardoさんをはじめ、Siemens社のみなさまに感謝します！この変更に対するGerardoさんとSiemens社の方々のコントリビュートについて、詳しくはこちらの[動画](https://www.youtube.com/watch?v=5-nQ1_Mi7zg)をご覧ください。Gerardoさんが、外部のコントリビューターとしてGitLabにコントリビュートした経験から得た洞察やベストプラクティスを紹介してくださっています。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/packages/package_registry/package_protection_rules.html)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/323969)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/GeCXDespqeM?si=44JAVztwQr5UQ5bW\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### エピック、イシュー、タスク用のカスタムフィールド\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nこのリリースから、イシュー、エピック、タスク、目標、および主な結果に対して、テキスト、数値、単一選択、および複数選択のカスタムフィールドを設定できるようになりました。これまでは、ラベルが作業アイテムを分類する主な方法でしたが、カスタムフィールドを使うことで、よりユーザーフレンドリーな形で、計画アーティファクトに構造化されたメタデータを追加できます。\n\nカスタムフィールドは、トップレベルグループで設定され、すべてのサブグループおよびプロジェクトに反映されます。また、フィールドは1つ以上の作業アイテムタイプにマッピング可能で、カスタムフィールドの値を使ってイシューやエピックの一覧を絞り込むこともできます。\n\n[ドキュメント](https://docs.gitlab.com/user/work_items/custom_fields/)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14904)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/work-items-custom-fields.png\">\n\n### 新しいイシュー画面の一般提供を開始\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nこのリリースより、新しいイシュー画面の一般提供が開始され、従来のイシュー画面に取って代わります。イシューはエピックやタスクと共通のフレームワークを使用するようになり、リアルタイムで更新されるとともに、ワークフローが改善されました。\n\n* **ドロワー表示：**\n\n  リストやボードのアイテムをドロワーで開いて、現在の画面から離れることなく素早く内容を閲覧できます。上部のボタンで全ページ表示に切り替わります。\n\n* **タイプの変更：**\n\n  「種類の変更」アクション（従来の「エピックへの昇格」）を使用して、エピック、イシュー、タスク間でタイプを変換できるようになりました。\n\n* **開始日：**\n\n  イシューで開始日がサポートされるようになり、エピックやタスクと機能が統一されました。\n\n* **祖先：**\n\n  タイトルの上とサイドバーの親フィールドに完全な階層が表示されます。関係の管理には、新しいクイックアクションコマンド`/set_parent`、`/remove_parent`、`/add_child`、`/remove_child`を使用できます。\n\n* **操作メニュー：**\n\n  すべてのアクションに上部のメニュー（縦方向の3点ドット）からアクセスできるようになりました。スクロールした場合でも消えずにヘッダーに表示されます。\n\n* **開発：**\n\n  イシューやタスクに関連するすべての開発アイテム（マージリクエスト、ブランチ、機能フラグ）が1つの便利なリストに統合されました。\n\n* **レイアウト：**\n\n  UIが改善され、イシュー、エピック、タスク、マージリクエスト間の移動がスムーズになり、より効率的にワークフローを進められるようになりました。\n\n* **リンクされたアイテム：**\n\n  改善されたリンクオプション機能で、タスク、イシュー、エピック間の関連付けが簡単になりました。ドラッグ＆ドロップでリンクのタイプを変更したり、ラベルや完了したアイテムの表示/非表示を切り替えたりできます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/issues/issue_work_items/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/525547)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/_jrnkD69KGw?si=nZojuQeVuJwvO5S0\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### サービスアカウントのUI\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nGitLabのUI上に、サービスアカウントの作成と管理に特化した専用画面が追加されました。このインターフェースを使用すると、GitLabリソースへの自動アクセスを作成、モニタリング、制御できます。これまでは、この機能はAPI経由でしか利用できませんでした。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/service_accounts.html)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/9965)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/ujX_yzmOMCQ?si=CBpg2LdWLEgWHf-E\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### Duo ProとDuo Enterpriseシートの自動割り当て\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nSAMLグループ同期を使用して、GitLab Duo ProやGitLab Duo Enterpriseのシートを自動的にユーザーに割り当てられるようになりました。GitLabグループに利用可能なDuo ProまたはDuo Enterpriseのシートが残っている限り、IDプロバイダ（IdP）からマッピングされたユーザーに自動的にシートが割り当てられます。これにより、シートの割り当てを管理する手間を抑えられます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html#gitlab-duo-seat-assignment)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/502496)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/govern_duo_saml.png\">\n\n### CI/CDパイプライン入力\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nCI/CD変数は動的なCI/CDワークフローには欠かせない要素で、環境変数、コンテキスト変数、ツールの設定、マトリックス変数など、さまざまな用途で使用されています。しかし、デベロッパーはCI/CD変数を使って[パイプライン変数](https://docs.gitlab.com/ci/variables/#use-pipeline-variables)をパイプラインに注入し、パイプラインの動作を手動で変更することがあります。これは、パイプライン変数の優先度が他の変数よりも高いため、予期しない影響を及ぼすリスクがあります。\n\nGitLab 17.11から、パイプライン変数の代わりに`inputs`機能を使って、安全にパイプラインの挙動を変更できるようになりました。この機能は、スケジュールされたパイプライン、ダウンストリームパイプライン、トリガーされたパイプラインなど、さまざまなケースで利用可能です。inputsを使うことで、デベロッパーがCI/CDジョブの実行中に動的な内容（状況に応じて変化する情報）を組み込む作業が、より構造化され柔軟に行えるようになります。inputsに切り替えた後、[パイプライン変数へのアクセスを完全に無効化する](https://docs.gitlab.com/ci/variables/#restrict-pipeline-variables)ことも可能です。\n\nぜひお試しの上、専用の[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/533802)からフィードバックをお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ci/inputs/#for-a-pipeline)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16321)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/run_new_pipeline_spec_input.png\">\n\n## GitLab 17.11のリリースに含まれるその他の改善点\n\n### 自動で無効化されたすべてのWebhookを自動で再有効化\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nこのリリースでは、`4xx`エラーを返すWebhookが自動的に再有効化されるようになりました。すべてのエラー（`4xx`、`5xx`、またはサーバーエラー）が同じように処理されるため、動作がより予測可能になり、トラブルシューティングが容易になります。この変更については、[こちらブログ投稿](https://about.gitlab.com/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities/)で詳しく解説しています。\n\n失敗したWebhookは、一時的に1分間無効になり、最大24時間まで延長されます。Webhookが40回連続して失敗すると、永久に無効になります。\n\nGitLab 17.10以前で永久に無効にされたWebhookは、データの移行が行われました。\n\n* GitLab.comの場合、これらの変更は自動的に適用されます。\n* GitLab Self-ManagedおよびGitLab Dedicatedの場合、これらの変更は、`auto_disabling_webhooks`の`ops`フラグが有効になっているインスタンスにのみ影響します。\n\nこの場を借りて、[コミュニティにコントリビュート](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/166329)してくれた[Phawin](https://gitlab.com/lifez)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/user/project/integrations/webhooks/#auto-disabled-webhooks)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/396577)\n\n### インポート時にGhostユーザーのコントリビュートを自動マッピング\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nこれまで、Ghostユーザーのコントリビュートはプレースホルダー参照として作成され、手動での再アサインを必要とし、移行作業に余分な手間がかかっていました。今回の改善により、[新しいコントリビュートおよびメンバーシップのマッピング機能](https://docs.gitlab.com/user/project/import/#user-contribution-and-membership-mapping)を使用するインポーター（たとえば、直接転送による移行や、GitHub、Bitbucket Server、Giteaのインポーター）では、Ghostユーザーのコントリビュートをより効率的に処理できるようになりました。コンテンツをGitLabにインポートする際、移行元インスタンスでGhostユーザーが行ったコントリビュートが、移行先インスタンスのGhostユーザーに自動的にマッピングされます。\n\nこの機能強化により、Ghostユーザーのコントリビュートに対して不要なプレースホルダーユーザーが作成されなくなり、ユーザーマッピング画面の煩雑さが減り、移行プロセス全体が簡素化されました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/import/#user-contribution-and-membership-mapping)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/514014)\n\n### GitLab.comへのインポート時におけるコントリビュートの再アサインにSAML認証が追加\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nこのマイルストーンでは、GitLab.comにインポートする際、コントリビュートの再アサインプロセスにSAML認証チェックを追加しました。これらのチェックにより、SAML SSOが有効なグループで発生していた再アサインエラーを防止できるようになりました。\n\nGitLab.comにインポートし、GitLab.comグループでSAML SSOを使用する場合、すべてのユーザーは、コントリビュートとメンバーシップを再アサインする前に、SAML IDをGitLab.comアカウントにリンクする必要があります。SAML IDが認証されていないユーザーにコントリビュートを再アサインすると、エラーメッセージが表示されます。これらのメッセージでは、グループメンバーシップを正しく割り当てるための手順が説明されています。\n\n[ドキュメント](https://docs.gitlab.com/user/project/import/#requirements)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/513686)\n\n### Wikiサイドバーのスタイルを改善\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nカスタムWikiサイドバーのスタイルが改善され、見出しサイズが小さくなり、リストの左側の余白も調整されました。こうした視認性を高める改善により、`_sidebar wiki`ページで作成されたカスタムナビゲーションの読みやすさが向上しました。\n\nカスタムサイドバーは、チームが独自のナレッジベース構造に合わせてWikiコンテンツを整理するのに役立ちます。このスタイルの更新により、サイドバーが見やすくなり、視覚的な階層構造がより明確になり、チームメンバーが必要な情報を見つけやすくなりました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/wiki/#customize-sidebar)\n[マージリクエスト](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/185678)\n\n### 作業中の上限をウェイトで設定\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nイシューの数に加えて、作業中の上限をウェイトで設定できるようになりました。これにより、チームのワークロードをより柔軟に管理できます。\n\nイシューの数だけでなく、各タスクの複雑さや作業量に基づいて作業の流れをコントロールできます。作業量をイシューのウェイトで表しているチームは、特定のボードリスト内のイシューの合計ウェイトを制限することで、チームに負担がかかりすぎるのを防げます。\n\nこの機能を活用することで、チームの生産性を最適化し、さまざまなタスクの複雑さを考慮した、よりバランスの取れたワークフローを実現できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/issue_board.html#work-in-progress-limits)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/119208)\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/allow_users_to_set_work_in_progress_limits_by_weight.png\">\n\n### キャンセル状態でスタックしたCI/CDジョブを強制キャンセル\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nCI/CDジョブが「キャンセル中」状態でスタックし、デプロイや共有リソースへのアクセスをブロックすることがあります。\n\nメンテナーの[ロール](https://docs.gitlab.com/user/permissions/)を持つユーザーは、ジョブログページから直接これらの停止したジョブを強制キャンセルできるようになりました。これにより、問題のあるジョブを適切に終了できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/ci/jobs/#force-cancel-a-job)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/467107)\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/force-cancel-stuck-jobs.png\">\n\n### 失敗したジョブが一目でわかるパイプラインビュー\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n新しい表示機能により、パイプライングラフで失敗したジョブをすばやく識別できるようになりました。失敗したジョブグループはパイプライングラフで強調表示され、失敗したジョブは各ステージの上部にグループ化されます。複雑なパイプライン構造を隅々まで調べなくても、問題のあるジョブを素早く特定してトラブルシューティングができるようになりました。\n[ドキュメント](https://docs.gitlab.com/ci/pipelines/#view-pipelines)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/512300)\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/failed-jobs-pipeline-graph.png\">\n\n### 依存プロキシのDocker Hub認証UIが登場\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab依存プロキシにおいて、Docker Hub認証をUIから設定できるようになりました。この機能はもともとGitLab 17.10でGraphQL APIを通じてのみ利用可能でしたが、今回のリリースで、より簡単に設定できるユーザーインターフェースが追加されました。\n\nこの機能強化により、グループ設定ページから直接Docker Hub認証を設定できるようになり、以下のことが可能になりました。\n\n* レート制限によるパイプラインの失敗を回避\n* プライベートなDocker Hubイメージへのアクセス\n* Docker Hubの認証情報、[パーソナルアクセストークン](https://docs.docker.com/security/for-developers/access-tokens/)、または[組織アクセストークン](https://docs.docker.com/security/for-admins/access-tokens/)を安全に保存\n\nこの効率化されたアプローチにより、GraphQL APIを使用せずに、CI/CDパイプラインでDocker Hubイメージに安定してアクセスできるようになりました。\n\n### Kubernetes 1.32のサポートを追加\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nこのリリースでは、2024年12月にリリースされたKubernetesバージョン1.32に対するフルサポートが追加されました。アプリケーションをKubernetesにデプロイしている場合は、接続中クラスターを最新バージョンにアップグレードすることで、Kubernetes 1.32が提供する機能をすべて活用できるようになります。\n\n[Kubernetesサポートポリシーとその他のサポートされているKubernetesバージョン](https://docs.gitlab.com/ee/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)の詳細については、ドキュメントをご覧ください。\n\n###  反射型XSSチェックのための動的解析機能を追加\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nGitLabの動的解析チームが、[CWE-79](https://cwe.mitre.org/data/definitions/79.html)に対応する新しいチェック機能を導入しました。これにより、DASTスキャナーは反射型XSS（クロスサイトスクリプティング）攻撃を検出できるようになりました。\n\n反射型XSSのチェック機能はデフォルトで有効になっています。このチェックを無効にするには、設定ファイルに`DAST_FF_XSS_ATTACK: false`を追加してください。ご質問やフィードバックがある場合は、[イシュー525861](https://gitlab.com/gitlab-org/gitlab/-/issues/525861)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dast/browser/checks/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/525861)\n\n### Python対応の静的到達性解析のベータ版を提供開始\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nコンポジション解析チームは、Python向け静的到達性解析のベータ版をリリースしました。このベータ版では、安定性、可観測性の向上に焦点を当て、より簡単な設定で優れたユーザーエクスペリエンスを提供します。\n\n静的到達性解析は、ソフトウェアコンポジション解析（SCA）で得られる結果をより充実させてくれる機能です。静的到達性解析では、GitLabの高度なSASTを活用し、プロジェクトのソースコードをスキャンして使用中のオープンソースの依存関係を特定します。\n\nトリアージや修正に関する意思決定を行う上で、静的到達性機能によって生成されたデータを活用できます。また、静的到達可能性データを共通脆弱性評価システム（CVSS）スコアや悪用予測スコアリングシステム （EPSS)、悪用されている既知の脆弱性（KEV）と併用することで、より焦点を絞って脆弱性を確認することも可能です。\n\nこの機能に関するフィードバックをお待ちしています。ご質問やご意見のある方、またはGitLabチームとのやり取りをご希望の場合は、こちらの[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/535498)をご覧ください。\n\n### 依存関係リストと脆弱性レポートのエクスポートに関するメール配信\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nこれまで、依存関係リストや脆弱性レポートをエクスポートする場合、レポートをダウンロードするにはエクスポートが完了するまでページを開いたままにする必要がありました。\n\n今回の改善により、依存関係リストまたは脆弱性レポートのエクスポートが完了すると、ダウンロードリンクが記載されたメールで通知が届くようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_list/#download-the-dependency-list)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/513149)\n\n### CI/CDジョブの`source` 値を保存してフィルタリングする\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 17.11では、CI/CDジョブのソース属性を追跡することで、ユーザーがビルドアーティファクトのソースを確認できる新機能が導入されました。この機能は特に、セキュリティ対策やコンプライアンス対応を求められるワークフローで役立ちます。たとえば、組織はソフトウェアサプライチェーンのセキュリティ対策を実装したり、コンプライアンス目的でセキュリティスキャンの検証可能な証拠を要求したりできます。\n\nGitLabのジョブは、発生源を識別する以下の`source`値を保存して表示するようになりました。\n\n* スキャン実行ポリシー\n* パイプライン実行ポリシー\n* 通常のパイプライン\n\n`source`属性には、ビルド   \\> ジョブページの新しいフィルターオプション、ジョブAPI、またはアーティファクト検証用のIDトークンクレームを通じて確認できます。\n\nこの新機能により、次のことができるようになりました。\n\n* セキュリティスキャン結果の信頼性を検証\n* ソースの種類でジョブを絞り込むことで、ポリシーによって実行されたスキャンをすばやく特定\n* 新しいIDトークンクレームを使用した、アーティファクトの暗号化検証を実装\n* 適切な監査証跡により、コンプライアンス要件が満たされていることを確認\n\nセキュリティチームやコンプライアンスチームは、この機能を活用して以下を行えます。\n\n* ジョブページの新しいフィルターを使用して、ポリシーによって実行されたジョブのみを表示\n* ジョブAPIの`source`フィールドにアクセスしてタスクを自動化\n* 新しいIDトークンクレームを使用して、アーティファクトの検証を実装\n  * `job_source`：ジョブの発生源を識別します\n  * `job_policy_ref_uri`：ポリシーファイルを指します（ポリシー定義のジョブの場合）\n  * `job_policy_ref_sha`：ポリシーのgitコミットSHAを含みます\n\n[ドキュメント](https://docs.gitlab.com/api/jobs/#view-the-source-of-a-job)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11796)\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/scan_execution_policy_job_source_filter.png\">\n\n### コンプライアンスフレームワークの作成時にプロジェクトを割り当て可能に\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nこれまでは、コンプライアンスフレームワークを作成した後、コンプライアンスセンターのプロジェクトタブに移動しないと、新しいコンプライアンスフレームワークをプロジェクトに割り当てることができませんでした。このプロセスは、グループで新しいフレームワークを作成する際に余計な混乱を生む原因となっていました。\n\nGitLab 17.11では、コンプライアンスフレームワークを作成するプロセスに新しい手順が追加され、作成前に複数のプロジェクトをコンプライアンスフレームワークに割り当てられるようになりました。\n\nこの新機能により以下が実現します。\n\n* コンプライアンスフレームワークのスムーズな作成\n* コンプライアンスフレームワークがグループ内のプロジェクトと連携し、グループ全体のコンプライアンス遵守状況を監視・管理する仕組みについての理解を深めるガイダンスを提供\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_frameworks/#apply-a-compliance-framework-to-a-project)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/500520)\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/provide_option_to_add_projects_in_compliance_creation_workflow.png\">\n\n### サービスアカウント管理画面でのトークン統計表示\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nサービスアカウントのトークン管理インターフェイスに、トークンの状況を一目で把握できる便利な統計ダッシュボードが追加されました。この機能は、トークンの状態を評価し、注意が必要なトークンを特定するのに役立ちます。統計ダッシュボードには、次の4つの主要なメトリクスが含まれます。\n\n\\- 有効なトークン：現在使用中のトークンの総数を表示します\n\\- 2週間以内に期限が切れるトークン：今後2週間で期限切れとなるトークンを特定します\n\\- 取り消したトークン：手動で取り消されたトークンを追跡します\n\\- 期限切れトークン：以前に期限切れとなったトークンを監視します\n\nこの場を借りて、コントリビュートしてくれた[Chaitanya Sonwane](https://gitlab.com/chaitanyason9)さんに感謝します！![Token statistics for service account management][image6]\n\n[ドキュメント](https://docs.gitlab.com/user/profile/service_accounts/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/520472)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/expiring_token_cards.png\">\n\n### GitLab Duo Chatとコード提案でLlama 3モデルが一般提供開始\n\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nLlama 3モデルがGitlab Duo Self-Hostedで一般提供され、GitLab Duo Chatとコード提案をサポートできるようになりました。\n\nこれらのモデルを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/#supported-models)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15678)\n\n### 管理者エリアでプレースホルダーユーザーをフィルタリング可能に\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nこれまで、インポート中に作成されたプレースホルダーユーザーは、管理者エリアのユーザーページで明確に区別されず、通常のユーザーと混在して表示されていました。\n\n本リリースから、管理者は管理者エリアのユーザーページの検索ボックスからプレースホルダーアカウントを絞り込めるようになりました。これを行うには、ドロップダウンリストで`タイプ`を選択し、`プレースホルダー`を選択します。\n\n[ドキュメント](https://docs.gitlab.com/administration/admin_area/#administering-users)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/521974)\n\n###  グループの使用量割り当てにプレースホルダーユーザー制限を表示\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab.comへのインポートの場合、プレースホルダーユーザーはトップレベルグループごとに制限されています。これらの制限は、GitLabライセンスとシート数によって異なります。 本リリースから、トップレベルグループのプレースホルダーユーザーの使用状況と制限をUIで確認できるようになりました。\n以下の手順で現在の使用状況と制限を表示できます。\n\n1. 左側のサイドバーで、「Search or go to...」を選択してグループを検索します。このグループはトップレベルである必要があります。\n2. 設定 \\> 使用量割り当てを選択します。\n\n3. 「インポート」タブを選択します。\n\n[ドキュメント](https://docs.gitlab.com/user/project/import/#placeholder-user-limits)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/486691)\n\n### GLQLビューで最後のコメントを列として表示可能に\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nGLQLビューで、イシューまたはマージリクエストの最後のコメントを列として表示できるようになりました。GLQLクエリにlastCommentをフィールドとして含めることで、作業中の画面から移動せずに最新の更新を確認できます。\n\nこれまでは、最後のコメントを確認するために各イシューまたはマージリクエストを個別に開く必要があり、時間がかかる上に、進捗状況の全体像をすばやく把握することが困難でした。この改善により、進行中の会話やステータス更新が一目でわかるようになり、チームの作業効率向上に役立ちます。\n\nこの機能強化ならびにGLQLビュー全般に関するフィードバックは、[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509791)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/glql/fields/#last-comment)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/512154)\n\n### GitLab Pages用のNuxtプロジェクトテンプレートが登場\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nGitLabは、最も人気のある静的サイトジェネレーター（SSG）のテンプレートを提供していますが、この度、Vue.js上に構築された強力なフレームワークであるNuxtを使用したGitLab Pagesサイトを作成できるようになりました。Nuxtは、設定の手間を減らしながらモダンで高性能なWebアプリケーションをビルドしたいチームにとって特に有用です。\n\nこの新機能により、初期のセットアップと設定に時間をかけることなく、CI/CDパイプラインと最新の開発体験を組み込んだPagesサイトをすばやく起動するオプションが増えました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/pages/getting_started/pages_new_project_template/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/461603)\n\n### インポートされたファイルをコード提案のコンテキストとして使用可能に\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nGitLab Duoコード提案で、IDEにインポートされたファイルをコンテキストとして活用できるようになり、コード提案の品質が進化しました。インポートされたファイルはプロジェクトに関する追加のコンテキストを提供し、より適切な提案を可能にします。現在、インポートファイルのコンテキストは、JavaScriptファイルとTypeScriptファイルに対応しています。\n\n### GitLab Runner 17.11\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nこのたび、GitLab Runner 17.11もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドのエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n新機能：\n\n* [GitLab RunnerのWindows実行可能ファイルにコード署名を追加](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2483)\n\nバグ修正：\n\n* [GitLab Runner 17.10.0でGit設定をクリーニングするとエラーが発生する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38681)\n* [`FF_DISABLE_UMASK_FOR_KUBERNETES_EXECUTOR`フラグが`umask`コマンドを無効にしない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38382)\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/17-11-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner/)\n\n### プロジェクトにおけるRunner管理の改善\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nプロジェクトでRunnerをより効率的に管理できるようになりました。Runnerは、従来の2列のビューではなく、1列のレイアウトで表示され、それぞれが独自のリストとして整理されるようになりました。\n\nこの構成の改善により、Runnerの検索と管理が簡素化され、割り当てられたプロジェクトの一覧、Runnerマネージャー、およびRunnerが実行したジョブなどの新機能が追加されました。GitLab 18.0で計画されているその他のRunner管理の改善については、[イシュー33803](https://gitlab.com/gitlab-org/gitlab/-/issues/33803)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/ci/runners/runners_scope/#project-runners)\n[マージリクエスト](https://release-17-11.about.gitlab-review.app/releases/2025/04/17/gitlab-17-11-released/%5B%22https://gitlab.com/gitlab-org/gitlab/-/merge_requests/185232%22,%20%22https://gitlab.com/gitlab-org/gitlab/-/merge_requests/186963%22%5D)\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/runner-project-redesign.png\">\n\n### スイッチボードで複数のIDプロバイダ（IdP）を使用したSAMLシングルサインオンに対応\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: -\n\nGitLab Dedicatedインスタンスにおいて、最大10個のIDプロバイダ（IdP）を使ったSAMLシングルサインオン（SSO）の設定が可能に\nなりました。\n\nGitLab Dedicatedインスタンスで利用可能なすべてのSAML設定オプションは、個々のIdPごとに設定できます。\n\n以前に複数のIdPを設定していた場合も、すべての既存SAML設定をスイッチボードで直接表示および編集できるようになりました。\n\n![Configure SAML single sign-on with multiple identity providers in Switchboard][image8]\n\n[ドキュメント](https://docs.gitlab.com/administration/dedicated/configure_instance/saml/)\n[Webページ](https://release-17-11.about.gitlab-review.app/releases/2025/04/17/gitlab-17-11-released/%5B%22https://about.gitlab.com/direction/platforms/dedicated/#theme-feature-parity%22%5D)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/switchboard-multiple-idp.png\">\n\n### イベントデータの共有をデプロイ前に無効にできる機能を追加\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 18.0では、GitLab Self-ManagedおよびGitLab Dedicatedインスタンスからイベントレベルの製品使用状況データの収集を有効にする予定です。集計データとは異なり、イベントレベルのデータを収集することでより詳細な利用状況を把握できるようになります。こうしたデータは、GitLabがプラットフォーム上のユーザーエクスペリエンスを向上させ、機能活用を促進させるのに役立ちます。\n\nGitLab 17.11から、上記のイベントデータ収集が始まる前に、あらかじめその機能を無効に設定することが可能になりました。オプトアウト方法の詳細については、ドキュメントを参照してください。\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/event_data/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/510333)\n\n### シークレットプッシュ保護とパイプラインシークレット検出のルールカバレッジを拡大\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nGitLabシークレット検出機能が大幅に更新され、17件の新しいシークレットプッシュ保護ルールと12件の新しいパイプラインシークレット検出ルールが追加されました。また、既存のルールの一部も更新され、検出精度の向上と誤検知の削減が図られています。詳細については、[変更履歴](https://gitlab.com/gitlab-org/security-products/secret-detection/secret-detection-rules/-/blob/main/CHANGELOG.md#v090)のv0.9.0を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/secret_detection/detected_secrets)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/534106)\n\n### プロジェクト依存関係リストをCycloneDX形式でエクスポート可能に\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\n多くの組織は現在、規制要件を満たし、ソフトウェアサプライチェーンのセキュリティをさらに強化するために、ソフトウェア部品表（SBOM）が求められるようになりました。以前は、GitLabでは依存関係リストのエクスポート形式がJSONもしくはCSVに限られていましたが、今回から業界標準のCycloneDX形式でエクスポートできるようなり、SBOMの生成が可能になりました。\nSBOMをCycloneDX形式で依存関係リストから直接ダウンロードするには、**エクスポート** \\> **CycloneDX（JSON）としてエクスポートする**を選択します。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_list/#download-the-dependency-list)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/524733)\n\n### 依存関係リストをCSV形式でエクスポート可能に\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nこれまで、GitLabから依存関係リストをCSVファイルとしてエクスポートすることはできませんでした。本リリースから新機能として、依存関係リストをダウンロードする際にCSVオプションを選択して、CSV形式でリストをエクスポートできるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_list/#download-the-dependency-list)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/435843)\n\n### 「ツールフィルター」が「スキャナーフィルター」と「レポートタイプフィルター」に置き換え\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nこれまで、脆弱性レポートの**ツール**検索フィルタでは、スキャナーのタイプ（ESLintやGemnasiumなど）とレポートのタイプ（SASTやコンテナスキャンなど）が単一のグループとして扱われ、個別に指定することができませんでした。\n\n今回、より効率的に適切なツールを検索できるよう、**ツール**フィルターを**スキャナー**フィルターと**レポートタイプ**フィルターに分けました。これにより、スキャナーとレポートタイプを別々に指定できるようになり、より細かく検索条件を設定できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerability_report/#report-type-filter)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/503371)\n\n### アクセストークンの並べ替えオプションを強化\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nUIとAPIにアクセストークンの並べ替えオプションが追加されました。これらの並べ替えオプションは、GitLabの既存のトークン管理機能を補完し、アクセストークン管理の自由度を高めるとともに、アクセストークンのセキュリティ維持にも役立ちます。新しい並べ替えオプションには次のものがあります。\n\n* 有効期限順（昇順）：最も早く期限が切れるトークンから表示\n* 有効期限順（降順）：有効期限までの期間が最も長いトークンから表示\n* 最終使用日順（昇順）：最近使用されていないトークンから表示\n* 最終使用日順（降順）：最近使用されたトークンから表示\n\n[ドキュメント](https://docs.gitlab.com/user/profile/personal_access_tokens/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/519716)\n\n### Geo - 新しいレプリケーションビューの導入\n\nSaaS: -\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nGeoのレプリケーションビューが、新しい見た目と使いやすさに生まれ変わりました。新しいデザインは、GitLab全体と統一感を持たせつつ、Geoセカンダリサイトの同期と検証ステータスを確認しやすい、より効率化されたインターフェイスを実現しています。さらに新機能として、各レプリケーション項目をクリックすると詳細画面が表示されるようになり、プライマリおよびセカンダリのチェックサム、エラーの詳細など、多くの情報が確認できるようになりました。これにより、Geoの同期に関する問題のトラブルシューティングがはるかに簡単になります。\n\n[ドキュメント](https://docs.gitlab.com/administration/geo/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509349)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/410401)\n\u003Cimg src=\"https://about.gitlab.com/images/17_11/geo_new_replicables_view.png\">\n\n### GitLab Duo ChatがAnthropicのClaude Sonnet 3.7を採用\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nGitLab Duo Chatのベースモデルが、AnthropicのClaude 3.5 SonnetからClaude Sonnet 3.7に更新されました。これにより、ほとんどの質問は新モデルで処理されます。\n\nClaude 3.7 Sonnetは、コーディングと推論機能が大幅に強化されており、コードの説明、コードの生成、テキストデータの処理、複雑なDevSecOps関連の質問に対して、より精度の高い回答が可能になりました。これらの分野では、より詳細で正確な応答が得られます。\n\nこのアップグレードはChat機能全体に適用され、すべてのChat機能で一貫した品質向上が図られています。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo_chat/examples/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/521034)\n\n### Linuxパッケージの改善\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 18.0では、PostgreSQLの最小サポートバージョンはバージョン16になります。この変更に備えて、[PostgreSQLクラスター](https://docs.gitlab.com/administration/postgresql/replication_and_failover/)を使用していないインスタンスでは、GitLab 17.11へのアップグレード時にPostgreSQLをバージョン16に自動的にアップグレードする仕組みが導入されます。\n\n[PostgreSQLクラスター](https://docs.gitlab.com/administration/postgresql/replication_and_failover/)を使用している場合、または[この自動アップグレードを希望しない](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades)場合は、[手動でPostgreSQL 16にアップグレード](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)してからGitLab 18.0にアップグレードする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/omnibus/)\n[イシュー](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8504)\n\n### GitLab Duo Chatで複数のチャットを管理可能に\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nGitLab Duo Chatを使用した複数のチャットが、GitLab Self-ManagedインスタンスのWeb UIで利用できるようになりました。新しいチャットの作成、履歴の閲覧、およびチャット間の切り替えをコンテキストを失うことなく行えます。\n\nプライバシー保護のために、30日間アクティビティのないチャットは自動的に削除されます。また、チャットはいつでも手動で削除できます。GitLab Self-Managedをご利用の場合、管理者は会話の保持時間をさらに短縮することも可能です。\n\n[イシュー526013](https://gitlab.com/gitlab-org/gitlab/-/issues/526013)で、ご意見をお聞かせください。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo_chat/#have-multiple-conversations-with-chat)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16108)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/h9ooN05cNbw?si=J6UGE_T5YIc6HL_P\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### GitLab Duo Self-Hostedで開いているファイルをコード提案のコンテキストとして使用可能に\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nGitlab Duo Self-Hostedでは、コード提案を使用するときに、[IDEのタブで開いているファイル](https://docs.gitlab.com/user/project/repository/code_suggestions/#using-open-files-as-context)をコンテキストとして使用できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/repository/code_suggestions/#using-open-files-as-context)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16611)\n\n### GitLab Duo Self-HostedでAI搭載機能ごとに個別のモデルを選択可能に\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nGitLab Duo Self-Hostedで、GitLab Self-Managedインスタンスの各GitLab Duo機能とサブ機能に対して、サポートされている個々のモデルを選択して設定できるようになりました。\n\nフィードバックは、[イシュー524175](https://gitlab.com/gitlab-org/gitlab/-/issues/524175)にお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/configure_duo_features/#configure-the-feature-to-use-a-self-hosted-model)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/17099)\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n17.11で提供されたすべてのバグ修正、パフォーマンスの強化、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=17.11)\n* [パフォーマンスの改善](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=bug%3A%3Aperformance&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=17.11)\n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.11)\n\n\u003Cbr>\n\u003Cbr>\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n* パイプライン実行ポリシーの「inject\\_ci」戦略が「inject\\_policy」に変更\n* コンプライアンス基準適合ダッシュボードがコンプライアンス状況ダッシュボードに刷新\n* クライアント認証情報を使用しないOAuth ROPCグラント方式を非推奨化\n\n\u003Cbr>\n\u003Cbr>\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n### GitLab 17.11へのアップグレードに関する重要なお知らせ\n\nGitLab 17.8では、新しい暗号化フレームワーク（GitLab 17.9から導入）に対応するため、3つの新しいシークレットが追加されました。\n\nマルチノード構成をご利用の場合は、[こちらのドキュメントページ（GitLab 17.11.0 changes）](https://docs.gitlab.com/update/versions/gitlab_17_changes/#17110)に記載されている、お使いの環境に適した手順に従ってください。\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ワークフロー](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://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/)でお試しいただけます。\n\n\u003Cbr>\n\u003Cbr>\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\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/)\n",[721,763,701,110],"2025-04-22",{"slug":1610,"featured":92,"template":681},"gitlab-17-11-release","content:ja-jp:blog:gitlab-17-11-release.yml","Gitlab 17 11 Release","ja-jp/blog/gitlab-17-11-release.yml","ja-jp/blog/gitlab-17-11-release",{"_path":1616,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1617,"content":1622,"config":1627,"_id":1629,"_type":16,"title":1630,"_source":17,"_file":1631,"_stem":1632,"_extension":20},"/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"title":1618,"description":1619,"ogTitle":1618,"ogDescription":1619,"noIndex":6,"ogImage":1221,"ogUrl":1620,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1620,"schema":1621},"GitLab Duo with Amazon Q（AWS向けに最適化された自律型AI）の一般提供を開始","AIを搭載した包括的なDevSecOpsプラットフォームと業界最高水準のクラウドコンピューティング機能の組み合わせにより、開発サイクルの高速化、自動化の推進、そしてコード品質の向上を可能にします。","https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo with Amazon Q（AWS向けに最適化された自律型AI）の一般提供を開始\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilio Salvador\"}],\n        \"datePublished\": \"2025-04-17\",\n      }",{"title":1618,"description":1619,"authors":1623,"heroImage":1221,"date":1605,"body":1625,"category":787,"tags":1626,"updatedDate":1608},[1624],"Emilio Salvador","このたび、[GitLab Duo with Amazon Q](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)が一般公開されました。この新機能は、AWSユーザー向けにソフトウェア開発ライフサイクル全体にわたって自律型AIを提供するものです。GitLab UltimateをベースとしたGitLab Duo with Amazon Qには、コード補完、コードの説明、コード生成、Chat、脆弱性の説明および修正など、使い慣れた機能が多数搭載されており、これらすべてがAmazon Qによって強化されています。このソリューションは、Amazon Web Services（AWS）環境のGitLab Self-Managedでご利用いただけます。\n\nAmazon QのAIエージェントがGitLabのDevSecOpsプラットフォームに直接組み込まれているため、デベロッパーは慣れ親しんだ開発環境を維持しながら、強力なAI機能を活用できます。これにより、開発サイクルの高速化、手作業の削減、コード品質の向上をスムーズに実現できる環境が整いました。\n\n「GitLab Duo with Amazon Qの早期アクセスプログラムに参加したことで、開発ワークフローの変革の可能性を垣間見ることができました」と、Volkswagen Digital Solutions社でDevOpsエンジニアを務めるOsmar Alonso氏は述べています。「まだ初期段階にもかかわらず、自律型エージェントとの緊密な連携により、コードのコミットから本番環境までのプロセス全体を効率化できることが明らかになりました。このテクノロジーによって、チームがイノベーションに集中し、デジタルトランスフォーメーションを加速できることに大いに期待しています」\n\n## 自律型AIが複雑な顧客環境に登場\n\nGitLabとAWSは、自律型AIと安全かつ信頼性の高いクラウドインフラを組み合わせることで、セキュリティ、拡張性、信頼性を備えたソリューションを実現しました。これにより、複雑な環境を運用するお客様でも、以下のようなメリットを実感していただけます。\n\n__シームレスな開発を実現する一元化された開発環境__\n\nデベロッパーは、GitLab Duo Chatインターフェイスを介して、普段使用しているIDEやGitLab WebインターフェイスからAmazon Qを利用できます。これにより、複数のツールの行き来がなくなり頭の切り替えが不要になるため、作業中のプロジェクトに集中しやすくなります。\n\n__ソフトウェア開発ライフサイクル全体に対応した統合ソリューション__\n\nコード提案や最適化は、AWS特有のパターンや手法を活用しながら実行されます。また、テストツールはAWSサービス間の相互作用や依存関係を適切に把握します。すべてのステージを通じて共通のデータストアを用いることで、AIエージェントに必要なコンテキストが提供され、関連する操作に対する完全な可視性とトレーサビリティが確保されます。\n\n__エンタープライズレベルのガードレールによる安全な開発__\n\n開発プラットフォームにはエンドツーエンドのセキュリティとコンプライアンスが直接組み込まれており、開発速度を損なうことなくリスクを軽減するためのガードレールが備わっています。この安全に優れたソフトウェア開発アプローチは、AIエージェントを通じて透明性と可監査性を確保しつつ、AWSのセキュリティサービスやコンプライアンスフレームワークとスムーズに連携します。\n\n## GitLab Duo with Amazon Qの始め方\n\nチームで自律型AIを活用し、より迅速かつ安全にソフトウェアを開発するための5つのユースケースをご紹介します。\n\n1. **機能開発の加速** \n\nイシューの説明生成、既存のコードベースに基づいた実装計画の立案、レビュー可能なマージリクエストの作成など、一連の作業を自動化します。これにより、社内の開発基準との整合性を維持しながら、機能リリースの加速化を実現します。\n\n2. **レガシーアプリケーションのモダナイゼーション**\n\n古いJavaコードベースを解析し、包括的なアップグレードプランを作成します。さらに、必要なコード変更をすべて含んだマージリクエストを自動生成します。これにより、Javaアップグレードの所要時間を大幅に短縮しながら、すべてのコード変更を明確に追跡できる監査証跡も提供します。なお、今後のリリースで、.NETやその他の言語のサポートも予定されています。\n\n3. **品質保証の強化**\n\nコードを解析し、アプリケーションのロジックやAWSサービスとの連携を正確に理解した上で、包括的な単体テストを自動生成します。これにより、テストカバレッジの拡大、手作業によるテスト作成の負担軽減、そしてアプリケーション全体におけるテスト品質の一貫性確保を実現します。\n\n4. **コードレビューの最適化**\n\nコード変更に対してフィードバックをインラインで提供し、開発標準に基づいた改善提案を行うとともに、セキュリティやパフォーマンスに関する重要な考慮点を明示します。これにより、コードレビューのサイクルを短縮し、より高品質なコードのマージとデプロイを実現できます。\n\n5. **脆弱性の修正**\n\n検出された脆弱性をわかりやすく詳細に説明し、推奨されるコード変更に基づいてワンクリックで修正できる機能を備えています。これにより、脆弱性の検出から修正までの時間を大幅に短縮できます。\n\n以下の動画で、GitLab Duo with Amazon Qを実際に使用する様子をご覧いただけます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Technical Demo: GitLab Duo with Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> #### GitLab Duo with Amazon Qのメリットを今すぐ体験\n> AIを搭載したGitLabの統合型DevSecOpsプラットフォームにAmazon Qの高度なAI機能を組み合わせることで、AWSユーザーにソフトウェアの構築およびデプロイのプロセスを革新するソリューションを提供します。GitLab Duo with Amazon Qの詳細については、[お近くで開催されるAWSサミット](https://about.gitlab.com/ja-jp/events/aws-summits/)にご参加いただくか、[GitLab担当者までお気軽にお問い合わせ](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/#form)ください。",[721,904,920,701,678,700],{"slug":1628,"featured":92,"template":681},"gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws","content:ja-jp:blog:gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws.yml","Gitlab Duo With Amazon Q Agentic Ai Optimized For Aws","ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws.yml","ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"_path":1634,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1635,"content":1641,"config":1647,"_id":1649,"_type":16,"title":1650,"_source":17,"_file":1651,"_stem":1652,"_extension":20},"/ja-jp/blog/journey-through-gits-20-year-history",{"title":1636,"description":1637,"ogTitle":1636,"ogDescription":1637,"noIndex":6,"ogImage":1638,"ogUrl":1639,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1639,"schema":1640},"20年にわたるGitの歴史をたどる","初めて行われたコミット、初期リリースのユニークな特徴、そしてgit-push(1)のデフォルト動作の変更によって生じた混乱について、一緒に振り返っていきましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","https://about.gitlab.com/blog/journey-through-gits-20-year-history","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"20年にわたるGitの歴史をたどる\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-14\",\n      }",{"title":1636,"description":1637,"authors":1642,"heroImage":1638,"date":1644,"body":1645,"category":962,"tags":1646},[1643],"Patrick Steinhardt","2025-04-14","Gitプロジェクトはちょうど20周年を迎えました。20年の間にさまざまなことがありました。Gitの概念的なデザインは、その登場以来大きく変わってはいないものの、ユーザーによるGitの操作方法は大きく変化しました。GitLabは、この重要な技術をベースにサービスを構築し、その歴史の一部であることを誇りに思っています。\n\nそれでは、Gitの歴史をたどり、長年にわたってどのように進化を遂げてきたかを一緒に見ていきましょう。\n\n## 初めてのコミット\n\n初めてのコミットは、2005年4月7日にLinuxカーネルの生みの親であるLinus Torvalds氏によって行われました。`e83c5163316 (Initial revision of \"git\", the information manager from hell, 2005-04-07)`\n\nご覧のとおり、このコミットには多くのファイルは含まれていませんでした。\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nビルドインフラストラクチャに加え、最初のコミットでは以下の7つのトップレベルコマンドが提供されていました。\n\n- `init-db`：新たなGitリポジトリを初期化\n- `update-cache`：インデックスにファイルを追加\n- `write-tree`：インデックスの内容を取得し、それをもとに新たなツリーを作成\n- `read-tree`：ツリーオブジェクトを読み込む\n- `commit-tree`：ツリーからコミットを作成\n- `cat-file`：特定のオブジェクトを一時ファイルに読み込む\n\nなお、この時点では、`git`コマンド自体存在していませんでした。代わりに、上記のコマンドを直接実行する必要がありました。\n\nでは、試しにリポジトリを新規作成してみましょう。\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nみなさんにはまったくなじみがないと思います。`.git`ディレクトリではなく、`.dircache`ディレクトリが使用されていました。では、プライベートストレージ領域はどこでしょうか？\n\n初期のGitのデザインでは、オブジェクトストレージ領域は「共有」と「プライベート」に分かれていました。このオブジェクトストレージ領域には、コミットやblobなども含め、あらゆるGitオブジェクトが格納されていました。\n\n`init-db`は、デフォルトではプライベートオブジェクトストレージ領域を作成します。これは、領域の作成先の管理ディレクトリ専用として使用されていました。一方、同じオブジェクトを二重に保存する必要がないように、「共有」オブジェクトストレージ領域を使用して、複数の管理ディレクトリ間でオブジェクトの内容を共有していました。\n\n### コミットを作成する\n\nリポジトリの作成後は、どのようにコミットを作成していたのでしょうか？作成方法は、現在利用可能な`git add . && git commit`ほどシンプルではありませんでした。その代わりに、以下の方法で行っていました。\n\n1. 追加するファイルごとに`update-cache`を呼び出してインデックスを更新する。\n1. `write-tree`を呼び出して新規ツリーを書き込む。インデックスに追加済みのすべての内容をもとに作成される。\n1. 環境変数を設定して、Gitにコミッターの情報を伝える。\n1. `commit-tree`を呼び出して、コミットオブジェクトを書き込む。\n\nそれでは、リポジトリにコミットを作成してみましょう。\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\n人間工学的な方法とは言えないものの、コミットは作成されます。それでは、生成されたコミットを見てみましょう。\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\n注目していただきたいのは、`cat-file`は内容を直接表示せず、まずは一時ファイルに書き出す点です。しかしながら、ファイルの内容は、まさに現代的なコミットと同じように見えます。\n\n### 変更を加える\n\nファイルの作成後、どのようにステータスを確認していたのでしょうか？おそらくお察しのとおりで、`show-diff`を使用していました。\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\n驚くべきことに、すでに`show-diff`では、変更されたファイルの新旧の状態を比較して差分を取得していました。しかも面白いことに、GitではこれをUNIXのdiff(1)ツールを使用するという簡単な方法で実現していました。\n\nつまり、これらはすべて必要最低限の機能しか備えていなかったものの、履歴の追跡に必要なすべての役割を果たしていました。以下のように制限は多数ありました。\n\n- あるコミットから別のコミットへ簡単に切り替える方法がなかった。\n- ログを表示できなかった。\n- ブランチやtag、また参照すら存在しなかった。そのため、ユーザーは手動でオブジェクトIDを追跡しなければならなかった。\n- 2つのリポジトリを相互に同期させる方法がなかった。代わりに、ユーザーがrsync(1)を使用して、`.dircache`ディレクトリを同期させる必要があった。\n- マージの実行方法がなかった。\n\n## Git 0.99\n\nGitの最初のテストリリースは、バージョン0.99でした。バージョン0.99は、最初のコミットからわずか2か月後にリリースされたものの、すでに1,076件のコミットが追加されていました。約50人のデベロッパーが開発に携わっており、最も頻繁にコミットを行っていたのはTorvalds氏自身でした。トーバルズ氏に続く勢いで、コミット件数の多かったコミッターは、現在メンテナーを務めている濱野純氏でした。\n\n最初のコミット以降、多数の変更が加えられました。\n\n- Gitは参照を使って複数の開発ブランチを追跡するようになりました。その結果、大抵の場合、手作業でオブジェクトIDを追跡せずに済むようになりました。\n- 新たにリモートプロトコルが導入され、2つのリポジトリ間で相互にオブジェクトを交換できるようになりました。\n- `.dircache`ディレクトリの名前が`.git`に変更されました。\n- 個々のファイルを相互にマージできるようになりました。\n\nただし、最も重要かつ顕著な変化は、トップレベルの`git`コマンドとそのサブコマンドが導入されたことでした。興味深いことに、「配管（plumbing）」コマンドと「磁器（porcelain）」コマンドの概念が導入されたのも、このリリースです。\n\n- 「配管」ツールは、基盤となるGitリポジトリにアクセスして低レベルな処理を行うコマンドです。\n- 「磁器」ツールは、「配管」コマンドをラップして、高レベルでよりユーザーフレンドリーなユーザーインターフェイスを提供するShellスクリプトです。\n\nGitには現在でもこの分け方は採用されており、[`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain)にも概説されています。しかしながら、「磁器」ツールの大半はShellスクリプトからC言語に書き直されたため、これらの2つのカテゴリ間の境界線はかなり曖昧になってきています。\n\n## Torvalds氏、メンテナーの役割を濱野氏に引き継ぐ\n\nTorvalds氏がGitに取り掛かった理由は、バージョン管理システムが好きだったためではなく、Linuxカーネル開発のためにBitKeeperの代替ツールを必要としていたためです。そのため、Gitのメンテナンスをずっと続けるつもりはなく、信頼できる人が現れるまで、メンテナーを務めようと考えていました。\n\nその条件に当てはまったのが、濱野純氏でした。濱野氏は、Torvalds氏が最初のコミットを行った約1週間後にGitの開発に参加しました。Git 0.99のリリース後にはすでに数百件のコミットを行っていました。そのため、2005年7月26日に、[Torvalds氏は濱野氏をGitプロジェクトの新たなメンテナーに任命しました](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/)。Torvalds氏は引き続きGitにコントリビュートしているものの、徐々にGitプロジェクトへの関わりは薄れていきました。これは、Linuxプロジェクトの責任者として多忙を極めているため、当然のことでした。\n\n現在でも、引き続き濱野氏がGitプロジェクトを率いています。\n\n## Git 1.0\n\n濱野氏は、2025年12月21日にGitの最初のメジャーリリースを行いました。興味深いことに、バージョン0.99から1.0の間には、34回もリリースが行われました（0.99.1～0.99.7、0.99.7a～0.99.7d、0.99.8～0.99.8g、0.99.9～0.99.9n）。\n\n0.99以降の特に重要なマイルストーンのひとつは、おそらく2つのツリーを相互にマージできる`git-merge(1)`コマンドの追加でしょう。それまでは基本的にファイルのマージを行う場合、ファイルごとにスクリプトを作成する必要があったことを考えると、非常に対照的です。\n\n### リモート\n\nもう1つの大きな変化は、リモートリポジトリの省略記法が導入されたことです。すでにGitからリモートリポジトリを操作することはできましたが、変更をフェッチする際に毎回、対象のリポジトリのURLを指定する必要がありました。通常は同じリモートリポジトリと何度もやり取りを行うため、これはユーザーにとってかなり使い勝手の悪い仕様でした。\n\n現在のremoteコマンドの仕組みはご存知だと思いますが、当時の仕組みはまだ大きく異なっていました。リモートリポジトリを管理するための`git-remote(1)`コマンドはまだ存在しておらず、リモートリポジトリの情報は`.git/config`ファイルに保存すらされていませんでした。実のところ、バージョン0.99.2でremoteコマンドが最初に導入された際、Gitにはconfigファイル自体*ありませんでした*。\n\n代わりに、`.git/branches`に直接ファイルを書き込んでリモートリポジトリの設定を行う必要がありました。今となってはあまり直感的な方法とは思えません。しかしながら、この仕組みは今でも動作します。\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nそれだけではなく、その直後にGitバージョン0.99.5でディレクトリ名が「remotes」に変更されたため、現在のGitクライアントではリモートリポジトリの設定方法が全部で3つあります。\n\nおそらく多くの方は、`.git/branches`も`.git/remotes`も使ったことがないと思います。これらはそれぞれ、2005年、および2011年以降、非推奨化されています。また、最終的にこれらのディレクトリは、Git 3.0で削除される予定です。\n\n## Gitのブランディング\n\n2007年に、Gitの最初のロゴが作成されました。これは、単に3つの緑のプラス記号の上に3つの赤いマイナス記号が配置された構成（`git diff`の出力がどのように見えるかを表していた）だったため、ロゴと呼べるかどうかについては、議論の余地があります。\n\n![`git diff`の出力がどのように見えるかを表し、3つの緑のプラス記号の上に3つの赤いマイナス記号が配置されている](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nそれから少し経った2008年に、ウェブサイト[git-scm.com](https://git-scm.com)が公開されました。\n\n![2026年時点でのgit-scm.comのランディングページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\n2012年に、Scott Chacon氏とJason Long氏によって、Gitのウェブサイトは[リニューアル](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/)されました。ご覧のように現在の外観にかなり近くなりました。\n\n![2012年にリニューアルされたGitウェブサイト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\n再デザインされたウェブサイトには、Jason Long氏がデザインし、今でも使用されている新しい赤橙色のロゴが目立つように掲載されていました。\n\n![Gitロゴ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nGit 1.0のリリース時点で、すでに現在のGitとかなり同じようになってきたため、ここでGitの歴史をたどる旅の歩みをGit 2.0まで進めます。Git 1.0の約10年後にリリースされたこのバージョンは、中央ワークフローに後方互換性のない変更を意図的に含めた最初のリリースでした。\n\n### `git-push(1)`のデフォルトの動作\n\nこのリリースで最も混乱を招いたのは、間違いなく`git-push(1)`のデフォルトの動作が変更されたことです。\n\nリモートリポジトリへのプッシュ時に何をプッシュするかを具体的に指定しなかった場合、Gitは以下のいずれかのアクションを取る可能性がありました。\n\n- Gitは何も実行せず、何をプッシュするか具体的な情報をユーザーに要求する。\n- その時点でチェックアウトされているブランチをプッシュする。\n- その時点でチェックアウトされているブランチをプッシュする（ただし、リモート側に対応するブランチがあることを確認できた場合に限る）。\n- リモート側に対応するブランチが存在する全ブランチをプッシュする。\n\n現在のGitは、いわゆる「シンプル」な手法を採用しており、上記の3番目のアクションを行います。しかしながら、Git 2.0より前のバージョンにおけるデフォルトの動作は、「マッチング」手法を使用した上記の最後のアクションでした。\n\n「マッチング」手法は、現在採用されている手法と比べて、はるかにリスクがありました。プッシュする前に毎回、リモート側に対応するブランチがあるすべてのローカルブランチをプッシュしても問題がないか確認する必要がありました。そうしないと、意図せずに変更がプッシュされてしまう可能性がありました。そこでリスクを軽減し、Gitを使い始めたばかりのユーザーにとって使い勝手をよくするために「シンプル」手法が採用されました。\n\n### `git-add(1)`\n\nもう1つの大きな変化は、削除された追跡済みファイルに対する`git-add(1)`のデフォルトの動作が変更されたことです。Git 2.0より前のバージョンでは、`git-add(1)`は削除済みのファイルを自動的にステージングしませんでした。そのため、コミットに含めるには、`git-rm(1)`を使用して削除済みのファイルを1つずつ手動で追加する必要がありました。Git 2.0ではこの動作が変更され、`git-add(1)`を実行すると、削除済みのファイルもインデックスに追加されるようになりました。\n\n## Gitコミュニティの業績を称えよう\n\nおそらくみなさんGitを日々活用しているかと思いますので、Gitの現在の仕組みについて細かくはここでは取り上げません。まだ活用していない方向けには、利用開始に役立つチュートリアルが多数用意されています。現在の仕組みについて説明する代わりに、Git誕生から20年経った今でも機能するように取り組んでくださったGitコミュニティの業績を称えたいと思います。\n\nGitは、その歴史の中で以下の実績を達成してきました。\n\n- Git 2.49のリリース時点での累計コミット件数、56,721件\n- 2,000人の個人のコントリビューターによるコントリビュート\n- 公開されたメジャーリリース件数、60件\n\nまた、Gitプロジェクトは[Google Summer of Code（GSOC）](https://summerofcode.withgoogle.com/)や[Outreachy](https://www.outreachy.org/)にも参加しており、新たなコントリビューターが着実に増えています。このような新たなコントリビューターのおかげで、Gitプロジェクトは長期的に健全な状態を保てます。\n\nこの場を借りて、すべてのコントリビューターに心からお礼申し上げます。みなさんのコントリビュートのおかげで、Gitが実現しました。\n\n## 今後の展開\n\nGitがバージョン管理システムの競争で事実上勝利を収めたと言っても、異論はほとんどないでしょう。Gitは大きな市場シェアを占めており、Git以外のバージョン管理システムを使用しているオープンソースプロジェクトはほとんどありません。そう考えると、Gitが多くのことを正しく成し遂げてきたことは明らかです。\n\nとは言っても、Gitの開発は完結したわけではなく、依存として多くの課題が残されています。その例が、以下のような技術的な課題です。\n- 古くなったコードベースのモダナイゼーション  \n- 拡大し続けるモノレポのサイズに合わせたスケーリング  \n- サイズの大きいバイナリファイルの処理の改善\n\nそれとは別に、以下のような社会的な課題もあります。\n- Gitの使いやすさの向上  \n- 長期にわたってプロジェクトの健全性を確保することを目的とした、Gitコミュニティの育成  \n\n取り組むべき作業は常にあります。次の20年もGitが素晴らしいバージョン管理システムであり続けられるよう、私たちGitLabもコントリビュートできることを誇りに思います。\n\n## Git関連のその他のリソース\n\n- [Gitの生みの親であるLinus Torvalds氏と20周年を祝う](https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n- [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)  \n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)",[825,966],{"slug":1648,"featured":92,"template":681},"journey-through-gits-20-year-history","content:ja-jp:blog:journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History","ja-jp/blog/journey-through-gits-20-year-history.yml","ja-jp/blog/journey-through-gits-20-year-history",{"_path":1654,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1655,"content":1661,"config":1667,"_id":1669,"_type":16,"title":1670,"_source":17,"_file":1671,"_stem":1672,"_extension":20},"/ja-jp/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance",{"title":1656,"description":1657,"ogTitle":1656,"ogDescription":1657,"noIndex":6,"ogImage":1658,"ogUrl":1659,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1659,"schema":1660},"GitLab Duo Workflowを使用してアプリケーションの品質保証を強化","自律型AIを使用してJavaアプリケーションに単体テストを追加する方法をステップ別にご説明します。動画チュートリアルもご覧いただけます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097617/Blog/Hero%20Images/Blog/Hero%20Images/Workflow%201800x945_2gQoQIbY9NvjLFpXtsxtXy_1750097616649.png","https://about.gitlab.com/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Workflowを使用してアプリケーションの品質保証を強化\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-04-10\",\n      }",{"title":1656,"description":1662,"authors":1663,"heroImage":1658,"date":1664,"body":1665,"category":787,"tags":1666},"自律型AIを使用してJavaアプリケーションに単体テストを追加する方法をステップ別にご説明します。動画チュートリアル（英語版）もご覧いただけます。",[783],"2025-04-10","テスト駆動設計、十分なコードカバレッジの確保、問題検出を通じてアプリケーションの品質を保証することは、顧客の信頼や組織の評判にとって非常に重要ですが、同時にそれは時間のかかる作業でもあります。最も包括的なDevSecOpsプラットフォーム上に構築された自律型AIである[GitLab\nDuo\nWorkflow](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)は、Javaアプリケーションに単体テストを追加するなどの開発作業を迅速に完了するよう支援します。このチュートリアルでは、こちらのサンプルの[Javaプロジェクト](https://gitlab.com/gitlab-da/playground/csaavedra/gdw/prodmgr-gdw)を使用しながら手順をご説明します。\n\n\n> GitLab Duo\nWorkflowは現在プライベートベータ版です。[ウェイトリスト](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)に登録して、ソフトウェアデリバリーライフサイクル（SDLC）全体のプロセスを理解するAIエージェントを活用すると何が実現できるのかをご確認ください。\n\n\n## プロジェクトをVS Codeで開く\n\n\n1. お使いのローカルマシンにクローンしたJavaプロジェクトをVisual Studio\nCodeで開きます。作業を始める前に、メインブランチやデフォルトブランチではなく、フィーチャーブランチにいることを確認してください。すでにマージリクエストの作業中であれば、対応するフィーチャーブランチが存在しているはずです。\n\n\n2.（このステップは任意です）。GitLab Duo\nWorkflowに単体テストを作成させたいJavaクラスを定義したファイルに移動します。そのファイルの内容を確認しておくことで、生成された単体テストがクラスのメンバーを正常にカバーしているかを後から確認できます。表示される内容は以下のとおりです。\n\n\n![GitLab Duo\nWorkflowに単体テストを作成させたいJavaクラスを定義するファイル](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097627482.png)\n\n\n**注意**：このチュートリアルは、VS CodeでGitLab Duo\nWorkflow拡張機能が有効になっていることを前提としています。そうでない場合は、[セットアップドキュメント](https://docs.gitlab.com/user/duo_workflow/#use-workflow-in-vs-code)を参照して有効化してください。\n\n\n3. VS Codeコマンドパレット[Ctrl + Shift + P]を開き、「GitLab Duo Workflow」と入力して、**GitLab:\nShow Duo Workflow**を選択して、GitLab Duo Workflowを起動します。次のようなタブが表示されます。\n\n\n![VS CodeでGitLab\nDuoワークフローを起動](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097627483.png)\n\n\n4.\n次に、デフォルトコンストラクター、オブジェクト作成の検証、およびProductクラスのプロパティの初期状態のテストを追加します。これを実行するには、GitLab\nDuo Workflowのテキストエリアに以下のプロンプトを入力します。\n\n\n```unset\n\nCreate unit tests for class defined in the Product.java file and store the\nunit tests in its own file titled ProductTest.java\n\n```\n\n\n![GitLab Duo\nWorkflowのプロンプトエリア](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097627484.png)\n\n\n5. GitLab Duo Workflowウィンドウの\n[**Start**（開始）]ボタンをクリックします。2つの新しいウィンドウが、画面中央と右側にそれぞれ表示されます。右側のウィンドウには、プロンプトで指定した目標を達成するために、GitLab\nDuo\nWorkflowが実行している分析内容が表示されます。中央のウィンドウには、作成された計画が表示されます。分析と計画の生成が終了すると、次のような出力が表示されるはずです。\n\n\n![GitLab Duo\nWorkflowによって生成された分析と計画](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097627486.png)\n\n\n6. 分析と計画を確認し、問題がなければ、ウィンドウの下部にある[**Approve plan**（計画を承認）]をクリックします。\n\n\n7. GitLab Duo Workflowは、承認された計画の実行を開始し、それに応じてプロジェクトに変更を加えます。\n\n\n8.\n計画の実行が終了すると、プロジェクトに新しいディレクトリ`src/test/java/csaa/jspring/ProductManager`が表示され、`ProductTest.java`という名前の新しいファイルが表示されます。このファイルには、`Product.java`クラスに対するすべての単体テストが含まれています。\n\n\n![新しいファイル名`ProductTest.java`のプロジェクト内の新しいディレクトリ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097627488.png)\n\n\n9.\n新しく作成されたファイル`ProductTest.java`に移動すると、いくつかのインポートステートメントが赤い下線で強調されており、インポートエラーが発生していることがわかります。\n\n\n![`ProductTest.java`には、インポートステートメントとエラーインジケータが赤で表示されます](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097627489.png)\n\n\nGitLab Duo Workflowを使用して、これらのエラーを修正してみましょう。\n\n\n**注意**：最初のプロンプトでGitLab Duo\nWorkflowに`pom.xml`ファイルを適宜更新するように依頼することもできます。今回はそうしなかったので、新しいワークフローでこれらのエラーを修正しましょう。\n\n\n## GitLab Duo Workflowを起動して、生成されたコードのエラーを修正する\n\n\n10. 画面右側の分析ウィンドウの下部にある[**New workflow**（新規ワークフロー）]\nボタンをクリックして、新しいワークフローを開始します。\n\n\n![新規ワークフローボタン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097627491.png)\n\n\n11. プロンプトテキストエリアに次のように入力します。\n\n\n```unset\n\nThe file ProductTest.java has an error “The import org.junit cannot be\nresolved”. Please fix it\n\n```\n\n\n12. 提案された計画を承認すると、GitLab Duo\nWorkflowは現在の`pom.xml`ファイルを読み取って分析を開始します。また、その後、古いJUnitの依存関係を削除し、正しい依存関係とバージョンを追加します。最後に、`ProductTest.java`ファイルを読み込み、依存性エラーをすべてクリアします。\n\n\n![GitLab Duo\nWorkflowは、pom.xmlを読み取って分析を実行します](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097627492.png)\n\n\n## チュートリアルを見る\n\n\nこの計画の実行を通じて、GitLab Duo\nWorkflowはプロンプトでリクエストされた内容を達成するために、プロジェクトを効果的に更新しています。これにより、時間と労力が節約され、生産性も向上するため、デベロッパーは組織のイノベーションと価値創造により多くの時間を費やせるようになります。\n\n\n上記の動作を確認したい場合は、次の動画をご覧ください。（英語版のみ視聴可能）\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Tuj7TgqY81Q?si=RReuL1pUsLafvAzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n[GitLab Duo\nWorkflowプライベートベータ版のウェイトリスト](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)にサインアップして、SDLC全体のプロセスを理解するAIエージェントを活用すると何が実現できるのかをご確認ください。\n\n\n## GitLab Duo Workflowと自律型AIの関連記事\n\n\n- [GitLab Duo\nWorkflow：自律型AIに対するエンタープライズレベルの可視性と管理](https://about.gitlab.com/ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n\n- [GitLab Duo Workflowドキュメント](https://docs.gitlab.com/user/duo_workflow/)\n\n- [GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)\n\n- [自律型AI：デベロッパーの可能性を解き放つ（The\nSource）](https://about.gitlab.com/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)\n",[721,904,676,701,678],{"slug":1668,"featured":6,"template":681},"use-gitlab-duo-workflow-to-improve-application-quality-assurance","content:ja-jp:blog:use-gitlab-duo-workflow-to-improve-application-quality-assurance.yml","Use Gitlab Duo Workflow To Improve Application Quality Assurance","ja-jp/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance.yml","ja-jp/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance",{"_path":1674,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1675,"content":1681,"config":1686,"_id":1688,"_type":16,"title":1689,"_source":17,"_file":1690,"_stem":1691,"_extension":20},"/ja-jp/blog/what-is-yaml",{"ogTitle":1676,"schema":1677,"ogImage":1678,"ogDescription":1679,"ogSiteName":1223,"noIndex":6,"ogType":1244,"ogUrl":1680,"title":1676,"canonicalUrls":1680,"description":1679},"拡張子YAMLファイルとは？基本から使い方まで徹底解説","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"拡張子YAMLファイルとは？基本から使い方まで徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662547/Blog/Hero%20Images/what_is_yaml.jpg","YAMLは構成ファイル紹介などに使用されるフォーマットです。この記事では、YAMLの基本からKubernetesなどでの具体的な使い方まで解説します。","https://about.gitlab.com/blog/what-is-yaml",{"title":1676,"description":1679,"authors":1682,"heroImage":1678,"date":1683,"body":1684,"category":672,"tags":1685},[738,696],"2025-04-09","## 目次\n\n* YAMLとは？\n* YAMLを何に使う？\n* YAMLとYMLの違いとは？\n* YAMLとJSONの違い\n* YAMLとCUEの比較\n* YAMLのデータ構造と書き方（基本編） \n* GitLabでYAMLを使う\n* 実際にYAMLファイルを編集してみましょう\n* YAMLに関するFAQ\n\nYAMLは、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)ファイルやAnsibleプレイブックに使用されるデータシリアライゼーション・フォーマットです。この記事では、YAMLファイルの基本的な書き方や具体的な利用シーンについて詳しく解説します。\n\n## YAMLとは？\n\nYAMLは、人間がデータを簡潔かつ理解しやすく表現するよう設計されており、設定ファイルやデータ転送で頻繁に使用されるプログラミング言語です。階層的情報の整理に適し、Jsonやxmlの代替と利用されることがあります。\n\n## YAMLを何に使う？\n\nYAMLは可読性の高いこともあり、設定ファイルやプレイブックの記載に使われます。いくつか例を下記に記載しますので、参考にしてください。\n\n* 設定ファイルの記述  \n* ログファイル  \n* プロセス間でのメッセージのやり取り  \n* アプリケーション間でのデータ共有  \n* 構造化データの記述\n\n## YAMLとYMLの違いとは？\n\nどちらも同じ形式のファイルを指し、拡張子が「.yml」か「.yaml」という表記の違いだけです。ヤムルファイルであることを示す正式な拡張子は.yamlですが、一般的に拡張子（.txt, .zip, .exe, .png等）は3文字で記載されるので、この3文字ルールに合わせたのが.ymlとなっています。短く簡潔に書きたい開発者には「.yml」が選ばれることが多いです。\n\n## YAMLとJSON形式の違い\n\nJSON形式では中括弧を使って要件を定義していくのに対して、YAMLは、インデントで構造が明示されるので、可読性が高くなっています。下記サンプルを見比べてください。\\\nYAMLは、プログラマーにとっての使いやすさを重視していることがわかると思います。\n\nYAML：\\\n![yamlのキーとバリューの記載例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/yaml-coding-sample-01.png)\n\nJSON:\n\n![JSON形式のキーとバリューの記載例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/json-format-coding-sample-01.png)\n\n## YAMLとCUEの比較\n\nYAMLは、可読性が高くシンプルな構造を持つのに比べ、CUEは、スキーマとデータを統合するため、複雑な設定もひとつのファイルで管理できます。また、YAML単体では実現できなかったスキーマバリデーション機能を持つので、データの整合性を担保しやすいです。\n\nまた、柔軟性も大きな特徴です。CUEは、あらゆる種類のデータを定義、生成、検証するために使用される[オープンソース](https://about.gitlab.com/ja-jp/blog/what-is-open-source/)の言語（具体的にはJSONのスーパーセット）なので、Go、JSON、OpenAPI、Protocol Buffers、YAMLなどの他の多くの言語と連携できます。\n\nまた、Go APIによるスクリプト機能を備えているので、CUEによるマニフェストを最終的な[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソースのYAMLとして表示したり、特定クラスタにデプロイするリソースを一覧するコマンドを実装する際などに使う機会があります。\n\n## YAMLのデータ構造と書き方（基本編）\n\n### YAMLファイル記述の注意点\n\nインデントとタブが、とても重要であることを覚えておいてください。余分なインデントやタブが使われていると、YAMLオブジェクトの意味が変わってしまうので、これらがとても重要になります。\n\n### YAMLのデータ構造\n\nYAMLは主に、コレクションとスカラーという２つのデータで成り立っています。コレクションは、シーケンスとマッピングから成り立ちます。シーケンスは配列、マッピングは名前と値のペア（Key : Valueで表現する配列）。そしてスカラーは、型を判別させるためのもので、文字列、数値などを表します。\n\n* コレクション  \n\n  * シーケンス  \n  * マッピング  \n* スカラー\n\n### YAMLの書き方\n\n![image2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/image2.png)\n\n* 複数行のコレクション：複数の行のフォーマットを維持する必要がある場合には | (バーティカルバー) シンボルを使用します。  \n* 複数行のフォーマット：長い文字列の値があり、フォーマットを維持したまま複数行に渡って記述する必要がある場合には、 > を使用します。  \n* リスト：リストは - （ハイフン）を使って表現します。  \n* ネスト：ネストされたデータ構造はインデントを使って表現されます。\n\n### Kubernetes（k8s)のYAMLファイルの書き方\n\nKubernetesでは、リソースの定義にYAMLファイルが使用されます。今回はYAMLマニフェストの書き方を紹介します。  \n\nYAMLマニフェスト：\\\n![YAMLでKubernetesのマニフェストの書き方例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/YAML-manufest-sample-Kubernetes.png)\n\n### AnsibleのYAMLファイルの書き方\n\nAnsibleでは、処理内容を記載するプレイブックをYAMLで記載します。以下に、簡単なAnsibleプレイブックの例を示します。\n\n![image3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687457/Blog/Content%20Images/image3.png)\n\n## GitLabでYAMLを使う\n\nGitLab CI/CD パイプラインは、プロジェクト毎に[.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/examples/index.html)というYAMLファイルを使って[パイプラインの構造と実行順序を定義](https://gitlab.com/stylez-co-jp/gitlab-ce/-/blob/dev-v12.0.3-ja.1/doc-ja/ci/yaml/README.md)します。このファイルで設定された内容を、GitLab Runnerの中で処理します。CI/CD YAML構文については[こちらの英文まとめページ](https://docs.gitlab.com/ee/ci/yaml/)をご参照ください。\n\n## 実際にYAMLファイルを編集してみましょう\n\nYAMLは、そのシンプルさと可読性の高さから、設定ファイル、CI/CDパイプライン、Kubernetesをはじめとするコンテナオーケストレーションやドキュメント、構成管理など、多岐にわたり利用されています。その可読性の高さで、開発者や運用エンジニアが構成やデータを容易に管理し、効率的に作業を進めることができます。YAMLを理解することで、様々なシステムやツールの設定がより簡単かつ直感的に行えるようになるでしょう。\n\n## YAMLに関するFAQ\n\n### YAMLは何に使われますか\n\nYAMLは、そのシンプルさと可読性の高さから、設定ファイル、CI/CDパイプライン、Kubernetesをはじめとするコンテナオーケストレーションやドキュメントと構成管理など、多岐にわたり利用されています。\n\n### YAMLとJSONの違いは？\n\nJSONファイルは中括弧を使って要件を定義していくのに対して、YAMLは、インデントで構造が明示されるので、可読性が高くなっています。ただし、YAMLではインデントやスペースがとても重要になる点に注意が必要です。\n\n### YAMLはなぜ人気なのですか？\n\nYAMLは開発者の間で人気のあるデータシリアライズ言語です。なぜなら、その読みやすさ、汎用性、Pythonと似たインデントシステムを使うからです。YAMLは複数のデータ型をサポートしており、多くのプログラミング言語で利用可能なパーサーライブラリが提供されているため、さまざまなデータシリアライゼーションタスクを扱うことができ、幅広い場面で活用されています。\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[1190,1548,702,110,533,1189,676,677,825,966],{"slug":1687,"featured":92,"template":681},"what-is-yaml","content:ja-jp:blog:what-is-yaml.yml","What Is Yaml","ja-jp/blog/what-is-yaml.yml","ja-jp/blog/what-is-yaml",{"_path":1693,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1694,"content":1700,"config":1707,"_id":1709,"_type":16,"title":1710,"_source":17,"_file":1711,"_stem":1712,"_extension":20},"/ja-jp/blog/safe-without-silos-in-gitlab",{"title":1695,"description":1696,"ogTitle":1695,"ogDescription":1696,"noIndex":6,"ogImage":1697,"ogUrl":1698,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1698,"schema":1699},"GitLabで実現するサイロのないSAFe","Scaled Agile Framework（SAFe）をDevSecOpsプラットフォームのネイティブ機能にマッピングする方法と、そこから得られるメリットについて学びましょう。","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","https://about.gitlab.com/blog/safe-without-silos-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabで実現するサイロのないSAFe\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-04-08\",\n      }",{"title":1695,"description":1696,"authors":1701,"heroImage":1697,"date":1703,"body":1704,"category":1705,"tags":1706},[1702],"Amanda Rueda","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","agile-planning",[1389,904,678,701,676],{"slug":1708,"featured":92,"template":681},"safe-without-silos-in-gitlab","content:ja-jp:blog:safe-without-silos-in-gitlab.yml","Safe Without Silos In Gitlab","ja-jp/blog/safe-without-silos-in-gitlab.yml","ja-jp/blog/safe-without-silos-in-gitlab",{"_path":1714,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1715,"content":1721,"config":1726,"_id":1728,"_type":16,"title":1729,"_source":17,"_file":1730,"_stem":1731,"_extension":20},"/ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":1716,"description":1717,"ogTitle":1716,"ogDescription":1717,"noIndex":6,"ogImage":1718,"ogUrl":1719,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1719,"schema":1720},"Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う","トーバルズ氏がオープンソースのバージョン管理システムの開発にいたった経緯、数か月で手を引いた理由、そしてGitでの新しいプログラミング言語のサポートについてどう考えているかをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-07\",\n      }",{"title":1716,"description":1717,"authors":1722,"heroImage":1718,"date":1723,"body":1724,"category":962,"tags":1725},[1643],"2025-04-07","バージョン管理システム「Git」の最初のバージョンは、Linuxカーネルの父であるリーナス・トーバルズ氏によって、2005年4月7日にリリースされました。現在ではほぼすべてのデベロッパーが使うようになったこの重要なプロジェクトの20周年を記念して、トーバルズ氏にインタビューし、Gitの歴史、Gitのメンテナーとしての役割を別の人物に引き継いだ理由、そしてもっとも重要なマイルストーンとは何かについてうかがいました。\n\n**Gitをリリースした2005年には、すでに人気のLinuxカーネルのメンテナーを務めていらっしゃいました。それなのに、なぜ新しいバージョン管理システムの開発を始めようと思ったのですか？**\n\nバージョン管理を行うのが、すごく嫌になっていたんです。\n\n従来型のバージョン管理システム（CVS／RCS／SCCS）はエンドユーザーとしても（例：[GCC](https://gcc.gnu.org/)などのオープンソースプロジェクトの追跡に使用）、デベロッパーとしても（トランスメタ社では何にでもCVSを使用していたため）使用していましたが、非常に嫌な体験でした。\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nその当時、CVSを使用していたプロジェクトはほとんど、[SVN](https://subversion.apache.org/)に移行したと思いますが、正直なところ、SVNは単に表面的な部分だけを変更した「ブタに真珠」だと感じていました。CVSを単に別のソフトにしただけのもので、ある程度UIが改善されていたものの、基本的な問題は一切修正されておらず、代わりに新たな問題を内包していました。\n\nCVSや類似のソフトウェアの問題は、数えきれないほどあります。幸いなことに、それらの問題はもはや重要でなくなっており、若いデベロッパーは対処しなくて済んでいるはずです。90年代にはいくつかのサブシステム（特にネットワーク側）で実際にCVSを使ってコードを追跡していましたが、カーネルでCVSを使うことは断固として拒否しました。\n\nその当時、私はサンフランシスコ・ベイエリアに住んでいました。別のプロジェクト（主に[lmbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf)）で知り合ったラリー・マクボイがBitMoverを立ち上げ、BitKeeper（略称「BK」）と呼ばれる新たなバージョン管理モデルを開発しました。\n\nBitKeeperはオープンソースではなかったものの、ラリー自身はオープンソースプロジェクトを好んでおり、バージョン管理の欠如がカーネルの足かせになっていると強く感じていました。ラリーの考えには同意していたものの、従来のソースコード管理ツール（SCM）の導入にはまったく賛成できませんでした。ラリーは時間をかけて、デイヴィッド・ミラー（ネットワーク機能のメンテナーで既存のCVSユーザー）と私に、BitKeeperでできることを説明してくれました。\n\nBitKeeperは完璧ではありませんでした。また、他の多くの従来型SCMと同様、ソースコード管理システム（SCCS）をベースにしていたため、うまく機能しない「ファイルごとの履歴」モデルが使用されていました。そのため、ファイルの名前変更や削除の際に根本的かつ重大な問題が生じるという欠点がありました。\n\nしかしながら、BitKeeperは単なる「ブタに真珠」ではありませんでした。下層レベルではSCCSが用いられていたかもしれませんが、それより上のレベルでは非常に根本的な部分がいくつか修正されており、適切に分散型開発が行われていました。また、ファイルごとではなく、全体的に履歴が管理されていたため、別のツリーからのコードのマージも実際に行えました。\n\nCVSでは、ブランチを作成してマージする場合、事前に計画して関係者と話し合う必要があり、一大イベントでした。一方、BitKeeperではすべてのリポジトリがブランチでした。これは今となっては当たり前のことです。もちろんGitではこれをさらに推し進め、リポジトリ*ごと*に複数のブランチを持てるようになっています。それと比べると、BitKeeperモデルははるかに制限されたものでしたが、当時は大きな前進でした。\n\nもう一度言いますが、BitKeeperは完璧ではありませんでした。先ほどもお話ししたように、ファイルごとに履歴を保持していたため、名前変更やファイルのマージが確実ではないという根本的かつ重大な問題がありました。そのため、どうしても混乱と手間が苦痛が生じていました（CVSを使っていた方は、Atticを思い出してみてください）。さらに、スケーラビリティの問題もいくつかありましたが、当時はまだ大きな問題ではありませんでした。\n\nしかしながら、BitKeeperの最大の問題はライセンスでした。数年かけて（2002年から2005年までBitKeeperを使用）、多くのカーネルメンテナーがBitKeeperに移行しましたが、毎回ライセンスの面で摩擦が生じていました。2004年後半にはそれが大問題となり、カーネルにBitKeeperを使用することは、数か月後には基本的に不可能という事態となりました。\n\n当時の私は、ようやく機能するソース管理ツールを使用できるようになってから3年間経っており、おかげで非常に多くの問題を解決できていました。ソース管理を行っていなかった時代に戻るのはお断りでしたが、BitKeeperを使用していた数年の間、それよりも良いツールはオープンソースコミュニティから出てこなかったのです。\n\nCVSやSVNがうまく機能しないことは周知の事実であり、別のアプローチを試したプロジェクトもありました。それらのアプローチの中には、さらにひどいもの（多くは「手の込んだパッチ追跡」に相当するもの）や、アイデア自体は良かったのに、その過程で新しい重大なデザインミスが起きたもの（[Monotone](https://www.monotone.ca/)）もありました。\n\nそのため、しばらく探し回ってから、他に選択肢はないから自分で開発しなければ、と決断しました。\n\n技術的には、Gitの最初のバージョンの作成には数日しかかかりませんでした。それはすべて、Gitのコミット履歴に残っています。ほぼ何もなかった状態から、1週間後には他の人から提供されたパッチを適用し始める（さらにその数日後には、カーネルに積極的に使用されるようになった）ほど使える状態になった様子は簡単に見て取れます。\n\nしかしながら、コミット履歴からは、それまでに私がこの問題についてしばらく*考えていた*という事実はわかりません。コードを書くこと自体は簡単です。重要なのは、良いデザインを行うことです。ですので、あの数日間の前にかなり長い準備期間がありました。その部分は、コミット履歴には反映されていません。\n\n最初のバージョンはとても粗削りなもので、後から登場する機能はほとんど備わっていませんでした。しかしながら、この最初のバージョンには、核となるデザインの大部分がすでに含まれていました。\n\n**Gitプロジェクトがどのように始まったか、最初の数日間と数週間について簡単に説明していただけますか？**\n\n私は基本的には、満足できる代替ツールができあがるまで、カーネルの開発を中断すると決めていました。主な目標は、分散型かつ高性能であること、そしてどんな破損でも確実に検出可能と信頼できるものを開発することでした。\n\nただし、お伝えしておきたいのは、SCM自体には興味がなかったということです。私が興味があったのは、プロセスではなく、最終的に得られる結果でした。そのため、私にとって、Gitはカーネルと同じではありませんでした。Linux開発はカーネルに興味があるから行っていますが、Gitは必要性に迫られて取り組みました。\n\nこれが、次の質問の回答にも直接つながります。\n\n**数か月後に、Gitのメンテナーの役割を濱野純氏に引き継がれました。今でも引き続き濱野氏がメンテナーを務めています。メンテナーを退いた理由、そして濱野氏を選んだ理由についてお聞かせください。**\n\nメンテナーの役割を引き継ぐことは、難しい決断ではありませんでした。「Gitのメンテナンスを任せられると思える相手が見つかったら、すぐにカーネルのメンテナーに戻ろう」と考えていたためです。\n\nもちろん、責任だけを押し付けて、成功を祈ったというわけではありません。メンテナンスを長期間にわたって担当してくれる、「センスが良い」人を探す必要があると考えていたため、結局、Gitのメンテナーを4か月ほど務めることになりました。\n\n濱野さんは、初期から参加したメンバーの1人でした（文字どおり、開発の最初の週から参加）。でも、すぐに「次のメンテナーになってください」と言ったわけではありません。誰が長期にわたって担当してくれるか、また誰がコードを書いて、適切な決定を下せるかを見極めるには、ある程度の時間がかかります。\n\n濱野さんはまさにぴったりでした。私がGitに費やしたのはわずか数か月間ですが、特に20周年を迎えるにあたり、賞賛を受けすぎていると感じています。適切に核となるデザインを行い、プロジェクトを立ち上げたことは私の実績ですが、（もちろん他の何百人もの関係者も重要ですが）実際にプロジェクトを主導してきたのは濱野さんです。\n\n**バージョン管理システムであるMercurialの最初のバージョンは、Gitの最初のバージョンがリリースされてからわずか12日後（2005年4月19日）にリリースされました。MercurialのユーザーエクスペリエンスはGitよりも優れていたと多くの人々が主張していますが、今では圧倒的にGitの方が人気があります。GitがMercurialに勝った理由は何だとお考えですか？**\n\n主な理由は、明らかにネットワーク効果だと思います。SCMには、非常に強力なネットワーク効果があります。制限が多いにもかかわらず、CVSがあれほど長く生き残った理由もそれです。\n\nつまり、カーネルでGitを使用していたためです（その後、ある時点でRuby on RailsコミュニティでGitが大人気となり、それからさまざまな場所で普及しました）。\n\nでも、Gitのデザインは本当に優れていると思います。コアモデルは非常にシンプルかつ強力です。そのおかげで、他の環境に簡単に移植できたと考えています。JGitは初期の移植例ですが、他にもMSgit仮想ファイルシステムなどの実装があります。\n\nたしかに当初はGitが使いにくいという評判がありましたが、その理由の一部は、Gitでは「正しく」処理を行っていたことが原因だと思います。Gitでは、従来のSCMでは決して行わなかったような、難しい判断をいくつか行っていたため、他の環境から移行したユーザーはGitを直感的ではないと感じたのでしょう。\n\n**Gitプロジェクトは、あなたが濱野氏にメンテナーの役割を引き継いだ後も、一度も停止せずに、コミュニティメンバーによる新機能の開発が常に進行中です。プロジェクトを離れた後、もっとも重要なマイルストーンは何だったとお考えですか？**\n\nそれは非常に答えにくい質問です。というのも、自分が満足するようにGitを開発したため、*私自身*が活用している機能は、開発当初から使えたためです。わかりやすい例としては、GitがWindowsに対応したことことは、他のユーザーにとっては間違いなく大きなステップでしたが、*私*にとってはまったく関係のないことでした。\n\nもちろんGit自体に、使いやすさを向上するためのインフラがすべて備わっていますが、大きなマイルストーンの大半は、Gitのインフラを利用して、それを中心に何かを構築してきた人たちによって成し遂げられたものだと思います。当然ながら、これらは最終的にはGitの機能に反映されがちです。しかしながら、本当のマイルストーンは外部に関するものです。\n\nわかりやすい例を挙げると、Gitのホスティングサイトはすべて大きなマイルストーンです。ホスティングサイトによって、より簡単にGitを配信できるようになったものの、*本当のマイルストーン*は、ホスティングによってユーザーがさまざまなプロジェクトでGitを非常に簡単に使えるようになったことです。\n\n**もし、またGitにフルタイムで携わることができるとしたら、実装したい機能はありますか？**\n\n一切ないですね。Gitではかなり初期の段階から、本当に必要としていたことをすべて実現できました。実のところ、私の使い方はかなり限定的で、本当に重視しているのは1つのプロジェクトだけなんです。\n\nそして、「一切ない」とお答えしたのは、先ほどお伝えしたとおり、私は当初からSCMにまったく興味がなかったためです。Gitが他のSCMとこれほど違うものになった（おおむね良い意味で）主な理由は、私が従来のSCMというより、分散型ジャーナリングファイルシステムに対してのように取り組んだからだと思います。\n\n**Gitの機能やデザイン上の決定で、後悔していることはありますか？**\n\nデザイン上の決定ですか？後悔していることはありません。今でも基本デザインは非常に優れていると思っています。実際の実装の複雑な詳細に一切触れることなく、さまざまなGitのコンセプトについて話し合えます。\n\nプロジェクトにおいては、それが重要だと思います。プロジェクトのコンセプトの方向性を指示するには、基本的なデザイン方針がある程度必要です。\n\nときにはこれが行き過ぎて、実装時に、基本デザインの核となる方針に盲目的に従うべきだと考える人もいます。これも間違っています。現実はややこしく、人々は変わったものを求めるため、*実装時*には複雑な多数のコーナーケースが生じます。なので、厄介な現実に対処しなくて済むように、参考になり、高度なレベルで検討できるような、ある種の基本デザインが必要となります。\n\nGitはそう言った面でバランスが取れていると思います。非常にわかりやすいオブジェクトストアデザインが採用されています（CS分野の方にとっては「マークル木構造」、ファイルシステム担当者には「内容アドレス記憶装置」という呼び方がピンとくるかもしれません）。コアデザインは存在しますが、一方でそれは実際のところ、実コードのほんの一部にすぎません。*コード*の大半はコアデザインに沿った内容です。根本的にデザインがわかりやすいため、プロジェクトにある種の基本構造が生まれます。\n\nこれは、かつてのUNIX自体の基本構造（すべてがファイルから構成されている仕組みや、プロセス処理方法）と同じようなものです。デザインのベースとなる「コンセプト」はいくつかあるものの、コードの99%は、それを実世界に適用するために、その上に構築される非常に細かな内容です。\n\n私には、技術に関する信念が2つあります。それは「私がかなたを見渡せたのだとしたら、それは巨人の肩の上に立っていたからです」（ニュートン）と「天才とは、1%のひらめきと99%の努力である」（エジソン）です。\n\n99%の努力について考えてみると、大まかなデザインには非常に満足していますが、細かい点については、もし今Gitに携わるなら違う風にしていただろうなと思うところは、確かに多々あります。\n\nでも正直なところ、そういった点はあまり重要でありません。それよりも、過去20年間に行われたすべての*良い*実装こそがはるかに重要です。\n\n**Linuxカーネルにおいて、一部のサブシステムのプログラミング言語としてRustの使用が開始されました。Gitの場合、このような新しいプログラミング言語を使い始めることは妥当だとお考えですか？**\n\nGitに関して言えば、新たな言語を使い始めることにあまり意味はないと思います。大抵の場合、苦労することになります。\n\nカーネルの場合、最終的な成果物は単一のカーネルバイナリです。その大半はモジュールとして動的に読み込むことはできるものの、実質的には単一のバイナリにリンクされています。\n\nそのため、複数の言語を使用すると、より複雑になります。しかしその一方で、カーネルではメモリ安全性についてさらに気を付けなければならないため、新しい言語に目を向ける必要性があります。\n\nGitの場合は、もしその一部をRustや他の言語で書きたいのであれば、複数の言語で1つのバイナリを開発するよりも、個別に実装する方がはるかに理にかなっていると思います。\n\nGitの核となるアイデアの多くはシンプルなので、中核となる部分の並列実装だけならそれほど難しくないはずです。そうすれば、別の言語での開発がより適切な問題領域に、個別に取り組めます。\n\nもちろん、このやり方はすでにGitでも行われています。まさにこの方法で開発されているのがJGitです。別の言語を使用したのは、Gitとは異なるウェブベースの環境であるため、より自然な選択だったからです。\n\nGitの主要機能の一部に対応したRustの実装はすでにいくつかありますが、同様の状況だと思います。特定の状況においては、「すべてをRustに移植しよう」というよりも、このアプローチの方が適切だと思います。\n\nですので、Rustでの実装に興味がある方には、Rustを使用する利点がより明らかな箇所を探すことをおすすめします。標準的なGitのソースベースでは、C言語の使用はそれほど問題はなかったと思います。\n\n**数年ごとに、新しいバージョン管理システムが登場しています。Gitは今後も、重要なツールとしての地位を維持できるとお考えですか？** \n\nSCMにネットワーク効果があることは先ほどお話ししました。そのため、Gitに取って代わるには、少し優れているだけではなく、はるかに優れている必要があると思います。もしくは、互換性が高すぎると、実質的にGitの新しい実装となります。\n\nSCMを取り巻く状況は実際に変わったと思います。Gitには、Git以前のSCMが抱えていたような、深刻かつ根本的な問題はありません。したがって、「はるかに優れている」ツールを開発するのはかなり大変です。\n\nですので、当面の間、Gitが現在の地位を維持できると考えています。人々はGitに代わるツールではなく、Gitを*ベース*として改善に取り組んでいくでしょう。\n\n*注：このインタビューは、長さを調節し、文意を明確にするために編集されています。*\n\n## Gitの関連リンク\n\n- [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)  \n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Gitプロジェクト](https://git-scm.com/)",[825,966],{"slug":1727,"featured":92,"template":681},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","content:ja-jp:blog:celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Celebrating Gits 20th Anniversary With Creator Linus Torvalds","ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"_path":1733,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1734,"content":1740,"config":1744,"_id":1746,"_type":16,"title":1747,"_source":17,"_file":1748,"_stem":1749,"_extension":20},"/ja-jp/blog/monday-merge-2025-april-7",{"title":1735,"description":1736,"ogTitle":1735,"ogDescription":1736,"noIndex":6,"ogImage":1737,"ogUrl":1738,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1738,"schema":1739},"🌞 4月のMonday Merge: AIとDevSecOpsの魔法が融合！","4月のMonday Mergeでは、AIの力を活かしたコミュニティ主導のセキュリティ強化、GitLab 17.10の注目機能、さらにサウスウエスト航空がどのようにDevOpsを活用させているのかご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663178/Blog/Hero%20Images/LinkedIn_Header_Images_April_-04.png","https://about.gitlab.com/blog/monday-merge-2025-april-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"🌞 4月のMonday Merge: AIとDevSecOpsの魔法が融合！\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-04-07\",\n      }",{"title":1735,"description":1736,"authors":1741,"heroImage":1737,"date":1723,"body":1742,"category":700,"tags":1743},[738],"GitLabコミュニティのみなさん、こんにちは！春と共に、今回のアップデートはかなりワクワクする内容のものが届いています。今月は、AIの力を活かしたコミュニティ主導のセキュリティ強化、GitLab 17.10の注目機能、さらにサウスウエスト航空がどのようにDevOpsを活用させているのかご紹介します。\n\n### 注目ポイントはこちら：\n- 📊 AIインパクト分析ダッシュボード – AIがただのトレンドじゃなく、生産性を劇的に向上させることを証明。\n- 🔒 オープンソースセキュリティハブ登場 – 脅威は単独ではなく、みんなで協力して防ぎましょう。\n- 🚀 GitLab 17.10が登場 – Duoコードレビュー、根本原因分析、DORAメトリクスで、DevOpsをもっと強力に。\n\n準備はOKですか？詳しく見ていきましょう！\n\n## GitLab Duo AIインパクト分析ダッシュボード: データで見るDevSecOpsの進化\n\n![03 Header Images April GitLab Duo AI Impact Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687561/Blog/Content%20Images/03_LinkedIn_Header_Images_April__GitLab_Duo_AI_Impact_Dashboard.png)\n\nAIのROIが測定できる時代が来ました。新しいダッシュボードでは、AIがどのようにワークフローを変えているかを確認できます。\n\n✅ コードによるDuoの提案を使ったチームは、マージサイクルが15%速くなっています。\n✅ チャットを使った Duo Chatの文脈に基づくヘルプで、クエリ解決は2倍速く。\n✅ パイプライン効率向上：AIによるテスト生成で、早期導入者のCI時間が30％短縮されます。\n\n🔗 [GitLab DuoがSDLCに与える影響をどう測っているかを見る（英語）\n](https://www.youtube.com/watch?v=FxSWX64aUOE&list=PLFGfElNsQthZGazU1ZdfDpegu0HflunXW&index=2)\n\n## オープンソースセキュリティハブ: みんなで強く\n\n![04 Header Images April Open Source Security Hub](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687562/Blog/Content%20Images/04_LinkedIn_Header_Images_April_Open_Source_Security_Hub.png)\n\nサイバー攻撃者たちは互いに協力しています。私たちも連携すべきではないでしょうか。GitLabのオープンソースセキュリティハブはその答えとなります。GitLabのセキュリティチームが作成したツールキットを、世界中で公開しています。\n\nなぜこれが重要なのかは次の通りです。\n- StORMテンプレート: GitLab内で使われるフレームワークで、リスクを標準化。\n- GUARDフレームワーク: 検出コードを自動化し、脅威対応を効率化。\n- CISベンチマークスキャナー: セキュリティ基準に照らしてプロジェクトを監査。\n\n私たちは、Crowdstrikeのようなリーダーにインスピレーションを受けています。オープンソースのツールがエコシステム全体を強化するのです。\n\n🔗 [GitLabがデベロッパーとセキュリティ担当者をどう支援しているかを知る（英語）\n](https://about.gitlab.com/blog/introducing-gitlabs-open-source-security-center/)\n\n## GitLab 17.10: よりスマートで、より速く、より繋がる\n![05 Header Images April GitLab 17.10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687562/Blog/Content%20Images/05_LinkedIn_Header_Images_April_GitLab_17.10.png)\n\nDevSecOpsツールが強力に進化しました。\n\n🔎 Duoコードレビュー（ベータ版） `@GitLabDuo` をMRでタグ付けすると、AIによるバグ発見と最適化提案が受けられます。\n\n🛠️ 根本原因分析（Self-Hosted） CI/CD失敗の原因をAIが数秒で解析。エアギャップ環境にも対応（Mistral、Anthropic、OpenAIをサポート）。\n\n📈 DORAメトリクスを視覚化 クロスプロジェクトダッシュボードでボトルネックを特定。実例：あるチームは、テストの不安定さを解決してデプロイ頻度を40%向上。\n\n🎨 GitLabクエリ言語（GLQL）ビュー＆Markdown Wikiにライブデータクエリを埋め込み、ピクセル完璧なメディア制御でドキュメントを作成。\n\n🔗 [リリースノートはこちら](https://about.gitlab.com/ja-jp/blog/gitlab-17-10-release/)\n\n## 📅 今後のイベント: ぜひご参加ください！\n\n![06 Header Images April Upcoming Events](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687562/Blog/Content%20Images/06_LinkedIn_Header_Images_April_Upcoming_Events.png)\n\nロンドンからラスベガスまで、DevSecOpsの知見を共有しに各地を巡回します。\n\n- KubeCon（4月1日〜4日、イギリス・ロンドン） – Cloud Native Computing Foundation（CNCF）主催のイベントで、オープンソースやクラウドネイティブの専門家たちが一堂に会しました。KubernetesやDevOps、クラウドネイティブの最新トレンドについて、業界のリーダーたちによって議論されました。\n\n👉 セッションの録画は、イベント終了後2週間以内にCNCFのYouTubeチャンネルに公開される予定です。[見逃した方はぜひチェックしてみてください！](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/)\n\n- Google Cloud Next（4月9日〜11日、ネバダ・ラスベガス） – Google主催のプレミアイベントにてAIやクラウド、セキュリティのトップ専門家と交流ができます。ライトニングトークやハンズオンのデモ、ワークショップを通してあなたのクラウドの知識レベルアップに。 さらに、ラスベガスのアレジアント・スタジアムでのThe Killers、Wyclef Jean、Tate Rennerのライブパフォーマンスも！\n\n👉 [ラスベガスで参加しよう！](https://cloud.withgoogle.com/next/25)\n\n- RSAC 2025（4月28日〜5月1日、カリフォルニア・サンフランシスコ） – サイバーセキュリティの最新脅威や戦略、イノベーションを学び、業界のリーダーと協力して未来のセキュリティを形作りましょう。\n\n👉 [参加しよう！](https://www.rsaconference.com/usa)\n\n## 事例のご紹介: サウスウエスト航空のDevOps活用\n![07 Header Images April Customer Spotlight](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687562/Blog/Content%20Images/07_LinkedIn_Header_Images_April_Customer_Spotlight.png)\n\nサウスウエスト航空は、デベロッパーのためにボトルネックを排除し、繰り返しの作業を減らして、より大きな革新に集中できる時間を提供しています🚀\nサウスウエスト航空のVP＆CISOであるJim Dayton氏はこう言います。\n\n「人がソフトウェア開発に携わるのは、その創造性が好きだからです。問題を解決することが好きです。私たちはその邪魔をしないようにするべきです」。 GitLabにコードを集中させ、セルフサービスツールを使うことで、サウスウエスト航空はデベロッパーがより早く答えを見つけ、効率的に作業できるようサポートしています。\n\n次に目指すのは？AIを使ったワークフローの自動化。Dayton氏は、AIが脆弱性の説明や、コードレビュアーへの提案などの日常的な作業を効率化し、チームが本当に重要なことに集中できるようになると考えています。\n\n🎯 キー・メッセージ: AIはデベロッパーを置き換えるのではなく、より良く、より速く作れるようにサポートするのです。\n\n🔗 [サウスウエスト航空事例に関する本文を読む](https://about.gitlab.com/ja-jp/blog/southwest-looking-to-help-developers-take-flight/)\n\n## おすすめ読書\n![08 Header Images April What We’re Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/08_LinkedIn_Header_Images_April_What_We_re_Reading.png)\n\n- Emilio Salvador：AI’s Next Chapter： 2025年のソフトウェア開発における4つの変化。GitLabの戦略VPが、AIがコードをコストやコンプライアンスに最適化する方法について説明します。\n\n👉 [Geekwireの記事を読む](https://www.geekwire.com/sponsor-post/ais-next-chapter-four-major-shifts-in-software-development-for-2025/)\n\n- Sabrina Farmer: The tech giants are wrong: GitLabのCTOが、開発者がAIの恩恵を受ける方法を解説。（GitLabのDevSecOpsレポートを用いて）\n\n👉 [Raconteurの記事を読む](https://www.raconteur.net/technology/ai-replace-engineers)\n\n- Joel Krooswyk: Creating a cybersecurity standard of care: ソフトウェアに関する責任の未来。GitLabの連邦CTOが、SBOM（ソフトウェア部品表）とオープンソース監査がどのように責任を守る手段になっているかを解説。\n\n👉 [Federal News Networkの記事を読む](https://federalnewsnetwork.com/commentary/2025/03/creating-a-cybersecurity-standard-of-care-the-future-of-software-liability/)\n\n## 💡 本日のインスピレーション\n\n変化の速い世界で、故Susan Wojcickiの言葉がますます真実味を帯びています。\n\n「最高のアイデアはしばしば予期しない場所から生まれる」\n\nそれでは、次回まで、好奇心を持ち続け、つながりを大切にし、Happy Merging！\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | GitLab Developer Advocate\n![SignOffBanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/SignOffBanner.png)\n\nP.S. DevSecOpsの最新情報を逃さないように、ぜひ来月も読んでくださいね！\n",[721,763,701],{"slug":1745,"featured":6,"template":681},"monday-merge-2025-april-7","content:ja-jp:blog:monday-merge-2025-april-7.yml","Monday Merge 2025 April 7","ja-jp/blog/monday-merge-2025-april-7.yml","ja-jp/blog/monday-merge-2025-april-7",{"_path":1751,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1752,"content":1758,"config":1764,"_id":1766,"_type":16,"title":1767,"_source":17,"_file":1768,"_stem":1769,"_extension":20},"/ja-jp/blog/enhance-application-security-with-gitlab-hackerone",{"title":1753,"description":1754,"ogTitle":1753,"ogDescription":1754,"noIndex":6,"ogImage":1755,"ogUrl":1756,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1756,"schema":1757},"GitLab + HackerOneでアプリケーションセキュリティを強化","GitLabとHackerOne社のパートナーシップの詳細と、組織のアプリケーションセキュリティ対策状況を強化するインテグレーションを簡単に導入する方法をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","https://about.gitlab.com/blog/enhance-application-security-with-gitlab-hackerone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab + HackerOneでアプリケーションセキュリティを強化\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-03\",\n      }",{"title":1753,"description":1754,"authors":1759,"heroImage":1755,"date":1760,"body":1761,"category":722,"tags":1762},[1507],"2025-04-03","開発プロセスにおいて、セキュリティはもはや後回しにできるものではありません。組織には、ソフトウェア開発ライフサイクル全体にセキュリティを統合できる堅牢なソリューションが求められています。ここで、HackerOne社とGitLabのパートナーシップが、現代のアプリケーション開発チームにとって魅力的な組み合わせとなります。\n\n\nGitLabはAI搭載の包括的なDevSecOpsプラットフォームであり、HackerOneは業界をリードするクラウドソーシング型セキュリティプラットフォームです。この2社がパートナーシップを結び、GitLabの効率的なDevSecOpsワークフローと、HackerOneの強力な脆弱性管理機能という両者の強みを融合させました。\n\n\nこのチュートリアルでは、HackerOneのGitLabインテグレーションを実装することで、デベロッパーの生産性とセキュリティ対策状況を強化する方法を説明します。\n\n\n## デベロッパーを支援するインテグレーション\n\n\nHackerOneのGitLabインテグレーションは、非常にシンプルでありながら強力です。セキュリティ研究者がHackerOneのプラットフォーム上で脆弱性を発見すると、その情報で自動的にGitLabのイシューが作成されます。これにより、以下のようなシームレスなワークフローが実現します。\n\n\n* セキュリティ研究者がHackerOneのプラットフォームで脆弱性を特定\n\n* 検証済みの脆弱性について自動的にGitLabのイシューが作成される\n\n* 開発チームは既存のワークフロー内でこれらのイシューに直接対応できる\n\n* 解決状況は両プラットフォーム間で同期される\n\n\nこの[インテグレーション](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)を使うことで、GitLabイシューをHackerOne上の参照として追跡でき、GitLabとHackerOneの強みをすぐに取り入れることができます。このインテグレーションにより、HackerOneのレポートとGitLabイシュー間で双方向かつシームレスなデータ同期が可能となり、開発チームとセキュリティチームの連携が強化され、セキュリティの脆弱性への対応が効率化します。\n\n\nHackerOneレポートとGitLabイシュー間で情報を同期するには、[HackerOneのGitLabインテグレーションのドキュメント](https://docs.hackerone.com/en/articles/10394699-gitlab-setup)に従って設定を行ってください。このドキュメントでは、以下の手順が解説されています。\n\n\n1. HackerOneの設定に基づいた[OAuth\n2.0アプリケーション](https://docs.gitlab.com/ee/integration/oauth_provider.html)をGitLabインスタンス上に作成する\n\n2. HackerOneと新たに作成したGitLabのOAuth 2.0を接続する\n\n3. GitLab APIへのアクセスをHackerOneに許可する \n\n4. HackerOneレポートをエスカレーションするGitLabプロジェクトを設定する\n\n5. HackerOneの各フィールドをGitLabの対応するフィールドにマッピングする\n\n6. GitLabからHackerOne、およびHackerOneからGitLabへのイベントを設定する\n\n\nインテグレーションを完了すると、GitLabとHackerOneの間でデータが双方向にシームレスに同期されます。これにより、コンテキストの切り替えが簡素化され、両方のシステムで脆弱性を簡単に追跡できるようになります。このインテグレーションにより、次の機能が使用できます。\n\n\n* **HackerOneからGitLabイシューを作成：**HackerOneで受け取ったレポートに基づき、新しいGitLabイシューを作成できます。\n\n* **HackerOneレポートを既存のGitLabタスクにリンク**   \n\n* **HackerOneからGitLabへの更新内容の同期：** レポートの以下の更新情報がGitLabのコメントとして同期されます。\n   * レポートのコメント\n  * ステータスの変更  \n  * 報酬情報\n  * 担当者の変更\n  * 公開設定の変更\n  * GitLabイシューのクローズ\n* **GitLabからHackerOneへの更新内容の同期：**\nGitLabの以下の更新情報がHackerOneの関連レポートの内部コメントとして反映されます。 \n  * コメント \n  * ステータスの変更\n* **HackerOneの重大度とGitLabラベルのマッピング：**\nレポートをGitLabにエスカレーションする際、カスタムの優先度を設定できます。 \n\n* **期限のマッピング：** レポートの重大度に基づいて、自動で期限を設定できます。\n\n\n![GitLab +\nHackerOneによる、GitLabでのレポートへのコメント追加およびステータス変更](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\n\nこれらの機能により、開発チームとセキュリティチームの連携がよりスムーズになり、効率よくセキュリティの脆弱性に対応できます。インテグレーションの仕組みについてさらに詳しく知りたい場合は、[インテグレーションドキュメント](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)をご覧ください。\n\n\n## HackerOne社のバグバウンティプログラムについて\n\n\nHackerOne社は、顧客のソフトウェアシステム、Webサイト、またはアプリケーションに存在する脆弱性を発見・報告することで報酬が得られる、バグバウンティプログラムやサイバーセキュリティ施策を提供しています。バグバウンティプログラムは、アプリケーションのセキュリティを強化する上で、以下のような役割を果たします。\n\n\n* 悪意ある攻撃者に悪用される前にセキュリティ上の欠陥を特定する\n\n* 世界中のセキュリティ研究者による多様な専門知識を活用する\n\n* コスト効率の高いサイバーセキュリティ強化手段を提供する\n\n* 社内のセキュリティ対策や従来型のペネトレーションテストを補完する\n\n\nGitLabはHackerOne社のバグバウンティプログラムを活用しており、セキュリティ研究者はGitLabのアプリケーションやインフラにおける脆弱性を報告できます。このクラウドソーシングによるアプローチにより、GitLabは潜在的なセキュリティ問題をより効果的に特定し、対処できます。\n\n\n![HackerOne社のGitLabバグバウンティページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\n\nHackerOneのプラットフォームと世界中のハッカーコミュニティを活用することで、組織はセキュリティ対策状況を大幅に強化し、脆弱性をより迅速に特定し、潜在的な脅威に先手を打つことができます。\n\n\n## GitLabでアプリケーションを保護し、効率性を向上させる\n\n\nGitLabは、セキュリティおよびコンプライアンスツールを含む、ソフトウェア開発ライフサイクル全体をカバーする完全なDevSecOpsプラットフォームを提供しています。GitLabは、以下の種類のセキュリティスキャナーに対応しています。\n\n- 静的アプリケーションセキュリティテスト（SAST）\n\n- 動的アプリケーションセキュリティテスト（DAST）\n\n- コンテナスキャン\n\n- 依存関係スキャン\n\n- Infrastructure as Codeスキャン\n\n- カバレッジガイド付きファジング\n\n- Web APIファジング\n\n\nGitLabを使えば、CI/CDパイプラインの定義ファイルにテンプレートを追加するだけで、セキュリティスキャンを導入できます。たとえば、SASTを有効にするには、.gitlab-ci.ymlファイルに数行のコードを追加するだけです。\n\n\n```yaml\n\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\n\nこれにより、testステージでSASTが実行され、アプリケーションで[使用されている言語を自動で検出](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)します。そして、マージリクエストが作成されるたびに、SASTがフィーチャーブランチとターゲットブランチ間の差分にある脆弱性を検出し、それぞれの脆弱性に関する修正のためのデータを提供します。\n\n\n![マージリクエストで検出されたNoSQLインジェクションの脆弱性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\n\nSASTスキャナーの結果は、セキュリティポリシーが適用されている場合、コードのマージをブロックすることができます。GitLabのネイティブユーザーを承認者として設定でき、脆弱なコードがマージされる前に必ずレビューを行うようにできます。これにより、すべての脆弱性が適切な関係者によって確認される体制が整います。\n\n\n![マージリクエストの承認ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\n\nHackerOneは、オペレーションおよび開発プロセスにおいてGitLabを複数の重要な方法で統合しており、それにより開発プロセスの改善、スケーラビリティの向上、チーム間のコラボレーションの強化を実現しています。こうした改善によって、デプロイがより迅速になり、チームプランニングもスムーズになります。\n\n\n## HackerOneのGitLabインテグレーションの主な利点\n\n\nHackerOneとGitLabを組み合わせて活用することで、以下のような主なメリットがあります。\n\n\n* **セキュリティの可視性向上：**\nデベロッパーは、普段の作業環境から離れることなく、セキュリティ上の脆弱性を即座に把握できます。リアルタイムで認識できるので、機能開発と並行してセキュリティ問題に優先順位を付けて対応できます。\n\n* **修正プロセスの効率化：**\nHackerOneのレポートを直接GitLabイシューに変換することで、修正作業が標準の開発サイクルに組み込まれます。プラットフォームを行き来する際の頭の切り替えを減らし、セキュリティ修正を他の開発作業と一緒に追跡できます。\n\n* **修正までの時間を短縮：**\nこのインテグレーションにより、脆弱性の発見から解決までの時間が大幅に短縮されます。HackerOneからの報告が即座にGitLabで確認できるため、デベロッパーは遅延なく修正に着手でき、全体的なセキュリティ対策状況の強化にもつながります。\n\n* **コラボレーションの改善：**\nセキュリティ研究者、セキュリティチーム、デベロッパーがこのインテグレーションを通じてより効果的に連携できます。コメントや更新情報が両プラットフォーム間でやり取りされ、セキュリティ強化に向けた協力体制が整います。\n\n* **実際の導入効果：** HackerOneとGitLabのインテグレーションを導入した組織では、以下のような成果が報告されています。\n  * 脆弱性の発見から修正までの時間が最大70%短縮\n  * デベロッパーが慣れ親しんだ作業環境のまま対応できることによる満足度の向上\n  * 組織全体でのセキュリティ可視性の向上\n  * セキュリティリソースのより効果的な活用\n\n>\n[インテグレーション設定ページ](https://docs.hackerone.com/en/articles/10394699-gitlab-setup)にアクセスして、今日から導入を始めましょう。\n\n\n## 関連リンク\n\n\nGitLabとHackerOneの詳細、およびセキュリティ対策状況の強化については、以下のリソースをご覧ください。\n\n*\n[HackerOneのGitLabインテグレーションの使用方法](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)  \n\n* [HackerOneのGitLabバグバウンティプログラム](https://hackerone.com/gitlab?type=team)\n\n*\n[GitLabのセキュリティおよびコンプライアンスソリューション](https://about.gitlab.com/ja-jp/solutions/security-compliance/)  \n\n*\n[HackerOne社は、GitLabにビルトインされたセキュリティにより、デプロイ速度を5倍まで高めることに成功](https://about.gitlab.com/ja-jp/customers/hackerone/)  \n\n*\n[GitLabアプリケーションセキュリティドキュメント](https://docs.gitlab.com/ee/user/application_security/)\n",[722,676,235,285,904,702,1763],"bug bounty",{"slug":1765,"featured":6,"template":681},"enhance-application-security-with-gitlab-hackerone","content:ja-jp:blog:enhance-application-security-with-gitlab-hackerone.yml","Enhance Application Security With Gitlab Hackerone","ja-jp/blog/enhance-application-security-with-gitlab-hackerone.yml","ja-jp/blog/enhance-application-security-with-gitlab-hackerone",{"_path":1771,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1772,"content":1778,"config":1783,"_id":1785,"_type":16,"title":1786,"_source":17,"_file":1787,"_stem":1788,"_extension":20},"/ja-jp/blog/what-is-sbom",{"title":1773,"description":1774,"ogTitle":1773,"ogDescription":1774,"noIndex":6,"ogImage":1775,"ogUrl":1776,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1776,"schema":1777},"SBOMの基本と導入方法｜ソフトウェアのセキュリティを守るための実践ガイド","この記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663321/Blog/Hero%20Images/SBOM_keyvisual.jpg","https://about.gitlab.com/blog/what-is-sbom","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SBOMの基本と導入方法｜ソフトウェアのセキュリティを守るための実践ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-26\",\n      }",{"title":1773,"description":1774,"authors":1779,"heroImage":1775,"date":1780,"body":1781,"category":722,"tags":1782},[738,696],"2025-03-26","ソフトウェア開発において、セキュリティリスクへの対応は年々重要性を増しています。特に、OSS（オープンソースソフトウェア）の普及に伴い、脆弱性管理やライセンス対応の課題に直面している方も多いのではないでしょうか。\n\nこうした中で注目を集めているのが、ソフトウェアの構成要素を可視化する「SBOM」です。本記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。セキュリティの強化や開発の効率化を目指す方は、ぜひ参考にしてください。\n\n## 1. SBOMとは？基本知識と重要性\n\nSBOMは「Software Bill of Materials」の略で、ソフトウェアに含まれるすべての構成要素（コンポーネント）を一覧化した「部品表」のことです。\n\nSBOMには、使用されているOSS、サードパーティ製ライブラリ、独自開発のコンポーネントなど、ソフトウェアを構成するすべての要素を記載します。各コンポーネントのバージョン情報、ライセンス情報、依存関係なども含まれており、これらの情報を一元管理し、製品全体の透明性や安全性を確保する重要な役割を果たします。\n\n## 2. SBOMが注目されている背景\n\n![SBOMとは3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF3.jpg)\n\n近年、ソフトウェア開発の環境が大きく変化する中で、SBOMの重要性が急速に高まっています。ここでは、SBOMの注目度が高まっている3つの背景について、詳しく見ていきましょう。\n\n### 2-1 ソフトウェアサプライチェーン攻撃の増加\n\nソフトウェアサプライチェーン攻撃とは、開発・供給過程で使用されるソフトウェアやツールに不正なコードや脆弱性を仕込む手法です。この攻撃は、正規の更新プログラムやコンポーネントを介して攻撃が拡散するという特徴があります。信頼される配布チャネルを利用するため攻撃の検知が極めて困難であり、被害が広範囲に及ぶケースも少なくありません。\n\n独立行政法人 情報処理推進機構（IPA）が発表した「[情報セキュリティ10大脅威 2024[組織]](https://www.ipa.go.jp/security/10threats/10threats2024.html)」（外部サイト）では、サプライチェーンを狙った攻撃が2位にランクインしており、その深刻さが伺えるでしょう。また、同ランキングの5位「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」や7位「脆弱性対策情報の公開に伴う悪用増加」では、脆弱性が指摘されたコンポーネントの存在や依存関係を迅速に把握できなければ、被害拡大の要因になります。\n\nこのような背景から、ソフトウェアの構成要素を詳細に可視化し、脆弱性や不正コードの混入を早期に検知できるSBOMの重要性が高まっています。\n\n#### 2-1-1 アメリカの大統領令のひとつにSBOMの提供が挙げられたことも\n\n2020年に発生したSolarWinds事件は、サプライチェーン攻撃の脅威を世界に示した象徴的な出来事です。この事件では、SolarWinds社が提供するツールを通じてマルウェアが配布され、約17,000の企業・組織に影響を与えています。\n\nこれを受け、2021年にはアメリカ政府が「国家のサイバーセキュリティ向上に関する大統領令」を発令しました。この中でSBOMの提供が重要な要件として位置づけられ、連邦政府機関に製品を提供するソフトウェア開発者や供給者は、正確なSBOMを提供することが求められるようになりました。\n\n### 2-2 OSSの普及\n\nOSSは、現代のソフトウェア開発において不可欠な要素のひとつです。OSSの活用は、開発コストの削減や開発スピードの向上、品質の確保など、多くのメリットをもたらします。\n\n一方で、OSSの利用拡大に関しては、一部課題もあります。特に深刻なのが、OSSコンポーネントを標的としたサプライチェーン攻撃の増加です。また、使用しているOSSの脆弱性対応やライセンスコンプライアンスの確保も、重要な課題となっています。\n\nこのような課題を解決するためにも、OSSを含めコンポーネントのバージョンやライセンス情報まで管理できるSBOMの有効性が注目されるようになりました。\n\n### 2-3 経済産業省による推進\n\n日本でSBOMへの注目が高まっている要因のひとつとして、経済産業省による積極的な推進も挙げられます。同省では、サイバーセキュリティリスクの増大に対応するため、SBOMの活用を含めた包括的なセキュリティ対策の強化を推進しています。\n\nたとえば、2024年8月には、SBOMを導入する具体的なメリットや導入プロセスを詳細に解説した「[ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0](https://www.meti.go.jp/press/2023/07/20230728004/20230728004-3.pdf)」が公開されました。\n\nまた、中小企業も含め、あらゆる企業でSBOM導入を効率的に活用できるよう、検討会や啓発活動も行われています。これらの取り組みにより、SBOMは今後さらに普及が進んでいくでしょう。\n\n## 3. SBOMを導入すべき理由とその効果\n\n![SBOMとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF.jpg)\n\nSBOMの導入によって、セキュリティリスクの可視化や脆弱性管理の効率化など、多くのメリットがあります。ここでは、SBOMを導入すべき理由とその効果について詳しく解説します。\n\n### 3-1 ソフトウェアサプライチェーンリスクの可視化\n\nSBOMを導入する最大のメリットのひとつは、ソフトウェアサプライチェーンのリスクを可視化できる点です。開発・運用するソフトウェアの全構成要素が一覧化され、各コンポーネントのバージョンや依存関係を明確に把握できるため、効率的かつ効果的なセキュリティ対策が可能となります。\n\n特に、複数のベンダーが関与する大規模なシステム開発において、すべてのコンポーネントが同じセキュリティ基準を満たしているかを確認するのは容易ではありません。一方、SBOMがあれば、各ベンダーが提供するソフトウェア部品のセキュリティ状況を統一的に管理でき、潜在的な不備やリスクを早期に発見できます。\n\nこのように、SBOMは組織のセキュリティリスク管理を強化し、セキュリティ事故を未然に防ぐための重要な基盤となります。\n\n### 3-2 脆弱性管理の効率化と迅速な対応\n\nSBOMを活用すると、システム全体の脆弱性管理を大幅に効率化できます。特に、新たな脆弱性が報告された際の迅速な対応が可能になるのは大きなメリットです。SBOMがあれば、脆弱性が指摘されたコンポーネントや、セキュリティリスクの高い古いバージョンのソフトウェアを即座に特定し、対処することができます。\n\nさらに、各コンポーネント間の依存関係も詳細に記録されているため、特定の脆弱性が他の部品に与える影響範囲の正確な把握が可能です。これにより、問題解決に向けた対応を効率的に進められ、被害を最小限に抑えられます。\n\nこのような迅速で正確な対応力は、セキュリティ事故への対処だけでなく、顧客や取引先からの信頼を維持するためにも欠かせません。\n\n### 3-3 コンプライアンス対応とライセンス管理\n\nSBOMは、ソフトウェア開発におけるコンプライアンス対応とライセンス管理の効率化を支援する強力なツールです。特にOSSを利用する場合、それぞれのコンポーネントには固有のライセンス条件が設定されており、これらを適切に管理しなければなりません。\n\nSBOMを活用すると使用しているOSSのライセンス情報を正確かつ迅速に確認できるため、ライセンス違反のリスクを回避できます。これにより、法的トラブルやブランドイメージの毀損といった事態も防げるでしょう。\n\nまた、ライセンス管理を手動で行う場合、見落としや記録ミスが発生しやすく、チェックに多くの時間を要するケースがあります。SBOMを活用するとライセンス情報の管理を自動化でき、運用効率が大幅に向上するのもメリットのひとつです。\n\n### 3-4 コスト削減や開発の効率化\n\nSBOMの導入は、組織全体のコスト削減や開発の効率化にも寄与します。まず、脆弱性の特定やライセンス違反の確認にかかる手間を大幅に削減できるため、人的リソースの効率的な活用が可能になります。\n\nまた、セキュリティリスクの早期発見と対応が可能になることで、インシデントへの対処や顧客補償にかかるコストを抑えられる点も大きなメリットです。加えて、ライセンス違反による法的対応コストや、プロジェクトの遅延によるペナルティコストなども抑えられます。\n\nさらに、ソフトウェアの全体構成が明確になるため、新しい機能追加やメンテナンス作業も効率的に行えます。そのため、SBOMの活用は、結果として開発チームの生産性の向上にもつながるでしょう。\n\n## 4. SBOMツールを導入する際の課題\n\n![SBOMとは4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF4.jpg)\n\nSBOMを作成するには、専用ツールの導入が一般的です。しかし、適切なツールの選定や運用に必要なリソースの確保といった課題に直面するケースも少なくありません。ここでは、SBOMツールの導入時に、特に注意しておきたい2つの課題を紹介します。\n\n### 4-1 ツール選びが難航する可能性がある\n\nSBOMツールは有償版と無償版を含め多くの選択肢があり、それぞれの特徴を理解したうえで適切なツールを選定しなければなりません。\n\n有償ツールは機能が豊富でサポートが充実していますが、導入コストが高くなる傾向があります。一方、無償ツールはコスト負担が少ないものの、機能やサポート範囲が限定的な場合が多く、使い方によっては十分な効果が得られない可能性があります。さらに、海外製のSBOMツールは問い合わせやサポートが英語のみの場合もあり、言語の壁が障害となるケースも考えられます。\n\nこのように、SBOMツールを選定する際には、ツールの特性だけでなく、自社のニーズやリソースに適合しているかを慎重に評価することが重要です。\n\n### 4-2 SBOMの運用には十分なリソースが必要\n\nSBOMを効果的に運用するには、まずツールを使いこなすための専門知識とスキルを持つ人材が必要不可欠です。特に、SBOMの作成や更新、脆弱性情報のモニタリング、影響範囲の分析といった業務を適切に行うには、高度なスキルと経験が求められます。また、有償ツールを導入する場合には、ライセンス料や月額費用といった運用コストが発生するため、予算の確保も課題のひとつです。\n\nさらに、SBOM運用の効果を十分に発揮するためには、運用プロセスの標準化や体制の整備も必要です。運用体制が不十分だとSBOMの管理が滞り、結果としてセキュリティリスクの増大やコンプライアンス違反などを招く可能性が高まります。\n\nこのように、SBOMの効果を最大限に引き出すには十分なリソースを確保する必要があり、これらが不足すると適切に運用できないおそれがあるため、注意が必要です。\n\n## 5. SBOMを導入する流れ\n\n![SBOMとは2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF2.jpg)\nSBOMを導入するには、社内体制の整備やツールの選定、解析作業など、いくつかのステップを踏む必要があります。スムーズに導入を進められるよう、事前に各工程のポイントを把握しておきましょう。以下で、具体的なSBOM導入の流れを解説します。\n\n### 5-1 社内体制の構築\n\nSBOMを効果的に導入・運用するためには、まず社内体制を整える必要があります。SBOM活用を推進する責任者を配置し、組織体制を整備しましょう。また、課題でも触れたように、実際にSBOMを管理・運用できる専門的な知識やスキルを持つ人材の確保も欠かせません。さらに、作成したSBOMの管理体制や管理方法を事前に決定しておくと、スムーズに運用を開始できます。\n\n### 5-2 SBOMツールの選定\n\nSBOMツールは、自社の目的や規模に応じたものを選ぶことが重要です。経済産業省の手引では、次のような選定観点の例が示されています。\n\n* 機能  \n* 性能  \n* 解析可能な情報  \n* データ形式  \n* コスト  \n* 対応フォーマット  \n* コンポーネント解析方法  \n* サポート体制  \n* 他ツールとの連携  \n* 提供形態  \n* ユーザーインターフェース  \n* 運用方法  \n* 対応するソフトウェア開発言語  \n* 日本語対応 など\n\nこれらに関して自社の制限や優先度を明確にした上で、最適なSBOMツールを選びましょう。\n\n参考：[ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ～全体概要～（経済産業省）](https://www.meti.go.jp/press/2023/07/20230728004/20230728004-3.pdf)\n\n### 5-3 コンポーネントの解析\n\n選定したSBOMツールを導入したら、対象ソフトウェアのスキャンを行い、コンポーネントを解析します。この段階で、誤検出や検出漏れがないかを慎重に確認しておかなければなりません。特に、重要なコンポーネントが漏れている場合、脆弱性やライセンスの管理に重大な影響を及ぼす可能性があるため、解析結果を丁寧に精査することが大切です。\n\n### 5-4 SBOMの作成と共有\n\n解析したコンポーネントのデータをもとに、SBOMを作成します。SBOMのフォーマットや項目、出力ファイル形式などについてあらかじめ基準を決めておくと、効率的にSBOMの作成を進められます。また、SBOMを対象ソフトウェアの利用者やサプライヤーに共有する際は、その方法についても事前に検討しておきましょう。\n\nたとえば、クラウドストレージやWebサイト、製品への組み込みなど、SBOMの共有方法にはいくつかの選択肢があります。公開範囲やデータ改ざん防止策、サプライヤーからの要件なども踏まえて、適切な方法を採用してください。\n\n### 5-5 SBOMの運用と管理\n\nSBOMは作成して終わりではなく、継続的な運用と管理が求められます。定期的に脆弱性スキャンを実施し、セキュリティ事故やコンプライアンス違反のリスクがないか確認しましょう。脆弱性情報が自動更新・通知されるツールを活用すれば、効率的かつ正確な運用が可能です。さらに、ソフトウェアのアップデートや新規コンポーネントの追加があった際にはSBOMも適宜更新し、常に最新の状態を保つ必要があります。\n\n### 5-6 SBOMの運用にAIを活用する方法も\n\nSBOMを効率的に運用・管理するために、AIを活用する方法もあります。過去の脆弱性データからSBOMに含まれるコンポーネントの潜在的なリスクを事前に予測する機能や、ソフトウェアの更新やコンポーネントの追加に応じて自動でSBOMを作成・更新する機能を活用すれば、管理負担の大幅な軽減が可能です。\n\n例えば、AI搭載のDevSecOpsプラットフォーム「[GitLab](https://about.gitlab.com/ja-jp/)」はSBOMを生成する機能がソースコード管理サービスと一体化していて、普段のソフトウェア開発とコンテキストスイッチなしに即時可視化状況を確認できるなど、独自の機能を備えています。\n\nまた、SBOMと脆弱性スキャンを連携させることで、依存コンポーネントの脆弱性を自動検出し、修復提案まで一元的に管理できるため、セキュリティ対策の効率が大幅に向上します。\n\n手間を削減しながらSBOMを適切に管理したい場合は、このような高性能なツールの活用を検討するとよいでしょう。\n\n## まとめ：SBOMを活用したセキュリティ対策が求められる\n\nSBOMは、ソフトウェアの構成要素を可視化し、脆弱性やライセンスの管理を効率的に行うための重要なツールです。特に、近年増加しているソフトウェアサプライチェーン攻撃やOSSの普及に伴うセキュリティリスクへの対策として、SBOMの注目度が高まっています。\n\nさらに、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)にセキュリティを融合させた「[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)」の実践においても、SBOMは重要な役割を果たします。セキュリティを確保しながら迅速に開発を進めたい場合にも、SBOMツールの活用を検討してみてください。\n\nより詳しい情報や、今後の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の展開について知りたい方は、ぜひ「2024 グローバルDevSecOpsレポート」をご活用ください。世界各地のDevSecOps専門家5000名を対象に行った調査結果をご覧いただけます。\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-sbom)  \n\n*監修：ハシュカ アンドリュー / Andrew Haschka [@ahaschka](https://gitlab.com/ahaschka)\u003Cbr>\n（GitLab フィールド最高技術責任者）*",[722,702,1191,825],{"slug":1784,"featured":92,"template":681},"what-is-sbom","content:ja-jp:blog:what-is-sbom.yml","What Is Sbom","ja-jp/blog/what-is-sbom.yml","ja-jp/blog/what-is-sbom",{"_path":1790,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1791,"content":1797,"config":1805,"_id":1807,"_type":16,"title":1808,"_source":17,"_file":1809,"_stem":1810,"_extension":20},"/ja-jp/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"title":1792,"description":1793,"ogTitle":1792,"ogDescription":1793,"noIndex":6,"ogImage":1794,"ogUrl":1795,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1795,"schema":1796},"今すぐ対策を：Docker Hubのレート制限がGitLab CI/CDに与える影響","Docker Hubの新しいプルレート制限がGitLabのパイプラインにどのような影響を与えるか、また、その影響によってCI/CDパイプラインが中断されるのを防ぐ対策を解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","https://about.gitlab.com/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"今すぐ対策を：Docker Hubのレート制限がGitLab CI/CDに与える影響\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-03-24\",\n      }",{"title":1792,"description":1793,"authors":1798,"heroImage":1794,"date":1800,"body":1801,"category":1802,"tags":1803,"updatedDate":1804},[1799],"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","bulletin-board",[110,700,904],"2025-03-31",{"slug":1806,"featured":92,"template":681},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd","content:ja-jp:blog:prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd.yml","Prepare Now Docker Hub Rate Limits Will Impact Gitlab Ci Cd","ja-jp/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd.yml","ja-jp/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"_path":1812,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1813,"content":1819,"config":1825,"_id":1827,"_type":16,"title":1828,"_source":17,"_file":1829,"_stem":1830,"_extension":20},"/ja-jp/blog/gitlab-17-10-release",{"title":1814,"description":1815,"ogTitle":1814,"ogDescription":1815,"noIndex":6,"ogImage":1816,"ogUrl":1817,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1817,"schema":1818},"GitLab 17.10リリース","GitLab 17.10でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662230/Blog/Hero%20Images/product-gl17-blog-release-cover-17-10-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-10-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.10リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-03-20\",\n      }",{"title":1814,"description":1815,"authors":1820,"heroImage":1816,"date":1821,"body":1822,"category":701,"tags":1823,"updatedDate":1824},[738],"2025-03-20","## GitLab Duoコードレビューと根本原因分析を備えたGitLab 17.10をリリース\n\nこのたび、GitLab 17.10のリリースを発表しました。このリリースでは、GitLab Duoコードレビュー（ベータ版）、GitLab DuoSelf-Hostedの根本原因分析、GitLabクエリ言語（GLQL）ビュー（ベータ版）、DORAメトリクスを活用したDevOpsパフォーマンスの新しい可視化機能など、さまざまな機能が追加されました！\n\nこれらの機能は、今回のリリースに含まれる115件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 17.10には、GitLabコミュニティのユーザーから205件ものコントリビュートがありました。ありがとうございました！\n\nGitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ](https://about.gitlab.com/upcoming-releases/)をご覧ください。\n\n> [GitLab 17.10では、GitLab-Duoコードレビューと根本原因分析が追加されました。\nクリックしてSNSで共有しましょう！](https://x.com/intent/post?text=GitLab+17.10%E3%81%A7%E3%81%AF%E3%80%81GitLab%C2%B7Duo%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%A8%E6%A0%B9%E6%9C%AC%E5%8E%9F%E5%9B%A0%E5%88%86%E6%9E%90%E3%81%8C%E8%BF%BD%E5%8A%A0%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%81%97%E3%81%A6SNS%E3%81%A7%E5%85%B1%E6%9C%89%E3%81%97%E3%81%BE%E3%81%97%E3%82%87%E3%81%86%EF%BC%81%0D%0A&url=https%3A%2F%2Fabout.gitlab.com%2Fja-jp%2Fblog%2F2025%2F03%2F20%2Fgitlab-17-10-release%2F)\n\n## 今月の[MVP](https://about.gitlab.com/community/mvp/)は[Alexey Butkeev](https://gitlab.com/abutkeev)さんが受賞\n\nMVPには、誰もが[GitLabコミュニティのコントリビューターを推薦](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)できます。現在の候補者を応援したり、他の誰かをノミネートしてみませんか？🙌\n\n[Alexey Butkeev](https://gitlab.com/abutkeev)さんは、GitLabのグローバルな展開とユーザーエクスペリエンスの向上に貢献する、貴重なコミュニティメンバーです。Alexeyさんの影響力のあるローカライゼーションと翻訳を通じた貢献は、当コミュニティの多様性、インクルージョン、帰属意識の価値観を体現しています。\n\n「GitLab 17.10のMVPに選ばれ、とても光栄です。GitLabをより使いやすく、包括的なものにするために貢献できることを嬉しく思います」とAlexeyさんは話します。「ローカライズはチームワークで成り立つものであり、支え合いの文化が深く根付いたコミュニティの一員であることに感謝しています。」\n\nコードへの貢献に加えて、AlexeyさんはGitLabとCrowdinを活用し、翻訳の誤りを発見・記録・修正する取り組みにも率先して取り組みました。その綿密なリサーチと問題解決能力が評価され、GitLab 17.10のMVPに選ばれました。\n\nAlexeyさんは、GitLabのグローバリゼーションテクノロジーのシニアマネージャーである[Oleksandr Pysaryuk](https://gitlab.com/opysaryuk)によって推薦され、GitLabのグローバリゼーション＆ローカライゼーションのディレクターである[Daniel Sullivan](https://gitlab.com/djsulliv)からも支持を受けました。「GitLabでのあなたの貢献とサポートに心から感謝しています」とDanielは言います。「GitLabが世界中でより多くの人に支持される企業となるために、ご尽力いただき本当にありがとうございます！」\n\nGitLabをより包括的で透明性の高いものにしてくれたAlexeyさん、ありがとうございます！\n\u003Cbr>\n\u003Cbr>\n\u003Cbr>\n\n## GitLab 17.10でリリースされた主な改善点\n\n### GitLab Duoコードレビュー（ベータ版）\n\nSaaS: Ultimate、Duo Enterprise\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nコードレビューは、ソフトウェア開発において不可欠な作業です。コードレビューを行うことで、プロジェクトへの新たなコントリビュートが確実にコード品質とセキュリティの保証と強化につながります。また、エンジニアに指導やフィードバックの場を提供できます。しかし、ソフトウェア開発プロセスにおいて特に時間がかかる作業でもあります。\n\nGitLab Duoコードレビューは、コードレビュープロセスの次世代の姿です。\n\nGitLab Duoコードレビューを使用すれば、開発プロセスを高速化できます。GitLab Duoコードレビューを使用してマージリクエストで最初のレビューを実行すると、潜在的なバグを特定し、改善点を提案してくれます。提案内容の一部はブラウザから直接適用できます。それをもとにイテレーションを行い、レビュープロセスに別の担当者を追加する前に、変更内容を改善します。\n\n__試してみましょう。__\n\n- すぐにコードレビューを開始するには、マージリクエストにレビュアーとして`@GitLabDuo`を追加してください。  \n- 変更内容に関するフィードバックを改良するには、コメントで`@GitLabDuo`をメンションしてください。\n\n今後の進捗状況に関しては、エピック[13008](https://gitlab.com/groups/gitlab-org/-/epics/13008)と関連する子エピックで追跡できます。フィードバックは、イシュー[517386](https://gitlab.com/gitlab-org/gitlab/-/issues/517386)で投稿できます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code)  \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16298)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/FlHqfMMfbzQ?si=k5-Vl_w3zIJDSx9u\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### GitLab Duo Self-Hostedで根本原因分析が利用可能に\n\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nGitLab Duo Self-Hostedで[GitLab Duo根本原因分析](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)を利用できるようになりました。この機能は、GitLab Duo Self-Hostedを使用しているGitLab Self-Managedインスタンス向けのベータ版です。Mistral、Anthropic、OpenAI GPTモデルファミリーをサポートしています。\n\nGitLab Duo Self-Hostedで根本原因分析を使用すると、データ主権を損なうことなく、CI/CDパイプラインで失敗したジョブのトラブルシューティングをより迅速に行えます。根本原因分析は、失敗したジョブのログを分析してその根本原因を素早く特定し、修正方法を提案します。\n\nGitLab Duo Self-Hostedの根本原因分析機能に関するフィードバックは、[イシュー523912](https://gitlab.com/gitlab-org/gitlab/-/issues/523912)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/#supported-gitlab-duo-features)  \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13759)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/RCA_beta_17.10_min.png\">\n\n### GitLab Dedicatedフェイルオーバーインスタンスのホスティング先として利用可能なAWSリージョンを追加\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: -\n\nAWSリージョンのリストが拡大され、GitLab Dedicatedをご利用のお客様は、[ディザスタリカバリ](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/#disaster-recovery)用にフェイルオーバーインスタンスをホストする場所として、より多くのリージョンを選択できるようになりました。\n\nフェイルオーバー対応リージョンの拡大により、GitLab Dedicatedのユーザーは、データレジデンシーのニーズを満たすために選択するAWSリージョンに関係なく、GitLab Dedicatedのディザスタリカバリ機能を最大限に活用できるようになりました。\n\n今回新たに追加されたリージョンは、GitLab Dedicatedが必要とする一部のAWS機能を完全にはサポートしていないため、フェイルオーバーインスタンスのホスティング先としてのみ利用可能です。\n\n[ドキュメント](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/)   \n[イシュー](https://about.gitlab.com/direction/saas-platforms/dedicated/#theme-global-availability)  \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/switchboard-secondary-region.png\">\n\n### GitLabクエリ言語ビュー（ベータ版）\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまで、GitLab全体で進行中の作業を追跡して理解するには、複数箇所にアクセスする必要がありました。そのため、チームの効率が下がり、貴重な時間が費やされていました。\n\n本リリースでは、GitLabクエリ言語（GLQL）ビューのベータ版が導入され、現在のワークフロー内で直接、リアルタイムで動的な作業追跡ディレクトリを作成できるようになりました。\n\nGLQLビューは、あらゆるWikiページ、エピックの説明、イシューのコメント、マージリクエスト内のMarkdownコードブロックにライブデータクエリを埋め込みます。\n\nこれまでGLQLビューは実験的機能として提供されていました、本リリースから、担当者、作成者、ラベル、マイルストーンなどの主要なフィールドで論理式と演算子を使用した高度なフィルタリングをサポートし、ベータ版として提供されます。ビューの表示方法を表形式またはリスト形式にカスタマイズしたり、表示されるフィールドの制御や結果の制限の設定を行ったりできるため、チーム向けに焦点を絞った実用的なインサイトを得られます。\n\nチームは現在のワークフローから離れずに、コンテキストを維持しながら、必要な情報にアクセスできます。また、メンバー間で共通認識を持ち、コラボレーションを改善できるようになりました。\n\n今後もこの機能を改善していく予定ですので、ぜひ[フィードバックをお寄せください](https://gitlab.com/gitlab-org/gitlab/-/issues/509791)。\n\n[ドキュメント](https://docs.gitlab.com/user/glql/#glql-views)  \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14938)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/CML0hefVwSA?si=y8loas4VYVx1KDFT\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### Markdownの利用体験の向上\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab Flavored Markdownに以下の改善点が加えられ、大幅に強化されました。\n\n__- 数式と画像処理の機能向上：__\n  -  より複雑な数式を扱えるように、グループやセルフホストインスタンスの[数式レンダリング](https://docs.gitlab.com/user/markdown/#math-equations)の制限を無効化 \n  -  コンテンツのレイアウトをより適切に管理できるように、ピクセル値またはパーセンテージを使用して[画像の寸法](https://docs.gitlab.com/user/markdown/#change-image-or-video-dimensions)を正確に制御\n\n__- エディタの利用体験の向上：__\n  -  Enter/Returnキーが押された際に、自動的にリストを続行\n  -  キーボードショートカットを使用して、テキストを左右にシフト\n  -  説明リストの構文を使用して、明確な用語と定義のペアを作成\n  -  動画の幅を柔軟に調整\n\n__- より効果的なコンテンツ整理：__\n  - 自動展開される[サマリークイックビュー](https://docs.gitlab.com/user/markdown/#show-item-summary)を用いて、より簡単にコンテンツにアクセス（URLに`+s`を追加）  \n  * 参照先の[イシュータイトル](https://docs.gitlab.com/user/markdown/#show-item-title)を自動的にレンダリング（URLに`+`を追加）  \n  * [include構文](https://docs.gitlab.com/user/markdown/#includes)を使用して、コンテンツをモジュール化して整理  \n  * [アラートボックス](https://docs.gitlab.com/user/markdown/#alerts)を使用して、視覚的にわかりやすい吹き出しや警告を作成\n\nGitLab Flavored Markdownのこれらの機能強化により、ドキュメントを作成・メンテナンスするチームは、より柔軟にコンテンツの表示・整理を行えます。\n\n[ドキュメント](https://docs.gitlab.com/user/markdown/)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/7654)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/enhanced_markdown_experience.png\">\n\n### DORAメトリクスを用いてプロジェクト全体のDevOpsパフォーマンスを新たに視覚化\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\n[バリューストリームダッシュボード](https://www.youtube.com/watch?v=EA9Sbks27g4)に新たに「**DORAメトリクスによるプロジェクト**」パネルが追加されました。この表形式のパネルには、トップレベルグループの全プロジェクトが[4つのDORAメトリクス](https://about.gitlab.com/solutions/value-stream-management/dora/#overview)の詳細とともに一覧表示されます。マネージャーはこの表を使用して、パフォーマンスが高、中、低レベルのプロジェクトを識別できます。また、この情報を参考にして、データドリブンの意思決定や、リソースの効果的な割り当てを行えるほか、ソフトウェアデリバリーのスピード、安定性、信頼性を向上させる取り組みに注力できます。\n\n[DORAメトリクス](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html)はGitLabですぐに利用可能であり、[DORAパフォーマースコアパネル](https://about.gitlab.com/blog/inside-dora-performers-score-in-gitlab-value-streams-dashboard/)と一緒に使用することで、経営陣は組織のDevOpsの健全性を包括的かつ完全に把握できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#projects-by-dora-categories) \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/408516)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/17.7_vsd_dora_table2.png\">\n\n### 新しいイシューの外観（ベータ版）\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n本リリースから、イシューはエピックやタスクと共通のフレームワークを使用するようになり、リアルタイムで更新されるとともに、ワークフローが改善されました。\n\n- **ドロワー表示：** リストやボードのアイテムをドロワーで開いて、現在のコンテキストを保持したまま、素早く閲覧できます。上部のボタンを使用すると、全ページ表示に切り替わります。  \n* **タイプの変更：** 「タイプを変更」アクションを使用して、エピック、イシュー、タスク間でタイプを変換（「エピックへのプロモート」の後継となるアクション）できます。  \n* **開始日：** イシューで開始日がサポートされるようになり、エピックやタスクと機能が統一されました。  \n* **祖先：** タイトルとサイドバーの親フィールドの上に完全な階層が表示されます。関係を管理するには、新しい[クイックアクション](https://docs.gitlab.com/user/project/quick_actions/) コマンド`/set_parent（親を設定）`、`/remove_parent（親を削除）`、`/set_child（子を設定）`、および`/remove_child（子を削除）`を使用してください。  \n* **コントロール：** すべてのアクションに上部のメニュー（縦方向の省略記号）からアクセスできるようになりました。スクロールした場合でも消えずにヘッダーに表示されます。  \n* **開発：** イシューやタスクに関連するすべての開発アイテム（マージリクエスト、ブランチ、機能フラグ）が1つの便利なリストに統合されました。  \n* **レイアウト：** UIが改善され、イシューやエピック、タスク、マージリクエスト間でよりシームレスな体験ができるようになり、ワークフローをより効率的に進められるようになりました。  \n* **リンクされたアイテム：** 改善されたリンクオプションを使用して、タスク、イシュー、エピックの関係を作成できるようになりました。ドラッグ＆ドロップでリンクのタイプを変更したり、ラベルや完了したアイテムの表示を切り替えたりできます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/issues/issue_work_items/)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/523713)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/focused-drawer-new-issues.png\">\n\n### エピック、イシュー、タスク、目標、主な結果用の説明テンプレート\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n作業アイテム（エピック、タスク、目標、主な結果）用の説明テンプレートを使用して、ワークフローを効率化し、プロジェクト全体で一貫性を確保できるようになりました。\n\nこの強力な機能の実装により、標準化されたテンプレートを作成できるため、作業時間を削減するとともに、新たな作業アイテムの作成時に重要な情報を漏れなく含められます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/description_templates.html)  \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16088)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/description_template.png\">\n\n### 脆弱性の重大度の変更\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\n脆弱性をトリアージする際は、組織固有のセキュリティコンテキストとリスク許容度に基づいて、柔軟に重大度を調整できなければなりません。これまでは、セキュリティスキャナーによって割り当てられるデフォルトの重大度レベルを使用せざるを得ませんでしたが、これでは特定の環境のリスクレベルを正確に反映できないことがあります。\n\n本リリースでは、組織のセキュリティニーズに合わせて、個別の脆弱性の重大度を手動で変更できるようになりました。具体的には、以下を行えるようになります。\n\n* 脆弱性の重大度レベルを **「致命的」、「高」、「中」、「低」、「情報」、「不明」** のいずれかに調整  \n* 脆弱性レポートから複数の脆弱性の重大度を一括で変更  \n* 視覚的なインジケーターにより、重大度レベルがカスタマイズされている脆弱性を簡単に特定\n\nすべての重大度の変更は、脆弱性情報の履歴および監査イベントで追跡され、プロジェクトのメンテナーロール以上、または`admin_vulnerability`権限を持つカスタムロールのチームメンバーのみが上書きできます。この機能により、セキュリティチームは脆弱性の優先順位付けをより柔軟に制御できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerability_report/#change-or-override-vulnerability-severity)  \u003Cbr>\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/16157)  \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/severity-override.png\">\n\n## GitLab 17.10のリリースに含まれるその他の改善点\n\n### To-Doアイテムの一括編集\n\nSaaS: Free、Premium、Ultimate  \u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n改善された一括編集機能を使用して、To-Doリストをより効率的に管理できるようになりました。複数のTo-Doアイテムを選択して、一度に「完了」または「スヌーズ済み」に設定できるため、タスクをより細かく管理できるようになり、少ない手間で整理できます。\n\n[ドキュメント](https://docs.gitlab.com/user/todos#bulk-edit-to-do-items)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/16564)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/bulk_edit_todos.png\">\n\n### To-Doアイテムのスヌーズ機能\n\nSaaS: Free、Premium、Ultimate  \u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nTo-Doリストの通知をスヌーズできるようになりました。重要なタスクに集中したいときに、一時的にアイテムを非表示にできます。作業に集中するために1時間後まで通知を受けたくない場合でも、翌日にタスクを再度確認したい場合でも、通知の再表示タイミングを細かく設定できるため、ワークフローをより効果的に管理できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/todos.html#snooze-to-do-items)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/17712)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/snooze-todo.png\">\n\n### アクセストークンを使用した非公開のPagesサイトでの認証\n\nSaaS: Free、Premium、Ultimate    \u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nアクセストークンを使用することで、プログラム経由で非公開のGitLab Pagesサイトで認証を受けられるようになりました。これにより、Pagesコンテンツとのやり取りを自動化しやすくなります。これまでは、制限付きのPagesサイトにアクセスするには、GitLab UIを通じた対話型認証が必要でした。\n\nこの機能強化により、セキュリティを維持しつつ生産性を向上させ、デベロッパーがより柔軟に非公開Pagesコンテンツを管理・配信できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/user/project/pages/pages_access_control/#authenticate-with-an-access-token)    \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/388)\n\n### ブランチルールでのスカッシュ設定の適用\n\nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\nGitのワークフローによって、ブランチ間のマージ時に適用すべきコミットの処理方法は異なります。以前のバージョンのGitLabでは、マージ時にコミットをスカッシュするかどうかの設定と、その設定をどの程度強制的に適用するかについて、ひとつの方法しか設定できませんでした。この方法では、エラーが発生しやすいほか、プロジェクトの規則に従うために、デベロッパーがそれぞれのブランチターゲットに対して個別に判断を下す必要があるといった問題がありました。\n\n今回のアップデートにより、ブランチルールを使用して、保護ブランチごとにスカッシュ設定を適用できるようになりました。たとえば、以下のような設定が可能です。\n\n* `feature`ブランチから`develop`ブランチへのマージ時にスカッシュを必須にすることで、履歴を整理しやすくする。  \n* `develop`ブランチから`main`ブランチへのマージ時にスカッシュを無効にすることで、詳細なコミット履歴を保持する。\n\nこれにより、デベロッパーが手動で調整する必要もなく、プロジェクト全体のコミット履歴を一貫性を保ちながら管理でき、ワークフローにおける各ブランチの固有のニーズにも柔軟に対応できます。\n\n[ドキュメント](https://docs.gitlab.com/user/project/repository/branches/branch_rules/#edit-squash-commits-option)    \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15526)\n\n### CODEOWNERSのパス除外設定\n\nSaaS: Premium、Ultimate    \u003Cbr>\nSelf-Managed: Premium、Ultimate\n\n`CODEOWNERS`ファイルを設定する際は、パスやファイルタイプに対する広範な一致パターンを含めることが一般的です。しかし、一部のドキュメントや自動ビルドファイル、その他のパターンでは、指定されたコードオーナーを必要としない場合があり、このような広範な設定が問題となる可能性があります。\n\n今回のアップデートで、`CODEOWNERS`ファイルにパス除外設定を追加することで、特定のパスを無視できるようになりました。これは、特定のファイルやパスをコードオーナーの承認対象から除外する場合に便利です。\n\n[ドキュメント](https://docs.gitlab.com/user/project/codeowners/reference/#exclusion-patterns)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/41914)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/create-codeowners-exclusions.png\">\n\n### 依存プロキシでのDocker Hub認証\n\nSaaS: Free、Premium、Ultimate  \u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nコンテナイメージのGitLab依存プロキシで、Docker Hubでの認証をサポートするようになりました。これにより、レート制限によるパイプラインの失敗を防ぎ、プライベートイメージへのアクセスが可能になります。\n\n2025年4月1日から、Docker Hubは未認証ユーザーに対してより厳しいプル制限（IPアドレスごとに10回のプル）を適用します。この制限に達すると、認証なしでのパイプライン実行が失敗する可能性があります。\n\n本リリースから、Docker Hubの認証情報や[パーソナルアクセストークン](https://docs.docker.com/security/for-developers/access-tokens/)、[組織アクセストークン](https://docs.docker.com/security/for-admins/access-tokens/)を使って、GraphQL APIを介してDocker Hub認証を設定できるようになりました。UI設定のサポートはGitLab 17.11で提供予定です。\n\n[ドキュメント](https://docs.gitlab.com/user/packages/dependency_proxy/#authenticate-with-docker-hub)   \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/331741)\n\n### 依存関係スキャンでのpub（Dart）パッケージマネージャーのサポート\n\nSaaS: Ultimate   \u003Cbr>\nSelf-Managed: Ultimate\n\n依存関係スキャンに、Dartの公式パッケージマネージャーであるpubのサポートが追加されました。このサポートは、依存関係スキャンの[最新テンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.latest.gitlab-ci.yml)および[CI/CDコンポーネント](https://gitlab.com/explore/catalog/components/dependency-scanning)に組み込まれています。\n\nこの追加は、ユーザーのAlexandre Larocheさんがコミュニティにコントリビュートしてくれたために実現しました。GitLabコンポジション解析チームは、製品向上へのコントリビュートに大変感謝しています。Alexandreさん、ありがとうございます。GitLabへのコントリビュート方法について、詳しくは[コミュニティコントリビュートプログラム](https://about.gitlab.com/community/contribute/)をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_scanning/#supported-languages-and-package-managers)   \u003Cbr>\n[エピック](https://gitlab.com/gitlab-org/security-products/analyzers/dependency-scanning/-/merge_requests/141)\n\n### GitLab OIDCプロバイダーによるトークン有効期限の設定\n\nSaaS: - \u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\nGitLabをOpenID Connect（OIDC）プロバイダーとして使用する際、`id_token_expiration`属性を使って、IDトークンの有効期限を設定できるようになりました。これまで、IDトークンの有効期限は120秒と決められていました。\n\nこの場を借りて、コントリビュートしてくれた[Henry Sachs](https://gitlab.com/DerAstronaut)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/auth/oidc.html#configure-a-custom-duration-for-id-tokens)   \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/377654)\n\n### トークン情報APIを使用したトークンの識別と失効\nSaaS: - \u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nGitLabの管理者は、統一されたAPIを使用してトークンを識別し、失効できるようになりました。これまで、管理者は特定のトークンタイプに関連するエンドポイントを使用する必要がありましたが、新たに追加されたAPIを使用すれば、トークンタイプに関係なく失効が可能です。サポートされているトークンタイプのリストについては、「[トークン情報API](https://docs.gitlab.com/ee/api/admin/token.html)」を参照してください。\n\nこの場を借りて、コントリビュートしてくれた[Nicholas Wittstruck](https://gitlab.com/nwittstruck)さんを始め、シーメンス社チームに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/api/admin/token.html)  \u003Cbr>\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/15777)\n\n### ドロップダウンリストからデフォルトのコンプライアンスフレームワークを選択可能に\n\nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\nユーザーは、GitLabコンプライアンスセンターでデフォルトのコンプライアンスフレームワークを設定でき、この設定はそのグループで作成される新しいプロジェクトやインポートされたプロジェクトに適用されます。デフォルトのコンプライアンスフレームワークには、ユーザーが識別しやすいように **デフォルト** というラベルが付いています。\n\nデフォルトのコンプライアンスフレームワークを設定しやすくするために、トップレベルグループのコンプライアンスセンター内のフレームワーク一覧ページで、ドロップダウンリストからフレームワークをデフォルトとして設定できる機能を追加しました。この機能は、サブグループやプロジェクトのコンプライアンスセンターでは利用できません。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_frameworks_report/#set-and-remove-a-compliance-framework-as-default)\u003Cbr>\n[エピック](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/181500)\n\n### トークンの有効期限通知の送信範囲を拡大\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまで、アクセストークンの有効期限通知メールは、トークンが期限切れになるグループやプロジェクトのダイレクトメンバーにのみ送信されていました。本リリースでは、設定を有効にすると、継承されたグループやプロジェクトのメンバーにも通知が送信されるようになりました。これにより、トークンの有効期限が切れる前に管理しやすくなります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/manage.html#expiry-emails-for-group-and-project-access-tokens)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/463016)\n\n### GitLab Duo Chatのサイズが変更可能に\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\u003Cbr>\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nGitLab UIで、GitLab Duo Chatのドロワーメニューの大きさを変更できるようになりました。これにより、コード出力の表示や、Chatを開いたままバックグラウンドでGitLabを操作することが容易になります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#use-gitlab-duo-chat-in-the-gitlab-ui)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/499849)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/ai-powered-resizable-duo-chat-in-the-web-app.gif\">\n\n### GitLab Duo Chatで複数のチャットを管理\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\u003Cbr>\nSelf-Managed: - \n\nGitLab Duo Chatでは、複数のチャットを並行して管理できるようになり、異なるトピック間でもコンテキストを把握しやすくなりました。新しいチャットの作成、チャット履歴の閲覧、およびチャット間の切り替えを行えます。\n\nこれまでは、新しいチャットを開始すると、既存のチャットの内容が消えてしまっていましたが、今回のアップデートで、別々のトピックに関する複数のチャットを管理できるようになりました。それぞれのチャットで個々の内容が維持されるため、たとえば、あるチャットでコードの説明について補足質問をする一方で、別のチャットで作業計画を準備することができます。\n\n過去のチャットを確認したい場合は、新しいチャット履歴アイコンを選択すれば、最近のチャットをすべて確認できます。チャットは最新のアクティビティ順に自動的に並べ替えられるので、前回の続きからスムーズに再開できます。\n\nプライバシーを保護するために、アクティビティが30日間ないチャットは自動的に削除されます。また、いつでもチャットを手動で削除することが可能です。\n\n現在、この機能はGitLab.comのWeb UIでのみ利用可能で、GitLab Self-ManagedインスタンスやIDE統合では利用できません。\n\n[ドキュメント](https://docs.gitlab.com/user/gitlab_duo_chat/#have-multiple-conversations-with-chat)  \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16108)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/h9ooN05cNbw?si=xNp7Ruzk57l9Kg5y\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### 「マイワーク」内のプロジェクトの新しいナビゲーション体験\n\nSaaS: Free、Premium、Ultimate  \u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nGitLabでは、「**マイワーク**」内のプロジェクト概要に大きな改善を加え、プロジェクトの検索とアクセス方法を効率化しました。このアップデートでは、ユーザーがプロジェクトを操作する方法に合わせて、より直感的なタブ形式のナビゲーションシステムが導入されました。\n\n- 新しい「**コントリビュート済み**」タブ（旧「**あなたの**」）では、自分がコントリビュートしたすべてのプロジェクトが表示されます。個人プロジェクトも含まれるため、開発活動の追跡が容易になります。  \n- 「**個人**」タブを使って、個人で取り組んでいるプロジェクトをすばやく見つけられるようになりました。このタブは、メインナビゲーションにわかりやすく表示されています。  \n- 「**メンバー**」タブ（旧「**すべて**」）では、自分がメンバーであるすべてのチームプロジェクトを確認できます。 \n- 「**無効**」タブ（旧「**削除予定**」）では、アーカイブ済みまたは削除予定のプロジェクトを一目で把握できます。\n\nさらに、適切な権限を持つユーザーは、「**マイワーク**」のプロジェクトの概要から直接プロジェクトを編集または削除できるようになりました。この変更は、より効率的で使いやすいGitLabの提供を目指す取り組みの一環です。新しいレイアウトにより、もっとも重要なプロジェクトに集中しやすくなり、異なるプロジェクトカテゴリ間を行き来する時間を短縮できます。\n\nこのアップデートに関するご意見をお待ちしています。新しいナビゲーションシステムに関するフィードバックを[エピック16662](https://gitlab.com/groups/gitlab-org/-/epics/16662)でぜひお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/project/working_with_projects/)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/465889)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/your_work_new_project_layout.png\">\n\n### CSVファイルを使用した再アサインのリクエスト\n\nSaaS: Free、Premium、Ultimate  \u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n本リリースでは、ユーザーコントリビュートマッピング時に、CSVファイルを使用して一括で再アサインを行えるようになりました。多数のプレースホルダーユーザーを含む大規模なユーザーベースを管理している場合、オーナーロールのグループメンバーは以下の操作を実行できます。\n\n1. あらかじめ項目が設定されたCSVテンプレートをダウンロード  \n2. 移行先インスタンスのGitLabユーザー名または公開メールアドレスを追加  \n3. 入力済みのファイルをアップロードし、一括ですべてのコントリビュートを再アサイン\n\nこの新機能により、UIを使った手動での再アサイン作業の手間を削減できます。さらに、本リリースでは、大規模な移行プロセスを効率化するため、API経由でもCSVを使用した再アサインが可能になりました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/import/#request-reassignment-by-using-a-csv-file)  \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16765)\n\n### プレースホルダーユーザーの作成日時を示すタイムスタンプの追加\n\nSaaS: Free、Premium、Ultimate  \u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまでは、グループやプロジェクトをインポートしても、[プレースホルダーユーザー](https://docs.gitlab.com/user/project/import/#placeholder-users)がいつ作成されたかを確認できませんでした。本リリースでタイムスタンプを追加し、移行の進捗を追跡したり、発生した問題を迅速に特定・対応したりできるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/project/import/#placeholder-user-attributes)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/507297)\n\n### GitLab Duoコード提案およびGitLab Duo Chatの傾向に関する新たなインサイト\n\nSaaS: Ultimate、Duo Enterprise  \u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nAIインパクトダッシュボードのAI比較メトリクスパネルに、GitLab Duoコード提案の採用率とGitLab Duo Chatの使用率（月ごとの比較、パーセント表示）の月次推移を追跡する機能が追加されました。この新しい分析は、既存のGitLab Duoコード提案とGitLab Duo Chatタイルの機能を補完するもので、これまで提供していた30日間のスナップショットに加えて利用できます。新しく追加されたこれらのメトリクスを使用することで、マネージャーはソフトウェア開発プロセスにおけるAIの影響をより正確に測定できるほか、コード提案の採用率とDuo Chatの使用率を他のSDLCメトリクスと長期的に比較することで、パターンを特定できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/analytics/ai_impact_analytics.html) \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/477246)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/17.9_ai_cs_mom.png\">\n\n### Git blameで特定のリビジョンを無視\n\nSaaS: Free、Premium、Ultimate  \u003Cbr> \nSelf-Managed: Free、Premium、Ultimate\n\nリポジトリの履歴を閲覧していると、プロジェクトにおける実質的な変更とは関係のないコミットがある場合があります。これは、次のような場合に発生する可能性があります。\n\n* リファクタリングを行って、機能を変更せずに、あるライブラリから別のライブラリに変更する場合  \n* コードフォーマッターやLinterを実行して、コードベース全体を標準化する場合\n\nこのようなコミットがあると、`blame`を使用してプロジェクト履歴を確認する際に、変更点を把握しにくくなります。Gitでは、プロジェクト内で`.git-blame-ignore-revs`ファイルを使用して、こうしたコミットを特定できます。GitLabでは、blame表示を切り替えて、これらの特定のリビジョンを「Blame環境設定」ドロップダウンリストから表示または非表示にすることができるようになりました。これにより、プロジェクトの履歴を把握しやすくなります。\n\n[ドキュメント](https://docs.gitlab.com/user/project/repository/files/git_blame/#ignore-specific-revisions)  \u003Cbr> \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15751)\n\n### GitLab Runner 17.10\n\nSaaS: Free、Premium、Ultimate  \u003Cbr> \nSelf-Managed: Free、Premium、Ultimate\n\n本日、GitLab Runner 17.10もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドのエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\n新機能：\n\n* [インスタンス使用前にAutoscaler Executorのヘルスチェックを実施](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38271)  \n* [Docker Executorのボリュームを拡張](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38249)  \n* [サービス用のデバイス追加のためのDocker Executor設定を追加](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6208)\n\nバグ修正：\n\n* [Windows `gitlab-runner-helper`イメージが\\`/opt/step-runner’パスの無効なボリューム指定により失敗する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38632)  \n* [GitLab Runner 17.7.0以降のバージョンでRPMパッケージのリポジトリのミラーリングが正常に機能しない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38409)  \n* [GitLab CI/CDで`git submodule update --remote`の実行時にエラーが発生する](https://gitlab.com/gitlab-org/gitlab/-/issues/359825)\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/17-10-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### パッケージレジストリに監査イベントを追加\n\nSaaS: Free、Premium、Ultimate  \u003Cbr> \nSelf-Managed: Free、Premium、Ultimate\n\nパッケージレジストリでの操作が、監査イベントとして記録されるようになりました。これにより、チームはパッケージの公開や削除の履歴を追跡し、コンプライアンス要件を満たすことができるようになります。\n\nこのリリース以前は、パッケージを公開・変更したユーザーを追跡するビルトイン機能はなく、チームは独自に追跡システムを作成したり、パッケージの変更内容を手動で記録したりする必要がありました。今後は、監査イベントが記録され、変更を行ったユーザー、変更の日時、認証方法、パッケージの変更内容を確認できます。\n\nプロジェクトの監査イベントは、グループのネームスペースまたは各プロジェクトオーナーのプロジェクト自体に保存されます。また、グループはストレージ管理のために監査イベントを無効化することもできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/audit_event_types.html)  \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/329588)\n\n### コンプライアンスを守るためのパイプライン実行ポリシーにおける`needs`ステートメントの処理方法\n\nSaaS: Ultimate  \u003Cbr> \nSelf-Managed: Ultimate\n\n本リリースから、パイプライン実行の制御を強化するために、`.pipeline-policy-pre`事前ステージで実施されるジョブは、後続のステージのジョブが開始される前に完了することが必須となりました。これは、ジョブに`needs`ステートメントが定義されているかどうかを問わず適用されます。これまでは、`.pipeline-policy-pre`ステージで定義されたジョブと、`needs`ステートメントを持つ後続のパイプラインのジョブは、パイプラインが実行されるとすぐに開始されていました。今回の改善により、後続のステージのジョブは、依存関係がないジョブの開始前に`.pipeline-policy-pre`ステージが完了するのを待つ必要があります。これにより、順序どおりの実行を強制し、セキュリティポリシーに基づくコンプライアンスを確保します。\n\nGitLabをご利用のお客様は、デベロッパーのジョブが実行される前にセキュリティやコンプライアンスチェックを強制するために事前ステージを活用しています。一般的なユースケースは、セキュリティチェックやコンプライアンスチェックを実施し、そのチェックに合格しなければパイプライン全体を失敗させるという方法です。ジョブが順不同で実行されると、この強制が回避され、ポリシーの意図が弱まる可能性があります。この改善により、コンプライアンスの適用に対するより一貫したアプローチが提供されます。\n\nパイプラインの開始時に、`needs`の動作を上書きせずにジョブを挿入するには、17.9で新たに導入されたカスタムステージ機能を使用して、ジョブを設定してください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html#pipeline-execution-policy-schema)  \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/469256)\n\n### 期限切れトークン向けのWebhookトリガーの拡張\n\nSaaS: Free、Premium、Ultimate  \u003Cbr> \nSelf-Managed: Free、Premium、Ultimate\n\nプロジェクトやグループのアクセストークンが期限切れになる60日および30日前に、Webhookイベントをトリガーできるようになりました。これまで、これらのWebhookイベントは有効期限が切れる7日前にのみトリガーされていました。この機能は任意で設定可能です。有効期限が近づくトークンに関する既存のメール通知スケジュールと同じタイミングでWebhook通知を受け取ることができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/manage.html#add-additional-webhook-triggers-for-group-access-token-expiration)  \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/499732)\n\n### OmniAuthプロファイル属性をユーザーへマッピング可能に\nSaaS: -\u003Cbr> \nSelf-Managed: Premium、Ultimate\n\nOmniAuthアイデンティティプロバイダー（IdP）からGitLabユーザーのプロフィールに、「組織」と「役職」の属性をマッピングできるようになりました。これにより、IdPをこれらの属性に関する信頼できる唯一の情報源として管理でき、ユーザー側での変更ができなくなります。\n\n[ドキュメント](https://docs.gitlab.com/ee/integration/omniauth.html#keep-omniauth-user-profiles-up-to-date)  \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/505575)\n\n### 認証情報インベントリ内でのアクセストークンの並べ替え\n\nSaaS: Ultimate  \u003Cbr> \nSelf-Managed: Ultimate\n\n認証情報インベントリで、個人、プロジェクト、およびグループのアクセストークンを、所有者、作成日、および最終使用日で並べ替えられるようになりました。これにより、アクセストークンの特定および管理をより素早く行えるようになります。この場を借りて、コントリビュートしてくれた[Chaitanya Sonwane](https://gitlab.com/chaitanyason9)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/administration/credentials_inventory/)  \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/513181)\n\n### GitLab Duo Self-Hostedのコード提案でAIインパクトダッシュボードが利用可能に\n\nSaaS: -\u003Cbr> \nSelf-Managed: Ultimate\n\nSelf-Managedインスタンスで、GitLab Duo Self-Hostedのコード提案と合わせてAIインパクトダッシュボードを利用できるようになりました。これにより、GitLab Duoが生産性に及ぼす影響を把握できます。GitLab Duo Self-HostedのAIインパクトダッシュボードはベータ版であり、Visual Studio Code、Microsoft Visual Studio、JetBrains、NeovimのIDEとともにSelf-Managedインスタンスで利用できます。\n\nAIインパクトダッシュボードを使用すると、リードタイム、サイクルタイム、DORA、脆弱性などのメトリクスとAI使用傾向を比較できます。これにより、GitLab Duo Self-Hostedを使用してエンドツーエンドのワークストリームで節約される時間を測定できるため、デベロッパーの活動ではなく、ビジネスの成果に焦点を当てられます。\n\nAIインパクトダッシュボードに関するフィードバックは、[イシュー456105](https://gitlab.com/gitlab-org/gitlab/-/issues/456105)からお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/analytics/ai_impact_analytics/)  \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/523807)\n\n### プロジェクトの作成権限の設定の改善\n\nSaaS: Free、Premium、Ultimate  \u003Cbr> \nSelf-Managed: Free、Premium、Ultimate\n\nプロジェクトの作成権限の設定がさらにわかりやすく、直感的に、そしてセキュリティ原則に沿ったものに改善されました。改善された設定には次のものが含まれます。\n\n* 「プロジェクトの作成に対するデフォルトの保護」というドロップダウンオプションを「プロジェクトの作成に必要なデフォルトの最小ロール」に変更し、目的をより明確にしました。  \n* プラットフォーム全体で一貫性を保つために、ドロップダウンオプションの「デベロッパー \\+ メンテナー」を「デベロッパー」に変更しました。  \n* ドロップダウンオプションを最も制限が厳しいアクセスレベルから最も制限の少ないアクセスレベルへ並べ替えました。\n\nこれにより、グループ内でプロジェクト作成が可能なロールの把握・設定を行いやすくなり、管理者がより確実に適切なアクセス制御を実施できます。  \nこの場を借りて、コミュニティにコントリビュートしてくれた[@yasuk](https://gitlab.com/yasuk)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/administration/settings/visibility_and_access_controls/#define-which-roles-can-create-projects)  \u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/507410)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/updated_project_creation_protection.png\">\n\n### Meta Llama 3モデルがGitLab Duo Self-Hostedのコード提案とChatで利用可能に\n\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nGitLab Duo Self-Hostedで、一部のMetaLlama 3モデルを利用できるようになりました。このモデルは、GitLab Duo Self-Hostedのベータ版で提供され、GitLab Duo Chatとコード提案をサポートします。\n\nこれらのモデルをGitLab Duo Self-Hostedで使用した際のフィードバックについて、ぜひ[イシュー523912](https://gitlab.com/gitlab-org/gitlab/-/issues/523917)にお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#supported-models)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/523917)\n\n### GitLab Duo Self-HostedでのAI搭載機能用モデルの選択\n\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nGitLab Duo Self-Hostedで、GitLab Duo Chatの各サブ機能に対して個別にサポートされているモデルを選択できるようになりました。Chatのサブ機能でのモデルの選択と設定は、現在ベータ版です。\n\nフィードバックは、[イシュー524175](https://gitlab.com/gitlab-org/gitlab/-/issues/524175)にお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/configure_duo_features/#configure-the-feature-to-use-a-self-hosted-model)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/524174)  \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_10/Expanded_Chat_17.10_v2.png\">\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。  \n17.10で提供されたすべてのバグ修正、パフォーマンスの強化、UI改善を確認するには、以下のリンクをクリックしてください。\n\n* [バグ修正](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%255B%255D=type::bug&or%255Blabel_name%255D%255B%255D=workflow::complete&or%255Blabel_name%255D%255B%255D=workflow::verification&or%255Blabel_name%255D%255B%255D=workflow::production&milestone_title=17.10)  \n* [パフォーマンスの改善](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%255B%255D=bug::performance&or%255Blabel_name%255D%255B%255D=workflow::complete&or%255Blabel_name%255D%255B%255D=workflow::verification&or%255Blabel_name%255D%255B%255D=workflow::production&milestone_title=17.10)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.10)\n\n\u003Cbr>\n\u003Cbr>\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n* [コンテナレジストリ用S3ストレージドライバー（AWS SDK v1）](https://docs.gitlab.com/update/deprecations/#s3-storage-driver-aws-sdk-v1-for-the-container-registry)  \n* [コンテナレジストリ用Azureストレージドライバー](https://docs.gitlab.com/update/deprecations/#azure-storage-driver-for-the-container-registry)\n\n\u003Cbr>\n\u003Cbr>\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n### 変更履歴\n変更内容をすべて表示するには、次のページから変更履歴を確認してください。\n\n* [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ワークフロー](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/ja-jp/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/)でお試しいただけます。  \n\n\u003Cbr>\n\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\u003Cbr>\n\n*ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n\u003Cbr>\n\u003Cbr>\n\n### 過去の日本語リリース情報\n\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],"2025-03-25",{"slug":1826,"featured":92,"template":681},"gitlab-17-10-release","content:ja-jp:blog:gitlab-17-10-release.yml","Gitlab 17 10 Release","ja-jp/blog/gitlab-17-10-release.yml","ja-jp/blog/gitlab-17-10-release",{"_path":1832,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1833,"content":1838,"config":1844,"_id":1846,"_type":16,"title":1847,"_source":17,"_file":1848,"_stem":1849,"_extension":20},"/ja-jp/blog/whats-new-in-git-2-49-0",{"title":1834,"description":1835,"ogTitle":1834,"ogDescription":1835,"noIndex":6,"ogImage":1206,"ogUrl":1836,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1836,"schema":1837},"Git 2.49.0の新機能","このリリースでは、zlib-ngによるパフォーマンス向上、新しい名前ハッシュアルゴリズム、そして新しいコマンドgit-backfill(1)の導入などが行われています。","https://about.gitlab.com/blog/whats-new-in-git-2-49-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.49.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Toon Claes\"}],\n        \"datePublished\": \"2025-03-14\",\n      }",{"title":1834,"description":1835,"authors":1839,"heroImage":1206,"date":1841,"body":1842,"category":962,"tags":1843},[1840],"Toon Claes","2025-03-14","Gitプロジェクトは最近、[Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/)をリリースしました。このリリースには、GitLabのGitチームや、より広範なGitコミュニティからのコントリビュートが含まれます。注目すべきハイライトを見てみましょう。\n\nこの記事では以下の変更点についてご紹介します。\n- [git-backfill(1)と新しいpath-walk API](#git-backfill(1)-and-the-new-path-walk-api)\n- [zlib-ngの導入](#introduction-of-zlib-ng)\n- [Mesonの継続的なイテレーション](#continued-iteration-on-meson)\n- [.git/branches/および.git/remotes/の非推奨化](#deprecation-of-.gitbranches%2F-and-.git%2Fremotes%2F)\n- [libgitに対するRustバインディング](#rust-bindings-for-libgit)\n- [新しい名前ハッシュアルゴリズム](#new-name-hashing-algorithm)\n- [プロミサーリモート機能](#promisor-remote-capability)\n- [`--revision`を使用した軽量なクローン](#thin-clone-using---revision)\n\n## git-backfill(1)と新しいpath-walk API\n\n[`git-clone(1)`](https://git-scm.com/docs/git-clone)コマンドでGitリポジトリをクローンする際に、\n[`--filter`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt-code--filterltfilter-specgtcode)オプションを指定することができます。\nこのオプションを使用すると、部分クローンを作成できます。部分クローンでは、指定されたオブジェクトフィルターに従って、サーバーから到達可能なオブジェクトの一部のみが送信されます。\n例えば、`--filter=blob:none`を指定してクローンを作成すると、サーバーからblob（ファイルの中身）が一切フェッチされず、_ブロブを含まないクローン_が作成されます。\n\nブロブを含まないクローンには、すべての到達可能なコミットとツリーは含まれますが、blobは含まれていません。そのため、[`git-checkout(1)`](https://git-scm.com/docs/git-checkout)のような操作を行うと、\nGitは必要なblobをサーバーからダウンロードして、その操作を完了させます。ただし、[`git-blame(1)`](https://git-scm.com/docs/git-blame)のような一部の操作では、\n必要なオブジェクトが1つずつダウンロードされることになり、この処理が非常に遅くなります。\nこれは、`git-blame(1)`がコミット履歴をたどって必要なblobを特定し、\n不足している各blobを個別にサーバーへリクエストする必要があるためです。\n\nGit 2.49では、新たに`git-backfill(1)`というサブコマンドが導入されました。これは、ブロブを含まない部分クローンに対して、不足しているblobをダウンロードするために使用できます。\n\n内部的には、`git-backfill(1)`は新しいパスウォークAPIを利用しています。これはGitが通常行うコミットのイテレーション処理とは異なります。従来の方法では、コミットを1つずつイテレーションし、それぞれに関連するツリーやblobに再帰的にアクセスしていました。一方、パスウォークAPIはパスごとに処理を行います。各パスについて関連するツリーオブジェクトのリストをスタックに追加し、そのスタックを深さ優先で処理します。つまり、コミット`1`のすべてのオブジェクトを処理してからコミット`2`へ進むのではなく、ファイル`A`のすべてのバージョンを全コミットにわたって処理してからファイル`B`に進む、という方式です。このアプローチは、パスごとにグループ化して処理する必要がある場合に、大幅なパフォーマンス向上をもたらします。\n\n[`gitlab-org/git`](https://gitlab.com/gitlab-org/git)リポジトリのブロブを含まないクローンを作成し、その使い方をお見せします。\n\n```shell\n$ git clone --filter=blob:none --bare --no-tags git@gitlab.com:gitlab-org/git.git\nCloning into bare repository 'git.git'...\nremote: Enumerating objects: 245904, done.\nremote: Counting objects: 100% (1736/1736), done.\nremote: Compressing objects: 100% (276/276), done.\nremote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused 244168 (from 1)\nReceiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.\nResolving deltas: 100% (161482/161482), done.\n```\n\n上の例では、Gitが初期ブランチをチェックアウトするためにblobをダウンロードする必要がないよう、`--bare`オプションを使用しています。このクローンにblobが含まれていないことは、次のコマンドで確認できます。\n\n```sh\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\nもしこのリポジトリ内のファイル内容を確認したい場合、Gitはそのファイルをダウンロードする必要があります。\n\n```sh\n$ git cat-file -p HEAD:README.md\nremote: Enumerating objects: 1, done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\nGit - fast, scalable, distributed revision control system\n=========================================================\n\nGit is a fast, scalable, distributed revision control system with an\nunusually rich command set that provides both high-level operations\nand full access to internals.\n\n[中略]\n```\n\nご覧のとおり、Gitはまずリモートリポジトリにアクセスし、blobをダウンロードしてから内容を表示しています。\n\nこのファイルに対して`git-blame(1)`を実行したい場合は、さらに多くのデータをダウンロードする必要があります。\n\n```sh\n$ git blame HEAD README.md\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\n\n[中略]\n\ndf7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1) [![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n5f7864663b README.md (Johannes Schindelin \t2019-01-29 06:19:32 -0800  2)\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  3) Git - fast, scalable, distributed revision control system\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  4) =========================================================\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  5)\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  6) Git is a fast, scalable, distributed revision control system with an\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  7) unusually rich command set that provides both high-level operations\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  8) and full access to internals.\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  9)\n\n[中略]\n```\n\n出力は省略していますが、ご覧のように、Gitはそのファイルの各リビジョンについて個別にサーバーへアクセスしています。これはとても非効率的です。そこで`git-backfill(1)`を使えば、Gitに対してすべてのblobを一括でダウンロードするよう指示できます。\n\n```shell\n$ git backfill\nremote: Enumerating objects: 50711, done.\nremote: Counting objects: 100% (15438/15438), done.\nremote: Compressing objects: 100% (708/708), done.\nremote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused 35273 (from 1)\nReceiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\nResolving deltas: 100% (49154/49154), done.\nremote: Enumerating objects: 50017, done.\nremote: Counting objects: 100% (10826/10826), done.\nremote: Compressing objects: 100% (634/634), done.\nremote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused 39191 (from 1)\nReceiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\nResolving deltas: 100% (48301/48301), done.\nremote: Enumerating objects: 47303, done.\nremote: Counting objects: 100% (7311/7311), done.\nremote: Compressing objects: 100% (618/618), done.\nremote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused 39992 (from 1)\nReceiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\nResolving deltas: 100% (43788/43788), done.\n```\n\nこれにより、すべてのblobが補完され、ブロブを含まないクローンが完全なクローンになります。\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n 148031 blob\n  83977 commit\n 161927 tree\n```\n\nこの[プロジェクト](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/)は[Derrick Stolee](https://stolee.dev/)によって主導され、[e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae)でマージされました。\n\n## zlib-ngの導入\n\n`.git/`フォルダ内のすべてのオブジェクトは、Gitによって[`zlib`](https://zlib.net/)を使って圧縮されています。`zlib`は[RFC\n1950](https://datatracker.ietf.org/doc/html/rfc1950)（ZLIB圧縮データフォーマット）のリファレンス実装であり、1995年に作られました。`zlib`は長い歴史を持ち、非常に高い移植性があり、\nインターネット以前の多くのシステムもサポートしています。このように幅広いアーキテクチャやコンパイラをサポートしている一方で、\nzlibには機能面での制限もあります。\n\nその制限に対応するために生まれたのが[`zlib-ng`](https://github.com/zlib-ng/zlib-ng)というフォークです。\n`zlib-ng`は、現代的なシステム向けに最適化されることを目指しており、レガシーシステムのサポートを廃止する代わりに、\nIntel向けの最適化パッチや、Cloudflareによる最適化、その他いくつかの小規模なパッチが取り込まれています。\n\n`zlib-ng`ライブラリ自体は`zlib`との互換レイヤーを提供しており、この互換性により、`zlib-ng`を`zlib`の代替としてそのまま差し替えて使うことが可能です。\nただし、この互換レイヤーはすべてのLinuxディストリビューションで利用できるわけではありません。Git 2.49では以下の変更が加えられました。\n\n- Gitプロジェクトへのzlib-ng互換レイヤーの追加\n- [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187)および[Mesonビルドファイル](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811)へのビルドオプションの追加\n\nこれらの追加により、`zlib-ng`によるパフォーマンス向上の恩恵を受けやすくなりました。\n\nローカルでのベンチマークでは、`zlib`ではなく`zlib-ng`を使用することで約25%の高速化が確認されています。現在、これらの変更をGitLab.comにも順次導入中です。\n\n`zlib-ng`によるパフォーマンス向上の恩恵を受けたい場合は、まず`git version --build-options`コマンドを実行して、お使いのマシンでGitがすでに`zlib-ng`を使用しているかどうかを確認してください。\n\n```shell\n$ git version --build-options\ngit version 2.47.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.6.0\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1.zlib-ng\n```\n\n出力の一番下の行に`zlib-ng`と表示されていれば、すでにGitは高速な`zlib`のバリアントでビルドされています。表示されていない場合は、以下のいずれかの方法で対応できます。\n\n- お使いのGitパッケージのメンテナーに、`zlib-ng`のサポートを有効にしてもらうよう依頼する\n- Gitをソースコードから自分でビルドする\n\nなお、これらの[変更](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0)\nは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって[導入](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/)されました。\n\n## Mesonの継続的なイテレーション\n\nGit 2.48のリリースについて紹介した記事では、[Mesonビルドシステムの導入](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/#meson%E3%83%93%E3%83%AB%E3%83%89%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)について触れました。[Meson](https://ja.wikipedia.org/wiki/Meson_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2))は、Gitプロジェクトで使用されるビルド自動化ツールで、将来的には[Autoconf](https://ja.wikipedia.org/wiki/Autoconf),\n[CMake](https://ja.wikipedia.org/wiki/CMake)さらには\n[Make](https://ja.wikipedia.org/wiki/Make_(UNIX))に取って代わる可能性もあります。\n\n今回のリリースサイクルでも、Mesonの利用に関する作業が引き続き進められ、不足していた機能の追加や安定性向上のための以下の修正が行われました。\n\n  - [CIのテストカバレッジ改善](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/)が、コミット[72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709)でマージされました\n- [`contrib/`ディレクトリでMesonを使えるようにする作業の一部](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/)が、コミット[2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace)でマージされました\n  - [Mesonベースのビルド手順に関する修正や改善](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/)が、コミット[ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f)でマージされました\n  - [git-subtree(1)のビルドにMesonを対応させる変更](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/)が、コミット[3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7)でマージされました\n  - [MesonにHTMLドキュメントページの生成を学習させる変更](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/)が、コミット[1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694)でマージされました\n\nこれらの作業はすべて[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって行われました。\n\n## .git/branches/および.git/remotes/の非推奨化\n\nおそらく、 `.git`ディレクトリやその中身についてはご存じかと思います。\nしかし、 `.git/branches/`や`.git/remotes/`というサブディレクトリの存在についてはどうでしょうか？\nご存じの通り、ブランチへの参照は`.git/refs/heads/`に保存されているため、`.git/branches/`はそのための場所ではありません。そして、`.git/remotes/`の用途は何でしょうか？\n\n2005年、[`.git/branches/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirbranches)はリモートの短縮名を保存するために導入されました。そしてその数か月後に、それらは[`.git/remotes/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirremotes)に移動されました。\n[2006年](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/)には、[`git-config(1)`](https://git-scm.com/docs/git-config)に[リモート](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl)設定を保存する機能が追加され、\nこれがリモートを設定する標準的な方法として定着しました。\nその後2011年には、`.git/branches/`と`.git/remotes/`は「レガシー」であることが[文書化](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124)され、現代のリポジトリでは使用されなくなりました。\n\nそして2024年、Gitの次のメジャーバージョン（v3.0）の破壊的な変更の概要をまとめるドキュメント[破壊的な変更](https://git-scm.com/docs/BreakingChanges)が作成されました。\nこのリリースはすぐに行われる予定はありませんが、このドキュメントにはそのリリースに含まれると予想される変更点について記載されています。\nコミット[8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674)では、`.git/branches/`および`.git/remotes/`ディレクトリの使用に関する内容がこのドキュメントに追加され、これにより公式に非推奨とされ、Git 3.0で削除予定であることが明示されました。\n\n[この非推奨化を正式に文書化](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/)した[Patrick Steinhardt](https://gitlab.com/pks-gitlab)に感謝します。\n\n## libgitに対するRustバインディング\n\nGitをコンパイルすると、内部ライブラリ`libgit.a`が生成されます。このライブラリには、Gitの中核となる機能の一部が含まれています。\n\nこのライブラリ（およびGitの大部分）はC言語で書かれていますが、Git 2.49では一部の関数をRustから使えるようにするためのバインディングが追加されました。この実現のために、2つの新しいCargoパッケージ、`libgit-sys`と`libgit-rs`が作成されました。これらのパッケージは、GitのSourceTree内の[`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib)サブディレクトリに配置されています。\n\n[他言語関数インターフェイス](https://ja.wikipedia.org/wiki/Foreign_function_interface)を使う場合、ライブラリを2つのパッケージに分けるのは[一般的](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages)な手法です。\n`libgit-sys`パッケージは、C関数への純粋なインターフェースを提供し、ネイティブの`libgit.a`にリンクします。一方、`libgit-rs`パッケージは、`libgit-sys`の関数をRustらしいスタイルで扱える高レベルなインターフェースを提供します。\n\n現時点では、これらのRustパッケージで使える機能は非常に限定的で、対応しているのは`git-config(1)`とやり取りするためのインターフェースのみです。\n\nこの取り組みは[Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/)さんによって主導され、コミット[a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd)でマージされました。\n\n## 新しい名前ハッシュアルゴリズム\n\n`.git/`にあるGitのオブジェクトデータベースは、その大部分のデータを パックファイルに保存しています。また、このパックファイルは、Gitのサーバーとクライアント間でオブジェクトをやり取りする際にも使われます。\n\nパックファイルのフォーマットについては、[`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack)に詳しく書かれていますが、その中でも重要なのが差分圧縮です。差分圧縮では、すべてのオブジェクトがそのまま保存されるわけではなく、一部のオブジェクトは他のオブジェクトとの_差分_として保存されます。つまり、オブジェクトの内容全体を保存するのではなく、他のオブジェクトと比較した変更点だけを記録します。\n\n差分の計算や保存方法についてはここでは詳しく触れませんが、\n非常に似ているファイルをグループ化しておくことが重要なのは想像できるかと思います。Git v2.48以前では、Gitは「ファイルパスの最後の16文字」をもとに、blobが似ているかどうかを判断していました。このアルゴリズムはバージョン`1`と呼ばれています。\n\nGit 2.49では、バージョン`2`のアルゴリズムが追加されました。これはバージョン`1`のイテレーションで、親ディレクトリの影響を減らすように調整されたバージョンです。どちらのアルゴリズムを使用するかは、[`git-repack(1)`](https://git-scm.com/docs/git-repack)の`--name-hash-version`オプションで指定できます。\n\n以下は、このプロジェクトを推進した[Derrick Stolee](https://stolee.dev/)さんによる、`git repack -adf --name-hash-version=\u003Cn>`を実行した際のパックファイルサイズの比較です。\n\n| リポジトリ                                          \t| バージョン1のサイズ   | バージョン2のサイズ |\n|---------------------------------------------------|-----------|---------|\n| [fluentui](https://github.com/microsoft/fluentui) | 440 MB \t| 161 MB   |\n| Repo B                                        \t| 6,248 MB   | 856 MB   |\n| Repo C                                        \t| 37,278 MB  | 6,921 MB |\n| Repo D                                        \t| 131,204 MB | 7,463 MB |\n\nこの件に関する詳細は、コミット[aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51)にマージされた[パッチセット](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/)にて確認できます。\n\n## プロミサーリモート機能\n\nGitが大きなファイルを扱うのに向いていないことは、よく知られています。この問題に対する解決策として、[Git LFS](https://git-lfs.com/)のようなツールがありますが、依然として以下のような欠点が残っています。\n\n- Git LFSでは、どのファイルをLFSに入れるかをユーザーが自分で設定する必要があり、サーバー側ではそれについて制御できず、すべてのファイルを提供する必要があります。\n- リポジトリにファイルがコミットされると、履歴を書き換えない限り、それを取り除く方法がありません。これは特に大きなファイルでは厄介で、一度入れると永遠に残ってしまいます。\n- ユーザーは、Git LFSに入れるファイルを後から変更することはできません。\n- Git LFS のようなツールは、導入・学習・運用すべてにそれなりの労力が必要です。\n\n以前からGitにはプロミサーリモートという概念が存在しており、この機能を大きなファイルに対処するための手段として利用できます。そしてGit 2.49では、この機能がさらに一歩前進しました。\n\n新しい「プロミサーリモート」機能の考え方は比較的シンプルです。Gitサーバーがすべてのオブジェクトを自ら送信する代わりに、「これらのオブジェクトは_XYZ_からダウンロードしてね」とGitクライアントに伝えます。この_XYZ_がプロミサーリモートです。\n\nGit 2.49では、サーバーがプロミサーリモートの情報をクライアントに通知できるようになりました。この変更は、[`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2)の拡張として行われています。サーバーとクライアントがデータを送受信している間に、サーバーは自分が知っているプロミサーリモートの名前やURLをクライアントに送信します。\n\n現時点では、Gitクライアントはクローン時にサーバーから受け取ったプロミサーリモートの情報をまだ利用していません。つまり、今のところは、クローン元のリモートからすべてのオブジェクトを取得しています。しかし今後は、サーバーから受け取ったプロミサーリモート情報を活用できるように開発を進め、より簡単に使える仕組みにしていく予定です。\n\nこの[パッチセット](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/)は[Christian Couder](https://gitlab.com/chriscool)さんによって提出され、コミット[2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c)でマージされました。\n\n## `--revision`を使用した軽量なクローン\n\n[`git-clone(1)`](https://git-scm.com/docs/git-clone)に新しく`--revision`オプションが追加されました。このオプションを使うことで、指定されたリビジョンの履歴のみを含む、軽量なクローンを作成できます。このオプションは`--branch`に似ていますが、`refs/heads/main`、`refs/tags/v1.0`、`refs/merge-requests/123`のような リファレンス名や、16進数のコミットオブジェクトIDを受け取る点が異なります。`--branch`との違いは、このオプションでは追跡ブランチが作られず、`HEAD`がデタッチ状態になる点です。そのため、このクローンを使ってブランチにコントリビュートするといった用途には向いていません。\n\n`--revision`と`--depth`を組み合わせて使うことで、非常にミニマルなクローンを作成できます。おすすめの用途は、自動テストです。たとえば、CIシステムが特定のブランチ（またはリファレンス）をチェックアウトして、ソースコードのテストを行うだけでいい場合、この最小限のクローンで十分です。\n\nこの[変更](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a)は[Toon Claes](https://gitlab.com/toon)さんによって[推進](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/)されました。\n\n# もっと詳しく\n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)\n- [Git 2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)\n- [Git 2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)",[270,825,966],{"slug":1845,"featured":92,"template":681},"whats-new-in-git-2-49-0","content:ja-jp:blog:whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0","ja-jp/blog/whats-new-in-git-2-49-0.yml","ja-jp/blog/whats-new-in-git-2-49-0",{"_path":1851,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1852,"content":1857,"config":1862,"_id":1864,"_type":16,"title":1865,"_source":17,"_file":1866,"_stem":1867,"_extension":20},"/ja-jp/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"title":1853,"description":1854,"ogTitle":1853,"ogDescription":1854,"noIndex":6,"ogImage":1402,"ogUrl":1855,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1855,"schema":1856},"gitlab-triage gemを使ったアジャイルワークフローの自動化","「GitLab入門」シリーズでは、イシューやマージリクエストのトリアージなどの繰り返し発生するタスクを自動化して、デベロッパーの貴重な時間を確保する方法をご紹介します。","https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"gitlab-triage gemを使ったアジャイルワークフローの自動化\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-13\",\n      }",{"title":1853,"description":1854,"authors":1858,"heroImage":1402,"date":1859,"body":1860,"category":701,"tags":1861},[696],"2025-03-13","*「GitLab入門」シリーズへようこそ。このシリーズでは新たにGitLabを使い始める方向けに、GitLab\nDevSecOpsプラットフォームに慣れ親しむために役立つ内容をお届けします。*\n\n\n今回の記事では、[`gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\ngemを取り上げます。この非常に強力なツールを使用すると、アジャイルワークフローを自動化するボットを作成できます。自動化により、手作業を排除して作業効率を向上させましょう。\n\n\n## ワークフローを自動化すべき理由\n\n\nソフトウェア開発では効率性は重要です。イシューやマージリクエストのトリアージなどの繰り返し発生するタスクを自動化できれば、チームの貴重な時間を確保し、一番重要な作業である「素晴らしいソフトウェアの開発」に集中できるようになります。\n\n\n`gitlab-triage`を使用すれば、次のことを実現できます。\n\n\n* **一貫性の確保**：定義済みのルールに基づいて、自動的にラベルを適用し、イシューを自動的に割り当てる  \n\n* **レスポンスタイムの短縮**：新たなイシューやマージリクエストに関するフィードバックを即座に得られる  \n\n* **手作業の削減**：手作業でトリアージや更新を行う必要がなくなる  \n\n* **生産性の向上**：チームが、コーディング作業やイノベーションの創出に集中できるようになる\n\n\n## `gitlab-triage`のご紹介\n\n\n`gitlab-triage`\ngemは、GitLabプロジェクトとやり取りするボットを作成できるRubyのライブラリです。作成したボットを使用すると、次のようなさまざまなアクションの実行を自動化できます。\n\n\n* **ラベル付け**：イシューやマージリクエストを自動的に分類する  \n\n* **コメントの追加**：最新情報やフィードバックの提供、または情報の提供依頼を行う  \n\n* **割り当て**：イシューやマージリクエストを適切なチームメンバーに割り当てる  \n\n* **クローズ**：解決済み、または古くなったイシューやマージリクエストをクローズする  \n\n* **作成**：特定のイベントや条件に基づいて新しいイシューを作成する  \n\n* **ほかにもさまざまなことを行えます！**\n\n\nぜひ[`gitlab-triage`\ngemリポジトリ](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)をチェックしてみてください。\n\n\n## トリアージボットのセットアップ\n\n\nでは、最初のトリアージボットをセットアップして動かしてみましょう！\n\n\n1. gemをインストールします。（注：gemコマンドは、プログラミング言語のRubyがインストールされている場合に利用できます）。\n\n\n```bash\n\ngem install gitlab-triage\n\n```\n\n\n2. GitLab APIトークンを取得します。\n\n\n* GitLab[プロファイル設定](https://gitlab.com/-/profile/preferences)に移動します。  \n\n* 「**アクセストークン**」に移動します。  \n\n* `api`スコープを指定して、新しいトークンを作成します。  \n\n* **作成したトークンを安全な場所に保存し、このガイドがいつ頃終わるかに基づいて有効期限を設定します。**\n\n\n3. トリアージポリシーを定義します。\n\n\nプロジェクトのルートディレクトリに`.triage-policies.yml`という名前のファイルを作成します。このファイルには、ボットの動作を制御するルールを含めます。以下に簡単な例をご紹介します。\n\n\n```yaml\n\n\n---\n\n- name: \"Apply 'WIP' label\"\n  condition:\n    draft: true\n  action:\n    labels:\n      - status::wip\n\n- name: \"Request more information on old issue\"\n  condition:\n   date:\n    attribute: updated_at\n    condition: older_than\n    interval_type: months\n    interval: 12\n  action:\n    comment: |\n      {{author}} This issue has been open for more than 12 months, is this still an issue?\n```\n\n\n上記の設定では、2つのポリシーを定義しています。\n\n\n* 1つ目のポリシーは、ドラフトモードにあるすべてのイシューに`status::wip`ラベルを適用します。  \n\n* 2つ目のポリシーは、12か月間更新がないイシューに、その旨のコメントを追加します。\n\n\n4. ボットを実行します。\n\n\n以下のコマンドを使用すると、手動でボットを実行できます。\n\n\n```bash\n\ngitlab-triage -t \u003Cyour_api_token> -p \u003Cyour_project_id>\n\n```\n\n\n`\u003Cyour_api_token>`の部分をご自身のGitLab\nAPIトークンに、また`\u003Cyour_project_id>`を[ご自身のGitLabプロジェクトID](https://docs.gitlab.com/user/project/working_with_projects/#access-a-project-by-using-the-project-id)に変更してください。実行前にこれらのアクションの影響を確認したい場合は、`-n`または`--dry-run`を追加すれば、ポリシーをまずはテストできます。\n\n\n## GitLab CI/CDによる自動化\n\n\nトリアージボットの実行を自動化するには、[GitLab\nCI/CD](https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation/)と統合します。以下は`.gitlab-ci.yml`の設定例です。\n\n\n```yaml\n\n\ntriage:\n  script:\n    - gem install gitlab-triage\n    - gitlab-triage -t $GITLAB_TOKEN -p $CI_PROJECT_ID\n  only:\n    - schedules\n```\n\n\n上記の設定では、「triage」という名前のジョブを定義しています。このジョブは、`gitlab-triage`\ngemをインストールし、`$GITLAB_TOKEN`（定義済みの[CI/CD変数](https://docs.gitlab.com/ci/variables/)）変数と`$CI_PROJECT_ID`変数を使用してボットを実行します。`only:\nschedules`によって、ジョブが必ずスケジュールに従って実行されることを保証します。\n\n\n[スケジュール](https://docs.gitlab.com/ee/ci/pipelines/schedules.html)を設定するには、プロジェクトの「**CI/CD**」設定にアクセスし、「**スケジュール**」に進みます。新しいスケジュールを作成したら、ボットを実行する頻度（毎日、毎時間など）を設定します。\n\n\n## 高度なトリアージポリシー\n\n\n`gitlab-triage`には、さらに複雑なトリアージポリシーを作成できるように、次のような高度な機能が用意されています。\n\n\n* **正規表現**：正規表現を使用すると、より強力なパターン一致を実現できます。  \n\n* **サマリーポリシー**：関連する複数のイシューを1つのサマリーイシューにまとめます。  \n\n*\n**カスタムアクション**：[Rubyコードブロック](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage#can-i-customize)を使用してカスタムアクションを定義し、GitLab\nAPI を使ったより複雑な操作を実行できます。\n\n\nGitLabのデベロッパーアドボカシーチームによる、高度なトリアージボットの実際の使用例をご紹介します。全ポリシーは、[こちらのファイル](https://gitlab.com/gitlab-da/projects/devrel-bot/-/blob/master/.triage-policies.yml?ref_type=heads)でご覧いただけます。\n\n\n```yaml\n\n- name: Issues where DA team member is an assignee outside DA-Meta project\ni.e. DevRel-Influenced\n  conditions:\n    assignee_member:\n      source: group\n      condition: member_of\n      source_id: 1008\n    state: opened\n    ruby: get_project_id != 18 \n    forbidden_labels:\n      - developer-advocacy\n  actions:   \n    labels:\n      - developer-advocacy\n      - DevRel-Influenced\n      - DA-Bot::Skip\n```\n\n\nこちらの例では、グループ全体のイシュー（IDが18のプロジェクトに含まれるイシューを除く）から、IDが1008のグループに所属し、`developer-advocacy`というラベルが付いていないメンバーが担当者であるイシューを割り出し、ラベルを適用しています。GitLabデベロッパーアドボカシーチームは、このポリシーを使用して、チームメンバーが担当しているものの、チームのプロジェクトとして割り当てられていないイシューを探し出しています。チームのラベルを追加することで、チーム外からのコントリビュートを特定・追跡しやすくなります。\n\n\n```\n\n- name: Missing Due Dates\n  conditions:\n    ruby: missing_due_date\n    state: opened\n    labels:\n      - developer-advocacy\n    forbidden_labels:\n      - DA-Due::N/A\n      - DA-Bot::Skip\n      - DA-Status::FYI\n      - DA-Status::OnHold\n      - CFP\n      - DA-Bot::Triage\n  actions:\n    labels:\n      - DA-Bot-Auto-Due-Date\n    comment: |\n      /due #{get_current_quarter_last_date}\n```\n\n\n上記の2つ目の例では、forbidden_labelsに含まれるラベルが適用されておらず、期限を過ぎていて、`developer-advocacy`ラベルが付いているイシューをすべて探し出します。スラッシュコマンドとRubyを使って生成した日付を用いてイシューにコメントすることで、自動的に期限が更新されます。\n\n\nポリシーで使用されているRubyスクリプトは、以下のように別のファイルで定義しています。この機能を使用すれば、フィルターとアクションを柔軟に扱えます。ご覧のように、ポリシーで使用したさまざまなRubyコマンド用に関数を作成しています。\n\n\n```\n\nrequire 'json'\n\nrequire 'date'\n\nrequire \"faraday\"\n\nrequire 'dotenv/load'\n\n\nmodule DATriagePlugin\n  def last_comment_at\n    conn = Faraday.new(\n      url: notes_url+\"?sort=desc&order_by=created_at&pagination=keyset&per_page=1\",\n      headers: {'PRIVATE-TOKEN' => ENV.fetch(\"PRIV_KEY\"), 'Content-Type' => 'application/json' }\n    )\n\n    response = conn.get()\n    if response.status == 200\n      jsonData = JSON.parse(response.body)\n      if jsonData.length > 0\n        Date.parse(jsonData[0]['created_at'])\n      else\n        Date.parse(resource[:created_at])\n      end\n    else\n      Date.parse(resource[:created_at])\n    end\n  end\n\n  def notes_url\n    resource[:_links][:notes]\n  end\n\n  def get_project_id\n    resource[:project_id]\n  end\n\n  def get_current_quarter_last_date()\n    yr = Time.now.year\n    case Time.now.month\n    when 2..4\n      lm = 4\n    when 5..7\n      lm = 7\n    when 8..10\n      lm = 10\n    when 11..12\n      lm = 1\n      yr = yr + 1\n    else\n      lm = 1    \n    end\n\n    return Date.new(yr, lm, -1) \n  end\n\n  def one_week_to_due_date\n    if(resource[:due_date] == nil)\n      false\n    else\n      days_to_due = (Date.parse(resource[:due_date]) - Date.today).to_i\n      if(days_to_due > 0 && days_to_due \u003C 7)\n        true\n      else\n        false\n      end\n    end\n  end\n\n  def due_date_past\n    if(resource[:due_date] == nil)\n      false\n    else\n      Date.today > Date.parse(resource[:due_date])\n    end\n  end\n\n  def missing_due_date\n    if(resource[:due_date] == nil)\n      true\n    else\n      false\n    end\n  end\n\nend\n\n\nGitlab::Triage::Resource::Context.include DATriagePlugin\n\n\n```\n\nトリアージボットを実行する際は、次のコマンドを使用します。\n\n\n``` \n\n`gitlab-triage -r ./triage_bot/issue_triage_plugin.rb --debug --token\n$PRIV_KEY --source-id gitlab-com --source groups`  \n\n```\n\n\n- `-r`：トリアージを実行するための要件ファイルを渡します。この場合は、Ruby関数を渡します。  \n\n- `--debug`：出力の一部としてデバッグ情報を表示します。  \n\n- `--token`：有効なGitLab APIトークンを渡すために使用します。  \n\n- `--source`：検索対象のイシューのソースがグループ内またはプロジェクト内かを指定します。  \n\n- `--source-id`:： 選択したソースタイプのID（この場合はグループ）を受け取ります。\n\n\n\nもう1つの実際の活用例としては、GitLab\n[triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)プロジェクトが挙げられます。こちらはさらに複雑で、専用のトリアージボットの作成方法を学ぶのに最適です。\n\n\n## ベストプラクティス\n\n\n* **まずは簡単なものから始める**：基本的なポリシーから始めて、必要に応じて徐々に複雑な設定にしていきましょう。 \n\n* **テストは徹底的に行う**：本番環境にデプロイする前に、ステージング環境でポリシーをテストします。  \n\n* **定期的にモニタリングする**：ボットの動作をモニタリングし、想定どおりに機能しているか確認してください。 \n\n* **わかりやすい名前を付ける**：メンテナンスしやすいように、ポリシーには明確でわかりやすい名前を付けましょう。 \n\n*\n**フィルターの適用範囲に注意する**：何千ものイシューが存在する全グループを対象に、イシューを絞り込むのはおすすめしません。トリアージに時間がかかってしまう可能性があるだけでなく、GitLab\nAPIのレート制限によってプロセス自体が失敗に終わることもあります。  \n\n*\n**トリアージの際にはラベルを使って優先順位付けする**：関係ないコメントやイシューがあふれて、ほかのユーザーの邪魔になることのないよう、トリアージを行う際はラベルを使用することをおすすめします。\n\n\n## ワークフローを制御する\n\n\n`gitlab-triage`\ngemを使用すれば、GitLabワークフローを自動化して、新たなレベルの効率化を実現できます。まずはシンプルなトリアージボットの作成から始めて、徐々に高度な機能を使ってみてください。どれだけ多くの時間や作業負荷を削減できるか、きっと驚かれると思います！\n\n\n## GitLab入門シリーズ\n\n\n「GitLab入門」シリーズのその他の記事をぜひご覧ください。\n\n\n-\n[ユーザーの管理方法](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)\n\n\n- \n[GitLabへのプロジェクトのインポート方法](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n\n-\n[プロジェクト管理を極める](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n",[904,676,701,1389,110],{"slug":1863,"featured":6,"template":681},"automating-agile-workflows-with-the-gitlab-triage-gem","content:ja-jp:blog:automating-agile-workflows-with-the-gitlab-triage-gem.yml","Automating Agile Workflows With The Gitlab Triage Gem","ja-jp/blog/automating-agile-workflows-with-the-gitlab-triage-gem.yml","ja-jp/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"_path":1869,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1870,"content":1876,"config":1881,"_id":1883,"_type":16,"title":1884,"_source":17,"_file":1885,"_stem":1886,"_extension":20},"/ja-jp/blog/developers-summit-2025-spring-event-report",{"title":1871,"description":1872,"ogTitle":1871,"ogDescription":1872,"noIndex":6,"ogImage":1873,"ogUrl":1874,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1874,"schema":1875},"AI活用の鍵はGitLabの一貫したコンテクスト 【Developers Summit 2025 イベントレポート】","2025年2月、GitLabは「Developers Summit 2025」に出展しました。本イベントにてシニアソリューションアーキテクト 佐々木直晴が講演をおこないましたので、本記事にてその模様をレポートします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663625/Blog/Hero%20Images/3508_resized.jpg","https://about.gitlab.com/blog/developers-summit-2025-spring-event-report","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI活用の鍵はGitLabの一貫したコンテクスト 【Developers Summit 2025 イベントレポート】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-03-13\",\n      }",{"title":1871,"description":1872,"authors":1877,"heroImage":1873,"date":1859,"body":1878,"category":740,"tags":1879},[738],"本講演のテーマは、ソフトウェア開発の現場が抱えているAI活用の課題とその解決策です。シニアソリューションアーキテクト[佐々木直晴](https://gitlab.com/naosasaki)は「ソフトウェア開発の現場で、AI時代の新しいサイロが発生している」と考えています。本講演でその解決策として紹介しているのが、GitLabのAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」です。\n\n## コードがどういう背景のもとで書かれたかといった情報までAIに与えるべき\n\n### 組織全体でコンテクストを共有することができているGitLabだからこそ持てたコンセプト\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_DSC1989_resized.jpg)\n*Developers Summit 2025での講演の様子*\n\n本講演における最初のブロックにて佐々木は、コードが書かれた背景に関する情報までAIに与えることが大切なのでは、と語りかけました。\n\nソフトウェア開発の現場でAIを使う際は、断片的なエラーコードのみ渡してその理由を探らせるなどします。しかしAIの可能性を引き出すには、そのコードがどういう背景のもとで書かれ、なぜそう決まったかという情報まで与えるべきです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_TOH3572_resized.jpg)\n*GitLab合同会社 シニアソリューションアーキテクト 佐々木直晴*\n\n佐々木はGitLabのAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」は、こういったコンセプトを持っていると話しました。そうして、このコンセプトは「我々の会社だからもてたもの」と言います。\n\nGitLabはご存知のとおり、オフィスを持たずオールリモートの働き方を実践している企業です。オールリモートを実現するには、ドキュメントによるコミュニケーションが重要になります。\n\n経緯や議論をドキュメントとして残し、「なぜそう決まったか」も含め組織全体でコンテクストを共有する必要があるのです。オールリモートではメンバー間の誤解が生まれないように、記録に残るコミュニケーション技術が必要になります。\n\nそのうえで佐々木は「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)のコンセプトは、コンテクストを組織全体で共有できているGitLabだからこそ持てたものと思っている」と話しました。\n\n## AI時代の新しいサイロが発生した\n### 現在のソフトウェア開発において、AIの活用レベルは3段階に分類される\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit.jpg)\n次のブロックで佐々木は、現在のソフトウェア開発現場におけるAI活用の課題について説明しました。\n\nAIをソフトウェア開発に利用しているという会社は、2023年には64％だったところ、2024年には78％に上がっている* 状況です。今年の調査であれば、100％に近い数字になっていると想定されます。\n\nこのようにソフトウェア開発においてAIはデフォルトになっているものの、現場によって「段階がありレベル感が違う」と佐々木は話しました。活用レベルは大きく分けて3つにわけられ、各レベルで別々の課題が生じているのです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__1_.jpg)\n\nまず、ソースコードの生成にAIを活用するのが、活用レベル1です。「ここはかなりコモディティ化している」と佐々木は話しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__2_.jpg)\n\nソフトウェア開発の様々な局面で、AIを活用するのが活用レベル2です。たとえば以下のような利用があげられます。\n\n- 議論の内容をAIに要約させる\n- 会議の文字起こしをさせる\n- トラブルが起きたらAIにコードを渡して原因を解析させる\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__3_.jpg)\n活用レベル3は、局面に応じて優れたLLMを採用して使い分けている状態です。たとえばチケット管理はこのLLMを利用し、ソースコードの推奨はこのLLMにさせるといった使い分けをします。\n\n### AIの活用レベルごとに異なる課題が生じている\n\n佐々木は「我々はマーケットを見て、それぞれの活用レベルで課題があると思っている」と指摘しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__4_.jpg)\n「活用レベル1：ソースコードの生成にAIを活用」での課題は、AIが局所的な利用にとどまってしまっていることだと佐々木は指摘しました。\n\nソフトウェア開発のなかでも、ソースコードを記述している時間は21％に過ぎない* という調査結果があります。仕事場所がオフィスでも自宅でも、誰にも邪魔されず集中してコードを書ける日はなかなかありません。打ち合わせが入ったりメンバーのタスク管理をしたり、トラブルで呼び出されたりします。\n\nソースコードの記述にAIを使うこと自体はよいことです。しかしAI活用がソースコードの記述にとどまっているということは、AI活用が局所的な効率化に限定されているとも言えます。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__5_.jpg)\n「活用レベル2：ソフトウェア開発の様々な局面でAIを活用」は、AIをいろいろなシーンで使えていて一見素晴らしいように見えます。しかし、「いろいろなところに様々な機能のAIがあり過ぎて統一したいという意見が多い」と佐々木は指摘しました。\n\nソフトウェア開発にAIを使用する全世界の組織のうち、約74％は「ツールチェーンを統合したい」と答えたという調査結果があります。AIのライセンス費用や使い勝手の違いなどがあり、1つにまとめたいという課題が生じているのです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__12_.jpg)\n\n「活用レベル3：各局面に応じて優れたLLMを採用」は、一見良い状態にみえます。チケット管理やコーディングなど、それぞれのシーンで優れたAIを利用できているためです。\n\nしかし「それぞれのシーンで共有されたAIとのコンテクストが、コーディングのときに失われている」と佐々木は指摘しました。AIがそれぞれのツールに特化して閉じており、経緯や議論が個別のツールに取り残されてしまっているのです。\n\nAI間でのコンテクスト共有が不十分なので、コーディング段階でAIがいろいろな推奨をしてくれるものの、その内容には違和感が生じます。佐々木は「これはAI時代の新たなサイロだと我々は定義している」と話しました。\n\n## GitLabだからこそ提案できる、AI利用の課題に対する解決策 \n### GitLabにはソフトウェア開発用のプラットフォームとして必要な機能が一通りそろっている\n\n前項で紹介したAI利用の課題に対して、GitLabが提案するのがGitLabにおけるAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」です。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は「オールリモートでコンテクストを共有しながら会社運営をする我々だからこそできる提案」と、佐々木は強調しています。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__6_.jpg)\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)の紹介をする前に、「そもそもGitLabとは何か」について佐々木が説明しました。\n\nGitLabではソフトウェア開発において、以下のような機能が必要と考えています。\n\nチケット管理をする機能、チケット管理のなかで詳細な議論ができる機能\nソースコードリポジトリ機能\nコミットしたら、自動的に何かをしてくれるCIの仕組み\nセキュリティスキャンなど\n\n「これら機能をばらばらに提供するのでなく、ひとつのプラットフォームとして提供するのがGitLab製品のコンセプト」と佐々木は説明しました。GitLabはソフトウェア開発に必要な機能を集約したDevSecOpsプラットフォームです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__7_.jpg)\n\nこうした製品コンセプトが評価され、[2024  Gartner®  Magic  Quadrant™for  DevOps Platformsにおいて、GitLabが高く（画像の一番右上）に評価された](https://about.gitlab.com/ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops/)ことを、佐々木は紹介しました。\n\n### 今までのAIはスポットで来てもらう助っ人、GitLab Duoは「勝手を知っているチームの一員」として働く\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__8_.jpg)\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__9_.jpg)\n\n前項で紹介したように、ソフトウェア開発にはいろいろな機能が必要になります。GitLabのAI「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」は、それら機能においてAIが同じコンテクストをもってサポートすると佐々木は解説しました。\n\nイシュー割り当てや議論要約、ソースコード生成、テストコードやテストケースの生成、また実装から詳細な説明用の資料を生成するなどの工程を、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は一貫してサポートします。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)はインターネットだけでなく、自社内のAIのゲートウェイを向けることにより自社のネットワークから出ずにAIを使えるのも強いと佐々木は強調しました。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使えば、以下のような\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__10_.jpg)\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__11_.jpg)\nDevSecOpsのループ全ての局面にAIの力をまぶすことができます。\n\n- 計画・議論\n- ロードマップ・スケジュール構築\n- イシューの作成・アサイン\n- 開発・検証\n- デプロイ\n- パフォーマンスのモニタリングとカイゼン\n\n佐々木は、「たとえて言うなら、今までのAIはスポットでちょっと来てもらう助っ人のようなものだった」と指摘しました。スポットの助っ人は、タスクの背景などは分かりません。限定的な情報のなかで、サポートをしなければならないのです。\n\nたとえば断片的なエラーだけ渡され「これは何か」と聞かれても、AIは与えられた情報のなかで提案を返すしかありません。佐々木は「AIは本当ならもっとできるはず、というのが我々の思いだ」と強調しました。\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_TOH3594_resized.jpg)\n一方GitLab Duoは、「勝手の知っているチームの一員として働く」と佐々木は指摘しています。GitLabを使えば、ソフトウェア開発におけるものづくりの全ての作業を同じプラットフォーム内で実行することが可能です。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、これらGitLabにおける活動を多く把握しています。たとえば、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、ソースコードの内容を変更した背景や流れを理解しているわけです。そのため、そのソースコードをプッシュしてCIで失敗したら、GitLab Duoはより深く原因の分析をおこなえます。\n\nまたソフトウェア運用中に、深刻な脆弱性が見つかったとしましょう。このとき[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は「脆弱性に対応するには、リポジトリのこのファイルとこのファイルをこう直したらいいですよ」と提案してくれるのです。\n\nこのように局面をまたいだAIの使い方は、単一のデータストアがないとできないと佐々木は強調しました。リポジトリ・チケット管理・CI・セキュリティスキャンなどソフトウェア開発に必要な機能を、GitLabは全て有しています。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、GitLabのなかでこれら機能と同一プラットフォームに存在し、その全ての活動を把握しているわけです。それゆえに、スポットの助っ人でなくチームの一員として活躍することができます。\n\n最後に佐々木は、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使ったデモを紹介しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_DSC2007_resized.jpg)\n本デモでは、CIが失敗した理由を[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)に調べさせています。そうするとGitLab Duoは、エラーログだけからは推察することが難しい関数や引数の型を使った修正例を提案しました。本デモでGitLab Duoは、デプロイが失敗した原因を、ソースコードの変更内容まで鑑みて分析しているのです。\n\nChatGPTにエラーログだけを渡して解析させるように、AIをスポットの助っ人として使うやり方であれば、コンテクストは共有されません。そのため、この修正例は出ないのではないかと佐々木は強調しました。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)はトラブル発生時に、断片的なログから推奨を返すのでなく、過去の計画まで遡りなぜ失敗が起こったかというところまで助けてくれます。本講演の最後で佐々木は、開発者がより創造的な作業に集中できる環境を作りたいという思いでGitLabを提供させていただいていると語りました。\n\n＊参考元：[GitLab「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_developers-summit-2025-spring-event-report) \n\n## 会場で配布したお土産について\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752174658/Blog/a8q0fxpkysdomfbarvfj.jpg\">\n会場にて本講演のアンケートに答えて下さった参加者の方には、バレンタインデーのチョコとナノブロックをお渡ししました。このナノブロックは、GitLabのロゴがモチーフとなっています。かわいらしいこのロゴの形は、狸をイメージしていることはご存知でしたでしょうか？\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/image5_resized.jpg)\n",[280,1880,702,904,721],"inside GitLab",{"slug":1882,"featured":92,"template":681},"developers-summit-2025-spring-event-report","content:ja-jp:blog:developers-summit-2025-spring-event-report.yml","Developers Summit 2025 Spring Event Report","ja-jp/blog/developers-summit-2025-spring-event-report.yml","ja-jp/blog/developers-summit-2025-spring-event-report",{"_path":1888,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1889,"content":1895,"config":1900,"_id":1902,"_type":16,"title":1903,"_source":17,"_file":1904,"_stem":1905,"_extension":20},"/ja-jp/blog/what-is-agile-development",{"title":1890,"description":1891,"ogTitle":1890,"ogDescription":1891,"noIndex":6,"ogImage":1892,"ogUrl":1893,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1893,"schema":1894},"アジャイル開発とは？意味や進め方、DevSecOpsとの関係性を解説","この記事では、アジャイル開発の概要やウォーターフォール開発との違い、導入するメリット・デメリットなどを解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663632/Blog/Hero%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA7.jpg","https://about.gitlab.com/blog/what-is-agile-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"アジャイル開発とは？意味や進め方、DevSecOpsとの関係性を解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-06\",\n      }",{"title":1890,"description":1891,"authors":1896,"heroImage":1892,"date":1897,"body":1898,"category":672,"tags":1899},[738,696],"2025-03-06","アジャイル開発はシステム・ソフトウェア開発手法のひとつであり、近年注目されています。実際に自社の開発課題を解決するために、アジャイル開発の導入を検討している担当者は多いのではないでしょうか。\n\nこの記事では、アジャイル開発の概要やウォーターフォール開発との違い、導入するメリット・デメリットなどを解説します。アジャイル開発におけるAI活用や、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の関係性についても触れているのでぜひ参考にして下さい。\n\n## アジャイル開発とは？\n\n![アジャイル開発2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA2.jpg)\n\nアジャイル開発とは、ソフトウェア開発において通常1週間から4週間程度の反復期間を設定し、企画から開発、テストまでの工程を機能単位ごとに繰り返し進めていく開発手法のことです。「アジャイル」という言葉には、「素早い」「機敏な」という意味があり、その言葉の通りアジャイル開発はスピード感のある開発が可能です。\n\n近年ビジネス環境の変化が激しく、日々変化するニーズや市場に柔軟に対応していく姿勢が必要です。アジャイル開発ならスピード感を持って開発を進められるだけでなく、仮説検証を含めた柔軟な開発が可能になります。\n\n物事の予測が立てにくい不確実な要素が多い時代の中で、顧客ニーズにマッチした新しい価値を創造するための手法としてアジャイル開発が注目されているのです。\n\n## アジャイルソフトウェア開発宣言とは？\n\n「アジャイルソフトウェア開発宣言」とは、17名のソフトウェア開発者が議論を行なって文書としてまとめたアジャイル開発の原則のことです。\n\n2001年に公開されたことをきっかけに、世界中にアジャイル開発の考え方が広まり、多くのソフトウェア開発者達に支持されました。\n\nアジャイルソフトウェア宣言では、アジャイル開発を実現するために以下の4つの価値を示しています。\n\n1. プロセスやツールよりも「個人と対話」  \n2. 包括的なドキュメントよりも「動くソフトウェア」  \n3. 契約交渉よりも「顧客との協調」  \n4. 計画に従うことよりも「変化への対応」\n\n※出典：[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)\n\n## アジャイル開発とウォーターフォール開発との違い・比較\n\n![アジャイル開発5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA5.jpg)\nアジャイル開発が登場する前にはウォーターフォール開発が主に活用されており、ソフトウェア開発の初期段階として位置付けられています。\n\nウォーターフォール開発は機能単位ごとに開発工程を繰り返すアジャイル開発とは異なり、開発前に全ての機能計画を立て、その計画通りに開発を進める手法になります。つまり、要件定義から設計、実装、テスト、運用といった各工程を順序立てて直線的に開発を進めていきます。\n\n開発対象の機能を事前に決定して開発を進めるため、最終的なリリース時期がわかりやすいというメリットがあります。一方、開発前から全ての工程が決まっているため、仕様変更がしにくいなどの課題もあります。\n\n## アジャイル開発でよく採用されている手法とは？\n\nアジャイル開発にはさまざまな開発手法がありますが、中でも「スクラム」と呼ばれる開発手法が最も採用されています。スクラムとは、少人数のチームにわかれて密にコミュニケーションをとりながら開発を進める手法です。\n\n実際に「[17th State of Agile Report](https://digital.ai/resource-center/analyst-reports/state-of-agile-report/)」の調査では、アジャイル開発手法の中で、63%がスクラムを採用していると報告されています。なお、スクラムの人気は2006年の最初の調査以降続いています。\n\nなぜ数ある開発手法の中でスクラムが最も採用されるのでしょうか。理由のひとつとして汎用性の高さにあると考えられます。スクラムはシンプルなフレームワークであり、さまざまな開発プロジェクトに活用することが可能です。\n\nまた、スクラムのルールが示された「[スクラムガイド](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)」は、18ページ程度の少なめのボリューム感となっており、内容もシンプルです。そのため、スクラムの全体の流れや仕組みについて理解がしやすく、自社の開発プロジェクトに合わせて応用がしやすいといえます。\n\nさらに、スクラムは有名な手法であることから開発事例も多く、情報収集が容易であるという事情も採用される理由として挙げられます。\n\n## アジャイル開発の流れ\n\nアジャイル開発はどのような流れで進められるでしょうか。IPAの「[アジャイル開発の進め方](https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065606.pdf)」を参考にスクラムを例に全体の流れを紹介します。\n\n1. プロダクトバックログの作成  \n2. スプリントプランニングの実施  \n3. 開発作業の実施\n\n### 1. プロダクトバックログの作成\n\nまずプロダクトバックログの作成を行います。プロダクトバックログとは、開発したいプロダクトが提供する価値をまとめたリストのことです。具体的には、顧客が求める機能やユーザーエクスペリエンスなどを洗い出してリストを作成していきます。\n\nこの際、リストは作業の優先順位をつけて並んでいることがポイントです。また、作成するリストは顧客を含むプロジェクトの関係者全員に共有する必要があるため、誰もが理解できる言葉で記載しなければなりません。\n\n### 2. スプリントプランニングの実施\n\n「スプリント」とは、スクラムにおける開発工程の反復（作業）期間のことです。スプリントが開始される前にスプリントプランニングを実施しましょう。具体的には、作成したプロダクトバックログのリストの中から対象のスプリントで扱う項目を選び出します。ここで選び出した項目は「スプリントバックログ」と呼ばれます。\n\nその後細かにタスクに落とし込み、スクラムチーム内で作業を分担します。なお、各タスクにおいては一般的に2〜8時間程度の時間単位で見積もられます。\n\n### 3. 開発作業の実施\n\n実際にスプリント内の開発作業を実施します。スプリントの途中では、スクラムチーム内で活動状況を報告する「デイリースクラム」が行われます。デイリースクラムは、達成すべきゴールに向けて課題になっていることを共有し、チーム全員が協力して解決を目指すためのミーティングです。\n\n無事にスプリントが完了した段階では「スプリントレビュー」と呼ばれるミーティングが開催され、関係者全員で完成したプロダクトのデモンストレーションを行います。\n\nまた、スプリントレビューの後には「スプリントレトロスペクティブ」が行われ、開発におけるプロセスを振り返ります。うまくいかなかったことは改善策を洗い出し、次のスプリントに活かします。\n\n## アジャイル開発のメリット\n\n![アジャイル開発6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA6.jpg)\nアジャイル開発には以下のようなメリットがあります。\n\n* 開発スピードが早い  \n* ユーザーのニーズを反映しやすい  \n* 手戻りの発生を防止・軽減しやすい  \n* 継続的な学習と改善の機会が得られる\n\n### 開発スピードが早い\n\nアジャイル開発は機能を小さな単位にわけて開発とリリースを繰り返して進めるため、結果的に優先度の高い機能から素早く価値を提供することが可能です。また、最初にプロダクトの全ての機能計画を立ててから開発するわけではないため、本来不要だった機能に関するドキュメント作成などに時間と手間をかけずに開発を進められます。\n\n一方、ウォーターフォール開発の場合は計画を重視することから、開発前に要件定義書や設計書などの作成に時間をかける必要があります。ビジネスにおいて「競合優位性を確立したい」「早期に顧客のフィードバックを収集したい」などの目的があるなら、小さな単位で素早く価値を提供できるアジャイル開発の採用が適切だといえます。\n\n### ユーザーのニーズを反映しやすい\n\nアジャイル開発は小さな単位で開発を進めるため、開発途中で顧客の要望や市場の変化に応じて優先順位や仕様を見直すことができます。顧客ニーズや市場調査の結果を踏まえながら柔軟に開発を進めることで最大限の価値を提供できるため、顧客満足度の向上にもつながります。\n\n一方、ウォーターフォール開発ではプロジェクトの初期段階で計画を確定させるため、途中での変更が困難になりがちです。ただし、アジャイル開発で変更に対応できるといっても、変更自体のコストや影響度は慎重に評価する必要があります。\n\n例えば、すでに開発した機能に大きな変更が必要な場合は、再設計や再実装のコストが発生します。アジャイル開発は変更を受け入れやすい仕組みを持っていますが、それは全ての変更が容易であることを意味するわけではありません。\n\n### 手戻りの発生を防止・軽減しやすい\n\nアジャイル開発は機能単位に区切って開発からテスト、リリースまで実行するため、テストの段階で不具合や問題が発生した場合でも手戻りの工数を最小限に抑えられます。\n\nウォーターフォール開発の場合は、事前に決めた計画通りに開発を進めるため、不具合が発生した箇所によっては手戻りの工数が大きくなってしまうデメリットがあります。アジャイル開発なら、前提として開発している範囲が少ないため、大きな手戻りが発生しにくいです。\n\n### 継続的な学習と改善の機会が得られる\n\nアジャイル開発では、小さな単位での開発を繰り返し、振り返りを行うプロセスが組み込まれています。これにより、チームは実践と改善を重ねながら学習を進める機会を得られます。例えば、スプリントごとの振り返り（スプリントレトロスペクティブ）では、うまくいったことや課題を議論し、より良い進め方を模索します。\n\nまた、開発途中では毎日ミーティングが実施され、品質の高いプロダクトを生み出せるようメンバー同士が意見を出し合います。そのようなプロセスを通してチームワークの向上も期待できるでしょう。\n\n## アジャイル開発のデメリット\n\n![アジャイル開発4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA4.jpg)\nアジャイル開発にはデメリットもあるため、対策を踏まえて把握しておくことが大切です。\n\n* 長期的な見通しの立て方が従来と異なる  \n* プロダクトの方向性を維持するための工夫が必要\n\n### 長期的な見通しの立て方が従来と異なる\n\nアジャイル開発では、詳細な計画を前もって確定させない代わりに、反復的な開発を通じて計画を継続的に見直し、調整していきます。そのため、従来のウォーターフォール型開発のように、プロジェクト全体の詳細なスケジュールを初期段階で確定することは難しくなります。また、顧客の要望で何度も仕様変更が発生した場合、最終リリースまでのスケジュールが伸びてしまう可能性もあります。\n\nアジャイル開発において適切なスケジュール管理を行うためには、チームの開発速度を計測、定期的に計画と実績を比較し、場合によっては優先順位や計画を見直す必要があります。\n\n### プロダクトの方向性を維持するための工夫が必要\n\nアジャイル開発では、開発途中での変更を受け入れやすい特徴がある一方で、その柔軟性を適切にコントロールしなければ、本来目指していたプロダクトの方向性から逸れてしまうリスクがあります。\n\n例えば、顧客からの仕様変更や機能追加の要望を受け入れ過ぎていると、プロジェクト全体の方向性を見失ってしまう場合があります。また、顧客との摩擦や齟齬が生まれてしまう可能性もあり、プロジェクトがスムーズに進まないという事態も招いてしまうでしょう。\n\nこのようなことを避けるためには、個々の単位だけでなく定期的な全体像の把握と、関係性全員での認識の擦り合わせが必要です。\n\n## アジャイル開発が向いている・向いていないプロジェクト\n\nアジャイル開発にはさまざまなメリットがありますが、プロジェクトの特性・内容によっては向き・不向きがあるため事前に把握し、自社に適した開発手法を採用しなければなりません。\n\nアジャイル開発は柔軟に開発を進められるメリットがあるため、ニーズが漠然としていたり、状況の変化が想定されていたりするケースに向いています。また、発注者が積極的に関わる案件なら、頻繁にフィードバックを受けやすいアジャイル開発の強みを十分に活かせるでしょう。\n\n反対に、要件が明確で大きな変更が想定されず、納期の厳守を求められる場合は、アジャイル開発の採用には慎重な検討が必要といえます。また、開発メンバーと発注者との間でコミュニケーションがとりにくいケースでアジャイル開発を採用しても、開発がスムーズに進まない可能性が高いため別の手法を検討するのが良いでしょう。\n\n## アジャイル開発を成功させるためのポイント\n![アジャイル開発8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA8.jpg)\n\nアジャイル開発を成功させるために以下のポイントを押さえておきましょう。\n\n* アジャイル開発の特性を理解した人材を選定する  \n* メンバー間で密にコミュニケーションをとる  \n* [CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)など自動化のテクノロジーを取り入れる  \n* 情報の透明性を保つ\n\n### アジャイル開発の特性を理解した人材を選定する\n\nアジャイル開発では、柔軟な仕様変更に伴うメンバー間での擦り合わせや協力が重要となります。必ずしもアジャイル開発の経験が豊富である必要はありませんが、ここまで紹介してきたようなアジャイル開発の特徴を理解し、オープンな姿勢でチームや関係者とコミュニケーションを取れる人材が求められます。\n\n「プロダクトオーナー」や開発チームを支援する「スクラムマスター」の役割も重要です。場合によってはアジャイルコーチによるトレーニングを活用したり、経験豊富な外部の専門家にサポートを依頼したりすることも有効です。\n\n### メンバー間で密にコミュニケーションをとる\n\nアジャイル開発を成功に導くためには、顧客を含めた関係者全員がコミュニケーションを密にとっていくことが大切です。先ほど説明したような「デイリースクラム」や「スプリントレビュー」などのミーティングを定期的に実施し、メンバー間でのコミュニケーションを活性化させましょう。\n\nチームメンバーが自由に意見を出しやすい雰囲気の中で開発を進めることで、進捗管理や品質の維持もしやすくなります。特に上下関係などの関係性を取り払って、お互いが率直に提案や指摘をし合えるような環境ならプロジェクトの成功率をより高められるでしょう。\n\n### CI/CDなど自動化のテクノロジーを取り入れる\n\nアジャイル開発をスムーズに進めるためには、[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)など自動化のテクノロジーを取り入れることもポイントです。[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/)の相性は良く、機能単位ごとの開発フローを[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)によって自動化することによって、一定の品質を維持したままリリース頻度の向上を実現できます。[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### 情報の透明性を保つ\n\nアジャイル開発においてはチームメンバーと顧客との間で信頼関係を構築することが求められます。顧客側が開発の中でどのようなことが行われているのかが把握できないと不安を抱いてしまいます。例えば、成果物が納品されるまで状況を掴めないような進め方だと、認識の齟齬が生まれる原因になるでしょう。\n\nそのため、アジャイル開発で扱う情報においては常に透明性をもたせることが大事です。\n\n例えば、以下のような情報に透明性をもたせて、顧客とチームメンバーとの間でスムーズに情報共有できるような仕組みを構築しておきましょう。\n\n* 全体の開発スケジュール  \n* 開発の作業内容  \n* 開発メンバーの保有スキル  \n* 開発の進捗状況 など\n\n情報の透明性を保ち、チームの誰でも同じ情報にアクセスできる状態のことをSingle Source Of Truth（SSOT、信頼できる唯一の情報源）と呼び、これがあることでチームの自律的な行動を促すことができます。こちらに関する記事は下記が詳しいため、併せてチェックしてみてください。\n\n[組織の自律自走を促すコミュニケーション](https://learn.gitlab.com/c/effective-communication-for-autonomous-organization-deck?x=JBqxmQ)\n\n## アジャイル開発におけるセキュリティの課題\n\nアジャイル開発では、仕様変更や機能追加などに対して柔軟に対応でき、スピード感を持って開発を進められます。その一方で、セキュリティが後回しにされたり、おろそかにしてしまったりするケースも多いといわれています。この課題に対応するには、リリース直前に実施される人手による脆弱性診断やペネトレーションテストだけでなく、静的解析ツールやコンテナスキャンなどの自動化されたセキュリティテストを[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)パイプラインに組み込むことが効果的です。\n\nなお、セキュリティ対策の重要性はアジャイル開発に限ったことではありません。[IPAの調査](https://www.ipa.go.jp/security/10threats/10threats2024.html)から近年組織ではさまざまなセキュリティインシデントが発生していることがわかります。開発の早い段階でセキュリティ上の問題を発見し、迅速な対応が可能になるこれらのプラクティスは「シフトレフト」と呼ばれ、セキュリティリスクをより早い段階で見つけ、手戻りを少なく品質をあげていく手法として、アジャイル開発以外での開発手法でも重要であると言われています。\n\n## アジャイル開発におけるAI活用について\n![アジャイル開発1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA1.jpg)\n\nアジャイル開発を採用する際には、AIを積極的に活用する視点も持っておきましょう。\n\n例えば、前述の通り、アジャイル開発ではリリース直前での脆弱性診断だけでなく、開発段階などでも常時セキュリティスキャンなどで脆弱性を検出することが重要です。この時に[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)のようなAIを活用することによってソフトウェアの脆弱性をより効率的に把握して修正でき、開発におけるセキュリティリスクを軽減することができます。\n\nその他にも、テストコードを書いたり、ソースコードからドキュメントから詳細設計書やパラメータシート相当のものを作成するなど、特にアジャイル開発でよく行われることにAIの支援を受けることができ、開発効率の向上を実現することができます。\n\nこれらの機能のデモもありますので、参考にしていただければと思います。\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/jygdsxzBC4Y?si=k6NWiV2Jc29fS0Uu\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## アジャイル開発とDevSecOpsの関係性\n\n先ほど挙げたアジャイル開発のセキュリティの課題においては「[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)」の必要性が高まっています。\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)とは、開発（Dev）・セキュリティ（Sec）・運用（Ops）を連携した開発アプローチのことです。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)では、セキュリティを後回しにすることなく、開発工程（Dev）の段階で対策を行い、ソフトウェアの安全性を高めます。\n\nアジャイル開発と[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)は親和性が高く、両者とも迅速なリリースと継続的な改善を推進する手法や考え方です。つまり、アジャイル開発において[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のアプローチも取り入れることで、セキュリティレベルを高めながら、迅速なソフトウェア開発を実現できます。補足として、アジャイル開発と同様、ウォーターフォール開発でもDevSecOpsの考え方は積極的に取り入れるべきポイントです。\n\nなお、「[GitLab](https://about.gitlab.com/ja-jp/)」なら[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のアプローチを踏まえたソフトウェア開発が可能です。アジャイル開発の代表的手法である「スクラム」を1つのプラットフォームで運用することもできるため、ぜひ自社のプロジェクトにお役立て下さい。\n\n## アジャイル開発に関するQ＆A\n![アジャイル開発3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA3.jpg)\n最後にアジャイル開発に関するQ＆Aを紹介します。\n\n### アジャイル開発の普及率は？\n\n「[DX白書2023](https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf)」によると、アジャイル開発を「全社的に活用している」「事業部で活用している」と回答した企業の割合の合計は22.9%となっています。米国の場合は53.9%となっているため、アジャイル開発の普及率において日米差は大きいことがわかります。\n\n### アジャイル開発が失敗する原因は？\n\nアジャイル開発が失敗してしまう原因はさまざまですが、主に以下が挙げられます。\n\n* アジャイル開発に不向きなプロジェクトで採用している  \n* 顧客とチームメンバーとの間でコミュニケーションが不足している  \n* プロダクトオーナーやスクラムマスターが役割を果たせていない \n\nそもそもアジャイル開発に向いていないようなプロジェクトで採用してしまうと、アジャイル開発の強みを活かせず失敗してしまう可能性が高まります。その他、関係者間でのコミュニケーション不足が発生していたりする場合、開発の方向性が大きくブレたりなどの事態を招く原因となるでしょう。\n\n## アジャイル開発の特徴を十分に理解して自社で導入しよう\n\nアジャイル開発なら、開発途中で発生する急な仕様変更にも柔軟に対応でき、顧客ニーズにマッチした価値を提供することが可能です。\n\nしかし、アジャイル開発に限ったことではないですがセキュリティ対策における課題もあるため、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のアプローチも積極的に取り入れていく姿勢も求められます。\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)プラットフォームを提供する[GitLab](https://about.gitlab.com/ja-jp/)では、世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しています。ソフトウェア開発におけるAI活用や、[DevSecOps](https://about.gitlab.com/ja-jp/topics/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-agile-development)  \n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[1389],{"slug":1901,"featured":92,"template":681},"what-is-agile-development","content:ja-jp:blog:what-is-agile-development.yml","What Is Agile Development","ja-jp/blog/what-is-agile-development.yml","ja-jp/blog/what-is-agile-development",{"_path":1907,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1908,"content":1914,"config":1920,"_id":1922,"_type":16,"title":1923,"_source":17,"_file":1924,"_stem":1925,"_extension":20},"/ja-jp/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"title":1909,"description":1910,"ogTitle":1909,"ogDescription":1910,"noIndex":6,"ogImage":1911,"ogUrl":1912,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1912,"schema":1913},"GitLab Pagesで手軽に数ステップでウェブサイトを作成","このチュートリアルでは、GitLab Pagesとすぐに使えるカスタマイズ可能なテンプレートを活用して、短時間で個人用ウェブサイトを作成・公開する方法を解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097716/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_7c3TDgNgct9xQbmTJSw0de_1750097716096.png","https://about.gitlab.com/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Pagesで手軽に数ステップでウェブサイトを作成\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alex Fracazo\"}],\n        \"datePublished\": \"2025-03-03\",\n      }",{"title":1909,"description":1910,"authors":1915,"heroImage":1911,"date":1917,"body":1918,"category":701,"tags":1919},[1916],"Alex Fracazo","2025-03-03","個人用ウェブサイトは、デジタルクリエイターやIT系のプロフェッショナルにとって単なるツールではなく、ブランドを表現する場です。しかしゼロから作るとなると、時間もお金もかかります。\n\n[GitLab Pages](https://docs.gitlab.com/user/project/pages/)なら、SSL証明書やGitLab独自のドメインなどの機能がFreeプランでも標準搭載されており、プロが作ったようなウェブサイトを簡単に公開できます。\n\nこのチュートリアルでは、GitLab Pagesを使って魅力的な個人ウェブサイトを作成する方法を紹介します。使いやすくカスタマイズ自在なテンプレートを用意しているので、簡単に自分らしいウェブサイトを作成できます。では早速始めましょう！\n\n## 準備するもの\n\n始める前に、下記を用意してください。\n\n* GitLabアカウント（[Freeプラン](https://about.gitlab.com/ja-jp/pricing/)でOK）\n* HTML/CSSの基本的な知識\n* ウェブサイトに載せるコンテンツと画像（任意）\n\nGitLabアカウントを作成し、必要なコンテンツを準備できたら、次のステップに進みましょう！\n\n## ステップ1：新規プロジェクトを作成する\n\n1. GitLabアカウントにサインインし、プロジェクトを作成します。\n\n![GitLab Pagesチュートリアル - ウェルカム画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097724/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183716_aHR0cHM6_1750097724662.png)\n\n2.「**空のプロジェクトを作成**」をクリックします。\n\n![GitLab Pagesチュートリアル - 新規プロジェクト作成画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183814_aHR0cHM6_1750097724663.png)\n\n3. プロジェクトの詳細を入力します。\n    * プロジェクト名を`yourusername.gitlab.io`に設定します。`yourusername`の部分は、ご自身のGitLabユーザー名に置き換えてください。**ヒント**：プロジェクト名は、ウェブサイトのURLに影響します。プロジェクト名を`yourusername.gitlab.io`に設定すると、ウェブサイトのURLは`https://yourusername.gitlab.io`になります（追加パスなし）。別のプロジェクト名を使用した場合は、サイトのURLは`https://yourusername.gitlab.io/project-name`になります。\n    * プロジェクトの公開範囲を「公開」に設定します。\n4 .「**プロジェクトを作成**」をクリックします。\n\n![GitLab Pagesチュートリアル - 空のプロジェクトの作成画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097724666.png)\n\n![GitLab Pagesチュートリアル - カスタマイズされた「はじめに」ページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097724668.png)\n\n## ステップ2：テンプレートファイルを追加する\n\nまず、リポジトリ内に以下の2つの新しいファイルを作成します。\n\n![GitLab Pagesチュートリアル - 個人用ページに新しいファイルを追加](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097724669.png)\n\n1. まず、`index.html`を作成します。\n    * プロジェクトで「**+**」ボタンをクリックし、「**新規ファイル**」を選択します。\n    * ファイル名を`index.html`に設定します。\n![GitLab Pagesチュートリアル - 新規ファイルページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097724671.png)\n    * HTMLコンテンツを追加します。\n        * 以下のサンプルHTMLを使用してください（プロによるアドバイス：GitLab Duo Chatに依頼すると、さらに便利な機能を備えたHTMLを生成できます）。\n\n```    \n\u003C!DOCTYPE html>\n\u003Chtml>\n\u003Chead>\n    \u003Cmeta charset=\"utf-8\"/>\n    \u003Ctitle>[名前] - [役職]\u003C/title>\n    \u003Cmeta name=\"description\" content=\"[Your Name] is a [Your Title].\"/>\n    \u003Cmeta name=\"author\" content=\"[Your Name]\"/>\n    \u003Cmeta property=\"og:title\" content=\"[Your Name]\" />\n    \u003Cmeta property=\"og:description\" content=\"[Your Title]\" />\n    \u003Cmeta property=\"og:image\" content=\"og.png\" />\n    \u003Cmeta name=\"viewport\" content=\"width=device-width,initial-scale=1\"/>\n    \u003Clink href=\"https://unpkg.com/basscss@8.0.2/css/basscss.min.css\" rel=\"stylesheet\">\n    \u003Clink href=\"style.css\" rel=\"stylesheet\">\n    \u003Clink rel=\"shortcut icon\" type=\"image/png\" href=\"favicon.png\"/>\n\u003C/head>\n\u003Cbody>\n\u003Cdiv class=\"content\" id=\"content\">\n  \u003Cdiv class=\"p2 sm-p4 mt2 sm-mt4 mb2 sm-mb4\">  \n  \u003Cdiv class=\"fade mt3\">\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">\n      \u003Cimg class=\"photo\" src=\"profile.png\" width=\"64\" height=\"64\">\n    \u003C/a>\n  \u003C/div>\n  \u003Ch2 class=\"mb0 mt4 fade\">\n    Hello, I'm [Your Name] \n    \u003Cspan class=\"smallcaps\">(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Your Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/h2>\n  \u003Ch2 class=\"mt0 mb4 fade gray\">\n    I'm a [Your Title]\n  \u003C/h2>\n  \u003Cp class=\"mb4 fade\">\n    I'm a [Your Role] at [Your Company], [Brief company description].\n  \u003C/p>\n  \u003Cdiv class=\"fade\">\n    \u003Cp class=\"fade mb4\">\n      Your personal statement about what you do and what you're interested in. Add your contact preferences here.\n    \u003C/p>\n  \u003C/div>\n  \u003Cp class=\"fade mb4\">\n    \u003Cspan class=\"gray\">—\u003C/span> \n    [Your Name] \n    \u003Cspan class=\"smallcaps>(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Your Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/p>\n  \u003C/div>\n\u003C/div>\n\u003C/body>\n\u003C/html> \n```\n\n* コミットメッセージを追加します（例：「index.htmlを追加」）。\n  * 「**変更のコミット**」をクリックします。\n\n2. `style.css`を作成します（上記と同じ手順）。\n\n```\nbody {\n  margin: 0;\n  padding: 0;\n  background: #000;\n  color: #f4f4f4;\n  font-family: \"Graphik Web\", system-ui, -apple-system, BlinkMacSystemFont, \"Helvetica Neue\", \"Helvetica\", \"Segoe UI\", Roboto, Ubuntu, sans-serif;\n  font-weight: 400;\n  font-smooth: antialiased;\n  -webkit-font-smoothing: antialiased;\n  -moz-osx-font-smoothing: grayscale;\n}\n\na {\n  color: #ff310a;\n  text-decoration: none;\n}\n\na:hover {\n  color: #CFEF54\n}\n\n.content {\n  max-width: 40rem;\n  margin: 0 auto;\n}\n\nimg.photo {\n  border-radius: 50%;\n}\n\np {\n  font-size: 1.5rem;\n  line-height: 1.4;\n  margin: 0;\n  letter-spacing: -0.05rem;\n}\n\nh2 {\n  font-weight: 400;\n  line-height: 1.3;\n  letter-spacing: -0.05rem;\n}\n\n.smallcaps {\n  font-variant: small-caps;\n  color:#333;\n}\n\n.gray{\n  color: #999;\n}\n\n.preloader {\n  display: flex;\n  justify-content: center;\n  align-items: center;\n  height: 100vh;\n  height: -moz-available;\n  height: -webkit-fill-available;\n  height: fill-available;\n  width: 100%;\n  background: #000;\n  position: fixed;\n  top: 0;\n  left: 0;\n  z-index: 9999;\n  transition: opacity 0.3s linear;\n  transform: translate3d(0, 0, 0);\n}\n\nbody.loaded .preloader {\n  opacity: 0;\n}\n\n.fade {\n  animation: fadeIn 1s ease-in-out both;\n}\n\n.fade:nth-child(2) {\n\tanimation-delay: 1s;\n}\n\n.fade:nth-child(3) {\n\tanimation-delay: 2s;\n}\n\n.fade:nth-child(4) {\n\tanimation-delay: 3s;\n}\n\n.fade:nth-child(5) {\n\tanimation-delay: 4s;\n}\n\n.fade:nth-child(6) {\n\tanimation-delay: 5s;\n}\n\n.fade:nth-child(7) {\n\tanimation-delay: 6s;\n}\n\n.fade:nth-child(8) {\n\tanimation-delay: 7s;\n}\n\n.fade:nth-child(9) {\n\tanimation-delay: 8s;\n}\n\n.fade:nth-child(10) {\n\tanimation-delay: 9s;\n}\n\n.fade:nth-child(11) {\n\tanimation-delay: 10s;\n}\n\n.fade:nth-child(12) {\n\tanimation-delay: 11s;\n}\n\n.fade:nth-child(13) {\n\tanimation-delay: 12s;\n}\n\n@keyframes fadeIn {\n\tfrom {\n\t\topacity: 0;\n\t\ttransform: translate3d(0, 0%, 0);\n\t}\n\tto {\n\t\topacity: 1;\n\t\ttransform: translate3d(0, 0, 0);\n\t}\n} \n\n```\n\n## ステップ3：GitLab CIファイルを設定する\n\nGitLabによるサイトのビルドおよびデプロイ方法を指定するGitLab CI設定ファイルを作成する方法は2通りあります。\n\n![GitLab Pagesチュートリアル - CI/CDパイプライン画面を使用したワークフローの最適化画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378215/Blog/ny6eumkybcrlprelf7ze.png)\n\n**オプション1 ：パイプラインエディタを使用する（推奨）**\n\n1. プロジェクト内で**「ビルド」>「パイプラインエディタ」**の順にアクセスします。\n\n![GitLab Pagesチュートリアル - パイプラインエディタ／mainブランチ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097724672.png)\n\n2. `.gitlab-ci.yml`ファイルが自動的に作成されます。\n3. 以下の設定をコピー＆ペーストします。\n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\n![GitLab Pagesチュートリアル - ウィンドウ内の新規ファイル](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097724673.png)\n\n**オプション2：手動で作成する**\n\nファイルを手動で作成する場合：\n1. 新規ファイルを作成し、名前を`.gitlab-ci.yml`に設定します。\n2. 以下の設定を追加します。\n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\nGitLab CI設定ファイルは、サイトの稼働に重要な要素です。このファイルが、GitLabにサイトのビルドとデプロイ方法を指示します。\n\n各部分がどのような役割を果たしているのかを見てみましょう。\n\n**スクリプト部分**\n\n```\nscript:\n  - mkdir .public\n  - cp -r * .public\n  - mv .public public\n```\n\nこれにより、`public`というフォルダが作成され、ウェブサイトの全ファイルがその中にコピーされます。GitLab Pagesはこのフォルダを使ってサイトを公開しますが、必要に応じて[公開フォルダを変更](https://docs.gitlab.com/user/project/pages/introduction/#customize-the-default-folder)することもできます。\n\n**only部分**\n\n```\nonly:\n  - main\n\n```\n\nこれにより、GitLabはmainブランチに変更が加えられた場合のみ、サイトの更新を行い、実験的な変更が誤ってサイトに反映されるのを防ぎます。\n\n## ステップ4：ウェブサイトをデプロイする\n1. すべての変更をコミットします。\n2. **「ビルド」>「パイプライン」**の順にアクセスして、デプロイの進行状況を確認します。\n3. パイプラインが完了するのを待ちます（緑のチェックマークで完了を確認）。\n\n![GitLab Pagesチュートリアル - 新規ページ用のパイプラインを実行中](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097724674.png)\n\n![GitLab Pagesチュートリアル - 新規ページ用のパイプライン成功](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097724676.png)\n\n## ステップ5：ウェブサイトにアクセスする\n\nパイプラインが正常に完了すると、ウェブサイトが**https://[yourusername].gitlab.io/**で利用可能になります。\n\nデプロイされたウェブサイトの概要や追加設定は、プロジェクトの**「デプロイ」>「ページ」**セクションで確認できます。このセクションでは、次のような役立つ情報を確認することができます。\n\n* ウェブサイトにアクセスするためのURL   \n* ドメイン設定\n* GitLabでは、デフォルトで「**一意のドメイン**」が有効になっています。GitLabが提供するドメインを使用する場合は、必ずこれを無効にしてください。詳しくは、[独自ドメインに関するドキュメント](https://docs.gitlab.com/ee/user/project/pages#unique-domains)をご覧ください。\n* HTTPS証明書のステータス\n* 最近のデプロイ\n* 追加の設定オプション\n* カスタムドメイン\n\nこのセクションは、カスタムドメインの設定やデプロイのトラブルシューティングを行う際に、特に役立ちます。\n\n**サイトをカスタマイズする**\n\n![GitLab Pagesチュートリアル - サイトのカスタマイズ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378219/Blog/uhkkbfzexgpyooswyyye.png)\n\n1. `index.html`内のすべての「Your...」プレースホルダーを自分の情報に置き換えます。\n\n![GitLab Pagesチュートリアル - ページのカスタマイズのためにファイルをアップロード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097724677.png)\n\n2. 画像を追加します。\n    - profile.png - 自分のプロフィール写真（64x64px）\n    - favicon.png - サイトのファビコン（32x32px）\n    - Og.png - SNSプレビュー用のOpenGraph画像（1200x630px）\n\n**動作を確認する**\n\nGitLabを使い慣れている場合は、[自分のリポジトリをフォーク](https://gitlab.com/fracazo/fracazo.gitlab.io)してすぐに作業を始めることができます。\n\n最終結果はこちらから確認できます。\n[https://fracazo.gitlab.io/](https://fracazo.gitlab.io/)\n\n**よくある問題と解決策**\n- GitLabでは、デフォルトでPagesプロジェクトの「一意のドメイン」が有効になっています。シンプルなGitLab提供のドメイン（`username.gitlab.io`など）を使用するには、**「デプロイ」>「ページ」**の順にアクセスし、「一意のドメインを使用」を無効にしてください。一意のドメインはアセットパスの処理などの面で技術的な利点がありますが、個人のウェブサイトの場合はよりシンプルなURL構造が好まれます。\n- パイプラインが失敗した場合、`.gitlab-ci.yml`ファイルで`master`ではなく、`main`を使用しているかどうかを確認してください。\n- GitLab Pagesが機能するには、グループとプロジェクトが公開に設定されている必要があります。\n- パイプラインでジョブが失敗した場合、ジョブログでエラーメッセージを確認して解決策を見つけましょう。\n\nGitLab Pagesとご紹介したテンプレートを使用すれば、すぐにビジネス用・個人用のウェブサイトを立ち上げることができます。このテンプレートはシンプルでレスポンシブ化されており、カスタマイズも簡単です。ご自身のキャリアの成長に合わせて、GitLabを使用して直接サイトを簡単に更新できます。\n\nGitLabのCI/CD機能を活用すれば、デプロイプロセスを自動化し、魅力的なコンテンツの作成に注力できます。\n\n一番のメリットは、これらすべてがGitLabのFreeプランで利用できるという点です。そのため、個人プロジェクト、ドキュメントサイト、または小規模なビジネスサイトを無料でホストする際に最適なオプションです。高度な機能と設定については、[Pagesのドキュメント](https://docs.gitlab.com/ee/user/project/pages/)をご覧ください。\n\n## GitLab Pagesの今後の取り組み\nGitLabでは、クリエイターやデベロッパーの皆さまのために、GitLab Pagesの改善に常に取り組んでいます。近日リリース予定の素晴らしい改善点をいくつかご紹介します。\n\n### ドメイン管理の簡素化\nGitLab Pagesでのドメインの管理が今まで以上に簡単になるアップデートが追加される予定です。新しいダッシュボードには、すべてのドメイン設定が1か所で簡単にアクセスできるように統合され、管理がよりスムーズになります。\n\nさらに、DNSやSSL証明書のステータスについてリアルタイムで最新情報を受け取れるようになるため、ドメインのセキュリティと安定性を維持しやすくなります。\n\n### カスタムドメインの設定\nガイドに従うだけで、簡単にカスタムドメインを設定できるようになります。詳しくガイドには、各手順の説明がわかりやすく記載されています。さらに、カスタムドメインを設定して、古いウェブサイトから新しいサイトへの訪問者の自動リダイレクトも行えるようになり、すべてのトラフィックを1つのメインサイトに集められるようになる予定です。カスタムドメインに関する詳細は、[こちら](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html#set-up-a-custom-domain)をご確認ください。\n\n> 今すぐ[GitLabのFreeプラン](https://about.gitlab.com/pricing/)でGitLab Pagesを使い始めましょう！\n\n## 関連リンク\n- [GitLab Pagesの機能：アプリレビューと複数のウェブサイトのデプロイ](https://about.gitlab.com/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment/)\n- [GitLab Pages：複数のウェブサイトのデプロイに関するドキュメント](https://docs.gitlab.com/user/project/pages/#parallel-deployments)\n- [GitLab Pagesを使用してホストしているウェブサイトの例](https://gitlab.com/pages)",[676,904],{"slug":1921,"featured":6,"template":681},"build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","content:ja-jp:blog:build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","Build A New Website In A Few Easy Steps With Gitlab Pages","ja-jp/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","ja-jp/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"_path":1927,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1928,"content":1934,"config":1938,"_id":1940,"_type":16,"title":1941,"_source":17,"_file":1942,"_stem":1943,"_extension":20},"/ja-jp/blog/what-is-ci-cd",{"title":1929,"description":1930,"ogTitle":1929,"ogDescription":1930,"noIndex":6,"ogImage":1931,"ogUrl":1932,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1932,"schema":1933},"CI/CDとは？意味や導入のメリット・デメリット、ツールの選び方を解説","この記事では、CI/CDの概要や導入するメリット、CI/CDツールの選び方などを詳しく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663328/Blog/Hero%20Images/cicd3.jpg","https://about.gitlab.com/blog/what-is-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CI/CDとは？意味や導入のメリット・デメリット、ツールの選び方を解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-03\",\n      }",{"title":1929,"description":1930,"authors":1935,"heroImage":1931,"date":1917,"body":1936,"category":672,"tags":1937},[738,696],"ソフトウェア開発においては、顧客に最大限の価値を提供するためにリリース後も繰り返し改善を行なっていくことが求められます。そのプロセスを効率化するために活用できるのが「CI/CD」です。\n\n実際に開発の効率化のための手段のひとつとしてCI/CDの採用を検討している担当者もいるのではないでしょうか。この記事では、CI/CDの概要や導入するメリット、CI/CDツールの選び方などを詳しく解説します。\n\n## CI/CDとは？\n![cicd1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687600/Blog/Content%20Images/cicd1.jpg)\n\nCI/CDとは、ソフトウェア開発におけるビルドやテスト、デプロイなど、従来であれば手作業で介入する必要があったプロセスを自動化して、素早くプロダクトをリリースする手法のことです。\n\n「Continuous Integration」と「Continuous Delivery」の略称であり、日本語で直訳すると「継続的インテグレーション／継続的デリバリー」となります。\n\n## CIとCDの違い\n\nでは、CIとCDではどのような違いがあるのかそれぞれ意味を解説していきます。\n\n### CI （継続的インテグレーション）\n\nCI （継続的インテグレーション）は、ソフトウェア開発において自動ビルドとテストを繰り返し実行することを示します。\n\n複数の開発者が修正したソースコードを頻繁に統合して、不具合がないか確認するためのプロセスです。このプロセスを繰り返し自動的に実行することで、プログラムのバグを早期に発見・改善でき開発を効率よく進められます。\n\n### CD（継続的デリバリー）\n\nCDとは、「継続的デリバリー」という言葉の通り、CIで検証されたソフトウェアを顧客に対して継続的に公開できる仕組みをつくることです。\n\nCIのプロセスにおいて自動ビルドやテストが実行された後に、ステージング環境やテスト環境などに成果物をデプロイし、さらにセキュリティテストや負荷テストなどを実施します。\n\n最終的な本番環境へのデプロイについては手動で承認する形で行い、ボタンをクリックするだけで反映することができます。\n\n### CD（継続的デプロイメント）\n\nCDには、継続的デリバリーの他にも「継続的デプロイメント」の意味もあります。継続的デプロイメントとは、全てのソースコードの変更が自動的に本番環境に反映される仕組みのことです。\n\n継続的デリバリーと継続的デプロイメントの違いは、手動で本番環境にリリースするか自動で行うかという点です。\n\n## CI/CDパイプラインとは？\n\nCI/CDパイプラインとは、ソースコードの変更からテスト、本番環境へのデプロイまでの一連の流れを自動化したプロセスを指します。つまり、CIとCDの両者を組み合わせた仕組みのことです。\n\nCI/CDパイプラインを構築することで、ソフトウェア開発における各工程の連携がスムーズになり、ビルドやテストの工数削減や迅速なリリースを実現できます。\n\n## CI/CDの導入が必要とされる背景とDevSecOps・アジャイル開発との関係性\n![cicd4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687600/Blog/Content%20Images/cicd4.jpg)\n\nCI/CDの導入がなぜソフトウェア開発の現場で必要とされているのでしょうか。CI/CDと[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)・アジャイル開発との関係性を踏まえながら解説します。\n\n### CI/CDが必要とされる背景\n\n現代は「Society 5.0時代」と呼ばれており、IT技術の発展と進化に伴い多様なシステムを活用して社会を豊かにするという考え方が重要視されています。ビジネスの場においてもテクノロジーの急激な進化に伴い、多くのサービスが生まれる中で企業間での競争が激化しています。\n\nそうした競争に打ち勝っていくためには、変化に柔軟かつ迅速に対応できる開発環境を構築しなければなりません。CI/CDなら一定の品質を維持したうえで開発プロセスを自動化でき、変化に対応しながら迅速にソフトウェアを顧客に届けることが可能です。\n\nこの品質とスピードの両方の課題を解決できるという強みが、ソフトウェア開発の領域においてCI/CDが注目されている理由だといえます。\n\n### DevSecOps・アジャイル開発との関係性\n\nCI/CDは、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)やアジャイル開発との相性が良い開発手法であり、これらの手法が主流となってきていることも注目される理由のひとつです。つまり、CI/CDは[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)とアジャイル開発を効果的に実現するための重要な要素として位置付けられています。\n\n例えば、アジャイル開発ではスピード感を持って機能をリリースしていくことが求められます。しかし、リリースを頻繁に繰り返すというプロセスは、毎回テストの実施などにおいて  \n開発者の負担が増大してしまうことを意味します。また、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)でいう「セキュリティのシフトレフト」という観点でも、コーディング直後にセキュリティスキャンを実施し、見つかったセキュリティ脆弱性を記憶が鮮明なうちに修正する、という先進的な取り組みにおいても、CI/CDは極めて重要な役割を担います。\n\nCI/CDを導入すれば開発プロセスを自動化できるため、アジャイル開発の強みを活かしながらコスト削減と品質の維持、安全なソフトウェア・サービス開発を実現することが可能です。\n\n## CI/CD導入のメリット\n![cicd2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687600/Blog/Content%20Images/cicd2.jpg)\n\n既に触れている内容でもありますが、改めてCI/CD導入のメリットについて把握しておきましょう。\n\n* 開発スピードを加速化できる  \n* 生産性と品質の向上が期待できる  \n* バグを早期に発見できる\n\n### 開発スピードを加速化できる\n\nCI/CDを導入することで、ソフトウェア開発からリリースまでの時間を短縮できます。\n\nソースコードを変更した後にはビルドやテスト、デプロイなどさまざまな工程を踏む必要があり、これらを全て手作業で行うとかなりの時間を要します。CI/CDなら手動での作業を自動化できるため、迅速に顧客のソフトウェアを提供することが可能です。\n\n### 生産性と品質の向上が期待できる\n\nCI/CDを導入すればテストからリリースまでの工程を自動化できるため、業務負担の削減につながります。これによって手動で作業していた分の時間をより重要なタスクに割くことが可能になり、生産性向上にも寄与するでしょう。\n\n例えば、プロダクトの品質向上に向けた施策立案や、顧客ニーズや市場の変化を踏まえた仕様変更や機能追加などの重要な業務に注力できるようになります。\n\n### バグを早期に発見できる\n\nCI/CD活用によってテスト工程が自動化されることから、頻繁にテストを実施できるようになります。先ほども触れたようにアジャイル開発の場合は頻繁にテストを繰り返す必要があるため、CI/CDの強みを活かすことでバグを早期に発見できます。\n\n早い段階でバグを発見してその都度修正を実施すれば、機能全体に影響を及ぼすような大きな不具合の発生を未然に防止することも可能です。\n\nまた、スピードを意識するあまりテストの実施が抜けてしまったという重大なミスの防止にもつながるでしょう。\n\n## CI/CD導入における考慮点と成功への鍵\n![cicd6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687600/Blog/Content%20Images/cicd6.jpg)\n\nCI/CDの導入を成功させるためには事前準備や継続的な改善を実施することが大切です。以下で詳しく解説します。\n\n### CI/CDパイプライン構築による開発基盤の強化を図る\n\nCI/CDを活用するためには、CI/CDパイプラインを構築して開発基盤の強化を図る必要があります。\n\n自動化の基準設定とテストコード作成を丁寧に行うことで、その後正しくCI/CDが機能し、ソフトウェア開発における長期的な品質向上の実現につながります。\n\n### 継続的な実施と改善で価値の最大化を実現する\n\nCI/CDの強みを最大限に活かすためには、アジャイル開発のように頻繁にテストとリリースを実施するような開発手法で活用することが大切です。ウォーターフォール開発の場合は、長期的な計画をベースとして開発が進められるため、CI/CDの使用頻度が少なく十分な効果を発揮できません。\n\nまた、CI/CDについては定期的な改善が必要です。例えば、ソフトウェアの変更によってテスト条件の修正を行う場合は、テストコードも書き直さなければなりません。「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」なら、CI/CDパイプラインの構築やメンテナンス、エラーの発見・分析を効率化できます。\n\n## CI/CDを導入する際のポイント\n\nCI/CDをスムーズに導入する際には以下のようなポイントを押さえておきましょう。\n\n* 必要なリソースを確保する  \n* メンバーに対する教育を行う\n\n### 必要なリソースを確保する\n\nCI/CDを導入する際には、予算や人材、工数の確保が求められます。自社の現状を把握してCI/CD導入にはどのくらいの予算が必要で、事前準備のためにどれだけの工数を必要とするのかを具体的に落とし込んでおくことが大切です。\n\nなお、CI/CDパイプラインの構築においては、DevOpsエンジニアやSREと呼ばれる人材のアサインが必要です。\n\n### メンバーに対する教育を行う\n\nCI/CDを導入して正しく運用していくためには、チームメンバー全体の理解が必要です。具体的には「自社でCI/CDを導入する目的や解決したい課題」「CI/CD関連でよく使用される用語」「CI/CDツールの使い方・運用ルール」などをメンバーに教育し、理解を深めてもらいます。\n\nしかし、チームメンバーに教育するには時間とコストが多くかかってしまい、その期間は利益を生み出していないことを意味します。「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」なら、AIによりソフトウェア開発のワークフロー全体を効率化できるため、人材の採用や教育コストの削減にもつなげられます。\n\n## CI/CDツールの選び方\n![cicd5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687600/Blog/Content%20Images/cicd5.jpg)\n\nCI/CDツールは以下の５つの観点を意識して選びましょう。\n\n* 機能  \n* 提供形態  \n* コスト  \n* セキュリティ  \n* サポート体制\n\n### 機能\n\nまずは、自社の開発プロジェクトに必要な機能が搭載されているか確認します。例えば、以下のような機能が搭載されたツールを選ぶと良いでしょう。\n\n* CI/CDパイプラインの構築やメンテナンス機能  \n* [API](https://about.gitlab.com/ja-jp/blog/what-is-an-api/)やプラグインなどの連携機能  \n* 優れた拡張機能 など\n\n### 提供形態\n\nCI/CDツールにおいては、クラウド型とオンプレミス型の提供形態があります。\n\nクラウド型はインターネット接続を通して提供元のツールを利用する方法で、サーバーを自社で管理する必要がなく手軽に導入できることがメリットです。ただし、カスタマイズ性は劣ります。\n\n一方、オンプレミス型は自社でサーバーを用意してツールを利用する方法です。オンプレミス型の場合は、カスタマイズ性が高く、インターネット上のセキュリティリスクが軽減できることから、特に機密性の高いデータを扱うビジネスや規制の強い業種にむいています。その反面、サーバー構築に手間がかかりますので、両者の特徴を把握したうえで自社にマッチした利用形態を選択しましょう。\n\n[GitLabでは、クラウド型とオンプレミス型の両方を提供しており、自社の置かれた状況に最適な構築が可能です](https://about.gitlab.com/ja-jp/pricing/)。\n\n### コスト\n\nCI/CDツールを導入する際には当然コストが発生するため、自社の予算と照らし合わせながら利用に必要なコストを確認します。\n\nその際、コストを抑えたいからといって自社に必要な機能が搭載されていないツールを導入しても効果は得られないため、機能面も考慮しながらチェックするのがポイントです。\n\nまた、いきなり開発環境を変えてしまうとリスクもあるため、まずは無料トライアルを受けられるツールを選定して使用感を確かめておきましょう。\n\n### セキュリティ\n\n近年企業においてもさまざまなセキュリティインシデントが発生しています。ソフトウェア開発におけるセキュリティリスクを軽減するためには、CI/CDツールが持つセキュリティスキャン等の機能もチェックしておきましょう。\n\n例えば、AI機能を搭載したツールならソースコードの脆弱性をより効率的に把握して修正できます。また、CI/CDツール製品そのものに、開発元からセキュリティパッチが迅速に提供されているかどうかもチェックしておきたいポイントです。\n\n### サポート体制\n\nCI/CDツールの導入や運用においてトラブルが発生する場合もあります。その際ツール提供側でサポート体制が提供されていると、早期の問題解決につながります。\n\nそのため、サポートプランの有無を確認し、窓口の対応時間や連絡方法をチェックしておきましょう。また、ユーザーコミュニティが活発化しているか、参考資料やドキュメントが充実しているかなども確認しておくと良いでしょう。\n\n## CI/CDツールなら「GitLab」\n\nCI/CDツールをお探しならぜひ「[GitLab](https://about.gitlab.com/ja-jp/)」をご検討下さい。CI/CDの機能を確保する際には、別々のツールを管理してそれらを統合することで実現しているケースがよく見られます。しかし、この構築方法ではツールの選定や準備にも手間がかかり、効率が良いとはいえません。\n\nAIを搭載したGitLabなら、単一の統合ツールとしてCI/CDパイプラインの効率化、セキュリティ対策、品質向上、運用コストの削減などを実現することができます。実際にさまざまな企業でGitLabが導入され、リリースサイクルの短縮に成功しています。\n\nまた、GitLabではクラウド型、オンプレミス型の両方を提供していますので、自社の環境に最適な方をお選びいただけます。無料トライアル版もご用意しているため、まずは使用感をお試しください。[サポート体制](https://about.gitlab.com/support/)や[参考ドキュメント](https://docs.gitlab.com/)も充実しているため、安心して運用いただけます。\n\n## CI/CDを導入して開発効率の向上を図ろう\n\nソフトウェアの開発においてCI/CDを導入することで、開発スピードや生産性向上などが期待できます。CI/CDを導入して自社のプロジェクトを成功させるためには、適切なCI/CDパイプライン構築と、継続的なメンテナンスを徹底する意識を持つことが大切です。\n\nCI/CDツールの選定においては、ぜひ「[GitLab](https://about.gitlab.com/ja-jp/)」をご検討下さい。GitLabならCI/CDの実現に必要な機能が搭載されているため、スムーズな導入を実現できます。\n\nGitLabによるCI/CDの事例はこちらからご覧下さい。\n\n> [CI/CDと堅牢なセキュリティスキャンがHilti社のSDLCを加速した方法](https://about.gitlab.com/ja-jp/customers/hilti/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo)\n\n\u003Cbr>\u003Cbr>\u003Cbr>\n\n*監修： ハシュカ アンドリュー /Andrew Haschka [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[110],{"slug":1939,"featured":92,"template":681},"what-is-ci-cd","content:ja-jp:blog:what-is-ci-cd.yml","What Is Ci Cd","ja-jp/blog/what-is-ci-cd.yml","ja-jp/blog/what-is-ci-cd",{"_path":1945,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1946,"content":1952,"config":1960,"_id":1962,"_type":16,"title":1963,"_source":17,"_file":1964,"_stem":1965,"_extension":20},"/ja-jp/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"title":1947,"description":1948,"ogTitle":1947,"ogDescription":1948,"noIndex":6,"ogImage":1949,"ogUrl":1950,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1950,"schema":1951},"GitLab Duo Self-Hosted：セキュリティ境界内で実現するエンタープライズ向けAI","GitLab Duo Self-Hostedを使用すれば、エンタープライズレベルのデータレジデンシーとプライバシーを維持しながら、生成AIの力を活用できます。セキュリティやガバナンスの要件が厳格でも、GitLab Duoをセルフマネージドのインフラ上に安全に導入できるようになりました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097840/Blog/Hero%20Images/Blog/Hero%20Images/Self-Hosted%201800x945_1dL1II2ITh2PteObA9DBLD_1750097839679.png","https://about.gitlab.com/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Self-Hosted：セキュリティ境界内で実現するエンタープライズ向けAI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"},{\"@type\":\"Person\",\"name\":\"Aathira Nair\"}],\n        \"datePublished\": \"2025-02-27\",\n      }",{"title":1947,"description":1948,"authors":1953,"heroImage":1949,"date":1956,"body":1957,"category":787,"tags":1958,"updatedDate":1959},[1954,1955],"Susie Bitters","Aathira Nair","2025-02-27","このたび、Gitab Duo Self-Hostedの一般提供を開始しました。この機能はGitLab Duoコード提案およびGitLab Duo Chatで利用可能です。これにより、組織はエンタープライズレベルの AI機能を活用しながら、データを自社のインフラ内で保持できるようになります。GitLab Duo Self-Hostedはオンプレミス、インターネット未接続（エアギャップ）環境、セキュアなクラウド設定に対応しており、 機密データや知的財産を厳重に管理しながら、チームが AI を活用して革新を促進できるよう支援します。\n\nセキュリティに関する懸念は、規制の厳しい業界でAIを導入する上で大きな障壁となっています。こちらの[グローバルDevSecOpsレポート](https://about.gitlab.com/ja-jp/developer-survey/2024/ai/)によると、回答者の半数以上が、ソフトウェア開発ライフサイクルにAIを組み込むことはリスクが伴うと答えています。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)により、組織がソフトウェア開発ライフサイクル全体でAIを活用し、より安全で迅速なソフトウェアデリバリーを実現できるようになります。\n\n17.9のリリースでは、厳格なデータプライバシー要件を持つ組織の特定のニーズに対応するためにGitLab Duo Self-Hostedの機能を拡張し、生成AIの大規模言語モデル（LLM）を含む柔軟なモデルデプロイメントが可能になりました。公共部門や規制の厳しい業界（金融サービス、自動車、医療）の組織は、AI を活用した開発ツールを自社の閉じた環境にシームレスに統合できるようになり、セキュリティチームは必要な制御を維持しながら、AIによる競争優位性を得ることができます。\n\nある米国政府機関は次のように述べています。\n「DevSecOpsプラットフォームの基盤としてGitLabを選定した後、ソフトウェアファクトリー機能をさらに強化するためにGitLab Duo Self-Hostedを採用することにしました。\nGitLab Duoはエアギャップ環境で利用でき、データに対して詳細な制御が可能なため、セキュアなAI機能の実現に不可欠でした。\nGitLab Duoの統一されたアプローチにより、ワークフローの効率化、セキュリティ強化、AI 活用による生産性向上を実現するとともに、厳格なコンプライアンス要件を満たすことができるようになりました」\n\n![GitLab Duo Self-Hosted モデル](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097848329.png)\n\n## セキュアなAI導入を設計\n\nGitLab Duo Self-Hostedは、Anthropic、Mistral、OpenAIなどの主要な生成AIモデルをサポート対象としており、GitLab Duoのユースケースやプロンプトライブラリに最適なパフォーマンスを発揮するモデルを選択できます。現在サポート対象となっているLLMは次のとおりです。\n\n* オンプレミス：vLLMサービングプラットフォームを使用したMistralモデル\n* AWS：AWS Bedrockを介したMistralおよびAnthropic Claude 3.5 Sonnet\n* Microsoft Azure：Azure AIを介したMistralおよびOpenAI GPTモデル\n\n今後サポート予定のモデルを評価中です。[サポートしているLLMについての詳細は、こちらをご覧ください。](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/)\n\nGitLab Duo Self-Hostedは、オープンソースのvLLMフレームワークを活用したオンプレミスインストールや、AWS BedrockやMicrosoft Azure AIなどのサービスを利用したプライベートクラウドデプロイメントを含む、多様なオプションをサポートしています。\nこの柔軟性により、組織は自社のセキュリティ、コンプライアンス、パフォーマンス要件に合わせた最適なAIソリューションを設計できます。\n\n## AI/MLの実装を簡単に\n\nAI抽象化レイヤーは、AI/MLテクノロジーの実装に必要なエンジニアリング作業を省き、選択した大規模言語モデル（LLM）への統合を標準化および簡素化します。\n企業は複数のツールを統合・維持する複雑さから解放され、AI導入プロセスを効率化するとともに、デベロッパーエクスペリエンスを向上させることができます。\n\n![GitLab Duo Self-Hosted AI機能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097848330.png)\n\n## データレジデンシー要件を満たす\n\nGitLabインスタンス、AIゲートウェイ、LLMを独自の環境や選択した国に分離することで、機密データや知的財産を指定された境界内に保持することができます。\nデータローカリティ（データが物理的に保存される場所）を細かく制御することにより、厳格なデータレジデンシー規制を遵守しつつ、エアギャップ環境などの安全な設定でAI機能を導入することが可能になります。\n外部APIへの依存をなくすことで、すべてのリクエストと応答のログに対して完全な可視性を確保でき透明性が向上します。公共部門の組織でも、最も厳格なコンプライアンス要件に準拠しながら AI機能を安全に導入できるようになります。\n\n**下の画像をクリックしてデモ（クリックスルー）をご覧ください。**\n\n[![GitLab Duo Self-Hosted tour screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-20_at_7.00.34_AM_aHR0cHM6_1750097848332.png)](https://gitlab.navattic.com/gitlab-duo-self-hosted)\n\n## GitLab Duo Self-Hostedの利用を開始する \n\n厳しいセキュリティやコンプライアンスの要件を満たしながらAI導入を進めていきたい場合は、[GitLab Duoのトライアルにご登録ください](https://about.gitlab.com/ja-jp/solutions/gitlab-duo-pro/sales/)。\n\n\u003Cbr>\u003Cbr>\u003Cbr>\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[721,678,904,701,700],"2025-02-28",{"slug":1961,"featured":92,"template":681},"gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy","content:ja-jp:blog:gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy.yml","Gitlab Duo Self Hosted Enterprise Ai Built For Data Privacy","ja-jp/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy.yml","ja-jp/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"_path":1967,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1968,"content":1974,"config":1980,"_id":1982,"_type":16,"title":1983,"_source":17,"_file":1984,"_stem":1985,"_extension":20},"/ja-jp/blog/the-ultimate-guide-to-token-management-at-gitlab",{"title":1969,"description":1970,"ogTitle":1969,"ogDescription":1970,"noIndex":6,"ogImage":1971,"ogUrl":1972,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1972,"schema":1973},"GitLabにおけるトークン管理の究極ガイド","ソフトウェア開発ライフサイクル全体のセキュリティを向上させるために、トークンを特定、管理、保護するためのエンドツーエンドのプロセスをすべてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-token-management-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabにおけるトークン管理の究極ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hakeem Abdul-Razak\"}],\n        \"datePublished\": \"2025-02-25\",\n      }",{"title":1969,"description":1970,"authors":1975,"heroImage":1971,"date":1977,"body":1978,"category":722,"tags":1979},[1976],"Hakeem Abdul-Razak","2025-02-25","深夜2時、成長中のテック企業でエンジニアとして働いているあなたに、緊急の電話がかかってきました。重要なデプロイパイプラインが失敗し、チームはその原因を突き止めようと必死です。数時間後、1週間前に退職したエンジニアのパーソナルアクセストークンが失効していたことが判明します。そのトークンは複数の重要な自動化プロセスで使用されており、その影響でシステム全体が混乱状態に陥ってしまいました。これを防ぐためには、どのようにトークンを管理すべきなのでしょうか？\n\n\nこのガイドでは、トークンを適切に特定、管理、保護するためのエンドツーエンドのプロセスをご紹介します。このガイドは、プロジェクト内でのトークン管理を徹底したいGitLabの管理者、デベロッパー、セキュリティチームに向けて、[トークンに関する詳しい文書](https://docs.gitlab.com/ee/security/tokens)を補う参考資料として活用いただけます。\n\n\nこのガイドでは、以下の内容を取り上げています。\n\n- [ジョブに適したトークンの選び方](#how-to-select-the-right-token-for-the-job)\n\n- [トークンの種類](#token-types)\n\n- [自分が使用しているトークンの把握方法](#discovering-your-tokens)\n    - [認証情報インベントリ](#credentials-inventory)\n- [GitLab UIおよびAPIでのトークン管理](#managing-tokens-in-the-gitlab-ui-and-api)\n\n- [トークンのローテーションと有効期限の管理](#token-rotation-and-expiration-management)\n\n- [トークン管理のベストプラクティス](#token-management-best-practices)\n    - [サービスアカウント](#service-accounts)\n\n## ジョブに適したトークンの選び方\n\n\nユースケースに合ったトークンを選ぶことで、セキュリティと機能性の両面で最適な運用が可能になります。\n\nトークンは、APIリクエストの認証、CI/CDパイプラインの自動化、サードパーティツールとの統合、デプロイやリポジトリの管理など、幅広い場面で活用できます。\n\n\n![トークン管理ガイド -\nトークンのフローチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097434869.png)\n\n\nわかりやすさを重視し、この図では1人のユーザーがトークンを所有するシンプルなユースケースを例にしています。詳細については、インスタンスまたはトップレベルグループの各[ネームスペース](https://docs.gitlab.com/ee/user/permissions.html)（ユーザー/グループ）におけるユーザーロールや権限に関するGitLabの文書をご参照ください。以下のようなユースケースが考えられます。\n\n\n- **パーソナルアクセストークン**（[PAT]\n(https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes)）：デベロッパーがユーザーの個人アクセスや権限を必要とする場合に使えるトークンです。このトークンは、ユーザーのステータスと権限に従って認証情報が管理されるため、ユーザーが特定のプロジェクトやグループへのアクセス権を失った場合や、アカウントが無効化された場合には、自動的にそのトークンも無効になります。\n\n-\n**プロジェクト/グループアクセストークン**（[PrAT](https://docs.gitlab.com/user/project/settings/project_access_tokens/#scopes-for-a-project-access-token)/[GrAT](https://docs.gitlab.com/user/group/settings/group_access_tokens/#scopes-for-a-group-access-token)）：特定のプロジェクトまたはグループ内でのリソースへのアクセスを制限する必要がある場合に適したトークンです。PrAT/GrATを持つユーザーは、割り当てられたスコープを通じてこれらのリソースにアクセスできるようになります。\n\n\n## トークンの種類\n\n\nこちらは、GitLabトークンの種類と、それぞれのデフォルトのプレフィックスおよびユースケースの一覧です。詳細については、[GitLabトークンの概要ページ](https://docs.gitlab.com/ee/security/tokens/#available-scopes)をご覧ください。\n\n\n| トークン | プレフィックス | 説明 |\n\n| :---: | :---: | :---: |\n\n| パーソナルアクセストークン | glpat | ユーザー固有のデータにアクセス |\n\n| OAuth 2.0トークン | gloas | OAuth2.0 認証プロトコルを使ったサードパーティアプリとの連携 |\n\n| なりすましトークン | glpat | 他のユーザーの代わりに管理操作を実行 |\n\n| プロジェクトアクセストークン | glpat | 特定のプロジェクトのデータにアクセス |\n\n| グループアクセストークン | glpat | 特定のグループのデータにアクセス |\n\n| デプロイトークン | gldt | ユーザー名とパスワードなしでプロジェクトのコンテナイメージをクローン、プッシュ、プル |\n\n| デプロイキー | 該当なし | リポジトリへの読み取り専用または読み書きアクセスを許可 |\n\n| Runner認証トークン | glrt | GitLab Runnerを認証 |\n\n| CI/CDジョブトークン | glcbt | CI/CDプロセスを自動化 |\n\n|トリガートークン| glptt | パイプラインを手動またはプログラムでトリガー |\n\n| フィードトークン | glft | パッケージ/RSSフィードへのアクセス認証 |\n\n| 受信メールトークン | glimt | 受信メールの処理 |\n\n| Kubernetes向けGitLabエージェントトークン | glagent |\nGitLabGitLabエージェントを通じてKubernetesクラスターを管理 |\n\n| SCIMトークン | glsoat | SCIMを利用したユーザー管理の統合 |\n\n| 機能フラグクライアントトークン | glffct | プログラムで機能フラグを有効化 |\n\n| Webhookトークン | 該当なし | WebhookのリクエストがGitLabから送信されたことを検証するための秘密トークン（ユーザーが設定）\n|\n\n\n## トークンの確認方法\n\n\n### 認証情報インベントリ\n\n\nGitLab Ultimateでは、GitLab\nSelf-Managedの管理者や、GitLab.com（バージョン17.5以降）における企業組織のトップレベルグループのオーナーが、自身のネームスペース内の認証情報を監視できます。\n\n\nこのインベントリでは、以下のようなトークン情報を確認できます。\n\n\n* トークンの種類\n  * [GitLab.com](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)で利用可能なトークン\n  * [GitLab Self-Managed](https://docs.gitlab.com/ee/administration/credentials_inventory.html)で利用可能なトークン\n* 関連付けられたユーザーアカウント \n\n* トークンのスコープ、および作成日と有効期限 \n\n* 最終使用時のIPアドレス（GitLab 17.10時点）\n\n* 上記のユーザー定義パラメータに基づくトークンのフィルタリング\n\n* トークンの取り消しおよびローテーションの機能\n\n\n認証情報インベントリを適切に管理することで、権限が過剰なトークンの特定や、ローテーションが必要な認証情報の把握が可能になり、安全かつ効率的な運用が実現します。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/A9ONfnwswd0?si=4VIEUgJaD4daj81b&start=105\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n#### 認証情報インベントリAPI\n\n\nUIの機能に加えて、新しい/group/:id/manage[エンドポイント](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project)を通じて認証情報インベントリAPIをリリースするための[開発が進行中](https://gitlab.com/groups/gitlab-org/-/epics/16343)です。このエンドポイントでアクセスできる認証情報は企業[ユーザー](https://docs.gitlab.com/ee/user/enterprise_user/)に限定されており、企業組織のトップレベルグループのオーナーが利用可能です。将来のAPIコールの例は以下のとおりです。\n\n\n```console\n\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\"\n\"https://verified_domain.com/api/v4/groups/\u003Cgroup_id>/manage/personal_access_tokens\"           \n\n```\n\n### GitLab API\n\n\nGitLab\nAPIを使用すると、組織内のトークンをプログラムで一覧表示および管理できます。主要な認証関連エンドポイントは、個人用、グループ用、CI/CDトークンなど、[さまざまなトークンの種類](https://docs.gitlab.com/ee/api/rest/authentication.html)をサポートしています。GitLab上で認証済みユーザーがアクセスできるすべてのプロジェクトを一覧表示する際のパーソナルアクセストークンの使用方法は次のとおりです。\n\n\n```console\n\ncurl --header \"PRIVATE-TOKEN: \u003Cyour_access_token>\" \\\n     \"https://gitlab.example.com/api/v4/projects\"\n\n```\n\n\nGitLab APIへのAPIコールの方法については、次の動画をご覧ください。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0LsMC3ZiXkA?si=vj871YH610jwQdFc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n### トークンの使用場所の確認\n\n\nトークンの使用場所を確認する方法は以下のとおりです。\n\n* **ユーザープロフィール >\n[アクセストークン](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)**\n\n* 認証情報インベントリ\n\n* 監査イベント\n\n* API経由\n\n\nトークンの使用状況に関する情報は、**last_used**は10分ごと、**last_used_ip**は1分ごとに更新されます。\n\n\nIPアドレスの確認機能はGitLab\n17.9で追加され、**:pat_ip**機能フラグにより管理されます。[トークンの最終使用時間](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)と、そのトークンが使われた最後の5つの異なるIPアドレスを表示する方法は以下のとおりです。\n\n\n![トークン管理ガイド -\nパーソナルアクセストークンの設定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097434870.png)\n\n\n## GitLab UIとAPIにおけるトークンの管理\n\n以下の表には、UIにおけるトークン作成の詳細と、APIを介したトークンの使用方法を示すビデオが含まれています。\n\n\n| トークン | GitLab UI | GitLab API |\n\n| ---------- | ---------- | ---------- |\n\n| パーソナルアクセストークン |\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=3)\n|\n[ドキュメント](https://docs.gitlab.com/ee/api/personal_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=43)\n|\n\n| グループアクセストークン |\n[ドキュメント](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=120)\n|\n[ドキュメント](https://docs.gitlab.com/ee/api/group_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=157)\n|\n\n| プロジェクトアクセストークン |\n[ドキュメント](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=254)\n|\n[ドキュメント](https://docs.gitlab.com/ee/api/project_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=285)\n|\n\n\n## トークンのローテーションと有効期限の管理\n\n\nトークンローテーションと厳格な有効期限管理を実施することで、セキュリティリスクを減らし、セキュリティ基準への準拠を確保できます。定期的なローテーションと有効期限の強制により、期限切れの認証情報がセキュリティの脆弱性となるのを防ぎます。\n\n\nこれまで、グループおよびプロジェクトのアクセストークンは、有効期限が切れると自動的に削除されていました。そのため、無効なトークンの記録が残らず、監査やセキュリティレビューを行う上で課題となっていました。この問題に対応するため、[最近のアップデート](https://gitlab.com/gitlab-org/gitlab/-/issues/462217)により、無効化されたグループおよびプロジェクトのアクセストークンの記録が、無効になってからUI上に30日間保持されるようになりました。これにより、トークンの使用状況や有効期限、取り消しの履歴を追跡しやすくなり、コンプライアンスやモニタリングの強化につながります。\n\n\nトークンのローテーションと有効期限の管理をより積極的に行うには、次の手順を実行します。\n\n\n*\nUIまたはAPIを介してトークンを積極的にローテーションする。APIを使用する場合は、[自動的にトークンの再利用を検知](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection)するセキュリティ機能に注意が必要です。\n\n*\nインスタンス全体で、[アクセストークンの最大有効期間](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens)を制限する設定を導入。\n\n\n### トークンローテーションAPI\n\n\nGitLab\n17.7までは、アクセストークンのローテーションはAPIを通じてプログラム上で行う必要がありましたが、現在はUI上でも実行可能になりました。操作方法は以下の表の動画または[ドキュメント](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui)をご確認ください。\n\n\n### トークンローテーションスニペット\n\n\n以下の表には、GitLabトークンのローテーションに関する動画のリンクをまとめています。\n\n\n| トークン | 前提条件 | GitLab UI | GitLab API |\n\n| :---: | :---: | ----- | ----- |\n\n| パーソナルアクセストークン | スコープ：api  |\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=76) \n|\n[ドキュメント](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token)\nと[動画](https://youtu.be/v5Nj3Jy4vaI?t=92)  |\n\n| グループアクセストークン | スコープ：apiと役割：オーナー |\n[ドキュメント](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=203) \n|\n[ドキュメント](https://docs.gitlab.com/ee/api/group_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=214) \n|\n\n| プロジェクトアクセストークン | スコープ：apiと役割：オーナー、メンテナー |\n[ドキュメント](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=335) \n|\n[ドキュメント](https://docs.gitlab.com/ee/api/project_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=349) \n|\n\n\n## トークン管理のベストプラクティス\n\n\n### 最小権限の原則\n\n\n各トークンに割り当てる権限を、それぞれのタスクに必要な最小限に制限することで、リスクを軽減します。これにより、システム内の潜在的な障害箇所を事前に予測・対処しやすくなります。以下のような方法で、この原則を実践できます。\n\n\n* それぞれのジョブに合った適切なトークンを選ぶ。フローチャートを参照。\n\n*\nトークンの作成時に必要なスコープのみを割り当てる。たとえば、監査目的のようなジョブには読み取り専用のスコープを使用します。詳細は[ロール](https://docs.gitlab.com/ee/user/permissions.html#roles)を参照。\n\n* 特別な理由がない限り、管理者権限を付与しない。\n\n*\nインスタンス全体でのデフォルトのトークン[有効期限](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1)を設定する。\n\n* トークンの権限を定期的に確認・監査し、運用実態に合っているか見直す。\n\n* タスク完了後は速やかにトークンを無効化する。\n\n\n### サービスアカウント\n\n\n[サービスアカウント](https://docs.gitlab.com/ee/user/profile/service_accounts.html)を使用することで、トークンを人間のユーザーではなく非人間エンティティに紐づけることができ、特定ユーザーへの依存を減らせます。自動化にトークンを使う場合、個人アカウントではなく、スコープを制限したサービスアカウントを作成することが推奨されます。サービスアカウントを使用する主なメリットは次のとおりです。\n\n\n* CI/CDパイプラインでサービスアカウントのトークンを使うことで、ユーザーアカウントの変更による中断を防げる\n\n* 個人アカウントに影響を与えずに、プログラム上でトークンのローテーション処理を自動化できる\n\n* サービスアカウントによる操作のモニタリング・監査がより明確になる \n\n*\n[有効期限のない](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date)サービスアカウントを作成できる\n\n*\n[ライセンスシート](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account)を消費しない\n\nGitLabでは、サービスアカウントとそのトークンの管理をより簡単にするために、[APIベースでの作成](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user)に対応する新しい[サービスアカウントUI](https://gitlab.com/groups/gitlab-org/-/epics/9965)の提供を予定しています。以下のデモでは、サービスアカウントをプログラム上で使用する方法を紹介しています。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oZvjg0SCsqY?si=cj-0LjfeonLGXv9u\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n### 脆弱性ツール\n\n\nGitLabに組み込まれたセキュリティツールを活用することで、トークンの使用に関連する脆弱性を特定し、リスクを軽減できます。最大限のカバレッジを得るには、各ツールを併用することを推奨します。\n\n\n*\n[シークレット検出](https://docs.gitlab.com/ee/user/application_security/secret_detection/)：リポジトリ内にハードコードされたシークレット（APIトークン、パスワード、その他の機密情報）がないかをスキャンします。[検出されたシークレットの一覧](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html)も確認可能です。\n\n*\n[静的アプリケーションセキュリティテスト（SAST）](https://docs.gitlab.com/ee/user/application_security/sast/)：ソースコードに存在するセキュリティ上の脆弱性を分析し、[マージリクエスト内でUI上のレポートとして表示](https://docs.gitlab.com/ee/user/application_security/sast/#features)するなどの機能を提供します。\n\n*\n[依存関係スキャン](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)：プロジェクトで使用しているサードパーティライブラリに、トークンに関連する脆弱性が含まれていないかを確認します\n\n\n### 監査ログとモニタリング\n\n\nインスタンスまたはグループ単位で、監査ログとトークンの使用状況を定期的に確認することで、トークンの健全性を維持できます。\n\n\n*\n[監査イベント](https://docs.gitlab.com/ee/user/compliance/audit_events.html)：GitLabの監査イベントログを有効にすると、トークンの作成、使用、削除、不審なAPIコール（ログ内の許可されていないパラメーターやレートリミッターの継続的なトリガーなど）を追跡できます。\n\n*\n[IP許可リスト](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions)：悪意のあるユーザーが複数のIPアドレスを使ってアクティビティを隠すことを防ぎます。\n\n*\n[アラート](https://docs.gitlab.com/ee/operations/incident_management/alerts.html)：不審なアクティビティに対してアラートを設定できます（オンコールローテーションに関するページングのトリガーやインシデントの作成に活用可能）。\n\n*\n[認証情報インベントリ](https://docs.gitlab.com/ee/administration/credentials_inventory.html)：利用可能なすべてのアクセストークンを完全に管理し、必要に応じて取り消すことができます。\n\n*\n[通知](https://docs.gitlab.com/ee/user/profile/notifications.html)：グループ、プロジェクト、パーソナルの各種トークンについて、有効期限が近づいた際に送信される通知メールを積極的に処理します。お客様からのご要望に応え、この通知機能は従来の7日前に加え、30日前、60日前の通知にも対応しました。\n\n*\n[Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook)：アクセストークンのWebhookをグループとプロジェクトに設定して、トークンの有効期限7日前の通知イベントを送信できるようになりました。この機能も最近、**:extended_expiry_webhook_execution_setting**機能\nフラグ（デフォルトでは無効）によって、30日、60日前の通知送信に対応しました。\n\n\n## 今後の展開\n\n\nGitLabでは多くの種類のトークンを提供しており、今後はそれらを統合しつつ、トークンの有効期間や細かなスコープ設定、一貫した管理・運用に重点を置いた改善を進めていく[予定](https://gitlab.com/gitlab-org/gitlab/-/issues/502630)です。現在注力しているトークン関連の機能には、サービスアカウント用の完全なUI、認証情報インベントリへの追加認証情報タイプの対応、トークンおよびサービスアカウントの監査強化などが含まれます。\n\n\n> トークン管理機能を体験するには、[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)にぜひご登録ください。\n",[676,722,904,678,701],{"slug":1981,"featured":92,"template":681},"the-ultimate-guide-to-token-management-at-gitlab","content:ja-jp:blog:the-ultimate-guide-to-token-management-at-gitlab.yml","The Ultimate Guide To Token Management At Gitlab","ja-jp/blog/the-ultimate-guide-to-token-management-at-gitlab.yml","ja-jp/blog/the-ultimate-guide-to-token-management-at-gitlab",{"_path":1987,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1988,"content":1994,"config":2000,"_id":2002,"_type":16,"title":2003,"_source":17,"_file":2004,"_stem":2005,"_extension":20},"/ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"title":1989,"description":1990,"ogTitle":1989,"ogDescription":1990,"noIndex":6,"ogImage":1991,"ogUrl":1992,"ogSiteName":1223,"ogType":1244,"canonicalUrls":1992,"schema":1993},"GitLab Duo Workflow：自律型AIに対するエンタープライズレベルの可視性と管理","安全で自律的かつコンテキストを理解できるAIエージェントに複雑なタスクを任せることで、デベロッパーは革新的なソフトウェアの迅速なリリースに専念できます。現在、限定公開のベータ版のウェイトリスト受付中です。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660174/Blog/Hero%20Images/Workflow_1800x945.png","https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Workflow：自律型AIに対するエンタープライズレベルの可視性と管理\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pini Wietchner\"}],\n        \"datePublished\": \"2025-02-24\",\n      }",{"title":1989,"description":1990,"authors":1995,"heroImage":1991,"date":1997,"body":1998,"category":787,"tags":1999,"updatedDate":1956},[1996],"Pini Wietchner","2025-02-24","このたび、[GitLab Duo Workflowの限定公開ベータ版](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)の利用登録（ウェイトリスト）の受付を開始しました。GitLab Duo Workflowは、最も包括的なDevSecOpsプラットフォーム上に構築された自律型AIです。GitLabのAIロードマップにおける次のステップとして、GitLab Duo Workflowは、プロジェクトの立ち上げからデプロイプロセス、デバッグ対応からチーム間の調整まで、あらゆる開発業務をIDE内で進行できるようサポートします。\n\nGitLab Duo Workflowは、コラボレーション、継続的インテグレーション、継続的デプロイメント、セキュリティ、コンプライアンスに特化したGitLabプラットフォームの枠組みを活かし、組織がAIエージェントを使用して開発プロセスを加速できるよう支援します。\n\nGitLab Duo Workflowを活用すると、次のような作業を効率化できます。\n\n* 新規開発プロジェクトの立ち上げ\n* コードのモダナイズ\n* コンテキストを考慮したタスクの実行\n* ドキュメントの作成\n* テストカバレッジの強化\n* その他\n\nこれらはあくまで基本的な活用例です。GitLabの統合データストアにより、GitLabを使えば使うほど、GitLab Duo Workflowはコード、設定、セキュリティ検出結果、デプロイ手法をより深く理解するようになります。結果として、組織に最適化された強力な開発プロセスが実現します。\n\n## AIエージェントの展望と課題\n\nソフトウェアは世界を大きく変えてきましたが、現在、ソフトウェア開発のスキルを持つ人材は、世界人口のごく一部にすぎません。それでも、こうした人材が生み出した技術は、スマートフォンやインターネットを通じて何十億人もの人々に届けられています。より多くの人々が本番環境レベルのソフトウェアを構築し、安全に運用し、提供できる世界を想像してみてください。そうなれば、何十億もの人々に影響を与えるソフトウェアが次々と生まれ、かつてない規模のイノベーションが巻き起こるでしょう。__自律型AIがそれを実現します。__\n\nAIエージェントはコンテキストを理解し、コードベース全体の知識を保持しており、開発、セキュリティ、オペレーションにまたがる複雑なソフトウェアプロジェクトを積極的にサポートできる高度な能力を備えています。AIエージェントを活用すれば、デベロッパーはこれまで個人やチームでは想像もできなかった規模でソフトウェアを開発できるようになります。\n\nしかしこの変化は、可視性、制御、AIがデベロッパーの業務にどのような影響を与えるかについて新たな懸念をもたらします。組織は、AIがデベロッパーの能力を強化しつつ、開発プロセスに対する適切な監視を維持する必要があります。このバランスの実現が、今日のソフトウェア開発における重大な課題です。単にAIを導入するだけでなく、セキュリティ、コンプライアンス、ガバナンスを維持しながらデベロッパーの能力を引き出す形でAIを導入することが成功の鍵と言えるでしょう。\n\n## AI導入を成功させるアプローチ：アドオンツールの追加ではなく包括的なプラットフォーム上にAIを構築\n\nより多くのデベロッパーが関与し、コードや潜在的なセキュリティリスクが増加するような環境に対し、新しい課題ごとに個別のツールを追加していくと、複雑さが増すだけです。最新の[DevSecOps調査で](https://about.gitlab.com/the-source/platform/devops-teams-want-to-shake-off-diy-toolchains-a-platform-is-the-answer/)、この問題の深刻さが明らかになりました。DevSecOpsチームは最大14種類のツールを使用せざるを得ない状況に陥り、最大80%の時間をコーディング以外のタスクに費やしています。AIが効果的に機能するためには、高品質で統一されたデータが必要ですが、個別のツールを追加し続けるアプローチでは、分散したデータを統合することが非常に困難になります。GitLab DevSecOpsプラットフォームとGitLab AIエージェントを組み合わせることで、ソースコード、マージリクエスト、エピック、ユーザー、アクセス権など、すべての要素を単一のデータモデルに統合します。当社が構築中のエージェントは、ユーザーとプロジェクトに関するコンテキストを使用して、チームの働き方を標準化し、セキュリティ問題のスキャンやコンプライアンス規則の適用など、デベロッパーの時間を奪ってしまうコーディング以外のタスクを自動化します。AIがプラットフォームに直接組み込まれることで、これらの機能がさらに強力になります。AIエージェントを開発パートナーとして活用しながら、AIがプロセスを強化する方法をユーザーがコントロールできるようにし、AIの効果とガバナンスのバランスを取ります。\n\n__これは遠い未来の話ではありません。GitLab Duo Workflowで現在構築中のものです。__\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1059060959?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo Workflow, the future of secure agentic AI software development\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>`\n\n## GitLab Duo Workflow： 最も包括的なDevSecOpsプラットフォーム上のAIエージェント\n\nGitLabのエンドツーエンドのDevSecOpsプラットフォームを活用したGitLab Duo Workflowは、デベロッパーが最大限の可能性を発揮できるように支援します。AIコードアシスタントが個々のコードを支援する一方で、GitLab Duo Workflowは開発ライフサイクル全体を理解してルーチンタスクを自動化します。これにより、デベロッパーは戦略的イノベーションとクリエイティブな問題解決に集中できます。GitLab Duo Workflowの開発が進むにつれ、チームは以下のことを実現できるようになります。\n\n### プロジェクトの立ち上げをスムーズに\n\nデベロッパーは、新しいプロジェクトのセットアップや依存関係の管理、基本的なインフラストラクチャの構築に追われ、本来の機能開発に充てる貴重な時間が削られがちです。GitLab Duo Workflowを使用すると、**IDE内で直接プロジェクトの立ち上げを自動化**できます。最初から適切な設定が適用されるため、より早くイノベーションの創出に専念できます。\n\n### レガシーコードから最新のアプリケーションへ\n\nレガシーコードのモダナイズは、単に構文を更新するだけではありません。依存関係、テスト、CI/CDパイプライン、ドキュメントを理解する必要があります。GitLab Duo Workflowは、コードからテストまでの**コードリファクタリングを実行することでコードベースのモダナイズ**を効率化します。\n\n### 頭の切り替えが必要な状態からフロー状態へ\n普段、デベロッパーは、ツール、ドキュメント、コードベースを常に切り替えながら問題を解決しています。GitLab Duo Workflowがコードベース関連のイシューやマージリクエストの完全なコンテキストを提供してくれるため、デベロッパーは切り替えなしで必要な情報にアクセスでき、開発に集中したフロー状態を維持できます。\n\n### ドキュメントを動的な知識へ\n\nドキュメントが最新の状態に追いつかないことで、コードベースの理解と保守が困難になります。GitLab Duo WorkflowがREADMEファイル、コードフロー図、アーキテクチャドキュメントなどのドキュメントの生成と更新をサポートするため、__ドキュメントが常に最新の状態を保ち__「動的な知識」として機能するようになります。\n\n### 断片的なテストから包括的なテストへ\n\nコードベースが拡大するにつれて、すべての機能や変更に対する包括的なテストというのが難しくなります。GitLab Duo Workflowは、既存のテストインフラストラクチャと統合しながら、AIを活用して __コードベースの広範囲に対するテストを自動的に生成できる__ ため、より少ない労力でより信頼性の高いソフトウェアを開発できます。\n\n## 限定公開ベータ版の利用を登録する\n\n[GitLab Duo Workflowの限定公開ベータ版の利用にご登録](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)ください。プロジェクトのセットアップからデプロイまで、当社のセキュアな自律型AIに関するビジョンにおける次のステップをご確認いただけます。これらのエージェントは、GitLabのDevSecOpsプラットフォーム上に構築されており、組織が必要とするエンタープライズレベルのセキュリティと制御を保持しながら、ソフトウェアライフサイクル全体を理解する高度な機能を提供します。\n\n*免責事項：このページには、今後予定されている製品、機能および機能性に関する情報が含まれています。この情報は情報提供のみを目的としたものであり、購入や計画の判断材料として使用することはお控えください。すべての項目は変更や未更新の可能性があります。開発、リリース、およびタイミングについては、予告なく内容を変更または削除する場合があります。*",[904,721,678,701,700,677],{"slug":2001,"featured":92,"template":681},"gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai","content:ja-jp:blog:gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai.yml","Gitlab Duo Workflow Enterprise Visibility And Control For Agentic Ai","ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai.yml","ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"_path":2007,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2008,"content":2014,"config":2020,"_id":2022,"_type":16,"title":2023,"_source":17,"_file":2024,"_stem":2025,"_extension":20},"/ja-jp/blog/gitlab-17-9-release",{"title":2009,"description":2010,"ogTitle":2009,"ogDescription":2010,"noIndex":6,"ogImage":2011,"ogUrl":2012,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2012,"schema":2013},"GitLab 17.9リリース","GitLab 17.9でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662202/Blog/Hero%20Images/product-gl17-blog-release-cover-17-9-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-9-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.9リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-02-20\",\n      }",{"title":2009,"description":2010,"authors":2015,"heroImage":2011,"date":2016,"body":2017,"category":701,"tags":2018,"updatedDate":2019},[738],"2025-02-20","**GitLab 17.9がリリースされ、生成AIの大規模言語モデル（LLM)を閉じた環境にデプロイ可能になったGitLab Duoの一般提供を開始しました**\n\nこのたび、GitLab 17.9のリリースを発表しました。このリリースでは、生成AIの大規模言語モデル(LLM)を閉じた環境にデプロイ可能になったGitLab Duoの一般提供、複数のGitLab Pagesサイトを並列デプロイで実行できる機能、VS CodeやJetBrains IDEでGitLab Duo Chatにプロジェクトファイルを取り込んでより深い解釈を可能にするオプション、古くなったパイプラインの自動削除など、さまざまな機能が追加されました。  \nこれらの機能は、今回のリリースに含まれる110件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。  \n\nGitLab 17.9には、GitLabコミュニティのユーザーから322件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、17.10リリースのキックオフビデオも視聴できる今後のリリースページをご覧ください。\n\n> [GitLab 17.9では、生成AIの大規模言語モデル（LLM)を閉じた環境にデプロイ可能になったGitLab Duoの一般提供を開始しました。クリックしてSNSで共有しましょう](https://x.com/intent/post?text=GitLab+17.9%E3%81%A7%E3%81%AF%E3%80%81%E7%94%9F%E6%88%90AI%E3%81%AE%E5%A4%A7%E8%A6%8F%E6%A8%A1%E8%A8%80%E8%AA%9E%E3%83%A2%E3%83%87%E3%83%AB%EF%BC%88LLM%29%E3%82%92%E9%96%89%E3%81%98%E3%81%9F%E7%92%B0%E5%A2%83%E3%81%AE%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9FGit+Lab+Duo%E3%81%AE%E4%B8%80%E8%88%AC%E6%8F%90%E4%BE%9B%E3%82%92%E9%96%8B%E5%A7%8B%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82&url=https%3A%2F%2Fabout.gitlab.com%2Fja-jp%2Fblog%2F2025%2F02%2F20%2Fgitlab-17-9-release%2F)\n\n## 今月の[MVP](https://about.gitlab.com/community/mvp/)は[Salihu Dickson](https://gitlab.com/salihudickson)さんが受賞\n\nMVPには、誰もが[GitLabコミュニティのコントリビューターをMVPに推薦できます](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)。現在の候補者を応援したり、他の誰かをノミネートしてみませんか🙌\n\n今回、コミュニティから200件以上の反響を集めた待望の[Wikiページへのコメント機能](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/171764)の開発を実装した、[Salihu Dickson](https://gitlab.com/salihudickson)さんの素晴らしい貢献を称え、MVPとして表彰できることを嬉しく思います！\n\n\u003Cbr>\n\u003Cbr>\n\u003Cbr>\n\n## GitLab 17.9でリリースされた主な改善点\n\n### セルフホストモデルが可能になったGitLab Duoの一般提供を開始\n\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\nこれにより、選択した大規模言語モデル（LLM）を自社のインフラストでホストし、それを GitLab Duo のコード提案やチャットのソースとして設定できるようになりました。この機能は、GitLab Ultimate \\+ Duo Enterpriseライセンスを持つセルフホスト型GitLabで一般提供が開始されました。\n\nセルフホストモデルが可能になったGitLab Duoを使用することで、オンプレミスまたはプライベートクラウドにホストされたモデルを GitLab Duo Chat やコード提案のソースとして利用できます。現在、Mistralモデル（vLLM または AWS Bedrock上でのオープンソース型モデル）、AWS BedrockのClaude 3.5 Sonnet、Azure OpenAIのOpenAIモデルをサポートしています。セルフホストモデルを活用することで、生成AIの力を最大限活かしながら、外部サービスに依存することなくデータ主権とプライバシーを確保できます。\n\nイシュー[512753](https://gitlab.com/gitlab-org/gitlab/-/issues/512753)から、ぜひフィードバックをお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/gitlab_duo_self_hosted/)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/517102)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/SH-UI.png\">\n\n### 複数のGitLab Pagesサイトを並列デプロイで実行可能に\n\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\n並列デプロイを使用して、複数のバージョンのGitLab Pagesサイトを同時に作成できるようになりました。各デプロイには、指定したプレフィックスに基づいて一意のURLが設定されます。たとえば、独自ドメインを指定した場合は`project-123456.gitlab.io/prefix`から、独自ドメインを指定しない場合は`namespace.gitlab.io/project/prefix`からサイトにアクセスできます。\n\nこの機能は、特に以下のような場合に役立ちます。\n\n- デザインの変更やコンテンツの更新をプレビューする  \n- 開発中のサイトの変更内容をテストする  \n- マージリクエストによる変更内容を確認する  \n- 複数のサイトのバージョンを保守する（ローカライズされたコンテンツなど）\n\nデフォルトでは、並列デプロイは24時間後に自動的に失効します。過去のデプロイが蓄積するのを防ぎ、効率的にストレージを管理できます。ただし、有効期間をカスタマイズしたり、デプロイが失効されないように設定したりすることが可能です。マージリクエストから作成された並列デプロイは、マージリクエストがマージされた、または完了したタイミングで削除（自動クリーンアップ）されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/pages/#parallel-deployments)\u003Cbr>\n\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14434)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/pages_pd_ga.png\">\n\n### VS CodeやJetBrains IDEでGitLab Duo Chatにプロジェクトファイルの追加が可能に\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\u003Cbr>\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nプロジェクトファイルをVS CodeやJetBrainsのGitLab Duo Chatに直接追加して、より強力でコンテキストに対応したAIアシストを利用できるようになりました。\n\nGitLab Duo Chatにプロジェクトファイルを追加することで、Duo Chatは特定のコードベースをより深く理解し、コンテキストに沿った正確な回答を提供できるようになります。このようなコンテキストアウェアネス（状況や背景を理解する能力）により、より適切なGitLab Duoコードの説明、デバッグに関する的確なサポート、既存のコードベースに密接に沿った提案が提供されます。この素晴らしい新機能に関するフィードバックをお待ちしています。ぜひ[フィードバック](https://gitlab.com/gitlab-org/gitlab/-/issues/492443)イシューからご意見をお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#ask-about-specific-files) \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15183)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/ycBgDBaUS9M?si=M1nflRQ0CFbFu0YA\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### Sysboxを用いたワークスペースコンテナのサポート\n\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nGitLabワークスペースにおいて、開発環境でコンテナのビルドと実行を直接行えるようになりました。[Sysboxを使用して](https://docs.gitlab.com/ee/user/workspace/configuration.html#with-sysbox)設定されたKubernetesクラスター上でワークスペースを実行している場合、追加の設定なしでコンテナのビルドと実行が可能です。\n\nこの機能はGitLab 17.4で[sudoアクセス機能](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/#secure-sudo-access-for-workspaces)の一部として提供されており、GitLabワークスペース環境で完全なコンテナワークフローを維持できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/workspace/configuration.html#build-and-run-containers-in-a-workspace)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/452464)\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/ycBgDBaUS9M?si=t4o-ONBzWEgb5oL1\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### カスタムdevfileなしでワークスペースが作成可能に\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nこれまでは、ワークスペースを設定する際に、`devfile.yaml`設定ファイルを作成する必要がありました。本リリースから、GitLabでは一般的な開発ツールを含むデフォルトファイルが提供されるようになりました。この機能強化により、次のことが可能になります。\n\n- 設定の手間がかからなくなる  \n- どのプロジェクトからでも素早くワークスペースを作成できる  \n- 一般的な開発ツールが事前に設定されており、すぐに利用可能  \n- 設定に時間をかけずに、開発に集中できる\n\n追加設定や設定手順の手間を省いて、すぐにワークスペースを作成して開発を始めることができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/workspace/#gitlab-default-devfile)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14644)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/default_devfile.png\">\n\n### GitLab管理の[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソース\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\n[GitLab管理のKubernetesリソース](https://docs.gitlab.com/ee/user/clusters/agent/kubernetes_managed_resources.html)を活用すれば、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)へのアプリケーションのデプロイプロセスの自動化が進み、きめ細かい制御も可能になります。これまでは、環境ごとに手動で[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソースを設定する必要がありましたが、本リリースではGitLab管理の[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソースを使用して、リソースを自動的にプロビジョニングして管理できるようになりました。\n\nGitLab管理の[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソースを使用すると、次のことを行えます。\n\n- 新しい環境のネームスペースとサービスアカウントを自動的に作成する  \n- ロールバインディングによってアクセス権限を管理する  \n- ほかに必要な[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソースを設定する\n\nデベロッパーがアプリケーションをデプロイすると、GitLabは用意されたリソーステンプレートに基づいて必要な[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソースを自動的に作成します。これにより、デプロイプロセスが効率化されるほか、環境間の一貫性が保たれます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/managed_kubernetes_resources.html)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16130)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/deploy-gitlabmanaged-kubernetes-resources.png\">\n\n### より簡単にプロジェクト環境内のデプロイ情報にアクセスできるように\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまでプロジェクト内のデプロイの概要を把握するのに苦労したことはありませんか？本リリースでは、各環境をいちいち展開しなくても、環境リストで最近のデプロイの詳細を閲覧できるようになりました。環境リストには、各環境における最新の成功したデプロイが表示されます。成功したデプロイがない場合は、試行された最新のデプロイが表示されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/)  \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/505770)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/deploy-surface-deployment-information-to-the-environment-list-view.png\">\n\n### Wikiページのコメント\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n本リリースからWikiページに直接コメントを追加できるようになりました。本来ドキュメントは静的なものですが、本機能を活用することでドキュメントを意見交換を伴う共同作業の場として使えるようになります。\n\nWikiページのコメントやスレッドは、チームが次のことを行うのに役立ちます:\n\n- コンテンツに沿ってドキュメント上で直接議論する\n- 改善点や修正案を提案する\n- ドキュメントを正確かつ最新の状態に保つ\n- 経験や専門知識を共有する\n\nWikiコメントを活用することで、ドキュメントが単なる記録ではなく、プロジェクトの進行に合わせて進化する「生きたドキュメント」になります。チームは、直接的なフィードバックや意見交換を通じて内容をリアルタイムで更新し続けることができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/discussions/)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14062)\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/Qnc8jXIqMqw?si=yse1OJsbNM0O4TCL\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### ワークフローの可視性の強化：マージリクエストのレビュー時間に関する新たなインサイト\n\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\n開発ワークフローの追跡を改善するために、[バリューストリーム分析](https://about.gitlab.com/solutions/value-stream-management/)（VSA）に新しいイベント「*Merge request last approved at*（*マージリクエストが最後に承認されたタイミング）*」が追加されました。[マージリクエストの承認](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)イベントは、レビュー段階の終了と、最終的なパイプラインの実行またはマージステージの開始を記録します。たとえば、マージリクエストの総レビュー時間を計算するには、VSAステージを作成して、開始イベントとして「*Merge request reviewer first assigned（マージリクエストのレビュアーが最初にアサイン）*」を、また終了イベントとして「*Merge request last approved at （マージリクエストが最後に承認されたタイミング）*」を指定します。\n\nこの機能強化により、チームはレビュー時間に関するインサイトを得ることができ、レビューを最適化しやすくなります。、結果として、開発全体のサイクルタイムが短縮され、そしてソフトウェアデリバリーをより迅速に行えるようになります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#value-stream-stage-events) \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/503754)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/17_9_vsa_last_approved.png\">\n\n### 脆弱性リスクの優先順位付けに役立つEPSS、KEV、およびCVSS（共通脆弱性評価システム）データ\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\n本リリースで、次の脆弱性リスクデータのサポートを追加しました。\n\n- 悪用予測スコアリングシステム（EPSS）  \n- 悪用されている既知の脆弱性（KEV）  \n- 共通脆弱性識別子（CVE）\n\nこれらのデータを使用して、依存関係やコンテナイメージにおける脆弱性のリスクを効率的に優先順位付けできるようになりました。このデータは、脆弱性レポートおよび脆弱性の詳細ページで確認できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/risk_assessment_data.html)\u003Cbr>  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11544)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/srm_epss_cvss_kev.png\">\n\n### UIからDASTスキャンの詳細設定が可能に\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\n複雑なアプリケーションを効果的にテストするには、セキュリティチームがDASTスキャンを柔軟に設定できる必要があります。これまでは、UIからDASTスキャンを設定する際に利用できる設定オプションが限られていたため、特定のセキュリティ要件が求められるアプリケーションではスキャンがうまく行えないことがありました。そのため、簡単なセキュリティ評価を行う場合でも、パイプラインベースのスキャンを使用する必要がありました。\n\n本リリースから、UIからDASTスキャンを設定する際にも、パイプラインベースのスキャンの利用時と同様の詳細な設定が、可能になりました。これには以下が含まれます。\n\n- カスタムヘッダーやクッキーを含む完全な認証設定  \n- 最大ページ数、最大深度、除外URLなどの正確なクロール設定  \n- 高度なスキャンのタイムアウトと再試行  \n- クロールするリンクの最大件数やDocument Objet Model（DOM）の深度など、カスタムスキャナーの動作  \n- 特定の脆弱性タイプを対象としたスキャンモード\n\nこれらの設定を再利用可能なプロファイルとして保存することで、複数のアプリケーション間で一貫したセキュリティテストを行えます。すべての変更は監査イベントによって追跡されるため、スキャン設定が追加、編集、削除されたタイミングを把握できます。\n\nこのような制御の強化により、詳細な監査証跡を使用してコンプライアンスに準拠したより効果的なセキュリティスキャンを実行できます。パイプライン設定の管理に時間がかからないため、アプリケーションごとに適切なスキャンを素早く実行し、脆弱性を迅速に発見して修正できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dast/on-demand_scan.html)\u003Cbr>  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/16057)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/dast_parity.png\">\n\n### CI/CDパイプラインの自動クリーンアップ\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまでは、古くなったCI/CDパイプラインを削除する場合、API経由で行う必要がありました。\n\nGitLab 17.9では、CI/CDパイプラインの有効期限を設定できるプロジェクト設定が導入され、指定した保持期間よりも古いパイプラインと関連するアーティファクトは自動的に削除されるようになりました。数多くのパイプラインを実行し、大きなアーティファクトを作成するプロジェクトはディスク使用量を圧迫する原因になりますが、この機能により不要なパイプラインやアーティファクトが自動で削除されるため、、ディスク使用量が抑えられ、さらに全体的なパフォーマンスの向上にもつながります。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/pipelines/settings.html#automatic-pipeline-cleanup)\u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/338480)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/verify_auto_pipeline_cleanup.png\">\n\n## GitLab 17.9のリリースに含まれるその他の改善点\n\n### REST APIでグループからプロジェクトのインテグレーションを管理\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまで、グループからプロジェクトのインテグレーションを管理する際は、GitLab UIから行う必要がありました。本リリースでは、REST APIを使用してこれらのインテグレーションを管理できるようになりました。\n\nこの場を借りて、[最初にコミュニティにコントリビュート](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148283)してくれた[Van](https://gitlab.com/van.m.anderson)さんに感謝します。Vanさんのコントリビュート後、GitLabが引き継いで実装しました。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/group_integrations.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/328496)\n\n### GitLab Pagesへのアクセスをグループレベルで制御\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab Pagesへのアクセスをグループレベルで制限できるようになりました。グループオーナーは、この設定を有効にするだけで、グループとそのサブグループ内のすべてのGitLab Pagesサイトをプロジェクトメンバーのみに限定公開できます。この一元管理により、個々のプロジェクト設定を変更しなくて済むため、セキュリティ管理が簡素化されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/pages/pages_access_control.html#restrict-pages-access-to-project-members-for-the-group-and-its-subgroups)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/254962)\n\n### 作業アイテム用GraphQL APIにクエリフィルターを追加\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n作業アイテム用のGraphQL APIに新たなクエリフィルターが追加され、次の条件で絞り込めるようになりました。\n\n- 作成日、更新日、完了日、期日\n- ヘルスステータス\n- ウェイト\n\nこれらの新しいフィルターを使用することで、APIを介して作業アイテムをクエリおよび整理する際に、より細かい制御が可能になります。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/513308)\n\n### GitLab Runner 17.9\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n本日、GitLab Runner 17.9もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドのエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\n新機能:\n- [Runnerオートスケーラーインスタンス用のヘルスチェックを追加](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38271)\n- [Runner準備段階の所要時間をヒストグラムメトリクスとして追加](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37471)\n- [Kubernetesエグゼキューターでサービスコンテナに任意の名前を付けられるように](https://gitlab.com/gitlab-org/gitlab/-/issues/421131)\n\nバグ修正:\n- [GitLab RunnerがS3 Express One Zoneからキャッシュを取得できない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38484)\n- [Kubernetes上のGitLab RunnerがAWS Spotインスタンスに対して「runner_system_failure」ではなく「script_failure」と報告する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37911)\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/17-9-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner/) \n\n### GitLabとKubernetesとの統合に関する入門ガイド\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n本リリースでは、新しい[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)入門ガイドを追加しました。このガイドでは、GitLabとFluxCDを使用してアプリケーションを直接[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)にデプロイする方法を説明しています。これらのチュートリアルはわかりやく、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)に関する深い知識がなくても完了できます。そのため、初心者でも経験豊富なユーザーでもGitLabと[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)を統合する方法を理解していただけます。\n\nまた、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)入門ガイドには、内容を補完するために、GitLabを[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)環境に統合する際の一連の推奨事項も含めました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/getting_started)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/505216)\n\n### Cargo、Conda、Cocoapods、SwiftプロジェクトでSBOMを用いた依存関係スキャンを有効にする\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nGitLab 17.9のリリースに伴い、コンポジション解析チームがSBOM（ソフトウェア部品表）を用いた依存関係スキャンへの移行を開始します。この移行には、新たな依存関係スキャンアナライザーが導入されます。このアナライザーはGemnasiumに代わるものです。Gemnasiumはバージョン18.0でサポートを終了しますが、GitLab 19.0までは引き続き使用可能です。\n\nSBOMを活用した依存関係スキャンのアプローチにより、対応言語の拡充、GitLabプラットフォーム内の統合強化とユーザーエクスペリエンスの向上、および業界標準のレポート形式（SBOMベースのスキャンとレポート）への移行という点で、お客様をより適切にサポートできるようになります。GitLab 17.9の時点で、新しい依存関係スキャンアナライザーは次のプロジェクトおよびファイル形式の場合、`latest`の依存関係スキャンCI/CDテンプレート（`Dependency-Scanning.latest.gitlab-ci.yml`）で、デフォルトで有効になります。\\* `conda-lock.yml`ファイルでCondaを使用しているC/C++/Fortran/Go/Python/Rプロジェクト\\* `podfile.lock`ファイルでCocoapodsを使用しているObjective-Cプロジェクト\\* `cargo.lock`ファイルでCargoを使用しているRustプロジェクト\\* `package.resolved`ファイルでSwiftを使用しているSwiftプロジェクト\n\nこの変更に伴い、新しいCI/CD変数として`DS_ENFORCE_NEW_ANALYZER`（デフォルトでは`false`）が導入されます。\n\nこの方法によって、`latest`テンプレートを使用しているすべての既存ユーザーは、デフォルトでGemnasiumアナライザーを引き続き利用でき、上記のファイル形式では新しい依存関係スキャンアナライザーが自動的に有効になります。\n\n新しい依存関係スキャンへの移行を希望する既存ユーザーは、（プロジェクト、グループ、またはインスタンスレベルで）`DS_ENFORCE_NEW_ANALYZER`を`true`に設定してください。この変更の詳細については、[非推奨化のお知らせ](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=18.0#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner)と関連する[移行ガイド](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/migration_guide_to_sbom_based_scans.html)をご参照ください。\n\n新しい依存関係スキャンアナライザーを一切使用したくない場合は、CI/CD変数`DS_EXCLUDED_ANALYZERS`を`dependency-scanning`に設定する必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/dependency_scanning_sbom/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/519597)\n\n### マルチコアAdvanced SASTがより高速なスキャンを提供\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nAdvanced SAST で、パフォーマンス向上のためのオプトイン機能としてマルチコアスキャンが利用できるようになりました。これにより、特に大規模なコードベースでは、スキャン時間が大幅に短縮されます。\n\nこの機能を有効にするには、CI/CD 変数`SAST_SCANNER_ALLOWED_CLI_OPTS`を `--multi-core N`に設定してください。`N`は使用したいコア数です。この変数は`gitlab-advanced-sast`ジョブにのみ設定し、他のジョブには設定しないでください。適切な値の選択方法については、[ドキュメント](https://docs.gitlab.com/user/application_security/sast/#security-scanner-configuration)で重要なガイダンスを確認してください。\n\nこのパフォーマンス向上をデフォルトで有効にする作業を進めています。これは[イシュー517409](https://gitlab.com/gitlab-org/gitlab/-/issues/517409) で追跡されています。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/sast/#security-scanner-configuration)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/514156)\n\n### プロジェクトの依存関係リストでコンポーネントによるフィルタリングが可能に\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nプロジェクトの依存関係リストで、コンポーネントフィルターを使用してパッケージ名でフィルタリングできるようになりました。\n\nこれまで、プロジェクトレベルの依存関係リストでは、パッケージを検索することができませんでした。コンポーネントフィルターを設定すれば、指定した文字列を含むパッケージを見つけられるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_list/#filter-dependency-list)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16490)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/srm_dependency_list_project_filter_by_component.png\">\n\n### 脆弱性レポートで識別子によるフィルタリング\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nプロジェクトの脆弱性レポートにおいて、脆弱性識別子を使用して結果をフィルタリングできるようになりました。これにより、プロジェクトやグループに潜む特定の脆弱性（CVEやCWEなど）を見つけられます。識別子は、別のフィルター（重大度、状態、ツールなど）と組み合わせて使用できます。脆弱性識別子フィルターは、脆弱性の数が20,000件を超えるレポートには適用できません。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#filtering-vulnerabilities)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13340)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/srm_filter_by_vulnerability_identifier.png\">\n\n### パイプライン実行ポリシーでマージリクエスト変数をサポート\n\nSaaS: Ultimate\u003Cbr> \nSelf-Managed: Ultimate\n\nパイプライン実行ポリシーで新しいマージリクエスト変数がサポートされるようになり、マージリクエスト関連の情報を考慮した、これまでよりも洗練されたポリシーを作成できるようになりました。CI/CDの適用をより的確かつ効率的に管理できるようになります。以下の変数がサポートされました。\n\n* `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA`  \n* `CI_MERGE_REQUEST_TARGET_BRANCH_SHA`  \n* `CI_MERGE_REQUEST_DIFF_BASE_SHA`\n\nこの機能拡張により、次のことが可能になります。\n\n- ソースブランチとターゲットブランチ間の変更点を比較する高度なセキュリティスキャンを実装し、徹底したコードレビューと脆弱性検出を実現する。\n\n- 各マージリクエストの詳細に基づいて適応する動的な構成のパイプラインを作成し、開発プロセスを効率化する。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html)  \n[エピック](https://gitlab.com/gitlab-org/gitlab/-/issues/512916)\n\n### ローテーション対象のサービスアカウントにカスタムの有効期限を設定\n\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nサービスアカウントのアクセストークンをローテーションする際に、expires\\_at属性を使用してカスタムの有効期限を設定できるようになりました。これまで、トークンは、ローテーションしてから7日後に自動的に失効していました。これにより、トークンの有効期限をよりきめ細かく管理できるようになり、安全にアクセス制御を継続して行う機能が強化されました。  \n\n[ドキュメント](https://docs.gitlab.com/ee/api/group_service_accounts.html#rotate-a-personal-access-token-for-a-service-account-user)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/505671)\n\n### カスタムロールの新しい権限\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nカスタムロールの作成時に、[コンプライアンスダッシュボードの読み取り権限](https://gitlab.com/gitlab-org/gitlab/-/issues/465324)を指定できるようになりました。カスタムロールを使用すると、ユーザーに対して、タスクの完了に必要な特定の権限のみを付与できます。これにより、グループのニーズに合わせてロールを定義できるため、オーナーまたはメンテナーロールが必要なユーザー数を減らせます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/custom_roles.html)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14746)\n\n### `Self_rotate`スコープを使ってアクセストークンをローテーションする\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n`self_rotate`スコープを使用して、アクセストークンをローテーションできるようになりました。このスコープは、パーソナルアクセストークン、プロジェクトアクセストークン、グループアクセストークンで使用できます。これまでは、新しいトークンの取得、そしてトークンのローテーションの実行というように、2つのリクエストを行う必要がありました。\n\nこの場を借りて、コントリビュートしてくれた[Stéphane Talbot](https://gitlab.com/stalb)さんと[Anthony Juckel](https://gitlab.com/ajuckel)さんに感謝します！  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-token-scopes)  \n [イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/430748)\n\n### 複数のOIDCプロバイダーの使用時に追加のグループメンバーシップをサポート\n\nSaaS: -\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\n複数のOIDCプロバイダーを使用している場合に、追加のグループメンバーシップを設定できるようになりました。これまでは、複数のOIDCプロバイダーを設定している場合でも、単一のグループメンバーシップしか設定できませんでした。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/auth/oidc.html#configure-multiple-openid-connect-providers)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/408248)\n\n### アクセストークンのIPアドレスを表示\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまでパーソナルアクセストークンの表示画面では、何分前にトークンが使用されたかという情報しか確認できませんでした。本リリースでは、トークンが使用された直近7件のIPアドレスも表示されるようになりました。このように情報がまとめて表示されることで、トークンがどこで使用されているかを追跡しやすくなります。\n\nこの場を借りて、コントリビュートしてくれた[Jayce Martin](https://jrm2k.us/)さん、[Avinash Koganti](http://www.linkedin.com/in/avinash-koganti-38b511162)さん、[Austin Dixon](https://austindixon.net/)さん、[Rohit Kala](https://www.linkedin.com/in/rohit-kala-1b891a179)さんに感謝します！  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used) \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/428577)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/govern_accesstoken_ip.png\">\n\n### AIエージェントとユーザーの両方のアイデンティ情報に基づいたより安全なアクセス管理\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまで、GitLabへのリクエストは単一のユーザーとしてのみ認証されていましたが、新しい「複合アイデンティティ」機能を使用することで、リクエストをサービスアカウントとユーザーの両方で同時に認証できるようになりました。AIエージェントのユースケースでは、システム内でタスクを実行したユーザーに基づいた権限が必要とされる一方で、そのユーザーとは異なる独自のアイデンティティを保持することが求められます。複合アイデンティティは、AIエージェントのアイデンティティを表す新しいアイデンティティプリンシパルであり、エージェントにアクションをリクエストした人間ユーザーのアイデンティティと関連付けられます。AIエージェントがリソースにアクセスしようとすると、複合アイデンティティトークンが使用されます。このトークンはサービスアカウントに紐づき、同時にエージェントを指示した人間ユーザーにもリンクされています。トークンに対する認可チェックは、リソースへのアクセスを許可する前に両方のアイデンティティを確認します。両方のアイデンティティがリソースにアクセスする権限を持っていない場合、アクセスは拒否されます。この新機能は、GitLab内でのリソース保護を強化するものです。サービスアカウントの複合アイデンティティの使用方法についての詳細は、[ドキュメント](https://docs.gitlab.com/development/ai_features/composite_identity/)をご確認ください。\n\n[ドキュメント](https://docs.gitlab.com/development/ai_features/composite_identity/)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/506641)\n\n### 作業アイテムタイプを変更\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n作業アイテムタイプを簡単に変更できるようになりました。これにより、より効率的かつ柔軟にプロジェクトを管理できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/tasks.html#convert-a-task-into-another-item-type)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/385131)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/change_work_item_type_to_another.png\">\n\n### 送信したフォームに子アイテムを直接追加\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\n複数の子アイテムを作成する際に、フォームが送信後も開いたままになるよう改善しました。余分なクリックなしで複数のエントリを簡単に追加できるようになったため、時間の節約につながるほか、タスク管理のワークフローもよりスムーズになります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#multi-level-child-epics)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/497767)\n\n### ワークスペース拡張機能でProposed APIをサポート\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nワークスペース拡張機能でProposed APIの有効化がサポートされ、本番環境での互換性と信頼性が向上しました。このアップデートによって、Python Debuggerなどの重要な開発ツールを含め、Proposed APIを利用する拡張機能がエラーなしに動作するようになりました。安定性を維持しながらAPIアクセスの拡大を実現させた改善と言えます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/workspace/#extension-marketplace)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/514741)\n\n### 証明書ベースのKubernetesクラスターの特定および移行\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n証明書ベースの[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)インテグレーションは、全ユーザーを対象に、2025年5月6日午前9時（UTC）から2025年5月8日午後10時（UTC）までの間にGitLab.comで無効化されます。さらに、GitLab 19.0でGitLab Self-Managedインスタンスから削除される予定です（2026年5月を予定）。\n\nユーザーの移行を支援するために、新たなクラスターAPIエンドポイントを追加しました。これにより、グループオーナーは、グループ、サブグループ、プロジェクトに登録されている[証明書ベースクラスター](https://docs.gitlab.com/ee/api/cluster_discovery.html)をクエリできるようになります。また、[移行に関するドキュメント](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html)を更新し、さまざまなユースケースに対応した移行手順を追加しました。\n\nGitLab.comのユーザーのみなさまは、影響の有無を確認した上で、早めに移行計画を立てることが推奨されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/cluster_discovery.html)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/512420)\n\n### FluxCD CI/CDコンポーネントを使用してOCIベースでGitOpsを実装\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\n[FluxCDコンポーネント](https://gitlab.com/components/fluxcd/)を使用することで、GitOpsのベストプラクティスを簡単に実現できます。FluxCDコンポーネントを使用して[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)マニフェストをOCIイメージとしてパッケージ化し、OCI互換のコンテナレジストリに保存できます。さらに、オプションとして、これらのイメージに署名し、FluxCDによる即時のリコンシリエーション（同期）をトリガーすることも可能です。\n\n[ドキュメント](https://gitlab.com/components/fluxcd/)\u003Cbr> \n[イシュー](https://gitlab.com/gitlab-org/ci-cd/deploy-stage/environments-group/experiments/fluxcd-ci-cd-component/-/issues/1)\n\n### Swiftパッケージのライセンススキャンをサポート\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nGitLab 17.9では、Swiftパッケージのライセンススキャンのサポートが追加されました。これにより、プロジェクト内でSwiftを使用しているユーザーは、Swiftパッケージのライセンスをより詳しく把握できるようになります。\n\nこのデータは、依存関係リスト、SBOMレポート、およびGraphQL APIを介して、コンポジション解析ユーザーが利用できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/index.html)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/506730)\n\n### 適用中のセキュリティポリシープロジェクトの削除をブロック\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nセキュリティポリシーを安全に管理し、有効化・適用されているポリシーの中断を防ぐために、運用中のセキュリティポリシープロジェクトの削除を防ぐ保護機能を追加しました。\n\nグループまたはプロジェクトにリンクされているセキュリティポリシープロジェクトを削除する場合は、まずはリンクを削除する必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/)  \n[エピック](https://gitlab.com/gitlab-org/gitlab/-/issues/482967)\n\n### パイプライン実行ポリシーでカスタムステージを適用\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nパイプライン実行ポリシーの新機能として、CI/CDパイプラインにおいて`Inject`モードで**カスタムステージ**を適用できるようになりました。この機能を使用すると、セキュリティとコンプライアンス要件を遵守しながら、パイプライン構造をより柔軟に制御し、次のことを実現できます。\n\n- **パイプラインのカスタマイズの強化**：カスタムステージを定義してパイプラインの特定の箇所に挿入することで、ジョブの実行順序をよりきめ細かく制御できます。  \n- **セキュリティとコンプライアンスの向上**：パイプラインにおいて最適なタイミング（例：ビルド後かつデプロイ前）で、セキュリティスキャンとコンプライアンスチェックが実行されるように指定できます。  \n- **柔軟なポリシー管理**：ポリシーを一元管理しながら、開発チームが定義されたガードレール内でパイプラインを自由にカスタマイズできます。  \n- **シームレスな統合**：カスタムステージは、既存のプロジェクトステージやその他のポリシータイプと連携するため、CI/CDワークフローを中断することなく強化できます。\n\n**仕組み**\n\n新たに改良されたパイプライン実行ポリシー用の`inject_policy`を使用すると、ポリシー設定でカスタムステージを定義できます。定義されたカスタムステージは、有向非巡回グラフ（DAG）アルゴリズムを使用してプロジェクトの既存のステージ間の依存関係を効率的管理した上で自動的にマージされるため、適切な順序が設定され、競合が回避されます。\n\nたとえば、ビルドステージとデプロイステージの間にカスタムセキュリティスキャンステージを簡単に挿入できます。\n\n`inject_policy`ステージは、非推奨となる`inject_ci`に代わるものです。`inject_policy`モードを選択することで、より効果的にポリシーを管理、適用できるようになります。ポリシーエディターで`Inject`を使用してポリシーの設定を行った場合、デフォルトで`inject_policy`モードが設定されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html#inject_policy)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/475152)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/custom-stages-yaml.png\">\n\n### マージリクエスト承認ポリシーでカスタムロールをサポート\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nマージリクエスト承認ポリシーに、承認者としてカスタムロールを割り当てられるようになりました。\n\nこれにより、組織のチーム構成や職務に応じた承認要件を設定でき、適切な担当者がポリシーに基づいてレビュープロセスに関与するよう調整可能になります。たとえば、セキュリティレビューにはアプリケーションセキュリティ（AppSec）エンジニアリングロールによる承認が、ライセンス承認にはコンプライアンスロールによる承認が必要と設定できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html#require_approval-action-type)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13550)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/custom-roles.png\">\n\n### プロジェクトのコンプライアンスセンターを使用してコンプライアンスフレームワークを適用\n\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nGitLab 17.2では、グループオーナーがグループのコンプライアンスセンターを使用して、グループ内のすべてのプロジェクトにコンプライアンスフレームワークを適用および削除する機能をリリースしました。\n\n本リリースではこの機能がさらに強化され、グループオーナーがプロジェクトレベルでもコンプライアンスフレームワークを適用および削除できるようになりました。これにより、グループオーナーによるプロジェクトレベルでのコンプライアンスフレームワークの適用およびモニタリングが容易になります。\n\nコンプライアンスフレームワークをプロジェクトレベルで適用および削除する機能は、グループオーナーのみが利用可能で、プロジェクトオーナーは利用できません。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html)  \u003Cbr>\n[エピック](https://gitlab.com/gitlab-org/gitlab/-/issues/507986)\n\n### サービスアカウントに関するメール通知\n\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nサービスアカウントのメール通知の送信先として、カスタムメールアドレスを設定できるようになりました。サービスアカウントの作成時にカスタムメールアドレスを指定すると、そのメールアドレス宛にGitLabから通知が送信されます。サービスアカウントごとに一意のメールアドレスを用いる必要があります。これにより、プロセスやイベントをより効果的にモニタリングできます。\n\nこの場を借りて、コントリビュートしてくれた[SNCF Connect & Techチーム](https://www.sncf-connect-tech.fr/)の[Gilles Dehaudt](https://gitlab.com/tonton1728)さん、[Étienne Girondel](https://gitlab.com/lenaing)さん、[Kevin Caborderie](https://gitlab.com/Densett)さん、[Geoffrey McQuat](https://gitlab.com/gmcquat)さん、[Raphaël Bihore](https://gitlab.com/rbihore)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/service_accounts.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/428750)\n\n### OAuthアプリケーション認証の監査イベント\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nこれまで、ユーザーがOAuthアプリケーションを認証しても、その行為を記録する監査イベントは生成されませんでした。しかし、特定のGitLabインスタンス上でユーザーが認証したOAuthアプリケーションに対し、セキュリティチームが監視、追跡を行うことは重要です。\n\n本リリースでは、「**ユーザーがOAuthアプリケーションを認証した**」ことを記録する監査イベントが追加され、GitLabインスタンスの監査機能がさらに強化されました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/audit_event_types.html#authorization)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/514152)\n\n### 認証情報インベントリでの検索およびフィルタリング\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\n認証情報インベントリで検索とフィルター機能を使用できるようになりました。これにより、ある期間内に有効期限が切れるトークンなど、ユーザー定義パラメーターに当てはまるトークンやキーを簡単に特定できます。これまで認証情報インベントリのエントリは静的リストとして表示されていました。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/credentials_inventory.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/345734)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/filter_search_credentials.png\">\n\n### APIを使用して、個々のエンタープライズユーザーの2FAを無効にする\n\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: -\n\nAPIを使用して、個々のエンタープライズユーザーの2要素認証（2FA）登録を一括で消去できるようになりました。これまではUIでのみ行えましたが、APIを使用することで、自動化や一括操作が可能になり、2FAの大規模なリセットが必要な場合に時間を節約できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/group_enterprise_users.html#disable-two-factor-authentication-for-an-enterprise-user)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/383319)\n\n### 無効なプロジェクトアクセストークンとグループアクセストークンを表示\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nUIで無効なグループアクセストークンとプロジェクトアクセストークンを表示できるようになりました。これまでGitLabでは、期限切れまたは失効済みとなったプロジェクトアクセストークンやグループアクセストークンはすぐに削除されていました。無効になったトークンの記録が存在しないため、監査やセキュリティレビューが困難になっていました。本リリースから、無効なグループアクセストークンとプロジェクトアクセストークンの記録が30日間保持されるようになりました。これにより、コンプライアンス対応やモニタリングを目的とした、トークンの使用状況と有効期限の追跡が容易になります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#revoke-or-rotate-a-project-access-token)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/462217)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/govern_expired_tokens_list.png\">\n\n### グループ共有の可視性を強化\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab全体でグループ共有の可視性が向上しました。これまではグループの概要ページで共有プロジェクトを閲覧できたものの、そのグループがどのグループに招待されているかまでは確認できませんでした。本リリースでは、グループの概要ページに**共有プロジェクト**と**共有グループ**の両方のタブが表示され、組織全体でどのようにグループがつながり、共有されているかを完全に把握できるようになりました。これにより、組織全体におけるグループアクセスの監査および管理が容易になります。\n\nこの変更に関するフィードバックがございましたら、ぜひ[エピック16777](https://gitlab.com/groups/gitlab-org/-/epics/16777)にご投稿ください。  \n\n[ドキュメント](https://docs.gitlab.com/user/project/members/sharing_projects_groups/#view-shared-groups)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/378629)\n\u003Cimg src=\"https://about.gitlab.com/images/17_9/group_overview_shared_groups.png\">\n\n### ユーザーによるプロフィールの非公開化を制限\n\nSaaS: -\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\nユーザーは自分のプロフィールを公開するか非公開にするかを選択できます。本リリースより、管理者は、GitLabインスタンス全体でユーザーがプロフィールを非公開にできるかどうかを制御できるようになりました。管理者エリアにある「ユーザーがプロフィールを非公開にすることを許可」という設定で、このオプションを管理できます。デフォルトではこの設定は有効になっており、ユーザーはプロフィールを非公開にできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.md#prevent-users-from-making-their-profiles-private) \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/421310)\n\n\u003Cbr>\n\u003Cbr>\n\n## 実験的な機能\n\n### ジョブトークンの詳細な権限設定\n\nジョブトークンは、パイプライン内でリソースにアクセスするための一時的な認証情報です。ジョブトークンはユーザーの権限を継承するため、通常は広範なアクセス権限を持っています。[ジョブトークンの詳細な権限設定](https://docs.gitlab.com/ee/ci/jobs/fine_grained_permissions.html)により、ジョブトークンがプロジェクト内のどのリソースにアクセスできるかを制御できます。\n\nこの機能に関するフィードバックをお待ちしています。ご質問やコメントがある場合、またはGitLabチームとのやり取りをご希望の場合は、[こちらのフィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/519575)をご覧ください。\n\n\u003Cbr>\n\u003Cbr>\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabでは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームをご利用のすべての人に、スムーズでシームレスな体験をお届けすることを約束します。\n\n以下のリンクをクリックして、17.9のバグ修正、パフォーマンスの強化、UIの改善についてすべてご覧ください。\n\n* [バグ修正](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=type%3A%3Abug&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=17.9)  \n* [パフォーマンスの改善](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=bug%3A%3Aperformance&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=17.9)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.9)\n\n\u003Cbr>\n\u003Cbr>\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n- [API Discoveryはデフォルトでブランチパイプラインを使用予定](https://docs.gitlab.com/ee/update/deprecations.html#api-discovery-will-use-branch-pipelines-by-default)  \n- [アプリケーションセキュリティテストアナライザーの大型バージョンアップ](https://docs.gitlab.com/ee/update/deprecations.html#application-security-testing-analyzers-major-version-update)  \n- [コンテナスキャンのデフォルトの重大度のしきい値を「中」に設定](https://docs.gitlab.com/ee/update/deprecations.html#container-scanning-default-severity-threshold-set-to-medium)  \n- [DASTの`dast_crawl_extract_element_timeout`および`dast_crawl_search_element_timeout`変数を非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#dast-dast_crawl_extract_element_timeout-and-dast_crawl_search_element_timeout-variables-are-deprecated) \n- [DASTの`dast_devtools_api_timeout`のデフォルト値を低めに変更予定](https://docs.gitlab.com/ee/update/deprecations.html#dast-dast_devtools_api_timeout-will-have-a-lower-default-value)  \n- [`defaultMaxHoursBeforeTermination`および`maxHoursBeforeTerminationLimit`フィールドを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#defaultmaxhoursbeforetermination-and-maxhoursbeforeterminationlimit-fields-are-deprecated)  \n\n- [依存プロキシへのトークンスコープの適用](https://docs.gitlab.com/ee/update/deprecations.html#dependency-proxy-token-scope-enforcement)  \n\n- [JavaScriptベンダーライブラリ向けの依存関係スキャン](https://docs.gitlab.com/ee/update/deprecations.html#dependency-scanning-for-javascript-vendored-libraries)  \n\n- [依存関係スキャンのGitLab SBOM脆弱性スキャナーへのアップグレード](https://docs.gitlab.com/ee/update/deprecations.html#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner)  \n\n- [CI/CDテンプレートからサポート終了となるSASTジョブを削除予定](https://docs.gitlab.com/ee/update/deprecations.html#end-of-support-sast-jobs-will-be-removed-from-the-cicd-template) \n\n- [GitLabの高度なSASTをデフォルトで有効化予定](https://docs.gitlab.com/ee/update/deprecations.html#gitlab-advanced-sast-will-be-enabled-by-default)  \n\n- [kptベースの`agentk`を非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#kpt-based-agentk-is-deprecated)  \n\n- [従来のGeo関連のPrometheusリポジトリチェックメトリクス](https://docs.gitlab.com/ee/update/deprecations.html#legacy-geo-prometheus-repository-checks-metrics)  \n\n- [レガシーWeb IDEを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#legacy-web-ide-is-deprecated)  \n\n- [Prometheusサブチャートの大型アップデート](https://docs.gitlab.com/ee/update/deprecations.html#major-update-of-the-prometheus-subchart)  \n\n- [Linux OSパッケージの`gitlab-runner-helper-images`と`gitlab-runner`の依存関係をオプションに](https://docs.gitlab.com/ee/update/deprecations.html#make-the-gitlab-runner-helper-images-linux-os-package-an-optional-dependency-of-gitlab-runner)  \n\n- [GitLab.comでの脆弱性に関する新しいデータ保持制限](https://docs.gitlab.com/ee/update/deprecations.html#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n\n- [グループ設定のプロジェクトページを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#project-page-in-group-settings-is-deprecated)  \n\n- [Raspberry Piの32ビットパッケージを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#raspberry-pi-32-bit-packages-are-deprecated)  \n\n- [REST APIエンドポイント`pre_receive_secret_detection_enabled`を非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#rest-api-endpoint-pre_receive_secret_detection_enabled-is-deprecated)  \n\n- [`allowed_pull_policies`にないコンテナイメージのプルポリシーを拒否](https://docs.gitlab.com/ee/update/deprecations.html#reject-container-image-pull-policies-not-in-allowed_pull_policies)  \n- [GraphQLタイプ`RemoteDevelopmentAgentConfig`を非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#remotedevelopmentagentconfig-graphql-type-is-deprecated)  \n\n- [GraphQLフィールド「duoProAssignedUsersCount」を削除](https://docs.gitlab.com/ee/update/deprecations.html#remove-duoproassigneduserscount-graphql-field)  \n\n- [Yarnプロジェクトの依存関係スキャンの脆弱性を修正](https://docs.gitlab.com/ee/update/deprecations.html#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects)  \n\n- [SASTジョブでグローバルキャッシュ設定を使用しないように変更](https://docs.gitlab.com/ee/update/deprecations.html#sast-jobs-no-longer-use-global-cache-settings)  \n- [シークレット検出アナライザーがデフォルトではルートユーザーで実行されないように](https://docs.gitlab.com/ee/update/deprecations.html#secret-detection-analyzer-doesnt-run-as-root-user-by-default)  \n\n- [公開APIのサブスクリプション関連のAPIエンドポイントを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#subscription-related-api-endpoints-in-the-public-api-are-deprecated)  \n\n- [SpotBugsスキャンの一部としてプロジェクトビルドをサポート](https://docs.gitlab.com/ee/update/deprecations.html#support-for-project-build-as-part-of-spotbugs-scans)  \n\n- [SUSE Linux Enterprise Server 15 SP2をサポート](https://docs.gitlab.com/ee/update/deprecations.html#support-for-suse-linux-enterprise-server-15-sp2)  \n\n- [`agentk`コンテナレジストリをクラウドネイティブGitLabに移行](https://docs.gitlab.com/ee/update/deprecations.html#the-agentk-container-registry-is-moving-to-cloud-native-gitlab)  \n- [CI/CDジョブトークンをJWT標準に更新](https://docs.gitlab.com/ee/update/deprecations.html#updating-cicd-job-tokens-to-jwt-standard)  \n\n- [GraphQLフィールド`maxHoursBeforeTermination`を非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#maxhoursbeforetermination-graphql-field-is-deprecated)\n\n\u003Cbr>\n\u003Cbr>\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受けるには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n- [openSUSE Leap 15.5のサポート](https://docs.gitlab.com/ee/update/deprecations.html#support-for-opensuse-leap-155)\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ワークフロー](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\u003Cbr>\n\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n\u003Cbr>\n\u003Cbr>\n\n### 過去の日本語リリース情報\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],"2025-02-21",{"slug":2021,"featured":92,"template":681},"gitlab-17-9-release","content:ja-jp:blog:gitlab-17-9-release.yml","Gitlab 17 9 Release","ja-jp/blog/gitlab-17-9-release.yml","ja-jp/blog/gitlab-17-9-release",{"_path":2027,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2028,"content":2034,"config":2040,"_id":2042,"_type":16,"title":2043,"_source":17,"_file":2044,"_stem":2045,"_extension":20},"/ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":2029,"description":2030,"ogTitle":2029,"ogDescription":2030,"noIndex":6,"ogImage":2031,"ogUrl":2032,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2032,"schema":2033},"継続的デリバリーにおける信頼できる情報源としてOCIイメージを活用する方法","GitOpsワークフローの一環としてOpen Container Initiative（OCI）イメージを活用する利点、およびKubernetesへのデプロイを簡素化するためにGitLabが提供する多くの機能について詳しくご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"継続的デリバリーにおける信頼できる情報源としてOCIイメージを活用する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":2029,"description":2030,"authors":2035,"heroImage":2031,"date":2037,"body":2038,"category":962,"tags":2039},[2036],"Daniel Helfand","2025-02-19","gitリポジトリをデプロイメントアーティファクトとして使用しない場合でも、それを[GitOps](https://about.gitlab.com/ja-jp/topics/gitops/)と呼ぶのは適切なのでしょうか？gitは依然としてGitOpsワークフローの中心的な要素ですが、近年では、インフラ定義をOpen\nContainer\nInitiative（OCI）アーティファクトとしてコンテナレジストリに保存し、それをGitOpsデプロイのソース（情報源）とする手法が広まりつつあります。この記事では、この傾向の背後にある考え方、およびGitLabの機能がどのようにGitOpsワークフローの進化を支えているのかについて詳しくご説明します。\n\n\n## GitOpsとは？\n\n\n[OpenGitOps](https://opengitops.dev/)プロジェクトでは、GitOpsの実践に関する以下の[4つの原則](https://opengitops.dev/#principles)を定義しています。\n\n-\n[GitOpsで管理されるシステム](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system)は、[望ましい状態が宣言的に表現](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description)されていること。\n\n- 望ましい状態は、不変性とバージョン管理が保証される形で保存され、完全なバージョン履歴が保持されていること。\n\n- ソフトウェアエージェントは、望ましい状態の宣言をソースから自動的にプルすること。\n\n-\nソフトウェアエージェントは、実際のシステム状態を[継続的](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous)に監視し、[望ましい状態の適用を試みる](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous)こと。\n\n\nGitOpsの一例として、マイクロサービスのKubernetesマニフェストをGitLabプロジェクトに保存することが挙げられます。これらのKubernetesリソースは、マイクロサービスがデプロイされたKubernetesクラスター上で実行されている[コントローラー](https://kubernetes.io/docs/concepts/architecture/controller/)によって継続的に調整されます。これにより、エンジニアは通常のコード作業と同じワークフローを使用してインフラを管理できます。たとえば、マージリクエストを作成し、変更を加えてレビューしたり、変更にバージョン管理を適用することができます。GitOpsは、[構成ドリフトを防ぐ](https://about.gitlab.com/topics/gitops/#cicd)といった運用上の利点もあり、エンジニアが特定の展開結果に至った変更を監査するのにも役立ちます。\n\n\n## GitOpsワークフローにおけるgitの利点と制限\n\n\ngitはGitOpsワークフローにおいて不可欠な要素ではありますが、もともとgitリポジトリはGitOpsコントローラによってデプロイされることを前提に設計されたものではありません。gitによってエンジニア同士が連携しながらインフラに変更を加えたり、その後変更を監査したりすることはできます。しかし、コントローラーが正常にデプロイを実行するために、gitリポジトリ全体をダウンロードする必要はありません。GitOpsコントローラーが必要とするのは、特定の環境のインフラ定義だけです。\n\n\nさらに、デプロイプロセスにおいて重要なのは、デプロイの変更が信頼できるソースから行われたものであることを確認するために、[デプロイに署名して検証](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing)することです。Gitのコミットは、GitOpsコントローラーによって署名・検証することが可能ですが、コミットはデプロイに関連しない他の詳細（ドキュメントの変更、他の環境の更新、Gitリポジトリの再構成など）を含むこともあります。また、1回のデプロイが複数のコミットにまたがる場合があるため、デプロイ全体が十分に反映しきれないこともあります。これもまた、このgit機能が設計されていないケースのように感じます。\n\n\nGitOpsワークフローにおけるgitのもう一つの課題は、想定以上に自動化が進んでしまう可能性があることです。監視しているブランチに変更をマージすると、すぐにデプロイされてしまいます。これは、gitの外側にプロセスを制御する仕組みがないためです。たとえば、金曜日の午後遅くにデプロイが行われないようにするにはどうすればよいでしょうか？あるいは、デプロイ担当のチームが特定のGitLabプロジェクトで変更をマージする権限を持っていない場合、どう対処すればよいのでしょうか？OCIイメージを使用することで、プロセスにパイプラインが追加され、[承認やデプロイの停止](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)といったデリバリー制御の機能を活用できるようになります。\n\n\n## OCIイメージ\n\n\n[Open Container\nInitiative](https://opencontainers.org/)は、コンテナ形式に関する標準を定義するために貢献してきました。多くのエンジニアは、Dockerfileを使用してコンテナイメージを作成することに慣れていますが、Kubernetesマニフェストをコンテナレジストリに保存することにはあまり馴染みがないかもしれません。[GitLabのコンテナレジストリ](https://docs.gitlab.com/ee/user/packages/container_registry/)はOCI準拠であるため、特定の環境向けのKubernetesマニフェストをコンテナレジストリにプッシュすることができます。これにより、[Flux\nCD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/)のようなGitOpsコントローラーは、gitリポジトリ全体をクローンすることなく、このOCIアーティファクトに保存されたマニフェストを利用してデプロイを実行できます。\n\n\nGitOpsワークフローでは、gitリポジトリにマイクロサービスがデプロイされるすべての環境のインフラ定義が含まれていることがよくあります。特定の環境向けのKubernetesマニフェストをパッケージ化することで、Flux\nCDはデプロイに必要な最小限のファイルだけをダウンロードして、特定の環境へのデプロイを実行できます。\n\n\n### OCIアーティファクトのセキュリティ上の利点\n\n\n前述のとおり、環境にデプロイされるアーティファクトに署名し、検証することで、ソフトウェアプロジェクトのセキュリティが一層強化されます。Kubernetesマニフェストがコンテナレジストリにプッシュされた後、[Sigstore\nCosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/)のようなツールを使用してOCIイメージに秘密鍵で署名できます。この秘密鍵は、GitLabプロジェクト内の[CI/CD変数](https://docs.gitlab.com/ee/ci/variables/)として安全に保存できます。その後、Flux\nCDはKubernetesクラスターに保存された公開鍵を使用して、デプロイが信頼できるソースから来ていることを確認できます。\n\n\n## GitLabを使ってOCIイメージをプッシュして署名する方法\n\n\nGitLabは、OCIイメージのパッケージ化、署名、デプロイのプロセスを簡素化する多くの機能を提供しています。GitOpsワークフローにおけるGitLabプロジェクト構成の一般的な方法は、各マイクロサービスのコード用に個別のGitLabプロジェクトを用意し、すべてのマイクロサービスに共通する単一のインフラリポジトリを持つというものです。アプリケーションが`n`個のマイクロサービスで構成されている場合、アプリケーションには`n\n+ 1`個のGitLabプロジェクトが必要になります。\n\n\nコードプロジェクトで作成されるアーティファクトは、通常、アプリケーションをパッケージ化するために使用されるコンテナイメージです。インフラプロジェクトまたはデリバリープロジェクトには、各マイクロサービスをスケールさせ、トラフィックを提供するために必要なリソースを定義したKubernetesマニフェストが含まれます。このプロジェクトで作成されるアーティファクトは通常、アプリケーションと他のマニフェストをKubernetesにデプロイするために使用されるOCIイメージです。\n\n\nこの構成では、環境の分離はKubernetesマニフェストを別々のフォルダに定義することで行われます。これらのフォルダは、アプリケーションをホストする環境（開発、ステージング、本番など）を表します。コードプロジェクトに変更が加えられ、新しいコンテナイメージがプッシュされた場合、その変更をGitLabのFlux\nCDとのインテグレーションを使ってデプロイするために必要なのは、環境フォルダ内のマニフェストを編集して新しいイメージ参照を追加し、マージリクエストを作成することだけです。マージリクエストのレビュー、承認、マージが実行されると、デリバリープロジェクトのCI/CDジョブが新しいOCIイメージをプッシュし、Flux\nCDがそれを受け取って新しい環境にデプロイします。\n\n\n![OCIイメージ -\nフローチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\n\nOCIイメージへの署名は、CosignをプロジェクトのCI/CDジョブに組み込むだけで簡単に行えます。以下のコマンドをローカルで実行することで、Cosignを使って新しい公開鍵と秘密鍵を生成できます。その際は、[glab\nCLI](https://gitlab.com/gitlab-org/cli/#installation)を使ってGitLabインスタンスにログインし、Cosignコマンド内の[`PROJECT_ID`]を[デリバリープロジェクトのID](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id)に置き換えてください。\n\n\n```\n\nglab auth login\n\ncosign generate-key-pair gitlab://[PROJECT_ID]\n\n```\n\n\ncosignコマンドが正常に実行されると、`COSIGN_PUBLIC_KEY`と`COSIGN_PRIVATE_KEY`という名前で、プロジェクトのCI/CD変数セクションにCosignキーが追加されていることが確認できます。\n\n\n### CI/CDジョブの例\n\n\nOCIイメージをプッシュするためのGitLab CI/CDジョブは、以下のような形になります。\n\n\n```yaml\n\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths: \n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\" \n```\n\n\n[GitLab\nCI/CDカタログ](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)には、GitLabが管理する[CI/CDコンポーネント（OCIアーティファクトおよびFlux\nCD向け）](https://gitlab.com/explore/catalog/components/fluxcd)が用意されています。このコンポーネントにより、開発チームはKubernetesマニフェストをOCIイメージとしてGitLabのコンテナレジストリや外部コンテナレジストリにプッシュし、Cosignを使用してOCIイメージに署名を行い、Flux\nCDを通じて新しくプッシュされたイメージをすぐに環境に同期することができます。 \n\n\n上記の例では、Flux CD\n`component`がGitLabプロジェクトの`.gitlab-ci.yml`ファイル内に含まれています。コンポーネントの入力パラメータを使って、ユーザーはイメージのプッシュ先レジストリ（すなわち`registry_image_url`と`image\ntag`）、プッシュ対象となるKubernetesマニフェストのファイルパス（すなわち`manifest_path`）、イメージの署名に使用するCosignの秘密鍵（すなわち`signing_private_key`）、そして環境への更新同期に必要なKubernetes名前空間とFlux\nCDの\n[OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/)名（すなわち`flux_oci_namespace_name`と`flux_oci_repo_name`）を定義できます。\n\n\n`kubernetes_agent_reference`を使用することで、各GitLabプロジェクトに`kubeconfig`\nCI/CD変数を個別に保存することなく、GitLab\nCI/CDジョブがKubernetesクラスターへアクセスするために必要な`kubeconfig`の権限を継承できるようになります。[Kubernetes向けGitLabエージェント](https://docs.gitlab.com/ee/user/clusters/agent/)をセットアップすることで、同じ[GitLabグループ](https://docs.gitlab.com/ee/user/group/)内のすべてのプロジェクトのCI/CDジョブに、Kubernetesクラスターへのデプロイ権限を継承させるように設定できます。\n\n\nKubernetesエージェントのコンテキストは、通常、GitLabグループ内でKubernetes向けGitLabエージェントを設定している場所で構成されます。この設定は、通常、Flux\nCDを管理しているプロジェクトで行うことが推奨されています。CI/CDアクセス向けのエージェント設定について詳しくは、[CI/CDワークフローのドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html)をご覧ください。\n\n\n`$COSIGN_PRIVATE_KEY`、`$FLUX_OCI_REPO_NAME`、`$FRONTEND_DEV_NAMESPACE`といった変数は、機密性の高い情報をCI/CDログ上でマスキングしつつ、簡単にアクセスできるようにするためにCI/CD変数として保存されています。`$CI_REGISTRY_IMAGE`は、GitLabジョブでデフォルトで利用可能な変数で、対象のGitLabプロジェクトのコンテナレジストリを示します。\n\n\n### OCIイメージのデプロイ\n\n\n[Flux\nCDをGitLabプロジェクトと組み合わせて使用する](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html)ことで、マイクロサービスの各環境へのデプロイと署名の検証を自動化できます。Flux\nCDをGitLabプロジェクトと連携するように設定したら、プッシュしたOCIイメージを同期するために、以下のKubernetesカスタムリソース定義\n[CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をプロジェクトに追加できます。\n\n\n```yaml\n\napiVersion: v1\n\nkind: Namespace\n\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\n\napiVersion: bitnami.com/v1alpha1\n\nkind: SealedSecret\n\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\n\napiVersion: source.toolkit.fluxcd.io/v1beta2\n\nkind: OCIRepository\n\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\n\napiVersion: kustomize.toolkit.fluxcd.io/v1\n\nkind: Kustomization\n\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n``` \n \n[`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/)リソースを使用することで、Kubernetesマニフェストをさらにカスタマイズできるほか、リソースをデプロイする対象のネームスペースも指定することができます。Flux\nCDの`OCIRepository`リソースでは、定期的に同期する対象となるOCIイメージのリポジトリ参照およびタグを指定できます。また、`verify.provider`と`verify.secretRef`というプロパティがあることに気づくでしょう。これらのフィールドを使うことで、クラスターにデプロイされるOCIイメージが、先ほどのCI/CDジョブで使用されたCosignの秘密鍵によって署名されたものであることを検証できます。\n\n\n公開鍵は、`OCIRepository`リソースと同じネームスペース内に格納する必要がある、[Kubernetesシークレット](https://kubernetes.io/docs/concepts/configuration/secret/)に保存しなければなりません。このシークレットをFlux\nCDによって管理し、平文で保存しないようにするには、値を暗号化してクラスター側のコントローラーで復号させるために、[SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/)の使用を検討しましょう。\n\n\nSealedSecretsを使わないより簡単な方法としては、[`kubectl\nCLI`](https://kubernetes.io/docs/reference/kubectl/)を使用して[GitLab\nCI/CDジョブでシークレットをデプロイする](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html)方法があります。SealedSecretを使用しない方法では、上記で使用していたSealedSecretを削除し、新しいOCIイメージをプッシュするジョブを実行する前に、公開鍵のシークレットをデプロイするジョブを実行するだけです。これにより、シークレットがGitLab上で安全に管理され、クラスター内でOCIRepositoryから正常にアクセスできるようになります。このアプローチは比較的シンプルですが、本番環境でのシークレット管理には適していないことにご留意ください。 \n\n\n## OCI、GitLab、およびGitOpsの利点\n\n\nOCIアーティファクトを活用することで、GitOpsチームはセキュリティ面での利点を得ながら、デプロイを最小限に抑えることができます。ユーザーは、インフラの信頼できる情報源としてgitを活用できる点や、プロジェクトでのコラボレーションが可能になる点など、gitがもたらすあらゆる利点を引き続き享受できます。OCIイメージは、GitOpsにおけるデプロイの側面を強化する新たなパッケージ化手法を提供します。\n\n\nGitLab\nは、GitOpsワークフローをよりシンプルにするための利用体験を提供できるよう、ユーザーやクラウドネイティブコミュニティから継続的に学び続けています。このブログでご紹介した機能をお使いになるには、[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/free-trial/)にお申込みください。これらのツールに関する皆さまのご利用体験についても、ぜひお聞かせください。フィードバックは[コミュニティフォーラム](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965)にて受け付けています。\n",[110,825,1548,533,966,676],{"slug":2041,"featured":6,"template":681},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","content:ja-jp:blog:how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery","ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":2047,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2048,"content":2054,"config":2059,"_id":2061,"_type":16,"title":2062,"_source":17,"_file":2063,"_stem":2064,"_extension":20},"/ja-jp/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":2049,"description":2050,"ogTitle":2049,"ogDescription":2050,"noIndex":6,"ogImage":2051,"ogUrl":2052,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2052,"schema":2053},"エンタープライズ規模のGitLabパッケージレジストリの構築","GitLab独自のプロジェクトベースの公開モデルを活用し、ルートグループレベルを使用して、安全で柔軟なパッケージ管理戦略を立てる方法についてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662332/Blog/Hero%20Images/blog-image-template-1800x945__23_.png","https://about.gitlab.com/blog/structuring-the-gitlab-package-registry-for-enterprise-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"エンタープライズ規模のGitLabパッケージレジストリの構築\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":2049,"description":2050,"authors":2055,"heroImage":2051,"date":2037,"body":2056,"category":701,"tags":2057},[1799],"組織の規模が拡大するにつれ、社内パッケージの管理はますます複雑になります。JFrog ArtifactoryやSonatype\nNexusなどの従来のパッケージ管理システムでは一元化されたリポジトリアプローチが使用される一方で、GitLabでは現代の開発チームの作業により合致する、別の方法を採用しています。この記事では、Mavenパッケージとnpmパッケージを例に、エンタープライズ規模のGitLabパッケージレジストリを効果的に構築する方法について見ていきます。\n\n\n## GitLabパッケージレジストリモデルについて\n\n\n従来のパッケージ管理システムからGitLabのアプローチへ移行する際は、その違いに最初は戸惑うかもしれません。GitLabでは、単一の集中型リポジトリを使用する代わりに、パッケージ管理を既存のプロジェクト構造とグループ構造に直接統合します。これにより、次のような運用が可能になります。\n\n\n- チームは、コードが含まれる特定のプロジェクトにパッケージを公開\n\n- チームは、ルートグループレジストリ（その下にある全パッケージを網羅）からパッケージを使用\n\n- アクセス制御はGitLabの既存の権限設定から継承\n\n\nこのモデルには、次のようないくつかの利点があります。\n\n\n- パッケージとともにそのソースコードの所有権を明確化\n\n- 追加設定なしできめ細かいアクセス制御を実現\n\n- CI/CD統合を簡素化\n\n- チーム構造との自然な整合性を実現\n\n- ルートグループを使用することで、自社の全パッケージに単一のURLからアクセス可能\n\n\n### ルートグループパッケージレジストリを利用する利点\n\n\nGitLabではさまざまなグループレベルでパッケージを利用できますが、GitLabユーザーの間では、ルートグループレベルを使うことがベストプラクティスとして定着しつつあります。それには、以下のような理由があります。\n\n\n- **単一のアクセスポイント**：単一のURLから組織内の全プライベートパッケージにアクセス可能\n\n- **一貫性のあるパッケージ名**：グループレベルのエンドポイントにより、各チームは競合することなく、希望する命名規則を適用可能\n\n- **設定の簡素化**：すべてのデベロッパーが同じ設定を使用してパッケージにアクセス可能\n\n- **安全なアクセス管理**：デプロイトークンと組み合わせることで、容易にローテーションとアクセス制御を実現\n\n- **階層型の構造**：統一された方法でのアクセスを維持しながら、組織構造に自然にマッピング可能\n\n\n## 実世界での例：エンタープライズ向け構成\n\n\nでは、実際に大規模な企業ではどのように機能するか見ていきましょう。\n\n\n```\n\ncompany/ (root group)\n\n├── retail-division/\n\n│   ├── shared-libraries/     # 部門固有の共有コード\n\n│   └── teams/\n\n│       ├── checkout/        # チームはここにパッケージを公開\n\n│       └── inventory/       # チームはここにパッケージを公開\n\n├── banking-division/\n\n│   ├── shared-libraries/    # 部門固有の共有コード\n\n│   └── teams/\n\n│       ├── payments/       # チームはここにパッケージを公開\n\n│       └── fraud/         # チームはここにパッケージを公開\n\n└── shared-platform/        # 企業全体の共有コード\n    ├── java-commons/      # 共有Javaライブラリ\n    └── ui-components/     # 共有UIコンポーネント\n```\n\n\n### 公開設定\n\n\nチームは各自のプロジェクトレジストリにパッケージを公開します。これにより、所有権が明確化されます。\n\n\n1. Mavenの例\n\n\n```xml\n\n\u003C!-- checkout/pom.xml -->\n\n\u003CdistributionManagement>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/distributionManagement>\n\n```\n\n\n2. npmの例\n\n\n```json\n\n// ui-components/package.json\n\n{\n  \"name\": \"@company/ui-components\",\n  \"publishConfig\": {\n    \"registry\": \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/\"\n  }\n}\n\n```\n\n\n### 使用設定\n\n\nルートグループを使用する利点をここで発揮します。全チームは、パッケージへのアクセス用に単一のエンドポイントを設定します。\n\n\n1. Mavenの例\n\n\n```xml\n\n\u003C!-- 任意のプロジェクトのpom.xml -->\n\n\u003Crepositories>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>https://gitlab.example.com/api/v4/groups/company/-/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/repositories>\n\n```\n\n\n2. npmの例\n\n\n```\n\n# 任意のプロジェクトのnpmrcファイル\n\n@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/\n\n```\n\n\nこの設定では、プロジェクトベースでの公開による利点を活用しつつ、社内全体にわたってすべてのパッケージへのアクセスを自動的に提供します。\n\n\n## 認証とアクセス制御\n\n\nGitLabが採用しているモデルでは、デプロイトークンとCI/CD統合により、認証が簡素化されます。\n\n\n### CI/CDパイプラインでの利用\n\n\nGitLabは、`CI_JOB_TOKEN`を使用してパイプラインでの認証を自動的に処理します。\n\n\n```yaml\n\n#-.gitlab. .gitlab-ci.yml\n\npublish:\n  script:\n    - mvn deploy  # またはnpm publish\n  # CI_JOB_TOKENによって自動的に認証が行われる\n```\n\n\n### 開発環境での利用\n\n\nグループデプロイトークンを用いて、パッケージを使用します。\n\n\n- ルートグループレベルで読み取り専用のデプロイトークンを作成\n\n- セキュリティのために定期的にトークンローテーションを行う\n\n- すべてのデベロッパー間で単一の設定を共有\n\n\n## ルートグループパッケージレジストリを使用する利点\n\n\n1. 設定の簡素化\n   - 単一のURLからすべてのパッケージにアクセス可能\n   - チーム間で一貫した設定\n   - トークンローテーションを簡単に実施可能\n2. 所有権の明確化\n   - パッケージをソースコードと一緒に保管\n   - 各チームが公開を制御\n   - バージョン履歴をプロジェクトアクティビティに関連付け\n3. 自然な構造\n   - 企業構造に合致\n   - チームの自律性をサポート\n   - チーム間のコラボレーションが可能\n\n## 始め方\n\n\n1. ルートグループの設定\n   - 明確なグループ構造を作成\n   - 適切なアクセス制御を設定\n   - グループデプロイトークンを作成\n2. チームプロジェクトの設定\n   - プロジェクトレベルでの公開設定を行う\n   - CI/CDパイプラインを実装\n   - パッケージの命名規則を文書化\n3. 使用の標準化\n   - ルートグループレジストリへのアクセスを設定\n   - デプロイトークンを安全に共有\n   - パッケージの検索プロセスを文書化\n\n## まとめ\n\n\nGitLabのパッケージレジストリモデルは、特にルートグループの使用を活用すれば、エンタープライズ向けのパッケージ管理用の強力なソリューションとなります。組織は、プロジェクトベースでの公開とルートグループでの利用を組み合わせることで、所有権の明確化とアクセスの簡素化の両方を実現できます。このアプローチなら、セキュリティと使いやすさを維持しながら、組織の規模に合わせて自然にスケールできます。\n\n\nまずは、1つのチームまたは部門にこのモデルを導入し、この統合アプローチの効果を実感しながら徐々に展開していくことをおすすめします。なお、この記事ではMavenとnpmに焦点を当ててご説明しましたが、GitLabでサポートされているすべてのタイプのパッケージにも、同じ原則を適用できます。\n\n\n> 今すぐパッケージレジストリを使い始めましょう！[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)にぜひお申し込みください。\n",[702,676,2058],"solutions architecture",{"slug":2060,"featured":92,"template":681},"structuring-the-gitlab-package-registry-for-enterprise-scale","content:ja-jp:blog:structuring-the-gitlab-package-registry-for-enterprise-scale.yml","Structuring The Gitlab Package Registry For Enterprise Scale","ja-jp/blog/structuring-the-gitlab-package-registry-for-enterprise-scale.yml","ja-jp/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"_path":2066,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2067,"content":2073,"config":2078,"_id":2080,"_type":16,"title":2081,"_source":17,"_file":2082,"_stem":2083,"_extension":20},"/ja-jp/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"title":2068,"description":2069,"ogTitle":2068,"ogDescription":2069,"noIndex":6,"ogImage":2070,"ogUrl":2071,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2071,"schema":2072},"Amazon ECRからGitLabへのコンテナイメージ移行の自動化","プラットフォームチームがCI/CDをGitLabに移行する際、コンテナイメージの移行がボトルネックになってはなりません。このガイドでは、パイプライン移行を自動化する方法を詳しく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","https://about.gitlab.com/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Amazon ECRからGitLabへのコンテナイメージ移行の自動化\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-13\",\n      }",{"title":2068,"description":2069,"authors":2074,"heroImage":2070,"date":2075,"body":2076,"category":672,"tags":2077},[1799],"2025-02-13","「Amazon Elastic Container\nRegistry（ECR）からGitLabに数百ものコンテナイメージを移行する必要があるのですが、手伝ってもらえますか？」これまでのプラットフォームエンジニアとの会話の中で、何度もこの質問が出てきました。彼らは、DevSecOpsツールチェーンをGitLabに統合してモダナイズしようとしていたものの、コンテナイメージの移行の箇所でつまずいていました。個々のイメージの移行は簡単でも、数が多すぎると、手作業で行うのは現実的ではありません。\n\n\nまさに、あるエンジニアは「やるべきことはわかっています。プルして、再タグ付けして、プッシュするだけです。しかし、マイクロサービスが200個もあり、それぞれに複数のタグがあります。インフラストラクチャ関連の重要な仕事が山積みの中、この移行作業に何週間も費やすわけにはいきません」と話していました。\n\n\n## 課題\n\n\nこの会話をきっかけに、プロセス全体を自動化できないかと考えました。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)をGitLabに移行する際、コンテナイメージの移行がボトルネックになってはなりません。手作業はシンプルですが、繰り返しが多すぎます。各イメージをプルし、再タグ付けし、GitLabのコンテナレジストリにプッシュする…これを数十のリポジトリ、各イメージの何百ものタグに対して行うとなると、数日から数週間かかる途方もない作業になります。\n\n\n## 解決策\n\n\nそこで、こういった大変な作業を自動処理するGitLabパイプラインの作成に取り掛かりました。目標はシンプルです。プラットフォームエンジニアが数分でセットアップできて、一晩放置すればすべてのイメージの移行が完了している、そんなツールを作ることでした。\n\n\n### アクセス権の設定\n\n\nまずはセキュリティです。チームが最小限のAWS権限でこの移行作業を実行できるようにすることを重視しました。以下の読み取り専用のアイデンティティおよびアクセス管理（IAM）ポリシーを用意しました。\n\n\n```json\n\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"ecr:GetAuthorizationToken\",\n                \"ecr:BatchCheckLayerAvailability\",\n                \"ecr:GetDownloadUrlForLayer\",\n                \"ecr:DescribeRepositories\",\n                \"ecr:ListImages\",\n                \"ecr:DescribeImages\",\n                \"ecr:BatchGetImage\"\n            ],\n            \"Resource\": \"*\"\n        }\n    ]\n}\n\n```\n\n\n### GitLabの設定\n\n\nセキュリティの次はGitLab側の設定です。最小限の構成で済むようにしました。CI/CD設定で以下の変数を設定します。\n\n\n```\n\nAWS_ACCOUNT_ID: AWSのアカウントID\n\nAWS_DEFAULT_REGION: ECRのリージョン\n\nAWS_ACCESS_KEY_ID: [マスク]\n\nAWS_SECRET_ACCESS_KEY: [マスク]\n\nBULK_MIGRATE: true\n\n```\n\n\n### 移行パイプライン\n\n\nここからが本番です。このパイプラインはDocker-in-Dockerを使って構築し、すべてのイメージ操作を安定して実行できるようにしました。\n\n\n```yaml\n\nimage: docker:20.10\n\nservices:\n  - docker:20.10-dind\n\nbefore_script:\n  - apk add --no-cache aws-cli jq\n  - aws sts get-caller-identity\n  - aws ecr get-login-password | docker login --username AWS --password-stdin\n  - docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} ${CI_REGISTRY}\n```\n\n\nこのパイプラインは3つのフェーズで構成され、それぞれが前のフェーズをベースにします。\n\n\n1. 検出\n\n\nまず、すべてのECRリポジトリを取得します。\n\n\n```bash\n\nREPOS=$(aws ecr describe-repositories --query\n'repositories[*].repositoryName' --output text)\n\n```\n\n\n2. タグの列挙\n\n\n次に、各リポジトリの全タグを取得します。\n\n\n```bash\n\nTAGS=$(aws ecr describe-images --repository-name $repo --query\n'imageDetails[*].imageTags[]' --output text)\n\n```\n\n\n3. 移行\n\n\n最後に、実際にイメージ移行を実行します。\n\n\n```bash\n\ndocker pull\n${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\n\ndocker tag\n${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\n${CI_REGISTRY_IMAGE}/${repo}:${tag}\n\ndocker push ${CI_REGISTRY_IMAGE}/${repo}:${tag}\n\n```\n\n\n## 期待できる成果\n\n\n移行に何週間もかける時間がないというプラットフォームエンジニアのために、このソリューションは次のような成果を提供します。\n\n\n- すべてのリポジトリとタグを自動的に検出・移行\n\n- ECRとGitLabのイメージ命名規則を統一\n\n- 転送失敗時のエラーハンドリング\n\n- 進捗を追跡できる明確なログ\n\n\n\n移行スクリプトを書いたり、移行作業を監視したりする必要がなくなり、プラットフォームエンジニアは他の重要な作業に集中できるようになります。\n\n\n## 使い方\n\n\n手順はシンプルです。\n\n\n1. `.gitlab-ci.yml`をリポジトリにコピー\n\n2. AWSとGitLabの変数を設定\n\n3. `BULK_MIGRATE`を「true」に設定して、移行を開始\n\n\n## ベストプラクティス\n\n\nさまざまなチームの移行を支援する中で、いくつかの重要なポイントが見えてきました。\n\n\n- ピーク時以外に実行し、チームへの影響を最小限に抑える\n\n- パイプラインのログを確認し、必要な対応がないかチェックする\n\n- すべてのイメージが正常に転送されたことを確認するまで、ECRを廃止しない\n\n- 大規模な移行の場合、ネットワーク負荷を避けるためにレート制限の適用を検討する\n\n\nこのパイプラインは、GitLabの公開リポジトリでオープンソースとして提供しています。プラットフォームエンジニアがコンテナイメージの移行に時間を取られるのではなく、本来の業務に専念できるよう設計されています。ニーズに応じてカスタマイズしてお使いください。実装についてのご質問もお待ちしています。\n\n\n> ####\nこのパッケージおよびその他のコンポーネントの詳細については、[CI/CDカタログのドキュメント](https://gitlab.com/explore/catalog/components/package)をご覧ください。\n",[110,920,676,904,701,2058],{"slug":2079,"featured":92,"template":681},"automating-container-image-migration-from-amazon-ecr-to-gitlab","content:ja-jp:blog:automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","Automating Container Image Migration From Amazon Ecr To Gitlab","ja-jp/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","ja-jp/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"_path":2085,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2086,"content":2092,"config":2097,"_id":2099,"_type":16,"title":2100,"_source":17,"_file":2101,"_stem":2102,"_extension":20},"/ja-jp/blog/getting-started-with-gitlab-mastering-project-management",{"title":2087,"description":2088,"ogTitle":2087,"ogDescription":2088,"noIndex":6,"ogImage":2089,"ogUrl":2090,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2090,"schema":2091},"GitLab入門：プロジェクト管理をマスターする","プロジェクト管理の主要な要素を学び、プロジェクトをより効率良く整理し、追跡する方法を習得しましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097294/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097293924.png","https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab入門：プロジェクト管理をマスターする\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-02-11\",\n      }",{"title":2087,"description":2088,"authors":2093,"heroImage":2089,"date":2094,"body":2095,"category":701,"tags":2096},[696],"2025-02-11","*「GitLab入門」シリーズへようこそ！このシリーズでは、GitLab DevSecOpsプラットフォームを初めて使う方に向けて、基本的な使い方を解説します。*\n\nGitLabは、単なるコードの保存場所ではありません。AI搭載のDevSecOpsプラットフォームであり、プロジェクトを計画、整理、追跡し、成功へ導くためのツールが備わっています。この記事では、GitLabの主要なプロジェクト管理機能と、それらを効果的に活用する方法を解説します。\n\n## なぜGitLabがプロジェクト管理に適しているのか？\n\nもし、コードリポジトリ、イシュートラッカー、コミュニケーションプラットフォームがすべて1か所でシームレスに統合されていたらどうでしょうか。それがGitLabの強みです。すべてを一元化することで、ワークフローを効率化し、コラボレーションを強化し、プロジェクトを円滑に進められます。もう、複数のツールを行き来して情報を見失う心配はありません。GitLabなら、プロジェクトの開始から完了までをスムーズに管理できる環境が整っています。\n\n## GitLabを使ったプロジェクト管理における主要な要素\n\n主要な要素を分かりやすく説明します：\n\n* [エピック](https://docs.gitlab.com/ee/user/group/epics/)：エピックは、プロジェクト全体の大枠を示すものです。プロジェクトにおける重要な機能、大きな目標、長期的な取り組みなどを表します。たとえば、「ウェブサイトのリニューアルを行う」なども、エピックに該当します。エピックを活用することで、作業を大きなまとまりで整理し、管理しやすくできます。\n* [イシュー](https://docs.gitlab.com/ee/user/project/issues/)：イシューは、プロジェクトの目標を達成するための個々のタスクや作業項目です。たとえば、「ホームページのデザインを作成する」「会社概要ページの文章を書く」など、具体的なアクションを表します。イシューはプロジェクトの構成要素であり、個々の作業の進捗を明確に把握するのに役立ちます。\n* [ラベル](https://docs.gitlab.com/ee/user/project/labels.html)：ラベルはタグのようなもので、作業を分類し、フィルタリングするのに役立ちます。ラベルを使用すると、優先度（例：高、中、低）、ステータス（例：未対応、進行中、完了）を示したり、特定のチームや個人にイシューを割り当てたりできます。ラベルを活用することで、作業の整理や優先順位付けを柔軟に行えます。\n* ボード：GitLabのイシューボードは、視覚的なワークスペースです。プロジェクトをKanban形式で表示し、すべてのイシューの状態を一目で確認できます。イシューを複数のリスト間（例：「未対応」「進行中」「完了」）でドラッグ＆ドロップすることで、ワークフローを可視化し、進捗を追跡できます。GitLabでは、[イシュー](https://docs.gitlab.com/ee/user/project/issue_board.html)や[エピック](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html)用のボードを作成できます。\n* [マイルストーン](https://docs.gitlab.com/ee/user/project/milestones/)：マイルストーンは、プロジェクト内の重要なチェックポイントや期限を示します。特定のゴールや締め切りに向けた進捗を追跡するのに役立ちます。例えば、重要な機能の開発完了、ベータ版のリリース、最終製品の公開などのマイルストーンを設定できます。 \n* [タスク](https://docs.gitlab.com/ee/user/tasks.html)：より細かい作業単位として、イシューを小さなタスクに分割できます。これにより、担当者を明確にし、タスクの見落としを防ぐことができます。タスクを使うことでイシュー内にチェックリストを作成でき、複雑な作業の進捗を簡単に追跡できます。\n\n## 各機能の詳細\n\n### 1. エピック：全体像\n\n* エピックの作成：グループの「プラン」メニュー内にある「エピック」に移動します。**新しいエピック**をクリックし、わかりやすいタイトルと、目標を具体的に示す説明を入力します。さらに、エピックの開始日と終了日を指定することもできます。これは、[ロードマップ](https://docs.gitlab.com/ee/user/group/roadmap/)を使用する際に便利です。\n\n![エピック作成ページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097300817.png)\n\n* [ロードマップ](https://docs.gitlab.com/ee/user/group/roadmap/)：エピックをロードマップに追加すると、プロジェクトのタイムラインや長期的な目標を視覚化できます。ロードマップではプロジェクト計画の全体像を俯瞰できるため、大局を把握しながら、主要なマイルストーンに向けた進捗を簡単に追跡できます。\n\n![ロードマップ表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097300818.png)\n\n### 2. イシュー：作業を進める\n\n* イシューの作成：プロジェクトの「プラン」メニュー内にある「イシュー」に移動し、**新しいイシュー**をクリックします。「ホームページのワイヤーフレームをデザインする」のような、簡潔でわかりやすいタイトルを入力し、担当者を割り当て、期限を設定し、タスクの要件を明確に記載した詳細な説明を追加します。\n* GitLab Duo：簡単な要望を伝えるだけで、[GitLab Duoで詳細なイシューの説明を作成](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#populate-an-issue-with-issue-description-generation)できます。\n* ウェイト付け：イシューにウェイトを設定することで、必要な労力を見積もることができます。これは計画や優先順位付けに役立ちます。例えば、簡単なタスクには**1**のウェイトを設定し、より複雑なタスクには**5**のウェイトを設定できます。\n\n![ウェイトが4に設定されているイシュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097300819.png)\n\n### 3. ラベル：作業を整理する\n\n* ラベルの作成：プロジェクトの「イシュー」タブに移動し、「ラベル」をクリックします。そして、イシューを分類する、明確な名前のカスタムラベルを作成します。例えば、**優先度：高**、**ステータス：進行中**、**チーム：デザイン**などのラベルを作成できます。これらのラベルをイシューに適用することで、整理やフィルターがしやすくなります。\n\n![ラベルの画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097300820.png)\n\n### 4. ボード：ワークフローを可視化する\n\n* Kanbanボード：GitLabのボードでは、プロジェクトをKanban形式で表示できます。「未対応」「進行中」「完了」などのリストを作成してワークフローの各ステージを示し、そのリスト間でイシューをドラッグアンドドロップすることで、進捗を可視化できます。\n* ボードのカスタマイズ：ボードはワークフローに合わせて自由に調整できます。列を追加したり、ラベルや担当者でイシューをフィルタリングしたり、エピックやその他の基準でイシューを分類するスイムレーンを設定したりできます。\n\n![イシューボードでワークフローを可視化する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097300820.png)\n\n### 5. タスク：作業を細分化する\n\n* タスクの作成：イシュー内でチェックリストMarkdown構文を使用することで、タスクリストを作成できます。リストの各項目は、イシューの中の小さなステップを表します。例えば、「ホームページのワイヤーフレームをデザインする」というイシューの中に、「初期コンセプトをスケッチする」、「デジタルワイヤーフレームを作成する」、「関係者からフィードバックをもらう」などのタスクを作成できます。タスクを作成するには、イシューのページの「子アイテム」セクションにある**追加**ボタンをクリックします。次に、タスクのタイトルを入力し、**タスクを作成**をクリックします。\n\n![「タスクを作成」ボタンのあるイシュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097300822.png)\n\n### 6. マイルストーン：進捗を追跡する\n* マイルストーンの設定：マイルストーンを使うことで、特定の機能の完成や重要な締め切りなど、プロジェクトの重要なポイントを示せます。マイルストーンには、明確なタイトルと期限を設定しましょう。\n* イシューとの関連付け：マイルストーンにイシューやエピックを関連付けることで、目標に向けた進捗を追跡できます。これにより、個々のタスクがプロジェクト計画全体にどのように貢献しているかを確認できます。\nマイルストーンの作成：「プラン」ドロップダウンメニューから**マイルストーン > 新しいマイルストーン**をクリックします。マイルストーンのタイトル、説明、開始日、および期限を指定します。\n\n![「新しいマイルストーン」画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097300823.png)\n\n\u003Cbr>\u003C/br>\n\n![マイルストーンのある新しいページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097300823.png)\n\n### 7. [イテレーション](https://docs.gitlab.com/ee/user/group/iterations/)：スプリントで作業を進める\n\n* イテレーションの定義：アジャイルワークフローを使用している場合は、特定の開始日と終了日を設定したイテレーション（スプリント）を定義します。これにより、作業をより小さく管理しやすい時間枠に分割できます。\n* イシューの割り当て：イシューをイテレーションに割り当てることで、作業をより短いサイクルで計画し、段階的な価値を生み出すことに集中できます。\n\n### 8. [タイムトラッキング](https://docs.gitlab.com/ee/user/project/time_tracking.html)：作業時間を測定する\n\n* 時間の記録：イシュー内で、「/spend」のクイックアクションを使用し、続けて作業時間を入力することで（例：「/spend 2h 30m」）、作業時間を記録できます。これにより、各タスクに費やした実際の時間を追跡できます。\n* データの分析：タイムトラッキングレポートを生成して、プロジェクトの進捗、チームの効率性、および潜在的なボトルネックなどに関するインサイトを得られます。\n\n![タイムトラッキングレポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097300824.png)\n\n### 9. 依存関係：ワークフローを管理する\n\n* [イシューのリンク](https://docs.gitlab.com/ee/user/project/issues/related_issues.html)：イシュー間に依存関係を設定することで、タスクが適切な順序で完了するように管理できます。例えば、「イシューAを完了しないと、イシューBを開始できない」ような場合、それらのイシューの間に依存関係を作成できます。これにより、ワークフローを可視化し、潜在的な障害を回避できます。\n\n### 10. テンプレート：イシューの作成を効率化する\n\n* [テンプレートの作成](https://docs.gitlab.com/ee/user/project/description_templates.html)：イシューテンプレートを作成することで、よくあるタスクに必要な情報を標準化し、時間を節約するとともに一貫性を保つことができます。例えば、バグ報告用のテンプレートを作成し、「再現手順」「期待される動作」「実際の動作」などの項目を作成できます。\n\n### コラボレーションは成功の鍵\n\nGitLabは、以下の機能を通じてチームのコラボレーションを促進します：\n\n* [コメント](https://docs.gitlab.com/ee/user/discussions/)：イシューやエピックについて、GitLab内で直接議論できます。進捗の共有や質問、フィードバックの提供にコメントを活用しましょう。\n* [メンション](https://docs.gitlab.com/ee/user/discussions/#mentions)：**@**を使って特定のメンバーをメンションすることで、更新を通知したり、意見を求めたりできます。\n* ディスカッション：イシューやエピック内でスレッド形式のディスカッションを行い、アイデアを出し合ったり、協力して問題を解決したり、チーム全員と情報共有したりできます。\n\n### 始めてみましょう\n\nGitLabのプロジェクト管理機能の強みを理解したところで、今度は実際に使ってみましょう！サンプルプロジェクトを作成し、さまざまな機能を試しながら、GitLabを使ったワークフロー改革をぜひ体験してください。また、GitLabドキュメントでは、GitLabを使った[Kanban](https://docs.gitlab.com/ee/tutorials/kanban/)や[スクラム](https://docs.gitlab.com/ee/tutorials/scrum_events/)の運用について詳しく説明しています。\n\n>  #### GitLabアカウントをお持ちでない場合は、[GitLab DuoとGitLab Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)をお試しください！\n\n## 関連リンク\n- [GitLab入門：ユーザーの管理方法](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [GitLab入門：プロジェクトをGitLabにインポートする方法](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)\n",[676,701,904,1389],{"slug":2098,"featured":6,"template":681},"getting-started-with-gitlab-mastering-project-management","content:ja-jp:blog:getting-started-with-gitlab-mastering-project-management.yml","Getting Started With Gitlab Mastering Project Management","ja-jp/blog/getting-started-with-gitlab-mastering-project-management.yml","ja-jp/blog/getting-started-with-gitlab-mastering-project-management",{"_path":2104,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2105,"content":2111,"config":2117,"_id":2119,"_type":16,"title":2120,"_source":17,"_file":2121,"_stem":2122,"_extension":20},"/ja-jp/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"title":2106,"description":2107,"ogTitle":2106,"ogDescription":2107,"noIndex":6,"ogImage":2108,"ogUrl":2109,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2109,"schema":2110},"アジャイルのスプリントを製品ロードマップと調和させる方法","ベストプラクティスとGitLabの機能を活用して、製品開発を進めましょう。一元化されたロードマップの作成、レビューセッションの実施、スプリントのライフサイクルの追跡など、製品開発をスムーズに進めるためのポイントを解説します。","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","https://about.gitlab.com/blog/how-to-harmonize-agile-sprints-with-product-roadmaps","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"アジャイルのスプリントを製品ロードマップと調和させる方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-02-04\",\n      }",{"title":2106,"description":2107,"authors":2112,"heroImage":2108,"date":2113,"body":2114,"category":1705,"tags":2115,"updatedDate":2116},[1702],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[1389,676,677,904],"2025-06-04",{"slug":2118,"featured":92,"template":681},"how-to-harmonize-agile-sprints-with-product-roadmaps","content:ja-jp:blog:how-to-harmonize-agile-sprints-with-product-roadmaps.yml","How To Harmonize Agile Sprints With Product Roadmaps","ja-jp/blog/how-to-harmonize-agile-sprints-with-product-roadmaps.yml","ja-jp/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"_path":2124,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2125,"content":2131,"config":2137,"_id":2139,"_type":16,"title":2140,"_source":17,"_file":2141,"_stem":2142,"_extension":20},"/ja-jp/blog/tips-for-async-communication",{"title":2126,"description":2127,"ogTitle":2126,"ogDescription":2127,"noIndex":6,"ogImage":2128,"ogUrl":2129,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2129,"schema":2130},"非同期コミュニケーションを機能させるには何が必要か？オールリモートのGitLabの働き方に見る “ルールと文化”のつくり方","GitLabのソリューションアーキテクトが語る、効果的なリモートワークの実践をご紹介。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662910/Blog/Hero%20Images/async_communication_key_visual.jpg","https://about.gitlab.com/blog/tips-for-async-communication","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"非同期コミュニケーションを機能させるには何が必要か？オールリモートのGitLabの働き方に見る “ルールと文化”のつくり方\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-01-31\",\n      }",{"title":2126,"description":2127,"authors":2132,"heroImage":2128,"date":2133,"body":2134,"category":2135,"tags":2136},[738],"2025-01-31","*写真：左よりGitLab合同会社 シニアソリューションアーキテクト佐々木直晴、スタッフソリューションアーキテクト 伊藤俊廷。書籍 『[GitLabに学ぶ 世界最先端のリモート組織のつくりかた](https://www.shoeisha.co.jp/book/detail/9784798179421)』 と 『[GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術](https://www.shoeisha.co.jp/book/detail/9784798185736)』 を手に*\u003Cbr>\u003Cbr>\n\n## 目次\n1. リモートワーク＝非同期コミュニケーションが発生すること\n2. 非同期コミュニケーションを改善するには？\n3. 非同期・同期コミュニケーションはどう使い分ける？\n4. オールリモート環境における効率的なオンボーディング\n5. オールリモート環境における生産的なコミュニケーション法\n6. GitLabのソリューションアーキテクトの役割とスキル\n\u003Cbr>\n\u003Cbr>\n\nコロナ禍を経た昨今、リモートワークを廃止し出社を前提とする企業が増えています。公益財団法人日本生産性本部がおこなった「第16回 働く人の意識調査※」によれば、テレワーク実施率は14.6%で過去最低を更新したとのことです。\n\n※参考：2025年1月30日公開 [第16回 働く人の意識調査 | 調査研究・提言活動 | 公益財団法人日本生産性本部](https://www.jpc-net.jp/research/detail/007214.html)\n\nリモートワークではコミュニケーションが不足しがちだったり、生産性が低下しやすかったりなどさまざまな課題が指摘されています。コロナ禍で多くの企業が導入を急いだ期間が過ぎ、日本企業におけるリモートワークは曲がり角に差し掛かっているのでしょう。それでもなお、企業はリモートワーク導入をすすめるべきなのでしょうか。\n\n今回は、リモートワークを前提とした「[all-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/)（オールリモート）」を実践されているGitLab社の担当者に「GitLabの働き方」について詳しく聞きました。オフィスを持たないGitLab社の働き方に、興味を持たれている方も多いのではないでしょうか。\n\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3704_resized.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\nそういった方の期待を裏切るかもしれませんが、今回話を聞いた伊藤・佐々木は、リモートワークを無条件に肯定してはいません。リモートワークはあくまで目的を達成するための手段であり、目的ではないというのがふたりの考えです。\n\n佐々木によれば __”[Everyone can contribute](https://handbook.gitlab.com/teamops/equal-contributions/)（誰もが貢献できる）”__ というGitLab社のミッションを実現する手段として、all-remoteが役立つということです。たとえばGitLab社では「サンフランシスコに住んでいないとエンジニアとして働けない」といったことはありません。採用をおこなう地域に一定のルール（※）はあるものの、少なくともオフィスがある場所でしかGitLabで働けないわけではないのです。\n\nall-remoteを実現できているおかげで、通信環境さえあれば他の地域で暮らすエンジニアもGitLab社で活躍できます。「”[Everyone can contribute](https://handbook.gitlab.com/teamops/equal-contributions/)”を重視し、『オフィスがあった方がいいね』とならないのはGitLab社の企業文化の特徴的な部分だ」と佐々木は話しました。\n\n今回のインタビューでは、ふたりにGitLab社がどのようにリモートワークを活用しているかをうかがっています。GitLab社の働き方を知りたい方、自社のリモートワーク導入に悩んでいる担当者の方はぜひ参考にしてください。\n\n※現在は、エンティティがある地域やPEOを通じて雇用が可能な地域でのみ採用を行っており、地域によっては職種を限定しています。\n\n\u003Cbr>\n\n> ーー GitLabにおける、ふたりのお仕事・役割・入社の経緯を教えてください\n## GitLabの先進的な働き方に興味を持ち ソリューションアーキテクトとして入社\n\n__伊藤__：わたしは、GitLabのソリューションアーキテクトというプリセールスエンジニアです。お客様がGitLabを導入される際に、技術面・ビジネス面それぞれの課題に対して、どのように解決できるかを一緒に考え、最適な活用方法をご提案しています。また、製品の価値をお客様のビジネスにどう活かすかを検討しながら、継続的にエンゲージメントを築くことも私の重要な役割です。\n\nGitLabには、LinkedInでリクルーターに声をかけられたことがきっかけで興味を持ち入社しました。GitLabの製品自体にも興味があったのですが、ハンドブック中心にall-remoteでドキュメンテーションをしている点にも興味を持ったのです。きっと先進的な働き方が確立されていると想定し、それを体験したかったです。\n![伊藤 俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3669_resize.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト 伊藤 俊廷*\n\n__佐々木__：わたしも、伊藤と同じくソリューションアーキテクトです。ソリューションアーキテクトは、GitLabを導入することで、お客様の業務やビジネスがどう変わるかにも着目します。お客様の近くで、課題を発見するという面白さがある役割ですね。\n\n入社前からGitLabを使っていて、製品自体に興味があった点はわたしも同じです。それ以外に透明性がすごいという印象もありましたね。\n\nGitLabでは以前にオペレーションのミスで、本番データベースが喪失したという事故がありました。その際、GitLabはその復旧作業をYouTubeでライブ中継していて、すごいなと思っていたのです。GitLabに入社することになったと周囲に報告した際に『復旧作業をライブ中継していた会社だよね』と言われたのは覚えています。\n\n> ーー おふたりが考えるリモートワークの定義を教えてください。\n## リモートワーク＝非同期コミュニケーションが発生すること\n### オフィスに行かないことがリモートワークではない\n\n__伊藤__：GitLabというより我々の考えになりますが、一般に言われているようにオフィスに行かないことがリモートワークという風に定義していません。\n\nたとえば東京と大阪にオフィスがあれば、オフィス間での仕事は必然的にリモートです。東京にしかオフィスがない会社でも、目の前の人とメールやSlackでやり取りするなどして、リモートでコミュニケーションをとります。突き詰めると一般的なオフィスワーカーは、働いているほんとんどの時間をリモートワークな状態で進めているのではないかと考えるようになったのです。\n\n必ずしも人と人が、いつも同じ場所・タイミングで仕事をするわけではありません。メールやSlackなどで、[非同期のコミュニケーション](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/)が発生することになります。\n\nこういった非同期のコラボレーションが発生することが、リモートワークとも言えますね。一方で、対面や電話、Zoomでの会議などは、同期コミュニケーションです。\n\n> ーー GitLabで実践されているall-remoteとはどんなものか教えてください\n\n### all-remoteとは物理的に集まるオフィスがなく、在宅での業務を基本とすること\n\n__伊藤__： 物理的にみんなが集まるオフィスがなく、在宅で仕事をすることが基本となるのがall-remoteです。リモートの人がいたりリモートでない人がいたりという状態でなく、全員がリモートで働けることをall-remoteと呼んでいます。\n\nall-remoteは『ほかの人と一切会わない』 ”[strictly remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#10-strictly-remote)” ではありません。GitLabは対面で会うことも重視しています。GitLabチームメンバーが少ないころは、9ヵ月に1度は世界のどこかで集まるということもしていました。  \n\n> ーー 全ての企業がリモートワークを実践すべきだと思いますか？\n\n### どんな企業でも、無理にリモートワークへ切り替える必要はない\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3764_resize.jpg)\n\n__佐々木__： 非同期・同期どちらのコミュニケーションが良くて、どちらが駄目というわけではありません。それぞれの特性があります。\n\n同期コミュニケーションには、Slackやメールなどと違いすぐに返事が返ってくるという良さがありますね。柔らかい状態で何か議論をはじめて輪郭をはっきりさせるフェーズにおいては、早い同期コミュニケーションが合っています。\n\n一方、ある程度枠が決まり分担して作業できたり、確認にインターバルがとれたりするフェーズでは非同期コミュニケーションも可能です。非同期のコミュニケーションは早さが劣りますが、メールなどが残りあとで探すことができます。\n\n__伊藤__：我々もZoomでちょっと話しながら、互いにアイデアを出し合うということはします。あと、たとえば製品チームなどが、大枠の設計をする際などは同期のコミュニケーションを使っていますね。同期コミュニケーションならではの良さがあるのです。同期コミュニケーションが適している企業は、無理に[all-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#9-all-remote)や[hybrid-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#5-hybrid-remote)に切り替える必要はありません。\n\nただ、非同期コミュニケーションが必ず発生するということを意識できていない組織が大半を占める印象はあります。同期コミュニケーションが適している企業でも、非同期コミュニケーションが一切不要なわけではなく、情報を一元的にドキュメント化をするデメリットは基本的にはないはずです。\n\n### 手段が整っていないから「うちはリモートワークに向かない」と思い込んでいるケースも\n\n__佐々木__：自分のところはリモートに向いていない、というのを聞くことがありますが本当にそうなのか疑問に思うことはあります。手段が整っていないから、リモートワークが向いていないと感じているだけなのか、鶏と卵の関係のような問題だと思いますね。\n\nたとえばドキュメントが整備されていなかったり、情報が集まっていなかったりすれば、確認の作業が多くなります。『この場合って、どうすればいいんだっけ』という確認作業が、その都度必要になるときは同期的な速いコミュニケーションと相性がいいのです。その結果、同じ場所にいた方が効率はいいよねってことになります。\n\nそうして非リモートで常に同じ場所で仕事をしていると、速いコミュニケーションがより促進されるわけです。ドキュメントが残らず、その場限りのコミュニケーションになりがちで、リモートが合わないという風になってしまいます。リモートワークが向かない状況は、何が原因で作り出されているのかにフォーカスする必要がありますね。\n\n## 非同期コミュニケーションを改善するには？\n### 非同期コミュニケーションの難しさを認識したうえで、意識的に改善できるかどうかが課題\n![伊藤俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3736_resize.jpg)\n\n__伊藤__：リモートワークか否かは関係なく、非同期のコミュニケーションはどうしても比重が増すと思うのですね。ソフトウェアエンジニアでもマーケティングの広報担当でも、ペアプロや資料作りを他のメンバーとずっと一緒にやるということはありません。そのため、非同期のコミュニケーションをどうやってうまくやるかに着目する必要があるのです。\n\n同期のコミュニケーション自体は、皆さんもあんまり工夫せずにできると思います。しかし非同期につなげるため、同期した内容を残すという意味のドキュメンテーションが意識できていないことが多いのではないでしょうか。非同期のコミュニケーションをどう改善するかが、多くの組織における喫緊の課題のように思います。\n\n> ーー GitLabがリモートワークを成立させるうえで大切にされているSSOTとは何かを教えてください。\n\n### SSOTは信頼できる唯一の情報源\n__佐々木__：SSOTは『Single Source of Truth』の略語で、信頼できる唯一の情報源という意味の言葉です。普段仕事をしているなかで『この点に関する情報はこれが正しい』というのを、ひとつ持ちます。そうして、それに誰もが適切にアクセスできる状態にするのです。\n\n__伊藤__：たとえばどういうお金は会社の経費として申請してよくて、会計上のコードはこれですといった話がありますね。[GitLabでは、こういった情報をインターネット上のハンドブックにまとめて公開](https://handbook.gitlab.com/handbook/finance/expenses/)しているのです。そこに書いてあることが最も確からしく、議論の前提となる情報であるという信頼性があるのがSSOTになります。\n\nGitLabではハンドブックのほか、Google Docsに保存したミーティングノートやチケットなども利用している状況です。本当であれば全ての情報がハンドブックに集約できるとよいのですが、運用上それは現実的ではありません。\n\nここに正しい情報がある、という認識がみんな揃っていることが重要と考えています。たとえば交通費精算のルールがハンドブックにあるため、誰かに精算の基本ルールを何回も聞く必要はありません。\n\n### 「正しい情報がここにある」と社員の意識が向くことが大事\n![佐々木と伊藤](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3819_resize.jpg)\n\n__伊藤__：ハンドブックがあって、そこにSSOT性の高い情報が集約されていることが重要かと思います。SlackやZoom、チケットシステムを導入しても、ハンドブックのように情報を長期的かつ正しく保存する運用をしないと大人数での非同期コミュニケーションは難しいです。『ここに書いてあることが正』という情報としてハンドブックがあることで、みんなの意識がここへ向かうというのが重要かなと思います。\n\n> ーー 非同期コミュニケーション・同期コミュニケーションをどう使い分けているか教えてください。\n## 非同期・同期コミュニケーションはどう使い分ける？\n## 業務の枠組みが決まってくるなどしたら、非同期コミュニケーションへ移行を検討する\n\n__佐々木__：速いコミュニケーションは重要ですので、同期コミュニケーションも活用します。ある程度枠組みが決まってきたり分担して作業したりができるようになってから、非同期のコミュニケーションを検討するイメージです。非同期のコミュニケーションはスピードが劣るものの、情報を残してあとで確認することができます。\n\n### 同期のコミュニケーションはニュアンスを持たせやすい\n\n__佐々木__：Slackなどの文字上・非同期のコミュニケーションに比べ、同期のコミュニケーションはニュアンスを持たせやすいですね。ちょっと敏感な話をするときは、いきなりSlackでどーんとやるのでなく、Zoomで『そういえば、あれさ』という風に話すようにしています。\n\n> ーー 確かに文字ベースで厳しく注意されても、冷たく感じてしまうかもしれません。Zoomなど同期のコミュニケーションであれば、感情などのニュアンスを持たせられるのは分かります。\n全てにおいて、同期もしくは非同期のコミュニケーションが優れているわけではないということですね。コミュニケーションの特性や必要性を考えて、うまく使い分けることが重要ということでしょうか。\n\n__佐々木__：はい、そうですね。\n\n> ーー リモートワークが前提のGitLabにおいて、オンボーディングをどのように実践されているか教えてください。\n\n## オールリモート環境における効率的なオンボーディング\n### 数百のタスクが集まったチケットを自分のペースでこなす\n\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3707_resize.jpg)\n\n> ーー GitLabに入社したい、転職したいという方は、all-remoteの現場でどのようなオンボーディングが実施されているか気になると思います。\n\n__伊藤__：[GitLabのオンボーディング](https://handbook.gitlab.com/handbook/people-group/general-onboarding/)では、ベースとしてメンバーごとにチケットが作成され、そこに数百のタスクが箇条書きで記載されています。それらを1ヵ月程度の時間をかけてこなすという感じですね。\n\nたとえばPCのセットアップや、トレーニングビデオの視聴といったタスクが並んでいます。『ここを学んで欲しい』『PCのセットアップをする』など入社にあたって当たり前に必要となることがチケットにまとめてあるのです。これらをこなせば、自分で仕事がすすめられるまでになります。\n\n全員が同じオンボーディングを完了することで、同じスタートラインに立てるわけです。たとえばハンドブックのどのあたりにどのようなことが記載されているという感覚が身につき、あとから適切に参照できるようになります。\n\n> ーー オンボーディングの際に、トレーナーのような役割の方はつきますか？\n\n__伊藤__：はい、[トレーナー役の『バディ』](https://handbook.gitlab.com/handbook/people-group/general-onboarding/onboarding-buddies/)が新人につきます。ずっとつくというより、毎日1回、1対1で状況や困ったことがないかを確認するイメージです。\n\n## オールリモート環境における生産的なコミュニケーション法\n### チケットによるオンボーディングのよいところは、研修の全体像が可視化されること\n\n__伊藤__：この仕組みのいいところは、全体像がみえる点です。ほかの会社でもオンボーディングの際は、ドキュメントを渡されると思います。一方でGitLabのオンボーディングでは、あちこち見に行かなくてもチケットをみれば研修の全体像が把握できるのです。\nチケットの仕組みを使っているので、チケット内で質問したりバディが状況をチェックして適宜フォローしたりもできます。all-remoteでは新人も不安になりやすいですが、それを取り除ける施策だと思いますね。\n\n> ーー 作業に集中するための「フォーカスタイム」をどのように確保されているか教えてください。\n\n### フォーカスタイムを入れておけば、自動的にミーティングが拒否される\n\n__伊藤__：\nフォーカスタイムは、Googleカレンダーに適宜登録します。なかにはフォーカスタイムの自動登録が可能なツールを使っているメンバーもいますね。\n\nフォーカスタイムを入れておけば、自動的にミーティングは拒否されます。それでも必要に応じて入ってきてしまうこともあるのですが、フォーカスタイムをしない場合に比べ入りづらくなりますね。作業に集中する時間の確保が求められるソフトウェア開発や技術調査、プレゼン作成などをする必要があるメンバーにとって、フォーカスタイムは特に必要です。 \n\n> ーー 非同期コミュニケーションを円滑にするためにおこなっているという「Coffee Chat」について教えてください。\n### Coffee Chatはオフィスで日常的におこなわれる立ち話を代替する手段\n\n__伊藤__：[Coffee Chat](https://handbook.gitlab.com/handbook/company/culture/all-remote/informal-communication/#coffee-chats)は雑談することを目的としたミーティングで、Zoomを使っておこないます。Coffee Chatは、非同期を加速させる手段として推奨されていますね。\n\nSlack上だけのやりとりとなり、なかなか会えないという人は社内にたくさんいます。こういった人たちと同期コミュニケーションをすることで、非同期のコミュニケーションを加速させるわけです。 \n\nただCoffee Chatは、どちらかというとall-remoteのデメリットを表しているとも思います。all-remoteでは、オフィスで日常的におこなわれるような立ち話はできません。立ち話で普通に話す方が、もっとスムーズに雑談ができるわけです。\n\nそういった観点では、Coffee Chatは立ち話の下位互換だとは思います。all-remoteで立ち話の役割を補助するのが、Coffee Chatの仕組みです。\n\n__佐々木__：普通のオフィスであれば、コーヒーを飲みにコーヒーサーバーの周りに集まって偶発的なコミュニケーションが生まれることがありますね。それをオンラインでできないか、というのがCoffee Chatのコンセプトだと理解しています。\n\nコーヒーサーバーのところで、たまたま顔を合わせた人とコミュニケーションをとるような、ランダムさが重要だと思うのです。たとえば、たまたまコーヒーサーバーのところで、隣の部署の人と顔を合わせることがありますね。そのとき『そういえばキャンプ好きでしたよね』といった何気ない会話で、雑談がはじまったりもします。\n\nそういった雑談で、繋がりができる良さがあると思いますね。困ったときに『そういえばマーケティング部門に、この前話した人がいたから相談してみよう』みたいなことがあります。\n\n僕はそういったランダムさが好きで、週1回ツールで自動的にマッチングされた人とCoffee Chatをしていますね。\n\n> ーー ふたりをはじめ、GitLabの皆さんがどのようにリモートワークを実践されているか伺いたいと思います。\u003Cbr>\n> 普段はどこでお仕事をされていますか？\n\n![伊藤俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3876_resize.jpg)\n\n__伊藤__：自宅で仕事をすることが多いです。海外や国内の出張時にはホテルのなかで仕事をしています。モバイルディスプレイを持ち込んで、自宅の環境となるべく遜色のないように工夫していますね。\n\n> ーー ワーケーションをされている方はいらっしゃいますか？\n\n__伊藤__：我々はロール的に対面でお客様と打ち合わせをする機会が多いので難しいですが、ロールによってはかなりしていますね。\n\nたとえばテクニカルサポートエンジニアは、メールベースで回答して時々Zoomでお客様と打ち合わせするといった感じなのでしやすいと思います。たとえば、シンガポール在住のサポートエンジニアがワーケーションとして日本に来るとか、そういったことができる環境は整備されています。\n\n__佐々木__：\nワーケーションとまではいかなくても、僕はリモートワークの良さを活用する意味で時間を有効活用するようにしています。\n\nたとえば2時間ほど隙間時間ができたら、休日だと混んでいる美術館へ行くとか髪を切りに行くなどして、その時間分は朝少し早く起きて仕事したり、夜にやって調整などをしていますね。そういう融通がきくという点は一部のエンジニアにとって福利厚生というか魅力だと思いますので、僕はあえてXに投稿したりしています。\n\nもちろん『本当はこの時間に打ち合わせをしたかったのに、いなかったからできなかった』といったような迷惑がかからないようにはしていますね。\n\n> ーー 仕事をする時間は決まっていますか？個人の裁量に委ねられているのでしょうか？\n\n__伊藤__：契約上は何時間働くなど最低限の決まりはありますが、基本的には個人の裁量に任せられていますね。たとえば我々はお客様対応が中心なので、それが滞りなく進められていれば良いということになります。\n\n__佐々木__：\nサポートエンジニアやSREの人などにはオンコール体制があり、その時間はトラブルや問い合わせに対応できるようにしないといけないというのはあります。ただ、それも毎日ずっとというわけではないので、ある程度柔軟にはできると思います。\n\n> ーー 他企業がリモートワークに失敗している原因について、ご意見をお聞かせください。\u003Cbr>\n> リモートワークでコミュニケーション不足になったり生産性が低下したりして、リモートワーク導入が失敗している企業が少なくありません。これらの原因について、ご意見をお聞かせいただければと思います。\n\n__伊藤__：リモートワークでは、コミュニケーション不足は絶対的に起こるので、工夫するしかないですね。たとえば会社の文化にも依存するのですが、オンライン会議などでカメラをオンにしない方もいます。そういった点も、コミュニケーション不足の原因になっているのではないかと思いますね。\n\n> ーー カメラは重要でしょうか？\n\n__伊藤__：はい。Coffee Chatのときも含め、GitLabでは全員ではないもののほとんどの人がカメラをつけています。カメラをつけるかつけないかで、Zoomでコミュニケーションをとるときなどの情報量も違いますね。\n\nコミュニケーション不足は避けられないにしても、その不足を補うという点でカメラをオンにするのは重要だと思います。\n\n> ーー コミュニケーションの工夫という点では、GitLab様の文化で素晴らしいと思った点があります。オンライン会議などでお子さんや飼い犬が映っても、それを悪とせずコミュニケーションのきっかけにするということですね。こういった文化も、GitLab様でコミュニケーション不足を防ぐ意味で有効かなと思いました。が起きにくい理由かなと思いました。\n\n__伊藤__：ミーティングの質にもよりますが、割と社内で許容されていますね。\n\n> ーー リモートワークにして生産性が低下した、という企業も存在するようですが、どう思われますか？\n\n__伊藤__：特にオフィスがある状態からの予期せぬ社会的変化によるリモートワークの強制導入においては、そのように感じる背景はよく理解できるが、そもそも本当にリモートワークの実施前後で生産性を測っているのかは気になりますね。何となくの印象で『生産性が落ちた』と言われていることも多いのではと考えています。特にマネジメント側からすると、リモートワークでは従業員の顔が見えず何をしているかわかりません。それで、『生産性が下がった』と感じていることもあると思います。単にチャットツールを多用するだけではない非同期コミュニケーションにおける工夫やドキュメント化を徹底的に推進してもやはりだめだったのかについて気になります。\n\n> ーー ソリューションアーキテクトという職種について教えていただきたいと思います。\u003Cbr>\n> まずはソリューションアーキテクトの職務範囲について教えてください。\n\n## GitLabのソリューションアーキテクトの役割とスキル\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3907_resize.jpg)\n\n__佐々木__：[厳密な定義はHandbookに記載](https://handbook.gitlab.com/job-families/sales/solutions-architect/)されていますが、ここではもう少し主観的に紹介しますね。ソリューションアーキテクトには、仕事の方向性が大きく分けて3つあると考えます。\n\nひとつ目はお客様に向けた方向性で、これは一番重要で割合の大きな部分だと考えます。ソリューションアーキテクトは単に技術営業として製品を紹介したり、デモをしたりするだけではありません。\n\nお客様の組織やプロセスをよく観察し、ときにはお客様自身も気付いていない課題やその解決策を提示・提案する活動があります。この活動には自社製品の知識だけでなく、開発手法・クラウドネイティブ技術・プロジェクトマネジメントといったスキルも必要です。ソリューションアーキテクトの個性や強みが活きる領域だと思いますね。\n\nふたつ目は社内です。社内に対しても、ソリューションアーキテクトの価値を発揮できるチャンスがあります。たとえば営業メンバーに対し、製品の新機能が持つ価値や解決可能な課題を説明し全員が概念として扱えるようにするイネーブルの要素です。\n\n個人的にはこういう仕事も好きで、社内でGeneral (Yorozu) Discussion Lunch Chatという場を週1回運営しています。General (Yorozu) Discussion Lunch Chatでは昼ご飯を食べながら、メンバーが質問し合ったり情報をシェアしたりするのです。\n\n最後はマーケット全体に向けた方向性になります。たとえばDevSecOpsの取り組みについては認知度が高まってきているとはいえ、十分とはいえません。クラウド技術のように先行して広まった概念に比べると一般化しているとは言えず、まだまだ知ってもらう必要があると思っています。イベント登壇やマーケティング組織と連携してのコンテンツ作成といった手法で、認知度向上に努めるのも重要な仕事ですね。\n\nこのようにソリューションアーキテクトには、やるべきことがたくさんあるとは言えるでしょう。ただ個人的には、走り回れるホワイトスペースが多くて非常にやりがいがあり楽しく感じています。\n\n> ーー ソリューションアーキテクトに英語スキルはどのくらい必要ですか？\n\n__佐々木__：もちろん英語スキルが高ければ高いほどいいのですが、いくつかの観点でお答えできればと思います。\n\n__伊藤__：自分は経験的に入社時期と組織の規模に大きく相関すると考えています。日本で採用される場合、日本にいる関連するロールでのチームメンバーが増えるにつれて、英語の必要性が少しずつ減っていくことを、他社での経験も含めて、体感しました。\n\n> ーー どういった場面で必要になりますか？\n\n__佐々木__：日常的に英語を読み書きするシーンはありますが、AIやツールの使いやすいところではあります。一番地力が必要になるのは、対面で会話する必要があるシーンですね。定例のような事前準備がしやすいシーンでなく、初めて対面するお客様や海外支社のメンバーと話すシーンでは特に英語力が求められます。\n\n> ーー TOEICスコアなどは関係がありますか？\n\n__佐々木__：よく『TOEIC L&Rテストの点がよくても英語で活躍できるわけじゃない』『TOEIC  L&Rテストはスピーキングがないので意味がない』という説も聞きます。しかし、そもそも聞けないと答えられないので、リスニングパートについては関係があると思いますね。リーディングはツールの活用でなんとかなるケースもあると思います。\n\n__伊藤__：AIを翻訳領域で活用すれば、英語で会話できる必要はなくなるという意見も耳にします。しかし、たとえAIベースの翻訳ツールが今後さらに進化したとしても、翻訳処理の遅延が完全になくなることはありません。\nまた、ビジネスでもプライベートでも、AI翻訳を介した会話で本当に人間関係を築けるのかには疑問が残ります。たとえば、海外のメンバーを含む社内のアクティビティや食事に参加したとき、自分だけが翻訳デバイスを使っていたら、意図せずとも他のメンバーから声をかけられる機会が減ることは容易に想像できると思います。\n\n上級レベルの英語運用力が測れない欠点はあるものの、私はTOEICは客観的に英語力を図るひとつの手段と考えます。外資系ソフトウェアベンダーの世界に入る前に、TOEIC L&Rテストと並行してTOEIC S&Wテストも受け、自分の英語での会話力向上に継続的に取り組んできました。\n\n> ーー 英語スキルを向上させるために、どんな努力をしていますか？\n\n__佐々木__：GitLabでは業務の必要に応じ、研修やトレーニングを受けるための費用を年間＄10,000ほど支援してくれます。この支援を活用して、英会話などの研修を受けたりアプリを利用したりといったことをかなりしましたね。あとは積極的に海外のメンバーとCoffee Chatをして、英語力を磨いています。\n\n> ーー 入社時に比べ、英語をつかうのには慣れましたか？\n\n__佐々木__：GitLab入社前は英語を使う環境はなかったので、本当に不安だった記憶があります。今では社内のメンバーであれば、何とかなるだろうという気持ちは持てるようになりました。\n\n社内メンバーなら最悪何回か聞き直したり、表現を変えて話し直したりすることができますからね。ただ、お客様相手ではそれができずまだ緊張するので、継続して英語力向上に取り組んでいく必要があると思っています。\n\n> ーー ソリューションアーキテクトのお仕事をする際の、よくある1日のスケジュールを教えてください。\n\n__佐々木__：以下のような感じですね。\n    \u003Ctable>\n        \u003Cthead>\n            \u003Ctr>\n                \u003Cth width=\"100\">時間\u003C/th>\n                \u003Cth>イベント\u003C/th>\n            \u003C/tr>\n        \u003C/thead>\n        \u003Ctbody>\n            \u003Ctr>\n                \u003Ctd>08:00\u003C/td>\n                \u003Ctd>下の子を幼稚園のバス停まで送る。\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>09:00\u003C/td>\n                \u003Ctd>位置情報ゲーム（Ingress）をしながら帰宅。その後、コーヒーを飲みながら業務開始。\u003Cbr>\n                午前中は打ち合わせがなく、集中して技術検証と新規ハンズオンのコンテンツ作成をおこなう。\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>13:00\u003C/td>\n                \u003Ctd>昼食を食べながら、同僚とZoomで製品の新機能について議論\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>14:00\u003C/td>\n                \u003Ctd>新規のお客様とディスカバリーミーティング*\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>15:30\u003C/td>\n                \u003Ctd>APAC SA Weekly Call（定例）で最近の案件について共有\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>17:00\u003C/td>\n                \u003Ctd>上の子を習い事まで送り、近くのコワーキングスペース（個室）を借りてオンライン英会話と仕事\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>19:00\u003C/td>\n                \u003Ctd>習い事が終わった子どもを迎えに行って帰宅\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>20:00\u003C/td>\n                \u003Ctd>夕食をすませ子どもと遊ぶ\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>22:00\u003C/td>\n                \u003Ctd>なんだかんだ気になって、Slackなどで仕事の対応をしてしまう（良くない日）\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>24:00\u003C/td>\n                \u003Ctd>就寝\u003C/td>\n            \u003C/tr>\n        \u003C/tbody>\n    \u003C/table>\n\n＊ディスカバリーミーティング：顧客の業務プロセス、要件、課題を深く理解し、効果的なソリューション設計のための情報を収集する初期段階の重要な会議\n\n> ーー ありがとうございました。\n\n> [GitLabで募集中のポジションはこちら](https://about.gitlab.com/jobs/all-jobs/)","culture",[1880],{"slug":2138,"featured":92,"template":681},"tips-for-async-communication","content:ja-jp:blog:tips-for-async-communication.yml","Tips For Async Communication","ja-jp/blog/tips-for-async-communication.yml","ja-jp/blog/tips-for-async-communication",{"_path":2144,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2145,"content":2151,"config":2160,"_id":2162,"_type":16,"title":2163,"_source":17,"_file":2164,"_stem":2165,"_extension":20},"/ja-jp/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"title":2146,"description":2147,"ogTitle":2146,"ogDescription":2147,"noIndex":6,"ogImage":2148,"ogUrl":2149,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2149,"schema":2150},"共同開発プログラム：ユーザーとともに築くGitLab","Thales社、Scania社、Kitware社などの組織がどのようにGitLabのエンジニアと連携し、コミュニティ全体に利益をもたらす重要な機能の開発にコントリビュートしているかをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","https://about.gitlab.com/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"共同開発プログラム：ユーザーとともに築くGitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2025-01-30\",\n      }",{"title":2146,"description":2147,"authors":2152,"heroImage":2148,"date":2154,"body":2155,"category":2156,"tags":2157,"updatedDate":2159},[2153],"Fatima Sarah Khalid","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","customer-stories",[2158,825,762],"contributors","2025-03-10",{"slug":2161,"featured":92,"template":681},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab","content:ja-jp:blog:the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","The Co Create Program How Customers Are Collaborating To Build Gitlab","ja-jp/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","ja-jp/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"_path":2167,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2168,"content":2174,"config":2182,"_id":2184,"_type":16,"title":2185,"_source":17,"_file":2186,"_stem":2187,"_extension":20},"/ja-jp/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"ogTitle":2169,"schema":2170,"ogImage":2171,"ogDescription":2172,"ogSiteName":1223,"noIndex":6,"ogType":1244,"ogUrl":2173,"title":2169,"canonicalUrls":2173,"description":2172},"コードから本番環境へ：GitLabを活用した継続的デプロイのガイド","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"コードから本番環境へ：GitLabを活用した継続的デプロイのガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Benjamin Skierlak\"},{\"@type\":\"Person\",\"name\":\"James Wormwell\"}],\n        \"datePublished\": \"2025-01-28\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","GitLabを活用して堅牢な継続的デプロイパイプラインを構築する方法をご紹介します。具体的な手順や例、ベストプラクティスを通して段階的にプロセスを理解できます。","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"heroImage":2171,"body":2175,"authors":2176,"updatedDate":2179,"date":2180,"title":2169,"tags":2181,"description":2172,"category":701},"継続的デプロイは、チームがより迅速かつ高い信頼性で価値を生み出せる画期的な手法です。しかし、GitOpsやKubernetesを用いたコンテナオーケストレーション、動的環境などの高度なデプロイワークフローに取り組むのは、継続的デプロイの導入を始めたばかりのチームにとってはハードルが高いと感じられるかもしれません。\n\n\nGitLabでは、シームレスかつスケーラブルなデリバリーを実現することに注力しています。チームが基本に集中できるようにすることで、時間をかけてより複雑な戦略へと発展できる、強固な基盤を構築できます。このガイドでは、GitLabを活用した継続的デプロイの導入に必要な基本的なステップを紹介し、長期的な成功のための土台作りをサポートします。\n\n\n## まずはワークフローの計画から\n\n\n技術的な実装に入る前に、デプロイワークフローをしっかりと設計する時間を取りましょう。成功の鍵は、慎重な計画と体系的なアプローチにあります。\n\n\n### アーティファクト管理戦略\n\n\n継続的デプロイにおいて、アーティファクトとは、ビルドプロセスによって生成されるパッケージ化された成果物を指し、保存、バージョン管理、デプロイが必要です。アーティファクトには、次のようなものが含まれます。\n\n\n* アプリケーション用のコンテナイメージ\n\n* パッケージ\n\n* コンパイル済みのバイナリや実行ファイル\n\n* ライブラリ\n\n* 設定ファイル\n\n* ドキュメントパッケージ\n\n* その他のアーティファクト\n\n\n各アーティファクトは、デプロイプロセスにおいて特定の役割を果たします。たとえば、一般的なWebアプリケーションでは、次のようなアーティファクトが生成されることがあります。\n\n\n* バックエンドサービス用のコンテナイメージ\n\n* コンパイル済みフロントエンドアセットのZIPアーカイブ\n\n* データベース変更用のSQLファイル\n\n* 環境ごとの設定ファイル\n\n\nアーティファクトの適切な管理はデプロイを成功させる鍵となります。ここからは、アーティファクト管理のアプローチについて詳しく見ていきましょう。\n\n\n#### アーティファクトとリリースのバージョニング戦略\n\n\nクリーンで整理された構造を保つためのベストプラクティスとして、アーティファクトの明確なバージョニング戦略を確立することが重要です。リリース作成時のポイントは以下のとおりです。\n\n\n* リリースタグにセマンティックバージョニング（major.minor.patch）を使用する\n\n  * 例：安定版リリースが`myapp:1.2.3`の場合\n  * 破壊的な変更がある場合は、メジャーバージョン変更（2.0.0）\n  * 新機能を追加する場合は、マイナーバージョン変更（1.3.0）\n  * バグ修正を行う場合は、パッチバージョン変更（1.2.4）\n* 最新の安定版を示す「latest」タグを維持する\n\n  * 例：`myapp:latest`（自動デプロイ用）\n* コミットSHAを含めることで、正確なバージョン追跡を行う\n\n  * 例：`myapp:1.2.3-abc123f`（デバッグ用）\n* 開発環境向けにブランチベースのタグを使用する\n\n  * 例：`myapp:feature-user-auth`（新機能テスト用）\n\n#### ビルドアーティファクトの保持\n\n\n明確な保持ルールを実装しましょう。\n\n\n* 一時的なアーティファクトの明確な有効期限を設定する\n\n* 永続的に保持する必要があるアーティファクトを定義する\n\n* ストレージ管理のためのクリーンアップポリシーを設定する\n\n\n#### レジストリアクセスと認証\n\n\n適切なアクセス制御でアーティファクトのセキュリティを確保しましょう。\n\n\n* デベロッパーのアクセス用にパーソナルアクセストークンを実装する\n\n* パイプラインの認証にCI/CD変数を設定する\n\n* 適切なアクセススコープを設定する\n\n\n### 環境戦略\n\n\n環境設計はデプロイパイプライン全体の構成に影響を与えるため、早い段階で検討しましょう。\n\n\n* 開発、ステージング環境、本番環境の設定\n\n* 環境ごとの変数とシークレットの管理\n\n* アクセス制御と保護ルールの設定\n\n* デプロイの追跡とモニタリングのアプローチ\n\n\n### デプロイターゲット\n\n\nどこに、どのようにデプロイするのかを慎重に検討しましょう。これらの決定は重要であり、それぞれのメリットとデメリットを考慮する必要があります。\n\n\n* インフラ要件（仮想マシン、コンテナ、クラウドサービス）\n\n* ネットワークアクセスとセキュリティ設定\n\n* 認証メカニズム（SSH鍵、アクセストークン）\n\n* リソースの割り当てとスケーリングの考慮\n\n\nこれで戦略が定まり、基盤となる決定が完了したので、これらの計画を実際に動作するパイプラインに落とし込んでいきます。それでは、実際に機能する例を作ることで概念を深掘りしていきましょう。まずはシンプルなアプリケーションから始め、徐々にデプロイの機能を追加していきます。\n\n\n## CDパイプラインの実装\n\n\n### 具体的な手順\n\n\nWebアプリケーション向けの基本的な継続的デプロイ（CD）パイプラインの実装手順を順を追って説明します。例としてシンプルなHTMLアプリケーションを使用しますが、ここで紹介する原則はどのタイプのアプリケーションにも応用できます。今回は、アプリケーションをDockerイメージとしてパッケージ化し、シンプルな仮想マシン上にデプロイします。これにより、最小限の依存関係を持つ厳選されたイメージを活用し、環境依存の要件が意図せず混入するのを防ぐことができます。また、仮想マシン上で動作させることで、GitLabのネイティブなインテグレーション機能を活用しない設定となります。複雑で本格的な環境ではなく、理解しやすい簡易的な環境から始めてみましょう。\n\n\n#### 前提条件\n\n\nこの例では、クラウドプロバイダーの仮想マシン上で実行するアプリケーションをコンテナ化することを目指します。また、ローカル環境でもこのアプリケーションをテストします。以下の前提条件は、このシナリオにおいてのみ必要なものです。\n\n\n##### [仮想マシン（VM）](https://about.gitlab.com/ja-jp/blog/what-is-vm/)のセットアップ\n\n\n* お好みのクラウドプロバイダーで[VM](https://about.gitlab.com/ja-jp/blog/what-is-vm/)をプロビジョニングします（例：GCP、AWS、Azure）\n\n* ネットワークルールを設定し、ポート22、80、443へのアクセスを許可します\n\n* デプロイ用にマシンのパブリックIPアドレスを記録します\n\n\n##### SSH認証のセットアップ：\n\n\n* マシン用の公開鍵と秘密鍵のペアを生成します\n\n* GitLabで**設定 > CI/CD > 変数**を開きます\n\n* `GITLAB_KEY`という変数を作成します\n\n* タイプを「ファイル」に設定します（SSH認証に必須）\n\n* 秘密鍵を「値」フィールドに貼り付けます\n\n* 「ユーザー」変数を定義します（VMにログインしてスクリプトを実行するユーザー）\n\n\n##### デプロイ変数の設定\n\n\n* デプロイターゲット用の変数を作成します\n\n  * `STAGING_TARGET`：ステージング環境のサーバーIPまたはドメイン\n  * `PRODUCTION_TARGET`：本番環境のサーバーIPまたはドメイン\n\n##### ローカル開発環境のセットアップ\n\n\n* デプロイのテスト用に、ローカルマシンにDockerをインストールします\n\n\n##### GitLabコンテナレジストリへのアクセス\n\n\n* レジストリパスを確認します：\n\n  * **デプロイ > コンテナレジストリ**を開きます\n  * レジストリパスをコピーします（例：registry.gitlab.com/group/project）\n* 認証の設定：\n\n  * **設定 > アクセストークン**を開きます\n  * レジストリアクセス権を持つ新しいトークンを作成します\n  * トークンの有効期限を最大1年に設定します\n  * トークンを安全に保存します\n* ローカルレジストリのアクセス設定：\n\n\n```\n\ndocker login registry.gitlab.com\n\n\n# パーソナルアクセストークンを使用する場合のユーザー名はgitlab-ci-tokenです\n\n\n# Password:（ここにアクセストークンを入力）\n\n```\n\n\n#### 1. アプリケーションを作成する\n\n\n基本的なWebアプリケーションから始めましょう。今回の例では、シンプルなHTMLページを使用します。\n\n\n```\n\n\u003C!|||UNTRANSLATED_CONTENT_START|||-- index.html -->\n\n\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!|||UNTRANSLATED_CONTENT_END|||-- ここにコンテンツを追加 -->\n  \u003C/body>\n\u003C/html>\n\n```\n\n\n#### 2. アプリケーションをコンテナ化する\n\n\nアプリケーションをパッケージ化するために、Dockerfileを作成します：\n\n\n```\n\nFROM nginx:1.26.2\n\n\nCOPY index.html /usr/share/nginx/html/index.html\n\n```\n\n\nこのDockerfileは\n\n\n* nginxをベースイメージとして使用し、Webコンテンツを配信できるようにします\n\n* 作成したindex.htmlをnginxのディレクトリ構造内の適切な場所にコピーします\n\n\n#### 3. CI/CDパイプラインを設定する\n\n\nGitLabのパイプラインステージを定義するために、`.gitlab-ci.yml`ファイル を作成します：\n\n\n```\n\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\n\n解説：\n\n\n`TAG_LATEST`は、次の3つの要素で構成されています：\n\n\n* `$CI_REGISTRY_IMAGE`：GitLabのプロジェクトのコンテナレジストリのパス\n\n\n例：`registry.gitlab.com/your-group/your-project`\n\n\n* `$CI_COMMIT_REF_NAME`：ブランチ名またはタグ名\n\n\n例：ブランチの場合は`/main`、フィーチャーブランチの場合は`/feature-login`\n\n\n* `:latest`：固定のサフィックス\n\n\nこれにより、mainブランチの`TAG_LATEST`は次のようになります：`registry.gitlab.com/your-group/your-project/main:latest`\n\n\n`TAG_COMMIT`は`TAG_LATEST`とほぼ同じですが、`:latest`の代わりにコミット識別子の`$CI_COMMIT_SHA`を使います。例：`:abc123def456`\n\n\nしたがって、同じmainブランチでの`TAG_COMMIT`は次のようになります：`registry.gitlab.com/your-group/your-project/main:abc123def456`\n\n\n両方のタグを使用する理由は、`TAG_LATEST`が常に最新バージョンを取得しやすくするのに対し、`TAG_COMMIT`は必要に応じて特定のバージョンに戻れるようにするためです。\n\n\n#### 4. コンテナレジストリに公開する\n\n\nパイプラインに公開ジョブを追加します：\n\n\n```\n\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\n\nこのジョブは\n\n\n* Docker-in-Dockerを使用してイメージをビルドします\n\n* 2つのタグを付けたイメージを作成します\n\n* GitLabレジストリへの認証を行います\n\n* 両方のイメージをレジストリにプッシュします \n\n\nこれで、コンテナイメージが安全にレジストリに保存されました。次は、ターゲット環境へのデプロイを進めていきます。本番環境へ移行する前に、まずローカル環境でテストを行い、設定が正しく機能していることを確認しましょう。 \n\n\n#### 5. 環境へデプロイする\n\n\n本番環境にデプロイする前に、ローカル環境でテストできます。先ほどGitLabレジストリにイメージを公開したので、それをローカル環境でプルしてテストします。コンテナイメージのパスが分からない場合は、GitLabの\\*\\*デプロイ\n\n\n> コンテナレジストリ\\*\\*に移動し、該当のコンテナイメージの行末にあるアイコンをクリックすると、パスをコピーできます。\n\n\n```\n\ndocker login registry.gitlab.com \n\n\ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n\n```\n\n\nこれにより、Webブラウザからlocalhostにアクセスし、ローカル環境でアプリケーションを確認できるようになります。\n\n\nそれでは、パイプラインにデプロイジョブを追加しましょう：\n\n\n```\n\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER \n      docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\n\nこのジョブは\n\n\n* デプロイ先のサーバーへのSSHアクセスを確立します\n\n* 最新のコンテナイメージをプルします\n\n* 既存のコンテナを削除します\n\n* 新しいバージョンのコンテナをデプロイします\n\n\n#### 6. デプロイを追跡する\n\n\n環境設定を追加してデプロイの追跡を有効にします：\n\n\n```\n\ndeploy:\n  environment:\n    name: production\n    url: https://your-application-url.com \n```\n\n\nこれにより、GitLabの**オペレーション > 環境**セクションに環境オブジェクトが作成され、以下の情報が提供されます：\n\n\n* デプロイ履歴\n\n* 現在のデプロイ状況\n\n* アプリケーションへのクイックアクセス\n\n\n単一の環境向けのパイプラインは、最初のステップとしては有効ですが、ほとんどのチームでは適切なテストやステージングを行うために複数の環境を管理する必要があります。このより実践的なシナリオに対応するために、パイプラインを拡張していきましょう。\n\n\n#### 7. 複数環境をセットアップする\n\n\nより堅牢なパイプラインを構築するために、ステージング環境と本番環境のデプロイを設定します：\n\n\n```\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # デプロイスクリプトを記述\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # デプロイスクリプトを記述\n```\n\n\nこの設定は\n\n\n* mainブランチからステージ環境へデプロイします\n\n* GitLabのタグを利用して本番環境へのデプロイをトリガーします\n\n* 環境ごとに分けてデプロイの状況を管理できるようにします\n\n\nこのステップと次のステップでは、GitLabの非常に便利な機能であるタグを活用しています。GitLabの**コード >\n\nタグ**セクションで手動でタグを作成すると、'$ CI_COMMMIT_TAG\n\n`変数が設定され、本番環境へのデプロイジョブが適切にトリガーされるようになります。\n\n\n#### 8. 自動リリースノートを作成する\n\n\nCI/CDパイプラインを通じてGitLabのリリース機能を使用します。まず、`.gitlab-ci.yml`のstagesを更新 します：\n\n\n```\n\nstages:\n\n\n\n- publish\n\n\n- staging\n\n\n- release # New stage for releases\n\n\n- version\n\n\n- production\n\n```\n\n\n次に、リリースジョブを追加します：\n\n\n```\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # タグが作成された場合のみ実行する\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # リリース設定\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # タグを作成する\n    ref: '$CI_COMMIT_TAG'                # リリースのベースとなるタグ\n```\n\n\nコンテナイメージのリンクを追加することで、さらに内容を充実させることができます：\n\n\n```\n\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\n\nコミットメッセージに基づいて自動リリースノートを生成する場合は次のようにします：\n\n\n```\n\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release notes for version $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  auto_generate_release_notes: true    # Enables automatic notes\n```\n\n\n自動リリースノートを充実させるには\n\n\n* 規則的なコミットメッセージを使用する（例：feat:, fix:）\n\n* イシュー番号を含める（例：#123）\n\n* 件名と本文の間に空行を入れる\n\n\nデプロイ時の情報をリリースノートに記載したい場合は、以下のように設定できます：\n\n\n```\n\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## デプロイ情報\n      - デプロイ日時: $DEPLOY_TIME\n      - 環境: 本番環境\n      - バージョン: $CI_COMMIT_TAG\n\n      ## 変更内容\n      $CHANGES\n\n      ## アーティファクト\n      - コンテナイメージ: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\n\nこの設定を行うと、Gitタグの作成時に自動でリリースが作成されるようになります。作成されたリリースは、GitLabの**デプロイ >\n\nリリース**で確認できます。\n\n\n#### 9. すべてをまとめる\n\n\n最終的なYAMLファイルは以下のようになります：\n\n\n```\n\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # CI/CD変数で設定\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # CI/CD変数で設定\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# ビルドとレジストリへの公開\n\n\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# stagingへデプロイ\n\n\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# リリースの作成\n\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## デプロイ情報\n      - デプロイ日時：$DEPLOY_TIME\n      - 環境：本番環境\n      - バージョン：$CI_COMMIT_TAG\n\n      ## 変更内容\n      $CHANGES\n\n      ## アーティファクト\n      - コンテナイメージ：\\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'コンテナイメージ'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# リリースタグ付きのバージョンを作成\n\n\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# 本番環境へデプロイ\n\n\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\n\n完成したパイプラインは\n\n\n* mainブランチでの変更をレジストリに公開します\n\n* mainブランチでの変更をstagingへデプロイします\n\n* タグが作成された際にリリースを作成します\n\n* リリースタグを付けたイメージを作成します\n\n* タグを基に本番環境へデプロイします\n\n\n主なメリット：\n\n\n* クリーンで再現性のあるローカル開発およびテスト環境が完成します\n\n* 構造化された本番環境へのデプロイフローにより、信頼性の高いデプロイを実現できます\n\n* 予期しない障害からの復旧パターンを確立します\n\n* より複雑なデプロイ戦略への拡張/導入に対応できます\n\n*\n\n\n### ベストプラクティス\n\n\n実装の際は、以下の原則を守りましょう：\n\n\n* 変数の使用方法からデプロイ手順まで、すべてを文書化する\n\n* GitLabのビルトイン機能（環境管理、リリース、レジストリ）を活用する\n\n* 適切なアクセス制御とセキュリティ対策を実施する\n\n* 強固なロールバック手順を計画し、障害に備える\n\n* パイプラインの設定はDRY（Don't Repeat Yourself：重複を避ける）を意識する\n\n\n## デプロイ戦略をスケールさせる\n\n\n次は何をすべきでしょうか？ここでは、継続的デプロイ戦略をさらに成熟させるために、検討すべきポイントを紹介します。\n\n\n### 高度なセキュリティ対策\n\n\n以下の方法でセキュリティを強化しましょう：\n\n\n* アクセスを制限した保護環境を設定する\n\n* 本番環境へのデプロイに承認を必須とする\n\n* セキュリティスキャンをパイプラインに統合する\n\n* 自動脆弱性評価を導入する\n\n* デプロイ関連の変更に対するブランチ保護ルールを適用する\n\n\n### 段階的なデリバリー戦略\n\n\n以下のような高度なデプロイ戦略を実装しましょう。\n\n\n* 機能フラグを活用して制御されたロールアウトを行う\n\n* リスクを軽減するためにカナリアデプロイを実施する\n\n* ブルーグリーンデプロイ戦略を導入する\n\n* A/Bテストを実施する\n\n* 動的環境管理を行う\n\n\n### モニタリングと最適化\n\n\n強固なモニタリング体制を確立しましょう：\n\n\n* デプロイ指標を追跡する\n\n* パフォーマンスモニタリングをセットアップする\n\n* デプロイアラートを設定する\n\n* デプロイのサービスレベル目標（SLO）を確立する\n\n* 定期的にパイプラインを最適化する\n\n\n## GitLabが選ばれる理由\n\n\nGitLabの継続的デプロイ機能は、現代のデプロイワークフローに最適です。GitLabは、コンテナレジストリ、環境管理、デプロイ追跡などの機能が1つのインターフェースに集約されており、コードから本番環境へのプロセスを効率化します。また、環境ごとの変数、デプロイ承認ゲート、ロールバック機能を備えており、本番環境へのデプロイ時に求められるセキュリティと管理を実現します。さらに、Review\n\nApps（レビューアプリ）や機能フラグを活用することで、段階的なデリバリー（プログレッシブデリバリー）戦略も可能です。GitLabのDevSecOpsプラットフォームの一部として、これらのCD機能はソフトウェアライフサイクル全体とシームレスに連携します。\n\n\n## 無料トライアルで今すぐスタート！\n\n\n継続的デプロイへの道のりは、革命ではなく進化のプロセスです。まずは基本を押さえ、しっかりとした基盤を築き、チームの成長に応じて徐々に高度な機能を取り入れていきましょう。GitLabは、最初の自動デプロイから、複数環境にまたがる複雑なデリバリーパイプラインまで、あらゆる段階でサポートするためのツールと柔軟性を提供します。 \n\n\n> [GitLab\n\n> Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/devsecops/)で、今日から継続的デプロイメントを始めましょう。\n\n\n\u003Cbr>\u003Cbr>\n\n\n\\*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n\n\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[2177,2178],"Benjamin Skierlak","James Wormwell","2025-06-11","2025-01-28",[1411,110,678,701,676],{"slug":2183,"featured":6,"template":681},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","content:ja-jp:blog:from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab","ja-jp/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","ja-jp/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"_path":2189,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2190,"content":2196,"config":2202,"_id":2204,"_type":16,"title":2205,"_source":17,"_file":2206,"_stem":2207,"_extension":20},"/ja-jp/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"title":2191,"description":2192,"ogTitle":2191,"ogDescription":2192,"noIndex":6,"ogImage":2193,"ogUrl":2194,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2194,"schema":2195},"GitLab入門：プロジェクトをGitLabにインポートする方法","Bitbucket、Gitea、GitHub、GitLab Self-Managedなど、さまざまなソースからプロジェクトをインポートする方法についてご説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097248/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097247785.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab入門：プロジェクトをGitLabにインポートする方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-28\",\n      }",{"title":2191,"description":2192,"authors":2197,"heroImage":2193,"date":2180,"body":2199,"category":701,"tags":2200,"updatedDate":2201},[2198],"Abubakar Siddiq Ango","*「GitLab入門」シリーズへようこそ！このシリーズでは、GitLab\nDevSecOpsプラットフォームを初めて使う方に向けて、基本的な使い方を解説します。*\n\n\nGitLab\nDevSecOpsプラットフォームを最大限に活用するためには、プロジェクトのインポート方法を理解することがきわめて重要です。[アカウントのセットアップ](https://university.gitlab.com/pages/getting-started)、ユーザーの招待、ユースケースやチーム構成に応じたユーザーの[整理](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)が完了したら、次は既存のプロジェクトをGitLabに取り込み、コラボレーションを開始します。これらのプロジェクトは、コンピューター上のローカルファイルでも、別のソースコード管理プラットフォームでホストされているものでも構いません。それでは、それぞれのインポート方法を見ていきましょう。\n\n\n## ローカルプロジェクトファイルをインポートする\n\n\n新しいプロジェクトを作成するたびに、一から始める必要はありません。以下の手順に従うことで、既存のレガシープロジェクトやアプリケーションを、バージョン管理の有無にかかわらずGitLabに取り込めます。\n\n\n### Gitプロジェクト\n\n\n1.\nローカルプロジェクトで[すでにGitが初期化されている](https://docs.gitlab.com/ee/topics/git/commands.html#git-init)場合は、GitLabで新しいプロジェクトを作成し、プロジェクトページの右上にある「**コード**」ボタンをクリックして、SSHまたはHTTPSのURLを取得します。\n\n\n![GitLabでSSH/HTTPS\nURLを使用して新規プロジェクトを作成する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097254/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097252717.png)\n\n\n2. ターミナルに切り替え、プロジェクトフォルダに移動します。\n\n\n```bash  \n\ncd /project_folder  \n\n```\n\n\n3. 既存の[Git\norigin](https://git-scm.com/book/ms/v2/Git-Basics-Working-with-Remotes)をバックアップします。\n\n\n```bash\n\n\ngit remote rename origin old-origin\n\n\n```\n\n\n4.\n新しいoriginの[GitLabリモート](https://git-scm.com/book/ms/v2/Git-Basics-Working-with-Remotes)のURLを追加します（SSHを使用する場合）。\n\n\n```bash  \n\ngit remote add origin\n[git@gitlab.com](mailto:git@gitlab.com):gitlab-da/playground/abubakar/new-test-repo.git  \n\n```\n\n\n（HTTPSを使用する場合）\n\n\n```bash  \n\ngit remote add origin\nhttps://gitlab.com/gitlab-da/playground/abubakar/new-test-repo.git  \n\n```\n\n\n5.\nすべての[ブランチ](https://docs.gitlab.com/ee/user/project/repository/branches/)と[タグ](https://docs.gitlab.com/ee/user/project/repository/tags/)をGitLabにプッシュします。\n\n\n```bash  \n\ngit push --set-upstream origin --all  \n\ngit push --set-upstream origin --tags  \n\n```\n\n\nこれで、すべてのファイル、ブランチ、タグがGitLabにプッシュされ、コラボレーションを開始できるようになります。\n\n\n### Gitが未初期化のプロジェクト\n\n\nGitをまだ初期化していないプロジェクトの場合、以下の手順でGitを初期化し、既存のファイルをコミットしてGitLabにプッシュする必要があります。\n\n\n```bash  \n\ngit init --initial-branch=main  \n\ngit remote add origin\ngit@gitlab.com:gitlab-da/playground/abubakar/new-test-repo.git  \n\ngit add .  \n\ngit commit -m \"Initial commit\"  \n\ngit push --set-upstream origin main  \n\n```\n\n\n## オンラインソースからインポートする\n\n\nGitLab.comや他のプラットフォームにあるプロジェクトを、別のGitLabインスタンス（たとえばSelf-Managedインスタンス）に移行したい場合や、他のプラットフォームからGitLab.comに移行したい場合は、GitLabのプロジェクトインポート機能を利用できます。この機能は、新しいプロジェクトを作成する際に使用できます。\n\n\n![新規プロジェクト作成画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378521/Blog/rcilwlmji2azhylqpcpa.png)\n\n\nプロジェクトをインポートすると、ソースに応じてプロジェクトのファイルやその他の一部のコンポーネントが移行されます。Bitbucket、GitHub、Gitea、GitLabインスタンスなど、さまざまなソースからのインポートが可能です。GitLab.comでは、これらのインポートソースはデフォルトで有効になっていますが、[Self-Managed環境では管理者によって有効化する](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources)必要があります。以降のセクションでは、いくつかのソースについて詳しく見ていきます。\n\n\n![サードパーティのソースからプロジェクトをインポートする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378540/Blog/xks5zenxe5h27accwj1a.png)\n\n\n## GitLabソース\n\n\nGitLab.comやGitLab\nSelf-Managedインスタンスからプロジェクトをエクスポートするには、プロジェクトの設定にある「プロジェクトのエクスポート」機能を使用できます。\n\n\n![エクスポートプロジェクト画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378558/Blog/wxkrvotrhabmc3snfyxt.png)\n\n\nエクスポート手順：\n\n\n- プロジェクトの設定に移動し、「**一般**」の項目をクリックします。\n\n- スクロールして「**高度な設定**」 セクションを展開します。\n\n- 「**プロジェクトのエクスポート**」を選択します。\n\n- 次の通知が表示されます。「プロジェクトのエクスポートを開始しました。ダウンロードリンクをメールで送信し、このページで利用可能になります。」\n\n-\nエクスポートの生成が完了したら、メールに記載されたリンクを開くか、プロジェクトの設定ページを更新すると、「エクスポートをダウンロード」オプションが表示されます。\n\n\n### プロジェクトをインポートする\n\n\n![エクスポートされたGitLabプロジェクトをインポートする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097252718.png)\n\n\n- 対象のGitLabインスタンスで「**新規プロジェクト**」ボタンをクリックします。\n\n- 「**プロジェクトのインポート**」を選択し、インポートソースの一覧から「**GitLab エクスポート**」をクリックします。\n\n- プロジェクト名を指定し、エクスポートファイルを選択した後、「**プロジェクトのインポート**」をクリックします。\n\n- 「インポート中です」のページが表示され、完了するとインポートしたプロジェクトのページにリダイレクトされます。\n\n\nインポートにかかる時間は、プロジェクトのサイズによって異なります。なお、プロジェクトの一部がエクスポートされなかったり、インポート後に若干の変更が生じたりする場合があります。これらの制限事項については、[ドキュメント](https://docs.gitlab.com/ee/user/project/settings/import_export.html#export-a-project-and-its-data)をご確認ください。個々のプロジェクトではなくグループ全体を移行する場合は、[直接転送](https://docs.gitlab.com/ee/user/group/import/index.html)を使用することをおすすめします。これにより、グループ全体のコピーが作成されます。\n\n\n## サードパーティプロバイダー\n\n\nGitLabは、Bitbucket Cloud、Bitbucket\nServer、FogBugz、Gitea、GitHubからのプロジェクトのインポートに対応しています。インポート手順は、対応しているすべてのサードパーティでほぼ同じですが、認証方法が異なります。ここでは、認証方法の例をいくつかご紹介します。\n\n\n### GitHub\n\n\n![GitHub認証画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097252719.png)\n\n\nGitHubのプロジェクトをGitLabにインポートする場合、以下の3つの方法があります。\n\n\n- [GitHub\nOAuthを使用する](https://docs.gitlab.com/ee/user/project/import/github.html#use-github-oauth)\n\n-\n[GitHubのパーソナルアクセストークンを使用する](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token)\n\n-\n[APIを使用する](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api)\n\n\n「GitHub\nOAuthを使用する」方法と「パーソナルアクセストークンを使用する」方法は似ていますが、GitLabがリポジトリへアクセスするための認証方法に違い\nがあります。より簡単なのはOAuthを使用する方法で、「GitHubで認証」ボタンをクリックするだけで、GitHubの認証ページにリダイレクトされ、アクセスを許可することで接続が完了します。認証後、プロジェクトの一覧が表示され、インポートするプロジェクトを選択できます。\n\n\n![「リポジトリをGitHubからインポートする」画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378579/Blog/dweaxwgtvikiauvj1juk.png)\n\n\nOAuthを使用しない場合は、`repo`スコープと`read:\norg`スコープを選択してGitHubのパーソナルアクセストークンを生成し、それを「インポート」ページで入力する必要があります。APIを使ってインポートする場合は、このパーソナルアクセストークンを使用することで、スクリプトやアプリケーションでGitLabの[Import\nREST\nAPIエンドポイント](https://docs.gitlab.com/ee/api/import.html#import-repository-from-github)を利用できます。\n\n\n次のデモ動画では、GitLabのシニアデベロッパーアドボケートを務めるFernando\nDiazが、OAuthを使ってGitHubからプロジェクトをインポートする方法を解説しています。\n\n\n\u003C!-- blank line -->  \n\n\u003Cfigure class=\"video_container\"> \n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=esF6wbz2j2JlhDVL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>  \n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\nGitLabの[インポートに関するドキュメント](https://docs.gitlab.com/ee/user/project/import/github.html)では、前提要件、既知の問題、GitHub\nEnterpriseからのインポート手順、その他の重要な情報を参照していただけます。\n\n\n### Bitbucket\n\n\nBitbucketからプロジェクトをインポートする手順は、GitHubの例とほとんど同じです。[Bitbucket\nCloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html)（BitbucketのSaaS版）を使用する場合はOAuth認証が可能ですが、[Bitbucket\nServer](htthttps://docs.gitlab.com/ee/user/project/import/bitbucket_server.html)（エンタープライズ向けのセルフホスト版）の場合は、URL、ユーザー名、パーソナルアクセストークンを入力する必要があります。「インポート」画面でBitbucket\nCloudを選択すると、自動的にAtlassianの認証ページ に移動し、Bitbucketの認証が行われます。\n\n\n![Bitbucketからプロジェクトをインポートする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097252720.png)\n\n\nBitbucketのプロジェクトは、[GitLab Import\nAPI](https://docs.gitlab.com/ee/api/import.html)を使用してインポートすることも可能です。\n\n\n### Gitea\n\n\n![Giteaからプロジェクトをインポートする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097252722.png)\n\n\n[Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html)からプロジェクトをインポートするには、Giteaのプラットフォーム上で[パーソナルアクセストークン](https://docs.gitea.com/next/development/api-usage#authentication-via-the-api)を作成し、それをGiteaサーバーのURLとともにGitLabのインポートページで入力する必要があります。なお、OAuth認証はサポートされていません。\n\n\n### 汎用リモートGitリポジトリ\n\n\n![リモートGitリポジトリからプロジェクトをインポートする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378589/Blog/v4ysiomfr6mqa14p5hii.png)\n\n\nお使いのGitプロバイダーがサポートされていない場合や、サポートされている方法でインポートできない場合、アクセス可能な`https://`または`git://`のURLを使ってリポジトリをインポートできます。リポジトリが公開されていない場合は、リポジトリURLに加えて、ユーザー名とパスワード（または多要素認証が必要な場合はアクセストークン）を入力する必要があります。\n\n\nこの方法は、リモートプロジェクトのコピーを維持し、同期を保つ目的にも使用できます。これを[ミラーリング](https://docs.gitlab.com/ee/user/project/repository/mirror/)といい、異なるプラットフォーム間でリポジトリを同期し、最新の状態を維持できます。たとえば、プライベートとパブリックのリポジトリを分けつつ、両者で同じ内容を保持できるため、内部プロジェクトをオープンソース化する際に便利です。また、異なるプラットフォームを使用する契約業者と協力していて、両者がコードベースにアクセスする必要がある場合にも活用できます。\n\n\n## まとめ\n\n\nGitLabのインスタンス間や外部ソースからのインポートおよび移行は、どのデータをどの方法でインポートするのかを明確に計画した上で実施すべき重要なプロセスです。ほとんどのサードパーティのインポート方法では、ファイル、イシュー、マージリクエストなどのプロジェクトアイテムがインポートされますが、一部の方法には既知の問題や制限があることにご注意ください。GitLabの[インポートに関するドキュメント](https://docs.gitlab.com/ee/user/project/import/)には、サポートしているすべての方法の詳細情報が記載されており、移行を計画する際に役立ちます。\n\n\n> ####\nもっとGitLabについて知りたい場合は、[GitLabユニバーシティのコースに登録](https://university.gitlab.com/)するか、[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/devsecops/)を今すぐお試しください。\n\n\n\u003Cbr>\n\n\u003Cbr>\n\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\u003Cbr>\n",[701,676,904],"2025-05-26",{"slug":2203,"featured":6,"template":681},"getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","content:ja-jp:blog:getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","Getting Started With Gitlab How To Import Your Projects To Gitlab","ja-jp/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","ja-jp/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"_path":2209,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2210,"content":2216,"config":2222,"_id":2224,"_type":16,"title":2225,"_source":17,"_file":2226,"_stem":2227,"_extension":20},"/ja-jp/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"title":2211,"description":2212,"ogTitle":2211,"ogDescription":2212,"noIndex":6,"ogImage":2213,"ogUrl":2214,"ogSiteName":1223,"ogType":1224,"canonicalUrls":2214,"schema":2215},"GitLabでSOC2セキュリティ要件に対応するためのガイド","SOC2セキュリティ要件に対応する、GitLab DevSecOpsプラットフォームのアプリケーションセキュリティ機能について解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099576/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1172300481_IGPi3TS4VzFgcqhvEdBlR_1750099575518.jpg","https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabでSOC2セキュリティ要件に対応するためのガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-01-22\",\n      }",{"title":2211,"description":2212,"authors":2217,"heroImage":2213,"date":2218,"body":2219,"category":722,"tags":2220},[1507],"2025-01-22","機密性の高い顧客情報を扱う企業にとって、SOC（システムおよび組織管理）2コンプライアンスの達成は単なる推奨事項ではなく、多くの場合、必要不可欠です。SOC2は、米国公認会計士協会（AICPA）が策定した厳格な監査基準であり、サービス組織のセキュリティ、可用性、処理の完全性、機密性、プライバシーに関する管理体制を評価します。\n\n\nSOC2は法的義務ではありませんが、ニュースで頻繁に報じられる情報漏洩事件の影響もあり、重要性が高まっています。SOC2コンプライアンスを達成することで、顧客データを適切に保管し、第三者によるセキュリティ管理の評価を受けていることが伝わり、顧客からの信頼を得られます。\n\n\n本ガイドでは、SOC2コンプライアンスの要件を解説し、GitLabがどのように組織のアプリケーションセキュリティの最高水準の達成に役立つかをご紹介します。\n\n\n## SOC 2で定められている要件\n\n\nSOC2コンプライアンスを達成するには、独立した監査担当者による監査が必要となります。監査では、組織の管理体制の設計および運用の有効性を評価します。監査プロセスは非常にコストがかかることが多く、多くの組織は監査前の準備を十分に行えていないのが現状です。通常、SOC2監査は約1年を要するため、効率的な事前監査プロセスを確立することが重要です。\n\n\nSOC2コンプライアンスを達成するには、組織は以下のトラストサービス規準に基づく要件を満たす必要があります。\n\n\n| 規準 | 要件 |\n\n| :---- | :---- |\n\n| セキュリティ | - 不正アクセスを防ぐための管理策を実施 \u003Cbr> - リスクの特定と軽減のための手順を確立\u003Cbr> - セキュリティインシデントを検知および対応するためのシステムを構築 |\n\n| 可用性 | - 合意されたとおりにシステムの稼働を保証\u003Cbr> - 現在の使用状況と容量をモニタリング \u003Cbr> - システム可用性に影響を与えうる環境リスクを特定・対処 |\n\n| 処理の完全性 | - システムの入力・出力の正確な記録を維持 \u003Cbr> - システムエラーを迅速に特定し修正する手順を実施 \u003Cbr> - 製品・サービスが仕様を満たすよう処理作業を定義 |\n\n| 機密性 | - 機密情報を特定し保護 \u003Cbr> - データ保持期間のポリシーを策定 \u003Cbr> - 保持期間終了後、機密データを安全に破棄する方法を確保 |\n\n| プライバシー | - 機密個人情報を収集する前に同意を取得 \u003Cbr> - プライバシーポリシーを明確かつわかりやすく伝達 \u003Cbr> - 法的手段を通じて信頼できる情報源からのみデータを収集 |\n\n\u003Cbr>\n\n\nなお、これらの要件は一度達成すれば終わりではなく、継続的に準拠する必要があります。監査担当者は一定期間にわたる管理策の有効性の有無を評価します。\n\n\n## セキュリティ要件を満たし、維持する方法\n\n\nGitLabには、SOC2のセキュリティ要件を満たすためにすぐに活用できる機能が数多く用意されています。\n\n\n| セキュリティ要件 | 対応機能 |\n\n| :---- | :---- |\n\n| 不正アクセスを防ぐための管理策を実施 | - 非公開のイシュー／マージリクエスト \u003Cbr> -  カスタムロールときめ細かい権限設定 \u003Cbr> - セキュリティポリシー \u003Cbr> - 検証済みコミット \u003Cbr> - コンテナイメージの署名 \u003Cbr> - CodeOwners \u003Cbr> - 保護ブランチ |\n\n| セキュリティインシデントを検知および対応するためのシステムを構築 | - 脆弱性スキャン \u003Cbr> - マージリクエスト内セキュリティウィジェット \u003Cbr> -  脆弱性インサイトコンプライアンスセンター \u003Cbr> - 監査イベント \u003Cbr> -脆弱性レポート依存関係リスト \u003Cbr> - AIによる脆弱性の説明 \u003Cbr> - AIによる脆弱性の修正 |\n\n| リスクの特定と軽減のための手順を確立 | 上記すべてのツールを活用して、セキュリティチームが脆弱性発見時の対応および軽減手順を確立できます |\n\n\u003Cbr>\n\nそれでは、各要件に対応するセキュリティ機能についてさらに詳しく解説しましょう。なお、上記のほとんどの機能は、[GitLab Ultimateプランのサブスクリプション](https://about.gitlab.com/ja-jp/free-trial/)および適切なロールと権限設定が必要となります。詳細については、該当するドキュメントをご確認ください。\n\n\n## 不正アクセスから保護するための制御の実装\n\n\n組織の資産を保護して、規制遵守を達成し、業務の継続性を維持し、信頼を築くためには、強固なアクセス制御の実装が不可欠です。GitLabでは、[最小権限の原則](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)に従ったアクセス制御を実装でき、不正アクセスからの保護を実現します。ここでは以下の項目について簡単に紹介します。\n\n\n* [セキュリティポリシー](#security-policies)\n\n* [カスタムロールときめ細かい権限設定](#custom-roles-and-granular-permissions)\n\n* [ブランチ保護とCodeOwners](#branch-protections-and-codeowners)\n\n* [検証済みコミット](#verified-commits)\n\n\n### セキュリティポリシー\n\n\nGitLabのセキュリティポリシー（いわゆるガードレール）を使用すると、セキュリティおよびコンプライアンスチームは組織全体で一貫した制御を実装できます。これにより、セキュリティインシデントの予防、コンプライアンス基準の維持、一括でのベストプラクティスの自動適用によるリスクの低減が可能になります。\n\n\n![マージリクエスト承認ポリシーの活用例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750099596925.png)\n\n\n\u003Ccenter>\u003Ci>マージリクエスト承認ポリシーの活用例\u003C/i>\u003C/center>\u003Cbr>\n\n\n以下のようなポリシーを利用できます。\n\n\n* スキャン実行ポリシー：パイプラインの一部として、または指定したスケジュールに応じてセキュリティスキャンの実行を強制\n\n* マージリクエスト承認ポリシー：スキャン結果に基づいて、プロジェクトレベルの設定や承認ルールを適用\n\n* パイプライン実行ポリシー：プロジェクトパイプライン内でCI/CDジョブの実行を強制\n\n* 脆弱性管理ポリシー：脆弱性の対応ワークフローを自動化\n\n\n以下に、パイプライン実行ポリシーを活用してコンプライアンスを確保する例をご紹介します。\n\n\n1. 複数のコンプライアンスジョブをまとめたプロジェクトを作成します。たとえば、デプロイされるファイルの権限を確認するジョブを含めます。これらのジョブは、複数のアプリケーションで再利用できるように汎用的な内容にしておきます。\n\n2. このプロジェクトへの権限はセキュリティ／コンプライアンス担当者に限定し、デベロッパーがジョブを削除できないようにします。これにより職務分離が実現します。\n\n3. 対象のプロジェクトにこれらのコンプライアンスジョブを一括で挿入します。ジョブが必ず実行されるよう強制しつつ、開発の妨げにならないようにチームリーダーが実行を承認できるようにします。これにより、コンプライアンスジョブが常に実行され、デベロッパーによって削除されることがなくなり、ご利用の環境にて常にコンプライアンスが確保されるようになります。\n\n\n> ##### セキュリティポリシーの作成方法については、GitLabの[セキュリティポリシーに関するページ](https://docs.gitlab.com/ee/user/application_security/policies/)をご覧ください。\n\n\n### カスタムロールと詳細な権限\n\n\nGitLabのカスタム権限を使用すると、標準のロールベースの権限ではできないきめ細かいアクセス制御を実装できます。これにより、以下のような利点が得られます。\n\n\n* より正確なアクセス制御\n\n* セキュリティコンプライアンスの向上\n\n* 誤ったアクセスのリスク軽減\n\n* ユーザー管理の効率化\n\n* 複雑な組織構造への対応\n\n\n![GitLabカスタムロール](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/custom_roles_aHR0cHM6_1750099596926.png)\n\n\n\u003Ccenter>\u003Ci>ロールと権限の設定（カスタムロールを含む）\u003C/i>\u003C/center>\n\n\n> ##### [カスタムロールに関するページ](https://docs.gitlab.com/ee/user/custom_roles.html)を参照して、きめ細かな権限を設定できるカスタムロールの作成方法をご確認ください。\n\n\n### ブランチ保護とCodeOwners\n\n\nGitLabでは、次の2つの主要な機能により、コードに変更を加えられるユーザーをさらに厳密に管理できます。\n\n* ブランチ保護：変更をマージする前に承認を必須とするなど、特定のブランチを変更できるユーザーに関するルールを設定できます。\n\n* CodeOwners：各ファイルを指定された所有者に関連付け、該当ファイルが変更された際に自動的に適切なレビュアーを指定します。\n\n\nこれらの機能を組み合わせることで、適切な担当者がレビュー・承認を行う体制を構築でき、コードのセキュリティと品質を高い水準で維持できます。\n\n\n![保護ブランチ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/protected_branches_aHR0cHM6_1750099596928.png)\n\n\n\u003Ccenter>\u003Ci>保護ブランチの設定\u003C/i>\u003C/center>\n\n\n> ##### 保護ブランチとCodeOwnersの設定方法については、[保護ブランチ](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html)および[CodeOwner](https://docs.gitlab.com/ee/user/project/codeowners/)のページをご参照ください。\n\n\n### 検証済みコミット\n\n\nコミットにデジタル署名を追加することで、なりすましではなく、本当に自分が作成したものであることを証明できます。デジタル署名は、自分だけが発行できる「電子印鑑」のようなものです。GitLabに公開GPG鍵を登録すれば、署名が正しいかを確認でき、マッチすればそのコミットには`Verified`（検証済み）のマークが付きます。さらに、未署名のコミットを拒否したり、本人確認ができていないユーザーのコミットをブロックしたりするルールも設定可能です。\n\n\n![検証済み署名付きコミット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/signed_commit_aHR0cHM6_1750099596929.png)\n\n\n\u003Ccenter>\u003Ci>検証済み署名付きコミット\u003C/i>\u003C/center>\u003Cbr>\n\n\nコミットには以下の方法で署名できます。\n\n\n* SSH鍵\n\n* GPG鍵\n\n* 個人用x.509証明書\n\n\n> ##### 検証済みコミットの詳細は、[署名付きコミットに関するページ](https://docs.gitlab.com/ee/user/project/repository/signed_commits/)をご覧ください。\n\n\n## セキュリティインシデントの検出と対応のためのシステムの構築\n\n\n強固なセキュリティ対策状況の維持、規制遵守の確保、被害の最小化、変化し続ける脅威への迅速な対応には、セキュリティインシデントを検知し対応するシステムの構築が不可欠です。\n\n\nGitLabには、アプリケーションのライフサイクル全体を対象とするセキュリティスキャンと脆弱性管理機能が備わっています。以下の機能について簡単に説明します。\n\n\n* [セキュリティスキャンと脆弱性管理](#security-scanning-and-vulnerability-management)\n\n* [ソフトウェア部品表（SBOM）](#software-bill-of-materials)\n\n* [システム監査とセキュリティ対策状況のレビュー](#system-auditing-and-security-posture-review)\n\n* [コンプライアンスおよびセキュリティ対策状況の監視](#compliance-and-security-posture-oversight)\n\n\n### セキュリティスキャンと脆弱性管理\n\n\nGitLabには以下のような多様なセキュリティスキャナーが備わっており、アプリケーションのライフサイクル全体をカバーします。\n\n\n* 静的アプリケーションセキュリティテスト（SAST）\n\n* 動的アプリケーションセキュリティテスト（DAST）\n\n* コンテナスキャン\n\n* 依存関係スキャン\n\n* Infrastructure as Code（IaC）スキャン\n\n* カバレッジガイドファジング\n\n* Web APIファジング\n\n\nこれらのスキャナーはテンプレートを利用すれば、パイプラインに追加できます。たとえば、テストステージでSASTと依存関係スキャンのジョブを実行するには、.gitlab-ci.ymlに以下を追加します。\n\n\n```yaml\n\nstages:   - test\n\ninclude:   - template: Jobs/Dependency-Scanning.gitlab-ci.yml   - template: Jobs/SAST.gitlab-ci.yml   ```\n\n\nこれらのジョブは環境変数やGitLabジョブ構文を使ってすべて設定可能です。パイプラインが起動すると、セキュリティスキャナーが動作し、現在のブランチとターゲットブランチの差分から脆弱性を検出します。検出された脆弱性はマージリクエスト（MR）内で確認でき、コードがターゲットブランチにマージされる前に細部まで監視する必要があります。MRには脆弱性に関して以下の情報が表示されます。\n\n\n* 説明\n\n* ステータス\n\n* 重大度\n\n* 証拠\n\n* 識別子\n\n* URL（該当する場合）\n\n* リクエスト／レスポンス（該当する場合）\n\n* 再現用資産（該当する場合）\n\n* トレーニング情報（該当する場合）\n\n* コードフロー（高度なSAST使用時）\n\n\n![脆弱性を紹介するMRの表示画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750099596931.png)\n\n\n\u003Ccenter>\u003Ci>脆弱性を紹介するMRの表示画面\u003C/i>\u003C/center>\u003Cbr>\n\n\nデベロッパーはこれらの情報を活用して、セキュリティチームのワークフローを妨げることなく脆弱性を修正できます。デベロッパーは、レビュープロセスにかかる時間を短縮するために、理由を添えて脆弱性を無視したり、もしくは脆弱性を追跡するための非公開イシューを作成したりすることが可能です。\n\n\nマージリクエストのコードがデフォルトブランチ（通常は本番環境レベル）にマージされると、脆弱性レポートにセキュリティスキャナーの結果が反映されます。セキュリティチームはこれらの結果をもとに、本番環境で見つかった脆弱性の管理・トリアージを行います。\n\n\n![バッチステータス設定が表示された脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099596936.png)\n\n\n\u003Ccenter>\u003Ci>バッチステータス設定が表示された脆弱性レポート\u003C/i>\u003C/center>\u003Cbr>\n\n\n脆弱性レポート内の脆弱性の説明をクリックすると、MRと同じ脆弱性データが表示される脆弱性ページに移動します。これらの情報は、影響評価や修正作業の際に信頼できる唯一の情報源として活用できます。脆弱性ページでは、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)のAI機能を使って脆弱性の説明を生成したり、修正のためのMRを作成したりして、解決までの時間を短縮できます。\n\n\n> ##### GitLabに含まれるセキュリティスキャナーや脆弱性管理の詳細は、[アプリケーションセキュリティに関するページ](https://docs.gitlab.com/ee/user/application_security/)をご覧ください。\n\n\n### ソフトウェア部品表\n\n\nGitLabはソフトウェアで使用されているコンポーネント（部品）の詳細をリスト化できます。これはコードの「材料表」のようなもので、ソフトウェア部品表（[SBOM](https://about.gitlab.com/ja-jp/blog/the-ultimate-guide-to-sboms/)）と呼ばれます。プロジェクトで使われている外部コードに関して、直接使われているコードやそれらが依存するコードも含め、すべてを把握できます。各項目について、使用バージョンやライセンス情報、既知のセキュリティ問題の有無も表示されます。これにより、自社のソフトウェアの構成を把握し、潜在的なリスクを見つけやすくなります。\n\n\n![グループレベルの依存関係リスト（SBOM）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/sbom_aHR0cHM6_1750099596937.png)\n\n\n\u003Ccenter>\u003Ci>グループレベルの依存関係リスト（SBOM）\u003C/i>\u003C/center>\n\n\n> ##### 依存関係リストのアクセス方法と活用法は、[依存関係リストに関するページ](https://docs.gitlab.com/ee/user/application_security/dependency_list/)をご参照ください。\n\n\n### システム監査とセキュリティ対策状況のレビュー\n\n\nGitLabは、誰がいつ何を変更したかなど、システム内のすべての動きを記録します。コードを監視するセキュリティカメラのようなものだと考えてください。これにより、以下が可能になります。\n\n\n* 不審な動きを発見する\n\n* 規制当局にルール遵守を証明する\n\n* 問題が発生した際に状況を把握する\n\n* GitLabの利用状況を把握する\n\n\nこれらの情報は一元管理されているため、必要に応じて容易に確認・調査できます。たとえば、監査イベントを使うと以下の情報を追跡できます。\n\n\n* GitLabプロジェクトにおいて、誰がいつ特定ユーザーの権限レベルを変更したか\n\n* 誰がいつ新しいユーザーを追加または削除したか\n\n\n![プロジェクトレベルの監査イベント](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/audit_events_aHR0cHM6_1750099596938.png)\n\n\n\u003Ccenter>\u003Ci>プロジェクトレベルの監査イベント\u003C/i>\u003C/center>\n\n\n> ##### 監査イベントの詳細については、[監査イベントに関するページ](https://docs.gitlab.com/ee/user/compliance/audit_events.html)をご覧ください。\n\n\n## コンプライアンスとセキュリティ対策状況の監視\n\n\nGitLabのセキュリティダッシュボードは、すべてのセキュリティリスクを1か所で表示する「コントロールルーム」のような機能です。複数のセキュリティツールを個別に確認する必要はなく、全プロジェクトの調査情報を1つの画面でまとめて把握できます。これにより、プロジェクトに潜む問題の早期発見と迅速な対応が可能になります。\n\n\n![グループレベルのセキュリティダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/security_dashboard_aHR0cHM6_1750099596939.png)\n\n\u003Ccenter>\u003Ci>グループレベルのセキュリティダッシュボード\u003C/i>\u003C/center>\n\n\n> ##### セキュリティダッシュボードの詳細については、[セキュリティダッシュボードに関するページ](https://docs.gitlab.com/ee/user/application_security/security_dashboard/)をご覧ください。\n\n\n## リスクを特定し、軽減するための手順の確立\n\n\n脆弱性には特定のライフサイクルがあります。たとえば、セキュリティポリシーを使って、脆弱なコードを保護ブランチにマージするには承認が必要という手続きを設けることができます。さらに、本番環境で脆弱なコードが検出された場合、優先的に対応し、評価・修正・検証を行うという流れを定めることも可能です。\n\n\n* 優先順位は、GitLabのスキャナーによって提供される脆弱性の重大度に基づいて決められます。\n\n* 評価は、AIによる脆弱性の説明機能が提供する悪用の詳細情報を使って行えます。\n\n* 修正後は、GitLabに組み込まれた回帰テストやスキャナーを使用して検証できます。\n\n\nすべての組織に共通の対応策はありませんが、GitLabのような統合プラットフォームを活用することで、複数の異なるツールを使う場合と比べて、リスクをすばやく把握・対処でき、リスク全体を低減することが可能です。\n\n\n### SOC 2コンプライアンスに関するベストプラクティス\n\n\n* 強固なセキュリティ文化を確立する：組織全体でセキュリティへの意識と責任感を高めましょう。\n\n* すべてを文書化する：ポリシー、手順、コントロールの詳細なドキュメントを維持しましょう。\n\n* 自動化できる部分は自動化する：自動化ツールを使用してコンプライアンスプロセスを効率化し、エラーを削減しましょう。\n\n* 効果的に情報を共有する：関係者に対し、コンプライアンスの取り組みについて情報を伝えましょう。\n\n* 専門家の助言を求める：SOC2準拠の取り組みにおいて、信頼できるコンサルタントとの連携を検討しましょう。\n\n\nSOC2コンプライアンスは大きな取り組みですが、その価値は計り知れません。アプリケーションセキュリティと運用上の卓越性への取り組みを示すことで、顧客からの信頼を築き、企業としての評判を高め、市場における競争力を強化できます。\n\n\n## 詳細はこちら\n\n\nGitLabの詳細、またGitLabがSOC2コンプライアンスの達成とセキュリティ対策状況の強化にどのように役立つかについては、以下のリソースをご覧ください。\n\n\n* [GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)\n\n* [GitLabのセキュリティおよびコンプライアンスソリューション](https://about.gitlab.com/ja-jp/solutions/security-compliance/)\n\n* [GitLabアプリケーションセキュリティに関するページ](https://docs.gitlab.com/ee/user/application_security/)\n\n* [GitLab DevSecOpsチュートリアルプロジェクト](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n",[985,127,479,2221,91],"機能",{"slug":2223,"featured":92,"template":681},"guide-to-fulfilling-soc-2-security-requirements-with-gitlab","content:ja-jp:blog:guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","Guide To Fulfilling Soc 2 Security Requirements With Gitlab","ja-jp/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","ja-jp/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"_path":2229,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2230,"content":2236,"config":2241,"_id":2243,"_type":16,"title":2244,"_source":17,"_file":2245,"_stem":2246,"_extension":20},"/ja-jp/blog/gitlab-17-8-release",{"title":2231,"description":2232,"ogTitle":2231,"ogDescription":2232,"noIndex":6,"ogImage":2233,"ogUrl":2234,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2234,"schema":2235},"GitLab 17.8リリース","GitLab 17.8でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662175/Blog/Hero%20Images/product-gl17-blog-release-cover-17-8-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-8-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.8リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-01-16\",\n      }",{"title":2231,"description":2232,"authors":2237,"heroImage":2233,"date":2238,"body":2239,"category":701,"tags":2240,"updatedDate":2180},[738],"2025-01-16","**コンテナリポジトリのセキュリティが向上したGitLab 17.8をリリース**\n\nこのたび、GitLab 17.8のリリースを発表しました。このリリースでは、コンテナリポジトリのセキュリティ強化、リリース関連のデプロイの一覧表示、機械学習モデル検証の追跡、GitLab Dedicated向けLinuxホステッドランナーなど、さまざまな機能が追加されました！  \n\nこれらの機能は、今回のリリースに含まれる60件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。  \n\nGitLab 17.8には、GitLabコミュニティのユーザーから121件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースも、ユーザーのみなさまのご協力なくしては実現しませんでした。  \n来月のリリースで予定されている内容を先取りするには、17.9リリースのキックオフビデオも視聴できる[今後のリリースページ](https://about.gitlab.com/direction/kickoff/)をご覧ください。  \n\n> [GitLab 17.8のリリースでは、コンテナリポジトリのセキュリティが向上しました！クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+17.8+released+with+improved+container+repository+security&url=https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/&hashtags=)\n\n## 今月の[MVP](https://about.gitlab.com/community/mvp/)は[Océane Legrand](https://gitlab.com/oceane_scania)さんと[Juan Pablo Gonzalez](https://gitlab.com/ScanianJP)さんが受賞\n\nMVPには、誰もが[GitLabコミュニティのコントリビューターをMVPに推薦できます](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)。現在の候補者を応援したり、他の誰かをノミネートしてみませんか🙌\n\n[Océane Legrand](https://gitlab.com/oceane_scania)さんは共同開発プログラムを通じて、Juan Pablo Gonzalezさんと協力しながら、Conanのパッケージレジストリの機能セットを強化する取り組みを主導してきました。お二人は、一般公開（GA）に向けた機能の準備、またConanバージョン2のサポート実装に重点的に取り組んできました。お二人の例は、GitLabのパッケージレジストリ機能を大幅に改善する上で、共同開発プログラムがいかに有効であるかを示しています。  \n\nLegrandさんとGonzalezさんは、GitLabのコントリビューターサクセスチームでシニアフルスタックエンジニアを務める[Raimund Hook](https://gitlab.com/stingrayza)によって推薦されました。Hookは、お二人が連携しながら粘り強く取り組み、Conanパッケージレジストリの機能改善を継続的に進めた点に注目しました。お二人の功績はGitLabの価値観を体現するものであり、GitLabプラットフォーム上でConanを利用する全ユーザーに恩恵をもたらします。\n\nScania社のフルスタックデベロッパーであるOcéane Legrandさんは、AWS上のセルフホスト型GitLabインスタンスの保守作業を担っています。Legrandさんは「私がオープンソースで取り組んでいる作業は、GitLabとScaniaの両方に影響を与えています。共同開発プログラムを通じてコントリビュートすることで、Rubyやバックグラウンドマイグレーションの経験など、新たなスキルを習得できました。Scaniaの所属チームでアップグレード作業中に問題が発生した際、共同開発プログラムですでに同じ問題を経験していたため、トラブルシューティングを手伝うことができました」と述べています。  \n\nGitLabの共同開発プログラムについて詳しくは[こちら](https://about.gitlab.com/community/co-create/)をご覧ください。これらのプログラムでは、GitLabのお客様が、当社製品チームやエンジニアリングチームと直接連携しながら新機能の開発や既存機能の改善に取り組んでいます。\n\n## GitLab 17.8のリリースに含まれる主な改善点\n\n### 保護されたコンテナリポジトリによるセキュリティ強化\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\n本リリースでは、保護されたコンテナリポジトリが導入されました。この新機能は、コンテナイメージを管理する際のセキュリティと制御の課題を解決することを目的に追加されました。組織は、機密性の高いコンテナリポジトリへの不正アクセス、意図せぬ変更、細かい制御が設定できない、コンプライアンスの維持の難しさといった課題に苦労することがよくあります。このソリューションは、厳格なアクセス制御、プッシュ、プル、管理の操作権限を詳細に設定できるようにし、、GitLab CI/CDパイプラインとの統合をシームレスにすることで、セキュリティを強化します。\n\n保護されたコンテナリポジトリの導入で、セキュリティ侵害リスクや過失によって重要な資産が変更されるリスクが軽減されます。また、開発速度とセキュリティの両方を維持しながら、ワークフローを効率化できます。コンテナレジストリの全体的なガバナンスが向上されるほか、組織のニーズに基づいて重要なコンテナ資産が保護されていることが分かるため、安心感も得られます。\n\nこの機能と[保護パッケージ](https://gitlab.com/groups/gitlab-org/-/epics/5574)は、`gerardo-navarro`さんとシーメンス社のみなさまによるコミュニティへのコントリビュートにより実現しました。この場を借りて、GitLabに多大なるコントリビュートをしてくださったNavarroさんをはじめ、シーメンス社のみなさまに感謝申し上げます！この変更に対するNavarroさんとシーメンス社の方々のコントリビュートについて、詳しくは[こちらの動画](https://www.youtube.com/watch?v=5-nQ1_Mi7zg)をご確認ください。Navarroさんが、外部のコントリビューターとしてGitLabにコントリビュートした経験から得た洞察やベストプラクティスを紹介してくれています。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/packages/container_registry/container_repository_protection_rules.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/480385)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/protected_containers.png\">\n\n### リリース関連のデプロイの一覧表示\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\nGitLabでは、これまでもGitタグを元にしたリリースの作成およびデプロイの追跡をサポートしてきました。しかし、これらの情報が異なる場所に分散していたため、紐づけるのが困難でした。本リリースより、リリース関連のデプロイがすべてリリースページに直接表示されるようになりました。これにより、リリースマネージャーは、リリースのデプロイ先や、どの環境がデプロイ待ちであるかといったステータスを素早く確認できます。既存のデプロイページではタグ付けされたデプロイのリリースノートを表示されますが、この機能は既存のデプロイページの統合を補完するものです。\n\nこの場を借りて、GitLabに両機能をコントリビュートしてくれた[Anton Kalmykov](https://gitlab.com/antonkalmykov)さんに心より感謝します。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/releases/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/501169)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/list_the_deployments_related_to_a_release.png\">\n\n### 機械学習モデル検証の追跡機能の一般公開\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\n機械学習モデルを作成する際、データサイエンティストはモデルの性能向上を目的に、さまざまなパラメーターや設定、特徴量エンジニアリングを試行することがよくあります。データサイエンティストにとって、これらのメタデータや関連するアーティファクトをすべて追跡し、後から実験を再現できるようにするのは容易ではありません。機械学習モデル検証の追跡により、パラメータ、メトリクス、アーティファクトをGitLabに直接記録できるため、後から簡単にアクセスできるだけでなく、すべての実験データをGitLab環境内で保持できるようになりました。この機能は、データ表示の強化、権限設定の強化、GitLabとのより緊密な統合、バグ修正といった改善が加えられ、本リリースより一般提供されています。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/9341)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/jkZq3SYm7a8?si=AaBF71InBSRhZWZa\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### GitLab Dedicated向けLinuxホステッドランナーが限定的に利用可能に\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：-\n\n本リリースより、GitLab Dedicated向けLinuxホステッドランナーが限定的に利用可能になりました。\n\nランナーのフリート管理作業は複雑になりがちで、デベロッパーの要求に応じてすべてのCI/CDジョブをスケールするには、豊富な経験が必要です。\nGitLab Dedicated向けのホステッドランナーでは、CI/CDジョブ用に徹底管理されたランナーを活用できます。そのため、独自のランナーインフラストラクチャを管理せずに済むほか、ランナーには、GitLab Dedicatedと同等のセキュリティ、柔軟性、効率性が確保されます。\nホステッドランナーは、CI/CDのニーズに合わせて自動的にスケールし、ピーク時や大規模プロジェクトにおいてパフォーマンスを最適化します。今回の限定リリースでは、2～32 vCPU、8～128 GBのメモリを搭載した、さまざまなサイズのLinuxランナーをご利用いただけます。\n\n限定リリース期間中にGitLab Dedicated向けホステッドランナーをご利用になりたい場合は、GitLabの担当者までお問い合わせください。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/dedicated/hosted_runners.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509142)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/runner_dedicated.png\">\n\n### macOS大規模M2 Proホステッドランナーが利用可能に（ベータ版）\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：-\n\nM2 Proの性能を、モバイルDevOpsチームが活用できるようになりました。  \nM1ランナーの最大2倍、x86-64 macOSランナーの最大6倍の性能を誇るM2 Proランナーを使用することで、開発チームによるアプリケーションのビルドとデプロイの作業速度が向上します。\n\nこのランナーは、GitLab CI/CDに完全統合され、オンデマンドで利用可能です。これにより、Appleエコシステム向けアプリケーションの作成、テスト、およびデプロイがより迅速かつシームレスになります。\n\n`.gitlab-ci.yml`ファイルのタグに`saas-macos-large-m2pro`を指定して、新しいM2 Proランナーをぜひお試しください。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/runners/hosted_runners/macos.html)  \n[エピック](https://gitlab.com/groups/gitlab-org/ci-cd/shared-runners/-/epics/19)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/rocket_m2pro.png\">\n\n## GitLab 17.8のリリースに含まれるその他の改善点\n\n### イシューまたはマージリクエスト内における複数のto-doアイテムの追跡\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\n単一のイシューまたはマージリクエスト内で、複数のディスカッションやメンションを追跡できるようになりました。この新機能は、メンションやアクションごとに個別のto-doアイテムを表示させて、重要な更新やリクエストを見逃さないようサポートします。この機能強化により、作業をより効果的に管理し、チームのニーズにより効率的に対応できるようになります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/todos.html#multiple-to-do-items-per-object)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/28355)\n\n### エピックの祖先を把握しやすい表示に\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\n祖先ウィジェットの設計が見直されたことで、[エピックの階層](https://docs.gitlab.com/ee/user/group/epics/#relationships-between-epics-and-other-items)を確認しやすくなりました。各エピックの上部に、パンくずリストのようなナビゲーションガイドで目立つように表示されます。1つ上の親と一番上の親を一目で確認し、エピック間の関係を素早く把握できます。これにより、プロジェクト構造の概要を分かりやすく管理し、関連するエピック間を簡単に移動できます。\n\n管理者は、[エピックの新しい外観](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html)を有効にする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/epics/#relationships-between-epics-and-other-items)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509920)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/epic_ancestors.png\">\n\n### エピックから親を追加\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\nイシューの場合と同様に、直接エピックから親を追加することで、エピック階層を簡単に管理できるようになりました。このプロセスの効率化により、作業をより柔軟に整理できるようになり、エピック間の関係を迅速に構築し、プロジェクト構造を分かりやすく保つことができます。\n\n管理者は、[エピックの新しい外観](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html)を有効にする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/epics/#relationships-between-epics-and-other-items)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509923)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/epic_parent.png\">\n\n### エピック、イシュー、目標の子アイテムにイテレーションフィールドを表示\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：Premium、Ultimate\n\nプランナーはエピックの詳細を閲覧する際、どの子イシューがイテレーション（スプリント）で計画されていて、どれがまだ計画されていないかを確認できなければなりません。この新機能により、定義されたすべての作業がスプリントで計画されているかどうか、チームがより簡単に確認できるようになりました。\n\n管理者は、[エピックの新しい外観](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html)を有効にする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/iterations)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/510005)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/show_iteration_field_on_items_within_the_work_items_child_widget.png\">\n\n### エピックのWebhook\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：Premium、Ultimate\n\nエピックのWebhookを使用することで、ワークフローの自動化が強化されるだけでなく、エピックで変更が発生するたびに、お好みのツールでリアルタイムの更新を受け取ることができます。お使いの他のサービスとGitLabを統合すると、コラボレーションを強化し、プロジェクトの進捗を常に把握できます。また、アプリケーション間を何度も移動する必要がなくなり、プロセスが効率化されます。\n\n管理者は、[エピックの新しい外観](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html)を有効にする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509928)\n\n### GitLab Community Editionでパイプラインの制限を適用可能に\n\nSaaS：-\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\n管理者は、GitLab Community Edition（CE）にCI/CDに関する制限を適用して、パイプラインリソースの使用を制御できるようになりました。これまで、この機能はGitLab Enterpriseエディションでのみ利用可能でした。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#set-cicd-limits)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/287669)\n\n### Kubernetes用ダッシュボードでのポッド検索\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\n大規模なデプロイの場合、Kubernetes用ダッシュボードで特定のポッドを見つけるのには時間がかかる可能性があります。新たに検索バーが追加され、ポッドの名前を指定して素早く絞り込めるようになりました。利用可能なすべてのポッドが検索対象に含まれます。また、ステータスフィルターと組み合わせて、モニタリングやトラブルシューティングが必要なポッドを特定することも可能です。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/508010)\n\n### シークレット検出の実行時に修正手順が表示されるように\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\n漏洩した認証情報を使用して攻撃者がシステムに侵入するリスクを最小限に抑えるには、公開されてしまったシークレットに素早く対処しなければなりません。正しく修正するには、認証情報のローテーションや不正アクセスできる可能性がある箇所の調査など、単にシークレットを削除するだけでなく、さまざまな手順を行う必要があります。本リリースから、システムの安全性を保つために、シークレット検出を実行すると、検出されたシークレットのタイプごとに具体的な修正手順が表示されるようになりました。この修正手順を参考にすることで、情報漏洩に体系的に対処し、セキュリティ侵害のリスクを軽減できます。パイプラインが完了すると、検出されたすべての脆弱性に関する修正手順が表示されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/505757)\n\n### `override_ci`戦略が一元化されたワークフロールールの適用に対応\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\nパイプライン実行ポリシーの`override_ci`戦略が、`include:project`の利用時に、プロジェクト設定で定義されたジョブだけでなく、ポリシー内で定義されたジョブに対しても、ポリシーの実施を支援するワークフロールールの使用をサポートするようになりました。ポリシー内でワークフロールールを定義することで、プロジェクトでのブランチパイプラインの使用を防ぐルールを設定するなど、特定のルールに基づいてパイプライン実行ポリシーによって実行されるジョブをフィルタリングできます。\n\nポリシー内で定義されたジョブのみを対象とするワークフロールールを切り離して使用するには、ポリシーによってグローバルにルールを定義せずに、ジョブに対してルールを定義するのがおすすめです。もしくは、別の`include`フィールドを用いて、ジョブやルールをグループ化することもできます。\n\nこれまでは`override_ci`戦略を使用すると、パイプライン実行ポリシーで定義されたジョブにのみ、ワークフロールールを適用できました。\n\n`Inject_ci`戦略に変更はありません。ワークフロールールは、プロジェクトのワークフロールールには影響を及ぼさず、ポリシーのジョブが実行されるタイミングを制御するためだけに利用できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html#override_project_ci)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/512123)\n\n### パイプライン実行ポリシーで`skip_ci`を設定可能に\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\nパイプライン実行ポリシー（PEP）に新たな設定オプションを導入され、より柔軟に`[skip ci]`ディレクティブを処理できるようになりました。この機能によって、重要なセキュリティおよびコンプライアンスのチェックを確実に実行しつつ、パイプラインの実行をバイパスする必要がある、特定の自動化されたプロセス（セマンティックリリースなど）に対応できます。\n\nこの機能を使用するには、パイプライン実行ポリシーのYAML設定で`skip_ci`を`allowed: false`に設定するか、ポリシーエディターで「**ユーザーがパイプラインをスキップできないようにする**」を有効にします。次に、`[skip ci]`の使用を許可するユーザーまたはサービスアカウントを指定します。`skip_ci`設定内で例外として除外されない限り、デフォルトでは、すべてのユーザーがパイプライン実行ジョブをスキップできません。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html#skip_ci-type)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/15647)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/service-account-exception-skip_ci-pep.png\">\n\n### マージリクエスト承認ポリシーで複数の異なる承認アクションをサポート\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\nこれまでマージリクエスト承認ポリシーはポリシーごとに1つの承認ルールしかサポートしておらず、「OR」条件を用いて複数の承認者を指定する場合も1セットしか設定できませんでした。結果として、さまざまなロール、個々の承認者、または別々のグループから成る、階層化されたセキュリティ承認の実装は非常に困難でした。\n\n今回の更新により、マージリクエスト承認ポリシーごとに最大5つの承認ルールを作成できるようになったことから、より柔軟で堅牢な承認ポリシーの設定が可能になりました。ルールごとに異なる承認者やルールを指定でき、各ルールは個別に評価されます。たとえば、セキュリティチームは、グループAとグループBからそれぞれ1名の承認者、もしくは特定のロールと特定のグループから1名の承認者を必要とするような複雑な承認ワークフローを定義できます。これにより、機密性の高いワークフローにおけるコンプライアンスと制御の強化が実現できます。\n\nこの機能強化の使用例を以下にご紹介します。\n\n* __異なるロールによる承認__：デベロッパーロールおよびメンテナーロールによる承認  \n* __ロールおよびグループによる承認__：デベロッパーまたはメンテナーロールによる承認と、セキュリティグループのメンバーによる承認  \n* __異なるグループによる承認__： Pythonエキスパートグループのメンバーによる承認と、セキュリティグループのメンバーによる承認\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html)\n\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/12319)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/multiple-distinc-approvers-nov-19.png\">\n\n### GitLab MLOps Pythonクライアント（ベータ版）\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\nデータサイエンティストや機械学習エンジニアは主に作業環境としてPythonを使用していますが、機械学習ワークフローをGitLabのMLOps機能と統合するには、頭の切り替えが必要となるだけでなく、GitLabのAPI構造を理解しなければなりません。結果として、開発プロセスに摩擦が生じ、実験の追跡、モデルアーティファクトの管理、チームメンバーとのコラボレーションの速度に悪影響を及ぼす可能性があります。\n\n新しいGitLab MLOps Pythonクライアントでは、GitLabのMLOps機能にシームレスにアクセスできる、Pythonに適したインターフェイスを利用できます。これにより、データサイエンティストは、Pythonスクリプトやノートブックから直接GitLabの[実験追跡](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/)機能や[モデルレジストリ](https://docs.gitlab.com/ee/user/project/ml/model_registry/)機能を利用できるようになりました。クライアントでは以下の機能を利用できます。\n\n* **GitLab内での実験の追跡**：GitLab内で行われる機械学習実験を簡単に追跡できます。  \n* **モデルレジストリの統合**：GitLabのモデルレジストリでモデルの登録および管理ができます。  \n* **実験の管理**：クライアントから直接実験を作成し、管理できます。  \n* **追跡の実行**：トレーニングの実行とモニタリングが簡単にできます。\n\nこの統合により、データサイエンティストはモデル開発に集中しながら、機械学習ライフサイクルのメタデータをGitLabに自動的に取り込むことが可能になりました。Pythonクライアントは既存の機械学習ワークフローとシームレスに連携し、設定は最小限で済むため、データサイエンスコミュニティにとってGitLabのMLOps機能がより身近な存在となります。\n\n幅広いPythonとデータサイエンスコミュニティのみなさまからのコントリビュートをお待ちしています。[プロジェクトのリポジトリ](https://gitlab.com/gitlab-org/modelops/mlops/gitlab-mlops)から、ぜひ直接フィードバックをお寄せください。\n\n[ドキュメント](https://gitlab.com/gitlab-org/modelops/mlops/gitlab-mlops)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/16193)\n\n### エピックの色をカスタマイズ可能\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：Premium、Ultimate\n\n既存の値やカスタムのRGB値または16進コードを含む、拡張されたカラーオプションを使用して、エピックをより柔軟に分類できるようになりました。この視覚的なカスタマイズの強化により、エピックをスクワッド、会社のイニシアチブ、または階層レベルに簡単に関連付けることができ、ロードマップやエピックボードでの作業の優先順位付けや整理が楽になります。\n\n管理者は、[エピックの新しい外観](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html)を有効にする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#epic-color)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509924)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/customizable_colors_for_epics.png\">\n\n### エピックのヘルスステータス\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\nエピックのヘルスステータス機能が新たに追加され、プロジェクトの進捗状況を共有しやすくなりました。ステータスを「健全」「要注意」「危険」のいずれかに設定することで、エピックの健全性が可視化され素早く把握できるようになります。これにより、リスクを管理しつつ、プロジェクト全体のステータスを関係者と常に共有できるようになりました。\n\n管理者は、[エピックの新しい外観](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html)を有効にする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#health-status.)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509922)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/epic_health_status.png\">\n\n### GitLab Pagesでのプライマリドメインへのリダイレクト\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\nGitLab Pagesでプライマリドメインを設定し、カスタムドメインからのリクエストをすべてプライマリドメインに自動的にリダイレクトできるようになりました。訪問者がどのURLからサイトにアクセスしても、指定したドメインにリダイレクトされるため、SEOランキングを維持し、一貫したブランド体験を提供するのに役立ちます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/pages/#primary-domain)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15000)\n\n### エピックに費やした時間の追跡\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：Premium、Ultimate\n\nエピック内で直接時間をトラッキングして、プロジェクトの時間管理をより細かくコントロールできるようになりました。この新機能を使用すると、プロジェクトに費やされた時間を細分化して記録できるため、スプリントやマイルストーンを進める中で、進捗をモニタリングし、スケジュールを遵守し、予算を管理するのに役立ちます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/time_tracking.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509930)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/epic_time_tracking.png\">\n\n### ロールを使用してプロジェクトメンバーをGitLabコードオーナーとして定義\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：Premium、Ultimate\n\nロールをGitLabコードオーナーとして`CODEOWNERS`ファイルに設定できるようになりました。これにより、ロールベースの技能と承認をより効率的に管理できるようになりました。個別のユーザーを列挙したり、グループを作成したりする代わりに、以下の構文を使用できます。\n\n* `@@developers`：デベロッパーロールが付与されたすべてのユーザーを参照  \n* `@@maintainers`：メンテナーロールが付与されたすべてのユーザーを参照  \n* `@@owners`：オーナーロールが付与されたすべてのユーザーを参照\n\nたとえば、`* @@maintainers`を追加すると、リポジトリにおけるすべての変更に対して、メンテナーによる承認が必要になります。  \nこれにより、プロジェクトにおいてチームメンバーの参加、離脱、またはロールの変更があった場合でも、GitLabコードオーナーを簡単に管理できます。GitLabが指定されたロールを持つすべてのユーザーを自動的に`CODEOWNERS`ファイルに反映するため、手動でファイルを更新することなく、常に最新の状態を維持できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/codeowners/reference.html#add-a-role-as-a-code-owner)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/282438)\n\n### 保護パッケージを使用して依存関係を守る\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\n本リリースでは、PyPIの保護パッケージが新たにサポートされました。こちらは、GitLabパッケージレジストリのセキュリティと安定性を強化することを目的として設計された新機能です。急速に変化するソフトウェア開発の現場では、パッケージを誤って変更または削除してしまった場合、開発プロセス全体に混乱が生じる可能性があります。保護パッケージを使用すると、意図せぬ変更を防いで最も重要な依存関係を保護できます。\n\nGitLab 17.8からは、保護ルールを作成してPyPIパッケージを保護します。保護ルールの条件に合致したパッケージは、指定されたユーザーのみが更新または削除できます。この機能を使用すると、手動による監視の必要性を減らすことにより、意図せぬ変更の防止、規制要件に関連するコンプライアンスの強化、ワークフローの効率化を実現できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/packages/package_registry/package_protection_rules.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/323971)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/protected_pypi_packages.png\">\n\n### Kubernetes用ダッシュボードで一時停止中のFluxの調整を表示\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\nこれまではKubernetes用ダッシュボードでFluxの調整（Flux reconciliation）を一時停止しても、一時停止状態であることを示す明確な指標がありませんでした。本リリースでは、既存のステータス指標に新たに「一時停止」が追加され、Fluxの調整が中断された状態であることが明示されるようになり、デプロイの状態に関する可視性が向上しました。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/501339)\n\n### Webhookイベントのサポート対象に脆弱性を追加\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\n脆弱性に関連するアクションに対してイベントを生成するWebhookインテグレーションが導入されました。これにより、自動化や外部リソースとの統合が可能になります。たとえば、脆弱性の発生時や脆弱性ステータスの変更時にイベントが生成されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#vulnerability-events)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/366770)\n\n\u003Cimg src=\"https://about.gitlab.com/images/unreleased/vulnerabiltiy-webhook.jpg\">\n\n### 脆弱性が修正されたコミットの特定\n\nSaaS：Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\nこれまでは、脆弱性が検出されなくなった場合に、その脆弱性がいつ、どこで修正されたかを確認できませんでした。本リリースより、脆弱性が修正されたコミットSHAへのリンクが表示されるようになったため、トレーサビリティが向上したほか、修正プロセスに関する詳細なインサイトも取得可能になりました。これにより、セキュリティチームと開発チームが連携してより効果的に脆弱性を管理しやすくなりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/372799)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_8/commit-link-vulnerability.png\">\n\n### スケジュールされたスキャン実行パイプラインの並行処理を管理\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：Ultimate\n\nグローバルスケジュール型スキャン実行ポリシーのスケーラビリティを向上させるために、スキャン実行ポリシーに時間枠を設定する機能が新たに導入されました。`time_window`プロパティでポリシーによって新規スケジュールが作成および実行される期間を定義し、最適なパフォーマンスを確保します。\n\n新たに追加されたプロパティを使用するには、YAMLモードを使用してポリシーを更新し、[`time_window`スキーマ](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html#time_window-schema)に従います。スケジュールが実行される時間枠は秒単位で指定できます。たとえば、24時間の時間枠を設定する場合は`86400`と指定します。次に、`distribution: random`フィールドおよび値を指定すると、定義された時間枠でスケジュールがランダムに実行されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html#concurrency-control)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13997)\n\n### コンプライアンスセンターの「フレームワーク」レポートタブのUIパフォーマンスをスケーリング\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：Premium、Ultimate\n\nGitLab 17.8では、バックエンドを改良し、コンプライアンスセンターで一貫した応答性と高速な動作を実現しました。たとえコンプライアンスセンターの「**フレームワーク**」レポートタブに数千件のコンプライアンスフレームワークがある場合でも、この性能は維持されます。\n\nさらに、より詳細な情報を求めて「**フレームワーク**」タブで任意のフレームワークをクリックすると、右側のポップアップメニューに、そのフレームワークに関連付けられているプロジェクト情報が1,000件まで表示されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/477394)\n\n### グループのプロジェクト作成権限にオーナーロールを追加\n\nSaaS：Free、Premium、Ultimate\u003Cbr>\nSelf-Managed：Free、Premium、Ultimate\n\n**プロジェクトの作成許可**設定を使用すると、プロジェクトを作成できる対象者をグループ内の特定のロールに制限できます。本リリースから、オーナーロールがオプションに追加され、新規プロジェクトを作成できる対象者をグループに対してオーナーロールを持つユーザーに制限できるようになりました。このロールは、これまで選択オプションに含まれていませんでした。\n\nこの場を借りて、コミュニティにコントリビュートしてくださった[@yasuk](https://gitlab.com/yasuk)さんに感謝申し上げます！\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/index.html#specify-who-can-add-projects-to-a-group)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/354355)\n\n### 削除予定のサブグループとプロジェクトの表示\n\nSaaS：Premium、Ultimate\u003Cbr>\nSelf-Managed：Premium、Ultimate\n\nグループを削除対象としてマークする際は、影響を受けるすべてのサブグループとプロジェクトを確認する必要があります。これまでは削除対象としてマークされたグループのみに「削除の保留中」ラベルが表示されており、そのサブグループとプロジェクトには表示されていなかったため、削除予定のコンテンツを特定するのは大変でした。\n\n本リリースから、グループが削除対象としてマークされると、そのすべてのサブグループとプロジェクトに「削除の保留中」ラベルが表示されるようになりました。これにより、可視性が向上し、グループ階層全体でアクティブなコンテンツと削除予定のコンテンツを素早く見分けることができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/#view-groups-pending-deletion)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/457718)\n\n## 実験的な機能\n\n### VS CodeでのSASTスキャン\n\nリアルタイムのGitLab SASTスキャンが、実験的な機能としてVS Codeで利用できるようになりました。\n\nプロジェクトファイルをコミットまたはプッシュする前にVS Codeで直接スキャンできるため、セキュリティの脆弱性をこれまでよりも早期に発見して修正できます。SASTスキャンのサイドパネルには、スキャン結果が表示され、コードに変更を加えると更新されます。脆弱性の結果にカーソルを合わせると、詳細な説明が表示されます。またはエディタウィンドウを開いて詳細を確認することも可能です。この機能の利用を開始するには、[こちらのドキュメント](https://docs.gitlab.com/ee/editor_extensions/visual_studio_code/#perform-sast-scanning)をご参照ください。\n\nこの機能は、UltimateプランでGitLab.comをご使用のお客様にご利用いただけます。ぜひ[フィードバック](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1775)をお寄せください。今後段階的に、本機能を改善していく予定です。\n\nデモをご覧になりたい場合は、[VS CodeでのSASTスキャンの動画](https://www.youtube.com/watch?v=KOYdVdA6ZCs)をご視聴ください。\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabでは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームをご利用のすべての方々に、スムーズでシームレスな体験をお届けすることを約束します。\n\n以下のリンクをクリックして、17.8のバグ修正、パフォーマンスの強化、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=17.8)  \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=17.8)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.8)\n\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)* \u003Cbr>\n*（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n\n### 過去の日本語リリース情報\n\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],{"slug":2242,"featured":92,"template":681},"gitlab-17-8-release","content:ja-jp:blog:gitlab-17-8-release.yml","Gitlab 17 8 Release","ja-jp/blog/gitlab-17-8-release.yml","ja-jp/blog/gitlab-17-8-release",{"_path":2248,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2249,"content":2255,"config":2260,"_id":2262,"_type":16,"title":2263,"_source":17,"_file":2264,"_stem":2265,"_extension":20},"/ja-jp/blog/event-report-gartner-it-infra-2024",{"title":2250,"description":2251,"ogTitle":2250,"ogDescription":2251,"noIndex":6,"ogImage":2252,"ogUrl":2253,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2253,"schema":2254},"DevOpsで実現。ソフトウェア開発のセキュリティ・ガバナンス【イベントレポート】","2024年12月に開催された「ガートナー ITインフラストラクチャ、オペレーション＆クラウド戦略コンファレンス」の当社セッションにおいて、ソリューションアーキテクト本部長 大井 雄介が講演しました。その模様をお伝えします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664977/Blog/Hero%20Images/Gartner_cover_image.jpg","https://about.gitlab.com/blog/event-report-gartner-it-infra-2024","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOpsで実現。ソフトウェア開発のセキュリティ・ガバナンス【イベントレポート】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-01-15\",\n      }",{"title":2250,"description":2251,"authors":2256,"heroImage":2252,"date":2257,"body":2258,"category":740,"tags":2259},[738],"2025-01-15","2024年12月、GitLabは「ガートナー ITインフラストラクチャ、オペレーション＆クラウド戦略コンファレンス」に出展しました。このイベントにおいて、ソリューションアーキテクト本部長 大井 雄介が講演いたしましたので、本ブログではその模様をレポートします。\n\n## GitLabはインフラチームにも大きな価値を提供できる\n\n講演の主要トピックは、[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)です。冒頭で大井は、「今回のイベントにはインフラ担当の方が多く参加されていて、このセッションにも多くお越しいただいています。GitLabはアプリ開発担当の方々には良く知られていますが、インフラ担当の皆様にはまだ浸透していないかもしれません。しかし、今日話すのは、インフラ担当の方にこそ、ぜひ聞いていただきたい内容になっています」と会場に語りかけます。\n\nインフラの運用・管理に[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を採用するケースは増加しています。SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）やGitOps（DevOpsをインフラ自動化に適用した運用モデル）を実現するために、何らかのツールが必要だという認識が高まったためです。実際に、ソフトウェア開発のプラットフォームであるGitLabをインフラ側にも適用することで、SSoT（Single Source of Truth；信頼できる唯一の情報源）として機能させられることは大きな価値をもたらします。\n\n![Gartner IT Infra講演の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/FAC306DD-2334-463A-963E-E63AEC8F35EC_1_105_c.jpg)\n*会場の様子*\n\n具体的には、インフラの運用・管理を行うツール群をまたいだSSoTとしてGitLabを利用すると、容易に全体像を把握できます。イシューを積極的に使っていれば、各ツールについて過去の採用から導入、改変の経緯についての詳細をつかむことも可能です。[IaC（Infrastructure as Code：インフラ定義ファイル）](https://about.gitlab.com/ja-jp/topics/gitops/infrastructure-as-code/)を管理しておけば、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインのバージョンが管理できるため、万一のことがあってもデプロイ手順に合わせてロールバックできるようになります。機器／OS＆ミドルウェアの各種設定ファイルの管理や配布も容易です。\n\nこのように、GitLabは[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を実現するプラットフォームでありながら、同時にSREやGitOpsなどインフラの運用・管理に活用できるさまざまな機能を備えた統合プラットフォームと言えるのです。\n\n「GitLabは、インフラチームにも大きな価値を提供できるソリューションであると自負しています」（大井）\n\n## 独立した専任のプラットフォームチームが必要\n\n![Gartner IT Infra講演の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/80582937-4BAD-4DC5-A51A-4B680FB15609_1_105_c.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 本部長 大井 雄介*\n\nエンジニアはソフトウェア開発にあたり、計画、開発、リリースのサイクルを高速に回すことを目指します。コンピュータの登場から今日まで、経営者はエンジニアにそれを求めてきました。\n\nしかし、状況は昔と今では大きく変わりました。かつてのエンジニアはコードを書く能力が第一で、スピーディに高効率なコードを生み出すことが求められていました。そして、美しいコードそのものが、エンジニアの誇りでした。しかしながら、現在はコンテナや[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api/)、セキュリティなど、コード以外のさまざまな知見が求められています。\n\n現在のエンジニアにとって、コードそのものは理解できれば問題ありません。すでにAIがある程度のコードを生成できますから、それを目的に合わせて修正することで業務効率が向上する状況が生まれているためです。最も重要なのは、コードの“周辺領域”を知ることで迅速に成果を出す能力。中でも、多数のクラウドツールの中からそれぞれの特徴を理解し、比較・検討して最適解を使用することは重要なスキルです。ただ、この状況はエンジニアの認知負荷が大幅に高まるという課題を生みました。実際に、エンジニアの認知負荷はかつての10倍になったとも言われています。\n\n必要な知見は多岐にわたるため、一人でカバーできる範囲は限られます。そのために、プロセスは細分化されてきました。必然的に、チーム内でもサイロ化が進むことになります。この状況におけるひとつの最適化のための解が、「プラットフォーム部分を共通化して切り出し、1つのチームに任せる」というものです。全体最適を果たすことを目指した取り組みで、そのために多くの組織で「プラットフォームチーム」が生まれることになりました。\n\n![Gartner プラットフォームチームが担う役割](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/Gartner___________________.jpg)\n\nプラットフォームチームのやるべきことを、上図に示しました。同チームは、各プロジェクトと連携しながら、自動化、セキュリティ、[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api/)、およびインフラについて一元的に管理することになります。これは、インフラを構築／保守する専任のプラットフォームチームが必要になるというガートナーの定義する[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)の考え方に一致します。\n\nプラットフォームチームは、開発チームが生産性高く作業を進めることをサポートします。開発チームの行動を制限しすぎず、一方でリスクの高いツールの使用を許さず、万一の際にはすでにリリースされたアプリケーションであってもすべて検査し、迅速に対処して被害を最小限に抑えます。\n\nプラットフォームチームが正しい方向で[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を推進できれば、開発チームが行うインフラ関連作業はほぼゼロになり、開発スピードの向上、開発サイクルの短期化を期待できます。一貫したコンプライアンス／ガバナンスも実現します。最終成果物次第で許容リスク範囲を増減させるなど柔軟な運用を可能にすることで、生産性とリスクのバランスを取りながら、全体最適を図ることができます。\n\n## セキュリティでは防災も意識してほしい\n\n![GitLab Tanuki](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/8622ADC4-CE48-4E04-8993-5569C4BCF269_1_105_c.jpg)\n*ブースで配布された景品*\n\nさらに、セキュリティ面においても[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)が大きく寄与することが期待されています。経営幹部の多くは、セキュリティと聞くとポリシー策定などの企画部分や、ウイルススキャンなどの運用部分だけに注目しがちです。そのため、多くの企業では企画、運用段階のセキュリティには対応が進んでいます。一方、エンジニアは開発段階にやるべきことがあることを知っています。\n\nたとえば、コードそのものがセキュアであるかどうかを検査しなければなりません。Software Bill of Materials（以下、SBOM：ソフトウェア構成の部品表）を実装し、OSSのソフトウェア・サプライチェーンを可視化し、リスクに備える必要があります。定期検査のプロセスは効率化したいですし、脆弱性発見時の即時検査を行える体制を整えておく必要もあります。外注先の管理も必須で、開発チームとプラットフォームチームにかかわるすべての人に共通するSSoTを備えておくことができれば理想です。\n\n大井は、「企画・運用におけるセキュリティを重視すると、主に“減災”を目指すことになります。確かに減災は必要で、SIEMやSOARは有益なソリューションなのですが、 できれば“防災”も目指したいところです。セキュリティ用語を使えば、サイバー・レジリエンスとともに、サイバー・ハイジーンを追求したいのです」と話します。\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)では、ソフトウェア開発プロセスの早期からセキュリティに取り組むことをシフトレフトと呼び、それを重視しています。つまり、開発段階から防災を意識することになり、DevSecOpsの先進企業はこぞってシフトレフトしています。GitLabでは、数多くのセキュリティスキャン機能を用意し、これらを開発プラットフォームに組み込んでいます。同時に、品質を安定させるガイドラインやポリシーをプロセスに適用できるため、規定どおりに各メンバーが仕事を進めながら防災を目指したソフトウェア開発を徹底することができます。\n\nもちろん、減災を無視してよいわけではありません。開発時にリスクゼロだった依存先OSSでも、リリース後に脆弱性が発見されるケースはあります。こうした際には、SBOMを使って完璧に可視化しておき、リスク別に見分けられるビューも提供しています。\n\n![Gartner GitLab Ultimateのセキュリティスキャン機能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/Gartner_GitLab_Ultimate_____________.jpg)\n\n優れたプラットフォームチームが[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を推進し、GitLabを活用すれば、さらなる価値を得ることもできます。GitLabを開発チームに提供することで得られる多くのメリットもあります。採用したエンジニアは、GitLabの使い方さえ覚えれば、すぐに仕事に慣れて戦力化します。AIを使った生産性の高い開発も可能で、すでにコードの提案機能に対応する言語は25以上になりました。自社が所有するAIモデルとの接続も可能で、社内ポリシーでインターネット経由でのAIサービス利用が制限されているケースにも対応できます。\n\n大井は、「GitLabを全社の共通プラットフォームとして活用することで、インフラチームと開発チームが一体となって仕事を進め、[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)の浸透を加速することができます」と話して講演を締めくくりました。\n\n![GitLab 書籍](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/9CCF584A-1244-4EFC-A6C7-5C39C36B68D5_1_105_c.jpg)\n*書籍*\n\n### 関連記事\n[くら寿司が語るソフトウェア開発の「生産性向上」と「セキュリティ・ガバナンス」の重要性【イベントレポート】](https://about.gitlab.com/ja-jp/blog/event-report-gartner-it-symposium/)",[702,722,280],{"slug":2261,"featured":92,"template":681},"event-report-gartner-it-infra-2024","content:ja-jp:blog:event-report-gartner-it-infra-2024.yml","Event Report Gartner It Infra 2024","ja-jp/blog/event-report-gartner-it-infra-2024.yml","ja-jp/blog/event-report-gartner-it-infra-2024",{"_path":2267,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2268,"content":2274,"config":2280,"_id":2282,"_type":16,"title":2283,"_source":17,"_file":2284,"_stem":2285,"_extension":20},"/ja-jp/blog/getting-started-with-gitlab-how-to-manage-users",{"title":2269,"description":2270,"ogTitle":2269,"ogDescription":2270,"noIndex":6,"ogImage":2271,"ogUrl":2272,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2272,"schema":2273},"GitLab入門：ユーザーの管理方法","グループ、ロール、権限を活用してユーザーを管理する方法と、プロジェクトへのアクセスを適切に設定して安全なコラボレーションを実現するための手順をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097273/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097273817.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab入門：ユーザーの管理方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-14\",\n      }",{"title":2269,"description":2270,"authors":2275,"heroImage":2271,"date":2276,"body":2277,"category":701,"tags":2278,"updatedDate":2279},[2198],"2025-01-14","*「GitLab入門」シリーズへようこそ！このシリーズでは、GitLab DevSecOpsプラットフォームを初めて使う方に向けて、基本的な使い方を解説します。*\n\n安全でコンプライアンスに準拠したコラボレーション環境を作るための第一歩は、ユーザー管理です。このチュートリアルでは、プロジェクトメンバーの設定、ロールと権限の割り当て、グループとサブグループの作成方法についてご説明します。\n\n注：このチュートリアルに沿って進めるには、GitLab.comまたは組織のSelf-ManagedインスタンスでGitLabアカウントをお持ちである必要があります。サポートが必要な場合は、[GitLab University](https://university.gitlab.com/)の基礎コンテンツをご覧ください。\n\nそれでは、始めましょう。\n\nGitLabユーザーを作成すると、そのユーザーは[非公開プロジェクト、公開プロジェクト、および内部プロジェクト](https://docs.gitlab.com/user/public_access/)にのみアクセスできます。このチュートリアルでは、プロジェクトは機密扱いとし、招待されたメンバーだけが各権限設定に応じてアクセスできるようにします。そのためには、ユーザーを[プロジェクトのメンバー](https://docs.gitlab.com/ee/user/project/members/)として招待する必要があります。\n\n## プロジェクトメンバー\n\n![プロジェクトメンバーの画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097278487.png)\nGitLabユーザーをプロジェクトに招待し、[ロールを割り当てる](https://docs.gitlab.com/ee/user/permissions.html)ことで、そのユーザーがプロジェクト内で実行できる操作が決定します。プロジェクトのオーナーは、他のユーザーをメンテナーに任命して、管理タスクを委任できます。メンテナーは、プロジェクトの削除、アーカイブ、転送などの変更を除き、オーナーとほぼ同じ操作を行うことができます。\n\n![メンバー招待画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097278487.png)\n\nプロジェクトの[メンテナー](https://docs.gitlab.com/ee/user/permissions.html#roles)は、他のメンバーをデベロッパーとして招待できます。デベロッパーは、ソフトウェアの作成、ビルド、デプロイに必要なすべての機能にアクセスできます。デベロッパーではないものの、プロジェクト管理へのアクセスが必要なユーザーには、[プランナー](https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)、レポーター、ゲストなどのロールを割り当てて招待できます。これらのロールには、それぞれ異なる権限レベルが設定され、[保護ブランチ](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html)に対する変更権限を誰が持つかを決定するためにも使用されます。\n\n請負業者と作業している場合や、ユーザー権限に有効期限を設定する必要がある場合は、期限日を設定することで、指定日以降にユーザーがプロジェクトへのアクセス権を失うようにできます。また、プロジェクトメンバーは、その[メンバーシップの種類](https://docs.gitlab.com/ee/user/project/members/#membership-types)に基づいて「直接メンバー」と「間接メンバー」に分類されます。直接メンバーはプロジェクトに直接招待されたユーザーであり、間接メンバーは通常、プロジェクトが属する[GitLabのグループ](https://docs.gitlab.com/ee/user/group/)から継承されたメンバーです。\n\n次に、グループメンバーシップについて見ていきましょう。\n\n## グループメンバーシップ\n\nGitLabのグループは、GitLabインスタンスのルートに作成されるトップレベルのコンポーネントとして使用できます。たとえば、[gitlab.com/gitlab-org](http://gitlab.com/gitlab-org)は親グループとして機能し、この親グループの下に[gitlab.com/gitlab-org/charts](http://gitlab.com/gitlab-org/charts)のようなサブグループを作成できます。グループは、プロジェクトが1つしかない場合でも便利です。\n\nグループは、以下の目的で使用できます。\n\n- 類似または関連するプロジェクトを整理する\n- ユーザーをグループ化し、チームの調整をしやすくする\n\n個々のユーザーではなくグループ単位で管理する手順を説明します。チームを各グループにまとめた上で、[グループをプロジェクトに招待](https://docs.gitlab.com/user/project/members/sharing_projects_groups/)します。チーム全体に特定のロールを割り当てます。たとえば、チームのデベロッパーたちには`dev`グループ、プロジェクトマネージャーには`pm`グループ、チームリードには`leads`グループを設定します。グループを招待する際に、`dev`にはデベロッパーロールを、`pm`にはプランナーロールを、`leads`にはメンテナーロールを割り当てます。\n\n![グループ招待画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097279/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097278488.png)\n\n各グループでは、プロジェクト権限を更新することなく、メンバーを追加または削除できます。これは、チームが複数のプロジェクトを管理するようになった場合に特に便利です。しかし、グループを使ったコラボレーションでは、[ベストプラクティスを守る](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html#setting-up-a-group-for-collaboration)ことが重要です。\n\n別の利点として、ユーザーをグループで整理しておくと、イシュー、マージリクエスト、コメント内でグループ全体を[メンション](https://docs.gitlab.com/ee/user/discussions/#mentions)できます。これにより、チーム全体の情報共有が簡単になります。\n\n### サブグループの作成\n\n[サブグループ](https://docs.gitlab.com/ee/user/group/subgroups/)は、グループ内のユーザーをより細かく整理するために使用でき、最大20階層まで追加できます。サブグループ内のユーザーは、親グループで与えられた権限を継承します。サブグループ内のユーザーに、そのユーザーが継承した権限よりも上位のロールを付与するには、新たなロールを指定して[サブグループに招待](https://docs.gitlab.com/ee/user/group/subgroups/#override-ancestor-group-membership)する必要があります。注：サブグループ内で権限を下げることはできません。\n\n### グループの管理\n\nグループのオーナーには、グループ内でユーザーが実行できる操作を設定するためのさまざまな管理オプションがあります。たとえば、ユーザーがグループへのアクセスをリクエストする方法の設定、[グループメンション](https://docs.gitlab.com/ee/user/group/manage.html#disable-group-mentions)の有効化／無効化、[アクセス制限](https://docs.gitlab.com/ee/user/group/manage.html#turn-on-restricted-access)、および[ユーザー管理](https://docs.gitlab.com/ee/user/group/moderate_users.html)などが含まれます。また、この記事の公開時点ではまだ開発中ですが、非アクティブなユーザーを最短90日、最長5年後に[自動的に削除](https://docs.gitlab.com/ee/user/group/moderate_users.html#automatically-remove-dormant-members)する機能が追加される予定です。これにより、グループが整理された状態を保ち、ライセンスシートをより効果的に管理できるようになります。\n\n## もっと詳しく\n\nGitLabでのユーザー管理の方法は、ユースケースによって異なります。GitLabでは、規模が大きく、高度なワークフローを必要とする組織向けに、[エンタープライズユーザーを管理](https://docs.gitlab.com/ee/user/enterprise_user/index.html)するための高度な機能を用意しています。他にも、[組織を管理](https://docs.gitlab.com/ee/topics/set_up_organization.html)するためのさまざまなオプションがあります。[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)を利用すれば、より細かい管理機能やコンプライアンス機能を活用できます。\n\n*次回の「GitLab入門」シリーズは、[プロジェクトをGitLabにインポートする方法（英語。和訳準備中）](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)について解説します*\n\n> #### もっとGitLabについて知りたい場合は、[GitLabユニバーシティのコースに登録](https://university.gitlab.com/)するか、[GitLab Ultimateの無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F)を今すぐお試しください。\n\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)* \u003Cbr>\n*（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n",[904,678,676,1389,701],"2025-05-14",{"slug":2281,"featured":92,"template":681},"getting-started-with-gitlab-how-to-manage-users","content:ja-jp:blog:getting-started-with-gitlab-how-to-manage-users.yml","Getting Started With Gitlab How To Manage Users","ja-jp/blog/getting-started-with-gitlab-how-to-manage-users.yml","ja-jp/blog/getting-started-with-gitlab-how-to-manage-users",{"_path":2287,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2288,"content":2294,"config":2300,"_id":2302,"_type":16,"title":2303,"_source":17,"_file":2304,"_stem":2305,"_extension":20},"/ja-jp/blog/whats-new-in-git-2-48-0",{"title":2289,"description":2290,"ogTitle":2289,"ogDescription":2290,"noIndex":6,"ogImage":2291,"ogUrl":2292,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2292,"schema":2293},"Git 2.48.0の新機能","Gitの最新バージョンについてご紹介します。新たなビルドシステムに加え、最適化された新しいreftableバックエンドが導入されました。また、GitLabのGitチームおよびGitコミュニティによるコントリビュートもご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.48.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }",{"title":2289,"description":2290,"authors":2295,"heroImage":2291,"date":2297,"body":2298,"category":962,"tags":2299,"updatedDate":2075},[2296],"Christian Couder","2025-01-10","Gitプロジェクトは先日[Git 2.48.0](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/)をリリースしました。本記事では、GitLabのGitチームや幅広いGitコミュニティからのコントリビュートなど、このリリースにおけるハイライトをご紹介します。\n\n## Mesonビルドシステム\n\nこれまで長い間、Gitは[Makefile](https://en.wikipedia.org/wiki/GNU_Make)ベースまたは[Autoconf](https://en.wikipedia.org/wiki/Autoconf)ベースのビルドシステムのいずれかを使用してビルドできる仕組みになっていました。しかし、Gitデベロッパーの多くはMakefileベースのビルドシステムを主に利用しており、[Autoconfベースのビルドシステムは機能やメンテナンスの面で後れ](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/)を取っていました。また、Windowsデベロッパーがよく利用する統合開発環境（IDE）は、MakefileやAutoconfベースのビルドシステムを十分にサポートしていないという問題もありました。\n\n2020年に[CMake](https://cmake.org/)を使用したGitのビルドが可能になり、特にVisual Studio向けに、WindowsでのサポートやIDE統合が改善されました。また、out-of-sourceビルドなどのモダンなビルドシステムも追加されました。\n\nしかし、最近ではCMakeのサポートも後れを取っており、前述の2つのビルドシステムを完全に置き換えるには適していない可能性が出てきました。こうした背景から、GitLabのGitエンジニアリングマネージャーである[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が、[Meson](https://mesonbuild.com/)ビルドシステムを導入しました。これにより、最終的にAutoconf、CMake、そして場合によってはMakefileベースのビルドシステムを置き換えることが期待されています。\n\nMesonビルドシステムの主なメリットは以下のとおりです。\n* MakefileやCMakeでは難しいビルドオプションを簡単に確認できる\n* AutoconfやCMakeに比べてシンプルな構文\n* さまざまなOS、コンパイラ、IDEをサポート\n* out-of-sourceビルドなど、モダンなビルドシステムに対応\n\n以下に、Mesonを使用したGitのビルド方法をご紹介します。\n\n```shell\n$ cd git             \t# Gitのソースコードのルートディレクトリに移動\n$ meson setup build/ \t# \"build\"をビルドディレクトリとして設定\n$ cd build           \t# \"build\"ディレクトリに移動\n$ meson compile      \t# Gitをビルド\n$ meson test         \t# 新しいビルドをテスト\n$ meson install      \t# 新しいビルドをインストール\n\n```\n\n`meson setup \u003Cbuild_dir>`を使うことで、複数のビルドディレクトリを設定できます。また、ビルドディレクトリ内で`meson configure`を実行して、そのディレクトリのビルド構成を確認または変更できます。\n\n詳しい手順は、Gitコードリポジトリの[`meson.build`ファイル](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build)の冒頭に記載されています。また、Gitで使用される[ビルドシステムの比較](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt)は、Gitの技術ドキュメントで確認できます。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## Gitのメモリリーク完全解消（テストスイートによる検証済み）\n\n前回のGit 2.47.0リリースに関するブログ記事で触れたように、GitLabでは[プロジェクト内で発生したメモリリークの修正](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#code-refactoring-and-maintainability-improvements)に取り組んできました。その結果、Git 2.47.0リリース以前は、223のテストファイルで確認されていたメモリリークが、最終的に60ファイルまで削減されました。\n\nその後、残りの60ファイルにおけるメモリリークもすべて解消され、テストスイートで検証された範囲では、Gitは完全にメモリリークがない状態となりました。この成果は、Git内部コンポーネントを内部ライブラリに「ライブラリ化（変換）」するという長年の目標に向け大きく前進したことを示しています。また、メモリ使用の最適化にもつながります。\n\n今後、新たに追加されるテストはデフォルトでメモリリークがないことが求められます。リークを含むテストも可能ですが、その場合、作成者は例外的な処理を使用して、メモリリークを解消できない理由を明示する必要があります。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## バンドルURIチェックの改善\n\nGit 2.46.0リリースに関するブログ記事で[Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/)による[バンドルURI修正](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#bundle-uri-fixes)を取り上げました。 その後、Xing Xinは[バンドルを使ったフェッチ](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/)が、通常のフェッチと同様に[fsck](https://git-scm.com/docs/git-fsck)メカニズムで完全に検証されるように改良しました。\n\n通常のフェッチの検証では、[異なるfsckの問題](https://git-scm.com/docs/git-fsck#_fsck_messages)に対して[異なる重大度](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-fsckltmsg-idgt)を指定することで、特定のリポジトリにおいて何を許容し、何を拒否するかを細かく制御できます。しかし、これまでバンドルを使ったフェッチではこうした制御は不可能でした。\n\n[バンドルURI](https://git-scm.com/docs/bundle-uri)の有用性と安全性をさらに高めるために、[この問題を解決](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/)し、バンドルを使ったフェッチの検証にも異なるfsck問題に対して異なる重大度を指定できるようにしました。\n\nこのプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。\n\n## 参照の整合性チェックを追加\n\nGit 2.47.0リリースに関するブログ記事で、[Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF)（GSoC 2024）の一環としてJialuo Sheが[「verify」サブコマンドをgit-refs(1)に追加](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#new-subcommand-for-git-refs\\(1\\))したことについて言及しました。\n\n記事では、最終目標として、この新しいサブコマンドをgit-fsck(1)に統合し、リポジトリの整合性チェックを一元化できるようにすることを挙げました。GSoC終了後、Jialuo Sheはこの統合作業に着手しました。\n\n[この取り組み](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/)の結果、git-fsck(1)は、参照の内容が不適切な場合や、シンボリック参照としてシンボリックリンクが使用された場合、ターゲットが無効な参照を指している場合など、参照に関連するさまざまな問題を検出し処理できるようになりました。git-fsck(1)の一部として`git refs verify`を呼び出し、git-fsck(1)が現在実行しているバックエンドに依存しないすべてのチェックを`git refs verify`が引き継ぐ必要がありますが、参照の整合性チェックを一元化するという最終目標に一歩近づきました。\n\nこのプロジェクトはJialuo Sheが主導しました。\n\n## reftableにおけるイテレータの再利用\n\n[Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt)のリリースでは、参照（主にブランチやタグ）を管理する新しいバックエンドとして「reftable」フォーマットが導入されました。reftableバックエンドについての詳細は、この機能を紹介している過去の[Gitリリースに関するブログ記事](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)や、[reftableの仕組みを詳しく解説した](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)初心者向けガイドをお読みください。\n\n2.45.0以降もバックエンドの改良を重ね、最近では、[内部イテレータの再利用](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/)によってランダムな参照を読み取る際のパフォーマンスを向上させることに注力しました。こうした改善がなされるまでは、単一の参照を読み取るたびに新しいイテレータを作成し、対象のテーブル内の正しい位置を探してそこに移動させ、次の値を読み取る必要があり、多くの参照を短時間で読み取る際にはきわめて非効率でした。しかし、今回の変更により、単一のイテレータを作成し、それを再利用して複数の参照を読み取ることで、処理効率を高められるようになりました。\n\nその結果、reftableに関連するさまざまなユースケースでパフォーマンスが向上しました。特に、ランダム読み取りが頻繁に実行されるトランザクション内で多くの参照を作成する際に、7%の速度向上が確認されています。また、この変更によって、イテレータ内で保持される状態をより多く再利用できるようになるため、最適化がさらに進むと予想できます。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## `git-refs migrate`におけるreflog対応\n\nGit 2.46.0のリリース記事では、[このツールに関する取り組み](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#tooling-to-migrate-reference-backends)に加え、いまだ存在する課題についても次のように言及しています。\n\n「リポジトリ内のreflogは参照バックエンドのコンポーネントであり、フォーマット間の移行も必要となります。残念ながら、現時点ではツールを使用してファイルとreftableバックエンドの間でreflogを変換することはできません」\n\n[この課題はGit 2.48.0で解決](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/)されました。\n`git refs migrate`を使うことでreflogの移行も可能になりました。複数のワークツリーを持つリポジトリを扱うことはまだできませんが、残された課題はこの一点のみであり、ワークツリーを使用していない場合は、既存のリポジトリでreftableバックエンドをすでに利用することが可能です。\n\nこのプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n## Ref-filterの最適化\n\n「ref-filter」サブシステムは、`git for-each-ref`、`git branch`、`git tag`といったコマンドで使用されるフォーマットコードで、Git参照に関連する情報を並べ替え、フィルタリング、フォーマット、表示する役割を担っています。\n\nリポジトリの規模が大きくなるにつれて、扱う参照の数も増加します。そのため、reftableバックエンドなどの参照を保存するバックエンド（上記参照）の改善だけでなく、「ref-filter」サブシステムのようなフォーマットコードの最適化にも取り組んでいます。\n\n今回、ref-filterのコードでバックエンドの順序通りに参照を処理すべき場合に、参照の一時的なバッファリングやイテレーション処理を不要にする[方法を特定](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/)しました。この結果、メモリの節約が可能になり、特定のコマンドでは処理速度が最大で770倍も速くなるケースが確認されています。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## 補足情報\n\nこのブログ記事では、最新リリースにおけるGitLabや広範なGitコミュニティによるコントリビュートの一部をご紹介しました。詳細は、Gitプロジェクトの公式リリース発表をご覧いただくと詳細をご確認いただけます。また、[これまでのGitリリースに関するブログ記事](https://about.gitlab.com/blog/tags/git/)では、GitLabチームの過去のコントリビュートもハイライトされていますので、ぜひご確認ください。\n\n- [Git 2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)（英語）\n- [Git 2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)（英語）\n- [Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)\n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)\n\n\u003Cbr>\n*監修：小松原 つかさ* [*@tkomatsubara*](https://gitlab.com/tkomatsubara)\u003Cbr>\n*（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[966,825,270],{"slug":2301,"featured":92,"template":681},"whats-new-in-git-2-48-0","content:ja-jp:blog:whats-new-in-git-2-48-0.yml","Whats New In Git 2 48 0","ja-jp/blog/whats-new-in-git-2-48-0.yml","ja-jp/blog/whats-new-in-git-2-48-0",{"_path":2307,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2308,"content":2314,"config":2320,"_id":2322,"_type":16,"title":2323,"_source":17,"_file":2324,"_stem":2325,"_extension":20},"/ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":2309,"description":2310,"ogTitle":2309,"ogDescription":2310,"noIndex":6,"ogImage":2311,"ogUrl":2312,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2312,"schema":2313},"CI/CD完全ガイド：基礎から高度な実装まで","パイプラインの開発、デリバリー、セキュリティまでを自動化した継続的インテグレーションおよび継続的デプロイの最新手法をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CI/CD完全ガイド：基礎から高度な実装まで\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2025-01-06\",\n      }",{"title":2309,"description":2310,"authors":2315,"heroImage":2311,"date":2317,"body":2318,"category":740,"tags":2319,"updatedDate":2201},[2316],"Sandra Gittlen","2025-01-06","継続的インテグレーション／継続的デリバリー（[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)）によって、ソフトウェアチームがユーザー向けに価値を生み出す方法は大きく変わりました。手動によるデプロイやインテグレーションに煩わされていた時代は過ぎ去り、最新の開発においては自動化、信頼性、そしてスピードが求められています。\n\nCI/CDの本質は、開発環境から本番環境にいたるまでコードが自動的かつ信頼性高く実行され、リアルタイムでフィードバックを取り入れるシームレスなパイプラインを作成することです。[CI](https://about.gitlab.com/ja-jp/topics/ci-cd/benefits-continuous-integration/)の目的は、コードの変更を頻繁に共有リポジトリにマージし、自動的にテストし検証することで、問題解決に伴う余分なコストが生じる前にチームが問題を早期に発見できるようにすることです。[CD](https://about.gitlab.com/ja-jp/topics/ci-cd/#what-is-continuous-delivery-cd)はこれをさらに発展させ、デプロイプロセスを自動化することで、リリースを予測可能でストレスなく行えるようにします。\n\nソフトウェア開発において手作業のプロセスや複雑なツールチェーンに頼るのではなく、堅牢なCI/CDパイプラインを使用してソフトウェアをビルド、テスト、デプロイできます。また、AIによってプロセスの効率化をさらに進め、品質、コンプライアンス、セキュリティチェックの一貫性を保ちながら、CI/CDパイプラインを自動的に設計することが可能になります。\n\nこのガイドでは、基本原則からベストプラクティス、高度な戦略まで、最新のCI/CDパイプラインに関する内容を説明します。また、先進企業がCI/CDをどのように使用して効果的に成果をあげているかについても取り上げます。このガイドでご紹介する内容は、DevSecOps環境をスケールし、[アジャイル](https://about.gitlab.com/ja-jp/topics/ci-cd/continuous-integration-agile/)で自動化された効率的な方法でソフトウェアを開発し、デリバリーする上で役立ちます。\n\nご紹介する内容：\n- 継続的インテグレーションとは\n- 継続的なデリバリーとは\n- ソースコード管理とCI/CDの関係\n- 現代のソフトウェア開発においてCI/CDを利用するメリット\n  - CI/CDと従来の開発の主な相違点\n- CI/CDの基礎を理解する\n  - CI/CDパイプラインとは\n- CI/CDの実装と管理のベストプラクティス\n  - CIのベストプラクティス\n  - CDのベストプラクティス\n- CI/CDの開始方法\n- セキュリティ、コンプライアンス、CI/CD\n- CI/CDとクラウド\n- 高度なCI/CD\n  - CI/CDにおける再利用と自動化\n  - AIによるパイプラインのトラブルシューティング\n- GitLab CI/CDへの移行方法\n- 大手企業から学ぶ教訓\n- CI/CDのチュートリアル\n\n## 継続的インテグレーションとは\n\n[継続的インテグレーション](https://about.gitlab.com/ja-jp/topics/ci-cd/benefits-continuous-integration/)（CI）とは、すべてのコード変更を共有ソースコードリポジトリのmainブランチに早い段階で頻繁に統合し、コミットまたはマージ時に変更内容を自動的にテストし、自動的にビルドを開始する手法のことです。継続的インテグレーションを行うことで、チームはエラーやセキュリティの問題を開発プロセスの初期段階で簡単に特定し、修正できます。\n\n## 継続的デリバリーとは\n[継続的デリバリー](https://about.gitlab.com/ja-jp/topics/ci-cd/#what-is-continuous-delivery-cd)（CD）は、「*継続的デプロイ*」と呼ばれることもあります。継続的デリバリーを行うことで、組織はアプリケーションを自動的にデプロイできるため、デベロッパーがデプロイ状況のモニタリングと成功の確認に専念できる時間を増やすことができます。継続的デリバリーでは、DevSecOpsチームが事前にコードのリリース基準を設定します。その基準が満たされて検証が完了すると、本番環境にコードがデプロイされます。これにより組織は俊敏性を高め、新機能をもっと迅速にユーザーに提供できるようになります。\n\n## ソースコード管理とCI/CDの関係\n\nソースコード管理（[SCM](https://about.gitlab.com/ja-jp/solutions/source-code-management/)）とCI/CDは、現代のソフトウェア開発手法の基盤と言えます。[Git](https://about.gitlab.com/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/)のようなSCMシステムは、変更の追跡、コードの各バージョンの管理、チームメンバー間のコラボレーションをスムーズに連携させる一元的な仕組みになっています。デベロッパーは新機能やバグ修正に取り組む際に、メインコードベースからブランチを作成して変更を加え、[マージリクエスト経由で変更をマージ](https://docs.gitlab.com/ee/user/project/merge_requests/)します。このようなブランチ戦略により、複数のデベロッパーが互いのコードに干渉することなく同時に作業を進められるだけでなく、常に本番環境で使用可能なコードが含まれる、安定したmainブランチを維持できます。\n\nCI/CDは、SCMシステムで管理されているコードを取得し、変更がプッシュされるたびに自動的にビルド、テスト、および検証を行います。デベロッパーがコードの変更を提出すると、CI/CDシステムは自動的に最新のコードを取得し、既存のコードベースに追加して、一連の自動チェックを実行します。これには通常、コードのコンパイル、ユニットテストの実行、静的コード解析の実施、コードカバレッジのチェックが含まれます。これらのステップのいずれかが失敗すると、すぐにチームに通知されます。チームが迅速に問題に対処できるため、他のデベロッパーへの影響を最小限に抑え本番環境への問題流出も防ぐことができます。このようなソース管理と継続的インテグレーションの緊密な連携により、フィードバックループが自動化され、従来の手動テストでは発見が遅れがちだった問題も早期に捉えられるようになり、コードの品質を維持できます。\n\n## 現代のソフトウェア開発においてCI/CDを利用するメリット\n\n新機能やバグ修正の提供に伴う時間とリスクを大幅に削減する[CI/CDは、現代のソフトウェア開発に革新的なメリットをもたらします](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/)。継続的なフィードバックループにより、DevSecOpsチームには、変更がコードベース全体と照らし合わせて自動的に検証されることが保証されます。結果として、ソフトウェアの品質の向上、デリバリーの高速化の実現に加え、リリースの頻度も増加するため、ユーザーのニーズや市場の需要に素早く対応できるようになります。\n\n最も重要なメリットはおそらく、CI/CDによってソフトウェア開発チーム内でコラボレーションと透明性の文化が育まれることです。誰もがビルド、テスト、デプロイの状況をリアルタイムで確認できれば、デリバリープロセスにおけるボトルネックの特定や解決が容易になります。また、CI/CDによって実現される自動化により、デベロッパーの認知負荷が軽減されます。そのため、デプロイプロセスを手動で管理する必要がなくなり、コーディング作業に注力できるようになります。その結果、デベロッパーの満足度と生産性が向上するとともに、これまでソフトウェアのリリースプロセス全体において生じていたリスクも減少します。迅速なコードレビューがCI/CDプロセスの標準プロセスとなり、必要に応じて素早く変更をロールバックできることをチームが理解しているため、より自由に実験を行うことができ、イノベーションと継続的な改善が促進されます。\n\n> GitLab CI/CDの利用を開始しましょう。[GitLab Ultimate](https://about.gitlab.com/ja-jp/free-trial/devsecops/)に登録して、AI搭載のDevSecOpsプラットフォームを無料でお試しください。\n\n### CI/CDと従来の開発の主な相違点\n\nCI/CDは、以下のような点で従来のソフトウェア開発とは異なります。\n\n**頻繁なコードコミット**\n\n大抵の場合、デベロッパーは単独で作業することが多く、コードをメインコードベースにアップロードする頻度が低いことから、マージの競合を始めとして、時間のかかる問題が発生しがちです。CI/CDの場合、デベロッパーは一日の中で頻繁にコミットをプッシュするため、競合を早いうちに発見でき、コードベースを最新の状態に保つことができます。\n\n**リスクの低減**\n\n長いテストサイクルとリリース前に行う大規模なプランニング作業は、従来のソフトウェア開発の特徴と言えます。リスクを最小化する目的で行われるものの、結果として問題の発見と修正の迅速さが犠牲になることも少なくありません。CI/CDでは、簡単に元に戻せる小規模の変更を段階的に適用し、注意深くモニタリングする方法でリスクを管理します。\n\n**継続的に実施される自動テスト**\n\n従来のソフトウェア開発では、開発が完了したタイミングでテストを行います。しかし、このやり方だと、納期の遅れやコストのかかるバグ修正などの問題が生じます。 CI/CDでは、コードをコミットするたびに自動テストが実行され、開発工程全体を通じて継続的にテストが行われます。さらに、デベロッパーにはタイムリーにフィードバックが提供されるため、それをもとに素早く対処できます。\n\n**繰り返し頻繁に実施可能で、自動化されたデプロイプロセス**\n\nCI/CDでは、デプロイプロセスは自動化されるため、大規模なソフトウェアのロールアウトに伴うストレスと手間が軽減されます。複数の環境で同じデプロイプロセスを繰り返し実行できるため、作業時間の短縮に加え、エラーや不整合を削減できます。\n\n## CI/CDの基礎を理解する\n\nCI/CDは、スケーラブルで保守しやすいデリバリープロセスを構築するためのフレームワークとして機能します。そのため、DevSecOpsチームが核となる概念をしっかりと把握しておくことは非常に重要です。CI/CDの原則を十分に理解することで、チームは従来のアプローチに縛られずに、テクノロジーの進化に合わせて戦略と手法を適応させることができます。ここでは、基本的な内容をいくつかご紹介します。\n\n### CI/CDパイプラインとは\n\n[CI/CDパイプライン](https://about.gitlab.com/ja-jp/topics/ci-cd/cicd-pipeline/)とは、ビルド、テスト、デプロイなどの一連のステップから成り、ソフトウェアデリバリープロセスを自動化および効率化するものです。[各ステージは品質ゲートとして機能し](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/)、検証されていないコードが次のステージに進むことのないように防ぎます。初期ステージでは通常、コンパイルやユニットテストなどの基本的なチェックを行います。後のほうのステージではインテグレーションテストやパフォーマンステスト、コンプライアンステストに加え、さまざまな環境への段階的なデプロイを行う場合があります。\n\n本番環境へのデプロイ前などの重要なタイミングでは、手動による承認を必要とするようにパイプラインを設定できます。その一方で、ルーチンタスクは自動化し、変更の健全性に関するフィードバックを迅速にデベロッパーに提供することが可能です。このような体系的なアプローチにより、一貫性の保証、ヒューマンエラーの削減の実現に加え、コード変更が開発環境から本番環境にどのように移行したかを明確に追跡できます。最新のパイプラインはコードとして実装されることが多いため、アプリケーションコードと同様に、バージョン管理、テスト、保守を行えます。\n\nCI/CDに関連する重要な用語をご紹介します。\n\n- **コミット**：コードの変更\n- **ジョブ**：Runnerが実行すべき命令\n- **Runner**：個々のジョブを実行するエージェントやサーバーで、必要に応じて起動または停止できる\n- **ステージ**：「ビルド」や「デプロイ」といった特定のジョブステージを定義するキーワード。同じステージにあるジョブは同時に実行される。プロジェクトのルートレベルでバージョン管理されたYAMLファイル（`.gitlab-ci.yml`）を使用して、パイプラインの設定を行う\n\n![CI/CDパイプラインの図](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673928/Blog/Content%20Images/1690824533476.png)\n\n## CI/CDの実装と管理のベストプラクティス\nCI/CDの実装によりどれだけ成功を収められるかどうかは、どの[ベストプラクティス](https://about.gitlab.com/ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices/)を取り入れるかに大きく依存します。\n\n#### CIのベストプラクティス\n\n* コミットを早めかつ頻繁に行う\n* パイプラインステージを最適化する\n* ビルドを迅速かつシンプルに\n* 失敗を活かしてプロセスを改善する\n* 必ず本番環境を模したテスト環境を構築する\n\n#### CDのベストプラクティス\n\n* 現状からはじめる。いつでもイテレーションを行える\n* 最小限のツールで最適な継続的デリバリーを行えることを理解する\n* 問題やマージリクエストが制御不能ならないよう、何が起きているかを追跡する\n* 自動化によってユーザー受け入れテストとステージングを効率化する\n* 自動化を通じてリリースパイプラインを管理する\n\n> ### ブックマークに登録しましょう！\n>\n>ぜひ[「CI/CD入門」ウェビナー](https://www.youtube.com/watch?v=BhmF29sUc48)をご視聴ください。\n>\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/BhmF29sUc48?si=vGF8wNdhyQof9aFC\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n## CI/CDの開始方法\n\nCI/CDを導入する際は、まずはパイロットプロジェクトとして、シンプルながら代表的なプロジェクトを選定する必要があります。基本的なテスト要件を備えた、シンプルなアプリケーションが最適です。そうすれば、複雑なデプロイシナリオに対処せずに済み、パイプラインの仕組みを学ぶことに集中できます。まずは、コードが[バージョン管理](https://about.gitlab.com/ja-jp/topics/version-control/)されており、[基本的な自動テスト](https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci/)（ユニットテストだけでも十分です）が設定されているかどうかを確認してください。理解度が深まるにつれて徐々に拡張できるように、[最小限のパイプラインを作成する](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/)ことを目指します。\n\nGitLabでは、具体的には、プロジェクトのルートディレクトリに`.gitlab-ci.yml`ファイルを作成することから始めます。このYAMLファイルでは、パイプラインのステージ（ビルド、テスト、デプロイなどの基本的なもの）とジョブを定義します。  \nシンプルなパイプラインの場合、  \nビルドステージではコードをコンパイルしてアーティファクトを作成  \nテストステージではユニットテストを実行  \nデプロイステージではアプリケーションをステージング環境にプッシュする  \nといった構成になります。  \nGitLabはこのファイルを自動的に検出し、リポジトリに変更がプッシュされるたびにパイプラインの実行を開始します。GitLabプラットフォームには、パイプラインジョブを実行する[ビルトインのRunner](https://docs.gitlab.com/runner/)が用意されていますが、より細かく制御したい場合はご自身でRunnerを設定することも可能です。\n\n基本に慣れてきたら、少しずつより高度なコンポーネントをパイプラインに追加していきます。コード品質チェック、[セキュリティスキャン](https://docs.gitlab.com/ee/user/application_security/#security-scanning)、本番環境への自動デプロイなどを実装してみてもよいかもしれません。GitLabのDevSecOpsプラットフォームには、[コンプライアンス管理](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)、[デプロイ変数](https://about.gitlab.com/blog/demystifying-ci-cd-variables/)、手動での承認ゲートなど、パイプラインの成熟に伴って組み込むことができる機能が含まれます。パイプラインの実行時間に注意しつつ、可能であれば並行してジョブを実行できる箇所を探しましょう。必ず適切なエラー処理と通知を追加して、パイプラインが失敗した場合にチームメンバーに速やかに通知されるようにします。一般的な問題が生じたり、解決策が見つかったりしたら、文書化するようにしましょう。ドキュメントはチーム規模が拡大するにつれ非常に役に立ちます。\n\n> ### CI/CDの開始方法についてさらに詳しく知りたい場合は、[GitLab Universityで無料のCI/CDコース](https://university.gitlab.com/courses/gitlab-with-git-essentials-s2-jp)にご登録ください\n\n## セキュリティ、コンプライアンス、CI/CD\nCI/CDを利用する最大のメリットの1つは、ソフトウェア開発ライフサイクルの早い段階において頻繁にセキュリティとコンプライアンスのチェックを組み込めることです。GitLabでは、`.gitlab-ci.yml`での設定を用いて、最初のコードコミットから本番環境へのデプロイまで複数のステージでセキュリティスキャンを自動的にトリガーすることができます。GitLabプラットフォームのコンテナスキャン、依存関係スキャン、セキュリティスキャン機能（[動的アプリケーションセキュリティテスト](https://docs.gitlab.com/ee/user/application_security/dast/)および[高度なSAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/)）は、コードが変更されるたびに自動的に実行され、脆弱性、コンプライアンス違反、セキュリティの設定ミスの有無をチェックするように設定できます。また、GitLabプラットフォームのAPIを使用すると、[外部のセキュリティツールとの連携も可能です](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)。テストカバレッジ機能は、セキュリティテストが必要な基準を満たしているかを確認できます。\n\nGitLabのセキュリティテストレポートでは、調査結果に関する詳細情報を確認できるため、セキュリティ問題が本番環境に到達する前に素早く修正できます。プロジェクト全体における脆弱性は、セキュリティダッシュボードで一元的に確認でき、[セキュリティポリシーの適用](https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/)は、マージリクエストの承認とパイプラインゲートによって行えます。さらに、CI/CDプロセス全体で機密情報を保護するための多層的なシークレット管理、シークレットへのアクセスを追跡するための監査ログ、許可されたユーザのみが機密性の高い設定データを閲覧または変更できるようにするロールベースのアクセス制御（RBAC）などの機能も備えています。\n\nGitLabはソフトウェア部品表（[SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)）の生成もサポートしています。チームは、アプリケーション内のすべてのソフトウェアコンポーネント、依存関係、ライセンスの包括的なインベントリを生成して、脆弱性を迅速に特定して対応し、規制要件に準拠することが可能です。\n## CI/CDとクラウド\n\nGitLabのCI/CDプラットフォームは、[Amazon Web Services](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)や[Google Cloud Platform](https://about.gitlab.com/blog/provision-group-runners-with-google-cloud-platform-and-gitlab-ci/)、[Microsoft Azure](https://docs.gitlab.com/ee/install/azure/)などの主要クラウドプロバイダーとの強力なインテグレーションが可能なため、パイプラインから直接クラウドへのデプロイを自動化することができます。GitLabのクラウド連携機能を使用すれば、クラウドリソースの管理、アプリケーションのデプロイ、クラウドサービスのモニタリングをすべてGitLabインターフェイス内で行えます。GitLabに標準搭載されているクラウドデプロイテンプレートと[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/)機能により、クラウドデプロイの手間が大幅に軽減されるため、チームはインフラ管理よりもアプリケーション開発に注力できます。GitOpsを使用してITインフラストラクチャを自動化したい組織向けに、GitLabでは[Flux CDインテグレーションも提供しています](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/)。\n\nGitLabのクラウド機能は、基本的なデプロイの自動化にとどまりません。GitLabプラットフォームの[Kubernetesインテグレーション](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/)を使用すると、複数のクラウドプロバイダー間でコンテナオーケストレーションを管理できます。また、[クラウドネイティブのGitLabインストールオプション](https://about.gitlab.com/ja-jp/topics/ci-cd/cloud-native-continuous-integration/)が用意されているため、クラウド環境でプラットフォーム自体を実行することも可能です。GitLabのクラウドネイティブ機能により、チームはパイプライン実行用にクラウドリソースを動的にプロビジョニングする自動スケーリングランナーを実装して、コストとパフォーマンスを最適化できます。GitLabプラットフォームとクラウドプロバイダーのセキュリティサービスとのインテグレーションにより、デプロイプロセス全体を通してセキュリティとコンプライアンスの要件が確実に満たされます。\n\nGitLabはマルチクラウド環境向けには、基盤となるクラウドプロバイダーに関係なく一貫したワークフローとツールを提供します。開発環境、ステージング環境、本番環境でそれぞれ異なるクラウド設定を管理したい場合もGitLabの環境管理機能で対応可能です。GitLabプラットフォームによる[infrastructure as code](https://docs.gitlab.com/ee/user/infrastructure/iac/)のサポート、特にTerraformとのネイティブなインテグレーションにより、チームは、クラウドインフラストラクチャのプロビジョニングをバージョン管理し自動化できます。GitLabのモニタリングと可観測性の機能は、クラウドプロバイダーのメトリクスと連携しているため、ク\n\n## 高度なCI/CD \nCI/CDは、単純なビルドとデプロイのパイプラインからはるかに進化を遂げてきました。CI/CDを高度に実装する場合、自動テスト、セキュリティスキャン、インフラストラクチャのプロビジョニング、AI活用など、高度なオーケストレーションが必要となります。ここでは、アーキテクチャが複雑化していく中でも、エンジニアリングチームがパイプラインをスケールし、問題をトラブルシューティングする際に役立つ高度なCI/CD戦略をいくつかご紹介します。\n\n### CI/CDにおける再利用と自動化\n\nGitLabは、開発チームによるCI/CDパイプラインの作成・管理方法を2つの革新的な機能で一新しています。一つは「[CI/CDカタログ](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)」、もう一つは「[CI/CDステップ](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/)」（現在、実験段階にあるDevSecOps自動化のための新しいプログラミング言語）です。CI/CDカタログは、デベロッパーがCI/CDコンポーネントを検索、再利用、コントリビュートできる一元化されたプラットフォームです。コンポーネントは、CI/CDワークフローにおける「レゴブロック」のような再利用可能な単機能パーツとして、パイプライン設定を簡素化します。また、CI/CDステップは、デベロッパーがCI/CDジョブの入出力を設定できるようにすることで、複雑なワークフローをサポートします。DevSecOpsチームはCI/CDカタログとCI/CDステップを活用することで、CI/CDとそのコンポーネントを簡単に標準化すると同時に、CI/CDパイプラインの開発と保守のプロセスを簡素化できます。\n\n> 詳しくは、[CI/CDカタログのFAQ](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)と[CI/CDステップのドキュメント](https://docs.gitlab.com/ee/ci/steps/)をご覧ください。\n\n### AIによるパイプラインのトラブルシューティング\n\nCI/CDパイプラインが壊れることは実際にあり得ますが、問題を素早くトラブルシューティングすれば、影響を最小限にとどめられます。GitLabが提供するAI機能「GitLab Duo」の一つである「根本原因分析」は、これまでデベロッパーの経験や勘に頼っていた部分を自動化し、[CI/CDパイプラインで発生した失敗の根本原因を特定](https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/)します。GitLabでは、パイプラインが失敗すると、失敗した場所と原因を具体的に示す詳細なジョブログ、エラーメッセージ、実行トレースが提供されます。その後、根本原因分析により、AIを使用して修正を提案します。 以下の動画で、GitLab Duo根本原因分析機能の実際の動作をご覧ください。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n## GitLab CI/CDへの移行方法\n\nDevSecOpsプラットフォームとビルトインのCI/CDに移行する際は、既存のパイプライン設定や依存関係、デプロイプロセスを分析し、GitLabの対応する機能と構文にマッピングする体系的なアプローチを取る必要があります。移行プロセスを開始する際は、以下のガイドをご参照ください。\n\n* [BambooからGitLab CI/CDへの移行方法](https://about.gitlab.com/blog/migrating-from-bamboo-to-gitlab-cicd/)（英語）\n* [JenkinsからGitLabへ：CI/CD環境のモダナイズに関する完全ガイド](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)（英語）\n* [GitHubからGitLabへの簡単な移行方法](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)（英語）\n\n## 先進企業から学ぶ教訓\n\nGitLab に移行し、CI/CD の様々なメリットを実感している先進企業の事例をご紹介します。各社の事例をぜひご覧ください。\n\n- [ロッキード・マーティン社](https://about.gitlab.com/ja-jp/customers/lockheed-martin/)\n- [Indeed社](https://about.gitlab.com/ja-jp/blog/how-indeed-transformed-its-ci-platform-with-gitlab/)\n- [CARFAX社](https://about.gitlab.com/ja-jp/customers/carfax/)\n- [HackerOne社](https://about.gitlab.com/ja-jp/customers/hackerone/)\n- [Betstudios社](https://about.gitlab.com/blog/betstudios-cto-on-improving-ci-cd-capabilities-with-gitlab-premium/)\n- [タレス社とカルフール社](https://about.gitlab.com/blog/how-carrefour-and-thales-are-evolving-their-ci-cd-platforms/)\n\n## CI/CDのチュートリアル\n\n以下にご紹介する簡単なチュートリアルを行って、CI/CDのエキスパートになりましょう。\n\n* * [CI入門：ジョブを順番どおりに、並列に、または順不同で実行する方法](https://about.gitlab.com/ja-jp/blog/basics-of-gitlab-ci-updated/)  \n* [初めてのGitLab CI/CDコンポーネントのセットアップ方法](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)（英語）  \n* [モノレポ用にGitLab CI/CDパイプラインを簡単に構築する方法](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)（英語）  \n* [子パイプラインの使用による5つの環境への継続的デプロイメント](https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/)（英語）  \n* [CI/CDの自動化：GitLabグループ全体で「デプロイフリーズ」の影響を最大化する](https://about.gitlab.com/blog/ci-cd-automation-maximize-deploy-freeze-impact-across-gitlab-groups/)（英語）  \n* [CI/CDテンプレートをCI/CDコンポーネントにリファクタリングする](https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component/)（英語）  \n* [GitLab CI/CDでCosignを使ってコンテナイメージにビルドの来歴を付ける](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd)（英語）\n\n> #### GitLab CI/CDの利用を開始しましょう。[GitLab Ultimateに登録](https://gitlab.com/-/trials/new)して、AI搭載のDevSecOpsプラットフォームを無料でお試しください。\n\n\u003Cbr>\u003Cbr>\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[110,702,904,676,722,701],{"slug":2321,"featured":92,"template":681},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation","content:ja-jp:blog:ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","Ultimate Guide To Ci Cd Fundamentals To Advanced Implementation","ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"_path":2327,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2328,"content":2334,"config":2340,"_id":2342,"_type":16,"title":2343,"_source":17,"_file":2344,"_stem":2345,"_extension":20},"/ja-jp/blog/gitlab-17-7-release",{"title":2329,"description":2330,"ogTitle":2329,"ogDescription":2330,"noIndex":6,"ogImage":2331,"ogUrl":2332,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2332,"schema":2333},"GitLab 17.7リリース","GitLab 17.7でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662186/Blog/Hero%20Images/product-gl17-blog-release-cover-17-7-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-7-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.7リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-12-19\",\n      }",{"title":2329,"description":2330,"authors":2335,"heroImage":2331,"date":2336,"body":2337,"category":701,"tags":2338,"updatedDate":2339},[738],"2024-12-19","**プランナーユーザーロールを新たに追加したGitLab 17.7をリリース**\n\nこのたび、GitLab 17.7のリリースを発表しました。今回のリリースでは、プランナーという新たなユーザーロール、脆弱性の自動解決ポリシー、管理者が制御可能なインスタンスのインテグレーションの許可リスト、UIでのアクセストークンローテーションなどが追加されました！\n\nこれらの機能は、今回のリリースに含まれる230件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 17.7には、GitLabコミュニティのユーザーから138件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。  \n\n来月のリリースで予定されている内容を先取りするには、17.8リリースのキックオフビデオも視聴できる[今後のリリースページ](https://about.gitlab.com/direction/kickoff/)をご覧ください。\n\n> [GitLab 17.7のリリースでは、プランナーというユーザーロールが新たに追加されました。クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+17.7+released+with+new+Planner+user+role&url=https://about.gitlab.com/releases/2024/12/19/gitlab-17-7-released/&hashtags=)\n\n## 今月のMost Valuable Person [MVP](https://about.gitlab.com/community/mvp/)は[Vedant Jain](https://gitlab.com/vedant-jain03)さんが受賞\n\nMVPには、誰もが[GitLabコミュニティのコントリビューターを推薦](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)できます。現在の候補者を応援したり、他の誰かをノミネートしてみませんか。🙌\n\nVedantさんは、コミュニティのコントリビューターとして活躍されていて、コントリビュートに対する積極的なアプローチ、デリバリーへのコミットメント、そしてコラボレーションスキルで知られています。フィードバックを受け入れ、それを作業に取り入れ、必要な場合は支援を求めることに長けていて、コントリビュートを完了させるだけでなく、常にGitLabの基準を満たしてくれています。\n\nVedantさんのコントリビュートには、[抽象化された作業アイテム属性を単一のリスト／ボードにまとめた](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172191)プロジェクト管理プロセスの効率化、[作業アイテムのメタデータの並べ替え](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173033)、[作業アイテムウィジェットの折りたたみ状態を記憶する](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/171228)機能の開発などがあります。また、UIのドキュメントへのリンクを修正し（[1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170633)、[2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170534)）、製品全体のユーザーエクスペリエンスを改善する重要な取り組みの一環として、テクニカルライティングチームを支援しました。\n\nGitLabのプロダクトプランニング担当シニアプロダクトマネージャーである[Amanda Rueda](https://gitlab.com/amandarueda)は、Vedantさんを推薦し、彼の積極的でコミュニティ指向の考え方について次のように述べました。「Vedantさんは業務を通じて、ユーザーのニーズに対応するだけでなく、コントリビュートにより安定性と信頼性をより一層高めたGitLab環境をともに作り上げてくれています。バグの修正、ユーザビリティの改善、メンテナンスの取り組みにコントリビュートすることで、製品の全体的な品質を向上させる上で重要な役割を担っています。Vedantさんの積極的なアプローチとグループの枠にとらわれないコントリビュートは、イテレーション、顧客とのコラボレーション、継続的な改善というGitLabのコアバリューを体現しており、彼はコミュニティの中でも傑出したコントリビューターと言えます」\n\n今回の受賞に関して、Vedantさんは次のように述べています。「ご協力いただいたみなさんのおかげです。良い影響を与えることができたことにとても感謝しており、これからもより多くのコントリビュートをしていきたいと思います」\n\nVedantさんは、最新のデータチーム向けのアクティブなメタデータプラットフォームであるAtlanのフロントエンドエンジニアであり、Google Summer of Code（GSOC）2024のメンターも務めています。\n\nVedantさんのコントリビュートを始め、GitLabにコントリビュートしてくださっているオープンソースコミュニティのみなさまに心より感謝します！\n\n## GitLab 17.7でリリースされた主な改善点\n\n### プランナーという新たなユーザーロール\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nプランナーというロールが新たに導入されました。これにより、[権限](https://docs.gitlab.com/ee/user/permissions.html)を過剰に付与することなく、エピック、ロードマップ、Kanbanボードなどのアジャイルプランニングツールへのアクセスをカスタマイズできます。この変更により、ワークフローを安全に保ち、最小権限の原則を守りながら、コラボレーションをより効果的に行うことができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/permissions.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/482733)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_7/new_planner_user_role.png\">\n\n### インスタンス管理者がどのインテグレーションを有効にするか設定可能に \nSaaS: -  \nSelf-Managed: Ultimate\n\nインスタンス管理者は、GitLabインスタンスで有効にするインテグレーションを許可リストで設定できるようになりました。空欄の許可リストを設定した場合、インスタンス上でインテグレーションは許可されません。許可リストの設定後、デフォルトでは新しいGitLabインテグレーションは許可リストに含まれません。\n\n以前に有効にしていたインテグレーションを後から許可リストの設定によってブロックした場合、そのインテグレーションは無効になります。これらのインテグレーションを再度許可すると、既存の設定で改めて有効になります。\n\n[ドキュメント  ](https://docs.gitlab.com/ee/administration/settings/project_integration_management.html#integration-allowlist)\n\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/500610)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_7/integrations_allowlist.png\">\n\n### Direct Transfer によるユーザーのコントリビューションとメンバーシップの新たなマッピングのサポート\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\n[Direct Transfer](https://docs.gitlab.com/ee/user/group/import/index.html)（直接転送）によりGitLabインスタンス間を移行する場合に、ユーザーのコントリビューションとメンバーシップの新たなマッピング方法を使用できるようになりました。この機能により、インポートプロセスを管理するユーザーと、コントリビューションの再割り当てを受けるユーザーの双方に対する柔軟性と制御性が向上しました。新しいマッピング方法による変更点は以下です。\n\n* インポートが完了した後、移行先のインスタンスの既存のユーザーにメンバーシップとコントリビュートを再割り当てできます。インポートするメンバーシップとコントリビュートはすべて、まずはプレースホルダーユーザーにマッピングされます。すべてのコントリビュートは、移行先のインスタンスで再割り当てするまで、プレースホルダーユーザーに関連付けられて表示されます。  \n* ソースインスタンスと移行先のインスタンスに異なるメールアドレスを持つユーザーのメンバーシップとコントリビュートをマッピングします。\n\n移行先のインスタンスのユーザーにコントリビュートを再割り当てすると、ユーザーは再割り当てを承認または拒否できます。  \n詳細については、[ユーザーのコントリビュートとメンバーシップのマッピングによる移行の効率化](https://about.gitlab.com/blog/streamline-migrations-with-user-contribution-and-membership-mapping/)（英語）を参照してください。フィードバックを投稿するには、[イシュー502565](https://gitlab.com/gitlab-org/gitlab/-/issues/502565)にコメントを追加してください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/import/#user-contribution-and-membership-mapping)  \n[エピック](https://gitlab.com/gitlab-org/gitlab/-/issues/478054)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_7/user_contributions_mapping.png\">\n\n### 後続のスキャンで見つからない場合、脆弱性を自動的に解決\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nGitLabの[セキュリティスキャンツール](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools)は、アプリケーションコードの既知の脆弱性と潜在的な弱点を特定するのに役立ちます。フィーチャーブランチのスキャンを行うと、新たな弱点や脆弱性が検出されるため、マージする前に修正できます。プロジェクトのデフォルトブランチにすでに脆弱性がある場合、フィーチャーブランチで修正しておけば、次のデフォルトブランチスキャンの実行時に脆弱性が検出されなくなります。どの脆弱性が検出されなくなったかを把握しておくことは有益であるものの、各脆弱性をクローズするには、それぞれ手動で解決済みとしてマークする必要があります。解決すべき脆弱性が多数ある場合、新しいアクティビティフィルターやステータスの一括変更を使用したとしても、時間がかかることがあります。\n\n本リリースでは、自動スキャンによって検出されなくなった脆弱性を自動的に解決済みに設定したいユーザーのニーズに応えて、新しいポリシータイプである*脆弱性管理ポリシー*を導入します。手順は簡単で、新たに追加された自動解決オプションを使用して新規ポリシーを設定し、適切なプロジェクトに適用するだけです。特定の重大度の脆弱性のみ、または特定のセキュリティスキャナーで検出された脆弱性のみを自動解決するように、ポリシーを設定することも可能です。設定が完了すると、プロジェクトのデフォルトブランチのスキャンが次回行われた際に検出されなかった既存の脆弱性は解決済みとしてマークされます。このアクションにより、脆弱性の情報が更新され、アクティビティノート、アクション発生時のタイムスタンプ、および脆弱性が削除されると判断されたパイプラインが記録されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/vulnerability_management_policy.html)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/5708)  \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_7/auto-resolve-when-not-found-in-subsequent-scan.png\">\n\n### パーソナル、プロジェクト、グループアクセストークンをUIからローテーション可能に\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nUIを使用して、パーソナルアクセストークン、プロジェクトアクセストークン、グループアクセストークンをローテーションできるようになりました。これまでは、UIからトークンを更新するにはAPIを使用する必要がありました。\n\nこの場を借りて、コントリビュートしてくれた[shangsuru](https://gitlab.com/shangsuru)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#revoke-or-rotate-a-personal-access-token)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/241523)\n\n\u003Ciframe width=\"478\" height=\"269\" src=\"https://www.youtube.com/embed/YqK2CF655OE\" title=\"Revoke and Renew a GitLab personal access token (PAT) in the UI\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### CI/CDコンポーネントの使用状況をプロジェクトをまたいで追跡可能に\n\nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\n中心となるDevOpsチームは多くの場合、パイプライン全体でCI/CDコンポーネントが使用されている場所を追跡して、より適切に管理し、最適化する必要があります。コンポーネントの利用状況を可視化する方法がなければ、古いコンポーネントの使用の特定、採用率の把握、コンポーネントのライフサイクルのサポートなどを行うのは困難です。\n\nこのようなニーズに応えるために、新たにGraphQLクエリを追加し、DevOpsチームが組織のパイプライン全体でコンポーネントが使用されているプロジェクトのリストを表示できるようにしました。この機能により、DevOpsチームは可視化に基づいた分析結果を活用して生産性を向上させ、より良い意思決定を行うことができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/index.html#cicatalogresourcecomponentusage)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/466575)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_7/catalog.png\">\n\n### Linux Armでホストされる小規模Runnerが全プランで利用可能に\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: -\n\n本リリースから、GitLab.com向けにLinux Armでホストされる小規模Runnerを全プランでご利用いただけるようになりました。この2 vCPU Arm Runnerは、GitLab CI/CDと完全に統合されており、Armアーキテクチャ上でネイティブにアプリケーションをビルドし、テストすることができます。\n\n当社は、業界最速のCI/CDビルド速度を実現できるよう尽力しており、みなさまのチームがフィードバックサイクルのさらなる短縮に成功し、最終的にソフトウェアをより迅速に提供できるようになることを願っております。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/runners/hosted_runners/linux.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/501423)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_7/runner_arm.png\">  \n\n## GitLab 17.7のリリースに含まれるその他の改善点\n\n### お好みのテキストエディタをデフォルトに設定\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\n本バージョンでは、お好きな方法で編集を行えるようにするために、デフォルトのテキストエディタを設定できるようになりました。この変更により、リッチテキストエディタ、プレーンテキストエディタ、またはデフォルトなしを選択できるようになり、コンテンツの作成方法と編集方法の幅が拡がりました。\n\n今回のアップデートにより、エディタインターフェイスを個々の好みやチームの標準に合わせられるようになり、よりスムーズなワークフローを実現できます。この機能強化でも、GitLabは従来どおり、すべてのユーザーを考慮した使いやすさ、そしてカスタマイズ性を優先しています。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/preferences.html#set-the-default-text-editor)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/423104)\n\n### GitLab Duo Chatの新しい`/help`コマンド\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise  \nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nGitLab Duo Chatの様々な強力な機能を見つけましょう！チャットメッセージフィールドに「`/help`」と入力するだけで、Duo Chatで利用可能な機能をすべて確認できるようになりました。\n\nぜひこの新しいコマンドも試してみて、Duo Chatを使用することでどのように作業をよりスムーズに効率化できるかご確認ください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#gitlab-duo-chat-slash-commands)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/462122)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_7/new_help_command_in_gitlab_duo_chat.png\">\n\n### CI/CDジョブからネームスペースとFluxリソースパスを設定可能に\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nKubernetes用ダッシュボードを使用するには、環境設定からKubernetesとの接続用エージェントを選択し、必要に応じてReconciliationのステータスを追跡するために、ネームスペースとFluxリソースを設定する必要があります。GitLab 17.6では、CI/CD設定でエージェントの指定が可能になりました。ただし、ネームスペースとFluxリソースを設定するには、引き続きUIを使用するか、APIコールを行う必要がありました。17.7では、`environment.kubernetes.namespace`と`environment.kubernetes.flux_resource_path`を選択したCI/CD構文を使用してダッシュボードの設定をすべて行えるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/500164)\n\n### KEVによる効率的なリスクの優先順位付け  \nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nGitLab 17.7では、悪用が確認された既知の脆弱性（KEV）カタログのサポートを追加しました。[KEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)（英語）は、実際に悪用された共通脆弱性識別子（CVE）のリストがまとめられたもので、米国サイバーセキュリティ・社会基盤安全保障庁（CISA）によって管理されています。KEVを活用すれば、スキャン結果の優先順位付けを改善できるほか、脆弱性によって環境に生じうる影響を評価できます。\n\nこのデータは、GraphQLを介してコンポジション解析ユーザーが利用できます。このデータをGitLab UIに表示できるようにする[作業が計画されて](https://gitlab.com/gitlab-org/gitlab/-/issues/427441)います。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/#cveenrichmenttype)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/11912)\n\n### 高度なSASTのためのコードフロービューの表示場所を拡大\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\n脆弱性が表示されている場所であればどこでも、高度なSASTの[コードフロービュー](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#vulnerability-code-flow)を利用できるようになりました。以下はその一例です。\n\n* [脆弱性レポート](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)  \n* [マージリクエストのセキュリティウィジェット](https://docs.gitlab.com/ee/user/application_security/sast/#merge-request-widget)  \n* [パイプラインセキュリティレポート](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/pipeline.html)  \n* [マージリクエスト変更ビュー](https://docs.gitlab.com/ee/user/application_security/sast/#merge-request-changes-view)\n\nGitLab.comでは、新しいビューが有効になっています。GitLab Self-Managedでは、新しいビューはデフォルトでGitLab 17.7（MR変更ビュー）とGitLab 17.6（他のすべてのビュー）から有効になっています。サポートされているバージョンと機能フラグの詳細については、[コードフロー機能の可用性](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#code-flow-feature-availability)を参照してください。\n\n高度なSASTの詳細については、[本機能の一般提供の発表に関するブログ記事](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available)（英語）をご覧ください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#vulnerability-code-flow)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/13499)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_7/ast-advanced-sast-code-flow.png\">\n\n### トークンの有効期限の通知機能の強化\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nこれまでは、トークンの有効期限に関するメール通知は、有効期限が切れる7日前にのみ送信されていましたが、本リリースから30日前と60日前にも送信されるようになりました。通知の頻度増加および日付範囲の拡大により、ユーザーはトークンの有効期限をより認識しやすくなりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/security/tokens/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/464040)\n\n### コンプライアンスセンターのナビゲーションと使いやすさを改善\nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\nGitLabでは、グループとプロジェクトの両方で、コンプライアンスセンターのユーザーエクスペリエンスに対する重要な改善を反復的に行っています。  \nGitLab 17.7で行った主な改善は次の2点です。\n\n* コンプライアンスセンターの「**プロジェクト**」タブでグループによるフィルタリングが可能になりました。これにより、ユーザーはこれまでとは別の方法で、適切なプロジェクトとそのプロジェクトに設定されたコンプライアンスフレームワークを適用、絞り込み、検索できるようになりました。  \n* プロジェクトのコンプライアンスセンターに「**フレームワーク**」タブが追加されました。ユーザーはこのタブを使用して、特定のプロジェクトに設定されているコンプライアンスフレームワークを検索できます。\n\nなお、フレームワークの追加や編集は、プロジェクトではなくグループで行われます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/499183)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/468399)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_7/navigation-and-usability-improvements-to-compliance-center.png\">\n\n### オムニバスの改善  \nSaaS: -  \nSelf-Managed: Free、Premium、Ultimate\n\nバグのため、GitLab 17.6以前のバージョンでのFIPS LinuxパッケージではシステムLibgcryptは使用されず、標準のLinuxパッケージにバンドルされているのと同じLibgcryptが使用されていました。\n\nこのイシューは、AmazonLinux 2を除くGitLab 17.7のすべてのFIPS Linuxパッケージで修正されています。AmazonLinux 2のLibgcryptバージョンは、FIPS LinuxパッケージにインストールされているGPGMEおよびGnuPGバージョンと互換性がありません。  \n\nAmazonLinux 2のFIPS Linuxパッケージでは、標準のLinuxパッケージにバンドルされているのと同じLibgcryptが引き続き使用されます。そうでない場合は、GPGMEとGnuPGをダウングレードする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/omnibus/)\n\n### Unicode 15.1の絵文字サポート🦖🍋‍🟩🐦‍🔥\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\n17.7より前のバージョンでは、絵文字のサポートは古いUnicode標準に限定されていたため、一部の新しい絵文字は利用できませんでした。\n\nGitLab 17.7では、Unicode 15.1のサポートが導入され、最新の絵文字が追加されました。これにより、ティラノサウルス🦖、ライム🍋‍🟩、不死鳥🐦‍🔥などの楽しい絵文字も使えるようになり、最新の絵文字を使用して表現の幅も広がります。\n\nさらに、今回のアップデートにより絵文字の多様性が強化され、文化、言語、アイデンティティをより適切に表現できるようになりました。プラットフォーム上でのやり取りにおいてすべての人が受け入れられていると感じられるようになります。\n\n[ドキュメント](https://gitlab-org.gitlab.io/ruby/gems/tanuki_emoji/)  \n[イシュー](https://gitlab.com/gitlab-org/ruby/gems/tanuki_emoji/-/issues/28)\n\n### Kubernetes 1.31のサポート\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\n本リリースでは、2024年8月にリリースされたKubernetesバージョン1.31のフルサポートが追加されました。Kubernetesにアプリをデプロイすると、接続しているクラスターを最新バージョンにアップグレードし、そのすべての機能を利用できるようになります。\n\n詳細については、[Kubernetesのサポートポリシーとサポートされているその他のKubernetesバージョン](https://docs.gitlab.com/ee/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/501390)  \n\n### `environment.action: access`と`prepare`の設定で`auto_stop_in`タイマーのリセットが可能に\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nこれまでは、`action: prepare`、`action: verify`、`action: access`ジョブを`auto_stop_in`と組み合わせた場合、タイマーはリセットされませんでした。18.0以降のバージョンでは、`action: prepare`と`action: access`を設定すると、タイマーがリセットされ、`action: verify`を設定すると、タイマーはそのままとなります。\n\n現時点では、`prevent_blocking_non_deployment_jobs`機能フラグを有効にすることで、タイマーがリセットされない問題を解消できます。\n\n複数の破壊的な変更は、`environment.action: prepare | verify | access`値の挙動を区別することを目的としています。`environment.action: access`キーワードを指定すると、タイマーのリセットを除き、現在の動作に最も近いままとなります。\n\n将来的に互換性の問題が発生しないように、これらのキーワードの使用方法を見直す必要があります。提案された変更の詳細については、次のイシューを参照してください。\n\n* [イシュー437132](https://gitlab.com/gitlab-org/gitlab/-/issues/437132)  \n* [イシュー437133](https://gitlab.com/gitlab-org/gitlab/-/issues/437133)  \n* [イシュー437142](https://gitlab.com/gitlab-org/gitlab/-/issues/437142)\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/yaml/#environmentauto_stop_in)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/437133)\n\n### APIを使用してグループ内でシークレットプッシュ保護を有効化\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\n本リリースでは、[REST API](https://docs.gitlab.com/ee/api/group_security_settings.html)と[GraphQL API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationsetgroupsecretpushprotection)を介して、グループ内のすべてのプロジェクトでシークレットプッシュ保護を有効にできるようになりました。これにより、プロジェクトごとではなく、グループごとにシークレットプッシュ保護を効率的に有効化できます。プッシュ保護が有効または無効になるたびに、監査イベントが記録されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/group_security_settings.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/502827)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/502828)\n\n### 高度なSASTでの検出精度を向上\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\n次の脆弱性クラスをより正確に検出できるように、高度なSASTを更新しました。\n\n* C\\#：OSコマンド導入とSQL挿入  \n* Go：パストラバーサル  \n* Java：コードインジェクション、ヘッダーまたはログへのCRLFインジェクション、クロスサイトリクエストフォージェリ（CSRF）、不適切な証明書の検証、脆弱なデシリアライゼーション、安全でないリフレクション、およびXML外部エンティティ（XXE）インジェクション  \n* JavaScript：コードインジェクション\n\nまた、C\\#（ASP.NET）とJava（JSF、HttpServlet）のユーザー入力ソースの検出を改善し、一貫性を保つために重大度レベルを更新しました。\n\n高度なSASTが各言語で検出できる脆弱性の種類を確認するには、[高度なSASTのカバレッジ](https://docs.gitlab.com/ee/user/application_security/sast/advanced_sast_coverage.html)を参照してください。この改良されたファイルや機能間のスキャンを使用するには、[高度なSASTを有効](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#enable-advanced-sast-scanning)にしてください。高度なSASTがすでに有効な場合は、新しいルールが[自動的に適用](https://docs.gitlab.com/ee/user/application_security/sast/rules.html#how-rule-updates-are-released)されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14685)  \n\n### 認証情報インベントリ内でグループおよびプロジェクトアクセストークンが表示されるように\n\nSaaS: Ultimate  \nSelf-Managed: -\n\nグループとプロジェクトのアクセストークンが、GitLab.comの資格情報インベントリに表示されるようになりました。これまでは、パーソナルアクセストークンとSSH鍵のみが表示されていました。インベントリ内に新たなトークンタイプが表示されるようになったことで、グループ全体の認証情報をさらに詳しく把握できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/498333)  \n\n### エンタープライズユーザーを一覧表示するAPIエンドポイントを追加\n\nSaaS: Premium、Ultimate  \nSelf-Managed: \\-\n\nグループオーナーは、専用のAPIエンドポイントを使用して、エンタープライズユーザーと関連する属性を一覧表示できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/group_enterprise_users.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/438366)  \n\n### アクセストークン用の説明フィールドを追加\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nパーソナル、プロジェクト、グループ、または代理のアクセストークンを作成する際に、任意でそのトークンの説明を入力できるようになりました。これにより、どこでどのように使用されるかなど、トークンに関する補足情報を入力できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/443819)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_7/sscs_token_description.png\">\n\n### カスタムロールからオーナーの基本ロールを削除\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nカスタムロールの作成時に、オーナーの基本ロールを利用できなくなりました。カスタムロールは権限を追加していく形で作成するものであり、オーナーの基本ロールを提供することは意味をなさないためです。オーナーの基本ロールを使用している既存のカスタムロールは、この変更の影響を受けません。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/custom_roles.html#create-a-custom-role)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/474273)\n\n## 実験的な機能\n\n### SCA Vulnerability Prioritizer\n\nこの実験的な機能の導入は、ユーザーが[依存関係スキャン](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html)または[コンテナスキャン](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html)中に特定された脆弱性への優先順位付けを支援する新たな一歩です。ユーザーは、このCI/CDコンポーネントを\\``.gitlab-ci.yml`\\`ファイルに含めることができます。これにより、プロジェクト内で見つかった脆弱性の優先順位付けレポートが生成されます。レポートはパイプラインに出力できます。\nこのコンポーネントは、GitLab GraphQL APIをクエリし、脆弱性データを取得後、次のように優先順位を付けます。\n\n1. 悪用が確認された既知の脆弱性（KEV）\n2. 悪用予測スコアリングシステム（EPSS）スコアが高い脆弱性\n3. 重大度の高い脆弱性\n\n検出および確認された脆弱性のみが表示されます。現在、このコンポーネントではEPSSとKEVデータを使用して、脆弱性の優先順位を付けています。EPSSとKEVデータは、依存関係スキャンとコンテナスキャンを通じて収集されるCVEでのみ利用可能です。詳細については、[Vulnerability Prioritizer](https://gitlab.com/components/vulnerability-prioritizer) を参照してください。\n\nフィードバックをお待ちしております。ぜひ[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509508)からご質問やコメントをお寄せください。\n\n### GitLab Self-Managedのカスタム管理者ロール\n\n管理者はカスタム管理者ロールを使用して、管理者エリアへのきめ細かいアクセスを提供できるようになりました。これにより、タスクを完了するために組織が管理者エリアへの完全なアクセス権をユーザーに付与する必要がなくなります。この機能は実験的に導入されました。詳細については、[カスタム管理者ロール](https://docs.gitlab.com/ee/user/custom_roles.html#custom-admin-roles)を参照してください。\n\nみなさまからのフィードバックをお待ちしています。ご質問やコメントがある場合、またはGitLabチームとのやり取りをご希望の場合は、こちらの[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/509376)をご覧ください。\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。  \n以下のリンクをクリックして、17.7のバグ修正、パフォーマンスの強化、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=17.7)  \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=17.7)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.7)\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n\n### 過去の日本語リリース情報\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],"2025-02-06",{"slug":2341,"featured":92,"template":681},"gitlab-17-7-release","content:ja-jp:blog:gitlab-17-7-release.yml","Gitlab 17 7 Release","ja-jp/blog/gitlab-17-7-release.yml","ja-jp/blog/gitlab-17-7-release",{"_path":2347,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2348,"content":2354,"config":2358,"_id":2360,"_type":16,"title":2361,"_source":17,"_file":2362,"_stem":2363,"_extension":20},"/ja-jp/blog/mastering-the-basics-of-git-push-tag",{"title":2349,"description":2350,"ogTitle":2349,"ogDescription":2350,"noIndex":6,"ogImage":2351,"ogUrl":2352,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2352,"schema":2353},"git pushタグの基本を徹底攻略","git pushコマンドで、他の開発者とバージョンやリリース情報、マイルストーンをタグを使用して共有する方法とコツをご紹介。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665200/Blog/Hero%20Images/gitpush.jpg","https://about.gitlab.com/blog/mastering-the-basics-of-git-push-tag","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"git pushタグの基本を徹底攻略\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-12-19\",\n      }",{"title":2349,"description":2350,"authors":2355,"heroImage":2351,"date":2336,"body":2356,"category":962,"tags":2357},[696],"gitを使った開発で最もよく利用するコマンドのひとつ`git push`。ローカルリポジトリのオブジェクトをリモートリポジトリに送信して更新を行うコマンドです。タグ機能と組み合わせて開発途中の特定の時点に参照しやすいように名前をつけておくことで、後から遡って異なるバージョンを比較できます。この記事では`git push`コマンドの基本について解説していきます。\n\n- git pushタグとは？\n- gitタグを使うメリットとは？\n- gitタグの種類\n- よく使うgitタグ   \n- git pushコマンドでコミットやタグをプッシュする方法\n- git pushとgit pushタグを使うためのベストプラクティス\n- GitLabでgitタグを使う\n- git pushタグのFAQ\n\n## git pushタグとは？\n`git push` タグとは、リポジトリ内でタグづけされたコミットを、リモートリポジトリにプッシュするためのコマンドです。ローカルで作成したタグをリモートリポジトリに送信し、複数人で特定のバージョンやマイルストーンを共有するのに有用です。\n\n例えば、`v1.0`というタグを`origin`という名前のリモートリポジトリにプッシュするには下記のように記載します。\n\n    git push origin v1.0\n\n## gitタグを使うメリットとは\ngitタグとは、本のしおりのようにプロジェクト履歴の中で特定のコミットに名前をつけられる機能です。特定のタグをタグ名で簡単に参照できることが最大のメリットで、新バージョンのリリースや、大規模な変更を実施する前のコードベースなど、その時点まで戻って参照する可能性のあるコミットにタグをつけて管理します。\n\n## gitタグの種類\ngitのタグには、主に2つの種類があります。\u003Cbr>\u003Cbr>\n\n1. 軽量タグ（Lightweight Tags）:\n\n軽量タグは、コミットに名前をつけるだけの単純なタグです。基本的にはコミットの名前とポインターですが、関連するコミットへのクイックリンクの作成などに適しています。軽量タグの作成は下記の通りです。\n\n    git tag TAG_NAME\n\nバージョン管理のタグの場合は、次のように名付けます。\n\n    git tag v1.0\n\n2. アノテーション（注釈付）タグ：\n\nアノテーションタグは、タグの作成者、メールアドレス、作成した日やメッセージなど追加のメタデータも保存されます。アノテーションタグを作成するには、`-a`でタグを作成し、`-m`を指定するとコメントも同時に指定することができます。\n\n    git tag -a TAG_NAME -m \"Comments\"\n\nアノテーションタグは、チームで共有すべきリリースやバージョン管理に追加の情報を含めたいときに広く使われます。\n\n## よく使うgitタグ\n### タグを一覧で確認する\n\nリポジトリに保存されたタグを一覧表示します。\u003Cbr>\n\n    git tag\n\nワイルドカード表現を使って絞り込むこともできます。\n\n    git tag -l *SEARCH WORD*\n\n\u003CH3>タグの内容を確認する\u003C/H3>\n\nタグの内容を確認する場合は`git show`を使います。\u003Cbr>\n\n    git show TAG_NAME\n\nこれにより以下の情報が取得できます。\n- Commit：コミット番号\n- Author：実行したユーザー名\n- Date：実行した日時\n\n### 作ったタグを削除する\nタグを削除するには`git tag`コマンドのオプション`-d`を指定します。削除した後、一覧から消えているか確認しましょう。\u003Cbr>\u003Cbr>\n\n    git tag -d TAG_NAME\n\n## git pushコマンドでコミットやタグをプッシュする方法\n`git push` コマンドを使ってコミットやタグをプッシュする方法は以下の通りです。\n\u003CH3>コミットをリモートリポジトリにプッシュする\u003C/H3>\n\n    git push REMOTE_NAME BRANCH_NAME\n\nリモート名）origin\u003Cbr>\nブランチ名）mainの場合には\n\n    git push origin main\n\nとなります。\n\n\u003CH3>タグをプッシュする\u003C/H3>\n\n    git push REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nタグ名）v1.0の場合、\n\n    git push origin v1.0\n\nとなります。\n\n## git pushとgit pushタグを使うためのベストプラクティス\n `git push` と `git push` タグを使用する際、特にチームのバージョン管理に使われている場合に避けた方が良いことがあります。それは、一度プッシュしたタグの名前を変更することです。逆にまだプッシュしていないタグは、\u003Ccode>git tag -f TAG_NAME Commit#\u003C/code>で上書きして、正しい名前にしてからプッシュするようにしましょう。またチーム内で管理されるタグ名は、一意に決定されその存在が担保されることが何より重要になるので、プッシュする前にはタグ名を十分確認するようにしましょう。\n\n## GitLabでgitタグを使う\n簡単にgitタグを使う方法をお探しの方におすすめなのが、プラットフォームを使用することです。中でもGitLabはリモートリポジトリのホスティング、インターフェースの提供、変更内容のコードレビュー、[プッシュされたコードの自動ビルド、テスト、デプロイまで実施](https://about.gitlab.com/ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices/) できます。また、プロジェクトやリポジトリごとにアクセス権を細かく管理することができるため、セキュリティの確保も可能です。\u003Cbr>\u003Cbr>\n\n[バージョン管理に使える](https://about.gitlab.com/ja-jp/solutions/source-code-management/)GitLabの無料トライアルは[こちら](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)からお申し込みいただけます。\u003Cbr>\u003Cbr>\n\n\u003CH2>git pushタグのFAQ\u003C/H2> \n\u003CH3>gitのタグを使うメリットは？\u003C/H3>\ngitタグの最大のメリットは特定のコミットをタグ名で簡単に参照できることです。新バージョンのリリースや、大規模な変更を実施する前のコードベースなど、その時点まで戻って参照する可能性のあるコミットにタグをつけて管理します。\n\n\u003CH3>gitタグのつけ方は？\u003C/H3>\nタグをつけるには下記の基本コードを使います。\n\n    git push REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nブランチ名）mainの場合には\n\n    git push origin main\n\nとなります。\n\n### プッシュしたタグを削除する方法は？\nプッシュしたタグを削除するコマンドは、\u003Cbr>\n\n    git push –delete REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nタグ名）v1.0の場合、\n\n    git push –delete origin v1.0\n\nとなります。\n\n### git pushタグを使うメリットは？\nコミットにタグをつけてリモートリポジトリに保存することで、ソフトウェアのリリース情報や作成者・作成日・コメントを保存できます。逆に、 [git fetchまたはgit pull](https://about.gitlab.com/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull/) を使用してリモートからタグを取得し、ローカルリポジトリに反映させることもできます。大幅な修正やベンチマークとなるリリースが行われた場合にも直近のバージョンや該当のリリースに戻って特定時点でのコミットを確認できます。\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[966,825],{"slug":2359,"featured":92,"template":681},"mastering-the-basics-of-git-push-tag","content:ja-jp:blog:mastering-the-basics-of-git-push-tag.yml","Mastering The Basics Of Git Push Tag","ja-jp/blog/mastering-the-basics-of-git-push-tag.yml","ja-jp/blog/mastering-the-basics-of-git-push-tag",{"_path":2365,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2366,"content":2372,"config":2380,"_id":2382,"_type":16,"title":2383,"_source":17,"_file":2384,"_stem":2385,"_extension":20},"/ja-jp/blog/automating-with-gitlab-duo-part-3-validating-testing",{"title":2367,"description":2368,"ogTitle":2367,"ogDescription":2368,"noIndex":6,"ogImage":2369,"ogUrl":2370,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2370,"schema":2371},"GitLab Duoを使用した自動化シリーズパート3：テストの検証","当社チームが自動テストプロセスにおけるGitLab Duoの影響を検証するために実行したテストや、達成した素晴らしい結果をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097447/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097447404.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-3-validating-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duoを使用した自動化シリーズパート3：テストの検証\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-17\",\n      }",{"title":2367,"description":2368,"authors":2373,"heroImage":2369,"date":2375,"body":2376,"category":787,"tags":2377,"updatedDate":2379},[2374],"Byron Boots","2024-12-17","このシリーズの前回の記事では、[GitLab Duoを使用してコードテストを生成する方法](https://about.gitlab.com/ja-jp/blog/automating-with-gitlab-duo-part-1-generating-tests/)と[GitLab Duoを使用して自動テストを生成する際に学んだこと](https://about.gitlab.com/ja-jp/blog/automating-with-gitlab-duo-part-2-complex-testing/)について説明しました。また、GitLab Duoによって生成されたテストに変更を加える方法もいくつかご紹介しました。このシリーズの最後の記事では、チームの自動テストプロセスにおけるGitLab Duoの影響を検証するために実行したテストと、これまでに達成した素晴らしい結果についてご紹介します。\n\n### 検証テストの結果\n\nテスト生成時のGitLab Duoの使い方が期待どおりの付加価値をもたらしているかを検証するために、自分たちとGitLab Duoへの挑戦として、テストカバレッジを置き換えて拡大させてみることにしました。チームは、以前に書いたテストをすべて削除してテストカバレッジを0%にしてから、リポジトリ内のコードを順番に確認していき、GitLab Duoが生成したテストを格納する新しいテストファイルを作成しました。\n\nこの出発点から、[最初のブログ記事](https://about.gitlab.com/ja-jp/blog/automating-with-gitlab-duo-part-1-generating-tests/)で概説した手順に従ってテストを生成しました。GitLab Duoの純粋な性能を正確に評価するために、テストとテストファイルは人間が一切修正しませんでした。`Tests Generated by Duo`というコメントをファイルの先頭に手動で追加し、テストの作成方法がわかるように末尾に`duo.py`と付けました。\n\nテストのすべてのイテレーションは、[シリーズの2番目のブログ記事](https://about.gitlab.com/ja-jp/blog/automating-with-gitlab-duo-part-2-complex-testing/)で概説したように、`Generate Tests`およびGitLab Duo Chatウィンドウを介したGitLab Duoとのインタラクションを通じてのみ行われました。先に述べたように、発生したエラーや失敗したテストに加え、GitLab Duoが追加のコンテキストとして使用できるようサンプルのコードスニペットに基づいて更新を行うよう、GitLab Duoにリクエストしました。\n\nGitLab Duoでテストする際には、常にテストとカバレッジレポートを実行していたため、GitLab Duoにより生成されたテストによってテストカバレッジが拡大され、期待どおりに付加価値を得られているかを確認できました。[GitLabのテストカバレッジの可視化](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization/)機能を活用することで、作業の結果を継続的にモニタリングできました。\n\n最終的に、以前はほとんど手動のテストでカバーされていたコードのテストについて、GitLab Duoを使用して再生成した結果、84%のテストカバレッジを達成することができ、これは当社チームにとって大きな成果でした。理由は次のとおりです。\n\n1. 74%であった以前のカバレッジから大幅に改善できた。 \n2. 複数のエンジニアが約4週間かかって74%を達成していたのに対し、1人のエンジニアが約2日で84%を達成できた。\n\nこの実験以来、当社チームはGitLab Duoの助けを借りてカバレッジをさらに89%まで向上し、新機能も積極的に導入しています。\n\n![成果のイメージ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097456/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097456771.png)\n\nGitLab Duoを使用することで、テストの効率とカバレッジが向上し、既存のコードに関する情報をあまり把握していないデベロッパーでも、重要なテストをすばやく書けるようになりました。これにより、エラーの心配をすることなく新機能を開発できるというチームの自信が高まりました。\n\n> [GitLab Duoを試してみたい](https://about.gitlab.com/ja-jp/solutions/gitlab-duo-pro/sales/)方は、今すぐ無料トライアルにお申し込みください！\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[721,2378,904,678],"testing","2025-05-13",{"slug":2381,"featured":6,"template":681},"automating-with-gitlab-duo-part-3-validating-testing","content:ja-jp:blog:automating-with-gitlab-duo-part-3-validating-testing.yml","Automating With Gitlab Duo Part 3 Validating Testing","ja-jp/blog/automating-with-gitlab-duo-part-3-validating-testing.yml","ja-jp/blog/automating-with-gitlab-duo-part-3-validating-testing",{"_path":2387,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2388,"content":2394,"config":2399,"_id":2401,"_type":16,"title":2402,"_source":17,"_file":2403,"_stem":2404,"_extension":20},"/ja-jp/blog/what-is-an-api",{"ogTitle":2389,"schema":2390,"ogImage":2391,"ogDescription":2392,"ogSiteName":1223,"noIndex":6,"ogType":1244,"ogUrl":2393,"title":2389,"canonicalUrls":2393,"description":2392},"APIとは？意味や利用のメリット、注意点、活用事例を徹底解説","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"APIとは？意味から注目のAPIゲートウェイまで徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-12-16\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780270/zrvqwpatilino8r9qm6e.jpg","API連携の仕組みやメリット、注意点を解説します。APIの種類や具体的な活用例も解説します。","https://about.gitlab.com/blog/what-is-an-api",{"heroImage":2391,"body":2395,"authors":2396,"updatedDate":805,"date":2397,"title":2389,"tags":2398,"description":2392,"category":672},"ソフトウェア開発の領域においては「API」の活用が注目されています。APIを導入することで開発コストの削減や効率化、高度な機能実装などを実現できます。\n\nしかし、APIといってもさまざまな種類があり、意味や仕組みについて詳しく理解していない人も多いのではないでしょうか。\n\nこの記事では、API連携の仕組みやメリット、注意点を解説します。APIの種類や具体的な活用例も解説しているので、ぜひ参考にしてください。\n\n## 1. APIとは？\n\n![APIとは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780256/hjsyokgzh5fnvoux66iw.jpg)\n\nAPI連携は、その名の通り、APIを利用してアプリケーションの機能やデータを他のアプリケーションやシステムと連携させ、利用できる機能を拡張することです。事前登録したクレジットカードから自動決済されるシステムやカレンダー機能を使った自動予約システムなどにもAPIが使われています。\n\nAPI連携によって、プログラムをゼロから開発しなくても既存のソフトウェアやWebサービスが提供している機能を活用できるため、効率よく顧客体験を向上させることができるため、幅広い業界で活用が広がっています。\n\n## 2. API連携のしくみ\n\n![API連携の仕組み](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/lfvsw0gtwpzw0yjtats3.jpg)\n\nAPI連携はリクエスト（要求）とレスポンス（応答）で成り立っています。利用者側がリクエストし、提供元がレスポンスするという構図です。API連携のためには、APIの提供元は事前にどのようなリクエストに対してどのようなレスポンスを返すのかルールを設定しなければなりません。\n\n利用者はそのルールに則ったコードを書くことでAPIを連携させることができます。\n\n## 3. API利用のメリット\n\n![API利用のメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/noicynlcnefzltl7kxkn.jpg)\n\nAPIを自社のソフトウェア開発に導入することで以下のようなメリットを享受できます。\n\n* 開発の効率化とコスト削減\n* データの2次利用　\n* セキュリティの向上\n* ユーザーの利便性の向上\n\n### 3-1 開発の効率化とコスト削減\n\nAPIを活用することで開発の効率化とコスト削減を実現できます。通常新しい機能を開発する場合、要件定義から設計、開発、テスト、リリースまでを自社で実施する必要があります。そのプロセスにおいて自社が求める機能を提供しているAPIと連携すれば、複雑なプログラミングを要してゼロから開発する必要がなくなるため、スピーディーに高度な機能を実装することが可能です。\n\nなお、多くのAPIは無料で提供されていますが、有料のAPIであっても自社でゼロから開発した場合に発生するコストと比べれば、低コストで開発を進められるでしょう。\n\n### 3-2 データの2次利用\n\n無料で提供されているAPIも多くありますし、有償APIも自社で開発から構築まで取り組んだ場合にかかる費用と比べれば、低コストに抑えられることがほとんどです。\n\nAPI連携によって他社サービスのデータを利用できます。例えば、ECサイトで提供されているAPIなら、ECサイトが保有している商品情報や在庫状況、顧客情報などを取得して自社のマーケティング戦略に活かせるでしょう。また、SNS業界でもAPIの公開が進んでいます。ユーザーの投稿やトレンドを分析すれば、新しい機能開発にもつなげられます。\n\nAPIの活用により膨大なデータの収集から登録、更新まで行う必要がないため、業務効率化や情報の信頼性向上が期待できます。\n\n### 3-3 セキュリティの向上\n\n近年セキュリティインシデントが多く発生しているため、自社でシステムを構築する際にもセキュリティ強化を徹底しなければなりません。API連携を行えば、開発におけるセキュリティ強化にもつなげられます。\n\n例えば、モバイルデバイスを利用した二段階認証をシステムに構築する場合、自社で構築・運用するよりもAPI連携で実績のある認証サービスを利用すれば、セキュリティレベルの高い二段階認証を導入できます。これによりユーザーも安心してシステムに登録できるため、登録ユーザー数の向上も期待できるでしょう。\n\n### 3-4 ユーザーの利便性の向上\n\nAPI連携を行えば、ユーザーの利便性向上も見込めます。例えば、自社のWebサービスをユーザーが初めて利用する際に登録情報の入力が面倒だと感じることも多いでしょう。\n\nそこでAPI連携によって他社サービスの登録情報を活用して登録・ログインできる仕組みを構築しておけば、ユーザーはスムーズにサービスを利用することができ、「登録・ログインの手間」による離脱防止につなげられます。\n\n## 4. APIを利用する際の注意点\n\n![APIを利用する際の注意点](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/pv7pq4uaaakouzkrwqmu.jpg)\n\nAPIにはさまざまなメリットがありますが、以下のような注意点もあるため利用前に把握しておくことが大切です。\n\n* サービスの不具合の可能性\n* 突然のサービス停止のリスク\n\n### 4-1 サービスの不具合の可能性\n\nAPI提供元でシステムの不具合が発生した場合、自社で連携しているAPIの機能が使えなくなる可能性があります。つまり、APIを安定的に継続して活用できるかどうかはAPI提供元に大きく依存するということです。\n\n万が一、トラブルが発生し機能が使えなくなった場合は自社での対応はできないため、解消されるまで待たなければなりません。システムの利用ユーザーに不安や不満を感じさせてしまう原因にもなるため、事前にリスク対策を検討しておくことが大切です。\n\n### 4-2 突然のサービス停止のリスク\n\nAPI提供元のシステムの不具合だけでなく、サービスそのものが停止される可能性も考慮しておく必要があります。\n\n機能そのものが停止してしまうと、自社のサービスでも利用できなくなるため、代替となるサービスを活用する必要があります。\n\n突然サービスが停止されてから新しいAPIを探して実装するとなると時間と手間がかかるため、あらかじめ調査しておくことをおすすめします。\n\n## 5. APIの種類\n\n![APIの種類](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/kkj6pd3tpcx8zmzla5g0.jpg)\n\nAPIには提供される目的や用途に応じていくつかの種類があり、いずれも提供元や活用方法が異なります。どのAPIを使うのが最適か判断するためにも、APIの種類について理解しておきましょう。\n\n### 5-1 Web API\n\nWebを介して機能の一部が提供されるAPIです。「HTTP/HTTPS」の通信方式を使ってインターネット経由でリクエスト／レスポンスのやり取りが行われます。プログラミング言語や使用するパソコンのOSに関係なく、あらゆる環境からアクセスが可能な点が大きな強みであり、多くの企業からさまざまなAPIが提供されています。\n\n### 5-2 OS API\n\nWindowsやAndroidのようなOSが提供する「OS API（ネイティブAPI）」。OSが持っている機能を、他のアプリケーションでも呼び出すことができるAPIです。WindowsがOSとして持っている機能をサードパーティ製のアプリでも使えるようにしています。OSが進化するとともに、OSが提供する機能は多岐にわたり、手軽にAPIを使えるようなツール（フレームワーク）が提供されることも増えています。\n\n### 5-3 ライブラリAPI \n\nライブラリAPIとは、プログラミング言語のライブラリが提供するAPIのことで、クラスライブラリやコアAPI、標準APIとも呼ばれる場合もあります。ライブラリには、外部から利用できる特定の機能を実装するためのプログラム部品が格納されており、APIとして利用すれば一からコードを記述する必要がなくなるため、開発効率を大幅に向上させることが可能です。\n\nつまり、ライブラリAPI を活用すれば複雑なプログラミングを短時間で実行できるようになります。\n\n### 5-4 ランタイムAPI\n\nランタイムAPIとは、プログラムが実行されている時に使用されるAPIで、プログラム実行中の情報を取得できます。例えば、アプリケーションの動作状況をリアルタイムで把握し、メモリの使用量や実行時間などを把握することが可能です。\n\nランタイムAPIを活用すれば早期にアプリケーションの状態を把握できるため、問題の早期発見・改善につながりパフォーマンスを最適化できます。\n\n## 6. APIの提供方式\n\n![APIの提供方式](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/kkj6pd3tpcx8zmzla5g0.jpg)\n\nAPIにはさまざまな提供方式があり、活用の目的によって使い分ける必要があります。\n\n* オープン（パブリック）API\n* パートナーAPI\n* 内部API\n* コンポジットAPI\n\n### 6-1 オープン（パブリック）API\n\nオープンAPIは、企業が運用しているシステムのAPIを外部に公開しているAPIを指します。API提供元の企業はAPIを外部公開することで自社サービスの認知拡大を図れ、さらにAPIの提供を有料コンテンツとすれば利益の確保にもつながります。\n\nAPI利用者側は利用規約に同意すれば誰でも利用できるため、システム開発の際に自由に連携することが可能です。これにより高度な機能実装やセキュリティ向上を実現できます。\n\n### 6-2 パートナーAPI\n\nパートナーAPIは、企業間で利用されるAPIを指し、オープンAPIとは異なり外部での利用が限定されるのが特徴です。\n\nパートナーAPIを利用すれば、パートナー企業が保有しているデータや機能といったリソースを最大限に活用できるため、自社システムのパフォーマンス向上や顧客体験の強化につなげられます。\n\n### 6-3 内部API\n\n内部APIは、企業内のシステム間でデータのやり取りをするために活用されるAPIを指します。社内向けのAPIであるため、外部に公開されることはありません。\n\n多数のシステムを保有している企業なら内部APIを整備することで、社内でのデータ連携が容易になるため業務スピードの向上を実現できます。\n\n### 6-4 コンポジットAPI\n\nコンポジットAPIとは、一つのAPIで複数のAPIをまとめて利用できる形式のことです。コンポジットAPIを活用すれば、複数のアプリケーションとデータ連携する際の負担が軽減されるため開発効率の向上が期待できます。\n\nクラウドサービス間のデータ連携においてコンポジットAPIが利用されることが多いです。\n\n## 7. 代表的な4つのAPIプロトコル\n\n![代表的な4つのAPIプロトコル](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780256/rfea6xfjdwi2iklpstev.jpg)\n\nAPIプロトコルとは、システム間でデータの送受信を行うための通信の仕組みを指します。代表的なプロトコルは以下が挙げられます。\n\n* HTTP / HTTPS\n* XML-RPC\n* JSON-RPC\n* SOAP\n\n### 7-1 HTTP / HTTPS\n\nHTTP / HTTPSは、WebサーバーとWebブラウザとの間でデータのやり取りをするために用いられるプロトコルを指し、多くのWeb  APIで利用されています。\n\nHTTPSは、通信内容が暗号化されるためHTTPよりも高いセキュリティでより安全な通信を実現できます。\n\n### 7-2 XML-RPC\n\nXML-RPCは、XML形式を利用してクライアントとサーバー間でデータのやり取りをするプロトコルです。RPC（Remote Procedure Call：リモートプロシージャコール）とは、ネットワーク上にある他のコンピューターに対して処理をリクエストして実行するための手法を指します。\n\nXML-RPCは、1998年にユーザーランド・ソフトウェア社とマイクロソフトが共同開発したもので後に紹介するSOAPへと発展しています。\n\n### 7-3 JSON-RPC\n\nJSON-RPCとは、JSONを利用してクライアントとサーバー間でデータのやり取りをするプロトコルを指します。\n\nJSONは可読性が高く、コンピューターにとっても扱いやすい軽量のデータフォーマットであるため幅広く利用されています。\n\n### 7-4 SOAP\n\nSOAPとは、「Simple Object Access Protocol」の略語のことでXML-RPCを拡張したプロトコルです。SOAPはデータをやり取りするためのルールが厳格に定められているため、XML-RPCと比べて複雑なデータの通信に使われます。例えば、決済や認証など高いセキュリティが求められるシーンで活用できます。\n\n## 8. API連携の具体例\n\n![API連携の具体例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780256/y02nbwxggacaweafck3r.jpg)\n\n具体的にどのような場面でAPI連携が使われているのでしょうか。\n\n* SNS\n* ECサイト\n* POSレジ\n* 地図・天気情報\n\n以上4つの例を具体的に説明します。\n\n### 8-1 SNS\n\n近年、SNSは企業と個人をつなぐツールとして不可欠な存在となりつつあります。世界中に顧客を持つ企業では、よりきめ細かなカスタマーケアを提供する方法としてX（旧Twitter）で公開されているAPI「Sprout Social」はDM（ダイレクトメール）やメンション、リプライなどで言及されたユーザーからの要望や質問を、企業内の担当者に直接転送してくれます。\n\nまた、カスタマーフィードバック機能では、XのDMで製品やサービスの満足度に関するアンケート調査を行えます。質問への回答率の向上や解答までの時間短縮が顧客体験の向上を実現します。他にもLINEを使った荷物の再配達設定など、SNSを使った顧客体験の向上は広い業界に広がっています。\n\n### 8-2 ECサイト\n\n決済サービスの運営事業者はECサイト向けのAPIやサードパーティアプリを提供しています。例えば、楽天ペイでは決済処理APIを提供しており、API連携をしたECサイトで楽天会員が決済する場合、楽天ペイに登録済みの情報を呼び出して決済できます。個人情報を入力して会員登録をする手間を省けるため、顧客体験やコンバージョン率の向上が見込めます。\n\n### 8-3 POSレジ\n\n販売情報を集計・記録するPOSレジでもAPI連携が広がっています。顧客管理システムとの連携で会員情報の共有や購買履歴にあわせた商品レコメンドが可能になります。また、在庫管理システムとの連携で仕入れ効率を向上するなどデータ管理の効率化でも使われています。業種や店舗形態によってさまざまな活用が広がっています。\n\n### 8-4 地図・天気情報\n\n自社のWebサイトやアプリに対して、地図や天気情報をAPI連携を通して反映させることができます。\n\n例えば、商品の認知拡大や購買意欲の向上を目的として屋外イベントを開催する際には、API連携してWebサイトに地図や天気情報を掲載して告知すればユーザーに有益な情報を提供できます。これによりユーザーの情報収集の手間が省けるため、顧客満足度の向上にもつながるでしょう。\n\n## 9. 注目のAPI提供元とそのサービス\n\n![注目のAPI提供元とそのサービス](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/rfo3pqrzugdasqidprzn.jpg)\n\nここからは、注目のAPI提供元をご紹介します。\n\n### 9-1 Google\n\nGoogleでは、クラウド基盤である「Google Cloud Platform」上で、利用できるAPIをライブラリにまとめており、GmailやMap、YouTube、Calendar、Driveの他、300種類のAPIが公開されています。\n\nこうしたAPIを使って、メールを簡単に取得するツールやカレンダーアプリを作ったり、ブラウザの拡張機能や画像認識を使ったスマホアプリ、ソフトウェア、Webサービスを構築できます。\n\n### 9-2 X（旧Twitter）\n\n大手SNSであるXもAPIを提供しています。Webサイトに表示される投稿内容や投稿をまとめたり、自動で投稿してくれるツールなど、全てAPIをベースに作られています。\n\nSNSを使った情報発信や、情報収集を効率化したい場合には、真っ先にチェックすべきAPIと言えるでしょう。\n\n### 9-3 OpenAI\n\n話題のChatGPTを提供するOpenAIもAPIを提供しています。画像生成、機械文字起こし、自動分類、機械学習を実装するAPIに注目が集まっています。\n\n### 9-4 ヤマト運輸\n\nWebAPIにより、配送連携APIを提供しています。二次元コードをかざすだけでコンビニやオープン型宅配便ロッカーからの荷物を発送するため、匿名配送や発送時の支払い簡略化が可能になり、高い顧客満足を誇っています。\n\n### 9-5 Slack\n\nアメリカ発のビジネス向けコミュニケーションツールであるSlackも、「Slack API」という独自のAPIを提供しています。利用することで、リマインドやリアルタイムでのアラートなどの通知が行えます。Botを活用し、タスク自動化、メッセージの送受信や会話へのリアクションなども実装できます。\n\nSlackへ外部サービスからのAPIも提供されており、例えばGitLabも[Slack向けのAPI](https://about.gitlab.com/ja-jp/solutions/slack/)を提供しています。\n\n## 10. APIの使い方・利用手順\n\n![APIの使い方・利用手順](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/kwai9kgdry7kvcbwabu1.jpg)\n\n1. API提供元のWebサービスに登録する\n2. APIキーとAPIシークレットを取得し設定を行う\n3. 実装・テストを行う\n\n多くの場合、まずAPIを提供しているWebサービスへの登録が必要になり、基本情報の入力を行います。登録が完了すればAPIキーとAPIシークレットを取得できます。これらはAPIを利用するためのコードであるため大切に保管しておいて下さい。\n\nコードの取得まで終わり、準備が整えば実装の段階に移ります。APIの実装手順は提供事業者によって異なるため、ドキュメントなどを確認しながら行いましょう。実装が完了したら実際に操作してみて動作に問題がないか確認します。\n\n## 11. API連携に関するよくある質問\n\n![API連携に関するよくある質問](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780256/o82yfn9ph698fmhcv41x.jpg)\n\n最後にAPI連携に関するよくある質問とその回答を紹介します。\n\n### 11-1 APIゲートウェイとは何ですか？\n\nAPIゲートウェイとは、APIの管理ツールです。複数のAPIと連携を行う場合、APIゲートウェイを使えば、APIゲートウェイがそれぞれのAPIへリクエストを振り分け、集約し適正なレスポンスを返却してくれます。\n\n### 11-2 APIは誰でも利用できますか？\n\n基本的には誰でも利用可能です。ただし、利用における必要な技術や、APIによっては有償化されているものもあるので、利用する際には、きちんとした理解と検討が必要です。\n\n### 11-3 RESTとSOAPの違いは？\n\nRESTは「Representational State Transfer」の略語であり、Webのアーキテクチャスタイルの一つです。HTTPプロトコルを使用しますが、REST自体はプロトコルではありません。\n\n一方、SOAPはメッセージングプロトコルであるため、両者は根本的に異なるアプローチだといえます。\n\n### 11-4 WebhookとAPIとの違いは？\n\nWebhookとAPIにおいては、どちらもアプリケーション間でデータを連携するために活用されますが、両者は仕組みの観点から明確な違いがあります。\n\nAPIの場合は、必要に応じてデータをリクエストしてレスポンスを受け取る方式ですが、Webhookは事前に設定した条件を満たすことでこちら側からリクエストしなくてもレスポンスを受け取れます。\n\nつまり、Webhookならリアルタイムで必要な情報を受け取ることができます。しかし、APIとは異なりユーザーを認証する機能がないため、悪意ある情報を受け取ったりなどセキュリティにおけるリスクがあります。\n\n## まとめ\t自社のビジネスやサービス開発にAPI戦略を取り入れよう！\n\n自社のソフトウェア開発やビジネスにおいてAPIを積極的に活用することで、開発効率の向上やコスト削減などを実現できます。\n\nAPIにはさまざまな種類がありますが、自社に必要な要件を満たしたAPIを探して積極的に開発に取り入れていくと良いでしょう。\n\n[GitLab](https://about.gitlab.com/ja-jp/)でも開発者向けに包括的なAPIを提供しており、CI/CDパイプラインの自動化から課題管理まで、様々な機能をAPI経由で利用できます。GitLabの利便性の高いAPIを、ぜひこの機会に体験して下さい。\n\nなお、[GitLab](https://about.gitlab.com/ja-jp/)では世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧ください。\n\n[2024グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/)",[696],"2024-12-16",[825,235],{"slug":2400,"featured":92,"template":681},"what-is-an-api","content:ja-jp:blog:what-is-an-api.yml","What Is An Api","ja-jp/blog/what-is-an-api.yml","ja-jp/blog/what-is-an-api",{"_path":2406,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2407,"content":2413,"config":2418,"_id":2420,"_type":16,"title":2421,"_source":17,"_file":2422,"_stem":2423,"_extension":20},"/ja-jp/blog/event-report-japan-it-week-autumn",{"title":2408,"description":2409,"ogTitle":2408,"ogDescription":2409,"noIndex":6,"ogImage":2410,"ogUrl":2411,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2411,"schema":2412},"Japan IT Weekレポート：AIがDevSecOpsを加速する。GitLabソリューションの現在地","2024年10月23～25日に開催されたJapan IT Weekにおいて、GitLabブースで実施したミニセミナーの内容をレポートします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665336/Blog/Hero%20Images/GitLab____.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-autumn","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Japan IT Weekレポート：AIがDevSecOpsを加速する。GitLabソリューションの現在地\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-12-11\",\n      }",{"title":2408,"description":2409,"authors":2414,"heroImage":2410,"date":2415,"body":2416,"category":740,"tags":2417},[738],"2024-12-11","GitLabは2024年10月23～25日、千葉・幕張メッセで開催された「Japan IT Week」に出展しました。今回はブース出展で、多くのお客様に来場いただき、[DevSecOp](https://about.gitlab.com/ja-jp/topics/devsecops/)sの価値とGitLabのソリューションについてお伝えすることができました。本稿では、ブースで開催したセミナーで、皆様にお伝えした内容をまとめて紹介します。\n\n![GitLabノベルティ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab______.jpg)\n*配布したGitLabノベルティ*\n\n## DevOpsからDevSecOps、シフトレフトへ\n\nGitLabのブースには、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)や[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にそれほど詳しくない方や、いままさにスタートさせようという方もいらっしゃいます。そこで、私たちは多くのセッションで、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)から[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)に至る歴史についてお伝えするようにしています。今回も15分というわずかな時間の中で、一定のボリュームをこの解説に割くことにしました。\n\nすでに広く知られているように、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)が生まれたのは、開発チームと運用チームが協力関係を築く方が、開発から運用に至るプロセスの効率化につながると期待されたためです。開発部門は、迅速に多種のソフトウェアを作りたいと考え、一方の運用部門は本番リリース後のリスクを懸念します。[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)は、両部門が対立するのではなく、仲良く目標に向かおうとする文化を醸成する考え方で、多くの組織がこれを取り入れて成功しました。\n\n![IT Week会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/IT_Week_____.jpg)\n*会場の様子*\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)は、開発チーム＋運用チームの[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)に、Sec＝セキュリティ チームを加え、3つのチームが開発段階から協力することで全体最適を図ろうという考え方です。仲良く仕事に取り組む文化はもちろん必要ですが、セキュリティが加わることで大きく変わる部分があります。それが、シフトレフトと呼ばれるものです。\n\n開発から運用の流れは、一般的な作業工程表と同様に、左から右に流れるプロセスとして作図します。シフトレフトは、「左側に移動する」ことで、セキュリティチェックを前倒しで行う変革です。たとえば、開発が完了し、運用前にチェックするという工程では、セキュリティに不備が発見されれば手戻りが発生し、リリースが遅れます。そして、そのような状況は、開発コストが増えることにつながります。[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)によって開発と運用は一連の流れになっているため、開発段階から随時セキュリティチェックを実施することで、プロセスの全体最適を図り、効率を高め、コストを下げ、プロジェクトのサイクルを高速化することができるのです。\n\nしかしながら、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)には多くの人がかかわり、複雑なプロセスを管理する必要があります。すべてを可視化し、最適化するためには、概念で理解するだけでは不可能で、その実現をサポートする“ツール群”が必要になります。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)をやりたいけれど、スタートするだけでも大変で、プロジェクトを回し続けるために[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の管理に多大な労力がかかることになれば、本末転倒です。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)をひとつのプラットフォームとして実現するソリューションがあれば理想でしょう。GitLabは、まさにそんな[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のプラットフォームなのです。\n\nそして、GitLabは、AIを搭載することで、さらに多機能で開発・運用の生産性を高めるプラットフォームへと進化しています。今回、ブースセミナーで主にお伝えしたのは、進化し続けているAI機能についてです。\n\n![GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 皆川 弘貴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab_________________________________________.jpg)\n*GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 皆川 弘貴*\n\n## AIはDevSecOpsに何をもたらすか\n\nブースセミナーでは、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にAIを適用する価値についてわかりやすく表現するために、「AI DevSecOps 1.0と2.0の違い」として説明しました。\n\nAI DevSecOps 1.0は、コード生成の補助が主体になります。「こんなコードを、この言語で書きたい」というプロンプトを入力すると、AIが自動的にコードを生成してくれます。これがバージョンアップしてAI DevSecOps 2.0になると、プロセス全体の効率化のためにAIを活用します。開発ワークフローのさまざまな場面でAIがサポートしてくれるのです。\n\n1.0のAIはいわば「作業ロボット」ですが、2.0ではAIが「バディ（仲間、同僚）」になるようなイメージと言えばわかりやすいでしょうか。\n\n1.0の段階であっても、生産性の向上には重要な役割を担えます。コード生成に加えてバグの自動修正や、AIによる脆弱性の抽出もできるでしょう。中でも、オープンソースプロジェクトにおいて、コール先のさらにコール先までたどって脆弱性を発見する際にAIは大いに役立つでしょう。\n\n2.0はGitLabの目指しているところです。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のリーダーとして、開発プロセス全体を効率化したいと考えているためです。そのため、1.0の中でもよりロボットに近い個別の機能を持つAIは、お客様が自由に選択できるようにしています。一方、ワークフローをまたいで動く「人間の意思」をサポートするAIは、GitLabというプラットフォーム側で用意します。\n\n近くリリースする予定の[GitLab Duo Workflow](https://about.gitlab.com/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/)が、その第一歩です。このAIは、プロンプトを入れると応答してくれる、ロボットのように受動的なAIではありません。開発テーマを与えると、計画やタスク、コードなどをユーザーと一緒に考えて、提案してくれる能動的なAIなのです。本物のバディのようなAIとしてご利用いただきたいと考えています。\n\n## GitLabが進めているAI実装のいま\n\n[GitLab Duo Workflow](https://about.gitlab.com/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/)は、リリース後も進化を続け、理想の姿へと近づけていきます。では、GitLabはまさにいま、どこまでのAI機能を搭載しているのでしょう。最終日の特別セッションで、現在の「AI-powered DevSecOpsプラットフォーム」が搭載する機能の一部を紹介しました。\n\n開発チーム向けの機能としては、AI利用のコーディング補助機能[Code Suggestions](https://about.gitlab.com/ja-jp/solutions/code-suggestions/)が真っ先に挙げられるでしょう。そのほか、レビュー担当者を推奨してくれるSuggested Reviewers、マージリクエスト（MR）の際に加えられた変更内容の説明を自動記述するSummarize MR changes、MRの各レビューにおいて内容を要約するSummarize my MR reviews、必要なGitコマンドを教えてくれるHelp with Git commandsなども開発生産性を高めてくれるAIです。\n\n![GitLab合同会社ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト 小松原 つかさ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab__________________________________________________.jpg)\n*GitLab合同会社ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト 小松原 つかさ*\n\nセキュリティ／運用チーム向けの機能としては、コードの説明を自動生成するExplain this codeが面白いでしょうか。デジタルに詳しくない経営幹部向け、CIO向け、もしくはエンジニア向けなど、対象読者がわかりやすいようにAIが説明文を作ってくれます。そのほか、脆弱性の説明をしてくれるExplain this vulnerability、MRにテストコードを自動で書いてくれるGenerate Tests in MRなども役立つでしょう。\n\n全体最適を図るAIとしては、イシューで議論された内容を要約するIssue Summaries、AIにチャット形式でイシューやエピックについての説明や要約を生成してもらうGitLab Chat、ソフトウェア開発ライフサイクル全体の生産性について過去の傾向の中から異常値を検出するValue streams forecastingなどが挙げられます。\n\nコード自動生成やコードレビューのように基本的な機能を用意する一方で、「GitLabはAIを使って[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のライフサイクルすべてを効率化させる」よう進化しようとしている方向性はご理解いただけると幸いです。\n\n## 3社のパートナー様にもご講演いただきました\n\n今回は、パートナー様に壇上に立ってもらうセッションも用意し、それぞれに興味深い内容をお話いただくことができました。\n\n[株式会社ジークス](https://www.zyyx.jp/) 久保 仁詩氏からは、ユーザー／パートナーとして見たGitLabと他製品の違いについてご講演いただきました。GitLabは、企業レベルのプロジェクトに最適で、グループ、サブグループ、プロジェクトにより、案件ごとにサブグループを切って多層的な階層構造を作れます。ツール切り替え不要のオールインワンプラットフォームであるため、UIは包括的で多機能です。\n\n「他製品でもできることはありますが、顕著な違いがあるのはセキュリティ関連の機能群です。本来の意味で[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を実現できるプラットフォームであると言えるのは、GitLabの最大の価値でしょう」（久保氏）\n\n![SB C&S株式会社 佐藤 梨花氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/SB_C_S___________.jpg)\n*SB C&S株式会社 佐藤 梨花氏*\n\n[SB C&S株式会社](https://cas.softbank.jp/) 佐藤 梨花氏には、[Platform Engineering](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)について紹介いただきました。GitLabは[Platform Engineering](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を実現するツールの1つという位置づけではありますが、極めて好相性です。大規模／分散開発を行っているチームとの親和性が高く、インフラ自動化要素を備えます。ワンプラットフォームであり、サードパーティー連携が豊富な点も魅力です。\n\n「個人的に良いなと感じるのは、ぜんぶそろっているので小さく始めやすいところ。いきなり大きく始めるのはリスクが高いため。少しずつ始めて範囲を広げていくことを望む組織は多く、GitLabを選択しておけば、成功を積み重ねて適用範囲を拡大していけます」（佐藤氏）\n\n[株式会社サーバーワークス](https://www.serverworks.co.jp/) アプリケーションサービス部 遠藤 広也氏からは、AWS CodeCommitからGitLabへの移行についてお話いただきました。AWS CodeCommitは、7月に新規顧客受付を停止しました。既存ユーザーは利用し続けることができるものの、新機能開発が停止されたため、有力な移行先としてGitLabが注目されています。\n\n参考：[【徹底解説！】AWS CodeCommitからGitLabへの移行ガイド](https://about.gitlab.com/ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab/)\n\n移行にあたっては、AWS CodeCommitをGitLabにミラーリングするやり方が良さそうです。両プラットフォームを並行稼働させられるため、移行リスクは最小化されます。遠藤氏は、単なる移行にとどまらないGitLabを使う運用効率化メリットについて、2つの機能を紹介してくれました。\n\n遠藤氏は、「GitLabの環境で[Code Suggestion](https://about.gitlab.com/ja-jp/solutions/code-suggestions/)を使えば確実に生産性を高められます。また、GitLabでもAWS CodePipelineと容易に連携できます。AWS側でソースプロバイダー設定を変更するだけで、クラウド[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)をそのまま使えるのは魅力的です」と話しています。\n\n![GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 権 東彬](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab________________________________________.jpg)\nGitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 権 東彬\n",[280,1880,702,904],{"slug":2419,"featured":92,"template":681},"event-report-japan-it-week-autumn","content:ja-jp:blog:event-report-japan-it-week-autumn.yml","Event Report Japan It Week Autumn","ja-jp/blog/event-report-japan-it-week-autumn.yml","ja-jp/blog/event-report-japan-it-week-autumn",{"_path":2425,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2426,"content":2432,"config":2438,"_id":2440,"_type":16,"title":2441,"_source":17,"_file":2442,"_stem":2443,"_extension":20},"/ja-jp/blog/automating-with-gitlab-duo-part-2-complex-testing",{"title":2427,"description":2428,"ogTitle":2427,"ogDescription":2428,"noIndex":6,"ogImage":2429,"ogUrl":2430,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2430,"schema":2431},"GitLab Duoを使用した自動化シリーズパート2：複雑なテスト","コードテストが標準に準拠していることを確認するなど、GitLabチームが、GitLab DuoのAI機能を使用して、通常より複雑なテスト状況にどのように対処したかをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099243/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750099243011.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-2-complex-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duoを使用した自動化シリーズパート2：複雑なテスト\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-10\",\n      }",{"title":2427,"description":2428,"authors":2433,"heroImage":2429,"date":2434,"body":2435,"category":787,"tags":2436,"updatedDate":2437},[2374],"2024-12-10","[GitLab Duoを使用したテスト生成](https://about.gitlab.com/ja-jp/blog/automating-with-gitlab-duo-part-1-generating-tests/)に関する3部構成シリーズの最初の記事では、コードテストを自動化する方法に焦点を当てました。この記事では、テスト生成にAIを使用する中で学んだ教訓をご紹介します。\n\n## 直面した状況とその対処方法\n\n全体的に見て、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使用してコードテストを生成した結果には満足しています。他の言語生成の場合と同様に、インポートパスを修正したり、データセット内の内容を編集したりするなど、微調整が必要な場合もありました。より複雑なケースでは、AIが提示したソリューションでは、多くの場合、コンテキストが欠けていることを念頭に置いておく必要がありました。それでは、GitLab Duoを使用して、より複雑なテスト状況にどのように対処したかを説明します。\n\n### 既存のテストケースの更新\n\nソフトウェア製品の開発時にソフトウェア製品の開発時にはよくあることですが、既存のテストの更新が必要になる状況が発生しました。私たちは、一般的な問題に対してテスト機能全体を手動で調整するのではなく、VS CodeのGitLab Duo Chatウィンドウを最大限に活用しました。たとえば、テストをリファクタリングするために、「Please update the provided tests to use unittest rather than pytest. （日本語：提供されたテストをpytestではなくunittestを使用するように更新してください。）」とChatプロンプトを入力してから、GitLab Duoに更新してもらいたいテストを貼り付けました。\n\n![テスト生成の自動化](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099252/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099252303.png)\n\n\u003Cbr>\u003C/br>\n\n![pytestではなくunittestの使用をリクエストするChatプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099252/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099252304.png)\n\n**注**：GitLab Duoの推奨事項をコードにコピー＆ペーストしています。\n\n### レガシーコードのテスト作成\n\n正常に動作しているとわかっていたレガシーコードのテストを作成するのも、困難な問題でした。こういった状況では、失敗したテストと一緒にエラースニペットを提供し、GitLab Duoに新しいテストを作成するようリクエストすると非常に便利でした。ターミナルウィンドウから記録された失敗とエラーをすべてコピーしてChatに貼り付け、「Please explain and fix this failing test.（日本語：この失敗しているテストを説明して修正してください。）」といったプロンプトを入力してリクエストしたところ、テストで発生した問題の概要と、問題に対処した新しいテストが生成されました。新しいテストでも失敗が何度か特定されたため、その後、複数回のリファクタリングが必要となる場合がありました。しかし、そういった場合でも、GitLab Duoのおかげで、さまざまなリファクタリングされたソリューションを迅速かつ効率的に得られたため、チーム全体とデベロッパーの効率性が向上する結果となりました。\n\n### 複雑なコードや抽象化されたコードの処理\n\nその他の例では、コードのモジュール化や複雑さにより、GitLab Duoの結果にばらつきが生じました。たとえば、GitLab Duoは、テストアプローチの違い（モックの使い方や、どのオブジェクトをモッキングするかなど）によって、成功するテストと失敗するテストを次々と生成することがありました。これに対処するため、GitLab Duoに成功したテストの例を提供し、一貫性を維持するために成功したテストのスタイルに合わせて個々のテストを1つずつ変更するようリクエストしました。また、同様のオブジェクトやタスクのテストがうまく行っているファイルをGitLab Duoに提供して、構造をミラーリングできるようにしました。\n\n### 生成されたコードが当社の基準に準拠していることを確認\n\nPythonモジュールの開発中、GitLab Duoを活用して、モックを用いた多くのテストを生成しましたが、多くの場合、特に命名標準化に関するリファクタリングが必要となりました。こうしたケースでは、GitLab Duo Chatを活用し、どの特定のテストコンポーネントを更新するかといった手順を指示すれば、テストをリファクタリングできました。GitLab Duoにこれらの変更を行うよう指示するほうが、今まで行っていたように、テストを個別にリファクタリングするよりもはるかに高速でした。\n\n### 対象外のテストケースへの対処\n\nGitLab Duoを使用することで、当社チームが今までは検討していなかった他のテストケースのテストを生成できたため、カバレッジが向上しました。幸いなことに、GitLab Duoを使用して、これらのエッジケースに迅速かつ効率的に対処し、テストカバレッジを拡大できました。これは、当社チームにとって、開発速度の向上、および堅牢な製品開発につながる重要な付加価値となりました。\n\n## 学んだ教訓\n\nGitLab Duoをうまく活用して成功を収める中で学んだ、重要な教訓をいくつかご紹介します。\n\n* **迅速で効率的な開発とイテレーション** - 自動テストの生成作業におけるGitLab Duoの役割は、チームの開発プロセス内での重要なアクセラレーターとなり、変更をより迅速かつ自信を持って行うことができました。\n* **適切なプロンプトを使用することの重要性** - GitLab Duoを当社のユースケースで使用する際には、機械学習の最適化における重要なトピックであるプロンプトエンジニアリングに触れました。理想的な回答を得るためには、いくつかのキーワードを使用して質問を修正する必要があることもわかりました。\n* **基盤となるフレームワークとコードを理解する必要性** - テストとして使用される場合であっても、製品に組み込まれるAI生成コードに関しては、どのように機能するかを理解して、適切にデバッグし、情報に基づいた変更をリクエストできるようにすることが重要です。\n* **望ましい最終的な状態と標準を把握しておく必要性** - AIを使用せずに開発する際に、フォーマットやライブラリの使用に関するコーディング標準に従うのと同様、AIを使用する際も意図する結果がどのようなものであるか、どのような標準に準拠すべきであるかというビジョンを持つことが重要です。GitLab Duoは、コード標準を理解するためにコンテキストを必要とします。そのため、GitLab Duoを使用するチームメンバーは、品質やその他の期待が確実に満たされるように、出力を適切に監視することが重要です。\n* **GitLab Duoはすべてのテストの代わりとなるものではない** - 自動化されたテストを生成する際は、GitLab Duoを多用していますが、他のテストや人間による監視に代わるものではありません。機能テスト、統合テストなどは、QAプロセスとソフトウェア開発ライフサイクル全体において以前として重要な役割を果たします。\n\nこのシリーズの次回の記事では、[チームの自動テストプロセスにおけるGitLab Duoの影響を検証するために実行したテスト](https://about.gitlab.com/ja-jp/blog/automating-with-gitlab-duo-part-3-validating-testing/)と、これまでに達成した素晴らしい結果について説明します。\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[721,2378,904],"2025-05-02",{"slug":2439,"featured":6,"template":681},"automating-with-gitlab-duo-part-2-complex-testing","content:ja-jp:blog:automating-with-gitlab-duo-part-2-complex-testing.yml","Automating With Gitlab Duo Part 2 Complex Testing","ja-jp/blog/automating-with-gitlab-duo-part-2-complex-testing.yml","ja-jp/blog/automating-with-gitlab-duo-part-2-complex-testing",{"_path":2445,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2446,"content":2452,"config":2458,"_id":2460,"_type":16,"title":2461,"_source":17,"_file":2462,"_stem":2463,"_extension":20},"/ja-jp/blog/how-gitlab-empowers-translators-with-more-context",{"title":2447,"description":2448,"ogTitle":2447,"ogDescription":2448,"noIndex":6,"ogImage":2449,"ogUrl":2450,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2450,"schema":2451},"翻訳者により多くのコンテキストを伝えるGitLabの新機能","翻訳者により詳細なコンテキストを伝える新機能がGitLabに追加されました。翻訳コミュニティに参加して、GitLabをあなたの言語に翻訳しませんか。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"翻訳者により多くのコンテキストを伝えるGitLabの新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n        \"datePublished\": \"2024-12-09\",\n      }",{"title":2447,"description":2448,"authors":2453,"heroImage":2449,"date":2455,"body":2456,"category":962,"tags":2457},[2454],"Oleksandr Pysaryuk","2024-12-09","GitLabは、翻訳者と校正者で構成されたグローバルコミュニティによって継続的に翻訳されています。この活動は[Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html)を通じて行われており、78の言語に翻訳することで、GitLabを世界中のユーザーにとってより身近なものにしています。GitLabの翻訳コミュニティには、ボランティア翻訳者、GitLabユーザーである社会人、[大学の授業のプロジェクトの一環として翻訳に取り組む学生](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/)が参加しています。\n\n### GitLabではオープンコアモデルで翻訳者を支援\n\nコミュニティではすばらしい協力体制が築かれているものの、翻訳しているテキストのコンテキストが十分にわからないという、大きな問題に直面することがあります。\n\n優れた翻訳とは、単なる言葉の変換ではありません。意味や意図、わかりやすさをターゲット言語でも維持しなければなりません。ソフトウェア翻訳には、特殊な技術が求められます。優れた翻訳者は、複数の言語だけでなく、製品に関する技術的な知識にも精通していることが一般的です。また翻訳に関連して、以下のようなさまざまな作業を行っています。\n\n* 技術用語の正確性と一貫性の維持  \n* 新しい概念に適した、新たな用語の策定  \n* スタイルやトーンの遵守\n* [共通ロケールデータリポジトリ（CLDR）の複雑な複数形に関する規則](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html)の理解 \n* 複数の要素からなるメッセージの翻訳可能性と、原文をローカライズ可能にするためのフィードバックの提供方法の理解\n\n翻訳者はコンテキストの調査や質問、[GitLabの製品ドキュメント](https://docs.gitlab.com/)の確認に多くの時間を費やしています。適切なコンテキストがなければ、単純なテキストであっても誤訳され、ユーザーのワークフローを混乱させる可能性があります。GitLabの特長は、翻訳者が製品開発のコンテキストの大部分に直接アクセスできる[オープンコアモデル](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/)にあります。この透明性により、翻訳者は[GitLabのグローバル製品の真の共同制作者](https://handbook.gitlab.com/handbook/company/mission/#mission)として積極的にコントリビュートできます。\n\n### 詳細なコンテキストを提供する新機能のご紹介\n\n翻訳者のニーズに応え、より多くのコンテキストを提供するために、GitLabは新たな機能を開発しました。[翻訳可能な各文字列へのコンテキストリンクの埋め込み機能](https://docs.gitlab.com/ee/development/i18n/translation.html#context)（具体的には、グローバル製品内検索へのリンクを埋め込む機能）です。これにより、翻訳者はその文字列がコードベース内のどこで使用されているかをすべて特定できるようになります。これらのリンクを使うことで、翻訳者は[Git blame]( https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html)を活用してコード内の現在の位置、マージリクエスト内のコミット、元の計画段階の話し合いまで、その文字列の履歴をすべて確認できます。\n\nたとえば、**Rotate**というテキストを翻訳する場合、**AccessTokens|**という[ネームスペース](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces)によって、そのテキストのコンテキストが、*アクセストークン*であることが示されます。しかし、**Rotate**が何を意味するかを示す視覚的なコンテキストはないため、翻訳者はその意味を考え、推測して、可能な限り最善の訳をターゲット言語で提供するしかありません。\n\n新しいコンテキスト支援機能によって、翻訳者は以下のことができるようになりました。\n\n1. 「**この文字列の使用箇所をコード内で確認**」セクションのURLをクリックします。\n\n![「この文字列の使用箇所をコード内で確認」セクション](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. [コード検索結果](https://gitlab.com/search?project_id=278964&search=%22%28%5B%5E%3A%5D%28+%29%2B%3F%7C_%5C%5C%28%29%5B%27%5C%22%60%5DAccessTokens%5C%5C%7CRotate%5B%27%5C%22%60%5D%22+%28file%3A%5C.js%24+or+file%3A%5C.vue%24+or+file%3A%5C.rb%24+or+file%3A%5C.erb%24+or+file%3A%5C.haml%24%29+%28file%3A%5Eee%2Fapp%2F+or+file%3A%5Eee%2Flib%2F+or+file%3A%5Eee%2Fconfig%2F+or+file%3A%5Eee%2Flocale%2F+or+file%3A%5Eapp%2F+or+file%3A%5Elib%2F+or+file%3A%5Econfig%2F+or+file%3A%5Elocale%2F%29&regex=true)を確認し、「**blameを表示**」アイコンをクリックします。\n\n![「blameを表示」アイコンが表示された画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378611/Blog/rungtmk8izelr685gcgt.png)\n\n3. 関連するマージリクエストへのリンク（[Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954)）を開きます。\n\n![関連するマージリクエストへのリンク](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n4. **コミット**ページで、実際のマージリクエストへのリンクを開きます。\n\n![リンクが表示されたコミットページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n5. ソフトウェアエンジニアがマージリクエストに追加した画面録画を確認します。\n\n![マージリクエストに追加された画面録画](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378617/Blog/rngjn0kxcicm5ctkbgji.png)\n\n6. さらに詳しく調べるには、以下のリンクを開きます。\n   a. リンクされたイシュー（[Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523)）またはその親エピック（[Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563)）\n\n![リンクされたイシューと親エピック](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\nb. [GitLab製品のドキュメントを更新する、関連するマージリクエスト](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916)\n\n![GitLab製品のドキュメントを更新する、関連するマージリクエスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378639/Blog/eka709hshg47eruwhauf.png)\n\nこれらの調査ステップを通じて、翻訳者は*アクセストークンローテーション*という技術的な概念、その機能がなぜ追加されたのか、どのように動作するのか、そしてそれがユーザーのどのような問題を解決するのかをより深く理解できます。\n\nこの充実した調査プロセスによって、翻訳者は**Rotate**という一見シンプルな単語に対しても、最大限のコンテキストを得た上で、技術的に正確かつ言語的に適切な翻訳を提供できます。\n\nこのアプローチは、スクリーンショットの提供や製品ユーザーインターフェイスの確認など、これまでの翻訳支援よりはるかに有益です。翻訳者は今後、以下の方法でコンテキストを完全に把握できます。\n\n* コード内で使用されるパスや命名規則からコンテキストを導き出す\n* 元のマージリクエストに追加されたスクリーンショットや動画を確認する\n* 初期の計画や開発段階のディスカッションを読む\n* そのテキスト表現にいたるまでのエンジニアリング、コピーライティング、製品管理の意思決定プロセスを確認する\n\n### AIを活用したコンテキスト支援機能をさらに追加予定\n\nGitLabのローカリゼーションチームはここで止まりません。現在、翻訳者に文字列の用途や配置に関する情報を提供するAI搭載ツールをはじめとした、[さらなるコンテキスト支援機能](https://gitlab.com/groups/gitlab-com/localization/-/epics/81)の開発に取り組んでいます。文字列が製品UIのどこでどのように使用されているのかについてエージェントに質問したり、コードの内容を踏まえた回答をいつでも即座に取得したりできるシステムを想像してみてください。\n\n> ### [Crowdinのコミュニティ](https://docs.gitlab.com/ee/development/i18n/)に、翻訳者または[校正者](https://docs.gitlab.com/ee/development/i18n/#proofreading)として参加して、新しいコンテキスト支援機能をお試しください。そして、[GitLabの翻訳体験と製品改善](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259)について、ぜひご意見をお聞かせください。\n",[270,675,701,2158],{"slug":2459,"featured":6,"template":681},"how-gitlab-empowers-translators-with-more-context","content:ja-jp:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","ja-jp/blog/how-gitlab-empowers-translators-with-more-context.yml","ja-jp/blog/how-gitlab-empowers-translators-with-more-context",{"_path":2465,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2466,"content":2472,"config":2477,"_id":2479,"_type":16,"title":2480,"_source":17,"_file":2481,"_stem":2482,"_extension":20},"/ja-jp/blog/event-report-gartner-it-symposium",{"title":2467,"description":2468,"ogTitle":2467,"ogDescription":2468,"noIndex":6,"ogImage":2469,"ogUrl":2470,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2470,"schema":2471},"くら寿司が語るソフトウェア開発の「生産性向上」と「セキュリティ・ガバナンス」の重要性【イベントレポート】","2024年10月に開催された「Gartner IT Symposium/Xpo」の当社セッションにおいて、くら寿司様より事例を紹介いただきましたので、その模様をお伝えします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665029/Blog/Hero%20Images/_________DX__________________GitLab____________________.jpg","https://about.gitlab.com/blog/event-report-gartner-it-symposium","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"くら寿司が語るソフトウェア開発の「生産性向上」と「セキュリティ・ガバナンス」の重要性【イベントレポート】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-12-05\",\n      }",{"title":2467,"description":2468,"authors":2473,"heroImage":2469,"date":2474,"body":2475,"category":2156,"tags":2476},[738],"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/)",[762],{"slug":2478,"featured":92,"template":681},"event-report-gartner-it-symposium","content:ja-jp:blog:event-report-gartner-it-symposium.yml","Event Report Gartner It Symposium","ja-jp/blog/event-report-gartner-it-symposium.yml","ja-jp/blog/event-report-gartner-it-symposium",{"_path":2484,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2485,"content":2490,"config":2495,"_id":2497,"_type":16,"title":2498,"_source":17,"_file":2499,"_stem":2500,"_extension":20},"/ja-jp/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai",{"title":2486,"description":2487,"ogTitle":2486,"ogDescription":2487,"noIndex":6,"ogImage":1221,"ogUrl":2488,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2488,"schema":2489},"GitLab Duo with Amazon Q：DevSecOpsに自律型AIという新たな選択肢を","AIを活用したDevSecOpsは、自律型AIエージェントにより、デベロッパーの生産性、アプリケーションのモダナイゼーション、そしてイノベーションを加速させます。","https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo with Amazon Q：DevSecOpsに自律型AIという新たな選択肢を\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilio Salvador\"}],\n        \"datePublished\": \"2024-12-03\",\n      }",{"title":2486,"description":2487,"authors":2491,"heroImage":1221,"date":2492,"body":2493,"category":787,"tags":2494,"updatedDate":2434},[1624],"2024-12-03","GitLabは、Amazon Qとの共同開発による新たなソリューション「GitLab Duo with Amazon Q」をリリースします。この統合型ソリューションは、GitLabの包括的なAI搭載DevSecOpsプラットフォームとAmazon Qの自律型AIエージェントを組み合わせたものです。\n\nGitLab Duo with Amazon Qを活用して強力なAIエージェントを日々のワークフローに直接統合することで、ソフトウェア開発を革新できます。複数のツールを切り替える必要がなくなり、デベロッパーはGitLabの包括的なDevSecOpsプラットフォーム内で、機能開発からコードレビューに至るまでの主要なタスクを加速できます。Amazon QのAIエージェントは、インテリジェントなアシスタントとして、要件に基づくコード生成、ユニットテストの作成、コードレビューの実施、Javaアプリケーションのモダナイゼーションなど、時間のかかるタスクを自動化します。この共同ソリューションは、こうした複雑なタスクを処理することで、セキュリティと品質基準を維持しながら、チームがイノベーションに集中できるよう支援します。\n\nこのエンタープライズ向けのデベロッパーエクスペリエンスには次の内容が含まれます。\n\n* 単一のデータストアを備えたGitLabの統合プラットフォームで、安全なコードのビルド、テスト、パッケージ化、デプロイを自動化できます。\n* Amazon Q Developerによって強化されたGitLab Duoで、GitLabプロジェクトのコンテキストを活用し、タスクに基づいて複数ファイルの変更を生成できます。\n* GitLab Duoに統合されたAmazon QのAIエージェントで、タスクごとにイシューを更新し、マージリクエストを作成できます。これらはプロジェクト単位で権限が設定されています。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1033653810?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo and Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## パートナーシップによるイノベーション：GitLabとAWS\n\nGitLab Duo with Amazon Qは、GitLabとAWS社のエンジニアリングチームの緊密な協力から誕生しました。このパートナーシップは、ソフトウェア開発を革新するために両社の強みを結集したものです。GitLabの統合型DevSecOpsにおける専門知識と、AWS社のクラウドコンピューティング分野でのリーダーシップを融合し、デベロッパーのニーズを理解する革新的なソリューションを実現しました。\n\nAmazon Qの自律型エージェントをGitLabの包括的なAI搭載プラットフォームに統合することで、単なる技術的な連携を超えた体験を実現しました。これにより、AIを活用した直感的な開発が可能になっただけでなく、エンタープライズが求めるセキュリティ、コンプライアンス、信頼性も確保されています。\n\n業界のアナリストたちは、AI搭載型ソフトウェア開発の進展においてこの統合が持つ重要性を認識しています。\n\n***「このコラボレーションにより、GitLabとAWSはそれぞれの強みを組み合わせて、ソフトウェア開発におけるエージェント型AIを実現しています。GitLab Duo with Amazon Qは、顧客がAIの可能性を最大限に活用できるよう、効果的なユースケースに取り組むとともに重要な課題に対処しています」（IDC社、リサーチマネージャー、Katie Norton氏）***\n\n***「デベロッパーと彼らが働く組織の両方が、シンプルで統合されたエクスペリエンスにますます関心を持っています。特に、セキュリティとプライバシーが最重要の懸念事項であるAIの時代には、最先端のテクノロジーの力を活用すると同時に、リスクを制御し、分断されたソフトウェアツールチェーンを最小限に抑えたいと考えています。GitLab DuoとAmazon Qのパートナーシップは、エンドツーエンドのDevSecOpsエクスペリエンスの中でデベロッパーが必要とするツールを提供することを目指しています」（RedMonk社、シニアアナリスト、Rachel Stephens氏）***\n\n## 4つの主要な顧客メリット\n\nGitLab Duo with Amazon Qは、AI搭載型DevSecOpsと最も充実したクラウドコンピューティング機能を組み合わせ、開発チームを次のように支援します。\n\n### 1. 機能開発におけるアイデアからコードへの変換を効率化\n\n開発チームは、要件をコードに変換する作業に多くの時間を費やすことが多く、その結果、納期の遅延や実装時の不整合が生じることがあります。しかし、新しいクイックアクション`/q dev`を使用することで、GitLab Duo with Amazon QのAIエージェントを呼び出し、イシューの内容をマージ可能なコードに数分で直接変換できるようになりました。このエージェントは要件を分析し、実装を計画し、最適なマージリクエストを生成します。すべて、チームの開発基準を遵守しながら行われます。さらに、コメントでのフィードバックを活用して迅速にイテレーションを行うことで、アイデアから本番環境での動作可能なコード開発を可能にします。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050110?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Feature Dev with Rev\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 2. レガシーコードのモダナイゼーションの手間を低減\n\n従来、Javaアプリケーションのアップグレードには、数週間にわたる慎重な計画、手作業でのコード変更、大規模なテストが必要でした。しかし、新しいクイックアクション`/q transform`を使用することで、Javaモダナイゼーションプロセス全体を自動化できます。エージェントは、Java 8やJava 11のコードベースの分析、包括的なアップグレード計画の作成、Java 17への移行に必要なマージリクエストのドキュメント化および生成、これらすべてを数時間でなく、わずか数分でこなします。コード変換中のすべての変更が逐次報告されるため、チームは安心して作業を進められ、アプリケーションのセキュリティとパフォーマンスも向上します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050145?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"QCT\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 3. 品質を損なうことなくコードレビューを加速\n\nコードレビューはボトルネックになりがちです。フィードバックを得るまでに数日待つ一方で、一貫した基準を維持する必要があります。しかし、クイックアクション`/q review`を使用すれば、マージリクエスト内でコード品質やセキュリティに関するフィードバックを即座に得られます。エージェントは、チームの基準に基づいて潜在的な問題を自動的に特定し、改善案を提案します。これにより、レビューサイクルを飛躍的に短縮しつつ、高品質なコードを維持できます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050136?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Code Reviews\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 4. テストの自動化により自信を持ってリリース\n\n手動でのテスト作成は時間がかかる上、チーム間でテストの範囲にばらつきが生じることがよくあります。しかし、クイックアクション`/q test`を使用すれば、アプリケーションのロジックを理解した包括的なユニットテストを自動生成できます。エージェントは重要なパスやエッジケースを徹底的にカバーし、既存のテストパターンに一致させます。この自動化により、チームは問題を早期に発見し、一貫した品質基準を維持しながら、デベロッパーの貴重な時間を節約できます。\n\n\u003Cdiv style=\"padding:54.37% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050181?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Use GitLab Duo with Amazon Q to add tests\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## エンタープライズ向けのセキュリティとガードレールを標準搭載\n\nエンタープライズ規模とセキュリティを念頭に設計されたこのソリューションは、GitLabの統合型セキュリティ、コンプライアンス、プライバシー機能とAmazon QのAIエージェントを組み合わせ、デベロッパーのワークフローを加速し、組織がより迅速にセキュアなソフトウェアをリリースできるよう支援します。\n\n統合機能の特長：\n\n* 開発速度を維持するためのガードレールを標準装備\n* それぞれのレベル（ユーザー、プロジェクト、グループ）でAI搭載機能を管理できるきめ細かい制御性\n* 既存のワークフローに統合可能なエンドツーエンドのセキュリティ\n\nDevSecOpsチームは、世界で最も広く採用されているクラウドを活用して、開発環境を安全にスケールできます。\n\n## 今後の展望\n\nGitLab Duo with Amazon Qは、[2024年5月に発表されたAWS社との既存のインテグレーション（英語）](https://press.aboutamazon.com/2024/4/aws-announces-general-availability-of-amazon-q-the-most-capable-generative-ai-powered-assistant-for-accelerating-software-development-and-leveraging-companies-internal-data)を基盤としており、ソフトウェア開発を変革するという共同のミッションにおいて大きな前進をもたらしました。今回のより高度なAI機能の統合は、AWS社との連携拡大の始まりを示しています。今後もこれらの機能を進化させ、次の点に注力していきます。\n\n* 開発ライフサイクル全体へのAI機能の拡張\n* デベロッパーの生産性向上\n* エンタープライズ規模の開発ニーズへの対応\n\n**GitLab Duo with Amazon Qは現在、GitLab.orgプロジェクト内の[パブリックブランチ](https://gitlab.com/groups/gitlab-org/-/epics/16059)で利用可能です。この機能のプレビュー版にアクセスし、ソフトウェア開発プロセスをどのように変革できるか詳しく知りたい方は、[当社のウェブサイト](https://about.gitlab.com/partners/technology-partners/aws/#interest)をご覧ください。**\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[700,920,721,904,235],{"slug":2496,"featured":92,"template":681},"gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai","content:ja-jp:blog:gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai.yml","Gitlab Duo With Amazon Q Devsecops Meets Agentic Ai","ja-jp/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai.yml","ja-jp/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai",{"_path":2502,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2503,"content":2509,"config":2514,"_id":2516,"_type":16,"title":2517,"_source":17,"_file":2518,"_stem":2519,"_extension":20},"/ja-jp/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai",{"title":2504,"description":2505,"ogTitle":2504,"ogDescription":2505,"noIndex":6,"ogImage":2506,"ogUrl":2507,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2507,"schema":2508},"破損したCI/CDパイプラインをAIで迅速に解決","CI/CDパイプラインの失敗が発生すると、遅延、生産性の低下、ストレスが生じます。AI搭載の根本原因分析なら、より迅速でスマートな問題解決ができます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097355/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097355230.png","https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"破損したCI/CDパイプラインをAIで迅速に解決\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2024-12-03\",\n      }",{"title":2504,"description":2505,"authors":2510,"heroImage":2506,"date":2492,"body":2511,"category":787,"tags":2512,"updatedDate":2513},[980],"CI/CDパイプラインは、ソフトウェア開発における効率の要です。これにより、チームはコードのテスト、ビルド、デプロイを迅速に行うことができます。しかし、こうしたパイプラインが破損すると、すべてに遅れが生じ、締め切りに間に合わなくなります。また、デベロッパーは、問題の解決に取り組み、プロジェクトを軌道に戻そうと奮闘する中で、不満を抱えたままになってしまいます。\n\n![失敗したジョブを複数含むCI/CDパイプライン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097362/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097362772.png)\n\n\u003Ccenter>\u003Ci>失敗したジョブを複数含むCI/CDパイプライン\u003C/i>\u003C/center>\u003Cbr>\u003C/br>\n\n**では、そもそもなぜパイプラインは破損してしまうのでしょうか？** 詳しく見ていきましょう。\n\n## パイプラインの失敗が生じる理由\n\nパイプラインの失敗は、[CI/CDパイプライン](https://about.gitlab.com/ja-jp/topics/ci-cd/cicd-pipeline/)内の自動化されたワークフロー（ビルド、テスト、コードのデプロイなどを含む一連のステップ）が正常に実行されず、エラーメッセージで終了する場合に発生します。この失敗により、コードが適切にビルド、テスト、またはデプロイされないことになり、ソフトウェアデリバリーが遅れるだけでなく、トラブルシューティングが必要になります。\n\nパイプラインの失敗にはさまざまな原因があります。一般的な原因には次のようなものがあります。\n\n- 構文エラー：セミコロンの不足や変数名の間違いなど、コード内の小さなミス\n- テストの失敗：コードの不具合、誤設定、依存関係の不一致により、ユニットテストや統合テストが失敗する\n- 設定ミス：パイプライン設定や環境設定により、ビルドやデプロイが失敗する\n\nさらに複雑な問題もあります。\n\n- Infrastructure-as-Code（[IaC](https://about.gitlab.com/ja-jp/topics/gitops/infrastructure-as-code/)）の問題：TerraformスクリプトやCloudFormationテンプレートのエラーなど、クラウドインフラストラクチャのプロビジョニングで問題が発生し、正常なデプロイができない\n- KubernetesとGitOpsの課題：[Kubernetesクラスター](https://about.gitlab.com/blog/kubernetes-the-container-orchestration-solution/)の設定ミスや[GitOps](https://about.gitlab.com/ja-jp/topics/gitops/)ワークフローの問題（Kubernetesの状態とGitリポジトリの同期など）により、原因特定が困難なパイプラインの失敗が発生する\n-  長くて複雑なスタックトレース：システムの深い部分でエラーが発生すると、特に複数のコンポーネントやサービスにまたがるとスタックトレースが長く複雑になり、解読が難しくなる\n\nこうした理由から、トラブルシューティングがより難しく時間がかかるものになります。根本原因を特定するには、複雑なログの確認や設定ファイルの見直し、さまざまな解決策の検証が必要になるからです。\n\n## 失敗したパイプラインの実際の影響\n\nパイプラインが失敗すると、デプロイが遅れるだけでなく、ストレスや不満も引き起こします。デベロッパーは作業を中断し、トラブルシューティングに専念する必要があり、多くの場合、チームやプロジェクト全体、他のタスクへと影響が広がります。 その結果、納期を守るのがさらに難しくなり、チーム全体のプレッシャーが増えます。しかし、なぜ手動でのトラブルシューティングはこれほど大きなストレスになるのでしょうか？\n\n### 手動でのトラブルシューティング\n\n壊れたパイプラインを修正するのにかかる時間はケースによってさまざまです。次のような要素に依存します：\n\n- デベロッパーがプロジェクトをどれだけ理解しているか  \n- 類似の問題に対する経験  \n- 全体的な問題解決能力\n\nログを手動で調べて原因を特定するのは、骨の折れる単調な作業です。ログは、アプリケーションエラーやシステムメッセージを含むあらゆるところに存在し、多くの場合、整理されておらず解釈が難しいことがあります。その上、パイプラインの修正には、通常、タスク間を行ったり来たりしながら作業を進める必要があり、さらに時間がかかります。\n\nそこで役に立つのが[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)です。GitLab Duoは、そういった複雑なデータをすべて分析し、問題を素早く見つけ出します。専門知識がなくても何が原因かを特定できるようプロセスをシンプルにします。AIを活用することで、パイプラインの修正がより速く、簡単で、はるかにストレスの少ないものになります。\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176104/Blog/zxvvu7p9vc3qpmwl32ya.png\" alt=\"broken pipeline\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176108/Blog/bpx6dqilfhltzboyp8k8.png\" alt=\"fix suggestions for broken pipelines\">\n\n## 生成AIによるGitLab Duo根本原因分析\n\n[GitLab Duo根本原因分析（RCA）](https://docs.gitlab.com/ee/user/gitlab_duo/#root-cause-analysis)を活用すれば、CI/CDパイプラインが破損しても、何時間もかけて手動でトラブルシューティングする必要はありません。このAI搭載ツールは、失敗の原因を正確かつ素早く特定し、修正案をDevSecOpsプラットフォーム内で提供します。スタックトレースがどれだけ長く複雑でも、RCAはすべてのデータを分析し、分かりやすく処理して、実行可能なインサイトを提供します。\n\nエラーの原因の正確な情報を提供してくれるだけでなく、修正手順を示し、注意が必要なファイルやコード行まで具体的に教えてくれます。 さらに、コード提案で全体を正常に戻すサポートをするため、トラブルシューティングが非常に速く、シンプルに進みます。\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176111/Blog/nmagby9hoksskogve53m.png\" alt=\"root cause of failure\">\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176115/Blog/dndis1cedwbmbnj33q3v.png\" alt=\"example fix\">\n\n## フォローアップ質問で会話を掘り下げる\n\nGitLab Duo RCAでは、答えを得た後にさらに詳細な質問をして、問題を掘り下げることができます。代替案を検討したい場合も、リポジトリ内の他のファイルやイシュー、エピックを参照にすることで、[コンテキスト](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html#the-context-chat-is-aware-of)を追加できます。たとえば、`.gitlab-ci.yml`ファイルをIDEで開き、「このファイルとCI/CDパイプラインの分析結果をもとに、どのようにパイプラインを改善するのが最適だと思いますか？」とChatで質問できます。\n\n## プライバシー第一で、すべてGitLab内で処理\n\nGitLab Duo RCAの最大の利点のひとつは、GitLab内でそのまま利用できることです。ツールを切り替えたり、外部のサポートを探したりする必要はありません。また、[ログや機密データを外部のAIソリューションに送信する必要もありません。GitLab内で安全に処理](https://about.gitlab.com/ja-jp/privacy/)されます。RCAはGitLabにシームレスに統合されており、プライバシーを守りながら有益なインサイトを提供します。\n\n![パイプラインの破損 - 画像6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097363/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097362773.png)\n\n## 今すぐ始める\n\nAIを活用して開発プロセスをパワーアップし、よりスムーズかつスピーディーに進めてみませんか？以下のGitLab Duo Enterprise製品ツアーで、プランニング、コーディング、トラブルシューティング、デプロイまで、GitLab DuoのAI搭載機能が全工程にわたって与える効果をご覧ください。ツアーを開始するには、下の画像をクリックしてください。\n\n[![GitLab Duo Enterpriseツアー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097363/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-12-02_at_12.41.10_PM_aHR0cHM6_1750097362774.png)](https://gitlab.navattic.com/duo-enterprise)\n\n> [GitLab Duoの無料トライアルを今すぐお試しいただけます。](https://about.gitlab.com/ja-jp/solutions/gitlab-duo-pro/sales/)\n\n\u003Cbr>\n\u003Cbr>\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n",[721,904,676,678],"2025-03-12",{"slug":2515,"featured":6,"template":681},"quickly-resolve-broken-ci-cd-pipelines-with-ai","content:ja-jp:blog:quickly-resolve-broken-ci-cd-pipelines-with-ai.yml","Quickly Resolve Broken Ci Cd Pipelines With Ai","ja-jp/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai.yml","ja-jp/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai",{"_path":2521,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2522,"content":2528,"config":2534,"_id":2536,"_type":16,"title":2537,"_source":17,"_file":2538,"_stem":2539,"_extension":20},"/ja-jp/blog/automating-with-gitlab-duo-part-1-generating-tests",{"title":2523,"description":2524,"ogTitle":2523,"ogDescription":2524,"noIndex":6,"ogImage":2525,"ogUrl":2526,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2526,"schema":2527},"GitLab Duoを使用した自動化シリーズパート1：テストの生成","AI主導のDevSecOpsプラットフォーム（GitLab Duo）を使用して自動テストを生成し、開発速度と品質を向上させた方法をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097480/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097480784.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-1-generating-tests","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duoを使用した自動化シリーズパート1：テストの生成\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-02\",\n      }",{"title":2523,"description":2524,"authors":2529,"heroImage":2525,"date":2530,"body":2531,"category":787,"tags":2532,"updatedDate":2533},[2374],"2024-12-02","テストの自動化には時間がかかり、プロジェクトが前進していないように感じることもあります。しかし、多くのデベロッパーが経験しているように、自動テストを導入することで全体的に投資収益率がプラスになります。カスタムモジュールを構築（この記事ではgitlab-helperと呼びます）した場合、これが特に当てはまりました。\n\n当初の開発においては、既存のスクリプトから、将来の機能のベースラインとしてのみ使用される新たなモジュールに、実績のある機能を移行することにフォーカスしました。既存のスクリプトには自動テストが含まれていませんでしたが、一貫して使用することで、機能の期待どおりの動作を示す強力な裏付けとなりました。\n\n私たちの目標は、この問題に対するより成熟した解決策を用意することでした。そのため、自動テストが必要になったのです。これにより、テストにかける時間と堅牢な製品を開発する時間のバランスを取りつつ、効率的に構築するという課題が生じました。合計3人しかいないチームメンバーにとって、これは大きな障壁でした。そこでチームは、当社の一連のAI機能である[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を活用してテスト生成を行い、製品のデリバリー速度と品質を向上させることにしました。\n\nGitLab Duoを使用した自動化に関するこの3部構成のシリーズでは、以下の内容を説明します。\n\n1. GitLab Duoを使用してコードテストをどのように生成したか\n2. より複雑な状況でのGitLab Duoのインタラクティブな活用方法\n3. 達成できた結果（ネタバレ：デベロッパー1名と GitLab Duoの活用だけで、 2日間で84%のカバレッジを実現）\n\n## GitLab Duoを使用してコードテストを生成する\n\n機能自体はどのツールでも利用できますが、この記事では、VS CodeでGitLab Duoを使用し、[VS Code用GitLabワークフロー拡張機能](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow)を用いて、テストを生成する方法について説明します。その他のGitLab Duoオプションへのリンクは、下部の参照に記載されています。\n\n### GitLab Duoをインストールして有効にする\n\nまずは、GitLab Duoを使用するための前提要件として、GitLab Duo対応のアカウントを持っていることを確認しました。GitLab Duoをお持ちでない場合は、[無料トライアルにお申し込み](https://about.gitlab.com/ja-jp/solutions/gitlab-duo-pro/sales/?type=free-trial)いただけます。\n\nVS CodeでGitLab Duo Chatを使用する方法は、[こちらのインストール手順](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#use-gitlab-duo-chat-in-vs-code)に従いました。そうすると、サイドバーにGitLab Duo Chat拡張機能が表示され、次のChatウィンドウが開きました。\n\n![質問ウィンドウ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097489/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097488918.png)\n\n### Chatでテストを生成する\n\ngitlab-helperは、チームの作業全体でGitLab APIとのインタラクションを標準化するために構築されたカスタムモジュールです。他のライブラリ機能を拡張して開発およびスクリプト作成作業を簡素化します。メソッドや機能がgitlab-helperに移行され、適切に実装されていることが確認できたら、そのテストを生成するプロセスは簡単でした。\n\n- IDEでメソッド、クラス、またはファイル全体を選択します。\n- 選択したコードを右クリックします。\n- **GitLab Duo Chat**で、**Generate tests**を選択します。\n\n![ドロップダウンを含む、テストを生成するための順列](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097489/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097488919.png)\n\n数秒以内にテストが生成され、GitLab Duo Chatウィンドウに表示されました。これらのテストはレビューしたり、コピー＆ペーストでコードベースに付け加えたり、既存や新規のテストファイルへ追加したりすることができます。今日のほとんどの世代の自然言語処理の場合と同様に、特にコンテキスト周りでは、GitLab Duoによって作成された初期テストの一部は失敗し、微調整（ネストされた依存関係の処理など）が必要になりました。\n\n> **上級者向けのコツ**：GitLab Duoは、生成されたテストの追加先のファイルを自動作成しません。新規のテストファイルを作成し、ファイル内の上部に`# Tests Generated by Duo`とコメントを追加し、さらにそれらのテストの作成方法がわかるように`_duo.py`と末尾につけておくと便利でした。\n\nGitLab Duoは、gitlab-helperの自動テストを構築するための優れた出発点となり、テスト作成の効率とコードカバレッジが大きく向上し、開発プロセスが大幅に高速化されました。GitLab Duoを使用しつつ、人間が監督することで、有用なテストのイテレーションを多数、gitlab-helperモジュールに導入することができました。\n\nこのシリーズの次回の記事では、[GitLab Duoを使用して自動テストを生成する際に学んだこと](https://about.gitlab.com/ja-jp/blog/automating-with-gitlab-duo-part-2-complex-testing/)と、より複雑な状況でのAIとのインタラクティブな作業について説明します。\n\n## 参照\n\nGitLab Duoを使用してテストを生成する方法は複数あります。他のオプションを以下にご紹介します。\n\n* GitLab UI  \n* [GitLab Web IDE（クラウド内のVS Code）](https://docs.gitlab.com/ee/user/project/web_ide/index.html)  \n* VS Codeと[VS Code用GitLabワークフロー拡張機能](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow)の使用  \n* JetBrains IDEと[JetBrains用GitLab Duoプラグイン](https://plugins.jetbrains.com/plugin/22325-gitlab-duo)の使用 \n* Visual Studio for Windowsと[Visual Studio用GitLab拡張機能](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio)の使用\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[721,676,2378,904,678],"2025-04-02",{"slug":2535,"featured":6,"template":681},"automating-with-gitlab-duo-part-1-generating-tests","content:ja-jp:blog:automating-with-gitlab-duo-part-1-generating-tests.yml","Automating With Gitlab Duo Part 1 Generating Tests","ja-jp/blog/automating-with-gitlab-duo-part-1-generating-tests.yml","ja-jp/blog/automating-with-gitlab-duo-part-1-generating-tests",{"_path":2541,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2542,"content":2547,"config":2553,"_id":2555,"_type":16,"title":2556,"_source":17,"_file":2557,"_stem":2558,"_extension":20},"/ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"title":2543,"description":2544,"ogTitle":2543,"ogDescription":2544,"noIndex":6,"ogImage":1794,"ogUrl":2545,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2545,"schema":2546},"アジャイルプランニングチームに特化したGitLabの新しい「プランナー」ロールのご紹介","GitLabの新しい「プランナー」ロールを活用して、SaaS、GitLab Dedicated、Self-Managedといった各ソリューションでのアクセス権を最適化し、アジャイルチームの計画ワークフローを効率的に管理する方法についてご説明します。","https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"アジャイルプランニングチームに特化したGitLabの新しい「プランナー」ロールのご紹介\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-11-25\",\n      }",{"title":2543,"description":2544,"authors":2548,"heroImage":1794,"date":2549,"body":2550,"category":1705,"tags":2551,"updatedDate":2552},[1702],"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",[1389,904,678,701],"2025-05-01",{"slug":2554,"featured":92,"template":681},"introducing-gitlabs-new-planner-role-for-agile-planning-teams","content:ja-jp:blog:introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","Introducing Gitlabs New Planner Role For Agile Planning Teams","ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"_path":2560,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2561,"content":2567,"config":2573,"_id":2575,"_type":16,"title":2576,"_source":17,"_file":2577,"_stem":2578,"_extension":20},"/ja-jp/blog/gitlab-17-6-release",{"title":2562,"description":2563,"ogTitle":2562,"ogDescription":2563,"noIndex":6,"ogImage":2564,"ogUrl":2565,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2565,"schema":2566},"GitLab 17.6リリース","GitLab 17.6でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662194/Blog/Hero%20Images/product-gl17-blog-release-cover-17-6-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-6-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.6リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-11-21\",\n      }",{"title":2562,"description":2563,"authors":2568,"heroImage":2564,"date":2569,"body":2570,"category":701,"tags":2571,"updatedDate":2572},[738],"2024-11-21","**セルフホストモデルが使用可能になったDuo Chat（ベータ版）を含むGitLab 17.6をリリース**\n\nこのたび、GitLab 17.6のリリースを発表しました。このリリースでは、セルフホストモデルが使用可能になったDuo Chat（ベータ版）、SASTとDASTセキュリティスキャナーの遵守チェック、脆弱性レポートのグループ化、モデルレジストリの一般提供など、さまざまな機能が追加されました！  \n\nこれらの機能は、今回のリリースに含まれる約150件の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 17.6には、GitLabコミュニティのユーザーから265件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。  \n来月のリリースで予定されている内容を先取りするには、17.7リリースのキックオフビデオも視聴できる[今後のリリースページ](https://about.gitlab.com/direction/kickoff/)をご覧ください。\n\n> [GitLab 17.6では、セルフホストモデルが使用可能になったDuo Chatが追加されました。クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+17.6+released+with+self-hosted+Duo+Chat+in+beta&url=https://about.gitlab.com/releases/2024/11/21/gitlab-17-6-released/&hashtags=)\n\n## 今月のMost Valuable Person [MVP](https://about.gitlab.com/community/mvp/)は[Joel Gerber](https://gitlab.com/Jitsusama)さんが受賞\n\nMVPには、誰もが[GitLabコミュニティのコントリビューターを推薦](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)できます。現在の候補者を応援したり、他の誰かをノミネートしてみませんか。🙌  \n\nJoelさんは、CIコンポーネントへの非常に貴重なコントリビューターとしての実績に加え、マージリクエストに関する洞察に富んだフィードバックや複雑なディスカッションに対する思慮深いコメントを寄せたことが評価されました。Joelさんのコントリビュートには、[CI/CDカタログのUIの改良](https://gitlab.com/gitlab-org/gitlab/-/issues/464703)、要望の多かったGitLab Terraform Providerのドキュメントの改善、[ジョブログのタイムスタンプ](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/164595)、[UI/UXチームへのフィードバックの提供](https://gitlab.com/gitlab-org/gitlab/-/issues/482524#note_2089551197)などが挙げられます。  \n\n[HackerOne社](https://www.hackerone.com/)のスタッフソフトウェアエンジニアであるJoelさんのコントリビュートと貴重なフィードバックの提供実績を評価し、推薦したのは、[Lee Tickett](https://gitlab.com/leetickett-gitlab)です。Leeは、GitLabのコントリビューターサクセスチームに所属するスタッフフルスタックエンジニアです。 \n\nLeeに続き、GitLabのシニア製品デザイナーである[Gina Doyle](https://gitlab.com/gdoyle)も、Joelさんを推薦しました。「GitLabでは多くのディスカッションが行われていたため、MRのプロセスが複雑になっていました。そのような状態でも、Joelさんは忍耐強く、そして積極的にディスカッションに参加し続け、コントリビュートしてくれました」とGinaは述べています。  \n\nまた、GitLabのスタッフ製品デザイナーである[Sunjung Park](https://gitlab.com/sunjungp)も次のように述べ、Joelさんの功績を讃えました。「Joelさんは、CI/CDカタログのイシューであったUIの改良にもコントリビュートしてくれました。Joelさんのおかげで、ユーザーインターフェイスが整い、他のエリアとの一貫性も保たれています」  \n\nJoelさんのコントリビュートを始め、GitLabにコントリビュートしてくださっているオープンソースコミュニティのみなさまに心より感謝します！\n\n## GitLab 17.6でリリースされた主な改善点\n\n### セルフホストモデルが使用可能になったGitLab Duo Chat\n\nSaaS: -\n\nSelf-Managed: Ultimate、Duo Enterprise\n\n選択した大規模言語モデル（LLM）を独自のインフラストラクチャでホストし、そのモデルをGitLab Duo Chatのソースとして設定できるようになりました。この機能はベータ版です。UltimateとDuo Enterpriseのサブスクリプションをお持ちであれば、Self-ManagedのGitLab環境でご利用いただけます。\n\nセルフホストモデルを使用すると、オンプレミスまたはプライベートクラウドでホストされたモデルを、GitLab Duo ChatまたはGitLab Duoコード提案（ベータ機能としてGitLab 17.5で導入）のソースとして利用できます。コード提案は現在、vLLMまたはAWS BedrockではオープンソースのMistralモデル、AWS BedrockではClaude 3.5 Sonnet、Azure OpenAIではOpenAIモデルをサポートしています。Duo Chatでは、vLLMまたはAWS BedrockではオープンソースのMistralモデル、AWS BedrockではClaude 3.5 Sonnetをサポートしています。セルフホストモデルを利用することで、エンタープライズレベルのデータ主権とプライバシーを維持しながら、生成AIの力を活用できます。\n\n[イシュー501268](https://gitlab.com/gitlab-org/gitlab/-/issues/501268)から、ぜひフィードバックをお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/self_hosted_models/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/501267)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_6/self-hosted-models-ui-17.6.png\">\n\n### マージリクエストのレビュアーの割り当ての強化\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\n慎重に変更内容を練り上げて、マージリクエストを準備したら、次のステップはプロセスを進めてくれるレビュアーを特定することです。マージリクエストに対し適切なレビュアーを特定するには、承認者として誰が適切であるか、また、提案する変更に関連する分野の専門家（コードオーナー）が誰であるかを見極める必要があります。  \n\nレビュアーを割り当てる際は、サイドバーでマージリクエストの承認要件とレビュアーの関連付けを行います。各承認ルールを閲覧してから、その承認ルールを満たしてマージリクエストを実行できる承認者を選択します。[オプションの「コードオーナー」セクション](https://docs.gitlab.com/ee/user/project/codeowners/#make-a-code-owners-section-optional)を使用する場合は、これらのルールもサイドバーに表示されるため、変更内容に関連する分野を得意とするレビュアーを見つけるのに役立ちます。  \n\nこのレビュアーの割り当ての強化により、GitLabにおけるレビュアーの割り当てプロセスが飛躍的に向上しました。これまではどのレビュアーをアサインすればよいか見極めるのに悩むことがありましたが、過去の判定処理に基づいて強化された本機能でその悩みが解消されます。なお、[今後のレビュアーの割り当てのイテレーション](https://gitlab.com/groups/gitlab-org/-/epics/14808)では、レビュアーの推薦やランク付けを行う際に使用する判定処理を引き続き強化していく予定です。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#request-a-review)\n\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12878)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_6/create-enhanced-reviewer-assignment.png\">\n\n### ワークスペースでのプライベートコンテナレジストリのサポート\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\nGitLabワークスペースで、プライベートコンテナレジストリがサポートされるようになりました。この設定を使用すると、任意のプライベートレジストリからコンテナイメージをプルすることができます。Kubernetesクラスターに有効なイメージプルシークレットがあれば、[GitLabエージェントの設定](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html)からそのシークレットを参照できます。  \n\nこの機能により、特にカスタムコンテナレジストリやサードパーティのコンテナレジストリを使用するチームのワークフローが簡素化されるとともに、コンテナ化された開発環境の柔軟性とセキュリティが向上します。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/workspace/configuration.html#configure-support-for-private-container-registries)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14664)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/yPrJKAwwaB0?si=4PHEC08_xCy2xJ8B\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### ワークスペースで拡張機能マーケットプレースが利用可能に\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\nワークスペースで拡張機能マーケットプレースを利用できるようになりました。拡張機能マーケットプレースでは、サードパーティの拡張機能を検索、インストール、管理できるため、開発体験が向上します。何千種類もの拡張機能から選択して、生産性の向上、ワークフローのカスタマイズを実現できます。  \n\nデフォルトでは、拡張機能マーケットプレースは無効になっています。利用を開始するには、ユーザー環境設定に移動して、[拡張機能マーケットプレースを有効にする](https://docs.gitlab.com/ee/user/profile/preferences.html#integrate-with-the-extension-marketplace)をオンにします。エンタープライズユーザーの場合は、トップレベルグループのオーナーロールを持つユーザーのみが[拡張機能マーケットプレースを有効にする](https://docs.gitlab.com/ee/user/enterprise_user/#enable-the-extension-marketplace-for-the-web-ide-and-workspaces)をオンにできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/web_ide/index.html#extension-marketplace)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12443)  \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_6/extensions-marketplace.png\">\n\n### 終了のタイミングの遅延によるワークスペースライフサイクルの改善に\n\nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\n本リリースでは、設定したタイムアウトが経過すると、ワークスペースが終了する代わりに、停止するようになりました。この機能を使用すると、いつでもワークスペースを再起動して、中断したところから再開できます。  \nデフォルトでは、ワークスペースは自動的に以下のように動作します。\n\n* ワークスペースが最後に起動または再起動されてから36時間後に停止する  \n* ワークスペースが最後に停止してから722時間後に終了する\n\nこれらの設定は、[GitLabエージェントの設定](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html)で行うことができます。  \nこの機能を使用すると、ワークスペースは停止してから1か月間ほど利用可能なままとなり、ワークスペースのリソースを最適化しつつ、進捗を保持できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/workspace/#automatic-workspace-stop-and-termination)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14910)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_6/workspace-suspend.gif\">\n\n### デプロイの詳細ページでのリリースノートの表示\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\n承認するよう求められたデプロイに一体何が含まれているのか、疑問に思ったことはありませんか。これまでのバージョンでは、リリース作成時に内容に関する詳細な説明やテスト手順を含めることはできたものの、関連する環境固有のデプロイに関してはデータが表示されませんでした。今回のリリースで、GitLabでは関連するデプロイの詳細ページにリリースノートが表示されるようになりました。  \n\nGitLabのリリースは必ずGitタグから作成されるため、タグによりトリガーされたパイプラインに関連するデプロイメントにのみ、リリースノートが表示されます。  \nGitLabのこの新機能は、[Anton Kalmykov](https://gitlab.com/antonkalmykov)さんがコントリビュートしてくれました。この場を借りて、Antonさんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#view-blocked-deployments)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/493260)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/deploy-automatically-show-release-notes.png\">\n\n### 管理者設定により、CI/CDジョブトークン許可リストの使用を強制\n\nSaaS: -\n\nSelf-Managed: Free、Premium、Ultimate \n\n以前に、デフォルトのCI/CDジョブトークン（`CI_JOB_TOKEN`）の動作が[GitLab 18.0で変更される予定であり](https://docs.gitlab.com/ee/update/deprecations.html#default-cicd-job-token-ci_job_token-scope-changed)、引き続きプロジェクトにアクセスできるようにしたい場合は、明示的に個々の[プロジェクトやグループをプロジェクトのジョブトークン許可リスト](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)に追加する必要があることを発表しました。  \n\n本バージョンからSelf-ManagedおよびGitLab Dedicatedインスタンスの管理者は、インスタンス上のすべてのプロジェクトに対して、より安全性の高いこの設定を強制できるようになりました。この設定を有効にすると、プロジェクトにおいてCI/CDジョブトークンを認証に使用したい場合、必ず許可リストを使用する必要があります。*注：セキュリティポリシーの強化の一環として、この設定を有効にすることをおすすめします。*\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/496647)  \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_6/allowlist_enforce_instance_toggle.png\">  \n\n### CI/CDジョブトークンによる認証の追跡\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nこれまでは、CI/CDジョブトークンによる認証を利用してご自身のプロジェクトにアクセスしている他のプロジェクトを追跡する機能はありませんでした。今回のリリースで認証ログが追加され、プロジェクトへのアクセスを簡単に監査および管理できるようになりました。  \n\n認証ログでは、ご自身のプロジェクトでジョブトークンによる認証を行った他のプロジェクトのリストをUI上で閲覧できるほか、CSVファイルにしてダウンロードできます。このデータは、プロジェクトへのアクセスの監査に使用できます。また、[ご自身のプロジェクトにアクセスできるオブジェクトヘの制御](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#control-job-token-access-to-your-project)を強化するために、ジョブトークン許可リストを作成する際に参考にできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#job-token-authentication-log)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/467292)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/auth_log_allowlist.png\">\n\n### 脆弱性レポートのグループ化\n\nSaaS: Ultimate\n\nSelf-Managed: Ultimate\n\n脆弱性をグループ別に表示する機能は、ユーザーにとって必須です。セキュリティアナリストは、グループに対して一括操作を適用することで、最適な方法でタスクをトリアージしやすくなります。さらに、ユーザーは自分が担当するグループに一致する脆弱性の数（OWASPトップ10の脆弱性の数など）を閲覧できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#group-vulnerabilities)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/10164)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/vulnerability_report_grouping.png\">\n\n### モデルレジストリの一般提供を開始\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\nGitLabのモデルレジストリの一般提供を開始しました。モデルレジストリは、既存のGitLabワークフローの流れの中で、機械学習モデルを一元的に管理できるハブです。モデルバージョンの追跡、アーティファクトとメタデータの保存に加え、モデルカード内で包括的なドキュメントを保持できます。  \n\nモデルレジストリはシームレスに統合できるように構築されているため、[MLflowクライアント](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/mlflow_client.html)とネイティブに連携可能です。また、CI/CDパイプラインに直接接続し、自動化されたモデルのデプロイとテストを可能にします。データサイエンティストは、直感的なUIまたは既存のMLflowワークフローを介してモデルを管理できます。一方、MLOpsチームも、セマンティックバージョニングとCI/CDインテグレーションを活用して、[GitLab API](https://docs.gitlab.com/ee/api/model_registry.html)内で本番環境のデプロイをすべて効率化できます。  \n\n[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/504458)からお気軽にご意見をお寄せください。こちらから折り返しご連絡いたします。GitLabインスタンスで**「デプロイ」\\>「モデルレジストリ」**の順にアクセスして、ぜひご利用ください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/ml/model_registry/)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14998)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/model-registry-17.6.png\">\n\n### GitLab Dedicated向けの新しいテナントネットワーク設定\n\nSaaS: -\n\nSelf-Managed: Ultimate\n\nGitLab Dedicatedのテナント管理者は、スイッチボードを使ってアウトバウンドプライベートリンクとプライベートホストゾーンを設定できるようになりました。また、スイッチボードで定期的にスナップショットを閲覧して、ネットワーク接続をモニタリングすることも可能です。\n\nアウトバウンドプライベートリンクとプライベートホストゾーンを設定することで、AWSアカウント内のリソースとGitLab Dedicated間でセキュアなネットワーク接続を確立できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/dedicated/configure_instance/network_security.html#outbound-private-link)  \n[イシュー](https://about.gitlab.com/direction/saas-platforms/switchboard/#fy25-q3)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/switchboard-tenant-networking-config.png\">\n\n### SASTとDASTセキュリティスキャナーの新しい遵守チェック\n\nSaaS: Ultimate\n\nSelf-Managed: Ultimate\n\nGitLabは、SAST、シークレット検出、依存関係スキャン、コンテナスキャンなど、幅広いセキュリティスキャナーを提供しており、これらを使用してアプリケーションにセキュリティの脆弱性が潜んでいないかチェックできます。\n何らかの方法で監査担当者や関係するコンプライアンス当局に対し、リポジトリへのセキュリティスキャナーの設定を義務付ける規制基準にアプリケーションが従っていることを示す必要があります。\n\n本リリースでは、こういった規制基準への遵守を証明するために、コンプライアンスセンターの基準遵守レポートに新しいチェックを2つ追加しました。新たに追加されたチェックは、グループ内のプロジェクトでSASTとDASTが有効になっているかどうかを点検します。これらのチェックにより、プロジェクトにおいてSASTとDASTセキュリティスキャナーが正しく実行され、パイプラインの実行により正しいアーティファクトを得られるかどうかを確かめることができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html#gitlab-standard)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12661)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/dast_scanner_adherence.png\">\n\n## GitLab 17.6のリリースに含まれるその他の改善点\n\n### グループWebhookのプロジェクトイベント\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\nこのリリースでは、グループWebhookにプロジェクトイベントが追加されました。次のような場合に、プロジェクトイベントがトリガーされます。\n\n* グループ内にプロジェクトが作成されたとき  \n* グループ内でプロジェクトが削除されたとき\n\nこれらのイベントは、[グループWebhook](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#group-webhooks)に対してのみトリガーされます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#project-events)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/359044)  \n\n### 任意のCI/CDジョブでのPagesサイトのデプロイ\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\nPagesのデプロイジョブに「`pages`」という名前を付ける必要がなくなり、パイプラインをより柔軟に設計できるようになりました。今後は任意のCI/CDジョブで`pages`属性を使用するだけで、Pagesのデプロイをトリガーできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/pages/#user-defined-job-names)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/232505)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/customizable-pages-job-name.png\">\n\n### ユーザーレベルでのGitLab Duo Enterpriseの利用状況メトリクスの取得\n\nSaaS: Ultimate、Duo Enterprise\n\nSelf-Managed: Ultimate、Duo Enterprise\n\nこれまでのリリースでは、GitLab Duo EnterpriseユーザーごとにGitLab Duo Chatおよびコード提案の使用状況データを取得することはできませんでした。それに対する改善として、17.6では、アクティブなGitLab Duo Enterpriseユーザーごとに、コード提案の採用数とDuo Chatとのインタラクションを可視化するGraphQL APIを追加しました。このAPIを使用すると、誰がどのGitLab Duo Enterprise機能をどのくらいの頻度で使用しているかといった情報を、より詳細に把握できます。この改善は、GitLabにおいて[GitLab Duo Enterpriseのより包括的な使用状況データを提供する](https://gitlab.com/groups/gitlab-org/-/epics/15026)という目標に向けた最初のイテレーションです。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/#aiusermetrics)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/483049)  \n\n### GitLab Duoでの企業ネットワークサポート\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\nGitLab Duoプラグインの最新アップデートで、高度なプロキシ認証が導入され、デベロッパーは強固なファイアウォールで守られている企業環境にもスムーズに接続できるようになりました。既存のHTTPプロキシサポートをベースに構築されたこの機能拡張により、認証された接続を確立できるだけでなく、VS CodeとJetBrains IDE内でGitLab Duo機能に安全な方法で中断なくアクセスすることが可能です。\n\nデベロッパーは制限されたネットワーク環境において安全な方法で認証して接続する必要があるため、今回のアップデートは非常に重要と言えるでしょう。これにより、セキュリティを損なうことなく、GitLab Duoの全機能を利用できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/editor_extensions/language_server/#enable-proxy-authentication)  \n[イシュー](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/issues/159)  \n\n### GitLab Runner 17.6\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\n本日、GitLab Runner 17.6もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドのエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。  \n\nバグ修正\n\n* [GitLab Runner 17.5.0で、ポッドが追加できる状態にならない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38260)  \n* [フリートプラグインのインストール時に`exec format error`が発生して、Runnerがクラッシュする](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38247)  \n* [OOMKill 実行時に、cgroup v2が有効であるKubernetes executerポッドがハングする  ](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38244)\n* [設定テンプレートを使用してRunnerを登録すると、Runnerのデフォルトが適用されない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38231)  \n* [execモードを使用している場合、ポーリング期間中にKubernetesポッドが追加可能な状態になるまで、GitLab Runnerが待機状態になる](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37244)  \n* [`FF_GIT_URLS_WITHOUT_TOKENS`機能フラグが有効な場合、認証の問題が発生する](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38268)\n\n[ドキュメント](https://docs.gitlab.com/runner)  \n\n### macOS Sequoia 15およびXcode 16のジョブイメージ\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: -\n\nmacOS Sequoia 15とXcode 16を使用して、最新世代のAppleデバイス向けアプリケーションを作成、テスト、デプロイできるようになりました。  \n\n[macOSにホストされているGitLab Runner](https://docs.gitlab.com/ee/ci/runners/hosted_runners/macos.html)を使用すれば、GitLab CI/CDと統合された安全なオンデマンドのビルド環境で、開発チームがmacOSアプリケーションをより迅速にビルドし、デプロイできます。\n\n`.gitlab-ci.yml`ファイルの`macos-15-xcode-16`イメージを使用して、ぜひお試しください。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/runners/hosted_runners/macos.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/502852)  \n\n### CI/CDジョブの環境でのGitLabエージェントの選択\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\nKubernetes用のダッシュボードを使用するには、環境設定からKubernetesとの接続用エージェントを選択する必要があります。これまでは、UIまたはAPI（GitLab 17.5以降のバージョン）からしかエージェントを選択できなかったため、CI/CDからダッシュボードの設定を行うことはできませんでした。GitLab 17.6では、`environment.kubernetes.agent`構文を使用して、エージェント接続を設定できるようになりました。さらに、[イシュー500164](https://gitlab.com/gitlab-org/gitlab/-/issues/500164)では、CI/CDの設定からネームスペースとFluxリソースを選択できるようにすることを提案しています。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html#configure-a-dashboard-for-a-dynamic-environment)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/467912)  \n\n### APIを介してプロジェクトでシークレットプッシュ保護を有効化\n\nSaaS: Ultimate\n\nSelf-Managed: Ultimate\n\nプログラムからさらに簡単にシークレットプッシュ保護を有効化できるようになりました。次のことを行えるように、アプリケーション設定のREST APIを更新しました。1. Self-Managedインスタンスで本機能を有効化し、プロジェクト単位で有効にする。2. プロジェクトで本機能が有効になっているかどうかを確認する。3. 指定したプロジェクトで本機能を有効にする。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/projects.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/490358)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/490357)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/490359)  \n\n### CycloneDX SBOMに含まれるライセンスデータのサポート\n\nSaaS: Ultimate\n\nSelf-Managed: Ultimate\n\nライセンススキャナーで、[サポートされているパッケージタイプ](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/#supported-languages-and-package-managers)を含む、CycloneDX SBOMに格納されている依存関係のライセンスデータを使用できるようになりました。  \n\nCycloneDX SBOMの`licenses`フィールドが使用可能な場合、ユーザーのSBOMから取得されたライセンスデータが表示されます。SBOMにライセンス情報が含まれていない場合は、引き続きライセンスデータベースからライセンスデータが取得されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscyclonedx)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/415935)  \n\n### 特権関連のアクションの監査イベント\n\nSaaS: -\n\nSelf-Managed: Free、Premium、Ultimate\n\n特権設定に関連する管理者アクションの監査イベントが追加されました。これらの設定が変更されたタイミングを記録することで、監査証跡が残るため、セキュリティを強化できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/audit_event_types.html#groups-and-projects)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/486532)  \n\n### 新しい場所からのサインインを通知するメールに情報を追加\n\nSaaS: -\n\nSelf-Managed: Free、Premium、Ultimate\n\nGitLabは、新しい場所からのサインインが検出された場合、オプションでメールを送信します。これまで、このメールにはIPアドレスしか記載されておらず、場所関連の情報は含まれていませんでした。本リリースから、メールに都市と国の情報も記載されるようになりました。\n\nこの場を借りて、コントリビュートしてくれた[Henry Helm](https://gitlab.com/shangsuru)さんに感謝します！  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/notifications.html#notifications-for-unknown-sign-ins)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/296128)  \n\n### サービスアカウントのバッジ\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\nサービスアカウントに所定のバッジが付き、ユーザーリストで簡単に識別できるようになりました。これまでサービスアカウントに付いていたボットバッジのみでは、グループやプロジェクトアクセストークンと区別するのが困難でしたが、今回のリリースで改善されました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/service_accounts.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/439768)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/govern_serviceaccountbadge.png\">\n\n### シートの割り当て有無によるGitLab Duoユーザーのフィルタリング\n\nSaaS: Premium、Ultimate、GitLab Duo Pro、GitLab Duo Enterprise\n\nSelf-Managed:  Premium、Ultimate、GitLab Duo Pro、GitLab Duo Enterprise\n\nこれまでのバージョンのGitLabでは、GitLab Duoシート割り当てページに表示されるユーザーリストをフィルタリングすることができなかったため、過去にGitLab Duoシートが割り当てられたことがあるユーザーを検索することができませんでした。本リリースから「アサインされたシート = はい」または「アサインされたシート = いいえ」でユーザーリストをフィルタリングして、現在どのユーザーにGitLab Duoシートが割り当てられているのか、または割り当てられていないのかを確認できるようになり、シートの割り当てを簡単に調整できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/subscriptions/subscription-add-ons.html#view-assigned-gitlab-duo-users)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/14683)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/filter-users-by-assigned-duo-seat.png\">\n\n### GitLab Duo Pro向けのAIインパクト分析API\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nSelf-Managed:  Premium、Ultimate、Duo Pro、Duo Enterprise\n\nGitLab Duo Proをご利用の方は、`aiMetrics` GraphQL APIを使ってAIインパクト分析メトリクスにプログラムからアクセスできるようになりました。メトリクスには、割り当て済みのGitLab Duoシート数、Duo Chatのユーザー数、コード提案のユーザー数が含まれます。APIを介して、コード提案に関する詳細情報（表示された回数や採用回数）も取得できます。このデータを参照することで、コード提案の採用率を計算できるほか、GitLab Duo ProユーザーによるDuo Chatとコード提案の導入状況をより明確に把握できます。また、AIインパクト分析メトリクスをバリューストリーム分析やDORAメトリクスと組み合わせれば、Duo Chatやコード提案の導入がチームの生産性にどのような影響を及ぼしているかをより深く理解することができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/#aimetrics)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/498497)  \n\n### 完了したアイテムをビューから簡単に削除できるように\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\n「**クローズ済みアイテムを表示**」の切り替えをオフにすることで、リンクされたアイテムや子アイテムリストの完了したアイテムを非表示にできるようになりました。この機能の追加により、複雑なプロジェクトにおいて視覚的に邪魔な要素を整理できるようになったため、ビューをより自由に制御でき、進行中の作業に集中しやすくなりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/456941)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/easily_remove_closed_items_from_your_view.png\">\n\n### リポジトリX-Rayの自動化\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nSelf-Managed:  Premium、Ultimate、Duo Pro、Duo Enterprise\n\nリポジトリX-Rayは、プロジェクトの依存関係関連の追加のコンテキストを提供することで、コード推奨内容の正確性と関連性を向上させ、GitLab Duoコード提案のコード生成リクエストを強化します。これはコード生成の品質向上につながります。これまでリポジトリX-RayではCIジョブが使用されており、ユーザーが設定や管理を行う必要がありました。  \n本リリースから、新規コミットがプロジェクトのデフォルトブランチにプッシュされると、リポジトリX-Rayによって、リポジトリ内の該当する設定ファイルをスキャンして解析するバックグラウンドジョブが自動的にトリガーされるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/repository_xray.html)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/14100)  \n\n### マージを実行する日時設定が可能に\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\nマージリクエストの中には、特定の日付または時間になるまで、マージの実行を保留する必要があるものもあります。その場合、その日付または時間になったら、マージ権限を持つユーザーを見つけて対応してもらわなければなりません。そのタイミングが勤務時間外だったり、必ずスケジュール通りにマージを実行しなければならなかったりする場合は、事前に誰かにタスクの対応を依頼しておく必要があるでしょう。  \n\n本リリースから、マージリクエストを作成または編集する際に、`merge after`を使用して日付を指定できるようになりました。この方法で日付を指定すると、その日付が過ぎるまでマージリクエストがマージされません。この新機能と以前リリースされた[自動マージの改善機能](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/#auto-merge-when-all-checks-pass)を組み合わせることで、マージリクエストのマージ実行を柔軟にスケジュールできるようになります。  \n\nこの場を借りて、素晴らしいコントリビュートをしてくれた[Niklas van Schrick](https://gitlab.com/Taucher2003)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/merge_requests/auto_merge.html#prevent-merge-before-a-specific-date)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/14380)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/create-scheduled-merge.png\">\n\n### JaCoCoのテストカバレッジの可視化の一般提供を開始\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\nマージリクエストの差分ビューで、JaCoCoのテストカバレッジ結果を直接確認できるようになりました。この可視化により、テストでどの行がカバーされていて、マージ前にどの行を追加でカバーする必要があるかを素早く特定できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization/jacoco.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/227345)  \n\n### `glab agent bootstrap` コマンドで新たに値をサポート\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\n前回のリリースでは、GitLab CLIツールにおけるエージェントの立ち上げを簡単に行える機能を導入しました。GitLab 17.6では、カスタムHelm値に対応し、`glab cluster agent bootstrap`コマンドをさらに改善しました。`--helm-release-values`と`--helm-release-values-from`フラグを使用して、生成された`HelmRelease`リソースをカスタマイズできます。\n\n[ドキュメント](https://gitlab.com/gitlab-org/cli/-/blob/main/docs/source/cluster/agent/bootstrap.md#options)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/482844)  \n\n### EPSSによる効率的なリスクの優先順位付け\n\nSaaS: Ultimate\n\nSelf-Managed: Ultimate\n\nGitLab 17.6では、悪用予測スコアリングシステム（EPSS）のサポートを追加しました。EPSSは各共通脆弱性識別子（CVE）に0～1のスコアを付けて、今後30日以内にそのCVEが悪用される確率を示します。EPSSを活用すれば、スキャン結果の優先順位付けを改善できるほか、脆弱性によって環境に生じうる影響を評価できます。\n\nこのデータは、GraphQLを介してコンポジション解析ユーザーが利用できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/#cveenrichmenttype)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/11544)  \n\n### 除外が適用されたシークレットプッシュ保護の監査イベントを記録\n\nSaaS: Ultimate\n\nSelf-Managed: Ultimate\n\nシークレットプッシュ保護の除外が適用された場合に、監査イベントが記録されるようになりました。これにより、セキュリティチームは、プロジェクトの除外リストに含まれるシークレットのプッシュが許可された場合に発生する出来事をすべて監査し、追跡できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/exclusions.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/492465)  \n\n### グループの保護ブランチの変更を防止\n\nSaaS: Ultimate\n\nSelf-Managed: Ultimate\n\nグループのブランチの変更を禁じるようにマージリクエストの承認ポリシーが設定されている場合、ポリシーにおいてグループに設定された保護ブランチが考慮されるようになりました。この設定が有効な場合、グループレベルで保護されたブランチの保護を解除することはできません。保護ブランチでは、ブランチの削除やブランチへの強制プッシュなど、特定のアクションが制限されます。新たに追加された`approval_settings.block_group_branch_modification`プロパティを使用して、この動作を上書きし、特定のトップレベルグループに対して例外を宣言すれば、グループオーナーが必要に応じて保護ブランチを一時的に変更できるようになります。  \n\nこの新たなプロジェクトの上書き設定により、グループの保護ブランチ設定を変更してセキュリティやコンプライアンス要件を回避することができなくなり、より安定した状態で保護ブランチを使用できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html#approval_settings)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13776)  \n\u003Cimg src=\"https://about.gitlab.com/images/17_6/override-group-branches.png\">\n\n### OTP認証アプリとWebAuthnデバイスを個別に無効化\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\nワンタイムパスワード（OTP）認証アプリとWebAuthnデバイスを個別または同時に無効にできるようになりました。これまではOTP認証アプリを無効にすると、WebAuthnデバイスも無効化されていました。個別に操作できるようになったことで、これらの認証方法をより細かく制御できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#disable-two-factor-authentication)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/393419)  \n\n### マージリクエストのマージ時の新しい監査イベント\n\nSaaS: Ultimate\n\nSelf-Managed: Ultimate\n\n本リリースでは、マージリクエストのマージ時に`merge_request_merged`という新しいタイプの監査イベントがトリガーされるようになりました。この監査イベントには、次のようなマージリクエストに関する重要な情報が含まれます。\n\n* マージリクエストのタイトル  \n* マージリクエストの説明またはサマリー  \n* マージに必要な承認数  \n* マージに付与された承認数  \n* マージリクエストを承認したユーザー  \n* コミッターによるマージリクエストの承認有無  \n* 作成者によるマージリクエストの承認有無  \n* マージの日付や時刻  \n* コミット履歴から取得したSHAリスト\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/audit_event_types.html#compliance-management)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/442279)  \n\n### トップレベルグループのオーナーがサービスアカウントを作成できるように\n\nSaaS: -\n\nSelf-Managed: Premium、Ultimate\n\n現在、GitLab Self-Managedでサービスアカウントを作成できるのは管理者のみです。本リリースでは、トップレベルグループのオーナーに対してサービスアカウントの作成を許可するオプション設定が追加されました。これにより、管理者はロールの範囲を広げてサービスアカウントの作成を許可するか、管理者のみが許可されたタスクのままとするかを選択できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#allow-top-level-group-owners-to-create-service-accounts)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/468806)  \n\n### APIの使用によるトークン関連情報の取得\n\nSaaS: -\n\nSelf-Managed: Free、Premium、Ultimate\n\n管理者は、新しいトークン情報のAPIを使用して、パーソナルアクセストークンに関する情報の取得、トークンのデプロイ、トークンへの入力を行えます。トークン情報が公開される他のAPIエンドポイントとは異なり、このエンドポイントを使用した場合、管理者はトークンの種類を知らなくてもトークン情報を取得できます。  \n\nこの場を借りて、コントリビュートしてくれた[Nicholas Wittstruck](https://gitlab.com/nwittstruck)さんを始め、シーメンス社の皆さまに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/api/admin/token.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/443597)  \n\n### GitLab Duoシートの割り当てに関する通知メールのアップデート\n\nSaaS: -\n\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nSelf-Managedインスタンスの全ユーザーに対して、GitLab Duoシートが割り当てられたタイミングでメールが送信されるようになりました。  \n\nこれまでは、GitLab Duo Enterpriseシートが割り当てられたユーザーや、一括割り当てによってアクセスを許可されたユーザーには通知メールは送信されませんでした。そのため、ほかのユーザーに教えてもらうか、GitLab UIで新しい機能に気付かない限り、自分にシートが割り当てられていることを知ることはできませんでした。  \n\n管理者は`duo_seat_assignment_email_for_sm`という名前の機能フラグを無効にすることで、このメール通知を無効化できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/subscriptions/subscription-add-ons.html#assign-gitlab-duo-seats)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170507)  \n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。  \n17.6で提供されたすべてのバグ修正、パフォーマンスの改善、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=17.6)  \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=17.6)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.6)\n\n## 非推奨事項\n\n削除されたすべての機能の一覧は、[GitLabのドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n- [GitLab chart use of NGINX controller image v1.3.1](https://docs.gitlab.com/ee/update/deprecations.html#gitlab-chart-use-of-nginx-controller-image-v131)\n- [Removal of `migrationState` field in `ContainerRepository` GraphQL API](https://docs.gitlab.com/ee/update/deprecations.html#removal-of-migrationstate-field-in-containerrepository-graphql-api)\n- [Guest users can pull packages from private projects on GitLab.com](https://docs.gitlab.com/ee/update/deprecations.html#guest-users-can-pull-packages-from-private-projects-on-gitlabcom)\n- [Deprecate CI job implementation of Repository X-Ray](https://docs.gitlab.com/ee/update/deprecations.html#deprecate-ci-job-implementation-of-repository-x-ray)\n- [Pipeline subscriptions](https://docs.gitlab.com/ee/update/deprecations.html#pipeline-subscriptions)\n- [Pipelines API cancel endpoint returns error for non-cancelable pipelines](https://docs.gitlab.com/ee/update/deprecations.html#pipelines-api-cancel-endpoint-returns-error-for-non-cancelable-pipelines)\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabのドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n### **変更履歴**\n\n変更内容をすべて表示するには、以下のページから変更履歴を確認してください。\n\n* [GitLab](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/CHANGELOG.md)   \n* [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/CHANGELOG.md)   \n* [VS CodeのGitLabワークフロー](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  個人ユーザー向けの永久無料機能を提供\n\n* [Premiumプラン](https://about.gitlab.com/pricing/premium/) \n\n  チームの生産性と調整を強化\n\n* [Ultimateプラン](https://about.gitlab.com/pricing/ultimate/) \n\n  組織全体のセキュリティ、コンプライアンス、プランニングに対応\n\n> GitLabのすべての機能を[無料](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)でお試しいただけます。\n\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)* \u003Cbr>\n*（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n\n### 過去の日本語リリース情報\n\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],"2025-02-18",{"slug":2574,"featured":92,"template":681},"gitlab-17-6-release","content:ja-jp:blog:gitlab-17-6-release.yml","Gitlab 17 6 Release","ja-jp/blog/gitlab-17-6-release.yml","ja-jp/blog/gitlab-17-6-release",{"_path":2580,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2581,"content":2587,"config":2593,"_id":2595,"_type":16,"title":2596,"_source":17,"_file":2597,"_stem":2598,"_extension":20},"/ja-jp/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":2582,"description":2583,"ogTitle":2582,"ogDescription":2583,"noIndex":6,"ogImage":2584,"ogUrl":2585,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2585,"schema":2586},"データドリブンのDevSecOps：GitLabインサイトダッシュボードのご紹介","主要なメトリクスの可視化、プロジェクトの進捗状況の追跡、カスタマイズ可能なデータドリブンビューを使ったチームの生産性の改善など、GitLabインサイトダッシュボードの活用方法について説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097210/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097210214.png","https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"データドリブンのDevSecOps：GitLabインサイトダッシュボードのご紹介\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ricardo Amarilla Villalba\"}],\n        \"datePublished\": \"2024-11-20\",\n      }",{"title":2582,"description":2583,"authors":2588,"heroImage":2584,"date":2590,"body":2591,"category":701,"tags":2592},[2589],"Ricardo Amarilla Villalba","2024-11-20","メトリクスおよび分析は、生産性や品質を高め、成功を収める上で極めて重要な要素です。包括的なDevSecOpsプラットフォームであるGitLabでは、こういった重要なメトリクスを追跡・可視化するための強力なツールをインサイトダッシュボード上で提供しています。この記事では、ご利用の環境でのインサイトダッシュボードの使用方法についてご紹介します。\n\n\n## GitLabのメトリクスと分析ツールのご紹介 \n\n\nGitLabでは、DevSecOpsライフサイクルのさまざまな側面に対応したメトリクスおよび分析ツール群をご用意しています。\n\n\n1.\n[生産性分析](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html)：チームの開発速度、サイクルタイム、リードタイムを追跡します。  \n\n2.\n[コードレビュー分析](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html)：コード品質、テストカバレッジ、レビュー効率を測定します。  \n\n3.\n[CI/CD分析](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html)：パイプラインのパフォーマンスとデプロイ頻度をモニタリングします。  \n\n4.\n[バリューストリーム分析](https://docs.gitlab.com/ee/user/group/value_stream_analytics/)：アイデア出しから本番稼働までの作業の流れを可視化します。  \n\n5.\n[インサイト](https://docs.gitlab.com/ee/user/project/insights/)：プロジェクトやグループに関するデータを調べて可視化します。\n\n\n開発プロセスに関する貴重なインサイトを得られるこれらのメトリクスを参考にして、ボトルネックの特定、ワークフローの最適化、データドリブンな意思決定を行えます。\n\n\n## 特定のメトリクスへのラベルの活用\n\n\nあまり目立たないものの、GitLabの特に強力な機能の1つがラベルです。ラベルを使うと、特定のメトリクスに絞り込んで、極めて正確に焦点を当てられます。イシューやマージリクエスト、エピックに戦略的にラベルを適用することで、プロジェクトのパフォーマンスや進捗について的確なインサイトを得られるカスタムビューを作成できます。\n\n\n用途の広い識別子として機能するGitLabのラベルを使用すれば、作業アイテムを柔軟に分類・整理できます。機能開発やバグ修正、チーム固有のタスクなど、追跡対象が何であれ、ラベルを使用すれば、プロジェクトデータをスライスして、別の視点から分析して意味のあるパターンや傾向を特定することが可能です。この概念は、クラウドのデプロイにおいて、管理やコスト配分、運用上のインサイト取得をスムーズに行うためにタグを使用するのと似ています。\n\n\nしっかりと考えながら作業アイテムにラベルを付けていくことで、カスタムダッシュボードやレポートの生成に活用できる高度なラベリングシステムが実質的に構築されます。このアプローチにより、チームや関係者にとって最も重要なメトリクスを重点的に取り上げられるとともに、プロジェクトの健全性と勢いに焦点を絞ってわかりやすく可視化できます。\n\n\n## GitLabインサイトの設定方法\n\n\nGitLabインサイトを使用すると、プロジェクトやグループに関するデータを調べて可視化できます。特定の期間内に作成された、または完了したイシュー、マージリクエストのマージが完了するまでの平均時間、トリアージの健全性など、さまざまな側面に関する有用な分析情報を得られます。インサイトは、プロジェクトとグループのどちらにも設定できます。\n\n\nインサイトの設定手順は次のとおりです。\n\n\n1. プロジェクトにインサイトを設定する場合：  \n   * プロジェクトのルートディレクトリ内に`.gitlab/insights.yml`という名前のファイルを作成します。  \n2. グループにインサイトを設定する場合：  \n   * グループに属するプロジェクト内に`.gitlab/insights.yml`ファイルを作成します。  \n   * グループの**設定 > 一般**の順に移動します。\n   * **分析セクション**を展開し、**インサイトセクション**を見つけます。  \n   * 設定ファイルが含まれるプロジェクトを選択し、変更を保存します。\n\n`.gitlab/insights.yml`は、レポート内のチャートの構造や順序に加え、表示されるチャートの形式を定義できるYAMLファイルです。各チャートの定義には、タイトル、説明、タイプ、データソースやフィルタリング条件を指定するクエリなどのパラメータを含められます。\n\n\nインサイトを表示するには、プロジェクトまたはグループで**分析 > インサイト**の順に移動します。\n\n\n![デフォルトのインサイトダッシュボードの表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097217972.png)\n\n\n## マージリクエストインサイトのカスタマイズ\n\n\nデフォルトビューでは有用な情報が未加工で表示されますが、インサイトダッシュボードをカスタマイズすれば、各マージリクエストの担当チームや、マージリクエストごとに解決された問題の種類など、より多くの情報が明らかになります。\n\n\n## スクワッドおよび要件タイプごとのマージリクエストインサイト\n\n\nGitLabでスクワッドの生産性を測定するのは、難しい場合があります。GitLabのグループとサブグループの構造が、実際のスクワッドの構成と完全に一致していない場合は特に困難です。こういった課題に対処し、効果的にスクワッドの生産性を追跡する方法をご紹介します。\n\n\n### **スクワッドベースのメトリクスの設定**\n\n\n1.\n**ラベルの作成**：スクワッドごと（例：`squad::alpha`、`squad::beta`）および要件タイプ（例：`type::bug`、`type::feature`、`type::maintenance`）ごとに範囲指定した一意のラベルを作成します。\n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZUOzORIUJeU?si=T8eHeGizS3blYFHB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n\n2.\n**ラベルの適用**：所属するプロジェクトやグループに関係なく、各スクワッドが対応するすべてのイシューおよびマージリクエストにこれらのスクワッドラベルを一貫して適用します。  \n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fJ9entEBZG8?si=MlM6mKirEdkmwDDJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n\n**ヒント**：  \n   * GitLab APIを使用すれば、既存のMR（未解決、マージ済み、完了したもの）に一括でラベルを適用できます。  \n   * GitLab CIパイプラインの一環としてラベルの追加や削除、更新を行えます。  \n   * GitLabトリアージボットを活用すれば、ラベルの適用プロセスを自動化できます。  \n\n3.\nダッシュボードの設定：プロジェクトのリポジトリに`.gitlab/insights.yml`ファイルを作成し、チームやタイプ固有のマージリクエストインサイト用のカスタムチャートを定義します。\n\n\n```\n\n\n## Default Merge Requests insights.yml \n\nmergeRequests:\n  title: Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week \n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month\n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n\n## Per-teams Merge Requests insights.yml\n\nmergeRequestsTeams:\n  title: Merge requests dashboard per teams\n  charts:\n    - title: Merge requests merged per week \n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n    - title: Merge requests merged per month\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n\n## Per-teams and Type Merge Requests insights.yml\n\nmergeRequestsTeamsAndType:\n  title: Per Teams and Type - Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n    - title: Merge requests merged per week - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n\n```\n\n\nこのようにカスタマイズすることで、チームおよび要件タイプごとのマージリクエストアクティビティがわかりやく表示される、役に立つ情報満載のダッシュボードを作成できます。それをもとに、長期的なトレンドの可視化、各スクワッドのパフォーマンスの比較、スクワット単位での作業タイプの分布の分析を行えます。\n\n\n![チームおよび要件タイプごとにMRアクティビティが表示されているダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097217972.png)\n\n\n![各スクワッドのパフォーマンスが比較されているダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097217974.png)\n\n\n## 無料トライアルで今すぐスタート！\n\n\nGitLabには、GitLabインサイト以外にも、メトリクスおよび分析関連のツールや機能が多数あります。ぜひ以下のバリューストリーム管理製品ツアーで、バリューストリーム分析やCI/CD分析、コードレビューメトリクスなど、GitLabの強力な分析機能の全容をご確認ください。\n\n\n[![バリューストリーム管理製品ツアー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-11-20_at_12.28.08_PM_aHR0cHM6_1750097217976.png)](https://gitlab.navattic.com/vsm)\n\n\n> カスタムメトリクスの作成を始める準備ができたら、[今すぐGitLab\nUltimateの無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F)にご登録ください。データドリブンのDevSecOpsを最大限に活用しましょう。\n\n\n## 関連リンク\n\n-\n[スケジュール設定できるレポート生成ツールでバリューストリーム管理を簡単に実施](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n\n-\n[新たなGitLabバリューストリームダッシュボードを使い始める](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n\n-\n[AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n",[110,904,701,678,676,2058],{"slug":2594,"featured":92,"template":681},"data-driven-devsecops-exploring-gitlab-insights-dashboards","content:ja-jp:blog:data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","Data Driven Devsecops Exploring Gitlab Insights Dashboards","ja-jp/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","ja-jp/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"_path":2600,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2601,"content":2607,"config":2613,"_id":2615,"_type":16,"title":2616,"_source":17,"_file":2617,"_stem":2618,"_extension":20},"/ja-jp/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"title":2602,"description":2603,"ogTitle":2602,"ogDescription":2603,"noIndex":6,"ogImage":2604,"ogUrl":2605,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2605,"schema":2606},"GitLab Ultimateの総経済効果：3年間でROIが483%","Forrester Consulting社によるGitLab Ultimateに関する調査では、DevSecOpsプラットフォームがセキュリティ関連の作業時間を5分の1に短縮し、セキュリティ対策を強化したことが示されています。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","https://about.gitlab.com/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Ultimateの総経済効果：3年間でROIが483%\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-11-13\",\n      }",{"title":2602,"description":2603,"authors":2608,"heroImage":2604,"date":2609,"body":2610,"category":700,"tags":2611,"updatedDate":2612},[1327],"2024-11-13","強力なDevSecOpsプラットフォームであるGitLabは、運用の効率化、セキュリティの脆弱性によるビジネスの混乱（およびコスト発生）の防止、生産性の向上、革新とコラボレーションの文化の醸成を可能にします。当社がGitLabを開発したのはまさにそのためであり、Ultimateプランはプラットフォームのすべての機能が搭載されています。実際の成果を確認すべく、Forrester Consulting社に『Total Economic Impact™ of GitLab Ultimate（GitLab Ultimateの総経済効果）』調査の実施を依頼しました。その結果の概要を以下にご紹介します。\n\nこの調査では、顧客へのヒアリング結果を基にして想定された複合企業モデルにおいて、GitLabが次のような成果をもたらしたことが確認されました。\n\n* **3年間でROIが483%**\n* **デベロッパーの生産性が400%向上**\n* **初回リリースまでの時間が15分の1に短縮\u003Csup>1\u003C/sup>**\n* **セキュリティ関連の作業時間が5分の1に短縮**\n\n**全体として、GitLabによってビジネス価値に直結する作業を50%増加させることができます。**\n\n上記の数字は、GitLabのプラットフォームがチームの働き方をいかに変革できるかを明確に示しています。セキュリティ対策の強化を担うアプリケーションセキュリティ担当者、高品質なコードをより迅速に提供したいデベロッパー、または拡張性・安全性・柔軟性に優れたDevSecOpsプラットフォームをお探しのCTOの方、どの役割の方にとっても、GitLab Ultimateがそれぞれのニーズに応えることをこの調査（詳しい調査方法は下記を参照）は示しています。それでは、調査結果を詳しく見ていきましょう。\n\n> [2024年Forrester Consulting社『Total Economic Impact™ of GitLab Ultimate（GitLab Ultimateの総経済効果）』調査レポート](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/)（英語、全文）をダウンロードできます。\n\n## **1. 3年間でROIが483%**\n\n*「我々が得た大きなメリットが、管理面と全体的な運用における効率性の向上です。今では、全員が協力して作業できるようになり、パイプラインの自動化も簡単に行えるようになりました。また、スタッフを柔軟に配置し、さまざまなタスクをより効率的に完了させることが可能になりました。以前はプログラムごとに異なるツールのトレーニングが必要でしたが、今ではGitLabの使い方さえ覚えればすぐに作業を開始できます」* - 防衛産業、CTO兼シニアバイスプレジデント\n\nこの調査では、主に効率性の向上により、GitLab Ultimateを導入してからわずか6か月で投資回収が始まったことが明らかになりました。**3年間で483%のROI**を達成した組織では、ソフトウェアツールチェーンのコストを25%削減し、ITチームが複雑なツールチェーンの管理時間を75%短縮しました。コスト削減だけでなく、統合プラットフォームへの移行により、チームにおけるソフトウェアの開発とデリバリーのプロセスが根本的に改善されました。\n\n## **2. 生産性が400%向上**\n\n*「GitLabについてデベロッパーたちと話すと、全員が口を揃えて、チームや役割を超えて組織全体の生産性が向上したと感じていると言います。このひとつのプラットフォームには、全員が活用できる機能が備わっています」* - エネルギー・研究業界、ソフトウェアアーキテクト\n\nデベロッパーが能力を発揮するには、作業を中断することなくタスクを簡単に切り替えられる環境が必要です。調査によると、GitLabの[テストの自動化機能](https://about.gitlab.com/ja-jp/topics/devops/devops-test-automation/)を活用することで、デベロッパーは年間最大305時間を創出できることがわかりました。この機能により、テストの頻度を上げ、バグを迅速に追跡して修正できるようになります。これらすべてが単一のインターフェース内で行えるため、複数タスクの並行による頭の切り替えも不要です。この効率化されたワークフローにより、デベロッパーは複数のツールやプロセスを扱う必要がなくなり、コーディングに集中できます。\n\n生産性向上の効果はオンボーディングにも及びます。調査対象となった複合企業のソフトウェア開発チームでは、新入社員が即戦力化するまでの期間が75%短縮されました（1.5か月から1.5週間に短縮）。この結果は、チーム全員がより早く意義のある作業に取り組めるようになるという効果を明確に示しています。\n\n## **3. 初回リリースまでの時間が15分の1に短縮**\n\n*「私たちの強みはソフトウェアにあり、そのパフォーマンスは、開発速度に加え、新機能を迅速に顧客に届ける能力で測られます。この目標を最優先するためにも、単一プラットフォームに各種機能を『統合する』ことが経済的に最も優れた選択肢でした」* - 防衛産業、CTO兼シニアバイスプレジデント\n\n質問に対する顧客の回答から得られたデータによると、GitLabを活用することで、組織は本番環境への初回リリースを従来の15倍の速度で実現できることが明らかになりました。この向上は、プロジェクトの迅速な立ち上げ、より頻繁なソフトウェアリリース、そして開発プロセスの初期段階からセキュリティスキャンをネイティブに統合するという積極的なセキュリティアプローチによって実現されています。開発速度が向上しても、ソフトウェアの品質やセキュリティは高い水準を維持しています。これは、デベロッパーが早期かつ迅速に問題を修正できるようになったおかげです。\n\n[セキュリティが開発プロセスに直接組み込まれている](https://about.gitlab.com/ja-jp/solutions/security-compliance/)ことで、デベロッパーは作業の流れを中断することなく、脆弱性を特定し、優先順位を付け、修正できます。このように、ソフトウェア開発ライフサイクル全体を統合的に管理するアプローチにより、チームはセキュリティを損なうことなく、より迅速に作業を進められます。\n\n## **4. セキュリティ関連の作業時間が5分の1に短縮**\n\n*「セキュリティスキャンと品質スキャンをパイプラインに統合したことで、私たちの業務は大きく変わりました。自動化が進み手作業が減ったことで、失敗や問題が少なくなり、作業の進捗スピードも向上しました」* - 金融業界、プログラムマネージャー\n\n開発速度が上がる一方で脅威も進化し続ける中、セキュリティはすべての組織にとって最重要課題です。GitLabを使用する複合企業では、ディザスタリカバリの準備、監査、コンプライアンスチェックといった反復的なタスクを自動化することで、セキュリティチームの**メンバー1人あたり年間78時間**を節約しています。また、GitLabはソフトウェア開発プロセスの可視性を高め、セキュリティチームと開発チームがより効率的に連携できるよう支援します。\n\n複合企業のサイバーセキュリティチームとソフトウェア開発チームは、**ソフトウェア開発ライフサイクル全体を通じて、セキュリティリスクの管理・軽減にかかる工数を81%削減**できました。これは、GitLabによってセキュリティプロトコルやスキャンをソフトウェア開発ライフサイクルのすべての段階に統合し、厳格なセキュリティ基準を維持するプロセスが簡素化されたためです。セキュリティテストや問題修正がパイプラインに組み込まれているおかげで、チームは平均対応時間を短縮し、問題が本番環境に到達するリスクを軽減できます。\n\n# **DevSecOpsを実際に試す**\n\n483%のROI達成や短期間での投資回収といった実績に加え、数多くの成功事例を持つGitLabは、ソフトウェア開発プロセスの変革を目指すエンタープライズにとって欠かせないツールです。\n\n> GitLabの活用によって貴社にどのようなメリットがもたらされるかについては、[Forrester Consulting社『Total Economic Impact™ of GitLab Ultimate（GitLab Ultimateの総経済効果）』調査レポート](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/)（英語、全文）をダウンロードしてご確認ください。\n\n**調査方法**\n*この調査では、Forrester社が金融、防衛、研究などさまざまな業界のGitLab Ultimateユーザー4社にインタビューを行い、その結果を集約して複合企業モデルを作成しました。この複合企業は、3年間ですべてのチームにGitLab Ultimateを導入することを想定しています。*\n\n*ここの複合企業は、売上高50億ドル、従業員5,000人の企業で、40％がソフトウェアの提供に関与し、年間売上の50％がソフトウェア開発によって生み出されています。彼らの目標は、複数のツールを統合して1つのプラットフォームにまとめ、デベロッパーの生産性を向上させ、業界規制や内部ポリシーの遵守を確保し、開発ライフサイクル全体でセキュリティを強化することです。*\n\n*1. 顧客インタビューの要約データに基づいています。複合企業の結果には適用されません。*",[904,1330,700,722],"2024-11-26",{"slug":2614,"featured":92,"template":681},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years","content:ja-jp:blog:gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","Gitlab Ultimates Total Economic Impact 483 Roi Over 3 Years","ja-jp/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","ja-jp/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"_path":2620,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2621,"content":2627,"config":2632,"_id":2634,"_type":16,"title":2635,"_source":17,"_file":2636,"_stem":2637,"_extension":20},"/ja-jp/blog/partner-cloud-ace",{"title":2622,"description":2623,"ogTitle":2622,"ogDescription":2623,"noIndex":6,"ogImage":2624,"ogUrl":2625,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2625,"schema":2626},"Cloud Source RepositoriesからGitLabへの移行で開発の未来を掴もう：Google CloudのCloud Workstations + GitLab","この記事では、Google CloudのCloud Source RepositoriesのソースコードリポジトリからGitLabへの移行と、Cloud Workstationsの導入がもたらす価値を詳しく解説し、次のステップへの道筋を提示します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665703/Blog/Hero%20Images/AdobeStock_617141001_Editorial_Use_Only.jpg","https://about.gitlab.com/blog/partner-cloud-ace","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Cloud Source RepositoriesからGitLabへの移行で開発の未来を掴もう：Google CloudのCloud Workstations + GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"}],\n        \"datePublished\": \"2024-10-31\",\n      }",{"title":2622,"description":2623,"authors":2628,"heroImage":2624,"date":2629,"body":2630,"category":700,"tags":2631},[1385],"2024-10-31","[Google Cloudの**Cloud Source Repositories**の縮小により、ユーザーは新たな開発環境への移行を迫られています](https://about.gitlab.com/ja-jp/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab/)。しかし、これは単なるツールの変更ではなく、開発プロセス全体を見直し、次世代のプラットフォームへ進化するチャンスです。**GitLab**は、ソースコード管理から[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)、セキュリティ統合までを一貫してサポートする強力なプラットフォームとして、多くの企業から移行先として選ばれています。\n\nさらに、**Cloud Workstations**との組み合わせは、開発者にとってこれまでにない快適で生産性の高い開発環境を提供します。そして、その移行と運用を支えるのが、Google CloudとGitLabの専門知識を兼ね備えた**クラウドエース株式会社**です。本記事では、GitLabへの移行とCloud Workstationsの導入がもたらす価値を詳しく解説し、次のステップへの道筋を提示します。\n\n### **1\\. Cloud Source Repositoriesの縮小がもたらす影響**\n\nCloud Source Repositoriesのサービス縮小に伴い、多くの開発チームが移行を検討しています。これまでの開発プロジェクトや[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインの維持が必要ですが、選択する移行先によって、今後の開発体験が大きく左右されます。\n\n* **既存のプロジェクトとデータの移行**：すべてのリポジトリや開発履歴を失うことなく、安全に新しいプラットフォームへ移行する必要があります。  \n* **[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインの継続運用**：新しいツール上で自動化を再構築し、開発の停滞を防ぐことが求められます。  \n* **セキュリティと運用管理の向上**：新たなプラットフォームでの運用を、より安全で効率的なものにすることが重要です。\n\nこの課題に対し、**GitLab**が提供する高度な機能は、理想的な解決策となります。\n\n### **2\\. なぜGitLabが理想的な移行先なのか**\n\n#### **オールインワンプラットフォーム**\n\nGitLabは、**ソースコード管理、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)の自動化、セキュリティ（[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)）を一つのプラットフォーム上で統合して提供します。これにより、分散したチームでも円滑に開発を進められ、生産性の向上と運用コストの削減**が期待できます。\n\n#### **シームレスな移行**\n\nGitLabは、**GitHub、Bitbucket、Cloud Source Repositories**からの移行ツールを提供しており、リポジトリのデータとプロジェクト管理を安全に移行できます。さらに、GitLabの自動化機能を活用することで、**[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインの再構築**もスムーズに行えます。\n\n#### **Google Cloudとの統合とクラウドネイティブ開発**\n\nGitLabは、**Google Cloud** **Kubernetes（GKE）やCloud Run**を活用し、コンテナベースの開発を効率化します。Google Cloudとの密接な連携により、クラウドネイティブな環境を活用した開発が可能です。\n\n### **3\\. 次世代の開発環境：Google CloudのCloud Workstations \\+ GitLab**\n\n移行後にお勧めしたいのが、**Cloud Workstations**とGitLabの組み合わせです。Cloud Workstationsは、完全管理型のクラウド開発環境を提供し、どこからでも快適に開発が行えます。\n\n#### **Cloud Workstationsの特徴**\n\n* **VS CodeやJetBrains IDE**をリモートで利用し、開発者が慣れ親しんだツールで作業を続けられます。  \n* **IAM（Identity and Access Management）** による厳格なアクセス管理で、セキュリティと権限管理を統合。  \n* **GKEとの連携**により、開発したアプリケーションの迅速なデプロイが可能です。\n\n#### **具体的なワークフロー**\n\n1. **Cloud Workstations**で開発者がコードを作成し、GitLabにプッシュします。  \n2. **GitLabのCI/CDパイプライン**が自動でテストを実行し、GKE上にデプロイします。  \n3. 開発から運用までのプロセスが自動化され、**迅速なフィードバックループ**が実現します。\n\n### **4\\. クラウドエース株式会社によるスムーズな移行と運用サポート**\n\n**クラウドエース株式会社**は、Google CloudとGitLabの両方に精通したパートナーであり、日本国内の企業向けに多くの移行プロジェクトを支援しています。クラウドエース株式会社の支援を受けることで、**移行プロセスの負担を最小限**に抑え、最適な環境を構築できます。\n\n#### **クラウドエース株式会社の技術サポートのポイント**\n\n* **TerraformやGoogle Cloud Deployment Manager**による自動化された環境構築。  \n* **セキュリティとコンプライアンス**を考慮したGitLabの運用支援。  \n* **継続的なサポート**により、バージョンアップや環境改善もスムーズに行えます。\n\n### **5\\. 次のステップ：新しい開発環境への第一歩を踏み出そう！**\n\nCloud Source RepositoriesからGitLabへの移行は、**次世代の開発環境への進化**を意味します。GitLabの強力な機能に加え、Google CloudのCloud Workstationsとの組み合わせは、開発者にとって最適なデベロッパーエクスペリエンスを提供します。\n\n* **[今すぐGitLabのトライアルを申し込む](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fja-jp%2Fblog%2F2024%2F08%2F28%2Ftutorial-migrate-from-google-cloud-source-repositories-to-gitlab%2F)**  \n* **[クラウドエース株式会社経由での無料相談を申し込む](https://cloud-ace.jp/contact/?ref=top_header)**\n\n### **6\\. まとめ：未来の開発スタイルを体験しよう**\n\nCloud Source Repositoriesの縮小により、新しい環境への移行が不可避となっています。しかし、これは新たな可能性を開くチャンスです。**GitLabとGoogle CloudのCloud Workstations**の組み合わせにより、開発者は柔軟で安全な環境の中で、より高速にプロジェクトを推進できるようになります。\n\n**クラウドエース株式会社の支援**を受けることで、移行の不安を解消し、次世代の開発スタイルをいち早く体験しましょう。新しい開発環境で、これまでにない生産性と快適さを手に入れてください。\n\n---\n\n**Google CloudのCloud Workstations \\+ GitLabで、未来の開発を今すぐ始めましょう！**\n",[285,1114],{"slug":2633,"featured":92,"template":681},"partner-cloud-ace","content:ja-jp:blog:partner-cloud-ace.yml","Partner Cloud Ace","ja-jp/blog/partner-cloud-ace.yml","ja-jp/blog/partner-cloud-ace",{"_path":2639,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2640,"content":2646,"config":2651,"_id":2653,"_type":16,"title":2654,"_source":17,"_file":2655,"_stem":2656,"_extension":20},"/ja-jp/blog/partner-classmethod",{"title":2641,"description":2642,"ogTitle":2641,"ogDescription":2642,"noIndex":6,"ogImage":2643,"ogUrl":2644,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2644,"schema":2645},"AWS CodeCommitからGitLabへの移行：課題、メリットと支援体制","AWSは、CodeCommitの新規受付終了に加え、機能の追加を停止しました。この記事では、CodeCommitユーザーが直面する課題と、GitLabへの移行がこれらの課題をどのように解決するかを具体的に紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665715/Blog/Hero%20Images/AdobeStock_542295701_Editorial_Use_Only.jpg","https://about.gitlab.com/blog/partner-classmethod","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AWS CodeCommitからGitLabへの移行：課題、メリットと支援体制\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"}],\n        \"datePublished\": \"2024-10-30\",\n      }",{"title":2641,"description":2642,"authors":2647,"heroImage":2643,"date":2648,"body":2649,"category":700,"tags":2650},[1385],"2024-10-30","AWSの発表により、CodeCommitが新規ユーザーを受け入れなくなり、今後の機能追加も予定されないことが明らかになりました。この方針は、多くの企業にとって**ソースコード管理の運用責任を自社で担う必要がある**という意味を持ち、開発環境の見直しが求められています。\n\nこの記事では、CodeCommitユーザーが直面する課題と、**GitLabへの移行がこれらの課題をどのように解決するか**を具体的に紹介します。また、GitLabの日本国内の強力なパートナーである**クラスメソッド社の移行支援**を活用することで、スムーズな運用が実現できることを解説します。\n\n## **1\\. AWS CodeCommitユーザーの課題**\n\n### **1-1. AWSの方針転換と運用責任の移行**\n\nAWSは、CodeCommitの新規受付終了に加え、機能の追加を停止しました。これにより、AWSの顧客は**自社でソースコード管理の運用と保守**を担う必要があります。\n\n* **運用経験不足への不安:** AWSインフラに依存していた企業では、ソースコード管理のノウハウが不足している場合があります。  \n* **分散ツールの複雑さ:** CodePipelineやCodeBuildなどのAWSツールは引き続き利用可能ですが、これらを組み合わせて効果的に運用するには、開発チームに新たなスキルと労力が求められます。\n\nこのような背景から、AWS環境に依存しない一貫したソースコード管理プラットフォームへの移行が検討されています。\n\n## **2\\. GitLabの特長とAWS環境とのシームレスな統合**\n\n__GitLabは、単なるリポジトリ管理ツールを超えたエンドツーエンドの[DevOpsプラットフォーム](https://about.gitlab.com/ja-jp/topics/devops/)__ であり、CodeCommitに対する最適な代替手段です。\n\n### **2-1. 一元管理による効率化**\n\nGitLabは、ソースコード管理だけでなく、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)、[コードレビュー](https://about.gitlab.com/ja-jp/topics/version-control/what-is-code-review/)、セキュリティスキャン、監査ログなどを一元管理します。これにより、**複数のツールを使い分ける必要がなくなり、運用がシンプル**になります。\n\n* **自動テストとデプロイ:** [CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)機能を使ってコードのビルドやテストを自動化し、迅速なデプロイを可能にします。  \n* **監査機能:** 企業のコンプライアンス要件に対応するため、詳細な変更履歴や監査ログを提供します。\n\n### **2-2. AWS環境との連携**\n\nGitLabはAWSの主要サービス（IAM、EKS、EC2など）とシームレスに統合でき、**既存のAWSリソースを活用した運用が可能**です。（以下は例）\n\n* **GitLab RunnerをEKS上で運用:** GitLabの[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインをEKS（Elastic Kubernetes Service）と連携させ、アプリケーションの自動デプロイを実現します。  \n* **AWS IAMと連携した認証管理:** GitLabのパイプラインからAWSリソースにアクセスする際、IAMロールを使用した安全な認証が可能です。\n\nこれにより、AWSとGitLabの強みを組み合わせた効率的な開発体制を構築できます。\n\n## **3\\. クラスメソッド社による移行支援**\n\nGitLabへの移行については、[【徹底解説！】AWS CodeCommitからGitLabへの移行ガイド](https://about.gitlab.com/ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab/)で全体像をご覧いただくのが良いでしょう。一方で、単なるリポジトリ移行にとどまらず、**AWSとGitLabの高度な統合を実現するための専門的な支援**が重要です。ここで、AWSに精通した**クラスメソッド社**の支援が鍵となります。\n\n### **クラスメソッド社の強み**\n\nクラスメソッド社は、AWSとGitLabの両方に精通したエキスパートとして、次のような包括的な移行支援を提供します(例)。\n\n* **移行計画の立案:** 現在のAWS環境と開発プロセスを分析し、GitLabへの移行計画を策定します。  \n* **PoC（概念実証）の実施:** 小規模なGitLab環境を試行し、機能の適合性を確認します。  \n* **AWSリソースとの最適な連携:** GitLab RunnerをAWS上に構築し、EKSやIAMを使ったシームレスな運用を実現します。\n\n## **4\\. GitLab導入のメリットと長期的な効果**\n\n### **4-1. 開発プロセスの効率化**\n\nGitLabの一元管理機能により、**ツール間の切り替えが不要**になり、開発速度が向上します。また、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)の自動化により、反復的な作業が減り、チームの生産性が向上します。\n\n### **4-2. コスト削減**\n\nGitLabは、複数のツールを組み合わせる代わりに**単一プラットフォームで運用**できるため、ライセンスや運用コストの削減が期待できます。また、クラウド版（SaaS）とオンプレミス版の両方を提供しており、企業のニーズに応じた選択が可能です。\n\n### **4-3. 持続的な開発環境の確立**\n\nGitLabはオープンソースとして開発が進められており、**新しい機能の追加やコミュニティサポート**が期待できます。これにより、長期にわたる開発環境の安定性が確保されます。\n\n## **5\\. まとめと次のステップ**\n\nAWS CodeCommitの終了は、企業にとって新しいソースコード管理体制への移行を求める大きな転換点です。しかし、**GitLabは単なる代替ではなく、開発プロセス全体を最適化するための強力なプラットフォーム**です。GitLabを導入することで、AWSインフラを活かしながら一貫性のある運用が実現します。\n\nさらに、AWSとGitLabの両方に精通する**クラスメソッド社の支援**を受けることで、スムーズな移行と持続可能な開発体制が構築できます。具体的な移行プロセスやPoC（概念実証）に関する相談は、[クラスメソッド社のDevOpsサービス](https://classmethod.jp/services/devops/)（外部サイト）からお問い合わせください。\n\n**今すぐGitLabへの移行を始め、新しい開発体制を一緒に構築しましょう。**",[285],{"slug":2652,"featured":92,"template":681},"partner-classmethod","content:ja-jp:blog:partner-classmethod.yml","Partner Classmethod","ja-jp/blog/partner-classmethod.yml","ja-jp/blog/partner-classmethod",{"_path":2658,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2659,"content":2665,"config":2672,"_id":2674,"_type":16,"title":2675,"_source":17,"_file":2676,"_stem":2677,"_extension":20},"/ja-jp/blog/introducing-the-source-insights-for-the-future-of-software-development",{"title":2660,"description":2661,"ogTitle":2660,"ogDescription":2661,"noIndex":6,"ogImage":2662,"ogUrl":2663,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2663,"schema":2664},"The Sourceの紹介: ソフトウェア開発の未来への洞察","The Sourceでは、革新的なソフトウェア開発戦略や、新たなテクノロジーに関する専門的なアドバイスを記事にして掲載します。ぜひご覧ください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674616/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","https://about.gitlab.com/blog/introducing-the-source-insights-for-the-future-of-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The Sourceの紹介: ソフトウェア開発の未来への洞察\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chandler Gibbons\"}],\n        \"datePublished\": \"2024-10-29\",\n      }",{"title":2660,"description":2661,"authors":2666,"heroImage":2662,"date":2668,"body":2669,"category":700,"tags":2670,"updatedDate":2671},[2667],"Chandler Gibbons","2024-10-29","最新のソフトウェア開発は、組織がビジネス価値を創造、提供、拡大する方法を変革しています。チームは、増大するセキュリティの脅威、新たなテクノロジー、ますます複雑化するコンプライアンスへの要求に対応しながら、迅速かつ効率的にソリューションを構築しなければなりません。 そこでGitLabは新たに、ビジネスの成功の実現に向けたソフトウェア開発の進化を取り上げる[『The Source』](https://about.gitlab.com/the-source/)をスタートし、GitLabの専門家やソートリーダー（その分野をけん引する第一人者のこと）による独自のリサーチや分析に裏打ちされた、ソフトウェア開発の未来に関する洞察を定期的にお届けします。『The Source』では、次のような疑問にお答えするコンテンツを提供します。\n\n* リーダーはソフトウェア開発ライフサイクル全体でAIの投資対効果（ROI）をどのように測定できるか？\n* ソフトウェアのサプライチェーン全体でセキュリティとコンプライアンスを確保する最適な方法とは？\n* プラットフォームやツールチェーンを統合することで、チームにおいてどのような効率化を実現できるか？\n\n現時点で『The Source』で取り上げている内容の一部を抜粋してご紹介します。\n\n**AIがもたらす影響を測定する4つのステップ**\n\n「AIにより強化されたコーディングの生産性を評価するには、コード行数やコードコミット数、タスク完了数といった従来のメトリクスよりも、より繊細なアプローチが必要となります。そのためには、開発速度、ソフトウェア品質、セキュリティのバランスを考慮した実際のビジネス成果に焦点を移す必要があります。」\n- [AIの専門家Taylor McCaslinがご紹介する4つのステップ](https://about.gitlab.com/the-source/ai/4-steps-for-measuring-the-impact-of-ai/)\n\n**一般的なセキュリティに関する不満の根本原因に対処するには**\n\n「DevSecOpsはエンジニアリングチームとセキュリティチーム間の連携の強化を保証するものですが、不満や食い違いがチーム間の溝として存在することも確かです。このような課題は、組織のセキュリティに対する考え方やチームの連携方法、セキュリティに割く時間の配分といった、より大きな問題の兆しとして発生しています。」\n- [GitLabの最高情報セキュリティ責任者Josh Lemosの力を借りて、チーム間の溝を解消する](https://about.gitlab.com/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/)\n\n**プラットフォームエンジニアリングでビジネス成果を推進する**\n\n「プラットフォームエンジニアリングの目的は、デベロッパーのワークフローを正常化・標準化することです。これは、大部分の作業に対しては最適化された「Golden Path」を提供し、残りの作業に対しては、例外的なケースを定義できるような柔軟性を持たせることで実現できます。」\n- [GitLabフィールド最高技術責任者Brian Waldによる、プラットフォームエンジニアリングを成功させるためのベストプラクティス](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/)\n\n## 『The Source』を意思決定の際の必読書に\n\n今すぐ[『The Source』](https://about.gitlab.com/the-source/)にアクセスし、最新の洞察や組織運営に関する疑問への答えを入手し、新たに学んだことをチームと共有しましょう。また、ニュースレターをご購読いただくと、定期的に最新情報をお届けします。先進的なテクノロジーリーダーが集うコミュニティに参加して、ともにソフトウェア開発の未来を形作りましょう。",[721,722,700,702],"2025-03-28",{"slug":2673,"featured":92,"template":681},"introducing-the-source-insights-for-the-future-of-software-development","content:ja-jp:blog:introducing-the-source-insights-for-the-future-of-software-development.yml","Introducing The Source Insights For The Future Of Software Development","ja-jp/blog/introducing-the-source-insights-for-the-future-of-software-development.yml","ja-jp/blog/introducing-the-source-insights-for-the-future-of-software-development",{"_path":2679,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2680,"content":2686,"config":2691,"_id":2693,"_type":16,"title":2694,"_source":17,"_file":2695,"_stem":2696,"_extension":20},"/ja-jp/blog/gitlab-17-5-released",{"title":2681,"description":2682,"ogTitle":2681,"ogDescription":2682,"noIndex":6,"ogImage":2683,"ogUrl":2684,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2684,"schema":2685},"GitLab 17.5リリース","GitLab 17.5でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662166/Blog/Hero%20Images/17_5-cover-image.png","https://about.gitlab.com/blog/gitlab-17-5-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.5リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-10-17\",\n      }",{"title":2681,"description":2682,"authors":2687,"heroImage":2683,"date":2688,"body":2689,"category":701,"tags":2690,"updatedDate":2238},[738],"2024-10-17","**GitLab Duo Quick Chat AIコードアシストを含むGitLab 17.5をリリース**\n\nこのたび、GitLab 17.5のリリースを発表しました。このリリースでは、GitLab Duo Quick ChatによるIDEでのコードアシスト、GitLab Duoコード提案のセルフホストモデル、コード提案使用状況のエクスポート、GitLab Duo ChatとのMRに関する対話など、さまざまな機能が追加されました。\n\nこれらの機能は、今回のリリースに含まれる125件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 17.5には、GitLabコミュニティのユーザーから200件以上ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、17.6リリースのキックオフビデオも視聴できる[今後のリリースページ](https://about.gitlab.com/direction/kickoff/)をご覧ください。  \n\n> [GitLab Duo Quick Chat AIコードアシストを含むGitLab 17.5をリリースしました。](http://twitter.com/share?text=GitLab+17.5+released+with+Duo+Quick+Chat+AI+code+assistance.&url=https://about.gitlab.com/releases/2024/10/17/gitlab-17-5-released/&hashtags=)クリックしてSNSで共有しましょう！\n\n## 今月のMost Valuable Person（[MVP](https://about.gitlab.com/community/mvp/)）は[Jim Ender](https://gitlab.com/jimender2)さんが受賞\n\nMVPには、誰もが[GitLabコミュニティのコントリビューターを推薦](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)できます。積極的に活動している候補者を応援したり、他の誰かをノミネートしてみませんか。🙌\n\nJimさんは、GitLabにおいて[100件近くのバックログイシューを解決する](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=closed&assignee_username%5B%5D=Jimender2&first_page_size=100)取り組みを主導したことが評価されました。興味深いディスカッションが繰り広げられる毎週恒例のペアリングセッションに精力的に参加しています。さらに、[GitLab Discord Community](https://discord.gg/gitlab)のユーザーを支援し、GitLabサポートリクエストのトラブルシューティングや新規コントリビューターへの指導なども行っています。Jimさんは、重要なインフラやERPシステム向けのソフトウェアを開発している産業テクノロジー企業に勤務しています。\n\n「小さな貢献であっても積み重なれば、プロジェクトが改善されます。ドキュメンテーションに関するコントリビュートのような小さなものでも、誰かの役に立ちます。新機能のすべてを開発する必要はないんです」とJimさんは述べています。\n\nJimさんを推薦したのは、GitLabのコントリビューターサクセスチームに所属する[スタッフフルスタックエンジニア、](https://gitlab.com/leetickett-gitlab)Lee Tickettです。「より幅広いコミュニティからの参加を促すために、イシューのトリアージおよびキュレーション作業は、私にとって最重要項目のひとつです。Jimさんはそのための道筋をつけてくれています」とLeeは言います。\n\nLeeに続き、GitLabのコントリビューターサクセスチームのシニアプログラムマネージャーである[Daniel Murphy](https://gitlab.com/daniel-murphy)も、Jimさんを推薦しました。「新規コントリビューターに対するJimさんの多大なるサポートとオンボーディングの際の丁寧な説明のおかげで、GitLabを共同開発するコミュニティとして成長できています」\n\n「Jimさんの[マージリクエスト](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163849)をレビューしましたが、素晴らしかったです！」と、GitLabのシニアフロントエンドエンジニアである[Vanessa Otto](https://gitlab.com/vanessaotto)は振り返ります。「Jimさんからはすぐに返答があり、提案した内容を即座に理解して、スムーズに実装してくださいました。Jimさんの効率的かつ明瞭なアプローチには感銘を受けました」\n\nJimさんを始め、GitLabにコントリビュートしてくださっているオープンソースコミュニティのみなさまに心から感謝します！\n\n## GitLab 17.5でリリースされた主な改善点\n\n### GitLab Duo Quick Chatの導入 \nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise  \nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nGitLab Duo Quick Chatが導入されました。これは、コードを編集している画面上で動作するように設計されたAI搭載のチャットです。Quick Chatは編集中の行で直接動作するため、デベロッパーはコードから一切離れずにリアルタイムでサポートを得られます。リファクタリング、バグの修正、テストの作成など、どのような状況であっても、Quick Chatによりその場で提案や説明が提供されるため、ツール間の移動による頭の切り替えが不要になり、完全に集中し続けることができます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#in-the-editor-window)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15218)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/5JbAM5g2VbQ?si=P58oz2nyORFl538a\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### GitLab Duoコード提案でのセルフホストモデルの使用(ベータ版)\n\nSaaS: -  \nSelf-Managed: Ultimate、Duo Enterprise\n\nGitLab承認の大規模言語モデル（LLM）を、自社のインフラ環境でホストして、コード提案のデータソースとして設定できるようになりました。この機能はベータ版で、UltimateとDuo Enterpriseのサブスクリプションをお持ちであれば、Self-ManagedのGItLab環境でご利用いただけます。  \nセルフホストモデルでは、オンプレミスまたはプライベートクラウドでホストしたモデルを使用して、コード提案を有効化できます。現在は、vLLMまたはAWS Bedrockを介してオープンソースのMistralモデルをサポートしています。セルフホストモデルを利用することで、エンタープライズレベルのデータ主権とプライバシーを維持しながら、生成AIの力を活用できます。  \n[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/498376)から、ぜひフィードバックをお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/self_hosted_models/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/498114)\n\n![self-hosted-beta](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687327/Blog/Content%20Images/self-hosted-beta.png)\n\n### コード提案使用状況のエクスポート\n\nSaaS: Ultimate、Duo Enterprise  \nSelf-Managed: Ultimate、Duo Enterprise\n\nこれまでAIインパクト分析は、GitLab.comでGitLab Duo Enterpriseを利用するお客様、およびGitLab Self-ManagedでClickHouseとのインテグレーションを利用するお客様に対してのみ提供されていました。さらに、デフォルトのメトリクスは集約されたものだけでした。\n\n本リリースでは、生データのコード提案イベントをGraphQL APIからエクスポートできるようになりました。この機能を使用してデータをデータ分析ツールにインポートすれば、提案のサイズ、言語、利用者など、より多くの側面から採用率に関するより詳しいインサイトを得られます。ClickHouseに生データは保存されないため、一部のAIインパクト分析メトリクスは、GitLab DedicatedやSelf-Managedを含めたGitLabの全デプロイで利用可能です。  \n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/#codesuggestionevent)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/477231)\n\n### GitLab Duo Chatとのマージリクエストに関する対話\n\nSaaS: Ultimate、Duo Enterprise  \nSelf-Managed: Ultimate、Duo Enterprise\n\nみなさまからのお寄せいただいたフィードバックに応え、GitLab Duo Chatがマージリクエストを認識するようになりました。レビュアーや作成者がマージリクエストについてDuo Chatとチャットで会話することで、マージリクエストについてすばやく調べたり、次に何をすべきかを確認したりできるようになりました。手順は簡単で、マージリクエストを開いてからDuo Chatを開き、会話を始めるだけです。\n\nこの新機能は既存の機能を補完するものです。GitLab Duoに「[コード変更のサマリー](https://docs.gitlab.com/ee/user/project/merge_requests/duo_in_merge_requests.html#generate-a-description-by-summarizing-code-changes)の作成を依頼することでマージリクエストの説明をすばやく入力でき、レビュアーはマージリクエストの概要を把握できます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples#ask-about-a-specific-merge-request)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/464587)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/4muvSFuWWL4?si=Btvvv1S9Evh3g8I1\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### ブランチルール編集機能の強化\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate \n\nGitLab 15.10では、[ブランチ関連の設定とルールが1つのページで表示されるようになり](https://about.gitlab.com/releases/2023/03/22/gitlab-15-10-released/#see-all-branch-related-settings-together)ました。これにより、複数の設定が適用されたプロジェクトの構成を簡単に理解できるようになりました。\n\n本リリースでは、この機能をベースに、ブランチ保護、承認ルール、外部ステータスチェック設定を含め、特定のブランチルールをこのページ上で直接変更できるようになりました。これらの新機能を土台としてブランチ設定の[継続的な改善](https://gitlab.com/groups/gitlab-org/-/epics/12546)に取り組み、将来的にはさらに柔軟に設定できるようになる予定です。\n\nぜひ新機能を活用し、フィードバックをお寄せください。フィードバックは、専用の[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/486050)からお寄せいただけます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/repository/branches/branch_rules.html#create-a-branch-rule)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/8075)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/lUteytQOiYc?si=qx9YoimLTKVmnQ0_\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### スイッチボードにGitLab Dedicatedテナント概要を追加\n\nSaaS: -\nSelf-Managed: Ultimate\n\nスイッチボードに新たにテナント概要が追加され、GitLab Dedicatedインスタンスに関する重要な情報にまとめてアクセスできるようになりました。\n\n今回のリリースで初めて追加されたこの機能により、現在お使いのGitLabのバージョン、インスタンスのURL、今後予定されているメンテナンス期間と過去のメンテナンス期間の日時をすべてテナント概要ページで確認できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/dedicated/tenant_overview.html) \n[イシュー](https://about.gitlab.com/direction/saas-platforms/switchboard/#roadmap)\n\n![switchboard-tenant-overview](https://about.gitlab.com//about.gitlab.com/images/17_5/switchboard-tenant-overview.png)\n\n### シークレットプッシュ保護の一般提供を開始\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nGitLab Ultimateをご利用のすべてのお客様を対象に、シークレットプッシュ保護の一般提供を開始しました。\n\nキーやAPIトークンなどのシークレット情報が誤ってGitリポジトリにコミットされた場合、リポジトリにアクセスできる人なら誰でも、情報を悪用する目的でそのシークレットのユーザーになりすますことができます。シークレットが流出すると、時間とコストがかかり、企業の評判に悪影響が及ぶ可能性があります。シークレットプッシュ保護は、そもそもシークレットがプッシュされないように保護することで、修正時間を削減し、リスクを軽減します。\n\nシークレットプッシュ保護機能は、ベータ版から改善されました。Git CLIを用いてコミットをプッシュすると、変更点（差分）のみを対象にスキャンが実行され、シークレットの有無を確認するようになりました。また、誤検出を防ぐために、パスやルール、特定の値を除外する実験的サポートも追加されました。\n\n詳細については、[ブログ記事（英語）](https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/13107)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/SFVuKx3hwNI?si=T2WPfTiMVHnzslEX\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### GitLab.comで認証情報インベントリが利用可能に\n\nSaaS: Ultimate  \nSelf-Managed: -\n\nGitLab.comのトップレベルグループのオーナーは、認証情報インベントリをご利用いただけるようになりました。認証情報インベントリでは、グループで使用される[エンタープライズユーザーの](https://docs.gitlab.com/ee/user/enterprise_user/)パーソナルアクセストークンとSSH鍵を閲覧できます。また、認証情報の失効や削除に加え、追加情報の表示も可能です。これまで認証情報インベントリは、GitLab Self-Managedの管理者のみが利用できました。\n\nグループオーナーは認証情報インベントリを使用することで、自分の管理権限内にある認証情報を把握できるため、可視性が高まります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/297441)\n\n![govern_credentialsinventory](https://about.gitlab.com//about.gitlab.com/images/17_5/govern_credentialsinventory.png)\n\n### 依存関係リストでのコンポーネントによるフィルタリング\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nGitLabで、特定の依存関係コンポーネントをすばやくフィルタリングして、グループまたはプロジェクトで使用されているかどうかを特定できるようになりました。特定のパッケージやバージョンが使用されているかを確認するためだけに、手動で全リストを調べるのは面倒で、時間もかかります。新たに依存関係リストで**コンポーネントごとにフィルタリング**を行えるようになったことで、脆弱な依存関係を取り出して、アプリケーションのリスクを評価できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_list/#filter-dependency-list)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12652)\n\n![component_filter_dependency_list](https://about.gitlab.com//about.gitlab.com/images/17_5/component_filter_dependency_list.png)\n\n## GitLab 17.5でリリースされたその他の改善点\n\n### コーディングエクスペリエンスの向上！Windows用Visual StudioでDuo Chatが利用可能に\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise  \nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nDuo ChatがWindows用Visual Studioにシームレスに統合され、開発ワークフローを強化できるようになりました。AI搭載機能を活用してコードの説明、改良、デバッグ、テストの作成をすべてリアルタイムで行うDuo ChatをVisual Studio上で使用できることで、コーディングエクスペリエンスを向上させます。この統合により、使い慣れた開発環境で直接Duo Chatの高度なAIツールを活用できるため、生産性が向上するとともに、より迅速かつ効率的に問題解決を行えます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html#use-gitlab-duo-chat-in-visual-studio-for-windows)  \n[エピック](https://gitlab.com/groups/gitlab-org/editor-extensions/-/epics/77)\n\n![duo-chat-visual-studio](https://about.gitlab.com//about.gitlab.com/images/17_5/duo-chat-visual-studio.png)\n\n### コンテナレジストリタグ操作時のAPIパフォーマンスの向上\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLab Self-Managedインスタンス用のコンテナレジストリAPIが大幅に改善されました。GitLab 17.5リリースで、`:id/registry/repositories/:repository_id/tags`エンドポイントにキーセットページネーションが実装され、GitLab.comでは既に提供されていた機能をご利用いただけるようになりました。この機能強化は、APIパフォーマンスの改善と、デプロイ方法に左右されることなくGitLabで一貫したエクスペリエンスを提供することを目的とした、継続的な取り組みの一環です。\n\nキーセットページネーションを使用すると、大規模なデータセットをより効率的に処理でき、結果としてパフォーマンスとユーザーエクスペリエンスが向上します。このアップデートにより、リポジトリタグをよりスムーズに操作できるようになったため、特に大規模なコンテナレジストリを管理する場合に特に効果的です。この機能を使用するには、Self-Managedインスタンスを[次世代のコンテナレジストリ](https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html)にアップグレードする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/container_registry.html#list-registry-repository-tags)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/482399)\n\n### REST APIを使用したエージェントおよびGitOps環境の設定\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nポッドのステータスとFluxの調整は、GitLab環境のUIから確認できます。ただし、この方法では、GraphQLかUIを使用しない限り必要な設定を確認できないため、スケーリングが難しい一面があります。本リリースから、Kubernetes用エージェントの設定と、環境ごとのネームスペースやFluxリソースの設定を行うREST APIサポートがGitLabに含まれるようになりました。動的な環境のサポートをさらに強化するために、[イシュー467912](https://gitlab.com/gitlab-org/gitlab/-/issues/467912)では、CI/CDパイプラインでこれらの設定のサポートを実装することが提案されています。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/environments.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/412677)\n\n### ファイアウォールで保護されたGitLabインストール環境向けにKubernetesインテグレーションをサポート\n\nSaaS: -\nSelf-Managed: Ultimate\n\nこれまで、Kubernetes用エージェントを使用できるのは、GitLabインスタンスにKubernetesクラスターが接続可能な場合のみでした。このような制限があることで、たとえばプライベートネットワーク上やファイアウォール経由でGitLabを実行しているお客様は、エージェントを使用できませんでした。GitLab 17.5からは、適切に設定された`agentk`インスタンスが接続開始を待機していることを前提とすることで、GitLabからクラスターとGitLab間の接続を開始できます。\n\n最初の接続が確立されると、エージェントの全機能を利用できるようになります。本リリースでは、クラスターからの初期化に関しては変更はありません。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/#receptive-agents) \n\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/437014)\n\n### GitLab UIからGitOpsの調整を一時停止または再開できるように\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nFluxを使用する中で、これまでに自動調整やドリフトの修正をすぐに停止せざるを得なかったことや、`HelmRelease`をトリガーして手動で削除したリソースを同期したいと思ったことはないでしょうか。このようなアクションは、Fluxの一時停止および再開機能を使用することで最も効果的に実現できます。これまではFlux CLIが利用可能な最良の方法でしたが、この方法では、ツール間の移動により頭の切り替えが発生するだけでなく、適切なリソースが対象となるようにコマンドをいくつか実行する必要がありました。GitLab 17.5では、Kubernetes用に組み込まれたダッシュボードから調整を一時停止または再開できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html#suspend-or-resume-flux-reconciliation)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/478380)\n\n### プロジェクトレベルでのコンプライアンスセンターへのアクセス\n\nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\nこれまで、コンプライアンス センターは最上位のグループとサブグループでのみ利用可能でした。\n\n今回のリリースでは、プロジェクトにもコンプライアンスセンターが追加されました。プロジェクトレベルでのコンプライアンスセンターでは、特定のプロジェクト関連のチェックおよび違反の閲覧のみ行えます。\n\nフレームワークを追加または編集する場合は、プロジェクトレベルではなく、トップレベルグループのコンプライアンスセンターにアクセスする必要があります。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance_center/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/441350)\n\n### エンタープライズユーザーのパスワード認証を無効にする\nSaaS: Premium、Ultimate  \nSelf-Managed: -\n\nエンタープライズユーザーは、ユーザー名とパスワードを使用してローカルアカウントで認証を行えます。本リリースでは、グループオーナーが、グループのエンタープライズユーザーのパスワード認証を無効にできるようになりました。パスワード認証が無効になっている場合、エンタープライズユーザーは、グループのSAML Identity Providerを使用してGitLabのWeb UIで認証するか、もしくはパーソナルアクセストークンを使用して、GitLab APIやGitでHTTP基本認証を行えます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/saml_sso/#disable-password-authentication-for-enterprise-users)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/373718)\n\n### コンプライアンスパイプラインからセキュリティポリシーへの移行プロセス\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nGitLab 17.3では、コンプライアンスパイプラインの非推奨化と、GitLab18.0リリースでの削除を発表しました。コンプライアンスパイプラインの代わりに、GitLab 17.2でリリースされたパイプライン実行ポリシータイプを使用することが推奨されます。\n\n既存のコンプライアンスパイプラインからパイプライン実行ポリシータイプへの移行を促すために、本リリースでは次の目的で警告バナーが表示されます。\n\n* コンプライアンスパイプラインの非推奨化に関するユーザーへの通知  \n* 既存のコンプライアンスパイプラインからパイプライン実行ポリシータイプへの移行を促すプロンプトと移行のガイド付きワークフローの提供\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/compliance_pipelines.html#pipeline-execution-policies-migration)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/11275)\n\n### APIを使用したトークンの関連付けの表示\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nトークンがどのグループ、サブグループ、またはプロジェクトに関連付けられているかを確認できるようになりました。これにより、トークンの有効期限や失効による影響を判断し、どこでトークンが使用可能であるかを把握しやすくなります。 \n\n[ドキュメント](https://docs.gitlab.com/ee/api/personal_access_tokens.html#list-token-associations) \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/466046)\n\n### GitLabチャートの改善\n\nSaaS: -  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 17.5では、NGINX Ingressコントローラーのバージョンがアップデートされました。本リリースに含まれる`nginx-controller`コンテナイメージのバージョンは1.11.2です。なお、新しいコントローラーではEndpointSliceが使用されており、EndpointSliceへのアクセスにはRBACルールが必要になるため、新しいRBAC要件が含まれていますのでご注意ください。\n\n[ドキュメント](https://docs.gitlab.com/charts/)\n\n### オムニバスの改善  \nSaaS: -  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 17.5では、単一ノードのインストール時にPostgreSQLをバージョン14.xから16.xにアップグレードできるようになりました。自動アップグレードは有効でないため、手動でPostgreSQLのアップグレードを実行する必要があります。\n\n[ドキュメント](https://docs.gitlab.com/omnibus/)\n\n### GitLab Runner 17.5\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\n本日、GitLab Runner 17.5もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\n**新機能：**\n\n* [スコープ指定された一時的な認証情報によるAWS S3のマルチパートアップロードをサポート](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26921)\n\n**バグの修正：**\n\n* [すべてのサービスコンテナが実行されていなければ、追加サービスを含むジョブが完了しない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38035)問題  \n* [Amazon Linux 2で`gitlab-runner-fips-17.4.0-1`パッケージの実行に失敗し、glibcエラーが返される](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38034)問題  \n* [S3 Express One Zoneエンドポイントを使用していると、Amazon S3でキャッシュが機能しない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37394)問題  \n* [`DOCKER_AUTH_CONFIG`変数に複数のレジストリが指定されている場合、ジョブがベースイメージをプルできない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28073)問題\n\n[ドキュメント](https://docs.gitlab.com/runner)  \n\n### 保護パッケージを使用して依存関係を守る\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: -\n\n本リリースでは、NPMの保護パッケージが新たにサポートされました。こちらは、GitLabパッケージレジストリのセキュリティと安定性を強化することを目的として設計された新機能です。急速に変化するソフトウェア開発の現場においては、パッケージを誤って変更または削除してしまった場合、開発プロセス全体に混乱が生じる可能性があります。保護パッケージを使用すると、意図せぬ変更を防いで最も重要な依存関係を保護できます。\n\nGitLab 17.5からは、保護ルールを作成してNPMパッケージを保護します。保護ルールの条件をパッケージが満たした場合、指定されたユーザーのみがパッケージを更新または削除できます。この機能を使用すると、手動による監視の必要性を減らすことにより、意図せぬ変更の防止、規制要件へのコンプライアンスの強化、ワークフローの効率化を実現できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/packages/package_registry/package_protection_rules.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/472655)\n\n![protected_npm_packages](https://about.gitlab.com//about.gitlab.com/images/17_5/protected_npm_packages.png)\n\n### GitLabのKubernetesインテグレーションが簡単に立ち上げ可能に\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabは、[Kubernetes用エージェント](https://docs.gitlab.com/ee/user/clusters/agent/)と[Fluxとのインテグレーション](https://docs.gitlab.com/ee/user/clusters/agent/gitops.html)を通じて、柔軟で信頼性が高く、安全なGitOpsサポートを提供していますがGitLabでFluxを立ち上げてKubernetes用エージェントを設定するには、さまざまなドキュメントを読み、GitLab UIとターミナル間で移動して作業を行う必要がありました。本リリースでは、GitLabに[`glab cluster agent bootstrap`コマンド](https://gitlab.com/gitlab-org/cli/-/blob/main/docs/source/cluster/agent/bootstrap.md)が追加され、インストール済みのFlux上に簡単にエージェントをインストールできるようになりました。これにより、たった2つの簡単なコマンドでFluxとエージェントを設定できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/install/#bootstrap-the-agent-with-flux-support-recommended)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/473987)  \n\n### Kubernetesリソースイベントのストリーミング\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabでは、Kubernetes用のダッシュボード上に、ポッドとポッドのログストリームのすべてがリアルタイムで表示されます。GitLab 17.4では、リソース固有のイベント情報の静的リストをUIから確認できるようになりました。今回のリリースではKubernetes用のダッシュボードをさらに強化し、クラスター内で発生した受信イベントをストリーミングできるようにしました。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/470042)  \n\n### 高度なSASTでのRubyのサポートとルールの更新\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nGitLabの高度なSASTのサポート対象として、新たにRubyを追加しました。Rubyを対象にファイルや機能をまたがるスキャンを実行するには、[高度なSASTを有効にしてください](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast/#enabling-advanced-sast-scanning)。高度なSASTがすでに有効な場合は、Rubyのサポートも自動的に有効になります。\n\nまた、[高度なSASTでサポートされる他の言語](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast/#supported-languages)の検出ルールを改善するために、次のアップデートを先月リリースしました。\n\n* 新たなJavaパストラバーサル、Javaコマンドインジェクション、JavaScriptパストラバーサルの脆弱性を検出  \n* 脆弱性の種類をより具体的かつ一貫性を持って特定できるようにCWEマッピングを更新  \n* パストラバーサルの脆弱性の重大度を増加\n\n高度なSASTが各言語で検出できる脆弱性の種類を確認するには、新しい[高度なSASTのカバレッジページ](https://docs.gitlab.com/ee/user/application_security/sast/advanced_sast_coverage/)を参照してください。\n\n高度なSASTの詳細については、[先月の一般提供の発表に関するブログ記事](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available)でご覧いただけます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast/)  \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/14425)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/457969) \n\n### セキュリティポリシーのスコープにグループを追加\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nセキュリティポリシーのスコープにグループやサブグループを含められるようになりました。これは既存のオプションを拡張するもので、グループやサブグループ内の全プロジェクト、定義されたプロジェクトリストに記載されているプロジェクト、コンプライアンスフレームワークラベルのリストと一致するプロジェクトを対象にできるようになりました。\n\n今回のアップデートにより、グループ全体でポリシーを有効にする際の柔軟性がさらに高まります。また、必要に応じてスコープに例外を適用して、プロジェクトにポリシーが適用されないようにすることも可能です。\n\nこの改善以外にも、セキュリティポリシープロジェクトをリンクし、スコープをきめ細かく設定してポリシーを実施するプロセスを簡素化する、さまざまな[機能強化](https://gitlab.com/groups/gitlab-org/-/epics/5446)を今後も行っていく予定です。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#security-policy-scopes)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14149)\n\n![scope-all-projects-in-linked-groups](https://about.gitlab.com//about.gitlab.com/images/17_5/scope-all-projects-in-linked-groups.png)\n\n### ユーザー管理サマリーの改善\nSaaS: -  \nSelf-Managed: Free、Premium、Ultimate\n\n管理者エリアで、インスタンス上のユーザーに関する次の重要な情報のサマリーが表示されるようになりました。\n\n* 承認保留中  \n* 2要素認証なし  \n* 管理者\n\n管理者は、サマリービューで何人のユーザーが上記の状態にあるかをすばやく確認し、フィルタリングできるため、ユーザ管理の効率性が向上します。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/account/create_accounts.html#create-users-in-admin-area)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/456332)\n\n![govern_admin_statcards](https://about.gitlab.com//about.gitlab.com/images/17_5/govern_admin_statcards.png)\n\n### SAMLシングルサインオンの適用が選択可能に\nSaaS: -  \nSelf-Managed: Free、Premium、Ultimate\n\nこれまでは、SAML SSOが有効な場合、グループはSSOの強制を選択できました。その場合、すべてのユーザーがグループにアクセスする際に、SSO認証を使用する必要がありました。しかし、グループによっては、従業員やグループメンバーに対してはSSOを実施してセキュリティを確保したい一方で、外部のコラボレーターや請負業者に関してはSSOなしでグループにアクセスできるようにしたい場合もあります。\n\n本リリースでは、SAML SSOが有効なグループでは、SAML IDを持つすべてのメンバーに対して自動的にSSOが実施されますが、SAML IDを持たないグループメンバーには、SSOの実施が明示的に有効化されていない限り、SSOの使用が求められません。\n\nメンバーがSAML IDを持っているとみなされるのは、次のいずれかまたは両方に該当する場合です。\n\n* GitLabグループのシングルサインオンURLを使用してGitLabにサインイン済みの場合  \n* SCIMを用いてプロビジョニングされた場合\n\nSSOの強制の選択をスムーズに動作させるには、「**このグループのSAML認証を有効にします**」チェックボックスをオンにする前に、SAMLの設定が正しく動作しているかどうかを確認してください。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/settings/sign_in_restrictions.html#disable-password-authentication-for-users-with-an-sso-identity)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/382917)  \n\n## 実験的な機能\n\n### JavaとPythonにおける静的な到達可能性のサポート\n本リリースでは、コンポジション解析でJavaとPythonにおける静的な到達可能性をサポートしました。\n\n静的な到達可能性のサポートにより、ソフトウェアコンポジション解析（SCA）で得られる結果がより充実します。静的な到達可能性機能では、GitLabの高度なSASTによってプロジェクトのソースコードをスキャンし、使用中のオープンソースの依存関係を特定します。  \n\nトリアージや修正に関する意思決定を行う上で、静的な到達可能性によって生成されたデータを参考にできます。また、静的な到達可能性データをCVSS（共通脆弱性評価システム）スコアと一緒に使用すれば、より焦点を絞って脆弱性を確認することも可能です。\n\nこの機能は実験的に導入されました。有効にするには、`.gitlab-ci.yml`ファイルまたは[プロジェクト変数](https://docs.gitlab.com/ee/ci/variables/#for-a-project)で`STATIC_REACHABILITY_ENABLED`変数を設定してください。この機能の詳細については、[解説動画](https://www.youtube-nocookie.com/embed/_SVhcfcy9N8)をご視聴ください。\n\nみなさまからのフィードバックをお待ちしています。ご質問やコメントがある場合、またはGitLabチームとのやり取りをご希望の場合は、こちらの[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/498526)をご覧ください。  \n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n\n以下のリンクをクリックして、17.5のバグ修正、パフォーマンスの強化、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=17.5)  \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=17.5)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.5)\n\n## 非推奨事項 \n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n-   [スキャン実行ポリシーで\\`scan\\`アクションを制限](https://docs.gitlab.com/ee/update/deprecations.html#limited-scan-actions-in-a-scan-execution-policy)  \n- [\\`mergeTrainIndex\\`および\\`mergeTrainsCount\\` GraphQLフィールドを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#mergetrainindex-and-mergetrainscount-graphql-fields-deprecated)\n- [GitLab Runner Docker Machine Executorを非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#gitlab-runner-docker-machine-executor-is-deprecated)\n- [\\`ciUsedMinutes\\` GraphQLフィールドの名前を\\`ciDuration\\`に変更](https://docs.gitlab.com/ee/update/deprecations.html#ciusedminutes-graphql-field-renamed-to-ciduration)\n- [\\`ciJobTokenScopeAddProject\\`のGraphQL変異を非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#cijobtokenscopeaddproject-graphql-mutation-is-deprecated)\n- [ネームスペースの\\`add\\_on\\_purchase\\` GraphQLフィールドを\\`add\\_on\\_purchases\\`に置き換え](https://docs.gitlab.com/ee/update/deprecations.html#replace-namespace-add_on_purchase-graphql-field-with-add_on_purchases)\n\n### 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n### GitLab 17.5へのアップグレードに関する重要なお知らせ\n\n* Gitlab 17.5以降のバージョンでは、Ruby 3.2が必要です。管理者が[ソースからインストール](https://docs.gitlab.com/ee/install/installation.html)して、GitLab 17.5以降のバージョンにアップグレードする場合、Ruby 3.2以降のバージョンが必要となります。現時点では、それ以外にユーザーによる対応は必要ありません。この変更が必要な理由は、2025年3月31日をもってRuby 3.1のサポートが終了し、公式のアップデートやサポートが提供されなくなるためです。GitLabでは、今後も[現在の安定バージョンのリリースに加え、セキュリティ修正を過去2回の月例リリース用に移植する](https://docs.gitlab.com/ee/policy/maintenance.html)方針を継続します。\n\nGitLab 17.5には、NGINXコントローラーコンテナイメージの新バージョン（`1.11.2`）が含まれています。新しいコントローラーではEndpointSliceが使用されており、アクセスにはRBACルールが必要となります。アップグレードする前に、新しいコンテナイメージを設定してください。  \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ワークフロー](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/ja-jp/pricing/) \n\n  個人ユーザー向けの永久無料機能を提供\n\n* [Premiumプラン](https://about.gitlab.com/ja-jp/pricing/premium/) \n\n  チームの生産性と調整を強化\n\n* [Ultimateプラン](https://about.gitlab.com/ja-jp/pricing/ultimate/) \n\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)\n（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n\n### 過去の日本語リリース情報\n\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],{"slug":2692,"featured":92,"template":681},"gitlab-17-5-released","content:ja-jp:blog:gitlab-17-5-released.yml","Gitlab 17 5 Released","ja-jp/blog/gitlab-17-5-released.yml","ja-jp/blog/gitlab-17-5-released",{"_path":2698,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2699,"content":2704,"config":2710,"_id":2712,"_type":16,"title":2713,"_source":17,"_file":2714,"_stem":2715,"_extension":20},"/ja-jp/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"title":2700,"description":2701,"ogTitle":2700,"ogDescription":2701,"noIndex":6,"ogImage":2070,"ogUrl":2702,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2702,"schema":2703},"Jira2Labを使用してJiraからGitLabへの大規模な移行をシームレスに実現","複雑なデータ移行の処理、スケーラビリティの向上、効率的な統合を保証するJira2GitLabを使用することで、JiraからGitLabへの大規模な移行がどのように簡素化されるかをご紹介します。","https://about.gitlab.com/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jira2Labを使用してJiraからGitLabへの大規模な移行をシームレスに実現\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Maximilien Belinga\"}],\n        \"datePublished\": \"2024-10-10\",\n      }",{"title":2700,"description":2701,"authors":2705,"heroImage":2070,"date":2707,"body":2708,"category":1705,"tags":2709},[2706],"Maximilien Belinga","2024-10-10","[2月にAtlassianサーバーのサポートが終了した](https://about.gitlab.com/ja-jp/move-to-gitlab-from-atlassian/)ことで、多くのユーザーがAtlassian CloudやAtlassian Data Centerのような代替製品を検討する必要に迫られています。その一方、Atlassianサーバーを使用している企業の間では、より柔軟でコスト効率に優れ、DevSecOpsの堅牢な統合を実現できるアジャイル計画ソリューションを求める動きが広がっています。こうした企業は、移行中にデータ量、カスタマイズ、ユーザーマッピング、パフォーマンス、データ整合性に関する課題にも取り組む必要があります。そこで役に立つのが、[GitLabのJira2Lab](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/jira2lab)です。Jira2Labは、CI/CDを完全に統合し、JiraからGitLabへの大規模な移行を実現するシームレスなソリューションを提供します。\n\n## 大規模なJiraの移行時に発生する問題\n\nJiraからGitLabへの移行は、特に複雑なワークフローや何千ものイシューを抱える企業では、非常に大変な作業となる場合があります。移行時に発生する最も一般的な課題は次のとおりです。\n\n- **大規模なデータ移行**：イシューや添付ファイル、コメント、プロジェクト数が多ければ多いほど、パフォーマンスの問題やデータ損失を生じさせずに、それらを移行するのは難しくなります。\n\n- **カスタムフィールドとワークフロー**：Jiraインスタンスには、GitLabにそのままではマッピングされないカスタムワークフローやフィールド、イシュータイプが含まれていることがよくあります。このようなギャップがあると、既存のツールではこれらの要素を変換するために手作業が必要となることが多いため、移行時に手間やストレスが生じます。\n\n- **包括的なDevSecOps機能の統合の欠如**：多くの移行ツールではプロジェクト管理データを処理できるものの、GitLabで提供されている包括的なDevSecOps機能は含まれていません。そのため、移行後に[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインとソース管理システムを手動で設定する手間がかかります。\n\n## Jira2Labについて\n\nJira2Labは、JiraからGitLabへの大規模な移行時に発生する特有の課題を解決するためにゼロから設計されました。単にデータを移行するだけでなく、ダウンタイムやデータ損失を引き起こすことなく、GitLabの強力なDevSecOps環境にシームレスに移行できるようにチームを支援します。\n\n### Jira2Labの主な機能\n\n1. 大規模なデータ処理の効率化\u003Cbr>\nJira2Labは、パフォーマンスを低下させることなく、複数のプロジェクトにわたって数千ものイシュー、添付ファイル、コメント、カスタムフィールドを処理できるように最適化されています。簡単にスケールできるため、最大規模の企業移行にも対応可能です。\n\n2. カスタムワークフローとフィールドのマッピング\u003Cbr>\nJira2Labの数ある機能の中でもひときわ目立つのは、JiraからGitLabへカスタムワークフローとフィールドを自動的にマッピングする機能です。このツールの柔軟なマッピング設定を活用することで、移行プロセス中の手作業が不要となり、JiraからGitLabにすべてをスムーズに移行できます。\n\n3. CI/CDパイプラインの統合\u003Cbr>\nJira2Labはイシューやプロジェクトを移行するだけでなく、GitLabのCI/CDパイプライン全体を移行プロセスに統合します。そのため、開発チームは移行後すぐに、自動テストやデプロイパイプラインなど、GitLabのDevSecOps機能を使い始められます。\n\n4. 移行テスト\u003Cbr>\nJira2Labは移行テストに対応しているため、大規模な移行を行う前に設定やワークフローをテストできます。テストを通じてあらゆる問題を早期に発見しておくことで、移行全体を中断することなく進められます。\n\n5. リアルタイムモニタリング\u003Cbr>\nJira2Labは、移行中のリアルタイムでのモニタリングとログ生成に対応しています。これらを活用することで、完全な透明性が確保され、すべてのステップがエラーなく正確に実行されていることを確認できます。\n\n6. 柔軟かつカスタマイズ可能\u003Cbr>\nJiraインスタンスに独自の設定やワークフローがある場合でも、Jira2Labは独自の要件に従って移行をカスタマイズできる柔軟性を備えているため、移行中に何かが失われることはありません。\n\n### JiraとGitLabの機能比較\n\nJiraからGitLabに移行することで、ワークフローの統合に加え、GitLab固有の高度な機能を利用できるようになります。各プラットフォームの主な機能を簡単に比較してみました。\n\n| **機能**             | **Jira**                        | **GitLab**                    |\n|-------------------------|----------------------------------|-------------------------------|\n| **イシュートラッキング**       | はい（高度にカスタマイズ可能）       | はい（DevSecOpsに統合されている）   |\n| **アジャイルボード**         | はい（Kanban、Scrum）             | はい（イシューボード、マイルストーン） |\n| **CI/CD**                | いいえ（外部ツールが必要）    | はい（ビルトインのCI/CD）           |\n| **ソース管理**       | いいえ（GitHub／Bitbucketが必要）  | いいえ（ネイティブGitサポート）       |\n| **DevSecOpsツール**         | 統合に制限あり            | DevSecOpsライフサイクル全体          |\n\nJira2Labでは、開発および運用に対するGitLabの統合されたアプローチが最大限に活用されており、イシュートラッキングからCI/CDパイプラインまで、すべての重要な要素をスムーズに移行可能です。\n\n## 移行方法\n\nJira2Labは、5段階からなる構造化された移行方法に基づき、中断を最小限に抑えてシームレスな移行を実現します。\n\n### 1. 調査と計画\n\nまずは、お客様のJiraの設定を十分に理解し、移行すべきすべてのカスタムワークフロー、フィールド、プロジェクトを特定します。この段階では、JiraとGitLabの機能を比較し、移行プロセスを細部まで計画するためのギャップ分析も行います。\n\n### 2. 設定\nこの段階では、移行ツールの設定に加え、JiraとGitLabの両方に必要な環境を設定します。移行開始前にすべての権限を確認し、Jiraデータのバックアップを設定する作業も、この段階で行います。\n\n### 3. 移行テスト\nデータセット全体を移行する前に、一部のプロジェクトで移行テストを実行して、移行プロセスやワークフロー、データの整合性をテストします。これにより、問題がある場合でも、プロセスの早い段階で特定して解決できます。\n\n### 4. 大規模な移行\n移行テストの結果を検証した後、全プロジェクトを対象に移行を行います。その際、ダウンタイムを最小限に抑え、開発チームがスムーズに移行を行えるようにします。\n\n### 5. 移行の完了および移行後のサポート\n移行完了後も、すべてのチームでGitLabを十分にご活用いただくために、引き続きサポートいたします。この段階では、ユーザートレーニングの提供に加え、必要な場合はJiraインスタンスの廃止も行います。\n\n## 事例：Jira2Labで大規模な移行に取り組む\n\nある大企業では最近、移行を実施する際に、50のプロジェクトにまたがる20,000件超のイシューをJiraからGitLabに移行する必要に迫られました。プロジェクトには高度にカスタマイズされたワークフロー、数千ものコメントや添付ファイルもあり、これらもすべて移行する必要がありました。\n\nJira2Labの活用により、以下を達成しました。\n\n- データを一切失うことなく、カスタムフィールドを含むすべてのデータを移行。\n- GitLab内にCI/CDパイプラインを設定したことで、移行後すぐにチームが作業を継続可能に。\n- 2つのプロジェクトで移行テストを実施することで、組織全体を対象に移行を進める前に、ワークフローの軽度の矛盾を特定して修正。\n\n結果として、大きなダウンタイムも発生することなく、全プロセスが予定していた期限内に完了し、GitLabへのシームレスな移行を実現できました。\n\n## Jira2Labを今すぐ利用する\n\nほかの移行ツールでは対応できない課題を解決できるJira2Labは、市場において注目を浴びています。大規模な移行に特化して設計されており、プロジェクト管理データのみを対象とする多くのツールとは異なり、GitLabのDevSecOpsライフサイクル全体と統合できます。カスタムワークフローのマッピング、およびCI/CDパイプラインの統合に対応するJira2Labは、GitLabへの移行時に開発ワークフローを強化したい企業にとって最適なソリューションです。\n\n> GitLabを使用した開発プロセスのスケーリングをご希望の場合は、GitLabの[プロフェッショナルサービスカタログ](https://about.gitlab.com/services/catalog/)をご覧ください。お客様が効率的かつ効果的に移行プロセスを進められるよう、当社チームで提供しているサポート内容をご紹介しています。GitLabによるJira2Labの個別デモをご希望の場合は、ページ下部のフォームからお問い合わせください。\n",[1389,110,702,678,701],{"slug":2711,"featured":92,"template":681},"seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","content:ja-jp:blog:seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","Seamlessly Migrate From Jira To Gitlab With Jira2lab At Scale","ja-jp/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","ja-jp/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"_path":2717,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2718,"content":2724,"config":2730,"_id":2732,"_type":16,"title":2733,"_source":17,"_file":2734,"_stem":2735,"_extension":20},"/ja-jp/blog/what-is-git",{"title":2719,"description":2720,"ogTitle":2719,"ogDescription":2720,"noIndex":6,"ogImage":2721,"ogUrl":2722,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2722,"schema":2723},"Gitとは？初心者に使い方、意味、機能、利点を徹底解説","Gitとは？管理部門やオペレーション部門、初心者には知られていないGitの基礎知識を、仕組みから利点、基礎用語、よくある質問まで徹底的に解説。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687231/Blog/Hero%20Images/Git.jpg","https://about.gitlab.com/blog/what-is-git","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Gitとは？初心者に使い方、意味、機能、利点を徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-10-08\",\n      }",{"title":2719,"description":2720,"authors":2725,"heroImage":2721,"date":2726,"body":2727,"category":962,"tags":2728,"updatedDate":2729},[671],"2024-10-08","## 目次\n- Gitとは何か？ \n- Gitの意味\n- Gitは何に使われている？\n- Gitの利点とは？\n- Gitの何がすごい？\n- 組織がGitを使ってできること \n- Gitの用語と使い方の初心者向け解説\n- Gitの弱点は？\n- Gitの管理はツールで手軽に \n- まとめ \n\nGit（ギット）という言葉をエンジニアや開発者が口にするのを耳にしたことがある方は多いはずです。プロジェクトを走らせながらツールやサービスの改善を行う[アジャイル手法](https://about.gitlab.com/ja-jp/topics/agile-delivery/agile-methodology/)が基本の今、業務効率化のためにGitを使用するのは当たり前となってきました。ただ、IT関連企業だったとしても、マネジメントやオペレーション部門などで働く非エンジニアや初心者は、Gitとは何か、なぜ世界で広く使われているのか、その理由を明確には理解していないかもしれません。\n\nしかし、Gitは開発部門だけではなく、チーム内の複数のメンバーが同時に作業を行う場合（たとえば人事部門で社外の専門家に相談しながら社則の見直しと刷新を行う、デザイン部門でブランドロゴのデザインを行うなど）にも、とても便利なツールです。また、プロジェクトの大きさや用途によっては、ノーコスト／ローコストで導入を[お試しできる点](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)も見逃せません。\n\nこの記事では、初めてGitに触れる方のために、Gitとは何か、組織にとってどんな利点があるのかを詳しく解説していきます。\n\n## Gitとは何か？\n\nGitとは、分散型バージョン管理システムで、ファイルのバージョン管理が簡単にできるツールです。「文書作成アプリケーションでも変更履歴を保存して表示できるし、それとどう違う？」「分散型バージョン管理システムっていったい何？」といった疑問も浮かぶことでしょう。この疑問については後ほど詳しく説明します。\n\n## Gitの意味\n\nそもそもGitとは「Global Information Tracker（グローバルインフォメーショントラッカー）」の頭文字を取っていると言われています。つまり、Gitは包括的（Global）に変更履歴情報（Information）の追跡（Tracker）を行うツールという意味です。\n\nここで注目しておきたいのは「包括的」という言葉です。文章作成ソフトの変更履歴と違い、ただ単にバージョン履歴を保存するだけではない点です。\n\n## Gitは何に使われている？\n\nGitはファイルやコードのバージョン管理に使われます。バージョン管理システムとは、その名のとおりファイルやコードなどの変更（バージョン）を管理するシステムであり、チーム全体での調整、共有、コラボレーションを容易にします。\n\nあるファイルを作成した後、時間が経つにつれ変更点が複雑になり、ファイルの本筋がどこにあるのかわかりにくくなることがあります。たとえば、ミーティングの議事録について考えてみましょう。議事録をプロジェクトチームに共有し、欠席者がその内容について質問コメントを残し、ある人が補足情報を足し、別の人が会議中生じた確認事項を追記し、また別のある人が補足情報の一部を削除する。このように複数の関係者が何度も編集することで各時点で実施された変更を正確に把握することは難しくなっていきます。\n\n![迷路化したバージョンの中心にGitLabのアイコン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/version-control.svg)\n\nバージョン管理システムは、ファイルのすべての変更を追跡し、以前のバージョンに戻ってシームレスに共同作業できるようにする非常に便利なツールです。\n\n### Gitの機能とは\n\nGitを含むバージョン管理システムには、主に次の3つの機能があります。\n\n1. ファイル共有：チーム内でファイルを共有\n2. ファイル同期：変更点を同期\n3. ファイルバックアップ：変更点を保存\n\nまた、バージョン管理システムの種類には、次の2つがあります。\n1. 中央集中型管理システム：Subversion（SVN）、Concurrent Version System（CVS）\n2. 分散型管理システム：Git、Mercurial、Bazaar、Fossil\n\n## Gitの利点とは？\n\nそれでは、Gitのような分散型管理システムの利点は何でしょうか？それを理解するために、まず2つのバージョン管理システムの仕組みを説明します。\n\n### 中央集中型バージョン管理システムの仕組み\n\n中央集中型バージョン管理システム（CVCS）では、すべてのバージョンを1つのサーバーに格納します。プロジェクトメンバーはそのサーバーにアクセスしてファイルを更新します。ある人が更新を行っている場合、他の人はそのファイルで作業できません。基本的に作業はオンラインで行い、変更点はサーバーによってきちんと保存およびカタログ化されます。このシステムはいたってシンプルであり、変更を管理する方法が簡単であるため、チームの規模が小さい場合に有効です。しかし、編集作業自体が複雑になってしまうため、更新を行ったメンバー同士の衝突が起こる場合もあります。\n\n### 分散型バージョン管理システムの仕組み\n\n一方、Gitのような分散型バージョン管理システム（DVCS）の利点は、柔軟性の高さです。分散型では、ファイルをサーバーで一元管理するだけに終わりません。 各プロジェクトメンバーはプロジェクト履歴全体をローカルに保持して、オフラインで作業できます。その作業結果を確認後、サーバーにアップすると、サーバー上でバージョンの保存およびカタログ化が行われます。したがって、中央集中型バージョン管理システムよりも、多様なバージョンの分岐ができ、またバージョンのマージ（結合）も容易になります。\n\n### 時代にフィットするGit\n\nハイブリッドやリモートなどさまざまな働き方が当たり前となった昨今、Gitのような分散型バージョン管理システムの柔軟性は、複数のプロジェクトを走らせたり織り交ぜたりするダイナミックなチームにとって不可欠な存在となっています。両者の違いを表で確認しましょう。\n\n| バージョン管理システム名 | 利点 |\n| :---- | ----- |\n| 中央集中型（CVCS） | ・小・中規模なチーム向き ・作業は基本的にオンラインで行う ・すべてのバージョンを1つのサーバーに ・管理がシンプル |\n| 分散型（DVCS） Gitほか | ・大規模のチームにも対応 ・プロジェクト履歴を各メンバーがローカルに保持 ・オフラインで作業できる ・より優れたアイディアが公平に取り入れられやすい ・柔軟性が高い ・バージョンの分岐やマージが簡単 |\n\n## Gitの何がすごい？  \n分散型バージョン管理システムの優れた点を説明してきましたが、Gitを使うメリットは、ずばり「開発業務の効率が上がること」です。プロジェクトメンバーが同時に作業でき、プログラムの共有を容易に行えるため、管理しやすいのです。また、開発過程で修正点やバグへの対処が必要となるのはよくあることですが、その際も管理されたバージョン履歴をたどって迅速に原因の特定ができます。そのため、迅速に対処できるのです。\n\n## 組織がGitを使ってできること\n\nここで改めてGitを導入してできることを具体的に挙げてみます。\n- 新旧のバージョンを一元管理できる\nGitを使うことで、ファイルの新旧を一元的に管理できます。変更をした際、いちいちファイル名に日時や「.V2」などの名前を付け、どのファイルが新しいのか見分けがつくようにする手間がなくなります。\n\n- 古いバージョンに簡単に戻ることができる\n作業途中に「前のほうが良かった」と旧バージョンに戻りたくなっても、Gitを使っていれば簡単に古いバージョンにさかのぼることができます。\n\n- ファイルや変更履歴をスムーズに共有できる\n作業者同士で直接ファイルをやりとりする必要がないため、バージョンの混乱も反映までの時差も発生しません。\n\n- チームでの共同開発を効率化できる\nGitなら、チームは変更を簡単に追跡できるため、さまざまなバージョンの追跡やマージに時間を費やすことなく、目の前のタスクに集中できます。また、オフラインで作業してローカルに保存するため、中央集中型よりも速いスピードで作業できます。\n\n- ノーコスト／ローコストで導入のお試しができる\nGitは世界で最も広く使用されているバージョン管理システムであり、事実上の業界標準です。したがって多くの人気開発者ツールでサポートされており、無料で利用できるリソースも多数あります。\n\n## gitの用語と使い方の初心者向け解説\n\nGitの使い方と、どのような用語を使用するか、初心者が理解しやすいように表組にまとめてみました。\n\n- 場所の名前\n\n| 場所 | 定義 |\n| :---- | :---- |\n| リポジトリ | ファイルや変更履歴を保存しておくデータベース。リポジトリには2種類ある。 ローカルリポジトリ（ローカル上）：ローカル環境で作業を行う際に使う。 リモートリポジトリ（ネットワーク上）：他のユーザーとファイルや変更履歴を共有する際に使う。 |\n| インデックス | リポジトリ（保存場所）とワークツリー（作業場所）の間の中間領域。ローカルで作業したファイルをリポジトリに保存するには、インデックスにいったん置く必要がある。 |\n| ワークツリー | ユーザーが編集している作業中のディレクトリのこと。 |\n\n- アクションとコマンド\n\n| アクション | 定義 | コマンド |\n| :---- | :---- | :---- |\n| クローン | リモートリポジトリのコミットを、ローカルリポジトリへ丸ごとコピーすること。 | git clone \\[リポジトリパス\\] |\n| コミット | リポジトリへファイルや変更履歴を登録することを指す。 | git commit \\[コミット名\\] |\n| プッシュ | 登録した変更（コミット）をローカルからリモートリポジトリへ反映させることを指す。 | git push |\n| ブランチ | 変更履歴を分岐することを指す。作成された分岐はブランチと呼ばれる。 | git branch |\n| マージ | 複数のブランチを一つにまとめること。 | git merge |\n| プル | リモートリポジトリのコミットをローカルリポジトリへと引っ張ってくることを指す。 |   git pull |\n| フェッチ | リモートリポジトリからファイルの最新情報を取得してくること。プルとは違い、ローカルのファイルは更新されない。 | git fetch \\[リポジトリ\\] |\n\n## Gitの弱点は？\n\nこのように便利でさまざまな利点があるGitですが、弱点もあります。\n\n- Gitの操作方法は非エンジニアにはなじみがない\n「Gitがそんなに便利なら、なぜマネジメントやオペレーション側にあまり浸透していないのだろう」という疑問も生まれるでしょう。しかしGitをそのまま使う場合、基本的にCUIという文字によるコマンドの打ち込みでコンピューターと対話する操作手法が必要です。PCが不調でシステムをセーフモードで起動した経験はないでしょうか（文字列だけの暗い画面が立ち上がります）。あるいはエンジニアが暗い画面にコードを表示して作業している様子を想像してみましょう。普段コマンドやコードに縁がない人にとってはハードルが高い操作方法と言えます。\n\n- Gitの学習には時間が必要\nGitを導入する際、プロジェクトチームは全員がGitを使えるようになる必要があります。用語も独特であり、また、各メンバーがローカルで作業するため、運用ルールを決めておかないと混乱する可能性があります。慣れるまでに学習時間が必要であるため、使用頻度がそこまで高くない場合、学習にかかる時間的コストの費用対効果が疑問視されることもあります。\n\n## Git管理はツールで手軽に\n\nこのようなGitの弱点を一挙に解決するのが、Gitにユーザーフレンドリーなインターフェイスを組み込んだ管理ツールです。管理ツールを使えば、コマンドを打ち込んで操作するのではなく、日常使っているアプリケーションのようにマウスでクリックして操作できるため、Gitの多数のメリットを組織にスムーズに取り入れられます。\n\nGit管理ツールを導入すると次のようなメリットがあります。\n\n- Gitを使うためにコマンドを覚える必要がない  \n- Gitを学習する時間が短縮できる  \n- エンジニア以外でもGitを使えるようになる\n\nGit管理ツールにはさまざまな種類がありますが、開発スピードを確保しつつセキュリティも高めたい組織が選んでいるのは、GitLabです。\n\nGitとGitLab。名前が似ているのは、GitLabが[Gitを使ったDevSecOpsプラットフォームサービス](https://about.gitlab.com/ja-jp/platform/)だからです。\n\n![GitLabのアイコンとロゴ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/gitlab-logo-150.jpg)\n\nGitLabはバージョン管理システムであるGitを中心に、開発（Dev）セキュリティ（Sec） オペレーション（Ops）のすべてをこなせるプラットフォームであり、アイコンやボタンなどのグラフィックを使用して視覚的に操作できるグラフィカルユーザーインターフェイスを採用しているため、Gitの弱点を克服できます。\n\n当然、先ほど挙げたGit管理ツールのメリットを享受できますが、それだけではありません。計画から本番まで、DevSecOpsのあらゆる機能が1つのアプリケーションにまとまっているため、プロジェクトにかかわる各部署の連携が強化され、チームにまとまりが生まれます。\n\nGitLabの「非エンジニアを含む各部門がGitを使用でき、情報を統一的に集約して管理しやすいツール」という面は、他にはない特徴です。\n\nまとめると、GitLabには次のような特徴があります。\n\n* ツールチェーンを簡素化できる\n\n  重要な[DevSecOpsツール](https://about.gitlab.com/ja-jp/platform/)がすべて1つのプラットフォームに集約されています。\n\n* ソフトウェアデリバリーを高速化できる\n\n  オートメーション、[AIを活用したワークフロー](https://about.gitlab.com/ja-jp/gitlab-duo/)が提供されています。\n\n* セキュリティを統合できる\n\n  セキュリティは[デフォルトでビルトイン](https://about.gitlab.com/ja-jp/solutions/security-compliance/)されており、追加は不要です。\n\n* どこにでもデプロイできる\n\n  複数のクラウドにコンピューティングを分散するマルチクラウドアプローチが行えます。\n\n* Freeプランでノーコストでのお試し導入ができる\n\n  [無料試用版](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/devsecops/&glm_content=default-saas-trial)をクレジットカードの登録なしで使用開始できます。\n\n![AIの助けで時間短縮](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/homepage-image.png)\n\n開発のスピード向上を計りたい＋包括的なセキュリティ対策を重要視したいという組織に、GitLabは最適です。\n\n[GitLab公式サイト](https://about.gitlab.com/ja-jp/)\n\n## まとめ \n\nここまで、組織のマネジメントやオペレーション部門などで働く非エンジニアや初心者向けに、Gitとは何か、おさえておくべき基礎知識、仕組み、用語をご紹介しました。Gitの概要を把握しておくことで、導入を検討する際の一助になれば幸いです。\n\nこれほど利便性が高いGitですが、開発（Dev）セキュリティ（Sec） オペレーション（Ops）プラットフォームであるGitLabの、ほんの一部の機能にすぎません。すべてをこなせるDevSecOpsプラットフォームの力強さに興味がある方は、ぜひ30日間無料トライアルでGitLabを体感してみてください。\n\n> [GitLab Ultimateの無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)を始めましょう\n\n\u003Cbr>\u003Cbr>\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[966,825],"2024-12-26",{"slug":2731,"featured":92,"template":681},"what-is-git","content:ja-jp:blog:what-is-git.yml","What Is Git","ja-jp/blog/what-is-git.yml","ja-jp/blog/what-is-git",{"_path":2737,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2738,"content":2744,"config":2749,"_id":2751,"_type":16,"title":2752,"_source":17,"_file":2753,"_stem":2754,"_extension":20},"/ja-jp/blog/event-report-devopsdive2024summer",{"title":2739,"description":2740,"ogTitle":2739,"ogDescription":2740,"noIndex":6,"ogImage":2741,"ogUrl":2742,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2742,"schema":2743},"DevOpsDive2024 Summerで、ソフトウェア開発におけるセキュリティを考える【イベントレポート】","2024年6月12日に開催した「GitLab DevOpsDive2024 Summer」のイベントレポートをお届けします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665902/Blog/Hero%20Images/heroimage_devopsdive.jpg","https://about.gitlab.com/blog/event-report-devopsdive2024summer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOpsDive2024 Summerで、ソフトウェア開発におけるセキュリティを考える【イベントレポート】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-10-07\",\n      }",{"title":2739,"description":2740,"authors":2745,"heroImage":2741,"date":2746,"body":2747,"category":740,"tags":2748},[738],"2024-10-07","2024年6月12日、GitLabはGINZA SIXの地下にある観世能楽堂において国内で3回目のプライベートイベント「DevOpsDive2024 Summer」を開催しました。本イベントは、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)／[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にかかわる人々が集い、集合知を作りたいという思いでスタート。今回のテーマは「ソフトウェア開発におけるセキュリティを考えよう」に設定しました。能楽専門の公演場を会場に、登壇者が足袋を履いて能舞台で話をするという演出は、デベロッパー界隈を少し賑わしたようなので、イベントがあったことを知っている読者の皆様もいらっしゃるかもしれません。このブログでは、当日の模様をお伝えします。\n\n## シフトレフトでサイバー攻撃に立ち向かう\n\nこの日は、6月ながら都内で気温が30度を超える真夏日になりました。アイスブレイクに登壇した川口 修平は、「暑い中、激アツなイベントへようこそ」と会場を沸かせ、「終了後の懇親会ではオリジナルビールで乾杯しましょう！」と呼びかけました。ビールは[GitLabのイシュー](https://docs.gitlab.com/ee/user/project/issues/)を使って醸造所の担当者とやり取りしながら作り上げたものです。\n\n*![商品名：Gitlab Hazy Gen3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/instagram.jpg)\n[イシューを使って作り上げたビールの紹介（Instagram）](https://www.instagram.com/p/C8bZdKEylKM/?utm_source=ig_web_copy_link&igsh=MzRlODBiNWFlZA==)*\n\nこのように親しみやすい雰囲気で始まったイベントですが、日本において[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)はまだまだこれから。実際に、『DX白書』でも北米の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)利用率52.9％に対し、日本は9.3％にすぎません。このギャップを埋めるためには、サイバーセキュリティの現状を正しく理解し、それと対峙するためのソフトウェア開発について考えておく必要があります。\n\n1人目の登壇者となった[タニウム合同会社 ](https://www.tanium.jp/)Chief IT Architect 楢原 盛史氏は、「見えないものは守れません」と話します。現在、私たちが直面している主な脅威はランサムウェアとサプライチェーン攻撃で、脅威は脆弱性のある場所を起点に忍び込んできます。\n\n> 全社で1万台のPCを使っている企業は、平均20％が管理されていない“野良端末”であると言われています。そして、攻撃者はここを狙ってくるのです。\u003Cbr>\n> （楢原 盛史氏）\n\n![DSC4331](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4331.jpg)\n*タニウム合同会社 Chief IT Architect 楢原 盛史氏*\n\n同氏は、サイバー攻撃の対象は組織が管理するハードウェアにインストールされたすべてのソフトウェアであり、中でもセキュリティ対策が万全でない自社開発のソフトウェア、およびそれに組み込まれたOSSが狙われやすいと指摘します。実際に、OSSコードベースの80％に脆弱性が含まれると言われており、ソフトウェア・サプライチェーン攻撃では、主に[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインが狙われます。\n\n実際に、昨今は大企業が攻撃されて被害に遭ったニュースが数多く報じられています。私たちは、被害者の金銭的損害や株価の暴落を目にしていますし、医療機関への被害は生命を危うくする事態に直結します。経営もこれらの事態を深刻に受け止めていますから、セキュリティへの投資はホットな話題になってきました。\n\nとはいえ、ほぼすべてのシステムはネットワークと切り離すことができません。完全に切り離されたシステムであっても、ファイルやデータのインポートを通じて外部と全く情報をやり取りしないことはないでしょう。実用性を重視する以上、完全なセキュリティを保つのは事実上不可能であると言っていいかもしれません。\n\nその中で、脅威に立ち向かうためには、シフトレフトの原則が大切になります。米国家情報長官室（ODNI）は、DevSecOpsが重要だと通達し、取り組みの必要性を強調しています。日本でも、デジタル庁が『セキュリティ・バイ・デザインガイドライン』を発行しました。そこでは、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)がセキュリティ品質を底上げできると明記されています。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)でセキュアな開発ライフサイクルを実現し、高速かつ頻繁なテストサイクルを回すことが、セキュリティを担保するひとつの答えになるのです。\n\n## 責任を自分に集中させて仕組みを作り、その後に分散する\n\n![DSC4608](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4608.jpg)\n*左よりCloudflare Japan株式会社 エバンジェリスト 亀田治伸氏、くら寿司株式会社 執行役員 DX本部長 中林 章氏、GitLab合同会社カントリーマネージャー小澤正治*\n\nイベントの後半は、3者の鼎談セッションになりました。[GitLab Japan](https://about.gitlab.com/ja-jp/) Country Manager小澤 正治をモデレーターに、[くら寿司株式会社](https://www.kurasushi.co.jp/) 執行役員 DX本部長 中林 章氏、および[Cloudflare Japan株式会社](https://www.cloudflare.com/ja-jp/) エバンジェリスト 亀田 治伸氏が登壇。話題は、くら寿司の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)推進事例が中心になりました。\n\nくら寿司は、数ある回転寿司チェーンの中で、技術への投資による業務効率化を率先して実行してきた企業です。たとえば、食べ終えたお皿を自動的に洗い場まで流す仕組みである「水回収システム」を業界で初めて開発したことは有名で、寿司ロボットをいち早く回転寿司で導入するなど、その後も技術投資を続けて様々な作業工程の自動化とおいしさを追い求めています。デジタル投資にも積極的で、「くら寿司ならでは」のDXを推進中。様々なタッチポイントから流入する予約システムや、店舗のタッチパネル型オーダーシステムなどの強化／開発を進めています。現在は、「お客様サービスと事業活動のリアルタイム連携」を目指すフェーズにあります。\n\nただ、同社はそこに至るまでに本質的な課題を抱えていました。中林氏は、「プロセスが整備されておらず、成果物の紐づけ管理が不十分でした」と話します。戦略会議が2週間ごとに開催されるため、開発サイクルはそれに合わせる必要があります。開発プロセスを統合管理することも必要で、要件定義書やスケジュール、ソースコードのレポジトリといったすべての成果物および中間成果物を必要な人が必要なタイミングで入手できる環境を整える必要もありました。\n\n![DSC4593](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4593.jpg)\n*くら寿司株式会社 執行役員 DX本部長 中林 章氏*\n\nこの状況を抜本的に解決するために、中林氏は[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)という文化を取り入れることを決断。[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)を採用し、他社とは一味違うDXに向けて進み始めます。多くのB2C企業は、顧客に会員登録してもらってロイヤルティを高めていく方向性で顧客戦略を考えます。一方、くら寿司はインバウンド顧客など一過性の顧客も大切にしなければなりません。そのため、ロイヤルティ向上施策と一見さん施策の両面で、多数のプロジェクトを同時並行し、スピード感をもって進められるようになりました。戦略会議で進捗報告し、新規施策の提案と承認、および新たなニーズの把握と共有を行うプロセスもGitLabで最適化。短期サイクルを実現するバックアップ体制も整えました。\n\nセキュリティについてはどうでしょう。中林氏は、「“セキュリティが担保されている”とはどのような状態なのでしょう。静的／動的検査をすればセキュリティが担保できるわけではないですよね。そこで、私たちはプロセス、ルール、成果物のすべてが正しく管理されていることが大切であるという結論に達しました」と話します。\n\n> 経営者にセキュリティを完璧に理解してもらうことは難しいものです。ですから、まず責任を自分に集中させて、仕組みを作りあげることが大切。そして、その後に破壊します。つまり、責任を分散するわけです。\u003Cbr>\n（中林 章氏）\n\n[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)は、この流れを実現できるプラットフォームです。ビジネスにおけるバックログを記録しておけば、それを部門や現場がプロダクトのバックログとして認識できます。要件定義書からスケジュール、ソースコードまで、すべてを一元的に管理できるGitLabがあれば、経営と現場をつなぐことができるのです。さらに、プロセスの中にセキュリティを担保する仕組みを組み込み、業務の中でセキュリティをチェック／実装できるようになります。\n\n![DSC4701](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4701.jpg)\n*Cloudflare Japan株式会社 エバンジェリスト 亀田 治伸氏*\n\n\u003Cbr>\n亀田氏は、くら寿司のリアルな現場の話を聞いて、次のような印象を持ったと語ります。\n\n> 多くの企業を見ていると、権限が属人化しているケースをよく見ます。スタートアップなどの少数精鋭組織ではそちらの方が合うのでしょうが、規模が大きくなると難しくなります。くら寿司さんが集中管理から分散管理へと移行させるやり方は理想的で、GitLabを使えば権限委譲をうまくやれることも体感的に理解できます。\u003Cbr> \n交通ルールを守れば、絶対に事故は起こりません。しかし事故は起きています。つまり、全員がまじめにルールを守らないのです。コンピュータが絡むデジタルにおいて、これは大きな教訓になりそうです。GitLabを使ってミスが起こりにくい仕組みを作ることが大切になるかもしれません。くら寿司さんはグローバル展開していますし、文化の違いも仕組み作りで乗り越えられる部分もあるでしょう。\u003Cbr>\n（亀田 治伸氏）\n\nくら寿司は、人々がデジタルに触れているタイミングをすべて機会としてとらえ、ビジネスに生かすという大きな目標に向かっています。グローバル展開を積極化させる中、セキュリティのルールが国・地域によって異なるという課題にも、すべての地域のメンバーが安心・安全に使えるデジタルを提供するという方向で一つひとつ解決しています。さらに、貴重なエンジニアを確保していけるような、楽しく働きやすい職場づくりを心がけ、エンジニアにとって心地よいカルチャーを育んでいきます。\n\nGitLabを使えば、経営と現場がつながり、グローバルでセキュリティを担保する仕組みが実現します。そしてGitLabは、風通しの良い文化の醸成にも寄与します。くら寿司はGitLabで多くの成果を得ながらDXを推進しています。GitLabを開発プラットフォームとしてビジネスを加速するくら寿司の今後にご注目ください。\n\n![DSC4937](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4937.jpg)",[280,1880,702,904],{"slug":2750,"featured":6,"template":681},"event-report-devopsdive2024summer","content:ja-jp:blog:event-report-devopsdive2024summer.yml","Event Report Devopsdive2024summer","ja-jp/blog/event-report-devopsdive2024summer.yml","ja-jp/blog/event-report-devopsdive2024summer",{"_path":2756,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2757,"content":2762,"config":2766,"_id":2768,"_type":16,"title":2769,"_source":17,"_file":2770,"_stem":2771,"_extension":20},"/ja-jp/blog/whats-new-in-git-2-47-0",{"title":2758,"description":2759,"ogTitle":2758,"ogDescription":2759,"noIndex":6,"ogImage":2291,"ogUrl":2760,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2760,"schema":2761},"Git 2.47.0の新機能","Gitの最新バージョンについてご紹介します。新たに追加されたグローバル変数を使用すれば、参照やオブジェクトのハッシュの形式を設定できます。GitLabのGitチームと、より広範なGitコミュニティによるコントリビュートをご確認ください。","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.47.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }",{"title":2758,"description":2759,"authors":2763,"heroImage":2291,"date":2746,"body":2764,"category":962,"tags":2765},[1205],"Gitプロジェクトは、最近[Gitバージョン2.47.0](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)をリリースしました。\n\nGitLabのGitチームやより広範なGitコミュニティからのコントリビュートを含む、本リリースの主なハイライトをご覧ください。\n\n\n## 新しいグローバル構成オプション\n\n\nGitの最新リリースをチェックしている方であれば、[Gitバージョン2.45](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)より新たに提供開始された「reftable」参照バックエンドについてご存知かもしれません。詳しくは、『[Git\nreftableフォーマットの入門ガイド](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)』をご確認ください。これまでは、「reftable」フォーマットを使用してリポジトリを初期化するには、次のようにgit-init(1)コマンドに`--ref-format`オプションを付けて実行する必要がありました。\n\n\n```sh\n\n$ git init --ref-format reftable\n\n```\n\n\nGit\n2.47のリリースでは、`init.defaultRefFormat`という設定オプションが追加され、リポジトリを初期化する際にどの参照バックエンドを使用するかをGitに指示できるようになりました。このオプションを使用することで、デフォルトの「files」バックエンドを上書きし、「reftable」バックエンドを利用できるようになります。設定するには、以下のコマンドを実行します\n\n\n```sh\n\n$ git config set --global init.defaultRefFormat reftable\n\n```\n\n\n一部の方はご存知かもしれませんが、Gitリポジトリで使用されるオブジェクトのハッシュ形式も設定可能です。デフォルトでは、リポジトリはSHA-1オブジェクト形式を使用するように初期化されますが、SHA-256形式というより安全で将来性のある代替案もあります。詳しくは、[GitalyにおけるSHA-256のサポートに関する過去のブログ記事](https://about.gitlab.com/blog/sha256-support-in-gitaly/#what-is-sha-256%3F)でご確認いただけます。SHA-256リポジトリは、git-init(1)に`--object-format`オプションを指定することで作成できます。\n\n\n```sh\n\n$ git init --object-format sha256\n\n```\n\n\nこのGitのリリースでは、別の設定オプションとして、`init.defaultObjectFormat`が追加されました。このオプションは、リポジトリを初期化する際に、どのオブジェクト形式をデフォルトで使用するかをGitに指示するものです。以下のコマンドで設定できます。\n\n\n```sh\n\n$ git config set --global init.defaultObjectFormat sha256\n\n```\n\n\n注意点として、SHA-256リポジトリはSHA-1リポジトリと互換性がなく、すべてのフォージがSHA-256リポジトリのホスティングをサポートしているわけではありません。先日GitLabが発表した[SHA-256リポジトリの実験的サポート](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/)をお試しになれます。\n\n\nこれらのオプションを使うことで、すぐにこれらのリポジトリ機能を使用できるようになり、新しいリポジトリを初期化するたびに形式について検討せずに済みます。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## git-refs(1)のサブコマンド\n\n\n前回のGitリリースでは、リポジトリ内の参照への低レベルアクセスを可能にするコマンド「[git-refs(1)](https://git-scm.com/docs/git-refs)」が導入されました。このコマンドには、参照バックエンド間での変換を行う「migrate」サブコマンドが含まれていました。今回のリリースでは、新たに「verify」サブコマンドが追加され、参照データベースの整合性を確認できるようになりました。リポジトリの整合性を確認する際には、「[git-fsck(1)](https://git-scm.com/docs/git-fsck)」を実行するケースが多々あります。\n\n\nしかし、このコマンドはリポジトリの参照データベースを明示的に検証するわけではありません。特に「reftable」というバイナリ形式の参照形式が導入されたことで、手動での検証が難しくなり、このギャップを埋めるツールの必要性が増しています。例として、無効な参照を設定したリポジトリを作成して検証してみましょう。\n\n\n```sh\n\n# The \"files\" backend is used so we can easily create an invalid reference.\n\n$ git init --ref-format files\n\n$ git commit --allow-empty -m \"init\"\n\n# A lone '@' is not a valid reference name.\n\n$ cp .git/refs/heads/main .git/refs/heads/@\n\n$ git refs verify\n\nerror: refs/heads/@: badRefName: invalid refname format\n\n```\n\n\nこの例では、無効な参照が検出され、エラーメッセージが表示されていることが確認できます。このツールはエンドユーザーが頻繁に使用するものではありませんが、サーバー側でリポジトリの整合性を保つために特に有用です。最終的には、このコマンドを「git-fsck(1)」に統合し、一貫したリポジトリ整合性チェックを行えるようにすることが目標です。\n\n\nこのプロジェクトは、Google Summer of Code（GSoC）の一環としてJialuo\nSheによって主導されました。詳しくは、Jialuoの『[GsoCレポート](https://luolibrary.com/2024/08/25/GSoC-Final-Report/)』をご参照ください。\n\n\n## reftableに関連した進行中の作業\n\n\n今回のリリースでは、「reftable」バックエンドに関するいくつかのバグ修正も含まれています。その中でも特に興味深いのは、テーブルの圧縮プロセスに関するバグです。\n\n\nご存知でない方のために説明すると、reftableバックエンドはリポジトリ内のすべての参照の状態を保持する一連のテーブルで構成されています。各参照のアトミックな変更が行われるたびに、新しいテーブルが作成され、「tables.list」ファイルに記録されます。テーブルの数を減らすために、参照の更新後には、テーブルがファイルサイズに基づいた幾何数列に従って圧縮されます。テーブルが圧縮されると、「tables.list」ファイルも更新され、ディスク上のreftableの最新の状態が反映されます。\n\n\n設計上、テーブルの書き込みと圧縮を同時に実行可能です。特定のタイミングでの同期は、ロックファイルを使用して制御されています。たとえば、圧縮が始まる際には、最初に「tables.list」ファイルが、安定した読み込みのためにロックされます。また、圧縮が必要なテーブルもロックされる場合があります。実際のテーブルの圧縮には時間がかかるため、ロックは途中で解除され、同時書き込みが実行されます。同時書き込みは、ロックされている圧縮対象のテーブルを変更してはいけないことを理解した上で行われるため、この処理は安全です。圧縮された新しいテーブルの書き込みが完了すると、再び「tables.list」ファイルがロックされ、今度は新しいテーブルの状態が反映されるように更新されます。\n\n\nしかし、次のような問題があります。もし、テーブルの圧縮中に最初のロックが解除された後、リストファイルが更新される前に、参照の同時更新によって新しいテーブルが「tables.list」に書き込まれたらどうなるでしょうか？このような競合が起こると、圧縮プロセスでは新しいテーブルの存在が認識されず、新しいテーブルを反映しないまま「tables.list」ファイルを書き直してしまいます。これにより、同時に行われた更新が失われ、参照が想定どおりに追加、更新、削除されない結果になる可能性があります。\n\n\n幸い、この問題は比較的簡単な手順で解決できます。圧縮プロセスで「tables.list」ファイルへの書き込みのためにロックが取得される際は、ファイルに更新があったかどうかを最初に確認してから、ファイルを再読み込みする必要があります。これにより、同時に行われたテーブルの更新も正しく反映されるようになります。こちらの修正について詳しくは、該当する[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1722435214.git.ps@pks.im/)をご参照ください。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## git-maintenance(1)の修正\n\n\nリポジトリが大きくなるにつれて、適切なメンテナンスが重要になります。デフォルトでは、Gitは特定のオペレーション後に[git-maintenance(1)](https://git-scm.com/docs/git-maintenance)を実行することで、リポジトリの健全性を保ちます。その際、不要なメンテナンスが行われないようにするために、`--auto`オプションが指定されています。このオプションでは、定義されたヒューリスティック（経験則）を使用してメンテナンスタスクを実行するかどうかを決定します。このコマンドは、さまざまなメンテナンスタスクを実行するように設定できますが、デフォルトでは、ユーザーが通常の作業を続けられるように、[git-gc(1)](https://git-scm.com/docs/git-gc)のみがバックグラウンドで実行されるようになっています。\n\n\nこの動作は通常、期待どおりに機能しますが、デフォルト以外のメンテナンスタスクを実行するように設定されている場合、設定されたメンテナンスタスクはフォアグラウンドで実行され、最初のメンテナンスプロセスはすべてのタスクが完了するまで終了しません。唯一「gc」タスクだけが期待どおりにバックグラウンドで実行されます。この原因は、git-gc(1)が`--auto`オプションで実行された際に、誤ってプロセスをデタッチしていたこと、また、ほかのメンテナンスタスクがそのような機能を持っていなかったことであると判明しました。この問題により、一部のGitコマンドが自動メンテナンスの完了を待機する必要があり、コマンドの実行速度が低下する可能性がありました。\n\n\n今回のリリースでは、git-maintenance(1)に`--detach`オプションが追加され、個々のタスクではなくgit-maintenance(1)全体のプロセスをバックグラウンドで実行できるようになったことで、この問題が解消されました。また、Gitが実行する自動メンテナンスもこの新しいオプションを使うように更新されています。こちらの修正について詳しくは、[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1723533091.git.ps@pks.im/)をご参照ください。\n\n\n前述したように、自動メンテナンスでは、特定のメンテナンス操作を実行すべきかどうかを判断するために一連のヒューリスティックが使用されます。しかし残念なことに、「files」参照バックエンドでは、[git-pack-refs(1)](https://git-scm.com/docs/git-pack-refs)が`--auto`オプションで実行された場合、このようなヒューリスティックが存在せず、疎な参照が必ず「packed-refs」ファイルにパック化されてしまいます。多くの参照を持つリポジトリでは、「packed-refs」ファイルの書き換えに時間がかかることがあります。\n\n\n今回のリリースでは、「files」バックエンドで疎な参照をパック化するかどうかを決定するヒューリスティックも導入されました。このヒューリスティックは、既存の「packed-refs」ファイルのサイズとリポジトリ内の疎な参照の数を考慮します。「packed-refs」ファイルが大きくなるほど、参照のパック化が実行される前に許容される疎な参照の数のしきい値も上がります。これにより、「files」バックエンドでの参照のパック化をやや抑制しつつ、適切にリポジトリがメンテナンスされた状態を保てます。詳しくは、[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1725280479.git.ps@pks.im/)をご参照ください。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## コードリファクタリングと保守性の向上\n\n\n機能の変更に加えて、コードリファクタリングやクリーンアップも進められています。これらの改善は、プロジェクトの内部コンポーネントをライブラリ化するという長期的な目標にも寄与するという点でも重要です。ライブラリ化に関する最新のアップデートについては、[こちらのスレッド](https://lore.kernel.org/git/eoy2sjhnul57g6crprxi3etgeuacjmgxpl4yllstih7woyuebm@bd62ib3fi2ju/)をご参照ください。\n\n\nメモリリークを解決することも、求められていた改善事項でした。Gitプロジェクトには多くのメモリリークが存在しますが、通常Gitプロセスは短時間しか動作せず、システムによるクリーンアップが後から行われるため、大きな問題が生じることはあまりありません。しかし、ライブラリ化を進める上では、この問題に対処する必要があります。リークサニタイザを使ってプロジェクト内のテストをコンパイルし、リークを検出することはできますが、既存のリークが存在しているために、新しい変更が新たなリークを引き起こしていないかを検証し、それを阻止するのは難しい状況でした。現在、プロジェクト内の既存のテストで検出されたすべてのメモリリークを修正する取り組みが進められています。リークのないテストは`TEST_PASSES_SANITIZE_LEAK=true`とマークされ、今後もリークが発生しないことが想定されます。今回のリリース以前は、プロジェクトにメモリリークを含むテストファイルが223件ありましたが、今回のリリースでは60件にまで減少しました。\n\n\nもう1つの取り組みとして、プロジェクト全体でグローバル変数の使用を減らす作業が進められています。その中でも特に問題視されているのが`the_repository`というグローバル変数で、これはオペレーション中のリポジトリの状態を保持し、プロジェクト内のさまざまな箇所で参照されています。今回のリリースでは、この`the_repository`の使用を減らし、必要な場所に直接値を渡すようにするための複数のパッチが導入されました。まだ`the_repository`に依存しているGitプロジェクトのサブシステムでは、このグローバル変数を使用できるようにするために`USE_THE_REPOSITORY_VARIABLE`が定義されています。現在ではrefs、config、pathのサブシステムはこの変数に依存しなくなりました。\n\n\nこのプロジェクトは、[John Cai](https://gitlab.com/jcaigitlab)と[Jeff\nKing氏](https://github.com/peff)の協力のもと、[Patrick\nSteinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## 補足情報\n\n\nこのブログ記事では、GitLabや広範なGitコミュニティによる最新リリースへのコントリビュートの一部をご紹介しました。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)では、さらに詳しい情報をご覧になれます。また、[過去のGitリリースに関するブログ記事](https://about.gitlab.com/blog/tags/git/)では、GitLabチームメンバーによるこれまでの主要なコントリビュートをご紹介しています。\n\n\n- [Git\n2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)\n\n- [Git\n2.45.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)\n\n- [Git\nreftableフォーマットの入門ガイド](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)\n\n- [git fetchとgit\npullコマンドの違いとは？](https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference/)\n",[966,825,270],{"slug":2767,"featured":92,"template":681},"whats-new-in-git-2-47-0","content:ja-jp:blog:whats-new-in-git-2-47-0.yml","Whats New In Git 2 47 0","ja-jp/blog/whats-new-in-git-2-47-0.yml","ja-jp/blog/whats-new-in-git-2-47-0",{"_path":2773,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2774,"content":2780,"config":2785,"_id":2787,"_type":16,"title":2788,"_source":17,"_file":2789,"_stem":2790,"_extension":20},"/ja-jp/blog/partner-sbcands",{"title":2775,"description":2776,"ogTitle":2775,"ogDescription":2776,"noIndex":6,"ogImage":2777,"ogUrl":2778,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2778,"schema":2779},"GitLabとSB C&S社の協力 – 成果と今後の展望","SB C&S社はGitLabのプロモーション、導入支援、技術トレーニングなどを通じて、GitLabの国内市場での普及に大きく貢献しています。この記事では、SB C&S社との協力を通じて得られた成果や、今後の展望について詳しくご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666029/Blog/Hero%20Images/AdobeStock_321783986.jpg","https://about.gitlab.com/blog/partner-sbcands","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabとSB C&S社の協力 – 成果と今後の展望\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"}],\n        \"datePublished\": \"2024-10-04\",\n      }",{"title":2775,"description":2776,"authors":2781,"heroImage":2777,"date":2782,"body":2783,"category":700,"tags":2784},[1385],"2024-10-04","GitLabは、世界中の多くの企業や開発者に利用される[DevOpsプラットフォーム](https://about.gitlab.com/ja-jp/topics/devops/)です。その成功には、優れたパートナーシップが重要な役割を果たしています。日本市場において、特に注目すべきは、SB C&S社との協力関係です。SB C&S社はGitLabのプロモーション、導入支援、技術トレーニングなどを通じて、GitLabの国内市場での普及に大きく貢献しています。この記事では、SB C&S社との協力を通じて得られた成果や、今後の展望について詳しくご紹介します。\n\n### SB C&S社による技術情報の提供\n\nSB C&S社が運営する「[DevOps Hub](https://licensecounter.jp/devops-hub/)」（外部サイト）は、GitLabをはじめとする多くの開発ツールに関する豊富な情報を提供するプラットフォームです。特に、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)や[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)といった現代の開発環境において重要なテーマについても深く掘り下げた記事が多く掲載されており、企業や個人開発者にとって有用なリソースとなっています。\n\n例えば、[GitLab SaaSの活用](https://licensecounter.jp/devops-hub/blog/gitlab-saas/)（外部サイト）に関する記事では、企業がGitLabを効率的に利用してCI/CDパイプラインを最適化するための方法が紹介されています。また、[AnsibleやGitLabを使用したインフラ自動化のケーススタディ](https://licensecounter.jp/devops-hub/blog/devops2ansible-gitlab/)（外部サイト）など、実際のビジネス環境で活用できる具体的なノウハウも提供されています。\n\nこれらの情報は、特にGitLabのような[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)ツールの導入を検討している企業にとって有益であり、導入に向けた判断材料となっています。GitLabとしても、このような実践的かつ技術的な情報提供を行うSB C&S社の取り組みを高く評価しています。\n\n### オンラインイベントでの協力\n\nSB C&S社との協力は、ブログ記事や技術解説にとどまりません。2024年に開催された一連のWebinarやイベントでは、SB C&S社の協力により、多くのリセラーやお客様にGitLabの機能や活用方法を紹介する機会を得ました。\n\n例えば、[2024年2月のWebinar](https://licensecounter.jp/devops-hub/info/event/gitlab-202402/)（外部サイト）では、GitLabの特徴を紹介するショートセミナーを実施しました。このWebinarは後日録画配信も行われ、参加できなかった方々にも情報を提供することができました。\n\nまた、[2024年6月のオンデマンドWebinar](https://licensecounter.jp/devops-hub/info/event/gitlab-on-demand-202406/) （外部サイト）や、[2024年9月のオンデマンドイベント](https://licensecounter.jp/devops-hub/info/event/gitlab-on-demand-202409/)（外部サイト）では、GitLabの最新機能や実践的な活用方法について情報を提供しました。これらのイベントは、技術解説だけでなく、実際のビジネス課題への対応方法も示す場となり、多くの企業にとって有益な機会となりました。\n\n### リアルイベント出展での協力\n\nGitLabが出展するイベントにおいても、SB C&S社は重要な役割を担っています。イベントブースでは、SB C&S社のスタッフがGitLabの活用方法や[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)のベストプラクティスについてのショートセミナーを実施しました。これらのセッションは参加者から好評を得ており、特にGitLabの高度な機能をわかりやすく解説する内容が注目されました。\n\nイベント後も、SB C&S社は参加者からの質問対応や追加資料の提供などのフォローアップを行っています。これにより、GitLabを活用した[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)導入の効果やメリットについて、多くの企業の理解が深まっています。\n\n### 今後の展望\n\nGitLabとSB C&S社のパートナーシップは、これまで多くの成果を生み出してきましたが、今後もさらなる展開が期待されます。両社は引き続き協力しながら、GitLabの持つ可能性をより多くの企業に伝え、開発プロセスの効率化やビジネスの成長を支援していく予定です。\n\n特に、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)や[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の重要性が増す現代において、SB C&S社が提供する技術解説やイベントは、企業にとって貴重な情報源となっています。今後も技術的な進化を追求しながら、より良いサービスの提供を目指します。\n\nGitLabとSB C&S社は、今後も協力関係を深め、新たな課題にも共に取り組んでいきます。日本企業のデジタル変革と競争力強化に向けて、両社の連携がさらなる価値を生み出すことを期待しています。\n",[285],{"slug":2786,"featured":92,"template":681},"partner-sbcands","content:ja-jp:blog:partner-sbcands.yml","Partner Sbcands","ja-jp/blog/partner-sbcands.yml","ja-jp/blog/partner-sbcands",{"_path":2792,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2793,"content":2799,"config":2804,"_id":2806,"_type":16,"title":2807,"_source":17,"_file":2808,"_stem":2809,"_extension":20},"/ja-jp/blog/partner-networld",{"title":2794,"description":2795,"ogTitle":2794,"ogDescription":2795,"noIndex":6,"ogImage":2796,"ogUrl":2797,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2797,"schema":2798},"Networld社への感謝と情報提供サービスのご紹介","この記事では、GitLabのディストリビューターとして日本市場における当社製品の普及と成長に重要な役割を果たしてくださっているNetworld社様をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666363/Blog/Hero%20Images/resize_AdobeStock_591239427.jpg","https://about.gitlab.com/blog/partner-networld","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Networld社への感謝と情報提供サービスのご紹介\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"}],\n        \"datePublished\": \"2024-10-02\",\n      }",{"title":2794,"description":2795,"authors":2800,"heroImage":2796,"date":2801,"body":2802,"category":700,"tags":2803},[1385],"2024-10-02","GitLab Japanチームを代表して、Networld社様に感謝申し上げます。Networld社様は、GitLabのディストリビューターとして日本市場における当社製品の普及と成長に重要な役割を果たしてくださっています。\n\nNetworld社様は製品の流通だけでなく、技術力と市場理解を活かし、リセラー様やエンドユーザー様向けの幅広いサポートを行っています。特に、Networld社様が運営されている「[Networld Dev Portal](https://dev.networld.co.jp/)」（外部サイト）は、GitLabの導入や活用を検討されている皆様にとって、貴重な情報源となっています。このポータルサイトに掲載されている技術記事や動画は、GitLabをより深く理解し、効果的に活用するための重要なリソースです。\n\n### 日本市場向けの情報提供\n\nNetworld社様の取り組みの一つに、GitLabのグローバルサイトに掲載されている最新情報を常にチェックし、日本国内のリセラー様やエンドユーザー様にとって有益な内容をGitLab Japanチームに迅速に共有いただいていることが挙げられます。この対応により、日本市場に適した情報をタイムリーに提供することが可能になっています。\n\n特に、GitLab DAST（動的アプリケーションセキュリティテスト）や[GitLab Code Suggestions](https://about.gitlab.com/ja-jp/solutions/code-suggestions/)（AI支援機能）に関する記事が多くの方々から好評を得ています。これらの技術解説や運用ヒントは、GitLabのセキュリティ機能や開発効率化を推進する上で有用なものとなっています。\n\n### セキュリティに関する最新情報の提供\n\nセキュリティへの関心が高まる中、Networld社様はGitLabに関連するセキュリティ情報の提供にも注力されています。例えば、[GitLabのクリティカルパッチリリースや脆弱性情報](https://about.gitlab.com/releases/categories/releases/)について、迅速に記事を作成し、リセラー様やエンドユーザー様にわかりやすく解説しています。これにより、セキュリティリスクに迅速に対応し、安心してGitLabを活用することができます。\n\nNetworld社様のセキュリティ関連のコンテンツは、専門的な内容をわかりやすくまとめており、技術的な知識が少ない方でも理解しやすいよう工夫されています。\n\n### 豊富な経験に基づくサポート\n\nNetworld社様の質の高いサポートの背景には、長年のソフトウェアおよびハードウェア製品のディストリビューションビジネスで培われた豊富な経験があります。リセラー様やエンドユーザー様が必要としている情報を、タイムリーに提供できる体制が整っていることは、GitLab製品の普及に大きく貢献しています。\n\n### リセラー様向けの充実したリソース\n\nNetworld社様は、リセラー様に向けて豊富な商材資料や技術解説も提供しています。特にGitLabの機能比較資料やユースケースの紹介は、リセラー様がエンドユーザー様に適切な提案を行う際に役立っています。\n\nさらに、成功事例や導入事例も紹介されており、リセラー様はこうした情報を基に、エンドユーザー様に対して信頼性の高い提案を行うことができます。\n\n### リセラー様、エンドユーザー様へ—「Networld Dev Portal」のご活用のお勧め\n\nリセラー様、エンドユーザー様には、Networld社様が提供されている「[Networld Dev Portal](https://dev.networld.co.jp/)」（外部サイト）の活用をお勧めします。このポータルサイトには、GitLabの技術情報やセキュリティアップデート、商材資料が豊富に揃っており、皆様のビジネスに役立つリソースが集約されています。\n\n特にリセラー様にとっては、提案活動を円滑に進めるための有用なサポートとなります。エンドユーザー様にとっても、GitLabの効果的な活用方法を学ぶ貴重な情報源となるでしょう。\n\n今後も、Networld社様と共に日本市場でのGitLabの普及と成長を目指してまいります。「[Networld Dev Portal](https://dev.networld.co.jp/)」（外部サイト）を定期的にご確認いただき、ご活用いただければ幸いです。皆様のビジネスの成功に少しでも貢献できることを願っております。",[285],{"slug":2805,"featured":92,"template":681},"partner-networld","content:ja-jp:blog:partner-networld.yml","Partner Networld","ja-jp/blog/partner-networld.yml","ja-jp/blog/partner-networld",{"_path":2811,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2812,"content":2818,"config":2823,"_id":2825,"_type":16,"title":2826,"_source":17,"_file":2827,"_stem":2828,"_extension":20},"/ja-jp/blog/what-is-gitflow",{"title":2813,"description":2814,"ogTitle":2813,"ogDescription":2814,"noIndex":6,"ogImage":2815,"ogUrl":2816,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2816,"schema":2817},"GitFlowとは？GitLab Flowとの違いと開発フローを解説","GitFlowとGitLab Flowの違いや、GitFlowとは何なのか、GitFlowの仕組みや使うメリット、よくある質問などをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659838/Blog/Hero%20Images/AdobeStock_662057734.jpg","https://about.gitlab.com/blog/what-is-gitflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitFlowとは？GitLab Flowとの違いと開発フローを解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-09-27\",\n      }",{"title":2813,"description":2814,"authors":2819,"heroImage":2815,"date":2820,"body":2821,"category":962,"tags":2822},[671],"2024-09-27","GitFlow では、開発者は「\u003Ccode>main\u003C/code>」（運用）ブランチの他に「\u003Ccode>develop\u003C/code>」（開発）ブランチを分けて作成しそれをデフォルトにしますが、[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は\u003Ccode>main\u003C/code>ブランチでもすぐ作業を始められます。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)にはプリプロダクションのブランチが組み込まれており、\u003Ccode>main\u003C/code> ブランチに変更点をマージして本番環境に移行する前にバグ修正を行うことができます。たとえば、\u003Ccode>main\u003C/code>からテストへ、テストから承認へ、または、承認からプロダクションへ、といったように、チームは必要に応じてプリプロダクションブランチを好きなだけ追加できます。\n\nここでは、GitFlowと[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)の違いや、GitFlowとは何なのか、GitFlowの仕組みやこれを使うメリット、よくある質問などをわかりやすく説明します。\n\n## 目次\n- GitFlowとは\n- GitFlowの仕組み\n- GitFlowと GitLab Flow はどう違うのか\n- GitFlowのワークフロー\n- GitLab Flowのワークフロー\n- GitFlowを使うメリットと各種機能\n- GitFlowの例\n- GitLab FlowとGitFlowのFAQ（よくある質問）\n\n## \u003CH2> GitFlowとは \u003C/H2>\n\nGitFlowとは、Git（分散型バージョン管理システム）ブランチを管理するGitワークフローのことで、Gitでのリポジトリの分岐（ブランチ）モデルです。複雑なソフトウェアリリース管理を簡素化するためにつくられ、Vincent Driessen氏によって2010年に利用が始まりました。規模の大きなチームの間で、特に人気があります。\n\n## \u003CH2> GitFlowの仕組み \u003C/H2>\n\nトランクベース開発と比較すると、GitFlowには永続的なブランチと大規模なコミットがあります。GitFlowは、リリースの周期が決まっているプロジェクトと、継続的なデリバリーを行なう [DevOps](https://about.gitlab.com/ja-jp/solutions/devops-platform/)ベストプラクティスに利用できます。\nGitFlowではワークフローが構造化されているため、たとえば、developブランチとmainブランチにfeatureブランチを追加し、次いでreleaseブランチを追加するなどして各ブランチを定義します。こうすると、チームがその構造を理解しやすく、変更点などを開発パイプラインのどこに加えるべきなのか、一目瞭然となります。\n## \u003CH2> GitFlowとGitLab Flowはどう違うのか \u003C/H2>\n\nGitFlowとは、Gitのブランチングモデルで、フィーチャーブランチの他に、複数の主要ブランチを使用します。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は、GitFlowが内包していた問題を解決し、チームメンバーがより効率よく作業できるようにしています。詳しいワークフローの違いを見てみましょう。\n\n### \u003CH3> GitFlowのワークフロー \u003C/H3>\n\nGitFlowのワークフローには、次の5つのブランチがあります。\n\n1. main\u003Cbr>\n2. develop\u003Cbr>\n3. feature\u003Cbr>\n4. release\u003Cbr>\n5. hotfix\u003Cbr>\n\nGitFlowをコード開発で使用するときは、mainブランチとそれ以外のサポートブランチを使用します。メインブランチには、製品としてリリースするためのmainブランチと、開発中のソースコードを管理するdevelopブランチの2つのブランチがあります。developブランチでコードの安定化を図り、リリースの準備ができたらmainブランチにマージします。サポートブランチには、feature、release、hotfixなどのブランチを作成し、それぞれの作業を進めます。\n\n### \u003CH3> GitLab Flow のワークフロー \u003C/H3>\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は、リリース、タグ付け、マージなどで発生するオーバーヘッドを防ぎ、開発を効率化します。\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はGitFlowを簡略化したもので、フィーチャー中心の開発と、イシュー追跡機能を組み合わせたものです。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)を使うと、シンプルで、わかりやすく、かつ効率的な作業が可能になります。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)には、ソフトウェア開発チームがスムーズに機能をリリースするための、ベストプラクティスが含まれています。\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はGitLabの開発で使用するワークフローで、メインのブランチである \u003Ccode>main\u003C/code>、リリース前のテスト用ブランチである \u003Ccode>pre-production\u003C/code>、リリース済みのコードを管理する\u003Ccode>production\u003C/code>、機能の開発やバグ修正用\u003Ccode>feature\u003C/code>/\u003Ccode>hotfix\u003C/code>などのブランチがあります。チームは、好きな数だけプリプロダクションブランチを追加できます。たとえば、\u003Ccode>main\u003C/code> からテストに、テストから承認に、承認からプロダクションに、といったように流れをつくります。\n\nチームはフィーチャーブランチを作成する一方で、プロダクションブランチを管理します。メインブランチのデプロイ準備が整ったら、それをプロダクションブランチにマージし、リリースします。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はリリースブランチでも使用できます。パブリックのAPIが必要なチームは異なるバージョンを管理しなければなりませんが、[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)を使うと個別に管理可能なv1ブランチとv2ブランチを作成できるため、コードレビューでバグを検出した場合にv1に戻れ、とても便利です。\n\n\u003CH2> GitFlowを使うメリットと各種機能 \u003C/H2>\n\u003CH3>メリット1: バグ修正を迅速に処理\u003C/H3>\n\nGitFlowを使うメリットのひとつは、本番環境でのバグ修正が素早く処理できる点です。GitFlowは規模の大きなチームで複雑なソフトウェア開発を行なう際に、Git（分散型バージョン管理システム）のワークフローとして利用します。\n\n\u003CH3>メリット2: テストを保証\u003C/H3>\n\nリリースブランチからソフトウェアをリリースするときは、ユーザーがステージング環境でテストできる期間を設定できます。これはコード開発とは独立して行なえます。また、コミットは下流側に流れるので、すべての環境でテスト済みであることが保証できます。\n\n\u003CH3>メリット3: ソフトウェア開発プロセスの効率化\u003C/H3>\nGitFlowを使うと、Gitが最大限に活用できます。それにより、ソフトウェア開発プロセスの効率化が図れます。\n\n\u003CH3>メリット4: より効率的なコラボレーション、コンフリクトの解決、継続的なデリバリー\u003C/H3>\n\nGitFlow を導入することで、コラボレーションが効率化できます。マージのコンフリクトも素早く解決でき、継続的なデリバリーが実現します。\n\n\u003CH2> GitFlowの例 \u003C/H2>\n以下に、GitFlowの構成例を図で示します。フロー全体と、それぞれの分岐や構造などがおわかりになるかと思います。\n\n![AdobeStock 569852816](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673714/Blog/Content%20Images/AdobeStock_569852816.jpg)\n\u003CH2> GitLab FlowとGitFlowのFAQ（よくある質問）\u003C/H2>\n\n### Q: Git Feature Flowとは何ですか。\nA: Gitを使った開発フローについて、提唱されているフローのひとつです。シンプルな開発なら Git Feature Flowで対応可能です。\n\n### Q: GitLab Flowは、使用するだけの価値がありますか。\nA: はい。GitLab Flowはリリース、タグ付け、マージなどのオーバーヘッドを低減します。こういった問題は、他の Gitワークフローでよく出くわす問題です。詳しくは、[こちら](https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/)（英語版）をご覧ください。\n\n### Q: GitLab FlowとGit Flow、どちらを選んだらいいですか。\n\nA: Git Flowでは、その構造上、開発ステージが明確に分かれている大型のプロジェクトに向いていますが、GitLab Flowは[アジャイル](https://about.gitlab.com/ja-jp/blog/what-is-agile-development/)なので、継続的なデリバリーや迅速なリリースを優先するようなプロジェクトに向いています。\n\n## \u003CH2>参考文献\u003C/H2>\n[GitLab のDevSecOpsについて](https://about.gitlab.com/ja-jp/)\n\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n## \u003CH2>今すぐGitLabを始めてみる\u003C/H2>\nGitやバージョンコントロールについて詳しく知りたい方は、[こちら](https://about.gitlab.com/resources/)をご覧ください。\n統合されたDevSecOpsプラットフォームを使用してチームの可能性の広がりを体感しませんか？\n\n[無料トライアルを開始](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com)\n",[966,825],{"slug":2824,"featured":6,"template":681},"what-is-gitflow","content:ja-jp:blog:what-is-gitflow.yml","What Is Gitflow","ja-jp/blog/what-is-gitflow.yml","ja-jp/blog/what-is-gitflow",{"_path":2830,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2831,"content":2837,"config":2844,"_id":2846,"_type":16,"title":2847,"_source":17,"_file":2848,"_stem":2849,"_extension":20},"/ja-jp/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"title":2832,"description":2833,"ogTitle":2832,"ogDescription":2833,"noIndex":6,"ogImage":2834,"ogUrl":2835,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2835,"schema":2836},"子パイプラインを使用して5つの環境に継続的にデプロイする","使用するGitLabワークフローを最小限に抑えつつ、複数の環境（事前の準備なしに一時的に利用できるsandboxなど）への継続的デプロイを管理する方法を解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097012/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750097011626.jpg","https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"子パイプラインを使用して5つの環境に継続的にデプロイする\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Olivier Dupré\"}],\n        \"datePublished\": \"2024-09-26\",\n      }",{"title":2832,"description":2833,"authors":2838,"heroImage":2834,"date":2840,"body":2841,"category":672,"tags":2842,"updatedDate":2843},[2839],"Olivier Dupré","2024-09-26","DevSecOpsチームでは、複数の環境にまたがる継続的デプロイを管理する機能が必要となることがあります。その場合、ワークフローを変更せずに、デプロイを行えるようにする必要があります。[GitLab\nDevSecOpsプラットフォーム](https://about.gitlab.com/)なら、事前の準備なしに一時的に利用できるsandboxを使用して工数を最小限に抑えるアプローチなどを通じて、こうしたニーズに対応できます。この記事では、Terraformを使って複数の環境上でインフラの継続的デプロイを行う方法についてご紹介します。\n\n\nこの手法は、[Pulumi](https://www.pulumi.com/)や[Ansible](https://www.ansible.com/)のような別の技術を使用したInfrastructure\nas\nCode（IaC）でも、どのような言語で書かれたソースコードでも、または多様な言語が混在するモノレポであっても、あらゆるプロジェクトに簡単に適用できます。\n\n\nこのチュートリアルの終了時には、以下のような環境をデプロイするパイプラインが完成します。\n\n\n* 各フィーチャーブランチの一時的な**レビュー（review）**環境。\n\n* 簡単に消去可能で、mainブランチからデプロイされる**統合（integration）**環境。\n\n* **品質管理（qa）**環境。同様にmainブランチからデプロイされ、品質管理プロセスを実行します。\n\n* タグ付けされるたびにデプロイされる**ステージング（staging）**環境。これは本番環境前の最後のステージです。\n\n*\nステージング環境の直後の**本番（production）**環境。今回はデモ用に手動でトリガーしますが、継続的にデプロイされるようにすることも可能です。\n\n\n>この記事で使用されるフローチャートの説明は以下のとおりです。\n\n> * 角が丸いボックスはGitLabブランチです。\n\n> * 四角のボックスは環境です。\n\n> * 矢印上のテキストは、あるボックスから次のボックスへのアクションを指します。\n\n> * ひし形のボックスは決定ステップです。\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    A(main) -->|新機能| B(feature_X)\n\n    B -->|自動デプロイ| C[review/feature_X]\n    B -->|マージ| D(main)\n    C -->|破棄| D\n\n    D -->|自動デプロイ| E[integration]\n    E -->|手動| F[qa]\n\n    D -->|タグ付け| G(X.Y.Z)\n    F -->|検証| G\n\n    G -->|自動デプロイ| H[staging]\n    H -->|手動| I{plan}\n    I -->|手動| J[production]\n\u003C/pre>\n\n\nステップごとに、[理由](#why)と[行うこと](#what)を説明した上で、[方法](#how)をご紹介します。これにより、このチュートリアルを完全に理解し、正確に実行しやすくなります。\n\n\n## 理由\n\n\n*\n[継続的インテグレーション](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-integration-ci)はほぼ事実上の業界標準と言えます。ほとんどの企業は、CIパイプラインを実装済みであるか、その実践の標準化を検討しています。\n\n\n*\nまた、CIパイプラインの最後にリポジトリまたはレジストリにアーティファクトをプッシュする[継続的なデリバリー](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-delivery-cd)も一般的です。\n\n\n*\n継続的デプロイメントはさらに進んで、これらのアーティファクトを自動的にデプロイしますが、その普及はまだ限定的です。導入されている場合、主にアプリケーション分野で見られます。インフラの継続的デプロイメントに関しては、状況がやや不明瞭で、複数の環境の管理に重きが置かれる傾向があります。一方で、インフラのコードをテストし、セキュリティを確保し、検証することはより難しいとされています。この分野は、DevOpsがまだ成熟に至っていない分野のひとつです。ほかの分野としては、セキュリティのシフトレフトが挙げられます。具体的には、セキュリティチームの介入、さらに重要なことに、セキュリティ上のリスクへの対応をデリバリーライフサイクルの早期に組み込み、DevOpsから***DevSecOps***へと発展させる取り組みのことです。\n\n\nこのような概況を踏まえ、本チュートリアルでは、インフラにDevSecOpsをシンプルかつ効果的に導入するシナリオに取り組みます。5つの環境にリソースをデプロイする例を交えながら、開発から本番環境へと段階的に進めていきます。\n\n\n__注__：個人的にはFinOpsアプローチを採用し、環境の数を減らすことを推奨していますが、開発環境、ステージング環境、本番環境以外の環境を保持すべき場合もあります。そのため、これからご紹介する例をご自身のニーズに合わせて調整してください。\n\n\n## 行うこと\n\n\nクラウド技術の台頭により、IaCの利用が促進されています。この分野を最初に開拓したのは、AnsibleとTerraformでした。OpenTofu、Pulumi、AWS\nCDK、Google Deploy Managerを始めとする多くの会社がその後に続きました。\n\n\nIaCを定義することは、インフラストラクチャを安全にデプロイするのに最適なソリューションです。目標を達成できるまで必要なだけ、テスト、デプロイ、再実行を繰り返し行えます。\n\n\n残念なことに、ターゲット環境ごとに複数のブランチやリポジトリを保持している企業がよくあります。これが原因で問題が生じます。こういった企業では、プロセスの実施が徹底されていません。本番環境のコードベースへの変更が、その前の環境で正しくテストされているかどうかも確認できません。その結果、ある環境から別の環境へ流れるだけになります。\n\n\nこのチュートリアルが必要だと気づいたのは、あるカンファレンスに参加した際に、本番環境へのデプロイ前にインフラストラクチャを十分にテストするワークフローがないと参加者全員から聞いたときです。みなが、本番環境で直接コードにパッチを適用することもあると言っていました。確かにこの方法は手っ取り早いですが、果たして安全でしょうか？前の環境にフィードバックをどう戻すのでしょうか？また副次効果が生じないようにするにはどうすればよいのでしょうか？新たな脆弱性が本番環境にあまりにも早くプッシュされることで会社がリスクにさらされないようにするには、どのように管理すべきでしょうか？\n\n\nここで重要なのは、DevOpsチームが本番環境に直接デプロイするのは*なぜ*かということです。パイプラインの効率性や速度を向上できる可能性があるためでしょうか？自動化できないのでしょうか？それどころか、*本番環境以外で正確にテストする方法がない*からなのでしょうか？\n\n\n次のセクションでは、インフラストラクチャを自動化し、ほかの人に影響を及ぼす環境にコードがプッシュされる前に、DevOpsチームが効果的かつ確実にテストを実施するための方法をご説明します。また、コードがどのように保護され、エンドツーエンドでデプロイが管理されているかも確認していきます。\n\n\n## 方法\n\n\n前述のとおり、現在では多くのIaC言語が存在しているため、この記事だけで客観的に*すべて*を取り上げることはできません。そのため、この記事ではバージョン1.4で実行される基本的なTerraformコードを使用します。IaC言語そのものではなく、貴社のエコシステムに適用できるプロセスに注目してください。\n\n\n### Terraformコード\n\n\nまずは、基本的なTerraformコードから始めましょう。\n\n\n仮想ネットワークであるAWSの仮想プライベートクラウド（VPC）にデプロイしたいと思います。VPCには、パブリックサブネットとプライベートサブネットをデプロイします。名前からわかるように、これらはメインVPCのサブネットです。最後に、パブリックサブネットにAmazon\nElastic Cloud Compute（EC2）インスタンス（仮想マシン）を追加します。\n\n\nこれは、比較的簡単な方法で4つのリソースをデプロイする方法を示しています。コードではなく、パイプラインに焦点を当てることがここでの目的です。\n\n\nここで目指すリポジトリの完成形は、以下のとおりです。\n\n\n![リポジトリの完成図](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097033415.png)\n\n\nステップごとに行っていきましょう。\n\n\nまずは、`terraform/main.tf`ファイルでリソースをすべて宣言します。\n\n\n```terraform\n\nprovider \"aws\" {\n  region = var.aws_default_region\n}\n\n\nresource \"aws_vpc\" \"main\" {\n  cidr_block = var.aws_vpc_cidr\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n\n\nresource \"aws_subnet\" \"public_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_public_subnet_cidr\n\n  tags = {\n    Name = \"Public Subnet\"\n  }\n}\n\nresource \"aws_subnet\" \"private_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_private_subnet_cidr\n\n  tags = {\n    Name = \"Private Subnet\"\n  }\n}\n\n\nresource \"aws_instance\" \"sandbox\" {\n  ami           = var.aws_ami_id\n  instance_type = var.aws_instance_type\n\n  subnet_id = aws_subnet.public_subnet.id\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n\n```\n\n\nご覧のとおり、このコードではいくつかの変数が必要となるため、`terraform/variables.tf`ファイルでそれらを宣言します。\n\n\n```terraform\n\nvariable \"aws_ami_id\" {\n  description = \"The AMI ID of the image being deployed.\"\n  type        = string\n}\n\n\nvariable \"aws_instance_type\" {\n  description = \"The instance type of the VM being deployed.\"\n  type        = string\n  default     = \"t2.micro\"\n}\n\n\nvariable \"aws_vpc_cidr\" {\n  description = \"The CIDR of the VPC.\"\n  type        = string\n  default     = \"10.0.0.0/16\"\n}\n\n\nvariable \"aws_public_subnet_cidr\" {\n  description = \"The CIDR of the public subnet.\"\n  type        = string\n  default     = \"10.0.1.0/24\"\n}\n\n\nvariable \"aws_private_subnet_cidr\" {\n  description = \"The CIDR of the private subnet.\"\n  type        = string\n  default     = \"10.0.2.0/24\"\n}\n\n\nvariable \"aws_default_region\" {\n  description = \"Default region where resources are deployed.\"\n  type        = string\n  default     = \"eu-west-3\"\n}\n\n\nvariable \"aws_resources_name\" {\n  description = \"Default name for the resources.\"\n  type        = string\n  default     = \"demo\"\n}\n\n```\n\n\nすでにIaC側に関しては、これでほぼ準備が整いました。しかしながら、これではTerraformの状態を共有できません。ご存知ない方のために大まかに説明すると、Terraformは以下を行うことで動作します。\n\n\n* `plan`により、インフラストラクチャの現在の状態とコートで定義されている内容の差分を確認してから、差分を出力します。\n\n* `apply`により、`plan`の差分を適用して、状態を更新します。\n\n\n最初のラウンドでは状態は空で、その後、Terraformによって適用されたリソースの詳細（IDなど）が挿入されます。\n\n\n問題は、その状態がどこに保存されるかということです。また、複数のデベロッパーがコード上で共同作業を行えるようにするにはどうすればよいのでしょうか？\n\n\n解決策はとても簡単で、GitLabを利用して、[Terraform\nHTTPバックエンド](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html)を介して状態を保存して共有するだけです。\n\n\nこのバックエンドを使用するには、まずはもっともシンプルな`terraform/backend.tf`ファイルを作成します。次のステップは、パイプラインで処理します。\n\n\n```terraform\n\nterraform {\n  backend \"http\" {\n  }\n}\n\n```\n\n\nこれで、4つのリソースをデプロイするための最低限のTerraformコードができあがりました。変数の値は実行する際に指定するので、後でご説明します。\n\n\n### ワークフロー\n\n\nこれから以下のワークフローを実装します。\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    A(main) -->|新機能| B(feature_X)\n\n    B -->|自動デプロイ| C[review/feature_X]\n    B -->|マージ| D(main)\n    C -->|破棄| D\n\n    D -->|自動デプロイ| E[integration]\n    E -->|手動| F[qa]\n\n    D -->|タグ付け| G(X.Y.Z)\n    F -->|検証| G\n\n    G -->|自動デプロイ| H[staging]\n    H -->|手動| I{plan}\n    I -->|手動| J[production]\n\u003C/pre>\n\n\n1.\n**フィーチャー**ブランチを作成します。これにより、コードに対して継続的にすべてのスキャナーが実行され、コンプライアンスとセキュリティを確保できます。このコードは、現在のブランチの名前が付けられた一時的な環境`review/feature_branch`に継続的にデプロイされます。これは、デベロッパーと運用チームが誰にも影響を与えることなくコードをテストできる安全な環境です。また、ここでコードレビューやスキャナーの実行などのプロセスを実施し、コードの品質とセキュリティが許容範囲内であることを確認し、資産が危険にさらされることのないようにします。このブランチでデプロイされたインフラストラクチャは、ブランチが閉じられると自動的に破棄されます。これにより予算範囲内に収めやすくなります。\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    A(main) -->|新機能| B(feature_X)\n\n    B -->|自動デプロイ| C[review/feature_X]\n    B -->|マージ| D(main)\n    C -->|破棄| D\n\u003C/pre>\n\n\n2.\n承認されると、フィーチャーブランチはmainブランチに**マージ**されます。これは[保護ブランチ](https://docs.gitlab.com/ee/user/project/protected_branches.html)であり、誰もプッシュできません。本番環境への変更リクエストをすべて十分にテストするために必要です。このブランチも継続的にデプロイされます。ここでのターゲットは`integration`環境です。この環境をもう少し安定させるために、削除は自動化されておらず、手動でトリガーできるようになっています。\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    D(main) -->|自動デプロイ| E[integration]\n\u003C/pre>\n\n\n3.\nここから次のデプロイをトリガーするには、手動による承認が必要となります。これにより、mainブランチが`qa`環境にデプロイされます。ここでパイプラインからの削除を防ぐルールを設定します。何しろすでに3つ目のこの環境はかなり安定しているはずなので、このルールは誤って削除されるのを防ぐことを目的とします。貴社のプロセスに合わせて、お好きなようなルールを調整してください。\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    D(main)-->|自動デプロイ| E[integration]\n    E -->|手動| F[qa]\n\u003C/pre>\n\n\n4.\n次に進むには、コードに**タグ付け**する必要があります。[保護タグ](https://docs.gitlab.com/ee/user/project/protected_tags.html)を使用して、特定のユーザーのみが最後の2つの環境にデプロイできるようにします。これにより、`staging`環境へのデプロイが即座にトリガーされます。\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    D(main) -->|タグ付け| G(X.Y.Z)\n    F[qa] -->|検証| G\n\n    G -->|自動デプロイ| H[staging]\n\u003C/pre>\n\n\n5.\nついに`production`に到達しました。インフラストラクチャに関して言うと、（10%や25%など）段階的にデプロイするのは難しい場合が多いため、インフラストラクチャ全体をデプロイします。ただし、この最後のステップで行う手動トリガーで、このデプロイを制御します。そして、この極めて重要な環境を最大限に制御できるようにするために、[保護環境](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)として管理します。\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    H[staging] -->|手動| I{plan}\n    I -->|手動| J[production]\n\u003C/pre>\n\n\n### パイプライン\n\n\n上記の[ワークフロー](#the-workflow)を実装するために、2つの[ダウンストリームパイプライン](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html)とともにパイプラインを構築します。\n\n\n#### メインパイプライン\n\n\nまずは、メインパイプラインから始めましょう。メインパイプラインは、**フィーチャーブランチへのプッシュ**、**デフォルトブランチへのマージ**、または**タグ付け**が発生すると、必ず自動的にトリガーされます。*このパイプライン*によって、`dev`、`integration`、`staging`環境に対する真の**継続的デプロイ**を実現できます。プロジェクトのルートにある`.gitlab-ci.yml`ファイルで宣言します。\n\n\n![リポジトリのターゲット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097033417.png)\n\n\n```yml\n\nStages:\n  - test\n  - environments\n\n.environment:\n  stage: environments\n  variables:\n    TF_ROOT: terraform\n    TF_CLI_ARGS_plan: \"-var-file=../vars/$variables_file.tfvars\"\n  trigger:\n    include: .gitlab-ci/.first-layer.gitlab-ci.yml\n    strategy: depend            # Wait for the triggered pipeline to successfully complete\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nreview:\n  extends: .environment\n  variables:\n    environment: review/$CI_COMMIT_REF_SLUG\n    TF_STATE_NAME: $CI_COMMIT_REF_SLUG\n    variables_file: review\n    TF_VAR_aws_resources_name: $CI_COMMIT_REF_SLUG  # Used in the tag Name of the resources deployed, to easily differenciate them\n  rules:\n    - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n\nintegration:\n  extends: .environment\n  variables:\n    environment: integration\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nstaging:\n  extends: .environment\n  variables:\n    environment: staging\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_TAG\n\n#### TWEAK\n\n# This tweak is needed to display vulnerability results in the merge\nwidgets.\n\n# As soon as this issue https://gitlab.com/gitlab-org/gitlab/-/issues/439700\nis resolved, the `include` instruction below can be removed.\n\n# Until then, the SAST IaC scanners will run in the downstream pipelines,\nbut their results will not be available directly in the merge request\nwidget, making it harder to track them.\n\n# Note: This workaround is perfectly safe and will not slow down your\npipeline.\n\ninclude:\n  - template: Security/SAST-IaC.gitlab-ci.yml\n#### END TWEAK\n\n\n```\n\n\nこのパイプラインは、`test`と`environments`の2つのステージのみを実行します。前者は、*TWEAK（微調整）*により、スキャナーを実行するために必要です。後者では、上記で定義したケース（ブランチへのプッシュ、デフォルトブランチへのマージ、タグ付け）ごとに異なる変数セットを持つ子パイプラインがトリガーされます。\n\n\nここで子パイプラインに[strategy:depend](https://docs.gitlab.com/ee/ci/yaml/index.html#triggerstrategy)キーワードで依存を追加します。これにより、デプロイの完了後にGitLabのパイプラインビューが更新されます。\n\n\nご覧のとおりベースとなるジョブが[無効になる](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs)ように定義し、特定の変数とルールで拡張して、ターゲット環境ごとに単一のデプロイメントだけがトリガーされるようにしています。\n\n\n[定義済み変数](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)に加え、定義する必要がある新たな2つのエントリを使用します。\n\n1. 各環境[固有の変数](#the-variable-definitions)：`../vars/$variables_file.tfvars`\n\n2. [子パイプライン](#the-child-pipeline)。`.gitlab-ci/.first-layer.gitlab-ci.yml`で定義\n\n\nまずは、簡単な方、つまり変数の定義から始めましょう。\n\n\n### 変数の定義\n\n\nここでは、2つのソリューションを組み合わせてTerraformに変数を提供します。\n\n\n*\n1つ目は、[.tfvarsファイル](https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files)を使用して、機密性の低い入力をすべて行う方法です。これはGitLab内に保存する必要があります。\n\n\n![Terraformに変数を提供するための1つ目のソリューション](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097033419.png)\n\n\n*\n2つ目は、プレフィックスに`TF_VAR`を付けた[環境変数](https://developer.hashicorp.com/terraform/language/values/variables#environment-variables)を使用する方法です。変数を挿入するこの2つ目の方法は、[変数をマスク](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable)し、[保護](https://docs.gitlab.com/ee/ci/variables/#protect-a-cicd-variable)し、さらに[スコープの環境を設定する](https://docs.gitlab.com/ee/ci/environments/index.html#limit-the-environment-scope-of-a-cicd-variable)GitLabの機能とも関係する、**機密情報の漏えいを防ぐ**強力なソリューションです（本番環境のプライベートClassless\nInter-Domain\nRouting（CIDR）で非常に機密性が高いデータをやり取りすると考えられる場合は、この方法で保護すれば、本番環境、および保護ブランチやタグに対して実行されるパイプラインでのみ利用できるようにし、ジョブのログでその値がマスクされるようにすることができます）。\n\n\n![Terraformに変数を提供するための2つ目のソリューション](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097033422.png)\n\n\nまた、各変数ファイルを変更できるユーザーを設定するために、[`CODEOWNERS`ファイル](https://docs.gitlab.com/ee/user/project/codeowners/)で各変数ファイルを管理する必要があります。\n\n\n```\n\n[Production owners] \n\nvars/production.tfvars @operations-group\n\n\n[Staging owners]\n\nvars/staging.tfvars @odupre @operations-group\n\n\n[CodeOwners owners]\n\nCODEOWNERS @odupre\n\n```\n\n\nこの記事は、Terraformのトレーニング用ではないため、詳しく説明せず、ここでは`vars/review.tfvars`ファイルを紹介するだけに留めます。当然ながら、これに続く環境ファイルもほぼ同じです。ここでは機密性の低い変数とその値を設定するだけです。\n\n\n```shell\n\naws_vpc_cidr = \"10.1.0.0/16\"\n\naws_public_subnet_cidr = \"10.1.1.0/24\"\n\naws_private_subnet_cidr = \"10.1.2.0/24\"\n\n```\n\n\n#### 子パイプライン\n\n\n実際の作業はこのパイプライン内で行われます。そのため、最初のパイプラインよりも少し複雑です。しかしながら、力を合わせれば何でも乗り越えられます！\n\n\n[メインパイプライン](#the-main-pipeline)の定義で説明したように、ダウンストリームパイプラインは`.gitlab-ci/.first-layer.gitlab-ci.yml`で宣言されています。\n\n\n![ファイルで宣言されているダウンストリームパイプライン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097033424.png)\n\n\n小さなステップに分けて説明します。最後に全体像が見えるはずです。\n\n\n##### Terraformコマンドを実行してコードを保護する\n\n\nまずは、Terraformのパイプラインを実行したいと思います。GitLabはオープンソースであるため、Terraform用のテンプレートもオープンソースです。そのため、このテンプレートを含めるだけで済みます。以下のスニペットを使用して行えます。\n\n\n```yml\n\ninclude:\n  - template: Terraform.gitlab-ci.yml\n```\n\n\nこのテンプレートは、planとapplyが行われる前に、Terraformによるフォーマットのチェックとコードの検証を実行します。デプロイしたものを破棄することもできます。\n\n\nさらに、GitLabは統合された単一のDevSecOpsプラットフォームであるため、このテンプレート内に2つのセキュリティスキャナーを自動的に組み込み、コード内の潜在的な脅威を検出し、次の環境にデプロイされる前に警告を発します。\n\n\nこれでコードの確認、保護、ビルド、デプロイが完了したので、いくつかの便利な技をご紹介します。\n\n\n##### ジョブ間でキャッシュを共有する\n\n\nジョブの結果をキャッシュして、後続のパイプラインジョブで再利用します。これはとても簡単で、以下のコードを追加するだけで行えます。\n\n\n```yml\n\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n```\n\n\nここでは、コミットごとに異なるキャッシュを定義し、必要に応じてmainブランチ名にフォールバックするようにします。\n\n\n使用しているテンプレートをよく見ると、ジョブの実行タイミングを制御するルールがあることがわかります。全ブランチですべての制御（QAとセキュリティの両方）を実行したいと思います。そのため、次にこれらの設定を上書きします。\n\n\n##### すべてのブランチで制御を実行する\n\n\nGitLabテンプレートは強力な機能で、テンプレートの一部のみを上書きできます。品質チェックとセキュリティチェックが必ず実行されるよう、一部のジョブのルールを上書きしたいと思います。これらのジョブ向けに定義するその他すべては、テンプレートで定義された内容のままにします。\n\n\n```yml\n\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - when: always\n\niac-sast:\n  rules:\n    - when: always\n```\n\n\nこれで品質とセキュリティの制御を実施できたため、[ワークフロー](#the-workflow)内のメインの環境（integrationとstaging）とreview環境の動作に違いを付けたいと思います。まずはメインの環境の振る舞いを定義し、review環境用にこの設定を微調整していきましょう。\n\n\n##### integrationとstaging環境への継続的デプロイ\n\n\n前述のように、この2つの環境にmainブランチとタグをデプロイしたいため、そのように制御するルールを`build`と`deploy`の両方のジョブに追加します。そして、`integration`環境でのみ`destroy`を有効にします。`staging`環境は重要度が高いため、ワンクリックで削除できないようにします。この操作はエラーを引き起こしやすく、避けたいと考えています。\n\n\n最後に、`deploy`ジョブを`destroy`ジョブにリンクして、GitLab GUIから直接環境を`stop`できるようにします。\n\n\nここで使用する`GIT_STRATEGY`は、破棄する際にRunner内のソースブランチからコードが取得されることを防ぎます。これは、ブランチが手動で削除された場合は失敗するため、キャッシュを使用して、Terraformの命令を実行するために必要なものすべてを取得します。\n\n\n```yml\n\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env\n(integration or staging) when merging to default branch or tagging. Second\nlayer environments (qa and production) will be controlled manually\n  environment: \n    name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n```\n\n前述のとおり、これは`integration`と`staging`環境へのデプロイというニーズに即しています。しかしながら、デベロッパーがほかの人に影響を及ぼさずに、自分のコードに触れて検証できる一時的な環境がまだ不足しています。そのため、次は`review`環境へのデプロイを行います。\n\n\n##### review環境への継続的デプロイ\n\n\nreview環境へのデプロイは、`integration`や`staging`環境へのデプロイと大差はありません。そこで、ここでもGitLabの機能を活用して、ジョブ定義の一部のみを上書きします。\n\n\nまずは、これらのジョブがフィーチャーブランチでのみ実行されるようルールを設定します。\n\n\n次に、`deploy_review`ジョブを`destroy_review`ジョブにリンクします。これにより、GitLabユーザーインターフェイスから**手動で**環境を停止できるようになりますが、さらに重要なのは、フィーチャーブランチの完了時に**環境の破棄が自動的にトリガー**されるようになります。これは、運用にかかる費用を抑えるのに効果的な、優れたFinOpsプラクティスです。\n\n\nTerraformでは、インフラストラクチャの構築時と同様に、破棄する際にもplanファイルが必要なため、`destroy_review`から`build_review`に依存を追加して、そのアーティファクトを取得します。\n\n\n最後に、ご覧のとおり、環境の名前を`$environment`に設定します。これは、[メインパイプライン](#the-main-pipeline)で`review/$CI_COMMIT_REF_SLUG`に設定され、`trigger:forward:yaml_variables:true`という命令により、その子パイプラインに転送されます。\n\n\n```yml\n\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n```\n\n\nさて、まとめると、これで次のことを行うパイプラインができました。\n\n\n* 一時的なreview環境へのデプロイ。フィーチャーブランチの完了時に、自動的にクリーンアップされます\n\n* **デフォルトブランチ**から`integration`への継続的デプロイ\n\n* **タグ**から`staging`への継続的デプロイ\n\n\nさらにレイヤを追加し、今回は手動でのトリガーをもとに`qa`と`production`環境にデプロイされるようにしましょう。\n\n\n##### qaとproduction環境への継続的デプロイ\n\n\n誰もが本番環境に継続的デプロイしたいわけではないため、次の2つのデプロイには手動による検証を追加します。単に**CD**の観点で考えた場合、このトリガーを追加することはありませんが、ほかのトリガーからジョブを実行する方法を学ぶ機会として捉えてください。\n\n\nこれまでデプロイを実行する際は、必ず[メインパイプライン](#the-main-pipeline)から[子パイプライン](#the-child-pipeline)を開始してきました。\n\n\nデフォルトブランチとタグからさらにデプロイを実行したいため、これらの追加ステップ用に別のレイヤを追加します。新たな手順は必要ありません。[メインパイプライン](#the-main-pipeline)で行ったのとまったく同じプロセスを再度繰り返します。この方法だと、必要な数だけレイヤを操作できます。中には最大で9つの環境がある例も見たことがあります。環境の数を抑えることの利点についてはあらためて説明しませんが、このプロセスを使用することで、初期段階から最終的なデリバリーまで、同じパイプラインを非常に簡単に実装できます。その上、パイプラインの定義をシンプルに保ちつつ、コストをかけずに維持できる小さな塊に分割可能です。\n\n\nここでは変数の競合を防ぐために、新しいvar名を使用してTerraformの状態と入力ファイルを識別しています。\n\n\n```yml\n\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Otherwise, all pipelines will fail when reaching the pipeline timeout before deployment to 2nd layer.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n```\n\n\n**ここで重要なテクニックは、新しいダウンストリームパイプラインに使用するstrategyの設定です。**`trigger:strategy`はデフォルトの値のままにしておきます。そうしなければ、[メインパイプライン](#the-main-pipeline)は、[孫パイプライン](#the-grand-child-pipeline)が完了するまで待機することになります。手動トリガーだと、非常に長い時間かかり、パイプラインダッシュボードが読みづらく、理解しにくくなる可能性があります。\n\n\nここでインクルードした`.gitlab-ci/.second-layer.gitlab-ci.yml`ファイルが何なのか疑問に感じた方もいらっしゃるかもしれません。こちらは次のセクションで説明します。\n\n\n##### 1つ目のレイヤのパイプラインに関する全定義\n\n\n1つ目のレイヤの全詳細（`.gitlab-ci/.first-layer.gitlab-ci.yml`に保存）を確認したい場合は、以下のセクションを参照してください。\n\n\n```yml\n\nvariables:\n  TF_VAR_aws_ami_id: $AWS_AMI_ID\n  TF_VAR_aws_instance_type: $AWS_INSTANCE_TYPE\n  TF_VAR_aws_default_region: $AWS_DEFAULT_REGION\n\ninclude:\n  - template: Terraform.gitlab-ci.yml\n\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n  - cleanup\n  - 2nd_layer       # Use to deploy a 2nd environment on both the main branch and on the tags\n\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\niac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\n###########################################################################################################\n\n## Integration env. and Staging. env\n\n##  * Auto-deploy to Integration on merge to main.\n\n##  * Auto-deploy to Staging on tag.\n\n##  * Integration can be manually destroyed if TF_DESTROY is set to true.\n\n##  * Destroy of next env. is not automated to prevent errors.\n\n###########################################################################################################\n\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env\n(integration or staging) when merging to default branch or tagging. Second\nlayer environments (qa and production) will be controlled manually\n  environment: \n    name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n###########################################################################################################\n\n\n###########################################################################################################\n\n## Dev env.\n\n##  * Temporary environment. Lives and dies with the Merge Request.\n\n##  * Auto-deploy on push to feature branch.\n\n##  * Auto-destroy on when Merge Request is closed.\n\n###########################################################################################################\n\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n###########################################################################################################\n\n\n###########################################################################################################\n\n## Second layer\n\n##  * Deploys from main branch to qa env.\n\n##  * Deploys from tag to production.\n\n###########################################################################################################\n\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Otherwise, all pipelines will fail when reaching the pipeline timeout before deployment to 2nd layer.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n###########################################################################################################\n\n```\n\n\nこの段階で、すでに3つの環境に問題なくデプロイしています。個人的にはこのアプローチが理想的でおすすめです。ただし、もっと多くの環境が必要であれば、CDパイプラインに追加してください。\n\n\n`trigger:include`というキーワードでダウンストリームパイプラインをインクルードしていることはすでにお気づきだと思います。これにより、`.gitlab-ci/.second-layer.gitlab-ci.yml`ファイルがインクルードされます。ほぼ同じパイプラインを実行したいため、当然ながら先ほど詳しく説明したものと内容は非常に似ています。ここで[孫パイプライン](#the-grand-child-pipeline)を定義する主な利点は、それ自体が独立しているため、変数やルールを非常に定義しやすくことです。\n\n\n### 孫パイプライン\n\n\nこの2つ目のレイヤとなるパイプラインは、まったく新しいパイプラインです。そのため、1つ目のレイヤの定義を模倣しつつ、以下を行う必要があります。\n\n\n* [Terraformテンプレートのインクルード](#run-terraform-commands-and-secure-the-code)。\n\n*\n[セキュリティチェックの実施](#run-controls-on-all-branches)。Terraformの検証は1つ目のレイヤと重複するものの、セキュリティスキャナーにより以前にスキャナーが実行されたときにはまだ存在していなかった脅威を見つけられる可能性があります（stagingへのデプロイの数日後にproductionへのデプロイを行う場合など）。\n\n*\n[buildとdeployジョブを上書きして特定のルールを設定](#cd-to-review-environments)。早すぎる削除を防ぐために、`destroy`ステージは自動化されないようになったことにご注意ください。\n\n\n上述のとおり、`TF_STATE_NAME`と`TF_CLI_ARGS_plan`は、[メインパイプライン](#the-main-pipeline)から[子パイプライン](#the-child-pipeline)に渡されています。これらの値を[子パイプライン](#the-child-pipeline)から[孫パイプライン](#the-grand-child-pipeline)に渡すには、別の変数名が必要でした。そのため、子パイプラインでは変数名の末尾に`_2`を付け足し、`before_script`の実行中に適切な変数に値をコピーしています。\n\n\n各ステップについては説明済みであるため、ここでは細かいところは省き、直接グローバルな2つ目のレイヤの定義（`.gitlab-ci/.second-layer.gitlab-ci.yml`に保存）の全体像をご確認ください。\n\n\n```yml\n\n# Use to deploy a second environment on both the default branch and the\ntags.\n\n\ninclude:\n  template: Terraform.gitlab-ci.yml\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n\nfmt:\n  rules:\n    - when: never\n\nvalidate:\n  rules:\n    - when: never\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: always\n\n###########################################################################################################\n\n## QA env. and Prod. env\n\n##  * Manually trigger build and auto-deploy in QA\n\n##  * Manually trigger both build and deploy in Production\n\n##  * Destroy of these env. is not automated to prevent errors.\n\n###########################################################################################################\n\nbuild:  # terraform plan\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment:\n    name: $TF_STATE_NAME_2\n    action: prepare\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - when: manual\n\ndeploy: # terraform apply\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment: \n    name: $TF_STATE_NAME_2\n    action: start\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG && $TF_AUTO_DEPLOY == \"true\"\n    - if: $CI_COMMIT_TAG\n      when: manual\n###########################################################################################################\n\n```\n\n\nこれで**準備完了です。**\n本番環境にデプロイする前に、ジョブの実行を管理する方法は自由に変更できます。たとえば、GitLabの機能を活用して、本番環境へのデプロイ前に[ジョブを遅延させる](https://docs.gitlab.com/ee/ci/jobs/job_control.html#run-a-job-after-a-delay)設定をすることも可能です。\n\n\n## 実際に試す\n\n\nついに目標を達成できました。**フィーチャーブランチ**、**mainブランチ**、**タグ**だけで、**5つの異なる環境へのデプロイ**を管理できるようになりました。\n\n* パイプラインの効率とセキュリティを確保するために、GitLabのオープンソーステンプレートを集中的に再利用しました。\n\n* GitLabテンプレートの機能を活用して、個別に制御が必要なブロックだけを上書きしました。\n\n* パイプラインを小さな塊に分割し、ニーズに完全に合うようにダウンストリームパイプラインを制御しました。\n\n\nここからは、自由に進めてください。たとえば、[trigger:rules:changes](https://docs.gitlab.com/ee/ci/yaml/#ruleschanges)キーワードを使って、ソフトウェアのソースコードのダウンストリームパイプラインをトリガーするように、メインパイプラインを簡単に更新することも可能です。また、発生した変更に応じて、別の[テンプレート](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/)を使用できます。その方法はまた別の機会に。\n",[110,1410,1411,904,676],"2025-06-12",{"slug":2845,"featured":6,"template":681},"using-child-pipelines-to-continuously-deploy-to-five-environments","content:ja-jp:blog:using-child-pipelines-to-continuously-deploy-to-five-environments.yml","Using Child Pipelines To Continuously Deploy To Five Environments","ja-jp/blog/using-child-pipelines-to-continuously-deploy-to-five-environments.yml","ja-jp/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"_path":2851,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2852,"content":2858,"config":2864,"_id":2866,"_type":16,"title":2867,"_source":17,"_file":2868,"_stem":2869,"_extension":20},"/ja-jp/blog/gitlab-17-4-released",{"title":2853,"description":2854,"ogTitle":2853,"ogDescription":2854,"noIndex":6,"ogImage":2855,"ogUrl":2856,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2856,"schema":2857},"GitLab 17.4リリース","GitLab 17.4でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662149/Blog/Hero%20Images/17_4-cover-image.png","https://about.gitlab.com/blog/gitlab-17-4-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.4リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-09-19\",\n      }",{"title":2853,"description":2854,"authors":2859,"heroImage":2855,"date":2860,"body":2861,"category":701,"tags":2862,"updatedDate":2863},[738],"2024-09-19","**よりコンテキストを意識するようになったGitLab Duoを含むGitLab 17.4をリリース**\n\nこのたび、開いているタブの内容を使用してよりコンテキストを意識するようになったコード提案、すべてのチェックに合格した場合の自動マージ、Web IDEの拡張機能マーケットプレース、一般提供が開始された高度なSASTなど、さまざまな機能を備えたGitLab 17.4のリリースを発表しました！\n\nこれらの機能は、今回のリリースに含まれる140件以上の改善点のほんの一部です。役に立つ最新情報をすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 17.4には、GitLabコミュニティのユーザーから220件以上ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、17.5リリースのキックオフビデオも視聴できる[今後のリリースページ](https://about.gitlab.com/direction/kickoff/)をご覧ください。\n\n> [GitLab Duoでコンテキストの改善を実現したGitLab 17.4がリリースされました。](http://twitter.com/share?text=GitLab+17.4+released+with+improved+context+in+GitLab+Duo&url=https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/&hashtags=)クリックしてSNSで共有しましょう！\n\n## **今月のMost Valuable Person（[MVP](https://about.gitlab.com/community/mvp/)）は[Archish Thakkar](https://gitlab.com/archish27)さんが受賞**\n\nMVPには、誰でも[GitLabコミュニティのコントリビューターを推薦](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)できます。積極的に活動している候補者を応援したり、他の誰かをノミネートしてみませんか。🙌\n\nArchish Thakkarさんは、今年特に活躍しているGitLabのコントリビューターの1人で、[46のイシューをクローズ](https://gitlab.com/groups/gitlab-org/-/issues/?sort=created_date&state=closed&assignee_username%5B%5D=archish27&first_page_size=100)し、[119ものマージリクエストをマージ](https://gitlab.com/groups/gitlab-org/-/merge_requests?assignee_username%5B%5D=archish27&first_page_size=100&sort=created_date&state=merged)してくれました。このようなすばらしい実績により、Archishさんは過去2回の[GitLabハッカソン](https://gitlab-community.gitlab.io/community-projects/merge-request-leaderboard/?&createdAfter=2024-08-26&createdBefore=2024-09-02&mergedBefore=2024-10-03&label=Hackathon)で1位に選ばれました。Archishさんは、[Middleware社の](https://middleware.io/)ソフトウェアエンジニアであり、オープンソースコントリビューターとして積極的に活動しています。\n\nArchishさんを推薦したのは、GitLabにおいてエンジニアリングの生産性を担当するスタッフバックエンドエンジニア、[Peter Leitzen](https://gitlab.com/splattael)です。GitLabのスタッフバックエンドエンジニアである[Max Woolf](https://gitlab.com/mwoolf)と、シニアバックエンドエンジニアの[James Nutt](https://gitlab.com/jnutt)も、Archishさんを推薦することに賛同しました。過去2か月間でArchishさんのコントリビュート件数は増加しており、GitLabのコードベースの改善、QoL（クオリティオブライフ）に関する複数の修正へのコントリビュート、技術的負債の削減への取り組みなど、一貫して優れた取り組みを行っています。\n\nこの場を借りて、GitLabを共同開発してくださっているArchishさん、そしてGitLabのオープンソースコントリビューターの方々に心から感謝します！\n\n## **GitLab 17.4でリリースされた主な改善点**\n\n### **開いているタブの内容をもとに、よりコンテキストを意識するようになったGitLab Duoのコード提案**\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise    \nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise   \n\n開いている他のタブの内容を使用し、よりコンテキストを意識したコード提案を提供して、コーディングワークフローを向上させます。\nこのコード提案の改善により、開いているエディタタブの内容を使用して、より関連性が高く正確なコード提案を提供できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/#use-open-tabs-as-context)  \n[イシュー](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/issues/206)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/open-tabs.gif\">\n\n### **すべてのチェックに合格した場合に自動マージ**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\nマージリクエストがマージ可能になるには、多数の必須チェックに合格する必要があります。これらのチェックには、承認、未解決のスレッド、パイプライン、その他満たす必要のある項目が含まれます。コードをマージする担当者にとって、これらのイベントをすべて追跡し、マージリクエストがマージ可能になったかどうかについてどのタイミングで改めて確認すればよいかを判断するのは難しいものです。\n\nGitLabでは本リリースから、マージリクエストのすべてのチェックで**自動マージが利用可能**になりました。自動マージを使用すると、マージを行えるユーザーなら誰でも、必要なすべてのチェックに合格する前であっても**自動マージ**が行われるようにマージリクエストを設定できます。マージ リクエストのライフサイクルが進み、前回不合格となったチェックに合格すると、自動的にマージリクエストがマージされます。\n\nこの改善により、マージリクエストのワークフローを高速化できるようになりました。[イシュー438395](https://gitlab.com/gitlab-org/gitlab/-/issues/438395)でこの機能についてのフィードバックをぜひお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/merge_requests/auto_merge.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/8128)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/10874)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/UbqAYizAFAk?si=GxUlLjpyNWmw-q3z\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### **Web IDEで拡張機能マーケットプレースが利用可能に**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: -\n\nGitLab.comのWeb IDEに拡張機能マーケットプレースが登場しました。拡張機能マーケットプレースでは、サードパーティの拡張機能を検索、インストール、管理できるため、開発体験が向上します。拡張機能によってはローカル実行環境が必要となり、Webのみのバージョンと互換性がないものもありますが、何千種類もの拡張機能から選択して、生産性を向上させたり、ワークフローをカスタマイズしたりできます。\n\nデフォルトでは、拡張機能マーケットプレースは無効になっています。利用を開始するには、[ユーザー環境設定](https://gitlab.com/-/profile/preferences)の**インテグレーション**セクションで拡張機能マーケットプレースを有効にします。[エンタープライズユーザー](https://docs.gitlab.com/ee/user/enterprise_user/)の場合は、トップレベルグループのオーナーロールを持つユーザーのみが拡張機能マーケットプレースを有効にできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/web_ide/index.html#extension-marketplace)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11769)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/extensions-marketplace.png\">\n\n### **ワークスペースでのsudoアクセスをセキュアに管理**\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\nワークスペースにおけるsudoアクセスが設定可能になり、開発環境で依存関係を直接インストール、設定、実行することがこれまで以上に簡単になりました。シームレスな開発環境を実現するために、次の3つのセキュアな方法が実装されています。\n- Sysbox\n- Kataコンテナ\n- ユーザーネームスペース\nこの機能により、ワークフローやプロジェクトのニーズに合わせて環境を完全にカスタマイズできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/workspace/configuration.html#configure-sudo-access-for-a-workspace)\n\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13983)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/sudo-access.gif\">\n\n### **Kubernetesリソースイベントの一覧表示**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabでは、ポッドとポッドのログストリームがリアルタイムで表示されます。ただし、これまでUIではリソース固有のイベント情報が表示されていなかったため、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)のデプロイをデバッグするにはサードパーティ製のツールを使用する必要がありました。今回のリリースでは、[Kubernetes用ダッシュボード](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)のリソース詳細ビューに「イベント」を追加しました。\n\nUIに「イベント」を追加するのは今回が初めてです。現在、リソース詳細ビューを開くと、イベント情報が更新されます。リアルタイムのイベントストリーミングの開発については、[イシュー470042](https://gitlab.com/gitlab-org/gitlab/-/issues/470042)で追跡できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/470041)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/kubernetes-events-list.png\">\n\n### **ワイルドカードDNSを使用しないGitLab Pagesの一般提供を開始**\n\nSaaS: -\n\nSelf-Managed: Free、Premium、Ultimate\n\nこれまでGitLab Pagesプロジェクトを作成するには、`name.example.io`や`name.pages.example.io`といった形式のドメインが必要でした。この要件を満たすには、ワイルドカードDNSレコードとTLS証明書の設定を行う必要がありました。今回のリリースでは、DNSワイルドカードを使用しないGitLab Pagesプロジェクトの作成機能を、ベータ版から一般提供へ移行しました。\n\nワイルドカード証明書の要件をなくすことで、GitLab Pages関連の管理上のオーバーヘッドが軽減されます。なお、一部のお客様は、組織におけるワイルドカードDNSレコードや証明書に関する制限のため、GitLab Pagesをご利用いただけません。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/pages/#pages-domain-without-wildcard-dns)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13404)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/z230iB-hJ3A?si=paf8_1xxggwVgsZT\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### **GitLab Pagesの並行デプロイ（ベータ版）**\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\n\n本リリースでは、GitLab Pagesの並行デプロイ（ベータ版）が導入されました。これにより、GitLab Pagesサイトの変更を簡単にプレビューし、並列デプロイを管理できるようになりました。この機能強化により、新しいアイデアの検証をスムーズに行えるため、自信を持ってサイトをテストして改良できます。問題を早期に発見することでGitLab Pagesの基盤が最適な状態となり、その上に構築された公開中のサイトを安定して洗練された状態に維持することができます。\n\nまた並列デプロイは、アプリケーションやWebサイトの複数の言語バージョンをデプロイするために、多言語化を行う場合も役立ちます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/pages/#parallel-deployments)  \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/10914)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/pages_parallel_deployments_beta.png\">\n\n### **GitLab Duo Chatによるイシューディスカッションサマリー生成**\n\nSaaS: Ultimate、Duo Enterprise\u003Cbr>\nSelf-Managed: Ultimate、Duo Enterprise\n\n長時間繰り広げられてきたイシューのディスカッションの内容を把握するには、かなりの時間がかかります。今回のリリースでは、AIによるイシューディスカッションサマリー生成機能がDuo Chatに統合され、GitLab.com、Self-Managed、およびDedicatedをご利用のお客様を対象に一般公開されました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/discussions/index.html#summarize-issue-discussions-with-duo-chat) \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/454550)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/plan-summarize-discussions-with-duo.png\">\n\n### **高度なSASTの一般提供を開始**\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\n\nGitLab Ultimateプランをご利用のすべてのお客様を対象に、高度な静的アプリケーションセキュリティテスト（SAST）スキャナーの一般提供を開始しました。\n\n高度なSASTは、今年初めに[Oxeyeから得た](https://about.gitlab.com/blog/oxeye-joins-gitlab-to-advance-application-security-capabilities/)技術を利用して新たに開発されたスキャナーです。独自の検出エンジンとともに、社内でのセキュリティ研究によって得られたルールを使用して、ファーストパーティコードに潜む悪用可能な脆弱性を特定します。これにより、より正確なスキャン結果が得られるため、デベロッパーやセキュリティチームは、誤検出の結果によるノイズを選別する必要がなくなります。\n\nGitLab 17.4には新しいスキャンエンジンに加え、次の機能が含まれます。\n\n* 脆弱性がファイルや関数を横断してどのように広がるかを追跡できる新しい[コードフロービュー](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-code-flow)\n\n* これまでのGitLab SASTスキャナーからの既存の結果を高度なSASTに「引き継げる」ようにする自動移行\n\n詳細については、[一般提供の発表に関するブログ記事](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/466322)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/secure-advanced-sast-code-flow.png\">\n\n### **CI/CD変数の値をUIで非表示にできるように**\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\n\nときには、プロジェクト設定に保存された変数の値を誰にも見られたくない場合があります。CI/CD変数の作成時に、新しく「**マスクして非表示**」を選択できるようになりました。このオプションを選択すると、CI/CD設定のUIで変数の値が永久的にマスクされ、作成後は誰にも表示されなくなるため、データが誰かに見られる危険性を低下できます。\n\n[ドキュメント](https://new.docs.gitlab.com/ci/variables/#define-a-cicd-variable-in-the-ui)\n\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/29674)\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/masked_and_hidden.png\">\n\n## **GitLab 17.4のその他の改善**\n\n### **Webhookリクエストの冪等キー**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\n本リリースから、Webhookリクエストのヘッダーで冪等キーをサポートします。冪等キーは、Webhookの再試行を複数回行っても一貫性が保たれる一意のIDであり、Webhookクライアントが再試行を検出できるようにします。統合においてWebhookの効果の冪等性を保つには、`Idempotency-Key`ヘッダーを使用してください。\n\nこの場を借りて、[コミュニティにコントリビュート](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/160952)してくれた[Van](https://gitlab.com/van.m.anderson)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#delivery-headers)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/388692)\n\n### **Wikiのサイドバーのサイズが変更可能に**\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\nWikiのサイドバーを調整して、長めのページタイトルを表示できるようになりました。これにより、全体的にコンテンツが見つけやすくなりました。Wikiコンテンツが充実するにつれて、階層が複雑になったり表示されるページが膨大になったりしますが、サイドバーのサイズ変更が可能になったことでWikiの運用が効率的になり、管理、閲覧しやすくなりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/wiki/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/154167)\n\n### **コードインテリジェンス用CI/CDコンポーネント**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabのコードインテリジェンスは、リポジトリを閲覧する際のコードナビゲーション機能を提供します。コードナビゲーションを開始する際は、CI/CDジョブを設定する必要があるため、複雑になりがちです。正しい出力と成果物を得るには、この作業を行う際にカスタムスクリプトが必要になる場合があります。\n\nGitLabでは本リリースから、簡単に設定を行えるように、公式の[コードインテリジェンス用CI/CDコンポーネント](https://gitlab.com/explore/catalog/components/code-intelligence)をサポートするようになりました。[コンポーネントの使い方](https://docs.gitlab.com/ee/ci/components/index.html#use-a-component)の手順に従って、このコンポーネントをプロジェクトに追加してください。これにより、GitLabでのコードインテリジェンスの導入が大幅に簡素化されます。\n\n現在、このコンポーネントでは次の言語をサポートしています。\n\n* Goバージョン1.21以降\n\n* TypeScriptまたはJavaScript\n\nこのコンポーネントの対応言語の拡大を検討するために、[利用可能なSCIP Indexer](https://github.com/sourcegraph/scip?tab=readme-ov-file#tools-using-scip)の評価を今後も続ける予定です。対応言語の追加に興味がある場合は、[コードインテリジェンスコンポーネント](https://gitlab.com/components/code-intelligence)プロジェクトでマージリクエストを作成してください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/code_intelligence.html#with-the-cicd-component)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/480401)  \n\n### **GitLab Runner 17.4**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\n本日、GitLab Runner 17.4もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドエージェントです。GitLab Runnerは、GitLabに組み込まれたオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\n新機能：\n\n* [Azure Compute用GitLab Runnerフリートプラグイン（一般公開）](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29223)\n\nバグの修正：\n\n* [Kubernetes executorジョブが完了前にキャンセルされた場合、ジョブログの`after_script` セクションに`step_script`のすべての内容が表示される](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37952)\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/17-4-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### **保護された環境への非デプロイジョブが手動ジョブにならないように**\n\nSaaS: Premium、Ultimate    \nSelf-Managed: Premium、Ultimate\n\n実装上の問題により、保護された環境で`action: prepare`、`action: verify`、`action: access`ジョブを実行した場合、手動ジョブになります。これらのジョブを実行するには、手動での操作が必要となりますが、追加の承認は必要ありません。\n\n[イシュー390025](https://gitlab.com/gitlab-org/gitlab/-/issues/390025)では、これらのジョブが手動ジョブにならないようにするために、実装に修正を加えることを提案しています。この提案が実装された後で現在の挙動が維持されるようにするには、[明示的にジョブを手動に設定する](https://docs.gitlab.com/ee/ci/jobs/job_control.html#types-of-manual-jobs)必要があります。\n\n現時点では、`prevent_blocking_non_deployment_jobs`機能フラグを有効にすることで、新しい実装に移行できます。\n\n破壊的な変更はすべて、`environment.action: prepare | verify | access`値の挙動を区別するために提案されています。`environment.action: access`キーワードを指定すると、現在の動作に最も近い形で維持されます。\n\n将来的に互換性の問題が発生しないように、これらのキーワードの使用方法を今すぐ見直してください。提案の詳細については、次のイシューを参照してください。\n\n* [イシュー437132](https://gitlab.com/gitlab-org/gitlab/-/issues/437132)\n\n* [イシュー437133](https://gitlab.com/gitlab-org/gitlab/-/issues/437133)\n\n* [イシュー437142](https://gitlab.com/gitlab-org/gitlab/-/issues/437142)\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/jobs/job_control.html#types-of-manual-jobs)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/390025)\n\n### **削除されたSASTアナライザーの自動クリーンアップ**\n\nSaaS: Ultimate    \nSelf-Managed: Ultimate\n\n[GitLab 17.0](https://docs.gitlab.com/ee/update/deprecations.html#sast-analyzer-coverage-changing-in-gitlab-170)、[16.0](https://docs.gitlab.com/ee/update/deprecations.html#sast-analyzer-coverage-changing-in-gitlab-160)、[15.4](https://docs.gitlab.com/ee/update/deprecations.html#sast-analyzer-consolidation-and-cicd-template-changes)ではGitLab SASTを効率化し、より少ない個別のアナライザーでコードの脆弱性をスキャンできるようにしました。\n\n本リリースでは、GitLab 17.3.1以降のバージョンにアップグレードした後で、データ移行を一度だけ行えば、[サポートが終了したアナライザー](https://docs.gitlab.com/ee/user/application_security/sast/#end-of-supported-analyzers)の検出対象である脆弱性が自動的に修正されるようになりました。これにより、脆弱性レポートがクリーンアップされるため、最新のアナライザーによって検出された脆弱性に集中して対応できます。\n\nデータ移行を行うと、確認または却下されていない脆弱性のみが修正されます。[Semgrepベースのスキャンに自動的に変換](https://docs.gitlab.com/ee/user/application_security/sast/analyzers/#transition-to-semgrep-based-scanning)された脆弱性には、影響は生じません。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/#end-of-supported-analyzers)\n\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/444926)\n\n### **CycloneDX 1.6のSBOMのインジェストをサポート**\n\nSaaS: Ultimate    \nSelf-Managed: Ultimate\n\nGitLab 15.3では、CycloneDX SBOMの[インジェスト](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscyclonedx)がサポートされました。\n\nこの度、GitLab 17.4では、CycloneDXバージョン1.6のSBOMのインジェストを新たにサポートするようになりました。\n\n現時点では、ハードウェア（HBOM）、サービス（SaaSBOM）、AI/MLモデル（AI/ML-BOM）関連のフィールドはサポート対象外です。これらのBOMの関連データを含むSBOMは処理されるものの、データは分析されず、ユーザーにも提示されません。こうした他の種類のBOMのサポートについては、[こちらのエピック](https://gitlab.com/groups/gitlab-org/-/epics/14989)で追跡されています。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscyclonedx)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/472837)\n\n### **トークンの有効期限設定オプション**\n\nSaaS: -\n\nSelf-Managed: Free、Premium、Ultimate\n\n個人、プロジェクト、グループ用のアクセストークンに有効期限の設定を必須にするかどうかを、管理者が決められるようになりました。この設定を管理者が無効にした場合、新たに生成されるアクセストークンでは有効期限の設定が不要になります。デフォルトではこの設定は有効になっており、有効期限を設定する際は許可されている最大有効期間よりも短くする必要があります。この設定は、GitLab 16.11以降のバージョンで利用可能です。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#require-expiration-dates-for-new-access-tokens)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/470192)\n\n### **パイプライン実行ポリシーで競合するジョブ名のサフィックスをサポート**\n\nSaaS: Ultimate    \nSelf-Managed: Ultimate\n\n[17.2リリースで追加されたパイプライン実行ポリシー](https://about.gitlab.com/ja-jp/blog/gitlab-17-2-released/)が拡張され、ポリシー作成者はジョブ名が重複した場合に適切に処理されるよう、パイプライン実行ポリシーを設定できるようになりました。パイプライン実行ポリシーの`policy.yml`で、次のオプションを設定できるようになりました。\n\n* `suffix: on_conflict`：重複が適切に処理されるように、ポリシーのジョブ名を変更するよう、ポリシーを設定します。今後は、これがデフォルトの動作です。\n\n* `suffix: never`：すべてのジョブ名が一意となるように強制し、重複が発生した場合はパイプラインが失敗します。17.2以降のバージョンでは、これがデフォルトの動作でした。\n\nこの改善により、パイプライン実行ポリシー内でセキュリティとコンプライアンスのジョブが必ず実行されるようになると同時に、下流工程のデベロッパーに不要な影響を及ぼすことのないように防ぐことができます。\n\n次の機能拡張では、ポリシーエディタ内でこの設定オプションを導入する予定です。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html#pipeline-execution-policy-schema)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/473189)  \n\n### **オムニバスの改善**\n\nSaaS: -\n\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 17.4を新規インストールすると、デフォルトでPostgreSQL 16が含まれます。\n\nGitLab 17.7では、OpenSSL V3が含まれます。これは、TLS証明書の112ビット以上の暗号化とともに、送信接続用のTLS 1.2以上の最低要件を満たしていない外部統合設定のオムニバスインスタンスに影響を与えます。ご自身のインスタンスが影響を受けるか等の詳細を確認したい場合は、[OpenSSLのアップグレードに関するドキュメント](https://docs.gitlab.com/omnibus/settings/ssl/openssl_3.html)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/omnibus/)\n\n### **グループAPIでドメインごとにグループアクセスを制限**\n\nSaaS: Premium、Ultimate    \nSelf-Managed: Premium、Ultimate\n\nこれまでは、ドメイン制限はUIでグループレベルでのみしか追加できませんでした。本リリースでは、グループAPIに追加された`allowed_email_domains_list`属性を使用してドメイン制限を行えるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/groups.html#update-group)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/351494)\n\n### **失敗したWebhookリクエストをAPIから再送信可能に**\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabではこれまで、Webhookリクエストの再送信機能をUIでのみ提供していましたが、リクエストが多数失敗した場合、この方法は非効率的でした。\n\n本リリースでは、コミュニティメンバーからのコントリビュートにより、失敗したWebhookリクエストをプログラムによって処理できるように、再送信用のAPIエンドポイントが追加されました。\n\n* [プロジェクトのWebhookリクエスト](https://docs.gitlab.com/ee/api/projects.html#resend-project-hook-event)\n\n* [グループのWebhookリクエスト](https://docs.gitlab.com/ee/api/groups.html#resend-group-hook-event)（PremiumおよびUltimateプランのみ）\n\n次の方法で再送信を行えるようになりました。\n\n1. [プロジェクトフック](https://docs.gitlab.com/ee/api/projects.html#get-project-hook-events)または[グループフック](https://docs.gitlab.com/ee/api/groups.html#get-group-hook-events)イベントのリストを取得します。\n\n2. リストをフィルタリングして、失敗したものを表示します。\n\n3. イベントの`id`を使用して再送信します。\n\nこの場を借りて、[コミュニティにコントリビュート](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/151130)してくれた[Phawin](https://gitlab.com/lifez)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/api/projects.html#resend-project-hook-event)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/372826)\n\n### **JetBrains IDEでOAuthを使用してGitLab Duoを認証**\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\nJetBrains用GitLab Duoプラグインの開始プロセスが、これまでよりも安全かつ効率的になりました。OAuthを使用して、すばやく安全にサインインできます。パーソナルアクセストークンは不要で、既存のワークフローとシームレスに統合されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/editor_extensions/jetbrains_ide/#configure-the-extension)  \n[エピック](https://gitlab.com/groups/gitlab-org/editor-extensions/-/epics/70)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/ZOTFWbpBBHI?si=Qv-BD5cy6KxMP2Tz\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### **リンクしたファイルがマージリクエスト内で最初に表示されるように**\n\nSaaS: Free、Premium、Ultimate\n\nSelf-Managed: Free、Premium、Ultimate\n\nマージリクエストで特定のファイルへのリンクを共有する目的は、通常はそのファイル内に含まれる内容を見てもらうことです。これまでマージリクエストでは、すべてのファイルが読み込まれてから、参照した特定の位置までスクロールする必要がありました。本リリースから、以下の方法でファイルに直リンクすることで、マージリクエストでの共同作業のスピードを効果的に向上させることができるようになりました。\n\n1. 最初に表示したいファイルを見つけます。ファイル名を右クリックして、リンクをコピーします。\n\n2. そのリンクにアクセスすると、選択したファイルがリストの一番上に表示されます。ファイルブラウザでは、ファイル名の横にリンクアイコンが表示されます。\n\nファイルのリンクに関するフィードバックは、[イシュー439582](https://gitlab.com/gitlab-org/gitlab/-/issues/439582)で投稿できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/merge_requests/changes.html#show-a-linked-file-first)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/387246)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/create-linked-files.png\">\n\n### **テストカバレッジ可視化のためにJaCoCoのサポートを開始（ベータ版）**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\nマージリクエスト内で、カバレッジ計測の標準として人気のあるJaCoCoのカバレッジレポートを使用できるようになりました。この機能はベータ版として提供されていますが、JaCoCoのカバレッジレポートをすぐに使用したい方なら誰でもテストできます。フィードバックがございましたら、ぜひ[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/479804)でお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization/jacoco.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/227345)\n\n### **クラスターUIからFluxの調整をトリガー**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\n指定した間隔で調整がトリガーされるようにFluxを設定できるものの、状況によってはすぐに調整を行いたいこともあります。これまでのリリースでは、CI/CDパイプラインまたはコマンドラインから調整をトリガーできました。GitLab 17.4では、追加の設定なしでKubernetes用ダッシュボードから調整をトリガーできるようになりました。\n\n調整をトリガーするには、設定済みのダッシュボードに移動し、Fluxのステータスバッジを選択します。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/434248)\n\n### **シークレット検出でのAnthropic APIキーのサポート**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\nパイプラインとクライアントサイドのシークレット検出の両方で、[Anthropic](https://www.anthropic.com/) APIキーの検出をサポートしました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/detected_secrets.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/481547)\n\n### **セキュリティポリシーにリンクされているプロジェクトのパイプライン実行YAMLファイルへの読み取りアクセスを許可**\n\nSaaS: Ultimate    \nSelf-Managed: Ultimate\n\nGitLab 17.4では、セキュリティポリシーの設定が追加され、リンクされているすべてのプロジェクトの`pipeline-execution.yml`ファイルへの読み取りアクセスを許可できるようになりました。この設定を使用すると、パイプラインの実行を行うユーザー、ボット、トークンをプロジェクト全体でグローバルかつより柔軟に指定できます。たとえば、グループやプロジェクトのアクセストークンがセキュリティポリシー構成を読み取り、パイプラインをトリガーできるようになります。引き続き、直接セキュリティポリシープロジェクトのリポジトリや[YAML](https://about.gitlab.com/ja-jp/blog/what-is-yaml/)を参照することはできません。この設定は、パイプラインの作成中にのみ使用できます。\n\n設定を行うには、共有したいセキュリティポリシープロジェクトに移動します。**「設定」 > 「一般」 > 「表示レベル、プロジェクトの機能、権限」**の順に選択し、**「パイプライン実行ポリシー」** までスクロールします。次に、**「セキュリティポリシープロジェクトソースとしてリンクされているプロジェクトに対して、このリポジトリへのアクセスを許可する」** を有効にします。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/469439)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/grant-access-to-spp.png\">\n\n### **複数のコンプライアンスフレームワークでの検索**\n\nSaaS: Premium、Ultimate\n\nSelf-Managed: Premium、Ultimate\n\nGitLab 17.3では、プロジェクトに複数のコンプライアンスフレームワークを追加できるようになりました。\n\n本リリースでは、複数のコンプライアンスフレームワークを指定して検索できるようになりました。これにより、複数のコンプライアンスフレームワークが設定されているプロジェクトをより簡単に検索できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/462943)\n\n### **グループやプロジェクトメンバーのソース列の表示内容を改善**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate    \n\nグループとプロジェクトのメンバーページでのソース列の表示内容を簡素化しました。ダイレクトメンバーは引き続き、`Direct member`として表示されます。継承メンバーの場合、`Inherited from`という文字列に続いて、グループ名が表示されるようになりました。グループが招待されたことで追加されたメンバーは、`Invited group`という文字列に続いて、グループ名が表示されます。また、本リリースから、グループが招待されて追加されたメンバーがその後に継承された場合、メンバーシップを管理するユーザーに必要な情報として、最後に発生したイベントが表示されるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/members/#membership-types)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/431066)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_4/data-stores_member-source.png\">\n\n### **グループまたはプロジェクトAPIを使用して、グループやプロジェクトに招待されたグループを一覧表示**\n\nSaaS: Free、Premium、Ultimate    \nSelf-Managed: Free、Premium、Ultimate\n\nグループAPIとプロジェクトAPIに新しいエンドポイントを追加しました。これにより、グループまたはプロジェクトに招待されたグループを取得できるようになりました。この機能は、グループまたはプロジェクトのメンバーページでのみ利用できます。このエンドポイントの追加により、グループやプロジェクトにおけるメンバーシップ管理がより簡単に自動化できるようになります。なお、このエンドポイントには、ユーザーあたり毎分60件のリクエストのレート制限が設定されています。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/groups.html#list-a-groups-invited-groups)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/465207)\n\n### **GitLab Duoシートの割り当てに関する通知メール**\n\nSaaS: -\n\nSelf-Managed: Premium、Ultimate、Duo Pro\n\nSelf-Managedインスタンスのユーザーには、GitLab Duoシートが割り当てられるとメールが届くようになりました。これまでは、ほかのユーザーに教えてもらうか、GitLab UIに新しい機能が表示されるようになったことに気付かない限り、シートが割り当てられたことはわかりませんでした。\n\n管理者は`duo_seat_assignment_email_for_sm`という名前の機能フラグを無効にすることで、このメール通知を無効にできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/subscriptions/subscription-add-ons.html#assign-gitlab-duo-seats)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/164104)\n\n## **バグ修正、パフォーマンスの改善、UIの改善**\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験を届けることを約束します。\n\n以下のリンクをクリックして、17.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=17.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=17.4)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.4) \n\n## **非推奨事項**\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードをサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n-   [よく利用されるユーザー、プロジェクト、グループAPIのエンドポイントに対するレート制限](https://docs.gitlab.com/ee/update/deprecations.html#rate-limits-for-common-user-project-and-group-api-endpoints)  \n-   [\\`add\\_on\\_purchase\\` GraphQLフィールドの\\`add\\_on\\_purchases\\`への置き換え](https://docs.gitlab.com/ee/update/deprecations.html#replace-add_on_purchase-graphql-field-with-add_on_purchases)  \n-   [セキュアコンテナレジストリの一般利用の非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#public-use-of-secure-container-registries-is-deprecated)  \n-   [\\`heroku/builder:22\\`イメージの非推奨化](https://docs.gitlab.com/ee/update/deprecations.html#the-herokubuilder22-image-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## **GitLabのアップグレードに関する重要なお知らせ** \n\nバックグラウンドでの移行が完了されるようにするには、GitLab 17.4にアップグレードする前に、まずは[GitLab 17.3](https://about.gitlab.com/ja-jp/blog/gitlab-17-3-released/)にアップグレードする必要があります。  \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ワークフロー](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  個人ユーザー向けの永久無料機能を提供\n\n* [Premiumプラン](https://about.gitlab.com/pricing/premium/) \n\n  チームの生産性と調整を強化\n\n* [Ultimateプラン](https://about.gitlab.com/pricing/ultimate/) \n\n  組織全体のセキュリティ、コンプライアンス、プランニングに対応\n\n> GitLabのすべての機能を[無料](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)でお試しいただけます。\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) \u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],"2025-01-07",{"slug":2865,"featured":92,"template":681},"gitlab-17-4-released","content:ja-jp:blog:gitlab-17-4-released.yml","Gitlab 17 4 Released","ja-jp/blog/gitlab-17-4-released.yml","ja-jp/blog/gitlab-17-4-released",{"_path":2871,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2872,"content":2878,"config":2884,"_id":2886,"_type":16,"title":2887,"_source":17,"_file":2888,"_stem":2889,"_extension":20},"/ja-jp/blog/what-is-an-okr",{"title":2873,"description":2874,"ogTitle":2873,"ogDescription":2874,"noIndex":6,"ogImage":2875,"ogUrl":2876,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2876,"schema":2877},"OKRとは？ 導入や運用、MBOやKPIとの違い徹底解説","OKRについて、その意味や設定方法、導入、運用までを解説。MBOとの違いやエンジニア向けOKR導入の支援ツールについても詳しく説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663217/Blog/Hero%20Images/AdobeStock_790549874.jpg","https://about.gitlab.com/blog/what-is-an-okr","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"OKRとは？ 導入や運用、MBOやKPIとの違い徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-09-06\",\n      }",{"title":2873,"description":2874,"authors":2879,"heroImage":2875,"date":2880,"body":2881,"category":2135,"tags":2882},[738],"2024-09-06","## OKR（Objectives and Key Results）とは？\n\nOKRとは、「Objectives and Key Results（目標と成果指標）」のことで、目標と成果指標を関連づけた目標管理方法のひとつです。OKRを活用することで、組織、チーム、個人が目指すゴールを共有しやすくなります。また、OKRは短期間での見直し、再設定を繰り返して運用するため、組織やプロジェクトメンバーの変化にも柔軟に対応できます。OKRは1970年代にアメリカのインテル社が導入したことをはじめ、Googleやメルカリ、Sansanなどの大企業で採用されています。\n\n## OKRの2つの目標設定方法とその使い分け \n目標管理の手法であるOKRは、企業の目標を部署や個人の目標とリンクさせて設定することが特徴です。企業の目標と部署や個人の目標を関連づけることで、高いモチベーション維持や連帯感の強化が期待できます。OKRの「Objectives（目標）」は、定性的でモチベーションアップにつながるもの、1-3ヶ月程度で達成できるものを設定します。「Key Results（成果指標）」は、達成難度を高めに設定し、60〜70%の達成度を現実的な目標として設定します。月または四半期といった短期間で目標設定、評価、最適化のサイクルを回します。OKRには2種類の目標設定方法があり、ひとつは、「ムーンショット」と呼ばれるもので「月に届く」ように難易度が高いものです。達成度は60%程度で成功とみなし、メンバーのチャレンジ精神やイノベーションを支援するものが目的です。もう1つは「ルーフショット」と呼ばれるもので、「屋根に届く」程度の難易度の目標を設定します。達成度は100%で成功とされ、確実に達成できる目標を設定します。一般的にOKRには「ムーンショット」が適しているとされていますが、導入初期など、まだOKRに慣れていない場合には「ルーフショット」を活用して、OKRが定着させるのがおすすめです。\n\n## OKRとMBOの違いとは？  \n目標管理方法には、OKRのほかにMBO（Management by Objectives）があります。OKRが定性的な目標と定量的な成果目標を組み合わせてサイクルを短期間で回すのに対して、MBOでは、社員それぞれの目標を企業の経営目標や部門の目標と連動させて業績アップにつなげます。それぞれのメリット・デメリットを把握して、チームの状態に合わせた目標管理手法を選びましょう。 \n\n### OKRのメリット・デメリット\nメリット\n\n* 月に一回、四半期などのサイクルで目標と成果指標を見直すため、柔軟に変更できる  \n* 高い目標設定とそれぞれに合わせた成果指標で、チームメンバーのモチベーションが維持できる \n\nデメリット\n\n* 全社的な取り組みとなるため、導入初期に時間と労力がかかる  \n* OKRを使ったことのある人が少ない（大手企業に限られがち）\n\n### MBOのメリット・デメリット  \nメリット \n\n* 目標を個人が設定するため、自主性が重んじられる  \n* 課題達成型でタスク管理がしやすい\n\nデメリット\n\n* 個人と組織の目標がずれる場合がある  \n* 部下の評価を行う管理職の精神的・時間的負担が大きくなりがち\n\n## OKRとKPIの違いとは？\n\nOKRとMBOはともに「Objective（目標）」を管理する手法でしたが、成果やパフォーマンスを図る指標には、OKRのほかにKPI（Key Performance Indicator）があります。OKRとKPIはどのように違うのでしょうか。下記の３つの項目について整理してみましょう。\n\n### 目的と焦点\n\nOKRは、目標（Objectives）とその達成に必要な鍵となる成果（Key Results）に焦点を当てて、組織やチームが達成したい大きな目標の達成度合いを定量的に測定します。一方KPIは、組織やチームのパフォーマンスを測定するための指標です。一般的に売上高、利益率、顧客満足度などが指標となり、ビジネスの健全性や成功を評価するのに使われます。\n\n### 範囲と対象\n\nOKRでは、組織やチーム全体の戦略的な目標や重要な取り組みに向けて成果を設定し、目標の達成度合いを測定し、進捗状況を追跡します。それに対して KPIは、特定のプロジェクト、部門、または個々の業務に関連するパフォーマンスを測定するために使用されます。KPIは、特定の業務やプロセスの効率性や成果の評価に使用されます。\n\n### 柔軟性と透明性\n\nOKRは、定期的なレビューやフィードバックを通じて目標を修正するため、柔軟性が高いことがメリットです。それぞれの目標は、チームや他のメンバーと共有されるため、透明性も高めます。一方KPIは、一度定めた指標は固定されることが多く、ほとんどの場合、定期的な見直しなどはありません。また、上級管理職や特定のチームによって管理され、外部に公開されることも滅多にありません。\n\nOKRとKPIは、それぞれ異なる目的や特性を持ちますが、ともに組織やチームの目標達成を促進する指標として、補完的に使用することができます。\n\n## なぜOKR？ OKRを導入する理由とは\n目標管理ツールであるOKRを導入することで期待される成果は大きく４つあります。 \n\n### 企業の目標を明確に共有できるため、組織としての一体感が期待できる\nOKRでは、まず企業としての大きな目標を設定し、その目標に対して各部署、プロジェクトチーム、社員一人ひとりの目標や具体的なアクションに落とし込んでいきます。このため、すべてのメンバーが最終的には企業の大きな目標達成を目指しているという一体感が持ちやすくなります。\n\n### 大きな目標に挑戦できる \nさきほどご紹介した２種類の目標設定方法の中でも、ムーンショットは60％ほどの達成率で成功とされるため、大きな目標を掲げて短いサイクルで取り組むことで、それに向かって何度も挑戦する経験を得られます。これにより、自然と大きな目標に取り組む姿勢が身につきます。\n\n### 部署間のコミュニケーションを促進   \n企業の目標を共有したうえで各部門の目標・成果指標が定められているため、同じ目標に向かってそれぞれの部門や個人がどう取り組むのかといった、部門間のコミュニケーションが期待できます。\n\n### モチベーションとエンゲージメントの向上\nOKRでは、社員の成果指標が企業の目標と紐づいているため、自分が何のためにこのタスクに携わっているかを日々意識することになります。自分の仕事が企業にどのように貢献しているか意識することで、モチベーションとエンゲージメントが向上すると考えられています。\n\n### 効果的なOKRの設定方法、運用方法とは？\nOKRの目的（Objectives）の設定では、「挑戦的であるか」「魅力的かどうか」「一貫性があるか」に注意します。次に成果指標（Key Results ) に関しては、「目的と関連性があるか」「計測可能か」「容易ではないが、達成が可能か」「重要なものにフォーカスしているか」という4点に基づき設定します。成果指標が達成されても目的が達成されないOKRの設定とは適切ではありません。これらの点に気をつけて設定した各部門や個人のOKRをチームで確認・運用します。一度設定したOKRは、1ヶ月または3ヶ月ごとに見直し、週1回程度のミーティングで進捗を確認し、必要であれば成果指標を調整します。\n\n## OKRがエンジニア部門にもたらすメリットと導入事例\nOKRの導入により、エンジニア部門が抱える以下のような課題が解決されます。\n\n* やっている業務が他部署に理解されづらい  \n* 運用部門など他の部門との連携が難しい  \n* エンジニア個人の成果が見えづらくエンゲージメントやモチベーションが低い  \n* 会社の目標とエンジニア部門の目標がリンクしづらい\n\n高度な専門性を求められる業務内容や、在宅・フレックス勤務を含む多様な勤務体制など、他部署と異なる部分も多く、他部署からの理解を得づらい場面もあるエンジニア部門。定性的な会社の目標やビジョンとエンジニア部門の目標が乖離してしまうこともしばしば起こります。OKRは、そんなエンジニア部門の課題を解決できるかもしれません。OKRがエンジニア部門にもたらすメリットを導入事例と共に見てみましょう。\n\n### Google \nGoogleでは2000年ごろから導入を開始し、3ヶ月ごとにOKRを見直し、定期的なミーティングでOKRの評価を行なっています。達成度は70%程度に設定され、作業の進捗や評価内容は全スタッフで共有、確認できるようになっています。わかりづらかったエンジニア部門のタスク内容や進捗が明確化され、部門間の連携強化につながっています。全社的に浸透度も高く、OKRの導入がGoogleを世界規模の会社へ押し上げたとの見方もあります。\n\n### メルカリ\n企業が急成長した2015年ごろより導入を開始。OKRとしてエンジニアは、担当するプロジェクトの他に「新しい技術習得」などの個人的なOKRも設定しています。定期的にエンジニアチームのマネージャーと進捗確認や振り返りを行いながら、OKRを運用します。マネージャーと成果目標を定めることで、チームの成長とエンジニアの成長がリンクし、エンジニア部門全体でモチベーションアップを実現しています。\n\n### Sansan\nMBOを採用していたものの、会社の目標とエンジニア部門の目標がリンクしづらくOKRに変更。会社の方針を受けて部門の方針を決め、その中で個人のOKRを設定することで、開発するプロダクトの方向性や業務の意義をエンジニアが理解しやすくなりました。また全社で掲げる定性的な目標への貢献度とOKRの達成度をバランスよく参考するなどし、独自の人事評価にもOKRを取り入れています。\n\n## OKR導入はツールで自動化するのがおすすめ  \nここまでOKR導入が企業にもたらすメリットについて述べてきましたが、どのようにOKRを始めたらいいのかお悩みの方もいらっしゃるのではないでしょうか。全社でOKRを導入するとなると管理にあてるリソースが増えてしまうことも事実です。企業が抱える課題に対する認識の共有や、短期的に見直されるOKRの内容、頻繁に変更される評価指標などをわかりやすく管理しなくてはなりません。こういった煩雑なステップを統括してくれるのがOKR支援ツールです。ツールを使うことで、目標の設定や成果指標の変更、社内共有までを一元管理できます。また、タスクに割り当てるユーザーの設定やタスク進捗の追跡なども簡単な操作で行うことができます。エンジニアなど特定業種に特化したOKR導入支援ツールもあり、運用までのすべてのステップを一括でサポートしてくれます。\n\n## OKR導入にあたってGitLabができること \nOKRの導入、運用を包括的にサポートし実現するAPIツールが「[GitLab](https://about.gitlab.com/ja-jp/)」です。GitLabなら、OKRの導入から運用までに必要な内容が一元管理できます。最適なOKRの設計、タスクの割り当て、進捗の共有など、OKRに必要なさまざまな業務を効率的に実施できます。初心者にも使いやすいUIや、[DevSecOps](https://about.gitlab.com/ja-jp/platform/)に強いGitLabならではのセキュアな環境を提供し、エンジニア部門だけでなく運用部門も含めて全社的に使っていただける「OKRの導入に最適なツール」です。\n\n## OKRについてよくある質問  \n### OKRはどんな意味ですか？\nOKRとは、「Objectives and Key Results」の略で、「目標と成果指標」などと呼ばれる目標管理手法のひとつです。\n\n### OKRとKPIの違いは何ですか？\nOKRは、企業としての目標から逆算された高い目標（60〜70%の達成を目指す）に向けて、よりイノベーティブな成長を目指す指標とされ、人事評価と強く結びつけないことがほとんどです。一方KPIは、最終目標に対してプロセスごとの定量的ゴールを設定し、目標達成のための成果進捗管理が主な役割となります。KPIでは、業績の向上に直結する指標を使って100%達成を目指す目標を設定します。\n\n### OKRを導入するときに気をつけることを教えてください   \n導入の際に気をつけるポイントとしては、以下の４つが挙げられます。\n\n* OKRは社内全体で公開、共有する  \n* 月1回または四半期に1回、内容確認を行い、成果指標などを最適化する  \n* OKRは、60〜70%の達成度でも成功とするチャレンジングな目標とする  \n* OKRの導入や運用の負担を軽減するため、適切なツールを導入することが望ましい\n\nOKRを始めるには、特化した支援ツールの導入がおすすめです。簡単かつ安全にOKRを自動化するなら[GitLab](https://about.gitlab.com/ja-jp/)にお問合せください。",[677,2883,547],"growth",{"slug":2885,"featured":6,"template":681},"what-is-an-okr","content:ja-jp:blog:what-is-an-okr.yml","What Is An Okr","ja-jp/blog/what-is-an-okr.yml","ja-jp/blog/what-is-an-okr",{"_path":2891,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2892,"content":2898,"config":2905,"_id":2907,"_type":16,"title":2908,"_source":17,"_file":2909,"_stem":2910,"_extension":20},"/ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"title":2893,"description":2894,"ogTitle":2893,"ogDescription":2894,"noIndex":6,"ogImage":2895,"ogUrl":2896,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2896,"schema":2897},"『2024 Gartner ® Magic Quadrant™』のDevOpsプラットフォーム部門でGitLabがリーダーの1社に位置付け","GitLabは、Ability to execute（実行能力）とCompleteness of vision（ビジョンの完全性）の両分野で最高評価を獲得しました。これは、当社のお客様の成功とDevOpsカテゴリでの継続的なイノベーションが評価された結果と考えられます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"『2024 Gartner ® Magic Quadrant™』のDevOpsプラットフォーム部門でGitLabがリーダーの1社に位置付け\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2024-09-05\",\n      }",{"title":2893,"description":2894,"authors":2899,"heroImage":2895,"date":2901,"body":2902,"category":700,"tags":2903,"updatedDate":2904},[2900],"Ashley Kramer","2024-09-05","DevOpsはもともと、従来は別々に動いていたチームを1つにまとめ、ソフトウェアをより迅速に提供するための単なる概念であり、開発手法に過ぎませんでした。言い換えると、ソフトウェアを開発する人々とデプロイする人々が分断されていることで生じるあらゆる問題への対応策でした。\n\nGitLabでは、その概念をさらに発展させ、ツールをつなぎ合わせた複雑なDevOpsツールチェーンではなく、[単一のDevOpsプラットフォーム](https://about.gitlab.com/ja-jp/platform/)を開発することで、より緊密なコラボレーション、より高度な自動化、そして、よりスケーラブルで標準化されたプロセスを実現しました。\n\n当社は、お客様の成功に焦点を当てるというこの戦略が正しかったと信じています。[今回で第2回目となる](https://about.gitlab.com/gartner-magic-quadrant/)『Gartner ® Magic Quadrant™』のDevOpsプラットフォーム部門で、GitLabは再びリーダーの評価を受けました。今回はAbility to execute（実行能力 ）とCompleteness of Vision（ビジョンの完全性）の両分野で最高評価を獲得しています。\n\n![『2024 Gartner Magic Quadrant for DevOps Platforms』の画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674334/Blog/Content%20Images/figure1.png)\n\n> [『2024 Gartner ® Magic Quadrant™』のDevOpsプラットフォーム部門に関するレポート](https://about.gitlab.com/ja-jp/gartner-magic-quadrant/)をダウンロードしましょう。\n\n昨今において、ソフトウェア企業は、増大するセキュリティの脅威や複雑なコンプライアンス要件に対応すると同時に、生成AIのような新技術を慎重に導入するといった課題に直面しています。これに加えて、スケーラブルなサービスを提供し続け、顧客に対して継続的なイノベーションを約束するという使命も果たさなければなりません。\n\nGitLabは、お客様がこれらの課題に対処し、業界のリーダーとしての地位を確立できるようサポートします。当社のAI搭載のDevSecOpsプラットフォームを使用すると、お客様はセキュリティのシフトレフトを実行し、開発ライフサイクル全体での可視性を確保し、世界に影響を与えるソフトウェアの提供に必要なすべての役割と責任を1つにまとめられます。\n\n## DevOpsビジョンの促進\n\nGitLabは進化を続けます。DevOpsのビジョンをさらに革新し、DevSecOpsプラットフォームを2つの方法で進化させます。\n\n1つ目は、[アジャイル計画](https://about.gitlab.com/blog/categories/agile-planning/)、[データサイエンス](https://about.gitlab.com/ja-jp/topics/devops/the-role-of-ai-in-devops/)、[可観測性やアプリケーションのモニタリング](https://docs.gitlab.com/operations/observability/)に関わるチームに特化した機能を提供することで、より多くのチームが同じプラットフォームでコラボレーションできるようにするというものです。\n\nそして2つ目が、お客様の多様なニーズに対応するために、プラットフォームの導入やデプロイにおいて、より柔軟な選択肢を用意するというものです。その選択肢のひとつが、シングルテナントのホスティングオプションである[GitLab Dedicated](https://about.gitlab.com/ja-jp/dedicated/)への投資です。これにより、厳格な規制が定められる業界の企業が、分離されたインフラストラクチャのコンプライアンス要件を満たしつつ、SaaSのシンプルさとすべての最新機能の利点を享受できるようになります。\n\n## 組織が安全なソフトウェアを構築できるよう支援\n\nGitLabでは、より優れたソフトウェアデリバリー向けコラボレーションプラットフォームの構築に加えて、組織がより安全でコンプライアンスに準拠したソフトウェアを構築できるよう支援することを最重要事項のひとつとしています。このビジョンに基づき、GitLabは、他社とは異なり、アプリケーションのリリース直前ではなく、コードコミットの段階に[セキュリティスキャン](https://about.gitlab.com/ja-jp/solutions/security-compliance/)を組み込んでいます。これにより、チームは脆弱性を早期に発見し、リリースサイクルを迅速化できます。さらに、GitLabはポリシーのガードレール設定機能や、[ソフトウェア部品表](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)の自動生成機能により、コンプライアンス対応を容易にします。\n\n当社では、ソフトウェアのアタックサーフェス（攻撃対象領域）が拡大するにつれて、お客様がより多くのセキュリティ脅威に直面していることを認識しています。こうした現状を受けて、GitLabは今後12か月間にわたり、SASTスキャナーの改善、追加のポリシー管理機能の導入、そして新たな[ネイティブシークレットマネージャー](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/)の開発を計画しています。\n\n## ソフトウェア開発ライフサイクル全体（SDLC）でのAI活用で業界をリード\n\n当社は、AIの分野でリーダーになるというビジョンも掲げています。これには、お客様がAIを活用して革新的なソフトウェアを開発できるよう支援するだけでなく、プライバシーを最優先に考えたAI技術を提供することも含まれています。AIは、SDLCのすべての段階に組み込むことで、非常に大きな可能性や改善の機会をもたらします。当社は、イノベーションの創出に責任を持って取り組んでいます。お客様は、[ガードレールが確保され](https://about.gitlab.com/the-source/ai/velocity-with-guardrails-ai-automation/)、[透明性があり](https://about.gitlab.com/ja-jp/ai-transparency-center/)、コードや知的財産を尊重するAIを望んでおり、GitLabはそうした声を真摯に受け止めています。\n\nそこでGitLabは、包括的でプライバシーを第一とし、ソフトウェア開発ライフサイクル全体をサポートする、AI搭載の機能群[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を、当社のDevSecOpsプラットフォーム向けに構築することに全力を注いでいます。\n\nこの取り組みとGitLab Duo機能に対する高い評価こそが、この度、[第1回となるGartner® Magic Quadrant™でAIコードアシスタントの分野におけるリーダーの1社に選ばれた理由](https://about.gitlab.com/ja-jp/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants/)であると、当社は考えています。\n\nこの光栄な評価を糧に、今後もお客様の声に耳を傾けて取り組んでまいります。お客様の声こそが、GitLabのビジョン、製品ロードマップ、そして最高のDevSecOpsプラットフォームを提供するための取り組みを支える原動力です。\n\n> [『2024 Gartner® Magic Quadrant™ 』のDevOpsプラットフォーム部門に関するレポート](https://about.gitlab.com/ja-jp/gartner-magic-quadrant/)をダウンロードしましょう。\n\n***出典：2024年8月、Gartner、Magic Quadrant for DevOps Platforms、Keith Mann、Thomas Murphy、Bill Holz、George Spafford***\n\n***GARTNERは、米国および国際的なGartner, Inc.および／またはその関連会社の登録商標およびサービスマークであり、MAGIC QUADRANTはGartner, Inc.および／またはその関連会社の登録商標であり、許可を得てここで使用されています。無断転載は禁止されています。***\n\n***Gartnerは、調査出版物で言及されているベンダー、製品、またはサービスを推奨するものではありません。また、最高評価またはその他の認定を受けたベンダーのみを選択するようユーザーに助言するものでもありません。Gartnerの調査出版物は、同社の研究機関の意見で構成されており、事実を表明するものとして解釈されるべきではありません。Gartnerは、本調査に関して、商品の品質・性能または特定の目的への適合性に関する保証を含め、その明示性または黙示性を問わず、いかなる保証も行いません。***\n\n***このグラフィックは、Gartner Incがより大規模なレポートの一部として発表したものであり、文書全体の文脈の中で評価される必要があります。Gartnerの文書を参照するには、同社への開示リクエストが必要になります。***",[700,1330,904,1190,702],"2024-10-24",{"slug":2906,"featured":92,"template":681},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","content:ja-jp:blog:gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","Gitlab Named A Leader In The 2024 Gartner Magic Quadrant For Devops","ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"_path":2912,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2913,"content":2919,"config":2925,"_id":2927,"_type":16,"title":2928,"_source":17,"_file":2929,"_stem":2930,"_extension":20},"/ja-jp/blog/gitlab-duo-enterprise-is-now-available",{"title":2914,"description":2915,"ogTitle":2914,"ogDescription":2915,"noIndex":6,"ogImage":2916,"ogUrl":2917,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2917,"schema":2918},"GitLab Duoエンタープライズを提供開始","AIパートナーの登場です。GitLab Duoエンタープライズが、DevSecOpsのライフサイクル全体にどのようなメリットをもたらすかご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665660/Blog/Hero%20Images/Untitled__1800_x_945_px_.png","https://about.gitlab.com/blog/gitlab-duo-enterprise-is-now-available","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duoエンタープライズを提供開始\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2024-09-03\",\n      }",{"title":2914,"description":2915,"authors":2920,"heroImage":2916,"date":2921,"body":2922,"category":787,"tags":2923,"updatedDate":2924},[1448],"2024-09-03","[GitLab Duoエンタープライズ](https://about.gitlab.com/ja-jp/gitlab-duo/)は、ソフトウェア開発ライフサイクル全体に適用できるように設計されたエンドツーエンドのAIパートナーです。この強力なAIツール群は、デベロッパーの生産性向上、セキュリティの強化、コラボレーションの効率化、そしてDevSecOpsプロセスの加速を目的として設計されました。\n\n主な機能は次のとおりです。\n- 25以上のプログラミング言語に対応したインテリジェントなコード支援\n- AIによるセキュリティ脆弱性の詳細情報と解決策の提示テスト生成と根本原因分析の自動化\n- テスト生成と根本原因分析の自動化\n- AI生成のサマリーによるチームコラボレーションの改善\n- AIインパクトダッシュボードによるROIの定量化\n\n## GitLab Duoエンタープライズを開発した理由\n\n組織は、より高品質なソフトウェアを迅速に提供し、顧客価値を高めようとする中で、その進捗を妨げる大きな課題に直面しています。[当社の調査（英語）](http://about.gitlab.com/developer-survey/2024/ai)によると、95%の企業がソフトウェア開発プロセスにおいてAIの導入を検討しているか、すでに使用しています。しかし、55%の回答者が、ソフトウェア開発にAIを使用することにはリスクが伴うと感じています。\n\n企業が直面する一般的な問題には、デベロッパーのエクスペリエンスや生産性の最適化が不十分であること、セキュリティやコンプライアンスの要求が増加していること、チーム間のコラボレーションが非効率であること、AI技術への投資に対するROIの評価が困難であることが挙げられます。GitLab Duoエンタープライズは、これらの課題に真っ向から取り組むために開発され、開発チームに対して安全で効率的かつ強力なAIパートナーを提供します。\n\n**このブログでは、GitLab Duoエンタープライズによって、企業のソフトウェア開発とデプロイにどのようなメリットがもたらされるかをご紹介します。** \n\n## インテリジェントなコード支援を活用してデベロッパーの生産性を高める\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252678?h=83f35171b6&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Code Suggestions clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nソフトウェア開発における主なハードルのひとつは、日常的なコーディング作業に時間がかかることです。しかし、次の機能を活用すれば、より重要な作業にすばやく着手できます。\n\n- __コード提案__：25以上のプログラミング言語に対応しています。このAI搭載機能を使用することで、コード作成の高速化、コード品質の向上、および定型作業にかかる時間の短縮を実現できます。\n\nしかし、新しいコードを作成することだけが目的ではありません。\n\n- __コードの説明__（GitLab Duoエンタープライズ機能）：デベロッパーが複雑なコードや不慣れなコードをすばやく理解できるよう支援します。\n\n- **コードリファクタリング**：この機能を使用することで、デベロッパーは[既存のコードの改善とモダナイゼーション（英語）](https://about.gitlab.com/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo/)を行えます。\n\n- __テスト生成__：包括的なユニットテストの作成を自動化します。これにより、デベロッパーがイノベーションを促進する価値の高いタスクに集中できるようになり、結果として開発サイクルの短縮とソフトウェアの品質向上につながります。\n\n> [欧州のテクノロジー企業であるCube社（英語）](https://about.gitlab.com/customers/cube/)が、コード提案やテスト生成、その他のGitLab Duo機能を活用して、どのようにスピードと効率を大幅に向上させているかをご確認ください。\n\n## チームのコラボレーションとコミュニケーションを強化\n\n効果的なコラボレーションは、ソフトウェア開発を成功に導くための基盤となります。しかし、長時間にわたる議論、複雑なマージリクエスト、そして時間のかかるコードレビューによって、その実現が妨げられてしまうことも多々あります。GitLab Duoエンタープライズなら、次に挙げる一連の要約（サマリー生成）機能とテンプレートツールを使用してこれらの課題に対処できます。\n\n- __ディスカッションサマリー__：イシュー内の長い議論内容を要約し、チームメンバーがすばやく理解できるよう支援します。\n- __マージリクエストサマリー__：提案された変更の概要を明確かつ簡潔に説明します。\n- __コードレビューサマリー__：レビュープロセスを効率化し、作成者とレビュアー間の引き継ぎをスムーズにします。\n\nGitLab Duoエンタープライズは、より明確なコミュニケーションと迅速な意思決定を促進し、チームがより効率的に仕事をし、より迅速に成果を上げられるよう支援します。\n\n## トラブルシューティングとデバッグを効率化\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252688?h=fc6c048bfd&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Root Cause Analysis clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n開発パイプラインが失敗した場合、プロジェクトタイムラインに大きな影響が生じる可能性があります。ここでは、GitLab Duoエンタープライズの__根本原因分析__機能が活躍します。根本原因分析は、ログを自動分析し、失敗の詳細な説明と修正手順を提示することで、トラブルシューティングにかかる時間を大幅に短縮できます。\n\nこのメリットは、単なる時間の節約にとどまりません。[CI/CDビルドの問題解決を高速化](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)することで、チームのスピード維持、ダウンタイムの削減、そして最終的には、ソフトウェアアップデートの頻度と信頼度を高めることができます。\n\n## 開発ライフサイクル全体のセキュリティを強化\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252706?h=73e568b89c&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Vulnerability Explanation and Resolution clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nサイバーセキュリティの脅威は常に存在しているため、堅牢なアプリケーションセキュリティが必要です。GitLab Duoエンタープライズは、 __脆弱性の説明機能__ と __脆弱性の修正機能__ を備えています。これらのAI搭載ツールは、[デベロッパーがセキュリティの脆弱性を完全に理解（英語）](https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities/)し、提案された修正案が反映されたマージリクエストを自動生成します。\n\n## AIの影響を定量化して戦略的意思決定を実現\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252663?h=d35106288b&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"AI Impact Dashboard clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n技術投資のROIを示すことは非常に重要です。このニーズを確実に満たすために、GitLab Duoエンタープライズには __AIのインパクトダッシュボード__ が備わっています。この分析ツールは、バリューストリーム分析とDORA4メトリクスに基づいて構築されており、サイクルタイムの改善やデプロイ頻度の向上に関連する具体的なメトリクスを提示します。これにより組織は、開発プロセスへのAI導入がもたらす明確なメリットを定量化できます。\n\n[AIインパクトダッシュボード](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)には、AIの活用が主要な生産性メトリクスとどのように関連しているかのインサイトが表示されます。これにより、経営陣はリソース配分や戦略的な技術投資に関するデータに基づいた意思決定を行えるようになります。\n\n## AIが導くDevSecOpsの新時代を迎えましょう\n\nGitLab Duoエンタープライズの発表に際し、GitLabが初の[Gartner® Magic Quadrant™のAIコードアシスタント部門](https://about.gitlab.com/ja-jp/gartner-mq-ai-code-assistants/)のリーダーの1社に選定されたことをご案内します。この評価は、真のビジネスバリューをもたらすAIソリューションを提供するGitLabの取り組みを強調するものです。\n\nソフトウェア開発の未来はすでにここにあり、それを支えているのはAIです。GitLabは、DevSecOpsのライフサイクル全体にインテリジェントで拡張性に優れたAIを組み込むサポートを提供し、組織が顧客に成果をより迅速に届けられるよう支援します。\n\n> [無料トライアルでGitLab Duoエンタープライズを今すぐ始めましょう！](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro)\n",[721,701,904,678,700],"2024-09-13",{"slug":2926,"featured":92,"template":681},"gitlab-duo-enterprise-is-now-available","content:ja-jp:blog:gitlab-duo-enterprise-is-now-available.yml","Gitlab Duo Enterprise Is Now Available","ja-jp/blog/gitlab-duo-enterprise-is-now-available.yml","ja-jp/blog/gitlab-duo-enterprise-is-now-available",{"_path":2932,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2933,"content":2939,"config":2945,"_id":2947,"_type":16,"title":2948,"_source":17,"_file":2949,"_stem":2950,"_extension":20},"/ja-jp/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"title":2934,"description":2935,"ogTitle":2934,"ogDescription":2935,"noIndex":6,"ogImage":2936,"ogUrl":2937,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2937,"schema":2938},"Google Cloud Source RepositoriesからGitLabへの移行ガイド【決定版】","Google CloudでCloud Source Repositoriesが非推奨になります。この記事では、Cloud Source RepositoriesのソースコードリポジトリをGitLabに移行する方法と、ベストプラクティスをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097739/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2813%29_1zdtbfPDHZVe6JC2AbdHmb_1750097738370.png","https://about.gitlab.com/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Google Cloud Source RepositoriesからGitLabへの移行ガイド【決定版】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Regnard Raquedan\"}],\n        \"datePublished\": \"2024-08-28\",\n      }",{"title":2934,"description":2935,"authors":2940,"heroImage":2936,"date":2941,"body":2942,"category":701,"tags":2943,"updatedDate":2944},[1385,1109],"2024-08-28","Google Cloudの[Cloud Source\nRepositories（またはCSR）が非推奨](https://cloud.google.com/source-repositories/docs/release-notes)（外部サイト）となることで、ソフトウェア開発者は自社のソースコードリポジトリ向けにフル機能を備えた代替製品を探す必要がでてきました。[Google\nCloudテクノロジーパートナー](https://cloud.google.com/find-a-partner/partner/gitlab-inc)（外部サイト）であり、包括的なDevSecOps機能を提供しているGitLabは、有力な選択肢の一つになるでしょう。\n\n\nこのガイドでは、GitLab.comを使用している方、またGoogle\nCloud上のSelf-Managedインスタンスを使用している方を対象に、CSRからGitLabにスムーズに移行するための手順をご紹介します。\n\n\n## GitLabがオススメの理由\n\nGoogle Cloud Source RepositoriesからGitLabへの移行がオススメな理由はお勧めの方法です。GitLabはGoogle\nCloudの戦略的パートナーであり、既存のインフラストラクチャと簡単かつシームレスに統合でき、次のような方法でお客様に価値をもたらします。\n\n- **DevSecOpsプラットフォームの統合**\n    - 計画からモニタリングまで、開発ライフサイクル全体を単一アプリケーションに統合します。これにより、個別ツールの乱立が解消され、劇的に生産性を向上できます。\n\n- **Google Cloudとのシームレスな統合**\n    - Google Kubernetes Engine（GKE）やCloud Build、Cloud Storageと簡単に接続できるため、Google Cloudエコシステム内でのスムーズな移行および効率的な運用が期待できます。\n\n- **高度なCI/CD機能**\n    - [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/)を活用して、セキュリティスキャンからデプロイまであらゆるプロセスを自動化し、開発サイクルを加速します。\n- **業界屈指のAIによるコーディング支援**\n    - [GitLab Duo](https://about.gitlab.com/gitlab-duo/)に組み込まれたAIアシスト開発を活用することで、安全かつ効率的なコーディング環境を促進できます。\n\n## 前提要件\n\n\n移行を開始する前に、以下の2点を必ず用意してください。\n\n- GitLabアカウント：GitLab.comまたはセルフホスト型インスタンス上でアカウントを設定します。\n\n- GitLabプロジェクト：CSRリポジトリの移行先として、GitLabで空のプロジェクトを作成します。\n\n\n## 移行手順\n\n\n1.\n空のGitLabプロジェクトを作成する：このプロジェクトをCSRリポジトリの移行先として使用します。作成したプロジェクトは今のところ、空のままにしておきます。\n\n2.\nパーソナルアクセストークン（PAT）を生成する：GitLabの設定に移動し、`read_repository`と`write_repository`スコープを有効にして[PATを生成](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)します。移行プロセス中にGitの操作を認証する際に、このトークンを使用します。\n\n3. Cloud Shellエディタでコードを編集する：CSRリポジトリで「コードを編集」ボタンをクリックして、Cloud\nShellエディタを開きます。続行するには、Cloud Shellを認証して「リポジトリを信頼する」を選択する必要があります。\n\n\n![Google Cloud\nShellエディタ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097750517.png)\n\n\n4. Gitのステータスを調べる：Cloud Shellで`git\nstatus`を実行して、現在のブランチを確認し、GitLabにプッシュする前にすべてが正常であることを確かめます。\n\n\n![Gitのステータスを調査する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097750518.png)\n\n\n5. リモートリポジトリを設定する：次のコマンドを実行して、GitLabプロジェクトをリモートリポジトリとして追加します。\n\n\n```\n\ngit remote add origin [GITLAB_PROJECT_URL]\n\n\n```\n\n\n6. `[GITLAB_PROJECT_URL]`の部分をGitLabプロジェクトの実際のURLに置き換えます。\n\nGitLabにプッシュする：最後に次のコマンドを実行して、ローカルリポジトリを[GitLabにプッシュ](https://about.gitlab.com/ja-jp/blog/mastering-the-basics-of-git-push-tag/)します。 \n\n\n```\n\ngit push -u origin [BRANCH_NAME]\n\n\n```\n\n\n7. `[BRANCH_NAME]`の部分を先程確認した現在のブランチ名に置き換えます。\n\nプロンプトが表示されたら、GitLabのユーザー名に加え、パスワードとしてPATを使用して認証を行い、プッシュを完了します。\n\n\n## ベストプラクティス\n\n\n- 開始前にバックアップする：移行プロセスをはじめる前に、必ずCSRリポジトリをバックアップしてください。\n\n- 移行後にテストする：ブランチやCI/CDパイプラインなど、リポジトリのすべての要素が想定どおりに、GitLabで動作することを確認しましょう。\n\n-\nGitLabの機能を活用する：[AI](https://about.gitlab.com/gitlab-duo/)や[CI/CD](https://docs.gitlab.com/ee/ci/)、[GitLab\nEnterprise Agile\nPlanning](https://about.gitlab.com/solutions/agile-delivery/)など、GitLabで提供される高度なDevSecOps機能を活用して、開発ワークフローを強化しましょう。\n\n\nGoogle Cloud Source\nRepositoriesからGitLabへの移行は容易に実施でき、単なるソースコードの管理以上に多くのメリットがあります。移行後にワークフローを強化したいと考えているデベロッパーにとって、GitLabをGoogle\nCloudと統合させることは非常に効果的な選択肢になると言えるでしょう。\n\n\n> [GitLabのGoogle\nCloudとの統合について詳しくは、こちら](https://about.gitlab.com/blog/gitlab-google-cloud-integrations-now-in-public-beta/)をお読みください。\n\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[676,1114,904],"2024-09-12",{"slug":2946,"featured":6,"template":681},"tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","content:ja-jp:blog:tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","Tutorial Migrate From Google Cloud Source Repositories To Gitlab","ja-jp/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","ja-jp/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"_path":2952,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2953,"content":2959,"config":2965,"_id":2967,"_type":16,"title":2968,"_source":17,"_file":2969,"_stem":2970,"_extension":20},"/ja-jp/blog/how-indeed-transformed-its-ci-platform-with-gitlab",{"title":2954,"description":2955,"ogTitle":2954,"ogDescription":2955,"noIndex":6,"ogImage":2956,"ogUrl":2957,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2957,"schema":2958},"GitLabでCIプラットフォームを変革したIndeed社の戦略","世界最大の求人サイトであるIndeed社は、数千のプロジェクトをGitLab CIに移行することで、生産性向上とコスト削減を実現しました。1日あたりのパイプライン実行数が79%増加するなど、得られた主なメリットをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","https://about.gitlab.com/blog/how-indeed-transformed-its-ci-platform-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabでCIプラットフォームを変革したIndeed社の戦略\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Carl Myers\"}],\n        \"datePublished\": \"2024-08-27\",\n      }",{"title":2954,"description":2955,"authors":2960,"heroImage":2956,"date":2962,"body":2963,"category":2156,"tags":2964,"updatedDate":2297},[2961],"Carl Myers","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/)の編集版です。**",[762,110,764,904],{"slug":2966,"featured":92,"template":681},"how-indeed-transformed-its-ci-platform-with-gitlab","content:ja-jp:blog:how-indeed-transformed-its-ci-platform-with-gitlab.yml","How Indeed Transformed Its Ci Platform With Gitlab","ja-jp/blog/how-indeed-transformed-its-ci-platform-with-gitlab.yml","ja-jp/blog/how-indeed-transformed-its-ci-platform-with-gitlab",{"_path":2972,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2973,"content":2978,"config":2985,"_id":2987,"_type":16,"title":2988,"_source":17,"_file":2989,"_stem":2990,"_extension":20},"/ja-jp/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo",{"title":2974,"description":2975,"ogTitle":2974,"ogDescription":2975,"noIndex":6,"ogImage":780,"ogUrl":2976,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2976,"schema":2977},"AI搭載のGitLab Duoでコードをモダンな言語にリファクタリング","この詳細なチュートリアルでは、デベロッパーがAIを活用し、コードを新しいプログラミング言語に移行してモダナイゼーションを進めるプロセスや、同じ言語における新機能についても学べる内容を紹介しています。","https://about.gitlab.com/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI搭載のGitLab Duoでコードをモダンな言語にリファクタリング\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-08-26\",\n      }",{"title":2974,"description":2975,"authors":2979,"heroImage":780,"date":2981,"body":2982,"category":787,"tags":2983,"updatedDate":2984},[2980],"Michael Friedrich","2024-08-26","コードベースやフレームワークのモダナイゼーションを行うために新しいプログラミング言語へ移行する必要があったり、同じ言語内の新しい機能の知識を深めたい場合は、AI搭載の[GitLab Duo](https://about.gitlab.com/gitlab-duo/)が有効です。ここでは、筆者が過去20年にわたるコーディングキャリアで培ったベストプラクティスをもとに、コードリファクタリングの際に直面する課題への効果的なアプローチ方法をご紹介します。\n\nこの記事では、VS CodeとJetBrains IDE（IntelliJ IDEA、PyCharm、CLion）を使用したプロンプトと例を紹介します。いずれのIDEにも[GitLab Duo拡張機能やプラグイン](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html)がインストールされています。開発環境としてはGitLab.comが使用されています。ここでは大規模言語モデル（LLM）がAnthropic Claude 3.5にアップデートされており、GitLab Duoの[コード提案](https://docs.gitlab.com/ee/user/gitlab_duo/#code-suggestions)と[Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo/#gitlab-duo-chat)に適用されています。これらの機能は卓越したパフォーマンスと効率性を発揮します。\n\nこの記事では必要なセクションだけを確認しても良いですし、上から順を追って読んでも構いません。また、自己学習に役立つソースコードや演習問題も用意しています。\n\n- モダンなプログラミング言語標準に合わせたコードのリファクタリング\n    - Java 7のコードを生成し、Java 8にリファクタリング\n    - C++標準に基づいたリファクタリング\n        - 移行：C++03をC++14にリファクタリング\n        - ダウングレード：C++23をC++11にリファクタリング\n    - COBOLの説明とリファクタリング\n- 異なる言語間でのリファクタリング\n    - CをRustにリファクタリング\n    - PerlをPythonにリファクタリング\n- その他のリファクタリング実践例\n    - JavaScriptのリファクタリング\n    - BashをZSHやSHにリファクタリング\n    - その他のユースケースやチュートリアル\n- 重要なポイント\n\n## モダンなプログラミング言語標準に合わせたコードのリファクタリング\n\n次のセクションでは、特定のプログラミング言語におけるリファクタリングの方法、言語固有の違いの説明、および理解の仕方について解説します。\n\n### Java 7のコードを生成し、Java 8にリファクタリング\n\nあるお客様から、GitLab DuoがJava 7をサポートしているかどうかのご質問が寄せられました。Java 7固有のコードを生成するためのコード提案とGitLab Chatのプロンプトをテストしている際、移行支援についても考えました。Anthropic Claude 3.5と同様に、GitLab Duoも言語固有の違いを理解できます。\n\n次の例では、コード提案を使用してJava 7のコードを生成するプロンプトを示しています。\n\n```java\n// Generate a new class for a File Manager. Use Java 7 features only.\nimport java.io.*;\nimport java.nio.file.*;\nimport java.util.*;\n\npublic class FileManager {\n    private Path rootDirectory;\n\n    public FileManager(String rootPath) throws IOException {\n        this.rootDirectory = Paths.get(rootPath);\n        if (!Files.exists(rootDirectory)) {\n            Files.createDirectories(rootDirectory);\n        }\n    }\n\n    public void createFile(String fileName, String content) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        Files.write(filePath, content.getBytes(), StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING);\n    }\n\n    public String readFile(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        return new String(Files.readAllBytes(filePath));\n    }\n\n    public void deleteFile(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        Files.delete(filePath);\n    }\n\n    public List\u003CString> listFiles() throws IOException {\n        List\u003CString> fileList = new ArrayList\u003C>();\n        try (DirectoryStream\u003CPath> stream = Files.newDirectoryStream(rootDirectory)) {\n            for (Path file : stream) {\n                fileList.add(file.getFileName().toString());\n            }\n        }\n        return fileList;\n    }\n\n    public void copyFile(String sourceFileName, String destinationFileName) throws IOException {\n        Path sourcePath = rootDirectory.resolve(sourceFileName);\n        Path destinationPath = rootDirectory.resolve(destinationFileName);\n        Files.copy(sourcePath, destinationPath, StandardCopyOption.REPLACE_EXISTING);\n    }\n\n    public void moveFile(String sourceFileName, String destinationFileName) throws IOException {\n        Path sourcePath = rootDirectory.resolve(sourceFileName);\n        Path destinationPath = rootDirectory.resolve(destinationFileName);\n        Files.move(sourcePath, destinationPath, StandardCopyOption.REPLACE_EXISTING);\n    }\n\n    public long getFileSize(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        return Files.size(filePath);\n    }\n\n    public boolean fileExists(String fileName) {\n        Path filePath = rootDirectory.resolve(fileName);\n        return Files.exists(filePath);\n    }\n}\n```\n\nご自身のIDEで次の手順を進めてください。\n\n1. 生成されたコードを理解する：エディタでコード部分を選択（スクリーンショットの青色部分）し、GitLab Duo Chatに切り替えて、`/explain` スラッシュ(/) コマンドをプロンプトとして送信します。\n\n![GitLab Duo Chatで `/explain` スラッシュ(/) コマンドを使用して生成したコードを検証する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/intellij_java7_generate_refactor.png)\n\n2. Java 7のコードをJava 8にリファクタリングする：エディタでコードを選択し、Chatに切り替えて、プロンプトを `/refactor using Java 8 features` に変更して送信します。\n3. リファクタリングの代替方法を練習する：新しいファイル `java8.java` を作成し、コード提案を使って `// Generate a new class for a File Manager. Use Java 8 features only.` というプロンプトでJava 8固有のコードを生成します。\n4. AI搭載のコード補完機能を使って、同じコンテキストでJava 8のコードの続きを記述します。\n\n次の録画ですべての手順をご覧になれます。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/XKRv6uBkD2I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\nソースコードは[GitLab Duo Challenge - Generate and refactor Java 7 to 8 project ]( https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-generate-refactor-java-7-to-8)で取得できます。\n\n### C++標準に基づいたリファクタリング\n\nC++の標準には長い歴史があり、安定性と成熟度には信頼があります。ターゲットとなるアーキテクチャやプラットフォームに応じて、サポートされる標準はホストのオペレーティングシステム上のコンパイラに依存します。\n\n筆者は自身のキャリアを通して、25種類の異なるLinuxおよびWindowsディストリビューションをサポートするオープンソースプロジェクトに関わり、新しい言語機能やC++標準に対するコンパイラのサポートが多様であることを実感してきました。2015年にはC++11の機能を採用し、それ以降C++14やC++17に触れることはありませんでした。\n\n関数やアルゴリズムを新しいC++標準にリファクタリングするのには多大な労力がかかり、その違いを説明する支援が必要でした。当時は、リファクタリングの調べものを、書籍やオンライン検索、Stack Overflow、そして時にはツールの助けを借りて行っていました。\n\nしかし、AI搭載のアシストやGitLab Duoの登場で状況は変わりました。コード提案やDuo Chatに、特定のC++標準に準拠したソースコードを提示するよう指示したり、異なる出力を比較したりできるようになったのです。\nしかし、AI搭載のアシストやGitLab Duoの登場で状況は変わりました。コード提案やDuo Chatに、特定のC++標準に準拠したソースコードを提示するよう指示したり、異なる出力を比較したりできるようになったのです。\n\n次の例では、C++03標準に特化したプロンプトを使用してソースコードを生成しています。これは、`.ini` 構成フォーマット用のシンプルなコンフィグパーサー（configparser）を実装しています。\n\n```c++\n/* iniフォーマットを解析できるconfigparserを作成\nC++03標準のみを使用\n */\n\n#include \u003Ciostream>\n#include \u003Cfstream>\n#include \u003Cstring>\n#include \u003Cmap>\n#include \u003Csstream>\n\nclass ConfigParser {\nprivate:\n    std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> > config;\n\npublic:\n    ConfigParser() {}\n\n    bool parse(const std::string& filename) {\n        std::ifstream file(filename.c_str());\n        if (!file.is_open()) {\n            return false;\n        }\n\n        std::string line;\n        std::string currentSection;\n\n        while (std::getline(file, line)) {\n            // Trim whitespace\n            size_t first = line.find_first_not_of(\" \\t\");\n            size_t last = line.find_last_not_of(\" \\t\");\n            if (first == std::string::npos) continue; // Skip empty lines\n            line = line.substr(first, (last - first + 1));\n\n            if (line[0] == '[' && line[line.length() - 1] == ']') {\n                // This is a section\n                currentSection = line.substr(1, line.length() - 2);\n            } else {\n                // This is a key-value pair\n                size_t delimiterPos = line.find('=');\n                if (delimiterPos != std::string::npos) {\n                    std::string key = line.substr(0, delimiterPos);\n                    std::string value = line.substr(delimiterPos + 1);\n                    config[currentSection][key] = value;\n                }\n            }\n        }\n\n        file.close();\n        return true;\n    }\n\n    std::string getValue(const std::string& section, const std::string& key) const {\n        std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> >::const_iterator sectionIt = config.find(section);\n        if (sectionIt != config.end()) {\n            std::map\u003Cstd::string, std::string>::const_iterator keyIt = sectionIt->second.find(key);\n            if (keyIt != sectionIt->second.end()) {\n                return keyIt->second;\n            }\n        }\n        return \"\";\n    }\n\n    void printConfig() const {\n        std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> >::const_iterator sectionIt;\n        for (sectionIt = config.begin(); sectionIt != config.end(); ++sectionIt) {\n            std::cout \u003C\u003C \"[\" \u003C\u003C sectionIt->first \u003C\u003C \"]\" \u003C\u003C std::endl;\n            std::map\u003Cstd::string, std::string>::const_iterator keyIt;\n            for (keyIt = sectionIt->second.begin(); keyIt != sectionIt->second.end(); ++keyIt) {\n                std::cout \u003C\u003C keyIt->first \u003C\u003C \" = \" \u003C\u003C keyIt->second \u003C\u003C std::endl;\n            }\n            std::cout \u003C\u003C std::endl;\n        }\n    }\n};\n\nint main() {\n    ConfigParser parser;\n    if (parser.parse(\"config.ini\")) {\n        std::cout \u003C\u003C \"Config file parsed successfully.\" \u003C\u003C std::endl;\n        parser.printConfig();\n\n        std::cout \u003C\u003C \"Value of 'key1' in 'section1': \" \u003C\u003C parser.getValue(\"section1\", \"key1\") \u003C\u003C std::endl;\n    } else {\n        std::cout \u003C\u003C \"Failed to parse config file.\" \u003C\u003C std::endl;\n    }\n    return 0;\n}\n```\n\n同じプロンプトを、[コードの説明](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide)、[テスト生成](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#write-tests-in-the-ide)、さらには[コードのリファクタリング](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide)にも適用できます。たとえば、`/explain focus on C++03 features`、`/tests for C++03 features`、`/refactor into C++03` などです。 \n\n次のC++標準は、GitLab Duoのコード提案を使用して動作を確認済みです。\n\n- C++03\n- C++11\n- C++14\n- C++17\n- C++20\n- C++23\n\nソースコードは、[Challenge - Refactor Cpp Standards Config Parser project](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser)で取得できます。\n\nC++標準間でソースコードをリファクタリングする組み合わせは数多く存在します。次の例では、C++コードを最新バージョンにアップグレードするケースに焦点を当てています。一方、熱心なデベロッパーがC++20を使用したいものの、エンタープライズな顧客環境をサポートするためにC++11にダウングレードしなければならなかったというシナリオもテストしています。\n\n#### 移行：C++03をC++14にリファクタリング\n\nここでは、コードのモダナイゼーションを行い、C++03からC++14への変更点を理解することを目標とします。IDEで[03.cpp](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser/-/blob/main/03.cpp?ref_type=heads)のソースコードを開き、選択した後、次のChatプロンプトを使用します。\n\n```markdown\n/refactor into C++14 and explain the changes\n（日本語訳：/C++14にリファクタリングし、変更を説明してください）\n```\n\nChatの回答例：\n\n```markdown\n…\n\n変更点の説明：\n\n1. デフォルトコンストラクタ: `ConfigParser() {}` を `ConfigParser() = default;` に変更し、デフォルトコンストラクタを使用しました。\n2. ファイルオープン: ファイルを開く際、`.c_str()` を削除しました。C++11以降では、`std::string` が直接サポートされています。\n3. ラムダ関数: 文字列のトリミング処理を行うラムダ関数trimを導入し、コードの可読性と再利用性を向上させました。\n4. 自動キーワード: 型推論のために様々な箇所で `auto` を使用し、コードの可読性を改善しました。\n5. 範囲ベースのforループ:  `printConfig` メソッド内で従来のforループを範囲ベースのforループに置き換え、より簡潔でエラーが少ない構造にしました。\n6. 構造化束縛: 範囲ベースのforループで構造化束縛を使用し、キーと値のペアに直接アクセスできるようにしました。\n7. 初期化付きif文: `getValue` メソッド内で、検索操作と条件チェックを1行で行える初期化付きif文を使用しました。\n8. 文字列メンバー関数: 文字列の最初と最後の文字を取得する際に、配列風のアクセスではなく `front()` と `back()` を使用しました。\n9. 初期化の統一: オブジェクトの生成時に `()` ではなく `{}` を使用する統一された初期化を採用しました。\n10. `std::endl` の削除： `std::endl` を `'\\n'` に置き換え、パフォーマンスを向上させました。`std::endl` は出力バッファーを強制的にフラッシュするためです。\n\nこれらの変更により、コードはよりモダンで簡潔になり、同じ機能を維持しつつ効率性が向上しています。\n\n```\n\n![コードに反映された変更](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp03_to_14_01.png)\n\n![コードに反映された変更2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675060/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp03_to_14_02.png)\n\n#### ダウングレード：C++23をC++11にリファクタリング\n\n時に、デベロッパーはC++20のようなモダンなC++標準で新しい機能の概念実証を開始しますが、エンタープライズな顧客環境で実際にサポートされているバージョンでは、C++11をサポートする古いコンパイラが必要になる場合があります。バージョンをダウングレードするにはコストがかかるほか、どの言語機能がまだサポートされているかを確認し、潜在的なデメリットを検討する必要があります。\n\nIDEで[23.cpp](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser/-/blob/main/23.cpp?ref_type=heads)のソースコードを開き、選択した後、次のChatプロンプトを使用します。\n\n```markdown\n/refactor into C++11, explain the necessary changes and potential problems\n（日本語訳：/C++14にリファクタリングし、必要な変更点と潜在的な問題点を説明してください）\n```\n\nDuo Chatの回答例：\n\n```markdown\nこのコードをC++11に対応させるために必要な主な変更点は次の通りです：\n\n1. C++23標準のコメントを削除しました。これはもう適用されないためです。\n2. trim関数内で `std::string::find_first_not_of` と  `std::string::find_last_not_of` をC++11対応の代替方法に置き換えました。\n3. ループ変数には `auto` の代わりに `const auto&` を使用し、不要なコピーを避けました。\n\nオリジナルのコードにおける潜在的な問題点は次の通りです：\n\n1. オリジナルのコードはC++23の機能を使用しており、まだ広くサポートされていない可能性があります。\n2. `trim` 関数では `std::string::find_first_not_of` と `std::string::find_last_not_of` を使用しており、これらはC++11には存在しません。\n3. 一部のループで `const auto&` の代わりに `auto` を使用していないと、複雑なオブジェクトが不必要にコピーされる可能性があります。\n\nこれらの問題はリファクタリング版で解決されています。`trim` 関数は、C++11対応の場合と同じ結果を得るために、ラムダ関数を使った `std::find_if_not` を利用するように変更されました。また、 `const auto&` を使用することで、設定マップを反復処理する際に不要なコピーが行われないようにしました。\n```\n\n![`trim` 関数は、C++11に対応する形で、ラムダ関数を使った `std::find_if_not` を使用して同じ結果をもたらすようになりました](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp23_to_11_01.png)\n\n![`const auto&` を使用することで、configマップを反復処理する際の不要なコピーの生成を防ぎ、パフォーマンスを最適化できます](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp23_to_11_02.png)\n\n**非同期練習**：他のバージョンのリファクタリングシナリオをテストしてみましょう。\n\n### COBOLの説明とリファクタリング\n\nGitLab Duoを使用して、COBOLプログラムのソースコードを説明させたり、解析、修正、リファクタリングを実行してもらえます。筆者はCOBOLを書いたことも学んだこともありませんでしたが、この[COBOL Programming Course](https://github.com/openmainframeproject/cobol-programming-course)では豊富な例が紹介されていて有用だと感じました。\n\nその後、次のように、Chatに「COBOLの始め方」「COBOLプログラムの作成方法」「macOSでのCOBOLプログラムのコンパイル方法」について質問しました。\n\n```markdown\nPlease explain what COBOL is and its syntax\n（日本語訳：COBOLとは何か、その構文について説明してください。）\n\nPlease create a COBOL program that shows the first steps\n（日本語訳：COBOLプログラムを作成し、最初のステップを示してください。）\n\nTell me more about the COBOL compiler. Which system do I need? Can I do it on my macOS?\n（日本語訳：COBOLコンパイラについて教えてください。どのようなシステムが必要ですか？ macOSで実行できますか？）\n```\t\n\n![GitLab Duo Chatに説明とその構文を求める](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/vscode_chat_cobol_generate_example.png)\n\nCOBOLプログラムを開き、ソースコードを選択したら、Duo Chatに切り替えて、`/explain` プロンプトを送信し、目的や機能を説明してもらいましょう。\n\nまた、プロンプトをさらに洗練して、全体像をより反映したサマリーを取得することもできます。\n\n```markdown \n/explain like I am five\n（日本語訳：/explain ５歳児にもわかるように説明してください。）\n```\n\n> ヒント：プログラミング言語は、類似したアルゴリズムや機能を共有しています。COBOLについては、ChatによるPythonを介した説明が提供されたため、以降のプロンプトではPythonでの説明を求めるように調整しました。\n\n```markdown\n/explain in a different programming language\n（日本語訳：/explain 異なるプログラミング言語で説明してください。）\n```\n\nChatでは、`/refactor` スラッシュ（/）コマンドを使用して、コード品質の改善、潜在的な問題の修正、およびCOBOLのPythonへのリファクタリングを実行できます。\n\n```markdown\n/refactor fix the environment error\n（日本語訳：/refactor 環境上のエラーを修正してください。）\n\n/refactor fix potential problems\n（日本語訳：/refactor 潜在的な問題を修正してください。）\n\n/refactor into Python\n（日本語訳：/refactor Pythonにリファクタリングしてください。）\n```\n\n次の[GitLab Duo Coffee Chat - Challenge: Explain and Refactor COBOL programs](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-explain-refactor-cobol-program)の録画では、欠落しているピリオドの見つけ方など、すべての手順が実際のユースケースをもとに説明されています。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/pwlDmLQMMPo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n## 異なる言語間でのリファクタリング\n\nモダナイゼーションとコード品質の改善には、プログラミング言語の変更が必要になる場合があります。GitLab Duoのリファクタリングプロンプトを使用して、移行プロセスを迅速に進められますCOBOLとPythonの例は、エンタープライズ環境において一般的な要件のひとつに過ぎません。その他のユースケースを詳しく見ていきましょう。\n\n### CをRustにリファクタリング\n\n2024年初頭に、Cを始めとするいくつかのプログラミング言語は、メモリの安全性に問題があると指摘されました。今後のプロジェクトでは、Rustのような[メモリ安全な言語](https://about.gitlab.com/blog/memory-safe-vs-unsafe/)（英語）が推奨されています。ここでは、移行へのアプローチや、想定すべき課題について理解しましょう。\n\n簡単なCの例で試してみましょう。このコードはコード提案を使用して生成されており、オペレーティングシステムの基本情報（名前、バージョン、プラットフォームなど）を表示します。このCコードは、Windows、Linux、macOSでクロスプラットフォームにコンパイルできます。\n\n```c\n// OSファイルを読み込み、プラットフォーム、名前、バージョンを特定する\n// ターミナルに出力する\n#include \u003Cstdio.h>\n#include \u003Cstdlib.h>\n#include \u003Cstring.h>\n\n#ifdef _WIN32\n    #include \u003Cwindows.h>\n#elif __APPLE__\n    #include \u003Csys/utsname.h>\n#else\n    #include \u003Csys/utsname.h>\n#endif\n\nvoid get_os_info() {\n    #ifdef _WIN32\n        OSVERSIONINFOEX info;\n        ZeroMemory(&info, sizeof(OSVERSIONINFOEX));\n        info.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);\n        GetVersionEx((OSVERSIONINFO*)&info);\n\n        printf(\"Platform: Windows\\n\");\n        printf(\"Version: %d.%d\\n\", info.dwMajorVersion, info.dwMinorVersion);\n        printf(\"Build: %d\\n\", info.dwBuildNumber);\n    #elif __APPLE__\n        struct utsname sys_info;\n        uname(&sys_info);\n\n        printf(\"Platform: macOS\\n\");\n        printf(\"Name: %s\\n\", sys_info.sysname);\n        printf(\"Version: %s\\n\", sys_info.release);\n    #else\n        struct utsname sys_info;\n        uname(&sys_info);\n\n        printf(\"Platform: %s\\n\", sys_info.sysname);\n        printf(\"Name: %s\\n\", sys_info.nodename);\n        printf(\"Version: %s\\n\", sys_info.release);\n    #endif\n}\n\nint main() {\n    get_os_info();\n    return 0;\n}\n```\n\nここでは、JetBrains CLionなどを使用して [`os.c`](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-c-to-rust/-/blob/897bf57a14bb7be07d842e7f044f93a61456d611/c/os.c) のソースコードを開きます。 ソースコードを選択し、Chatプロンプトで `/explain` を使用して目的や機能を説明します。次に、Chatプロンプトで `/refactor` を使用してCコードをリファクタリングし、さらに `/refactor into Rust` を使用してRustにリファクタリングします。\n\n新しいRustプロジェクトを初期化（ヒント：Duo Chatに質問してみましょう）し、生成されたソースコードを `src/main.rs` ファイルにコピーします。`cargo build` を実行してコードをコンパイルします。\n\n![新しいRustプロジェクトを初期化し、生成されたソースコードを `src/main.rs` ファイルにコピーします。`cargo build` を実行してコードをコンパイルします。](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/jetbrains_clion_c_rust.png)\n\n[GitLab Duo Coffee Chat: Challenge - Refactor C into Rust ]( https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-c-to-rust)の録画では、の録画では、すべての手順を確認できるほか、コンパイルエラーが発生し、それがChatと `/refactor` スラッシュ(/) コマンドによって修正される様子もご覧になれます。また、このセッションでは、新しいRustコードのメンテナンス性を向上させるために、エラーハンドリングを追加する方法も紹介されています。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/nf8g2ucqvkI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n### PerlをPythonにリファクタリング\n\n本番環境サーバーでジョブを実行するスクリプトがありますが、作成者は10年前に退社しており、誰もそのスクリプトに手を付けたがりません。この問題は、複数のスクリプトや、さらにはアプリケーション全体にも影響している可能性があります。そこで、すべてをモダンなPython 3に移行する決定が下されました。ここでは、コードのモダナイゼーションを行い、PerlからPythonへの変更点を理解することを目標とします。\n\n最近、GitLab Duoのワークショップに参加したお客様から、GitLab Duoを使って直接移行が可能かどうかという質問がありました。一言でお答えすれば、「可能」です。これを詳しく説明するならば、この記事にある他の例と同様に、洗練されたChatプロンプトを使用することで、PerlコードをPythonにリファクタリングすることができます。\n\n`script.pl` ソースコードをIDEで開き、選択して、Chatを開きます。\n\n```perl\n#!/usr/bin/perl\nuse strict;\nuse warnings;\n\nopen my $md_fh, '\u003C', 'file.md' or die \"Could not open file.md: $!\";\n\nmy $l = 0;\nmy $e = 0;\nmy $h = 0;\n\nwhile (my $line = \u003C$md_fh>) {\n  $l++;\n  if ($line =~ /^\\s*$/) {\n    $e++;\n    next;\n  }\n  if ($line =~ /^#+\\s*(.+)/) {\n    print \"$1\\n\";\n    $h++; \n  }\n}\n\nprint \"\\nS:\\n\"; \nprint \"L: $l\\n\";\nprint \"E: $e\\n\"; \nprint \"H: $h\\n\";\n```\n\n次のプロンプトを使用できます：\n\n1. `/explain` でその目的を説明させ、 `/refactor` でコードを改善させます。\n2. `/refactor into Python`：実行可能なPythonスクリプトを取得します。\n\n![Pythonへのリファクタリング](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/pycharm_duo_refactor_perl_python.png)\n\n> ヒント：Perlコードは、より多くのターゲット言語にリファクタリングできます。[GitLab Duo Coffee Chat：チャレンジ - PerlからPythonへのリファクタリング](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-perl-python)の録画では、PHP、Ruby、Rust、Go、Java、VB.NET、C#などの言語も取り上げています。\n>\n> Perlスクリプトの使用を継続するには、Duoのコード提案で[Perlを追加言語として](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html#add-support-for-more-languages)設定できます。ChatはすでにPerlを理解しており、質問やスラッシュ（/） コマンドのプロンプトにも対応できます。次の録画でこれについて確認できます。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/03HGhxXg9lw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n## その他のリファクタリング実践例\n\n### JavaScriptのリファクタリング\n\nJavaScriptをリファクタリングしてコード品質を向上させたり、機能を追加したりする方法について、Eddie Jaoudeが実用的な例を交えて紹介しています。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mHn8KOzpPNY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n### BashをZSHやSHにリファクタリング\n\n筆者はBashをShellとして20年間使用していましたが、最近になってmacOSのZSHに移行しました。この移行に伴い、スクリプトが機能しなくなったり、端末に不明なエラーが発生したりしました。リファクタリングの別のユースケースとして、Shellの制約があります。たとえば、一部のオペレーティングシステムやLinux/Unixディストリビューション（Alpineなど）では、Bashが提供されておらず、SHしか使用できません。\n\n![シェルスクリプトのリファクタリング](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/intellj_refactor_shell_scripts.png)\n\n[GitLab Duo Coffee Chat: Challenge - Refactor Shell Scripts ]( https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-shell-scripts)では、syslogファイルを追跡するCプログラムと、Bashで記述されたビルドスクリプトの例が紹介されています。このチャレンジの中では、コードの改善を目的として、Chatに対して `/explain` や `/refactor` のプロンプトが使用されます。また、BashをPOSIX準拠のSHやZSHにリファクタリングすることもできます。セッションの最後では、Chatに5つの異なるShellスクリプトの実装を提供させ、そのサマリーについて説明するようリクエストしています。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mssqYjlKGzU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n### その他のユースケースとチュートリアル\n\n- [ドキュメント：GitLab Duoのユースケース](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html)\n- [チュートリアル：AI搭載のGitLab Duoチャットを使用するためのベストプラクティス【10選】](https://about.gitlab.com/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo/)\n- [チュートリアル：AI搭載のGitLab Duoチャットを使用するためのベストプラクティス【10選】](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/)\n\n## 重要なポイント\n\n1. GitLab Duoは、コードの説明やリファクタリングにおいて効率的なサポートを提供します。\n1. 言語標準間でコードをリファクタリングしたり、Chatで追加の質問をしたりできます。\n1. コード提案のプロンプトは、特定の言語標準に基づいたコードを生成できます。また、コード補完は現行のコードのコンテキストを尊重します。\n1. 新しいプログラミング言語へのリファクタリングは、長期的な移行プロセスやモダナイゼーションの計画に有効です。\n1. コードは、古いシステムがサポートする言語標準に「ダウングレード」することもできます。\n1. GitLab Duoは、複雑なコードやプログラミング言語について、異なるプログラミング言語の例を用いて説明できます。\n1. GitLab.comにおけるAnthropic Claude 3.5へのアップデートにより、コード提案およびChatの質と速度がさらに向上しました（Self-Managed版では17.3へのアップグレードを推奨しています）。\n1. 本番環境における問題がある場合を除き、ユースケースはアイデア次第で無限に広がります。\n\nコード提案とChatを活用した効率的なワークフローについて理解を深めましょう。GitLab DuoのAI搭載コードリファクタリングを、今すぐお試しいただけます。\n\n> [GitLab Duoのの無料トライアルを開始しましょう！](https://about.gitlab.com/ja-jp/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro_)\n\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)* \u003Cbr>\n*（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n",[721,676,702],"2025-02-10",{"slug":2986,"featured":6,"template":681},"refactor-code-into-modern-languages-with-ai-powered-gitlab-duo","content:ja-jp:blog:refactor-code-into-modern-languages-with-ai-powered-gitlab-duo.yml","Refactor Code Into Modern Languages With Ai Powered Gitlab Duo","ja-jp/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo.yml","ja-jp/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo",{"_path":2992,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2993,"content":2999,"config":3006,"_id":3008,"_type":16,"title":3009,"_source":17,"_file":3010,"_stem":3011,"_extension":20},"/ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"title":2994,"description":2995,"ogTitle":2994,"ogDescription":2995,"noIndex":6,"ogImage":2996,"ogUrl":2997,"ogSiteName":1223,"ogType":1244,"canonicalUrls":2997,"schema":2998},"【徹底解説！】AWS CodeCommitからGitLabへの移行ガイド","この記事では、AWSサービスからGitLabに移行し、DevSecOpsプラットフォームとシームレスに統合する方法をわかりやすく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097810/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2828%29_4mi0l4wzUa5VI4wtf8gInx_1750097810027.png","https://about.gitlab.com/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"【徹底解説！】AWS CodeCommitからGitLabへの移行ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"},{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"},{\"@type\":\"Person\",\"name\":\"Bart Zhang\"}],\n        \"datePublished\": \"2024-08-26\",\n      }",{"title":2994,"description":2995,"authors":3000,"heroImage":2996,"date":2981,"body":3004,"category":701,"tags":3005,"updatedDate":2901},[1385,3001,3002,3003],"Darwin Sanoy","Samer Akkoub","Bart Zhang","2024年7月25日に、AWSが自社のCodeCommitサービスについて重要な発表を行いました。詳細はAWSの[公式ブログ記事（外部サイト）](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)に記載されていますが、CodeCommitでの新規顧客の利用受付が終了することになりました。既存のお客様は引き続きサービスを利用できるものの、今後AWSが新機能を実装することはなく、セキュリティ、可用性、パフォーマンスの改善のみに注力するとのことです。\n\n今回の発表は、開発チームがリポジトリを別のGitプロバイダーに移行することを検討するきっかけとなっています。これらの変更をふまえ、お客様がGitLabに移行して他のAWSサービスと統合できるように、抱括的なガイドをご用意しました。\n\n__注：__ 移行に関するAWSの公式推奨事項の詳細については、[AWSのブログ記事（外部サイト）](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)をご覧ください。\n\n## このガイドについて\n\nこのガイドでは、GitLabを使用していてAWSサービスとの統合を検討している開発チームや、AWSにホストされているGitリポジトリからGitLab.comに移行予定の開発チーム向けに包括的な情報を提供します。このガイドは次の3つの主要セクションで構成されています。\n\n* [GitLabへの並行移行](https://app.contentful.com/spaces/r9o86ar0p03f/entries/2tGP1LjJy6E5hzf9B24KIl?focusedField=body\\&focusedLocale=en-US\\#section-1-parallel-migration-to-gitlab)：リスクを最小限に抑えつつ、AWSにホストされている既存リポジトリからGitLab.comへ徐々に移行する方法について説明します。  \n* [AWS CodeBuildとの統合](https://app.contentful.com/spaces/r9o86ar0p03f/entries/2tGP1LjJy6E5hzf9B24KIl?focusedField=body\\&focusedLocale=en-US\\#section-2-integrating-gitlab-with-aws-codebuild)：GitLabリポジトリをAWS CodeBuildと統合し、強力な継続的インテグレーション（CI）環境を設定する手順を紹介します。  \n* [AWS CodePipelineとの統合](https://app.contentful.com/spaces/r9o86ar0p03f/entries/2tGP1LjJy6E5hzf9B24KIl?focusedField=body\\&focusedLocale=en-US\\#section-3-integrating-gitlab-with-aws-codepipeline)：効率的な継続的デリバリーパイプラインを構築するために、GitLabリポジトリをAWS CodePipelineと接続する方法について詳しく説明します。  \n* [CodePipelineとCodeStar Connectionsのダウンストリーム統合](https://app.contentful.com/spaces/r9o86ar0p03f/entries/2tGP1LjJy6E5hzf9B24KIl?focusedField=body\\&focusedLocale=en-US\\#section-4-migrating-to-gitlab)：GitLabとAWS間の接続を活用して広範なサービスの利用を実現する方法について説明します。この方法を用いると、AWSエコシステム全体での統合の可能性が連鎖的に広がります。\n\nこのガイドを通して、GitLabとAWSの強力な機能を組み合わせ、効率的で柔軟な開発ワークフローを作成する方法を学びましょう！\n\n## **第1セクション：GitLabへの並行移行**\n\nAWSにホストされているGitリポジトリをGitLab.comに移行することを検討中の方向けに、段階的なアプローチについて取り上げる本セクションでは、リスクを最小限に抑えながら移行を達成する方法をご紹介します。GitLabのミラーリング機能を活用すれば、既存の開発フローを維持しながら、新しい環境をテストできます。\n\n### **並行移行が重要な理由**\n\n大規模なシステムの移行には常にリスクが伴います。特に、実施中の開発作業や既存のインテグレーション、自動化されたプロセスに影響が生じる可能性があります。並行移行アプローチを採用すると、次のようなメリットがあります。\n\n1\\. リスクの最小化：既存のシステムを稼働させた状態で新しい環境をテストできます。  \n2\\. シームレスな移行：開発チームが新しいシステムに少しずつ慣れることができます。   \n3\\. インテグレーションテスト：すべてのインテグレーションと自動化を新しい環境で徹底的にテストできます。   \n4\\. 将来性：既存のCIと並行して、チームが徐々にGitLab [CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)に移行できるようにします。\n\n直接GitLabに一括で移行することが望ましいとわかっている場合は、並行移行を行う必要はありません。\n\n### **GitLab.comへの移行手順**\n\n#### **ステップ1：GitLab.comをセットアップする**\n\n* 会社で使用中のGitLab.comのグループがあるかどうか、またシングルサインオン（SSO）を設定済みであるかどうかを確認します。グループがあり、シングルサインオンを設定済みである場合は、両方とも使用することになります。\n\n* GitLab.comに会社で使用しているグループがない場合は、[GitLab.com](https://app.contentful.com/spaces/r9o86ar0p03f/entries/www.gitlab.com)にアクセスして新規アカウントを作成するか、既存のアカウントにログインしてください。\n\n* 会社用のネームスペース（Gitlab.comのルートレベルのグループ）を新たに作成します。  \n* ネームスペースに、（これまでに使用されていない）会社に合った名前を付けます。\n\n#### **ステップ2：リポジトリをインポートする**\n\n並行移行の場合：GitLabのプルミラーリング機能を使用して、AWSにホストされているリポジトリからGitLab.comに変更を自動的に同期します。\n\n1. GitLab.comのターゲットグループに移動します。  \n2. 右上の「新規プロジェクト」をクリックします。   \n3. 「新しいプロジェクトを作成」ページで「プロジェクトをインポート」をクリックします。   \n4. 「プロジェクトをインポート」ページで「URLによるリポジトリ」をクリックします。  \n5. 「GitリポジトリのURL」フィールドに、AWSにホストされているリポジトリのURLを入力します。   \n6. 「GitリポジトリのURL」フィールドの下にある「リポジトリをミラーリング」にチェックを入れます。  \n7. 認証の設定：AWS CodeCommitコンソールで、移行するリポジトリのクローンURLを選択します。CodeCommitリポジトリをGitLabに移行する場合は、HTTPS CodeCommit URLを使用して、GitLabのリポジトリのミラーリングを介してリポジトリをクローンできます。また、GitLabにAWSのIAMユーザーに割り当てたGit認証情報を入力する必要があります。AWS CodeCommit用のGit認証情報を作成する方法は、こちらの[AWSガイド（外部サイト）](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html)に従ってください。\n\n![クローンURL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/clone-url-screenshot__1__aHR0cHM6_1750097822121.png)\n\nこの設定を行うと、デフォルトでは5分ごとにAWSにホストされているリポジトリからGitLab.comに変更が自動的にプルされます。\n\n詳細については、[リポジトリのミラーリングに関するドキュメント](https://docs.gitlab.com/ee/user/project/repository/mirror/)をご参照ください。\n\n#### **ステップ3：インテグレーションのテストと検証を行う**\n\n1. [CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)パイプライン：既存のパイプラインを複製するために、GitLab CIで `.gitlab-ci.yml`  ファイルを設定します。[他のCIツールからGitLab CI/CDへの移行の計画](https://docs.gitlab.com/ee/ci/migration/plan\\_a\\_migration.html)について詳細をご確認ください。  \n2. イシュートラッキング：プロジェクトのイシューとテストワークフローをインポートします。  \n3. コードレビュー：マージリクエストプロセスとテストレビューワークフローを設定します。\n\n#### **ステップ4：段階的に移行する**\n\n1. 小規模または重要度の低いプロジェクトから移行を始めて、GitLab.comでの作業に慣れましょう。  \n2. チームメンバー向けにトレーニングを行い、新しいワークフローに適応する時間を十分に確保します。  \n3. インテグレーションとワークフローに問題がないことを確認しながら、徐々にその他のプロジェクトを移行します。\n\n詳細については、[CodeCommitからGitLabへの移行の自動化](https://gitlab.com/guided-explorations/aws/migrating-from-codecommit-to-gitlab/-/blob/main/migrating\\_codecommit\\_to\\_gitlab.md)をご参照ください。\n\n#### **ステップ5：移行を完了する**\n\nすべてのテストと検証が完了し、新しい環境にチームが慣れてきたら、完全な移行の計画を立てます。プロジェクトごとに以下の対応を行います。\n\n1. 移行日を決めて、すべてのステークホルダーに通知する。  \n2. 最後のデータ同期を行う。  \n3. ミラーリング設定をGitLabプロジェクトから削除する。  \n4. AWSにホストされているリポジトリを読み取り専用に設定し、すべての開発作業をGitLab.comに移行する。\n\n#### **ステップ6：新しい機能を導入するかどうかを判断する**\n\nGitLabでデベロッパーが利用できるコラボレーションとワークフローの自動化機能は、CodeCommitと比べてはるかに豊富です。これらの機能について理解するには、ある程度時間がかかります。中でもマージリクエストプロセスは、CodeCommitよりも強力です。\n\nGitLab上でリポジトリが安定させてしまえば、既存のソリューションと並行して非常に簡単にGitLab CI/CDを試せることになるでしょう。本番環境のワークフローはそのままに、時間をかけてGitLab CI/CDの自動化を完成させることができるのです。\n\nGitLabのアーティファクト管理も、リリース機能や多くのパッケージレジストリで非常に役に立ちます。\n\n### **第1セクションのまとめ**\n\nGitLabへの並行移行アプローチを採用すると、リスクを最小限に抑えながらスムーズな移行を実現できます。このプロセスを通じて、チームは新しい環境に徐々に適応でき、すべてのインテグレーションと自動化が正しく機能するようになります。並行移行を行う必要がないとわかっていて一括で移行する場合でも、スキップできるのは1つのチェックボックス設定のみです。\n\n## **第2セクション：GitLabとAWS CodeBuildの統合**\n\nAWS CodeBuildを使用して、GitLabリポジトリを構築してコードをテストしたい方は、こちらの完全ガイドを参考にして、CIパイプラインを効率的に設定してください。\n\n### **前提条件**\n\n* GitLab.comアカウント  \n* AWSアカウント  \n* AWS CLI（構成済み）\n\n### **ステップ1：AWS CodeStar ConnectionsでGitLabとの接続を作成する**\n\n1. AWSマネージメントコンソールにログインし、CodeBuildサービスに移動します。  \n2. 左側のナビゲーションパネルから「設定」\\>「接続」の順に選択します。  \n3. 「接続を作成」ボタンをクリックします。  \n4. プロバイダーとして「GitLab」を選択します。  \n5. 接続名を入力して「GitLabに接続」をクリックします。  \n6. GitLabの認証ページにリダイレクトされます。  \n7. 必要な権限を承認します。  \n8. 正常に接続されると、接続ステータスが「利用可能」に変わります。\n\n![CodeStar Connectセットアップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### **ステップ2：AWS CodeBuildプロジェクトを作成する**\n\n1. CodeBuildダッシュボードで「ビルドプロジェクトを作成」をクリックします。  \n2. プロジェクトの名前と説明を入力します。  \n3. ソース設定では、プロバイダーとして「GitLab」を選択します。  \n4. 先程作成した接続を選択し、GitLabのリポジトリとブランチを指定します。\n\n![CodeBuildプロジェクトを追加](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_3_add_codebuild_aHR0cHM6_1750097822123.png)\n\n**注：ステップ3以降では、ご自身の環境とニーズに応じて設定を行ってください。**\n\n### **第2セクションのまとめ**\n\nこのセクションでは、GitLabリポジトリをAWS CodeBuildと統合する方法について詳しく説明しました。このように設定することで、GitLabで行ったコード変更がAWS CodeBuildによって自動的にビルド・テストされる継続的インテグレーションパイプラインを実現できます。\n\n## **第3セクション：GitLabとAWS CodePipelineの統合**\n\nAWS CodePipelineを使用してGitLabリポジトリからの継続的デリバリーを実装しようとしている方は、この詳細なガイドを参考にしてください。GitLabをAWS CodeStar Connectionsプロバイダーとして利用できるようになったため、これまでよりも統合しやすくなりました。\n\n### **前提条件**\n\n* GitLab.comアカウント  \n* AWSアカウント  \n* AWS CLI（構成済み）\n\n### **ステップ1：AWS CodeStar ConnectionsでGitLabとの接続を作成する**\n\n1. AWSマネージメントコンソールにログインし、CodePipelineサービスに移動します。  \n2. 左側のナビゲーションパネルから「設定」\\>「接続」の順に選択します。   \n3. 「接続を作成」ボタンをクリックします。  \n4. プロバイダーとして「GitLab」を選択します。  \n5. 接続名を入力して「GitLabに接続」をクリックします。  \n6. GitLabの認証ページにリダイレクトされます。  \n7. 必要な権限を承認します。  \n8. 正常に接続されると、接続ステータスが「利用可能」に変わります。\n\n![CodeStar Connectセットアップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### **ステップ2：AWS CodePipelineを作成する**\n\n1. CodePipelineダッシュボードで「パイプラインを作成」をクリックします。  \n2. パイプライン名を入力して「次へ」をクリックします。  \n3. ソースプロバイダーとして「GitLab」を選択します。  \n4. 先程作成した接続を選択し、GitLabのリポジトリとブランチを指定します。  \n5. トリガータイプを選択します。リポジトリ内の特定のブランチやファイルタイプに対するプルイベントまたはプッシュイベントに基づいて、CodePipelineパイプラインの実行をトリガーできます。\n\n![ソースプロバイダーを追加](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822125.png)\n\n![ソース構成を追加](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_provider_aHR0cHM6_1750097822127.png)\n\n**注：ステップ3以降では、ご自身の環境とニーズに応じて設定を行ってください。** \n\n### **第3セクションのまとめ**\n\nこのセクションでは、GitLabリポジトリをAWS CodePipelineと統合する方法について詳しく説明しました。このように設定することで、GitLabで行ったコード変更が自動的にAWS環境にデプロイされる継続的デリバリーパイプラインを実現できます。\n\n## **第4セクション：GitLabへの移行**\n\nGitLabにAWSを統合すると、開発ワークフローとデプロイワークフローを効率化する強力な機能を利用できるようになり、ソースコード管理に伴う問題を解決しやすくなります。統合方法は次のようにいくつかあり、それぞれに独自のメリットがあります。\n\n* AWS CodeStar Connectionsを使用してGitLabとAWSサービスを連携させる場合、さまざまなAWSサービスにGitLabなどの外部のGitリポジトリを接続できるようになるため、より一貫したワークフローを実現できます。この設定方法では、GitLabレポジトリでの自動ビルド、デプロイ、その他の重要なアクションが直接サポートされるため、開発プロセスの一貫性および効率性が向上します。  \n* AWS CodeStar Connections経由でGitLabとAWS CodePipelineを接続すると、完全なCI/CDパイプラインを作成できるため、自動化を次のレベルへと進められます。このアプローチでは、GitLabをAWS CodePipelineと統合することで、CodeBuildやCodeDeployなどのAWSサービスを使用して、ソース管理やビルドからテストやデプロイまでの全プロセスを自動化できます。これにより、堅牢でスケーラブルかつ効率的なデリバリープロセスを実現できます。\n\n![GitLabとAWSを一緒に使用するための新しいテクノロジーとソリューションのチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_configured_aHR0cHM6_1750097822129.png)\u003Cbr>\u003Cbr>\n\n1.AWS CodeStar Connectionsを使ってGitLabとAWSサービスを接続する\n\nAWS CodeStar Connectionsは、外部のGitリポジトリ（GitHubやBitbucketなど）をAWSサービスと接続するためのサービスです。また、CodeStar Connections経由でGitLabをAWSサービスに接続することもできます。GitLabを使用する場合、HTTP Gitサーバーとしてカスタム接続を設定しなければならない可能性があります。 この方法でGitLabに接続できるAWSサービスは以下のとおりです。\n\n* __AWSサービスカタログ__ \n\nAWS Service Catalogは、組織におけるAWSリソースの標準化および管理を支援します。AWS Service CatalogをGitLabと統合すると、リソース管理の透明性が向上し、変更を追跡しやすくなります。具体的には、GitLabのコミットに基づいてカタログの更新を自動化し、運用効率を向上させることができます。\n\n* __AWS CodeBuild__ \n\nAWS CodeBuildは、ソースコードをコンパイルし、テストを実行し、デプロイできるソフトウェアパッケージを生成するマネージド型のビルドサービスです。GitLabとCodeBuildを統合すると、GitLabにコード変更がプッシュされるたびに自動化されたビルドプロセスが開始されるようになります。これにより、ビルドの一貫性が確保され、コラボレーションとバージョン管理を容易に進められます。\n\n* __AWS Glue ノートブックジョブ__ \n\nAWS Glueノートブックジョブは、データの準備とETL （抽出、変換、ロード）タスクを対話形式で開発して実行できるサービスです。GitLabとGlueノートブックジョブを統合すると、ノートブックとETLスクリプトのバージョン管理を行えるようになり、チームメンバー間のコラボレーションが促進され、データ処理パイプラインの品質管理が強化されます。\n\n* __AWS Proton__\n\nAWS Protonは、[マイクロサービス](https://about.gitlab.com/ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture/)とServerlessアプリケーションの開発とデプロイを自動化するサービスです。GitLabとAWS Protonを統合することで、インフラストラクチャをコードとして管理し、デプロイを自動化し、一貫した環境管理を実現できるため、開発プロセスをさらに効率化できます。\n\nAWS CodeStar Connectionsのサポート対象のサービスが増えるにつれ、より多くのAWSサービスをGitLabとさらに簡単に接続できるようになります。そのため、CodeStar Connectionsを新たにサポートするサービスを定期的にチェックすることをお勧めします。\u003Cbr>\u003Cbr>\n\n2. AWS CodeStar Connections経由（CodeDeployを含む）でCodePipelineとGitLabを接続する\n\nAWS CodePipelineは、ソフトウェアのリリースプロセスを自動化する継続的デリバリーサービスです。GitLabとCodePipelineを接続するには、AWS CodeStar Connectionsを使用する必要があります。この設定方法を用いると、GitLabリポジトリをソースとして指定し、CI/CDパイプライン全体を自動化できます。 CodePipelineがサポートする主なアクションは以下のとおりです。\n\n* __ソース管理__ ：AWS CodeCommit、GitHub、Bitbucket、GitLab  \n* __ビルドとテスト__ ：AWS CodeBuild、Jenkins  \n* __デプロイ__ ：AWS CodeDeploy、Elastic Beanstalk、ECS、S3  \n* __承認__ ：手動承認  \n* __インフラストラクチャ管理__ ：AWS CloudFormation  \n* __Serverless__ ：AWS Lambda  \n* __テスト__ ：AWS Device Farm  \n* __カスタムアクション__ ：AWS Step Functions\n\nGitLabとCodePipelineを統合すると、GitLabにコード変更がプッシュされるたびにパイプラインが自動的にトリガーされるため、一貫したプロセスでビルドからデプロイまでを行えます。さらに、これをGitLabのバージョン管理機能と組み合わせることで、デプロイの履歴と状態を簡単に追跡できるようになり、より柔軟で信頼性の高いソフトウェアデリバリーを実現できます。\n\n## **まとめ**\n\nこのガイドでは、GitLabへの移行、およびGitLabとAWSとの統合に関する包括的な情報を提供しました。4つの主なトピックを通して、以下の内容を取り上げました。\n\n* GitLabへの並行移行：リスクを最小限に抑えつつ、AWSにホストされている既存リポジトリからGitLab.comへ徐々に移行する方法。  \n* AWS CodeBuildとの統合：GitLabリポジトリと統合された強力なCI環境を設定する手順。  \n* AWS CodePipelineとの統合：GitLabリポジトリを使用して効率的な継続的デリバリーパイプラインを構築する方法。  \n* CodePipelineとCodeStar Connectionsのダウンストリーム統合：GitLabとAWS間の接続を活用して広範なサービスの利用を実現する方法。この方法を用いると、AWSエコシステム全体での統合の可能性が連鎖的に広がります。\n\nコードホスティングと統合の実装戦略は組織ごとに異なります。このガイドをチュートリアルとして、貴社独自のGitLab とAWSの統合および実装戦略の出発点としてご利用ください。\n\n## **リソース**\n\nより詳しい情報と高度な設定については、以下のリソースを参照してください。\n\n* [GitLabドキュメント](https://docs.gitlab.com/)  \n* [AWS CodeBuildユーザーガイド](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)  \n* [AWS CodePipelineユーザーガイド](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)  \n* [GitLab CI/CDドキュメント](https://docs.gitlab.com/ee/ci/)  \n* [AWSとの統合](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab\\_aws\\_integration.html)\n\nご質問がある場合やサポートが必要な場合は、[GitLabサポート](https://about.gitlab.com/support/)またはAWSサポートまでお問い合わせください。みなさまがAWSとGitLabの統合を始める上で、こちらの総合ガイドがお役に立てば幸いです。\n\u003Cbr>\u003Cbr>\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[110,920,904,676,2058,701,235],{"slug":3007,"featured":92,"template":681},"ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","content:ja-jp:blog:ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","Ultimate Guide To Migrating From Aws Codecommit To Gitlab","ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"_path":3013,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3014,"content":3020,"config":3025,"_id":3027,"_type":16,"title":3028,"_source":17,"_file":3029,"_stem":3030,"_extension":20},"/ja-jp/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"title":3015,"description":3016,"ogTitle":3015,"ogDescription":3016,"noIndex":6,"ogImage":3017,"ogUrl":3018,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3018,"schema":3019},"『2024 Gartner® Magic Quadrant™ 』のAIコードアシスタント部門でGitLabがリーダーの1社として評価されました","Gartner® Magic Quadrant™の同部門の第1回目の選出において、GitLabはAIコードアシスタント技術における実行能力とビジョンの完全性が評価されました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"『2024 Gartner® Magic Quadrant™ 』のAIコードアシスタント部門でGitLabがリーダーの1社として評価されました\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-08-22\",\n      }",{"title":3015,"description":3016,"authors":3021,"heroImage":3017,"date":3022,"body":3023,"category":787,"tags":3024},[1327],"2024-08-22","[『2024 Gartner® Magic Quadrant™』のAIコードアシスタント部門](https://about.gitlab.com/ja-jp/gartner-mq-ai-code-assistants/)でGitLabがリーダーの1社として評価されました。この部門が導入された初年度において、このような評価をいただけたことを大変嬉しく思います。この評価は、当社が力を入れている、ソフトウェアデリバリを高速化して、セキュリティを強化し、顧客のイノベーションを促進するAI搭載機能の提供に対する、当社の取り組みが認められたのだと感じており、非常に重要な評価と認識しています。\n\nAIコードアシスタントは、単にコードを生成したりコードを補完するだけではありません。コード品質を向上させ、継続的な学習をサポートすることで、デベロッパーの効率を高める共同パートナーでもあるのです。当社のAIを搭載したGitLab Duoのようなアシスタントが、定型的な作業を自動化し、インテリジェントな提案を行うことで、デベロッパーをアシストし、より高度な問題解決に集中できるようにします。\n\n![Gartner MQ AIコードアシスタントの画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675964/Blog/Content%20Images/AI_Code_Assistants_MQ_graphic__1_.png)\n\n> [2024年AIコードアシスタントに関するGartner® Magic Quadrant™レポート](https://about.gitlab.com/ja-jp/gartner-mq-ai-code-assistants/)をダウンロードする\n\n## AIコードアシスタント：スピーディ、セキュア、シームレスな統合\n\nAIコードアシスタントは、あらゆる規模の組織にとって不可欠な存在であり、DevSecOpsチームがセキュアなソフトウェアを迅速に開発し、デプロイすることを支援します。しかし、AIの真の価値は、ソフトウェア開発ライフサイクル全体にわたって統合されたときに発揮されます。断片的なツールチェーンやデータのサイロ化を招く可能性のある限定的なAIポイントソリューションとは異なり、GitLabの包括的なプラットフォームは、計画段階から本番環境までの全体にAIを組み込み、メトリクスとダッシュボードを通じて全体的な可視性と洞察を提供します。\n\n##  GitLab Duoのパワー\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、デベロッパーのエクスペリエンスを向上して、開発サイクルのセキュリティをシフトレフトし、開発、セキュリティ、運用チーム間のコラボレーションを強化するために設計されたAI機能の包括的なツールボックスです。\n主な機能は次のとおりです：\n\n* コード生成やコード補完をするコード提案機能\n* コードの説明、コードリファクタリング、テスト生成において、アプリ内でコンテキストに応じたサポートをするチャット機能\n* コードの脆弱性をよく理解する脆弱性説明機能\n* 発見された脆弱性を軽減する脆弱性修正機能\n* パイプラインの問題をトラブルシューティングする根本原因分析機能\n* リアルタイムの洞察を得て、組織のAI投資利益率（ROI）を評価するAIインパクト分析ダッシュボード機能\n\n## AIによるROIの最大化\n\nビジネスリーダーやエンジニアリングリーダーは、テクノロジー投資のROIを評価するために、ソフトウェア開発ライフサイクル全体でAIがどのように使用されているかを可視化する必要があります。GitLabの[AIインパクト分析ダッシュボード](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)は、AIの導入率やパフォーマンスの改善などを測定するメトリクスだけでなく、その可視性を提供します。\n\n## 柔軟性、プライバシー、透明性を重視\n\nAI搭載機能を検討中のGitLabのお客様は、GitLab Duoを使用することで、難しい設定なしで即座に、任意のIDEまたはリモート開発ワークスペースでAIのパワーを余すことなく活用できます。柔軟な価格体系と無料トライアルが用意されています。また、[GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/)では、当社のガバナンスと透明性の取り組みを完全に可視化しています。\n\n近い将来、組織はモデルのパーソナライズやセルフホスト型モデルのデプロイによって、戦略的要件や規制要件に合わせて[AIエクスペリエンスをカスタマイズ](https://about.gitlab.com/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/)できるようになります。モデルのパーソナライズにより、企業はGitLab Duoをビジネス目標、運用ニーズ、顧客の期待に密接に合わせてカスタマイズし、AIの可能性を最大限に引き出せます。セルフホスト型モデルの導入により、データが組織のセキュアな環境外に出ることがなくなり、情報漏えいのリスクを低減し、規制の厳しい業界のコンプライアンスを確保できます。\n\n## DevSecOpsでAIの未来をリードする\n\nGitLabは、AIを活用したソフトウェア開発のパートナーです。 当社は、ソフトウェアをより迅速に構築、セキュリティ保護、デプロイできるツールを提供します。GitLabでは、お客様が常にAIの最前線に立てるよう、イノベーションに全力を注いでいます。DevSecOpsに革命を起こし続ける、当社のロードマップの最新情報にご注目ください。\n\n> [2024年AIコードアシスタントに関するGartner® Magic Quadrant™レポート](https://about.gitlab.com/ja-jp/gartner-mq-ai-code-assistants/)をダウンロードする\n\n***出典：2024年8月、Gartner、Magic Quadrant for AI Code Assistants、Arun Batchu、Haritha Khandabattu、Philip Walsh、Matt Brasier***\n\n***GARTNERは、米国および国際的なGartner, Inc.および/またはその関連会社の登録商標およびサービスマークであり、MAGIC QUADRANTはGartner, Inc.および/またはその関連会社の登録商標であり、許可を得てここで使用されています。無断転載は禁止されています。***\n\n***Gartnerは、調査出版物で言及されているベンダー、製品、またはサービスを推奨するものではありません。また、最高評価またはその他の認定を受けたベンダーのみを選択するようテクノロジーユーザーに助言するものでもありません。Gartnerリサーチの発行物は、同社の研究機関の意見で構成されており、事実を表明するものとして解釈されるべきではありません。Gartnerは、本調査に関して、明示的または黙示的を問わず、商品性や特定の目的への適合性をはじめ、いかなる保証も行いません。***\n\n***このグラフィックは、Gartner Incがより大規模なレポートの一部として発表したものであり、文書全体の文脈の中で評価されています。Gartnerの文書を参照するには、Gartner B.V. への開示リクエストが必要になります。***\n",[700,721,702,1330],{"slug":3026,"featured":92,"template":681},"gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants","content:ja-jp:blog:gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants.yml","Gitlab Named A Leader In 2024 Gartner Magic Quadrant For Ai Code Assistants","ja-jp/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants.yml","ja-jp/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"_path":3032,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3033,"content":3039,"config":3044,"_id":3046,"_type":16,"title":3047,"_source":17,"_file":3048,"_stem":3049,"_extension":20},"/ja-jp/blog/customers-sourcenext",{"title":3034,"description":3035,"ogTitle":3034,"ogDescription":3035,"noIndex":6,"ogImage":3036,"ogUrl":3037,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3037,"schema":3038},"外部開発パートナーを含む開発プロセスを、GitLabによるオールインワン開発環境に統合し最適化","社内にあるECを含む最も大きなシステムの開発・運用プロジェクトにおいて、GitLabのすべての機能を有効に活用し、DevSecOpsを実現したソースネクスト株式会社様の事例をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665427/Blog/Hero%20Images/_NYG2730.jpg","https://about.gitlab.com/blog/customers-sourcenext","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"外部開発パートナーを含む開発プロセスを、GitLabによるオールインワン開発環境に統合し最適化\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-08-21\",\n      }",{"title":3034,"description":3035,"authors":3040,"heroImage":3036,"date":3041,"body":3042,"category":2156,"tags":3043},[738],"2024-08-21","ソースネクスト株式会社（以下、ソースネクスト）は、社内にあるECを含む最も大きなシステムの開発・運用プロジェクトにおいて、GitLabのすべての機能を有効に活用し、DevSecOpsを実現しました。社内の開発メンバーと外部の開発パートナー企業がGitLabをひとつの開発プラットフォームとして駆使し、プロセスの厳格化によるビジネスリスク低減に成功。同時に、Deploy工程の9割を自動化するなどの工数削減効果を得て、生産性250％アップという成果に結びつけることができました。\n\n## 目次\n1. 3つの開発環境をGitLabでひとつに統合\n2. オールインワン開発環境のGitLabをフルに使ってやってみる\n3. Deploy工程の9割を自動化、生産性は250％アップ\n4. 「気づいていないリスク」を可視化する価値\n\n## 3つの開発環境をGitLabでひとつに統合\n\nソースネクストは、パソコン・スマートフォンソフトウェアおよびハードウェア製品の企画・開発・販売を行う東証プライム市場上場企業です。「製品を通じて、喜びと感動を、世界中の人々に広げる」という創業以来の思いから、消費者とメーカーにとって最適なプライシング戦略が強み。近年はIoT製品の取り扱いを広げ、AIを活用した取り組みも積極化させるなど、最新テクノロジーをうまくビジネスに取り入れながら成長を続けています。\n\n同社では、ソフトウェア開発において、少数精鋭の社内エンジニアと外部開発パートナー企業との協業体制を取っています。長年一緒にやる中で関係性は深まり、優れたチーム同士が役割分担しながらシステムをブラッシュアップしてきました。しかし、セキュリティとガバナンスが大きな経営課題としてクローズアップされる中、より密にチーム同士を連携させ、一貫した厳格な開発プロセスへと移行とすることで、ビジネスへのリスクを極小化したいというニーズが出てきました。\n\n同社 CIO 高沢 冬樹氏は、「開発環境刷新の対象としたシステムを担当する外部開発パートナーは2社で、どちらもスキルが高く、信頼できるメンバーがそろっている企業です。ただ、以前の開発プロセスは、社内のものと2社のものが同時に走る状態で、いわば3つのDevOpsが並立していたようなイメージだったのです」と話します。\n\nこれら3つの開発環境を統合するとともに、セキュリティを開発プロセスに取り込む __DevSecOps__  \u003Csup>*\u003C/sup>へと昇華させたい――。高沢氏も経営層も意見は同じでしたが、管理を厳格化すると現場がやらなければならないことが増え、結果として現場に負担を強いることになります。そこで、DevSecOpsを定着させて経営の求める厳格な開発プロセスへと移行しながら、同時に現場を楽にする自動化をやり遂げ、負担をトレードオフするという発想が生まれました。\n\n\u003Csup>*\u003C/sup>*開発と運用を統合するDevOpsにセキュリティを加え、運用を視野に入れながら開発とセキュリティを同時に進め、安心・安全なソフトウェアを迅速にリリースするというコンセプト。*\n\n## オールインワン開発環境のGitLabをフルに使ってやってみる\n![DSC2776](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687819/Blog/Content%20Images/_DSC2776.jpg)\nソースネクスト株式会社 CIO 高沢 冬樹氏\n\nDevSecOpsを検討するにあたり、ソースネクストは株式会社トレンドソリューションズ（以下、トレンドソリューションズ）に協力を依頼しました。そして、市場にあるDevSecOpsソリューションの中から、GitLabを本格的に調査することになりました。検討初期において、GitLabの最大の魅力は強力な脆弱性スキャン能力でした。ただ、DevSecOpsのコンセプトを深く理解するようになるにつれ、「1つの製品でDevSecOpsのすべてのプロセスに対応できる」ことと、「豊富なドキュメント系の機能を備えていて、振り返りをしやすい仕組み」こそが、求めている仕様にマッチしていることがわかってきたといいます。\n\n「GitLabだけがあればDevSecOpsを実現できる、というトータルソリューションになっている点は、初めて取り組む上で重要でした。開発コードのセキュリティスキャン、CI/CDなど開発リリース時に必須の個別プロセスに対応できるツールを組み合わせて“DevSecOpsのDIY”をするというアプローチもあるのかもしれませんが、詳細な機能比較をするにしても、だれも体感したことのない機能に優劣をつけようがありません。ですから、まずはGitLabをフルに使ってやりたいことをすべてやってみて、どうしても足りなければそのときに考えようという方向で意見が一致しました」（高沢氏）\n\n今回のプロジェクトで対象となったのは、社内で最も大きなECを含むフロントエンドシステムです。高沢氏は、「スモールスタートでテストしたかったわけではありません。最も難しいところからスタートしたのは、動機が“DevSecOpsを使ってみたい”ではなく、“ビジネスの品質を高めたい”という真剣なものだったから。最初から成果が求められました」と振り返ります。\n\nGitLabの採用を決め、半年をかけてじっくりと新たな開発プロセスを整備していきました。経験豊富なトレンドソリューションズのスペシャリストがプロジェクトをリードし、社内エンジニアが外部開発パートナーを巻き込んで議論を重ね、さまざまな決めごとをクリアしていったのです。\n\n具体的には、GitLabとDevSecOpsのコンセプト理解および共有からスタートし、to beモデルを作成。それに向けた課題をリスト化し、順次プロセスの中に落とし込んでいくイメージです。ワークフローの整備やCI/CDの仕様策定など、専門的な知見が生きる分野はトレンドソリューションズが主導したことで、プロジェクトはスムーズに進みました。\n\n巨大で複雑なシステムであるために、苦労した点もありました。Microsoft Azureベースのシステムであり、「自動化のための呪文（笑）を唱えるとうまくいくところ」（高沢氏）を切り抜ける必要がありました。システムの中にCMSパッケージがあり、その部分と連携するシステム開発においてサーバ側で独特な手法を取りながら自動化するという調整も実施しました。AzureとCMS、GitLabのすべてを深く理解しているメンバーはおらず、最適な着地点を見い出すために全員がプロジェクトの成功にコミットして知識を持ち寄る必要もありました。\n\nプロジェクトメンバーは、これらの課題に立ち向かい、稼働時にはGitLabを使う新たな開発プロセスへと移行することができました。プロジェクト初期から、課題管理にGitLabのイシュー機能を利用したことも、スムーズな移行に役立ちました。これはトレンドソリューションズがGitLab導入プロジェクトでよく使う手法で、初期からすべてのメンバーが仕事の中でGitLabを使う習慣が自然と身につくという点で価値は高かったといいます。\n\n## Deploy工程の9割を自動化、生産性は250％アップ\n![DSC2726](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687819/Blog/Content%20Images/_DSC2726.jpg)\n\n実は、無理をして自動化しなかった部分や、あえて手作業を残した部分もあります。たとえば、CI/CDを工夫し、一部に手作業を加えることでよりセキュアな開発をできるようにしました。Deployにかかわる全工程は、現状で9割の自動化にとどめています。\n\n高沢氏は、「Deploy部分は、もっと自動化しようと思えばできます。ただ、実務を考えると自動化しない部分を残しておいた方が良いと判断したケースもあるのです。たとえば、最後の検証作業はパフォーマンスチェックも含むので、自動化したとしても結局は目視することになります。やろうと思えば95％までならいけるのですが、やめておいた方がより良さそう、というせめぎあいです。もう少し慣れてくると、現場と相談して自動化部分を増やすかもしれません。ただ、現場がやりやすい開発プロセスを目指すなら、9割くらいが最適解かもしれませんし、9割は十分に良い数字だと自負しています」と話しています。\n\nGitLabの稼働後、そのほかにも多くの成果が顕在化しています。エラー検知とセキュリティ診断がプロセスに取り込まれた上に自動化されたことで、作業効率を高めながらプロセスを厳格化することに成功しました。手作業でやっていった際には時間のかかっていたパッケージングプロセスは完全に自動化できました。これらを含め、トータルな作業負荷を低減できたため、エンジニアの生産性は250％以上アップしている感覚があるといいます。\n\nこれまでの“3つのDevOps”は、“ひとつのDevSecOps”になり、自社が担当する部分と開発パートナーに任せる部分をすべてソースコードレベルから、イシューを含めて管理できます。これにより、初期開発時の思想を含めてすべての情報を管理できるようになりました。また、以前は時間を要していた組織をまたいだマージリクエスト処理でも、“組織”という壁はもはやありません。\n\n## 「気づいていないリスク」を可視化する価値\n![DSC2722](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687819/Blog/Content%20Images/_DSC2722.jpg)\n\n高沢氏は、「開発における最大の課題は、“気づいていないリスク”です」と話します。あらゆるシステムは、「将来にわたって絶対にリスクがない」と言えませんが、それ以上に、「今リスクがあるのかどうかも不確かであり、確かめようがなかった」のです。「例えば、サードパーティのJSライブラリを、ユーザー体験をより良くするためにWebサイトのごく一部で使っていた、などのケースはよくあることです。これらは存在すら見つけにくい上に、コールするライブラリの先の先にリスクが潜んでいる場合もあります。ソースコードチェックだけでリスク発見することはほぼ不可能です」。\n\nGitLabで一貫したDevSecOpsを実現したことで、コールするライブラリの先の先までを自動検証し、リスクを避けることができます。目指していた姿は、「100％安全なシステムはありえないけれど、“ここまできちんとやっている”と自信を持って説明できる状態」（高沢氏）です。そして、それを実現することができました。今回の成功を受けて、販売する製品別のシステム開発プロジェクトや、社内業務システムの開発・運用プロジェクトにも、今後GitLabを展開する計画も出てきました。\n\nソースネクストがDevSecOpsを推進している、という噂は、IT関係者に伝わり始めているようです。そのため、高沢氏は各社のCIOが集まる場で意見を求められるケースが増えてきたといいます。\n\n高沢氏は、「DevSecOpsは国内企業からも大きな注目を集めていて、私たちがGitLabを使って __シフトレフト__ \u003Csup>**\u003C/sup>に全力で取り組んでいるという話をすると、みなさん興味津々です。ただ、実際に取り組んでいる企業の数となるとまだまだかもしれません。ですから、まずはDevSecOpsというコンセプトを理解すること。そして、それに共感するのであれば、いちはやくスタートすることをおすすめしています」と話してくれました。\n\n\u003Csup>**\u003C/sup> *開発の各フェーズにセキュリティ対策を組み込み、開発効率を向上させながらセキュリティリスクを低減しようとする考え方。GitLabはコード解析、脅威モデリング、テストなどシフトレフトに役立つ機能を提供している。*\n\u003Cbr>\n\u003Cbr>\n\n## ▶️事例PDFを[無料でダウンロードする](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752463863/xmtslzjkrk9noyv7bio1.pdf)\n\u003Cbr>\u003Cbr>",[904,762,110,722,702,764],{"slug":3045,"featured":92,"template":681},"customers-sourcenext","content:ja-jp:blog:customers-sourcenext.yml","Customers Sourcenext","ja-jp/blog/customers-sourcenext.yml","ja-jp/blog/customers-sourcenext",{"_path":3051,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3052,"content":3058,"config":3064,"_id":3066,"_type":16,"title":3067,"_source":17,"_file":3068,"_stem":3069,"_extension":20},"/ja-jp/blog/gitlab-17-3-released",{"title":3053,"description":3054,"ogTitle":3053,"ogDescription":3054,"noIndex":6,"ogImage":3055,"ogUrl":3056,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3056,"schema":3057},"GitLab 17.3リリース","GitLab 17.3でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662141/Blog/Hero%20Images/17-3-cover.png","https://about.gitlab.com/blog/gitlab-17-3-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.3リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-08-15\",\n      }",{"title":3053,"description":3054,"authors":3059,"heroImage":3055,"date":3060,"body":3061,"category":701,"tags":3062,"updatedDate":3063},[738],"2024-08-15","**GitLab Duo の根本原因分析機能を含むGitLab 17.3をリリース**\n\nこのたび、GitLab 17.3がリリースされたことを嬉しく思います。このリリースでは、GitLab Duoによる失敗したパイプラインジョブの根本原因分析、AIアシストによる脆弱性の修正、AIインパクト分析でのコード提案の採用率とGitLab Duoシートの使用率の表示、単一プロジェクトへの複数のコンプライアンスフレームワークの追加などの機能をご利用いただけるようになりました。\n\n本日、GitLab Duoによる失敗したパイプラインジョブの根本原因分析、AIアシストによる脆弱性の修正、コード提案の採用率とGitLab Duoアクティブユーザーの使用率に関するAIインパクト分析、単一プロジェクトへの複数のコンプライアンスフレームワークの追加などの機能を備えたGitLab 17.3のリリースを発表します！\n\nこれらの機能は、今回のリリースに含まれる160件以上の改善点のほんの一部です。役に立つ最新情報をすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 17.3には、GitLabコミュニティのユーザーから130件以上ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、17.4リリースのキックオフビデオも視聴できる[今後のリリースページ](https://about.gitlab.com/direction/kickoff/) をご覧ください。\n\n## **今月のMost Valuable Person（[MVP](https://about.gitlab.com/community/mvp/)）は[Anton Kalmykov](https://gitlab.com/antonkalmykov)さんが受賞**\n\nMVPには、誰でも[GitLabコミュニティのコントリビューターを推薦](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)できます。積極的に活動している候補者を応援したり、他の誰かをノミネートしてみませんか。🙌\n\nAnton Kalmykovさんは、今年特に活躍しているGitLabのコントリビューターの1人で、2月以降、37もの[コントリビューションがマージ](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&author_username=antonkalmykov)されており、現在進行中のその他のイシューにもコントリビュートしてくれています。Antonさんは[Yolo Group（Bombay Games）](https://yolo.com/)のシニアフロントエンドエンジニアです。\n\nAntonさんは次のようにコメントしています。「GitLabへのコントリビューションは、もっとも挑戦しがいがあり、やりがいがあって楽しい取り組みです。このような素晴らしい製品の開発と改善に携わる機会を持てたことに感謝しています。この機会を通じて新たに多くのことを学びましたが、やるべきことがまだたくさんあります。GitLabチーム、中でも私のMRをレビューし、正しい方向に導いてくれた方々にとても感謝しています」\nAntonさんは、[テナントスケール](https://about.gitlab.com/direction/runtime/)グループに関するフロントエンドのイシューの解決を支援したことが評価され、GitLabのシニアプロダクトマネージャーである[Christina Lohr](https://gitlab.com/lohrc)により推薦されました。\n\n「基本的なワークフローに取り組む中で、ユーザーエクスペリエンスに関する小規模な改善を多数行う必要があります。コミュニティユーザーの力を借りて、このような取り組みをより迅速に完了できるのはありがたいことです」とChristinaは述べています。「このようなあらゆる改善を通じて、グループやプロジェクト間でより一貫したユーザーエクスペリエンスを実現できています。Antonさん、ありがとうございます」\n\nこの場を借りて、GitLabを共同開発してくださっているAntonさん、そしてGitLabのオープンソースコントリビューターの方々に心から感謝します！\n\n## **GitLab 17.3でリリースされた主な改善点**\n\n### **根本原因分析による失敗したジョブのトラブルシューティング**\n\nSaaS: Ultimate、Duo Enterprise\nSelf-Managed: Ultimate、Duo Enterprise\n\n根本原因分析の一般提供を開始しました。根本原因分析を使用すると、CI/CDパイプラインで失敗したジョブの問題を迅速に解決できます。AI搭載のこの機能は、失敗したジョブのログを分析し、ジョブの失敗に繋がった根本原因をすばやく特定し、修正方法を提案します。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo/#root-cause-analysis)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13080)\n\n\u003Ciframe width=\"1046\" height=\"588\" src=\"https://www.youtube.com/embed/Yf7Iidf2GW8\" title=\"Troubleshoot pipeline job failures with AI\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### **GitLab Duoのヘルスチェック（ベータ）**\n\nSaaS: \\-\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nSelf-ManagedインスタンスでGitLab Duoのセットアップのトラブルシューティングができるようになりました。GitLab Duoページの**管理者**エリアで、「**ヘルスチェックを実行**」を選択します。このヘルスチェックでは、一連の検証を実行し、GitLab Duoを確実に利用可能な状態にするために適切な是正措置を提案します。\nGitLab Duoのヘルスチェックは、Self-ManagedおよびGitLab Dedicatedでベータ機能として利用可能です。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo/turn_on_off.html#run-a-health-check-for-gitlab-duo)\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/14518)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/Failed_GitLab_Duo_health_check.png\">\n\n### **GitLab UIからポッドを削除**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nKubernetesで失敗したポッドを再起動または削除せざるを得なかったことはありますか。その場合、これまではGitLabを離れて別のツールを使用してクラスターに接続し、ポッドを停止し、新しいポッドが起動されるのを待つ必要がありました。今回、ポッドの削除機能がGitLabに組み込まれたため、Kubernetesクラスターに関する問題をスムーズに解決できるようになりました。\n\nクラスターまたはネームスペース全体のすべてのポッドが一覧表示される[Kubernetes用ダッシュボード](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)から、ポッドを停止できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html#delete-a-pod)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/467653)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/delete-pod.png\">\n\n### **ローカルターミナルからクラスターに簡単に接続**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nローカルターミナル、またはデスクトップ用のKubernetes GUIツールのいずれかを使用して、Kubernetesクラスターに接続したい場合、[Kubernetes用のエージェントのユーザーアクセス機能](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html)を使用してターミナルに接続することが可能になりました。これまでコマンドを見つけるには、GitLabを離れてドキュメントを閲覧する必要がありましたが、今回のリリースでGitLab UIから接続コマンドを利用できるようになりました。さらにユーザーアクセスの設定にも対応します！\n\n接続コマンドを取得するには、[Kubernetesダッシュボード](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html)または[エージェントリスト](https://docs.gitlab.com/ee/user/clusters/agent/work_with_agent.html#view-your-agents)にアクセスしてください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/463769)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/17-3-connect-agent.png\">\n\n### **AIによる脆弱性の修正**\n\nSaaS: Ultimate、Duo Enterprise\nSelf-Managed: Ultimate、Duo Enterprise\n\n脆弱性の修正にAIが活用され、ユーザーが脆弱性を修正できるよう、具体的なコード修正案が提示されるようになりました。ボタンをクリックすると、[SASTがサポートしているCWE識別子リスト](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#availability)から脆弱性の解決作業を開始できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/10783)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/vulnerability_resolution.png\">\n\n### **単一のプロジェクトへの複数のコンプライアンスフレームワークの追加**\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nコンプライアンスフレームワークを作成して、プロジェクトに特定のコンプライアンス要件があるか、もしくは追加の監督が必要であるかを特定できます。コンプライアンスフレームワークをプロジェクトに適用すると、任意でコンプライアンスパイプライン設定を実施できます。\n\nこれまでユーザーは、プロジェクトごとに1つのコンプライアンスフレームワークしか適用できなかったため、プロジェクトに設定できるコンプライアンス要件の数が限られていました。今回、プロジェクトごとに複数のコンプライアンスフレームワークを適用できるようになりました。これにより、特定の時点において複数の異なるコンプライアンスフレームワークを単一のプロジェクトに適用できます。適用後、プロジェクトには各フレームワークのコンプライアンス要件が設定されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#add-a-compliance-framework-to-a-project)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13294)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/multiple-compliance-frameworks.png\">\n\n### **AIインパクト分析：コード提案の採用率とGitLab Duoのシートの使用率**\n\nSaaS: Ultimate、Duo Enterprise\nSelf-Managed: Ultimate、Duo Enterprise\n\nGitLab Duoの有効性と使用率を示す2つの新しいメトリックが、[バリューストリームダッシュボードのAIインパクト分析](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)に追加され、GitLab Duoがビジネス価値の提供にもたらす影響を把握できるようになりました。\n\n**コード提案の採用率**メトリックは、デベロッパーがGitLab Duoによるコード提案を採用する頻度を示します。このメトリックは、コード提案の有効性と、コントリビューターのAI機能に対する信頼度の両方を反映します。具体的には、このメトリックは過去30日間にコードコントリビューターが採用したGitLab Duoによるコード提案の割合を示します。\n\n**アサイン済みおよび使用済みのGitLab Duoシート**メトリックは、使用されているライセンスシートの割合を示します。組織はこのメトリックを参考にして、ライセンスの使用状況やリソースの割り当て、使用パターンを把握する計画を効果的に立てられます。このメトリックは、過去30日間に1つ以上のAI機能を使用したアサイン済みのシートの割合を追跡します。\n\nこれらの新しいメトリックの追加に伴い、新しい概要タイルも導入されました。メトリックのサマリーがわかりやすく視覚的に表示されるため、AI機能の現状を迅速に評価できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#ai-impact-analytics)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/471168)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/173_ai_tiles.png\">\n\n## **GitLab 17.3のその他の改善**\n\n### **コマンドパレットを使用したグループ設定の検索**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n17.2では、[コマンドパレットを使用してプロジェクトを検索する](https://about.gitlab.com/releases/2024/07/18/gitlab-17-2-released/#find-project-settings-by-using-the-command-palette)機能を追加しました。この変更により、必要な設定をすばやく見つけやすくなりました。\n\n17.3では、コマンドパレットからグループ設定も検索できるようになりました。グループを開き、「**検索または移動先…**」を選択し、コマンドモードで「`>`」を入力してから設定セクションの名前（**マージリクエストの承認**）を入力してみてください。表示された結果をクリックすると、その設定に移動できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/search/command_palette.html)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/448646)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/manage-search-for-group-settings.png\">\n\n### **APIを使用した継承設定の切り替え**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nこれまではUIからのみ、プロジェクトにインテグレーション設定を継承するか、独自の設定を使用するかを制御できました。\n\n本リリースでは、すべてのインテグレーションのREST APIパラメータに`use_inherited_settings`が追加されるようになります。このパラメータを使用すると、APIを用いてプロジェクトにインテグレーション設定を継承するかどうかを設定できます。パラメータを設定していない場合、デフォルトの動作は`false` であり、プロジェクト独自の設定を使用します。\n\n[ドキュメント](https://docs.gitlab.com/ee/api/integrations.html)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/467089)\n\n### **タスクへのマージリクエストの追加**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nタスクは、イシューをエンジニアリング実装ステップに分割する際によく使用されます。このリリース以前は、実装されているマージリクエストにタスクを結びつける方法はありませんでしたが、今回のリリースで、マージリクエストの説明からイシューを参照するときと同様に[クロージングパターン](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)を使用することが可能になりました。タスクビューでは、関連するマージリクエストがサイドバーに表示されます。プロジェクトの[自動完了設定が有効](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#disable-automatic-issue-closing)になっている場合、関連するマージリクエストがデフォルトのブランチにマージされると、タスクが自動的にクローズされます。\n[ドキュメント](https://docs.gitlab.com/ee/user/tasks.html#add-a-merge-request-and-automatically-close-tasks)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/440851)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/task-merge-requests.png\">\n\n### **タスクやOKR（Objective and Key Results）アイテムの不正利用の報告**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n従来のイシューと同様、「**アクション**」メニューから直接、作業アイテムの不正利用を簡単に報告できるようになりました。この新機能を使用すると、不適切なコンテンツにすばやくフラグを立てられるため、ワークスペースがクリーンかつ安全に保たれて、チームのコラボレーション環境が向上します。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/report_abuse.html)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/461848)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/report_abuse_for_task_objective_and_key_result_items.png\">\n\n### **OKRとタスクの親アイテムの設定**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n[OKR](https://docs.gitlab.com/ee/user/okrs.html#set-an-objective-as-a-parent)と[タスク](https://docs.gitlab.com/ee/user/tasks.html#set-an-issue-as-a-parent)の親の割り当てを子レコードから直接、簡単に更新できるようになりました。もういろいろな画面を行ったり来たりする必要はありません。これは、当社の目標である[ワークフローの効率性の向上](https://gitlab.com/groups/gitlab-org/-/epics/10501)に向けた大きな一歩です。\n参考：[OKRとは](https://about.gitlab.com/ja-jp/blog/what-is-an-okr/)？\n\n[ドキュメント](https://docs.gitlab.com/ee/user/okrs.html#set-an-objective-as-a-parent)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11198)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/parent_widget_for_work_items.png\">\n\n### **JetBrains IDEでのTLSサポートの向上**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n機密性の高い環境でセキュリティを強化するために、JetBrains IDEの設定で、クライアント証明書や公開認証局（CA）などのカスタムHTTPエージェントオプションを直接設定できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/editor_extensions/jetbrains_ide/#add-a-custom-certificate-for-code-suggestions)\n[イシュー](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/issues/371)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/certificate-settings.png\">\n\n### **CI/CDカタログコンポーネントの入力の詳細に説明とタイプを追加**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nカタログのCI/CDコンポーネントの詳細ページには、コンポーネントに関する有用な情報が表示されます。本リリースでは、利用可能な入力に関する情報を示す表に2つの列を追加しました。新たに追加された「**説明**」および「**タイプ**」列を使用すると、入力が何に使用され、どのようなタイプの値が想定されるかが非常にわかりやすくなります。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/components/#cicd-catalog)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/426870)\n\n### **GitLab Runner 17.3**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n本日、GitLab Runner 17.3がリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、軽量で拡張性の高いエージェントです。GitLab Runnerは、GitLabに組み込まれているオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\n**バグの修正：**\n\n* [Kubernetes Runnerでキャンセルすると、ジョブがハングアップする模様](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37780)\n* [指定されていない場合、ログレベルが更新されない](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37490)\n* [Runner Kubernetes executorを使用すると、ジョブログにより余計な改行が追加される](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27099)\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/17-3-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### **マージトレインの可視化**\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nマージトレインを可視化して、パイプラインのマージリクエストのステータスと順序を、より的確に理解できるようになりました。マージトレインの可視化により、コンフリクトを早めに特定し、マージトレイン内で直接マージリクエストに対してアクションを実行し、デフォルトブランチを破損するリスクを最小限に抑えられます。(補足：マージトレインの可視化は、複数のマージリクエストを並列で管理し、マージ前の競合を事前に解決する機能です)\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html)\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13705)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/merge-train-visualization.png\">\n\n### **Kubernetes 1.30のサポート**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n本リリースでは、2024年4月にリリースされたKubernetesバージョン1.30のフルサポートが追加されました。Kubernetesにアプリをデプロイすると、接続しているクラスターを最新バージョンにアップグレードし、そのすべての機能を利用できるようになります。\n[Kubernetesのサポートポリシーやサポートされているその他のKubernetesバージョン](https://docs.gitlab.com/ee/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)について、詳細をご確認ください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/456929)\n\n### **SAST、IaCスキャン、シークレット検出で使用されるルールセットの実施**\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nリポジトリにコミットされたローカル設定ファイルを作成するか、CI/CD変数を設定して複数のプロジェクトに共有設定を適用することで、[SAST](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html)、[IaCスキャン](https://docs.gitlab.com/ee/user/application_security/iac_scanning/#customize-rules)、[シークレット検出](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html#customizing-analyzer-settings)で使用されるルールをカスタマイズできます。\nこれまでは共有ルールセットの参照が設定されている場合でも、スキャナーはローカル設定ファイルを優先していました。この優先順位により、スキャンの際に既知の信頼できるルールセットを確実に使用することは困難でした。\n\n今回、新しいCI/CD変数`SECURE_ENABLE_LOCAL_CONFIGURATION`が追加され、ローカル設定ファイルを許可するかどうかを制御できるようになりました。この変数は、ローカル設定ファイルの使用を許可するかどうかを制御します。デフォルトではローカル設定が優先されますが、これを無効にすると、共有設定が優先されます。[スキャンの実行](https://docs.gitlab.com/ee/user/application_security/#enforce-scan-execution)時にこの値を`false`に設定すると、プロジェクトメンバーのデベロッパーによりローカル設定ファイルが追加された場合でも、スキャンの際に共有ルールセットまたはデフォルトルールセットが確実に使用されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html#specify-a-remote-configuration-file)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/414732)\n\n### **マージリクエストの外部ステータスチェックに認証を追加**\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\n外部ステータスチェックの設定時、HMAC（ハッシュベースのメッセージ認証コード）認証を指定できるようになりました。これにより、GitLabから外部サービスへのリクエストの信頼性をより安全な方法で検証できます。\n\nステータスチェックを有効にすると、共有シークレットを使用してリクエストごとに一意の署名が生成されます。生成された署名は、ハッシュアルゴリズムとしてSHA256を用いて、`X-Gitlab-Signature`ヘッダーで送信されます。\n\n* セキュリティの向上：HMAC認証はリクエストの改ざんを防ぎ、正当な送信元からのリクエストであることを保証します。\n* コンプライアンス：この機能は、セキュリティを最も重視する銀行など、規制の厳しい業界において特に有用です。\n* 後方互換性：この機能の利用は任意です。また後方互換性があります。ユーザーは、新規または既存のチェックでHMAC認証を有効にするかどうかを選べますが、既存の外部ステータスチェックは変更なく引き続き機能します。\n\n[今後のイテレーション](https://gitlab.com/gitlab-org/gitlab/-/issues/476163)で、GitLabはHTTPリクエストも検証してブロックするオプションを追加する予定です。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/433035)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/status-check-hmac.png\">\n\n### **管理者用UIを使用したパーソナルアクセストークンの無効化**\n\nSaaS: \\-\nSelf-Managed: Free、Premium、Ultimate\n\n管理者は、管理者用UIからインスタンスのパーソナルアクセストークンを無効化または再有効化できるようになりました。以前これを行うには、管理者はアプリケーション設定APIかGitLab Railsコンソールを使用する必要がありました。\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#use-the-admin-ui)[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/436991)\n\n### **カスタムロールに対するLDAPグループリンクのサポート**\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nLDAPグループリンクを使用してグループのユーザー権限を管理している組織は、すでにデフォルトのロールをメンバーシップに使用できます。\n今回のリリースで、そのサポートをカスタムロールに拡張しました。この設定により、多数のユーザーグループへのアクセスをマッピングしやすくなりました。\n\n### **サインアウト時にサブドメインのCookieを保持**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nGitLabのサインアウトプロセスを改善し、サインアウト時に兄弟サブドメインからのCookieが削除されないようにしました。これまでは、これらのCookieは削除されていたため、ユーザーはGitLabと同じトップレベルドメイン上にある他のサブドメインサービスからもサインアウトされてしまっていました。たとえば、ユーザーが`kibana.example.com`上にKibanaを設定し、`gitlab.example.com`上にGitLabを設定している場合、今後はGitLabからサインアウトしても、Kibanaからサインアウトされることはありません。\n\nこの場を借りて、コントリビュートしてくれた[Guilherme C. Souza](https://gitlab.com/GCSBOSS)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/active_sessions.html)\n\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/471097)\n\n### **オムニバスの改善**\n\nSaaS: \\-\nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 17.3には、[Raspberry Pi OS 12](https://www.raspberrypi.com/news/bookworm-the-new-version-of-raspberry-pi-os/)をサポートするパッケージが含まれています。\nDebian 10の[サポートは、2024年6月30日をもって終了](https://www.debian.org/releases/buster/)しました。GitLabでは、GitLab 17.6でDebian 10のサポートを終了します。\n\n[ドキュメント](https://docs.gitlab.com/omnibus/)\n\n### **「マイワーク」でのプロジェクトやグループのソートとフィルタリングの改善**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n「**マイワーク**」でのプロジェクトやグループの概要のソートとフィルタリング機能を更新しました。これまでは、プロジェクトの「**マイワーク**」ページで名前や言語でフィルタリングしたり、事前定義されたソートオプションを使用したりすることができました。今回、**名前**、**作成日**、**更新日**、**スター**といった標準化されたソートオプションを使用できるようになりました。また、昇順または降順でソートするナビゲーション要素を追加し、言語フィルターを「フィルター」メニューに移動しました。新たに追加された「**非アクティブ**」タブで、アーカイブされたプロジェクトを確認できるようになりました。さらに、**ロール**フィルターが追加され、自分がオーナーとなっているプロジェクトを検索することもできます。\n\nグループの「マイワーク」ページでは、**名前**、**作成日**、**更新日**などの標準化されたソートオプションを使用できるようになりました。また、ナビゲーション要素を使用すると昇順または降順でソートすることができます。\nこの変更についてのフィードバックは[イシュー438322](https://gitlab.com/gitlab-org/gitlab/-/issues/438322)で投稿できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/working_with_projects.html#search-in-projects)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/25368)\n\n### **APIを使用して、グループやプロジェクトのWebhookイベントを一覧表示できるように**\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nGitLab 9.3以降のバージョンでは、プロジェクトのWebhookリクエスト履歴をUIで表示できます。また、GitLab 15.3以降のバージョンでは、[グループのWebhookリクエスト履歴もUIで表示](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#view-webhook-request-history)されます。\n\n本リリースでは、そのデータにREST APIでアクセスできるようになりました。これにより、Webhookエラーを検出して対処するプロセスを自動化できます。特定の[プロジェクトフック](https://docs.gitlab.com/ee/api/projects.html#get-project-hook-events)と[グループフック](https://docs.gitlab.com/ee/api/groups.html#get-group-hook-events)に関する過去7日間のイベントリストを取得できます。\n\nこの場を借りて、[コミュニティにコントリビュート](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/151048)してくれた[Phawin](https://gitlab.com/lifez)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/api/projects.html#get-project-hook-events)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/437188)\n\n### **スパークラインによって傾向の可視化が強化されたAIインパクト分析**\n\nSaaS: Ultimate、Duo Enterprise\nSelf-Managed: Ultimate、Duo Enterprise\n\n本リリースでは、スパークラインの導入により、[AIインパクト分析](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)が大幅に改善されました。データ表に埋め込まれたこのシンプルなミニグラフは、AIインパクトのデータの読みやすさとアクセシビリティを向上します。新たに導入されたスパークラインでは数値を視覚的な表現に変換することで、長期にわたる傾向を特定しやすくなり、上向きまたは下向きの動きを見つけられます。この新しい視覚的なアプローチにより、複数のメトリックにまたがる傾向を比較するプロセスが効率化され、数字だけに頼っていた場合に必要だった時間と労力を削減できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#ai-impact-analytics)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/464692)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/17.3_aii_spark.png\">\n\n### **サイクルタイム短縮のためのバリューストリーム分析の新しいステージイベント**\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nGitLabにおけるマージリクエスト（MR）の追跡を改善するために、[バリューストリーム分析に新しいステージイベント](https://about.gitlab.com/solutions/value-stream-management/)「**MRのレビュアーが最初にアサイン**」を追加しました。新たにこのイベントが追加されたことで、チームはレビュープロセスのどの場所で遅延が生じているかを特定し、コラボレーションを改善できる機会を見つけ、チームメンバーに対して対応力と責任を高める文化を促進できます。レビュー時間が短縮されると、開発の全体的なサイクルタイムに直接影響し、[迅速なソフトウェアデリバリーにつながり](https://about.gitlab.com/blog/three-steps-to-optimize-software-value-streams/)ます。 例を挙げると、「**MRのレビュアーが最初にアサイン**」からはじまって「**MRをマージ済み**」で終わる新しいカスタムステージ「**マージまでのレビュー時間（RTTM）**」を追加できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#value-stream-stage-events)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/466383)\n\n\u003Ciframe width=\"443\" height=\"249\" src=\"https://www.youtube.com/embed/kblpge6xeL8\" title=\"Optimizing Merge Request review process with Value Stream Analytics\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### **タスク、目標、主な成果内でのスレッドの解決**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nタスク、目標、主な成果においてスレッドを解決できるようになり、重要なやり取りの管理および追跡をしやすくなりました。デフォルトでは解決済みのスレッドは折りたたまれているため、進行中のディスカッションに集中しやすくなり、コラボレーションのワークフローが効率化されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/discussions/#resolve-a-thread)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/458818)\n\n### **VS Codeで言語ごとにコード提案をきめ細かく制御できるように**\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise\nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\n特定のプログラミング言語のコード提案を有効または無効にすることで、VS Codeでのコーディング体験をより細かく制御できます。このようにきめ細かく制御することで、ワークフローをカスタマイズし、ご希望の言語でのコード提案のメリットはそのままに、無関係または邪魔な提案の表示件数を減らせます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html#manage-languages-for-code-suggestions)\n[イシュー](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1388)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/create-granular-language-controls.png\">\n\n### **リポジトリからコンテンツをより簡単に削除できるように**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\n現在、リポジトリからコンテンツを削除するプロセスは複雑です。GitLabにプロジェクトを強制的にプッシュしなければならない可能性があります。そのため、エラーが発生しやすくなり、プッシュを有効にするために保護を一時的に無効にしなければならないこともあります。リポジトリ内にある容量を使いすぎているファイルを削除する場合は、さらに難しい可能性があります。\n\nプロジェクト設定に新しく追加されたリポジトリメンテナンスオプションを使用して、オブジェクトIDリストに基づいてblobを削除できるようになりました。この新しい方法を使用すれば、GitLabにプロジェクトを強制プッシュしなくても、コンテンツを選択して削除できます。\n\nまた、プロジェクトから削除する必要があるシークレットやその他のコンテンツがプッシュされた場合に、テキストを削除する新たなオプションも導入します。ユーザーは、GItLabによりプロジェクト全体のファイルで「`***削除済み***`」に置き換えられる文字列を指定します。テキストの編集後、ハウスキーピングが実行され、古いバージョンの文字列が削除されます。\n\nこの新しいUIにより、コンテンツを削除する必要がある際のリポジトリの管理方法が効率化されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/repository/reducing_the_repo_size_using_git.html#remove-blobs)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/450701)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/create-ui-for-repository-maintenance.png\">\n\n### **ジョブ名でジョブをフィルタリング**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nジョブ名を検索することで、特定のジョブをすばやく見つけられるようになりました。\nこれまでは、ステータスによってのみジョブリストをフィルタリングでき、特定のジョブを見つけるには手動でスクロールする必要がありました。本リリースでは、ジョブ名を入力して結果をフィルタリングできるようになりました。結果に含まれるのは、GitLab 17.3のリリース後に実行されたパイプラインのジョブのみです。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/jobs/)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/387547)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/filter-jobs-by-job-name.png\">\n\n### **macOSでホストされるRunnerのパフォーマンスが向上**\n\nSaaS: Premium、Ultimate\nSelf-Managed: \\-\n\n最近のmacOS 14.5とXcode 15.4へのアップグレードに伴い、パフォーマンスを改善しました。この変更により、Xcodeのビルドジョブは以前のジョブ実行と比べて大幅に高速化されました。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/runners/hosted_runners/macos.html)\n[イシュー](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/job-images/-/issues/6)\n\n### **Kubernetes用エージェントの作成および削除時の監査イベント**\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nKubernetes用エージェントは、KubernetesクラスターとGitLabの間で双方向のデータフローを実現するため、システムにアクセスできるコンポーネントが追加または削除されるタイミングを把握するのは重要なことです。これまでのリリースでは、コンプライアンスチームはカスタムツールを使用するか、GitLabで直接これらのデータを検索する必要がありました。本リリースから、GitLabでは次の監査イベントを提供するようになりました。\n\n* `cluster_agent_created`：新しいKubernetes用エージェントを登録したユーザーに関する記録\n* `cluster_agent_create_failed`：新しいKubernetes用エージェントを登録しようとしたものの、失敗したユーザーに関する記録\n* `cluster_agent_deleted`：Kubernetes用エージェントの登録を削除したユーザーに関する記録\n* `cluster_agent_delete_failed`：Kubernetes用エージェントの登録を削除しようとしたものの、失敗したユーザーに関する記録\n\nこれらの監査イベントによって`cluster_agent_token_created`および`cluster_agent_token_revoked`監査イベントが拡張され、GitLabインスタンスの監査機能がさらに強化されます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/audit_event_types.html#deployment-management)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/462749)\n\n### **GitLab UIでSBOMの取り込みエラーが表示されるように**\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nGitLab 15.3では、CycloneDX SBOMの[取り込み](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscyclonedx)が新たにサポートされました。SBOMレポートはCycloneDXスキーマと照らし合わせて検証されるものの、検証の一環として生成された警告やエラーはユーザーには表示されませんでした。\n\nGitLab 17.3では、このような検証メッセージをGitLabの画面上で確認できるようになり、プロジェクトレベルの脆弱性レポートと依存関係リストのページに表示されます。\nGitLabの画面上（プロジェクトレベルの脆弱性レポート、依存関係リストページ、パイプラインページの「ライセンス」と「セキュリティ」タブ）でSBOMの取り込みエラーを確認できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_list/)\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/14408)\n\n### **依存関係スキャンとライセンススキャンでRustをサポート**\n\nSaaS: Ultimate\nSelf-Managed: Ultimate\n\nコンポジション解析で、Rustでの依存関係スキャンとライセンススキャンのサポートを開始しました。Rustスキャンでは、`Cargo.lock`ファイルタイプをサポートします。\nプロジェクトでRustスキャンを有効にするには、[CI/CDコンポーネントの依存関係スキャン](https://gitlab.com/explore/catalog/components/dependency-scanning)の`cargo`テンプレートを使用してください。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/#supported-languages-and-package-managers)\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/13093)\n\n### **ユーザープロファイルへのBluesky IDの追加**\n\nSaaS: Free、Premium、Ultimate\nSelf-Managed: Free、Premium、Ultimate\n\nGitLabプロファイルにBluesky did:plc識別子を追加できるようになりました。\nこの場を借りて、コントリビュートしてくれた[Dominique](https://domi.zip/)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/#add-external-accounts-to-your-user-profile-page)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/451690)\n\n### **高度な検索のためのエンドツーエンドのインスタンスのインデックス作成**\n\nSaaS: Premium、Ultimate\nSelf-Managed: Premium、Ultimate\n\nGitLabで高度な検索を有効にする際に「**インスタンスにインデックスを作成**」を選択して、初期インデックスを作成したり、ゼロからインデックスを再作成したりできるようになりました。この設定では、サポートされているすべての種類のデータのインデックスが、統合されたElasticsearchまたはOpenSearchクラスターに作成されるため、`gitlab:elastic:index`のRakeタスクと同等の機能レベルが実現されます。\n\n初期インデックス作成のみ可能であったすべてのプロジェクトでのインデックス作成設定は、「**インスタンスにインデックスを作成**」設定に置き換わります。\n\n[ドキュメント](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html#index-the-instance)\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/271532)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_3/update_index_all_projects_to_allow_end_to_end_instance_indexing.png\">\n\n## **バグ修正、パフォーマンスの改善、UIの改善**\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験を届けることを約束します。\n\n以下のリンクをクリックして、17.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=17.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=17.3)\n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.3)\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#compliance-pipelines)\n* [CodeClimateベースのCode Qualityスキャンが削除されます](https://docs.gitlab.com/ee/update/deprecations.html#codeclimate-based-code-quality-scanning-will-be-removed)\n* [GitGuardianのシークレット検出をスキップするオプションの名前が変更されました](https://docs.gitlab.com/ee/update/deprecations.html#rename-options-to-skip-gitguardian-secret-detection)\n\n## **削除された機能と破壊的な変更**\n\n削除されたすべての機能の一覧は、[GitLabのドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードをサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n## **GitLabのアップグレードに関する重要なお知らせ**\n\nバックグラウンドでの移行が完了されるようにするには、GitLab 17.4にアップグレードする前に、まずはGitLab 17.3にアップグレードする必要があります。\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ワークフロー](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のダウンロードページ](file:///C:\\\\install\\\\)をご覧ください。\n\n### **更新**\n\n[更新ページ](https://about.gitlab.com/update/)を確認してください。\n\n### **ご不明な点がある場合**\n\nご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、[GitLabフォーラム](https://forum.gitlab.com/)にアクセスして質問を投稿してください。\n\n### **GitLabサブスクリプションプラン**\n\n* [Freeプラン](https://about.gitlab.com/pricing/)\n\n  個人ユーザー向けの永久無料機能を提供\n\n* [Premiumプラン](https://about.gitlab.com/pricing/premium/)\n\n  チームの生産性と調整を強化\n\n* [Ultimateプラン](https://about.gitlab.com/pricing/ultimate/)\n\n  組織全体のセキュリティ、コンプライアンス、プランニングに対応\n\nGitLabのすべての機能を[無料](https://about.gitlab.com/free-trial/)でお試しいただけます。\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],"2024-09-24",{"slug":3065,"featured":92,"template":681},"gitlab-17-3-released","content:ja-jp:blog:gitlab-17-3-released.yml","Gitlab 17 3 Released","ja-jp/blog/gitlab-17-3-released.yml","ja-jp/blog/gitlab-17-3-released",{"_path":3071,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3072,"content":3078,"config":3085,"_id":3087,"_type":16,"title":3088,"_source":17,"_file":3089,"_stem":3090,"_extension":20},"/ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"title":3073,"description":3074,"ogTitle":3073,"ogDescription":3074,"noIndex":6,"ogImage":3075,"ogUrl":3076,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3076,"schema":3077},"金融サービス業界向け：GitLabの職務分離機能を実装する方法","金融サービス業界において、GitLabの職務分離機能を活用して安全でコンプライアンスに準拠したソフトウェア開発を実現する方法をご説明します。また、規制フレームワークの遵守を支援する機能も併せてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png","https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"金融サービス業界向け：GitLabの職務分離機能を実装する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cherry Han\"},{\"@type\":\"Person\",\"name\":\"Gavin Peltz\"}],\n        \"datePublished\": \"2024-08-13\",\n      }",{"title":3073,"description":3074,"authors":3079,"heroImage":3075,"date":3082,"body":3083,"category":722,"tags":3084},[3080,3081],"Cherry Han","Gavin Peltz","2024-08-13","ソフトウェア開発の過程において、特に金融サービスのようなデータの完全性や規制の遵守が不可欠な業界では、強固なセキュリティとコンプライアンス対策が求められます。これらの基準を維持する上で重要な要素の1つが職務分離（SoD）です。SoDは、プロセス全体の管理を1人に割り当てないようにすることで、エラーや不正行為のリスクを軽減するアプローチです。SoDにより、ソフトウェア開発プロセスの完全性を損なう可能性のある外部からの悪意ある行為を防ぎ、ソフトウェアサプライチェーンにおけるリスクを軽減できます。\n\n## 金融サービス業界におけるSoDの重要性\n\n金融サービス業界では、SoDが機密情報の保護やコンプライアンス遵守の確保を実現する上で重要な役割を果たします。SoDは、金融サービス業界において戦略的に以下のようなメリットをがあります。\n\n* **リスク軽減**：職務を複数の役割に分担することで、システムの完全性や規制コンプライアンスの遵守を損なう可能性のあるエラー、不正行為、無許可のアクティビティのリスクを軽減します。\n* **責任の強化**：明確な職務分担により、1人の担当者がプロセス全体を一貫して管理することができなくなり、結果として透明性と責任意識が高まります。透明性と責任意識は、ステークホルダーや規制当局との信頼関係を維持する上で不可欠です。\n* **規制コンプライアンス**：SoDは、機密性の高い業務が監視と審査の下で行われることを保証する目的で、金融規制によって義務付けられています。これらの基準を遵守することで、ペナルティを回避できるだけでなく、組織の評判も保護されます。\n* **運用の強靭性**：意思決定と実行を分散することで、組織は人的ミスや悪意ある行為、および予期せぬ出来事によってもたらされる混乱の影響を受けにくくなります。\n\n## GitLabによる職務分離とベストプラクティス\nGitLabでは、DevSecOpsワークフロー全体を対象としたエンドツーエンドの職務分離機能を使用できます。\n\n![金融サービスのSoD - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\n上記の図は、SoDの原則を維持するために、マージリクエスト承認ポリシー、保護機能、ユーザー権限、コンプライアンスフレームワーク、監査イベントといった重要な要素がどのように統合され、連携しているかを示しています。各要素については、後続のセクションで安全かつコンプライアンスに準拠した開発環境の構築方法を解説する中で、詳述します。\n\n### マージリクエスト承認ポリシー\n\n金融サービス業界が直面する課題のひとつに、不正またはチェックされていない変更が統合されるのを防ぐ承認メカニズムの実装があります。ここで役立つのが[マージリクエスト承認ポリシー](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html)です。このポリシーにより、セキュリティと開発の職務分離が強制され、デベロッパーが脆弱性を含むコード変更を自分で承認したり、開発チームが適切な監視なしにコードを本番環境に直接デプロイしたりすることを防止できます。\n\nポリシーを作成する際には、承認者として誰が適切であるかを検討することをおすすめします。承認者には、個人ユーザー、アプリケーションセキュリティチームなどのグループ、あるいはメンテナーといったロールタイプを指定できます。さらに制約を加えたい場合は、以下の主要なポリシー機能の使用をご検討ください。\n\n- 作成者による承認を防止：このポリシーにより、マージリクエストの作成者が自身の変更を承認できないようガードレールが設定されます。独立したレビューを求めることで、承認プロセスの客観性と公平性が維持されます。\n\n- コミットを追加したユーザーによる承認を防ぐ：マージリクエストにコミットを追加したユーザーも、承認を行うことができないようにします。これにより、変更に直接関わっていないチームメンバーによって検証が行われる、独立したレビューの原則がさらに強化されます。\n\n- 承認ルールの編集を防止：承認プロセスの整合性を維持するため、GitLabではプロジェクトやマージリクエストレベルで承認ルールの編集を管理者が禁止できます。これにより、一度定義された承認ポリシーが無断で変更されたり回避されたりしないよう保証されます。\n\n- 承認にユーザーパスワードを要求：追加のセキュリティ対策として、GitLabではマージリクエストを承認するユーザーに対して、パスワードの入力を求めることができます。\n\n職務分離を明確に維持するため、マージリクエスト承認ポリシーを含むセキュリティポリシーを格納するための専用の[トップレベルグループを別途作成](https://docs.gitlab.com/ee/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance)することが推奨されます。この設定により、権限を継承するユーザーの数が最小限に抑えられ、ポリシー管理を厳格に制御できます。この専用グループから、目標に合う最上位グループレベルで[セキュリティポリシープロジェクトをリンク](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project)することで、ポリシー管理の手間を軽減し、開発環境全体で包括的なカバレッジを確保できます。\n\nまた、ポリシーがデフォルトで有効になっている場合、そのポリシーは関連するリンクされたグループ、サブグループ、および個別のプロジェクト内のすべてのプロジェクトに適用されることにも注意してください。より対象を絞ってポリシーを適用したい場合、GitLabは[コンプライアンスフレームワークラベル](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html)を使用してポリシーの適用範囲を絞り込むことを推奨しています。厳格な規制に対応しているお客様の多くは、「SOX」や「PCI」などの規制要件に対応するコンプライアンスラベルを作成しています。また、このフレームワークへのリンクにより、[ネイティブコンプライアンスセンター](https://docs.gitlab.com/ee/user/compliance/compliance_center/)でさまざまなユースケースに合わせたセキュリティポリシーを管理できるようになります。\n\n### コンプライアンスフレームワークと制御\n\n規制対象の業界に属するお客様は、大規模な組織においてコンプライアンスを維持する上で大きな課題に直面しています。手動のプロセスはエラーが生じやすく、チーム間でポリシーを一貫して適用し続けることが難しい場合もあります。\n\nGitLabのコンプライアンスフレームワークを使用することで、組織は予防措置の自動化と管理、リスクの体系的な管理、そして規制コンプライアンスのシームレスな適用を実現できます。これらのフレームワークによって、どのようなパイプラインでもセキュリティプロトコルやカスタムジョブを実施できます。\n\nコンプライアンス設定を組織レベルで保護するために、GitLabではグループまたはプロジェクトのオーナーのみがコンプライアンスフレームワークを追加または削除できるようになっています。この対策により、適切な権限レベルを持たない開発チームやマネージャーによるコンプライアンス設定の変更が防止され、セキュリティがさらに強化されます。なお、メンテナー権限を持つ個人がサブグループを作成できる場合、そのサブグループのオーナーとなりコンプライアンスフレームワークを変更できる点に注意してください。これを防ぐには、権限とグループの設定で[サブグループの作成者](https://docs.gitlab.com/ee/user/group/subgroups/#change-who-can-create-subgroups)を制限してください。\n\n## SoDのための権限とロール\n\n金融サービス業界で職務分離を効果的に実施するには、明確かつ正確なアクセス制御の設定が不可欠です。GitLabには、あらかじめ定義されたロール（ゲスト、レポーター、デベロッパー、メンテナー、オーナーなど）による階層的な[権限モデル](https://docs.gitlab.com/ee/user/permissions.html)が備わっています。各ロールには特定の権限セットが割り当てられており、個人が業務を遂行する際に自身の権限の範囲を逸脱しないようになっています。これにより、利益相反やセキュリティリスクを抑えられます。GitLabでは[最小権限の原則](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)に従ってロールを割り当てることを推奨しています。\n\n細かいニーズを持つ組織、特にGitLab Ultimateを使用している組織では、[カスタムロール](https://docs.gitlab.com/ee/user/custom_roles.html)を活用することで、さらに柔軟な対応が可能になります。これらのロールを使用することで、各組織の独自のワークフローやコンプライアンス要件に合わせた特定の権限を設定できます。担当者が相反するタスクを実行できなくなるため、SoDの強制に特に役立ちます。\n\n一般的なユースケースとして、デプロイロールが必要な場合があります。これは、デプロイの権限が必要な個人に対して、コードの編集やプッシュの権限は与えたくない場合に使用できます。こういった要件に対応するために、GitLabは[保護環境](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments)を提供しています。保護環境を使用すると、[ジョブのデプロイ承認を受けたグループを招待](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#deployment-only-access-to-protected-environments)し、ユーザーのロールをレポーターに限定できます。なお、デプロイジョブにはenvironmentキーワードを含める必要があります。この設定により、コードの編集権限がないユーザーがデプロイを実行できるようになり、コンプライアンス要件に準拠できます。\n\n組織においてロールと権限を慎重に定義し適用することで、安全かつコンプライアンスに準拠した開発環境を構築できます。ユーザー権限を広範に見直したい場合、[こちらのグループメンバーレポート](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report)を使用して各ロールのメンバー数を確認し、それに応じた次のステップを検討することが可能です。\n\n## 保護機能\nGitLabは、開発プロセスをより厳重にかんりできるようにするために「保護」機能を提供しています。これらの機能は、指定された担当者のみが重要な変更を行えるようにするために使用でき、SoDを維持するためには不可欠です。\n\n- 保護ブランチ：保護ブランチでは、誰がプッシュ、マージ、または強制プッシュを実行できるかが制限されます。権限を持つユーザーのみが変更を加えられるように制御でき、特に「main」や「production」のようなブランチで効果的です。\n- 保護Gitタグ：このタグを使用すると、タグの作成権限を持つユーザーを制御できます。タグの作成後に誤った更新や削除が発生しないよう防止され、バージョン管理の整合性が保たれます。\n- 保護環境：特定の環境、特に本番環境への無許可のアクセスを防ぐことは必須事項と言えます。保護環境では、適切な権限を持つユーザーのみがデプロイできるため、意図しない変更から環境を保護できます。これは前述のデプロイロール機能と関連しており、コードを編集せずにジョブをデプロイできるようになるため、コンプライアンスとセキュリティを確保できます。\n- 保護パッケージ：パッケージ保護ルールを使用することで、どのユーザーがパッケージに変更を加えられるかを制限できます。\nこれらの保護機能はすべて、SoDの原則に沿った安全でコンプライアンスに準拠した開発環境の維持に役立ちます。\n\n## 監査イベントとコンプライアンスセンター\nここまで承認ポリシー、コンプライアンスフレームワーク、ロール、保護機能について説明してきましたが、最後に、GitLabでこれらの実装をどのようにモニタリングおよび監査してコンプライアンスを遵守できるかについて解説します。GitLabの[監査イベント](https://docs.gitlab.com/ee/user/compliance/audit_events.html)では、ユーザーの活動やプロジェクトの変更など、オーナーや管理者向けに詳細なアクティビティ履歴を提供します。このログは、ユーザーアクションを追跡したり、無許可のアクティビティを検出したりする上で不可欠です。組織において[監査イベントストリーミング](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html)を使用して監査イベントを外部システムにストリーミングすることで、リアルタイムでの分析やアラートが可能になります。これにより、改変や違反が検出され、迅速に修正できるようになります。\n\n[GitLabのコンプライアンスセンター](https://docs.gitlab.com/ee/user/compliance/compliance_center/)は、コンプライアンスに関連するアクティビティを一元的に管理およびモニタリングできる場所です。ここではプロジェクトやグループ全体のコンプライアンス状況の概要を確認でき、マージリクエスト承認ルールやその他のポリシーの違反が強調表示されます。管理者は問題に迅速に対処し、あらかじめ定義されたコンプライアンス基準への準拠を確認できます。この一元化されたアプローチにより、コンプライアンス管理が簡素化され、高度なレベルでモニタリングと制御を行えます。\n\n> GitLabのSoDやコンプライアンスに関する考え方について詳しく知りたい方は、[Governステージに関するGitLabの製品方針](https://about.gitlab.com/direction/govern/) と[GitLabのコンプライアンスドキュメント](https://docs.gitlab.com/ee/administration/compliance.html)をご覧ください。\n\n## その他のリソース\n\n- [GitLabのコンプライアンスとセキュリティポリシー管理で規制基準を遵守](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [GitLabを使ったGitLabの構築：セキュリティ認証ポートフォリオを拡充](https://about.gitlab.com/blog/building-gitlab-with-gitlab-expanding-our-security-certification-portfolio/)\n- [オンライン小売業者bol社、GitLabで拡大するコンプライアンスニーズに対応](https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab/)",[722,904,701,552],{"slug":3086,"featured":6,"template":681},"finserv-how-to-implement-gitlabs-separation-of-duties-features","content:ja-jp:blog:finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","Finserv How To Implement Gitlabs Separation Of Duties Features","ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"_path":3092,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3093,"content":3099,"config":3104,"_id":3106,"_type":16,"title":3107,"_source":17,"_file":3108,"_stem":3109,"_extension":20},"/ja-jp/blog/gitlab-17-1-released",{"title":3094,"description":3095,"ogTitle":3094,"ogDescription":3095,"noIndex":6,"ogImage":3096,"ogUrl":3097,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3097,"schema":3098},"GitLab 17.1リリース","GitLab 17.1でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662125/Blog/Hero%20Images/17_1-cover-image.png","https://about.gitlab.com/blog/gitlab-17-1-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.1リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-08-08\",\n      }",{"title":3094,"description":3095,"authors":3100,"heroImage":3096,"date":3101,"body":3102,"category":701,"tags":3103},[738],"2024-08-08","__GitLab 17.1のリリースでモデルレジストリがベータ版で提供開始、さらにVS Codeで複数のGitLab Duoコード提案が利用可能に__\n\nこのたび、[ベータ版のモデルレジストリ](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#model-registry-available-in-beta)、[VS Codeでの複数のGitLab Duoコード提案](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#see-multiple-gitlab-duo-code-suggestions-in-vs-code)、[ベータ版のシークレットプッシュ保護](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#secret-push-protection-available-in-beta)、[GitLab Runner Autoscalerなどの機能](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#gitlab-runner-autoscaler-is-generally-available)を備えたGitLab17.1のリリースを発表しました。\u003Cbr>\n\nこれらの機能は、今回のリリースに含まれる45件以上の改善点のほんの一部です。この記事では、役に立つ最新情報をすべてご紹介していますので、ぜひ最後までお読みください。\u003Cbr>\n\nGitLab 17.1には、GitLabコミュニティのユーザーから340件以上ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはユーザーのみなさまの協力なしには実現しませんでした。\u003Cbr>\n\n来月のリリースで予定されている内容を先取りするには、17.2リリースのキックオフビデオも視聴できる[今後のリリースページ](https://about.gitlab.com/direction/kickoff/)をご覧ください。\u003Cbr>\n\n## 今月のMost Valuable Person（[MVP](https://about.gitlab.com/community/mvp/)）は[Shubham Kumar](https://gitlab.com/imskr)さんと[Joe Snyder](https://gitlab.com/joe-snyder)さんの2名が同時受賞\n\nMVPには、[誰もがGitLabコミュニティのコントリビューターを推薦できます](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)。現在の候補者を応援したり、他の誰かをノミネートしてみませんか。🙌\u003Cbr>\nShubham Kumarさんは[17.1で7つのイシューを完了するなど](https://gitlab.com/dashboard/issues?sort=due_date_desc&state=closed&assignee_username%5B%5D=imskr&milestone_title=17.1)、2021年以来一貫してGitLabにコントリビュートしてきました。 今では、そのコントリビューションのうち50以上がマージされるまでになりました。Shubhamさんは[GitLab Hero](https://about.gitlab.com/community/heroes/)であり、Google Summer of Codeの前コントリビューターでもあります。\u003Cbr>\n\nShubhamさんを推薦したのは、GitLabのシニアプロダクトマネージャー、[Christina Lohr](https://gitlab.com/lohrc)です。「Shubhamさんは、過去数週間～数か月にわたって特に[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)製品の問題を解決するために力を貸してくれました。Shubhamさんがコントリビュートしてくれた機能の数は膨大で、その内容も書ききれないほどです！」とChristinaは述べています。\u003Cbr>\n\nShubhamさんは「GitLabのオープンソースコミュニティは最高です。この機会をいただけたこと、そして高く評価していただいたことにとても感謝しています。今後もGitLabプラットフォームへのコントリビュートを続けていきたいです」とコメントしています。\u003Cbr>\n\nJoe Snyderさんは、GitLabのプリンシパルプロダクトマネージャーである[Kai Armstrong](https://gitlab.com/phikai)により、 [差分をメールに含まれないよう制限](https://gitlab.com/gitlab-org/gitlab/-/issues/24733)するという待望の機能のビルドで推薦されました。 このコントリビュートには、GitLab 15.3以来10件以上ものマージリクエストがありました。「この機能は大規模なもので、多くの努力、複雑な移行作業、製品への変更作業を経て提供が可能になりました。Joeさんはこの作業を完了のために努力を重ね、多くの管理者やコラボレーターと協力しながらマイルストーンに到達できました」とKaiは語っています。\u003Cbr>\n\nGitLabのプロジェクトマネージャーである[Jocelyn Eillis](https://gitlab.com/jocelynjane)は、 `[build:resource_group](https://gitlab.com/gitlab-org/gitlab/-/issues/361438)` の[ネストされた変数](https://gitlab.com/gitlab-org/gitlab/-/issues/361438)が[展開されない](https://gitlab.com/gitlab-org/gitlab/-/issues/361438)というバグを修正した功績を称えJoeさんを推薦しました。 Jocelynは「このバグ修正に関するお客様からの要望が多かったことに加え、さらに23の同意票が寄せられていました。レビュアーのフィードバックへの迅速な対応により、修正をGitLab 17.1に含めることができました」と述べています。\u003Cbr>\n\nこれは[GitLab 16.6](https://about.gitlab.com/releases/2023/11/16/gitlab-16-6-released/#mvp)以来、Joeさんが受け取る2つ目のGitLab MVPとなります。 Joeさんは[Kitware](https://www.kitware.com/)社のシニア調査開発エンジニアであり、2021年からGitLabへのコントリビュートを続けています。\n\n## GitLab 17.1でリリースされた主な改善点 \n\n### ベータ版のモデルレジストリ\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLabでは、ベータ版のモデルレジストリを非常に重要な機能として位置付け、正式なサポートを開始しました。これにより、UIを介してモデルを直接追加、編集できるほか、MLflow統合機能を利用してGitLabをモデルレジストリのバックエンドとして利用できるようになりました。\u003Cbr>\n\nモデルレジストリは、データサイエンスチームが機械学習（ML）モデルとその関連するメタデータを管理するのに役立つハブであり、トレーニングを受けた機械学習（ML）モデルを組織が保存、バージョン管理、文書化、検出するための一元化された場所として機能します。これにより、モデルのライフサイクル全体にわたるコラボレーション、再現性、ガバナンスが向上します。\u003Cbr>\n\nGitLabはモデルレジストリをチームのコラボレーション、デプロイ、モニタリング、継続的なモデルのトレーニングの基礎となるコンセプトと考えており、ユーザーのみなさまの声をぜひ聞きたいと思っています。[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/465405)からお気軽に意見をお寄せください。こちらから折り返しご連絡いたします。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/ml/model_registry/) \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/9423)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/8uyxk0vhifE?si=-fan7BaDKgqj8ZSe\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### VS Codeで複数のGitLab Duoコード提案を表示\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\nVS CodeのGitLab Duoコード提案に、利用可能な複数の提案の有無が表示されるようになりました。操作は簡単で、提案にカーソルを合わせ、矢印またはキーボードショートカットを使用して候補を切り替えられます。\u003Cbr>\n[ドキュメント](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html#view-multiple-code-suggestions)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1325)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/multiple-code-suggestions-vs-code.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### ベータ版シークレットプッシュの保護\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: -\u003Cbr>\n\nキーや[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)トークンなどのシークレット情報が誤ってGitリポジトリにコミットされた場合、リポジトリにアクセスできる人なら誰でも、悪意のある目的でそのシークレットのユーザーになりすますことができます。このリスクの対処として、ほとんどの組織では漏洩したシークレット情報を失効させて置き換える必要がありますが、そもそも情報がプッシュされなければ、修復にかける時間も必要なく、リスクを軽減できます。\u003Cbr>\n\nシークレットプッシュの保護は、GitLabにプッシュされた各コミットの内容をチェックします。[シークレット情報が検出されると](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/detected_secrets.html)プッシュはブロックされ、次の事項を含むコミットに関する情報が表示されます。\u003Cbr>\n\n- シークレット情報を含むコミットID\n- シークレット情報を含むファイル名と行番号\n- シークレット情報のタイプ\u003Cbr>\n\nテストのためにシークレットプッシュ保護を回避する必要がある場合は、シークレットプッシュ検出をスキップすると、GitLabは監査イベントをログに記録して調査できるようにします。\u003Cbr>\n\nシークレットプッシュ保護は[ベータ](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#beta)機能としてGitLab.comおよびDedicatedのユーザーに提供されており、[プロジェクトごとに](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/index.html#enable-secret-push-protection-in-a-project)有効にできます。 [イシュー467408](https://gitlab.com/gitlab-org/gitlab/-/issues/467408)からフィードバックを投稿し、シークレットプッシュ保護の改善にご協力ください。\u003Cbr>\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection)\u003Cbr>\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/12729)\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/2jBC3uBUlyU?si=hW3nu57X5yJVQr7r\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### GitLab Runner Autoscalerの一般提供開始\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n旧バージョンのGitLabでは、一部のユーザーはパブリッククラウドプラットフォームの仮想マシンインスタンスでGitLab Runnerの自動スケーリングソリューションが必要でした。その場合、レガシーな[Docker Machine executor](https://docs.gitlab.com/runner/configuration/autoscale.html)や、クラウドプロバイダのテクノロジーを使ってつなぎ合わせたカスタムソリューションに依存しなければなりませんでした。\u003Cbr>\n\n本リリースで、GitLab Runner Autoscalerが一般公開されます。GitLab Runner Autoscalerは、GitLabが開発したtaskscalerと[fleeting](https://docs.gitlab.com/runner/fleet_scaling/fleeting.html)テクノロジー、そしてGoogle Compute Engine用のクラウドプロバイダプラグインで構成されています。\n[ドキュメント](https://docs.gitlab.com/runner/runner_autoscale/)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29221)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/runner_fleeting_ga.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### Snowflake MarketplaceでGitLabコネクタアプリケーションが利用可能に\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\n監査イベントが作成され、GitLabに保存されるようになります。今回のリリース以前は、監査イベントはGitLabからのアクセスのみで、GitLab UIを使用して結果を確認するか、すべての監査イベントを構造化されたJSONとして受信するようにストリーミング先を設定する必要がありました。\u003Cbr>\n\n一方でユーザーはSnowflakeといったSIEMソリューションなどのサードパーティの宛先に監査イベントを持つ機能も求めていました。それは次を可能にするからです：\u003Cbr>\n\n- GitLabを含む、組織の複数のシステムからのすべての監査イベントデータを簡単に表示、結合、操作、レポートすること\n- 特定の監査イベントのみを表示し、関心のある質問に迅速に回答\n- GitLab内で起きていることの全体像を把握し、事後確認できる\u003Cbr>\n\nユーザーがこうしたタスクを実行できるよう、Snowflake Marketplace用のGitLabコネクタアプリケーションを作成しました。このアプリケーションは監査イベント[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)を使用します。 この機能を使用するには、[Snowflake Marketplace](https://app.snowflake.com/marketplace/listing/GZTYZXESENG/gitlab-gitlab-data-connector)を使用してアプリケーションをデプロイ・管理する必要があります。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/integration/snowflake.html)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13004)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/gitlab-snowflake-connector.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### Wikiユーザーエクスペリエンスの改善\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLab 17.1のWiki機能はより統一され、ワークフローの効率が改善されました。\u003Cbr>\n\n- 新しいリポジトリのクローンボタンを使用すると、さらに[簡単かつ迅速にクローンを作成](https://gitlab.com/gitlab-org/gitlab/-/issues/281830)できます。 これによりコラボレーションが改善され、編集や表示の際のWikiコンテンツへのアクセスが高速化されます。\n- [削除オプションをわかりやすいデザイン](https://gitlab.com/gitlab-org/gitlab/-/issues/335169)に変更し、見つけやすい場所に移動しました。これによりWikiページの検索にかかる時間が短縮され、Wikiページの管理時に発生する可能性のあるエラーや混乱が最小限に抑えられます。\n- [空白のページが許可](https://gitlab.com/gitlab-org/gitlab/-/issues/221061)されることで、柔軟性が向上します。 必要に応じて空白のプレースホルダーを作成して、Wikiコンテンツの計画と整理に集中し、後で空白のページを埋めることもできます。\u003Cbr>\n\n今回の機能強化により、Wikiワークフローの利便性、発見性、コンテンツ管理機能が向上しました。GitLabでは、Wikiを効率的で使いやすいものにしたいと考えています。 クローンリポジトリへのアクセスを容易にし、主要なオプションを再配置して表示レベルを高め、空白のプレースホルダーを作成できるようにするなど、よりユーザーが利用しやすいプラットフォームになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/wiki/)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/452225)\u003Cbr>\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/t2z7sZoJ6oE?si=Xu22Y7ZIzLP2ByRd\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### 新しいバリューストリーム管理レポート生成ツール\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nバリューストリーム管理用の新しいレポート生成ツールの追加により、意思決定者がソフトウェア開発ライフサイクル（SDLC）の最適化をより効率的かつ効果的に行うことができるようになりました。\u003Cbr>\n[DevSecOps比較メトリクスレポート](https://gitlab.com/components/vsd-reports-generator#example-for-monthly-executive-value-streams-report)または[AIインパクト分析](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#ai-impact-analytics-in-the-value-streams-dashboard)レポートを、GitLabイシューの関連情報とともに自動的かつ主体的に配信するよう設定できるようになりました。 スケジュールされたレポートを活用することで、マネージャーは必要なデータを求めて適切なダッシュボードを手動で検索するなどして時間を浪費することなく、インサイトを分析し、情報に基づいた意思決定に集中できます。\u003Cbr>\n[CI/CDカタログ](https://gitlab.com/explore/catalog)を使用するとスケジュールレポートツールにアクセスできます。\u003Cbr>\n[ドキュメント](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#schedule-value-streams-dashboard-reports) \u003Cbr>\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/10880)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/17.1_vsm_reports2.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### 署名にコンテナイメージを関連付け\n\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: -\u003Cbr>\n\nGitLabコンテナレジストリは、署名されたコンテナイメージとその署名を関連付けるようになりました。この改善により、ユーザーは次をより簡単に実行できます：\u003Cbr>\n\n- 署名されているイメージとそうでないイメージの特定\n- コンテナイメージに関連付けられている署名を見つけて検証\u003Cbr>\n\nこの機能はGitLab.comでのみ一般提供されています。 Self-Managedサポートはベータ版であり、ユーザーはベータ版の[次世代コンテナレジストリ](https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html)を有効にする必要があります。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/packages/container_registry/#container-image-signatures)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/7856)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/container-registry-signatures.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### マニュアルジョブの確認の必須化設定\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nマニュアルジョブは、本番環境へのデプロイといったCIパイプラインで非常に重要な操作をトリガーするために使用できます。今回のリリースでは、マニュアルジョブが実行される前に確認を必須にするよう設定できるようになりました。 `manual_confirmation` と `when: manual` を使用すると、マニュアルジョブが実行された際にUIに確認ダイアログが表示されます。 マニュアルジョブの確認を必須化すると、セキュリティと操作に新たな保護レイヤーが追加されます。\u003Cbr>\nこの場を借りて、コミュニティにコントリビュートしてくれた[Phawin](https://gitlab.com/lifez)さんに感謝します！\u003Cbr>\n[ドキュメント](https://docs.gitlab.com/ee/ci/jobs/job_control.html#add-a-confirmation-dialog-for-manual-jobs)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/18906)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/ask-confirmation-on-manual-job.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### グループ用Runnerフリートダッシュボード\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nグループレベルでSelf-ManagedされたRunnerフリートのオペレーターは、観測性に加え、Runnerフリートインフラストラクチャに関する重要な質問にすぐに回答できる能力が必要です。グループ用のRunnerフリートダッシュボードを使用すると、GitLab UIでRunnerフリートの観測性や実行可能なインサイトを直接得られるようになります。 これによりRunnerの健全性をすばやく判断できるほか、組織のターゲットサービスレベル目標におけるRunnerの使用状況メトリクスとCI/CDジョブキューサービス機能に関するインサイトを得られます。\u003Cbr>\nGitLab.comユーザーは、現在グループ向けに提供されているすべてのフリートダッシュボードメトリクスを利用できます。Self-Managedのユーザーはフリートダッシュボードメトリクスのほとんどの機能を使用できますが、__Runnerの使用状況__ と__ジョブが選択されるまでの待機時間__メトリクスを使用するには、ClickHouse分析データベースを構成する 必要があります。\u003Cbr>\n[ドキュメント](https://docs.gitlab.com/ee/ci/runners/runner_fleet_dashboard_groups.html)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/424789)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/runners-fleet-dashboard-groups-beta.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n## GitLab 17.1のその他の改善 \n\n### Webhook作成時の監査イベント\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\n監査イベントは、GitLabで実行される重要なアクションを記録します。 これまで、システム、グループ、プロジェクトのWebhookがユーザーによって追加される際に監査イベントは作成されませんでした。\u003Cbr>\nこのリリースでは、ユーザーがシステム、グループ、プロジェクトのWebhookを作成する際の監査イベントが追加されました。\u003Cbr>\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/audit_event_types.html#webhooks) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/8068) \u003Cbr>\n\n### APIを使用して選択したプロジェクトリレーションを再インポート\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n同じ種類の多くのアイテム（マージリクエストやパイプラインなど）を含むエクスポートファイルからプロジェクトをインポートする場合、アイテムの一部がインポートされないことがあります。\u003Cbr>\n\n本リリースでは、名前が付けられているリレーションを再インポートし、すでにインポートされているアイテムをスキップする[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)エンドポイントが追加されました。APIには以下の両方が必要です：\u003Cbr>\n- プロジェクトエクスポートアーカイブ\n- イシュー、マージリクエスト、パイプライン、マイルストーンのいずれかのタイプ\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/project_import_export#import-a-single-relation) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/455889)\u003Cbr>\n\n### REST APIを使用して実行中の直接転送移行をキャンセル\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nこれまで、実行中の直接転送移行をキャンセル[するにはRailsコンソールへのアクセスが必要](https://docs.gitlab.com/ee/user/group/import/direct_transfer_migrations.html#cancel-a-running-import)でした。\u003Cbr>\n\n今回のリリースでは、REST APIを使用して管理者が移行をキャンセルできる機能が追加されました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/bulk_imports.html#cancel-a-migration) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/438281)\u003Cbr>\n\n### イメージアップロード時に貼り付けるイメージの縮小\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLab 17.1では高解像度画像の処理性能が強化され、アップロード中にイメージが縮小できるようになりました。以前、イメージは元のサイズで表示されていたため、表示のされかたが最適ではありませんでした。これにより、大きなイメージが含まれているページでもレイアウトが崩れないよう改善されました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/markdown.html#change-the-image-or-video-dimensions) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/419913)\u003Cbr>\n\n### GitLab APIコールでの相互TLSのPagesサポート\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLabは[SSL証明書を使用してクライアント認証を実施](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#:~:text=enforce%20client%20authentication%20with%20SSL%20certificates)するよう設定できますが、GitLab Pagesサービスはクライアント証明書を使うよう設定できないため、この機能と互換性がなく、内部[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)コールは却下されていました。\u003Cbr>\n\nGitLab 17.1以降GitLab Pagesのクライアント証明書の設定が可能となり、GitLab APIでクライアント認証を有効にしてGitLabインスタンスのセキュリティを強化できるようになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/pages/#support-mutual-tls-when-calling-the-gitlab-api) \u003Cbr>[イシュー](https://docs.gitlab.com/ee/administration/pages/#support-mutual-tls-when-calling-the-gitlab-api)\u003Cbr>\n\n### 名前の変更時にWikiページを新しいURLにリダイレクト\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLab 17.1では、Wikiページのリダイレクト機能が大幅に強化されました。Wikiページの名前を変更後に誰かが以前のページにアクセスしようとすると自動的に新しいページにリダイレクトされ、既存のすべてのリンクが確実に機能するようになりました。この改善によってページ名の変更管理のワークフローが合理化され、全体的なナレッジマネジメントの作業体験が向上します。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/wiki/) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/257892)\u003Cbr>\n\n### エピックの進行率の把握\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\n子アイテムのウェイトの完了度合いから、エピック全体の進行状況を簡単に確認できるようになりました。階層ウィジェットに新しく追加された進行状況のロールアップにより、エピックの全作業範囲を簡単に把握し、進行状況を確認しながら作業を進められます。\u003Cbr>\n\nドキュメント\u003Ca href=\"https://https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#view-epic-progress\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">Embedded content: https://https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#view-epic-progress\u003C/a> \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/5163)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/weight_and_progress_information_in_epic.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### コードレビューメールでの差分プレビューの無効化\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nマージリクエストでコードをレビューしてその行にコメントした場合、GitLabではその差分の数行を参加者への通知メールに含めるよう設定されています。一部の組織のポリシーではメールが安全性の低いシステムとして扱われていたり、メール用の独自のインフラストラクチャが管理されていない場合があり、IPやソースコードのアクセス制御にリスクが発生するおそれがあります。\u003Cbr>\n\nグループとプロジェクトに新しい設定が追加され、組織はマージリクエストメールから差分プレビューを削除できるようになりました。これにより、機密情報がGitLab以外に流出しないよう保護することができます。\u003Cbr>\nこの場を借りて、コミュニティにコントリビュートしてくれた[Joe Snyder](https://gitlab.com/joe-snyder)さんに感謝します！\n\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/manage#disable-diff-previews-in-email-notifications) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/24733)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/create-restrict-diffs-email.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### GitLab Runner 17.1がリリース\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLab Runner 17.1がリリースされます！ GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、軽量で拡張性の高いエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\u003Cbr>\n新機能：\u003Cbr>\n\n- GCP Compute Engine用GitLab Runnerフリートプラグイン\u003Cbr>\n\nバグの修正：\u003Cbr>\n- Runnerヘルパーイメージのエントリポイントの欠如\u003Cbr>\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/17-1-stable/CHANGELOG.md)で確認できます。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/runner) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/36942)\u003Cbr>\n\n### コンテナレジストリタグの公開日順でソート\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: -\u003Cbr>\n\nソースコードやパイプラインと一緒にDockerイメージまたはOCIイメージを表示、プッシュ、プルするには、GitLabコンテナレジストリを使用しますが、多くの場合、コンテナイメージのビルド後に正しい状態かどうかを確認する必要があります。ユーザーの多くが、ユーザーインターフェースを使用して正しいコンテナイメージを見つけることを難しく感じています。\u003Cbr>\n\nそんな問題を解決するため、コンテナレジストリのタグリストを公開日順にソートできるようになりました。この機能を使用すると、新しく公開されたコンテナイメージをすばやく検索して検証できます。\u003Cbr>\n\nこの機能はGitLab.comでのみ一般提供されています。次世代型コンテナレジストリはベータ版のため、Self-Managedサポートもベータ版となります。詳細については[コンテナレジストリメタデータデータベースのドキュメント](https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html)を参照してください。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/packages/container_registry/#view-the-container-registry) \u003Cbr>[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/7856)\u003Cbr>\n\n### APIセキュリティテストアナライザーの更新\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nGitLab 17.1は、[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)セキュリティテスト用に次の構成変数を追加しました：\u003Cbr>\n1.  `APISEC_SUCCESS_STATUS_CODES` は、APIセキュリティテストのスキャンジョブがパスしたかを定義するHTTP成功ステータスコードのリストを、カンマ区切りで作成します。\n2.  `APISEC_TARGET_CHECK_DISABLED` は、スキャン開始前にターゲットAPIが利用可能になるまでの待機を無効にします。\n3.  `APISEC_TARGET_CHECK_STATUS_CODE` は、APIターゲットの可用性チェックで想定されるステータスコードを指定します。 指定されていない場合、500以外のステータスコードをスキャナーに使用できます。\u003Cbr>\n4.  \nこうした新しい変数によりカスタマイズ性や自由度が向上し、スキャンを確実に成功させられるようになります。\u003Cbr>\n\nDAST APIは、16.10でAPIセキュリティテストに名前が変更されました。今後、変数名のプレフィックスは `APISEC` となります。 以前のプレフィックスは `DAST_API` でした。 `DAST_API` がプレフィックスとなっている変数は、18.0（2025年5月）までサポートされます。設定が期待通りに動作するように、できるだけ早く変数名を更新するようにしてください。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/api_security_testing/configuration/variables.html) \u003Cbr>[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/14170)\u003Cbr>\n\n### ファジングアナライザーの更新\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nGitLab 17.1は、ファジング用に次の構成変数を追加しました：\u003Cbr>\n\n1.  `FUZZAPI_SUCCESS_STATUS_CODES` は、ファジングのジョブがパスしたかを定義するHTTP成功ステータスコードのリストをカンマ区切りで作成します。\n2.  `FUZZAPI_TARGET_CHECK_SKIP` は、スキャン開始前にターゲットAPIが利用可能になるまでの待機を無効にします。\n3.  `FUZZAPI_TARGET_CHECK_STATUS_CODE` は、APIターゲットの可用性チェックで想定されるステータスコードを指定します。指定されていない場合、500以外のステータスコードをスキャナーに使用できます。\u003Cbr>\n\nこうした新しい変数によりカスタマイズ性や自由度が向上し、スキャンを確実に実行させられるようになります。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/configuration/variables.html) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/442699)\u003Cbr>\n\n### マージリクエスト認証ポリシーのフェールオープン/クローズ（ポリシーエディター）\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\n前回の[イテレーション](https://gitlab.com/groups/gitlab-org/-/epics/10816)に基づいてポリシーエディター内に新しいオプションを導入し、ユーザーがセキュリティポリシーをフェールオープンまたはフェールクローズに切り替えられるようになりました。 この拡張機能では、ポリシーエディタービュー内でより設定が簡単にできるようYAMLサポートを拡張します。\u003Cbr>\n\n例えばフェールオープンで設定されたマージリクエストポリシーは、基準を評価するのに十分なエビデンスがない場合に、マージリクエストをマージできます。エビデンスの欠如の理由として、アナライザーがプロジェクトで有効になっていないか、アナライザーがポリシーの評価結果を生成できなかったことが考えられます。このアプローチでは、チームが適切なスキャンの実行と実施を確実にできるよう、ポリシーを段階的にロールアウトできます。\n\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#fallback_behavior) \u003Cbr>[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13227)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/fail-open.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### プロジェクトオーナーに有効期限間近のアクセストークン通知を送信\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nプロジェクトオーナーと、ダイレクトメンバーシップを持つメンテナーの両方に、プロジェクトアクセストークンの有効期限が近づくとメール通知が送信されるようになりました。以前、この通知が送信されていたのはプロジェクトのメンテナーのみでした。この更新により、多くのユーザーがトークンの有効期限が近づいていることを通知で知れるようになります。\u003Cbr>\n\nこの場を借りて、コントリビュートしてくれた[Jacob Henner](https://gitlab.com/arcesium-henner)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/security/token_overview.html#project-access-tokens) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/460818)\u003Cbr>\n\n### Omnibusの改善\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitlab 17.1には[Ubuntu Noble 24.04](https://docs.gitlab.com/ee/administration/package_information/supported_os.html)をサポートするパッケージが含まれています。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/omnibus/)\u003Cbr>\n\n### グループAPIを使用して `marked_for_deletion_on` の日付でグループをフィルタリング\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\nグループ[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)で `marked_for_deletion_on` 属性を使用して応答をフィルタリングできるようになりました。これを実行すると、特定の日付で削除するようマークされたグループが返されます。\u003Cbr>\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@imskr](https://gitlab.com/imskr)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/groups.html#list-groups) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/429315)\u003Cbr>\n\n### 表示レベル選択の改善\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n以前、グループやプロジェクトの一般的な設定で表示されるのは許可された表示レベルの項目のみでした。そのため、特定のオプションが利用できないユーザーを混乱させたり、情報が正しく表示されないなどの状況が発生していました。新しいビューではすべての表示レベルを確認でき、選択できない項目はグレーで表示されます。さらに、ポップオーバーで項目が利用できない理由の詳細情報を確認できます。表示レベルが利用できない理由として、管理者による制限やプロジェクトまたは親グループの表示レベルとの競合などがあります。\u003Cbr>\n\n今回の変更で、希望する表示レベル選択時の競合の問題が解決できることを願っています。この場を借りて、コミュニティにコントリビュートしてくれた[@gerardo-navarro](https://gitlab.com/gerardo-navarro)さんに感謝します！\n\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/public_access.html#change-group-visibility) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/455668)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/improved-visibility-selection.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n### グループとプロジェクト用の新しいGraphQL API引数 `markedForDeletionOn`\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\n新しいGraphQL API引数 `markedForDeletionOn` を使用し、特定の日付で削除するようマークされたグループまたはプロジェクトを一覧表示できるようになりました。\u003Cbr>\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@imskr](https://gitlab.com/imskr)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/index.html#querygroups) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/463809)\u003Cbr>\n### グループバッジとプロジェクトバッジ用の新しいプレースホルダー\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n4つの新しいプレースホルダーを使用し、バッジリンクと画像URLを作成できるようになりました。\u003Cbr>\n\n-  `%{project_namespace}` -プロジェクト名前空間の完全なパスを参照\n-  `%{group_name} ` - グループ名を参照\n-  `%{gitlab_server} ` - グループまたはプロジェクトのサーバー名を参照\n-  `%{gitlab_pages_domain} ` - グループまたはプロジェクトのドメイン名を参照\u003Cbr>\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@TamsilAmani](https://gitlab.com/TamsilAmani)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/badges.html#placeholders) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/22278)\u003Cbr>\n\n### 直接転送でインポートする際に、継承されたメンバーシップ構造を維持\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nこれまでは、直接転送での移行の場合は[継承されたメンバーシップ](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#:~:text=Until%20now%2C-,inherited%20memberships,-were%20not%20imported)を確実にインポートすることはできませんでした。そのため、プロジェクトの継承メンバーは直接メンバーとしてインポートされていました。\u003Cbr>\n\n今回のリリースで、GitLabはプロジェクトのメンバーシップを移行する前に、まずグループメンバーシップを移行するよう変更されました。これにより、ソースのGitLabインスタンスで継承されたメンバーシップが複製されます。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/import/#memberships) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/458834)\u003Cbr>\n### REST APIによるグループフックのテスト\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\nこれまで、REST APIでテストできるのはプロジェクトフックのみでした。今回のリリースでは、指定されたグループのテストフックをトリガーできるようになりました。\u003Cbr>\n\nこのエンドポイントには、グループフックごとに毎分最大3つのリクエストという特別なレート制限があります。管理者は `web_hook_test_api_endpoint_rate_limit` 機能フラグを無効にすることで、Self-Managed GitLabとGitLab Dedicatedでこの制限を無効化できます。\u003Cbr>\n\nこの場を借りて、[コミュニティにコントリビュート](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/150486)してくれた[Phawin](https://gitlab.com/lifez)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/groups.html#trigger-a-test-group-hook) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/455589)\u003Cbr>\n\n### REST APIを使用してカスタムWebhookヘッダーを設定\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLab 16.11では、[Webhookを作成または編集する際のカスタムヘッダーを追加する機能](https://about.gitlab.com/releases/2024/04/18/gitlab-16-11-released/#custom-webhook-headers)を導入しました。\u003Cbr>\n\n今回のリリースでは、GitLab REST APIを使用してカスタムWebhookヘッダーを設定できるようになりました。\u003Cbr>\n\nこの場を借りて、[コミュニティにコントリビュート](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/153768)してくれた[Niklas](https://gitlab.com/Taucher2003)さんに感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/projects.html#set-a-custom-header) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/455528)\u003Cbr>\n\n### リッチテキストエディターでドラッグ可能なメディア\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n以前は、リッチテキストエディターでメディアを移動するには、各アイテムを手動でコピー＆ペーストする必要がありました。そのため、イシュー、エピック、Wikiにメディアを含める際によく遅延が発生していました。GitLab 17.1では、リッチテキストエディターでメディアをドラッグ＆ドロップできるようになり、編集時の効率が大幅に向上しました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/rich_text_editor.html) \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/452233)\u003Cbr>\n\n### よりスムーズなワークフローを実現するリアルタイムのボード最新情報\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n[ボード](https://docs.gitlab.com/ee/user/project/issue_board.html)上のイシューを更新する際のエクスペリエンスがよりスムーズになります！サイドバーで行った変更はボードに即座に反映され、再度更新する必要はありません。 この即時反映機能によってワークフローが合理化され、リアルタイムで内容を確認しながら更新をすばやく行うことができます。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/issue_board.html) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/468187)\u003Cbr>\n### タスクの所要時間を追跡\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nこのリリースでは推定時間を設定し、クイックアクションやタスクのサイドバーのタイムトラッキングウィジェットでタスクに費やした時間を記録できるようになりました。 タスクに費やした時間は、タスクのタイムトラッキングレポートで確認できます。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/time_tracking.html) \u003Cbr>[イシュー](https://docs.gitlab.com/ee/user/project/time_tracking.html)\u003Cbr>\n\n### Pages UIの更新\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLab 17.1ではPagesユーザーインターフェイスが改善され、たとえば画面スペースをより効率的に使用することができるようになりました。今回のUIの改善は、Pagesを管理する際のユーザーエクスペリエンスと効率性の改善に焦点を当てたものです。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/pages/) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/153250)\u003Cbr>\n### ユーザー定義変数を上書きできるユーザー権限管理の強化\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nユーザー定義の変数を上書きできるユーザーをより適切に管理できるよう、 `ci_pipeline_variables_minimum_role` プロジェクト設定が導入されました。 この新設定では既存の [`restrict_user_defined_variables`](https://docs.gitlab.com/ee/ci/variables/#restrict-who-can-override-variables) 設定よりもさらに自由度が向上し、上書きの権限をどのユーザーにも許可しない、もしくはデベロッパー、メンテナ、オーナー以上のロールを持つユーザーのみに制限できるようになりました。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/variables/#restrict-who-can-override-variables-by-user-minimum-role) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/440338)\u003Cbr>\n### コンテナイメージの最終公開日を表示\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: -\u003Cbr>\n\nこれまでは、公開されたタイムスタンプがコンテナレジストリユーザーインターフェースで正しく表示されない状況がよく発生しており、コンテナイメージを見つけて検証する際にタイムスタンプ内の重要なデータを確認することができませんでした。\u003Cbr>\n\nGitLab 17.1では、正確な `last_published_at` タイムスタンプを含めるようUIが更新されました。タイムスタンプは、__デプロイ > コンテナレジストリ__ に移動してタグを選択すると表示されます。 最終公開日はページ上部に表示されます。\u003Cbr>\n\nこの機能はGitLab.comでのみ一般提供されています。Self-Managedサポートはベータ版であり、ベータ版[次世代コンテナレジストリ](https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html)を有効にしたインスタンスでのみ利用できます。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/packages/container_registry/#view-the-container-registry) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/290949)\u003Cbr>\n\n### リリースページにリリースRSSアイコンを表示する\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n新しいリリースが投稿されたときに通知でのお知らせを希望しますか？GitLabでは、リリースをお知らせするRSSフィードの提供を開始しました。プロジェクトのリリースページにあるRSSアイコンから、リリースフィードにサブスクライブできます。\u003Cbr>\n\nこの場を借りて、コントリビュートしてくれた[Martin Schurz](https://gitlab.com/schurzi)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/releases/#track-releases-with-an-rss-feed) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/30988)\u003Cbr>\n\n### レジストリのコンテナスキャン\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nGitLabのコンポジション解析が、レジストリのコンテナスキャンのサポートを開始しました。\u003Cbr>\n\nレジストリのコンテナのスキャンがプロジェクトで有効になっており、コンテナイメージがプロジェクトのコンテナレジストリにプッシュされている場合、GitLabはタグとスキャン制限を確認します。\u003Cbr>\n\nタグが `latest` でスキャン回数が制限（1日50回）に到達していない場合、GitLabはイメージ上で `container_scanning` ジョブを実行する新規パイプラインを作成します。 パイプラインはイメージをレジストリにプッシュしたユーザーに関連付けられます。\u003Cbr>\n\nスキャンジョブは、GitLabにアップロードされるCycloneDX SBOMを生成します。継続的な脆弱性スキャン機能が有効になり、SBOMで検出されたパッケージがスキャンされます。\n注：脆弱性スキャンは新しいアドバイザリが公開され、[パッケージメタデータが同期](https://docs.gitlab.com/ee/administration/settings/security_and_compliance.html)されている場合に実行されます。\u003Cbr>\n\n今回も新しくリリースされた機能に関するフィードバックをお寄せください。この[フィードバックイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/466117)にコメントすると、フィードバックを送信できます。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/container_scanning/) \u003Cbr>[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/2340)\u003Cbr>\n\n### 管理者がメールアドレスの一部分の入力でユーザー検索が可能に\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n管理者は、管理者エリアのユーザー概要ページからメールアドレスの一部を入力することでユーザーを検索できるようになりました。たとえば、特定のメールドメインでユーザーをフィルタリングすると、特定の機関に所属する全ユーザーを見つけることができます。権限のないユーザーが他のアカウントのメールアドレスを閲覧できないよう、この機能は管理者向けに制限されています。\u003Cbr>\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@zzaakiirr](https://gitlab.com/zzaakiirr)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/admin_area.html#administering-users) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/20381)\u003Cbr>\n\n### カスタムロールの新しい権限\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nGitLab 17.1では、次の新しい権限でカスタムロールを作成できるようになりました。\u003Cbr>\n\n- [マージリクエスト設定の管理](https://docs.gitlab.com/ee/user/custom_roles/abilities.html#code-review-workflow)\n- [インテグレーションの管理](https://docs.gitlab.com/ee/user/custom_roles/abilities.html#integrations)\n- [デプロイトークンの管理](https://docs.gitlab.com/ee/user/custom_roles/abilities.html#continuous-delivery)\n- [CRMコンタクトを読む](https://docs.gitlab.com/ee/user/custom_roles/abilities.html#team-planning)\u003Cbr>\n\nカスタムロールでは同等の権限を持つユーザーを作成し、オーナーロールを持つユーザーの数を減らすことができます。これによってグループで必要なロールに特化し、不必要な権限の昇格を防げます。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/custom_roles.html) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/391760)\u003Cbr>\n\n++++++++++++\n\n### メンバーAPIを使用してユーザー名でメンバーを追加\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nこれまでは、メンバーAPIを使用する場合、メンバーのグループとプロジェクトへの追加には必ずユーザーIDを使用する必要がありました。今回のリリースで、ユーザー名でメンバーを追加できるようになりました。\u003Cbr>\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@imskr](https://gitlab.com/imskr)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/members.html#add-a-member-to-a-group-or-project)\u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/28208)\u003Cbr>\n\n### プロジェクトAPIを使用して `marked_for_deletion_on` の日付でプロジェクトを絞り込む\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\nプロジェクトAPIで `marked_for_deletion_on` 属性を使用した応答の絞り込みができるようになりました。これを実行すると、特定の日付で削除するようマークされたプロジェクトが返されます。\u003Cbr>\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@imskr](https://gitlab.com/imskr)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/projects.html#list-all-projects) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/463939)\u003Cbr>\n\n### GraphQL APIを使用したユーザーがコントリビュートしたプロジェクトを一覧表示\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n新しいGraphQL APIフィールド `User.contributedProjects` を使用し、ユーザーがコントリビュートしたプロジェクトを一覧表示できるようになりました。\u003Cbr>\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@yasuk](https://gitlab.com/yasuk)さんに感謝します！\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/graphql/reference/index.html#usercontributedprojects) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/450191)\u003Cbr>\n\n### バッジの新しい `%{latest_tag}` のプレースホルダー\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n `%{latest_tag}` プレースホルダーを使用してバッジリンクと画像URLを作成できるようになりました。 このプレースホルダーは、リポジトリに対して公開された最新のタグを参照します。\u003Cbr>\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@TamsilAmani](https://gitlab.com/TamsilAmani)さんに感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/badges.html#placeholders) \u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/26420)\u003Cbr>\n\n### Exploreのソートとフィルター機能を更新\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nグループとプロジェクトのExploreページのソートとフィルター機能が更新され、フィルターバーが大きくなって読みやすくなりました。\u003Cbr>\n\nプロジェクトのExploreページでは __名前、作成日、更新日、スター__ などの標準化されたソートオプションを使用できるようになりました。また、ナビゲーション要素を使用すると昇順または降順で並べ替えることができます。 言語フィルターはフィルターメニューに移動しました。新しい __非アクティブ__ タブでは、より焦点を絞った検索ができるようアーカイブされたプロジェクトが表示されます。 さらに __ロール__ フィルターを使用すると  、オーナーとなっているプロジェクトを検索できます。\u003Cbr>\n\nグループのExploreページでは__名前、作成日、更新日__などの標準化されたソートオプションを使用できるようになりました。また、ナビゲーション要素を使用すると昇順または降順で並べ替えることができます。 \u003Cbr>\n\nこの変更についてのフィードバックは[イシュー438322](https://gitlab.com/gitlab-org/gitlab/-/issues/438322)で投稿できます。\n\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/working_with_projects.html#search-in-projects) \u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/434473)\u003Cbr>[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/434469)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/17_1/updated-explore-filtering.png\" class=\"embedly-card\" data-card-width=\"100%\" data-card-controls=\"0\">\n\n---\n## 実験的な機能\n\n### GitLab CLIでスタックされた差分の作成および管理\n\nスタックされた差分ワークフローでは、相互にビルドされた小規模な変更を作成し、最終的な機能を提供できます。以前は、スタックの変更はフィードバックに基づいてレビュー・更新されていましたが、このワークフローでは変更を継続してビルドすることで開発時間を短縮できます。\u003Cbr>\n\n[GitLab CLIの1.42.0リリース](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#:~:text=1.42.0%20release%20of%20the%20GitLab%20CLI)では、変更のスタックの作成・管理ができる新しい `stack` コマンドが導入されています。 スタックの作成後も、引き続き変更を加えたり、変更を同期したり、スタック内のさまざまな変更に移動したり、以前の変更を修正したりできます。\u003Cbr>\n\nスタックされた差分はGitLab CLIで完全に管理されるため、最新バージョンのCLIをインストール後すぐに使用を開始できます。新しい `stack` コマンドの動作を確認し、機能の仕組みについて詳しく見るにはこの[動画](https://www.youtube.com/watch?v=TOQOV8PWYic)をご覧ください。\u003Cbr>\n\nGitLab CLIを使用したスタックされた差分に関するフィードバックは、[イシュー7473](https://gitlab.com/gitlab-org/cli/-/issues/7473)で投稿できます。\n\n---\n## バグの修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用する全ての人にスムーズでシームレスな体験を届けることを約束します。\u003Cbr>\n\n以下のリンクをクリックして17.1のバグ修正、パフォーマンス向上、UI改善についてすべてご覧ください。\n- [バグの修正\n](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=type%3A%3Abug&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=16.11)\n- [パフォーマンスの改善](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=bug%3A%3Aperformance&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=16.11)\n- [UIの改善\n](https://nicolasdular.gitlab.io/gitlab-polish-gallery/?milestone=16.11)\n\n---\n\n## 非推奨事項\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabのドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受けるには、[破壊的な変更のRSSフィードをサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\u003Cbr>\n\n-  [OpenTofu CI/CDテンプレート](https://docs.gitlab.com/ee/update/deprecations.html#opentofu-cicd-template)\n-  [コンテナレジストリ通知の「threshold」が「maxretries」に置き換えられます](https://docs.gitlab.com/ee/update/deprecations.html#replace-threshold-with-maxretries-for-container-registry-notifications)\n\n---\n## 削除された機能と変更点 \n\n消去されたすべての機能の一覧は、[GitLabのドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。 今後の破壊的な変更について通知を受けるには、[破壊的な変更のRSSフィードをサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n---\n\n### 変更履歴\n変更内容をすべて表示するには、以下のページから変更履歴を確認してください。\n\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ワークフロー](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md)\n- [GitLab CLI](https://gitlab.com/gitlab-org/cli/-/releases)\n\n### インストール\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/install/)をご覧ください。\n### 更新\n[更新ページ](https://about.gitlab.com/update/)を確認してください。\n### ご不明な点がある場合\nご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、[GitLabフォーラム](https://forum.gitlab.com/)にアクセスし質問を投稿してください。\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\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/)\n",[721,701,763],{"slug":3105,"featured":92,"template":681},"gitlab-17-1-released","content:ja-jp:blog:gitlab-17-1-released.yml","Gitlab 17 1 Released","ja-jp/blog/gitlab-17-1-released.yml","ja-jp/blog/gitlab-17-1-released",{"_path":3111,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3112,"content":3117,"config":3123,"_id":3125,"_type":16,"title":3126,"_source":17,"_file":3127,"_stem":3128,"_extension":20},"/ja-jp/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way",{"title":3113,"description":3114,"ogTitle":3113,"ogDescription":3114,"noIndex":6,"ogImage":2311,"ogUrl":3115,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3115,"schema":3116},"モノレポ用のGitLab CI/CDパイプラインを簡単に構築する方法","単一のリポジトリで複数のアプリケーションをホストするモノレポ用に、GitLab CI/CDパイプラインを作成する方法についてご紹介します。","https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"モノレポ用のGitLab CI/CDパイプラインを簡単に構築する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Morris\"}],\n        \"datePublished\": \"2024-07-30\",\n      }",{"title":3113,"description":3114,"authors":3118,"heroImage":2311,"date":3120,"body":3121,"category":672,"tags":3122},[3119],"Sam Morris","2024-07-30","モノレポを使用すると、単一のリポジトリで複数のアプリケーションのコードをホストできます。GitLabでこれを実現しようとすると、プロジェクト内の各ディレクトリに異なるアプリケーションのソースコードを配置することになります。この方法だとコードの保存場所をバージョン管理できるものの、GitLabの[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプライン機能を最大限に活用するのは困難でした。しかしながら、新たな方法が登場しました！\n\n\n## モノレポにおけるCI/CDの理想的な実例\n\n\n通常、リポジトリには複数のアプリケーションのコードが格納されているため、複数のパイプライン設定が必要となります。たとえば、.NETアプリケーションとSpringアプリケーションがあるプロジェクトの場合、アプリケーションごとに異なるビルドジョブとテストジョブを実施している可能性があります。この場合、パイプラインを完全に切り離し、特定のアプリケーションのソースコードの変更が発生した場合のみ、各パイプラインを実行するのが理想的です。\n\n\nこのようなプロセスを技術的に実現するには、特定のディレクトリの変更に基づいて特定のYAMLファイルをインクルードする、プロジェクトレベルのパイプライン設定ファイル`.gitlab-ci.yml`を用意します。`.gitlab-ci.yml`パイプラインは、コードに加えられた変更に基づき、適切なパイプラインをトリガーするコントロールプレーンとして機能します。\n\n\n## 従来のアプローチ\n\n\nGitLab\n16.4より前のバージョンでは、プロジェクト内のディレクトリまたはファイルへの変更に基づいてYAMLファイルをインクルードすることはできませんでした。ただし、回避策を使えばこの機能を実現することは可能でした。\n\n\nこれからご紹介するモノレポプロジェクトの例では、異なるアプリケーション用に2つのディレクトリがあるとします。それぞれJavaアプリ用の`java`ディレクトリとPythonアプリ用の`python`ディレクトリがあります。それぞれのディレクトリには、各アプリをビルドするためのアプリケーション固有のYAMLファイルが含まれています。シンプルにプロジェクトのパイプラインファイルに両アプリケーションのパイプラインファイルをインクルードし、それらのファイルで直接ロジック処理を行います。\n\n\n`.gitlab-ci.yml`：\n\n\n```\n\nstages:\n  - build\n  - test\n  - deploy\n\ntop-level-job:\n  stage: build\n  script:\n    - echo \"Hello world...\"\n\ninclude:\n  - local: '/java/j.gitlab-ci.yml'\n  - local: '/python/py.gitlab-ci.yml'\n\n```\n\n\nアプリケーション固有の各パイプラインファイルで「.java-common」もしくは「.python-common」という名前の非表示ジョブを作成します。これらのジョブは対応するアプリのディレクトリに変更が加えられた場合にのみ実行されます。デフォルトでは[非表示ジョブ](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs)は実行されず、通常は特定のジョブ設定を再利用するために使用されます。各パイプラインは、非表示ジョブを拡張して変更がないか監視するファイルを定めたルールを継承してから、パイプラインジョブを開始します。\n\n\n`j.gitlab-ci.yml`：\n\n\n```\n\nstages:\n  - build\n  - test\n  - deploy\n\n.java-common:\n  rules:\n    - changes:\n      - '../java/*'\n\njava-build-job:\n  extends: .java-common\n  stage: build\n  script:\n    - echo \"Javaのビルド\"\n\njava-test-job:\n  extends: .java-common\n  stage: test\n  script:\n    - echo \"Javaのテスト\"\n\n```\n\n\n`py.gitlab-ci.yml`：\n\n\n```\n\nstages:\n  - build\n  - test\n  - deploy\n\n.python-common:\n  rules:\n    - changes:\n      - '../python/*'\n\npython-build-job:\n  extends: .python-common\n  stage: build\n  script:\n    - echo \"Pythonのビルド\"\n\npython-test-job:\n  extends: .python-common\n  stage: test\n  script:\n    - echo \"Pythonのテスト\"\n\n```\n\n\nこの方法にはいくつかのデメリットがあります。たとえば、確実にルールに準拠するために、YAMLファイル内の他のジョブ用にそれぞれジョブを拡張しなければならないため、多くの冗長なコードが発生し、ヒューマンエラーが起きやすくなります。さらに拡張されたジョブでは重複するキーは持てないため、各ジョブにおいて独自の`rules`ロジックを定義できません。定義しようとした場合、キーの競合が発生し、[キーの値はマージされません](https://docs.gitlab.com/ee/ci/yaml/index.html#extends)。\n\n\n結果として、`java/`が更新されると、j.gitlab-ci.ymlジョブを含むパイプラインが実行され、`python/`が更新されると、py.gitlab-ci.ymlジョブを含むパイプラインが実行されます。\n\n\n## 新たなアプローチ：パイプラインファイルを条件付きでインクルードする\n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6phvk8jioAo?si=y6ztZODvUtM-cHmZ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n\nGitLab\n16.4では、[パイプライン向けに`rules:changes`を含む`include`](https://docs.gitlab.com/ee/ci/yaml/includes.html#include-with-ruleschanges)が導入されました。それまでは`include`に`rules:if`を使用することはできたものの、`rules:changes`は使用できませんでした。これは非常に強力なアップデートです。これにより、プロジェクトのパイプライン設定で`include`キーワードを使用するだけで、モノレポのルールを定義できるようになりました。\n\n\n新たな`.gitlab-ci.yml`：\n\n\n```\n\nstages:\n  - build\n  - test\n\ntop-level-job:\n  stage: build\n  script:\n    - echo \"Hello world...\"\n\ninclude:\n  - local: '/java/j.gitlab-ci.yml'\n    rules:\n      - changes:\n        - 'java/*'\n  - local: '/python/py.gitlab-ci.yml'\n    rules:\n      - changes:\n        - 'python/*'\n\n```\n\n\nその後、各アプリケーションのYAMLファイルにおいて非表示ジョブを何度も拡張せずに済むため、アプリケーションコードのビルドとテストだけに集中できます。これによって、より柔軟にジョブを定義できるようになり、エンジニアによるコードの書き直し作業が軽減します。\n\n\n新たな`j.gitlab-ci.yml`：\n\n\n```\n\nstages:\n  - build\n  - test\n  - deploy\n\njava-build-job:\n  stage: build\n  script:\n    - echo \"Javaのビルド\"\n\njava-test-job:\n  stage: test\n  script:\n    - echo \"Javaのテスト\"\n\n```\n\n\n新たな`py.gitlab-ci.yml`：\n\n```\n\nstages:\n  - build\n  - test\n  - deploy\n\npython-build-job:\n  stage: build\n  script:\n    - echo \"Pythonのビルド\"\n\npython-test-job:\n  stage: test\n  script:\n    - echo \"Pythonのテスト\"\n\n```\n\n\n上記の設定により、JavaとPythonのディレクトリがそれぞれ変更された場合にのみ、JavaまたはPythonのジョブをインクルードするという同じタスクを実行できます。実装時に考慮すべき点は、[`changes`を使用すると、ジョブが予期せぬタイミングで実行される可能性がある](https://docs.gitlab.com/ee/ci/jobs/job_troubleshooting.html#jobs-or-pipelines-run-unexpectedly-when-using-changes)ということです。新しいブランチやタグをGitLabにプッシュすると、changesルールは必ず「true」と評価されるため、`rules:changes`の定義内容にかかわらず、ブランチへの最初のプッシュ時に、含まれるすべてのジョブが実行されます。こういった事態がなるべく起こらないようにするために、まずはフィーチャーブランチを作成してからマージリクエストを開いて開発を始めることをおすすめします。ブランチの作成時に最初にプッシュすることで、すべてのジョブが強制的に実行されるためです。\n\n\n総括すると、モノレポはGitLabおよびCI/CDと組み合わせて、戦略的に利用できる手法です。新たな`rules:changes`機能を含む`include`キーワードの登場により、GitLab\nCIにおいてモノレポを使う際に適用できる優れたベストプラクティスができました。モノレポの利用をお考えの場合は、ぜひGitlab\nUltimateの無料トライアルをご利用ください。\n\n\n## CI/CDに関するその他のリソース\n\n\n*\n[GitLabでモノレポを管理するためのヒント5選](https://about.gitlab.com/blog/tips-for-managing-monorepos-in-gitlab/)\n\n*\n[CI/CDについて素早く学ぶ方法](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/)\n",[110,676],{"slug":3124,"featured":6,"template":681},"building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way","content:ja-jp:blog:building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way.yml","Building A Gitlab Ci Cd Pipeline For A Monorepo The Easy Way","ja-jp/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way.yml","ja-jp/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way",{"_path":3130,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3131,"content":3137,"config":3142,"_id":3144,"_type":16,"title":3145,"_source":17,"_file":3146,"_stem":3147,"_extension":20},"/ja-jp/blog/whats-new-in-git-2-46-0",{"title":3132,"description":3133,"ogTitle":3132,"ogDescription":3133,"noIndex":6,"ogImage":3134,"ogUrl":3135,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3135,"schema":3136},"Git 2.46.0の新機能","ここでは、参照バックエンド移行ツールやトランザクションシンボリック参照の更新など、GitLabのGitチームやより広範なGitコミュニティがリリースにコントリビュートしたハイライトをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.46.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }",{"title":3132,"description":3133,"authors":3138,"heroImage":3134,"date":3139,"body":3140,"category":962,"tags":3141},[1205],"2024-07-29","Gitプロジェクトは最近[Gitバージョン2.46.0](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u)をリリースしました。GitLabのGitチームやより広範なGitコミュニティからのコントリビュートを含む、本リリースの主なハイライトをご覧ください。\n\n\n## 参照バックエンド移行ツール\n\n\n前回の[Git\n2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt?ref_type=heads)リリースでは、reftablesフォーマットが参照を保存するための新しいバックエンドとして導入されました。この新しい参照フォーマットは、参照数の増加に伴って大規模なリポジトリが直面する複数の課題を解決します。reftableバックエンドについての詳細は、前回の[Gitリリースに関するブログ記事](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)をお読みください。機能の紹介や、初心者向けガイドが掲載されているため、[reftablesの仕組みについて詳しく確認できます](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)。\n\n\nreftableバックエンドのオンディスクフォーマットは、既存のファイルバックエンドとは異なります。したがって、既存のリポジトリでreftableを使用するにはさまざまなフォーマット間の変換が必要となります。これを達成するため、参照バックエンド移行の実行時に利用可能な`migrate`サブコマンドを含む新しいgit-refs(1)コマンドが導入されました。以下は、このコマンドの使用方法の例です。\n\n\n```shell\n\n# reflogが含まれないようにするために、新規リポジトリを「bare」として初期化します。\n\n$ git init --bare .\n\n$ git commit --allow-empty -m \"init\"\n\n# リポジトリに、バックエンドのファイルへの参照を投入します。\n\n$ git branch foo\n\n$ git branch bar\n\n$ tree .git/refs\n\n.git/refs\n\n├── heads\n\n│   ├── bar\n\n│   ├── foo\n\n│   ├── main\n\n└── tags\n\n# reftableフォーマットへの参照移行を実行します。\n\n$ git refs migrate --ref-format=reftable\n\n# reftableバックエンドが使用されていることを確認します。\n\n$ tree .git/reftable\n\n.git/reftable\n\n├── 0x000000000001-0x000000000001-a3451eed.ref\n\n└── tables.list\n\n# リポジトリ設定をチェックして、`refstorage`フォーマットが変更されていることを確認します。\n\n$ cat config\n\n[core]\n        repositoryformatversion = 1\n        filemode = true\n        bare = true\n        ignorecase = true\n        precomposeunicode = true\n[extensions]\n        refstorage = reftable\n```\n\n\nリポジトリが移行されるとオンディスクフォーマットが変更され、reftableバックエンドを使用するようになります。リポジトリに対するGit操作は引き続き機能し、以前と同様にリモートでやり取りを行います。移行はリポジトリ内での参照の保存方法にのみ影響します。ファイル参照バックエンドに戻したい場合は、代わりに`--ref-format=files`を指定して同じコマンドで実行します。\n\n\n移行ツールには現在いくつか留意すべき制限があります。リポジトリ内のreflogは参照バックエンドのコンポーネントであり、フォーマット間の移行が必要となります。残念ながら、現時点ではツールを使用してファイルとreftablesバックエンド間でreflogを変換することはできません。また、worktreeが含まれるリポジトリには基本的に複数のrefストアがありますが、移行ツールはまだこのようなシナリオに対応していません。したがって、リポジトリにreflogまたはworktreeが含まれている場合、現時点では参照移行を行えません。こうした制限は、今後のバージョンでなくなる可能性があります。\n\n\nbare\nGitリポジトリにはreflogが含まれないため、移行は簡単です。標準的なnon-bareリポジトリを移行するには、まずreflogを削除する必要があります。そのため、reflogやworktreeのないリポジトリであれば、すべて移行できます。こうした制限はありますが、このツールを使うことで既存のリポジトリでreftablesバックエンドを活用し始められます。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## トランザクションシンボリック参照の更新\n\n\n[git-update-ref(1)](https://git-scm.com/docs/git-update-ref)コマンドは、Gitリポジトリ内で参照更新を実行します。こうした参照更新は、`git\nupdate-ref\n--stdin`を使用してupdate-ref命令をstdinに渡すことで、トランザクションで一括してアトミックに実行することもできます。こちらは実行方法の例です。\n\n\n```shell\n\n$ git init .\n\n$ git branch -m main\n\n$ git commit --allow-empty -m \"foo\" && git commit --allow-empty -m \"bar\"\n\n# 作成された2つのコミットのオブジェクトIDを取得します。\n\n$ git rev-parse main~ main\n\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n\n# トランザクションを開始し、update-ref命令を出し、コミットします。\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> start\n\n> create refs/heads/new-ref 3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n\n> update refs/heads/main 567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n\n> commit\n\n> EOF\n\n$ git for-each-ref\n\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e commit refs/heads/main\n\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631 commit refs/heads/my-ref\n\n```\n\n\nこの例では、トランザクションがコミットされると「bar」コミットを指す新しいブランチが作成され、メインブランチは以前の\n「foo」コミットを指すよう更新されます。トランザクションをコミットすると、指定された参照更新がアトミックに実行されます。個々の参照更新が失敗した場合、トランザクションは中止され、参照更新は実行されません。\n\n\nここで注目すべきは、こうしたトランザクションでシンボリック参照更新をサポートする命令がないことです。ユーザーが、同一のトランザクション内で他の参照とともにシンボリック参照をアトミックに更新したい場合でも、それに対応できるツールはありません。今回のリリースでは、この機能を提供するために`symref-create`、`symref-update`、`symref-delete`、`symref-verify`命令が導入されました。\n\n\n```shell\n\n# 次の操作で更新されるシンボリック参照を作成します。\n\n$ git symbolic-ref refs/heads/symref refs/heads/main\n\n# シンボリック参照自体が更新されるようにするには、--no-derefフラグが必要です。\n\n$ git update-ref --stdin --no-deref \u003C\u003CEOF\n\n> start\n\n> symref-create refs/heads/new-symref refs/heads/main\n\n> symref-update refs/heads/symref refs/heads/new-ref\n\n> commit\n\n> EOF\n\n$ git symbolic-ref refs/heads/symref\n\nrefs/heads/new-ref\n\n$ git symbolic-ref refs/heads/new-symref\n\nrefs/heads/main\n\n```\n\n\n上記の例ではトランザクション内で新しいシンボリック参照が作成され、別のシンボリック参照が更新されています。こうした新しいsymref命令を既存の命令と組み合わせて使用することで、あらゆる種類の参照更新を単一のトランザクションで実行できます。新しい命令に関する詳細はこちらの[ドキュメント](https://git-scm.com/docs/git-update-ref)をご覧ください。\n\n\nこのプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n\n## git-config(1)のUXの改善\n\n\ngit-config(1)コマンドを使用すると、リポジトリやグローバルオプションの表示や設定を行えます。設定を行う際に使用するモードは、フラグを使用して明示的に選択したり、コマンドに指定した引数の数に基づいて暗黙的に決定したりすることができます。例：\n\n\n```shell\n\n$ git config --list\n\n# ユーザー名の設定を明示的に取得\n\n$ git config --get user.name\n\n# ユーザー名の設定を暗黙的に取得\n\n$ git config user.name\n\n# ユーザー名の設定を明示的に行う\n\n$ git config --set user.name \"Sidney Jones\"\n\n# ユーザー名の設定を暗黙的に行う\n\n$ git config user.name \"Sidney Jones\"\n\n# 3つ目の引数を指定することも可能です。これは何の役に立つのでしょうか？\n\n$ git config \u003Cname> [\u003Cvalue> [\u003Cvalue-pattern>]]\n\n```\n\n\n全体的に[git-config(1)](https://git-scm.com/docs/git-config)のユーザーインターフェイスは、サブコマンドを使うのが一般的な、他のより現代的なGitコマンドの動作とは一致していません（例：`git\nremist`）。このリリースではconfigコマンドで使用するサブコマンドとして`list`、`get`、`set`、`unset`、`rename-section`、`remove-section`、`edit`が導入されましたが、以前の形式の構文も引き続き使用できます。今回の変更はconfigコマンドをよりUIに沿ったものにし、Git内の他のコマンドとの整合性を高めてユーザーエクスペリエンスを向上させることを目的としています。以下は新しいコマンドの使用例です。\n\n\n```shell\n\n$ git config list\n\n$ git config get user.name\n\n$ git config set user.name \"Sidney Jones\"\n\n```\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって主導されました。\n\n\n## パフォーマンスのリグレッションへの対応\n\n\n属性を使用するGit操作は、リポジトリのworktreeにある`.gitattributes`ファイルの読み取りに依存しています。bare\nGitリポジトリの場合は定義上worktreeが欠如しているため、問題となります。これを回避するためGitには`attr.tree`という設定があり、SourceTreeを指定して属性を参照できます。\n\n\nGitリリース2.43.0では、bareリポジトリのGit属性のソースとして`HEAD`のツリーをデフォルトで使用するようになりました。残念なことに、Gitの属性ファイルのスキャンによる負荷の増加は、パフォーマンスに深刻な影響を及ぼす結果となっています。これは`attr.tree`が設定されている場合、属性を検索するたびにSourceTreeを開いて関連する`.gitattributes`ファイルを確認する必要があるためです。リポジトリのSourceTreeが大きく深くなればなるほど、性能のリグレッションも顕著なものとなります。たとえば、linux.gitリポジトリで実行されるベンチマークでは、git-pack-objects(1)完了までに1.68倍の時間がかかっています。これにより、クローンやフェッチを実行する際に速度が低下するおそれがあります。\n\n\n```\n\n# Gitバージョン2.43.0では、デフォルトでattr.treeがHEADに完了済みとして設定されています。\n\nBenchmark 1: git -c attr.tree=HEAD pack-objects --all --stdout \u003C/dev/null\n>/dev/null\n  Time (mean ± σ):     133.807 s ±  4.866 s    [User: 129.034 s, System: 6.671 s]\n  Range (min … max):   128.447 s … 137.945 s    3 runs\n\n# 2.43.0より前のバージョンのGitでは、属性検索を無効にするためにattr.treeが空のツリーに設定されていました。\n\nBenchmark 2: git -c attr.tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904\npack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     79.442 s ±  0.822 s    [User: 77.500 s, System: 6.056 s]\n  Range (min … max):   78.583 s … 80.221 s    3 runs\n```\n\n\n影響を受けた重要なGitコマンドには、前述のように大規模または深いツリーのあるリポジトリで使用された場合の`clone`、`pull`、`fetch`、`diff`などがあります。そのため、パフォーマンスのリグレッションに対処するために、'attr.tree`設定は部分的に元に戻され、デフォルトで`HEAD`に設定されることはなくなりました。詳細についてはこちらのメール[スレッド](https://lore.kernel.org/git/CAKOHPAn1btewYTdLYWpW+fOaXMY+JQZsLCQxUSwoUqnnFN_ohA@mail.gmail.com/)をご覧ください。\n\n\n## ユニットテストの移行\n\n\nこれまでGitプロジェクトでのテストは、シェルスクリプトとして実装されたE2Eテストを通じて行われてきました。Gitプロジェクトでは比較的最近、Cで書かれたユニットテストフレームワークが導入されました。この新しいテストフレームワークにより、個々の関数呼び出しレベルで低レベルの実装の詳細をより詳しくテストする機会がもたらされたほか、既存のE2Eテストが補完されます。既存のE2Eテストにはユニットテストにより適しているものがあり、移行に適しています。\n\n\n本年度も、GitLabは[Google Summer of\nCode（GSoC）](https://summerofcode.withgoogle.com/)のGitプロジェクトに参加するコントリビューターのメンターを務めています。進行中のGSoCプロジェクトとより広範なGitコミュニティの貢献により、既存のテストの一部がリファクタリングされ、ユニットテストフレームワークに移行されつつあります。前回のリリースサイクルでは、Gitプロジェクトのテストを改善するという目標に向けて複数のコントリビュートがありました。上述のGSoCコントリビューターのプロジェクトの詳細については、[Chandra](https://chand-ra.github.io/)および[Ghanshyam](https://spectre10.github.io/posts/)のブログをご確認ください。\n\n\n## バンドルURIの修正\n\n\n通常、クライアントがリモートリポジトリからフェッチする場合、必要なすべてのオブジェクトはリモートサーバーによって計算されたパックファイルで送信されます。こうした計算の一部を回避するため、サーバーは、リモートサーバーとは別に保存され、クライアントが必要とする可能性のある参照とオブジェクトのセットを含む事前構築の「バンドル」のアドバタイズを選択できます。クライアントは、[bundle-uri](https://git-scm.com/docs/bundle-uri)と呼ばれるメカニズムを介して最初にこうしたバンドルを取得できます。\n\n\n[Xing\nXin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/)さんのコントリビュートにより、いくつかのバンドルをダウンロードしたにもかかわらず、Gitがバンドルがないかのようにリモートからすべてをダウンロードし続けるという問題が特定・修正されました。これは、Gitがダウンロードしたすべてのバンドルを正しく検出できなかったために、リモートから連続したバンドルを取得する必要があったことが理由でした。この問題が修正されたことで、bundle-uriメカニズムを使用するリモートは冗長な作業を実行する必要がなくなったため、パフォーマンスが向上します。\n\n\n## 補足情報\n\n\n今回の記事では、最新リリースでGitLabとGitコミュニティが行ったコントリビュートのほんの一部をご紹介しました。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u)ではさらに詳しい情報をご覧いただけます。また、[以前のGitリリースのブログ記事](https://about.gitlab.com/blog/tags/git/)をチェックしてGitLabチームメンバーによる過去の主なコントリビュートをご覧ください。\n",[966,825,270],{"slug":3143,"featured":92,"template":681},"whats-new-in-git-2-46-0","content:ja-jp:blog:whats-new-in-git-2-46-0.yml","Whats New In Git 2 46 0","ja-jp/blog/whats-new-in-git-2-46-0.yml","ja-jp/blog/whats-new-in-git-2-46-0",{"_path":3149,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3150,"content":3156,"config":3161,"_id":3163,"_type":16,"title":3164,"_source":17,"_file":3165,"_stem":3166,"_extension":20},"/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull",{"title":3151,"description":3152,"ogTitle":3151,"ogDescription":3152,"noIndex":6,"ogImage":3153,"ogUrl":3154,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3154,"schema":3155},"git fetchとgit pullのコマンド上での違いとは？","git pullは、git fetchと同時にgit mergeを実施するgitコマンドのことです。この記事では、それぞれの特徴と適した用途をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665856/Blog/Hero%20Images/AdobeStock_869074524.jpg","https://about.gitlab.com/blog/what-is-the-difference-between-git-fetch-and-git-pull","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"git fetchとgit pullのコマンド上での違いとは？\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-25\",\n      }",{"title":3151,"description":3152,"authors":3157,"heroImage":3153,"date":3158,"body":3159,"category":962,"tags":3160},[738],"2024-07-25","# \u003CH1> git fetchとgit pullの違いとは？\u003C/H1> \ngitコマンドは、[分散型バージョン管理システム](https://about.gitlab.com/ja-jp/solutions/source-code-management/)として非常に人気があり、リモートリポジトリとの同期が必須です。開発に携わるエンジニアは、プロジェクトのニーズに応じて、適切なコマンドを選択する必要があります。この記事では、git fetchとgit pullの基本とその相違点を説明し、それぞれの使用目的について詳しく解説していきます。\u003Cbr>\n\n## 目次\n\n1. git fetchとgit pullの基本\n2. git fetchとは\n3. git pullとは\n4. git fetchを使うべき場面とは\n5. git pullを使うべき場面とは\n6. git fetchとgit pullに関する FAQ\n\n## \u003CH2> git fetchとgit pullの基本 \u003C/H2>  \ngit fetch（git フェッチ）とgit pull（git プル）は、両方ともgitのコマンドであり、リモートリポジトリから更新情報を取得するために使用されます。\nでは、なにが異なるのでしょうか。git fetchは、リモートリポジトリの変更状況をローカルリポジトリにダウンロードしますが、現在の作業ディレクトリには変更を加えません。ローカルのブランチにマージされないため、作業中に中断を引き起こすことなく、リモートリポジトリの変更を確認できることが利点です。\n一方git pullとは、リモートリポジトリから最新の変更を取得するところまではgit fetchと同様ですが、さらに現在のブランチに自動的にmerge（マージ）するコマンドです。リモートリポジトリの変更が直接ローカルの作業ディレクトリにも反映される点が、git fetchとの違いです。\n\n## \u003CH2> git fetchとは \u003C/H2>  \ngit fetchコマンドは、リモートリポジトリから最新のコミット履歴を取得しますが、ローカルの作業ディレクトリには反映されません。リモートの変更を取得しても、ローカルのブランチには反映されません。\n主に、リモートリポジトリの最新の状態を取得し、それがローカルリポジトリに反映される前に、変更内容を確認したい場合に使用されます。\n取得した変更内容をローカルブランチに適用するには[git mergeやgit rebase](https://docs.gitlab.com/ee/user/project/merge_requests/methods/)を手動で実行する必要があります。\n\n## \u003CH2> git pullとは \u003C/H2>\ngit pullコマンドは、`git fetch`と`git merge`（または`git rebase`）の組み合わせを一つのコマンドで実行します。これにより、リモートリポジトリの変更を取得してローカルの現在のブランチに自動的に統合します。git fetchはリモートリポジトリの変更を取得してローカルに反映させないのに対し、git pullを実行すると、リモートからの変更がローカルブランチに自動的に統合します。\n\n`git pull`は、リモートの変更をローカルのブランチに迅速に反映させるのに適していますが、コンフリクトが発生する可能性があるため、特に複数人での作業時には注意が必要です。\n\n## \u003CH2> git fetchを使うべき場面とは \u003C/H2> \ngit fetchは、リモートリポジトリから最新の情報を取得するコマンドです。取得した情報はローカルのブランチには直接反映されることはありません。git pullを使うと、誤ったリモートブランチや問題のあるリモートブランチもすべてローカルブランチに反映されてしまいます。\n\nリモートおよびローカルの両方で同時に変更が加えられている場合や、開発初心者の方がいるチームでは、git fetchを使ってリモートブランチの内容を取得してからmergeまたはrebaseするのが安全です。\n\n## \u003CH2> git pullを使うべき場面とは \u003C/H2> \ngit pullはgit fetchと比較して、より多くのプロセスを実施してくれるコマンドです。git pullで、git fetchに加えて、git merge（マージ）またはgit Rebase（リベース）を実施することができます。このため、リモートリポジトリの変更をローカルのブランチに素早く反映したいときにおすすめです。\n\n## \u003CH2> git fetchとgit pullに関する FAQ\u003C/H2> \n### \u003CH3> git pullと git fetchはなにが違うの？\u003C/H3> \ngit pullは、git fetch + git mergeもしくはgit fetch + git rebaseを実施するコマンドです。git fetchがローカルリポジトリに影響を与えないのに対し、git pullはリモートリポジトリの変更をローカルリポジトリにも自動で同期します。\n\n### \u003CH3> git pullを使用する際の注意点は？\u003C/H3> \ngit pullを実行する際には、リモートとローカルの変更が競合することがあります。特にマージコンフリクトが発生しやすいので、コンフリクトが発生した場合には手動で解決する必要があります。また、git pull --rebaseを使うことで、リベースを行いながら最新の変更を取り込むこともできます。\n\n### \u003CH3> git fetchは何のために使うの？\u003C/H3> \ngit fetchは、リモートリポジトリの最新の状態を確認・取得するのに役立ちます。しかし、取得した変更はローカルのブランチに自動的に反映されず、ローカルとリモートのリポジトリを同期するために使用されます。\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[966,825],{"slug":3162,"featured":92,"template":681},"what-is-the-difference-between-git-fetch-and-git-pull","content:ja-jp:blog:what-is-the-difference-between-git-fetch-and-git-pull.yml","What Is The Difference Between Git Fetch And Git Pull","ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull.yml","ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull",{"_path":3168,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3169,"content":3175,"config":3181,"_id":3183,"_type":16,"title":3184,"_source":17,"_file":3185,"_stem":3186,"_extension":20},"/ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"title":3170,"description":3171,"ogTitle":3170,"ogDescription":3171,"noIndex":6,"ogImage":3172,"ogUrl":3173,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3173,"schema":3174},"柔軟な組織階層を構築するためのベストプラクティス","このページでは、GitLabで組織階層をモデル化する方法をご紹介します。アジャイルの原則を守りながら、明確なコミュニケーションライン、戦略的な連携などを持つ組織を構築する方法を学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098165/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098164666.png","https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"柔軟な組織階層を構築するためのベストプラクティス\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-22\",\n      }",{"title":3170,"description":3171,"authors":3176,"heroImage":3172,"date":3177,"body":3178,"category":1705,"tags":3179,"updatedDate":3180},[1702],"2024-07-22","GitLabサブスクリプションのメリットをフル活用するには、効果的な組織設定が欠かせません。このガイドでは、グループ、サブグループ、プロジェクト構造を設定することで、GitLabの使いやすさを向上させる方法をわかりやすく説明します。\n\n## グループ、サブグループ、プロジェクトの構造を理解する\n\nグループとプロジェクトは、組織階層をモデル化し、高度な権限管理と「チームの集合体」を活用した計画を可能にします。グループとサブグループは、戦略的な計画立案に利用され、その設定が下位階層のサブグループやプロジェクトに引き継がれるよう構成管理を行えます。\n\nこの他にも、バリューストリームをモデル化して、組織全体のプロジェクト管理やコラボレーションを強化することも可能です。\n\n- **プロジェクトレベル（チームレベル）**\n    - プロジェクトは、グループやサブグループに属しており、実際の作業はここで行われます。ここにはリポジトリがあり、プロジェクト固有の設定が管理できます。このレベルでは、日々の作業や詳しいプロジェクトの進捗を確認できます。\n    - 効果的にプロジェクトを設定することで、データを明確に整理し、報告や分析を正確に行うことができます。\n\n- **サブグループレベル（チームの集合体）**\n    - サブグループでは、より細かい権限管理が可能です。特定のチームやプロジェクトのニーズに合わせてカスタマイズできるため、組織全体で一貫したワークフローを実現できます。\n    - サブグループは、アジャイルにおける「チームの集合体」と同じように、関連するプロジェクトの集合体として機能します。\n    - このレベルは、共通の製品やサービスに取り組む複数のチームを管理する際に効果的です。これにより、複数のプロジェクト間で可視化と連携が容易になり、チーム間の同期が取れるようになるため、相互依存関係や目標の共有が可能になります。\n\n- **グループレベル（「チームの集合体」の集合体）**\n    - グループはGitLab内の組織の柱のようなもので、そこでは幅広い権限とアクセスを管理することができます。\n    - 最上位のレベルであるグループは、複数のサブグループが含まれます。アジャイルにおける『「チームの集合体」の集合体』のような、プロジェクト管理の戦略的な階層を表します。\n    - このレベルでは、包括的な目標と戦略を設定し、プロジェクトやサブグループにリソースを割り当てることで、組織の全体的なビジネス目標との整合性を確保します。\n\nGitLabを使って組織を構造化することで、選択したアジャイル手法を並行して実行でき、プロジェクト全体に自然にアジャイルの原則を適用できます。この構造により、明確なコミュニケーションライン、効率的なリソース管理、戦略的な連携が促進され、アジャイル手法特有の柔軟性や対応力が維持されます。\n\n> [GitLabアジャイルプランニング](https://about.gitlab.com/blog/categories/agile-planning/)に関するニュースやインサイトはこちらから。\n\n## GitLabの継承モデルを活用する\n\nGitLabの強力な機能のひとつに[継承モデル](https://docs.gitlab.com/ee/tutorials/scrum_events/index.html#understanding-the-inheritance-model-in-gitlab)があります。これは、上位階層で設定した権限、構成が自動的に下位階層にも適用されるようにするものです。また逆に、下位階層のデータを直感的に上位階層で利用することも可能です。継承モデルを使用すると、ポートフォリオ全体を上位のグループから可視化できます。さらに、個々のチームが作業を管理できるように、階層構造の下位に専用のスペースを確保します。\n\n例：\n- **上位グループでマイルストーンやラベルを作成**し、下位のすべてのサブグループやプロジェクトに自動的に適用することで、一貫性と組織の標準への準拠を促進します。\n- 下位レベルのプロジェクトやサブグループの**イシューやエピック**は、バリューストリーム階層の構造に沿って集約されるため、プログラム管理者やエグゼクティブ層が参照しやすくなります。\n- **グループレベルまたはトップレベルのサブグループ**でユーザー権限を管理することで、権限やアクセス制限を効率化できます。これにより、アクセス制御の管理が簡素化され、設定を繰り返すことなく、複数のプロジェクトにわたって適切な人が適切なアクセス権を持てるようになります。\n\nこうしたヒントを活用することで、管理上のオーバーヘッドを減らすことができるだけでなく、上位レベルでの変更が一貫して下位レベルに反映されるようになり、その結果、セキュリティとコンプライアンスの強化が実現できます。\n\n![組織階層図](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098179305.png)\n\n## GitLabセットアップのベストプラクティス\n\nGitLabの組織階層を設定する際には、組織のニーズに応じて以下のオプションをおすすめします。Self-managedユーザーの場合、「会社名」などのルートグループ階層を省略できます。Self-Managedはシングルテナントデプロイメントのためこのような追加の組織階層は必要ないからです。こういった柔軟性により、特定の組織構造や導入形態に合わせたGitLabのセットアップが実現できます。\n\n### オプション1：組織のサブグループレベルで権限とアクセスを付与する\n\nこのオプションは、複雑な権限構造や、多数のユーザー間で効率的にプロジェクトを共有する必要がある大規模な組織に最適です。\n\n#### 構造の例\n\n- 組織グループ\n    - 主に企業の提供システムとの統合を通じて、広範なアクセス権限を管理します。\n    - ユーザーはサブグループに追加され、これらのグループは、グループ全体を別の[グループ](https://docs.gitlab.com/ee/user/group/manage.html#share-a-group-with-another-group) や [プロジェクト](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html)と共有する基盤として機能します。これにより、直接ユーザーを管理する手間を最小限に抑えます。\n    - ユーザーグループを作成すると、GitLab内で[グループメンション](https://docs.gitlab.com/ee/user/discussions/index.html#mentions)が利用できるので、一度に多くのユーザーグループをメンションできます。\n\n- 開発グループ\n    - 最上位の開発グループレベルにおいて、エグゼクティブレベルとプログラムマネジメントレベルに対して、すべての開発プロジェクトにまたがる可視性を提供します。\n    - 製品機能レベルの開発は、複数のリポジトリにアクセスが必要なため、サブグループレベルで作成されます。\n    - プロジェクトは開発用のリポジトリを管理するために作成されます。これは各開発チームのアクセスに利用します。\n\n![サブグループレベルの組織図](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_1_aHR0cHM6_1750098179306.png)\n\n### オプション2：任意のレベルで権限とアクセスを付与する。\nこのオプションは、アクセス要件がそれほど複雑でない小規模な組織に最適です。ユーザーは、アクセスが必要な際に、部門グループ、サブグループ、またはプロジェクトに個別に追加されます。これにより、プロジェクト管理と運用の可視性を直接管理できます。\n\n#### 概要\n- 必要なアクセス権限に応じて、ユーザーを階層の最上位にあるグループまたは下位のサブグループやプロジェクトに追加できます。同じグループに属するメンバーを一度に追加するのではなく、各メンバーを個別に追加する必要があります。\n- 最上位の開発グループレベルにおいて、エグゼクティブレベルとプログラムマネジメントレベルに対して、すべての開発プロジェクトにまたがる可視性を提供します。\n- 製品機能レベルの開発は、複数のリポジトリにアクセスが必要なため、サブグループレベルで作成します。\n- プロジェクトは開発用のリポジトリを管理するために作成します。これは各開発チームのアクセスに利用します。\n\n![任意のレベルで付与される権限](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_2_aHR0cHM6_1750098179307.png)\n\n### その他の構成に関する考慮事項\n\n- マイルストーンとイテレーション\n    - 幅広い可視性を確保するため、またはグループ間でマイルストーンを共有する必要がある場合は、グループレベルのマイルストーンを作成します。  \n    - マイルストーンが1つのプロジェクトに固有の場合は、プロジェクトレベルでマイルストーンを作成します。 \n    - 複数のグループにまたがって作業しているチームの場合、親グループレベルでイテレーションを設定すると、追跡が統一され、効率よく作業を進めることができます。\n\n- データ管理\n    - GitLabのロードマップ、ボード、リストページを活用して、組織の設定を反映したデータを取り込みましょう。これにより、進捗状況を可視化し、組織のさまざまなレベルにわたって効果的に計画を立てることができます。\n    - GitLabでは、下位レベルで作成されたデータであっても、上位レベルのグループで利用できます。\n    - 複数のグループやプロジェクトにまたがるデータを確認する場合には上位レベルのビューを作成し、特定のグループやプロジェクトのデータに集中する場合には下位レベルのビューを作成します。\n\n- テンプレートの作成\n    - 上位レベルのテンプレートを作成して、後続のすべてのサブグループやプロジェクトに確実に適用できるようにします。これには、一般的なガイドラインやプロジェクト固有の要件を盛り込みます。\n    - テンプレートは、該当するグループ（[関連するドキュメント](https://docs.gitlab.com/ee/user/project/description_templates.html)）内の独自のリポジトリ内に作成します。\n\n- ラベル\n    - 上位レベルのラベルを作成し、後続のすべてのサブグループやプロジェクトに確実に適用できるようにします。これには、組織ラベルとプロジェクト固有のラベルが含まれます。\n    - スコープ付きラベルを使用して、チームやワークフローのステータスなどの組織構造を定義します。\n\n![ラベル付きイシューボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098179310.png)\n\n## GitLabの機能を活用して成果を上げる\n\nGitLabで適切な構造を実装することは、ソフトウェアプロジェクトの管理を合理化するだけでなく、組織のさまざまなレベルでの可視性を高め、トップマネジメントから一般社員まで、情報に基づいた意思決定を行うために必要な情報を確実に得ることができます。 \n\n> [GitLab Ultimateの無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)で、組織の階層構造のモデリングを始めませんか？\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[1389,678,904],"2024-12-27",{"slug":3182,"featured":6,"template":681},"best-practices-to-set-up-organizational-hierarchies-that-scale","content:ja-jp:blog:best-practices-to-set-up-organizational-hierarchies-that-scale.yml","Best Practices To Set Up Organizational Hierarchies That Scale","ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale.yml","ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"_path":3188,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3189,"content":3195,"config":3200,"_id":3202,"_type":16,"title":3203,"_source":17,"_file":3204,"_stem":3205,"_extension":20},"/ja-jp/blog/event-report-japan-it-week-spring-2",{"title":3190,"description":3191,"ogTitle":3190,"ogDescription":3191,"noIndex":6,"ogImage":3192,"ogUrl":3193,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3193,"schema":3194},"DevSecOpsで人材問題は解決できるか: IT Week 2024 春イベントレポート【後編】","2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えするシリーズの「後編」です。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666515/Blog/Hero%20Images/_DSC1507.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-spring-2","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevSecOpsで人材問題は解決できるか: IT Week 2024 春イベントレポート【後編】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-18\",\n      }",{"title":3190,"description":3191,"authors":3196,"heroImage":3192,"date":3197,"body":3198,"category":740,"tags":3199},[738],"2024-07-18","*2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えするシリーズの「後編」です。前編では、DevSecOpsの最新状況とGitLabの価値について紹介しましたが、今回は人材がテーマ。一見GitLabのソリューションと遠いところにあるように感じられるかもしれませんが、実はGitLabを活用してDevSecOpsを推進すれば、人材育成や人材確保を進めることができるのです。*\n\u003Cbr>\n[前編を読む:DevOpsからDevSecOpsへ\n](https://about.gitlab.com/ja-jp/blog/event-report-japan-it-week-spring-1/)\n## 開発者たちに気分良く仕事をしてもらうために\n\nデジタル化が急速に進んだ近年、デジタル人材の確保が困難になっていると言われるようになってきました。実際に、『DX白書2023』では、2022年度においてDXを推進する人材の「質」を確保できている企業はわずか6.1％にすぎず、大幅な不足を感じている企業が過半に上ります。2021年度がそれぞれ10.7％、30.5％であったことからも、年々人材の確保が厳しくなっていることがわかります。\n\n一方、米国においては人材が充足されつつあるようです。グローバルエコノミーの時代、人材を海外に求めるという手段はあるかもしれませんが、為替リクスは大きな足かせになります。日本において、デジタル人材はあらゆる業界から引く手あまたで、人材側が企業を選べる状況と言えるでしょう。\n\n人材にとっては喜ばしいでしょうが、企業にとっては切実な悩みです。そこで、この状況を解決するための1つの手段として、「デベロッパー・エクスペリエンス」を高めることに注目してみてください。\n\n![DSC2630_ToshiIto](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/68A1C322-771B-4CA0-B996-73A58E7050BC_1_105_c.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト 伊藤 俊廷*\n\nデベロッパー・エクスペリエンスは、直訳すると開発者体験になります。最近あちこちで聞くカスタマー・エクスペリエンス＝顧客体験の開発者版と言えばわかりやすいでしょうか。これを向上させるカギは、デジタル人材たちに気分良く能力を発揮してもらう環境を整備すること。給与やオフィス環境、マシンスペックなどのハード面、文化とコミュニケーション、成長機会、低い認知負荷などのソフト面のどちらのアプローチも必要になります。\n\nただし、ハード面にはコストという制約があります。そこで、今回はソフト面においてデベロッパー・エクスペリエンスを向上させるという方向性について解説します。まずは、DevSecOpsと親和性の高いセキュリティ人材の体験向上から見ていきましょう。\n\n## DevSecOpsはセキュリティ人材の体験を高める\n\nデジタル人材の中でも、セキュリティ人材は最も確保が困難と言われる分野です。脅威は進化し続けている上に多様化し、常に最新の脅威について学び続ける必要もあります。[株式会社野村総合研究所](https://aslead.nri.co.jp/) プラットフォームサービス開発一部 宮原 俊介氏は、DevSecOpsによってセキュリティ人材の負担軽減と育成を期待できると考えています。\n\nDevSecOpsでは、シフトレフトの考え方を取り入れ、システム開発における設計、開発、テストというプロセスでもセキュリティ診断を実施します。これにより、単体テスト、統合テストといったアプリケーションの機能面のテストが完了してからセキュリティ診断をすることによる手戻りを抑制できます。\n\nそして、DevSecOpsというコンセプトが現実的になっているのは、それらのプロセスにおいて多様な自動化ツールが用意されている点にあります。従来型のやり方では、セキュリティ人材はセキュリティ診断と修正のレビューに忙殺されることになりますが、あらかじめセキュリティが担保されているアプリケーションに対して、最終チェックという形で専門的な診断を行う業務に注力できるようになるのです。\n\n![DSC1517_202404JapanITWeekImage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687918/Blog/Content%20Images/_DSC1517.jpg)\n\nDevSecOpsを実現するためには、3つの要素があると言われています。それらは、技術、プロセス、および文化です。ここで文化がクローズアップされていることに着目してください。DevSecOpsでは、開発、運用、セキュリティの各チームが協力してサービス価値の最大化を図ります。ゴールは共通しているため、チーム間で継続的に改善・学習する体制が出来上がっています。これは、セキュリティ人材のデベロッパー・エクスペリエンス向上につながる継続的な学習機会と、有意義なコミュニケーションの機会を提供することにつながります。\n\n## GitLabで作り上げる文化がデベロッパー・エクスペリエンスに好影響\n\nセキュリティ人材を中心に見てきましたが、DevSecOpsは、セキュリティ人材だけでなく、あらゆるデジタル人材のデベロッパー・エクスペリエンスの向上に役立ちます。GitLabは、市場にある中で唯一“DevSecOpsプラットフォーム”と呼べる統合的なソリューションです。では、GitLabを使うことで、デベロッパー・エクスペリエンスの向上にどのように役立つのでしょうか。\n\nまずは、文化とコミュニケーションいう側面から見ていきましょう。GitLabは、開発構想を含めたすべての情報を一元管理する開発者のためのSSOTとして機能します。過去をすべて可視化できるだけでなく、現在の状況もリアルタイムに反映されていきます。開発者は、GitLab内でコミュニケーションを取ることができ、だれが何をやっているのかを理解しながら、自分のやるべきことを進めることができます。\n\n履歴がすべて残るため、口頭による指示で、言った／言っていないと論争になることはありません。指示がコロコロ変わっても、責任の所在は明確になります。これは、指示の内容について開発者が納得できる説明が必要になることと同義ですから、自然に開発プロジェクトとビジネス側の関係も良くなっていくでしょう。\n\n![NYG2321_202404JapanITWeekimage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/_NYG2321.jpg)\n\n成長機会では、手前味噌になりますがGitLabというデファクト・スタンダードを実際に仕事で使う経験を得られることは大きなメリットです。開発者は、「GitLabを使える」という市場価値の高いスキルを得ることができます。一見、開発者側にとって魅力的でも企業側からは離職リスクを高めるポイントに見えるかもしれませんが、市場から人材を調達しやすく、経験はなくてもポテンシャルの高い人材に魅力を感じてもらえるプロジェクトを展開できるというメリットが勝るはずです。\n\n低い認知負荷についても解説しておきます。GitLabは、DevSecOpsプラットフォームであり、DevSecOpsを実現する機能を包括的に提供しています。そのため、ポイントソリューションである各種ツールの使い方を個別に学習する必要がありません。「何をやりたいか」という本質的な理解があれば、GitLab内ですべてを完結させることができるのです。これは、開発者が“ツールの専門家”にならず、プロジェクト全体を見渡す視野を得られるという点において重要な要素です。\n\nさらに、自動化を加速できることも大きな価値を生みます。リリースの際に、モニターをターミナルで一杯にしながらサーバごとにコマンドを打ち込んだり、手順書からコピー＆ペーストしたりする必要はありません。こうした「スキルアップにつながらないものの、時間を使ってやらなくてはならない作業」を最小化することは、デベロッパー・エクスペリエンスに良い影響を与えてくれます。\n\n## 開発者の提案に寄り添う姿勢を\n\n最後に、ビジネス側やプロジェクトリーダーの方々に向けて、開発者のやる気を引き出すコミュニケーションをどうすれば良いかについて触れておきます。\n\n優秀な開発者は最新のテクノロジーを活用したがるものです。これに制約をかけると、彼らのモチベーションは維持できません。新規で必要な機能があり、その開発を依頼するケースで、最新のテクノロジーを使用したいと提案された場合、コストやセキュリティリスクなどを列挙し、無下に却下するのではなく、寄り添う姿勢を見せてください。\n\n緊急を要する案件でない限り、プロジェクトでそのテクノロジーを使えばどのようなメリットがあるか、コストはどれくらいかかるか、リスクはどこにあるか、という検証をする価値は大きいのです。その上で提案を却下したとしても、開発者が納得のいく説明をできれば、彼らは高いモチベーションを維持し、常に最新のテクノロジーにアンテナを張って次の提案を持ってきてくれるでしょう。その中に、ビジネスの価値を大きく飛躍させる種が眠っているかもしれません。\n\n![NYG2316_202404JapanITWeekimage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/_NYG2316.jpg)\n",[280,1880,702,904],{"slug":3201,"featured":92,"template":681},"event-report-japan-it-week-spring-2","content:ja-jp:blog:event-report-japan-it-week-spring-2.yml","Event Report Japan It Week Spring 2","ja-jp/blog/event-report-japan-it-week-spring-2.yml","ja-jp/blog/event-report-japan-it-week-spring-2",{"_path":3207,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3208,"content":3214,"config":3219,"_id":3221,"_type":16,"title":3222,"_source":17,"_file":3223,"_stem":3224,"_extension":20},"/ja-jp/blog/gitlab-17-2-released",{"title":3209,"description":3210,"ogTitle":3209,"ogDescription":3210,"noIndex":6,"ogImage":3211,"ogUrl":3212,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3212,"schema":3213},"GitLab 17.2リリース","GitLab 17.2でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662130/Blog/Hero%20Images/17-2-cover.jpg","https://about.gitlab.com/blog/gitlab-17-2-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.2リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-18\",\n      }",{"title":3209,"description":3210,"authors":3215,"heroImage":3211,"date":3197,"body":3216,"category":701,"tags":3217,"updatedDate":3218},[738],"**GitLab 17.2のリリースで、ログストリーミング、新しいパイプライン実行セキュリティポリシー、脆弱性の説明機能の一般提供を開始**\n\nこのたび、GitLab 17.2のリリースを発表しました。このリリースでは、[脆弱性の説明機能の一般提供が開始され、さらにGitLab Duoと統合されることで](\\#bookmark=id.gjdgxs)、SASTの脆弱性を把握できるようになりました。また、[Kubernetesのログストリーミングのサポート](\\#bookmark=id.30j0zll)により、GitLab上でワークロードの問題を解決できるようになったほか、CI/CDジョブの実行を強制する新たな[タイプのパイプライン実行セキュリティポリシー](\\#bookmark=id.1fob9te)、リモート開発環境での生産性の向上に役立つ[GitLabワークスペースでのDuoチャットとコード提案のサポート](\\#bookmark=id.3znysh7)など、さまざまな機能が追加されました。これらの機能は、今回のリリースで追加された30を超える改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。  \n\nGitLab 17.2には、GitLabコミュニティのメンバーのみなさまから160件以上ものコントリビュートがありました。GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースはみなさまのご協力なしには実現できませんでした。ご協力いただき誠にありがとうございました！  \n\n来月のリリースに向けたプレビューは、[今後のリリースページ](about:blank)をご覧ください。17.3リリースのキックオフビデオもご視聴いただけます。  \n\n## **今月のMost Valuable Person（[MVP](about:blank)）は[Phawin Khongkhasawan](https://gitlab.com/lifez)さんが受賞**\n\n[誰もがGitLabコミュニティのコントリビューターをMVPに推薦できます](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/490)。積極的に活動している候補者を応援したり、他の誰かをノミネートしてみませんか。🙌  \n\n[Jitta社](https://www.jitta.com/)のテクニカルリードであるPhawin Khongkhasawanさんは、2024年2月からGitLabにコントリビュートしてくださっています。わずか数か月のうちに、Phawinさんは20件を超えるコントリビュートをマージしました。それらのコントリビュートは、リリース[16.11](https://about.gitlab.com/ja-jp/blog/gitlab-16-11-released/)、[17.0](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/\\#customize-avatars-for-users)、[17.1](https://about.gitlab.com/ja-jp/blog/gitlab-17-1-released/)に含まれています。  \n\nPhawinさんは、[API経由でのプロジェクトテストWebhookのトリガーを許可する](https://gitlab.com/gitlab-org/gitlab/-/issues/455589)リクエストなど、Webhook関連の機能を改善したことが評価され、GitLabのプロダクトマネージャーである[Magdalena Frankiewicz](https://gitlab.com/m\\_frankiewicz)に初めて推薦されました。GitLabのエンジニア[Marc Shaw](https://gitlab.com/marc\\_shaw)と[Jose Ivan Vargas](https://gitlab.com/jivanvl)、またGitLabのプロダクトマネージャー[Rutvik Shah](https://gitlab.com/rutshah)は、[GitLabのコアバリュー](https://handbook.gitlab.com/handbook/values/)であるコラボレーションとイテレーションに対するPhawinさんの忍耐強い取り組みに注目しました。  \n\nGitLabのスタッフバックエンドエンジニアである[Patrick Bajao](https://gitlab.com/patrickbajao)は、「”[Add order by merged\\_at](https://gitlab.com/gitlab-org/gitlab/-/merge\\_requests/147052)機能”を完成まで導いたPhawinさんの仕事ぶり、忍耐強さ、そして粘り強さには本当に感謝しています」と述べています。「マージされデプロイされるまでには、いくつかのマイルストーンを要しましたが、Phawinさんが手を止めることはなく、一緒に取り組んでくださいました」  \n\n新たに加わったコントリビューターでも、すぐに影響をもたらし、GitLabの共同開発に貢献できることを示してくださったPhawinさんに心から感謝申し上げます。\n\n## **GitLab 17.2でリリースされた主な改善点**\n\n### [**Kubernetesのポッドとコンテナのログストリーミング**](\\#bookmark=id.30j0zll)\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 16.1でKubernetesポッドのリストと詳細ビューを導入したものの、ワークロードを詳しく分析するには、引き続きサードパーティのツールを使用する必要がありました。本リリースでGitLabにポッドとコンテナのログストリーミングビューが追加されたため、直接アプリケーション配信ツール上で環境全体の問題をすばやく確認して、問題を解決できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/environments/kubernetes\\_dashboard.html)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13793)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/k8s-logs-view.png\">\n\n### **変更のリクエストによるマージリクエストのブロック**\n\nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\nレビューを行う際は、最後に`承認`、`コメント`、`変更のリクエスト`のいずれかを選択できます（[GitLab 16.9でリリース](https://about.gitlab.com/releases/2024/02/15/gitlab-16-9-released/\\#request-changes-on-merge-requests)）。レビューの最中に、解決されるまでマージリクエストを実行できないような変更が見つかる可能性があります。その場合、`変更のリクエスト`を行って、レビューを完了します。  \n\nこの度、変更がリクエストされると、そのリクエストが解決されるまでマージを防止するマージチェックがGitLabに追加されました。変更のリクエストを解決するには、最初に変更をリクエストしたユーザーがマージリクエストを再度レビューしてから、承認する必要があります。最初に変更をリクエストしたユーザーが承認できない場合、マージ権限を持つユーザーであれば誰でも変更リクエストを**バイパス**できるため、開発を続行できます。  \n\n[イシュー455339](https://gitlab.com/gitlab-org/gitlab/-/issues/455339)でこの新機能に関するフィードバックをぜひお寄せください。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/merge\\_requests/reviews/index.html\\#prevent-merge-when-you-request-changes)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/761)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11719) \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/create-block-mr-request-changes.png\">\n\n### **脆弱性の説明**\n\nSaaS: Ultimate、Duo Enterprise  \nSelf-Managed: Ultimate、Duo Enterprise\n\n脆弱性の説明がGitLab Duoチャットの一部として、一般提供されました。脆弱性の説明機能を使用すれば、SASTの脆弱性が見つかった場合に、チャットを開いて脆弱性についてより深く理解し、どのように悪用される可能性があるかを確認し、適用可能な修正方法を検討できます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/vulnerabilities/\\#explaining-a-vulnerability)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/10642)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/vulnerability_explanation_duo_chat.png\">\n\n### **OAuth 2.0デバイスの認証付与サポート**\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\n[OAuth 2.0デバイスの認証付与フロー](https://datatracker.ietf.org/doc/html/rfc8628)がGitLabでサポートされるようになりました。このフローを使用すれば、入力制限によりブラウザを使用できないデバイスからでも、GitLabのユーザー認証を安全に行えます。これにより、ヘッドレスサーバーやUIがない、またはUIが制限されている他のデバイスからGitLabサービスを利用する際に、デバイスの認証付与プロセスが最適です。この場を借りて、コントリビュートしてくれた[John Parent](https://kitware.com/)さんに感謝します！  \n\n[ドキュメント](https://docs.gitlab.com/ee/api/oauth2.html\\#device-authorization-grant-flow)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/332682)\n\n\u003Ciframe width=\"898\" height=\"505\" src=\"https://www.youtube.com/embed/jwocmqtKpJs\" title=\"GitLab OAuth2 Device Auth Demo\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### **パイプライン実行ポリシーのタイプ**\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nパイプライン実行ポリシーは、汎用的なCIジョブやスクリプト、命令の実行を強制できる新しいタイプのセキュリティポリシーです。\n\nセキュリティチームやコンプライアンスチームは、このパイプライン実行ポリシータイプを使用することで、カスタマイズした[GitLabセキュリティスキャンテンプレート](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs)や、[GitLabまたはパートナーがサポートするCIテンプレート](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates)、サードパーティのセキュリティスキャンテンプレートを適用できるほか、CIジョブ経由でカスタムレポートルール、またGitLab CI経由でカスタムスクリプトやルールを実施できます。\n\nパイプライン実行ポリシーには、「インジェクション」と「上書き」の2種類のモードがあります。*インジェクション*モードでは、プロジェクトのCI/CDパイプラインにジョブが挿入されます。*上書き*モードでは、プロジェクトのCI/CDパイプライン設定が置き換えられます。  \n\nその他すべてのGitLabポリシーと同様、ポリシーの作成・管理担当として指定されたセキュリティおよびコンプライアンスチームのメンバーが一元的に実施を管理できます。最初の[スキャン実行ポリシーを作成して、始め方を学びましょう！](https://docs.gitlab.com/ee/tutorials/scan\\_execution\\_policy/)！  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/policies/pipeline\\_execution\\_policies.html)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13266)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/pipeline-execution-policy-rp.png\">\n\n### **パイプラインのシークレット検出におけるカスタムルールセットのサポートの拡張**\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nパイプラインのシークレット検出におけるカスタムルールセットのサポートを拡張しました。  \nリモートルールセットを設定する際に、新しいタイプのパススルーとして `git` と `url` を使用できます。これにより、複数のプロジェクト間でルールセットの設定を共有するなど、ワークフローの管理を簡単に行えます。\n\nまた、これらの新しいタイプのパススルーを使用して、リモートルールセットでデフォルト設定を拡張することもできます。\n\nまた、アナライザーでは次の機能もサポートされるようになりました。\n\n* 最大20のパススルーを 単一の設定に連結し、事前定義されたルールを置き換える  \n* パススルーに環境変数を含める  \n* パススルーの読み込み時にタイムアウトを設定する  \n* ルールセット設定でTOML構文を検証する\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/secret\\_detection/pipeline/\\#custom-rulesets)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/336395)\u003Cbr>\n[マージリクエスト](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/merge\\_requests/310) \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/secrets-expanded-custom-rulesets-support.png\">\n\n### **ワークスペースでGitLab Duoチャットとコード提案が利用可能に**\n\nSaaS: Premium、Ultimate、Duo Pro、Duo Enterprise  \nSelf-Managed: Premium、Ultimate、Duo Pro、Duo Enterprise\n\nワークスペースで[GitLab Duoチャット](https://docs.gitlab.com/ee/user/gitlab\\_duo\\_chat/)と[コード提案](https://docs.gitlab.com/ee/user/project/repository/code\\_suggestions/)を利用できるようになりました！すぐに回答が必要な場合や、コードを効率的に改善したい場合に、生産性を向上させ、ワークフローを効率化するように設計されたDuoチャットとコード提案を使用すれば、これまで以上に効率的かつ効果的にワークスペースでのリモート開発を進められます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab\\_duo/)   \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/12780)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/workspaces_duo.png\">\n\n## **GitLab 17.2のその他の改善**\n\n### **削除されたブランチがJira開発パネルで消去**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nこれまでは[Jira Cloudアプリ向けGitLab](https://docs.gitlab.com/ee/integration/jira/connect-app.html)の使用時に、GitLabでブランチを削除した場合でも、Jira開発パネルにはそのブランチが表示されていました。また、削除したブランチを選択すると、GitLabで`404`エラーが発生していました。  \n\n本リリースから、GitLabでブランチを削除した場合、Jira開発パネルから消去されます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/integration/jira/development\\_panel.html\\#feature-availability)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/351625)\n\n### **UIにインポート済みのアイテムであることが表示**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabに、[他のSCMソリューション](https://docs.gitlab.com/ee/user/project/import/\\#supported-import-sources)からプロジェクトをインポートできます。ただし、プロジェクトアイテムがインポートされたものか、またはGitLabインスタンスで作成されたものかを判断するのは困難でした。  \n\n本リリースでは、作成者が特定のユーザーであることが明らかになっているGitHub、Gitea、Bitbucket Server、Bitbucket Cloudからインポートされたアイテムに表示インジケーターを追加しました。対象となるアイテムは、マージリクエスト、イシュー、メモなどです。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/import/\\#supported-import-sources)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13825)\n\n### **イシューイベントのWebhookにタイプ属性を追加**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nイシュー、タスク、インシデント、要求事項、目標、主要な成果はすべて、**イシューイベント**のWebhookカテゴリで、ペイロードをトリガーします。これまでは、イベントペイロード内でWebhookをトリガーしたオブジェクトのタイプをすばやく特定する方法がありませんでした。本リリースでは、**イシューイベント**、**コメント**、**非公開のイシューイベント**、**絵文字イベント**トリガー内のペイロードで利用可能な `object_attributes.type` 属性が導入されました。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/webhook\\_events.html\\#issue-events)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/467415)\n\n### **Wikiページのタイトルとパスフィールドを分離**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 17.2では、Wikiページのタイトルはパスと切り離されています。以前のリリースでは、ページタイトルが変更された場合、パスも変更され、ページへのリンクが破損してしまう可能性がありました。本リリースではWikiページのタイトルが変更されても、パスは変わりません。Wikiページのパスが変更された場合でも、自動リダイレクトが設定されるため、リンクが壊れることはありません。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/wiki/)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/30758)\n\n### **マージコミットメッセージ生成の一般提供を開始**\nSaaS: Ultimate、Duo Enterprise  \nSelf-Managed: Ultimate、Duo Enterprise\n\nコミットメッセージの作成は、コードベースのどの部分がどのような理由で変更されたのかを、その後他のユーザーが確実に把握できるようにするために不可欠です。変更した可能性のあるすべての内容を考慮した上で、変更点を効果的に伝えられるメッセージを作成するのは大変です。  \n\n本リリースでは、GitLab Duoによるマージコミットの生成の一般提供が開始され、すべてのマージリクエストで質の高いコミットメッセージを作成できるようになりました。マージする前に、マージウィジェットの「**コミットメッセージを編集**」選択し、「**コミットメッセージを生成**」オプションを使用してコミットメッセージのドラフトを生成します。  \n\nこの新しいGitLab Duo機能は、デベロッパーがプロジェクトのコミット履歴を貴重なリソースとしてその後活用できるようにする上で最適です。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab\\_duo/index.html\\#merge-commit-message-generation)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13661)\n\n### **Pure SSH転送プロトコルによるLFS**  \nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\n2021年9月に、[`git-lfs` 3.0.0](https://github.com/git-lfs/git-lfs/blob/main/CHANGELOG.md\\#300-24-sep-2021)がリリースされ、HTTPの代わりにSSHを転送プロトコルとして使用できるようになりました。それ以前のバージョンでは、転送プロトコルとしてHTTPのみがサポートされていました。そのため、一部のユーザーは、GitLabで `git-lfs` を使用できませんでした。本リリースでは、 `git-lfs` の転送プロトコルとして、HTTPの代わりにSSHを使用できるようになりました。  \n\nこの場を借りて、コントリビュートしてくれた[Kyle Edwards](https://gitlab.com/KyleFromKitware)さんと[Joe Snyder](https://gitlab.com/joe-snyder)さんに感謝します！  \n\n[ドキュメント](https://docs.gitlab.com/ee/administration/lfs/\\#pure-ssh-transfer-protocol)  \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11872)\n\n### **パイプラインスケジュールのソートオプション**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nパイプラインスケジュールリストを説明、参照、次回の実行、作成日、更新日の順でソートできるようになりました。  \n\n[ドキュメント](https://docs.gitlab.com/ee/ci/pipelines/schedules.html)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/37246)\n\n### **保護環境へのデプロイと承認がトリガーとなり、監査イベントを生成** \nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\nデプロイの承認など、デプロイイベントの記録にアクセスできるようにしておくことは、コンプライアンス管理を行う上で不可欠です。これまで、GitLabではデプロイ関連の監査イベントが提供されていなかったため、コンプライアンスマネージャーはカスタムツールを使用するか、GitLab上で該当するデータを直接検索する必要がありました。本リリースによりGitLabは、次の3種類の監査イベントの提供を開始しました。\n\n* `deployment_started` デプロイジョブを開始したユーザーと開始日時を記録  \n* `deployment_approved` デプロイジョブを承認したユーザーと承認日時を記録  \n* `deployment_rejected` デプロイジョブを却下したユーザーとその日時を記録\n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/audit\\_event\\_types.html\\#continuous-delivery)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/456687)\n\n### **APIセキュリティテストで署名付き認証リクエストをサポート**\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nAPIセキュリティには、スキャナーから送信されたリクエストを変更できる「上書き」機能がすでにサポートされていますが、事前に上書きを設定する必要があり、リクエストに応じて変更することはできません。GitLab 17.2では、「リクエストに基づくスクリプト」として`APISEC_PER_REQUEST_SCRIPT`が追加され、各リクエストを送信する前に呼び出されるC\\#スクリプトをユーザーが提供できるようになりました。これにより、認証の一環としてシークレットを使用したリクエストへの「署名」をサポートします。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/api\\_security\\_testing/configuration/variables.html)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/458825)\n\n### **DASTアナライザーの改善**\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\n17.2リリースのマイルストーンでは、以下の改善を行いました。\n\n1. 3種類のチェックを新たに追加しました。\n\n* チェック506.1は、Polyfill.io CDNの乗っ取りによって侵害された可能性の高いリクエストURLを特定するパッシブチェックです。  \n* チェック384.1は、有効なセッション識別子が悪意のある人物によって再利用される可能性をもたらすセッション固定の弱点を特定するパッシブチェックです。  \n* チェック16.11は、HTTPのTRACEデバッグメソッドが本番サーバーでいつ有効になっているかを特定するアクティブチェックです。有効になっている場合、誤って機密情報が公開される恐れがあります。\n\n2. 誤検出を減らすため、以下のバグ修正を行いました。\n\n* DASTチェック614.1（Secure属性なしの機密性の高いCookie）と1004.1（HttpOnly属性なしの機密性の高いCookie）では、サイトで以前に設定された有効期限によりCookieが消去された場合、検出結果が生成されなくなりました  \n* DASTチェック1336.1 （サーバーサイドテンプレートインジェクション）では、攻撃の成功を判定するために、HTTPレスポンスステータスコード「500」に依存しなくなりました\n\n3. 以下の機能強化を行いました。\n\n* DASTの脆弱性検出で、すべてのレスポンスヘッダーが証拠として提示されるようになりました。この追加情報の提供により、調査結果のトリアージに費やす時間が短縮されます  \n* Sitemap.xmlファイルをクロールして追加のURLを取得できるようになりました。これにより、ターゲットWebサイトのカバレッジが向上します\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/dast/browser/checks/)   \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/13411)\n\n### **Self-Managedでシークレットプッシュ保護が利用可能に。また、漏えいの可能性に関する警告を改善**\n\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\n17.2リリースのマイルストーンでは、以下の改善を行いました。\n\n* Self-Managedをご利用のお客様を対象に、シークレットプッシュ保護（ベータ）がご利用いただけるようになりました。管理者により[インスタンス全体で本機能が有効化](https://docs.gitlab.com/ee/user/application\\_security/secret\\_detection/secret\\_push\\_protection/\\#allow-the-use-of-secret-push-protection-in-your-gitlab-instance)されたら、ドキュメントを参照の上、プロジェクトで[プッシュ保護を有効](https://docs.gitlab.com/ee/user/application\\_security/secret\\_detection/secret\\_push\\_protection/\\#enable-secret-push-protection-in-a-project)にしてください  \n* [テキストコンテンツにおける漏えいの可能性に関する警告](https://docs.gitlab.com/ee/user/application\\_security/secret\\_detection/client/)の内容がより詳しくなりました。これにより、イシュー、エピック、MRのいずれかの説明やコメントにおいて、どのような種類の機密情報が漏えいしようとしているのかを理解しやすくなりました\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/secret\\_detection/)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/412229)  \u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13107) \n\n### **GitLabアナライザーごとに`latest`テンプレートを実行できるよう「スキャン実行ポリシー」を拡張**\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\n[スキャン実行ポリシー](https://docs.gitlab.com/ee/user/application\\_security/policies/scan-execution-policies.html)が拡張され、ポリシールールを定義する際に、`default` と `latest` のGitLabテンプレートのどちらかを選べるようになりました。`default` では現在の動作が反映されている一方、ポリシーを `latest` に更新することで、 指定されたセキュリティアナライザーの最新テンプレートでのみ利用可能な機能を使用できます。\n\n`latest` テンプレートの活用により、`latest` テンプレートで有効になっている他のルールと一緒に、マージリクエストパイプラインで確実にスキャンを実行できるようになりました。これまでは、ブランチパイプライン、または指定されたスケジュールに限定されていました。\n\n注：ポリシーを変更する前に、`default` と `latest` テンプレートの相違点をすべてチェックして、ニーズに合っているかどうかを確認してください！\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/policies/scan-execution-policies.html)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/415427)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/latest-template-image.png\">\n\n### **OAuth認証画面の改善**\n\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nOAuth認証画面で、許可する認証がより明確に説明されるようになりました。また、GitLabが提供するアプリケーションに関しては「erified by GitLab」セクションも表示されます。これまでは、GitLabによって提供されたアプリケーションであってもそうでない場合でも、ユーザーエクスペリエンスは同じでしたが、この新機能により、信頼性がさらに向上します。\n\n[ドキュメント](https://docs.gitlab.com/ee/integration/oauth\\_provider.html)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/462655)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/govern_oauth_improvements.png\">\n\n### **インスタンス管理者の設定プロセスを効率化**\nSaaS: \\-  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabの新規インストール時の管理者による設定プロセスが効率化され、より安全になりました。デフォルトの管理者用rootメールアドレスがランダムに設定されるようになったため、管理者はアクセス可能なメールアドレスに変更する必要があります。以前は、この手順を行うのが遅くなり、管理者がメールアドレスの変更を忘れてしまう恐れがありました。\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/458985)\n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/govern_admin_setup.png\">\n\n### ** `rules:changes:compare_to` でのCI/CD変数の使用をサポート**  \nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 15.3では、`rules:change`に[`compare_to`キーワード](https://docs.gitlab.com/ee/ci/yaml/\\#ruleschangescompare\\_to)を導入しました。これにより、比較対象として正確な参照先を定義できるようになりました。GitLab 17.2からは、このキーワードでCI/CD変数を使えるようになっため、より簡単に`compare_to`値を定義して、複数のジョブで再利用できます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/ci/yaml/\\#ruleschangescompare\\_to)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/369916)\n\n### **グループAPIを使用して、グループの招待先のグループを一覧表示できるように**  \nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nグループAPIに、グループが招待された他のグループを一覧表示するエンドポイントが追加されました。この機能は、[グループが招待されたプロジェクトを一覧表示するエンドポイント](https://docs.gitlab.com/ee/api/groups.html\\#list-a-groups-shared-projects)を補完するもので、グループが追加されたすべてのグループとプロジェクトの概要を包括的に確認できるようになりました。このエンドポイントには、ユーザーあたり毎分60件のリクエストのレート制限が設定されています。\n\nこの場を借りて、コミュニティにコントリビュートしてくれた[@imskr](https://gitlab.com/imskr)さんに感謝します！  \n\n[ドキュメント](https://docs.gitlab.com/ee/api/groups.html\\#list-a-groups-shared-groups)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/424959)\n\n### **コマンドパレットを使用したプロジェクト設定の検索**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabでは、プロジェクト、グループ、インスタンス、そしてユーザー向けに多種多様な設定が用意されています。そのため、多くの場合、必要な設定を見つけるにはUIのさまざまなエリアをクリックする必要があり、時間がかかっていました。\n\n今回のリリースでは、コマンドパレットからプロジェクト設定を検索できるようになりました。プロジェクトを開き、「**検索または移動先...**」を選択し、「`>`」キーでコマンドモードに入り、設定セクション名（例：「**保護タグ**」）を入力してみてください。表示された結果をクリックすると、その設定に直接移動できます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/search/command\\_palette.html)  \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/448637) \n\n\u003Cimg src=\"https://about.gitlab.com/images/17_2/project_settings_search.png\">\n\n### **一度に1つのディスカッションのTo-Doアイテムが完了できるように**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLabのイシューでのディスカッションが活発になることがあります。GitLabは、ご自身に関連するコメントに対してTo-Doアイテムを表示することでやり取りを管理しやすくします。またイシューに対してアクションを起こすと、自動的にそのアイテムを完了します。\n\nこれまでは、イシュー内のスレッドでアクションを起こすと、複数の異なるスレッドで自分がメンションされていた場合であっても、すべてのTo-Doアイテムが完了として処理されていました。今回のリリースから、自分がアクションを起こしたスレッドのTo-Doアイテムのみが完了されるようになりました。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/todos.html)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/461111)  \n\n### **Wikiのサイドバーの改善**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 17.2では、Wikiでのサイドバーの表示方法にいくつかの機能拡張が追加されました。今回の機能拡張により、Wikiのサイドバーにすべてのページ（最大5,000ページ）と目次（TOC）が表示されるようになり、さらにページを迅速に探せるよう検索バーが追加されました。\n\nこれまではサイドバーに目次が表示されていなかったため、ページのセクションへの移動が大変でした。新しい目次機能を使用すると、ページ構造がわかりやすくなるとともに、さまざまなセクションに迅速に移動できるため、使いやすさが大幅に向上します。\n\n検索バーが追加されることで、より簡単にコンテンツを見つけられるようになります。また、サイドバーにすべてのページが表示されるようになったため、Wiki全体をスムーズに閲覧できます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/wiki/)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/281570)  \n\n### **CLI用GitLab Duoの一般提供を開始**\nSaaS: Ultimate、Duo Enterprise  \nSelf-Managed: Ultimate、Duo Enterprise\n\n全ユーザーを対象に、CLI用のGitLab Duoの一般提供が開始されました。今後は、ニーズに合った `git` コマンドを見つける手助けをGitLab Duoに`依頼`できます。\n\n`glab duo ask \u003Cgit question>` を使うと、GitLab Duoが目的達成のためにフォーマットされた `git` コマンドを提供します。次にGitLab CLIが、渡されるフラグの情報など、コマンドやその実行内容に関する追加情報を提供します。その後、コマンドを実行して、ワークフローで直接出力結果を得られます。\n\nGitLab CLIの `ask` コマンドは、覚えづらい `git` コマンドを利用してワークフローを高速化する上で最適な方法です。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/gitlab\\_duo/index.html\\#gitlab-duo-for-the-cli)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/10402)  \n\n\u003Ciframe width=\"868\" height=\"489\" src=\"https://www.youtube.com/embed/1DG_xN1tg1U\" title=\"GitLab Duo for the CLI is now GA\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### **ワークスペース向けの新しいエージェント認証方法**\nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\nこのリリースでは、ワークスペース向けに新しい認証方法を導入しました。これにより、従来の認証方法における制限に対処し、グループのオーナーや管理者に対してより柔軟かつ詳細な管理の実現を可能にしました。新しい認証方法を使用すれば、グループのオーナーと管理者はワークスペースのホスティングに使用するクラスターエージェントを制御できます。\n\nスムーズに移行できるようにするために、ユーザーが従来の認証方法を利用している場合、自動的に新しい認証方法に変更されます。また、ワークスペースをサポートする既存のエージェントは、自動的にそのエージェントが存在するルートグループで許可されます。この移行は、エージェントがルートグループ内の異なるグループで許可されている場合でも行われます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/workspace/gitlab\\_agent\\_configuration.html)   \n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/14025)  \n\n### **GitLab Runner 17.2** \nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\n本日、GitLab Runner 17.2がリリースされます！GitLab Runnerは、CI/CDジョブを実行し、その結果をGitLabインスタンスに送信する、軽量で拡張性の高いエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。  \n\n**新機能：**\n\n* [AWS EC2インスタンス用GitLab Runnerフリートプラグイン（一般公開）](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29222)  \n* [Runnerの`livenessProbe`と`readinessProbe`設定の許可](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/545)  \n* [Kubernetes Executorの`umask 0000`コマンドの有効化と無効化機能](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28867)  \n* [GitLab Runnerオペレータ向けRed Hat OpenShift 4.16のサポート](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/203)\n\n**バグ修正：**\n\n* [Gitlab Runnerをアップグレードすると、すべてのキャッシュボリュームが削除される](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/30876)\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/17-2-stable/CHANGELOG.md)で確認できます。  \n\n[ドキュメント](https://docs.gitlab.com/runner)  \n\n### **Terraformモジュールレジストリのドキュメントモジュール**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nTerraformモジュールレジストリにReadmeファイルが表示されるようになりました！ご要望の多かったこの機能を使用すると、各モジュールの目的、構成、要件を透過的に文書化できます。  \nこれまでは、これらの重要な情報を他のソースから探す必要があったため、モジュールを適切に評価し使用することが困難でした。このリリースから、モジュールのドキュメントをすぐに確認できるようになり、モジュールの機能をすばやく理解できるようになりました。Readmeファイルを閲覧できるようになったことで、組織全体でTerraformコードを安心して共有し、再利用できます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/packages/terraform\\_module\\_registry/index.html\\#view-terraform-modules)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/451054)  \n\n\u003Ciframe width=\"868\" height=\"489\" src=\"https://www.youtube.com/embed/SWRwW4pS7Gk\" title=\"Package speed-run: View Terraform module documentation\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### **APIファジングテストで署名付き認証リクエストをサポート**\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\nAPIファジングには、スキャナーから送信されたリクエストを変更できる「上書き」機能がすでにサポートされていますが、事前に上書きを設定する必要があり、リクエスト自体に応じて変更することはできません。GitLab 17.2では、「リクエストに基づくスクリプト」として `FUZZAPI_PER_REQUEST_SCRIPT` が追加され、各リクエストを送信する前に呼び出されるC\\#スクリプトをユーザーが提供できるようになりました。これにより、認証の一環としてシークレットを使用したリクエストへの「署名」をサポートします。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/api\\_fuzzing/configuration/variables.html)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/458825)  \n\n### **コンテナスキャン：継続的な脆弱性スキャンの対象OSの拡張**\nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\n17.2では、コンテナスキャンMVCの継続的な脆弱性スキャンを強化するために、APKとRPMオペレーティングシステムのパッケージバージョンのサポートを追加しました。\n\nこの機能強化により、[APK](https://gitlab.com/gitlab-org/gitlab/-/issues/428703)と[RPM](https://gitlab.com/gitlab-org/gitlab/-/issues/428941)オペレーティングシステムのPURLタイプのパッケージバージョンを比較することで、コンテナスキャンの継続的な脆弱性警告を完全にサポートできるようになりました。  \n\nなお、キャレット（`^`）が含まれるRPMバージョンはサポートされていません。キャレットを含むバージョンのサポートに関する作業は、[こちらのイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/459969)で追跡されています。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/continuous\\_vulnerability\\_scanning/\\#supported-package-types)\u003Cbr>\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/10174)  \n\n### **Go、Java、Pythonで高度なSAST（ベータ）が利用可能に** \nSaaS: Ultimate  \nSelf-Managed: Ultimate\n\n高度なSASTが[ベータ機能として](https://docs.gitlab.com/ee/policy/experiment-beta-support.html\\#beta)、Ultimateをお使いのお客様にご利用いただけるようになりました。高度なSASTは、ファイルや機能をまたがる分析により、より品の高い結果を提供します。現在、Go、Java、Pythonをサポートしています。 \n\nベータフェーズでは、既存のSASTアナライザーを置き換えずに、テストプロジェクトで高度なSASTを実行することをお勧めします。高度なSASTを有効にするには、こちらの[手順](https://docs.gitlab.com/ee/user/application\\_security/sast/gitlab\\_advanced\\_sast/\\#enabling-the-analyzer)を参照してください。GitLab 17.2から、高度なSASTは[`SAST.latest` CI/CDテンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.latest.gitlab-ci.yml)に含まれています。\n\nこれは、[Oxeyeテクノロジーの統合](https://about.gitlab.com/blog/oxeye-joins-gitlab-to-advance-application-security-capabilities/)プロセスの一環です。今後のリリースでは、高度なSASTを一般公開し、[他の言語](https://gitlab.com/groups/gitlab-org/-/epics/14312)をサポートし、脆弱性の流れを追跡できる新たなUI要素を導入する予定です。ぜひテストして、フィードバックを[イシュー466322](https://gitlab.com/gitlab-org/gitlab/-/issues/466322)にお寄せください。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/application\\_security/sast/gitlab\\_advanced\\_sast/)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/466322)  \n\n### **サブグループのコンプライアンスセンターでのフレームワークの割り当て** \nSaaS: Premium、Ultimate  \nSelf-Managed: Premium、Ultimate\n\nコンプライアンスセンターは、コンプライアンスチームがコンプライアンス基準の遵守状況や違反についての報告、グループのコンプライアンスフレームワークの管理などを一括して行える場所です。\n\nこれまではコンプライアンスセンターの関連機能はすべて、トップレベルグループでのみ利用できました。そのため、サブグループのオーナーは、トップレベルグループのコンプライアンスセンターで提供される機能を利用できませんでした。  \n\nこういった重要な課題を解決するために、サブグループへのコンプライアンスフレームワークの割り当てと割り当ての解除機能を追加しました。これにより、グループオーナーは、すでに利用可能なトップグループレベルのコンプライアンスセンターダッシュボードに加え、サブグループレベルでもコンプライアンス状況を可視化できるようになりました。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance\\_center/compliance\\_projects\\_report.html)   \n[エピック](https://gitlab.com/gitlab-org/gitlab/-/issues/469004)  \n\n### **複数のアクセストークンの有効期限の特定**\nSaaS: \\-  \nSelf-Managed: Free、Premium、Ultimate\n\n管理者は、複数のアクセストークンの有効期限を特定するスクリプトを実行できるようになりました。このスクリプトを[トークンのトラブルシューティングページ](https://docs.gitlab.com/ee/security/token\\_overview.html\\#troubleshooting)に記載されている他のスクリプトと組み合わせて使用することができます。トークンのローテーション準備がまだ整っていない場合、有効期限が間近に迫っているトークンを特定して、期限を延長できます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/security/token\\_overview.html\\#identify-dates-when-many-tokens-expire)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/467313)  \n\n### **Google Cloudインテグレーションの設定プロセスの簡素化**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: \\-\n\nGoogle Cloud IAMインテグレーションのワークロードアイデンティティフェデレーションを設定する際に、Google Cloud CLIコマンドをネイティブで利用できるようになりました。これまではガイド付き設定で、cURLコマンドでダウンロードしたスクリプトを使用していました。また、設定プロセスをよりわかりやすく説明するヘルプテキストが追加されました。これらの改善により、グループオーナーはGoogle Cloud IAMインテグレーションの設定をより迅速に行えるようになりました。  \n\n[ドキュメント](https://docs.gitlab.com/ee/tutorials/set\\_up\\_gitlab\\_google\\_integration/\\#secure-your-usage-with-google-cloud-identity-and-access-management-iam)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/454343)  \n\n### **SnowflakeデータコネクターへのユーザーAPIの追加**\nSaaS: \\-  \nSelf-Managed: Free、Premium、Ultimate\n\nGitLab 17.2では、[GitLabデータコネクター](https://app.snowflake.com/marketplace/listing/GZTYZXESENG/gitlab-gitlab-data-connector)で[ユーザーAPI](https://docs.gitlab.com/ee/api/users.html\\#list-users)が新たにサポートされました。このAPIは、Snowflake Marketplaceアプリで利用できます。ユーザーAPIを使用して、Self-ManagedのGitLab インスタンスからSnowflakeにユーザーデータをストリーミングできるようになりました。  \n\n[ドキュメント](https://docs.gitlab.com/ee/integration/snowflake.html)   \n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13004)  \n\n### **グループの概要のソートとフィルタリングの改善**\nSaaS: Free、Premium、Ultimate  \nSelf-Managed: Free、Premium、Ultimate\n\nグループの概要ページのソートとフィルタリング機能を更新しました。検索要素がページ全体に広がり、検索文字列が見やすくなりました。また、`名前`、`作成日`、`更新日`、`お気に入り`といった標準化されたソートオプションを使用できるようになりました。  \n\nこの変更についてのフィードバックは[イシュー438322](https://gitlab.com/gitlab-org/gitlab/-/issues/438322)で投稿できます。  \n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/\\#view-a-group)   \n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/437013)  \n\n## **バグ修正、パフォーマンスの改善、UIの改善**\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けすることに専心しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験を届けることを約束します。  \n\n以下のリンクをクリックして、17.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=17.2)  \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=17.2)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=17.2)\n\n## **非推奨事項**\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更RSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n## **削除された機能と破壊的な変更**\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更RSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n### **GitLab 17.2 へのアップグレードに関する重要な注意事項**\n\nGitLab 17.2から、Geoインストールは `gitlab-ctl set-geo-primary-node` コマンドを使ってプライマリサイトを定義した時にプライマリサイトのチェックサムプロセスを開始します。これまでは、セカンダリサイトが設定された後にチェックサム処理が開始されていました。つまり、`gitlab-ctl set-geo-primary-node` コマンドの実行後にプライマリサイトがデータのチェックサムを生成し始めるので、Geoのセットアップの少し早い段階でプライマリサイトのリソース使用量が増えることになります。\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ワークフロー](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md)   \n* [GitLab CLI](https://gitlab.com/gitlab-org/cli/-/releases)\n\n### インストール\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/install/)をご覧ください。\n\n### 更新\n[更新ページ](https://about.gitlab.com/update/)を確認してください。\n\n### ご不明な点がある場合\nご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、[GitLabフォーラム](https://forum.gitlab.com/)にアクセスし質問を投稿してください。\u003Cbr>\u003Cbr>\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\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/)\n",[721,763,701],"2024-08-30",{"slug":3220,"featured":92,"template":681},"gitlab-17-2-released","content:ja-jp:blog:gitlab-17-2-released.yml","Gitlab 17 2 Released","ja-jp/blog/gitlab-17-2-released.yml","ja-jp/blog/gitlab-17-2-released",{"_path":3226,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3227,"content":3233,"config":3238,"_id":3240,"_type":16,"title":3241,"_source":17,"_file":3242,"_stem":3243,"_extension":20},"/ja-jp/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"title":3228,"description":3229,"ogTitle":3228,"ogDescription":3229,"noIndex":6,"ogImage":3230,"ogUrl":3231,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3231,"schema":3232},"GitLabのアジャイル計画によって共同プロジェクト管理を推進する方法","プロジェクト管理においてGitLabを使用することでもたらされる変革は、単にツールを使用するということではなく、コラボレーションと継続的な改善の文化が育まれることです。その方法についてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097041/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2822%29_718ZuurL0op4weunB2fBlD_1750097040694.png","https://about.gitlab.com/blog/how-gitlab-agile-planning-improves-collaborative-project-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabのアジャイル計画によって共同プロジェクト管理を推進する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-16\",\n      }",{"title":3228,"description":3229,"authors":3234,"heroImage":3230,"date":3235,"body":3236,"category":1705,"tags":3237,"updatedDate":2843},[1702],"2024-07-16","効果的なコラボレーションはアジャイルプロジェクト管理の土台であり、企業においてチームが高品質なソフトウェアを効率的に提供することを可能にします。GitLabの包括的なプラットフォームは、コラボレーションを促進し、ワークフローを効率化します。また、[アジャイルの原則](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)をサポートしています。この記事では、GitLabを使用することで、チームがシームレスに協力し合い、プロジェクトの成果を向上させる方法についてご紹介します。\n\n## 共同プロジェクト管理によってエンタープライズアジャイルチームが得られる価値\n\n今日のダイナミックな開発環境においてアジャイルチームが成功を収めるには、共同プロジェクト管理方法を採用することが不可欠です。これがなぜ重要なのか、またGitLab Enterprise Agile Planningがどのように役立つかを以下に説明します。\n\n- **コミュニケーションの強化**：コラボレーションすることで、チームメンバー全員が円滑にコミュニケーションを取り、誤解を防ぎ、全員が共通の目標に向け取り組むことができます。これは、迅速なイテレーションと継続的なフィードバックが鍵となるエンタープライズアジャイル環境では非常に重要です。\n- *GitLabでエピックを分解し、スレッド形式のコメントを使用することで、だれもが共通認識を持つことができ、イシュー内での綿密なディスカッションが促進されます。*\n- **効率性の向上**：連携しやすい雰囲気を作り出すことで、チームは各メンバーのユニークなスキルや専門知識を活用できるため、結果として問題解決やタスクの完了までにかかる時間が短縮されます。コラボレーションツールを使用すると、ワークフローの効率化やボトルネックの削減に加え、チームがより迅速に価値を提供できるようになります。\t\n  - *GitLabの統合プラットフォームは、計画からデプロイまで開発のあらゆる側面を統合し、合理的かつ効率的なワークフローを実現します。*\n\n- **より良い意思決定の実現**：チームメンバーが密接に連携することで、多様な視点やインサイトを共有できるため、より良い意思決定を下せます。コラボレーションをとおして、最高のアイデアが見いだされ、実践される「集合知の文化」が促進されます。\n- *GitLabのイシューボードとラベルは、アイデアの整理や優先順位付けを行う上で便利です。使用することで、選択肢の評価や情報に基づいた意思決定を行いやすくなります。*\n- **士気とエンゲージメントの向上**：コントリビュートに重きを置く共同作業環境で働くことで、チームの士気とエンゲージメントが大幅に向上します。効果的にコラボレーションを行うアジャイルチームでは、モチベーションや所有権の意識が高く、プロジェクトの成功により積極的に取り組む傾向があります。\n- *メンバーの実績を認め、お祝いするには、GitLabでチームメンバーによるコントリビュートやアクティビティフィードにリンクしましょう。*\n- **成果物の品質向上**：多くの場合、共同作業を行うことで、より質の高い成果物を得られます。継続的なフィードバックとピアレビューにより、問題を早期に発見して迅速に対処でき、結果としてより洗練された堅牢な製品を開発できます。\n- *GitLabのマイルストーントラッキングとプロジェクトテンプレートを使用すると、プロジェクト間で一貫した品質基準を達成でき、徹底したレビューと標準化を行えます。*\n- **適応性と柔軟性**：アジャイルチームは、フィードバックや変化する要件に基づいて素早くピボット（方向転換）できなければなりません。コラボレーションを行うことで、計画や戦略をリアルタイムで柔軟に調整できるため、チームが迅速に対応できるだけでなく、プロジェクト目標に沿って作業を進められるようになります。\n- *GitLabのロードマップと動的なスケジュール機能を使用すると、タイムラインと優先順位を適宜調整できるため、チームのアジャイル性が保たれ、変化にも迅速に対応できます。*\n\n私はプロダクトマネージャーという立場から、これらのメリットがチームのパフォーマンスにどのように変化をもたらすかを目の当たりにしてきました。アジャイルチームにおいて、これらの共同プロジェクト管理方法を取り入れることで、生産性が高まり、イノベーションが促進され、そしてプロジェクト全体の成果を向上できます。\n\n> [GitLabのアジャイル計画に関する最新情報とインサイトはこちら](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)から。\n\n## GitLabを使用してアジャイルを成功させる\n\n包括的なツールを提供するGitLabは、次のような共同作業を完璧にサポートします。\n\n- **アジャイル開発の効率化**：GitLabでは階層型プランニングがサポートされているため、チームはプロジェクトをエピックに作成して、それを機能やユーザーストーリー、タスクに分解できます。このようにわかりやすい構成により、複雑なプロジェクトでも管理しやすく、透明性が確保され、着実かつ継続的な価値の提供が促進されます。GitLabでは作業を詳細なセグメントに分割できるため、アジャイルチームは焦点を維持し、効率的に目標を達成しやすくなります。\n\n![エピックと子イシューのネストされたリスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097050298.png)\n\n- **可視性と責任の向上**：さまざまな部門が関わる取り組みでは、依存関係を管理することが重要です。依存関係を作成、トラッキング、視覚化するGitLabツールを使用すると、チームメンバーは大規模なプロジェクトにおいて、自分の作業がどの部分を担っているのかを明確に把握できます。このように視覚化することで、ボトルネックを防ぎ、プロジェクト目標に沿って作業を行えるため、より責任感を感じながら、足並みをそろえてプロジェクトを進められます。\n\n![取り組みの依存関係が表示されたスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097050300.png)\n\n- **すべてのユーザー向けの統合プラットフォーム**：GitLabは、すべてのステークホルダーを単一プラットフォームの下に統合し、さまざまなツールを使うことで生まれがちなサイロ化を解消します。これにより、チーム間のコミュニケーションとコラボレーションが強化されます。デベロッパー、プロジェクトマネージャー、QAスペシャリスト、UXデザイナーなど職種を問わず、GitLabでは誰もが同じデータやツールを利用できるため、より一貫性のある作業環境が実現されます。\n\n- **リアルタイムでのコラボレーションとコミュニケーション**：GitLabは、マージリクエスト、イシュートラッキング、継続的インテグレーション／継続的デプロイ（[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)）パイプラインなどの機能によって、リアルタイムのコラボレーションをサポートします。これらの機能は開発プロセスを効率化し、継続的なフィードバックの提供と反復的な改善を促進します。組み込みのチャット、マージリクエストへのコメント、リアルタイムの通知により、だれもが最新情報を入手し、足並みをそろえることができます。\n\n![製品、開発、デザインチーム間のチャットのやり取りが表示されたスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097050305.png)\n\n- **データドリブンの意思決定と継続的な改善**：GitLabで行われるすべてのアクションは測定可能であるため、戦略的プランニングと運用調整を行う上で役立つ貴重なインサイトを得られます。[GitLabの分析機能](https://about.gitlab.com/solutions/value-stream-management/)を使用すると、サイクルタイムやデプロイ頻度などの重要業績評価指標をモニタリングできます。このようなデータドリブンアプローチにより、推測ではなく証拠に基づいて意思決定を行うことができ、リーンの原則に沿って継続的な改善が促進されます。\n\n![バリューストリーム分析ダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097050308.png)\n\n## エンタープライズアジャイルプランニングの変革を始める\n\nGitLabがプロジェクト管理にもたらす変革はすばらしいものです。単にツールを使用するということではなく、コラボレーションと継続的な改善の文化が育まれます。担当するチームが協力し合うことなく、各自取り組みを行っていた状態から、一体となり、効率的でモチベーションの高いチームへと変化するのを目の当たりにできたときは、非常に報われた気持ちになりました。\n\nGitLabは、包括的な計画ツールとリアルタイムのコラボレーション機能を単一プラットフォームに統合することで、共同プロジェクト管理の定義を変えます。アジャイルのプラクティスとシームレスに連携し、チームがより効率的かつ正確にプロジェクトを管理できるようにします。GitLabは組織の規模を問わず、現代のソフトウェア開発の複雑さに対応するために必要なツールを提供することで、プロジェクトが成功し、納期を遵守できるようにします。\n\n> [GitLab Ultimateの無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)で、今すぐGitLab Enterprise Agile Planningをスタート！",[1389],{"slug":3239,"featured":92,"template":681},"how-gitlab-agile-planning-improves-collaborative-project-management","content:ja-jp:blog:how-gitlab-agile-planning-improves-collaborative-project-management.yml","How Gitlab Agile Planning Improves Collaborative Project Management","ja-jp/blog/how-gitlab-agile-planning-improves-collaborative-project-management.yml","ja-jp/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"_path":3245,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3246,"content":3252,"config":3259,"_id":3261,"_type":16,"title":3262,"_source":17,"_file":3263,"_stem":3264,"_extension":20},"/ja-jp/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"title":3247,"description":3248,"ogTitle":3247,"ogDescription":3248,"noIndex":6,"ogImage":3249,"ogUrl":3250,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3250,"schema":3251},"GitLab Duo開発の現場から：AIを活用したセキュリティ脆弱性の修正","このチュートリアルでは、GitLab Duoの脆弱性の説明と脆弱性の修正、その他のAI搭載機能が、脆弱性に迅速に対処するのにどのように役立つのかをご説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098106/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098106040.png","https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から：AIを活用したセキュリティ脆弱性の修正\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"},{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2024-07-15\",\n      }",{"title":3247,"description":3248,"authors":3253,"heroImage":3249,"date":3255,"body":3256,"category":787,"tags":3257,"updatedDate":3258},[2980,3254],"Alana Bellucci","2024-07-15","新しい仕事を始めたばかりの初日、大規模な本番環境でのインシデントが発生し、全員での対応が求められる状況に直面したとします。いくつもの重大な脆弱性が新たに発覚し、即時の対応、分析、軽減、そして修正が必要です。こうした場合、どこから調査を始めるべきでしょうか？\n\n\nこの記事では、GitLab\nDuoの脆弱性の説明や脆弱性の修正、その他のAI機能を活用し、たった数分以内に脆弱性への対応を開始する方法を解説していきます。実践的な例を通じて、AI搭載のアシスト機能を活用して効果的に脆弱性を分析し、説明するアプローチを習得しましょう。追加の修正として、AIが生成したコード修正がMR（マージリクエスト）に示され、脆弱性の修正を迅速化します。\n\n\n> [GitLab\nDuoの無料トライアル](https://about.gitlab.com/ja-jp/gitlab-duo/#free-trial)を始めて、脆弱性の修正機能を組織に取り入れてみませんか。\n\n\n## はじめ方：分析\n\n\n最初のステップは、脆弱性の影響と重大度を分析することです。GitLabのUIを開き、`セキュリティ > 脆弱性レポート`\nの順に進み、メニューから[Vulnerability\nReport（脆弱性レポート）](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)にアクセスします。脆弱性リストを\n`SAST` でフィルタリングし、対応を必要とする最も致命的な脆弱性を特定します。\n\n\n![脆弱性レポートの概要](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/vulnerability_reports_overview_aHR0cHM6_1750098116056.png)\n\n\nSASTのスキャン結果は詳細ビューで要約され、ソースコードへのリンクが表示されます。また、公開されているセキュリティアドバイザリからの詳細情報も提示されます。攻撃の範囲や技術的な詳細、脆弱な環境を十分に把握していない限り、デベロッパーがセキュリティレポートから分析を始めるのは難しい場合が多いでしょう。\n\n\n## 脆弱性の説明に基づく理解と軽減策\n\n\n脆弱性を理解し、最良かつ最も効率的な修正方法を知ることは不可欠です。また、修正により既存の機能に影響を与えないようにする必要があります。もし影響する場合は、保守担当者（メンテナー）やプロダクトオーナーとの議論が必要となり、その際には全体像を要約し、代替の軽減策を用意しなければなりません。また、離職した社員が作成したコードやテストを実施していないコードの場合、修正計画を立てるのがさらに難しくなることもあります。\n\n\nAI搭載の脆弱性の説明機能は、攻撃者がどのように脆弱性を悪用（エクスプロイト）できるかについて要約し、その影響や修正方法についての詳細な説明も行います。\n\n\n以下の例は、OSコマンドインジェクションの脆弱性を示しており、次のコードスニペットを使用しています。\n\n\n```php\n\n\u003C?php \n\n\n// Read variable name from GET request\n\n$name = $_GET['name'];\n\n\n// Use the variable name to call eval and print its value \n\neval('echo $' . $name . ';');\n\n```\n\n\n脆弱性レポートには詳細な説明がないため、全体の内容や影響について理解する必要があります。画面右上の `Explain\nVulnerability`（脆弱性の説明）オプションを選択すると、事前に定義されたプロンプトアクションでGitLab Duo\nChatが開きます。Chat内に脆弱性の追加の概要が表示され、脆弱性がどのように悪用されるかの説明や、推奨される修正方法が提示されます。\n\n\n![OSコマンドで使用される特殊文字の適切な無害化が行われていない（'OSコマンドインジェクション'）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750098116057.png)\n\n\n### 脆弱性の説明を文脈に沿った会話にする\n\n\n脆弱性の説明に関するUXの改善もされています。以前は、脆弱性の説明がオーバーレイとして右側に表示されていましたが、説明内容をGitLab Duo\nChatのワークフローに統合しました。脆弱性が複雑である場合は、それに対して複数の軽減ステップに分かれたり、ソースコードの経路が不明瞭になることもあります。\n\n\nソースコードツリーを参照しながら、同じChatの文脈でコードの説明、修正、リファクタリング、そしてテストを続けられます。\n\n\nC言語の例で全体的なワークフローに取り組んでみましょう。この例では、セキュリティスキャンによってバッファオーバーフローが検出されています。\n\n\n1. セキュリティの脆弱性の詳細ビューを開き、右上にある「Explain\nVulnerability」（脆弱性の説明）ボタンを選択します。Chatプロンプトが開き、問題の概要、潜在的な攻撃ベクター、および提案された修正が表示されます。\n\n\n![脆弱性のためのAI -\n画像4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750098116059.png)\n\n\n2. 提案された修正を確認し、続けて `Can you show an alternative fix using a different\nfunction` （日本語：別の関数を使った代替修正方法を見せてくれますか？）というプロンプトで、Chatに尋ねます。この目的は、`strcpy()`\nに代わるより安全な関数がないか調べることです。\n\n\n![脆弱性のためのAI -\n画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098116060.png)\n\n\n3. `strlcpy()`\nを使用した代替修正がChat内で提案されます（下図参照）。この関数は、ターゲット文字列に許容される文字数のみをコピーし、常に文字列をnullで終端します。また、ソース文字列の長さを返し、文字列が切り詰められたかどうかを判断します。\n\n\n![脆弱性のためのAI -\n画像5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750098116062.png)\n\n\n4. 次に、`Location file`\nURLをクリックし、ソースコードビューに移動します。再度Chatを開き、前の脆弱性の説明の文脈が保持されていることを確認します。次のステップでは、修正を続ける前にテストを追加していきます。これにより、機能の破損やリグレッションの発生を防ぐことができます。たとえば、`Based\non the vulnerability context and opened source code, how would you add tests\nfor it?` （日本語：脆弱性のコンテキストと表示されたソースコードに基づいて、テストを追加するにはどうしますか？）などのプロンプトを使用します。\n\n\n![脆弱性のためのAI -\n画像7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098116063.png)\n\n\n5. テストが生成され（仮に追加されたとして）、同じセッションで `Can you refactor the source code too?`\n（日本語：ソースコードもリファクタリングできますか？）というプロンプトを使用して、Chatにソースコードのリファクタリングも依頼できます。\n\n\n![脆弱性のためのAI -\n画像6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098116063.png)\n\n\nこのワークフローでは、脆弱性の分析、理解、軽減、代替アプローチの発見、テストの追加、さらには脆弱性の修正に対するリファクタリングを行う手順が示されています。\n\n\nChatを使ってこのプロセスを続けた後、Web\nIDEに切り替えて、学んだことを基にソースコードを修正できます。さらに、変更をコミットし、CI/CDやセキュリティスキャンをトリガーして、DevSecOpsライフサイクル全体のループを完結させる継続的なワークフローも含まれています。\n\n\n## AIアシストによる脆弱性の修正\n\n\nセキュリティ脆弱性を理解し、軽減するには、問題の修正を作成し、新しいマージリクエストでパイプラインを実行し、再度セキュリティスキャンを実施するなどのエンジニアリング作業が必要になります。また、修正をステージング（staging）環境にデプロイし、一定期間テストすることも必要な場合があります。\n\n\nAIを活用し、脆弱性とソースコードに基づいた提案修正を生成することで、脆弱性修正プロセスを迅速化します。\n\n\nヒント：これまでの経験の中で最も厄介だった脆弱性を思い出し、そのユースケースを再現してGitLab\nDuoの導入に活用してみましょう。ちなみに、[MITREのCWE Top\n25（最も危険なソフトウェアの脆弱性）](https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html)も、ユースケースとしてはよい例です。\n\n\n次の例は、[CWE-328：弱いハッシュ関数の使用](https://cwe.mitre.org/data/definitions/328.html)を実装したもので、`md5`\nを使用しています。これは[SASTスキャン](https://docs.gitlab.com/ee/user/application_security/sast/)によって正しく識別されます。\n\n\n```python\n\nimport hashlib\n\n\nclass User:\n    def __init__(self, username, password):\n        self.username = username\n        self.password = password\n\n    def set_password(self, password):\n        self.password = hashlib.md5(password.encode()).hexdigest()\n```\n\n\n![脆弱性のためのAI\n-画像8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750098116064.png)\n\n\n右上の `Resolve with merge\nrequest`（マージリクエストで解決）ボタンをクリックすると、AIを活用して修正を提案するMRが開きます。この脆弱性に対する修正として、別のハッシュ関数を使用することが考えられます。\n\n\n![脆弱性のためのAI -\n画像9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098116065.png)\n\n\nもうひとつの一般的な脆弱性の例として、関数のエラーコードや潜在的な例外をチェックしないケースがあります。以下のCコードスニペットは、`fopen()`\nや `chmod()`\nの呼び出しに対する[CWE-362](https://cwe.mitre.org/data/definitions/362.html)に関連するファイル操作におけるタイミング攻撃の例を実装しています。\n\n\n```c\n\n#include \u003Cstdio.h>\n\n#include \u003Cstring.h>\n\n#include \u003Csys/mman.h>\n\n#include \u003Csys/stat.h>\n\n#include \u003Cunistd.h>\n\n\nint main(int argc, char **argv) {##$_0A$####$_0A$##    // File\noperations##$_0A$##    char *fname = \"gitlab.keksi\";##$_0A$####$_0A$##   \nFILE *fp;##$_0A$##    fp = fopen(fname, \"r\");##$_0A$##    fprintf(fp, \"Hello\nfrom GitLab Duo Vulnerability Resolution Challenge\");##$_0A$##   \nfclose(fp);##$_0A$####$_0A$##    // Potential chmod() timing attacks   \n##$_0A$####$_0A$##    // Make the file world readable##$_0A$##   \nchmod(fname, S_IRWXU|S_IRWXG|S_IRWXO);##$_0A$####$_0A$##    return\n0;##$_0A$##}\n\n```\n\n\n`chmod()` に関するSASTレポートは、次のように表示される場合があります。\n\n\n![脆弱性のためのAI -\n画像10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098116065.png)\n\n\n提案された `chmod()`\nのマージリクエストにはエラーハンドリングが含まれており、ファイルが世界中で書き込み可能になる潜在的な問題も修正されて、権限が `777` から\n`600` に変更されています。\n\n\n![脆弱性のためのAI -\n画像11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098116066.png)\n\n\n> 次に`fopen()` 関数の脆弱性も特定し、分析した上で修正してみてください。\n\n ## GitLab DuoによるさらなるAI支援\n\nセキュリティ問題は、簡単な修正や回避策で解決できることがよくあり、それによって開発チームが長期的な解決策を議論し、計画する時間を確保できます。他のケースでは、問題がより複雑になり、適切な修正が本番環境に反映されるまで、機能[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)を無効にしたり、ファイアウォールでの軽減策が必要になることもあります。\n\n\nGitLab Duoは、こうした問題の解決に役立つAIを活用した追加機能を提供しています。\n\n\n**コードの説明**：デベロッパーやセキュリティエンジニアとして、行った変更に自信を持つことが重要です。IDE内で[コードの説明機能](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide)を使用することで、AIが提案した脆弱性修正をより深く理解できます。この機能により、どのような調整が行われたか、そしてその理由を正確に把握できます。\n\n\n**根本原因分析：**\n修正によりCI/CDパイプラインがエラーを起こしてしまった場合、[根本原因分析機能](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)を利用できます。このツールは、根本的な問題を特定し、説明するのに役立ち、効果的に問題に対処できます。必要な修正を加えた後、テストを再実行して問題が解決したか確認できます。\n\n\n**リファクタリング**：脆弱性の修正が済んでも、より安全なコードにできないか検討する価値があります。IDE内でGitLab Duo\nChatを開き、[リファクタリング機能](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide)を使用して、コードをより安全に書くための代替方法を探ることができます。この事前対策的なアプローチにより、堅牢でセキュアなコードベースを維持できます。\n\n\nこれらのGitLab Duoの機能を活用することで、脆弱性に自信を持って対処し、コードのセキュリティと効率を確保できます。\n\n\n## 今後の取り組み\n\n\n脆弱性の説明と修正の機能をMRのプロセスに直接組み込むことで、シフトレフト（より早い段階に移行）させることを計画しています。この統合により、開発サイクルの初期段階で脆弱性に対処し、解決できるようになり、ワークフローが効率化され、シフトレフトによりコードのセキュリティが強化された状態になります。\n\n\n## GitLab Duoを始める\n\n\nGitLab\nUltimateで利用可能な機能を有効化する方法を説明する[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo/turn_on_off.html)をご参照ください。また、GitLab\nDuoの[脆弱性の説明](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#explaining-a-vulnerability)および[脆弱性の修正](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution)は、GitLabのSelf-Managed環境やGitLab\nDedicatedでも利用可能です。\n\n\n[「GitLab\nDuo開発の現場から」ブログシリーズ](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-series/)をチェックすることで、GitLab\nDuoの最新情報についてご確認いただけます。\n\n\n*監修：伊藤 俊廷 [@toshitakaito](https://gitlab.com/toshitakaito) \u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト）*\n\n\n> [GitLab\nDuoの無料トライアル](https://about.gitlab.com/ja-jp/gitlab-duo/#free-trial)を始めて、脆弱性の修正機能を組織に取り入れてみませんか。\n",[721,722,701,678,676],"2025-01-21",{"slug":3260,"featured":92,"template":681},"developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","content:ja-jp:blog:developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","Developing Gitlab Duo Use Ai To Remediate Security Vulnerabilities","ja-jp/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","ja-jp/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"_path":3266,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3267,"content":3273,"config":3281,"_id":3283,"_type":16,"title":3284,"_source":17,"_file":3285,"_stem":3286,"_extension":20},"/ja-jp/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements",{"title":3268,"description":3269,"ogTitle":3268,"ogDescription":3269,"noIndex":6,"ogImage":3270,"ogUrl":3271,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3271,"schema":3272},"GitLab Duo開発の現場から：チャット機能強化について","新たなインテグレーション、迅速なキャンセル、アーキテクチャのアップグレードなど、GitLab Duo Chatの最新の改善点についてまとめました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098374/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098374059.png","https://about.gitlab.com/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から：チャット機能強化について\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jannik Lehmann\"},{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-07-10\",\n      }",{"title":3268,"description":3269,"authors":3274,"heroImage":3270,"date":3277,"body":3278,"category":787,"tags":3279,"updatedDate":3280},[3275,3276],"Jannik Lehmann","David O'Regan","2024-07-10","ユーザーの皆さまの常に変化し続けるニーズを満たすため、GitLabはAIアシスタントである[GitLab Duo Chatの継続的な改善](https://gitlab.com/gitlab-org/gitlab/-/issues/430124)に取り組んでいます。ワークフローを効率化し、生産性を向上させる最近の機能強化をいくつかご紹介します。\n\n> GitLab 17バーチャルリリースイベントではAI主導のソフトウェア開発の未来を探りました。[今すぐこのイベントの動画をご視聴ください](https://about.gitlab.com/ja-jp/seventeen/)！\n\n## 脆弱性の説明：新たなインテグレーション\n\nチャット機能は常に進化し続けていますが、今回[GitLab Duoの脆弱性の説明](https://about.gitlab.com/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/)という重要な機能が追加されました。これは[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)プラットフォームでAIグループ外のチームによってチャットに統合された最初の機能であり、まさにGitLabのコラボレーション精神と部門間の協力関係を象徴する取り組みです。\n\n### 今回のインテグレーションの主な特長\n\n- **迅速な実行：** 新しい技術の検証から実装までをわずか3週間で進め、チームはその敏捷性と実行力を実証しました。\n- **チーム間のコラボレーション：** 今回のインテグレーションはAIグループ外のチームが主導しており、今後さらに多様な機能の追加が期待されています。\n- **セキュリティインサイトの強化：** まもなく、ユーザーはチャットを活用してプロジェクトで検出された脆弱性をより深く理解できるようになります。\n\n今回のインテグレーションは、特にセキュリティの分野において、チャットをデベロッパーにとってさらに強力で汎用性の高いツールにするための重要な一歩です。\n\n## コンテキスト認識の強化\n\nチャットのコンテキスト認識を改善し、さまざまなシナリオでより高度な対応ができるようになりました。\n\n### いつでも詳細な情報を提供\n\nGitLab Duo Chatでは常にアクセスできるのは次のとおりです：\n- GitLabドキュメント\n- 一般的なプログラミングとコーディングに関する知識\n\nチャットはGitLabインスタンスやコードベース全体に無制限にアクセスするものではないことをご了承ください。クエリで提供された特定の情報、GitLab UI、その他IDEの現在表示されている内容に直接関連する情報のみを処理します。\n\nGitLabは常にユーザーのプライバシーとデータセキュリティを第一に考えながら、チャットのコンテキスト認識を拡大してより多くの種類のコンテンツに対応できるよう継続的に取り組んでいます。今回の段階的な拡張は、適切なデータアクセスの境界線を維持しながら、チャットが開発ワークフローをサポートするさらに強力なアシスタントとして機能することを目的としたものです。\n\n### コンテキストに関する知識の拡大\n\nGitLab Duo Chatでは、GitLab UIとIDEの両方で[作業中のコンテキストをより深く理解](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#the-context-chat-is-aware-of)できるようになりました。チャットが認識する内容は次のとおりです。\n\nGitLab UI内\n- **エピック** - チャットは「this epic（このエピック）」という指示やエピックのURLの内容を理解できます。\n- **イシュー** - エピックと同様、チャットは「this issue（このイシュー）」という指示やイシューのURLの内容を理解できます。\n- **コードファイル** - 1つのファイルを表示すると、チャットは「このコード」または「このファイル」に関するリクエストを解釈できます。\n\nIDE内\n- **選択されたコード** - チャットは「this code （このコード）」または「this file （このファイル）」について尋ねられた場合に、選択されたコードを分析します。\n- **エピックとイシュー** - チャットはURLを入力するとコンテキストを理解できます。\n\nさらにIDEで`/explain`、`/refactor`、`/tests`などのスラッシュ（/）コマンドを使用すると、チャットは選択されたコードにアクセスできます。\n\n![GitLab Duo Chatウィンドウのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098382107.png)\n\n### チャット履歴とキャッシュ\nGitLab Duo Chatでは、チャット履歴の最新50件のメッセージが保持されます。この履歴は最後の使用から3日後に失効します。ブラウザまたはIDEを閉じてもこの期間内のチャット履歴が完全に削除されるわけではありませんが、現時点でチャットデータの長期保存はサポートされていません。\n\n## 迅速なキャンセル：オンデマンドで回答を停止\n\n強く待ち望まれていた機能である[プロンプトキャンセル]( https://gitlab.com/groups/gitlab-org/-/epics/13662)が利用可能になりました。ユーザーはGitLab.comのチャットで進行中のプロンプトをキャンセルできるようになり、[やり取りをより詳細にコントロール](https://gitlab.com/gitlab-org/gitlab/-/issues/458397)できます。\n- 現在利用可能な利用方式：この機能はすでにGitLab.comで一般提供されています。\n- 近日リリースされる利用方式：この機能は次回のリリースでSelf-Managedインスタンスで利用できるようになります。GitLab Dedicatedユーザーは毎月のアップグレードで機能が追加されます。\n- 開発中の機能：[エディター拡張機能のインテグレーション]( https://docs.gitlab.com/ee/editor_extensions/) - [関連イシューはこちら](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/issues/335)。\n\n今回の機能強化により、プロンプトの送信が早すぎた場合や、待機中に考えが変わった場合などに応答を停止することができるようになりました。小さな変化のように思われるかもしれませんが、時間を節約し、イライラを軽減する優れた機能です。\n\nGitLab Duo Chatでプロンプトをキャンセルするには次の手順に従ってください。\n1. GitLab.comでGitLab Duo Chatを開きます。\n2. プロンプトや`What is this issue about?`などの質問を入力します。\n\n![GitLab Duo Chatでのプロンプトのキャンセル方法を示す画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098382108.png)\n\n3. プロンプトを送信した後に応答をキャンセルしたい場合は、チャットが応答を生成している間に新しく表示されるようになった「キャンセル」ボタンを押してください。\n\n![キャンセルボタンが表示されているチャットのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098382110.png)\n\n4 .「キャンセル」ボタンをクリックすると応答の生成がすぐに停止されます。\n\n![応答停止を示すスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098382112.png)\n\n## アーキテクチャの改善\n\nチームはGitLab Duo Chatをより強化し、効率化するためのアーキテクチャの改善に取り組んできました。\n\n- 言語サーバープロトコルへの移行([LSP](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp))：この取り組みにより、さまざまな開発環境とのチャットのインテグレーションが改善されます。\n- GitLab Language Serverは、IDE拡張機能がGitLabの機能を構築するための共通インターフェイスを提供する実験的なTypeScriptプロジェクトです。現在はGitLab Duoコード提案をサポートしており、今後はGitLab Duo Chatのサポートを開始する予定です。\n\nこの変更は主に基礎となるアーキテクチャに影響を与えるものですが、次のような改善を体験できます。\n- さまざまなIDEやエディターでのチャット使用で応答性とパフォーマンスが向上。\n- さまざまな開発環境でのチャット機能の一貫性の高い動作。\n- 今後の新機能や改善点追加能力の強化。\n\n次の動画では、GitLab Language Serverのコード提案強化について詳しく紹介しています。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/VQlWz6GZhrs?si=_G5mOyYqEGAmnRv4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## 今後の追加機能\n\nGitLab Duo Chatは継続的に改善されています。こちらにいくつかの注目ポイントをまとめました。\n\n- 現在AI機能を[Claude 3.5 Sonnet](https://gitlab.com/gitlab-org/gitlab/-/issues/468334)に移行中です。 このアップグレードにより、チャットやその他のAI搭載機能のパフォーマンスと性能が向上します。\n- 現在、[カスタムのセルフホスティングモデルでチャットを使用できるよう](https://gitlab.com/groups/gitlab-org/-/epics/13760)積極的に取り組んでいます。 これにより組織は独自のAIモデルをチャットで使用できるようになり、AIのナレッジベースをより詳細に制御できるほか、ドメイン固有のタスクのパフォーマンス向上が期待できます。\n- 現在、WebUIを含む[すべてのクライアント間のメッセージの同期](https://gitlab.com/gitlab-org/gitlab/-/issues/418760)を完了しています。これによりシームレスなコミュニケーションが実現されるほかすべてのクライアントが常に同期され、コラボレーションエクスペリエンスが向上します。\n- [「コメントの要約」機能がチャットに移行します](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/156650)。 1つのイシュー上の複数のコメントをチャット内で直接まとめることで、ディスカッションの要点や重要事項をすばやく把握し、コラボレーションを向上させることができます。\n\nぜひ[機能強化に関するフィードバックをお寄せください]( https://gitlab.com/gitlab-org/gitlab/-/issues/430124)。 GitLab Duo Chatは今後も進化していきますので、最新情報をお見逃しなく。\n\n> [GitLab Duo開発の現場から]( https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-series/)シリーズではGitLab Duoの開発方法の詳細をご覧いただけます。\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[721,678,701],"2024-11-12",{"slug":3282,"featured":92,"template":681},"developing-gitlab-duo-a-roundup-of-recent-chat-enhancements","content:ja-jp:blog:developing-gitlab-duo-a-roundup-of-recent-chat-enhancements.yml","Developing Gitlab Duo A Roundup Of Recent Chat Enhancements","ja-jp/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements.yml","ja-jp/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements",{"_path":3288,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3289,"content":3295,"config":3300,"_id":3302,"_type":16,"title":3303,"_source":17,"_file":3304,"_stem":3305,"_extension":20},"/ja-jp/blog/event-report-japan-it-week-spring-1",{"title":3290,"description":3291,"ogTitle":3290,"ogDescription":3291,"noIndex":6,"ogImage":3292,"ogUrl":3293,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3293,"schema":3294},"DevOpsからDevSecOpsへ: IT Week 2024 春イベントレポート【前編】","2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666522/Blog/Hero%20Images/_NYG2319.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-spring-1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOpsからDevSecOpsへ: IT Week 2024 春イベントレポート【前編】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-04\",\n      }",{"title":3290,"description":3291,"authors":3296,"heroImage":3292,"date":3297,"body":3298,"category":740,"tags":3299},[738],"2024-07-04","*今回から2回に分けて、2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えします。前編では、DevSecOpsの最新状況とGitLabの価値について、パートナー様やお客様のご意見を取り入れながら紹介していきます。*\n\n## DevOpsをより高品質にするPlatform Engineering\n\nアプリケーション開発のやり方は、テクノロジーの進化とともに変化し、最適化されていきます。変化のスピードは2000年代に入ると加速し、近年はより高まっているように感じられるのは、テクノロジーの進化と多様化が進んでいるためでしょう。その中で、いくつも最新ワードが流行し、消費されることになりますが、時代を象徴する言葉は永く私達の記憶に刻まれることになるでしょう。\n\nいま、注目を集めているワードは、どのようなものでしょう。[SB C&S株式会社](https://cas.softbank.jp/)の佐藤 梨花氏は、「Platform Engineering」を取り上げます。Platform Engineeringは、開発プラットフォームの硬直化を防ぐ概念。開発効率の高いプラットフォームをいち早く取り入れ、モダン化できる状況を整えることで、開発生産性と開発品質をどちらも向上させようとする考え方です。DevOpsを信頼性の高いものとして安定的に運用するために必要なものとして有名なのはSREですが、SREとは別のアプローチでDevOpsをより高速に回し、最適化し続けるものがPlatform Engineeringであると言えばわかりやすいでしょうか。\n\nPlatform Engineeringは、GitLabと相性が良いことも好印象です。[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)にSAST/DASTを組み込んだ自動化はもちろん、イシューとエピック、Wikiによる情報共有、そしてプロジェクトの状況を可視化するアナライズ機能など、GitLabはPlatform Engineeringの成功に必要なさまざまな機能を備えています。VSM（Value Stream Mapping）を使った成果測定手法も確立しつつあり、これからも注目されることになるでしょう。\n\nDevOpsをうまく回すための手法が、最新のワードとして取り上げられるのは興味深い事実です。DevOpsは、すでに「当たり前の存在」になったと言えるのかもしれません。[アジャイル開発](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)と親和性が高いことで普及が後押しされたという側面はありますが、DevOpsの概念であるDevelopment＝開発とOperation＝運用が連携／協力して、フレキシブルかつスピーディに業務を遂行することで得られる価値が多くの企業で実証されたことも重要なポイントでしょう。\n\n![DSC2328_202404JapanITWeekYukiMurakami](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC2328.jpg)\n*GitLab合同会社 営業本部 エンタープライズ営業部 シニア アカウントエグゼクティブ 村上 裕紀*\n\nDevOpsというワードが生まれた当初は、あくまでもコンセプトであり考え方にすぎなかったのですが、それを実現するツール群が提供されるようになったことで、そのコンセプトを実際のプロセスに適用できるようになりました。DevOpsの登場で、「できるだけ早く多くの機能を実装したい」という開発者たちと、「できるだけ安全かつ継続的に運用したい」という運用チームの立場の違いを吸収し、両者が連携して効率的にプロジェクトを進められるようになったのです。\n\nこの流れに乗ってGitLabも進化を続けています。[2023年にガートナーのマジック・クアドラント](https://about.gitlab.com/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms/)において、DevOpsプラットフォームのリーダーに位置づけられ、フォレスター・リサーチのThe Forrester Waveでは唯一のリーダーポジションを得ています。開発、テスト、Deployのプロセスを自動化できるだけでなく、DevOpsの全プロセスを網羅する機能群を提供し、それらが有機的に結びついた開発生産性の高いプラットフォームとなっていることが評価されました。\n\n## DevOpsにセキュリティを組み込むDevSecOpsの価値\n\nDevSecOpsという最新のコンセプトは、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)をDevOpsのプロセスに組み込むものです。[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)／コンプライアンスの重要性が高まり、“説明可能な”[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)が求められるいま、多くの日本企業が注目し、アーリーアダプターが成果を出し始めています。そして、GitLabはすでにDevOpsを超えてDevSecOpsを実現する機能を提供しています。\n\n「DevSecOpsを実現するツール」を調べると、多くの選択肢が目に止まるかもしれません。実際に、DevSecOpsを実現するために、活用できるツールにはさまざまなものがあります。ただ、その中でGitLabは唯一、「DevSecOpsをやりたければGitLabがあれば良い」という統合ソリューションを提供できるのです。開発者、セキュリティチーム、運用チームを一連のプロセスの中で統合できるのはGitLabだけです。\n\n「複数のツールを組み合わせてDevSecOpsをDIYで作る」やり方も可能ではありますが、その場合「DIYしたDevSecOpsの運用コスト」が必要になります。GitLabならそれが必要ないことは大きなメリットで、開発、テスト、Deployという一連のプロセスを自動化し、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)を含めた開発プロセスすべてを管理できます。\n\nさらに、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)機能として最も重視される脆弱性の早期検知においても、強力なエンジンを提供しています。この機能はテストプロセスの後に組み込まれ、開発してすぐテストするというDevOpsの流れをそのまま持ち込めば、開発者は自分の書いたコードや使用するライブラリに脆弱性が含まれるかどうかをすぐに理解することができます。計画段階においてはイシューに要件を付加しておけば、どのレベルの[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)が必要かどうかを振り返って判断することもでき、レビュー時に再確認することも容易です。自動化と人手による検証をどちらも可能にし、開発からリリースに至る全工程に[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)を持ち込み、必要なところは自動化できるようになるのです。\n![DSC1407_202404JapanITWeekYoheiKawase](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1407.jpg)\n*GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスマネジメント部 シニアカスタマーサクセスマネージャー 川瀬 洋平*\n\nひとつのプラットフォームでDevSecOpsを実現することで、ツールを連携させて運用するコストはなくなり、ライセンスコストも最小化します。GitLabのユーザーインタフェースは直感的で評価は高く、開発生産性は大きく向上します。自動化により、開発プロセスはスピードアップします。GitLabが外部委託した調査では、ユーザー企業が収益を生み出すアプリケーション開発プロセスおいて427％のROIを実現し、6か月未満で投資を回収できたことが明らかになりました。\n\nさらに、GitLabでは、DevSecOpsプロセスに[AI](https://about.gitlab.com/ja-jp/gitlab-duo/)を取り入れ、より強力にプロセスの効率化を支援しています。[AI](https://about.gitlab.com/ja-jp/gitlab-duo/)の進化、およびその使い方の熟成が進めば、数字として表面化する成果もより優れたものになると期待されています。\n\n## CI/CDでリリース1回あたりの作業時間を9分の1に\n\n最後に、日本ですでにDevSecOpsに取り組んでいる事例を紹介します。ブースセミナーに登壇した[株式会社キャラウェブ](https://www.chara-web.co.jp/) クラウドパートナーグループ 副部長 中山 桂一氏は、GitLabの導入支援を実施する立場からのコメントをいただき、[株式会社ジークス](https://www.zyyx.jp/) 新規事業開発室 久保 仁詩氏には自社での活用状況についてお話いただいています。\n\nジークスの久保氏が最も顕著な成果を得られたと感じているのは、[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)による自動化です。作業時間の短縮だけでなく、人為的ミスをなくすことにもCI/CDは役立っています。\n\n![DSC1773_202404 Japan IT Week Kubo san from ZYYX](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1773.jpg)\n*株式会社ジークス 新規事業開発室 久保 仁詩氏*\n\nリリースプロセスでは、まず手順書を準備し、モジュールを作成。ターミナルに接続してコマンドを実行する作業をサーバ台数分繰り返す必要がありました。これらをすべて開発者の手作業で実施していたころには、3人がそれぞれ30分をかける必要のあるプロセスで、実行コマンドの入力（手順書のコピー＆ペースト）ミスやリリース漏れなどのリスクがありました。\n\n[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を導入すれば、これらのプロセスはすべて自動化されます。その結果、導入後には、1人の開発者が実行結果を確認するためにわずか10分の時間をかけるだけで済むようになりました。ジークスでは、スモールスタートで効果を確認し、[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を採用するプロジェクトを拡大。現在はモバイル領域にも[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を適用し、月間平均80時間に相当する業務効率化を達成しました。さらに、リリースタイミングは月次や週次ではなく、1日に5回できるようになりました。\n\nキャラウェブの中山氏は、GitLabで開発プロセスを管理する価値は大きいと紹介してくれました。具体的には、マージリクエストの際に、自動的に脆弱性検査とライセンスチェック、コード品質検査を実施することで手戻りは最小限に抑えられます。9種のセキュリティテストを同時に走らせ、静的スキャンに加えて動的な脆弱性スキャンも実施することができます。マージ後に再度セキュリティテストを実行することで、安心できるセキュリティレベルを保証することも可能です。\n\n![DSC1811_202404JapanITWeekNakayamasan](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1811.jpg)\n*株式会社キャラウェブ クラウドパートナーグループ 副部長 中山 桂一氏*\n\n\u003Cbr>\nブースセミナーにパートナー様とお客様が登壇してくださったように、日本でもDevSecOpsは徐々に浸透してきています。アーリーアダプターからはすでに数多くの成功者が生まれています。これからもDevSecOpsの発展とGitLabにご注目ください。\n\n\u003Cbr>\u003Cbr>\n＜[後編を読む：DevSecOpsで人材問題は解決できるか](https://about.gitlab.com/ja-jp/blog/event-report-japan-it-week-spring-2/)＞",[280,1880,702,904],{"slug":3301,"featured":92,"template":681},"event-report-japan-it-week-spring-1","content:ja-jp:blog:event-report-japan-it-week-spring-1.yml","Event Report Japan It Week Spring 1","ja-jp/blog/event-report-japan-it-week-spring-1.yml","ja-jp/blog/event-report-japan-it-week-spring-1",{"_path":3307,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3308,"content":3314,"config":3319,"_id":3321,"_type":16,"title":3322,"_source":17,"_file":3323,"_stem":3324,"_extension":20},"/ja-jp/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci",{"title":3309,"description":3310,"ogTitle":3309,"ogDescription":3310,"noIndex":6,"ogImage":3311,"ogUrl":3312,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3312,"schema":3313},"AI搭載のGitLab Duoチャットを使用するためのベストプラクティス【10選】 (1)","AI搭載のDevSecOpsワークフローにGitLab Duoチャットを統合するためのヒントとコツをご覧ください。さらに、最高の結果を得るためにチャットプロンプトを絞り込む方法に関する専門家のアドバイスもご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659684/Blog/Hero%20Images/AdobeStock_479904468__1_.jpg","https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI搭載のGitLab Duoチャットを使用するためのベストプラクティス【10選】 (1)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2024-07-02\",\n      }",{"title":3309,"description":3310,"authors":3315,"heroImage":3311,"date":3316,"body":3317,"category":740,"tags":3318},[2153],"2024-07-02","AIと会話を交わすのはチャレンジングかもしれません。どのような質問から始めるべきでしょうか？どのように質問を組み立てますか？どのくらいのコンテキストが必要でしょうか？会話により最高かつ最適な結果を得られるのでしょうか？\n\n\nこのチュートリアルでは、AI搭載のDevSecOpsワークフローにGitLab\nDuoチャットを統合し、最良な結果を得るためにプロンプトを洗練させる上で役立つヒントとベストプラクティス10選をご紹介します。\n\n\n[始める：GitLab\nDuoチャットを開いたままにしておく](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#始める：GitLab-Duoチャットを開いたままにしておく)\n\n\n[GitLab\nDuoチャットを使用するためのベストプラクティス10選](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#GitLab-Duoチャットを使用するためのベストプラクティス10選)\n\n\n1.\n[会話を交わす](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#1.-会話を交わす)\n\n2.\n[効率を上げるためにプロンプトを絞り込む](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#2.-効率を上げるためにプロンプトを絞り込む)\n\n3.\n[プロンプトのパターンに従う](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#3.-プロンプトのパターンに従う)\n\n4.\n[ローコンテキストコミュニケーションを使用する](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#4.-ローコンテキストコミュニケーションを使用する)\n\n5.\n[繰り返す](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#5.-繰り返す)\n\n6.\n[焦らない](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#6.-焦らない)\n\n7.\n[リセットして再起動](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#7.-リセットして再起動)\n\n8.\n[IDEのスラッシュコマンドで効率化](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#8.-IDEのスラッシュコマンドで効率化)\n\n9.\n[スラッシュコマンドのプロンプトを絞り込む](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#9.-スラッシュコマンドのプロンプトを絞り込む)\n\n10.\n[スラッシュコマンドでクリエイティブに](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#10.-スラッシュコマンドでクリエイティブに)\n\n\nボーナスコンテンツ：\n\n-\n[ショートカット](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#ショートカット)\n\n-\n[試してみよう](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#試してみよう)\n\n-\n[詳細](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#詳細)\n\n\n> AIで進化する最新のGitlab １７とGitLab Duoを、ライブ中継で観てみませんか？\u003Cbr>\n[__＞日本時間6月28日のイベントに今すぐ登録する＜__](https://about.gitlab.com/seventeen/)\n\n\n## 始める：GitLab Duoチャットを開いたままにしておく\n\n\n[GitLab\nDuoチャット](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)は、GitLab\nUI、Web IDE、およびVS CodeなどのサポートされているプログラミングIDEで利用できます。\n\n\nVS Codeでは、デフォルトの左ペインでGitLab\nDuoチャットを開くことができます。アイコンを右側のペインにドラッグアンドドロップすることもできます。これにより、コードを書いたり、ファイルツリーを移動したり、Gitアクションを実行したりしている間も、チャットを開いたままにしておくことが可能です。チャットの場所をリセットするには、コマンドパレットを開きます。macOSの場合は\n`[Command] + [Shift] + [P]`、Windows/Linuxの場合は `[Ctrl] + [Shift] + [P]`\nキーボードショートカットを押し、`View: Reset View Locations` と入力します。以下の短いビデオで、その方法を説明します。\n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/foZpUvWPRJQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n\nWeb IDEとVS Codeは同じフレームワークを共有しています。Web IDEでは同じメソッドを使用でき、より効率的なワークフローを実現できます。\n\n\n![Web\nIDEのチャット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676997/Blog/Content%20Images/1.duo-chat-installing-catch2.png)\n\n\n## GitLab Duoチャットを使用するためのベストプラクティス10選\n\n\n### 1. 会話を交わす\n\n\nチャットは会話形式で行うべきであり、検索フォームではありません。\n\n\n会話の始め方としては、ブラウザでの検索と同様の検索用語から始めて、応答と出力を試してみることをおすすめします。この例では、C#プロジェクトとベストプラクティスから始めましょう。\n\n\n> c# start project best practices \n\n> \n\n> （c#プロジェクト スタート時のベストプラクティス）\n\n\n![C#スタートプロジェクトのベストプラクティスのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/2.running-catch2-tests.png)\n\n\nこの回答は、C#の幅広いスコープを理解するのには役立ちますが、すぐに実践できるベストプラクティスを提示しているわけではありません。次は、同じコンテキストで、より焦点を絞った質問をしてみましょう。\n\n\n> Please show the project structure for the C# project.\n\n> \n\n> （C#プロジェクトのプロジェクト構造を示してください）\n\n\n![C#プロジェクトの構造のチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/2.0-passed-tests-UI.png)\n\n\nこの回答は参考になります。次に、同じ質問の構成でGitに関する質問をしてみましょう。何かを表示してほしいと指示します。\n\n\n> Show an example for a .gitignore for C#\n\n> \n\n> （C#の.gitignoreの例を示してください）\n\n\n![C#の.gitignoreのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/2.1-failed-test-simulation.png)\n\n\nCI/CDに進み、C#プロジェクトを構築する方法を尋ねます。\n\n\n> Show a GitLab CI/CD configuration for building the C# project\n\n> \n\n> （C#プロジェクトを構築するためのGitLab CI/CD設定を表示してください）\n\n\n![C#プロジェクトを構築するためのGitLab\nCI/CD設定のチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/2.2-failed-test-simulation-details.png)\n\n\nこの例では、チャットは、具体的な変更をリクエストするよう促しています。.NET SDK 6.0の代わりに、.NET SDK\n8.0を使用するようリクエストしましょう。\n\n\n> In the above example, please use the .NET SDK 8.0 image\u003Cbr>\n\n> （上記の例では、次を使用してください。.NET SDK 8.0イメージ）\n\n\n![.NET SDK\n8.0を使用するためのチャットプロンプトと回答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/3.get-current-weather-function-completion.png)\n\n\nCI/CD設定で.NETコマンドラインインターフェース（CLI）が使用されます。もしかしたら、プロジェクトやテストの構造を作成するコマンドの効率化にも使えるかもしれません。\n\n\n> Explain how to create projects and test structure on the CL\n\n> \n\n> （CLIでプロジェクトとテスト構造を作成する方法を説明してください）\n\n\n![CLIでプロジェクトとテスト構造を作成する方法を説明するよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image14.png)\n\n\nもちろん、これらのコマンドをターミナルで実行することもできますが、引き続きVS\nCodeを使用したい場合はどうすればよいでしょうか。チャットに尋ねましょう。\n\n\n> Explain how to open a new terminal in VS Code\n\n> \n\n> （VS Codeで新しいターミナルを開く方法を説明してください）\n\n\n![VS\nCodeで新しいターミナルを開く方法を説明するよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image5.png)\n\n\n### 2. 効率を上げるためにプロンプトを絞り込む\n\n\nGitLab Duoチャットを人間と同じように考え、あなたの考えや質問に関してできるだけ多くの文脈を伝えられるよう、文章でやり取りしてください。\n\n\nブラウザで頻繁に検索する方は、クエリに対するこのアプローチをご存知かもしれません。質問を組み立て、さらに用語を追加して範囲を絞り込み、たくさんのタブが表示された上で検索を再開します。 \n\n\nブラウザ検索では、おそらく4つから5つの検索ウィンドウが表示されるでしょう。\n\n\n```マークダウン\n\nc# start project best practices\n\nc# .gitignore\n\nc# gitlab cicd \n\nc# gitlab security scanning \n\nc# solutions and projects, application and tests\n\n``` \n\n\nチャットでの会話でも、同じ戦略を採用できます。より多くの文脈を加え、会話的なアプローチにする必要があります。GitLab\nDuoチャットでは、1回の会話リクエストで複数の質問ができます。例：上記の検索と同様、新しいC#プロジェクトから始めて、ベストプラクティスを適用し、`.gitignore`\nファイルを追加し、CI/CDとセキュリティスキャンを設定する必要があります。チャットでは、質問を1つのリクエストにまとめることができます。\n\n\n> How can I get started creating an empty C# console application in VS Code?\nPlease show a .gitignore and .gitlab-ci.yml configuration with steps for C#,\nand add security scanning for GitLab. Explain how solutions and projects in\nC# work, and how to add a test project on the CLI.\n\n> \n\n> （VS\nCodeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示し、GitLabのセキュリティスキャンを追加してください。C#のソリューションとプロジェクトがどのように動作するのかに加え、CLIでテストプロジェクトを追加する方法を説明してください）\n\n\n![より多くの文脈を加えたチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image37.png)\n\n\nこの応答で、チャットは会話のフォローアップの質問で具体的な設定例を尋ねるよう提案しています。応用：フォローアップの質問を作成しましょう。同じチャットセッションでは、コンテキストとしてC#を省略することができます。\n\n\n> Please show an example for a .gitignore. Please show a CI/CD\nconfiguration. Include the SAST template.\n\n> \n\n>   （gitignoreの例を示してください。CI/CDの設定を示してください。SASTテンプレートを含めてください）\n\n\n### 3. プロンプトのパターンに従う \n\n\n「プロンプト命令文、助けを求めて、追加のリクエストをする」というパターンに従ってください。最初の質問ですべての答えが得られるとは限りません。閉塞感を感じないよう、最初は「プロンプト命令文、助けを求める」を繰り返すことから始めましょう。\n\n\n> I need to fulfill compliance requirements. How can I get started with\nCodeowners and approval rules?\n\n> \n\n> （コンプライアンス要件を満たす必要があります。CODEOWNERSと承認ルールの使い始め方を教えてください）\n\n\n![CODEOWNERSと承認ルールを使い始めるためのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image19.png)\n\n\n回答は役に立つものの、明らかに一般的な内容です。そこで、チーム用の設定について具体的な内容を教えてもらうこともできます。\n\n\n> Please show an example for Codeowners with different teams: backend,\nfrontend, release managers.\n\n> \n\n> (バックエンド、フロントエンド、リリースマネージャーといった異なるチームのCODEOWNERSの例を示してください)\n\n\n![バックエンド、フロントエンド、リリースマネージャーといった異なるチームのCODEOWNERSの例を示すよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image31.png)\n\n\nもう1つの方法は、自分が置かれている状況を説明し、意見を求めることです。STARモデル（状況、タスク、アクション、結果）に従うと、うまく質問ができるでしょう。\n\n\n> I have a Kubernetes cluster integrated in GitLab. Please generate a Yaml\nconfiguration for a Kubernetes service deployment. Explain how GitOps works\nas a second step. How to verify the results?\n\n> \n\n>\n（GitLabに統合されたKubernetesクラスターがあります。KubernetesサービスをデプロイするためのYAML設定を生成してください。2つ目のステップとしてGitOpsがどのように動作するかを説明してください。結果を検証する方法は？）\n\n\n![複数の質問を含むチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image27.png)\n\n\n### 4. ローコンテキストコミュニケーションを使用する\n\n\n回答するためになるべく多くのコンテキストを提供します。以前の履歴または開かれたソースコードからは、そういった有用なコンテキストが得られない場合もあります。より効率的に質問するために、GitLabのオールリモート環境でのコミュニケーションで使用される[ローコンテキストコミュニケーション](https://handbook.gitlab.com/handbook/company/culture/all-remote/effective-communication/#understanding-low-context-communication)のパターンを適用します。\n\n\n次の質問の場合、C++プロジェクトにおいて十分なコンテキストを提供できていません。\n\n\n> Should I use virtual override instead of just override?\n\n> \n\n> （単にオーバーライドをつかうのではなく、仮想オーバーライドをつかったほうがいいですか？）\n\n\n![ユーザーが上書きの代わりに仮想の上書きを使用する必要があるかどうかを尋ねるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image34.png)\n\n\n代わりに、より多くのコンテキストを追加してみてください。\n\n\n> When implementing a pure virtual function in an inherited class, should I\nuse virtual function override, or just function override? Context is C++.\n\n> \n\n>\n（継承クラスに純粋な仮想関数を実装する場合、仮想関数の上書きを使用する必要がありますか、それとも単に関数の上書きを使用する必要がありますか？コンテキストはC++です）\n\n\n![詳細情報を含むチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image36.png)\n\n\nこの例は、[GitLab\nDuoコーヒーチャット：抽象的なデータベース処理のためにC++関数をOOPクラスにリファクタリングする](https://youtu.be/Z9EJh0J9358?t=2190)でもご紹介しています。\n\n\n### 5. 繰り返す\n\n\nAIは予測できないものです。想定した結果が返されない場合や、コンテキストが不足しているためソースコードの例や設定スニペットが生成されない場合があります。質問を繰り返し、要件を絞り込んでいくことをおすすめします。\n\n\n以下の例では、C#アプリケーションを作成します。最初の試行では、アプリケーションタイプを指定しませんでした。C#を使用してコンソール/ターミナルだけでなく、UIアプリケーションも作成できます。また、回答結果には、空のサンプルソースコードも表示されませんでした。2つ目に再度入力するプロンプトでは、「コンソール」と「空」の2つの単語を追加します。\n\n\n> How can I get started creating an C# application in VSCode?\n\n> \n\n> （VS CodeでC#アプリケーションを作成するにはどうすればよいですか？）\n\n> \n\n> How can I get started creating an empty C# console application in VSCode?\n\n> \n\n> （VS Codeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？）\n\n\nプロンプトの結果は異なります。最初の質問への回答内容は、VS\nCodeウィンドウの手順に従って開始するのに役立ちますが、ソースコードの場所と変更方法は示されません。改良したプロンプトを改めて入力することで、回答内容が修正され、デフォルトのテンプレートを\n「hello world」コードで上書きする方法が示されます。\n\n\n![修正したプロンプトを改めて入力したチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image28.png)\n\n\n質問を繰り返したり洗練させることで、アプリケーションコードやテストの例を表示するよう、チャットにリクエストもできます。\n\n\n> How can I get started creating an empty C# console application in VSCode?\nPlease show an example for application and tests.\n\n> \n\n> （VS Codeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？アプリケーションとテストの例を示してください）\n\n\n![アプリケーションとテストの例を求めるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image3.png)\n\n\n#### 一般的な質問を繰り返します \n\n\n一般的な技術的質問を尋ねた場合、GitLab\nDuoチャットでは対応できないことがあります。次のシナリオでは、Javaのビルドツールとフレームワークに関する提案を得ようとしたものの、うまくいきませんでした。この質問への答えは数多く考えられます。ビルドツールとしてはMaven、Gradleなどがあり、テクノロジースタックや要件によっては[100以上のJavaフレームワーク](https://en.wikipedia.org/wiki/List_of_Java_frameworks)があります。\n\n\n![Javaのビルドツールとフレームワークに関するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image2.png)\n\n\nでは、[Java Spring\nBoot](https://spring.io/projects/spring-boot)を使った顧客環境に焦点を当てたいと想定してみます。\n\n\n> I want to create a Java Spring Boot application. Please explain the\nproject structure and show a hello world example.\n\n> \n\n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello Worldの例を示してください）\n\n\n![Hello\nWorldの例を含め、追加情報を求めるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image26.png)\n\n\nすでに素晴らしい結果が返って来ています。応用として、プロンプトを繰り返し、アプリケーションのデプロイ方法を尋ね、それぞれのステップでさらに改良を加えてください。別の方法として、フォローアップの会話にする方法もあります。\n\n\n> I want to create a Java Spring Boot application. Please explain the\nproject structure and show a hello world example. Show how to build and\ndeploy the application in CI/CD.\n\n> \n\n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello\nWorldの例を示してください。CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください）\n\n> \n\n> I want to create a Java Spring Boot application. Please explain the\nproject structure and show a hello world example. Show how to build and\ndeploy the application in CI/CD, using container images.\n\n> \n\n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello\nWorldの例を示してください。コンテナイメージを使用して、CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください）\n\n> \n\n> I want to create a Java Spring Boot application. Please explain the\nproject structure and show a hello world example. Show how to build and\ndeploy the application in CI/CD, using container images. Use Kubernetes and\nGitOps in GitLab.\n\n> \n\n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello\nWorldの例を示してください。コンテナイメージを使用して、CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください。示します。GitLabでKubernetesとGitOpsを使用してください）\n\n### 6. 焦らない\n\n\n1つの単語または短い文章すると、[このビデオの例に示すように]（https://youtu.be/JketELxLNEw?t=1220）、望ましい結果が得られない場合があります。GitLab\nDuo Chatは、利用可能なデータから推測を行うことができる場合がありますが、より多くのコンテキストの提供を主張する場合もあります。\n\n\n例：`labels` はGitLabのドキュメントの内容に一致します。\n\n\n![ラベルと応答に関するチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image12.png)\n\n\n指示内容をブラッシュアップしてイシューボードでの使用法についてさらなる改良を行います。\n\n\n> Explain labels in GitLab. Provide an example for efficient usage with\nissue boards.\n\n> \n\n> （GitLabのラベルを説明してください。イシューボードで効率的に使用できる例をください）\n\n\n![例と回答を求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image21.png)\n\n\nまたは、問題を記述し、その後に質問をして、追加の例を尋ねます。\n\n\n> I don't know how to use labels in GitLab. Please provide examples, and how\nto use them for filters in different views. Explain these views with\nexamples.\n\n> \n\n>\n（GitLabでラベルを使用する方法が分かりません。さまざまなビューのフィルターにラベルを使用する方法の例をください。これらのビューを例で説明してください）\n\n\n![問題文と回答を含むチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image10.png)\n\n\nまた、「はい/いいえ」の質問を避け、代わりに特定のコンテキストを追加します。\n\n\n> Can you help me fix performance regressions?\n\n> \n\n> （パフォーマンスのレグレッションを修正するのを手伝ってもらえますか？）\n\n\n![パフォーマンスのリグレッションと応答を修正するための助けを求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image18.png)\n\n\n代わりに、プログラミング言語、フレームワーク、テクノロジースタック、および環境を含む、パフォーマンスレグレッションのコンテキストを提供します。次の例では、数年前の環境を使用していますが、現在でも十分正確です。\n\n\n> My PHP application encounters performance regressions using PHP 5.6 and\nMySQL 5.5. Please explain potential root causes, and how to address them.\nThe app is deployed on Linux VMs.\n\n> \n\n> （私のPHPアプリケーションは、PHP 5.6とMySQL\n5.5を使用してパフォーマンスのリグレッションに遭遇しています。潜在的な根本原因とそれらに対処する方法を説明してください。このアプリはLinux\nVMにデプロイされています）\n\n\n![詳細と回答を含むチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image24.png)\n\n\n### 7. リセットして再起動\n\n\n時々、チャット履歴を見る限り、意図しない学習経路を辿ってしまったが故に、フォローアップの質問のコンテキストが間違っている場合があります。または、GitLab\nDuoチャットが回答を提供できない特定の質問をした可能性があります。生成系AIは予測不可能であり、特定の例を提供することができなかったかもしれませんが、将来の応答でそれらを提供していけるようになるでしょう（チャットベータで観察）。基礎となる大規模言語モデル（LLM）は、時には無限ループに陥ってしまう場合もあります。\n\n\n> How can I get started creating an empty C# console application in VSCode?\nPlease show a .gitignore and .gitlab-ci.yml configuration with steps for C#,\nand add security scanning for GitLab. Explain how solutions and projects in\nC# work, and how to add a test project on the CLI.\n\n> \n\n>\n（VSCodeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示し、GitLabのセキュリティスキャンを追加してください。C#のソリューションとプロジェクトがどのように機能するのか、CLIでテストプロジェクトを追加する方法を説明してください）\n\n\n上記の内容で質問をした後、よりカスタマイズされた応答を得るために、質問の範囲を縮小したいと思いました。チャットはコンテキストでチャット履歴を把握しており、以前の回答を参照しているため、期待どおりに機能しませんでした。\n\n\n> How can I get started creating an empty C# console application in VSCode?\nPlease show a .gitignore and .gitlab-ci.yml configuration with steps for C#.\n\n> \n\n>\n（VSCodeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示してください）\n\n\n![設定例と応答を求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image23.png)\n\n\nチャットを新しいコンテキストに強制的に追加するには、`/reset` をスラッシュ（/）\nコマンドとして使用してセッションをリセットし、質問を繰り返してより良い結果を得ていくことになります。`/clean` または `/clear`\nを使用して、会話内のすべてのメッセージを削除することもできます。\n\n\n### 8. IDEのスラッシュコマンドで効率化\n\n\n#### コードを説明する\n\n\n- 質問：生成されたコードですか？既存のコードですか？従来のコードですか？\n\n- 回答：[IDEの`/explain`スラッシュ（/）\nコマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#explain-code-in-the-ide)を使用します。\n\n- 回答2：より焦点を当てた応答でプロンプトを絞り込む。例： `/explain focus on potential shortcomings or\nbugs. （/explain 潜在的な欠点やバグに焦点を当てる）`\n\n\n![/explainスラッシュ（/）\nコマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/gitlab_duo_chat_slash_commands_explain_01.png)\n\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image6.png)\n\n\n#### コードのリファクタリング\n\n\n- 質問：読みづらいコードですか？長いスパゲッティコードですか？テストカバレッジはゼロですか？\n\n- 回答：[IDEの`/refactor`スラッシュ（/）\nコマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#refactor-code-in-the-ide)を使用します。\n\n- 回答2 ：よりターゲットを絞ったアクションのプロンプトを絞り込む。例：オブジェクト指向パターン：`/refactor into\nobject-oriented classes with methods and attributes`。\n\n\n![/refactor\nslashコマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image35.png)\n\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image30.png)\n\n\n#### テストを生成\n\n\n- 質問：テスト可能なコードですが、テストの作成に時間がかかりすぎますか？\n\n- 回答：[IDEの`/tests`スラッシュ(/)\nコマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#write-tests-in-the-ide)を使用します。\n\n-\n回答2：特定のテストフレームワーク、またはテストターゲットのプロンプトを絞り込む。プロンプトにリファクタリングに焦点を当てるように指示し、次にテストを生成することもできます。`/tests`はコードを関数にリファクタリングし、テストを生成することに焦点を当てます。\n\n\n![/testsスラッシュ(/)\nコマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image29.png)\n\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image4.png)\n\n\n完全な開発ワークフローのより実用的な例は、[GitLab\nDuoの例](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html)のドキュメンテーションで入手できます。\n\n\n### 9. スラッシュコマンドのプロンプトを絞り込む\n\n\nこのブログ記事には、洗練されたプロンプトのヒントが数多くあったことでしょう。これらは、AIを活用したワークフロー効率を向上させるための要素の1つです。スラッシュ(/)\nコマンドを賢く使うことで、GitLab Duoチャットでより良い結果が得られます。\n\n\nあるお客様は最近、次のように尋ねました。「`/explain` を使用したコードの説明は、コード内にコメントを作成できますか？」\n答えは「いいえ」です。ただし、チャットプロンプトを使用してフォローアップの質問をしたり、コード内に記述できるコメント形式でコードの要約を求めることができます。その場合は、言語の指定が必要でしょう。\n\n\n[curlライブラリを使用したC++\nHTTPクライアントコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5cc9bdd65ee8ee16c548bea0402c18f8209d4d06/chat/slash-commands/c++/cli.cpp)の次の例には、より多くのドキュメント（指示内容）が必要です。コード内のコメントを追加して、より洗練した指示内容を/explainコマンドに渡すことで、よりよい結果が得られ、その結果をエディタ内に貼り付けていく、という方法もよいでしょう。\n\n\n> /explain add documentation, rewrite the code snippet\n\n> （/explain ドキュメントを追加し、コードスニペットを書き換えてください）\n\n\n![ドキュメントを追加し、コードスニペットと応答を書き換えるためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image13.png)\n\n\nまたは、チャットにソースコードを `/refactor`\nするように依頼し、洗練されたプロンプトを使用して不足しているコードコメントを生成することもできます。\n\n\n> /refactor add code comments and documentation\n\n>\n\n> （/refactor コードのコメントとドキュメントを追加してください）\n\n\n![ソースコードをリファクタリングし、コードコメントを生成するためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image15.png)\n\n\n### 10. スラッシュコマンドでクリエイティブに\n\n\nチャットプロンプトがソースコードまたはプログラミング言語に関する質問への回答が得られない場合は、スラッシュ(/) コマンド\n`/explain`、`/explain`、`/tests` を試してみて、それらがコンテキスト作りに役に立つかどうかみてみましょう。\n\n\n以下の例では、C++のコード内でSQLクエリ文字列が1行で作成されます。読みやすさを高め、将来的にはより多くのデータベース列を追加できるようにするには、書式を複数行の文字列に変更すると便利です。\n\n\n> std::string sql = \"CREATE TABLE IF NOT EXISTS users （id INTEGER PRIMARY\nKEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL）\";\n\n\nたとえば、次の質問をその後に続けてGitLab Duo Chatに尋ねられます。\n\n\n> How to create a string in C++ using multiple lines?\u003Cbr>\n\n>（複数行を使用してC++で文字列を作成する方法）\n\n\nチャット自体は、説明文とオプションでソースコードの例で回答してくれるでしょう。ただ、この場合は、単にその文字列を\"¥n\"を間に入れて複数行にすればいい、という解釈をするでしょう。でも、私達が求めているのは、そうではなく、ソースコード上で見やすくするために「複数行」にしてほしい、ということですよね。\n\n\nVSCodeとWeb IDEには、追加のコンテキストの代替案があります。問題のソースコードを選択し、右クリックして、[GitLab Duoチャット]>\n[リファクタリング]に移動します。これにより、チャットプロンプトが開き、`/refactor`コードタスクがすぐに開始されます。\n\n\nただし、コードタスクは期待される結果をもたらさない可能性があります。1行のSQL文字列をリファクタリングすることは、読みやすさのために複数行を使用すること、定数を作成することなど、多くを意味するからです。\n\n\nコードタスクには、プロンプトを絞り込むオプションがあります。`/refactor` コマンドの後にテキストを追加し、GitLab\nDuoチャットに特定のコードタイプ、アルゴリズム、またはデザインパターンを使用するように指示できます。\n\n\nもう一度やり直してみましょう。ソースコードを選択し、フォーカスをチャットに変更し、次のプロンプトを入力して、`[Enter]`を押します。\n\n\n> /refactor into a multi-line written string. Show different approaches for\nall C++ standards.\n\n>\n\n>（/refactor 複数行の書き込み文字列に変換します。すべてのC++標準に異なるアプローチを示します）\n\n\n![複数行の文字列と応答にリファクタリングするためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image17.png)\n\n\n**ヒント：** GitLab Duoのコード提案を使用して、リファクタリング後にソースコードをさらに洗練することも、あるいは、かわりに\n`/refactor` プロンプトの絞り込みを使用することもできます。\n\n\n> /refactor into a multi-line written string, show different approaches\n\n>\n\n> （/refactor 複数行の文字列に変換し、さまざまなC++標準のアプローチを表示してください）\n\n>\n\n> /refactor into multi-line string, not using raw string literals\n\n>\n\n> （/refactor 複数行の文字列に変換し、生の文字列リテラルを使用しないでください）\n\n>\n\n>/refactor into a multi-line written string. Make the table name\nparametrizable\n\n>\n\n>（/refactor 複数行の書き込み文字列に変換してください。テーブル名はパラメータ化してください）\n\n\n`stringstream` タイプの代替アプローチは、[GitLab\nDuoコーヒーチャット：抽象的なデータベース処理のためにC++関数をOOPクラスにリファクタリングする](https://www.youtube.com/watch?v=Z9EJh0J9358)、[MR差分](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-coffee-chat/gitlab-duo-coffee-chat-2024-01-23/-/commit/7ea233138aed46d77e6ce0d930dd8e10560134eb#4ce01e4c84d4b62df8eed159c2db3768ad4ef8bf_33_35)に記載されています。\n\n\n#### 脆弱性の説明\n\n\n常に機能するとは限りませんが、セキュリティの脆弱性の説明については、`/explain` スラッシュ(/)\nコマンドも尋ねることができます。この例では、[Cコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c)には、strcpy()バッファオーバーフロー、ワールド書き込み可能なファイルアクセス許可、競合条件攻撃などの複数の脆弱性が含まれています。\n\n\n>/explain why this code has multiple vulnerabilitie\u003Cbr>\n\n>（/explain このコードに複数の脆弱性がある理由を説明してください）\n\n\n![/コードの複数の脆弱性についてのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image20.png)\n\n\n#### CコードをRustにリファクタリングする\n\n\nRustはメモリの安全性を提供します。`refactor into Rust`\nを使用して、脆弱な[Cコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c)をRustにリファクタリングするようにDuo\nChatに依頼できます。より良い結果を得るために、より洗練されたプロンプトで練習してください。\n\n\n> /refactor into Rust and use high level libraries\n\n> \n\n> （/refactor Rustに変換し、高レベルのライブラリを使用してください）\n\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image8.png)\n\n\n### ショートカット\n\n\nこれらのショートカットを読者の環境で試し、GitLab Duoチャットを使用して応用例を試してみてください。\n\n\n1. CVEからの脆弱性に基づいてコードを調べ、`/explain why is this code vulnerable`\nを使用して、それが何をし、どのように修正するかを尋ねます。\n\n**ヒント：** GitLab Duoチャットのコード説明を利用するには、GitLabでオープンソースプロジェクトをインポートしてください。\n\n2. レガシーコードの移行計画を支援するために、コードを新しいプログラミング言語にリファクタリングしてみてください。\n\n3. `/refactor into GitLab CI/CD configuration` を使用して、Jenkins設定をGitLab\nCI/CDにリファクタリングすることもできます。\n\n\n### 試してみよう\n\n\nクリッピーのように振る舞うよう、チャットを説得してみてください。\n\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image22.png)\n\n\nGitLabのミッション、「誰でも貢献できます」について尋ねてください。\n\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image33.png)\n\n\n### 詳細\n\n\nいろいろなところに情報が記載されています。より実用的な例で[GitLab\nDuoチャットドキュメンテーション](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)を更新し、チャットを含むAI搭載のDevSecOpsワークフローを深く掘り下げる新しい[GitLab\nDuoの例](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html)セクションを追加しました。\n\n\nGitLab Duoの学習は、遊び心のあるチャレンジと実際の本番環境のコードを通じて最も効果的に機能します。新しい学習シリーズ、GitLab\nDuoコーヒーチャットは、2024年も続きます。本人確認ができるまでは、[このYouTubeプレイリスト](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp5uj_JgQiSvHw1jQu0mSVZ)で録画を見ることができます。GitLabのお客様で、GitLab\nDuoコーヒーチャットに参加して一緒に学ぶことに興味がある場合は、[この計画のエピック](https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/476)でお知らせください。\n\n\n*監修：小松原 つかさ\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n\n> GitLab\nDuoチャットを試してみませんか？[今すぐ無料トライアルを開始](https://about.gitlab.com/solutions/gitlab-duo-pro/self-managed-and-gitlab-dedicated-trial/)。\n",[676,2378,1410,721,702],{"slug":3320,"featured":92,"template":681},"develop-c-unit-testing-with-catch2-junit-and-gitlab-ci","content:ja-jp:blog:develop-c-unit-testing-with-catch2-junit-and-gitlab-ci.yml","Develop C Unit Testing With Catch2 Junit And Gitlab Ci","ja-jp/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci.yml","ja-jp/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci",{"_path":3326,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3327,"content":3332,"config":3337,"_id":3339,"_type":16,"title":3340,"_source":17,"_file":3341,"_stem":3342,"_extension":20},"/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"title":3328,"description":3329,"ogTitle":3328,"ogDescription":3329,"noIndex":6,"ogImage":1481,"ogUrl":3330,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3330,"schema":3331},"GitLab Duo Workflowの紹介 - AI主導の開発の未来","自律型AIエージェントであるWorkflowは、チームがソフトウェアを構築してデリバリーする方法に変革をもたらします。Workflowの登場により、GitLabはAI主導のDevSecOpsの実現に向けた強力な最初の一歩を踏み出します。","https://about.gitlab.com/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Workflowの紹介 - AI主導の開発の未来\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2024-06-27\",\n      }",{"title":3328,"description":3329,"authors":3333,"heroImage":1481,"date":3334,"body":3335,"category":787,"tags":3336,"updatedDate":3060},[1448],"2024-06-27","ソフトウェアのコードを、ソフトウェア自らが作成できるとしたらどうでしょう？それは遠い未来でしか実現できないことのように思えますが、絶えず成長する大規模言語モデル（LLM）とGitLabの一元化されたAI搭載のDevSecOpsプラットフォームにより、その未来は間近に迫っています。GitLabは、[GitLab 17のリリースイベント](https://about.gitlab.com/seventeen/)でGitLab Duo Workflowについて発表しました。GitLab Duo Workflowは、チームがソフトウェアのビルド、保護、デプロイ、モニタリングする方法に変革をもたらす自律型AIエージェントです。\n\nGitLab Duo Workflowは、ソフトウェア開発ライフサイクルのあらゆる側面の最適化に積極的に貢献する自律的なチームメンバーを作り出し、プロンプトベースで受け身でしかなかったAIアシスタントのこれまでの状況を刷新します。Workflowが特に優れている点は、関連するすべてのデータ、プロジェクト、リポジトリ、ドキュメントをシームレスにつなげるGitLabの統合されたデータストアを活用していることです。これにより、Workflowはインテリジェントで常時稼働するエージェントとして、プロジェクトの常時モニタリング、本番環境で起こりうる問題の予測、自動的な脆弱性の特定・修正、パフォーマンスの最大化を目的としたアプリケーションの最適化、カスタマイズされたリモート開発環境の迅速な構築によるオンボーディングの効率化をすることができます。\n\n今やAIにより、安全なソフトウェアの開発、メンテナンス、更新、デプロイ、モニタリングの方法が変容し、従来よりも多くのソフトウェアをデリバリーできるようになっています。GitLab Duo Workflowは、AI主導のDevSecOpsの実現に向けた強力な第一歩です。当社は、[GitLab Duo](https://about.gitlab.com/gitlab-duo/)によって繰り返しの作業を処理し、外からは見えない部分を最適化することで、デベロッパーが高度な問題解決や価値創造に注力できるようにすることを目指しています。\n\n## GitLab Duo Workflowのビジョン\nGitLab Duo Workflowでは、いくつかの主要なユースケースに重点的に取り組むことで、ソフトウェア開発プロセス全体を自動化および最適化しています。\n### 1. 開発の自動化\n\nGitLab Duo Workflowは、IDE上で直接、個々のプロジェクトや定義済みの組織プロセスに合わせたタスクを計画や、優先順位付けを支援します。特定の作業アイテム（エピックやイシュー、タスクなど）の要件に基づき、デベロッパーがレビューした上で改良できる実装計画を作成します。その後、Workflowは計画に沿って作業を進め、定義された要件を達成できるように、コードの生成または修正を行います。Workflowではこれらの処理が[GitLabリモート開発ワークスペース](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/)内で行われるため、安全かつ確実にコード変更の記述、評価、テストが実施されます。また、これにより、Workflowが要件を満たすだけでなく、セキュリティスキャンを含むすべてのCIパイプラインテストに通るコードを生成することも保証されます。パイプラインが失敗した場合、Workflowは自動的に問題に対処し、必要に応じてトラブルシューティングを行い、組織の基準を満たす高品質のコードのみが作成され、プロジェクトにコミットされるようにします。\n\n準備ができたら、Workflowはコード変更をまとめたマージリクエストを自動的に作成し、コードのレビュアーや管理者とのやり取りなど、マージリクエストの承認プロセスを実行します。人間のレビュアーが現在行っているように、Workflowにコードをレビューさせて、マージリクエストにコメントを残させるよう指示することすら可能です。さらに、必要に応じてWorkflowは提案内容を実装することもできます。そして、これはまだ始まりに過ぎません。\n\n### 2. インテリジェントな継続的改善\nGitLab Duo Workflowは、コードベースをリアルタイムで分析し、効率、パフォーマンス、コスト削減を向上させるためにアーキテクチャの最適化を提案します。さらに、デベロッパーに対して変更を提案したり、サンドボックス環境に変更を自動的に実装することで、スケーラビリティを向上させ、技術的負債に対処するためのコードリファクタリングの機会を積極的に特定します。また、Workflowはクラウドリソースを動的に管理して、オーバープロビジョニングを回避し、アプリケーションが常にパフォーマンス目標を満たせるようにします。\n\n### 3. 積極的なセキュリティとコンプライアンス対応\nどのような組織においても、セキュリティとコンプライアンスは最優先事項です。GitLab Duo Workflowは、パッチの適用や脆弱なコードのリファクタリングに加え、新たに出現する脅威にリアルタイムで対応するよう、デベロッパーに対して自動的に指示を出します。さらに、アプリケーションと本番環境に関連するセキュリティリスクを継続的に評価し、軽減策の実装を支援します。\n\n### 4. パフォーマンスの向上に向けた自己最適化\nGitLab Duo Workflowには、継続的な学習と改善を行うために高度なフィードバックループが組み込まれています。モニタリングツールやユーザーとのやり取り、ビジネス成果から得たデータの分析を通じて、アプリケーションのアーキテクチャがビジネスニーズに常に合致するように、コードベースを絶えず改善します。すべてのAIと同様、Workflowは絶えず改善され、組織のパートナーとして成長しながら、自らのミスを見つけて、修正できるようになります。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://player.vimeo.com/video/967982166?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allowfullscreen=\"true\" title=\"GitLab Duo Workflow the future of AI-driven DevSecOps\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n## 未来のAIはすでに現実に\nGitLab Duo Workflowの登場は、常に人間が指示する必要があったAIから、必要なときにのみ人間の指示を受けて開発のワークフローとプロセスを推進するAIへと移行する、大きな前進を意味します。DevSecOpsライフサイクルをカバーするGitLabの統一されたAI主導のインターフェイスを利用することで、最高水準のセキュリティとコンプライアンスを維持しながら、他に類を見ないスピード、効率性、イノベーションを実現して、新世代のAI搭載型アプリケーションを開発できます。その際に、トレードオフが生じることはありません。\n\nGitLabでは今後もソフトウェア開発においてAIができることの範囲を広げていきますので、インサイトや最新情報をお見逃しなく。一緒にAI主導のDevSecOpsの未来に進み、チームと組織の可能性を最大限に解き放ちましょう。\n\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n> AI主導のDevSecOpsに関心があり、ぜひプレリリースプログラムに参加して体験してみたいという方は、[GitLab Duo Workflowウェイティングリスト](https://forms.gle/5ppRuNVb8LwSPNVJA)にご登録ください。\n",[721,904,702,700,677],{"slug":3338,"featured":92,"template":681},"meet-gitlab-duo-workflow-the-future-of-ai-driven-development","content:ja-jp:blog:meet-gitlab-duo-workflow-the-future-of-ai-driven-development.yml","Meet Gitlab Duo Workflow The Future Of Ai Driven Development","ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development.yml","ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"_path":3344,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3345,"content":3351,"config":3358,"_id":3360,"_type":16,"title":3361,"_source":17,"_file":3362,"_stem":3363,"_extension":20},"/ja-jp/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"title":3346,"description":3347,"ogTitle":3346,"ogDescription":3347,"noIndex":6,"ogImage":3348,"ogUrl":3349,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3349,"schema":3350},"2024年グローバルDevSecOps調査で明らかになった、3つの注目すべき結果","今年の調査では、AIが台頭する中、組織における投資の優先分野が変化し、AIによりチームの働き方にどのような影響が生じているかが明らかになりました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751993603/Blog/Hero%20Images/fy25-global-devsecops-report-blog-image.png","https://about.gitlab.com/blog/3-surprising-findings-from-our-2024-global-devsecops-survey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2024年グローバルDevSecOps調査で明らかになった、3つの注目すべき結果\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-06-25\",\n      }",{"title":3346,"description":3347,"authors":3352,"heroImage":3348,"date":3353,"body":3354,"category":3355,"tags":3356},[1327],"2024-06-25","[世界各地のDevSecOpsの専門家5,000名を対象に行われた今年の調査](https://about.gitlab.com/ja-jp/developer-survey/)は、組織がAIなどの新しい技術を導入する中、投資の優先分野を見直していること、またデベロッパーエクスペリエンスを向上させる方法をより入念に検討していることが示唆される結果となりました。この記事では、今年の調査で明らかになったさらに驚くべき3つの結果を紹介し、それらが2024年以降、ソフトウェアの開発、オペレーション、セキュリティを担当するチームにとって何を意味するのかを見ていきます。\n\n## 1. AIにより煩雑なツールチェーンの欠点が浮き彫りに\n\n今年の調査では、AIが既存のツールチェーンに対するDevSecOpsチームの意識にどのような影響を与える可能性があるかについて、特に注目しました。その結果、やや意外な事実が判明しました。AIによりソフトウェア開発を簡素化できることはご存知のとおりですが、調査の結果、現在AIを使用している回答者は、AIを使用していない回答者よりもツールチェーンに不満を感じている可能性があることが判明しました。\n\n現在AIをソフトウェア開発に使用している組織の回答者の4分の3近く（74%）が、またAIを使用していない組織の回答者の57%がツールチェーンを統合したいと回答しています。ただし、2つのグループ間で回答者が使用していると報告したツールの数に大きな差はありませんでした。つまり、現在AIを使用している回答者は、より多くのツールを使用しているわけではないものの、ツールチェーンを統合する必要性を強く感じていました。\n\nAIの使用が統合への欲求を加速させるのは一体なぜでしょうか？1つ考えられる理由として、さまざまなポイントソリューションで異なるAIモデルが実行されたために、ソフトウェア開発ライフサイクルにおいて手に負えない（かつ測定不能な）無秩序の状態が生じ、組織の煩雑で非生産的な既存のツールチェーンの欠点が浮き彫りになったことが挙げられます。組織がAIへの投資を増やすにつれ、乱立するツールチェーンの統合・簡素化することで効率性を向上させる必要性が高まります。ツールチェーンの規模が小さいほどチームがAIから得られる価値は大きくなり、ソフトウェア開発ライフサイクル全体でAIの統合が容易になります。\n\n今年のソフトウェア開発における最大の課題は、「（AIツールを含む）ツールの数とコンテキストスイッチ（頭の切り替え）が多すぎる」ことだと答えた回答者がいる一方、別の回答者は「全社的にさまざまなツールが断片化されていて複雑な状況」 であることだと述べています。\n\nさらに、別の回答者は次のように述べ、AIによってツールチェーンの課題を解決できる可能性を強調しました。「AIは急成長しており、AIを統合することによって既存のツールチェーンは大幅に改善できます。チームメンバーをさらにトレーニングし、日々の業務で効果的にAIを活用する方法を学んでもらう必要があります」\n\n## 2. AIによりデベロッパーのオンボーディング時間は短縮されるものの、依然として懸念を抱く組織\n\n今年の調査では、チームで使用されるツール数の増加に伴い、デベロッパーのオンボーディング（新しく組織やチームに加入したメンバーが活躍できるように体制を整えること）にかかる時間も大幅に増加していることがわかりました。今年は70%の回答者が自社のデベロッパーのオンボーディングと生産性向上には1か月以上かかると述べており、2023年の66%から増加しました。\n\nAIを活用した[チャットアシスタント](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/)や[コード提案](https://about.gitlab.com/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo/)を使用すれば、デベロッパーのオンボーディング時間を短縮できることは当然ですが、今回の調査では驚くべき効果が明らかになりました。ソフトウェア開発にAIを使用していると答えた回答者は、デベロッパーのオンボーディングには通常1か月未満しかかからないと答える傾向がより強く見られました。\n\nAIがデベロッパーエクスペリエンスにもたらすメリットは明白であるものの、回答者はAIの急速な採用に関して、いくつか懸念を表明しました。回答者の半数以上（55%）が、ソフトウェア開発ライフサイクルへのAIの導入にはリスクが伴うと述べており、49%は今後5年以内に現在の職務をAIに取られることを危惧していると答えています。\n\n業界リサーチ会社であるRedMonk社のシニアアナリスト、Rachel Stephens氏は、これらの調査結果について次のような見解を述べています。「AIをどのように感じるかには、心理的安全性とチームの文化といった要素が影響を及ぼします。人々はセキュリティやAIによるプライバシーへの影響を心配している可能性がある一方、準備できていないという意識は、AIにより自分の生業に個人的なリスクが生じるという考えが根底にあるのかもしれません」\n\nGitLabでは、AIの価値は、繰り返しの作業を自動化し、外からは見えない部分を最適化することで、チームメンバーが高度な問題解決、イノベーション、価値創造に集中できるようになることだと考えています。AIは、ソフトウェア開発における人的要素を置き換えるわけでなく、補完するものです。ある回答者は、このことを次のように簡潔に言い表しました。「私たちは、AIに頼りながら創造力を育み維持していくという課題に直面しています。あくまでAIは、クリエイティブな人たちが生産性の妨げとなる不要なものを排除するために使用するツールの1つであることを忘れてはなりません。人間の創造力に取って代わるものではないのです」\n\n## 3. クラウドはあって当たり前の存在に\n\nGitLabが実施した調査では、クラウドコンピューティングは過去数年間一貫してIT投資分野の上位にランクインしています。2022年には、クラウドコンピューティングはセキュリティに次いで2位にランクインし、2023年は1位という結果になりました。これは、組織に対する[デジタルトランスフォーメーション](https://about.gitlab.com/blog/lockheed-martin-aws-gitlab/)へのプレッシャーが高まっている現状を考えると、当然のことです。\n\nしかしながら、2024年にはクラウドコンピューティングは大幅に順位を落とし、IT投資分野で5位という結果となりました。その一方で、クラウドが引き続き重要な要素であることは明らかです。実際に、アプリケーションの50%以上をクラウドで実行していると答えた回答者数は大幅に増加しました。これは、クラウドが多くの企業にとって依然として業務や使命の達成において不可欠である一方、その存在は「あって当たり前」のものとして、技術チームとITリーダーの優先事項にその他の新しい要素が追加され続けていることを示唆しています。\n\nRedMonk社のStephens氏は、次のように述べています。「通常、資金面で制約のある財務環境にあることから、テクノロジーに投資する際には優先順位を決める必要があります。そのため、組織はデジタルトランスフォーメーションに関する予算の一部をAIなどのテクノロジーに再配分することがあっても、そのすべてが使われるわけではないのです。」\n\n## 今年のレポートを確認しよう\n\nAIやセキュリティ、デベロッパーエクスペリエンスなど、さまざまなインサイトを得られる[2024年グローバルDevSecOps調査](https://about.gitlab.com/ja-jp/developer-survey/)の全文をぜひご覧ください。","insights",[3357,702,721,722,700],"developer survey",{"slug":3359,"featured":6,"template":681},"3-surprising-findings-from-our-2024-global-devsecops-survey","content:ja-jp:blog:3-surprising-findings-from-our-2024-global-devsecops-survey.yml","3 Surprising Findings From Our 2024 Global Devsecops Survey","ja-jp/blog/3-surprising-findings-from-our-2024-global-devsecops-survey.yml","ja-jp/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"_path":3365,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3366,"content":3372,"config":3376,"_id":3378,"_type":16,"title":3379,"_source":17,"_file":3380,"_stem":3381,"_extension":20},"/ja-jp/blog/gitlab-16-11-released",{"title":3367,"description":3368,"ogTitle":3367,"ogDescription":3368,"noIndex":6,"ogImage":3369,"ogUrl":3370,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3370,"schema":3371},"GitLab 16.11リリース","GitLab 16.11でリリースした最新機能をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662118/Blog/Hero%20Images/16_11-cover-image.png","https://about.gitlab.com/blog/gitlab-16-11-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 16.11リリース\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-06-20\",\n      }",{"title":3367,"description":3368,"authors":3373,"heroImage":3369,"date":3374,"body":3375,"category":701,"updatedDate":3353},[738],"2024-06-20","__「GitLab Duo Chat」をGitLab 16.11に統合して一般提供開始__\n\n本日、一般提供された[GitLab Duoチャット](https://about.gitlab.com/releases/2024/04/18/gitlab-16-11-released/#gitlab-duo-chat-now-generally-available)および[プロダクト分析やセキュリティポリシーのスコーピング](https://about.gitlab.com/releases/2024/04/18/gitlab-16-11-released/#understand-your-users-better-with-product-analytics)、その他多くの機能が含まれるGitLab 16.11のリリースを発表します。\n\nこれらの機能は、このリリースで追加された40を超える新機能のほんの一部です。お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLabコミュニティメンバーのみなさま、GitLab 16.11に190件以上のコントリビュートをしてただきありがとうございました！GitLabでは[誰でもコントリビュートできます](https://about.gitlab.com/community/contribute/)。みなさまのご協力なしでは実現できませんでした。\n\n来月のリリースで予定されている内容をプレビューするには、17.0リリースのキックオフビデオもご覧いただける[今後のリリースページ](https://about.gitlab.com/direction/kickoff/)をご覧ください。\n\n## 今月のMost Valuable Person（[MVP](https://about.gitlab.com/community/mvp/)）を[Ivan Shtyrliaiev](https://gitlab.com/bahek2462774)さんと[Baptiste Lalanne](https://gitlab.com/BaptisteLalanne)さんに共同で授与\n\n[Ivan Shtyrliaiev](https://gitlab.com/bahek2462774)さんは、2024年にGitLabに[6件コントリビュート](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&state=merged&author_username=bahek2462774)しました。Ivanさんは、GitLabのプリンシパルプロダクトマネージャー、[Hannah Sutor](https://gitlab.com/hsutor)によって推薦され、[ユーザーリストの検索とフィルタリング体験の向上に大きく貢献しました](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144907)。\n\n「これはユーザーエクスペリエンスの大幅な改善です。横方向にスクロール可能なリストから、2つのタブと検索ボックスのみのすっきりとしたUXに移行できました」とHannahは述べています。「ユーザーはタブを横方向にスクロールせずに、検索ボックスを使って絞り込みが可能になりました！」\n\nIvanさんは、この難しいリクエストを担当し、GitLab UXチームと協力して提案をブラッシュアップし、レビューにすばやく対応したことが評価されました。GitLabのエンジニアリングマネージャーの[Adil Farrukh](https://gitlab.com/adil.farrukh)も、この機能は重要で、Ivanさんがフィードバックに迅速に対応してくださったと述べており、推薦を支援しています。GitLabのフロントエンドエンジニアの[Eduardo Sanz García](https://gitlab.com/eduardosanz)もまた、Ivanさんの推薦を支援しており、彼の適応能力についてコメントしています。\n\n「Eduardoさんのレビューに加え、GitLabチームがコントリビュートを実現するために尽力してくれたことに心から感謝しています」とIvanさんは述べています。「とても助かりましたし、実際にかかる時間が実感できました」\n\nIvanさんは、[Politico社](https://www.politico.com/)のフロントエンドソフトウェアエンジニアです。\n\n[Baptiste Lalanne](https://gitlab.com/BaptisteLalanne)さんは、3年前に作成され、70件近くの同意が寄せられていたイシューを担当し、CI/CD設定に `retry:exit codes` を追加する[非常にリクエストの多かった機能](https://gitlab.com/gitlab-org/gitlab/-/issues/262674)にコントリビュートしました。このコントリビュートにより、失敗したパイプラインジョブやexitコードが異なるジョブをユーザーがより柔軟に管理できるようになりました。\n\nBaptisteさんは、GitLabのプロダクトマネージャーの[Dov Hershkovitch](https://gitlab.com/dhershkovitch)が推薦しました。「このプロジェクトに対するBaptisteさんの勤勉な取り組みは、単なる実装とはかけ離れていました」とDovは述べています。「今回の成果は、GitLabコミュニティにおける共同作業の強みの代表的な例です。Baptisteさんの努力により、GitLabにおいて重要なニーズを満たすだけでなく、オープン性と透明性に対する取り組みに加え、オープンコアの精神を強化できました」\n\n「今回の受賞は心温まることであり、大変感謝しています」とBaptisteさんは述べています。「とても楽しいので、これからも空いている時間にコントリビュートしていきたいです」\n\n過去1年間で、Baptisteさんは6つのマージリクエストをGitLabにマージしました。次は、[GitLab Runnerにコントリビュートすること](https://docs.gitlab.com/runner/development/)を楽しみにしているそうです。Baptisteさんは、[DataDog社](https://www.datadoghq.com/)のソフトウェアエンジニアです。\n\n新たなMVPであるIvanさんとBaptisteさん、そしてその他のGitLabコミュニティのコントリビューターのみなさまに心から感謝申し上げます！🙌\n\n## GitLab 16.11でリリースされた主な改善点\n\n### GitLab Duoチャットを一般提供\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\nGitLab Duoチャットが[一般提供](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#generally-available-ga)されました。また、本リリースでは、以下の機能も一般公開します。\n- コードの提案機能で、開発者やあまり技術の知識を持たないユーザーがなじみのないコードをより早く理解できます\n\n- コードリファクタリング機能で、開発者が既存のコードを簡素化して改善できます\n- テスト生成機能で、反復的なタスクを自動化し、チームがバグを早期に発見できます\n\nユーザーは、GitLab UI、Web IDE、VS Code、またはJetBrains IDEからGitLab Duoチャットにアクセスできます。\u003Cbr>\n\n本リリースのGitLab Duoチャットの詳細については、こちらの[ブログ記事（英語）](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/)をご覧ください。\u003Cbr>\n現在、チャットはUltimateとPremiumのユーザーが利用できます。インスタンス管理者、グループオーナー、およびプロジェクトオーナーは、[Duo機能によるデータのアクセスおよび処理の制限設定](https://docs.gitlab.com/ee/user/ai_features.html#disable-gitlab-duo-features-for-specific-groups-or-projects-or-an-entire-instance)ができます。\n\nGitLab Duoチャットは、[GitLab Duo Pro](https://about.gitlab.com/gitlab-duo/#pricing)の一部です。GitLab Duo Proをまだ購入されていないユーザーのチャットのベータ版の移行を容易にするために、PremiumおよびUltimateをご利用のお客様を対象に、引き続きDuoチャットを（アドオンなしで）短期間提供します。Duo Proをサブスクライブされている方のみにアクセスが制限される時期については、後日お知らせします。\n\nチャット内のフィードバックボタンをクリックするか、イシューを作成してGitLab Duoチャットにメンションして、ぜひご意見をお聞かせください。みなさまからのフィードバックをお待ちしています！\u003Cbr>\n\n[ドキュメント](https://gitlab.com/groups/gitlab-org/-/epics/13516)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13516)\u003Cbr>\n\n\u003Ciframe width=\"1046\" height=\"588\" src=\"https://www.youtube.com/embed/ZQBAuf-CTAY\" title=\"GitLab Duo Chat\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### JetBrains IDEでGitLab Duoチャットが利用可能に\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nJetBrains IDEでGitLab Duoチャットをご利用いただけるようになりました。\u003Cbr>\n\nGitLabのAI機能の一環であるDuoチャットは、対応しているJetBrains IDEにインタラクティブなチャットウィンドウに加え、コードの説明、テストの記述、および既存のコードのリファクタリングの機能を直接提供することで、開発者は効率的に作業ができます。\u003Cbr>\n\n機能の完全なリストについては、[Duoチャットのドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)をご覧ください。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/editor_extensions/jetbrains_ide/index.html)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/issues/307)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/create-duo-chat-in-jetbrains.png\">\n\n### セキュリティポリシーのスコープ\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nポリシーのスコープにより、きめ細かい管理とポリシーの適用を実現します。この新機能を使用すると、セキュリティチームおよびコンプライアンスチームは、マージリクエストの承認（スキャン結果）ポリシーとスキャン実行ポリシーの両方において、ポリシーの実施範囲をコンプライアンスフレームワークまたはグループに含まれるまたは除外されるプロジェクトに設定できます。\u003Cbr>\n\n現在、セキュリティポリシープロジェクトで管理されているすべてのポリシーは、リンクされているすべてのグループ、サブグループ、およびプロジェクトに対して実施されていますが、ポリシーのスコープを使用すれば、ポリシー単位で実施ポリシーを設定できるようになります。これにより、セキュリティチームとコンプライアンスチームは以下を行えるようになります。\n\n- ポリシーをより細かく実施しながら、組織全体でポリシーを一元管理しやすくなります\n\n- GitLabで実装および実施されているコントロールが、定義したコンプライアンスフレームワークにどのように組み込まれているかをより深く把握できます\n- コンプライアンスセンターから、コンプライアンスフレームワークにリンクされているポリシーを閲覧および管理できます\n- セキュリティとコンプライアンスの体制をよりよく整理し、把握できます\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#security-policy-scopes)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/5510)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/policy-scoping-release-post-image-optimized.png\">\n\n### プロダクト分析を使用してユーザーについて理解を深める\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\n今後のイノベーションと最適化についてデータに基づいた意思決定を行うためには、ユーザーがアプリケーションにどのように関わっているかを理解することが不可欠です。ビジネスに不可欠なクリティカルURLの使用量が増加しているか、毎月のアクティブユーザー数が異常なほど減少しているか、またはAndroidのモバイルデバイスを使用するお客様によるエンゲージメントが増えているか、といった質問への回答を得て、GitLabプラットフォームからエンジニアリングチームがアクセスできるようにすることで、チームは開発作業がユーザーの成果にどのように影響しているかを常に把握できるようになります。\n\nGitLabの新しいプロダクト分析機能を使用すると、アプリケーションを計測し、ユーザーの主要な使用状況と導入データを収集して、GitLab内に表示できます。データをダッシュボード上に表示したり、レポートを作成したりできるほか、さまざまな方法でフィルタリングして、ユーザーに関するインサイトを見つけられます。これにより、最近のリリースの成功を祝うだけでなく、問題があることを意味する顧客使用率の予期せぬ低下や急増を迅速に特定して対応できるようになりました。\n\nプロダクト分析を使用するには、こちらの[Helm Chart](https://gitlab.com/gitlab-org/analytics-section/product-analytics/helm-charts)をインストールし、アプリケーションを計測してトラフィックを送信するために、Kubernetesクラスターが必要となります。その後、GitLabはクラスターに接続し、視覚化のためにデータを取得します。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/product_analytics/)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12716)\u003Cbr>\n\n\u003Ciframe width=\"478\" height=\"269\" src=\"https://www.youtube.com/embed/i8Mze9lRZiY\" title=\"Product Analytics release video\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### エンタープライズユーザーのパーソナルアクセストークンを無効にする\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: -\u003Cbr>\n\nGitLab.comのグループオーナーは、グループ内のエンタープライズユーザーがパーソナルアクセストークンを作成・使用することを無効にできるようになりました。パーソナルアクセストークンは強力な権限が付与させることがあるため、セキュリティ上の理由により、これらのトークンを無効化したいオーナーもいるでしょう。\u003Cbr>\nこのきめ細かい制御により、GitLab.comでセキュリティとアクセシビリティのバランスを取るための選択肢が提供されます。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#disable-personal-access-tokens-for-enterprise-users)\u003Cbr>\n[イシュー\n](https://gitlab.com/gitlab-org/gitlab/-/issues/369504)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/govern-disable-pats.jpg\">\n\n### Wikiページへのリンクのオートコンプリートサポート\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLab 16.11でWikiページへのリンクのオートコンプリートサポートが導入されます！この新機能により、エピックやイシューからWikiページにリンクすることがかつてないほど簡単になりました。キーを数回クリックするだけでリンクできます。\u003Cbr>\n\nもうWikiページのURLをコピーして、エピックやイシューのコメントに貼り付ける必要はありません。今後は、Wikiページのあるグループやプロジェクトに移動し、エピックやイシューにアクセスし、オートコンプリートのショートカットを使用して、エピックやイシューからWikiページにシームレスにリンクするだけです！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/markdown.html#gitlab-specific-references)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/442229)\u003Cbr>\n\n\u003Ciframe width=\"478\" height=\"269\" src=\"https://www.youtube.com/embed/qqN6KxMB06E\" title=\"Knowledge Group: Introducing Autocomplete Support for Wiki Pages\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n### プロジェクト概要ページに表示されるメタデータ用のサイドバー\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nプロジェクト概要ページのデザインを一新しました。これにより、すべてのプロジェクト情報とリンクが複数のエリアに表示されるのではなく、1つのサイドバーで確認できるようになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/working_with_projects.html)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/429186/)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/431537)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/project-overview-sidebar.png\">\n\n### Switchboardを用いて行った変更に関するメール通知\nSaaS: -\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nテナント管理者がSwitchboardを使用してGitLab Dedicatedインスタンスの設定を変更すると、完了時にメール通知が生成されるようになりました。\u003Cbr>\n\nSwitchboardでテナントを表示または編集するアクセス権を持つすべてのユーザーに、変更が行われるたびに通知が送信されます。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/dedicated/configure_instance.html#manage-notification-preferences)\u003Cbr>\n[イシュー](https://about.gitlab.com/direction/saas-platforms/switchboard/#fy25-q1)\n\n### ジョブの失敗時に直ちにパイプラインをキャンセルするオプション\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nジョブが失敗したことに気づいた場合、失敗の原因である問題に対処する間、リソースを節約するために手動で残りのパイプラインをキャンセルすることがあります。GitLab 16.11では、ジョブが失敗した際に自動的にパイプラインがキャンセルされるように設定できるようになりました。特に並行して多数のジョブが長時間実行される、実行に長時間かかる大規模なパイプラインでは、リソースの使用量とコストを削減する効果的な方法として利用できます。\u003Cbr>\n\n[ダウンストリームのパイプラインが失敗した場合に直ちにパイプラインがキャンセルされる](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html#auto-cancel-the-parent-pipeline-from-a-downstream-pipeline)ように設定することも可能です。この場合、親パイプラインと他のすべてのダウンストリームのパイプラインがキャンセルされます。\u003Cbr>\n\nこの場を借りて、この機能にコントリビュートしてくれた[Marco](https://gitlab.com/zillemarco)さんに心から感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/yaml/#workflowauto_cancelon_job_failure)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/23605)\u003Cbr>\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/16.11_auto_cancel_on_job_failure.png\">\u003Cbr>\n\n## GitLab 16.11におけるその他の改善点\n\n### インポートジョブの上限を設定可能に\n\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nこれまでインポートジョブの最大数は以下のとおりでした。\u003Cbr>\n\n- GitHubインポーターは1,000件でした。\n- Bitbucket CloudとBitbucket Serverのインポーターは100件でした。\n\n上記の制限はハードコーディングされており、変更できませんでした。これらの制限により、キューに追加されるのと同じタイミングでインポートジョブを処理するには処理速度が不十分であった可能性があり、結果としてインポート速度が低下していたかもしれません。\u003Cbr>\n\n今回のリリースでは、ハードコーディングされていた制限をアプリケーション設定に移行しました。GitLab.com版では上限を上げていませんが、Self-Managed版のGitLabインスタンスの管理者は、ニーズに応じてインポートジョブの数を設定できるようになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#maximum-number-of-simultaneous-import-jobs)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/439286)\n\n### Slackアプリ用GitLabがグループとインスタンスで設定可能に\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nこれまでSlackアプリ用GitLabは、一度に1つのプロジェクトに対してしか設定できませんでした。本リリースでは、グループまたはインスタンス向けのインテグレーションを設定し、複数のプロジェクトに一度に変更を加えられるようになりました。\u003Cbr>\n\nこの改善により、Slackアプリ用GitLabの機能は、非推奨の[Slack通知インテグレーション](https://docs.gitlab.com/ee/user/project/integrations/slack.html)と同等のレベルに近づきました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#from-the-project-or-group-settings)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/391526)\n\n### GitLab Pagesのサイドバー上での可視性が向上\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n以前のリリースでは、GitLab Pages サイトがあるプロジェクトでサイトURLを見つけるのは大変でした。\nGitLab 16.11からは、右側のサイドバーにサイトへのショートカットリンクが表示され、ドキュメントを確認しなくてもURLを見つけられるようになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/pages/)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/18027)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/gitlab_pages_sidebar.png\">\n\n### 色を用いてエピックを視覚的に区別\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\n組織全体でポートフォリオ管理機能をさらに充実して利用できるように、[ロードマップ](https://docs.gitlab.com/ee/user/group/roadmap/)と[エピックボード](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html)でエピックを色で区別できるようになりました。\u003Cbr>\n\n軽量で用途の広いこの機能を使用すれば、グループの所有権、ライフサイクルステージ、開発の成熟度、その他の様々なカテゴリをすばやく区別できます。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#epic-color)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/9033)\n\n### GitLabからのGoogle Compute Engine Runnerの作成を自動化 - パブリックベータ版\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nこれまでGoogle Compute EngineでGitLab Runnerを作成する際は、GitLabとGoogle Cloudの間で複数回コンテキストを切り替える必要がありました。\u003Cbr>\n\nGitLab RunnerインフラストラクチャのツールキットのterraformテンプレートとGitLabを使用することで、複数のシステム間を移動しなくても、Google Compute EngineでGitLab Runnerを簡単にプロビジョニングして、GitLab Runnerをデプロイし、Google Cloudインフラストラクチャをプロビジョニングできるようになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/runners/provision_runners_google_cloud.html#creating-a-runner-provisioned-in-google-cloud)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13494)\n\n### ArtifactoryとAWSを含む、Hashicorp Vaultのシークレットのサポートを拡張\n\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\nHashiCorp VaultとGitLabのインテグレーションが拡張され、多様なタイプのシークレットに対応できます。GitLab Runner 16.11で導入された'汎用'タイプのシークレットエンジンを選択できるようになりました。この汎用エンジンは、HashiCorp Vaultの[Artifactory Secretsプラグイン](https://jfrog.com/help/r/jfrog-integrations-documentation/hashicorp-vault-artifactory-secrets-plugin)および[AWSシークレットエンジン](https://developer.hashicorp.com/vault/docs/secrets/aws)をサポートしています。このオプションを使用して、必要なシークレットを安全に取得し、GitLab CI/CDパイプラインで使用しましょう！\u003Cbr>\n\nこの素晴らしいコントリビュートをしてくれた[Ivo Ivanov](https://gitlab.com/urbanwax)さんに心から感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/secrets/#vault-secrets-engines)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/366492)\n\n### 特定のexitコードにより、失敗したCIジョブの自動リトライを改善\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nこれまでは `retry:max` に加え、`retry:when` を使用して、スクリプトの失敗時など、特定の失敗が発生した際に、ジョブを何回リトライするかを設定できました。\u003Cbr>\n\n本リリースでは、`retry:exit_codes` を利用して、特定のスクリプトの終了に基づき、失敗したジョブの自動リトライを設定できるようになりました。`retry:exit_codes` とともに `retry:when` および `retry:max` を用いて、特定のニーズに応じてパイプラインの動作を微調整し、パイプラインの実行を改善できます。\u003Cbr>\n\nこの場を借りて、コミュニティへの貢献をしてくれた[Baptiste Lalanne](https://gitlab.com/BaptisteLalanne)さんに感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/yaml/#retry)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/262674)\n\n### Google Artifact RegistryをGitLabプロジェクトに接続\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: -\u003Cbr>\n\nソースコードおよびパイプラインと一緒にDockerイメージとOCIイメージを表示、プッシュ、プルするには、GitLabコンテナレジストリを使用します。この方法はGitLabを使用する多くのお客様にとって、'テスト'および'ビルド'フェーズでのコンテナイメージに最適です。しかし、組織がGoogleなどのクラウドプロバイダーに本番環境のイメージを公開するのは一般的なことです。\u003Cbr>\n\nこれまでGitLabからGoogle Artifact Registryにイメージをプッシュするには、Artifact Registryへに接続して、デプロイ用のカスタムスクリプトを作成し、保守する必要がありました。この方法はエラーが起きやすく、非効率でした。また、簡単にコンテナイメージ全体像を把握する方法もありませんでした。\u003Cbr>\n\nGoogle Artifact管理の新機能を活用して、GitLabプロジェクトをArtifact Registryリポジトリに簡単に接続できるようになりました。接続後、GitLab CI/CDパイプラインを使用して、Artifact Registryにイメージを公開できます。また、GitLabで\u003Cb>デプロイ > Google Artifact Registry\u003C/b>の順に移動すれば、Artifact Registryに公開されたイメージを閲覧できます。イメージの詳細を表示したい場合は、イメージを選択するだけです。\u003Cbr>\n\nこの機能はベータ版であり、現在GitLab.com版でのみ利用できます。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/google_artifact_management.html)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12365)\n\n### GitLab Duoでプロダクト分析データを確認\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\n[プロダクト分析機能が一般](https://about.gitlab.com/releases/2024/04/18/gitlab-16-11-released/#understand-your-users-better-with-product-analytics)提供されました。本リリースには[カスタム可視化デザイナー](https://docs.gitlab.com/ee/user/analytics/analytics_dashboards.html#visualization-designer)があります。カスタム可視化デザイナーを使用して、アプリケーションイベントデータの確認やダッシュボードの構築を行うことができ、顧客の使用状況と導入パターンを理解しやすくなります。\u003Cbr>\n\n可視化デザイナーでは、テキスト形式でリクエストを入力して、GitLab Duoにグラフや表の作成を依頼できます。たとえば、「2024年の月間アクティブユーザー数を表示してください」や「今週の上位URLをリストアップしてください」というように依頼します。\u003Cbr>\n\nプロダクト分析のGitLab Duoは、[実験的な](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment)機能として提供されています。\u003Cbr>\n\n本機能をさらに改善できるよう、こちらの[フィードバック用のイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/455363)から、カスタム可視化デザイナーでGitLab Duoを使用した体験に関するフィードバックをお寄せください。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/product_analytics/)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12245)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/PA_customviz_duo.png\">\n\n### Dependency ScanningでのYarn v4のサポート\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nDependency ScanningがYarn v4に対応しました。この機能強化により、アナライザーでYarn v4のロックファイルを解析できるようになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html#supported-languages-and-package-managers)\u003Cbr>\n[エピック](https://gitlab.com/gitlab-org/gitlab/-/issues/431752)\n\n## ワークロードIDティフェデレーションによりGoogle Cloudを認証\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: -\u003Cbr>\n\nワークロードIDフェデレーションを使用すると、サービスアカウントキーを使用せずにGitLabとGoogle Cloud間でワークロードを安全に接続できます。キーは長期的に使用される認証情報であることから、攻撃の経路となる可能性があるため、これによりセキュリティが改善されました。また、キーを使用する場合、作成、保護、および交換のための管理負荷も発生します。\u003Cbr>\n\nワークロードIDフェデレーションを使用すると、GitLabとGoogle Cloud間でIAMロールをマッピングできます。\u003Cbr>\n\nこの機能はベータ版であり、現在GitLab.com版でのみ利用できます。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/integration/google_cloud_iam.html)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/12758)\n\n### ポリシーボットのコメントを拡張して違反データを追加\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nセキュリティポリシーボットは、プロジェクトでポリシーがいつ実施されたか、いつ評価が完了したか、またMRをブロックする違反がある場合に、解決方法を提供するガイダンスも提示します。この度、ポリシーによってMRがブロックされる理由に関するさらなるインサイトに加え、解決方法についてのよりきめ細かいフィードバックが提供されるように、ボットコメントのサポートを拡張しました。コメントには以下の詳細情報が含まれます。\u003Cbr>\n\n- MRを明確にブロックしているセキュリティの調査結果\n- ポリシーに違反しているライセンス\n- デフォルトで「フェールクローズ」または動作をブロックする可能性のあるポリシーエラー\n- セキュリティの調査結果の評価で考慮されているパイプラインの詳細\n\nこういった詳細情報が提供されることで、MRのステータスをより迅速に把握し、どのような問題であっても自分でトラブルシューティングできるようになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/433403)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/bot-comment-policy-violations.png\">\n\n### ユーザー名の選択肢がさらに豊富に\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nユーザー名には、アクセントなしの文字、数字、アンダースコア（`_`）、ハイフン（`-`）、ピリオド（`.`）のみを使用できます。ユーザー名をハイフン（`-`）で始めたり、ピリオド（`.`）や `.git`、`.atom` で終わらせることはできません。\u003Cbr>\n\nユーザー名の検証時に、この基準がより正確に表示されるようになりました。このように検証機能が改良されたことで、ユーザー名を決める際の選択肢がより明確になりました。\u003Cbr>\n\nこの場を借りて、コントリビュートしてくれた[Justin Zeng](https://www.linkedin.com/in/jzeng88/)さんに感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/#change-your-username)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/429283)\n\n### ユーザーリストの検索とフィルタリングの改善\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n管理者エリアのユーザーページを改善しました。\u003Cbr>\n\nこれまで、ユーザーリストの上部にタブが水平に配置されていたため、目的のフィルターまで移動するのに苦労していました。\u003Cbr>\n\nこの度、フィルターが検索ボックスに統合され、ユーザーの検索とフィルタリングを非常に簡単に行えるようになりました。\u003Cbr>\n\nこの場を借りて、コントリビュートしてくれた[Ivan Shtyrliaiev](https://www.linkedin.com/in/bahek2462774/)さんに感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/administration/admin_area.html#administering-users)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/238183)\n\n### Omnibusの改善\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nGitLab 17.0では、PostgreSQLの最小サポートバージョンが14になる予定です。\u003Cbr>\n\nこの変更に備え、GitLab 16.11では'attempt_auto_pg_upgrade?'の設定を'true'に変更しました。この設定により、PostgreSQLのバージョン14に自動的にアップグレードしようと試行します。\nこのプロセスは、前回PostgreSQLの最小サポートバージョンを更新した際のプロセスと同じものです。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/omnibus/)\n\n### カスタムWebhookヘッダー\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n以前まで、GitLab Webhookはカスタムヘッダーに対応していませんでした。そのため、当時のWbhookは、特定の名前を持つヘッダーの認証トークンを承認するシステムと併用できませんでした。\u003Cbr>\n\nこのリリースにより、Webhookを作成または編集する際に最大20個のカスタムヘッダーを追加できるようになりました。これらのカスタムヘッダーは、外部サービスの認証用に使用できます。\u003Cbr>\n\nこの機能とGitLab 16.10で導入された[カスタムWebhookテンプレート](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#custom-webhook-template)を使用することで、カスタムWebhookを自由に作成できます。設定を行うことで、Webhookを通じて次のことを行えます。\n- カスタムペイロードを投稿する。\n- 必要に応じて認証ヘッダーを追加する。\nシークレットトークンやURLパラメータと同様に、カスタムヘッダーはターゲットURLが変更されるとリセットされます。\u003Cbr>\n\nこの場を借りて、[コミュニティへの貢献](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/146702)をしてくれた[Niklas](https://gitlab.com/Taucher2003)に感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#custom-headers)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/17290)\n\n### REST APIによるプロジェクトテスト用フック\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n以前まで、プロジェクトフックのテストは、GitLab UIでのみ行うことができました。このリリースにより、REST APIを使用して、指定されたプロジェクトのテストフックをトリガーできるようになりました。\u003Cbr>\n\nこの場を借りて、[コミュニティへの貢献](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/147656)をしてくれた[Phawin](https://gitlab.com/lifez)に感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/projects.html#trigger-a-test-project-hook)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/25329)\n\n### バリューストリームイベントの累積計算が可能に\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\n新たなメソッドの導入により、ラベルイベント間の実行時間をより効果的に計算できるようになりました。この変更は、イベントが複数回発生するシナリオに対応するものです。たとえば、マージリクエストでラベルが開発段階とレビュー状態の間を行ったり来たりして変更される場合などです。以前、実行時間は最初と最後のラベルイベント間の時間を合計することで算出されていました。\u003Cbr>\n\n現在、実行時間は累積時間として算出されるようになり、イシューまたはマージリクエストに特定のラベルが割り当てられている場合の実行時間のみを正確に表しています。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#cumulative-label-event-duration)\u003Cbr>\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/12088)\n\n### グループコメントテンプレート\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nイシュー、エピック、またはマージリクエストにおいて、組織全体でテンプレート化された返答文があると便利です。こうしたテンプレートには、標準的な質問、よくある問題の解決策、またはマージリクエストのレビューコメント用のフォーマットなどが含まれます。\u003Cbr>\n\nグループコメントテンプレートでは、GitLab全体のコメントボックスに投稿できる保存可能な返答文を作成し、ワークフローを合理化できます。この新機能により、組織におけるテンプレートの一元的な作成および管理が可能になり、すべてのユーザーが同じテンプレートを活用できるようになります。\u003Cbr>\n\nコメントテンプレートを作成するには、GitLabの任意のコメントボックスに移動し、__「コメントテンプレートを挿入」>「グループコメントテンプレートを管理」__ の順に選択します。作成したコメントテンプレートには、すべてのグループメンバーがアクセスできます。コメント作成時に、__「コメントテンプレートを挿入」__ のアイコンを選択すると、保存された返答文が適用されます。\u003Cbr>\n\nこのコメントテンプレートにおける強化機能をぜひお試しください。また、近日中に[プロジェクトレベルのコメントテンプレート](https://gitlab.com/gitlab-org/gitlab/-/issues/440818)も追加される予定です。フィードバックがございましたら、[イシュー45120](https://gitlab.com/gitlab-org/gitlab/-/issues/451520)でコメントにてお知らせください。\n\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/comment_templates.html)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/440817)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/create-group-comment-templates.png\">\n\n### ジョブアーティファクトのダウンロード権限の管理\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nデフォルトでは、パブリックパイプライン内のCI/CDジョブから生成されたすべてのアーティファクトは、パイプラインへのアクセス権を持つすべてのユーザーがダウンロード可能です。ただし、アーティファクトのダウンロードを一切許可すべきでない場合、または高いアクセスレベルを持ったチームメンバーのみに限定すべき場合もあります。\u003Cbr>\n\nそこで、このリリースでは、`artifacts:access` キーワードが導入されました。ユーザーは、どのユーザーにアーティファクトのダウンロードを許可するか設定（パイプラインへのアクセス権を持つすべてのユーザー、開発者以上のロールを持つユーザーに限定、一切許可しないなど）できるようになりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/yaml/#artifactsaccess)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/428677)\n\n### GitLab Runner 16.11\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\n本日、GitLab Runner 16.11もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、軽量で拡張性の高いエージェントです。 GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\u003Cbr>\n\nバグの修正：\n- [クラッシュ：致命的なエラー：マップの同時読み取りと同時書き込み ](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/31077)\n- [「FF_KUBERNETES_HONOR_ENTRYPOINT」機能が動作しない](https://gitlab.com/gitlab-org/gitlab-runner/blob/16-11-stable/CHANGELOG.md)\n\nすべての変更のリストは、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/16-11-stable/CHANGELOG.md)にあります。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### パイプラインの詳細ページの改善\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nパイプライングラフには、ジョブの状態、ランタイムの更新、マルチプロジェクトパイプライン、親子パイプラインなど、パイプラインの詳細な概要が表示されます。\u003Cbr>\n\n本日、デザインが一新されたパイプライングラフがリリースされます。新しいパイプライングラフは、デザイン性の改善、ジョブのグループ化、モバイル端末での利用体験の向上、既存ビュー内でのダウンストリームパイプラインの可視性の強化を特徴とします。\u003Cbr>\n\nぜひお試しの上、専用の[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/450676)からフィードバックをお寄せいただけますと幸いです。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132462)\n\n### Auto DevOpsのビルド段階におけるアップグレード\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nAuto DevOpsのAuto Buildコンポーネントに使用されていた `heroku/buildpacks:20` イメージがupstreamで非推奨となったため、`heroku/builder:20` イメージに移行します。\u003Cbr>\n\nこの破壊的な変更は、upstreamの問題に対処するためにGitLabのメジャーリリース以外で実施されます。アップグレードが原因でパイプラインが破損する可能性は低いです。一時的な解決策として、手動で `heroku/builder:20` イメージを設定して[ビルダーのサンセットエラー（builder sunset error）](https://docs.gitlab.com/ee/topics/autodevops/troubleshooting.html#skipping-errors)を回避することができます。\u003Cbr>\n\nさらに、GitLab 17.0では、`heroku/builder:20` から `heroku/builder:22` へのメジャーアップグレードが別途予定されています。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/topics/autodevops/troubleshooting.html#builder-sunset-error)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/-/issues/73)\n\n### DASTアナライザーのパフォーマンスの更新\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n16.11リリースのマイルストーンでは、DASTにおける以下の改善が完了しました。\u003Cbr>\n\n- ナビゲーションパスを最適化することで、クローラーのパフォーマンスが向上し、スキャン時間が20%短縮（GitLabのベンチマークテストに基づく）されました。詳細については、イシューを参照してください。\n- DASTレポートを最適化してメモリ使用量を削減することで、DASTスキャン中のランナーのメモリ使用量の上昇率を抑えることに成功しました。詳細については、[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/430815)を参照してください。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dast/browser/)\u003Cbr>\n[イシュー](https://gitlab.com/groups/gitlab-org/-/epics/12194)\n\n### 依存関係スキャンのSBOM用の依存関係グラフのサポート\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nユーザーは、依存関係スキャンレポートの一環で生成されたCycloneDX SBOMの依存関係グラフの情報にアクセスできます。以下のパッケージマネージャーを対象とした依存関係グラフの情報を使用できます。\n\n- NuGet\n- Yarn 1.x\n- sbt\n- Conan\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_list/)\u003Cbr>\n[エピック](https://gitlab.com/gitlab-org/gitlab/-/issues/366168)\n\n### コンプライアンスフレームワークにリンクされたセキュリティポリシーの表示\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nコンプライアンスセンターがコンプライアンスマネージャーにとっての中心的なハブへと進化している今、コンプライアンスフレームワークを管理する機能が備わりました。さらに、セキュリティポリシーによって確立され、コンプライアンスフレームワークに関連付けられた制御情報を可視化することもできます。\u003Cbr>\n\nこれらの包括的な制御性を活用して、コンプライアンスの対象となるプロジェクトで実行するセキュリティスキャナや2人の承認者を必須とする要件を実装したり、脆弱性管理ワークフローを確立したりできます。こうして確立した制御要件をコンプライアンスフレームワークに統合することで、フレームワーク内の関連プロジェクトが各要件に従って実行されるようになります。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html)\u003Cbr>\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/11480)\u003Cbr>\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/cf-security-policy-link.png\">\n\n### セキュリティポリシーの重複に関する問題を解決\n\nSaaS: Ultimate\u003Cbr>\nSelf-Managed: Ultimate\u003Cbr>\n\nGitLab 16.9以前のバージョンでは、プロジェクトが親グループやサブグループのセキュリティポリシーを継承しながら、同じセキュリティポリシープロジェクトにリンクされることがありました。これが原因で、リストに重複したポリシーが表示されていました。\u003Cbr>\nこの問題は解決され、セキュリティポリシープロジェクトからすでにポリシーが継承されている場合、そのプロジェクトにリンクされることはできなくなりました。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/416903)\n\n### APIを使用したアプリケーションシークレットの更新\nSaaS: -\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nアプリケーションAPIを使用して、アプリケーションシークレットを更新できるようになりました。以前は、これを行うにはUIを使用する必要がありましたが、APIを使用して、プログラムに基づいたシークレットの更新を実行できるようになりました。\u003Cbr>\n\nこの場を借りて、貢献してくれた[Phawin](https://gitlab.com/lifez)に感謝します！\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/api/applications.html#renew-an-application-secret)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/422420)\n\n### 期限が迫っているグループおよびプロジェクトのアクセストークンをお知らせするWebhook通知\nSaaS: Premium、Ultimate\u003Cbr>\nSelf-Managed: Premium、Ultimate\u003Cbr>\n\nグループとプロジェクトのアクセストークン用のWebhookイベントが利用可能になりました。\u003Cbr>\n\n以前は、期限が迫っているトークンに関する通知を受け取る手段がメールだけに限られていました。Webhookイベントがトリガーされると、アクセストークンが期限切れになる7日前に実行されます。\u003Cbr>\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#project-and-group-access-token-events)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/426147)\n\n### プロジェクトアーカイブ機能の更新\nSaaS: Free、Premium、Ultimate\u003Cbr>\nSelf-Managed: Free、Premium、Ultimate\u003Cbr>\n\nアーカイブ済みプロジェクトをプロジェクトリストで簡単に特定できるようになりました。 16.11以降、アーカイブされたプロジェクトはグループの概要の\u003Cb>アーカイブ済み\u003C/b>タブに移動し、\u003Cb>アーカイブ済み\u003C/b>バッジが表示されます。このバッジは、プロジェクト概要ページのプロジェクトタイトルにも表示されます。\u003Cbr>\nアーカイブ済みプロジェクトが読み取り専用であることを示すアラートメッセージが表示されます。このメッセージは、アーカイブ済みプロジェクトのサブページで作業する際にこの情報が見落とされることがないよう、すべてのプロジェクトページで表示されます。\u003Cbr>\nまた、グループを削除しようとすると、アーカイブ済みプロジェクトが誤って削除されることを防止するために、確認モーダルにアーカイブ済みプロジェクトの件数が表示されるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/working_with_projects.html#archive-a-project)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/23667)\u003Cbr>\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/18069)\n\n\u003Cimg src=\"https://about.gitlab.com/images/16_11/updated_project_archiving.png\">\n\n## 実験的な機能\n\n### GitLab CIステップを使用したGitHubアクションの実行（実験）\n\n新しいGitLab Steps構文とStep Runnerを利用することで、CI/CDワークフロー用のGitHub ActionsをGitLab CI/CDパイプラインに組み込めるようになりました。この機能により、GitHub Actionsから移行するユーザーをオンボーディングする際のプロセスを簡素化できます。\u003Cbr>\n\nこの機能は実験的に導入されました。詳細については、[こちらのドキュメント](https://docs.gitlab.com/ee/ci/steps/index.html)を参照してください。\n\n### ロギング（実験）\n\nロギングを利用することで、インフラストラクチャレベル（システムログ）やエンドユーザーアプリケーションなどにおける最近のログや過去のログを収集、保持、照会することができます。さまざまなログソースを一元化することで、ユーザーは個々のイベントを関連付けてシステム内の連携を確立し、問題の根本原因を迅速に特定できるようになります。これにより、コンテキストスイッチ（ツール間の切り替え）が削減され、トラブルシューティングにおける所要時間が短縮します。\u003Cbr>\n\nこの機能は実験的に導入されました。詳細と開始方法については、[ログに関するドキュメント](https://docs.gitlab.com/ee/operations/logs)を参照してください。\n\n### メトリクス（実験）\n\nメトリクスを利用することで、Open-TelemetryライブラリとSDKを活用したデータ収集が可能になり、インフラストラクチャやアプリケーションレベルにおける過去または最近のメトリクスを収集、保持、クエリすることができます。\u003Cbr>\n\nこの機能は実験的に導入されました。詳細と開始方法については、[メトリクスに関するドキュメント](https://docs.gitlab.com/ee/operations/metrics)を参照してください。\n\n### モデルレジストリ（実験）\n\nデータサイエンティストは[モデルレジストリ](https://docs.gitlab.com/ee/user/project/ml/model_registry/)を利用することで、機械学習（ML）モデルを、その作成に関連付けられたすべてのメタデータ（パラメーター、パフォーマンスメトリクス、アーティファクト、ログなど）とともに管理できます。\u003Cbr>\n\n現在、この実験的な機能は[MLflowクライアント](https://docs.gitlab.com/ee/user/project/ml/model_registry/)と互換性があります。\n\n### バグの修正、パフォーマンスの改善、UIの改善\n\nGitLabは、ユーザーに可能な限り最高のエクスペリエンスを提供することに専念しています。 リリースごとに、バグの修正、パフォーマンスの向上、UIの強化に精力的に取り組んでいます。GitLabでは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームをご利用いただくすべての方に、スムーズでシームレスな利用体験を届けるために精一杯取り組んでいます。\u003Cbr>\n\n16.11で提供されたすべてのバグの修正、パフォーマンスの強化、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=16.11)\n- [パフォーマンスの改善](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=bug%3A%3Aperformance&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=16.11)\n- [UIの改善\n](https://nicolasdular.gitlab.io/gitlab-polish-gallery/?milestone=16.11)\n\n### 非推奨事項\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabのドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受けるには、[破壊的な変更のRSSフィードをサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\u003Cbr>\n\n- [`GITLAB_SHARED_RUNNERS_REGISTRATION_TOKEN`は非推奨となりました](https://about.gitlab.com/breaking-changes.xml)\n\n## 削除された機能と変更点 \n\n消去されたすべての機能の一覧は、[GitLabのドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。 今後の破壊的な変更について通知を受けるには、[破壊的な変更のRSSフィードをサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n## その他の重要な変更\n\n### パッチとセキュリティの統合リリース\n\nGitLabは、4月に「パッチ」および「セキュリティ」のリリースを一新し、これらを[セマンティックバージョニング](https://semver.org/)の標準に準拠した「パッチ」リリースに統合しました。\u003Cbr>\n\n変更の詳細については、[パッチリリースとセキュリティリリースの統合](https://about.gitlab.com/blog/were-combining-patch-and-security-releases/)に関するブログ記事を参照してください。\n\n### メジャーリリースに先立つ破壊的な変更の実施日時\n\n17.0のメジャーリリースは2024年5月16日に予定されています！\u003Cbr>\n\nこのバージョンでは、GitLabに多くの素晴らしい改善が加えられる一方で、同時に非推奨機能も削除されます。破壊的な変更は、以下の3回の日程で実施されます。この期間に、17.0における破壊的な変更の大部分がGitLab.comにデプロイされることが予想されます。\n\n- 2024年4月22日9時00分～2024年4月24日22時00分（協定世界時）\n- 2024年4月29日9時00分～2024年4月31日22時00分（協定世界時）\n- 2024年5月6日9時00分～2024年5月8日22時00分（協定世界時）\n\n詳細については、[GitLab 17.0における重大かつ破壊的な変更に関するガイド記事](https://about.gitlab.com/blog/a-guide-to-the-high-impact-breaking-changes-in-gitlab-17-0/)を参照してください。\n今年のメジャーリリースで予定されているすべての削除項目を確認するには、[非推奨ページ](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=17.0)にアクセスしてください。\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ワークフロー](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新しいGitLabのインストールをセットアップする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/install/)を参照してください。\n## 更新\n[更新ページ](https://about.gitlab.com/update/)を確認してください。\n## ご質問\nご意見をお聞かせください。本リリースについてご不明な点がある場合は、[GitLabフォーラム](https://forum.gitlab.com/)にアクセスし質問を投稿してください。\u003Cbr>\u003Cbr>\n\n*監修：大井 雄介 （GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n### 過去の日本語リリース情報\n\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/)\n",{"slug":3377,"featured":6,"template":681},"gitlab-16-11-released","content:ja-jp:blog:gitlab-16-11-released.yml","Gitlab 16 11 Released","ja-jp/blog/gitlab-16-11-released.yml","ja-jp/blog/gitlab-16-11-released",{"_path":3383,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3384,"content":3390,"config":3397,"_id":3399,"_type":16,"title":3400,"_source":17,"_file":3401,"_stem":3402,"_extension":20},"/ja-jp/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab",{"title":3385,"description":3386,"ogTitle":3385,"ogDescription":3386,"noIndex":6,"ogImage":3387,"ogUrl":3388,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3388,"schema":3389},"大手EC会社のBol社がGitLabでコンプライアンス管理に成功した事例","ヨーロッパの大手EC会社が常に変化するコンプライアンスに、GitLabでどのように対処しているかを事例を通してご紹介します。ぜひお読みください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665465/Blog/Hero%20Images/blog-image-template-1800x945__15_.png","https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"大手EC会社のBol社がGitLabでコンプライアンス管理に成功した事例\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julie Griffin\"}],\n        \"datePublished\": \"2024-06-12\",\n      }",{"title":3385,"description":3386,"authors":3391,"heroImage":3387,"date":3393,"body":3394,"category":2156,"tags":3395,"updatedDate":3396},[3392],"Julie Griffin","2024-06-12","国際的な大手小売業のBol社がGitLabを利用して、どのように開発効率化とソフトウェア規制遵守を実現しているのかご紹介します。\n\n[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)プランを利用しているBol社は、オランダとベルギーにおける最大級のオンライン小売業（EC会社）です。同社のマーケットプレイスでは、5万ものパートナーが商品を販売しており、商品ラインナップ数は3,800万点に上ります。同社は革新的なテクノロジーを利用することで開発効率を向上させ、めまぐるしく変化するソフトウェアのコンプライアンス規制を遵守し、広範な顧客基盤からの信頼を維持しています。\n\n## BolがGitLabによってコンプライアンス管理に成功した事例\n\nBol社はGitLabの[DevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/platform/)を自社チームに導入し、デベロッパーが迅速かつ安全にプロジェクトを完了できるようにすると同時に、手動で行っていたコンプライアンスチェックにかかる工数を数千時間から大幅に削減しました。\n\nBol社の収益が増加するにつれて、同社が遵守しなければならないコンプライアンスルールや規制も増加しました。一般データ保護規則 （GDPR）や国際標準化機構 （ISO）の要件、EU人工知能法など、厳格で頻繁に更新される規制に準拠するためには、ソフトウェアを継続的に適応させる必要があります。\n\nBol社のCI/CD開発チームエンジニアリングマネージャであるGuus Houtzager氏は、次のように述べています。\n\n「GitLabは、当社が成長し、ソフトウェアとデベロッパーが順守すべき要件が増大する中で、柔軟性と競争力の維持に大きく貢献しています。私たちが抱えていたこれら最大の課題に対し、GitLabを活用することで解決を図りました。」\n\nBol社は2016年に[GitLabコミュニティ](https://about.gitlab.com/community/)に参入し、その数年後に[GitLab Premium](https://about.gitlab.com/ja-jp/pricing/premium/)を導入、2024年にはGitLab Ultimateにアップグレードしました。これにより、コンプライアンスの負荷増に対応するとともに、チームがより迅速かつ効率的にプロジェクトに取り組むことができる基盤を作り上げてきました。\n![bol社のGitLabに対するコメント](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675638/Blog/Content%20Images/bol_Blog_-_Guus.png)\n\n## 毎月数千時間の開発時間の節約 \n\nGitLabを活用することで、Bol社のDevSecOpsチームはコンプライアンス設定とチェックを自動化するポリシーを設定できます。これにより、[コンプライアンスへの取り組みに関する一貫性と拡張性を実現](https://about.gitlab.com/ja-jp/solutions/security-compliance/)し、人為的エラーによるリスクを軽減できます。コンプライアンスのガードレールが設定されたことで、850人の開発者チームは革新的で安全なソフトウェアの開発により多くのエネルギーを注ぐことができます。\n\nHoutzager氏は、次のように語りました。  \n「GitLab Ultimateを導入したことで、初めからコンプライアンス規制の範囲内で仕事ができるという強制的なコンプライアンスパイプラインを作ることができます。これにより、デベロッパーの作業時間を月間で数千時間ほど節約できました。」\n\nデベロッパーがコンプライアンス規制の負担を気にする必要がなくなり、コーディングに集中できるようになったことで、Bol開発チームの効率は飛躍的に向上しました。時間の節約だけでなく、チームは将来のコンプライアンス規制にも対応できると自信を持つようになりました。\n\nHoutzager氏はさらに続けます。  \n「私たちは、GitLabがコンプライアンスとソフトウェアセキュリティの両方に役立つことを信じています。GitLabには新しい規制に従って構築できるツールキットがあります。将来のことは誰にもわかりませんが、たとえ新しい規制が増えたとしても、GitLabであればどのような事態にも対処できると考えています。」  \n\n## 顧客と事業を守るためのシフトレフト\n\nヨーロッパ小売業界大手の1つであるBol社にとって、「信頼」はビジネスモデルの重要な柱です。同社は住所や注文明細など大量の個人データを取り扱っています。規制による罰金が懸念される一方で、、顧客からの信頼維持も重要な課題です。セキュリティの重要性は言うまでもありません。\n\nHoutzager氏は次のように述べました。  \n「オランダやベルギーのほとんどの住民が、これまでにBol社での購買経験があり、私たちを信頼してくれています。彼らは弊社が顧客の支払い情報を適切に扱うと信じています。弊社がお客様の個人識別情報（PIIデータ）を販売したりせず、データを安全に保管していると信じています。」\n\n顧客データとビジネスを保護するために、Bol社はシフトレフトセキュリティを導入し、デベロッパーが開発プロセスの早い段階でエラーや脆弱性を発見できるようにしました。しかし、適切なツールを使用せずにシフトレフトすると、発見した問題を修正するためにデベロッパーが膨大な時間を費やすことになる可能性があります。\n\nHoutzager氏はシフトレフトの実施について、次のように説明を加えました。  \n「チームが作業を効率的に実行できるようにするツールやサポート、プロセスを提供しないままでシフトレフトすると、チームは手順や手作業において困難を抱えます。」\n\nGitLab Ultimateを利用すれば、同社のセキュリティ要件を満たすレイアウトや権限モデルを設定できるため、デベロッパーは顧客とビジネスデータを保護しながら、プロジェクトを迅速に立ち上げリリースできます。また、DevSecOpsプラットフォームには、デベロッパーが行った変更や修正を追跡し、コンプライアンスレコードに記録するという機能もあります。\n\n## AIとともに見据える未来\n\nBol社は今後、クラウド統合や人工知能 (AI) 機能、セキュリティ機能など、GitLab Ultimateをさらに活用していく予定です。\n\n同社は、AI機能が搭載された[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)がソフトウェア開発のスケールアップを支援してくれると期待しています。GitLab Duoは、安全ななソフトウェアの迅速な構築からデベロッパーエクスペリエンスの向上まで幅広く貢献します。\n\nHoutzager氏は、AIの可能性と利用条件について、次のように述べています。  \n「私たちがAIを使うには、状況が整っている必要があります。そして、AIがどのように役立つかを必ず検討します。他の企業の皆さんと同じように、ソフトウェア開発のライフサイクル全体を見通しながら、AIによって改善できる箇所を探しています。例えば、コード作成の場面や一連のプロセスの他の場面で、どのようにAIを活用できるかなどを常に考えています。」\n\n> GitLabのさらなる魅力については、 [GitLabを選ぶ10の理由](https://about.gitlab.com/ja-jp/why-gitlab/)をご覧ください。\n",[110,722,762,904],"2024-11-28",{"slug":3398,"featured":6,"template":681},"online-retailer-bol-tackles-growing-compliance-needs-with-gitlab","content:ja-jp:blog:online-retailer-bol-tackles-growing-compliance-needs-with-gitlab.yml","Online Retailer Bol Tackles Growing Compliance Needs With Gitlab","ja-jp/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab.yml","ja-jp/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab",{"_path":3404,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3405,"content":3411,"config":3418,"_id":3420,"_type":16,"title":3421,"_source":17,"_file":3422,"_stem":3423,"_extension":20},"/ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"title":3406,"description":3407,"ogTitle":3406,"ogDescription":3407,"noIndex":6,"ogImage":3408,"ogUrl":3409,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3409,"schema":3410},"GitLab Duo開発の現場から：AIと根本原因分析を併用したCI/CDパイプラインの修正","AIを活用したGitLabの根本原因分析が、破損したCI/CDパイプラインの修復にどのように役立つかについて、具体的なシナリオと実習問題を交えながら解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097321/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750097321081.png","https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から：AIと根本原因分析を併用したCI/CDパイプラインの修正\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rutvik Shah\"},{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-06-06\",\n      }",{"title":3406,"description":3407,"authors":3412,"heroImage":3408,"date":3414,"body":3415,"category":787,"tags":3416,"updatedDate":3417},[3413,2980],"Rutvik Shah","2024-06-06","___生成AIは、ソフトウェアの開発、保護、運用を容易にし、ソフトウェア開発業界に重要な変化をもたらしています。GitLabの製品チームとエンジニアリングチームが手掛ける新しいブログシリーズでは、企業全体に統合すべきAI機能をどのように作成、テスト、そしてデプロイするか明らかにし、DevSecOpsチームがよりよいソフトウェアを顧客に届ける上で、GitLab Duoの新機能がどのように役立つのかご理解いただける内容になっています。___\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインがエラーを起こして、その根本原因を突き止めるために、やむを得ずDevSecOpsワークフローを停止したり、ソフトウェアのデプロイを遅らせたりした経験はありませんか？従来のアプローチでは、ソフトウェア開発で問題が発生した場合、デベロッパーはトラブルシューティングやログファイルの分析を行い、多くの場合で、試行錯誤を繰り返しながら開発を進める必要があります。[GitLab Duo根本原因分析](https://about.gitlab.com/ja-jp/gitlab-duo/)はGitLabの一連のAI搭載機能に含まれるもので、類推に頼ることなくCI/CDパイプラインで発生した失敗の根本原因を特定します。この記事では、根本原因分析について、また、GitLab DuoのAI搭載機能をDevSecOpsワークフローに適用する方法についてご説明します。\n\n> デモ動画公開！GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を体験しませんか？（[今すぐ登録する](https://about.gitlab.com/ja-jp/seventeen/)）\n\n### 根本原因分析とは？\n\nGitLab Duoの根本原因分析は、ログを分析してCI/CDジョブログにおける失敗の根本原因を特定し、修正方法を提案してくれるAI搭載機能です。\n\n根本原因分析はソフトウェア開発のインシデント管理によく用いられますが、そのワークフローやデバッグの手法はあらゆるDevSecOpsワークフローにも活用されています。パイプラインの失敗を調査する際、運用チーム、管理者、そしてプラットフォームエンジニアは、Infrastructure as Code（IaC）のデプロイエラー、KubernetesやGitOpsの問題、そして長いスタックトレースなどに対処しなければなりません。\n\nGitLab Duoの根本原因分析は、全員を同じインターフェイスに集め、AIを活用して要約、分析、修正提案を行うことで、組織がより迅速に安全なソフトウェアをリリースできるように支援します。\n\nパイプラインの失敗の原因としては、コードの構文エラー、パイプラインに使用される依存関係の欠落、ビルドプロセスにおけるテストの失敗、KubernetesやIaCのデプロイタイムアウト、その他多くの問題が考えられます。そのような失敗が発生した場合、関係者全員が、パイプラインで生成されたログを慎重に確認する必要があります。こうしたログの確認には、詳細な出力情報を精査してエラーを特定し、パイプラインにおける失敗の根本原因を特定したりする作業が伴います。たとえば、次のパイプラインには、調査と修正が必要なジョブの失敗が複数あります。\n\n![複数のジョブの失敗を示す画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097332601.png)\n\nこうした失敗の修正に要する時間は、次のような要因によって大きく異なります。\n- プロジェクトに関するデベロッパーの熟知度\n- 同様の問題の対処に関するデベロッパーの経験値\n- パイプラインにおけるトラブルシューティングと問題解決に関するデベロッパーの全体的なスキルレベル\n\n手動での分析は非常に困難で時間がかかることがあります。これは、ログデータを構成するアプリケーションログとシステムメッセージに、さまざまな失敗の原因が含まれている可能性があるためです。一般的なパイプライン修正のプロセスでは、複数回にわたるイテレーションや、（作業を行ったり来たりすることによる）頭の切り替えが必要になります。ログの複雑さや非構造的な性質に対しては、生成AIを使うことで作業を高速化できます。AIを活用することで、パイプラインのエラーを特定して修正する時間を大幅に短縮でき、上記のようなパイプラインを修正するために必要な専門知識のハードルも下げられます。\n\n以下の動画で、実際にGitLab Duoの根本原因分析を使用する流れをご覧ください。\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n\n \u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n### 根本原因分析の仕組み\n\n[根本原因分析](https://docs.gitlab.com/ee/user/ai_experiments.html#root-cause-analysis)は、CI/CDジョブログの一部を[GitLab AIゲートウェイ](https://docs.gitlab.com/ee/architecture/blueprints/ai_gateway/)に転送することで機能します。GitLabでは、転送される内容が大規模言語モデル（LLM）のトークン制限内に収まるように調整されます。また、ジョブの失敗原因に関する洞察を提供するよう指示する既定のプロンプトも併せて送信されます。また、このプロンプトは、破損したジョブの修正方法の例をユーザーに提示するよう、LLMに指示します。\n\nここでは、根本原因分析を活用できるシナリオの例を2つご紹介します。\n\n#### 1. Pythonの依存関係エラーを分析する\n\nPythonのアプリケーションでは、標準ライブラリには備わっていない機能を含むパッケージモジュールをインポートできます。プロジェクト「[Challenge - Root Cause Analysis - Python Config（演習 - 根本原因分析 - Pythonの構成）](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config)」では、構成の解析とSQLiteデータベースの初期化を実行するアプリケーションが実装されており、いずれも依存関係なしで正常に動作しています。また、このプロジェクトでは、Python環境とキャッシュを用いて、CI/CDのベストプラクティスを採用しています。最新の機能追加でRedisのキャッシュクライアントが導入されましたが、これを機にCI/CDビルドが何らかの理由で失敗するようになりました。\n\n根本原因分析を使用すれば、`ModuleNotFoundError`テキストの内容が、モジュールが実際にはPython環境にインストールされていないことを意味しているとすぐにわかります。また、GitLab Duoによって「PIPパッケージマネージャーを介してRedisモジュールをインストールする」ことが修正方法として提案されます。\n\n!['modulenotfounderror'とGitLab Duoによって提案された解決策を示す画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097332602.png)\n\n失敗しているパイプラインは[こちら](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config/-/jobs/6992716398)でご確認いただけます。\n\n根本原因分析のプロンプトに問題のサマリーが表示されており、`redis`モジュールが欠落していることが問題のようです。では、`redis`モジュールをインストールして問題を解決できるか試してみましょう。CI/CDジョブの`スクリプト`セクションで`pip install redis`を呼び出すか、`requirements.txt`ファイルを使用した、より高度なアプローチも選択できます。後者の方法は、開発環境とCI/CDパイプラインにインストールされている依存関係に関連した信頼できる唯一の情報源を確立するのに有効です。\n\n```yaml\ntest:\n  extends: [.python-req]\n  stage: test \n  before_script:\n     # [🦊] hint: Root cause analysis.\n    # Solution 1: Install redis using pip\n    - pip install redis\n    # Solution 2: Add redis to requirements.txt, use pip\n    - pip install -r requirements.txt \n\n  script:\n    - python src/main.py\n```\n\n欠落しているPythonの依存関係を修正した後、CI/CDジョブが再び失敗します。根本原因分析をもう一度使用すると、ジョブでRedisサービスが実行されていないことがわかります。GitLab Duoチャットに切り替え、`How to start a Redis service in CI/CD`（CI/CDでRedisサービスを開始する方法）というプロンプトを使用して、CI/CDジョブで`services`属性を構成する方法を確認します。\n\n![Redisサービスを開始する方法を尋ねるプロンプトを示す画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097333/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097332602.png)\n\n`.gitlab-ci.yml`を`test`ジョブで修正し、`redis`サービスを指定します。\n\n```yaml\ntest:\n  extends: [.python-req]\n  stage: test \n  before_script:\n    # [🦊] hint: Root cause analysis.\n   # Solution 1: Install redis using pip\n    - pip install redis\n    # Solution 2: Add redis to requirements.txt, use pip\n    - pip install -r requirements.txt \n\n  script:\n    - python src/main.py\n\n  # Solution 3 - Running Redis\n  services:\n    - redis\n```\n\nRedisサーバーを実行すると、Pythonアプリケーションを正常に実行し、その出力をCI/CDジョブログに出力できます。\n\n![Pythonアプリケーションの出力](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097332603.png)\n\nこの解決策は、[solution/ ディレクトリ](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config/-/tree/main/solution?ref_type=heads)で確認できます。\n\n**ヒント**：以下のようなプロンプトを使用して、[GitLab Duoチャット](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)に発生リスクのある問題のフォローアップを依頼することもできます。\n\n```markdown\nHow to lint Python code? Which tools are recommended for CI/CD.\nHow to pin a package version in Python requirements file?\t\nWhat are possible ways that this exception stacktrace is triggered in the future?\nAre there ways to prevent the application from failing?\n``` \n\n次の例はより高度で、複数の失敗が含まれています。\n\n#### 2. 不足しているGoランタイムを分析する\n\nCI/CDジョブは、指定された`イメージ`から生成されたコンテナ内で実行できます。コンテナがプログラミング言語のランタイムを提供していない場合、`go`バイナリを参照する実行スクリプトセクションは失敗します。たとえば、`/ bin/sh: eval: line 149: go: not found`というエラーメッセージが表示されたら、これを理解して修正する必要があります。\n\nコンテナ内で`go`コマンドが見つからない場合、以下のような複数の理由が考えられます。\n\n1. ジョブが最小限のコンテナイメージ（`alpine`など）を使用しており、Go言語ランタイムがインストールされていない。\n1. ジョブが誤ったデフォルトのコンテナイメージを使用している。これには、CI/CD構成の先頭で指定されたイメージや`default`キーワードを使用して指定されたイメージなどが該当する。\n1. ジョブがコンテナイメージではなく、Shell executorで実行されている。ホストのオペレーティングシステムにGo言語ランタイムがインストールされていない、または設定が壊れているか正しく構成されていない。\n\nプロジェクト「[Challenge - Root Cause Analysis - Go GitLab Release Fetcher（演習 - 根本原因分析 - GoのGitLabリリースフェッチャー）](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-go-gitlab-release-fetcher)」は、Goで構築されたGitLabリリースフェッチャーアプリケーションのCI/CD問題を分析し、修正するための演習課題です。このプロジェクトでは、`build`と`docker-build`のCI/CDジョブが失敗しています。この問題を解決するには、2つのポイントを抑える必要があります。ひとつはGoランタイムがインストールされていない理由を理解すること、もうひとつは`Dockerfile`構文について学ぶことです。\n\n![変更Dockerラベルジョブの失敗を示すスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097332603.png)\n\n[`solution/` ディレクトリ](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-go-gitlab-release-fetcher)では、根本原因分析の次に試す2つの解決策が確認できます。\n\n## 根本原因分析の練習\n\n以下のシナリオを想定して、根本原因分析を練習してみましょう。\n\n- Kubernetesデプロイメントのエラーやタイムアウトが発生した場合。\n\n- OpenTofuやTerraformのIaCパイプラインがクラウドリソースのプロビジョニングに失敗した場合。\n\n- AnsibleプレイブックがCI/CDで不可解な権限エラーで失敗した場合。\n\n- Javaのスタックトレースが10ページにも及ぶ場合。\n\n- シェルスクリプトが実行エラーを示している場合。\n\n- Perlスクリプトが1行（スクリプト内の唯一の行）で失敗した場合。\n\n- CI/CDジョブがタイムアウトし、どの部分が原因なのか不明な場合。\n\n- ネットワーク接続のタイムアウトが発生し、DNSが原因でないと思われる場合。\n\n### GitLab Duoの根本原因分析の次のステップ\n\nGitLabは、最小限のイテレーションでパイプラインの問題を修正できるようユーザーを支援したいと考えています。根本原因分析が目指す次のステップでは、根本原因分析はGitLab Duoチャット（AIアシスタント）で結果を表示します。ユーザーは、提案された内容を基に、さらに具体的な質問（例：プログラミング言語に特化した修正方法を尋ねる）をしたり、根本原因に基づいた代替の修正方法を尋ねたりすることで、より正確な修正方法を確立できます。\n\nたとえば、失敗したジョブの根本原因分析は次のとおりです。\n\n![根本原因分析の回答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097332603.png)\n\nユーザーは、AIが生成した回答に対し、掘り下げた質問ができます。\n\n- 独自のDockerイメージを作成したくありません。問題を解決するための別の方法を説明してください。\n\n- Dockerイメージの作成にアクセスできません。Goバイナリが見つからないようです。代替のイメージを提案できますか？\n\nGitLabでは、生成された回答の品質ベンチマークを実行し、使いやすさの改善も行います。\n\n詳しくは、[根本原因分析の一般提供（GA）エピック](https://gitlab.com/groups/gitlab-org/-/epics/13080)をご参照ください。機能に関するフィードバックをお寄せいただける方は、[根本原因分析のフィードバック用イシュー](https://gitlab.com/groups/gitlab-org/-/epics/13872)にコメントを投稿してください。\n\n## 根本原因分析を開始する\n\nGitLab Ultimateプランで利用可能な機能を有効化する方法を説明するGitLab[ドキュメント](https://docs.gitlab.com/ee/user/ai_experiments.html#root-cause-analysis)をご参照ください。また、GitLab Duoの根本原因分析は、GitLab Self-ManagedとGitLab Dedicatedでまもなく利用可能になります。\n\nGitLab Ultimateをご利用でない場合は、[無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/blog&glm_content=default-saas-trial)を今すぐ開始していただけます。\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*\n\n## 「GitLab Duo開発の現場から」シリーズをもっと読む\n\n- [GitLab Duo開発の現場から：AIモデルの大規模な検証とテストの方法](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n\n- [GitLab Duo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [GitLab Duo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n\n- [GitLab Duo開発の現場から： AI生成コードに対するセキュリティ確保と徹底的なテスト](https://about.gitlab.com/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)",[721,676,702,904,678],"2024-11-15",{"slug":3419,"featured":92,"template":681},"developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd","content:ja-jp:blog:developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd.yml","Developing Gitlab Duo Blending Ai And Root Cause Analysis To Fix Ci Cd","ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd.yml","ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"_path":3425,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3426,"content":3432,"config":3437,"_id":3439,"_type":16,"title":3440,"_source":17,"_file":3441,"_stem":3442,"_extension":20},"/ja-jp/blog/developing-gitlab-duo-series",{"title":3427,"description":3428,"ogTitle":3427,"ogDescription":3428,"noIndex":6,"ogImage":3429,"ogUrl":3430,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3430,"schema":3431},"「GitLab Duo開発の現場から」シリーズ","プロダクトチームとエンジニアリングチームが執筆するこのブログシリーズでは、AIイノベーションの舞台裏をご紹介するとともに、DevSecOpsワークフローを支える最新のAI機能を詳しく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659856/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25.png","https://about.gitlab.com/blog/developing-gitlab-duo-series","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"「GitLab Duo開発の現場から」シリーズ\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-06-03\",\n      }",{"title":3427,"description":3428,"authors":3433,"heroImage":3429,"date":3434,"body":3435,"category":787,"tags":3436,"updatedDate":3258},[671],"2024-06-03","生成AIは、ソフトウェアの開発、保護、運用を容易にし、ソフトウェア開発業界に重要な変化をもたらしています。GitLabの製品チームとエンジニアリングチームが手掛ける新しいブログシリーズでは、企業全体に統合すべきAI機能をどのように作成、テスト、そしてデプロイするか明らかにし、DevSecOpsチームがよりよいソフトウェアを顧客に届ける上で、GitLab Duoの新機能がどのように役立つのかご理解いただける内容になっています。\n\n> デモ動画公開！GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を体験しませんか？ [今すぐ登録する](https://about.gitlab.com/ja-jp/seventeen/)\n\n## 1. [AIモデルの大規模な検証とテスト方法](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n\n- 記念すべき1本目は、LLMをどのように評価し、ユースケースに適合させ、ユーザーにとってより良い回答が得られるように微調整しているのか。その舞台裏をご紹介します。\n\n## 2. [AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- 「コード提案利用率」のような、詳しいメトリクスを表示する新機能を継続的に取り上げ、AI投資の効果について理解を深めていただきます。\n\n## 3. [GitLabにおけるAI機能のドッグフーディングの取り組み](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n\n- GitLabがどのようにソフトウェア開発ライフサイクル全体にAIを統合しているのか、また、メトリクスを用いてパフォーマンスを測定しているのかを、実例を用いて解説します。\n\n## 4. [AI生成コードに対するセキュリティ確保と徹底的なテスト](https://about.gitlab.com/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n\n- GitLab DuoとGitLab Pages、コードサンプルとプロンプトを使用して、AI生成コードの信頼性とセキュリティを強化する方法をステップごとにご紹介します。\n\n## 5. [AIと根本原因分析を併用したCI/CDパイプラインの修正](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)\n\n- AIを活用したGitLabの根本原因分析が、破損したCI/CDパイプラインの修復にどのように役立つかについて、具体的なシナリオと実習問題を交えながら解説します。\n\n## 6. [チャット機能強化について](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements)\n- 新たなインテグレーション、迅速なキャンセル、アーキテクチャのアップグレードなど、GitLab Duo Chatの最新の改善点についてまとめました。\n\n> DevSecOpsワークフロー向けのAI機能、 [GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)が新登場。[GitLab Duoの無料トライアル](https://about.gitlab.com/ja-jp/gitlab-duo/#free-trial) もお試しください。 \n\n##  7. [AIを活用したセキュリティ脆弱性の修正](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities)\nGitLab Duo脆弱性の説明とGitLab Duo脆弱性の修正に加え、他のAI機能が、いかに迅速に脆弱性に対応するかを解説します。",[721,678,702,904],{"slug":3438,"featured":6,"template":681},"developing-gitlab-duo-series","content:ja-jp:blog:developing-gitlab-duo-series.yml","Developing Gitlab Duo Series","ja-jp/blog/developing-gitlab-duo-series.yml","ja-jp/blog/developing-gitlab-duo-series",{"_path":3444,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3445,"content":3451,"config":3456,"_id":3458,"_type":16,"title":3459,"_source":17,"_file":3460,"_stem":3461,"_extension":20},"/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format",{"title":3446,"description":3447,"ogTitle":3446,"ogDescription":3447,"noIndex":6,"ogImage":3448,"ogUrl":3449,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3449,"schema":3450},"初心者向けGit reftableフォーマットガイド","Git 2.45.0では、GitLabがreftableバックエンドをGitに取り込んだことで、参照の保存方法が完全に変更されました。この新しいフォーマットの内部の仕組みを詳しく見てみましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"初心者向けGit reftableフォーマットガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-05-30\",\n      }",{"title":3446,"description":3447,"authors":3452,"heroImage":3448,"date":3453,"body":3454,"category":962,"tags":3455,"updatedDate":2113},[1643],"2024-05-30","最近まで、Gitでの参照の保存方法は、「files」フォーマットだけに限られていましたが、[Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)により、Gitでは参照を「reftable」フォーマットで保存できるようになりました。この新しいフォーマットは、バイナリフォーマットで非常に複雑ですが、その複雑さが「files」フォーマットのいくつかの欠点を解決します。「reftable」フォーマットは、次のような目的で設計されました。\n\n- 単一の参照の検索と参照範囲のイテレーションを、可能な限り効率的かつ迅速に行えるようにする。\n- 複数の参照が部分的にしか更新されていない中途半端な状態をGitが読み取らないように、一貫した参照の読み取りをサポートする。\n- 複数の参照の更新がオールオアナッシング型のオペレーションとして実行される、アトミック書き込みをサポートする。\n- 参照および参照ログの効率的な保存。\n\nこの記事では、「reftable」フォーマットの仕組みを詳しく見ていきます。\n\n## Gitでの参照の保存方法\n\n「reftable」フォーマットについて詳しく掘り下げる前に、まずはGitがこれまで参照をどのように保存してきたのかを簡単に振り返ってみましょう。すでにご存知の方は、このセクションを読み飛ばして構いません。\n\nGitリポジトリは、次の重要な2つのデータ構造を追跡します。\n\n- [オブジェクト](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)：リポジトリの実際のデータ（コミット、ディレクトリツリー構造、ソースコードを含むblobなど）を格納しています。オブジェクトは互いに参照し合い、オブジェクトグラフを形成します。さらに、各オブジェクトにはオブジェクトIDがあり、そのオブジェクトを一意に識別します。\n\n- 参照：ブランチやタグなどがあります。これらはオブジェクトグラフへのポインタであり、オブジェクトに覚えやすい名前を付けたり、開発履歴の異なるトラックを追跡するのに使われます。たとえば、リポジトリには`main`ブランチが含まれている場合があり、これは特定のコミットを指し示す`refs/heads/main`という名前の参照です。\n\n参照は、参照データベースに保存されます。Git 2.45.0までは、「files」データベースフォーマットのみが存在していました。このフォーマットでは、各参照が通常のファイルとして保存され、そのファイルには次のいずれかが含まれます。\n\n- 通常の参照：指し示すコミットのオブジェクトIDが保存されています。\n- シンボリック参照：別の参照の名前が保存されています。これは、シンボリックリンクが別のファイルを指し示すのと似ています。\n\n定期的に、これらの参照は検索を効率化するために1つのpacked-refsファイルにまとめられます。\n\n次の例は、「files」フォーマットがどのように動作するかを示しています。\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEADはrefs/heads/mainを指すシンボリック参照です。\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/mainはコミットを指す通常の参照です。\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1)はこれらの参照をpacked-refsファイルにパック化します。\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n```\n\n## reftableフォーマットの構造概要\n\nGit 2.45.0以降がインストールされている場合、`--ref-format=reftable`スイッチを使用して「reftable」フォーマットでリポジトリを作成できます。\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# わかりやすくするために不要なファイルを削除しています。\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nまず、リポジトリの設定を見ると、それには`extension.refstorage`キーがあります。\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nこの設定は、リポジトリが「reftable」フォーマットで初期化されており、「reftable」バックエンドを使用してアクセスするようGitに指示するものです。\n\n不思議なことに、このリポジトリにはまだ「files」バックエンドが使われているかのように見えるいくつかのファイルがあります。\n\n- `HEAD`は通常、現在チェックアウト済みのブランチを指すシンボリック参照です。「reftable」バックエンドでは使用されませんが、GitクライアントがディレクトリをGitリポジトリとして検出するために必要です。したがって、「reftable」フォーマットを使用する場合、`HEAD`は`ref: refs/heads/.invalid`という内容のスタブになります。\n\n- `refs/heads`は、`this repository uses the reftable format`という内容が書かれているファイルです。「reftable」フォーマットを認識できないGitクライアントは、このパスがディレクトリであると想定します。したがって、このパスをファイルとして作成することで、古いGitクライアントが「files」バックエンドでリポジトリにアクセスしようとすると、意図的に失敗するようになります。\n\n実際の参照は、次のように`reftable/`ディレクトリに保存されます。\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nここには、次の2つのファイルがあります。\n\n- `0x000000000001-0x000000000001-794bd722.ref`は、参照と参照ログデータをバイナリフォーマットで含むテーブルです。\n\n- `tables.list`は、テーブルのリストです。リポジトリの現在の状態では、このファイルにはテーブルの名前の1行だけが含まれています。このファイルは「reftable」データベースにある現在有効なテーブルをまとめて追跡し、新しいテーブルがリポジトリに追加されるたびに更新されます。\n\n次のように、参照を更新すると、新しいテーブルが作成されます。\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nご覧のとおり、以前のテーブルは新しいテーブルに置き換えられました。さらに、`tables.list`ファイルが更新され、新しいテーブルが取り込まれました。\n\n## テーブルの構造\n\n前述のとおり、参照データベースの実際のデータはテーブルに含まれています。テーブルは大まかに次のような複数のセクションに分かれています。\n\n- header：テーブルに関するメタデータが含まれています。これには、フォーマットのバージョン、ブロックサイズ、およびリポジトリで使用されるハッシュ関数（SHA1、SHA256など）が、他の情報と一緒に含まれています。\n- ref：参照が含まれています。これらのレコードは参照名と等しいキーを有し、通常の参照の場合はオブジェクトIDを、シンボリック参照の場合は他の参照を指します。\n- obj：オブジェクトIDからそれらのオブジェクトIDを指す参照への逆マッピングが含まれています。これにより、Gitは特定のオブジェクトIDを指す参照を効率的に検索できます。\n- log：参照ログエントリが含まれています。これらのレコードは、参照名にログエントリの番号を表すインデックスを付け足したものと等しいキーを有し、 さらに、古いオブジェクトIDと新しいオブジェクトID、およびその参照ログエントリのメッセージを含みます。\n- footer：各セクションへのオフセットが含まれます。\n\n![すべてのreftableセクションを含んだ縦長の表](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\n各セクションのタイプは、似たような構造を持っています。セクションには一連のレコードが含まれており、各レコードのキーでソートされています。たとえば、 `refs/heads/aaaaa`と `refs/heads/bbb`という2つの参照レコードがある場合、これらの参照名がそれぞれのキーとなり、`refs/heads/aaaaa`が`refs/heads/bbb`よりも前に来ます。\n\nさらに、各セクションは固定長のブロックに分割されています。このブロックの長さはヘッダー（header）にエンコードされており、次の2つの目的を果たします。\n\n- セクションの開始位置とブロックサイズに基づき、リーダー（reader）は各ブロックの開始位置を暗に認識します。これにより、Gitは先行するブロックを読み込むことなくセクションの途中に簡単に移動できるため、ブロック上でのバイナリ検索が可能になり、レコードの検索を高速化します。\n- 一度に読み込むディスクデータの量をリーダーが認識できるようにします。このために、ブロックサイズはデフォルトで4KiBに設定されており、これはハードディスクのセクターサイズとしては最も一般的です。最大ブロックサイズは16MBです。\n\nたとえば、「ref」セクションを覗いてみると、おおよそ次の図のようになります。ここで留意すべき点は、レコードがブロック内で、そしてブロック間の両方で辞書順に並んでいることです。\n\n![未圧縮参照ブロック](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\n現在の情報を基に、次の手順でレコードを検索できます。\n\n1. 各ブロックの最初のレコードのキーを確認してバイナリ検索を行い、目的のレコードが含まれているブロックを特定します。\n\n2. 特定したブロック内で線形検索を行い、目的のレコードを特定します。\n\nこの手順はまだ少し非効率です。多くのブロックがある場合、目的のブロックを特定するためにバイナリ検索で対数的に多くのブロックを読み込むことが必要になる場合があります。また、ブロックに多数のレコードが含まれている場合、線形検索中にすべてのレコードの読み込みが必要になる可能性もあります。\n\n「reftable」フォーマットには、これらのパフォーマンス問題に対処する追加のメカニズムが組み込まれています。後のセクションでこれらについて詳しく説明します。\n\n### プレフィックス圧縮\n\nお気づきかもしれませんが、すべてのレコードキーには`refs/`という共通のプレフィックスがあります。これはGitでは一般的です。\n\n- すべてのブランチは`refs/heads/`で始まります。\n- すべてのタグは`refs/tags /`で始まります。\n\nしたがって、後続のレコードもキーの大部分で共通のプレフィックスを持つことが予想されます。これを利用して、貴重なディスク容量を節約できます。ほとんどのキーが共通のプレフィックスを持つことがわかっているため、これを最適化するのは理にかなっています。\n\nこの最適化にはプレフィックス圧縮を使用します。各レコードは、前のレコードのキーから何バイトを再利用するかを示すプレフィックスの長さがエンコードされています。たとえば、`refs/heads/a`と`refs/heads/b`という2つのレコードがある場合、後者はプレフィックスの長さを11バイトとしてエンコードし、サフィックスとして`b`だけを保存します。その後、リーダーは`refs/heads/a`の最初の11バイト（`refs/heads/`）を取得し、サフィックス`b`を追加します。\n\n![プレフィックス圧縮](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### 再起点\n\n前述のように、現在の「reftable」フォーマットの理解に基づいてブロック内の参照を検索する最適な方法は、線形検索です。これは、レコードが固定長ではないため、ブロックの先頭からスキャンしないとレコードの開始位置を特定できないためです。また、レコードが固定長であったとしても、レフィックス圧縮があるため、先行するレコードを読み込む必要があり、ブロックの途中に直接移動はできません。 \n\nしかし、ブロックには数百から数千のレコードが含まれる可能性があり、線形検索は非常に非効率です。この問題に対処するために、「reftable」フォーマットは各ブロックに「再起点」と呼ばれるポイントをエンコードします。再起点は圧縮されていないレコードであり、ここではプレフィックス圧縮がリセットされます。したがって、再起点のレコードは常に完全なキーを含んでおり、先行するレコードをスキップしながら直接移動してレコードを読み込むことが可能になります。これらの再起点は各ブロックのフッターにリストされています。\n\nこの情報を用いることで、ブロック全体を線形検索する必要がなくなります。代わりに、再起点のバイナリ検索を行い、目的のキーより大きい最初の再起点を探します。そこから、目的のレコードが_前の_再起点から特定された再起点までのセクションに存在することがわかります。\n\nしたがって、レコードを検索する最初の手順（ブロックのバイナリ検索、レコードの線形検索）は次のようになります。\n\n1. ブロックのバイナリ検索を行い、目的のレコードが含まれるブロックを特定します。\n\n2. 再起点のバイナリ検索を行い、目的のレコードが含まれるブロックのサブセクションを特定します。\n\n3. 特定したサブセクション内でレコードの線形検索を行います。\n\n![レコードの線形検索](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### インデックス\n\nブロック内のレコードの検索はかなり効率化されましたが、ブロック自体の位置を特定するのはまだ効率的とはいえません。数個のブロックであればバイナリ検索でも十分に効率的です。しかし、数百万もの参照を含むリポジトリには数百から数千のブロックが存在します。この場合、追加のデータ構造がなければ、平均して対数的に多くのディスクアクセスが必要になります。\n\nこの問題を避けるために、各セクションの後にブロックを効率的に検索するためのインデックスセクションを追加できます。各インデックスレコードには次の情報が含まれます。\n\n- インデックス化されているブロックの位置。\n- インデックス化されているブロックの最後のレコードのキー。\n\n3つ以下のブロックであれば、バイナリ検索は最大2回のディスク読み取りで目的のブロックを特定できます。この読み取り回数は、インデックスを使用する場合も同じです。具体的には、インデックス自体を読み取るための1回と、目的のブロックを読む取るための1回です。したがって、インデックスは実際に読み取り回数を減らす場合、つまりインデックス化されたブロックが4つ以上ある場合にのみ作成されます。\n\n次の疑問は、インデックス自体が複数のブロックにまたがるほど大きくなった場合はどうすべきかという点です。その答えは、そのインデックスをインデックス化するために別のインデックスを作成するというものです。この複数階層のインデックスは、数十万もの参照があるリポジトリでのみ必要となります。\n\n次のインデックスを使用することで、レコードの検索手順をさらに効率化できます。\n1. テーブルのフッターを見てインデックスがあるかどうかを確認します。\n\t- インデックスがあれば、バイナリ検索を行い、目的のブロックを特定します。このブロックがインデックスブロック自体を指している場合は、目的のレコードタイプに到達するまでこの手順を繰り返します。\n\t- インデックスがなければ、先ほどのようにブロックのバイナリ検索を行います。\n2. 再起点のバイナリ検索を行い、目的のレコードが含まれているブロックのサブセクションを特定します。\n3. 特定したサブセクション内でレコードの線形検索を行います。\n\n## 複数のテーブル\n\nここまでは、単一のテーブルを読み取る方法について説明してきましたが、`tables.list`という名前が示すように、「reftable」データベースには複数のテーブルを格納できます。\n\nリポジトリ内の参照を更新するたびに、新しいテーブルが作成され、`tables.list`に追加されます。したがって、最終的には次のように複数のテーブルが存在することになります。\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├── 0x000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\n\nリポジトリの実際の状態を読み取るためには、これらの複数のテーブルを単一の仮想テーブルにマージする必要があります。\n\nここで疑問が生じます。それは、参照が更新されるたびにテーブルが作成され、同じ参照が複数回更新される場合、「reftable」フォーマットは特定の参照の最新の値をどのように把握するのか、ということです。直感的には、最新のテーブルに含まれる参照の値が最新であると仮定できます。\n\n実際には、各レコードには「更新インデックス」と呼ばれるものがあり、これがレコードの「優先度」をエンコードしています。たとえば、同じ名前の2つの参照レコードが存在する場合、更新インデックスが高い方が低い方を上書きします。\n\nこれらの更新インデックスは、上のファイル構造で確認できます。長い16進文字列（例：`0x000000000001`）が更新インデックスであり、テーブル名の左側がテーブルに含まれる最小の更新インデックス、そして右側が最大の更新インデックスを示しています。\n\nテーブルのマージは、参照レコードのキーと更新インデックスによって順序付けられた[優先キュー](https://en.wikipedia.org/wiki/Priority_queue)を介して行われます。すべての参照レコードをスキャンする場合、次の手順で行います。\n\n1. 各テーブルの最初のレコードを優先キューに追加します。\n\n![優先キューに最初のレコードを追加する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. 優先キューの先頭を取り出します。このキューは更新インデックス順に並んでいるため、先頭にあるレコードは最新のバージョンでなければなりません。そのテーブルの次の項目を優先キューに追加します。\n\n![優先キューの先頭を取り出す](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. 同じ名前を持つすべてのレコードをキューから削除します。これらのレコードは上書きされているため表示されません。レコードを削除した各テーブルについては、その次のレコードを優先キューに追加します。\n\n![同じ名前を持つすべてのレコードをキューから削除する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\n\nこれを繰り返して、他のキーのレコードを読み取ります。\n\nテーブルには、レコードが削除されたことを示す特殊な「トゥームストーン」レコードが含まれている場合があります。このように、すべてのテーブルを書き換えることなく、レコードを削除できます。\n\n### 自動圧縮\n\n優先キューの考え方はシンプルですが、このアプローチでは、マージするテーブルの数が数百個、あるいは数十個であっても、非常に非効率になります。参照を更新するたびに新しいテーブルが`tables.list`ファイルに付加されるのは事実ですが、他にも重要な特徴があります。\n\nそれが、自動圧縮です。新しいテーブルがテーブルリストに付加された後、「reftable」バックエンドは一部のテーブルをマージする必要があるかどうかを確認します。これは、シンプルなルールを使って行われます。具体的には、テーブルのリストがファイルサイズの[幾何数列](https://en.wikipedia.org/wiki/Geometric_progression)を形成しているかどうかをチェックします。すべてのテーブル`n`は、その次に新しいテーブル`n+1`の2倍以上のサイズでなければなりません。この幾何数列が維持されなかった場合、バックエンドはテーブルを圧縮して幾何数列を復元します。\n\n時間が経つにつれて、次のような構造になります。\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nすべてのテーブルにおいて、`size(n) > size(n+1) * 2`という性質が維持されていることに注目してください。\n\n自動圧縮がもたらすメリットのひとつは、「reftable」バックエンドのメンテナンスが自動化されることです。これにより、リポジトリで`git pack-refs`を実行する必要がなくなります。\n\n## さらに詳しく知りたい方へ\n\nこの記事では、新しい「reftable」フォーマットの仕組みについて解説しました。さらに詳しく知りたい場合は、Gitプロジェクトで提供される[テクニカルドキュメント](https://git-scm.com/docs/reftable)をご参照ください。\n\n> [Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)では、このバージョンにおけるその他の変更点をご確認いただけます。\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[966,676,825,1191],{"slug":3457,"featured":92,"template":681},"a-beginners-guide-to-the-git-reftable-format","content:ja-jp:blog:a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format","ja-jp/blog/a-beginners-guide-to-the-git-reftable-format.yml","ja-jp/blog/a-beginners-guide-to-the-git-reftable-format",{"_path":3463,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3464,"content":3470,"config":3474,"_id":3476,"_type":16,"title":3477,"_source":17,"_file":3478,"_stem":3479,"_extension":20},"/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"title":3465,"description":3466,"ogTitle":3465,"ogDescription":3466,"noIndex":6,"ogImage":3467,"ogUrl":3468,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3468,"schema":3469},"GitLab Duo開発の現場から： AI生成コードに対するセキュリティ確保と徹底的なテスト","GitLab DuoとGitLab Pages、コードサンプルとプロンプトを使用して、AI生成コードの信頼性とセキュリティを強化する方法をステップごとにご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097183/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750097183481.png","https://about.gitlab.com/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から： AI生成コードに対するセキュリティ確保と徹底的なテスト\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-05-30\",\n      }",{"title":3465,"description":3466,"authors":3471,"heroImage":3467,"date":3453,"body":3472,"category":787,"tags":3473,"updatedDate":2707},[3276],"___生成系AIは、ソフトウェアの開発、保護、運用を容易にし、ソフトウェア開発業界に重要な変化をもたらしています。この新しいブログシリーズでは、GitLabの製品チームとエンジニアリングチームが、必要なAI機能をエンタープライズ全体に統合し、どのように作成、テスト、デプロイするかをご紹介します。GitLab\nDuoの新機能によってDevSecOpsチームがお客様にどんな価値をもたらせるようになるか、見ていきましょう！___\n\n\nソフトウェア開発でAIがますます重要な役割を果たすようになる中、AI生成コードに対するセキュリティ確保や、徹底したテストの実施は極めて重要です。本記事では、AI機能を活用してDevSecOpsワークフローを強化できる[GitLab\nDuo](https://about.gitlab.com/gitlab-duo/)と、[GitLab\nPages](https://docs.gitlab.com/ee/user/project/pages/)を組み合わせて、AI生成コードを安全にテストする手順をステップごとに説明しています。一般的なリスクを軽減する方法や、テストの自動生成、コードのテスト、テストレポートのデプロイなどのプロセスについても取り上げます。これらはすべて、AI生成コードの信頼性を高めるためのアプローチです。\n\n\n> デモ動画公開！GitLab\n17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を体験しませんか？[今すぐ登録する](https://about.gitlab.com/ja-jp/seventeen/)\n\n\n## AI生成コードの課題\n\n\nAI生成コードは、次のような問題に頻繁に直面します。\n\n\n- アルゴリズムの不一致：不適切または最適化されていないアルゴリズムが生成される場合があります。\n\n- 依存関係の問題： AIが生成するコードには、古い依存関係や互換性のない依存関係が含まれている可能性があります。\n\n- セキュリティ上の脆弱性：AIは、セキュリティ上の欠陥を伴うコードを生成することがあります。\n\n\n上記のように、AI生成コードは、アルゴリズムの不一致、依存関係の問題、セキュリティの脆弱性などの問題によく直面します。プログラミング関連の質問に対するChatGPTの回答について、[Association\nof Computing\nMachinery（計算機協会）が発表した最近の研究](https://dl.acm.org/doi/pdf/10.1145/3613904.3642596)（外部サイト）では、回答の52%に誤った情報が含まれており、77%が過度に冗長であることがわかりました。これらの欠点があるにもかかわらず、ユーザーはChatGPTの包括的でよく構成された回答を35%の割合で好み、誤情報が含まれていても39%の割合でそれを見過ごしました。これらの課題に対処するには、高度なツールとフレームワークを使用する必要があります。\n\n\n## AIセキュリティとテストに対するGitLabのアプローチ\n\n\nGitLabでは、開発ワークフロー内にセキュリティ対策を組み込むことに焦点を当てた、包括的なコンテンツ戦略を採用しています。GitLab\nDuoを活用してAIによるコード生成を応用したり、GitLab\nPagesを利用してテストレポートを（ウェブサイトに）埋め込んだりすることで、デベロッパーはAI生成コードのセキュリティと信頼性を確保できます。\n\n\n以下は、GitLab DuoとGitLab Pagesを組み合わせて、[Flask\nwebサーバー](https://flask.palletsprojects.com/en/3.0.x/)（外部サイト）を実装することでAI生成コードを安全かつ徹底的にテストするための手順ガイドになります。\n\n\n#### 1. GitLab.comで新しいプロジェクトを作成する\n\n\n- [GitLab.com](http://GitLab.com)にアクセスします。\n\n- 「新しいプロジェクト」ボタンをクリックします。\n\n- 「空白のプロジェクトを作成」を選択します。\n\n- プロジェクト名を入力します（例：AI_CODE_SECURITY）。\n\n- 表示レベル（公開、内部、非公開）を設定します。\n\n- 「プロジェクトを作成」をクリックします。\n\n\n#### 2. GitLab Duoのコード提案を有効にする\n\n\n- プロジェクトに移動します。\n\n- 「Web IDE」ボタンをクリックしてWeb IDEを開きます。\n\n- GitLab Duoの機能（コード提案、Duoチャットなど）が有効になっていることを確認します。\n\n- [Web\nIDE](https://docs.gitlab.com/ee/user/project/web_ide/)でコーディングを開始します。入力する際に、GitLab\nDuoによるコード提案が表示され、より効率的なコーディングを支援してくれます。\n\n\n#### 3. Flask Webサーバーを作成する\n\n\n下のスクリーンショットのコメント（緑色のテキスト）を使用して、Flask Webサーバーを作成できます。\n\n\n![DGDテスト -\n画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097192520.png)\n\n\n#### 4. GitLab Duoでテストを生成する\n\n\nユニットテストは、生成されたコードの機能を検証する上で不可欠です。GitLab Duoの` /tests`コマンドを使用して、直接[Web\nIDE内でテストの提案を生成](https://docs.gitlab.com/ee/user/gitlab_duo_chat_examples.html#write-tests-in-the-ide)します。このコマンドは、具体的な側面（パフォーマンス、リグレッション、特定のフレームワークの使用など）に焦点を当てるために、指示を追加してカスタマイズできます。\n\n\n##### Web IDEでの使用例：\n\n\n- テストを生成したいコードを選択します。\n\n- `/tests`コマンドを使用し、必要に応じて指示を追加します。\n\n\n![DGDテスト -\n画像2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097192521.png)\n\n\n#### 5. GitLab Duoチャットを使用してAI生成コードの問題を特定する\n\n\nGitLab Duoチャットを使用して、AIが生成したコードのレビューと修正を行います。たとえば、Flask\nWebサーバーのコードにセキュリティ脆弱性がないか確認する場合は、以下のプロンプトを使用します。\n\n\n```unset\n\nプロンプト：このコードをレビューして、潜在的なセキュリティ脆弱性と依存関係の問題を検証してください。\n\n\n```\n\n\n![DGDテスト -\n画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097192523.png)\n\n\nGitLab Duoチャットを使用することで、上記のコード内の脆弱性を特定しやすくなります。\n\n\n#### 6. テストレポートを生成する\n\n\nテストを実行した後、GitLab Pagesを使用してデプロイするテストレポートを生成します。\n\n\n```unset\n\n\nプロンプト：GitLab Pagesを使用してデプロイするテストレポートを生成するPythonスクリプトを作成してください。\n\n\n```\n\n\n![DGDテスト -\n画像4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097192525.png)\n\n\nここでの処理内容は以下のとおりです。\n\n\n- スクリプトは、test_reportsディレクトリが存在することを確認します。\n\n- `subprocess.run()`を使用して`test_server.py`ファイルを実行し、出力（テスト結果）をキャプチャします。\n\n- 出力のRAWデータを`test_reports/test_output.txt`に保存します。\n\n-\nテスト結果を読みやすいように`\u003Cpre>`タグ内に埋め込んだHTMLレポートを生成し、`test_reports/index.html`として保存します。\n\n\n#### 7. GitLab Pagesを使用してテストレポートをデプロイする\n\n\n[GitLab\nPages](https://docs.gitlab.com/ee/user/project/pages/)を使用し、テストレポートを公開します。テストレポートをデプロイするための`.gitlab-ci.yml`ファイルの構成は次のとおりです。\n\n\n```python\n\n\nstages:\n  - test\n  - deploy\ntest_job:\n  stage: test\n  script:\n    - python generate_test_report.py\n  artifacts:\n    paths:\n      - test_reports/\npages:\n  stage: deploy\n  script:\n    - mv test_reports public\n  artifacts:\n    paths:\n      - public\n\n ```\n\nこの構成では、`test_job`ステージでPythonスクリプトを実行してテストレポートを生成します。`pages`ステージでは、`test_reports`ディレクトリが`public`に移動され、GitLab\nPagesがそのコンテンツを提供するために使用されます。\n\n\n#### 8. MRウィジェットにテストレポートを埋め込む\n\n\n[MRウィジェットにテストレポート](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html)を埋め込むことで、テストの結果を即座に確認でき、透明性と信頼性を確保できます。これは、次のように、CI/CDパイプラインの構成にテストレポートをアーティファクトとして含めることで実現できます。\n\n\n```python\n\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the project...\"\n    - # Your build commands here\n\ntest_job:\n  stage: test\n  script:\n    - mkdir -p test-reports\n    - python test_server.py > test-reports/results.xml\n  artifacts:\n    when: always\n    reports:\n      junit: test-reports/results.xml\n    paths:\n      - test-reports/results.xml\n\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - mv test-reports .public/\n  artifacts:\n    paths:\n      - .public\n\n```\n\nテストレポートをアーティファクトとして含め、レポートセクションに指定することで、GitLabによってテスト結果が自動的にMRウィジェットに表示されます。これにより、テストの結果が即座に確認でき、透明性と信頼性が向上します。\n\n\n#### ケーススタディ：セキュリティポリシーとスキャナーによるAIの信頼性\n\n\nAI生成コードのスニペットが、既知の脆弱性を持つ依存関係を取り込んだ状況を想定してみましょう。GitLab\nDuoとそのセキュリティポリシーを使用することで、この依存関係はコード生成プロセス中に検出されます。AIによって生成された以下のスニペットの例を見てみましょう。\n\n\n```python\n\n\nimport os\n\nfrom flask import Flask, request\n\n\napp = Flask(__name__)\n\n\n@app.route('/search')\n\ndef search():\n    query = request.args.get('query')\n    execute_os_command(query)\n    return 'You searched for: ' + query\n\ndef execute_os_command(command):\n    os.system(command)\n\nif __name__ == '__main__':\n    app.run()\n\n```\n\n\nこの例では、検索エンドポイントがOSコマンドインジェクションの脆弱性を持っています。GitLabの静的アプリケーションセキュリティテスト（[SAST](https://docs.gitlab.com/ee/user/application_security/sast/)）コンポーネントを活用することで、この脆弱性はCI/CDパイプライン中に検出されます。\n\n\n##### SASTスキャンを統合して脆弱性を検出する\n\n\nGitLab\nSASTは、自動的にコードを分析してセキュリティ脆弱性を検出します。以下は、`.gitlab-ci.yml`ファイルに統合して問題をスキャンする方法です。\n\n\n```python\n\n\nstages:\n  - build\n  - test\n  - sast\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the project...\"\n    - # Your build commands here\n\ntest_job:\n  stage: test\n  script:\n    - python test_server.py > test-reports/results.xml\n  artifacts:\n    when: always\n    reports:\n      junit: test-reports/results.xml\n    paths:\n      - test-reports/results.xml\n\nsast_job:\n  stage: sast\n  script:\n    - echo \"Running SAST...\"\n  artifacts:\n    reports:\n      sast: gl-sast-report.json\n  only:\n    - branches\n\npages:\n  stage: deploy\n  script:\n    - mv test-reports public\n  artifacts:\n    paths:\n      - public\n\n```\n\n\nこの設定では、`sast_job`ステージがSASTを実行してコードの脆弱性を検出し、パイプラインアーティファクトに含まれるレポート（`gl-sast-report.json`）を生成します。GitLab\nDuoは、セキュリティポリシーと強力なテストフレームワークを統合することで、お客様がAI生成コードの効率性とセキュリティを確保することを支援します。\n\n\n## 始めてみよう\n\nソフトウェア開発におけるAIの統合は大きなメリットをもたらしますが、新たな課題も伴います。GitLab DuoやGitLab\nPagesのようなツールを使用することで、デベロッパーはAI生成コードを徹底的にテストし、そのセキュリティと信頼性を確保できます。まずはこれらのツールをお試しになり、AIセキュリティとテストの強化を検討してみませんか？\u003Cbr>\n\n\u003Cbr>\n\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n\n\n> 今すぐ[GitLab\nUltimateのトライアルを開始](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)して、GitLab\nDuoとGitLab Pagesをご利用ください。\n\n\n## 「GitLab Duo開発の現場から」シリーズをもっと読む\n\n\n- [GitLab\nDuo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [GitLab\nDuo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [GitLab\nDuo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n\n- [GitLab\nDuo開発の現場から：AIと根本原因分析を併用したCI/CDパイプラインの修正](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)\n",[721,702,676,722],{"slug":3475,"featured":6,"template":681},"how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code","content:ja-jp:blog:how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code.yml","How Gitlab Duo Helps Secure And Thoroughly Test Ai Generated Code","ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code.yml","ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"_path":3481,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3482,"content":3488,"config":3493,"_id":3495,"_type":16,"title":3496,"_source":17,"_file":3497,"_stem":3498,"_extension":20},"/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"title":3483,"description":3484,"ogTitle":3483,"ogDescription":3484,"noIndex":6,"ogImage":3485,"ogUrl":3486,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3486,"schema":3487},"GitLab Duo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み","このブログシリーズの記事では、GitLabがどのようにソフトウェア開発ライフサイクル全体にAIを統合しているのか、また、メトリクスを用いてパフォーマンスを測定しているのかを、実例を用いて解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098360/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098360821.png","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-05-20\",\n      }",{"title":3483,"description":3484,"authors":3489,"heroImage":3485,"date":3490,"body":3491,"category":787,"tags":3492,"updatedDate":3277},[3276],"2024-05-20","***生成系AIは、ソフトウェアの開発、セキュリティ保護、運用のプロセスを簡素化し、ソフトウェア開発業界に大きな変革をもたらしています。GitLabの製品チームとエンジニアリングチームが手掛ける新しいブログシリーズでは、企業全体に統合すべきAI機能を、我々はどのように作成、テスト、デプロイしているかを説明しています。をこれは皆様のDevSecOpsチームがよりよいソフトウェアを顧客に届ける上で、GitLab Duoの新機能をどう利用できるのかを知っていただける内容になっています。*** \n\nAI機能を集めた[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、当社の社内エンジニアリングワークフローを刷新し、開発プロセス全体の効率化を推進してきました。GitLabはドッグフーディングと透明性を重視しています。そのため、この記事では、当社のチームがコード提案やチャットなどの代表的なGitLab DuoのAI機能を日常的に活用し、開発プロセスの合理化や手作業の削減、生産性の向上を実現しているアプローチについて解説したいと思います。エンジニアリングのような高度な技術を用いるチームから、テクニカルライティングや製品管理など、あまり技術的でないチームまで、当社が得ているメリットについて解説します。\n\n> GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を発見しましょう！[【今すぐ視聴する】](https://about.gitlab.com/ja-jp/seventeen/)\n\n## 実際のユースケース\n\nGitLabのチームは、[GitLab Duoの各種機能](https://about.gitlab.com/gitlab-duo/#features)を日々のルーチンに組み込んでいます。日常的な仕事を実行する上でGitLab Duoをどのように役立てているのかについて、いくつか実例をご紹介します。\n\n### 要約とドキュメント\n- **コードレビュープロセスを効率化：** スタッフバックエンド開発者の[Gosia Ksionek]( https://about.gitlab.com/company/team/#mksionek)は、GitLab Duoを使ってAIをワークフローに用いる実践的なメリットとして、コードレビュープロセスの無駄を省くことができる点を挙げています。彼女はGitLab Duoを用いて効果的に[マージリクエストを](https://youtu.be/3SIhe8dgFEc)要約し、コード変更のレビューを簡素化し、作業をスピードアップさせています。また、マージリクエストの要約に加えて、GitLab Duoを使って[コーディングの質問への回答](https://www.youtube.com/watch?v=6n0I53XsjTc)と[複雑なコードスニペットの説明](https://www.youtube.com/watch?v=3m2YRxa1SCY)も実施しています。このように、生産性の向上のほか、複雑なコードベースの理解と管理にAIを活用しています。以下のデモで、GitLab Duoが大幅な効率向上と開発プロセスの見える化に貢献しており、開発者にとって欠かせないツールであることを強調しています。\n\n\u003Ccenter>\n\nGitLab Duoを使ってマージリクエスト要約する方法をご覧ください。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3SIhe8dgFEc?si=Q8JG3Ix3K_THhbpv\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\nGitLab Duoを使ってコーディングに関する質問に回答する方法をご覧ください。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6n0I53XsjTc?si=LA9VBHrgXpfJImSL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!--空白行-->\n\nGitLab Duoを使って複雑なコードスニペットを説明する方法をご覧ください。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3m2YRxa1SCY?si=oms3szKwZoz-4yeq\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n\u003C/center>\n\n- **コメントスレッドの要約：** エクスパンションソフトウェア開発を統括する[Bartek Marnane](https://about.gitlab.com/company/team/#bmarnane)は、GitLab Duoを使って長いコメントスレッドを要約し、イシューの説明を更新しても重要な情報が洩れることがないように工夫しています。\n\n- **ドキュメントの新規作成：** データサイエンスセクションの製品部門グループマネージャーを務める[Taylor McCaslin](https://about.gitlab.com/company/team/#tmccaslin)は、GitLab Duoを用いて[GitLab Duo用の新規ドキュメントを作成](https://docs.gitlab.com/ee/user/ai_features.html)し、情報の明確化と一貫性の確保、および新機能のドキュメンテーションに費やす時間の大幅な短縮を実現しています。\n\n- **リリースノートの作成：** 製品企画部門でシニア製品マネージャーを務める[Amanda Rueda](https://about.gitlab.com/company/team/#amandarueda)はGitLab Duoをとおして、[リリースノートに使用する簡潔で有益な要約を作成](https://gitlab.com/groups/gitlab-org/-/epics/10267)し、変更点やその価値をユーザーに説明しています。以下のような効果的なプロンプトを使うことで、ワークフローを大幅に改善し、各リリースノートがわかりやすく、簡潔で、ユーザー目線で書かれるようにしています。その結果、コミュニケーション全般とユーザー体験の向上につながっています。\u003Cbr>\u003Cbr>\n*「この変更を2つの文で要約してください。リリースノートに使用します。会話のようなトーンで、二人称を使います。要約には問題や変更の説明を盛り込み、当社が、あなた、つまりユーザーにもたらす価値と関連付けてください」*\n\u003Cbr>\u003Cbr>\n    - 以下に、GitLab Duoを使って作成したリリースノートの例を挙げます。\n      - [ロードマップをソートするためのオプションを拡大](https://gitlab.com/gitlab-org/gitlab/-/issues/460492)\n      - [マイルストーンとイテレーションを用いてイシューボードを明確化](https://gitlab.com/gitlab-org/gitlab/-/issues/25758)\n      - [デザイン管理機能を製品チームに拡張](https://gitlab.com/gitlab-org/gitlab/-/issues/438829)\n\n- **ドキュメントサイトのナビゲーションを最適化：** スタッフテクニカルライターの[Suzanne Selhorn](https://about.gitlab.com/company/team/#sselhorn)はGitLab Duoを使ってページをワークフローに基づいた順番に並び替え、[ドキュメントの左側のナビゲーションを最適化](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html)しています。機能の一覧をGitLab Duoに伝えることで、適切な順番が生成され、その順番に合うように左側のナビゲーションを更新しました。また、GitLab Duoを使って、手作業よりも大幅に速く[スタートガイド](https://docs.gitlab.com/ee/user/get_started/get_started_planning_work.html)の下書きを作成できるようになりました。\n\n### 目標設定とチームの連携\n- **OKRの下書き作成と改善：** Create:Codeレビューバックエンドチームでエンジニアリングマネージャーを務める[François Rosé](https://about.gitlab.com/company/team/#francoisrose)は、OKR（目標と主な成果）の下書き作成と改善において[GitLab Duoチャット](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/)の利便性を実感しています。目標をより明確に、効果的に伝えることで、目標設定とチームでの認識の共有を強化しています。GitLab Duoチャットを使用すると、正確で、アクションに結びつきやすく、なおかつチームの目標と一致するOKRを策定できるため、チームの全体的なパフォーマンスの向上と団結を導けます。以下に、プロンプトの例を記載します。\u003Cbr>\u003Cbr>\n\n    *「次のようなOKRを作ろうと思っています。*\n\n    *目標：チームメンバー全員からレトロスペクティブを徹底してチームを活性化する*\n\n    *主な成果：チームメンバー全員からレトロスペクティブにの満足度を測定する*\n\n    *主な成果：非同期で行うレトロスペクティブの改善点を3つ特定する*\n\n    *主な成果：改善を1つ実行する*\n\n    *上記の目標と3つの主な成果の構成を改善する方法に関して率直なフィードバックをください」*\n\u003Cbr>\u003Cbr>\n\n- **採用と採用活動プロセスを合理化：** スタッフフロントエンドエンジニアの[Denys Mishunov](https://about.gitlab.com/company/team/#dmishunov)が、面接を受ける候補者に送るメールテンプレートを明確で簡潔な文章で修正する際に重宝した実際のチャットを[こちら](https://gitlab.com/gitlab-com/people-group/hiring-processes/-/merge_requests/2165#note_1904898688)からご覧ください。必要な情報を漏れなく候補者に伝えるため、チームが協力して、どのようにマージリクエストを通してコミュニケーションを改善しているのかに注目しましょう。この例は、採用ワークフローにおけるコミュニケーションプロセスの強化をもたらす、AIツールの実用的な活用方法を示すものです。\n\n### インシデントのレスポンスと設定\n- **本番環境のインシデントを要約：** \nスタッフサイトリライアビリティエンジニアの[Steve Xuereb](https://about.gitlab.com/company/team/#sxuereb)は、GitLab Duoを本番環境のインシデントの要約、および詳細なレビューの作成に利用し、ドキュメンテーションプロセスの合理化を促進しています。\n\n- **ボイラープレート`.gitlab-ci.yml`ファイルを作成：**  GitLab Duoチャットを介して、ボイラープレート`.gitlab-ci.yml`ファイルも作成し、ワークフローの大幅な改善を実践しています。[GitLab Duoチャット](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)はアイデアを提案してくれる頼りになるパートナーです。さらに、[コードの説明]( https://docs.gitlab.com/ee/user/ai_features.html#code-explanation)機能のおかげで、インシデント発生時に詳細かつ有益な回答を得ることができ、生産性の向上とコードベースの正確な理解につながっています。\n\n### コードの生成とテスト\n- **フルスタック開発：** シニアフロントエンドエンジニアの[Peter Hegman](https://about.gitlab.com/company/team/#peterhegman)は[コードの提案機能をJavaScriptとRubyによる開発](https://gitlab.com/gitlab-org/gitlab/-/issues/435783#note_1731321963)に応用しており、フルテクニカルスタック全体において開発者にとって欠かせないツールとして、AIの存在価値を示しています。\n\n- **Pythonのスクリプトを生成** Denys Mishunovは[GitLab DuoをGitLab以外のタスクに使用する実験](https://gitlab.com/gitlab-org/ai-powered/ai-framework/ai-experimentation)を行いました。この実験は、一般的なソフトウェア開発のタスクに留まらないGitLabのAIツールならではの柔軟性と利便性を証明しています。\n\n\u003Ccenter>\n以下の動画で、GitLab Duoを使ってPythonのスクリプトを作成し、コンテンツのデータを取り込んだ後、ローカルに保存するMishunovのアプローチをご覧いただけます。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/30ZTtk4K5yU?si=p5ZcFLg6dTZL5gFE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n\u003C/center>\n\n### 調査とサポート\n- **テスト用ソースコードの生成：**  シニア開発者アドボケートの[Michael Friedrich](https://about.gitlab.com/company/team/#dnsmichi)はGitLab Duoを用いて、CI/CDのコンポーネントに使用するテストソースコードを生成しています。このアプローチは、先日開催されたOpen Source @ Siemens([公開スライド](https://go.gitlab.com/duA2Fc))を含むさまざまなトークイベントやプレゼンで紹介されています。このようにGitLab Duoを活用することで、コードの一貫性の確保や正確なドキュメント作成を実施できるほか、GitLabのベストプラクティスに沿って作業を進められます。[Rustの例](https://gitlab.com/components/rust#contributing)をご覧ください。\n\n![Rustの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098367/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098367547.png)\n\n- **調査タスクの合理化：** GitLabのチームメンバーはGitLabの機能に関する質問は必ずGitLab Duoチャットで尋ね、調査およびサポートタスクの負担を軽減しています。Friedrichは「GitLabの機能についてわからないことがあったら、ブラウザのタブを次々と開いて調べるする前に、まずはチャットに頼ります。このワークフローにより、コミュニティフォーラムでのユーザー支援をより効率よく実施できるようになりました。たとえば、先日、実際にこの方法を使って[SSHのデプロイに関するユーザーからの質問に回答](https://forum.gitlab.com/t/how-to-make-ssh-deployment-more-clear-in-gitlab/102051/4?u=dnsmichi)しました」と述べています。チャットの活用は、時短につながるだけではなく、正確な情報を速く伝えられるようになり、コミュニティサポートの取り組みを底上げできます。\n\n### 機能テスト\n- **新しい機能のテスト：** GitLabのエンジニアは[コード提案におけるMarkdownへのサポート](https://gitlab.com/gitlab-org/gitlab/-/issues/443365)などGitLab Duoを使って新機能のテストを実施しています。あるチームメンバーは「コード提案でのMarkdownのサポートをテストして、ブログの記事とVS CodeでGitLabのドキュメントを作成します。17.0に統合されていたことを知っていたからです」と述べています。GitLabでは、これらの機能をリリース前に社内でテストし、当社の品質基準を確実に満たす取り組みを行っています。\n\n### 外部のコードベースを理解\n- **外部のプロジェクトの説明：** GitLab Duoの`/explain`機能はGitLabにインポートされた外部のプロジェクトを理解する際にとりわけ有効です。この機能は、オープンソースエキスパートのEddie Jaoude氏を招いて先日行った配信イベントでも紹介しました。Michael Friedrichは「外部のプロジェクトでは`/explain`を使ってソースコードの理解を深めています。配信中に、オープンソースプロジェクトや依存などについて学ぶアイデアとしてこの方法を推奨しました」と指摘しています。 これは、不慣れなコードベースの機能や依存性を速やかに理解する必要がある開発者にとって欠かせない機能であり、効率の向上を導くだけでなく、正確にコードを理解できるようになる利点があります。\n\n\u003Ccenter>\nEddie Jaoude氏を招いた配信イベントでFriedrichが実施した`/explain`のデモをご覧ください。\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/L2Mx8hOhkEE?si=R7W3v4EDqeJCaPOw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\n\u003C/center>\n\n## GitLab Duoを使用するメリット\n\nGitLab Duoのインテグレーションは、多くのポジティブなインパクトをもたらしており、以下のようにGitLabのエンジニアリングと製品開発ワークフローを大きく改善しました。\n\n- 以前は手作業が必要だった多くのタスクを自動化できたため、エンジニアが貴重な時間を他のタスクに充てられるようになりました。たとえば、長いスレッドの要約やボイラープレートコードの作成の効率が高まり、チームはより複雑な課題に集中できるようになっています。\n- イシューのドキュメントや要約に費やす時間を短縮し、情報の伝達と意思決定をより速く行えるようになりました。\n- AIアシストのコードの提案と説明を活用することで、チームはより質の高いコードを作成し、さらにエラー数の削減とデバッグプロセスのスピードアップを達成しました。GitLab Duoをインシデントレビューとコーディング支援に導入した結果、コードレビューの取り組みをより効果的・効率的に進められるようなりました。\n- [OKR](https://about.gitlab.com/ja-jp/blog/what-is-an-okr/)の下書きやリリースノートの作成などの管理タスクを合理化できました。 \n\nご覧のようにGitLab Duoは、効率向上のほか、開発プロセスのスピードアップにも貢献しており、ソフトウェア開発にイノベーションをもたらすAIの能力を遺憾なく発揮しています。\n\n## 今後の取り組み\n\nGitLabはAIのワークフローへの導入を今後も積極的に行い、社内のフィードバックとニーズの変化に応じてGitLab Duoの機能を継続的に改善していきます。また、[AIインパクト分析ダッシュボード](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)をとおしてユースケースとメトリクスの収集を進めており、GitLab Duoの強化に加えて、AIを活用した開発ツールをリードする取り組みに役立てています。\n\n![Duoへのドッグフーディング - AI分析ダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098367/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098367547.png)\n\n*監修：佐々木直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*\n\n> [GitLab Duoの無料トライアルをご利用ください](https://about.gitlab.com/gitlab-duo/#free-trial)\n\n## 「GitLab Duo開発の現場から」シリーズをもっと読む\n\n- [GitLab Duo開発の現場から：AIモデルの大規模な検証とテスト方法](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n- [GitLab Duo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n- [GitLab Duo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n- [GitLab Duo開発の現場から：AI生成コードの安全性確認と詳細なテスト](https://about.gitlab.com/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n",[721,742,678,904,677],{"slug":3494,"featured":92,"template":681},"developing-gitlab-duo-how-we-are-dogfooding-our-ai-features","content:ja-jp:blog:developing-gitlab-duo-how-we-are-dogfooding-our-ai-features.yml","Developing Gitlab Duo How We Are Dogfooding Our Ai Features","ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features.yml","ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"_path":3500,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3501,"content":3507,"config":3514,"_id":3516,"_type":16,"title":3517,"_source":17,"_file":3518,"_stem":3519,"_extension":20},"/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"title":3502,"description":3503,"ogTitle":3502,"ogDescription":3503,"noIndex":6,"ogImage":3504,"ogUrl":3505,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3505,"schema":3506},"GitLab Duo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定","このブログシリーズでは、「コード提案利用率」のような、詳しいメトリクスを表示する新機能を継続的に取り上げ、AI投資の効果について理解を深めていただくことが狙いです。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098611/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098611370.png","https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2024-05-15\",\n      }",{"title":3502,"description":3503,"authors":3508,"heroImage":3504,"date":3510,"body":3511,"category":787,"tags":3512,"updatedDate":3513},[3509],"Haim Snir","2024-05-15","***生成系AIは、ソフトウェアの開発、セキュリティ保護、運用のプロセスを簡素化し、ソフトウェア開発業界に大きな変革をもたらしています。GitLabの製品チームとエンジニアリングチームが手掛ける新しいブログシリーズでは、企業全体に統合すべきAI機能をどのように作成、テスト、そしてデプロイするか明らかにし、DevSecOpsチームがよりよいソフトウェアを顧客に届ける上で、GitLab Duoの新機能がどのように役立つのかご理解いただける内容になっています。***\n\n組織が[GitLab Duo](https://about.gitlab.com/gitlab-duo/)（DevSecOpsワークフローを最適化する各種AI機能）を導入するにあたり、ビジネスリーダーやエンジニアリングリーダーは、こうしたテクノロジーのROI（投資対効果）をリアルタイムで可視化する必要があります。ソフトウェア開発におけるAIの有効性を評価するには、詳細な使用データ、パフォーマンスの改善、その他の[生産性メトリクス](https://about.gitlab.com/blog/measuring-ai-effectiveness-beyond-developer-productivity-metrics/)に加え、スピード、セキュリティ、品質のバランスをとることが必要です。GitLabはこれに対処するために、AIのROIを測定する新たな手段としてGitLab DuoのAIインパクト分析ダッシュボードを導入しました。この機能はGitLab 17.0から利用可能です。\n\n> ライブデモイベント開催決定！GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を発見してみませんか（[今すぐ登録する](https://about.gitlab.com/seventeen/)）。\n\n## GitLab DuoのAI搭載機能のROI\n\nソフトウェア開発ライフサイクルにおけるAIの影響を正確に評価するため、企業は次のような機能をリクエストしています：\n- AIへの投資によって向上したメトリクスの可視化\n- AIを使用しているチームと使用していないチームのパフォーマンスの比較\n- AI導入の進捗の追跡\n- 大量のパフォーマンスデータからのインサイトの自動抽出\n\nGitLab DuoのAIインパクト分析ダッシュボードはこのようなさまざまな機能に加え、カスタマイズ可能な可視化機能も備えており、活用することで、以下が可能になります。\n\n- **AI導入率のモニタリング**：AIの導入率を観察することで、組織はテクノロジー投資のROIを最大化するための戦略を評価できます。\n- **パフォーマンス改善の追跡**：リーダーはパフォーマンスメトリクスを追跡し、AI導入後の変化を観察することで、AI機能がもらたすメリットとビジネス価値を迅速に評価できます。\n\n## AIインパクト分析ダッシュボードとは？\n\nAIインパクト分析ダッシュボードの初回リリースでは、GitLab Duoのコード提案の導入に関する、以下のインサイトとメトリクスの提供に焦点が当てられています。\n\n- **詳細な使用状況メトリクス**：コード提案の月間利用率とユニークコードコントリビューターの総数を比較します。これをもとに、チーム内でコード提案をどの程度活用できているかを把握できます。\n- **相関性のモニタリング**：プロジェクトやグループ内におけるAI使用率の動向が、主要な生産性メトリクスにどのような影響を与えるかを、当月と過去6か月間のデータに基づき表示します。\n  - この相関分析に関連し、独立変数（原因）として「コード提案利用率」という新しいメトリクスが導入されました。コード提案の月間利用率は、コード提案の月間ユニークユーザー数を月間ユニーク[コントリビューター](https://docs.gitlab.com/ee/user/profile/contributions_calendar.html#user-contribution-events)総数で割ることで算出されます。GitLabでは、月間コードコントリビューター総数を基準とし、プッシュ済みイベントの記録があるユーザーのみをこの計算に含めています。\n  - 依存変数（効果）として、「サイクルタイム」「リードタイム」「デプロイ頻度」という[パフォーマンスメトリクス](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports)と、「変更失敗率」と「致命的な脆弱性」という[品質とセキュリティのメトリクス](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports)が追加されました。\n- **比較ビュー**：AIを使用しているチームとそうでないチームのパフォーマンスを比較し、スピード、品質、セキュリティ脆弱性のバランスを管理します。\n\n![AI利用率とSDLCパフォーマンスの比較](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098620998.png)\n\n## AIインパクト分析ダッシュボードに今後導入される機能は？\n\nGitLabでは、AIインパクト分析ダッシュボードの更なる機能強化に向けて計画を進めています。以下に、その一部をご紹介します。\n\n1.「GitLab Duoシート：アサイン済みと使用済み」「コード提案：採用率（%）」「GitLab Duoチャット：ユニークユーザー数」といった新しいタイルデータを導入することから得られる可視性により、GitLab Duoの使用パターンをより深く理解できるようになります。\n\n![AI Impactダッシュボード - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-07-17_at_12.50.31_aHR0cHM6_1750098620999.png)\n\n2. 比較棒グラフを新たに導入し、あるメトリクスの変化が他のメトリクスの変化とどのように関連しているかを観察できるようになります。\n\n![AIインパクト比較棒グラフ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098621000.png)\n\n3. [コントリビュート分析レポート](https://docs.gitlab.com/ee/user/group/contribution_analytics/index.html)のAI統計の導入により、ユーザーがAI機能をどのように利用しているのかを把握できます。 以下のように、どのユーザーがAI機能を活用しているのか、またそのパフォーマンスの推移が表示されます。\n![コントリビュート分析レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098621001.png)\n\n## 始めてみましょう\n\nAIインパクト分析ダッシュボードは、AIによる実際のビジネス成果を実証するだけでなく、DevSecOpsライフサイクルにおける将来のAI最適化に関して、より多くの情報に基づいた意思決定を促進する可能性があります。今後の機能については、[AIインパクト分析ダッシュボードのエピックをご覧ください](https://gitlab.com/groups/gitlab-org/-/epics/12978)。また、こちらからフィードバックやご質問もぜひお寄せください。\n\n[今すぐ、GitLab Duoの無料トライアルとAIインパクト分析ダッシュボード](https://about.gitlab.com/gitlab-duo/#free-trial)をお試しください。\n\n## 「GitLab Duo開発の現場から」シリーズをもっと読む\n\n- [GitLab Duo開発の現場から：AIモデルの大規模な検証とテスト方法](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n- [GitLab Duo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n- [GitLab Duo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n- [GitLab Duo開発の現場から：AI生成コードの安全性確認と詳細なテスト](https://about.gitlab.com/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n\n_免責事項：このブログには、今後の製品、機能、機能に関する情報が含まれています。このブログ投稿の情報は、情報提供のみを目的としている点にご留意ください。これらの情報は、購入や計画の際の判断材料として使用すべきものではありません。すべてのプロジェクトと同様に、このブログおよびリンク先のページに記載されている項目は、変更または遅延される場合があります。製品、機能、機能の開発、リリース、タイミングは、GitLab Inc.の独自の裁量に委ねられます。_\n\n*\u003Cbr>\n監修：\u003Cbr>\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[721,1191,678],"2024-06-13",{"slug":3515,"featured":92,"template":681},"developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai","content:ja-jp:blog:developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai.yml","Developing Gitlab Duo Ai Impact Analytics Dashboard Measures The Roi Of Ai","ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai.yml","ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"_path":3521,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3522,"content":3527,"config":3532,"_id":3534,"_type":16,"title":3535,"_source":17,"_file":3536,"_stem":3537,"_extension":20},"/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"title":3523,"description":3524,"ogTitle":3523,"ogDescription":3524,"noIndex":6,"ogImage":3429,"ogUrl":3525,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3525,"schema":3526},"GitLab Duo開発の現場から： AIモデルの大規模な検証とテスト方法","LLMをどのように評価し、ユースケースに適合させ、ユーザーにとってより良い回答が得られるように微調整しているのか。その舞台裏をご紹介します。","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から： AIモデルの大規模な検証とテスト方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"}],\n        \"datePublished\": \"2024-05-09\",\n      }",{"title":3523,"description":3524,"authors":3528,"heroImage":3429,"date":3529,"body":3530,"category":787,"tags":3531,"updatedDate":3414},[1954],"2024-05-09","**_生成系AIは、ソフトウェア開発業界における重要な変化であり、ソフトウェアの開発、保護、および運用を容易にします。この新しいブログシリーズでは、GitLabの製品チームとエンジニアリングチームが、必要なAI機能をエンタープライズ全体に統合し、どのように作成、テスト、デプロイするかをご紹介します。GitLab Duoの新機能によってDevSecOpsチームがお客様にどんな価値をもたらせるようになるか、見ていきましょう！_**\n\nGitLabは、お客様からの信頼を大切にしています。信頼を維持するためには、[GitLab Duo](https://about.gitlab.com/gitlab-duo/) AI機能をどのように構築し、評価し、高品質を確保しているかについて透明性を持つことが重要です。GitLab Duo機能は多様なモデルセットを備えており、それによって幅広いユースケースをサポートし、顧客に柔軟性を提供しています。GitLabはデフォルトで、単一のモデルプロバイダのみに依存していません。現在、[Google](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/vertex_text.py?ref_type=heads#L86)および[Anthropic](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/anthropic.py?ref_type=heads#L62)の基盤モデルを使用していますが、GitLab Duoのユースケースに適したモデルを継続的に評価しています。このブログでは、AIモデルの検証プロセスを詳しくご紹介します。\n\n>ライブデモ開催！ GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を体験しませんか。[【今すぐ登録する】](https://about.gitlab.com/seventeen/)\n\n## LLMを理解する\n\n大規模言語モデル（LLM）は、プラットフォーム全体の多くのAI機能を強化する生成系AIモデルです。膨大なデータセットで訓練されたLLMは、直前の文脈に基づいて一連の流れの中で次の単語を予測します。入力プロンプトが与えられると、プロンプトに条件付けられた単語の確率分布からサンプリングすることで、人間が書いたようなテキストを生成します。\n\nLLMは、インテリジェントなコード提案、会話型チャットボット、コード説明、脆弱性分析などを可能にします。特定のプロンプトに対して多様な出力を生成する能力があるため、標準化された品質評価が困難です。LLMはさまざまな特性に合わせて最適化できるので、多くのAIモデルが積極的に開発されています。\n\n## 大規模なテスト\n\nインプットとアウトプットがより簡単に定義され、テストできる従来のソフトウェアシステムとは異なり、LLMは、微妙で、また多様でもあり、文脈に依存するアウトプットをよく生成します。これらのモデルをテストするには、品質が主観的で変わりやすいことや、アウトプットがの確率的に変動することを考慮した包括的な戦略が必要です。したがって、LLMのアウトプットの質を個別にまたは経験に基づいて判断するのではなく、LLMの全体的な動作パターンを調べる必要があります。これらのパターンを理解するには、大規模なテストが必要です。大規模なテストとは、膨大で多様なデータセットやユースケースにわたるシステムやアプリケーションのパフォーマンス、信頼性、堅牢性を評価するプロセスを指します。当社の[集中評価フレームワーク（CEF）](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/)は、数十のユースケースに結びついた何千ものプロンプトを利用することで、重要なパターンを特定し、基礎となるLLMとそれらが統合されているGitLab Duo機能の全体的な動作を評価できます。\n\n大規模なテストによって、次のような効果があります。\n\n- __品質を確保する：__ 大規模なテストを行うことで、さまざまなシナリオやインプットでこれらのモデルの品質と信頼性を評価できます。大規模にモデルの出力を検証することにより、パターンを特定し、体系的なバイアス、異常、不正確さなどの潜在的な問題を軽減できます。\n- **パフォーマンスの最適化：** テストをスケールアップすることで、GitLabは実際の条件下でLLMのパフォーマンスと効率を評価できます。これは、アウトプット品質、レイテンシー、コストなどの要因を評価し、GitLab Duo機能に組み込まれたこれらのモデルを最良の状態に保つ作業を指します。\n- **リスクを軽減する：** LLMを大規模にテストすれば、重要なアプリケーションにLLMをデプロイする際のリスクを軽減できます。さまざまなデータセットやユースケースで徹底的なテストを実施することで、潜在的な故障モード、セキュリティの脆弱性、倫理的懸念を特定し、顧客に影響を与える前に対処できます。\n\nGitLabプラットフォーム内でのデプロイの信頼性と堅牢性を確保するには、LLMの大規模なテストが不可欠です。GitLabは、さまざまなデータセット、ユースケース、シナリオを含む包括的なテスト戦略に投資することにより、潜在的なリスクを軽減しながら、AIを活用したワークフローの可能性を最大限引き出すようにに取り組んでいます。\n\n### 大規模にテストする方法\n\nLLMを大規模にテストする手順は次のとおりです。\n\n#### ステップ1 ：本番環境用プロキシとしてプロンプトライブラリを作成する\n現在、他社はAIをトレーニングするために顧客データを表示して使用していますが、GitLabは使用していません。 その結果、本番環境での規模でさまざまな操作ーを模倣する包括的なプロンプトライブラリーを開発する必要がありました。\n\nこのプロンプトライブラリは質問と回答で構成されています。質問は本番環境で実際にあるようなクエリやインプットで、回答はグラウンドトゥルース（理想的な回答の基準）を表します。このグラウンドトゥルースは、目標とする回答として考えることができます。質問も回答も人間が生成した可能性がありますが、必ずしもそうではありません。このような質問と回答の組み合わせから、比較基準や参照フレームができあがり、モデルや機能間の違いを明らかにできます。複数のモデルが同じ質問を受け、異なる回答を生成する場合、グラウンドトゥルースを使用して、実際の回答に最も近いものを提供したモデルを決定し、それに応じてスコアを付けることができます。\n\nここでも、包括的なプロンプトライブラリーの重要な要素は、必ず本番環境で実際ありうるインプットに最も近いものとなるということです。私たちは、基盤となるモデルが特定のユースケースにどの程度適合していて、また自分たちの機能がどの程度うまく機能しているかを知りたいのです。多数のベンチマークプロンプトデータセットがありますが、これらのデータセットは、GitLabにある機能のユースケースを反映していない可能性があります。当社のプロンプトライブラリは、GitLabの機能やユースケースを対象に設計されています。\n\n#### ステップ2 ：ベースラインモデルのパフォーマンス\n\n本番環境のアクティビティーを正確に反映するプロンプトライブラリを作成したら、これらの質問を[さまざまなモデル](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/foundation_models/)に入力して、顧客のニーズをどの程度満たしているかをテストします。\n\n各回答をグラウンドトゥルースと比較し、以下のような一連のメトリクスに基づくランキングを提供します：[コサイン類似度スコア](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#similarity-scores)、[クロス類似度スコア](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#cross-similarity-score)、[LLMジャッジ](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#llm-judge)、[LLMジャッジによるコンセンサスフィルタリング](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#consensus-filtering-with-llm-judge)。この最初のイテレーションは、各モデルがどの程度うまく機能しているかのベースラインを提供し、機能の基盤となるモデルの選択の指針となります。簡潔に説明するため、ここでは詳細に触れませんが、[メトリクスの詳細についてはこちら](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/)をご覧ください。これはまだ解決された問題ではないのでご注意ください。広範囲にわたるAI業界は、新しい技術の研究と開発を積極的に行っています。GitLabのモデル検証チームは、業界の動向を把握し、GitLab Duoが使用するLLM測定やススコアリング方法を継続的に改善しています。\n\n#### ステップ3 ：機能開発\n\n選択したモデルのパフォーマンスのベースラインができたので、自信を持って機能を開発できます。プロンプトエンジニアリングは多くの話題を呼びますが、検証を行わずにプロンプト（またはその他の手法）を介してモデルの動作を変更することだけに焦点を当てると、暗闇の中で作業しているようなものとなり、プロンプトを過剰適合させる可能性が非常に高くなります。1つの問題を解決することはできても、それ以上の問題を引き起こしてしまいます。何が起こるかは分かりません。モデルのパフォーマンスのベースラインを作成することで、必要なすべてのユースケースで時間の経過とともにどのように行動が変化しているかを追跡できます。GitLabでは、アクティブな開発中に機能のパフォーマンスを日々再検証し、すべての変更が全体的な機能性を確実に向上させるようにしています。\n\n#### ステップ4 ：何度も繰り返す\n\nここでは、実験的イテレーションの仕組みを説明します。各サイクルで、大規模なテストのスコアを調べてパターンを特定します。\n\n- 最も弱い分野の共通点は何ですか？\n- 特定のメトリクスや特定のユースケースに基づいた機能でパフォーマンスが低下していますか？\n- 特定の種類の質問に対して一貫したエラーが表示されていますか？\n\n大規模なテストを行ってこそ、このようなパターンが浮き彫りになり、実験に集中できるようになります。これらのパターンに基づいて、特定の分野や特定のメトリクスでパフォーマンスを向上させるさまざまな実験やアプローチを提案します。\n\nしかし、大規模なテストは高価で時間がかかります。より高速で低コストのイテレーションを可能にするために、ミニプロキシとして機能する小規模なデータセットを作成します。焦点を絞ったサブセットには、改善したいと考えている質問と回答の組み合わせが含まれるように重み付けをします。一方、より広範なサブセットには、変更が機能全般に悪影響を及ぼしていないかを確認するために、他のすべてのユースケースとスコアのサンプリングも含まれます。変更を加えて、焦点を絞ったデータのサブセットに対して実行します。新しい回答はベースラインと比較してどうでしょう？グラウンドトゥルースと比較するとどうでしょうか？\n\n焦点を絞ったサブセットで取り組んでいる特定のユースケースに対応するプロンプトが見つかったら、機能の他の分野に悪影響を与えないようにするために、より広範なデータのサブセットに対してそのプロンプトを検証します。新しいプロンプトが検証メトリクスによりターゲット領域でのパフォーマンスを向上させ、それ以外の領域でのパフォーマンスを低下させないと確信した場合にのみ、その変更を本番環境にプッシュします。\n\n集中評価フレームワーク（CEF）全体が新しいプロンプトに対して実行され、前日のベースラインと比べて機能全体のパフォーマンスが向上したかを検証します。このようにして、GitLabは常にイテレーションを行い、GitLabエコシステム全体でAIを使用した機能の最新かつ最高のパフォーマンスを確保しています。これにより、より迅速に、協力ながら作業を続けられます。\n\n### GitLab Duoをさらに優れたものにするために\n\nGitLab Duoの機能開発にどのくらい責任を持って取り組んでいるのかご理解いただいていると幸いです。このプロセスは、[GitLab Duoコード提案](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/)と[GitLab Duoチャット](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)を一般提供したことにより開発されました。また、GitLab Duoの機能をイテレーションする際に、この検証プロセスを開発プロセスに統合しました。さまざまな試行錯誤があり、1つを修正したと思えば別の3つで問題が発生するというようなことがよくありました。しかし、そのような影響についてデータに基づいたインサイトがあり、GitLab Duoが常に改良されているという確信材料となっています。\n\n\u003Cbr>\n\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n>今すぐ[【GitLab Duoの無料トライアル】](https://about.gitlab.com/gitlab-duo/#free-trial)を始めましょう。\n\n## 「GitLab Duo開発の現場から」シリーズをもっと読む\n\n- [GitLab Duo開発の現場から：AIモデルの大規模な検証とテスト方法](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n- [GitLab Duo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n- [GitLab Duo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n- [GitLab Duo開発の現場から：AI生成コードの安全性確認と詳細なテスト](https://about.gitlab.com/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n\n ## リソース\n- [GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/)\n- [GitLabの製品開発におけるAI倫理原則](https://handbook.gitlab.com/handbook/legal/ethics-compliance-program/ai-ethics-principles/)\n- [GitLab AIを活用したディレクションページ](https://about.gitlab.com/direction/ai-powered/)\n\n\u003Cfigure class=video_container>\n\u003Ciframe width=560 height=315 src=\"https://www.youtube-nocookie.com/embed/LifJdU3Qagw?si=A4kl6d32wPYC4168\" title=\"YouTube video player\" frameborder=0 allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen=\"\">\u003C/iframe>\n\u003C/figure>\n",[721,702,904,678,1880],{"slug":3533,"featured":92,"template":681},"developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale","content:ja-jp:blog:developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","Developing Gitlab Duo How We Validate And Test Ai Models At Scale","ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"_path":3539,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3540,"content":3546,"config":3553,"_id":3555,"_type":16,"title":3556,"_source":17,"_file":3557,"_stem":3558,"_extension":20},"/ja-jp/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"title":3541,"description":3542,"ogTitle":3541,"ogDescription":3542,"noIndex":6,"ogImage":3543,"ogUrl":3544,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3544,"schema":3545},"GitHub Advanced SecurityプランからGitLab Ultimateプランへの移行ガイド","GitLab UltimateとGitHub Advanced Securityの共通点と違いを理解し、GitLab DevSecOpsプラットフォームへの移行を段階的に進めるための詳細ガイドです。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","https://about.gitlab.com/blog/migration-guide-github-advanced-security-to-gitlab-ultimate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitHub Advanced SecurityプランからGitLab Ultimateプランへの移行ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-05-01\",\n      }",{"title":3541,"description":3542,"authors":3547,"heroImage":3543,"date":3548,"body":3549,"category":722,"tags":3550,"updatedDate":3552},[1507],"2024-05-01","GitLabは、最も包括的なAIを搭載したDevSecOpsプラットフォームで、ソフトウェアデリバリーライフサイクル全体を1つのプラットフォームで実現することで、より安全で迅速なソフトウェアのリリースを可能にしています。GitHubでは、GitHub内の追加のセキュリティ機能を有効にするAdvanced\nSecurityアドオンを提供してはいますが、GitLabと比較すると、ネイティブに提供するセキュリティ機能の深さと幅広さでは機能の範囲と深さが限定的です。SDLCのすべての領域にわたってセキュリティを強化すべくGitLab\nUltimateプランへの移行を検討している組織は、このガイドを参考にして両製品を比較し、またGitLabプラットフォームに移行するためのチュートリアルとしてもお役立てください。\n\n\nこの記事には次の内容が含まれます\n\n\n- GitLab UltimateとGitHub Advanced Securityの比較\n\n- GitHubリポジトリをGitLabに移行する方法\n\n- GitHub Advanced SecurityからGitLab Ultimateへの機能別の移行方法\n\n- GitLab Ultimateのセキュリティ追加機能の紹介\n\n\n## GitLab UltimateとGitHub Advanced Securityの比較\n\n\n[GitLab\nUltimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)は、安全なソフトウェアをより速く提供したいと考えている企業向けの、GitLabの最上位サブスクリプションプランです。GitHub\nAdvanced Securityは、追加のセキュリティ機能を有効にするGitHub Enterpriseのアドオンです。\n\n\n### GitLab UltimateとGitHub Advanced Securityの類似点\n\n\nGitLab UltimateとGitHub Advanced Securityの両プランに次の機能が搭載されています。\n\n\n-\n静的アプリケーションセキュリティテスト（[SAST](https://docs.gitlab.com/ee/user/application_security/sast/)）、シークレットスキャン、依存関係スキャン\n\n- コンテキスト脆弱性インテリジェンスと解決策のアドバイス\n\n-\n依存関係またはソフトウェア部品表のリスト（[SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)）\n\n- セキュリティ指標と分析情報\n\n\n### GitLab UltimateとGitHub Advanced Securityの相違点\n\n\nGitLab Ultimateは、次の点でGitHub Advanced Securityと異なります。\n\n\n-\nGitLabは、コンテナスキャン、動的アプリケーションセキュリティテスト（[DAST](https://docs.gitlab.com/ee/user/application_security/dast/)）、Web\nAPIファジングなどの追加のコードスキャナーをネイティブに提供します。スキャナーは、カスタムルールセットを備え最適化された、独自のオープンソーステクノロジーを組み合わせたものです。完全なリストについては、[GitLab\nAppSecのドキュメント](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html)をご覧ください。\n\n-\nGitLabは、セキュリティ上問題のあるコードが承認なしにマージされることを防ぐため、[詳細な制御機能（セキュリティガードレール）](https://docs.gitlab.com/ee/user/application_security/policies/)を提供しています。\n\n\n-\nGitLabセキュリティスキャナーは、[インターネット未接続（エアギャップ）環境や制限付きネットワーク環境](https://docs.gitlab.com/ee/user/application_security/offline_deployments/)でも実行可能です。\n\n\n-\nGitLabは、組織全体のコンプライアンス違反を監視できる[コンプライアンスセンター](https://docs.gitlab.com/ee/user/compliance/compliance_center/)を提供しています。\n\n\nさらにGitLab\nUltimateでは、追加のセキュリティやコンプライアンス機能、ポートフォリオとバリューストリームの管理、アップグレード時のライブサポート機能なども提供しています。追加機能の詳細については、[GitLab\nUltimateのドキュメント](https://about.gitlab.com/ja-jp/pricing/ultimate/)を参照してください。\n\n\n## GitHubリポジトリをGitLabに移行する方法\n\n\nGitLabには、GitHub.comまたはGitHub\nEnterpriseからGitHubプロジェクトをGitLabにインポートできるインポーターが組み込まれています。インポーターを使用すると、GitHubリポジトリだけでなく、イシュー、コラボレーター（メンバー）、プルリクエストなど他のオブジェクトもGitLabに移行できます。移行できるものの全リストについては、[GitHubインポートされたデータのドキュメント](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data)を参照してください。移行は次の手順で行います。\n\n1. 左側のサイドバー上部で **新規作成（+）** を選択する\n\n3. **GitLab内**セクションで**新しいプロジェクト/リポジトリ**を選択する\n\n4. **プロジェクトのインポート**を選択する\n\n\n![迷路化したバージョンの中心にGitLabのアイコン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\n\n4. **GitHub**ボタンを押す\n\n- GitLab\nSelf-Managedを使用している場合は、[GitHubインポーターを有効にする](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources)必要があります\n\n- 他のインポーターも同様の方法で開始できます\n\n5. これで、以下のいずれかが可能になりました\n\n- **GitHubで認証**を選択して、GitHub Oauthで認証する\n\n- GitHubのパーソナルアクセストークンを使う\n  - [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new)に移動します\n  - **Note**フィールドにトークンの説明を入力します\n  - **リポジトリ**スコープを選択します\n  - オプションとしてコラボレーターをインポートするには、**read:org**スコープを選択します\n  - **トークンを生成**ボタンを押します\n  - GitLabのインポートページのパーソナルアクセストークンフィールドに、GitHubのパーソナルアクセストークンを貼り付けます\n6. **認証**ボタンを押す\n\n7. 移行するアイテムを選択する\n\n8. 移行するプロジェクトと場所を選択する\n\n9. **インポート**ボタンを押す\n\n\nインポートされたプロジェクトがワークスペースにあることをご確認ください。GitHubからGitLabへの移行に関するさらに詳しいガイダンスは、次の動画をご覧ください。\n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=HEpZVy94cpfPfAky\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!--空白行-->\n\n\n[GitHubパーソナルアクセストークン](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token)または[GitLab\nREST\nAPI](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api)を使用した移行も可能です。また、インポーターは、BitbucketやGiteaなどの他のソースからのインポートも支援します。詳細については、[インポーターのドキュメント](https://docs.gitlab.com/ee/user/project/import/)を参照してください。\n\n\n## 機能別の移行方法\n\n\n次は、GitLab UltimateのGitHub Advanced\nSecurityが提供する各機能の活用方法について見てみましょう。続行するには、[GitLab\nUltimateライセンス](https://about.gitlab.com/ja-jp/pricing/ultimate/)が必要です。GitLabは、[無料トライアル](https://about.gitlab.com/ja-jp/free-trial/devsecops/)がお試しいただけます。\n\n\n### コードスキャン\n\nGitHubでは、静的ソースコードの文脈上の脆弱性インテリジェンスやアドバイスを提供する目的でコードスキャンを実行しています。[SAST](https://docs.gitlab.com/ee/user/application_security/sast/)を有効にすることで、GitLab内でも同じことができます。GitLab\nSASTスキャナーは、GitHubの[CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql)よりも幅広いプログラミング言語とフレームワークをカバーしています。\n\n\nGitLabでコードスキャンを有効にすれば、[SASTテンプレート](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml)を`.gitlab-ci.yml`に追加するだけです。\n\n\n```yaml\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\n\nテンプレートが追加されると、新しいコードがチェックインされるたびに、SASTはプロジェクトで使用されている[プログラミング言語](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)を自動的に検出します。そして、ソースコードに既知の脆弱性がないかスキャンします。\n\n\n**注：**\nセキュリティスキャナーは、GitLabの[セキュリティ設定](https://docs.gitlab.com/ee/user/application_security/configuration/)からプロジェクトに追加することもできます。これにより、パイプラインを更新するためのマージリクエストを自動的に作成できます。詳細については、[UIドキュメントを使用してSASTを構成する](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-by-using-the-ui)を参照してください。\n\n\nフィーチャーブランチとターゲットブランチの差分のSAST結果は、マージリクエストウィジェットで表示されます。マージリクエストウィジェットには、マージリクエストで行われた変更によって導入されたSASTの結果と解決策が表示されます。\n\n\n![マージリクエストでのセキュリティスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/2-SAST-MR-View.png)\n\n\nどの脆弱性にも、詳細な説明、重大度、場所、解決情報など、修正を支援するデータが表示されます。\n\n\n![SASTの脆弱性の詳細](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/3-SAST-MR-View-Detailed.png)\n\n\n脆弱性への対処として次が挙げられます。\n\n\n-\n**脆弱性を無視**：デベロッパーがコメントで脆弱性を無視できるようにします。そうすることで、セキュリティチームがレビューを実行できるようになります。\n\n- **イシューを作成**：イシューを作成して、追加の監視が必要な脆弱性を追跡できるようにします。\n\n\nこれらの変更内容は、マージリクエスト内の**差分表示画面**でもインラインで確認できます。\n\n\n![SASTの脆弱性がビューを変更](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/4-SAST-MR-View-Changes.png)\n\n\n#### SASTスキャナーのカスタマイズ\n\n\nGitLabでは、SASTジョブの定義を上書きできるため、変数、依存関係、ルールなどのプロパティを変更できます。これは、SASTジョブと同じ名前のジョブ名を宣言し、上書きして実行できます。次に、テンプレートをインクルードした後にこの新しいジョブを配置し、その下に追加のキーを指定します。\n\n\nたとえば、次のような設定ができます：\n\n- `semgrep-sast`スキャナーが使用するバージョンを上書きする\n\n- `gosec-sast`を実行する前に、プライベートプロジェクトからモジュールを取得するスクリプトを実行する\n\n- すべてのスキャナーが最大深度10で検索するように設定する\n\n\n```yaml\n\ninclude：\n  - template：Jobs/SAST.gitlab-ci.yml\n\nvariables：\n  SEARCH_MAX_DEPTH：10\n\nsemgrep-sast：\n  variables：\n    SAST_ANALYZER_IMAGE_TAG：\"3.7\"\n\ngosec-sast：\n  before_script：\n    - |\n      cat \u003C\u003CEOF > ~/.netrc\n      machine gitlab.com\n      login $CI_DEPLOY_USER\n      password $CI_DEPLOY_PASSWORD\n      EOF\n```\n\n\n**注：** 利用可能なSASTジョブは、[' SAST.gitlab-ci.yml\n`テンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)にあります。設定については、[利用可能なSAST\nCI/CD変数のドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables)を参照してください。\n\n\n#### SASTルールセットのカスタマイズ\n\n\nGitLabはSASTアナライザーごとにコードを処理し、ルールを使用してソースコードの脆弱性を特定します。これらのルールは、スキャナーが報告する弱点の種類を決定します。\n\n\n-\nSemgrepを基盤としたSASTスキャナーについては、GitLabが検出ルールの作成、保守、サポートを一括して提供しています。Semgrepオープンソースエンジン、GitLabの管理による検出ルール、脆弱性追跡と誤検出のためのGitLab独自の技術を集結しています。\n\n- 他のSASTアナライザーの場合、ルールは各スキャナーのupstreamプロジェクトで定義されています。\n\n\nスキャンされるリポジトリ内の設定ファイルを定義することで、SASTスキャナーの動作をカスタマイズできます。\n\n- 事前定義されたルールを無効にする（すべてのアナライザーで利用可能）\n\n- 事前定義されたルールを上書きする（すべてのアナライザーで利用可能）\n\n- パススルーを使用してカスタム設定を合成することにより、事前定義されたルールを置き換える\n\n\nSASTルールの設定の詳細と例については、[SASTルール](https://docs.gitlab.com/ee/user/application_security/sast/rules.html)と[ルールセットのカスタマイズのドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html)を参照してください。\n\n\n### シークレットスキャン\n\n\nGitHubは、流出したシークレットを見つけ、ブロックし、取り消すことができるシークレットスキャンをサポートします。[シークレット検出](https://docs.gitlab.com/ee/user/application_security/secret_detection/)を有効にすることで、GitLab内でも同じことができます。\n\n\nGitLabでシークレット検出を有効にするには、次のテンプレートを'.gitlab-ci.yml `に追加するだけです。\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\n\nテンプレートが追加されると、新しいコードがチェックインされる（またはパイプラインが実行される）たびに、シークレットスキャナーは既知のシークレットのソースコードをスキャンします。パイプラインでのシークレット検出は、コードの各要素を別々にスキャンします。「デフォルトブランチ」を除くすべてのメソッドでは、パイプラインシークレット検出はワークツリーではなくコミットをスキャンします。シークレットスキャンの仕組みについては、[シークレット検出カバレッジドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#coverage)を参照してください。\n\n\nマージリクエストを作成する際、シークレット検出はソースブランチで行われたすべてのコミットをスキャンします。SASTと同様に、検出されたすべての脆弱性から、修正プロセスを支援するため、以下の情報（ロケーションなど）や識別子を提供します。\n\n\n![シークレット検出の脆弱性の詳細](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/5-Secret-Detection-MR-Detailed.png)\n\n\nSASTと同様に、マージリクエストから直接、脆弱性の無視やイシューの作成など、検出された脆弱性に対するアクションを取ることができます。\n\n\n#### シークレット検出ジョブのカスタマイズ\n\n\nGitLabではシークレット検出ジョブの定義を上書きして、変数や依存関係、ルールなどのプロパティを変更できます。上書きするには、シークレット検出ジョブと同名のジョブを宣言します。次に、テンプレートをインクルードした後に新しいジョブを配置し、その下に追加のキーを指定します。たとえば、次のような設定です。\n\n\n- シークレット検出ジョブの実行ステージを`security`に上書きする\n\n- 過去のコミットに対するスキャンを有効にする\n\n- シークレットアナライザーのバージョンを4.5に変更する\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n  stage: security\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n    SECRETS_ANALYZER_VERSION: \"4.5\"\n```\n\n\n**注：**\n利用可能なシークレット検出ジョブは、[SAST.gitlab-ci.ymlテンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml)にあります。利用可能な設定は、[利用可能なシークレット検出CI/CD変数のドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customizing-analyzer-settings)に記載されています。\n\n\n#### シークレット検出ルールセットのカスタマイズ\n\n\nシークレット検出アナライザーでは、GitLab\nUIに表示されるシークレットをカスタマイズできます。次のカスタマイズオプションは、個別または組み合わせて使用できます。\n\n\n- 定義済みルールを無効にする\n\n- 定義済みルールを上書きする\n\n- カスタム設定を合成する\n\n- リモート設定ファイルを指定する\n\n\nたとえば、`.gitlab/secret-detection-ruleset.toml`というファイルをプロジェクトのルートディレクトリに作成すると、デフォルトのGitLeaksパッケージがテストトークンの検出を無視するように拡張されます。\n\n\n```yaml\n\n### extended-gitleaks-config.toml\n\ntitle = \"extension of gitlab's default gitleaks config\"\n\n\n[extend]\n\n### Extends default packaged path\n\npath = \"/gitleaks.toml\"\n\n\n[allowlist]\n  description = \"allow list of test tokens to ignore in detection\"\n  regexTarget = \"match\"\n  regexes = [\n    '''glpat-1234567890abcdefghij''',\n ]\n```\n\n\n定義済みのアナライザールールを上書きする方法については、[シークレット検出のドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#override-predefined-analyzer-rules)を参照してください。\n\n\n#### シークレット漏洩時の自動対応機能\n\n\nGitLabシークレット検出は、特定のタイプの流出したシークレットを発見すると自動的に対応します。自動対応には次のようなアクションがあります。\n\n- 自動的にシークレットを失効させる\n\n-\nシークレットを発行したパートナーに通知し、パートナーはシークレットを取り消すか、その所有者に通知するか、またはその他の方法で不正利用からの保護につなげる\n\n\nGitLabは、パートナーが発行した認証情報がGitLab.comの公開リポジトリに流出した場合、パートナーへの通知も可能です。クラウドやSaaS製品を運用していて、このような通知の受け取りに興味があるという場合、GitLab\nToken Revocation APIから呼び出されるPartner APIを実装できます。\n\n\n詳しくは[流出したシークレットへの自動対応](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)を参照してください。\n\n\n### サプライチェーンのセキュリティ\n\n\nGitHubは、自動化されたセキュリティとバージョン更新、ワンクリックのSBOMにより、ソフトウェアサプライチェーンのセキュリティ確保、管理、レポートを可能にします。GitLabは依存関係スキャンと依存関係リスト（SBOM）機能を使って、サプライチェーンセキュリティのニーズを満たすことができます。\n\n\nGitLabで依存関係スキャンを有効にするには、`.gitlab-ci.yml`に以下のテンプレートを追加するだけです：\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\n\n\nテンプレートが追加されると、新しいコードがチェックインされるたびに、依存関係スキャンがプロジェクトで使われている[パッケージマネージャ](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers)を自動検出します。そして、使用されている依存関係に既知の脆弱性がないかスキャンします。フィーチャーブランチとターゲットブランチの差分の依存関係のスキャン結果は、マージリクエストウィジェットに表示されます。マージリクエストウィジェットは、マージリクエストで行われた変更によって導入された依存関係スキャンの結果と解決策を表示します。マージリクエストの中で、検出された脆弱性は、識別子、証拠、解決策といった、修正を支援する関連情報を表示します。\n\n\n![依存関係スキャナーの脆弱性の詳細](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/6-Dependency-Scanner-MR-View-Detailed.png)\n\n\nSASTやシークレット検出と同様に、脆弱性の無視やイシューの作成など、これらの脆弱性に対するアクションをマージリクエストから直接実行できます。\n\n\n#### 依存関係スキャンの設定\n\n\nジョブの定義を上書きするには（たとえば、変数や依存関係のようなプロパティを変更するには）、上書き対象のジョブと同じ名前で新しいジョブを宣言します。テンプレートをインクルードした後に新しいジョブを配置し、その下に追加のキーを指定します。たとえば、次のコードでは以下の設定を行っています。\n\n\n- 脆弱な依存関係の自動修正を無効にする\n\n- 依存関係スキャンの実行前にビルドジョブの完了を要求する\n\n\n```yaml\n\ninclude：\n  - template：Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning：\n  variables：\n    DS_REMEDIATE：\"false\"\n  dependencies：[\"build\"]\n```\n\n\n依存関係スキャナーの設定についての詳細は、[アナライザーの動作をカスタマイズするドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-analyzer-behavior)を参照してください。\n\n\n#### SBOMの生成\n\n\nGitLabの依存関係リスト（SBOM）で、プロジェクトやグループの依存関係や、既知の脆弱性を含む依存関係の重要な詳細を確認できます。このリストには、プロジェクトにおける依存関係が集約されており、既知のものや新たに検出されたものの両方が含まれています。依存関係リストは、依存関係スキャナーが[デフォルトブランチ](https://docs.gitlab.com/ee/user/project/repository/branches/default.html)で正常に実行された後に生成されます。依存関係リストにアクセスするには\n\n\n1. 左サイドバーで、**検索または移動先...** を選択し、プロジェクトを見つけます。\n\n2. **セキュリティ > 依存関係リスト**の順に選択します。\n\n\n![依存関係リスト（SBOM）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/7-Dependency-List.png)\n\n\nここから、依存関係に関する次の情報を表示できます。\n\n\n|フィールド|説明|\n\n| ---------- | ---------- |\n\n|コンポーネント|依存関係の名前とバージョン。|\n\n|パッケージャー| 依存関係のインストールに使用されるパッケージャー。|\n\n|ロケーション|\nシステムの依存関係の場合、スキャンされたイメージのリストが表示されます。アプリケーションの依存関係の場合、依存関係を宣言したプロジェクト内のパッケージャー固有のロックファイルへのリンクが表示されます。また、トップレベルの依存関係への依存関係パスも表示されます（該当の依存関係が存在する場合）。| \n\n|ライセンス| 依存関係のソフトウェアライセンスへのリンク依存関係で検出された脆弱性の数を示す警告バッジ。| \n\n|プロジェクト|\n依存関係のあるプロジェクトへのリンク。同じ依存関係を持つプロジェクトが複数ある場合、プロジェクトの合計数が表示されます。依存関係のあるプロジェクトに移動するには、プロジェクトの番号を選択し、その名前を検索して選択します。プロジェクト検索機能は、グループ階層内に最大600件のプロジェクトがあるグループでのみサポートされています。|\n\n\n\u003Cp>\u003C/p>\n\n\n詳細については、[依存関係リストのドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_list/)を参照してください。\n\n\n### セキュリティとコンプライアンスの管理\n\n\nGitHub Advanced\nSecurityを使用すると、セキュリティメトリクスとインサイトを閲覧し、コードセキュリティリスクを評価できます。次に、GitLab\nUltimateで同じことをする方法を見てみましょう。\n\n\n#### セキュリティメトリクスとインサイトの閲覧\n\n\nGitLabは、アプリケーションのセキュリティ状況を評価するのに役立つ[セキュリティダッシュボード](https://docs.gitlab.com/ee/user/application_security/security_dashboard/)を提供しています。ダッシュボードには、プロジェクトで実行されたセキュリティスキャナーによって検出された脆弱性のメトリクス、評価、チャートがまとめて表示されます。\n\n\n- グループ内のすべてのプロジェクトの30日、60日、90日間の期間にわたる脆弱性の傾向\n\n- 脆弱性の重大度に基づく各プロジェクトの評価（A~Fの文字グレード評価）\n\n- 過去365日以内に検出された脆弱性の総数とその重大度\n\n\nセキュリティダッシュボードにアクセスする方法：\n\n\n1. 左側のサイドバーで、**検索または移動先...** を選択し、プロジェクトまたはグループを見つけます。\n\n2. サイドタブから、**セキュリティ > セキュリティ** ダッシュボードを選択します。\n\n3. 必要なものを絞り込んで検索します。\n\n\nグループビューには、グループ内のすべてのプロジェクトのセキュリティ状況が表示されます。\n\n\n![グループセキュリティダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\n\nプロジェクトビューには、あるプロジェクトのみのセキュリティ体制が表示されます。\n\n\n![プロジェクトセキュリティダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n\n#### コードのセキュリティリスクを評価\n\n\nGitLab\nUltimateは、デフォルトブランチのスキャン結果から脆弱性に関する情報を提供する[脆弱性レポート](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)を備えています。レポートには、パイプラインが成功したかどうかにかかわらず、すべての成功したジョブの累積結果が含まれます。すべてのレベルで、脆弱性レポートには次が表示されます。\n\n\n- 重大度レベルごとの脆弱性の合計\n\n- 一般的な脆弱性の属性のフィルター\n\n- 表形式のレイアウトで表示される各脆弱性の詳細\n\n\n![脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\n\n脆弱性をクリックすると、その[脆弱性ページ](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/)にアクセスできます。このページには、脆弱性の説明、ロケーション、識別子などの情報が記載されています。以下は、SASTスキャナーによって検出されたSQLインジェクションの脆弱性のページの例です。\n\n\n![SQLインジェクションの脆弱性ページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/11-Vulnerability-Page-1.png)\n\n\nここから、セキュリティチームは、[理由とともに脆弱性の状態を変更](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability)し、[変更をより適切に追跡するためのイシューを作成する](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability)ことでコラボレーションできます。\n\n\n脆弱性のページから、AI搭載の各機能が集約された[GitLab\nDuo](https://about.gitlab.com/ja-jp/gitlab-duo/)を活用して脆弱性を説明し、[脆弱性を解決するマージリクエストを自動的に作成する](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution)こともできます。\n\nGitLab\nDuoの[脆弱性の説明](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation)は、大規模な言語モデルを使用して次を行います。\n\n\n- 脆弱性を要約する\n\n- 脆弱性について、どのように悪用される可能性があるか、どのように修正するかをデベロッパーやセキュリティアナリストが理解できるようにする\n\n- 緩和策を推奨する\n\n\n![SQLインジェクションGitLab Duo\nAIの説明](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/13-Explain-Vulnerability.png)\n\n\n## GitLab Ultimateのセキュリティ追加機能\n\n\nGitLab Ultimateには、GitHub Advanced\nSecurityにはない多くのセキュリティ機能を搭載しています。追加のセキュリティ機能の例として、ソフトウェア開発ライフサイクル（SDLC）全体のための追加のセキュリティスキャナー、きめ細かいセキュリティガードレール、カスタム権限などが挙げられます。\n\n\n### SDLC全体のセキュリティスキャナー\n\n\n当社のセキュリティスキャナーのポートフォリオは、SDLC全体に対応しています。\n\n\n|スキャナー名|スキャン|スキャンされた言語/ファイル|\n\n| -------------- | ----- | ------------------------- |\n\n|\n[静的アプリケーションセキュリティテスト（SAST）](https://docs.gitlab.com/ee/user/application_security/sast/)|静的ソースコード|\nC/C++、Java、Python、Go、JavaScript、C #など|\n\n|\n[動的アプリケーションセキュリティテスト（DAST）](https://docs.gitlab.com/ee/user/application_security/dast/)|\nWebアプリケーション、ライブAPIの実行|言語に依存しない|\n\n|[Infrastructure as\nCode（IaC）のスキャン](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)|\nIaCファイル| Terraform、AWS Cloud Formation、Ansibleなど|\n\n|\n[コンテナのスキャン](https://docs.gitlab.com/ee/user/application_security/container_scanning/)|静的および実行中のコンテナイメージ|\nDockerfile |\n\n|\n[依存関係のスキャンとライセンスのスキャン](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)|アプリケーションの依存関係|\nRequirements.txt、Yarn、Gradle、Npmなど|\n\n| [Web\nAPIファズテスト](https://docs.gitlab.com/ee/user/application_security/api_fuzzing)|ランダム/不正な形式のデータをweb\n- apiに送信| OpenAPI、GraphQL、HAR、Postman Collection |\n\n|[カバレッジ -\nガイド付きファズテスト](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)|ランダム/不正な形式のデータを関数に送信|\nC/C++、Go、Swift、Python、Rust、Java、JavaScript、AFL |\n\n\n\u003Cp>\u003C/p>\n\n\nGitLabでは、[サードパーティのスキャナー（英語）](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)と[カスタムスキャナー（英語）](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/)をプラットフォームに統合することもできます。スキャナーの結果は、パイプラインビュー、マージリクエストウィジェット、セキュリティダッシュボードなど、GitLabのさまざまな場所に自動的に表示されます。詳細については、[セキュリティスキャナー統合ドキュメント](https://docs.gitlab.com/ee/development/integrations/secure.html)を参照してください。\n\n\n### きめ細かいセキュリティとコンプライアンスポリシー\n\n\nGitLabのポリシーは、セキュリティとコンプライアンスの両チームに[組織内でグローバルに制御を実施する方法（英語）](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)を提供します。セキュリティチームは次のことを保証できます。\n\n\n- 適切な設定で開発チームのパイプラインにセキュリティスキャナーを実施\n\n- すべてのスキャンジョブは、変更や修正なしで実行\n\n- これらの調査結果に基づき、マージリクエストに対して適切な承認を提供\n\n\n![マージリクエストのセキュリティポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/14-MR-Policy.png)\n\n\nコンプライアンスチームは、すべてのマージリクエストに対して複数の承認者を必須とし、マージリクエストやリポジトリの設定を有効化またはロックするなど、組織の要件に基づくプロジェクトでさまざまな設定が有効になっていることを確認できます。詳細については、[GitLabセキュリティポリシーのドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/)を参照してください。\n\n\n### カスタムロールときめ細かい権限\n\n\n[GitLab\nUltimateはカスタムロールを提供します（英語）](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/)。これにより、組織はニーズに見合った正確な特権と権限を持つユーザーロールを作成できます。\n\n\nたとえば、ユーザーはシステム内のセキュリティの脆弱性を表示する権限を持つ「セキュリティ監査担当者」ロールを作成できますが、この権限ではソースコードを表示したり、リポジトリ内で変更を実行したりできないよう設定できます。このきめ細かい権限設定により、職務の棲み分けを明確にできます。\n\n\n![カスタムロールの作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\n\n詳細については、[カスタムロール](https://docs.gitlab.com/ee/user/custom_roles.html)および[利用可能な詳細な権限のドキュメント](https://docs.gitlab.com/ee/user/custom_roles/abilities.html)を参照してください。\n\n\n### コンプライアンスセンター\n\n\nコンプライアンスチームが、コンプライアンス基準の遵守状況や違反についての報告、グループのコンプライアンスフレームワークの管理などを一括して行う場所がコンプライアンスセンターです。コンプライアンスセンターには次の内容があります。\n\n\n-\n[コンプライアンス基準遵守ダッシュボード](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html)は、GitLab標準に準拠したプロジェクトの遵守状況を一覧表示します。\n\n-\n[コンプライアンス違反の報告](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html)は、グループ内のすべてのプロジェクトのマージリクエストアクティビティの概要を表示します。\n\n-\n[コンプライアンスフレームワークのレポート](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html)は、グループ内のコンプライアンスに関するすべてのフレームワークを表示します。\n\n-\n[コンプライアンスプロジェクトのレポート](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html)は、グループ内のプロジェクトに適用されるコンプライアンスのフレームワークを表示します。\n\n\n![コンプライアンスセンター](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\n\nこれらのダッシュボードは、組織内のコンプライアンスを最適化するために、職務の棲み分けがきちんと守られているかを確認する上で有益です。詳細については、[コンプライアンスセンターのドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance_center/)を参照してください。\n\n\n## 続きを読む\n\n\nこの記事では、GitLab Ultimateが提供する幅広いセキュリティ機能の一部についてのみ説明しています。GitLab\nUltimateが組織のセキュリティとデベロッパーの効率を向上させる方法について、詳しくは次のリソースを参照してください。\n\n\n- [Ultimateを選ぶ理由](https://about.gitlab.com/ja-jp/pricing/ultimate/)\n\n-\n[DevSecOpsチュートリアルを始める](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n\n-\n[DevSecOpsサンプルプロジェクトの始め方](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n\n-\n[プロジェクトをGitHubからGitLabドキュメントにインポートする](https://docs.gitlab.com/ee/user/project/import/github.html)\n\n- [GitHub\nActionsドキュメントからの移行](https://docs.gitlab.com/ee/ci/migration/github_actions.html)\n\n- [チュートリアル：最初のGitLab\nCI/CDパイプラインを作成して実行する](https://docs.gitlab.com/ee/ci/quick_start/)\n\n-\n[チュートリアル：複雑なパイプラインを作成する](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)\n\n- [CI/CD YAML構文リファレンス](https://docs.gitlab.com/ee/ci/yaml/)\n\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[676,3551,722,904,2378],"zero trust","2024-12-25",{"slug":3554,"featured":92,"template":681},"migration-guide-github-advanced-security-to-gitlab-ultimate","content:ja-jp:blog:migration-guide-github-advanced-security-to-gitlab-ultimate.yml","Migration Guide Github Advanced Security To Gitlab Ultimate","ja-jp/blog/migration-guide-github-advanced-security-to-gitlab-ultimate.yml","ja-jp/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"_path":3560,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3561,"content":3567,"config":3573,"_id":3575,"_type":16,"title":3576,"_source":17,"_file":3577,"_stem":3578,"_extension":20},"/ja-jp/blog/whats-new-in-git-2-45-0",{"title":3562,"description":3563,"ogTitle":3562,"ogDescription":3563,"noIndex":6,"ogImage":3564,"ogUrl":3565,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3565,"schema":3566},"Git 2.45.0の新機能","ここでは、GitLabのGitチームと、より広範なGitコミュニティが最新のGitリリースにコントリビュートしたいくつかのハイライトを紹介します。これには、「reftables」や参照用の優れたツールなどが挙げられます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-45-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.45.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-04-30\",\n      }",{"title":3562,"description":3563,"authors":3568,"heroImage":3564,"date":3569,"body":3570,"category":962,"tags":3571,"updatedDate":3572},[1643],"2024-04-30","Gitプロジェクトは最近、[Gitバージョン2.45.0](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/)をリリースしました。このリリースのハイライトを見てみましょう。これには、GitLabのGitチームと、より広範なGitコミュニティからのコントリビュートによるものがあります。\n\n\n## Reftables: 新しい参照ストレージバックエンド\n\n\nすべてのGitリポジトリは、次の2つの基本的なデータ構造を追跡する必要があります:\n\n\n- ファイルのデータ、ディレクトリ構造、コミットメッセージ、タグを保存するオブジェクトグラフ。\n\n- 特定のオブジェクトをよりアクセスしやすい名前に関連付けるためのオブジェクトグラフへのポインタである参照。たとえば、ブランチは名前が\n`refs/heads/` プレフィックスで始まる参照です。\n\n\n参照がリポジトリに保存されるディスク上のフォーマットは、Gitの発足以来ほとんど変わっておらず、「files」フォーマットと呼ばれています。参照を作成するたびに、Gitは、パスが参照名と一致するGitリポジトリ内のプレーンなファイルである、いわゆる「ルース参照」を作成します。たとえば、\n\n\n```shell\n\n$ git init .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n\n# Updating a reference will cause Git to create a \"loose ref\". This loose\nref is\n\n# a simple file which contains the object ID of the commit.\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n[main (root-commit) c70f266] Initial commit\n\n$ cat .git/refs/heads/main\n\nc70f26689975782739ef9666af079535b12b5946\n\n\n# Creating a second reference will end up with a second loose ref.\n\n$ git branch feature\n\n$ cat .git/refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946\n\n$ tree .git/refs\n\n.git/refs/\n\n├── heads\n\n│   ├── feature\n\n│   └── main\n\n└── tags\n\n\n3 directories, 2 files\n\n```\n\n\n時々、Gitはそれらの参照を「パックされた」ファイルフォーマットにパックして、参照をより効率的に検索できるようにします。たとえば、\n\n\n```shell\n\n# Packing references will create \"packed\" references, which are a sorted\nlist of\n\n# references. The loose reference does not exist anymore.\n\n$ git pack-refs --all\n\n$ cat .git/refs/heads/main\n\ncat: .git/refs/heads/main: No such file or directory\n\n$ cat .git/packed-refs\n\n# pack-refs with: peeled fully-peeled sorted\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n\n```\n\n\nこのフォーマットはかなりシンプルですが、次のような制限があります。\n\n\n-\n多くの参照を持つ大規模な単一のリポジトリでは、スケーラビリティの問題が発生し始めました。参照を削除することは、特に非効率的です。なぜなら、削除済みの参照を削除するには、「packed\n-\nrefs」ファイル全体を書き換える必要があるからです。当社の最大のリポジトリでは、参照を削除するごとに数ギガバイトのデータを書き換える可能性があります。\n\n- すべての参照を把握するには複数のファイルを読み取る必要があるため、同時に書き込みを行うことなく参照をアトミックに読み取ることはできません。\n\n- 複数のファイルを作成または更新する必要があるため、アトミックに書き込みを実行することができず、ワンステップで実行できません。\n\n- 完全な「packed - refs」ファイルを書き換える必要があるため、参照のメンテナンスはスケーリングがうまくいきません。\n\n-\nルース参照はファイルシステムパスをその名前として使用するため、ファイルシステム固有の動作の対象となります。例えば、大文字と小文字を区別しないファイルシステムは、単に大文字と小文字が異なるだけの参照を保存することはできません。\n\n\nこれらの問題に対処するために、Git\nv2.45.0は新しい「reftable」バックエンドを導入しました。これは、新しいバイナリフォーマットを使用して参照を保存します。この新しいバックエンドは非常に長い間開発され続けてきました。最初は2017年7月に[Shawn\nPearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/)によって提案され、[JGit](https://www.eclipse.org/jgit/)に実装されました。これは[Gerrit\nプロジェクト](https://www.gerritcodereview.com/)で広く使用されています。2021年、[Han-Wen\nNienhuys](https://hanwen.home.xs4all.nl/)がライブラリをGitにアップストリームし、[reftableフォーマット](https://git-scm.com/docs/reftable)の読み取りと書き込みを可能にしました。\n\n\nGit v2.45.0\nでアップストリームした新しい「reftable」バックエンドは、ついにreftableライブラリとGitを統合し、新しいフォーマットをGitリポジトリのストレージバックエンドとして使用できるようになりました。\n\n\n少なくともGit v2.45.0を使用していれば、`--ref-format=reftable` スイッチを`git-init(1)` または\n`git-clone(1)` のいずれかに渡すことで、「reftable」フォーマットを使用して新しいリポジトリを作成できます。たとえば、\n\n\n```shell\n\n$ git init --ref-format=reftable .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n$ git rev-parse --show-ref-format\n\nreftable\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/tables.list\n\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n\n.git/reftable/tables.list\n\n```\n\n\nご覧のとおり、参照は `.git/refs` ディレクトリではなく `.git/reftable` に保存されています。参照と参照ログは、`.ref`\nで終わるファイルである「テーブル」に保存されますが、`tables.list`\nファイルには現在アクティブなすべてのテーブルのリストが含まれています。この仕組みの技術的な詳細については、別のブログ記事でご説明します。引き続きブログをご覧いただくようお願いいたします。\n\n\n「reftable」バックエンドは、「files」バックエンドに取って代わるものです。したがって、ユーザーの観点からは、すべてが同じように機能する必要があります。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。また、Shawn\nPearceがフォーマットのオリジナルを発案、Han - Wen Nienhuysがreftableライブラリを作成しています。\n\n\n## 参照用ツールの改善\n\n「reftable」フォーマットは、私たちが抱えている多くの問題を解決してくれる一方で、新しい問題も生み出しています。\n最も重要な問題の1つが、格納されているデータへのアクセシビリティです。\n\n\n「files」バックエンドを使用すると、最悪の場合、通常のUnixツールを使用して参照の状態を調べることになります。「packed」参照と「loose」参照の両方には、人間が簡単に理解できるデータが含まれています。これは、バイナリフォーマットである「reftable」フォーマットとは異なります。したがって、Gitは新しい「reftable」フォーマットからデータを抽出するために必要なすべてのツールを提供する必要があります。\n\n\n### すべての参照の一覧表示\n\n最初の問題は、リポジトリからすべての参照を把握するのは基本的に不可能であるということです。\nGitで参照を作成したり変更できるのに、すべての参照を網羅的にリストできないと聞くと、困惑する方もいるかもしれません。\n\n\n確かに、「files」バックエンドはできません。`refs/`\nプレフィックスで始まるすべての「通常の」参照を簡単にリストすることはできますが、Gitはいわゆる[pseudo\nrefs](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpseudorefapseudoref)（疑似参照）も使用します。これらのファイルはGitディレクトリのルートに直接存在し、たとえば\n`.git/MERGE_HEAD` などのようなファイルです。問題は、これらの疑似参照が、Gitが格納する、たとえば `.git/config`\nのような他のファイルの隣に存在することです。\n\n\n一部の疑似参照はよく知られているため識別しやすく、理論上はGitが書き込むことができる参照に制限はありません。「foobar」という参照を作成するのを妨げるものはありません。\n\n\nたとえば、\n\n\n```shell\n\n$ git update-ref foobar HEAD\n\n$ cat .git/foobar\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n\n```\n\n\n「files」バックエンドにある問題は、ディレクトリをスキャンして参照を列挙するしかないということです。したがって `.git/foobar`\nが実際には参照であることを理解するために、Gitはファイルを開き、ファイルが参照のようにフォーマットされているかどうかを確認する必要があります。\n\n\n一方、「reftable」バックエンドは、それに含まれるすべての参照について簡単に認識します。参照はデータ構造にエンコードされているため、それらの参照をデコードして返すだけです。しかし、「files」バックエンドの制限により、存在するすべての参照について学ぶことができるツールは存在しません。\n\n\nこの問題に対処するために、`git-for-each-ref(1)` に `--include-root-refs`\nという新しいフラグを追加しました。これにより、参照名の階層のルートに存在するすべての参照もリストアップされます。\n\nたとえば、\n\n\n```shell\n\n$ git for-each-ref --include-root-refs\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n\n```\n\n\n「files」バックエンドの場合、この新しいフラグはベストエフォートで処理され、既知の疑似参照名に一致するすべての参照が含まれます。「reftable」バックエンドの場合、それに関連するすべての参照をすべてリストアップすることができます。\n\n\nこのプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n\n### すべての参照ログの一覧表示\n\n\nブランチを更新するたびに、Gitはデフォルトでそれらのブランチの更新をいわゆる参照ログで追跡します。この参照ログを使用すると、意図しない変更を行った場合に、そのブランチへの変更をロールバックできるため、非常に役立つツールとなります。\n\n\n「files」バックエンドでは、これらのログは `.git/logs` ディレクトリに保存されます。\n\n\n```shell\n\n$ find -type f .git/logs/\n\n.git/logs/HEAD\n\n.git/logs/refs/heads/main\n\n```\n\n\n実際、このディレクトリ内のファイルを一覧表示することが、そもそもどの参照が実際に参照ログを保持しているかを知る唯一の方法です。これは、参照と一緒にそれらのログを保存する「reftable」バックエンドの問題です。そのため、「reftable」フォーマットを使用すると、リポジトリにどの参照ログが存在するかを知る方法はまったくありません。\n\n\nこれは実際には「reftable」フォーマットの欠陥ではありませんが、Gitが提供するツールにおける不備です。この欠落に対処するために、`git-reflog(1)`\nに新しい `list` サブコマンドを導入しました。これにより、すべての既存の参照ログをリストアップできます。\n\n\n```shell\n\n$ git reflog list\n\nHEAD\n\nrefs/heads/main\n\n```\n\n\nこのプロジェクトは、[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n### 参照のより効率的なパッキング\n\n\nGitリポジトリを効率的に保つには、定期的なメンテナンスが必要です。 通常、このメンテナンスは `git maintenance run --auto`\nを実行してGitリポジトリにデータを書き込むさまざまなGitコマンドによってトリガーされます。このコマンドは、Gitが計算リソースを無駄にしないように、実際に最適化が必要なデータ構造のみを最適化します。\n\n\nGitのメンテナンスによって最適化されるデータ構造の1つは、`git pack-refs --all`\nを実行することによって行われる参照データベースです。「files」バックエンドの場合、これは、すべての参照が「packed -\nrefs」ファイルに再パックされ、ルース参照が削除されることを意味します。一方、「reftable」バックエンドの場合、すべてのテーブルが単一のテーブルにマージされます。\n\n\n「files」バックエンドについては、合理的に改善することはできません。「packed -\nrefs」ファイル全体を書き直す必要があることを考えると、すべてのルース参照をパックしたいと考えるのは理にかなっています。\n\n\nしかし、「reftable」バックエンドの場合、「reftable」バックエンドが自己最適化されるため、最適ではありません。Gitは、新しいテーブルを「reftable」バックエンドに追加するたびに、必要に応じて自動コンパクションを実行し、テーブルを一緒にマージします。したがって、参照データベースは常に適切に最適化された状態にある必要があり、そのため、すべてのテーブルを一緒にマージすることは無駄な努力となります。\n\n\nそこでGit v2.45.0では、新しい `git pack-refs --auto`\nモードを導入し、参照バックエンドに必要に応じて最適化を行うようにしました。 「files」バックエンドは、`--auto`\nフラグが設定されていても同じように動作し続けますが、「reftable」バックエンドは、自動コンパクションにすでに使用されているのと同じ経験則を使用します。\n実際には、これはほとんどの場合何も操作を行いません。\n\n\nさらに、`git maintenance run --auto` は、デフォルトでこの新しいモードを使用するために、`-tauto` フラグを\n`git-pack-refs(1)` に渡すように調整されています。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## 補足情報\n\n\nこのブログ記事では、新しい「reftable」バックエンドに重点を置いています。このバックエンドにより、多くの参照を持つ大規模なリポジトリでの拡張性が向上しました。また、このバックエンドをうまく機能させるために関連したツールも導入しました。このGitリリースではさまざまなパフォーマンスの向上、バグ修正、その他の細かい機能がGitコミュニティによって導入されています。Gitプロジェクトの[公式リリース発表](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/)をご覧いただくと詳細をご確認いただけます。\n\n\n*監修：小松原 つかさ\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n\n## 過去のGitリリースへのコントリビューション\n\n* [Git\n2.44.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/gitlabs-contributions-to-git-2-44-0/)\n\n* [Git\n2.43.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/the-contributions-we-made-to-the-git-2-43-release/)\n\n* [Git\n2.42.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/contributions-to-git-2-42-release/)\n\n* [Git\n2.41.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/contributions-to-latest-git-release/)\n",[966,270],"2024-05-17",{"slug":3574,"featured":6,"template":681},"whats-new-in-git-2-45-0","content:ja-jp:blog:whats-new-in-git-2-45-0.yml","Whats New In Git 2 45 0","ja-jp/blog/whats-new-in-git-2-45-0.yml","ja-jp/blog/whats-new-in-git-2-45-0",{"_path":3580,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3581,"content":3587,"config":3593,"_id":3595,"_type":16,"title":3596,"_source":17,"_file":3597,"_stem":3598,"_extension":20},"/ja-jp/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"title":3582,"description":3583,"ogTitle":3582,"ogDescription":3583,"noIndex":6,"ogImage":3584,"ogUrl":3585,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3585,"schema":3586},"【トップ10】プロダクトマネージャーが一挙紹介！GitLabワークフロー テクニック","GitLabのプロダクトマネージャーが、GitLab DevSecOpsプラットフォームを効率的に操作し、チームコラボレーションを促進できるお気に入りのテクニックを一挙ご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099361/Blog/Hero%20Images/Blog/Hero%20Images/lightvisibility_lightvisibility.png_1750099361252.png","https://about.gitlab.com/blog/top-10-gitlab-workflow-hacks-you-need-to-know","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"【トップ10】プロダクトマネージャーが一挙紹介！GitLabワークフロー テクニック\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-04-09\",\n      }",{"title":3582,"description":3583,"authors":3588,"heroImage":3584,"date":3589,"body":3590,"category":740,"tags":3591,"updatedDate":3592},[1702],"2024-04-09","ソフトウェア開発の世界では、「効率」とは単に速く動くことではなく、スマートなナビゲーションのことも意味します。GitLabのプロダクトマネージャーとして、本日ご紹介する私のお気に入りのGitLab機能トップ10は、必要であることに気づいていなかったワークフローハックかもしれません。\n\nこれらのテクニックをぜひ身につけて、チーム内の生産性とコラボレーションを新たなレベルに引き上げてみませんか。\n\nそれでは一つずつ見ていきましょう。\n\n## 1. コメントの解決\n\nコメントの解決は、マージリクエスト上だけではありません。イシューへのコメントを解決することで、ノイズを大幅に減らし、タスク管理を合理化できます。特にフィードバックを効率的に管理するのに便利です。\n\n> __お気に入りの理由：__ コメントを解決することは、イシューのノイズを減らすだけでなく、タスクを管理する効果的な方法でもあるからです。\n> \n> **ユースケース：** コメントを解決することは、フィードバックを集めているイシューにとって有効な手法です。フィードバックに返信してリンクを提供し、コメントを解決して次のイシューに進みましょう。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/discussions/#resolve-a-thread)__\n\n![解決コメントの例 - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099376147.gif)\n\n\u003Cp>\u003C/p>\n\n## 2. 内部コメント\n\n外部の人に見られることなく、チームと直接相談することができます。イシューまたはマージリクエスト内のディスカッションは非公開にし、コメントはチームメンバーのみが閲覧できるようにしましょう。透明性とプライバシーのバランスが絶妙です。\n\n> __お気に入りの理由：__ プライバシーと透明性のバランスをとりながら、より幅広い議論をコミュニティに投げかけられるからです。\n> \n> __ユースケース：__ 例えば製品のローンチを調整する際、マーケティングチームが社内のコメントを使ってメッセージングや戦略について話し合い、練り直すことができます。ドラフトモード中もディスカッションは一元管理され、チームも簡単にアクセスできますよ。\n> \n> **[詳細はこちら](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note)**\n\n![内部コメント例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099376148.png)\n\n\u003Cp>\u003C/p>\n\n## 3. and/orフィルター\n\n一覧ページでレコードを検索する場合、and/orフィルターを使用することで、ノイズを切り分け、探しているものを素早く効率的に見つけることができます。\n\n> __お気に入りの理由：__ 必要なものを的確に見つけ、効率的で合理的なワークフローを実現するからです。\n> \n>**ユースケース：** 特定のグループに割り当てられた、特定のイニシアチブに関連する機能のイシューを検索します。\n>\n> __[詳細はこちら](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#filter-with-the-or-operator)__\n\n![および/またはフィルター例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/and_or__1__aHR0cHM6_1750099376152.gif)\n\n\u003Cp>\u003C/p>\n\n## 4. URLの自動展開\n\nGitLabのURLの末尾に '+' または '+s' を追加すると、そのURLは情報スニペットに変換され、チームメイトがページを離れることなく進捗を共有できるようになります。\n\n> __お気に入りの理由：__ URLのX線透視をするようなもので、クリックすることなく重要な情報を見ることができるからです。\n>\n> **ユースケース：** コメントで進捗状況を共有したい場合、リンクに '+s' を加えるだけで、誰もが即座に状況を把握できます。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/markdown.html#show-the-issue-merge-request-or-epic-title-in-the-reference)__\n\n![URLの自動展開の例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099376154.gif)\n\n\u003Cp>\u003C/p>\n\n## 5. クイック アクション\n\nシンプルなテキストコマンドを使用したショートカットであるクイック アクションでは、説明やコメント欄から直接、ユーザーの割り当てやラベルの追加などのタスクを実行できるため、クリック数と時間を減らせます。\n\n> __お気に入りの理由：__ クリック数と時間を減らして時間を節約できるからです。\n> \n> **ユースケース：** 新しいイシューを作成する際、クイック アクションを使用して、ラベル、マイルストーンを自動的に追加し、レコードを保存する際にエピックに接続します。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/project/quick_actions.html)__\n\n![クイック アクションの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099376156.gif)\n\n\u003Cp>\u003C/p>\n\n## 6. 一括編集\n\n複数のイシューに対して、ラベルの適用、担当者の変更、マイルストーンの更新を一度に行うことができます。この機能により、面倒になりがちなアップデートが簡単になり、数多くのイシューを素早く調整できるようになります。\n\n> __お気に入りの理由：__ 面倒な更新作業が、簡単かつ迅速に行えるようになるからです。\n> \n> **ユースケース：** スプリントのイシューすべてにレビューが必要なタグを付ける必要がある場合、フィルターをかけて、すべて選択し、ラベルを一括で追加するだけ。とても簡単です。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-edit-issues-from-a-project)__\n\n![一括編集の例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099376157.gif)\n\n\u003Cp>\u003C/p>\n\n## 7. エピックスイムレーン\nボード上のエピックでイシューをグループ化すると、進捗状況を視覚的に追跡し、議論できます。レビューやスタンドアップの際に、作業同士のつながりをわかりやすくします。\n\n> __お気に入りの理由：__ ボードを確認することで、仕事の背景を容易に理解できるからです。\n> \n> **ユースケース：** スタンドアップレビュー中にエピックごとにグループ化し、親イニシアチブと簡単に連携します。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issues-in-swimlanes)__\n\n![エピックスイムレーンの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099376158.gif)\n\n\u003Cp>\u003C/p>\n\n## 8. Wikiダイアグラム\n\n作成が簡単なダイアグラムを使用して、Wikiページに直接アイデアとワークフローを示します。この機能により視覚的に学習でき、複雑な概念を簡素化できます。\n\n> __お気に入りの理由：__ 非常にユーザーフレンドリーで柔軟性があるからです。\n> \n> **ユースケース：** 新しい機能のワークフローを概説する場合は、チーム全員が明確に理解できるように、Wikiページに直接描画します。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/administration/integration/diagrams_net.html)__\n\n![WiKiダイアグラムの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099376159.gif)\n\n\u003Cp>\u003C/p>\n\n## 9. 表の作成\n\n表の作成にはマークダウンを使用しないでください。リッチテキストエディターを使用すると、表を簡単に挿入および書式設定でき、ドキュメントをより明確に構造化できます。\n\n> __お気に入りの理由：__ これを使えば、表作成の手間が一気に省け、数回のクリックできれいに整理された更新をかけられます。\n> \n> **ユースケース：** スプリントのレトロスペクティブ（振り返り）を作成する際、表を素早く挿入して、フィードバック、アクションアイテム、オーナーを整理することで、全員がレビュープロセスをスムーズに行えます。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/rich_text_editor.html#tables)__ \n\n![テーブル作成の例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099376160.gif)\n\n\u003Cp>\u003C/p>\n\n## 10. ビデオとGIFの埋め込み\n\nイシューやエピックの説明やコメントにGIFやYouTube動画を埋め込んで、コミュニケーションに動的な要素を加えましょう。\n\n> __お気に入りの理由：__ 時にはGIFや動画の方が言葉よりも伝わりやすいですよね。\n> \n> **ユースケース：** UIのバグを説明する時は、YouTube動画を埋め込んで、提案する機能改善の手順を簡単に示しましょう。\n\n![ビデオとGIFの埋め込みの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/gif__1__aHR0cHM6_1750099376161.gif)\n\n\u003Cp>\u003C/p>\n\n## これらの機能をもっと活用しましょう！\n\nこれらの機能は、GitLabの包括的なツールキットのほんの一部にすぎません。ツールキットは効率を高め、より良いコラボレーションを促進するように設計されています。十分に活用されていないかもしれませんが、ワークフローに大きな影響を与える可能性があります。日々のルーティーンにぜひ取り入れてくださいね。\n\n*監修：大井 雄介 （GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n> GitLabを使用してDevSecOpsワークフローを強化しよう！[GitLab Ultimateを【無料】で試す](https://gitlab.com/-/trial_registrations/new)。\n",[676,904,678,677],"2024-05-29",{"slug":3594,"featured":6,"template":681},"top-10-gitlab-workflow-hacks-you-need-to-know","content:ja-jp:blog:top-10-gitlab-workflow-hacks-you-need-to-know.yml","Top 10 Gitlab Workflow Hacks You Need To Know","ja-jp/blog/top-10-gitlab-workflow-hacks-you-need-to-know.yml","ja-jp/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"_path":3600,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3601,"content":3606,"config":3612,"_id":3614,"_type":16,"title":3615,"_source":17,"_file":3616,"_stem":3617,"_extension":20},"/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat",{"title":3602,"description":3310,"ogTitle":3602,"ogDescription":3310,"noIndex":6,"ogImage":3603,"ogUrl":3604,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3604,"schema":3605},"AI搭載のGitLab Duoチャットを使用するためのベストプラクティス【10選】","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097639/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_77JeTV9gAmbXM0224acirV_1750097638765.png","https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI搭載のGitLab Duoチャットを使用するためのベストプラクティス【10選】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-04-02\",\n      }",{"title":3602,"description":3310,"authors":3607,"heroImage":3603,"date":3608,"body":3609,"category":787,"tags":3610,"updatedDate":3611},[2980],"2024-04-02","AIと会話を交わすのはチャレンジングかもしれません。どのような質問から始めるべきでしょうか？どのように質問を組み立てますか？どのくらいのコンテキストが必要でしょうか？会話により最高かつ最適な結果を得られるのでしょうか？\n\n\nこのチュートリアルでは、AI搭載のDevSecOpsワークフローにGitLab\nDuoチャットを統合し、最良な結果を得るためにプロンプトを洗練させる上で役立つヒントとベストプラクティス10選をご紹介します。\n\n\n[始める：GitLab\nDuoチャットを開いたままにしておく](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#始める：GitLab-Duoチャットを開いたままにしておく)\n\n\n[GitLab\nDuoチャットを使用するためのベストプラクティス10選](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#GitLab-Duoチャットを使用するためのベストプラクティス10選)\n\n\n1.\n[会話を交わす](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#1.-会話を交わす)\n\n2.\n[効率を上げるためにプロンプトを絞り込む](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#2.-効率を上げるためにプロンプトを絞り込む)\n\n3.\n[プロンプトのパターンに従う](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#3.-プロンプトのパターンに従う)\n\n4.\n[ローコンテキストコミュニケーションを使用する](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#4.-ローコンテキストコミュニケーションを使用する)\n\n5.\n[繰り返す](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#5.-繰り返す)\n\n6.\n[焦らない](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#6.-焦らない)\n\n7.\n[リセットして再起動](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#7.-リセットして再起動)\n\n8.\n[IDEのスラッシュコマンドで効率化](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#8.-IDEのスラッシュコマンドで効率化)\n\n9.\n[スラッシュコマンドのプロンプトを絞り込む](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#9.-スラッシュコマンドのプロンプトを絞り込む)\n\n10.\n[スラッシュコマンドでクリエイティブに](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#10.-スラッシュコマンドでクリエイティブに)\n\n\nボーナスコンテンツ：\n\n-\n[ショートカット](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#ショートカット)\n\n-\n[試してみよう](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#試してみよう)\n\n-\n[詳細](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#詳細)\n\n\n> AIで進化する最新のGitlab １７とGitLab Duoを、ライブ中継で観てみませんか？\u003Cbr>\n[__＞日本時間6月28日のイベントに今すぐ登録する＜__](https://about.gitlab.com/seventeen/)\n\n\n## 始める：GitLab Duoチャットを開いたままにしておく\n\n\n[GitLab\nDuoチャット](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)は、GitLab\nUI、Web IDE、およびVS CodeなどのサポートされているプログラミングIDEで利用できます。\n\n\nVS Codeでは、デフォルトの左ペインでGitLab\nDuoチャットを開くことができます。アイコンを右側のペインにドラッグアンドドロップすることもできます。これにより、コードを書いたり、ファイルツリーを移動したり、Gitアクションを実行したりしている間も、チャットを開いたままにしておくことが可能です。チャットの場所をリセットするには、コマンドパレットを開きます。macOSの場合は\n`[Command] + [Shift] + [P]`、Windows/Linuxの場合は `[Ctrl] + [Shift] + [P]`\nキーボードショートカットを押し、`View: Reset View Locations` と入力します。以下の短いビデオで、その方法を説明します。\n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/foZpUvWPRJQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n\nWeb IDEとVS Codeは同じフレームワークを共有しています。Web IDEでは同じメソッドを使用でき、より効率的なワークフローを実現できます。\n\n\n![Web\nIDEのチャット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097645344.png)\n\n\n## GitLab Duoチャットを使用するためのベストプラクティス10選\n\n\n### 1. 会話を交わす\n\n\nチャットは会話形式で行うべきであり、検索フォームではありません。\n\n\n会話の始め方としては、ブラウザでの検索と同様の検索用語から始めて、応答と出力を試してみることをおすすめします。この例では、C#プロジェクトとベストプラクティスから始めましょう。\n\n\n> c# start project best practices \n\n> \n\n> （c#プロジェクト スタート時のベストプラクティス）\n\n\n![C#スタートプロジェクトのベストプラクティスのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097646/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097645345.png)\n\n\nこの回答は、C#の幅広いスコープを理解するのには役立ちますが、すぐに実践できるベストプラクティスを提示しているわけではありません。次は、同じコンテキストで、より焦点を絞った質問をしてみましょう。\n\n\n> Please show the project structure for the C# project.\n\n> \n\n> （C#プロジェクトのプロジェクト構造を示してください）\n\n\n![C#プロジェクトの構造のチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097645346.png)\n\n\nこの回答は参考になります。次に、同じ質問の構成でGitに関する質問をしてみましょう。何かを表示してほしいと指示します。\n\n\n> Show an example for a .gitignore for C#\n\n> \n\n> （C#の.gitignoreの例を示してください）\n\n\n![C#の.gitignoreのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image25_aHR0cHM6_1750097645347.png)\n\n\nCI/CDに進み、C#プロジェクトを構築する方法を尋ねます。\n\n\n> Show a GitLab CI/CD configuration for building the C# project\n\n> \n\n> （C#プロジェクトを構築するためのGitLab CI/CD設定を表示してください）\n\n\n![C#プロジェクトを構築するためのGitLab\nCI/CD設定のチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image16_aHR0cHM6_1750097645349.png)\n\n\nこの例では、チャットは、具体的な変更をリクエストするよう促しています。.NET SDK 6.0の代わりに、.NET SDK\n8.0を使用するようリクエストしましょう。\n\n\n> In the above example, please use the .NET SDK 8.0 image\u003Cbr>\n\n> （上記の例では、次を使用してください。.NET SDK 8.0イメージ）\n\n\n![.NET SDK\n8.0を使用するためのチャットプロンプトと回答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image32_aHR0cHM6_1750097645350.png)\n\n\nCI/CD設定で.NETコマンドラインインターフェース（CLI）が使用されます。もしかしたら、プロジェクトやテストの構造を作成するコマンドの効率化にも使えるかもしれません。\n\n\n> Explain how to create projects and test structure on the CL\n\n> \n\n> （CLIでプロジェクトとテスト構造を作成する方法を説明してください）\n\n\n![CLIでプロジェクトとテスト構造を作成する方法を説明するよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097645351.png)\n\n\nもちろん、これらのコマンドをターミナルで実行することもできますが、引き続きVS\nCodeを使用したい場合はどうすればよいでしょうか。チャットに尋ねましょう。\n\n\n> Explain how to open a new terminal in VS Code\n\n> \n\n> （VS Codeで新しいターミナルを開く方法を説明してください）\n\n\n![VS\nCodeで新しいターミナルを開く方法を説明するよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097645351.png)\n\n\n### 2. 効率を上げるためにプロンプトを絞り込む\n\n\nGitLab Duoチャットを人間と同じように考え、あなたの考えや質問に関してできるだけ多くの文脈を伝えられるよう、文章でやり取りしてください。\n\n\nブラウザで頻繁に検索する方は、クエリに対するこのアプローチをご存知かもしれません。質問を組み立て、さらに用語を追加して範囲を絞り込み、たくさんのタブが表示された上で検索を再開します。 \n\n\nブラウザ検索では、おそらく4つから5つの検索ウィンドウが表示されるでしょう。\n\n\n```マークダウン\n\nc# start project best practices\n\nc# .gitignore\n\nc# gitlab cicd \n\nc# gitlab security scanning \n\nc# solutions and projects, application and tests\n\n``` \n\n\nチャットでの会話でも、同じ戦略を採用できます。より多くの文脈を加え、会話的なアプローチにする必要があります。GitLab\nDuoチャットでは、1回の会話リクエストで複数の質問ができます。例：上記の検索と同様、新しいC#プロジェクトから始めて、ベストプラクティスを適用し、`.gitignore`\nファイルを追加し、CI/CDとセキュリティスキャンを設定する必要があります。チャットでは、質問を1つのリクエストにまとめることができます。\n\n\n> How can I get started creating an empty C# console application in VS Code?\nPlease show a .gitignore and .gitlab-ci.yml configuration with steps for C#,\nand add security scanning for GitLab. Explain how solutions and projects in\nC# work, and how to add a test project on the CLI.\n\n> \n\n> （VS\nCodeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示し、GitLabのセキュリティスキャンを追加してください。C#のソリューションとプロジェクトがどのように動作するのかに加え、CLIでテストプロジェクトを追加する方法を説明してください）\n\n\n![より多くの文脈を加えたチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image37_aHR0cHM6_1750097645352.png)\n\n\nこの応答で、チャットは会話のフォローアップの質問で具体的な設定例を尋ねるよう提案しています。応用：フォローアップの質問を作成しましょう。同じチャットセッションでは、コンテキストとしてC#を省略することができます。\n\n\n> Please show an example for a .gitignore. Please show a CI/CD\nconfiguration. Include the SAST template.\n\n> \n\n>   （gitignoreの例を示してください。CI/CDの設定を示してください。SASTテンプレートを含めてください）\n\n\n### 3. プロンプトのパターンに従う \n\n\n「プロンプト命令文、助けを求めて、追加のリクエストをする」というパターンに従ってください。最初の質問ですべての答えが得られるとは限りません。閉塞感を感じないよう、最初は「プロンプト命令文、助けを求める」を繰り返すことから始めましょう。\n\n\n> I need to fulfill compliance requirements. How can I get started with\nCodeowners and approval rules?\n\n> \n\n> （コンプライアンス要件を満たす必要があります。CODEOWNERSと承認ルールの使い始め方を教えてください）\n\n\n![CODEOWNERSと承認ルールを使い始めるためのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image19_aHR0cHM6_1750097645352.png)\n\n\n回答は役に立つものの、明らかに一般的な内容です。そこで、チーム用の設定について具体的な内容を教えてもらうこともできます。\n\n\n> Please show an example for Codeowners with different teams: backend,\nfrontend, release managers.\n\n> \n\n> (バックエンド、フロントエンド、リリースマネージャーといった異なるチームのCODEOWNERSの例を示してください)\n\n\n![バックエンド、フロントエンド、リリースマネージャーといった異なるチームのCODEOWNERSの例を示すよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image31_aHR0cHM6_1750097645353.png)\n\n\nもう1つの方法は、自分が置かれている状況を説明し、意見を求めることです。STARモデル（状況、タスク、アクション、結果）に従うと、うまく質問ができるでしょう。\n\n\n> I have a\n[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)\ncluster integrated in GitLab. Please generate a Yaml configuration for a\n[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)\nservice deployment. Explain how GitOps works as a second step. How to verify\nthe results?\n\n> \n\n>\n（GitLabに統合されたKubernetesクラスターがあります。[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)サービスをデプロイするためのYAML設定を生成してください。2つ目のステップとしてGitOpsがどのように動作するかを説明してください。結果を検証する方法は？）\n\n\n![複数の質問を含むチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image27_aHR0cHM6_1750097645354.png)\n\n\n### 4. ローコンテキストコミュニケーションを使用する\n\n\n回答するためになるべく多くのコンテキストを提供します。以前の履歴または開かれたソースコードからは、そういった有用なコンテキストが得られない場合もあります。より効率的に質問するために、GitLabのオールリモート環境でのコミュニケーションで使用される[ローコンテキストコミュニケーション](https://handbook.gitlab.com/handbook/company/culture/all-remote/effective-communication/#understanding-low-context-communication)のパターンを適用します。\n\n\n次の質問の場合、C++プロジェクトにおいて十分なコンテキストを提供できていません。\n\n\n> Should I use virtual override instead of just override?\n\n> \n\n> （単にオーバーライドをつかうのではなく、仮想オーバーライドをつかったほうがいいですか？）\n\n\n![ユーザーが上書きの代わりに仮想の上書きを使用する必要があるかどうかを尋ねるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image34_aHR0cHM6_1750097645354.png)\n\n\n代わりに、より多くのコンテキストを追加してみてください。\n\n\n> When implementing a pure virtual function in an inherited class, should I\nuse virtual function override, or just function override? Context is C++.\n\n> \n\n>\n（継承クラスに純粋な仮想関数を実装する場合、仮想関数の上書きを使用する必要がありますか、それとも単に関数の上書きを使用する必要がありますか？コンテキストはC++です）\n\n\n![詳細情報を含むチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image36_aHR0cHM6_1750097645355.png)\n\n\nこの例は、[GitLab\nDuoコーヒーチャット：抽象的なデータベース処理のためにC++関数をOOPクラスにリファクタリングする](https://youtu.be/Z9EJh0J9358?t=2190)でもご紹介しています。\n\n\n### 5. 繰り返す\n\n\nAIは予測できないものです。想定した結果が返されない場合や、コンテキストが不足しているためソースコードの例や設定スニペットが生成されない場合があります。質問を繰り返し、要件を絞り込んでいくことをおすすめします。\n\n\n以下の例では、C#アプリケーションを作成します。最初の試行では、アプリケーションタイプを指定しませんでした。C#を使用してコンソール/ターミナルだけでなく、UIアプリケーションも作成できます。また、回答結果には、空のサンプルソースコードも表示されませんでした。2つ目に再度入力するプロンプトでは、「コンソール」と「空」の2つの単語を追加します。\n\n\n> How can I get started creating an C# application in VSCode?\n\n> \n\n> （VS CodeでC#アプリケーションを作成するにはどうすればよいですか？）\n\n> \n\n> How can I get started creating an empty C# console application in VSCode?\n\n> \n\n> （VS Codeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？）\n\n\nプロンプトの結果は異なります。最初の質問への回答内容は、VS\nCodeウィンドウの手順に従って開始するのに役立ちますが、ソースコードの場所と変更方法は示されません。改良したプロンプトを改めて入力することで、回答内容が修正され、デフォルトのテンプレートを\n「hello world」コードで上書きする方法が示されます。\n\n\n![修正したプロンプトを改めて入力したチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image28_aHR0cHM6_1750097645355.png)\n\n\n質問を繰り返したり洗練させることで、アプリケーションコードやテストの例を表示するよう、チャットにリクエストもできます。\n\n\n> How can I get started creating an empty C# console application in VSCode?\nPlease show an example for application and tests.\n\n> \n\n> （VS Codeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？アプリケーションとテストの例を示してください）\n\n\n![アプリケーションとテストの例を求めるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097645356.png)\n\n\n#### 一般的な質問を繰り返します \n\n\n一般的な技術的質問を尋ねた場合、GitLab\nDuoチャットでは対応できないことがあります。次のシナリオでは、Javaのビルドツールとフレームワークに関する提案を得ようとしたものの、うまくいきませんでした。この質問への答えは数多く考えられます。ビルドツールとしてはMaven、Gradleなどがあり、テクノロジースタックや要件によっては[100以上のJavaフレームワーク](https://en.wikipedia.org/wiki/List_of_Java_frameworks)があります。\n\n\n![Javaのビルドツールとフレームワークに関するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097645356.png)\n\n\nでは、[Java Spring\nBoot](https://spring.io/projects/spring-boot)を使った顧客環境に焦点を当てたいと想定してみます。\n\n\n> I want to create a Java Spring Boot application. Please explain the\nproject structure and show a hello world example.\n\n> \n\n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello Worldの例を示してください）\n\n\n![Hello\nWorldの例を含め、追加情報を求めるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image26_aHR0cHM6_1750097645357.png)\n\n\nすでに素晴らしい結果が返って来ています。応用として、プロンプトを繰り返し、アプリケーションのデプロイ方法を尋ね、それぞれのステップでさらに改良を加えてください。別の方法として、フォローアップの会話にする方法もあります。\n\n\n> I want to create a Java Spring Boot application. Please explain the\nproject structure and show a hello world example. Show how to build and\ndeploy the application in CI/CD.\n\n> \n\n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello\nWorldの例を示してください。CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください）\n\n> \n\n> I want to create a Java Spring Boot application. Please explain the\nproject structure and show a hello world example. Show how to build and\ndeploy the application in CI/CD, using container images.\n\n> \n\n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello\nWorldの例を示してください。コンテナイメージを使用して、CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください）\n\n> \n\n> I want to create a Java Spring Boot application. Please explain the\nproject structure and show a hello world example. Show how to build and\ndeploy the application in CI/CD, using container images. Use Kubernetes and\nGitOps in GitLab.\n\n> \n\n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello\nWorldの例を示してください。コンテナイメージを使用して、CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください。示します。GitLabで[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)とGitOpsを使用してください）\n\n### 6. 焦らない\n\n\n1つの単語または短い文章すると、[このビデオの例に示すように]（https://youtu.be/JketELxLNEw?t=1220）、望ましい結果が得られない場合があります。GitLab\nDuo Chatは、利用可能なデータから推測を行うことができる場合がありますが、より多くのコンテキストの提供を主張する場合もあります。\n\n\n例：`labels` はGitLabのドキュメントの内容に一致します。\n\n\n![ラベルと応答に関するチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097645357.png)\n\n\n指示内容をブラッシュアップしてイシューボードでの使用法についてさらなる改良を行います。\n\n\n> Explain labels in GitLab. Provide an example for efficient usage with\nissue boards.\n\n> \n\n> （GitLabのラベルを説明してください。イシューボードで効率的に使用できる例をください）\n\n\n![例と回答を求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image21_aHR0cHM6_1750097645358.png)\n\n\nまたは、問題を記述し、その後に質問をして、追加の例を尋ねます。\n\n\n> I don't know how to use labels in GitLab. Please provide examples, and how\nto use them for filters in different views. Explain these views with\nexamples.\n\n> \n\n>\n（GitLabでラベルを使用する方法が分かりません。さまざまなビューのフィルターにラベルを使用する方法の例をください。これらのビューを例で説明してください）\n\n\n![問題文と回答を含むチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097645358.png)\n\n\nまた、「はい/いいえ」の質問を避け、代わりに特定のコンテキストを追加します。\n\n\n> Can you help me fix performance regressions?\n\n> \n\n> （パフォーマンスのレグレッションを修正するのを手伝ってもらえますか？）\n\n\n![パフォーマンスのリグレッションと応答を修正するための助けを求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image18_aHR0cHM6_1750097645359.png)\n\n\n代わりに、プログラミング言語、フレームワーク、テクノロジースタック、および環境を含む、パフォーマンスレグレッションのコンテキストを提供します。次の例では、数年前の環境を使用していますが、現在でも十分正確です。\n\n\n> My PHP application encounters performance regressions using PHP 5.6 and\nMySQL 5.5. Please explain potential root causes, and how to address them.\nThe app is deployed on Linux VMs.\n\n> \n\n> （私のPHPアプリケーションは、PHP 5.6とMySQL\n5.5を使用してパフォーマンスのリグレッションに遭遇しています。潜在的な根本原因とそれらに対処する方法を説明してください。このアプリはLinux\nVMにデプロイされています）\n\n\n![詳細と回答を含むチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image24_aHR0cHM6_1750097645360.png)\n\n\n### 7. リセットして再起動\n\n\n時々、チャット履歴を見る限り、意図しない学習経路を辿ってしまったが故に、フォローアップの質問のコンテキストが間違っている場合があります。または、GitLab\nDuoチャットが回答を提供できない特定の質問をした可能性があります。生成系AIは予測不可能であり、特定の例を提供することができなかったかもしれませんが、将来の応答でそれらを提供していけるようになるでしょう（チャットベータで観察）。基礎となる大規模言語モデル（LLM）は、時には無限ループに陥ってしまう場合もあります。\n\n\n> How can I get started creating an empty C# console application in VSCode?\nPlease show a .gitignore and .gitlab-ci.yml configuration with steps for C#,\nand add security scanning for GitLab. Explain how solutions and projects in\nC# work, and how to add a test project on the CLI.\n\n> \n\n>\n（VSCodeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示し、GitLabのセキュリティスキャンを追加してください。C#のソリューションとプロジェクトがどのように機能するのか、CLIでテストプロジェクトを追加する方法を説明してください）\n\n\n上記の内容で質問をした後、よりカスタマイズされた応答を得るために、質問の範囲を縮小したいと思いました。チャットはコンテキストでチャット履歴を把握しており、以前の回答を参照しているため、期待どおりに機能しませんでした。\n\n\n> How can I get started creating an empty C# console application in VSCode?\nPlease show a .gitignore and .gitlab-ci.yml configuration with steps for C#.\n\n> \n\n>\n（VSCodeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示してください）\n\n\n![設定例と応答を求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image23_aHR0cHM6_1750097645360.png)\n\n\nチャットを新しいコンテキストに強制的に追加するには、`/reset` をスラッシュ（/）\nコマンドとして使用してセッションをリセットし、質問を繰り返してより良い結果を得ていくことになります。`/clean` または `/clear`\nを使用して、会話内のすべてのメッセージを削除することもできます。\n\n\n### 8. IDEのスラッシュコマンドで効率化\n\n\n#### コードを説明する\n\n\n- 質問：生成されたコードですか？既存のコードですか？従来のコードですか？\n\n- 回答：[IDEの`/explain`スラッシュ（/）\nコマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#explain-code-in-the-ide)を使用します。\n\n- 回答2：より焦点を当てた応答でプロンプトを絞り込む。例： `/explain focus on potential shortcomings or\nbugs. （/explain 潜在的な欠点やバグに焦点を当てる）`\n\n\n![/explainスラッシュ（/）\nコマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/gitlab_duo_chat_slash_commands_explain_01_aHR0cHM6_1750097645361.png)\n\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097645361.png)\n\n\n#### コードのリファクタリング\n\n\n- 質問：読みづらいコードですか？長いスパゲッティコードですか？テストカバレッジはゼロですか？\n\n- 回答：[IDEの`/refactor`スラッシュ（/）\nコマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#refactor-code-in-the-ide)を使用します。\n\n- 回答2 ：よりターゲットを絞ったアクションのプロンプトを絞り込む。例：オブジェクト指向パターン：`/refactor into\nobject-oriented classes with methods and attributes`。\n\n\n![/refactor\nslashコマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image35_aHR0cHM6_1750097645362.png)\n\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image30_aHR0cHM6_1750097645362.png)\n\n\n#### テストを生成\n\n\n- 質問：テスト可能なコードですが、テストの作成に時間がかかりすぎますか？\n\n- 回答：[IDEの`/tests`スラッシュ(/)\nコマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#write-tests-in-the-ide)を使用します。\n\n-\n回答2：特定のテストフレームワーク、またはテストターゲットのプロンプトを絞り込む。プロンプトにリファクタリングに焦点を当てるように指示し、次にテストを生成することもできます。`/tests`はコードを関数にリファクタリングし、テストを生成することに焦点を当てます。\n\n\n![/testsスラッシュ(/)\nコマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image29_aHR0cHM6_1750097645363.png)\n\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097645363.png)\n\n\n完全な開発ワークフローのより実用的な例は、[GitLab\nDuoの例](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html)のドキュメンテーションで入手できます。\n\n\n### 9. スラッシュコマンドのプロンプトを絞り込む\n\n\nこのブログ記事には、洗練されたプロンプトのヒントが数多くあったことでしょう。これらは、AIを活用したワークフロー効率を向上させるための要素の1つです。スラッシュ(/)\nコマンドを賢く使うことで、GitLab Duoチャットでより良い結果が得られます。\n\n\nあるお客様は最近、次のように尋ねました。「`/explain` を使用したコードの説明は、コード内にコメントを作成できますか？」\n答えは「いいえ」です。ただし、チャットプロンプトを使用してフォローアップの質問をしたり、コード内に記述できるコメント形式でコードの要約を求めることができます。その場合は、言語の指定が必要でしょう。\n\n\n[curlライブラリを使用したC++\nHTTPクライアントコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5cc9bdd65ee8ee16c548bea0402c18f8209d4d06/chat/slash-commands/c++/cli.cpp)の次の例には、より多くのドキュメント（指示内容）が必要です。コード内のコメントを追加して、より洗練した指示内容を/explainコマンドに渡すことで、よりよい結果が得られ、その結果をエディタ内に貼り付けていく、という方法もよいでしょう。\n\n\n> /explain add documentation, rewrite the code snippet\n\n> （/explain ドキュメントを追加し、コードスニペットを書き換えてください）\n\n\n![ドキュメントを追加し、コードスニペットと応答を書き換えるためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097645363.png)\n\n\nまたは、チャットにソースコードを `/refactor`\nするように依頼し、洗練されたプロンプトを使用して不足しているコードコメントを生成することもできます。\n\n\n> /refactor add code comments and documentation\n\n>\n\n> （/refactor コードのコメントとドキュメントを追加してください）\n\n\n![ソースコードをリファクタリングし、コードコメントを生成するためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image15_aHR0cHM6_1750097645364.png)\n\n\n### 10. スラッシュコマンドでクリエイティブに\n\n\nチャットプロンプトがソースコードまたはプログラミング言語に関する質問への回答が得られない場合は、スラッシュ(/) コマンド\n`/explain`、`/explain`、`/tests` を試してみて、それらがコンテキスト作りに役に立つかどうかみてみましょう。\n\n\n以下の例では、C++のコード内でSQLクエリ文字列が1行で作成されます。読みやすさを高め、将来的にはより多くのデータベース列を追加できるようにするには、書式を複数行の文字列に変更すると便利です。\n\n\n> std::string sql = \"CREATE TABLE IF NOT EXISTS users （id INTEGER PRIMARY\nKEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL）\";\n\n\nたとえば、次の質問をその後に続けてGitLab Duo Chatに尋ねられます。\n\n\n> How to create a string in C++ using multiple lines?\u003Cbr>\n\n>（複数行を使用してC++で文字列を作成する方法）\n\n\nチャット自体は、説明文とオプションでソースコードの例で回答してくれるでしょう。ただ、この場合は、単にその文字列を\"¥n\"を間に入れて複数行にすればいい、という解釈をするでしょう。でも、私達が求めているのは、そうではなく、ソースコード上で見やすくするために「複数行」にしてほしい、ということですよね。\n\n\nVSCodeとWeb IDEには、追加のコンテキストの代替案があります。問題のソースコードを選択し、右クリックして、[GitLab Duoチャット]>\n[リファクタリング]に移動します。これにより、チャットプロンプトが開き、`/refactor`コードタスクがすぐに開始されます。\n\n\nただし、コードタスクは期待される結果をもたらさない可能性があります。1行のSQL文字列をリファクタリングすることは、読みやすさのために複数行を使用すること、定数を作成することなど、多くを意味するからです。\n\n\nコードタスクには、プロンプトを絞り込むオプションがあります。`/refactor` コマンドの後にテキストを追加し、GitLab\nDuoチャットに特定のコードタイプ、アルゴリズム、またはデザインパターンを使用するように指示できます。\n\n\nもう一度やり直してみましょう。ソースコードを選択し、フォーカスをチャットに変更し、次のプロンプトを入力して、`[Enter]`を押します。\n\n\n> /refactor into a multi-line written string. Show different approaches for\nall C++ standards.\n\n>\n\n>（/refactor 複数行の書き込み文字列に変換します。すべてのC++標準に異なるアプローチを示します）\n\n\n![複数行の文字列と応答にリファクタリングするためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image17_aHR0cHM6_1750097645364.png)\n\n\n**ヒント：** GitLab Duoのコード提案を使用して、リファクタリング後にソースコードをさらに洗練することも、あるいは、かわりに\n`/refactor` プロンプトの絞り込みを使用することもできます。\n\n\n> /refactor into a multi-line written string, show different approaches\n\n>\n\n> （/refactor 複数行の文字列に変換し、さまざまなC++標準のアプローチを表示してください）\n\n>\n\n> /refactor into multi-line string, not using raw string literals\n\n>\n\n> （/refactor 複数行の文字列に変換し、生の文字列リテラルを使用しないでください）\n\n>\n\n>/refactor into a multi-line written string. Make the table name\nparametrizable\n\n>\n\n>（/refactor 複数行の書き込み文字列に変換してください。テーブル名はパラメータ化してください）\n\n\n`stringstream` タイプの代替アプローチは、[GitLab\nDuoコーヒーチャット：抽象的なデータベース処理のためにC++関数をOOPクラスにリファクタリングする](https://www.youtube.com/watch?v=Z9EJh0J9358)、[MR差分](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-coffee-chat/gitlab-duo-coffee-chat-2024-01-23/-/commit/7ea233138aed46d77e6ce0d930dd8e10560134eb#4ce01e4c84d4b62df8eed159c2db3768ad4ef8bf_33_35)に記載されています。\n\n\n#### 脆弱性の説明\n\n\n常に機能するとは限りませんが、セキュリティの脆弱性の説明については、`/explain` スラッシュ(/)\nコマンドも尋ねることができます。この例では、[Cコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c)には、strcpy()バッファオーバーフロー、ワールド書き込み可能なファイルアクセス許可、競合条件攻撃などの複数の脆弱性が含まれています。\n\n\n>/explain why this code has multiple vulnerabilitie\u003Cbr>\n\n>（/explain このコードに複数の脆弱性がある理由を説明してください）\n\n\n![/コードの複数の脆弱性についてのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image20_aHR0cHM6_1750097645365.png)\n\n\n#### CコードをRustにリファクタリングする\n\n\nRustはメモリの安全性を提供します。`refactor into Rust`\nを使用して、脆弱な[Cコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c)をRustにリファクタリングするようにDuo\nChatに依頼できます。より良い結果を得るために、より洗練されたプロンプトで練習してください。\n\n\n> /refactor into Rust and use high level libraries\n\n> \n\n> （/refactor Rustに変換し、高レベルのライブラリを使用してください）\n\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097645366.png)\n\n\n### ショートカット\n\n\nこれらのショートカットを読者の環境で試し、GitLab Duoチャットを使用して応用例を試してみてください。\n\n\n1. CVEからの脆弱性に基づいてコードを調べ、`/explain why is this code vulnerable`\nを使用して、それが何をし、どのように修正するかを尋ねます。\n\n**ヒント：** GitLab Duoチャットのコード説明を利用するには、GitLabでオープンソースプロジェクトをインポートしてください。\n\n2. レガシーコードの移行計画を支援するために、コードを新しいプログラミング言語にリファクタリングしてみてください。\n\n3. `/refactor into GitLab CI/CD configuration` を使用して、Jenkins設定をGitLab\nCI/CDにリファクタリングすることもできます。\n\n\n### 試してみよう\n\n\nクリッピーのように振る舞うよう、チャットを説得してみてください。\n\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image22_aHR0cHM6_1750097645366.png)\n\n\nGitLabのミッション、「誰でも貢献できます」について尋ねてください。\n\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image33_aHR0cHM6_1750097645367.png)\n\n\n### 詳細\n\n\nいろいろなところに情報が記載されています。より実用的な例で[GitLab\nDuoチャットドキュメンテーション](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)を更新し、チャットを含むAI搭載のDevSecOpsワークフローを深く掘り下げる新しい[GitLab\nDuoの例](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html)セクションを追加しました。\n\n\nGitLab Duoの学習は、遊び心のあるチャレンジと実際の本番環境のコードを通じて最も効果的に機能します。新しい学習シリーズ、GitLab\nDuoコーヒーチャットは、2024年も続きます。本人確認ができるまでは、[このYouTubeプレイリスト](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp5uj_JgQiSvHw1jQu0mSVZ)で録画を見ることができます。GitLabのお客様で、GitLab\nDuoコーヒーチャットに参加して一緒に学ぶことに興味がある場合は、[この計画のエピック](https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/476)でお知らせください。\n\n\n*監修：小松原 つかさ\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n\n> GitLab\nDuoチャットを試してみませんか？[今すぐ無料トライアルを開始](https://about.gitlab.com/solutions/gitlab-duo-pro/self-managed-and-gitlab-dedicated-trial/)。\n",[721,676,904,678],"2024-05-23",{"slug":3613,"featured":92,"template":681},"10-best-practices-for-using-ai-powered-gitlab-duo-chat","content:ja-jp:blog:10-best-practices-for-using-ai-powered-gitlab-duo-chat.yml","10 Best Practices For Using Ai Powered Gitlab Duo Chat","ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat.yml","ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat",{"_path":3619,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3620,"content":3626,"config":3631,"_id":3633,"_type":16,"title":3634,"_source":17,"_file":3635,"_stem":3636,"_extension":20},"/ja-jp/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"title":3621,"description":3622,"ogTitle":3621,"ogDescription":3622,"noIndex":6,"ogImage":3623,"ogUrl":3624,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3624,"schema":3625},"GitLabにカスタムセキュリティスキャナーをインテグレーションする方法","ワークフローにカスタムセキュリティスキャナーを追加して、DevSecOpsプラットフォームを拡張する方法を学びましょう（わかりやすいチュートリアルが含まれています）。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097082/Blog/Hero%20Images/Blog/Hero%20Images/securitycheck_securitycheck.png_1750097081856.png","https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabにカスタムセキュリティスキャナーをインテグレーションする方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-27\",\n      }",{"title":3621,"description":3622,"authors":3627,"heroImage":3623,"date":3628,"body":3629,"category":722,"tags":3630},[1507],"2024-02-27","最も包括的なDevSecOpsプラットフォームであるGitLabには、アプリケーションにおけるプラン、管理、ビルド、デプロイ、セキュア、ガバナンス、およびモニタリングに必要なすべての機能が備わっています。しかし、サードパーティのツールやカスタムツールを使用してGitLabを拡張したいときもあります。たとえば、別のソリューションからDevSecOpsプラットフォームに移行したり、サードパーティのツールを評価したり、独自の、またはカスタムビルドのソリューションをGitLabにインテグレーションしたりすることが求められる場合があります。\n\nこの記事では、次の内容について説明します。\n- [GitLab DevSecOpsプラットフォームの拡張性](#gitlab-devsecops-platform-extensibility)\n- [GitLabセキュリティスキャナーのインテグレーション](#gitlab-security-scanner-integration)\n- [マージリクエストのセキュリティウィジェット](#merge-request-security-widget)\n- [パイプラインセキュリティセクション](#pipeline-security-section\n)\n- [脆弱性レポート](#vulnerability-report)\n- [脆弱性ページ](#vulnerability-pages)\n- [セキュリティダッシュボード](#security-dashboard)\n- [スキャン結果ポリシーのインテグレーション](#scan-result-policy-integration)\n- [チュートリアル：カスタムセキュリティスキャナーのインテグレーション](#tutorial-integrating-custom-security-scanners)\n- [カスタムセキュリティスキャナーの作成](#creating-a-custom-security-scanner)\n- [カスタムセキュリティスキャナーとGitLabのインテグレーション](#integrating-a-custom-security-scanner-with-gitlab)\n\n## GitLab DevSecOpsプラットフォームの拡張性\n\nGitLabはさまざまな方法で拡張でき、組織で必要となる拡張機能をサポートします。これらのインテグレーションの一般的な例としては、次のようなものがあります。\n\n- JenkinsやSlackなどの外部アプリケーションのインテグレーション\n- BugzillaやJiraなどの外部イシュートラッキングのインテグレーション\n- LDAPやSAMLなどの外部認証プロバイダーのインテグレーション\n- FortifyやCheckmarxなどの外部セキュリティスキャナーのインテグレーション\n- AWSやGCPのアクセスキーなどの流出したシークレットに対応する機能\n\n利用可能なすべてのインテグレーション機能は、[GitLabドキュメントとのインテグレーション](https://docs.gitlab.com/ee/integration/)で確認できます（注：ドキュメントにはすべてのインテグレーションが記載されているわけではありません）。\n\n## GitLabセキュリティスキャナーのインテグレーション\n\n[サードパーティのセキュリティスキャナー](https://docs.gitlab.com/ee/integration/#security-improvements)または[カスタムビルドのセキュリティスキャナー](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)をGitLabにインテグレーションして、マージリクエストウィジェット、パイプラインセキュリティセクション、脆弱性レポート、脆弱性ページ、セキュリティダッシュボード、およびスキャン結果ポリシーを作成できます。各インテグレーションについて確認しましょう。\n\n### マージリクエストのセキュリティウィジェット\n\nマージリクエストには、新たに検出された脆弱性の概要を表示するセキュリティウィジェットが含まれています。\n\n![セキュリティスキャナーのインテグレーション - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097088837.png)\n\n\u003Ccenter>\u003Ci>マージリクエストのセキュリティウィジェット\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n脆弱性をクリックすると、次の情報がポップアップ表示されます。\n- 状態\n- 説明\n- プロジェクト\n- ファイル\n- 識別子\n- 重大度\n- ツール\n- スキャナープロバイダー\n\n![セキュリティスキャナーのインテグレーション - 画像2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097088838.png)\n\n\u003Ccenter>\u003Ci>実行可能な脆弱性とその詳細\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nこれらの脆弱性は実行可能なため、無視するか、非公開のイシューとして作成できます。\n\nカスタムスキャナーの結果は、セキュリティウィジェットに入力するために使用できます。脆弱性データは、スキャナーが出力するJSONスキーマから入力されます。\n\n### パイプラインセキュリティセクション\n\nすべての有効なセキュリティアナライザーはパイプラインで実行され、結果をアーティファクトとして出力します。これらのアーティファクトは重複排除を含む処理が行われ、結果はパイプラインセキュリティタブに表示されます。ここから、生成されたJSONファイルをダウンロードすることもできます。\n\n![セキュリティスキャナーのインテグレーション - 画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097088840.png)\n\n\u003Ccenter>\u003Ci>パイプラインセキュリティタブ\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nカスタムスキャナーの結果は、パイプラインセキュリティタブに入力するために使用できます。列は、スキャナーが出力するJSONスキーマを使用して入力されます。\n\n### 脆弱性レポート\n\n脆弱性レポートには、デフォルトブランチのスキャンから得られた脆弱性に関する情報が記載されています。これには以下が含まれます。\n\n- 重大度レベルごとの脆弱性の総数\n- 一般的な脆弱性属性のフィルター\n- 表形式のレイアウトで表示される各脆弱性の詳細\n\n![セキュリティスキャナーのインテグレーション - 画像4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097088842.png)\n\n\u003Ccenter>\u003Ci>脆弱性レポート\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nデフォルトブランチのカスタムスキャナーの結果を使用して、脆弱性レポートを作成できます。\n\n### 脆弱性ページ\n\n脆弱性レポート内の脆弱性をクリックすると、その脆弱性に関するページに移動します。プロジェクト内の各脆弱性には、次のような詳細情報が記載されている脆弱性ページがあります。\n\n- 説明\n- 検出時期\n- 現在の状態\n- 検出場所\n- 実行可能なアクション\n- 紐つけられたイシュー\n- アクションログ\n- ソリューション\n- 識別子\n- トレーニング\n\n脆弱性ページで提供されるデータを使用して、検出された脆弱性をトリアージしたり、修正をサポートしたりできます。\n\n![セキュリティスキャナーのインテグレーション - 画像5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097088844.png)\n\n\u003Ccenter>\u003Ci>シークレット検出脆弱性の脆弱性ページ\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nカスタムスキャナーの結果は、脆弱性ページに入力するために使用できます。脆弱性データは、スキャナーが出力するJSONスキーマから入力されます。\n\n### セキュリティダッシュボード\n\nセキュリティダッシュボードは、アプリケーションのセキュリティ対策状況を評価するために使用されます。GitLabは、プロジェクトで実行されているセキュリティスキャナーによって検出された脆弱性に関するメトリクス、評価、チャートを提供します。セキュリティダッシュボードには、次のようなデータが表示されます。\n\n- グループ内のすべてのプロジェクトにおける、30日間、60日間、または90日間の脆弱性トレンド\n- 脆弱性の重大度に基づく各プロジェクトのレターグレードの評価\n- 過去365日以内に検出された脆弱性の総数とその重大度レベル\n\n![セキュリティスキャナーのインテグレーション - 画像6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097088846.png)\n\n\u003Ccenter>\u003Ci>グループレベルのセキュリティダッシュボード\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nグループレベルのセキュリティダッシュボードからプロジェクトをクリックすると、365日間の状況を表示する特定のセキュリティダッシュボードにアクセスできます。\n\n![セキュリティスキャナーのインテグレーション - 画像7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097088847.png)\n\n\u003Ccenter>\u003Ci>プロジェクトレベルのセキュリティダッシュボード\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n### スキャン結果ポリシーのインテグレーション\n\nスキャン結果ポリシーは、1つ以上のセキュリティスキャンジョブによる発見事項に基づいて承認を要求するために使用されます。これにより、脆弱なコードが本番環境にマージされるのを防ぐことができます。スキャン結果ポリシーは、CI（継続的インテグレーション）スキャンジョブが完全に実行された後、完了したパイプラインで公開されるジョブアーティファクトレポートに基づいて評価されます。\n\nたとえば、シークレット検出スキャナーが脆弱性を発見した場合、プロジェクトのメンテナーによる承認を必要とするスキャン結果ポリシーを作成できます。手順は次のとおりです。\n\n1. 左側のサイドバーで、**検索または移動先**を選択し、ポリシーを追加するプロジェクトを検索します。\n2. プロジェクトの左側のサイドバーで、**セキュア > ポリシー**に移動します。\n3. **新しいポリシー**を選択します。\n4. **スキャン結果ポリシー**セクションで、**ポリシーを選択**を選択します。\n5. 次のフィールドに入力します。\n- 名前：ポリシーの名前\n- 説明：ポリシーの説明\n- ポリシーの状態：有効かどうか\n- ルール：アクションを実行する（承認が必要）ために満たす必要がある条件\n\n![セキュリティスキャナーのインテグレーション - 画像8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097088849.png)\n\u003Ccenter>\u003Ci>スキャン結果ポリシーのルール\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- アクション：ルールの条件（定義された脆弱性/ライセンスの検出）が満たされた場合に実行されるアクションです\n\n![セキュリティスキャナーのインテグレーション - 画像9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097088850.png)\n\n\u003Ccenter>\u003Ci>スキャン結果ポリシーのアクション\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- プロジェクトの承認設定を上書き：選択した場合、次のオプションによりプロジェクト設定が上書きされますが、ポリシーで選択されたブランチにのみ影響します\n\n![セキュリティスキャナーのインテグレーション - 画像11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097088851.png)\n\n\u003Ccenter>\u003Ci>スキャン結果ポリシーの承認設定\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n6. [マージリクエスト経由で設定]ボタンを押します。\n\nスキャン結果ポリシーがマージされると、マージリクエストを作成し、ルールで定義された条件が満たされるたびに、定義されたアクションがトリガーされます。この場合、コードをマージするには、メンテナーからの承認が少なくとも1回必要になります。\n\n![セキュリティスキャナーのインテグレーション - 画像10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097088852.png)\n\n\u003Ccenter>\u003Ci>脆弱性が検出されたためにブロックされたマージリクエスト\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nカスタムスキャナーの結果は、スキャン結果ポリシーと完全に統合できます。カスタムスキャナーが脆弱性を検出した場合、コードをマージするには承認が必要になります。スキャン結果ポリシーで選択するスキャナーは、適切なJSONスキーマを利用している必要があります。\n\n## チュートリアル：カスタムセキュリティスキャナーのインテグレーション\n\nでは、カスタムセキュリティスキャナーのインテグレーションという重要なパートについて見てみましょう。このチュートリアルでは、カスタムセキュリティスキャナーの作成方法と、それをGitLabに統合する方法を学びます。次のプロジェクトを活用します。\n\n- [Fernパターンスキャナー](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner)：パスワード、秘密キー、社会保障番号などの特定のパターンを探してファイルをスキャンします。\n- [シークレットリスト](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/secret-list)：ユーザーのパスワード、クライアント、およびキーのリストが含まれています。このプロジェクトは、カスタムセキュリティスキャナーをGitLabに統合する方法を示すために使用されています。\n\nアプリケーションの作成方法と使用方法を詳しく説明していますので、次の動画をご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/timMbl5SP-w?si=R2DKtZ5MmBR1rQFL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### カスタムセキュリティスキャナーの作成\n\n次に、GitLabに統合できるカスタムスキャナーを作成しましょう。カスタムスキャナーをGitLabと完全に統合する前に、スキャナーは以下の要件を満たす必要があります。\n- ディレクトリをスキャンして定義されたパターンを探す\n- 適切なスキーマに従っったJSONを出力する\n- コンテナ化され、アクセス可能である\n- 別のプロジェクトで実行できるテンプレートを作成する\n\n提供されたテンプレートを使用して[Fernパターンスキャナー](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner)をプロジェクトで実行すると、次の手順を実行します。\n1. 検出するパターン（正規表現）を定義する一連のルールを読み込みます。\n- 組織のニーズの変化に合わせてルールを構成できるようにします。\n2. ファイルをスキャンして定義されたパターンを探します。\n3. シークレット検出スキーマに従ってJSONレポートを出力します。\n- このプロジェクトでは、Goテンプレートを使用してJSONを作成します。\n- スキャナーの検出対象に応じて、適切なスキーマを使用するようにしてください。\n\nJSONレポートがアーティファクトとしてGitLabに読み込まれると、上記で定義されているように、マージリクエストウィジェット、脆弱性レポート、脆弱性ページ、スキャン結果ポリシー、およびセキュリティダッシュボードが作成されます。\n\n### カスタムセキュリティスキャナーとGitLabのインテグレーション\n\nインテグレーションのすべてのニーズを満たすカスタムスキャナーを作成したら、それをGitLabで実行できます。\n\nカスタムスキャナーの実行は、テンプレートを追加するのと同じくらい簡単です。[シークレットリスト](https://gitlab.com/gitlab-da/tutorials/security-and-governance/custom-scanner-integration/secret-list)プロジェクトの`.gitlab-ci.yml`を調べることで、Fernパターンスキャナーテンプレートがどのように読み込まれるかを確認できます。\n\n1. スキャナーを実行するプロジェクトに[.gitlab-ci.ymlファイル](https://docs.gitlab.com/ee/ci/quick_start/#create-a-gitlab-ciyml-file)を作成します。\n2. [カスタムスキャナーテンプレート](https://docs.gitlab.com/ee/ci/yaml/includes.html)を含めます。\n- 環境変数を使用してテンプレートを設定することもできます。\n3. ファイルをmainブランチにコミットします。\n\nファイルがコミットされると、カスタムスキャナーがパイプラインで実行されることがわかります。パイプラインが完了すると、スキャナーは上記の[GitLabセキュリティスキャナーのインテグレーション](#gitlab-security-scanner-integration)セクションで定義されたすべての領域にデータを入力します。\n\n## 詳細を読む\n\nGitLabの詳細とDevSecOpsプラットフォームを拡張するその他の方法については、次のリソースをご覧ください。\n\n- [セキュリティスキャナーのGitLabインテグレーション](https://docs.gitlab.com/ee/development/integrations/secure.html)\n- [GitLabパートナーインテグレーション](https://docs.gitlab.com/ee/integration/)\n- [カスタムセキュリティスキャナーのプロジェクトグループ](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)\n- [シークレット漏洩への自動応答](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)\n",[676,722,2378,904],{"slug":3632,"featured":92,"template":681},"how-to-integrate-custom-security-scanners-into-gitlab","content:ja-jp:blog:how-to-integrate-custom-security-scanners-into-gitlab.yml","How To Integrate Custom Security Scanners Into Gitlab","ja-jp/blog/how-to-integrate-custom-security-scanners-into-gitlab.yml","ja-jp/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"_path":3638,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3639,"content":3645,"config":3651,"_id":3653,"_type":16,"title":3654,"_source":17,"_file":3655,"_stem":3656,"_extension":20},"/ja-jp/blog/jenkins-to-gitlab-migration-made-easy",{"title":3640,"description":3641,"ogTitle":3640,"ogDescription":3641,"noIndex":6,"ogImage":3642,"ogUrl":3643,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3643,"schema":3644},"JenkinsからGitLabへのスムーズな移行","JenkinsからGitLabへ移行するメリットと簡単に行える移行手順を分かりやすく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"JenkinsからGitLabへのスムーズな移行\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-01\",\n      }",{"title":3640,"description":3641,"authors":3646,"heroImage":3642,"date":3647,"body":3648,"category":740,"tags":3649,"updatedDate":3650},[1507],"2024-02-01","GitLabは、最も包括的なAI搭載のDevSecOpsプラットフォームです。GitLabには、ソフトウェアの計画、開発、セキュリティ確保、迅速なリリースに必要な機能がすべて揃っています。\n\n\nプラットフォームを活用することで、さまざまなツールの統合（DIY\nDevOps）に苦労することなく、ソフトウェア開発ライフサイクル（SDLC）を実現できます。一方、Jenkinsはプラットフォームではないため、SDLCを実現させるには他のツールと組み合わせる必要があります。このようなDIY\nDevOpsのアプローチではツールチェーンの複雑さが増し、以下のようなデメリットが生じます。\n\n\n- ツールの統合やオーケストレーションに特別なサポートが必要\n\n- 個々のツールの保守、アップグレード、セキュリティ対策の負担が大きい\n\n- 組織における変革の進捗を正確に把握しづらい\n\n- デベロッパーエクスペリエンスが悪化する\n\n- 管理コスト、時間、予算がかかる\n\n- 生産性が低下する\n\n- 頭の切り替えが必要となり、コラボレーションの効率が下がる\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>DIY DevOpsとDevSecOpsプラットフォームの比較\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\nこうした理由から、Jenkinsを使用する多くのチームがDevSecOpsプラットフォームへの移行を検討しています。より強力で、信頼性と安全性の高いソリューションを求めているなら、GitLabが最適です。GitLabは無料で使い始められ、組織のニーズに応じたさまざまなサブスクリプションプランが用意されています。GitLab\nのプランや機能の詳細については、[価格ページ](https://about.gitlab.com/ja-jp/pricing/)をご覧ください。\n\n\nこのブログ記事では、以下について学べます。\n\n- 移行計画の立て方\n\n- 他のソースコード管理（SCM）ツールからGitLabへリポジトリを移行する方法\n\n- JenkinsからGitLabへCI/CDパイプラインを移行する方法\n\n- 移行に関するその他の考慮事項\n\n\n### 移行計画を立てる\n\n\n他のツールからGitLab\nCI/CDへ移行を開始する前に、まず移行計画を立てる必要があります。移行計画は、期待値を明確にするための重要な技術的ステップです。CI/CDツールは、それぞれアプローチや構造、技術的な仕様が異なるため、単純にデータを1対1でマッピングできるわけではありません。適切な移行計画を立てることでもたらされるメリットを次に挙げます。\n\n\n-\n移行の目的を明確にして共有することで、なぜ移行が価値のある取り組みなのかをユーザーに理解してもらいやすくなります。作業が完了すればその価値は明らかになりますが、移行中の段階においても認識してもらうことが重要です。\n\n- 関係する経営陣の支援や合意が得られ、移行の重要性や目的が全員に伝わりやすくなります。\n\n- 移行後の環境の違いについて、ユーザーが理解を深める時間を確保できます。\n\n- 移行の順序を決めたり、一部の移行を後回しにしたりすることで、未移行や部分的な移行状態が長引くのを防ぎます。\n\n- GitLab CI/CDにより得られる改善点やメリットを文書化し、移行の一環として既存の実装を更新できます。\n\n\n適切な移行計画を策定することで、業務への影響を最小限に抑えながら、GitLabへ徐々に移行できます。具体的には、JenkinsとGitLabを併用しつつ、一部のプロジェクトをGitLabに移し、Jenkinsの利用を徐々に減らしていくといった計画が考えられます。\n\n\n### 変更管理プロセスを定める\n\n\n移行計画では、効果的な変更管理プロセスを定める必要があります。デベロッパー、IT運用担当者、クラウド管理者、セキュリティ担当者、品質エンジニアなどの関係者は、GitLabの使用経験がなく、なぜあなたや経営陣がこの移行を決定したのかを理解していないかもしれません。\n\n\nこの移行によって影響を受ける人々に、以下の点を理解してもらう必要があります。\n\n- __なぜ__：この変更が行われるのか\n\n- __何が__：移行後の状態として想定されているのか\n\n- __どのように__：現在の状況から移行後の状態にするのか\n\n- __どこで__：追加の情報やサポートを得られるのか\n\n\n移行の影響を受ける各部門のへの影響を理解し、その変化を管理するには、以下の手順が必要です。\n\n\n-\n__現在の状況を分析する__：まず、現在のプロセスを文書化し、基準となる指標を収集します。次に、主要なチームメンバーへのインタビューを通じて、CI/CDにおいてうまく機能している点と機能していない点を特定します。課題を特定したら、定量的、定性的の両面から記録します。移行のビジョンと変更の理由を関係者に理解してもらう必要があるため、課題は明確に定義すればするほど、社内の合意を得やすくなります。\n\n-\n__ビジョンを確立する__：現在の課題を、定量的な基準値と定性的なチームメンバーのフィードバックで明確にしたら、次に将来のビジョンを共有します。ビジネスの成功指標と結びつけて、なぜこの移行が重要なのかを説明します。また、望ましい状態の具体的な例をライブデモや録画を通じて示し、現在の状況と比較します。さらに、このメッセージを定着させるために、チャットグループ、全社ミーティング、メール通知、GitLab上のバナーメッセージなど、複数のチャネルやメディアを活用して発信します。\n\n- __従業員を教育する__：GitLabの専門家が実施する[GitLab\nCI/CDトレーニング](https://about.gitlab.com/services/education/gitlab-ci/)に投資し、[GitLab認定](https://levelup.gitlab.com/pages/certifications)を活用して、知識の習得度や定着度を測定します。\n\n-\n__ロードマップとリソースを共有する__：チームメンバーに対し、移行の予定タイムラインや、移行に役立つリソースを案内します。また、チャットグループ、Q&Aボード、GitLabインフルエンサーによるオフィスアワーなど、コミュニティのリソースも案内し、質問に対する回答やサポートを得られる環境を整えます。さらに、早期に移行したチームを対象とした報酬制度を導入して、移行体験を他のアプリケーショングループと共有してもらうのも効果的です。\n\n\n移行の開始時にこれらの要素が揃っていれば、成功へ向けたしっかりとした基盤を築けます。\n\n\n### 移行目標を設定する\n\n移行を実施する前に、目標とそれを達成する方法をしっかりと把握しておく必要があります。たとえば、以下のような質問に対する答えを用意しておくことが重要です。\n\n- 移行のタイムラインはどのようになっているのか？\n\n- 現在のJenkinsサーバーの構成はどうなっているか？\n\n- 移行対象のプロジェクトはいくつあるか？\n\n- パイプラインの複雑さはどの程度か？\n\n- 外部依存関係、複数のパイプライントリガー、並列ビルドなどが必要か？\n\n- コードのデプロイ方法とデプロイ先は？\n\n- デプロイするコードのリリースやレビューのプロセスはどのようになっているか？\n\n- Jenkinsに統合されているのか、それともJenkinsがトリガーする別のワークフローなのか？\n\n- パイプラインの成功に必要なビルドアーティファクトやバイナリは何か？\n\n- 現在Jenkinsのジョブで使用しているプラグインは何か？\n\n- Jenkinsエージェントにインストールされているソフトウェアは何か？\n\n- 現在使用しているSCMソリューションは何か？\n\n- Jenkinsのジョブで共有ライブラリを使用しているか？\n\n- Jenkinsで使用している認証方法は何か（Basic認証、LDAP/AD、SSOなど）？\n\n- パイプラインからアクセスする必要がある他のプロジェクトはあるか？\n\n- Jenkinsが外部サービスと連携する際に使用するアクセス用認証情報はあるか？\n\n\nこれらの質問に答えることで、移行の進め方、所要時間、どこから始めるべきかが明確になります。移行計画を立て、期待値や想定される課題をしっかり把握できたら、いよいよ移行プロセスの開始です。\n\n\n### 移行の前提要件\n\n移行計画を作成し、移行に関するすべての期待事項を整理できたら、GitLabのセットアップを開始できます。移行の前に推奨される前提要件をいくつかご紹介します。\n\n- GitLabに慣れる。[GitLab\nCI/CDの主な機能](https://docs.gitlab.com/ee/ci/index.html)を読んで理解を深める。\n\n-\nチュートリアルを活用し、最初の[GitLabパイプライン](https://docs.gitlab.com/ee/ci/quick_start/index.html)と、静的サイトをビルド、テスト、デプロイする[より複雑なパイプライン](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)を作成する。\n\n-\n[.gitlab-ci.ymlのキーワード参照](https://docs.gitlab.com/ee/ci/yaml/index.html)を確認する。\n\n- GitLabをセットアップし、適切に設定する。\n\n- GitLabインスタンスをテストする。\n\n\nGitLabの理解を深め、インスタンスの設定が完了したら、移行計画に沿ってJenkinsからGitLabへのプロジェクト移行を進めることができます。その際、GitLabインスタンスがGitLabのベストプラクティスや[リファレンスアーキテクチャ](https://docs.gitlab.com/ee/administration/reference_architectures/)に従って適切に設定されていることを確認してください。\n\n\n### リポジトリをGitLabに移行する\n\nJenkinsの主な欠点の1つは、SCMソリューションがないことです。Jenkinsを使用している場合、別のSCMソリューションにコードを保存し、そこにJenkinsからアクセスする必要があります。一方、GitLabにはSCMが組み込まれているため、Jenkinsからの移行に伴い、従来使用していたSCMソリューションからも移行でき、さらなるコスト削減につながります。\n\n\nGitLabには、リポジトリやそのメタデータを簡単にGitLabへと移行できるツールが用意されています。プロジェクトをGitLabへ移行する際に活用できるインポーターは以下のとおりです。\n\n\n- [GitHub](https://docs.gitlab.com/ee/user/project/import/github.html)\n\n-\n[別のGitLabインスタンス](https://docs.gitlab.com/ee/user/project/settings/import_export.html)\n\n- [Bitbucket\nCloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html)\n\n- [Bitbucket\nServer](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html)\n\n- [FogBugz](https://docs.gitlab.com/ee/user/project/import/fogbugz.html)\n\n- [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html)\n\n- [Jira（イシューのみ）](https://docs.gitlab.com/ee/user/project/import/jira.html)\n\n-\n[manifestファイルによるリポジトリのインポート](https://docs.gitlab.com/ee/user/project/import/manifest.html)\n\n-\n[URLによるリポジトリのインポート](https://docs.gitlab.com/ee/user/project/import/repo_by_url.html)\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\" alt=\"GitHub to GitLab Repo Exporter\">\n   \u003Cfigcaption>GitHubからGitLabへのリポジトリエクスポーター\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n各インポーターは、プロジェクトから異なる種類のデータをインポートします。インポーターによりGitLabへ移行できるデータの詳細については、[インポートとプロジェクトの移行に関するるドキュメント](https://docs.gitlab.com/ee/user/project/import/)を参照してください。さらに、[グループやプロジェクトのインポートを自動化](https://docs.gitlab.com/ee/user/project/import/#automate-group-and-project-import)したり、組織のニーズに合わせたカスタムソリューションを構築したりすることも可能です。\n\n\n- [プロフェッショナルサービス](https://about.gitlab.com/ja-jp/services/)\n\n-\n[移行ユーティリティ](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n\n-\n[移行に関するよくある質問](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n\n### リポジトリを移行する方法\n\nGitLabには組み込みのインポーターが用意されており、リポジトリの移行は簡単に行えます。例として、GitHubからGitLabへリポジトリをコピーし、[そのリソース](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data)（イシュー、プルリクエスト、マイルストーンなど）も含めて移行する方法をご紹介します。別のGitHubからGitLabへリポジトリを移行するには、以下の手順に従ってください。\n\n\n1. 左側のサイドバーの上部で、**新規作成**（+）を選択します。\n\n2. 「GitLab」セクションで**新規プロジェクト/リポジトリ**を選択します。\n\n3. **プロジェクトのインポート**を選択します。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>インポートするプロジェクトの選択\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n4. **GitHub**ボタンをクリックします。\n\n- GitLab\nSelf-Managedを使用している場合は、[GitHubインポーターを有効にする](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources)\n必要があります。\n    - 他のインポーターも同様の方法で開始できます。\n5. 次に、以下のいずれかの方法で認証します。\n    - GitHub OAuthで認証する場合：**GitHubで認証**を選択します。\n    - GitHubのパーソナルアクセストークンを使う場合：\n       - [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new)にアクセスします。\n       - **ノート**フィールドにトークンの説明を入力します。\n       - リポジトリスコープを選択します。\n       - オプションとしてコラボレーターをインポートするには、**read:org**スコープを選択します。\n       - **トークンの生成**ボタンをクリックします。\n       - GitLabのインポートページの「パーソナルアクセストークン」フィールドに、GitHubのパーソナルアクセストークンを貼り付けます。\n6. **認証**ボタンをクリックします。\n\n7. 移行するアイテムを選択します。\n\n8. 移行するプロジェクトと移行先を選択します。\n\n9. **インポート**ボタンを押します。\n\n\nこれで、インポートされたプロジェクトがワークスペースに追加されます。GitHubからGitLabへの移行に関する詳しいガイドについては、こちらの動画をご覧ください。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\nリポジトリの移行が完了したら、JenkinsのパイプラインでGitLab内のJenkinsfileを活用できるように設定できます。これは、Jenkinsのパイプライン設定メニューから、新しくインポートしたプロジェクトのリポジトリURLを指定することで実行できます。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\" alt=\"Jenkins Pipeline SCM settings\">\n   \u003Cfigcaption>JenkinsパイプラインのSCM設定\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\nの方法は、移行の初期段階でもJenkinsの既存の機能を維持しながらGitLabと並行して使用できるため、CI/CD機能の移行作業中にサービスが中断されるのを防げます。\n\n\nさらに、[GitLab\nJenkinsプラグイン](https://plugins.jenkins.io/gitlab-plugin/)を活用することで、移行をスムーズに進めることができます。このプラグインを使用すると、GitLabからJenkinsのビルドをトリガーしたり、ビルドのステータスを取得したりできるようになります。\n\n\n### CI/CDパイプラインを移行する\n\nリポジトリの移行が完了したら、今度はJenkinsのパイプラインをGitLabへ移行できます。このプロセスは比較的シンプルですが、JenkinsとGitLabの両方の概念や構文を理解する必要があります。\n\n\nJenkinsには、パイプラインを定義するための構文として宣言型とスクリプト型の2種類があります。今回は、最も一般的に使用されている宣言型パイプラインからの移行方法を解説します。\n\n\n### パイプラインを段階的に移行する\n\nこのチュートリアルでは、Jenkinsfile（Groovy）とGitLab\nCI/CDの設定ファイル（YAML）を比較しながら、Go言語で書かれたマイクロサービスをビルド、テスト、デプロイする方法を分析します。その後、GitLabでパイプラインを有効化し、実際の動作を確認します。このパイプラインは以下の処理を行います。\n\n\n- **alpine**タグ付きのGo言語コンテナイメージを使用する\n\n- Go言語のコードを実行可能なバイナリにビルドするジョブを実行する\n   - ビルドしたバイナリをアーティファクトとして保存する\n- ユニットテストを実行するジョブを実行する\n\n- stagingステージにデプロイするジョブを実行する\n   - コミットが**staging**ブランチに向けたものである場合のみ実行される\n   - **test**ステージが成功した後に開始される\n   - 以前のジョブで作成された実行可能なバイナリアーティファクトを使用する\n\n以下に、JenkinsとGitLabのパイプライン定義とコメントを示します。実際のパイプラインの動作は[Meow\nMigrationプロジェクト](https://gitlab.com/gitlab-de/projects/blogs/meow-migration)で確認できます。\n\n\nでは、Groovyで記述されたJenkinsfileを見ていきましょう。\n\n\n```  \n\n// 宣言型パイプラインの\n\n// トップレベルを定義します。\n\npipeline {\n\n  // ジョブ内で明示的に定義されていない場合に\n  // デフォルトで使用するエージェントを\n  // 指定します。\n    agent any\n\n  // 数値順に実行される\n  // ステージを定義します。各ステージは\n  // 1つのジョブのみを実行します。\n    stages {\n\n    // ステージの名前を定義します。\n        stage('build') {\n      // このジョブで使用する\n      // コンテナイメージを定義し、\n      //デフォルトの'agent any'を上書きします。\n      // 実行にはJenkins Docker\n      // プラグインの設定が\n      // 必要です。\n            agent { docker 'golang:alpine' }\n\n      // ステージが実行される際に\n      // 実行する処理の順序を\n      // 定義します。\n            steps {\n                sh 'go build -o bin/meow-micro'\n                sh 'chmod +x bin/meow-micro'\n            }\n\n      // ステージ完了後に\n      // 実行する処理を定義します。\n            post {\n              always {\n\n        // 他のジョブで使用するために\n        // ステージアーティファクトを\n        // 保存します。\n                archiveArtifacts artifacts: 'bin/meow-micro'\n                onlyIfSuccessful: true\n              }\n            }\n        }\n\n    stage('test') {\n            agent { docker 'golang:alpine' }\n            steps {\n                sh 'go test .'\n            }\n        }\n\n        stage('deploy') {\n      // このジョブを\n      // 実行するための\n      // 条件を定義します。この場合、\n      // stagingブランチでのみ\n      // デプロイジョブが実行されます。\n            when {\n              branch 'staging'\n            }\n            steps {\n                echo 'Deploying meow-micro to staging'\n        // buildステージで保存した\n        // アーティファクトを使用します。\n                sh './bin/meow-micro'\n            }\n        }\n    }\n}\n\n```\n\n\nでは、同じ機能をGitLabで作成する方法について見ていきましょう。\n\n\n```\n\n# ジョブ内で明示的に定義されていない場合に\n\n# デフォルトで使用するイメージを\n\n# 指定します。\n\ndefault:\n  image: alpine:latest\n\n# 実行するステージの順序を定義します。\n\n# 各ステージには複数のジョブを含めることができます。\n\nstages:\n  - build\n  - test\n  - deploy\n\n# ジョブ名を定義します。\n\ncreate-binary:\n # このジョブが実行されるステージを定義します。\n  stage: build\n # このジョブで使用するコンテナイメージを定義し、\n # デフォルトの設定を上書きします。\n  image: golang:alpine\n # ジョブ実行時に実行する\n # 一連の手順を定義します。\n  script:\n    - go build -o bin/meow-micro\n    - chmod +x bin/meow-micro\n # 他のジョブで使用するために\n # ジョブのアーティファクトを保存します。\n  artifacts:\n    paths:\n      - bin/meow-micro\n    expire_in: 1 week\n\nunit-tests:\n  stage: test\n  image: golang:alpine\n  script:\n    - go test .\n # ジョブの実行後に実行するコマンドを\n # 定義します。\n after_script:\n  - echo \"Tests Complete\"\n\nstaging-deploy:\n  stage: deploy\n # ジョブの実行前に実行するコマンドを\n # 定義します。\n  before_script:\n    - apk update\n  script:\n    - echo \"Deploying meow-micro to staging environment\"\n    - ./bin/meow-micro\n # このジョブが実行される\n # 条件を定義します。この\n # 場合、stagingブランチでのみ\n # staging-deployジョブが実行されます。\n  rules:\n    - if: $CI_COMMIT_BRANCH == 'staging'\n # buildジョブで保存されたアーティファクトを\n # このジョブで使用できるようにします。\n  artifacts:\n    paths:\n      - bin/meow-micro\n```\n\n\nご覧のとおり、JenkinsとGitLabの構文には多くの共通点があり、パイプラインの移行は比較的簡単です。ここでは基本的な例を紹介しましたが、両ツールの詳しい[機能や概念の比較](https://docs.gitlab.com/ee/ci/migration/jenkins.html#comparison-of-features-ad-concepts)もぜひご確認ください。\n\n\nJenkinsからGitLabへのマッピング方法を理解したところで、GitLabで同じ機能を持つパイプラインの作成を始めましょう。以下の手順でCI/CDを移行できます。\n\n\n##### 1. 先程GitLabに移行したリポジトリを開きます。\n\n- 左側のサイドバー上部で**検索または移動先…** を選択します。\n\n- プロジェクトを検索し、開きます。\n\n\n##### 2. [パイプラインエディタ](https://docs.gitlab.com/ee/ci/pipeline_editor/)を開きます。\n\n- 左側のサイドバーから**ビルド > パイプラインエディタ**を選択します。\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png\" alt=\"Pipeline editor menu\">\n   \u003Cfigcaption>パイプラインエディタのメニュー\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n- **パイプラインの設定** ボタンをクリックします。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\" alt=\"Configure pipeline selection\">\n   \u003Cfigcaption>「パイプラインの設定」を選択\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n##### 3. [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/)に入力します。\n\n- GitLab CIのパイプラインコードを追加します。\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png\" alt=\"Pipeline editor input\">\n   \u003Cfigcaption>パイプラインエディタへの入力\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n- 構文が正しいか検証します。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\" alt=\"Pipeline syntax validation\">\n   \u003Cfigcaption>パイプライン構文の検証\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n- パイプラインの構造を視覚化して確認します。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\" alt=\"Pipeline visualization\">\n   \u003Cfigcaption>パイプラインの視覚化\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n##### 4. ファイルをmainブランチにコミットします。\n\n- コミットメッセージを追加します。\n\n- ブランチがmainになっていることを確認します。\n\n- 「変更をコミットする」ボタンをクリックします。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\" alt=\"Commit changes dialog\">\n   \u003Cfigcaption>「変更をコミットする」のダイアログ\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\nファイルがマージされると、定義されたパイプラインが実行されます。プロジェクトページの**ビルド >\nパイプライン**から、実行中の[パイプラインを確認](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines)できます。今回は**main**ブランチで実行されているため、**create-binary**とunit-testsのジョブのみが表示されます。**staging-deploy**のジョブは、stagingブランチでのみ実行されます。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\" alt=\"Pipeline running on main branch\">\n   \u003Cfigcaption>mainブランチで実行中のパイプライン\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\nstagingブランチを作成すると、以下のパイプラインが開始されるのを確認できます。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\" alt=\"Pipeline running on staging branch\">\n   \u003Cfigcaption>stagingブランチで実行中のパイプライン\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\nジョブをクリックすると、その出力を確認できます。\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\" alt=\"create-binary job output\">\n   \u003Cfigcaption>create-binaryジョブの出力\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\" alt=\"unit-tests job output input\">\n   \u003Cfigcaption>unit-testsジョブの出力\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\n\u003Ccenter>\n\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\" alt=\"staging-deploy job output\">\n   \u003Cfigcaption>staging-deployジョブの出力\u003C/figcaption>\n\u003C/figure>\n\n\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\nこのように、create-binaryジョブで保存されたアーティファクトが、staging-deployジョブで使用されることが確認できます。これだけの手順で、JenkinsのパイプラインをスムーズにGitLabへ移行できます！\n\n\n### 移行に関するその他の考慮事項\n\nデプロイプロセスをよりシンプルにするために役立つポイントとして、以下の点を考慮することをおすすめします。\n\n\n-\nタスクをそのまま1:1でGitLabのジョブに移行しようとしない：既存のパイプラインが何を行っているのか、どのような問題を解決しているのかを整理し、理解する時間を確保することが重要です。\n\n\n- 一部のJenkinsジョブは複雑すぎてすぐにGitLabに移行できない場合がある：そのため、[GitLab\nJenkinsプラグイン](https://plugins.jenkins.io/gitlab-plugin/)を活用し、JenkinsのパイプラインをGitLabから直接起動し、結果を表示できるようにするとよいでしょう。これにより、一部の処理を徐々にGitLabに移行し、最終的にパイプライン全体をGitLabへ統合できます。\n\n\n-\nGitLabが提供する組み込みテンプレートを活用し、[セキュリティスキャナーやコード品質チェック](https://docs.gitlab.com/ee/user/application_security/)を最初から導入する：これにより、セキュリティのシフトレフトを行い、漏洩のリスクを低減できます。\n\nまた、CI/CDの設定を過度に複雑にしないようにし、すべての機能を一度に活用しようとするのではなく、コードをモジュール化し、複数の小さなステップに分けて導入するようにしてください。\n\n\n- モニタリングとガバナンスを最初から実装する。\n\n\n- GitLab\nRunner（Go）はJenkinsエージェント（Java）とは動作が異なる可能性があることを理解する：CPU使用率やメモリ消費量が異なる可能性があるため、時間をかけて比較しながら調整する必要があります。\n\n\n- 自動スケーリングの導入を検討し、週末や業務時間外に不要なリソースをシャットダウンすることを検討する。\n\n\n-\nジョブのコンテナ化を進め、アプリケーション開発をモダナイズする：現在ではJenkinsのジョブはコンテナ上ではなく、仮想マシン（VM）として動作するJenkinsエージェント上で実行されます。\n\n\nこのリストはすべての考慮事項を網羅しているわけではありませんが、移行を進めるうえで重要なポイントを押さえています。さらにサポートが必要な場合は、GitLabの[プロフェッショナルサービス](https://about.gitlab.com/ja-jp/get-help/)を活用し、移行プロセスをスムーズに進めることも可能です。\n\n\n### 関連リンク\n\nここまでお読みいただきありがとうございます！本ガイドが、JenkinsからGitLabへ移行するメリットと手順を理解する助けとなれば幸いです。まだ迷っている方は、ぜひ[GitLabの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)でDevSecOpsプラットフォームの価値を実感してください！\n\n\nさらに詳しく知りたい方のために、GitLabの機能やDevSecOpsプラットフォームのメリット、Jenkinsからの移行に関する情報を学べるリソースをいくつかご紹介します。\n\n\n- [Jenkinsからの移行（英語）](https://docs.gitlab.com/ee/ci/migration/jenkins.html)\n\n-\n[移行計画の立て方（英語）](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html)\n\n- [GitLabプロジェクトインポーター（英語）](https://docs.gitlab.com/ee/user/project/import/)\n\n-\n[チュートリアル：簡単にできるGitHubからGitLabへの移行（英語）](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n\n-\n[動画：簡単にできるGitHubからGitLabへの移行（英語）](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n\n- [JenkinsからGitLabへ:\nCI/CD環境をモダナイズするための究極ガイド（英語）](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n\n\n\u003Cbr>\n\n\u003Cbr>\n\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\u003Cbr>\n",[110,702],"2025-04-15",{"slug":3652,"featured":92,"template":681},"jenkins-to-gitlab-migration-made-easy","content:ja-jp:blog:jenkins-to-gitlab-migration-made-easy.yml","Jenkins To Gitlab Migration Made Easy","ja-jp/blog/jenkins-to-gitlab-migration-made-easy.yml","ja-jp/blog/jenkins-to-gitlab-migration-made-easy",{"_path":3658,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3659,"content":3665,"config":3672,"_id":3674,"_type":16,"title":3675,"_source":17,"_file":3676,"_stem":3677,"_extension":20},"/ja-jp/blog/southwest-looking-to-help-developers-take-flight",{"title":3660,"description":3661,"ogTitle":3660,"ogDescription":3661,"noIndex":6,"ogImage":3662,"ogUrl":3663,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3663,"schema":3664},"ソフトウェア開発効率化に成功したサウスウエスト航空の事例","GitLabのDevSecOpsプラットフォームによって業務削減と開発効率化に成功したサウスウエスト航空の事例をご紹介します。ぜひ参考にしてください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665272/Blog/Hero%20Images/AdobeStock_380312133.jpg","https://about.gitlab.com/blog/southwest-looking-to-help-developers-take-flight","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ソフトウェア開発効率化に成功したサウスウエスト航空の事例\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n        \"datePublished\": \"2024-01-30\",\n      }",{"title":3660,"description":3661,"authors":3666,"heroImage":3662,"date":3668,"body":3669,"category":2156,"tags":3670,"updatedDate":2549},[3667],"Sharon Gaudin","2024-01-30","世界最大の格安航空会社「サウスウエスト航空」のITリーダーは、デベロッパーのワークフローから時間のかかる反復作業を取り除き、時間に余裕を持たせることで、より大きなプロジェクトに集中できる環境を作り上げています。特に意識しているのは、デベロッパーの仕事を「容易」にすることです。\n\n航空会社のDevOpsチームが、GitLabの導入と運用によって問題の検出力と解決力を飛躍的に向上させている事例についてご紹介します。\n\nサウスウエスト航空の副社長兼最高情報責任者であるJim Dayton氏は、次のように述べています。\n「デベロッパーを阻害する要因をできる限り取り除くことが、当社のやり方です。彼らがソフトウェア開発に携わるのは、その創造性が好きで、問題解決が大好きだからだと確信しています。よって、私たちの役割は、彼らの邪魔をしているものを排除することなのです。」\n\nDayton氏がこの考えを実現するために利用しているものが[GitLabのプラットフォーム](https://about.gitlab.com/ja-jp/platform/)です。\n\nDayton氏は、GitLabがダラスで開催した「[DevSecOps World Tour](https://about.gitlab.com/events/devsecops-world-tour/)」の舞台上インタビューで、デベロッパーの立場に立ちながら彼らの業務を滞りなく進行させるサウスウエスト航空の取り組みについて語りました。また、GitLabのエンタープライズソリューションアーキテクチャのディレクターであるReshmi Krishnaとの対談では、人工知能機能がチームにもたらすメリットについて意見を述べました。\n\nサウスウエスト航空の幹部は、アプリケーション開発にDevOpsアプローチを導入していると述べ、同社がデベロッパーにより多くの自己解決型ツールとナレッジマネジメントプロセスを提供していると語りました。\n\n「私たちは、デベロッパーが問題をより素早く調べ、解決策を発見できるようにして、頭の切り替えをできる限り減らしたいと考えています。幹部の私たちが、彼らに求めることを正確に把握し、何が彼らの生産性を妨げているのかを見極めなければなりません。」\n\nDayton氏によると、サウスウエスト航空は2019年にGitLabとの関係を確立して以来、ソフトウェア開発プロセスの一貫性確保に注力しています。これは、コードをGitLabの共有リポジトリに移すことを意味します。すべてのコードがどこに保管されているのかを把握することで、チームはより簡単に指標を評価し、コードの再利用による効率化を目指せるようになります。\n\nDayton氏は次のように付け加えました。  \n「弊社は現在、エンタープライズ・パイプラインを完成させる過程にあり、チームの移行を開始する準備が整っています。様々なアプリケーション開発チームと緊密に協力しており、新たに構築中のパイプラインに必要なものを理解し、移行する準備を進めています。年末までにはほとんどのプロセスが完了すると想定しています。」\n\n### AIの将来性\n\nDayton氏は、AIの利用はデベロッパーがより大きく、より革新的なタスクに集中できるようにする方法の1つだと述べています。\n\n生成AIは、脆弱性の説明やコードの提案、コード補完のいずれにおいても、ソフトウェア開発におけるライフサイクル全体のワークフローに多大な影響を与える能力を備えています。プラットフォームに組み込まれたAIツールを活用することで、セキュリティを強化し、コードレビューやアプリケーション開発に費やす時間を短縮できます。\n\nDayton氏は、AI機能を使用することで開発とデプロイを迅速かつ容易にできるようになると期待を寄せています。\n\n「私たちは、凡庸で形式的な作業をできる限り排除したいと思っています。AIを使えば、それが実現できるかもしれません。AIについては大きな話題性がある一方で、実際に大きな可能性も秘めています。特定されたばかりの脆弱性に対するソリューションを即座に提供できること、コードの一部がどのような処理を行っているかを教えてくれることなどは、そのすばらしい例です。これが何と統合しているのか、アクセスしているデータは何か、その理由などもAIが教えてくれます。例えば、このアプリケーションで過去1年間に発生したインシデントの20%が、この特定のコーディングセットによるものであることの理由を英語でわかりやすく説明してとAIに依頼もできます。AIの力が発揮されるのはこういうところでしょう。」\n\nDayton氏は、AIがデベロッパーに取って代わることはないが、彼らの仕事をスムーズに進められるよう支援するだろうと考えます。AIがもたらすもう一つのメリットは、コロナ後に多くの人がリモートで仕事をしている時代に、デベロッパーをつなぐことも挙げられます。\n\n「GitLabのロードマップにある便利な機能のひとつが『レビュアーの推奨』です。以前であればコードレビューを依頼する際には、壁越しや別の部屋に向けて『誰か私のコードを見てくれないか』と叫ぶ必要がありましたが、リモートの環境においてはそれは不可能です。AIは、そのコードで実際に作業したことがある人や、そのコードでインシデントを解決したことがある人を見つけ出し、提案してくれます。これがレビュープロセスにどのくらいの価値をもたらすのかは容易に想像できるでしょう。自動化が進めば進むほど、手動のステップや待機時間が少なくなると思います。」\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/UnUfp7pKnEQ?si=qcX2Qm3zpgQOV4xy\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*サウスウエスト航空はテキサス州ダラスに拠点を置く、およそ240億ドル規模の企業です。72,000人の従業員を擁し、120の目的地に1日4,000便を運航しています。サウスウエスト航空は他のどの航空会社よりも国内線を多く運行しています。GitLabのさらなる魅力については、 [GitLabを選ぶ10の理由](https://about.gitlab.com/customers/)をご覧ください。*",[1190,3671,721,762],"DevOps platform",{"slug":3673,"featured":6,"template":681},"southwest-looking-to-help-developers-take-flight","content:ja-jp:blog:southwest-looking-to-help-developers-take-flight.yml","Southwest Looking To Help Developers Take Flight","ja-jp/blog/southwest-looking-to-help-developers-take-flight.yml","ja-jp/blog/southwest-looking-to-help-developers-take-flight",{"_path":3679,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3680,"content":3686,"config":3692,"_id":3694,"_type":16,"title":3695,"_source":17,"_file":3696,"_stem":3697,"_extension":20},"/ja-jp/blog/u-s-navy-black-pearl-lessons-in-championing-devsecops",{"title":3681,"description":3682,"ogTitle":3681,"ogDescription":3682,"noIndex":6,"ogImage":3683,"ogUrl":3684,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3684,"schema":3685},"米国海軍 Black Pearl: DevSecOps の推進における教訓","Sigma Defense社がDevSecOpsセキュリティとコンプライアンスを考慮し、米海軍Black PearlでDevSecOpsを導入した成功事例を見ていきましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png","https://about.gitlab.com/blog/u-s-navy-black-pearl-lessons-in-championing-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"米国海軍 Black Pearl: DevSecOps の推進における教訓\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2023-12-12\",\n      }",{"title":3681,"description":3682,"authors":3687,"heroImage":3683,"date":3688,"body":3689,"category":2156,"tags":3690,"updatedDate":3691},[2316],"2023-12-12","米国政府請負業者である[Sigma Defense（英語）](https://sigmadefense.com/)のエンジニアリングディレクター、Manuel Gauto氏は、真のDevSecOps推進者です。Gauto氏は、Sigma Defenseが米国海軍向けに管理するDevSecOps環境「Black Pearl」の共同開発者として、開発、セキュリティ、運用の統合が、ソフトウェア開発のモダナイゼーションとスケーリングにおいてどれほど力を発揮できるかを直接目の当たりにしています。\n\nGauto氏は、「DevSecOps環境が正しく構築されていれば、ツール、セキュリティとコンプライアンス、接続性、オンボーディングといった要素がすべてプラットフォームの一部として扱われますから、ミッションの担当者は自分たちのミッションの状況に合わせてCI/CDの習熟に集中できます」と言います。\n\nまた、Gauto氏はワシントンD.C.で開催されたGitLabのDevSecOps World Tourに参加し、GitLab FederalのCTOであるJoel Krooswykとともに「Black Pearl」について語りました。特に、多数のソフトウェアファクトリーを統合し、単一で管理できるDevSecOpsクラウド環境に移行することで大きな成果が得られたと話し、具体的な成果として次の点を挙げました。\n\n- ソフトウェアファクトリーの準備時間が約6か月から3〜5日へと大幅に短縮\n- コストが約400万ドルから約40万ドルへと10分の1に削減\n- 運用許可（ATO: Authorization to Operate）による固有のセキュリティがあるため、より安全な環境を実現\n- オンボーディング時間が5週間から1日に短縮\n\n## Black Pearlの起源\n\n数年前、米国海軍は数多くのソフトウェアファクトリーを同時に稼働させていました。Gauto氏自身も、そのいくつかの立ち上げに関わっていました。「私たちは、多くのソフトウェアファクトリーを同時に稼働することは効率的なアプローチではないと気付きました。4か所か5か所の異なる場所でインフラが重複し、それぞれでまったく同じことを行っていたのです」とGauto氏は振り返ります。\n\nそこで、チームは、単一環境を提案しました。クラウドインフラを統合し、セキュリティの問題に対処し、接続性を提供できる環境を構築してはどうだろうかと。この単一環境は「Black Pearl」と名付けられ、現在は2つのサービスがあります。ひとつはLighthouseで、DevSecOpsのInfrastructure as Code（IaC）またはConfiguration as Code（CaC）のベースラインです。もうひとつはParty Bargeといい、マネージド型の共有サービスです。\n\nBlack Pearlの共通ソフトウェア環境には、運用許可（ATO）が与えられており、標準化されたDevSecOpsツール、パイプラインコンポーネントのテンプレート、ガバナンス/管理、ログおよびメトリクス、統合インフラ、クラウド自動化、コンピューティングリソースが利用できます。GitLabのDevSecOpsプラットフォームはBlack Pearlの要となる部分であり、ソースコード管理、タスク、ドキュメンテーション、およびセキュリティスキャンのための「ワンストップショップ」となっています。Gauto氏は、ソフトウェアのリリース判定には、ダッシュボードと可視化が特に重要であると語っています。\n\n「GitLabは私たちのニーズを実現可能にするプラットフォームです。これまでの開発では異なるツールを使い分ける必要があったのですが、今では組織内の開発でも、GitLabだけですべてが行えます。全員がひとつのプラットフォームに集まりますから、コラボレーションにおける効率も向上します」とGauto氏は語っています。\n\nGauto氏は、GitLabの機能が、スピードや安全面だけでなくコスト効率においてもソフトウェアファクトリーの立ち上げをサポートしていると言います。\n\n> 公共部門でのGitLabの活用法について詳しく見るには、[今すぐこちらからお問い合わせください]( https://about.gitlab.com/ja-jp/solutions/public-sector/)。\n\n## 強靭なDevSecOps環境を構築する方法\n\nBlack Pearlの立ち上げ以来、Gauto氏は強靭で安全な DevSecOps環境を構築するために何が重要なのかを数多く学んできました。Gauto氏は、重要なのは、サイロ化の解消、開発エコシステムの確立、DevSecOps環境におけるセキュリティとコンプライアンスの一元化、人材のオンボーディングを円滑かつ迅速にすること、柔軟性を保ちイノベーションに対してオープンであり続けることだと明かします。\n\n### 強力な開発エコシステムを確立する\n\n大規模組織、特に政府機関の間では、ソフトウェア開発がサイロ化に陥りがちです。「イノベーションのための部門があっても、コラボレーションの足かせとなることがあります。その部門が、ある環境や建物内では機能していても、他と連携するのが難しくなることがあります」とGauto氏は述べ、コード、ベストプラクティス、ツール、インフラなどの共有は難しい場合があると言います。\n\n「しかしGitLabを使用して適切に確立、管理されたツールのデプロイを構築すれば、他のチームが何をしているかが見えるようになり、より容易に共有ができるようになります」とGauto氏。「国内の別のラボにCDを郵送する代わりに、DevSecOpsチームが『あなたをこちらのプロジェクトのデベロッパーとして追加するので、リポジトリを自由に操作してください』と言うだけです」。\n\nエコシステムは、インフラストラクチャの認証での障壁を打破することで、ニーズを集約する助けになります。組織間に介在する認証はどのコミュニティにも共通する課題です。請負業社や政府のコンピュータが、どこからでもインターネット経由でBlack Pearlに接続できるようにすることに関して、「非機密下では他との連携において障壁となりうる認証を難しくしないことが大切です」とGauto氏は口にします。\n\n強靭なエコシステムがあれば、プランニング（アジャイル、スクラム、カンバンなど）に関するベストプラクティスやプロセスを構築し、オンサイトとリモートでの開発を統合し、ソフトウェアの承認を得て、さまざまな環境にアプリケーションを届けられます。\n\n### セキュリティとコンプライアンスを適用する\nDevSecOps環境におけるセキュリティとコンプライアンスに関して Gauto氏は、「最も重要なのは、列車が線路を進んでくるのが見えたら、可能な限り事前に準備を整えておくこと」と話しつつ、「驚かないように、そして電車が来たとき線路に立っていないようにすることです」と語りました。\n\nこの考えが完全に当てはまる分野のひとつがコンプライアンスです。この分野では、規制が目まぐるしい速さで進化しています。「データやツールを、役割に見合った人がすぐに理解できる形式で提供できるように準備したい」とGautoは氏は言います。\n\nこの課題にもGitLab が上手く機能したとGauto氏は評価しています。同氏は「GitLab Ultimateは、はじめからコンプライアンスを組み込むことができ、多くの要素をテンプレート化できる」とした上で、顧客は直ちにコンプライアンスを遵守した運用を開始できると述べました。\n\nGitLabは、単一のプラットフォーム内でのライセンスとATOスキャンもサポートしています。\n\n### 人材の迅速なオンボーディングをサポートする\n\n軍において、トップレベルのDevSecOps人材を確保するにはいくつか障害があります。例えば、窓のない建物での勤務を厭わないことや、機密ネットワークで作業するための多くの手続きや規制をクリアしなければならないことです。\n\n「こういったことが、私たちが抱える非常に難しい問題を解決できる優秀な人材を呼び込む能力を大きく制限していると思います」とGauto氏。Black Pearlのミッション支援を成功裏におさめるには、「できるだけ幅広い人材へのアクセスを可能にし、その後、持続可能なオンボーディングのワークフローを構築すること」が不可欠でした。\n\n国防総省（DoD）内には解決を必要とする難しい問題が数多く存在しますが、政府、産業界、学界という異なる組織を横断して連携する能力が制約要因となることがあります。「ソフトウェア開発が行われている場所は多数ありますが、共通の作業環境がなければ、作業が重複したり、失われたり、十分に活用されなかったりすることがあります」とGauto氏は訴えます。\n\nBlack Pearlは、異なる組織がアクセスしやすい形で連携できる環境を提供しています。Black Pearlは、認可されたユーザーが煩雑なアクセス手順なしに、さまざまなデバイス、ネットワーク、ロケーションから環境にアクセスできるようにすることを第一目標にしています。このアプローチは、新しいアイデアの創出を促進し、新しい機能の実現をスピードアップします。\n\n### 柔軟性を保ちイノベーションを実現する\n\n軍には、潜水艦から航空母艦まで、多種多様な配備環境があるため、Black Pearlはことのほか柔軟でなければなりません。「私たちは、一人ひとりが自分の領域を管理でき、それぞれの問題領域に特化した部分に努力を集中できるようにしています」とGauto氏は語ります。「それひとつですべてを統制できるようなパイプラインなどないことは分かっています。だからこそ、ツールキットを提供し、全ユーザーがそれぞれのニーズに合わせてソリューションをカスタマイズできるようにしています。『ソフトウェア開発はこの方法で行うべきだ、こうやってデリバリーを行なうべきだ』とは言いません」。\n\nBlack Pearlは、顧客がCI/CDパイプライン、スキャン、テストなどのGitLab Ultimateの構成要素を活用し、それぞれの環境において責任を持つよう推奨しています。「お客様には、私たちが提供するすべてのツールを使えるレベルに到達してほしいと考えています」とGauto氏は言います。また、Black Pearlが顧客に機能を提案するのではなく、顧客が自己の要件を主導できるように顧客を教育しています。\n\nたとえば、Black Pearlチームは、海軍のイージス統合兵器システムのソフトウェアファクトリーであるThe Forgeの開発チームと緊密なコラボレーションを図っています。「ある日、The Forge チームが『ソースコードをチェックインする前に、それに機密情報が含まれていないかスキャンすべきだと思います』と言ったのですが、まさにその通りでした」。\n\nGauto氏はまた、イノベーションを抑制したり、顧客を過度に制約したりしないように注意したいとも考えています。「すべてがクラウドに格納されるコンテナ化されたビジネスアプリケーションというわけではありませんからね」と Gauto氏。同氏はチームメンバーに「独自のアプローチを取る人に対してこそ柔軟に対応する戦略を」と指示しています。「なぜなら、風変わりなことをしている人はたいてい、何か面白いことをしているからです」。\n\n人工知能（AI）と機械学習は、この哲学の試金石となるでしょう。「これから、斬新なツールや目新しいデータ分類が生み出されていく中で、私たちはそれらに迅速に、かつ繰り返し対応していく必要があるでしょう」とGauto氏は語っています。\n\n## 証明された理論\nGauto氏は、Black Pearlの導入率が過去12ヶ月で400%増加したことを誇りに思っています。これが同氏の唱えるコンセプトの有効性を証明していると考えるからです。「『煩わしい作業』は気にせず、問題を迅速に解決できようにするマネージドサービスというBlack Pearlの理論は機能し、価値があります」とGauto氏は語っています。\n\n> [公共部門でのGitLabの活用法](https://about.gitlab.com/ja-jp/solutions/public-sector/)をもっと知りたいですか。こちらをお読みください。",[702,904,722,270,188],"2024-12-04",{"slug":3693,"featured":92,"template":681},"u-s-navy-black-pearl-lessons-in-championing-devsecops","content:ja-jp:blog:u-s-navy-black-pearl-lessons-in-championing-devsecops.yml","U S Navy Black Pearl Lessons In Championing Devsecops","ja-jp/blog/u-s-navy-black-pearl-lessons-in-championing-devsecops.yml","ja-jp/blog/u-s-navy-black-pearl-lessons-in-championing-devsecops",{"_path":3699,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3700,"content":3707,"config":3713,"_id":3715,"_type":16,"title":3716,"_source":17,"_file":3717,"_stem":3718,"_extension":20},"/ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":3701,"description":3702,"ogTitle":3703,"ogDescription":3702,"noIndex":6,"ogImage":3704,"ogUrl":3705,"ogSiteName":1223,"ogType":1224,"canonicalUrls":3705,"schema":3706},"チュートリアル：GitLabでリリースとリリースノートを自動化する","GitLabのChangelog APIを使用すると、リリースアーティファクト、リリースノートなどの変更をまとめた、包括的な変更履歴の生成を自動化できます。","チュートリアル：GitLabでリリース自動化とリリースノート自動生成","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab","\n                        \n        {\"@context\": \" https://schema.org \",\n        \"@type\": \"Article\",\n        \"headline\": \"チュートリアル：GitLabでリリース自動化とリリースノート自動生成\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\n      \",}",{"title":3703,"description":3702,"authors":3708,"heroImage":3704,"date":3710,"body":3711,"category":701,"tags":3712,"updatedDate":1269},[3709],"Ben Ridley","2023-11-01","***2025年の更新情報**  GitLab Changelog APIは進化を続けており、今回のブログでは取り上げていない優れた新機能も追加されています。たとえば、コミット履歴からテンプレート化された値を使ってカスタムの変更履歴を提供できるようになっています。[詳しくは、変更履歴に関する公式ドキュメントをご覧ください。](https://docs.gitlab.com/user/project/changelogs/)*\n\nユーザーが頼りにしているソフトウェアを開発する際には、各リリースでの変更点を効果的に伝えることが不可欠です。新機能や変更点、削除された内容をきちんと伝えることで、ユーザーはソフトウェアを最大限に活用でき、アップグレード時の思わぬトラブルも回避できます。\n\nこれまで、リリースノートの作成や変更履歴の管理は手間のかかる作業でした。デベロッパーが外部ツールで変更を追跡したり、リリースマネージャーがマージ履歴を手作業で確認したりする必要があったためです。GitLabのChangelog APIを使うと、Gitリポジトリに記録された豊富な履歴情報を活用して、リリースノートの作成や変更履歴の管理を簡単に行うことができます。\n\nこのチュートリアルでは、GitLabを使ったリリースの自動化について詳しく説明します。リリースアーティファクトの生成、リリースノートの作成、そしてユーザーに関係する変更点をすべて網羅した包括的な変更履歴の生成方法について取り上げます。\n\n## GitLabにおけるリリース\nまずは、GitLabでリリースがどのように機能しているのかを見ていきましょう。\n\nGitLabにおけるリリースとは、Gitタグで識別される特定のコードバージョンのことを指します。このリリースには、前回のリリース以降に行われた変更内容（およびリリースノート）や、そのバージョンのコードからビルドされた関連アーティファクト（Dockerイメージ、インストールパッケージ、ドキュメントなど）が含まれます。\n\nリリースは、GitLabのUIを使って作成・管理することもできますし、Release APIを呼び出すか、CIパイプラインの中に特別な`release`ジョブを定義することでも実現できます。このチュートリアルでは、CI/CDパイプライン内の`release`ジョブを使用します。これにより、テストやコードスキャンなどに使っている自動化プロセスを、リリースの実行にも拡張できるようになります。\n\nリリースを自動化するために、まず確認しなければならないことがあります。「リリースノートや変更履歴を作成するための変更情報は、どこから取得するのか？」その答えは、Gitリポジトリです。コミットメッセージやマージコミットの履歴を通じて、豊富な開発履歴が得られます。この情報を活用して、リリースノートや変更履歴を自動生成できるか試してみましょう。\n\n## コミットトレーラーの導入\n[コミットトレーラー](https://git-scm.com/docs/git-interpret-trailers)とは、Gitのコミットメッセージの末尾に追加する、構造化されたエントリーのことです。書き方はシンプルで、`\u003CHEADER>:\u003CBODY>`という形式のメッセージをコミットの最後に追加するだけです。これにより、`git`のコマンドラインインターフェース（CLI）ツールがそれらを解析して、他のシステムで利用できるようになります。たとえば、すでに使ったことがあるかもしれませんが、`git commit --sign-off`でコミットに署名する機能もこの仕組みを使っています。これは、`Signed-off-by: \u003Cあなたの名前>`というトレーラーをコミットに追加することで実現されています。このトレーラーには、好きな構造化データを自由に追加できるので、変更履歴に役立つ情報を保存する場所として非常に便利です。\n\n実際に、コミットに`Changelog: \u003Cadded/changed/removed>`というトレーラーを使うと、GitLabのChangelog APIがそれを解析し、自動的に変更履歴を生成してくれます！\n\nそれでは、実際のコードベースに変更を加えてリリースを行い、リリースノートと変更履歴のエントリーを生成する手順を見ていきましょう。\n\n## サンプルプロジェクトについて\n今回のブログでは、シンプルなPythonのWebアプリのリポジトリを使っています。仮に、このアプリケーションのバージョン1.0.0がちょうどリリースされたばかりで、これが現在のコードのバージョンだとしましょう。また、GitLab上で1.0.0のリリースも作成してありますが、これはまだ自動化されたリリースパイプラインを作っていないため、手動で作成しました。\n\n![GitLabのUI上で、バージョン1.0.0のリリースが表示されているスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n## 変更の実施\n現在は開発を急ピッチで進めている段階なので、今日はアプリケーションのバージョン2.0.0のリリース作業を進めていきます。2.0.0リリースでは、アプリに新機能の「チャットボット」を追加します。そして、量子ブロックチェーン機能は削除します。これは最初のベンチャーキャピタル向けに必要だっただけなので、もう不要です。さらに、2.0.0リリースに向けて、CI/CDパイプラインに自動リリースジョブも追加する予定です。\n\nまずは不要な機能の削除から始めましょう。不要な部分を削除したマージリクエストを作成しました。ここで重要なのは、コミットメッセージに`Changelog: removed`トレーラーを含めることです。これを行う方法はいくつかあります。たとえば、最初からコミットに直接含めたり、インタラクティブリベースを使ってCLIで後から追加したりもできます。しかし、今回の状況では、一番簡単な方法は最後にGitLabの`Edit commit message`ボタンを使って、マージコミットにトレーラーを追加する方法だと思います。\n\n![GitLabのUIに表示された、使われていない機能を削除するマージリクエストのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\nこの方法を使えば、マージコミットのタイトルをもっと簡潔なものに変更することもできます。ここでは、マージコミットのタイトルを'Remove Unused Features'に変更しました。これは変更履歴のエントリに表示されます。\n\n次に、2.0.0リリース用の新機能を追加しましょう。ここでも、新機能を含む別のマージリクエストを開き、マージコミットを編集して`Changelog: added`トレーラーを追加し、コミットのタイトルをより簡潔に編集するだけです。\n\n![GitLabのUIに表示された、新しい機能を追加するマージリクエストのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png) \n\nこれで、バージョン2.0.0をリリースする準備はほとんど整いました。ただし、今回は手動でリリースを作成したくありません。そのため、リリースの前に`.gitlab-ci.yml`ファイルにいくつかのジョブを追加し、コードに`2.0.0`のような新しいバージョンのタグを付けた際に、自動でリリース処理を行い、対応するリリースノートや変更履歴のエントリを生成するようにします。\n\n**注：**変更履歴のトレーラーを強制したい場合は、[Dangerのようなツールを使用して、マージリクエストの規則を自動的にチェックする](https://docs.gitlab.com/ee/development/dangerbot.html)方法を検討してください。\n\n## 自動リリースパイプラインの構築\nパイプラインを機能させるには、プロジェクトアクセストークンを作成し、GitLabのAPIを呼び出して変更履歴のエントリーを生成できるようにする必要があります。[APIスコープを指定してプロジェクトアクセストークンを作成](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token)し、それを`CI_API_TOKEN`という名前の[CI/CD変数として保存](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui)します。この変数を参照して、APIの認証を行います。\n\n次に、`gitlab-ci.yml`ファイルに以下の2つの新しいジョブを追加します。\n```yaml\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\n上記の設定では、`prepare_job`が`curl`と`jq`を使ってGitLabのChangelog APIエンドポイントを呼び出し、その結果を`release_job`に渡して、リリースの作成を行います。詳しく見ていきましょう。\n- まず、先ほど作成したプロジェクトアクセストークンを使ってGitLabのChangelog APIを呼び出し、リリースノートを生成します。そして、その出力をアーティファクトとして保存します。\n- バージョンには`$CI_COMMIT_TAG`変数を使用しています。この仕組みが機能するには、タグにセマンティックバージョニング（たとえば`2.0.0`のような形式）を使用する必要があります。そのため、リリースジョブには、セマンティックバージョンのタグが付いているかどうかを確認する`rules`セクションを追加しています。\n\t- GitLabのChangelog APIを使うには、セマンティックバージョニングが必要です。この形式を用いて、現在のリリースとの比較対象となる最新リリースを特定します。\n- GitLabが提供する公式の`release-cli`イメージを使用しています。ジョブ内で`release`キーワードを使うには、この`release-cli`が必要です。\n- `release`キーワードを使用して、GitLab上にリリースを作成します。これは、リリースの作成と必須フィールドの入力のために確保されている特別なジョブキーワードです。\n- リリースの`description`には、ファイルを引数として渡すことができます。今回の例では、`prepare_job`で生成し、アーティファクトとしてこのジョブに渡されたファイルを使っています。\n- さらに、パイプラインの早い段階でビルドされているコンテナイメージも、リリースアセットとして追加しています。ビルドプロセスの中で作成したバイナリやドキュメントなども、パイプライン内でアップロード済みのURLを指定することで、リリースアセットとして添付できます。\n\n## 自動リリースの実行\nこの設定が完了すれば、リリースを実行するために必要なのは、バージョン付けのルールに従ったタグをリポジトリにプッシュすることだけです。CLIからタグをプッシュすることもできますが、ここではGitLabのUIを使って、mainブランチにタグを作成する例をご紹介します。タグを作成するには、サイドバーからコード > タグ > 新しいタグを選択します。\n![タグの作成方法を示すGitLabのUIのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\nタグの作成が完了すると、パイプラインの実行が開始されます。 GitLabのChangelog APIが、今回のリリースと前回のリリースの間に行われた変更をすべて含むリリースノートをMarkdown形式で自動的に生成します。 以下は、この例で生成されたMarkdownの出力結果です。\n\n```md\n## 2.0.0 (2023-08-25)\n\n### added (1 change)\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n### removed (1 change)\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n```\n\nご覧のとおり、GitLabはgitのコミットトレーラーをもとに、リリースノートのエントリを自動で抽出しています。さらに、変更の詳細やディスカッションが確認できるよう、マージリクエストへのリンクも付けられています。\n\nそしてこちらが、最終的に作成されたリリースです。\n![GitLabのリリースUIに表示された、バージョン2.0.0のリリース画面](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n## 変更履歴の作成\n次に、変更履歴（すべてのリリースノートをまとめた履歴）を更新します。これを行うには、先ほど使用したChangelog APIエンドポイントに対して、`POST`リクエストを送ります。\n\n必要であれば、この処理をリリースパイプラインの一部として実行することも可能です。たとえば、prepareジョブの`script`セクションに以下の内容を追加します。\n```sh\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n```\n\n**この処理は実際にリポジトリを変更する点にご注意ください。** 具体的には、最新のリリースノートを`CHANGELOG.md`ファイルに追加するためのコミットが作成されます。\n![変更履歴ファイルを更新するコミットを示すリポジトリのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\nこれですべて完了です！`git`が提供する豊富な履歴情報と、便利なコミットトレーラーを活用することで、GitLabの強力なAPIとCI/CDパイプラインを使って、リリースプロセスとリリースノートの生成を自動化できます。\n\n> この記事で使用したプロジェクトを実際に確認したい場合は、[こちらのリンク](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo)からご覧いただけます。\n",[985,1410,110,1190,702,966],{"slug":3714,"featured":6,"template":681},"tutorial-automated-release-and-release-notes-with-gitlab","content:ja-jp:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"_path":3720,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3721,"content":3727,"config":3734,"_id":3736,"_type":16,"title":3737,"_source":17,"_file":3738,"_stem":3739,"_extension":20},"/ja-jp/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions",{"title":3722,"description":3723,"ogTitle":3722,"ogDescription":3723,"noIndex":6,"ogImage":3724,"ogUrl":3725,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3725,"schema":3726},"AIを活用して学ぶ、Rustの高度なプログラミング","このガイド付きチュートリアルでは、AIを搭載したGitLab Duoのコード提案を活用しながら、Rustの高度なプログラミングを学ぶことができます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662439/Blog/Hero%20Images/codewithheart.png","https://about.gitlab.com/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AIを活用して学ぶ、Rustの高度なプログラミング\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2023-10-12\",\n      }",{"title":3722,"description":3723,"authors":3728,"heroImage":3724,"date":3729,"body":3730,"category":787,"tags":3731,"updatedDate":3733},[2980],"2023-10-12","20年以上前に新しいプログラミング言語を学び始めたとき、私たちは6枚のCD-ROMからインストールしたVisual Studio\n6のMSDNライブラリにアクセスしていました。ペンと紙でアルゴリズムを記録し、設計パターンの本を読み漁り、MSDNで正しい型を調べていましたが、こうした作業に時間がかかることが多々ありました。しかし、リモートコラボレーションや人工知能（AI）の時代が到来し、プログラミング言語の学び方は根本的に変わりました。今では[リモート開発環境](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/)をすばやく立ち上げて画面を共有し、グループでのプログラミングセッションを行えるようになりました。[GitLab\nDuoのコード提案](https://about.gitlab.com/ja-jp/gitlab-duo/)を使用すれば、AIというインテリジェントなパートナーにいつでも頼ることができます。コード提案機能は、ユーザーのプログラミングのスタイルと経験に基づいて学習します。この機能は、インプットとコンテキストさえあれば、最も効率的な提案を提供してくれるのです。\n\n\nこのチュートリアルでは、[入門編のブログ記事](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/)（英語）からさらに一歩踏み込み、シンプルなフィードリーダーアプリケーションの設計と作成に取り組みます。\n\n\n- 準備\n    - コード提案\n- Rustの学習の継続\n    - 「Hello, Reader!」アプリ\n    - プロジェクトの初期化\n    - RSSフィードURLの定義\n- モジュール\n    - main() 関数によるモジュール関数の呼び出し\n- クレート\n    - feed-rs：XMLフィードの解析\n- ランタイム設定：プログラム引数\n    - ユーザー入力のエラーハンドリング\n- 永続性とデータ保存\n\n- 最適化\n    - 非同期実行\n    - スレッドの生成\n    - 関数スコープ、スレッド、クロージャ\n- フィードのXMLの解析およびオブジェクト型への変換\n    - 汎用的なフィードデータ型のマッピング\n    - Option::unwrap()によるエラーハンドリング\n- ベンチマーク\n    - 逐次実行と並列実行のベンチマークの比較\n    - Rustのキャッシュを使用したCI/CD\n- 次のステップ\n    - 非同期学習の演習\n    - フィードバックの共有\n\n## 準備\n\nソースコードを参照する前に、[VS\nCode](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/#vs-code)と[Rustの開発環境](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/#development-environment-for-rust)をセットアップしてください。\n\n\n### コード提案\n\n実際に提案機能を検証する前に、まずはこの機能の使い方を理解しましょう。GitLab\nDuoのコード提案は、特定のキーボードショートカットを必要とせず、キーを入力するだけで使用できます。たとえば、コード提案を受け入れるには、`Tab`\nキーを押します。また、新しく作成したコードの方が、既存のコードをリファクタリングしたものよりもエラー発生率が低くなる点も覚えておきましょう。AIは非決定的であるため、一度削除したコード提案は再び同じ形で提示されない可能性があります。コード提案は現在ベータ版であり、GitLabは、同機能が生成するコンテンツの全体的な精度向上に取り組んでいます。\n\n\n**ヒント**：コード提案の最新リリースでは、複数行の指示文に対応しています。ニーズに合わせて指示文を調整することで、よりよい提案を得ることができます。\n\n\n```rust\n    // Create a function that iterates over the source array\n    // and fetches the data using HTTP from the RSS feed items.\n    // Store the results in a new hash map.\n    // Print the hash map to the terminal.\n```\n\n\nVS Code拡張機能のオーバーレイは、提案を提示する際に表示されます。提案された行を受け入れるには `Tab` キーを使用し、一単語だけ受け入れるには\n`Cmd + 右カーソル` キーを使用します。さらに、三点リーダーメニューからツールバーを常に表示するオプションを選択することも可能です。\n\n\n![VS CodeにおけるGitLab\nDuoの指示文とコード提案のオーバーレイ](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_code_suggestions_options_overlay_keep_toolbar.png){:\n.shadow}\n\n\n## Rustの学習の継続\n\nでは、引き続きRustについて学んでいきましょう。Rustは[コード提案でサポートされている言語](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/)のひとつです。[Rust\nby\nExample](https://doc.rust-lang.org/rust-by-example/)（英語）では、初心者に最適なチュートリアルが提供されており、公式の[Rust\nBook](https://doc.rust-lang.org/book/)（英語）を確認しながら進めると効果的です。どちらのリソースもこのブログの執筆の際に参考にしています。\n\n\n### 「Hello, Reader!」アプリ\n\nアプリケーションの作成やRustの学習には、さまざまなアプローチがあります。その中には、既存のRustライブラリ、いわゆる `Crates`\nを利用するものがあり、このブログ記事の後半でも使用します。たとえば、画像を処理して、その結果をファイルに書き込むコマンドラインアプリを作成することができます。また、昔ながらの迷路をクリアしたり、数独を解いたりするアプリケーションを作成するのも楽しいでしょうし、ゲーム開発を行うこともできます。たとえば、[Hands-on\nRust](https://hands-on-rust.com/)（英語）というガイドブックでは、ダンジョンクローラー（迷宮探検）ゲームを作りながら、Rustを体系的に学習できるコースを提供しています。筆者の同僚であるFatima\nSarah Khalidは、[AIを活用してC++でDragon\nRealmの制作](/blog/building-a-text-adventure-using-cplusplus-and-code-suggestions/)（英語）を始めたそうです。ぜひそちらもご覧ください。\n\n\nここで、実際の問題を解決するのに役立つ実用的なユースケースをひとつご紹介します。それは、異なるソースから重要な情報をRSSフィードに集約するというものです。RSSフィードには、セキュリティリリース、ブログ記事、およびソーシャルディスカッションフォーラム（Hacker\nNewsなど）の最新情報が含まれます。アップデートに含まれる特定のキーワードやバージョンを絞り込んで検索したいと考えることがよくあります。こうしたニーズを基に、アプリケーションの要件をリスト化できます。具体的には、次のような要件です。\n\n\n1. HTTPウェブサイト、REST API、RSSフィードなどの異なるソースからデータをフェッチ（取得）する（最初の段階ではRSSフィードを使用）。\n\n1. データを解析する。\n\n1. データをユーザーに提示する、またはディスクに書き込む。\n\n1. パフォーマンスを最適化する。\n\n\nこのブログ記事の学習ステップを完了すると、以下のサンプルアプリケーションの出力が得られます。\n\n\n![VS Codeのターミナルでのcargo\nrunの実行と、形成されたフィードエントリの出力](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_run_formatted_output_final.png)\n\n\nアプリケーションはモジュール化されている必要があり、また、将来的にデータ型やフィルター、アクションをトリガーするフックを追加できる基盤も整えておく必要があります。\n\n\n### プロジェクトの初期化\n\nリマインダー：`cargo init` をプロジェクトのルートディレクトリで実行すると、 `main ()`\nエントリポイントを含んだファイル構造が作成されます。これを踏まえ、次のステップでは、Rustのモジュールの作成と使用方法を学びます。\n\n\n`learn-rust-ai-app-reader` という名前のディレクトリを新規作成し、そのディレクトリに移動したら、`cargo init`\nを実行します。このコマンドは、暗黙的に `git init`\nを実行し、新しいGitリポジトリをローカルで初期化します。残りのステップでは、Gitリモートリポジトリのパスを設定していきます。たとえば、`https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader`\nのように設定します（ご自身のネームスペースに合わせてパスを置き換えてください）。[Gitリポジトリをプッシュ](https://about.gitlab.com/ja-jp/blog/mastering-the-basics-of-git-push-tag/)すると、[GitLabで新しいプロジェクトが自動的に作成](https://docs.gitlab.com/ee/user/project/#create-a-new-project-with-git-push)されます。\n\n\n```shell\n\nmkdir learn-rust-ai-app-reader\n\ncd learn-rust-ai-app-reader\n\n\ncargo init\n\n\ngit remote add origin\nhttps://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader.git\n\ngit push --set-upstream origin main\n\n```\n\n\n新しく作成されたディレクトリからVS Codeを開きます。`code` コマンドラインインターフェース（CLI）によって、macOS上で新しいVS\nCodeのウィンドウが起動します。\n\n\n```shell\n\ncode .\n\n```\n\n\n### RSSフィードURLの定義\n\n新しいHashMapを追加して、`src/main.rs` ファイル内の `main()`\n関数にRSSフィードのURLを保存します。複数行の指示コメントを入力することで、GitLab\nDuoのコード提案に対し、[`HashMap`](https://doc.rust-lang.org/stable/std/collections/struct.HashMap.html)\nオブジェクトを作成して、Hacker\nNewsやTechCrunchのデフォルト値で初期化するよう指示できます。注：提案に含まれるURLが正しいことを確認してください。\n\n\n```rust\n\nfn main() {##$_0A$##    // Define RSS feed URLs in the variable\nrss_feeds##$_0A$##    // Use a HashMap##$_0A$##    // Add Hacker News and\nTechCrunch##$_0A$##    // Ensure to use String as type##$_0A$####$_0A$##}\n\n```\n\n\nコードコメントでは以下の点を指示しています。\n\n\n1. 変数名 `rss_feeds`\n\n2. `HashMap` タイプ\n\n3. 3. 初期のseedキー/バリューペア\n\n4. String 型（`to_string ()` 呼び出しで確認可能）\n\n\n考えられるコードの例は次の通りです。\n\n\n```rust\n\nuse std::collections::HashMap;\n\n\nfn main() {##$_0A$##    // Define RSS feed URLs in the variable\nrss_feeds##$_0A$##    // Use a HashMap##$_0A$##    // Add Hacker News and\nTechCrunch##$_0A$##    // Ensure to use String as type##$_0A$##    let\nrss_feeds = HashMap::from([##$_0A$##        (\"Hacker News\".to_string(),\n\"https://news.ycombinator.com/rss\".to_string()),##$_0A$##       \n(\"TechCrunch\".to_string(),\n\"https://techcrunch.com/feed/\".to_string()),##$_0A$##   \n]);##$_0A$####$_0A$##}\n\n```\n\n\n![VS Codeにおける、コード提案を活用したHacker\nNewsとTechCrunchのRSSフィードURLの提案](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_main_array_rss_feed_urls_suggested.png)\n\n\nVS Codeで新しいターミナルを開き（cmd + shift + p で `terminal` を検索）、`cargo build`\nを実行して変更をビルドします。エラーメッセージが表示され、`use std::collections::HashMap;`\nのインポートを追加するよう指示されます。\n\n\n次のステップでは、RSSフィードのURLを使用して操作を行います。[以前のブログ記事](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/)（英語）では、コードを関数に分割する方法を解説しました。今回は、リーダーアプリケーションのコードをよりモジュール化して整理し、Rustのモジュールを使用します。\n\n\n## モジュール\n\n[モジュール](https://doc.rust-lang.org/rust-by-example/mod.html)は、\nコードの整理に役立ちます。また、関数をモジュールのスコープ内に隠し、main()スコープからのアクセスを制限することも可能です。リーダーアプリケーションでは、RSSフィードのコンテンツを取得し、XMLレスポンスを解析したいため、`main()`\nからは、`get_feeds()` 関数のみにアクセスできるようにし、それ以外の機能はモジュール内のみで使用できるように制限します。\n\n\n`src/` ディレクトリに `feed_reader.rs` という名前の新しいファイルを作成します。コード提案に、`feed_reader`\nという名前の公開モジュールと、String HashMapをインプットとして受け取る `get_feeds()`\nという公開関数を作成するよう指示します。重要：[Rustのモジュール構造](https://doc.rust-lang.org/book/ch07-02-defining-modules-to-control-scope-and-privacy.html)に従って、ファイル名とモジュール名を同じにする必要があります。\n\n\n![コード提案：関数と入力型を使った公開モジュールの作成](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_public_module_function_input.png){:\n.shadow}\n\n\nコード提案に入力変数名と型を指定すると、必要な `std::collections::HashMap`\nモジュールが自動的にインポートされます。ヒント：最適な結果を得られるよう、コメントを使って変数の型を調整してみましょう。また、Rustでは関数のパラメータをオブジェクト参照として渡すのがベストプラクティスとされています。以下に例を示します。\n\n\n```rust\n\n// Create public module feed_reader\n\n// Define get_feeds() function which takes rss_feeds as String HashMap\nreference as input\n\npub mod feed_reader {##$_0A$##    use\nstd::collections::HashMap;##$_0A$####$_0A$##    pub fn get_feeds(rss_feeds:\n&HashMap\u003CString, String>) {##$_0A$##        // Do something with the RSS\nfeeds##$_0A$##    }##$_0A$##}\n\n```\n\n\n![コード提案：`get_feeds()`\n関数と提案された入力変数を含む公開モジュール](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_public_module_function_input.png){:\n.shadow}\n\n\n関数内では、コード提案に以下の手順を指示します。\n\n\n1. `// Iterate over the RSS feed URLs` （RSSフィードURLを反復処理する）\n\n2. `// Fetch URL content` （URLコンテンツを取得する）\n\n3. `// Parse XML body` （XMLの本文を解析する）\n\n4. `// Print the result`  (結果を出力する)\n\n\n![コード提案：`get_feeds()`\n関数を含む公開モジュール、ステップ1：イテレート](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_01_iterate.png){:\n.shadow}\n\n\n![コード提案：`get_feeds()`\n関数を含む公開モジュール、ステップ2：URLコンテンツの取得](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_02_fetch_content.png){:\n.shadow}\n\n\n![コード提案：`get_feeds()`\n関数を含む公開モジュール、ステップ3：XML本文の解析](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_03_parse_body.png){:\n.shadow}\n\n\n![コード提案：`get_feeds()`\n関数を含む公開モジュール、ステップ4：結果の出力](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_04_print_result.png){:\n.shadow}\n\n\n次のコードが提案されます。\n\n\n```rust\n\n// Create public module feed_reader\n\n// Define get_feeds() function which takes rss_feeds as String HashMap\nreference as input\n\npub mod feed_reader {##$_0A$##    use\nstd::collections::HashMap;##$_0A$####$_0A$##    pub fn get_feeds(rss_feeds:\n&HashMap\u003CString, String>) {##$_0A$##        // Iterate over the RSS feed\nURLs##$_0A$##        for (name, url) in rss_feeds {##$_0A$##           \nprintln!(\"{}: {}\", name, url);##$_0A$####$_0A$##            // Fetch URL\ncontent##$_0A$##            let body =\nreqwest::blocking::get(url).unwrap().text().unwrap();##$_0A$####$_0A$##           \n// Parse XML body##$_0A$##            let parsed_body =\nroxmltree::Document::parse(&body).unwrap();##$_0A$####$_0A$##            //\nPrint the result##$_0A$##            println!(\"{:#?}\",\nparsed_body);##$_0A$##        }##$_0A$##    }##$_0A$##}\n\n```\n\n\nここで新しいキーワード\n[`unwrap()`](https://doc.rust-lang.org/rust-by-example/error/option_unwrap.html)が登場します。Rustは\n`null` 値をサポートしておらず、すべての値に対して [`Option`\n型](https://doc.rust-lang.org/rust-by-example/std/option.html)を使用します。たとえば、`Text`\nや `String` といった特定のラップされた型を使用することが確定している場合、`unwrap()`\nメソッドを呼び出してその値を取得できます。ただし、値が `None` の場合、`unwrap()` メソッドはパニックを起こします。\n\n\n**注意**：コード提案は、`// Fetch URL content` のコメント指示に従って、`reqwest::blocking::get`\n関数を参照します。[`reqwest`](https://docs.rs/reqwest/latest/reqwest/)というクレーと名は意図的なものであり、タイポではありません。非同期リクエストとブロッキングリクエストの処理に役立つ、優れた利便性と高レベルのHTTPクライアントの機能を提供します。\n\n\nXMLの本文の解析は難しく、異なる結果が得られることがあります。また、スキーマはRSSフィードURLごとに異なる可能性があります。まずは\n`get_feeds()` 関数を呼び出し、その後でコードの改善に取り組みましょう。\n\n\n### main() 関数によるモジュール関数の呼び出し\n\n\n現在、main() 関数は `get_feeds()`\n関数を認識していないため、まずそのモジュールをインポートする必要があります。他のプログラミング言語では `include` や `import`\nといったキーワードを目にすることがありますが、Rustのモジュールシステムは異なります。\n\n\nモジュールはパスディレクトリに整理されます。今回の例では、両方のソースファイルが同じディレクトリレベルに存在しています。`feed_reader.rs`\nはクレートとして解釈され、その中に `feed_reader` というモジュールがあり、そのモジュールが `get_feeds()`\n関数を定義しています。\n\n\n```\n\nsrc/\n  main.rs\n  feed_reader.rs\n```\n\n\n`feed_reader.rs` ファイルの `get_feeds()` 関数にアクセスするためには、まず `main.rs`\nのスコープに[モジュールパスを取り込み](https://doc.rust-lang.org/book/ch07-04-bringing-paths-into-scope-with-the-use-keyword.html)、その後フルパスで関数を呼び出します。\n\n\n```rust\n\nmod feed_reader;\n\n\nfn main() {\n\n    feed_reader::feed_reader::get_feeds(&rss_feeds);\n\n```\n\n\nあるいは、`use` キーワードを使って関数のフルパスをインポートし、その後短い関数名で呼び出すこともできます。\n\n\n```rust\n\nmod feed_reader;\n\nuse feed_reader::feed_reader::get_feeds;\n\n\nfn main() {\n\n    get_feeds(&rss_feeds);\n\n```\n\n\n**ヒント**：Rustのモジュールシステムを視覚的によりよく理解するために、[Rustモジュールシステムについてわかりやすく説明したブログ記事](https://www.sheshbabu.com/posts/rust-module-system/)（英語）をお読みください。\n\n\n```diff\n\n\nfn main() {\n    // ...\n\n    // Print feed_reader get_feeds() output\n    println!(\"{}\", feed_reader::get_feeds(&rss_feeds));\n```\n\n\n```rust\n\nuse std::collections::HashMap;\n\n\nmod feed_reader;\n\n// Alternative: Import full function path\n\n//use feed_reader::feed_reader::get_feeds;\n\n\nfn main() {##$_0A$##    // Define RSS feed URLs in the variable\nrss_feeds##$_0A$##    // Use a HashMap##$_0A$##    // Add Hacker News and\nTechCrunch##$_0A$##    // Ensure to use String as type##$_0A$##    let\nrss_feeds = HashMap::from([##$_0A$##        (\"Hacker News\".to_string(),\n\"https://news.ycombinator.com/rss\".to_string()),##$_0A$##       \n(\"TechCrunch\".to_string(),\n\"https://techcrunch.com/feed/\".to_string()),##$_0A$##   \n]);##$_0A$####$_0A$##    // Call get_feeds() from feed_reader\nmodule##$_0A$##   \nfeed_reader::feed_reader::get_feeds(&rss_feeds);##$_0A$##    // Alternative:\nImported full path, use short path here.##$_0A$##   \n//get_feeds(&rss_feeds);##$_0A$##}\n\n```\n\n\nターミナルで `cargo build` を再実行しコードをビルドします。\n\n\n```shell\n\ncargo build\n\n```\n\n\n以下は、HTTPリクエストやXML解析に関する一般的なコードを参照した際に発生する可能性のあるビルドエラーの例です。\n\n\n1. エラー： `could not find blocking in reqwest`\n\n解決策：`Config.toml` ファイルで `reqwest` クレートの `blocking` 機能を有効にします（`reqwest = {\nversion = \"0.11.20\", features = [\"blocking\"] }`）\n\n2. エラー：`failed to resolve: use of undeclared crate or module reqwest`\n\n解決策：`reqwest` クレートを追加します\n\n3. エラー：`failed to resolve: use of undeclared crate or module roxmltree`\n\n解決策：`roxmltree` クレートを追加します\n\n\n```shell\n\nvim Config.toml\n\n\nreqwest = { version = \"0.11.20\", features = [\"blocking\"] }\n\n```\n\n\n```shell\n\ncargo add reqwest\n\ncargo add roxmltree\n\n```\n\n\n**ヒント**：エラーメッセージの文字列を `Rust \u003Cerror message>`\nとしてブラウザで検索し、欠落しているクレートが利用可能であるかどうか確認しましょう。通常、検索結果に「crates.io」が表示され、そこから不足している依存関係を追加できます。\n\n\nビルドが成功したら、`cargo run` でコードを実行し、Hacker NewsのRSSフィードの出力を確認します。\n\n\n![VS Codeのターミナルでcargo runを実行して、Hacker\nNewsのXMLフィードを取得](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_fetch_rss_feed_output_hacker_news.png){:\n.shadow}\n\n\nXML本文を人間が読める形式に解析するにはどうすればいいでしょうか？次のセクションでは、既存の解決策とRustのクレートがどのように機能するかを説明します。\n\n\n## クレート\n\nRSSフィードは共通のプロトコルと仕様に基づいており、XMLを解析して下位のオブジェクト構造を理解するのは、例えば車輪のように、すでに存在しているものを再び深く掘り下げて再発明するかのようです。。こういったタスクに対するおすすめのアプローチは、過去に同じ問題に直面した人がいないか、また、その問題を解決するためのコードがすでに作られていないかを調べることです。\n\n\nRustでの再利用可能なライブラリコードは\n[`Crates`](https://doc.rust-lang.org/rust-by-example/crates.html)と呼ばれる単位で整理され、パッケージで提供されます。これらはcrates.ioのパッケージレジストリで利用可能です。これらの依存関係をプロジェクトに追加するには、`Config.toml`\nファイルの `[dependencies]` セクションを編集するか、`cargo add \u003Cname>` コマンドを使用します。\n\n\nリーダーアプリケーションでは、[feed-rs\nクレート](https://crates.io/crates/feed-rs)を使用したいため、新しいターミナルを開き、次のコマンドを実行してください。\n\n\n```shell\n\ncargo add feed-rs\n\n```\n\n\n![VS\nCodeのターミナル：クレートを追加し、Config.tomlで確認](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_rust_crate_add_feed-rs_explained.png)\n\n\n### feed-rs：XMLフィードの解析\n\n`src/feed_reader.rs` に移動し、XML本文を解析する部分に対して修正を加えます。コード提案は、`feed-rs` クレートの\n`parser::parse` 関数をどのように呼び出すか理解していますが、ひとつだけ特別な点があります。`feed-rs`\nは文字列をrawバイトとして入力し、自らエンコーディングを判断します。ただし、コメントに指示を追加することで、期待の結果を得ることは可能です。\n\n\n```rust\n            // Parse XML body with feed_rs parser, input in bytes\n            let parsed_body = feed_rs::parser::parse(body.as_bytes()).unwrap();\n```\n\n\n![コード提案：`get_feeds()`\n関数を含む公開モジュール、ステップ5：XMLパーサーをfeed-rsに変更](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_05_use_feed_rs_to_parse.png){:\n.shadow}\n\n\n`feed-rs` を使用するメリットは即座に可視化できるものでなく、`cargo run`\nで出力を確認するとその効果が明らかになります。すべてのキーと値がそれぞれのRustオブジェクト型にマッピングされ、さらに高度な処理に利用できるようになります。\n\n\n![VS Codeのターミナル、cargo runを実行してHacker\nNewsのXMLフィードを取得](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_fetch_rss_feed_output_hacker_news_feed_rs.png){:\n.shadow}\n\n\n## ランタイム設定：プログラム引数\n\nここまで、コンパイル時にバイナリに埋め込まれ、ハードコードされたRSSフィードの値を使用してプログラムを実行してきました。次のステップでは、実行時にRSSフィードを設定できるようにします。\n\n\nRustでは、標準miscライブラリに[プログラム引数](https://doc.rust-lang.org/rust-by-example/std_misc/arg.html)を処理するための機能が用意されています。[プログラム引数を解析](https://doc.rust-lang.org/rust-by-example/std_misc/arg/matching.html)することで、高度なプログラム引数パーサー（たとえば[clap](https://docs.rs/clap/latest/clap/)クレート）を使用したり、プログラムパラメータを構成ファイルやフォーマット（[TOML](https://toml.io/en/)やYAML）に移したりするよりも、簡単かつ効率的に学習を進めることができます。実際にいくつかの方法を試した結果、学習効果を最大限に高めるには、この方法が最適であると判断しましたが、唯一の方法ではありません。他の方法でRSSフィードの設定を試してみる価値もあります。\n\n\n単純な解決策としては、コマンドパラメータを `\"name,url\"` の文字列ペアとして渡してから、`,`\nで分割して名前とURLの値を抽出します。コード提案に、これらの操作を実行して新しい値で `rss_feeds`\nハッシュマップを拡張するようコメントで指示します。変数が変更可能でない可能性があるため、`let rss_feeds` を `let mut\nrss_feeds` に変更する必要がある点にご注意ください。\n\n\n`src/main.rs` に移動し、`rss_feeds` 変数の後に次のコードを `main()`\n関数の追加します。まずはコメントでプログラム引数を定義し、提案されたコードスニペットを確認します。\n\n\n```rust\n    // Program args, format \"name,url\"\n    // Split value by , into name, url and add to rss_feeds\n```\n\n\n![プログラム引数に関するコード提案、および rss_feeds\n変数のために名前とURLの値を分割するコード提案](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_program_args_boring_solution.png){:\n.shadow}\n\n\nコード全体の例は次のようになります。\n\n\n```rust\n\nfn main() {##$_0A$##    // Define RSS feed URLs in the variable\nrss_feeds##$_0A$##    // Use a HashMap##$_0A$##    // Add Hacker News and\nTechCrunch##$_0A$##    // Ensure to use String as type##$_0A$##    let mut\nrss_feeds = HashMap::from([##$_0A$##        (\"Hacker News\".to_string(),\n\"https://news.ycombinator.com/rss\".to_string()),##$_0A$##       \n(\"TechCrunch\".to_string(),\n\"https://techcrunch.com/feed/\".to_string()),##$_0A$##   \n]);##$_0A$####$_0A$##    // Program args, format \"name,url\"##$_0A$##    //\nSplit value by , into name, url and add to rss_feeds##$_0A$##    for arg in\nstd::env::args().skip(1) {##$_0A$##        let mut split =\narg.split(\",\");##$_0A$##        let name =\nsplit.next().unwrap();##$_0A$##        let url =\nsplit.next().unwrap();##$_0A$##        rss_feeds.insert(name.to_string(),\nurl.to_string());##$_0A$##    }##$_0A$####$_0A$##    // Call get_feeds()\nfrom feed_reader module##$_0A$##   \nfeed_reader::feed_reader::get_feeds(&rss_feeds);##$_0A$##    // Alternative:\nImported full path, use short path here.##$_0A$##   \n//get_feeds(&rss_feeds);##$_0A$##}\n\n```\n\n\nプログラムの引数を `cargo run` コマンドに直接渡すことができます。その際は引数の前に `--`をつけます。\nすべての引数をダブルクォートで囲み、名前の後にカンマを付けてRSSフィードのURLを引数として渡します。引数は空白で区切ります。\n\n\n```\n\ncargo build\n\n\ncargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\"\n\"CNCF,https://www.cncf.io/feed/\"\n\n```\n\n\n![VS\nCodeターミナル、GitLabブログのRSSフィード出力例](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_gitlab_blog_rss_feed_example.png){:\n.shadow}\n\n\n### ユーザー入力のエラーハンドリング\n\n提供されたユーザー入力がプログラムで想定される内容と異なる場合、[エラーを発生](https://doc.rust-lang.org/rust-by-example/error.html)させ、呼び出し元がプログラム引数を修正できるようにする必要があります。たとえば、不正なURL形式が渡された場合、それをランタイムエラーとして処理する必要があります。コード提案に対し、URLが無効な場合はエラーをスローするようコメントで指示します。\n\n\n```rust\n    // Ensure that URL contains a valid format, otherwise throw an error\n```\n\n\nひとつの解決策として、`url` 変数が `http://` または `https://` で始まっているかを確認し、そうでなければ [panic!\nマクロ](https://doc.rust-lang.org/rust-by-example/std/panic.html)を使ってエラーをスローする方法があります。コード全体の例は次のようになります。\n\n\n```rust\n    // Program args, format \"name,url\"\n    // Split value by , into name, url and add to rss_feeds\n    for arg in std::env::args().skip(1) {\n        let mut split = arg.split(\",\");\n        let name = split.next().unwrap();\n        let url = split.next().unwrap();\n\n        // Ensure that URL contains a valid format, otherwise throw an error\n        if !url.starts_with(\"http://\") && !url.starts_with(\"https://\") {\n            panic!(\"Invalid URL format: {}\", url);\n        }\n\n        rss_feeds.insert(name.to_string(), url.to_string());\n    }\n```\n\n\n任意のURL文字列から `:` を削除してエラーハンドリングをテストします。`RUST_BACKTRACE=full`\n環境変数を追加すると、`panic()` 呼び出しが発生した際に詳細な出力を取得できます。\n\n\n```\n\nRUST_BACKTRACE=full cargo run -- \"GitLab\nBlog,https://about.gitlab.com/atom.xml\" \"CNCF,https//www.cncf.io/feed/\"\n\n```\n\n\n![間違ったURL形式によるパニックエラーのバックトレースが表示されたVS\nCodeターミナル](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_url_format_error_panic_backtrace.png){:\n.shadow}\n\n\n## 永続性とデータ保存\n\nフィードデータを保存する単純な解決策は、解析されたデータを新しいファイルに書き出すことです。コード提案に、RSSフィードの名前と現在のISO日付を含むパターンでファイルを保存するよう指示します。\n\n\n```rust\n    // Parse XML body with feed_rs parser, input in bytes\n    let parsed_body = feed_rs::parser::parse(body.as_bytes()).unwrap();\n\n    // Print the result\n    println!(\"{:#?}\", parsed_body);\n\n    // Dump the parsed body to a file, as name-current-iso-date.xml\n    let now = chrono::offset::Local::now();\n    let filename = format!(\"{}-{}.xml\", name, now.format(\"%Y-%m-%d\"));\n    let mut file = std::fs::File::create(filename).unwrap();\n    file.write_all(body.as_bytes()).unwrap();\n```\n\n\nこの処理の一例として、[chronoクレート](https://crates.io/crates/chrono)を使用する方法があります。`cargo\nadd chrono` を実行して追加し、その後 `cargo build` と `cargo run` を再度実行します。\n\n\nファイルは `cargo run` が実行されたディレクトリに保存されます。バイナリを `target/debug/`\nディレクトリで直接実行している場合、すべてのファイルはそのディレクトリにダンプされます。\n\n\n![CNCFのRSSフィード内容を含むファイルがディスクに保存された状態のVS Code](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_cncf_rss_feed_saved_on_disk.png)\n\n\n## 最適化\n\n`rss_feeds`\n変数内のエントリは逐次実行されています。もし100件以上のURLがリストに設定されている場合、データの取得と処理にはかなりの時間がかかるでしょう。複数のフェッチリクエストを並行して実行できたらどうでしょうか？\n\n\n### 非同期実行\n\nRustでは、[スレッド](https://doc.rust-lang.org/book/ch16-01-threads.html)を使用した非同期実行が可能です。\n\n\n最も簡単な解決策は、各RSSフィードURLごとにスレッドを生成することです。最適化戦略については後のセクションで説明します。並行実行を開始する前に、\n`time` コマンドの前に`cargo run` をつけて、逐次実行コードの実行時間を測定しましょう。\n\n\n```\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\"\n\"CNCF,https://www.cncf.io/feed/\"\n\n\n0.21s user 0.08s system 10% cpu 2.898 total\n\n```\n\n\nなお、この演習では、手動のコーディング作業が多くなる場合があります。並列実行の影響をより効果的に比較するには、逐次実行の動作状態を新しいGitコミットとブランチ\n`sequential-exec` に保存してください。\n\n```shell\n\ngit commit -avm \"Sequential execution working\"\n\ngit checkout -b sequential-exec\n\ngit push -u origin sequential-exec\n\n\ngit checkout main\n\n```\n\n\n### スレッドの生成\n\n`src/feed_reader.rs` を開き、`get_feeds()`\n関数をリファクタリングします。まず、現在の状態をGitコミットで保存し、その後、関数のスコープ内の内容を削除します。次に、コード提案への指示と以下のコードコメントを入力します。\n\n\n1. `// Store threads in\nvector`：スレッドのハンドルをベクターに格納し、関数呼び出しの最後にスレッドが終了するまで待機できるようにします。\n\n2. `// Loop over rss_feeds and spawn\nthreads`：すべてのRSSフィードを反復処理するためのコードを作成し、新しいスレッドを作成します。\n\n\n`thread` モジュールと `time` モジュールを扱うには、次の `use` 文を追加します。\n\n\n```rust\n    use std::thread;\n    use std::time::Duration;\n```\n\n\nその後、forループを閉じるまでコードを書き進めます。コード提案は、自動的にスレッドハンドルを `threads`\nベクター変数に追加し、関数の最後でスレッドを結合（join）するよう提案します。\n\n\n```rust\n    pub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n\n        // Store threads in vector\n        let mut threads: Vec\u003Cthread::JoinHandle\u003C()>> = Vec::new();\n\n        // Loop over rss_feeds and spawn threads\n        for (name, url) in rss_feeds {\n            let thread_name = name.clone();\n            let thread_url = url.clone();\n            let thread = thread::spawn(move || {\n\n            });\n            threads.push(thread);\n        }\n\n        // Join threads\n        for thread in threads {\n            thread.join().unwrap();\n        }\n    }\n```\n\n\n次に、`thread` クレートを追加し、もう一度コードをビルドし実行します。\n\n\n```shell\n\ncargo add thread\n\n\ncargo build\n\n\ncargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\"\n\"CNCF,https://www.cncf.io/feed/\"\n\n```\n\n\nこの段階では、データの処理や出力は行われていません。次のステップに移る前に、ここで新たに導入されたキーワードについて解説します。\n\n\n### 関数スコープ、スレッド、クロージャ\n\n提案されるコードには新しいキーワードやデザインパターンが含まれることもあるため、これらについて理解しておくことが重要になります。スレッドハンドルは\n`thread::JoinHandle`\nという型で、スレッドが終わるのを待機するために使用します（[join()](https://doc.rust-lang.org/book/ch16-01-threads.html#waiting-for-all-threads-to-finish-using-join-handles)メソッドを使います）。\n\n\n`thread::spawn()`\nは新しいスレッドを生成し、このスレッド内では、関数オブジェクトを渡すことができます。この場合、[クロージャ](https://doc.rust-lang.org/book/ch13-01-closures.html)式が無名関数として渡されます。また、クロージャ入力は\n`||` 構文を使用して渡されますが、この際には[`move`\nクロージャ](https://doc.rust-lang.org/book/ch16-01-threads.html#using-move-closures-with-threads)が関数スコープの変数をスレッドスコープに移動します。これにより、どの変数を新しい関数やクロージャスコープに渡すかを手動で指定する必要がなくなります。\n\n\nただし、これには制限があります。`rss_feeds` は参照 `&` で、`get_feeds()`\n関数の呼び出し元からパラメータとして渡されています。この変数は関数スコープ内でのみ有効です。このエラーを引き起こすには、次のコードスニペットを使用します。\n\n\n```rust\n\npub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {##$_0A$####$_0A$##   \n// Store threads in vector##$_0A$##    let mut threads:\nVec\u003Cthread::JoinHandle\u003C()>> = Vec::new();##$_0A$####$_0A$##    // Loop over\nrss_feeds and spawn threads##$_0A$##    for (key, value) in rss_feeds\n{##$_0A$##        let thread = thread::spawn(move || {##$_0A$##           \nprintln!(\"{}\", key);##$_0A$##        });##$_0A$##    }##$_0A$##}\n\n```\n\n\n![VS Codeターミナル、参照とスレッドのmoveクロージャに関する変数スコープエラー](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_build_error_function_threads_variable_scopes.png){:\n.shadow}\n\n\n`key` 変数は関数スコープ内で作成されていますが、`rss_feeds`\n変数を参照しているため、スレッドスコープに移動することはできません。関数パラメータ `rss_feeds`\nのハッシュマップからアクセスされる値は、`clone()` を使ってローカルコピーを作成する必要があります。\n\n\n![VS\nCodeターミナル、cloneを使用したスレッドの生成](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_thread_spawn_clone.png){:\n.shadow}\n\n\n```rust\n\npub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n\n    // Store threads in vector\n    let mut threads: Vec\u003Cthread::JoinHandle\u003C()>> = Vec::new();\n\n    // Loop over rss_feeds and spawn threads\n    for (name, url) in rss_feeds {\n        let thread_name = name.clone();\n        let thread_url = url.clone();\n        let thread = thread::spawn(move || {\n            // Use thread_name and thread_url as values, see next chapter for instructions.\n```\n\n\n## フィードのXMLの解析およびオブジェクト型への変換\n\n次のステップは、スレッド内のクロージャでRSSフィードの解析手順を繰り返すことです。コード提案の指示とともに以下のコードコメントを追加します。\n\n\n1. `// Parse XML body with feed_rs parser, input in\nbytes`：コード提案に対し、RSSフィードのURLコンテンツを取得し、`feed_rs` クレートの関数で解析したいという要望を伝えます。\n\n2. `// Check feed_type attribute feed_rs::model::FeedType::RSS2 or Atom and\nprint its name`：`feed_type` 属性を\n[`feed_rs::model::FeedType`](https://docs.rs/feed-rs/latest/feed_rs/model/enum.FeedType.html)\nと照合してフィードの種類を抽出します。この場合、コード提案に対して、照合の対象とする正確なEnum値を指示する必要があります。\n\n\n![コード提案に特定のフィードタイプと照合するよう指示](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_feed_rs_type_condition.png){:\n.shadow}\n\n\n```rust\n            // Parse XML body with feed_rs parser, input in bytes\n            let body = reqwest::blocking::get(thread_url).unwrap().bytes().unwrap();\n            let feed = feed_rs::parser::parse(body.as_ref()).unwrap();\n\n            // Check feed_type attribute feed_rs::model::FeedType::RSS2 or Atom and print its name\n            if feed.feed_type == feed_rs::model::FeedType::RSS2 {\n                println!(\"{} is an RSS2 feed\", thread_name);\n            } else if feed.feed_type == feed_rs::model::FeedType::Atom {\n                println!(\"{} is an Atom feed\", thread_name);\n            }\n```\n\n\nプログラムをもう一度ビルドして実行し、出力を確認します。\n\n\n```\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\"\n\"CNCF,https://www.cncf.io/feed/\"\n\n\nCNCF is an RSS2 feed\n\nTechCrunch is an RSS2 feed\n\nGitLab Blog is an Atom feed\n\nHacker News is an RSS2 feed\n\n```\n\n\nフィードURLをブラウザで開くか、以前にダウンロードしたファイルを調べて、この出力を確認します。\n\n\nHacker News はRSS\n2.0をサポートしており、`channel(title,link,description,item(title,link,pubDate,comments))`\nの構造を持っています。TechCrunchとCNCFブログは同様の構造をしています。\n\n```xml\n\n\u003Crss version=\"2.0\">\u003Cchannel>\u003Ctitle>Hacker\nNews\u003C/title>\u003Clink>https://news.ycombinator.com/\u003C/link>\u003Cdescription>Links for\nthe intellectually curious, ranked by\nreaders.\u003C/description>\u003Citem>\u003Ctitle>Writing a debugger from scratch:\nBreakpoints\u003C/title>\u003Clink>https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-5/\u003C/link>\u003CpubDate>Wed,\n27 Sep 2023 06:31:25\n+0000\u003C/pubDate>\u003Ccomments>https://news.ycombinator.com/item?id=37670938\u003C/comments>\u003Cdescription>\u003C![CDATA[\u003Ca\nhref=\"https://news.ycombinator.com/item?id=37670938\">Comments\u003C/a>]]>\u003C/description>\u003C/item>\u003Citem>\n\n```\n\n\nGitLabブログには[Atom](https://datatracker.ietf.org/doc/html/rfc4287)フィード形式が使用されています。RSSに類似していますが異なる解析ロジックが必要です。\n\n```xml\n\n\u003C?xml version='1.0' encoding='utf-8' ?>\n\n\u003Cfeed xmlns='http://www.w3.org/2005/Atom'>\n\n\u003C!-- / Get release posts -->\n\n\u003C!-- / Get blog posts -->\n\n\u003Ctitle>GitLab\u003C/title>\n\n\u003Cid>https://about.gitlab.com/blog\u003C/id>\n\n\u003Clink href='https://about.gitlab.com/blog/' />\n\n\u003Cupdated>2023-09-26T00:00:00+00:00\u003C/updated>\n\n\u003Cauthor>\n\n\u003Cname>The GitLab Team\u003C/name>\n\n\u003C/author>\n\n\u003Centry>\n\n\u003Ctitle>Atlassian Server ending: Goodbye disjointed toolchain, hello\nDevSecOps platform\u003C/title>\n\n\u003Clink\nhref='https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/'\nrel='alternate' />\n\n\u003Cid>https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/\u003C/id>\n\n\u003Cpublished>2023-09-26T00:00:00+00:00\u003C/published>\n\n\u003Cupdated>2023-09-26T00:00:00+00:00\u003C/updated>\n\n\u003Cauthor>\n\n\u003Cname>Dave Steer, Justin Farris\u003C/name>\n\n\u003C/author>\n\n```\n\n\n### 汎用的なフィードデータ型のマッピング\n\n[`roxmltree::Document::parse`](https://docs.rs/roxmltree/latest/roxmltree/struct.Document.html)\nを使用する場合、XMLノードツリーとその特定のタグ名を理解する必要があります。幸い、[`feed_rs::model::Feed`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html)\nはRSSとAtomフィードの統合モデルを提供しているため、引き続き `feed_rs` クレートを使用して進めましょう。\n\n\n1. Atom：Feed->Feed、Entry->Entry\n\n2. RSS：Channel->Feed、Item->Entry\n\n\n上記のマッピングに加えて、必要な属性を抽出し、それらのデータ型をマッピングする必要があります。[feed_rs::modelのドキュメント](https://docs.rs/feed-rs/latest/feed_rs/model/index.html)を開き、構造体やそのフィールド、実装について理解しながら進めることをお勧めします。これは、`feed_rs`\nの実装に特有の型変換エラーやコンパイルエラーが発生するのを防ぐためです。\n\n\n[`Feed`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html) 構造体は\n`title` を提供しますが、その型は `Option\u003CText>`\nで、値が設定されているか、何もないかのいずれかです。[`Entry`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Entry.html)\n構造体は以下の情報を提供します。\n\n\n1. `title`：`Option\u003CText>`\n型で、[`Text`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html)\nには `content` フィールドが `String` 型として含まれています。\n\n2. `published`：`Option\u003CDateTime\u003CUtc>>`\n型で、[`DateTime`](https://docs.rs/chrono/latest/chrono/struct.DateTime.html) は\n[`format()`\nメソッド](https://docs.rs/chrono/latest/chrono/struct.DateTime.html#method.format)を持ちます。\n\n3. `summary`：`Option\u003CText>` \n型で、[`Text`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html)\nには `content` フィールドが `String` 型として含まれています。\n\n4. `links`：`Vec\u003CLink>`\n型で、[`Link`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Link.html)\n項目のベクターです。`href` 属性が生のURL文字列を提供します。\n\n\n1から4に従って、フィードエントリから必要なデータを抽出します。繰り返しますが、すべての `Option` 型には `unwrap()`\nを呼び出す必要があります。このため、コード提案に対してより直接的な指示が求められます。\n\n\n```rust\n                // https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html\n                // https://docs.rs/feed-rs/latest/feed_rs/model/struct.Entry.html\n                // Loop over all entries, and print\n                // title.unwrap().content\n                // published.unwrap().format\n                // summary.unwrap().content\n                // links href as joined string\n                for entry in feed.entries {\n                    println!(\"Title: {}\", entry.title.unwrap().content);\n                    println!(\"Published: {}\", entry.published.unwrap().format(\"%Y-%m-%d %H:%M:%S\"));\n                    println!(\"Summary: {}\", entry.summary.unwrap().content);\n                    println!(\"Links: {:?}\", entry.links.iter().map(|link| link.href.clone()).collect::\u003CVec\u003CString>>().join(\", \"));\n                    println!();\n                }\n```\n\n\n![特定の要件に基づいてフィードエントリの型を出力するためのコード提案](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_print_feed_entries_fields_with_rust_type_specifics.png){:\n.shadow}\n\n\n### Option::unwrap()によるエラーハンドリング\n\nプログラムを再ビルドして実行した後、複数行の指示を引き続き処理します。補足：`unwrap()` は空の値に遭遇すると `panic!`\nマクロを呼び出し、プログラムを強制終了させます。これは、フィードデータ内に `summary` のようなフィールドが設定されていない場合に発生します。\n\n\n```shell\n\nGitLab Blog is an Atom feed\n\nTitle: How the Colmena project uses GitLab to support citizen journalists\n\nPublished: 2023-09-27 00:00:00\n\nthread '\u003Cunnamed>' panicked at 'called `Option::unwrap()` on a `None`\nvalue', src/feed_reader.rs:40:59\n\n```\n\n\n解決策のひとつとして、[`std::Option::unwrap_or_else`](https://doc.rust-lang.org/std/option/enum.Option.html#method.unwrap_or_else)\nを使用し、デフォルト値として空の文字列を設定することが挙げられます。この構文には、空の `Text` 構造体のインスタンスを返すクロージャが必要です。\n\n\n問題を解決する上で、正しい初期化方法を見つけるために試行錯誤を重ねました。単に空の文字列を渡すだけではカスタム型ではうまく機能しませんでした。以下に、筆者が試したすべてのアプローチとリサーチの過程をまとめました。\n\n\n```rust\n\n// Problem: The `summary` attribute is not always initialized. unwrap() will\npanic! then.\n\n// Requires use mime; and use feed_rs::model::Text;\n\n/*\n\n// 1st attempt: Use unwrap() to extraxt Text from Option\u003CText> type.\n\nprintln!(\"Summary: {}\", entry.summary.unwrap().content);\n\n// 2nd attempt. Learned about unwrap_or_else, passing an empty string.\n\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| \"\").content);\n\n// 3rd attempt. summary is of the Text type, pass a new struct\ninstantiation.\n\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{}).content);\n\n// 4th attempt. Struct instantiation requires 3 field values.\n\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{\"\", \"\",\n\"\"}).content);\n\n// 5th attempt. Struct instantation with public fields requires key: value\nsyntax\n\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type:\n\"\", src: \"\", content: \"\"}).content);\n\n// 6th attempt. Reviewed expected Text types in\nhttps://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html and created\nMime and String objects\n\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type:\nmime::TEXT_PLAIN, src: String::new(), content: String::new()}).content);\n\n// 7th attempt: String and Option\u003CString> cannot be casted automagically.\nCompiler suggested using `Option::Some()`.\n\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type:\nmime::TEXT_PLAIN, src: Option::Some(), content: String::new()}).content);\n\n*/\n\n\n// xth attempt: Solution. Option::Some() requires a new String object.\n\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type:\nmime::TEXT_PLAIN, src: Option::Some(String::new()), content:\nString::new()}).content);\n\n```\n\n\nこのアプローチは、コードが複雑で読みにくく、さらにコード提案の支援がなかったため、手動でコーディングする必要があり、満足のいくものではありませんでした。一旦立ち止まり、アプローチを見直しました。`Option`\nが `none` の場合に`unwrap()`\nはエラーをスローするのであれば、そのエラーを処理する簡単な方法があるのではと考え、コード提案に新しいコメントで質問しました。\n\n\n```\n                // xth attempt: Solution. Option::Some() requires a new String object.\n                println!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: Option::Some(String::new()), content: String::new()}).content);\n\n                // Alternatively, use Option.is_none()\n```\n\n\n![コード提案によるOptions.is_noneを使った代替案](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_after_complex_unwrap_or_else_ask_for_alternative_option.png){:\n.shadow}\n\n\n結果として、読みやすさが向上し、`unwrap()`\nによる無駄なCPUサイクルが減りました。複雑な問題を解決することから単純な解決策を使用することまでの学習過程を大幅に短縮できました。まさにウィンウィンです。\n\n\n忘れないうちに、XMLデータをディスクに保存する指示を再度追加して、リーダーアプリを完成させましょう。\n\n\n```rust\n                // Dump the parsed body to a file, as name-current-iso-date.xml\n                let file_name = format!(\"{}-{}.xml\", thread_name, chrono::Local::now().format(\"%Y-%m-%d-%H-%M-%S\"));\n                let mut file = std::fs::File::create(file_name).unwrap();\n                file.write_all(body.as_ref()).unwrap();\n```\n\n\nプログラムをビルドして実行し、出力を確認します。\n\n\n```shell\n\ncargo build\n\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\"\n\"CNCF,https://www.cncf.io/feed/\"\n\n```\n\n\n![VS Codeターミナルでcargo\nrunを実行し、フォーマットされたフィードエントリの出力](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_run_formatted_output_final.png)\n\n\n## ベンチマーク\n\n\n### 逐次実行と並列実行のベンチマークの比較\n\nそれぞれ5つのサンプルを作成して、実行時間のベンチマークを比較します。\n\n\n1. 逐次実行\n\n2. 並列実行\n\n\n```shell\n\n# Sequential\n\ngit checkout sequential-exec\n\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\"\n\"CNCF,https://www.cncf.io/feed/\"\n\n\n0.21s user 0.08s system 10% cpu 2.898 total\n\n0.21s user 0.08s system 11% cpu 2.585 total\n\n0.21s user 0.09s system 10% cpu 2.946 total\n\n0.19s user 0.08s system 10% cpu 2.714 total\n\n0.20s user 0.10s system 10% cpu 2.808 total\n\n```\n\n\n```shell\n\n# Parallel\n\ngit checkout parallel-exec\n\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\"\n\"CNCF,https://www.cncf.io/feed/\"\n\n\n0.19s user 0.08s system 17% cpu 1.515 total\n\n0.18s user 0.08s system 16% cpu 1.561 total\n\n0.18s user 0.07s system 17% cpu 1.414 total\n\n0.19s user 0.08s system 18% cpu 1.447 total\n\n0.17s user 0.08s system 16% cpu 1.453 total\n\n```\n\n\n4つのRSSフィードスレッドを並列実行した場合、CPU使用率は増加しましたが、逐次実行に比べて全体の実行時間はほぼ半減しました。この点を踏まえて、Rustの学習を続け、コードと機能を最適化していきます。\n\n\nなお、ここではCargoを使ってデバッグビルドを実行しており、最適化されたリリースビルドはまだ実行していません。また、並列実行にはいくつか注意点があります。一部のHTTPエンドポイントはレート制限を設けており、並列処理がこの制限に引っかかりやすくなる可能性があります。\n\n\n複数のスレッドを並列実行するシステムも過負荷になる可能性があります。これは、カーネル内でのコンテキストスイッチ（スレッド間の切り替え）を通じて各スレッドにリソースを割り当てる必要があるためです。1つのスレッドが計算リソースを使用している間、他のスレッドは待機状態になります。スレッドが多すぎると、システム全体が遅くなり、処理がスピードアップするどころか逆に遅くなることもあります。解決策としては、呼び出し元がキューにタスクを追加し、定義された数のワーカースレッドが非同期実行のためにタスクを処理する[ワークキュー](https://docs.rs/work-queue/latest/work_queue/)などの設計パターンがあります。\n\n\nRustでは、スレッド間のデータ同期を行う[チャンネル](https://doc.rust-lang.org/rust-by-example/std_misc/channels.html)を利用することもできます。競合状態を防ぐために、セーフロックを提供する[ミューテックス](https://doc.rust-lang.org/std/sync/struct.Mutex.html)も利用可能です。\n\n\n### Rustのキャッシュを使用したCI/CD\n\n以下のCI/CD構成を `.gitlab-ci.yml` ファイルに追加します。この `run-latest` ジョブは `cargo run`\nをRSSフィードURLの例とともに呼び出し、実行時間を継続的に計測します。\n\n\n```\n\nstages:\n  - build\n  - test\n  - run\n\ndefault:\n  image: rust:latest\n  cache:\n    key: ${CI_COMMIT_REF_SLUG}\n    paths:\n      - .cargo/bin\n      - .cargo/registry/index\n      - .cargo/registry/cache\n      - target/debug/deps\n      - target/debug/build\n    policy: pull-push\n\n# Cargo data needs to be in the project directory for being cached.\n\nvariables:\n  CARGO_HOME: ${CI_PROJECT_DIR}/.cargo\n\nbuild-latest:\n  stage: build\n  script:\n    - cargo build --verbose\n\ntest-latest:\n  stage: build\n  script:\n    - cargo test --verbose\n\nrun-latest:\n  stage: run\n  script:\n    - time cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\n\n![Rust用のGitLab CI/CDパイプライン、cargo\nrunの出力](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/gitlab_cicd_pipeline_rust_cargo_run_output.png){:\n.shadow}\n\n\n## 次のステップ\n\nこのブログ記事の執筆は、筆者自身が高度なRustプログラミング技術を学びつつ、コード提案を使って最適な学習過程を見出すという点で難しいものでした。コード提案は、単なる定型的なコードだけでなく、ローカルコンテキストを理解し、記述されたコードが多いほどアルゴリズムの目的や範囲をよりよく把握した迅速なコード生成にも大いに役立ちます。このブログ記事を読むことで、全てではないにしろ、いくつかの課題や解決策についてご理解いただけたかと思います。\n\n\nRSSフィードの解析は、外部HTTPリクエストや並列最適化を伴うデータ構造が関わるため、ハードルが高めです。経験豊富なRustユーザーであれば、`なぜstd::rssクレートを使わなかったのか？`\nと疑問に思うかもしれません。その理由は、std::rssは高度な非同期実行に最適化されており、このブログ記事でご説明したさまざまなRustの機能を示したり説明したりすることができないためです。ぜひ、非同期の演習として、[`rss`\nクレート](https://docs.rs/rss/latest/rss/)を使ってコードを書き直してみてください。\n\n\n### 非同期学習のエクササイズ\n\nこのブログ記事で学んだ内容は、永続的なデータ保存やデータ表示に関する理解を今後も深めていく上で基礎となります。引き続きRustを学びながら、リーダーアプリを最適化していくためのアイデアをいくつかご紹介します。\n\n\n1. データ保存：sqliteなどのデータベースを使用し、RSSフィードの更新履歴を追跡する。\n\n2. 通知：子プロセスを生成して、Telegramなどに通知を送る機能を追加する。\n\n3. 機能：リーダータイプを拡張して、REST APIをサポートする。\n\n4. 構成：RSSフィードやAPIなどの構成ファイルのサポートを追加する。\n\n5. 効率性：フィルタリングやサブスクライブしたタグのサポートを追加する。\n\n6.\nデプロイ：Webサーバーを使用して、Prometheusメトリクスを収集して[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)にデプロイする。\n\n\n今後のブログ記事では、これらのアイデアのいくつかを取り上げ、その実装方法について説明します。既存のRSSフィードの実装を詳しく調べ、どのように既存のコードをリファクタリングしてRustのライブラリ（`crates`）を活用できるか学びましょう。\n\n\n### フィードバックの共有\n\n[GitLab\nDuo](https://about.gitlab.com/ja-jp/gitlab-duo/)のコード提案をご使用になった方は、ぜひ[ご意見をフィードバックイシューにお寄せください](https://gitlab.com/gitlab-org/gitlab/-/issues/405152)。\n\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) \u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*\n",[702,3732,676,677,721],"careers","2025-01-24",{"slug":3735,"featured":6,"template":681},"learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions","content:ja-jp:blog:learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions.yml","Learn Advanced Rust Programming With A Little Help From Ai Code Suggestions","ja-jp/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions.yml","ja-jp/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions",{"_path":3741,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3742,"content":3748,"config":3753,"_id":3755,"_type":16,"title":3756,"_source":17,"_file":3757,"_stem":3758,"_extension":20},"/ja-jp/blog/gitlab-flow-duo",{"title":3743,"description":3744,"ogTitle":3743,"ogDescription":3744,"noIndex":6,"ogImage":3745,"ogUrl":3746,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3746,"schema":3747},"GitLab Flow (フロー) と GitLab Duo  (デュオ) を併用してワークフローを強化する","GitLab Flow に AI 搭載の GitLab Duo の能力を合わせ、DevSecOps ワークフローの効率をアップする方法をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png","https://about.gitlab.com/blog/gitlab-flow-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Flow (フロー) と GitLab Duo  (デュオ) を併用してワークフローを強化する\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2023-07-27\",\n      }",{"title":3743,"description":3744,"authors":3749,"heroImage":3745,"date":3750,"body":3751,"category":787,"tags":3752,"updatedDate":2941},[783],"2023-07-27","DevSecOps を始めるには、綿密に検討されたワークフローが必要ですが、時としてそれは厳しい挑戦のように感じられます。しかし、過度に心配する必要はありません。GitLab Flow と GitLab Duo の 2 つがワークフロー設計をサポートしてくれるからです。GitLab Flow は、DevSecOps プロセスを支障なく適用するのを支援するもので、手順がすでに規定されたアプローチです。GitLab Duo は、GitLab DevSecOps プラットフォーム内で提供される[パワフルな一連のAI 機能](https://about.gitlab.com/blog/supercharge-productivity-with-gitlab-duo/)で、 組織におけるコード開発、運用の改善、ソフトウェアのセキュリティ強化をより効率的に行う手助けとなります。GitLab Flow と GitLab Duo を併用すると、組織ではエンドツーエンドのワークフロー効率を顕著に改善できます。それにより、生産性、デプロイの頻度、コード品質、総合的なセキュリティ、本番環境の耐久性と可用性に、さらなる向上が期待されます。この記事では、企業でうまくDevSecOps を運用するため、GitLab Flow と GitLab Duo の組み合わせがどのように役立つか、深く掘り下げていきます。\n\n> GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を発見しましょう！ [【今すぐ視聴する】](https://about.gitlab.com/ja-jp/seventeen/)\n\n## GitLab Flow とは\nGitLab Flow は、手順が規定されている、アプリケーションの開発ライフサイクルのためのエンドツーエンドのワークフローです。GitLab Flow はユーザーインタフェースとデータモデルをそれぞれ 1 つずつ備えている、AI 搭載の DevSecOps プラットフォーム、GitLab を使用します。GitLab Flow には、顧客からのフィードバックや、自社使用から得られた教訓など、ベストプラクティスや経験から学んだことが組み込まれています。さらに、GitLab Flow は[DevSecOps ライフサイクルの全段階](https://about.gitlab.com/stages-devops-lifecycle/)にまたがるもので、ある特定のアップデートのための内側のフィードバックループと、開発ライフサイクルのみならずアプリケーション全体を改善させていく外側のフィードバックループで構成される、効率的なワークフローです。\n\n![The GitLab Flow inner and outer loops](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-feedback-loops.png)\n\u003Ccenter>GitLab Flowの内側と外側のフィードバックループ\u003C/center>\u003Cp>\u003C/p>\n\nGitLab Flow には多くの段階がありますが、ご存知のようにソフトウェア開発にはコードを書くだけでは終わらないたくさんの作業があります。以下で、GitLab Flow の各ステップと、GitLab Duo の役割について詳しく説明します。\n\n### GitLab Flowでのプランニング\n\nGitLab Flow の第一段階はプランニングです。プランニングは、GitLab Flow の外側のフィードバックループに配置されています。プランニング段階には、イシュー、マージリクエスト (MR)、エピック、マイルストーン、イテレーション、リリース、リリースエビデンスなど、さまざまなものが含まれます。これから、GitLab Flow でのこれらの各種要素の役割と、GitLab Duo がどのように役立つかについて説明します。\n\n![Planning - first portion of GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-planning-portion.png)\n\u003Ccenter>プランニング – GitLab Flow の第 1 部\u003C/center>\u003Cp>\u003C/p>\n\n#### イシュー\nイシューは、コードの問題や新機能を定義するもので、かつチームメンバーが協力し合える場です。イシューが作成されたら、タイトルを追加し、GitLab Duoの「**イシュー説明文の生成**」機能を用いると、説明欄へ自動で記入してくれるので、時間と労力が節約できます。1つのイシューについてのコメントスレッドには数多くの関係者が参加できます。「**イシューコメントのサマリー**」は GitLab Duoの AI機能のひとつで、あるイシューに関する何百ものコメントを簡潔なひとつのパラグラフに要約できるので、関係者は迅速に会話の内容を把握でき、議論に参加し、生産的な活動にすぐに貢献できます。\n\nイシューは、イシューボードで整理・視覚化できます。イシューボードはソフトウェアのプロジェクト管理ツールで、カンバンボードやスクラムボードとして利用できます。こういったボード類は、チームが機能や製品リリースのワークフローを計画、整理、視覚化するのに便利です。ボードのカテゴリは異なるものとして作成でき、イシューは簡単にドラッグアンドドロップで 1 つのリストから別のリストに移動させることができます。\n\n#### マージリクエスト\nマージリクエスト (MR) とは、解決策が開発される場を意味します。リリースを構成する要素として、イシューやマージリクエストは、DevOps やプラットフォームエンジニア、システム管理者やデータベース管理者、セキュリティエンジニア、そして開発者など、関係者により行われるアプリケーションの変更を、監査可能で追跡できる仕組みとして提供します。また、イシューやマージリクエストはリリースプランニングのプロセスに対する重要なインプットでもあります。\n\nマージリクエストは個別に作成することも、イシュー上で作成することも可能です。イシュー上でマージリクエストを作成した場合には、作成したマージリクエストが自動的にそのイシューに関連付けられるため、マージリクエストがマージされると、関連付けられているイシューも自動的にクローズされます。マージリクエストは手動でイシューに関連付けることもできます。\n\n![Merged merge request will close issue](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/mr-with-its-issue.png)\n\u003Ccenter>マージされたマージリクエストによりイシューがクローズされる\u003C/center>\u003Cp>\u003C/p>\n\nイシューと同様、マージリクエストには多くの関係者がアップデートを行なうフィーチャーのロングリストを含められます。GitLab Duo の「**マージリクエスト変更の要約**」機能を使うと、マージリクエストに含まれている更新内容のすべてを認識・理解する必要がある共同作業者は、変更点を素早く把握できます。\n\n同じテーマを持つイシューはエピック内でグループ化でき、取り組むべき作業を整理できます。エピックには子イシューやサブエピックが設定でき、組織全体のエピックにリンクすることも可能です。イテレーションを使用すると作業のスプリントの追跡ができ、手動でスケジュール設定したり、イテレーションの反復を使って自動でスケジュール設定し、プランニングのワークフローを効率化したりできます。さらに、イテレーションにはバーンダウンチャートとバーンアップチャートがあります。バーンダウンチャートを使用するとプロジェクトの全スコープに対する進捗状況の全体を追跡できます。バーンアップチャートはイテレーションの期間内に追加した、または完了したイシューの日次合計数と重み付けを追跡します。\n\n#### マイルストーン\nチームでマイルストーンを使えば、イシューやマージリクエストに任意の開始日や完了期限を設定し、関連のある 1 つのグループとして整理できます。マイルストーンは通常リリースの追跡に使用しますが、プロジェクト単位またはグループ単位で、イシューやマージリクエストを追跡することもできます。イテレーションと同様、マイルストーンでもバーンダウンチャートとバーンアップチャートが利用でき、進捗状況が可視化されます。\n\nマイルストーンはリリースに関連付けられます。リリースの自動作成からはリリースエビデンスを含む、多くのアーティファクトが生成されます。リリースエビデンスとはリリースに関連付けられている、自動収集されたデータのスナップショットです。テストアーティファクトやリンクされたマイルストーンに加えて、ジョブのアーティファクトもオプションとしてリリースエビデンスに含められるので、外部監査などの内部プロセスが容易になります。\n\nエピック、マイルストーン、そしてイテレーションは、「ロードマップ」ページで可視化できます。このページを使うと、リリースの進捗状況が追跡でき、リリースプロセスが効率化できます。\n\nプランニングに進むと、問題の解決や新機能に向けた作業が開始できます。これはマージリクエストで作業していきます。では、GitLab Flow でそのプロセスがどのように行われるのか、もう少し詳しく見てみましょう。 \n\n> [GitLab FlowとGitLab Duoを試してみる](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fblog%2F)\n\n### マージリクエストとコードのプッシュ\n\n![Merge requests and pushing code - second portion of GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-mr-pushing-code-portion.png)\n\u003Ccenter>マージリクエストとコードのプッシュ – GitLab Flow の第 2 部\u003C/center>\u003Cp>\u003C/p>\n\nGitLab Flow の第 2 部は、マージリクエスト (MR) とコードのプッシュに関連したものです。前述のように、マージリクエストとは組織全体から参加する関係者の共同作業で、解決策が生み出される場です。この共同作業は分散された場所から、非同期で行うことも可能です。参加者は、タグ付け、インラインでの提案、インラインコメント、マージリクエストのコメント、レビュースレッド、レビューリクエストなど、コラボレーション機能を活用でき、コード品質、可用性、信頼性とパフォーマンスの改善につながります。マージリクエストを作成するとすぐ、GitLab Flow の内側フィードバックループがスタートします。ここでは、コードと修正点のプッシュ、テストとスキャンの実行が行われ、アップデートのレビューなど共同作業が発生します。\n\n#### パイプライン\nアップデートは、マージリクエストを通してフィーチャーブランチに適用されます。パイプラインが定義されていれば、自動的に実行されます。パイプラインには複数のステージやジョブが設定でき、ビルドやテストを行った後、アプリケーションやマイクロサービスをレビュー環境にデプロイします。そのレビュー環境では、アップデートはメインブランチにマージする前に動的に検証できます。この自動化は、アプリケーションのアップデートとレビュープロセスを効率良く行う手助けになります。\n\nさらに、DevSecOps チームがマージリクエストを通じてアプリケーションのアップデートをする際は、さまざまなAI 搭載機能が活用できます。チームメンバーがコードを書いて更新するとき、GitLab Duo の「**コードの提案**」が次に書くべきコードを推奨してくれます。開発者はその提案を受け入れるか、無視するか選択できます。「コード提案」は、エラーを減らして開発者がより速くコードを書けるようにすることでプログラミング体験を向上させ、コード品質が改善します。「コード提案」はまた、開発者の生産性を高めるので、イテレーションやロールアウトの高速化にもつながります。\n\n組織内で異なる関係者がアプリケーションの開発やレビューに参加する場合、ドキュメントが不十分だったり、複雑で難解なコード、あまり馴染みのないプログラミング言語で書かれたコードなどに出くわすことがあります。GitLab Duo の「**コードの解説**」機能は、コードを自然言語で説明してくれるので、誰もが理解でき、そのスピードを高められます。\n\nさらに、フィーチャーブランチにアップデートがコミットされると、GitLab Duo の「**推奨レビュアー**」機能がマージリクエスト内の変更点とコントリビューションカレンダーグラフを使い、マージリクエストのサイドバー内のドロップダウンにプロジェクトに最適なレビュアーを提案してくれます。このリストにはアプリケーションのある特定の部分に詳しいユーザーが数人含まれ、そのアップデートのレビューの適任者が示されます。レビュー適任者をさがして特定する必要がありませんので、開発者の時間が節約でき、レビュープロセスを効率化し、遅延やレビューの品質低下を防ぎます。\n\n開発者がコードに変更を加える場合、その具体的な変更点についてマージリクエストにコメントを書くことはあまりありません。GitLab Duo の「**マージリクエスト変更の要約**」機能を使うと、マージリクエストで変更を行ったコード作成者は、AI を使用して自然言語のコメントを生成することができます。このコメントは、コードへの更新内容を要約するものです。これによりレビュアーは変更内容をよりよく理解でき、レビュープロセス全体の効率化につながります。\n\nレビュアーがマージリクエストでコード更新をレビューすると、レビューブロックが作成されます。このブロックには数多くのソースファイルにまたがる多数のコメントが含まれ、非常に長いので目を通すのが大変です。ここで、コード作成者がレビュー内容をしっかり理解できるように、GitLab Duo の「**マージリクエストレビューの要約**」機能を使うと、レビュアーのフィードバックが自然言語で生成されます。これによりコード作成者とレビュアーの間の引き継ぎがよりスムーズになり、レビュープロセスが効率化されます。\n\nさらに、マージリクエストに開発者が新しいコードを追加する際は、GitLab Duo の「**マージリクエストのテスト生成**」機能を活用すれば、AI を使って新しいコード用のユニットテストを生成できます。そのため開発者の生産性は高まり、テストカバレッジが向上し、開発ライフサイクル内でのバグ検出が前倒しできます。\n\nパイプラインはブランチの更新に対して実行されます。さらに、自動テストやスキャンをそこに組み込むことができます。それはセキュリティをシフトレフトすることにつながっていきます。\n\n### セキュリティのシフトレフト\n\n![Shifting security left - third portion of GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-shift-sec-left-portion.png)\n\u003Ccenter>セキュリティをシフトレフトする –  GitLab Flow の第 3 部\u003C/center>\u003Cp>\u003C/p>\n\nGitLab Flow の第 3 部は、セキュリティのシフトレフトです。これは GitLab Flow の内側フィードバックループの一部です。\n\nDevOps やプラットフォームエンジニア、システム管理者やデータベース管理者、開発者、マージリクエストで共同作業している関係者の中には、セキュリティやコンプライアンスを危惧している人もいるかもしれません。そういった場合に、自動化テストやセキュリティスキャンが役立ちます。スキャンはすぐ利用可能なテンプレートを使って簡単にパイプラインに埋め込むことができ、マージリクエストのパイプラインから自動的に実行できます。GitLab では、幅広い組み込みのセキュリティスキャナとアナライザが利用できます。これらはGitLab Flow から利用できます。さらに、DevSecOps プラットフォームにはサードパーティのスキャナやカスタムスキャナも取り込めます。\n\nソフトウェア開発プロセスで不具合検出をできる限り早い段階で行ない、早期解決する目的で、GitLab Flow はパイプライン内でセキュリティをシフトレフトしました。開発サイクルの早い段階で脆弱性を修正する方が、アプリケーションが本番環境に入ってからの修正より、はるかに簡単でコストもあまりかかりません。本番環境での修正では、予定外の停止によりユーザーや収益に影響が及ぶ恐れもあります。\n\nGitLab の組み込みのセキュリティスキャナおよびアナライザには、ユニットテスト、[Infrastructure-as-Code (IaC)](https://about.gitlab.com/ja-jp/blog/using-ansible-and-gitlab-as-infrastructure-for-code/) スキャン、静的アプリケーションセキュリティテスト (SAST) スキャナ、依存関係スキャナ、シークレット検出、コンテナスキャン、API セキュリティ、Web API ファズテスト、カバレッジガイド式ファズテストが含まれています。これに加えて、GitLab ではさまざまなセキュリティダッシュボードやレポートが利用できますので、脆弱性を管理・可視化できます。これには、依存関係リスト、セキュリティダッシュボード、脆弱性レポート、脆弱性ページなどが含まれます。\n\n開発者およびセキュリティエンジニアの脆弱性への理解を深め、脆弱性への対処をより効率的に行うため、GitLab Duo の「**脆弱性の説明**」機能からは、ある特定の脆弱性についての説明が得られます。脆弱性がどのように悪用されうるのかが説明されるだけでなく、それをどう修正したらよいのか提案もしてくれます。この AI 搭載機能は、本番環境でのサイバー攻撃で悪用される可能性のある脆弱性を防ぐため、アプリケーションのセキュリティを強化するプロセスの最適化を助長します。\n\nSAST スキャナのほかに、GitLab では動的アプリケーションセキュリティテスト (DAST) スキャナも提供しています。これには実行中のアプリケーションが必要です。このスキャナを活用すると、GitLab では DAST スキャン用に自動的に DAST 環境をプロビジョニングし、DASTテスト後はすべてのリソースを完全にクリーンアップしてくれます。これに加え、実行中のコンテナについては、GitLab では操作用のコンテナスキャンも使えます。このスキャンは、セキュリティの脆弱性をチェックするため、クラスタ内のコンテナイメージをスキャンします。\n\n上記のスキャンは、マージリクエストのパイプライン内で自動実行できますが、場合によっては、スキャン実行ポリシーやスキャン結果ポリシーを使い、実行をスケジュール化することも可能です。こういったポリシーは、GitLab UI または YAML ファイルで定義可能で、別個のプロジェクト内で構成します。これにより再利用性、メンテナンスと管理の責任が分離できます。スキャン実行ポリシーでは、指定されたスケジュールまたはプロジェクトパイプラインと一緒にセキュリティスキャンを実行する必要があり、スキャン結果ポリシーはスキャン結果に基づいて対処します。セキュリティエンジニアや各種チームはこれらのポリシーを定義して、組織全体のセキュリティプロセスを強化できます。GitLab Flow はこういったステップもカバーしていますので、これらのポリシーを活用することができます。\n\n組織内でセキュリティおよびコンプライアンスを強化する際は、コンプライアンスラベルやパイプラインを使用します。コンプライアンスラベルおよびパイプラインは、プロジェクト自体のパイプラインを実行する前に必須にすることも可能です。このアプローチでは、組織内のすべてのチームが確実に組織内のセキュリティとコンプライアンス基準に準拠していることが確認できます。さらに、開発中のアプリケーションをサイバー攻撃から守り、政府のコンプライアンス標準に準拠し、常に監査に備えられます。GitLab Flow で可能になる、これらすべてのセキュリティ指針の主な目標は、アプリケーションが本番環境に出ていった後ではなく、開発サイクルの早い段階で脆弱性を修正することにあります。本番環境で脆弱性の修復を行うことは、評判や収益面から非常に高価になるためです。\n\n脆弱性はGitLab Flow の内側フィードバックループでそのリスクが軽減できます。フィーチャーブランチでアプリケーションにさらなるアップデートを適用したら、関係者はアップデートを再度レビューして、アップデートの適用を確認し、誤って逆戻りするようなアップデートが導入されないようにする必要があります。\n\n### 継続的なレビュー\n\n![Reviews - fourth portion of GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-reviewing-features-portion.png)\n\u003Ccenter>レビュー –  GitLab Flow の第 4 部\u003C/center>\u003Cp>\u003C/p>\n\nGitLab Flow の第 4 部はレビュー機能で、ここでアプリケーションの継続的なレビューを規定します。フィーチャーのレビューには、レビュー環境を立ち上げる機能が含まれます。ここでは、開発途中のアプリケーション (フィーチャーブランチ) がデプロイされるため、関係者はリアルタイムでレビューし、フィードバックを提供できます。開発途中のアプリケーションは、メインブランチにマージできるようになるまで継続的に調整を入れます。GitLab Flow では、マージリクエストがメインブランチにマージされる時点で、すべてのプロビジョニングされたレビュー環境リソースをクリーンアップすることも規定しています。\n\nこの反復的な自動化されたレビュープロセスは、GitLab Flow の内側フィードバックループの一部とされています。上述したとおり、内側フィードバックループ内では、「ソースコードの説明」、「推奨レビュアー」、「マージリクエスト変更の要約」、および「マージリクエストレビューの要約」などのGitLab Duo 機能はGitLab Flow によって規定されており、コード作成者とレビュアーの間の引き継ぎをよりスムーズに行ない、レビュープロセス全体を効率化することができます。\n\nGitLab Flow の内側フィードバックループは、すべてのレビュー項目が解決され、マージリクエストが承認されてメインブランチにマージされると終了します。これがトリガーとなって、アプリケーションが本番環境にデプロイされます。\n\n### アプリケーションとインフラストラクチャのデプロイ\n\n![Deploying - fifth portion of GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-deploy-apps-portion.png)\n\u003Ccenter>デプロイ – GitLab Flow の第 5 部\u003C/center>\u003Cp>\u003C/p>\n\n組織のニーズに応じて、継続的デリバリーまたは継続的デプロイをGitLab Flow で規定します。継続的デリバリーはコードの頻繁なリリースで、その都度 (本番環境への) デプロイを手動でトリガーします。継続的デプロイは人間が関わることなく行われる、コードの (本番環境への) 自動リリースを意味します。では、継続的デリバリーを最初に見てみましょう。\n\n継続的デリバリーでソフトウェアをリリースする際は、いくつかのデプロイオプションがあります。フリーズウィンドウ（作業を一時停止する期間）を設定し、カナリアロールアウト、ブルー・グリーンロールアウト、タイムドロールアウト、インクリメンタルロールアウトなどの、高度なデプロイ技術が利用できます。インクリメンタルロールアウトは本番環境でのシステムダウンのリスクが低減できるため、よりよいユーザーエクスペリエンスと顧客満足度が得られます。各種の高度なデプロイ技術を用いると、開発とデリバリーの効率が改善できるため、リリースプロセスが効率化されます。\n\n継続的なデプロイでソフトウェアをリリースする際は、変更点やアップデートはすべて直接、本番環境に反映されます。フィーチャーフラグのような段階的なデリバリーアプローチを採用すると、特定のフィーチャーの提供をローンチから分離できるため、リスクを低減し、本番ユーザーに利用してもらえる機能性を管理できます。フィーチャーフラグは多くのプログラミング言語をサポートしているため、開発者は実験をしたり、管理環境下でのテストを可能にします。また、フィーチャーフラグを使うと、ある特定のユーザーだけにフィーチャーをロールアウトすることも可能になります。\n\nGitLab はこうしたデプロイアプローチのすべてをサポートしていますが、GitLab Flow では、組織や特定のプロジェクトのニーズに特化したアプローチの採用が可能です。\n\n### アプリケーションの監視と DevSecOps のプロセス\n\nアプリケーションを本番環境にデプロイしたら、安定性、パフォーマンス、可用性を保証するために継続的に監視する必要があります。また、DevSecOps プロセスが実行されると、それらが測定され、パフォーマンスと効率性を改善する機会が得られます。GitLab には監視機能があり、GitLab Flow でそれを活用できます。\n\n実行中のコンテナに対しては、GitLab はオペレーショナルコンテナスキャン (OCS) を行ないます。OCS は、クラスタ内のコンテナイメージをスキャンすることにより、セキュリティ脆弱性をチェックします。こういったスキャンは、実行するタイミングをスケジューリングすることで自動化でき、また、検出された脆弱性をセキュリティダッシュボードに自動的に表示します。OCS はクラスタアプリケーションをセキュアに保ち、個人データの流出や予期せぬシステム停止につながるサイバー攻撃を未然に防ぎます。\n\nエラーの追跡を行なえば、開発者は、開発しているアプリケーションで発生したエラーを検知したり、表示ができます。アプリケーション内で生成されたエラーはすべて、GitLab の「エラートラッキングリスト」に表示されます。エラートラッキングは、予期せぬアプリケーションの状態を迅速に見つけ出し、解決するので、アプリケーションの可用性とパフォーマンスをよりよいものにします。\n\nGitLab は、Webhookレシーバー経由でPrometheus を含むあらゆる監視ソースからのアラートを受け取れます。アラートが受信されると「GitLab アラート」リストに表示され、ここから手動で管理できます。アラートは自動的にインシデントや ChatOps を生成するようにしたり、適切な個人やグループにメッセージを送るよう、トリガー設定できます。こういった機能はすべて、アラートの解決策および管理プロセスを効率化します。\n\n本番環境で発生した問題のためにインシデントが作成されると、インシデント管理用に GitLab の「インシデントリスト」に表示されます。インシデントは 1 つまたは複数を一度に管理でき、ソートや、検索、割り当てを行なったり、ステータスを設定し、SLA プリセットカウントダウンタイマーを見ることもできます。さらに、インシデントを処理するために、オンコールのスケジュールやローテーション、エスカレーションポリシーを作成し、ページングや通知を設定することもできます。さらに、インシデントはアラートにリンクすることで、インシデントがクローズされるとそれに関連付けられていたアラートも自動的に解決されるよう設定可能です。インシデントのタイムラインは、役員や外部からの閲覧者がインシデント中に何が起きたのか、それを解決するためにどんな手順を踏んだのかを確認する機能です。こういった各種機能はすべて、インシデント管理プロセスを効率化し、インシデントを可能な限り迅速に解決するためのものです。\n\n監査イベントは、GitLab で誰がいつ関連する対応を行なったのか、など重要なイベントを追跡します。監査イベントは GitLab の「監査イベント」リストに表示され、オブジェクトに対して実行したアクション、実行者、実行日時などが表示されます。\n\nこれまで説明した、すべてのリストとダッシュボードは、コンプライアンス違反の事前対策を手助けし、ペナルティを回避するだけでなく、監査プロセスを効率化するのにも役立ちます。実行中のアプリケーションから生成されたデータやメトリクスは、GitLab Flow の外側のフィードバックループで使用できます。このため、アプリケーションの改善と最適化が促され、予定外の本番環境でのシステム停止のリスクが低減されます。\n\n### 継続的な改善\nGitLab Flow を適用すると、GitLabが提供するエンドツーエンドのプロセスメトリクスのダッシュボードから知見が得られます。そのため、アプリケーションだけでなくソフトウェアのデリバリーパフォーマンスも継続的に改善できます。これらのダッシュボードとそのメトリクスは GitLab によって自動生成され、常時利用可能です。\n\nアプリケーション開発のライフサイクルは「バリューストリーム分析ダッシュボード」を使い、追跡、監視できます。ここでは時間の経過によるプロジェクトやグループの統計が確認できます。このダッシュボードはカスタマイズできますが、GitLab が提供しているデフォルトのテンプレートを使って、バリューストリームを作成すれば、迅速に開始できます。デフォルトのダッシュボードには、事前定義されたバリューストリーム分析の各ステージのメトリクスが表示されます。メトリクスとは、イシュー、プラン、コード、テスト、レビュー、ステージングなどで、それぞれの完了までにかかる平均時間がグラフで表示されます。ここには、リードタイム、サイクルタイム、新規イシュー、コミット、デプロイなどバリューストリーム分析のキーメトリクスも表示されます。これらのメトリクスを利用すれば、バリューストリームの各ステージについて、改善可能な領域が見つかります。\n\nパフォーマンスメトリクスでは、組織の開発およびデリバリーの有効性や効果を測定しますが、こういったメトリクス用に、GitLab は DORA (DevOps Research and Assessment) メトリクスダッシュボードを提供しています。ここには「デプロイ頻度」、「変更のリードタイム」、「サービス復旧時間」、「変更失敗率」の、4 つの主なメトリクス（Four Keys）が表示されます。「デプロイ頻度」は組織がどのくらいの頻度で本番環境にコードをデプロイするのか、またはそれをエンドユーザーにリリースするのかを測定します。「変更のリードタイム」は、コードをコミットした時点から、本番環境で実行されるまで、どれくらいの時間がかかるのかを測定します。「サービス復旧時間」は、インシデントが発生した場合に、どれくらいの時間でサービスをインシデント以前の状態に復旧できるのかを測定します。「変更失敗率」は、本番環境への変更またはユーザーにリリースされた変更のうち、サービス改悪につながったもの (たとえばサービス障害や停止につながった変更) で、その後、復旧が必要になった (ホットフィックス、ロールバック、パッチが必要になったなど) 変更の割合を示します。これらの 4 つの主要メトリクスは現在のプロセスを表すものであり、これを分析すれば、いろいろな要因や能力を改善できるでしょう。\n\nもうひとつのダッシュボードは、カスタム化可能な「バリューストリームダッシュボード」で、意思決定者が、傾向、パターンやソフトウェア開発改善の機会を特定できるようにするものです。表示されるメトリクスは DORA メトリクスに続いて、バリューストリーム分析のフローメトリクスと直近 1 か月間、2 か月間、6 か月間の重大な脆弱性の件数です。\n\nGitLab Duo は、継続的な改善への取り組みにも役立ちます。たとえば、「**バリューストリーム予測**」機能は、過去のデータを取り込んで、開発ライフサイクル全体のデータ傾向を使い、組織のバリューストリームメトリクスの今後の動向を予測します。こういった予測解析は、最適化の取り組みに活用できます。\n\nこれまで説明してきたすべてのダッシュボードや、そこで報告されるメトリクスは、GitLab Flow の外側フィードバックループを構成しており、予定外の本番環境でのシステム停止のリスクを低減し、アプリケーションと DevSecOps ワークフローを改善し、かつ最適化するのに役に立ちます。\n\n## GitLab Flow を使う理由\nGitLab Flow は、手順が規定されたアプローチで、世界中のユーザーが実践しているもので、次のような利点があります。\n\n* GitLab Flow を活用することで、GitLab が提供する自動化機能や、単一ユーザーインターフェース、データモデルによって生産性が向上\n\n* 継続的な改善をサポートする、エンドツーエンドの DevSecOps ライフサイクルへの正確な洞察\n\n* アプリケーションと DevSecOps プロセスの最適化に役立つ組み込み型ダッシュボードとメトリクス\n\n* コード品質の向上、ならびにアプリケーションの信頼性・可用性の向上\n\n* 組み込みのセキュリティスキャナと各種機能によるアプリケーションセキュリティの向上\n\n* 組み込みのコンプライアンス機能によるコンプライアンスおよび監査への対応デプロイ頻度を高めるサイクル時間の短縮\n\n* GitLab Flow の内側フィードバックループによる継続的なレビュー\n\n* GitLab Flow の内側フィードバックループによる、アプリケーションのアップデートの最適化、コード品質向上、アプリケーションの信頼性と可用性の改善\n\n* GitLab Flow の外側フィードバックループによる、開発ライフサイクルそのものだけでなく、アプリケーションも改善\n\n* 組織内の関係者間での強力な共同体制の確立\n\n* セキュリティをシフトレフトすることにより、コードを本番環境に出す前に、アプリケーション内の脆弱性を見つけ、費用のかかる、予定外のシステム停止を回避\n\n* GitLab によりサポートされている高度なデプロイ技術やプログレッシブデリバリーアプローチにより、本番環境へのデプロイ時のリスクを低減\n\n* 開発ライフサイクル全体にわたり、生産性、コード品質、継続的改善、セキュリティやコンプライアンスなどを強化させるAI 搭載機能\n\n* クラウドネイティブと非クラウドネイティブのアプリケーションをサポート\n\n* ハイブリッド / マルチクラウドアプリケーション向けのマルチクラウドサポート\n\nGitLab Flow はどう始めたらよいのでしょう。GitLab Flow の原則をお使いのアプリケーション開発ライフサイクルに適用してみたい場合、GitLab Auto DevOpsやその一部を活用することから始めるのが良いかもしれません。\n\n## GitLab Flow と Auto DevOps\n\n![Auto DevOps - an instantiation of GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/ado-pipeline.png)\n\u003Ccenter>Auto DevOps – GitLab Flow のインスタンス化\u003C/center>\u003Cp>\u003C/p>\n\n[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) は、GitLab Flow の全ステージやジョブに適用されます。つまり、Auto DevOps は GitLab Flow のインスタンス化の好例と考えるとよいでしょう。\n\nAuto DevOps は事前定義済みの、すぐに使用可能な CI/CD テンプレートで、ソースコードを自動検出できます。ベストプラクティスに基づき、CI/CD テンプレートは自動的にアプリケーションを検出、ビルド、テスト、デプロイ、監視します。\n\nAuto DevOpsパイプラインは、ソフトウェアデリバリープロセスで、早期段階で欠陥を発見し、予防する作業をシフトレフトします。次にAuto DevOps パイプラインはアプリケーションを検証するためステージング環境にデプロイし、その後、本番環境に段階的に、または、タイミングを合わせてデプロイします。\n\nAuto DevOps は迅速に利用開始でき、開発者の生産性を向上できます。また、最も一般的なプログラミングフレームワークとプログラミング言語をサポートするので、ニーズに合わせて簡単にカスタマイズできます。Auto DevOps はモジュラーであり、カスタマイズができ、拡張可能です。そのため、パイプラインに Auto DevOps の一部を活用したり、アプリケーションにすべてを適用することもできます。\n\n## 今すぐ始めてみましょう\n[GitLab Flow と GitLab Duo を組み合わせる](https://gitlab.com/-/trials/new?glm\\_content=default-saas-trial\\&glm\\_source=about.gitlab.com%2Fblog%2F) と、エンドツーエンドのワークフロー効率が顕著に改善できます。それにより、生産性、デプロイ頻度、コード品質、セキュリティ全般、プロダクションの耐久性と可用性について、さらなる改善が実現できます。\n\nGitLab Flow と GitLab Duo を併用するアプリケーションでのワークフローの確認や、メリットの確認には、次のビデオをご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0JQUf9UOAdo?si=ZxgI3_nIODV6Gijw\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*\\*監修：伊藤 俊廷 [@toshitakaito](https://gitlab.com/toshitakaito) （GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト）*",[110,721,702],{"slug":3754,"featured":6,"template":681},"gitlab-flow-duo","content:ja-jp:blog:gitlab-flow-duo.yml","Gitlab Flow Duo","ja-jp/blog/gitlab-flow-duo.yml","ja-jp/blog/gitlab-flow-duo",{"_path":3760,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3761,"content":3767,"config":3772,"_id":3774,"_type":16,"title":3775,"_source":17,"_file":3776,"_stem":3777,"_extension":20},"/ja-jp/blog/the-ultimate-guide-to-sboms",{"title":3762,"description":3763,"ogTitle":3762,"ogDescription":3763,"noIndex":6,"ogImage":3764,"ogUrl":3765,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3765,"schema":3766},"SBOMとは？セキュリティとの関連性を含めた完全ガイド","SBOM（ソフトウェア部品表）がソフトウェア開発の管理やセキュリティに与える影響等について様々な観点から学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SBOMとは？セキュリティとの関連性を含めた完全ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }",{"title":3762,"description":3763,"authors":3768,"heroImage":3764,"date":3769,"body":3770,"category":722,"tags":3771,"updatedDate":1229},[2316],"2022-10-25","急速に進化を遂げる今日のデジタル環境では、ソフトウェアサプライチェーンにおけるアプリケーション・セキュリティの重要性がかつてないほど高まっています。アップストリームの依存関係をソフトウェアに統合するには、透明性とセキュリティ対策が必須ですが、その実装と管理は思った以上に複雑です。そこで、今回のテーマであるソフトウェア部品表（SBOM）の出番となります。\n\nSBOM（Software Bill of Materials）、日本語でソフトウェア部品表は、ソフトウェアの構成部品を包括的にリスト化したもので、開発ライフサイクル全体で使用されるライブラリ、ツール、プロセスの複雑な関係性を明確にします。また、脆弱性管理ツールと組み合わせることで、ソフトウェア製品に潜在する脆弱性を明らかにするだけでなく、戦略的リスク軽減も可能にします。本ガイドは、SBOMの重要な役割、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)戦略におけるその中心的位置付け、そしてアプリケーションのSBOM健全性を向上させるための戦略について深く掘り下げます。そして、潜在的脅威に満ちた環境における組織のサイバーセキュリティ体制を強化することを目的としています。\n\n## 目次\n\n1. SBOMとは？\n2. SBOMが重要な理由 \n3. SBOMデータ交換標準フォーマットの種類\n4. SBOMとソフトウェアの脆弱性管理を組み合わせるメリット\n5. Gitlabと動的なSBOM\n   1. SBOMの生成と管理の拡大\n   2. SBOMの統合とインジェスト\n   3. SBOMの健全性を他持つための対策を迅速に行うには  \n   4. 継続的なSBOM分析\n   5. SBOMの信頼構築\n6. Gitlab SBOM機能の今後の進化\n7. SBOMを始めましょう\n8. SBOMに関するFAQ  \n   1. SBOMとは？\n   2. なぜSBOMは重要なのですか？\n   3. SBOMのデータ交換に使用される標準フォーマットは何ですか？\n   4. SBOMに対するGitLabのアプローチはどのようなものですか？\n   5. SBOMを組織に導入するにはどうすれば良いですか？\n\n## SBOMとは？\n\nSBOMとは、ソフトウェアを作るために使用された[コンポーネントをリスト化](https://www.cisa.gov/sbom#)（外部サイト）したものです。コンポーネント間の関係性も階層的に示します。このリストには、ソフトウェア・アーティファクトの開発、構築、およびデプロイに使用されるライブラリ、ツール、およびプロセスに関する重要情報も含まれます。\n\nSBOMの概念は10年以上前から存在しています。しかし、米国ホワイトハウスが2023年に発表した国家サイバー戦略を実施する一環として、CISA（米国土安全保障省の外局機関「サイバーセキュリティー・インフラセキュリティー庁」）の「[セキュア・バイ・デザイン（Secure by Design）](https://www.cisa.gov/securebydesign)（外部サイト）」フレームワークはソフトウェアメーカーに対して、この原則を採用、サイバーセキュリティを製品に統合するよう促しています。加えて同政府は、公共部門に販売するアプリケーションデベロッパーにソフトウェア・パッケージに SBOM を含めるよう促すベストプラクティスも発表しました。民間企業もこれに追随し、SBOMは普及への道を進んでいます。また日本でも、同年度に「[ソフトウェア管理に向けたSBOM導入に関する手引](https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html)（外部サイト）」が経済産業省により作成されました。\n\nSBOMは専用のソフトウェアで個別に作成されることが多いものの、GitLabのようなプラットフォーム型のソリューションでは、DevSecOpsワークフローの初期段階からSBOMの生成が完全に組み込まれており、重要な役割を果たすようにしています。\n\n![サプライチェーンセキュリティとシステム開発ライフサイクル](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n## SBOMが重要な理由\n\n現代のソフトウェア開発は、より迅速かつ効率的な方法でアプリケーションをリリースすることに注力しています。そのためデベロッパーは、オープンソースのリポジトリやプロプライエタリ（専有）パッケージのコードをアプリケーションに組み込むことがあります。Synopsys社が発行した「2024年度オープンソースセキュリティおよびリスク分析レポート」によると、2023年に17の業界にわたる1,000以上の商用コードベースを分析した結果、コードベース全体の96%にオープンソースが含まれ、リスク評価されたコードベースの84%に脆弱性が含まれていたことが明らかになりました。\n\n未知のリポジトリを使用することは、ハッカーに悪用される脆弱性を含むコードを取り込む可能性を高めます。実際、2020年の[SolarWinds社への攻撃](https://cloud.watch.impress.co.jp/docs/topic/special/1359685.html)（外部サイト）は、彼らのOrion製品で使用されているパッケージに、悪意のあるコードが仕込まれており、これが実行されたことに端を発しています。この事件では、ソフトウェアサプライチェーン全体の顧客が重大な影響を受けました。また、多くの商用ソフトウェアベンダーに影響を与えたlog4jの脆弱性を含むその他の攻撃は、[ソフトウェアサプライチェーン全体のリスクを評価](https://about.gitlab.com/ja-jp/solutions/supply-chain/)できるよう、コンテナやインフラを含むアプリケーションの依存関係を綿密調査する必要性を確固たるものとしました。\n\nさらに、ソフトウェアのセキュリティ脆弱性を発見し修正するにはコストがかかることも、SBOMの必要性が高まっている理由の一つであり、同時にソフトウェアのサプライチェーン攻撃が企業の評判に与えるダメージも考慮すべき要素です。SBOMは依存関係の把握や、脆弱性や内部ポリシーに準拠していないライセンスの特定にも役立ちます。\n## SBOMデータ交換標準フォーマットの種類\n\nSBOMは、名前、バージョン、パッケージャーなどの情報の生成と解釈が自動化されることで、最も効果的に活用できます。これには、すべての関係者が標準的なデータ交換フォーマットを使用することが重要です。現在使用されている主なSBOMデータ交換標準フォーマットには、次の2つの種類があります:\n\n* [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/)（外部サイト）  \n* [SPDX](https://spdx.dev/)（外部サイト）\n\nGitLabは、SBOMの生成にCycloneDXを使用しています。この標準フォーマットは指示的で使いやすく、複雑な関係を簡素化し、特定や将来のユースケースに対応できる拡張性を備えています。さらに[cyclonedx-cli](https://github.com/CycloneDX/cyclonedx-cli#convert-command)（外部サイト）や[cdx2spdx](https://github.com/spdx/cdx2spdx)（外部サイト）は、CycloneDXファイルを必要に応じてSPDXに変換するためのオープンソースツールとして利用可能です。\n\n## SBOMとソフトウェアの脆弱性管理を組み合わせるメリット\n\nSBOMがDevSecOpsチームやソフトウェアの利用者にとって非常に有益な理由は次の通りです。\n\n* アプリケーションに含まれる追加のソフトウェアコンポーネントとその宣言場所が標準的なアプローチで理解できるため\n* アプリケーションの作成履歴を継続的に可視化し、サードパーティのコードの出所やホストリポジトリの詳細を含むため\n* ファーストパーティによる開発コードと採用されたオープンソースソフトウェアの両方に対して、深いレベルでセキュリティの透明性を提供できるため\n* SBOMが提供する詳細情報により、DevOpsチームが脆弱性を特定し、潜在的なリスクを評価し、それらを軽減することができるため\n* アプリケーション購入者が昨今求めている透明性を提供できるため\n\n## Gitlabと動的なSBOM\n\nSBOMを最大限活用するには、組織がSBOMを自動生成し、アプリケーションセキュリティスキャンツールと連携させ、脆弱性やライセンスをダッシュボードに統合することで内容を把握しやすくし、対応できるようにする必要があります。さらに、継続的に更新することが求められます。GitLabは、これらすべての要件をサポートしています。\n\n![ダイナミックSBOM管理](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### SBOM生成と管理の拡大\n\nオープンソース、サードパーティ、および専有ソフトウェアを網羅した正確で包括的なSBOMを所有することが、内部ポリシーや規制に準拠する上で重要です。そして、各コンポーネントや製品バージョンのSBOMを効果的に管理するには、SBOMの作成、統合、検証、承認を効率的に行うためのスムーズなプロセス確立が必須です。GitLabの[依存関係リスト](https://gitlab-docs.creationline.com/ee/user/application_security/dependency_list/)機能は、既知の脆弱性およびライセンスに関するデータを一元化されたユーザーインターフェース内で表示します。依存関係スキャンレポートの一部として依存関係グラフ情報も生成され、ユーザーは個々のプロジェクトや複数のプロジェクトにわたる依存関係やリスクに関する包括的なインサイトを得ることができます。また、CIパイプライン内でJSON形式のCycloneDXアーティファクトの生成が可能です。このAPIは、SBOM生成において、より柔軟でカスタマイズ可能なアプローチを提供します。さらにSBOMは、UIや特定のパイプライン、プロジェクト、またはGitLab APIを通じてエクスポートすることができます。\n\n### SBOMの統合とインジェスト\n\nGitLabは、サードパーティのSBOMを取り込むことができ、サードパーティによる開発コードと採用されたオープンソースソフトウェアの両方に対して、深いレベルでセキュリティの透明性を提供します。。Gitlabの[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ジョブを使うことで、複数のCycloneDX SBOMをシームレスに統合し、1つのSBOMにまとめることもできます。\n\n各SBOMのCycloneDXメタデータに含まれるビルドやロックファイルの場所などの実装固有の詳細を使用し、統合ファイルから重複情報が削除されます。またこのデータは、SBOM内のコンポーネントに対するライセンス情報および脆弱性情報が追加されることで自動的に強化されます。\n\n### SBOMの健全性を保つための対策を迅速に行うには\n\n高品質な製品を迅速に構築するには、対策可能なセキュリティ上の問題を検出し、デベロッパーがその中で最も影響の大きい脆弱性に対処できるようにする必要があります。GitLabはソースコード、コンテナ、依存関係、実行中アプリケーションにおける[脆弱性をスキャン](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html)することで、サプライチェーンのセキュリティを強化します。また、静的アプリケーションセキュリティテスト（SAST）、動的アプリケーションセキュリティテスト（DAST）、コンテナスキャン、ソフトウェア構成分析（SCA）機能など、さまざまなセキュリティスキャン機能を提供し、進化する脅威ベクトルに対し、全方位的な防御を実現します。GitLabのAI搭載機能「GitLab Duo脆弱性の説明」は、デベロッパーやセキュリティエンジニアが脆弱性をより理解し効率的に修正できるようサポートします。具体的には、特定の脆弱性に関する説明、その悪用可能性、そしてこれが最重要ですが、修正方法の提案を行います。「GitLab Duo 脆弱性の修正」と組み合わせることで、DevSecOpsチームはたった数回のクリックで脆弱性を特定、分析、修正することができます。\n\nまた、本プラットフォームは、新たに検出された脆弱性に基づいて、新しいポリシーの作成や[コンプライアンスの強制](https://docs.gitlab.com/ee/administration/compliance.html)もサポートしています。\n\n### 継続的なSBOM分析\n\nGitLabの継続的な脆弱性スキャンは、パイプラインの実行に関わらず、コンテナスキャン、依存関係スキャン、またはその両方が有効になっている全プロジェクトにに対してスキャンをトリガーします。新しい共通脆弱性識別子（CVE）が米国国立脆弱性データベース（NVD）に報告された場合、ユーザーが最新フィードを取得するためにパイプラインを再実行する必要はありません。\n\nGitLabの脆弱性調査チームが、GitLabのアドバイザリ・データベースにそれらの脆弱性情報を追加し、自動的にGitLabに脆弱性として報告されます。このように、最新の情報がリアルタイムで更新される仕組みから、GitLabのSBOMが本質的に動的であることが分かります。\n\n### SBOMに対する信頼構築\n[コンプライアンス機能](https://about.gitlab.com/ja-jp/solutions/compliance/)を必要とする組織は、GitLab Runnerによって生成されたすべてのビルドアーティファクトの証明書を作成できます。このプロセスでは、GitLab Runner内で証明書を生成します。データを外部サービスに引き渡すことないため、安全です。\n\n## Gitlab SBOM機能の今後の進化\n\n大手ソフトウェアベンダーやオープンソースソフトウェアエコシステムを狙った集中的な攻撃が頻繁に発生しているため、ソフトウェアサプライチェーンのセキュリティは、サイバーセキュリティおよびソフトウェア業界において引き続き重要なトピックとなっています。確かにSBOM業界は急速に進化していますが、SBOMの生成方法、生成頻度、保存場所、分析方法、複雑なアプリケーション向けに複数SBOMを統合する方法、アプリケーションの健全性向上に際した活用方法等に関して、依然として懸念があります。\n\nGitLabはSBOMを、[ソフトウェアサプライチェーン戦略](https://about.gitlab.com/direction/supply-chain/)になくてはならないものと位置付け、新機能追加の計画を含め、DevSecOpsプラットフォーム内でSBOM関連機能の強化を継続しています。最近の改善点には、証明の自動化、ビルドアーティファクトのデジタル署名、外部で自動生成されたSBOMのサポートが含まれます。\n\nまた、GitLabはプラットフォーム内に堅牢なSBOM成熟度モデルを確立しており、これには自動SBOM生成、開発環境からのSBOM取得、アーティファクトのSBOM分析、SBOMのデジタル署名の推奨といったステップが含まれています。さらに今後のリリースでは、ビルドアーティファクトの自動デジタル署名機能も追加する予定です。\n## SBOMを始めましょう\n\nSBOMの需要は既に高まっています。政府機関はソフトウェアベンダー、連邦政府のソフトウェアデベロッパー、さらにはオープンソースコミュニティに対して、SBOM作成を推奨または義務付けるになってきています。\n\n> これら要件を先取りするなら、[Gitlab DevSecOpsプラットフォームで提供されている](https://about.gitlab.com/ja-jp/)  \nGitLab Ultimate向けSBOM機能をご確認ください。\n\n## SBOMの基礎知識まとめとFAQ\n\n### SBOMとは？\n\nSBOMとはソフトウェア部品表のことであり、ソフトウェアの作成、ビルド、デプロイに使用されたすべてのコンポーネント、ライブラリ、ツールを一覧にして詳しく記載したものです。この包括的なリストは単なる一覧にとどまらず、コードの起源に関する重要な情報も含み、アプリケーションの構成や潜在的脆弱性をより深く理解するのに役立ちます。\n\n### なぜSBOMは重要なのですか？\n\nSBOMが重要な理由は次の通りです。\n\n* **依存関係のインサイト**: ソフトウェアの構成要素を理解することで、サードパーティ製コンポーネントに関連するリスクを特定し、軽減できます。  \n* **セキュリティの強化**: アプリケーションコンポーネントにの詳細を把握し、脆弱性を迅速に特定し、適切な対策を講じることができます。  \n* **規制遵守**: 規制やベストプラクティスにより、特に公共部門向けのソフトウェアパッケージに対して、SBOMが推奨または義務化されつつあります。  \n* **開発の効率化**: デベロッパーが、使用されているライブラリやコンポーネントに関するインサイトをSBOMから得ることで、開発サイクルの時間を節約し、エラーを減らすことができます。\n\n### SBOMのデータ交換に使用される標準フォーマットは何ですか？\n\n主なフォーマットは次の2つです。\n\n* **CycloneDX**: ソフトウェアコンポーネントとサポート間の複雑な関係を簡素化してくれるため、その使いやすさで知られており、特定のユースケースににも柔軟に対応します。  \n* **SPDX**: SBOMデータ交換のために、広く使われているもう一つのフレームワーク。ソフトウェア環境内のコンポーネントに関する詳細情報を提供します。\n\nGitLabはSBOMの生成にCycloneDXを採用しています。指示的でありながらも柔軟に拡張可能であり、将来にわたって使い続けられるためです。\n\n### SBOMに対するGitLabのアプローチはどのようなものですか？\n\nGitLabは動的なSBOMの作成として次の点を重視しています。\n\n* **自動生成**: ソフトウェアの構成に関する最新情報が常に反映されること  \n* **ツールとの統合**: リスク評価を徹底的に実施するために、脆弱性スキャンツールと連携すること  \n* **簡単な管理**: SBOMの取り込みや統合をサポートし、包括的な分析が可能なこと  \n* **継続的な分析**: プロジェクトを継続的にスキャンし、新たに発生する脆弱性を検出すること\n\n### SBOMを組織に導入するにはどうすれば良いですか？\n\nSBOMの導入を検討している組織向けに、GitLab Ultimateがあります。このパッケージは、DevSecOpsワークフロー内でSBOMの生成と管理を行うための強力なプラットフォームを提供します。GitLabのツールを活用することで、チームはコンプライアンスの確保、セキュリティの強化、開発プロセスの最適化を実現できます。\n\nSBOMへの需要が高まっている背景には、ソフトウェアのセキュリティとサプライチェーンの整合性への関心が増していることが挙げられます。SBOM機能を統合することで、組織は脆弱性に対する保護を強化し、新しい規制にも確実に対応できるようになります。\n\n> GitLab Ultimateを[無料](https://about.gitlab.com/ja-jp/free-trial/devsecops/)でお試しください。\n\n免責事項: このブログには、今後の製品、機能、および機能性に関する情報が含まれています。本ブログの情報はあくまで参考情報であり、購入やプランニングの際に情報の正確性を保証するものではありません。本ブログやリンクされたページに記載されている内容は、変更や未更新の可能性があります。製品、性能、および機能の開発、リリース、タイミングについては、予告なく内容を変更または削除する場合があります。\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*",[722,702,1191,825,188],{"slug":3773,"featured":6,"template":681},"the-ultimate-guide-to-sboms","content:ja-jp:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","ja-jp/blog/the-ultimate-guide-to-sboms.yml","ja-jp/blog/the-ultimate-guide-to-sboms",{"_path":3779,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3780,"content":3786,"config":3794,"_id":3796,"_type":16,"title":3797,"_source":17,"_file":3798,"_stem":3799,"_extension":20},"/ja-jp/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"title":3781,"description":3782,"ogTitle":3781,"ogDescription":3782,"noIndex":6,"ogImage":3783,"ogUrl":3784,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3784,"schema":3785},"GitLabにおける「Docs as Code」の5つのポイント","この記事では、GitLabのテクニカルライターがDocs-as-Codeワークフローを用いてGitLabをどのように利用しているのかを、5つのポイントに分けてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660257/Blog/Hero%20Images/pen.jpg","https://about.gitlab.com/blog/five-fast-facts-about-docs-as-code-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabにおける「Docs as Code」の5つのポイント\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suzanne Selhorn\"},{\"@type\":\"Person\",\"name\":\"Susan Tacker\"},{\"@type\":\"Person\",\"name\":\"Diana Logan\"}],\n        \"datePublished\": \"2022-10-12\",\n      }",{"title":3781,"description":3782,"authors":3787,"heroImage":3783,"date":3791,"body":3792,"category":3355,"tags":3793},[3788,3789,3790],"Suzanne Selhorn","Susan Tacker","Diana Logan","2022-10-12","\n\nGitLabでは、「Docs-as-Code」ワークフローを使うことで、単一のプラットフォームとしてGitLabを使ってGitLabのドキュメントを作成・管理しています。少しわかりづらいでしょうか？\n\nGitLabのテクニカルライティングチームは、GitLabを使って[GitLabドキュメント](https://docs.gitlab.com/)の計画、作成、レビュー、編集、公開までを一貫して行っています。Docs-as-Codeワークフローを導入することで、熱意ある少人数の効率的な備えたチームで膨大な量のコンテンツを生み出すことが可能になっています。\n\nDocs-as-Codeに馴染みがない方のために、簡単にご説明します。\n\n[Docs-as-Code](https://idratherbewriting.com/trends/trends-to-follow-or-forget-docs-as-code.html#what-is-docs-as-code)とは、製品ドキュメントの開発や公開を、ソフトウェアコードの開発と同じツールやプロセスを用いて行う手法です。ドキュメントファイルはコードファイルと同じリポジトリで管理され、バージョン管理も可能です。\n\nご自身が所属する組織でGitLabにDocs-as-Codeワークフローを採用できるか気になっている場合は、ぜひこの記事を読み進めてください。GitLabチームが実践している5つの方法をまとめてご紹介します。\n\n## GitLabを使ってGitLabの機能とドキュメントの更新を計画\n\nプロダクトマネージャー、UXデザイナー、エンジニア、品質管理チームは連携して機能の開発計画を立てます。リリースを計画する際に、Kanbanボードを使ったり、サードパーティのツールでイシューを作成したりするチームも多いかと思います。\n\nGitLabでは、エピックとイシュー[イシュー](https://gitlab.com/gitlab-org/technical-writing/-/issues/680)を使って作業計画を立て、[イシューボード](https://gitlab.com/groups/gitlab-org/-/boards/4340643?label_name%5B%5D=Category%3ADocs%20Site)を用いて進捗を管理します。GitLabでは透明性を重視しているため、計画に関するディスカッションも含め、こうした情報には誰もがアクセスできるようになっています。そのため、テクニカルライティングチームは開発の進行状況をいつでも把握できる環境にあります。\n\n![イシューの計画](https://about.gitlab.com/images/blogimages/planning_issue.png)\n\n大規模なドキュメント作業を行う場合、その進捗をGitLabで管理し、変更はGitLabを使用して行い、イシューが完了したらGitLabで完了マークを付けます。1年後に変更の理由を振り返りたい場合、GitLabで検索すれば、誰がどのような理由で変更を加えたのかを確認できます。現在、複数のツールを使って作業している方は、一度にすべてを一元的に管理できる環境を想像してみてください。より迅速かつ効率的に作業を進められると思いませんか？通常ならメールやウェブサイト、Slackを見て回って見失ったディスカッションを探すのに時間を費やしていたかもしれませんが、それがすべてGitLabに集約されているため、無駄な時間を省けます。\n\nもしWikiを愛用していて、不可欠だという場合でもご安心ください。GitLabにはWiki機能も備わっています。\n\n## GitLabを使ってドキュメントのフィードバックをやりとり\n\nライターとして一定の経験がある方なら、コンテンツのレビューを依頼する際の手間をよくご存じでしょう。\n\nGitLabでは、デベロッパーがすべての新機能に関するコンテンツの初稿を作成します。そして、そのコンテンツはコードと同じリポジトリに保存されます。機能に関するドキュメントは、GitLabの開発プロセスにおける「完了の定義（DoD）」の一部です。デベロッパーはその初稿をライターに割り当て、ライターはそれをレビューし、提案を加え、アイデアや必要な編集内容を作成者であるライターに返します。\n\nライター自身もコンテンツの変更を行う場合は、マージリクエスト（MR）を作成します。MRを作成するのがライターであれ、デベロッパーであれ、サポートエンジニアであれ、コミュニティのコントリビューターであれ、誰でもお互いの作業に簡単にコメントできる仕組みになっています。\n\nマージリクエストでは、「提案」ボタンを選択するだけで簡単にコメントできます。1行、または複数行単位でコメントを付けることができ、変更や編集を提案できます。MRを作成した本人は、その変更を簡単に適用したり、別の提案を作成し議論したりできます。他のユーザーを会話に招待するには、コメントにユーザー名を入力します。すると、相手にコメントがGitLabのTo Doアイテムとして表示されます。このようにして、あらゆる変更について議論でき、透明性があり、誰もが参加できる環境が整っています。\n\n![提案](https://about.gitlab.com/images/blogimages/suggestion.png)\n\nドキュメントの内容はMarkdown形式で記述されており、プレーンテキストに似ているため、ファイルのバージョン間の違いを簡単に確認でき、誰がどの変更をコミットしたのかも把握できます。\n\nPDFやWordドキュメント、Googleドキュメントでコメント機能を使ってレビューを行った経験がある方も多いでしょう。このワークフローを試すと、どれだけ効率的に作業が進むかを実感できるはずです。古いバージョンのドキュメントが使われることもなく、誰かのコメントを意図せず削除してしまうようなこともありません。\n\nまた、変更の理由を知りたい場合も、ページの履歴を簡単に確認でき、特定の行について誰が「担当者」であるかもすぐに確認できます。\n\n![担当者の表示](https://about.gitlab.com/images/blogimages/blame.png)\n\n複数のバージョンのPDFドキュメントを管理したり、誰がどの変更を提案したのかを探したりする必要はもうありません。すべての管理がGitLab内で完結するため、手間が省けます。\n\n## GitLabを使ってドキュメントの内容をプレビュー\n\nGitLabでは、ドキュメントサイトのコンテンツをローカルで生成するツールを提供していますが、マージリクエストから直接ドキュメントサイトを簡単に共有することもできます。新しいアイデアを試していて、それを誰かに見せたい場合は、マージリクエストを開き、「アプリレビュー」を生成すると、変更されたドキュメントサイトを公開URLで確認できるようになります。\n\n![アプリレビュー](https://about.gitlab.com/images/blogimages/view_app.png)\n\n変更内容を確認でき、イテレーションを行うことも、そのままコミットすることも可能です。次にこれに関連する、GitLabの便利な機能をもうひとつご紹介します。\n\n## GitLabを使ってすべてのコンテンツの変更をテスト\n\nドキュメント内のリンクをテストしたり、スペルや文法のルールを確認したりするために、サードパーティーのツールが使っている方も多いかと思います。\n\nGitLabでは、Nanoc（リンクのテスト用）やVale（スペル・文法の確認用）などのサードパーティツールを使用していますが、これらのツールもGitLabに統合でき、ライターのワークフローにも組み込むことができます。\n\n各ライターは、自身のローカル環境でこれらのツールを使用し、ドキュメントの読解レベルや文法修正などをすべて確認できます。これらのツールを持っていないコントリビューターには、パイプラインで自動的にテストを実行し、すべてのコミットに対して結果を表示する仕組みを導入しています。\n\n![Lintエラー](https://about.gitlab.com/images/blogimages/lint_error_2.png)\n\nデベロッパーとして、文章の専門知識に自信がない場合、マージリクエストのパイプラインで重要な文法やブランディングルールに従っていないために処理が進まないことがあります。GitLabでは、さまざまなルールを定め、それぞれに優先順位を付けています。そのため、[スタイルガイド](https://docs.gitlab.com/ee/development/documentation/styleguide/)や[単語リスト](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html)を用意しているだけでなく、テストを実行してコンテンツがそうしたルールに沿ったものになっているかを確認しています。\n\n## GitLabを使ってHTML出力を生成し、その出力をGitLab Pagesでホスト\n\nGitLabのCI/CDパイプラインは、Markdown形式のコンテンツをHTMLに変換してコンパイルします。その後、出力内容をGitLab Pagesを介して、[docs.gitlab.com](http://docs.gitlab.com)にホストします。\n\n![パイプライン](https://about.gitlab.com/images/blogimages/pipeline2.png)\n\nパイプラインによって出力を生成することで、必要なときにいつでもドキュメントサイトを更新できます。製品は月に一度リリースされますが、ドキュメントサイトは1時間ごとに更新されます。そのため、docs.gitlab.comでは常に最新の情報が提供されており、時にはリリース前の情報も公開されます。開発計画や実装に関するイシューはGitLabの透明性の方針に基づき公開されているため、機能の事前発表を行うことに問題はありません。\n\nこのように、GitLabが「Docs-as-Code」ワークフローを重視する理由は数多くあります。最初はドキュメント作成を1つのツールで完結させることに慣れずに戸惑うかもしれませんが、GitLabはライター全員のワークフローを最初から最後までサポートしており、長年の実績がその効果を証明しています。\n\nGitLabでのテクニカルライティングにおける「Docs-as-Code」ワークフローについて詳しくは、次の動画をご視聴ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZlabtdA-gZE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\nオープンソースドキュメントへのコントリビュート方法は、「[ドキュメントの更新方法](https://docs.gitlab.com/ee/development/documentation/workflow.html#how-to-update-the-docs)」でご確認いただけます。ぜひご参加ください。\n",[3732,2158,1880],{"slug":3795,"featured":6,"template":681},"five-fast-facts-about-docs-as-code-at-gitlab","content:ja-jp:blog:five-fast-facts-about-docs-as-code-at-gitlab.yml","Five Fast Facts About Docs As Code At Gitlab","ja-jp/blog/five-fast-facts-about-docs-as-code-at-gitlab.yml","ja-jp/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"_path":3801,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3802,"content":3808,"config":3814,"_id":3816,"_type":16,"title":3817,"_source":17,"_file":3818,"_stem":3819,"_extension":20},"/ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture",{"title":3803,"description":3804,"ogTitle":3803,"ogDescription":3804,"noIndex":6,"ogImage":3805,"ogUrl":3806,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3806,"schema":3807},"マイクロサービスアーキテクチャの基本とそのメリット","マイクロサービスアーキテクチャは、環境を細分化することで開発がスピーディに、かつ低コストで行えます。拡張性やセキュリティ面にも優れています。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662898/Blog/Hero%20Images/microservices-explosion.jpg","https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"マイクロサービスアーキテクチャの基本とそのメリット\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-09-29\",\n      }",{"title":3803,"description":3804,"authors":3809,"heroImage":3805,"date":3810,"body":3811,"category":740,"tags":3812,"updatedDate":3813},[696],"2022-09-29","マイクロサービスアーキテクチャを利用すると、アプリケーション開発がスピーディかつ低コストで行えます。また、複雑な開発や規模の大きな開発にも適しているため、マイクロサービスアーキテクチャを導入する企業が世界中で増加しています。\n\n本記事では、マイクロサービスアーキテクチャとは何か、マイクロサービスアーキテクチャを利用するメリットやデメリットについて解説します。\n\n## マイクロサービスアーキテクチャとは？\n\nマイクロサービスアーキテクチャ（Microservices Architecture）とは、開発環境やデータベースを細分化したアプリケーション開発手法です。それぞれのメンバーが、異なる環境やプログラミング言語で開発し、最終的にそれぞれの開発内容を統合して1つのアプリケーションやシステムを作りあげます。単にマイクロサービスと呼ばれることもあります。\n\n以前は、1つの環境でシステム開発を進める「モノリシック」という方法が主流でした。モノリシック（monolithic）は「一枚岩のような」という意味を持ち、開発者全員が単一の開発環境やデータベースを利用していました。これにより、優れたシステムやアプリケーションが多数誕生したのも事実です。\n\nしかしながら昨今、モノリシックは様々な壁に直面しています。例えば、モノリシックでは1つのエラーでシステム全体が影響を受けてしまい、修正に多くのコスト（時間や人件費）が必要になることがあります。また、変化の激しいVUCA時代に突入し、顧客からの要求が日々変化するようになり、モノリシック型の開発環境では対応に時間がかかりすぎるという課題も指摘されるようになりました。\n\nそこで注目を集めたのがマイクロサービスアーキテクチャです。マイクロサービスアーキテクチャは、複数人が同時並行で開発を進められます。また、問題が生じた際には関連する箇所を修正するだけで解決可能です。\n\n![Microservices vs monolith ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687528/Blog/Content%20Images/monolith-vs-microservices.png)\n\n*図：モノリスとマイクロサービスの比較*\n\n## 世界はモノリシックからマイクロサービスへ\n\n日本ではまだマイクロサービスを利用している企業は限定的ですが、世界ではモノリシックサービスからマイクロサービスへと変わりつつあります。例えば、日本でも人気の動画ストリーミングサービス「Netflix」は、モノリシックからマイクロサービスへ移行することで成功を収めた企業として有名です。膨大な情報をマイクロサービスで細分化して管理することで、1日に何千回も発生するデプロイや顧客からの要望に迅速に対応しています。\n\n[Fortune Business Insightsの調査](https://www.fortunebusinessinsights.com/jp/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E5%B8%82%E5%A0%B4-107793)によれば、世界のマイクロサービスクラウドの評価額は2022年に12億9千万ドル、そして2030年までに60億4千万ドルまで成長すると見込まれています。\n\n## マイクロサービスアーキテクチャのメリット\n\nマイクロサービスアーキテクチャを利用するメリットを以下にまとめました。それぞれについて詳しく説明します。\n\n- サービスをスピーディに提供できる\n- 拡張性が高い\n- 大規模なエラーが抑制できる\n- プログラミング言語の自由度が高い\n- 市場の要求に応じて柔軟に対応できる\n- 新規機能へのアップグレードが容易\n- コスト削減につながる\n- セキュリティ対策がしやすい\n- アウトソーシングを活用しやすくなる\n- 優秀な人材を確保しやすくなる \n\n### サービスをスピーディに提供できる\n\nモノリシックアーキテクチャーでは、1つの開発環境を共有し順番に開発を進めていく必要があります。自身に割り当てられた作業も、その他の作業が終わっていないという理由で、取りかかれないことがありました。\n\n一方マイクロサービスでは、各サービスが独立しているため、好きなタイミングで作業に取り組むことが可能です。また、複数人が同時に作業できるため、アプリケーションやシステムをスピーディに提供したい事業者に適しています。\n\n### 拡張性が高い\n\n各マイクロサービスが独立しているため、サービスの追加や削除、更新、拡張などが容易に実施できます。アップデートや市場に合わせた修正を頻繁に行いたい企業にとって大きなメリットといえます。\n\n### 大規模なエラーが抑制できる\n\nモノリシックアーキテクチャーでは、1つのエラーが原因でシステム全体が崩壊する可能性があります。一方マイクロサービスでは、各サービスが独立しているため、他のサービスに影響を与えることがまずありません。これにより、1つのエラーがシステム全体に影響を及ぼすことを抑制できます。\n\n### プログラミング言語の自由度が高い\n\nモノリシックアーキテクチャーの場合、単一の環境によって開発を行うため、場合によっては不慣れなスキルセットやテクノロジーでの対応が必要になります。その結果、開発に時間がかかるとともに、クオリティにも影響を及ぼします。\n\n一方マイクロサービスでは、各サービスでプログラミング言語やテクノロジーを選べます。開発者が得意なスキルセットを選べるため、高いクオリティのアプリケーションをスピーディに開発できるとともに、不慣れなプログラミング言語でエラーを出してしまうような事故も防ぐことができます。\n\n### 市場の要求に柔軟に対応できる\n\nシステムやアプリケーションを開発している最中に、市場の状況が変わり、急な変更を迫られることもあるでしょう。モノリシックの場合には、修正箇所がシステム全体に影響し、開発が大きく停滞してしまうことがありますが、マイクロサービスの場合、関連する箇所のみの修正で、その他のマイクロサービスには影響を与えないため、手戻りを最小限に食い止めることができます。\n\n### 新規機能へのアップグレードが容易\n\nモノリシックな環境では、一度構築したシステムやアプリケーションをアップグレードするのに多くのコストを費やす必要があるため、企画や実行に多大な労力が必要になります。一方マイクロサービスでは、必要な箇所のみのアップグレードで完了するため、開発の負担が圧倒的に小さくなります。\n\n### コスト削減につながる\n\nマイクロサービスでは、改修での開発工数やテスト工数を削減できるため、コスト削減につながります。サービスのアップデートやエラー修正にかかる時間も削減できるため、保守・運用にかかるコストを大幅に削減できるのも魅力です。\n\n### セキュリティ対策がしやすい\n\nモノリシックな環境下で何らかのセキュリティ問題が発生した場合、開発環境上にあるすべての情報が漏洩する可能性があります。一方マイクロサービスの場合には、各サービスごとに情報が分断されているため、重要な情報がまとまったかたちで漏洩するのを防げます。機密情報を扱う箇所に強固なセキュリティ対策を施しておけば、大規模な情報漏洩のリスクを削減できます。サービス間の連携では適切な[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)を使用すれば、より安心して利用できるでしょう。\n\n### アウトソーシングを活用しやすくなる\n\n昨今、開発業務の一部をアウトソースする企業が増えています。モノリシックな環境では、組織の知的財産の共有が懸念点としてありましたが、マイクロサービスであれば、必要なサービスの環境のみを共有できるため、情報漏洩の不安を抱えずに協力体制を構築できます。\n\n### 優秀な人材を確保しやすくなる\n\nマイクロサービスアーキテクチャは、開発者にとっても魅力的なプラットフォームです。プログラミング言語の自由度が高いことで、自身の得意なプログラミング言語やテクノロジーを最大限に活用して貢献できるためです。日本ではまだマイクロサービスを導入している企業が少ないのが現状ですが、今後マイクロサービス環境に興味を持ち、アプローチしてくる開発者が増えるでしょう。\n\n## マイクロサービスアーキテクチャのデメリット \n\n一方で、マイクロサービスアーキテクチャには以下のようなデメリットもあります。\n- 初期費用（導入コスト）が高くなる\n- 熟練者が求められる\n- インターフェイス制御が難しい\n- エラーの特定や結合テストが複雑になる\n\n### 初期費用（導入コスト）が高くなる\n\nマイクロサービスは長期的に見た場合にはコストカットに効果的ですが、セキュリティやメンテナンスサポートを備えたホスティングインフラストラクチャが必要になるため、初期費用はモノリシックと比べて高くなる傾向にあります。\n\n### 熟練者が求められる\n\nマイクロサービスは様々なパーツ開発を同時並行でマネジメントしたり、出来上がったサービスを適切に組み合わせたりするスキルが必要です。そのため、マイクロサービスの活用に精通した熟練者が1名以上必要です。\n\n### インターフェイス制御が難しい\n\nマイクロサービスの接点、つまりインターフェイスの制御が複雑になり、ときにマイクロサービスを利用する企業の悩みの種になります。各サービスには独自の[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)があるため、大規模なアプリケーションを開発する際には大量の[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)を同時に管理する必要があります。\n\n### エラーの特定や結合テストが複雑になる\n\nマイクロサービスでは、複数の開発が同時に行われるのに加え、サービスごとに異なる環境やコーディング規約で開発が行われているため、エラーの特定や修正に時間がかかる場合があります。\n\nまた、複数のサービス間で実施する結合テストは、各サービスのインターフェース設定を事前に行う必要があるため、より複雑で、時間がかかる傾向にあります。\n\n## サービス指向アーキテクチャ（Service-oriented architecture）とマイクロサービスの違い\n\nクラウドコンピューティングに携わっている方なら、サービス指向アーキテクチャ（SOA）とマイクロサービスの議論を耳にしたことがあるかもしれません。どちらも作業しやすいように小さなユニットに分割すること、またアジャイル開発のためのクラウドコンピューティングを必要とすることなど、類似点もたくさんあります。\n\nしかし、SOAは「できる限り共通性を持たせた上で細分化」するのに対し、マイクロサービスは「共通性よりも独立性を尊重している」という大きな違いがあります。例えばSOAでは、チーム内でできる限りリソースやコードを統一しようと努めます。一方でマイクロサービスは、それぞれの担当者が自分の得意なスキルセットを用いて開発することに重点を置きます。\n\n大規模なシステム開発会社が社内のリソースで大規模開発を行う際などにはSOAが優先されます。一方で、アウトソーシングや他社との連携を利用するなど、多様なヒストリーを持つ開発者が共同で開発を行う場合にはマイクロサービスが好まれます。\n\n考え方は非常によく似ていますが、開発に関する手法やコンセプトの点で違いがあるため、実施前にどちらが最適か、よく検討するとよいでしょう。\n\n## GitLabでマイクロサービスを利用する\n\nマイクロサービスアーキテクチャは、各サービスを必要に応じて組み合わせる開発手法により、開発会社が抱える様々な悩みを解決します。[GitLabは、マイクロサービスアーキテクチャにも対応](https://about.gitlab.com/ja-jp/topics/cloud-native/)していますので、マイクロサービス開発で使えるプラットフォームをお探しの方はぜひ検討してみてください。 \n\n*監修：伊藤 俊廷 [@toshitakaito](https://gitlab.com/toshitakaito) （GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト）*",[1190,1190,678],"2024-12-12",{"slug":3815,"featured":92,"template":681},"what-are-the-benefits-of-a-microservices-architecture","content:ja-jp:blog:what-are-the-benefits-of-a-microservices-architecture.yml","What Are The Benefits Of A Microservices Architecture","ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture.yml","ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture",{"_path":3821,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3822,"content":3828,"config":3835,"_id":3837,"_type":16,"title":3838,"_source":17,"_file":3839,"_stem":3840,"_extension":20},"/ja-jp/blog/ensuring-compliance",{"ogTitle":3823,"schema":3824,"ogImage":3825,"ogDescription":3826,"ogSiteName":1223,"noIndex":6,"ogType":1224,"ogUrl":3827,"title":3823,"canonicalUrls":3827,"description":3826},"GitLabで職務分離を実現し、コンプライアンスを遵守する方法","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabで職務分離を実現し、コンプライアンスを遵守する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Beatriz Barbosa\"},{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-04-04\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098232/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098232241.jpg","DevSecOpsプラットフォームを使用して開発速度を保ったまま、コンプライアンスを遵守しましょう。","https://about.gitlab.com/blog/ensuring-compliance",{"heroImage":3825,"body":3829,"authors":3830,"updatedDate":3832,"date":3833,"title":3823,"tags":3834,"description":3826,"category":722},"この記事では、GitLab DevSecOpsプラットフォームを使用して**職務分離**と\n\n**継続的なコンプライアンス**を実現するためのさまざまな方法についてご紹介します。まずは、2つの重要な概念について説明しましょう。\n\n\n**コンプライアンス**とは、企業や政府機関などが定めたガイドラインや規格に則って\n\n行動することです。コンプライアンスは、\n\n企業倫理や適切なユーザーポリシー、セキュリティ基準などを守り、\n\n消費者の安全を確保する上で役立ちます。\n\n\nコンプライアンスに違反した場合、裁判費用や罰金が発生する可能性があります。そのため、コンプライアンスを維持することは非常に重要です。DevSecOpsチームはコンプライアンスを遵守しつつ開発速度を維持し、さらにシンプルさや可視性、制御といった要件も満たす必要があります。\n\n\n**職務分離**とは、エラーの防止や不正行為の抑止を目的に、業務を複数の担当者で分担することです。職務分離を行うことで、その作業に最適な担当者が作業を実施する体制となります。たとえば以下のように、\n\nそれぞれの担当者が特定の目的のもとで業務を受け持ちます。\n\n\n* デベロッパーは新機能の開発を担当\n\n* コンプライアンス担当者はパイプラインの作成と使用の実施を担当\n\n* アプリケーションセキュリティエンジニアは脆弱性のあるマージリクエストの承認を担当\n\n\nこのように業務が分担されていれば、たとえばデベロッパーが実行中のパイプラインを変更することはできません。\n\nそのような業務を行えるのはコンプライアンス担当者のみであり、承認なしでプッシュできるのはコンプライアンスに準拠しているコードのみであることが保証されます。\n\n\n脆弱性のあるコードのレビューと承認を担当するアプリケーションセキュリティエンジニアは、適切な方法で脆弱性を軽減し、将来的に問題が発生しないようにします。このシナリオでは、コンプライアンス\n\nとセキュリティの要件が満たされるまでデベロッパーはコードをマージできません。\n\n\n## セキュリティポリシー\n\n\nGitLabの**セキュリティポリシー**を使用すれば、セキュリティチームは設定に従ってセキュリティスキャンが必ず実行されるように指定できます。これにより、セキュリティチームは、設定済みのスキャンが変更されたり無効化されたりしていないことを把握できます。\n\n\nセキュリティポリシーは、特定の**コンプライアンスフレームワーク**を満たすようにスコープを設定できます。この場合、プロジェクトには特定のコンプライアンス要件が適用されているため、追加で監視を行う必要があります。このラベルは、トップレベルグループの **「セキュア」>「コンプライアンスセンター」>「フレームワーク」** から作成できます。\n\n\n![コンプライアンスフレームワークラベル](https://about.gitlab.com/images/blogimages/compliance-04-2022/cf-step-2.png)\n\n\n**注**：コンプライアンスラベルは、ラベルを作成したトップレベルグループ内のプロジェクトにのみ割り当てられます。\n\n\nポリシーには、[スキャン実行ポリシー](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html)、[マージリクエスト承認ポリシー](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html)、[パイプライン実行ポリシー](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html)の3種類があります。\n\n\n* **スキャン実行ポリシー**：セキュリティスキャンが、あらかじめ設定したスケジュールに従って実行されるか、プロジェクトのパイプライン内で実行されるようにします。\n\n* **マージリクエスト承認ポリシー**：マージを実行する前にセキュリティチームによる承認を求めるなど、スキャン結果に基づいてアクションを実行します。\n\n* **パイプライン実行ポリシー**：対象のプロジェクトでCI/CDジョブを実施します。\n\n\nこれらのポリシーは、ポリシーエディタ上で簡単な手順で設定できます。\n\n\n### スキャンの実行\n\n\n1. **「セキュリティとコンプライアンス」 >「ポリシー」** の順に移動します。\n\n2. **「新しいポリシー」** ボタンをクリックして新規ポリシーを作成します。\n\n3. **「スキャン実行」** を選択します。\n\n4. ルールを作成します。例として、[SAST](https://docs.gitlab.com/ee/user/application_security/sast/)が設定されていなければパイプラインを実行できないようにするルールを作成します。\n\n\n```yaml\n\nname: force_sast\n\ndescription: 'require sast to run'\n\nenabled: true\n\nrules:\n\n- type: pipeline branches: - main actions:\n\n- scan: sast\n\n```\n\n\n5. マージリクエストを作成してからマージを実行し、ポリシーを送信します。\n\n\nすべてのスキャン実行ポリシーの変更は、10分ごとに実行されるバックグラウンドジョブを通じて適用されます。\n\n対象プロジェクトにコミットされたポリシーの変更が反映されるまで、最長で10分かかることがあります。\n\n\n6. パイプラインを実行してみてください。YAMLでSASTを定義していない場合、パイプラインは実行されません。\n\n\n**注**：タイマーを設定してSASTを強制的に実行することもできます。詳細はスキャン実行ポリシーの\n\n[ドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html)をご参照ください。\n\n\n### マージリクエストの承認\n\n\n1. **「セキュア」>「ポリシー」** の順に移動します。\n\n2. **「新しいポリシー」** ボタンをクリックして新規ポリシーを作成します。\n\n3. **「マージリクエスト承認ポリシー」** を選択します。\n\n4. ポリシーのスコープを定義します。\n\n5. ルールを作成します。\n\n\n![職務分離のための更新 - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098241214.png)\n\n\n6. 実行するアクションを追加します。\n\n\n![職務分離のための更新 - 画像2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098241215.png)\n\n\n**注**：ポリシーは設定したルールに従って評価されます。 そのため、ルールが無効であるか評価できない場合は、承認が必要となります。これを防ぐには、デフォルトのフォールバック動作フィールドを`open`に変更します。\n\n\n![職務分離のための更新 - 画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098241217.png)\n\n\n1. マージリクエストを作成してからマージを実行し、ポリシーを送信します。\n\n2. 脆弱性を含むマージリクエストを別途作成します。\n\n\n脆弱性の追加方法については、GitLab DevSecOpsワークショップの「デベロッパーワークフロー」セクションをご参照ください。\n\n\n3. マージリクエストを表示して、マージリクエスト承認ポリシーが使用されていることを確認します。\n\n\n### パイプライン実行ポリシー\n\n\nパイプライン実行ポリシーを設定するには、まず実行するCIファイルを含むプロジェクトを作成する必要があります。職務分離を確実にするため、セキュリティチームや管理者だけがアクセスできるように設定してください。例として、適用したいYAMLを含む「コンプライアンスとデプロイ」プロジェクトを作成しました。\n\n\n1. **「セキュア」>「ポリシー」** の順に移動します。\n\n2. **「新しいポリシー」** ボタンをクリックして新規ポリシーを作成します。\n\n3. **「パイプライン実行ポリシー」** を選択します。\n\n4. ポリシーのスコープを定義します。\n\n5. 実行するアクションを追加します。\n\n\n![職務分離のための更新 - 画像4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098241219.png)\n\n\n6. 条件を追加します。\n\n7. マージリクエストを作成してからマージを実行し、ポリシーを送信します。\n\n8. パイプラインを実行してみてください。パイプラインにポリシー固有のジョブとステージが表示されます。\n\n\n## 監査管理とコンプライアンスダッシュボード\n\n\nコンプライアンスを遵守する上でもうひとつ重要なのは、実際にグループやプロジェクト内で起きていることを把握することです。GitLabには、監査に対応するために監査イベントとコンプライアンスレポートが備わっています。\n\n\n**監査イベント**を使用すると、GitLabのオーナーと管理者は、特定のアクションを実行したユーザーや、そのアクションが行われた時間といった重要なイベントを追跡できます。\n\n\n![監査イベント](https://about.gitlab.com/images/blogimages/compliance-04-2022/project-audit-events.png)\n\n\n監査イベントはグループやプロジェクトごとにさまざまなイベントを記録するもので、[監査イベント](https://docs.gitlab.com/ee/administration/audit_events.html)のドキュメントで内容を\n\n確認できます。\n\n監査イベントには、**「セキュリティとコンプライアンス」>「監査イベント」**の順に移動してアクセスできます。\n\n以下はその一例です。\n\n\n* ユーザーがプロジェクトに追加され、権限が付与された\n\n* プロジェクトに割り当てられたユーザーの権限が変更された\n\n* プロジェクトにCI/CD変数が追加または削除された、または保護された状態が変更された\n\n* ユーザーがグループに追加され、権限が付与された\n\n* グループ名またはパスが変更された\n\n\n監査イベントは、監査イベントストリーミングを使用してHTTPエンドポイントに送信することもできます。監査イベントストリーミングの\n\n実装方法については、こちらの[動画](https://youtu.be/zHwVF9-i7e4?t=52)をご覧ください。\n\n\n**「基準遵守」**では、グループのマージリクエストアクティビティを確認できます。ここでは、グループ内のすべてのプロジェクトの概要が表示されます。\n\n\n![職務分離のための更新 - 画像5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098241222.png)\n\n\nこのレポートでは、次の情報を確認できます。\n\n\n* 各プロジェクトの最新のマージリクエストの概要\n\n* マージリクエストの承認ステータスや承認者\n\n* マージリクエストの作成者\n\n* 各マージリクエストの最新のCI/CDパイプライン結果\n\n\n基準遵守レポートは、トップレベルグループの **「セキュア」 >「コンプライアンスセンター」**にある**「基準遵守」** タブから確認できます。\n\n\n- - -\n\n\nここまでお読みいただきありがとうございました。GitLabでの職務分離について詳しくは、[GitLabによる継続的なソフトウェアコンプライアンス](/solutions/compliance/)をご参照ください。\n",[3831,1507],"Beatriz Barbosa","2025-07-15","2022-04-04",[1410,1411],{"slug":3836,"featured":6,"template":681},"ensuring-compliance","content:ja-jp:blog:ensuring-compliance.yml","Ensuring Compliance","ja-jp/blog/ensuring-compliance.yml","ja-jp/blog/ensuring-compliance",{"_path":3842,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3843,"content":3849,"config":3856,"_id":3858,"_type":16,"title":3859,"_source":17,"_file":3860,"_stem":3861,"_extension":20},"/ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices",{"title":3844,"description":3845,"ogTitle":3844,"ogDescription":3845,"noIndex":6,"ogImage":3846,"ogUrl":3847,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3847,"schema":3848}," CI/CDとは？ベストプラクティスやメリットも解説","CI/CDは高品質のアプリをスピーディに開発するのに最適です。注目度が高まるCI/CDとは何か、メリットやベストプラクティスについても説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661856/Blog/Hero%20Images/ci-cd-demo.jpg","https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \" CI/CDとは？ベストプラクティスやメリットも解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-02-03\",\n      }",{"title":3844,"description":3845,"authors":3850,"heroImage":3846,"date":3852,"body":3853,"category":3355,"tags":3854,"updatedDate":3855},[3851],"Valerie Silverthorne","2022-02-03","## 目次\n* CI/CDとは\n* CI/CDのメリット\n* CI/CDのベストプラクティス\n* CI/CDの成果を検討する方法\n* CI/CDパイプラインとは？\n* CI/CDツールの選び方\n* 多くの企業がGitLabのCI/CDを選ぶ理由とは？\n* 結論\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、高品質のアプリケーション・システム開発をよりスピーディに行うだけでなく、エラー削減やコストカットにも効果的です。しかしながら日本ではまだまだ知名度が低く、利用している企業は一握りというのが現状です。\n\n本記事では、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)とは何かについてわかりやすく解説するとともに、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットやベストプラクティスについて紹介します。\n\n## CI/CDとは\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、[継続的インテグレーション（Continuous Integration）](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)と継続的デリバリー（Continuous Delivery）の略称です。それぞれについて詳しく説明します。\n\n### CI（継続的インテグレーション）\n\n[CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)とは、開発者がコードを修正しそれをリポジトリにプッシュした際に、自動的にビルドやテストを実行するプロセスや仕組みのことです。[CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)によって継続的にテストを行うことで、コードの品質を高く保つことができます。\n\n### CD（継続的デリバリー）\n\nCDは、[CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)による統合や一体化をさらに拡張したもので、より高度にかつ自動的にシステムに変更が反映されるように設計された環境や概念を指します。\n\n### CI/CDの考え方\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、分割されているツールやプラットフォームを統合し、1つの変更が自動的に他ツールに反映されるように環境を組むことであり、アプリケーション開発の効率化を図ることです。ツールやプラットフォームを指すこともあれば、手法や概念として用いられることもあります。\n\n近年は著しい変化を伴う環境の中での開発が求められており、開発中に急に変更が生じることも多々あります。従来のウォーターフォール型の開発手法では急な変化に対応できず、常に変更とテストを繰り返しながら開発を進めていく[アジャイル開発](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)が主流となっています。\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、ビルド、テスト、デプロイ、インフラストラクチャのプロビジョニングなどを一体化し、これまで手動で実施していた介入のほとんどを自動化します。アジャイル開発や近年注目が集まる[DevOps](https://about.gitlab.com/ja-jp/platform/)とマッチしており、開発環境の改善を図りたい企業に積極的に採用されています。\n\n今後、よりスピーディで高品質の開発を進めていきたいのであれば、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)環境や考え方を積極的に取り入れていく必要があるでしょう。\n\n## CI/CDのメリット\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットは以下の通りです。\n\n* 制作物の品質が高まる\n* 開発スピードが向上する\n* ツール間のズレを予防できる\n* デベロッパーが開発に集中できる\n\n### 制作物の品質が高まる\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を利用することで、ソフトウェアやアプリなどの品質が高まります。\n\n従来であれば、最新のバージョンを適用するのに数時間もしくは数日かかるため、アップデートやツール追加などが容易に行えない状況がありました。\n\n一方[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、最新のコードやテクノロジー適用が容易です。開発環境を常に最新に保つことができるため、最先端・高品質の制作物が期待できます。\n\n### 開発スピードが向上する\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)はツール間で連携されており、入力情報が他ツールに自動的に適用されるため、作業量が必然的に少なくなります。これにより、開発スピードが格段に高まるとともに、急な変化にも対応しやすくなります。\n\n### 環境の差異による問題を予防できる\n\n複数の開発環境を利用する場合、環境ごとの仕様が原因でエラーが生じたり、セキュリティに問題が発生したりすることがありました。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、各ツールが自動的に連携されているため、環境の際による問題が予防でき、それによるエラーやセキュリティ問題が減少します。エラーが少なくなれば人的コストを大幅にカットできるため、予算削減にもつながります。\n\n### デベロッパーが開発に集中できる\n\nデベロッパーの仕事は「開発」です。しかしながら、実際にはエラーやバグの修正に追われ、開発に専念しづらい状況が発生しています。\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ではエラーが発生しにくいため、これまでエラー対応にあてていた時間を開発に注げるようになります。デベロッパーのエンゲージメントが向上し、長期にわたって貢献してくれる土台が作られます。\n\n## CI/CDのベストプラクティス\n\n新しく[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を導入する場合には、これから紹介するベストプラクティスを実施することで、効果をより高められます。\n\n### コードの品質を管理する\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、ビルド、テスト、デプロイまで、同じコードを用いて開発を進めていきます。そのため、初期でコードの間違いがあった場合には、それが後半まで影響を与えます。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、通常の開発以上に、コードの適切な利用が重要です。\n\nデベロッパー間で認識の違いが生じないように、コートレポジトリを適切に作成・管理してください。また、定期的にコードレビューを行うとともに、コードの変更を行う際にはレポジトリの書き換えも必ず行うようにしてください。\n\n### 初期は微調整を頻繁に行う\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、一度組織にフィットすると、開発スピード向上やエラー削減に大きく貢献します。しかしながら、新規に導入した[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)をいきなり組織にフィットさせることは稀です。多くの企業が、実践とフィードバックを繰り返しながら、自社に最適化させていくプロセスを経験しています。\n\nそのため、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を取り入れる際には、デベロッパーからの声を丁寧に拾い上げる仕組みを作り上げることが重要です。何に困っているのか、どの部分がうまく機能していないのかを確認しながら、必要に応じて[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を微調整していくことで、自社に真にマッチしたCI/CDへと改良されていきます。\n\n### 適切なセキュリティ対策を行う\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、ビルド、テスト、デプロイが1つの環境で行える一方で、情報が外部に漏れた場合には、制作物すべてに影響を及ぼす可能性があります。そのため、セキュリティ対策はより強固に行う必要があります。\n\nログイン情報を不特定多数に共有しないようにするとともに、ログイン時の認証を強化する、ツールは最小限に抑える、問題発生時のリスクマネジメントを決めておくなど、セキュリティ対策には力を入れるようにしてください。\n\n### 設定ファイルを再利用する\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、設定ファイルに記述されたコードを繰り返し利用することで、開発時間の短縮とエラーやバグの削減を可能にしています。しかしながら、デベロッパーの人数が増えると情報共有が上手くいかず、設定ファイルの情報を用いずに開発を進めてしまう場合があるようです。これでは、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットを最大限に活かせません。\n\n組織として、設定ファイルをどのように活用すべきかを明確化するとともに、見やすい場所に設置しておく、定期的に情報共有するなど、対策を図るようにしてください。\n\n### 気づいたエラーを放置しない\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、コードを複数箇所に自動的に反映させることで、高速化とエラー減を実現しています。しかしながら、もし初期に利用したコードにエラーがあった場合、それがその他の箇所にも影響を及ぼします。エラーに気づいたら、すぐに修正を図るようにしてください。\n\n### デプロイごとに本番前環境をクリーンアップする\n\n環境の実行期間が長くなるほど、適用されたすべての構成変更と更新を追跡することが難しくなります。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、デプロイごとに本番前環境をクリーンアップすることで、以前のデータが悪さするのを防げます。不要なファイルやデータ、一時ファイル、ログなどを毎回削除するようにしてください。\n\n## CI/CDの成果を検討する方法\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を導入した場合には、以下の項目を用いて、成果を適切に検討するようにしてください。\n\n### サイクルタイム\n\nサイクルタイムは、1つの作業の工程開始から完了までにかかる時間です。コードの書き始めからアプリ完成までの時間を計測し、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入の前後で比較します。ただし、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)に変更して初回のアプリ開発は当然時間がかかるため、ある程度慣れてきたころのサイクルタイムを用いて比較するようにしてください。\n\n### 作業時間\n\nデベロッパーが何にどのぐらいの時間を費やしているのかを記録、分析します。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)がうまく機能し始めると、問題の処理やツール間の調整にかかる時間が減り、メインとなる開発にかけられる時間が増えます。もしその傾向があるのならば、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットをうまく享受できていると考えてよいでしょう。\n\n### エラー率\n\nアプリケーション開発においてエラー発生は避けられません。しかしながら、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入前後でエラー率がどの程度変わったのかを追跡することには大きな意味があります。もし[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入後にもエラーが大量に発生している、もしくはエラー修正にかかる作業時間が削減されていない場合、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)がうまく機能していない可能性があるため、見直しが必要です。\n\n### インフラコスト\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入にかかる費用を適切に把握するとともに、パフォーマンスとコストを見比べ、導入が適切であったかどうかを検討します。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は様々なメリットがある反面、当然のことながらインフラストラクチャ構築費用がかかります。開発スピードやエラー率、人件費などを見比べながら、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入がコスト面からみて妥当かどうかを検討してください。\n\n### チームの声\n\n実際に作業を行うデベロッパーの声も大切な評価基準です。ツールが使いやすいか、実際にエラーが少なくなったと感じるか、デベロッパー同士の連携に問題ないかなどを質問することで、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)が開発者目線から見てどうかを把握できます。\n\n## CI/CDパイプラインとは？\n\nパイプラインは特定のものをつなぐパイプです。例えば、AとBという別のものがある場合、パイプラインがない場合にはそれぞれが独立して機能します。一方、AとBがパイプで結ばれている場合、AとBがそれぞれ干渉しあい、影響し合うことで様々なメリット・デメリットを生み出します。\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、様々なステージや環境、ツールなどをパイプラインで結ぶことで自動化を図り、作業の効率化やエラーの削減、アップデートの容易化などを図ります。例えば、通常であればそれぞれ独立している「ビルド」「テスト」「デプロイ」の各ステージをパイプラインで結び付けることで、特定の変更が他のステージにおいても自動的に反映されます。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインは、CI/CDが効果を発揮する上での核となる考え方や構造です。\n\nこのパイプラインが正しく機能しているプラットフォームやツールを利用することで、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットを最大限に享受できます。\n\n一方で、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインがうまく機能しない場合、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)の恩恵を受けられないばかりか、エラーが増えたり、余計に時間がかかったりする場合があります。そのため、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールの選定は慎重に行う必要があります。\n\n## CI/CDツールの選び方\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を導入する目的は、開発サイクル全体にわたって包括的なフィードバックを提供しながら、正確で信頼性の高い製品を迅速に生成することです。そのため、正確性、信頼性、速度の面で優れた[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールを探す必要があります。\n\nまた、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールの導入は、デベロッパーにとって大きな変化になるのに加え、インフラコストも発生します。そのため、環境をいきなり変えてしまうのではなく、まずは無料トライアルがある[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールを利用し、使用感を確認するようにしてください。\n\nGitLabでは、優れた性能の[CI/CDパイプライン](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を提供しています。[無料トライアル](https://about.gitlab.com/free-trial/)も受け付けているため、お気軽にお問い合わせください。\n\n## 多くの企業がGitLabのCI/CDを選ぶ理由とは？\n\n多くの[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールは、CIとCDを別々のツールで管理し、それを結びつけることでCI/CDを実現しています。一方、GitLabは長年の[DevOpsプラットフォーム](https://about.gitlab.com/ja-jp/platform/)の提供経験をもとに、ビルドーテストーデプロイが一体となった[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールの提供を行っています。\n\nGitLabツールであれば、他社のツールとの結合を一切考慮することなく、すべて[1つのツール内で完結](https://about.gitlab.com/ja-jp/devsecops/)できます。\n\n## 結論\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、近年重要性が高まっているアプリケーション開発のスピーディ化を実現するために非常に重要です。日本ではまだまだ導入企業が少ないものの、世界ではスタンダードになりつつあります。もし世界水準での開発環境を整えたければ、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールの導入を少しでも早く検討するとよいでしょう。\n\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*",[1410,1411,1190],"2024-11-06",{"slug":3857,"featured":6,"template":681},"how-to-keep-up-with-ci-cd-best-practices","content:ja-jp:blog:how-to-keep-up-with-ci-cd-best-practices.yml","How To Keep Up With Ci Cd Best Practices","ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices.yml","ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices",{"_path":3863,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3864,"content":3870,"config":3877,"_id":3879,"_type":16,"title":3880,"_source":17,"_file":3881,"_stem":3882,"_extension":20},"/ja-jp/blog/demystifying-ci-cd-variables",{"title":3865,"description":3866,"ogTitle":3865,"ogDescription":3866,"noIndex":6,"ogImage":3867,"ogUrl":3868,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3868,"schema":3869},"GitLabの環境変数をわかりやすく解説","CI/CD変数はジョブやパイプラインを制御するのに便利（かつ柔軟に利用可能）なツールです。この記事では、GitLabの環境変数について知っておくべき情報をすべてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664679/Blog/Hero%20Images/blog-image-template-1800x945__24_.png","https://about.gitlab.com/blog/demystifying-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabの環境変数をわかりやすく解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2021-04-09\",\n      }",{"title":3865,"description":3866,"authors":3871,"heroImage":3867,"date":3873,"body":3874,"category":672,"tags":3875,"updatedDate":3876},[3872],"Veethika Mishra","2021-04-09","[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)変数は、さまざまな方法で定義・使用でき、高い柔軟性を持っています。変数はジョブやパイプラインを制御する上で非常に便利で、`.gitlab-ci.yml`設定ファイルに値をハードコーディングせずに済みます。このブログ記事では、変数のスコープや機能を分かりやすくお伝えするため、変数の定義や使い方に関する情報を網羅的に整理し、全体像をご紹介します。記事全体をとおして、関連するドキュメントがリンクされています。\n\n\n[GitLab\nCI/CD](https://docs.gitlab.com/ee/ci/)では、値を定義して保存することで、変数を使用してジョブをカスタマイズできます。変数を使用すれば、値をハードコーディングする必要はありません。GitLabでCI/CD変数を定義するには、**「設定」>>「CI/CD」>>「変数」**の順に移動します。または`.gitlab-ci.yml`ファイルで定義することも可能です。\n\n\n変数は、異なるデプロイ環境（`testing`、`staging`、`production`など）におけるサードパーティサービスの設定に役立ちます。それらの環境に紐づけられたサービスは、必要なAPIエンドポイントを指す変数を変更するだけで、簡単に変更できます。また、変数を使用してジョブを設定し、ジョブ実行時にジョブ内で環境変数として利用できるようにすることも可能です。\n\n\n![GitLabは、.gitlab-ci.ymlファイルを読み込んで、参照される変数をスキャンし、GitLab\nRunnerにその情報を送信します。変数情報はRunnerに渡され、Runnerによって出力されます。](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_processing.jpeg)\n\n\n## 変数と環境の関係\n\n\nソフトウェア開発プロセスには、製品をユーザー向けにリリースする前にテストするステージが含まれます。[環境](https://docs.gitlab.com/ee/ci/environments/)は、これらのステージの内容を定義するために使用されるもので、チームや組織によって異なる可能性があります。\n\n\n一方、変数とは、ユーザーによる製品の操作によって変化する可能性のあるデータ値を指します。これには、年齢や好み、またはタスクフローにおける次のステップを決定する要素となるあらゆる入力が該当します。\n\n\n[環境変数](https://docs.gitlab.com/ee/administration/environment_variables.html)という言葉は、皆さんもよく耳にされると思います。これは、ある環境で定義されているものの、アプリケーションの外部に存在する変数を指します。GitLab\nCI/CD変数を使用すると、デベロッパーはコード内で値を設定できます。変数の使用には、コードの柔軟性が保証されるという利点があります。GitLab\nCI/CD変数を使用すれば、コードに変更を加えることなく、特定の環境にデプロイされたアプリケーションを変更できます。これにより、アプリケーションの外部で設定の環境変数を変更するだけで、テストの実行やサードパーティサービスの統合を簡単に行えます。\n\n\n## CI/CD変数のスコープ\n\n\n![CI/CD変数の優先順位：1) 手動によって実行、トリガー、スケジュールされたパイプライン変数、2)\nプロジェクトレベル、グループレベル、インスタンスレベルの保護変数、3) 継承されたCI/CD変数、4)\nymlに定義された、ジョブレベルのグローバル変数、5) デプロイ変数、6)\n定義済みのCI/CD変数](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_precedence.jpeg)\n\n\n### `.gitlab-ci.yml`に定義された変数\n\n\nGitLabには、ジョブ環境で利用する必要がある変数を追加できます。これらのCI/CD変数は、`.gitlab-ci.yml`ファイルのデータベースURLのような、機密性の低いプロジェクト設定を保存するために使用されます。この変数は、複数のジョブやスクリプトで再利用でき、必要な場所で値を参照できます。値を変更する場合は、変数を一度更新するだけで、変数が使用されているすべての箇所に変更が反映されます。\n\n\n### プロジェクトのCI/CD変数\n\n\nリポジトリ固有の要件に縛られることなく、[プロジェクト設定](https://docs.gitlab.com/ee/ci/variables/#for-a-project)でCI/CD変数を定義できます。これにより、CI/CDパイプラインで利用できるようになります。これらの変数は、リポジトリの外部（`.gitlab-ci.yml`ファイルには保存されません）に保存されますが、CI/CDの設定やスクリプトで引き続き利用可能です。変数を`.gitlab-ci.yml`ファイル外に保存することで、これらの値のスコープをプロジェクト内のみに限定し、プロジェクトにプレーンテキストとして保存されることを防ぎます。\n\n\n### グループおよびインスタンスのCI/CD変数\n\n\n一部の変数は、グループレベル、あるいはインスタンスレベルで適用でき、グループやインスタンス内のすべてのプロジェクトで有用となる可能性があります。[グループまたはインスタンス設定](https://docs.gitlab.com/ee/ci/variables/#for-a-group)で変数を定義することで、それらのスコープ内にあるすべてのプロジェクトにおいて、実際の値がわからなくても、変数を使用できるようになります。下位スコープの変数を作成する必要もありません。たとえば、複数のプロジェクトにおいて更新が必要な共通の値がある場合、1か所で最新の状態に保つことで管理しやすくなります。また、パスワードの値を実際に知らなくても、複数のプロジェクトで特定のパスワードを使用することも可能です。\n\n\n## 環境としてのジョブとパイプライン\n\n\nGitLab\nCI/CDの変数は、環境変数としてだけでなく、`.gitlab-ci.yml`設定ファイル内でパイプラインの動作を設定するためにも使用されます。この場合、特定の環境に依存しない状況でも利用できます。また、プロジェクト、グループ、インスタンスの設定に保存しておくことで、パイプライン内のジョブで利用可能になります。\n\n\n以下に例を示します。\n\n\n```  \n\njob:  \n  rules:  \n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  \n  script:  \n  - echo \"This job ran on the $CI_COMMIT_BRANCH branch.\"  \n```\n\n\nスクリプトセクション内で使用されている変数（例：`$CI_COMMIT_BRANCH`）は、定義されたジョブのスコープ内で実行されます。このスコープは「ジョブ環境」と呼ばれます。つまり、ジョブが開始されると、GitLab\nRunnerはDockerコンテナを起動し、その環境でジョブを実行します。Runnerはその変数（および他のすべての定義済み変数やカスタム変数）をジョブに提供します。さらに、その値をログ出力に表示することも可能です。\n\n\nただし、この変数は、ジョブの実行タイミングを決定するために、`if:`セクション**でも**使用されます。ただし、そのセクション自体は環境ではないため、これらの変数を「CI/CD変数」と呼びます。CI/CDジョブを動的に設定する際に使用できるのは**もちろん**、ジョブの実行時に環境変数としても利用できます。\n\n\n## 定義済み変数\n\n\nGitLab\nCI/CDパイプラインが開始されたタイミングで、[定義済み変数](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)がすでに存在します。ユーザーは変数自体を定義せずに、コミットやプロジェクト、パイプラインの詳細などの値にすぐにアクセスできます。\n\n\n## カスタムCI/CD変数\n\n\n![Runnerは、2種類のカスタムCI/CD変数（タイプとファイル）を作成できます。](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variable_types.jpeg)\n\n\nGitLabでは、設定でCI/CD変数を作成する際に、変数に対してより詳細な設定オプションを利用できます。次のような追加の設定オプションを使用して、機密性の高い変数をより厳密に管理することが可能です。\n\n\n**環境スコープ**：ある変数を特定の環境でのみ使用する必要がある場合に、その環境でのみ使用できるように設定します。たとえば、デプロイトークンを`production`環境でのみ使用できるように設定できます。\n\n\n**保護変数**：環境スコープと同様に、デフォルトブランチなどの保護ブランチでパイプラインが実行される場合にのみ、変数を使用できるように設定できます。\n\n\n**変数タイプ**：一部のアプリケーションでは、設定をファイル形式で渡す必要があります。そうした設定が必要なアプリケーションを利用する場合は、変数タイプを「File」に設定します。この方法でCI/CD変数を設定する場合、Runnerが環境内で変数を利用できるようにする際に、実際に一時ファイルに変数を書き出し、そのファイルパスを変数の値として保存します。その後、アプリケーションに必要なファイルパスを渡すことで設定が適用されます。\n\n\nご紹介した変数の定義方法や使用方法に加えて、GitLabでは、手動でパイプラインを実行する必要がある場合に、事前入力済みの変数を生成する機能が導入されました。事前入力済みの変数が生成されることで、エラーの発生リスクが軽減され、パイプラインを実行しやすくなります。\n\n\n**マスクされた変数**：[マスクされた変数](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable)は、変数の値が表示されないように**ジョブログに隠された**CI変数です。\n\n\n**マスクおよび非表示化された変数**：[GitLab\n17.4](https://about.gitlab.com/ja-jp/blog/gitlab-17-4-released/)で導入された[マスクおよび非表示化された](https://docs.gitlab.com/ee/ci/variables/#hide-a-cicd-variable)変数は、ジョブログと同じマスキング機能を利用し、**設定UI**でも**値を非表示**にします。これらの変数を機密データ（シークレットなど）に使用した場合、誤って公開されてしまう可能性があるため、推奨されません。\n\n\n## シークレット\n\n\nシークレットとは、機密性が高く、秘密に保つべき認証情報のことを指し、以下のようなものが該当します。\n\n\n* パスワード\n\n* SSH鍵\n\n* アクセストークン\n\n* その他、漏洩すると組織に害を及ぼす可能性のある認証情報\n\n\nGitLabでは現在、キーやトークン、その他のシークレットをプロジェクトレベルで安全に管理するために、HashiCorp Vault、Google\nCloud Secret Manager、Azure Key\nVaultを活用できます。これにより、[CIで外部シークレットを使用](https://docs.gitlab.com/ee/ci/secrets/)することが可能です。そのため、セキュリティ上の理由から、これらのシークレットを他のCI/CD変数から分離して管理できます。\n\n\n### GitLabシークレットマネージャー\n\n\nGitLabでは、CIにおける外部シークレットのサポートに加えて、GitLab内でシークレットを安全かつ便利に保存するための[ネイティブなシークレット管理ソリューション](https://gitlab.com/groups/gitlab-org/-/epics/10108)の導入にも取り組んでいます。このソリューションは、お客様がGitLab固有のコンポーネントや環境で保存されたシークレットを使用したり、ネームスペースグループやプロジェクトレベルでのアクセスを簡単に管理したりする上でも役立ちます。\n\n\n## 関連リンク\n\n*\n[GitLabネイティブシークレットマネージャーでソフトウェアサプライチェーンのセキュリティを強化](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/)\n\n\n***免責事項**：このブログには、今後リリース予定の製品、機能、および機能性に関する情報が記載されています。ただし、それらの情報はあくまで参考のために提供されているため、購入や計画の判断材料として使用することはお控えください。すべてのプロジェクトと同様に、このブログおよびリンク先のページに記載されている項目は、変更または遅延される場合があります。製品、機能、機能性の開発、リリース、およびタイミングに関する決定権は、GitLabに帰属します。*\n",[1411,678,1880,1410,110,676],"2025-01-13",{"slug":3878,"featured":6,"template":681},"demystifying-ci-cd-variables","content:ja-jp:blog:demystifying-ci-cd-variables.yml","Demystifying Ci Cd Variables","ja-jp/blog/demystifying-ci-cd-variables.yml","ja-jp/blog/demystifying-ci-cd-variables",{"_path":3884,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3885,"content":3890,"config":3897,"_id":3899,"_type":16,"title":3900,"_source":17,"_file":3901,"_stem":3902,"_extension":20},"/ja-jp/blog/ci-deployment-and-environments",{"config":3886,"ogImage":3887,"description":3888,"title":3889},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749662033/Blog/Hero%20Images/intro.jpg","GitLab CI の多様性とパワーをAWS(S3)を例に学び、デプロイに活かせる開発力を身に着けましょう。","GitLab CIを使って複数の環境にデプロイする方法 | GitLab",{"heroImage":3887,"body":3891,"authors":3892,"updatedDate":882,"date":3894,"title":3895,"tags":3896,"description":3888,"category":672},"いくつかのシナリオを通じて、[GitLab\n\n\nCI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)\n\n\nが持つ多様性と強みをご紹介します。\n\n\n\nこの投稿は、ある架空のニュースポータルのサクセスストーリーです。あなたは、そのポータルの所有者かつエディターで、唯一の開発者でもあります。プロジェクトコードは既に GitLab.com でホストされており、GitLab CI/CD で[テストを実行する (英語版)](https://docs.gitlab.com/ee/ci/testing/)こともできます。ここであなたは考えます。これを[デプロイに使う (英語版)](https://about.gitlab.com/blog/2022/02/03/how-to-keep-up-with-ci-cd-best-practices/)ことはできないだろうかと。そして、どこまで活用できるのだろう、と。\n\n\n\nこのサクセスストーリーを技術スタックに依存しないものにするために、このアプリは単なるHTML ファイルを集めたものだと仮定しましょう。サーバー側のコードも、高度な JavaScript のコンパイルもないものとします。\n\n\n\nデプロイ先のプラットフォームも単純なものにしましょう。ここでは、「[Amazon S3](https://aws.amazon.com/jp/s3/)」を使います。\n\n\n\nこの記事の目的は、コピー＆ペースト可能なスニペットを数多く紹介することではありません。[GitLab CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/) の基本原理や各種機能をご紹介し、それを現場の技術スタックに簡単に適用できるようにすることが目的です。\n\n\n\nそれでは、はじめましょう。このストーリーには、まだ、継続的インテグレーション (CI) は登場しません。\n\n\n\n\n\n## 最初のステップ\n\n\n\n**デプロイ**：今回、「デプロイ」とは、一連の HTML ファイルが ([静的な Web サイトホスティング ](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/HostingWebsiteOnS3Setup.html)用に設定済み) S3 バケット上に表示されることを意味します。\n\n\n\nこれを実現する方法は無数にあります。ここでは、Amazon から提供されている[ awscli ライブラリ (英語版)](http://docs.aws.amazon.com/cli/latest/reference/s3/cp.html#%E4%BE%8B) を使います。\n\n\n\nコマンドは、全体ではこのようになります。\n\n\n\n```shell\n\n\naws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n\n\n```\n\n\n\n![Manual deployment](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/13.jpg){: .center}\n\n\n\nリポジトリへのコードのプッシュと、デプロイは別々のプロセスです。\n\n\n\n{: .note .text-center}\n\n\n\n重要なポイント：このコマンドは、2 つの環境変数`AWS_ACCESS_KEY_ID` と  `AWS_SECRET_ACCESS_KEY` の指定を[コードデベロッパーが行なうものと想定](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence)しています。また、\n\n\n\n重要なポイント：このコマンドは、2 つの環境変数 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY の指定を[コードデベロッパーが行なうものと想定](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence)しています。また、`AWS_DEFAULT_REGION` も指定する必要があるかもしれません。\n\n\n\nでは、[GitLab CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/) を使って自動化してみましょう。\n\n\n\n\n\n\n## **はじめての自動化デプロイ**\n\n\n\nGitLab では、どのコマンドを実行しても違いはありません。GitLab CI はユーザーの具体的なニーズに合わせて、あたかもコンピュータ上のローカルターミナルで操作している感覚でセットアップできます。ここで実行するコマンドをGitLabにも実行させるよう、CI に指定可能です。 `.gitlab-ci.yml`ファイルにスクリプトを記述し、コードをプッシュするだけです。これで、CI がジョブをトリガーし、指定コマンドが実行されます。\n\n\n\nでは、ここでストーリーにもう少し肉付けをしましょう。私たちの Web サイトは小規模で、1日あたり 20～30 人の訪問者がいるだけです。コードリポジトリには`main` という1つのデフォルトブランチ (があるものとします。\n\n\n\nそれでは、 `.gitlab-ci.yml` ファイルに、先程のコマンドを使った*ジョブ*を指定することから始めましょう。\n\n\n\n```yaml\n\n\ndeploy:\n  script: aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\n\nうまくいかないようです：\n\n\n\n![Failed command](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/fail1.png){: .shadow}\n\n\n\n実行ファイルには`aws` が必要です。これを確認するのは、私たちの*ジョブ*です。`awscli` をインストールするには、pipが必要です。これは、Pythonパッケージのインストール用のツールです。では、Pythonが事前にインストール済みのDockerイメージを指定しましょう。これには`pip` が含まれているはずです。\n\n\n\n\n\n\n```yaml\n\n\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\n\n![Automated deployment](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/14.jpg){: .center}\n\n\n\nGitLab にコードをプッシュすると、CI により自動的にデプロイされます。awscli のインストールによりジョブの実行時間が伸びますがこの時点ではそれほど問題ではありません。プロセスを高速化する場合、awscliが事前にインストールされた [Docker イメージを探す (英語版)](https://hub.docker.com/)  ことが可能です。または、イメージをご自身で作成しても構いません。\n\n\n\nここで、[AWS コンソール (英語版) ](https://console.aws.amazon.com/)から取得した環境変数を忘れないでください。\n\n\n\n\n\n\n```yaml\n\n\nvariables:\n  AWS_ACCESS_KEY_ID: \"AKIAIOSFODNN7EXAMPLE\"\n  AWS_SECRET_ACCESS_KEY: \"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\"\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\n\n今回は上手くいくはずですが、シークレットキーをオープンにしたままにすることは、プライベートリポジトリであってもよくありません。ではどうすればよいのか、もう少し見てみましょう。\n\n\n\n### **シークレット事項を守り抜くために**\n\n\n\nGitLab にはシークレット変数用に特別な項目があります:  **Settings（設定） > CI/CD > Variables（変数）**\n\n\n\n![Picture of Variables page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/add-variable-updated.png)\n\n\n\nここに入力したものすべてが**環境変数**になります。「Visibility（表示レベル）」の「Masked（マスクする）」ラジオボタンをオンにすると、ジョブログ内で変数がマスクされます。「Protect variable（変数の保護）」チェックボックスにチェックを入れると、変数は保護されているブランチやタグ上で実行されているパイプラインにのみ、エクスポートされます。プロジェクトの「オーナー」や「メンテナー」の権限を持つユーザーが、このセクションにアクセスできます。\n\n\n\nCI 設定から、variables セクションを削除することも可能ですが、別の目的で使用してみましょう。\n\n\n\n\n\n\n### **シークレットではない変数を指定して使用する方法**\n\n\n\n構成が大きくなる場合、初期段階で、いくつかのパラメータを変数として設定しておくと便利です。これは特に、パラメータを複数の場面で使用する場合に便利です。今回のケースではまだそのような状況ではありませんが、デモとして、S3 バケット名を **[variable](https://docs.gitlab.com/ee/ci/variables/)** に設定してみましょう。\n\n\n\n```yaml\n\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\n\nここまで、順調ですね。\n\n\n\n![Successful build](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/build.png){: .shadow.medium.center}\n\n\n\nこの架空シナリオでは、Web サイトの訪問者数が増えたため、開発者を雇いました。これでチームができました。チームワークにより、[GitLab CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/) ワークフローがどのように変化するのか、見てみましょう。\n\n\n\n\n\n\n## **GitLab CIをチームで使う方法**\n\n\n\n同一のリポジトリで 2 人が作業をするようになったため、開発に main ブランチを使うのは得策ではなくなりました。そこで、新規機能や新規記事ごとに異なるブランチを使うことにし、準備ができたら、main ブランチにマージする、ということに決めました。\n\n\n\nここで問題があります。現行の CI 設定は、ブランチをまったく考慮していない、という点です。GitLab に何かをプッシュするたびに、S3 にデプロイされてしまいます。\n\n\n\nこの問題は簡単に回避できます。deploy するジョブに、only: main を追加するだけです。\n\n\n\n\n\n\n![Automated deployment of main branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/15-updated.png){: .center}\n\n\n\n本番の Web サイトに、すべてのブランチをデプロイしたくありませんが、フィーチャーブランチからの変更点を何らかの方法でプレビューできたら嬉しいですね。\n\n\n\n\n\n\n{: .note .text-center}\n\n\n\n### **コードのテスト用に別の場所を設定する方法**\n\n\n\n最近雇った人 (ここでは「パトリック」と呼びましょう) が、GitLab には[ GitLab Pages (英語版)](https://about.gitlab.com/stages-devops-lifecycle/pages/) という機能がある、と教えてくれました。作業中のコードをプレビューする場所にもってこいです。\n\n\n\n[GitLab Pagesで Web サイトをホストする (英語版) ](https://about.gitlab.com/blog/2016/04/07/gitlab-pages-setup/) には、CI 設定ファイルが 次の3 つのシンプルなルールを満たしている必要があります。\n\n\n\n* ジョブはpagesと名付けなければならない\n\n\n* artifacts セクションがあり、その中に public フォルダを作成しなければならない\n\n\n* ホストしたいすべてのファイルは、このpublic フォルダ内に置かなければならない\n\n\n\npublic フォルダの中身は、http://\u003Cusername>.gitlab.io/\u003Cprojectname>/でホストされます。\n\n\n\nプレーン[ HTML Web サイト用の設定例](https://gitlab.com/pages/plain-html/blob/master/.gitlab-ci.yml)を適用した後は、CI設定全体はこのようになります。\n\n\n\n\n\n\n```yaml\n\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n  only:\n  - main\n\npages:\n  image: alpine:latest\n  script:\n  - mkdir -p ./public\n  - cp ./*.html ./public/\n  artifacts:\n    paths:\n    - public\n  except:\n  - main\n```\n\n\n\n2 つのジョブを指定しました。1つは、顧客用に Web サイトを S3 にデプロイします (deploy)。もう1つのジョブ (pages) は、Web サイトを GitLab Pages にデプロイします。2 つのジョブは、それぞれ「本番環境」と「ステージング環境」と呼びます。\n\n\n\n\n\n\n![Deployment to two places](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/16-updated.png){: .center}\n\n\n\nマスター以外の全ブランチが GitLab Pages にデプロイされます。\n\n\n\n\n\n\n{: .note .text-center}\n\n\n\n## **環境の導入**\n\n\n\nGitLab は[ 環境へのサポート (英語版)](https://docs.gitlab.com/ee/ci/environments/) (動的環境および静的環境を含む) を提供しているため、ユーザーは、各デプロイジョブに対応する環境を指定するだけで済みます。\n\n\n\n```yaml\n\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy to production:\n  environment: production\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n  only:\n  - main\n\npages:\n  image: alpine:latest\n  environment: staging\n  script:\n  - mkdir -p ./public\n  - cp ./*.html ./public/\n  artifacts:\n    paths:\n    - public\n  except:\n  - main\n```\n\n\n\nGitLab はユーザーのデプロイを追跡するため、サーバー上で何がデプロイされているのかを常に把握できます。\n\n\n\n![List of environments](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/envs-updated.png){: .shadow.center}\n\n\n\nGitLab は現在の環境のそれぞれについて、デプロイの完全履歴を提供してくれます。\n\n\n\n\n\n\n![List of deployments to staging environment](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/staging-env-detail-updated.png){: .shadow.center}\n\n\n\n![Environments](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/17-updated.png){: .center}\n\n\n\nすべてが自動化され、セットアップも完了です。これで、新しい課題にチャレンジする準備が整いました。\n\n\n\n## **デプロイのトラブルシューティング方法**\n\n\n\nまた、同じことが起きました。ステージング環境で自分のフィーチャーブランチをプレビューするためにプッシュした 1 分後、パトリックが彼のブランチをプッシュしたのです。ステージング環境はパトリックの作業内容で上書きされてしまいました。大変です。今日で 3 回目です。\n\n\n\nそこで、アイデアが浮かびました。Slackを使ってデプロイを通知するようにすれば、デプロイが完了した時に、コンテンツを別の人がプッシュしてしまうことがなくなります。\n\n\n\n\n\n\n> [GitLabとSlackを連携する方法はこちら](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html)\n\n\n\n## **規模に応じたチームワーク**\n\n\n\n時は過ぎ、Web サイトの人気は非常に上がり、チームも 2 人から 8 人に増えました。チームメンバーは同時進行で開発を行うため、「ステージング」でプレビューを待ち合うことが多くなってきました。「ステージングに対してすべてのブランチをデプロイする」という方針はうまくいかなくなってしまったのです。\n\n\n\n\n\n\n![Queue of branches for review on Staging](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/queue.jpg){: .center}\n\n\n\nもう一度、プロセスを見直す時がきました。誰かがステージングサーバー上でコードへの変更内容を確認したいときは、まず「ステージング」ブランチに変更内容をマージする、ということにチームで同意しました。\n\n\n\n.gitlab-ci.yml への変更は最小限に抑えられます。\n\n\n\n```yaml\n\n\nexcept:\n\n\n\n- main\n\n\n```\n\n\n\nを次のように変更します：\n\n\n\n```yaml\n\n\nonly:\n\n\n\n- staging\n\n\n```\n\n\n\n![Staging branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/18-updated.png){: .center}\n\n\n\nステージングサーバー上でプレビューを行なう前に、フィーチャーブランチをマージしなければなりません。\n\n\n\n{: .note .text-center}\n\n\n\nもちろん、これによりマージに追加の時間や労力がかかりますが、待機するよりは良い、ということで全員が同意しました。\n\n\n\n### **緊急時の対応**\n\n\n\nすべてを制御することは不可能です。そのため、時として何かがうまくいかないこともあります。誰かがブランチを誤った方法でマージしてしまい、あなたのサイトが HackerNews のトップに載ったタイミングで、本番環境に直接プッシュしてしまいました。何千人もの人が、輝かしいメインページの代わりに、完全に崩れたレイアウトを目撃してしまったのです。\n\n\n\nしかし幸運なことに、「**ロールバック**」ボタンを見つけた人がいたため、問題発覚 1 分後に、Web サイトは修正されました。\n\n\n\n\n\n\n![List of environments](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/prod-env-rollback-arrow-updated.png){: .shadow.center}\n\n\n\n「ロールバック」により、1つ前のコミットでの1つ前のジョブが再起動されます\n\n\n\n\n\n\n{: .note .text-center}\n\n\n\nとにかく、この問題に対応する必要があると感じたため、本番環境への GitLab 自動デプロイを停止して、手動デプロイに切り替えることにしました。そのためには、ジョブに when: manual を追加する必要があります。\n\n\n\n予想通り、その後は「本番環境」への自動デプロイは行なわれなくなりました。手動でデプロイするには、**CI/CD > Pipelines（パイプライン）** に移動し、下図にあるボタンをクリックします。\n\n\n\n\n\n\n![Skipped job is available for manual launch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/manual-pipeline-arrow-updated.png){: .shadow.center}\n\n\n\n時間を早送りしましょう。ついに、あなたの組織は法人化されました。Web サイトに取り組んでいる人も数百人になり、これまでの妥協策はもう通用しません。\n\n\n\n### **「Review Apps」の出番です**\n\n\n\n次にすべき論理的なステップは、レビュー用に、フィーチャーブランチごとにアプリケーションの一時インスタンスを起動することでしょう。\n\n\n\nここでは、そのために S3 上に別のバケットをセットアップします。ただ一つ違うところは、開発ブランチの名前で Web サイトのコンテンツを「フォルダ」にコピーする点です。URL は次のようになります。\n\n\n\nhttp://\u003CREVIEW_S3_BUCKET_NAME>.s3-website-us-east-1.amazonaws.com/\u003Cbranchname>/\n\n\n\n前に使った pages ジョブを次のコードで置き換えます。\n\n\n\n\n\n\n```yaml\n\n\nreview apps:\n  variables:\n    S3_BUCKET_NAME: \"reviewbucket\"\n  image: python:latest\n  environment: review\n  script:\n  - pip install awscli\n  - mkdir -p ./$CI_BUILD_REF_NAME\n  - cp ./*.html ./$CI_BUILD_REF_NAME/\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\n\n興味深いのは、$CI_BUILD_REF_NAME という変数がどこからきたか、という点です。GitLab は [多くの環境変数 (英語版)](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) があらかじめ定義されています。そのため、ジョブではすぐ変数が使えます。\n\n\n\nここでご注意いただきたいのは、S3_BUCKET_NAME 変数はジョブ内で定義している、ということです。トップレベルの定義を再定義するとき、これを行ないます。\n\n\n\n\n\n\n\n\n{: .alert .alert-info}\n\n\n\nこの構成を視覚的にわかりやすく描くと、次のようになります。\n\n\n\n\n\n![How to use GitLab CI - update - 19 - updated](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/19-updated.png){: .illustration}\n\n\n\n\n\n「Review Apps」の実装の詳細は、実際に現場で使っている技術スタックやデプロイプロセスなどにより大きく異なります。そのため、このブログ記事では詳細をカバーできません。\n\n\n\n現実は、この静的な HTML Web サイトのように簡単ではないのです。例えば、あるインスタンスを一時インスタンスにして、必要なソフトウェアやサービスを即座に、自動的に起動させることは簡単な作業ではありません。しかし、特に Docker コンテナ、または Chef や Ansible を使えば実現可能です。\n\n\n\nDocker を使ったデプロイについては、今後のブログ記事で取り上げます。GitLab デプロイプロセスをシンプルな HTML ファイルのコピーに単純化し、より複雑なシナリオにしなかったことに対して、少々後めたい気持ちがあります。複雑なシナリオを知りたい方は、「Building an Elixir Release into a Docker image using GitLab CI (英語版のみ：[GitLab CI を使用して、Elixir リリースを Docker イメージにビルドする)」 をご覧ください](https://about.gitlab.com/blog/2016/08/11/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/)。\n\n\n\nさて、記事に戻ります。最後の点について、お話しましょう。\n\n\n\n\n\n\n### **異なるプラットフォームへの GitLab デプロイ**\n\n\n\n現実は、S3 や GitLab Pages だけに限定されるものではありません。GitLab はまざまなサービスにアプリやパッケージをホストし、デプロイしています。\n\n\n\nさらに、ある時点で、新しいプラットフォームへの移行を決定し、デプロイスクリプトをすべて書き直す必要が生じるかもしれません。そういった場合のダメージを最小限に抑えるために、dpl という Gem を使えます。\n\n\n\n上の例では、サービス (Amazon S3) へのコードのサンプルツールとして awscli を使用しました。しかし、どのツールを使っても、また、デプロイ先のシステムに何を選んでも、基本原則は変わりません。いくつかのパラメータでコマンドを実行し、何らかの方法で認証用にシークレットキーを渡すということです。\n\n\n\ndpl のデプロイツールは、この基本原則に従い、[このプロバイダーのリスト](https://github.com/travis-ci/dpl#supported-providers)に対して統一されたインターフェイスを提供します。\n\n\n\nこちらが、dplを使用した場合の、本番デプロイジョブの例です。\n\n\n\n\n\n```yaml\n\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy to production:\n  environment: production\n  image: ruby:latest\n  script:\n  - gem install dpl\n  - dpl --provider=s3 --bucket=$S3_BUCKET_NAME\n  only:\n  - main\n```\n\n\n\n異なるシステムにデプロイする場合、またはデプロイ先のプラットフォームを頻繁に変更する場合には、デプロイ用スクリプトが統一されるように dplを使うことを検討してください。\n\n\n\n\n\n\n## **まとめ：5つの重要なポイント**\n\n\n\nGitLab での CI デプロイについて、CI/CD AWS を使って説明してきました。GitLab AWS デプロイについて役立つ知識が得られたでしょうか。これまで学んできたポイントをまとめると、次のようになります。\n\n\n\n1. デプロイとは、定期的に実行される、単一の (もしくは一連の) コマンドにすぎません。このため、デプロイは [GitLab CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/) 内で実行できます。\n\n\n2. ほとんどの場合、実行するコマンドに対していくつかの (もしくは単一の) シークレットキーを指定する必要があります。指定するシークレットキーは、**Settings （設定）> CI/CD > Variables（変数）** に格納します。\n\n\n3. [GitLab CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/) では、デプロイ先のブランチを柔軟に指定できます。\n\n\n4. 複数の環境にデプロイする場合、GitLab はデプロイ履歴を保持します。そのため、任意の前バージョンにロールバックできます。\n\n\n5. インフラストラクチャの重要な部分については、GitLab 自動デプロイの代わりに、GitLab インターフェイスからの手動デプロイを有効化できます。\n\n\n\n\u003Cstyle>\n\n\n\nimg.illustration {\n  padding-left: 12%;\n  padding-right: 12%;\n\n}\n\n\n\n@media (max-width: 760px) {\n  img.illustration {\n    padding-left: 0px;\n    padding-right: 0px;\n  }\n}\n\n\n\n\u003C/style>\n\n\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)*\n\n\n\n*（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[3893,783],"Ivan Nemytchenko","2021-02-05","GitLab CIを使って複数の環境にデプロイする方法",[1410,1411,676],{"featured":6,"template":681,"slug":3898},"ci-deployment-and-environments","content:ja-jp:blog:ci-deployment-and-environments.yml","Ci Deployment And Environments","ja-jp/blog/ci-deployment-and-environments.yml","ja-jp/blog/ci-deployment-and-environments",{"_path":3904,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3905,"content":3910,"config":3918,"_id":3920,"_type":16,"title":3921,"_source":17,"_file":3922,"_stem":3923,"_extension":20},"/ja-jp/blog/we-need-to-talk-no-proxy",{"title":3906,"description":3907,"ogTitle":3906,"ogDescription":3907,"noIndex":6,"ogImage":3564,"ogUrl":3908,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3908,"schema":3909},"no_proxyを標準化する方法：お客様事例で徹底解説","環境変数“no proxy”が原因で問題発生したことは？お客様事例を取り上げ、標準化の方法を考えてみました。","https://about.gitlab.com/blog/we-need-to-talk-no-proxy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"no_proxyを標準化する方法：お客様事例で徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stan Hu\"}],\n        \"datePublished\": \"2021-01-27\",\n      }",{"title":3906,"description":3907,"authors":3911,"heroImage":3564,"date":3913,"body":3914,"category":672,"tags":3915,"updatedDate":3917},[3912],"Stan Hu","2021-01-27","ウェブプロキシサーバーを使用した経験がある方なら、環境変数`http_proxy`や`HTTP_PROXY`をよくご存知でしょう。しかし、`no_proxy`（ノープロキシ）に関しては、どうもわかりにくい、と感じていらっしゃる方も多いのではないでしょうか。\n\nno proxyとは、あるホスト宛のトラフィックでプロキシを経由させないようにする環境変数です。世界基準が存在するHTTPと違い、ウェブクライアントがno proxyを処理する方法に「標準」は存在しません。その結果、ウェブクライアントは場合により異なる方法で処理を行います。\n\nその違いが原因でサービスが通信を停止し、その原因を突き止めるために週末返上で作業する羽目になったGitLabのお客様もいらっしゃいます。\n\nそこで、この記事ではGitLabのお客様が直面した問題について、具体例を挙げながら根本原因を探り、「no proxyを標準化する方法」というテーマを掘り下げてみます。\n\n### no proxyはなぜ「わかりにくい」のか\n\nno proxyがなぜわかりにくいのか、具体例を挙げて説明します。\n\n現在、ほとんどのウェブクライアントは環境変数を介してプロキシサーバーへの接続をサポートしています。環境変数には大文字表記と小文字表記があります。\n\n- `http_proxy` / `HTTP_PROXY`\n- `https_proxy` / `HTTPS_PROXY`\n- `no_proxy` / `NO_PROXY`\n\nこれらの変数は、プロキシサーバーにアクセスするのにどのURLを使用するか、またどういった例外を作っているか、クライアントに指示するものです。\n\nたとえば、ある企業で田中さんが`http://tanaka.example.com:8080` でリッスンしているプロキシサーバーの場合、次のようになります。\n\n```sh\nexport http_proxy=http://tanaka.example.com:8080\n```\n\n一方、同僚の斎藤さんも、次のように大文字バージョンの`HTTP_PROXY` で定義していたとします。\n\n```sh\nexport HTTP_PROXY=http://saito.example.com:8080\n```\n\nこの場合、どちらのプロキシサーバーが使用されることになるのでしょうか？答えは「状況によって異なる」です。ある場合は田中さんのプロキシサーバーが有効になる場合もあれば、ある場合は斎藤さんのプロキシサーバーが有効になる場合があります。\n\nこの場合、どちらのプロキシサーバーが使用されることになるのでしょうか？答えは「状況によって異なる」です。ある場合は田中さんのプロキシサーバーが有効になる場合もあれば、ある場合は斎藤さんのプロキシサーバーが有効になる場合があります。\n\nでは、例外を設定したい場合はどうなるでしょうか。たとえば、`internal.example.com`と`internal2.example.com`以外のすべてで、プロキシサーバーを経由したい場合です。このような場合が`no_proxy`変数の出番です。`no_proxy`を次のように定義します。\n\n```sh\nexport no_proxy=internal.example.com,internal2.example.com\n```\n\nでは、IPアドレスを除外したい場合はどうすればよいでしょうか？アスタリスクやワイルドカードは使用できるのでしょうか？CIDRブロック（例:`192.168.1.1/32`）は？\n\nこれらの答えも、「状況によって異なる」です。つまり「使用言語やツールという”PC環境”によって、proxy変数の処理方法が異なる」のが、no proxyがわかりにくいとされている理由です。次の項では、proxy変数の処理方法の違いについてさらに掘り下げます。\n\n### なぜno proxyはこんなに複雑なのか？\n\nこの問題の理解を深めるため、no proxyを巡るこれまでの経緯を説明しておきます。\n\n1994年においてほとんどのウェブクライアントは、[`http_proxy`と`no_proxy`環境変数をサポートするCERNの](https://courses.cs.vt.edu/~cs4244/spring.09/documents/Proxies.pdf)`libwww`を使用していました。`libwww`は、`http_proxy`の小文字形式のみを使用し、[`no_proxy`構文は以下のようにシンプルでした。](https://github.com/w3c/libwww/blob/8678b3dcb4191065ca39caea54bb1beba809a617/Library/src/HTAccess.c#L234-L239)\n\n```\nno_proxy is a comma- or space-separated list of machine\nor domain names, with optional :port part.  If no :port\npart is present, it applies to all ports on that domain.\n\nExample:\n\t\tno_proxy=\"cern.ch,some.domain:8001\"\n```\n\nつまり、元々「小文字表記のみ」で始まったのですが、その後新しいクライアントである`wget`や`curl`の登場により、`no proxy`の大文字が使用可になったり、不可とされたりと変遷しているのです。\n\n1996年1月にHrvoje Niksicが、`libwww`をリンクせずに独自のHTTP実装を追加する新しいクライアント、`geturl`（現在の`wget`の前身）をリリースしました。翌月には`geturl`が[バージョン1.1でhttp\\_proxyのサポートを追加](https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/www/utilities/wget/old-versions/)され、同年5月には`geturl`バージョン1.3で`no_proxy`のサポートが追加されました。ここでは`libwww`と同様に、`geturl`では小文字形式`no_proxy`のみのサポートでした。\n\n1998年1月には、Daniel Stenbergが`curl`v5.1をリリースし、[`http_proxy`および`no_proxy`](https://github.com/curl/curl/blob/ae1912cb0d494b48d514d937826c9fe83ec96c4d/CHANGES#L929-L944)変数をサポート。また、大文字の形式の`HTTP_PROXY`および`NO_PROXY`も許可されました。\n\n2009年3月にはcurl v7.19.4がセキュリティ上の懸念から、大文字`HTTP_PROXY`のサポートを廃止します。`curl`では`HTTP_PROXY`は無視されますが、`HTTPS_PROXY`は現在でも動作します。\n\n### 一目でわかるproxy変数の処理方法の違い\n\nGitLabの[Nourdinel Bachaが調査したところ](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/2991)、これらのプロキシサーバー変数の処理方法は、使用言語やツールによって異なることがわかりました。\n\n#### http_proxyとhttps_proxyの場合\n\n各行はサポートされている動作を表し、各列にはそれが適用されるツール（例：curl）または言語（例：Ruby）を表しています。\n\n|                 | curl      | wget           | Ruby          | Python    | Go        |\n|-----------------|-----------|----------------|---------------|-----------|-----------|\n| `http_proxy`    | はい       | はい            | はい           | はい       | はい       |\n| `HTTP_PROXY`    | いいえ        | いいえ             | はい ([警告](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1519)) | はい (`REQUEST_METHOD` が環境にない場合)       | はい       |\n| `https_proxy`   | はい       | はい            | はい           | はい       | はい       |\n| `HTTPS_PROXY`   | はい       | いいえ             | はい           | はい       | はい       |\n| 大文字と小文字の優先順位 | 小文字 | 小文字のみ | 小文字     | 小文字 | 大文字 |\n| 参照       | [出所](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2250-L2266) | [出所](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1222-L1239) | [出所](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1474-L1543) | [出所](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2488-L2517) | [出所](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L82-L97) |\n\nこの表から以下のことがわかります。\n\n* http\\_proxyとhttps\\_proxyは常に全面的にサポートされているが、HTTP\\_PROXYは必ずしもサポートされているわけではない。  \n* Python（urllib経由）では状況がさらに複雑となる。HTTP\\_PROXYが使用できるのは、[REQUEST\\_METHODが環境で定義されていない場合に限られる](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2504-L2508)。  \n* Goだけは他と異なり、小文字バージョンより大文字バージョンを優先する。\n\n環境変数はすべて大文字だと思われがちですが、実は最初に登場した`http_proxy`に倣い、小文字表記が事実上のスタンダードとなっています。よくわからない場合は、普遍的にサポートされている小文字形式の使用をおすすめします。\n\n#### no_proxyの場合\n\nさて、次は`no_pproxy`について説明します。次の表は、さまざまな実装の状態を示しています。こちらの表は`http_proxy`の場合に比べてもっと複雑です。例えば、`no_proxy`設定が次の様に定義されているとします。\n\n```sh\nexport no_proxy=example.com\n```\n\nこれはドメインが完全一致である必要があるのか、それともsubdomain.example.comのようなサブドメインも含まれるのでしょうか。次の表は様々な実装状況を示しています。「サフィックス（接尾辞）と一致？」の行を見ると分かるように、実際にはすべての実装がサフィックス（ドメイン末尾）を適切に一致させることができます。\n\n|                       | curl      | wget           | Ruby      | Python    | Go        |\n|-----------------------|-----------|----------------|-----------|-----------|-----------|\n| `no_proxy`            | はい       | はい            | はい       | はい       | はい       |\n| `NO_PROXY`            | はい       | いいえ             | はい       | いいえ       | はい       |\n| 大文字と小文字の優先順位       | 小文字 | 小文字のみ | 小文字 | 小文字のみ | 大文字 |\n| サフィックス（接尾辞）と一致？     | はい       | はい            | はい       | はい       | はい       |\n| `.`でリーディング停止？   | はい       | いいえ             | はい       | はい       | いいえ        |\n| `*` はすべてのホストに一致？| はい       | いいえ             | いいえ        | はい       | はい       |\n| 正規表現をサポート？     | いいえ        | いいえ             | いいえ        | いいえ        | いいえ        |\n| CIDRブロックをサポート？ | いいえ        | いいえ             | はい       | いいえ        | はい       |\n| ループバックIPを検出する？ | いいえ        | いいえ             | いいえ        | いいえ        | はい       |\n| 参考             | [出所](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2152-L2206) | [出所](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1266-L1274) | [出所](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1545-L1554) | [出所](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2519-L2551)| [出所](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L170-L206) |\n\nただし、`no_proxy`設定の先頭に「.」がある場合、動作が異なります。\n\nたとえば、`curl`と`wget`は動作が異なります。`curl`は常に先頭の「.」を削除し、ドメインサフィックスと照合します。次の呼び出しはプロキシをバイパスします。\n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com curl https://gitlab.com\n\u003Chtml>\u003Cbody>You are being \u003Ca href=\"https://about.gitlab.com/\">redirected\u003C/a>.\u003C/body>\u003C/html>\n```\n\nただし、`wget`は先頭の「`.`」を削除せず、ホスト名に対して正確な文字列一致を実行します。その結果、`wget`はトップレベルドメインが使用されている場合にプロキシの使用を試みます。\n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com wget https://gitlab.com\nResolving non.existent (non.existent)... failed: Name or service not known.\nwget: unable to resolve host address 'non.existent'\n```\n\nすべての実装において、正規表現はサポートされません。\n\n正規表現には独自の特徴（PCRE、POSIXなど）があるため、正規表現を使用すると問題がさらに複雑になると思われます。また、正規表現を使用すると、パフォーマンスとセキュリティの問題が発生する可能性があります。\n\n`no_proxy`を`*`に設定するとプロキシが完全に無効になる場合もあるが、これはすべてに共通するルールではない。  \n\nプロキシを使用するかどうかを決定する際に、ホスト名をIPアドレスに解決するためのDNSルックアップを実行する実装はない。\n\nクライアントによってIPアドレスが明示的に使用されることが予想される場合を除き、`no_proxy`変数にIPアドレスを指定しないようにしましょう。\n\n`18.240.0.1/24`などのCIDRブロックは、リクエストが直接IPアドレスに対して行われた場合にのみ機能します。CIDRブロックが許可されるのはGoとRubyのみです。他の実装とは異なり、GoではループバックIPアドレスが検出されると、プロキシの使用が自動的に無効になります。\n\n### GitLabのお客様が抱えたno proxy問題\n\n大文字小文字表記、言語とツールによるリアクションの違いに注意を払う必要があるのは、複数の言語で記述されたアプリケーションを、プロキシサーバーを備えた企業のファイアウォールの背後で動作させる場合です。GitLabもそのひとつであり、RubyとGoで記述された複数のサービスで構成されています。\n\nここでGitLabのあるお客様の例を挙げましょう。お客様はプロキシ構文を次のように設定しました。\n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\n```\n\nこのお客様からGitLabに以下の問題の報告がありました。\n\n1. コマンドラインからの`git` pushが起動した\n2. ウェブUI経由で行われたGitの変更が失敗した\n\n連絡を受けたサポートエンジニアは、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)の構文の問題により、古い値が残っていることを発見しました。ポッドの環境は実際には次のようになっていました。\n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\nno_proxy: .wrong-company.com\n```\n\n`no_proxy`と`NO_PROXY`、両者の定義が一致していないため警告が出ました。定義を一致させるか／誤ったエントリを削除することで、この問題を解決できます。\n\nこの古いエントリの何が原因で問題が起きたのか、もう少し詳しく見てみることにします。先ほど「[no proxyの場合](#bookmark=id.3j5kjy3c5qh2)」で述べたことをここで思い出してみましょう。\n\n1. Rubyはまず小文字形式を試す\n2. Goはまず大文字形式を試す\n\nその結果、GitLab WorkhorseなどのGoで記述されたサービスには正しいプロキシ構文となりました。Goサービスが主にこのアクティビティを処理したため、コマンドラインからの`git push`は正常に機能しました。\n\n```mermaid\nsequenceDiagram\n    participant C as Client\n    participant W as Workhorse\n    participant G as Gitaly\n    C->>W: 1. git push\n    W->>G: 2. gRPC: PostReceivePack\n    G->>W: 3. OK\n    W->>C: 4. OK\n```\n\ngRPC呼び出しでは、`no_proxy`がGitalyに直接接続するように適切に構成されていたため、プロキシの使用が試行されませんでした。\n\nただし、ユーザーがUIを変更すると、GitalyはリクエストをRubyで記述された`gitaly-ruby`サービスに転送します。`gitaly-ruby`はリポジトリに変更を加え、[gRPCコールバックを介して親プロセスにレポートを返します](https://gitlab.com/gitlab-org/gitaly/-/issues/3189)(英語）。ただし、以下の手順4に示すように、レポート手順は実行されませんでした。\n\n```mermaid\nsequenceDiagram\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: 1. Change file in UI\n    R->>G: 2. gRPC: UserCommitFiles\n    G->>GR: 3. gRPC: UserCommitFiles\n    GR->>P: 4. CONNECT\n    P->>GR: 5. FAIL\n```\n\ngRPCは基盤となるトランスポートとしてHTTP/2を使用するため、`gitaly-ruby`は間違った`no_proxy`設定で構成されたプロキシへのCONNECTを試行しました。プロキシはこのHTTP要求を即座に拒否し、ウェブUIプッシュケースで失敗を引き起こしました。\n\n環境から小文字の`no_proxy`を削除すると、UIからのプッシュが期待どおりに機能し、`gitaly-ruby`が親のGitalyプロセスに直接接続されました。以下の図のステップ4は適切に機能しました。\n\n```mermaid\nsequenceDiagram\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: 1. Change file in UI\n    R->>G: 2. gRPC: UserCommitFiles\n    G->>GR: 3. gRPC: UserCommitFiles\n    GR->>G: 4. OK\n    G->>R: 5. OK\n    R->>C: 6. OK\n```\n\n#### もう一つの原因はgRPCにあった\n\n`https://`ではなく`http://`が使用されています。セキュリティの観点からは理想的ではありませんが、TLS証明書の検証の問題によりクライアントが失敗するという面倒を避けるために行う場合もあります。\n\nしかしこの場合、HTTPSプロキシが指定されていれば、この問題は発生しなかったでしょう。HTTPSプロキシが使用されている場合、gRPCは[HTTPSプロキシをサポートしていない](https://github.com/grpc/grpc/issues/20939)ため、この設定を無視するからです。\n\n### 解決策：最小限の共通項で設定する\n\n小文字と大文字のプロキシ設定で矛盾した値を定義すべきではないことは、誰もが同意すると思います。ただし、複数の言語で記述されたスタックを管理する必要がある場合は、HTTPプロキシ構文を最も共通する設定で行うよう検討することをおすすめします。\n\n#### `http_proxy` と `https_proxy`\n\n* 小文字形式を使用する。 `HTTP_PROXY` は常にサポートまたは推奨されるわけではない。\n    * どうしても大文字形式も使用する必要がある場合は、__必ず__ 同じ値を共有する。\n\n#### `no_proxy`\n\n1. 小文字形式を使用する。\n2. カンマ区切りの`hostname:port`値を使用する。\n3. IPアドレスは問題ないが、ホスト名は解決されない。\n4. サフィックスは常にマッチングされる(例:`example.com`は`test.example.com`と一致)。\n5. トップレベルドメインを一致させる必要がある場合は、先頭のドット(`.`)を使用しない。\n6. GoとRubyのみがCIDRマッチングをサポートしているため、CIDRマッチングの使用は避ける。\n\n### 解決策：`no_proxy`の標準化チェックリスト\n\n最小公分母を知っておくと、定義が異なるウェブクライアントにコピーされた場合に、問題を回避する上で役立ちます。しかし、`no_proxy`やその他のプロキシ設定には、間に合わせの標準よりも、文書化された標準が必要かもしれません。以下のリストを出発点としてお役立てください。\n\n1. 大文字の変数よりも小文字の変数を優先する (例 `http_proxy` は`HTTP_PROXY`の前に検索すべき)。\n2. カンマ区切りの `hostname:port` 値を使用する。\n    * 各値にはオプションの空白を含めることができる。\n3. DNSルックアップの実行や、正規表現の使用を行わない。\n4. **すべての** ホストに一致させるには`*`を使用する。\n5. 先頭のドット (`.`) を削除し、ドメインサフィックスに対してマッチングさせる。\n6. CIDRブロックマッチングをサポートする。\n7. 特別なIPアドレスを想定しない（たとえば`no_proxy`のループバックアドレス)。\n\n#### まとめ\n\n最初のウェブプロキシがリリースされてから25年以上経ちました。環境変数を介してウェブクライアントを構成する基本的な仕組みはあまり変わっていませんが、さまざまな実装で微妙な違いが生じています。\n\n今回、GitLabのあるお客様の具体的な事例をご紹介しました。このお客様の状況は以下のとおりでした。\n\n* 競合する`no_proxy`変数と`NO_PROXY`変数を誤って定義  \n* RubyとGoはこれらの設定を処理する方法が異なるため、トラブルシューティングに何時間も費やす\n\nこのブログではこの2つの違いに焦点を当て、解説しました。皆様の本番スタックで将来の問題発生回避にお役立ていただけると幸いです。また、設定標準チェックリストを参照して、ウェブクライアントの保守担当者様が動作を標準化し、このような問題を根本的に回避することを願っています。\n\nGitの利便性を生かしつつ、一元化されたプラットフォームでデベロッパー、セキュリティ担当者、運用チームをサポートするGitLabでは、[AIによるコード提案機能があるため、効率性を高められます](https://about.gitlab.com/ja-jp/platform/)。導入検討中の方は、ぜひ無料でのトライアルをお試しください。\n\n> [無料トライアルを開始してみる](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/platform&glm_content=default-saas-trial)\n\n画像出展： [PixaBay](https://pixabay.com/illustrations/question-mark-pile-questions-symbol-2492009)\n{: .note}\n\n\u003Cbr>\u003Cbr>\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[270,3732,764,3916],"startups","2025-03-17",{"slug":3919,"featured":6,"template":681},"we-need-to-talk-no-proxy","content:ja-jp:blog:we-need-to-talk-no-proxy.yml","We Need To Talk No Proxy","ja-jp/blog/we-need-to-talk-no-proxy.yml","ja-jp/blog/we-need-to-talk-no-proxy",{"_path":3925,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3926,"content":3932,"config":3937,"_id":3939,"_type":16,"title":3940,"_source":17,"_file":3941,"_stem":3942,"_extension":20},"/ja-jp/blog/basics-of-gitlab-ci-updated",{"title":3927,"description":3928,"ogTitle":3927,"ogDescription":3928,"noIndex":6,"ogImage":3929,"ogUrl":3930,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3930,"schema":3931},"CI 入門：ジョブを順序どおりに、並列に、または順不同で実行する方法","継続的インテグレーション (CI) 入門：CI は初めてですか？GitLab CI の使い方を学び、最初のCIパイプラインをGitLabでビルドしてみましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662061/Blog/Hero%20Images/cicdcover.png","https://about.gitlab.com/blog/basics-of-gitlab-ci-updated","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CI 入門：ジョブを順序どおりに、並列に、または順不同で実行する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2020-12-10\",\n      }",{"title":3927,"description":3928,"authors":3933,"heroImage":3929,"date":3934,"body":3935,"category":672,"tags":3936,"updatedDate":2016},[980],"2020-12-10","[継続的インテグレーション (CI) (英語版)](https://about.gitlab.com/topics/ci-cd/)\nのことを何一つ知らず、ソフトウェア開発ライフサイクルに [どうして CI が必要なのか\n(英語版)](https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices/)\n分からない、と仮定しましょう。\n\n\nいま、あるプロジェクトで作業をしていて、そこには2つのテキストファイルから成るコードがあるものとします。さらに、これらの2つのファイルには「Hello\nworld」というフレーズが含まれている必要がある、という点に注意してください。\n\n\nこのフレーズが含まれていなければ、開発チームがその月のお給料を受け取れないことになるかもしれないくらい、重要なポイントです。\n\n\nそこで、責任感のあるソフトウェアデベロッパーが、顧客にコードを納品する前に実行する、短いスクリプトを書きました。\n\n\n以下のような非常に洗練されたコードです。\n\n\n```bash\n\ncat file1.txt file2.txt | grep -q \"Hello world\"\n\n```\n\n\nここでの懸念事項はチームには10名のデベロッパーがいて、人的要因がコードの品質に大きな影響を及ぼす可能性があるという点です。\n\n\n1週間前、新しくチームに入ったメンバーがこのスクリプトを実行し忘れ、3件のクライアントに機能しないビルドが納品されるという事態が発生しました。この事態の解決にあたり、幸いにもコードは既にGitLab\nにあり、[ビルトインの\nCI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)\nがあることが分かりました。さらに、あるカンファレンスで、テスト実行にCIを使うのが一般的ということを耳にしていました。\n\n\n## CI 内で最初のテストを実行する\n\n\nドキュメントによると、CI の実行に必要なのは `.gitlab-ci.yml` ファイル内に 以下の2 行のコードを追加することだけでした。\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n```\n\n\nコミットして...無事にビルドが成功しました。\n\n\n![CI内でビルドに成功](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_succeeded.png)\n\n\nでは、2 つ目のファイルの「world」という文言を「Africa」に置き換え、何が起こるか確認してみましょう。\n\n\n![CI内でビルドに失敗](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_failed.png)\n\n\nビルドは予想どおり失敗します。\n\nここで、自動化テストが完成しました。GitLab CI は、DevOps\n環境内でソースコードのリポジトリに新しいコードをプッシュするたびにこのテストスクリプトを実行します。\n\n\n__注:__ 上記例では、file1.txt と file2.txt がGitLabランナーを実行するホストに存在すると仮定しています。\n\n\nこの例を実際に GitLabで実行するには、以下のようにファイルを作成するコードを実行した後、テストスクリプトを実行する必要があります。\n\n\n```yaml\n\ntest:\n\nbefore_script:\n      - echo \"Hello \" > | tr -d \"\\n\" | > file1.txt\n      - echo \"world\" > file2.txt\nscript: cat file1.txt file2.txt | grep -q 'Hello world'\n\n```\n\n\nなお、分かりやすくするために、この 2 つのファイルは既にホストに存在していると仮定し、以降の例では作成しないものとします。\n\n\n## CIビルド結果をダウンロード可能にする\n\n\n次にすることは、顧客に納品するコードをパッケージ化することです。ソフトウェア開発プロセスのこの部分も自動化してしまいましょう。\n\n\nまず、CI に別のジョブを定義する必要があります。このジョブは「package」という名前にしましょう。\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > package.gz\n```\n\n\nよって、今ここにはタブが 2 つあります。\n\n\n![2つのタブ ―\n2つのジョブから生成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/two_tabs.png)\n\n\nしかし、新たに作成されるファイルがダウンロードできるようにビルドの「アーティファクト」であることを指定し忘れてしまいました。。修正するには、`artifacts`\nセクションを追加します。\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\n修正した結果を確認すると、アーティファクトが作成されダウンロードできるようになっています。\n\n\n![ダウンロードボタンのチェック](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/artifacts.png)\n\n\nしかし、ここで修正が必要な新たな問題があります。2\nつのジョブは現在は並列実行されていますが、テストに失敗した場合、アプリケーションをパッケージ化しないように変更をする必要があります。\n\n\n## ジョブを順次実行する\n\n\nそこで「package」ジョブは、テストが成功した場合のみ実行するものとします。`stages` を指定し、ジョブの実行順序を定義しましょう。\n\n\n```yaml\n\nstages:\n  - test\n  - package\n\ntest:\n  stage: test\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\n上記のようになりました。\n\n\nちなみに、コンパイル (我々のケースでは2つのファイルを連結することを意味します) には時間がかかるため、2\n回も実行したくはありません。コンパイルは別のステップとして定義しましょう。\n\n\n```yaml\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nそれでは、アーティファクトを見てみましょう。\n\n\n![不必要なアーティファクト](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/clean-artifacts.png)\n\n\nこの「コンパイル」ファイルを常にダウンロード可能にする必要はないようです。一時的なアーティファクトとして「20\n分」で保存期間切れとなるよう、`expire_in` を設定します。\n\n\n```yaml\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n```\n\n\n構成ファイルは見たところ問題なさそうです。\n\n\n- アプリケーションをコンパイル、テスト、パッケージ化するために、3 つの連続したステージを作成しました。\n\n\n- コンパイル済みアプリを次のステージに渡すと、コンパイルを 2回実行する必要がなくなります(それにより実行が高速化されます)。\n\n\n- パッケージ化されたアプリケーションは、今後も使用できるようビルドアーティファクトとして保管します。\n\n\n## どのDockerイメージを使用するのか学ぶ\n\n\nここまでは順調です。しかし、CIビルドにはまだ時間がかかります。ログを見てみましょう。\n\n\n![ruby3.1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/ruby-31.png)\n\n\nここに注目してください。Ruby 3.1とあります。\n\n\nなぜ Ruby が必要なのかといえば、GitLab.com が [ビルド実行\n(英語版)](https://about.gitlab.com/blog/shared-runners/) に Docker\nイメージを使用しており、[デフォルトで\n(英語版)](https://docs.gitlab.com/ee/user/gitlab_com/#shared-runners) \n[`ruby:3.1`](https://hub.docker.com/_/ruby/)\nイメージを使用するからです。間違いなく、このイメージには必要のないパッケージが多数含まれています。Google\nで検索して調べたところ、[`alpine`](https://hub.docker.com/_/alpine/) というイメージがあり、ほとんど空の\nLinux イメージであることが分かりました。\n\n\nそれでは、`.gitlab-ci.yml` に  `image: alpine` を追加して、このイメージを使用したいと明示的に指定しましょう。\n\n\nうまくいきました。パイプラインの実行が3 分ほど短縮できたようです。\n\n\n![ビルド速度を短縮](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/speed.png)\n\n\nパブリックイメージはたくさんあるようです。\n\n- [mysql](https://hub.docker.com/_/mysql/)\n\n- [Python](https://hub.docker.com/_/python/)\n\n- [Java](https://hub.docker.com/_/java/)\n\n- [php](https://hub.docker.com/_/php/)\n\n\nそれにより、我々の技術スタックに適したものを選ぶことができます。不必要なソフトウェアが含まれていないイメージを指定することで、ダウンロード時間が最短で済みます。\n\n\n## 複雑なシナリオに対応する\n\n\nさて、ここで新しいクライアントが、アプリを `.gz` ではなく、`.iso` イメージとしてパッケージ化してほしい、と希望しているとします。CI\nがすべての作業を行なってくれるため、コードにはジョブを 1 つ追加するだけです。ISO\nイメージはmkisofsコマンドを使用して作成できます。構成ファイルは次のようになります。\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\n# ... \"compile\" and \"test\" jobs are skipped here for the sake of compactness\n\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nジョブ名は同じにする必要はありません。ジョブ名が同じだと、ソフトウェア開発プロセスの同じステージでジョブを並列実行できません。そのため、ジョブやステージの名前が同じになるのは、偶然のことだと考えてください。\n\n\nさて、ビルドは失敗しました。\n\n\n![mkisofs\nが欠落しているために失敗したビルド](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/mkisofs.png)\n\n\n`mkisofs` が `alpine` イメージに含まれていないことが原因です。まずはこのパッケージをインストールする必要があります。\n\n\n## 欠落しているソフトウェアやパッケージの対応\n\n\n[Alpine Linux Web サイト\n(英語版)](https://pkgs.alpinelinux.org/contents?file=mkisofs&path=&name=&branch=edge&repo=&arch=)\nによると、`mkisofs` は `xorriso`パッケージと `cdrkit`\nパッケージの一部です。次のコマンドを実行することでパッケージをインストールできます。\n\n\n```bash\n\necho \"ipv6\" >> /etc/modules  # enable networking\n\napk update                   # update packages list\n\napk add xorriso              # install package\n\n```\n\n\nCI ではこれらは他のコマンドと何ら変わりません。`script` セクションで実行する必要があるコマンドの全リストは、このようになります。\n\n\n```yml\n\nscript:\n\n- echo \"ipv6\" >> /etc/modules\n\n- apk update\n\n- apk add xorriso\n\n- mkisofs -o ./packaged.iso ./compiled.txt\n\n```\n\n\n構文的に正しくするため、パッケージのインストールに関連したコマンドは `before_script` 内に置きましょう。`before_script`\nを構成の最上位レベルで使うと、そのコマンドがすべてのジョブの前に実行されることに留意してください。今回は特定のジョブの前で実行させます。\n\n\n## DAG（有向非巡回グラフ）：より高速で柔軟なパイプラインのために\n\n\nステージを定義して、テストに合格した場合にのみパッケージジョブを実行するようにしました。後のステージに定義されているジョブに対し、いくつかのジョブのステージ順序を並び替えて先に実行させたい場合はどうすればいいでしょうか。場合によっては、従来のステージ順序がパイプライン全体の実行時間を遅くしてしまう可能性があります。\n\n\nテストステージに、実行に時間のかかる負荷の高いテストがいくつか含まれており、それらのテストが必ずしもパッケージジョブに関連していないとします。この場合、テストの完了を待たずにパッケージジョブを開始できれば、より効率的になります。それにはDAG\n(有向非巡回グラフ) が役立ちます。特定のジョブのステージ順序を変えるためには、ジョブの依存関係 (通常のステージの順序をスキップするもの)\nを定義します。\n\n\nGitLab には、ジョブ間の依存関係を作成する特殊キーワード `needs`\nがあります。これを使うことで、依存しているジョブが完了するとすぐにジョブを前倒しで実行できるようになります。\n\n\n次の例では、テストジョブが完了するとすぐにパックジョブが実行を開始します。そのため、将来誰かがテストをテストステージに追加した場合に、新しいテストジョブの完了を待たずにパッケージジョブが実行を開始します。\n\n\n```yaml\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\n`.gitlab-ci.yml` の最終バージョン:\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  before_script:\n      - echo \"Hello  \" | tr -d \"\\n\" > file1.txt\n      - echo \"world\" > file2.txt\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nパイプラインが作成できました！ステージは 3 つの連続したステージで、ジョブ `pack-gz` と `pack-iso` が、`package`\nステージ内で並列実行されています。\n\n\n![パイプラインのイラスト](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/pipeline.png)\n\n\n## 高度なパイプラインの構築\n\n\nここからは、高度なパイプラインを構築する方法を説明します。\n\n\n### CIパイプラインに自動テストを実装 \n\n\n[DevOps](https://about.gitlab.com/ja-jp/)\nにおいて、ソフトウェア開発戦略の重要なルールは、素晴らしいユーザーエクスペリエンスを備えた優れたアプリを作成する、というものです。ここでは、CI\nパイプラインにいくつかのテストを追加し、プロセス全体の早い段階でバグを検出、修正しましょう。この方法なら、問題が大きくなる前や新しいプロジェクトに移る前に問題を修正できます。\n\n\nGitLabにはさまざまな [テスト](https://docs.gitlab.com/ee/ci/testing/)\n用にすぐ使えるテンプレートがあり、これらを使用することで作業が簡単になります。必要な手順は、CI の構成にテンプレートを追加するだけです。\n\n\nこの例では、[アクセシビリティテスト\n(英語版)](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html)\nを追加します。\n\n\n```yaml\n\nstages:\n  - accessibility\n\nvariables:\n  a11y_urls: \"https://about.gitlab.com https://www.example.com\"\n\ninclude:\n  - template: \"Verify/Accessibility.gitlab-ci.yml\"\n```\n\n\n`a11y_urls` 変数をカスタム化し、Web ページの URL を挿入して、[Pa11y](https://pa11y.org/) と\n[コード品質](https://docs.gitlab.com/ee/ci/testing/code_quality.html) のテストを行います。\n\n\n```yaml\n   include:\n   - template: Jobs/Code-Quality.gitlab-ci.yml\n```\n\n\nGitLab\nを使うと、マージリクエストのウィジェットエリア内でテストレポートを簡単に確認できます。コードレビュー、パイプラインステータス、テスト結果を一か所にまとめることで、あらゆることがよりスムーズに効率よくできるようになります。\n\n\n![アクセシビリティレポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_10.56.41.png)\n\n\u003Ccenter>\u003Ci>アクセシビリティ・マージリクエスト・ウィジェット\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n![MR\n内のコード品質ウィジェット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.00.25.png)\n\n\u003Ccenter>\u003Ci>コード品質マージリクエストウィジェット\u003C/i>\u003C/center>\n\n\n### マトリックスビルド\n\n\n場合によっては、異なる構成、OS\nバージョン、プログラミング言語バージョンなどでアプリをテストする必要があります。そのような場合には、[parallel:matrix\n(英語版)](https://docs.gitlab.com/ee/ci/yaml/#parallelmatrix) ビルドを使って、1\nつのジョブ構成でさまざまな組み合わせでアプリケーションを並列にテストします。このブログでは、マトリックスキーワードを使用して、異なるバージョンの\nPython でコードのテストを行います。\n\n\n```yaml\n\npython-req:\n  image: python:$VERSION\n  stage: lint\n  script:\n    - pip install -r requirements_dev.txt\n    - chmod +x ./build_cpp.sh\n    - ./build_cpp.sh\n  parallel:\n    matrix:\n      - VERSION: ['3.8', '3.9', '3.10', '3.11']   # https://hub.docker.com/_/python\n```\n\n\nパイプライン実行中、このジョブは 4 通りの方法で並列実行されます。それぞれ以下のように異なる Python イメージを使用します。\n\n\n![実行中のマトリックスジョブ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.12.48.png)\n\n\n### ユニットテスト  \n\n\n#### ユニットテストとは\n\n\nユニットテストとは、ソフトウェアの個々のコンポーネントや機能が期待通りに機能するかを確認する、対象を絞った単体テストです。ユニットテストは、ソフトウェア開発プロセスの早い段階でバグを検出して修正し、コードのそれぞれの部分が、独立した状態でも正しく機能することを確認するために必須です。\n\n\n例: 計算機アプリを開発しているとします。加算関数のユニットテストでは、2 + 2 が 4\nになるかどうかを確認します。このテストに合格すれば、加算関数が正しく機能していることが確認されます。\n\n\n#### ユニットテストのベストプラクティス\n\n\nテストに失敗すると、パイプラインは失敗し、ユーザーに通知が送られます。デベロッパーはジョブのログ (通常何千行もある)\nを確認し、どこでテストに失敗したのかを特定し、修正します。このチェックには時間がかかり、効率がよくありません。\n\n\nそこで、[ユニットテストレポート\n(英語版)](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html)\nを使うようにジョブを構成することができます。GitLab\nはマージリクエストとパイプラインの詳細ページ上にレポートを表示することができるため、ログ全体を確認しなくてもエラーをより簡単に素早く特定できます。\n\n\n##### JUnitテストレポート\n\n\n以下はJUnit テストレポートの例です。\n\n\n![パイプラインの JUnit テストレポート v13\n10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674097/Blog/Content%20Images/pipelines_junit_test_report_v13_10.png){:\n.shadow.center}\n\n\n### 統合テストおよびエンドツーエンドテスト戦略\n\n通常の開発ルーチンに加え、統合テストとエンドツーエンドテスト専用に指定したパイプラインをセットアップすることが非常に重要です。これらのテストでは、[マイクロサービス\n(英語版)](https://about.gitlab.com/topics/microservices/)、UI\nテスト、それ他のコンポーネントを含んだ、コードの異なる部位の連携がスムーズかどうかをチェックします。\n\n\nこれらのテストは [毎晩 (英語版)](https://docs.gitlab.com/ee/ci/pipelines/schedules.html)\n実行されます。[テスト結果を自動的に指定のスラックチャンネルに送るよう\n(英語版)](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#notification-events)\nに設定することもできます。そうすることで、デベロッパーが翌日出社したときに迅速に問題を確認できます。こうした機能はすべて、問題を早期に特定して修正することを優先すべく設計されています。\n\n\n### テスト環境 \n\n\nテストの中には、アプリをしっかりテストするために、テスト環境を構築しなければならない場合があります。GitLab CI/CD\nを使用するとテスト環境のデプロイが自動化でき、時間を大幅に節約できます。本ブログは主に CI\nに着目したものとなっているため、詳細には触れません。アプリのデプロイとリリースについては、[GitLab ドキュメントのこのセクション\n(英語版)](https://docs.gitlab.com/ee/topics/release_your_application.html)\nを参照してください。\n\n\n## CI パイプラインへのセキュリティスキャンの実装\n\n\nCI パイプラインにセキュリティスキャンを実装する方法は次のとおりです。\n\n\n### SASTおよびDASTインテグレーション\n\n\nコードの安全性を守ることは非常に重要であり、最新の変更に脆弱性がある場合は、その内容を直ちに把握したいと考えます。したがって、パイプラインにセキュリティスキャンを追加するのが最適な対応といえるでしょう。セキュリティスキャンは、コミットごとにコードをチェックし、リスクがあれば警告してくれます。CI\nパイプラインに静的アプリケーションセキュリティテスト ([SAST\n(英語版)](https://docs.gitlab.com/ee/user/application_security/sast/))\nや動的アプリケーションセキュリティテスト ([DAST\n(英語版)](https://docs.gitlab.com/ee/user/application_security/dast/))\nなどの各種スキャンを追加する方法を説明する以下のナビゲーションをご確認ください。\n\n\nナビゲーションを開始するには、以下の画像を**クリック**してください。 \n\n\n[![スキャンの製品ツアー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.44.42.png)](https://gitlab.navattic.com/gitlab-scans)\n\n\nさらに、AI を活用すれば、脆弱性をさらに深く掘り下げ、修正方法の提案が得られます。詳しくは以下のナビゲーションをご確認ください。\n\n\nナビゲーションを開始するには、以下の画像をクリックしてください。\n\n\n[![製品ツアーでの脆弱性の説明](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.50.24.png)](https://tech-marketing.gitlab.io/static-demos/pt-explain-vulnerability.html)\n\n\n## GitLab CI使い方まとめ\n\n\nまだまだお伝えしたいことはありますが、ここで一度終わりにしましょう。説明に使用した例はすべて意図的に単純なものにしました。これは、慣れない技術スタックの説明が続くことで内容が頭に入らないといった状況を避け、GitLab\nCIのコンセプトを理解してもらうためです。では、ここまで学んできたことを次にまとめます。\n\n\n1. GitLab CI に作業をまかせるには、`.gitlab-ci.yml` 内で 1 つ以上の[ジョブ\n(英語版)](https://docs.gitlab.com/ee/ci/jobs/)を定義する必要があります。\n\n2. ジョブには名前を付ける必要がありますが、その際は適切な名前を付けるようにしてください。\n\n3. それぞれのジョブには、指定のキーワードで定義された、 GitLab CI 用の一連のルールと指示が含まれます。\n\n4. ジョブは、順序どおりに、並列に、または [DAG\n(英語版)](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/index.html)\nを使って順不同で実行できます。\n\n5. ジョブ間ではファイルを渡してビルドアーティファクトに保存し、インターフェイスからダウンロードできるようにすることも可能です。\n\n6. CI パイプラインに [テストとセキュリティスキャン\n(英語版)](https://docs.gitlab.com/ee/development/integrations/secure.html)\nを追加して、開発中のアプリの品質とセキュリティを確保します。\n\n\n本記事で使用した用語およびキーワードの説明と、関連するドキュメントのリンクを下表にまとめました。\n\n\n### キーワードの説明とドキュメント\n\n\n{: #keywords}\n\n\n| キーワード/用語       | 説明 |\n\n|---------------|--------------------|\n\n| [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/) |\nプロジェクトのビルド方法の定義をすべて含むファイル |\n\n| [script](https://docs.gitlab.com/ee/ci/yaml/#script)        |\n実行するシェルスクリプトを定義する |\n\n| [before_script](https://docs.gitlab.com/ee/ci/yaml/#before_script) | (全)\nジョブの前に実行するコマンドを定義するために使用する |\n\n|\n[image](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-image)\n| 使用するDocker イメージを定義する |\n\n| [stages](https://docs.gitlab.com/ee/ci/yaml/#stages)         |\nパイプラインのステージを定義する (デフォルトは test) |\n\n| [artifacts](https://docs.gitlab.com/ee/ci/yaml/#artifacts)     |\nビルドアーティファクトのリストを定義する |\n\n|\n[artifacts:expire_in](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in)\n| 指定時間後にアップロードしたアーティファクトを削除するために使用する |\n\n| [needs](https://docs.gitlab.com/ee/ci/yaml/#needs) |\nジョブ間の依存関係を定義するときに使用し、ジョブを特定の順序で実行することを可能にする |\n\n| [pipelines](https://about.gitlab.com/topics/ci-cd/cicd-pipeline/) |\nいくつかのステージ (バッチ) で実行されるビルドのグループを指す |\n\n\n※ドキュメントはすべて英語版です。\n\n\n## CI/CDについてさらに詳しく\n\n\n- [GitLab’s guide to CI/CD for beginners (GitLab のビギナーのための CI/CD ガイド\n(英語版))](https://about.gitlab.com/blog/beginner-guide-ci-cd/)\n\n- [Get faster and more flexible pipelines with a Directed Acyclic Graph\n(有向非巡回グラフ（DAG）を使用して、より高速で柔軟なパイプラインを実現する(英語版))](https://about.gitlab.com/blog/directed-acyclic-graph/)\n\n- [Decrease build time with custom Docker image (カスタム化した Docker\nイメージでビルド時間を短縮する\n(英語版))](http://beenje.github.io/blog/posts/gitlab-ci-and-conda/)\n\n- [Introducing the GitLab CI/CD Catalog Beta (GitLab CI/CD カタログベータ版の紹介\n(英語版))](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/)\n\n\n## よくある質問 (FAQ)\n\n\n### CIジョブを順次実行するか、または並列実行するか、どのように選択すればいいですか？\n\n\nCI\nジョブを順次実行するか、並列実行するかを選択する際は、ジョブの依存関係、リソースの利用可能性、実行時間、潜在的な干渉、テストスイートの構造、コスト面を考慮します。たとえば、デプロイジョブが始まるまでに終わらせなければならないビルドジョブがあったとします。その場合、これらのジョブを順次実行して、正しい実行順序を確かめます。一方、ユニットテストや統合テストなどのタスクは独立しており、それぞれの完了には依存しないため、並列実行できます。\n\n\n### GitLab CIの DAG（有向非巡回グラフ）とは何ですか？また、DAG はパイプラインの柔軟性をどのように向上させますか？\n\n\nGitLab CI の有向非巡回グラフ (DAG) は、パイプラインステージの順序を並び替えます。DAG\nはジョブ間の依存関係を設定するため、前のステージにあるジョブが終わり次第、その後のステージのジョブが開始されます。これによりパイプライン全体の実行時間が短縮され、効率が向上し、一部のジョブは通常の順序より早く完了します。\n\n\n### GitLab の CI ジョブに最適なDockerイメージを選ぶ際に重要視しなければならないことは何ですか？\n\n\nGitLab はジョブの実行の際に Docker イメージを使用します。デフォルトのイメージは ruby:3.1\nです。ジョブの要件によって、最適なイメージを選ぶことがとても大切です。ジョブはまず指定された Docker\nイメージをダウンロードしますが、イメージに必要ではない追加パッケージが含まれていると、ダウンロードや実行に余分な時間がかかります。そのため、実行時に不必要な遅延が発生しないように、選択したイメージにはジョブに必要なパッケージだけが含まれていることを確認することが重要です。\n\n\n## 次のステップ\n\n\nソフトウェア開発プラクティスで後れを取らないためにも、次のステップとしてCI/CDコンポーネントの標準化と再利用方法を理解することをお勧めします。[GitLab\nCI/CD カタログ\n(英語版)](https://docs.gitlab.com/ee/architecture/blueprints/ci_pipeline_components/)\nもご確認ください。\n\n\n継続的インテグレーションとデリバリー入門は、[こちら](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)をご覧ください。\n\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[1410,676],{"slug":3938,"featured":6,"template":681},"basics-of-gitlab-ci-updated","content:ja-jp:blog:basics-of-gitlab-ci-updated.yml","Basics Of Gitlab Ci Updated","ja-jp/blog/basics-of-gitlab-ci-updated.yml","ja-jp/blog/basics-of-gitlab-ci-updated",{"_path":3944,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3945,"content":3951,"config":3957,"_id":3959,"_type":16,"title":3960,"_source":17,"_file":3961,"_stem":3962,"_extension":20},"/ja-jp/blog/integrating-azure-devops-scm-and-gitlab",{"title":3946,"description":3947,"ogTitle":3946,"ogDescription":3947,"noIndex":6,"ogImage":3948,"ogUrl":3949,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3949,"schema":3950},"Azure DevOpsリポジトリをGitLabと統合する方法","Azure DevOpsリポジトリのGitLabとの統合は簡単。やり方を学んで、Azure DevOpsからGitLab CI/CDへの移行をスムーズに行いましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664363/Blog/Hero%20Images/aleksey-kuprikov.jpg","https://about.gitlab.com/blog/integrating-azure-devops-scm-and-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Azure DevOpsリポジトリをGitLabと統合する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2020-07-09\",\n      }",{"title":3946,"description":3947,"authors":3952,"heroImage":3948,"date":3953,"body":3954,"category":672,"tags":3955,"updatedDate":3956},[980],"2020-07-09","## 目次\n\n1. Azure DevOpsはGitLabに統合できるのか \n\n2. GitLabとAzure DevOpsの違い\n\n3. GitLabからAzureへの接続方法\n\n4. 推奨される開発フロー\n\n5. デプロイのワークフローのデモ動画\n\n6. 試みる価値のあるソリューション\n\n7. まとめ\n\n\nAzure\nDevOpsリポジトリ内にコードを置いたままで、GitLabのパイプラインでCI/CDを実行する方法をご説明します。リンクは特に断りのない限り、英語版ページへのリンクとなります。ご留意ください。\n\n\n最近、Azure DevOps/VSTS（Visual Studio Team\nServices）のソースコード管理（SCM）とGitLabを統合することは可能でしょうかと質問を受けることが続きました。こういった質問をしてきた方は、GitLabのような最新の[CI/CD\nソリューション](https://about.gitlab.com/topics/ci-cd/)を検討しているものの、段階移行で一時的に新旧のシステムが共存する間は、コードをAzure\nDevOps/VSTS内で管理する必要があるようです。\n\n\n## Azure DevOpsはGitLabに統合できるのか\n\n\nはい、Azure DevOpsはGitLabに統合できます。\n\n\nGitLabではGitLab CI/CDをGitLabの組み込みSCMと併せて使用することを推奨していますが、Azure\nDevOpsのソースコード管理とGitLabとを統合すると、コードをAzure\n[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)リポジトリに残したままGitLab\nCI/CDも導入できるため、Azure\nDevOpsから徐々にGitLabに移行することが可能です。GitLabのセルフマネージドバージョンと、SaaSバージョンのどちらでも統合が可能です。しかし、統合可能なのは、Azure\nDevOps/VSTSの Gitバージョン管理のみです。TFVC（Team Foundation Version\nControl）はサポートされていませんのでご注意ください。\n\n\n### Azure DevOpsとの統合を可能にするGitLabの2つの機能\n\n\n[外部リポジトリ用GitLab\nCI/CD](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/) ― GitLab\nCI/CDは外部リポジトリ（GitHub, Bitbucket Cloud など）のGitサーバーで利用できます。\n\n\n[リモートリポジトリのミラーリング](https://docs.gitlab.com/ee/user/project/repository/mirror/)\n―\nリポジトリは外部ソースとの間でミラーリングできます。どのリポジトリをソースとして使用するかも選択できます。ミラーリングを行なうと、ブランチ、タグ、コミットなどが自動的に同期されます。\n\n\n#### DevOps におけるリポジトリとは？\n\n\nGitLabやAzureのようなツールにおけるコードリポジトリは、あらゆるソースコードを格納するために存在します。こういったリポジトリはDevOpsの「リポ」と呼ばれたり、「ソースリポジトリ」と呼ばれたりします。名前がどうであれ、デベロッパーが高いコード品質を目指して作業するための場所をコードリポジトリが提供することに変わりありません。GitLabは、バージョン管理によるソースコード管理に[Gitベースのリポジトリ（日本語版）](https://about.gitlab.com/ja-jp/solutions/source-code-management/)を使用します。Gitベースのリポジトリを使用したバージョン管理により、GitLabユーザーがコードレビューを行い、開発面での問題を簡単に解決することができるのです。\n\n\n## GitLabとAzure DevOpsの違い\n\n\nAzure\nDevOpsには、開発ライフサイクルを管理するための幅広いサービスがあります。主要機能には、アジャイルプランニングボード、ソースコード管理用のプライベートGitリポ、そしてAzureパイプラインなどがあります。\n\nDevSecOpsライフサイクル全体に対応した単一プラットフォームとして提供されるGitLabには以下が含まれます。\n\n- プランニングとコラボレーション\n\n- ソースコード管理\n\n- コードレビュー\n\n- CI/CDパイプライン\n\n- 継続的なセキュリティスキャンと監視\n\n- 高度なデプロイ\n\n- 脆弱性の管理\n\n\u003Cbr>\n\n\u003Cbr>\n\nGitLabは、セキュリティとコンプライアンスを強化しながら、DevSecOpsのライフサイクル全体の管理をサポートしてソフトウェアを迅速かつ効率的に提供します。\n\n\n## GitLabからAzureへの接続方法\n\n\nソースコード管理をAzureからGitLabへ完全に移行するには時間がかかる場合があります。ここでは、スムーズな移行のために、GitLabからAzure統合に接続する手順を説明します。\n\n\n1. 「New Project（新規プロジェクト）」ボタンをクリックして、GitLab内に新規プロジェクトを作成します。\n![新規プロジェクトの作成](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado1.png){:\n.large.center}\n\n\n2. 「CI/CD for external repo（外部リポジトリ用 CI/CD）」タブを選択し、Repo by\nURL（リポジトリのURL）をクリックします。  ![外部リポジトリ用\nCI/CD](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado2.png){:\n.large.center}\n\n\n3. Azure DevOps 内でリポジトリを開き、「Clone（クローン）」をクリックします。\n  ![クローンURLを入手する](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado3.png){: .large.center}\n\n4. URLをコピーします。お使いのリポジトリがプライベートだった場合、Gitの認証情報を生成する必要があります。「Generate Git\nCredentials（Git認証情報を生成）」をクリックし、ユーザー名とパスワードをコピーしてください。\n![認証情報](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado4.png){:\n.large.center}\n\n\n5. 「Git repository URL（Gitリポジトリの URL）下の欄にURLを貼り付けます。\n\nプロジェクト名を付けます。\n\n可視性の表示レベルを設定します。\n\n「プロジェクトを作成」をクリックします。\n\nAzure DevOpsリポジトリがプライベートだった場合には、ユーザー名とパスワードを追加します。\n\n\n__注__:リポジトリは、http://、https:// または git:// でアクセスできなければなりません。http:// または\nhttps:// プロトコルを使用する場合は、リポジトリへの正確なURLを指定してください。HTTPリダイレクトは実行されません。\n\n  ![プロジェクトフォームの作成\"](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado5.png){: .large.center}\n\n6. プロジェクトはGitLabと正常にミラーリングされました。これで、ブランチ、タグ、コミットがGitLabと自動的に同期されるようになります。\n\n\n7. CI/CDパイプラインを構成するオプションは2つあります。\n  ![Auto DevOps 設定](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado6.png){: .shadow.large.center}\n\nAuto DevOpsを使わずにパイプライン構成をご自分で定義したい場合には、お使いのリポジトリのルートディレクトリに\n[.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/)\nファイルを追加してください。このyamlコードには、[CI/CD定義](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/)\nを必ずインクルードしてください。\n\n\nこのファイルがルートディレクトリにインクルードされると、CI/CDパイプラインが各コミットごとにトリガーされます。.gitlab-ci.yml\nに不慣れな場合には、.gitlab-ci.yml\nという名前でファイルを作成し、以下のコードを貼り付けてください。このコードにはビルドステージとテストステージがあり、それぞれに、単一のジョブが含まれます。このジョブは各ステージでコンソールにテキストを表示します。\n\n\n後でそれぞれのジョブにスクリプトを追加できます。また、ジョブやステージの追加も可能です。より複雑なパイプラインを作成するときは、ゼロから着手するのではなく、[GitLabに付属の](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates)[パイプラインテンプレートを使用する](https://docs.gitlab.com/ee/ci/yaml/#includetemplate)とよいでしょう。\n\n\n```\n\nstages:\n  - build\n  - test \n\nbuild:\n  stage: build\n  script:\n    - echo \"Build job\"\n\ntest:\n  stage: test\n  script:\n    - echo \"Test job\"\n```\n\n\n以上です。これで準備は済みました。\n\n\n## 推奨される開発フロー \n\n\n![開発フローの図](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado_7_2.png){:\n.shadow.large.center}\n\n\n1. コード（デベロッパーが選択したIDE）\u003Cbr>\n\nデベロッパーはお気に入りのIDEを使用してコードを開発し、リポジトリをワークステーションに複製し、ブランチを作成します。\n  ![Visual Studioのコード](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado8.png){: .shadow.large.center}\n\u003Cbr>\n\n\n2. コミット（GIT）\u003Cbr>\n\nフィーチャーの開発またはバグ修正が完了したあと、デベロッパーはワークをAzureリポジトリサーバーにプッシュします。  ![Azure\nDevOpsリポ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado9.png){:\n.shadow.large.center}\n\n\u003Cbr>\n\n3. ビルド（GitLab）\u003Cbr>\n\nコミット履歴つきのブランチがGitLabにミラーリングされます。CI/CDパイプラインがトリガーされ、このパイプラインにより、コードがビルドされます。 \n![GitLabパイプライングラフ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado10.png){:\n.shadow.large.center}\n\n    アーティファクトが作成され、ダウンロードできるようになります。\n  ![アーティファクト](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado11.png){: .shadow.large.center}\n\n    「Auto DevOps」が有効化されていれば、コンテナイメージが作成され、ビルトインのコンテナレジストリにプッシュされます。 \n![GitLabコンテナレジストリ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado12.png){:\n.shadow.large.center}\n\n    プロジェクト内でパッケージレジストリが有効化されている場合には、パッケージが指定されたパッケージマネージャに公開されます。 \n![GitLabパッケージレジストリ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado13.png){:\n.shadow.large.center}\n\n\u003Cbr>\n\n4. テスト (GitLab)\u003Cbr>\n\nCI パイプラインの一環として、セキュリティスキャン、ライセンススキャン、その他のテストが実行されます。 ![GitLab\nスキャン](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado14.png){:\n.shadow.large.center}\n\n\u003Cbr>\n\n5. レビューとプルリクエスト (GitLabおよびAzure DevOpsリポジトリ)\u003Cbr>\n\nGitLabでパイプラインの結果をレビューし、エラーなくパイプラインがパスした場合、かつ、新しい変更により新たな脆弱性が生じていなければ、Azure\nDevOpsでプルリクエストを作成します。コードレビューが始まったら、デベロッパーはメインにマージする前に、新しい変更を加える必要がある場合があります。各コミットは、\nGitLab内でCI/CDパイプラインをトリガーします。 ![Azure\nDevOpsプルリクエスト](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado15.png){:\n.shadow.large.center}\n\n\u003Cbr>\n\n6. マージ（Azure DevOpsリポジトリとGitLab）\u003Cbr>\n\nAzure DevOpsのプルリクエストが承認され、ブランチがAzure DevOpsリポジトリのメインブランチにマージされます。\n\n\nパイプラインの構成により異なりますが、メインブランチへのこのマージは\nGitLab内のCI/CDパイプラインをトリガーし、マージ結果が検証され、新しいパッケージとコンテナイメージがビルドされ、その後それらがデプロイされます。 \n![GitLab\nCI/CDパイプラインのグラフ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado16.png){:\n.shadow.large.center}\n\n\u003Cbr>\n\n## デプロイのワークフローのデモ動画\n\n\n\u003Ciframe width=\"560\" height=\"315\"\nsrc=\"https://www.youtube.com/embed/HfpP2pEmkoM\" frameborder=\"0\"\nallow=\"accelerometer; autoplay; encrypted-media; gyroscope;\npicture-in-picture\" allowfullscreen>\u003C/iframe>\n\n\n## 試みる価値のあるソリューション\n\n\nGitLabは、トップクラスのソースコード管理（SCM）とCI/CDソリューションを単一のアプリケーションで提供し、多くの\n[GitLab顧客](https://about.gitlab.com/customers/)がこのパワフルな組み合わせを利用しています。しかし、チームがすぐにリポジトリをGitLab\nSCMに移行できないという制約があるケースがあることも理解しています。そのような場合のために、一時的に外部リポジトリ用GitLab\nCI/CDを提供しています。\n\n\n## まとめ\n\n\nソースコード管理（SCM）とGitLabのCI/CDソリューションは、簡単に統合ができます。「Azure\nDevOpsリポジトリをGitLabのCI/CDに統合することも**簡単にできる**ということを納得していただけたでしょうか。GitLabのCI/CDについてもっと詳しくお知りになりたい場合には、[こちらの記事（日本語版）](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)をご覧ください。\n\n\n### GitLab CI/CDについてさらに詳しく\n\n\n[フォレスターのレポート:主要なCI/CDツールの比較（英語版）](https://about.gitlab.com/analysts/forrester-cloudci19/)\n\n\n[AWS Fargateを使用したGitLab\nCIのオートスケール（英語版）](/blog/introducing-autoscaling-gitlab-runners-on-aws-fargate/)\n\n\n[お客様事例:ゴールドマン・サックスはビルド頻度を2週間に1回から1日に1000回以上へ改善（日本語版）](https://about.gitlab.com/ja-jp/customers/goldman-sachs/)\n\n\n\u003Cbr>\n\n\u003Cbr>\n\n\u003Cbr>\n\n\nカバーイメージ出典：[Aleksey Kuprikov](https://unsplash.com/@alekskuprfilmz) on\n[Unsplash](https://unsplash.com/)\n\n{: .note}\n\n\n\u003Cbr>\n\n\u003Cbr>\n\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n",[110,1389,676],"2025-02-26",{"slug":3958,"featured":6,"template":681},"integrating-azure-devops-scm-and-gitlab","content:ja-jp:blog:integrating-azure-devops-scm-and-gitlab.yml","Integrating Azure Devops Scm And Gitlab","ja-jp/blog/integrating-azure-devops-scm-and-gitlab.yml","ja-jp/blog/integrating-azure-devops-scm-and-gitlab",{"_path":3964,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3965,"content":3971,"config":3980,"_id":3982,"_type":16,"title":3983,"_source":17,"_file":3984,"_stem":3985,"_extension":20},"/ja-jp/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"title":3966,"description":3967,"ogTitle":3966,"ogDescription":3967,"noIndex":6,"ogImage":3968,"ogUrl":3969,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3969,"schema":3970},"GitLabとAnsibleを使ってIaCを作成する方法","Ansible playbookを使ってIaCを作成します。GitLab CIが持つ力を探求してみてください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665322/Blog/Hero%20Images/gitlab-ansible-cover.png","https://about.gitlab.com/blog/using-ansible-and-gitlab-as-infrastructure-for-code","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabとAnsibleを使ってIaCを作成する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brad Downey\"},{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-07-01\",\n      }",{"title":3966,"description":3967,"authors":3972,"heroImage":3968,"date":3975,"body":3976,"category":672,"tags":3977,"updatedDate":3979},[3973,3974],"Brad Downey","Sara Kassabian","2019-07-01","IaCとして管理されるAnsible playbookを実行する際に力を発揮する、GitLab CIの機能を探求してみませんか。\n\n\nGitLab\nCIは、[IaC](https://about.gitlab.com/ja-jp/topics/gitops/infrastructure-as-code/)や[GitOps](https://about.gitlab.com/ja-jp/solutions/gitops/)など、さまざまな用途に使用できる強力なツールです。GitLabはツールに依存しないプラットフォームですが、AnsibleはIaCを管理するために、開発者によく使用される言語なので、今回はAnsibleを使用していきます。\n\n\n## Ansibleとは\n\n\nAnsibleはオープンソースであり、デプロイ、構成、そしてコンピュータシステムの管理を自動的に行なう際に使用し、構成管理ツールに分類されます。開発者やシステム管理者がAnsibleを使用すると、サーバーの構成やアプリケーションのデプロイ、またネットワークデバイスの管理といった、複雑な、繰り返しの多いプロセスを自動化できます。AnsibleはYAMLを使って、playbookとして知られている宣言型のタスク説明を作成します。作成された宣言型のタスク説明は、コマンドを実行するターゲットホストへのSSH接続を通じてAnsibleが行なう、望まれるシステム状態を説明してくれます。\n\n\n## デモ：GitLab CI と Ansible\n\n\n[GitLab\nCI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)の特に優れている機能のひとつは、ローカルの端末等に依存ライブラリをインストールしなくても\n[Ansible\nplaybook](https://docs.ansible.com/ansible/latest/cli/ansible-playbook.html)（外部サイト）のコードを編集しデプロイできることです。デモでご紹介するプロジェクトは、セキュリティポリシーに従って毎月すべてのデバイスのSNMP文字列を更新する必要がありますが、これはGitLabがホストする\n[GitLab.com](https://about.gitlab.com/ja-jp/pricing/)で簡単に行なうことができます。  \n\n\nまずはじめに、Ansible playbookを開いてください。ここには次の4つのタスクがあります。\n\n\n* ルーターの情報を収集  \n\n* バージョンを表示  \n\n* シリアル番号を表示  \n\n* SNMPを構成\n\n\nこのデモでは、SNMPの文字列の構成方法に焦点を当てています。構成は簡単な一連のステップに従うことで完了できます。\n\n\n## はじめに：イシューボード\n\n\nGitLabではプロジェクトに関する計画はすべて同じやり方、[イシューの起票](https://handbook.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/getting-started/101/#issue)から始まります。そのためGitLabのワークフローの最初のステップでは、[ansible-demoプロジェクト](https://gitlab.com/bdowney/ansible-demo)内のイシューボードを確認します。[ansible-demoイシューボード](https://gitlab.com/bdowney/ansible-demo/-/boards)を見ると、すでに\n[すべてのルーターのSNMP文字列の変更](https://gitlab.com/bdowney/ansible-demo/issues/4)に関連するイシューがあることがわかります。イシューの中に、SNMP文字列を毎月ローテーションさせ、読み取り専用と読み書き両方の場合には、異なる文字列を使用する必要があることを記述したGitLabセキュリティポリシーのWikiへのリンクがあります。\n\n\n![Security\npolicies](https://about.gitlab.com/images/blogimages/ansible_screenshots/security_policies_1A.png){:\n.shadow.medium.center}\n\nSNMP 文字列用の GitLab セキュリティポリシー\n\n{: .note.text-center}\n\n\nGitLabのセキュリティポリシーによると、SNMP文字列を毎月更新する必要があります。  \n\n\n次に、[2つのルーターのデモ](https://gitlab.com/bdowney/ansible-demo/blob/master/ci-cd-demo/ci.yml)でSNMP文字列を設定するコマンドが、イシューで概説されているGitLabのセキュリティポリシーに従っていることを確認します。\n\n\n![Ansible SNMP\nchange](https://about.gitlab.com/images/blogimages/ansible_screenshots/ansible_snmp_change_2.png){:\n.shadow.medium.center}\n\nSNMP 文字列設定のためのコマンド\n\n{: .note.text-center}\n\n\nSNMP文字列を設定するコマンドは、Ansible playbookに記載されています。\n\n\n次に、イシューに戻り、イシューをご自身にアサインしてください。右サイドバーのラベルを`to-do`から`doing`に切り替えるか、または、イシューボードの列をドラッグして移動することもできます。\n\n\n## マージリクエストを作成する\n\n\n次のステップでは、イシューからマージリクエスト (MR)\nを作成します。「Draft」のフラグがMRに付いていることを再度確認してください。これにより、準備ができていないうちにmasterブランチにマージされてしまうことが防止されます。ここでは、SNMP文字列への変更点が少ないので、ローカルの\nIDEでソースコードを編集するのではなく、GitLabの [Web\nIDE](https://docs.gitlab.com/ee/user/project/web_ide/) を使います。  \n\n\n* [CI/CD](https://about.gitlab.com/topics/ci-cd/)デモセクションを開きます。  \n\n* Ansible playbookに移動します。  \n\n* SNMPセクションを次のように編集します。\n\n\n```\n\n-snmp-server community New-SNMP-DEMO1 RO\n\n\n-snmp-server community Fun-SNMP-RW-STR RW\n\n```\n\n\n*  [イシュー](https://gitlab.com/bdowney/ansible-demo/issues/1)で説明されている[GitLab\nセキュリティポリシー](https://gitlab.com/bdowney/ansible-demo/wikis/Security-Policies)に従い、ROとRWが異なる文字列として設定されていることに注意してください。\n\n\n## 変更をコミットする\n\n\nSNMP文字列がガイドラインに沿って更新されましたので、変更をコミットします。最新のコミットでMRが更新されたことを確認するために、side-by-side比較機能を利用してください。\n\n\n![Commit\nchanges](https://about.gitlab.com/images/blogimages/ansible_screenshots/side-by-side_3.png){:\n.shadow.medium.center}\n\nGitLab Ansible 内でのマージリクエストのサイド・バイ・サイド比較\n\n{: .note.text-center}\n\n\n並べて比較できるツールにより、変更内容が一目でわかります。\n\n\n## マージリクエストの出力\n\n\n変更内容をコミットすると、GitLab CIパイプラインが自動的に起動されます。ここでは、次のようなタスクが実行されます。\n\n構文のチェック\n\nドライラン\n\nラボ/シミュレーション環境での変更点のテスト\n\nGitLab CIパイプラインの各ジョブの進捗状況と出力を表示して、SNMPの更新を実行します。\n\n\n![Job\nrunning](https://about.gitlab.com/images/blogimages/ansible_screenshots/job_running_4.png){:\n.shadow.medium.center}\n\nGitLabジョブの出力\n\n{: .note.text-center}\n\n\nジョブからの出力を確認して、シミュレーション環境でSNMPの更新が確実に行なわれたことを確認します。\n\nこのすべてのタスクは、マージリクエスト (MR) 内で実行され、記録されます。\n\n\n![Pipeline](https://about.gitlab.com/images/blogimages/ansible_screenshots/pipeline_5A.png){:\n.shadow.medium.center}\n\nGitLab CIパイプライン内のチェックマーク\n\n{: .note.text-center}\n\n\n緑色のチェックマークは、GitLab CIパイプラインで各タスクが正常に完了したことを示しています。\n\n次に、ラボのルーターにログインして、変更内容を確認します。\n\n\n![routers\nsnmp](https://about.gitlab.com/images/blogimages/ansible_screenshots/routersnmp_6.png){:\n.shadow.medium.center}\n\nルーターのSNMP\n\n{: .note.text-center}\n\n\n読み取り専用（RO）および読み書き（RW）のSNMP文字列の変更点がルーターに反映されています。\n\n\n## マージリクエストのレビュー\n\n\nオプションとして、[マージリクエスト（MR）の承認](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)をアクティブ化することもできます。これにより、変更が本番環境に送られる前に、より多くのユーザーが変更点をレビューできるようになります。\n\n\n![approvers](https://about.gitlab.com/images/blogimages/ansible_screenshots/approvers_7.png){:\n.shadow.medium.center}\n\nGitLabでのSNMP文字列の更新\n\n{: .note.text-center}\n\n\nマージリクエスト（MR）は、masterブランチへのマージを行なう前に、別のユーザーに作業内容をレビューしてもらうように設定することができます。\n\n\n## Masterブランチへのマージ\n\n\nテストが完了したら、変更点をmasterブランチにマージします。masterブランチには、本番環境コードが格納されています。\n\n準備ができたら、`Mark`ボタンをクリックし、次に`Merge`をクリックします。\n\n「Draft」のステータスを解決すると、MRがマージされ、イシューがクローズされます。\n\nすると、新しいパイプラインが実行され、追加のステップとして playbookを本番環境で実行する、すべてのテストが実行されます。\n\n「パイプライン」の画面では、その進捗とログが確認できます。このプロセスが完了したら、本番用ルーターにログインし、SNMPセキュリティ文字列が更新されたことを確認します。\n\n\n## GitLab CIの魔法\n\n\nこれまで説明してきたさまざまな機能を可能にした魔法は GitLab CIです。GitLab\nCIパイプラインとは、Ansibleコードをテストしてデプロイするために必要なあらゆることを実行する、一連の連続したタスクを意味します。\n\n\nGitLab CIは、リポジトリ内に存在する単一のシンプルな [YAML\nファイル](https://about.gitlab.com/blog/three-yaml-tips-better-pipelines/)である`.gitlab-ci.yml`で構成されています。\n\n\nこのデモでは`.gitlab-ci.yml`ファイルが3つのステージで構成されていることがご確認いただけます。\n\n1. Deploy：Ansibleを使用する AWSに 、２つのルーターのシミュレーションネットワークが作成されます。\n\n2. Demo：SNMP文字列を変更するplaybook が実行されます。\n\n3. Destory：２つのルーターのシミュレーションネットワークが破棄されます。\n\n\nGitLab CIは、ベースイメージで始まります。この場合、必要なすべての\nAnsibleバイナリと依存ライブラリを含むDockerイメージを使用しています。必要に応じて、それぞれのステージで実行するコマンドと、依存関係を指定します。\n\n\n![More\ncode](https://about.gitlab.com/images/blogimages/ansible_screenshots/more_code_9A.png){:\n.shadow.medium.center}\n\n単純なYAMLファイルには、GitLab CIの3つのフェーズが含まれます。\n\n{: .note.text-center}\n\n\n![More\nCode](https://about.gitlab.com/images/blogimages/ansible_screenshots/more_code_10A.png){:\n.shadow.medium.center}\n\nGitLab CIのデモレベル\n\n{: .note.text-center}\n\n\nGitLab CIのデモステージを覗いてみましょう。これはAnsible playbookを実行しているものです。\n\n\n今度はパイプラインを見てみましょう。GitLab\nCIを使用すれば、コンピュータにAnsibleの依存関係をインストールすることなく構成管理を実装できることがわかります。これは、IaCを実行するために\nGitLab CIを使用する方法の一例に過ぎません。以下のリンクは、完全版チュートリアルの動画ですので、ぜひご覧ください。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/M-SgRTKSeOg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n## FAQ - よくある質問\n\n\n### Q: Ansibleとは\n\n\nA:\nAnsibleとは、ITプロセスの自動化と構成管理を可能にするオープンソースのツールです。アプリケーションのデプロイ、構成管理、オーケストレーション、プロビジョニングなど、コンピュータシステムの管理を自動的に行なう際に使用します。\n\n\nAnsibleを使用すると、サーバーの構成やアプリケーションのデプロイ、またネットワークデバイスの管理といった、複雑な、繰り返しの多いワークフローのオーケストレーションが可能になります。AnsibleはYAMLを使って、playbookとして知られている宣言型のタスク説明を作成します。作成された宣言型のタスク説明は、コマンドを実行するターゲットホストへのSSH接続を通じてAnsibleが行なう、望まれるシステム状態を説明してくれます。詳しくは[こちら](#heading=h.llxgny6efk4z)をご覧ください。\n\n\n### Q: Ansible Playbookとは\n\n\nA: Ansible\nPlaybookはyamlで書かれたタスクのリストファイルのことで、指定したインベントリーやホストのグループに対して自動的に実行されます。ネットワークインフラ、WindowsサーバーなどITインフラに適用するタスクやコンフィグレーションをこのファイルで定義します。Ansibleタスクは、1つまたは複数タスクがplayとしてグループ化され、それぞれのplayが特定のホストやホストグループに対して実行されます。クラウド管理、ユーザー管理、ネットワーク、セキュリティ、構成管理などがAnsible\nPlaybookで管理できます。\n\n\n### Q: GitLab CIとは\n\n\nA: GitLab CI（継続的インテグレーション、Continuous\nIntegration）とは、GitLab上でコードの変更が行われた際に自動的にテストやビルドを実行するツールで、サードパーティのツールやライブラリを導入しなくても利用できます。GitLab\nCIは、すべてのコード変更を共有ソースコードリポジトリのmainブランチに早い段階で頻繁に統合し、コミットやマージ時に各変更を自動的にテストし、自動的にビルドを開始するプラクティスのことです。継続的インテグレーションを行うことで、エラーやセキュリティの問題をより簡単に、開発プロセスのかなり早い段階で特定し、修正することが可能になります。詳しくは[こちら](https://about.gitlab.com/ja-jp/topics/ci-cd/#what-is-continuous-integration-ci)をご覧ください。\n\n\n### Q: GitLab CIとAnsibleを使用するメリットは何ですか\n\n\nA: GitLab CIなら、ローカルの端末等に依存ライブラリをインストールしなくてもAnsible\nplaybookのコードを編集しデプロイできます。また、GitLab\nCIパイプラインは、Ansibleコードをテストしてデプロイするために必要なあらゆることを実行する、一連の連続したタスクです。つまり、GitLabでは、リポジトリの管理とCIおよびAnsible\nTowerのワークフロー実行が行なえます。加えられた変更の内容、たとえば、いつ、誰がどのファイルに対して変更を行なったのかも自動で記録されるうえ、マージリクエスト(MR)を使えば、理由や目的などのメモも残せるなど、いろいろなメリットがあります。\n\n\n*\\*監修：伊藤 俊廷 [@toshitakaito](https://gitlab.com/toshitakaito) \n\n（GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト）*\n",[3978,110],"demo","2024-10-21",{"slug":3981,"featured":6,"template":681},"using-ansible-and-gitlab-as-infrastructure-for-code","content:ja-jp:blog:using-ansible-and-gitlab-as-infrastructure-for-code.yml","Using Ansible And Gitlab As Infrastructure For Code","ja-jp/blog/using-ansible-and-gitlab-as-infrastructure-for-code.yml","ja-jp/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"_path":3987,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3988,"content":3994,"config":4000,"_id":4002,"_type":16,"title":4003,"_source":17,"_file":4004,"_stem":4005,"_extension":20},"/ja-jp/blog/keeping-git-commit-history-clean",{"title":3989,"description":3990,"ogTitle":3989,"ogDescription":3990,"noIndex":6,"ogImage":3991,"ogUrl":3992,"ogSiteName":1223,"ogType":1244,"canonicalUrls":3992,"schema":3993}," git Commit（コミット）の履歴が重要な理由とその整理方法","git コミット履歴は、煩雑になりがち。gitコミットのメッセージ履歴をクリーンに保ち、変更内容を把握する方法とその重要性をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659457/Blog/Hero%20Images/keep-git-commit-history-clean.jpg","https://about.gitlab.com/blog/keeping-git-commit-history-clean","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \" git Commit（コミット）の履歴が重要な理由とその整理方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kushal Pandya\"}],\n        \"datePublished\": \"2018-06-07\",\n      }",{"title":3989,"description":3990,"authors":3995,"heroImage":3991,"date":3997,"body":3998,"category":672,"tags":3999,"updatedDate":2843},[3996],"Kushal Pandya","2018-06-07","## 目次\n\n\n- git コミットの履歴が重要な理由\n\n- 直前のgitコミットメッセージを変更する\n\n- ２つ以上前のgitコミットの内容を修正する\n\n- 修正用に作ったgitコマンドは元のコミットと組み合わせて履歴をクリーンに保つ\n\n- gitコミットのセーフティネット reflogs\n\n- gitコミットを整理して、未来の開発に備えよう\n\n\ngitコミットは、リポジトリの重要な要素のひとつであり、コミットメッセージはリポジトリの履歴ログでもあります。プロジェクトやリポジトリがチームメンバーに編集・更新（新機能の追加、バグ修正、アーキテクチャのリファクタリングなど）されていくなかで、コミットメッセージは何がどのように変更されたのかを知るための重要な手掛かりとなります。そのため、コミットメッセージは基本的な変更を、簡潔かつ正確に反映することが求められます。\n\n\n## git コミットの履歴が重要な理由\n\n\ngitコミットメッセージは、あなたが触れたコードに残す指紋のようなものです。あなたが今日コミットしたコードには、一年後に同じ変更を見たときにもすぐに理解できるよう、簡潔で正確なメッセージが添えてあるべきです。gitコミットがコンテキストに基づいて分割されていれば、該当のコミットで発生したバグを素早く見つけられ、バグの原因となるコミットを元通りに修正することができます。大規模なプロジェクトで作業していると、常に多数の更新、追加、削除が発生します。そのような場合に、適切なコミットメッセージの記載は不可欠になります。この記事では、gitリポジトリでの作業中に開発者がよく使うgitコミットについて解説していきます。\n\nこの記事では、git\nの基本的な知識、ブランチの仕組み、ブランチの未コミットの変更をステージングす方法、変更をコミットする方法について理解していることを前提としています。これらの流れがよくわからないという方は、こちらのGitLabドキュメントもご参照ください。\n\n\n- [Situation 1: I need to change the most recent\ncommit](#situation-1-i-need-to-change-the-most-recent-commit)\n\n- [Situation 2: I need to change a specific\ncommit](#situation-2-i-need-to-change-a-specific-commit)\n\n- [Situation 3: I need to add, remove, or combine\ncommits](#situation-3-i-need-to-add-remove-or-combine-commits)\n\n- [Situation 4: My commit history doesn't make sense, I need a fresh\nstart!](#situation-4-my-commit-history-doesnt-make-sense-i-need-a-fresh-start)\n\n\nBut before we dive in, let's quickly go through what a typical development\nworkflow looks like in our hypothetical Ruby application.\n\n\n**Note:** This article assumes that you are aware about basics of Git, how\nbranches work, how to add uncommitted changes of a branch to stage and how\nto commit the changes. If you're unsure of these flows, [our\ndocumentation](https://docs.gitlab.com/ee/topics/git/index.html) is a great\nstarting point.\n\n\n## A day in the life\n\n\nHere, we are working on a small Ruby on Rails project where we need to add a\nnavigation view on the homepage and that involves updating and adding\nseveral files. Following is a step by step breakdown of the entire flow:\n\n\n- You start working on a feature with updating a single file; let's call it\n`application_controller.rb`\n\n- This feature requires you to also update a view: `index.html.haml`\n\n- You added a partial which is used in index page: `_navigation.html.haml`\n\n- Styles for the page also need to be updated to reflect the partial we\nadded: `styles.css.scss`\n\n- Feature is now ready with the desired changes, time to also update tests;\nfiles to be updated are as follows:\n  - `application_controller_spec.rb`\n  - `navigation_spec.rb`\n- Tests are updated and passing as expected, now time to commit the changes!\n\n\nSince all the files belong to different territories of the architecture, we\ncommit the changes isolated of each other to ensure that each commit\nrepresents a certain context and is made in a certain order. I usually\nprefer backend -> frontend order where most backend-centric change is\ncommitted first, followed by the middle layer and then by frontend-centric\nchanges in the Git list commits.\n\n\n1.  `application_controller.rb` & `application_controller_spec.rb`; **Add\nroutes for navigation**.\n\n2.  `_navigation.html.haml` &  `navigation_spec.rb`; **Page Navigation\nView**.\n\n3.  `index.html.haml`; **Render navigation partial**.\n\n4.  `styles.css.scss`; **Add styles for navigation**.\n\n\nNow that we have our changes committed, we create a merge request with the\nbranch. Once you have merge request open, it typically gets reviewed by your\npeer before the changes are merged into repo's `master` branch. Now let's\nlearn what different situations we may end up with during code review.\n\n\n## Situation 1: How to change the most recent Git commit\n\n\nImagine a case where the reviewer looked at `styles.css.scss` and suggested\na change. In such a case, it is very simple to do the change as the\nstylesheet changes are part of **last** commit on your branch. Here's how we\ncan handle this;\n\n\n- You directly do the necessary changes to `styles.css.scss` in your current\nbranch.\n\n- Once you're done with the changes, add these changes to stage; run `git\nadd styles.css.scss`.\n\n- Once changes are staged, we need to _add_ these changes to our last\ncommit; run `git commit --amend`.\n  -  **Command breakdown**: Here, we're asking the `git commit` command to _amend_ whatever changes are present in stage to the most recent commit.\n- This will open your last commit in your Git-defined text editor which has\nthe commit message **Add styles for navigation**.\n\n- Since we only updated the CSS declaration, we don't need to alter the\ncommit message. At this point, you can just save and exit the text editor\nthat Git opened for you and your changes will be reflected in the commit.\n\n\nSince you modified an existing Git commit, these changes are required to be\n_force pushed_ to your remote repo using `git push --force-with-lease\n\u003Cremote_name> \u003Cbranch_name>`. This command will override the commit `Add\nstyles for navigation` on remote repo with updated commit that we just made\nin our local repo.\n\n\nOne thing to keep in mind while force pushing branches is that if you are\nworking on the same branch with multiple people, force pushing may cause\ntrouble for other users when they try to normally push their changes on a\nremote branch that has new commits force pushed. Hence, use this feature\nwisely. You can learn more about Git force push options\n[here](https://git-scm.com/docs/git-push#git-push---no-force-with-lease).\n\n\n## Situation 2: How to change a specific Git commit changes\n\n\nIn the previous situation, the Git commit change was rather simple as we had\nto modify only our last Git commit, but imagine if reviewer suggested to\nchange something in `_navigation.html.haml`. In this case, it is second\ncommit from the top, so changing it won't be as direct as it was in the\nfirst situation. Let's see how we can handle this:\n\n\nWhenever a commit is made in a branch, it is identified by a unique SHA-1\nhash string. Think of it as a unique ID that separates one commit from\nanother. You can view all the previous commits, along with their SHA-1\nhashes in a branch by running the `git log` command. With this, you would\nsee an output that looks somewhat as follows and is a list of commits, where\nthe most recent commits are at the top;\n\n\n```\n\ncommit aa0a35a867ed2094da60042062e8f3d6000e3952 (HEAD ->\nadd-page-navigation)\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 15:24:02 2018 +0530\n\n    Add styles for navigation\n\ncommit c22a3fa0c5cdc175f2b8232b9704079d27c619d0\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:42:52 2018 +0000\n\n    Render navigation partial\n\ncommit 4155df1cdc7be01c98b0773497ff65c22ba1549f\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:42:51 2018 +0000\n\n    Page Navigation View\n\ncommit 8d74af102941aa0b51e1a35b8ad731284e4b5a20\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:12:20 2018 +0000\n\n    Add routes for navigation\n```\n\n\nThis is where `git rebase` command comes into play. Whenever we wish to edit\na specific commit with `git rebase`, we need to first rebase our branch by\nmoving back HEAD to the point right _before_ the commit we wish to edit. In\nour case, we need to change the commit that reads `Page Navigation View`.\n\n\n![Commit\nLog](https://about.gitlab.com/images/blogimages/keeping-git-commit-history-clean/GitRebase.png){:\n.shadow.center.medium}\n\n\nHere, notice the hash of commit which is right before the commit we want to\nmodify; copy the hash and perform the following steps:\n\n\n- Rebase the branch to move to commit before our target commit; run `git\nrebase -i 8d74af102941aa0b51e1a35b8ad731284e4b5a20`\n  -  **Git command breakdown**: Here we're running Git's `rebase` command with _interactive_ mode with provided SHA-1 hash as commit to rebase to.\n- This will run rebase command for Git in interactive mode and will open\nyour text editor showing all of your commits that came _after_ the commit\nyou rebased to. It will look somewhat like this:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\n\n# Rebase 8d74af10294..aa0a35a867e onto 8d74af10294 (3 commands)\n\n#\n\n# Commands:\n\n# p, pick = use commit\n\n# r, reword = use commit, but edit the commit message\n\n# e, edit = use commit, but stop for amending\n\n# s, squash = use commit, but meld into previous commit\n\n# f, fixup = like \"squash\", but discard this commit's log message\n\n# x, exec = run command (the rest of the line) using shell\n\n# d, drop = remove Git commit\n\n#\n\n# These lines can be re-ordered; they are executed from top to bottom.\n\n#\n\n# If you remove a line here THAT COMMIT WILL BE LOST.\n\n#\n\n# However, if you remove everything, the rebase will be aborted.\n\n#\n\n# Note that empty commits are commented out\n\n```\n\n\nNotice how each commit has a word `pick` in front of it, and in the contents\nbelow, there are all possible keywords we can use. Since we want to _edit_ a\ncommit, we need to change `pick 4155df1cdc7 Page Navigation View` to `edit\n4155df1cdc7 Page Navigation View`. Save the changes and exit editor.\n\n\nNow your branch is rebased to the point in time right before the commit you\nmade which included `_navigation.html.haml`. Open the file and perform\ndesired changes as per the review feedback. Once you're done with the\nchanges, stage them by running `git add _navigation.html.haml`.\n\n\nSince we have staged the changes, it is time to move branch HEAD back to the\ncommit we originally had (while also including the new changes we added),\nrun `git rebase --continue`, this will open your default editor in the\nterminal and show you the commit message that we edited during rebase; `Page\nNavigation View`. You can change this message if you wish, but we would\nleave it as it is for now, so save and exit the editor. At this point, Git\nwill replay all the commits that followed after the commit you just edited\nand now branch `HEAD` is back to the top commit we originally had, and it\nalso includes the new changes you made to one of the commits.\n\n\nSince we again modified a commit that's already present in remote repo, we\nneed force push this branch again using `git push --force-with-lease\n\u003Cremote_name> \u003Cbranch_name>`.\n\n\n## Situation 3: How to add, remove, or combine Git commits\n\n\nA common situation is when you've made several commits just to fix something\npreviously committed. Now let's reduce them as much as we can, combining\nthem with the original commits.\n\n\nAll you need to do is start the interactive rebase as you would in the other\nscenarios.\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\npick 62e858a322 Fix a typo\n\npick 5c25eb48c8 Ops another fix\n\npick 7f0718efe9 Fix 2\n\npick f0ffc19ef7 Argh Another fix!\n\n```\n\n\nNow imagine you want to combine all those fixes into `c22a3fa0c5c Render\nnavigation partial`. You just need to:\n\n\n1. Move the fixes up so that they are right below the commit you want to\nkeep in the end.\n\n2. Change `pick` to `squash` or `fixup` for each of the fixes.\n\n\n*Note:* `squash` keeps the git fix commit messages in the description.\n`fixup` will forget the commit messages of the fixes and keep the original.\n\n\nYou'll end up with something like this:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo\n\nfixup 5c25eb48c8 Ops another fix\n\nfixup 7f0718efe9 Fix 2\n\nfixup f0ffc19ef7 Argh Another fix!\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nSave the changes, exit the editor, and you're done! This is the resulting\nhistory:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick 96373c0bcf Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nAs before, all you need to do now is `git push --force-with-lease\n\u003Cremote_name> \u003Cbranch_name>` and the changes are up.\n\n\nIf you want to remove a Git commit from branch altogether, instead of\n`squash` or `fixup`, just write `drop` or simply delete that line.\n\n\n### How to avoid Git commit conflicts\n\n\nTo avoid conflicts, make sure the commits you're moving up the timeline\naren't touching the same files touched by the commits left after them.\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo                 # this changes styles.css\n\nfixup 5c25eb48c8 Ops another fix            # this changes image/logo.svg\n\nfixup 7f0718efe9 Fix 2                      # this changes styles.css\n\nfixup f0ffc19ef7 Argh Another fix!          # this changes styles.css\n\npick aa0a35a867e Add styles for navigation  # this changes index.html (no\nconflict)\n\n```\n\n\n### Pro-tip: Quick Git commit `fixup`s\n\n\nIf you know exactly which commit you want to fixup, when committing you\ndon't have to waste brain cycles thinking of good temporary names for \"Fix\n1\", \"Fix 2\", ..., \"Fix 42\".\n\n\n**Step 1: Meet `--fixup`**\n\n\nAfter you've staged the changes fixing whatever it is that needs fixing,\njust Git commit all the changes like this:\n\n\n```\n\ngit commit --fixup c22a3fa0c5c\n\n```\n\n(Note that this is the hash for the commit `c22a3fa0c5c Render navigation\npartial`)\n\n\nThis will generate this commit message: `fixup! Render navigation partial`.\n\n\n**Step 2: And the sidekick `--autosquash`**\n\n\nEasy interactive rebase. You can have `git` place the `fixup`s automatically\nin the right place.\n\n\n`git rebase -i 4155df1cdc7 --autosquash`\n\n\nHistory will be shown like so:\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo\n\nfixup 5c25eb48c8 Ops another fix\n\nfixup 7f0718efe9 Fix 2\n\nfixup f0ffc19ef7 Argh Another fix!\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nReady for you to just review and proceed.\n\n\nIf you're feeling adventurous you can do a non-interactive rebase `git\nrebase --autosquash`, but only if you like living dangerously, as you'll\nhave no opportunity to review the squashes being made before they're\napplied.\n\n\n## Situation 4: My Git commit history doesn't make sense, I need a fresh\nstart!\n\n\nIf we're working on a large feature, it is common to have several fixup and\nreview-feedback changes that are being committed frequently. Instead of\nconstantly rebasing the branch, we can leave the cleaning up of Git commits\nuntil the end of development.\n\n\nThis is where creating patch files is extremely handy. In fact, patch files\nwere the primary way of sharing code over email while collaborating on large\nopen source projects before Git-based services like GitLab were available to\ndevelopers. Imagine you have one such branch (eg; `add-page-navigation`)\nwhere there are tons of commits that don't convey the underlying changes\nclearly. Here's how you can create a patch file for all the changes you made\nin this branch:\n\n\n- The first step to create the patch file is to make sure that your branch\nhas all the changes present from `master` branch and has no conflicts with\nthe same.\n\n- You can run `git rebase master` or `git merge master` while you're checked\nout in `add-page-navigation` branch to get all the changes from `master` on\nto your branch.\n\n- Now create the patch file; run `git diff master add-page-navigation >\n~/add_page_navigation.patch`.\n  -  **Command breakdown**: Here we're using Git's _diff_ feature, and asking for a diff between `master` branch and `add-page-navigation` branch, and _redirecting_ the output (via `>` symbol) to a file named `add_page_navigation.patch` in our user home directory (typically `~/` in *nix operating systems).\n- You can specify any path you wish to keep this file in and the file name\nand extension could be anything you want.\n\n- Once the command is run and you don't see any errors, the patch file is\ngenerated.\n\n- Now checkout `master` branch; run `git checkout master`.\n\n- Delete the branch `add-page-navigation` from local repo; run `git branch\n-D add-page-navigation`. Remember, we already have changes of this branch in\na created patch file.\n\n- Now create a new branch with the same name (while `master` is checked\nout); run `git checkout -b add-page-navigation`.\n\n- At this point, this is a fresh branch and doesn't have any of your\nchanges.\n\n- Finally, apply your changes from the patch file; `git apply\n~/add_page_navigation.patch`.\n\n- Here, all of your changes are applied in a branch and they will appear as\nuncommitted, as if all your modification where done, but none of the\nmodifications were actually committed in the branch.\n\n- Now you can go ahead and commit individual files or files grouped by area\nof impact in the order you want with concise commit messages.\n\n\nAs with previous situations, we basically modified the whole branch, so it\nis time to force push!\n\n\n## Git commit history: Conclusion\n\n\nWhile we have covered most common and basic situations that arise in a\nday-to-day workflow with Git, rewriting Git history is a vast topic and as\nyou get familiar with above tips, you can learn more advanced concepts\naround the subject in the [Git Official\nDocumentation](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).\nHappy git'ing!\n\n\nPhoto by [pan\nxiaozhen](https://unsplash.com/photos/pj-BrFZ9eAA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\non\n[Unsplash](https://unsplash.com/search/photos/clean?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n\n{: .note}\n\n> \n\n\n\u003Cbr>\u003Cbr>\n\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)* \u003Cbr>\n\n*（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n",[966,677],{"slug":4001,"featured":6,"template":681},"keeping-git-commit-history-clean","content:ja-jp:blog:keeping-git-commit-history-clean.yml","Keeping Git Commit History Clean","ja-jp/blog/keeping-git-commit-history-clean.yml","ja-jp/blog/keeping-git-commit-history-clean",{"_path":4007,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":4008,"content":4014,"config":4021,"_id":4023,"_type":16,"title":4024,"_source":17,"_file":4025,"_stem":4026,"_extension":20},"/ja-jp/blog/gitlab-for-agile-software-development",{"title":4009,"description":4010,"ogTitle":4009,"ogDescription":4010,"noIndex":6,"ogImage":4011,"ogUrl":4012,"ogSiteName":1223,"ogType":1244,"canonicalUrls":4012,"schema":4013},"GitLab をアジャイルソフトウェア開発で使用する方法","本ブログでは、アジャイルアーティファクトが GitLab 機能にどのようにマッピングされるのか、また、GitLab 内でアジャイルのイテレーションがどのように表示されるのかについてご説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097459/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097459157.png","https://about.gitlab.com/blog/gitlab-for-agile-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab をアジャイルソフトウェア開発で使用する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"},{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2018-03-05\",\n      }",{"title":4009,"description":4010,"authors":4015,"heroImage":4011,"date":4017,"body":4018,"category":1705,"tags":4019,"updatedDate":4020},[4016,1702],"Victor Wu","2018-03-05","GitLab で[アジャイル開発手法](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)がサポートされているかどうか考えたことはありますか。GitLab の使用を検討中の場合、DevSecOps プラットフォームの機能がどのようにアジャイルのアーティファクトと対応しているのかが分かりにくいかもしれません。そこで、本記事で詳しくご説明します。\n\nアジャイルとは、ここ数十年でソフトウェアエンジニアリング分野に導入された、最も重要で革新的な手法のひとつです。アジャイルの概念に関する細かい用語は統一されていないものの、アジャイル自体は、[アジャイルソフトウェア開発](https://about.gitlab.com/ja-jp/topics/agile-delivery/)プロセスとアジャイルデリバリープロセスを通じて顧客中心の製品を効率的に開発できるなど、ソフトウェア開発チームに大きなプラスの影響を与えてきました。\n\nGitLab は、アジャイルであっても、アジャイルの影響を受けた手法であっても、ソフトウェア開発の手法に柔軟に適応できるよう設計されています。この記事では、アジャイルアーティファクトを簡単に GitLab 機能にマッピングさせる方法をご紹介し、お客様が GitLab を使用することで、パフォーマンスの良い[アジャイルソフトウェアデリバリーチーム](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)をどのように運営しているのかを解説します。\n\n## アジャイルアーティファクトを GitLab 機能にマッピングする\n\n### アジャイルアーティファクト → GitLab 機能\n\n- ユーザーストーリー –> [イシュー](https://docs.gitlab.com/ee/user/project/issues/) \n- タスク –> [タスク](https://docs.gitlab.com/ee/user/tasks.html) \n- エピック –> [エピック](https://docs.gitlab.com/ee/user/group/epics/) \n- ポイントと推定 –> [イシューのウェイト](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) \n- プロダクトのバックログ –> [イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- スプリント／イテレーション –> [イテレーション](https://docs.gitlab.com/ee/user/group/iterations/) \n- アジャイルボード –> [イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- チームワークロード –> [イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- バーンダウンチャート –> [バーンダウンチャート](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)\n\n## GitLabで行うアジャイルのイテレーション\n\n### ユーザーストーリー → GitLab イシュー\n\nアジャイルソフトウェア開発手法では、通常、ユーザーストーリーの作成から始めます。ユーザーストーリーでは、1つの機能に対する理解を深め、ユーザーにビジネス価値を提供するために必要な要素を明確にします。GitLab では、[イシュー](https://docs.gitlab.com/ee/user/project/issues/) (英語版) を作成します。GitLab のイシューはタスクやプロジェクトを管理する効果的な手法であり、アジャイルチームにとって不可欠です。ソフトウェアデベロッパーはイシューの作成、割り当て、追跡を行い、責任の明確化と進捗の可視化を実現できます。イシューには、担当者、イテレーション、ウェイト、ラベルといった重要なメタデータが含まれており、ソフトウェア開発プロセス全体を通じてタスクの優先順位付けやワークフローの管理が強化されます。さらに、ディスカッションスレッド、添付ファイル、リアルタイムでの通知により、チームが効率的にイシューに取り組むことができるため、スムーズなコミュニケーションが促進され、優れたチームワークが発揮されます。\n\n![GitLabイシューのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097468/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097468371.png)\n\nGitLab のイシューは、冒頭にタイトルがあり、その下にビジネス価値やユーザーストーリーに関連するペルソナといった詳細を記載できます。右側のサイドバーには、イシューが紐付けられている親エピックや、イシューのイテレーション、イシューのウェイトなど、他のアジャイル対応機能と統合されており、推定工数を反映しています。\n\n### タスク → タスク\n\nユーザーストーリーは多くの場合、個々のタスクに細分化されます。GitLab の[タスク](https://docs.gitlab.com/ee/user/tasks.html)(英語版) を使用すると、アジャイルチームはユーザーストーリーを個々の作業に細分化できるため、効率的にプロジェクト管理を進められます。この機能は、ソフトウェアデベロッパーがプロジェクト内でタスクを作成、割り当て、追跡できるようにすることで、アジャイルフレームワークをサポートします。タスク管理を GitLab に直接統合することによって、チームは一貫したワークフローを維持し、ソフトウェア開発プロジェクトのあらゆるアクテビティを簡単に追跡、管理できます。\n\n![GitLab を使ったタスク管理とプロジェクト追跡を示すスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097468372.png)\n\nGitLabを使用して正確なタスク管理とプロジェクト追跡を行うことで、ユーザーに提供する価値を高められます。タスクも、担当者、イテレーション、ウェイト、ラベル、タイムトラッキング、コラボレーション機能など、イシューと同じメタデータを備えています。この包括的な各種機能により、アジャイルチームやプロジェクトマネージャーはワークロードの効果的な管理、タスクの優先順位付け、ソフトウェアデベロッパー間のシームレスなコラボレーションを実現できます。\n\n### エピック → GitLabエピック\n一方、アジャイルを使用する人の中には、エピックと呼ばれる抽象化したものをユーザーストーリーの上に指定する人もいます。エピックとは、複数の機能から構成されている大きなユーザーフローを指します。GitLab の[エピック](https://docs.gitlab.com/ee/user/group/epics/) (英語) には、イシューと同様にタイトルと説明が記載されます。また、複数の子イシューも表示させることができ、階層構造が一見して分かります。\n![ネストされたGitLabエピックのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097468374.png)\n\nGitLab では、 最大9 階層までのエピックをネストできるため、アジャイルチームは大規模なプロジェクトも効果的に構築、管理することができます。この階層構造により、プロジェクトのロードマップが明確に示され、ソフトウェアデベロッパーやプロジェクトマネージャーが複雑なイニシアティブを管理しやすいサイズに細分化しやすくなります。子エピックや[紐付けされたエピック](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html) (英語) を活用すると、チームは進捗状況、依存関係、プロジェクトのマイルストーンを的確に追跡できるため、コラボレーションの向上と、一環したアジャイルデリバリーを実現できます。\n\n### プロダクトバックログ → GitLabイシューボード\n\nプロダクトやビジネスのオーナーは通常、ビジネスや顧客のニーズを反映させるためにユーザーストーリーを作成します。ユーザーストーリーは緊急性や開発希望順に基づいてプロダクトバックログ内で優先順位が付けられます。プロダクトオーナーは関係者とコミュニケーションをとり、優先順位を決定したり継続してバックログを調整します。GitLab には[イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html) (英語版) があり、イテレーションをリストとして整理できるほか、ドラッグアンドドロップで作業を進められるため、アジャイルでのバックログが簡単に優先順位付けできたり、ストーリーを次のスプリントに割り当てたりできます。\n\n![GitLabイシューボードのGIF画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/WIP_limit_aHR0cHM6_1750097468376.gif)\n\n### スプリント → GitLabイテレーション\n\nアジャイルにおけるスプリントとは、作業が完了するまでの期限を指します。 1 週間、数週間、または 1 ヶ月以上になることもあります。プロダクトオーナーと開発チーム間で検討を重ね、次のスプリントのスコープとなる作業を決定します。GitLab の[イテレーション](https://docs.gitlab.com/ee/user/group/iterations/) (英語版) 機能ではイテレーションに開始日と終了日を設定し、イテレーションの期間を把握できます。次に、チームは特定のイテレーションにイシューを割り当て、スプリントに取り込みます。\n\nイテレーションを使用することで、GitLab の強化されたアジャイルプロジェクト管理機能を活用して、アジャイルのプランニングならびにデリバリーにおける可視性とコントロールを向上できます。\n\n### ポイントと推定 → GitLabイシューのウェイト\n\nこの章にあるリンクはすべて英語版です。\n\nまた、この段階でユーザーストーリーが共有され、スコープ内の各ユーザーストーリーごとに技術的工数の推定が行われます。GitLab では、イシューには[ウェイト](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html)属性があり、工数の推定に使用されます。\n\nこの時点（またはこの後の段階）で、ユーザーストーリーがさらに技術的な成果物に細分化されたり、技術計画やアーキテクチャがドキュメント化されたりすることもあります。GitLab では、この情報をイシューか[マージリクエストの説明](https://docs.gitlab.com/ee/user/project/merge_requests/)に記載します。技術的なコラボレーションはマージリクエストで行われることが多いためです。\n\nスプリント (GitLabのイテレーション) 中、ソフトウェア開発チームのメンバーは取り組むユーザーストーリーをひとつずつ選びます。GitLab では、イシューに担当者を指定できます。イシューに自分を[割り当てる](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html)ことで、現在その作業に取り組んでいることを明示します。コードの最初の一行を書く前に[イシューに紐付けた空のマージリクエストを作成する](https://docs.gitlab.com/ee/user/project/issues/)ことをお勧めします。そうすることで技術的なコラボレーションプロセスをすぐに開始できます。\n\n### アジャイルボード → GitLabイシューボード\n\nこの章にあるリンクはすべて英語版です。\n\nアジャイルでは、スプリントの間、イシューは特定の組織のワークフローに応じて「`Ready for dev` (開発準備完了)」「`In dev` (開発中)」「`In QA` (QA 中)」「`In review` (レビュー中)」「`Done` (完了)」など、さまざまなステージを経て進行していきます。\n\n通常、これらのステージがアジャイルボードの列として表示されます。GitLab では、[イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html)でステージを定義し、イシューをステージ間で移動させることができます。チームは、イテレーションやその他の関連属性に応じて[ボードを設定](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration)できます。毎日のスタンドアップミーティングでは、チームメンバーが一緒にボードを見て、ワークフローの観点からスプリントの進捗状況を確認します。\n\n![GitLabイシューボードのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097468378.png)\nGitLab イシューボードは、GitLab イシューリストと同様、イシューを動的にプルしますが、より柔軟なワークフローも可能です。ボードに個別のリストを設定すれば、アジャイルボードのステージを反映できます。このようにして、チームはユーザーストーリーが「`Ready for dev` (開発準備完了)」から「`Released to production` (本番環境にリリース)」まで推移していくのを管理、追跡できます。\n\n### チームワークロード → GitLabイシューボード\n\nアジャイルチームは、GitLab 内で担当者別でフィルタリングされたリストを持つイシューボードを作成して、ワークフローを最適化できます。この機能により、チームメンバー間のタスクの分配が可視化され、アジャイルデリバリーが強化されます。担当者ごとのリストを作成するには、プロジェクトまたはグループに移動し、「ボード」セクションで新規ボードを作成し、各担当者用の[リストを追加](https://docs.gitlab.com/ee/user/project/issue_board.html#create-a-new-list) (英語) します。イシューをチームメンバーに割り当てると、対応するリストに割り当てが自動的に表示されます。この動的なビューにより、作業負荷のバランスを取りながら効果的なタスク管理を行うことができます。\n\n![整理されたGitLabイシューボードのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097468380.png)\n\n[スコープラベル]を使用すると、担当者別またはスクワッド別にイシューボードを整理できます。GitLabのイシューボードは非常に幅広く、ソフトウェア開発ライフサイクル全体のワークフローをサポートします。\n\n### バーンダウンチャート → GitLabバーンダウンチャート\n\nこの章にあるリンクはすべて英語版です。\n\n開発チームは、リアルタイムでプロジェクトが順調に進んでいるかどうかを把握し、リスクが発生した場合にはそれを軽減したいと考えます。GitLab の[バーンダウンチャート](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)を使用すれば、チームは現在のスプリントのスコープとなっている作業が完了するにつれて「バーンダウンする（作業量が減少していく）」様子を視覚化できます。\n\nスプリントの終わりに近づくと、開発チームは完成した機能のデモをさまざまな関係者に向けて実施します。GitLab では、[レビューアプリ](https://docs.gitlab.com/ee/ci/review_apps/index.html)を使うことでこのプロセスが簡素化され、まだ本番環境にリリースされていないコードでも、さまざまなテスト、ステージング、または UAT 環境でデモを行うことができます。レビューアプリと [CI/CD 機能](https://docs.gitlab.com/ee/ci/)は、マージリクエスト自体に統合されています。\n\nデベロッパーやQA担当者は、こうしたツールを活用してCI/CDによる自動テストやレビューアプリ環境での手動テストを行い、ソフトウェアの品質を維持しています。\n\n![GitLabバーンダウンチャートのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097468381.png)\n\nGitLabのバーンダウンチャートを使用すると、チームはスプリントのスコープとなっている作業が完了する様子を追跡できます。そのため、リスクに早期に対処し、それに応じて調整を行えます。たとえば、ある機能が次のスプリントに遅れることが見込まれている場合、それを関係者に知らせることができます。\n\nアジャイルスプリントの最後に行われるチームレトロスペクティブ（振り返り）は、GitLab の [wiki](https://docs.gitlab.com/ee/user/project/wiki/index.html) に記録できるため、学んだ教訓や対処項目などを長期にわたって追跡できます。実際のレトロスペクティブでは、チームは[イテレーションレポート](https://docs.gitlab.com/ee/user/group/iterations/#iteration-report)を見ながら、バーンダウンチャートや完了したスプリントに関するその他の統計などを確認することができます。\n\n## GitLabでアジャイルを試してみよう\nアジャイルにおけるプロジェクトマネジメントをレベルアップさせませんか？GitLab は、アジャイルチーム、ソフトウェアデベロッパー、プロジェクトマネージャー向けに特化した包括的な機能を提供し、円滑なコラボレーションと効率的なワークフローを実現します。GitLab の価格オプションをご覧いただき、無料トライアルを始めましょう。GitLab がどのようにアジャイルデリバリープロセスを変革できるかをぜひご体感ください。\n\n> [GitLab アジャイルプランニングについてさらに詳しく知り](https://about.gitlab.com/ja-jp/pricing/)、今すぐGitLabでアジャイルを始めましょう。\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n",[1389,678,677,675],"2025-03-19",{"slug":4022,"featured":6,"template":681},"gitlab-for-agile-software-development","content:ja-jp:blog:gitlab-for-agile-software-development.yml","Gitlab For Agile Software Development","ja-jp/blog/gitlab-for-agile-software-development.yml","ja-jp/blog/gitlab-for-agile-software-development",{"_path":4028,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":4029,"content":4035,"config":4040,"_id":4042,"_type":16,"title":4043,"_source":17,"_file":4044,"_stem":4045,"_extension":20},"/ja-jp/blog/gitlab-wallpaper",{"title":4030,"description":4031,"ogTitle":4030,"ogDescription":4031,"noIndex":6,"ogImage":4032,"ogUrl":4033,"ogSiteName":1223,"ogType":1244,"canonicalUrls":4033,"schema":4034},"GITLABの壁紙.","GitLabの壁紙を見る","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664472/Blog/Hero%20Images/gitlabflatlogomap.png","https://about.gitlab.com/blog/gitlab-wallpaper","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GITLABの壁紙.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2012-06-20\",\n      }",{"title":4030,"description":4031,"authors":4036,"heroImage":4032,"date":4037,"body":4038,"category":302,"updatedDate":4039},[696],"2012-06-20","![Wallpaper](https://about.gitlab.com/images/gitlab.jpg)","2012-06-21",{"slug":4041,"featured":6,"template":681},"gitlab-wallpaper","content:ja-jp:blog:gitlab-wallpaper.yml","Gitlab Wallpaper","ja-jp/blog/gitlab-wallpaper.yml","ja-jp/blog/gitlab-wallpaper",1758292846396]