[{"data":1,"prerenderedAt":876},["ShallowReactive",2],{"/en-us/blog/tags/devops":3,"navigation-ja-jp":20,"banner-ja-jp":436,"footer-ja-jp":449,"footer-source-/en-us/blog/tags/devops/":659,"DevOps-tag-page-ja-jp":662},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/devops","tags",false,"",{"tag":9,"tagSlug":10},"DevOps","devops",{"template":12},"BlogTag","content:en-us:blog:tags:devops.yml","yaml","Devops","content","en-us/blog/tags/devops.yml","en-us/blog/tags/devops","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":432,"_type":14,"title":433,"_source":16,"_file":434,"_stem":435,"_extension":19},"/shared/ja-jp/main-navigation","ja-jp",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":376,"minimal":410,"duo":423},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/ja-jp/","gitlab logo","header",{"text":30,"config":31},"無料トライアルを開始",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"お問い合わせ",{"href":37,"dataGaName":38,"dataGaLocation":28},"/ja-jp/sales/","sales",{"text":40,"config":41},"サインイン",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,187,192,298,358],{"text":46,"config":47,"cards":49,"footer":72},"プラットフォーム",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":53,"config":54},"プラットフォームを詳しく見る",{"href":55,"dataGaName":48,"dataGaLocation":28},"/ja-jp/platform/",{"title":57,"description":58,"link":59},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":60,"config":61},"GitLab Duoのご紹介",{"href":62,"dataGaName":63,"dataGaLocation":28},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":68,"config":69},"詳細はこちら",{"href":70,"dataGaName":71,"dataGaLocation":28},"/ja-jp/why-gitlab/","why gitlab",{"title":73,"items":74},"利用を開始：",[75,80,85],{"text":76,"config":77},"プラットフォームエンジニアリング",{"href":78,"dataGaName":79,"dataGaLocation":28},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"開発者の経験",{"href":83,"dataGaName":84,"dataGaLocation":28},"/ja-jp/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":169},"製品",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":28},"/ja-jp/solutions/",[99,125,147],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/ja-jp/solutions/continuous-integration/",{"text":113,"config":114},"AIアシストによる開発",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"ソースコード管理",{"href":119,"dataGaLocation":28,"dataGaName":120},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Application Security Testing",{"href":130,"dataGaName":137,"dataGaLocation":28},"Application security testing",{"text":139,"config":140},"ソフトウェアサプライチェーンの安全性",{"href":141,"dataGaLocation":28,"dataGaName":142},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":28},"/ja-jp/solutions/software-compliance/",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":28},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":28,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":28,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":28,"dataGaName":168},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLabが活躍する場所",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":28,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":28,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共機関",{"href":185,"dataGaLocation":28,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":28,"dataNavLevelOne":191},"/ja-jp/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":285},"関連リソース",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"すべてのリソースを表示",{"href":199,"dataGaName":195,"dataGaLocation":28},"/ja-jp/resources/",[201,234,257],{"title":202,"items":203},"はじめに",[204,209,214,219,224,229],{"text":205,"config":206},"インストール",{"href":207,"dataGaName":208,"dataGaLocation":28},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":28},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":28,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":28},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":28},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247,252],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":28},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":28},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/ja-jp/teamops/","teamops",{"title":258,"items":259},"つなげる",[260,265,270,275,280],{"text":261,"config":262},"GitLabサービス",{"href":263,"dataGaName":264,"dataGaLocation":28},"/ja-jp/services/","services",{"text":266,"config":267},"コミュニティ",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"フォーラム",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"イベント",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"パートナー",{"href":283,"dataGaName":284,"dataGaLocation":28},"/ja-jp/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":290,"config":291},"ソースプロモカード",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"最新情報を読む",{"href":296,"dataGaName":297,"dataGaLocation":28},"/ja-jp/the-source/","the source",{"text":299,"config":300,"lists":302},"会社情報",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"GitLabについて",{"href":308,"dataGaName":309,"dataGaLocation":28},"/ja-jp/company/","about",{"text":311,"config":312,"footerGa":315},"採用情報",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"経営陣",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"チーム",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"ハンドブック",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"投資家向け情報",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"トラストセンター",{"href":341,"dataGaName":342,"dataGaLocation":28},"/ja-jp/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":28},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"ニュースレター",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"プレス",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":35,"config":359,"lists":360},{"dataNavLevelOne":301},[361],{"items":362},[363,366,371],{"text":35,"config":364},{"href":37,"dataGaName":365,"dataGaLocation":28},"talk to sales",{"text":367,"config":368},"サポートを受ける",{"href":369,"dataGaName":370,"dataGaLocation":28},"/support/","get help",{"text":372,"config":373},"カスタマーポータル",{"href":374,"dataGaName":375,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":377,"login":378,"suggestions":385},"閉じる",{"text":379,"link":380},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":381,"config":382},"GitLab.com",{"href":42,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"提案",[388,391,396,398,402,406],{"text":57,"config":389},{"href":62,"dataGaName":390,"dataGaLocation":384},"GitLab Duo (AI)",{"text":392,"config":393},"コード提案（AI）",{"href":394,"dataGaName":395,"dataGaLocation":384},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":397},{"href":111,"dataGaName":109,"dataGaLocation":384},{"text":399,"config":400},"GitLab on AWS",{"href":401,"dataGaName":399,"dataGaLocation":384},"/ja-jp/partners/technology-partners/aws/",{"text":403,"config":404},"GitLab on Google Cloud",{"href":405,"dataGaName":403,"dataGaLocation":384},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":407,"config":408},"GitLabを選ぶ理由",{"href":70,"dataGaName":409,"dataGaLocation":384},"Why GitLab?",{"freeTrial":411,"mobileIcon":415,"desktopIcon":420},{"text":30,"config":412},{"href":413,"dataGaName":33,"dataGaLocation":414},"https://gitlab.com/-/trials/new/","nav",{"altText":416,"config":417},"GitLabアイコン",{"src":418,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":416,"config":421},{"src":422,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"GitLab Duoの詳細について",{"href":62,"dataGaName":427,"dataGaLocation":414},"gitlab duo",{"altText":416,"config":429},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":431},{"src":422,"dataGaName":419,"dataGaLocation":414},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":437,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":438,"button":439,"config":444,"_id":446,"_type":14,"_source":16,"_file":447,"_stem":448,"_extension":19},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":440,"config":441},"ベータ版を試す",{"href":442,"dataGaName":443,"dataGaLocation":28},"/ja-jp/gitlab-duo/agent-platform/","duo banner",{"layout":445},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":450,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":451,"_id":655,"_type":14,"title":656,"_source":16,"_file":657,"_stem":658,"_extension":19},"/shared/ja-jp/main-footer",{"text":452,"source":453,"edit":459,"contribute":464,"config":469,"items":474,"minimal":647},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":454,"config":455},"ページのソースを表示",{"href":456,"dataGaName":457,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":460,"config":461},"このページを編集",{"href":462,"dataGaName":463,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":465,"config":466},"ご協力をお願いします",{"href":467,"dataGaName":468,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":470,"facebook":471,"youtube":472,"linkedin":473},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[475,498,552,584,619],{"title":46,"links":476,"subMenu":481},[477],{"text":478,"config":479},"DevSecOpsプラットフォーム",{"href":55,"dataGaName":480,"dataGaLocation":458},"devsecops platform",[482],{"title":188,"links":483},[484,488,493],{"text":485,"config":486},"プランの表示",{"href":190,"dataGaName":487,"dataGaLocation":458},"view plans",{"text":489,"config":490},"Premiumを選ぶ理由",{"href":491,"dataGaName":492,"dataGaLocation":458},"/ja-jp/pricing/premium/","why premium",{"text":494,"config":495},"Ultimateを選ぶ理由",{"href":496,"dataGaName":497,"dataGaLocation":458},"/ja-jp/pricing/ultimate/","why ultimate",{"title":499,"links":500},"ソリューション",[501,506,509,511,516,521,525,528,531,536,538,540,542,547],{"text":502,"config":503},"デジタルトランスフォーメーション",{"href":504,"dataGaName":505,"dataGaLocation":458},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":507,"config":508},"セキュリティとコンプライアンス",{"href":130,"dataGaName":137,"dataGaLocation":458},{"text":122,"config":510},{"href":105,"dataGaName":106,"dataGaLocation":458},{"text":512,"config":513},"アジャイル開発",{"href":514,"dataGaName":515,"dataGaLocation":458},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":517,"config":518},"クラウドトランスフォーメーション",{"href":519,"dataGaName":520,"dataGaLocation":458},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":522,"config":523},"SCM",{"href":119,"dataGaName":524,"dataGaLocation":458},"source code management",{"text":109,"config":526},{"href":111,"dataGaName":527,"dataGaLocation":458},"continuous integration & delivery",{"text":160,"config":529},{"href":162,"dataGaName":530,"dataGaLocation":458},"value stream management",{"text":532,"config":533},"GitOps",{"href":534,"dataGaName":535,"dataGaLocation":458},"/ja-jp/solutions/gitops/","gitops",{"text":173,"config":537},{"href":175,"dataGaName":176,"dataGaLocation":458},{"text":178,"config":539},{"href":180,"dataGaName":181,"dataGaLocation":458},{"text":183,"config":541},{"href":185,"dataGaName":186,"dataGaLocation":458},{"text":543,"config":544},"教育",{"href":545,"dataGaName":546,"dataGaLocation":458},"/ja-jp/solutions/education/","education",{"text":548,"config":549},"金融サービス",{"href":550,"dataGaName":551,"dataGaLocation":458},"/ja-jp/solutions/finance/","financial services",{"title":193,"links":553},[554,556,558,560,563,565,568,570,572,574,576,578,580,582],{"text":205,"config":555},{"href":207,"dataGaName":208,"dataGaLocation":458},{"text":210,"config":557},{"href":212,"dataGaName":213,"dataGaLocation":458},{"text":215,"config":559},{"href":217,"dataGaName":218,"dataGaLocation":458},{"text":220,"config":561},{"href":222,"dataGaName":562,"dataGaLocation":458},"docs",{"text":243,"config":564},{"href":245,"dataGaName":246},{"text":566,"config":567},"お客様の成功事例",{"href":240,"dataGaLocation":458},{"text":238,"config":569},{"href":240,"dataGaName":241,"dataGaLocation":458},{"text":248,"config":571},{"href":250,"dataGaName":251,"dataGaLocation":458},{"text":261,"config":573},{"href":263,"dataGaName":264,"dataGaLocation":458},{"text":253,"config":575},{"href":255,"dataGaName":256,"dataGaLocation":458},{"text":266,"config":577},{"href":268,"dataGaName":269,"dataGaLocation":458},{"text":271,"config":579},{"href":273,"dataGaName":274,"dataGaLocation":458},{"text":276,"config":581},{"href":278,"dataGaName":279,"dataGaLocation":458},{"text":281,"config":583},{"href":283,"dataGaName":284,"dataGaLocation":458},{"title":585,"links":586},"Company",[587,589,591,593,595,597,599,603,608,610,612,614],{"text":306,"config":588},{"href":308,"dataGaName":301,"dataGaLocation":458},{"text":311,"config":590},{"href":313,"dataGaName":314,"dataGaLocation":458},{"text":319,"config":592},{"href":321,"dataGaName":322,"dataGaLocation":458},{"text":324,"config":594},{"href":326,"dataGaName":327,"dataGaLocation":458},{"text":329,"config":596},{"href":331,"dataGaName":332,"dataGaLocation":458},{"text":334,"config":598},{"href":336,"dataGaName":337,"dataGaLocation":458},{"text":600,"config":601},"Sustainability",{"href":602,"dataGaName":600,"dataGaLocation":458},"/sustainability/",{"text":604,"config":605},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":606,"dataGaName":607,"dataGaLocation":458},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":609},{"href":341,"dataGaName":342,"dataGaLocation":458},{"text":349,"config":611},{"href":351,"dataGaName":352,"dataGaLocation":458},{"text":354,"config":613},{"href":356,"dataGaName":357,"dataGaLocation":458},{"text":615,"config":616},"現代奴隷制の透明性に関する声明",{"href":617,"dataGaName":618,"dataGaLocation":458},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":620},[621,623,625,627,632,637,642],{"text":35,"config":622},{"href":37,"dataGaName":38,"dataGaLocation":458},{"text":367,"config":624},{"href":369,"dataGaName":370,"dataGaLocation":458},{"text":372,"config":626},{"href":374,"dataGaName":375,"dataGaLocation":458},{"text":628,"config":629},"ステータス",{"href":630,"dataGaName":631,"dataGaLocation":458},"https://status.gitlab.com/","status",{"text":633,"config":634},"利用規約",{"href":635,"dataGaName":636,"dataGaLocation":458},"/terms/","terms of use",{"text":638,"config":639},"プライバシーに関する声明",{"href":640,"dataGaName":641,"dataGaLocation":458},"/ja-jp/privacy/","privacy statement",{"text":643,"config":644},"Cookieの設定",{"dataGaName":645,"dataGaLocation":458,"id":646,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":648},[649,651,653],{"text":633,"config":650},{"href":635,"dataGaName":636,"dataGaLocation":458},{"text":638,"config":652},{"href":640,"dataGaName":641,"dataGaLocation":458},{"text":643,"config":654},{"dataGaName":645,"dataGaLocation":458,"id":646,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":660,"config":661,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},{"tag":9,"tagSlug":10},{"template":12},[663,691,715,740,766,789,814,837,857],{"_path":664,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":665,"content":673,"config":684,"_id":687,"_type":14,"title":688,"_source":16,"_file":689,"_stem":690,"_extension":19},"/ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"title":666,"description":667,"ogTitle":666,"ogDescription":667,"noIndex":6,"ogImage":668,"ogUrl":669,"ogSiteName":670,"ogType":671,"canonicalUrls":669,"schema":672},"『2024 Gartner ® Magic Quadrant™』のDevOpsプラットフォーム部門でGitLabがリーダーの1社に位置付け","GitLabは、Ability to execute（実行能力）とCompleteness of vision（ビジョンの完全性）の両分野で最高評価を獲得しました。これは、当社のお客様の成功とDevOpsカテゴリでの継続的なイノベーションが評価された結果と考えられます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"『2024 Gartner ® Magic Quadrant™』のDevOpsプラットフォーム部門でGitLabがリーダーの1社に位置付け\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2024-09-05\",\n      }",{"title":666,"description":667,"authors":674,"heroImage":668,"date":676,"body":677,"category":678,"tags":679,"updatedDate":683},[675],"Ashley Kramer","2024-09-05","DevOpsはもともと、従来は別々に動いていたチームを1つにまとめ、ソフトウェアをより迅速に提供するための単なる概念であり、開発手法に過ぎませんでした。言い換えると、ソフトウェアを開発する人々とデプロイする人々が分断されていることで生じるあらゆる問題への対応策でした。\n\nGitLabでは、その概念をさらに発展させ、ツールをつなぎ合わせた複雑なDevOpsツールチェーンではなく、[単一のDevOpsプラットフォーム](https://about.gitlab.com/ja-jp/platform/)を開発することで、より緊密なコラボレーション、より高度な自動化、そして、よりスケーラブルで標準化されたプロセスを実現しました。\n\n当社は、お客様の成功に焦点を当てるというこの戦略が正しかったと信じています。[今回で第2回目となる](https://about.gitlab.com/gartner-magic-quadrant/)『Gartner ® Magic Quadrant™』のDevOpsプラットフォーム部門で、GitLabは再びリーダーの評価を受けました。今回はAbility to execute（実行能力 ）とCompleteness of Vision（ビジョンの完全性）の両分野で最高評価を獲得しています。\n\n![『2024 Gartner Magic Quadrant for DevOps Platforms』の画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674334/Blog/Content%20Images/figure1.png)\n\n> [『2024 Gartner ® Magic Quadrant™』のDevOpsプラットフォーム部門に関するレポート](https://about.gitlab.com/ja-jp/gartner-magic-quadrant/)をダウンロードしましょう。\n\n昨今において、ソフトウェア企業は、増大するセキュリティの脅威や複雑なコンプライアンス要件に対応すると同時に、生成AIのような新技術を慎重に導入するといった課題に直面しています。これに加えて、スケーラブルなサービスを提供し続け、顧客に対して継続的なイノベーションを約束するという使命も果たさなければなりません。\n\nGitLabは、お客様がこれらの課題に対処し、業界のリーダーとしての地位を確立できるようサポートします。当社のAI搭載のDevSecOpsプラットフォームを使用すると、お客様はセキュリティのシフトレフトを実行し、開発ライフサイクル全体での可視性を確保し、世界に影響を与えるソフトウェアの提供に必要なすべての役割と責任を1つにまとめられます。\n\n## DevOpsビジョンの促進\n\nGitLabは進化を続けます。DevOpsのビジョンをさらに革新し、DevSecOpsプラットフォームを2つの方法で進化させます。\n\n1つ目は、[アジャイル計画](https://about.gitlab.com/blog/categories/agile-planning/)、[データサイエンス](https://about.gitlab.com/ja-jp/topics/devops/the-role-of-ai-in-devops/)、[可観測性やアプリケーションのモニタリング](https://docs.gitlab.com/operations/observability/)に関わるチームに特化した機能を提供することで、より多くのチームが同じプラットフォームでコラボレーションできるようにするというものです。\n\nそして2つ目が、お客様の多様なニーズに対応するために、プラットフォームの導入やデプロイにおいて、より柔軟な選択肢を用意するというものです。その選択肢のひとつが、シングルテナントのホスティングオプションである[GitLab Dedicated](https://about.gitlab.com/ja-jp/dedicated/)への投資です。これにより、厳格な規制が定められる業界の企業が、分離されたインフラストラクチャのコンプライアンス要件を満たしつつ、SaaSのシンプルさとすべての最新機能の利点を享受できるようになります。\n\n## 組織が安全なソフトウェアを構築できるよう支援\n\nGitLabでは、より優れたソフトウェアデリバリー向けコラボレーションプラットフォームの構築に加えて、組織がより安全でコンプライアンスに準拠したソフトウェアを構築できるよう支援することを最重要事項のひとつとしています。このビジョンに基づき、GitLabは、他社とは異なり、アプリケーションのリリース直前ではなく、コードコミットの段階に[セキュリティスキャン](https://about.gitlab.com/ja-jp/solutions/application-security-testing/)を組み込んでいます。これにより、チームは脆弱性を早期に発見し、リリースサイクルを迅速化できます。さらに、GitLabはポリシーのガードレール設定機能や、[ソフトウェア部品表](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)の自動生成機能により、コンプライアンス対応を容易にします。\n\n当社では、ソフトウェアのアタックサーフェス（攻撃対象領域）が拡大するにつれて、お客様がより多くのセキュリティ脅威に直面していることを認識しています。こうした現状を受けて、GitLabは今後12か月間にわたり、SASTスキャナーの改善、追加のポリシー管理機能の導入、そして新たな[ネイティブシークレットマネージャー](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/)の開発を計画しています。\n\n## ソフトウェア開発ライフサイクル全体（SDLC）でのAI活用で業界をリード\n\n当社は、AIの分野でリーダーになるというビジョンも掲げています。これには、お客様がAIを活用して革新的なソフトウェアを開発できるよう支援するだけでなく、プライバシーを最優先に考えたAI技術を提供することも含まれています。AIは、SDLCのすべての段階に組み込むことで、非常に大きな可能性や改善の機会をもたらします。当社は、イノベーションの創出に責任を持って取り組んでいます。お客様は、[ガードレールが確保され](https://about.gitlab.com/the-source/ai/velocity-with-guardrails-ai-automation/)、[透明性があり](https://about.gitlab.com/ja-jp/ai-transparency-center/)、コードや知的財産を尊重するAIを望んでおり、GitLabはそうした声を真摯に受け止めています。\n\nそこでGitLabは、包括的でプライバシーを第一とし、ソフトウェア開発ライフサイクル全体をサポートする、AI搭載の機能群[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を、当社のDevSecOpsプラットフォーム向けに構築することに全力を注いでいます。\n\nこの取り組みとGitLab Duo機能に対する高い評価こそが、この度、[第1回となるGartner® Magic Quadrant™でAIコードアシスタントの分野におけるリーダーの1社に選ばれた理由](https://about.gitlab.com/ja-jp/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants/)であると、当社は考えています。\n\nこの光栄な評価を糧に、今後もお客様の声に耳を傾けて取り組んでまいります。お客様の声こそが、GitLabのビジョン、製品ロードマップ、そして最高のDevSecOpsプラットフォームを提供するための取り組みを支える原動力です。\n\n> [『2024 Gartner® Magic Quadrant™ 』のDevOpsプラットフォーム部門に関するレポート](https://about.gitlab.com/ja-jp/gartner-magic-quadrant/)をダウンロードしましょう。\n\n***出典：2024年8月、Gartner、Magic Quadrant for DevOps Platforms、Keith Mann、Thomas Murphy、Bill Holz、George Spafford***\n\n***GARTNERは、米国および国際的なGartner, Inc.および／またはその関連会社の登録商標およびサービスマークであり、MAGIC QUADRANTはGartner, Inc.および／またはその関連会社の登録商標であり、許可を得てここで使用されています。無断転載は禁止されています。***\n\n***Gartnerは、調査出版物で言及されているベンダー、製品、またはサービスを推奨するものではありません。また、最高評価またはその他の認定を受けたベンダーのみを選択するようユーザーに助言するものでもありません。Gartnerの調査出版物は、同社の研究機関の意見で構成されており、事実を表明するものとして解釈されるべきではありません。Gartnerは、本調査に関して、商品の品質・性能または特定の目的への適合性に関する保証を含め、その明示性または黙示性を問わず、いかなる保証も行いません。***\n\n***このグラフィックは、Gartner Incがより大規模なレポートの一部として発表したものであり、文書全体の文脈の中で評価される必要があります。Gartnerの文書を参照するには、同社への開示リクエストが必要になります。***","news",[678,680,681,9,682],"research","DevSecOps platform","DevSecOps","2024-10-24",{"slug":685,"featured":91,"template":686},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","BlogPost","content:ja-jp:blog:gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","Gitlab Named A Leader In The 2024 Gartner Magic Quadrant For Devops","ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"_path":692,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":693,"content":699,"config":709,"_id":711,"_type":14,"title":712,"_source":16,"_file":713,"_stem":714,"_extension":19},"/ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices",{"title":694,"description":695,"ogTitle":694,"ogDescription":695,"noIndex":6,"ogImage":696,"ogUrl":697,"ogSiteName":670,"ogType":671,"canonicalUrls":697,"schema":698}," CI/CDとは？ベストプラクティスやメリットも解説","CI/CDは高品質のアプリをスピーディに開発するのに最適です。注目度が高まるCI/CDとは何か、メリットやベストプラクティスについても説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661856/Blog/Hero%20Images/ci-cd-demo.jpg","https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \" CI/CDとは？ベストプラクティスやメリットも解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-02-03\",\n      }",{"title":694,"description":695,"authors":700,"heroImage":696,"date":702,"body":703,"category":704,"tags":705,"updatedDate":708},[701],"Valerie Silverthorne","2022-02-03","## 目次\n* CI/CDとは\n* CI/CDのメリット\n* CI/CDのベストプラクティス\n* CI/CDの成果を検討する方法\n* CI/CDパイプラインとは？\n* CI/CDツールの選び方\n* 多くの企業がGitLabのCI/CDを選ぶ理由とは？\n* 結論\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、高品質のアプリケーション・システム開発をよりスピーディに行うだけでなく、エラー削減やコストカットにも効果的です。しかしながら日本ではまだまだ知名度が低く、利用している企業は一握りというのが現状です。\n\n本記事では、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)とは何かについてわかりやすく解説するとともに、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットやベストプラクティスについて紹介します。\n\n## CI/CDとは\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、[継続的インテグレーション（Continuous Integration）](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)と継続的デリバリー（Continuous Delivery）の略称です。それぞれについて詳しく説明します。\n\n### CI（継続的インテグレーション）\n\n[CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)とは、開発者がコードを修正しそれをリポジトリにプッシュした際に、自動的にビルドやテストを実行するプロセスや仕組みのことです。[CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)によって継続的にテストを行うことで、コードの品質を高く保つことができます。\n\n### CD（継続的デリバリー）\n\nCDは、[CI](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)による統合や一体化をさらに拡張したもので、より高度にかつ自動的にシステムに変更が反映されるように設計された環境や概念を指します。\n\n### CI/CDの考え方\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、分割されているツールやプラットフォームを統合し、1つの変更が自動的に他ツールに反映されるように環境を組むことであり、アプリケーション開発の効率化を図ることです。ツールやプラットフォームを指すこともあれば、手法や概念として用いられることもあります。\n\n近年は著しい変化を伴う環境の中での開発が求められており、開発中に急に変更が生じることも多々あります。従来のウォーターフォール型の開発手法では急な変化に対応できず、常に変更とテストを繰り返しながら開発を進めていく[アジャイル開発](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)が主流となっています。\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、ビルド、テスト、デプロイ、インフラストラクチャのプロビジョニングなどを一体化し、これまで手動で実施していた介入のほとんどを自動化します。アジャイル開発や近年注目が集まる[DevOps](https://about.gitlab.com/ja-jp/platform/)とマッチしており、開発環境の改善を図りたい企業に積極的に採用されています。\n\n今後、よりスピーディで高品質の開発を進めていきたいのであれば、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)環境や考え方を積極的に取り入れていく必要があるでしょう。\n\n## CI/CDのメリット\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットは以下の通りです。\n\n* 制作物の品質が高まる\n* 開発スピードが向上する\n* ツール間のズレを予防できる\n* デベロッパーが開発に集中できる\n\n### 制作物の品質が高まる\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を利用することで、ソフトウェアやアプリなどの品質が高まります。\n\n従来であれば、最新のバージョンを適用するのに数時間もしくは数日かかるため、アップデートやツール追加などが容易に行えない状況がありました。\n\n一方[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、最新のコードやテクノロジー適用が容易です。開発環境を常に最新に保つことができるため、最先端・高品質の制作物が期待できます。\n\n### 開発スピードが向上する\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)はツール間で連携されており、入力情報が他ツールに自動的に適用されるため、作業量が必然的に少なくなります。これにより、開発スピードが格段に高まるとともに、急な変化にも対応しやすくなります。\n\n### 環境の差異による問題を予防できる\n\n複数の開発環境を利用する場合、環境ごとの仕様が原因でエラーが生じたり、セキュリティに問題が発生したりすることがありました。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、各ツールが自動的に連携されているため、環境の際による問題が予防でき、それによるエラーやセキュリティ問題が減少します。エラーが少なくなれば人的コストを大幅にカットできるため、予算削減にもつながります。\n\n### デベロッパーが開発に集中できる\n\nデベロッパーの仕事は「開発」です。しかしながら、実際にはエラーやバグの修正に追われ、開発に専念しづらい状況が発生しています。\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ではエラーが発生しにくいため、これまでエラー対応にあてていた時間を開発に注げるようになります。デベロッパーのエンゲージメントが向上し、長期にわたって貢献してくれる土台が作られます。\n\n## CI/CDのベストプラクティス\n\n新しく[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を導入する場合には、これから紹介するベストプラクティスを実施することで、効果をより高められます。\n\n### コードの品質を管理する\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、ビルド、テスト、デプロイまで、同じコードを用いて開発を進めていきます。そのため、初期でコードの間違いがあった場合には、それが後半まで影響を与えます。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、通常の開発以上に、コードの適切な利用が重要です。\n\nデベロッパー間で認識の違いが生じないように、コートレポジトリを適切に作成・管理してください。また、定期的にコードレビューを行うとともに、コードの変更を行う際にはレポジトリの書き換えも必ず行うようにしてください。\n\n### 初期は微調整を頻繁に行う\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、一度組織にフィットすると、開発スピード向上やエラー削減に大きく貢献します。しかしながら、新規に導入した[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)をいきなり組織にフィットさせることは稀です。多くの企業が、実践とフィードバックを繰り返しながら、自社に最適化させていくプロセスを経験しています。\n\nそのため、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を取り入れる際には、デベロッパーからの声を丁寧に拾い上げる仕組みを作り上げることが重要です。何に困っているのか、どの部分がうまく機能していないのかを確認しながら、必要に応じて[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を微調整していくことで、自社に真にマッチしたCI/CDへと改良されていきます。\n\n### 適切なセキュリティ対策を行う\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、ビルド、テスト、デプロイが1つの環境で行える一方で、情報が外部に漏れた場合には、制作物すべてに影響を及ぼす可能性があります。そのため、セキュリティ対策はより強固に行う必要があります。\n\nログイン情報を不特定多数に共有しないようにするとともに、ログイン時の認証を強化する、ツールは最小限に抑える、問題発生時のリスクマネジメントを決めておくなど、セキュリティ対策には力を入れるようにしてください。\n\n### 設定ファイルを再利用する\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、設定ファイルに記述されたコードを繰り返し利用することで、開発時間の短縮とエラーやバグの削減を可能にしています。しかしながら、デベロッパーの人数が増えると情報共有が上手くいかず、設定ファイルの情報を用いずに開発を進めてしまう場合があるようです。これでは、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットを最大限に活かせません。\n\n組織として、設定ファイルをどのように活用すべきかを明確化するとともに、見やすい場所に設置しておく、定期的に情報共有するなど、対策を図るようにしてください。\n\n### 気づいたエラーを放置しない\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、コードを複数箇所に自動的に反映させることで、高速化とエラー減を実現しています。しかしながら、もし初期に利用したコードにエラーがあった場合、それがその他の箇所にも影響を及ぼします。エラーに気づいたら、すぐに修正を図るようにしてください。\n\n### デプロイごとに本番前環境をクリーンアップする\n\n環境の実行期間が長くなるほど、適用されたすべての構成変更と更新を追跡することが難しくなります。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、デプロイごとに本番前環境をクリーンアップすることで、以前のデータが悪さするのを防げます。不要なファイルやデータ、一時ファイル、ログなどを毎回削除するようにしてください。\n\n## CI/CDの成果を検討する方法\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を導入した場合には、以下の項目を用いて、成果を適切に検討するようにしてください。\n\n### サイクルタイム\n\nサイクルタイムは、1つの作業の工程開始から完了までにかかる時間です。コードの書き始めからアプリ完成までの時間を計測し、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入の前後で比較します。ただし、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)に変更して初回のアプリ開発は当然時間がかかるため、ある程度慣れてきたころのサイクルタイムを用いて比較するようにしてください。\n\n### 作業時間\n\nデベロッパーが何にどのぐらいの時間を費やしているのかを記録、分析します。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)がうまく機能し始めると、問題の処理やツール間の調整にかかる時間が減り、メインとなる開発にかけられる時間が増えます。もしその傾向があるのならば、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットをうまく享受できていると考えてよいでしょう。\n\n### エラー率\n\nアプリケーション開発においてエラー発生は避けられません。しかしながら、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入前後でエラー率がどの程度変わったのかを追跡することには大きな意味があります。もし[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入後にもエラーが大量に発生している、もしくはエラー修正にかかる作業時間が削減されていない場合、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)がうまく機能していない可能性があるため、見直しが必要です。\n\n### インフラコスト\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入にかかる費用を適切に把握するとともに、パフォーマンスとコストを見比べ、導入が適切であったかどうかを検討します。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は様々なメリットがある反面、当然のことながらインフラストラクチャ構築費用がかかります。開発スピードやエラー率、人件費などを見比べながら、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)導入がコスト面からみて妥当かどうかを検討してください。\n\n### チームの声\n\n実際に作業を行うデベロッパーの声も大切な評価基準です。ツールが使いやすいか、実際にエラーが少なくなったと感じるか、デベロッパー同士の連携に問題ないかなどを質問することで、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)が開発者目線から見てどうかを把握できます。\n\n## CI/CDパイプラインとは？\n\nパイプラインは特定のものをつなぐパイプです。例えば、AとBという別のものがある場合、パイプラインがない場合にはそれぞれが独立して機能します。一方、AとBがパイプで結ばれている場合、AとBがそれぞれ干渉しあい、影響し合うことで様々なメリット・デメリットを生み出します。\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)では、様々なステージや環境、ツールなどをパイプラインで結ぶことで自動化を図り、作業の効率化やエラーの削減、アップデートの容易化などを図ります。例えば、通常であればそれぞれ独立している「ビルド」「テスト」「デプロイ」の各ステージをパイプラインで結び付けることで、特定の変更が他のステージにおいても自動的に反映されます。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインは、CI/CDが効果を発揮する上での核となる考え方や構造です。\n\nこのパイプラインが正しく機能しているプラットフォームやツールを利用することで、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)のメリットを最大限に享受できます。\n\n一方で、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインがうまく機能しない場合、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)の恩恵を受けられないばかりか、エラーが増えたり、余計に時間がかかったりする場合があります。そのため、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールの選定は慎重に行う必要があります。\n\n## CI/CDツールの選び方\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)を導入する目的は、開発サイクル全体にわたって包括的なフィードバックを提供しながら、正確で信頼性の高い製品を迅速に生成することです。そのため、正確性、信頼性、速度の面で優れた[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールを探す必要があります。\n\nまた、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールの導入は、デベロッパーにとって大きな変化になるのに加え、インフラコストも発生します。そのため、環境をいきなり変えてしまうのではなく、まずは無料トライアルがある[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールを利用し、使用感を確認するようにしてください。\n\nGitLabでは、優れた性能の[CI/CDパイプライン](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を提供しています。[無料トライアル](https://about.gitlab.com/free-trial/)も受け付けているため、お気軽にお問い合わせください。\n\n## 多くの企業がGitLabのCI/CDを選ぶ理由とは？\n\n多くの[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールは、CIとCDを別々のツールで管理し、それを結びつけることでCI/CDを実現しています。一方、GitLabは長年の[DevOpsプラットフォーム](https://about.gitlab.com/ja-jp/platform/)の提供経験をもとに、ビルドーテストーデプロイが一体となった[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールの提供を行っています。\n\nGitLabツールであれば、他社のツールとの結合を一切考慮することなく、すべて[1つのツール内で完結](https://about.gitlab.com/ja-jp/devsecops/)できます。\n\n## 結論\n\n[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)は、近年重要性が高まっているアプリケーション開発のスピーディ化を実現するために非常に重要です。日本ではまだまだ導入企業が少ないものの、世界ではスタンダードになりつつあります。もし世界水準での開発環境を整えたければ、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ツールの導入を少しでも早く検討するとよいでしょう。\n\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*","insights",[706,707,9],"CI","CD","2024-11-06",{"slug":710,"featured":6,"template":686},"how-to-keep-up-with-ci-cd-best-practices","content:ja-jp:blog:how-to-keep-up-with-ci-cd-best-practices.yml","How To Keep Up With Ci Cd Best Practices","ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices.yml","ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices",{"_path":716,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":723,"config":734,"_id":736,"_type":14,"title":737,"_source":16,"_file":738,"_stem":739,"_extension":19},"/ja-jp/blog/southwest-looking-to-help-developers-take-flight",{"title":718,"description":719,"ogTitle":718,"ogDescription":719,"noIndex":6,"ogImage":720,"ogUrl":721,"ogSiteName":670,"ogType":671,"canonicalUrls":721,"schema":722},"ソフトウェア開発効率化に成功したサウスウエスト航空の事例","GitLabのDevSecOpsプラットフォームによって業務削減と開発効率化に成功したサウスウエスト航空の事例をご紹介します。ぜひ参考にしてください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665272/Blog/Hero%20Images/AdobeStock_380312133.jpg","https://about.gitlab.com/blog/southwest-looking-to-help-developers-take-flight","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ソフトウェア開発効率化に成功したサウスウエスト航空の事例\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n        \"datePublished\": \"2024-01-30\",\n      }",{"title":718,"description":719,"authors":724,"heroImage":720,"date":726,"body":727,"category":728,"tags":729,"updatedDate":733},[725],"Sharon Gaudin","2024-01-30","世界最大の格安航空会社「サウスウエスト航空」のITリーダーは、デベロッパーのワークフローから時間のかかる反復作業を取り除き、時間に余裕を持たせることで、より大きなプロジェクトに集中できる環境を作り上げています。特に意識しているのは、デベロッパーの仕事を「容易」にすることです。\n\n航空会社のDevOpsチームが、GitLabの導入と運用によって問題の検出力と解決力を飛躍的に向上させている事例についてご紹介します。\n\nサウスウエスト航空の副社長兼最高情報責任者であるJim Dayton氏は、次のように述べています。\n「デベロッパーを阻害する要因をできる限り取り除くことが、当社のやり方です。彼らがソフトウェア開発に携わるのは、その創造性が好きで、問題解決が大好きだからだと確信しています。よって、私たちの役割は、彼らの邪魔をしているものを排除することなのです。」\n\nDayton氏がこの考えを実現するために利用しているものが[GitLabのプラットフォーム](https://about.gitlab.com/ja-jp/platform/)です。\n\nDayton氏は、GitLabがダラスで開催した「[DevSecOps World Tour](https://about.gitlab.com/events/devsecops-world-tour/)」の舞台上インタビューで、デベロッパーの立場に立ちながら彼らの業務を滞りなく進行させるサウスウエスト航空の取り組みについて語りました。また、GitLabのエンタープライズソリューションアーキテクチャのディレクターであるReshmi Krishnaとの対談では、人工知能機能がチームにもたらすメリットについて意見を述べました。\n\nサウスウエスト航空の幹部は、アプリケーション開発にDevOpsアプローチを導入していると述べ、同社がデベロッパーにより多くの自己解決型ツールとナレッジマネジメントプロセスを提供していると語りました。\n\n「私たちは、デベロッパーが問題をより素早く調べ、解決策を発見できるようにして、頭の切り替えをできる限り減らしたいと考えています。幹部の私たちが、彼らに求めることを正確に把握し、何が彼らの生産性を妨げているのかを見極めなければなりません。」\n\nDayton氏によると、サウスウエスト航空は2019年にGitLabとの関係を確立して以来、ソフトウェア開発プロセスの一貫性確保に注力しています。これは、コードをGitLabの共有リポジトリに移すことを意味します。すべてのコードがどこに保管されているのかを把握することで、チームはより簡単に指標を評価し、コードの再利用による効率化を目指せるようになります。\n\nDayton氏は次のように付け加えました。  \n「弊社は現在、エンタープライズ・パイプラインを完成させる過程にあり、チームの移行を開始する準備が整っています。様々なアプリケーション開発チームと緊密に協力しており、新たに構築中のパイプラインに必要なものを理解し、移行する準備を進めています。年末までにはほとんどのプロセスが完了すると想定しています。」\n\n### AIの将来性\n\nDayton氏は、AIの利用はデベロッパーがより大きく、より革新的なタスクに集中できるようにする方法の1つだと述べています。\n\n生成AIは、脆弱性の説明やコードの提案、コード補完のいずれにおいても、ソフトウェア開発におけるライフサイクル全体のワークフローに多大な影響を与える能力を備えています。プラットフォームに組み込まれたAIツールを活用することで、セキュリティを強化し、コードレビューやアプリケーション開発に費やす時間を短縮できます。\n\nDayton氏は、AI機能を使用することで開発とデプロイを迅速かつ容易にできるようになると期待を寄せています。\n\n「私たちは、凡庸で形式的な作業をできる限り排除したいと思っています。AIを使えば、それが実現できるかもしれません。AIについては大きな話題性がある一方で、実際に大きな可能性も秘めています。特定されたばかりの脆弱性に対するソリューションを即座に提供できること、コードの一部がどのような処理を行っているかを教えてくれることなどは、そのすばらしい例です。これが何と統合しているのか、アクセスしているデータは何か、その理由などもAIが教えてくれます。例えば、このアプリケーションで過去1年間に発生したインシデントの20%が、この特定のコーディングセットによるものであることの理由を英語でわかりやすく説明してとAIに依頼もできます。AIの力が発揮されるのはこういうところでしょう。」\n\nDayton氏は、AIがデベロッパーに取って代わることはないが、彼らの仕事をスムーズに進められるよう支援するだろうと考えます。AIがもたらすもう一つのメリットは、コロナ後に多くの人がリモートで仕事をしている時代に、デベロッパーをつなぐことも挙げられます。\n\n「GitLabのロードマップにある便利な機能のひとつが『レビュアーの推奨』です。以前であればコードレビューを依頼する際には、壁越しや別の部屋に向けて『誰か私のコードを見てくれないか』と叫ぶ必要がありましたが、リモートの環境においてはそれは不可能です。AIは、そのコードで実際に作業したことがある人や、そのコードでインシデントを解決したことがある人を見つけ出し、提案してくれます。これがレビュープロセスにどのくらいの価値をもたらすのかは容易に想像できるでしょう。自動化が進めば進むほど、手動のステップや待機時間が少なくなると思います。」\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/UnUfp7pKnEQ?si=qcX2Qm3zpgQOV4xy\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*サウスウエスト航空はテキサス州ダラスに拠点を置く、およそ240億ドル規模の企業です。72,000人の従業員を擁し、120の目的地に1日4,000便を運航しています。サウスウエスト航空は他のどの航空会社よりも国内線を多く運行しています。GitLabのさらなる魅力については、 [GitLabを選ぶ10の理由](https://about.gitlab.com/customers/)をご覧ください。*","customer-stories",[9,730,731,732],"DevOps platform","AI/ML","customers","2024-11-25",{"slug":735,"featured":6,"template":686},"southwest-looking-to-help-developers-take-flight","content:ja-jp:blog:southwest-looking-to-help-developers-take-flight.yml","Southwest Looking To Help Developers Take Flight","ja-jp/blog/southwest-looking-to-help-developers-take-flight.yml","ja-jp/blog/southwest-looking-to-help-developers-take-flight",{"_path":741,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":742,"content":750,"config":760,"_id":762,"_type":14,"title":763,"_source":16,"_file":764,"_stem":765,"_extension":19},"/ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":743,"description":744,"ogTitle":745,"ogDescription":744,"noIndex":6,"ogImage":746,"ogUrl":747,"ogSiteName":670,"ogType":748,"canonicalUrls":747,"schema":749},"チュートリアル：GitLabでリリースとリリースノートを自動化する","GitLabのChangelog APIを使用すると、リリースアーティファクト、リリースノートなどの変更をまとめた、包括的な変更履歴の生成を自動化できます。","チュートリアル：GitLabでリリース自動化とリリースノート自動生成","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab","記事","\n                        \n        {\"@context\": \" https://schema.org \",\n        \"@type\": \"Article\",\n        \"headline\": \"チュートリアル：GitLabでリリース自動化とリリースノート自動生成\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\n      \",}",{"title":745,"description":744,"authors":751,"heroImage":746,"date":753,"body":754,"category":755,"tags":756,"updatedDate":759},[752],"Ben Ridley","2023-11-01","***2025年の更新情報**  GitLab Changelog APIは進化を続けており、今回のブログでは取り上げていない優れた新機能も追加されています。たとえば、コミット履歴からテンプレート化された値を使ってカスタムの変更履歴を提供できるようになっています。[詳しくは、変更履歴に関する公式ドキュメントをご覧ください。](https://docs.gitlab.com/user/project/changelogs/)*\n\nユーザーが頼りにしているソフトウェアを開発する際には、各リリースでの変更点を効果的に伝えることが不可欠です。新機能や変更点、削除された内容をきちんと伝えることで、ユーザーはソフトウェアを最大限に活用でき、アップグレード時の思わぬトラブルも回避できます。\n\nこれまで、リリースノートの作成や変更履歴の管理は手間のかかる作業でした。デベロッパーが外部ツールで変更を追跡したり、リリースマネージャーがマージ履歴を手作業で確認したりする必要があったためです。GitLabのChangelog APIを使うと、Gitリポジトリに記録された豊富な履歴情報を活用して、リリースノートの作成や変更履歴の管理を簡単に行うことができます。\n\nこのチュートリアルでは、GitLabを使ったリリースの自動化について詳しく説明します。リリースアーティファクトの生成、リリースノートの作成、そしてユーザーに関係する変更点をすべて網羅した包括的な変更履歴の生成方法について取り上げます。\n\n## GitLabにおけるリリース\nまずは、GitLabでリリースがどのように機能しているのかを見ていきましょう。\n\nGitLabにおけるリリースとは、Gitタグで識別される特定のコードバージョンのことを指します。このリリースには、前回のリリース以降に行われた変更内容（およびリリースノート）や、そのバージョンのコードからビルドされた関連アーティファクト（Dockerイメージ、インストールパッケージ、ドキュメントなど）が含まれます。\n\nリリースは、GitLabのUIを使って作成・管理することもできますし、Release APIを呼び出すか、CIパイプラインの中に特別な`release`ジョブを定義することでも実現できます。このチュートリアルでは、CI/CDパイプライン内の`release`ジョブを使用します。これにより、テストやコードスキャンなどに使っている自動化プロセスを、リリースの実行にも拡張できるようになります。\n\nリリースを自動化するために、まず確認しなければならないことがあります。「リリースノートや変更履歴を作成するための変更情報は、どこから取得するのか？」その答えは、Gitリポジトリです。コミットメッセージやマージコミットの履歴を通じて、豊富な開発履歴が得られます。この情報を活用して、リリースノートや変更履歴を自動生成できるか試してみましょう。\n\n## コミットトレーラーの導入\n[コミットトレーラー](https://git-scm.com/docs/git-interpret-trailers)とは、Gitのコミットメッセージの末尾に追加する、構造化されたエントリーのことです。書き方はシンプルで、`\u003CHEADER>:\u003CBODY>`という形式のメッセージをコミットの最後に追加するだけです。これにより、`git`のコマンドラインインターフェース（CLI）ツールがそれらを解析して、他のシステムで利用できるようになります。たとえば、すでに使ったことがあるかもしれませんが、`git commit --sign-off`でコミットに署名する機能もこの仕組みを使っています。これは、`Signed-off-by: \u003Cあなたの名前>`というトレーラーをコミットに追加することで実現されています。このトレーラーには、好きな構造化データを自由に追加できるので、変更履歴に役立つ情報を保存する場所として非常に便利です。\n\n実際に、コミットに`Changelog: \u003Cadded/changed/removed>`というトレーラーを使うと、GitLabのChangelog APIがそれを解析し、自動的に変更履歴を生成してくれます！\n\nそれでは、実際のコードベースに変更を加えてリリースを行い、リリースノートと変更履歴のエントリーを生成する手順を見ていきましょう。\n\n## サンプルプロジェクトについて\n今回のブログでは、シンプルなPythonのWebアプリのリポジトリを使っています。仮に、このアプリケーションのバージョン1.0.0がちょうどリリースされたばかりで、これが現在のコードのバージョンだとしましょう。また、GitLab上で1.0.0のリリースも作成してありますが、これはまだ自動化されたリリースパイプラインを作っていないため、手動で作成しました。\n\n![GitLabのUI上で、バージョン1.0.0のリリースが表示されているスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n## 変更の実施\n現在は開発を急ピッチで進めている段階なので、今日はアプリケーションのバージョン2.0.0のリリース作業を進めていきます。2.0.0リリースでは、アプリに新機能の「チャットボット」を追加します。そして、量子ブロックチェーン機能は削除します。これは最初のベンチャーキャピタル向けに必要だっただけなので、もう不要です。さらに、2.0.0リリースに向けて、CI/CDパイプラインに自動リリースジョブも追加する予定です。\n\nまずは不要な機能の削除から始めましょう。不要な部分を削除したマージリクエストを作成しました。ここで重要なのは、コミットメッセージに`Changelog: removed`トレーラーを含めることです。これを行う方法はいくつかあります。たとえば、最初からコミットに直接含めたり、インタラクティブリベースを使ってCLIで後から追加したりもできます。しかし、今回の状況では、一番簡単な方法は最後にGitLabの`Edit commit message`ボタンを使って、マージコミットにトレーラーを追加する方法だと思います。\n\n![GitLabのUIに表示された、使われていない機能を削除するマージリクエストのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\nこの方法を使えば、マージコミットのタイトルをもっと簡潔なものに変更することもできます。ここでは、マージコミットのタイトルを'Remove Unused Features'に変更しました。これは変更履歴のエントリに表示されます。\n\n次に、2.0.0リリース用の新機能を追加しましょう。ここでも、新機能を含む別のマージリクエストを開き、マージコミットを編集して`Changelog: added`トレーラーを追加し、コミットのタイトルをより簡潔に編集するだけです。\n\n![GitLabのUIに表示された、新しい機能を追加するマージリクエストのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png) \n\nこれで、バージョン2.0.0をリリースする準備はほとんど整いました。ただし、今回は手動でリリースを作成したくありません。そのため、リリースの前に`.gitlab-ci.yml`ファイルにいくつかのジョブを追加し、コードに`2.0.0`のような新しいバージョンのタグを付けた際に、自動でリリース処理を行い、対応するリリースノートや変更履歴のエントリを生成するようにします。\n\n**注：**変更履歴のトレーラーを強制したい場合は、[Dangerのようなツールを使用して、マージリクエストの規則を自動的にチェックする](https://docs.gitlab.com/ee/development/dangerbot.html)方法を検討してください。\n\n## 自動リリースパイプラインの構築\nパイプラインを機能させるには、プロジェクトアクセストークンを作成し、GitLabのAPIを呼び出して変更履歴のエントリーを生成できるようにする必要があります。[APIスコープを指定してプロジェクトアクセストークンを作成](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token)し、それを`CI_API_TOKEN`という名前の[CI/CD変数として保存](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui)します。この変数を参照して、APIの認証を行います。\n\n次に、`gitlab-ci.yml`ファイルに以下の2つの新しいジョブを追加します。\n```yaml\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\n上記の設定では、`prepare_job`が`curl`と`jq`を使ってGitLabのChangelog APIエンドポイントを呼び出し、その結果を`release_job`に渡して、リリースの作成を行います。詳しく見ていきましょう。\n- まず、先ほど作成したプロジェクトアクセストークンを使ってGitLabのChangelog APIを呼び出し、リリースノートを生成します。そして、その出力をアーティファクトとして保存します。\n- バージョンには`$CI_COMMIT_TAG`変数を使用しています。この仕組みが機能するには、タグにセマンティックバージョニング（たとえば`2.0.0`のような形式）を使用する必要があります。そのため、リリースジョブには、セマンティックバージョンのタグが付いているかどうかを確認する`rules`セクションを追加しています。\n\t- GitLabのChangelog APIを使うには、セマンティックバージョニングが必要です。この形式を用いて、現在のリリースとの比較対象となる最新リリースを特定します。\n- GitLabが提供する公式の`release-cli`イメージを使用しています。ジョブ内で`release`キーワードを使うには、この`release-cli`が必要です。\n- `release`キーワードを使用して、GitLab上にリリースを作成します。これは、リリースの作成と必須フィールドの入力のために確保されている特別なジョブキーワードです。\n- リリースの`description`には、ファイルを引数として渡すことができます。今回の例では、`prepare_job`で生成し、アーティファクトとしてこのジョブに渡されたファイルを使っています。\n- さらに、パイプラインの早い段階でビルドされているコンテナイメージも、リリースアセットとして追加しています。ビルドプロセスの中で作成したバイナリやドキュメントなども、パイプライン内でアップロード済みのURLを指定することで、リリースアセットとして添付できます。\n\n## 自動リリースの実行\nこの設定が完了すれば、リリースを実行するために必要なのは、バージョン付けのルールに従ったタグをリポジトリにプッシュすることだけです。CLIからタグをプッシュすることもできますが、ここではGitLabのUIを使って、mainブランチにタグを作成する例をご紹介します。タグを作成するには、サイドバーからコード > タグ > 新しいタグを選択します。\n![タグの作成方法を示すGitLabのUIのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\nタグの作成が完了すると、パイプラインの実行が開始されます。 GitLabのChangelog APIが、今回のリリースと前回のリリースの間に行われた変更をすべて含むリリースノートをMarkdown形式で自動的に生成します。 以下は、この例で生成されたMarkdownの出力結果です。\n\n```md\n## 2.0.0 (2023-08-25)\n\n### added (1 change)\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n### removed (1 change)\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n```\n\nご覧のとおり、GitLabはgitのコミットトレーラーをもとに、リリースノートのエントリを自動で抽出しています。さらに、変更の詳細やディスカッションが確認できるよう、マージリクエストへのリンクも付けられています。\n\nそしてこちらが、最終的に作成されたリリースです。\n![GitLabのリリースUIに表示された、バージョン2.0.0のリリース画面](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n## 変更履歴の作成\n次に、変更履歴（すべてのリリースノートをまとめた履歴）を更新します。これを行うには、先ほど使用したChangelog APIエンドポイントに対して、`POST`リクエストを送ります。\n\n必要であれば、この処理をリリースパイプラインの一部として実行することも可能です。たとえば、prepareジョブの`script`セクションに以下の内容を追加します。\n```sh\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n```\n\n**この処理は実際にリポジトリを変更する点にご注意ください。** 具体的には、最新のリリースノートを`CHANGELOG.md`ファイルに追加するためのコミットが作成されます。\n![変更履歴ファイルを更新するコミットを示すリポジトリのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\nこれですべて完了です！`git`が提供する豊富な履歴情報と、便利なコミットトレーラーを活用することで、GitLabの強力なAPIとCI/CDパイプラインを使って、リリースプロセスとリリースノートの生成を自動化できます。\n\n> この記事で使用したプロジェクトを実際に確認したい場合は、[こちらのリンク](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo)からご覧いただけます。\n","product",[757,706,109,9,682,758],"チュートリアル","git","2025-06-05",{"slug":761,"featured":6,"template":686},"tutorial-automated-release-and-release-notes-with-gitlab","content:ja-jp:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"_path":767,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":768,"content":774,"config":783,"_id":785,"_type":14,"title":786,"_source":16,"_file":787,"_stem":788,"_extension":19},"/ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture",{"title":769,"description":770,"ogTitle":769,"ogDescription":770,"noIndex":6,"ogImage":771,"ogUrl":772,"ogSiteName":670,"ogType":671,"canonicalUrls":772,"schema":773},"マイクロサービスアーキテクチャの基本とそのメリット","マイクロサービスアーキテクチャは、環境を細分化することで開発がスピーディに、かつ低コストで行えます。拡張性やセキュリティ面にも優れています。","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":769,"description":770,"authors":775,"heroImage":771,"date":777,"body":778,"category":779,"tags":780,"updatedDate":782},[776],"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合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト）*","devsecops",[9,9,781],"features","2024-12-12",{"slug":784,"featured":91,"template":686},"what-are-the-benefits-of-a-microservices-architecture","content:ja-jp:blog:what-are-the-benefits-of-a-microservices-architecture.yml","What Are The Benefits Of A Microservices Architecture","ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture.yml","ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture",{"_path":790,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":791,"content":794,"config":808,"_id":810,"_type":14,"title":811,"_source":16,"_file":812,"_stem":813,"_extension":19},"/ja-jp/blog/what-is-docker",{"noIndex":6,"description":792,"title":793},"Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。","Dockerとは：GitLabとの統合とコンテナについての入門編 | GitLab",{"title":795,"description":796,"authors":797,"date":799,"body":800,"category":801,"heroImage":802,"tags":803},"Dockerとは：超入門編","Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。\n",[798],"GitLab Team","2025-06-18","Dockerコンテナ技術は、2013年にオープンソースの「Dockerエンジン」として公開され、翌年2014年には本番環境向けの商用版が発表されました。その後約10年の間に、Dockerは使いやすさと高い利便性から、IT業界で瞬く間に広く普及してきました。これからもその人気は高まっていくでしょう。\n\nしかしその一方で、いまだに「Dockerとは何ですか」という声もよく耳にします。この記事では、Docker環境の導入を検討中で、Dockerにまだ不慣れなデベロッパーやプログラマーの皆様を対象に、Dockerの基本を解説します。Dockerに触れたことのない初心者向けの「Docker超入門編」です。\n\n## 目次\n\n1. Dockerとは：超入門編\n2. Dockerの目的\n\n   * Dockerとは\n   * Dockerでできること\n   * Dockerイメージとは\n   * Dockerコンテナとは\n   * Dockerfileとは\n   * Dockerはなぜ重要なのか\n3. Dockerの主な機能\n\n   * Dockerの特徴\n   * Docker Composeとは\n4. アプリケーションのデプロイにおけるDockerのメリット\n\n   * 開発環境と本番環境のシームレス化\n   * 起動の軽量化・処理速度の高速化\n   * バージョン管理のしやすさ\n   * 優れたスケーラビリティ\n5. Dockerのデメリット\n\n   * ひとつのOSを使わなければならない\n   * 大規模開発時のオーバーヘッド\n   * 技能習得に時間がかかる\n   * セキュリティに脆弱性が生じることもある\n   * コンテナ間での連携が難しい\n6. GitLabはDockerが抱える課題をどのように解決するのか\n7. GitLabのDevSecOpsにおけるDockerの役割\n8. まとめ\n9. FAQ（よくある質問）\n\n## Dockerの目的\n\nはじめに、Dockerとはどういったもので、何ができて、どうして便利なのか、なぜ重要なのか、Dockerの目的に着目しながらその概念をまとめていきます。\n\n### Dockerとは\n\nDockerは、Linuxのコンテナ技術を用いた軽量なソフトウェアコンテナプラットフォームです。アプリケーションの開発、出荷、実行を簡易化するために設計されました。Dockerを使えば、すべての依存関係と一緒にアプリケーションをパッケージ化できるため、依存関係を一つひとつ手動でインストールする必要がなくなり、一貫性のあるコード実行が可能になります。\n\nDockerを使えばアプリケーションの実行環境を標準化でき、環境の違いによる問題を減らすことで開発から本番環境へのデプロイ時間を大幅に短縮できます。\n\nLinuxには以前からコンテナ仮想化という技術がありました。この技術を使うと、プログラムを開発・実行環境から隔離することにより、複数のプログラムを素早く実行できます。ただし、この従来型の仮想化技術は、仮想環境を構築するためにホストとなるOS（オペレーティングシステム）に依存する必要がありました。Dockerはこのコンテナ仮想化技術をOSに関係なく簡単に扱えるようにしたソフトウェアといえます。\n\nDockerの基本概念はイメージとコンテナです。Dockerイメージは、読み取り専用のテンプレートであり、コンテナを作成するための指示が記述されています。たとえば、コンテナで実行するアプリケーションとその依存関係、環境変数、ファイルシステムなどがこれに含まれます。\n\n### Dockerでできること\n\nDockerを使うと、1台のマシン中に複数のコンテナ（仮想環境）をビルドできるため、いくつかの開発環境に対応することができます。つまり、1台のサーバー上で複数のアプリケーションを効率的に動かすことができるのです。アプリケーションの開発環境をDockerで構築すれば、たとえば開発環境（Windows）で動いていたアプリケーションがLinux上で起動しない、といった問題は発生しません。Dockerで構築した環境は、他のデベロッパーとクラウド上で簡単に共有できるため、開発作業がスムーズに進められます。\n\n### Dockerイメージとは\n\nDockerイメージは、アプリケーションを実行するのに必要なソースコードと必要な依存関係をパッケージ化したものです。Dockerコンテナを実行する際には、このDockerイメージが必要です。\n\nDockerイメージは、コンテナイメージを構成する複数のファイルに、`Dockerfile` を合わせてビルドします。つまり、Dockerイメージは、手作業で書くのではなく、コマンドを使って作成します。\n\nそのため、Dockerイメージは単一のファイルではなく、Dockerコンテナの実行に必要なパッケージ（ファイルやメタデータの集合体）であることを理解することが重要です。\n\n### Dockerコンテナとは\n\nLinuxのコンテナは、アプリケーションを内包し、必要なライブラリや依存関係、ファイルが含まれています。\n\n一方、Dockerコンテナは、Dockerイメージの実行可能なインスタンスです。これはDockerイメージから生成され、アプリケーションを実行するためのランタイム環境です。ただし、ハイパーバイザーを使用する従来の仮想化とは違い、DockerのコンテナはホストOS（オペレーティングシステム）のカーネルで実行されます。Dockerイメージ内には、個別のOSはありません。\n\nDockerイメージは環境のスナップショットであり、コンテナはソフトウェアを実行する環境といえます。\n\n### Dockerfileとは\n\n`Dockerfile`は文字情報を主体とするファイルで、ファイルの拡張子はありません。`Dockerfile`には、アプリケーションの構築から実行までのプロセスに必要なコマンドが記述されています。どのファイルをどこから取得して、どんな処理を行ない、Dockerイメージに含めるのかなどを記述します。\n\n`Dockerfile`は、Dockerイメージを作成するためのテキストファイルです。コンテナイメージをビルドする場合も、コンテナのビルド手順を`Dockerfile`で定義する必要があります。この`Dockerfile`には、命令のスクリプトが含まれており、Dockerはコンテナイメージをビルドする際にこのスクリプトを使用します。\n\n### Dockerはなぜ重要なのか\n\nDockerは、コンテナに関する既存のコンピューティングの概念、とりわけLinuxの「cgroups」や「namespaces」、「overlayfs」などの技術を活用しています。これは、アプリケーションの依存関係をサーバーやネットワークなどのインフラストラクチャから隔離したいという、デベロッパーやシステムオペレーターのニーズに応えるものでした。\n\nDockerを使うと、1台のサーバー上でさまざまなアプリケーションを簡単に仮想化・実行できるようになります。さらには、ローカルマシンに依存しない開発環境を実現でき（開発環境の統一）、本番環境に近い環境でのシミュレーションが可能になり、アプリケーションの依存関係も管理できます。加えて、ビルド、テスト、デプロイまでの各プロセスを一貫して行なうことができます。\n\n## Dockerの主な機能\n\nDockerは、Linuxのコンテナ技術を使用しています。Dockerコンテナはよく仮想マシンと比較されます。\n\n仮想マシンでは、ホストマシン上でハイパーバイザーを利用してゲストOSを動かし、さらにその上でミドルウェアやライブラリ、さらにその上にアプリなどを実行します。\n\nそれに対し、コンテナはホストマシンのカーネルを利用し、プロセスやユーザーなどを隔離します。そのため、非常に軽量で、まるで別のマシンが動いているかのように動作します。その結果、アプリなどを高速に起動、停止することが可能です。\n\nDockerは、次の4つの構成要素から成り立っています。\n\n* **Dockerイメージ：** アプリケーション実行に必要なソースコード、アプリと依存関係のパッケージ\n* **Dockerコンテナ：** アプリケーションを実行するランタイム環境\n* **Docker Hub：** クラウド上のレジストリサービス。アプリケーションやサービスコンテナのビルドと配信を行なう\n* **Dockerfile：** Dockerイメージを作成するために実行するコマンドライン命令を含むテキストファイル\n\n### Dockerの特徴\n\nDockerには、次のような特徴があります。\n\n* **軽量かつ高速：** 1つのOSで複数のコンテナを管理でき、仮想マシンより軽量で高速に立ち上げることが可能。\n* **環境の一貫性が保持でき再現性がアップ：** Dockerコンテナは異なるプラットフォームでも一貫して動作するため、ローカル、クラウド、ハイブリッド環境への移行が簡単にできる。\n  移植性が高い －クラウドシステムとの親和性が高く、主要なクラウドプロバイダーはDockerコンテナの実行をサポートしている。\n* **サンドボックスの提供：** セキュリティ対策やソフトウェア開発において、隔離された仮想環境でプログラムを実行・検証できる。このため、ホストマシンの環境を守ることができる。\n* **IaC（インフラストラクチャのコード化）を使用して、インフラをコード化：** Dockerfileによりミドルウェアのインストールや環境設定をコード化して管理できる。\n\n### Docker Composeとは\n\nDocker Composeは、複数のDockerコンテナを一元管理する、 Dockerアプリケーションのためのツールです。YAMLファイルを使用してアプリケーションのサービスを設定します。単一のコマンドで複数のサービスをまとめて生成したり、起動・停止したりすることができます。\n\nDocker Composeのコマンド例は次のとおりです。\n\n* **`docker-compose up`：** サービス用のコンテナを構築、作成、起動、アタッチします。リンクされているサービスがまだ起動していない場合は、それらも起動します。\n* **`docker-compose ps`：** Docker Composeで管理されている稼働中のサービスを一覧表示します。\n* **`docker-compose build`：** Docker Composeファイルで定義されているサービスをビルド（構築）します。\n\n## アプリケーションのデプロイにおけるDockerのメリット\n\nアプリケーションのデプロイにおけるDockerのメリットは次のとおりです。\n\n### 開発環境と本番環境のシームレス化\n\nコンテナ技術の利用を開発環境と本番環境で統一することで、環境の違いにより起こる問題を減らすことができます。その結果、デベロッパーと運用チームとの連携がスムーズに行われ、チーム間で発生していた問題も最小限に抑えられます。\n\n### 起動の軽量化・処理速度の高速化\n\nDockerのコンテナ技術は従来の仮想環境より軽く、アプリを瞬時に起動できます。これは、CPUやメモリなどのコンピュートリソースを必要最低限しか使用しないためです。起動速度が上がることで、開発にも集中できます。\n\n### バージョン管理のしやすさ\n\nDockerでは、GitLabなどのソースコードのバージョン管理ツールを使用できるため、バージョン管理の可視化が進むだけでなく、ロールバックやアップデートも簡単に行なえるようになります。\n\n### 優れたスケーラビリティ\n\nコンテナは軽量で拡張性に優れています。必要に応じて簡単に増減できます。これにより、アプリケーションの拡張やスケーリングを迅速に行なえるため、変わりゆく状況にも柔軟に対応できます。\n\n## Dockerのデメリット\n\nDockerにはさまざまなメリットがありますが、いくつかデメリットも存在します。以下にデメリットを挙げます。\n\n### 1つのOSを使わなければならない\n\nDockerは1つのOS上で複数のコンテナを作成します。これにより起動速度や処理速度の面でメリットがありますが、同時にデメリットになることもあります。たとえば、異なるOS環境で検証をしたい場合には、別のマシンや仮想マシンを準備する必要が生じます。\n\n### 大規模開発時のオーバーヘッド\n\nDocker自体は軽量ですが、大規模システムに拡張する場合には、Dockerの管理に伴う負荷が発生します。Dockerは1台のサーバーで多数のコンテナを実行できますが、その反面、管理やオーケストレーションが必要になり、その処理のためにオーバーヘッドが生じる場合があります。Dockerだけですべての管理を行なうのが困難になることもあります。\n\n### 技能習得に時間がかかる\n\nDockerは他の仮想マシンと異なる手法で仮想環境を構築します。つまり、デベロッパーは新しいコンセプトをすべてゼロから習得しなければならず、それには時間がかかります。Dockerの動作原理をきちんと理解せずに使用すると、あとでトラブルや問題が発生することもあります。Dockerについてしっかりと学習してから運用に取り組むようにしましょう。\n\n### セキュリティに脆弱性が生じることもある\n\nDockerはコンテナ型アーキテクチャです。1台のマシン上で複数のコンテナが動作するため、このことに起因する脆弱性には注意が必要です。たとえば、複数のコンテナがホストOSのリソースやカーネルを共有しているため、一つのコンテナに脆弱性があった場合、全体にその影響が及ぶ可能性があります。\n\n### コンテナ間での連携が難しい\n\n複数のコンテナ間での連携を検討している場合、各種設定が難しいために、運用時に問題が発生することがあります。たとえば、アプリとデータベースを別のコンテナで作成し、一緒に運用したい場合には、同一ホスト内で通信設定をしなければなりません。ポートやソケットを開放する場合にはセキュリティ面でリスクが生じます。それを避けるために設定を複雑にしてしまうと、今度は運用面で問題が起きる恐れがあります。コンテナを連携させる際は、設計段階から十分に検討することが重要です。\n\n## GitLabはDockerが抱える課題をどのように解決するのか\n\nDockerコンテナ内にGitLabをインストールすることができます。[GitLab](https://about.gitlab.com/ja-jp/platform/)は、Git「分散型バージョン管理システム」を主体としたDevSecOpsプラットフォームです。ソフトウェア開発ライフサイクル全体に対応する単一のプラットフォームで、GItLabを活用することで高品質なソフトウェアの迅速なデリバリーを実現できます。\n\nDockerコンテナ内にGitLabをインストールすると、GitLabインスタンスにアクセスできるようになります。Dockerコンテナへの[GitLab Dockerイメージのインストールは公式にサポート](https://about.gitlab.com/ja-jp/install/)されています。\n\nDockerが抱えるいくつかの問題のうち、特にセキュリティについては、GitLabのDevSecOps（開発、セキュリティ、運用）を活用して対処することができます。GitLabのDevSecOpsでは、[シフトレフト](https://about.gitlab.com/ja-jp/topics/ci-cd/shift-left-devops/)を重視しており、セキュリティ対策を開発サイクルの早い段階に組み込むことにより、コンテナイメージの持つセキュリティの問題の早期発見と対応を図っています。継続的インテグレーションによってこのシフトレフトのコンセプトを実践することで、セキュリティ対応にかかっていたコストを削減できます。\n\nDevSecOpsにおいて重要なCI/CDを実現するためには、自動化が欠かせません。GitLabではパイプラインがCI/CDの命令をまとめています。そして、その指示に従いプロセスの自動化を実現するときの基盤になっているのが[GitLab Runner](https://docs.gitlab.com/runner/)（英語）です。GitLab Runnerはセキュリティのシフトレフトを実現する上で重要な役割を果たしています。\n\nGitLab Runnerはセキュリティスキャンやテストを指定したタイミングで自動で実行してくれます。また、レポート作成ジョブを実行して、ダッシュボードに最新情報を表示することも可能です。\n\n## GitLabのDevSecOpsにおけるDockerの役割\n\nGitLabを活用したDevSecOpsインテグレーションにおいても、Dockerは非常に大切な役割を担っています。\n\n### CI/CDジョブのコンテナ化\n\nGitLab CI/CDでは、CI/CDパイプラインでDockerコンテナを使用することで、次のようなことが可能になります。\n\n* **一貫性：** CI/CDジョブはコンテナ内で実行されるため、依存関係や環境の違いによるエラーが防げます。\n* **スケーラビリティ：** コンテナは軽量かつ迅速に起動でき、大規模なパイプラインでも効率的に実行できます。\n* **環境の柔軟性：** ジョブごとに異なるDockerイメージを指定できるため、必要な環境を簡単に準備できます。\n\nGitLab RunnerのDockerイメージは、UbuntuまたはAlpine Linuxをベースにしています。Dockerイメージは標準の`gitlab-runner`コマンドを内包しており、ホストに直接GitLab Runnerをインストールしたかのように動作します。\n\n### セキュリティスキャンの自動化\n\nセキュリティはDevSecOpsでの重要な要素であり、Dockerはこれをサポートします。\n\n* **コンテナイメージのセキュリティスキャン：** GitLabには、CI/CDパイプラインでDockerイメージをスキャンする機能があります。このスキャンにより脆弱性がチェックされ、イメージ内の依存関係やコードの安全性を評価できます。\n* **コンテナ脆弱性スキャンの自動化：** GitLabにはTrivyやAquaなどのセキュリティツールを統合できます。DockerイメージのOSやアプリケーションが最新であるか、既知の脆弱性がないかをチェックします。\n\n### IaC（インフラストラクチャのコード化）と環境管理\n\n* **再現性：** DockerをGitLabのCI/CDジョブ内で使用することで、開発環境と本番環境の整合性を保つことできます。\n* **ステージングやテスト環境を即時に構築：** Docker ComposeやKubernetesと連携することで、特定のブランチやマージリクエストごとに分離された環境をGitLabで作成できます。これにより、テストやセキュリティスキャンを効率的に実行できます。\n\n### デプロイの効率化\n\nGitLabは、Dockerを使用する以下のデプロイパターンをサポートしています。\n\n* **Dockerイメージのビルドとプッシュ：** アプリをコンテナイメージとしてビルドして、GitLabのContainer Registryや他のDockerレジストリにプッシュします。\n* **継続的デリバリー：** Dockerイメージを使ってコンテナオーケストレーションツールにデプロイすることで、迅速で安全なリリースが可能になります。\n\n### マイクロサービスアーキテクチャのサポート\n\nGitLabとDockerを組み合わせることで、マイクロサービスアーキテクチャを簡単に構築できます。マイクロサービスは別々のDockerコンテナとして実行します。GitLab CI/CDパイプラインを使うと、以下のことを管理できます。\n\n* サービス間の依存関係の設定\n* 個別のセキュリティスキャン\n* バージョン管理（ロールバックが容易になります）\n\n## まとめ\n\n2013年の公表以来、Dockerは瞬く間にIT業界に広く普及しました。本記事では、Dockerの基本概念、基本技術、Dockerを使って何ができるのか、なぜDockerが重要なのか、Dockerを理解上でよく目にする用語などについて紹介してきました。\n\nDockerを使う場合には、DevSecOpsにとって大切なCI/CDを実現するためにも、GitLab CI/CDなどの自動化ツールの導入をおすすめします。GitLab のCI/CDパイプラインでDockerコンテナを使用することで、開発における一貫性の維持、スケーラビリティの実現、柔軟な環境の準備が可能になります。\n\n## FAQ（よくある質問）\n\n### Dockerで何ができるのか？\n\nDockerコンテナは、軽量でスタンドアロンの仮想化技術であり、アプリケーションコード、その依存関係、ライブラリをすべてパッケージ化します。Dockerを使うと、1台のマシン上に複数のコンテナ（仮想環境）を構築でき、開発環境や検証環境の統一が図れます。詳しくは、記事の本文をご覧ください。\n\n### Dockerは何に使うのか？\n\nDockerは、デベロッパーがアプリケーションとその依存関係をシステムから切り離したいとき使用します。コンテナにはアプリケーションとその依存関係がまとめられており、軽量な実行環境を提供します。詳しくは、記事の本文をご覧ください。\n\n### Dockerコンテナとは何ですか？\n\nDockerイメージが実行時にコンテナになります。Dockerコンテナは、アプリケーションを実行するためのランタイム環境です。Dockerコンテナに関する詳細は、記事の本文をご覧ください。\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)*\n\n*（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","engineering","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750226168/pf5cwmvqq09v1pe0re66.jpg",[109,804,9,682,781,805,806,807],"cloud native","performance","security","tutorial",{"featured":91,"template":686,"slug":809},"what-is-docker","content:ja-jp:blog:what-is-docker.yml","What Is Docker","ja-jp/blog/what-is-docker.yml","ja-jp/blog/what-is-docker",{"_path":815,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":816,"content":822,"config":831,"_id":833,"_type":14,"title":834,"_source":16,"_file":835,"_stem":836,"_extension":19},"/ja-jp/blog/what-is-kubernetes",{"title":817,"description":818,"ogTitle":817,"ogDescription":818,"noIndex":6,"ogImage":819,"ogUrl":820,"ogSiteName":670,"ogType":671,"canonicalUrls":820,"schema":821},"Kubernetes（K8s）とは？その仕組みから利点、使い方まで","Kubernetes（K8s）とは？Kubernetes の読み方から覚えておきたい用語、仕組みやその利点について学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687485/Blog/Hero%20Images/kubernetes.jpg","https://about.gitlab.com/blog/what-is-kubernetes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes（K8s）とは？その仕組みから利点、使い方まで\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-28\",\n      }",{"title":817,"description":818,"authors":823,"heroImage":819,"date":825,"body":826,"category":801,"tags":827},[824,776],"GitLab Japan Team","2025-04-28","## 目次\n\n1. Kubernetesとは？その読み方と用途\n2. Kubernetes（K8s）の基本用語解説\n  - コンテナ、Pod、Node、クラスター\n  - Dockerとの違い\n3. Kubernetesの主な特徴\n  - デプロイの自動化\n  - ハイブリッド / マルチクラウドに対応\n  - 拡張性とプラグインアーキテクチャ\n  - ローリングアップデートとロールバック\n  - 柔軟なスケーラビリティ\n  - リリース後のアプリケーション監視\n4. Kubernetesの利点とは\n  - 生産性の向上\n  - 自己修復機能により障害に耐性\n  - 高い可用性を担保\n  - オンプレミスでも、クラウドでも運用可能\n  - 大量のコンテナを一括管理\n  - DevSecOpsとの親和性が高い\n  - クラウドネイティブなワークロードを安全に保つ\n5. GitLabでKubernetesを統合する\n6. Kubernetes（K8s）のよくある質問\n  - KubernetesとDockerの違いは何ですか？\n  - Kubernetesで何ができますか？\n  - Kubernetesコンテナとは何ですか？\n  - Kubernetesの読み方は？\n\n## Kubernetesとは？その読み方と用途\n\nKubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と発音します。ギリシャ語のκυβερνήτηςに由来し、「統治者」や「パイロット」といった意味を持ちます。また、K8sと表記されることもあります。  \n\nKubernetesは、一言で表せばソフトウェア開発においてコンテナを操作・管理するもので、コンテナオーケストレーションの役割を果たすオープンソースソフトウェアとして開発されました。Kubernetesは、クラウドネイティブのプログラムの開発に使用します。これを使用することで[マイクロサービス](https://about.gitlab.com/ja-jp/topics/microservices/)アーキテクチャが可能になり、プログラムの開発が高速化できます。  \nでは、Kubernetesについて、もう少し掘り下げて見ていきましょう。\n\n## Kubernetes（K8s）の基本用語解説\n\n### コンテナ、Pod、Node、クラスター\n\nKubernetesは、コンテナをオーケストレーションするためのツールです。オーケストレーションとは、複数のコンピュータシステムやアプリケーション、サービスなどを調整して管理し、頻繁に繰り返される大規模なワークフローやプロセスを実行できるようにすることを指します。では、コンテナとは何でしょう。ソフトウェア開発におけるコンテナ化とは、ソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することを意味します。コンテナは、完全に機能するポータブルなコンピューティング環境です。また、このコンテナを複数まとめたものがPod、PodをまとめたものがNode、Nodeをまとめたものがクラスタと呼ばれます（以下の図を参照）。\n\n![kubernetesとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687494/Blog/Content%20Images/kubernetes-diagram.svg)\n\n*Kubernetesにおけるコンテナとクラスタの関係を示した図*\n### Dockerとの違い\n\nKuberunetesはコンテナオーケストレーションツールですが、Dockerはコンテナ化ツールの1つです。Dockerはアプリケーションのコンテナ化を行なうとき使用するプラットフォームです。仮想マシンよりも軽量で高速であることや、環境構築が簡単なことから、コンテナ化の主流ツールになっています。\n\n## Kubernetesの主な特徴\n\nKubernetesは、前述したようにコンテナを管理するコンテナオーケストレーションツールで、代表的な機能としては次のようなものが挙げられます。\n\n### デプロイの自動化\n\nKubernetesは、アプリケーションのデプロイ時に、新しいコンテナの作成や既存コンテナの削除を自動で実施します。また、新しく作成したコンテナにも自動でリソースを適用します。\n\n### ハイブリッド / マルチクラウドに対応\n\nクラウドプロバイダーに依存することなく、オンプレミス環境や様々なクラウドサービス（AWS、Azureなど）上で動作します。よって、ハイブリッドクラウドやマルチクラウド環境を簡単に構築、管理することができます。\n\n### 拡張性とプラグインアーキテクチャ\n\n多様なプラグインや拡張機能が利用できます。例えば、CustomResourceDefinitions（CRD）を使って新規にリソースタイプやロジックを追加したり、CNI（Container Network Interface）やCSI（Container Storage Interface）といったプラグインでネットワークやストレージのカスタマイズが可能です。\n\n### ローリングアップデートとロールバック\n\nKubernetesでは、アプリケーションのバージョンを更新する際、ローリングアップデートがそのデフォルトとなります。また、ビルトインでロールバック機構もあります。このため、ライブトラフィックに影響を与えず、ダウンタイムゼロでデプロイを実現できます。\n\n### 柔軟なスケーラビリティ\n\nKubernetesは、大量のコンテナを効率的に管理するためのもので、システムのスケーラビリティが向上できます。スケーラビリティとは、どのくらいシステムの拡張ができるかを示す特性で、Kubernetesではコンテナ化されたアプリケーションの数を増減することでスケーリングします。\n\n### リリース後のアプリケーション監視\n\nPrometheusやGrafanaといった監視ツールを使用することで、アプリケーション固有のメトリクスが監視できます。リリース後のパフォーマンス低下や不具合発見といった事象がアラートされるため、問題に迅速に対処できます。\n\n## Kubernetesの利点とは\n\nKubernetesには次のような7つのメリットがあります。\n\n### 生産性の向上\n\n一つ目のメリットは、アプリケーション開発で生産性が向上できる点にあります。従来の仮想化では、アプリケーションごとにゲストOSを用意する必要がありましたが、Kubernetesでは、アプリケーションを直接コンテナエンジン上にデプロイできるため、サーバーのリソース使用量が抑えられます。\n\n### 自己修復機能により障害に耐性\n\nKubernetesには、PodやNodeに障害が起きた場合、最初の定義（マニフェスト）の状態まで自動修復する機能が備わっています。\n\n### 高い可用性を担保\n\nKubernetesは、複数のNodeの集まりであるクラスターを構成します。あるクラスターで障害が発生した場合、障害が起きたコンテナを自動で再起動させます。また、他のNodeでコンテナを起動させ、処理を引き継ぐ動作も継続できるため、高い可用性が担保できます。\n\n### オンプレミスでも、クラウドでも運用可能\n\nKubernetesは、オンプレミスでも、プライベートクラウド、パブリッククラウドでも利用できます。つまり、自社サーバーでも、クラウドを使っても、どんな環境でも運用可能です。\n\n### 大量のコンテナの一括管理\n\nKubernetesでは、大量のコンテナが一括で管理・運用できます。また、設定ファイルを複数のコンテナ間で共有することによって、設定変更時も正確かつ大量に設定を反映させることが可能です。\n\n### DevSecOpsとの親和性が高い\nDevSecOpsとは、開発と運用を統合するDevOpsにセキュリティを加え、運用を視野に入れながら開発とセキュリティを同時に進め、安心・安全なソフトウェアを迅速にリリースするというコンセプトです。Kubernetesにはアプリケーションの開発と運用の双方に必要とされる機能が多く搭載されているため、DevSecOpsとの親和性が非常に高いという特長があります。\n\n### クラウドネイティブなワークロードを安全に保つ\n\nKubernetesは、クラウドネイティブアーキテクチャに基づいており、クラウドネイティブな情報セキュリティに関するベストプラクティスについて、CNCF（Cloud Native Computing Foundation）からのアドバイスを活用しています。\n\nたとえばKubernetesには、APIやセキュリティコントロールが含まれており、情報セキュリティを管理するポリシーを定義する手段も備わっています。クラウドの利用などでセキュリティ面において懸念が生じても、Kubernetesならユーザーごとにアクセス制限を設定でき、不正アクセスが防止できるため安心です。\n\nまた、Pod Security Standardによりセキュリティに3つのポリシーが定義されています。非常に緩いものから非常に厳しいものまで累積的に定義できます。\n\n## GitLabでKubernetesを統合する\n\nKubernetesクラスターとGitLabを接続すると、アプリの開発・デプロイ・管理・監視ができます。  \nGitLabをKubernetesと連携させる、またはKubernetes内で動作させるには、3つの異なる方法があります。単独で使用することも、組み合わせて使用することもできます。\n\n* GitLabからKubernetesにソフトウェアをデプロイする  \n* Kubernetesを使用してGitLabインスタンスに紐づいたRunnerを管理する  \n* GitLabのアプリケーションとサービスをKubernetesクラスター上で実行する\n\nさらに詳しい情報やお問い合わせは[こちら](https://about.gitlab.com/ja-jp/solutions/kubernetes/)をご覧ください。\n\n## Kubernetes （K8s）のよくある質問\n\n### KubernetesとDockerの違いは何ですか？\n\nDockerはコンテナ化ツールのひとつで、アプリケーションコンテナを構築し、アプリケーションの開発・配布・実行をします。Kubernetesは、より大規模に複数のマイクロサービスを管理するのに使われます。  \nまた、Kubernetesはクラスターで実行され、Dockerはノードで実行されます。Kubernetesの使用目的はコンテナ管理ですが、Dockerの使用目的の一つは、アプリケーションをコンテナに分離することになります。\n\n### Kubernetesで何ができますか？\n\nKubernetesでできることの代表例には下記のようなものが挙げられます。\n\n* 大量のコンテナの一括管理\n* 起動を含めた動作の高速化・軽量化  \n* 自動デプロイ  \n* 自己修復機能により障害に耐性\n* 高い可用性を担保\n* オンプレミスでも、クラウドでも運用可能\n* DevSecOpsとの親和性が高い\n* クラウドネイティブなワークロードを安全に保つ\n\n### Kubernetesコンテナとは何ですか？\n\nソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することをコンテナ化と言います。Kubernetesコンテナは、完全に機能するポータブルなコンピューティング環境で、さまざまなプラットフォームでデプロイ可能なプログラムとして[マイクロサービス](https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture/)アーキテクチャを可能にします（リンクは英語版です）。\n\n### Kubernetesの読み方は？\n\nKubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と読み、「K8s（ケーエイツ）」と略されます。\n",[828,804,9,109,532,829,806,805,830],"kubernetes","open source","workflow",{"slug":832,"featured":91,"template":686},"what-is-kubernetes","content:ja-jp:blog:what-is-kubernetes.yml","What Is Kubernetes","ja-jp/blog/what-is-kubernetes.yml","ja-jp/blog/what-is-kubernetes",{"_path":838,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":839,"content":844,"config":851,"_id":853,"_type":14,"title":854,"_source":16,"_file":855,"_stem":856,"_extension":19},"/ja-jp/blog/what-is-platform-engineering",{"config":840,"ogImage":841,"title":842,"description":843},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508254/duu6d4vclamtnnxjdaat.jpg","プラットフォームエンジニアリングとは？意味や導入メリットをわかりやすく解説","この記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。具体的な導入ステップや基盤構築に役立つおすすめのプラットフォームも。",{"category":801,"body":845,"date":846,"authors":847,"heroImage":841,"title":842,"description":848,"tags":849},"近年ソフトウェア開発の領域では「プラットフォームエンジニアリング」と呼ばれる開発者の生産性向上に寄与するアプローチが注目されています。\n\n実際にプラットフォームエンジニアリングに興味はあるものの、意味や定義などを詳しく理解していない人も多いのではないでしょうか。\n\nこの記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。具体的な導入ステップや基盤構築に役立つおすすめのプラットフォームも紹介するのでぜひ参考にして下さい。\n\n## 1. プラットフォームエンジニアリングとは？\n\n![プラットフォームエンジニアリングとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508139/eui82g7mlcb2fr5vavir.jpg)\n\nまずはプラットフォームエンジニアリングの意味や特徴について解説します。\n\n### 1-1. プラットフォームエンジニアリングの意味・特徴\n\nプラットフォームエンジニアリングとは、企業内の開発者に対して適切なプラットフォーム（IDP）を整備し、ソフトウェア開発の効率化や生産性向上を実現するアプローチのことです。\n\n近年はIT技術の発展や消費者ニーズの多様化などを背景として将来の予測が難しい時代（VUCA時代）だと言われています。プラットフォームエンジニアリングは、VUCA時代において複雑化するビジネスニーズに対応するための新しいエンジニアリング手法として、ガートナー社が積極的に提案しているアプローチでもあります。\n\n### 1-2. IDP（内部開発者向けプラットフォーム）とは\n\nInternal Developer Platform（内部開発者向けプラットフォーム、以下IDP）とは、企業内の開発者が開発プロセスにおいて必要な機能やリソースを自ら取得して利用できるプラットフォームを指し、プラットフォームエンジニアリングの導入における重要な技術基盤に当たります。\n\nIDPを通してチームで共通して利用できるツールやリソースを開発者に提供することで、迅速なソフトウェアの構築やデプロイを実現できます。\n\nIDPの構築においては、自社の課題や目的に応じてさまざまなツールや技術を組み合わせて行いますが、[GitLab](https://about.gitlab.com/ja-jp/)のように単一のプラットフォームで開発プロセスにおける多くの作業を効率化できるサービスもあります。\n\n## 2. プラットフォームエンジニアリングが注目されている背景\n\n![プラットフォームエンジニアリングが注目されている背景](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/hvzgimgumavwq5mmfqlx.jpg)\n\nソフトウェア開発の領域でなぜプラットフォームエンジニアリングが注目されているのでしょうか。具体的な背景としては以下が挙げられます。\n\n* 開発環境の複雑化  \n* ビジネス環境の激化  \n* IT人材の不足\n\n### 2-1. 開発環境の複雑化\n\nプラットフォームエンジニアリングの必要性が高まっている背景の一つとしてまず挙げられるのが、開発環境の複雑化による開発者の認知負荷の増大にあります。\n\nソフトウェア開発における開発手法や技術は年々進化・発展し続けており、クラウドや生成AI、マイクロサービス、APIなどさまざまな技術が広く使われるようになっています。これらの技術活用によって柔軟なソフトウェア開発を実現できますが、その一方で管理すべきツールの種類が増え、かつ多様な技術を身につけなければならないという課題が発生します。\n\nそれにより、開発者は重要な開発作業や取り組み以外に自身のリソースを割く必要があり、それが結果としてチーム全体の生産性低下も招くことになります。\n\nつまり、ソフトウェア開発において効果的に最新技術を取り入れていくためには、開発者が本質的な業務に集中できる環境を構築しなければなりません。\n\n### 2-2. ビジネス環境の激化\n\n先ほども少し触れていますが、近年は[VUCA時代](https://www.nri.com/jp/knowledge/glossary/vuca.html)と呼ばれる将来の予測が難しい不確実な要素が多い時代です。\n\n市場が常に変化する中で社会や消費者にとって必要とされる価値あるソフトウェアを開発して競合と差別化を図るためには、多様な技術を活用したスケーラブルな開発が求められます。\n\nまた、自社の競争力を高めていくためには、アジャイル開発のようなスピード感のある開発手法を積極的に採用していく考えも大切です。\n\n開発者がセルフサービスで利用できるプラットフォームの提供は、柔軟かつ迅速なソフトウェア開発を実現する手段として有効なアプローチだと言えます。\n\n[アジャイル開発とは？意味や進め方、DevSecOpsとの関係性を解説](https://about.gitlab.com/ja-jp/blog/what-is-agile-development/)\n\n### 2-3. IT人材の不足\n\nソフトウェア開発の領域では、慢性的な人手不足が課題となっています。クラウドやAIなど高度な最新技術が次々と登場する一方で、それらを扱える専門知識を持った人材が業界全体で不足しているのです。\n\n実際に「[IT人材需給に関する調査](https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf)」を見てみると、2030年には最大で約79万人のIT人材が不足すると予測されています。\n\n![IT人材需給に関する調査](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/zv15e7qpd6cppogiogat.png)\n\n※引用元：[IT人材需給に関する調査](https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf)\n\nこのような背景の中で適切にソフトウェア開発を進めていくためには、プラットフォームエンジニアリングの導入を通じて開発者の負担削減や生産性向上を実現し、自社のリソースを上手に活用していく姿勢や工夫が求められると言えます。\n\n## 3. プラットフォームエンジニアリングとDevSecOps・SREとの関係性とは\n\n![プラットフォームエンジニアリングとDevSecOps・SREとの関係性とは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508140/psg7uvfabu13r50vbwzc.jpg)\n\nプラットフォームエンジニアリングを理解する上では、DevSecOpsやSREとの違いについても把握しておくことが大切です。\n\n### 3-1. DevSecOpsとの違い\n\nDevSecOpsとは、開発（Dev）、セキュリティ（Sec）、運用（Ops）の3つの領域を連携させて開発を進めるアプローチを指します。開発と運用を連携してリリースサイクルを短縮させる従来の「DevOps」の考え方に対して、セキュリティ（Sec）のプロセスも加えることでソフトウェアの安全性を確保しつつ、迅速なリリースが可能になります。\n\n一方、プラットフォームエンジニアリングはDevSecOpのようなワークフローを実現する上で土台となるプラットフォームを社内で整備する取り組みです。\n\nつまり、プラットフォームエンジニアリングとDevSecOpsは親和性が高く、プラットフォームエンジニアリングはDevSecOpsをサポートする役割を担っていると言えます。\n\n### 3-2. SREとの違い\n\nSREとは、「Site Reliability Engineering」の略語で直訳すると、「サイト信頼性エンジニアリング」になります。Google社によって提唱された概念であり、運用プロセスにおいて手間のかかるタスクを自動化してシステムの安定稼働を実現しつつ、新機能の追加や更新などを通してユーザー体験（UX）の向上を目指す取り組みを指します。\n\nプラットフォームエンジニアリングとSREは、いずれも開発と運用における効率性・信頼性向上に関わるものですが、それぞれ目的や焦点が異なります。\n\nプラットフォームエンジニアリングは、社内の開発者の生産性向上や利便性向上を目的としたアプローチであり、SREは主にシステムの信頼性と可用性、スケーラビリティの向上に焦点を当てた考え方になります。\n\n## 4. プラットフォームエンジニアリングの導入目的とメリット\n\n![プラットフォームエンジニアリングの導入目的とメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508134/m2jqfbt1sfjpjqh3dbih.jpg)\n\nプラットフォームエンジニアリングの導入目的やメリットは以下の通りです。\n\n* 開発プロセスの効率化  \n* 開発者の生産性向上  \n* プロダクトの品質向上  \n* セキュリティ・ガバナンスの維持と強化  \n* 人材不足の解消  \n* 新しいイノベーションの創出  \n* コスト削減\n\n### 4-1. 開発プロセスの効率化\n\nまずプラットフォームエンジニアリングの導入は、開発プロセスの効率化につなげられます。\n\nIDPにより開発者は開発に必要なリソースを必要な時に素早く取得して利用できるため、環境構築に手間と時間をかけることなく本質的な開発業務に集中することが可能です。\n\nアジャイル開発やDevSecOpsの手法を活用する際に、積極的にプラットフォームエンジニアリングの考え方も採用すれば、プロダクトや機能のリリース頻度・スピードが向上し、自社ビジネスの加速化に貢献できるでしょう。\n\n### 4-2. 開発者の生産性向上\n\nプラットフォームエンジニアリングでIDPを整備することで、チームで再利用可能なツールと機能を開発者に提供できるようになります。この仕組みにより、開発者それぞれで多数のツールを管理・運用する手間がなくなり、認知的負荷の軽減につなげられるでしょう。\n\nその結果、戦略立案や分析、新機能開発などより重要な業務にリソースを割けるようになり、生産性の最大化を図れるでしょう。\n\n### 4-3. プロダクトの品質向上\n\n顧客が満足するプロダクトを提供するためには、品質も担保しなければなりません。IDPに対してテストやレビュー、セキュリティスキャン、デプロイなどを自動化する仕組みを整備すれば、ヒューマンエラーの防止につなげられます。\n\nプラットフォームエンジニアリングの導入でテストやレビューなどを標準化することによって、開発者やプロジェクトごとの品質のバラつきを防止でき、自社で定義されたプラットフォームの基準に沿って開発と運用を進められます。\n\nつまり、プラットフォームエンジニアリングの導入は、開発効率や生産性の向上だけでなく、プロダクト品質や信頼性の向上にも寄与します。\n\n### 4-4. セキュリティ・ガバナンスの維持と強化\n\nプラットフォームエンジニアリングで自社に必要なセキュリティやガバナンスを定義し、それらを自社のプラットフォーム上に反映させて運用することも可能です。\n\n権限設定や監査ログ、セキュリティポリシー、脆弱性対応などをプラットフォーム上で集約して一元化することで管理や証跡の収集が容易になり、組織全体におけるセキュリティ・ガバナンスの維持と強化につなげられるでしょう。\n\nまた、標準化されたプラットフォームの整備によって、開発者の心理的な負担を軽減して安全に開発を進められます。\n\n### 4-5. 人材不足の解消\n\nプラットフォームエンジニアリングの導入は、開発プロセスの効率化や開発者の生産性向上に寄与するため、企業のリソースを最大限に活かしながらソフトウェア開発を進められます。\n\nまた、開発者のニーズにマッチしたプラットフォームを提供して働きやすい環境を構築することで、開発者体験（Developer Experience）の向上も実現できます。その結果、自社に対する開発者や求職者からのイメージも良くなり、優秀なエンジニアの獲得と定着を図れるでしょう。\n\n### 4-6. 新しいイノベーションの創出\n\n近年ソフトウェア開発の効率化や価値向上に役立つさまざまな最新技術が登場しています。しかし、複数の技術やツールを開発者個人で活用するには管理の負担が増えてしまい、実際の活用にはハードルが高いと言えます。\n\nプラットフォームエンジニアリングならさまざまな機能やツールが搭載されたプラットフォームをチームで利用できるため、開発者全員が最新技術に触れやすくなります。それをきっかけとして自社で新しいアイデアやイノベーションが生まれたり、より品質の高いプロダクトをリリースできたりする可能性が高まるでしょう。\n\n### 4-7. コスト削減\n\nプラットフォームエンジニアリングを取り入れることで、ツールや環境の共通化によるコスト削減にもつながります。例えば、ソフトウェア開発のプロセスにおいて複数のツールを活用している企業が、[GitLab](https://about.gitlab.com/ja-jp/)のようなさまざまなツールを単一のプラットフォームで利用できるサービスを導入すれば、ライセンス費用や管理コストの削減につなげられるでしょう。\n\nまた、CI/CDやセキュリティチェックなどをプラットフォーム上で自動化することで運用コストの削減も実現できます。\n\nワークフローの自動化や標準化により開発スピードが向上すれば、限られたリソースを効果的に活用できるため、長期的な人件費の最適化にもつながります。\n\n## 5. プラットフォームエンジニアリングの導入ステップ\n\n![プラットフォームエンジニアリングの導入ステップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/cep3gdqsqca4gb0ckt2w.jpg)\n\nここでは実際にプラットフォームエンジニアリングを導入する際の手順について見ていきましょう。\n\n1. 専門チームの組成  \n2. 開発課題の分析と目標設定  \n3. プラットフォームの構築・組織体制の変更  \n4. フィードバック・継続的なメンテナンス\n\n### 5-1. 専門チームの組成\n\nプラットフォームエンジニアリングを導入する際には、まず専門チームの組成から始めます。専門チームを社内に配置すれば、プラットフォームエンジニアリング導入の取り組みを推進できます。専門チームの主な役割としては以下が挙げられます。\n\n* 開発者のニーズ調査  \n* プラットフォームの設計・構築  \n* 社内でのプラットフォーム活用の浸透の実現  \n* プラットフォームの運用・定期的な改善 など\n\n実際のメンバー構成においては、開発者のさまざまなニーズを考慮したプラットフォームを導入するためにも、開発・運用・セキュリティなど多様なスキルセットを持つ人材や、それぞれの分野を専門とする人材を集めることがポイントです。\n\nまた、社内向けではあるものの、自社での活用を浸透させるためにはプラットフォームを一つのサービスとして捉え、ユーザーニーズを満たすという視点が重要になります。\n\n### 5-2. 開発課題の分析と目標設定\n\nプラットフォームエンジニアリングの専門チーム結成後は、現状の開発課題の把握と分析を実施します。課題の把握や分析においては、エンジニアとの個別面談やサーベイなどを通して行います。\n\nその中で、「複数のツールを管理するための負担がかかり過ぎている」「開発環境の構築から実際のリリースまで時間がかかっており、開発効率が悪い」などの課題が挙げられたなら、それらの課題を解決するためにどのようなプラットフォームを導入すれば良いのかを検討し、具体的な目標を設定します。\n\n例えば、開発者のツール管理の負担が主な課題としてあるなら、単一のプラットフォームで複数のツールや技術を活用できるIDPを整備するという方向性を定められるでしょう。\n\n### 5-3. プラットフォームの構築・組織体制の変更\n\nプラットフォームエンジニアリングの導入における目標や方向性が明確になった後は、実際に基盤となるプラットフォームの構築を行います。\n\n開発プロセスの課題解決につながるような機能やツールを搭載し、さまざまな手法で開発を進められるよう整備していきます。\n\nまた、プラットフォームを構築して実際に活用していく際には、これまでの開発プロセスに変化が生じるため、必要に応じて開発者間での認識の擦り合わせや組織体制の変更を行いましょう。\n\n### 5-4. フィードバック・継続的なメンテナンス\n\nプラットフォームエンジニアリングの基盤構築後は、実際にプラットフォームを運用し開発者に活用してもらいます。その中で開発者からフィードバックや要望があれば、機能追加や改善を柔軟に行っていきます。\n\nソフトウェア開発におけるツールや技術は進化し続けており、トレンドも常に移り変わるため、最新情報のキャッチアップや定期的なメンテナンスがプラットフォームエンジニアリングを成功させるための鍵となります。\n\n## 6. プラットフォームエンジニアリングの導入における注意点\n\n![プラットフォームエンジニアリングの導入における注意点](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/ew7szhpm1mnheubghlnk.jpg)\n\nプラットフォームエンジニアリングの導入においては以下のような注意点もあります。\n\n* プラットフォーム構築を目的としない  \n* 導入に効果が期待できるか見極める  \n* トップダウンでの導入は避ける  \n* 段階的に導入して小さく始める\n\n### 6-1. プラットフォーム構築を目的としない\n\nまずプラットフォームエンジニアリングの導入において、プラットフォーム構築そのものを目的として進めてしまうと失敗してしまう可能性が高まります。\n\n例えば、「最新技術だから」「高機能だから」というような考えだけで導入してしまうと、開発者ニーズにマッチしないプラットフォームを構築してしまうことになります。そうなると、社内での活用も浸透せず、誰にも使われないという結果を招いてしまうでしょう。\n\nそのため、開発者への調査を徹底して行い、どんな課題を解決したいのかを明確にした上でプラットフォームを構築する必要があります。\n\n### 6-2. 導入に効果が期待できるか見極める\n\nプラットフォームエンジニアリングの導入そのものが、実際に自社にとって効果が期待できるのかも見極めなければなりません。\n\n例えば、エンタープライズや中規模など大きめ組織で、かつ必要な人材が揃っているなら、専門チームの組成もスムーズに進み、実際のプラットフォーム構築によって開発の効率化やコスト削減などの効果が期待できる可能性が高いと言えます。\n\n一方、小規模な組織の場合で、かつ人手が足りない場合プラットフォーム構築や運用そのものに大きな負担がかかってしまい、逆効果になる可能性もあります。\n\nそのため、「プラットフォームエンジニアリングの導入や運用が自社で可能なのか」「実際にどのような効果が期待できるのか」をきちんと検討することが大切です。\n\n### 6-3. トップダウンでの導入は避ける\n\nプラットフォームエンジニアリングは開発者向けのアプローチであり、開発者がプラットフォームを問題なくセルフサービスで利用できるという要素が重要になります。\n\nそのため、トップダウンで現場の課題や開発者のニーズを無視して導入を進めてしまうと、新しいやり方に対して開発者から抵抗や反発を受ける可能性があります。\n\nスムーズな導入を実現するためには、経営層と開発者で双方向コミュニケーションをとり、開発者に選択の余地とアイデアを積極的に発信できる場を与える必要があります。\n\n### 6-4. 段階的に導入して小さく始める\n\n最初から全ての要件を満たした完璧なプラットフォームを構築して、運用しようとすると開発者が変化に対応しきれない可能性があります。また、時間をかけてプラットフォームを構築しているとトレンドに乗り遅れ、完成後には搭載した技術やツールが既に古いものになってしまっていたというケースも考えられます。\n\nそのため、まずは優先度の高い課題にフォーカスして、効果が期待できる機能から実装し段階的に運用するなど、アジャイル的な進め方がプラットフォームエンジニアリングの導入に求められると言えます。\n\n## 7. プラットフォームエンジニアリングの基盤構築に役立つツール・サービスの選び方\n\n![プラットフォームエンジニアリングの基盤構築に役立つツール・サービスの選び方](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508136/bdq3zpkcrz1ez00md2yr.jpg)\n\nプラットフォームエンジニアリングの導入においては、基盤構築に役立つサービスを積極的に活用すると効率的です。ここでは具体的な選び方を解説します。\n\n* 機能  \n* コスト  \n* サポート体制\n\n### 7-1. 機能\n\nプラットフォームエンジニアリングの導入を成功させるためには、開発者のニーズを満たし、かつ自社の課題を解決できる機能が搭載されたサービスを選ぶことが大切です。\n\n例えば、プラットフォームを構成する重要な要素として挙げられる機能は以下の通りです。\n\n* CI/CD（自動ビルド・テスト・デプロイ）  \n* ソースコード管理  \n* ドキュメント  \n* モニタリング  \n* API連携  \n* セキュリティ・ガバナンス など\n\nこのような機能が搭載されているサービスなら、開発者の生産性向上に貢献できるでしょう。\n\n### 7-2. コスト\n\nプラットフォームエンジニアリングの基盤構築となるサービスを選定する際には、コスト面も考慮することが大切です。\n\n組織の規模や導入形態などによってもコストが異なるため、ベンダーに問い合わせするなどして費用対効果が期待できるかしっかりチェックしておきましょう。\n\n無料トライアルを設けているサービスも多いため、まずは使用感を試してみてから導入を検討するのも良いでしょう。\n\n### 7-3. サポート体制\n\nプラットフォームエンジニアリングをスムーズに導入・運用していくためには、ツールやサービスを提供するベンダーのサポート体制をチェックしておく必要もあります。\n\n充実したサポート体制があれば、万が一トラブルや不明点が発生した場合でも、専任スタッフが迅速に対応してくれるでしょう。また、ベンダーがドキュメントやマニュアルなどを通して積極的にノウハウを公開していれば、トラブル時にも自社で解決しやすくなるでしょう。\n\n## 8. プラットフォームエンジニアリングの基盤構築なら「GitLab」\n\n![プラットフォームエンジニアリングの基盤構築なら「GitLab」](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508135/hy8mmygwnbm0ws0ejtik.png)\n\nプラットフォームエンジニアリングの基盤構築をスムーズに実現するなら「[GitLab](https://about.gitlab.com/ja-jp/)」の活用がおすすめです。ここでは、GitLabのサービス概要や強みについて紹介します。\n\n### 8-1. GitLabとは\n\nGitLabは、DevSecOpsワークフローを支援するAIを搭載したプラットフォームです。AIによるソースコード管理やセキュリティ対策、CI/CD、コンプライアンス管理など豊富な機能を単一のプラットフォームで活用でき、プラットフォームエンジニアリングの基盤構築に役立てられます。\n\n中小企業からエンタープライズまで多くの企業で導入されているプラットフォームで、高品質かつ迅速なソフトウェア開発を実現できます。\n\n### 8-2. GitLabが選ばれる理由\n\nGitLabの強みは、DevSecOpsツールチェーンの構築を単一のプラットフォームで実現できることです。これまで複数のツールを管理していた企業がGitLabを導入すれば、コスト削減や開発者の認知負荷の軽減につなげられ、プラットフォームエンジニアリングの運用をスムーズに行えるようになります。\n\nチーム全員で単一のプラットフォームを通して作業することで、メンバー間の連携や情報共有も容易に実施できます。また、サポート体制も充実しているため、導入と運用においても安心して進められるのも強みの一つです。\n\nGitLabを通してプラットフォームエンジニアリングを実現すれば、ソフトウェア開発のライフサイクル全体を効率化でき、競合との差別化につながる機能開発など本質的な作業に集中できるようになるでしょう。\n\n## 9. GitLabによるプラットフォームエンジニアリング実現のアプローチと活用例\n\n![GitLabによるプラットフォームエンジニアリング実現のアプローチと活用例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508136/gn4zixnirbsgrk1anwi8.jpg)\n\n実際にGitLabによるプラットフォームエンジニアリング実現のアプローチと活用例を紹介します。\n\n* 再利用可能なCI/CDコンポーネント  \n* セキュリティとコンプライアンス  \n* データ活用と分析  \n* コミュニケーションの効率化\n\n### 9-1. 再利用可能なCI/CDコンポーネント\n\nCI/CDコンポーネントは、再利用可能な単一のパイプライン構成ユニットのことで、この機能を使用すればCI/CDパイプラインの設定が容易になります。\n\nまた、再利用可能なCI/CDコンポーネントをリスト化して、各コンポーネントの情報を確認できる「[CI/CDカタログ](https://gitlab.com/explore/catalog)」も提供しています。コンポーネントが一元管理されているため、必要なものを必要な時に見つけ出して再利用できる仕様となっています。\n\nこれにより、開発者の作業効率向上や、組織全体でのスムーズなナレッジ共有を実現できるでしょう。\n\nCI/CDコンポーネントの詳細については以下のページをご覧下さい。\n\n[GitLab入門：CI/CDについて理解する](https://about.gitlab.com/ja-jp/blog/getting-started-with-gitlab-understanding-ci-cd/)\n\n### 9-2. セキュリティとコンプライアンス\n\nGitLabでは、ソフトウェア開発ライフサイクルの全てのステージに対応したセキュリティやコンプライアンス機能を搭載しています。\n\n開発を進める中で、セキュリティリスクなどの問題を早期に発見して対応できるため、トラブル発生時の対応コストを抑えたり、事態の深刻化を未然に防止したりすることが可能です。\n\n### 9-3. データ活用と分析\n\nGitLabでは、データ活用と分析による開発の効率性向上も実現できます。プロジェクトの運用状況などソフトウェア開発ライフサイクルにおけるさまざまなデータが一元管理されている仕組みとなっているため、関係者全員がスムーズに必要な情報にアクセスできます。\n\nまた、 プラットフォームに蓄積された主要なメトリクスを追跡して問題点を詳細に分析することで、迅速な改善や顧客価値の向上につなげられます。GitLabでは、DevOpsのパフォーマンスや健全性を示す[DORAメトリクス](https://docs.gitlab.com/user/analytics/dora_metrics/)の可視化・分析機能などを提供しています。\n\n### 9-4. コミュニケーションの効率化\n\nGitLabは統合型プラットフォームであり、全員が同じツールにアクセスして利用できるようになるため、開発者間でのコミュニケーションが効率化されます。\n\n誰もがアクセスしやすい共同ドキュメントの作成も可能であるため、別のツールに切り替えて作業する必要がなく、情報の共有や整理が容易になります。\n\nなお、プラットフォームエンジニアリングにおけるGitLab活用の詳細については以下のページをご覧下さい。\n\n> [プラットフォームエンジニアリングにおけるGitLabの活用](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)\n\n[](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)\n\n## まとめ： プラットフォームエンジニアリングの実現により開発品質の向上と効率化を図ろう\n\nプラットフォームエンジニアリングの導入は、ビジネス環境が激化している時代において重要視されているアプローチです。実際の導入においては、適切な専門チームの組成やツール・サービスの選定が大切なポイントとなってきます。\n\nプラットフォームエンジニアリングの基盤構築なら、ぜひ[GitLab](https://about.gitlab.com/ja-jp/)をご活用下さい。GitLabなら単一のプラットフォームで豊富な機能を利用できるため、開発者の認知負荷を軽減し、迅速かつ品質の高いソフトウェア開発を実現できます。\n\nなお、GitLabでは世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧下さい。\n\n> [2024グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-platform-engineering)\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)*\n\n*（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","2025-09-22",[798],"この記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。",[109,850,9,682,781,805,807,830],"collaboration",{"featured":6,"template":686,"slug":852},"what-is-platform-engineering","content:ja-jp:blog:what-is-platform-engineering.yml","What Is Platform Engineering","ja-jp/blog/what-is-platform-engineering.yml","ja-jp/blog/what-is-platform-engineering",{"_path":858,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":859,"content":865,"config":870,"_id":872,"_type":14,"title":873,"_source":16,"_file":874,"_stem":875,"_extension":19},"/ja-jp/blog/what-is-yaml",{"ogTitle":860,"schema":861,"ogImage":862,"ogDescription":863,"ogSiteName":670,"noIndex":6,"ogType":671,"ogUrl":864,"title":860,"canonicalUrls":864,"description":863},"拡張子YAMLファイルとは？基本から使い方まで徹底解説","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"拡張子YAMLファイルとは？基本から使い方まで徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662547/Blog/Hero%20Images/what_is_yaml.jpg","YAMLは構成ファイル紹介などに使用されるフォーマットです。この記事では、YAMLの基本からKubernetesなどでの具体的な使い方まで解説します。","https://about.gitlab.com/blog/what-is-yaml",{"title":860,"description":863,"authors":866,"heroImage":862,"date":867,"body":868,"category":801,"tags":869},[824,776],"2025-04-09","## 目次\n\n* YAMLとは？\n* YAMLを何に使う？\n* YAMLとYMLの違いとは？\n* YAMLとJSONの違い\n* YAMLとCUEの比較\n* YAMLのデータ構造と書き方（基本編） \n* GitLabでYAMLを使う\n* 実際にYAMLファイルを編集してみましょう\n* YAMLに関するFAQ\n\nYAMLは、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)ファイルやAnsibleプレイブックに使用されるデータシリアライゼーション・フォーマットです。この記事では、YAMLファイルの基本的な書き方や具体的な利用シーンについて詳しく解説します。\n\n## YAMLとは？\n\nYAMLは、人間がデータを簡潔かつ理解しやすく表現するよう設計されており、設定ファイルやデータ転送で頻繁に使用されるプログラミング言語です。階層的情報の整理に適し、Jsonやxmlの代替と利用されることがあります。\n\n## YAMLを何に使う？\n\nYAMLは可読性の高いこともあり、設定ファイルやプレイブックの記載に使われます。いくつか例を下記に記載しますので、参考にしてください。\n\n* 設定ファイルの記述  \n* ログファイル  \n* プロセス間でのメッセージのやり取り  \n* アプリケーション間でのデータ共有  \n* 構造化データの記述\n\n## YAMLとYMLの違いとは？\n\nどちらも同じ形式のファイルを指し、拡張子が「.yml」か「.yaml」という表記の違いだけです。ヤムルファイルであることを示す正式な拡張子は.yamlですが、一般的に拡張子（.txt, .zip, .exe, .png等）は3文字で記載されるので、この3文字ルールに合わせたのが.ymlとなっています。短く簡潔に書きたい開発者には「.yml」が選ばれることが多いです。\n\n## YAMLとJSON形式の違い\n\nJSON形式では中括弧を使って要件を定義していくのに対して、YAMLは、インデントで構造が明示されるので、可読性が高くなっています。下記サンプルを見比べてください。\\\nYAMLは、プログラマーにとっての使いやすさを重視していることがわかると思います。\n\nYAML：\\\n![yamlのキーとバリューの記載例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/yaml-coding-sample-01.png)\n\nJSON:\n\n![JSON形式のキーとバリューの記載例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/json-format-coding-sample-01.png)\n\n## YAMLとCUEの比較\n\nYAMLは、可読性が高くシンプルな構造を持つのに比べ、CUEは、スキーマとデータを統合するため、複雑な設定もひとつのファイルで管理できます。また、YAML単体では実現できなかったスキーマバリデーション機能を持つので、データの整合性を担保しやすいです。\n\nまた、柔軟性も大きな特徴です。CUEは、あらゆる種類のデータを定義、生成、検証するために使用される[オープンソース](https://about.gitlab.com/ja-jp/blog/what-is-open-source/)の言語（具体的にはJSONのスーパーセット）なので、Go、JSON、OpenAPI、Protocol Buffers、YAMLなどの他の多くの言語と連携できます。\n\nまた、Go APIによるスクリプト機能を備えているので、CUEによるマニフェストを最終的な[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソースのYAMLとして表示したり、特定クラスタにデプロイするリソースを一覧するコマンドを実装する際などに使う機会があります。\n\n## YAMLのデータ構造と書き方（基本編）\n\n### YAMLファイル記述の注意点\n\nインデントとタブが、とても重要であることを覚えておいてください。余分なインデントやタブが使われていると、YAMLオブジェクトの意味が変わってしまうので、これらがとても重要になります。\n\n### YAMLのデータ構造\n\nYAMLは主に、コレクションとスカラーという２つのデータで成り立っています。コレクションは、シーケンスとマッピングから成り立ちます。シーケンスは配列、マッピングは名前と値のペア（Key : Valueで表現する配列）。そしてスカラーは、型を判別させるためのもので、文字列、数値などを表します。\n\n* コレクション  \n\n  * シーケンス  \n  * マッピング  \n* スカラー\n\n### YAMLの書き方\n\n![image2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/image2.png)\n\n* 複数行のコレクション：複数の行のフォーマットを維持する必要がある場合には | (バーティカルバー) シンボルを使用します。  \n* 複数行のフォーマット：長い文字列の値があり、フォーマットを維持したまま複数行に渡って記述する必要がある場合には、 > を使用します。  \n* リスト：リストは - （ハイフン）を使って表現します。  \n* ネスト：ネストされたデータ構造はインデントを使って表現されます。\n\n### Kubernetes（k8s)のYAMLファイルの書き方\n\nKubernetesでは、リソースの定義にYAMLファイルが使用されます。今回はYAMLマニフェストの書き方を紹介します。  \n\nYAMLマニフェスト：\\\n![YAMLでKubernetesのマニフェストの書き方例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/YAML-manufest-sample-Kubernetes.png)\n\n### AnsibleのYAMLファイルの書き方\n\nAnsibleでは、処理内容を記載するプレイブックをYAMLで記載します。以下に、簡単なAnsibleプレイブックの例を示します。\n\n![image3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687457/Blog/Content%20Images/image3.png)\n\n## GitLabでYAMLを使う\n\nGitLab CI/CD パイプラインは、プロジェクト毎に[.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/examples/index.html)というYAMLファイルを使って[パイプラインの構造と実行順序を定義](https://gitlab.com/stylez-co-jp/gitlab-ce/-/blob/dev-v12.0.3-ja.1/doc-ja/ci/yaml/README.md)します。このファイルで設定された内容を、GitLab Runnerの中で処理します。CI/CD YAML構文については[こちらの英文まとめページ](https://docs.gitlab.com/ee/ci/yaml/)をご参照ください。\n\n## 実際にYAMLファイルを編集してみましょう\n\nYAMLは、そのシンプルさと可読性の高さから、設定ファイル、CI/CDパイプライン、Kubernetesをはじめとするコンテナオーケストレーションやドキュメント、構成管理など、多岐にわたり利用されています。その可読性の高さで、開発者や運用エンジニアが構成やデータを容易に管理し、効率的に作業を進めることができます。YAMLを理解することで、様々なシステムやツールの設定がより簡単かつ直感的に行えるようになるでしょう。\n\n## YAMLに関するFAQ\n\n### YAMLは何に使われますか\n\nYAMLは、そのシンプルさと可読性の高さから、設定ファイル、CI/CDパイプライン、Kubernetesをはじめとするコンテナオーケストレーションやドキュメントと構成管理など、多岐にわたり利用されています。\n\n### YAMLとJSONの違いは？\n\nJSONファイルは中括弧を使って要件を定義していくのに対して、YAMLは、インデントで構造が明示されるので、可読性が高くなっています。ただし、YAMLではインデントやスペースがとても重要になる点に注意が必要です。\n\n### YAMLはなぜ人気なのですか？\n\nYAMLは開発者の間で人気のあるデータシリアライズ言語です。なぜなら、その読みやすさ、汎用性、Pythonと似たインデントシステムを使うからです。YAMLは複数のデータ型をサポートしており、多くのプログラミング言語で利用可能なパーサーライブラリが提供されているため、さまざまなデータシリアライゼーションタスクを扱うことができ、幅広い場面で活用されています。\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[9,828,682,109,532,804,807,830,829,758],{"slug":871,"featured":91,"template":686},"what-is-yaml","content:ja-jp:blog:what-is-yaml.yml","What Is Yaml","ja-jp/blog/what-is-yaml.yml","ja-jp/blog/what-is-yaml",1760103619509]