[{"data":1,"prerenderedAt":762},["ShallowReactive",2],{"/en-us/blog/tags/gitops/":3,"navigation-ja-jp":20,"banner-ja-jp":437,"footer-ja-jp":450,"GitOps-tag-page-ja-jp":658},{"_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/gitops","tags",false,"",{"tag":9,"tagSlug":10},"GitOps","gitops",{"template":12},"BlogTag","content:en-us:blog:tags:gitops.yml","yaml","Gitops","content","en-us/blog/tags/gitops.yml","en-us/blog/tags/gitops","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":433,"_type":14,"title":434,"_source":16,"_file":435,"_stem":436,"_extension":19},"/shared/ja-jp/main-navigation","ja-jp",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":411,"duo":424},{"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,188,193,299,359],{"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":170},"製品",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":28},"/ja-jp/solutions/",[99,125,148],{"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/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"ソフトウェアサプライチェーンの安全性",{"href":142,"dataGaLocation":28,"dataGaName":143},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"測定",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"可視性と測定",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"バリューストリーム管理",{"href":163,"dataGaLocation":28,"dataGaName":164},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"分析とインサイト",{"href":168,"dataGaLocation":28,"dataGaName":169},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLabが活躍する場所",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/ja-jp/enterprise/","enterprise",{"text":179,"config":180},"スモールビジネス",{"href":181,"dataGaLocation":28,"dataGaName":182},"/ja-jp/small-business/","small business",{"text":184,"config":185},"公共機関",{"href":186,"dataGaLocation":28,"dataGaName":187},"/ja-jp/solutions/public-sector/","public sector",{"text":189,"config":190},"価格",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/ja-jp/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"関連リソース",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"すべてのリソースを表示",{"href":200,"dataGaName":196,"dataGaLocation":28},"/ja-jp/resources/",[202,235,258],{"title":203,"items":204},"はじめに",[205,210,215,220,225,230],{"text":206,"config":207},"インストール",{"href":208,"dataGaName":209,"dataGaLocation":28},"/ja-jp/install/","install",{"text":211,"config":212},"クイックスタートガイド",{"href":213,"dataGaName":214,"dataGaLocation":28},"/ja-jp/get-started/","quick setup checklists",{"text":216,"config":217},"学ぶ",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"製品ドキュメント",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"ベストプラクティスビデオ",{"href":228,"dataGaName":229,"dataGaLocation":28},"/ja-jp/getting-started-videos/","best practice videos",{"text":231,"config":232},"インテグレーション",{"href":233,"dataGaName":234,"dataGaLocation":28},"/ja-jp/integrations/","integrations",{"title":236,"items":237},"検索する",[238,243,248,253],{"text":239,"config":240},"お客様成功事例",{"href":241,"dataGaName":242,"dataGaLocation":28},"/ja-jp/customers/","customer success stories",{"text":244,"config":245},"ブログ",{"href":246,"dataGaName":247,"dataGaLocation":28},"/ja-jp/blog/","blog",{"text":249,"config":250},"リモート",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/ja-jp/teamops/","teamops",{"title":259,"items":260},"つなげる",[261,266,271,276,281],{"text":262,"config":263},"GitLabサービス",{"href":264,"dataGaName":265,"dataGaLocation":28},"/ja-jp/services/","services",{"text":267,"config":268},"コミュニティ",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"フォーラム",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"イベント",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"パートナー",{"href":284,"dataGaName":285,"dataGaLocation":28},"/ja-jp/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":291,"config":292},"ソースプロモカード",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"最新情報を読む",{"href":297,"dataGaName":298,"dataGaLocation":28},"/ja-jp/the-source/","the source",{"text":300,"config":301,"lists":303},"Company",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"GitLabについて",{"href":309,"dataGaName":310,"dataGaLocation":28},"/ja-jp/company/","about",{"text":312,"config":313,"footerGa":316},"採用情報",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"経営陣",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"チーム",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"ハンドブック",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"投資家向け情報",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"トラストセンター",{"href":342,"dataGaName":343,"dataGaLocation":28},"/ja-jp/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":28},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"ニュースレター",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"プレス",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":35,"config":360,"lists":361},{"dataNavLevelOne":302},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"サポートを受ける",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"カスタマーポータル",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"閉じる",{"text":380,"link":381},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":382,"config":383},"GitLab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"提案",[389,392,397,399,403,407],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"コード提案（AI）",{"href":395,"dataGaName":396,"dataGaLocation":385},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":398},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":400,"config":401},"GitLab on AWS",{"href":402,"dataGaName":400,"dataGaLocation":385},"/ja-jp/partners/technology-partners/aws/",{"text":404,"config":405},"GitLab on Google Cloud",{"href":406,"dataGaName":404,"dataGaLocation":385},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":408,"config":409},"GitLabを選ぶ理由",{"href":70,"dataGaName":410,"dataGaLocation":385},"Why GitLab?",{"freeTrial":412,"mobileIcon":416,"desktopIcon":421},{"text":30,"config":413},{"href":414,"dataGaName":33,"dataGaLocation":415},"https://gitlab.com/-/trials/new/","nav",{"altText":417,"config":418},"GitLabアイコン",{"src":419,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":417,"config":422},{"src":423,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"GitLab Duoの詳細について",{"href":62,"dataGaName":428,"dataGaLocation":415},"gitlab duo",{"altText":417,"config":430},{"src":419,"dataGaName":420,"dataGaLocation":415},{"altText":417,"config":432},{"src":423,"dataGaName":420,"dataGaLocation":415},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":438,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":439,"button":440,"config":445,"_id":447,"_type":14,"_source":16,"_file":448,"_stem":449,"_extension":19},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":441,"config":442},"ベータ版を試す",{"href":443,"dataGaName":444,"dataGaLocation":28},"/ja-jp/gitlab-duo/agent-platform/","duo banner",{"layout":446},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":451,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":452,"_id":654,"_type":14,"title":655,"_source":16,"_file":656,"_stem":657,"_extension":19},"/shared/ja-jp/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":646},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":455,"config":456},"ページのソースを表示",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"このページを編集",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"ご協力をお願いします",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,551,584,618],{"title":46,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOpsプラットフォーム",{"href":55,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":189,"links":484},[485,489,494],{"text":486,"config":487},"プランの表示",{"href":191,"dataGaName":488,"dataGaLocation":459},"view plans",{"text":490,"config":491},"Premiumを選ぶ理由",{"href":492,"dataGaName":493,"dataGaLocation":459},"/ja-jp/pricing/premium/","why premium",{"text":495,"config":496},"Ultimateを選ぶ理由",{"href":497,"dataGaName":498,"dataGaLocation":459},"/ja-jp/pricing/ultimate/","why ultimate",{"title":500,"links":501},"ソリューション",[502,507,510,512,517,522,526,529,532,535,537,539,541,546],{"text":503,"config":504},"デジタルトランスフォーメーション",{"href":505,"dataGaName":506,"dataGaLocation":459},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":508,"config":509},"セキュリティとコンプライアンス",{"href":137,"dataGaName":138,"dataGaLocation":459},{"text":122,"config":511},{"href":105,"dataGaName":106,"dataGaLocation":459},{"text":513,"config":514},"アジャイル開発",{"href":515,"dataGaName":516,"dataGaLocation":459},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":518,"config":519},"クラウドトランスフォーメーション",{"href":520,"dataGaName":521,"dataGaLocation":459},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":523,"config":524},"SCM",{"href":119,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":109,"config":527},{"href":111,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":161,"config":530},{"href":163,"dataGaName":531,"dataGaLocation":459},"value stream management",{"text":9,"config":533},{"href":534,"dataGaName":10,"dataGaLocation":459},"/ja-jp/solutions/gitops/",{"text":174,"config":536},{"href":176,"dataGaName":177,"dataGaLocation":459},{"text":179,"config":538},{"href":181,"dataGaName":182,"dataGaLocation":459},{"text":184,"config":540},{"href":186,"dataGaName":187,"dataGaLocation":459},{"text":542,"config":543},"教育",{"href":544,"dataGaName":545,"dataGaLocation":459},"/ja-jp/solutions/education/","education",{"text":547,"config":548},"金融サービス",{"href":549,"dataGaName":550,"dataGaLocation":459},"/ja-jp/solutions/finance/","financial services",{"title":194,"links":552},[553,555,557,559,562,564,568,570,572,574,576,578,580,582],{"text":206,"config":554},{"href":208,"dataGaName":209,"dataGaLocation":459},{"text":211,"config":556},{"href":213,"dataGaName":214,"dataGaLocation":459},{"text":216,"config":558},{"href":218,"dataGaName":219,"dataGaLocation":459},{"text":221,"config":560},{"href":223,"dataGaName":561,"dataGaLocation":459},"docs",{"text":244,"config":563},{"href":246,"dataGaName":247},{"text":565,"config":566},"お客様の成功事例",{"href":567,"dataGaLocation":459},"/customers/",{"text":239,"config":569},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":249,"config":571},{"href":251,"dataGaName":252,"dataGaLocation":459},{"text":262,"config":573},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":254,"config":575},{"href":256,"dataGaName":257,"dataGaLocation":459},{"text":267,"config":577},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":579},{"href":274,"dataGaName":275,"dataGaLocation":459},{"text":277,"config":581},{"href":279,"dataGaName":280,"dataGaLocation":459},{"text":282,"config":583},{"href":284,"dataGaName":285,"dataGaLocation":459},{"title":300,"links":585},[586,588,590,592,594,596,598,602,607,609,611,613],{"text":307,"config":587},{"href":309,"dataGaName":302,"dataGaLocation":459},{"text":312,"config":589},{"href":314,"dataGaName":315,"dataGaLocation":459},{"text":320,"config":591},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":593},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":330,"config":595},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":335,"config":597},{"href":337,"dataGaName":338,"dataGaLocation":459},{"text":599,"config":600},"Sustainability",{"href":601,"dataGaName":599,"dataGaLocation":459},"/sustainability/",{"text":603,"config":604},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":605,"dataGaName":606,"dataGaLocation":459},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":608},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":350,"config":610},{"href":352,"dataGaName":353,"dataGaLocation":459},{"text":355,"config":612},{"href":357,"dataGaName":358,"dataGaLocation":459},{"text":614,"config":615},"現代奴隷制の透明性に関する声明",{"href":616,"dataGaName":617,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":619},[620,622,624,626,631,636,641],{"text":35,"config":621},{"href":37,"dataGaName":38,"dataGaLocation":459},{"text":368,"config":623},{"href":370,"dataGaName":371,"dataGaLocation":459},{"text":373,"config":625},{"href":375,"dataGaName":376,"dataGaLocation":459},{"text":627,"config":628},"ステータス",{"href":629,"dataGaName":630,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":632,"config":633},"利用規約",{"href":634,"dataGaName":635,"dataGaLocation":459},"/terms/","terms of use",{"text":637,"config":638},"プライバシーに関する声明",{"href":639,"dataGaName":640,"dataGaLocation":459},"/ja-jp/privacy/","privacy statement",{"text":642,"config":643},"Cookieの設定",{"dataGaName":644,"dataGaLocation":459,"id":645,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":459},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":459},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":459,"id":645,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"allPosts":659,"featuredPost":735,"totalPagesCount":760,"initialPosts":761},[660,688,715],{"_path":661,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":662,"content":670,"config":681,"_id":684,"_type":14,"title":685,"_source":16,"_file":686,"_stem":687,"_extension":19},"/ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":663,"description":664,"ogTitle":663,"ogDescription":664,"noIndex":6,"ogImage":665,"ogUrl":666,"ogSiteName":667,"ogType":668,"canonicalUrls":666,"schema":669},"継続的デリバリーにおける信頼できる情報源としてOCIイメージを活用する方法","GitOpsワークフローの一環としてOpen Container Initiative（OCI）イメージを活用する利点、およびKubernetesへのデプロイを簡素化するためにGitLabが提供する多くの機能について詳しくご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"継続的デリバリーにおける信頼できる情報源としてOCIイメージを活用する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":663,"description":664,"authors":671,"heroImage":665,"date":673,"body":674,"category":675,"tags":676},[672],"Daniel Helfand","2025-02-19","gitリポジトリをデプロイメントアーティファクトとして使用しない場合でも、それを[GitOps](https://about.gitlab.com/ja-jp/topics/gitops/)と呼ぶのは適切なのでしょうか？gitは依然としてGitOpsワークフローの中心的な要素ですが、近年では、インフラ定義をOpen\nContainer\nInitiative（OCI）アーティファクトとしてコンテナレジストリに保存し、それをGitOpsデプロイのソース（情報源）とする手法が広まりつつあります。この記事では、この傾向の背後にある考え方、およびGitLabの機能がどのようにGitOpsワークフローの進化を支えているのかについて詳しくご説明します。\n\n\n## GitOpsとは？\n\n\n[OpenGitOps](https://opengitops.dev/)プロジェクトでは、GitOpsの実践に関する以下の[4つの原則](https://opengitops.dev/#principles)を定義しています。\n\n-\n[GitOpsで管理されるシステム](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system)は、[望ましい状態が宣言的に表現](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description)されていること。\n\n- 望ましい状態は、不変性とバージョン管理が保証される形で保存され、完全なバージョン履歴が保持されていること。\n\n- ソフトウェアエージェントは、望ましい状態の宣言をソースから自動的にプルすること。\n\n-\nソフトウェアエージェントは、実際のシステム状態を[継続的](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous)に監視し、[望ましい状態の適用を試みる](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous)こと。\n\n\nGitOpsの一例として、マイクロサービスのKubernetesマニフェストをGitLabプロジェクトに保存することが挙げられます。これらのKubernetesリソースは、マイクロサービスがデプロイされたKubernetesクラスター上で実行されている[コントローラー](https://kubernetes.io/docs/concepts/architecture/controller/)によって継続的に調整されます。これにより、エンジニアは通常のコード作業と同じワークフローを使用してインフラを管理できます。たとえば、マージリクエストを作成し、変更を加えてレビューしたり、変更にバージョン管理を適用することができます。GitOpsは、[構成ドリフトを防ぐ](https://about.gitlab.com/topics/gitops/#cicd)といった運用上の利点もあり、エンジニアが特定の展開結果に至った変更を監査するのにも役立ちます。\n\n\n## GitOpsワークフローにおけるgitの利点と制限\n\n\ngitはGitOpsワークフローにおいて不可欠な要素ではありますが、もともとgitリポジトリはGitOpsコントローラによってデプロイされることを前提に設計されたものではありません。gitによってエンジニア同士が連携しながらインフラに変更を加えたり、その後変更を監査したりすることはできます。しかし、コントローラーが正常にデプロイを実行するために、gitリポジトリ全体をダウンロードする必要はありません。GitOpsコントローラーが必要とするのは、特定の環境のインフラ定義だけです。\n\n\nさらに、デプロイプロセスにおいて重要なのは、デプロイの変更が信頼できるソースから行われたものであることを確認するために、[デプロイに署名して検証](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing)することです。Gitのコミットは、GitOpsコントローラーによって署名・検証することが可能ですが、コミットはデプロイに関連しない他の詳細（ドキュメントの変更、他の環境の更新、Gitリポジトリの再構成など）を含むこともあります。また、1回のデプロイが複数のコミットにまたがる場合があるため、デプロイ全体が十分に反映しきれないこともあります。これもまた、このgit機能が設計されていないケースのように感じます。\n\n\nGitOpsワークフローにおけるgitのもう一つの課題は、想定以上に自動化が進んでしまう可能性があることです。監視しているブランチに変更をマージすると、すぐにデプロイされてしまいます。これは、gitの外側にプロセスを制御する仕組みがないためです。たとえば、金曜日の午後遅くにデプロイが行われないようにするにはどうすればよいでしょうか？あるいは、デプロイ担当のチームが特定のGitLabプロジェクトで変更をマージする権限を持っていない場合、どう対処すればよいのでしょうか？OCIイメージを使用することで、プロセスにパイプラインが追加され、[承認やデプロイの停止](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)といったデリバリー制御の機能を活用できるようになります。\n\n\n## OCIイメージ\n\n\n[Open Container\nInitiative](https://opencontainers.org/)は、コンテナ形式に関する標準を定義するために貢献してきました。多くのエンジニアは、Dockerfileを使用してコンテナイメージを作成することに慣れていますが、Kubernetesマニフェストをコンテナレジストリに保存することにはあまり馴染みがないかもしれません。[GitLabのコンテナレジストリ](https://docs.gitlab.com/ee/user/packages/container_registry/)はOCI準拠であるため、特定の環境向けのKubernetesマニフェストをコンテナレジストリにプッシュすることができます。これにより、[Flux\nCD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/)のようなGitOpsコントローラーは、gitリポジトリ全体をクローンすることなく、このOCIアーティファクトに保存されたマニフェストを利用してデプロイを実行できます。\n\n\nGitOpsワークフローでは、gitリポジトリにマイクロサービスがデプロイされるすべての環境のインフラ定義が含まれていることがよくあります。特定の環境向けのKubernetesマニフェストをパッケージ化することで、Flux\nCDはデプロイに必要な最小限のファイルだけをダウンロードして、特定の環境へのデプロイを実行できます。\n\n\n### OCIアーティファクトのセキュリティ上の利点\n\n\n前述のとおり、環境にデプロイされるアーティファクトに署名し、検証することで、ソフトウェアプロジェクトのセキュリティが一層強化されます。Kubernetesマニフェストがコンテナレジストリにプッシュされた後、[Sigstore\nCosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/)のようなツールを使用してOCIイメージに秘密鍵で署名できます。この秘密鍵は、GitLabプロジェクト内の[CI/CD変数](https://docs.gitlab.com/ee/ci/variables/)として安全に保存できます。その後、Flux\nCDはKubernetesクラスターに保存された公開鍵を使用して、デプロイが信頼できるソースから来ていることを確認できます。\n\n\n## GitLabを使ってOCIイメージをプッシュして署名する方法\n\n\nGitLabは、OCIイメージのパッケージ化、署名、デプロイのプロセスを簡素化する多くの機能を提供しています。GitOpsワークフローにおけるGitLabプロジェクト構成の一般的な方法は、各マイクロサービスのコード用に個別のGitLabプロジェクトを用意し、すべてのマイクロサービスに共通する単一のインフラリポジトリを持つというものです。アプリケーションが`n`個のマイクロサービスで構成されている場合、アプリケーションには`n\n+ 1`個のGitLabプロジェクトが必要になります。\n\n\nコードプロジェクトで作成されるアーティファクトは、通常、アプリケーションをパッケージ化するために使用されるコンテナイメージです。インフラプロジェクトまたはデリバリープロジェクトには、各マイクロサービスをスケールさせ、トラフィックを提供するために必要なリソースを定義したKubernetesマニフェストが含まれます。このプロジェクトで作成されるアーティファクトは通常、アプリケーションと他のマニフェストをKubernetesにデプロイするために使用されるOCIイメージです。\n\n\nこの構成では、環境の分離はKubernetesマニフェストを別々のフォルダに定義することで行われます。これらのフォルダは、アプリケーションをホストする環境（開発、ステージング、本番など）を表します。コードプロジェクトに変更が加えられ、新しいコンテナイメージがプッシュされた場合、その変更をGitLabのFlux\nCDとのインテグレーションを使ってデプロイするために必要なのは、環境フォルダ内のマニフェストを編集して新しいイメージ参照を追加し、マージリクエストを作成することだけです。マージリクエストのレビュー、承認、マージが実行されると、デリバリープロジェクトのCI/CDジョブが新しいOCIイメージをプッシュし、Flux\nCDがそれを受け取って新しい環境にデプロイします。\n\n\n![OCIイメージ -\nフローチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\n\nOCIイメージへの署名は、CosignをプロジェクトのCI/CDジョブに組み込むだけで簡単に行えます。以下のコマンドをローカルで実行することで、Cosignを使って新しい公開鍵と秘密鍵を生成できます。その際は、[glab\nCLI](https://gitlab.com/gitlab-org/cli/#installation)を使ってGitLabインスタンスにログインし、Cosignコマンド内の[`PROJECT_ID`]を[デリバリープロジェクトのID](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id)に置き換えてください。\n\n\n```\n\nglab auth login\n\ncosign generate-key-pair gitlab://[PROJECT_ID]\n\n```\n\n\ncosignコマンドが正常に実行されると、`COSIGN_PUBLIC_KEY`と`COSIGN_PRIVATE_KEY`という名前で、プロジェクトのCI/CD変数セクションにCosignキーが追加されていることが確認できます。\n\n\n### CI/CDジョブの例\n\n\nOCIイメージをプッシュするためのGitLab CI/CDジョブは、以下のような形になります。\n\n\n```yaml\n\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths: \n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\" \n```\n\n\n[GitLab\nCI/CDカタログ](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)には、GitLabが管理する[CI/CDコンポーネント（OCIアーティファクトおよびFlux\nCD向け）](https://gitlab.com/explore/catalog/components/fluxcd)が用意されています。このコンポーネントにより、開発チームはKubernetesマニフェストをOCIイメージとしてGitLabのコンテナレジストリや外部コンテナレジストリにプッシュし、Cosignを使用してOCIイメージに署名を行い、Flux\nCDを通じて新しくプッシュされたイメージをすぐに環境に同期することができます。 \n\n\n上記の例では、Flux CD\n`component`がGitLabプロジェクトの`.gitlab-ci.yml`ファイル内に含まれています。コンポーネントの入力パラメータを使って、ユーザーはイメージのプッシュ先レジストリ（すなわち`registry_image_url`と`image\ntag`）、プッシュ対象となるKubernetesマニフェストのファイルパス（すなわち`manifest_path`）、イメージの署名に使用するCosignの秘密鍵（すなわち`signing_private_key`）、そして環境への更新同期に必要なKubernetes名前空間とFlux\nCDの\n[OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/)名（すなわち`flux_oci_namespace_name`と`flux_oci_repo_name`）を定義できます。\n\n\n`kubernetes_agent_reference`を使用することで、各GitLabプロジェクトに`kubeconfig`\nCI/CD変数を個別に保存することなく、GitLab\nCI/CDジョブがKubernetesクラスターへアクセスするために必要な`kubeconfig`の権限を継承できるようになります。[Kubernetes向けGitLabエージェント](https://docs.gitlab.com/ee/user/clusters/agent/)をセットアップすることで、同じ[GitLabグループ](https://docs.gitlab.com/ee/user/group/)内のすべてのプロジェクトのCI/CDジョブに、Kubernetesクラスターへのデプロイ権限を継承させるように設定できます。\n\n\nKubernetesエージェントのコンテキストは、通常、GitLabグループ内でKubernetes向けGitLabエージェントを設定している場所で構成されます。この設定は、通常、Flux\nCDを管理しているプロジェクトで行うことが推奨されています。CI/CDアクセス向けのエージェント設定について詳しくは、[CI/CDワークフローのドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html)をご覧ください。\n\n\n`$COSIGN_PRIVATE_KEY`、`$FLUX_OCI_REPO_NAME`、`$FRONTEND_DEV_NAMESPACE`といった変数は、機密性の高い情報をCI/CDログ上でマスキングしつつ、簡単にアクセスできるようにするためにCI/CD変数として保存されています。`$CI_REGISTRY_IMAGE`は、GitLabジョブでデフォルトで利用可能な変数で、対象のGitLabプロジェクトのコンテナレジストリを示します。\n\n\n### OCIイメージのデプロイ\n\n\n[Flux\nCDをGitLabプロジェクトと組み合わせて使用する](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html)ことで、マイクロサービスの各環境へのデプロイと署名の検証を自動化できます。Flux\nCDをGitLabプロジェクトと連携するように設定したら、プッシュしたOCIイメージを同期するために、以下のKubernetesカスタムリソース定義\n[CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をプロジェクトに追加できます。\n\n\n```yaml\n\napiVersion: v1\n\nkind: Namespace\n\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\n\napiVersion: bitnami.com/v1alpha1\n\nkind: SealedSecret\n\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\n\napiVersion: source.toolkit.fluxcd.io/v1beta2\n\nkind: OCIRepository\n\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\n\napiVersion: kustomize.toolkit.fluxcd.io/v1\n\nkind: Kustomization\n\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n``` \n \n[`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/)リソースを使用することで、Kubernetesマニフェストをさらにカスタマイズできるほか、リソースをデプロイする対象のネームスペースも指定することができます。Flux\nCDの`OCIRepository`リソースでは、定期的に同期する対象となるOCIイメージのリポジトリ参照およびタグを指定できます。また、`verify.provider`と`verify.secretRef`というプロパティがあることに気づくでしょう。これらのフィールドを使うことで、クラスターにデプロイされるOCIイメージが、先ほどのCI/CDジョブで使用されたCosignの秘密鍵によって署名されたものであることを検証できます。\n\n\n公開鍵は、`OCIRepository`リソースと同じネームスペース内に格納する必要がある、[Kubernetesシークレット](https://kubernetes.io/docs/concepts/configuration/secret/)に保存しなければなりません。このシークレットをFlux\nCDによって管理し、平文で保存しないようにするには、値を暗号化してクラスター側のコントローラーで復号させるために、[SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/)の使用を検討しましょう。\n\n\nSealedSecretsを使わないより簡単な方法としては、[`kubectl\nCLI`](https://kubernetes.io/docs/reference/kubectl/)を使用して[GitLab\nCI/CDジョブでシークレットをデプロイする](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html)方法があります。SealedSecretを使用しない方法では、上記で使用していたSealedSecretを削除し、新しいOCIイメージをプッシュするジョブを実行する前に、公開鍵のシークレットをデプロイするジョブを実行するだけです。これにより、シークレットがGitLab上で安全に管理され、クラスター内でOCIRepositoryから正常にアクセスできるようになります。このアプローチは比較的シンプルですが、本番環境でのシークレット管理には適していないことにご留意ください。 \n\n\n## OCI、GitLab、およびGitOpsの利点\n\n\nOCIアーティファクトを活用することで、GitOpsチームはセキュリティ面での利点を得ながら、デプロイを最小限に抑えることができます。ユーザーは、インフラの信頼できる情報源としてgitを活用できる点や、プロジェクトでのコラボレーションが可能になる点など、gitがもたらすあらゆる利点を引き続き享受できます。OCIイメージは、GitOpsにおけるデプロイの側面を強化する新たなパッケージ化手法を提供します。\n\n\nGitLab\nは、GitOpsワークフローをよりシンプルにするための利用体験を提供できるよう、ユーザーやクラウドネイティブコミュニティから継続的に学び続けています。このブログでご紹介した機能をお使いになるには、[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/free-trial/)にお申込みください。これらのツールに関する皆さまのご利用体験についても、ぜひお聞かせください。フィードバックは[コミュニティフォーラム](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965)にて受け付けています。\n","open-source",[109,677,678,9,679,680],"open source","kubernetes","git","tutorial",{"slug":682,"featured":6,"template":683},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","BlogPost","content:ja-jp:blog:how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery","ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":689,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":690,"content":696,"config":709,"_id":711,"_type":14,"title":712,"_source":16,"_file":713,"_stem":714,"_extension":19},"/ja-jp/blog/what-is-kubernetes",{"title":691,"description":692,"ogTitle":691,"ogDescription":692,"noIndex":6,"ogImage":693,"ogUrl":694,"ogSiteName":667,"ogType":668,"canonicalUrls":694,"schema":695},"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":691,"description":692,"authors":697,"heroImage":693,"date":700,"body":701,"category":702,"tags":703},[698,699],"GitLab Japan Team","GitLab","2025-04-28","## 目次\n\n1. Kubernetesとは？その読み方と用途\n2. Kubernetes（K8s）の基本用語解説\n  - コンテナ、Pod、Node、クラスター\n  - Dockerとの違い\n3. Kubernetesの主な特徴\n  - デプロイの自動化\n  - ハイブリッド / マルチクラウドに対応\n  - 拡張性とプラグインアーキテクチャ\n  - ローリングアップデートとロールバック\n  - 柔軟なスケーラビリティ\n  - リリース後のアプリケーション監視\n4. Kubernetesの利点とは\n  - 生産性の向上\n  - 自己修復機能により障害に耐性\n  - 高い可用性を担保\n  - オンプレミスでも、クラウドでも運用可能\n  - 大量のコンテナを一括管理\n  - DevSecOpsとの親和性が高い\n  - クラウドネイティブなワークロードを安全に保つ\n5. GitLabでKubernetesを統合する\n6. Kubernetes（K8s）のよくある質問\n  - KubernetesとDockerの違いは何ですか？\n  - Kubernetesで何ができますか？\n  - Kubernetesコンテナとは何ですか？\n  - Kubernetesの読み方は？\n\n## Kubernetesとは？その読み方と用途\n\nKubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と発音します。ギリシャ語のκυβερνήτηςに由来し、「統治者」や「パイロット」といった意味を持ちます。また、K8sと表記されることもあります。  \n\nKubernetesは、一言で表せばソフトウェア開発においてコンテナを操作・管理するもので、コンテナオーケストレーションの役割を果たすオープンソースソフトウェアとして開発されました。Kubernetesは、クラウドネイティブのプログラムの開発に使用します。これを使用することで[マイクロサービス](https://about.gitlab.com/ja-jp/topics/microservices/)アーキテクチャが可能になり、プログラムの開発が高速化できます。  \nでは、Kubernetesについて、もう少し掘り下げて見ていきましょう。\n\n## Kubernetes（K8s）の基本用語解説\n\n### コンテナ、Pod、Node、クラスター\n\nKubernetesは、コンテナをオーケストレーションするためのツールです。オーケストレーションとは、複数のコンピュータシステムやアプリケーション、サービスなどを調整して管理し、頻繁に繰り返される大規模なワークフローやプロセスを実行できるようにすることを指します。では、コンテナとは何でしょう。ソフトウェア開発におけるコンテナ化とは、ソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することを意味します。コンテナは、完全に機能するポータブルなコンピューティング環境です。また、このコンテナを複数まとめたものがPod、PodをまとめたものがNode、Nodeをまとめたものがクラスタと呼ばれます（以下の図を参照）。\n\n![kubernetesとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687494/Blog/Content%20Images/kubernetes-diagram.svg)\n\n*Kubernetesにおけるコンテナとクラスタの関係を示した図*\n### Dockerとの違い\n\nKuberunetesはコンテナオーケストレーションツールですが、Dockerはコンテナ化ツールの1つです。Dockerはアプリケーションのコンテナ化を行なうとき使用するプラットフォームです。仮想マシンよりも軽量で高速であることや、環境構築が簡単なことから、コンテナ化の主流ツールになっています。\n\n## Kubernetesの主な特徴\n\nKubernetesは、前述したようにコンテナを管理するコンテナオーケストレーションツールで、代表的な機能としては次のようなものが挙げられます。\n\n### デプロイの自動化\n\nKubernetesは、アプリケーションのデプロイ時に、新しいコンテナの作成や既存コンテナの削除を自動で実施します。また、新しく作成したコンテナにも自動でリソースを適用します。\n\n### ハイブリッド / マルチクラウドに対応\n\nクラウドプロバイダーに依存することなく、オンプレミス環境や様々なクラウドサービス（AWS、Azureなど）上で動作します。よって、ハイブリッドクラウドやマルチクラウド環境を簡単に構築、管理することができます。\n\n### 拡張性とプラグインアーキテクチャ\n\n多様なプラグインや拡張機能が利用できます。例えば、CustomResourceDefinitions（CRD）を使って新規にリソースタイプやロジックを追加したり、CNI（Container Network Interface）やCSI（Container Storage Interface）といったプラグインでネットワークやストレージのカスタマイズが可能です。\n\n### ローリングアップデートとロールバック\n\nKubernetesでは、アプリケーションのバージョンを更新する際、ローリングアップデートがそのデフォルトとなります。また、ビルトインでロールバック機構もあります。このため、ライブトラフィックに影響を与えず、ダウンタイムゼロでデプロイを実現できます。\n\n### 柔軟なスケーラビリティ\n\nKubernetesは、大量のコンテナを効率的に管理するためのもので、システムのスケーラビリティが向上できます。スケーラビリティとは、どのくらいシステムの拡張ができるかを示す特性で、Kubernetesではコンテナ化されたアプリケーションの数を増減することでスケーリングします。\n\n### リリース後のアプリケーション監視\n\nPrometheusやGrafanaといった監視ツールを使用することで、アプリケーション固有のメトリクスが監視できます。リリース後のパフォーマンス低下や不具合発見といった事象がアラートされるため、問題に迅速に対処できます。\n\n## Kubernetesの利点とは\n\nKubernetesには次のような7つのメリットがあります。\n\n### 生産性の向上\n\n一つ目のメリットは、アプリケーション開発で生産性が向上できる点にあります。従来の仮想化では、アプリケーションごとにゲストOSを用意する必要がありましたが、Kubernetesでは、アプリケーションを直接コンテナエンジン上にデプロイできるため、サーバーのリソース使用量が抑えられます。\n\n### 自己修復機能により障害に耐性\n\nKubernetesには、PodやNodeに障害が起きた場合、最初の定義（マニフェスト）の状態まで自動修復する機能が備わっています。\n\n### 高い可用性を担保\n\nKubernetesは、複数のNodeの集まりであるクラスターを構成します。あるクラスターで障害が発生した場合、障害が起きたコンテナを自動で再起動させます。また、他のNodeでコンテナを起動させ、処理を引き継ぐ動作も継続できるため、高い可用性が担保できます。\n\n### オンプレミスでも、クラウドでも運用可能\n\nKubernetesは、オンプレミスでも、プライベートクラウド、パブリッククラウドでも利用できます。つまり、自社サーバーでも、クラウドを使っても、どんな環境でも運用可能です。\n\n### 大量のコンテナの一括管理\n\nKubernetesでは、大量のコンテナが一括で管理・運用できます。また、設定ファイルを複数のコンテナ間で共有することによって、設定変更時も正確かつ大量に設定を反映させることが可能です。\n\n### DevSecOpsとの親和性が高い\nDevSecOpsとは、開発と運用を統合するDevOpsにセキュリティを加え、運用を視野に入れながら開発とセキュリティを同時に進め、安心・安全なソフトウェアを迅速にリリースするというコンセプトです。Kubernetesにはアプリケーションの開発と運用の双方に必要とされる機能が多く搭載されているため、DevSecOpsとの親和性が非常に高いという特長があります。\n\n### クラウドネイティブなワークロードを安全に保つ\n\nKubernetesは、クラウドネイティブアーキテクチャに基づいており、クラウドネイティブな情報セキュリティに関するベストプラクティスについて、CNCF（Cloud Native Computing Foundation）からのアドバイスを活用しています。\n\nたとえばKubernetesには、APIやセキュリティコントロールが含まれており、情報セキュリティを管理するポリシーを定義する手段も備わっています。クラウドの利用などでセキュリティ面において懸念が生じても、Kubernetesならユーザーごとにアクセス制限を設定でき、不正アクセスが防止できるため安心です。\n\nまた、Pod Security Standardによりセキュリティに3つのポリシーが定義されています。非常に緩いものから非常に厳しいものまで累積的に定義できます。\n\n## GitLabでKubernetesを統合する\n\nKubernetesクラスターとGitLabを接続すると、アプリの開発・デプロイ・管理・監視ができます。  \nGitLabをKubernetesと連携させる、またはKubernetes内で動作させるには、3つの異なる方法があります。単独で使用することも、組み合わせて使用することもできます。\n\n* GitLabからKubernetesにソフトウェアをデプロイする  \n* Kubernetesを使用してGitLabインスタンスに紐づいたRunnerを管理する  \n* GitLabのアプリケーションとサービスをKubernetesクラスター上で実行する\n\nさらに詳しい情報やお問い合わせは[こちら](https://about.gitlab.com/ja-jp/solutions/kubernetes/)をご覧ください。\n\n## Kubernetes （K8s）のよくある質問\n\n### KubernetesとDockerの違いは何ですか？\n\nDockerはコンテナ化ツールのひとつで、アプリケーションコンテナを構築し、アプリケーションの開発・配布・実行をします。Kubernetesは、より大規模に複数のマイクロサービスを管理するのに使われます。  \nまた、Kubernetesはクラスターで実行され、Dockerはノードで実行されます。Kubernetesの使用目的はコンテナ管理ですが、Dockerの使用目的の一つは、アプリケーションをコンテナに分離することになります。\n\n### Kubernetesで何ができますか？\n\nKubernetesでできることの代表例には下記のようなものが挙げられます。\n\n* 大量のコンテナの一括管理\n* 起動を含めた動作の高速化・軽量化  \n* 自動デプロイ  \n* 自己修復機能により障害に耐性\n* 高い可用性を担保\n* オンプレミスでも、クラウドでも運用可能\n* DevSecOpsとの親和性が高い\n* クラウドネイティブなワークロードを安全に保つ\n\n### Kubernetesコンテナとは何ですか？\n\nソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することをコンテナ化と言います。Kubernetesコンテナは、完全に機能するポータブルなコンピューティング環境で、さまざまなプラットフォームでデプロイ可能なプログラムとして[マイクロサービス](https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture/)アーキテクチャを可能にします（リンクは英語版です）。\n\n### Kubernetesの読み方は？\n\nKubernetesは、「クバネティス」、「クーベネティス」、または「クーバネーティス」と読み、「K8s（ケーエイツ）」と略されます。\n","engineering",[678,704,705,109,9,677,706,707,708],"cloud native","DevOps","security","performance","workflow",{"slug":710,"featured":91,"template":683},"what-is-kubernetes","content:ja-jp:blog:what-is-kubernetes.yml","What Is Kubernetes","ja-jp/blog/what-is-kubernetes.yml","ja-jp/blog/what-is-kubernetes",{"_path":716,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":723,"config":729,"_id":731,"_type":14,"title":732,"_source":16,"_file":733,"_stem":734,"_extension":19},"/ja-jp/blog/what-is-yaml",{"ogTitle":718,"schema":719,"ogImage":720,"ogDescription":721,"ogSiteName":667,"noIndex":6,"ogType":668,"ogUrl":722,"title":718,"canonicalUrls":722,"description":721},"拡張子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":718,"description":721,"authors":724,"heroImage":720,"date":725,"body":726,"category":702,"tags":727},[698,699],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[705,678,728,109,9,704,680,708,677,679],"DevSecOps",{"slug":730,"featured":91,"template":683},"what-is-yaml","content:ja-jp:blog:what-is-yaml.yml","What Is Yaml","ja-jp/blog/what-is-yaml.yml","ja-jp/blog/what-is-yaml",{"_path":736,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":737,"content":741,"config":754,"_id":756,"_type":14,"title":757,"_source":16,"_file":758,"_stem":759,"_extension":19},"/ja-jp/blog/claude-code-gitlab-ai-development-workflow",{"noIndex":6,"title":738,"description":739,"ogImage":740},"エージェンティックAI Claude CodeとGitLab CLIの開発フロー","Claude CodeとGLabを組み合わせてローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIのコード補助を活かした開発フローを構築する方法を紹介","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751953181/rtejicnkhd9oslaxsoo5.jpg",{"heroImage":740,"category":742,"body":743,"date":744,"authors":745,"description":747,"title":748,"tags":749},"ai-ml","## 目次\n\n1. はじめに: AI活用の新時代を切り拓く効率的なソフトウェア開発\n2. Claude Codeとは何か？\n3. GitLabのCLIであるGLabの紹介\n4. Claude CodeとGLabを組み合わせた開発の流れ\n5. AIを使った開発の今後の広がりについて\n6. まとめ\n7. よくある質問\n\n\n\n## はじめに: AI活用の新時代を切り拓く効率的なソフトウェア開発\n\nこの記事を読むと、エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法がわかるようになります。\n\n## Claude Codeとは何か？\n\nClaude Codeとはエージェント型AIで、ターミナル上でAIにコマンドを実行させることで既存ツールを使いながら効率的に開発できます。\n\n## GitLabのCLIであるGLabの紹介\n\nGLabはオープンソースのGitLab CLIツールです。GLabをターミナルに統合し、作業中のコマンドラインツールや、IDEの中に表示できます。GitLabのWebUIにアクセスするためにブラウザのウィンドウやタブに切り替える必要がなくなり、マージリクエストの作成やパイプラインの状況の確認など、様々なことを直感的にコマンドラインで実行可能になります。\n\n## Claude CodeとGLabを組み合わせた開発の流れ\n\n### **Claude Codeとglabのインストール**\n\nここでは個別のインストール方法や導入の仕方については割愛しますが、下記の公式サイトが参考になると思いますのでご確認ください。\n\nClaude Code: \u003Chttps://docs.anthropic.com/ja/docs/claude-code/overview>\n\nGLab: \u003Chttps://gitlab.com/gitlab-org/cli/-/blob/main/README.md>\n\n### [](https://gitlab.com/gitlab-org/cli/-/blob/main/README.md)**GitLabの認証情報を設定**\n\nまずはGLabのセットアップをしていきましょう。GLabでGitLabサーバーにログインします。\n\n`$ glab auth login`\n\n上記を実行すると、ログインするサーバーの先を問われるので、選びます。続いて、Tokenによるログインか、Webブラウザを使って認証するか聞かれるため、これも好きな方を選んでください。下記は、Webを選んだ場合の画面です。\n\n![Webログイン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/tl81t9qzwhqjnrro3lrb.png)\n\n次に、Gitクライアントが通信するデフォルトのプロトコルを聞かれるので、これも好きなものを選んでください。環境によってはSSHプロトコルの通信が制限されている場合もあるかと思うので、そのような場合はHTTPSを選ぶことをおすすめします。\n\n最後に、Gitの認証にもCredentialsの認証情報使うかを問われるため、これも選んでいただければと思います。\nYesの場合は、GitのHTTPS認証にもglabのPersonal Access Token（PAT）を使うよう.gitconfigに設定され、Noを選んだ場合は、glabでIssueやMRの操作をする一方で、Gitのpush/pullは従来通りのSSHや別途設定した認証方式で行う必要があります。\n\n初期の設定が終わった画面を下記に示します。\n\n![初期設定完了画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198582/xtpheeez1gcwr8sfjmdv.png)\n\n### **開発対象プロジェクトのclone**\n\n次に、Claude Codeに指示を与えて、glabコマンドを使って、リモートリポジトリからcloneします。下記のコマンドでClaude Codeを起動します。\n\n`$ claude`\n\n既にGLabで認証は終わっているため、作業するプロジェクトのリポジトリをcloneするように指示を与えます。\n\n`> GitLab上で自分が参加しているプロジェクトを表示してください`\n\n上記のようにプロンプトするとClaude Codeが\n\n`$ glab repo list`\n\nなどを実行してくれると思います。次に、作業したいリポジトリを上記から選び、Cloneします。プロジェクト名は各自の環境に合わせて指定してください。\n\n`> プロジェクト naosasaki-demo/study/spring-demo をcloneしてください`\n\nClaude Codeの処理が終わると、一度Claude Codeを終了し、ターミナルでディレクトリを確認すると、cloneされたディレクトリが作られていることがわかると思います。\n\n**新しいIssueの作成**\n\n次に、このプロジェクトに新しくイシューを作りたいと思います。通常であればWebブラウザでGitLabにアクセスしイシューを登録しますが、GLabとClaude Codeを使って、IDEやターミナル画面から作ってみたいと思います。\n\n`> このプロジェクトに新しいイシューを作ってください。内容は、今の東京の温度と天気を返すWebAPIのエンドポイントを作成します。`\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/iizlucpfxgsa0nrdsvqn.png)\n\n\n上記のようにglabを使ってイシューを作成するコマンドが提案されます。またイシューのなかの記載もある程度書いてくれていることがわかります。\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198579/ye2wtupp6nf8ljzja2yh.png)\n\nブラウザでアクセスしても、正しく作られていることがわかります。\n\n![イシュー作成](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198582/vbo22zzdzzanvnrbsszq.png)\n\n### **マージリクエストとブランチの作成と作業開始**\n\n次に、実際のこのIssueの内容を実装していきたいと思います。ここからはIDEのVisual Studio Codeも利用していきたいと思います。Visual Studio Codeを起動し、内蔵されたターミナルを開き、そこでClaude Codeを起動します。\n\n早速、先ほど作ったイシューからマージリクエストを作って、その中で作業をしていきたいと思います。\n\n`> このリポジトリのプロジェクトのissue 53を実装したいので、glabでMRを作って、そのブランチをチェックアウトして`\n\n![マージリクエストとブランチの作成と作業開始](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/or6l5si3k4dbprcnnfgq.png)\n\n**コードの編集と検証**\n\n`> イシューの記載に基づいて実装してください。また、リポジトリ内部のドキュメントも追加に伴って更新してください。`\n\n![コードの編集と検証](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/dlgq0j60n2jfk24vxaj3.png)\n\nOpenWeatherMap APIを使うことを提案してくれています。そのほかにも、いくつかのクラスを作成することを提案されるので、中身を確認しつつ、それを受け入れ、git pushなども依頼します。\n\n![CC_8_git push](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198584/esdeisz4mzyyjlerlahl.png)\n\n### **レビューとCI/CDの確認**\n\n実際にマージリクエストを確認すると、ローカルで作成した変更がプッシュされ、GitLab側のCI/CDでの単体テストや、セキュリティスキャンなども正常に実行され、問題なく終了していることがわかりました。\n\n![レビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/e7hyheb5gkpvb7iixrro.png)\n\nしかし、テストが通っていても、それが適切な方法で実装されているか、非機能的な観点で問題がないかは別途確認する必要があります。ここで[GitLab Duo in merge requests](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/)という機能を利用して、GitLabのAI機能であるGitLab Duoにレビューを依頼してみたいと思います。\n\nマージリクエストのコメントでレビューをリクエストし、レビュアーとしてDuoを指定します。この時、レビューの観点なども同時に与えることができます。下記のようにコメントでレビューをDuoに依頼します。\n\n`/request_review @GitLabDuo`\n\n`マージリクエストのコードを下記の観点でレビューしてください：`\n\n`拡張性：将来的な機能追加や変更に対応しやすい設計・実装になっているか  \n可読性：他の開発者が理解しやすいコードになっているか  \n安全性：バグやセキュリティリスクを引き起こす可能性がないか  \nパフォーマンス：必要以上にリソースを消費していないか`\n\n![Duoレビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198581/tnkt52hpapm8cyi4qplw.png)\n\n上記をコメントすることで、Duoにレビューを依頼できます。\n\n実際にレビュー指摘がありました。\n\n![Duoレビュー指摘](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752198573/vehscyu2beo4pz9ns3y2.png)\n\nDuoの指摘のとおり、Claude Codeが生成した元のコードでは、translateWeatherToJapanese メソッドが呼ばれるたびに HashMap が新しく作成されています。これはパフォーマンスの低下や不要なオブジェクト生成につながります。Duoは「このマップは不変であり、再利用可能なので static final にすべき」と提案しています。これの指摘は確かにその通りなので、マージリクエスト上でこの指摘と、変更の提案を受け入れます。\n\nこの変更の受け入れ自体も、ソースコードの変更なので、受け入れたらCI/CDパイプラインが動き出して、再度自動的にセキュリティスキャンや単体テスト実施されます。再度CI/CDパイプラインが動き、問題がなかったためmainブランチにマージしました。これでこの機能の開発は完了です。\n\n## AIを使った開発の今後の広がりについて\n\n### **AIは「補助ツール」から「実行の主体」へ**\n\n従来のチャットベースのインタラクティブな開発支援、すなわち一問一答のやり取りを繰り返しながら人間が主導で手を動かしていた開発スタイルから、いま大きな転換が始まっています。\n\nGLabのようなCLIツールやWebAPIと、エージェンティックAIを組み合わせることで、「命令→実行→ステータス確認→再試行」といった一連の開発オペレーションを、AIが自律的かつ反復的に担う、まさに実行主体としてのAIへの進化が進んでいます。\n\nこれは単なる補助からの脱却であり、ソフトウェア開発における人と機械の役割分担そのものを再定義しつつあります。人間は「何を実現したいか」を定義し、AIは「どう実現するか」を粘り強く試行錯誤していく、そんな協働の形が、現実の開発現場に静かに浸透し始めています。\n\n**レビューとガバナンスの重要性**\n\nAIによってコードが自動生成されるようになった今、開発効率が飛躍的に向上する一方で、「そのコードは本当に安全か？」「人間はAIの出力を正しくレビューできるのか？」といった新たな課題が生まれています。\n\n人間の作業と同様に、AIによって生成されたコードは、動作するからといって、品質が担保されているとは限りません。\n\nこうした背景から、組織的にAIを活用していくには、**コードの品質・セキュリティ・コンプライアンスを保証する仕組みを開発プロセスに組み込む**ことが不可欠です。\n\n今回は、コードの生成にClaude Codeを利用しましたが、そのコードに含まれる性能的な懸念をGitLab Duoによるレビューで摘出することができました。\n\nその他にも、GitLabでは「パイプライン実行ポリシー」を用いることで、プロジェクト単位ではなくグループやサブグループに対して、**SASTや依存関係スキャン、シークレット検出などのセキュリティジョブを強制適用**することが可能です。\n\nこのように、**AIによる開発支援とセキュリティ・品質管理の自動化を同時に実現できる**のは、DevSecOpsを包括的に支援するプラットフォームであるGitLabの強みといえます。\n\n## まとめ\n\nこの記事では、Claude CodeのようなAIエージェントと、GitLab公式CLIツールGLabを組み合わせることで、自然言語によるコード生成からGitLab上でのイシュー管理やマージリクエスト作成までをAIエージェントにやってもらうことで、開発効率を向上させる例を紹介しました。一方で、AIエージェントが生成するコードの品質を担保するには、GitLabのセキュリティスキャンやパイプライン実行ポリシーを活用した自動検証の仕組みが欠かせません。AIと人間、それぞれの強みを活かした開発フローが、今後ますます重要になっていくでしょう。\n\n> 今すぐ始められる：GitLabでAIを使ったソフトウェア開発を体験しよう\n>\n> [GitLab Duoの無料トライアルに申し込む](https://about.gitlab.com/ja-jp/solutions/gitlab-duo-pro/sales/)\n\n## よくある質問\n\n### Q1: GitLabのAI機能にはどのようなものがありますか？\n\nA1: GitLabのAI機能「GitLab Duo」には、ソースコードの提案、テストケース/コードの生成はもちろん、脆弱性の自動修復や、CI/CD失敗時の根本原因分析など、ソフトウェア開発全体に対するAIによる支援機能群が含まれています。\n\n\n### Q2: GitLab Duoはユーザーのソースコードを学習に使いますか？\n\nA2: いいえ。GitLab Duoは利用者のコードやデータをモデルの再学習には使用しません。GitLabはユーザーデータのプライバシーとセキュリティを重視しており、企業向けにも安心して利用できる設計となっています。詳細については、[GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/)をご確認ください。\n\n### Q3: Claude Codeとは何ですか？\n\nA3: Claude Codeとはエージェント型AIで、ターミナル上でAIにコマンドを実行させることで既存ツールを使いながら効率的に開発できます。\n\n### Q4: GitLab CLIのGLabとは何ですか？\n\nA4: GLabは、GitLab公式が提供するオープンソースのCLIツールです。GLabをターミナルに統合し、作業中のコマンドラインツールや、IDEの中に表示できます。","2025-07-14",[746],"Naoharu Sasaki","エージェント型AIであるClaude CodeとGitLab CLIツール「GLab」を組み合わせて、ローカル環境から効率的にIssue作成・MR操作・レビュー依頼などを自動化し、生成AIによるコード補助を活かした実践的な開発フローを構築する方法をご紹介します。","Claude Code × GitLab：AI活用を加速する、エージェンティックAIとGitLab CLIによる効率的なソフトウェア開発フロー",[750,109,751,752,728,753,9,234,706,680,708],"AI/ML","code review","collaboration","features",{"featured":91,"template":683,"slug":755},"claude-code-gitlab-ai-development-workflow","content:ja-jp:blog:claude-code-gitlab-ai-development-workflow.yml","Claude Code Gitlab Ai Development Workflow","ja-jp/blog/claude-code-gitlab-ai-development-workflow.yml","ja-jp/blog/claude-code-gitlab-ai-development-workflow",1,[660,688,715],1758326277265]