[{"data":1,"prerenderedAt":1118},["ShallowReactive",2],{"/en-us/blog/tags/open-source/":3,"navigation-ja-jp":20,"banner-ja-jp":437,"footer-ja-jp":450,"open source-tag-page-ja-jp":660},{"_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/open-source","tags",false,"",{"tag":9,"tagSlug":10},"open source","open-source",{"template":12},"BlogTag","content:en-us:blog:tags:open-source.yml","yaml","Open Source","content","en-us/blog/tags/open-source.yml","en-us/blog/tags/open-source","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":656,"_type":14,"title":657,"_source":16,"_file":658,"_stem":659,"_extension":19},"/shared/ja-jp/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":648},"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,553,586,620],{"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,537,539,541,543,548],{"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":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":459},"/ja-jp/solutions/gitops/","gitops",{"text":174,"config":538},{"href":176,"dataGaName":177,"dataGaLocation":459},{"text":179,"config":540},{"href":181,"dataGaName":182,"dataGaLocation":459},{"text":184,"config":542},{"href":186,"dataGaName":187,"dataGaLocation":459},{"text":544,"config":545},"教育",{"href":546,"dataGaName":547,"dataGaLocation":459},"/ja-jp/solutions/education/","education",{"text":549,"config":550},"金融サービス",{"href":551,"dataGaName":552,"dataGaLocation":459},"/ja-jp/solutions/finance/","financial services",{"title":194,"links":554},[555,557,559,561,564,566,570,572,574,576,578,580,582,584],{"text":206,"config":556},{"href":208,"dataGaName":209,"dataGaLocation":459},{"text":211,"config":558},{"href":213,"dataGaName":214,"dataGaLocation":459},{"text":216,"config":560},{"href":218,"dataGaName":219,"dataGaLocation":459},{"text":221,"config":562},{"href":223,"dataGaName":563,"dataGaLocation":459},"docs",{"text":244,"config":565},{"href":246,"dataGaName":247},{"text":567,"config":568},"お客様の成功事例",{"href":569,"dataGaLocation":459},"/customers/",{"text":239,"config":571},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":249,"config":573},{"href":251,"dataGaName":252,"dataGaLocation":459},{"text":262,"config":575},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":254,"config":577},{"href":256,"dataGaName":257,"dataGaLocation":459},{"text":267,"config":579},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":581},{"href":274,"dataGaName":275,"dataGaLocation":459},{"text":277,"config":583},{"href":279,"dataGaName":280,"dataGaLocation":459},{"text":282,"config":585},{"href":284,"dataGaName":285,"dataGaLocation":459},{"title":300,"links":587},[588,590,592,594,596,598,600,604,609,611,613,615],{"text":307,"config":589},{"href":309,"dataGaName":302,"dataGaLocation":459},{"text":312,"config":591},{"href":314,"dataGaName":315,"dataGaLocation":459},{"text":320,"config":593},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":595},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":330,"config":597},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":335,"config":599},{"href":337,"dataGaName":338,"dataGaLocation":459},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":459},"/sustainability/",{"text":605,"config":606},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":607,"dataGaName":608,"dataGaLocation":459},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":610},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":350,"config":612},{"href":352,"dataGaName":353,"dataGaLocation":459},{"text":355,"config":614},{"href":357,"dataGaName":358,"dataGaLocation":459},{"text":616,"config":617},"現代奴隷制の透明性に関する声明",{"href":618,"dataGaName":619,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":621},[622,624,626,628,633,638,643],{"text":35,"config":623},{"href":37,"dataGaName":38,"dataGaLocation":459},{"text":368,"config":625},{"href":370,"dataGaName":371,"dataGaLocation":459},{"text":373,"config":627},{"href":375,"dataGaName":376,"dataGaLocation":459},{"text":629,"config":630},"ステータス",{"href":631,"dataGaName":632,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":634,"config":635},"利用規約",{"href":636,"dataGaName":637,"dataGaLocation":459},"/terms/","terms of use",{"text":639,"config":640},"プライバシーに関する声明",{"href":641,"dataGaName":642,"dataGaLocation":459},"/ja-jp/privacy/","privacy statement",{"text":644,"config":645},"Cookieの設定",{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":649},[650,652,654],{"text":634,"config":651},{"href":636,"dataGaName":637,"dataGaLocation":459},{"text":639,"config":653},{"href":641,"dataGaName":642,"dataGaLocation":459},{"text":644,"config":655},{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"allPosts":661,"featuredPost":1096,"totalPagesCount":1116,"initialPosts":1117},[662,686,711,732,751,771,795,819,840,861,880,902,921,940,959,978,996,1015,1034,1054,1073],{"_path":663,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":664,"content":672,"config":679,"_id":682,"_type":14,"title":683,"_source":16,"_file":684,"_stem":685,"_extension":19},"/ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":665,"description":666,"ogTitle":665,"ogDescription":666,"noIndex":6,"ogImage":667,"ogUrl":668,"ogSiteName":669,"ogType":670,"canonicalUrls":668,"schema":671},"Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う","トーバルズ氏がオープンソースのバージョン管理システムの開発にいたった経緯、数か月で手を引いた理由、そしてGitでの新しいプログラミング言語のサポートについてどう考えているかをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-07\",\n      }",{"title":665,"description":666,"authors":673,"heroImage":667,"date":675,"body":676,"category":10,"tags":677},[674],"Patrick Steinhardt","2025-04-07","バージョン管理システム「Git」の最初のバージョンは、Linuxカーネルの父であるリーナス・トーバルズ氏によって、2005年4月7日にリリースされました。現在ではほぼすべてのデベロッパーが使うようになったこの重要なプロジェクトの20周年を記念して、トーバルズ氏にインタビューし、Gitの歴史、Gitのメンテナーとしての役割を別の人物に引き継いだ理由、そしてもっとも重要なマイルストーンとは何かについてうかがいました。\n\n**Gitをリリースした2005年には、すでに人気のLinuxカーネルのメンテナーを務めていらっしゃいました。それなのに、なぜ新しいバージョン管理システムの開発を始めようと思ったのですか？**\n\nバージョン管理を行うのが、すごく嫌になっていたんです。\n\n従来型のバージョン管理システム（CVS／RCS／SCCS）はエンドユーザーとしても（例：[GCC](https://gcc.gnu.org/)などのオープンソースプロジェクトの追跡に使用）、デベロッパーとしても（トランスメタ社では何にでもCVSを使用していたため）使用していましたが、非常に嫌な体験でした。\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nその当時、CVSを使用していたプロジェクトはほとんど、[SVN](https://subversion.apache.org/)に移行したと思いますが、正直なところ、SVNは単に表面的な部分だけを変更した「ブタに真珠」だと感じていました。CVSを単に別のソフトにしただけのもので、ある程度UIが改善されていたものの、基本的な問題は一切修正されておらず、代わりに新たな問題を内包していました。\n\nCVSや類似のソフトウェアの問題は、数えきれないほどあります。幸いなことに、それらの問題はもはや重要でなくなっており、若いデベロッパーは対処しなくて済んでいるはずです。90年代にはいくつかのサブシステム（特にネットワーク側）で実際にCVSを使ってコードを追跡していましたが、カーネルでCVSを使うことは断固として拒否しました。\n\nその当時、私はサンフランシスコ・ベイエリアに住んでいました。別のプロジェクト（主に[lmbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf)）で知り合ったラリー・マクボイがBitMoverを立ち上げ、BitKeeper（略称「BK」）と呼ばれる新たなバージョン管理モデルを開発しました。\n\nBitKeeperはオープンソースではなかったものの、ラリー自身はオープンソースプロジェクトを好んでおり、バージョン管理の欠如がカーネルの足かせになっていると強く感じていました。ラリーの考えには同意していたものの、従来のソースコード管理ツール（SCM）の導入にはまったく賛成できませんでした。ラリーは時間をかけて、デイヴィッド・ミラー（ネットワーク機能のメンテナーで既存のCVSユーザー）と私に、BitKeeperでできることを説明してくれました。\n\nBitKeeperは完璧ではありませんでした。また、他の多くの従来型SCMと同様、ソースコード管理システム（SCCS）をベースにしていたため、うまく機能しない「ファイルごとの履歴」モデルが使用されていました。そのため、ファイルの名前変更や削除の際に根本的かつ重大な問題が生じるという欠点がありました。\n\nしかしながら、BitKeeperは単なる「ブタに真珠」ではありませんでした。下層レベルではSCCSが用いられていたかもしれませんが、それより上のレベルでは非常に根本的な部分がいくつか修正されており、適切に分散型開発が行われていました。また、ファイルごとではなく、全体的に履歴が管理されていたため、別のツリーからのコードのマージも実際に行えました。\n\nCVSでは、ブランチを作成してマージする場合、事前に計画して関係者と話し合う必要があり、一大イベントでした。一方、BitKeeperではすべてのリポジトリがブランチでした。これは今となっては当たり前のことです。もちろんGitではこれをさらに推し進め、リポジトリ*ごと*に複数のブランチを持てるようになっています。それと比べると、BitKeeperモデルははるかに制限されたものでしたが、当時は大きな前進でした。\n\nもう一度言いますが、BitKeeperは完璧ではありませんでした。先ほどもお話ししたように、ファイルごとに履歴を保持していたため、名前変更やファイルのマージが確実ではないという根本的かつ重大な問題がありました。そのため、どうしても混乱と手間が苦痛が生じていました（CVSを使っていた方は、Atticを思い出してみてください）。さらに、スケーラビリティの問題もいくつかありましたが、当時はまだ大きな問題ではありませんでした。\n\nしかしながら、BitKeeperの最大の問題はライセンスでした。数年かけて（2002年から2005年までBitKeeperを使用）、多くのカーネルメンテナーがBitKeeperに移行しましたが、毎回ライセンスの面で摩擦が生じていました。2004年後半にはそれが大問題となり、カーネルにBitKeeperを使用することは、数か月後には基本的に不可能という事態となりました。\n\n当時の私は、ようやく機能するソース管理ツールを使用できるようになってから3年間経っており、おかげで非常に多くの問題を解決できていました。ソース管理を行っていなかった時代に戻るのはお断りでしたが、BitKeeperを使用していた数年の間、それよりも良いツールはオープンソースコミュニティから出てこなかったのです。\n\nCVSやSVNがうまく機能しないことは周知の事実であり、別のアプローチを試したプロジェクトもありました。それらのアプローチの中には、さらにひどいもの（多くは「手の込んだパッチ追跡」に相当するもの）や、アイデア自体は良かったのに、その過程で新しい重大なデザインミスが起きたもの（[Monotone](https://www.monotone.ca/)）もありました。\n\nそのため、しばらく探し回ってから、他に選択肢はないから自分で開発しなければ、と決断しました。\n\n技術的には、Gitの最初のバージョンの作成には数日しかかかりませんでした。それはすべて、Gitのコミット履歴に残っています。ほぼ何もなかった状態から、1週間後には他の人から提供されたパッチを適用し始める（さらにその数日後には、カーネルに積極的に使用されるようになった）ほど使える状態になった様子は簡単に見て取れます。\n\nしかしながら、コミット履歴からは、それまでに私がこの問題についてしばらく*考えていた*という事実はわかりません。コードを書くこと自体は簡単です。重要なのは、良いデザインを行うことです。ですので、あの数日間の前にかなり長い準備期間がありました。その部分は、コミット履歴には反映されていません。\n\n最初のバージョンはとても粗削りなもので、後から登場する機能はほとんど備わっていませんでした。しかしながら、この最初のバージョンには、核となるデザインの大部分がすでに含まれていました。\n\n**Gitプロジェクトがどのように始まったか、最初の数日間と数週間について簡単に説明していただけますか？**\n\n私は基本的には、満足できる代替ツールができあがるまで、カーネルの開発を中断すると決めていました。主な目標は、分散型かつ高性能であること、そしてどんな破損でも確実に検出可能と信頼できるものを開発することでした。\n\nただし、お伝えしておきたいのは、SCM自体には興味がなかったということです。私が興味があったのは、プロセスではなく、最終的に得られる結果でした。そのため、私にとって、Gitはカーネルと同じではありませんでした。Linux開発はカーネルに興味があるから行っていますが、Gitは必要性に迫られて取り組みました。\n\nこれが、次の質問の回答にも直接つながります。\n\n**数か月後に、Gitのメンテナーの役割を濱野純氏に引き継がれました。今でも引き続き濱野氏がメンテナーを務めています。メンテナーを退いた理由、そして濱野氏を選んだ理由についてお聞かせください。**\n\nメンテナーの役割を引き継ぐことは、難しい決断ではありませんでした。「Gitのメンテナンスを任せられると思える相手が見つかったら、すぐにカーネルのメンテナーに戻ろう」と考えていたためです。\n\nもちろん、責任だけを押し付けて、成功を祈ったというわけではありません。メンテナンスを長期間にわたって担当してくれる、「センスが良い」人を探す必要があると考えていたため、結局、Gitのメンテナーを4か月ほど務めることになりました。\n\n濱野さんは、初期から参加したメンバーの1人でした（文字どおり、開発の最初の週から参加）。でも、すぐに「次のメンテナーになってください」と言ったわけではありません。誰が長期にわたって担当してくれるか、また誰がコードを書いて、適切な決定を下せるかを見極めるには、ある程度の時間がかかります。\n\n濱野さんはまさにぴったりでした。私がGitに費やしたのはわずか数か月間ですが、特に20周年を迎えるにあたり、賞賛を受けすぎていると感じています。適切に核となるデザインを行い、プロジェクトを立ち上げたことは私の実績ですが、（もちろん他の何百人もの関係者も重要ですが）実際にプロジェクトを主導してきたのは濱野さんです。\n\n**バージョン管理システムであるMercurialの最初のバージョンは、Gitの最初のバージョンがリリースされてからわずか12日後（2005年4月19日）にリリースされました。MercurialのユーザーエクスペリエンスはGitよりも優れていたと多くの人々が主張していますが、今では圧倒的にGitの方が人気があります。GitがMercurialに勝った理由は何だとお考えですか？**\n\n主な理由は、明らかにネットワーク効果だと思います。SCMには、非常に強力なネットワーク効果があります。制限が多いにもかかわらず、CVSがあれほど長く生き残った理由もそれです。\n\nつまり、カーネルでGitを使用していたためです（その後、ある時点でRuby on RailsコミュニティでGitが大人気となり、それからさまざまな場所で普及しました）。\n\nでも、Gitのデザインは本当に優れていると思います。コアモデルは非常にシンプルかつ強力です。そのおかげで、他の環境に簡単に移植できたと考えています。JGitは初期の移植例ですが、他にもMSgit仮想ファイルシステムなどの実装があります。\n\nたしかに当初はGitが使いにくいという評判がありましたが、その理由の一部は、Gitでは「正しく」処理を行っていたことが原因だと思います。Gitでは、従来のSCMでは決して行わなかったような、難しい判断をいくつか行っていたため、他の環境から移行したユーザーはGitを直感的ではないと感じたのでしょう。\n\n**Gitプロジェクトは、あなたが濱野氏にメンテナーの役割を引き継いだ後も、一度も停止せずに、コミュニティメンバーによる新機能の開発が常に進行中です。プロジェクトを離れた後、もっとも重要なマイルストーンは何だったとお考えですか？**\n\nそれは非常に答えにくい質問です。というのも、自分が満足するようにGitを開発したため、*私自身*が活用している機能は、開発当初から使えたためです。わかりやすい例としては、GitがWindowsに対応したことことは、他のユーザーにとっては間違いなく大きなステップでしたが、*私*にとってはまったく関係のないことでした。\n\nもちろんGit自体に、使いやすさを向上するためのインフラがすべて備わっていますが、大きなマイルストーンの大半は、Gitのインフラを利用して、それを中心に何かを構築してきた人たちによって成し遂げられたものだと思います。当然ながら、これらは最終的にはGitの機能に反映されがちです。しかしながら、本当のマイルストーンは外部に関するものです。\n\nわかりやすい例を挙げると、Gitのホスティングサイトはすべて大きなマイルストーンです。ホスティングサイトによって、より簡単にGitを配信できるようになったものの、*本当のマイルストーン*は、ホスティングによってユーザーがさまざまなプロジェクトでGitを非常に簡単に使えるようになったことです。\n\n**もし、またGitにフルタイムで携わることができるとしたら、実装したい機能はありますか？**\n\n一切ないですね。Gitではかなり初期の段階から、本当に必要としていたことをすべて実現できました。実のところ、私の使い方はかなり限定的で、本当に重視しているのは1つのプロジェクトだけなんです。\n\nそして、「一切ない」とお答えしたのは、先ほどお伝えしたとおり、私は当初からSCMにまったく興味がなかったためです。Gitが他のSCMとこれほど違うものになった（おおむね良い意味で）主な理由は、私が従来のSCMというより、分散型ジャーナリングファイルシステムに対してのように取り組んだからだと思います。\n\n**Gitの機能やデザイン上の決定で、後悔していることはありますか？**\n\nデザイン上の決定ですか？後悔していることはありません。今でも基本デザインは非常に優れていると思っています。実際の実装の複雑な詳細に一切触れることなく、さまざまなGitのコンセプトについて話し合えます。\n\nプロジェクトにおいては、それが重要だと思います。プロジェクトのコンセプトの方向性を指示するには、基本的なデザイン方針がある程度必要です。\n\nときにはこれが行き過ぎて、実装時に、基本デザインの核となる方針に盲目的に従うべきだと考える人もいます。これも間違っています。現実はややこしく、人々は変わったものを求めるため、*実装時*には複雑な多数のコーナーケースが生じます。なので、厄介な現実に対処しなくて済むように、参考になり、高度なレベルで検討できるような、ある種の基本デザインが必要となります。\n\nGitはそう言った面でバランスが取れていると思います。非常にわかりやすいオブジェクトストアデザインが採用されています（CS分野の方にとっては「マークル木構造」、ファイルシステム担当者には「内容アドレス記憶装置」という呼び方がピンとくるかもしれません）。コアデザインは存在しますが、一方でそれは実際のところ、実コードのほんの一部にすぎません。*コード*の大半はコアデザインに沿った内容です。根本的にデザインがわかりやすいため、プロジェクトにある種の基本構造が生まれます。\n\nこれは、かつてのUNIX自体の基本構造（すべてがファイルから構成されている仕組みや、プロセス処理方法）と同じようなものです。デザインのベースとなる「コンセプト」はいくつかあるものの、コードの99%は、それを実世界に適用するために、その上に構築される非常に細かな内容です。\n\n私には、技術に関する信念が2つあります。それは「私がかなたを見渡せたのだとしたら、それは巨人の肩の上に立っていたからです」（ニュートン）と「天才とは、1%のひらめきと99%の努力である」（エジソン）です。\n\n99%の努力について考えてみると、大まかなデザインには非常に満足していますが、細かい点については、もし今Gitに携わるなら違う風にしていただろうなと思うところは、確かに多々あります。\n\nでも正直なところ、そういった点はあまり重要でありません。それよりも、過去20年間に行われたすべての*良い*実装こそがはるかに重要です。\n\n**Linuxカーネルにおいて、一部のサブシステムのプログラミング言語としてRustの使用が開始されました。Gitの場合、このような新しいプログラミング言語を使い始めることは妥当だとお考えですか？**\n\nGitに関して言えば、新たな言語を使い始めることにあまり意味はないと思います。大抵の場合、苦労することになります。\n\nカーネルの場合、最終的な成果物は単一のカーネルバイナリです。その大半はモジュールとして動的に読み込むことはできるものの、実質的には単一のバイナリにリンクされています。\n\nそのため、複数の言語を使用すると、より複雑になります。しかしその一方で、カーネルではメモリ安全性についてさらに気を付けなければならないため、新しい言語に目を向ける必要性があります。\n\nGitの場合は、もしその一部をRustや他の言語で書きたいのであれば、複数の言語で1つのバイナリを開発するよりも、個別に実装する方がはるかに理にかなっていると思います。\n\nGitの核となるアイデアの多くはシンプルなので、中核となる部分の並列実装だけならそれほど難しくないはずです。そうすれば、別の言語での開発がより適切な問題領域に、個別に取り組めます。\n\nもちろん、このやり方はすでにGitでも行われています。まさにこの方法で開発されているのがJGitです。別の言語を使用したのは、Gitとは異なるウェブベースの環境であるため、より自然な選択だったからです。\n\nGitの主要機能の一部に対応したRustの実装はすでにいくつかありますが、同様の状況だと思います。特定の状況においては、「すべてをRustに移植しよう」というよりも、このアプローチの方が適切だと思います。\n\nですので、Rustでの実装に興味がある方には、Rustを使用する利点がより明らかな箇所を探すことをおすすめします。標準的なGitのソースベースでは、C言語の使用はそれほど問題はなかったと思います。\n\n**数年ごとに、新しいバージョン管理システムが登場しています。Gitは今後も、重要なツールとしての地位を維持できるとお考えですか？** \n\nSCMにネットワーク効果があることは先ほどお話ししました。そのため、Gitに取って代わるには、少し優れているだけではなく、はるかに優れている必要があると思います。もしくは、互換性が高すぎると、実質的にGitの新しい実装となります。\n\nSCMを取り巻く状況は実際に変わったと思います。Gitには、Git以前のSCMが抱えていたような、深刻かつ根本的な問題はありません。したがって、「はるかに優れている」ツールを開発するのはかなり大変です。\n\nですので、当面の間、Gitが現在の地位を維持できると考えています。人々はGitに代わるツールではなく、Gitを*ベース*として改善に取り組んでいくでしょう。\n\n*注：このインタビューは、長さを調節し、文意を明確にするために編集されています。*\n\n## Gitの関連リンク\n\n- [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)  \n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Gitプロジェクト](https://git-scm.com/)",[9,678],"git",{"slug":680,"featured":91,"template":681},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","BlogPost","content:ja-jp:blog:celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Celebrating Gits 20th Anniversary With Creator Linus Torvalds","ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"_path":687,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":688,"content":694,"config":705,"_id":707,"_type":14,"title":708,"_source":16,"_file":709,"_stem":710,"_extension":19},"/ja-jp/blog/gitlab-free-tier-integration-guide",{"title":689,"description":690,"ogTitle":689,"ogDescription":690,"noIndex":6,"ogImage":691,"ogUrl":692,"ogSiteName":669,"ogType":670,"canonicalUrls":692,"schema":693},"フリー版のGitLabでできる Integration Guide 〜どんどんつなげよう、GitLabの輪〜","この記事ではGitLabのフリー版をご利用の方が無料で実現できる、他社製品とのインテグレーション方法について、詳しくご説明します。\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659791/Blog/Hero%20Images/%E3%83%95%E3%83%AA%E3%83%BC%E7%89%88%E3%81%AEGitLab%E3%81%A7%E3%81%A7%E3%81%8D%E3%82%8B6.png","https://about.gitlab.com/blog/gitlab-free-tier-integration-guide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"フリー版のGitLabでできる Integration Guide 〜どんどんつなげよう、GitLabの輪〜\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"}],\n        \"datePublished\": \"2025-05-28\",\n      }",{"title":689,"description":690,"authors":695,"heroImage":691,"date":697,"body":698,"category":10,"tags":699},[696],"Tsukasa Komatsubara","2025-05-28","## 目次\n\n__1.はじめに__\u003Cbr>\n__2.はしがき__\u003Cbr>\n__3.Redmine__\u003Cbr>\n  本書で扱うRedmine\u003Cbr>\n  Redmineのインストール\u003Cbr>\n      セットアップ\u003Cbr>\n      初期設定\u003Cbr>\n  GitLabのマニュアルの確認\u003Cbr>\n  GitLab側の設定\u003Cbr>\n  実際に使用している様子\u003Cbr>\n  GitLabのコミット時に「#2」を指定している様子\u003Cbr>\n  本インテグレーションのポイント\u003Cbr>\n  ご注意\u003Cbr>\n\n__4.Backlog__\u003Cbr>\n  本書で扱うBacklog\u003Cbr>\n      Backlogの利用開始\u003Cbr>\t\n      ユーザ登録\t\u003Cbr>\n  初期設定\u003Cbr>\n  GitLabのマニュアルの確認\u003Cbr>\n  GitLab側の設定\u003Cbr>\n      GitLabのイシュー機能を非表示\t\u003Cbr>\n  実際に使用している様子\t\u003Cbr>\n  GitLabのコミット時に「キー情報」を指定している様子\t\u003Cbr>\n  本インテグレーションのポイント\u003Cbr>\t\n  ご注意\t\u003Cbr>\n\n__5.Jira__\u003Cbr>\n  本書で扱うJiraと2つのユースケース\t\u003Cbr>\n  Jiraの利用開始\u003Cbr>\t\n      ユーザ登録\t\u003Cbr>\n      初期設定\t\u003Cbr>\n  GitLabのマニュアルの確認\t\u003Cbr>\n  ユースケース1. Jira Issue Integration\t\u003Cbr>\n  GitLab側の設定\t\u003Cbr>\n  GitLabのイシュー機能を非表示\t\u003Cbr>\n  実際に使用している様子\t\u003Cbr>\n  GitLabのコミット時に「URL情報」を指定している様子\t\u003Cbr>\n  本インテグレーションJira Issueのポイント\t\u003Cbr>\n  ご注意\t\u003Cbr>\n  ユースケース2. Jira development panel Integration\t\u003Cbr>\n  Jira側の設定\t\u003Cbr>\n  実際に使用している様子\t\u003Cbr>\n\n## 1.はじめに\n\n本書は、GitLabのフリー版をお使いの皆様に、無料で実現できる他社製品とのインテグレーション方法について詳しく説明したものです。  \n\nぜひ実際に手を動かして、セットアップしてみてください。  \nいずれもプロジェクト単位なので、他のGitLab上のプロジェクトに影響を与えることはありません。\n\n## 2.はしがき\n\n- 本書に登場する会社名および商品名は各社の商標または登録商標です。  \n- なお、本書ではⓇ、TM マークを明記しておりません。\n- 本書で前提としている各製品等のバージョンは以下となります。\n\n  GitLab.com および GitLab Community Edition/Enterprise Edition Free版 17.10\n\n## 3.Redmine\n\n### 本書で扱うRedmine\n\nRedmineとは、[https://www.redmine.org/](https://www.redmine.org/) で提供されている、無料のプロジェクト管理ツールです。非常に人気が高いOSSプロダクトです。\n\n![フリー版のGitLabでできる6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%E3%83%95%E3%83%AA%E3%83%BC%E7%89%88%E3%81%AEGitLab%E3%81%A7%E3%81%A7%E3%81%8D%E3%82%8B6.png)\n\n*引用元: https://www.redmine.org/*\n\n2025/04/01時点で、最新のものは、 [6.0.4](https://www.redmine.org/projects/redmine/wiki/Download)となっています。\n\n![フリー版のGitLabでできる26](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__26.png)\n*引用元: https://www.redmine.org/*\n\n### Redmineのインストール\n\n#### セットアップ\n\n本書では、Dockerをつかってインストールします。\n\n以下のファイルを作成： docker-compose.yml\n\n```\nversion: '3.1'\n\nservices:\n\n  redmine:\n    image: redmine\n    restart: always\n    ports:\n      - 80:3000\n    environment:\n      REDMINE_DB_MYSQL: db\n      REDMINE_DB_PASSWORD: example\n      REDMINE_SECRET_KEY_BASE: supersecretkey\n\n  db:\n    image: mysql:8.0\n    restart: always\n    environment:\n      MYSQL_ROOT_PASSWORD: example\n      MYSQL_DATABASE: redmine\n\n```\n\nその後、以下のコマンドでインスタンスを起動します。\n\n```\nsudo docker compose up \\-d\n```\n\n#### 初期設定\n\nRedmine側でプロジェクトや、イシューを作成できるよう、トラッカー等の設定をおこないます。一通りセットアップを完了します。\n\n![フリー版のGitLabでできる37](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__37.png)\n*引用元: https://www.redmine.org/*\n\n仮に以下の内容で準備が完了したとします。\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| URL | [http://my-redmine.samurai-tanuki.com/](http://my-redmine.samurai-tanuki.com/) |\n| 作成したプロジェクト | sample-project-1 |\n\n### GitLabのマニュアルの確認\n\n以下のURLで、GitLabとRedmineの設定方法についてのガイドが記載されています。\n\n[Redmine | GitLab Docs](https://docs.gitlab.com/user/project/integrations/redmine/) \n\n### GitLab側の設定\n\n![フリー版のGitLabでできる20](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__20.png)\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| プロジェクトのURL | http://my-redmine.samurai-tanuki.com/projects/sample-project-1 |\n| イシューのURL | http://my-redmine.samurai-tanuki.com/issues/:id |\n| 新しいイシューのURL | http://my-redmine.samurai-tanuki.com/projects/sample-project-1/issues/new |\n\n（*上記では、「新しいイシューのURL」を指定していますが、本機能はもう動作しません。UI上は入力チェック機能が動作するため、なにか適当な文字列を指定すればよいです。プロジェクトのURL、イシューのURLを指定し、「テスト設定」を押下して動作を確認します）\n\n上記の「プロジェクトのURL」は、GitLabのメニューの以下の部分に表示されます。\n\n![フリー版のGitLabでできる15](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__15.png)\n\n### 実際に使用している様子\n\nRedmine側で、以下のようにイシューを作成します。\n\n![フリー版のGitLabでできる11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__11.png)\n\n*引用元: https://www.redmine.org/*\n\n![フリー版のGitLabでできる12](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__12.png)\n*引用元: https://www.redmine.org/*\n\n### GitLabのコミット時に「#2」を指定している様子\n\n![フリー版のGitLabでできる16](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__16.png)\n\nコミットした後、以下のようにリンクが作成されます。\n\n![フリー版のGitLabでできる34](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__34.png)\n\n上記で「Issue in Redmine」をクリックすると、以下の画面に遷移します。\n\n![フリー版のGitLabでできる12](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__12.png)\n*引用元: https://www.redmine.org/*\n\n### 本インテグレーションのポイント\n\nGitLabとRedmineのインテグレーションを実現すると、以下のような内容が実現できます。\n\n1. Redmine側でイシューを作成  \n2. GitLab側でソースコード等へ修正を加え、コミット時に、Redmine側でのチケット番号を指定すると、URLとして保存される  \n3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのRedmineのチケットURLへ飛ぶことができる\n\nポイントとして、\n\n* GitLab側から、Redmine側へ直接「書き込み」は行わない  \n* あくまでもリンクをつなげることで、GitLab ⇔ Redmine間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ\n\nの2点が価値ポイントとなります。\n\n### ご注意\n\n本機能を有効にすると、GitLab側の「イシュー」機能が利用できなくなります。\n\n## 4.Backlog\n\n### 本書で扱うBacklog\n\nBacklogとは、株式会社ヌーラボ社から提供されている、製品です。ここでは、GitLabとのインテグレーション方法について解説します。\n\n![フリー版のGitLabでできる31](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__31.png)\n*引用元: https://backlog.com/ja/*\n\n### Backlogの利用開始\n\n#### ユーザ登録 \n\nBacklogの契約がまだで、テスト的に利用したい場合は、Free版が提供されているようなので、それを利用するのものオススメです。\n\n### 初期設定\n\nBacklog側でプロジェクトの作成をおこないます。Backlogの場合、プロジェクトを作成すれば、すぐに使えるようになっています。\n\n![フリー版のGitLabでできる44](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__44.png)\n\n*引用元: https://backlog.com/ja/*\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| URL | https://tsukasano.backlog.com/ |\n| 作成したプロジェクト | sample-project-1 |\n\n### GitLabのマニュアルの確認\n\n以下のURLで、GitLabとBacklogについては、汎用的な接続インターフェースで設定します。  \nこの設定をした場合、GitLabの既存の「イシュー」機能も「存続」します。そのため、特に併用の必要がない場合は、GitLab側の「イシュー」を非表示することをおすすめします。\n\n[Custom issue tracker | GitLab Docs](https://docs.gitlab.com/user/project/integrations/custom_issue_tracker/)\n\n### GitLab側の設定\n\n![フリー版のGitLabでできる35](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__35.png)\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| プロジェクトのURL | https://tsukasano.backlog.com/projects/PAFE1 |\n| イシューのURL | https://tsukasano.backlog.com/view/PAFE1-:id |\n| 新しいイシューのURL | https://tsukasano.backlog.com/add/PAFE1 |\n\nBacklogの場合、イシューのURLの部分に少し注意が必要です。上記では、プロジェクトIDは「PAGE1」ですが、イシューを参照したときのURLは、(イシュー番号が6の場合)「https://tsukasano.backlog.com/view/PAFE1-6」となります。そのため、分かりづらいですが、上記の「イシューのURL」のように、「:id」を含める部分については注意が必要です。不明であれば、一旦、Backlog側でイシューを開き、そのURLの構成を確認するとよいでしょう。\n\n（* 上記では、「新しいイシューのURL」を指定していますが、本機能はもう動作しません。UI上は入力チェック機能が動作するため、なにか適当な文字列を指定すればよいです。プロジェクトのURL、イシューのURLを指定し、「テスト設定」を押下して動作を確認します）\n\n上記の「プロジェクトのURL」は、GitLabのメニューの以下の部分に表示されます。\n\n![フリー版のGitLabでできる50](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__50.png)\n\n#### GitLabのイシュー機能を非表示\n\nBacklogをメインとして使う場合、GitLabの「設定」ー「一般」ー「可視性、プロジェクトの機能、権限」より、「イシュー」をOffにします。\n\n![フリー版のGitLabでできる17](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__17.png)\n\nその後、[変更を保存]ボタンを押して、設定を反映します。  \n![フリー版のGitLabでできる8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__8.png)\nそうすると、以下のようにメニューの表示が変わります。\n\n![フリー版のGitLabでできる50](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__50.png)\n\n### 実際に使用している様子\n\nBacklog側で、以下のようにイシューを作成します。\n![フリー版のGitLabでできる23](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__23.png)\n*引用元: https://backlog.com/ja/*\n\nこの時、上の図の矢印アイコンをクリックすると、課題名とキーが含まれた「キー情報」がクリップボードにコピーされます。\n\n### GitLabのコミット時に「キー情報」を指定している様子\n![フリー版47](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/image47.png)\n\nコミットした後、以下のようにリンクが作成されます。\n\n![フリー版のGitLabでできる10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__10.png)\n\n上記で「Issue in Custom issue tracker」をクリックすると、以下の画面に遷移します。\n\n![フリー版のGitLabでできる45](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__45.png)\n*引用元: https://backlog.com/ja/*\n\n### 本インテグレーションのポイント\n\nGitLabとBacklogのインテグレーションを実現すると、以下のような内容が実現できます。\n\n1. Backlog側でイシューを作成  \n2. GitLab側でソースコード等へ修正を加え、コミット時に、Backlog側でのチケット番号を指定すると、URLとして保存される(Backlog側のUIから、チケット情報をコピーするとよいでしょう)  \n3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのBacklogのチケットURLへ飛ぶことができる\n\nポイントとして、\n\n* GitLab側から、Backlog側へ直接「書き込み」は行わない  \n* あくまでもリンクをつなげることで、GitLab ⇔ Backlog間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ\n\nの2点が価値ポイントとなります。\n\n### ご注意\n\n本機能を有効にすると、GitLab側の「イシュー」機能は残りますので、特別な理由がない限り、GitLab側の「イシュー」機能は停止するとよいでしょう。\n\n## 5.Jira\n\n### 本書で扱うJiraと2つのユースケース\n\nJiraとは、アトラシアン社から提供されている、製品です。ここでは、GitLabとのインテグレーション方法について解説します。\n\nここで扱うユースケースは、2つあります。このJiraの場合だけ、少し特殊なのが面白いところです。  \n「Jira Issue」と「Jira development panel」Integrationです。\n\n![フリー版のGitLabでできる3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__3.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n### Jiraの利用開始\n\n#### ユーザ登録\n\nJiraの契約がまだで、テスト的に利用したい場合は、Free版が提供されているようなので、それを利用するのものオススメです。\n\n#### 初期設定\n\nJira側でプロジェクトの作成をおこないます。Jiraの場合、プロジェクトを作成すれば、すぐに使えるようになっています。\n![フリー版のGitLabでできる5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__5.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| URL | https://gitlab-tsukasa.atlassian.net/jira/software/projects/KAN/boards/1 |\n| 作成したプロジェクト | KAN |\n\n### GitLabのマニュアルの確認\n\n以下のURLで、GitLabとJiraについては、専用のインターフェースで設定します。Jiraの場合は他のプロダクトと比較して、よりレベルの高いインテグレーションが可能になっています。\n\n[Jira | GitLab Docs](https://docs.gitlab.com/integration/jira/)\n\nGitLabとJiraのインテグレーションは、以下の2箇所あります。\n\n* Jira イシュー … チケット機能です  \n* Jira デベロップメントパネル … GitLab内のブランチ情報などをJiraに連携します\n\nそれぞれ、GitLabとどう関係するのかは、以下のURLをご参考ください。\n\n[Jira | GitLab Docs](https://docs.gitlab.com/integration/jira/#feature-availability)\n\n例)  \n![フリー版のGitLabでできる52](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__52.png)\n\n(以下続く)\n\n### ユースケース1. Jira Issue Integration\n\n以下のURLにアクセスして、Jira側でAPIトークンを取得します。  \n[https://id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens)\n\nその時のユーザは、Jiraの管理者である必要があります。このユーザをつかって、GitLab側でのコミット情報をJira側にも書き込みます。\n\n#### GitLab側の設定\n\n![フリー版のGitLabでできる41](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__41.png)\nここでは、Web URLをつかって、インテグレーションをおこないます。\n\n| 項目 | 設定値 |\n| :---- | :---- |\n| Web URL | https://gitlab-tsukasa.atlassian.net |\n\n以下の部分はデフォルトでチェックされていますので、そのままにします。これにより、Jira側へコメントが自動書き込みされます。\n![フリー版のGitLabでできる51](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__51.png)\n\nGitLab Premium版以上を使うと、GitLabの「イシュー」画面から透過的にJiraのイシューを見ることができますが、本書はGitLabフリー版を前提としていますので、GitLabの「イシュー」機能を非表示にします。\n\n#### GitLabのイシュー機能を非表示\n\nJiraをメインとして使う場合、GitLabの「設定」ー「一般」ー「可視性、プロジェクトの機能、権限」より、「イシュー」をOffにします。\n![フリー版のGitLabでできる17](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176161/Blog/upmcvbthskxusvq6qf38.png)\n\nその後、[変更を保存]ボタンを押して、設定を反映します。\n\n![フリー版のGitLabでできる8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__8.png)\n\nそうすると、以下のようにメニューの表示が変わります。\n\n![フリー版のGitLabでできる39](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__39.png)\n\n#### 実際に使用している様子\n\nJira側で、以下のようにイシューを作成します。\n\n![フリー版のGitLabでできる43](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__43.png)\n\nこの時、上の図のクリップアイコンをクリックすると、このチケットへのURLがクリップボードにコピーされます。\n\n#### GitLabのコミット時に「URL情報」を指定している様子\n![フリー版33](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/image33.png)\nコミットした後、以下のようにリンクが作成されます。\n![フリー版のGitLabでできる27](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__27.png)\n\n一方、キー番号のみを記述すると以下にになります。\n\n![フリー版のGitLabでできる40](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__40.png)\n\n![フリー版のGitLabでできる1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__1.png)\n上記で「Issue in Jira issue」をクリックすると、以下の画面に遷移します。\n\n![フリー版のGitLabでできる24](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__24.png)\n\nこのように、コメントが記入されますので、URLよりも、キーを指定することをおすすめします。\n\n#### 本インテグレーション（Jira Issue）のポイント \n\nGitLabとJira Issueのインテグレーションを実現すると、以下のような内容が実現できます。\n\n1. Jira側でイシューを作成  \n2. GitLab側でソースコード等へ修正を加え、コミット時に、Jira側でのチケット番号を指定すると、URLとして保存される  \n3. GitLabの画面で、そのチケット番号部分が「URLリンク」になっているため、クリックすればすぐにそのJiraのチケットURLへ飛ぶことができる  \n4. さらに、そのJiraのチケットに、コミット時のコメントが記載される\n\nポイントとして、\n\n* GitLab側から、Jira Issue側へ直接「書き込み」を行う  \n* チケットへのURLを貼ると、「書き込み」は行われない  \n* これにより、GitLab ⇔ Jira間で手動で行き来する手間と(別のチケットを参照しないように)操作ミスを防ぐ\n\nの3点が価値ポイントとなります。\n\n#### ご注意\n\n__GitLab Free版を使う場合__\n\n本機能を有効にすると、GitLab側の「イシュー」機能は残りますので、特別な理由がない限り、GitLab側の「イシュー」機能は停止するとよいでしょう。\n\n__ご参考__\nGitLab Premium以上をご利用するとGitLabの「イシュー」から、JiraのIssueが見えるようになります。\n\n[Jira issues integration | GitLab Docs](https://docs.gitlab.com/integration/jira/configure/#view-jira-issues)\n\nまた、GitLab Ultimateをご利用すると、GitLab側でセキュリティスキャンを行ったのち、脆弱性がみつかった際、その脆弱性をJira側へ新規のチケットとして起票する、という機能が利用可能です。\n\n[Jira issues integration | GitLab Docs](https://docs.gitlab.com/integration/jira/configure/#create-a-jira-issue-for-a-vulnerability)  \n\n### ユースケース2. Jira development panel Integration\n\nこのユースケースを使用する際、Jira側でどの「Jira」を使っているのかが重要になります。Atlassian社が提供するクラウドサービスを使っている場合、「GitLab for Jira Cloud app」(GitLab製)を使います。一方、オンプレミス版の「Jira Data Center or Jira Server」を使っている場合は、「Jira DVCS connector」（Atlassian社製）を使います。\n\n本書では、クラウドサービスのJiraを使っている、という前提で解説します。\n\n#### Jira側の設定\n\nJiraの画面で、「アプリ」ー「その他のアプリを探す」をクリックします。\n\n![フリー版のGitLabでできる14](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__14.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nここで、GitLab製のこの「GitLab for Jira Cloud」Appをインストールします。\n\n![フリー版のGitLabでできる7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__7.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n![フリー版のGitLabでできる2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__2.png)\n\n![フリー版のGitLabでできる48](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__48.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nこれで無事インストールが完了です。\n\n完了すると、次のポップアップが表示されますので、「Get started」をクリックします。\n\n![フリー版のGitLabでできる30](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__30.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nすると、次の画面が表示されますので、GitLab.comを選択した状態で、認証を完了させます。\n\n![フリー版のGitLabでできる18](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__18.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n![フリー版のGitLabでできる4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__4.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n次に、このAppを有効にするGitLab側のグループを選択する画面になります。ここで、任意のグループを選択します。\n\n![フリー版のGitLabでできる32](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__32.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nここで選択できるのは、プロジェクトではなく、グループです。\n\n![フリー版のGitLabでできる49](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__49.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n無事完了すると、次の画面になります。\n\n![フリー版のGitLabでできる53](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__53.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n#### 実際に使用している様子\n\nでは、実際になにがどう見えるのか実践してみます。\n\nJira側で、なにか適当なイシューを作成するなり、見つけてみましょう。そのキーが「KAN-14」だとします。\n![フリー版のGitLabでできる25](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__25.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nここで、GitLab側でなにか適当に変更して、コミットする際のダイアログボックス画面で以下のように入力します。\n\n![フリー版のGitLabでできる21](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__21.png)\n\nJira側にもどって、該当チケットを見てみます。\n\n赤矢印のところに、GitLab側のレポジトリ情報が連携されていることがわかります。\n\n![フリー版のGitLabでできる19](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__19.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n以下のように、コミット情報等も連携されていることがわかります。\n\n![フリー版のGitLabでできる28](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__28.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nまた、「すべての開発情報を表示」をクリックすると、以下のような画面も表示されます。\n![フリー版のGitLabでできる29](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__29.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n参考までに、この時点でこのAppをアンインストールすると、以下のように、開発情報は表示されなくなります。\n![フリー版のGitLabでできる42](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__42.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nJira側からブランチを作成することも可能です。  \n![フリー版のGitLabでできる22](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__22.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nまた、以下は他のチケットですが、一度コミット時にJiraとの紐づけを行っておくと、そのブランチに対してビルドしたり、デプロイしたりした履歴が、以下のようにJira側にも反映されます。\n\n![フリー版のGitLabでできる36](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__36.png)\n*引用元: https://www.atlassian.com/software/jira*\n\n![フリー版のGitLabでできる38](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687054/Blog/Content%20Images/%C3%A3__%C3%A3_%C2%AA%C3%A3__%C3%A7__%C3%A3__GitLab%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__38.png)\n*引用元: https://www.atlassian.com/software/jira*\n\nこのように、Jiraのチケットから、「最終的にいまどこまで進んだ？」みたいな内容まで確認できるようになります。  \n",[234,700,109,701,9,702,703,704],"agile","collaboration","tutorial","workflow","embedded DevOps",{"slug":706,"featured":91,"template":681},"gitlab-free-tier-integration-guide","content:ja-jp:blog:gitlab-free-tier-integration-guide.yml","Gitlab Free Tier Integration Guide","ja-jp/blog/gitlab-free-tier-integration-guide.yml","ja-jp/blog/gitlab-free-tier-integration-guide",{"_path":712,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":713,"content":719,"config":726,"_id":728,"_type":14,"title":729,"_source":16,"_file":730,"_stem":731,"_extension":19},"/ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":714,"description":715,"ogTitle":714,"ogDescription":715,"noIndex":6,"ogImage":716,"ogUrl":717,"ogSiteName":669,"ogType":670,"canonicalUrls":717,"schema":718},"継続的デリバリーにおける信頼できる情報源として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","\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":714,"description":715,"authors":720,"heroImage":716,"date":722,"body":723,"category":10,"tags":724},[721],"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",[109,9,725,533,678,702],"kubernetes",{"slug":727,"featured":6,"template":681},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","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":733,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":734,"content":740,"config":745,"_id":747,"_type":14,"title":748,"_source":16,"_file":749,"_stem":750,"_extension":19},"/ja-jp/blog/journey-through-gits-20-year-history",{"title":735,"description":736,"ogTitle":735,"ogDescription":736,"noIndex":6,"ogImage":737,"ogUrl":738,"ogSiteName":669,"ogType":670,"canonicalUrls":738,"schema":739},"20年にわたるGitの歴史をたどる","初めて行われたコミット、初期リリースのユニークな特徴、そしてgit-push(1)のデフォルト動作の変更によって生じた混乱について、一緒に振り返っていきましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","https://about.gitlab.com/blog/journey-through-gits-20-year-history","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"20年にわたるGitの歴史をたどる\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-14\",\n      }",{"title":735,"description":736,"authors":741,"heroImage":737,"date":742,"body":743,"category":10,"tags":744},[674],"2025-04-14","Gitプロジェクトはちょうど20周年を迎えました。20年の間にさまざまなことがありました。Gitの概念的なデザインは、その登場以来大きく変わってはいないものの、ユーザーによるGitの操作方法は大きく変化しました。GitLabは、この重要な技術をベースにサービスを構築し、その歴史の一部であることを誇りに思っています。\n\nそれでは、Gitの歴史をたどり、長年にわたってどのように進化を遂げてきたかを一緒に見ていきましょう。\n\n## 初めてのコミット\n\n初めてのコミットは、2005年4月7日にLinuxカーネルの生みの親であるLinus Torvalds氏によって行われました。`e83c5163316 (Initial revision of \"git\", the information manager from hell, 2005-04-07)`\n\nご覧のとおり、このコミットには多くのファイルは含まれていませんでした。\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nビルドインフラストラクチャに加え、最初のコミットでは以下の7つのトップレベルコマンドが提供されていました。\n\n- `init-db`：新たなGitリポジトリを初期化\n- `update-cache`：インデックスにファイルを追加\n- `write-tree`：インデックスの内容を取得し、それをもとに新たなツリーを作成\n- `read-tree`：ツリーオブジェクトを読み込む\n- `commit-tree`：ツリーからコミットを作成\n- `cat-file`：特定のオブジェクトを一時ファイルに読み込む\n\nなお、この時点では、`git`コマンド自体存在していませんでした。代わりに、上記のコマンドを直接実行する必要がありました。\n\nでは、試しにリポジトリを新規作成してみましょう。\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nみなさんにはまったくなじみがないと思います。`.git`ディレクトリではなく、`.dircache`ディレクトリが使用されていました。では、プライベートストレージ領域はどこでしょうか？\n\n初期のGitのデザインでは、オブジェクトストレージ領域は「共有」と「プライベート」に分かれていました。このオブジェクトストレージ領域には、コミットやblobなども含め、あらゆるGitオブジェクトが格納されていました。\n\n`init-db`は、デフォルトではプライベートオブジェクトストレージ領域を作成します。これは、領域の作成先の管理ディレクトリ専用として使用されていました。一方、同じオブジェクトを二重に保存する必要がないように、「共有」オブジェクトストレージ領域を使用して、複数の管理ディレクトリ間でオブジェクトの内容を共有していました。\n\n### コミットを作成する\n\nリポジトリの作成後は、どのようにコミットを作成していたのでしょうか？作成方法は、現在利用可能な`git add . && git commit`ほどシンプルではありませんでした。その代わりに、以下の方法で行っていました。\n\n1. 追加するファイルごとに`update-cache`を呼び出してインデックスを更新する。\n1. `write-tree`を呼び出して新規ツリーを書き込む。インデックスに追加済みのすべての内容をもとに作成される。\n1. 環境変数を設定して、Gitにコミッターの情報を伝える。\n1. `commit-tree`を呼び出して、コミットオブジェクトを書き込む。\n\nそれでは、リポジトリにコミットを作成してみましょう。\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\n人間工学的な方法とは言えないものの、コミットは作成されます。それでは、生成されたコミットを見てみましょう。\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\n注目していただきたいのは、`cat-file`は内容を直接表示せず、まずは一時ファイルに書き出す点です。しかしながら、ファイルの内容は、まさに現代的なコミットと同じように見えます。\n\n### 変更を加える\n\nファイルの作成後、どのようにステータスを確認していたのでしょうか？おそらくお察しのとおりで、`show-diff`を使用していました。\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\n驚くべきことに、すでに`show-diff`では、変更されたファイルの新旧の状態を比較して差分を取得していました。しかも面白いことに、GitではこれをUNIXのdiff(1)ツールを使用するという簡単な方法で実現していました。\n\nつまり、これらはすべて必要最低限の機能しか備えていなかったものの、履歴の追跡に必要なすべての役割を果たしていました。以下のように制限は多数ありました。\n\n- あるコミットから別のコミットへ簡単に切り替える方法がなかった。\n- ログを表示できなかった。\n- ブランチやtag、また参照すら存在しなかった。そのため、ユーザーは手動でオブジェクトIDを追跡しなければならなかった。\n- 2つのリポジトリを相互に同期させる方法がなかった。代わりに、ユーザーがrsync(1)を使用して、`.dircache`ディレクトリを同期させる必要があった。\n- マージの実行方法がなかった。\n\n## Git 0.99\n\nGitの最初のテストリリースは、バージョン0.99でした。バージョン0.99は、最初のコミットからわずか2か月後にリリースされたものの、すでに1,076件のコミットが追加されていました。約50人のデベロッパーが開発に携わっており、最も頻繁にコミットを行っていたのはTorvalds氏自身でした。トーバルズ氏に続く勢いで、コミット件数の多かったコミッターは、現在メンテナーを務めている濱野純氏でした。\n\n最初のコミット以降、多数の変更が加えられました。\n\n- Gitは参照を使って複数の開発ブランチを追跡するようになりました。その結果、大抵の場合、手作業でオブジェクトIDを追跡せずに済むようになりました。\n- 新たにリモートプロトコルが導入され、2つのリポジトリ間で相互にオブジェクトを交換できるようになりました。\n- `.dircache`ディレクトリの名前が`.git`に変更されました。\n- 個々のファイルを相互にマージできるようになりました。\n\nただし、最も重要かつ顕著な変化は、トップレベルの`git`コマンドとそのサブコマンドが導入されたことでした。興味深いことに、「配管（plumbing）」コマンドと「磁器（porcelain）」コマンドの概念が導入されたのも、このリリースです。\n\n- 「配管」ツールは、基盤となるGitリポジトリにアクセスして低レベルな処理を行うコマンドです。\n- 「磁器」ツールは、「配管」コマンドをラップして、高レベルでよりユーザーフレンドリーなユーザーインターフェイスを提供するShellスクリプトです。\n\nGitには現在でもこの分け方は採用されており、[`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain)にも概説されています。しかしながら、「磁器」ツールの大半はShellスクリプトからC言語に書き直されたため、これらの2つのカテゴリ間の境界線はかなり曖昧になってきています。\n\n## Torvalds氏、メンテナーの役割を濱野氏に引き継ぐ\n\nTorvalds氏がGitに取り掛かった理由は、バージョン管理システムが好きだったためではなく、Linuxカーネル開発のためにBitKeeperの代替ツールを必要としていたためです。そのため、Gitのメンテナンスをずっと続けるつもりはなく、信頼できる人が現れるまで、メンテナーを務めようと考えていました。\n\nその条件に当てはまったのが、濱野純氏でした。濱野氏は、Torvalds氏が最初のコミットを行った約1週間後にGitの開発に参加しました。Git 0.99のリリース後にはすでに数百件のコミットを行っていました。そのため、2005年7月26日に、[Torvalds氏は濱野氏をGitプロジェクトの新たなメンテナーに任命しました](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/)。Torvalds氏は引き続きGitにコントリビュートしているものの、徐々にGitプロジェクトへの関わりは薄れていきました。これは、Linuxプロジェクトの責任者として多忙を極めているため、当然のことでした。\n\n現在でも、引き続き濱野氏がGitプロジェクトを率いています。\n\n## Git 1.0\n\n濱野氏は、2025年12月21日にGitの最初のメジャーリリースを行いました。興味深いことに、バージョン0.99から1.0の間には、34回もリリースが行われました（0.99.1～0.99.7、0.99.7a～0.99.7d、0.99.8～0.99.8g、0.99.9～0.99.9n）。\n\n0.99以降の特に重要なマイルストーンのひとつは、おそらく2つのツリーを相互にマージできる`git-merge(1)`コマンドの追加でしょう。それまでは基本的にファイルのマージを行う場合、ファイルごとにスクリプトを作成する必要があったことを考えると、非常に対照的です。\n\n### リモート\n\nもう1つの大きな変化は、リモートリポジトリの省略記法が導入されたことです。すでにGitからリモートリポジトリを操作することはできましたが、変更をフェッチする際に毎回、対象のリポジトリのURLを指定する必要がありました。通常は同じリモートリポジトリと何度もやり取りを行うため、これはユーザーにとってかなり使い勝手の悪い仕様でした。\n\n現在のremoteコマンドの仕組みはご存知だと思いますが、当時の仕組みはまだ大きく異なっていました。リモートリポジトリを管理するための`git-remote(1)`コマンドはまだ存在しておらず、リモートリポジトリの情報は`.git/config`ファイルに保存すらされていませんでした。実のところ、バージョン0.99.2でremoteコマンドが最初に導入された際、Gitにはconfigファイル自体*ありませんでした*。\n\n代わりに、`.git/branches`に直接ファイルを書き込んでリモートリポジトリの設定を行う必要がありました。今となってはあまり直感的な方法とは思えません。しかしながら、この仕組みは今でも動作します。\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nそれだけではなく、その直後にGitバージョン0.99.5でディレクトリ名が「remotes」に変更されたため、現在のGitクライアントではリモートリポジトリの設定方法が全部で3つあります。\n\nおそらく多くの方は、`.git/branches`も`.git/remotes`も使ったことがないと思います。これらはそれぞれ、2005年、および2011年以降、非推奨化されています。また、最終的にこれらのディレクトリは、Git 3.0で削除される予定です。\n\n## Gitのブランディング\n\n2007年に、Gitの最初のロゴが作成されました。これは、単に3つの緑のプラス記号の上に3つの赤いマイナス記号が配置された構成（`git diff`の出力がどのように見えるかを表していた）だったため、ロゴと呼べるかどうかについては、議論の余地があります。\n\n![`git diff`の出力がどのように見えるかを表し、3つの緑のプラス記号の上に3つの赤いマイナス記号が配置されている](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nそれから少し経った2008年に、ウェブサイト[git-scm.com](https://git-scm.com)が公開されました。\n\n![2026年時点でのgit-scm.comのランディングページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\n2012年に、Scott Chacon氏とJason Long氏によって、Gitのウェブサイトは[リニューアル](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/)されました。ご覧のように現在の外観にかなり近くなりました。\n\n![2012年にリニューアルされたGitウェブサイト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\n再デザインされたウェブサイトには、Jason Long氏がデザインし、今でも使用されている新しい赤橙色のロゴが目立つように掲載されていました。\n\n![Gitロゴ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nGit 1.0のリリース時点で、すでに現在のGitとかなり同じようになってきたため、ここでGitの歴史をたどる旅の歩みをGit 2.0まで進めます。Git 1.0の約10年後にリリースされたこのバージョンは、中央ワークフローに後方互換性のない変更を意図的に含めた最初のリリースでした。\n\n### `git-push(1)`のデフォルトの動作\n\nこのリリースで最も混乱を招いたのは、間違いなく`git-push(1)`のデフォルトの動作が変更されたことです。\n\nリモートリポジトリへのプッシュ時に何をプッシュするかを具体的に指定しなかった場合、Gitは以下のいずれかのアクションを取る可能性がありました。\n\n- Gitは何も実行せず、何をプッシュするか具体的な情報をユーザーに要求する。\n- その時点でチェックアウトされているブランチをプッシュする。\n- その時点でチェックアウトされているブランチをプッシュする（ただし、リモート側に対応するブランチがあることを確認できた場合に限る）。\n- リモート側に対応するブランチが存在する全ブランチをプッシュする。\n\n現在のGitは、いわゆる「シンプル」な手法を採用しており、上記の3番目のアクションを行います。しかしながら、Git 2.0より前のバージョンにおけるデフォルトの動作は、「マッチング」手法を使用した上記の最後のアクションでした。\n\n「マッチング」手法は、現在採用されている手法と比べて、はるかにリスクがありました。プッシュする前に毎回、リモート側に対応するブランチがあるすべてのローカルブランチをプッシュしても問題がないか確認する必要がありました。そうしないと、意図せずに変更がプッシュされてしまう可能性がありました。そこでリスクを軽減し、Gitを使い始めたばかりのユーザーにとって使い勝手をよくするために「シンプル」手法が採用されました。\n\n### `git-add(1)`\n\nもう1つの大きな変化は、削除された追跡済みファイルに対する`git-add(1)`のデフォルトの動作が変更されたことです。Git 2.0より前のバージョンでは、`git-add(1)`は削除済みのファイルを自動的にステージングしませんでした。そのため、コミットに含めるには、`git-rm(1)`を使用して削除済みのファイルを1つずつ手動で追加する必要がありました。Git 2.0ではこの動作が変更され、`git-add(1)`を実行すると、削除済みのファイルもインデックスに追加されるようになりました。\n\n## Gitコミュニティの業績を称えよう\n\nおそらくみなさんGitを日々活用しているかと思いますので、Gitの現在の仕組みについて細かくはここでは取り上げません。まだ活用していない方向けには、利用開始に役立つチュートリアルが多数用意されています。現在の仕組みについて説明する代わりに、Git誕生から20年経った今でも機能するように取り組んでくださったGitコミュニティの業績を称えたいと思います。\n\nGitは、その歴史の中で以下の実績を達成してきました。\n\n- Git 2.49のリリース時点での累計コミット件数、56,721件\n- 2,000人の個人のコントリビューターによるコントリビュート\n- 公開されたメジャーリリース件数、60件\n\nまた、Gitプロジェクトは[Google Summer of Code（GSOC）](https://summerofcode.withgoogle.com/)や[Outreachy](https://www.outreachy.org/)にも参加しており、新たなコントリビューターが着実に増えています。このような新たなコントリビューターのおかげで、Gitプロジェクトは長期的に健全な状態を保てます。\n\nこの場を借りて、すべてのコントリビューターに心からお礼申し上げます。みなさんのコントリビュートのおかげで、Gitが実現しました。\n\n## 今後の展開\n\nGitがバージョン管理システムの競争で事実上勝利を収めたと言っても、異論はほとんどないでしょう。Gitは大きな市場シェアを占めており、Git以外のバージョン管理システムを使用しているオープンソースプロジェクトはほとんどありません。そう考えると、Gitが多くのことを正しく成し遂げてきたことは明らかです。\n\nとは言っても、Gitの開発は完結したわけではなく、依存として多くの課題が残されています。その例が、以下のような技術的な課題です。\n- 古くなったコードベースのモダナイゼーション  \n- 拡大し続けるモノレポのサイズに合わせたスケーリング  \n- サイズの大きいバイナリファイルの処理の改善\n\nそれとは別に、以下のような社会的な課題もあります。\n- Gitの使いやすさの向上  \n- 長期にわたってプロジェクトの健全性を確保することを目的とした、Gitコミュニティの育成  \n\n取り組むべき作業は常にあります。次の20年もGitが素晴らしいバージョン管理システムであり続けられるよう、私たちGitLabもコントリビュートできることを誇りに思います。\n\n## Git関連のその他のリソース\n\n- [Gitの生みの親であるLinus Torvalds氏と20周年を祝う](https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n- [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)  \n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)",[9,678],{"slug":746,"featured":91,"template":681},"journey-through-gits-20-year-history","content:ja-jp:blog:journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History","ja-jp/blog/journey-through-gits-20-year-history.yml","ja-jp/blog/journey-through-gits-20-year-history",{"_path":752,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":753,"content":759,"config":765,"_id":767,"_type":14,"title":768,"_source":16,"_file":769,"_stem":770,"_extension":19},"/ja-jp/blog/mastering-the-basics-of-git-push-tag",{"title":754,"description":755,"ogTitle":754,"ogDescription":755,"noIndex":6,"ogImage":756,"ogUrl":757,"ogSiteName":669,"ogType":670,"canonicalUrls":757,"schema":758},"git pushタグの基本を徹底攻略","git pushコマンドで、他の開発者とバージョンやリリース情報、マイルストーンをタグを使用して共有する方法とコツをご紹介。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665200/Blog/Hero%20Images/gitpush.jpg","https://about.gitlab.com/blog/mastering-the-basics-of-git-push-tag","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"git pushタグの基本を徹底攻略\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-12-19\",\n      }",{"title":754,"description":755,"authors":760,"heroImage":756,"date":762,"body":763,"category":10,"tags":764},[761],"GitLab","2024-12-19","gitを使った開発で最もよく利用するコマンドのひとつ`git push`。ローカルリポジトリのオブジェクトをリモートリポジトリに送信して更新を行うコマンドです。タグ機能と組み合わせて開発途中の特定の時点に参照しやすいように名前をつけておくことで、後から遡って異なるバージョンを比較できます。この記事では`git push`コマンドの基本について解説していきます。\n\n- git pushタグとは？\n- gitタグを使うメリットとは？\n- gitタグの種類\n- よく使うgitタグ   \n- git pushコマンドでコミットやタグをプッシュする方法\n- git pushとgit pushタグを使うためのベストプラクティス\n- GitLabでgitタグを使う\n- git pushタグのFAQ\n\n## git pushタグとは？\n`git push` タグとは、リポジトリ内でタグづけされたコミットを、リモートリポジトリにプッシュするためのコマンドです。ローカルで作成したタグをリモートリポジトリに送信し、複数人で特定のバージョンやマイルストーンを共有するのに有用です。\n\n例えば、`v1.0`というタグを`origin`という名前のリモートリポジトリにプッシュするには下記のように記載します。\n\n    git push origin v1.0\n\n## gitタグを使うメリットとは\ngitタグとは、本のしおりのようにプロジェクト履歴の中で特定のコミットに名前をつけられる機能です。特定のタグをタグ名で簡単に参照できることが最大のメリットで、新バージョンのリリースや、大規模な変更を実施する前のコードベースなど、その時点まで戻って参照する可能性のあるコミットにタグをつけて管理します。\n\n## gitタグの種類\ngitのタグには、主に2つの種類があります。\u003Cbr>\u003Cbr>\n\n1. 軽量タグ（Lightweight Tags）:\n\n軽量タグは、コミットに名前をつけるだけの単純なタグです。基本的にはコミットの名前とポインターですが、関連するコミットへのクイックリンクの作成などに適しています。軽量タグの作成は下記の通りです。\n\n    git tag TAG_NAME\n\nバージョン管理のタグの場合は、次のように名付けます。\n\n    git tag v1.0\n\n2. アノテーション（注釈付）タグ：\n\nアノテーションタグは、タグの作成者、メールアドレス、作成した日やメッセージなど追加のメタデータも保存されます。アノテーションタグを作成するには、`-a`でタグを作成し、`-m`を指定するとコメントも同時に指定することができます。\n\n    git tag -a TAG_NAME -m \"Comments\"\n\nアノテーションタグは、チームで共有すべきリリースやバージョン管理に追加の情報を含めたいときに広く使われます。\n\n## よく使うgitタグ\n### タグを一覧で確認する\n\nリポジトリに保存されたタグを一覧表示します。\u003Cbr>\n\n    git tag\n\nワイルドカード表現を使って絞り込むこともできます。\n\n    git tag -l *SEARCH WORD*\n\n\u003CH3>タグの内容を確認する\u003C/H3>\n\nタグの内容を確認する場合は`git show`を使います。\u003Cbr>\n\n    git show TAG_NAME\n\nこれにより以下の情報が取得できます。\n- Commit：コミット番号\n- Author：実行したユーザー名\n- Date：実行した日時\n\n### 作ったタグを削除する\nタグを削除するには`git tag`コマンドのオプション`-d`を指定します。削除した後、一覧から消えているか確認しましょう。\u003Cbr>\u003Cbr>\n\n    git tag -d TAG_NAME\n\n## git pushコマンドでコミットやタグをプッシュする方法\n`git push` コマンドを使ってコミットやタグをプッシュする方法は以下の通りです。\n\u003CH3>コミットをリモートリポジトリにプッシュする\u003C/H3>\n\n    git push REMOTE_NAME BRANCH_NAME\n\nリモート名）origin\u003Cbr>\nブランチ名）mainの場合には\n\n    git push origin main\n\nとなります。\n\n\u003CH3>タグをプッシュする\u003C/H3>\n\n    git push REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nタグ名）v1.0の場合、\n\n    git push origin v1.0\n\nとなります。\n\n## git pushとgit pushタグを使うためのベストプラクティス\n `git push` と `git push` タグを使用する際、特にチームのバージョン管理に使われている場合に避けた方が良いことがあります。それは、一度プッシュしたタグの名前を変更することです。逆にまだプッシュしていないタグは、\u003Ccode>git tag -f TAG_NAME Commit#\u003C/code>で上書きして、正しい名前にしてからプッシュするようにしましょう。またチーム内で管理されるタグ名は、一意に決定されその存在が担保されることが何より重要になるので、プッシュする前にはタグ名を十分確認するようにしましょう。\n\n## GitLabでgitタグを使う\n簡単にgitタグを使う方法をお探しの方におすすめなのが、プラットフォームを使用することです。中でもGitLabはリモートリポジトリのホスティング、インターフェースの提供、変更内容のコードレビュー、[プッシュされたコードの自動ビルド、テスト、デプロイまで実施](https://about.gitlab.com/ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices/) できます。また、プロジェクトやリポジトリごとにアクセス権を細かく管理することができるため、セキュリティの確保も可能です。\u003Cbr>\u003Cbr>\n\n[バージョン管理に使える](https://about.gitlab.com/ja-jp/solutions/source-code-management/)GitLabの無料トライアルは[こちら](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)からお申し込みいただけます。\u003Cbr>\u003Cbr>\n\n\u003CH2>git pushタグのFAQ\u003C/H2> \n\u003CH3>gitのタグを使うメリットは？\u003C/H3>\ngitタグの最大のメリットは特定のコミットをタグ名で簡単に参照できることです。新バージョンのリリースや、大規模な変更を実施する前のコードベースなど、その時点まで戻って参照する可能性のあるコミットにタグをつけて管理します。\n\n\u003CH3>gitタグのつけ方は？\u003C/H3>\nタグをつけるには下記の基本コードを使います。\n\n    git push REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nブランチ名）mainの場合には\n\n    git push origin main\n\nとなります。\n\n### プッシュしたタグを削除する方法は？\nプッシュしたタグを削除するコマンドは、\u003Cbr>\n\n    git push –delete REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nタグ名）v1.0の場合、\n\n    git push –delete origin v1.0\n\nとなります。\n\n### git pushタグを使うメリットは？\nコミットにタグをつけてリモートリポジトリに保存することで、ソフトウェアのリリース情報や作成者・作成日・コメントを保存できます。逆に、 [git fetchまたはgit pull](https://about.gitlab.com/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull/) を使用してリモートからタグを取得し、ローカルリポジトリに反映させることもできます。大幅な修正やベンチマークとなるリリースが行われた場合にも直近のバージョンや該当のリリースに戻って特定時点でのコミットを確認できます。\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[678,9],{"slug":766,"featured":91,"template":681},"mastering-the-basics-of-git-push-tag","content:ja-jp:blog:mastering-the-basics-of-git-push-tag.yml","Mastering The Basics Of Git Push Tag","ja-jp/blog/mastering-the-basics-of-git-push-tag.yml","ja-jp/blog/mastering-the-basics-of-git-push-tag",{"_path":772,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":773,"content":779,"config":789,"_id":791,"_type":14,"title":792,"_source":16,"_file":793,"_stem":794,"_extension":19},"/ja-jp/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"title":774,"description":775,"ogTitle":774,"ogDescription":775,"noIndex":6,"ogImage":776,"ogUrl":777,"ogSiteName":669,"ogType":670,"canonicalUrls":777,"schema":778},"共同開発プログラム：ユーザーとともに築くGitLab","Thales社、Scania社、Kitware社などの組織がどのようにGitLabのエンジニアと連携し、コミュニティ全体に利益をもたらす重要な機能の開発にコントリビュートしているかをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","https://about.gitlab.com/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"共同開発プログラム：ユーザーとともに築くGitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2025-01-30\",\n      }",{"title":774,"description":775,"authors":780,"heroImage":776,"date":782,"body":783,"category":784,"tags":785,"updatedDate":788},[781],"Fatima Sarah Khalid","2025-01-30","過去一年間で、800人以上のコミュニティメンバーによって、GitLabに3,000以上のコントリビュートが寄せられました。コントリビューターにはThales社やScania社などの世界的な企業のチームメンバーも含まれており、GitLabの[共同開発プログラム](https://about.gitlab.com/community/co-create/)を通じてGitLabの未来を共に築いています。このプログラムでは、GitLabユーザーがGitLabのエンジニアと直接協力し、プラットフォームに価値ある機能を提供しています。\n\nワークショップやペアプログラミング、継続的なサポートを通じて、プログラム参加者はGitLabのアーキテクチャやコードベースに触れながら、機能改善や問題解決に取り組みます。\n\nThales社のオープンソースアドボケートであるSébastien Lejeune氏は次のように述べています。「共同開発プログラムを通じた経験は本当に素晴らしいものでした。GitLabのコントリビューターサクセスチームのエンジニアと話し合いを始めてから、GitLabのリリースに反映されるまでわずか2か月でした」\n\nこの記事では、GitLabユーザーが共同開発プログラムを通じて、どのようにアイデアをコードとして実装し、その過程で学びながらコントリビュートしているのかをご紹介します。\n\n## 共同開発プログラムについて\n\n[GitLab Development Kit（GitLab開発キット、略してGDK）](https://gitlab.com/gitlab-org/gitlab-development-kit)は、コントリビューターがGitLabではじめて開発を行う際に役立ちます。「新しいコントリビューターにアドバイスするとしたら、GDKで何かを壊すことはできないということです。変更を加えてうまくいかない場合は、元に戻したり、最初からやり直したりすることができます。GDKの良さは、環境を気にすることなく、調整したり、テストしたり、学んだりできることです」とGitLabのコントリビューターサクセスチームでシニアフルスタックエンジニアを務めるRaimund Hookは言います。\n\n共同開発プログラムに参加する各組織は、コントリビュートのプロセス全体を通じて次のようなサポートを受けられます。\n\n- __テクニカルオンボーディングワークショップ__：GDKのセットアップやGitLabのアーキテクチャを理解するための専用セッション\n\n- __1対1のエンジニアリングサポート__：GitLabエンジニアとのペアプログラミングや技術的なアドバイス\n- __アーキテクチャの詳細解説__：各組織がコントリビュートしている課題に関連する特定のGitLabコンポーネントに焦点を当てたセッション\n- __コードレビューのサポート__：マージリクエストの手順に関する詳細なフィードバックとガイダンス\n- __定期的なチェックイン__：進捗状況を確認し、あらゆる課題に対処するための継続的なコラボレーション\n\nこの仕組みにより、GitLabのコードベースやRuby/Goプログラミング言語になじみのないチームでも、効果的にコントリビュートできるようになります。Kitware社のJohn Parent氏は次のように語ります。「GitLabを見たことも、使ったこともない人は、複数のプロジェクトにまたがる洗練されたアーキテクチャと膨大なコードを見て圧倒されるかもしれません。共同開発プログラムでは、社内研修で何週間もかけて学ぶ内容を、的を絞った短期集中コースとして習得できます」\n\nこのプログラムの成果は、新機能の提供にとどまりません。GitLabとそのユーザーコミュニティの間に長期的な関係を築くことにもつながっています。「情熱を持ってGitLabの開発にコントリビュートしてくださるユーザーのみなさまを見て、私たちエンジニアも刺激をもらっています。ユーザーは『GitLab流』を学び、エンジニアはユーザーがGitLabの未来を形作る姿勢を目の当たりにするのです」とGitLabのプリンシパルエンジニアであるShekhar Patnaikは述べています。\n\n## Thales社のコントリビュートによるプロジェクトUXの向上\n\nThales社は、GitLabの空のプロジェクトUIの改善として、単に機能リクエストを提出するのではなく、自らソリューションを構築しました。同チームのコントリビュートの焦点は、インターフェイスをタブ形式にしてSSH/HTTPS設定を簡素化し、コードスニペットのコピー/ペースト機能を追加することで、新しいプロジェクトのセットアップを効率化することでした。これらの変更は、デベロッパーのワークフローに大きな影響を与えました。\n\nまた、このチームの影響はUXの改善だけにとどまりませんでした。Thales社でエッジクラウドアプリケーションの博士研究員を務めるQuentin Michaud氏は、GDKの改善にもコントリビュートしました。Arch LinuxのパッケージメンテナーでもあるMichaud氏の専門知識により、GDKのドキュメントが改善され、コンテナ化の取り組みが進められたことで、新しいコントリビューターがより簡単に開発を始められるようになりました。\n\nMichaud氏は「オープンソースの経験があったおかげで、Linuxディストリビューション向けのGDKサポートを改善する際に役立ちました。パッケージのバージョン管理ドキュメントを改善する過程で、GitLabのコントリビューターサクセスチームもGDKのコンテナ化に取り組んでいることを知りましたが、双方の取り組みが交わる瞬間を見ることができたのは非常に印象的でした。オープンソースのコラボレーションがより優れたソリューションを生み出すことを実感した瞬間でした」と語ります。\n\nThales社のチームにとってポジティブな経験であったため、Lejeune氏は現在、共同開発プログラムを「オープンソースコントリビュートによる投資対効果をマネージャーに示す強力な事例」として活用しています。\n\n## Scania社のコントリビュートによるパッケージサポートの強化\n\nGitLabの高度なパッケージサポートの必要性を理解したScania社は、自らコントリビュートして、それを構築する機会を見出しました。\n\n「私たちは長年GitLabを使用し、組織内でオープンソースを積極的に推進してきました。共同開発プログラムのおかげで、オープンソースに直接コントリビュートする有意義なアプローチが可能になりました」とScania社のソリューションアーキテクトであるPuttaraju Venugopal Hassan氏は語ります。\n\nチームはまず、コードベースとレビューのプロセスに慣れるために小さな変更から着手し、徐々に大きな機能開発へと進みました。「共同開発プログラムで最も充実感を感じたのは、プロセス全体を振り返り、どれだけ成長したかを実感できたことです」とScania社のソフトウェアデベロッパーであるOcéane Legrand氏は振り返ります。「最初は調査や小さな変更から取り組み、次第により大きなタスクへとステップアップしていきました。その進歩を目の当たりにできてうれしく思います」\n\nScania社のコントリビュートには、パッケージレジストリのバグ修正や、Conanパッケージレジストリ機能の強化が含まれます。これにより、Conanパッケージレジストリは一般公開（GA）に向けた準備が進み、Conanバージョン2のサポートも実装されました。Scania社の取り組みとGitLabとのコラボレーションは、GitLabのパッケージレジストリ機能を大幅に改善する上で、共同開発プログラムがいかに有効であるかを示しています。\n\n「共同開発プログラムを開始してすぐに、非常に体系的に構築されていることを実感しました。コントリビュートに必要なことをすべて学べるトレーニングセッションがありましたし、GitLabのエンジニアとの1対1のセッションでは、GitLabのパッケージアーキテクチャについて深く理解することができ、コントリビュートをスムーズに進められました」とScania社のソフトウェアデベロッパーであるJuan Pablo Gonzalez氏は語ります。\n\nこのプログラムの成果はコードのみにとどまりません。プログラム参加者は、コントリビュートを通じて貴重なスキルを身につけます。[GitLab 17.8リリース](https://about.gitlab.com/ja-jp/blog/gitlab-17-8-release/)では、Legrand氏とGonzalez氏がともにGitLab MVPに選ばれました。Legrand氏は、オープンソースでの作業がGitLabとScania社の両方に与える影響について言及し、自身とチームの新たなスキル習得にもつながったと述べています。「共同開発プログラムを通じてコントリビュートすることで、Rubyやバックグラウンドマイグレーションの知識など、新たなスキルを習得できました。Scaniaの所属チームでアップグレード作業中に問題が発生した際、共同開発プログラムですでに同じ問題を経験していたため、トラブルシューティングを手伝うことができました」\n\n## Kitware社のコントリビュートによる高性能計算（HPC）向け認証の最適化 \n\nKitware社は、国立研究所との協力で培った専門知識を活かし、GitLabの認証フレームワークの改善にコントリビュートしました。このコントリビュートには、GitLabのOAuth2デバイス認証付与フローのサポートの追加や、新しいデータベーステーブル、コントローラー、ビュー、ドキュメントの実装が含まれます。これにより、GitLabの認証オプションが強化され、ブラウザを持たないデバイスや入力機能が限られたデバイスでも利用しやすくなりました。\n\n「共同開発プログラムは、外部コントリビューターとしてGitLabにコントリビュートする最も効率的で効果的な方法です。デベロッパー同士のペアリングセッションを通じて、1人で作業していたら見逃していたかもしれない、より優れた実装方法を見つけることができました」とKitware社の研究開発エンジニアであるJohn Parent氏は話します。\n\n長年にわたりオープンソースにコントリビュートしてきたKitware社は、GitLabの開発手法を特に高く評価しています。「GitLabほどの規模であれば、既成のソリューションに頼ることはないだろうと思っていましたが、社内で独自のソリューションを開発するのではなく、Rubyの依存関係を取り入れているのを見て素晴らしいと思いました。C++の世界ではパッケージマネージャーがほとんど使われないため、このようなアプローチを目にし、そのシンプルさを実感できたのは新鮮でした」とParent氏は述べます。\n\n## 共に築く未来：共同開発のメリット\n共同開発プログラムは、双方に価値をもたらします。「このプログラムは、GitLabのエンジニアとユーザーの間のギャップを埋める役割を果たしています。ユーザーと一緒に取り組む中で、日々の課題や、GitLabのどの部分を重視しているのか、どこに改善の余地があるのかを直接聞くことができます。ユーザーがGitLabの開発に積極的に関わろうとしている姿には感銘を受けます」と、GitLabのスタッフバックエンドエンジニアであるImre Farkasは説明します。\n\nこの協力的なアプローチには、GitLabの開発スピードを加速させる効果もあります。GitLabのプリンシパルエンジニアであるShekhar Patnaikは次のように述べています。「共同開発を通じて、ユーザーはGitLabのロードマップを前進させる手助けをしてくれています。彼らのコントリビュートにより、重要な機能をより早く提供できるようになり、すべてのユーザーにとって大きなメリットとなっています。このプログラムが拡大するにつれて、実際にその機能を必要としているユーザーと共に開発を進めることで、最も重要な機能の開発をさらに加速できる可能性があります」\n\n## 共同開発を始める\n機能リクエストを実現しませんか？Thales社のようにGitLabのUIを強化したい、Scania社のようにパッケージサポートを充実させたい、またはKitware社のように認証機能を改善したいとお考えなら、共同開発プログラムへご参加ください。本プログラムでは、価値あるオープンソースの経験を積みながら、GitLabの未来を積極的に形作りたい組織を歓迎します。\n\n共同開発プログラムへの参加について、詳しくはGitLabの担当者にお問い合わせいただくか、[共同開発のページ](https://about.gitlab.com/community/co-create/)をご覧ください。\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n","customer-stories",[786,9,787],"contributors","customers","2025-03-10",{"slug":790,"featured":91,"template":681},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab","content:ja-jp:blog:the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","The Co Create Program How Customers Are Collaborating To Build Gitlab","ja-jp/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","ja-jp/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"_path":796,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":797,"content":803,"config":813,"_id":815,"_type":14,"title":816,"_source":16,"_file":817,"_stem":818,"_extension":19},"/ja-jp/blog/the-ultimate-guide-to-sboms",{"title":798,"description":799,"ogTitle":798,"ogDescription":799,"noIndex":6,"ogImage":800,"ogUrl":801,"ogSiteName":669,"ogType":670,"canonicalUrls":801,"schema":802},"SBOMとは？セキュリティとの関連性を含めた完全ガイド","SBOM（ソフトウェア部品表）がソフトウェア開発の管理やセキュリティに与える影響等について様々な観点から学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SBOMとは？セキュリティとの関連性を含めた完全ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }",{"title":798,"description":799,"authors":804,"heroImage":800,"date":806,"body":807,"category":808,"tags":809,"updatedDate":812},[805],"Sandra Gittlen","2022-10-25","急速に進化を遂げる今日のデジタル環境では、ソフトウェアサプライチェーンにおけるアプリケーション・セキュリティの重要性がかつてないほど高まっています。アップストリームの依存関係をソフトウェアに統合するには、透明性とセキュリティ対策が必須ですが、その実装と管理は思った以上に複雑です。そこで、今回のテーマであるソフトウェア部品表（SBOM）の出番となります。\n\nSBOM（Software Bill of Materials）、日本語でソフトウェア部品表は、ソフトウェアの構成部品を包括的にリスト化したもので、開発ライフサイクル全体で使用されるライブラリ、ツール、プロセスの複雑な関係性を明確にします。また、脆弱性管理ツールと組み合わせることで、ソフトウェア製品に潜在する脆弱性を明らかにするだけでなく、戦略的リスク軽減も可能にします。本ガイドは、SBOMの重要な役割、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)戦略におけるその中心的位置付け、そしてアプリケーションのSBOM健全性を向上させるための戦略について深く掘り下げます。そして、潜在的脅威に満ちた環境における組織のサイバーセキュリティ体制を強化することを目的としています。\n\n## 目次\n\n1. SBOMとは？\n2. SBOMが重要な理由 \n3. SBOMデータ交換標準フォーマットの種類\n4. SBOMとソフトウェアの脆弱性管理を組み合わせるメリット\n5. Gitlabと動的なSBOM\n   1. SBOMの生成と管理の拡大\n   2. SBOMの統合とインジェスト\n   3. SBOMの健全性を他持つための対策を迅速に行うには  \n   4. 継続的なSBOM分析\n   5. SBOMの信頼構築\n6. Gitlab SBOM機能の今後の進化\n7. SBOMを始めましょう\n8. SBOMに関するFAQ  \n   1. SBOMとは？\n   2. なぜSBOMは重要なのですか？\n   3. SBOMのデータ交換に使用される標準フォーマットは何ですか？\n   4. SBOMに対するGitLabのアプローチはどのようなものですか？\n   5. SBOMを組織に導入するにはどうすれば良いですか？\n\n## SBOMとは？\n\nSBOMとは、ソフトウェアを作るために使用された[コンポーネントをリスト化](https://www.cisa.gov/sbom#)（外部サイト）したものです。コンポーネント間の関係性も階層的に示します。このリストには、ソフトウェア・アーティファクトの開発、構築、およびデプロイに使用されるライブラリ、ツール、およびプロセスに関する重要情報も含まれます。\n\nSBOMの概念は10年以上前から存在しています。しかし、米国ホワイトハウスが2023年に発表した国家サイバー戦略を実施する一環として、CISA（米国土安全保障省の外局機関「サイバーセキュリティー・インフラセキュリティー庁」）の「[セキュア・バイ・デザイン（Secure by Design）](https://www.cisa.gov/securebydesign)（外部サイト）」フレームワークはソフトウェアメーカーに対して、この原則を採用、サイバーセキュリティを製品に統合するよう促しています。加えて同政府は、公共部門に販売するアプリケーションデベロッパーにソフトウェア・パッケージに SBOM を含めるよう促すベストプラクティスも発表しました。民間企業もこれに追随し、SBOMは普及への道を進んでいます。また日本でも、同年度に「[ソフトウェア管理に向けたSBOM導入に関する手引](https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html)（外部サイト）」が経済産業省により作成されました。\n\nSBOMは専用のソフトウェアで個別に作成されることが多いものの、GitLabのようなプラットフォーム型のソリューションでは、DevSecOpsワークフローの初期段階からSBOMの生成が完全に組み込まれており、重要な役割を果たすようにしています。\n\n![サプライチェーンセキュリティとシステム開発ライフサイクル](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n## SBOMが重要な理由\n\n現代のソフトウェア開発は、より迅速かつ効率的な方法でアプリケーションをリリースすることに注力しています。そのためデベロッパーは、オープンソースのリポジトリやプロプライエタリ（専有）パッケージのコードをアプリケーションに組み込むことがあります。Synopsys社が発行した「2024年度オープンソースセキュリティおよびリスク分析レポート」によると、2023年に17の業界にわたる1,000以上の商用コードベースを分析した結果、コードベース全体の96%にオープンソースが含まれ、リスク評価されたコードベースの84%に脆弱性が含まれていたことが明らかになりました。\n\n未知のリポジトリを使用することは、ハッカーに悪用される脆弱性を含むコードを取り込む可能性を高めます。実際、2020年の[SolarWinds社への攻撃](https://cloud.watch.impress.co.jp/docs/topic/special/1359685.html)（外部サイト）は、彼らのOrion製品で使用されているパッケージに、悪意のあるコードが仕込まれており、これが実行されたことに端を発しています。この事件では、ソフトウェアサプライチェーン全体の顧客が重大な影響を受けました。また、多くの商用ソフトウェアベンダーに影響を与えたlog4jの脆弱性を含むその他の攻撃は、[ソフトウェアサプライチェーン全体のリスクを評価](https://about.gitlab.com/ja-jp/solutions/supply-chain/)できるよう、コンテナやインフラを含むアプリケーションの依存関係を綿密調査する必要性を確固たるものとしました。\n\nさらに、ソフトウェアのセキュリティ脆弱性を発見し修正するにはコストがかかることも、SBOMの必要性が高まっている理由の一つであり、同時にソフトウェアのサプライチェーン攻撃が企業の評判に与えるダメージも考慮すべき要素です。SBOMは依存関係の把握や、脆弱性や内部ポリシーに準拠していないライセンスの特定にも役立ちます。\n## SBOMデータ交換標準フォーマットの種類\n\nSBOMは、名前、バージョン、パッケージャーなどの情報の生成と解釈が自動化されることで、最も効果的に活用できます。これには、すべての関係者が標準的なデータ交換フォーマットを使用することが重要です。現在使用されている主なSBOMデータ交換標準フォーマットには、次の2つの種類があります:\n\n* [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/)（外部サイト）  \n* [SPDX](https://spdx.dev/)（外部サイト）\n\nGitLabは、SBOMの生成にCycloneDXを使用しています。この標準フォーマットは指示的で使いやすく、複雑な関係を簡素化し、特定や将来のユースケースに対応できる拡張性を備えています。さらに[cyclonedx-cli](https://github.com/CycloneDX/cyclonedx-cli#convert-command)（外部サイト）や[cdx2spdx](https://github.com/spdx/cdx2spdx)（外部サイト）は、CycloneDXファイルを必要に応じてSPDXに変換するためのオープンソースツールとして利用可能です。\n\n## SBOMとソフトウェアの脆弱性管理を組み合わせるメリット\n\nSBOMがDevSecOpsチームやソフトウェアの利用者にとって非常に有益な理由は次の通りです。\n\n* アプリケーションに含まれる追加のソフトウェアコンポーネントとその宣言場所が標準的なアプローチで理解できるため\n* アプリケーションの作成履歴を継続的に可視化し、サードパーティのコードの出所やホストリポジトリの詳細を含むため\n* ファーストパーティによる開発コードと採用されたオープンソースソフトウェアの両方に対して、深いレベルでセキュリティの透明性を提供できるため\n* SBOMが提供する詳細情報により、DevOpsチームが脆弱性を特定し、潜在的なリスクを評価し、それらを軽減することができるため\n* アプリケーション購入者が昨今求めている透明性を提供できるため\n\n## Gitlabと動的なSBOM\n\nSBOMを最大限活用するには、組織がSBOMを自動生成し、アプリケーションセキュリティスキャンツールと連携させ、脆弱性やライセンスをダッシュボードに統合することで内容を把握しやすくし、対応できるようにする必要があります。さらに、継続的に更新することが求められます。GitLabは、これらすべての要件をサポートしています。\n\n![ダイナミックSBOM管理](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### SBOM生成と管理の拡大\n\nオープンソース、サードパーティ、および専有ソフトウェアを網羅した正確で包括的なSBOMを所有することが、内部ポリシーや規制に準拠する上で重要です。そして、各コンポーネントや製品バージョンのSBOMを効果的に管理するには、SBOMの作成、統合、検証、承認を効率的に行うためのスムーズなプロセス確立が必須です。GitLabの[依存関係リスト](https://gitlab-docs.creationline.com/ee/user/application_security/dependency_list/)機能は、既知の脆弱性およびライセンスに関するデータを一元化されたユーザーインターフェース内で表示します。依存関係スキャンレポートの一部として依存関係グラフ情報も生成され、ユーザーは個々のプロジェクトや複数のプロジェクトにわたる依存関係やリスクに関する包括的なインサイトを得ることができます。また、CIパイプライン内でJSON形式のCycloneDXアーティファクトの生成が可能です。このAPIは、SBOM生成において、より柔軟でカスタマイズ可能なアプローチを提供します。さらにSBOMは、UIや特定のパイプライン、プロジェクト、またはGitLab APIを通じてエクスポートすることができます。\n\n### SBOMの統合とインジェスト\n\nGitLabは、サードパーティのSBOMを取り込むことができ、サードパーティによる開発コードと採用されたオープンソースソフトウェアの両方に対して、深いレベルでセキュリティの透明性を提供します。。Gitlabの[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)ジョブを使うことで、複数のCycloneDX SBOMをシームレスに統合し、1つのSBOMにまとめることもできます。\n\n各SBOMのCycloneDXメタデータに含まれるビルドやロックファイルの場所などの実装固有の詳細を使用し、統合ファイルから重複情報が削除されます。またこのデータは、SBOM内のコンポーネントに対するライセンス情報および脆弱性情報が追加されることで自動的に強化されます。\n\n### SBOMの健全性を保つための対策を迅速に行うには\n\n高品質な製品を迅速に構築するには、対策可能なセキュリティ上の問題を検出し、デベロッパーがその中で最も影響の大きい脆弱性に対処できるようにする必要があります。GitLabはソースコード、コンテナ、依存関係、実行中アプリケーションにおける[脆弱性をスキャン](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html)することで、サプライチェーンのセキュリティを強化します。また、静的アプリケーションセキュリティテスト（SAST）、動的アプリケーションセキュリティテスト（DAST）、コンテナスキャン、ソフトウェア構成分析（SCA）機能など、さまざまなセキュリティスキャン機能を提供し、進化する脅威ベクトルに対し、全方位的な防御を実現します。GitLabのAI搭載機能「GitLab Duo脆弱性の説明」は、デベロッパーやセキュリティエンジニアが脆弱性をより理解し効率的に修正できるようサポートします。具体的には、特定の脆弱性に関する説明、その悪用可能性、そしてこれが最重要ですが、修正方法の提案を行います。「GitLab Duo 脆弱性の修正」と組み合わせることで、DevSecOpsチームはたった数回のクリックで脆弱性を特定、分析、修正することができます。\n\nまた、本プラットフォームは、新たに検出された脆弱性に基づいて、新しいポリシーの作成や[コンプライアンスの強制](https://docs.gitlab.com/ee/administration/compliance.html)もサポートしています。\n\n### 継続的なSBOM分析\n\nGitLabの継続的な脆弱性スキャンは、パイプラインの実行に関わらず、コンテナスキャン、依存関係スキャン、またはその両方が有効になっている全プロジェクトにに対してスキャンをトリガーします。新しい共通脆弱性識別子（CVE）が米国国立脆弱性データベース（NVD）に報告された場合、ユーザーが最新フィードを取得するためにパイプラインを再実行する必要はありません。\n\nGitLabの脆弱性調査チームが、GitLabのアドバイザリ・データベースにそれらの脆弱性情報を追加し、自動的にGitLabに脆弱性として報告されます。このように、最新の情報がリアルタイムで更新される仕組みから、GitLabのSBOMが本質的に動的であることが分かります。\n\n### SBOMに対する信頼構築\n[コンプライアンス機能](https://about.gitlab.com/ja-jp/solutions/compliance/)を必要とする組織は、GitLab Runnerによって生成されたすべてのビルドアーティファクトの証明書を作成できます。このプロセスでは、GitLab Runner内で証明書を生成します。データを外部サービスに引き渡すことないため、安全です。\n\n## Gitlab SBOM機能の今後の進化\n\n大手ソフトウェアベンダーやオープンソースソフトウェアエコシステムを狙った集中的な攻撃が頻繁に発生しているため、ソフトウェアサプライチェーンのセキュリティは、サイバーセキュリティおよびソフトウェア業界において引き続き重要なトピックとなっています。確かにSBOM業界は急速に進化していますが、SBOMの生成方法、生成頻度、保存場所、分析方法、複雑なアプリケーション向けに複数SBOMを統合する方法、アプリケーションの健全性向上に際した活用方法等に関して、依然として懸念があります。\n\nGitLabはSBOMを、[ソフトウェアサプライチェーン戦略](https://about.gitlab.com/direction/supply-chain/)になくてはならないものと位置付け、新機能追加の計画を含め、DevSecOpsプラットフォーム内でSBOM関連機能の強化を継続しています。最近の改善点には、証明の自動化、ビルドアーティファクトのデジタル署名、外部で自動生成されたSBOMのサポートが含まれます。\n\nまた、GitLabはプラットフォーム内に堅牢なSBOM成熟度モデルを確立しており、これには自動SBOM生成、開発環境からのSBOM取得、アーティファクトのSBOM分析、SBOMのデジタル署名の推奨といったステップが含まれています。さらに今後のリリースでは、ビルドアーティファクトの自動デジタル署名機能も追加する予定です。\n## SBOMを始めましょう\n\nSBOMの需要は既に高まっています。政府機関はソフトウェアベンダー、連邦政府のソフトウェアデベロッパー、さらにはオープンソースコミュニティに対して、SBOM作成を推奨または義務付けるになってきています。\n\n> これら要件を先取りするなら、[Gitlab DevSecOpsプラットフォームで提供されている](https://about.gitlab.com/ja-jp/)  \nGitLab Ultimate向けSBOM機能をご確認ください。\n\n## SBOMの基礎知識まとめとFAQ\n\n### SBOMとは？\n\nSBOMとはソフトウェア部品表のことであり、ソフトウェアの作成、ビルド、デプロイに使用されたすべてのコンポーネント、ライブラリ、ツールを一覧にして詳しく記載したものです。この包括的なリストは単なる一覧にとどまらず、コードの起源に関する重要な情報も含み、アプリケーションの構成や潜在的脆弱性をより深く理解するのに役立ちます。\n\n### なぜSBOMは重要なのですか？\n\nSBOMが重要な理由は次の通りです。\n\n* **依存関係のインサイト**: ソフトウェアの構成要素を理解することで、サードパーティ製コンポーネントに関連するリスクを特定し、軽減できます。  \n* **セキュリティの強化**: アプリケーションコンポーネントにの詳細を把握し、脆弱性を迅速に特定し、適切な対策を講じることができます。  \n* **規制遵守**: 規制やベストプラクティスにより、特に公共部門向けのソフトウェアパッケージに対して、SBOMが推奨または義務化されつつあります。  \n* **開発の効率化**: デベロッパーが、使用されているライブラリやコンポーネントに関するインサイトをSBOMから得ることで、開発サイクルの時間を節約し、エラーを減らすことができます。\n\n### SBOMのデータ交換に使用される標準フォーマットは何ですか？\n\n主なフォーマットは次の2つです。\n\n* **CycloneDX**: ソフトウェアコンポーネントとサポート間の複雑な関係を簡素化してくれるため、その使いやすさで知られており、特定のユースケースににも柔軟に対応します。  \n* **SPDX**: SBOMデータ交換のために、広く使われているもう一つのフレームワーク。ソフトウェア環境内のコンポーネントに関する詳細情報を提供します。\n\nGitLabはSBOMの生成にCycloneDXを採用しています。指示的でありながらも柔軟に拡張可能であり、将来にわたって使い続けられるためです。\n\n### SBOMに対するGitLabのアプローチはどのようなものですか？\n\nGitLabは動的なSBOMの作成として次の点を重視しています。\n\n* **自動生成**: ソフトウェアの構成に関する最新情報が常に反映されること  \n* **ツールとの統合**: リスク評価を徹底的に実施するために、脆弱性スキャンツールと連携すること  \n* **簡単な管理**: SBOMの取り込みや統合をサポートし、包括的な分析が可能なこと  \n* **継続的な分析**: プロジェクトを継続的にスキャンし、新たに発生する脆弱性を検出すること\n\n### SBOMを組織に導入するにはどうすれば良いですか？\n\nSBOMの導入を検討している組織向けに、GitLab Ultimateがあります。このパッケージは、DevSecOpsワークフロー内でSBOMの生成と管理を行うための強力なプラットフォームを提供します。GitLabのツールを活用することで、チームはコンプライアンスの確保、セキュリティの強化、開発プロセスの最適化を実現できます。\n\nSBOMへの需要が高まっている背景には、ソフトウェアのセキュリティとサプライチェーンの整合性への関心が増していることが挙げられます。SBOM機能を統合することで、組織は脆弱性に対する保護を強化し、新しい規制にも確実に対応できるようになります。\n\n> GitLab Ultimateを[無料](https://about.gitlab.com/ja-jp/free-trial/devsecops/)でお試しください。\n\n免責事項: このブログには、今後の製品、機能、および機能性に関する情報が含まれています。本ブログの情報はあくまで参考情報であり、購入やプランニングの際に情報の正確性を保証するものではありません。本ブログやリンクされたページに記載されている内容は、変更や未更新の可能性があります。製品、性能、および機能の開発、リリース、タイミングについては、予告なく内容を変更または削除する場合があります。\n\n\u003Cbr>\u003Cbr>\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","security",[808,810,811,9,187],"DevSecOps","performance","2025-06-10",{"slug":814,"featured":6,"template":681},"the-ultimate-guide-to-sboms","content:ja-jp:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","ja-jp/blog/the-ultimate-guide-to-sboms.yml","ja-jp/blog/the-ultimate-guide-to-sboms",{"_path":820,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":821,"content":827,"config":834,"_id":836,"_type":14,"title":837,"_source":16,"_file":838,"_stem":839,"_extension":19},"/ja-jp/blog/what-is-an-api",{"ogTitle":822,"schema":823,"ogImage":824,"ogDescription":825,"ogSiteName":669,"noIndex":6,"ogType":670,"ogUrl":826,"title":822,"canonicalUrls":826,"description":825},"APIとは？意味や利用のメリット、注意点、活用事例を徹底解説","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"APIとは？意味から注目のAPIゲートウェイまで徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-12-16\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780270/zrvqwpatilino8r9qm6e.jpg","API連携の仕組みやメリット、注意点を解説します。APIの種類や具体的な活用例も解説します。","https://about.gitlab.com/blog/what-is-an-api",{"heroImage":824,"body":828,"authors":829,"updatedDate":830,"date":831,"title":822,"tags":832,"description":825,"category":833},"ソフトウェア開発の領域においては「API」の活用が注目されています。APIを導入することで開発コストの削減や効率化、高度な機能実装などを実現できます。\n\nしかし、APIといってもさまざまな種類があり、意味や仕組みについて詳しく理解していない人も多いのではないでしょうか。\n\nこの記事では、API連携の仕組みやメリット、注意点を解説します。APIの種類や具体的な活用例も解説しているので、ぜひ参考にしてください。\n\n## 1. APIとは？\n\n![APIとは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780256/hjsyokgzh5fnvoux66iw.jpg)\n\nAPI連携は、その名の通り、APIを利用してアプリケーションの機能やデータを他のアプリケーションやシステムと連携させ、利用できる機能を拡張することです。事前登録したクレジットカードから自動決済されるシステムやカレンダー機能を使った自動予約システムなどにもAPIが使われています。\n\nAPI連携によって、プログラムをゼロから開発しなくても既存のソフトウェアやWebサービスが提供している機能を活用できるため、効率よく顧客体験を向上させることができるため、幅広い業界で活用が広がっています。\n\n## 2. API連携のしくみ\n\n![API連携の仕組み](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/lfvsw0gtwpzw0yjtats3.jpg)\n\nAPI連携はリクエスト（要求）とレスポンス（応答）で成り立っています。利用者側がリクエストし、提供元がレスポンスするという構図です。API連携のためには、APIの提供元は事前にどのようなリクエストに対してどのようなレスポンスを返すのかルールを設定しなければなりません。\n\n利用者はそのルールに則ったコードを書くことでAPIを連携させることができます。\n\n## 3. API利用のメリット\n\n![API利用のメリット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/noicynlcnefzltl7kxkn.jpg)\n\nAPIを自社のソフトウェア開発に導入することで以下のようなメリットを享受できます。\n\n* 開発の効率化とコスト削減\n* データの2次利用　\n* セキュリティの向上\n* ユーザーの利便性の向上\n\n### 3-1 開発の効率化とコスト削減\n\nAPIを活用することで開発の効率化とコスト削減を実現できます。通常新しい機能を開発する場合、要件定義から設計、開発、テスト、リリースまでを自社で実施する必要があります。そのプロセスにおいて自社が求める機能を提供しているAPIと連携すれば、複雑なプログラミングを要してゼロから開発する必要がなくなるため、スピーディーに高度な機能を実装することが可能です。\n\nなお、多くのAPIは無料で提供されていますが、有料のAPIであっても自社でゼロから開発した場合に発生するコストと比べれば、低コストで開発を進められるでしょう。\n\n### 3-2 データの2次利用\n\n無料で提供されているAPIも多くありますし、有償APIも自社で開発から構築まで取り組んだ場合にかかる費用と比べれば、低コストに抑えられることがほとんどです。\n\nAPI連携によって他社サービスのデータを利用できます。例えば、ECサイトで提供されているAPIなら、ECサイトが保有している商品情報や在庫状況、顧客情報などを取得して自社のマーケティング戦略に活かせるでしょう。また、SNS業界でもAPIの公開が進んでいます。ユーザーの投稿やトレンドを分析すれば、新しい機能開発にもつなげられます。\n\nAPIの活用により膨大なデータの収集から登録、更新まで行う必要がないため、業務効率化や情報の信頼性向上が期待できます。\n\n### 3-3 セキュリティの向上\n\n近年セキュリティインシデントが多く発生しているため、自社でシステムを構築する際にもセキュリティ強化を徹底しなければなりません。API連携を行えば、開発におけるセキュリティ強化にもつなげられます。\n\n例えば、モバイルデバイスを利用した二段階認証をシステムに構築する場合、自社で構築・運用するよりもAPI連携で実績のある認証サービスを利用すれば、セキュリティレベルの高い二段階認証を導入できます。これによりユーザーも安心してシステムに登録できるため、登録ユーザー数の向上も期待できるでしょう。\n\n### 3-4 ユーザーの利便性の向上\n\nAPI連携を行えば、ユーザーの利便性向上も見込めます。例えば、自社のWebサービスをユーザーが初めて利用する際に登録情報の入力が面倒だと感じることも多いでしょう。\n\nそこでAPI連携によって他社サービスの登録情報を活用して登録・ログインできる仕組みを構築しておけば、ユーザーはスムーズにサービスを利用することができ、「登録・ログインの手間」による離脱防止につなげられます。\n\n## 4. APIを利用する際の注意点\n\n![APIを利用する際の注意点](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/pv7pq4uaaakouzkrwqmu.jpg)\n\nAPIにはさまざまなメリットがありますが、以下のような注意点もあるため利用前に把握しておくことが大切です。\n\n* サービスの不具合の可能性\n* 突然のサービス停止のリスク\n\n### 4-1 サービスの不具合の可能性\n\nAPI提供元でシステムの不具合が発生した場合、自社で連携しているAPIの機能が使えなくなる可能性があります。つまり、APIを安定的に継続して活用できるかどうかはAPI提供元に大きく依存するということです。\n\n万が一、トラブルが発生し機能が使えなくなった場合は自社での対応はできないため、解消されるまで待たなければなりません。システムの利用ユーザーに不安や不満を感じさせてしまう原因にもなるため、事前にリスク対策を検討しておくことが大切です。\n\n### 4-2 突然のサービス停止のリスク\n\nAPI提供元のシステムの不具合だけでなく、サービスそのものが停止される可能性も考慮しておく必要があります。\n\n機能そのものが停止してしまうと、自社のサービスでも利用できなくなるため、代替となるサービスを活用する必要があります。\n\n突然サービスが停止されてから新しいAPIを探して実装するとなると時間と手間がかかるため、あらかじめ調査しておくことをおすすめします。\n\n## 5. APIの種類\n\n![APIの種類](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/kkj6pd3tpcx8zmzla5g0.jpg)\n\nAPIには提供される目的や用途に応じていくつかの種類があり、いずれも提供元や活用方法が異なります。どのAPIを使うのが最適か判断するためにも、APIの種類について理解しておきましょう。\n\n### 5-1 Web API\n\nWebを介して機能の一部が提供されるAPIです。「HTTP/HTTPS」の通信方式を使ってインターネット経由でリクエスト／レスポンスのやり取りが行われます。プログラミング言語や使用するパソコンのOSに関係なく、あらゆる環境からアクセスが可能な点が大きな強みであり、多くの企業からさまざまなAPIが提供されています。\n\n### 5-2 OS API\n\nWindowsやAndroidのようなOSが提供する「OS API（ネイティブAPI）」。OSが持っている機能を、他のアプリケーションでも呼び出すことができるAPIです。WindowsがOSとして持っている機能をサードパーティ製のアプリでも使えるようにしています。OSが進化するとともに、OSが提供する機能は多岐にわたり、手軽にAPIを使えるようなツール（フレームワーク）が提供されることも増えています。\n\n### 5-3 ライブラリAPI \n\nライブラリAPIとは、プログラミング言語のライブラリが提供するAPIのことで、クラスライブラリやコアAPI、標準APIとも呼ばれる場合もあります。ライブラリには、外部から利用できる特定の機能を実装するためのプログラム部品が格納されており、APIとして利用すれば一からコードを記述する必要がなくなるため、開発効率を大幅に向上させることが可能です。\n\nつまり、ライブラリAPI を活用すれば複雑なプログラミングを短時間で実行できるようになります。\n\n### 5-4 ランタイムAPI\n\nランタイムAPIとは、プログラムが実行されている時に使用されるAPIで、プログラム実行中の情報を取得できます。例えば、アプリケーションの動作状況をリアルタイムで把握し、メモリの使用量や実行時間などを把握することが可能です。\n\nランタイムAPIを活用すれば早期にアプリケーションの状態を把握できるため、問題の早期発見・改善につながりパフォーマンスを最適化できます。\n\n## 6. APIの提供方式\n\n![APIの提供方式](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/kkj6pd3tpcx8zmzla5g0.jpg)\n\nAPIにはさまざまな提供方式があり、活用の目的によって使い分ける必要があります。\n\n* オープン（パブリック）API\n* パートナーAPI\n* 内部API\n* コンポジットAPI\n\n### 6-1 オープン（パブリック）API\n\nオープンAPIは、企業が運用しているシステムのAPIを外部に公開しているAPIを指します。API提供元の企業はAPIを外部公開することで自社サービスの認知拡大を図れ、さらにAPIの提供を有料コンテンツとすれば利益の確保にもつながります。\n\nAPI利用者側は利用規約に同意すれば誰でも利用できるため、システム開発の際に自由に連携することが可能です。これにより高度な機能実装やセキュリティ向上を実現できます。\n\n### 6-2 パートナーAPI\n\nパートナーAPIは、企業間で利用されるAPIを指し、オープンAPIとは異なり外部での利用が限定されるのが特徴です。\n\nパートナーAPIを利用すれば、パートナー企業が保有しているデータや機能といったリソースを最大限に活用できるため、自社システムのパフォーマンス向上や顧客体験の強化につなげられます。\n\n### 6-3 内部API\n\n内部APIは、企業内のシステム間でデータのやり取りをするために活用されるAPIを指します。社内向けのAPIであるため、外部に公開されることはありません。\n\n多数のシステムを保有している企業なら内部APIを整備することで、社内でのデータ連携が容易になるため業務スピードの向上を実現できます。\n\n### 6-4 コンポジットAPI\n\nコンポジットAPIとは、一つのAPIで複数のAPIをまとめて利用できる形式のことです。コンポジットAPIを活用すれば、複数のアプリケーションとデータ連携する際の負担が軽減されるため開発効率の向上が期待できます。\n\nクラウドサービス間のデータ連携においてコンポジットAPIが利用されることが多いです。\n\n## 7. 代表的な4つのAPIプロトコル\n\n![代表的な4つのAPIプロトコル](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780256/rfea6xfjdwi2iklpstev.jpg)\n\nAPIプロトコルとは、システム間でデータの送受信を行うための通信の仕組みを指します。代表的なプロトコルは以下が挙げられます。\n\n* HTTP / HTTPS\n* XML-RPC\n* JSON-RPC\n* SOAP\n\n### 7-1 HTTP / HTTPS\n\nHTTP / HTTPSは、WebサーバーとWebブラウザとの間でデータのやり取りをするために用いられるプロトコルを指し、多くのWeb  APIで利用されています。\n\nHTTPSは、通信内容が暗号化されるためHTTPよりも高いセキュリティでより安全な通信を実現できます。\n\n### 7-2 XML-RPC\n\nXML-RPCは、XML形式を利用してクライアントとサーバー間でデータのやり取りをするプロトコルです。RPC（Remote Procedure Call：リモートプロシージャコール）とは、ネットワーク上にある他のコンピューターに対して処理をリクエストして実行するための手法を指します。\n\nXML-RPCは、1998年にユーザーランド・ソフトウェア社とマイクロソフトが共同開発したもので後に紹介するSOAPへと発展しています。\n\n### 7-3 JSON-RPC\n\nJSON-RPCとは、JSONを利用してクライアントとサーバー間でデータのやり取りをするプロトコルを指します。\n\nJSONは可読性が高く、コンピューターにとっても扱いやすい軽量のデータフォーマットであるため幅広く利用されています。\n\n### 7-4 SOAP\n\nSOAPとは、「Simple Object Access Protocol」の略語のことでXML-RPCを拡張したプロトコルです。SOAPはデータをやり取りするためのルールが厳格に定められているため、XML-RPCと比べて複雑なデータの通信に使われます。例えば、決済や認証など高いセキュリティが求められるシーンで活用できます。\n\n## 8. API連携の具体例\n\n![API連携の具体例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780256/y02nbwxggacaweafck3r.jpg)\n\n具体的にどのような場面でAPI連携が使われているのでしょうか。\n\n* SNS\n* ECサイト\n* POSレジ\n* 地図・天気情報\n\n以上4つの例を具体的に説明します。\n\n### 8-1 SNS\n\n近年、SNSは企業と個人をつなぐツールとして不可欠な存在となりつつあります。世界中に顧客を持つ企業では、よりきめ細かなカスタマーケアを提供する方法としてX（旧Twitter）で公開されているAPI「Sprout Social」はDM（ダイレクトメール）やメンション、リプライなどで言及されたユーザーからの要望や質問を、企業内の担当者に直接転送してくれます。\n\nまた、カスタマーフィードバック機能では、XのDMで製品やサービスの満足度に関するアンケート調査を行えます。質問への回答率の向上や解答までの時間短縮が顧客体験の向上を実現します。他にもLINEを使った荷物の再配達設定など、SNSを使った顧客体験の向上は広い業界に広がっています。\n\n### 8-2 ECサイト\n\n決済サービスの運営事業者はECサイト向けのAPIやサードパーティアプリを提供しています。例えば、楽天ペイでは決済処理APIを提供しており、API連携をしたECサイトで楽天会員が決済する場合、楽天ペイに登録済みの情報を呼び出して決済できます。個人情報を入力して会員登録をする手間を省けるため、顧客体験やコンバージョン率の向上が見込めます。\n\n### 8-3 POSレジ\n\n販売情報を集計・記録するPOSレジでもAPI連携が広がっています。顧客管理システムとの連携で会員情報の共有や購買履歴にあわせた商品レコメンドが可能になります。また、在庫管理システムとの連携で仕入れ効率を向上するなどデータ管理の効率化でも使われています。業種や店舗形態によってさまざまな活用が広がっています。\n\n### 8-4 地図・天気情報\n\n自社のWebサイトやアプリに対して、地図や天気情報をAPI連携を通して反映させることができます。\n\n例えば、商品の認知拡大や購買意欲の向上を目的として屋外イベントを開催する際には、API連携してWebサイトに地図や天気情報を掲載して告知すればユーザーに有益な情報を提供できます。これによりユーザーの情報収集の手間が省けるため、顧客満足度の向上にもつながるでしょう。\n\n## 9. 注目のAPI提供元とそのサービス\n\n![注目のAPI提供元とそのサービス](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/rfo3pqrzugdasqidprzn.jpg)\n\nここからは、注目のAPI提供元をご紹介します。\n\n### 9-1 Google\n\nGoogleでは、クラウド基盤である「Google Cloud Platform」上で、利用できるAPIをライブラリにまとめており、GmailやMap、YouTube、Calendar、Driveの他、300種類のAPIが公開されています。\n\nこうしたAPIを使って、メールを簡単に取得するツールやカレンダーアプリを作ったり、ブラウザの拡張機能や画像認識を使ったスマホアプリ、ソフトウェア、Webサービスを構築できます。\n\n### 9-2 X（旧Twitter）\n\n大手SNSであるXもAPIを提供しています。Webサイトに表示される投稿内容や投稿をまとめたり、自動で投稿してくれるツールなど、全てAPIをベースに作られています。\n\nSNSを使った情報発信や、情報収集を効率化したい場合には、真っ先にチェックすべきAPIと言えるでしょう。\n\n### 9-3 OpenAI\n\n話題のChatGPTを提供するOpenAIもAPIを提供しています。画像生成、機械文字起こし、自動分類、機械学習を実装するAPIに注目が集まっています。\n\n### 9-4 ヤマト運輸\n\nWebAPIにより、配送連携APIを提供しています。二次元コードをかざすだけでコンビニやオープン型宅配便ロッカーからの荷物を発送するため、匿名配送や発送時の支払い簡略化が可能になり、高い顧客満足を誇っています。\n\n### 9-5 Slack\n\nアメリカ発のビジネス向けコミュニケーションツールであるSlackも、「Slack API」という独自のAPIを提供しています。利用することで、リマインドやリアルタイムでのアラートなどの通知が行えます。Botを活用し、タスク自動化、メッセージの送受信や会話へのリアクションなども実装できます。\n\nSlackへ外部サービスからのAPIも提供されており、例えばGitLabも[Slack向けのAPI](https://about.gitlab.com/ja-jp/solutions/slack/)を提供しています。\n\n## 10. APIの使い方・利用手順\n\n![APIの使い方・利用手順](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780251/kwai9kgdry7kvcbwabu1.jpg)\n\n1. API提供元のWebサービスに登録する\n2. APIキーとAPIシークレットを取得し設定を行う\n3. 実装・テストを行う\n\n多くの場合、まずAPIを提供しているWebサービスへの登録が必要になり、基本情報の入力を行います。登録が完了すればAPIキーとAPIシークレットを取得できます。これらはAPIを利用するためのコードであるため大切に保管しておいて下さい。\n\nコードの取得まで終わり、準備が整えば実装の段階に移ります。APIの実装手順は提供事業者によって異なるため、ドキュメントなどを確認しながら行いましょう。実装が完了したら実際に操作してみて動作に問題がないか確認します。\n\n## 11. API連携に関するよくある質問\n\n![API連携に関するよくある質問](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756780256/o82yfn9ph698fmhcv41x.jpg)\n\n最後にAPI連携に関するよくある質問とその回答を紹介します。\n\n### 11-1 APIゲートウェイとは何ですか？\n\nAPIゲートウェイとは、APIの管理ツールです。複数のAPIと連携を行う場合、APIゲートウェイを使えば、APIゲートウェイがそれぞれのAPIへリクエストを振り分け、集約し適正なレスポンスを返却してくれます。\n\n### 11-2 APIは誰でも利用できますか？\n\n基本的には誰でも利用可能です。ただし、利用における必要な技術や、APIによっては有償化されているものもあるので、利用する際には、きちんとした理解と検討が必要です。\n\n### 11-3 RESTとSOAPの違いは？\n\nRESTは「Representational State Transfer」の略語であり、Webのアーキテクチャスタイルの一つです。HTTPプロトコルを使用しますが、REST自体はプロトコルではありません。\n\n一方、SOAPはメッセージングプロトコルであるため、両者は根本的に異なるアプローチだといえます。\n\n### 11-4 WebhookとAPIとの違いは？\n\nWebhookとAPIにおいては、どちらもアプリケーション間でデータを連携するために活用されますが、両者は仕組みの観点から明確な違いがあります。\n\nAPIの場合は、必要に応じてデータをリクエストしてレスポンスを受け取る方式ですが、Webhookは事前に設定した条件を満たすことでこちら側からリクエストしなくてもレスポンスを受け取れます。\n\nつまり、Webhookならリアルタイムで必要な情報を受け取ることができます。しかし、APIとは異なりユーザーを認証する機能がないため、悪意ある情報を受け取ったりなどセキュリティにおけるリスクがあります。\n\n## まとめ\t自社のビジネスやサービス開発にAPI戦略を取り入れよう！\n\n自社のソフトウェア開発やビジネスにおいてAPIを積極的に活用することで、開発効率の向上やコスト削減などを実現できます。\n\nAPIにはさまざまな種類がありますが、自社に必要な要件を満たしたAPIを探して積極的に開発に取り入れていくと良いでしょう。\n\n[GitLab](https://about.gitlab.com/ja-jp/)でも開発者向けに包括的なAPIを提供しており、CI/CDパイプラインの自動化から課題管理まで、様々な機能をAPI経由で利用できます。GitLabの利便性の高いAPIを、ぜひこの機会に体験して下さい。\n\nなお、[GitLab](https://about.gitlab.com/ja-jp/)では世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しているので、ぜひこちらもご覧ください。\n\n[2024グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/)",[761],"2025-09-02","2024-12-16",[9,234],"engineering",{"slug":835,"featured":91,"template":681},"what-is-an-api","content:ja-jp:blog:what-is-an-api.yml","What Is An Api","ja-jp/blog/what-is-an-api.yml","ja-jp/blog/what-is-an-api",{"_path":841,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":842,"content":848,"config":855,"_id":857,"_type":14,"title":858,"_source":16,"_file":859,"_stem":860,"_extension":19},"/ja-jp/blog/what-is-git",{"title":843,"description":844,"ogTitle":843,"ogDescription":844,"noIndex":6,"ogImage":845,"ogUrl":846,"ogSiteName":669,"ogType":670,"canonicalUrls":846,"schema":847},"Gitとは？初心者に使い方、意味、機能、利点を徹底解説","Gitとは？管理部門やオペレーション部門、初心者には知られていないGitの基礎知識を、仕組みから利点、基礎用語、よくある質問まで徹底的に解説。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687231/Blog/Hero%20Images/Git.jpg","https://about.gitlab.com/blog/what-is-git","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Gitとは？初心者に使い方、意味、機能、利点を徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-10-08\",\n      }",{"title":843,"description":844,"authors":849,"heroImage":845,"date":851,"body":852,"category":10,"tags":853,"updatedDate":854},[850],"GitLab Team","2024-10-08","## 目次\n- Gitとは何か？ \n- Gitの意味\n- Gitは何に使われている？\n- Gitの利点とは？\n- Gitの何がすごい？\n- 組織がGitを使ってできること \n- Gitの用語と使い方の初心者向け解説\n- Gitの弱点は？\n- Gitの管理はツールで手軽に \n- まとめ \n\nGit（ギット）という言葉をエンジニアや開発者が口にするのを耳にしたことがある方は多いはずです。プロジェクトを走らせながらツールやサービスの改善を行う[アジャイル手法](https://about.gitlab.com/ja-jp/topics/agile-delivery/agile-methodology/)が基本の今、業務効率化のためにGitを使用するのは当たり前となってきました。ただ、IT関連企業だったとしても、マネジメントやオペレーション部門などで働く非エンジニアや初心者は、Gitとは何か、なぜ世界で広く使われているのか、その理由を明確には理解していないかもしれません。\n\nしかし、Gitは開発部門だけではなく、チーム内の複数のメンバーが同時に作業を行う場合（たとえば人事部門で社外の専門家に相談しながら社則の見直しと刷新を行う、デザイン部門でブランドロゴのデザインを行うなど）にも、とても便利なツールです。また、プロジェクトの大きさや用途によっては、ノーコスト／ローコストで導入を[お試しできる点](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)も見逃せません。\n\nこの記事では、初めてGitに触れる方のために、Gitとは何か、組織にとってどんな利点があるのかを詳しく解説していきます。\n\n## Gitとは何か？\n\nGitとは、分散型バージョン管理システムで、ファイルのバージョン管理が簡単にできるツールです。「文書作成アプリケーションでも変更履歴を保存して表示できるし、それとどう違う？」「分散型バージョン管理システムっていったい何？」といった疑問も浮かぶことでしょう。この疑問については後ほど詳しく説明します。\n\n## Gitの意味\n\nそもそもGitとは「Global Information Tracker（グローバルインフォメーショントラッカー）」の頭文字を取っていると言われています。つまり、Gitは包括的（Global）に変更履歴情報（Information）の追跡（Tracker）を行うツールという意味です。\n\nここで注目しておきたいのは「包括的」という言葉です。文章作成ソフトの変更履歴と違い、ただ単にバージョン履歴を保存するだけではない点です。\n\n## Gitは何に使われている？\n\nGitはファイルやコードのバージョン管理に使われます。バージョン管理システムとは、その名のとおりファイルやコードなどの変更（バージョン）を管理するシステムであり、チーム全体での調整、共有、コラボレーションを容易にします。\n\nあるファイルを作成した後、時間が経つにつれ変更点が複雑になり、ファイルの本筋がどこにあるのかわかりにくくなることがあります。たとえば、ミーティングの議事録について考えてみましょう。議事録をプロジェクトチームに共有し、欠席者がその内容について質問コメントを残し、ある人が補足情報を足し、別の人が会議中生じた確認事項を追記し、また別のある人が補足情報の一部を削除する。このように複数の関係者が何度も編集することで各時点で実施された変更を正確に把握することは難しくなっていきます。\n\n![迷路化したバージョンの中心にGitLabのアイコン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/version-control.svg)\n\nバージョン管理システムは、ファイルのすべての変更を追跡し、以前のバージョンに戻ってシームレスに共同作業できるようにする非常に便利なツールです。\n\n### Gitの機能とは\n\nGitを含むバージョン管理システムには、主に次の3つの機能があります。\n\n1. ファイル共有：チーム内でファイルを共有\n2. ファイル同期：変更点を同期\n3. ファイルバックアップ：変更点を保存\n\nまた、バージョン管理システムの種類には、次の2つがあります。\n1. 中央集中型管理システム：Subversion（SVN）、Concurrent Version System（CVS）\n2. 分散型管理システム：Git、Mercurial、Bazaar、Fossil\n\n## Gitの利点とは？\n\nそれでは、Gitのような分散型管理システムの利点は何でしょうか？それを理解するために、まず2つのバージョン管理システムの仕組みを説明します。\n\n### 中央集中型バージョン管理システムの仕組み\n\n中央集中型バージョン管理システム（CVCS）では、すべてのバージョンを1つのサーバーに格納します。プロジェクトメンバーはそのサーバーにアクセスしてファイルを更新します。ある人が更新を行っている場合、他の人はそのファイルで作業できません。基本的に作業はオンラインで行い、変更点はサーバーによってきちんと保存およびカタログ化されます。このシステムはいたってシンプルであり、変更を管理する方法が簡単であるため、チームの規模が小さい場合に有効です。しかし、編集作業自体が複雑になってしまうため、更新を行ったメンバー同士の衝突が起こる場合もあります。\n\n### 分散型バージョン管理システムの仕組み\n\n一方、Gitのような分散型バージョン管理システム（DVCS）の利点は、柔軟性の高さです。分散型では、ファイルをサーバーで一元管理するだけに終わりません。 各プロジェクトメンバーはプロジェクト履歴全体をローカルに保持して、オフラインで作業できます。その作業結果を確認後、サーバーにアップすると、サーバー上でバージョンの保存およびカタログ化が行われます。したがって、中央集中型バージョン管理システムよりも、多様なバージョンの分岐ができ、またバージョンのマージ（結合）も容易になります。\n\n### 時代にフィットするGit\n\nハイブリッドやリモートなどさまざまな働き方が当たり前となった昨今、Gitのような分散型バージョン管理システムの柔軟性は、複数のプロジェクトを走らせたり織り交ぜたりするダイナミックなチームにとって不可欠な存在となっています。両者の違いを表で確認しましょう。\n\n| バージョン管理システム名 | 利点 |\n| :---- | ----- |\n| 中央集中型（CVCS） | ・小・中規模なチーム向き ・作業は基本的にオンラインで行う ・すべてのバージョンを1つのサーバーに ・管理がシンプル |\n| 分散型（DVCS） Gitほか | ・大規模のチームにも対応 ・プロジェクト履歴を各メンバーがローカルに保持 ・オフラインで作業できる ・より優れたアイディアが公平に取り入れられやすい ・柔軟性が高い ・バージョンの分岐やマージが簡単 |\n\n## Gitの何がすごい？  \n分散型バージョン管理システムの優れた点を説明してきましたが、Gitを使うメリットは、ずばり「開発業務の効率が上がること」です。プロジェクトメンバーが同時に作業でき、プログラムの共有を容易に行えるため、管理しやすいのです。また、開発過程で修正点やバグへの対処が必要となるのはよくあることですが、その際も管理されたバージョン履歴をたどって迅速に原因の特定ができます。そのため、迅速に対処できるのです。\n\n## 組織がGitを使ってできること\n\nここで改めてGitを導入してできることを具体的に挙げてみます。\n- 新旧のバージョンを一元管理できる\nGitを使うことで、ファイルの新旧を一元的に管理できます。変更をした際、いちいちファイル名に日時や「.V2」などの名前を付け、どのファイルが新しいのか見分けがつくようにする手間がなくなります。\n\n- 古いバージョンに簡単に戻ることができる\n作業途中に「前のほうが良かった」と旧バージョンに戻りたくなっても、Gitを使っていれば簡単に古いバージョンにさかのぼることができます。\n\n- ファイルや変更履歴をスムーズに共有できる\n作業者同士で直接ファイルをやりとりする必要がないため、バージョンの混乱も反映までの時差も発生しません。\n\n- チームでの共同開発を効率化できる\nGitなら、チームは変更を簡単に追跡できるため、さまざまなバージョンの追跡やマージに時間を費やすことなく、目の前のタスクに集中できます。また、オフラインで作業してローカルに保存するため、中央集中型よりも速いスピードで作業できます。\n\n- ノーコスト／ローコストで導入のお試しができる\nGitは世界で最も広く使用されているバージョン管理システムであり、事実上の業界標準です。したがって多くの人気開発者ツールでサポートされており、無料で利用できるリソースも多数あります。\n\n## gitの用語と使い方の初心者向け解説\n\nGitの使い方と、どのような用語を使用するか、初心者が理解しやすいように表組にまとめてみました。\n\n- 場所の名前\n\n| 場所 | 定義 |\n| :---- | :---- |\n| リポジトリ | ファイルや変更履歴を保存しておくデータベース。リポジトリには2種類ある。 ローカルリポジトリ（ローカル上）：ローカル環境で作業を行う際に使う。 リモートリポジトリ（ネットワーク上）：他のユーザーとファイルや変更履歴を共有する際に使う。 |\n| インデックス | リポジトリ（保存場所）とワークツリー（作業場所）の間の中間領域。ローカルで作業したファイルをリポジトリに保存するには、インデックスにいったん置く必要がある。 |\n| ワークツリー | ユーザーが編集している作業中のディレクトリのこと。 |\n\n- アクションとコマンド\n\n| アクション | 定義 | コマンド |\n| :---- | :---- | :---- |\n| クローン | リモートリポジトリのコミットを、ローカルリポジトリへ丸ごとコピーすること。 | git clone \\[リポジトリパス\\] |\n| コミット | リポジトリへファイルや変更履歴を登録することを指す。 | git commit \\[コミット名\\] |\n| プッシュ | 登録した変更（コミット）をローカルからリモートリポジトリへ反映させることを指す。 | git push |\n| ブランチ | 変更履歴を分岐することを指す。作成された分岐はブランチと呼ばれる。 | git branch |\n| マージ | 複数のブランチを一つにまとめること。 | git merge |\n| プル | リモートリポジトリのコミットをローカルリポジトリへと引っ張ってくることを指す。 |   git pull |\n| フェッチ | リモートリポジトリからファイルの最新情報を取得してくること。プルとは違い、ローカルのファイルは更新されない。 | git fetch \\[リポジトリ\\] |\n\n## Gitの弱点は？\n\nこのように便利でさまざまな利点があるGitですが、弱点もあります。\n\n- Gitの操作方法は非エンジニアにはなじみがない\n「Gitがそんなに便利なら、なぜマネジメントやオペレーション側にあまり浸透していないのだろう」という疑問も生まれるでしょう。しかしGitをそのまま使う場合、基本的にCUIという文字によるコマンドの打ち込みでコンピューターと対話する操作手法が必要です。PCが不調でシステムをセーフモードで起動した経験はないでしょうか（文字列だけの暗い画面が立ち上がります）。あるいはエンジニアが暗い画面にコードを表示して作業している様子を想像してみましょう。普段コマンドやコードに縁がない人にとってはハードルが高い操作方法と言えます。\n\n- Gitの学習には時間が必要\nGitを導入する際、プロジェクトチームは全員がGitを使えるようになる必要があります。用語も独特であり、また、各メンバーがローカルで作業するため、運用ルールを決めておかないと混乱する可能性があります。慣れるまでに学習時間が必要であるため、使用頻度がそこまで高くない場合、学習にかかる時間的コストの費用対効果が疑問視されることもあります。\n\n## Git管理はツールで手軽に\n\nこのようなGitの弱点を一挙に解決するのが、Gitにユーザーフレンドリーなインターフェイスを組み込んだ管理ツールです。管理ツールを使えば、コマンドを打ち込んで操作するのではなく、日常使っているアプリケーションのようにマウスでクリックして操作できるため、Gitの多数のメリットを組織にスムーズに取り入れられます。\n\nGit管理ツールを導入すると次のようなメリットがあります。\n\n- Gitを使うためにコマンドを覚える必要がない  \n- Gitを学習する時間が短縮できる  \n- エンジニア以外でもGitを使えるようになる\n\nGit管理ツールにはさまざまな種類がありますが、開発スピードを確保しつつセキュリティも高めたい組織が選んでいるのは、GitLabです。\n\nGitとGitLab。名前が似ているのは、GitLabが[Gitを使ったDevSecOpsプラットフォームサービス](https://about.gitlab.com/ja-jp/platform/)だからです。\n\n![GitLabのアイコンとロゴ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/gitlab-logo-150.jpg)\n\nGitLabはバージョン管理システムであるGitを中心に、開発（Dev）セキュリティ（Sec） オペレーション（Ops）のすべてをこなせるプラットフォームであり、アイコンやボタンなどのグラフィックを使用して視覚的に操作できるグラフィカルユーザーインターフェイスを採用しているため、Gitの弱点を克服できます。\n\n当然、先ほど挙げたGit管理ツールのメリットを享受できますが、それだけではありません。計画から本番まで、DevSecOpsのあらゆる機能が1つのアプリケーションにまとまっているため、プロジェクトにかかわる各部署の連携が強化され、チームにまとまりが生まれます。\n\nGitLabの「非エンジニアを含む各部門がGitを使用でき、情報を統一的に集約して管理しやすいツール」という面は、他にはない特徴です。\n\nまとめると、GitLabには次のような特徴があります。\n\n* ツールチェーンを簡素化できる\n\n  重要な[DevSecOpsツール](https://about.gitlab.com/ja-jp/platform/)がすべて1つのプラットフォームに集約されています。\n\n* ソフトウェアデリバリーを高速化できる\n\n  オートメーション、[AIを活用したワークフロー](https://about.gitlab.com/ja-jp/gitlab-duo/)が提供されています。\n\n* セキュリティを統合できる\n\n  セキュリティは[デフォルトでビルトイン](https://about.gitlab.com/ja-jp/solutions/security-compliance/)されており、追加は不要です。\n\n* どこにでもデプロイできる\n\n  複数のクラウドにコンピューティングを分散するマルチクラウドアプローチが行えます。\n\n* Freeプランでノーコストでのお試し導入ができる\n\n  [無料試用版](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/devsecops/&glm_content=default-saas-trial)をクレジットカードの登録なしで使用開始できます。\n\n![AIの助けで時間短縮](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/homepage-image.png)\n\n開発のスピード向上を計りたい＋包括的なセキュリティ対策を重要視したいという組織に、GitLabは最適です。\n\n[GitLab公式サイト](https://about.gitlab.com/ja-jp/)\n\n## まとめ \n\nここまで、組織のマネジメントやオペレーション部門などで働く非エンジニアや初心者向けに、Gitとは何か、おさえておくべき基礎知識、仕組み、用語をご紹介しました。Gitの概要を把握しておくことで、導入を検討する際の一助になれば幸いです。\n\nこれほど利便性が高いGitですが、開発（Dev）セキュリティ（Sec） オペレーション（Ops）プラットフォームであるGitLabの、ほんの一部の機能にすぎません。すべてをこなせるDevSecOpsプラットフォームの力強さに興味がある方は、ぜひ30日間無料トライアルでGitLabを体感してみてください。\n\n> [GitLab Ultimateの無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)を始めましょう\n\n\u003Cbr>\u003Cbr>\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[678,9],"2024-12-26",{"slug":856,"featured":91,"template":681},"what-is-git","content:ja-jp:blog:what-is-git.yml","What Is Git","ja-jp/blog/what-is-git.yml","ja-jp/blog/what-is-git",{"_path":862,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":863,"content":869,"config":874,"_id":876,"_type":14,"title":877,"_source":16,"_file":878,"_stem":879,"_extension":19},"/ja-jp/blog/what-is-gitflow",{"title":864,"description":865,"ogTitle":864,"ogDescription":865,"noIndex":6,"ogImage":866,"ogUrl":867,"ogSiteName":669,"ogType":670,"canonicalUrls":867,"schema":868},"GitFlowとは？GitLab Flowとの違いと開発フローを解説","GitFlowとGitLab Flowの違いや、GitFlowとは何なのか、GitFlowの仕組みや使うメリット、よくある質問などをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659838/Blog/Hero%20Images/AdobeStock_662057734.jpg","https://about.gitlab.com/blog/what-is-gitflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitFlowとは？GitLab Flowとの違いと開発フローを解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-09-27\",\n      }",{"title":864,"description":865,"authors":870,"heroImage":866,"date":871,"body":872,"category":10,"tags":873},[850],"2024-09-27","GitFlow では、開発者は「\u003Ccode>main\u003C/code>」（運用）ブランチの他に「\u003Ccode>develop\u003C/code>」（開発）ブランチを分けて作成しそれをデフォルトにしますが、[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は\u003Ccode>main\u003C/code>ブランチでもすぐ作業を始められます。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)にはプリプロダクションのブランチが組み込まれており、\u003Ccode>main\u003C/code> ブランチに変更点をマージして本番環境に移行する前にバグ修正を行うことができます。たとえば、\u003Ccode>main\u003C/code>からテストへ、テストから承認へ、または、承認からプロダクションへ、といったように、チームは必要に応じてプリプロダクションブランチを好きなだけ追加できます。\n\nここでは、GitFlowと[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)の違いや、GitFlowとは何なのか、GitFlowの仕組みやこれを使うメリット、よくある質問などをわかりやすく説明します。\n\n## 目次\n- GitFlowとは\n- GitFlowの仕組み\n- GitFlowと GitLab Flow はどう違うのか\n- GitFlowのワークフロー\n- GitLab Flowのワークフロー\n- GitFlowを使うメリットと各種機能\n- GitFlowの例\n- GitLab FlowとGitFlowのFAQ（よくある質問）\n\n## \u003CH2> GitFlowとは \u003C/H2>\n\nGitFlowとは、Git（分散型バージョン管理システム）ブランチを管理するGitワークフローのことで、Gitでのリポジトリの分岐（ブランチ）モデルです。複雑なソフトウェアリリース管理を簡素化するためにつくられ、Vincent Driessen氏によって2010年に利用が始まりました。規模の大きなチームの間で、特に人気があります。\n\n## \u003CH2> GitFlowの仕組み \u003C/H2>\n\nトランクベース開発と比較すると、GitFlowには永続的なブランチと大規模なコミットがあります。GitFlowは、リリースの周期が決まっているプロジェクトと、継続的なデリバリーを行なう [DevOps](https://about.gitlab.com/ja-jp/solutions/devops-platform/)ベストプラクティスに利用できます。\nGitFlowではワークフローが構造化されているため、たとえば、developブランチとmainブランチにfeatureブランチを追加し、次いでreleaseブランチを追加するなどして各ブランチを定義します。こうすると、チームがその構造を理解しやすく、変更点などを開発パイプラインのどこに加えるべきなのか、一目瞭然となります。\n## \u003CH2> GitFlowとGitLab Flowはどう違うのか \u003C/H2>\n\nGitFlowとは、Gitのブランチングモデルで、フィーチャーブランチの他に、複数の主要ブランチを使用します。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は、GitFlowが内包していた問題を解決し、チームメンバーがより効率よく作業できるようにしています。詳しいワークフローの違いを見てみましょう。\n\n### \u003CH3> GitFlowのワークフロー \u003C/H3>\n\nGitFlowのワークフローには、次の5つのブランチがあります。\n\n1. main\u003Cbr>\n2. develop\u003Cbr>\n3. feature\u003Cbr>\n4. release\u003Cbr>\n5. hotfix\u003Cbr>\n\nGitFlowをコード開発で使用するときは、mainブランチとそれ以外のサポートブランチを使用します。メインブランチには、製品としてリリースするためのmainブランチと、開発中のソースコードを管理するdevelopブランチの2つのブランチがあります。developブランチでコードの安定化を図り、リリースの準備ができたらmainブランチにマージします。サポートブランチには、feature、release、hotfixなどのブランチを作成し、それぞれの作業を進めます。\n\n### \u003CH3> GitLab Flow のワークフロー \u003C/H3>\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は、リリース、タグ付け、マージなどで発生するオーバーヘッドを防ぎ、開発を効率化します。\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はGitFlowを簡略化したもので、フィーチャー中心の開発と、イシュー追跡機能を組み合わせたものです。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)を使うと、シンプルで、わかりやすく、かつ効率的な作業が可能になります。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)には、ソフトウェア開発チームがスムーズに機能をリリースするための、ベストプラクティスが含まれています。\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はGitLabの開発で使用するワークフローで、メインのブランチである \u003Ccode>main\u003C/code>、リリース前のテスト用ブランチである \u003Ccode>pre-production\u003C/code>、リリース済みのコードを管理する\u003Ccode>production\u003C/code>、機能の開発やバグ修正用\u003Ccode>feature\u003C/code>/\u003Ccode>hotfix\u003C/code>などのブランチがあります。チームは、好きな数だけプリプロダクションブランチを追加できます。たとえば、\u003Ccode>main\u003C/code> からテストに、テストから承認に、承認からプロダクションに、といったように流れをつくります。\n\nチームはフィーチャーブランチを作成する一方で、プロダクションブランチを管理します。メインブランチのデプロイ準備が整ったら、それをプロダクションブランチにマージし、リリースします。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はリリースブランチでも使用できます。パブリックのAPIが必要なチームは異なるバージョンを管理しなければなりませんが、[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)を使うと個別に管理可能なv1ブランチとv2ブランチを作成できるため、コードレビューでバグを検出した場合にv1に戻れ、とても便利です。\n\n\u003CH2> GitFlowを使うメリットと各種機能 \u003C/H2>\n\u003CH3>メリット1: バグ修正を迅速に処理\u003C/H3>\n\nGitFlowを使うメリットのひとつは、本番環境でのバグ修正が素早く処理できる点です。GitFlowは規模の大きなチームで複雑なソフトウェア開発を行なう際に、Git（分散型バージョン管理システム）のワークフローとして利用します。\n\n\u003CH3>メリット2: テストを保証\u003C/H3>\n\nリリースブランチからソフトウェアをリリースするときは、ユーザーがステージング環境でテストできる期間を設定できます。これはコード開発とは独立して行なえます。また、コミットは下流側に流れるので、すべての環境でテスト済みであることが保証できます。\n\n\u003CH3>メリット3: ソフトウェア開発プロセスの効率化\u003C/H3>\nGitFlowを使うと、Gitが最大限に活用できます。それにより、ソフトウェア開発プロセスの効率化が図れます。\n\n\u003CH3>メリット4: より効率的なコラボレーション、コンフリクトの解決、継続的なデリバリー\u003C/H3>\n\nGitFlow を導入することで、コラボレーションが効率化できます。マージのコンフリクトも素早く解決でき、継続的なデリバリーが実現します。\n\n\u003CH2> GitFlowの例 \u003C/H2>\n以下に、GitFlowの構成例を図で示します。フロー全体と、それぞれの分岐や構造などがおわかりになるかと思います。\n\n![AdobeStock 569852816](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673714/Blog/Content%20Images/AdobeStock_569852816.jpg)\n\u003CH2> GitLab FlowとGitFlowのFAQ（よくある質問）\u003C/H2>\n\n### Q: Git Feature Flowとは何ですか。\nA: Gitを使った開発フローについて、提唱されているフローのひとつです。シンプルな開発なら Git Feature Flowで対応可能です。\n\n### Q: GitLab Flowは、使用するだけの価値がありますか。\nA: はい。GitLab Flowはリリース、タグ付け、マージなどのオーバーヘッドを低減します。こういった問題は、他の Gitワークフローでよく出くわす問題です。詳しくは、[こちら](https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/)（英語版）をご覧ください。\n\n### Q: GitLab FlowとGit Flow、どちらを選んだらいいですか。\n\nA: Git Flowでは、その構造上、開発ステージが明確に分かれている大型のプロジェクトに向いていますが、GitLab Flowは[アジャイル](https://about.gitlab.com/ja-jp/blog/what-is-agile-development/)なので、継続的なデリバリーや迅速なリリースを優先するようなプロジェクトに向いています。\n\n## \u003CH2>参考文献\u003C/H2>\n[GitLab のDevSecOpsについて](https://about.gitlab.com/ja-jp/)\n\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n## \u003CH2>今すぐGitLabを始めてみる\u003C/H2>\nGitやバージョンコントロールについて詳しく知りたい方は、[こちら](https://about.gitlab.com/resources/)をご覧ください。\n統合されたDevSecOpsプラットフォームを使用してチームの可能性の広がりを体感しませんか？\n\n[無料トライアルを開始](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com)\n",[678,9],{"slug":875,"featured":6,"template":681},"what-is-gitflow","content:ja-jp:blog:what-is-gitflow.yml","What Is Gitflow","ja-jp/blog/what-is-gitflow.yml","ja-jp/blog/what-is-gitflow",{"_path":881,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":882,"content":888,"config":896,"_id":898,"_type":14,"title":899,"_source":16,"_file":900,"_stem":901,"_extension":19},"/ja-jp/blog/what-is-kubernetes",{"title":883,"description":884,"ogTitle":883,"ogDescription":884,"noIndex":6,"ogImage":885,"ogUrl":886,"ogSiteName":669,"ogType":670,"canonicalUrls":886,"schema":887},"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":883,"description":884,"authors":889,"heroImage":885,"date":891,"body":892,"category":833,"tags":893},[890,761],"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",[725,894,895,109,533,9,808,811,703],"cloud native","DevOps",{"slug":897,"featured":91,"template":681},"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":903,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":904,"content":910,"config":915,"_id":917,"_type":14,"title":918,"_source":16,"_file":919,"_stem":920,"_extension":19},"/ja-jp/blog/what-is-open-source",{"noIndex":6,"title":905,"ogTitle":906,"description":907,"ogImage":908,"ogDescription":909},"オープンソースソフトウェア（OSS）とは？詳しく解説​ | GitLab","オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。読んで、理解を深めましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",{"title":906,"description":909,"authors":911,"heroImage":908,"date":912,"body":913,"category":10,"tags":914},[850],"2025-07-17","## オープンソースとは？\n\nオープンソースとは、ソフトウェアのコードが公開され、誰もが利用、改良、再配布できるという仕組みのことを指します。「オープンソースソフトウェア」と同義で使用されることが多いです。\n\n## オープンソースソフトウェア（OSS）とは？\n\nオープンソースソフトウェアはOSSとも記述され、Open Source Softwareの略称です。一般的な商用ソフトウェアとは異なり、誰でも利用、改良、再配布ができるようソースコードが公開されています。これにより個人や企業のデベロッパーは、各々の環境に合わせてソフトウェアを自由に改変し、特定の用途や問題に最適化することが容易にできます。ただし、OSSによってはライセンス制約が存在する場合もあります。\n\nフリー（無料）ソフトと混同されることがありますが、フリーソフトのほとんどはソースコードが非公開です。よって、ソースコードが公開されているかどうかで、OSSかの判断をするのが一般的です。\n\n## オープンソースソフトウェアの基本原則\n\nオープンソフトウェアに明確な定義はありませんが、「ソースコードが公開されていること」以外にも広く認知されている要件があります。これら要件は、米国のOpen Source Initiative（OSI）という団体が提唱した以下10項目を指すのが一般的です。\n\n* 再配布の自由\n* ソースコードの配布\n* 派生ソフトウェアの配布許可\n* 作成者のオリジナルコードの完全性\n* 個人やグループに対する差別禁止\n* 使用分野に対する差別禁止\n* ライセンスの配布\n* 特定製品でのみ有効なライセンスの禁止\n* 他ソフトウェアを制限するライセンスの禁止\n* ライセンスの技術的中立\n\n要約するとOSSの基本原則は、ユーザーやデベロッパーに自由を提供し、協力的な環境を促進することと言えます。ただし、「自由」ではあるものの、ライセンスによって一定のルールは設定されています。例えば、GPLやMITライセンスは、OSSに付随するライセンスの利用や再配布、改変の範囲を規定し、自由利用を促進しつつも、デベロッパーやユーザーの権利を保護しています。OSS利用の際は、こういったライセンスルールを理解し、遵守することを忘れないようにしましょう。ライセンスについては後ほど詳しく解説します。\n\n## オープンソースソフトウェアの具体例\n\nどういったソフトウェアがOSSなのかと問われると、すぐには思いつかないかもしれません。実際に、どういったソフトが様々な分野で活躍しているのかいくつかご紹介しましょう。\n\n### WordPress\n\nWordPressという名前は、誰もが一度は聞いたことがあるでしょう。WordPressはウェブサイトを簡単に作成できるコンテンツ管理システム（CMS）で、世界中でもっとも利用されているCMSとなっています。ウェブサイトデベロッパーは自由にカスタマイズを行うことができ、また、活発なコミュニティで互いをサポートし合うことにより、新たな拡張機能の開発等に貢献しています。\n\n### GIMP\n\nGIMPは、イラストレーター、グラフィックデザイナー、フォトグラファー、サイエンティストなど画像を扱う専門家に人気の画像編集ソフトウェアです。ユーザーは無料でダウンロードして利用でき、WordPressと同じく活発なコミュニティが、日々のバグ修正や、新プラグインを開発をサポートしています。\n\n### Brave Browser\n\nBraveは、ユーザーのプライバシー保護を主眼としたウェブブラウザであり、広告やトラッキングを防止してくれます。さらに、独自の暗号通貨（BAT）や検索システムを開発しているなどの理由で、デベロッパー間では人気のブラウザの一つです。Braveもオープンソースであるため、個人が自由にブラウザ機能をカスタマイズしたり、新たに機能を追加したりすることができる仕様となっています。\n\n### GitLabのオープンソースプロジェクト\n\n[GitLabプラットフォーム](https://about.gitlab.com/ja-jp/)を利用して開発されているオープンソースプロジェクトをいくつかご紹介します。\n\n#### Drupal\n\nDrupalはWordPressと同様に、オープンソースのコンテンツ管理システム（CMS）です。堅牢性と拡張性の高さが評価されており、NASAや経済産業省といった政府機関や、Teslaなどの企業に採用されています。\n\n#### VLC\n\nWindowsやMacにとどまらず、LinuxやiOS等でも使うことできる、メディアプレイヤーです。多様な種類の音声や動画ファイルを再生でき、様々なファイル形式に対応しています。広告等、ユーザーにとって不要な機能が一切搭載されておらず、世界中で広く利用されています。\n\n#### LibreOffice\n\nMicrosoft Officeとよく比較されることがあるのが、LibreOfficeです。無料で利用することができ、様々なオフィスツールを提供することから、たくさんの企業や個人に使用されています。\n\n## オープンソース開発のメリットとデメリット\n\nOSSの開発には様々なメリットとデメリットがあります。開発手法についての議論は付きませんが、ここでは言及されることが多いポイントをいくつか挙げてみます。\n\n### メリット\n\n#### コミュニティによる自発的なサポートと開発\n\nオープンソース開発は通常、世界中のデベロッパーが参加した活発なコミュニティを形成しています。多種多様なバックグランドを持つ個々のユーザーたちがお互いにアイデアやフィードバック、サポートし合うことを基本とし、継続的な開発とサポートをしてくれます。\n\n#### 高い透明性に担保された信頼とセキュリティ\n\nOSSの信頼とセキュリティは、誰もがソースコードを参照できることで実現されています。\n\nまず、たくさんのデベロッパーの目に触れるため、脆弱性やバグが比較的早い段階で発見されます。これにより、セキュリティを高レベルに引き上げることができます。そして、ソースコードが公開されているため、不正な動作やバックドアの存在といったリスクを排除しやすく、ソフトウェアの信頼性を高めてくれます。\n\n#### 開発にかかる時間と費用の削減\n\nオープンソースソフトウェアは大抵が無料で、自由にソースコードを改変できます。よって、ライセンス料とスクラッチ開発が不要であり、個人や企業の費用と開発時間を大幅に削減してくれます。\n\n### デメリット\n\n#### 開発プロジェクトの継続性\n\nオープンソース開発は、有志が中心となって行われる場合が多いため、プロジェクトが遅延したり、突然中止となったりするリスクがあります。また、安定した開発スケジュールが維持されないこともあります。\n\nプロジェクトの多くは無償、スポンサー、寄付で成り立っていることが一般的なので、開発コアメンバーが抜けた、資金が枯渇してしまった、などの理由から開発自体が立ち行かなくなることもあります。\n\n#### 責任の所在が曖昧\n\nコミュニティ主導で開発が進められる場合、ユーザーにバグや他ソフトと統合できないといった問題が発生しても商用ソフトウェアとは異なり、自己解決しなくてはならないケースが通常です。迅速かつ的確なサポートが受けづらいケースも、発生することがあります。\n\n#### ライセンスの準拠で\n\n当然ながら、OSSにもライセンスが存在します。無条件に利用や再配布ができるわけではないので、しっかりとライセンスを理解した上で使用しなければいけません。ライセンス規約に違反してしまい、過去には訴訟に発展したケースもあるため、注意が必要です。詳しくは後ほど解説します。\n\n### オープンソースの課題とGitLabのアプローチ\n\nGitLabというプラットフォームが、OSSにおける課題に対してどう取り組んでいるかについて、いくつかご紹介しましょう。詳細を知りたい場合は、[オープンソースプロジェクト向けのGitLabソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を読んでみてください。\n\n#### 脆弱性の早期発見と修正\n\nオープンソースは、コードが公開されているため、悪意のある人物が脆弱性を発見してしまうリスクがあります。\n\n[DevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/topics/devsecops/)であるGitLabは、開発プロセス全体においてセキュリティを重要視しています。静的アプリケーションセキュリティテスト（SAST）や依存関係スキャンといった強力なツールが、早期の脆弱性発見と修正を実現する仕組みを実現します。\n\n#### サポートの補完\n\nOSSはコミュニティによるサポートが中心となり、的確なサポートや迅速な対応を受けられないケースが発生することがあります。\n\n[商用版GitLab](https://about.gitlab.com/ja-jp/pricing/)には、「GitLab Premium」「GitLab Ultimate」があり、公式サポートという選択肢が用意されています。また、コミュニティの結束を高める働きかけをすることで自発的サポートも促進しています。\n\n#### コミュニティの活性化\n\n活発なコミュニティなしに、OSSを成功させることはできませんが、これを維持するのは容易ではありません。\n\nGitLabは、[GitLabフォーラム](https://forum.gitlab.com/c/community/gitlab-for-open-source/49)を運営したり、[オープンソース団体向けプログラム](https://about.gitlab.com/ja-jp/solutions/open-source/join/)を実施、GitLabハッカソンやオンラインイベントを開催したりすることで、デベロッパー同士の繋がりを促進、コミュニティの活性化と拡大に貢献しています。\n\n## オープンソースのライセンスとその重要性\n\nオープンソースのライセンスは、ソフトウェアの利用、配布、変更等に関する権利と制限を明記したものであり、法的拘束力を持ちます。よって、ソフト利用者はこれをしっかりと理解した上で、トラブル回避をすることが望ましいといえます。\n\nまた、ソフトウェアデベロッパーがどのライセンス規約にするかを考える場合には、透明性を重視するのか、自由度を重視するのかなどにより選択するライセンスが異なってきます。ここでは、いくつか代表的なものをご紹介しましょう。\n\n以下に表としてまとめてみました。\n\n![オープンソース　ライセンスのタイプと代表例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720035/v9ld6h78ilk22x30nged.jpg)\n\n### コピーレフト\n\nコピーレフトライセンスは、元となるソフトウェアを再配布する時には、派生物も元OSSと同じ条件下で行う必要があるというものです。このタイプのライセンスは、非常に伝播性が強いのが特徴です。\n\nまたコピーレフトという言葉は、「コピーライト」をもじったものから誕生しました。\n\n### 準コピーレフト\n\nコピーレフトと比べ、伝播性が多少弱いのが準コピーレフトです。元のOSSのソースコードを再利用した時に、元のライセンスと同条件で再配布する必要があります。\n\n### 非コピーレフト\n\nパーミッシブライセンスとも呼ばれます。名前の通りですが、元のOSSと同条件のライセンスにする必要がありません。ソースコードの公開義務がないため、商用利用されることが多いです。\n\n## よくある質問\n\n### オープンソースソフトウェア（OSS）とは何ですか？\n\nOSSとは、ソースコードが公開され、誰でも自由に利用、修正、配布できるソフトウェアのことです。\n\n### OSSのセキュリティは安心ですか？\n\nOSSライセンスは、ソフトウェアの利用や再配布に関する自由と制約を明確に定義したものです。\n\n### OSSのライセンスにはどんな種類がありますか？\n\nライセンスにはGPL、MIT、Apache Licenseなど、異なる自由度や利用条件を持つものがあり、コピーレフト、準コピーレフト、非コピーレフトの３つに大別されます。\n\n### なぜ企業がOSSを採用するのですか？\n\nコスト削減、柔軟性、信頼性向上、技術コミュニティとの連携が理由となる場合が多いです。またGitLabでは、[オープンソースプロジェクト向けのソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を提供しています。ぜひご確認ください。\n\n*監修：佐々木 直晴* [@naosasaki](https://gitlab.com/naosasaki)*（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[701,270,9,808],{"featured":91,"template":681,"slug":916},"what-is-open-source","content:ja-jp:blog:what-is-open-source.yml","What Is Open Source","ja-jp/blog/what-is-open-source.yml","ja-jp/blog/what-is-open-source",{"_path":922,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":923,"content":929,"config":934,"_id":936,"_type":14,"title":937,"_source":16,"_file":938,"_stem":939,"_extension":19},"/ja-jp/blog/what-is-sbom",{"title":924,"description":925,"ogTitle":924,"ogDescription":925,"noIndex":6,"ogImage":926,"ogUrl":927,"ogSiteName":669,"ogType":670,"canonicalUrls":927,"schema":928},"SBOMの基本と導入方法｜ソフトウェアのセキュリティを守るための実践ガイド","この記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663321/Blog/Hero%20Images/SBOM_keyvisual.jpg","https://about.gitlab.com/blog/what-is-sbom","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SBOMの基本と導入方法｜ソフトウェアのセキュリティを守るための実践ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-26\",\n      }",{"title":924,"description":925,"authors":930,"heroImage":926,"date":931,"body":932,"category":808,"tags":933},[890,761],"2025-03-26","ソフトウェア開発において、セキュリティリスクへの対応は年々重要性を増しています。特に、OSS（オープンソースソフトウェア）の普及に伴い、脆弱性管理やライセンス対応の課題に直面している方も多いのではないでしょうか。\n\nこうした中で注目を集めているのが、ソフトウェアの構成要素を可視化する「SBOM」です。本記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。セキュリティの強化や開発の効率化を目指す方は、ぜひ参考にしてください。\n\n## 1. SBOMとは？基本知識と重要性\n\nSBOMは「Software Bill of Materials」の略で、ソフトウェアに含まれるすべての構成要素（コンポーネント）を一覧化した「部品表」のことです。\n\nSBOMには、使用されているOSS、サードパーティ製ライブラリ、独自開発のコンポーネントなど、ソフトウェアを構成するすべての要素を記載します。各コンポーネントのバージョン情報、ライセンス情報、依存関係なども含まれており、これらの情報を一元管理し、製品全体の透明性や安全性を確保する重要な役割を果たします。\n\n## 2. SBOMが注目されている背景\n\n![SBOMとは3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF3.jpg)\n\n近年、ソフトウェア開発の環境が大きく変化する中で、SBOMの重要性が急速に高まっています。ここでは、SBOMの注目度が高まっている3つの背景について、詳しく見ていきましょう。\n\n### 2-1 ソフトウェアサプライチェーン攻撃の増加\n\nソフトウェアサプライチェーン攻撃とは、開発・供給過程で使用されるソフトウェアやツールに不正なコードや脆弱性を仕込む手法です。この攻撃は、正規の更新プログラムやコンポーネントを介して攻撃が拡散するという特徴があります。信頼される配布チャネルを利用するため攻撃の検知が極めて困難であり、被害が広範囲に及ぶケースも少なくありません。\n\n独立行政法人 情報処理推進機構（IPA）が発表した「[情報セキュリティ10大脅威 2024[組織]](https://www.ipa.go.jp/security/10threats/10threats2024.html)」（外部サイト）では、サプライチェーンを狙った攻撃が2位にランクインしており、その深刻さが伺えるでしょう。また、同ランキングの5位「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」や7位「脆弱性対策情報の公開に伴う悪用増加」では、脆弱性が指摘されたコンポーネントの存在や依存関係を迅速に把握できなければ、被害拡大の要因になります。\n\nこのような背景から、ソフトウェアの構成要素を詳細に可視化し、脆弱性や不正コードの混入を早期に検知できるSBOMの重要性が高まっています。\n\n#### 2-1-1 アメリカの大統領令のひとつにSBOMの提供が挙げられたことも\n\n2020年に発生したSolarWinds事件は、サプライチェーン攻撃の脅威を世界に示した象徴的な出来事です。この事件では、SolarWinds社が提供するツールを通じてマルウェアが配布され、約17,000の企業・組織に影響を与えています。\n\nこれを受け、2021年にはアメリカ政府が「国家のサイバーセキュリティ向上に関する大統領令」を発令しました。この中でSBOMの提供が重要な要件として位置づけられ、連邦政府機関に製品を提供するソフトウェア開発者や供給者は、正確なSBOMを提供することが求められるようになりました。\n\n### 2-2 OSSの普及\n\nOSSは、現代のソフトウェア開発において不可欠な要素のひとつです。OSSの活用は、開発コストの削減や開発スピードの向上、品質の確保など、多くのメリットをもたらします。\n\n一方で、OSSの利用拡大に関しては、一部課題もあります。特に深刻なのが、OSSコンポーネントを標的としたサプライチェーン攻撃の増加です。また、使用しているOSSの脆弱性対応やライセンスコンプライアンスの確保も、重要な課題となっています。\n\nこのような課題を解決するためにも、OSSを含めコンポーネントのバージョンやライセンス情報まで管理できるSBOMの有効性が注目されるようになりました。\n\n### 2-3 経済産業省による推進\n\n日本でSBOMへの注目が高まっている要因のひとつとして、経済産業省による積極的な推進も挙げられます。同省では、サイバーセキュリティリスクの増大に対応するため、SBOMの活用を含めた包括的なセキュリティ対策の強化を推進しています。\n\nたとえば、2024年8月には、SBOMを導入する具体的なメリットや導入プロセスを詳細に解説した「[ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0](https://www.meti.go.jp/press/2023/07/20230728004/20230728004-3.pdf)」が公開されました。\n\nまた、中小企業も含め、あらゆる企業でSBOM導入を効率的に活用できるよう、検討会や啓発活動も行われています。これらの取り組みにより、SBOMは今後さらに普及が進んでいくでしょう。\n\n## 3. SBOMを導入すべき理由とその効果\n\n![SBOMとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF.jpg)\n\nSBOMの導入によって、セキュリティリスクの可視化や脆弱性管理の効率化など、多くのメリットがあります。ここでは、SBOMを導入すべき理由とその効果について詳しく解説します。\n\n### 3-1 ソフトウェアサプライチェーンリスクの可視化\n\nSBOMを導入する最大のメリットのひとつは、ソフトウェアサプライチェーンのリスクを可視化できる点です。開発・運用するソフトウェアの全構成要素が一覧化され、各コンポーネントのバージョンや依存関係を明確に把握できるため、効率的かつ効果的なセキュリティ対策が可能となります。\n\n特に、複数のベンダーが関与する大規模なシステム開発において、すべてのコンポーネントが同じセキュリティ基準を満たしているかを確認するのは容易ではありません。一方、SBOMがあれば、各ベンダーが提供するソフトウェア部品のセキュリティ状況を統一的に管理でき、潜在的な不備やリスクを早期に発見できます。\n\nこのように、SBOMは組織のセキュリティリスク管理を強化し、セキュリティ事故を未然に防ぐための重要な基盤となります。\n\n### 3-2 脆弱性管理の効率化と迅速な対応\n\nSBOMを活用すると、システム全体の脆弱性管理を大幅に効率化できます。特に、新たな脆弱性が報告された際の迅速な対応が可能になるのは大きなメリットです。SBOMがあれば、脆弱性が指摘されたコンポーネントや、セキュリティリスクの高い古いバージョンのソフトウェアを即座に特定し、対処することができます。\n\nさらに、各コンポーネント間の依存関係も詳細に記録されているため、特定の脆弱性が他の部品に与える影響範囲の正確な把握が可能です。これにより、問題解決に向けた対応を効率的に進められ、被害を最小限に抑えられます。\n\nこのような迅速で正確な対応力は、セキュリティ事故への対処だけでなく、顧客や取引先からの信頼を維持するためにも欠かせません。\n\n### 3-3 コンプライアンス対応とライセンス管理\n\nSBOMは、ソフトウェア開発におけるコンプライアンス対応とライセンス管理の効率化を支援する強力なツールです。特にOSSを利用する場合、それぞれのコンポーネントには固有のライセンス条件が設定されており、これらを適切に管理しなければなりません。\n\nSBOMを活用すると使用しているOSSのライセンス情報を正確かつ迅速に確認できるため、ライセンス違反のリスクを回避できます。これにより、法的トラブルやブランドイメージの毀損といった事態も防げるでしょう。\n\nまた、ライセンス管理を手動で行う場合、見落としや記録ミスが発生しやすく、チェックに多くの時間を要するケースがあります。SBOMを活用するとライセンス情報の管理を自動化でき、運用効率が大幅に向上するのもメリットのひとつです。\n\n### 3-4 コスト削減や開発の効率化\n\nSBOMの導入は、組織全体のコスト削減や開発の効率化にも寄与します。まず、脆弱性の特定やライセンス違反の確認にかかる手間を大幅に削減できるため、人的リソースの効率的な活用が可能になります。\n\nまた、セキュリティリスクの早期発見と対応が可能になることで、インシデントへの対処や顧客補償にかかるコストを抑えられる点も大きなメリットです。加えて、ライセンス違反による法的対応コストや、プロジェクトの遅延によるペナルティコストなども抑えられます。\n\nさらに、ソフトウェアの全体構成が明確になるため、新しい機能追加やメンテナンス作業も効率的に行えます。そのため、SBOMの活用は、結果として開発チームの生産性の向上にもつながるでしょう。\n\n## 4. SBOMツールを導入する際の課題\n\n![SBOMとは4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF4.jpg)\n\nSBOMを作成するには、専用ツールの導入が一般的です。しかし、適切なツールの選定や運用に必要なリソースの確保といった課題に直面するケースも少なくありません。ここでは、SBOMツールの導入時に、特に注意しておきたい2つの課題を紹介します。\n\n### 4-1 ツール選びが難航する可能性がある\n\nSBOMツールは有償版と無償版を含め多くの選択肢があり、それぞれの特徴を理解したうえで適切なツールを選定しなければなりません。\n\n有償ツールは機能が豊富でサポートが充実していますが、導入コストが高くなる傾向があります。一方、無償ツールはコスト負担が少ないものの、機能やサポート範囲が限定的な場合が多く、使い方によっては十分な効果が得られない可能性があります。さらに、海外製のSBOMツールは問い合わせやサポートが英語のみの場合もあり、言語の壁が障害となるケースも考えられます。\n\nこのように、SBOMツールを選定する際には、ツールの特性だけでなく、自社のニーズやリソースに適合しているかを慎重に評価することが重要です。\n\n### 4-2 SBOMの運用には十分なリソースが必要\n\nSBOMを効果的に運用するには、まずツールを使いこなすための専門知識とスキルを持つ人材が必要不可欠です。特に、SBOMの作成や更新、脆弱性情報のモニタリング、影響範囲の分析といった業務を適切に行うには、高度なスキルと経験が求められます。また、有償ツールを導入する場合には、ライセンス料や月額費用といった運用コストが発生するため、予算の確保も課題のひとつです。\n\nさらに、SBOM運用の効果を十分に発揮するためには、運用プロセスの標準化や体制の整備も必要です。運用体制が不十分だとSBOMの管理が滞り、結果としてセキュリティリスクの増大やコンプライアンス違反などを招く可能性が高まります。\n\nこのように、SBOMの効果を最大限に引き出すには十分なリソースを確保する必要があり、これらが不足すると適切に運用できないおそれがあるため、注意が必要です。\n\n## 5. SBOMを導入する流れ\n\n![SBOMとは2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF2.jpg)\nSBOMを導入するには、社内体制の整備やツールの選定、解析作業など、いくつかのステップを踏む必要があります。スムーズに導入を進められるよう、事前に各工程のポイントを把握しておきましょう。以下で、具体的なSBOM導入の流れを解説します。\n\n### 5-1 社内体制の構築\n\nSBOMを効果的に導入・運用するためには、まず社内体制を整える必要があります。SBOM活用を推進する責任者を配置し、組織体制を整備しましょう。また、課題でも触れたように、実際にSBOMを管理・運用できる専門的な知識やスキルを持つ人材の確保も欠かせません。さらに、作成したSBOMの管理体制や管理方法を事前に決定しておくと、スムーズに運用を開始できます。\n\n### 5-2 SBOMツールの選定\n\nSBOMツールは、自社の目的や規模に応じたものを選ぶことが重要です。経済産業省の手引では、次のような選定観点の例が示されています。\n\n* 機能  \n* 性能  \n* 解析可能な情報  \n* データ形式  \n* コスト  \n* 対応フォーマット  \n* コンポーネント解析方法  \n* サポート体制  \n* 他ツールとの連携  \n* 提供形態  \n* ユーザーインターフェース  \n* 運用方法  \n* 対応するソフトウェア開発言語  \n* 日本語対応 など\n\nこれらに関して自社の制限や優先度を明確にした上で、最適なSBOMツールを選びましょう。\n\n参考：[ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ～全体概要～（経済産業省）](https://www.meti.go.jp/press/2023/07/20230728004/20230728004-3.pdf)\n\n### 5-3 コンポーネントの解析\n\n選定したSBOMツールを導入したら、対象ソフトウェアのスキャンを行い、コンポーネントを解析します。この段階で、誤検出や検出漏れがないかを慎重に確認しておかなければなりません。特に、重要なコンポーネントが漏れている場合、脆弱性やライセンスの管理に重大な影響を及ぼす可能性があるため、解析結果を丁寧に精査することが大切です。\n\n### 5-4 SBOMの作成と共有\n\n解析したコンポーネントのデータをもとに、SBOMを作成します。SBOMのフォーマットや項目、出力ファイル形式などについてあらかじめ基準を決めておくと、効率的にSBOMの作成を進められます。また、SBOMを対象ソフトウェアの利用者やサプライヤーに共有する際は、その方法についても事前に検討しておきましょう。\n\nたとえば、クラウドストレージやWebサイト、製品への組み込みなど、SBOMの共有方法にはいくつかの選択肢があります。公開範囲やデータ改ざん防止策、サプライヤーからの要件なども踏まえて、適切な方法を採用してください。\n\n### 5-5 SBOMの運用と管理\n\nSBOMは作成して終わりではなく、継続的な運用と管理が求められます。定期的に脆弱性スキャンを実施し、セキュリティ事故やコンプライアンス違反のリスクがないか確認しましょう。脆弱性情報が自動更新・通知されるツールを活用すれば、効率的かつ正確な運用が可能です。さらに、ソフトウェアのアップデートや新規コンポーネントの追加があった際にはSBOMも適宜更新し、常に最新の状態を保つ必要があります。\n\n### 5-6 SBOMの運用にAIを活用する方法も\n\nSBOMを効率的に運用・管理するために、AIを活用する方法もあります。過去の脆弱性データからSBOMに含まれるコンポーネントの潜在的なリスクを事前に予測する機能や、ソフトウェアの更新やコンポーネントの追加に応じて自動でSBOMを作成・更新する機能を活用すれば、管理負担の大幅な軽減が可能です。\n\n例えば、AI搭載のDevSecOpsプラットフォーム「[GitLab](https://about.gitlab.com/ja-jp/)」はSBOMを生成する機能がソースコード管理サービスと一体化していて、普段のソフトウェア開発とコンテキストスイッチなしに即時可視化状況を確認できるなど、独自の機能を備えています。\n\nまた、SBOMと脆弱性スキャンを連携させることで、依存コンポーネントの脆弱性を自動検出し、修復提案まで一元的に管理できるため、セキュリティ対策の効率が大幅に向上します。\n\n手間を削減しながらSBOMを適切に管理したい場合は、このような高性能なツールの活用を検討するとよいでしょう。\n\n## まとめ：SBOMを活用したセキュリティ対策が求められる\n\nSBOMは、ソフトウェアの構成要素を可視化し、脆弱性やライセンスの管理を効率的に行うための重要なツールです。特に、近年増加しているソフトウェアサプライチェーン攻撃やOSSの普及に伴うセキュリティリスクへの対策として、SBOMの注目度が高まっています。\n\nさらに、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)にセキュリティを融合させた「[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)」の実践においても、SBOMは重要な役割を果たします。セキュリティを確保しながら迅速に開発を進めたい場合にも、SBOMツールの活用を検討してみてください。\n\nより詳しい情報や、今後の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の展開について知りたい方は、ぜひ「2024 グローバルDevSecOpsレポート」をご活用ください。世界各地のDevSecOps専門家5000名を対象に行った調査結果をご覧いただけます。\n\n> [2024グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-sbom)  \n\n*監修：ハシュカ アンドリュー / Andrew Haschka [@ahaschka](https://gitlab.com/ahaschka)\u003Cbr>\n（GitLab フィールド最高技術責任者）*",[808,810,811,9],{"slug":935,"featured":91,"template":681},"what-is-sbom","content:ja-jp:blog:what-is-sbom.yml","What Is Sbom","ja-jp/blog/what-is-sbom.yml","ja-jp/blog/what-is-sbom",{"_path":941,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":942,"content":948,"config":953,"_id":955,"_type":14,"title":956,"_source":16,"_file":957,"_stem":958,"_extension":19},"/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull",{"title":943,"description":944,"ogTitle":943,"ogDescription":944,"noIndex":6,"ogImage":945,"ogUrl":946,"ogSiteName":669,"ogType":670,"canonicalUrls":946,"schema":947},"git fetchとgit pullのコマンド上での違いとは？","git pullは、git fetchと同時にgit mergeを実施するgitコマンドのことです。この記事では、それぞれの特徴と適した用途をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665856/Blog/Hero%20Images/AdobeStock_869074524.jpg","https://about.gitlab.com/blog/what-is-the-difference-between-git-fetch-and-git-pull","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"git fetchとgit pullのコマンド上での違いとは？\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-25\",\n      }",{"title":943,"description":944,"authors":949,"heroImage":945,"date":950,"body":951,"category":10,"tags":952},[890],"2024-07-25","# \u003CH1> git fetchとgit pullの違いとは？\u003C/H1> \ngitコマンドは、[分散型バージョン管理システム](https://about.gitlab.com/ja-jp/solutions/source-code-management/)として非常に人気があり、リモートリポジトリとの同期が必須です。開発に携わるエンジニアは、プロジェクトのニーズに応じて、適切なコマンドを選択する必要があります。この記事では、git fetchとgit pullの基本とその相違点を説明し、それぞれの使用目的について詳しく解説していきます。\u003Cbr>\n\n## 目次\n\n1. git fetchとgit pullの基本\n2. git fetchとは\n3. git pullとは\n4. git fetchを使うべき場面とは\n5. git pullを使うべき場面とは\n6. git fetchとgit pullに関する FAQ\n\n## \u003CH2> git fetchとgit pullの基本 \u003C/H2>  \ngit fetch（git フェッチ）とgit pull（git プル）は、両方ともgitのコマンドであり、リモートリポジトリから更新情報を取得するために使用されます。\nでは、なにが異なるのでしょうか。git fetchは、リモートリポジトリの変更状況をローカルリポジトリにダウンロードしますが、現在の作業ディレクトリには変更を加えません。ローカルのブランチにマージされないため、作業中に中断を引き起こすことなく、リモートリポジトリの変更を確認できることが利点です。\n一方git pullとは、リモートリポジトリから最新の変更を取得するところまではgit fetchと同様ですが、さらに現在のブランチに自動的にmerge（マージ）するコマンドです。リモートリポジトリの変更が直接ローカルの作業ディレクトリにも反映される点が、git fetchとの違いです。\n\n## \u003CH2> git fetchとは \u003C/H2>  \ngit fetchコマンドは、リモートリポジトリから最新のコミット履歴を取得しますが、ローカルの作業ディレクトリには反映されません。リモートの変更を取得しても、ローカルのブランチには反映されません。\n主に、リモートリポジトリの最新の状態を取得し、それがローカルリポジトリに反映される前に、変更内容を確認したい場合に使用されます。\n取得した変更内容をローカルブランチに適用するには[git mergeやgit rebase](https://docs.gitlab.com/ee/user/project/merge_requests/methods/)を手動で実行する必要があります。\n\n## \u003CH2> git pullとは \u003C/H2>\ngit pullコマンドは、`git fetch`と`git merge`（または`git rebase`）の組み合わせを一つのコマンドで実行します。これにより、リモートリポジトリの変更を取得してローカルの現在のブランチに自動的に統合します。git fetchはリモートリポジトリの変更を取得してローカルに反映させないのに対し、git pullを実行すると、リモートからの変更がローカルブランチに自動的に統合します。\n\n`git pull`は、リモートの変更をローカルのブランチに迅速に反映させるのに適していますが、コンフリクトが発生する可能性があるため、特に複数人での作業時には注意が必要です。\n\n## \u003CH2> git fetchを使うべき場面とは \u003C/H2> \ngit fetchは、リモートリポジトリから最新の情報を取得するコマンドです。取得した情報はローカルのブランチには直接反映されることはありません。git pullを使うと、誤ったリモートブランチや問題のあるリモートブランチもすべてローカルブランチに反映されてしまいます。\n\nリモートおよびローカルの両方で同時に変更が加えられている場合や、開発初心者の方がいるチームでは、git fetchを使ってリモートブランチの内容を取得してからmergeまたはrebaseするのが安全です。\n\n## \u003CH2> git pullを使うべき場面とは \u003C/H2> \ngit pullはgit fetchと比較して、より多くのプロセスを実施してくれるコマンドです。git pullで、git fetchに加えて、git merge（マージ）またはgit Rebase（リベース）を実施することができます。このため、リモートリポジトリの変更をローカルのブランチに素早く反映したいときにおすすめです。\n\n## \u003CH2> git fetchとgit pullに関する FAQ\u003C/H2> \n### \u003CH3> git pullと git fetchはなにが違うの？\u003C/H3> \ngit pullは、git fetch + git mergeもしくはgit fetch + git rebaseを実施するコマンドです。git fetchがローカルリポジトリに影響を与えないのに対し、git pullはリモートリポジトリの変更をローカルリポジトリにも自動で同期します。\n\n### \u003CH3> git pullを使用する際の注意点は？\u003C/H3> \ngit pullを実行する際には、リモートとローカルの変更が競合することがあります。特にマージコンフリクトが発生しやすいので、コンフリクトが発生した場合には手動で解決する必要があります。また、git pull --rebaseを使うことで、リベースを行いながら最新の変更を取り込むこともできます。\n\n### \u003CH3> git fetchは何のために使うの？\u003C/H3> \ngit fetchは、リモートリポジトリの最新の状態を確認・取得するのに役立ちます。しかし、取得した変更はローカルのブランチに自動的に反映されず、ローカルとリモートのリポジトリを同期するために使用されます。\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[678,9],{"slug":954,"featured":91,"template":681},"what-is-the-difference-between-git-fetch-and-git-pull","content:ja-jp:blog:what-is-the-difference-between-git-fetch-and-git-pull.yml","What Is The Difference Between Git Fetch And Git Pull","ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull.yml","ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull",{"_path":960,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":961,"content":967,"config":972,"_id":974,"_type":14,"title":975,"_source":16,"_file":976,"_stem":977,"_extension":19},"/ja-jp/blog/what-is-yaml",{"ogTitle":962,"schema":963,"ogImage":964,"ogDescription":965,"ogSiteName":669,"noIndex":6,"ogType":670,"ogUrl":966,"title":962,"canonicalUrls":966,"description":965},"拡張子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":962,"description":965,"authors":968,"heroImage":964,"date":969,"body":970,"category":833,"tags":971},[890,761],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[895,725,810,109,533,894,702,703,9,678],{"slug":973,"featured":91,"template":681},"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":979,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":980,"content":983,"config":990,"_id":992,"_type":14,"title":993,"_source":16,"_file":994,"_stem":995,"_extension":19},"/ja-jp/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":981,"description":982},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",{"title":981,"description":982,"authors":984,"heroImage":986,"body":987,"date":988,"category":10,"tags":989},[985],"Justin Tobler","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","Gitプロジェクトは最近、[Gitバージョン2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u)をリリースしました。今回のリリースの注目すべきポイントをいくつかご紹介します。これには、GitLabのGitチームやより広範なGitコミュニティからのコントリビュートも含まれています。\n\n## 新しいgit-diff-pairs(1)コマンド\n\n\n差分は、すべてのコードレビューの中心となるもので、2つのリビジョン間で行われた\n\nすべての変更を表示します。GitLabでは、さまざまな場所で差分が表示されますが、最も\n\n一般的なのはマージリクエストの[「変更」タブ](https://docs.gitlab.com/user/project/merge_requests/changes/)です。\n\nその裏側では、差分の生成に[`git-diff(1)`](https://git-scm.com/docs/git-diff)が\n\n使われています。たとえば、以下のように使います。\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nこのコマンドは、変更されたすべてのファイルの完全な差分を返します。ただし、リビジョン間で変更されたファイル数が非常に多い場合、スケーラビリティの課題が生じる可能性があります。GitLabのバックエンドでは、コマンドが自己設定されたタイムアウトに達してしまうこともあります。変更数が多い場合、\n\n差分の計算をより小さく扱いやすい単位に分割できる方法があれば、より効果的です。\n\n\nこの課題を解決する1つの方法は、\n\n[`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree)を使って、\n\n変更されたすべてのファイルに関する情報を取得することです。\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n\n```\n\n\nGitはこの出力を[「raw」フォーマット](https://git-scm.com/docs/git-diff-tree#_raw_output_format)と呼んでいます。\n\n簡単に言えば、出力の各行にはファイルのペアと、\n\nそれらの間で何が変更されたかを示すメタデータが表示されます。大規模な変更に対して\n\n「パッチ」形式の出力を生成する方法と比べて、\n\nこの処理は比較的高速な上、すべての変更の概要を把握できます。また、このコマンドでは、`-M`フラグを付けることでリネーム検出を有効にし、変更がファイルのリネームによるものかどうかを判別することもできます。\n\n\nこの情報を使えば、`git-diff(1)`を使って各ファイルペアの差分を\n\n個別にコンピューティングすることができます。たとえば、以下のようにblob IDを\n\n直接指定することも可能です。\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nこの処理は、各ファイルペアごとに繰り返すことができますが、\n\n個別のファイル差分ごとにGitプロセスを立ち上げるのは、あまり効率的ではありません。\n\nさらに、blob IDを使った場合、変更ステータスやファイルモードといった、\n\n親ツリーオブジェクトに格納されているコンテキスト情報が差分から失われてしまいます。\n\n本当に必要なのは、「raw」なファイルペア情報を元に、\n\n対応するパッチ出力を生成する仕組みです。\n\n\nバージョン2.50から、Gitに新しい組み込みコマンド\n\n[`git-diff-pairs(1)`](https://git-scm.com/docs/git-diff-pairs)が追加されました。このコマンドは、\n\n標準入力（stdin）から「raw」形式のファイルペア情報を受け取り、どのパッチを出力すべきかを正確に判断します。以下の例は、\n\nこのコマンドの使用方法を示しています。\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nこのように使用した場合、出力結果は`git-diff(1)`を使った場合と同じになります。\n\nパッチ出力を生成する専用コマンドを分けることで、\n\n`git-diff-tree(1)`から得られた「raw」出力を、より小さなファイルペアのバッチに分割し、それぞれを別々の\n\n`git-diff-pairs(1)`プロセスにフィードすることができます。これにより、差分を一度にすべてコンピューティングする必要がなくなるため、\n\n先に挙げたスケーラビリティの課題が解決されます。今後のGitLabリリースでは、\n\nこの仕組みの応用により、\n\n特に変更量が多い場合における差分生成のパフォーマンス向上が\n\n期待されます。この変更についての詳細は、該当する\n\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/)をご覧ください。\n\n\n_このプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。_\n\n\n## 参照更新の一括処理\n\n\nGitには、参照を更新するための[`git-update-ref(1)`](https://git-scm.com/docs/git-update-ref)\n\nコマンドが用意されています。このコマンドを`--stdin`フラグとともに使用すると、\n\n複数の参照を1つのトランザクションとしてまとめて更新できます。\n\nこれを行うには、各参照更新の指示を標準入力（stdin）で指定します。\n\nこの方法で参照を一括更新すると、アトミックな動作も実現できます。つまり、1つでも参照の更新に失敗した場合、\n\nトランザクション全体が中断され、\n\nどの参照も更新されません。以下は、この動作を示す例です。\n\n\n```shell\n\n# 3つの空のコミットと「foo」という名前のブランチを持つリポジトリを作成する\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n\n# コミットIDを出力する\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n\n# 指定された古いオブジェクトIDが一致しないため、更新は失敗することが予想されます。\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# 「bar」リファレンスは作成されませんでした。\n\n$ git switch bar\n\nfatal: invalid reference: bar\n\n```\n\n\n多くの参照を個別に更新する場合と比べて、一括で更新するほうがはるかに効率的です。\n\nこの方法は基本的にうまく機能しますが、\n\n一括更新による効率面のメリットを優先するために、\n\nリクエストされた参照更新の一部が失敗することを許容したい場合も\n\nあります。\n\n\n今回のリリースで、`git-update-ref(1)`に新しく`--batch-updates`オプションが追加されました。\n\nこのオプションを使用すると、1つ以上の参照更新が失敗しても、処理を続行できるようになります。\n\nこのモードでは、個々の失敗が次の形式で出力されます。\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n```\n\n\nこれにより、成功した参照の更新はそのまま進行しつつ、どの更新が拒否されたのか、\n\nまたその理由についての情報も得ることができます。前の例と同じリポジトリを\n\n使った例は以下のとおりです。\n\n\n```shell\n\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# 「foo」への更新が拒否されたにもかかわらず、「bar」参照が作成されました。\n\n$ git switch bar\n\nSwitched to branch 'bar'\n\n```\n\n\n今回は`--batch-updates`オプションを使用したことで、\n\n更新処理が失敗しても参照の作成は成功しました。この一連のパッチは、\n\n`git-fetch(1)`や`git-receive-pack(1)`における今後の一括参照更新時の\n\nパフォーマンス改善の基盤となります。詳細については、該当する\n\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)をご覧ください。\n\n\n_このプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n\n## git-cat-file(1)の新しいフィルタオプション\n\n\n[`git-cat-file(1)`](https://git-scm.com/docs/git-cat-file)を使うと、\n\nリポジトリ内に含まれるすべてのオブジェクトの情報を\n\n`--batch–all-objects`オプションで出力できます。たとえば、以下のように実行します。\n\n\n```shell\n\n# シンプルなリポジトリを設定します。\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n\n# 到達不能なオブジェクトを作成します。\n\n$ git commit --amend --no-edit\n\n\n# git-cat-file(1)を使用して、到達不能なオブジェクトを含むすべてのオブジェクトに関する情報を出力します。\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\n状況によっては、リポジトリ内のすべてのオブジェクトを検索し、\n\n特定の属性に基づいて一部のオブジェクトだけを出力したい場合があります。\n\nたとえば、コミットオブジェクトだけを表示したいときは、\n\n`grep(1)`を使って以下のように実行できます。\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nこの方法でも目的は達成できますが、出力のフィルタリングには欠点があります。\n\nそれは、`git-cat-file(1)`が\n\nユーザーが関心を持っていないオブジェクトも含め、リポジトリ内のすべてのオブジェクトをたどらなければならない点です。これはかなり非効率です。\n\n\n今回のリリースでは、`git-cat-file(1)`に`--filter`オプションが追加され、\n\n指定した条件に一致するオブジェクトだけを表示できるようになりました。これは`git-rev-list(1)`にある同名のオプションと似ていますが、\n\n対応しているフィルターの種類はその一部に限られています。\n\n対応しているフィルターは`blob:none`、`blob:limit=`および\n\n`object:type=`です。先ほどの例と同様に、オブジェクトはGitを使用して直接\n\n種類でフィルタリングできます。\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nGitに処理を任せられるのは便利なだけでなく、オブジェクト数の多い大規模なリポジトリにおいては\n\n効率面のメリットも期待できます。\n\nリポジトリにビットマップインデックスがある場合、\n\nGitが特定の種類のオブジェクトを効率的に検索できるようになり、パックファイル全体をスキャンする必要がなくなるため、\n\n処理速度が大幅に向上します。\n\n[Chromiumリポジトリ](https://github.com/chromium/chromium.git)で行われた\n\nベンチマークでは、こうした最適化による大きな改善が確認されています。\n\n\n```text\n\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs\n\nSummary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter ```\n\n\n興味深いことに、これらの結果からは、処理時間がパックファイル内の総オブジェクト数ではなく、\n\n指定された種類のオブジェクト数に比例して増減することが示されています。\n\n元のメーリングリストのスレッドは、\n\n[こちら](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/)でご覧いただけます。\n\n\n_このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。_\n\n\n## バンドル生成時のパフォーマンスが向上\n\n\nGitには、指定した参照とそれに関連する到達可能なオブジェクトを含むリポジトリのアーカイブを生成する機能があります。\n\n具体的には、\n\n[`git-bundle(1)`](https://git-scm.com/docs/git-bundle)コマンドを使用します。この操作は、\n\nGitLabがリポジトリのバックアップを作成する際や、\n\n[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムの一部としても使用されます。\n\n\n何百万もの参照を含む大規模なリポジトリでは、\n\nこの操作に数時間から数日かかることもあります。たとえば、GitLabのメインリポジトリ\n\n（[gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)）では、\n\nバックアップに約48時間を要していました。調査の結果、バンドルに重複した参照が含まれないようにチェックする処理において、\n\nパフォーマンスのボトルネックが存在することが判明しました。\n\nこの実装では、すべての参照をイテレーションして比較するために入れ子の`for`loopが使われており、\n\n時間計算量はO(N^2)となっていました。これは、\n\nリポジトリ内の参照数が増えるほど、処理性能が大きく低下する構造です。\n\n\n今回のリリースでは、この問題に対応し、\n\nネストされたloopをマップ型のデータ構造に置き換えることで、処理速度が大幅に向上しました。以下は、\n\n10万件の参照を含むリポジトリでバンドルを作成した際のパフォーマンス改善を\n\n示すベンチマーク結果です。\n\n\n```text\n\nBenchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs\n\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master) ```\n\n\n詳しくは、\n\n[GitLabがリポジトリのバックアップ時間を48時間から41分に短縮した方法](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)を紹介するブログ記事をご覧ください。\n\n元のメーリングリストのスレッドは\n\n[こちら](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/)でご覧いただけます。\n\n\n_このプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n\n## バンドルURIのアンバンドルの改善\n\n\nGitの[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムは、\n\nフェッチするバンドルの場所をクライアントに提供することで、クローンやフェッチの速度を\n\n向上させることを目的としています。クライアントがバンドルをダウンロードすると、\n\n`refs/heads/*`以下の参照が、その関連オブジェクトとともにバンドルから\n\nリポジトリにコピーされます。バンドルには`refs/tags/*`のように\n\n`refs/heads/*`以外の参照も含まれていることがありますが、\n\nこれらはクローン時にバンドルURIを使用する場合、単に無視されていました。\n\n\nGit 2.50ではこの制限が解除され、\n\nダウンロードされたバンドルに含まれる`refs/*`に一致するすべての参照がコピーされるようになりました。\n\nこの機能を実装した[Scott Chacon](https://github.com/schacon)さんは、\n\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss)をクローンした際の\n\n挙動の違いを紹介しています。\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nこれらの結果を比較すると、Git 2.50はバンドル展開後に43,887個（40.42 MiB）のオブジェクトをフェッチしているのに対し、\n\nGit 2.49は合計で959,773個（366.94 MiB）のオブジェクトをフェッチしています。\n\nGit 2.50では、取得されるオブジェクト数が約95%、\n\nデータ量が約90%削減されており、クライアントとサーバーの双方にとってメリットがあります。\n\nサーバー側ではクライアントに送信するデータ量が大幅に減り、\n\nクライアント側でもダウンロードおよび展開するデータが少なくて済みます。Chaconさんの提供した例では、\n\nこれによって処理速度が25%向上しました。\n\n\n詳細については、\n\n該当する[メーリングリストのスレッド](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/)をご覧ください。\n\n\n_この一連のパッチは、[Scott Chacon](https://github.com/schacon)さんによって提供されました。_\n\n\n## 詳細はこちら\n\n\n本記事でご紹介したのは、最新リリースにおいてGitLabと広範なGitコミュニティによって行われた\n\nコントリビュートのごく一部にすぎません。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/)では、\n\nさらに詳しい情報をご覧になれます。また、\n\n[以前のGitリリースのブログ記事](https://about.gitlab.com/blog/tags/git/)もぜひご覧ください。GitLabチームメンバーによる過去の主なコントリビュートをご確認いただけます。\n","2025-06-16",[678,9,270],{"featured":91,"template":681,"slug":991},"what-s-new-in-git-2-50-0","content:ja-jp:blog:what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0","ja-jp/blog/what-s-new-in-git-2-50-0.yml","ja-jp/blog/what-s-new-in-git-2-50-0",{"_path":997,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":998,"content":1004,"config":1009,"_id":1011,"_type":14,"title":1012,"_source":16,"_file":1013,"_stem":1014,"_extension":19},"/ja-jp/blog/whats-new-in-git-2-46-0",{"title":999,"description":1000,"ogTitle":999,"ogDescription":1000,"noIndex":6,"ogImage":1001,"ogUrl":1002,"ogSiteName":669,"ogType":670,"canonicalUrls":1002,"schema":1003},"Git 2.46.0の新機能","ここでは、参照バックエンド移行ツールやトランザクションシンボリック参照の更新など、GitLabのGitチームやより広範なGitコミュニティがリリースにコントリビュートしたハイライトをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.46.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }",{"title":999,"description":1000,"authors":1005,"heroImage":1001,"date":1006,"body":1007,"category":10,"tags":1008},[985],"2024-07-29","Gitプロジェクトは最近[Gitバージョン2.46.0](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u)をリリースしました。GitLabのGitチームやより広範なGitコミュニティからのコントリビュートを含む、本リリースの主なハイライトをご覧ください。\n\n\n## 参照バックエンド移行ツール\n\n\n前回の[Git\n2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt?ref_type=heads)リリースでは、reftablesフォーマットが参照を保存するための新しいバックエンドとして導入されました。この新しい参照フォーマットは、参照数の増加に伴って大規模なリポジトリが直面する複数の課題を解決します。reftableバックエンドについての詳細は、前回の[Gitリリースに関するブログ記事](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)をお読みください。機能の紹介や、初心者向けガイドが掲載されているため、[reftablesの仕組みについて詳しく確認できます](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)。\n\n\nreftableバックエンドのオンディスクフォーマットは、既存のファイルバックエンドとは異なります。したがって、既存のリポジトリでreftableを使用するにはさまざまなフォーマット間の変換が必要となります。これを達成するため、参照バックエンド移行の実行時に利用可能な`migrate`サブコマンドを含む新しいgit-refs(1)コマンドが導入されました。以下は、このコマンドの使用方法の例です。\n\n\n```shell\n\n# reflogが含まれないようにするために、新規リポジトリを「bare」として初期化します。\n\n$ git init --bare .\n\n$ git commit --allow-empty -m \"init\"\n\n# リポジトリに、バックエンドのファイルへの参照を投入します。\n\n$ git branch foo\n\n$ git branch bar\n\n$ tree .git/refs\n\n.git/refs\n\n├── heads\n\n│   ├── bar\n\n│   ├── foo\n\n│   ├── main\n\n└── tags\n\n# reftableフォーマットへの参照移行を実行します。\n\n$ git refs migrate --ref-format=reftable\n\n# reftableバックエンドが使用されていることを確認します。\n\n$ tree .git/reftable\n\n.git/reftable\n\n├── 0x000000000001-0x000000000001-a3451eed.ref\n\n└── tables.list\n\n# リポジトリ設定をチェックして、`refstorage`フォーマットが変更されていることを確認します。\n\n$ cat config\n\n[core]\n        repositoryformatversion = 1\n        filemode = true\n        bare = true\n        ignorecase = true\n        precomposeunicode = true\n[extensions]\n        refstorage = reftable\n```\n\n\nリポジトリが移行されるとオンディスクフォーマットが変更され、reftableバックエンドを使用するようになります。リポジトリに対するGit操作は引き続き機能し、以前と同様にリモートでやり取りを行います。移行はリポジトリ内での参照の保存方法にのみ影響します。ファイル参照バックエンドに戻したい場合は、代わりに`--ref-format=files`を指定して同じコマンドで実行します。\n\n\n移行ツールには現在いくつか留意すべき制限があります。リポジトリ内のreflogは参照バックエンドのコンポーネントであり、フォーマット間の移行が必要となります。残念ながら、現時点ではツールを使用してファイルとreftablesバックエンド間でreflogを変換することはできません。また、worktreeが含まれるリポジトリには基本的に複数のrefストアがありますが、移行ツールはまだこのようなシナリオに対応していません。したがって、リポジトリにreflogまたはworktreeが含まれている場合、現時点では参照移行を行えません。こうした制限は、今後のバージョンでなくなる可能性があります。\n\n\nbare\nGitリポジトリにはreflogが含まれないため、移行は簡単です。標準的なnon-bareリポジトリを移行するには、まずreflogを削除する必要があります。そのため、reflogやworktreeのないリポジトリであれば、すべて移行できます。こうした制限はありますが、このツールを使うことで既存のリポジトリでreftablesバックエンドを活用し始められます。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## トランザクションシンボリック参照の更新\n\n\n[git-update-ref(1)](https://git-scm.com/docs/git-update-ref)コマンドは、Gitリポジトリ内で参照更新を実行します。こうした参照更新は、`git\nupdate-ref\n--stdin`を使用してupdate-ref命令をstdinに渡すことで、トランザクションで一括してアトミックに実行することもできます。こちらは実行方法の例です。\n\n\n```shell\n\n$ git init .\n\n$ git branch -m main\n\n$ git commit --allow-empty -m \"foo\" && git commit --allow-empty -m \"bar\"\n\n# 作成された2つのコミットのオブジェクトIDを取得します。\n\n$ git rev-parse main~ main\n\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n\n# トランザクションを開始し、update-ref命令を出し、コミットします。\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> start\n\n> create refs/heads/new-ref 3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n\n> update refs/heads/main 567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n\n> commit\n\n> EOF\n\n$ git for-each-ref\n\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e commit refs/heads/main\n\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631 commit refs/heads/my-ref\n\n```\n\n\nこの例では、トランザクションがコミットされると「bar」コミットを指す新しいブランチが作成され、メインブランチは以前の\n「foo」コミットを指すよう更新されます。トランザクションをコミットすると、指定された参照更新がアトミックに実行されます。個々の参照更新が失敗した場合、トランザクションは中止され、参照更新は実行されません。\n\n\nここで注目すべきは、こうしたトランザクションでシンボリック参照更新をサポートする命令がないことです。ユーザーが、同一のトランザクション内で他の参照とともにシンボリック参照をアトミックに更新したい場合でも、それに対応できるツールはありません。今回のリリースでは、この機能を提供するために`symref-create`、`symref-update`、`symref-delete`、`symref-verify`命令が導入されました。\n\n\n```shell\n\n# 次の操作で更新されるシンボリック参照を作成します。\n\n$ git symbolic-ref refs/heads/symref refs/heads/main\n\n# シンボリック参照自体が更新されるようにするには、--no-derefフラグが必要です。\n\n$ git update-ref --stdin --no-deref \u003C\u003CEOF\n\n> start\n\n> symref-create refs/heads/new-symref refs/heads/main\n\n> symref-update refs/heads/symref refs/heads/new-ref\n\n> commit\n\n> EOF\n\n$ git symbolic-ref refs/heads/symref\n\nrefs/heads/new-ref\n\n$ git symbolic-ref refs/heads/new-symref\n\nrefs/heads/main\n\n```\n\n\n上記の例ではトランザクション内で新しいシンボリック参照が作成され、別のシンボリック参照が更新されています。こうした新しいsymref命令を既存の命令と組み合わせて使用することで、あらゆる種類の参照更新を単一のトランザクションで実行できます。新しい命令に関する詳細はこちらの[ドキュメント](https://git-scm.com/docs/git-update-ref)をご覧ください。\n\n\nこのプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n\n## git-config(1)のUXの改善\n\n\ngit-config(1)コマンドを使用すると、リポジトリやグローバルオプションの表示や設定を行えます。設定を行う際に使用するモードは、フラグを使用して明示的に選択したり、コマンドに指定した引数の数に基づいて暗黙的に決定したりすることができます。例：\n\n\n```shell\n\n$ git config --list\n\n# ユーザー名の設定を明示的に取得\n\n$ git config --get user.name\n\n# ユーザー名の設定を暗黙的に取得\n\n$ git config user.name\n\n# ユーザー名の設定を明示的に行う\n\n$ git config --set user.name \"Sidney Jones\"\n\n# ユーザー名の設定を暗黙的に行う\n\n$ git config user.name \"Sidney Jones\"\n\n# 3つ目の引数を指定することも可能です。これは何の役に立つのでしょうか？\n\n$ git config \u003Cname> [\u003Cvalue> [\u003Cvalue-pattern>]]\n\n```\n\n\n全体的に[git-config(1)](https://git-scm.com/docs/git-config)のユーザーインターフェイスは、サブコマンドを使うのが一般的な、他のより現代的なGitコマンドの動作とは一致していません（例：`git\nremist`）。このリリースではconfigコマンドで使用するサブコマンドとして`list`、`get`、`set`、`unset`、`rename-section`、`remove-section`、`edit`が導入されましたが、以前の形式の構文も引き続き使用できます。今回の変更はconfigコマンドをよりUIに沿ったものにし、Git内の他のコマンドとの整合性を高めてユーザーエクスペリエンスを向上させることを目的としています。以下は新しいコマンドの使用例です。\n\n\n```shell\n\n$ git config list\n\n$ git config get user.name\n\n$ git config set user.name \"Sidney Jones\"\n\n```\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって主導されました。\n\n\n## パフォーマンスのリグレッションへの対応\n\n\n属性を使用するGit操作は、リポジトリのworktreeにある`.gitattributes`ファイルの読み取りに依存しています。bare\nGitリポジトリの場合は定義上worktreeが欠如しているため、問題となります。これを回避するためGitには`attr.tree`という設定があり、SourceTreeを指定して属性を参照できます。\n\n\nGitリリース2.43.0では、bareリポジトリのGit属性のソースとして`HEAD`のツリーをデフォルトで使用するようになりました。残念なことに、Gitの属性ファイルのスキャンによる負荷の増加は、パフォーマンスに深刻な影響を及ぼす結果となっています。これは`attr.tree`が設定されている場合、属性を検索するたびにSourceTreeを開いて関連する`.gitattributes`ファイルを確認する必要があるためです。リポジトリのSourceTreeが大きく深くなればなるほど、性能のリグレッションも顕著なものとなります。たとえば、linux.gitリポジトリで実行されるベンチマークでは、git-pack-objects(1)完了までに1.68倍の時間がかかっています。これにより、クローンやフェッチを実行する際に速度が低下するおそれがあります。\n\n\n```\n\n# Gitバージョン2.43.0では、デフォルトでattr.treeがHEADに完了済みとして設定されています。\n\nBenchmark 1: git -c attr.tree=HEAD pack-objects --all --stdout \u003C/dev/null\n>/dev/null\n  Time (mean ± σ):     133.807 s ±  4.866 s    [User: 129.034 s, System: 6.671 s]\n  Range (min … max):   128.447 s … 137.945 s    3 runs\n\n# 2.43.0より前のバージョンのGitでは、属性検索を無効にするためにattr.treeが空のツリーに設定されていました。\n\nBenchmark 2: git -c attr.tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904\npack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     79.442 s ±  0.822 s    [User: 77.500 s, System: 6.056 s]\n  Range (min … max):   78.583 s … 80.221 s    3 runs\n```\n\n\n影響を受けた重要なGitコマンドには、前述のように大規模または深いツリーのあるリポジトリで使用された場合の`clone`、`pull`、`fetch`、`diff`などがあります。そのため、パフォーマンスのリグレッションに対処するために、'attr.tree`設定は部分的に元に戻され、デフォルトで`HEAD`に設定されることはなくなりました。詳細についてはこちらのメール[スレッド](https://lore.kernel.org/git/CAKOHPAn1btewYTdLYWpW+fOaXMY+JQZsLCQxUSwoUqnnFN_ohA@mail.gmail.com/)をご覧ください。\n\n\n## ユニットテストの移行\n\n\nこれまでGitプロジェクトでのテストは、シェルスクリプトとして実装されたE2Eテストを通じて行われてきました。Gitプロジェクトでは比較的最近、Cで書かれたユニットテストフレームワークが導入されました。この新しいテストフレームワークにより、個々の関数呼び出しレベルで低レベルの実装の詳細をより詳しくテストする機会がもたらされたほか、既存のE2Eテストが補完されます。既存のE2Eテストにはユニットテストにより適しているものがあり、移行に適しています。\n\n\n本年度も、GitLabは[Google Summer of\nCode（GSoC）](https://summerofcode.withgoogle.com/)のGitプロジェクトに参加するコントリビューターのメンターを務めています。進行中のGSoCプロジェクトとより広範なGitコミュニティの貢献により、既存のテストの一部がリファクタリングされ、ユニットテストフレームワークに移行されつつあります。前回のリリースサイクルでは、Gitプロジェクトのテストを改善するという目標に向けて複数のコントリビュートがありました。上述のGSoCコントリビューターのプロジェクトの詳細については、[Chandra](https://chand-ra.github.io/)および[Ghanshyam](https://spectre10.github.io/posts/)のブログをご確認ください。\n\n\n## バンドルURIの修正\n\n\n通常、クライアントがリモートリポジトリからフェッチする場合、必要なすべてのオブジェクトはリモートサーバーによって計算されたパックファイルで送信されます。こうした計算の一部を回避するため、サーバーは、リモートサーバーとは別に保存され、クライアントが必要とする可能性のある参照とオブジェクトのセットを含む事前構築の「バンドル」のアドバタイズを選択できます。クライアントは、[bundle-uri](https://git-scm.com/docs/bundle-uri)と呼ばれるメカニズムを介して最初にこうしたバンドルを取得できます。\n\n\n[Xing\nXin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/)さんのコントリビュートにより、いくつかのバンドルをダウンロードしたにもかかわらず、Gitがバンドルがないかのようにリモートからすべてをダウンロードし続けるという問題が特定・修正されました。これは、Gitがダウンロードしたすべてのバンドルを正しく検出できなかったために、リモートから連続したバンドルを取得する必要があったことが理由でした。この問題が修正されたことで、bundle-uriメカニズムを使用するリモートは冗長な作業を実行する必要がなくなったため、パフォーマンスが向上します。\n\n\n## 補足情報\n\n\n今回の記事では、最新リリースでGitLabとGitコミュニティが行ったコントリビュートのほんの一部をご紹介しました。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u)ではさらに詳しい情報をご覧いただけます。また、[以前のGitリリースのブログ記事](https://about.gitlab.com/blog/tags/git/)をチェックしてGitLabチームメンバーによる過去の主なコントリビュートをご覧ください。\n",[678,9,270],{"slug":1010,"featured":91,"template":681},"whats-new-in-git-2-46-0","content:ja-jp:blog:whats-new-in-git-2-46-0.yml","Whats New In Git 2 46 0","ja-jp/blog/whats-new-in-git-2-46-0.yml","ja-jp/blog/whats-new-in-git-2-46-0",{"_path":1016,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1017,"content":1023,"config":1028,"_id":1030,"_type":14,"title":1031,"_source":16,"_file":1032,"_stem":1033,"_extension":19},"/ja-jp/blog/whats-new-in-git-2-47-0",{"title":1018,"description":1019,"ogTitle":1018,"ogDescription":1019,"noIndex":6,"ogImage":1020,"ogUrl":1021,"ogSiteName":669,"ogType":670,"canonicalUrls":1021,"schema":1022},"Git 2.47.0の新機能","Gitの最新バージョンについてご紹介します。新たに追加されたグローバル変数を使用すれば、参照やオブジェクトのハッシュの形式を設定できます。GitLabのGitチームと、より広範なGitコミュニティによるコントリビュートをご確認ください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.47.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }",{"title":1018,"description":1019,"authors":1024,"heroImage":1020,"date":1025,"body":1026,"category":10,"tags":1027},[985],"2024-10-07","Gitプロジェクトは、最近[Gitバージョン2.47.0](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)をリリースしました。\n\nGitLabのGitチームやより広範なGitコミュニティからのコントリビュートを含む、本リリースの主なハイライトをご覧ください。\n\n\n## 新しいグローバル構成オプション\n\n\nGitの最新リリースをチェックしている方であれば、[Gitバージョン2.45](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)より新たに提供開始された「reftable」参照バックエンドについてご存知かもしれません。詳しくは、『[Git\nreftableフォーマットの入門ガイド](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)』をご確認ください。これまでは、「reftable」フォーマットを使用してリポジトリを初期化するには、次のようにgit-init(1)コマンドに`--ref-format`オプションを付けて実行する必要がありました。\n\n\n```sh\n\n$ git init --ref-format reftable\n\n```\n\n\nGit\n2.47のリリースでは、`init.defaultRefFormat`という設定オプションが追加され、リポジトリを初期化する際にどの参照バックエンドを使用するかをGitに指示できるようになりました。このオプションを使用することで、デフォルトの「files」バックエンドを上書きし、「reftable」バックエンドを利用できるようになります。設定するには、以下のコマンドを実行します\n\n\n```sh\n\n$ git config set --global init.defaultRefFormat reftable\n\n```\n\n\n一部の方はご存知かもしれませんが、Gitリポジトリで使用されるオブジェクトのハッシュ形式も設定可能です。デフォルトでは、リポジトリはSHA-1オブジェクト形式を使用するように初期化されますが、SHA-256形式というより安全で将来性のある代替案もあります。詳しくは、[GitalyにおけるSHA-256のサポートに関する過去のブログ記事](https://about.gitlab.com/blog/sha256-support-in-gitaly/#what-is-sha-256%3F)でご確認いただけます。SHA-256リポジトリは、git-init(1)に`--object-format`オプションを指定することで作成できます。\n\n\n```sh\n\n$ git init --object-format sha256\n\n```\n\n\nこのGitのリリースでは、別の設定オプションとして、`init.defaultObjectFormat`が追加されました。このオプションは、リポジトリを初期化する際に、どのオブジェクト形式をデフォルトで使用するかをGitに指示するものです。以下のコマンドで設定できます。\n\n\n```sh\n\n$ git config set --global init.defaultObjectFormat sha256\n\n```\n\n\n注意点として、SHA-256リポジトリはSHA-1リポジトリと互換性がなく、すべてのフォージがSHA-256リポジトリのホスティングをサポートしているわけではありません。先日GitLabが発表した[SHA-256リポジトリの実験的サポート](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/)をお試しになれます。\n\n\nこれらのオプションを使うことで、すぐにこれらのリポジトリ機能を使用できるようになり、新しいリポジトリを初期化するたびに形式について検討せずに済みます。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## git-refs(1)のサブコマンド\n\n\n前回のGitリリースでは、リポジトリ内の参照への低レベルアクセスを可能にするコマンド「[git-refs(1)](https://git-scm.com/docs/git-refs)」が導入されました。このコマンドには、参照バックエンド間での変換を行う「migrate」サブコマンドが含まれていました。今回のリリースでは、新たに「verify」サブコマンドが追加され、参照データベースの整合性を確認できるようになりました。リポジトリの整合性を確認する際には、「[git-fsck(1)](https://git-scm.com/docs/git-fsck)」を実行するケースが多々あります。\n\n\nしかし、このコマンドはリポジトリの参照データベースを明示的に検証するわけではありません。特に「reftable」というバイナリ形式の参照形式が導入されたことで、手動での検証が難しくなり、このギャップを埋めるツールの必要性が増しています。例として、無効な参照を設定したリポジトリを作成して検証してみましょう。\n\n\n```sh\n\n# The \"files\" backend is used so we can easily create an invalid reference.\n\n$ git init --ref-format files\n\n$ git commit --allow-empty -m \"init\"\n\n# A lone '@' is not a valid reference name.\n\n$ cp .git/refs/heads/main .git/refs/heads/@\n\n$ git refs verify\n\nerror: refs/heads/@: badRefName: invalid refname format\n\n```\n\n\nこの例では、無効な参照が検出され、エラーメッセージが表示されていることが確認できます。このツールはエンドユーザーが頻繁に使用するものではありませんが、サーバー側でリポジトリの整合性を保つために特に有用です。最終的には、このコマンドを「git-fsck(1)」に統合し、一貫したリポジトリ整合性チェックを行えるようにすることが目標です。\n\n\nこのプロジェクトは、Google Summer of Code（GSoC）の一環としてJialuo\nSheによって主導されました。詳しくは、Jialuoの『[GsoCレポート](https://luolibrary.com/2024/08/25/GSoC-Final-Report/)』をご参照ください。\n\n\n## reftableに関連した進行中の作業\n\n\n今回のリリースでは、「reftable」バックエンドに関するいくつかのバグ修正も含まれています。その中でも特に興味深いのは、テーブルの圧縮プロセスに関するバグです。\n\n\nご存知でない方のために説明すると、reftableバックエンドはリポジトリ内のすべての参照の状態を保持する一連のテーブルで構成されています。各参照のアトミックな変更が行われるたびに、新しいテーブルが作成され、「tables.list」ファイルに記録されます。テーブルの数を減らすために、参照の更新後には、テーブルがファイルサイズに基づいた幾何数列に従って圧縮されます。テーブルが圧縮されると、「tables.list」ファイルも更新され、ディスク上のreftableの最新の状態が反映されます。\n\n\n設計上、テーブルの書き込みと圧縮を同時に実行可能です。特定のタイミングでの同期は、ロックファイルを使用して制御されています。たとえば、圧縮が始まる際には、最初に「tables.list」ファイルが、安定した読み込みのためにロックされます。また、圧縮が必要なテーブルもロックされる場合があります。実際のテーブルの圧縮には時間がかかるため、ロックは途中で解除され、同時書き込みが実行されます。同時書き込みは、ロックされている圧縮対象のテーブルを変更してはいけないことを理解した上で行われるため、この処理は安全です。圧縮された新しいテーブルの書き込みが完了すると、再び「tables.list」ファイルがロックされ、今度は新しいテーブルの状態が反映されるように更新されます。\n\n\nしかし、次のような問題があります。もし、テーブルの圧縮中に最初のロックが解除された後、リストファイルが更新される前に、参照の同時更新によって新しいテーブルが「tables.list」に書き込まれたらどうなるでしょうか？このような競合が起こると、圧縮プロセスでは新しいテーブルの存在が認識されず、新しいテーブルを反映しないまま「tables.list」ファイルを書き直してしまいます。これにより、同時に行われた更新が失われ、参照が想定どおりに追加、更新、削除されない結果になる可能性があります。\n\n\n幸い、この問題は比較的簡単な手順で解決できます。圧縮プロセスで「tables.list」ファイルへの書き込みのためにロックが取得される際は、ファイルに更新があったかどうかを最初に確認してから、ファイルを再読み込みする必要があります。これにより、同時に行われたテーブルの更新も正しく反映されるようになります。こちらの修正について詳しくは、該当する[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1722435214.git.ps@pks.im/)をご参照ください。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## git-maintenance(1)の修正\n\n\nリポジトリが大きくなるにつれて、適切なメンテナンスが重要になります。デフォルトでは、Gitは特定のオペレーション後に[git-maintenance(1)](https://git-scm.com/docs/git-maintenance)を実行することで、リポジトリの健全性を保ちます。その際、不要なメンテナンスが行われないようにするために、`--auto`オプションが指定されています。このオプションでは、定義されたヒューリスティック（経験則）を使用してメンテナンスタスクを実行するかどうかを決定します。このコマンドは、さまざまなメンテナンスタスクを実行するように設定できますが、デフォルトでは、ユーザーが通常の作業を続けられるように、[git-gc(1)](https://git-scm.com/docs/git-gc)のみがバックグラウンドで実行されるようになっています。\n\n\nこの動作は通常、期待どおりに機能しますが、デフォルト以外のメンテナンスタスクを実行するように設定されている場合、設定されたメンテナンスタスクはフォアグラウンドで実行され、最初のメンテナンスプロセスはすべてのタスクが完了するまで終了しません。唯一「gc」タスクだけが期待どおりにバックグラウンドで実行されます。この原因は、git-gc(1)が`--auto`オプションで実行された際に、誤ってプロセスをデタッチしていたこと、また、ほかのメンテナンスタスクがそのような機能を持っていなかったことであると判明しました。この問題により、一部のGitコマンドが自動メンテナンスの完了を待機する必要があり、コマンドの実行速度が低下する可能性がありました。\n\n\n今回のリリースでは、git-maintenance(1)に`--detach`オプションが追加され、個々のタスクではなくgit-maintenance(1)全体のプロセスをバックグラウンドで実行できるようになったことで、この問題が解消されました。また、Gitが実行する自動メンテナンスもこの新しいオプションを使うように更新されています。こちらの修正について詳しくは、[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1723533091.git.ps@pks.im/)をご参照ください。\n\n\n前述したように、自動メンテナンスでは、特定のメンテナンス操作を実行すべきかどうかを判断するために一連のヒューリスティックが使用されます。しかし残念なことに、「files」参照バックエンドでは、[git-pack-refs(1)](https://git-scm.com/docs/git-pack-refs)が`--auto`オプションで実行された場合、このようなヒューリスティックが存在せず、疎な参照が必ず「packed-refs」ファイルにパック化されてしまいます。多くの参照を持つリポジトリでは、「packed-refs」ファイルの書き換えに時間がかかることがあります。\n\n\n今回のリリースでは、「files」バックエンドで疎な参照をパック化するかどうかを決定するヒューリスティックも導入されました。このヒューリスティックは、既存の「packed-refs」ファイルのサイズとリポジトリ内の疎な参照の数を考慮します。「packed-refs」ファイルが大きくなるほど、参照のパック化が実行される前に許容される疎な参照の数のしきい値も上がります。これにより、「files」バックエンドでの参照のパック化をやや抑制しつつ、適切にリポジトリがメンテナンスされた状態を保てます。詳しくは、[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1725280479.git.ps@pks.im/)をご参照ください。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## コードリファクタリングと保守性の向上\n\n\n機能の変更に加えて、コードリファクタリングやクリーンアップも進められています。これらの改善は、プロジェクトの内部コンポーネントをライブラリ化するという長期的な目標にも寄与するという点でも重要です。ライブラリ化に関する最新のアップデートについては、[こちらのスレッド](https://lore.kernel.org/git/eoy2sjhnul57g6crprxi3etgeuacjmgxpl4yllstih7woyuebm@bd62ib3fi2ju/)をご参照ください。\n\n\nメモリリークを解決することも、求められていた改善事項でした。Gitプロジェクトには多くのメモリリークが存在しますが、通常Gitプロセスは短時間しか動作せず、システムによるクリーンアップが後から行われるため、大きな問題が生じることはあまりありません。しかし、ライブラリ化を進める上では、この問題に対処する必要があります。リークサニタイザを使ってプロジェクト内のテストをコンパイルし、リークを検出することはできますが、既存のリークが存在しているために、新しい変更が新たなリークを引き起こしていないかを検証し、それを阻止するのは難しい状況でした。現在、プロジェクト内の既存のテストで検出されたすべてのメモリリークを修正する取り組みが進められています。リークのないテストは`TEST_PASSES_SANITIZE_LEAK=true`とマークされ、今後もリークが発生しないことが想定されます。今回のリリース以前は、プロジェクトにメモリリークを含むテストファイルが223件ありましたが、今回のリリースでは60件にまで減少しました。\n\n\nもう1つの取り組みとして、プロジェクト全体でグローバル変数の使用を減らす作業が進められています。その中でも特に問題視されているのが`the_repository`というグローバル変数で、これはオペレーション中のリポジトリの状態を保持し、プロジェクト内のさまざまな箇所で参照されています。今回のリリースでは、この`the_repository`の使用を減らし、必要な場所に直接値を渡すようにするための複数のパッチが導入されました。まだ`the_repository`に依存しているGitプロジェクトのサブシステムでは、このグローバル変数を使用できるようにするために`USE_THE_REPOSITORY_VARIABLE`が定義されています。現在ではrefs、config、pathのサブシステムはこの変数に依存しなくなりました。\n\n\nこのプロジェクトは、[John Cai](https://gitlab.com/jcaigitlab)と[Jeff\nKing氏](https://github.com/peff)の協力のもと、[Patrick\nSteinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## 補足情報\n\n\nこのブログ記事では、GitLabや広範なGitコミュニティによる最新リリースへのコントリビュートの一部をご紹介しました。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)では、さらに詳しい情報をご覧になれます。また、[過去のGitリリースに関するブログ記事](https://about.gitlab.com/blog/tags/git/)では、GitLabチームメンバーによるこれまでの主要なコントリビュートをご紹介しています。\n\n\n- [Git\n2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)\n\n- [Git\n2.45.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)\n\n- [Git\nreftableフォーマットの入門ガイド](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)\n\n- [git fetchとgit\npullコマンドの違いとは？](https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference/)\n",[678,9,270],{"slug":1029,"featured":91,"template":681},"whats-new-in-git-2-47-0","content:ja-jp:blog:whats-new-in-git-2-47-0.yml","Whats New In Git 2 47 0","ja-jp/blog/whats-new-in-git-2-47-0.yml","ja-jp/blog/whats-new-in-git-2-47-0",{"_path":1035,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1036,"content":1041,"config":1048,"_id":1050,"_type":14,"title":1051,"_source":16,"_file":1052,"_stem":1053,"_extension":19},"/ja-jp/blog/whats-new-in-git-2-48-0",{"title":1037,"description":1038,"ogTitle":1037,"ogDescription":1038,"noIndex":6,"ogImage":1020,"ogUrl":1039,"ogSiteName":669,"ogType":670,"canonicalUrls":1039,"schema":1040},"Git 2.48.0の新機能","Gitの最新バージョンについてご紹介します。新たなビルドシステムに加え、最適化された新しいreftableバックエンドが導入されました。また、GitLabのGitチームおよびGitコミュニティによるコントリビュートもご紹介します。","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.48.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }",{"title":1037,"description":1038,"authors":1042,"heroImage":1020,"date":1044,"body":1045,"category":10,"tags":1046,"updatedDate":1047},[1043],"Christian Couder","2025-01-10","Gitプロジェクトは先日[Git 2.48.0](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/)をリリースしました。本記事では、GitLabのGitチームや幅広いGitコミュニティからのコントリビュートなど、このリリースにおけるハイライトをご紹介します。\n\n## Mesonビルドシステム\n\nこれまで長い間、Gitは[Makefile](https://en.wikipedia.org/wiki/GNU_Make)ベースまたは[Autoconf](https://en.wikipedia.org/wiki/Autoconf)ベースのビルドシステムのいずれかを使用してビルドできる仕組みになっていました。しかし、Gitデベロッパーの多くはMakefileベースのビルドシステムを主に利用しており、[Autoconfベースのビルドシステムは機能やメンテナンスの面で後れ](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/)を取っていました。また、Windowsデベロッパーがよく利用する統合開発環境（IDE）は、MakefileやAutoconfベースのビルドシステムを十分にサポートしていないという問題もありました。\n\n2020年に[CMake](https://cmake.org/)を使用したGitのビルドが可能になり、特にVisual Studio向けに、WindowsでのサポートやIDE統合が改善されました。また、out-of-sourceビルドなどのモダンなビルドシステムも追加されました。\n\nしかし、最近ではCMakeのサポートも後れを取っており、前述の2つのビルドシステムを完全に置き換えるには適していない可能性が出てきました。こうした背景から、GitLabのGitエンジニアリングマネージャーである[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が、[Meson](https://mesonbuild.com/)ビルドシステムを導入しました。これにより、最終的にAutoconf、CMake、そして場合によってはMakefileベースのビルドシステムを置き換えることが期待されています。\n\nMesonビルドシステムの主なメリットは以下のとおりです。\n* MakefileやCMakeでは難しいビルドオプションを簡単に確認できる\n* AutoconfやCMakeに比べてシンプルな構文\n* さまざまなOS、コンパイラ、IDEをサポート\n* out-of-sourceビルドなど、モダンなビルドシステムに対応\n\n以下に、Mesonを使用したGitのビルド方法をご紹介します。\n\n```shell\n$ cd git             \t# Gitのソースコードのルートディレクトリに移動\n$ meson setup build/ \t# \"build\"をビルドディレクトリとして設定\n$ cd build           \t# \"build\"ディレクトリに移動\n$ meson compile      \t# Gitをビルド\n$ meson test         \t# 新しいビルドをテスト\n$ meson install      \t# 新しいビルドをインストール\n\n```\n\n`meson setup \u003Cbuild_dir>`を使うことで、複数のビルドディレクトリを設定できます。また、ビルドディレクトリ内で`meson configure`を実行して、そのディレクトリのビルド構成を確認または変更できます。\n\n詳しい手順は、Gitコードリポジトリの[`meson.build`ファイル](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build)の冒頭に記載されています。また、Gitで使用される[ビルドシステムの比較](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt)は、Gitの技術ドキュメントで確認できます。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## Gitのメモリリーク完全解消（テストスイートによる検証済み）\n\n前回のGit 2.47.0リリースに関するブログ記事で触れたように、GitLabでは[プロジェクト内で発生したメモリリークの修正](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#code-refactoring-and-maintainability-improvements)に取り組んできました。その結果、Git 2.47.0リリース以前は、223のテストファイルで確認されていたメモリリークが、最終的に60ファイルまで削減されました。\n\nその後、残りの60ファイルにおけるメモリリークもすべて解消され、テストスイートで検証された範囲では、Gitは完全にメモリリークがない状態となりました。この成果は、Git内部コンポーネントを内部ライブラリに「ライブラリ化（変換）」するという長年の目標に向け大きく前進したことを示しています。また、メモリ使用の最適化にもつながります。\n\n今後、新たに追加されるテストはデフォルトでメモリリークがないことが求められます。リークを含むテストも可能ですが、その場合、作成者は例外的な処理を使用して、メモリリークを解消できない理由を明示する必要があります。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## バンドルURIチェックの改善\n\nGit 2.46.0リリースに関するブログ記事で[Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/)による[バンドルURI修正](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#bundle-uri-fixes)を取り上げました。 その後、Xing Xinは[バンドルを使ったフェッチ](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/)が、通常のフェッチと同様に[fsck](https://git-scm.com/docs/git-fsck)メカニズムで完全に検証されるように改良しました。\n\n通常のフェッチの検証では、[異なるfsckの問題](https://git-scm.com/docs/git-fsck#_fsck_messages)に対して[異なる重大度](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-fsckltmsg-idgt)を指定することで、特定のリポジトリにおいて何を許容し、何を拒否するかを細かく制御できます。しかし、これまでバンドルを使ったフェッチではこうした制御は不可能でした。\n\n[バンドルURI](https://git-scm.com/docs/bundle-uri)の有用性と安全性をさらに高めるために、[この問題を解決](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/)し、バンドルを使ったフェッチの検証にも異なるfsck問題に対して異なる重大度を指定できるようにしました。\n\nこのプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。\n\n## 参照の整合性チェックを追加\n\nGit 2.47.0リリースに関するブログ記事で、[Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF)（GSoC 2024）の一環としてJialuo Sheが[「verify」サブコマンドをgit-refs(1)に追加](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#new-subcommand-for-git-refs\\(1\\))したことについて言及しました。\n\n記事では、最終目標として、この新しいサブコマンドをgit-fsck(1)に統合し、リポジトリの整合性チェックを一元化できるようにすることを挙げました。GSoC終了後、Jialuo Sheはこの統合作業に着手しました。\n\n[この取り組み](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/)の結果、git-fsck(1)は、参照の内容が不適切な場合や、シンボリック参照としてシンボリックリンクが使用された場合、ターゲットが無効な参照を指している場合など、参照に関連するさまざまな問題を検出し処理できるようになりました。git-fsck(1)の一部として`git refs verify`を呼び出し、git-fsck(1)が現在実行しているバックエンドに依存しないすべてのチェックを`git refs verify`が引き継ぐ必要がありますが、参照の整合性チェックを一元化するという最終目標に一歩近づきました。\n\nこのプロジェクトはJialuo Sheが主導しました。\n\n## reftableにおけるイテレータの再利用\n\n[Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt)のリリースでは、参照（主にブランチやタグ）を管理する新しいバックエンドとして「reftable」フォーマットが導入されました。reftableバックエンドについての詳細は、この機能を紹介している過去の[Gitリリースに関するブログ記事](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)や、[reftableの仕組みを詳しく解説した](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)初心者向けガイドをお読みください。\n\n2.45.0以降もバックエンドの改良を重ね、最近では、[内部イテレータの再利用](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/)によってランダムな参照を読み取る際のパフォーマンスを向上させることに注力しました。こうした改善がなされるまでは、単一の参照を読み取るたびに新しいイテレータを作成し、対象のテーブル内の正しい位置を探してそこに移動させ、次の値を読み取る必要があり、多くの参照を短時間で読み取る際にはきわめて非効率でした。しかし、今回の変更により、単一のイテレータを作成し、それを再利用して複数の参照を読み取ることで、処理効率を高められるようになりました。\n\nその結果、reftableに関連するさまざまなユースケースでパフォーマンスが向上しました。特に、ランダム読み取りが頻繁に実行されるトランザクション内で多くの参照を作成する際に、7%の速度向上が確認されています。また、この変更によって、イテレータ内で保持される状態をより多く再利用できるようになるため、最適化がさらに進むと予想できます。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## `git-refs migrate`におけるreflog対応\n\nGit 2.46.0のリリース記事では、[このツールに関する取り組み](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#tooling-to-migrate-reference-backends)に加え、いまだ存在する課題についても次のように言及しています。\n\n「リポジトリ内のreflogは参照バックエンドのコンポーネントであり、フォーマット間の移行も必要となります。残念ながら、現時点ではツールを使用してファイルとreftableバックエンドの間でreflogを変換することはできません」\n\n[この課題はGit 2.48.0で解決](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/)されました。\n`git refs migrate`を使うことでreflogの移行も可能になりました。複数のワークツリーを持つリポジトリを扱うことはまだできませんが、残された課題はこの一点のみであり、ワークツリーを使用していない場合は、既存のリポジトリでreftableバックエンドをすでに利用することが可能です。\n\nこのプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n## Ref-filterの最適化\n\n「ref-filter」サブシステムは、`git for-each-ref`、`git branch`、`git tag`といったコマンドで使用されるフォーマットコードで、Git参照に関連する情報を並べ替え、フィルタリング、フォーマット、表示する役割を担っています。\n\nリポジトリの規模が大きくなるにつれて、扱う参照の数も増加します。そのため、reftableバックエンドなどの参照を保存するバックエンド（上記参照）の改善だけでなく、「ref-filter」サブシステムのようなフォーマットコードの最適化にも取り組んでいます。\n\n今回、ref-filterのコードでバックエンドの順序通りに参照を処理すべき場合に、参照の一時的なバッファリングやイテレーション処理を不要にする[方法を特定](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/)しました。この結果、メモリの節約が可能になり、特定のコマンドでは処理速度が最大で770倍も速くなるケースが確認されています。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## 補足情報\n\nこのブログ記事では、最新リリースにおけるGitLabや広範なGitコミュニティによるコントリビュートの一部をご紹介しました。詳細は、Gitプロジェクトの公式リリース発表をご覧いただくと詳細をご確認いただけます。また、[これまでのGitリリースに関するブログ記事](https://about.gitlab.com/blog/tags/git/)では、GitLabチームの過去のコントリビュートもハイライトされていますので、ぜひご確認ください。\n\n- [Git 2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)（英語）\n- [Git 2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)（英語）\n- [Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)\n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)\n\n\u003Cbr>\n*監修：小松原 つかさ* [*@tkomatsubara*](https://gitlab.com/tkomatsubara)\u003Cbr>\n*（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[678,9,270],"2025-02-13",{"slug":1049,"featured":91,"template":681},"whats-new-in-git-2-48-0","content:ja-jp:blog:whats-new-in-git-2-48-0.yml","Whats New In Git 2 48 0","ja-jp/blog/whats-new-in-git-2-48-0.yml","ja-jp/blog/whats-new-in-git-2-48-0",{"_path":1055,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1056,"content":1061,"config":1067,"_id":1069,"_type":14,"title":1070,"_source":16,"_file":1071,"_stem":1072,"_extension":19},"/ja-jp/blog/whats-new-in-git-2-49-0",{"title":1057,"description":1058,"ogTitle":1057,"ogDescription":1058,"noIndex":6,"ogImage":986,"ogUrl":1059,"ogSiteName":669,"ogType":670,"canonicalUrls":1059,"schema":1060},"Git 2.49.0の新機能","このリリースでは、zlib-ngによるパフォーマンス向上、新しい名前ハッシュアルゴリズム、そして新しいコマンドgit-backfill(1)の導入などが行われています。","https://about.gitlab.com/blog/whats-new-in-git-2-49-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.49.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Toon Claes\"}],\n        \"datePublished\": \"2025-03-14\",\n      }",{"title":1057,"description":1058,"authors":1062,"heroImage":986,"date":1064,"body":1065,"category":10,"tags":1066},[1063],"Toon Claes","2025-03-14","Gitプロジェクトは最近、[Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/)をリリースしました。このリリースには、GitLabのGitチームや、より広範なGitコミュニティからのコントリビュートが含まれます。注目すべきハイライトを見てみましょう。\n\nこの記事では以下の変更点についてご紹介します。\n- [git-backfill(1)と新しいpath-walk API](#git-backfill(1)-and-the-new-path-walk-api)\n- [zlib-ngの導入](#introduction-of-zlib-ng)\n- [Mesonの継続的なイテレーション](#continued-iteration-on-meson)\n- [.git/branches/および.git/remotes/の非推奨化](#deprecation-of-.gitbranches%2F-and-.git%2Fremotes%2F)\n- [libgitに対するRustバインディング](#rust-bindings-for-libgit)\n- [新しい名前ハッシュアルゴリズム](#new-name-hashing-algorithm)\n- [プロミサーリモート機能](#promisor-remote-capability)\n- [`--revision`を使用した軽量なクローン](#thin-clone-using---revision)\n\n## git-backfill(1)と新しいpath-walk API\n\n[`git-clone(1)`](https://git-scm.com/docs/git-clone)コマンドでGitリポジトリをクローンする際に、\n[`--filter`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt-code--filterltfilter-specgtcode)オプションを指定することができます。\nこのオプションを使用すると、部分クローンを作成できます。部分クローンでは、指定されたオブジェクトフィルターに従って、サーバーから到達可能なオブジェクトの一部のみが送信されます。\n例えば、`--filter=blob:none`を指定してクローンを作成すると、サーバーからblob（ファイルの中身）が一切フェッチされず、_ブロブを含まないクローン_が作成されます。\n\nブロブを含まないクローンには、すべての到達可能なコミットとツリーは含まれますが、blobは含まれていません。そのため、[`git-checkout(1)`](https://git-scm.com/docs/git-checkout)のような操作を行うと、\nGitは必要なblobをサーバーからダウンロードして、その操作を完了させます。ただし、[`git-blame(1)`](https://git-scm.com/docs/git-blame)のような一部の操作では、\n必要なオブジェクトが1つずつダウンロードされることになり、この処理が非常に遅くなります。\nこれは、`git-blame(1)`がコミット履歴をたどって必要なblobを特定し、\n不足している各blobを個別にサーバーへリクエストする必要があるためです。\n\nGit 2.49では、新たに`git-backfill(1)`というサブコマンドが導入されました。これは、ブロブを含まない部分クローンに対して、不足しているblobをダウンロードするために使用できます。\n\n内部的には、`git-backfill(1)`は新しいパスウォークAPIを利用しています。これはGitが通常行うコミットのイテレーション処理とは異なります。従来の方法では、コミットを1つずつイテレーションし、それぞれに関連するツリーやblobに再帰的にアクセスしていました。一方、パスウォークAPIはパスごとに処理を行います。各パスについて関連するツリーオブジェクトのリストをスタックに追加し、そのスタックを深さ優先で処理します。つまり、コミット`1`のすべてのオブジェクトを処理してからコミット`2`へ進むのではなく、ファイル`A`のすべてのバージョンを全コミットにわたって処理してからファイル`B`に進む、という方式です。このアプローチは、パスごとにグループ化して処理する必要がある場合に、大幅なパフォーマンス向上をもたらします。\n\n[`gitlab-org/git`](https://gitlab.com/gitlab-org/git)リポジトリのブロブを含まないクローンを作成し、その使い方をお見せします。\n\n```shell\n$ git clone --filter=blob:none --bare --no-tags git@gitlab.com:gitlab-org/git.git\nCloning into bare repository 'git.git'...\nremote: Enumerating objects: 245904, done.\nremote: Counting objects: 100% (1736/1736), done.\nremote: Compressing objects: 100% (276/276), done.\nremote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused 244168 (from 1)\nReceiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.\nResolving deltas: 100% (161482/161482), done.\n```\n\n上の例では、Gitが初期ブランチをチェックアウトするためにblobをダウンロードする必要がないよう、`--bare`オプションを使用しています。このクローンにblobが含まれていないことは、次のコマンドで確認できます。\n\n```sh\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\nもしこのリポジトリ内のファイル内容を確認したい場合、Gitはそのファイルをダウンロードする必要があります。\n\n```sh\n$ git cat-file -p HEAD:README.md\nremote: Enumerating objects: 1, done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\nGit - fast, scalable, distributed revision control system\n=========================================================\n\nGit is a fast, scalable, distributed revision control system with an\nunusually rich command set that provides both high-level operations\nand full access to internals.\n\n[中略]\n```\n\nご覧のとおり、Gitはまずリモートリポジトリにアクセスし、blobをダウンロードしてから内容を表示しています。\n\nこのファイルに対して`git-blame(1)`を実行したい場合は、さらに多くのデータをダウンロードする必要があります。\n\n```sh\n$ git blame HEAD README.md\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\n\n[中略]\n\ndf7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1) [![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n5f7864663b README.md (Johannes Schindelin \t2019-01-29 06:19:32 -0800  2)\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  3) Git - fast, scalable, distributed revision control system\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  4) =========================================================\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  5)\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  6) Git is a fast, scalable, distributed revision control system with an\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  7) unusually rich command set that provides both high-level operations\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  8) and full access to internals.\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  9)\n\n[中略]\n```\n\n出力は省略していますが、ご覧のように、Gitはそのファイルの各リビジョンについて個別にサーバーへアクセスしています。これはとても非効率的です。そこで`git-backfill(1)`を使えば、Gitに対してすべてのblobを一括でダウンロードするよう指示できます。\n\n```shell\n$ git backfill\nremote: Enumerating objects: 50711, done.\nremote: Counting objects: 100% (15438/15438), done.\nremote: Compressing objects: 100% (708/708), done.\nremote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused 35273 (from 1)\nReceiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\nResolving deltas: 100% (49154/49154), done.\nremote: Enumerating objects: 50017, done.\nremote: Counting objects: 100% (10826/10826), done.\nremote: Compressing objects: 100% (634/634), done.\nremote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused 39191 (from 1)\nReceiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\nResolving deltas: 100% (48301/48301), done.\nremote: Enumerating objects: 47303, done.\nremote: Counting objects: 100% (7311/7311), done.\nremote: Compressing objects: 100% (618/618), done.\nremote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused 39992 (from 1)\nReceiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\nResolving deltas: 100% (43788/43788), done.\n```\n\nこれにより、すべてのblobが補完され、ブロブを含まないクローンが完全なクローンになります。\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n 148031 blob\n  83977 commit\n 161927 tree\n```\n\nこの[プロジェクト](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/)は[Derrick Stolee](https://stolee.dev/)によって主導され、[e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae)でマージされました。\n\n## zlib-ngの導入\n\n`.git/`フォルダ内のすべてのオブジェクトは、Gitによって[`zlib`](https://zlib.net/)を使って圧縮されています。`zlib`は[RFC\n1950](https://datatracker.ietf.org/doc/html/rfc1950)（ZLIB圧縮データフォーマット）のリファレンス実装であり、1995年に作られました。`zlib`は長い歴史を持ち、非常に高い移植性があり、\nインターネット以前の多くのシステムもサポートしています。このように幅広いアーキテクチャやコンパイラをサポートしている一方で、\nzlibには機能面での制限もあります。\n\nその制限に対応するために生まれたのが[`zlib-ng`](https://github.com/zlib-ng/zlib-ng)というフォークです。\n`zlib-ng`は、現代的なシステム向けに最適化されることを目指しており、レガシーシステムのサポートを廃止する代わりに、\nIntel向けの最適化パッチや、Cloudflareによる最適化、その他いくつかの小規模なパッチが取り込まれています。\n\n`zlib-ng`ライブラリ自体は`zlib`との互換レイヤーを提供しており、この互換性により、`zlib-ng`を`zlib`の代替としてそのまま差し替えて使うことが可能です。\nただし、この互換レイヤーはすべてのLinuxディストリビューションで利用できるわけではありません。Git 2.49では以下の変更が加えられました。\n\n- Gitプロジェクトへのzlib-ng互換レイヤーの追加\n- [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187)および[Mesonビルドファイル](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811)へのビルドオプションの追加\n\nこれらの追加により、`zlib-ng`によるパフォーマンス向上の恩恵を受けやすくなりました。\n\nローカルでのベンチマークでは、`zlib`ではなく`zlib-ng`を使用することで約25%の高速化が確認されています。現在、これらの変更をGitLab.comにも順次導入中です。\n\n`zlib-ng`によるパフォーマンス向上の恩恵を受けたい場合は、まず`git version --build-options`コマンドを実行して、お使いのマシンでGitがすでに`zlib-ng`を使用しているかどうかを確認してください。\n\n```shell\n$ git version --build-options\ngit version 2.47.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.6.0\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1.zlib-ng\n```\n\n出力の一番下の行に`zlib-ng`と表示されていれば、すでにGitは高速な`zlib`のバリアントでビルドされています。表示されていない場合は、以下のいずれかの方法で対応できます。\n\n- お使いのGitパッケージのメンテナーに、`zlib-ng`のサポートを有効にしてもらうよう依頼する\n- Gitをソースコードから自分でビルドする\n\nなお、これらの[変更](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0)\nは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって[導入](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/)されました。\n\n## Mesonの継続的なイテレーション\n\nGit 2.48のリリースについて紹介した記事では、[Mesonビルドシステムの導入](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/#meson%E3%83%93%E3%83%AB%E3%83%89%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)について触れました。[Meson](https://ja.wikipedia.org/wiki/Meson_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2))は、Gitプロジェクトで使用されるビルド自動化ツールで、将来的には[Autoconf](https://ja.wikipedia.org/wiki/Autoconf),\n[CMake](https://ja.wikipedia.org/wiki/CMake)さらには\n[Make](https://ja.wikipedia.org/wiki/Make_(UNIX))に取って代わる可能性もあります。\n\n今回のリリースサイクルでも、Mesonの利用に関する作業が引き続き進められ、不足していた機能の追加や安定性向上のための以下の修正が行われました。\n\n  - [CIのテストカバレッジ改善](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/)が、コミット[72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709)でマージされました\n- [`contrib/`ディレクトリでMesonを使えるようにする作業の一部](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/)が、コミット[2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace)でマージされました\n  - [Mesonベースのビルド手順に関する修正や改善](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/)が、コミット[ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f)でマージされました\n  - [git-subtree(1)のビルドにMesonを対応させる変更](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/)が、コミット[3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7)でマージされました\n  - [MesonにHTMLドキュメントページの生成を学習させる変更](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/)が、コミット[1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694)でマージされました\n\nこれらの作業はすべて[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって行われました。\n\n## .git/branches/および.git/remotes/の非推奨化\n\nおそらく、 `.git`ディレクトリやその中身についてはご存じかと思います。\nしかし、 `.git/branches/`や`.git/remotes/`というサブディレクトリの存在についてはどうでしょうか？\nご存じの通り、ブランチへの参照は`.git/refs/heads/`に保存されているため、`.git/branches/`はそのための場所ではありません。そして、`.git/remotes/`の用途は何でしょうか？\n\n2005年、[`.git/branches/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirbranches)はリモートの短縮名を保存するために導入されました。そしてその数か月後に、それらは[`.git/remotes/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirremotes)に移動されました。\n[2006年](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/)には、[`git-config(1)`](https://git-scm.com/docs/git-config)に[リモート](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl)設定を保存する機能が追加され、\nこれがリモートを設定する標準的な方法として定着しました。\nその後2011年には、`.git/branches/`と`.git/remotes/`は「レガシー」であることが[文書化](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124)され、現代のリポジトリでは使用されなくなりました。\n\nそして2024年、Gitの次のメジャーバージョン（v3.0）の破壊的な変更の概要をまとめるドキュメント[破壊的な変更](https://git-scm.com/docs/BreakingChanges)が作成されました。\nこのリリースはすぐに行われる予定はありませんが、このドキュメントにはそのリリースに含まれると予想される変更点について記載されています。\nコミット[8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674)では、`.git/branches/`および`.git/remotes/`ディレクトリの使用に関する内容がこのドキュメントに追加され、これにより公式に非推奨とされ、Git 3.0で削除予定であることが明示されました。\n\n[この非推奨化を正式に文書化](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/)した[Patrick Steinhardt](https://gitlab.com/pks-gitlab)に感謝します。\n\n## libgitに対するRustバインディング\n\nGitをコンパイルすると、内部ライブラリ`libgit.a`が生成されます。このライブラリには、Gitの中核となる機能の一部が含まれています。\n\nこのライブラリ（およびGitの大部分）はC言語で書かれていますが、Git 2.49では一部の関数をRustから使えるようにするためのバインディングが追加されました。この実現のために、2つの新しいCargoパッケージ、`libgit-sys`と`libgit-rs`が作成されました。これらのパッケージは、GitのSourceTree内の[`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib)サブディレクトリに配置されています。\n\n[他言語関数インターフェイス](https://ja.wikipedia.org/wiki/Foreign_function_interface)を使う場合、ライブラリを2つのパッケージに分けるのは[一般的](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages)な手法です。\n`libgit-sys`パッケージは、C関数への純粋なインターフェースを提供し、ネイティブの`libgit.a`にリンクします。一方、`libgit-rs`パッケージは、`libgit-sys`の関数をRustらしいスタイルで扱える高レベルなインターフェースを提供します。\n\n現時点では、これらのRustパッケージで使える機能は非常に限定的で、対応しているのは`git-config(1)`とやり取りするためのインターフェースのみです。\n\nこの取り組みは[Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/)さんによって主導され、コミット[a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd)でマージされました。\n\n## 新しい名前ハッシュアルゴリズム\n\n`.git/`にあるGitのオブジェクトデータベースは、その大部分のデータを パックファイルに保存しています。また、このパックファイルは、Gitのサーバーとクライアント間でオブジェクトをやり取りする際にも使われます。\n\nパックファイルのフォーマットについては、[`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack)に詳しく書かれていますが、その中でも重要なのが差分圧縮です。差分圧縮では、すべてのオブジェクトがそのまま保存されるわけではなく、一部のオブジェクトは他のオブジェクトとの_差分_として保存されます。つまり、オブジェクトの内容全体を保存するのではなく、他のオブジェクトと比較した変更点だけを記録します。\n\n差分の計算や保存方法についてはここでは詳しく触れませんが、\n非常に似ているファイルをグループ化しておくことが重要なのは想像できるかと思います。Git v2.48以前では、Gitは「ファイルパスの最後の16文字」をもとに、blobが似ているかどうかを判断していました。このアルゴリズムはバージョン`1`と呼ばれています。\n\nGit 2.49では、バージョン`2`のアルゴリズムが追加されました。これはバージョン`1`のイテレーションで、親ディレクトリの影響を減らすように調整されたバージョンです。どちらのアルゴリズムを使用するかは、[`git-repack(1)`](https://git-scm.com/docs/git-repack)の`--name-hash-version`オプションで指定できます。\n\n以下は、このプロジェクトを推進した[Derrick Stolee](https://stolee.dev/)さんによる、`git repack -adf --name-hash-version=\u003Cn>`を実行した際のパックファイルサイズの比較です。\n\n| リポジトリ                                          \t| バージョン1のサイズ   | バージョン2のサイズ |\n|---------------------------------------------------|-----------|---------|\n| [fluentui](https://github.com/microsoft/fluentui) | 440 MB \t| 161 MB   |\n| Repo B                                        \t| 6,248 MB   | 856 MB   |\n| Repo C                                        \t| 37,278 MB  | 6,921 MB |\n| Repo D                                        \t| 131,204 MB | 7,463 MB |\n\nこの件に関する詳細は、コミット[aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51)にマージされた[パッチセット](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/)にて確認できます。\n\n## プロミサーリモート機能\n\nGitが大きなファイルを扱うのに向いていないことは、よく知られています。この問題に対する解決策として、[Git LFS](https://git-lfs.com/)のようなツールがありますが、依然として以下のような欠点が残っています。\n\n- Git LFSでは、どのファイルをLFSに入れるかをユーザーが自分で設定する必要があり、サーバー側ではそれについて制御できず、すべてのファイルを提供する必要があります。\n- リポジトリにファイルがコミットされると、履歴を書き換えない限り、それを取り除く方法がありません。これは特に大きなファイルでは厄介で、一度入れると永遠に残ってしまいます。\n- ユーザーは、Git LFSに入れるファイルを後から変更することはできません。\n- Git LFS のようなツールは、導入・学習・運用すべてにそれなりの労力が必要です。\n\n以前からGitにはプロミサーリモートという概念が存在しており、この機能を大きなファイルに対処するための手段として利用できます。そしてGit 2.49では、この機能がさらに一歩前進しました。\n\n新しい「プロミサーリモート」機能の考え方は比較的シンプルです。Gitサーバーがすべてのオブジェクトを自ら送信する代わりに、「これらのオブジェクトは_XYZ_からダウンロードしてね」とGitクライアントに伝えます。この_XYZ_がプロミサーリモートです。\n\nGit 2.49では、サーバーがプロミサーリモートの情報をクライアントに通知できるようになりました。この変更は、[`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2)の拡張として行われています。サーバーとクライアントがデータを送受信している間に、サーバーは自分が知っているプロミサーリモートの名前やURLをクライアントに送信します。\n\n現時点では、Gitクライアントはクローン時にサーバーから受け取ったプロミサーリモートの情報をまだ利用していません。つまり、今のところは、クローン元のリモートからすべてのオブジェクトを取得しています。しかし今後は、サーバーから受け取ったプロミサーリモート情報を活用できるように開発を進め、より簡単に使える仕組みにしていく予定です。\n\nこの[パッチセット](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/)は[Christian Couder](https://gitlab.com/chriscool)さんによって提出され、コミット[2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c)でマージされました。\n\n## `--revision`を使用した軽量なクローン\n\n[`git-clone(1)`](https://git-scm.com/docs/git-clone)に新しく`--revision`オプションが追加されました。このオプションを使うことで、指定されたリビジョンの履歴のみを含む、軽量なクローンを作成できます。このオプションは`--branch`に似ていますが、`refs/heads/main`、`refs/tags/v1.0`、`refs/merge-requests/123`のような リファレンス名や、16進数のコミットオブジェクトIDを受け取る点が異なります。`--branch`との違いは、このオプションでは追跡ブランチが作られず、`HEAD`がデタッチ状態になる点です。そのため、このクローンを使ってブランチにコントリビュートするといった用途には向いていません。\n\n`--revision`と`--depth`を組み合わせて使うことで、非常にミニマルなクローンを作成できます。おすすめの用途は、自動テストです。たとえば、CIシステムが特定のブランチ（またはリファレンス）をチェックアウトして、ソースコードのテストを行うだけでいい場合、この最小限のクローンで十分です。\n\nこの[変更](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a)は[Toon Claes](https://gitlab.com/toon)さんによって[推進](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/)されました。\n\n# もっと詳しく\n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)\n- [Git 2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)\n- [Git 2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)",[270,9,678],{"slug":1068,"featured":91,"template":681},"whats-new-in-git-2-49-0","content:ja-jp:blog:whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0","ja-jp/blog/whats-new-in-git-2-49-0.yml","ja-jp/blog/whats-new-in-git-2-49-0",{"_path":1074,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1075,"content":1079,"config":1090,"_id":1092,"_type":14,"title":1093,"_source":16,"_file":1094,"_stem":1095,"_extension":19},"/ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"config":1076,"title":1077,"description":1078},{"noIndex":6},"DevSecOpsにおける企業の独立性がこれまで以上に重要な理由","開発インフラを誰がコントロールしているのか、リーダーたちが疑問を持つ中、GitLabの独立性と透明性の優位性はかつてないほど注目されています。",{"heroImage":1080,"body":1081,"authors":1082,"updatedDate":1084,"date":830,"title":1077,"tags":1085,"description":1078,"category":1089},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1756500636/wmey6kqzzuhirk88w2de.png","10年以上にわたり、GitLabは透明性、独立性、そしてデベロッパーファーストの姿勢を大切にしてきました。業界が進化する今日、これらの価値はこれまで以上に重要になっています。「開発インフラを最終的に管理するのは誰なのか？」「AIシステムでコードがどのように使用されているのか？」「ベンダーの優先事項が重要な要件から離れた場合はどうなるのか？」企業のリーダーたちはこのような重要な疑問を投げかけています。\n\n先月、[GitLab 18.3のリリースを発表](https://about.gitlab.com/ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/)しました。これは、AIネイティブなDevSecOpsプラットフォームの最新版です。GitLab Duo Agent Platformの一部であるエージェントインサイトは、エージェントの意思決定プロセスを可視化します。AIモデルサポートの拡張により、ベンダーロックインを回避できます。強化されたガバナンス管理により、複数の管轄区域にわたるコンプライアンスの実現を支援します。\n\nこれらは単なる機能ではありません。GitLabを定義する透明性、独立性、デベロッパーファーストのアプローチの実証なのです。この戦略が実際にどう機能するかをご紹介します。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1115249475?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Who is GitLab_Robin_090225_FINAL\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## DevSecOpsライフサイクル全体でのAI透明性\n\n**GitLabでは、10年間にわたる透明性への取り組みが、これらの懸念に直接対処しています。** 人工知能が開発ワークフローにますます統合される中、組織は自社のコードとデータがAI学習にどのように使用されているかを当然懸念しています。\n\n2024年4月に開始されたGitLab [AI Transparency Center](https://about.gitlab.com/ja-jp/ai-transparency-center/)は、データガバナンスの実践、プライバシー保護、倫理的AI原則について明確な文書を提供しています。データ使用ポリシーが不明確なAI機能を運用する可能性のあるプラットフォームとは異なり、GitLabは透明性を優先し、お客様が[自分たちのデータがどのように処理](https://docs.gitlab.com/user/gitlab_duo/data_usage/)、保存、保護されているかを正確に把握できるようにしています。お客様のデータでの学習は一切行いません。\n\n私たちのアプローチは、モデルの柔軟性とベンダーの独立性にも及んでいます。お客様を単一の大規模言語モデル（LLM）プロバイダーに限定し、追加のベンダー依存や潜在的な単一障害点を作り出すプラットフォームがある一方で、GitLabのAI機能は様々なモデルによって強化されています。このアプローチにより、幅広いユースケースをサポートし、お客様の戦略的優先事項に合わせた柔軟性を持ち合わせています。\n\nGitLab Duo Agent Platformの開発をさらに進める中で、データ制御と包括的な人間参加型制御の維持に焦点を当て続けています。また、GitLab Duo Self-Hostedは、エアギャップ環境へのデプロイオプション、ゼロデイデータ保持ポリシー、自社インフラ内ですべてのAIリクエストを処理する機能により、完全なデータ主権を提供します。\n\n2024年5月以降、私たちは業界をリードするコミットメントを含む[AI継続プラン](https://handbook.gitlab.com/handbook/product/ai/continuity-plan/)も維持しています。これは、プロバイダーが顧客データに関する実践を変更した場合、30日以内に新しいモデルを評価して移行する能力です。AIベンダーリスク管理に対するこの積極的なアプローチは、顧客管理への私たちの取り組みを反映しています。\n\n## デプロイの選択、クラウドプロバイダーの選択\n\n**DevSecOps環境をどこにどのようにデプロイするかを選択できるべきです。** GitLabは真のデプロイの柔軟性を実現します。組織は、オンプレミス導入、マルチテナントSaaS、または完全管理型のシングルテナントSaaSソリューションであるGitLab Dedicatedから選択でき、機能を犠牲にしたり、エコシステムロックインを促進する人為的な制限に直面することはありません。GitLabはクラウドニュートラルでもあり、お客様はビジネスニーズと環境に最適なクラウドプロバイダーを使用できます。\n\nこの柔軟性は、複雑な管轄要件や規制上の課題をナビゲートする際に、非常に価値があることが証明されています。欧州連合やその他の地域で見られるような新しいデータローカライゼーション法が登場した場合、GitLabを使用する組織は、エコシステムの依存関係に制約されることなく、デプロイ戦略を迅速に適応させることができます。\n\n調達とリスク管理の観点から、プラットフォームの独立性は契約交渉において重要な影響力も提供します。組織は、顧客のニーズよりもベンダーの利益を優先する制限的なライセンス契約に縛られることがありません。この独立性は、企業がAIスタックの管理者が誰なのかを警戒するようになる中で、特に重要になります。\n\n## セキュリティとコンプライアンス：組み込み型で常に優先事項\n\n**セキュリティとコンプライアンスは現在、開発機能と同様に重要であり、後付けではなく、プラットフォームに組み込まれているべきです。** GitLabの単一プラットフォームアプローチは、基本的なセキュリティとガバナンス機能を実現させるために、サードパーティのアドインに依存する断片化されたプラットフォームよりも大きな優位性を提供します。このアーキテクチャの違いは、潜在的な法的リスク、運用効率、規制コンプライアンスに重要な影響を与えます。チェーン内の追加ツールはそれぞれ、別の潜在的な障害点、交渉すべき別の利用規約セット、そして別のリスクの源となります。\n\nGitLabは、カスタムコンプライアンスフレームワーク、動的アプリケーションセキュリティテスト（DAST）、APIファズテスト、カバレッジガイドファズテスト、Infrastructure-as-Codeテストなど、包括的な組み込みセキュリティとコンプライアンス機能を提供します。これらの機能はプラットフォームにネイティブに統合されており、一貫したポリシー実施を提供し、複数のサードパーティツールの管理に伴うコンプライアンスの複雑さや追加コストを削減します。\n\nGitLabの[コンプライアンスセンター](https://docs.gitlab.com/user/compliance/compliance_center/)は、チームがコンプライアンス基準、遵守レポート、違反レポート、グループのコンプライアンスフレームワークを管理するための中央拠点を提供します。このコンプライアンス管理への統一されたアプローチは、監査証跡とコンプライアンス文書が重要な、高度に規制された業界で事業を行う組織にとって特に価値があります。\n\n## オープンソースコミュニティとの密接な関係の維持\n\n**最高のツールは、それを使用する人々によって形作られます。** オープンソースへの取り組みとコミュニティとの関わりは、GitLabの創設以来の中核となっています。例えば、私たちの[Co-Createプログラム](https://about.gitlab.com/community/co-create/)は、お客様がGitLabエンジニアと直接連携してGitLabプラットフォームへの機能、修正、改良をコントリビュートできる協力的な取り組みです。\n\n透明性という価値観は、私たちのビジネスの根幹であり続けています。この例として、お客様が私たちの開発進捗をフォローし、製品改善についてGitLabチームと直接議論に参加できる[オープンイシュートラッカー](https://gitlab.com/groups/gitlab-org/-/issues)があります。最近立ち上げた、[ヘルシーバックログイニシアチブ](https://about.gitlab.com/blog/inside-gitlabs-healthy-backlog-initiative/)では、私たちの開発計画をさらに詳しくお客様に公開し、いただいたフィードバックをもっとも効果的に活かせる部分に確実に反映させています。\n\n私たちのアプローチにより、組織は規制環境に必要なガバナンス、監査証跡、セキュリティ管理を維持しながら、オープンソースイノベーションに貢献し、その恩恵を受けることができます。\n\n## データガバナンス：自分のデータは自分で守る\n\n**データとその処理方法について、完全な管理権限を保持できます。** データガバナンスは、国や地域ごとの複雑なデータ保護法や、ソースコード、顧客インサイト、戦略的イニシアチブ、競争情報といった機密知的財産に対する管理への懸念の高まりを背景に、企業技術の意思決定においてますます重要な要因となっています。\n\nGitLabでは、プラットフォーム内のAI搭載機能へのアクセス権限を管理でき、単純なアクセス制御を超えて、規制フレームワークに合わせた暗号化基準と監査機能を包括します。また、お客様のコードとデータはAIモデルの学習に使用されることは一切ありません。\n\n## 選択は明確です\n\nGitLabは、AIネイティブなDevSecOpsプラットフォームイノベーションをリードし続けています。私たちの最新の[18.3リリース](https://about.gitlab.com/ja-jp/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/)がそれを実証していますが、同時に常に私たちを導いてきた独立性と透明性へのコミットメントを堅持しています。\n\nお客様には選択肢があり、その選択は明確です：管理権の保持かベンダーロックインか。透明性か不確実性か。イノベーションへのコントリビュートか、より大きなエコシステムの気まぐれか。\n\nGitLabは、イノベーションと独立性のバランスを取る持続可能なデジタルトランスフォーメーションの基盤を提供し、お客様のビジネス価値の実現を支援します。\n\n[GitLab UltimateとGitLab Duoを今すぐ無料でお試しください。](https://about.gitlab.com/ja-jp/free-trial/)",[1083],"Robin Schulman","2025-09-03",[1086,810,1087,1088,9],"AI/ML","product","features","ai-ml",{"featured":91,"template":681,"slug":1091},"why-enterprise-independence-matters-more-than-ever-in-devsecops","content:ja-jp:blog:why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","Why Enterprise Independence Matters More Than Ever In Devsecops","ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","ja-jp/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"_path":1097,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1098,"content":1104,"config":1110,"_id":1112,"_type":14,"title":1113,"_source":16,"_file":1114,"_stem":1115,"_extension":19},"/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format",{"title":1099,"description":1100,"ogTitle":1099,"ogDescription":1100,"noIndex":6,"ogImage":1101,"ogUrl":1102,"ogSiteName":669,"ogType":670,"canonicalUrls":1102,"schema":1103},"初心者向けGit reftableフォーマットガイド","Git 2.45.0では、GitLabがreftableバックエンドをGitに取り込んだことで、参照の保存方法が完全に変更されました。この新しいフォーマットの内部の仕組みを詳しく見てみましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"初心者向けGit reftableフォーマットガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-05-30\",\n      }",{"title":1099,"description":1100,"authors":1105,"heroImage":1101,"date":1106,"body":1107,"category":10,"tags":1108,"updatedDate":1109},[674],"2024-05-30","最近まで、Gitでの参照の保存方法は、「files」フォーマットだけに限られていましたが、[Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)により、Gitでは参照を「reftable」フォーマットで保存できるようになりました。この新しいフォーマットは、バイナリフォーマットで非常に複雑ですが、その複雑さが「files」フォーマットのいくつかの欠点を解決します。「reftable」フォーマットは、次のような目的で設計されました。\n\n- 単一の参照の検索と参照範囲のイテレーションを、可能な限り効率的かつ迅速に行えるようにする。\n- 複数の参照が部分的にしか更新されていない中途半端な状態をGitが読み取らないように、一貫した参照の読み取りをサポートする。\n- 複数の参照の更新がオールオアナッシング型のオペレーションとして実行される、アトミック書き込みをサポートする。\n- 参照および参照ログの効率的な保存。\n\nこの記事では、「reftable」フォーマットの仕組みを詳しく見ていきます。\n\n## Gitでの参照の保存方法\n\n「reftable」フォーマットについて詳しく掘り下げる前に、まずはGitがこれまで参照をどのように保存してきたのかを簡単に振り返ってみましょう。すでにご存知の方は、このセクションを読み飛ばして構いません。\n\nGitリポジトリは、次の重要な2つのデータ構造を追跡します。\n\n- [オブジェクト](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)：リポジトリの実際のデータ（コミット、ディレクトリツリー構造、ソースコードを含むblobなど）を格納しています。オブジェクトは互いに参照し合い、オブジェクトグラフを形成します。さらに、各オブジェクトにはオブジェクトIDがあり、そのオブジェクトを一意に識別します。\n\n- 参照：ブランチやタグなどがあります。これらはオブジェクトグラフへのポインタであり、オブジェクトに覚えやすい名前を付けたり、開発履歴の異なるトラックを追跡するのに使われます。たとえば、リポジトリには`main`ブランチが含まれている場合があり、これは特定のコミットを指し示す`refs/heads/main`という名前の参照です。\n\n参照は、参照データベースに保存されます。Git 2.45.0までは、「files」データベースフォーマットのみが存在していました。このフォーマットでは、各参照が通常のファイルとして保存され、そのファイルには次のいずれかが含まれます。\n\n- 通常の参照：指し示すコミットのオブジェクトIDが保存されています。\n- シンボリック参照：別の参照の名前が保存されています。これは、シンボリックリンクが別のファイルを指し示すのと似ています。\n\n定期的に、これらの参照は検索を効率化するために1つのpacked-refsファイルにまとめられます。\n\n次の例は、「files」フォーマットがどのように動作するかを示しています。\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEADはrefs/heads/mainを指すシンボリック参照です。\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/mainはコミットを指す通常の参照です。\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1)はこれらの参照をpacked-refsファイルにパック化します。\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n```\n\n## reftableフォーマットの構造概要\n\nGit 2.45.0以降がインストールされている場合、`--ref-format=reftable`スイッチを使用して「reftable」フォーマットでリポジトリを作成できます。\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# わかりやすくするために不要なファイルを削除しています。\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nまず、リポジトリの設定を見ると、それには`extension.refstorage`キーがあります。\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nこの設定は、リポジトリが「reftable」フォーマットで初期化されており、「reftable」バックエンドを使用してアクセスするようGitに指示するものです。\n\n不思議なことに、このリポジトリにはまだ「files」バックエンドが使われているかのように見えるいくつかのファイルがあります。\n\n- `HEAD`は通常、現在チェックアウト済みのブランチを指すシンボリック参照です。「reftable」バックエンドでは使用されませんが、GitクライアントがディレクトリをGitリポジトリとして検出するために必要です。したがって、「reftable」フォーマットを使用する場合、`HEAD`は`ref: refs/heads/.invalid`という内容のスタブになります。\n\n- `refs/heads`は、`this repository uses the reftable format`という内容が書かれているファイルです。「reftable」フォーマットを認識できないGitクライアントは、このパスがディレクトリであると想定します。したがって、このパスをファイルとして作成することで、古いGitクライアントが「files」バックエンドでリポジトリにアクセスしようとすると、意図的に失敗するようになります。\n\n実際の参照は、次のように`reftable/`ディレクトリに保存されます。\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nここには、次の2つのファイルがあります。\n\n- `0x000000000001-0x000000000001-794bd722.ref`は、参照と参照ログデータをバイナリフォーマットで含むテーブルです。\n\n- `tables.list`は、テーブルのリストです。リポジトリの現在の状態では、このファイルにはテーブルの名前の1行だけが含まれています。このファイルは「reftable」データベースにある現在有効なテーブルをまとめて追跡し、新しいテーブルがリポジトリに追加されるたびに更新されます。\n\n次のように、参照を更新すると、新しいテーブルが作成されます。\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nご覧のとおり、以前のテーブルは新しいテーブルに置き換えられました。さらに、`tables.list`ファイルが更新され、新しいテーブルが取り込まれました。\n\n## テーブルの構造\n\n前述のとおり、参照データベースの実際のデータはテーブルに含まれています。テーブルは大まかに次のような複数のセクションに分かれています。\n\n- header：テーブルに関するメタデータが含まれています。これには、フォーマットのバージョン、ブロックサイズ、およびリポジトリで使用されるハッシュ関数（SHA1、SHA256など）が、他の情報と一緒に含まれています。\n- ref：参照が含まれています。これらのレコードは参照名と等しいキーを有し、通常の参照の場合はオブジェクトIDを、シンボリック参照の場合は他の参照を指します。\n- obj：オブジェクトIDからそれらのオブジェクトIDを指す参照への逆マッピングが含まれています。これにより、Gitは特定のオブジェクトIDを指す参照を効率的に検索できます。\n- log：参照ログエントリが含まれています。これらのレコードは、参照名にログエントリの番号を表すインデックスを付け足したものと等しいキーを有し、 さらに、古いオブジェクトIDと新しいオブジェクトID、およびその参照ログエントリのメッセージを含みます。\n- footer：各セクションへのオフセットが含まれます。\n\n![すべてのreftableセクションを含んだ縦長の表](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\n各セクションのタイプは、似たような構造を持っています。セクションには一連のレコードが含まれており、各レコードのキーでソートされています。たとえば、 `refs/heads/aaaaa`と `refs/heads/bbb`という2つの参照レコードがある場合、これらの参照名がそれぞれのキーとなり、`refs/heads/aaaaa`が`refs/heads/bbb`よりも前に来ます。\n\nさらに、各セクションは固定長のブロックに分割されています。このブロックの長さはヘッダー（header）にエンコードされており、次の2つの目的を果たします。\n\n- セクションの開始位置とブロックサイズに基づき、リーダー（reader）は各ブロックの開始位置を暗に認識します。これにより、Gitは先行するブロックを読み込むことなくセクションの途中に簡単に移動できるため、ブロック上でのバイナリ検索が可能になり、レコードの検索を高速化します。\n- 一度に読み込むディスクデータの量をリーダーが認識できるようにします。このために、ブロックサイズはデフォルトで4KiBに設定されており、これはハードディスクのセクターサイズとしては最も一般的です。最大ブロックサイズは16MBです。\n\nたとえば、「ref」セクションを覗いてみると、おおよそ次の図のようになります。ここで留意すべき点は、レコードがブロック内で、そしてブロック間の両方で辞書順に並んでいることです。\n\n![未圧縮参照ブロック](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\n現在の情報を基に、次の手順でレコードを検索できます。\n\n1. 各ブロックの最初のレコードのキーを確認してバイナリ検索を行い、目的のレコードが含まれているブロックを特定します。\n\n2. 特定したブロック内で線形検索を行い、目的のレコードを特定します。\n\nこの手順はまだ少し非効率です。多くのブロックがある場合、目的のブロックを特定するためにバイナリ検索で対数的に多くのブロックを読み込むことが必要になる場合があります。また、ブロックに多数のレコードが含まれている場合、線形検索中にすべてのレコードの読み込みが必要になる可能性もあります。\n\n「reftable」フォーマットには、これらのパフォーマンス問題に対処する追加のメカニズムが組み込まれています。後のセクションでこれらについて詳しく説明します。\n\n### プレフィックス圧縮\n\nお気づきかもしれませんが、すべてのレコードキーには`refs/`という共通のプレフィックスがあります。これはGitでは一般的です。\n\n- すべてのブランチは`refs/heads/`で始まります。\n- すべてのタグは`refs/tags /`で始まります。\n\nしたがって、後続のレコードもキーの大部分で共通のプレフィックスを持つことが予想されます。これを利用して、貴重なディスク容量を節約できます。ほとんどのキーが共通のプレフィックスを持つことがわかっているため、これを最適化するのは理にかなっています。\n\nこの最適化にはプレフィックス圧縮を使用します。各レコードは、前のレコードのキーから何バイトを再利用するかを示すプレフィックスの長さがエンコードされています。たとえば、`refs/heads/a`と`refs/heads/b`という2つのレコードがある場合、後者はプレフィックスの長さを11バイトとしてエンコードし、サフィックスとして`b`だけを保存します。その後、リーダーは`refs/heads/a`の最初の11バイト（`refs/heads/`）を取得し、サフィックス`b`を追加します。\n\n![プレフィックス圧縮](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### 再起点\n\n前述のように、現在の「reftable」フォーマットの理解に基づいてブロック内の参照を検索する最適な方法は、線形検索です。これは、レコードが固定長ではないため、ブロックの先頭からスキャンしないとレコードの開始位置を特定できないためです。また、レコードが固定長であったとしても、レフィックス圧縮があるため、先行するレコードを読み込む必要があり、ブロックの途中に直接移動はできません。 \n\nしかし、ブロックには数百から数千のレコードが含まれる可能性があり、線形検索は非常に非効率です。この問題に対処するために、「reftable」フォーマットは各ブロックに「再起点」と呼ばれるポイントをエンコードします。再起点は圧縮されていないレコードであり、ここではプレフィックス圧縮がリセットされます。したがって、再起点のレコードは常に完全なキーを含んでおり、先行するレコードをスキップしながら直接移動してレコードを読み込むことが可能になります。これらの再起点は各ブロックのフッターにリストされています。\n\nこの情報を用いることで、ブロック全体を線形検索する必要がなくなります。代わりに、再起点のバイナリ検索を行い、目的のキーより大きい最初の再起点を探します。そこから、目的のレコードが_前の_再起点から特定された再起点までのセクションに存在することがわかります。\n\nしたがって、レコードを検索する最初の手順（ブロックのバイナリ検索、レコードの線形検索）は次のようになります。\n\n1. ブロックのバイナリ検索を行い、目的のレコードが含まれるブロックを特定します。\n\n2. 再起点のバイナリ検索を行い、目的のレコードが含まれるブロックのサブセクションを特定します。\n\n3. 特定したサブセクション内でレコードの線形検索を行います。\n\n![レコードの線形検索](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### インデックス\n\nブロック内のレコードの検索はかなり効率化されましたが、ブロック自体の位置を特定するのはまだ効率的とはいえません。数個のブロックであればバイナリ検索でも十分に効率的です。しかし、数百万もの参照を含むリポジトリには数百から数千のブロックが存在します。この場合、追加のデータ構造がなければ、平均して対数的に多くのディスクアクセスが必要になります。\n\nこの問題を避けるために、各セクションの後にブロックを効率的に検索するためのインデックスセクションを追加できます。各インデックスレコードには次の情報が含まれます。\n\n- インデックス化されているブロックの位置。\n- インデックス化されているブロックの最後のレコードのキー。\n\n3つ以下のブロックであれば、バイナリ検索は最大2回のディスク読み取りで目的のブロックを特定できます。この読み取り回数は、インデックスを使用する場合も同じです。具体的には、インデックス自体を読み取るための1回と、目的のブロックを読む取るための1回です。したがって、インデックスは実際に読み取り回数を減らす場合、つまりインデックス化されたブロックが4つ以上ある場合にのみ作成されます。\n\n次の疑問は、インデックス自体が複数のブロックにまたがるほど大きくなった場合はどうすべきかという点です。その答えは、そのインデックスをインデックス化するために別のインデックスを作成するというものです。この複数階層のインデックスは、数十万もの参照があるリポジトリでのみ必要となります。\n\n次のインデックスを使用することで、レコードの検索手順をさらに効率化できます。\n1. テーブルのフッターを見てインデックスがあるかどうかを確認します。\n\t- インデックスがあれば、バイナリ検索を行い、目的のブロックを特定します。このブロックがインデックスブロック自体を指している場合は、目的のレコードタイプに到達するまでこの手順を繰り返します。\n\t- インデックスがなければ、先ほどのようにブロックのバイナリ検索を行います。\n2. 再起点のバイナリ検索を行い、目的のレコードが含まれているブロックのサブセクションを特定します。\n3. 特定したサブセクション内でレコードの線形検索を行います。\n\n## 複数のテーブル\n\nここまでは、単一のテーブルを読み取る方法について説明してきましたが、`tables.list`という名前が示すように、「reftable」データベースには複数のテーブルを格納できます。\n\nリポジトリ内の参照を更新するたびに、新しいテーブルが作成され、`tables.list`に追加されます。したがって、最終的には次のように複数のテーブルが存在することになります。\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├── 0x000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\n\nリポジトリの実際の状態を読み取るためには、これらの複数のテーブルを単一の仮想テーブルにマージする必要があります。\n\nここで疑問が生じます。それは、参照が更新されるたびにテーブルが作成され、同じ参照が複数回更新される場合、「reftable」フォーマットは特定の参照の最新の値をどのように把握するのか、ということです。直感的には、最新のテーブルに含まれる参照の値が最新であると仮定できます。\n\n実際には、各レコードには「更新インデックス」と呼ばれるものがあり、これがレコードの「優先度」をエンコードしています。たとえば、同じ名前の2つの参照レコードが存在する場合、更新インデックスが高い方が低い方を上書きします。\n\nこれらの更新インデックスは、上のファイル構造で確認できます。長い16進文字列（例：`0x000000000001`）が更新インデックスであり、テーブル名の左側がテーブルに含まれる最小の更新インデックス、そして右側が最大の更新インデックスを示しています。\n\nテーブルのマージは、参照レコードのキーと更新インデックスによって順序付けられた[優先キュー](https://en.wikipedia.org/wiki/Priority_queue)を介して行われます。すべての参照レコードをスキャンする場合、次の手順で行います。\n\n1. 各テーブルの最初のレコードを優先キューに追加します。\n\n![優先キューに最初のレコードを追加する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. 優先キューの先頭を取り出します。このキューは更新インデックス順に並んでいるため、先頭にあるレコードは最新のバージョンでなければなりません。そのテーブルの次の項目を優先キューに追加します。\n\n![優先キューの先頭を取り出す](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. 同じ名前を持つすべてのレコードをキューから削除します。これらのレコードは上書きされているため表示されません。レコードを削除した各テーブルについては、その次のレコードを優先キューに追加します。\n\n![同じ名前を持つすべてのレコードをキューから削除する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\n\nこれを繰り返して、他のキーのレコードを読み取ります。\n\nテーブルには、レコードが削除されたことを示す特殊な「トゥームストーン」レコードが含まれている場合があります。このように、すべてのテーブルを書き換えることなく、レコードを削除できます。\n\n### 自動圧縮\n\n優先キューの考え方はシンプルですが、このアプローチでは、マージするテーブルの数が数百個、あるいは数十個であっても、非常に非効率になります。参照を更新するたびに新しいテーブルが`tables.list`ファイルに付加されるのは事実ですが、他にも重要な特徴があります。\n\nそれが、自動圧縮です。新しいテーブルがテーブルリストに付加された後、「reftable」バックエンドは一部のテーブルをマージする必要があるかどうかを確認します。これは、シンプルなルールを使って行われます。具体的には、テーブルのリストがファイルサイズの[幾何数列](https://en.wikipedia.org/wiki/Geometric_progression)を形成しているかどうかをチェックします。すべてのテーブル`n`は、その次に新しいテーブル`n+1`の2倍以上のサイズでなければなりません。この幾何数列が維持されなかった場合、バックエンドはテーブルを圧縮して幾何数列を復元します。\n\n時間が経つにつれて、次のような構造になります。\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nすべてのテーブルにおいて、`size(n) > size(n+1) * 2`という性質が維持されていることに注目してください。\n\n自動圧縮がもたらすメリットのひとつは、「reftable」バックエンドのメンテナンスが自動化されることです。これにより、リポジトリで`git pack-refs`を実行する必要がなくなります。\n\n## さらに詳しく知りたい方へ\n\nこの記事では、新しい「reftable」フォーマットの仕組みについて解説しました。さらに詳しく知りたい場合は、Gitプロジェクトで提供される[テクニカルドキュメント](https://git-scm.com/docs/reftable)をご参照ください。\n\n> [Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)では、このバージョンにおけるその他の変更点をご確認いただけます。\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[678,702,9,811],"2025-02-04",{"slug":1111,"featured":91,"template":681},"a-beginners-guide-to-the-git-reftable-format","content:ja-jp:blog:a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format","ja-jp/blog/a-beginners-guide-to-the-git-reftable-format.yml","ja-jp/blog/a-beginners-guide-to-the-git-reftable-format",3,[662,686,711,732,751,771,795,819,840],1758326277361]