[{"data":1,"prerenderedAt":1685},["ShallowReactive",2],{"/en-us/blog/tags/devsecops":3,"navigation-ja-jp":20,"banner-ja-jp":436,"footer-ja-jp":449,"footer-source-/en-us/blog/tags/devsecops/":659,"DevSecOps-tag-page-ja-jp":662},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/devsecops","tags",false,"",{"tag":9,"tagSlug":10},"DevSecOps","devsecops",{"template":12},"BlogTag","content:en-us:blog:tags:devsecops.yml","yaml","Devsecops","content","en-us/blog/tags/devsecops.yml","en-us/blog/tags/devsecops","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":432,"_type":14,"title":433,"_source":16,"_file":434,"_stem":435,"_extension":19},"/shared/ja-jp/main-navigation","ja-jp",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":376,"minimal":410,"duo":423},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/ja-jp/","gitlab logo","header",{"text":30,"config":31},"無料トライアルを開始",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"お問い合わせ",{"href":37,"dataGaName":38,"dataGaLocation":28},"/ja-jp/sales/","sales",{"text":40,"config":41},"サインイン",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,187,192,298,358],{"text":46,"config":47,"cards":49,"footer":72},"プラットフォーム",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":53,"config":54},"プラットフォームを詳しく見る",{"href":55,"dataGaName":48,"dataGaLocation":28},"/ja-jp/platform/",{"title":57,"description":58,"link":59},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":60,"config":61},"GitLab Duoのご紹介",{"href":62,"dataGaName":63,"dataGaLocation":28},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":68,"config":69},"詳細はこちら",{"href":70,"dataGaName":71,"dataGaLocation":28},"/ja-jp/why-gitlab/","why gitlab",{"title":73,"items":74},"利用を開始：",[75,80,85],{"text":76,"config":77},"プラットフォームエンジニアリング",{"href":78,"dataGaName":79,"dataGaLocation":28},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"開発者の経験",{"href":83,"dataGaName":84,"dataGaLocation":28},"/ja-jp/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":169},"製品",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":28},"/ja-jp/solutions/",[99,125,147],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/ja-jp/solutions/continuous-integration/",{"text":113,"config":114},"AIアシストによる開発",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"ソースコード管理",{"href":119,"dataGaLocation":28,"dataGaName":120},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Application Security Testing",{"href":130,"dataGaName":137,"dataGaLocation":28},"Application security testing",{"text":139,"config":140},"ソフトウェアサプライチェーンの安全性",{"href":141,"dataGaLocation":28,"dataGaName":142},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":28},"/ja-jp/solutions/software-compliance/",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":28},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":28,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":28,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":28,"dataGaName":168},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLabが活躍する場所",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":28,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":28,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共機関",{"href":185,"dataGaLocation":28,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":28,"dataNavLevelOne":191},"/ja-jp/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":285},"関連リソース",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"すべてのリソースを表示",{"href":199,"dataGaName":195,"dataGaLocation":28},"/ja-jp/resources/",[201,234,257],{"title":202,"items":203},"はじめに",[204,209,214,219,224,229],{"text":205,"config":206},"インストール",{"href":207,"dataGaName":208,"dataGaLocation":28},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":28},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":28,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":28},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":28},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247,252],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":28},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":28},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/ja-jp/teamops/","teamops",{"title":258,"items":259},"つなげる",[260,265,270,275,280],{"text":261,"config":262},"GitLabサービス",{"href":263,"dataGaName":264,"dataGaLocation":28},"/ja-jp/services/","services",{"text":266,"config":267},"コミュニティ",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"フォーラム",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"イベント",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"パートナー",{"href":283,"dataGaName":284,"dataGaLocation":28},"/ja-jp/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":290,"config":291},"ソースプロモカード",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"最新情報を読む",{"href":296,"dataGaName":297,"dataGaLocation":28},"/ja-jp/the-source/","the source",{"text":299,"config":300,"lists":302},"会社情報",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"GitLabについて",{"href":308,"dataGaName":309,"dataGaLocation":28},"/ja-jp/company/","about",{"text":311,"config":312,"footerGa":315},"採用情報",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"経営陣",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"チーム",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"ハンドブック",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"投資家向け情報",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"トラストセンター",{"href":341,"dataGaName":342,"dataGaLocation":28},"/ja-jp/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":28},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"ニュースレター",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"プレス",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":35,"config":359,"lists":360},{"dataNavLevelOne":301},[361],{"items":362},[363,366,371],{"text":35,"config":364},{"href":37,"dataGaName":365,"dataGaLocation":28},"talk to sales",{"text":367,"config":368},"サポートを受ける",{"href":369,"dataGaName":370,"dataGaLocation":28},"/support/","get help",{"text":372,"config":373},"カスタマーポータル",{"href":374,"dataGaName":375,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":377,"login":378,"suggestions":385},"閉じる",{"text":379,"link":380},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":381,"config":382},"GitLab.com",{"href":42,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"提案",[388,391,396,398,402,406],{"text":57,"config":389},{"href":62,"dataGaName":390,"dataGaLocation":384},"GitLab Duo (AI)",{"text":392,"config":393},"コード提案（AI）",{"href":394,"dataGaName":395,"dataGaLocation":384},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":397},{"href":111,"dataGaName":109,"dataGaLocation":384},{"text":399,"config":400},"GitLab on AWS",{"href":401,"dataGaName":399,"dataGaLocation":384},"/ja-jp/partners/technology-partners/aws/",{"text":403,"config":404},"GitLab on Google Cloud",{"href":405,"dataGaName":403,"dataGaLocation":384},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":407,"config":408},"GitLabを選ぶ理由",{"href":70,"dataGaName":409,"dataGaLocation":384},"Why GitLab?",{"freeTrial":411,"mobileIcon":415,"desktopIcon":420},{"text":30,"config":412},{"href":413,"dataGaName":33,"dataGaLocation":414},"https://gitlab.com/-/trials/new/","nav",{"altText":416,"config":417},"GitLabアイコン",{"src":418,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":416,"config":421},{"src":422,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"GitLab Duoの詳細について",{"href":62,"dataGaName":427,"dataGaLocation":414},"gitlab duo",{"altText":416,"config":429},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":431},{"src":422,"dataGaName":419,"dataGaLocation":414},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":437,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":438,"button":439,"config":444,"_id":446,"_type":14,"_source":16,"_file":447,"_stem":448,"_extension":19},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":440,"config":441},"ベータ版を試す",{"href":442,"dataGaName":443,"dataGaLocation":28},"/ja-jp/gitlab-duo/agent-platform/","duo banner",{"layout":445},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":450,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":451,"_id":655,"_type":14,"title":656,"_source":16,"_file":657,"_stem":658,"_extension":19},"/shared/ja-jp/main-footer",{"text":452,"source":453,"edit":459,"contribute":464,"config":469,"items":474,"minimal":647},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":454,"config":455},"ページのソースを表示",{"href":456,"dataGaName":457,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":460,"config":461},"このページを編集",{"href":462,"dataGaName":463,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":465,"config":466},"ご協力をお願いします",{"href":467,"dataGaName":468,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":470,"facebook":471,"youtube":472,"linkedin":473},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[475,498,552,584,619],{"title":46,"links":476,"subMenu":481},[477],{"text":478,"config":479},"DevSecOpsプラットフォーム",{"href":55,"dataGaName":480,"dataGaLocation":458},"devsecops platform",[482],{"title":188,"links":483},[484,488,493],{"text":485,"config":486},"プランの表示",{"href":190,"dataGaName":487,"dataGaLocation":458},"view plans",{"text":489,"config":490},"Premiumを選ぶ理由",{"href":491,"dataGaName":492,"dataGaLocation":458},"/ja-jp/pricing/premium/","why premium",{"text":494,"config":495},"Ultimateを選ぶ理由",{"href":496,"dataGaName":497,"dataGaLocation":458},"/ja-jp/pricing/ultimate/","why ultimate",{"title":499,"links":500},"ソリューション",[501,506,509,511,516,521,525,528,531,536,538,540,542,547],{"text":502,"config":503},"デジタルトランスフォーメーション",{"href":504,"dataGaName":505,"dataGaLocation":458},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":507,"config":508},"セキュリティとコンプライアンス",{"href":130,"dataGaName":137,"dataGaLocation":458},{"text":122,"config":510},{"href":105,"dataGaName":106,"dataGaLocation":458},{"text":512,"config":513},"アジャイル開発",{"href":514,"dataGaName":515,"dataGaLocation":458},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":517,"config":518},"クラウドトランスフォーメーション",{"href":519,"dataGaName":520,"dataGaLocation":458},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":522,"config":523},"SCM",{"href":119,"dataGaName":524,"dataGaLocation":458},"source code management",{"text":109,"config":526},{"href":111,"dataGaName":527,"dataGaLocation":458},"continuous integration & delivery",{"text":160,"config":529},{"href":162,"dataGaName":530,"dataGaLocation":458},"value stream management",{"text":532,"config":533},"GitOps",{"href":534,"dataGaName":535,"dataGaLocation":458},"/ja-jp/solutions/gitops/","gitops",{"text":173,"config":537},{"href":175,"dataGaName":176,"dataGaLocation":458},{"text":178,"config":539},{"href":180,"dataGaName":181,"dataGaLocation":458},{"text":183,"config":541},{"href":185,"dataGaName":186,"dataGaLocation":458},{"text":543,"config":544},"教育",{"href":545,"dataGaName":546,"dataGaLocation":458},"/ja-jp/solutions/education/","education",{"text":548,"config":549},"金融サービス",{"href":550,"dataGaName":551,"dataGaLocation":458},"/ja-jp/solutions/finance/","financial services",{"title":193,"links":553},[554,556,558,560,563,565,568,570,572,574,576,578,580,582],{"text":205,"config":555},{"href":207,"dataGaName":208,"dataGaLocation":458},{"text":210,"config":557},{"href":212,"dataGaName":213,"dataGaLocation":458},{"text":215,"config":559},{"href":217,"dataGaName":218,"dataGaLocation":458},{"text":220,"config":561},{"href":222,"dataGaName":562,"dataGaLocation":458},"docs",{"text":243,"config":564},{"href":245,"dataGaName":246},{"text":566,"config":567},"お客様の成功事例",{"href":240,"dataGaLocation":458},{"text":238,"config":569},{"href":240,"dataGaName":241,"dataGaLocation":458},{"text":248,"config":571},{"href":250,"dataGaName":251,"dataGaLocation":458},{"text":261,"config":573},{"href":263,"dataGaName":264,"dataGaLocation":458},{"text":253,"config":575},{"href":255,"dataGaName":256,"dataGaLocation":458},{"text":266,"config":577},{"href":268,"dataGaName":269,"dataGaLocation":458},{"text":271,"config":579},{"href":273,"dataGaName":274,"dataGaLocation":458},{"text":276,"config":581},{"href":278,"dataGaName":279,"dataGaLocation":458},{"text":281,"config":583},{"href":283,"dataGaName":284,"dataGaLocation":458},{"title":585,"links":586},"Company",[587,589,591,593,595,597,599,603,608,610,612,614],{"text":306,"config":588},{"href":308,"dataGaName":301,"dataGaLocation":458},{"text":311,"config":590},{"href":313,"dataGaName":314,"dataGaLocation":458},{"text":319,"config":592},{"href":321,"dataGaName":322,"dataGaLocation":458},{"text":324,"config":594},{"href":326,"dataGaName":327,"dataGaLocation":458},{"text":329,"config":596},{"href":331,"dataGaName":332,"dataGaLocation":458},{"text":334,"config":598},{"href":336,"dataGaName":337,"dataGaLocation":458},{"text":600,"config":601},"Sustainability",{"href":602,"dataGaName":600,"dataGaLocation":458},"/sustainability/",{"text":604,"config":605},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":606,"dataGaName":607,"dataGaLocation":458},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":609},{"href":341,"dataGaName":342,"dataGaLocation":458},{"text":349,"config":611},{"href":351,"dataGaName":352,"dataGaLocation":458},{"text":354,"config":613},{"href":356,"dataGaName":357,"dataGaLocation":458},{"text":615,"config":616},"現代奴隷制の透明性に関する声明",{"href":617,"dataGaName":618,"dataGaLocation":458},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":620},[621,623,625,627,632,637,642],{"text":35,"config":622},{"href":37,"dataGaName":38,"dataGaLocation":458},{"text":367,"config":624},{"href":369,"dataGaName":370,"dataGaLocation":458},{"text":372,"config":626},{"href":374,"dataGaName":375,"dataGaLocation":458},{"text":628,"config":629},"ステータス",{"href":630,"dataGaName":631,"dataGaLocation":458},"https://status.gitlab.com/","status",{"text":633,"config":634},"利用規約",{"href":635,"dataGaName":636,"dataGaLocation":458},"/terms/","terms of use",{"text":638,"config":639},"プライバシーに関する声明",{"href":640,"dataGaName":641,"dataGaLocation":458},"/ja-jp/privacy/","privacy statement",{"text":643,"config":644},"Cookieの設定",{"dataGaName":645,"dataGaLocation":458,"id":646,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":648},[649,651,653],{"text":633,"config":650},{"href":635,"dataGaName":636,"dataGaLocation":458},{"text":638,"config":652},{"href":640,"dataGaName":641,"dataGaLocation":458},{"text":643,"config":654},{"dataGaName":645,"dataGaLocation":458,"id":646,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":660,"config":661,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},{"tag":9,"tagSlug":10},{"template":12},[663,691,717,741,763,783,805,825,845,866,887,906,926,945,963,982,1001,1020,1040,1060,1081,1101,1123,1142,1161,1182,1203,1223,1244,1265,1285,1301,1320,1339,1358,1378,1398,1419,1440,1463,1488,1508,1528,1549,1569,1587,1606,1625,1645,1665],{"_path":664,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":665,"content":673,"config":684,"_id":687,"_type":14,"title":688,"_source":16,"_file":689,"_stem":690,"_extension":19},"/ja-jp/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"title":666,"description":667,"ogTitle":666,"ogDescription":667,"noIndex":6,"ogImage":668,"ogUrl":669,"ogSiteName":670,"ogType":671,"canonicalUrls":669,"schema":672},"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","https://about.gitlab.com","article","\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":666,"description":667,"authors":674,"heroImage":668,"date":676,"body":677,"category":678,"tags":679},[675],"Dave Steer","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",[680,9,681,682,683],"developer survey","AI/ML","security","news",{"slug":685,"featured":6,"template":686},"3-surprising-findings-from-our-2024-global-devsecops-survey","BlogPost","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":692,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":693,"content":697,"config":711,"_id":713,"_type":14,"title":714,"_source":16,"_file":715,"_stem":716,"_extension":19},"/ja-jp/blog/claude-code-gitlab-ai-development-workflow",{"noIndex":6,"title":694,"description":695,"ogImage":696},"エージェンティックAI Claude CodeとGitLab CLIの開発フロー","Claude CodeとGLabを組み合わせてローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIのコード補助を活かした開発フローを構築する方法を紹介","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751953181/rtejicnkhd9oslaxsoo5.jpg",{"heroImage":696,"category":698,"body":699,"date":700,"authors":701,"description":703,"title":704,"tags":705},"ai-ml","## 目次\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",[702],"Naoharu Sasaki","エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法をご紹介します。","Claude Code × GitLab：AI活用を加速する、エージェンティックAIとGitLab CLIによる効率的なソフトウェア開発フロー",[681,109,706,707,9,708,532,233,682,709,710],"code review","collaboration","features","tutorial","workflow",{"featured":91,"template":686,"slug":712},"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":718,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":719,"content":725,"config":735,"_id":737,"_type":14,"title":738,"_source":16,"_file":739,"_stem":740,"_extension":19},"/ja-jp/blog/customers-sourcenext",{"title":720,"description":721,"ogTitle":720,"ogDescription":721,"noIndex":6,"ogImage":722,"ogUrl":723,"ogSiteName":670,"ogType":671,"canonicalUrls":723,"schema":724},"外部開発パートナーを含む開発プロセスを、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":720,"description":721,"authors":726,"heroImage":722,"date":728,"body":729,"category":730,"tags":731},[727],"GitLab Japan Team","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>","customer-stories",[732,733,109,682,9,734],"DevSecOps platform","customers","user stories",{"slug":736,"featured":91,"template":686},"customers-sourcenext","content:ja-jp:blog:customers-sourcenext.yml","Customers Sourcenext","ja-jp/blog/customers-sourcenext.yml","ja-jp/blog/customers-sourcenext",{"_path":742,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":743,"content":749,"config":757,"_id":759,"_type":14,"title":760,"_source":16,"_file":761,"_stem":762,"_extension":19},"/ja-jp/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci",{"title":744,"description":745,"ogTitle":744,"ogDescription":745,"noIndex":6,"ogImage":746,"ogUrl":747,"ogSiteName":670,"ogType":671,"canonicalUrls":747,"schema":748},"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":744,"description":745,"authors":750,"heroImage":746,"date":752,"body":753,"category":10,"tags":754},[751],"Fatima Sarah Khalid","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/eighteen/)\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",[709,755,756,681,9],"testing","CI",{"slug":758,"featured":91,"template":686},"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":764,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":765,"content":771,"config":777,"_id":779,"_type":14,"title":780,"_source":16,"_file":781,"_stem":782,"_extension":19},"/ja-jp/blog/developers-summit-2025-spring-event-report",{"title":766,"description":767,"ogTitle":766,"ogDescription":767,"noIndex":6,"ogImage":768,"ogUrl":769,"ogSiteName":670,"ogType":671,"canonicalUrls":769,"schema":770},"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":766,"description":767,"authors":772,"heroImage":768,"date":773,"body":774,"category":10,"tags":775},[727],"2025-03-13","本講演のテーマは、ソフトウェア開発の現場が抱えている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",[279,776,9,732,681],"inside GitLab",{"slug":778,"featured":91,"template":686},"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":784,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":785,"content":791,"config":799,"_id":801,"_type":14,"title":802,"_source":16,"_file":803,"_stem":804,"_extension":19},"/ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"title":786,"description":787,"ogTitle":786,"ogDescription":787,"noIndex":6,"ogImage":788,"ogUrl":789,"ogSiteName":670,"ogType":671,"canonicalUrls":789,"schema":790},"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":786,"description":787,"authors":792,"heroImage":788,"date":795,"body":796,"category":698,"tags":797,"updatedDate":798},[793,794],"Rutvik Shah","Michael Friedrich","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/eighteen/)）\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/)",[681,709,9,732,708],"2024-11-15",{"slug":800,"featured":91,"template":686},"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":806,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":807,"content":813,"config":819,"_id":821,"_type":14,"title":822,"_source":16,"_file":823,"_stem":824,"_extension":19},"/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"title":808,"description":809,"ogTitle":808,"ogDescription":809,"noIndex":6,"ogImage":810,"ogUrl":811,"ogSiteName":670,"ogType":671,"canonicalUrls":811,"schema":812},"GitLab Duo開発の現場から： AIモデルの大規模な検証とテスト方法","LLMをどのように評価し、ユースケースに適合させ、ユーザーにとってより良い回答が得られるように微調整しているのか。その舞台裏をご紹介します。","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-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":808,"description":809,"authors":814,"heroImage":810,"date":816,"body":817,"category":698,"tags":818,"updatedDate":795},[815],"Susie Bitters","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/eighteen/)\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",[681,9,732,708,776],{"slug":820,"featured":91,"template":686},"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":826,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":827,"content":832,"config":839,"_id":841,"_type":14,"title":842,"_source":16,"_file":843,"_stem":844,"_extension":19},"/ja-jp/blog/developing-gitlab-duo-series",{"title":828,"description":829,"ogTitle":828,"ogDescription":829,"noIndex":6,"ogImage":810,"ogUrl":830,"ogSiteName":670,"ogType":671,"canonicalUrls":830,"schema":831},"「GitLab Duo開発の現場から」シリーズ","プロダクトチームとエンジニアリングチームが執筆するこのブログシリーズでは、AIイノベーションの舞台裏をご紹介するとともに、DevSecOpsワークフローを支える最新のAI機能を詳しく解説します。","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":828,"description":829,"authors":833,"heroImage":810,"date":835,"body":836,"category":698,"tags":837,"updatedDate":838},[834],"GitLab Team","2024-06-03","生成AIは、ソフトウェアの開発、保護、運用を容易にし、ソフトウェア開発業界に重要な変化をもたらしています。GitLabの製品チームとエンジニアリングチームが手掛ける新しいブログシリーズでは、企業全体に統合すべきAI機能をどのように作成、テスト、そしてデプロイするか明らかにし、DevSecOpsチームがよりよいソフトウェアを顧客に届ける上で、GitLab Duoの新機能がどのように役立つのかご理解いただける内容になっています。\n\n> デモ動画公開！GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を体験しませんか？ [今すぐ登録する](https://about.gitlab.com/ja-jp/eighteen/)\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機能が、いかに迅速に脆弱性に対応するかを解説します。",[681,708,9,732],"2025-01-21",{"slug":840,"featured":6,"template":686},"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":846,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":847,"content":853,"config":860,"_id":862,"_type":14,"title":863,"_source":16,"_file":864,"_stem":865,"_extension":19},"/ja-jp/blog/enhance-application-security-with-gitlab-hackerone",{"title":848,"description":849,"ogTitle":848,"ogDescription":849,"noIndex":6,"ogImage":850,"ogUrl":851,"ogSiteName":670,"ogType":671,"canonicalUrls":851,"schema":852},"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":848,"description":849,"authors":854,"heroImage":850,"date":856,"body":857,"category":682,"tags":858},[855],"Fernando Diaz","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/application-security-testing/)\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",[682,709,233,284,732,9,859],"bug bounty",{"slug":861,"featured":6,"template":686},"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":867,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":868,"content":873,"config":881,"_id":883,"_type":14,"title":884,"_source":16,"_file":885,"_stem":886,"_extension":19},"/ja-jp/blog/event-report-aws-summit-2025",{"config":869,"ogImage":870,"title":871,"description":872},{"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":874,"description":875,"authors":876,"date":877,"body":878,"category":10,"heroImage":870,"tags":879},"GitLab with Amazon Qで開発スピードを高め、AI生成コードの品質を担保する【イベントレポート】","この記事ではAWS Summit Japan 2025に出展した際に「GitLab with Amazon Q」について語ったセッションの模様をお伝えします。",[727],"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のキーホルダー*",[880,681,706,707,733,9,279,682,734],"AWS",{"featured":91,"template":686,"slug":882},"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":888,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":889,"content":895,"config":900,"_id":902,"_type":14,"title":903,"_source":16,"_file":904,"_stem":905,"_extension":19},"/ja-jp/blog/event-report-devopsdive2024summer",{"title":890,"description":891,"ogTitle":890,"ogDescription":891,"noIndex":6,"ogImage":892,"ogUrl":893,"ogSiteName":670,"ogType":671,"canonicalUrls":893,"schema":894},"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":890,"description":891,"authors":896,"heroImage":892,"date":897,"body":898,"category":10,"tags":899},[727],"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)",[279,776,9,732],{"slug":901,"featured":6,"template":686},"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":907,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":908,"content":914,"config":920,"_id":922,"_type":14,"title":923,"_source":16,"_file":924,"_stem":925,"_extension":19},"/ja-jp/blog/event-report-gartner-application-innovation-2025",{"config":909,"ogImage":910,"title":911,"description":912,"ogDescription":913},{"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":911,"description":915,"heroImage":910,"date":916,"body":917,"category":10,"tags":918,"authors":919},"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*イベントで配られたノベルティ*",[733,681,707,9,279,551,682,734],[727],{"featured":91,"template":686,"slug":921},"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":927,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":928,"content":934,"config":939,"_id":941,"_type":14,"title":942,"_source":16,"_file":943,"_stem":944,"_extension":19},"/ja-jp/blog/event-report-gartner-it-infra-2024",{"title":929,"description":930,"ogTitle":929,"ogDescription":930,"noIndex":6,"ogImage":931,"ogUrl":932,"ogSiteName":670,"ogType":671,"canonicalUrls":932,"schema":933},"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":929,"description":930,"authors":935,"heroImage":931,"date":936,"body":937,"category":10,"tags":938},[727],"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/)",[9,682,279],{"slug":940,"featured":91,"template":686},"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":946,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":947,"content":951,"config":957,"_id":959,"_type":14,"title":960,"_source":16,"_file":961,"_stem":962,"_extension":19},"/ja-jp/blog/event-report-gartner-security-risk-management-2025",{"noIndex":6,"title":948,"ogTitle":948,"description":949,"ogImage":950},"コード生成AIのリスク管理とポテンシャル最大化【レポート】","ガートナー セキュリティ＆リスク・マネジメントサミット2025で登壇したGitLab吉瀬 淳一のセッション内容をレポート。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480526/wk05yajf5e4bmwuygve7.jpg",{"date":952,"authors":953,"title":954,"description":949,"heroImage":950,"category":10,"tags":955,"body":956},"2025-09-10",[727],"コード生成AIのリスクを管理し、ポテンシャルを最大限に引き出す【イベントレポート】",[681,706,9,279,682],"GitLabは2025年7月23～25日の3日間、都内ホテルで開催された「ガートナー セキュリティ ＆ リスク・マネジメント サミット2025」に出展しました。本記事では、GitLabシニア・ソリューション・アーキテクト 吉瀬 淳一が登壇したセッションの模様についてレポートします。\n\n![ガートナー セキュリティ ＆ リスク・マネジメント サミット2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480502/dy6lgmfb1oihyvrjcxqx.jpg)\n\n*会場の様子*\n\nこの日の講演は、コード生成AIの話が中心です。まずは会社の話から入ったのですが、吉瀬は比較的社歴の浅いエンジニアで、働き方の紹介もユニークでした。GitLabは、全世界の全従業員がリモートで働いていることで知られています。実際に、GitLab社員の多くは、お客様やパートナー様から「よく聞くけれど、本当にそうなの？」と尋ねられた経験をしています。\n\n吉瀬は、「GitLabには本社がありません。世界中のどこを探しても、オフィスすらありません。私の場合も、入社が決まると会社のPCが送られてきて、GitLabでの生活が始まりました。入社した当日から、いきなり1人ぼっちです」と話して、会場の空気を和ませました。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480501/glglfhj8thtnkdsgqn8j.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\n## セキュリティ対策の全体像とシフトレフトの重要性\n\nソフトウェア開発においてコード生成AIを活用する前に、プロジェクトにおいてセキュリティをどう担保するかについて決めていく必要があります。その際に、セキュリティ対策の全体像を分解し、企画、開発、運用という大きく3つのくくりで詳細を決めることが必要です。\n\n![企業が取り組むべきセキュリティ対策の全体像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757386735/vqy6xhnubpvwjnsfcxvc.png)\n\n*スライド：企業が取り組むべきセキュリティ対策の全体像*\\\n\\\n企画は、いわゆる統制やガバナンスのようなもの。企業全体、もしくはプロジェクト全体としてのルールを、ここで決めます。開発は、コードを生み出す段階での対策です。脆弱性検査の自動化やセキュアコーディングの標準化などがこれに当たります。運用におけるセキュリティ対策は、実行環境を守る手段を指します。エンドポイントセキュリティやネットワーク監視、ID管理、ログ管理などです。\n\nそして、これらの中で、最も課題が多いのは開発の部分になります。吉瀬は、「開発課題が大きい理由のひとつは、実際の開発を外部委託していることでしょう。委託先が何をやってるのか見えにくいのです。ただ、この部分の改革に取り組んでいかなければ、本当の意味でのセキュリティを守ることはできません」と話します。\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480501/eskdwrakqm2n7t2bsocq.jpg)\n\n*スライド：デジタル庁が提示する「セキュリティ・バイ・デザイン」の原則*\\\n\\\nそのためにも、シフトレフトが重要になります。開発の上流工程で対策を講じることで、デプロイ後に脆弱性が見つかって対応するなどの手戻りは大幅に低減します。さらに、品質の向上につながることも期待できます。実際に、デジタル庁が公開した『政府情報システムのためのセキュリティ・バイ・デザインガイドライン』でも、開発のなるべく早い段階にセキュリティを担保するプロセスを組み込み、問題点を潰していくことの重要性がうたわれています。\n\n「現在、多くの日本企業は“事故が起きてからどうするかを考える”というセキュリティ対策を重視する傾向があるようです。それももちろん大切なのですが、偏りすぎると問題です。開発から運用に至るプロセスは左から右へと図示されますが、左側の開発段階でもやれることは数多くあります。きちんとシフトレフトして、開発の上流工程も最適化する方向で考えるべきです」（吉瀬）\n\n## 生成AIを活用するエンジニアはすでに100%！？\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480501/ns3x4ai53zkqjkbrcn5z.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\nその最適化すべき“左側”で、生成AIは大きなムーブメントになっています。吉瀬は、「生成AIを活用しているエンジニアは、ほぼ100%と言ってもいいくらい」と話します。「ソフトウェア開発にAIを使っていると答えた組織の割合が78%という調査結果がありますが、よく見てください。 “組織”ですよ。個人のレベルになるとどうでしょう。組織としては、人が書いていると思っているけれど、実はその人がAIを使っているケースは多いでしょう。なにしろ、生産性が桁違いですから」。\n\n一方、GitLabの調査をまとめた『[2024グローバルDevSecOpsレポート](https://about.gitlab.com/ja-jp/developer-survey/)』によると、ソフトウェアエンジニアがコードを書く時間は、全就業時間の21%にとどまっています。残りの79%は脆弱性の対応やテスト、トラブルシューティング、打ち合わせなど。ここに、生成AIを導入してる企業の開発生産性が2割程度しか上がらない原因があります。全体の21%を占める部分の生産性が10倍になっても、残りの79%がボトルネックになり、全体的な生産性は上がらないのです。\n\n![スライド：AI生成コードの脆弱性とセキュリティリスクの急増](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757386736/syfahxrakeeqlpyurjlv.png)\n\n*スライド：AI生成コードの脆弱性とセキュリティリスクの急増*\\\n\\\nさらに、生成AIのはらむセキュリティリスクに注意が必要です。上図に示したように、懸念点は大きく3つ。まず、AIが生成するコードには脆弱性が含まれがちです。次に、エンジニアは脆弱性が含まれていることは認識できるものの、その発見や対処法に自信を持っていません。最後に、マネジメントは、社内でAIがどういう扱われ方をしていて、どんなリスクが発生しているかをつかみきれていません。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480496/zs5kufi2hwvlvchjhiws.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\nさらに問題を大きくしているのが、AIのサイロ化です。ソフトウェア開発プロセスでは、さまざまなツールが使用されます。そしていま、各ツールの裏でAIが動くようになりました。これらのAIが、IssueやEpic、マージリクエストの議論、過去の変更履歴といった開発の全体的なコンテキストを把握できないことが問題なのです。プロセスの中には、特定の脆弱性を修正する目的のIssueがあります。しかし、コード生成AIはその背景を知りません。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のAIは単にテストの成否だけを見ます。この状況では、「脆弱性を修正する」という本来の修正意図が反映されているかどうかを判断できません。“開発の文脈”を理解しないまま、各ツール上だけで動くAIが部分的な判断を下すことで、本質的な問題が見過ごされてしまうリスクが高まってしまうのです。\n\n## 単一のプラットフォームでソフトウェア開発ライフサイクル全体を管理する\n\nこうした状況を抜本的に解決するために、 GitLabは単一のプラットフォームでソフトウェア開発ライフサイクル全体を管理するというアプローチを採ります。企画、開発、運用にまたがるセキュリティ対策全体を鳥瞰する包括的な解決策であり、コードの脆弱性、開発者の信頼性、ガバナンスという3つの懸念点もクリアできます。\n\n![スライド：セキュアなAI活用を実現するDevSecOpsプラットフォーム](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757386735/rhpuem4bdeja6c2hr7iv.png)\n\n*スライド：セキュアなAI活用を実現するDevSecOpsプラットフォーム*\\\n\\\nGitLabのソリューションにおいて、生成AIを活用した開発プロジェクトのシフトレフトを支える中心になるのが、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)の[コードレビュー&修正支援機能](https://player.vimeo.com/video/929891003?badge=0&autopause=0&player_id=0&app_id=58479/)です。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)では、人間がレビューする前にAIがコードを自動チェックし、脆弱性を指摘します。さらに、脆弱性が生まれた原因と具体的な修正方法までAIが提案することで、脆弱性発生リスクを極小化することができます。開発段階において[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を利用することで、セキュアなコード開発を促進する体制が自然に生まれることになります。\n\nGitLab上でプロセスを整え、ルール化を徹底すれば、シフトレフトは自然に推進されます。たとえば、パイプラインポリシーを整備すれば、開発者のスキルや意識に依存しない一貫したセキュリティレベルを担保できます。コードのコミットをトリガーに多様なセキュリティスキャンを自動実行するなど、適切なタイミングでセキュリティスキャンするプロセスを組織に根付かせることもできます。開発プロセスを最適化し続けることで、問題を早期に発見し、対処できる強固な体制が生まれます。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480495/ocag236gff9qw5bvaoxx.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\nGitLabのAIはプラットフォームとしての強みを生かし、一貫したコンテキストにもとづいて全体に対する有益な示唆を与えてくれます。GitLabを単一データストアとして、開発の全工程のデータを一元管理しておけば、AIが“全体の文脈”を理解できます。コードの関連性を把握し、変更の影響範囲もスピーディに指摘してくれます。サイロ化されたツールでは不可能な、一貫性のある高度な支援が可能になるのです。\n\nさらに、GitLabのAIポリシーは、極めて透明性の高いものです。[GitLabのAIは、「顧客のデータを学習データとして利用しない」など、企業の知的財産を守る明確なポリシーを設けています](https://about.gitlab.com/ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops/#%E3%83%87%E3%83%BC%E3%82%BF%E3%82%AC%E3%83%90%E3%83%8A%E3%83%B3%E3%82%B9%EF%BC%9A%E8%87%AA%E5%88%86%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AF%E8%87%AA%E5%88%86%E3%81%A7%E5%AE%88%E3%82%8B)。ユーザーは、安心して最先端のAI技術を活用することも可能ですし、よりセキュアな環境を求める場合は、オンプレミス環境におけるローカルLLM運用にも対応しています。\n\n## 一貫したコンテキストの中でAIの力を最大限に生かす\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480495/nlqrw5sadygg4blh3ln3.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一*\n\nコード生成AIは、開発を加速させる強力な武器です。ただし、正しく活用すれば、であることに注意が必要です。コード生成AIのポテンシャルを最大限に引き出し、同時にリスクを管理するために必要な要素は、ここまで述べてきたとおりです。つまり、開発ライフサイクル全体を俯瞰し、一貫したルールとコンテキストのもとでAIを機能させる、GitLabのような統合プラットフォームが不可欠なのです。\n\n吉瀬は、「生成AIの時代は始まったばかりで、これからどんどん広まっていくでしょう。ひとりの開発者が生み出すコードの量は、これまでに比べると凄まじく増えます。生産性はどんどん高まります。すばらしいことです」と話します。\n\n「確かに、生成AIの書いたコードに脆弱性が大量に含まれているというリスクはありますが、生産性とリスクのバランスを考えると、AIを使わないという選択肢はありえません。だからこそ、コードのレビューや脆弱性の修正にもAIを使い、パイプラインポリシーのシフトレフトをきちんとやる必要があるのです。プラットフォームを統合して、一貫したコンテキストの中でAIの力を最大限に生かしていきましょう。これがGitLabからのメッセージです」（吉瀬）\n\n![イベントで配られたノベルティ（水筒）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480495/yibqr6h9osxu0nqyxxdu.jpg)\n\n*イベントで配られたノベルティ（水筒）*\n\n![イベントで配られたノベルティ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480495/kx2htmmgdnrwqsdctif5.jpg)\n\n*イベントで配られたノベルティ（スニーカー）*",{"featured":91,"template":686,"slug":958},"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":964,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":965,"content":971,"config":976,"_id":978,"_type":14,"title":979,"_source":16,"_file":980,"_stem":981,"_extension":19},"/ja-jp/blog/event-report-japan-it-week-autumn",{"title":966,"description":967,"ogTitle":966,"ogDescription":967,"noIndex":6,"ogImage":968,"ogUrl":969,"ogSiteName":670,"ogType":671,"canonicalUrls":969,"schema":970},"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":966,"description":967,"authors":972,"heroImage":968,"date":973,"body":974,"category":10,"tags":975},[727],"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",[279,776,9,732],{"slug":977,"featured":91,"template":686},"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":983,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":984,"content":990,"config":995,"_id":997,"_type":14,"title":998,"_source":16,"_file":999,"_stem":1000,"_extension":19},"/ja-jp/blog/event-report-japan-it-week-spring-1",{"title":985,"description":986,"ogTitle":985,"ogDescription":986,"noIndex":6,"ogImage":987,"ogUrl":988,"ogSiteName":670,"ogType":671,"canonicalUrls":988,"schema":989},"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":985,"description":986,"authors":991,"heroImage":987,"date":992,"body":993,"category":10,"tags":994},[727],"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/application-security-testing/)をDevOpsのプロセスに組み込むものです。[セキュリティ](https://about.gitlab.com/ja-jp/solutions/application-security-testing/)／コンプライアンスの重要性が高まり、“説明可能な”[セキュリティ](https://about.gitlab.com/ja-jp/solutions/application-security-testing/)が求められるいま、多くの日本企業が注目し、アーリーアダプターが成果を出し始めています。そして、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/application-security-testing/)を含めた開発プロセスすべてを管理できます。\n\nさらに、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/application-security-testing/)機能として最も重視される脆弱性の早期検知においても、強力なエンジンを提供しています。この機能はテストプロセスの後に組み込まれ、開発してすぐテストするというDevOpsの流れをそのまま持ち込めば、開発者は自分の書いたコードや使用するライブラリに脆弱性が含まれるかどうかをすぐに理解することができます。計画段階においてはイシューに要件を付加しておけば、どのレベルの[セキュリティ](https://about.gitlab.com/ja-jp/solutions/application-security-testing/)が必要かどうかを振り返って判断することもでき、レビュー時に再確認することも容易です。自動化と人手による検証をどちらも可能にし、開発からリリースに至る全工程に[セキュリティ](https://about.gitlab.com/ja-jp/solutions/application-security-testing/)を持ち込み、必要なところは自動化できるようになるのです。\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/)＞",[279,776,9,732],{"slug":996,"featured":91,"template":686},"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":1002,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1003,"content":1009,"config":1014,"_id":1016,"_type":14,"title":1017,"_source":16,"_file":1018,"_stem":1019,"_extension":19},"/ja-jp/blog/event-report-japan-it-week-spring-2",{"title":1004,"description":1005,"ogTitle":1004,"ogDescription":1005,"noIndex":6,"ogImage":1006,"ogUrl":1007,"ogSiteName":670,"ogType":671,"canonicalUrls":1007,"schema":1008},"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":1004,"description":1005,"authors":1010,"heroImage":1006,"date":1011,"body":1012,"category":10,"tags":1013},[727],"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",[279,776,9,732],{"slug":1015,"featured":91,"template":686},"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":1021,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1022,"content":1025,"config":1034,"_id":1036,"_type":14,"title":1037,"_source":16,"_file":1038,"_stem":1039,"_extension":19},"/ja-jp/blog/gitlab-and-accenture-announce-global-reseller-agreement",{"noIndex":6,"title":1023,"description":1024},"GitLabとAccentureがグローバル販売代理店契約を発表","Accentureが包括的なDevSecOpsプラットフォームの提供を可能にする販売代理店契約を締結",{"heroImage":1026,"body":1027,"authors":1028,"updatedDate":1030,"date":1031,"title":1023,"tags":1032,"description":1024,"category":683},"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の営業担当にお問い合わせください。",[1029],"GitLab","2025-09-17","2025-09-15",[683,1033,9],"product",{"featured":6,"template":686,"slug":1035},"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":1041,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1042,"content":1045,"config":1054,"_id":1056,"_type":14,"title":1057,"_source":16,"_file":1058,"_stem":1059,"_extension":19},"/ja-jp/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"noIndex":6,"title":1043,"description":1044},"GitLab Duoエージェントプラットフォーム","GitLab Duoエージェントプラットフォームは自律型AIを活用し、ソフトウェア開発ライフサイクルにわたる人間とAIエージェントのコラボレーションを実現。",{"heroImage":1046,"title":1047,"description":1048,"authors":1049,"date":1051,"body":1052,"category":698,"tags":1053},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750687578/esmflevxk5bf3eezjhwk.png","GitLab Duo Agent Platform","GitLab Duo Agent Platformは自律型AIを活用し、ソフトウェア開発ライフサイクルにわたる人間とAIエージェントのコラボレーションを実現。",[1050],"Bill Staples","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/)",[9],{"featured":91,"template":686,"slug":1055},"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":1061,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1062,"content":1068,"config":1075,"_id":1077,"_type":14,"title":1078,"_source":16,"_file":1079,"_stem":1080,"_extension":19},"/ja-jp/blog/gitlab-flow-duo",{"title":1063,"description":1064,"ogTitle":1063,"ogDescription":1064,"noIndex":6,"ogImage":1065,"ogUrl":1066,"ogSiteName":670,"ogType":671,"canonicalUrls":1066,"schema":1067},"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":1063,"description":1064,"authors":1069,"heroImage":1065,"date":1071,"body":1072,"category":698,"tags":1073,"updatedDate":1074},[1070],"Cesar Saavedra","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/eighteen/)\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合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト）*",[109,681,9],"2024-08-28",{"slug":1076,"featured":6,"template":686},"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":1082,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1083,"content":1089,"config":1095,"_id":1097,"_type":14,"title":1098,"_source":16,"_file":1099,"_stem":1100,"_extension":19},"/ja-jp/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"title":1084,"description":1085,"ogTitle":1084,"ogDescription":1085,"noIndex":6,"ogImage":1086,"ogUrl":1087,"ogSiteName":670,"ogType":671,"canonicalUrls":1087,"schema":1088},"『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":1084,"description":1085,"authors":1090,"heroImage":1086,"date":1091,"body":1092,"category":698,"tags":1093},[675],"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",[683,681,9,1094],"research",{"slug":1096,"featured":91,"template":686},"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":1102,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1103,"content":1109,"config":1117,"_id":1119,"_type":14,"title":1120,"_source":16,"_file":1121,"_stem":1122,"_extension":19},"/ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"title":1104,"description":1105,"ogTitle":1104,"ogDescription":1105,"noIndex":6,"ogImage":1106,"ogUrl":1107,"ogSiteName":670,"ogType":671,"canonicalUrls":1107,"schema":1108},"『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":1104,"description":1105,"authors":1110,"heroImage":1106,"date":1112,"body":1113,"category":683,"tags":1114,"updatedDate":1116},[1111],"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/application-security-testing/)を組み込んでいます。これにより、チームは脆弱性を早期に発見し、リリースサイクルを迅速化できます。さらに、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の文書を参照するには、同社への開示リクエストが必要になります。***",[683,1094,732,1115,9],"DevOps","2024-10-24",{"slug":1118,"featured":91,"template":686},"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":1124,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1125,"content":1129,"config":1136,"_id":1138,"_type":14,"title":1139,"_source":16,"_file":1140,"_stem":1141,"_extension":19},"/ja-jp/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants",{"config":1126,"title":1127,"description":1128},{"noIndex":6},"『2025 Gartner® Magic Quadrant™ for AI Code Assistants』でGitLabがリーダーの1社として評価されました","Gartner® Magic Quadrant™の同部門において、GitLabは2年連続でリーダーの1社に選出され、AIコードアシスタント技術における実行能力とビジョンの完全性が評価されました。",{"title":1130,"description":1128,"heroImage":1131,"authors":1132,"date":1030,"body":1134,"category":683,"tags":1135},"『2025年Gartner® Magic Quadrant™ for AI Code Assistants』でGitLabがリーダーの1社として評価されました","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757675943/q9kb7zfiw1cyxx9fcafp.png",[1133],"Manav Khurana","『2025年Gartner® Magic Quadrant™ for AI Code Assistants』で、GitLabが再びリーダーの1社として評価されました。この評価は、私たちのAI戦略の重要な柱が認められたと認識させるものと考えています。インテリジェントなコード支援から始まり、チーム全体がソフトウェアを計画・構築・保護・デプロイする方法を変革する包括的なAIへと進化させていく戦略です。\n![『2025 Gartner® Magic Quadrant™ for AI Code Assistants』](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758121248/jfkmhddve6qvlg79xico.png)\n> [『2025 Gartner® Magic Quadrant™ for AI Code Assistants』レポートをダウンロードする](https://about.gitlab.com/gartner-mq-ai-code-assistants/)\n## AI機能からインテリジェントな協働へ\n\n今回のGartnerによる評価では、GitLab Duoの生成AIコード支援機能に重点が置かれたと考えております。GitLab DuoはGitLab DevSecOpsプラットフォームへのAI搭載機能として始まりましたが、現在のGitLab DevSecOpsプラットフォームにネイティブに構築されたエージェント型AIへの発展の基盤を築きました。\n\nGitLab Duo Agent Platformより、デベロッパーはソフトウェアライフサイクル全体にわたってタスクを自動化する複数のAIエージェントと連携できます。エージェントは相互に、そして人間と協力し、GitLabのナレッジグラフを活用してプロジェクト全体の文脈を把握して行動します。これにより、チームは可視性とコントロールを維持しながら、より迅速に作業を進められます。\n\n* **専門エージェント**が、コード生成、セキュリティ分析、調査などのタスクを並行して処理します。\n\n* **ナレッジグラフ**により、エージェントはコード、イシュー、パイプライン、コンプライアンスデータ全体にわたる統合された記録システムに接続されます。\n\n* **人間とエージェントの協働**は、自然言語チャットとカスタマイズ可能なワークフローにより実現され、レビューと監視が組み込まれています。\n\n* **外部ツールやシステムとの相互運用性**は、Model Context Protocol（MCP）とエージェント間フレームワークを通じてサポートされます。\n\nエージェント型AIが人間の指導の下で定型的な作業を処理することで、チームはより迅速に作業を進め、より価値の高いタスクに集中し、プロジェクトの安全性とコンプライアンスを維持できます。\n\n## 設計時からセキュリティを組み込み、実践では柔軟に対応\n\nGitLab Duo Agent Platformは、セキュリティとコンプライアンスを最優先に設計されています。エージェントはGitLabの信頼されるDevSecOps環境内で動作し、すべてのアクションは変更が行われる前に可視化・レビュー可能です。セキュアな統合により認証情報と機密データが安全に処理され、オープンスタンダードを通じた相互運用性により、組織をリスクにさらさずにエージェントを外部ツールに接続できます。\n\nこのプラットフォームを使えば、ガバナンスを損なうことなくAIで生産性を高められるため、チームは安心して導入できます。その仕組みは以下の通りです：\n\n* **デベロッパー**は、複雑で影響力の大きい作業に集中し続けながら、定型的なタスクをエージェント型AIに委ねることで、より迅速な結果だけでなく、既存のワークフローを通じて提供される詳細な文脈を得られます。\n\n* **エンジニアリングリーダー**は、設定された範囲内でエージェント型AIが安全に動作する中で、ライフサイクル全体にわたって作業の進捗を可視性できます。これにより、チームは重要なタスクに注力できるようになり、エージェント型AIが提供するコンテクストに応じたワークフローのガンダンスによって、オンボーディングを簡素化できます。\n\n* **IT組織**は、コーディングとセキュリティポリシーを適用しながら、AIモデルを柔軟に選択し、セキュアな相互運用性を確保するガバナンス機能を活用して、エージェント型AIの活動を制御できます。重要なのは、すべてのプロセスに人間の判断が介在するということです。\n\n## AI機能の新境地を切り開く\n\nGitLabは、Duoから始まったビジョンを継続的に発展させ、新しいエージェント型AI機能、高度なワークフロー、さらなるオーケストレーション機能でGitLab Duo Agent Platformを拡張し続けます。このイノベーションへの取り組みにより、お客様が知り、信頼するプラットフォーム上でチームの生産性を最大化できます。AI機能をDevSecOpsに統合し続ける、GitLabのロードマップの最新情報に今後もご注目ください。\n\n> [『2025 Gartner® Magic Quadrant™ for AI Code Assistants』レポートをダウンロード](https://about.gitlab.com/gartner-mq-ai-code-assistants/)して、[GitLab Duo Agent Platformを今すぐお試しください](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)\n\n*出典: Gartner, Magic Quadrant for AI Code Assistants, Philip Walsh, Haritha Khandabattu, Matt Brasier, Keith Holloway, Arun Batchu, 15 September 2025*\n\n*GARTNERは、Gartner, Inc.および/または米国とその他の国におけるその関連会社の商標およびサービスマークであり、MAGIC QUADRANTは、Gartner, Inc.および/またはその関連会社の登録商標であり、本書では許可を得て使用しています。All rights reserved.*\n\n*この図表は、Gartner, Inc.がリサーチの一部として公開したものであり、文書全体のコンテクストにおいて評価されるべきものです。オリジナルのGartnerドキュメントは、リクエストにより GitLabからご提供することが可能です。*\n\n*Gartnerは、Gartnerリサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティング又はその他の評価を得たベンダーのみを選択するようにテクノロジーユーザーに助言するものではありません。Gartnerリサーチの発行物は、Gartnerリサーチの見解を表したものであり、事実を表現したものではありません。Gartnerは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の責任を負うものではありません。*",[1033,683,9],{"featured":91,"template":686,"slug":1137},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants","content:ja-jp:blog:gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants.yml","Gitlab Named A Leader In The 2025 Gartner Magic Quadrant For Ai Code Assistants","ja-jp/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants.yml","ja-jp/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants",{"_path":1143,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1144,"content":1147,"config":1155,"_id":1157,"_type":14,"title":1158,"_source":16,"_file":1159,"_stem":1160,"_extension":19},"/ja-jp/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":1145,"title":1146},"GitLabとIBMの新しいソリューションは、シームレスな統合、CI/CDランナーサポート、エンドツーエンドの可視性、およびコスト効率により、メインフレームとクラウドネイティブ開発を橋渡しします。","GitLab Ultimate for IBM Z：メインフレーム向けモダンDevSecOps",{"title":1146,"description":1145,"body":1148,"category":1033,"tags":1149,"authors":1150,"heroImage":1153,"date":1154},"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/)をご覧ください。",[284,1033,109,9],[1151,1152],"Mike Flouton","Andy Bradfield","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png","2025-06-20",{"featured":91,"template":686,"slug":1156},"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":1162,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1163,"content":1169,"config":1176,"_id":1178,"_type":14,"title":1179,"_source":16,"_file":1180,"_stem":1181,"_extension":19},"/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"title":1164,"description":1165,"ogTitle":1164,"ogDescription":1165,"noIndex":6,"ogImage":1166,"ogUrl":1167,"ogSiteName":670,"ogType":671,"canonicalUrls":1167,"schema":1168},"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":1164,"description":1165,"authors":1170,"heroImage":1166,"date":1172,"body":1173,"category":698,"tags":1174,"updatedDate":1175},[1171],"David O'Regan","2024-05-30","___生成系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/eighteen/)\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",[681,9,709,682],"2024-10-10",{"slug":1177,"featured":6,"template":686},"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":1183,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1184,"content":1190,"config":1197,"_id":1199,"_type":14,"title":1200,"_source":16,"_file":1201,"_stem":1202,"_extension":19},"/ja-jp/blog/introducing-the-source-insights-for-the-future-of-software-development",{"title":1185,"description":1186,"ogTitle":1185,"ogDescription":1186,"noIndex":6,"ogImage":1187,"ogUrl":1188,"ogSiteName":670,"ogType":671,"canonicalUrls":1188,"schema":1189},"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":1185,"description":1186,"authors":1191,"heroImage":1187,"date":1193,"body":1194,"category":683,"tags":1195,"updatedDate":1196},[1192],"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/)にアクセスし、最新の洞察や組織運営に関する疑問への答えを入手し、新たに学んだことをチームと共有しましょう。また、ニュースレターをご購読いただくと、定期的に最新情報をお届けします。先進的なテクノロジーリーダーが集うコミュニティに参加して、ともにソフトウェア開発の未来を形作りましょう。",[681,682,683,9],"2025-03-28",{"slug":1198,"featured":91,"template":686},"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":1204,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1205,"content":1211,"config":1217,"_id":1219,"_type":14,"title":1220,"_source":16,"_file":1221,"_stem":1222,"_extension":19},"/ja-jp/blog/jenkins-to-gitlab-migration-made-easy",{"title":1206,"description":1207,"ogTitle":1206,"ogDescription":1207,"noIndex":6,"ogImage":1208,"ogUrl":1209,"ogSiteName":670,"ogType":671,"canonicalUrls":1209,"schema":1210},"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":1206,"description":1207,"authors":1212,"heroImage":1208,"date":1213,"body":1214,"category":10,"tags":1215,"updatedDate":1216},[855],"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",[109,9],"2025-04-15",{"slug":1218,"featured":91,"template":686},"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":1224,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1225,"content":1231,"config":1238,"_id":1240,"_type":14,"title":1241,"_source":16,"_file":1242,"_stem":1243,"_extension":19},"/ja-jp/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions",{"title":1226,"description":1227,"ogTitle":1226,"ogDescription":1227,"noIndex":6,"ogImage":1228,"ogUrl":1229,"ogSiteName":670,"ogType":671,"canonicalUrls":1229,"schema":1230},"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":1226,"description":1227,"authors":1232,"heroImage":1228,"date":1233,"body":1234,"category":698,"tags":1235,"updatedDate":1237},[794],"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",[9,1236,709,710,681],"careers","2025-01-24",{"slug":1239,"featured":6,"template":686},"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":1245,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1246,"content":1252,"config":1259,"_id":1261,"_type":14,"title":1262,"_source":16,"_file":1263,"_stem":1264,"_extension":19},"/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"title":1247,"description":1248,"ogTitle":1247,"ogDescription":1248,"noIndex":6,"ogImage":1249,"ogUrl":1250,"ogSiteName":670,"ogType":671,"canonicalUrls":1250,"schema":1251},"GitLab Duo Workflowの紹介 - AI主導の開発の未来","自律型AIエージェントであるWorkflowは、チームがソフトウェアを構築してデリバリーする方法に変革をもたらします。Workflowの登場により、GitLabはAI主導のDevSecOpsの実現に向けた強力な最初の一歩を踏み出します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658912/Blog/Hero%20Images/blog-image-template-1800x945__20_.png","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":1247,"description":1248,"authors":1253,"heroImage":1249,"date":1255,"body":1256,"category":698,"tags":1257,"updatedDate":1258},[1254],"David DeSanto, Chief Product Officer, GitLab","2024-06-27","ソフトウェアのコードを、ソフトウェア自らが作成できるとしたらどうでしょう？それは遠い未来でしか実現できないことのように思えますが、絶えず成長する大規模言語モデル（LLM）とGitLabの一元化されたAI搭載のDevSecOpsプラットフォームにより、その未来は間近に迫っています。GitLabは、[GitLab 17のリリースイベント](https://about.gitlab.com/eighteen/)で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",[681,732,9,683,710],"2024-08-15",{"slug":1260,"featured":91,"template":686},"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":1266,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1267,"content":1271,"config":1279,"_id":1281,"_type":14,"title":1282,"_source":16,"_file":1283,"_stem":1284,"_extension":19},"/ja-jp/blog/monday-merge-2025-august-11",{"config":1268,"title":1269,"description":1270},{"noIndex":6},"Monday Merge 8月号","Monday Merge8月号では、",{"date":1272,"title":1269,"category":683,"tags":1273,"body":1275,"authors":1276,"description":1277,"heroImage":1278},"2025-08-11",[109,681,880,707,269,733,9,279,708,683,1274,682,734],"releases","GitLabコミュニティのみなさん、こんにちは！今月もソフトウェア開発の最新トレンドをお届けします。\n\n今回のトピックはこちら：\n\n* GitLab Duo Agent Platformのパブリックベータ版がスタート：AIともっとスマートに働く方法とは\n* 現場のニーズに応える最新GitLabリリース情報\n* 世界2,786名のCレベル層に聞いた、AIとソフトウェアイノベーションに関する意識調査\n* 注目イベントやおすすめコンテンツ、NatWest社の導入事例もご紹介\n\nそれでは、さっそく見ていきましょう⚓\n\n# **GitLab Duo Agent Platform：パブリックベータ版がついに登場**\n\n![agent platform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369419/qascscd3p9azk7ros2nw.png)\n\n従来のAIアシスタントの概念を覆す新しい体験 ── GitLab Duo Agent Platformは、開発・セキュリティ・運用すべてをカバーする次世代のDevSecOpsオーケストレーションエンジンです。パブリックベータ版としての提供がスタートしました。\n\nこれは単なるIDE内のAIボットではありません。複数のAIエージェントがチームの一員として非同期に連携し、計画からリリースまでをトータルでサポートします。\n\n初期搭載されているエージェントは以下の通りです：\n\n* **Chat Agent**：自然言語での質問や汎用的な開発作業をサポート\n* **Developer Agent**：仮想開発環境でマージリクエストを作成\n* **Security Analyst Agent**：脆弱性の検出と修正提案\n* **Deep Research Agent**：リポジトリ全体を分析し、背景を踏まえたインサイトを提供\n* **Software Development Flow**：複数エージェントを連携させて一連の開発タスクを自動化\n\nGitLabのイシュー、パイプライン、CI/CDなど25以上の機能にネイティブにアクセスできるため、コンテキストを理解した精度の高い支援が可能です。さらに今後は、エージェントをカスタマイズし、複雑な作業を自動実行できる「フロー」も登場予定です。\n\nPremiumおよびUltimateプランをご利用中の方は、VS CodeやJetBrains IDEでベータ版を今すぐお試しいただけます。Web UIでも「Duo Agentic Chat」がすでに利用可能です。　\n\n▶︎ [GitLabがオーケストレーションプラットフォームとして持つ独自の強みについて、CEOのBill Staplesが語るインタビューはこちら。導入方法もあわせてご紹介しています。](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)\n\n[](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)\n\n# [](https://about.gitlab.com/blog/gitlab-duo-agent-platform-public-beta)**GitLab企業経営調査2025：AI・信頼・7,500億ドルの可能性**\n\n![$750+B](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/i8ccbygymqgrxno9vul5.png)\n\nAIは単なるトレンドではありません。世界の開発者2,700万人がAIを活用すれば、7,500億ドル以上の価値が生まれると言われています。最新のGitLab企業経営調査2025では、世界中の経営層2,786名にAIとソフトウェア開発の未来について調査を行いました。\n\n主な調査結果：\n\n* AI活用によって、開発者1人あたり年間28,249ドルのコスト削減を実現（世界中の開発者数で見積もると7,500億ドル規模に）\n* 89％の経営者が、今後3年以内にAIエージェントが業界標準になると予想\n* 懸念点は「サイバー攻撃（52%）」「データのプライバシーとセキュリティ（51%）」「ガバナンスの維持（45%）」\n* 92％が「社員がAIと協働できるようスキルトレーニングが必要」と回答\n\n📥 [レポート全文はこちらからダウンロードできます](https://about.gitlab.com/software-innovation-report)\n\n（日本に特化したレポートは近日中に公開予定）\n\n# **GitLab 18.2がリリースされました**\n\n![GitLab 18.2 Release ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/vdubujaphpphyk2n4wnw.png)\n\nGitLab 18.2では、30以上の新機能や改善が追加され、よりスピーディーかつ安全な開発が可能に。今回のアップデートにも、GitLabコミュニティから152件の貢献が寄せられました。ありがとうございます！\n\n注目の新機能：\n\n* ✅ カスタムワークフローステータス：イシューの状態を自社の運用に合わせて柔軟に管理可能に\n* 🧭 Merge Requestページの再設計：ロールやワークフロー別に表示を最適化\n* 🔐不変コンテナタグ： 本番環境への不意な変更を防止\n\n🔗 [全リリース内容はこちら](https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/)\n\n[](https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/)\n\n# **今月のイベント情報：Black Hat USA & OSS EU**\n\n![Black Hat USA & OSS EU](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/buoqb3vmhmnsnznqquwj.png)\n\n今月はGitLabチームがイベントに登場します！\n\n📍 Black Hat USA（ラスベガス） – [詳細はこちら](https://www.blackhat.com/us-25/)[\n](https://www.blackhat.com/us-25/)\\\n📍 Open Source Summit Europe（アムステルダム） – 今月後半 👉 [登録はこちら](https://events.linuxfoundation.org/open-source-summit-europe/register/)\n\n開催地にいらっしゃる方は、ぜひお立ち寄りください！ステッカーもご用意しています。\n\n# **お客様事例：NatWest社**\n\n![NatWest](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/dr8uwztk6f1akrj7cdsp.png)\n\n金融機関NatWest社は、GitLab Duo Agent Platformを活用して開発スピードと生産性を大幅に向上させています。\n\n「GitLab Duo Agent Platformは、私たちのコードベースと組織構造を理解したうえで、AIが開発ワークフロー全体を支援してくれます。コード・テスト・CI/CDとあらゆる工程にAIが溶け込み、チームの一員として一緒に仕事している感覚があります。開発者はより創造的な仕事に集中できるようになりました」\n— NatWest社エンジニアリングプラットフォームリード Bal Kang\n\n# **今月のおすすめ記事＆動画👀**\n\n![What We're Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369415/mmjg9yy77orkohaureis.png)\n\nGitLabリーダーたちが語る、AI・DevSecOps・ソフトウェアセキュリティの未来。\n\n\u003Chttps://leaddev.com/reporting/the-rise-and-looming-fall-of-acceptance-rate>\n\n\u003Chttps://www.thestack.technology/a-cisos-focus-lessons-from-the-field/>\n\n\u003Chttps://www.raconteur.net/technology/agentic-ai-vibe-coding-oped>\n\n\u003Chttps://thenewstack.io/software-security-imperative-forging-a-unified-standard-of-care/>\n\n\u003Chttps://youtu.be/wZytaN-1URM>\n\n**最後に、今月の名言を**\n\n> 「知性の本当の証は知識ではなく、想像力である」\n> — アルベルト・アインシュタイン\n\n素晴らしいアイデアは、予想外の場所から生まれるものです。知識だけでなく、「想像する力」を大切にしたいですね。\n\n今月号は以上です。Duo Agent Platformはついに一般公開され、AIはC-suiteの重要議題へ、そしてMerge Requestページもさらに進化した、盛りだくさんな月でしたね。\n\nそれではまた来月、お会いしましょう！Happy Merging！\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/)｜GitLab Developer Advocate\n\n🧡 このニュースレターが気に入った方は、ぜひチームにもシェアしてください。\n 👉 [The Developer Show](https://www.linkedin.com/feed/update/urn:li:activity:7340777670714019840)の購読もお忘れなく！\n\n![Happy Merging!](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754369416/is5jitqrtujnkmmkijlg.png)",[727],"AIエージェント、新機能、そして7,500億ドルの可能性に注目\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754368844/vagh8krfgft9cghbknod.png",{"featured":91,"template":686,"slug":1280},"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":1286,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1287,"content":1291,"config":1295,"_id":1297,"_type":14,"title":1298,"_source":16,"_file":1299,"_stem":1300,"_extension":19},"/ja-jp/blog/monday-merge-2025-july-14",{"noIndex":6,"ogImage":1288,"title":1289,"description":1290},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204420/ccdkkhlyrjmyjxsicf7d.jpg","Monday Merge 7月号","Monday Merge７月号では、GitLab 18の最新トピックのほか、AWS Summit、新しいライブ番組のスタート、そして注目のカスタマーストーリーをご紹介します。",{"date":700,"body":1292,"title":1289,"category":683,"heroImage":1288,"authors":1293,"description":1290,"tags":1294},"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)",[727],[109,681,880,707,269,733,9,279,708,683,1274,682,734],{"featured":6,"template":686,"slug":1296},"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":1302,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1303,"content":1309,"config":1314,"_id":1316,"_type":14,"title":1317,"_source":16,"_file":1318,"_stem":1319,"_extension":19},"/ja-jp/blog/monday-merge-2025-june-9",{"title":1304,"description":1305,"ogTitle":1304,"ogDescription":1305,"noIndex":6,"ogImage":1306,"ogUrl":1307,"ogSiteName":670,"ogType":671,"canonicalUrls":1307,"schema":1308},"🌞 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","\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":1304,"description":1305,"authors":1310,"heroImage":1306,"date":1311,"body":1312,"category":683,"tags":1313},[727],"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/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)",[1274,9,681,1033,682,683,279,233,880,734,707,269],{"slug":1315,"featured":6,"template":686},"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":1321,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1322,"content":1328,"config":1333,"_id":1335,"_type":14,"title":1336,"_source":16,"_file":1337,"_stem":1338,"_extension":19},"/ja-jp/blog/monday-merge-2025-may-9",{"title":1323,"description":1324,"ogTitle":1323,"ogDescription":1324,"noIndex":6,"ogImage":1325,"ogUrl":1326,"ogSiteName":670,"ogType":671,"canonicalUrls":1326,"schema":1327},"🌞 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":1323,"description":1324,"authors":1329,"heroImage":1325,"date":1330,"body":1331,"category":683,"tags":1332},[727],"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",[1274,9,681,1033,682,683,279,233,880,734,707,269],{"slug":1334,"featured":91,"template":686},"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":1340,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1341,"content":1346,"config":1352,"_id":1354,"_type":14,"title":1355,"_source":16,"_file":1356,"_stem":1357,"_extension":19},"/ja-jp/blog/monday-merge-2025-october-13",{"config":1342,"title":1343,"ogTitle":7,"description":1344,"ogImage":1345},{"noIndex":6},"Monday Merge 10月号","10月号のMonday MergeではGitLab 18.4、金融業界のリーダーたちによる最新の経営層インサイト、ドイツ鉄道社の事例をお届け。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1759899124/uip5uk6hq3mwq9rqx4g5.png",{"title":1347,"description":1344,"heroImage":1345,"date":1348,"body":1349,"category":683,"tags":1350,"authors":1351},"Monday Merge 10月号：AIネイティブ開発、7,500億ドル超の金融サービスインサイト、そしてドイツ鉄道社の変革","2025-10-13","今月は、最新リリースのGitLab 18.4をご紹介。このバージョンでは、AIネイティブなDevSecOpsをさらに進化させました。\n\n金融業界のリーダーたちによる最新の経営層インサイト、ドイツ鉄道社（Deutsche Bahn）の変革ストーリー、そして世界各地で開催されるイベント情報もお届けします。\n\nさらに、今月のおすすめ記事や、少し前向きになれるインスピレーションもお届けします。\n\nそれでは、さっそく見ていきましょう👇\n\n## GitLab 18.4：AIネイティブ開発をさらに拡張\n\n![GitLab 18.4：AIネイティブ開発をさらに拡張](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759974747/r6izlyuh62ahsz7k6etp.png)\n\n失敗したデプロイを何時間も追跡したことがあるなら、現代の開発はコードを書くことと同じくらい「複雑さの管理」が重要だと感じたことがあるはずです。GitLab 18.4では、DevSecOpsのライフサイクル全体にAIを組み込むことで、その課題をより簡単に解決できるようになりました。\n\n#### **新機能：**\n\n* **GitLab Duo AI Catalog（AIカタログ）** – 組織内でカスタムエージェントを定義、作成、共有可能。可視性の設定で、安全に実験し、非公開にするものと広く再利用できるものを選べます。これにより、エージェント管理を一元化し、Duo Agent Platformの基盤として統合・協調された知能のハブを構築できます。\n* **スマートなエージェント型チャット** – AIエージェントとリアルタイムで協働できます。新しいセッションビューでエージェントのアクティビティ、ログ、コンテキストを確認できるため、AIがどのように作業を前進させているかを常に把握できます。\n* **強化されたGitLab Knowledge Graph（ナレッジグラフ）** – コードベースをより深いコンテキストで検索可能。ルートファイルから依存関係の影響まで、オンボーディングが容易になり、デバッグが迅速化し、調査が正確になります — 人間にもAIエージェントにも有効です。\n* **ビジネスに配慮したパイプライン自動化** – パイプラインは現代のソフトウェアデリバリーの心臓部です。今では、エラーを修正するだけでなく、ビジネスへの影響や優先度を理解した上で修正を提案・実行できる自動化が可能です。\n* **ガバナンスとセキュリティ** – GitLab Duoのコンテキスト除外機能、拡張されたModel Context Protocol（MCP）ツール、GitLab管理キー、一般提供が開始したGitLab Duoモデル選択により、企業はAIの展開方法やアクセス可能なデータを制御可能です。イノベーションの速度を落とすことなく、安全に導入できます。\n\nこれらの機能により、GitLab 18.4は単なるアップグレードではなく、AIとの協働をより速く、コンテキストを理解し、コントロールできる形で実現する革新的な一歩となります。\n\n 🔗 [18.4リリースノート全文はこちら](https://about.gitlab.com/ja-jp/blog/gitlab-18-04-release/)\n\n## **金融業界の経営層インサイト：7,500億ドルを超えるチャンス**\n\n![金融業界の経営層インサイト：7,500億ドルを超えるチャンス](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759974745/oqpf7tebgql0akmee26r.png)\n\n最新のGitLab金融業界経営調査では、AIが業界にどれほどの影響を与えているかが明らかになりました。\n\n銀行、保険、資本市場の経営者は、AI搭載のソフトウェア革新に大きなチャンスを感じています：\n\n* AIによるソフトウェア革新で得られる世界規模の潜在価値：7,500億ドル以上\n* 金融サービス業界の95%の経営者が、ソフトウェア革新を現在のコアビジネスにおける優先事項と認識\n* 過去1年間で、AI投資によるビジネス成長を経験したと答えた経営者は93%\n* 93%の経営者が、エージェント型AIが3年以内にソフトウェア開発の業界標準になると予測\n\n金融リーダーからのメッセージは明確です。AIの潜在力を最大限に引き出すには、技術だけでなく、信頼性、ガバナンス、スキル向上が不可欠です。\n\n 🔗[ レポート全文はこちら](https://about.gitlab.com/software-innovation-report/finserv/)\n\n## **今後のイベント：10月の予定**\n\n![今後のイベント：10月の予定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759974745/skvnsr1pkqfa9xtwhgy2.png)\n\n10月はGitLabチームにとって盛りだくさんの月です。参加予定のイベントはこちら：\n\n* **[Cloud & AI Infrastructure Expo, シンガポール (10/8–9)](https://www.singaporetechnologyweek.com/cloud-ai-infrastructure)** – Tech Week Singaporeの一環として、6つの主要テックイベントが一堂に会しました。GitLabブースでは、最新のDevSecOpsとAIに関する情報で盛り上がりました。\n* **[GitLab DACH Roadshow, ミュンヘン (10/14)](https://page.gitlab.com/event-october14-roadshowmunich-emea.html)** – エンジニアリングリーダーやDevSecOps専門家と共に、実際の顧客事例、ハンズオンワークショップ、ネットワーキングを体験。参加無料（ランチ付き）。\n* **[Gartner IT Symposium/Xpo, オーランド (10/20–23)](https://www.gartner.com/en/conferences/na/symposium-us/1?mrasn=1500051.1868414.7OzTUFLs)** – 年間最大規模のテックイベントの1つ。GitLabがどのようにAIネイティブDevSecOpsの変革を推進しているかを紹介。\n* **[GitLab DACH Roadshow, デュッセルドルフ (10/28)](https://page.gitlab.com/event-october28-roadshowduesseldorf-emea.html)** – コミュニティとの交流、インサイトの共有、そして技術的な課題へのサポートを行います。\n\n参加予定の方は、ぜひブースにお立ち寄りください！\n\n 🔗 [世界各地のイベント情報はこちら](https://about.gitlab.com/events/)\n\n## **GitLabハッカソン：貢献・協働・創造**\n\n![GitLabハッカソン：貢献・協働・創造](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759974745/v9o15pakposcooov6v3e.png)\n\n10月1日〜8日にかけてGitLabハッカソンが開催されました。\n\nハッカソンは1週間のオンラインイベントで、誰でもGitLabプロジェクトにコントリビュートできます。楽しみながらインパクトを生み出すことが目的です。\n\n参加のメリット：\n\n* 🏆 賞品獲得、プロファイル実績のアンロック、GitLabスキル向上\n* 💻 コーディング、ドキュメント作成、翻訳、UXデザインなどの実践経験\n* 🌍 DevSecOpsに熱意を持つ世界中のオープンソースコミュニティと協働\n\n初めてのマージリクエストでも100回目でも、誰でも参加可能です。今後も開催予定ですので、学び、作り、つながるチャンスをお見逃しなく。\n\n 🔗[ ハッカソン登録はこちら](https://contributors.gitlab.com/hackathon)\n\n## **事例のご紹介：ドイツ鉄道社（Deutsche Bahn）**\n\n![事例のご紹介：ドイツ鉄道社（Deutsche Bahn）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759974745/hfqxnwzw0adg4xvrceu5.png)\n\n今月は、ドイツの国営鉄道でありヨーロッパ最大級の鉄道事業者であるドイツ鉄道社、　Deutsche Bahnをフィーチャー。約34万人の従業員と年間20億人の乗客を抱える同社は、デジタル成長のためにDevSecOpsを統合する単一プラットフォームを必要としていました。\n\nGitLab Premiumを導入したことで、ソフトウェア開発と運用が大きく変革：\n\n* 📈 継続的デプロイの成功率91%\n* 📈 35のDevSecOpsチーム間のコラボレーション向上\n* 📈 コンプライアンスの簡略化とシステム信頼性向上\n\nさらに、インフラコストを10〜20%削減し、2,300万人のユニークユーザー向けの世界クラスの予約システムを構築しました。\n\nMartin Ortmann氏（プロダクトオーナー）のコメント：\n\n「共同作業ができるプラットフォームのおかげで、学びや議論が活発になり、大きな成果につながっています。GitLabは私たちの協働と成功に欠かせない存在です。」\n\nまさに、1つのDevSecOpsプラットフォームに統合した成果が、その背景にあります。\n\n 🔗 [Deutsche Bahnのケーススタディ全文はこちら](https://about.gitlab.com/ja-jp/customers/deutsche-bahn-ag/)\n\n## **今月のおすすめ記事 📚**\n\n![今月のおすすめ記事 📚](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759974745/qgxncujbsuz73cs1601f.png)\n\n今月のおすすめは、次の戦略セッションに役立つインサイト満載の記事です。\n\n\u003Chttps://thenewstack.io/sustainable-scale-how-to-grow-engineering-teams-strategically/>\n\n\u003Chttps://social-www.forbes.com/councils/forbestechcouncil/2025/09/09/softwares-agentic-future-is-less-than-3-years-away-cisos-must-prepare-now/>?\n\n\u003Chttps://www.washingtontechnology.com/opinion/2025/09/bridging-gap-legacy-systems-secure-ai-innovation/407991/>\n\n\u003Chttps://vmblog.com/archive/2025/09/09/authorization-systems-aren-t-built-for-ai-agents-here-s-how-to-adapt.aspx>　\n\n## **最後に、今月の名言を**\n\nヘンリー・フォード（フォード・モーターの創設者）はこう言いました：\n\n「皆が一緒に前進すれば、成功は自然についてくる」\n\nGitLabもまさにこれを目指しています！\n チームが一緒に、より速く、安全に、成功を手にできるよう支援することが私たちの使命です。\n\n今月もお読みいただきありがとうございます。それでは次回まで、Happy Merging!\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | Developer Advocate, GitLab\n\nこのニュースレターが役立ったら、ぜひチームにもシェアしてください。\nそして忘れずに👉 [YouTubeチャンネル](https://www.youtube.com/@Gitlab)もご登録を！\n\n![Fatima Sarah Khalid](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759974745/jmxrdaikant0ze1bis3j.png)",[681,707,269,733,9,279,708,551,734],[727],{"featured":6,"template":686,"slug":1353},"monday-merge-2025-october-13","content:ja-jp:blog:monday-merge-2025-october-13.yml","Monday Merge 2025 October 13","ja-jp/blog/monday-merge-2025-october-13.yml","ja-jp/blog/monday-merge-2025-october-13",{"_path":1359,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1360,"content":1365,"config":1372,"_id":1374,"_type":14,"title":1375,"_source":16,"_file":1376,"_stem":1377,"_extension":19},"/ja-jp/blog/monday-merge-2025-september-8",{"config":1361,"title":1362,"ogImage":1363,"description":1364},{"noIndex":6},"Monday Merge 9月号","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756904278/ov1n66vq8dnikcjyu0iw.png","最新リリース、注目のホワイトペーパー、そして大規模なDevSecOpsの取り組み事例をお届け。",{"title":1366,"authors":1367,"heroImage":1363,"date":1368,"category":683,"tags":1369,"body":1370,"description":1371},"Monday Merge 9月号：より速いパイプライン、もっと賢いエージェント、そしてより大きな成果を！",[727],"2025-09-08",[681,109,707,269,733,9,279,708,683,1274,682,734],"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":686,"slug":1373},"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":1379,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1380,"content":1386,"config":1392,"_id":1394,"_type":14,"title":1395,"_source":16,"_file":1396,"_stem":1397,"_extension":19},"/ja-jp/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo",{"title":1381,"description":1382,"ogTitle":1381,"ogDescription":1382,"noIndex":6,"ogImage":1383,"ogUrl":1384,"ogSiteName":670,"ogType":671,"canonicalUrls":1384,"schema":1385},"AI搭載のGitLab Duoでコードをモダンな言語にリファクタリング","この詳細なチュートリアルでは、デベロッパーがAIを活用し、コードを新しいプログラミング言語に移行してモダナイゼーションを進めるプロセスや、同じ言語における新機能についても学べる内容を紹介しています。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662465/Blog/Hero%20Images/GitLab_Duo_Workflow_Unified_Data_Store__1_.png","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":1381,"description":1382,"authors":1387,"heroImage":1383,"date":1388,"body":1389,"category":698,"tags":1390,"updatedDate":1391},[794],"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",[681,709,9],"2025-02-10",{"slug":1393,"featured":6,"template":686},"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":1399,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1400,"content":1406,"config":1413,"_id":1415,"_type":14,"title":1416,"_source":16,"_file":1417,"_stem":1418,"_extension":19},"/ja-jp/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"title":1401,"description":1402,"ogTitle":1401,"ogDescription":1402,"noIndex":6,"ogImage":1403,"ogUrl":1404,"ogSiteName":670,"ogType":671,"canonicalUrls":1404,"schema":1405},"Jira2Labを使用してJiraからGitLabへの大規模な移行をシームレスに実現","複雑なデータ移行の処理、スケーラビリティの向上、効率的な統合を保証するJira2GitLabを使用することで、Jiraから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/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":1401,"description":1402,"authors":1407,"heroImage":1403,"date":1175,"body":1409,"category":1410,"tags":1411},[1408],"Maximilien Belinga","[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","agile-planning",[1412,109,9,708,1033],"agile",{"slug":1414,"featured":91,"template":686},"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":1420,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1421,"content":1427,"config":1434,"_id":1436,"_type":14,"title":1437,"_source":16,"_file":1438,"_stem":1439,"_extension":19},"/ja-jp/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":1422,"description":1423,"ogTitle":1422,"ogDescription":1423,"noIndex":6,"ogImage":1424,"ogUrl":1425,"ogSiteName":670,"ogType":671,"canonicalUrls":1425,"schema":1426},"エンタープライズ規模の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":1422,"description":1423,"authors":1428,"heroImage":1424,"date":1430,"body":1431,"category":1033,"tags":1432},[1429],"Tim Rizzi","2025-02-19","組織の規模が拡大するにつれ、社内パッケージの管理はますます複雑になります。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",[9,709,1433],"solutions architecture",{"slug":1435,"featured":91,"template":686},"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":1441,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1442,"content":1448,"config":1457,"_id":1459,"_type":14,"title":1460,"_source":16,"_file":1461,"_stem":1462,"_extension":19},"/ja-jp/blog/the-ultimate-guide-to-sboms",{"title":1443,"description":1444,"ogTitle":1443,"ogDescription":1444,"noIndex":6,"ogImage":1445,"ogUrl":1446,"ogSiteName":670,"ogType":671,"canonicalUrls":1446,"schema":1447},"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":1443,"description":1444,"authors":1449,"heroImage":1445,"date":1451,"body":1452,"category":682,"tags":1453,"updatedDate":1456},[1450],"Sandra Gittlen","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合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*",[682,9,1454,1455,186],"performance","open source","2025-06-10",{"slug":1458,"featured":6,"template":686},"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":1464,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1465,"content":1473,"config":1482,"_id":1484,"_type":14,"title":1485,"_source":16,"_file":1486,"_stem":1487,"_extension":19},"/ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":1466,"description":1467,"ogTitle":1468,"ogDescription":1467,"noIndex":6,"ogImage":1469,"ogUrl":1470,"ogSiteName":670,"ogType":1471,"canonicalUrls":1470,"schema":1472},"チュートリアル：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":1468,"description":1467,"authors":1474,"heroImage":1469,"date":1476,"body":1477,"category":1033,"tags":1478,"updatedDate":1481},[1475],"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",[1479,756,109,1115,9,1480],"チュートリアル","git","2025-06-05",{"slug":1483,"featured":6,"template":686},"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":1489,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1490,"content":1496,"config":1502,"_id":1504,"_type":14,"title":1505,"_source":16,"_file":1506,"_stem":1507,"_extension":19},"/ja-jp/blog/u-s-navy-black-pearl-lessons-in-championing-devsecops",{"title":1491,"description":1492,"ogTitle":1491,"ogDescription":1492,"noIndex":6,"ogImage":1493,"ogUrl":1494,"ogSiteName":670,"ogType":671,"canonicalUrls":1494,"schema":1495},"米国海軍 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":1491,"description":1492,"authors":1497,"heroImage":1493,"date":1498,"body":1499,"category":730,"tags":1500,"updatedDate":1501},[1450],"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/)をもっと知りたいですか。こちらをお読みください。",[9,732,682,269,186],"2024-12-04",{"slug":1503,"featured":91,"template":686},"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":1509,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1510,"content":1516,"config":1522,"_id":1524,"_type":14,"title":1525,"_source":16,"_file":1526,"_stem":1527,"_extension":19},"/ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":1511,"description":1512,"ogTitle":1511,"ogDescription":1512,"noIndex":6,"ogImage":1513,"ogUrl":1514,"ogSiteName":670,"ogType":671,"canonicalUrls":1514,"schema":1515},"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":1511,"description":1512,"authors":1517,"heroImage":1513,"date":1518,"body":1519,"category":10,"tags":1520,"updatedDate":1521},[1450],"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合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[109,9,732,709,682,1033],"2025-05-26",{"slug":1523,"featured":91,"template":686},"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":1529,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1530,"content":1536,"config":1543,"_id":1545,"_type":14,"title":1546,"_source":16,"_file":1547,"_stem":1548,"_extension":19},"/ja-jp/blog/what-is-ai-platform",{"config":1531,"ogImage":1532,"title":1533,"ogTitle":1534,"description":1535},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1759710675/bp7phtsziq0begfmoifj.jpg","AIプラットフォームとは | GitLab","AIプラットフォームとは","AI開発環境である AIプラットフォームとは？AIプラットフォームの種類や機能、そのメリット・デメリットを徹底解説します。",{"title":1534,"description":1537,"authors":1538,"heroImage":1532,"date":1539,"body":1540,"category":1541,"tags":1542},"AIプラットフォームの種類や機能、そのメリット・デメリットを徹底解説します。",[834],"2025-10-06","### 目次\n\n* AIプラットフォームとは \n* AIプラットフォームの種類\n* AIプラットフォームの主な機能 \n* AI開発環境とは\n* GitLabではどのようにAIを活用してDevSecOpsプラットフォームを強化しているのか\n* GitLabなどのAIプラットフォームを使用するメリット\n* AIプラットフォームの課題やデメリット\n* GitLabはどのようにAIプラットフォームのデメリットを克服しているのか\n* FAQ（よくある質問）\n\n## AIプラットフォームとは\n\nAIプラットフォームとは、人工知能（AI）の開発・運用を行なう際の基盤を提供するシステムのことで、開発や実行に必要な機能やデータがひとつになっています。具体的には、機械学習（ML）や深層学習（ディープラーニング）モデルを構築、開発、評価、実装、実行するための統合テクノロジーです。AIプラットフォームを正しく使えば、手作業でするより、より高速に、より高い精度で開発を進めることができます。\n\nAIプラットフォームはAIの機能を構築し、モデルを訓練・評価し、実用化するまでをトータルでサポートする環境とも言えます。AIを使った開発を行なう際は、まずAIが動作する環境を整え、AIに学習データを読み込んでモデルを構築します。一般的なAI開発アプリケーションの場合、AIプラットフォームを活用することで、AI開発プロセスにおけるモデル開発の工程を簡略化できます。AIプラットフォームに既にAIの動作環境が整っているため、AIを構築する手間が省略できるからです。開発工程の難度が下がれば、AI開発のコストを抑えられます。\n\n## AIプラットフォームの種類\n\nAIプラットフォームには、PaaS系の総合型AIプラットフォームと、特化型AIプラットフォームの2種類があります。\n\n**PaaS（Platform as a Service）系の統合型AIプラットフォーム**は、AI開発に必要な環境がすべてクラウドに揃っているサービスです。アプリケーションを稼働するためのネットワーク、ハードウェア、OS、ミドルウェアなどのプラットフォームに加え、膨大な量のデータを学習したAIモデルが用意されています。\n\n**特化型AIプラットフォーム**は、特定の業界や機能に特化したAIプラットフォームです。汎用性は高くありませんが、得意な領域では特定のタスクを効果的に処理できます。つまり、開発できるAIの種類は少なくなりますが、より高精度なAIを効率よく開発できます。\n\n## AIプラットフォームの主な機能\n\nAIプラットフォームには、AI開発をサポートする機能が備わっています。主なAIプラットフォームには以下の機能が含まれます。\n\n* **データ収集**\n\nAIを優れたものとするには、良質な学習データの収集が欠かせません。AIプラットフォームのデータ収集機能を活用すれば、データを無駄なく効率的に収集できます。\n\n* **データ処理**\n\n収集したデータは、AIに適した形式に変換・加工しなければなりません。AIプラットフォームの機能を使えば、データの分割や正規化などの処理作業も効率よく進められます。\n\n* **モデル構築**\n\nAIモデルとは、AIでデータを処理するときのパターンのことで、データ解析を行なう方法のひとつです。AIモデルの種類には、「回帰モデル」や「分類モデル」などさまざまな種類があります。AIモデルではまず仮のモデルを構築し、想定しているものが実現可能かどうかを実際のデータを使って検証します。アルゴリズムの選択もこの段階で実施されます。\n\n* **再学習**\n\nAIプラットフォームでは、継続的な運用に向けた再学習やデータの見直しを行ないます。最新の学習データやフィードバックを取り込むことで、AIの精度が高まります。再学習には、モデルの再学習、デプロイ、パラメータの調整、監視などが含まれます。\n\n## AI開発環境とは\n\n近年、AI（人工知能）の発展は目覚ましく、AIをビジネスで活用したいと考えている企業も増加しています。ただし、AI開発には専門知識が必要で、適切な開発環境も整える必要があります。\n\nAI開発環境とは、AIモデルの設計・開発・テストを行なうためのインフラとツールが整った作業環境を指します。AI開発を進めるには、プログラミングスキルやデータ分析スキルといった専門知識に加え、ハードウェア・ソフトウェアの環境整備が必要です。機械学習（ML）アルゴリズムや深層学習（ディープラーニング）モデル、環境を構築するためのフレームワークやライブラリも不可欠です。\n\n## GitLabではどのようにAIを活用してDevSecOpsプラットフォームを強化しているのか\n\nGitLabでは、AI機能を活用して[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)（開発・セキュリティ・運用の統合）を強化しています。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、現在利用できるAI搭載プラットフォームの中で最も包括的なDevSecOpsプラットフォームです。GitLabは、ソフトウェアの開発、セキュリティ、デプロイなど、DevSecOpsライフサイクル全般にわたってチームをサポートします。 [強力なAIを搭載した包括的なDevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/blog/gitlab-flow-duo/)が、コードレビューやテスト自動化の支援、セキュリティ脆弱性の予測や対策の提案、プロジェクト管理の効率化などをサポートするため、イシュー管理、バージョン管理、コードレビュー、継続的インテグレーション / 継続的デリバリ ([CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/))、モニタリングが、ひとつのアプリケーションで完結します。開発から運用までのプロセスを迅速かつ安全に進められます。\n\n## GitLabなどのAIプラットフォームを使用するメリット\n\nAIプラットフォームを使用するメリットとして、以下が挙げられます。\n\n* **コストの縮減**\n\nAIプラットフォームを導入すれば、すべてを自社開発した場合と比べて開発期間が短縮でき、コストを抑えることができます。AIの開発には、サーバーやOSといったさまざまなリソースが必要ですが、AIプラットフォームにはAI開発の基盤となるシステムが備わっているため、ノーコードで開発でき、コーダーなどの人件費も節約できます。それにより、求められる機能を備えたAIを、低コストで効率よく開発できます。\n\n* **システム開発の高速化**\n\n既存の機能や環境、AIモデルを利用することで、システム構築のスピードが上がります。ゼロからシステムを構築する場合、AIが動作できる環境を整え、それからAIに学習データを読み込ませてモデルを構築する工程が必要になりますが、AIプラットフォームを使えば、この工程を省略できます。\n\n* **AI専門エンジニアが不要な場合も**\n\nAIプラットフォームなら、前述のようにノーコードでAIを導入できる環境が整っているため、プログラミングの知識がなくてもAI開発ができる場合があります。プログラミング言語を習得する必要性が減ってきているのです。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、コードの理解からセキュリティ脆弱性の修正まで、最適なAIモデルが単一のプラットフォームに統合されています。エンジニアでなくてもAI開発に取り組めるようになります。\n\n* **小規模なAI開発から始められる**\n  AIプラットフォームはさまざまな規模のAI開発に対応しているため、規模の小さいAIから開発を始め、規模を大きくしていくことができます。これにより、AI開発は大企業だけではなく、中小企業やスタートアップでも取り組めるようになりました。\n* **DevSecOps（開発・セキュリティ・運用）におけるエラーの早期発見と対策**\n\nGitLabのAIプラットフォームなら、DevSecOpsチームはAI開発を加速できます。このAIプラットフォームは、チームが問題を早期に発見して修正できるよう設計されているため、問題が複雑化する前に対応でき、後から大きなコストがかかる事態を防ぐことができます。\n\n## AIプラットフォームの課題やデメリット\n\nAIをソフトウェア開発プロセスに統合するメリットは数多くありますが、AIプラットフォームにはデメリットもあります。導入を検討する際は、次のような点を考慮する必要があります。\n\n* **開発や運用に専門知識やスキルが求められる場合がある**\n\n  AIプラットフォームの中にはコーディングの知識が必要なものもあります。こうした知識や技術が必要になる場合、導入コストが高くなることがあります。\n* **機能確認を怠ると導入に失敗する場合もある**\n\n  どんなAIを開発したいのか、どのくらいのデータを扱うのかなどを事前に確認せずにAIプラットフォームを選択してしまうと、導入に失敗する恐れがあります。事前調査を怠らず、しっかりと目的に合ったAIプラットフォームを選択しましょう。\n* **データ品質とデータセキュリティの問題**\n\n  AIプラットフォームを利用する際には、データの品質やセキュリティに関する技術的な課題が生じる場合があります。データの品質ならびにセキュリティ要件を担保するためには、データの検証やクレンジング、アクセス制御の厳格化、プライバシー保護の強化などが求められます。\n\n  [GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)なら、AIを活用した機能を利用できるユーザー、プロジェクト、グループを自由に設定できます。また、プロプライエタリコードやデータがAIモデルのトレーニングに使用されることはないため、情報の機密性を保つことができます。\n\n## AIプラットフォームのデメリット克服のためのGitLabの取り組み\n\nGitLabでは、AIプラットフォームのデメリットを克服するために、データの品質やセキュリティ、ユーザーのプライバシー保護を強化しています。\n\nソフトウェア開発におけるAIの有効性は、コード生成といった生産性メトリクスだけでなく、コード品質、保守、テスト、セキュリティに対してAIがもたらす影響も考慮して測定すべきです。また、コーディングプロセスにAIを統合することで、ソフトウェアデベロッパーが戦略的タスクにかけられる時間が増え、認知負荷が軽減され、より優れた価値を提供できるようにもなります。\n\n* **データ品質管理**\n\n  GitLabでは、データの品質管理に自動データ検証を取り入れ、トレーニングデータや運用データに不正確な情報やバイアスが含まれるリスクを減らし、AIモデルの精度向上を図っています。また、継続的インテグレーション/継続的デリバリー（[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)）の導入により、データの一貫性と品質を維持しています。\n* **セキュリティ対策**\n\n  GitLabでは、AIモデルとデータのセキュリティ監視を実施し、AIモデルやデータストレージへの脅威をリアルタイムで検出し、リスクに迅速に対応しています。また、データアクセスについては、ユーザーやチームごとにアクセス制御を行ない、内部からのデータ漏えいリスクを軽減しています。\n* **自動化とコラボレーション支援**\n\n  GitLabのAIツールは、反復的な作業を自動化し、デベロッパーの生産性向上を図ることにより、コラボレーションを促進します。この効率化により、エラーや不整合の発生を抑え、チーム全体でのスムーズな開発体制が可能になります。\n\nGitLabは、上記のような取り組みにより、AIプラットフォームのデメリットを最低限に抑え、デベロッパーにとって安全で信頼性の高い環境を提供しています。\n\n## まとめ\n\nAIは現在、ソフトウェア開発において広く使用されています。この記事では、AIプラットフォームのメリットやデメリットなども採り上げ、問題を認識しつつ、イノベーションが促進される環境作りを担うAIプラットフォームについて解説してきました。専門知識や開発経験があまりなくても、AIプラットフォームを使えば、AIの開発・運用がスムーズに行なえます。\n\n## FAQ（よくある質問）\n\n1. **AI開発環境であるAIプラットフォームについて分かりやすく説明してください。**\n   AIプラットフォームとは、人工知能（AI）の開発・運用を行なう際の基盤を提供するシステムのことで、開発や実行に必要な機能やデータがひとつになったものです。具体的には、機械学習（ML）や深層学習（ディープラーニング）モデルを構築、開発、評価、実装、実行するための統合テクノロジーです。\n2. **AIプラットフォームには何種類ありますか。**\n\n   AIプラットフォームには、大きく分けて2つの種類があります。「PaaS系の総合型AIプラットフォーム」と「特化型AIプラットフォーム」です。詳しくは、本記事の「AIプラットフォームの種類」をご覧ください。\n3. **AIプラットフォームはどう機能しますか。**\n\n   AIプラットフォームには、AI開発を支援するための機能がいくつか備わっています。データ収集、データ処理、モデル構築、再学習の4つが主要機能といえます。詳しくは本記事の「AIプラットフォームの主な機能」をご覧ください。","engineering",[681,9,708],{"featured":6,"template":686,"slug":1544},"what-is-ai-platform","content:ja-jp:blog:what-is-ai-platform.yml","What Is Ai Platform","ja-jp/blog/what-is-ai-platform.yml","ja-jp/blog/what-is-ai-platform",{"_path":1550,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1551,"content":1554,"config":1563,"_id":1565,"_type":14,"title":1566,"_source":16,"_file":1567,"_stem":1568,"_extension":19},"/ja-jp/blog/what-is-docker",{"noIndex":6,"description":1552,"title":1553},"Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。","Dockerとは：GitLabとの統合とコンテナについての入門編 | GitLab",{"title":1555,"description":1556,"authors":1557,"date":1558,"body":1559,"category":1541,"heroImage":1560,"tags":1561},"Dockerとは：超入門編","Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。\n",[834],"2025-06-18","Dockerコンテナ技術は、2013年にオープンソースの「Dockerエンジン」として公開され、翌年2014年には本番環境向けの商用版が発表されました。その後約10年の間に、Dockerは使いやすさと高い利便性から、IT業界で瞬く間に広く普及してきました。これからもその人気は高まっていくでしょう。\n\nしかしその一方で、いまだに「Dockerとは何ですか」という声もよく耳にします。この記事では、Docker環境の導入を検討中で、Dockerにまだ不慣れなデベロッパーやプログラマーの皆様を対象に、Dockerの基本を解説します。Dockerに触れたことのない初心者向けの「Docker超入門編」です。\n\n## 目次\n\n1. Dockerとは：超入門編\n2. Dockerの目的\n\n   * Dockerとは\n   * Dockerでできること\n   * Dockerイメージとは\n   * Dockerコンテナとは\n   * Dockerfileとは\n   * Dockerはなぜ重要なのか\n3. Dockerの主な機能\n\n   * Dockerの特徴\n   * Docker Composeとは\n4. アプリケーションのデプロイにおけるDockerのメリット\n\n   * 開発環境と本番環境のシームレス化\n   * 起動の軽量化・処理速度の高速化\n   * バージョン管理のしやすさ\n   * 優れたスケーラビリティ\n5. Dockerのデメリット\n\n   * ひとつのOSを使わなければならない\n   * 大規模開発時のオーバーヘッド\n   * 技能習得に時間がかかる\n   * セキュリティに脆弱性が生じることもある\n   * コンテナ間での連携が難しい\n6. GitLabはDockerが抱える課題をどのように解決するのか\n7. GitLabのDevSecOpsにおけるDockerの役割\n8. まとめ\n9. FAQ（よくある質問）\n\n## Dockerの目的\n\nはじめに、Dockerとはどういったもので、何ができて、どうして便利なのか、なぜ重要なのか、Dockerの目的に着目しながらその概念をまとめていきます。\n\n### Dockerとは\n\nDockerは、Linuxのコンテナ技術を用いた軽量なソフトウェアコンテナプラットフォームです。アプリケーションの開発、出荷、実行を簡易化するために設計されました。Dockerを使えば、すべての依存関係と一緒にアプリケーションをパッケージ化できるため、依存関係を一つひとつ手動でインストールする必要がなくなり、一貫性のあるコード実行が可能になります。\n\nDockerを使えばアプリケーションの実行環境を標準化でき、環境の違いによる問題を減らすことで開発から本番環境へのデプロイ時間を大幅に短縮できます。\n\nLinuxには以前からコンテナ仮想化という技術がありました。この技術を使うと、プログラムを開発・実行環境から隔離することにより、複数のプログラムを素早く実行できます。ただし、この従来型の仮想化技術は、仮想環境を構築するためにホストとなるOS（オペレーティングシステム）に依存する必要がありました。Dockerはこのコンテナ仮想化技術をOSに関係なく簡単に扱えるようにしたソフトウェアといえます。\n\nDockerの基本概念はイメージとコンテナです。Dockerイメージは、読み取り専用のテンプレートであり、コンテナを作成するための指示が記述されています。たとえば、コンテナで実行するアプリケーションとその依存関係、環境変数、ファイルシステムなどがこれに含まれます。\n\n### Dockerでできること\n\nDockerを使うと、1台のマシン中に複数のコンテナ（仮想環境）をビルドできるため、いくつかの開発環境に対応することができます。つまり、1台のサーバー上で複数のアプリケーションを効率的に動かすことができるのです。アプリケーションの開発環境をDockerで構築すれば、たとえば開発環境（Windows）で動いていたアプリケーションがLinux上で起動しない、といった問題は発生しません。Dockerで構築した環境は、他のデベロッパーとクラウド上で簡単に共有できるため、開発作業がスムーズに進められます。\n\n### Dockerイメージとは\n\nDockerイメージは、アプリケーションを実行するのに必要なソースコードと必要な依存関係をパッケージ化したものです。Dockerコンテナを実行する際には、このDockerイメージが必要です。\n\nDockerイメージは、コンテナイメージを構成する複数のファイルに、`Dockerfile` を合わせてビルドします。つまり、Dockerイメージは、手作業で書くのではなく、コマンドを使って作成します。\n\nそのため、Dockerイメージは単一のファイルではなく、Dockerコンテナの実行に必要なパッケージ（ファイルやメタデータの集合体）であることを理解することが重要です。\n\n### Dockerコンテナとは\n\nLinuxのコンテナは、アプリケーションを内包し、必要なライブラリや依存関係、ファイルが含まれています。\n\n一方、Dockerコンテナは、Dockerイメージの実行可能なインスタンスです。これはDockerイメージから生成され、アプリケーションを実行するためのランタイム環境です。ただし、ハイパーバイザーを使用する従来の仮想化とは違い、DockerのコンテナはホストOS（オペレーティングシステム）のカーネルで実行されます。Dockerイメージ内には、個別のOSはありません。\n\nDockerイメージは環境のスナップショットであり、コンテナはソフトウェアを実行する環境といえます。\n\n### Dockerfileとは\n\n`Dockerfile`は文字情報を主体とするファイルで、ファイルの拡張子はありません。`Dockerfile`には、アプリケーションの構築から実行までのプロセスに必要なコマンドが記述されています。どのファイルをどこから取得して、どんな処理を行ない、Dockerイメージに含めるのかなどを記述します。\n\n`Dockerfile`は、Dockerイメージを作成するためのテキストファイルです。コンテナイメージをビルドする場合も、コンテナのビルド手順を`Dockerfile`で定義する必要があります。この`Dockerfile`には、命令のスクリプトが含まれており、Dockerはコンテナイメージをビルドする際にこのスクリプトを使用します。\n\n### Dockerはなぜ重要なのか\n\nDockerは、コンテナに関する既存のコンピューティングの概念、とりわけLinuxの「cgroups」や「namespaces」、「overlayfs」などの技術を活用しています。これは、アプリケーションの依存関係をサーバーやネットワークなどのインフラストラクチャから隔離したいという、デベロッパーやシステムオペレーターのニーズに応えるものでした。\n\nDockerを使うと、1台のサーバー上でさまざまなアプリケーションを簡単に仮想化・実行できるようになります。さらには、ローカルマシンに依存しない開発環境を実現でき（開発環境の統一）、本番環境に近い環境でのシミュレーションが可能になり、アプリケーションの依存関係も管理できます。加えて、ビルド、テスト、デプロイまでの各プロセスを一貫して行なうことができます。\n\n## Dockerの主な機能\n\nDockerは、Linuxのコンテナ技術を使用しています。Dockerコンテナはよく仮想マシンと比較されます。\n\n仮想マシンでは、ホストマシン上でハイパーバイザーを利用してゲストOSを動かし、さらにその上でミドルウェアやライブラリ、さらにその上にアプリなどを実行します。\n\nそれに対し、コンテナはホストマシンのカーネルを利用し、プロセスやユーザーなどを隔離します。そのため、非常に軽量で、まるで別のマシンが動いているかのように動作します。その結果、アプリなどを高速に起動、停止することが可能です。\n\nDockerは、次の4つの構成要素から成り立っています。\n\n* **Dockerイメージ：** アプリケーション実行に必要なソースコード、アプリと依存関係のパッケージ\n* **Dockerコンテナ：** アプリケーションを実行するランタイム環境\n* **Docker Hub：** クラウド上のレジストリサービス。アプリケーションやサービスコンテナのビルドと配信を行なう\n* **Dockerfile：** Dockerイメージを作成するために実行するコマンドライン命令を含むテキストファイル\n\n### Dockerの特徴\n\nDockerには、次のような特徴があります。\n\n* **軽量かつ高速：** 1つのOSで複数のコンテナを管理でき、仮想マシンより軽量で高速に立ち上げることが可能。\n* **環境の一貫性が保持でき再現性がアップ：** Dockerコンテナは異なるプラットフォームでも一貫して動作するため、ローカル、クラウド、ハイブリッド環境への移行が簡単にできる。\n  移植性が高い －クラウドシステムとの親和性が高く、主要なクラウドプロバイダーはDockerコンテナの実行をサポートしている。\n* **サンドボックスの提供：** セキュリティ対策やソフトウェア開発において、隔離された仮想環境でプログラムを実行・検証できる。このため、ホストマシンの環境を守ることができる。\n* **IaC（インフラストラクチャのコード化）を使用して、インフラをコード化：** Dockerfileによりミドルウェアのインストールや環境設定をコード化して管理できる。\n\n### Docker Composeとは\n\nDocker Composeは、複数のDockerコンテナを一元管理する、 Dockerアプリケーションのためのツールです。YAMLファイルを使用してアプリケーションのサービスを設定します。単一のコマンドで複数のサービスをまとめて生成したり、起動・停止したりすることができます。\n\nDocker Composeのコマンド例は次のとおりです。\n\n* **`docker-compose up`：** サービス用のコンテナを構築、作成、起動、アタッチします。リンクされているサービスがまだ起動していない場合は、それらも起動します。\n* **`docker-compose ps`：** Docker Composeで管理されている稼働中のサービスを一覧表示します。\n* **`docker-compose build`：** Docker Composeファイルで定義されているサービスをビルド（構築）します。\n\n## アプリケーションのデプロイにおけるDockerのメリット\n\nアプリケーションのデプロイにおけるDockerのメリットは次のとおりです。\n\n### 開発環境と本番環境のシームレス化\n\nコンテナ技術の利用を開発環境と本番環境で統一することで、環境の違いにより起こる問題を減らすことができます。その結果、デベロッパーと運用チームとの連携がスムーズに行われ、チーム間で発生していた問題も最小限に抑えられます。\n\n### 起動の軽量化・処理速度の高速化\n\nDockerのコンテナ技術は従来の仮想環境より軽く、アプリを瞬時に起動できます。これは、CPUやメモリなどのコンピュートリソースを必要最低限しか使用しないためです。起動速度が上がることで、開発にも集中できます。\n\n### バージョン管理のしやすさ\n\nDockerでは、GitLabなどのソースコードのバージョン管理ツールを使用できるため、バージョン管理の可視化が進むだけでなく、ロールバックやアップデートも簡単に行なえるようになります。\n\n### 優れたスケーラビリティ\n\nコンテナは軽量で拡張性に優れています。必要に応じて簡単に増減できます。これにより、アプリケーションの拡張やスケーリングを迅速に行なえるため、変わりゆく状況にも柔軟に対応できます。\n\n## Dockerのデメリット\n\nDockerにはさまざまなメリットがありますが、いくつかデメリットも存在します。以下にデメリットを挙げます。\n\n### 1つのOSを使わなければならない\n\nDockerは1つのOS上で複数のコンテナを作成します。これにより起動速度や処理速度の面でメリットがありますが、同時にデメリットになることもあります。たとえば、異なるOS環境で検証をしたい場合には、別のマシンや仮想マシンを準備する必要が生じます。\n\n### 大規模開発時のオーバーヘッド\n\nDocker自体は軽量ですが、大規模システムに拡張する場合には、Dockerの管理に伴う負荷が発生します。Dockerは1台のサーバーで多数のコンテナを実行できますが、その反面、管理やオーケストレーションが必要になり、その処理のためにオーバーヘッドが生じる場合があります。Dockerだけですべての管理を行なうのが困難になることもあります。\n\n### 技能習得に時間がかかる\n\nDockerは他の仮想マシンと異なる手法で仮想環境を構築します。つまり、デベロッパーは新しいコンセプトをすべてゼロから習得しなければならず、それには時間がかかります。Dockerの動作原理をきちんと理解せずに使用すると、あとでトラブルや問題が発生することもあります。Dockerについてしっかりと学習してから運用に取り組むようにしましょう。\n\n### セキュリティに脆弱性が生じることもある\n\nDockerはコンテナ型アーキテクチャです。1台のマシン上で複数のコンテナが動作するため、このことに起因する脆弱性には注意が必要です。たとえば、複数のコンテナがホストOSのリソースやカーネルを共有しているため、一つのコンテナに脆弱性があった場合、全体にその影響が及ぶ可能性があります。\n\n### コンテナ間での連携が難しい\n\n複数のコンテナ間での連携を検討している場合、各種設定が難しいために、運用時に問題が発生することがあります。たとえば、アプリとデータベースを別のコンテナで作成し、一緒に運用したい場合には、同一ホスト内で通信設定をしなければなりません。ポートやソケットを開放する場合にはセキュリティ面でリスクが生じます。それを避けるために設定を複雑にしてしまうと、今度は運用面で問題が起きる恐れがあります。コンテナを連携させる際は、設計段階から十分に検討することが重要です。\n\n## GitLabはDockerが抱える課題をどのように解決するのか\n\nDockerコンテナ内にGitLabをインストールすることができます。[GitLab](https://about.gitlab.com/ja-jp/platform/)は、Git「分散型バージョン管理システム」を主体としたDevSecOpsプラットフォームです。ソフトウェア開発ライフサイクル全体に対応する単一のプラットフォームで、GItLabを活用することで高品質なソフトウェアの迅速なデリバリーを実現できます。\n\nDockerコンテナ内にGitLabをインストールすると、GitLabインスタンスにアクセスできるようになります。Dockerコンテナへの[GitLab Dockerイメージのインストールは公式にサポート](https://about.gitlab.com/ja-jp/install/)されています。\n\nDockerが抱えるいくつかの問題のうち、特にセキュリティについては、GitLabのDevSecOps（開発、セキュリティ、運用）を活用して対処することができます。GitLabのDevSecOpsでは、[シフトレフト](https://about.gitlab.com/ja-jp/topics/ci-cd/shift-left-devops/)を重視しており、セキュリティ対策を開発サイクルの早い段階に組み込むことにより、コンテナイメージの持つセキュリティの問題の早期発見と対応を図っています。継続的インテグレーションによってこのシフトレフトのコンセプトを実践することで、セキュリティ対応にかかっていたコストを削減できます。\n\nDevSecOpsにおいて重要なCI/CDを実現するためには、自動化が欠かせません。GitLabではパイプラインがCI/CDの命令をまとめています。そして、その指示に従いプロセスの自動化を実現するときの基盤になっているのが[GitLab Runner](https://docs.gitlab.com/runner/)（英語）です。GitLab Runnerはセキュリティのシフトレフトを実現する上で重要な役割を果たしています。\n\nGitLab Runnerはセキュリティスキャンやテストを指定したタイミングで自動で実行してくれます。また、レポート作成ジョブを実行して、ダッシュボードに最新情報を表示することも可能です。\n\n## GitLabのDevSecOpsにおけるDockerの役割\n\nGitLabを活用したDevSecOpsインテグレーションにおいても、Dockerは非常に大切な役割を担っています。\n\n### CI/CDジョブのコンテナ化\n\nGitLab CI/CDでは、CI/CDパイプラインでDockerコンテナを使用することで、次のようなことが可能になります。\n\n* **一貫性：** CI/CDジョブはコンテナ内で実行されるため、依存関係や環境の違いによるエラーが防げます。\n* **スケーラビリティ：** コンテナは軽量かつ迅速に起動でき、大規模なパイプラインでも効率的に実行できます。\n* **環境の柔軟性：** ジョブごとに異なるDockerイメージを指定できるため、必要な環境を簡単に準備できます。\n\nGitLab RunnerのDockerイメージは、UbuntuまたはAlpine Linuxをベースにしています。Dockerイメージは標準の`gitlab-runner`コマンドを内包しており、ホストに直接GitLab Runnerをインストールしたかのように動作します。\n\n### セキュリティスキャンの自動化\n\nセキュリティはDevSecOpsでの重要な要素であり、Dockerはこれをサポートします。\n\n* **コンテナイメージのセキュリティスキャン：** GitLabには、CI/CDパイプラインでDockerイメージをスキャンする機能があります。このスキャンにより脆弱性がチェックされ、イメージ内の依存関係やコードの安全性を評価できます。\n* **コンテナ脆弱性スキャンの自動化：** GitLabにはTrivyやAquaなどのセキュリティツールを統合できます。DockerイメージのOSやアプリケーションが最新であるか、既知の脆弱性がないかをチェックします。\n\n### IaC（インフラストラクチャのコード化）と環境管理\n\n* **再現性：** DockerをGitLabのCI/CDジョブ内で使用することで、開発環境と本番環境の整合性を保つことできます。\n* **ステージングやテスト環境を即時に構築：** Docker ComposeやKubernetesと連携することで、特定のブランチやマージリクエストごとに分離された環境をGitLabで作成できます。これにより、テストやセキュリティスキャンを効率的に実行できます。\n\n### デプロイの効率化\n\nGitLabは、Dockerを使用する以下のデプロイパターンをサポートしています。\n\n* **Dockerイメージのビルドとプッシュ：** アプリをコンテナイメージとしてビルドして、GitLabのContainer Registryや他のDockerレジストリにプッシュします。\n* **継続的デリバリー：** Dockerイメージを使ってコンテナオーケストレーションツールにデプロイすることで、迅速で安全なリリースが可能になります。\n\n### マイクロサービスアーキテクチャのサポート\n\nGitLabとDockerを組み合わせることで、マイクロサービスアーキテクチャを簡単に構築できます。マイクロサービスは別々のDockerコンテナとして実行します。GitLab CI/CDパイプラインを使うと、以下のことを管理できます。\n\n* サービス間の依存関係の設定\n* 個別のセキュリティスキャン\n* バージョン管理（ロールバックが容易になります）\n\n## まとめ\n\n2013年の公表以来、Dockerは瞬く間にIT業界に広く普及しました。本記事では、Dockerの基本概念、基本技術、Dockerを使って何ができるのか、なぜDockerが重要なのか、Dockerを理解上でよく目にする用語などについて紹介してきました。\n\nDockerを使う場合には、DevSecOpsにとって大切なCI/CDを実現するためにも、GitLab CI/CDなどの自動化ツールの導入をおすすめします。GitLab のCI/CDパイプラインでDockerコンテナを使用することで、開発における一貫性の維持、スケーラビリティの実現、柔軟な環境の準備が可能になります。\n\n## FAQ（よくある質問）\n\n### Dockerで何ができるのか？\n\nDockerコンテナは、軽量でスタンドアロンの仮想化技術であり、アプリケーションコード、その依存関係、ライブラリをすべてパッケージ化します。Dockerを使うと、1台のマシン上に複数のコンテナ（仮想環境）を構築でき、開発環境や検証環境の統一が図れます。詳しくは、記事の本文をご覧ください。\n\n### Dockerは何に使うのか？\n\nDockerは、デベロッパーがアプリケーションとその依存関係をシステムから切り離したいとき使用します。コンテナにはアプリケーションとその依存関係がまとめられており、軽量な実行環境を提供します。詳しくは、記事の本文をご覧ください。\n\n### Dockerコンテナとは何ですか？\n\nDockerイメージが実行時にコンテナになります。Dockerコンテナは、アプリケーションを実行するためのランタイム環境です。Dockerコンテナに関する詳細は、記事の本文をご覧ください。\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)*\n\n*（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750226168/pf5cwmvqq09v1pe0re66.jpg",[109,1562,1115,9,708,1454,682,709],"cloud native",{"featured":91,"template":686,"slug":1564},"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":1570,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1571,"content":1576,"config":1581,"_id":1583,"_type":14,"title":1584,"_source":16,"_file":1585,"_stem":1586,"_extension":19},"/ja-jp/blog/what-is-local-llm",{"config":1572,"title":1573,"description":1574,"ogImage":1575},{"noIndex":6},"ローカルLLMとは？開発での活用メリットと注意点","ローカルLLMの意味やクラウドLLMとの違い、ソフトウェア開発における導入メリットなどを解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577836/qjcz9aubvivrn4zy1kqr.jpg",{"title":1573,"description":1574,"authors":1577,"heroImage":1575,"date":1578,"body":1579,"category":1541,"tags":1580},[834],"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合同会社ソリューションアーキテクト本部シニアパートナーソリューションアーキテクト）*",[681,9,708,709,682],{"featured":6,"template":686,"slug":1582},"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":1588,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1589,"content":1594,"config":1600,"_id":1602,"_type":14,"title":1603,"_source":16,"_file":1604,"_stem":1605,"_extension":19},"/ja-jp/blog/what-is-platform-engineering",{"config":1590,"ogImage":1591,"title":1592,"description":1593},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508254/duu6d4vclamtnnxjdaat.jpg","プラットフォームエンジニアリングとは？意味や導入メリットをわかりやすく解説","この記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。具体的な導入ステップや基盤構築に役立つおすすめのプラットフォームも。",{"category":1541,"body":1595,"date":1596,"authors":1597,"heroImage":1591,"title":1592,"description":1598,"tags":1599},"近年ソフトウェア開発の領域では「プラットフォームエンジニアリング」と呼ばれる開発者の生産性向上に寄与するアプローチが注目されています。\n\n実際にプラットフォームエンジニアリングに興味はあるものの、意味や定義などを詳しく理解していない人も多いのではないでしょうか。\n\nこの記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。具体的な導入ステップや基盤構築に役立つおすすめのプラットフォームも紹介するのでぜひ参考にして下さい。\n\n## 1. プラットフォームエンジニアリングとは？\n\n![プラットフォームエンジニアリングとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508139/eui82g7mlcb2fr5vavir.jpg)\n\nまずはプラットフォームエンジニアリングの意味や特徴について解説します。\n\n### 1-1. プラットフォームエンジニアリングの意味・特徴\n\nプラットフォームエンジニアリングとは、企業内の開発者に対して適切なプラットフォーム（IDP）を整備し、ソフトウェア開発の効率化や生産性向上を実現するアプローチのことです。\n\n近年はIT技術の発展や消費者ニーズの多様化などを背景として将来の予測が難しい時代（VUCA時代）だと言われています。プラットフォームエンジニアリングは、VUCA時代において複雑化するビジネスニーズに対応するための新しいエンジニアリング手法として、ガートナー社が積極的に提案しているアプローチでもあります。\n\n### 1-2. IDP（内部開発者向けプラットフォーム）とは\n\nInternal Developer Platform（内部開発者向けプラットフォーム、以下IDP）とは、企業内の開発者が開発プロセスにおいて必要な機能やリソースを自ら取得して利用できるプラットフォームを指し、プラットフォームエンジニアリングの導入における重要な技術基盤に当たります。\n\nIDPを通してチームで共通して利用できるツールやリソースを開発者に提供することで、迅速なソフトウェアの構築やデプロイを実現できます。\n\nIDPの構築においては、自社の課題や目的に応じてさまざまなツールや技術を組み合わせて行いますが、[GitLab](https://about.gitlab.com/ja-jp/)のように単一のプラットフォームで開発プロセスにおける多くの作業を効率化できるサービスもあります。\n\n## 2. プラットフォームエンジニアリングが注目されている背景\n\n![プラットフォームエンジニアリングが注目されている背景](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/hvzgimgumavwq5mmfqlx.jpg)\n\nソフトウェア開発の領域でなぜプラットフォームエンジニアリングが注目されているのでしょうか。具体的な背景としては以下が挙げられます。\n\n* 開発環境の複雑化  \n* ビジネス環境の激化  \n* IT人材の不足\n\n### 2-1. 開発環境の複雑化\n\nプラットフォームエンジニアリングの必要性が高まっている背景の一つとしてまず挙げられるのが、開発環境の複雑化による開発者の認知負荷の増大にあります。\n\nソフトウェア開発における開発手法や技術は年々進化・発展し続けており、クラウドや生成AI、マイクロサービス、APIなどさまざまな技術が広く使われるようになっています。これらの技術活用によって柔軟なソフトウェア開発を実現できますが、その一方で管理すべきツールの種類が増え、かつ多様な技術を身につけなければならないという課題が発生します。\n\nそれにより、開発者は重要な開発作業や取り組み以外に自身のリソースを割く必要があり、それが結果としてチーム全体の生産性低下も招くことになります。\n\nつまり、ソフトウェア開発において効果的に最新技術を取り入れていくためには、開発者が本質的な業務に集中できる環境を構築しなければなりません。\n\n### 2-2. ビジネス環境の激化\n\n先ほども少し触れていますが、近年は[VUCA時代](https://www.nri.com/jp/knowledge/glossary/vuca.html)と呼ばれる将来の予測が難しい不確実な要素が多い時代です。\n\n市場が常に変化する中で社会や消費者にとって必要とされる価値あるソフトウェアを開発して競合と差別化を図るためには、多様な技術を活用したスケーラブルな開発が求められます。\n\nまた、自社の競争力を高めていくためには、アジャイル開発のようなスピード感のある開発手法を積極的に採用していく考えも大切です。\n\n開発者がセルフサービスで利用できるプラットフォームの提供は、柔軟かつ迅速なソフトウェア開発を実現する手段として有効なアプローチだと言えます。\n\n[アジャイル開発とは？意味や進め方、DevSecOpsとの関係性を解説](https://about.gitlab.com/ja-jp/blog/what-is-agile-development/)\n\n### 2-3. IT人材の不足\n\nソフトウェア開発の領域では、慢性的な人手不足が課題となっています。クラウドやAIなど高度な最新技術が次々と登場する一方で、それらを扱える専門知識を持った人材が業界全体で不足しているのです。\n\n実際に「[IT人材需給に関する調査](https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf)」を見てみると、2030年には最大で約79万人のIT人材が不足すると予測されています。\n\n![IT人材需給に関する調査](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/zv15e7qpd6cppogiogat.png)\n\n※引用元：[IT人材需給に関する調査](https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf)\n\nこのような背景の中で適切にソフトウェア開発を進めていくためには、プラットフォームエンジニアリングの導入を通じて開発者の負担削減や生産性向上を実現し、自社のリソースを上手に活用していく姿勢や工夫が求められると言えます。\n\n## 3. プラットフォームエンジニアリングとDevSecOps・SREとの関係性とは\n\n![プラットフォームエンジニアリングとDevSecOps・SREとの関係性とは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/psg7uvfabu13r50vbwzc.jpg)\n\nプラットフォームエンジニアリングを理解する上では、DevSecOpsやSREとの違いについても把握しておくことが大切です。\n\n### 3-1. DevSecOpsとの違い\n\nDevSecOpsとは、開発（Dev）、セキュリティ（Sec）、運用（Ops）の3つの領域を連携させて開発を進めるアプローチを指します。開発と運用を連携してリリースサイクルを短縮させる従来の「DevOps」の考え方に対して、セキュリティ（Sec）のプロセスも加えることでソフトウェアの安全性を確保しつつ、迅速なリリースが可能になります。\n\n一方、プラットフォームエンジニアリングはDevSecOpのようなワークフローを実現する上で土台となるプラットフォームを社内で整備する取り組みです。\n\nつまり、プラットフォームエンジニアリングとDevSecOpsは親和性が高く、プラットフォームエンジニアリングはDevSecOpsをサポートする役割を担っていると言えます。\n\n### 3-2. SREとの違い\n\nSREとは、「Site Reliability Engineering」の略語で直訳すると、「サイト信頼性エンジニアリング」になります。Google社によって提唱された概念であり、運用プロセスにおいて手間のかかるタスクを自動化してシステムの安定稼働を実現しつつ、新機能の追加や更新などを通してユーザー体験（UX）の向上を目指す取り組みを指します。\n\nプラットフォームエンジニアリングとSREは、いずれも開発と運用における効率性・信頼性向上に関わるものですが、それぞれ目的や焦点が異なります。\n\nプラットフォームエンジニアリングは、社内の開発者の生産性向上や利便性向上を目的としたアプローチであり、SREは主にシステムの信頼性と可用性、スケーラビリティの向上に焦点を当てた考え方になります。\n\n## 4. プラットフォームエンジニアリングの導入目的とメリット\n\n![プラットフォームエンジニアリングの導入目的とメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508134/m2jqfbt1sfjpjqh3dbih.jpg)\n\nプラットフォームエンジニアリングの導入目的やメリットは以下の通りです。\n\n* 開発プロセスの効率化  \n* 開発者の生産性向上  \n* プロダクトの品質向上  \n* セキュリティ・ガバナンスの維持と強化  \n* 人材不足の解消  \n* 新しいイノベーションの創出  \n* コスト削減\n\n### 4-1. 開発プロセスの効率化\n\nまずプラットフォームエンジニアリングの導入は、開発プロセスの効率化につなげられます。\n\nIDPにより開発者は開発に必要なリソースを必要な時に素早く取得して利用できるため、環境構築に手間と時間をかけることなく本質的な開発業務に集中することが可能です。\n\nアジャイル開発やDevSecOpsの手法を活用する際に、積極的にプラットフォームエンジニアリングの考え方も採用すれば、プロダクトや機能のリリース頻度・スピードが向上し、自社ビジネスの加速化に貢献できるでしょう。\n\n### 4-2. 開発者の生産性向上\n\nプラットフォームエンジニアリングでIDPを整備することで、チームで再利用可能なツールと機能を開発者に提供できるようになります。この仕組みにより、開発者それぞれで多数のツールを管理・運用する手間がなくなり、認知的負荷の軽減につなげられるでしょう。\n\nその結果、戦略立案や分析、新機能開発などより重要な業務にリソースを割けるようになり、生産性の最大化を図れるでしょう。\n\n### 4-3. プロダクトの品質向上\n\n顧客が満足するプロダクトを提供するためには、品質も担保しなければなりません。IDPに対してテストやレビュー、セキュリティスキャン、デプロイなどを自動化する仕組みを整備すれば、ヒューマンエラーの防止につなげられます。\n\nプラットフォームエンジニアリングの導入でテストやレビューなどを標準化することによって、開発者やプロジェクトごとの品質のバラつきを防止でき、自社で定義されたプラットフォームの基準に沿って開発と運用を進められます。\n\nつまり、プラットフォームエンジニアリングの導入は、開発効率や生産性の向上だけでなく、プロダクト品質や信頼性の向上にも寄与します。\n\n### 4-4. セキュリティ・ガバナンスの維持と強化\n\nプラットフォームエンジニアリングで自社に必要なセキュリティやガバナンスを定義し、それらを自社のプラットフォーム上に反映させて運用することも可能です。\n\n権限設定や監査ログ、セキュリティポリシー、脆弱性対応などをプラットフォーム上で集約して一元化することで管理や証跡の収集が容易になり、組織全体におけるセキュリティ・ガバナンスの維持と強化につなげられるでしょう。\n\nまた、標準化されたプラットフォームの整備によって、開発者の心理的な負担を軽減して安全に開発を進められます。\n\n### 4-5. 人材不足の解消\n\nプラットフォームエンジニアリングの導入は、開発プロセスの効率化や開発者の生産性向上に寄与するため、企業のリソースを最大限に活かしながらソフトウェア開発を進められます。\n\nまた、開発者のニーズにマッチしたプラットフォームを提供して働きやすい環境を構築することで、開発者体験（Developer Experience）の向上も実現できます。その結果、自社に対する開発者や求職者からのイメージも良くなり、優秀なエンジニアの獲得と定着を図れるでしょう。\n\n### 4-6. 新しいイノベーションの創出\n\n近年ソフトウェア開発の効率化や価値向上に役立つさまざまな最新技術が登場しています。しかし、複数の技術やツールを開発者個人で活用するには管理の負担が増えてしまい、実際の活用にはハードルが高いと言えます。\n\nプラットフォームエンジニアリングならさまざまな機能やツールが搭載されたプラットフォームをチームで利用できるため、開発者全員が最新技術に触れやすくなります。それをきっかけとして自社で新しいアイデアやイノベーションが生まれたり、より品質の高いプロダクトをリリースできたりする可能性が高まるでしょう。\n\n### 4-7. コスト削減\n\nプラットフォームエンジニアリングを取り入れることで、ツールや環境の共通化によるコスト削減にもつながります。例えば、ソフトウェア開発のプロセスにおいて複数のツールを活用している企業が、[GitLab](https://about.gitlab.com/ja-jp/)のようなさまざまなツールを単一のプラットフォームで利用できるサービスを導入すれば、ライセンス費用や管理コストの削減につなげられるでしょう。\n\nまた、CI/CDやセキュリティチェックなどをプラットフォーム上で自動化することで運用コストの削減も実現できます。\n\nワークフローの自動化や標準化により開発スピードが向上すれば、限られたリソースを効果的に活用できるため、長期的な人件費の最適化にもつながります。\n\n## 5. プラットフォームエンジニアリングの導入ステップ\n\n![プラットフォームエンジニアリングの導入ステップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/cep3gdqsqca4gb0ckt2w.jpg)\n\nここでは実際にプラットフォームエンジニアリングを導入する際の手順について見ていきましょう。\n\n1. 専門チームの組成  \n2. 開発課題の分析と目標設定  \n3. プラットフォームの構築・組織体制の変更  \n4. フィードバック・継続的なメンテナンス\n\n### 5-1. 専門チームの組成\n\nプラットフォームエンジニアリングを導入する際には、まず専門チームの組成から始めます。専門チームを社内に配置すれば、プラットフォームエンジニアリング導入の取り組みを推進できます。専門チームの主な役割としては以下が挙げられます。\n\n* 開発者のニーズ調査  \n* プラットフォームの設計・構築  \n* 社内でのプラットフォーム活用の浸透の実現  \n* プラットフォームの運用・定期的な改善 など\n\n実際のメンバー構成においては、開発者のさまざまなニーズを考慮したプラットフォームを導入するためにも、開発・運用・セキュリティなど多様なスキルセットを持つ人材や、それぞれの分野を専門とする人材を集めることがポイントです。\n\nまた、社内向けではあるものの、自社での活用を浸透させるためにはプラットフォームを一つのサービスとして捉え、ユーザーニーズを満たすという視点が重要になります。\n\n### 5-2. 開発課題の分析と目標設定\n\nプラットフォームエンジニアリングの専門チーム結成後は、現状の開発課題の把握と分析を実施します。課題の把握や分析においては、エンジニアとの個別面談やサーベイなどを通して行います。\n\nその中で、「複数のツールを管理するための負担がかかり過ぎている」「開発環境の構築から実際のリリースまで時間がかかっており、開発効率が悪い」などの課題が挙げられたなら、それらの課題を解決するためにどのようなプラットフォームを導入すれば良いのかを検討し、具体的な目標を設定します。\n\n例えば、開発者のツール管理の負担が主な課題としてあるなら、単一のプラットフォームで複数のツールや技術を活用できるIDPを整備するという方向性を定められるでしょう。\n\n### 5-3. プラットフォームの構築・組織体制の変更\n\nプラットフォームエンジニアリングの導入における目標や方向性が明確になった後は、実際に基盤となるプラットフォームの構築を行います。\n\n開発プロセスの課題解決につながるような機能やツールを搭載し、さまざまな手法で開発を進められるよう整備していきます。\n\nまた、プラットフォームを構築して実際に活用していく際には、これまでの開発プロセスに変化が生じるため、必要に応じて開発者間での認識の擦り合わせや組織体制の変更を行いましょう。\n\n### 5-4. フィードバック・継続的なメンテナンス\n\nプラットフォームエンジニアリングの基盤構築後は、実際にプラットフォームを運用し開発者に活用してもらいます。その中で開発者からフィードバックや要望があれば、機能追加や改善を柔軟に行っていきます。\n\nソフトウェア開発におけるツールや技術は進化し続けており、トレンドも常に移り変わるため、最新情報のキャッチアップや定期的なメンテナンスがプラットフォームエンジニアリングを成功させるための鍵となります。\n\n## 6. プラットフォームエンジニアリングの導入における注意点\n\n![プラットフォームエンジニアリングの導入における注意点](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/ew7szhpm1mnheubghlnk.jpg)\n\nプラットフォームエンジニアリングの導入においては以下のような注意点もあります。\n\n* プラットフォーム構築を目的としない  \n* 導入に効果が期待できるか見極める  \n* トップダウンでの導入は避ける  \n* 段階的に導入して小さく始める\n\n### 6-1. プラットフォーム構築を目的としない\n\nまずプラットフォームエンジニアリングの導入において、プラットフォーム構築そのものを目的として進めてしまうと失敗してしまう可能性が高まります。\n\n例えば、「最新技術だから」「高機能だから」というような考えだけで導入してしまうと、開発者ニーズにマッチしないプラットフォームを構築してしまうことになります。そうなると、社内での活用も浸透せず、誰にも使われないという結果を招いてしまうでしょう。\n\nそのため、開発者への調査を徹底して行い、どんな課題を解決したいのかを明確にした上でプラットフォームを構築する必要があります。\n\n### 6-2. 導入に効果が期待できるか見極める\n\nプラットフォームエンジニアリングの導入そのものが、実際に自社にとって効果が期待できるのかも見極めなければなりません。\n\n例えば、エンタープライズや中規模など大きめ組織で、かつ必要な人材が揃っているなら、専門チームの組成もスムーズに進み、実際のプラットフォーム構築によって開発の効率化やコスト削減などの効果が期待できる可能性が高いと言えます。\n\n一方、小規模な組織の場合で、かつ人手が足りない場合プラットフォーム構築や運用そのものに大きな負担がかかってしまい、逆効果になる可能性もあります。\n\nそのため、「プラットフォームエンジニアリングの導入や運用が自社で可能なのか」「実際にどのような効果が期待できるのか」をきちんと検討することが大切です。\n\n### 6-3. トップダウンでの導入は避ける\n\nプラットフォームエンジニアリングは開発者向けのアプローチであり、開発者がプラットフォームを問題なくセルフサービスで利用できるという要素が重要になります。\n\nそのため、トップダウンで現場の課題や開発者のニーズを無視して導入を進めてしまうと、新しいやり方に対して開発者から抵抗や反発を受ける可能性があります。\n\nスムーズな導入を実現するためには、経営層と開発者で双方向コミュニケーションをとり、開発者に選択の余地とアイデアを積極的に発信できる場を与える必要があります。\n\n### 6-4. 段階的に導入して小さく始める\n\n最初から全ての要件を満たした完璧なプラットフォームを構築して、運用しようとすると開発者が変化に対応しきれない可能性があります。また、時間をかけてプラットフォームを構築しているとトレンドに乗り遅れ、完成後には搭載した技術やツールが既に古いものになってしまっていたというケースも考えられます。\n\nそのため、まずは優先度の高い課題にフォーカスして、効果が期待できる機能から実装し段階的に運用するなど、アジャイル的な進め方がプラットフォームエンジニアリングの導入に求められると言えます。\n\n## 7. プラットフォームエンジニアリングの基盤構築に役立つツール・サービスの選び方\n\n![プラットフォームエンジニアリングの基盤構築に役立つツール・サービスの選び方](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508136/bdq3zpkcrz1ez00md2yr.jpg)\n\nプラットフォームエンジニアリングの導入においては、基盤構築に役立つサービスを積極的に活用すると効率的です。ここでは具体的な選び方を解説します。\n\n* 機能  \n* コスト  \n* サポート体制\n\n### 7-1. 機能\n\nプラットフォームエンジニアリングの導入を成功させるためには、開発者のニーズを満たし、かつ自社の課題を解決できる機能が搭載されたサービスを選ぶことが大切です。\n\n例えば、プラットフォームを構成する重要な要素として挙げられる機能は以下の通りです。\n\n* CI/CD（自動ビルド・テスト・デプロイ）  \n* ソースコード管理  \n* ドキュメント  \n* モニタリング  \n* API連携  \n* セキュリティ・ガバナンス など\n\nこのような機能が搭載されているサービスなら、開発者の生産性向上に貢献できるでしょう。\n\n### 7-2. コスト\n\nプラットフォームエンジニアリングの基盤構築となるサービスを選定する際には、コスト面も考慮することが大切です。\n\n組織の規模や導入形態などによってもコストが異なるため、ベンダーに問い合わせするなどして費用対効果が期待できるかしっかりチェックしておきましょう。\n\n無料トライアルを設けているサービスも多いため、まずは使用感を試してみてから導入を検討するのも良いでしょう。\n\n### 7-3. サポート体制\n\nプラットフォームエンジニアリングをスムーズに導入・運用していくためには、ツールやサービスを提供するベンダーのサポート体制をチェックしておく必要もあります。\n\n充実したサポート体制があれば、万が一トラブルや不明点が発生した場合でも、専任スタッフが迅速に対応してくれるでしょう。また、ベンダーがドキュメントやマニュアルなどを通して積極的にノウハウを公開していれば、トラブル時にも自社で解決しやすくなるでしょう。\n\n## 8. プラットフォームエンジニアリングの基盤構築なら「GitLab」\n\n![プラットフォームエンジニアリングの基盤構築なら「GitLab」](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/hy8mmygwnbm0ws0ejtik.png)\n\nプラットフォームエンジニアリングの基盤構築をスムーズに実現するなら「[GitLab](https://about.gitlab.com/ja-jp/)」の活用がおすすめです。ここでは、GitLabのサービス概要や強みについて紹介します。\n\n### 8-1. GitLabとは\n\nGitLabは、DevSecOpsワークフローを支援するAIを搭載したプラットフォームです。AIによるソースコード管理やセキュリティ対策、CI/CD、コンプライアンス管理など豊富な機能を単一のプラットフォームで活用でき、プラットフォームエンジニアリングの基盤構築に役立てられます。\n\n中小企業からエンタープライズまで多くの企業で導入されているプラットフォームで、高品質かつ迅速なソフトウェア開発を実現できます。\n\n### 8-2. GitLabが選ばれる理由\n\nGitLabの強みは、DevSecOpsツールチェーンの構築を単一のプラットフォームで実現できることです。これまで複数のツールを管理していた企業がGitLabを導入すれば、コスト削減や開発者の認知負荷の軽減につなげられ、プラットフォームエンジニアリングの運用をスムーズに行えるようになります。\n\nチーム全員で単一のプラットフォームを通して作業することで、メンバー間の連携や情報共有も容易に実施できます。また、サポート体制も充実しているため、導入と運用においても安心して進められるのも強みの一つです。\n\nGitLabを通してプラットフォームエンジニアリングを実現すれば、ソフトウェア開発のライフサイクル全体を効率化でき、競合との差別化につながる機能開発など本質的な作業に集中できるようになるでしょう。\n\n## 9. GitLabによるプラットフォームエンジニアリング実現のアプローチと活用例\n\n![GitLabによるプラットフォームエンジニアリング実現のアプローチと活用例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508136/gn4zixnirbsgrk1anwi8.jpg)\n\n実際にGitLabによるプラットフォームエンジニアリング実現のアプローチと活用例を紹介します。\n\n* 再利用可能なCI/CDコンポーネント  \n* セキュリティとコンプライアンス  \n* データ活用と分析  \n* コミュニケーションの効率化\n\n### 9-1. 再利用可能なCI/CDコンポーネント\n\nCI/CDコンポーネントは、再利用可能な単一のパイプライン構成ユニットのことで、この機能を使用すればCI/CDパイプラインの設定が容易になります。\n\nまた、再利用可能なCI/CDコンポーネントをリスト化して、各コンポーネントの情報を確認できる「[CI/CDカタログ](https://gitlab.com/explore/catalog)」も提供しています。コンポーネントが一元管理されているため、必要なものを必要な時に見つけ出して再利用できる仕様となっています。\n\nこれにより、開発者の作業効率向上や、組織全体でのスムーズなナレッジ共有を実現できるでしょう。\n\nCI/CDコンポーネントの詳細については以下のページをご覧下さい。\n\n[GitLab入門：CI/CDについて理解する](https://about.gitlab.com/ja-jp/blog/getting-started-with-gitlab-understanding-ci-cd/)\n\n### 9-2. セキュリティとコンプライアンス\n\nGitLabでは、ソフトウェア開発ライフサイクルの全てのステージに対応したセキュリティやコンプライアンス機能を搭載しています。\n\n開発を進める中で、セキュリティリスクなどの問題を早期に発見して対応できるため、トラブル発生時の対応コストを抑えたり、事態の深刻化を未然に防止したりすることが可能です。\n\n### 9-3. データ活用と分析\n\nGitLabでは、データ活用と分析による開発の効率性向上も実現できます。プロジェクトの運用状況などソフトウェア開発ライフサイクルにおけるさまざまなデータが一元管理されている仕組みとなっているため、関係者全員がスムーズに必要な情報にアクセスできます。\n\nまた、 プラットフォームに蓄積された主要なメトリクスを追跡して問題点を詳細に分析することで、迅速な改善や顧客価値の向上につなげられます。GitLabでは、DevOpsのパフォーマンスや健全性を示す[DORAメトリクス](https://docs.gitlab.com/user/analytics/dora_metrics/)の可視化・分析機能などを提供しています。\n\n### 9-4. コミュニケーションの効率化\n\nGitLabは統合型プラットフォームであり、全員が同じツールにアクセスして利用できるようになるため、開発者間でのコミュニケーションが効率化されます。\n\n誰もがアクセスしやすい共同ドキュメントの作成も可能であるため、別のツールに切り替えて作業する必要がなく、情報の共有や整理が容易になります。\n\nなお、プラットフォームエンジニアリングにおけるGitLab活用の詳細については以下のページをご覧下さい。\n\n> [プラットフォームエンジニアリングにおけるGitLabの活用](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)\n\n[](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)\n\n## まとめ： プラットフォームエンジニアリングの実現により開発品質の向上と効率化を図ろう\n\nプラットフォームエンジニアリングの導入は、ビジネス環境が激化している時代において重要視されているアプローチです。実際の導入においては、適切な専門チームの組成やツール・サービスの選定が大切なポイントとなってきます。\n\nプラットフォームエンジニアリングの基盤構築なら、ぜひ[GitLab](https://about.gitlab.com/ja-jp/)をご活用下さい。GitLabなら単一のプラットフォームで豊富な機能を利用できるため、開発者の認知負荷を軽減し、迅速かつ品質の高いソフトウェア開発を実現できます。\n\nなお、GitLabでは世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧下さい。\n\n> [2024グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-platform-engineering)\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)*\n\n*（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","2025-09-22",[834],"この記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。",[109,707,1115,9,708,1454,709,710],{"featured":6,"template":686,"slug":1601},"what-is-platform-engineering","content:ja-jp:blog:what-is-platform-engineering.yml","What Is Platform Engineering","ja-jp/blog/what-is-platform-engineering.yml","ja-jp/blog/what-is-platform-engineering",{"_path":1607,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1608,"content":1614,"config":1619,"_id":1621,"_type":14,"title":1622,"_source":16,"_file":1623,"_stem":1624,"_extension":19},"/ja-jp/blog/what-is-sbom",{"title":1609,"description":1610,"ogTitle":1609,"ogDescription":1610,"noIndex":6,"ogImage":1611,"ogUrl":1612,"ogSiteName":670,"ogType":671,"canonicalUrls":1612,"schema":1613},"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":1609,"description":1610,"authors":1615,"heroImage":1611,"date":1616,"body":1617,"category":682,"tags":1618},[727,1029],"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 フィールド最高技術責任者）*",[682,9,1454,1455],{"slug":1620,"featured":91,"template":686},"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":1626,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1627,"content":1633,"config":1639,"_id":1641,"_type":14,"title":1642,"_source":16,"_file":1643,"_stem":1644,"_extension":19},"/ja-jp/blog/what-is-yaml",{"ogTitle":1628,"schema":1629,"ogImage":1630,"ogDescription":1631,"ogSiteName":670,"noIndex":6,"ogType":671,"ogUrl":1632,"title":1628,"canonicalUrls":1632,"description":1631},"拡張子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":1628,"description":1631,"authors":1634,"heroImage":1630,"date":1635,"body":1636,"category":1541,"tags":1637},[727,1029],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[1115,1638,9,109,532,1562,709,710,1455,1480],"kubernetes",{"slug":1640,"featured":91,"template":686},"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":1646,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1647,"content":1653,"config":1659,"_id":1661,"_type":14,"title":1662,"_source":16,"_file":1663,"_stem":1664,"_extension":19},"/ja-jp/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"title":1648,"description":1649,"ogTitle":1648,"ogDescription":1649,"noIndex":6,"ogImage":1650,"ogUrl":1651,"ogSiteName":670,"ogType":671,"canonicalUrls":1651,"schema":1652},"統合された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":1648,"description":1649,"authors":1654,"heroImage":1650,"date":1656,"body":1657,"category":10,"tags":1658},[1655],"Itzik Gan Baruch","2025-06-02","今日の最新のソフトウェア開発を取り巻く環境では、多くの組織がクラウドに移行し、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/)",[9,732,1033],{"slug":1660,"featured":6,"template":686},"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":1666,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1667,"content":1671,"config":1679,"_id":1681,"_type":14,"title":1682,"_source":16,"_file":1683,"_stem":1684,"_extension":19},"/ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"config":1668,"title":1669,"description":1670},{"noIndex":6},"DevSecOpsにおける企業の独立性がこれまで以上に重要な理由","開発インフラを誰がコントロールしているのか、リーダーたちが疑問を持つ中、GitLabの独立性と透明性の優位性はかつてないほど注目されています。",{"heroImage":1672,"body":1673,"authors":1674,"updatedDate":1676,"date":1677,"title":1669,"tags":1678,"description":1670,"category":698},"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/)",[1675],"Robin Schulman","2025-09-03","2025-09-02",[681,9,1033,708,1455],{"featured":91,"template":686,"slug":1680},"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",1760103634851]