[{"data":1,"prerenderedAt":1325},["ShallowReactive",2],{"/en-us/blog/tags/security/":3,"navigation-ja-jp":19,"banner-ja-jp":436,"footer-ja-jp":449,"security-tag-page-ja-jp":658},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/en-us/blog/tags/security","tags",false,"",{"tag":9,"tagSlug":9},"security",{"template":11},"BlogTag","content:en-us:blog:tags:security.yml","yaml","Security","content","en-us/blog/tags/security.yml","en-us/blog/tags/security","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":432,"_type":13,"title":433,"_source":15,"_file":434,"_stem":435,"_extension":18},"/shared/ja-jp/main-navigation","ja-jp",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":376,"minimal":410,"duo":423},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/ja-jp/","gitlab logo","header",{"text":29,"config":30},"無料トライアルを開始",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"お問い合わせ",{"href":36,"dataGaName":37,"dataGaLocation":27},"/ja-jp/sales/","sales",{"text":39,"config":40},"サインイン",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,187,192,298,358],{"text":45,"config":46,"cards":48,"footer":71},"プラットフォーム",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":52,"config":53},"プラットフォームを詳しく見る",{"href":54,"dataGaName":47,"dataGaLocation":27},"/ja-jp/platform/",{"title":56,"description":57,"link":58},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":59,"config":60},"GitLab Duoのご紹介",{"href":61,"dataGaName":62,"dataGaLocation":27},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":67,"config":68},"詳細はこちら",{"href":69,"dataGaName":70,"dataGaLocation":27},"/ja-jp/why-gitlab/","why gitlab",{"title":72,"items":73},"利用を開始：",[74,79,84],{"text":75,"config":76},"プラットフォームエンジニアリング",{"href":77,"dataGaName":78,"dataGaLocation":27},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"開発者の経験",{"href":82,"dataGaName":83,"dataGaLocation":27},"/ja-jp/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":169},"製品",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"すべてのソリューションを表示",{"href":96,"dataGaName":92,"dataGaLocation":27},"/ja-jp/solutions/",[98,124,147],{"title":99,"description":100,"link":101,"items":106},"自動化","CI/CDと自動化でデプロイを加速",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,111,115,120],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/ja-jp/solutions/continuous-integration/",{"text":112,"config":113},"AIアシストによる開発",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"ソースコード管理",{"href":118,"dataGaLocation":27,"dataGaName":119},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"自動化されたソフトウェアデリバリー",{"href":104,"dataGaLocation":27,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":27,"icon":131},"/ja-jp/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,138,143],{"text":134,"config":135},"Application Security Testing",{"href":136,"dataGaName":137,"dataGaLocation":27},"/solutions/application-security-testing/","Application security testing",{"text":139,"config":140},"ソフトウェアサプライチェーンの安全性",{"href":141,"dataGaLocation":27,"dataGaName":142},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":27},"/solutions/software-compliance/",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":27},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":27,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":27,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":27,"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":27,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":27,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共機関",{"href":185,"dataGaLocation":27,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":27,"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":27},"/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":27},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":27},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":27,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":27},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":27},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247,252],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":27},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":27},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":27},"/ja-jp/teamops/","teamops",{"title":258,"items":259},"つなげる",[260,265,270,275,280],{"text":261,"config":262},"GitLabサービス",{"href":263,"dataGaName":264,"dataGaLocation":27},"/ja-jp/services/","services",{"text":266,"config":267},"コミュニティ",{"href":268,"dataGaName":269,"dataGaLocation":27},"/community/","community",{"text":271,"config":272},"フォーラム",{"href":273,"dataGaName":274,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"イベント",{"href":278,"dataGaName":279,"dataGaLocation":27},"/events/","events",{"text":281,"config":282},"パートナー",{"href":283,"dataGaName":284,"dataGaLocation":27},"/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":27},"/ja-jp/the-source/","the source",{"text":299,"config":300,"lists":302},"Company",{"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":27},"/ja-jp/company/","about",{"text":311,"config":312,"footerGa":315},"採用情報",{"href":313,"dataGaName":314,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":27},{"text":319,"config":320},"経営陣",{"href":321,"dataGaName":322,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":324,"config":325},"チーム",{"href":326,"dataGaName":327,"dataGaLocation":27},"/company/team/","team",{"text":329,"config":330},"ハンドブック",{"href":331,"dataGaName":332,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"投資家向け情報",{"href":336,"dataGaName":337,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"トラストセンター",{"href":341,"dataGaName":342,"dataGaLocation":27},"/ja-jp/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":27},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"ニュースレター",{"href":351,"dataGaName":352,"dataGaLocation":27},"/company/contact/","newsletter",{"text":354,"config":355},"プレス",{"href":356,"dataGaName":357,"dataGaLocation":27},"/press/","press",{"text":34,"config":359,"lists":360},{"dataNavLevelOne":301},[361],{"items":362},[363,366,371],{"text":34,"config":364},{"href":36,"dataGaName":365,"dataGaLocation":27},"talk to sales",{"text":367,"config":368},"サポートを受ける",{"href":369,"dataGaName":370,"dataGaLocation":27},"/support/","get help",{"text":372,"config":373},"カスタマーポータル",{"href":374,"dataGaName":375,"dataGaLocation":27},"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":41,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"提案",[388,391,396,398,402,406],{"text":56,"config":389},{"href":61,"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":108,"config":397},{"href":110,"dataGaName":108,"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":69,"dataGaName":409,"dataGaLocation":384},"Why GitLab?",{"freeTrial":411,"mobileIcon":415,"desktopIcon":420},{"text":29,"config":412},{"href":413,"dataGaName":32,"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":61,"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":21,"_draft":6,"_partial":6,"_locale":7,"title":438,"button":439,"config":444,"_id":446,"_type":13,"_source":15,"_file":447,"_stem":448,"_extension":18},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":440,"config":441},"ベータ版を試す",{"href":442,"dataGaName":443,"dataGaLocation":27},"/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":21,"_draft":6,"_partial":6,"_locale":7,"data":451,"_id":654,"_type":13,"title":655,"_source":15,"_file":656,"_stem":657,"_extension":18},"/shared/ja-jp/main-footer",{"text":452,"source":453,"edit":459,"contribute":464,"config":469,"items":474,"minimal":646},"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,618],{"title":45,"links":476,"subMenu":481},[477],{"text":478,"config":479},"DevSecOpsプラットフォーム",{"href":54,"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":136,"dataGaName":137,"dataGaLocation":458},{"text":121,"config":510},{"href":104,"dataGaName":105,"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":118,"dataGaName":524,"dataGaLocation":458},"source code management",{"text":108,"config":526},{"href":110,"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":299,"links":585},[586,588,590,592,594,596,598,602,607,609,611,613],{"text":306,"config":587},{"href":308,"dataGaName":301,"dataGaLocation":458},{"text":311,"config":589},{"href":313,"dataGaName":314,"dataGaLocation":458},{"text":319,"config":591},{"href":321,"dataGaName":322,"dataGaLocation":458},{"text":324,"config":593},{"href":326,"dataGaName":327,"dataGaLocation":458},{"text":329,"config":595},{"href":331,"dataGaName":332,"dataGaLocation":458},{"text":334,"config":597},{"href":336,"dataGaName":337,"dataGaLocation":458},{"text":599,"config":600},"Sustainability",{"href":601,"dataGaName":599,"dataGaLocation":458},"/sustainability/",{"text":603,"config":604},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":605,"dataGaName":606,"dataGaLocation":458},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":608},{"href":341,"dataGaName":342,"dataGaLocation":458},{"text":349,"config":610},{"href":351,"dataGaName":352,"dataGaLocation":458},{"text":354,"config":612},{"href":356,"dataGaName":357,"dataGaLocation":458},{"text":614,"config":615},"現代奴隷制の透明性に関する声明",{"href":616,"dataGaName":617,"dataGaLocation":458},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":34,"links":619},[620,622,624,626,631,636,641],{"text":34,"config":621},{"href":36,"dataGaName":37,"dataGaLocation":458},{"text":367,"config":623},{"href":369,"dataGaName":370,"dataGaLocation":458},{"text":372,"config":625},{"href":374,"dataGaName":375,"dataGaLocation":458},{"text":627,"config":628},"ステータス",{"href":629,"dataGaName":630,"dataGaLocation":458},"https://status.gitlab.com/","status",{"text":632,"config":633},"利用規約",{"href":634,"dataGaName":635,"dataGaLocation":458},"/terms/","terms of use",{"text":637,"config":638},"プライバシーに関する声明",{"href":639,"dataGaName":640,"dataGaLocation":458},"/ja-jp/privacy/","privacy statement",{"text":642,"config":643},"Cookieの設定",{"dataGaName":644,"dataGaLocation":458,"id":645,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":458},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":458},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":458,"id":645,"isOneTrustButton":90},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"allPosts":659,"featuredPost":1302,"totalPagesCount":1323,"initialPosts":1324},[660,689,715,738,759,781,801,820,838,859,878,901,922,942,961,982,1003,1023,1039,1058,1077,1097,1118,1141,1161,1181,1201,1224,1245,1263,1283],{"_path":661,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":662,"content":666,"config":682,"_id":685,"_type":13,"title":686,"_source":15,"_file":687,"_stem":688,"_extension":18},"/ja-jp/blog/claude-code-gitlab-ai-development-workflow",{"noIndex":6,"title":663,"description":664,"ogImage":665},"エージェンティックAI Claude CodeとGitLab CLIの開発フロー","Claude CodeとGLabを組み合わせてローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIのコード補助を活かした開発フローを構築する方法を紹介","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751953181/rtejicnkhd9oslaxsoo5.jpg",{"heroImage":665,"category":667,"body":668,"date":669,"authors":670,"description":672,"title":673,"tags":674},"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",[671],"Naoharu Sasaki","エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法をご紹介します。","Claude Code × GitLab：AI活用を加速する、エージェンティックAIとGitLab CLIによる効率的なソフトウェア開発フロー",[675,108,676,677,678,679,532,233,9,680,681],"AI/ML","code review","collaboration","DevSecOps","features","tutorial","workflow",{"featured":90,"template":683,"slug":684},"BlogPost","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":690,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":691,"content":699,"config":709,"_id":711,"_type":13,"title":712,"_source":15,"_file":713,"_stem":714,"_extension":18},"/ja-jp/blog/customers-sourcenext",{"title":692,"description":693,"ogTitle":692,"ogDescription":693,"noIndex":6,"ogImage":694,"ogUrl":695,"ogSiteName":696,"ogType":697,"canonicalUrls":695,"schema":698},"外部開発パートナーを含む開発プロセスを、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","https://about.gitlab.com","article","\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":692,"description":693,"authors":700,"heroImage":694,"date":702,"body":703,"category":704,"tags":705},[701],"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",[706,707,108,9,678,708],"DevSecOps platform","customers","user stories",{"slug":710,"featured":90,"template":683},"customers-sourcenext","content:ja-jp:blog:customers-sourcenext.yml","Customers Sourcenext","ja-jp/blog/customers-sourcenext.yml","ja-jp/blog/customers-sourcenext",{"_path":716,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":723,"config":732,"_id":734,"_type":13,"title":735,"_source":15,"_file":736,"_stem":737,"_extension":18},"/ja-jp/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"title":718,"description":719,"ogTitle":718,"ogDescription":719,"noIndex":6,"ogImage":720,"ogUrl":721,"ogSiteName":696,"ogType":697,"canonicalUrls":721,"schema":722},"GitLab Duo開発の現場から：AIを活用したセキュリティ脆弱性の修正","このチュートリアルでは、GitLab Duoの脆弱性の説明と脆弱性の修正、その他のAI搭載機能が、脆弱性に迅速に対処するのにどのように役立つのかをご説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098106/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098106040.png","https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から：AIを活用したセキュリティ脆弱性の修正\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"},{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2024-07-15\",\n      }",{"title":718,"description":719,"authors":724,"heroImage":720,"date":727,"body":728,"category":667,"tags":729,"updatedDate":731},[725,726],"Michael Friedrich","Alana Bellucci","2024-07-15","新しい仕事を始めたばかりの初日、大規模な本番環境でのインシデントが発生し、全員での対応が求められる状況に直面したとします。いくつもの重大な脆弱性が新たに発覚し、即時の対応、分析、軽減、そして修正が必要です。こうした場合、どこから調査を始めるべきでしょうか？\n\n\nこの記事では、GitLab\nDuoの脆弱性の説明や脆弱性の修正、その他のAI機能を活用し、たった数分以内に脆弱性への対応を開始する方法を解説していきます。実践的な例を通じて、AI搭載のアシスト機能を活用して効果的に脆弱性を分析し、説明するアプローチを習得しましょう。追加の修正として、AIが生成したコード修正がMR（マージリクエスト）に示され、脆弱性の修正を迅速化します。\n\n\n> [GitLab\nDuoの無料トライアル](https://about.gitlab.com/ja-jp/gitlab-duo/#free-trial)を始めて、脆弱性の修正機能を組織に取り入れてみませんか。\n\n\n## はじめ方：分析\n\n\n最初のステップは、脆弱性の影響と重大度を分析することです。GitLabのUIを開き、`セキュリティ > 脆弱性レポート`\nの順に進み、メニューから[Vulnerability\nReport（脆弱性レポート）](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)にアクセスします。脆弱性リストを\n`SAST` でフィルタリングし、対応を必要とする最も致命的な脆弱性を特定します。\n\n\n![脆弱性レポートの概要](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/vulnerability_reports_overview_aHR0cHM6_1750098116056.png)\n\n\nSASTのスキャン結果は詳細ビューで要約され、ソースコードへのリンクが表示されます。また、公開されているセキュリティアドバイザリからの詳細情報も提示されます。攻撃の範囲や技術的な詳細、脆弱な環境を十分に把握していない限り、デベロッパーがセキュリティレポートから分析を始めるのは難しい場合が多いでしょう。\n\n\n## 脆弱性の説明に基づく理解と軽減策\n\n\n脆弱性を理解し、最良かつ最も効率的な修正方法を知ることは不可欠です。また、修正により既存の機能に影響を与えないようにする必要があります。もし影響する場合は、保守担当者（メンテナー）やプロダクトオーナーとの議論が必要となり、その際には全体像を要約し、代替の軽減策を用意しなければなりません。また、離職した社員が作成したコードやテストを実施していないコードの場合、修正計画を立てるのがさらに難しくなることもあります。\n\n\nAI搭載の脆弱性の説明機能は、攻撃者がどのように脆弱性を悪用（エクスプロイト）できるかについて要約し、その影響や修正方法についての詳細な説明も行います。\n\n\n以下の例は、OSコマンドインジェクションの脆弱性を示しており、次のコードスニペットを使用しています。\n\n\n```php\n\n\u003C?php \n\n\n// Read variable name from GET request\n\n$name = $_GET['name'];\n\n\n// Use the variable name to call eval and print its value \n\neval('echo $' . $name . ';');\n\n```\n\n\n脆弱性レポートには詳細な説明がないため、全体の内容や影響について理解する必要があります。画面右上の `Explain\nVulnerability`（脆弱性の説明）オプションを選択すると、事前に定義されたプロンプトアクションでGitLab Duo\nChatが開きます。Chat内に脆弱性の追加の概要が表示され、脆弱性がどのように悪用されるかの説明や、推奨される修正方法が提示されます。\n\n\n![OSコマンドで使用される特殊文字の適切な無害化が行われていない（'OSコマンドインジェクション'）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750098116057.png)\n\n\n### 脆弱性の説明を文脈に沿った会話にする\n\n\n脆弱性の説明に関するUXの改善もされています。以前は、脆弱性の説明がオーバーレイとして右側に表示されていましたが、説明内容をGitLab Duo\nChatのワークフローに統合しました。脆弱性が複雑である場合は、それに対して複数の軽減ステップに分かれたり、ソースコードの経路が不明瞭になることもあります。\n\n\nソースコードツリーを参照しながら、同じChatの文脈でコードの説明、修正、リファクタリング、そしてテストを続けられます。\n\n\nC言語の例で全体的なワークフローに取り組んでみましょう。この例では、セキュリティスキャンによってバッファオーバーフローが検出されています。\n\n\n1. セキュリティの脆弱性の詳細ビューを開き、右上にある「Explain\nVulnerability」（脆弱性の説明）ボタンを選択します。Chatプロンプトが開き、問題の概要、潜在的な攻撃ベクター、および提案された修正が表示されます。\n\n\n![脆弱性のためのAI -\n画像4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750098116059.png)\n\n\n2. 提案された修正を確認し、続けて `Can you show an alternative fix using a different\nfunction` （日本語：別の関数を使った代替修正方法を見せてくれますか？）というプロンプトで、Chatに尋ねます。この目的は、`strcpy()`\nに代わるより安全な関数がないか調べることです。\n\n\n![脆弱性のためのAI -\n画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098116060.png)\n\n\n3. `strlcpy()`\nを使用した代替修正がChat内で提案されます（下図参照）。この関数は、ターゲット文字列に許容される文字数のみをコピーし、常に文字列をnullで終端します。また、ソース文字列の長さを返し、文字列が切り詰められたかどうかを判断します。\n\n\n![脆弱性のためのAI -\n画像5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750098116062.png)\n\n\n4. 次に、`Location file`\nURLをクリックし、ソースコードビューに移動します。再度Chatを開き、前の脆弱性の説明の文脈が保持されていることを確認します。次のステップでは、修正を続ける前にテストを追加していきます。これにより、機能の破損やリグレッションの発生を防ぐことができます。たとえば、`Based\non the vulnerability context and opened source code, how would you add tests\nfor it?` （日本語：脆弱性のコンテキストと表示されたソースコードに基づいて、テストを追加するにはどうしますか？）などのプロンプトを使用します。\n\n\n![脆弱性のためのAI -\n画像7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098116063.png)\n\n\n5. テストが生成され（仮に追加されたとして）、同じセッションで `Can you refactor the source code too?`\n（日本語：ソースコードもリファクタリングできますか？）というプロンプトを使用して、Chatにソースコードのリファクタリングも依頼できます。\n\n\n![脆弱性のためのAI -\n画像6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098116063.png)\n\n\nこのワークフローでは、脆弱性の分析、理解、軽減、代替アプローチの発見、テストの追加、さらには脆弱性の修正に対するリファクタリングを行う手順が示されています。\n\n\nChatを使ってこのプロセスを続けた後、Web\nIDEに切り替えて、学んだことを基にソースコードを修正できます。さらに、変更をコミットし、CI/CDやセキュリティスキャンをトリガーして、DevSecOpsライフサイクル全体のループを完結させる継続的なワークフローも含まれています。\n\n\n## AIアシストによる脆弱性の修正\n\n\nセキュリティ脆弱性を理解し、軽減するには、問題の修正を作成し、新しいマージリクエストでパイプラインを実行し、再度セキュリティスキャンを実施するなどのエンジニアリング作業が必要になります。また、修正をステージング（staging）環境にデプロイし、一定期間テストすることも必要な場合があります。\n\n\nAIを活用し、脆弱性とソースコードに基づいた提案修正を生成することで、脆弱性修正プロセスを迅速化します。\n\n\nヒント：これまでの経験の中で最も厄介だった脆弱性を思い出し、そのユースケースを再現してGitLab\nDuoの導入に活用してみましょう。ちなみに、[MITREのCWE Top\n25（最も危険なソフトウェアの脆弱性）](https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html)も、ユースケースとしてはよい例です。\n\n\n次の例は、[CWE-328：弱いハッシュ関数の使用](https://cwe.mitre.org/data/definitions/328.html)を実装したもので、`md5`\nを使用しています。これは[SASTスキャン](https://docs.gitlab.com/ee/user/application_security/sast/)によって正しく識別されます。\n\n\n```python\n\nimport hashlib\n\n\nclass User:\n    def __init__(self, username, password):\n        self.username = username\n        self.password = password\n\n    def set_password(self, password):\n        self.password = hashlib.md5(password.encode()).hexdigest()\n```\n\n\n![脆弱性のためのAI\n-画像8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750098116064.png)\n\n\n右上の `Resolve with merge\nrequest`（マージリクエストで解決）ボタンをクリックすると、AIを活用して修正を提案するMRが開きます。この脆弱性に対する修正として、別のハッシュ関数を使用することが考えられます。\n\n\n![脆弱性のためのAI -\n画像9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098116065.png)\n\n\nもうひとつの一般的な脆弱性の例として、関数のエラーコードや潜在的な例外をチェックしないケースがあります。以下のCコードスニペットは、`fopen()`\nや `chmod()`\nの呼び出しに対する[CWE-362](https://cwe.mitre.org/data/definitions/362.html)に関連するファイル操作におけるタイミング攻撃の例を実装しています。\n\n\n```c\n\n#include \u003Cstdio.h>\n\n#include \u003Cstring.h>\n\n#include \u003Csys/mman.h>\n\n#include \u003Csys/stat.h>\n\n#include \u003Cunistd.h>\n\n\nint main(int argc, char **argv) {##$_0A$####$_0A$##    // File\noperations##$_0A$##    char *fname = \"gitlab.keksi\";##$_0A$####$_0A$##   \nFILE *fp;##$_0A$##    fp = fopen(fname, \"r\");##$_0A$##    fprintf(fp, \"Hello\nfrom GitLab Duo Vulnerability Resolution Challenge\");##$_0A$##   \nfclose(fp);##$_0A$####$_0A$##    // Potential chmod() timing attacks   \n##$_0A$####$_0A$##    // Make the file world readable##$_0A$##   \nchmod(fname, S_IRWXU|S_IRWXG|S_IRWXO);##$_0A$####$_0A$##    return\n0;##$_0A$##}\n\n```\n\n\n`chmod()` に関するSASTレポートは、次のように表示される場合があります。\n\n\n![脆弱性のためのAI -\n画像10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098116065.png)\n\n\n提案された `chmod()`\nのマージリクエストにはエラーハンドリングが含まれており、ファイルが世界中で書き込み可能になる潜在的な問題も修正されて、権限が `777` から\n`600` に変更されています。\n\n\n![脆弱性のためのAI -\n画像11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098116066.png)\n\n\n> 次に`fopen()` 関数の脆弱性も特定し、分析した上で修正してみてください。\n\n ## GitLab DuoによるさらなるAI支援\n\nセキュリティ問題は、簡単な修正や回避策で解決できることがよくあり、それによって開発チームが長期的な解決策を議論し、計画する時間を確保できます。他のケースでは、問題がより複雑になり、適切な修正が本番環境に反映されるまで、機能[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)を無効にしたり、ファイアウォールでの軽減策が必要になることもあります。\n\n\nGitLab Duoは、こうした問題の解決に役立つAIを活用した追加機能を提供しています。\n\n\n**コードの説明**：デベロッパーやセキュリティエンジニアとして、行った変更に自信を持つことが重要です。IDE内で[コードの説明機能](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide)を使用することで、AIが提案した脆弱性修正をより深く理解できます。この機能により、どのような調整が行われたか、そしてその理由を正確に把握できます。\n\n\n**根本原因分析：**\n修正によりCI/CDパイプラインがエラーを起こしてしまった場合、[根本原因分析機能](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)を利用できます。このツールは、根本的な問題を特定し、説明するのに役立ち、効果的に問題に対処できます。必要な修正を加えた後、テストを再実行して問題が解決したか確認できます。\n\n\n**リファクタリング**：脆弱性の修正が済んでも、より安全なコードにできないか検討する価値があります。IDE内でGitLab Duo\nChatを開き、[リファクタリング機能](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide)を使用して、コードをより安全に書くための代替方法を探ることができます。この事前対策的なアプローチにより、堅牢でセキュアなコードベースを維持できます。\n\n\nこれらのGitLab Duoの機能を活用することで、脆弱性に自信を持って対処し、コードのセキュリティと効率を確保できます。\n\n\n## 今後の取り組み\n\n\n脆弱性の説明と修正の機能をMRのプロセスに直接組み込むことで、シフトレフト（より早い段階に移行）させることを計画しています。この統合により、開発サイクルの初期段階で脆弱性に対処し、解決できるようになり、ワークフローが効率化され、シフトレフトによりコードのセキュリティが強化された状態になります。\n\n\n## GitLab Duoを始める\n\n\nGitLab\nUltimateで利用可能な機能を有効化する方法を説明する[ドキュメント](https://docs.gitlab.com/ee/user/gitlab_duo/turn_on_off.html)をご参照ください。また、GitLab\nDuoの[脆弱性の説明](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#explaining-a-vulnerability)および[脆弱性の修正](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution)は、GitLabのSelf-Managed環境やGitLab\nDedicatedでも利用可能です。\n\n\n[「GitLab\nDuo開発の現場から」ブログシリーズ](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-series/)をチェックすることで、GitLab\nDuoの最新情報についてご確認いただけます。\n\n\n*監修：伊藤 俊廷 [@toshitakaito](https://gitlab.com/toshitakaito) \u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト）*\n\n\n> [GitLab\nDuoの無料トライアル](https://about.gitlab.com/ja-jp/gitlab-duo/#free-trial)を始めて、脆弱性の修正機能を組織に取り入れてみませんか。\n",[675,9,730,679,680],"product","2025-01-21",{"slug":733,"featured":90,"template":683},"developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","content:ja-jp:blog:developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","Developing Gitlab Duo Use Ai To Remediate Security Vulnerabilities","ja-jp/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","ja-jp/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"_path":739,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":740,"content":746,"config":753,"_id":755,"_type":13,"title":756,"_source":15,"_file":757,"_stem":758,"_extension":18},"/ja-jp/blog/enhance-application-security-with-gitlab-hackerone",{"title":741,"description":742,"ogTitle":741,"ogDescription":742,"noIndex":6,"ogImage":743,"ogUrl":744,"ogSiteName":696,"ogType":697,"canonicalUrls":744,"schema":745},"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":741,"description":742,"authors":747,"heroImage":743,"date":749,"body":750,"category":9,"tags":751},[748],"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/security-compliance/)  \n\n*\n[HackerOne社は、GitLabにビルトインされたセキュリティにより、デプロイ速度を5倍まで高めることに成功](https://about.gitlab.com/ja-jp/customers/hackerone/)  \n\n*\n[GitLabアプリケーションセキュリティドキュメント](https://docs.gitlab.com/ee/user/application_security/)\n",[9,680,233,284,706,678,752],"bug bounty",{"slug":754,"featured":6,"template":683},"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":760,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":761,"content":766,"config":775,"_id":777,"_type":13,"title":778,"_source":15,"_file":779,"_stem":780,"_extension":18},"/ja-jp/blog/event-report-aws-summit-2025",{"config":762,"ogImage":763,"title":764,"description":765},{"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":767,"description":768,"authors":769,"date":770,"body":771,"category":772,"heroImage":763,"tags":773},"GitLab with Amazon Qで開発スピードを高め、AI生成コードの品質を担保する【イベントレポート】","この記事ではAWS Summit Japan 2025に出展した際に「GitLab with Amazon Q」について語ったセッションの模様をお伝えします。",[701],"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のキーホルダー*","devsecops",[774,675,676,677,707,678,279,9,708],"AWS",{"featured":90,"template":683,"slug":776},"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":782,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":783,"content":789,"config":795,"_id":797,"_type":13,"title":798,"_source":15,"_file":799,"_stem":800,"_extension":18},"/ja-jp/blog/event-report-gartner-application-innovation-2025",{"config":784,"ogImage":785,"title":786,"description":787,"ogDescription":788},{"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":786,"description":790,"heroImage":785,"date":791,"body":792,"category":772,"tags":793,"authors":794},"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*イベントで配られたノベルティ*",[707,675,677,678,279,551,9,708],[701],{"featured":90,"template":683,"slug":796},"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":802,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":803,"content":809,"config":814,"_id":816,"_type":13,"title":817,"_source":15,"_file":818,"_stem":819,"_extension":18},"/ja-jp/blog/event-report-gartner-it-infra-2024",{"title":804,"description":805,"ogTitle":804,"ogDescription":805,"noIndex":6,"ogImage":806,"ogUrl":807,"ogSiteName":696,"ogType":697,"canonicalUrls":807,"schema":808},"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":804,"description":805,"authors":810,"heroImage":806,"date":811,"body":812,"category":772,"tags":813},[701],"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/)",[678,9,279],{"slug":815,"featured":90,"template":683},"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":821,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":822,"content":826,"config":832,"_id":834,"_type":13,"title":835,"_source":15,"_file":836,"_stem":837,"_extension":18},"/ja-jp/blog/event-report-gartner-security-risk-management-2025",{"noIndex":6,"title":823,"ogTitle":823,"description":824,"ogImage":825},"コード生成AIのリスク管理とポテンシャル最大化【レポート】","ガートナー セキュリティ＆リスク・マネジメントサミット2025で登壇したGitLab吉瀬 淳一のセッション内容をレポート。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757480526/wk05yajf5e4bmwuygve7.jpg",{"date":827,"authors":828,"title":829,"description":824,"heroImage":825,"category":772,"tags":830,"body":831},"2025-09-10",[701],"コード生成AIのリスクを管理し、ポテンシャルを最大限に引き出す【イベントレポート】",[675,676,678,279,9],"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":90,"template":683,"slug":833},"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":839,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":840,"content":846,"config":853,"_id":855,"_type":13,"title":856,"_source":15,"_file":857,"_stem":858,"_extension":18},"/ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"title":841,"description":842,"ogTitle":841,"ogDescription":842,"noIndex":6,"ogImage":843,"ogUrl":844,"ogSiteName":696,"ogType":697,"canonicalUrls":844,"schema":845},"金融サービス業界向け：GitLabの職務分離機能を実装する方法","金融サービス業界において、GitLabの職務分離機能を活用して安全でコンプライアンスに準拠したソフトウェア開発を実現する方法をご説明します。また、規制フレームワークの遵守を支援する機能も併せてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png","https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"金融サービス業界向け：GitLabの職務分離機能を実装する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cherry Han\"},{\"@type\":\"Person\",\"name\":\"Gavin Peltz\"}],\n        \"datePublished\": \"2024-08-13\",\n      }",{"title":841,"description":842,"authors":847,"heroImage":843,"date":850,"body":851,"category":9,"tags":852},[848,849],"Cherry Han","Gavin Peltz","2024-08-13","ソフトウェア開発の過程において、特に金融サービスのようなデータの完全性や規制の遵守が不可欠な業界では、強固なセキュリティとコンプライアンス対策が求められます。これらの基準を維持する上で重要な要素の1つが職務分離（SoD）です。SoDは、プロセス全体の管理を1人に割り当てないようにすることで、エラーや不正行為のリスクを軽減するアプローチです。SoDにより、ソフトウェア開発プロセスの完全性を損なう可能性のある外部からの悪意ある行為を防ぎ、ソフトウェアサプライチェーンにおけるリスクを軽減できます。\n\n## 金融サービス業界におけるSoDの重要性\n\n金融サービス業界では、SoDが機密情報の保護やコンプライアンス遵守の確保を実現する上で重要な役割を果たします。SoDは、金融サービス業界において戦略的に以下のようなメリットをがあります。\n\n* **リスク軽減**：職務を複数の役割に分担することで、システムの完全性や規制コンプライアンスの遵守を損なう可能性のあるエラー、不正行為、無許可のアクティビティのリスクを軽減します。\n* **責任の強化**：明確な職務分担により、1人の担当者がプロセス全体を一貫して管理することができなくなり、結果として透明性と責任意識が高まります。透明性と責任意識は、ステークホルダーや規制当局との信頼関係を維持する上で不可欠です。\n* **規制コンプライアンス**：SoDは、機密性の高い業務が監視と審査の下で行われることを保証する目的で、金融規制によって義務付けられています。これらの基準を遵守することで、ペナルティを回避できるだけでなく、組織の評判も保護されます。\n* **運用の強靭性**：意思決定と実行を分散することで、組織は人的ミスや悪意ある行為、および予期せぬ出来事によってもたらされる混乱の影響を受けにくくなります。\n\n## GitLabによる職務分離とベストプラクティス\nGitLabでは、DevSecOpsワークフロー全体を対象としたエンドツーエンドの職務分離機能を使用できます。\n\n![金融サービスのSoD - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\n上記の図は、SoDの原則を維持するために、マージリクエスト承認ポリシー、保護機能、ユーザー権限、コンプライアンスフレームワーク、監査イベントといった重要な要素がどのように統合され、連携しているかを示しています。各要素については、後続のセクションで安全かつコンプライアンスに準拠した開発環境の構築方法を解説する中で、詳述します。\n\n### マージリクエスト承認ポリシー\n\n金融サービス業界が直面する課題のひとつに、不正またはチェックされていない変更が統合されるのを防ぐ承認メカニズムの実装があります。ここで役立つのが[マージリクエスト承認ポリシー](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html)です。このポリシーにより、セキュリティと開発の職務分離が強制され、デベロッパーが脆弱性を含むコード変更を自分で承認したり、開発チームが適切な監視なしにコードを本番環境に直接デプロイしたりすることを防止できます。\n\nポリシーを作成する際には、承認者として誰が適切であるかを検討することをおすすめします。承認者には、個人ユーザー、アプリケーションセキュリティチームなどのグループ、あるいはメンテナーといったロールタイプを指定できます。さらに制約を加えたい場合は、以下の主要なポリシー機能の使用をご検討ください。\n\n- 作成者による承認を防止：このポリシーにより、マージリクエストの作成者が自身の変更を承認できないようガードレールが設定されます。独立したレビューを求めることで、承認プロセスの客観性と公平性が維持されます。\n\n- コミットを追加したユーザーによる承認を防ぐ：マージリクエストにコミットを追加したユーザーも、承認を行うことができないようにします。これにより、変更に直接関わっていないチームメンバーによって検証が行われる、独立したレビューの原則がさらに強化されます。\n\n- 承認ルールの編集を防止：承認プロセスの整合性を維持するため、GitLabではプロジェクトやマージリクエストレベルで承認ルールの編集を管理者が禁止できます。これにより、一度定義された承認ポリシーが無断で変更されたり回避されたりしないよう保証されます。\n\n- 承認にユーザーパスワードを要求：追加のセキュリティ対策として、GitLabではマージリクエストを承認するユーザーに対して、パスワードの入力を求めることができます。\n\n職務分離を明確に維持するため、マージリクエスト承認ポリシーを含むセキュリティポリシーを格納するための専用の[トップレベルグループを別途作成](https://docs.gitlab.com/ee/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance)することが推奨されます。この設定により、権限を継承するユーザーの数が最小限に抑えられ、ポリシー管理を厳格に制御できます。この専用グループから、目標に合う最上位グループレベルで[セキュリティポリシープロジェクトをリンク](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project)することで、ポリシー管理の手間を軽減し、開発環境全体で包括的なカバレッジを確保できます。\n\nまた、ポリシーがデフォルトで有効になっている場合、そのポリシーは関連するリンクされたグループ、サブグループ、および個別のプロジェクト内のすべてのプロジェクトに適用されることにも注意してください。より対象を絞ってポリシーを適用したい場合、GitLabは[コンプライアンスフレームワークラベル](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html)を使用してポリシーの適用範囲を絞り込むことを推奨しています。厳格な規制に対応しているお客様の多くは、「SOX」や「PCI」などの規制要件に対応するコンプライアンスラベルを作成しています。また、このフレームワークへのリンクにより、[ネイティブコンプライアンスセンター](https://docs.gitlab.com/ee/user/compliance/compliance_center/)でさまざまなユースケースに合わせたセキュリティポリシーを管理できるようになります。\n\n### コンプライアンスフレームワークと制御\n\n規制対象の業界に属するお客様は、大規模な組織においてコンプライアンスを維持する上で大きな課題に直面しています。手動のプロセスはエラーが生じやすく、チーム間でポリシーを一貫して適用し続けることが難しい場合もあります。\n\nGitLabのコンプライアンスフレームワークを使用することで、組織は予防措置の自動化と管理、リスクの体系的な管理、そして規制コンプライアンスのシームレスな適用を実現できます。これらのフレームワークによって、どのようなパイプラインでもセキュリティプロトコルやカスタムジョブを実施できます。\n\nコンプライアンス設定を組織レベルで保護するために、GitLabではグループまたはプロジェクトのオーナーのみがコンプライアンスフレームワークを追加または削除できるようになっています。この対策により、適切な権限レベルを持たない開発チームやマネージャーによるコンプライアンス設定の変更が防止され、セキュリティがさらに強化されます。なお、メンテナー権限を持つ個人がサブグループを作成できる場合、そのサブグループのオーナーとなりコンプライアンスフレームワークを変更できる点に注意してください。これを防ぐには、権限とグループの設定で[サブグループの作成者](https://docs.gitlab.com/ee/user/group/subgroups/#change-who-can-create-subgroups)を制限してください。\n\n## SoDのための権限とロール\n\n金融サービス業界で職務分離を効果的に実施するには、明確かつ正確なアクセス制御の設定が不可欠です。GitLabには、あらかじめ定義されたロール（ゲスト、レポーター、デベロッパー、メンテナー、オーナーなど）による階層的な[権限モデル](https://docs.gitlab.com/ee/user/permissions.html)が備わっています。各ロールには特定の権限セットが割り当てられており、個人が業務を遂行する際に自身の権限の範囲を逸脱しないようになっています。これにより、利益相反やセキュリティリスクを抑えられます。GitLabでは[最小権限の原則](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)に従ってロールを割り当てることを推奨しています。\n\n細かいニーズを持つ組織、特にGitLab Ultimateを使用している組織では、[カスタムロール](https://docs.gitlab.com/ee/user/custom_roles.html)を活用することで、さらに柔軟な対応が可能になります。これらのロールを使用することで、各組織の独自のワークフローやコンプライアンス要件に合わせた特定の権限を設定できます。担当者が相反するタスクを実行できなくなるため、SoDの強制に特に役立ちます。\n\n一般的なユースケースとして、デプロイロールが必要な場合があります。これは、デプロイの権限が必要な個人に対して、コードの編集やプッシュの権限は与えたくない場合に使用できます。こういった要件に対応するために、GitLabは[保護環境](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments)を提供しています。保護環境を使用すると、[ジョブのデプロイ承認を受けたグループを招待](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#deployment-only-access-to-protected-environments)し、ユーザーのロールをレポーターに限定できます。なお、デプロイジョブにはenvironmentキーワードを含める必要があります。この設定により、コードの編集権限がないユーザーがデプロイを実行できるようになり、コンプライアンス要件に準拠できます。\n\n組織においてロールと権限を慎重に定義し適用することで、安全かつコンプライアンスに準拠した開発環境を構築できます。ユーザー権限を広範に見直したい場合、[こちらのグループメンバーレポート](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report)を使用して各ロールのメンバー数を確認し、それに応じた次のステップを検討することが可能です。\n\n## 保護機能\nGitLabは、開発プロセスをより厳重にかんりできるようにするために「保護」機能を提供しています。これらの機能は、指定された担当者のみが重要な変更を行えるようにするために使用でき、SoDを維持するためには不可欠です。\n\n- 保護ブランチ：保護ブランチでは、誰がプッシュ、マージ、または強制プッシュを実行できるかが制限されます。権限を持つユーザーのみが変更を加えられるように制御でき、特に「main」や「production」のようなブランチで効果的です。\n- 保護Gitタグ：このタグを使用すると、タグの作成権限を持つユーザーを制御できます。タグの作成後に誤った更新や削除が発生しないよう防止され、バージョン管理の整合性が保たれます。\n- 保護環境：特定の環境、特に本番環境への無許可のアクセスを防ぐことは必須事項と言えます。保護環境では、適切な権限を持つユーザーのみがデプロイできるため、意図しない変更から環境を保護できます。これは前述のデプロイロール機能と関連しており、コードを編集せずにジョブをデプロイできるようになるため、コンプライアンスとセキュリティを確保できます。\n- 保護パッケージ：パッケージ保護ルールを使用することで、どのユーザーがパッケージに変更を加えられるかを制限できます。\nこれらの保護機能はすべて、SoDの原則に沿った安全でコンプライアンスに準拠した開発環境の維持に役立ちます。\n\n## 監査イベントとコンプライアンスセンター\nここまで承認ポリシー、コンプライアンスフレームワーク、ロール、保護機能について説明してきましたが、最後に、GitLabでこれらの実装をどのようにモニタリングおよび監査してコンプライアンスを遵守できるかについて解説します。GitLabの[監査イベント](https://docs.gitlab.com/ee/user/compliance/audit_events.html)では、ユーザーの活動やプロジェクトの変更など、オーナーや管理者向けに詳細なアクティビティ履歴を提供します。このログは、ユーザーアクションを追跡したり、無許可のアクティビティを検出したりする上で不可欠です。組織において[監査イベントストリーミング](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html)を使用して監査イベントを外部システムにストリーミングすることで、リアルタイムでの分析やアラートが可能になります。これにより、改変や違反が検出され、迅速に修正できるようになります。\n\n[GitLabのコンプライアンスセンター](https://docs.gitlab.com/ee/user/compliance/compliance_center/)は、コンプライアンスに関連するアクティビティを一元的に管理およびモニタリングできる場所です。ここではプロジェクトやグループ全体のコンプライアンス状況の概要を確認でき、マージリクエスト承認ルールやその他のポリシーの違反が強調表示されます。管理者は問題に迅速に対処し、あらかじめ定義されたコンプライアンス基準への準拠を確認できます。この一元化されたアプローチにより、コンプライアンス管理が簡素化され、高度なレベルでモニタリングと制御を行えます。\n\n> GitLabのSoDやコンプライアンスに関する考え方について詳しく知りたい方は、[Governステージに関するGitLabの製品方針](https://about.gitlab.com/direction/govern/) と[GitLabのコンプライアンスドキュメント](https://docs.gitlab.com/ee/administration/compliance.html)をご覧ください。\n\n## その他のリソース\n\n- [GitLabのコンプライアンスとセキュリティポリシー管理で規制基準を遵守](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [GitLabを使ったGitLabの構築：セキュリティ認証ポートフォリオを拡充](https://about.gitlab.com/blog/building-gitlab-with-gitlab-expanding-our-security-certification-portfolio/)\n- [オンライン小売業者bol社、GitLabで拡大するコンプライアンスニーズに対応](https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab/)",[9,706,730,551],{"slug":854,"featured":6,"template":683},"finserv-how-to-implement-gitlabs-separation-of-duties-features","content:ja-jp:blog:finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","Finserv How To Implement Gitlabs Separation Of Duties Features","ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"_path":860,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":861,"content":865,"config":872,"_id":874,"_type":13,"title":875,"_source":15,"_file":876,"_stem":877,"_extension":18},"/ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering",{"config":862,"title":863,"description":864},{"noIndex":6},"GitLab 18.3: ソフトウェアエンジニアリングにおけるAIオーケストレーションの拡張","強化されたフロー、エンタープライズガバナンス、シームレスなツール統合により、人間とAIのコラボレーションを進化させる方法をご紹介します。",{"heroImage":866,"body":867,"authors":868,"updatedDate":791,"date":870,"title":863,"tags":871,"description":864,"category":667},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1755711502/wuuadis1pza3zehqohcc.png","GitLabは現在、ソフトウェアライフサイクルのあらゆる段階を統合する包括的なDevSecOpsプラットフォームです。その基盤の上に、世界初のソフトウェアエンジニアリング向けAIネイティブプラットフォームへの進化を進めています。GitLabでは、ソフトウェアエンジニアリングの未来は本質的に人間とAIのコラボレーションにあると考えており、すべてのGitLabユーザーに最高のAI機能を提供したいと考えています。\n\nこの変革は、他のAI開発ツールが行っていることを超えた3つの異なるレイヤーで起こっています：\n\n![以下に示すAIネイティブ変革のスライド](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755762266/iwuugge3cxweiyvi0yjk.png)\n\n**第一に、記録システムです。** 統合データプラットフォームは、最も価値のあるデジタル資産を保持しています。これには、ソースコードと知的財産だけでなく、プロジェクト計画、バグバックログ、CI/CD構成、デプロイメント履歴、セキュリティレポート、コンプライアンスデータにまたがる豊富な非構造化データが含まれます。これにより、GitLab環境内に安全に保持され、汎用エージェントや大規模言語モデルでは利用できない、文脈データの宝庫が作成されます。\n\n**第二に、ソフトウェアコントロールプレーンとして機能します。** Gitリポジトリ、REST API、およびエンドツーエンドのソフトウェアデリバリーを支えるWebhookベースのインターフェースを通じて、最も重要なビジネスプロセスをオーケストレーションします。多くの顧客は、これを重要なビジネスプロセスが日常的に依存するティア0の依存関係として考えています。\n\n**第三に、強力なユーザーエクスペリエンスを提供します。** ほとんどのエンジニアリングチームの速度を低下させる負荷の高い頭の切り替えを排除するのに役立つ統合インターフェースを提供します。1つのプラットフォームで完全なライフサイクルの可視性とコラボレーションツールを提供することで、5,000万人以上の登録ユーザーと広大なコミュニティが、仕事を成し遂げるためにGitLabを活用しています。この専門知識により、GitLabは、既存の信頼できるワークフローを維持しながら、チームの生産性を増幅する直感的な人間とAIのコラボレーションを先駆的に開拓する独自の立場にあります。\n\n**あらゆるレイヤーにAIをネイティブに統合してプラットフォームを拡張**\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo/agent-platform/)は、これら3つのレイヤーすべてを統合し、拡張します。拡張性と相互運用性のために設計されており、顧客やパートナーがさらに価値を創造するソリューションを構築できるようにします。オープンプラットフォームアプローチは、3つのレイヤーすべてで既存のスタックに深く統合されながら、外部AIツールやシステムとのシームレスな接続性を重視しています。\n\n* まず、**ナレッジグラフ**で統合データプラットフォームを拡張しています。これは、コードと他のすべての非構造化データをインデックス化して結び付け、エージェントアクセスに特化して最適化されたものです。AIはコンテキストで成長し、これによりエージェントによる推論と推論を加速するだけでなく、より低コストで高品質なエージェントの成果を提供できると考えています。\n* 第二に、既存のコントロールプレーンに重要な**オーケストレーションレイヤー**を3つの異なる部分で追加しています：エージェントとフローがGitLab SDLCイベントのサブスクライバーとして登録できるようにし、目的別のマルチエージェントフローを可能にする新しいオーケストレーションエンジンを構築し、比類のない相互運用性のためにMCPと標準プロトコルを介してGitLabツール、エージェント、フローを公開します。\n* 最後に、ソフトウェア開発ライフサイクル全体にわたってファーストクラスのエージェントとエージェントフローを提供するために**GitLabエクスペリエンス**を拡張しています。エージェントに非同期タスクを割り当て、コメントで@メンションし、ワークフローに固有のコンテキストでカスタムエージェントを作成できるようになります。さらに重要なことに、GitLabは、サードパーティエージェントの豊富なエコシステムのロックを解除しながら、開発のあらゆる段階でネイティブエージェントを出荷しています。これにより、エージェントが人間のチームメイトと同じように自然に作業できる真の人間とAIのコラボレーションが生まれます。\n\nこのビデオで18.3以降の新機能をご覧いただくか、以下をお読みください。\n\n\u003Cdiv style=\"padding:75% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111796316?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab_18.3 Release_081925_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLab 18.3の新機能\n\n18.2では、ソフトウェア開発ライフサイクル全体でデベロッパーと協力する専門的な[AIエージェント](https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-public-beta/#%E3%81%99%E3%81%90%E3%81%AB%E4%BD%BF%E3%81%88%E3%82%8B%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88)と、ソフトウェア開発フローを導入しました。これは、複数のエージェントをオーケストレーションして、エンドツーエンドでコード変更を計画、実装、テストする強力な機能です。\n\nGitLab 18.3では、拡張された統合と相互運用性、より多くのフロー、そしてソフトウェア開発ライフサイクル全体でのコンテキスト認識の強化を導入しています。\n\n### 拡張された統合と相互運用性\n\nファーストパーティのGitLabエージェントとサードパーティエージェントの豊富なエコシステムの両方を通じて、包括的なAI拡張性を提供しており、すべてがプロジェクトコンテキストとデータへの完全なアクセスを持っています。このアプローチは、これらのエージェントとGitLabのコアプラットフォーム間の高度に統合されたオーケストレーションを通じて好みのツールを選択する柔軟性を提供しながら、ネイティブのGitLabワークフローとガバナンスを維持します。チームは、主要な統合、監視、ユーザーエクスペリエンスの利点を維持しながら、強化されたAI機能を獲得します。\n\n* **MCPサーバー - ユニバーサルAI統合：** GitLabのMCP（[モデルコンテキストプロトコル](https://about.gitlab.com/topics/ai/model-context-protocol/)）サーバーにより、AIシステムはGitLabプロジェクトと開発プロセスに直接安全に統合できます。この標準化されたインターフェースにより、カスタム統合のオーバーヘッドが排除され、[Cursor](https://docs.cursor.com/en/tools/mcp)を含むAIツールが既存のGitLab環境内でインテリジェントに動作できるようになります。18.3に含まれるツールの完全なリストについては、[ドキュメント](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/)をご覧ください。**これは始まりに過ぎません。18.4では追加のツールが計画されています。**\n\n  **注：** サードパーティエージェントは、GitLab Premiumベータ機能であり、GitLab Duo Enterpriseの顧客が評価のためにのみ利用できます。\n\n> *「GitLabワークフローをCursorに直接持ち込むことは、デベロッパーの摩擦を減らすための重要なステップです。頭の切り替えの必要性を最小限に抑えることで、チームはコーディング環境を離れることなく、イシューのステータスをチェックし、マージリクエストをレビューし、パイプラインの結果を監視できます。この統合は共有顧客にとって自然な選択であり、デベロッパーの生産性を継続的に向上させるために、GitLabとの長期的なパートナーシップを楽しみにしています。」*\n>\n> \\- **Ricky Doar、Cursor フィールドエンジニアリング副社長**\n>\n> *「GitLabのMCPサーバーとCLIエージェントサポートは、Amazon Qが開発ワークフローと統合するための強力な新しい方法を作成します。Amazon Q DeveloperはGitLabのリモートMCPインターフェースを介して直接接続できるようになり、チームはイシューやマージリクエストでAmazon Q CLIを@メンションするだけで開発タスクを委任できます。これらの統合に組み込まれた堅牢なセキュリティとガバナンス機能により、企業は開発標準を維持しながら、AIコーディングツールを活用する自信を得ることができます。GitLabとのパートナーシップは、AIエコシステムを拡大し、デベロッパーが作業する場所でインテリジェントな開発ツールにアクセスできるようにするというAWSの継続的なコミットメントを示しています。」*\n>\n> \\- **Deepak Singh、AWS デベロッパーエージェントおよびエクスペリエンス担当副社長**\n\n* **Claude Code、Codex、Amazon Q、Google Gemini、opencode（独自のキーを持参）のCLIエージェントサポート：** 18.3では、イシューやマージリクエストでエージェントを直接@メンションすることで、チームが日常的な開発作業を委任できる統合を導入しています。デベロッパーがこれらのAIアシスタントにメンションすると、周囲のコンテキストとリポジトリコードを自動的に読み取り、レビュー可能なコード変更またはインラインコメントでユーザーのコメントに応答します。これらの統合では、それぞれのAIプロバイダー用に独自のAPIキーを持参する必要があり、適切な権限と監査証跡を維持しながら、すべてのやり取りをGitLabのインターフェース内でネイティブに保持します。\n\n  **注：** サードパーティエージェントは、GitLab Premiumベータ機能であり、GitLab Duo Enterpriseの顧客が評価のためにのみ利用できます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111784124?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Third Party Agents Flows Claude Code\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> *「Claude CodeをGitLabに直接持ち込むことで、何百万人ものデベロッパーがすでに毎日コラボレーションしてコードを出荷している場所にAIアシスタンスを配置します。イシューやマージリクエストでClaudeを直接メンションする機能により、人間の監視とレビュープロセスで品質を維持しながら、摩擦が除去されます。このアップデートにより、Claude Codeの機能がチームが作業するより多くの場所に提供され、AIをデベロッパーワークフローの自然な一部にします。」*\n>\n> **\\- Cat Wu、Claude Code プロダクトリード、Anthropic**\n>\n> *「GitLab 18.3の新しいエージェント統合により、既存のワークフロー内でopencodeを使用できます。イシューやマージリクエストでopencodeを@メンションすると、CIパイプラインでエージェントが実行されます。この方法でopencodeを設定して実行する機能は、オープンソースコミュニティが本当に評価する統合のタイプです。」*\n>\n> **\\- Jay V.、CEO、opencode**\n\n* **すべてのPremiumおよびUltimate顧客が利用できるVisual Studio IDEおよびGitLab UIのエージェントチャットサポート：** 18.3では、GitLabの完全な開発ライフサイクルデータにアクセスするためにツール間で頭の切り替えをする必要がなくなりました。強化された統合により、GitLab DuoのフルパワーがGitLab UIとIDEにもたらされ、JetBrainsとVS Codeからのサポートが拡張され、現在はVisual Studioも含まれています。これにより、デベロッパーは好みの環境内で豊富なプロジェクトコンテキスト、デプロイメント履歴、チームコラボレーションデータに直接アクセスしながら、フローに留まることができます。\n* **拡張されたAIモデルサポート：** GitLab Duo Self-Hostedは追加のAIモデルをサポートするようになり、チームにAI支援開発ワークフローでより柔軟性を提供します。データセンターのハードウェア上でvLLMを介して、またはプライベートクラウドのAzure OpenAIやAWS Bedrockなどのクラウドサービスを介して、オープンソースのOpenAI GPTモデル（20Bおよび120Bパラメータ）をデプロイできるようになりました。さらに、AnthropicのClaude 4はAWS Bedrockで利用可能です。\n\n### 新しい自動開発フロー\n\nGitLabのフローは、複数のAIエージェントを事前構築された指示で調整し、時間のかかる日常的なタスクを自律的に処理するため、デベロッパーは最も重要な作業に集中できます。\n\nGitLab 18.3には2つの新しいフローが付属しています：\n\n* **概念から完成まで数分でコードを自動生成するイシューからMRへのフロー：** このFlowは、要件を分析し、包括的な実装計画を準備し、レビュー可能な本番グレードのコードを生成するためにエージェントを調整することにより、イシューを実行可能なマージリクエスト（MR）に自動的に変換します。アイデアを数時間ではなく数分でレビュー可能な実装に変えるのに役立ちます。\n\n\u003Cdiv style=\"padding:75% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111782058?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Issue to MR\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **シームレスな移行インテリジェンスのために構築されたCI File変換フロー：** CI File変換フローは、エージェントが既存のCI/CD構成を分析し、完全なパイプライン互換性を持つGitLab CI形式にインテリジェントに変換することで、移行ワークフローを合理化します。これにより、CI構成をゼロから書き直す手動作業と潜在的なエラーが排除され、チームは自信を持ってデプロイメントパイプライン全体を移行できます。18.3にはJenkins移行のサポートが含まれています。将来のリリースでは追加サポートが計画されています。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783724?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Convert to CI Flow\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### インテリジェントなコードと検索\n\nAIポイントソリューションは通常、分離されたコードスニペットへの限定的な可視性で動作しますが、GitLabのナレッジグラフは、より迅速でインテリジェントな応答を通知するための環境コンテキストをエージェントに提供します。\n\n* **リアルタイムコードインテリジェンスのためのナレッジグラフ：** 18.3では、GitLabのナレッジグラフがリアルタイムコードインデックスを提供し、より高速なコード検索を可能にし、より正確で文脈に沿った結果を提供します。コードベース全体にわたるファイル、依存関係、開発パターン間の関係を理解することにより、エージェントは人間のデベロッパーが発見するのに何時間もかかる洞察を提供するように設計されています。**これは、ナレッジグラフに計画されている強力な機能のロックを解除する最初のステップにすぎません。**\n\n### エンタープライズガバナンス\n\nAIの透明性と組織のコントロールは、チームがAI搭載開発ツールを完全に採用することを妨げる可能性のある重要な課題であり、[85%の経営幹部が、エージェント型AIが前例のないセキュリティ課題を生み出すことに同意しています](https://about.gitlab.com/software-innovation-report/)。\n\n18.3のこれらの新機能は、データガバナンス、コンプライアンス要件、AI意思決定プロセスへの可視性の必要性に関する懸念に対処するのに役立つため、組織は既存のセキュリティとポリシーフレームワーク内でAIを統合できます。\n\n* **インテリジェンスを通じた透明性のためのエージェントインサイト：** 組み込みのエージェント追跡により、エージェントの意思決定プロセスへの可視性が提供されます。ユーザーは、透明なアクティビティ追跡を通じてワークフローを最適化し、ベストプラクティスに従うことができます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783244?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agent Insights\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **Self-Hosted向けGitLab Duoコードレビュー：** これにより、厳格なデータガバナンス要件を持つ組織にGitLab Duoのインテリジェンスがもたらされ、チームが機密性の高いコードを管理された環境に保持できるようになります。\n* **柔軟なAIデプロイメントのためのハイブリッドモデル構成：** GitLab Duo Self-Hostedをご利用のお客様は、ローカルAIゲートウェイを介したセルフホステッドAIモデルとGitLabのAIゲートウェイを介したGitLabのクラウドモデルを組み合わせたハイブリッドモデル構成を使用できるようになり、さまざまな機能へのアクセスが可能になりました。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783569?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Self Hosted Models Code Review\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **OAuthサポートによるセキュリティの強化：** MCPサーバーには、完全なOAuth 2.0認証サポートが含まれるようになり、保護されたリソースと機密性の高い開発環境への安全な接続が可能になりました。この実装は、MCPのドラフトOAuth仕様に従い、認証フロー、トークン管理、動的クライアント登録を処理します。\n\n### Secure by Designプラットフォーム：スケールするガバナンス\n\n真のプラットフォームセキュリティには、開発ライフサイクルのあらゆるレイヤーにわたるガバナンス原則の一貫した適用が必要です。AI採用を安全にするのと同じセキュリティの基本（最小権限アクセス、一元化されたポリシー管理、プロアクティブな監視、きめ細かい権限）は、凝集性のある多層防御アプローチを作成するために、SDLC全体に組み込まれる必要があります。\n\nGitLab 18.3は、これらの新しいアップデートでソフトウェアサプライチェーン全体を保護するのに役立つ基盤的なコントロールを強化します：\n\n* **カスタム管理者ロール：** ブランケット管理アクセスを正確な最小権限コントロールに置き換える、きめ細かく目的に合わせた管理権限を提供します。セキュリティリスクを生み出すブランケット管理権限を付与する代わりに、組織は特定の機能に合わせたカスタマイズされたロールを作成できるようになりました。ランナーと監視を管理するプラットフォームチーム、ユーザー管理を処理するサポートチーム、ダッシュボードと使用統計にアクセスするリーダーシップなど。UIとAPIを介した完全なロールライフサイクル管理、監査ログ、自動生成されたドキュメントにより、この機能は運用効率を維持し、全体的なインスタンスセキュリティを向上させながら、真の最小権限管理を可能にします。\n* **インスタンスレベルのコンプライアンスフレームワークとセキュリティポリシー管理：** 組織は、標準化されたフレームワークとセキュリティポリシーをトップレベルグループに直接適用する権限を持つ専用のコンプライアンスグループを指定でき、すべてのサブグループとプロジェクトに自動的にカスケード適用されます。この一元化されたアプローチは、追加のローカルポリシーに対するグループの自律性を維持しながら、断片化されたポリシー管理のコンプライアンス採用ブロッカーを排除します。\n* **強化された違反レポート：** チームは、MR承認ルールに対して不正な変更が行われたとき、フレームワークポリシーに適切な承認がないとき、または時間ベースのコンプライアンスコントロールが違反されたときに、即座に通知を受け取るようになりました。違反を特定のコンプライアンスフレームワークコントロールに直接リンクすることで、チームはどの要件が違反されたかを正確に伝える実用的な洞察を得て、コンプライアンスを反応的なチェックボックスの演習から、開発とセキュリティワークフローのプロアクティブで統合された部分に変えます。\n* **CI/CDジョブトークンのきめ細かい権限：** 広範なトークンアクセスを、CI/CDジョブが実際に必要とする特定のAPIエンドポイントへのアクセスのみを付与する、きめ細かく明示的な権限に置き換えます。ジョブにプロジェクトリソースへのブランケットアクセスを許可する代わりに、チームはデプロイメント、パッケージ、リリース、環境、その他の重要なリソースに対する正確な権限を定義でき、攻撃対象領域と権限昇格の可能性を減らすことができます。\n* **AWS Secrets Manager統合：** AWS Secrets Managerを使用しているチームは、GitLab CI/CDジョブでシークレットを直接取得できるようになり、ビルドとデプロイプロセスが簡素化されます。シークレットは、OpenID Connectプロトコルベースの認証を使用してGitLab Runnerによってアクセスされ、ジョブログでの露出を防ぐためにマスクされ、使用後に破棄されます。このアプローチにより、変数にシークレットを保存する必要がなくなり、既存のGitLabおよびAWSベースのワークフローにクリーンに統合されます。Deutsche BahnおよびAWS Secrets Managerチームとの緊密な協力により開発されたこの統合は、実世界の課題を解決するためにユーザーと一緒にソリューションを構築するという当社のコミットメントを反映しています。\n\n### アーティファクト管理：ソフトウェアサプライチェーンの保護\n\nアーティファクトが適切に管理されていない場合、小さな変更が大きな結果をもたらす可能性があります。可変パッケージ、上書きされたコンテナイメージ、ツール間で一貫性のないルールは、本番障害を引き起こし、脆弱性を招き、コンプライアンスギャップを作成する可能性があります。エンタープライズDevSecOpsにとって、安全で一元化されたアーティファクト管理は、ソフトウェアサプライチェーンを維持するために不可欠です。\n\n#### 18.3のエンタープライズグレードアーティファクト保護\n\n包括的なパッケージ保護機能を基盤として、GitLab 18.3は重要な新機能を追加します：\n\n* **Conanリビジョンサポート：** 18.3の新機能である[Conanリビジョン](https://docs.gitlab.com/user/packages/conan_2_repository/#conan-revisions)は、C++デベロッパーにパッケージの不変性を提供します。パッケージのバージョンを変更せずに変更を加えた場合、Conanはこれらの変更を追跡するための一意の識別子を計算し、チームがバージョンの明確性を維持しながら不変のパッケージを維持できるようにします。\n* **強化されたコンテナレジストリセキュリティ：** 18.2での[不変コンテナタグ](https://docs.gitlab.com/user/packages/container_registry/immutable_container_tags/)のローンチ成功に続き、エンタープライズでの採用が進んでいます。不変ルールに一致するタグが作成されると、権限レベルに関係なく、誰もそのコンテナイメージを変更できなくなり、本番依存関係への意図しない変更を防ぎます。\n\nこれらの機能強化は、npm、PyPI、Maven、NuGet、Helmチャート、および汎用パッケージに対する既存の保護機能を補完し、プラットフォームチームがソフトウェアサプライチェーン全体で一貫したガバナンスを実装できるようにします。これは、安全な内部デベロッパープラットフォームを構築する組織にとって不可欠です。\n\nスタンドアロンのアーティファクトソリューションとは異なり、GitLabの統合アプローチは、コードからデプロイメントまでのエンドツーエンドのトレーサビリティを提供しながら、複数のツールを使い分ける際の頭の切り替えを排除し、プラットフォームチームがソフトウェアデリバリーパイプライン全体で一貫したガバナンスを実装できるようにします。\n\n### 埋め込みビュー：リアルタイムの可視性とレポート\n\nGitLabプロジェクトの複雑さが増すにつれて、チームは作業ステータスへの可視性を維持するために、イシュー、マージリクエスト、エピック、マイルストーン間を移動することになります。課題は、頭の切り替えやフローを中断することなく、チームがプロジェクトの進行状況にリアルタイムでアクセスできるようにしながら、この情報を効率的に統合することにあります。\n**18.3でリアルタイム作業ステータスの可視性をローンチ**\n強力な[GitLabクエリ言語（GLQL）を搭載したGitLab 18.3の埋め込みビュー](https://docs.gitlab.com/user/glql/#embedded-views)は、ライブプロジェクトデータをワークフローに直接もたらすことで、頭の切り替えを排除します：\n\n* **動的ビュー：** ページを読み込むたびに現在のプロジェクト状態で自動的に更新される、Markdownコードブロックのwikiページ、エピック、イシュー、マージリクエスト全体にライブGLQLクエリを挿入します。\n* **文脈に応じたパーソナライゼーション：** ビューは、手動設定なしで、表示している人に関連する情報を表示するために、`currentUser()`や`today()`などの関数を使用して自動的に適応します。\n* **強力なフィルタリング：** 担当者、作成者、ラベル、マイルストーン、ヘルスステータス、作成日など、25以上のフィールドでフィルタリングします。\n* **表示の柔軟性：** カスタマイズ可能なフィールド選択、アイテム制限、並べ替え順序を使用して、データをテーブル、リスト、または番号付きリストとして表示し、ビューを集中的で実行可能に保ちます。\n\n断片化されたプロジェクト管理アプローチとは異なり、埋め込みビューは、リアルタイムの可視性を提供しながらワークフローの継続性を維持するように設計されており、チームが複数のツールやインターフェース間で焦点を失ったり切り替えたりすることなく、情報に基づいた意思決定を行えるようにします。\n\n> [GitLab 18.3の最新機能](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/)について詳しく見る。\n\n## 今すぐ始める\n\nGitLab 18.3は、GitLab.comおよびセルフマネージド環境のGitLab PremiumおよびUltimateユーザーが今すぐ利用できます。\n\nGitLab Dedicatedのお客様は現在18.2にアップグレードされており、来月GitLab 18.3でリリースされた機能を使用できるようになります。\n\nソフトウェアエンジニアリングの未来を体験する準備はできましたか？[GitLab Duoのベータ版と実験的機能を有効](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)にして、完全な開発コンテキストを理解するAIエージェントとのコラボレーションを開始してください。\n\nGitLabは初めてですか？[無料トライアルを今すぐ開始](https://gitlab.com/-/trials/new)して、世界で最も包括的なDevSecOpsプラットフォームを通じてオーケストレーションされた、人間とAIのコラボレーションがソフトウェアエンジニアリングの未来である理由を発見してください。\n\n\u003Cp>\u003Csmall>\u003Cem>このブログ投稿には、1933年証券法第27A条および1934年証券取引所法第21E条の意味における「将来を見据えた声明」が含まれています。このブログ投稿に含まれる将来を見据えた声明に反映された期待は合理的であると信じていますが、実際の結果または成果が将来を見据えた声明によって表現または暗示された将来の結果または成果と実質的に異なる原因となる可能性のある既知および未知のリスク、不確実性、仮定、およびその他の要因の対象となります。\u003C/em>\u003C/p>\n\u003Cp>\u003Cem>実際の成果と結果が、このブログ投稿に含まれる、または検討される将来を見据えた声明に含まれるものと実質的に異なる原因となる可能性のあるリスク、不確実性、およびその他の要因に関する詳細情報は、証券取引委員会に提出および報告する「リスク要因」というキャプションの下およびその他の場所に含まれています。このブログ投稿の日付以降に将来を見据えた声明の改訂を更新またはリリースする義務、またはイベントや状況を報告する義務、または予期しないイベントの発生を反映する義務を負いません（法律で要求される場合を除く）。\u003C/em>\u003C/small>\u003C/p>",[869],"Bill Staples","2025-08-21",[730,675,706,679,9],{"featured":90,"template":683,"slug":873},"gitlab-18-3-expanding-ai-orchestration-in-software-engineering","content:ja-jp:blog:gitlab-18-3-expanding-ai-orchestration-in-software-engineering.yml","Gitlab 18 3 Expanding Ai Orchestration In Software Engineering","ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering.yml","ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering",{"_path":879,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":880,"content":886,"config":895,"_id":897,"_type":13,"title":898,"_source":15,"_file":899,"_stem":900,"_extension":18},"/ja-jp/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"title":881,"description":882,"ogTitle":881,"ogDescription":882,"noIndex":6,"ogImage":883,"ogUrl":884,"ogSiteName":696,"ogType":697,"canonicalUrls":884,"schema":885},"GitLab Ultimateの総経済効果：3年間でROIが483%","Forrester Consulting社によるGitLab Ultimateに関する調査では、DevSecOpsプラットフォームがセキュリティ関連の作業時間を5分の1に短縮し、セキュリティ対策を強化したことが示されています。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","https://about.gitlab.com/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Ultimateの総経済効果：3年間でROIが483%\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-11-13\",\n      }",{"title":881,"description":882,"authors":887,"heroImage":883,"date":889,"body":890,"category":891,"tags":892,"updatedDate":894},[888],"Dave Steer","2024-11-13","強力なDevSecOpsプラットフォームであるGitLabは、運用の効率化、セキュリティの脆弱性によるビジネスの混乱（およびコスト発生）の防止、生産性の向上、革新とコラボレーションの文化の醸成を可能にします。当社がGitLabを開発したのはまさにそのためであり、Ultimateプランはプラットフォームのすべての機能が搭載されています。実際の成果を確認すべく、Forrester Consulting社に『Total Economic Impact™ of GitLab Ultimate（GitLab Ultimateの総経済効果）』調査の実施を依頼しました。その結果の概要を以下にご紹介します。\n\nこの調査では、顧客へのヒアリング結果を基にして想定された複合企業モデルにおいて、GitLabが次のような成果をもたらしたことが確認されました。\n\n* **3年間でROIが483%**\n* **デベロッパーの生産性が400%向上**\n* **初回リリースまでの時間が15分の1に短縮\u003Csup>1\u003C/sup>**\n* **セキュリティ関連の作業時間が5分の1に短縮**\n\n**全体として、GitLabによってビジネス価値に直結する作業を50%増加させることができます。**\n\n上記の数字は、GitLabのプラットフォームがチームの働き方をいかに変革できるかを明確に示しています。セキュリティ対策の強化を担うアプリケーションセキュリティ担当者、高品質なコードをより迅速に提供したいデベロッパー、または拡張性・安全性・柔軟性に優れたDevSecOpsプラットフォームをお探しのCTOの方、どの役割の方にとっても、GitLab Ultimateがそれぞれのニーズに応えることをこの調査（詳しい調査方法は下記を参照）は示しています。それでは、調査結果を詳しく見ていきましょう。\n\n> [2024年Forrester Consulting社『Total Economic Impact™ of GitLab Ultimate（GitLab Ultimateの総経済効果）』調査レポート](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/)（英語、全文）をダウンロードできます。\n\n## **1. 3年間でROIが483%**\n\n*「我々が得た大きなメリットが、管理面と全体的な運用における効率性の向上です。今では、全員が協力して作業できるようになり、パイプラインの自動化も簡単に行えるようになりました。また、スタッフを柔軟に配置し、さまざまなタスクをより効率的に完了させることが可能になりました。以前はプログラムごとに異なるツールのトレーニングが必要でしたが、今ではGitLabの使い方さえ覚えればすぐに作業を開始できます」* - 防衛産業、CTO兼シニアバイスプレジデント\n\nこの調査では、主に効率性の向上により、GitLab Ultimateを導入してからわずか6か月で投資回収が始まったことが明らかになりました。**3年間で483%のROI**を達成した組織では、ソフトウェアツールチェーンのコストを25%削減し、ITチームが複雑なツールチェーンの管理時間を75%短縮しました。コスト削減だけでなく、統合プラットフォームへの移行により、チームにおけるソフトウェアの開発とデリバリーのプロセスが根本的に改善されました。\n\n## **2. 生産性が400%向上**\n\n*「GitLabについてデベロッパーたちと話すと、全員が口を揃えて、チームや役割を超えて組織全体の生産性が向上したと感じていると言います。このひとつのプラットフォームには、全員が活用できる機能が備わっています」* - エネルギー・研究業界、ソフトウェアアーキテクト\n\nデベロッパーが能力を発揮するには、作業を中断することなくタスクを簡単に切り替えられる環境が必要です。調査によると、GitLabの[テストの自動化機能](https://about.gitlab.com/ja-jp/topics/devops/devops-test-automation/)を活用することで、デベロッパーは年間最大305時間を創出できることがわかりました。この機能により、テストの頻度を上げ、バグを迅速に追跡して修正できるようになります。これらすべてが単一のインターフェース内で行えるため、複数タスクの並行による頭の切り替えも不要です。この効率化されたワークフローにより、デベロッパーは複数のツールやプロセスを扱う必要がなくなり、コーディングに集中できます。\n\n生産性向上の効果はオンボーディングにも及びます。調査対象となった複合企業のソフトウェア開発チームでは、新入社員が即戦力化するまでの期間が75%短縮されました（1.5か月から1.5週間に短縮）。この結果は、チーム全員がより早く意義のある作業に取り組めるようになるという効果を明確に示しています。\n\n## **3. 初回リリースまでの時間が15分の1に短縮**\n\n*「私たちの強みはソフトウェアにあり、そのパフォーマンスは、開発速度に加え、新機能を迅速に顧客に届ける能力で測られます。この目標を最優先するためにも、単一プラットフォームに各種機能を『統合する』ことが経済的に最も優れた選択肢でした」* - 防衛産業、CTO兼シニアバイスプレジデント\n\n質問に対する顧客の回答から得られたデータによると、GitLabを活用することで、組織は本番環境への初回リリースを従来の15倍の速度で実現できることが明らかになりました。この向上は、プロジェクトの迅速な立ち上げ、より頻繁なソフトウェアリリース、そして開発プロセスの初期段階からセキュリティスキャンをネイティブに統合するという積極的なセキュリティアプローチによって実現されています。開発速度が向上しても、ソフトウェアの品質やセキュリティは高い水準を維持しています。これは、デベロッパーが早期かつ迅速に問題を修正できるようになったおかげです。\n\n[セキュリティが開発プロセスに直接組み込まれている](https://about.gitlab.com/ja-jp/solutions/security-compliance/)ことで、デベロッパーは作業の流れを中断することなく、脆弱性を特定し、優先順位を付け、修正できます。このように、ソフトウェア開発ライフサイクル全体を統合的に管理するアプローチにより、チームはセキュリティを損なうことなく、より迅速に作業を進められます。\n\n## **4. セキュリティ関連の作業時間が5分の1に短縮**\n\n*「セキュリティスキャンと品質スキャンをパイプラインに統合したことで、私たちの業務は大きく変わりました。自動化が進み手作業が減ったことで、失敗や問題が少なくなり、作業の進捗スピードも向上しました」* - 金融業界、プログラムマネージャー\n\n開発速度が上がる一方で脅威も進化し続ける中、セキュリティはすべての組織にとって最重要課題です。GitLabを使用する複合企業では、ディザスタリカバリの準備、監査、コンプライアンスチェックといった反復的なタスクを自動化することで、セキュリティチームの**メンバー1人あたり年間78時間**を節約しています。また、GitLabはソフトウェア開発プロセスの可視性を高め、セキュリティチームと開発チームがより効率的に連携できるよう支援します。\n\n複合企業のサイバーセキュリティチームとソフトウェア開発チームは、**ソフトウェア開発ライフサイクル全体を通じて、セキュリティリスクの管理・軽減にかかる工数を81%削減**できました。これは、GitLabによってセキュリティプロトコルやスキャンをソフトウェア開発ライフサイクルのすべての段階に統合し、厳格なセキュリティ基準を維持するプロセスが簡素化されたためです。セキュリティテストや問題修正がパイプラインに組み込まれているおかげで、チームは平均対応時間を短縮し、問題が本番環境に到達するリスクを軽減できます。\n\n# **DevSecOpsを実際に試す**\n\n483%のROI達成や短期間での投資回収といった実績に加え、数多くの成功事例を持つGitLabは、ソフトウェア開発プロセスの変革を目指すエンタープライズにとって欠かせないツールです。\n\n> GitLabの活用によって貴社にどのようなメリットがもたらされるかについては、[Forrester Consulting社『Total Economic Impact™ of GitLab Ultimate（GitLab Ultimateの総経済効果）』調査レポート](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/)（英語、全文）をダウンロードしてご確認ください。\n\n**調査方法**\n*この調査では、Forrester社が金融、防衛、研究などさまざまな業界のGitLab Ultimateユーザー4社にインタビューを行い、その結果を集約して複合企業モデルを作成しました。この複合企業は、3年間ですべてのチームにGitLab Ultimateを導入することを想定しています。*\n\n*ここの複合企業は、売上高50億ドル、従業員5,000人の企業で、40％がソフトウェアの提供に関与し、年間売上の50％がソフトウェア開発によって生み出されています。彼らの目標は、複数のツールを統合して1つのプラットフォームにまとめ、デベロッパーの生産性を向上させ、業界規制や内部ポリシーの遵守を確保し、開発ライフサイクル全体でセキュリティを強化することです。*\n\n*1. 顧客インタビューの要約データに基づいています。複合企業の結果には適用されません。*","news",[706,893,891,9],"research","2024-11-26",{"slug":896,"featured":90,"template":683},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years","content:ja-jp:blog:gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","Gitlab Ultimates Total Economic Impact 483 Roi Over 3 Years","ja-jp/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","ja-jp/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"_path":902,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":903,"content":909,"config":916,"_id":918,"_type":13,"title":919,"_source":15,"_file":920,"_stem":921,"_extension":18},"/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"title":904,"description":905,"ogTitle":904,"ogDescription":905,"noIndex":6,"ogImage":906,"ogUrl":907,"ogSiteName":696,"ogType":697,"canonicalUrls":907,"schema":908},"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":904,"description":905,"authors":910,"heroImage":906,"date":912,"body":913,"category":667,"tags":914,"updatedDate":915},[911],"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/seventeen/)\n\n\n## AI生成コードの課題\n\n\nAI生成コードは、次のような問題に頻繁に直面します。\n\n\n- アルゴリズムの不一致：不適切または最適化されていないアルゴリズムが生成される場合があります。\n\n- 依存関係の問題： AIが生成するコードには、古い依存関係や互換性のない依存関係が含まれている可能性があります。\n\n- セキュリティ上の脆弱性：AIは、セキュリティ上の欠陥を伴うコードを生成することがあります。\n\n\n上記のように、AI生成コードは、アルゴリズムの不一致、依存関係の問題、セキュリティの脆弱性などの問題によく直面します。プログラミング関連の質問に対するChatGPTの回答について、[Association\nof Computing\nMachinery（計算機協会）が発表した最近の研究](https://dl.acm.org/doi/pdf/10.1145/3613904.3642596)（外部サイト）では、回答の52%に誤った情報が含まれており、77%が過度に冗長であることがわかりました。これらの欠点があるにもかかわらず、ユーザーはChatGPTの包括的でよく構成された回答を35%の割合で好み、誤情報が含まれていても39%の割合でそれを見過ごしました。これらの課題に対処するには、高度なツールとフレームワークを使用する必要があります。\n\n\n## AIセキュリティとテストに対するGitLabのアプローチ\n\n\nGitLabでは、開発ワークフロー内にセキュリティ対策を組み込むことに焦点を当てた、包括的なコンテンツ戦略を採用しています。GitLab\nDuoを活用してAIによるコード生成を応用したり、GitLab\nPagesを利用してテストレポートを（ウェブサイトに）埋め込んだりすることで、デベロッパーはAI生成コードのセキュリティと信頼性を確保できます。\n\n\n以下は、GitLab DuoとGitLab Pagesを組み合わせて、[Flask\nwebサーバー](https://flask.palletsprojects.com/en/3.0.x/)（外部サイト）を実装することでAI生成コードを安全かつ徹底的にテストするための手順ガイドになります。\n\n\n#### 1. GitLab.comで新しいプロジェクトを作成する\n\n\n- [GitLab.com](http://GitLab.com)にアクセスします。\n\n- 「新しいプロジェクト」ボタンをクリックします。\n\n- 「空白のプロジェクトを作成」を選択します。\n\n- プロジェクト名を入力します（例：AI_CODE_SECURITY）。\n\n- 表示レベル（公開、内部、非公開）を設定します。\n\n- 「プロジェクトを作成」をクリックします。\n\n\n#### 2. GitLab Duoのコード提案を有効にする\n\n\n- プロジェクトに移動します。\n\n- 「Web IDE」ボタンをクリックしてWeb IDEを開きます。\n\n- GitLab Duoの機能（コード提案、Duoチャットなど）が有効になっていることを確認します。\n\n- [Web\nIDE](https://docs.gitlab.com/ee/user/project/web_ide/)でコーディングを開始します。入力する際に、GitLab\nDuoによるコード提案が表示され、より効率的なコーディングを支援してくれます。\n\n\n#### 3. Flask Webサーバーを作成する\n\n\n下のスクリーンショットのコメント（緑色のテキスト）を使用して、Flask Webサーバーを作成できます。\n\n\n![DGDテスト -\n画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097192520.png)\n\n\n#### 4. GitLab Duoでテストを生成する\n\n\nユニットテストは、生成されたコードの機能を検証する上で不可欠です。GitLab Duoの` /tests`コマンドを使用して、直接[Web\nIDE内でテストの提案を生成](https://docs.gitlab.com/ee/user/gitlab_duo_chat_examples.html#write-tests-in-the-ide)します。このコマンドは、具体的な側面（パフォーマンス、リグレッション、特定のフレームワークの使用など）に焦点を当てるために、指示を追加してカスタマイズできます。\n\n\n##### Web IDEでの使用例：\n\n\n- テストを生成したいコードを選択します。\n\n- `/tests`コマンドを使用し、必要に応じて指示を追加します。\n\n\n![DGDテスト -\n画像2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097192521.png)\n\n\n#### 5. GitLab Duoチャットを使用してAI生成コードの問題を特定する\n\n\nGitLab Duoチャットを使用して、AIが生成したコードのレビューと修正を行います。たとえば、Flask\nWebサーバーのコードにセキュリティ脆弱性がないか確認する場合は、以下のプロンプトを使用します。\n\n\n```unset\n\nプロンプト：このコードをレビューして、潜在的なセキュリティ脆弱性と依存関係の問題を検証してください。\n\n\n```\n\n\n![DGDテスト -\n画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097192523.png)\n\n\nGitLab Duoチャットを使用することで、上記のコード内の脆弱性を特定しやすくなります。\n\n\n#### 6. テストレポートを生成する\n\n\nテストを実行した後、GitLab Pagesを使用してデプロイするテストレポートを生成します。\n\n\n```unset\n\n\nプロンプト：GitLab Pagesを使用してデプロイするテストレポートを生成するPythonスクリプトを作成してください。\n\n\n```\n\n\n![DGDテスト -\n画像4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097192525.png)\n\n\nここでの処理内容は以下のとおりです。\n\n\n- スクリプトは、test_reportsディレクトリが存在することを確認します。\n\n- `subprocess.run()`を使用して`test_server.py`ファイルを実行し、出力（テスト結果）をキャプチャします。\n\n- 出力のRAWデータを`test_reports/test_output.txt`に保存します。\n\n-\nテスト結果を読みやすいように`\u003Cpre>`タグ内に埋め込んだHTMLレポートを生成し、`test_reports/index.html`として保存します。\n\n\n#### 7. GitLab Pagesを使用してテストレポートをデプロイする\n\n\n[GitLab\nPages](https://docs.gitlab.com/ee/user/project/pages/)を使用し、テストレポートを公開します。テストレポートをデプロイするための`.gitlab-ci.yml`ファイルの構成は次のとおりです。\n\n\n```python\n\n\nstages:\n  - test\n  - deploy\ntest_job:\n  stage: test\n  script:\n    - python generate_test_report.py\n  artifacts:\n    paths:\n      - test_reports/\npages:\n  stage: deploy\n  script:\n    - mv test_reports public\n  artifacts:\n    paths:\n      - public\n\n ```\n\nこの構成では、`test_job`ステージでPythonスクリプトを実行してテストレポートを生成します。`pages`ステージでは、`test_reports`ディレクトリが`public`に移動され、GitLab\nPagesがそのコンテンツを提供するために使用されます。\n\n\n#### 8. MRウィジェットにテストレポートを埋め込む\n\n\n[MRウィジェットにテストレポート](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html)を埋め込むことで、テストの結果を即座に確認でき、透明性と信頼性を確保できます。これは、次のように、CI/CDパイプラインの構成にテストレポートをアーティファクトとして含めることで実現できます。\n\n\n```python\n\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the project...\"\n    - # Your build commands here\n\ntest_job:\n  stage: test\n  script:\n    - mkdir -p test-reports\n    - python test_server.py > test-reports/results.xml\n  artifacts:\n    when: always\n    reports:\n      junit: test-reports/results.xml\n    paths:\n      - test-reports/results.xml\n\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - mv test-reports .public/\n  artifacts:\n    paths:\n      - .public\n\n```\n\nテストレポートをアーティファクトとして含め、レポートセクションに指定することで、GitLabによってテスト結果が自動的にMRウィジェットに表示されます。これにより、テストの結果が即座に確認でき、透明性と信頼性が向上します。\n\n\n#### ケーススタディ：セキュリティポリシーとスキャナーによるAIの信頼性\n\n\nAI生成コードのスニペットが、既知の脆弱性を持つ依存関係を取り込んだ状況を想定してみましょう。GitLab\nDuoとそのセキュリティポリシーを使用することで、この依存関係はコード生成プロセス中に検出されます。AIによって生成された以下のスニペットの例を見てみましょう。\n\n\n```python\n\n\nimport os\n\nfrom flask import Flask, request\n\n\napp = Flask(__name__)\n\n\n@app.route('/search')\n\ndef search():\n    query = request.args.get('query')\n    execute_os_command(query)\n    return 'You searched for: ' + query\n\ndef execute_os_command(command):\n    os.system(command)\n\nif __name__ == '__main__':\n    app.run()\n\n```\n\n\nこの例では、検索エンドポイントがOSコマンドインジェクションの脆弱性を持っています。GitLabの静的アプリケーションセキュリティテスト（[SAST](https://docs.gitlab.com/ee/user/application_security/sast/)）コンポーネントを活用することで、この脆弱性はCI/CDパイプライン中に検出されます。\n\n\n##### SASTスキャンを統合して脆弱性を検出する\n\n\nGitLab\nSASTは、自動的にコードを分析してセキュリティ脆弱性を検出します。以下は、`.gitlab-ci.yml`ファイルに統合して問題をスキャンする方法です。\n\n\n```python\n\n\nstages:\n  - build\n  - test\n  - sast\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the project...\"\n    - # Your build commands here\n\ntest_job:\n  stage: test\n  script:\n    - python test_server.py > test-reports/results.xml\n  artifacts:\n    when: always\n    reports:\n      junit: test-reports/results.xml\n    paths:\n      - test-reports/results.xml\n\nsast_job:\n  stage: sast\n  script:\n    - echo \"Running SAST...\"\n  artifacts:\n    reports:\n      sast: gl-sast-report.json\n  only:\n    - branches\n\npages:\n  stage: deploy\n  script:\n    - mv test-reports public\n  artifacts:\n    paths:\n      - public\n\n```\n\n\nこの設定では、`sast_job`ステージがSASTを実行してコードの脆弱性を検出し、パイプラインアーティファクトに含まれるレポート（`gl-sast-report.json`）を生成します。GitLab\nDuoは、セキュリティポリシーと強力なテストフレームワークを統合することで、お客様がAI生成コードの効率性とセキュリティを確保することを支援します。\n\n\n## 始めてみよう\n\nソフトウェア開発におけるAIの統合は大きなメリットをもたらしますが、新たな課題も伴います。GitLab DuoやGitLab\nPagesのようなツールを使用することで、デベロッパーはAI生成コードを徹底的にテストし、そのセキュリティと信頼性を確保できます。まずはこれらのツールをお試しになり、AIセキュリティとテストの強化を検討してみませんか？\u003Cbr>\n\n\u003Cbr>\n\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n\n\n> 今すぐ[GitLab\nUltimateのトライアルを開始](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)して、GitLab\nDuoとGitLab Pagesをご利用ください。\n\n\n## 「GitLab Duo開発の現場から」シリーズをもっと読む\n\n\n- [GitLab\nDuo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [GitLab\nDuo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [GitLab\nDuo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n\n- [GitLab\nDuo開発の現場から：AIと根本原因分析を併用したCI/CDパイプラインの修正](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)\n",[675,678,680,9],"2024-10-10",{"slug":917,"featured":6,"template":683},"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":923,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":924,"content":930,"config":936,"_id":938,"_type":13,"title":939,"_source":15,"_file":940,"_stem":941,"_extension":18},"/ja-jp/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"title":925,"description":926,"ogTitle":925,"ogDescription":926,"noIndex":6,"ogImage":927,"ogUrl":928,"ogSiteName":696,"ogType":697,"canonicalUrls":928,"schema":929},"GitLabにカスタムセキュリティスキャナーをインテグレーションする方法","ワークフローにカスタムセキュリティスキャナーを追加して、DevSecOpsプラットフォームを拡張する方法を学びましょう（わかりやすいチュートリアルが含まれています）。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097082/Blog/Hero%20Images/Blog/Hero%20Images/securitycheck_securitycheck.png_1750097081856.png","https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabにカスタムセキュリティスキャナーをインテグレーションする方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-27\",\n      }",{"title":925,"description":926,"authors":931,"heroImage":927,"date":932,"body":933,"category":9,"tags":934},[748],"2024-02-27","最も包括的なDevSecOpsプラットフォームであるGitLabには、アプリケーションにおけるプラン、管理、ビルド、デプロイ、セキュア、ガバナンス、およびモニタリングに必要なすべての機能が備わっています。しかし、サードパーティのツールやカスタムツールを使用してGitLabを拡張したいときもあります。たとえば、別のソリューションからDevSecOpsプラットフォームに移行したり、サードパーティのツールを評価したり、独自の、またはカスタムビルドのソリューションをGitLabにインテグレーションしたりすることが求められる場合があります。\n\nこの記事では、次の内容について説明します。\n- [GitLab DevSecOpsプラットフォームの拡張性](#gitlab-devsecops-platform-extensibility)\n- [GitLabセキュリティスキャナーのインテグレーション](#gitlab-security-scanner-integration)\n- [マージリクエストのセキュリティウィジェット](#merge-request-security-widget)\n- [パイプラインセキュリティセクション](#pipeline-security-section\n)\n- [脆弱性レポート](#vulnerability-report)\n- [脆弱性ページ](#vulnerability-pages)\n- [セキュリティダッシュボード](#security-dashboard)\n- [スキャン結果ポリシーのインテグレーション](#scan-result-policy-integration)\n- [チュートリアル：カスタムセキュリティスキャナーのインテグレーション](#tutorial-integrating-custom-security-scanners)\n- [カスタムセキュリティスキャナーの作成](#creating-a-custom-security-scanner)\n- [カスタムセキュリティスキャナーとGitLabのインテグレーション](#integrating-a-custom-security-scanner-with-gitlab)\n\n## GitLab DevSecOpsプラットフォームの拡張性\n\nGitLabはさまざまな方法で拡張でき、組織で必要となる拡張機能をサポートします。これらのインテグレーションの一般的な例としては、次のようなものがあります。\n\n- JenkinsやSlackなどの外部アプリケーションのインテグレーション\n- BugzillaやJiraなどの外部イシュートラッキングのインテグレーション\n- LDAPやSAMLなどの外部認証プロバイダーのインテグレーション\n- FortifyやCheckmarxなどの外部セキュリティスキャナーのインテグレーション\n- AWSやGCPのアクセスキーなどの流出したシークレットに対応する機能\n\n利用可能なすべてのインテグレーション機能は、[GitLabドキュメントとのインテグレーション](https://docs.gitlab.com/ee/integration/)で確認できます（注：ドキュメントにはすべてのインテグレーションが記載されているわけではありません）。\n\n## GitLabセキュリティスキャナーのインテグレーション\n\n[サードパーティのセキュリティスキャナー](https://docs.gitlab.com/ee/integration/#security-improvements)または[カスタムビルドのセキュリティスキャナー](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)をGitLabにインテグレーションして、マージリクエストウィジェット、パイプラインセキュリティセクション、脆弱性レポート、脆弱性ページ、セキュリティダッシュボード、およびスキャン結果ポリシーを作成できます。各インテグレーションについて確認しましょう。\n\n### マージリクエストのセキュリティウィジェット\n\nマージリクエストには、新たに検出された脆弱性の概要を表示するセキュリティウィジェットが含まれています。\n\n![セキュリティスキャナーのインテグレーション - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097088837.png)\n\n\u003Ccenter>\u003Ci>マージリクエストのセキュリティウィジェット\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n脆弱性をクリックすると、次の情報がポップアップ表示されます。\n- 状態\n- 説明\n- プロジェクト\n- ファイル\n- 識別子\n- 重大度\n- ツール\n- スキャナープロバイダー\n\n![セキュリティスキャナーのインテグレーション - 画像2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097088838.png)\n\n\u003Ccenter>\u003Ci>実行可能な脆弱性とその詳細\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nこれらの脆弱性は実行可能なため、無視するか、非公開のイシューとして作成できます。\n\nカスタムスキャナーの結果は、セキュリティウィジェットに入力するために使用できます。脆弱性データは、スキャナーが出力するJSONスキーマから入力されます。\n\n### パイプラインセキュリティセクション\n\nすべての有効なセキュリティアナライザーはパイプラインで実行され、結果をアーティファクトとして出力します。これらのアーティファクトは重複排除を含む処理が行われ、結果はパイプラインセキュリティタブに表示されます。ここから、生成されたJSONファイルをダウンロードすることもできます。\n\n![セキュリティスキャナーのインテグレーション - 画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097088840.png)\n\n\u003Ccenter>\u003Ci>パイプラインセキュリティタブ\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nカスタムスキャナーの結果は、パイプラインセキュリティタブに入力するために使用できます。列は、スキャナーが出力するJSONスキーマを使用して入力されます。\n\n### 脆弱性レポート\n\n脆弱性レポートには、デフォルトブランチのスキャンから得られた脆弱性に関する情報が記載されています。これには以下が含まれます。\n\n- 重大度レベルごとの脆弱性の総数\n- 一般的な脆弱性属性のフィルター\n- 表形式のレイアウトで表示される各脆弱性の詳細\n\n![セキュリティスキャナーのインテグレーション - 画像4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097088842.png)\n\n\u003Ccenter>\u003Ci>脆弱性レポート\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nデフォルトブランチのカスタムスキャナーの結果を使用して、脆弱性レポートを作成できます。\n\n### 脆弱性ページ\n\n脆弱性レポート内の脆弱性をクリックすると、その脆弱性に関するページに移動します。プロジェクト内の各脆弱性には、次のような詳細情報が記載されている脆弱性ページがあります。\n\n- 説明\n- 検出時期\n- 現在の状態\n- 検出場所\n- 実行可能なアクション\n- 紐つけられたイシュー\n- アクションログ\n- ソリューション\n- 識別子\n- トレーニング\n\n脆弱性ページで提供されるデータを使用して、検出された脆弱性をトリアージしたり、修正をサポートしたりできます。\n\n![セキュリティスキャナーのインテグレーション - 画像5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097088844.png)\n\n\u003Ccenter>\u003Ci>シークレット検出脆弱性の脆弱性ページ\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nカスタムスキャナーの結果は、脆弱性ページに入力するために使用できます。脆弱性データは、スキャナーが出力するJSONスキーマから入力されます。\n\n### セキュリティダッシュボード\n\nセキュリティダッシュボードは、アプリケーションのセキュリティ対策状況を評価するために使用されます。GitLabは、プロジェクトで実行されているセキュリティスキャナーによって検出された脆弱性に関するメトリクス、評価、チャートを提供します。セキュリティダッシュボードには、次のようなデータが表示されます。\n\n- グループ内のすべてのプロジェクトにおける、30日間、60日間、または90日間の脆弱性トレンド\n- 脆弱性の重大度に基づく各プロジェクトのレターグレードの評価\n- 過去365日以内に検出された脆弱性の総数とその重大度レベル\n\n![セキュリティスキャナーのインテグレーション - 画像6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097088846.png)\n\n\u003Ccenter>\u003Ci>グループレベルのセキュリティダッシュボード\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nグループレベルのセキュリティダッシュボードからプロジェクトをクリックすると、365日間の状況を表示する特定のセキュリティダッシュボードにアクセスできます。\n\n![セキュリティスキャナーのインテグレーション - 画像7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097088847.png)\n\n\u003Ccenter>\u003Ci>プロジェクトレベルのセキュリティダッシュボード\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n### スキャン結果ポリシーのインテグレーション\n\nスキャン結果ポリシーは、1つ以上のセキュリティスキャンジョブによる発見事項に基づいて承認を要求するために使用されます。これにより、脆弱なコードが本番環境にマージされるのを防ぐことができます。スキャン結果ポリシーは、CI（継続的インテグレーション）スキャンジョブが完全に実行された後、完了したパイプラインで公開されるジョブアーティファクトレポートに基づいて評価されます。\n\nたとえば、シークレット検出スキャナーが脆弱性を発見した場合、プロジェクトのメンテナーによる承認を必要とするスキャン結果ポリシーを作成できます。手順は次のとおりです。\n\n1. 左側のサイドバーで、**検索または移動先**を選択し、ポリシーを追加するプロジェクトを検索します。\n2. プロジェクトの左側のサイドバーで、**セキュア > ポリシー**に移動します。\n3. **新しいポリシー**を選択します。\n4. **スキャン結果ポリシー**セクションで、**ポリシーを選択**を選択します。\n5. 次のフィールドに入力します。\n- 名前：ポリシーの名前\n- 説明：ポリシーの説明\n- ポリシーの状態：有効かどうか\n- ルール：アクションを実行する（承認が必要）ために満たす必要がある条件\n\n![セキュリティスキャナーのインテグレーション - 画像8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097088849.png)\n\u003Ccenter>\u003Ci>スキャン結果ポリシーのルール\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- アクション：ルールの条件（定義された脆弱性/ライセンスの検出）が満たされた場合に実行されるアクションです\n\n![セキュリティスキャナーのインテグレーション - 画像9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097088850.png)\n\n\u003Ccenter>\u003Ci>スキャン結果ポリシーのアクション\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- プロジェクトの承認設定を上書き：選択した場合、次のオプションによりプロジェクト設定が上書きされますが、ポリシーで選択されたブランチにのみ影響します\n\n![セキュリティスキャナーのインテグレーション - 画像11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097088851.png)\n\n\u003Ccenter>\u003Ci>スキャン結果ポリシーの承認設定\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n6. [マージリクエスト経由で設定]ボタンを押します。\n\nスキャン結果ポリシーがマージされると、マージリクエストを作成し、ルールで定義された条件が満たされるたびに、定義されたアクションがトリガーされます。この場合、コードをマージするには、メンテナーからの承認が少なくとも1回必要になります。\n\n![セキュリティスキャナーのインテグレーション - 画像10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097088852.png)\n\n\u003Ccenter>\u003Ci>脆弱性が検出されたためにブロックされたマージリクエスト\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nカスタムスキャナーの結果は、スキャン結果ポリシーと完全に統合できます。カスタムスキャナーが脆弱性を検出した場合、コードをマージするには承認が必要になります。スキャン結果ポリシーで選択するスキャナーは、適切なJSONスキーマを利用している必要があります。\n\n## チュートリアル：カスタムセキュリティスキャナーのインテグレーション\n\nでは、カスタムセキュリティスキャナーのインテグレーションという重要なパートについて見てみましょう。このチュートリアルでは、カスタムセキュリティスキャナーの作成方法と、それをGitLabに統合する方法を学びます。次のプロジェクトを活用します。\n\n- [Fernパターンスキャナー](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner)：パスワード、秘密キー、社会保障番号などの特定のパターンを探してファイルをスキャンします。\n- [シークレットリスト](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/secret-list)：ユーザーのパスワード、クライアント、およびキーのリストが含まれています。このプロジェクトは、カスタムセキュリティスキャナーをGitLabに統合する方法を示すために使用されています。\n\nアプリケーションの作成方法と使用方法を詳しく説明していますので、次の動画をご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/timMbl5SP-w?si=R2DKtZ5MmBR1rQFL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### カスタムセキュリティスキャナーの作成\n\n次に、GitLabに統合できるカスタムスキャナーを作成しましょう。カスタムスキャナーをGitLabと完全に統合する前に、スキャナーは以下の要件を満たす必要があります。\n- ディレクトリをスキャンして定義されたパターンを探す\n- 適切なスキーマに従っったJSONを出力する\n- コンテナ化され、アクセス可能である\n- 別のプロジェクトで実行できるテンプレートを作成する\n\n提供されたテンプレートを使用して[Fernパターンスキャナー](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner)をプロジェクトで実行すると、次の手順を実行します。\n1. 検出するパターン（正規表現）を定義する一連のルールを読み込みます。\n- 組織のニーズの変化に合わせてルールを構成できるようにします。\n2. ファイルをスキャンして定義されたパターンを探します。\n3. シークレット検出スキーマに従ってJSONレポートを出力します。\n- このプロジェクトでは、Goテンプレートを使用してJSONを作成します。\n- スキャナーの検出対象に応じて、適切なスキーマを使用するようにしてください。\n\nJSONレポートがアーティファクトとしてGitLabに読み込まれると、上記で定義されているように、マージリクエストウィジェット、脆弱性レポート、脆弱性ページ、スキャン結果ポリシー、およびセキュリティダッシュボードが作成されます。\n\n### カスタムセキュリティスキャナーとGitLabのインテグレーション\n\nインテグレーションのすべてのニーズを満たすカスタムスキャナーを作成したら、それをGitLabで実行できます。\n\nカスタムスキャナーの実行は、テンプレートを追加するのと同じくらい簡単です。[シークレットリスト](https://gitlab.com/gitlab-da/tutorials/security-and-governance/custom-scanner-integration/secret-list)プロジェクトの`.gitlab-ci.yml`を調べることで、Fernパターンスキャナーテンプレートがどのように読み込まれるかを確認できます。\n\n1. スキャナーを実行するプロジェクトに[.gitlab-ci.ymlファイル](https://docs.gitlab.com/ee/ci/quick_start/#create-a-gitlab-ciyml-file)を作成します。\n2. [カスタムスキャナーテンプレート](https://docs.gitlab.com/ee/ci/yaml/includes.html)を含めます。\n- 環境変数を使用してテンプレートを設定することもできます。\n3. ファイルをmainブランチにコミットします。\n\nファイルがコミットされると、カスタムスキャナーがパイプラインで実行されることがわかります。パイプラインが完了すると、スキャナーは上記の[GitLabセキュリティスキャナーのインテグレーション](#gitlab-security-scanner-integration)セクションで定義されたすべての領域にデータを入力します。\n\n## 詳細を読む\n\nGitLabの詳細とDevSecOpsプラットフォームを拡張するその他の方法については、次のリソースをご覧ください。\n\n- [セキュリティスキャナーのGitLabインテグレーション](https://docs.gitlab.com/ee/development/integrations/secure.html)\n- [GitLabパートナーインテグレーション](https://docs.gitlab.com/ee/integration/)\n- [カスタムセキュリティスキャナーのプロジェクトグループ](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)\n- [シークレット漏洩への自動応答](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)\n",[680,9,935,706],"testing",{"slug":937,"featured":90,"template":683},"how-to-integrate-custom-security-scanners-into-gitlab","content:ja-jp:blog:how-to-integrate-custom-security-scanners-into-gitlab.yml","How To Integrate Custom Security Scanners Into Gitlab","ja-jp/blog/how-to-integrate-custom-security-scanners-into-gitlab.yml","ja-jp/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"_path":943,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":944,"content":950,"config":955,"_id":957,"_type":13,"title":958,"_source":15,"_file":959,"_stem":960,"_extension":18},"/ja-jp/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":945,"description":946,"ogTitle":945,"ogDescription":946,"noIndex":6,"ogImage":947,"ogUrl":948,"ogSiteName":696,"ogType":697,"canonicalUrls":948,"schema":949},"GitLabのカスタムコンプライアンスフレームワークをDevSecOps環境で活用する方法","新しいフレームワークと、50個を超えるすぐに使えるコントロールを活用することで、これまでひとつずつチェックしていた規制要件を、統合された自動化ワークフローの一部へと変換する方法をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabのカスタムコンプライアンスフレームワークをDevSecOps環境で活用する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-30\",\n      }",{"title":945,"description":946,"authors":951,"heroImage":947,"date":952,"body":953,"category":9,"tags":954},[748],"2025-04-30","コンプライアンスは、単なるチェック項目ではなく、業務リスクから顧客の信頼に至るまで、あらゆるものに影響を与える重要なビジネス機能です。開発チームにとっては、コンプライアンス要件と開発速度のバランスを取ることは特に困難です。GitLabの[カスタムコンプライアンスフレームワーク](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)を使えば、コンプライアンスの確認を開発ワークフローに直接統合することができます。この記事では、この機能の概要と、その効果を最大限に活用する方法についてご紹介します。\n\n## GitLabのカスタムコンプライアンスフレームワークとは？\n\nGitLabのカスタムコンプライアンスフレームワークを使うと、組織は自社のGitLabインスタンス内で、コンプライアンス基準を定義・実装・適用できます。この機能により、GitLabに元々備わっているコンプライアンス機能を拡張し、特定の規制要件や社内ポリシー、業界標準に合わせたカスタマイズ可能なフレームワークを作成できるようになります。\n\nカスタムコンプライアンスフレームワークには、次のようなメリットがあります。\n* 手動での追跡作業にかかる手間を削減\n* 監査対応の準備を加速\n* コンプライアンス制御をGitLab上でネイティブに適用\n\n![フレームワークが一覧表示されたコンプライアンスセンターのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\n今回のリリースでは、50個を超えるすぐに使える（OOTB）コントロールが提供されており（今後さらに追加予定）、医療分野のHIPAA、データプライバシーに関するGDPR（EU一般データ保護規則）、サービス組織向けのシステムおよび組織管理（SOC）2、その他業界固有の規制など、組織ごとのコンプライアンスのニーズに合わせて調整できます。OOTBコントロールの一例は以下のとおりです。\n\n* 職務分離（SoD、例：最低2名の承認者が必要、作成者によるマージリクエストの承認）\n* セキュリティスキャナの実行（例：SASTの実行、[依存関係スキャン](https://docs.gitlab.com/user/application_security/dependency_scanning/)の実行）\n* 認証/認可（例：プロジェクトの公開設定が非公開、AuthSSOが必須）\n* アプリケーション構成（例：ステータスチェックが必須、Terraformが必須）\n\nさらに、GitLab APIを使用して外部環境のコントロールを構成することもでき、外部環境のステータスや詳細を確認できます。\n\n## ゼロからカスタムコンプライアンスフレームワークを作成する\n\nその価値を理解できたところで、次はGitLab環境でカスタムコンプライアンスフレームワークを実装する方法を見ていきましょう。デモアプリケーションを使って説明しますので、動画を見ながら一緒に進めてください。\n\n**注：** GitLab Ultimateのサブスクリプションが必要です。\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**ステップ1：コンプライアンス要件を定義する**\n\nカスタムフレームワークを構築する前に、まずはコンプライアンス要件を明確に定義する必要があります。\n\n1. **適用される規制を特定する：** 自社に適用される規制や標準（例：GDPR、PCI DSS、HIPAA）を確認します。\n2. **各要件に対応するコントロールを割り当てる：** 各規制を、具体的で実行可能なコントロールとして整理します。\n3. **要件に優先順位を付ける：** リスクの高い領域や、影響の大きい要件を優先します。\n\n**ステップ2：カスタムコンプライアンスフレームワークを作成する**\n\n以下の手順でカスタムコンプライアンスフレームワークを作成できます。\n\n1. GitLabグループの**セキュア  > コンプライアンスセンター**セクションに移動します。\n2. **新しいフレームワーク**ボタンを押します。  \n3. **空のフレームワークを作成**を選択します。\n\n![カスタムコンプライアンスフレームワークの作成画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. フレームワークの名前、説明、色を設定します。\n\n![「新しいコンプライアンスフレームワーク」の画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. フレームワークに要件を追加します：\n   a. ページを下にスクロールして**要件**タブを開きます。\n\n   b. **新しい要件**ボタンをクリックします。\n\n   c. 名前と説明を入力します。\n   d. **コントロール**セクションで**GitLab コントロールを選択**をクリックします。  \n   e. 一覧からコントロールを選択します（例：少なくとも 2 つの承認、SAST の実行など）。 \n   f.  **要求事項を作成**ボタンをクリックします。\n\n![「要求事項を作成」ボタン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378652/Blog/oufh8frdwiq1os85byin.png)\n\n6. **フレームワークを作成**ボタンをクリックします。\n\n指定した内容でフレームワークが作成され、プロジェクトに追加できるようになります。また、適切なスキーマに準拠したJSONを使用して、コンプライアンスフレームワークを[インポート](http://TODO)することも可能です。\n\n**ステップ3：プロジェクトにフレームワークを適用する**\n\nフレームワークを作成したら、以下の手順に従います。\n1. コンプライアンスセンターから**プロジェクト**タブを選択します。\n2. 検索バーを使って対象のプロジェクトを**検索**または**絞り込み**ます。 \n3. フレームワークを適用するプロジェクトを選択します。\n4. **一括操作を選択**ボタンをクリックします。\n5. **選択したプロジェクトにフレームワークを適用する**を選択します。\n6. **フレームワークを選択**ボタンをクリックします。\n7. 一覧から適用するフレームワークを選択します。\n8. **適用**ボタンをクリックします。\n\n![SOC 2フレームワークのドロップダウンが表示されたコンプライアンスセンターの画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n適用されたフレームワークは、プロジェクト内で要求事項として可視化され、追跡できるようになります。\n\n**ステップ4：コンプライアンスの状況をモニタリング・報告する**\n\nフレームワークを設定したら、以下のことができるようになります。\n\n1. コンプライアンスセンターを使って、プロジェクト全体のコンプライアンス状況を管理する。不合格となったコントロールの詳細や、推奨される修正方法も確認できます。\n2. 監査や関係者によるレビューへ向けた、**コンプライアンスレポート**を生成する。\n3. **コンプライアンスに関するアラート**を設定し、潜在的な問題を関係者へ通知する。\n4. **監査イベント**で、コンプライアンス設定に対して行われた操作の概要を確認する。\n\n![SOC2テストフレームワークが表示されたコンプライアンスセンターの画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\n## 実例：SOC2 コンプライアンスフレームワークの実装\n\nシステムおよび組織管理（SOC）2、通称SOC2は、米国公認会計士協会（AICPA）によって策定された、厳格な監査基準です。SOC2は、サービス組織のセキュリティ、可用性、処理の完全性、機密性、プライバシーに関するコントロールを評価します。詳細については、[GitLabでSOC 2のセキュリティ要件を満たすためのガイド](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/)をご覧ください。\n\nそれでは、カスタムコンプライアンスフレームワークを使って SOC2 のセキュリティコンプライアンスを検証する実践的な例を見てみましょう。SOC2 のセキュリティ基準には以下が求められます。\n\n* 不正アクセスを防ぐためのコントロールの導入\n* リスクを特定し、軽減するための手順の確立\n* セキュリティインシデントの検出および対応のためのシステムの構築\n\n**免責事項：** これはSOC2の要件に準拠するために利用可能な一部のコントロールを紹介する例です。本番環境に導入する前に、必ずセキュリティ/コンプライアンスチームと相談してください。\n\nGitLabのOOTB（すぐに使える）コントロールを活用したSOC2用カスタムコンプライアンスフレームワークの例：\n\n* **名前：** SOC2セキュリティ要件\n* **説明：** SOC2フレームワークに準拠するためのセキュリティ要件を追加します\n* **要件：**  \n  * **不正アクセスを防ぐためのコントロールの導入**  \n    * Auth SSOを有効化\n    * CI/CDジョブトークンのスコープを有効化\n    * 組織レベルでMFA（多要素認証）を必須化\n  * **リスクを特定し、軽減するための手順の確立**  \n    * 少なくとも2つの承認\n    * 作成者によるマージリクエストの承認\n    * コミッターによるマージリクエストの承認\n    * デフォルトブランチの保護\n  * **セキュリティインシデントの検出および対応のためのシステムの構築**  \n    * 依存関係スキャンの実行\n    * SASTの実行\n    * DASTの実行\n\nこのフレームワークをプロジェクトに適用することで、コンプライアンスが崩れたタイミングや、再度準拠するために必要な対策を把握できるようになります。なお、1つのプロジェクトに対して複数のコンプライアンスフレームワークを作成・適用することも可能です。たとえば、SOC2のプロセス整合性要件専用のフレームワークを別途設けることもできます。\n\n## コンプライアンス要件を満たすためにセキュリティポリシーを実装する\n\n必須ではありませんが、カスタムコンプライアンスフレームワークを含むプロジェクトにセキュリティポリシーを適用することができます。これにより、特定のコンプライアンス基準がセキュリティポリシーによって強制されることを保証できます。たとえば、セキュリティスキャンを求めるカスタムコンプライアンスフレームワークが適用されたプロジェクトに対して、セキュリティスキャナーの実行を強制できます。\n\nGitLab では、以下のようなさまざまなセキュリティポリシーが提供されています。\n\n* [スキャン実行ポリシー](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/)：パイプラインの一部または指定されたスケジュールでセキュリティスキャンを実行します。\n* [マージリクエスト承認ポリシー](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/)：スキャン結果に基づいて、プロジェクトレベルの設定や承認ルールを強制します。\n* [パイプライン実行ポリシー](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/)：プロジェクトのパイプラインにおけるCI/CDジョブの実行を強制します。\n* [脆弱性管理ポリシー](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/)：デフォルトブランチで検出されなくなった脆弱性を自動的に解決します。\n\nここでは、SASTスキャナーを実行することで、SASTスキャンを要求する要件への準拠を自動的に行う方法を紹介します。特定のフレームワークが適用されたプロジェクトに対してセキュリティポリシーを作成・適用するには、次の手順に従います。\n\n1. **SAST スキャン**が求められるカスタムコンプライアンスフレームワークが適用されているプロジェクトに移動します。\n2. サイドバーで、**セキュア > ポリシー**の順に選択します。\n3. **新しいポリシー**ボタンをクリックします。\n4. **スキャン実行ポリシー**で、**ポリシーを選択**ボタンをクリックします。\n5. **名前**と**説明**を入力します。\n6. **アクション**で、実行するスキャンとして**SAST**を選択します。\n\n![「アクション」画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n7. **条件**で、すべてのブランチでパイプラインが実行されたときにトリガーされるように設定します。\n\n![「条件」画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n8. **マージリクエスト経由で設定** ボタンをクリックします。\n9. この時点で、すべてのセキュリティポリシーが含まれた別プロジェクトでマージリクエスト（MR）が作成されます。\n10. **マージ**ボタンをクリックします。\n\nこれで、すべてのブランチでSASTが実行されるようになり、その領域におけるコンプライアンスが保証されます。他にもさまざまな種類のセキュリティポリシーがありますので、要件に合うものを探してみてください。\n\n\n\n## 5つのベストプラクティス\n\nカスタムコンプライアンスフレームワークを最大限に活用するために、以下のベストプラクティスに従いましょう。\n\n1. **小さく始める：** まずは、重要な規制や標準のうち1つから着手し、そこから範囲を広げていきましょう。\n2. **関係者を巻き込む：** フレームワークの作成には、コンプライアンスチーム、セキュリティチーム、デベロッパーチームを含めることが重要です。\n3. **可能な限り自動化する：** GitLab CI/CDを活用して、コンプライアンスチェックの自動化を図りましょう。\n4. **しっかりと文書化する：** フレームワークがどのように規制要件に対応しているか、明確に文書化しておきましょう。\n5. **定期的に見直す：** 規制の変更や新たな要件の発生に応じて、フレームワークを更新するようにしましょう。\n\n## 無料トライアルで今すぐスタート！\n\nGitLabのカスタムコンプライアンスフレームワークは、コンプライアンスを開発ワークフローに直接組み込むことで、DevSecOpsにおける大きな進化をもたらします。カスタムフレームワークを導入することで、コンプライアンス業務の負担を軽減し、リスク管理を強化しながら、規制要件を満たしたまま開発サイクルを加速させることが可能になります。\n\nカスタムコンプライアンスフレームワークを定義・適用できる機能により、チームは自社特有の規制状況に対応する柔軟性を得られる一方で、組織全体のコンプライアンスの慣習を一貫させるために必要な構造も得られます。\n\n今後さらに規制要件が複雑化していく中で、カスタムコンプライアンスフレームワークのようなツールを活用して、コンプライアンスと開発速度のバランスを持続的に両立させることが、ますます重要になるでしょう。\n\n> 今すぐカスタムコンプライアンスフレームワークをお試しになりたい場合は、[GitLab Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)にぜひお申し込みください。\n\n## 関連リンク\n\n以下のリソースで、カスタムコンプライアンスフレームワークの詳細や、そのメリットについてご覧いただけます。\n\n* [カスタムコンプライアンスフレームワークのドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)  \n* [カスタムコンプライアンスフレームワークに関するエピック](https://gitlab.com/groups/gitlab-org/-/epics/13295)  \n* [セキュリティポリシーに関するドキュメント](https://docs.gitlab.com/user/application_security/policies/)  \n* [GitLabのセキュリティおよびコンプライアンスソリューション](https://about.gitlab.com/ja-jp/solutions/security-compliance/)",[9,680,706,679,730],{"slug":956,"featured":90,"template":683},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","content:ja-jp:blog:how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","How To Use Gitlabs Custom Compliance Frameworks In Your Devsecops","ja-jp/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","ja-jp/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"_path":962,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":963,"content":969,"config":976,"_id":978,"_type":13,"title":979,"_source":15,"_file":980,"_stem":981,"_extension":18},"/ja-jp/blog/introducing-the-source-insights-for-the-future-of-software-development",{"title":964,"description":965,"ogTitle":964,"ogDescription":965,"noIndex":6,"ogImage":966,"ogUrl":967,"ogSiteName":696,"ogType":697,"canonicalUrls":967,"schema":968},"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":964,"description":965,"authors":970,"heroImage":966,"date":972,"body":973,"category":891,"tags":974,"updatedDate":975},[971],"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/)にアクセスし、最新の洞察や組織運営に関する疑問への答えを入手し、新たに学んだことをチームと共有しましょう。また、ニュースレターをご購読いただくと、定期的に最新情報をお届けします。先進的なテクノロジーリーダーが集うコミュニティに参加して、ともにソフトウェア開発の未来を形作りましょう。",[675,9,891,678],"2025-03-28",{"slug":977,"featured":90,"template":683},"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":983,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":984,"content":990,"config":997,"_id":999,"_type":13,"title":1000,"_source":15,"_file":1001,"_stem":1002,"_extension":18},"/ja-jp/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"title":985,"description":986,"ogTitle":985,"ogDescription":986,"noIndex":6,"ogImage":987,"ogUrl":988,"ogSiteName":696,"ogType":697,"canonicalUrls":988,"schema":989},"GitHub Advanced SecurityプランからGitLab Ultimateプランへの移行ガイド","GitLab UltimateとGitHub Advanced Securityの共通点と違いを理解し、GitLab DevSecOpsプラットフォームへの移行を段階的に進めるための詳細ガイドです。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","https://about.gitlab.com/blog/migration-guide-github-advanced-security-to-gitlab-ultimate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitHub Advanced SecurityプランからGitLab Ultimateプランへの移行ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-05-01\",\n      }",{"title":985,"description":986,"authors":991,"heroImage":987,"date":992,"body":993,"category":9,"tags":994,"updatedDate":996},[748],"2024-05-01","GitLabは、最も包括的なAIを搭載したDevSecOpsプラットフォームで、ソフトウェアデリバリーライフサイクル全体を1つのプラットフォームで実現することで、より安全で迅速なソフトウェアのリリースを可能にしています。GitHubでは、GitHub内の追加のセキュリティ機能を有効にするAdvanced\nSecurityアドオンを提供してはいますが、GitLabと比較すると、ネイティブに提供するセキュリティ機能の深さと幅広さでは機能の範囲と深さが限定的です。SDLCのすべての領域にわたってセキュリティを強化すべくGitLab\nUltimateプランへの移行を検討している組織は、このガイドを参考にして両製品を比較し、またGitLabプラットフォームに移行するためのチュートリアルとしてもお役立てください。\n\n\nこの記事には次の内容が含まれます\n\n\n- GitLab UltimateとGitHub Advanced Securityの比較\n\n- GitHubリポジトリをGitLabに移行する方法\n\n- GitHub Advanced SecurityからGitLab Ultimateへの機能別の移行方法\n\n- GitLab Ultimateのセキュリティ追加機能の紹介\n\n\n## GitLab UltimateとGitHub Advanced Securityの比較\n\n\n[GitLab\nUltimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)は、安全なソフトウェアをより速く提供したいと考えている企業向けの、GitLabの最上位サブスクリプションプランです。GitHub\nAdvanced Securityは、追加のセキュリティ機能を有効にするGitHub Enterpriseのアドオンです。\n\n\n### GitLab UltimateとGitHub Advanced Securityの類似点\n\n\nGitLab UltimateとGitHub Advanced Securityの両プランに次の機能が搭載されています。\n\n\n-\n静的アプリケーションセキュリティテスト（[SAST](https://docs.gitlab.com/ee/user/application_security/sast/)）、シークレットスキャン、依存関係スキャン\n\n- コンテキスト脆弱性インテリジェンスと解決策のアドバイス\n\n-\n依存関係またはソフトウェア部品表のリスト（[SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)）\n\n- セキュリティ指標と分析情報\n\n\n### GitLab UltimateとGitHub Advanced Securityの相違点\n\n\nGitLab Ultimateは、次の点でGitHub Advanced Securityと異なります。\n\n\n-\nGitLabは、コンテナスキャン、動的アプリケーションセキュリティテスト（[DAST](https://docs.gitlab.com/ee/user/application_security/dast/)）、Web\nAPIファジングなどの追加のコードスキャナーをネイティブに提供します。スキャナーは、カスタムルールセットを備え最適化された、独自のオープンソーステクノロジーを組み合わせたものです。完全なリストについては、[GitLab\nAppSecのドキュメント](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html)をご覧ください。\n\n-\nGitLabは、セキュリティ上問題のあるコードが承認なしにマージされることを防ぐため、[詳細な制御機能（セキュリティガードレール）](https://docs.gitlab.com/ee/user/application_security/policies/)を提供しています。\n\n\n-\nGitLabセキュリティスキャナーは、[インターネット未接続（エアギャップ）環境や制限付きネットワーク環境](https://docs.gitlab.com/ee/user/application_security/offline_deployments/)でも実行可能です。\n\n\n-\nGitLabは、組織全体のコンプライアンス違反を監視できる[コンプライアンスセンター](https://docs.gitlab.com/ee/user/compliance/compliance_center/)を提供しています。\n\n\nさらにGitLab\nUltimateでは、追加のセキュリティやコンプライアンス機能、ポートフォリオとバリューストリームの管理、アップグレード時のライブサポート機能なども提供しています。追加機能の詳細については、[GitLab\nUltimateのドキュメント](https://about.gitlab.com/ja-jp/pricing/ultimate/)を参照してください。\n\n\n## GitHubリポジトリをGitLabに移行する方法\n\n\nGitLabには、GitHub.comまたはGitHub\nEnterpriseからGitHubプロジェクトをGitLabにインポートできるインポーターが組み込まれています。インポーターを使用すると、GitHubリポジトリだけでなく、イシュー、コラボレーター（メンバー）、プルリクエストなど他のオブジェクトもGitLabに移行できます。移行できるものの全リストについては、[GitHubインポートされたデータのドキュメント](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data)を参照してください。移行は次の手順で行います。\n\n1. 左側のサイドバー上部で **新規作成（+）** を選択する\n\n3. **GitLab内**セクションで**新しいプロジェクト/リポジトリ**を選択する\n\n4. **プロジェクトのインポート**を選択する\n\n\n![迷路化したバージョンの中心にGitLabのアイコン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\n\n4. **GitHub**ボタンを押す\n\n- GitLab\nSelf-Managedを使用している場合は、[GitHubインポーターを有効にする](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources)必要があります\n\n- 他のインポーターも同様の方法で開始できます\n\n5. これで、以下のいずれかが可能になりました\n\n- **GitHubで認証**を選択して、GitHub Oauthで認証する\n\n- GitHubのパーソナルアクセストークンを使う\n  - [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new)に移動します\n  - **Note**フィールドにトークンの説明を入力します\n  - **リポジトリ**スコープを選択します\n  - オプションとしてコラボレーターをインポートするには、**read:org**スコープを選択します\n  - **トークンを生成**ボタンを押します\n  - GitLabのインポートページのパーソナルアクセストークンフィールドに、GitHubのパーソナルアクセストークンを貼り付けます\n6. **認証**ボタンを押す\n\n7. 移行するアイテムを選択する\n\n8. 移行するプロジェクトと場所を選択する\n\n9. **インポート**ボタンを押す\n\n\nインポートされたプロジェクトがワークスペースにあることをご確認ください。GitHubからGitLabへの移行に関するさらに詳しいガイダンスは、次の動画をご覧ください。\n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=HEpZVy94cpfPfAky\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!--空白行-->\n\n\n[GitHubパーソナルアクセストークン](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token)または[GitLab\nREST\nAPI](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api)を使用した移行も可能です。また、インポーターは、BitbucketやGiteaなどの他のソースからのインポートも支援します。詳細については、[インポーターのドキュメント](https://docs.gitlab.com/ee/user/project/import/)を参照してください。\n\n\n## 機能別の移行方法\n\n\n次は、GitLab UltimateのGitHub Advanced\nSecurityが提供する各機能の活用方法について見てみましょう。続行するには、[GitLab\nUltimateライセンス](https://about.gitlab.com/ja-jp/pricing/ultimate/)が必要です。GitLabは、[無料トライアル](https://about.gitlab.com/ja-jp/free-trial/devsecops/)がお試しいただけます。\n\n\n### コードスキャン\n\nGitHubでは、静的ソースコードの文脈上の脆弱性インテリジェンスやアドバイスを提供する目的でコードスキャンを実行しています。[SAST](https://docs.gitlab.com/ee/user/application_security/sast/)を有効にすることで、GitLab内でも同じことができます。GitLab\nSASTスキャナーは、GitHubの[CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql)よりも幅広いプログラミング言語とフレームワークをカバーしています。\n\n\nGitLabでコードスキャンを有効にすれば、[SASTテンプレート](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml)を`.gitlab-ci.yml`に追加するだけです。\n\n\n```yaml\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\n\nテンプレートが追加されると、新しいコードがチェックインされるたびに、SASTはプロジェクトで使用されている[プログラミング言語](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)を自動的に検出します。そして、ソースコードに既知の脆弱性がないかスキャンします。\n\n\n**注：**\nセキュリティスキャナーは、GitLabの[セキュリティ設定](https://docs.gitlab.com/ee/user/application_security/configuration/)からプロジェクトに追加することもできます。これにより、パイプラインを更新するためのマージリクエストを自動的に作成できます。詳細については、[UIドキュメントを使用してSASTを構成する](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-by-using-the-ui)を参照してください。\n\n\nフィーチャーブランチとターゲットブランチの差分のSAST結果は、マージリクエストウィジェットで表示されます。マージリクエストウィジェットには、マージリクエストで行われた変更によって導入されたSASTの結果と解決策が表示されます。\n\n\n![マージリクエストでのセキュリティスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/2-SAST-MR-View.png)\n\n\nどの脆弱性にも、詳細な説明、重大度、場所、解決情報など、修正を支援するデータが表示されます。\n\n\n![SASTの脆弱性の詳細](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/3-SAST-MR-View-Detailed.png)\n\n\n脆弱性への対処として次が挙げられます。\n\n\n-\n**脆弱性を無視**：デベロッパーがコメントで脆弱性を無視できるようにします。そうすることで、セキュリティチームがレビューを実行できるようになります。\n\n- **イシューを作成**：イシューを作成して、追加の監視が必要な脆弱性を追跡できるようにします。\n\n\nこれらの変更内容は、マージリクエスト内の**差分表示画面**でもインラインで確認できます。\n\n\n![SASTの脆弱性がビューを変更](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/4-SAST-MR-View-Changes.png)\n\n\n#### SASTスキャナーのカスタマイズ\n\n\nGitLabでは、SASTジョブの定義を上書きできるため、変数、依存関係、ルールなどのプロパティを変更できます。これは、SASTジョブと同じ名前のジョブ名を宣言し、上書きして実行できます。次に、テンプレートをインクルードした後にこの新しいジョブを配置し、その下に追加のキーを指定します。\n\n\nたとえば、次のような設定ができます：\n\n- `semgrep-sast`スキャナーが使用するバージョンを上書きする\n\n- `gosec-sast`を実行する前に、プライベートプロジェクトからモジュールを取得するスクリプトを実行する\n\n- すべてのスキャナーが最大深度10で検索するように設定する\n\n\n```yaml\n\ninclude：\n  - template：Jobs/SAST.gitlab-ci.yml\n\nvariables：\n  SEARCH_MAX_DEPTH：10\n\nsemgrep-sast：\n  variables：\n    SAST_ANALYZER_IMAGE_TAG：\"3.7\"\n\ngosec-sast：\n  before_script：\n    - |\n      cat \u003C\u003CEOF > ~/.netrc\n      machine gitlab.com\n      login $CI_DEPLOY_USER\n      password $CI_DEPLOY_PASSWORD\n      EOF\n```\n\n\n**注：** 利用可能なSASTジョブは、[' SAST.gitlab-ci.yml\n`テンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)にあります。設定については、[利用可能なSAST\nCI/CD変数のドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables)を参照してください。\n\n\n#### SASTルールセットのカスタマイズ\n\n\nGitLabはSASTアナライザーごとにコードを処理し、ルールを使用してソースコードの脆弱性を特定します。これらのルールは、スキャナーが報告する弱点の種類を決定します。\n\n\n-\nSemgrepを基盤としたSASTスキャナーについては、GitLabが検出ルールの作成、保守、サポートを一括して提供しています。Semgrepオープンソースエンジン、GitLabの管理による検出ルール、脆弱性追跡と誤検出のためのGitLab独自の技術を集結しています。\n\n- 他のSASTアナライザーの場合、ルールは各スキャナーのupstreamプロジェクトで定義されています。\n\n\nスキャンされるリポジトリ内の設定ファイルを定義することで、SASTスキャナーの動作をカスタマイズできます。\n\n- 事前定義されたルールを無効にする（すべてのアナライザーで利用可能）\n\n- 事前定義されたルールを上書きする（すべてのアナライザーで利用可能）\n\n- パススルーを使用してカスタム設定を合成することにより、事前定義されたルールを置き換える\n\n\nSASTルールの設定の詳細と例については、[SASTルール](https://docs.gitlab.com/ee/user/application_security/sast/rules.html)と[ルールセットのカスタマイズのドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html)を参照してください。\n\n\n### シークレットスキャン\n\n\nGitHubは、流出したシークレットを見つけ、ブロックし、取り消すことができるシークレットスキャンをサポートします。[シークレット検出](https://docs.gitlab.com/ee/user/application_security/secret_detection/)を有効にすることで、GitLab内でも同じことができます。\n\n\nGitLabでシークレット検出を有効にするには、次のテンプレートを'.gitlab-ci.yml `に追加するだけです。\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\n\nテンプレートが追加されると、新しいコードがチェックインされる（またはパイプラインが実行される）たびに、シークレットスキャナーは既知のシークレットのソースコードをスキャンします。パイプラインでのシークレット検出は、コードの各要素を別々にスキャンします。「デフォルトブランチ」を除くすべてのメソッドでは、パイプラインシークレット検出はワークツリーではなくコミットをスキャンします。シークレットスキャンの仕組みについては、[シークレット検出カバレッジドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#coverage)を参照してください。\n\n\nマージリクエストを作成する際、シークレット検出はソースブランチで行われたすべてのコミットをスキャンします。SASTと同様に、検出されたすべての脆弱性から、修正プロセスを支援するため、以下の情報（ロケーションなど）や識別子を提供します。\n\n\n![シークレット検出の脆弱性の詳細](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/5-Secret-Detection-MR-Detailed.png)\n\n\nSASTと同様に、マージリクエストから直接、脆弱性の無視やイシューの作成など、検出された脆弱性に対するアクションを取ることができます。\n\n\n#### シークレット検出ジョブのカスタマイズ\n\n\nGitLabではシークレット検出ジョブの定義を上書きして、変数や依存関係、ルールなどのプロパティを変更できます。上書きするには、シークレット検出ジョブと同名のジョブを宣言します。次に、テンプレートをインクルードした後に新しいジョブを配置し、その下に追加のキーを指定します。たとえば、次のような設定です。\n\n\n- シークレット検出ジョブの実行ステージを`security`に上書きする\n\n- 過去のコミットに対するスキャンを有効にする\n\n- シークレットアナライザーのバージョンを4.5に変更する\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n  stage: security\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n    SECRETS_ANALYZER_VERSION: \"4.5\"\n```\n\n\n**注：**\n利用可能なシークレット検出ジョブは、[SAST.gitlab-ci.ymlテンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml)にあります。利用可能な設定は、[利用可能なシークレット検出CI/CD変数のドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customizing-analyzer-settings)に記載されています。\n\n\n#### シークレット検出ルールセットのカスタマイズ\n\n\nシークレット検出アナライザーでは、GitLab\nUIに表示されるシークレットをカスタマイズできます。次のカスタマイズオプションは、個別または組み合わせて使用できます。\n\n\n- 定義済みルールを無効にする\n\n- 定義済みルールを上書きする\n\n- カスタム設定を合成する\n\n- リモート設定ファイルを指定する\n\n\nたとえば、`.gitlab/secret-detection-ruleset.toml`というファイルをプロジェクトのルートディレクトリに作成すると、デフォルトのGitLeaksパッケージがテストトークンの検出を無視するように拡張されます。\n\n\n```yaml\n\n### extended-gitleaks-config.toml\n\ntitle = \"extension of gitlab's default gitleaks config\"\n\n\n[extend]\n\n### Extends default packaged path\n\npath = \"/gitleaks.toml\"\n\n\n[allowlist]\n  description = \"allow list of test tokens to ignore in detection\"\n  regexTarget = \"match\"\n  regexes = [\n    '''glpat-1234567890abcdefghij''',\n ]\n```\n\n\n定義済みのアナライザールールを上書きする方法については、[シークレット検出のドキュメント](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#override-predefined-analyzer-rules)を参照してください。\n\n\n#### シークレット漏洩時の自動対応機能\n\n\nGitLabシークレット検出は、特定のタイプの流出したシークレットを発見すると自動的に対応します。自動対応には次のようなアクションがあります。\n\n- 自動的にシークレットを失効させる\n\n-\nシークレットを発行したパートナーに通知し、パートナーはシークレットを取り消すか、その所有者に通知するか、またはその他の方法で不正利用からの保護につなげる\n\n\nGitLabは、パートナーが発行した認証情報がGitLab.comの公開リポジトリに流出した場合、パートナーへの通知も可能です。クラウドやSaaS製品を運用していて、このような通知の受け取りに興味があるという場合、GitLab\nToken Revocation APIから呼び出されるPartner APIを実装できます。\n\n\n詳しくは[流出したシークレットへの自動対応](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)を参照してください。\n\n\n### サプライチェーンのセキュリティ\n\n\nGitHubは、自動化されたセキュリティとバージョン更新、ワンクリックのSBOMにより、ソフトウェアサプライチェーンのセキュリティ確保、管理、レポートを可能にします。GitLabは依存関係スキャンと依存関係リスト（SBOM）機能を使って、サプライチェーンセキュリティのニーズを満たすことができます。\n\n\nGitLabで依存関係スキャンを有効にするには、`.gitlab-ci.yml`に以下のテンプレートを追加するだけです：\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\n\n\nテンプレートが追加されると、新しいコードがチェックインされるたびに、依存関係スキャンがプロジェクトで使われている[パッケージマネージャ](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers)を自動検出します。そして、使用されている依存関係に既知の脆弱性がないかスキャンします。フィーチャーブランチとターゲットブランチの差分の依存関係のスキャン結果は、マージリクエストウィジェットに表示されます。マージリクエストウィジェットは、マージリクエストで行われた変更によって導入された依存関係スキャンの結果と解決策を表示します。マージリクエストの中で、検出された脆弱性は、識別子、証拠、解決策といった、修正を支援する関連情報を表示します。\n\n\n![依存関係スキャナーの脆弱性の詳細](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/6-Dependency-Scanner-MR-View-Detailed.png)\n\n\nSASTやシークレット検出と同様に、脆弱性の無視やイシューの作成など、これらの脆弱性に対するアクションをマージリクエストから直接実行できます。\n\n\n#### 依存関係スキャンの設定\n\n\nジョブの定義を上書きするには（たとえば、変数や依存関係のようなプロパティを変更するには）、上書き対象のジョブと同じ名前で新しいジョブを宣言します。テンプレートをインクルードした後に新しいジョブを配置し、その下に追加のキーを指定します。たとえば、次のコードでは以下の設定を行っています。\n\n\n- 脆弱な依存関係の自動修正を無効にする\n\n- 依存関係スキャンの実行前にビルドジョブの完了を要求する\n\n\n```yaml\n\ninclude：\n  - template：Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning：\n  variables：\n    DS_REMEDIATE：\"false\"\n  dependencies：[\"build\"]\n```\n\n\n依存関係スキャナーの設定についての詳細は、[アナライザーの動作をカスタマイズするドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-analyzer-behavior)を参照してください。\n\n\n#### SBOMの生成\n\n\nGitLabの依存関係リスト（SBOM）で、プロジェクトやグループの依存関係や、既知の脆弱性を含む依存関係の重要な詳細を確認できます。このリストには、プロジェクトにおける依存関係が集約されており、既知のものや新たに検出されたものの両方が含まれています。依存関係リストは、依存関係スキャナーが[デフォルトブランチ](https://docs.gitlab.com/ee/user/project/repository/branches/default.html)で正常に実行された後に生成されます。依存関係リストにアクセスするには\n\n\n1. 左サイドバーで、**検索または移動先...** を選択し、プロジェクトを見つけます。\n\n2. **セキュリティ > 依存関係リスト**の順に選択します。\n\n\n![依存関係リスト（SBOM）](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/7-Dependency-List.png)\n\n\nここから、依存関係に関する次の情報を表示できます。\n\n\n|フィールド|説明|\n\n| ---------- | ---------- |\n\n|コンポーネント|依存関係の名前とバージョン。|\n\n|パッケージャー| 依存関係のインストールに使用されるパッケージャー。|\n\n|ロケーション|\nシステムの依存関係の場合、スキャンされたイメージのリストが表示されます。アプリケーションの依存関係の場合、依存関係を宣言したプロジェクト内のパッケージャー固有のロックファイルへのリンクが表示されます。また、トップレベルの依存関係への依存関係パスも表示されます（該当の依存関係が存在する場合）。| \n\n|ライセンス| 依存関係のソフトウェアライセンスへのリンク依存関係で検出された脆弱性の数を示す警告バッジ。| \n\n|プロジェクト|\n依存関係のあるプロジェクトへのリンク。同じ依存関係を持つプロジェクトが複数ある場合、プロジェクトの合計数が表示されます。依存関係のあるプロジェクトに移動するには、プロジェクトの番号を選択し、その名前を検索して選択します。プロジェクト検索機能は、グループ階層内に最大600件のプロジェクトがあるグループでのみサポートされています。|\n\n\n\u003Cp>\u003C/p>\n\n\n詳細については、[依存関係リストのドキュメント](https://docs.gitlab.com/ee/user/application_security/dependency_list/)を参照してください。\n\n\n### セキュリティとコンプライアンスの管理\n\n\nGitHub Advanced\nSecurityを使用すると、セキュリティメトリクスとインサイトを閲覧し、コードセキュリティリスクを評価できます。次に、GitLab\nUltimateで同じことをする方法を見てみましょう。\n\n\n#### セキュリティメトリクスとインサイトの閲覧\n\n\nGitLabは、アプリケーションのセキュリティ状況を評価するのに役立つ[セキュリティダッシュボード](https://docs.gitlab.com/ee/user/application_security/security_dashboard/)を提供しています。ダッシュボードには、プロジェクトで実行されたセキュリティスキャナーによって検出された脆弱性のメトリクス、評価、チャートがまとめて表示されます。\n\n\n- グループ内のすべてのプロジェクトの30日、60日、90日間の期間にわたる脆弱性の傾向\n\n- 脆弱性の重大度に基づく各プロジェクトの評価（A~Fの文字グレード評価）\n\n- 過去365日以内に検出された脆弱性の総数とその重大度\n\n\nセキュリティダッシュボードにアクセスする方法：\n\n\n1. 左側のサイドバーで、**検索または移動先...** を選択し、プロジェクトまたはグループを見つけます。\n\n2. サイドタブから、**セキュリティ > セキュリティ** ダッシュボードを選択します。\n\n3. 必要なものを絞り込んで検索します。\n\n\nグループビューには、グループ内のすべてのプロジェクトのセキュリティ状況が表示されます。\n\n\n![グループセキュリティダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\n\nプロジェクトビューには、あるプロジェクトのみのセキュリティ体制が表示されます。\n\n\n![プロジェクトセキュリティダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n\n#### コードのセキュリティリスクを評価\n\n\nGitLab\nUltimateは、デフォルトブランチのスキャン結果から脆弱性に関する情報を提供する[脆弱性レポート](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)を備えています。レポートには、パイプラインが成功したかどうかにかかわらず、すべての成功したジョブの累積結果が含まれます。すべてのレベルで、脆弱性レポートには次が表示されます。\n\n\n- 重大度レベルごとの脆弱性の合計\n\n- 一般的な脆弱性の属性のフィルター\n\n- 表形式のレイアウトで表示される各脆弱性の詳細\n\n\n![脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\n\n脆弱性をクリックすると、その[脆弱性ページ](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/)にアクセスできます。このページには、脆弱性の説明、ロケーション、識別子などの情報が記載されています。以下は、SASTスキャナーによって検出されたSQLインジェクションの脆弱性のページの例です。\n\n\n![SQLインジェクションの脆弱性ページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/11-Vulnerability-Page-1.png)\n\n\nここから、セキュリティチームは、[理由とともに脆弱性の状態を変更](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability)し、[変更をより適切に追跡するためのイシューを作成する](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability)ことでコラボレーションできます。\n\n\n脆弱性のページから、AI搭載の各機能が集約された[GitLab\nDuo](https://about.gitlab.com/ja-jp/gitlab-duo/)を活用して脆弱性を説明し、[脆弱性を解決するマージリクエストを自動的に作成する](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution)こともできます。\n\nGitLab\nDuoの[脆弱性の説明](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation)は、大規模な言語モデルを使用して次を行います。\n\n\n- 脆弱性を要約する\n\n- 脆弱性について、どのように悪用される可能性があるか、どのように修正するかをデベロッパーやセキュリティアナリストが理解できるようにする\n\n- 緩和策を推奨する\n\n\n![SQLインジェクションGitLab Duo\nAIの説明](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/13-Explain-Vulnerability.png)\n\n\n## GitLab Ultimateのセキュリティ追加機能\n\n\nGitLab Ultimateには、GitHub Advanced\nSecurityにはない多くのセキュリティ機能を搭載しています。追加のセキュリティ機能の例として、ソフトウェア開発ライフサイクル（SDLC）全体のための追加のセキュリティスキャナー、きめ細かいセキュリティガードレール、カスタム権限などが挙げられます。\n\n\n### SDLC全体のセキュリティスキャナー\n\n\n当社のセキュリティスキャナーのポートフォリオは、SDLC全体に対応しています。\n\n\n|スキャナー名|スキャン|スキャンされた言語/ファイル|\n\n| -------------- | ----- | ------------------------- |\n\n|\n[静的アプリケーションセキュリティテスト（SAST）](https://docs.gitlab.com/ee/user/application_security/sast/)|静的ソースコード|\nC/C++、Java、Python、Go、JavaScript、C #など|\n\n|\n[動的アプリケーションセキュリティテスト（DAST）](https://docs.gitlab.com/ee/user/application_security/dast/)|\nWebアプリケーション、ライブAPIの実行|言語に依存しない|\n\n|[Infrastructure as\nCode（IaC）のスキャン](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)|\nIaCファイル| Terraform、AWS Cloud Formation、Ansibleなど|\n\n|\n[コンテナのスキャン](https://docs.gitlab.com/ee/user/application_security/container_scanning/)|静的および実行中のコンテナイメージ|\nDockerfile |\n\n|\n[依存関係のスキャンとライセンスのスキャン](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)|アプリケーションの依存関係|\nRequirements.txt、Yarn、Gradle、Npmなど|\n\n| [Web\nAPIファズテスト](https://docs.gitlab.com/ee/user/application_security/api_fuzzing)|ランダム/不正な形式のデータをweb\n- apiに送信| OpenAPI、GraphQL、HAR、Postman Collection |\n\n|[カバレッジ -\nガイド付きファズテスト](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)|ランダム/不正な形式のデータを関数に送信|\nC/C++、Go、Swift、Python、Rust、Java、JavaScript、AFL |\n\n\n\u003Cp>\u003C/p>\n\n\nGitLabでは、[サードパーティのスキャナー（英語）](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)と[カスタムスキャナー（英語）](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/)をプラットフォームに統合することもできます。スキャナーの結果は、パイプラインビュー、マージリクエストウィジェット、セキュリティダッシュボードなど、GitLabのさまざまな場所に自動的に表示されます。詳細については、[セキュリティスキャナー統合ドキュメント](https://docs.gitlab.com/ee/development/integrations/secure.html)を参照してください。\n\n\n### きめ細かいセキュリティとコンプライアンスポリシー\n\n\nGitLabのポリシーは、セキュリティとコンプライアンスの両チームに[組織内でグローバルに制御を実施する方法（英語）](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)を提供します。セキュリティチームは次のことを保証できます。\n\n\n- 適切な設定で開発チームのパイプラインにセキュリティスキャナーを実施\n\n- すべてのスキャンジョブは、変更や修正なしで実行\n\n- これらの調査結果に基づき、マージリクエストに対して適切な承認を提供\n\n\n![マージリクエストのセキュリティポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/14-MR-Policy.png)\n\n\nコンプライアンスチームは、すべてのマージリクエストに対して複数の承認者を必須とし、マージリクエストやリポジトリの設定を有効化またはロックするなど、組織の要件に基づくプロジェクトでさまざまな設定が有効になっていることを確認できます。詳細については、[GitLabセキュリティポリシーのドキュメント](https://docs.gitlab.com/ee/user/application_security/policies/)を参照してください。\n\n\n### カスタムロールときめ細かい権限\n\n\n[GitLab\nUltimateはカスタムロールを提供します（英語）](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/)。これにより、組織はニーズに見合った正確な特権と権限を持つユーザーロールを作成できます。\n\n\nたとえば、ユーザーはシステム内のセキュリティの脆弱性を表示する権限を持つ「セキュリティ監査担当者」ロールを作成できますが、この権限ではソースコードを表示したり、リポジトリ内で変更を実行したりできないよう設定できます。このきめ細かい権限設定により、職務の棲み分けを明確にできます。\n\n\n![カスタムロールの作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\n\n詳細については、[カスタムロール](https://docs.gitlab.com/ee/user/custom_roles.html)および[利用可能な詳細な権限のドキュメント](https://docs.gitlab.com/ee/user/custom_roles/abilities.html)を参照してください。\n\n\n### コンプライアンスセンター\n\n\nコンプライアンスチームが、コンプライアンス基準の遵守状況や違反についての報告、グループのコンプライアンスフレームワークの管理などを一括して行う場所がコンプライアンスセンターです。コンプライアンスセンターには次の内容があります。\n\n\n-\n[コンプライアンス基準遵守ダッシュボード](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html)は、GitLab標準に準拠したプロジェクトの遵守状況を一覧表示します。\n\n-\n[コンプライアンス違反の報告](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html)は、グループ内のすべてのプロジェクトのマージリクエストアクティビティの概要を表示します。\n\n-\n[コンプライアンスフレームワークのレポート](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html)は、グループ内のコンプライアンスに関するすべてのフレームワークを表示します。\n\n-\n[コンプライアンスプロジェクトのレポート](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html)は、グループ内のプロジェクトに適用されるコンプライアンスのフレームワークを表示します。\n\n\n![コンプライアンスセンター](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\n\nこれらのダッシュボードは、組織内のコンプライアンスを最適化するために、職務の棲み分けがきちんと守られているかを確認する上で有益です。詳細については、[コンプライアンスセンターのドキュメント](https://docs.gitlab.com/ee/user/compliance/compliance_center/)を参照してください。\n\n\n## 続きを読む\n\n\nこの記事では、GitLab Ultimateが提供する幅広いセキュリティ機能の一部についてのみ説明しています。GitLab\nUltimateが組織のセキュリティとデベロッパーの効率を向上させる方法について、詳しくは次のリソースを参照してください。\n\n\n- [Ultimateを選ぶ理由](https://about.gitlab.com/ja-jp/pricing/ultimate/)\n\n-\n[DevSecOpsチュートリアルを始める](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n\n-\n[DevSecOpsサンプルプロジェクトの始め方](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n\n-\n[プロジェクトをGitHubからGitLabドキュメントにインポートする](https://docs.gitlab.com/ee/user/project/import/github.html)\n\n- [GitHub\nActionsドキュメントからの移行](https://docs.gitlab.com/ee/ci/migration/github_actions.html)\n\n- [チュートリアル：最初のGitLab\nCI/CDパイプラインを作成して実行する](https://docs.gitlab.com/ee/ci/quick_start/)\n\n-\n[チュートリアル：複雑なパイプラインを作成する](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)\n\n- [CI/CD YAML構文リファレンス](https://docs.gitlab.com/ee/ci/yaml/)\n\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[680,995,9,706,935],"zero trust","2024-12-25",{"slug":998,"featured":90,"template":683},"migration-guide-github-advanced-security-to-gitlab-ultimate","content:ja-jp:blog:migration-guide-github-advanced-security-to-gitlab-ultimate.yml","Migration Guide Github Advanced Security To Gitlab Ultimate","ja-jp/blog/migration-guide-github-advanced-security-to-gitlab-ultimate.yml","ja-jp/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"_path":1004,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1005,"content":1009,"config":1017,"_id":1019,"_type":13,"title":1020,"_source":15,"_file":1021,"_stem":1022,"_extension":18},"/ja-jp/blog/monday-merge-2025-august-11",{"config":1006,"title":1007,"description":1008},{"noIndex":6},"Monday Merge 8月号","Monday Merge8月号では、",{"date":1010,"title":1007,"category":891,"tags":1011,"body":1013,"authors":1014,"description":1015,"heroImage":1016},"2025-08-11",[108,675,774,677,269,707,678,279,679,891,1012,9,708],"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)",[701],"AIエージェント、新機能、そして7,500億ドルの可能性に注目\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754368844/vagh8krfgft9cghbknod.png",{"featured":90,"template":683,"slug":1018},"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":1024,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1025,"content":1029,"config":1033,"_id":1035,"_type":13,"title":1036,"_source":15,"_file":1037,"_stem":1038,"_extension":18},"/ja-jp/blog/monday-merge-2025-july-14",{"noIndex":6,"ogImage":1026,"title":1027,"description":1028},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752204420/ccdkkhlyrjmyjxsicf7d.jpg","Monday Merge 7月号","Monday Merge７月号では、GitLab 18の最新トピックのほか、AWS Summit、新しいライブ番組のスタート、そして注目のカスタマーストーリーをご紹介します。",{"date":669,"body":1030,"title":1027,"category":891,"heroImage":1026,"authors":1031,"description":1028,"tags":1032},"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)",[701],[108,675,774,677,269,707,678,279,679,891,1012,9,708],{"featured":6,"template":683,"slug":1034},"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":1040,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1041,"content":1047,"config":1052,"_id":1054,"_type":13,"title":1055,"_source":15,"_file":1056,"_stem":1057,"_extension":18},"/ja-jp/blog/monday-merge-2025-june-9",{"title":1042,"description":1043,"ogTitle":1042,"ogDescription":1043,"noIndex":6,"ogImage":1044,"ogUrl":1045,"ogSiteName":696,"ogType":697,"canonicalUrls":1045,"schema":1046},"🌞 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":1042,"description":1043,"authors":1048,"heroImage":1044,"date":1049,"body":1050,"category":891,"tags":1051},[701],"2025-06-09","みなさん、こんにちは！6月のMonday Mergeにようこそ。今回も最新情報をお届けします！\n\n大規模アップデートや新しいAI機能、次のスプリントに役立つDevSecOpsインサイトが満載です。今月の注目ポイント？それは GitLab 18の正式リリースです。しかも今回から、PremiumおよびUltimateのすべてのお客様が、GitLab Duoの主要なAI機能を追加料金なしでご利用可能になりました。\n\nそれでは、さっそく見ていきましょう👇\n\n## GitLab 18：GitLabにとっての小さな一歩、DevSecOpsにとっての大きな飛躍\n![gitlab 18](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/image6.png)\n\nGitLab 18.0のリリースでは、PremiumとUltimateプランにGitLab Duoが標準搭載され、AIネイティブなDevSecOpsの新たな時代が始まります。\n\n### 新機能ハイライト\n\n* Duoコード提案 & GitLab Duo ChatがIDEで利用可能に：コードの記述から理解、リファクタリング、テストまでリアルタイムで支援します。  \n* リポジトリX-Ray（Self-Hostedはベータ版）：リポジトリ構造とコードの健全性を可視化します。  \n* GitLab Duoコードレビューの自動有効化：すべてのマージリクエストにAIレビューを適用。  \n* プロンプトキャッシュ機能：AI応答の遅延を軽減し、スムーズなやり取りを実現。\n\n最新のグローバルDevSecOps調査では、デベロッパーがコード以外の作業に79％もの時間を費やしていることが明らかになりました。つまり、AIを“コード支援”のみに使っているだけでは、AIの真の力を活かしきれていません。GitLab 18では、ソフトウェア開発ライフサイクル全体にAIを組み込み、面倒な作業を減らして本質的なイノベーションに集中できる環境を提供します。\n\nこのリリースを可能にしたのは、世界中の素晴らしいコミュニティの力です。328件のコントリビュートにより支えられたGitLab 18は、まさに「使う人たちによって作られた」リリースです。\n\n今月の注目コントリビューターは、Adfinis社CTOのMichael Hoferさん。GitLabのGeo機能やSecrets Managerの改善など、本当にたくさんの貢献をしてくださいました。オープンソースにかける想いと、周囲を巻き込む力に、私たちもたくさんの学びをもらっています。\n\n👉 [GitLab 18 リリースノート全文を読む](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)\n\n## 事例のご紹介：Ignite by FORVIA HELLA\n![ignite](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/image3.png)\n\nソフトウェアが自動車産業の中核となる今、[Ignite by FORVIA HELLA](https://www.linkedin.com/company/ignite-by-forvia-hella/)は次世代車両開発のために、ベルリンを拠点とするソフトウェア・イノベーションハブ Ignite を立ち上げました。\n\nCTOのFelix Kortmann氏はGitLab Duoについてこう語ります。\n\n「Duoのインテリジェントなコード提案は、デベロッパーにとって日常の必需品です。チャット機能と組み合わせることで、即座のフィードバックと反復が可能になり、開発サイクルが短縮され、コードの安全性も向上しました。私たちのワークフローに、シームレスかつ強力に統合されています」\n\nGitLab CI/CDとAI機能を組み合わせることで、Igniteは反復テストや品質チェックを自動化。コードがpushされた瞬間に自動処理が走り、早期の課題検出とスピーディーなデリバリーを実現しています。\n\n## GitLab 18のローンチイベントがバーチャルで開催！しかもアジア時間に！さらに日本語字幕付き！\n\n2025年6月24日（火）13時より、GitLab 18の新機能を紹介するグローバルオンラインイベントを開催します。\n\n### ✨ イベント内容\n\n* GitLab 18の新機能を実演するライブデモ  \n* GitLabのリーダーたち（Bill Staples、Sabrina Farmer、Josh Lemos、David DeSantoほか）によるインサイト共有  \n* 新ライブシリーズ「The Developer Show」の初公開： コーディングデモ、プロダクト解説、コミュニティのストーリーをお届け！\n\nご都合の良い時間帯を選んでぜひご参加ください。質問も大歓迎です！\n\n👉 [今すぐイベント登録する](https://about.gitlab.com/eighteen/)\n\n## GitLab Duo、Premiumにも標準搭載\n\nGitLab 18のリリースにより、Duoの主要機能がPremiumおよびUltimateで標準提供されます。追加ツールも、追加費用も不要。IDE上でスマートな開発がすぐに始められます。\n\n### 機能ハイライト\n\n* GitLab Duoコード提案：20以上のプログラミング言語で高速なコード作成・リファクタリング  \n* GitLab Duo Chat：コードの解説、テスト生成、トラブル対応を簡単に\n\nさらに、より高度な機能を求めるチームには、Ultimate限定だったDuo EnterpriseがPremiumでも利用可能に。[GitLab Duo根本原因分析](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases)、GitLab Duo Self-Hosted、AIコードレビューなどが利用できます。\n\n👉 [Duoを有効にして、開発を始めましょう](https://about.gitlab.com/ja-jp/blog/gitlab-premium-with-duo/)\n\n## AWS Summit で直接お会いしましょう！\n![aws summit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687124/Blog/Content%20Images/image1.png)\n\n東京をはじめ、世界各地のAWS SummitにGitLabも出展します！GitLabとAWSの連携機能を体験できるほか、安全なクラウドネイティブ開発の事例もご紹介。もちろん、ノベルティもご用意しています！\n\n🗓️ 6月のイベント予定\n\n* シドニー｜6月4日〜5日  \n* ストックホルム｜6月4日  \n* ハンブルク｜6月5日  \n* マドリード｜6月11日  \n* ミラノ｜6月18日  \n* ムンバイ｜6月19日  \n* 東京｜6月25日〜26日\n\n👉 [AWS Summit 2025でお会いできるのを楽しみにしています！](https://about.gitlab.com/ja-jp/events/aws-summits/)\n\n## 今月のおすすめ読書\n![08 Header Images April What We’re Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/08_LinkedIn_Header_Images_April_What_We_re_Reading.png)\n\n* **A Practical Roadmap for Adopting Vibe Coding（Vibe Coding 導入のための実践ロードマップ）**\nスピードを重視するあまり、品質や保守性が犠牲にならないよう、適切なガバナンスが必要だとGitLabの戦略VPであるEmilio Salvadorが解説。\n\n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/a-practical-roadmap-for-vibe-coding-adoption/)\n\n* **3 ways APAC engineering teams can operationalise AI（APACの開発チームがAIを活用する3つの方法）**  \nAPACのエンジニアリングチームによる日常業務へのAI統合、業務効率化、抵抗感の軽減、ビジネス価値の可視化についてGitLabのCTOであるSabrina Farmerが説明します。  \n🔗 [Frontier Enterpriseの記事を読む](https://www.frontier-enterprise.com/3-ways-apac-engineering-teams-can-operationalise-ai/)  \n\n* **Beyond Culture: Addressing Common Security Frustrations（文化を越えて：セキュリティ課題の根本に向き合うには）**  \n文化づくりも重要ですが、開発とセキュリティの基本設計から見直す必要があります。GitLab最高情報セキュリティ責任者のJosh Lemosによる解説記事。  \n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/beyond-culture-addressing-common-security-frustrations/)  \n\n* **The Field CTO View: AI, Vibe Coding, and Developer Skillsets（フィールドCTOの視点：AIとVibe Coding、デベロッパーのスキルセットのこれから）**\n企業のIT部門ではAIがどう実装されているのか？ デベロッパーの適応はどう進んでいるのか？GitLabのフィールドCTO部門責任者が答えています。  \n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/the-field-cto-view-ai-vibe-coding-and-developer-skillsets/)\n\n## 今月のひとこと\n\n最後に、私が心に留めている言葉をシェアします。完璧を目指すよりも、まずは一歩を踏み出すこと。大きなアイデアは、小さな行動から始まります。\n\n「何かを始める方法は、話すのをやめて行動することだ」– ウォルト・ディズニー\n\nこれからも、ひとつずつマージを重ねながら、学び、作り、そして成長していきましょう 💜\n\n🦊 また次回まで！\n\nGitLabコミュニティの一員でいてくださり、ありがとうございます！みなさんがGitLab 18でどんなものを作ってくださるのか、私たちも楽しみにしています。バーチャルイベントの登録と、AI機能の活用開始もお忘れなく。それではまた次回のMonday Mergeでお会いしましょう。Happy Merging!\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | GitLab Developer Advocate\n![SignOffBanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/SignOffBanner.png)",[1012,678,675,730,9,891,279,233,774,708,677,269],{"slug":1053,"featured":6,"template":683},"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":1059,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1060,"content":1066,"config":1071,"_id":1073,"_type":13,"title":1074,"_source":15,"_file":1075,"_stem":1076,"_extension":18},"/ja-jp/blog/monday-merge-2025-may-9",{"title":1061,"description":1062,"ogTitle":1061,"ogDescription":1062,"noIndex":6,"ogImage":1063,"ogUrl":1064,"ogSiteName":696,"ogType":697,"canonicalUrls":1064,"schema":1065},"🌞 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":1061,"description":1062,"authors":1067,"heroImage":1063,"date":1068,"body":1069,"category":891,"tags":1070},[701],"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",[1012,678,675,730,9,891,279,233,774,708,677,269],{"slug":1072,"featured":90,"template":683},"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":1078,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1079,"content":1084,"config":1091,"_id":1093,"_type":13,"title":1094,"_source":15,"_file":1095,"_stem":1096,"_extension":18},"/ja-jp/blog/monday-merge-2025-september-8",{"config":1080,"title":1081,"ogImage":1082,"description":1083},{"noIndex":6},"Monday Merge 9月号","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756904278/ov1n66vq8dnikcjyu0iw.png","最新リリース、注目のホワイトペーパー、そして大規模なDevSecOpsの取り組み事例をお届け。",{"title":1085,"authors":1086,"heroImage":1082,"date":1087,"category":891,"tags":1088,"body":1089,"description":1090},"Monday Merge 9月号：より速いパイプライン、もっと賢いエージェント、そしてより大きな成果を！",[701],"2025-09-08",[675,108,677,269,707,678,279,679,891,1012,9,708],"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":683,"slug":1092},"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":1098,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1099,"content":1105,"config":1112,"_id":1114,"_type":13,"title":1115,"_source":15,"_file":1116,"_stem":1117,"_extension":18},"/ja-jp/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab",{"title":1100,"description":1101,"ogTitle":1100,"ogDescription":1101,"noIndex":6,"ogImage":1102,"ogUrl":1103,"ogSiteName":696,"ogType":697,"canonicalUrls":1103,"schema":1104},"大手EC会社のBol社がGitLabでコンプライアンス管理に成功した事例","ヨーロッパの大手EC会社が常に変化するコンプライアンスに、GitLabでどのように対処しているかを事例を通してご紹介します。ぜひお読みください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665465/Blog/Hero%20Images/blog-image-template-1800x945__15_.png","https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"大手EC会社のBol社がGitLabでコンプライアンス管理に成功した事例\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julie Griffin\"}],\n        \"datePublished\": \"2024-06-12\",\n      }",{"title":1100,"description":1101,"authors":1106,"heroImage":1102,"date":1108,"body":1109,"category":704,"tags":1110,"updatedDate":1111},[1107],"Julie Griffin","2024-06-12","国際的な大手小売業のBol社がGitLabを利用して、どのように開発効率化とソフトウェア規制遵守を実現しているのかご紹介します。\n\n[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)プランを利用しているBol社は、オランダとベルギーにおける最大級のオンライン小売業（EC会社）です。同社のマーケットプレイスでは、5万ものパートナーが商品を販売しており、商品ラインナップ数は3,800万点に上ります。同社は革新的なテクノロジーを利用することで開発効率を向上させ、めまぐるしく変化するソフトウェアのコンプライアンス規制を遵守し、広範な顧客基盤からの信頼を維持しています。\n\n## BolがGitLabによってコンプライアンス管理に成功した事例\n\nBol社はGitLabの[DevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/platform/)を自社チームに導入し、デベロッパーが迅速かつ安全にプロジェクトを完了できるようにすると同時に、手動で行っていたコンプライアンスチェックにかかる工数を数千時間から大幅に削減しました。\n\nBol社の収益が増加するにつれて、同社が遵守しなければならないコンプライアンスルールや規制も増加しました。一般データ保護規則 （GDPR）や国際標準化機構 （ISO）の要件、EU人工知能法など、厳格で頻繁に更新される規制に準拠するためには、ソフトウェアを継続的に適応させる必要があります。\n\nBol社のCI/CD開発チームエンジニアリングマネージャであるGuus Houtzager氏は、次のように述べています。\n\n「GitLabは、当社が成長し、ソフトウェアとデベロッパーが順守すべき要件が増大する中で、柔軟性と競争力の維持に大きく貢献しています。私たちが抱えていたこれら最大の課題に対し、GitLabを活用することで解決を図りました。」\n\nBol社は2016年に[GitLabコミュニティ](https://about.gitlab.com/community/)に参入し、その数年後に[GitLab Premium](https://about.gitlab.com/ja-jp/pricing/premium/)を導入、2024年にはGitLab Ultimateにアップグレードしました。これにより、コンプライアンスの負荷増に対応するとともに、チームがより迅速かつ効率的にプロジェクトに取り組むことができる基盤を作り上げてきました。\n![bol社のGitLabに対するコメント](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675638/Blog/Content%20Images/bol_Blog_-_Guus.png)\n\n## 毎月数千時間の開発時間の節約 \n\nGitLabを活用することで、Bol社のDevSecOpsチームはコンプライアンス設定とチェックを自動化するポリシーを設定できます。これにより、[コンプライアンスへの取り組みに関する一貫性と拡張性を実現](https://about.gitlab.com/ja-jp/solutions/security-compliance/)し、人為的エラーによるリスクを軽減できます。コンプライアンスのガードレールが設定されたことで、850人の開発者チームは革新的で安全なソフトウェアの開発により多くのエネルギーを注ぐことができます。\n\nHoutzager氏は、次のように語りました。  \n「GitLab Ultimateを導入したことで、初めからコンプライアンス規制の範囲内で仕事ができるという強制的なコンプライアンスパイプラインを作ることができます。これにより、デベロッパーの作業時間を月間で数千時間ほど節約できました。」\n\nデベロッパーがコンプライアンス規制の負担を気にする必要がなくなり、コーディングに集中できるようになったことで、Bol開発チームの効率は飛躍的に向上しました。時間の節約だけでなく、チームは将来のコンプライアンス規制にも対応できると自信を持つようになりました。\n\nHoutzager氏はさらに続けます。  \n「私たちは、GitLabがコンプライアンスとソフトウェアセキュリティの両方に役立つことを信じています。GitLabには新しい規制に従って構築できるツールキットがあります。将来のことは誰にもわかりませんが、たとえ新しい規制が増えたとしても、GitLabであればどのような事態にも対処できると考えています。」  \n\n## 顧客と事業を守るためのシフトレフト\n\nヨーロッパ小売業界大手の1つであるBol社にとって、「信頼」はビジネスモデルの重要な柱です。同社は住所や注文明細など大量の個人データを取り扱っています。規制による罰金が懸念される一方で、、顧客からの信頼維持も重要な課題です。セキュリティの重要性は言うまでもありません。\n\nHoutzager氏は次のように述べました。  \n「オランダやベルギーのほとんどの住民が、これまでにBol社での購買経験があり、私たちを信頼してくれています。彼らは弊社が顧客の支払い情報を適切に扱うと信じています。弊社がお客様の個人識別情報（PIIデータ）を販売したりせず、データを安全に保管していると信じています。」\n\n顧客データとビジネスを保護するために、Bol社はシフトレフトセキュリティを導入し、デベロッパーが開発プロセスの早い段階でエラーや脆弱性を発見できるようにしました。しかし、適切なツールを使用せずにシフトレフトすると、発見した問題を修正するためにデベロッパーが膨大な時間を費やすことになる可能性があります。\n\nHoutzager氏はシフトレフトの実施について、次のように説明を加えました。  \n「チームが作業を効率的に実行できるようにするツールやサポート、プロセスを提供しないままでシフトレフトすると、チームは手順や手作業において困難を抱えます。」\n\nGitLab Ultimateを利用すれば、同社のセキュリティ要件を満たすレイアウトや権限モデルを設定できるため、デベロッパーは顧客とビジネスデータを保護しながら、プロジェクトを迅速に立ち上げリリースできます。また、DevSecOpsプラットフォームには、デベロッパーが行った変更や修正を追跡し、コンプライアンスレコードに記録するという機能もあります。\n\n## AIとともに見据える未来\n\nBol社は今後、クラウド統合や人工知能 (AI) 機能、セキュリティ機能など、GitLab Ultimateをさらに活用していく予定です。\n\n同社は、AI機能が搭載された[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)がソフトウェア開発のスケールアップを支援してくれると期待しています。GitLab Duoは、安全ななソフトウェアの迅速な構築からデベロッパーエクスペリエンスの向上まで幅広く貢献します。\n\nHoutzager氏は、AIの可能性と利用条件について、次のように述べています。  \n「私たちがAIを使うには、状況が整っている必要があります。そして、AIがどのように役立つかを必ず検討します。他の企業の皆さんと同じように、ソフトウェア開発のライフサイクル全体を見通しながら、AIによって改善できる箇所を探しています。例えば、コード作成の場面や一連のプロセスの他の場面で、どのようにAIを活用できるかなどを常に考えています。」\n\n> GitLabのさらなる魅力については、 [GitLabを選ぶ10の理由](https://about.gitlab.com/ja-jp/why-gitlab/)をご覧ください。\n",[108,9,707,706],"2024-11-28",{"slug":1113,"featured":6,"template":683},"online-retailer-bol-tackles-growing-compliance-needs-with-gitlab","content:ja-jp:blog:online-retailer-bol-tackles-growing-compliance-needs-with-gitlab.yml","Online Retailer Bol Tackles Growing Compliance Needs With Gitlab","ja-jp/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab.yml","ja-jp/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab",{"_path":1119,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1120,"content":1126,"config":1135,"_id":1137,"_type":13,"title":1138,"_source":15,"_file":1139,"_stem":1140,"_extension":18},"/ja-jp/blog/the-ultimate-guide-to-sboms",{"title":1121,"description":1122,"ogTitle":1121,"ogDescription":1122,"noIndex":6,"ogImage":1123,"ogUrl":1124,"ogSiteName":696,"ogType":697,"canonicalUrls":1124,"schema":1125},"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":1121,"description":1122,"authors":1127,"heroImage":1123,"date":1129,"body":1130,"category":9,"tags":1131,"updatedDate":1134},[1128],"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合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*",[9,678,1132,1133,186],"performance","open source","2025-06-10",{"slug":1136,"featured":6,"template":683},"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":1142,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1143,"content":1149,"config":1155,"_id":1157,"_type":13,"title":1158,"_source":15,"_file":1159,"_stem":1160,"_extension":18},"/ja-jp/blog/the-ultimate-guide-to-token-management-at-gitlab",{"title":1144,"description":1145,"ogTitle":1144,"ogDescription":1145,"noIndex":6,"ogImage":1146,"ogUrl":1147,"ogSiteName":696,"ogType":697,"canonicalUrls":1147,"schema":1148},"GitLabにおけるトークン管理の究極ガイド","ソフトウェア開発ライフサイクル全体のセキュリティを向上させるために、トークンを特定、管理、保護するためのエンドツーエンドのプロセスをすべてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-token-management-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabにおけるトークン管理の究極ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hakeem Abdul-Razak\"}],\n        \"datePublished\": \"2025-02-25\",\n      }",{"title":1144,"description":1145,"authors":1150,"heroImage":1146,"date":1152,"body":1153,"category":9,"tags":1154},[1151],"Hakeem Abdul-Razak","2025-02-25","深夜2時、成長中のテック企業でエンジニアとして働いているあなたに、緊急の電話がかかってきました。重要なデプロイパイプラインが失敗し、チームはその原因を突き止めようと必死です。数時間後、1週間前に退職したエンジニアのパーソナルアクセストークンが失効していたことが判明します。そのトークンは複数の重要な自動化プロセスで使用されており、その影響でシステム全体が混乱状態に陥ってしまいました。これを防ぐためには、どのようにトークンを管理すべきなのでしょうか？\n\n\nこのガイドでは、トークンを適切に特定、管理、保護するためのエンドツーエンドのプロセスをご紹介します。このガイドは、プロジェクト内でのトークン管理を徹底したいGitLabの管理者、デベロッパー、セキュリティチームに向けて、[トークンに関する詳しい文書](https://docs.gitlab.com/ee/security/tokens)を補う参考資料として活用いただけます。\n\n\nこのガイドでは、以下の内容を取り上げています。\n\n- [ジョブに適したトークンの選び方](#how-to-select-the-right-token-for-the-job)\n\n- [トークンの種類](#token-types)\n\n- [自分が使用しているトークンの把握方法](#discovering-your-tokens)\n    - [認証情報インベントリ](#credentials-inventory)\n- [GitLab UIおよびAPIでのトークン管理](#managing-tokens-in-the-gitlab-ui-and-api)\n\n- [トークンのローテーションと有効期限の管理](#token-rotation-and-expiration-management)\n\n- [トークン管理のベストプラクティス](#token-management-best-practices)\n    - [サービスアカウント](#service-accounts)\n\n## ジョブに適したトークンの選び方\n\n\nユースケースに合ったトークンを選ぶことで、セキュリティと機能性の両面で最適な運用が可能になります。\n\nトークンは、APIリクエストの認証、CI/CDパイプラインの自動化、サードパーティツールとの統合、デプロイやリポジトリの管理など、幅広い場面で活用できます。\n\n\n![トークン管理ガイド -\nトークンのフローチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097434869.png)\n\n\nわかりやすさを重視し、この図では1人のユーザーがトークンを所有するシンプルなユースケースを例にしています。詳細については、インスタンスまたはトップレベルグループの各[ネームスペース](https://docs.gitlab.com/ee/user/permissions.html)（ユーザー/グループ）におけるユーザーロールや権限に関するGitLabの文書をご参照ください。以下のようなユースケースが考えられます。\n\n\n- **パーソナルアクセストークン**（[PAT]\n(https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes)）：デベロッパーがユーザーの個人アクセスや権限を必要とする場合に使えるトークンです。このトークンは、ユーザーのステータスと権限に従って認証情報が管理されるため、ユーザーが特定のプロジェクトやグループへのアクセス権を失った場合や、アカウントが無効化された場合には、自動的にそのトークンも無効になります。\n\n-\n**プロジェクト/グループアクセストークン**（[PrAT](https://docs.gitlab.com/user/project/settings/project_access_tokens/#scopes-for-a-project-access-token)/[GrAT](https://docs.gitlab.com/user/group/settings/group_access_tokens/#scopes-for-a-group-access-token)）：特定のプロジェクトまたはグループ内でのリソースへのアクセスを制限する必要がある場合に適したトークンです。PrAT/GrATを持つユーザーは、割り当てられたスコープを通じてこれらのリソースにアクセスできるようになります。\n\n\n## トークンの種類\n\n\nこちらは、GitLabトークンの種類と、それぞれのデフォルトのプレフィックスおよびユースケースの一覧です。詳細については、[GitLabトークンの概要ページ](https://docs.gitlab.com/ee/security/tokens/#available-scopes)をご覧ください。\n\n\n| トークン | プレフィックス | 説明 |\n\n| :---: | :---: | :---: |\n\n| パーソナルアクセストークン | glpat | ユーザー固有のデータにアクセス |\n\n| OAuth 2.0トークン | gloas | OAuth2.0 認証プロトコルを使ったサードパーティアプリとの連携 |\n\n| なりすましトークン | glpat | 他のユーザーの代わりに管理操作を実行 |\n\n| プロジェクトアクセストークン | glpat | 特定のプロジェクトのデータにアクセス |\n\n| グループアクセストークン | glpat | 特定のグループのデータにアクセス |\n\n| デプロイトークン | gldt | ユーザー名とパスワードなしでプロジェクトのコンテナイメージをクローン、プッシュ、プル |\n\n| デプロイキー | 該当なし | リポジトリへの読み取り専用または読み書きアクセスを許可 |\n\n| Runner認証トークン | glrt | GitLab Runnerを認証 |\n\n| CI/CDジョブトークン | glcbt | CI/CDプロセスを自動化 |\n\n|トリガートークン| glptt | パイプラインを手動またはプログラムでトリガー |\n\n| フィードトークン | glft | パッケージ/RSSフィードへのアクセス認証 |\n\n| 受信メールトークン | glimt | 受信メールの処理 |\n\n| Kubernetes向けGitLabエージェントトークン | glagent |\nGitLabGitLabエージェントを通じてKubernetesクラスターを管理 |\n\n| SCIMトークン | glsoat | SCIMを利用したユーザー管理の統合 |\n\n| 機能フラグクライアントトークン | glffct | プログラムで機能フラグを有効化 |\n\n| Webhookトークン | 該当なし | WebhookのリクエストがGitLabから送信されたことを検証するための秘密トークン（ユーザーが設定）\n|\n\n\n## トークンの確認方法\n\n\n### 認証情報インベントリ\n\n\nGitLab Ultimateでは、GitLab\nSelf-Managedの管理者や、GitLab.com（バージョン17.5以降）における企業組織のトップレベルグループのオーナーが、自身のネームスペース内の認証情報を監視できます。\n\n\nこのインベントリでは、以下のようなトークン情報を確認できます。\n\n\n* トークンの種類\n  * [GitLab.com](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)で利用可能なトークン\n  * [GitLab Self-Managed](https://docs.gitlab.com/ee/administration/credentials_inventory.html)で利用可能なトークン\n* 関連付けられたユーザーアカウント \n\n* トークンのスコープ、および作成日と有効期限 \n\n* 最終使用時のIPアドレス（GitLab 17.10時点）\n\n* 上記のユーザー定義パラメータに基づくトークンのフィルタリング\n\n* トークンの取り消しおよびローテーションの機能\n\n\n認証情報インベントリを適切に管理することで、権限が過剰なトークンの特定や、ローテーションが必要な認証情報の把握が可能になり、安全かつ効率的な運用が実現します。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/A9ONfnwswd0?si=4VIEUgJaD4daj81b&start=105\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n#### 認証情報インベントリAPI\n\n\nUIの機能に加えて、新しい/group/:id/manage[エンドポイント](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project)を通じて認証情報インベントリAPIをリリースするための[開発が進行中](https://gitlab.com/groups/gitlab-org/-/epics/16343)です。このエンドポイントでアクセスできる認証情報は企業[ユーザー](https://docs.gitlab.com/ee/user/enterprise_user/)に限定されており、企業組織のトップレベルグループのオーナーが利用可能です。将来のAPIコールの例は以下のとおりです。\n\n\n```console\n\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\"\n\"https://verified_domain.com/api/v4/groups/\u003Cgroup_id>/manage/personal_access_tokens\"           \n\n```\n\n### GitLab API\n\n\nGitLab\nAPIを使用すると、組織内のトークンをプログラムで一覧表示および管理できます。主要な認証関連エンドポイントは、個人用、グループ用、CI/CDトークンなど、[さまざまなトークンの種類](https://docs.gitlab.com/ee/api/rest/authentication.html)をサポートしています。GitLab上で認証済みユーザーがアクセスできるすべてのプロジェクトを一覧表示する際のパーソナルアクセストークンの使用方法は次のとおりです。\n\n\n```console\n\ncurl --header \"PRIVATE-TOKEN: \u003Cyour_access_token>\" \\\n     \"https://gitlab.example.com/api/v4/projects\"\n\n```\n\n\nGitLab APIへのAPIコールの方法については、次の動画をご覧ください。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0LsMC3ZiXkA?si=vj871YH610jwQdFc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n### トークンの使用場所の確認\n\n\nトークンの使用場所を確認する方法は以下のとおりです。\n\n* **ユーザープロフィール >\n[アクセストークン](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)**\n\n* 認証情報インベントリ\n\n* 監査イベント\n\n* API経由\n\n\nトークンの使用状況に関する情報は、**last_used**は10分ごと、**last_used_ip**は1分ごとに更新されます。\n\n\nIPアドレスの確認機能はGitLab\n17.9で追加され、**:pat_ip**機能フラグにより管理されます。[トークンの最終使用時間](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)と、そのトークンが使われた最後の5つの異なるIPアドレスを表示する方法は以下のとおりです。\n\n\n![トークン管理ガイド -\nパーソナルアクセストークンの設定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097434870.png)\n\n\n## GitLab UIとAPIにおけるトークンの管理\n\n以下の表には、UIにおけるトークン作成の詳細と、APIを介したトークンの使用方法を示すビデオが含まれています。\n\n\n| トークン | GitLab UI | GitLab API |\n\n| ---------- | ---------- | ---------- |\n\n| パーソナルアクセストークン |\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=3)\n|\n[ドキュメント](https://docs.gitlab.com/ee/api/personal_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=43)\n|\n\n| グループアクセストークン |\n[ドキュメント](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=120)\n|\n[ドキュメント](https://docs.gitlab.com/ee/api/group_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=157)\n|\n\n| プロジェクトアクセストークン |\n[ドキュメント](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=254)\n|\n[ドキュメント](https://docs.gitlab.com/ee/api/project_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=285)\n|\n\n\n## トークンのローテーションと有効期限の管理\n\n\nトークンローテーションと厳格な有効期限管理を実施することで、セキュリティリスクを減らし、セキュリティ基準への準拠を確保できます。定期的なローテーションと有効期限の強制により、期限切れの認証情報がセキュリティの脆弱性となるのを防ぎます。\n\n\nこれまで、グループおよびプロジェクトのアクセストークンは、有効期限が切れると自動的に削除されていました。そのため、無効なトークンの記録が残らず、監査やセキュリティレビューを行う上で課題となっていました。この問題に対応するため、[最近のアップデート](https://gitlab.com/gitlab-org/gitlab/-/issues/462217)により、無効化されたグループおよびプロジェクトのアクセストークンの記録が、無効になってからUI上に30日間保持されるようになりました。これにより、トークンの使用状況や有効期限、取り消しの履歴を追跡しやすくなり、コンプライアンスやモニタリングの強化につながります。\n\n\nトークンのローテーションと有効期限の管理をより積極的に行うには、次の手順を実行します。\n\n\n*\nUIまたはAPIを介してトークンを積極的にローテーションする。APIを使用する場合は、[自動的にトークンの再利用を検知](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection)するセキュリティ機能に注意が必要です。\n\n*\nインスタンス全体で、[アクセストークンの最大有効期間](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens)を制限する設定を導入。\n\n\n### トークンローテーションAPI\n\n\nGitLab\n17.7までは、アクセストークンのローテーションはAPIを通じてプログラム上で行う必要がありましたが、現在はUI上でも実行可能になりました。操作方法は以下の表の動画または[ドキュメント](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui)をご確認ください。\n\n\n### トークンローテーションスニペット\n\n\n以下の表には、GitLabトークンのローテーションに関する動画のリンクをまとめています。\n\n\n| トークン | 前提条件 | GitLab UI | GitLab API |\n\n| :---: | :---: | ----- | ----- |\n\n| パーソナルアクセストークン | スコープ：api  |\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=76) \n|\n[ドキュメント](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token)\nと[動画](https://youtu.be/v5Nj3Jy4vaI?t=92)  |\n\n| グループアクセストークン | スコープ：apiと役割：オーナー |\n[ドキュメント](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=203) \n|\n[ドキュメント](https://docs.gitlab.com/ee/api/group_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=214) \n|\n\n| プロジェクトアクセストークン | スコープ：apiと役割：オーナー、メンテナー |\n[ドキュメント](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=335) \n|\n[ドキュメント](https://docs.gitlab.com/ee/api/project_access_tokens.html)と[動画](https://youtu.be/v5Nj3Jy4vaI?t=349) \n|\n\n\n## トークン管理のベストプラクティス\n\n\n### 最小権限の原則\n\n\n各トークンに割り当てる権限を、それぞれのタスクに必要な最小限に制限することで、リスクを軽減します。これにより、システム内の潜在的な障害箇所を事前に予測・対処しやすくなります。以下のような方法で、この原則を実践できます。\n\n\n* それぞれのジョブに合った適切なトークンを選ぶ。フローチャートを参照。\n\n*\nトークンの作成時に必要なスコープのみを割り当てる。たとえば、監査目的のようなジョブには読み取り専用のスコープを使用します。詳細は[ロール](https://docs.gitlab.com/ee/user/permissions.html#roles)を参照。\n\n* 特別な理由がない限り、管理者権限を付与しない。\n\n*\nインスタンス全体でのデフォルトのトークン[有効期限](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1)を設定する。\n\n* トークンの権限を定期的に確認・監査し、運用実態に合っているか見直す。\n\n* タスク完了後は速やかにトークンを無効化する。\n\n\n### サービスアカウント\n\n\n[サービスアカウント](https://docs.gitlab.com/ee/user/profile/service_accounts.html)を使用することで、トークンを人間のユーザーではなく非人間エンティティに紐づけることができ、特定ユーザーへの依存を減らせます。自動化にトークンを使う場合、個人アカウントではなく、スコープを制限したサービスアカウントを作成することが推奨されます。サービスアカウントを使用する主なメリットは次のとおりです。\n\n\n* CI/CDパイプラインでサービスアカウントのトークンを使うことで、ユーザーアカウントの変更による中断を防げる\n\n* 個人アカウントに影響を与えずに、プログラム上でトークンのローテーション処理を自動化できる\n\n* サービスアカウントによる操作のモニタリング・監査がより明確になる \n\n*\n[有効期限のない](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date)サービスアカウントを作成できる\n\n*\n[ライセンスシート](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account)を消費しない\n\nGitLabでは、サービスアカウントとそのトークンの管理をより簡単にするために、[APIベースでの作成](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user)に対応する新しい[サービスアカウントUI](https://gitlab.com/groups/gitlab-org/-/epics/9965)の提供を予定しています。以下のデモでは、サービスアカウントをプログラム上で使用する方法を紹介しています。\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oZvjg0SCsqY?si=cj-0LjfeonLGXv9u\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n### 脆弱性ツール\n\n\nGitLabに組み込まれたセキュリティツールを活用することで、トークンの使用に関連する脆弱性を特定し、リスクを軽減できます。最大限のカバレッジを得るには、各ツールを併用することを推奨します。\n\n\n*\n[シークレット検出](https://docs.gitlab.com/ee/user/application_security/secret_detection/)：リポジトリ内にハードコードされたシークレット（APIトークン、パスワード、その他の機密情報）がないかをスキャンします。[検出されたシークレットの一覧](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html)も確認可能です。\n\n*\n[静的アプリケーションセキュリティテスト（SAST）](https://docs.gitlab.com/ee/user/application_security/sast/)：ソースコードに存在するセキュリティ上の脆弱性を分析し、[マージリクエスト内でUI上のレポートとして表示](https://docs.gitlab.com/ee/user/application_security/sast/#features)するなどの機能を提供します。\n\n*\n[依存関係スキャン](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)：プロジェクトで使用しているサードパーティライブラリに、トークンに関連する脆弱性が含まれていないかを確認します\n\n\n### 監査ログとモニタリング\n\n\nインスタンスまたはグループ単位で、監査ログとトークンの使用状況を定期的に確認することで、トークンの健全性を維持できます。\n\n\n*\n[監査イベント](https://docs.gitlab.com/ee/user/compliance/audit_events.html)：GitLabの監査イベントログを有効にすると、トークンの作成、使用、削除、不審なAPIコール（ログ内の許可されていないパラメーターやレートリミッターの継続的なトリガーなど）を追跡できます。\n\n*\n[IP許可リスト](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions)：悪意のあるユーザーが複数のIPアドレスを使ってアクティビティを隠すことを防ぎます。\n\n*\n[アラート](https://docs.gitlab.com/ee/operations/incident_management/alerts.html)：不審なアクティビティに対してアラートを設定できます（オンコールローテーションに関するページングのトリガーやインシデントの作成に活用可能）。\n\n*\n[認証情報インベントリ](https://docs.gitlab.com/ee/administration/credentials_inventory.html)：利用可能なすべてのアクセストークンを完全に管理し、必要に応じて取り消すことができます。\n\n*\n[通知](https://docs.gitlab.com/ee/user/profile/notifications.html)：グループ、プロジェクト、パーソナルの各種トークンについて、有効期限が近づいた際に送信される通知メールを積極的に処理します。お客様からのご要望に応え、この通知機能は従来の7日前に加え、30日前、60日前の通知にも対応しました。\n\n*\n[Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook)：アクセストークンのWebhookをグループとプロジェクトに設定して、トークンの有効期限7日前の通知イベントを送信できるようになりました。この機能も最近、**:extended_expiry_webhook_execution_setting**機能\nフラグ（デフォルトでは無効）によって、30日、60日前の通知送信に対応しました。\n\n\n## 今後の展開\n\n\nGitLabでは多くの種類のトークンを提供しており、今後はそれらを統合しつつ、トークンの有効期間や細かなスコープ設定、一貫した管理・運用に重点を置いた改善を進めていく[予定](https://gitlab.com/gitlab-org/gitlab/-/issues/502630)です。現在注力しているトークン関連の機能には、サービスアカウント用の完全なUI、認証情報インベントリへの追加認証情報タイプの対応、トークンおよびサービスアカウントの監査強化などが含まれます。\n\n\n> トークン管理機能を体験するには、[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)にぜひご登録ください。\n",[680,9,706,679,730],{"slug":1156,"featured":90,"template":683},"the-ultimate-guide-to-token-management-at-gitlab","content:ja-jp:blog:the-ultimate-guide-to-token-management-at-gitlab.yml","The Ultimate Guide To Token Management At Gitlab","ja-jp/blog/the-ultimate-guide-to-token-management-at-gitlab.yml","ja-jp/blog/the-ultimate-guide-to-token-management-at-gitlab",{"_path":1162,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1163,"content":1169,"config":1175,"_id":1177,"_type":13,"title":1178,"_source":15,"_file":1179,"_stem":1180,"_extension":18},"/ja-jp/blog/u-s-navy-black-pearl-lessons-in-championing-devsecops",{"title":1164,"description":1165,"ogTitle":1164,"ogDescription":1165,"noIndex":6,"ogImage":1166,"ogUrl":1167,"ogSiteName":696,"ogType":697,"canonicalUrls":1167,"schema":1168},"米国海軍 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":1164,"description":1165,"authors":1170,"heroImage":1166,"date":1171,"body":1172,"category":704,"tags":1173,"updatedDate":1174},[1128],"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/)をもっと知りたいですか。こちらをお読みください。",[678,706,9,269,186],"2024-12-04",{"slug":1176,"featured":90,"template":683},"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":1182,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1183,"content":1189,"config":1195,"_id":1197,"_type":13,"title":1198,"_source":15,"_file":1199,"_stem":1200,"_extension":18},"/ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":1184,"description":1185,"ogTitle":1184,"ogDescription":1185,"noIndex":6,"ogImage":1186,"ogUrl":1187,"ogSiteName":696,"ogType":697,"canonicalUrls":1187,"schema":1188},"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":1184,"description":1185,"authors":1190,"heroImage":1186,"date":1191,"body":1192,"category":772,"tags":1193,"updatedDate":1194},[1128],"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合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[108,678,706,680,9,730],"2025-05-26",{"slug":1196,"featured":90,"template":683},"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":1202,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1203,"content":1206,"config":1218,"_id":1220,"_type":13,"title":1221,"_source":15,"_file":1222,"_stem":1223,"_extension":18},"/ja-jp/blog/what-is-docker",{"noIndex":6,"description":1204,"title":1205},"Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。","Dockerとは：GitLabとの統合とコンテナについての入門編 | GitLab",{"title":1207,"description":1208,"authors":1209,"date":1211,"body":1212,"category":1213,"heroImage":1214,"tags":1215},"Dockerとは：超入門編","Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。\n",[1210],"GitLab Team","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合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","engineering","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750226168/pf5cwmvqq09v1pe0re66.jpg",[108,1216,1217,678,679,1132,9,680],"cloud native","DevOps",{"featured":90,"template":683,"slug":1219},"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":1225,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1226,"content":1232,"config":1239,"_id":1241,"_type":13,"title":1242,"_source":15,"_file":1243,"_stem":1244,"_extension":18},"/ja-jp/blog/what-is-kubernetes",{"title":1227,"description":1228,"ogTitle":1227,"ogDescription":1228,"noIndex":6,"ogImage":1229,"ogUrl":1230,"ogSiteName":696,"ogType":697,"canonicalUrls":1230,"schema":1231},"Kubernetes（K8s）とは？その仕組みから利点、使い方まで","Kubernetes（K8s）とは？Kubernetes の読み方から覚えておきたい用語、仕組みやその利点について学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687485/Blog/Hero%20Images/kubernetes.jpg","https://about.gitlab.com/blog/what-is-kubernetes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes（K8s）とは？その仕組みから利点、使い方まで\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-28\",\n      }",{"title":1227,"description":1228,"authors":1233,"heroImage":1229,"date":1235,"body":1236,"category":1213,"tags":1237},[701,1234],"GitLab","2025-04-28","## 目次\n\n1. Kubernetesとは？その読み方と用途\n2. Kubernetes（K8s）の基本用語解説\n  - コンテナ、Pod、Node、クラスター\n  - Dockerとの違い\n3. Kubernetesの主な特徴\n  - デプロイの自動化\n  - ハイブリッド / マルチクラウドに対応\n  - 拡張性とプラグインアーキテクチャ\n  - ローリングアップデートとロールバック\n  - 柔軟なスケーラビリティ\n  - リリース後のアプリケーション監視\n4. Kubernetesの利点とは\n  - 生産性の向上\n  - 自己修復機能により障害に耐性\n  - 高い可用性を担保\n  - オンプレミスでも、クラウドでも運用可能\n  - 大量のコンテナを一括管理\n  - DevSecOpsとの親和性が高い\n  - クラウドネイティブなワークロードを安全に保つ\n5. GitLabでKubernetesを統合する\n6. Kubernetes（K8s）のよくある質問\n  - KubernetesとDockerの違いは何ですか？\n  - Kubernetesで何ができますか？\n  - Kubernetesコンテナとは何ですか？\n  - Kubernetesの読み方は？\n\n## Kubernetesとは？その読み方と用途\n\nKubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と発音します。ギリシャ語のκυβερνήτηςに由来し、「統治者」や「パイロット」といった意味を持ちます。また、K8sと表記されることもあります。  \n\nKubernetesは、一言で表せばソフトウェア開発においてコンテナを操作・管理するもので、コンテナオーケストレーションの役割を果たすオープンソースソフトウェアとして開発されました。Kubernetesは、クラウドネイティブのプログラムの開発に使用します。これを使用することで[マイクロサービス](https://about.gitlab.com/ja-jp/topics/microservices/)アーキテクチャが可能になり、プログラムの開発が高速化できます。  \nでは、Kubernetesについて、もう少し掘り下げて見ていきましょう。\n\n## Kubernetes（K8s）の基本用語解説\n\n### コンテナ、Pod、Node、クラスター\n\nKubernetesは、コンテナをオーケストレーションするためのツールです。オーケストレーションとは、複数のコンピュータシステムやアプリケーション、サービスなどを調整して管理し、頻繁に繰り返される大規模なワークフローやプロセスを実行できるようにすることを指します。では、コンテナとは何でしょう。ソフトウェア開発におけるコンテナ化とは、ソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することを意味します。コンテナは、完全に機能するポータブルなコンピューティング環境です。また、このコンテナを複数まとめたものがPod、PodをまとめたものがNode、Nodeをまとめたものがクラスタと呼ばれます（以下の図を参照）。\n\n![kubernetesとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687494/Blog/Content%20Images/kubernetes-diagram.svg)\n\n*Kubernetesにおけるコンテナとクラスタの関係を示した図*\n### Dockerとの違い\n\nKuberunetesはコンテナオーケストレーションツールですが、Dockerはコンテナ化ツールの1つです。Dockerはアプリケーションのコンテナ化を行なうとき使用するプラットフォームです。仮想マシンよりも軽量で高速であることや、環境構築が簡単なことから、コンテナ化の主流ツールになっています。\n\n## Kubernetesの主な特徴\n\nKubernetesは、前述したようにコンテナを管理するコンテナオーケストレーションツールで、代表的な機能としては次のようなものが挙げられます。\n\n### デプロイの自動化\n\nKubernetesは、アプリケーションのデプロイ時に、新しいコンテナの作成や既存コンテナの削除を自動で実施します。また、新しく作成したコンテナにも自動でリソースを適用します。\n\n### ハイブリッド / マルチクラウドに対応\n\nクラウドプロバイダーに依存することなく、オンプレミス環境や様々なクラウドサービス（AWS、Azureなど）上で動作します。よって、ハイブリッドクラウドやマルチクラウド環境を簡単に構築、管理することができます。\n\n### 拡張性とプラグインアーキテクチャ\n\n多様なプラグインや拡張機能が利用できます。例えば、CustomResourceDefinitions（CRD）を使って新規にリソースタイプやロジックを追加したり、CNI（Container Network Interface）やCSI（Container Storage Interface）といったプラグインでネットワークやストレージのカスタマイズが可能です。\n\n### ローリングアップデートとロールバック\n\nKubernetesでは、アプリケーションのバージョンを更新する際、ローリングアップデートがそのデフォルトとなります。また、ビルトインでロールバック機構もあります。このため、ライブトラフィックに影響を与えず、ダウンタイムゼロでデプロイを実現できます。\n\n### 柔軟なスケーラビリティ\n\nKubernetesは、大量のコンテナを効率的に管理するためのもので、システムのスケーラビリティが向上できます。スケーラビリティとは、どのくらいシステムの拡張ができるかを示す特性で、Kubernetesではコンテナ化されたアプリケーションの数を増減することでスケーリングします。\n\n### リリース後のアプリケーション監視\n\nPrometheusやGrafanaといった監視ツールを使用することで、アプリケーション固有のメトリクスが監視できます。リリース後のパフォーマンス低下や不具合発見といった事象がアラートされるため、問題に迅速に対処できます。\n\n## Kubernetesの利点とは\n\nKubernetesには次のような7つのメリットがあります。\n\n### 生産性の向上\n\n一つ目のメリットは、アプリケーション開発で生産性が向上できる点にあります。従来の仮想化では、アプリケーションごとにゲストOSを用意する必要がありましたが、Kubernetesでは、アプリケーションを直接コンテナエンジン上にデプロイできるため、サーバーのリソース使用量が抑えられます。\n\n### 自己修復機能により障害に耐性\n\nKubernetesには、PodやNodeに障害が起きた場合、最初の定義（マニフェスト）の状態まで自動修復する機能が備わっています。\n\n### 高い可用性を担保\n\nKubernetesは、複数のNodeの集まりであるクラスターを構成します。あるクラスターで障害が発生した場合、障害が起きたコンテナを自動で再起動させます。また、他のNodeでコンテナを起動させ、処理を引き継ぐ動作も継続できるため、高い可用性が担保できます。\n\n### オンプレミスでも、クラウドでも運用可能\n\nKubernetesは、オンプレミスでも、プライベートクラウド、パブリッククラウドでも利用できます。つまり、自社サーバーでも、クラウドを使っても、どんな環境でも運用可能です。\n\n### 大量のコンテナの一括管理\n\nKubernetesでは、大量のコンテナが一括で管理・運用できます。また、設定ファイルを複数のコンテナ間で共有することによって、設定変更時も正確かつ大量に設定を反映させることが可能です。\n\n### DevSecOpsとの親和性が高い\nDevSecOpsとは、開発と運用を統合するDevOpsにセキュリティを加え、運用を視野に入れながら開発とセキュリティを同時に進め、安心・安全なソフトウェアを迅速にリリースするというコンセプトです。Kubernetesにはアプリケーションの開発と運用の双方に必要とされる機能が多く搭載されているため、DevSecOpsとの親和性が非常に高いという特長があります。\n\n### クラウドネイティブなワークロードを安全に保つ\n\nKubernetesは、クラウドネイティブアーキテクチャに基づいており、クラウドネイティブな情報セキュリティに関するベストプラクティスについて、CNCF（Cloud Native Computing Foundation）からのアドバイスを活用しています。\n\nたとえばKubernetesには、APIやセキュリティコントロールが含まれており、情報セキュリティを管理するポリシーを定義する手段も備わっています。クラウドの利用などでセキュリティ面において懸念が生じても、Kubernetesならユーザーごとにアクセス制限を設定でき、不正アクセスが防止できるため安心です。\n\nまた、Pod Security Standardによりセキュリティに3つのポリシーが定義されています。非常に緩いものから非常に厳しいものまで累積的に定義できます。\n\n## GitLabでKubernetesを統合する\n\nKubernetesクラスターとGitLabを接続すると、アプリの開発・デプロイ・管理・監視ができます。  \nGitLabをKubernetesと連携させる、またはKubernetes内で動作させるには、3つの異なる方法があります。単独で使用することも、組み合わせて使用することもできます。\n\n* GitLabからKubernetesにソフトウェアをデプロイする  \n* Kubernetesを使用してGitLabインスタンスに紐づいたRunnerを管理する  \n* GitLabのアプリケーションとサービスをKubernetesクラスター上で実行する\n\nさらに詳しい情報やお問い合わせは[こちら](https://about.gitlab.com/ja-jp/solutions/kubernetes/)をご覧ください。\n\n## Kubernetes （K8s）のよくある質問\n\n### KubernetesとDockerの違いは何ですか？\n\nDockerはコンテナ化ツールのひとつで、アプリケーションコンテナを構築し、アプリケーションの開発・配布・実行をします。Kubernetesは、より大規模に複数のマイクロサービスを管理するのに使われます。  \nまた、Kubernetesはクラスターで実行され、Dockerはノードで実行されます。Kubernetesの使用目的はコンテナ管理ですが、Dockerの使用目的の一つは、アプリケーションをコンテナに分離することになります。\n\n### Kubernetesで何ができますか？\n\nKubernetesでできることの代表例には下記のようなものが挙げられます。\n\n* 大量のコンテナの一括管理\n* 起動を含めた動作の高速化・軽量化  \n* 自動デプロイ  \n* 自己修復機能により障害に耐性\n* 高い可用性を担保\n* オンプレミスでも、クラウドでも運用可能\n* DevSecOpsとの親和性が高い\n* クラウドネイティブなワークロードを安全に保つ\n\n### Kubernetesコンテナとは何ですか？\n\nソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することをコンテナ化と言います。Kubernetesコンテナは、完全に機能するポータブルなコンピューティング環境で、さまざまなプラットフォームでデプロイ可能なプログラムとして[マイクロサービス](https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture/)アーキテクチャを可能にします（リンクは英語版です）。\n\n### Kubernetesの読み方は？\n\nKubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と読み、「K8s（ケーエイツ）」と略されます。\n",[1238,1216,1217,108,532,1133,9,1132,681],"kubernetes",{"slug":1240,"featured":90,"template":683},"what-is-kubernetes","content:ja-jp:blog:what-is-kubernetes.yml","What Is Kubernetes","ja-jp/blog/what-is-kubernetes.yml","ja-jp/blog/what-is-kubernetes",{"_path":1246,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1247,"content":1252,"config":1257,"_id":1259,"_type":13,"title":1260,"_source":15,"_file":1261,"_stem":1262,"_extension":18},"/ja-jp/blog/what-is-local-llm",{"config":1248,"title":1249,"description":1250,"ogImage":1251},{"noIndex":6},"ローカルLLMとは？開発での活用メリットと注意点","ローカルLLMの意味やクラウドLLMとの違い、ソフトウェア開発における導入メリットなどを解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577836/qjcz9aubvivrn4zy1kqr.jpg",{"title":1249,"description":1250,"authors":1253,"heroImage":1251,"date":1254,"body":1255,"category":1213,"tags":1256},[1210],"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合同会社ソリューションアーキテクト本部シニアパートナーソリューションアーキテクト）*",[675,678,679,680,9],{"featured":6,"template":683,"slug":1258},"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":1264,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1265,"content":1271,"config":1277,"_id":1279,"_type":13,"title":1280,"_source":15,"_file":1281,"_stem":1282,"_extension":18},"/ja-jp/blog/what-is-open-source",{"noIndex":6,"title":1266,"ogTitle":1267,"description":1268,"ogImage":1269,"ogDescription":1270},"オープンソースソフトウェア（OSS）とは？詳しく解説​ | GitLab","オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。読んで、理解を深めましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",{"title":1267,"description":1270,"authors":1272,"heroImage":1269,"date":1273,"body":1274,"category":1275,"tags":1276},[1210],"2025-07-17","## オープンソースとは？\n\nオープンソースとは、ソフトウェアのコードが公開され、誰もが利用、改良、再配布できるという仕組みのことを指します。「オープンソースソフトウェア」と同義で使用されることが多いです。\n\n## オープンソースソフトウェア（OSS）とは？\n\nオープンソースソフトウェアはOSSとも記述され、Open Source Softwareの略称です。一般的な商用ソフトウェアとは異なり、誰でも利用、改良、再配布ができるようソースコードが公開されています。これにより個人や企業のデベロッパーは、各々の環境に合わせてソフトウェアを自由に改変し、特定の用途や問題に最適化することが容易にできます。ただし、OSSによってはライセンス制約が存在する場合もあります。\n\nフリー（無料）ソフトと混同されることがありますが、フリーソフトのほとんどはソースコードが非公開です。よって、ソースコードが公開されているかどうかで、OSSかの判断をするのが一般的です。\n\n## オープンソースソフトウェアの基本原則\n\nオープンソフトウェアに明確な定義はありませんが、「ソースコードが公開されていること」以外にも広く認知されている要件があります。これら要件は、米国のOpen Source Initiative（OSI）という団体が提唱した以下10項目を指すのが一般的です。\n\n* 再配布の自由\n* ソースコードの配布\n* 派生ソフトウェアの配布許可\n* 作成者のオリジナルコードの完全性\n* 個人やグループに対する差別禁止\n* 使用分野に対する差別禁止\n* ライセンスの配布\n* 特定製品でのみ有効なライセンスの禁止\n* 他ソフトウェアを制限するライセンスの禁止\n* ライセンスの技術的中立\n\n要約するとOSSの基本原則は、ユーザーやデベロッパーに自由を提供し、協力的な環境を促進することと言えます。ただし、「自由」ではあるものの、ライセンスによって一定のルールは設定されています。例えば、GPLやMITライセンスは、OSSに付随するライセンスの利用や再配布、改変の範囲を規定し、自由利用を促進しつつも、デベロッパーやユーザーの権利を保護しています。OSS利用の際は、こういったライセンスルールを理解し、遵守することを忘れないようにしましょう。ライセンスについては後ほど詳しく解説します。\n\n## オープンソースソフトウェアの具体例\n\nどういったソフトウェアがOSSなのかと問われると、すぐには思いつかないかもしれません。実際に、どういったソフトが様々な分野で活躍しているのかいくつかご紹介しましょう。\n\n### WordPress\n\nWordPressという名前は、誰もが一度は聞いたことがあるでしょう。WordPressはウェブサイトを簡単に作成できるコンテンツ管理システム（CMS）で、世界中でもっとも利用されているCMSとなっています。ウェブサイトデベロッパーは自由にカスタマイズを行うことができ、また、活発なコミュニティで互いをサポートし合うことにより、新たな拡張機能の開発等に貢献しています。\n\n### GIMP\n\nGIMPは、イラストレーター、グラフィックデザイナー、フォトグラファー、サイエンティストなど画像を扱う専門家に人気の画像編集ソフトウェアです。ユーザーは無料でダウンロードして利用でき、WordPressと同じく活発なコミュニティが、日々のバグ修正や、新プラグインを開発をサポートしています。\n\n### Brave Browser\n\nBraveは、ユーザーのプライバシー保護を主眼としたウェブブラウザであり、広告やトラッキングを防止してくれます。さらに、独自の暗号通貨（BAT）や検索システムを開発しているなどの理由で、デベロッパー間では人気のブラウザの一つです。Braveもオープンソースであるため、個人が自由にブラウザ機能をカスタマイズしたり、新たに機能を追加したりすることができる仕様となっています。\n\n### GitLabのオープンソースプロジェクト\n\n[GitLabプラットフォーム](https://about.gitlab.com/ja-jp/)を利用して開発されているオープンソースプロジェクトをいくつかご紹介します。\n\n#### Drupal\n\nDrupalはWordPressと同様に、オープンソースのコンテンツ管理システム（CMS）です。堅牢性と拡張性の高さが評価されており、NASAや経済産業省といった政府機関や、Teslaなどの企業に採用されています。\n\n#### VLC\n\nWindowsやMacにとどまらず、LinuxやiOS等でも使うことできる、メディアプレイヤーです。多様な種類の音声や動画ファイルを再生でき、様々なファイル形式に対応しています。広告等、ユーザーにとって不要な機能が一切搭載されておらず、世界中で広く利用されています。\n\n#### LibreOffice\n\nMicrosoft Officeとよく比較されることがあるのが、LibreOfficeです。無料で利用することができ、様々なオフィスツールを提供することから、たくさんの企業や個人に使用されています。\n\n## オープンソース開発のメリットとデメリット\n\nOSSの開発には様々なメリットとデメリットがあります。開発手法についての議論は付きませんが、ここでは言及されることが多いポイントをいくつか挙げてみます。\n\n### メリット\n\n#### コミュニティによる自発的なサポートと開発\n\nオープンソース開発は通常、世界中のデベロッパーが参加した活発なコミュニティを形成しています。多種多様なバックグランドを持つ個々のユーザーたちがお互いにアイデアやフィードバック、サポートし合うことを基本とし、継続的な開発とサポートをしてくれます。\n\n#### 高い透明性に担保された信頼とセキュリティ\n\nOSSの信頼とセキュリティは、誰もがソースコードを参照できることで実現されています。\n\nまず、たくさんのデベロッパーの目に触れるため、脆弱性やバグが比較的早い段階で発見されます。これにより、セキュリティを高レベルに引き上げることができます。そして、ソースコードが公開されているため、不正な動作やバックドアの存在といったリスクを排除しやすく、ソフトウェアの信頼性を高めてくれます。\n\n#### 開発にかかる時間と費用の削減\n\nオープンソースソフトウェアは大抵が無料で、自由にソースコードを改変できます。よって、ライセンス料とスクラッチ開発が不要であり、個人や企業の費用と開発時間を大幅に削減してくれます。\n\n### デメリット\n\n#### 開発プロジェクトの継続性\n\nオープンソース開発は、有志が中心となって行われる場合が多いため、プロジェクトが遅延したり、突然中止となったりするリスクがあります。また、安定した開発スケジュールが維持されないこともあります。\n\nプロジェクトの多くは無償、スポンサー、寄付で成り立っていることが一般的なので、開発コアメンバーが抜けた、資金が枯渇してしまった、などの理由から開発自体が立ち行かなくなることもあります。\n\n#### 責任の所在が曖昧\n\nコミュニティ主導で開発が進められる場合、ユーザーにバグや他ソフトと統合できないといった問題が発生しても商用ソフトウェアとは異なり、自己解決しなくてはならないケースが通常です。迅速かつ的確なサポートが受けづらいケースも、発生することがあります。\n\n#### ライセンスの準拠で\n\n当然ながら、OSSにもライセンスが存在します。無条件に利用や再配布ができるわけではないので、しっかりとライセンスを理解した上で使用しなければいけません。ライセンス規約に違反してしまい、過去には訴訟に発展したケースもあるため、注意が必要です。詳しくは後ほど解説します。\n\n### オープンソースの課題とGitLabのアプローチ\n\nGitLabというプラットフォームが、OSSにおける課題に対してどう取り組んでいるかについて、いくつかご紹介しましょう。詳細を知りたい場合は、[オープンソースプロジェクト向けのGitLabソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を読んでみてください。\n\n#### 脆弱性の早期発見と修正\n\nオープンソースは、コードが公開されているため、悪意のある人物が脆弱性を発見してしまうリスクがあります。\n\n[DevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/topics/devsecops/)であるGitLabは、開発プロセス全体においてセキュリティを重要視しています。静的アプリケーションセキュリティテスト（SAST）や依存関係スキャンといった強力なツールが、早期の脆弱性発見と修正を実現する仕組みを実現します。\n\n#### サポートの補完\n\nOSSはコミュニティによるサポートが中心となり、的確なサポートや迅速な対応を受けられないケースが発生することがあります。\n\n[商用版GitLab](https://about.gitlab.com/ja-jp/pricing/)には、「GitLab Premium」「GitLab Ultimate」があり、公式サポートという選択肢が用意されています。また、コミュニティの結束を高める働きかけをすることで自発的サポートも促進しています。\n\n#### コミュニティの活性化\n\n活発なコミュニティなしに、OSSを成功させることはできませんが、これを維持するのは容易ではありません。\n\nGitLabは、[GitLabフォーラム](https://forum.gitlab.com/c/community/gitlab-for-open-source/49)を運営したり、[オープンソース団体向けプログラム](https://about.gitlab.com/ja-jp/solutions/open-source/join/)を実施、GitLabハッカソンやオンラインイベントを開催したりすることで、デベロッパー同士の繋がりを促進、コミュニティの活性化と拡大に貢献しています。\n\n## オープンソースのライセンスとその重要性\n\nオープンソースのライセンスは、ソフトウェアの利用、配布、変更等に関する権利と制限を明記したものであり、法的拘束力を持ちます。よって、ソフト利用者はこれをしっかりと理解した上で、トラブル回避をすることが望ましいといえます。\n\nまた、ソフトウェアデベロッパーがどのライセンス規約にするかを考える場合には、透明性を重視するのか、自由度を重視するのかなどにより選択するライセンスが異なってきます。ここでは、いくつか代表的なものをご紹介しましょう。\n\n以下に表としてまとめてみました。\n\n![オープンソース　ライセンスのタイプと代表例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720035/v9ld6h78ilk22x30nged.jpg)\n\n### コピーレフト\n\nコピーレフトライセンスは、元となるソフトウェアを再配布する時には、派生物も元OSSと同じ条件下で行う必要があるというものです。このタイプのライセンスは、非常に伝播性が強いのが特徴です。\n\nまたコピーレフトという言葉は、「コピーライト」をもじったものから誕生しました。\n\n### 準コピーレフト\n\nコピーレフトと比べ、伝播性が多少弱いのが準コピーレフトです。元のOSSのソースコードを再利用した時に、元のライセンスと同条件で再配布する必要があります。\n\n### 非コピーレフト\n\nパーミッシブライセンスとも呼ばれます。名前の通りですが、元のOSSと同条件のライセンスにする必要がありません。ソースコードの公開義務がないため、商用利用されることが多いです。\n\n## よくある質問\n\n### オープンソースソフトウェア（OSS）とは何ですか？\n\nOSSとは、ソースコードが公開され、誰でも自由に利用、修正、配布できるソフトウェアのことです。\n\n### OSSのセキュリティは安心ですか？\n\nOSSライセンスは、ソフトウェアの利用や再配布に関する自由と制約を明確に定義したものです。\n\n### OSSのライセンスにはどんな種類がありますか？\n\nライセンスにはGPL、MIT、Apache Licenseなど、異なる自由度や利用条件を持つものがあり、コピーレフト、準コピーレフト、非コピーレフトの３つに大別されます。\n\n### なぜ企業がOSSを採用するのですか？\n\nコスト削減、柔軟性、信頼性向上、技術コミュニティとの連携が理由となる場合が多いです。またGitLabでは、[オープンソースプロジェクト向けのソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を提供しています。ぜひご確認ください。\n\n*監修：佐々木 直晴* [@naosasaki](https://gitlab.com/naosasaki)*（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*","open-source",[677,269,1133,9],{"featured":90,"template":683,"slug":1278},"what-is-open-source","content:ja-jp:blog:what-is-open-source.yml","What Is Open Source","ja-jp/blog/what-is-open-source.yml","ja-jp/blog/what-is-open-source",{"_path":1284,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1285,"content":1291,"config":1296,"_id":1298,"_type":13,"title":1299,"_source":15,"_file":1300,"_stem":1301,"_extension":18},"/ja-jp/blog/what-is-sbom",{"title":1286,"description":1287,"ogTitle":1286,"ogDescription":1287,"noIndex":6,"ogImage":1288,"ogUrl":1289,"ogSiteName":696,"ogType":697,"canonicalUrls":1289,"schema":1290},"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":1286,"description":1287,"authors":1292,"heroImage":1288,"date":1293,"body":1294,"category":9,"tags":1295},[701,1234],"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 フィールド最高技術責任者）*",[9,678,1132,1133],{"slug":1297,"featured":90,"template":683},"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":1303,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1304,"content":1310,"config":1317,"_id":1319,"_type":13,"title":1320,"_source":15,"_file":1321,"_stem":1322,"_extension":18},"/ja-jp/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"title":1305,"description":1306,"ogTitle":1305,"ogDescription":1306,"noIndex":6,"ogImage":1307,"ogUrl":1308,"ogSiteName":696,"ogType":697,"canonicalUrls":1308,"schema":1309},"2024年グローバルDevSecOps調査で明らかになった、3つの注目すべき結果","今年の調査では、AIが台頭する中、組織における投資の優先分野が変化し、AIによりチームの働き方にどのような影響が生じているかが明らかになりました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751993603/Blog/Hero%20Images/fy25-global-devsecops-report-blog-image.png","https://about.gitlab.com/blog/3-surprising-findings-from-our-2024-global-devsecops-survey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2024年グローバルDevSecOps調査で明らかになった、3つの注目すべき結果\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-06-25\",\n      }",{"title":1305,"description":1306,"authors":1311,"heroImage":1307,"date":1312,"body":1313,"category":1314,"tags":1315},[888],"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",[1316,678,675,9,891],"developer survey",{"slug":1318,"featured":6,"template":683},"3-surprising-findings-from-our-2024-global-devsecops-survey","content:ja-jp:blog:3-surprising-findings-from-our-2024-global-devsecops-survey.yml","3 Surprising Findings From Our 2024 Global Devsecops Survey","ja-jp/blog/3-surprising-findings-from-our-2024-global-devsecops-survey.yml","ja-jp/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",4,[660,689,715,738,759,781,801,820,838],1758747470574]