[{"data":1,"prerenderedAt":936},["ShallowReactive",2],{"/ja-jp/blog/categories/devsecops/":3,"navigation-ja-jp":22,"banner-ja-jp":439,"footer-ja-jp":451,"devsecops-category-page-ja-jp":661},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":17,"_source":18,"_file":19,"_stem":20,"_extension":21},"/ja-jp/blog/categories/devsecops","categories",false,"",{"title":9,"description":10},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","devsecops","content:ja-jp:blog:categories:devsecops.yml","yaml","Devsecops","content","ja-jp/blog/categories/devsecops.yml","ja-jp/blog/categories/devsecops","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":435,"_type":16,"title":436,"_source":18,"_file":437,"_stem":438,"_extension":21},"/shared/ja-jp/main-navigation","ja-jp",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":379,"minimal":413,"duo":426},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/ja-jp/","gitlab logo","header",{"text":32,"config":33},"無料トライアルを開始",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"お問い合わせ",{"href":39,"dataGaName":40,"dataGaLocation":30},"/ja-jp/sales/","sales",{"text":42,"config":43},"サインイン",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,190,195,301,361],{"text":48,"config":49,"cards":51,"footer":74},"プラットフォーム",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":55,"config":56},"プラットフォームを詳しく見る",{"href":57,"dataGaName":50,"dataGaLocation":30},"/ja-jp/platform/",{"title":59,"description":60,"link":61},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":62,"config":63},"GitLab Duoのご紹介",{"href":64,"dataGaName":65,"dataGaLocation":30},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":70,"config":71},"詳細はこちら",{"href":72,"dataGaName":73,"dataGaLocation":30},"/ja-jp/why-gitlab/","why gitlab",{"title":75,"items":76},"利用を開始：",[77,82,87],{"text":78,"config":79},"プラットフォームエンジニアリング",{"href":80,"dataGaName":81,"dataGaLocation":30},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"開発者の経験",{"href":85,"dataGaName":86,"dataGaLocation":30},"/ja-jp/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":92,"left":93,"config":94,"link":96,"lists":100,"footer":172},"製品",true,{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"すべてのソリューションを表示",{"href":99,"dataGaName":95,"dataGaLocation":30},"/ja-jp/solutions/",[101,127,150],{"title":102,"description":103,"link":104,"items":109},"自動化","CI/CDと自動化でデプロイを加速",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":30},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[110,114,118,123],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":30,"dataGaName":111},"/ja-jp/solutions/continuous-integration/",{"text":115,"config":116},"AIアシストによる開発",{"href":64,"dataGaLocation":30,"dataGaName":117},"AI assisted development",{"text":119,"config":120},"ソースコード管理",{"href":121,"dataGaLocation":30,"dataGaName":122},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"自動化されたソフトウェアデリバリー",{"href":107,"dataGaLocation":30,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":30,"icon":134},"/ja-jp/solutions/security-compliance/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"セキュリティとコンプライアンス",{"href":132,"dataGaLocation":30,"dataGaName":139},"Security & Compliance",{"text":141,"config":142},"ソフトウェアサプライチェーンの安全性",{"href":143,"dataGaLocation":30,"dataGaName":144},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"コンプライアンスとガバナンス",{"href":148,"dataGaLocation":30,"dataGaName":149},"/ja-jp/solutions/continuous-software-compliance/","Compliance and governance",{"title":151,"link":152,"items":157},"測定",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":30},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"可視性と測定",{"href":155,"dataGaLocation":30,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"バリューストリーム管理",{"href":165,"dataGaLocation":30,"dataGaName":166},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":168,"config":169},"分析とインサイト",{"href":170,"dataGaLocation":30,"dataGaName":171},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":173,"items":174},"GitLabが活躍する場所",[175,180,185],{"text":176,"config":177},"Enterprise",{"href":178,"dataGaLocation":30,"dataGaName":179},"/ja-jp/enterprise/","enterprise",{"text":181,"config":182},"スモールビジネス",{"href":183,"dataGaLocation":30,"dataGaName":184},"/ja-jp/small-business/","small business",{"text":186,"config":187},"公共機関",{"href":188,"dataGaLocation":30,"dataGaName":189},"/ja-jp/solutions/public-sector/","public sector",{"text":191,"config":192},"価格",{"href":193,"dataGaName":194,"dataGaLocation":30,"dataNavLevelOne":194},"/ja-jp/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":288},"関連リソース",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"すべてのリソースを表示",{"href":202,"dataGaName":198,"dataGaLocation":30},"/ja-jp/resources/",[204,237,260],{"title":205,"items":206},"はじめに",[207,212,217,222,227,232],{"text":208,"config":209},"インストール",{"href":210,"dataGaName":211,"dataGaLocation":30},"/ja-jp/install/","install",{"text":213,"config":214},"クイックスタートガイド",{"href":215,"dataGaName":216,"dataGaLocation":30},"/ja-jp/get-started/","quick setup checklists",{"text":218,"config":219},"学ぶ",{"href":220,"dataGaLocation":30,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"製品ドキュメント",{"href":225,"dataGaName":226,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"ベストプラクティスビデオ",{"href":230,"dataGaName":231,"dataGaLocation":30},"/ja-jp/getting-started-videos/","best practice videos",{"text":233,"config":234},"インテグレーション",{"href":235,"dataGaName":236,"dataGaLocation":30},"/ja-jp/integrations/","integrations",{"title":238,"items":239},"検索する",[240,245,250,255],{"text":241,"config":242},"お客様成功事例",{"href":243,"dataGaName":244,"dataGaLocation":30},"/ja-jp/customers/","customer success stories",{"text":246,"config":247},"ブログ",{"href":248,"dataGaName":249,"dataGaLocation":30},"/ja-jp/blog/","blog",{"text":251,"config":252},"リモート",{"href":253,"dataGaName":254,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":256,"config":257},"TeamOps",{"href":258,"dataGaName":259,"dataGaLocation":30},"/ja-jp/teamops/","teamops",{"title":261,"items":262},"つなげる",[263,268,273,278,283],{"text":264,"config":265},"GitLabサービス",{"href":266,"dataGaName":267,"dataGaLocation":30},"/ja-jp/services/","services",{"text":269,"config":270},"コミュニティ",{"href":271,"dataGaName":272,"dataGaLocation":30},"/community/","community",{"text":274,"config":275},"フォーラム",{"href":276,"dataGaName":277,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":279,"config":280},"イベント",{"href":281,"dataGaName":282,"dataGaLocation":30},"/events/","events",{"text":284,"config":285},"パートナー",{"href":286,"dataGaName":287,"dataGaLocation":30},"/ja-jp/partners/","partners",{"backgroundColor":289,"textColor":290,"text":291,"image":292,"link":296},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":293,"config":294},"ソースプロモカード",{"src":295},"/images/navigation/the-source-promo-card.svg",{"text":297,"config":298},"最新情報を読む",{"href":299,"dataGaName":300,"dataGaLocation":30},"/ja-jp/the-source/","the source",{"text":302,"config":303,"lists":305},"Company",{"dataNavLevelOne":304},"company",[306],{"items":307},[308,313,319,321,326,331,336,341,346,351,356],{"text":309,"config":310},"GitLabについて",{"href":311,"dataGaName":312,"dataGaLocation":30},"/ja-jp/company/","about",{"text":314,"config":315,"footerGa":318},"採用情報",{"href":316,"dataGaName":317,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":317},{"text":279,"config":320},{"href":281,"dataGaName":282,"dataGaLocation":30},{"text":322,"config":323},"経営陣",{"href":324,"dataGaName":325,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":327,"config":328},"チーム",{"href":329,"dataGaName":330,"dataGaLocation":30},"/company/team/","team",{"text":332,"config":333},"ハンドブック",{"href":334,"dataGaName":335,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":337,"config":338},"投資家向け情報",{"href":339,"dataGaName":340,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":342,"config":343},"トラストセンター",{"href":344,"dataGaName":345,"dataGaLocation":30},"/ja-jp/security/","trust center",{"text":347,"config":348},"AI Transparency Center",{"href":349,"dataGaName":350,"dataGaLocation":30},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":352,"config":353},"ニュースレター",{"href":354,"dataGaName":355,"dataGaLocation":30},"/company/contact/","newsletter",{"text":357,"config":358},"プレス",{"href":359,"dataGaName":360,"dataGaLocation":30},"/press/","press",{"text":37,"config":362,"lists":363},{"dataNavLevelOne":304},[364],{"items":365},[366,369,374],{"text":37,"config":367},{"href":39,"dataGaName":368,"dataGaLocation":30},"talk to sales",{"text":370,"config":371},"サポートを受ける",{"href":372,"dataGaName":373,"dataGaLocation":30},"/support/","get help",{"text":375,"config":376},"カスタマーポータル",{"href":377,"dataGaName":378,"dataGaLocation":30},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"閉じる",{"text":382,"link":383},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":384,"config":385},"GitLab.com",{"href":44,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"提案",[391,394,399,401,405,409],{"text":59,"config":392},{"href":64,"dataGaName":393,"dataGaLocation":387},"GitLab Duo (AI)",{"text":395,"config":396},"コード提案（AI）",{"href":397,"dataGaName":398,"dataGaLocation":387},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":400},{"href":113,"dataGaName":111,"dataGaLocation":387},{"text":402,"config":403},"GitLab on AWS",{"href":404,"dataGaName":402,"dataGaLocation":387},"/ja-jp/partners/technology-partners/aws/",{"text":406,"config":407},"GitLab on Google Cloud",{"href":408,"dataGaName":406,"dataGaLocation":387},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":410,"config":411},"GitLabを選ぶ理由",{"href":72,"dataGaName":412,"dataGaLocation":387},"Why GitLab?",{"freeTrial":414,"mobileIcon":418,"desktopIcon":423},{"text":32,"config":415},{"href":416,"dataGaName":35,"dataGaLocation":417},"https://gitlab.com/-/trials/new/","nav",{"altText":419,"config":420},"GitLabアイコン",{"src":421,"dataGaName":422,"dataGaLocation":417},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":419,"config":424},{"src":425,"dataGaName":422,"dataGaLocation":417},"/images/brand/gitlab-logo-type.svg",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"GitLab Duoの詳細について",{"href":64,"dataGaName":430,"dataGaLocation":417},"gitlab duo",{"altText":419,"config":432},{"src":421,"dataGaName":422,"dataGaLocation":417},{"altText":419,"config":434},{"src":425,"dataGaName":422,"dataGaLocation":417},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":440,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":441,"button":442,"config":446,"_id":448,"_type":16,"_source":18,"_file":449,"_stem":450,"_extension":21},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":70,"config":443},{"href":444,"dataGaName":445,"dataGaLocation":30},"/ja-jp/gitlab-duo/agent-platform/","duo banner",{"layout":447},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":452,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":453,"_id":657,"_type":16,"title":658,"_source":18,"_file":659,"_stem":660,"_extension":21},"/shared/ja-jp/main-footer",{"text":454,"source":455,"edit":461,"contribute":466,"config":471,"items":476,"minimal":649},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":456,"config":457},"ページのソースを表示",{"href":458,"dataGaName":459,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":462,"config":463},"このページを編集",{"href":464,"dataGaName":465,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":467,"config":468},"ご協力をお願いします",{"href":469,"dataGaName":470,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":472,"facebook":473,"youtube":474,"linkedin":475},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[477,500,554,587,621],{"title":48,"links":478,"subMenu":483},[479],{"text":480,"config":481},"DevSecOpsプラットフォーム",{"href":57,"dataGaName":482,"dataGaLocation":460},"devsecops platform",[484],{"title":191,"links":485},[486,490,495],{"text":487,"config":488},"プランの表示",{"href":193,"dataGaName":489,"dataGaLocation":460},"view plans",{"text":491,"config":492},"Premiumを選ぶ理由",{"href":493,"dataGaName":494,"dataGaLocation":460},"/ja-jp/pricing/premium/","why premium",{"text":496,"config":497},"Ultimateを選ぶ理由",{"href":498,"dataGaName":499,"dataGaLocation":460},"/ja-jp/pricing/ultimate/","why ultimate",{"title":501,"links":502},"ソリューション",[503,508,511,513,518,523,527,530,533,538,540,542,544,549],{"text":504,"config":505},"デジタルトランスフォーメーション",{"href":506,"dataGaName":507,"dataGaLocation":460},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":137,"config":509},{"href":132,"dataGaName":510,"dataGaLocation":460},"security & compliance",{"text":124,"config":512},{"href":107,"dataGaName":108,"dataGaLocation":460},{"text":514,"config":515},"アジャイル開発",{"href":516,"dataGaName":517,"dataGaLocation":460},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":519,"config":520},"クラウドトランスフォーメーション",{"href":521,"dataGaName":522,"dataGaLocation":460},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":524,"config":525},"SCM",{"href":121,"dataGaName":526,"dataGaLocation":460},"source code management",{"text":111,"config":528},{"href":113,"dataGaName":529,"dataGaLocation":460},"continuous integration & delivery",{"text":163,"config":531},{"href":165,"dataGaName":532,"dataGaLocation":460},"value stream management",{"text":534,"config":535},"GitOps",{"href":536,"dataGaName":537,"dataGaLocation":460},"/ja-jp/solutions/gitops/","gitops",{"text":176,"config":539},{"href":178,"dataGaName":179,"dataGaLocation":460},{"text":181,"config":541},{"href":183,"dataGaName":184,"dataGaLocation":460},{"text":186,"config":543},{"href":188,"dataGaName":189,"dataGaLocation":460},{"text":545,"config":546},"教育",{"href":547,"dataGaName":548,"dataGaLocation":460},"/ja-jp/solutions/education/","education",{"text":550,"config":551},"金融サービス",{"href":552,"dataGaName":553,"dataGaLocation":460},"/ja-jp/solutions/finance/","financial services",{"title":196,"links":555},[556,558,560,562,565,567,571,573,575,577,579,581,583,585],{"text":208,"config":557},{"href":210,"dataGaName":211,"dataGaLocation":460},{"text":213,"config":559},{"href":215,"dataGaName":216,"dataGaLocation":460},{"text":218,"config":561},{"href":220,"dataGaName":221,"dataGaLocation":460},{"text":223,"config":563},{"href":225,"dataGaName":564,"dataGaLocation":460},"docs",{"text":246,"config":566},{"href":248,"dataGaName":249},{"text":568,"config":569},"お客様の成功事例",{"href":570,"dataGaLocation":460},"/customers/",{"text":241,"config":572},{"href":243,"dataGaName":244,"dataGaLocation":460},{"text":251,"config":574},{"href":253,"dataGaName":254,"dataGaLocation":460},{"text":264,"config":576},{"href":266,"dataGaName":267,"dataGaLocation":460},{"text":256,"config":578},{"href":258,"dataGaName":259,"dataGaLocation":460},{"text":269,"config":580},{"href":271,"dataGaName":272,"dataGaLocation":460},{"text":274,"config":582},{"href":276,"dataGaName":277,"dataGaLocation":460},{"text":279,"config":584},{"href":281,"dataGaName":282,"dataGaLocation":460},{"text":284,"config":586},{"href":286,"dataGaName":287,"dataGaLocation":460},{"title":302,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":309,"config":590},{"href":311,"dataGaName":304,"dataGaLocation":460},{"text":314,"config":592},{"href":316,"dataGaName":317,"dataGaLocation":460},{"text":322,"config":594},{"href":324,"dataGaName":325,"dataGaLocation":460},{"text":327,"config":596},{"href":329,"dataGaName":330,"dataGaLocation":460},{"text":332,"config":598},{"href":334,"dataGaName":335,"dataGaLocation":460},{"text":337,"config":600},{"href":339,"dataGaName":340,"dataGaLocation":460},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":460},"/sustainability/",{"text":606,"config":607},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":608,"dataGaName":609,"dataGaLocation":460},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":342,"config":611},{"href":344,"dataGaName":345,"dataGaLocation":460},{"text":352,"config":613},{"href":354,"dataGaName":355,"dataGaLocation":460},{"text":357,"config":615},{"href":359,"dataGaName":360,"dataGaLocation":460},{"text":617,"config":618},"現代奴隷制の透明性に関する声明",{"href":619,"dataGaName":620,"dataGaLocation":460},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":37,"links":622},[623,625,627,629,634,639,644],{"text":37,"config":624},{"href":39,"dataGaName":40,"dataGaLocation":460},{"text":370,"config":626},{"href":372,"dataGaName":373,"dataGaLocation":460},{"text":375,"config":628},{"href":377,"dataGaName":378,"dataGaLocation":460},{"text":630,"config":631},"ステータス",{"href":632,"dataGaName":633,"dataGaLocation":460},"https://status.gitlab.com/","status",{"text":635,"config":636},"利用規約",{"href":637,"dataGaName":638,"dataGaLocation":460},"/terms/","terms of use",{"text":640,"config":641},"プライバシーに関する声明",{"href":642,"dataGaName":643,"dataGaLocation":460},"/ja-jp/privacy/","privacy statement",{"text":645,"config":646},"Cookieの設定",{"dataGaName":647,"dataGaLocation":460,"id":648,"isOneTrustButton":93},"cookie preferences","ot-sdk-btn",{"items":650},[651,653,655],{"text":635,"config":652},{"href":637,"dataGaName":638,"dataGaLocation":460},{"text":640,"config":654},{"href":642,"dataGaName":643,"dataGaLocation":460},{"text":645,"config":656},{"dataGaName":647,"dataGaLocation":460,"id":648,"isOneTrustButton":93},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"featuredPost":662,"allPosts":682,"totalPages":934,"initialPosts":935},{"_path":663,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":664,"content":668,"config":675,"_id":678,"_type":16,"title":679,"_source":18,"_file":680,"_stem":681,"_extension":21},"/ja-jp/blog/event-report-devopsdive2025",{"noIndex":6,"title":665,"description":666,"ogDescription":666,"ogTitle":665,"ogImage":667},"GitLab DevOpsDive2025イベントレポート","2025年5月20日に開催した「GitLab DevOpsDive2025～セキュアなAI活用を実現する3つの方法とは～」のイベントレポートをお届けします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751591672/la3jvyygusvvh5ag7czj.jpg",{"title":669,"authors":670,"date":672,"category":14,"tags":673,"description":666,"body":674,"heroImage":667},"【DevOpsDive2025レポート】AIはソフトウェア開発ライフサイクル全体にAIを適用することで、未来の開発が見えてくる",[671],"GitLab Japan Team","2025-07-10",[282],"GitLabは2025年5月20日、東京・新宿の１０９シネマズプレミアム新宿において、「DevOpsDive2025」を開催しました。新宿ミラノ座の跡地に建つ複合施設にあり、プレミアム映画館として名高い会場のワンフロアを貸し切り、来場者の皆様にはポップコーンとジュースをサービス。映画鑑賞気分でイベントを楽しんでいただきました。\n\n![DevOpsDive2025会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/rgayfhyenn1yjtkfeuxx.jpg)\n\n*会場の様子*\n\n振り返れば、[昨年のイベント](https://about.gitlab.com/ja-jp/blog/event-report-devopsdive2024summer/)は観世能楽堂で実施して、大好評でした。GitLabは、全世界でオフィスを持たない企業として知られていて、全員がリモートワークです。社員とお客様、デベロッパーの皆様と直接触れ合える機会ですから、自分たちにとっても参加者の皆様にとっても楽しいものにしたいと、会場選びから気合を入れて準備してきました。ぜひ次の機会もお楽しみに！\n\nさて、このブログ記事では、当日の講演の模様をお伝えします。テーマは、AIです。\n\n![DevOpsDive2025会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616954/z2xaf83c4javhoxdamrs.jpg)\n\n*会場の様子*\n\n世間では、日本企業のAI活用は遅れているとされています。しかし、基調講演に登壇したAndrew Haschkaは、具体的なデータを示し、実はそうでないと説明します。Haschkaは、豪州を拠点にアジア太平洋地域を中心にGitLabのField CTOとしてユーザーのさまざまな課題に向き合っており、ユーザーの事情を肌感覚で知っているため、説得力があります。\n\n![DevOpsDive2025で話すAndrew Haschka](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616947/dsnsqvj2zjxyaronfcnu.jpg)\n\n*GitLab Field CTO, Asia Pacific & Japan, Andrew Haschka*\n\nソフトウェア開発ライフサイクル（SDLC）においてAIを使用中の企業は、米国の34%に対して日本は48%。これは世界的に見ても高い数値です。ただし、Haschkaは「数字だけを見ると良い傾向なのですが、日本のAI活用はAIコーディングの部分にとどまっています」と釘を刺します。「残念ながら、ソフトウェア開発のライフサイクル全体を通したAI活用には至っていません」。\n\n![AI導入予定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617775/su4hqxb8krrxfcktyh6d.png)\n\n*SDLCで現在AIを使用している、または今後の導入を計画している割合*\n\nAIは、確かにコーディングをスピードアップしてくれます。一方で、セキュリティがないがしろにされてしまうリスクには注意が必要です。Haschkaは、あるインドネシアのGitLabユーザーを例に挙げました。その企業は、AIコーディングによって、開発スピードが大幅に向上し、同じ時間で完成するコード量が飛躍的に増えました。その結果、何が起きたのでしょう。コード量と同時にリスク要素が増えてしまい、脆弱性チェックに大変な手間がかかるようになってしまったのです。\n\nHaschkaは、「ただ、このケースはまだ良い方です。コードをきちんとチェックできているわけですから。“コンプライアンス・ガードレール”が正しく機能していることが証明されたと言えます」と話します。大きな問題は、SDLCに正しくガードレールを設置できておらず、コーディングのスピードアップにより、セキュリティがないがしろにされても、それに気づかない状態のまま放置されることで発生します。\n\nそうした事態に陥ることを防ぎ、セキュリティを担保しながらAIをソフトウェア開発に役立てるために、HaschkaはSDLCを通した3つの視点を持つ必要があるとします。まずは、**SDLCを透過的に管理できる統合されたプラットフォームを持つ**こと。GitLabのように統合的なプラットフォームでSDLC全体へのガバナンスを効かせることが必要で、ポイントソリューションの組み合わせで運用することは難しいのです。\n\n![DevOpsDive2025で話すAndrew Haschka](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616947/dow9hyavtyf7vooswmgw.jpg)\n\n*GitLab Field CTO, Asia Pacific & Japan, Andrew Haschka*\n\n次に、**SDLCに動的なセキュリティ対策を行き渡らせる**こと。対策における最大のテーマは脆弱性管理と依存性管理です。ライブラリやコンポーネントの依存性を可視化・管理し、セキュリティとライセンスについての承認プロセスを必要なポイントで埋め込みます。スキャンの強制実行も大切な要素で、この部分は自動化できるケースもあり、開発生産性を損なわずにセキュリティを担保することを期待できます。これらは、GitLabをSDLCのプラットフォームとして使っていれば、必要なプロセスに埋め込み、優れたガードレールとして機能させることができます。\n\n![GitLab Duoの利用形態](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617775/qdyujjzp99voh7h9qf6h.png)\n\n*GitLab Duoの利用形態*\n\n最後に、**必要に応じてローカルLLMを活用する**こと。ローカルLLMは、クラウドを通さずローカル環境で動作するLLMで、データプライバシーを保護できることが特長。ローカルで稼働するため、機密情報を安全に扱うことができます。GitLab Duo Self Hosted Modelsを使うことで、ローカルLLMをGitLabと連携して運用することが可能になります。\n\nこれら3つの視点を持ち、SDLCを安全に運用するひとつのやり方として、Haschkaはプラットフォーム・エンジニアリング（PE）チームが主導的な立場を担うケースがあると指摘しています。\n\n## PEチームと開発部門が密な連携を取り、GitLabでSDLCを改革\n\n![Olympus株式会社柳田修太氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/soab0npkbzsac2bofvrc.jpg)\n\n*オリンパス株式会社 R&Dセンターオブソフトウェアエクセレンス, グローバル ソフトウェア開発インフラストラクチャ シニアディレクター 柳田 修太氏*\n\n続いては、オリンパス株式会社の事例講演です。同社は、内視鏡を主力に医療デバイスをワールドワイドに提供するメーカーです。そして、優れたPEチームがSDLCの改革で大きな役割を果たした企業の1つでもあります。同社のPEへの取り組みは、グローバルに展開されるソフトウェア開発の効率化、およびコスト適正化を図るためにスタートしました。\n\nスクリーンを背後に演壇に立った柳田 修太氏は、「弊社の開発サイクルは5から10年と長いものが多いことが特徴です。そのため、プロジェクト開始時のインフラが最新でなくなるケースが多いのです」と話します。「医療機器に組み込まれるソフトウェアの開発ですから、ソフトウェアを使う前のバリデーションが不可欠になります。クラウド化されていて特定のタイミングで強制的にバージョンアップされてしまうツールは、どれだけすばらしいものであっても、弊社の開発で使用することは困難です」。\n\nSDLCをよりセキュアにするためには、何らかのプラットフォームは必要になります。要件は、全世界でサポートしてくれるプラットフォームであること。そして、各国で異なる法規制に対応できること。さらに、自社のさまざまな開発要件への適用が可能であること。たとえば、アジャイル開発、仮想化、コンテナへの対応は当然のこと。特殊なニーズのある組み込みソフトウェアの開発プロセスにも対応できなければなりません。\n\n![Olympus株式会社柳田修太氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616952/cck02oslxsqyz0a7fppf.jpg)\n\n*オリンパス株式会社 R&Dセンターオブソフトウェアエクセレンス, グローバル ソフトウェア開発インフラストラクチャ シニアディレクター 柳田 修太氏*\n\nこうしてGitLabを選定したのですが、当初は抵抗もあったといいます。人命にかかわる医療機器の開発プロセスの改革ですから、万全を期する必要があるためです。それでも深い議論を重ね、開発部門と密な連携を取ったことで、少しずつGitLabを試してもらえるようになりました。そうして実際に成果を体験してもらったことで、開発者側からもGitLabを使いたいという声が上がってきます。\n\n柳田氏は、「ビルドのスピードアップが大きなポイントで、並行して複数のビルドを走らせられるため、開発生産性が高まりました。統合ツールとしてインフラ管理が楽なことも、開発現場に受け入れられた理由の大きなところでしょう。開発部門との関係性も高めることができ、いまでは新規プロジェクトを中心にユーザーがどんどん増えています」と話します。\n\nGitLabの浸透に伴ってアジャイルな開発スタイルでの活用も進み、開発スピードはさらに向上しました。GitLabでSDLCを包括的に管理できたことで運用コストを低減し、GitLab Runner（CI/CDのジョブ実行主体）を活用することでコンテナ環境における開発も大幅に効率化しています。こうしてHaschkaの指摘した3つの視点のうち、1と2は着実にオリンパスに定着しつつあります。\n\n今後取り組むのは、3のセキュアなAI活用です。現状は、オリンパスの開発者が作ったコードをAIの学習に使わないと明記したMoUをGitLabと締結した段階。社内でリスクアセスメントを実施し、本格運用に向けた試験運用を続けています。\n\n## 「AIコーディングだけをとってもローカルLLMの価値は大きい」\n\n![株式会社NTTデータグループ加藤耕也氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/k2rn3su6d1ollmyx4n05.jpg)\n\n\\\n*株式会社NTTデータグループ 技術革新統括本部 AI技術部 部長 加藤耕也氏*\n\n\\\n続いては、NTT DATAの講演です。NTT DATAは、生成AI活用コンセプト「SmartAgent™」を発表するなど、ローカルLLMビジネスを積極的に展開しています。グローバルで1000件超の受注実績があり、SDLCの生産性向上目標としてFY25で50%、FY27には70%を掲げています。\n\n同社は社内でも生成AIをソフトウェア開発分野へ適用し、開発業務の効率化を目指しています。現在は、タスクの自動化を進めている段階。これは支援型AIと定義される分野ですが、次なるターゲットはいわゆる自律型AIへの進化です。自律型AIが実用段階に入れば、労働集約型産業はAI駆動型へと進化することが期待されています。NTT DATAは市場に先駆けて自律型AIの本格運用を進めることで、今年から2027年にかけてプロセスの自動化へと発展させ、さらに将来は開発業務のより広範な領域をまたいだ業務の自動化も実現させたい考えです。\n\n![株式会社NTTデータグループ市原大暉氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616948/yjgdcm3cgysc62vaouln.jpg)\n\n\\\n*株式会社NTTデータグループ 技術革新統括本部 AI技術部 市原大暉氏*\n\n\n\n\n\n![AI活用におけるオンプレの重要性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617776/xj4xv49xvtakt4lwqzae.png)\n*生成AI活用におけるプライベートクラウド・オンプレミスの重要性*\n\nAIの利用範囲が拡大することに伴い、よりセキュアなAIが求められるようになります。そのためにローカルLLMの注目が高まっているわけですが、上の表に示したように、ローカルLLMにはメリットもデメリットもあります。それでも機密情報を扱うためには閉域網での開発が必須です。また、NTT DATAでは、顧客に対して独自に実施したヒアリングの結果、AIを独自にチューニングしてオリジナルな学習の方向性を定めたいというニーズが今後増えてくると見ています。これは、公共分野をはじめ、金融、製造、観光などさまざまな業種に共通するニーズです。講演した加藤 耕也氏は、「実は、AIコーディングだけをとってもローカルLLMの価値は大きいのです。そのプロセスにも強力なガバナンスを効かせられるようになりますから」と話します。同社では、すでに社内で約3,000ユーザーがローカルLLMを使って開発プロジェクトを進めています。\n\n![GitLab Duoを用いた検証結果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751617777/b0deb8vbv61osovquall.png)\n\n*GitLab Duoを用いた検証結果*\n\nそしてこの日、GitLab Duoを用いたローカルLLM AIコーディング環境の検証結果を明らかにしてくれました。この検証では、機能面・非機能面での実用性を73項目で精査し、十分な精度を得られたことが報告されています。\n\n## 「ローカルLLMは究極の安全性をもたらす」\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616953/nf6jwyqj4l9xhxbsf2nb.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\n最後のセッションに登壇したのは、GitLabの佐々木 直晴。この日のすべてのセッションを振り返りながら、さまざまなポイントの背景や詳細について語りました。中でも印象深かったのは、AIがコーディングすることでセキュリティレベルが低下する背景についてです。\n\n佐々木は、CSETが昨年公開した資料を示し、AIは人間が書いた脆弱性を含むコードを学習データとするためそれを模倣してしまう可能性があると警告しました。「AIは、 “機能的に正しく動くコードを素早く出力”しようとします。そのとき、セキュリティの観点で重要な構成要素を無視してしまうことがあるようです。たとえば、例外処理や入力チェックなどはコードに入っていなくても機能的には正しく動くため、AIの提案からは抜け漏れやすいということが考えられます」。ローカルLLMについては、「自社の強みが流出するリスクを抑え、究極的な安全性をもたらす存在」とし、実際に多くの企業がそこを目指すだろうと展望しています。\n\n![GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1751616954/nswoq6ryvcrdph9waaam.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\n佐々木は、Haschka の3つの視点を目指すにあたり、GitLabはユーザーのAI利用時にもプライバシーや知的財産権を保護しながらSDLC全体をAIでサポートできるプラットフォームであり続けるとも述べ、AIに取り組むなら安心してGitLabを採用してほしいと会場に呼びかけました。\n\n*\\*SmartAgentは日本国内における株式会社NTTデータグループの商標です。*",{"featured":93,"template":676,"slug":677},"BlogPost","event-report-devopsdive2025","content:ja-jp:blog:event-report-devopsdive2025.yml","Event Report Devopsdive2025","ja-jp/blog/event-report-devopsdive2025.yml","ja-jp/blog/event-report-devopsdive2025",[683,707,728,748,770,789,808,827,846,868,891,912],{"_path":684,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":685,"content":693,"config":701,"_id":703,"_type":16,"title":704,"_source":18,"_file":705,"_stem":706,"_extension":21},"/ja-jp/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"title":686,"description":687,"ogTitle":686,"ogDescription":687,"noIndex":6,"ogImage":688,"ogUrl":689,"ogSiteName":690,"ogType":691,"canonicalUrls":689,"schema":692},"統合されたDevSecOpsプラットフォームへの移行を組織が進めている理由","各種ツールの統合、セキュリティの強化、AIの活用を通じてソフトウェア開発の効率化を実現する、GitLabの包括的な統合DevSecOpsプラットフォームについてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","https://about.gitlab.com/blog/why-are-organizations-moving-to-a-unified-devsecops-platform","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"統合されたDevSecOpsプラットフォームへの移行を組織が進めている理由\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2025-06-02\",\n      }",{"title":686,"description":687,"authors":694,"heroImage":688,"date":696,"body":697,"category":14,"tags":698},[695],"Itzik Gan Baruch","2025-06-02","今日の最新のソフトウェア開発を取り巻く環境では、多くの組織がクラウドに移行し、DevSecOpsプロセスの導入を進めています。しかしながら、このような移行プロセスには、最新の開発方法に合わせて設計されていないツールやレガシーシステムの増加という大きな課題が伴います。そのため、組織はタスク管理、CI/CD、セキュリティ、モニタリングなど、さまざまな用途のツール向けのインテグレーションを作成して、これらのシステムをDevSecOpsに適応させる必要があります。結果として、複雑な運用プロセス、高い保守コスト、開発チームと運用チーム間のコラボレーションへの悪影響といった新たな問題が生じます。さらに、デベロッパーは、計画から本番環境へのデプロイまでの1つの開発フローを完了するために、常に複数のツール間を切り替える必要があり、不満を抱えることになります。\n\n![DevSecOpsプロセスに複数のツールを統合する難しさと、その際に生じる運用コスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>DevSecOpsプロセスに複数のツールを統合するのがどれほど難しいか\u003C/i>\u003C/center> \n\n\u003Cbr>\u003C/br>\n\n幸いなことに、これには解決策があります。ソフトウェア開発に対する統一されたアプローチを提供する包括的なDevSecOpsプラットフォームです。\n\nこのようなプラットフォームは、クラウドベースおよびDevSecOps環境で運用を行う組織向けに構築されており、コード管理、CI/CDプロセス、タスク管理、セキュリティからAI主導の自動化まで、すべてのソフトウェア開発ステージを単一プラットフォームに統合します。すべてのソフトウェア開発ワークフローを統一されたインターフェイスに一元化できるため、開発チームと運用チームの作業やコミュニケーションが効率化され、運用面の複雑さや混乱を最小限に抑えられます。\n\nさらに、デベロッパーエクスペリエンスも大幅に向上します。エンジニアは最新の開発ニーズに特化して設計された製品で作業することになるため、満足度が高まります。\n\n以降のセクションでは、プロジェクトやタスクの管理、セキュリティやコンプライアンスの確保、AI搭載の開発ツールの導入など、チームがよく直面する課題を解決するためにGitLabがどのように役立つかをご紹介します。GitLabなら、単一の統合プラットフォーム内ですべてを行えます。\n\n## 統合されたアジャイルプロジェクト管理\n\nGitLabでは、CI/CDなどソフトウェア開発ライフサイクルの全ステージにわたって、プロジェクトとタスクの管理が完全に統合されている包括的なソリューションが提供されているため、リアルタイムで開発の進捗状況を追跡できます。イシューとエピックは自動化プロセスに直接紐づけられるため、計画から本番環境へのデプロイまでのシームレスなフローが実現されます。このアプローチにより、チーム間の透明性が高まり、遅延の発生が減り、すべてのステークホルダーがリアルタイムで開発状況を明確に把握できるようになります。\n\n![イシューとエピックは自動化プロセスに直接紐づけられるため、計画から本番環境へのデプロイまでのシームレスなフローが実現されます。](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## ビルトインのセキュリティ\nGitLabでは、包括的なセキュリティ機能を統合すること（セキュリティを最優先）を非常に重視しています。GitLabプラットフォームには、以下を含むさまざまな自動セキュリティスキャナーが組み込まれています。\n\n- [依存関係スキャン](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n- [静的アプリケーションセキュリティテスト（SAST）](https://docs.gitlab.com/user/application_security/sast/)\n- [動的アプリケーションセキュリティテスト（DAST）](https://docs.gitlab.com/user/application_security/dast/)\n- [シークレット検出](https://docs.gitlab.com/user/application_security/secret_detection/)\n- [コンテナスキャン](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![さまざまな開発ステージでCI/CDプロセスに統合されているセキュリティスキャン機能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>さまざまな開発ステージでCI/CDプロセスに統合されているセキュリティスキャン機能\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nこれらのセキュリティチェックは、CI/CDパイプラインを含むソフトウェア開発ライフサイクルの全ステージに直接組み込まれており、開発サイクルの早い段階で潜在的なセキュリティ上の問題についてデベロッパーに即座にフィードバックを提供します。\n\n## コンプライアンスと規制要件\n\n効率性や優れたユーザーエクスペリエンスの確保に加え、多くの組織（特に金融機関や大企業など規制の厳しい業界の組織）は、厳格なセキュリティおよびコンプライアンス基準にプロセスが準拠していることを確認する必要があります。こういった組織では、特定のコードブランチ（mainブランチや保護ブランチなど）でCI/CDパイプラインが実行されるたびにセキュリティスキャナーが実行されるようにしたり、mainブランチにコードをマージする前に特定の承認を必須としたりするなど、さまざまなプロジェクトにポリシーを適用する機能が必要です。\n\nGitLabでは、[コンプライアンスフレームワーク](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)という機能があるため、このようなポリシーを簡単に適用できます。構造化されたポリシーを定義し、特定のプロジェクトに対して適用できる機能です。これにより、シームレスで効率的なデベロッパーワークフローを維持しつつ、規制やセキュリティ要件へのコンプライアンスを自動的に実現できます。\n\n## AI搭載の開発支援\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、すべての開発ステージにわたってAI主導のアシスタンスを提供します。そのため、いちいち外部ツールに切り替える必要性がなくなります。すべてのリクエストは、プロジェクトとコードベース全体のコンテキストを把握したAI搭載機能によって処理されるため、より効率的かつスマートに作業を進められます。\n\n例を挙げると、AIは以下のようなタスクを実行できます。\n- タスクの説明の自動生成\n- イシューディスカッションのスマートな要約によるデベロッパーの貴重な時間の節約\n- 高度なコードレビュー機能\n- コードの改善および最適化の提案\n- 自動テスト生成\n- セキュリティの脆弱性の検出と修正\n- 失敗したCIパイプラインの根本原因分析によるトラブルシューティング\n- プライバシーとデータセキュリティ\n\n公共機関や金融機関を始めとする規制の厳しい組織のニーズを理解しているGitLabは、セキュアな環境でAIモデルを実行できるよう独自のソリューションを提供しています。GitLab Duoセルフホストモデルを採用すると、各組織はデータプライバシー、セキュリティ、および大規模言語モデル（[LLM](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/)）の独自インフラへのデプロイを完全に制御しつつ、以下を実現できます。\n- データプライバシーの保護\n- 規制要件へのコンプライアンス\n- 最高レベルのセキュリティ\n- 外部ネットワークの利用やリスクなしでAIのメリットを活用\n\n## まとめ\n\n組織がプロセスの効率化、セキュリティの強化、イノベーションの加速を実現するためには、包括的なDevSecOpsプラットフォームが必要です。ビルトインのセキュリティ機能とAI搭載の自動化を備え、開発、セキュリティ、運用に不可欠なすべてのツールが統合された単一アプリケーションであるGitLabなら、まさにそれらを実現できます。\n\n実際にGitLabがどのように動作するかをご覧になりたい方は、ぜひ以下のインタラクティブなデモをチェックしてみてください。\n\n- [GitLab Duoが搭載されたGitLab PremiumとUltimate](https://gitlab.navattic.com/gitlab-premium-with-duo) – AI搭載の開発支援を体験しましょう\n\n- [CI/CDパイプラインへのセキュリティ実装](https://gitlab.navattic.com/gitlab-scans) – 統合されたセキュリティスキャンによってソフトウェアをどのように保護できるかをご覧ください\n\n- [コンプライアンスフレームワーク](https://gitlab.navattic.com/compliance) – GitLabを使用して全プロジェクトにポリシーを適用してガバナンスを向上させる方法をご紹介します\n\n> GitLab 18オンラインリリースイベントに参加して、自律型AIが担う役割など、DevSecOpsプラットフォームの未来について学びましょう。[今すぐご登録ください！](https://about.gitlab.com/ja-jp/eighteen/)",[9,699,700],"DevSecOps platform","product",{"slug":702,"featured":6,"template":676},"why-are-organizations-moving-to-a-unified-devsecops-platform","content:ja-jp:blog:why-are-organizations-moving-to-a-unified-devsecops-platform.yml","Why Are Organizations Moving To A Unified Devsecops Platform","ja-jp/blog/why-are-organizations-moving-to-a-unified-devsecops-platform.yml","ja-jp/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"_path":708,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":709,"content":715,"config":722,"_id":724,"_type":16,"title":725,"_source":18,"_file":726,"_stem":727,"_extension":21},"/ja-jp/blog/developers-summit-2025-spring-event-report",{"title":710,"description":711,"ogTitle":710,"ogDescription":711,"noIndex":6,"ogImage":712,"ogUrl":713,"ogSiteName":690,"ogType":691,"canonicalUrls":713,"schema":714},"AI活用の鍵はGitLabの一貫したコンテクスト 【Developers Summit 2025 イベントレポート】","2025年2月、GitLabは「Developers Summit 2025」に出展しました。本イベントにてシニアソリューションアーキテクト 佐々木直晴が講演をおこないましたので、本記事にてその模様をレポートします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663625/Blog/Hero%20Images/3508_resized.jpg","https://about.gitlab.com/blog/developers-summit-2025-spring-event-report","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI活用の鍵はGitLabの一貫したコンテクスト 【Developers Summit 2025 イベントレポート】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-03-13\",\n      }",{"title":710,"description":711,"authors":716,"heroImage":712,"date":717,"body":718,"category":14,"tags":719},[671],"2025-03-13","本講演のテーマは、ソフトウェア開発の現場が抱えているAI活用の課題とその解決策です。シニアソリューションアーキテクト[佐々木直晴](https://gitlab.com/naosasaki)は「ソフトウェア開発の現場で、AI時代の新しいサイロが発生している」と考えています。本講演でその解決策として紹介しているのが、GitLabのAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」です。\n\n## コードがどういう背景のもとで書かれたかといった情報までAIに与えるべき\n\n### 組織全体でコンテクストを共有することができているGitLabだからこそ持てたコンセプト\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_DSC1989_resized.jpg)\n*Developers Summit 2025での講演の様子*\n\n本講演における最初のブロックにて佐々木は、コードが書かれた背景に関する情報までAIに与えることが大切なのでは、と語りかけました。\n\nソフトウェア開発の現場でAIを使う際は、断片的なエラーコードのみ渡してその理由を探らせるなどします。しかしAIの可能性を引き出すには、そのコードがどういう背景のもとで書かれ、なぜそう決まったかという情報まで与えるべきです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_TOH3572_resized.jpg)\n*GitLab合同会社 シニアソリューションアーキテクト 佐々木直晴*\n\n佐々木はGitLabのAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」は、こういったコンセプトを持っていると話しました。そうして、このコンセプトは「我々の会社だからもてたもの」と言います。\n\nGitLabはご存知のとおり、オフィスを持たずオールリモートの働き方を実践している企業です。オールリモートを実現するには、ドキュメントによるコミュニケーションが重要になります。\n\n経緯や議論をドキュメントとして残し、「なぜそう決まったか」も含め組織全体でコンテクストを共有する必要があるのです。オールリモートではメンバー間の誤解が生まれないように、記録に残るコミュニケーション技術が必要になります。\n\nそのうえで佐々木は「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)のコンセプトは、コンテクストを組織全体で共有できているGitLabだからこそ持てたものと思っている」と話しました。\n\n## AI時代の新しいサイロが発生した\n### 現在のソフトウェア開発において、AIの活用レベルは3段階に分類される\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit.jpg)\n次のブロックで佐々木は、現在のソフトウェア開発現場におけるAI活用の課題について説明しました。\n\nAIをソフトウェア開発に利用しているという会社は、2023年には64％だったところ、2024年には78％に上がっている* 状況です。今年の調査であれば、100％に近い数字になっていると想定されます。\n\nこのようにソフトウェア開発においてAIはデフォルトになっているものの、現場によって「段階がありレベル感が違う」と佐々木は話しました。活用レベルは大きく分けて3つにわけられ、各レベルで別々の課題が生じているのです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__1_.jpg)\n\nまず、ソースコードの生成にAIを活用するのが、活用レベル1です。「ここはかなりコモディティ化している」と佐々木は話しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__2_.jpg)\n\nソフトウェア開発の様々な局面で、AIを活用するのが活用レベル2です。たとえば以下のような利用があげられます。\n\n- 議論の内容をAIに要約させる\n- 会議の文字起こしをさせる\n- トラブルが起きたらAIにコードを渡して原因を解析させる\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__3_.jpg)\n活用レベル3は、局面に応じて優れたLLMを採用して使い分けている状態です。たとえばチケット管理はこのLLMを利用し、ソースコードの推奨はこのLLMにさせるといった使い分けをします。\n\n### AIの活用レベルごとに異なる課題が生じている\n\n佐々木は「我々はマーケットを見て、それぞれの活用レベルで課題があると思っている」と指摘しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__4_.jpg)\n「活用レベル1：ソースコードの生成にAIを活用」での課題は、AIが局所的な利用にとどまってしまっていることだと佐々木は指摘しました。\n\nソフトウェア開発のなかでも、ソースコードを記述している時間は21％に過ぎない* という調査結果があります。仕事場所がオフィスでも自宅でも、誰にも邪魔されず集中してコードを書ける日はなかなかありません。打ち合わせが入ったりメンバーのタスク管理をしたり、トラブルで呼び出されたりします。\n\nソースコードの記述にAIを使うこと自体はよいことです。しかしAI活用がソースコードの記述にとどまっているということは、AI活用が局所的な効率化に限定されているとも言えます。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__5_.jpg)\n「活用レベル2：ソフトウェア開発の様々な局面でAIを活用」は、AIをいろいろなシーンで使えていて一見素晴らしいように見えます。しかし、「いろいろなところに様々な機能のAIがあり過ぎて統一したいという意見が多い」と佐々木は指摘しました。\n\nソフトウェア開発にAIを使用する全世界の組織のうち、約74％は「ツールチェーンを統合したい」と答えたという調査結果があります。AIのライセンス費用や使い勝手の違いなどがあり、1つにまとめたいという課題が生じているのです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__12_.jpg)\n\n「活用レベル3：各局面に応じて優れたLLMを採用」は、一見良い状態にみえます。チケット管理やコーディングなど、それぞれのシーンで優れたAIを利用できているためです。\n\nしかし「それぞれのシーンで共有されたAIとのコンテクストが、コーディングのときに失われている」と佐々木は指摘しました。AIがそれぞれのツールに特化して閉じており、経緯や議論が個別のツールに取り残されてしまっているのです。\n\nAI間でのコンテクスト共有が不十分なので、コーディング段階でAIがいろいろな推奨をしてくれるものの、その内容には違和感が生じます。佐々木は「これはAI時代の新たなサイロだと我々は定義している」と話しました。\n\n## GitLabだからこそ提案できる、AI利用の課題に対する解決策 \n### GitLabにはソフトウェア開発用のプラットフォームとして必要な機能が一通りそろっている\n\n前項で紹介したAI利用の課題に対して、GitLabが提案するのがGitLabにおけるAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」です。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は「オールリモートでコンテクストを共有しながら会社運営をする我々だからこそできる提案」と、佐々木は強調しています。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__6_.jpg)\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)の紹介をする前に、「そもそもGitLabとは何か」について佐々木が説明しました。\n\nGitLabではソフトウェア開発において、以下のような機能が必要と考えています。\n\nチケット管理をする機能、チケット管理のなかで詳細な議論ができる機能\nソースコードリポジトリ機能\nコミットしたら、自動的に何かをしてくれるCIの仕組み\nセキュリティスキャンなど\n\n「これら機能をばらばらに提供するのでなく、ひとつのプラットフォームとして提供するのがGitLab製品のコンセプト」と佐々木は説明しました。GitLabはソフトウェア開発に必要な機能を集約したDevSecOpsプラットフォームです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__7_.jpg)\n\nこうした製品コンセプトが評価され、[2024  Gartner®  Magic  Quadrant™for  DevOps Platformsにおいて、GitLabが高く（画像の一番右上）に評価された](https://about.gitlab.com/ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops/)ことを、佐々木は紹介しました。\n\n### 今までのAIはスポットで来てもらう助っ人、GitLab Duoは「勝手を知っているチームの一員」として働く\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__8_.jpg)\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__9_.jpg)\n\n前項で紹介したように、ソフトウェア開発にはいろいろな機能が必要になります。GitLabのAI「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」は、それら機能においてAIが同じコンテクストをもってサポートすると佐々木は解説しました。\n\nイシュー割り当てや議論要約、ソースコード生成、テストコードやテストケースの生成、また実装から詳細な説明用の資料を生成するなどの工程を、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は一貫してサポートします。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)はインターネットだけでなく、自社内のAIのゲートウェイを向けることにより自社のネットワークから出ずにAIを使えるのも強いと佐々木は強調しました。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使えば、以下のような\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__10_.jpg)\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__11_.jpg)\nDevSecOpsのループ全ての局面にAIの力をまぶすことができます。\n\n- 計画・議論\n- ロードマップ・スケジュール構築\n- イシューの作成・アサイン\n- 開発・検証\n- デプロイ\n- パフォーマンスのモニタリングとカイゼン\n\n佐々木は、「たとえて言うなら、今までのAIはスポットでちょっと来てもらう助っ人のようなものだった」と指摘しました。スポットの助っ人は、タスクの背景などは分かりません。限定的な情報のなかで、サポートをしなければならないのです。\n\nたとえば断片的なエラーだけ渡され「これは何か」と聞かれても、AIは与えられた情報のなかで提案を返すしかありません。佐々木は「AIは本当ならもっとできるはず、というのが我々の思いだ」と強調しました。\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_TOH3594_resized.jpg)\n一方GitLab Duoは、「勝手の知っているチームの一員として働く」と佐々木は指摘しています。GitLabを使えば、ソフトウェア開発におけるものづくりの全ての作業を同じプラットフォーム内で実行することが可能です。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、これらGitLabにおける活動を多く把握しています。たとえば、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、ソースコードの内容を変更した背景や流れを理解しているわけです。そのため、そのソースコードをプッシュしてCIで失敗したら、GitLab Duoはより深く原因の分析をおこなえます。\n\nまたソフトウェア運用中に、深刻な脆弱性が見つかったとしましょう。このとき[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は「脆弱性に対応するには、リポジトリのこのファイルとこのファイルをこう直したらいいですよ」と提案してくれるのです。\n\nこのように局面をまたいだAIの使い方は、単一のデータストアがないとできないと佐々木は強調しました。リポジトリ・チケット管理・CI・セキュリティスキャンなどソフトウェア開発に必要な機能を、GitLabは全て有しています。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、GitLabのなかでこれら機能と同一プラットフォームに存在し、その全ての活動を把握しているわけです。それゆえに、スポットの助っ人でなくチームの一員として活躍することができます。\n\n最後に佐々木は、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使ったデモを紹介しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_DSC2007_resized.jpg)\n本デモでは、CIが失敗した理由を[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)に調べさせています。そうするとGitLab Duoは、エラーログだけからは推察することが難しい関数や引数の型を使った修正例を提案しました。本デモでGitLab Duoは、デプロイが失敗した原因を、ソースコードの変更内容まで鑑みて分析しているのです。\n\nChatGPTにエラーログだけを渡して解析させるように、AIをスポットの助っ人として使うやり方であれば、コンテクストは共有されません。そのため、この修正例は出ないのではないかと佐々木は強調しました。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)はトラブル発生時に、断片的なログから推奨を返すのでなく、過去の計画まで遡りなぜ失敗が起こったかというところまで助けてくれます。本講演の最後で佐々木は、開発者がより創造的な作業に集中できる環境を作りたいという思いでGitLabを提供させていただいていると語りました。\n\n＊参考元：[GitLab「2024 グローバルDevSecOpsレポート」](https://about.gitlab.com/ja-jp/developer-survey/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_developers-summit-2025-spring-event-report) \n\n## 会場で配布したお土産について\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752174658/Blog/a8q0fxpkysdomfbarvfj.jpg\">\n会場にて本講演のアンケートに答えて下さった参加者の方には、バレンタインデーのチョコとナノブロックをお渡ししました。このナノブロックは、GitLabのロゴがモチーフとなっています。かわいらしいこのロゴの形は、狸をイメージしていることはご存知でしたでしょうか？\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/image5_resized.jpg)\n",[282,720,9,699,721],"inside GitLab","AI/ML",{"slug":723,"featured":93,"template":676},"developers-summit-2025-spring-event-report","content:ja-jp:blog:developers-summit-2025-spring-event-report.yml","Developers Summit 2025 Spring Event Report","ja-jp/blog/developers-summit-2025-spring-event-report.yml","ja-jp/blog/developers-summit-2025-spring-event-report",{"_path":729,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":730,"content":736,"config":742,"_id":744,"_type":16,"title":745,"_source":18,"_file":746,"_stem":747,"_extension":21},"/ja-jp/blog/event-report-gartner-it-infra-2024",{"title":731,"description":732,"ogTitle":731,"ogDescription":732,"noIndex":6,"ogImage":733,"ogUrl":734,"ogSiteName":690,"ogType":691,"canonicalUrls":734,"schema":735},"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":731,"description":732,"authors":737,"heroImage":733,"date":738,"body":739,"category":14,"tags":740},[671],"2025-01-15","2024年12月、GitLabは「ガートナー ITインフラストラクチャ、オペレーション＆クラウド戦略コンファレンス」に出展しました。このイベントにおいて、ソリューションアーキテクト本部長 大井 雄介が講演いたしましたので、本ブログではその模様をレポートします。\n\n## GitLabはインフラチームにも大きな価値を提供できる\n\n講演の主要トピックは、[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)です。冒頭で大井は、「今回のイベントにはインフラ担当の方が多く参加されていて、このセッションにも多くお越しいただいています。GitLabはアプリ開発担当の方々には良く知られていますが、インフラ担当の皆様にはまだ浸透していないかもしれません。しかし、今日話すのは、インフラ担当の方にこそ、ぜひ聞いていただきたい内容になっています」と会場に語りかけます。\n\nインフラの運用・管理に[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を採用するケースは増加しています。SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）やGitOps（DevOpsをインフラ自動化に適用した運用モデル）を実現するために、何らかのツールが必要だという認識が高まったためです。実際に、ソフトウェア開発のプラットフォームであるGitLabをインフラ側にも適用することで、SSoT（Single Source of Truth；信頼できる唯一の情報源）として機能させられることは大きな価値をもたらします。\n\n![Gartner IT Infra講演の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/FAC306DD-2334-463A-963E-E63AEC8F35EC_1_105_c.jpg)\n*会場の様子*\n\n具体的には、インフラの運用・管理を行うツール群をまたいだSSoTとしてGitLabを利用すると、容易に全体像を把握できます。イシューを積極的に使っていれば、各ツールについて過去の採用から導入、改変の経緯についての詳細をつかむことも可能です。[IaC（Infrastructure as Code：インフラ定義ファイル）](https://about.gitlab.com/ja-jp/topics/gitops/infrastructure-as-code/)を管理しておけば、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインのバージョンが管理できるため、万一のことがあってもデプロイ手順に合わせてロールバックできるようになります。機器／OS＆ミドルウェアの各種設定ファイルの管理や配布も容易です。\n\nこのように、GitLabは[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を実現するプラットフォームでありながら、同時にSREやGitOpsなどインフラの運用・管理に活用できるさまざまな機能を備えた統合プラットフォームと言えるのです。\n\n「GitLabは、インフラチームにも大きな価値を提供できるソリューションであると自負しています」（大井）\n\n## 独立した専任のプラットフォームチームが必要\n\n![Gartner IT Infra講演の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/80582937-4BAD-4DC5-A51A-4B680FB15609_1_105_c.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 本部長 大井 雄介*\n\nエンジニアはソフトウェア開発にあたり、計画、開発、リリースのサイクルを高速に回すことを目指します。コンピュータの登場から今日まで、経営者はエンジニアにそれを求めてきました。\n\nしかし、状況は昔と今では大きく変わりました。かつてのエンジニアはコードを書く能力が第一で、スピーディに高効率なコードを生み出すことが求められていました。そして、美しいコードそのものが、エンジニアの誇りでした。しかしながら、現在はコンテナや[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api/)、セキュリティなど、コード以外のさまざまな知見が求められています。\n\n現在のエンジニアにとって、コードそのものは理解できれば問題ありません。すでにAIがある程度のコードを生成できますから、それを目的に合わせて修正することで業務効率が向上する状況が生まれているためです。最も重要なのは、コードの“周辺領域”を知ることで迅速に成果を出す能力。中でも、多数のクラウドツールの中からそれぞれの特徴を理解し、比較・検討して最適解を使用することは重要なスキルです。ただ、この状況はエンジニアの認知負荷が大幅に高まるという課題を生みました。実際に、エンジニアの認知負荷はかつての10倍になったとも言われています。\n\n必要な知見は多岐にわたるため、一人でカバーできる範囲は限られます。そのために、プロセスは細分化されてきました。必然的に、チーム内でもサイロ化が進むことになります。この状況におけるひとつの最適化のための解が、「プラットフォーム部分を共通化して切り出し、1つのチームに任せる」というものです。全体最適を果たすことを目指した取り組みで、そのために多くの組織で「プラットフォームチーム」が生まれることになりました。\n\n![Gartner プラットフォームチームが担う役割](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/Gartner___________________.jpg)\n\nプラットフォームチームのやるべきことを、上図に示しました。同チームは、各プロジェクトと連携しながら、自動化、セキュリティ、[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api/)、およびインフラについて一元的に管理することになります。これは、インフラを構築／保守する専任のプラットフォームチームが必要になるというガートナーの定義する[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)の考え方に一致します。\n\nプラットフォームチームは、開発チームが生産性高く作業を進めることをサポートします。開発チームの行動を制限しすぎず、一方でリスクの高いツールの使用を許さず、万一の際にはすでにリリースされたアプリケーションであってもすべて検査し、迅速に対処して被害を最小限に抑えます。\n\nプラットフォームチームが正しい方向で[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を推進できれば、開発チームが行うインフラ関連作業はほぼゼロになり、開発スピードの向上、開発サイクルの短期化を期待できます。一貫したコンプライアンス／ガバナンスも実現します。最終成果物次第で許容リスク範囲を増減させるなど柔軟な運用を可能にすることで、生産性とリスクのバランスを取りながら、全体最適を図ることができます。\n\n## セキュリティでは防災も意識してほしい\n\n![GitLab Tanuki](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/8622ADC4-CE48-4E04-8993-5569C4BCF269_1_105_c.jpg)\n*ブースで配布された景品*\n\nさらに、セキュリティ面においても[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)が大きく寄与することが期待されています。経営幹部の多くは、セキュリティと聞くとポリシー策定などの企画部分や、ウイルススキャンなどの運用部分だけに注目しがちです。そのため、多くの企業では企画、運用段階のセキュリティには対応が進んでいます。一方、エンジニアは開発段階にやるべきことがあることを知っています。\n\nたとえば、コードそのものがセキュアであるかどうかを検査しなければなりません。Software Bill of Materials（以下、SBOM：ソフトウェア構成の部品表）を実装し、OSSのソフトウェア・サプライチェーンを可視化し、リスクに備える必要があります。定期検査のプロセスは効率化したいですし、脆弱性発見時の即時検査を行える体制を整えておく必要もあります。外注先の管理も必須で、開発チームとプラットフォームチームにかかわるすべての人に共通するSSoTを備えておくことができれば理想です。\n\n大井は、「企画・運用におけるセキュリティを重視すると、主に“減災”を目指すことになります。確かに減災は必要で、SIEMやSOARは有益なソリューションなのですが、 できれば“防災”も目指したいところです。セキュリティ用語を使えば、サイバー・レジリエンスとともに、サイバー・ハイジーンを追求したいのです」と話します。\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)では、ソフトウェア開発プロセスの早期からセキュリティに取り組むことをシフトレフトと呼び、それを重視しています。つまり、開発段階から防災を意識することになり、DevSecOpsの先進企業はこぞってシフトレフトしています。GitLabでは、数多くのセキュリティスキャン機能を用意し、これらを開発プラットフォームに組み込んでいます。同時に、品質を安定させるガイドラインやポリシーをプロセスに適用できるため、規定どおりに各メンバーが仕事を進めながら防災を目指したソフトウェア開発を徹底することができます。\n\nもちろん、減災を無視してよいわけではありません。開発時にリスクゼロだった依存先OSSでも、リリース後に脆弱性が発見されるケースはあります。こうした際には、SBOMを使って完璧に可視化しておき、リスク別に見分けられるビューも提供しています。\n\n![Gartner GitLab Ultimateのセキュリティスキャン機能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/Gartner_GitLab_Ultimate_____________.jpg)\n\n優れたプラットフォームチームが[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を推進し、GitLabを活用すれば、さらなる価値を得ることもできます。GitLabを開発チームに提供することで得られる多くのメリットもあります。採用したエンジニアは、GitLabの使い方さえ覚えれば、すぐに仕事に慣れて戦力化します。AIを使った生産性の高い開発も可能で、すでにコードの提案機能に対応する言語は25以上になりました。自社が所有するAIモデルとの接続も可能で、社内ポリシーでインターネット経由でのAIサービス利用が制限されているケースにも対応できます。\n\n大井は、「GitLabを全社の共通プラットフォームとして活用することで、インフラチームと開発チームが一体となって仕事を進め、[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)の浸透を加速することができます」と話して講演を締めくくりました。\n\n![GitLab 書籍](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/9CCF584A-1244-4EFC-A6C7-5C39C36B68D5_1_105_c.jpg)\n*書籍*\n\n### 関連記事\n[くら寿司が語るソフトウェア開発の「生産性向上」と「セキュリティ・ガバナンス」の重要性【イベントレポート】](https://about.gitlab.com/ja-jp/blog/event-report-gartner-it-symposium/)",[9,741,282],"security",{"slug":743,"featured":93,"template":676},"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":749,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":750,"content":756,"config":764,"_id":766,"_type":16,"title":767,"_source":18,"_file":768,"_stem":769,"_extension":21},"/ja-jp/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":751,"description":752,"ogTitle":751,"ogDescription":752,"noIndex":6,"ogImage":753,"ogUrl":754,"ogSiteName":690,"ogType":691,"canonicalUrls":754,"schema":755},"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":751,"description":752,"authors":757,"heroImage":753,"date":759,"body":760,"category":14,"tags":761,"updatedDate":763},[758],"Sandra Gittlen","2025-01-06","継続的インテグレーション／継続的デリバリー（[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)）によって、ソフトウェアチームがユーザー向けに価値を生み出す方法は大きく変わりました。手動によるデプロイやインテグレーションに煩わされていた時代は過ぎ去り、最新の開発においては自動化、信頼性、そしてスピードが求められています。\n\nCI/CDの本質は、開発環境から本番環境にいたるまでコードが自動的かつ信頼性高く実行され、リアルタイムでフィードバックを取り入れるシームレスなパイプラインを作成することです。[CI](https://about.gitlab.com/ja-jp/topics/ci-cd/benefits-continuous-integration/)の目的は、コードの変更を頻繁に共有リポジトリにマージし、自動的にテストし検証することで、問題解決に伴う余分なコストが生じる前にチームが問題を早期に発見できるようにすることです。[CD](https://about.gitlab.com/ja-jp/topics/ci-cd/#what-is-continuous-delivery-cd)はこれをさらに発展させ、デプロイプロセスを自動化することで、リリースを予測可能でストレスなく行えるようにします。\n\nソフトウェア開発において手作業のプロセスや複雑なツールチェーンに頼るのではなく、堅牢なCI/CDパイプラインを使用してソフトウェアをビルド、テスト、デプロイできます。また、AIによってプロセスの効率化をさらに進め、品質、コンプライアンス、セキュリティチェックの一貫性を保ちながら、CI/CDパイプラインを自動的に設計することが可能になります。\n\nこのガイドでは、基本原則からベストプラクティス、高度な戦略まで、最新のCI/CDパイプラインに関する内容を説明します。また、先進企業がCI/CDをどのように使用して効果的に成果をあげているかについても取り上げます。このガイドでご紹介する内容は、DevSecOps環境をスケールし、[アジャイル](https://about.gitlab.com/ja-jp/topics/ci-cd/continuous-integration-agile/)で自動化された効率的な方法でソフトウェアを開発し、デリバリーする上で役立ちます。\n\nご紹介する内容：\n- 継続的インテグレーションとは\n- 継続的なデリバリーとは\n- ソースコード管理とCI/CDの関係\n- 現代のソフトウェア開発においてCI/CDを利用するメリット\n  - CI/CDと従来の開発の主な相違点\n- CI/CDの基礎を理解する\n  - CI/CDパイプラインとは\n- CI/CDの実装と管理のベストプラクティス\n  - CIのベストプラクティス\n  - CDのベストプラクティス\n- CI/CDの開始方法\n- セキュリティ、コンプライアンス、CI/CD\n- CI/CDとクラウド\n- 高度なCI/CD\n  - CI/CDにおける再利用と自動化\n  - AIによるパイプラインのトラブルシューティング\n- GitLab CI/CDへの移行方法\n- 大手企業から学ぶ教訓\n- CI/CDのチュートリアル\n\n## 継続的インテグレーションとは\n\n[継続的インテグレーション](https://about.gitlab.com/ja-jp/topics/ci-cd/benefits-continuous-integration/)（CI）とは、すべてのコード変更を共有ソースコードリポジトリのmainブランチに早い段階で頻繁に統合し、コミットまたはマージ時に変更内容を自動的にテストし、自動的にビルドを開始する手法のことです。継続的インテグレーションを行うことで、チームはエラーやセキュリティの問題を開発プロセスの初期段階で簡単に特定し、修正できます。\n\n## 継続的デリバリーとは\n[継続的デリバリー](https://about.gitlab.com/ja-jp/topics/ci-cd/#what-is-continuous-delivery-cd)（CD）は、「*継続的デプロイ*」と呼ばれることもあります。継続的デリバリーを行うことで、組織はアプリケーションを自動的にデプロイできるため、デベロッパーがデプロイ状況のモニタリングと成功の確認に専念できる時間を増やすことができます。継続的デリバリーでは、DevSecOpsチームが事前にコードのリリース基準を設定します。その基準が満たされて検証が完了すると、本番環境にコードがデプロイされます。これにより組織は俊敏性を高め、新機能をもっと迅速にユーザーに提供できるようになります。\n\n## ソースコード管理とCI/CDの関係\n\nソースコード管理（[SCM](https://about.gitlab.com/ja-jp/solutions/source-code-management/)）とCI/CDは、現代のソフトウェア開発手法の基盤と言えます。[Git](https://about.gitlab.com/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/)のようなSCMシステムは、変更の追跡、コードの各バージョンの管理、チームメンバー間のコラボレーションをスムーズに連携させる一元的な仕組みになっています。デベロッパーは新機能やバグ修正に取り組む際に、メインコードベースからブランチを作成して変更を加え、[マージリクエスト経由で変更をマージ](https://docs.gitlab.com/ee/user/project/merge_requests/)します。このようなブランチ戦略により、複数のデベロッパーが互いのコードに干渉することなく同時に作業を進められるだけでなく、常に本番環境で使用可能なコードが含まれる、安定したmainブランチを維持できます。\n\nCI/CDは、SCMシステムで管理されているコードを取得し、変更がプッシュされるたびに自動的にビルド、テスト、および検証を行います。デベロッパーがコードの変更を提出すると、CI/CDシステムは自動的に最新のコードを取得し、既存のコードベースに追加して、一連の自動チェックを実行します。これには通常、コードのコンパイル、ユニットテストの実行、静的コード解析の実施、コードカバレッジのチェックが含まれます。これらのステップのいずれかが失敗すると、すぐにチームに通知されます。チームが迅速に問題に対処できるため、他のデベロッパーへの影響を最小限に抑え本番環境への問題流出も防ぐことができます。このようなソース管理と継続的インテグレーションの緊密な連携により、フィードバックループが自動化され、従来の手動テストでは発見が遅れがちだった問題も早期に捉えられるようになり、コードの品質を維持できます。\n\n## 現代のソフトウェア開発においてCI/CDを利用するメリット\n\n新機能やバグ修正の提供に伴う時間とリスクを大幅に削減する[CI/CDは、現代のソフトウェア開発に革新的なメリットをもたらします](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/)。継続的なフィードバックループにより、DevSecOpsチームには、変更がコードベース全体と照らし合わせて自動的に検証されることが保証されます。結果として、ソフトウェアの品質の向上、デリバリーの高速化の実現に加え、リリースの頻度も増加するため、ユーザーのニーズや市場の需要に素早く対応できるようになります。\n\n最も重要なメリットはおそらく、CI/CDによってソフトウェア開発チーム内でコラボレーションと透明性の文化が育まれることです。誰もがビルド、テスト、デプロイの状況をリアルタイムで確認できれば、デリバリープロセスにおけるボトルネックの特定や解決が容易になります。また、CI/CDによって実現される自動化により、デベロッパーの認知負荷が軽減されます。そのため、デプロイプロセスを手動で管理する必要がなくなり、コーディング作業に注力できるようになります。その結果、デベロッパーの満足度と生産性が向上するとともに、これまでソフトウェアのリリースプロセス全体において生じていたリスクも減少します。迅速なコードレビューがCI/CDプロセスの標準プロセスとなり、必要に応じて素早く変更をロールバックできることをチームが理解しているため、より自由に実験を行うことができ、イノベーションと継続的な改善が促進されます。\n\n> GitLab CI/CDの利用を開始しましょう。[GitLab Ultimate](https://about.gitlab.com/ja-jp/free-trial/devsecops/)に登録して、AI搭載のDevSecOpsプラットフォームを60日間無料でお試しください。\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プラットフォームを60日間無料でお試しください。\n\n\u003Cbr>\u003Cbr>\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[111,9,699,762,741,700],"tutorial","2025-05-26",{"slug":765,"featured":93,"template":676},"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":771,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":772,"content":778,"config":783,"_id":785,"_type":16,"title":786,"_source":18,"_file":787,"_stem":788,"_extension":21},"/ja-jp/blog/event-report-japan-it-week-autumn",{"title":773,"description":774,"ogTitle":773,"ogDescription":774,"noIndex":6,"ogImage":775,"ogUrl":776,"ogSiteName":690,"ogType":691,"canonicalUrls":776,"schema":777},"Japan IT Weekレポート：AIがDevSecOpsを加速する。GitLabソリューションの現在地","2024年10月23～25日に開催されたJapan IT Weekにおいて、GitLabブースで実施したミニセミナーの内容をレポートします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665336/Blog/Hero%20Images/GitLab____.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-autumn","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Japan IT Weekレポート：AIがDevSecOpsを加速する。GitLabソリューションの現在地\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-12-11\",\n      }",{"title":773,"description":774,"authors":779,"heroImage":775,"date":780,"body":781,"category":14,"tags":782},[671],"2024-12-11","GitLabは2024年10月23～25日、千葉・幕張メッセで開催された「Japan IT Week」に出展しました。今回はブース出展で、多くのお客様に来場いただき、[DevSecOp](https://about.gitlab.com/ja-jp/topics/devsecops/)sの価値とGitLabのソリューションについてお伝えすることができました。本稿では、ブースで開催したセミナーで、皆様にお伝えした内容をまとめて紹介します。\n\n![GitLabノベルティ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab______.jpg)\n*配布したGitLabノベルティ*\n\n## DevOpsからDevSecOps、シフトレフトへ\n\nGitLabのブースには、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)や[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にそれほど詳しくない方や、いままさにスタートさせようという方もいらっしゃいます。そこで、私たちは多くのセッションで、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)から[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)に至る歴史についてお伝えするようにしています。今回も15分というわずかな時間の中で、一定のボリュームをこの解説に割くことにしました。\n\nすでに広く知られているように、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)が生まれたのは、開発チームと運用チームが協力関係を築く方が、開発から運用に至るプロセスの効率化につながると期待されたためです。開発部門は、迅速に多種のソフトウェアを作りたいと考え、一方の運用部門は本番リリース後のリスクを懸念します。[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)は、両部門が対立するのではなく、仲良く目標に向かおうとする文化を醸成する考え方で、多くの組織がこれを取り入れて成功しました。\n\n![IT Week会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/IT_Week_____.jpg)\n*会場の様子*\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)は、開発チーム＋運用チームの[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)に、Sec＝セキュリティ チームを加え、3つのチームが開発段階から協力することで全体最適を図ろうという考え方です。仲良く仕事に取り組む文化はもちろん必要ですが、セキュリティが加わることで大きく変わる部分があります。それが、シフトレフトと呼ばれるものです。\n\n開発から運用の流れは、一般的な作業工程表と同様に、左から右に流れるプロセスとして作図します。シフトレフトは、「左側に移動する」ことで、セキュリティチェックを前倒しで行う変革です。たとえば、開発が完了し、運用前にチェックするという工程では、セキュリティに不備が発見されれば手戻りが発生し、リリースが遅れます。そして、そのような状況は、開発コストが増えることにつながります。[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)によって開発と運用は一連の流れになっているため、開発段階から随時セキュリティチェックを実施することで、プロセスの全体最適を図り、効率を高め、コストを下げ、プロジェクトのサイクルを高速化することができるのです。\n\nしかしながら、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)には多くの人がかかわり、複雑なプロセスを管理する必要があります。すべてを可視化し、最適化するためには、概念で理解するだけでは不可能で、その実現をサポートする“ツール群”が必要になります。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)をやりたいけれど、スタートするだけでも大変で、プロジェクトを回し続けるために[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の管理に多大な労力がかかることになれば、本末転倒です。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)をひとつのプラットフォームとして実現するソリューションがあれば理想でしょう。GitLabは、まさにそんな[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のプラットフォームなのです。\n\nそして、GitLabは、AIを搭載することで、さらに多機能で開発・運用の生産性を高めるプラットフォームへと進化しています。今回、ブースセミナーで主にお伝えしたのは、進化し続けているAI機能についてです。\n\n![GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 皆川 弘貴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab_________________________________________.jpg)\n*GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 皆川 弘貴*\n\n## AIはDevSecOpsに何をもたらすか\n\nブースセミナーでは、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にAIを適用する価値についてわかりやすく表現するために、「AI DevSecOps 1.0と2.0の違い」として説明しました。\n\nAI DevSecOps 1.0は、コード生成の補助が主体になります。「こんなコードを、この言語で書きたい」というプロンプトを入力すると、AIが自動的にコードを生成してくれます。これがバージョンアップしてAI DevSecOps 2.0になると、プロセス全体の効率化のためにAIを活用します。開発ワークフローのさまざまな場面でAIがサポートしてくれるのです。\n\n1.0のAIはいわば「作業ロボット」ですが、2.0ではAIが「バディ（仲間、同僚）」になるようなイメージと言えばわかりやすいでしょうか。\n\n1.0の段階であっても、生産性の向上には重要な役割を担えます。コード生成に加えてバグの自動修正や、AIによる脆弱性の抽出もできるでしょう。中でも、オープンソースプロジェクトにおいて、コール先のさらにコール先までたどって脆弱性を発見する際にAIは大いに役立つでしょう。\n\n2.0はGitLabの目指しているところです。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のリーダーとして、開発プロセス全体を効率化したいと考えているためです。そのため、1.0の中でもよりロボットに近い個別の機能を持つAIは、お客様が自由に選択できるようにしています。一方、ワークフローをまたいで動く「人間の意思」をサポートするAIは、GitLabというプラットフォーム側で用意します。\n\n近くリリースする予定の[GitLab Duo Workflow](https://about.gitlab.com/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/)が、その第一歩です。このAIは、プロンプトを入れると応答してくれる、ロボットのように受動的なAIではありません。開発テーマを与えると、計画やタスク、コードなどをユーザーと一緒に考えて、提案してくれる能動的なAIなのです。本物のバディのようなAIとしてご利用いただきたいと考えています。\n\n## GitLabが進めているAI実装のいま\n\n[GitLab Duo Workflow](https://about.gitlab.com/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/)は、リリース後も進化を続け、理想の姿へと近づけていきます。では、GitLabはまさにいま、どこまでのAI機能を搭載しているのでしょう。最終日の特別セッションで、現在の「AI-powered DevSecOpsプラットフォーム」が搭載する機能の一部を紹介しました。\n\n開発チーム向けの機能としては、AI利用のコーディング補助機能[Code Suggestions](https://about.gitlab.com/ja-jp/solutions/code-suggestions/)が真っ先に挙げられるでしょう。そのほか、レビュー担当者を推奨してくれるSuggested Reviewers、マージリクエスト（MR）の際に加えられた変更内容の説明を自動記述するSummarize MR changes、MRの各レビューにおいて内容を要約するSummarize my MR reviews、必要なGitコマンドを教えてくれるHelp with Git commandsなども開発生産性を高めてくれるAIです。\n\n![GitLab合同会社ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト 小松原 つかさ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab__________________________________________________.jpg)\n*GitLab合同会社ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト 小松原 つかさ*\n\nセキュリティ／運用チーム向けの機能としては、コードの説明を自動生成するExplain this codeが面白いでしょうか。デジタルに詳しくない経営幹部向け、CIO向け、もしくはエンジニア向けなど、対象読者がわかりやすいようにAIが説明文を作ってくれます。そのほか、脆弱性の説明をしてくれるExplain this vulnerability、MRにテストコードを自動で書いてくれるGenerate Tests in MRなども役立つでしょう。\n\n全体最適を図るAIとしては、イシューで議論された内容を要約するIssue Summaries、AIにチャット形式でイシューやエピックについての説明や要約を生成してもらうGitLab Chat、ソフトウェア開発ライフサイクル全体の生産性について過去の傾向の中から異常値を検出するValue streams forecastingなどが挙げられます。\n\nコード自動生成やコードレビューのように基本的な機能を用意する一方で、「GitLabはAIを使って[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のライフサイクルすべてを効率化させる」よう進化しようとしている方向性はご理解いただけると幸いです。\n\n## 3社のパートナー様にもご講演いただきました\n\n今回は、パートナー様に壇上に立ってもらうセッションも用意し、それぞれに興味深い内容をお話いただくことができました。\n\n[株式会社ジークス](https://www.zyyx.jp/) 久保 仁詩氏からは、ユーザー／パートナーとして見たGitLabと他製品の違いについてご講演いただきました。GitLabは、企業レベルのプロジェクトに最適で、グループ、サブグループ、プロジェクトにより、案件ごとにサブグループを切って多層的な階層構造を作れます。ツール切り替え不要のオールインワンプラットフォームであるため、UIは包括的で多機能です。\n\n「他製品でもできることはありますが、顕著な違いがあるのはセキュリティ関連の機能群です。本来の意味で[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を実現できるプラットフォームであると言えるのは、GitLabの最大の価値でしょう」（久保氏）\n\n![SB C&S株式会社 佐藤 梨花氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/SB_C_S___________.jpg)\n*SB C&S株式会社 佐藤 梨花氏*\n\n[SB C&S株式会社](https://cas.softbank.jp/) 佐藤 梨花氏には、[Platform Engineering](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)について紹介いただきました。GitLabは[Platform Engineering](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を実現するツールの1つという位置づけではありますが、極めて好相性です。大規模／分散開発を行っているチームとの親和性が高く、インフラ自動化要素を備えます。ワンプラットフォームであり、サードパーティー連携が豊富な点も魅力です。\n\n「個人的に良いなと感じるのは、ぜんぶそろっているので小さく始めやすいところ。いきなり大きく始めるのはリスクが高いため。少しずつ始めて範囲を広げていくことを望む組織は多く、GitLabを選択しておけば、成功を積み重ねて適用範囲を拡大していけます」（佐藤氏）\n\n[株式会社サーバーワークス](https://www.serverworks.co.jp/) アプリケーションサービス部 遠藤 広也氏からは、AWS CodeCommitからGitLabへの移行についてお話いただきました。AWS CodeCommitは、7月に新規顧客受付を停止しました。既存ユーザーは利用し続けることができるものの、新機能開発が停止されたため、有力な移行先としてGitLabが注目されています。\n\n参考：[【徹底解説！】AWS CodeCommitからGitLabへの移行ガイド](https://about.gitlab.com/ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab/)\n\n移行にあたっては、AWS CodeCommitをGitLabにミラーリングするやり方が良さそうです。両プラットフォームを並行稼働させられるため、移行リスクは最小化されます。遠藤氏は、単なる移行にとどまらないGitLabを使う運用効率化メリットについて、2つの機能を紹介してくれました。\n\n遠藤氏は、「GitLabの環境で[Code Suggestion](https://about.gitlab.com/ja-jp/solutions/code-suggestions/)を使えば確実に生産性を高められます。また、GitLabでもAWS CodePipelineと容易に連携できます。AWS側でソースプロバイダー設定を変更するだけで、クラウド[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)をそのまま使えるのは魅力的です」と話しています。\n\n![GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 権 東彬](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab________________________________________.jpg)\nGitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 権 東彬\n",[282,720,9,699],{"slug":784,"featured":93,"template":676},"event-report-japan-it-week-autumn","content:ja-jp:blog:event-report-japan-it-week-autumn.yml","Event Report Japan It Week Autumn","ja-jp/blog/event-report-japan-it-week-autumn.yml","ja-jp/blog/event-report-japan-it-week-autumn",{"_path":790,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":791,"content":797,"config":802,"_id":804,"_type":16,"title":805,"_source":18,"_file":806,"_stem":807,"_extension":21},"/ja-jp/blog/event-report-devopsdive2024summer",{"title":792,"description":793,"ogTitle":792,"ogDescription":793,"noIndex":6,"ogImage":794,"ogUrl":795,"ogSiteName":690,"ogType":691,"canonicalUrls":795,"schema":796},"DevOpsDive2024 Summerで、ソフトウェア開発におけるセキュリティを考える【イベントレポート】","2024年6月12日に開催した「GitLab DevOpsDive2024 Summer」のイベントレポートをお届けします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665902/Blog/Hero%20Images/heroimage_devopsdive.jpg","https://about.gitlab.com/blog/event-report-devopsdive2024summer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOpsDive2024 Summerで、ソフトウェア開発におけるセキュリティを考える【イベントレポート】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-10-07\",\n      }",{"title":792,"description":793,"authors":798,"heroImage":794,"date":799,"body":800,"category":14,"tags":801},[671],"2024-10-07","2024年6月12日、GitLabはGINZA SIXの地下にある観世能楽堂において国内で3回目のプライベートイベント「DevOpsDive2024 Summer」を開催しました。本イベントは、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)／[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にかかわる人々が集い、集合知を作りたいという思いでスタート。今回のテーマは「ソフトウェア開発におけるセキュリティを考えよう」に設定しました。能楽専門の公演場を会場に、登壇者が足袋を履いて能舞台で話をするという演出は、デベロッパー界隈を少し賑わしたようなので、イベントがあったことを知っている読者の皆様もいらっしゃるかもしれません。このブログでは、当日の模様をお伝えします。\n\n## シフトレフトでサイバー攻撃に立ち向かう\n\nこの日は、6月ながら都内で気温が30度を超える真夏日になりました。アイスブレイクに登壇した川口 修平は、「暑い中、激アツなイベントへようこそ」と会場を沸かせ、「終了後の懇親会ではオリジナルビールで乾杯しましょう！」と呼びかけました。ビールは[GitLabのイシュー](https://docs.gitlab.com/ee/user/project/issues/)を使って醸造所の担当者とやり取りしながら作り上げたものです。\n\n*![商品名：Gitlab Hazy Gen3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/instagram.jpg)\n[イシューを使って作り上げたビールの紹介（Instagram）](https://www.instagram.com/p/C8bZdKEylKM/?utm_source=ig_web_copy_link&igsh=MzRlODBiNWFlZA==)*\n\nこのように親しみやすい雰囲気で始まったイベントですが、日本において[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)はまだまだこれから。実際に、『DX白書』でも北米の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)利用率52.9％に対し、日本は9.3％にすぎません。このギャップを埋めるためには、サイバーセキュリティの現状を正しく理解し、それと対峙するためのソフトウェア開発について考えておく必要があります。\n\n1人目の登壇者となった[タニウム合同会社 ](https://www.tanium.jp/)Chief IT Architect 楢原 盛史氏は、「見えないものは守れません」と話します。現在、私たちが直面している主な脅威はランサムウェアとサプライチェーン攻撃で、脅威は脆弱性のある場所を起点に忍び込んできます。\n\n> 全社で1万台のPCを使っている企業は、平均20％が管理されていない“野良端末”であると言われています。そして、攻撃者はここを狙ってくるのです。\u003Cbr>\n> （楢原 盛史氏）\n\n![DSC4331](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4331.jpg)\n*タニウム合同会社 Chief IT Architect 楢原 盛史氏*\n\n同氏は、サイバー攻撃の対象は組織が管理するハードウェアにインストールされたすべてのソフトウェアであり、中でもセキュリティ対策が万全でない自社開発のソフトウェア、およびそれに組み込まれたOSSが狙われやすいと指摘します。実際に、OSSコードベースの80％に脆弱性が含まれると言われており、ソフトウェア・サプライチェーン攻撃では、主に[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインが狙われます。\n\n実際に、昨今は大企業が攻撃されて被害に遭ったニュースが数多く報じられています。私たちは、被害者の金銭的損害や株価の暴落を目にしていますし、医療機関への被害は生命を危うくする事態に直結します。経営もこれらの事態を深刻に受け止めていますから、セキュリティへの投資はホットな話題になってきました。\n\nとはいえ、ほぼすべてのシステムはネットワークと切り離すことができません。完全に切り離されたシステムであっても、ファイルやデータのインポートを通じて外部と全く情報をやり取りしないことはないでしょう。実用性を重視する以上、完全なセキュリティを保つのは事実上不可能であると言っていいかもしれません。\n\nその中で、脅威に立ち向かうためには、シフトレフトの原則が大切になります。米国家情報長官室（ODNI）は、DevSecOpsが重要だと通達し、取り組みの必要性を強調しています。日本でも、デジタル庁が『セキュリティ・バイ・デザインガイドライン』を発行しました。そこでは、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)がセキュリティ品質を底上げできると明記されています。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)でセキュアな開発ライフサイクルを実現し、高速かつ頻繁なテストサイクルを回すことが、セキュリティを担保するひとつの答えになるのです。\n\n## 責任を自分に集中させて仕組みを作り、その後に分散する\n\n![DSC4608](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4608.jpg)\n*左よりCloudflare Japan株式会社 エバンジェリスト 亀田治伸氏、くら寿司株式会社 執行役員 DX本部長 中林 章氏、GitLab合同会社カントリーマネージャー小澤正治*\n\nイベントの後半は、3者の鼎談セッションになりました。[GitLab Japan](https://about.gitlab.com/ja-jp/) Country Manager小澤 正治をモデレーターに、[くら寿司株式会社](https://www.kurasushi.co.jp/) 執行役員 DX本部長 中林 章氏、および[Cloudflare Japan株式会社](https://www.cloudflare.com/ja-jp/) エバンジェリスト 亀田 治伸氏が登壇。話題は、くら寿司の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)推進事例が中心になりました。\n\nくら寿司は、数ある回転寿司チェーンの中で、技術への投資による業務効率化を率先して実行してきた企業です。たとえば、食べ終えたお皿を自動的に洗い場まで流す仕組みである「水回収システム」を業界で初めて開発したことは有名で、寿司ロボットをいち早く回転寿司で導入するなど、その後も技術投資を続けて様々な作業工程の自動化とおいしさを追い求めています。デジタル投資にも積極的で、「くら寿司ならでは」のDXを推進中。様々なタッチポイントから流入する予約システムや、店舗のタッチパネル型オーダーシステムなどの強化／開発を進めています。現在は、「お客様サービスと事業活動のリアルタイム連携」を目指すフェーズにあります。\n\nただ、同社はそこに至るまでに本質的な課題を抱えていました。中林氏は、「プロセスが整備されておらず、成果物の紐づけ管理が不十分でした」と話します。戦略会議が2週間ごとに開催されるため、開発サイクルはそれに合わせる必要があります。開発プロセスを統合管理することも必要で、要件定義書やスケジュール、ソースコードのレポジトリといったすべての成果物および中間成果物を必要な人が必要なタイミングで入手できる環境を整える必要もありました。\n\n![DSC4593](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4593.jpg)\n*くら寿司株式会社 執行役員 DX本部長 中林 章氏*\n\nこの状況を抜本的に解決するために、中林氏は[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)という文化を取り入れることを決断。[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)を採用し、他社とは一味違うDXに向けて進み始めます。多くのB2C企業は、顧客に会員登録してもらってロイヤルティを高めていく方向性で顧客戦略を考えます。一方、くら寿司はインバウンド顧客など一過性の顧客も大切にしなければなりません。そのため、ロイヤルティ向上施策と一見さん施策の両面で、多数のプロジェクトを同時並行し、スピード感をもって進められるようになりました。戦略会議で進捗報告し、新規施策の提案と承認、および新たなニーズの把握と共有を行うプロセスもGitLabで最適化。短期サイクルを実現するバックアップ体制も整えました。\n\nセキュリティについてはどうでしょう。中林氏は、「“セキュリティが担保されている”とはどのような状態なのでしょう。静的／動的検査をすればセキュリティが担保できるわけではないですよね。そこで、私たちはプロセス、ルール、成果物のすべてが正しく管理されていることが大切であるという結論に達しました」と話します。\n\n> 経営者にセキュリティを完璧に理解してもらうことは難しいものです。ですから、まず責任を自分に集中させて、仕組みを作りあげることが大切。そして、その後に破壊します。つまり、責任を分散するわけです。\u003Cbr>\n（中林 章氏）\n\n[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)は、この流れを実現できるプラットフォームです。ビジネスにおけるバックログを記録しておけば、それを部門や現場がプロダクトのバックログとして認識できます。要件定義書からスケジュール、ソースコードまで、すべてを一元的に管理できるGitLabがあれば、経営と現場をつなぐことができるのです。さらに、プロセスの中にセキュリティを担保する仕組みを組み込み、業務の中でセキュリティをチェック／実装できるようになります。\n\n![DSC4701](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4701.jpg)\n*Cloudflare Japan株式会社 エバンジェリスト 亀田 治伸氏*\n\n\u003Cbr>\n亀田氏は、くら寿司のリアルな現場の話を聞いて、次のような印象を持ったと語ります。\n\n> 多くの企業を見ていると、権限が属人化しているケースをよく見ます。スタートアップなどの少数精鋭組織ではそちらの方が合うのでしょうが、規模が大きくなると難しくなります。くら寿司さんが集中管理から分散管理へと移行させるやり方は理想的で、GitLabを使えば権限委譲をうまくやれることも体感的に理解できます。\u003Cbr> \n交通ルールを守れば、絶対に事故は起こりません。しかし事故は起きています。つまり、全員がまじめにルールを守らないのです。コンピュータが絡むデジタルにおいて、これは大きな教訓になりそうです。GitLabを使ってミスが起こりにくい仕組みを作ることが大切になるかもしれません。くら寿司さんはグローバル展開していますし、文化の違いも仕組み作りで乗り越えられる部分もあるでしょう。\u003Cbr>\n（亀田 治伸氏）\n\nくら寿司は、人々がデジタルに触れているタイミングをすべて機会としてとらえ、ビジネスに生かすという大きな目標に向かっています。グローバル展開を積極化させる中、セキュリティのルールが国・地域によって異なるという課題にも、すべての地域のメンバーが安心・安全に使えるデジタルを提供するという方向で一つひとつ解決しています。さらに、貴重なエンジニアを確保していけるような、楽しく働きやすい職場づくりを心がけ、エンジニアにとって心地よいカルチャーを育んでいきます。\n\nGitLabを使えば、経営と現場がつながり、グローバルでセキュリティを担保する仕組みが実現します。そしてGitLabは、風通しの良い文化の醸成にも寄与します。くら寿司はGitLabで多くの成果を得ながらDXを推進しています。GitLabを開発プラットフォームとしてビジネスを加速するくら寿司の今後にご注目ください。\n\n![DSC4937](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4937.jpg)",[282,720,9,699],{"slug":803,"featured":6,"template":676},"event-report-devopsdive2024summer","content:ja-jp:blog:event-report-devopsdive2024summer.yml","Event Report Devopsdive2024summer","ja-jp/blog/event-report-devopsdive2024summer.yml","ja-jp/blog/event-report-devopsdive2024summer",{"_path":809,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":810,"content":816,"config":821,"_id":823,"_type":16,"title":824,"_source":18,"_file":825,"_stem":826,"_extension":21},"/ja-jp/blog/event-report-japan-it-week-spring-2",{"title":811,"description":812,"ogTitle":811,"ogDescription":812,"noIndex":6,"ogImage":813,"ogUrl":814,"ogSiteName":690,"ogType":691,"canonicalUrls":814,"schema":815},"DevSecOpsで人材問題は解決できるか: IT Week 2024 春イベントレポート【後編】","2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えするシリーズの「後編」です。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666515/Blog/Hero%20Images/_DSC1507.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-spring-2","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevSecOpsで人材問題は解決できるか: IT Week 2024 春イベントレポート【後編】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-18\",\n      }",{"title":811,"description":812,"authors":817,"heroImage":813,"date":818,"body":819,"category":14,"tags":820},[671],"2024-07-18","*2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えするシリーズの「後編」です。前編では、DevSecOpsの最新状況とGitLabの価値について紹介しましたが、今回は人材がテーマ。一見GitLabのソリューションと遠いところにあるように感じられるかもしれませんが、実はGitLabを活用してDevSecOpsを推進すれば、人材育成や人材確保を進めることができるのです。*\n\u003Cbr>\n[前編を読む:DevOpsからDevSecOpsへ\n](https://about.gitlab.com/ja-jp/blog/event-report-japan-it-week-spring-1/)\n## 開発者たちに気分良く仕事をしてもらうために\n\nデジタル化が急速に進んだ近年、デジタル人材の確保が困難になっていると言われるようになってきました。実際に、『DX白書2023』では、2022年度においてDXを推進する人材の「質」を確保できている企業はわずか6.1％にすぎず、大幅な不足を感じている企業が過半に上ります。2021年度がそれぞれ10.7％、30.5％であったことからも、年々人材の確保が厳しくなっていることがわかります。\n\n一方、米国においては人材が充足されつつあるようです。グローバルエコノミーの時代、人材を海外に求めるという手段はあるかもしれませんが、為替リクスは大きな足かせになります。日本において、デジタル人材はあらゆる業界から引く手あまたで、人材側が企業を選べる状況と言えるでしょう。\n\n人材にとっては喜ばしいでしょうが、企業にとっては切実な悩みです。そこで、この状況を解決するための1つの手段として、「デベロッパー・エクスペリエンス」を高めることに注目してみてください。\n\n![DSC2630_ToshiIto](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/68A1C322-771B-4CA0-B996-73A58E7050BC_1_105_c.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト 伊藤 俊廷*\n\nデベロッパー・エクスペリエンスは、直訳すると開発者体験になります。最近あちこちで聞くカスタマー・エクスペリエンス＝顧客体験の開発者版と言えばわかりやすいでしょうか。これを向上させるカギは、デジタル人材たちに気分良く能力を発揮してもらう環境を整備すること。給与やオフィス環境、マシンスペックなどのハード面、文化とコミュニケーション、成長機会、低い認知負荷などのソフト面のどちらのアプローチも必要になります。\n\nただし、ハード面にはコストという制約があります。そこで、今回はソフト面においてデベロッパー・エクスペリエンスを向上させるという方向性について解説します。まずは、DevSecOpsと親和性の高いセキュリティ人材の体験向上から見ていきましょう。\n\n## DevSecOpsはセキュリティ人材の体験を高める\n\nデジタル人材の中でも、セキュリティ人材は最も確保が困難と言われる分野です。脅威は進化し続けている上に多様化し、常に最新の脅威について学び続ける必要もあります。[株式会社野村総合研究所](https://aslead.nri.co.jp/) プラットフォームサービス開発一部 宮原 俊介氏は、DevSecOpsによってセキュリティ人材の負担軽減と育成を期待できると考えています。\n\nDevSecOpsでは、シフトレフトの考え方を取り入れ、システム開発における設計、開発、テストというプロセスでもセキュリティ診断を実施します。これにより、単体テスト、統合テストといったアプリケーションの機能面のテストが完了してからセキュリティ診断をすることによる手戻りを抑制できます。\n\nそして、DevSecOpsというコンセプトが現実的になっているのは、それらのプロセスにおいて多様な自動化ツールが用意されている点にあります。従来型のやり方では、セキュリティ人材はセキュリティ診断と修正のレビューに忙殺されることになりますが、あらかじめセキュリティが担保されているアプリケーションに対して、最終チェックという形で専門的な診断を行う業務に注力できるようになるのです。\n\n![DSC1517_202404JapanITWeekImage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687918/Blog/Content%20Images/_DSC1517.jpg)\n\nDevSecOpsを実現するためには、3つの要素があると言われています。それらは、技術、プロセス、および文化です。ここで文化がクローズアップされていることに着目してください。DevSecOpsでは、開発、運用、セキュリティの各チームが協力してサービス価値の最大化を図ります。ゴールは共通しているため、チーム間で継続的に改善・学習する体制が出来上がっています。これは、セキュリティ人材のデベロッパー・エクスペリエンス向上につながる継続的な学習機会と、有意義なコミュニケーションの機会を提供することにつながります。\n\n## GitLabで作り上げる文化がデベロッパー・エクスペリエンスに好影響\n\nセキュリティ人材を中心に見てきましたが、DevSecOpsは、セキュリティ人材だけでなく、あらゆるデジタル人材のデベロッパー・エクスペリエンスの向上に役立ちます。GitLabは、市場にある中で唯一“DevSecOpsプラットフォーム”と呼べる統合的なソリューションです。では、GitLabを使うことで、デベロッパー・エクスペリエンスの向上にどのように役立つのでしょうか。\n\nまずは、文化とコミュニケーションいう側面から見ていきましょう。GitLabは、開発構想を含めたすべての情報を一元管理する開発者のためのSSOTとして機能します。過去をすべて可視化できるだけでなく、現在の状況もリアルタイムに反映されていきます。開発者は、GitLab内でコミュニケーションを取ることができ、だれが何をやっているのかを理解しながら、自分のやるべきことを進めることができます。\n\n履歴がすべて残るため、口頭による指示で、言った／言っていないと論争になることはありません。指示がコロコロ変わっても、責任の所在は明確になります。これは、指示の内容について開発者が納得できる説明が必要になることと同義ですから、自然に開発プロジェクトとビジネス側の関係も良くなっていくでしょう。\n\n![NYG2321_202404JapanITWeekimage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/_NYG2321.jpg)\n\n成長機会では、手前味噌になりますがGitLabというデファクト・スタンダードを実際に仕事で使う経験を得られることは大きなメリットです。開発者は、「GitLabを使える」という市場価値の高いスキルを得ることができます。一見、開発者側にとって魅力的でも企業側からは離職リスクを高めるポイントに見えるかもしれませんが、市場から人材を調達しやすく、経験はなくてもポテンシャルの高い人材に魅力を感じてもらえるプロジェクトを展開できるというメリットが勝るはずです。\n\n低い認知負荷についても解説しておきます。GitLabは、DevSecOpsプラットフォームであり、DevSecOpsを実現する機能を包括的に提供しています。そのため、ポイントソリューションである各種ツールの使い方を個別に学習する必要がありません。「何をやりたいか」という本質的な理解があれば、GitLab内ですべてを完結させることができるのです。これは、開発者が“ツールの専門家”にならず、プロジェクト全体を見渡す視野を得られるという点において重要な要素です。\n\nさらに、自動化を加速できることも大きな価値を生みます。リリースの際に、モニターをターミナルで一杯にしながらサーバごとにコマンドを打ち込んだり、手順書からコピー＆ペーストしたりする必要はありません。こうした「スキルアップにつながらないものの、時間を使ってやらなくてはならない作業」を最小化することは、デベロッパー・エクスペリエンスに良い影響を与えてくれます。\n\n## 開発者の提案に寄り添う姿勢を\n\n最後に、ビジネス側やプロジェクトリーダーの方々に向けて、開発者のやる気を引き出すコミュニケーションをどうすれば良いかについて触れておきます。\n\n優秀な開発者は最新のテクノロジーを活用したがるものです。これに制約をかけると、彼らのモチベーションは維持できません。新規で必要な機能があり、その開発を依頼するケースで、最新のテクノロジーを使用したいと提案された場合、コストやセキュリティリスクなどを列挙し、無下に却下するのではなく、寄り添う姿勢を見せてください。\n\n緊急を要する案件でない限り、プロジェクトでそのテクノロジーを使えばどのようなメリットがあるか、コストはどれくらいかかるか、リスクはどこにあるか、という検証をする価値は大きいのです。その上で提案を却下したとしても、開発者が納得のいく説明をできれば、彼らは高いモチベーションを維持し、常に最新のテクノロジーにアンテナを張って次の提案を持ってきてくれるでしょう。その中に、ビジネスの価値を大きく飛躍させる種が眠っているかもしれません。\n\n![NYG2316_202404JapanITWeekimage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/_NYG2316.jpg)\n",[282,720,9,699],{"slug":822,"featured":93,"template":676},"event-report-japan-it-week-spring-2","content:ja-jp:blog:event-report-japan-it-week-spring-2.yml","Event Report Japan It Week Spring 2","ja-jp/blog/event-report-japan-it-week-spring-2.yml","ja-jp/blog/event-report-japan-it-week-spring-2",{"_path":828,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":829,"content":835,"config":840,"_id":842,"_type":16,"title":843,"_source":18,"_file":844,"_stem":845,"_extension":21},"/ja-jp/blog/event-report-japan-it-week-spring-1",{"title":830,"description":831,"ogTitle":830,"ogDescription":831,"noIndex":6,"ogImage":832,"ogUrl":833,"ogSiteName":690,"ogType":691,"canonicalUrls":833,"schema":834},"DevOpsからDevSecOpsへ: IT Week 2024 春イベントレポート【前編】","2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666522/Blog/Hero%20Images/_NYG2319.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-spring-1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOpsからDevSecOpsへ: IT Week 2024 春イベントレポート【前編】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-04\",\n      }",{"title":830,"description":831,"authors":836,"heroImage":832,"date":837,"body":838,"category":14,"tags":839},[671],"2024-07-04","*今回から2回に分けて、2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えします。前編では、DevSecOpsの最新状況とGitLabの価値について、パートナー様やお客様のご意見を取り入れながら紹介していきます。*\n\n## DevOpsをより高品質にするPlatform Engineering\n\nアプリケーション開発のやり方は、テクノロジーの進化とともに変化し、最適化されていきます。変化のスピードは2000年代に入ると加速し、近年はより高まっているように感じられるのは、テクノロジーの進化と多様化が進んでいるためでしょう。その中で、いくつも最新ワードが流行し、消費されることになりますが、時代を象徴する言葉は永く私達の記憶に刻まれることになるでしょう。\n\nいま、注目を集めているワードは、どのようなものでしょう。[SB C&S株式会社](https://cas.softbank.jp/)の佐藤 梨花氏は、「Platform Engineering」を取り上げます。Platform Engineeringは、開発プラットフォームの硬直化を防ぐ概念。開発効率の高いプラットフォームをいち早く取り入れ、モダン化できる状況を整えることで、開発生産性と開発品質をどちらも向上させようとする考え方です。DevOpsを信頼性の高いものとして安定的に運用するために必要なものとして有名なのはSREですが、SREとは別のアプローチでDevOpsをより高速に回し、最適化し続けるものがPlatform Engineeringであると言えばわかりやすいでしょうか。\n\nPlatform Engineeringは、GitLabと相性が良いことも好印象です。[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)にSAST/DASTを組み込んだ自動化はもちろん、イシューとエピック、Wikiによる情報共有、そしてプロジェクトの状況を可視化するアナライズ機能など、GitLabはPlatform Engineeringの成功に必要なさまざまな機能を備えています。VSM（Value Stream Mapping）を使った成果測定手法も確立しつつあり、これからも注目されることになるでしょう。\n\nDevOpsをうまく回すための手法が、最新のワードとして取り上げられるのは興味深い事実です。DevOpsは、すでに「当たり前の存在」になったと言えるのかもしれません。[アジャイル開発](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)と親和性が高いことで普及が後押しされたという側面はありますが、DevOpsの概念であるDevelopment＝開発とOperation＝運用が連携／協力して、フレキシブルかつスピーディに業務を遂行することで得られる価値が多くの企業で実証されたことも重要なポイントでしょう。\n\n![DSC2328_202404JapanITWeekYukiMurakami](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC2328.jpg)\n*GitLab合同会社 営業本部 エンタープライズ営業部 シニア アカウントエグゼクティブ 村上 裕紀*\n\nDevOpsというワードが生まれた当初は、あくまでもコンセプトであり考え方にすぎなかったのですが、それを実現するツール群が提供されるようになったことで、そのコンセプトを実際のプロセスに適用できるようになりました。DevOpsの登場で、「できるだけ早く多くの機能を実装したい」という開発者たちと、「できるだけ安全かつ継続的に運用したい」という運用チームの立場の違いを吸収し、両者が連携して効率的にプロジェクトを進められるようになったのです。\n\nこの流れに乗ってGitLabも進化を続けています。[2023年にガートナーのマジック・クアドラント](https://about.gitlab.com/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms/)において、DevOpsプラットフォームのリーダーに位置づけられ、フォレスター・リサーチのThe Forrester Waveでは唯一のリーダーポジションを得ています。開発、テスト、Deployのプロセスを自動化できるだけでなく、DevOpsの全プロセスを網羅する機能群を提供し、それらが有機的に結びついた開発生産性の高いプラットフォームとなっていることが評価されました。\n\n## DevOpsにセキュリティを組み込むDevSecOpsの価値\n\nDevSecOpsという最新のコンセプトは、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)をDevOpsのプロセスに組み込むものです。[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)／コンプライアンスの重要性が高まり、“説明可能な”[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)が求められるいま、多くの日本企業が注目し、アーリーアダプターが成果を出し始めています。そして、GitLabはすでにDevOpsを超えてDevSecOpsを実現する機能を提供しています。\n\n「DevSecOpsを実現するツール」を調べると、多くの選択肢が目に止まるかもしれません。実際に、DevSecOpsを実現するために、活用できるツールにはさまざまなものがあります。ただ、その中でGitLabは唯一、「DevSecOpsをやりたければGitLabがあれば良い」という統合ソリューションを提供できるのです。開発者、セキュリティチーム、運用チームを一連のプロセスの中で統合できるのはGitLabだけです。\n\n「複数のツールを組み合わせてDevSecOpsをDIYで作る」やり方も可能ではありますが、その場合「DIYしたDevSecOpsの運用コスト」が必要になります。GitLabならそれが必要ないことは大きなメリットで、開発、テスト、Deployという一連のプロセスを自動化し、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)を含めた開発プロセスすべてを管理できます。\n\nさらに、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)機能として最も重視される脆弱性の早期検知においても、強力なエンジンを提供しています。この機能はテストプロセスの後に組み込まれ、開発してすぐテストするというDevOpsの流れをそのまま持ち込めば、開発者は自分の書いたコードや使用するライブラリに脆弱性が含まれるかどうかをすぐに理解することができます。計画段階においてはイシューに要件を付加しておけば、どのレベルの[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)が必要かどうかを振り返って判断することもでき、レビュー時に再確認することも容易です。自動化と人手による検証をどちらも可能にし、開発からリリースに至る全工程に[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)を持ち込み、必要なところは自動化できるようになるのです。\n![DSC1407_202404JapanITWeekYoheiKawase](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1407.jpg)\n*GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスマネジメント部 シニアカスタマーサクセスマネージャー 川瀬 洋平*\n\nひとつのプラットフォームでDevSecOpsを実現することで、ツールを連携させて運用するコストはなくなり、ライセンスコストも最小化します。GitLabのユーザーインタフェースは直感的で評価は高く、開発生産性は大きく向上します。自動化により、開発プロセスはスピードアップします。GitLabが外部委託した調査では、ユーザー企業が収益を生み出すアプリケーション開発プロセスおいて427％のROIを実現し、6か月未満で投資を回収できたことが明らかになりました。\n\nさらに、GitLabでは、DevSecOpsプロセスに[AI](https://about.gitlab.com/ja-jp/gitlab-duo/)を取り入れ、より強力にプロセスの効率化を支援しています。[AI](https://about.gitlab.com/ja-jp/gitlab-duo/)の進化、およびその使い方の熟成が進めば、数字として表面化する成果もより優れたものになると期待されています。\n\n## CI/CDでリリース1回あたりの作業時間を9分の1に\n\n最後に、日本ですでにDevSecOpsに取り組んでいる事例を紹介します。ブースセミナーに登壇した[株式会社キャラウェブ](https://www.chara-web.co.jp/) クラウドパートナーグループ 副部長 中山 桂一氏は、GitLabの導入支援を実施する立場からのコメントをいただき、[株式会社ジークス](https://www.zyyx.jp/) 新規事業開発室 久保 仁詩氏には自社での活用状況についてお話いただいています。\n\nジークスの久保氏が最も顕著な成果を得られたと感じているのは、[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)による自動化です。作業時間の短縮だけでなく、人為的ミスをなくすことにもCI/CDは役立っています。\n\n![DSC1773_202404 Japan IT Week Kubo san from ZYYX](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1773.jpg)\n*株式会社ジークス 新規事業開発室 久保 仁詩氏*\n\nリリースプロセスでは、まず手順書を準備し、モジュールを作成。ターミナルに接続してコマンドを実行する作業をサーバ台数分繰り返す必要がありました。これらをすべて開発者の手作業で実施していたころには、3人がそれぞれ30分をかける必要のあるプロセスで、実行コマンドの入力（手順書のコピー＆ペースト）ミスやリリース漏れなどのリスクがありました。\n\n[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を導入すれば、これらのプロセスはすべて自動化されます。その結果、導入後には、1人の開発者が実行結果を確認するためにわずか10分の時間をかけるだけで済むようになりました。ジークスでは、スモールスタートで効果を確認し、[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を採用するプロジェクトを拡大。現在はモバイル領域にも[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を適用し、月間平均80時間に相当する業務効率化を達成しました。さらに、リリースタイミングは月次や週次ではなく、1日に5回できるようになりました。\n\nキャラウェブの中山氏は、GitLabで開発プロセスを管理する価値は大きいと紹介してくれました。具体的には、マージリクエストの際に、自動的に脆弱性検査とライセンスチェック、コード品質検査を実施することで手戻りは最小限に抑えられます。9種のセキュリティテストを同時に走らせ、静的スキャンに加えて動的な脆弱性スキャンも実施することができます。マージ後に再度セキュリティテストを実行することで、安心できるセキュリティレベルを保証することも可能です。\n\n![DSC1811_202404JapanITWeekNakayamasan](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1811.jpg)\n*株式会社キャラウェブ クラウドパートナーグループ 副部長 中山 桂一氏*\n\n\u003Cbr>\nブースセミナーにパートナー様とお客様が登壇してくださったように、日本でもDevSecOpsは徐々に浸透してきています。アーリーアダプターからはすでに数多くの成功者が生まれています。これからもDevSecOpsの発展とGitLabにご注目ください。\n\n\u003Cbr>\u003Cbr>\n＜[後編を読む：DevSecOpsで人材問題は解決できるか](https://about.gitlab.com/ja-jp/blog/event-report-japan-it-week-spring-2/)＞",[282,720,9,699],{"slug":841,"featured":93,"template":676},"event-report-japan-it-week-spring-1","content:ja-jp:blog:event-report-japan-it-week-spring-1.yml","Event Report Japan It Week Spring 1","ja-jp/blog/event-report-japan-it-week-spring-1.yml","ja-jp/blog/event-report-japan-it-week-spring-1",{"_path":847,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":848,"content":854,"config":862,"_id":864,"_type":16,"title":865,"_source":18,"_file":866,"_stem":867,"_extension":21},"/ja-jp/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci",{"title":849,"description":850,"ogTitle":849,"ogDescription":850,"noIndex":6,"ogImage":851,"ogUrl":852,"ogSiteName":690,"ogType":691,"canonicalUrls":852,"schema":853},"AI搭載のGitLab Duoチャットを使用するためのベストプラクティス【10選】 (1)","AI搭載のDevSecOpsワークフローにGitLab Duoチャットを統合するためのヒントとコツをご覧ください。さらに、最高の結果を得るためにチャットプロンプトを絞り込む方法に関する専門家のアドバイスもご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659684/Blog/Hero%20Images/AdobeStock_479904468__1_.jpg","https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI搭載のGitLab Duoチャットを使用するためのベストプラクティス【10選】 (1)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2024-07-02\",\n      }",{"title":849,"description":850,"authors":855,"heroImage":851,"date":857,"body":858,"category":14,"tags":859},[856],"Fatima Sarah Khalid","2024-07-02","AIと会話を交わすのはチャレンジングかもしれません。どのような質問から始めるべきでしょうか？どのように質問を組み立てますか？どのくらいのコンテキストが必要でしょうか？会話により最高かつ最適な結果を得られるのでしょうか？\n\nこのチュートリアルでは、AI搭載のDevSecOpsワークフローにGitLab Duoチャットを統合し、最良な結果を得るためにプロンプトを洗練させる上で役立つヒントとベストプラクティス10選をご紹介します。\n\n[始める：GitLab Duoチャットを開いたままにしておく](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#始める：GitLab-Duoチャットを開いたままにしておく)\n\n[GitLab Duoチャットを使用するためのベストプラクティス10選](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#GitLab-Duoチャットを使用するためのベストプラクティス10選)\n\n1. [会話を交わす](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#1.-会話を交わす)\n2. [効率を上げるためにプロンプトを絞り込む](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#2.-効率を上げるためにプロンプトを絞り込む)\n3. [プロンプトのパターンに従う](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#3.-プロンプトのパターンに従う)\n4. [ローコンテキストコミュニケーションを使用する](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#4.-ローコンテキストコミュニケーションを使用する)\n5. [繰り返す](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#5.-繰り返す)\n6. [焦らない](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#6.-焦らない)\n7. [リセットして再起動](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#7.-リセットして再起動)\n8. [IDEのスラッシュコマンドで効率化](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#8.-IDEのスラッシュコマンドで効率化)\n9. [スラッシュコマンドのプロンプトを絞り込む](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#9.-スラッシュコマンドのプロンプトを絞り込む)\n10. [スラッシュコマンドでクリエイティブに](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#10.-スラッシュコマンドでクリエイティブに)\n\nボーナスコンテンツ：\n- [ショートカット](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#ショートカット)\n- [試してみよう](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#試してみよう)\n- [詳細](https://about.gitlab.com/ja-jp/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/#詳細)\n\n> AIで進化する最新のGitlab １７とGitLab Duoを、ライブ中継で観てみませんか？\u003Cbr> [__＞日本時間6月28日のイベントに今すぐ登録する＜__](https://about.gitlab.com/seventeen/)\n\n## 始める：GitLab Duoチャットを開いたままにしておく\n\n[GitLab Duoチャット](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)は、GitLab UI、Web IDE、およびVS CodeなどのサポートされているプログラミングIDEで利用できます。\n\nVS Codeでは、デフォルトの左ペインでGitLab Duoチャットを開くことができます。アイコンを右側のペインにドラッグアンドドロップすることもできます。これにより、コードを書いたり、ファイルツリーを移動したり、Gitアクションを実行したりしている間も、チャットを開いたままにしておくことが可能です。チャットの場所をリセットするには、コマンドパレットを開きます。macOSの場合は `[Command] + [Shift] + [P]`、Windows/Linuxの場合は `[Ctrl] + [Shift] + [P]` キーボードショートカットを押し、`View: Reset View Locations` と入力します。以下の短いビデオで、その方法を説明します。\n\n\u003C!-- 空白行 -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/foZpUvWPRJQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- 空白行 -->\n\nWeb IDEとVS Codeは同じフレームワークを共有しています。Web IDEでは同じメソッドを使用でき、より効率的なワークフローを実現できます。\n\n![Web IDEのチャット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676997/Blog/Content%20Images/1.duo-chat-installing-catch2.png)\n\n## GitLab Duoチャットを使用するためのベストプラクティス10選\n\n### 1. 会話を交わす\n\nチャットは会話形式で行うべきであり、検索フォームではありません。\n\n会話の始め方としては、ブラウザでの検索と同様の検索用語から始めて、応答と出力を試してみることをおすすめします。この例では、C#プロジェクトとベストプラクティスから始めましょう。\n\n> c# start project best practices \n> \n> （c#プロジェクト スタート時のベストプラクティス）\n\n![C#スタートプロジェクトのベストプラクティスのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/2.running-catch2-tests.png)\n\nこの回答は、C#の幅広いスコープを理解するのには役立ちますが、すぐに実践できるベストプラクティスを提示しているわけではありません。次は、同じコンテキストで、より焦点を絞った質問をしてみましょう。\n\n> Please show the project structure for the C# project.\n> \n> （C#プロジェクトのプロジェクト構造を示してください）\n\n![C#プロジェクトの構造のチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/2.0-passed-tests-UI.png)\n\nこの回答は参考になります。次に、同じ質問の構成でGitに関する質問をしてみましょう。何かを表示してほしいと指示します。\n\n> Show an example for a .gitignore for C#\n> \n> （C#の.gitignoreの例を示してください）\n\n![C#の.gitignoreのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/2.1-failed-test-simulation.png)\n\nCI/CDに進み、C#プロジェクトを構築する方法を尋ねます。\n\n> Show a GitLab CI/CD configuration for building the C# project\n> \n> （C#プロジェクトを構築するためのGitLab CI/CD設定を表示してください）\n\n![C#プロジェクトを構築するためのGitLab CI/CD設定のチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/2.2-failed-test-simulation-details.png)\n\nこの例では、チャットは、具体的な変更をリクエストするよう促しています。.NET SDK 6.0の代わりに、.NET SDK 8.0を使用するようリクエストしましょう。\n\n> In the above example, please use the .NET SDK 8.0 image\u003Cbr>\n> （上記の例では、次を使用してください。.NET SDK 8.0イメージ）\n\n![.NET SDK 8.0を使用するためのチャットプロンプトと回答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676998/Blog/Content%20Images/3.get-current-weather-function-completion.png)\n\nCI/CD設定で.NETコマンドラインインターフェース（CLI）が使用されます。もしかしたら、プロジェクトやテストの構造を作成するコマンドの効率化にも使えるかもしれません。\n\n> Explain how to create projects and test structure on the CL\n> \n> （CLIでプロジェクトとテスト構造を作成する方法を説明してください）\n\n![CLIでプロジェクトとテスト構造を作成する方法を説明するよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image14.png)\n\nもちろん、これらのコマンドをターミナルで実行することもできますが、引き続きVS Codeを使用したい場合はどうすればよいでしょうか。チャットに尋ねましょう。\n\n> Explain how to open a new terminal in VS Code\n> \n> （VS Codeで新しいターミナルを開く方法を説明してください）\n\n![VS Codeで新しいターミナルを開く方法を説明するよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image5.png)\n\n### 2. 効率を上げるためにプロンプトを絞り込む\n\nGitLab Duoチャットを人間と同じように考え、あなたの考えや質問に関してできるだけ多くの文脈を伝えられるよう、文章でやり取りしてください。\n\nブラウザで頻繁に検索する方は、クエリに対するこのアプローチをご存知かもしれません。質問を組み立て、さらに用語を追加して範囲を絞り込み、たくさんのタブが表示された上で検索を再開します。 \n\nブラウザ検索では、おそらく4つから5つの検索ウィンドウが表示されるでしょう。\n\n```マークダウン\nc# start project best practices\nc# .gitignore\nc# gitlab cicd \nc# gitlab security scanning \nc# solutions and projects, application and tests\n``` \n\nチャットでの会話でも、同じ戦略を採用できます。より多くの文脈を加え、会話的なアプローチにする必要があります。GitLab Duoチャットでは、1回の会話リクエストで複数の質問ができます。例：上記の検索と同様、新しいC#プロジェクトから始めて、ベストプラクティスを適用し、`.gitignore` ファイルを追加し、CI/CDとセキュリティスキャンを設定する必要があります。チャットでは、質問を1つのリクエストにまとめることができます。\n\n> How can I get started creating an empty C# console application in VS Code? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#, and add security scanning for GitLab. Explain how solutions and projects in C# work, and how to add a test project on the CLI.\n> \n> （VS Codeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示し、GitLabのセキュリティスキャンを追加してください。C#のソリューションとプロジェクトがどのように動作するのかに加え、CLIでテストプロジェクトを追加する方法を説明してください）\n\n![より多くの文脈を加えたチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image37.png)\n\nこの応答で、チャットは会話のフォローアップの質問で具体的な設定例を尋ねるよう提案しています。応用：フォローアップの質問を作成しましょう。同じチャットセッションでは、コンテキストとしてC#を省略することができます。\n\n> Please show an example for a .gitignore. Please show a CI/CD configuration. Include the SAST template.\n> \n>   （gitignoreの例を示してください。CI/CDの設定を示してください。SASTテンプレートを含めてください）\n\n### 3. プロンプトのパターンに従う \n\n「プロンプト命令文、助けを求めて、追加のリクエストをする」というパターンに従ってください。最初の質問ですべての答えが得られるとは限りません。閉塞感を感じないよう、最初は「プロンプト命令文、助けを求める」を繰り返すことから始めましょう。\n\n> I need to fulfill compliance requirements. How can I get started with Codeowners and approval rules?\n> \n> （コンプライアンス要件を満たす必要があります。CODEOWNERSと承認ルールの使い始め方を教えてください）\n\n![CODEOWNERSと承認ルールを使い始めるためのチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image19.png)\n\n回答は役に立つものの、明らかに一般的な内容です。そこで、チーム用の設定について具体的な内容を教えてもらうこともできます。\n\n> Please show an example for Codeowners with different teams: backend, frontend, release managers.\n> \n> (バックエンド、フロントエンド、リリースマネージャーといった異なるチームのCODEOWNERSの例を示してください)\n\n![バックエンド、フロントエンド、リリースマネージャーといった異なるチームのCODEOWNERSの例を示すよう指示するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image31.png)\n\nもう1つの方法は、自分が置かれている状況を説明し、意見を求めることです。STARモデル（状況、タスク、アクション、結果）に従うと、うまく質問ができるでしょう。\n\n> I have a Kubernetes cluster integrated in GitLab. Please generate a Yaml configuration for a Kubernetes service deployment. Explain how GitOps works as a second step. How to verify the results?\n> \n> （GitLabに統合されたKubernetesクラスターがあります。KubernetesサービスをデプロイするためのYAML設定を生成してください。2つ目のステップとしてGitOpsがどのように動作するかを説明してください。結果を検証する方法は？）\n\n![複数の質問を含むチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image27.png)\n\n### 4. ローコンテキストコミュニケーションを使用する\n\n回答するためになるべく多くのコンテキストを提供します。以前の履歴または開かれたソースコードからは、そういった有用なコンテキストが得られない場合もあります。より効率的に質問するために、GitLabのオールリモート環境でのコミュニケーションで使用される[ローコンテキストコミュニケーション](https://handbook.gitlab.com/handbook/company/culture/all-remote/effective-communication/#understanding-low-context-communication)のパターンを適用します。\n\n次の質問の場合、C++プロジェクトにおいて十分なコンテキストを提供できていません。\n\n> Should I use virtual override instead of just override?\n> \n> （単にオーバーライドをつかうのではなく、仮想オーバーライドをつかったほうがいいですか？）\n\n![ユーザーが上書きの代わりに仮想の上書きを使用する必要があるかどうかを尋ねるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image34.png)\n\n代わりに、より多くのコンテキストを追加してみてください。\n\n> When implementing a pure virtual function in an inherited class, should I use virtual function override, or just function override? Context is C++.\n> \n> （継承クラスに純粋な仮想関数を実装する場合、仮想関数の上書きを使用する必要がありますか、それとも単に関数の上書きを使用する必要がありますか？コンテキストはC++です）\n\n![詳細情報を含むチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image36.png)\n\nこの例は、[GitLab Duoコーヒーチャット：抽象的なデータベース処理のためにC++関数をOOPクラスにリファクタリングする](https://youtu.be/Z9EJh0J9358?t=2190)でもご紹介しています。\n\n### 5. 繰り返す\n\nAIは予測できないものです。想定した結果が返されない場合や、コンテキストが不足しているためソースコードの例や設定スニペットが生成されない場合があります。質問を繰り返し、要件を絞り込んでいくことをおすすめします。\n\n以下の例では、C#アプリケーションを作成します。最初の試行では、アプリケーションタイプを指定しませんでした。C#を使用してコンソール/ターミナルだけでなく、UIアプリケーションも作成できます。また、回答結果には、空のサンプルソースコードも表示されませんでした。2つ目に再度入力するプロンプトでは、「コンソール」と「空」の2つの単語を追加します。\n\n> How can I get started creating an C# application in VSCode?\n> \n> （VS CodeでC#アプリケーションを作成するにはどうすればよいですか？）\n> \n> How can I get started creating an empty C# console application in VSCode?\n> \n> （VS Codeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？）\n\nプロンプトの結果は異なります。最初の質問への回答内容は、VS Codeウィンドウの手順に従って開始するのに役立ちますが、ソースコードの場所と変更方法は示されません。改良したプロンプトを改めて入力することで、回答内容が修正され、デフォルトのテンプレートを 「hello world」コードで上書きする方法が示されます。\n\n![修正したプロンプトを改めて入力したチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image28.png)\n\n質問を繰り返したり洗練させることで、アプリケーションコードやテストの例を表示するよう、チャットにリクエストもできます。\n\n> How can I get started creating an empty C# console application in VSCode? Please show an example for application and tests.\n> \n> （VS Codeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？アプリケーションとテストの例を示してください）\n\n![アプリケーションとテストの例を求めるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image3.png)\n\n#### 一般的な質問を繰り返します \n\n一般的な技術的質問を尋ねた場合、GitLab Duoチャットでは対応できないことがあります。次のシナリオでは、Javaのビルドツールとフレームワークに関する提案を得ようとしたものの、うまくいきませんでした。この質問への答えは数多く考えられます。ビルドツールとしてはMaven、Gradleなどがあり、テクノロジースタックや要件によっては[100以上のJavaフレームワーク](https://en.wikipedia.org/wiki/List_of_Java_frameworks)があります。\n\n![Javaのビルドツールとフレームワークに関するチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image2.png)\n\nでは、[Java Spring Boot](https://spring.io/projects/spring-boot)を使った顧客環境に焦点を当てたいと想定してみます。\n\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example.\n> \n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello Worldの例を示してください）\n\n![Hello Worldの例を含め、追加情報を求めるチャットプロンプトと応答](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image26.png)\n\nすでに素晴らしい結果が返って来ています。応用として、プロンプトを繰り返し、アプリケーションのデプロイ方法を尋ね、それぞれのステップでさらに改良を加えてください。別の方法として、フォローアップの会話にする方法もあります。\n\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD.\n> \n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello Worldの例を示してください。CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください）\n> \n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD, using container images.\n> \n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello Worldの例を示してください。コンテナイメージを使用して、CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください）\n> \n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD, using container images. Use Kubernetes and GitOps in GitLab.\n> \n> （JavaのSpring Bootアプリケーションを作りたいです。プロジェクトの構造を説明し、Hello Worldの例を示してください。コンテナイメージを使用して、CI/CDでアプリケーションをビルドおよびデプロイする方法を示してください。示します。GitLabでKubernetesとGitOpsを使用してください）\n### 6. 焦らない\n\n1つの単語または短い文章すると、[このビデオの例に示すように]（https://youtu.be/JketELxLNEw?t=1220）、望ましい結果が得られない場合があります。GitLab Duo Chatは、利用可能なデータから推測を行うことができる場合がありますが、より多くのコンテキストの提供を主張する場合もあります。\n\n例：`labels` はGitLabのドキュメントの内容に一致します。\n\n![ラベルと応答に関するチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image12.png)\n\n指示内容をブラッシュアップしてイシューボードでの使用法についてさらなる改良を行います。\n\n> Explain labels in GitLab. Provide an example for efficient usage with issue boards.\n> \n> （GitLabのラベルを説明してください。イシューボードで効率的に使用できる例をください）\n\n![例と回答を求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image21.png)\n\nまたは、問題を記述し、その後に質問をして、追加の例を尋ねます。\n\n> I don't know how to use labels in GitLab. Please provide examples, and how to use them for filters in different views. Explain these views with examples.\n> \n> （GitLabでラベルを使用する方法が分かりません。さまざまなビューのフィルターにラベルを使用する方法の例をください。これらのビューを例で説明してください）\n\n![問題文と回答を含むチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image10.png)\n\nまた、「はい/いいえ」の質問を避け、代わりに特定のコンテキストを追加します。\n\n> Can you help me fix performance regressions?\n> \n> （パフォーマンスのレグレッションを修正するのを手伝ってもらえますか？）\n\n![パフォーマンスのリグレッションと応答を修正するための助けを求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image18.png)\n\n代わりに、プログラミング言語、フレームワーク、テクノロジースタック、および環境を含む、パフォーマンスレグレッションのコンテキストを提供します。次の例では、数年前の環境を使用していますが、現在でも十分正確です。\n\n> My PHP application encounters performance regressions using PHP 5.6 and MySQL 5.5. Please explain potential root causes, and how to address them. The app is deployed on Linux VMs.\n> \n> （私のPHPアプリケーションは、PHP 5.6とMySQL 5.5を使用してパフォーマンスのリグレッションに遭遇しています。潜在的な根本原因とそれらに対処する方法を説明してください。このアプリはLinux VMにデプロイされています）\n\n![詳細と回答を含むチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image24.png)\n\n### 7. リセットして再起動\n\n時々、チャット履歴を見る限り、意図しない学習経路を辿ってしまったが故に、フォローアップの質問のコンテキストが間違っている場合があります。または、GitLab Duoチャットが回答を提供できない特定の質問をした可能性があります。生成系AIは予測不可能であり、特定の例を提供することができなかったかもしれませんが、将来の応答でそれらを提供していけるようになるでしょう（チャットベータで観察）。基礎となる大規模言語モデル（LLM）は、時には無限ループに陥ってしまう場合もあります。\n\n> How can I get started creating an empty C# console application in VSCode? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#, and add security scanning for GitLab. Explain how solutions and projects in C# work, and how to add a test project on the CLI.\n> \n> （VSCodeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示し、GitLabのセキュリティスキャンを追加してください。C#のソリューションとプロジェクトがどのように機能するのか、CLIでテストプロジェクトを追加する方法を説明してください）\n\n上記の内容で質問をした後、よりカスタマイズされた応答を得るために、質問の範囲を縮小したいと思いました。チャットはコンテキストでチャット履歴を把握しており、以前の回答を参照しているため、期待どおりに機能しませんでした。\n\n> How can I get started creating an empty C# console application in VSCode? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#.\n> \n> （VSCodeで空のC#コンソールアプリケーションを作成するにはどうすればよいですか？.gitignoreと.gitlab-ci.ymlの設定をC#用のステップで表示してください）\n\n![設定例と応答を求めるチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image23.png)\n\nチャットを新しいコンテキストに強制的に追加するには、`/reset` をスラッシュ（/） コマンドとして使用してセッションをリセットし、質問を繰り返してより良い結果を得ていくことになります。`/clean` または `/clear` を使用して、会話内のすべてのメッセージを削除することもできます。\n\n### 8. IDEのスラッシュコマンドで効率化\n\n#### コードを説明する\n\n- 質問：生成されたコードですか？既存のコードですか？従来のコードですか？\n- 回答：[IDEの`/explain`スラッシュ（/） コマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#explain-code-in-the-ide)を使用します。\n- 回答2：より焦点を当てた応答でプロンプトを絞り込む。例： `/explain focus on potential shortcomings or bugs. （/explain 潜在的な欠点やバグに焦点を当てる）`\n\n![/explainスラッシュ（/） コマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/gitlab_duo_chat_slash_commands_explain_01.png)\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image6.png)\n\n#### コードのリファクタリング\n\n- 質問：読みづらいコードですか？長いスパゲッティコードですか？テストカバレッジはゼロですか？\n- 回答：[IDEの`/refactor`スラッシュ（/） コマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#refactor-code-in-the-ide)を使用します。\n- 回答2 ：よりターゲットを絞ったアクションのプロンプトを絞り込む。例：オブジェクト指向パターン：`/refactor into object-oriented classes with methods and attributes`。\n\n![/refactor slashコマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image35.png)\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image30.png)\n\n#### テストを生成\n\n- 質問：テスト可能なコードですが、テストの作成に時間がかかりすぎますか？\n- 回答：[IDEの`/tests`スラッシュ(/) コマンド](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#write-tests-in-the-ide)を使用します。\n- 回答2：特定のテストフレームワーク、またはテストターゲットのプロンプトを絞り込む。プロンプトにリファクタリングに焦点を当てるように指示し、次にテストを生成することもできます。`/tests`はコードを関数にリファクタリングし、テストを生成することに焦点を当てます。\n\n![/testsスラッシュ(/) コマンドのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674351/Blog/Content%20Images/image29.png)\n\n![洗練されたプロンプトでチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image4.png)\n\n完全な開発ワークフローのより実用的な例は、[GitLab Duoの例](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html)のドキュメンテーションで入手できます。\n\n### 9. スラッシュコマンドのプロンプトを絞り込む\n\nこのブログ記事には、洗練されたプロンプトのヒントが数多くあったことでしょう。これらは、AIを活用したワークフロー効率を向上させるための要素の1つです。スラッシュ(/) コマンドを賢く使うことで、GitLab Duoチャットでより良い結果が得られます。\n\nあるお客様は最近、次のように尋ねました。「`/explain` を使用したコードの説明は、コード内にコメントを作成できますか？」 答えは「いいえ」です。ただし、チャットプロンプトを使用してフォローアップの質問をしたり、コード内に記述できるコメント形式でコードの要約を求めることができます。その場合は、言語の指定が必要でしょう。\n\n[curlライブラリを使用したC++ HTTPクライアントコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5cc9bdd65ee8ee16c548bea0402c18f8209d4d06/chat/slash-commands/c++/cli.cpp)の次の例には、より多くのドキュメント（指示内容）が必要です。コード内のコメントを追加して、より洗練した指示内容を/explainコマンドに渡すことで、よりよい結果が得られ、その結果をエディタ内に貼り付けていく、という方法もよいでしょう。\n\n> /explain add documentation, rewrite the code snippet\n> （/explain ドキュメントを追加し、コードスニペットを書き換えてください）\n\n![ドキュメントを追加し、コードスニペットと応答を書き換えるためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image13.png)\n\nまたは、チャットにソースコードを `/refactor` するように依頼し、洗練されたプロンプトを使用して不足しているコードコメントを生成することもできます。\n\n> /refactor add code comments and documentation\n>\n> （/refactor コードのコメントとドキュメントを追加してください）\n\n![ソースコードをリファクタリングし、コードコメントを生成するためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image15.png)\n\n### 10. スラッシュコマンドでクリエイティブに\n\nチャットプロンプトがソースコードまたはプログラミング言語に関する質問への回答が得られない場合は、スラッシュ(/) コマンド `/explain`、`/explain`、`/tests` を試してみて、それらがコンテキスト作りに役に立つかどうかみてみましょう。\n\n以下の例では、C++のコード内でSQLクエリ文字列が1行で作成されます。読みやすさを高め、将来的にはより多くのデータベース列を追加できるようにするには、書式を複数行の文字列に変更すると便利です。\n\n> std::string sql = \"CREATE TABLE IF NOT EXISTS users （id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL）\";\n\nたとえば、次の質問をその後に続けてGitLab Duo Chatに尋ねられます。\n\n> How to create a string in C++ using multiple lines?\u003Cbr>\n>（複数行を使用してC++で文字列を作成する方法）\n\nチャット自体は、説明文とオプションでソースコードの例で回答してくれるでしょう。ただ、この場合は、単にその文字列を\"¥n\"を間に入れて複数行にすればいい、という解釈をするでしょう。でも、私達が求めているのは、そうではなく、ソースコード上で見やすくするために「複数行」にしてほしい、ということですよね。\n\nVSCodeとWeb IDEには、追加のコンテキストの代替案があります。問題のソースコードを選択し、右クリックして、[GitLab Duoチャット]> [リファクタリング]に移動します。これにより、チャットプロンプトが開き、`/refactor`コードタスクがすぐに開始されます。\n\nただし、コードタスクは期待される結果をもたらさない可能性があります。1行のSQL文字列をリファクタリングすることは、読みやすさのために複数行を使用すること、定数を作成することなど、多くを意味するからです。\n\nコードタスクには、プロンプトを絞り込むオプションがあります。`/refactor` コマンドの後にテキストを追加し、GitLab Duoチャットに特定のコードタイプ、アルゴリズム、またはデザインパターンを使用するように指示できます。\n\nもう一度やり直してみましょう。ソースコードを選択し、フォーカスをチャットに変更し、次のプロンプトを入力して、`[Enter]`を押します。\n\n> /refactor into a multi-line written string. Show different approaches for all C++ standards.\n>\n>（/refactor 複数行の書き込み文字列に変換します。すべてのC++標準に異なるアプローチを示します）\n\n![複数行の文字列と応答にリファクタリングするためのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image17.png)\n\n**ヒント：** GitLab Duoのコード提案を使用して、リファクタリング後にソースコードをさらに洗練することも、あるいは、かわりに `/refactor` プロンプトの絞り込みを使用することもできます。\n\n> /refactor into a multi-line written string, show different approaches\n>\n> （/refactor 複数行の文字列に変換し、さまざまなC++標準のアプローチを表示してください）\n>\n> /refactor into multi-line string, not using raw string literals\n>\n> （/refactor 複数行の文字列に変換し、生の文字列リテラルを使用しないでください）\n>\n>/refactor into a multi-line written string. Make the table name parametrizable\n>\n>（/refactor 複数行の書き込み文字列に変換してください。テーブル名はパラメータ化してください）\n\n`stringstream` タイプの代替アプローチは、[GitLab Duoコーヒーチャット：抽象的なデータベース処理のためにC++関数をOOPクラスにリファクタリングする](https://www.youtube.com/watch?v=Z9EJh0J9358)、[MR差分](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-coffee-chat/gitlab-duo-coffee-chat-2024-01-23/-/commit/7ea233138aed46d77e6ce0d930dd8e10560134eb#4ce01e4c84d4b62df8eed159c2db3768ad4ef8bf_33_35)に記載されています。\n\n#### 脆弱性の説明\n\n常に機能するとは限りませんが、セキュリティの脆弱性の説明については、`/explain` スラッシュ(/) コマンドも尋ねることができます。この例では、[Cコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c)には、strcpy()バッファオーバーフロー、ワールド書き込み可能なファイルアクセス許可、競合条件攻撃などの複数の脆弱性が含まれています。\n\n>/explain why this code has multiple vulnerabilitie\u003Cbr>\n>（/explain このコードに複数の脆弱性がある理由を説明してください）\n\n![/コードの複数の脆弱性についてのチャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image20.png)\n\n#### CコードをRustにリファクタリングする\n\nRustはメモリの安全性を提供します。`refactor into Rust` を使用して、脆弱な[Cコード](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c)をRustにリファクタリングするようにDuo Chatに依頼できます。より良い結果を得るために、より洗練されたプロンプトで練習してください。\n\n> /refactor into Rust and use high level libraries\n> \n> （/refactor Rustに変換し、高レベルのライブラリを使用してください）\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687965/Blog/Content%20Images/image8.png)\n\n### ショートカット\n\nこれらのショートカットを読者の環境で試し、GitLab Duoチャットを使用して応用例を試してみてください。\n\n1. CVEからの脆弱性に基づいてコードを調べ、`/explain why is this code vulnerable` を使用して、それが何をし、どのように修正するかを尋ねます。\n**ヒント：** GitLab Duoチャットのコード説明を利用するには、GitLabでオープンソースプロジェクトをインポートしてください。\n2. レガシーコードの移行計画を支援するために、コードを新しいプログラミング言語にリファクタリングしてみてください。\n3. `/refactor into GitLab CI/CD configuration` を使用して、Jenkins設定をGitLab CI/CDにリファクタリングすることもできます。\n\n### 試してみよう\n\nクリッピーのように振る舞うよう、チャットを説得してみてください。\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image22.png)\n\nGitLabのミッション、「誰でも貢献できます」について尋ねてください。\n\n![チャットプロンプト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687469/Blog/Content%20Images/image33.png)\n\n### 詳細\n\nいろいろなところに情報が記載されています。より実用的な例で[GitLab Duoチャットドキュメンテーション](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)を更新し、チャットを含むAI搭載のDevSecOpsワークフローを深く掘り下げる新しい[GitLab Duoの例](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html)セクションを追加しました。\n\nGitLab Duoの学習は、遊び心のあるチャレンジと実際の本番環境のコードを通じて最も効果的に機能します。新しい学習シリーズ、GitLab Duoコーヒーチャットは、2024年も続きます。本人確認ができるまでは、[このYouTubeプレイリスト](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp5uj_JgQiSvHw1jQu0mSVZ)で録画を見ることができます。GitLabのお客様で、GitLab Duoコーヒーチャットに参加して一緒に学ぶことに興味がある場合は、[この計画のエピック](https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/476)でお知らせください。\n\n*監修：小松原 つかさ\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n> GitLab Duoチャットを試してみませんか？[今すぐ無料トライアルを開始](https://about.gitlab.com/solutions/gitlab-duo-pro/self-managed-and-gitlab-dedicated-trial/)。\n",[762,860,861,721,9],"testing","CI",{"slug":863,"featured":93,"template":676},"develop-c-unit-testing-with-catch2-junit-and-gitlab-ci","content:ja-jp:blog:develop-c-unit-testing-with-catch2-junit-and-gitlab-ci.yml","Develop C Unit Testing With Catch2 Junit And Gitlab Ci","ja-jp/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci.yml","ja-jp/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci",{"_path":869,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":870,"content":876,"config":885,"_id":887,"_type":16,"title":888,"_source":18,"_file":889,"_stem":890,"_extension":21},"/ja-jp/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"title":871,"description":872,"ogTitle":871,"ogDescription":872,"noIndex":6,"ogImage":873,"ogUrl":874,"ogSiteName":690,"ogType":691,"canonicalUrls":874,"schema":875},"【トップ10】プロダクトマネージャーが一挙紹介！GitLabワークフロー テクニック","GitLabのプロダクトマネージャーが、GitLab DevSecOpsプラットフォームを効率的に操作し、チームコラボレーションを促進できるお気に入りのテクニックを一挙ご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099361/Blog/Hero%20Images/Blog/Hero%20Images/lightvisibility_lightvisibility.png_1750099361252.png","https://about.gitlab.com/blog/top-10-gitlab-workflow-hacks-you-need-to-know","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"【トップ10】プロダクトマネージャーが一挙紹介！GitLabワークフロー テクニック\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-04-09\",\n      }",{"title":871,"description":872,"authors":877,"heroImage":873,"date":879,"body":880,"category":14,"tags":881,"updatedDate":884},[878],"Amanda Rueda","2024-04-09","ソフトウェア開発の世界では、「効率」とは単に速く動くことではなく、スマートなナビゲーションのことも意味します。GitLabのプロダクトマネージャーとして、本日ご紹介する私のお気に入りのGitLab機能トップ10は、必要であることに気づいていなかったワークフローハックかもしれません。\n\nこれらのテクニックをぜひ身につけて、チーム内の生産性とコラボレーションを新たなレベルに引き上げてみませんか。\n\nそれでは一つずつ見ていきましょう。\n\n## 1. コメントの解決\n\nコメントの解決は、マージリクエスト上だけではありません。イシューへのコメントを解決することで、ノイズを大幅に減らし、タスク管理を合理化できます。特にフィードバックを効率的に管理するのに便利です。\n\n> __お気に入りの理由：__ コメントを解決することは、イシューのノイズを減らすだけでなく、タスクを管理する効果的な方法でもあるからです。\n> \n> **ユースケース：** コメントを解決することは、フィードバックを集めているイシューにとって有効な手法です。フィードバックに返信してリンクを提供し、コメントを解決して次のイシューに進みましょう。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/discussions/#resolve-a-thread)__\n\n![解決コメントの例 - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099376147.gif)\n\n\u003Cp>\u003C/p>\n\n## 2. 内部コメント\n\n外部の人に見られることなく、チームと直接相談することができます。イシューまたはマージリクエスト内のディスカッションは非公開にし、コメントはチームメンバーのみが閲覧できるようにしましょう。透明性とプライバシーのバランスが絶妙です。\n\n> __お気に入りの理由：__ プライバシーと透明性のバランスをとりながら、より幅広い議論をコミュニティに投げかけられるからです。\n> \n> __ユースケース：__ 例えば製品のローンチを調整する際、マーケティングチームが社内のコメントを使ってメッセージングや戦略について話し合い、練り直すことができます。ドラフトモード中もディスカッションは一元管理され、チームも簡単にアクセスできますよ。\n> \n> **[詳細はこちら](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note)**\n\n![内部コメント例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099376148.png)\n\n\u003Cp>\u003C/p>\n\n## 3. and/orフィルター\n\n一覧ページでレコードを検索する場合、and/orフィルターを使用することで、ノイズを切り分け、探しているものを素早く効率的に見つけることができます。\n\n> __お気に入りの理由：__ 必要なものを的確に見つけ、効率的で合理的なワークフローを実現するからです。\n> \n>**ユースケース：** 特定のグループに割り当てられた、特定のイニシアチブに関連する機能のイシューを検索します。\n>\n> __[詳細はこちら](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#filter-with-the-or-operator)__\n\n![および/またはフィルター例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/and_or__1__aHR0cHM6_1750099376152.gif)\n\n\u003Cp>\u003C/p>\n\n## 4. URLの自動展開\n\nGitLabのURLの末尾に '+' または '+s' を追加すると、そのURLは情報スニペットに変換され、チームメイトがページを離れることなく進捗を共有できるようになります。\n\n> __お気に入りの理由：__ URLのX線透視をするようなもので、クリックすることなく重要な情報を見ることができるからです。\n>\n> **ユースケース：** コメントで進捗状況を共有したい場合、リンクに '+s' を加えるだけで、誰もが即座に状況を把握できます。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/markdown.html#show-the-issue-merge-request-or-epic-title-in-the-reference)__\n\n![URLの自動展開の例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099376154.gif)\n\n\u003Cp>\u003C/p>\n\n## 5. クイック アクション\n\nシンプルなテキストコマンドを使用したショートカットであるクイック アクションでは、説明やコメント欄から直接、ユーザーの割り当てやラベルの追加などのタスクを実行できるため、クリック数と時間を減らせます。\n\n> __お気に入りの理由：__ クリック数と時間を減らして時間を節約できるからです。\n> \n> **ユースケース：** 新しいイシューを作成する際、クイック アクションを使用して、ラベル、マイルストーンを自動的に追加し、レコードを保存する際にエピックに接続します。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/project/quick_actions.html)__\n\n![クイック アクションの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099376156.gif)\n\n\u003Cp>\u003C/p>\n\n## 6. 一括編集\n\n複数のイシューに対して、ラベルの適用、担当者の変更、マイルストーンの更新を一度に行うことができます。この機能により、面倒になりがちなアップデートが簡単になり、数多くのイシューを素早く調整できるようになります。\n\n> __お気に入りの理由：__ 面倒な更新作業が、簡単かつ迅速に行えるようになるからです。\n> \n> **ユースケース：** スプリントのイシューすべてにレビューが必要なタグを付ける必要がある場合、フィルターをかけて、すべて選択し、ラベルを一括で追加するだけ。とても簡単です。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-edit-issues-from-a-project)__\n\n![一括編集の例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099376157.gif)\n\n\u003Cp>\u003C/p>\n\n## 7. エピックスイムレーン\nボード上のエピックでイシューをグループ化すると、進捗状況を視覚的に追跡し、議論できます。レビューやスタンドアップの際に、作業同士のつながりをわかりやすくします。\n\n> __お気に入りの理由：__ ボードを確認することで、仕事の背景を容易に理解できるからです。\n> \n> **ユースケース：** スタンドアップレビュー中にエピックごとにグループ化し、親イニシアチブと簡単に連携します。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issues-in-swimlanes)__\n\n![エピックスイムレーンの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099376158.gif)\n\n\u003Cp>\u003C/p>\n\n## 8. Wikiダイアグラム\n\n作成が簡単なダイアグラムを使用して、Wikiページに直接アイデアとワークフローを示します。この機能により視覚的に学習でき、複雑な概念を簡素化できます。\n\n> __お気に入りの理由：__ 非常にユーザーフレンドリーで柔軟性があるからです。\n> \n> **ユースケース：** 新しい機能のワークフローを概説する場合は、チーム全員が明確に理解できるように、Wikiページに直接描画します。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/administration/integration/diagrams_net.html)__\n\n![WiKiダイアグラムの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099376159.gif)\n\n\u003Cp>\u003C/p>\n\n## 9. 表の作成\n\n表の作成にはマークダウンを使用しないでください。リッチテキストエディターを使用すると、表を簡単に挿入および書式設定でき、ドキュメントをより明確に構造化できます。\n\n> __お気に入りの理由：__ これを使えば、表作成の手間が一気に省け、数回のクリックできれいに整理された更新をかけられます。\n> \n> **ユースケース：** スプリントのレトロスペクティブ（振り返り）を作成する際、表を素早く挿入して、フィードバック、アクションアイテム、オーナーを整理することで、全員がレビュープロセスをスムーズに行えます。\n> \n> __[詳細はこちら](https://docs.gitlab.com/ee/user/rich_text_editor.html#tables)__ \n\n![テーブル作成の例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099376160.gif)\n\n\u003Cp>\u003C/p>\n\n## 10. ビデオとGIFの埋め込み\n\nイシューやエピックの説明やコメントにGIFやYouTube動画を埋め込んで、コミュニケーションに動的な要素を加えましょう。\n\n> __お気に入りの理由：__ 時にはGIFや動画の方が言葉よりも伝わりやすいですよね。\n> \n> **ユースケース：** UIのバグを説明する時は、YouTube動画を埋め込んで、提案する機能改善の手順を簡単に示しましょう。\n\n![ビデオとGIFの埋め込みの例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/gif__1__aHR0cHM6_1750099376161.gif)\n\n\u003Cp>\u003C/p>\n\n## これらの機能をもっと活用しましょう！\n\nこれらの機能は、GitLabの包括的なツールキットのほんの一部にすぎません。ツールキットは効率を高め、より良いコラボレーションを促進するように設計されています。十分に活用されていないかもしれませんが、ワークフローに大きな影響を与える可能性があります。日々のルーティーンにぜひ取り入れてくださいね。\n\n*監修：大井 雄介 （GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n> GitLabを使用してDevSecOpsワークフローを強化しよう！[GitLab Ultimateを【30日間無料】で試す](https://gitlab.com/-/trial_registrations/new)。\n",[762,699,882,883],"features","workflow","2024-05-29",{"slug":886,"featured":6,"template":676},"top-10-gitlab-workflow-hacks-you-need-to-know","content:ja-jp:blog:top-10-gitlab-workflow-hacks-you-need-to-know.yml","Top 10 Gitlab Workflow Hacks You Need To Know","ja-jp/blog/top-10-gitlab-workflow-hacks-you-need-to-know.yml","ja-jp/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"_path":892,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":893,"content":899,"config":906,"_id":908,"_type":16,"title":909,"_source":18,"_file":910,"_stem":911,"_extension":21},"/ja-jp/blog/jenkins-to-gitlab-migration-made-easy",{"title":894,"description":895,"ogTitle":894,"ogDescription":895,"noIndex":6,"ogImage":896,"ogUrl":897,"ogSiteName":690,"ogType":691,"canonicalUrls":897,"schema":898},"JenkinsからGitLabへのスムーズな移行","JenkinsからGitLabへ移行するメリットと簡単に行える移行手順を分かりやすく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"JenkinsからGitLabへのスムーズな移行\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-01\",\n      }",{"title":894,"description":895,"authors":900,"heroImage":896,"date":902,"body":903,"category":14,"tags":904,"updatedDate":905},[901],"Fernando Diaz","2024-02-01","GitLabは、最も包括的なAI搭載のDevSecOpsプラットフォームです。GitLabには、ソフトウェアの計画、開発、セキュリティ確保、迅速なリリースに必要な機能がすべて揃っています。\n\nプラットフォームを活用することで、さまざまなツールの統合（DIY DevOps）に苦労することなく、ソフトウェア開発ライフサイクル（SDLC）を実現できます。一方、Jenkinsはプラットフォームではないため、SDLCを実現させるには他のツールと組み合わせる必要があります。このようなDIY DevOpsのアプローチではツールチェーンの複雑さが増し、以下のようなデメリットが生じます。\n\n- ツールの統合やオーケストレーションに特別なサポートが必要\n- 個々のツールの保守、アップグレード、セキュリティ対策の負担が大きい\n- 組織における変革の進捗を正確に把握しづらい\n- デベロッパーエクスペリエンスが悪化する\n- 管理コスト、時間、予算がかかる\n- 生産性が低下する\n- 頭の切り替えが必要となり、コラボレーションの効率が下がる\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>DIY DevOpsとDevSecOpsプラットフォームの比較\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nこうした理由から、Jenkinsを使用する多くのチームがDevSecOpsプラットフォームへの移行を検討しています。より強力で、信頼性と安全性の高いソリューションを求めているなら、GitLabが最適です。GitLabは無料で使い始められ、組織のニーズに応じたさまざまなサブスクリプションプランが用意されています。GitLab のプランや機能の詳細については、[価格ページ](https://about.gitlab.com/ja-jp/pricing/)をご覧ください。\n\nこのブログ記事では、以下について学べます。\n- 移行計画の立て方\n- 他のソースコード管理（SCM）ツールからGitLabへリポジトリを移行する方法\n- JenkinsからGitLabへCI/CDパイプラインを移行する方法\n- 移行に関するその他の考慮事項\n\n### 移行計画を立てる\n\n他のツールからGitLab CI/CDへ移行を開始する前に、まず移行計画を立てる必要があります。移行計画は、期待値を明確にするための重要な技術的ステップです。CI/CDツールは、それぞれアプローチや構造、技術的な仕様が異なるため、単純にデータを1対1でマッピングできるわけではありません。適切な移行計画を立てることでもたらされるメリットを次に挙げます。\n\n- 移行の目的を明確にして共有することで、なぜ移行が価値のある取り組みなのかをユーザーに理解してもらいやすくなります。作業が完了すればその価値は明らかになりますが、移行中の段階においても認識してもらうことが重要です。\n- 関係する経営陣の支援や合意が得られ、移行の重要性や目的が全員に伝わりやすくなります。\n- 移行後の環境の違いについて、ユーザーが理解を深める時間を確保できます。\n- 移行の順序を決めたり、一部の移行を後回しにしたりすることで、未移行や部分的な移行状態が長引くのを防ぎます。\n- GitLab CI/CDにより得られる改善点やメリットを文書化し、移行の一環として既存の実装を更新できます。\n\n適切な移行計画を策定することで、業務への影響を最小限に抑えながら、GitLabへ徐々に移行できます。具体的には、JenkinsとGitLabを併用しつつ、一部のプロジェクトをGitLabに移し、Jenkinsの利用を徐々に減らしていくといった計画が考えられます。\n\n### 変更管理プロセスを定める\n\n移行計画では、効果的な変更管理プロセスを定める必要があります。デベロッパー、IT運用担当者、クラウド管理者、セキュリティ担当者、品質エンジニアなどの関係者は、GitLabの使用経験がなく、なぜあなたや経営陣がこの移行を決定したのかを理解していないかもしれません。\n\nこの移行によって影響を受ける人々に、以下の点を理解してもらう必要があります。\n- __なぜ__：この変更が行われるのか\n- __何が__：移行後の状態として想定されているのか\n- __どのように__：現在の状況から移行後の状態にするのか\n- __どこで__：追加の情報やサポートを得られるのか\n\n移行の影響を受ける各部門のへの影響を理解し、その変化を管理するには、以下の手順が必要です。\n\n- __現在の状況を分析する__：まず、現在のプロセスを文書化し、基準となる指標を収集します。次に、主要なチームメンバーへのインタビューを通じて、CI/CDにおいてうまく機能している点と機能していない点を特定します。課題を特定したら、定量的、定性的の両面から記録します。移行のビジョンと変更の理由を関係者に理解してもらう必要があるため、課題は明確に定義すればするほど、社内の合意を得やすくなります。\n- __ビジョンを確立する__：現在の課題を、定量的な基準値と定性的なチームメンバーのフィードバックで明確にしたら、次に将来のビジョンを共有します。ビジネスの成功指標と結びつけて、なぜこの移行が重要なのかを説明します。また、望ましい状態の具体的な例をライブデモや録画を通じて示し、現在の状況と比較します。さらに、このメッセージを定着させるために、チャットグループ、全社ミーティング、メール通知、GitLab上のバナーメッセージなど、複数のチャネルやメディアを活用して発信します。\n- __従業員を教育する__：GitLabの専門家が実施する[GitLab CI/CDトレーニング](https://about.gitlab.com/services/education/gitlab-ci/)に投資し、[GitLab認定](https://levelup.gitlab.com/pages/certifications)を活用して、知識の習得度や定着度を測定します。\n- __ロードマップとリソースを共有する__：チームメンバーに対し、移行の予定タイムラインや、移行に役立つリソースを案内します。また、チャットグループ、Q&Aボード、GitLabインフルエンサーによるオフィスアワーなど、コミュニティのリソースも案内し、質問に対する回答やサポートを得られる環境を整えます。さらに、早期に移行したチームを対象とした報酬制度を導入して、移行体験を他のアプリケーショングループと共有してもらうのも効果的です。\n\n移行の開始時にこれらの要素が揃っていれば、成功へ向けたしっかりとした基盤を築けます。\n\n### 移行目標を設定する\n移行を実施する前に、目標とそれを達成する方法をしっかりと把握しておく必要があります。たとえば、以下のような質問に対する答えを用意しておくことが重要です。\n- 移行のタイムラインはどのようになっているのか？\n- 現在のJenkinsサーバーの構成はどうなっているか？\n- 移行対象のプロジェクトはいくつあるか？\n- パイプラインの複雑さはどの程度か？\n- 外部依存関係、複数のパイプライントリガー、並列ビルドなどが必要か？\n- コードのデプロイ方法とデプロイ先は？\n- デプロイするコードのリリースやレビューのプロセスはどのようになっているか？\n- Jenkinsに統合されているのか、それともJenkinsがトリガーする別のワークフローなのか？\n- パイプラインの成功に必要なビルドアーティファクトやバイナリは何か？\n- 現在Jenkinsのジョブで使用しているプラグインは何か？\n- Jenkinsエージェントにインストールされているソフトウェアは何か？\n- 現在使用しているSCMソリューションは何か？\n- Jenkinsのジョブで共有ライブラリを使用しているか？\n- Jenkinsで使用している認証方法は何か（Basic認証、LDAP/AD、SSOなど）？\n- パイプラインからアクセスする必要がある他のプロジェクトはあるか？\n- Jenkinsが外部サービスと連携する際に使用するアクセス用認証情報はあるか？\n\nこれらの質問に答えることで、移行の進め方、所要時間、どこから始めるべきかが明確になります。移行計画を立て、期待値や想定される課題をしっかり把握できたら、いよいよ移行プロセスの開始です。\n\n### 移行の前提要件\n移行計画を作成し、移行に関するすべての期待事項を整理できたら、GitLabのセットアップを開始できます。移行の前に推奨される前提要件をいくつかご紹介します。\n- GitLabに慣れる。[GitLab CI/CDの主な機能](https://docs.gitlab.com/ee/ci/index.html)を読んで理解を深める。\n- チュートリアルを活用し、最初の[GitLabパイプライン](https://docs.gitlab.com/ee/ci/quick_start/index.html)と、静的サイトをビルド、テスト、デプロイする[より複雑なパイプライン](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)を作成する。\n- [.gitlab-ci.ymlのキーワード参照](https://docs.gitlab.com/ee/ci/yaml/index.html)を確認する。\n- GitLabをセットアップし、適切に設定する。\n- GitLabインスタンスをテストする。\n\nGitLabの理解を深め、インスタンスの設定が完了したら、移行計画に沿ってJenkinsからGitLabへのプロジェクト移行を進めることができます。その際、GitLabインスタンスがGitLabのベストプラクティスや[リファレンスアーキテクチャ](https://docs.gitlab.com/ee/administration/reference_architectures/)に従って適切に設定されていることを確認してください。\n\n### リポジトリをGitLabに移行する\nJenkinsの主な欠点の1つは、SCMソリューションがないことです。Jenkinsを使用している場合、別のSCMソリューションにコードを保存し、そこにJenkinsからアクセスする必要があります。一方、GitLabにはSCMが組み込まれているため、Jenkinsからの移行に伴い、従来使用していたSCMソリューションからも移行でき、さらなるコスト削減につながります。\n\nGitLabには、リポジトリやそのメタデータを簡単にGitLabへと移行できるツールが用意されています。プロジェクトをGitLabへ移行する際に活用できるインポーターは以下のとおりです。\n\n- [GitHub](https://docs.gitlab.com/ee/user/project/import/github.html)\n- [別のGitLabインスタンス](https://docs.gitlab.com/ee/user/project/settings/import_export.html)\n- [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html)\n- [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html)\n- [FogBugz](https://docs.gitlab.com/ee/user/project/import/fogbugz.html)\n- [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html)\n- [Jira（イシューのみ）](https://docs.gitlab.com/ee/user/project/import/jira.html)\n- [manifestファイルによるリポジトリのインポート](https://docs.gitlab.com/ee/user/project/import/manifest.html)\n- [URLによるリポジトリのインポート](https://docs.gitlab.com/ee/user/project/import/repo_by_url.html)\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\" alt=\"GitHub to GitLab Repo Exporter\">\n   \u003Cfigcaption>GitHubからGitLabへのリポジトリエクスポーター\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n各インポーターは、プロジェクトから異なる種類のデータをインポートします。インポーターによりGitLabへ移行できるデータの詳細については、[インポートとプロジェクトの移行に関するるドキュメント](https://docs.gitlab.com/ee/user/project/import/)を参照してください。さらに、[グループやプロジェクトのインポートを自動化](https://docs.gitlab.com/ee/user/project/import/#automate-group-and-project-import)したり、組織のニーズに合わせたカスタムソリューションを構築したりすることも可能です。\n\n- [プロフェッショナルサービス](https://about.gitlab.com/ja-jp/services/)\n- [移行ユーティリティ](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n- [移行に関するよくある質問](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n### リポジトリを移行する方法\nGitLabには組み込みのインポーターが用意されており、リポジトリの移行は簡単に行えます。例として、GitHubからGitLabへリポジトリをコピーし、[そのリソース](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data)（イシュー、プルリクエスト、マイルストーンなど）も含めて移行する方法をご紹介します。別のGitHubからGitLabへリポジトリを移行するには、以下の手順に従ってください。\n\n1. 左側のサイドバーの上部で、**新規作成**（+）を選択します。\n2. 「GitLab」セクションで**新規プロジェクト/リポジトリ**を選択します。\n3. **プロジェクトのインポート**を選択します。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>インポートするプロジェクトの選択\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n4. **GitHub**ボタンをクリックします。\n- GitLab Self-Managedを使用している場合は、[GitHubインポーターを有効にする](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources) 必要があります。\n    - 他のインポーターも同様の方法で開始できます。\n5. 次に、以下のいずれかの方法で認証します。\n    - GitHub OAuthで認証する場合：**GitHubで認証**を選択します。\n    - GitHubのパーソナルアクセストークンを使う場合：\n       - [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new)にアクセスします。\n       - **ノート**フィールドにトークンの説明を入力します。\n       - リポジトリスコープを選択します。\n       - オプションとしてコラボレーターをインポートするには、**read:org**スコープを選択します。\n       - **トークンの生成**ボタンをクリックします。\n       - GitLabのインポートページの「パーソナルアクセストークン」フィールドに、GitHubのパーソナルアクセストークンを貼り付けます。\n6. **認証**ボタンをクリックします。\n7. 移行するアイテムを選択します。\n8. 移行するプロジェクトと移行先を選択します。\n9. **インポート**ボタンを押します。\n\nこれで、インポートされたプロジェクトがワークスペースに追加されます。GitHubからGitLabへの移行に関する詳しいガイドについては、こちらの動画をご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nリポジトリの移行が完了したら、JenkinsのパイプラインでGitLab内のJenkinsfileを活用できるように設定できます。これは、Jenkinsのパイプライン設定メニューから、新しくインポートしたプロジェクトのリポジトリURLを指定することで実行できます。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\" alt=\"Jenkins Pipeline SCM settings\">\n   \u003Cfigcaption>JenkinsパイプラインのSCM設定\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nの方法は、移行の初期段階でもJenkinsの既存の機能を維持しながらGitLabと並行して使用できるため、CI/CD機能の移行作業中にサービスが中断されるのを防げます。\n\nさらに、[GitLab Jenkinsプラグイン](https://plugins.jenkins.io/gitlab-plugin/)を活用することで、移行をスムーズに進めることができます。このプラグインを使用すると、GitLabからJenkinsのビルドをトリガーしたり、ビルドのステータスを取得したりできるようになります。\n\n### CI/CDパイプラインを移行する\nリポジトリの移行が完了したら、今度はJenkinsのパイプラインをGitLabへ移行できます。このプロセスは比較的シンプルですが、JenkinsとGitLabの両方の概念や構文を理解する必要があります。\n\nJenkinsには、パイプラインを定義するための構文として宣言型とスクリプト型の2種類があります。今回は、最も一般的に使用されている宣言型パイプラインからの移行方法を解説します。\n\n### パイプラインを段階的に移行する\nこのチュートリアルでは、Jenkinsfile（Groovy）とGitLab CI/CDの設定ファイル（YAML）を比較しながら、Go言語で書かれたマイクロサービスをビルド、テスト、デプロイする方法を分析します。その後、GitLabでパイプラインを有効化し、実際の動作を確認します。このパイプラインは以下の処理を行います。\n\n- **alpine**タグ付きのGo言語コンテナイメージを使用する\n- Go言語のコードを実行可能なバイナリにビルドするジョブを実行する\n   - ビルドしたバイナリをアーティファクトとして保存する\n- ユニットテストを実行するジョブを実行する\n- stagingステージにデプロイするジョブを実行する\n   - コミットが**staging**ブランチに向けたものである場合のみ実行される\n   - **test**ステージが成功した後に開始される\n   - 以前のジョブで作成された実行可能なバイナリアーティファクトを使用する\n\n以下に、JenkinsとGitLabのパイプライン定義とコメントを示します。実際のパイプラインの動作は[Meow Migrationプロジェクト](https://gitlab.com/gitlab-de/projects/blogs/meow-migration)で確認できます。\n\nでは、Groovyで記述されたJenkinsfileを見ていきましょう。\n\n```  \n// 宣言型パイプラインの\n// トップレベルを定義します。\npipeline {\n\n  // ジョブ内で明示的に定義されていない場合に\n  // デフォルトで使用するエージェントを\n  // 指定します。\n    agent any\n\n  // 数値順に実行される\n  // ステージを定義します。各ステージは\n  // 1つのジョブのみを実行します。\n    stages {\n\n    // ステージの名前を定義します。\n        stage('build') {\n      // このジョブで使用する\n      // コンテナイメージを定義し、\n      //デフォルトの'agent any'を上書きします。\n      // 実行にはJenkins Docker\n      // プラグインの設定が\n      // 必要です。\n            agent { docker 'golang:alpine' }\n\n      // ステージが実行される際に\n      // 実行する処理の順序を\n      // 定義します。\n            steps {\n                sh 'go build -o bin/meow-micro'\n                sh 'chmod +x bin/meow-micro'\n            }\n\n      // ステージ完了後に\n      // 実行する処理を定義します。\n            post {\n              always {\n\n        // 他のジョブで使用するために\n        // ステージアーティファクトを\n        // 保存します。\n                archiveArtifacts artifacts: 'bin/meow-micro'\n                onlyIfSuccessful: true\n              }\n            }\n        }\n\n    stage('test') {\n            agent { docker 'golang:alpine' }\n            steps {\n                sh 'go test .'\n            }\n        }\n\n        stage('deploy') {\n      // このジョブを\n      // 実行するための\n      // 条件を定義します。この場合、\n      // stagingブランチでのみ\n      // デプロイジョブが実行されます。\n            when {\n              branch 'staging'\n            }\n            steps {\n                echo 'Deploying meow-micro to staging'\n        // buildステージで保存した\n        // アーティファクトを使用します。\n                sh './bin/meow-micro'\n            }\n        }\n    }\n}\n```\n\nでは、同じ機能をGitLabで作成する方法について見ていきましょう。\n\n```\n# ジョブ内で明示的に定義されていない場合に\n# デフォルトで使用するイメージを\n# 指定します。\ndefault:\n  image: alpine:latest\n\n# 実行するステージの順序を定義します。\n# 各ステージには複数のジョブを含めることができます。\nstages:\n  - build\n  - test\n  - deploy\n\n# ジョブ名を定義します。\ncreate-binary:\n # このジョブが実行されるステージを定義します。\n  stage: build\n # このジョブで使用するコンテナイメージを定義し、\n # デフォルトの設定を上書きします。\n  image: golang:alpine\n # ジョブ実行時に実行する\n # 一連の手順を定義します。\n  script:\n    - go build -o bin/meow-micro\n    - chmod +x bin/meow-micro\n # 他のジョブで使用するために\n # ジョブのアーティファクトを保存します。\n  artifacts:\n    paths:\n      - bin/meow-micro\n    expire_in: 1 week\n\nunit-tests:\n  stage: test\n  image: golang:alpine\n  script:\n    - go test .\n # ジョブの実行後に実行するコマンドを\n # 定義します。\n after_script:\n  - echo \"Tests Complete\"\n\nstaging-deploy:\n  stage: deploy\n # ジョブの実行前に実行するコマンドを\n # 定義します。\n  before_script:\n    - apk update\n  script:\n    - echo \"Deploying meow-micro to staging environment\"\n    - ./bin/meow-micro\n # このジョブが実行される\n # 条件を定義します。この\n # 場合、stagingブランチでのみ\n # staging-deployジョブが実行されます。\n  rules:\n    - if: $CI_COMMIT_BRANCH == 'staging'\n # buildジョブで保存されたアーティファクトを\n # このジョブで使用できるようにします。\n  artifacts:\n    paths:\n      - bin/meow-micro\n```\n\nご覧のとおり、JenkinsとGitLabの構文には多くの共通点があり、パイプラインの移行は比較的簡単です。ここでは基本的な例を紹介しましたが、両ツールの詳しい[機能や概念の比較](https://docs.gitlab.com/ee/ci/migration/jenkins.html#comparison-of-features-ad-concepts)もぜひご確認ください。\n\nJenkinsからGitLabへのマッピング方法を理解したところで、GitLabで同じ機能を持つパイプラインの作成を始めましょう。以下の手順でCI/CDを移行できます。\n\n##### 1. 先程GitLabに移行したリポジトリを開きます。\n- 左側のサイドバー上部で**検索または移動先…** を選択します。\n- プロジェクトを検索し、開きます。\n\n##### 2. [パイプラインエディタ](https://docs.gitlab.com/ee/ci/pipeline_editor/)を開きます。\n- 左側のサイドバーから**ビルド > パイプラインエディタ**を選択します。\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png\" alt=\"Pipeline editor menu\">\n   \u003Cfigcaption>パイプラインエディタのメニュー\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- **パイプラインの設定** ボタンをクリックします。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\" alt=\"Configure pipeline selection\">\n   \u003Cfigcaption>「パイプラインの設定」を選択\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 3. [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/)に入力します。\n- GitLab CIのパイプラインコードを追加します。\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png\" alt=\"Pipeline editor input\">\n   \u003Cfigcaption>パイプラインエディタへの入力\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- 構文が正しいか検証します。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\" alt=\"Pipeline syntax validation\">\n   \u003Cfigcaption>パイプライン構文の検証\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- パイプラインの構造を視覚化して確認します。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\" alt=\"Pipeline visualization\">\n   \u003Cfigcaption>パイプラインの視覚化\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 4. ファイルをmainブランチにコミットします。\n- コミットメッセージを追加します。\n- ブランチがmainになっていることを確認します。\n- 「変更をコミットする」ボタンをクリックします。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\" alt=\"Commit changes dialog\">\n   \u003Cfigcaption>「変更をコミットする」のダイアログ\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nファイルがマージされると、定義されたパイプラインが実行されます。プロジェクトページの**ビルド > パイプライン**から、実行中の[パイプラインを確認](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines)できます。今回は**main**ブランチで実行されているため、**create-binary**とunit-testsのジョブのみが表示されます。**staging-deploy**のジョブは、stagingブランチでのみ実行されます。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\" alt=\"Pipeline running on main branch\">\n   \u003Cfigcaption>mainブランチで実行中のパイプライン\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nstagingブランチを作成すると、以下のパイプラインが開始されるのを確認できます。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\" alt=\"Pipeline running on staging branch\">\n   \u003Cfigcaption>stagingブランチで実行中のパイプライン\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nジョブをクリックすると、その出力を確認できます。\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\" alt=\"create-binary job output\">\n   \u003Cfigcaption>create-binaryジョブの出力\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\" alt=\"unit-tests job output input\">\n   \u003Cfigcaption>unit-testsジョブの出力\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\" alt=\"staging-deploy job output\">\n   \u003Cfigcaption>staging-deployジョブの出力\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nこのように、create-binaryジョブで保存されたアーティファクトが、staging-deployジョブで使用されることが確認できます。これだけの手順で、JenkinsのパイプラインをスムーズにGitLabへ移行できます！\n\n### 移行に関するその他の考慮事項\nデプロイプロセスをよりシンプルにするために役立つポイントとして、以下の点を考慮することをおすすめします。\n\n- タスクをそのまま1:1でGitLabのジョブに移行しようとしない：既存のパイプラインが何を行っているのか、どのような問題を解決しているのかを整理し、理解する時間を確保することが重要です。\n\n- 一部のJenkinsジョブは複雑すぎてすぐにGitLabに移行できない場合がある：そのため、[GitLab Jenkinsプラグイン](https://plugins.jenkins.io/gitlab-plugin/)を活用し、JenkinsのパイプラインをGitLabから直接起動し、結果を表示できるようにするとよいでしょう。これにより、一部の処理を徐々にGitLabに移行し、最終的にパイプライン全体をGitLabへ統合できます。\n\n- GitLabが提供する組み込みテンプレートを活用し、[セキュリティスキャナーやコード品質チェック](https://docs.gitlab.com/ee/user/application_security/)を最初から導入する：これにより、セキュリティのシフトレフトを行い、漏洩のリスクを低減できます。\nまた、CI/CDの設定を過度に複雑にしないようにし、すべての機能を一度に活用しようとするのではなく、コードをモジュール化し、複数の小さなステップに分けて導入するようにしてください。\n\n- モニタリングとガバナンスを最初から実装する。\n\n- GitLab Runner（Go）はJenkinsエージェント（Java）とは動作が異なる可能性があることを理解する：CPU使用率やメモリ消費量が異なる可能性があるため、時間をかけて比較しながら調整する必要があります。\n\n- 自動スケーリングの導入を検討し、週末や業務時間外に不要なリソースをシャットダウンすることを検討する。\n\n- ジョブのコンテナ化を進め、アプリケーション開発をモダナイズする：現在ではJenkinsのジョブはコンテナ上ではなく、仮想マシン（VM）として動作するJenkinsエージェント上で実行されます。\n\nこのリストはすべての考慮事項を網羅しているわけではありませんが、移行を進めるうえで重要なポイントを押さえています。さらにサポートが必要な場合は、GitLabの[プロフェッショナルサービス](https://about.gitlab.com/ja-jp/get-help/)を活用し、移行プロセスをスムーズに進めることも可能です。\n\n### 関連リンク\nここまでお読みいただきありがとうございます！本ガイドが、JenkinsからGitLabへ移行するメリットと手順を理解する助けとなれば幸いです。まだ迷っている方は、ぜひ[GitLabの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)でDevSecOpsプラットフォームの価値を実感してください！\n\nさらに詳しく知りたい方のために、GitLabの機能やDevSecOpsプラットフォームのメリット、Jenkinsからの移行に関する情報を学べるリソースをいくつかご紹介します。\n\n- [Jenkinsからの移行（英語）](https://docs.gitlab.com/ee/ci/migration/jenkins.html)\n- [移行計画の立て方（英語）](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html)\n- [GitLabプロジェクトインポーター（英語）](https://docs.gitlab.com/ee/user/project/import/)\n- [チュートリアル：簡単にできるGitHubからGitLabへの移行（英語）](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n- [動画：簡単にできるGitHubからGitLabへの移行（英語）](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n- [JenkinsからGitLabへ: CI/CD環境をモダナイズするための究極ガイド（英語）](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n\n\u003Cbr>\n\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\u003Cbr>\n",[111,9],"2025-04-15",{"slug":907,"featured":93,"template":676},"jenkins-to-gitlab-migration-made-easy","content:ja-jp:blog:jenkins-to-gitlab-migration-made-easy.yml","Jenkins To Gitlab Migration Made Easy","ja-jp/blog/jenkins-to-gitlab-migration-made-easy.yml","ja-jp/blog/jenkins-to-gitlab-migration-made-easy",{"_path":913,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":914,"content":920,"config":928,"_id":930,"_type":16,"title":931,"_source":18,"_file":932,"_stem":933,"_extension":21},"/ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture",{"title":915,"description":916,"ogTitle":915,"ogDescription":916,"noIndex":6,"ogImage":917,"ogUrl":918,"ogSiteName":690,"ogType":691,"canonicalUrls":918,"schema":919},"マイクロサービスアーキテクチャの基本とそのメリット","マイクロサービスアーキテクチャは、環境を細分化することで開発がスピーディに、かつ低コストで行えます。拡張性やセキュリティ面にも優れています。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662898/Blog/Hero%20Images/microservices-explosion.jpg","https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"マイクロサービスアーキテクチャの基本とそのメリット\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-09-29\",\n      }",{"title":915,"description":916,"authors":921,"heroImage":917,"date":923,"body":924,"category":14,"tags":925,"updatedDate":927},[922],"GitLab","2022-09-29","マイクロサービスアーキテクチャを利用すると、アプリケーション開発がスピーディかつ低コストで行えます。また、複雑な開発や規模の大きな開発にも適しているため、マイクロサービスアーキテクチャを導入する企業が世界中で増加しています。\n\n本記事では、マイクロサービスアーキテクチャとは何か、マイクロサービスアーキテクチャを利用するメリットやデメリットについて解説します。\n\n## マイクロサービスアーキテクチャとは？\n\nマイクロサービスアーキテクチャ（Microservices Architecture）とは、開発環境やデータベースを細分化したアプリケーション開発手法です。それぞれのメンバーが、異なる環境やプログラミング言語で開発し、最終的にそれぞれの開発内容を統合して1つのアプリケーションやシステムを作りあげます。単にマイクロサービスと呼ばれることもあります。\n\n以前は、1つの環境でシステム開発を進める「モノリシック」という方法が主流でした。モノリシック（monolithic）は「一枚岩のような」という意味を持ち、開発者全員が単一の開発環境やデータベースを利用していました。これにより、優れたシステムやアプリケーションが多数誕生したのも事実です。\n\nしかしながら昨今、モノリシックは様々な壁に直面しています。例えば、モノリシックでは1つのエラーでシステム全体が影響を受けてしまい、修正に多くのコスト（時間や人件費）が必要になることがあります。また、変化の激しいVUCA時代に突入し、顧客からの要求が日々変化するようになり、モノリシック型の開発環境では対応に時間がかかりすぎるという課題も指摘されるようになりました。\n\nそこで注目を集めたのがマイクロサービスアーキテクチャです。マイクロサービスアーキテクチャは、複数人が同時並行で開発を進められます。また、問題が生じた際には関連する箇所を修正するだけで解決可能です。\n\n![Microservices vs monolith ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687528/Blog/Content%20Images/monolith-vs-microservices.png)\n\n*図：モノリスとマイクロサービスの比較*\n\n## 世界はモノリシックからマイクロサービスへ\n\n日本ではまだマイクロサービスを利用している企業は限定的ですが、世界ではモノリシックサービスからマイクロサービスへと変わりつつあります。例えば、日本でも人気の動画ストリーミングサービス「Netflix」は、モノリシックからマイクロサービスへ移行することで成功を収めた企業として有名です。膨大な情報をマイクロサービスで細分化して管理することで、1日に何千回も発生するデプロイや顧客からの要望に迅速に対応しています。\n\n[Fortune Business Insightsの調査](https://www.fortunebusinessinsights.com/jp/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E5%B8%82%E5%A0%B4-107793)によれば、世界のマイクロサービスクラウドの評価額は2022年に12億9千万ドル、そして2030年までに60億4千万ドルまで成長すると見込まれています。\n\n## マイクロサービスアーキテクチャのメリット\n\nマイクロサービスアーキテクチャを利用するメリットを以下にまとめました。それぞれについて詳しく説明します。\n\n- サービスをスピーディに提供できる\n- 拡張性が高い\n- 大規模なエラーが抑制できる\n- プログラミング言語の自由度が高い\n- 市場の要求に応じて柔軟に対応できる\n- 新規機能へのアップグレードが容易\n- コスト削減につながる\n- セキュリティ対策がしやすい\n- アウトソーシングを活用しやすくなる\n- 優秀な人材を確保しやすくなる \n\n### サービスをスピーディに提供できる\n\nモノリシックアーキテクチャーでは、1つの開発環境を共有し順番に開発を進めていく必要があります。自身に割り当てられた作業も、その他の作業が終わっていないという理由で、取りかかれないことがありました。\n\n一方マイクロサービスでは、各サービスが独立しているため、好きなタイミングで作業に取り組むことが可能です。また、複数人が同時に作業できるため、アプリケーションやシステムをスピーディに提供したい事業者に適しています。\n\n### 拡張性が高い\n\n各マイクロサービスが独立しているため、サービスの追加や削除、更新、拡張などが容易に実施できます。アップデートや市場に合わせた修正を頻繁に行いたい企業にとって大きなメリットといえます。\n\n### 大規模なエラーが抑制できる\n\nモノリシックアーキテクチャーでは、1つのエラーが原因でシステム全体が崩壊する可能性があります。一方マイクロサービスでは、各サービスが独立しているため、他のサービスに影響を与えることがまずありません。これにより、1つのエラーがシステム全体に影響を及ぼすことを抑制できます。\n\n### プログラミング言語の自由度が高い\n\nモノリシックアーキテクチャーの場合、単一の環境によって開発を行うため、場合によっては不慣れなスキルセットやテクノロジーでの対応が必要になります。その結果、開発に時間がかかるとともに、クオリティにも影響を及ぼします。\n\n一方マイクロサービスでは、各サービスでプログラミング言語やテクノロジーを選べます。開発者が得意なスキルセットを選べるため、高いクオリティのアプリケーションをスピーディに開発できるとともに、不慣れなプログラミング言語でエラーを出してしまうような事故も防ぐことができます。\n\n### 市場の要求に柔軟に対応できる\n\nシステムやアプリケーションを開発している最中に、市場の状況が変わり、急な変更を迫られることもあるでしょう。モノリシックの場合には、修正箇所がシステム全体に影響し、開発が大きく停滞してしまうことがありますが、マイクロサービスの場合、関連する箇所のみの修正で、その他のマイクロサービスには影響を与えないため、手戻りを最小限に食い止めることができます。\n\n### 新規機能へのアップグレードが容易\n\nモノリシックな環境では、一度構築したシステムやアプリケーションをアップグレードするのに多くのコストを費やす必要があるため、企画や実行に多大な労力が必要になります。一方マイクロサービスでは、必要な箇所のみのアップグレードで完了するため、開発の負担が圧倒的に小さくなります。\n\n### コスト削減につながる\n\nマイクロサービスでは、改修での開発工数やテスト工数を削減できるため、コスト削減につながります。サービスのアップデートやエラー修正にかかる時間も削減できるため、保守・運用にかかるコストを大幅に削減できるのも魅力です。\n\n### セキュリティ対策がしやすい\n\nモノリシックな環境下で何らかのセキュリティ問題が発生した場合、開発環境上にあるすべての情報が漏洩する可能性があります。一方マイクロサービスの場合には、各サービスごとに情報が分断されているため、重要な情報がまとまったかたちで漏洩するのを防げます。機密情報を扱う箇所に強固なセキュリティ対策を施しておけば、大規模な情報漏洩のリスクを削減できます。サービス間の連携では適切な[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)を使用すれば、より安心して利用できるでしょう。\n\n### アウトソーシングを活用しやすくなる\n\n昨今、開発業務の一部をアウトソースする企業が増えています。モノリシックな環境では、組織の知的財産の共有が懸念点としてありましたが、マイクロサービスであれば、必要なサービスの環境のみを共有できるため、情報漏洩の不安を抱えずに協力体制を構築できます。\n\n### 優秀な人材を確保しやすくなる\n\nマイクロサービスアーキテクチャは、開発者にとっても魅力的なプラットフォームです。プログラミング言語の自由度が高いことで、自身の得意なプログラミング言語やテクノロジーを最大限に活用して貢献できるためです。日本ではまだマイクロサービスを導入している企業が少ないのが現状ですが、今後マイクロサービス環境に興味を持ち、アプローチしてくる開発者が増えるでしょう。\n\n## マイクロサービスアーキテクチャのデメリット \n\n一方で、マイクロサービスアーキテクチャには以下のようなデメリットもあります。\n- 初期費用（導入コスト）が高くなる\n- 熟練者が求められる\n- インターフェイス制御が難しい\n- エラーの特定や結合テストが複雑になる\n\n### 初期費用（導入コスト）が高くなる\n\nマイクロサービスは長期的に見た場合にはコストカットに効果的ですが、セキュリティやメンテナンスサポートを備えたホスティングインフラストラクチャが必要になるため、初期費用はモノリシックと比べて高くなる傾向にあります。\n\n### 熟練者が求められる\n\nマイクロサービスは様々なパーツ開発を同時並行でマネジメントしたり、出来上がったサービスを適切に組み合わせたりするスキルが必要です。そのため、マイクロサービスの活用に精通した熟練者が1名以上必要です。\n\n### インターフェイス制御が難しい\n\nマイクロサービスの接点、つまりインターフェイスの制御が複雑になり、ときにマイクロサービスを利用する企業の悩みの種になります。各サービスには独自の[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)があるため、大規模なアプリケーションを開発する際には大量の[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api)を同時に管理する必要があります。\n\n### エラーの特定や結合テストが複雑になる\n\nマイクロサービスでは、複数の開発が同時に行われるのに加え、サービスごとに異なる環境やコーディング規約で開発が行われているため、エラーの特定や修正に時間がかかる場合があります。\n\nまた、複数のサービス間で実施する結合テストは、各サービスのインターフェース設定を事前に行う必要があるため、より複雑で、時間がかかる傾向にあります。\n\n## サービス指向アーキテクチャ（Service-oriented architecture）とマイクロサービスの違い\n\nクラウドコンピューティングに携わっている方なら、サービス指向アーキテクチャ（SOA）とマイクロサービスの議論を耳にしたことがあるかもしれません。どちらも作業しやすいように小さなユニットに分割すること、またアジャイル開発のためのクラウドコンピューティングを必要とすることなど、類似点もたくさんあります。\n\nしかし、SOAは「できる限り共通性を持たせた上で細分化」するのに対し、マイクロサービスは「共通性よりも独立性を尊重している」という大きな違いがあります。例えばSOAでは、チーム内でできる限りリソースやコードを統一しようと努めます。一方でマイクロサービスは、それぞれの担当者が自分の得意なスキルセットを用いて開発することに重点を置きます。\n\n大規模なシステム開発会社が社内のリソースで大規模開発を行う際などにはSOAが優先されます。一方で、アウトソーシングや他社との連携を利用するなど、多様なヒストリーを持つ開発者が共同で開発を行う場合にはマイクロサービスが好まれます。\n\n考え方は非常によく似ていますが、開発に関する手法やコンセプトの点で違いがあるため、実施前にどちらが最適か、よく検討するとよいでしょう。\n\n## GitLabでマイクロサービスを利用する\n\nマイクロサービスアーキテクチャは、各サービスを必要に応じて組み合わせる開発手法により、開発会社が抱える様々な悩みを解決します。[GitLabは、マイクロサービスアーキテクチャにも対応](https://about.gitlab.com/ja-jp/topics/cloud-native/)していますので、マイクロサービス開発で使えるプラットフォームをお探しの方はぜひ検討してみてください。 \n\n*監修：伊藤 俊廷 [@toshitakaito](https://gitlab.com/toshitakaito) （GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト）*",[926,926,882],"DevOps","2024-12-12",{"slug":929,"featured":93,"template":676},"what-are-the-benefits-of-a-microservices-architecture","content:ja-jp:blog:what-are-the-benefits-of-a-microservices-architecture.yml","What Are The Benefits Of A Microservices Architecture","ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture.yml","ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture",2,[683,707,728,748,770,789,808,827,846],1753733120029]