[{"data":1,"prerenderedAt":1192},["ShallowReactive",2],{"/ja-jp/blog/":3,"navigation-ja-jp":21,"banner-ja-jp":437,"footer-ja-jp":450,"blogCategories-ja-jp":661,"relatedBlogPosts-ja-jp":782,"maineFeaturedPost-ja-jp":1155,"recentFeaturedPosts-ja-jp":1160,"recentPosts-ja-jp":1176},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":13,"_id":15,"_type":16,"title":7,"_source":17,"_file":18,"_stem":19,"_extension":20},"/ja-jp/blog","ja-jp",false,"",{"title":9,"description":10},"Blog","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"title":12},"GitLab Blog",{"template":14},"BlogHome","content:ja-jp:blog:index.yml","yaml","content","ja-jp/blog/index.yml","ja-jp/blog/index","yml",{"_path":22,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":433,"_type":16,"title":434,"_source":17,"_file":435,"_stem":436,"_extension":20},"/shared/ja-jp/main-navigation",{"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,138,143],{"text":135,"config":136},"セキュリティとコンプライアンス",{"href":130,"dataGaLocation":28,"dataGaName":137},"Security & Compliance",{"text":139,"config":140},"ソフトウェアサプライチェーンの安全性",{"href":141,"dataGaLocation":28,"dataGaName":142},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"コンプライアンスとガバナンス",{"href":146,"dataGaLocation":28,"dataGaName":147},"/ja-jp/solutions/continuous-software-compliance/","Compliance and governance",{"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},"/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},"/images/navigation/the-source-promo-card.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},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":417,"config":422},{"src":423,"dataGaName":420,"dataGaLocation":415},"/images/brand/gitlab-logo-type.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":5,"_draft":6,"_partial":6,"_locale":7,"title":439,"titleMobile":439,"button":440,"config":445,"_id":447,"_type":16,"_source":17,"_file":448,"_stem":449,"_extension":20},"/shared/ja-jp/banner","GitLab 18と知的進化する次世代のDevSecOps。6月24日のオンラインイベントにご参加ください。",{"text":441,"config":442},"今すぐ申し込む",{"href":443,"dataGaName":444,"dataGaLocation":28},"/ja-jp/eighteen/","gitlab 18 banner",{"layout":446},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":451,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":452,"_id":657,"_type":16,"title":658,"_source":17,"_file":659,"_stem":660,"_extension":20},"/shared/ja-jp/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":649},"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,621],{"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},"/solutions/digital-transformation/","digital transformation",{"text":135,"config":508},{"href":130,"dataGaName":509,"dataGaLocation":459},"security & compliance",{"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/solutions/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,569,571,573,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":241,"dataGaLocation":459},{"text":239,"config":570},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":249,"config":572},{"href":251,"dataGaName":252,"dataGaLocation":459},{"text":262,"config":574},{"href":575,"dataGaName":265,"dataGaLocation":459},"/services/",{"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,605,610,612,614,616],{"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},"環境、社会、ガバナンス（ESG）",{"href":603,"dataGaName":604,"dataGaLocation":459},"/ja-jp/environmental-social-governance/","environmental, social and governance",{"text":606,"config":607},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":608,"dataGaName":609,"dataGaLocation":459},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":611},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":350,"config":613},{"href":352,"dataGaName":353,"dataGaLocation":459},{"text":355,"config":615},{"href":357,"dataGaName":358,"dataGaLocation":459},{"text":617,"config":618},"現代奴隷制の透明性に関する声明",{"href":619,"dataGaName":620,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":622},[623,625,627,629,634,639,644],{"text":35,"config":624},{"href":37,"dataGaName":38,"dataGaLocation":459},{"text":368,"config":626},{"href":370,"dataGaName":371,"dataGaLocation":459},{"text":373,"config":628},{"href":375,"dataGaName":376,"dataGaLocation":459},{"text":630,"config":631},"ステータス",{"href":632,"dataGaName":633,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":635,"config":636},"利用規約",{"href":637,"dataGaName":638,"dataGaLocation":459},"/terms/","terms of use",{"text":640,"config":641},"プライバシーに関する声明",{"href":642,"dataGaLocation":459,"dataGaName":643},"/privacy/","privacy statement",{"text":645,"config":646},"Cookieの設定",{"dataGaName":647,"dataGaLocation":459,"id":648,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":650},[651,653,655],{"text":635,"config":652},{"href":637,"dataGaName":638,"dataGaLocation":459},{"text":640,"config":654},{"href":642,"dataGaName":643,"dataGaLocation":459},{"text":645,"config":656},{"dataGaName":647,"dataGaLocation":459,"id":648,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",[662,676,688,700,712,724,736,748,760,771],{"_path":663,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":665,"content":668,"config":669,"_id":672,"_type":16,"title":673,"_source":17,"_file":674,"_stem":675,"_extension":20},"/ja-jp/blog/categories/agile-planning","categories",{"title":666,"description":667},"アジャイル計画","Browse articles related to アジャイル計画 on the GitLab Blog",{"name":666},{"template":670,"slug":671,"hide":6},"BlogCategory","agile-planning","content:ja-jp:blog:categories:agile-planning.yml","Agile Planning","ja-jp/blog/categories/agile-planning.yml","ja-jp/blog/categories/agile-planning",{"_path":677,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":678,"content":681,"config":682,"_id":684,"_type":16,"title":685,"_source":17,"_file":686,"_stem":687,"_extension":20},"/ja-jp/blog/categories/ai-ml",{"title":679,"description":680},"AIと機械学習","Browse articles related to AIと機械学習 on the GitLab Blog",{"name":679},{"template":670,"slug":683,"hide":6},"ai-ml","content:ja-jp:blog:categories:ai-ml.yml","Ai Ml","ja-jp/blog/categories/ai-ml.yml","ja-jp/blog/categories/ai-ml",{"_path":689,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":690,"content":693,"config":694,"_id":696,"_type":16,"title":697,"_source":17,"_file":698,"_stem":699,"_extension":20},"/ja-jp/blog/categories/bulletin-board",{"title":691,"description":692},"掲示板","Browse articles related to 掲示板 on the GitLab Blog",{"name":691},{"template":670,"slug":695,"hide":6},"bulletin-board","content:ja-jp:blog:categories:bulletin-board.yml","Bulletin Board","ja-jp/blog/categories/bulletin-board.yml","ja-jp/blog/categories/bulletin-board",{"_path":701,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":702,"content":705,"config":706,"_id":708,"_type":16,"title":709,"_source":17,"_file":710,"_stem":711,"_extension":20},"/ja-jp/blog/categories/customer-stories",{"title":703,"description":704},"お客様事例","Browse articles related to お客様事例 on the GitLab Blog",{"name":703},{"template":670,"slug":707,"hide":6},"customer-stories","content:ja-jp:blog:categories:customer-stories.yml","Customer Stories","ja-jp/blog/categories/customer-stories.yml","ja-jp/blog/categories/customer-stories",{"_path":713,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":714,"content":717,"config":718,"_id":720,"_type":16,"title":721,"_source":17,"_file":722,"_stem":723,"_extension":20},"/ja-jp/blog/categories/devsecops",{"title":715,"description":716},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":715},{"template":670,"slug":719,"hide":6},"devsecops","content:ja-jp:blog:categories:devsecops.yml","Devsecops","ja-jp/blog/categories/devsecops.yml","ja-jp/blog/categories/devsecops",{"_path":725,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":726,"content":729,"config":730,"_id":732,"_type":16,"title":733,"_source":17,"_file":734,"_stem":735,"_extension":20},"/ja-jp/blog/categories/engineering",{"title":727,"description":728},"エンジニアリング","Browse articles related to エンジニアリング on the GitLab Blog",{"name":727},{"template":670,"slug":731,"hide":6},"engineering","content:ja-jp:blog:categories:engineering.yml","Engineering","ja-jp/blog/categories/engineering.yml","ja-jp/blog/categories/engineering",{"_path":737,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":738,"content":741,"config":742,"_id":744,"_type":16,"title":745,"_source":17,"_file":746,"_stem":747,"_extension":20},"/ja-jp/blog/categories/news",{"title":739,"description":740},"ニュース","Browse articles related to ニュース on the GitLab Blog",{"name":739},{"template":670,"slug":743,"hide":6},"news","content:ja-jp:blog:categories:news.yml","News","ja-jp/blog/categories/news.yml","ja-jp/blog/categories/news",{"_path":749,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":750,"content":753,"config":754,"_id":756,"_type":16,"title":757,"_source":17,"_file":758,"_stem":759,"_extension":20},"/ja-jp/blog/categories/open-source",{"title":751,"description":752},"オープンソース","Browse articles related to オープンソース on the GitLab Blog",{"name":751},{"template":670,"slug":755,"hide":6},"open-source","content:ja-jp:blog:categories:open-source.yml","Open Source","ja-jp/blog/categories/open-source.yml","ja-jp/blog/categories/open-source",{"_path":761,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":762,"content":764,"config":765,"_id":767,"_type":16,"title":768,"_source":17,"_file":769,"_stem":770,"_extension":20},"/ja-jp/blog/categories/product",{"title":90,"description":763},"Browse articles related to 製品 on the GitLab Blog",{"name":90},{"template":670,"slug":766,"hide":6},"product","content:ja-jp:blog:categories:product.yml","Product","ja-jp/blog/categories/product.yml","ja-jp/blog/categories/product",{"_path":772,"_dir":664,"_draft":6,"_partial":6,"_locale":7,"seo":773,"content":775,"config":776,"_id":778,"_type":16,"title":779,"_source":17,"_file":780,"_stem":781,"_extension":20},"/ja-jp/blog/categories/security",{"title":126,"description":774},"Browse articles related to セキュリティ on the GitLab Blog",{"name":126},{"template":670,"slug":777,"hide":6},"security","content:ja-jp:blog:categories:security.yml","Security","ja-jp/blog/categories/security.yml","ja-jp/blog/categories/security",[783,827,871,885,929,965,1006,1043,1080,1118],{"category":666,"slug":671,"posts":784},[785,802,815],{"content":786,"config":799},{"title":787,"description":788,"authors":789,"heroImage":791,"date":792,"body":793,"category":671,"tags":794},"GitLabで実現するサイロのないSAFe","Scaled Agile Framework（SAFe）をDevSecOpsプラットフォームのネイティブ機能にマッピングする方法と、そこから得られるメリットについて学びましょう。",[790],"Amanda Rueda","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","2025-04-08","あなたの組織がScaled Agile Framework（SAFe）を導入し、エンタープライズ規模へとスケールしようとするとき、何が起こるのか考えてみましょう。複数のチームが複雑な製品の開発に取り組んでおり、すべての作業を調整する手段が必要になります。しかし、ここでよくある問題が発生します。計画はあるツールで行い、実際の開発作業はまったく別の場所で進められているという状況です。\n\nこのような分断は、日常業務においてさまざまな問題を引き起こします。デベロッパーは複数のシステムを行き来し、プロダクトマネージャーは正確な進捗状況を把握できず、誰もが情報を手作業でほかの場所へとコピーすることに時間を浪費します。これこそがまさに、SAFeが解消しようとしている「分断された体験」の典型です。\n\nすでに開発チームがGitLabを使ってソースコード管理、CI/CD、セキュリティを行っている場合、SAFeフレームワークでの計画管理にもGitLabを活用できるのかどうか疑問に思うかもしれません。幸いなことに、GitLabのアジャイルプロジェクト管理機能はSAFeを強力にサポートしています。この記事では、GitLabがSAFeの各種概念やセレモニーとどのように対応しているのかを紹介します。しかも、すべてデベロッパーがすでに慣れ親しんでいる同じDevSecOpsプラットフォーム上で実現できます。\n\n## SAFeとは？\n\nSAFe（Scaled Agile Framework）は、アジャイルの考え方をスピードや方向性、顧客重視の姿勢を失うことなく、大規模な組織全体に広げるための手法です。少人数チームで使われる柔軟かつ反復的なアジャイルの進め方を、複数のチームやロードマップ、関係者を抱える大規模組織にも適用できるように設計されています。このフレームワークを活用することで、組織全体の方向性が揃い、計画と実行が一貫して進むようになります。プロダクトマネージャーにとっては、SAFeを導入することで、戦略と実行をしっかりつなげることができ、とにかく早くリリースするだけでなく、チームで方向性を揃え、優先順位に基づいて本当に出すべきものをリリースできるようになります。\nSAFeはサイロを減らし、チーム間のコラボレーションを促進するとともに、単なる作業の実行ではなく、「顧客が求める成果」を中心にチームをまとめます。GitLabにSAFeを統合すると、可視性、トレーサビリティ、成果のすべてが、1か所に集約され、その効果はさらに高まります。\n\n## GitLabにおけるSAFeの用語対応\n\nまず、SAFeの概念がGitLab内でどのように対応するかを確認しましょう。\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | トップレベルエピック |\n| Capability | サブエピック（レベル1） |\n| Feature | サブエピック（レベル2） |\n| User Story | イシュー |\n| Task | タスク |\n| Team | カスタムフィールド/範囲指定したラベル |\n| Sprint | イテレーション |\n| Program Increment (PI) | マイルストーン |\n| Value Stream | トップレベルグループ |\n| Agile Release Train (ART) | トップレベルグループ |\n\n\u003Cbr>\u003C/br>\n\nこの対応表をガイドとして活用すると、GitLabをSAFeの実装と連動させて構築できます。グループ構造を使うと、バリューストリームやART（Agile Release Train）単位で整理できます。また、最大7階層までネスト可能なエピックによる作業アイテムの階層構造により、複雑なプロダクトポートフォリオにも対応できる深さを備えています。ポートフォリオレベル（トップレベルグループ）、プログラムレベル（サブグループ）、チームレベル（プロジェクト）といった、どの階層で作業していても、GitLabの組織構造はSAFeの階層とぴったり合致します。\n\n## GitLabでのSAFeのセレモニーのサポート\n\nここからが本題です。GitLab上でSAFeのセレモニーを実際にどう実行するのか、順を追って見ていきましょう。\n\n### PIプランニング\n\nチーム間の調整と依存関係の管理を促進し、PIプランニングを成功させるために、GitLabでは以下のような機能が提供されています。\n\n* [ロードマップ](https://docs.gitlab.com/user/group/roadmap/)ビューを使用して、複数のチームや期間にわたるフィーチャーを可視化する\n* フィーチャーをPI[マイルストーン](https://docs.gitlab.com/user/project/milestones/)に割り当てる\n* 見つかったチーム間の[依存関係](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues)を文書化し、視覚化する\n\nGitLabでは、エピックボード（チームごとの割り当てを表示するように設定可能）とロードマップビュー（ガントチャートのように時間軸でフィーチャーを表示）を使い分けることで、柔軟にPIプランニングを進めることができます。タイムラインかチーム構成のどちらに注目するかに応じて、プランニング中にビューを切り替えられます。\n\n![ロードマップビューとエピックボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![ガントチャート付きロードマップビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### リファインメント\n\nプロダクトマネージャーにとって、効果的なリファインメントを行うには、フィーチャーのバックログを明確に把握しておくことが重要です。GitLabなら、リファインメントをそのままGitLab上で実施できます。会議中に1つのツールを更新して、その後に別のツールを更新する必要はもうありません。 \n\nGitLabでは、以下の機能によってリファインメントを効率的に進められます。\n\n* 状態ごとにフィーチャーを整理できる[エピックボード](https://docs.gitlab.com/user/group/epics/epic_boards/)\n* ストーリーポイントを[概要](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic)ビューで直接確認できる機能\n* 作業アイテムをその場で操作しながら、全体の文脈を見失わない包括的な[drawerビュー](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer)\n* エピックから[子イシュー](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic)を直接作成・リンクできる機能 \n\n![SAFe - 画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### スプリント計画\n\n次のスプリントでチームが取り組む作業を決めるタイミングでは、GitLabの以下の機能を活用できます。\n\n* バックログを包括的に確認できる[イシューボード](https://docs.gitlab.com/user/project/issue_board/)\n* ボード上にユーザーストーリーの[合計ウェイト](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights)を直接表示\n* イシューを簡単にイテレーション間で移動できる機能\n* スプリント間のストーリー移動を効率化する折りたたみ可能なビュー\n\nつまり、すべてを1か所に集約して管理でき、プランニングミーティングではツールを行き来するのではなく、実際の計画に集中できます。\n\n![GitLabで行うスプリント計画](// images.ctfassets.net/r9o86ar0p03f/7KXnAye9JcMZsv7exICm41/a9ee23c95b58c172bd59e61410e58ef6/image4.gif )\n\n* GitLabを活用したスクラムの進め方については、[こちら](https://docs.gitlab.com/tutorials/scrum_events/)のチュートリアルをご覧ください。アジャイルプランニングやスプリントの進捗管理におけるGitLabの便利な機能を詳しく確認できます。*\n\n### デイリースタンドアップ\n\nデイリースタンドアップでは、チーム全員がボードを囲んで、誰が何に取り組んでいるか、どこで詰まっているか、どの作業がレビュー待ちかを、すべて単一のビューで確認できます。GitLabでは、以下の機能が開発チームのデイリースタンドアップに役立ちます。\n\n* 現在のスプリントに絞った[イテレーションスコープ付き](https://docs.gitlab.com/user/project/issue_board/#iteration-lists)のボードを作成\n* 各カード上にストーリーポイント/ウェイトを直接表示\n* コンテキストを失わずに詳細にアクセスできる[drawerビュー](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer)の活用\n* [ヘルスステータス](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status)でリスクのあるタスクをハイライト表示\n\n![デイリースタンドアップのボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n### スプリントレビュー\n\nチームの進捗状況を継続的に把握したいですか？GitLabでは、以下のような包括的なメトリクスを利用できます。\n\n* イテレーションごとの[バーンダウンチャートおよびバーンアップチャート](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts)\n* ベロシティのトラッキング\n* [リードタイムおよびサイクルタイム](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics)のメトリクス\n* チーム単位でスコープ設定できるダッシュボード\n\nこれらの指標により、チームのスピードが上がっているか、どこでつまずいているか、そして次回のレトロスペクティブで話し合うべきポイントを明確に把握できます。\n\n![バーンダウンチャートとバーンアップチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n## 統合プラットフォームが強みとなる5つの理由\n\nSAFeのセレモニーを管理できる計画ツールはたくさんあります。でも、GitLabが本当に他と違うと私が感じているのには、明確な理由があります。\n\n1. **頭の切り替えが不要** - 計画、コーディング、テスト、セキュリティのすべてを、1か所で完結できます。\n2. **すべてがつながっている** - 大きなエピックからコード、デプロイまで、作業の流れをたどれます。\n3. **全員が同じ認識を持てる** - デベロッパー、プロダクト担当、セキュリティチームが、同じツール上で連携できます。\n4. **完全な可視性** - ステークホルダーは、進捗の確認を1か所で行えます。\n5. **全体像が見える** - 計画と開発のメトリクスをまとめて確認できるため、本当の状況が明確になります。\n\nもしあなたの開発チームがすでにGitLabを使いこなしているなら、プランニングのためだけに別のツールへ切り替えたり、複雑なインテグレーションを無理やり組み合わせたりする必要はありません。SAFeプランニングをGitLabに取り込むことで、チーム全体にとってはるかにスムーズな体験が得られます。\n\n## 実装の原則\n\n私は従来型のSAFeツールからGitLabへの移行に取り組むチームと協力してきましたが、その経験から学んだことがあります。それは、以前のツールをそのまま再現しようとするのではなく、**それぞれのセレモニーが何を目的としているか**に注目することが重要だということです。\n\nGitLabの利点を最大限に活用しているのは、GitLabのネイティブ機能を素直に受け入れて、それに逆らわずに活用しているチームです。もちろん、SAFeの概念をどうマッピングするか、ワークフローをどう構築するかを最初に整理するには少し手間がかかります。しかし、一度その形ができてしまえば、プロセスは複雑になるどころか、むしろシンプルになります。\n\n成功のカギは、全員が従うべき規則を定義することです。どのラベルが何を意味するのか？ チームをどう追跡するのか？エピックとイシューにはそれぞれ何を入れるのか？こうした判断を事前に少し整理しておくだけで、複数ツール間の調整にかかっていた手間を解消できる、直感的なシステムが手に入ります。\n\n## 導入を始める\n\nさて、試してみる準備はできましたか？GitLabでSAFeを導入するためのステップは以下のとおりです。\n\n1. **構造を整える** - [組織構成](https://about.gitlab.com/ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/)に合わせて、グループやサブグループを作成します。\n2. **作業の詳細を定義する** - [エピック](https://about.gitlab.com/ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/)、[イシュー](https://docs.gitlab.com/user/project/issues/managing_issues/)、[タスク](https://docs.gitlab.com/user/tasks/)をどのように使い分けるかを定義します。\n3. **イテレーションを作成する** - [スプリントのスケジュール](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence)を設定します。\n4. **マイルストーンを追加** - GitLab上でプログラムインクリメント（PI）を表す[マイルストーン](https://docs.gitlab.com/user/project/milestones/#create-a-milestone)を作成します。 \n5. **ボードを構築する** - セレモニーごとに異なるビューを用意します。\n6. **規則について合意する** - ラベルやカスタムフィールドの使い方を文書化し、チームで統一します。\n\nこれらのポイントを最初にしっかり考えておくことで、後々のトラブルや混乱を避けられます。そして、初日から完璧にする必要はないことを忘れないでください。運用しながら学び、必要に応じていつでも調整できます。\n\n## すべてをまとめる\n\nGitLabは、SAFeを実行するための堅実な基盤を提供します。特に、あなたの開発チームがすでにGitLabに慣れ親しんでいる場合には最適です。計画と開発を同じツール上で進めることで、煩雑なハンドオフが不要になり、コラボレーションが格段にしやすくなり、すべての動きがよりスピーディになります。\n\nGitLabのプランニングツールの魅力は、あなたのチームに合わせて柔軟にSAFeをカスタマイズできることです。 決められた型にはまる必要はありません。チームが成熟し、ニーズが変われば、それに応じて運用方法も進化させることができます。\n\n> サイロ化したプランニングにさよならして、もっと快適なワークフローを体験してみませんか？まずは[無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)して、GitLabがどのようにSAFe導入を変革できるかを実感してください。\n\n*💡 このトピックに興味を持った方は、関連記事の[アジャイルソフトウェア開発におけるGitLabの活用法](https://about.gitlab.com/ja-jp/blog/gitlab-for-agile-software-development/)もぜひご覧ください*\n",[795,796,797,766,798],"agile","DevSecOps platform","features","tutorial",{"slug":800,"featured":91,"template":801},"safe-without-silos-in-gitlab","BlogPost",{"content":803,"config":813},{"title":804,"description":805,"authors":806,"heroImage":807,"date":808,"body":809,"category":671,"tags":810,"updatedDate":812},"アジャイルのスプリントを製品ロードマップと調和させる方法","ベストプラクティスとGitLabの機能を活用して、製品開発を進めましょう。一元化されたロードマップの作成、レビューセッションの実施、スプリントのライフサイクルの追跡など、製品開発をスムーズに進めるためのポイントを解説します。",[790],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","2025-02-04","製品チームと開発チームが協力せずに、それぞれ作業している様子を想像してみてください。たとえば、製品チームが12か月分のロードマップを作成して社内に共有したものの、開発チームのレビューは受けてなかったとします。このため、開発チームは、全体の計画を把握しないまま、次のスプリントで予定されている機能の開発を始めました。その影響で、プロジェクトの並行実施、チームキャパシティの考慮、再利用可能なAPIの構築など、本来なら最適なタイミングで進められたはずの機会を逃してしまいます。最終的に、非効率的になり、価値の提供も遅れてしまいます。\n短期的な成功と長期的なビジョンのバランスを取るのは簡単ではありません。明確なコミュニケーション、優先事項の調整、そして適切なツールが必要です。このガイドでは、アジャイルのスプリントを戦略的ロードマップと調和させる方法、よくある課題への取り組み方、チームに合わせた実践的なアプローチをご紹介します。\n\n## 信頼できる唯一の情報源の重要性\n\n長期的目標を含むロードマップに関する、信頼できる一貫した唯一の情報源があれば、チームは常に最新の全体像にアクセスできます。具体的には、ロードマップの情報をひとつのプラットフォームに集約し、定期的に更新することを意味します。逆に、一元化されていない、つまり微妙に差があるロードマップを複数管理する場合、方向性の理解にずれが生じてしまいます。\n\n### 一元化されたロードマップを作成する\n\n一元化されたロードマップを作成することで、次のことが可能になります。\n\n* 長期的な戦略を伝える\n* 伝達ミスを最小限に抑える\n* 部門間の足並みが揃いやすくなる\n* 背景を把握しながら、変化に素早く対応する\n* 情報を自分で取得でき、情報を保持する単一の窓口への依存度を減らす\n\n***GitLabに関するヒント**：[エピック](https://docs.gitlab.com/ee/user/group/epics/)と[ロードマップ表示](https://docs.gitlab.com/ee/user/group/roadmap/)を使用すれば、製品計画と進捗の透明性を確保できます。ロードマップ表示を使用すると、進捗の追跡やボトルネックの特定に加え、全体的な目標とスプリントレベルでの実施内容を確実に一致させることができます。* \n\n![グループのロードマップ表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## ロードマップの共同レビューの実施\n\n[プロダクトトリオ](https://www.producttalk.org/product-trio/)（製品チーム、エンジニアリングチーム、ユーザーエクスペリエンスチーム）は連携し、定期的なロードマップのレビューと合意を得る仕組みを作りましょう。共同レビューを行うことで、チーム間の認識が揃い、リスクの早期発見と対処につながります。GitLabのプロダクトマネージャーは、エンジニアリングマネージャー、UXデザイナーと毎月ミーティングを行い、変更内容をレビューしてもらった上で、承認を得ています。Wikiに承認の記録を残しておくことで、スケジュールへの責任を明確にし、社内の他のメンバーに対してオープンに情報を提供しています。\n\n#### レビューセッションの効果を高める方法\n\nレビューの場を有意義なものにするには、以下のベストプラクティスを意識しましょう。\n\n* ロードマップの変更頻度に応じて、月ごとまたは四半期ごとの定期的なレビューを設定する。\n\n* 潜在的なリスクや依存関係をあらかじめ議論することで、製品目標、UXのリードタイム、技術的実現可能性の間の整合性を検証する。\n\n  * ロードマップに組織のビジネス目標が反映されているかどうかを検証する。\n  * 設計のタイムラインが現実的であり、技術的な調査や検証の必要性が考慮されていることを確認する。\n\n* チームのキャパシティの制約を考慮し、作業順序をチームのスキルプロファイルに合うよう工夫して、チームの生産性を最適化する：\nこれには、休暇期間中のスタッフ減少といった状況を見越して計画を立てながら、チームの能力の活用不足やスキルのミスマッチを避けることも含まれます。\n\n* スコープを正しく設定し、何が達成できるかについて適切な期待値を設定する：\n「全部やりたい」という気持ちを抑え、何を優先すべきかを明確にし、段階的に価値を提供するよう心がけることが大切です。タスク間の依存関係を減らしたり、再利用可能なコンポーネントを活用するなど、イテレーションの改善や開発速度を上げる方法を特定して、最適化できる機会を模索します。\n\n* トレードオフや優先順位についてオープンに話し合い、多角的な視点を取り入れる：\nこのような協調的なアプローチを取ることで課題に対して新しい視点や発想を取り入れた解決策が見つかり、今後の方向性について合意を得やすくなります。\n\n***GitLabに関するヒント**：[GitLab Wiki](https://docs.gitlab.com/ee/user/project/wiki/)を活用して[ロードマップ](https://docs.gitlab.com/ee/user/group/roadmap/)機能を補完しましょう。Wikiには、ビジネス上の根拠、ユーザー調査へのリンク、RICEスコア、依存関係やリスクに関する詳細など、製品ロードマップに関する幅広いコンテキストを記載できます。アクセスしやすいようにロードマップへの直リンクを記載し、今後のディスカッションスレッド機能を活用して、非同期コラボレーションを促進し、チームからのフィードバックを得られるようにしましょう。*\n\n![PlanFlow製品のロードマップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## 継続的な方向性の検証と進捗測定\n\n製品ロードマップを作成する目的は、予定どおりに進めることだけでなく、顧客に真の価値を提供することです。ユーザーからの継続的なフィードバックや行動データを共有する機会を設けるために、スプリントのサイクルとは別に、定期的にプロダクトトリオの三者で集まる場を設けることを検討してください。このようなセッションでは、インサイトの確認やトレンドの分析、そしてユーザーの変化し続けるニーズが製品ロードマップに反映されていることを確認します。実際のユーザーから得たインサイトに基づき、ロードマップを更新することで、単に予定していた機能をリリースするだけでなく、顧客にとって本当に重要な価値を提供できます。\n顧客にとっての価値は、使いやすさの向上、技術的負債の削減、またはまったく新しい機能の提供など、さまざまです。プロダクトトリオがロードマップのビジョンで一致していれば、達成しようと目指している成果に関しても足並みが揃っている状態だと言えます。\n成果の達成に向け順調かどうかを測定するには、想定する成果がどのようなものであるかを明確に定義する必要があります。後からユーザーストーリーを追加するといったスコープクリープ（スコープの拡大）は、価値の提供を遅らせてしまう恐れがあります。さらに、ロードマップに沿っていない作業があれば、価値を提供した後であっても特定し、なぜそうなったのか理由を把握することも重要です。\n\n### スプリント計画\n\n製品ロードマップとの整合性を保つには、まずは綿密なスプリント計画を立てる必要があります。ここでは、チームが作業を順調に進め、価値の提供に重点的に取り組むために役立つベストプラクティスをいくつかご紹介します。\n\n- デリバリーに対して確信を持てるように、求める成果を明確に定義し、範囲を絞り込んで設定する。\n- デリバリーを遅らせる可能性のある遅めの段階での追加や調整を特定し、継続して注力できるようにバッファを設ける。\n- チームと作業順序を調整し、キャパシティやスキルプロファイルを最適化し、依存関係を減らす。\n- 集中力を維持し、納期遵守の確実性を高めるために、チームのキャパシティが一杯になるような計画はしないようにする。スプリント中に発生する可能性のある未知の問題や新たな発見に備えて、バッファ（10%～20%）を設けておきましょう。\n\n### スプリント期間中\n\nスプリント期間中にロードマップとの整合性を保ち続けるには、集中力とコミュニケーションに加え、継続的な評価が必要です。価値の提供が目標である一方で、進行中の作業が、事前に決めて計画した成果に沿っているかどうかを確認することも同様に重要です。\n\n- 進行中の作業をロードマップで定めた成果と照らし合わせて継続的に検証し、各スプリントが全体像に寄与しているかを確認する。\n- 想定している目標や成果に向けて引き続き取り組んでいるかどうか、定期的に確認するようチームに促す。\n- スプリントを通じてオープンなコミュニケーションを保つ：デイリースタンドアップミーティングや非同期なアップデートを用いて、リスクや予定外の作業、依存関係を早い段階で明らかにし、必要に応じて調整します。\n- 何が何でもスプリントに沿って行動する：新たに生じた問題を解決したいという衝動に駆られるのは当然ですが、事前に合意した優先順位を見失うことのないように、計画していなかった作業は慎重に見極める必要があります。\n- スコープクリープを主体的に管理する：スプリントの途中で新たな作業が出てきた場合、それが現在のロードマップで定めた注力対象にあっているかを確認しましょう。たとえ魅力的なアイデアや機能であっても、。直近の価値提供という観点では優先度が低いかもしれません。このような内容は文書化し、今後のイテレーションに含めるか、あとで検討する項目として整理しましょう。現在のスプリントで取り組むものとした優先事項を後回しにするのは避けるべきです。\n\n### スプリントレトロスペクティブ（ふりかえり）\n\nスプリントレトロスペクティブでは、チームが目指す成果にどれだけ近づけたかを「ふりかえる」時間を取りましょう。以下の質問を投げかけることをおすすめします。\n\n- スプリント期間中に、予定外の作業によって価値の提供が遅れたことはなかったか？その原因は何だったか？どのように対応すればよかったか？\n- ロードマップとずれた作業がなかったか。その背景や経緯は？今後にどう活かせるか？そこから学んだことを話し合いましょう。\n\nスプリント計画からスプリントレトロスペクティブまで、ユーザーと関係者に具体的な成果をもたらすことチームの重要な役割です。各ステップで足並みを揃えることで、ロードマップが価値を効率的かつ継続的に提供する道標になります。\n\n***GitLabに関するヒント**：[バーンダウンチャート](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)を使用すると、進捗状況が可視化され、早い段階でロードマップからの逸脱が検知できるため、チームが成果の達成に集中しやすくなります。*\n\n![バーンダウンチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## ロードマップで定めた成果を確実に実現する\n\nアジャイルのスプリントと戦略的なロードマップを結びつけるには、意図的な取り組み、チームの賛同、そして適切なツールが必要です。信頼できる唯一の情報源としてロードマップを作成し、共同レビューを実施し、進捗状況を測定することで、ビジョンに沿った行動を取ることができます。GitLabの強力な計画機能を活用することで、チームは課題をイノベーションと成長の機会へと変えることができます。\n\n早速、戦略的ロードマップに合わせてスプリントを進めてみませんか？[GitLabの無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/)して、確実に成果を実現するために役立つツールを試してみましょう。\n\n## 関連リンク\n\n* [アジャイルプランニングのコンテンツハブ](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)  \n* [アジャイルプランニングチームに特化したGitLabの新しい「プランナーロール」のご紹介](https://about.gitlab.com/ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)」（日本語）  \n* [効果的なナレッジマネジメントの実施に役立つGitLab Wikiのご紹介](https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)（英語）\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[795,798,811,796],"workflow","2025-06-04",{"slug":814,"featured":91,"template":801},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"content":816,"config":825},{"title":817,"description":818,"authors":819,"heroImage":820,"date":821,"body":822,"category":671,"tags":823,"updatedDate":824},"アジャイルプランニングチームに特化したGitLabの新しい「プランナー」ロールのご紹介","GitLabの新しい「プランナー」ロールを活用して、SaaS、GitLab Dedicated、Self-Managedといった各ソリューションでのアクセス権を最適化し、アジャイルチームの計画ワークフローを効率的に管理する方法についてご説明します。",[790],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","2024-11-25","GitLabは、DevSecOpsプラットフォームに新たなロール「プランナー」を導入しました。以前リリースされた[カスタムロール機能と同様に](https://docs.gitlab.com/ee/user/custom_roles.html)、「役割に応じた柔軟なアクセス制御を実現する」というGitLabの戦略に基づいて開発されました。このロールは、ソフトウェア開発チームや計画に携わるユーザーに対し、過剰な権限を付与することなく、アジャイル開発のワークフローを管理するために必要なツールへのアクセス権を提供します。これにより、過剰な権限付与によるセキュリティリスクの増加を防止できます。プランナーロールを活用してユーザーごとの特定のニーズに合わせてアクセスを調整することで、チームは生産性を維持しつつ、セキュリティとコンプライアンスを確保し、[最小権限の原則](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)を遵守できます。\n\n## プランナーロールが開発された理由\n\nこの新しいロールの開発は、お客様や社内チームからのフィードバックをきっかけに始まりました。GitLabはアジャイル開発サイクルを計画および管理するための包括的なツールを提供していますが、役割に基づくより具体的なアクセス制御が必要だという声が度々寄せられていました。プロダクトマネージャーやプロジェクトリード、その他の計画業務を担当する役割は、計画機能へのアクセスは必要ですが、開発全体の権限は必要ありません。実際、必要以上のアクセス権は、セキュリティリスクだけでなく、コードや重要な設定に意図しない変更を加える可能性も高めるため、好ましくありません。このようなフィードバックを受け、GitLabは対応を進めました。\n\nユーザーへの聞き取り、競合分析、そして徹底的な調査を通じて、新しいロールの必要性が明確になりました。計画ツールへの十分なアクセスを提供しつつ、デベロッパー向けの機能へのアクセスを制限することでセキュリティを確保するロールが求められていました。\n\n## プランナーロールの特徴\n\nプランナーロールは、既存の[ゲストロールとレポーターロール](https://docs.gitlab.com/ee/user/permissions.html#roles)を組み合わせたハイブリッドロールであり、計画ワークフローへのアクセスが必要なユーザー向けに特化して設計されています。\n\nこのロールを使用すると、以下のことを行えます。\n\n* 主要な計画ツール（エピック、ロードマップ、イシューボード、[OKR](https://docs.gitlab.com/ee/user/okrs.html)など）へのアクセスを許可する（*一部の機能はGitLab PremiumまたはGitLab Ultimateのライセンスが必要です*）\n* 機密性の高い開発関連の機能への不要なアクセスを制限することで、セキュリティを強化する\n* プランナーロールをGitLab Enterprise Agile Planningアドオンと併用することで、チームに計画ツールへのカスタマイズされたアクセスを提供しつつ、セキュリティと制御を維持する（*プランナーロール単体はすべてのライセンスプランで利用可能です*）\n\nプランナーロールは、SaaS、GitLab Dedicated、Self-Managedを含むすべてのGitLabソリューションで利用可能となっており、すべてのお客様がこのカスタマイズされたアクセス制御のメリットを活用できます。\n\nこのロールを使用することで、チームは職務に応じて権限を柔軟に調整でき、アクセス性とセキュリティのバランスを確保できます。\n\n## アジャイル手法の実践を後押しするプランナーロールの役割\n\n[アジャイルソフトウェア開発](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)において、各チームメンバーにそれぞれの役割に即したツールと権限を与えることは、ワークフローを効率化する上で非常に重要です。プランナーロールは、計画チームのメンバーが開発やデプロイといった領域に踏み込み過ぎるリスクを排除しつつ、ソフトウェア開発ライフサイクルの計画段階に適切に参加できるようにすることで、アジャイル開発をサポートします。\n\nプランナーロールは、エピックの作成・管理からロードマップの定義まで、アジャイルチームが連携を保ちながら効率的に業務を進めるために必要なツールを提供します。\n\n## お客様中心の設計\nこのロールは、GitLabが単独で作り上げたものではありません。プロセスのすべての段階でコミュニティの意見を取り入れてきました。具体的には、アンケート調査、インタビュー、テストを通じて、プロダクトマネージャーやプロジェクトマネージャーの実務上のニーズに合致するよう、権限を細かく調整しました。\n\nまた、このロールには「エンタープライズアジャイルチーム向けのプラットフォームを提供する」というGitLabの長年の使命が反映されており、企業がアジャイル開発手法を大規模に導入する上で必要な柔軟性と制御性を提供します。\n\n## コミュニティのフィードバックとエンゲージメント\n\nGitLabでは、皆様からのご意見を大変重視しており、新しいプランナーロールに関するご感想をぜひお聞かせいただきたいと考えています。皆様からのフィードバックは、GitLabの利用体験の改良・改善に欠かせません。ご意見やご提案がありましたら、ぜひ[フィードバック用イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/503817)からお寄せください。\n\n## 今すぐGitLabで計画を始めましょう！\n\nGitLabは、ソフトウェア開発チームの効果的な計画、コラボレーション、デリバリーをさまざまなアプローチを通じて支援しており、プランナーロールはそのうちの一つにすぎません。GitLabは、製品管理ワークフローの効率化、チームコラボレーションの強化、アジャイル手法の整備など、あらゆる目的の達成を支援する充実したツールを取り揃えています。\n\n> GitLabのすべての機能をお試しになりたい場合は、ぜひ[GitLab Ultimateの60日間無料トライアルにご登録](https://about.gitlab.com/ja-jp/free-trial/)ください。チーム独自のニーズに合わせてカスタマイズされたプランナーロールを活用して、次のプロジェクトの計画を始めましょう。\n\n## その他の記事\n- [開発チームだけでなく、あらゆる職務に対応可能なGitLab Enterprise Agile Planningアドオン（英語）](https://about.gitlab.com/blog/gitlab-enterprise-agile-planning-add-on-for-all-roles/)\n- [GitLabをアジャイルソフトウェア開発で使用する方法](https://about.gitlab.com/ja-jp/blog/gitlab-for-agile-software-development/)\n- [初公開：新しくなったGitLabのアジャイル計画（英語）](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/)\n\n\u003Cbr>\n\u003Cbr>\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n",[795,796,797,766],"2025-05-01",{"slug":826,"featured":91,"template":801},"introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"category":679,"slug":683,"posts":828},[829,845,858],{"content":830,"config":843},{"heroImage":831,"body":832,"authors":833,"updatedDate":835,"date":836,"title":837,"tags":838,"description":842,"category":683},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1750096976/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750096975734.png","コードレビューは、バグの検出、コードの可読性の向上、コーディング標準の順守の徹底に不可欠ですが、その一方でワークフローにおける大きなボトルネックになることもあります。迅速に機能をリリースしようとする際に、複数のチームメンバーによるコードレビューの完了を待つのは歯がゆいものです。多くのやり取りが発生するディスカッション、スケジュールの衝突、チーム全体の合意形成にかかる時間などによって、本来は簡単なレビューが数日から数週間に及ぶことがあります。\n\nそこでおすすめなのが、[GitLab Duo with Amazon Q](https://about.gitlab.com/ja-jp/blog/2025/04/17/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)です。AWSユーザー向けにソフトウェア開発ライフサイクル全体にわたって自律型AIを提供するGitLab Duo with Amazon Qを使用すれば、レビュープロセスを変革できます。このAI搭載ソリューションは、チームメンバーがこれまで費やしていたほんの一部の時間で、包括的なコードレビューを実行できます。GitLab Duo with Amazon Qは高度な自律型AI機能を活用することで、必要な品質や徹底性を犠牲にすることなく、レビューワークフロー全体を効率化します。たとえるなら、瞬時にコードを分析して実用的なフィードバックを提供できる非常に熟練したレビュアーがいて、いつでも対応可能な状態のようなものです。\n\n## 仕組み：コードレビューの開始\n\nでは、GitLab Duo with Amazon Qが実際にどのように機能するかをご説明します。ある機能に関する作業が終わり、ちょうど複数のコード更新を含むマージリクエストを作成したところだとします。コードレビューの開始方法は非常に簡単です。チームメンバーに連絡して対応可能かどうかの返答を待つ代わりに、コメントセクションに「/q review」というシンプルなコマンドを入力するだけです。これだけでAIによるコードレビューがトリガーされます。\n\n\n![GitLab Duo with Amazon Qを使用したコードレビューがトリガーされている様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097002/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097002096.png)\n\n\nコマンドが入力されると、Amazon Q Servicesはすぐにコード変更の分析を開始します。レビューを実行中である旨の確認メッセージが表示され、数秒のうちにAIが更新内容のすべての行を調査し、さまざまな側面から潜在的な問題がないかをチェックします。\nレビューが完了すると、バグの検出、可読性の改善、構文エラー、チームのコーディング標準への準拠など、すべての基準を網羅した包括的なフィードバックが表示されます。AIによって問題が特定されるだけでなく、修正のためのコンテキストと修正案も提供されるため、対応が必要な箇所とその理由を簡単に把握できます。\n\nこの自律型AIアプローチの優れた点は、コードレビューの面倒な作業をAIにまかせられるため、デベロッパーが最も重要な作業である「優れたソフトウェアの開発」に集中できることです。時間を無駄に費やすことなく、バグ検出精度の向上、コーディング標準の順守、コード品質の向上など、徹底したコードレビューのメリットを享受できます。さらに、レビューの待ち時間がなくなるため、デプロイまでの時間が大幅に短縮され、チーム全体の生産性が向上します。\n\n## GitLab Duo with Amazon Qの導入メリット\n\nGitLab Duo with Amazon Qを使用することで、以下のように開発プロセスを変革できます。\n- 品質を妥協しない、迅速なコードレビュー\n- コードベース全体にわたってコーディング標準を一貫して適用\n- 本番環境に到達する前に問題を修正できるよう、即座にフィードバックを提供\n- デプロイまでの時間が短縮されるため、より迅速に機能をリリース可能\n- レビューを何度も行わずに済むため、本質的な問題解決に集中できる時間が増加\n\n以下の動画では、GitLab Duo with Amazon Qを使用してコードレビュープロセスに変革をもたらす方法についてご紹介しています。ぜひこの革新的な機能に関する動画をご覧ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> GitLab Duo with Amazon Qの詳細については、 [お近くで開催されるAWS Summit](https://about.gitlab.com/events/aws-summits/) にご参加いただくか [GitLab担当者にお問い合わせ](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)ください.\n> \n> また、自律型AIの今後の計画などについてご紹介するGitLab 18オンラインリリースイベントにもぜひご参加ください。[ご登録はこちら](https://about.gitlab.com/ja-jp/eighteen/)",[834],"Cesar Saavedra","2025-06-24","2025-06-02","GitLab DuoとAmazon Qでコードレビューを加速",[839,796,840,766,797,285,841,798],"AI/ML","code review","AWS","AI搭載エージェントを使用して、コードレビューを最適化しましょう。自動的にマージリクエストを分析し、バグや可読性、コーディング標準に関する包括的なフィードバックを得られます。",{"featured":91,"template":801,"slug":844},"accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"content":846,"config":856},{"title":847,"description":848,"authors":849,"heroImage":851,"date":852,"body":853,"category":683,"tags":854,"updatedDate":855},"GitLab Duo Chatが自律型AIでさらに進化","実験的なリリースとして提供が開始された新しいGitLab Duo Chatは、デベロッパーがプロジェクトに参加したり、担当作業を理解したり、変更を実装したりする際に役立ちます。",[850],"Torsten Linz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png","2025-05-29","生成AIのチャットアシスタントは、ソフトウェア開発の現場で一般的に使われるようになり、コードの作成や修正をサポートします。もしそのチャットアシスタントが、コードだけでなく開発プロセス全体のアーティファクトを理解できたとしたらどうでしょうか？コードを書く前にイシューやプロジェクトドキュメントの確認を手伝い、CI/CDパイプラインやマージリクエストにアクセスして、コーディング作業を適切に完了できるように支援してくれるとしたらどうでしょうか？\n\n**こうした高度な開発支援を実現するのが、次世代のGitLab Duo Chat「GitLab Duo Agentic Chat」です。これは、AIネイティブな開発支援の大きな進化形であり、現在は[実験的なリリース](https://docs.gitlab.com/policy/development_stages_support/#experiment)としてGitLabプラットフォームに新たに追加された機能です。** GitLab Duo Agentic Chatは、VS CodeでGitLab Workflow拡張機能をお使いのGitLab.comユーザーであれば利用できます。\n\nAgentic Chatは、従来の対話型AIによるチャット体験を、ユーザーに代わってアクションを実行するチャット体験に変革します。複雑な問題を細かいタスクに分割し、自律的に完了することができます。Agentic Chatは、提供されたコンテキストに基づいて質問に答えるだけでなく、以下のようなことができます。\n\n* 質問に答えるために必要な情報を**自律的に判断する**\n* 複数の情報源から必要な情報を取得するための**一連の操作を実行する** \n* プロジェクト全体から得られる分析結果を組み合わせて、**包括的な回答を作成する**\n* ソリューションを実装するために**ファイルを作成、編集する**\n\nこれらすべての作業が、人間のデベロッパーが常に状況を把握できる状態で行われます。\n\nAgentic Chatは、[現在プライベートベータ版](https://about.gitlab.com/ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)のDuo Workflowアーキテクチャ上に構築されています。このアーキテクチャは、与えられた質問に適したコンテキストを見つけたり、ファイルを編集したりするなど、特定のタスクを担うエージェントとツールで構成されています。\n\n**GitLab Duo Agentic Chatのユースケース**\n\nここでは、Agentic Chatの実際の活用例と一般的なユースケースをご紹介します。\n\n* __新しいプロジェクトにすばやくオンボーディング__：新しいコードベースに慣れる作業をAIが支援することで、より迅速にプロジェクトに参加できます。\n\n* __担当業務にすぐに着手__：イシューの説明が不明確でも、Agentic Chatが要件と既存の実装との関連性を示してくれるため、すぐに担当作業に取りかかることができます。\n\n* __変更の実装支援__：変更作業が必要になった際には、Agentic Chatがプロジェクト全体にわたって複数のファイルを作成、編集し、実装を支援します。\n\n* __リリース時の検証__：リリースの段階では、Agentic Chatがマージリクエストと元のイシューやタスクを照らし合わせて、ソリューションが本当に要件を満たしているかを検証する手助けをします。\n\n![agentic chat - 例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099210/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099210429.png)\n\n\u003Ccenter>\u003Ci>コードの編集を行う Agentic Chat\u003C/i>\u003C/center>\n\n## 学習からリリースまで：4ステップの開発ワークフロー\n\nGitLabエンジニアリングチームの実際のシナリオを通じて、Agentic Chatが開発体験をどのように変革するかをご紹介します。あなたはチームの新メンバーとして、イシューを割り当てられましたが、コードベースについてはまだ何も知らないとします。 それでは、以下のデモ動画に従って体験してみましょう。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/uG9-QLAJrrg?si=kaOhYylMIaWkIuG8j\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**ステップ1：プロジェクトを理解する**\n\nファイルやドキュメントを自分で探し回る代わりに、Agentic Chatに以下のように質問してみましょう。\n\n```unset\nこのプロジェクトは初めてです。構造を読んで説明してもらえますか？\n```\n\nAgentic Chatは、以下の方法でプロジェクトの全体像をわかりやすく示してくれます。\n- ディレクトリ構造の探索\n- READMEファイルやドキュメントの読み取り\n- 主要なコンポーネントやアプリケーションの特定\n\n**ステップ2：担当タスクを理解する**\n\n次に、あなたが担当するタスクの内容を把握する必要があります。以下のように質問してみましょう。\n\n```unset\nイシュー1119を担当することになりました。このタスクの内容を説明してもらえますか？特に、リファクタリングが必要な箇所はどこですか？\n```\n\nAgentic Chatは、以下の方法でタスクの説明とリファクタリングの提案を行ってくれます。\n- リモートのGitLabサーバーからイシューの詳細を取得し、分析\n- 関連するプロジェクトファイルの調査\n- 変更が必要な箇所の特定\n\n**ステップ3：ソリューションを実装する**\n\n手動で作業する代わりに、以下のようにリクエストできます。\n\n```unset\nその編集を行ってもらえますか？ステップ1、2、3から始めてください。\n```\n\nAgentic Chatは以下のアクションを実行します。\n- 必要に応じて新しいディレクトリやファイルを作成\n- 複数の場所にまたがってコードを抽出、リファクタリング\n- 変更されたすべてのファイル間で一貫性を維持\n- 行ったすべての変更の要約を報告\n\n**ステップ4：作業の完了を確認する**\n\nマージリクエストを作成したら、最後に作業の完了を確認します。\n\n```unset\nこのマージリクエストはイシュー1119を完全に解決していますか？\n```\n\nAgentic Chatは、マージリクエストと元のイシューの内容を分析し、すべての要件が満たされているかどうかを検証してくれます。\n\n## フィードバックをお待ちしています\n\nGitLab Duo Agentic Chatは現在、VS Codeの実験的機能として、GitLab Duo ProおよびEnterpriseユーザーの皆様にご利用いただけます。前提要件や設定手順については、[セットアップドキュメント](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/)をご確認ください。\n\n実験的な機能であるAgentic Chatにはいくつかの既知の制限があります。これには、複数のAPIコールによる応答時間の遅延、文脈理解による検索ではなくキーワードベースの検索の実行、新しいローカルフォルダやGitLab以外のプロジェクトに対するサポートの制限などが含まれます。現在GitLabは、これらの事項の改善に積極的に取り組んでいます。 **皆さまからのフィードバックは、改善の優先順位を決め、Agentic Chatを一般公開へと導く上で非常に重要です。ぜひ、[こちらのイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/542198)で皆さまの体験を共有してください。**\n\n## 今後の取り組み\n\nGitLabは、Agentic Chatの改善と一般公開へ向けた開発を全力で進めています。主な取り組みとして、応答速度の改善のほか、現在のGitLab Duo Chatで利用可能な各種機能をAgentic Chatでも使えるようにする作業があります。これには、セルフホストモデルのGitLab Duoとの統合や、VS Codeに加えてJetBrainsやVisual Studioをサポートする機能拡張が含まれます。Duo Chatをこの新しいアーキテクチャに切り替えた後は、GitLab Webアプリケーション内のチャットにもAgentic Chatを導入する予定です。 また、GitLabアーティファクトの編集、カスタムモデルコンテキストプロトコル（MCP）サーバーからのコンテキストの取得、ターミナルで実行できるコマンドの提供など、多くの新機能の追加も予定しています。\n\n> まだGitLabをご利用でなくても、自律型の開発支援を今すぐ体験していただけます。[GitLab UltimateとGitLab Duo Enterpriseの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)で、Agentic Chatを今すぐお試しください。AIを活用した開発の未来を一緒に形作りましょう。VS Codeでのセットアップ手順は、[こちら](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-vs-code)からご確認いただけます。\n\n***免責事項：このブログには、今後の製品、機能、および機能性に関する情報が含まれています。本ブログ記事に含まれる情報は、情報提供のみを目的としている点にご留意ください。購入や計画の判断材料として使用することはお控えください。すべてのプロジェクトと同様に、このブログおよびリンク先のページに記載されている項目は、変更または遅延される場合があります。製品、機能、機能性の開発、リリース、およびタイミングに関する決定権は、GitLabに帰属します。***\n\n## 関連リンク\n\n- [GitLab Duo Workflow：自律型AIに対するエンタープライズレベルの可視性と管理](https://about.gitlab.com/ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n- [自律型AIとは？](https://about.gitlab.com/ja-jp/topics/agentic-ai/)\n- [自律型AIに関するガイドとリソース](https://about.gitlab.com/blog/agentic-ai-guides-and-resources/)（英語）\n",[839,743,797,796,766,798],"2025-06-05",{"slug":857,"featured":91,"template":801},"gitlab-duo-chat-gets-agentic-ai-makeover",{"content":859,"config":869},{"title":860,"description":861,"authors":862,"heroImage":864,"date":865,"body":866,"category":683,"tags":867,"updatedDate":868},"自律型AIに関するガイドとリソース","概要と仕組み、DevSecOps環境のレベルアップに役立つ理由、導入時のベストプラクティスなど、自律型AIについて知っておくべきことをすべてご紹介します。",[863],"GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658912/Blog/Hero%20Images/blog-image-template-1800x945__20_.png","2025-05-07","## 自律型AIの定義\n\n自律型AIは、高度な言語モデルや自然言語処理を活用して、自律的に行動を起こすタイプの人工知能です。従来の生成AIツールが常に人間からの指示を必要とするのに対し、自律型AIはリクエストを理解し、意思決定を行い、目標達成のために複数ステップにわたる計画を実行できます。複雑なタスクを管理可能なステップに分解し、課題に直面した際には適応学習を通じてアプローチを柔軟に変えることができます。\n\n[自律型AIの詳細はこちら](https://about.gitlab.com/ja-jp/topics/agentic-ai/)\n\n## 自律型AIに関するインサイト\n\n- [新たに登場し、ソフトウェア開発に変革をもたらす自律型AIのトレンド](https://about.gitlab.com/the-source/ai/emerging-agentic-ai-trends-reshaping-software-development/)：自律型AIによって、個別にコーディングを行う開発プロセスを、セキュリティを維持しながら生産性を向上させるインテリジェントなワークフローへとどのように変えられるかを説明します。\n- [デベロッパーの可能性を大きく解放する自律型AI](https://about.gitlab.com/ja-jp/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)：自律型AIは、コード補完の枠を超え、複雑なタスクに主体的に挑むパートナーへと進化しつつあり、ソフトウェア開発を大きく変革しようとしています。\n- [自律型AI、GitLab Duoセルフホストモデルなど：2025年のAIトレンド](https://about.gitlab.com/ja-jp/the-source/ai/ai-trends-for-2025-agentic-ai-self-hosted-models-and-more/)：オンプレミスでのモデル展開から、インテリジェントで適応性の高いAIエージェントまで、ソフトウェア開発における主要なAIトレンドをご紹介します。\n- [自律型AIによってプラットフォームエンジニアリングの可能性を引き出す方法](https://about.gitlab.com/the-source/ai/how-agentic-ai-unlocks-platform-engineering-potential/)：自律型AIによって複雑なワークフローを自動化し、標準化を大規模に実施することで、どのようにプラットフォームエンジニアリングをレベルアップできるかを説明します。\n\n## 自律型AIを導入するためのベストプラクティス\n\n- [AIエージェント向けに効果的なガードレールを実装する](https://about.gitlab.com/the-source/ai/implementing-effective-guardrails-for-ai-agents/)：コンプライアンス制御やインフラ保護からユーザーアクセス管理まで、DevSecOps環境においてAIエージェント向けに実装すべきセキュリティガードレールをご紹介します。\n\n## GitLabが提供する自律型AI機能\n\n### GitLab Duo with Amazon Q\n\n- [GitLab Duo with Amazon Q（AWS向けに最適化された自律型AI）の一般提供を開始](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)：AIを搭載した包括的なDevSecOpsプラットフォームと業界最高水準のクラウドコンピューティング機能の組み合わせにより、開発サイクルの高速化、自動化の推進、そしてコード品質の向上を可能にします。\n- [DevSecOps + 自律型AI：AWSインスタンスのGitLab Self-Managed Ultimateで利用可能に](https://about.gitlab.com/blog/devsecops-agentic-ai-now-on-gitlab-self-managed-ultimate-on-aws/)：AWSインスタンスのGitLab Self-Managed Ultimateで、DevSecOps向けに強化されたAI搭載エージェントを使い始めましょう。GitLab DuoとAmazon Qの両方のメリットを得られます。\n- [GitLab Duo with Amazon Qパートナーページ](https://about.gitlab.com/ja-jp/partners/technology-partners/aws/)\n\n以下の動画で、GitLab Duo with Amazon Qを実際に使用する様子をご覧いただけます。\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Technical Demo: GitLab Duo with Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n#### ガイド付きツアー\n\n以下の画像をクリックすると、GitLab Duo with Amazon Qのツアーが開始されます。\n\n[![GitLab Duo with Amazon Qのインタラクティブなツアー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673568/Blog/Content%20Images/Screenshot_2025-05-07_at_7.24.45_AM.png)](https://gitlab.navattic.com/duo-with-q)\n\n#### GitLab Duo with Amazon Qのチュートリアル\n\n- [GitLab Duo + Amazon Q：数分でアイデアをもとにコードを作成](https://about.gitlab.com/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes/)：新たに追加されたGitLab Duo with Amazon Qは、イシューの説明文を分析し、完全に動作するコードの自動生成を通じてソリューションを提供することで、開発ワークフローを加速します。\n\n### GitLab Duo Workflow\n\n- [GitLab Duo Workflow](https://about.gitlab.com/ja-jp/gitlab-duo/workflow/)：安全な自律型AIソフトウェア開発の未来\n- [GitLab Duo Workflow：自律型AIに対するエンタープライズレベルの可視性と管理](https://about.gitlab.com/ja-jp/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)：安全で自律的かつコンテキスト認識型のAIエージェントに複雑なタスクを任せることで、デベロッパーは革新的なソフトウェアの迅速なリリースに専念できます。現在、限定公開のベータ版のウェイトリスト受付中です。\n- [GitLab Duo Workflow](https://about.gitlab.com/ja-jp/gitlab-duo/workflow/)\n- [GitLab Duo Workflowのドキュメント](https://docs.gitlab.com/user/duo_workflow/)\n\n以下の動画では、GitLab Duo Workflowに関する詳細をご紹介しています。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/eN2Sd5UNc0g?si=C9HibBJ3QDDHADq2\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### ガイド付きツアー\n\n以下の画像をクリックすると、GitLab Duo Workflowのツアーが開始されます。\n\n[![GitLab Duo Workflowのガイド付きツアー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673569/Blog/Content%20Images/Screenshot_2025-05-07_at_7.29.57_AM.png)](https://gitlab.navattic.com/duo-workflow)\n\n#### GitLab Duo Workflowのチュートリアルとユースケース\n\n- [GitLab Duo Workflowを使ってJavaScriptコードをTypeScriptにリファクタリングする](https://about.gitlab.com/blog/refactoring-javascript-to-typescript-with-gitlab-duo-workflow/)\n\n- [面倒なコーディング作業をGitLab Duo Workflowで自動化](https://about.gitlab.com/blog/automate-tedious-coding-tasks-with-gitlab-duo-workflow/)：自律型AIを導入すると、これまで繰り返しの作業に費やしていた時間が削減されるため、革新的なソリューションの開発や次の重要な製品のリリースに注力できるようになります。\n\n- [GitLab Duo Workflowを活用してアプリケーションの品質保証を向上](https://about.gitlab.com/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance/)：自律型AIを使用してJavaアプリケーションに単体テストを追加する方法をステップ別にご説明します（チュートリアル動画を含む）。\n\n- [GitLab Duo Workflowを使って複雑な課題を解決](https://about.gitlab.com/blog/solving-complex-challenges-with-gitlab-duo-workflow/)：GitLabカスタマーサクセスマネジメントチームが、パッケージレジストリにおけるHelmチャートの制限への対処など、実際の問題解決においてどのように自律型AIを活用しているかをご紹介します。\n\n## GitLab Universityでさらに詳しく学ぶ\n\n- [GitLab Duo入門コース](https://university.gitlab.com/pages/ai)\n- [GitLab Duo Enterpriseを体系的に学ぶコース](https://university.gitlab.com/learning-paths/gitlab-duo-enterprise-learning-path)\n\n## その他のAI関連リソース\n\n- [2024年グローバルDevSecOps調査：DevSecOpsにおけるAI導入のトレンドと進化](https://about.gitlab.com/ja-jp/developer-survey/2024/ai/)\n- [DevOpsにおけるAIの役割](https://about.gitlab.com/ja-jp/topics/devops/the-role-of-ai-in-devops/)\n- [GitLabによるAIと機械学習関連の最新記事](https://about.gitlab.com/ja-jp/blog/categories/ai-ml/)\n- [GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)",[839,796,798],"2025-05-22",{"slug":870,"featured":91,"template":801},"agentic-ai-guides-and-resources",{"category":691,"slug":695,"posts":872},[873],{"content":874,"config":883},{"title":875,"description":876,"authors":877,"heroImage":820,"date":879,"body":880,"category":695,"tags":881,"updatedDate":882},"今すぐ対策を：Docker Hubのレート制限がGitLab CI/CDに与える影響","Docker Hubの新しいプルレート制限がGitLabのパイプラインにどのような影響を与えるか、また、その影響によってCI/CDパイプラインが中断されるのを防ぐ対策を解説します。",[878],"Tim Rizzi","2025-03-24","2025年4月1日より、DockerはDocker Hubに新たな[プルレート制限](https://docs.docker.com/docker-hub/usage/)を導入します。これは、GitLabで稼働しているものを含め、業界全体のCI/CDパイプラインに大きな影響を及ぼす可能性があります。最も大きな変更点は、未認証ユーザーに対して1時間あたり10回までというプル制限が設けられることです。\n\n## 変更点\n\n4月1日から、Dockerは以下のプルレート制限を適用します。\n\n| ユーザータイプ | 1時間あたりのプルレート制限 | パブリックリポジトリ数 | プライベートリポジトリ数 |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business、Team、Pro（認証済） | 無制限（フェアユース） | 無制限 | 無制限 |\n| Personal（認証済） | 100 | 無制限 | 最大1つ |\n| 未認証ユーザー | IPv4アドレスまたはIPv6/64サブネットごとに1時間あたり10回 | 該当なし | 該当なし |\n\n\u003Cp>\u003C/p>\nこの変更が重要な理由は以下のとおりです。\n\n* GitLabの依存プロキシは現在、未認証ユーザーとしてDocker Hubからプルしています。\n* 依存プロキシを使用していないほとんどのCI/CDパイプラインは、未認証ユーザーとしてDocker Hubから直接プルしています。\n* GitLab.comのホステッドランナーでは、複数のユーザーが同じIPアドレスやサブネットを共有することがあり、全体がこの制限の対象になります。\n\n## GitLabユーザーへの影響\n\n**Docker Hubからの直接プルに関する影響**\n\nCI/CDパイプラインがDocker Hubから認証なしで直接イメージをプルしている場合、IPアドレスごとに1時間あたり10回の制限が適用されます。頻繁に実行されるパイプラインや、同じランナーインフラを共有している複数プロジェクトでは、この制限にすぐに達してしまい、パイプラインの失敗が発生する可能性があります。\n\n**GitLab依存プロキシへの影響**\n\nGitLabの依存プロキシ機能は、DockerイメージをGitLab内にキャッシュすることでパイプラインの高速化や外部依存関係の削減を実現します。ただし、現在の実装では未認証ユーザーとしてDocker Hubからプルしているため、これも1時間あたり10回という制限の対象になります。\n\n**ホステッドランナーへの影響**\n\nGitLab.comのホステッドランナーでは、[Google Cloudのプルスルーキャッシュ](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=ja)を使用しています。これにより、よく使われるイメージがミラーされ、レート制限を回避できます。`.gitlab-ci.yml`ファイル内で`image:`または`services:`として定義されたジョブイメージは、レート制限の影響を受けません。\n\n一方で、ランナー環境内でイメージをプルするケースではやや複雑になります。ランナー実行中にイメージをプルする最も一般的なユースケースは、Docker-in-DockerやKanikoを使ってイメージをビルドする場合です。このシナリオでは、`Dockerfile`で指定されたDocker Hubのイメージが直接プルされるため、レート制限の影響を受ける可能性があります。\n\n## GitLabの対応\n\nこの問題を緩和するため、GitLabでは以下の対応を進めています。\n\n* **依存プロキシの認証：** GitLabの[依存プロキシ機能](https://gitlab.com/gitlab-org/gitlab/-/issues/331741)にDocker Hubの認証のサポートを追加しました。これにより、依存プロキシは認証済みユーザーとしてDocker Hubからイメージをプルできるようになり、レート制限が大幅に緩和されます。\n* **ドキュメントの更新：** Docker Hubのパイプライン認証の設定に関する明確なガイダンスを提供するために、[ドキュメント](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials)を更新しました。\n* **内部インフラの整備：** GitLab.comのホステッドランナーへの影響を最小限にするため、内部インフラを整備中です。\n\n## ユーザー側でできる対策\n\n**オプション1：パイプラインでDocker Hub認証を設定する**\n\nDocker Hubから直接プルしているパイプラインでは、認証を設定することでレート制限を1時間あたり100回（または有料プランなら無制限）まで増やせます。\n\nDocker Hubの認証情報をプロジェクトまたはグループのCI/CD変数に追加してください（`.gitlab-ci.yml`には追加しないでください）。`DOCKER_AUTH_CONFIG` CI/CD変数の正しい設定方法については、[Dockerイメージの使用に関するドキュメント](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials)を参照してください。\n\n**オプション2：GitLabのコンテナレジストリを使用する**\n\n頻繁に使用するDockerイメージを[GitLabのコンテナレジストリ](https://docs.gitlab.com/user/packages/container_registry/)にプッシュすることで、CI/CDの実行中にDocker Hubからプルする必要がなくなります。\n\n1. Docker Hubからイメージをプルします\n2. GitLabコンテナレジストリにタグ付けします\n3. GitLabコンテナレジストリにプッシュします\n4. パイプラインをGitLabコンテナレジストリからプルするよう更新します\n\n```\ndocker pull busybox:latest\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n```\n\nそれから、`.gitlab-ci.yml`で以下のように記述します。\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n**オプション3：GitLabの依存プロキシを使用する**\n\nGitLabの依存プロキシ機能を使うことで、Dockerイメージをキャッシュしてプロキシ経由で取得できるため、外部依存関係を減らし、レート制限の問題を軽減できます。\n\n現在の認証オプションは以下のとおりです。\n* GitLab 17.10：[GraphQL API](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api)を使って、依存プロキシ用のDocker Hub認証を設定\n* GitLab 17.11：グループ設定に新しく追加されたUIベースの設定を使用（GitLab.comでは既に利用可能）\n\n認証が正しく設定されると、以下の操作が可能になります。\n\n1. グループの依存プロキシ設定でDocker Hubの認証情報を設定する\n  - GitLab 17.11以降（またはGitLab.com）：グループ設定 > パッケージとレジストリ > 依存プロキシで設定\n  - GitLab 17.10：GraphQL APIで認証を設定\n2. CI/CD設定で依存プロキシURLを使用するよう、パイプラインを更新する\u003Cbr>\n`image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n**オプション4：Docker Hubの有料プランを検討する**\n\nDocker Hubの利用が多い組織の場合は、プル回数が無制限の有料Dockerサブスクリプション（TeamまたはBusiness）へのアップグレードが最も簡単な解決策となる場合があります。\n\n## Docker Hubのレート制限による影響を減らすベストプラクティス\n\nどのオプションを選ぶ場合でも、Docker Hubのレート制限の影響を最小限に抑えるために、以下のベストプラクティスを参考にしてください。\n\n* `latest`タグではなく、特定のバージョンタグを使用して不要なプルを避ける\n* Dockerファイルを統合し、同じベースイメージを複数のプロジェクトで使い回す\n* あまり重要でないパイプラインは、ピーク時間を避けて実行するようスケジュールする\n* キャッシュを有効活用し、同じイメージを繰り返しプルするのを避ける\n\n**注：** Docker Hubの[ドキュメント](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition)によると、プル回数はイメージのサイズやレイヤー数ではなく、manifestを取得した時点で1回とカウントされます。\n\n## スケジュールと今後の流れ\n\n**現在**\n  * Docker Hubからの直接プルに認証を実装します\n* GitLab.comユーザーは以下のいずれかで依存プロキシ認証を設定できます\n    * GraphQL API\n    * グループ設定のUI\n  * Self-ManagedのGitLab 17.10ユーザーはGraphQL APIを使用して依存プロキシ認証を設定できます\n\n**2025年4月1日**\n  * Docker Hubのレート制限が始まります\n\n**2025年4月17日**\n  * Self-Managedインスタンス向けの依存プロキシ認証機能をUIに追加したGitLab 17.11がリリースされます\n\nパイプラインの予期せぬ失敗を回避するために、可能な限り速やかに対応することをおすすめします。多くのユーザーにとっては、Docker Hub認証を使用して依存プロキシを設定することが最も効率的な長期的解決策となります。\n\n> ご質問がある場合や、実装に関してサポートが必要な場合は、[こちらのイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/526605)をご覧ください。GitLabのチームによる対応が確認できます。\n\n\u003Cbr>\u003Cbr>\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[109,743,796],"2025-03-31",{"slug":884,"featured":91,"template":801},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":703,"slug":707,"posts":886},[887,903,915],{"content":888,"config":901},{"title":889,"description":890,"authors":891,"heroImage":893,"date":894,"body":895,"category":707,"tags":896,"updatedDate":900},"共同開発プログラム：ユーザーとともに築くGitLab","Thales社、Scania社、Kitware社などの組織がどのようにGitLabのエンジニアと連携し、コミュニティ全体に利益をもたらす重要な機能の開発にコントリビュートしているかをご紹介します。",[892],"Fatima Sarah Khalid","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","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",[897,898,899],"contributors","open source","customers","2025-03-10",{"slug":902,"featured":91,"template":801},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":904,"config":913},{"title":905,"description":906,"authors":907,"heroImage":909,"date":910,"body":911,"category":707,"tags":912},"くら寿司が語るソフトウェア開発の「生産性向上」と「セキュリティ・ガバナンス」の重要性【イベントレポート】","2024年10月に開催された「Gartner IT Symposium/Xpo」の当社セッションにおいて、くら寿司様より事例を紹介いただきましたので、その模様をお伝えします。",[908],"GitLab Japan Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665029/Blog/Hero%20Images/_________DX__________________GitLab____________________.jpg","2024-12-05","2024年10月、GitLabはGartner IT Symposium/Xpoに出展しました。このイベントにおいて、GitLabユーザーの[くら寿司株式会社](https://www.kurasushi.co.jp/) 執行役員 DX本部長 中林 章氏に弊社セッションに登壇いただきましたので、本ブログではその模様を中心にレポートします。\n\n![ガートナーITシンポジウム会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/___________________.jpg)\n*会場の様子*\n\n中林氏の講演は、当社のJapan Country Manager 小澤 正治をモデレーターとする対談形式で行われました。開催2週間前に満員御礼となり、当日も満員の来場者が詰めかけた人気セッションでしたが、講演の冒頭で小澤は、「今日のこの時間がMLBのワールドシリーズにぶつかると考えていませんでした。昨夜から、本当に人が来てくれるのかどうか心配していて、皆さんに来ていただけて安心しました」と会場の笑いを誘います。\n\n![くら寿司株式会社 DX本部 執行役員 本部長 中林 章氏 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/_________DX__________________3.jpg)\n*くら寿司株式会社 執行役員 DX本部長 中林 章氏*\n\n中林氏は、「GitLabとの出会いは去年のこのイベントです。私たちが必要としていたソリューションがGitLabだということがすっと腑に落ちて、その場で採用を決めました」と話し、ブースのパネル展示を見てGitLabが合うと感じたと明かします。小澤は「私の講演を聞いてくれたのではなかったのですか」と合いの手を入れましたが、中林氏は「いえ、ブースのパネル展示で」とつれない返事。会場は再び笑いに包まれました。こうして、セッションはやわらかな雰囲気で和気あいあいと進みます。\n\n![GitLab合同会社カントリーマネージャー小澤正治](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/GitLab____________________.jpg)\n*GitLab合同会社 カントリーマネージャー 小澤 正治*\n\n## GitLabに登録したビジネスバックログは、そのままプロダクトバックログになる\n\nくら寿司は、「安心・美味しい・安い」というコンセプトに加え、「ビッくらポン!」を代表とした「楽しい」を追求しています。「抗菌寿司カバー 鮮度くん」など独自の品質管理などでも消費者の信頼を獲得し、成長してきました。また、先進的な業務の標準化、効率化を進め、業界に先駆けて機械化／デジタル化を進めている企業としても知られています。\n\n![くら寿司様サービス展開の歴史](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/_______________.jpg)\n*図：くら寿司のサービス展開の歴史*\n\n中林氏は、そんな同社の歴史について、機械化に取り組んだ時代を経て、デジタル化の時代が来たと説明します。デジタル化には、タッチパネル注文など店舗内のものとスマホ予約システムなど店舗外のものがあり、現在は機械を含めた店舗内のプロセスと店舗内／店舗外のデジタル、および本社のビジネスプロセスをつなぐさまざまな取り組みを実施できる段階に来ています。そして、デジタルテクノロジーとデータを活用した企業理念の実践を実現しようとしているのです。\n\n「GitLabを使って進めているくら寿司流DXで大切にしていることは、独自性です。お客様DX、事業基盤DX、従業員DXと3つのDXを進めていますが、くら寿司ならではの競争力のあるDXを推進することが求められています」（中林氏）\n\nなぜ「ならでは」である必要があるのでしょう。それは、くら寿司の経営スピードが極めて速いサイクルで進むためです。経営会議は2週間に1度あり、その場で意思決定がなされ、プロジェクトが実行に移されます。たとえば異業種とのコラボレーションなどのイベントも、このスピード感で決まり、実行します。現場のアイデアや困りごとはすぐに吸い上げ、優先順位をつけて即座に対応していくことになります。\n\nこれはデジタルにおいても同様で、中林氏は2週間に1度、新たな複数のプロジェクトを開発現場に持ち帰ることになります。中林氏は、「このサイクルに合わせるためには、DevSecOpsが不可欠になります。経営会議の決定をビジネスバックログとしてGitLabに登録すると、それがプロダクトバックログになるイメージです」と話します。\n\nGitLabによってDevSecOpsを根付かせることで、ビジネスの意思決定をプロダクトの計画、設計、開発、リリース、運用というプロセスに一貫した流れに落とし込めます。これにより、セキュリティリスクとビジネスリスクをどちらも低く抑えることができます。GitLab導入後1年を経た今、くら寿司の社内には、「GitLabに合わせて開発する」という文化が根付きました。\n\nすべての開発プロジェクトはGitLabの中で完結するため、開発と運用にかかわるすべての経緯はGitLabを見て、過去のログをたどればわかります。中林氏が経営会議から持ち帰ったビジネスバックログまで遡ることができるのです。セキュリティ面では、シフトレフトを加速させています。成果物によって求めるセキュリティレベルは異なるため、ビジネスモデルやスプリントごとに最適なセキュリティを決定し、それを開発プロセスに組み込むことで、求めるセキュリティレベルを担保できるようにしています。\n\n## セキュリティはプロアクティブな対応に近づけたい\n\n![GitLab導入前の課題と導入後の効果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/GitLab______________.jpg)\n*図：くら寿司のGitLab導入前の課題と導入後の効果*\n\nセキュリティについては、脅威側が日々進化するという問題があり、どれほどの対策をしても終わりはありません。くら寿司の場合、開発プロジェクトのほぼすべてが自社開発になっているため、ソフトウェア・サプライチェーンのリスクは大きな課題です。地産地消の推進に伴い、国内でも地域／店舗ごとにソフトウェアやデータの連携先、デジタルタッチポイントなどは異なります。さらに、海外店舗もあるため、プロセス／データの連携先に対するガバナンスも必要になってきます。\n\nこれらの課題に向き合うために、くら寿司では、「お客様に迷惑をかけないこと」を第一義として整理しています。「セキュリティに対してリアクティブな対応で良しとしようという風潮はあります。しかし、本来プロアクティブな対応を取れるとより良いわけで、少しでもそこに近づける必要はあるでしょう。GitLabのおかげで、リスク要素がよく見えるようになりました。どのサーバで問題が起きているか、という視点でなく、どのスプリントがどの程度のリスクをはらんでいるのか、という視点を得られたのは大きな成果でした」（中林氏）。\n\n![くら寿司株式会社 DX本部 執行役員 本部長 中林 章氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/_________DX_________________.jpg)\n*左より、くら寿司株式会社 執行役員 DX本部長 中林 章氏、GitLab合同会社カントリーマネージャー小澤正治*\n\n海外拠点では、国内システムと共通化すべき部分とそうでない部分を切り分けて運用することにしました。本社の高速な意思決定サイクルを海外にも展開しながら、現地が自ら考えてその地域に最適なプロダクトを開発し、その上で適切なセキュリティを担保できる開発を推進しています。いわば、ITも地産地消なのです。\n\n## お客様に満足し尽くしてもらえるようなAIを提供してみたい\n\n喫緊の課題に、将来のAI活用があります。中林氏は、狭義のITを「回転レーンの寿司を監視するような、モノの判別に使えるようなAI」と定義し、そうではない広義のAIを活用していきたいと語ります。\n\n![くら寿司株式会社 DX本部 執行役員 本部長 中林 章氏 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/_________DX__________________2.jpg)\n*くら寿司株式会社 DX本部 執行役員 本部長 中林 章氏*\n\n中林氏は、「AIはお客様に継続的な価値を提供し続けるために使いたいです。たとえば、お客様が“今はマグロじゃなくてスイーツを食べたい気分”なら、それを察知してレコメンドしてくれるようなAIが居てくれるとうれしくないですか？お客様とずっとコミュニケーションを取ることで、お客様に満足し尽くしてもらえるようなAIを提供してみたいと考えています」と話してくれました。\n\n![Gartner ITシンポジウムにおけるGitLabのブース](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687748/Blog/Content%20Images/GitLab_____.jpg)\n*GitLabのブース*\n\n### 関連記事\n[DevOpsで実現。ソフトウェア開発のセキュリティ・ガバナンス【イベントレポート】](https://about.gitlab.com/ja-jp/blog/event-report-gartner-it-infra-2024/)",[899],{"slug":914,"featured":91,"template":801},"event-report-gartner-it-symposium",{"content":916,"config":927},{"title":917,"description":918,"authors":919,"heroImage":921,"date":922,"body":923,"category":707,"tags":924,"updatedDate":926},"GitLabでCIプラットフォームを変革したIndeed社の戦略","世界最大の求人サイトであるIndeed社は、数千のプロジェクトをGitLab CIに移行することで、生産性向上とコスト削減を実現しました。1日あたりのパイプライン実行数が79%増加するなど、得られた主なメリットをご紹介します。",[920],"Carl Myers","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","2024-08-27","***編集者からのお知らせ：GitLabでは、当社ブログの執筆者として、カスタマーコミュニティのメンバーをお招きすることがあります。今回のブログ記事では、Indeed社のCIプラットフォームマネージャーを務めるCarl Myers氏に、GitLabに関する経験を共有していただきました。*** \n\nIndeedは、「We help people get jobs.（人々の仕事さがしを支援する）」というミッションを掲げています。Indeedは、[月間3億5,000万人以上のユニークビジターを持つ、世界最大の求人サイト](https://jp.indeed.com/about)（外部サイト）です。\n\nIndeedのエンジニアリングプラットフォームチームは「We help people to help people get jobs.（人々の仕事さがしを支援する人を支援する）」というモットーを掲げており、これは会社のミッションとは少し異なるものです。20年近くにわたり、常に求職者を第一に考えるデータドリブンのエンジニアリング文化を醸成してきました。この文化を推進する中で、当社はこのアプローチを実現し、日々エンジニアが求職者によい結果を届けられるようにするためのツールの構築に責任を持って取り組んでいます。\n\nわずか11人から成るIndeedのCIプラットフォームチームは、GitLabの継続的インテグレーション（CI）を導入したことで、社内の数千人のユーザーを効果的にサポートできるようになりました。このほかにも、IndeedはGitLab CIへの移行により次のメリットを得ました。\n- 1日あたりのパイプライン実行数が79%増加\n- CIハードウェアコストを10～20%削減\n- サポート負担の軽減\n\n## CIプラットフォームの進化：Jenkinsから拡張性に優れたソリューションへ\n\n多くの大手テクノロジー企業と同様に、当社は会社の成長に伴い、当時利用可能なオープンソースや業界標準のソリューションを用いてCIプラットフォームを段階的に構築してきました。2007年、Indeedのエンジニアが20人にも満たなかった頃、チームではHudson（Jenkinsの前身）を使用していました。\n\n20年近くにわたる成長を経た現在、Indeedには数千人のエンジニアが在籍しています。新しい技術が登場するたびに、段階的に改善に取り組み、2011年頃にはJenkinsに移行しました。また、[AWS EC2](https://aws.amazon.com/ec2/)を使用して、ほとんどのワークロードを動的なクラウドワーカーノードに移行することにも成功しました。しかし、Kubernetes時代に突入すると、システムのアーキテクチャが限界に達しました。\n\nJenkinsのアーキテクチャは、クラウドを前提に設計されていません。Jenkinsは、パイプラインの重要な部分を実行し、特定のタスクをワーカーノードに割り当てる役割を持つ『コントローラー』ノードを使用して動作します（ワーカーノードはある程度水平にスケーリングが可能）。しかし、コントローラーのスケーリングは手動で調整する必要があります。\n\nジョブが多すぎて1つのコントローラーに収まらない場合、ジョブを複数のコントローラーに手動で分割する必要があります。CloudBees社は、こうしたボトルネックを軽減するための対策として、CloudBees Jenkins Operations Centerをはじめとする、複数のコントローラーを一元管理するソリューションを提案しています。しかし、各コントローラーは依然として脆弱な単一障害点となり、Kubernetes環境での運用には困難があります。ノードのロールアウトやハードウェアの障害などのアクティビティはダウンタイムを引き起こします。\n\nJenkins自体に内在する技術的な制約に加えて、自社のCIプラットフォームにも、社内プロセスが原因で発生した問題がいくつかありました。たとえば、各リポジトリ内のコードからジョブを生成するためにGroovy Jenkins DSLを使用していたため、各プロジェクトがコピー＆ペーストされた独自のジョブパイプラインを持つことになり、その結果、数百ものバージョンが生成され、メンテナンスや更新が困難になりました。Indeedのエンジニアリング文化は柔軟性を重視し、チームが別々のリポジトリで作業することを許容していますが、その柔軟性により、チームは定期的にメンテナンスを行わなければならず、多大な時間を費やさせる負担要因となっていました。\n\nこうした技術的負債を認識した当社は、「[Golden Pathパターン](https://tag-app-delivery.cncf.io/whitepapers/platforms/)（英語）」に目を向けました。このパターンは、柔軟性を保ちながら、アップデートを簡素化し、プロジェクト間で運用の一貫性を促進するための標準的な手順を提供するものです。\n\nIndeedのCIプラットフォームチームは11人ほどのエンジニアで構成されており、決して規模は大きくないものの、サポートリクエストへの対応、アップグレードやメンテナンスの実施、そしてグローバル企業としての常時サポート体制の確保を通じて、数千人のユーザーサポートにあたっています。\n\n当社のチームは、GitLabインスタンスだけでなく、アーティファクトサーバーや共有ビルドコード、さらに複数のカスタムコンポーネントを含むCIプラットフォーム全体をサポートしているため、業務量は非常に多岐にわたります。そのため、既存のリソースを最大限に活用し、課題に対処する計画が必要でした。\n\n## GitLab CIへの移行\n\n主要なステークホルダーとの慎重な設計レビューを経て、当社は全社的にJenkinsからGitLab CIへ移行することを決定しました。GitLab CIを選んだ主な理由は次のとおりです。\n\n- すでにGitLabをソースコード管理に使用していたため。\n- GitLabは、当社がCIに求める機能をすべて備えた包括的なソリューションであるため。\n- GitLab CIの設計は拡張性に優れ、クラウドにも対応しているため。\n- GitLab CIは、テンプレートを拡張して新たなテンプレートを作成できるという点が、当社の「Golden Path」戦略と合致していたため。\n- GitLabがオープンソースソフトウェアであり、さらにGitLabチームが当社の修正提案に常に協力的であったことから、柔軟性と安心感を得られたため。\n\nGitLab CIプラットフォームの一般提供を正式に発表した時点で、すでに全ビルドの23%がGitLab CI上で行われていました。これは、個々のユーザーの自主的な取り組みや早期導入者のおかげです。\n\nしかし、移行の課題は「ロングテール」にありました。Jenkinsには多くのカスタムビルドが存在するため、自動移行ツールはほとんどのチームに適用できませんでした。新しいシステムの利点の多くは、旧システムを完全に停止（0%）にするまで実現しません。そうして初めてハードウェアを停止し、CloudBeesのライセンス費用を削減できるようになるのです。\n\n## 機能の同等性とゼロからの再出発の利点\n\nIndeedでは多様な技術をサポートしていますが、最も一般的な言語はJava、Python、JavaScriptです。これらの言語は、ライブラリの構築、デプロイ可能なサービス（ウェブサービスやアプリケーションなど）、およびcronジョブ（データレイク内のデータセットを構築するような、定期的に実行されるプロセス）を作成するために使用されます。これらの言語は、Javaライブラリ、Pythonのcronジョブ、JavaScriptのウェブアプリケーションといったプロジェクトタイプのマトリックスを形成しており、Jenkinsではそれぞれに対して事前定義されたスケルトンがありました。そのため、これらすべてのプロジェクトタイプに対応する「Golden Path」テンプレートをGitLab CIでも作成する必要がありました。\n\nほとんどのユーザーは推奨されたパスをそのまま使用できましたが、カスタマイズが必要な場合でも「Golden Path」は有用な出発点になりました。必要な部分だけを調整しながら、将来的には一元管理されたテンプレートが更新されるたびに、その利点を享受することができます。\n\n当社はすぐに、カスタマイズが必要なユーザーでさえ「Golden Path」の採用に前向きであり、少なくとも試用を望んでいることがわかりました。もし以前のカスタマイズが必要であれば、後から追加することができたからです。これは驚くべき結果でした。大幅なカスタマイズに投資してきたチームはそれを手放すことに抵抗があるだろうと思っていましたが、大多数のチームはもはやそれを気にしなくなっていたのです。これにより、多くのプロジェクトを非常に迅速に移行することができました。プロジェクトに「Golden Path」（インクルードを含む6行ほどの小さなファイル）を追加するだけで、あとは各チームがそれを活用して進めることができました。\n\n## インナーソースによる救済\n\nCIプラットフォームチームは、「外部からのコントリビュートを優先する」というポリシーを採用し、社員全体の参加を促進しました。このアプローチは「インナーソース」と呼ばれることもあります。私たちは、外部からのコントリビュート（自分たちのチーム以外からのコントリビュート）を促進するために、テストやドキュメントを作成しました。カスタマイズを望むチームは、そのカスタマイズを、Golden Pathに組み込んで、機能フラグを使用して共有できるようになりました。これにより、カスタマイズを行ったチームは自分たちの作業を他のチームと共有できるようになっただけでなく、そのカスタマイズがCIプラットフォームチームのコードベースの一部になったため、将来的にそのカスタマイズが壊されないことを保証できるようになりました。\n\nこの取り組みには、特定のチームが必要な機能を求めて待機することなく、自分たちでその開発に取り組めるようになったという利点もありました。たとえば、「その機能は数週間後に実装する予定ですが、もし早めに必要であれば、ぜひコントリビュートしてください」と伝えることができます。結果的に、同等性に必要な多くのコア機能がこのようなアプローチで開発され、チームのリソースでは実現できないほど迅速かつ質の高い形で提供されました。このモデルがなければ、移行は成功しなかったでしょう。\n\n## 予定より早く、予算内で達成\n\nチームのCloudBeesライセンスは2024年4月1日に期限切れになりました。これに伴い、完全移行を達成するための挑戦的な目標を設定しました。当時、ビルド全体の80%（全プロジェクトの60%）でCIにJenkinsが使用されていたことを考えると、この目標は特に野心的だったと言えます。つまり、2,000以上の[Jenkinsfiles](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/)を新たに書き直すか、Golden Pathのテンプレートに置き換える必要があったのです。\n\nこの目標を達成するために、チームはドキュメントやサンプルコードを提供し、可能な限り機能を実装したほか、ユーザーが機能を追加できるように支援しました。\n\nまた、定期的なオフィスアワーを設け、誰でも質問をしたり、移行の支援を求めたりできるようにしました。さらに、移行に関連するサポートの質問を、一部を除いて他のどの質問よりも優先しました。CIプラットフォームはGitLab CIのエキスパートとなり、その専門知識をチーム内および組織全体で共有しました。\n\n自動移行はほとんどのプロジェクトでは実現できませんでしたが、カスタマイズがまれな比較的小規模なプロジェクトには有効であることがわかりました。チームはSourcegraphの一括変更キャンペーンを作成し、数百のプロジェクトを移行するためにマージリクエストを送信しました。そして、ユーザーにその承認を促しました。\n\nユーザーからの成功事例を広く共有し、ユーザーがGolden Pathに新しい機能を追加するたびに、「GitLab CIに移行するとこれらの機能が無料で利用できる」と宣伝しました。これらの機能には、ビルトインのセキュリティやコンプライアンススキャン、CIビルドのSlack通知、他の内部システムとのインテグレーションなどがあります。\n\nさらに、積極的な「screamテスト」キャンペーンを実施しました。しばらく実行されていない、または成功していないJenkinsジョブを自動的に無効にし、必要であれば再度有効にできるとユーザーに通知しました。これは、手間をかけずに実際に必要なジョブを特定できる効果的なアプローチでした。前回のCI移行（JenkinsからJenkinsへの移行）以降、一度も実行されていない数千のジョブがあり、これらをほぼすべて安全に無視できることがわかりました。\n\n2024年1月には、例外が明示的に要求されない限り、すべてのJenkinsコントローラーが読み取り専用（ビルド不可）になると発表しました。コントローラーに関する所有情報が大幅に改善され、組織の構造に合致していたため、ジョブよりもコントローラーに焦点を当てることが合理的でした。コントローラーのリストはジョブのリストよりもはるかに管理しやすいものでした。\n\n例外を認めるために、ユーザーにはスプレッドシートでコントローラーを見つけ、その横に連絡先情報を入力してもらうよう依頼しました。これにより、フォローアップできる利害関係者の最新リストを確実に取得できるだけでなく、ユーザーからも絶対に必要なジョブを明確に知らせてもらうことができました。ピーク時には約400ものコントローラーがありましたが、1月には220に減少し、そのうち例外を必要とするのは54のコントローラーだけでした（そのうちいくつかはチームで所有し、テストやカナリアのために使用していました）。\n\n![Indeed - Jenkinsコントローラー（個数）の推移グラフ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099357/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099357392.png)\n\n私たちは、約50チームの管理可能なリストをチーム内で分担し、各チームの移行の進捗状況を聞き取りし始めました。1月、2月中に、そして一部のチームは2月28日までに私たちの支援なしで移行を完了させる予定であり、他のチームはその時点までのプロジェクト廃止を計画していることが判明しました。そして、ごく少数のチームが期限内に完了できるか非常に心配していました。\n\n私たちはこの少数のチームと協力し、きめ細やかな個別対応サービスを提供しました。私たちには移行を代行する上での専門知識が不足しているものの、そのチームの特定分野の専門家と協力できることを説明しました。一部のプロジェクトでは、私たちがコードを書き、そのチームがレビューを行い、他のプロジェクトではそのチームがコードを書き、私たちがレビューを行いました。最終的に、すべての努力が実を結び、8か月前に宣言した日に、Jenkinsを無事に廃止することができました。\n\n## 成果：CI効率とユーザー満足度の向上\n\nJenkins CIプラットフォームのピーク時には、1日あたり14,000以上のパイプラインが実行され、数千のプロジェクトをサポートしていました。現在、GitLab CIプラットフォームは、1日あたり40,000以上のパイプラインを処理し、通常は25,000以上のパイプラインが日常的に稼働しています。各パイプラインのジョブごとの増分コストはJenkinsと同程度ですが、コントローラーを実行するためのハードウェアのオーバーヘッドがなくなりました。これらのコントローラーは、単一障害点であり、スケールの制限要因でもあったため、プラットフォームを人工的にセグメント化せざるを得ませんでした。正確な比較は難しいものの、このオーバーヘッドがなくなったことで、CIハードウェアコストは10～20%削減できたと考えています。さらに、GitLab CIはクラウド上で自動的にスケールし、複数の可用性ゾーンで動作する耐障害性を備えているほか、テンプレート言語には優れた公開ドキュメントがあるため、サポートの負担も軽減されています。\n\n特筆すべきもうひとつの利点としては、現在、Golden Pathの採用率が70%を超えていることです。これにより、私たちが改善策をロールアウトすれば、Indeedの5,000以上のプロジェクトは、特別な操作をせずにすぐにそのメリットを享受できるようになることがわかりました。この結果、一部のジョブをよりコスト効率の高いARM64インスタンスに移行したり、ユーザーのビルドイメージをより簡単に更新したりできるようになりました。また、他のコスト削減の機会をより適切に管理することも可能になりました。最も重要なことは、ユーザーが新しいプラットフォームに満足していることです。\n\n__著者について__：\n*Carl Myers氏はカリフォルニア州サクラメント在住で、Indeed社のCIプラットフォームチームのマネージャーを務めています。Carl氏は、約20年にわたるキャリアを通じて、大小さまざまな企業で、エンジニアのニーズを満たし、その能力を引き出すための社内ツールやデベロッパー向けプラットフォームの構築に尽力してきました。*\n\n**謝辞**：\n*この移行プロジェクトは、Tron Nedelea氏、Eddie Huang氏、Vivek Nynaru氏、Carlos Gonzalez氏、Lane Van Elderen氏、そしてCIプラットフォームチームの他のメンバーの尽力なしには実現できませんでした。チームはまた、プロジェクト全体を通じて、合意やリソースの確保、そして社内全体の調整に尽力していただいたDeepak Bitragunta氏とIrina Tyree氏のリーダーシップに、特に感謝しております。最後に、コード、フィードバック、バグレポートに貢献し、プロジェクトの移行を支援してくださったIndeed社の皆様に感謝申し上げます。*\n\n**この記事は、Indeedエンジニアリングブログに掲載された[「How Indeed Replaced Its CI Platform with GitLab CI」](https://engineering.indeedblog.com/blog/2024/08/indeed-gitlab-ci-migration/)の編集版です。**",[899,109,925,796],"user stories","2025-01-10",{"slug":928,"featured":91,"template":801},"how-indeed-transformed-its-ci-platform-with-gitlab",{"category":715,"slug":719,"posts":930},[931,942,954],{"content":932,"config":940},{"title":933,"description":934,"authors":935,"heroImage":937,"date":836,"body":938,"category":719,"tags":939},"統合されたDevSecOpsプラットフォームへの移行を組織が進めている理由","各種ツールの統合、セキュリティの強化、AIの活用を通じてソフトウェア開発の効率化を実現する、GitLabの包括的な統合DevSecOpsプラットフォームについてご紹介します。",[936],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","今日の最新のソフトウェア開発を取り巻く環境では、多くの組織がクラウドに移行し、DevSecOpsプロセスの導入を進めています。しかしながら、このような移行プロセスには、最新の開発方法に合わせて設計されていないツールやレガシーシステムの増加という大きな課題が伴います。そのため、組織はタスク管理、CI/CD、セキュリティ、モニタリングなど、さまざまな用途のツール向けのインテグレーションを作成して、これらのシステムをDevSecOpsに適応させる必要があります。結果として、複雑な運用プロセス、高い保守コスト、開発チームと運用チーム間のコラボレーションへの悪影響といった新たな問題が生じます。さらに、デベロッパーは、計画から本番環境へのデプロイまでの1つの開発フローを完了するために、常に複数のツール間を切り替える必要があり、不満を抱えることになります。\n\n![DevSecOpsプロセスに複数のツールを統合する難しさと、その際に生じる運用コスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>DevSecOpsプロセスに複数のツールを統合するのがどれほど難しいか\u003C/i>\u003C/center> \n\n\u003Cbr>\u003C/br>\n\n幸いなことに、これには解決策があります。ソフトウェア開発に対する統一されたアプローチを提供する包括的なDevSecOpsプラットフォームです。\n\nこのようなプラットフォームは、クラウドベースおよびDevSecOps環境で運用を行う組織向けに構築されており、コード管理、CI/CDプロセス、タスク管理、セキュリティからAI主導の自動化まで、すべてのソフトウェア開発ステージを単一プラットフォームに統合します。すべてのソフトウェア開発ワークフローを統一されたインターフェイスに一元化できるため、開発チームと運用チームの作業やコミュニケーションが効率化され、運用面の複雑さや混乱を最小限に抑えられます。\n\nさらに、デベロッパーエクスペリエンスも大幅に向上します。エンジニアは最新の開発ニーズに特化して設計された製品で作業することになるため、満足度が高まります。\n\n以降のセクションでは、プロジェクトやタスクの管理、セキュリティやコンプライアンスの確保、AI搭載の開発ツールの導入など、チームがよく直面する課題を解決するためにGitLabがどのように役立つかをご紹介します。GitLabなら、単一の統合プラットフォーム内ですべてを行えます。\n\n## 統合されたアジャイルプロジェクト管理\n\nGitLabでは、CI/CDなどソフトウェア開発ライフサイクルの全ステージにわたって、プロジェクトとタスクの管理が完全に統合されている包括的なソリューションが提供されているため、リアルタイムで開発の進捗状況を追跡できます。イシューとエピックは自動化プロセスに直接紐づけられるため、計画から本番環境へのデプロイまでのシームレスなフローが実現されます。このアプローチにより、チーム間の透明性が高まり、遅延の発生が減り、すべてのステークホルダーがリアルタイムで開発状況を明確に把握できるようになります。\n\n![イシューとエピックは自動化プロセスに直接紐づけられるため、計画から本番環境へのデプロイまでのシームレスなフローが実現されます。](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## ビルトインのセキュリティ\nGitLabでは、包括的なセキュリティ機能を統合すること（セキュリティを最優先）を非常に重視しています。GitLabプラットフォームには、以下を含むさまざまな自動セキュリティスキャナーが組み込まれています。\n\n- [依存関係スキャン](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n- [静的アプリケーションセキュリティテスト（SAST）](https://docs.gitlab.com/user/application_security/sast/)\n- [動的アプリケーションセキュリティテスト（DAST）](https://docs.gitlab.com/user/application_security/dast/)\n- [シークレット検出](https://docs.gitlab.com/user/application_security/secret_detection/)\n- [コンテナスキャン](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![さまざまな開発ステージでCI/CDプロセスに統合されているセキュリティスキャン機能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>さまざまな開発ステージでCI/CDプロセスに統合されているセキュリティスキャン機能\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nこれらのセキュリティチェックは、CI/CDパイプラインを含むソフトウェア開発ライフサイクルの全ステージに直接組み込まれており、開発サイクルの早い段階で潜在的なセキュリティ上の問題についてデベロッパーに即座にフィードバックを提供します。\n\n## コンプライアンスと規制要件\n\n効率性や優れたユーザーエクスペリエンスの確保に加え、多くの組織（特に金融機関や大企業など規制の厳しい業界の組織）は、厳格なセキュリティおよびコンプライアンス基準にプロセスが準拠していることを確認する必要があります。こういった組織では、特定のコードブランチ（mainブランチや保護ブランチなど）でCI/CDパイプラインが実行されるたびにセキュリティスキャナーが実行されるようにしたり、mainブランチにコードをマージする前に特定の承認を必須としたりするなど、さまざまなプロジェクトにポリシーを適用する機能が必要です。\n\nGitLabでは、[コンプライアンスフレームワーク](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)という機能があるため、このようなポリシーを簡単に適用できます。構造化されたポリシーを定義し、特定のプロジェクトに対して適用できる機能です。これにより、シームレスで効率的なデベロッパーワークフローを維持しつつ、規制やセキュリティ要件へのコンプライアンスを自動的に実現できます。\n\n## AI搭載の開発支援\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、すべての開発ステージにわたってAI主導のアシスタンスを提供します。そのため、いちいち外部ツールに切り替える必要性がなくなります。すべてのリクエストは、プロジェクトとコードベース全体のコンテキストを把握したAI搭載機能によって処理されるため、より効率的かつスマートに作業を進められます。\n\n例を挙げると、AIは以下のようなタスクを実行できます。\n- タスクの説明の自動生成\n- イシューディスカッションのスマートな要約によるデベロッパーの貴重な時間の節約\n- 高度なコードレビュー機能\n- コードの改善および最適化の提案\n- 自動テスト生成\n- セキュリティの脆弱性の検出と修正\n- 失敗したCIパイプラインの根本原因分析によるトラブルシューティング\n- プライバシーとデータセキュリティ\n\n公共機関や金融機関を始めとする規制の厳しい組織のニーズを理解しているGitLabは、セキュアな環境でAIモデルを実行できるよう独自のソリューションを提供しています。GitLab Duoセルフホストモデルを採用すると、各組織はデータプライバシー、セキュリティ、および大規模言語モデル（[LLM](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/)）の独自インフラへのデプロイを完全に制御しつつ、以下を実現できます。\n- データプライバシーの保護\n- 規制要件へのコンプライアンス\n- 最高レベルのセキュリティ\n- 外部ネットワークの利用やリスクなしでAIのメリットを活用\n\n## まとめ\n\n組織がプロセスの効率化、セキュリティの強化、イノベーションの加速を実現するためには、包括的なDevSecOpsプラットフォームが必要です。ビルトインのセキュリティ機能とAI搭載の自動化を備え、開発、セキュリティ、運用に不可欠なすべてのツールが統合された単一アプリケーションであるGitLabなら、まさにそれらを実現できます。\n\n実際にGitLabがどのように動作するかをご覧になりたい方は、ぜひ以下のインタラクティブなデモをチェックしてみてください。\n\n- [GitLab Duoが搭載されたGitLab PremiumとUltimate](https://gitlab.navattic.com/gitlab-premium-with-duo) – AI搭載の開発支援を体験しましょう\n\n- [CI/CDパイプラインへのセキュリティ実装](https://gitlab.navattic.com/gitlab-scans) – 統合されたセキュリティスキャンによってソフトウェアをどのように保護できるかをご覧ください\n\n- [コンプライアンスフレームワーク](https://gitlab.navattic.com/compliance) – GitLabを使用して全プロジェクトにポリシーを適用してガバナンスを向上させる方法をご紹介します\n\n> GitLab 18オンラインリリースイベントに参加して、自律型AIが担う役割など、DevSecOpsプラットフォームの未来について学びましょう。[今すぐご登録ください！](https://about.gitlab.com/ja-jp/eighteen/)",[715,796,766],{"slug":941,"featured":6,"template":801},"why-are-organizations-moving-to-a-unified-devsecops-platform",{"content":943,"config":952},{"title":944,"description":945,"authors":946,"heroImage":947,"date":948,"body":949,"category":719,"tags":950},"AI活用の鍵はGitLabの一貫したコンテクスト 【Developers Summit 2025 イベントレポート】","2025年2月、GitLabは「Developers Summit 2025」に出展しました。本イベントにてシニアソリューションアーキテクト 佐々木直晴が講演をおこないましたので、本記事にてその模様をレポートします。",[908],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663625/Blog/Hero%20Images/3508_resized.jpg","2025-03-13","本講演のテーマは、ソフトウェア開発の現場が抱えているAI活用の課題とその解決策です。シニアソリューションアーキテクト[佐々木直晴](https://gitlab.com/naosasaki)は「ソフトウェア開発の現場で、AI時代の新しいサイロが発生している」と考えています。本講演でその解決策として紹介しているのが、GitLabのAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」です。\n\n## コードがどういう背景のもとで書かれたかといった情報までAIに与えるべき\n\n### 組織全体でコンテクストを共有することができているGitLabだからこそ持てたコンセプト\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_DSC1989_resized.jpg)\n*Developers Summit 2025での講演の様子*\n\n本講演における最初のブロックにて佐々木は、コードが書かれた背景に関する情報までAIに与えることが大切なのでは、と語りかけました。\n\nソフトウェア開発の現場でAIを使う際は、断片的なエラーコードのみ渡してその理由を探らせるなどします。しかしAIの可能性を引き出すには、そのコードがどういう背景のもとで書かれ、なぜそう決まったかという情報まで与えるべきです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_TOH3572_resized.jpg)\n*GitLab合同会社 シニアソリューションアーキテクト 佐々木直晴*\n\n佐々木はGitLabのAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」は、こういったコンセプトを持っていると話しました。そうして、このコンセプトは「我々の会社だからもてたもの」と言います。\n\nGitLabはご存知のとおり、オフィスを持たずオールリモートの働き方を実践している企業です。オールリモートを実現するには、ドキュメントによるコミュニケーションが重要になります。\n\n経緯や議論をドキュメントとして残し、「なぜそう決まったか」も含め組織全体でコンテクストを共有する必要があるのです。オールリモートではメンバー間の誤解が生まれないように、記録に残るコミュニケーション技術が必要になります。\n\nそのうえで佐々木は「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)のコンセプトは、コンテクストを組織全体で共有できているGitLabだからこそ持てたものと思っている」と話しました。\n\n## AI時代の新しいサイロが発生した\n### 現在のソフトウェア開発において、AIの活用レベルは3段階に分類される\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit.jpg)\n次のブロックで佐々木は、現在のソフトウェア開発現場におけるAI活用の課題について説明しました。\n\nAIをソフトウェア開発に利用しているという会社は、2023年には64％だったところ、2024年には78％に上がっている* 状況です。今年の調査であれば、100％に近い数字になっていると想定されます。\n\nこのようにソフトウェア開発においてAIはデフォルトになっているものの、現場によって「段階がありレベル感が違う」と佐々木は話しました。活用レベルは大きく分けて3つにわけられ、各レベルで別々の課題が生じているのです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__1_.jpg)\n\nまず、ソースコードの生成にAIを活用するのが、活用レベル1です。「ここはかなりコモディティ化している」と佐々木は話しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__2_.jpg)\n\nソフトウェア開発の様々な局面で、AIを活用するのが活用レベル2です。たとえば以下のような利用があげられます。\n\n- 議論の内容をAIに要約させる\n- 会議の文字起こしをさせる\n- トラブルが起きたらAIにコードを渡して原因を解析させる\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__3_.jpg)\n活用レベル3は、局面に応じて優れたLLMを採用して使い分けている状態です。たとえばチケット管理はこのLLMを利用し、ソースコードの推奨はこのLLMにさせるといった使い分けをします。\n\n### AIの活用レベルごとに異なる課題が生じている\n\n佐々木は「我々はマーケットを見て、それぞれの活用レベルで課題があると思っている」と指摘しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__4_.jpg)\n「活用レベル1：ソースコードの生成にAIを活用」での課題は、AIが局所的な利用にとどまってしまっていることだと佐々木は指摘しました。\n\nソフトウェア開発のなかでも、ソースコードを記述している時間は21％に過ぎない* という調査結果があります。仕事場所がオフィスでも自宅でも、誰にも邪魔されず集中してコードを書ける日はなかなかありません。打ち合わせが入ったりメンバーのタスク管理をしたり、トラブルで呼び出されたりします。\n\nソースコードの記述にAIを使うこと自体はよいことです。しかしAI活用がソースコードの記述にとどまっているということは、AI活用が局所的な効率化に限定されているとも言えます。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__5_.jpg)\n「活用レベル2：ソフトウェア開発の様々な局面でAIを活用」は、AIをいろいろなシーンで使えていて一見素晴らしいように見えます。しかし、「いろいろなところに様々な機能のAIがあり過ぎて統一したいという意見が多い」と佐々木は指摘しました。\n\nソフトウェア開発にAIを使用する全世界の組織のうち、約74％は「ツールチェーンを統合したい」と答えたという調査結果があります。AIのライセンス費用や使い勝手の違いなどがあり、1つにまとめたいという課題が生じているのです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__12_.jpg)\n\n「活用レベル3：各局面に応じて優れたLLMを採用」は、一見良い状態にみえます。チケット管理やコーディングなど、それぞれのシーンで優れたAIを利用できているためです。\n\nしかし「それぞれのシーンで共有されたAIとのコンテクストが、コーディングのときに失われている」と佐々木は指摘しました。AIがそれぞれのツールに特化して閉じており、経緯や議論が個別のツールに取り残されてしまっているのです。\n\nAI間でのコンテクスト共有が不十分なので、コーディング段階でAIがいろいろな推奨をしてくれるものの、その内容には違和感が生じます。佐々木は「これはAI時代の新たなサイロだと我々は定義している」と話しました。\n\n## GitLabだからこそ提案できる、AI利用の課題に対する解決策 \n### GitLabにはソフトウェア開発用のプラットフォームとして必要な機能が一通りそろっている\n\n前項で紹介したAI利用の課題に対して、GitLabが提案するのがGitLabにおけるAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」です。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は「オールリモートでコンテクストを共有しながら会社運営をする我々だからこそできる提案」と、佐々木は強調しています。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__6_.jpg)\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)の紹介をする前に、「そもそもGitLabとは何か」について佐々木が説明しました。\n\nGitLabではソフトウェア開発において、以下のような機能が必要と考えています。\n\nチケット管理をする機能、チケット管理のなかで詳細な議論ができる機能\nソースコードリポジトリ機能\nコミットしたら、自動的に何かをしてくれるCIの仕組み\nセキュリティスキャンなど\n\n「これら機能をばらばらに提供するのでなく、ひとつのプラットフォームとして提供するのがGitLab製品のコンセプト」と佐々木は説明しました。GitLabはソフトウェア開発に必要な機能を集約したDevSecOpsプラットフォームです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__7_.jpg)\n\nこうした製品コンセプトが評価され、[2024  Gartner®  Magic  Quadrant™for  DevOps Platformsにおいて、GitLabが高く（画像の一番右上）に評価された](https://about.gitlab.com/ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops/)ことを、佐々木は紹介しました。\n\n### 今までのAIはスポットで来てもらう助っ人、GitLab Duoは「勝手を知っているチームの一員」として働く\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__8_.jpg)\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__9_.jpg)\n\n前項で紹介したように、ソフトウェア開発にはいろいろな機能が必要になります。GitLabのAI「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」は、それら機能においてAIが同じコンテクストをもってサポートすると佐々木は解説しました。\n\nイシュー割り当てや議論要約、ソースコード生成、テストコードやテストケースの生成、また実装から詳細な説明用の資料を生成するなどの工程を、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は一貫してサポートします。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)はインターネットだけでなく、自社内のAIのゲートウェイを向けることにより自社のネットワークから出ずにAIを使えるのも強いと佐々木は強調しました。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使えば、以下のような\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__10_.jpg)\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__11_.jpg)\nDevSecOpsのループ全ての局面にAIの力をまぶすことができます。\n\n- 計画・議論\n- ロードマップ・スケジュール構築\n- イシューの作成・アサイン\n- 開発・検証\n- デプロイ\n- パフォーマンスのモニタリングとカイゼン\n\n佐々木は、「たとえて言うなら、今までのAIはスポットでちょっと来てもらう助っ人のようなものだった」と指摘しました。スポットの助っ人は、タスクの背景などは分かりません。限定的な情報のなかで、サポートをしなければならないのです。\n\nたとえば断片的なエラーだけ渡され「これは何か」と聞かれても、AIは与えられた情報のなかで提案を返すしかありません。佐々木は「AIは本当ならもっとできるはず、というのが我々の思いだ」と強調しました。\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_TOH3594_resized.jpg)\n一方GitLab Duoは、「勝手の知っているチームの一員として働く」と佐々木は指摘しています。GitLabを使えば、ソフトウェア開発におけるものづくりの全ての作業を同じプラットフォーム内で実行することが可能です。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、これらGitLabにおける活動を多く把握しています。たとえば、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、ソースコードの内容を変更した背景や流れを理解しているわけです。そのため、そのソースコードをプッシュしてCIで失敗したら、GitLab Duoはより深く原因の分析をおこなえます。\n\nまたソフトウェア運用中に、深刻な脆弱性が見つかったとしましょう。このとき[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は「脆弱性に対応するには、リポジトリのこのファイルとこのファイルをこう直したらいいですよ」と提案してくれるのです。\n\nこのように局面をまたいだAIの使い方は、単一のデータストアがないとできないと佐々木は強調しました。リポジトリ・チケット管理・CI・セキュリティスキャンなどソフトウェア開発に必要な機能を、GitLabは全て有しています。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、GitLabのなかでこれら機能と同一プラットフォームに存在し、その全ての活動を把握しているわけです。それゆえに、スポットの助っ人でなくチームの一員として活躍することができます。\n\n最後に佐々木は、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使ったデモを紹介しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_DSC2007_resized.jpg)\n本デモでは、CIが失敗した理由を[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)に調べさせています。そうするとGitLab Duoは、エラーログだけからは推察することが難しい関数や引数の型を使った修正例を提案しました。本デモでGitLab Duoは、デプロイが失敗した原因を、ソースコードの変更内容まで鑑みて分析しているのです。\n\nChatGPTにエラーログだけを渡して解析させるように、AIをスポットの助っ人として使うやり方であれば、コンテクストは共有されません。そのため、この修正例は出ないのではないかと佐々木は強調しました。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)はトラブル発生時に、断片的なログから推奨を返すのでなく、過去の計画まで遡りなぜ失敗が起こったかというところまで助けてくれます。本講演の最後で佐々木は、開発者がより創造的な作業に集中できる環境を作りたいという思いでGitLabを提供させていただいていると語りました。\n\n＊参考元：[GitLab「2024 グローバルDevSecOpsレポート」](https://about.gitlab.com/ja-jp/developer-survey/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_developers-summit-2025-spring-event-report) \n\n## 会場で配布したお土産について\n\n\u003Cimg src=\"https://images.ctfassets.net/r9o86ar0p03f/71MiD2VIstBGoKEgMN0duQ/f6c103c2112ebc484e9d315ebddf6071/8622ADC4-CE48-4E04-8993-5569C4BCF269_1_105_c.jpeg\">\n会場にて本講演のアンケートに答えて下さった参加者の方には、バレンタインデーのチョコとナノブロックをお渡ししました。このナノブロックは、GitLabのロゴがモチーフとなっています。かわいらしいこのロゴの形は、狸をイメージしていることはご存知でしたでしょうか？\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/image5_resized.jpg)\n",[280,951,715,796,839],"inside GitLab",{"slug":953,"featured":91,"template":801},"developers-summit-2025-spring-event-report",{"content":955,"config":963},{"title":956,"description":957,"authors":958,"heroImage":959,"date":960,"body":961,"category":719,"tags":962},"DevOpsで実現。ソフトウェア開発のセキュリティ・ガバナンス【イベントレポート】","2024年12月に開催された「ガートナー ITインフラストラクチャ、オペレーション＆クラウド戦略コンファレンス」の当社セッションにおいて、ソリューションアーキテクト本部長 大井 雄介が講演しました。その模様をお伝えします。",[908],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664977/Blog/Hero%20Images/Gartner_cover_image.jpg","2025-01-15","2024年12月、GitLabは「ガートナー ITインフラストラクチャ、オペレーション＆クラウド戦略コンファレンス」に出展しました。このイベントにおいて、ソリューションアーキテクト本部長 大井 雄介が講演いたしましたので、本ブログではその模様をレポートします。\n\n## GitLabはインフラチームにも大きな価値を提供できる\n\n講演の主要トピックは、[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)です。冒頭で大井は、「今回のイベントにはインフラ担当の方が多く参加されていて、このセッションにも多くお越しいただいています。GitLabはアプリ開発担当の方々には良く知られていますが、インフラ担当の皆様にはまだ浸透していないかもしれません。しかし、今日話すのは、インフラ担当の方にこそ、ぜひ聞いていただきたい内容になっています」と会場に語りかけます。\n\nインフラの運用・管理に[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を採用するケースは増加しています。SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）やGitOps（DevOpsをインフラ自動化に適用した運用モデル）を実現するために、何らかのツールが必要だという認識が高まったためです。実際に、ソフトウェア開発のプラットフォームであるGitLabをインフラ側にも適用することで、SSoT（Single Source of Truth；信頼できる唯一の情報源）として機能させられることは大きな価値をもたらします。\n\n![Gartner IT Infra講演の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/FAC306DD-2334-463A-963E-E63AEC8F35EC_1_105_c.jpg)\n*会場の様子*\n\n具体的には、インフラの運用・管理を行うツール群をまたいだSSoTとしてGitLabを利用すると、容易に全体像を把握できます。イシューを積極的に使っていれば、各ツールについて過去の採用から導入、改変の経緯についての詳細をつかむことも可能です。[IaC（Infrastructure as Code：インフラ定義ファイル）](https://about.gitlab.com/ja-jp/topics/gitops/infrastructure-as-code/)を管理しておけば、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインのバージョンが管理できるため、万一のことがあってもデプロイ手順に合わせてロールバックできるようになります。機器／OS＆ミドルウェアの各種設定ファイルの管理や配布も容易です。\n\nこのように、GitLabは[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を実現するプラットフォームでありながら、同時にSREやGitOpsなどインフラの運用・管理に活用できるさまざまな機能を備えた統合プラットフォームと言えるのです。\n\n「GitLabは、インフラチームにも大きな価値を提供できるソリューションであると自負しています」（大井）\n\n## 独立した専任のプラットフォームチームが必要\n\n![Gartner IT Infra講演の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/80582937-4BAD-4DC5-A51A-4B680FB15609_1_105_c.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 本部長 大井 雄介*\n\nエンジニアはソフトウェア開発にあたり、計画、開発、リリースのサイクルを高速に回すことを目指します。コンピュータの登場から今日まで、経営者はエンジニアにそれを求めてきました。\n\nしかし、状況は昔と今では大きく変わりました。かつてのエンジニアはコードを書く能力が第一で、スピーディに高効率なコードを生み出すことが求められていました。そして、美しいコードそのものが、エンジニアの誇りでした。しかしながら、現在はコンテナや[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api/)、セキュリティなど、コード以外のさまざまな知見が求められています。\n\n現在のエンジニアにとって、コードそのものは理解できれば問題ありません。すでにAIがある程度のコードを生成できますから、それを目的に合わせて修正することで業務効率が向上する状況が生まれているためです。最も重要なのは、コードの“周辺領域”を知ることで迅速に成果を出す能力。中でも、多数のクラウドツールの中からそれぞれの特徴を理解し、比較・検討して最適解を使用することは重要なスキルです。ただ、この状況はエンジニアの認知負荷が大幅に高まるという課題を生みました。実際に、エンジニアの認知負荷はかつての10倍になったとも言われています。\n\n必要な知見は多岐にわたるため、一人でカバーできる範囲は限られます。そのために、プロセスは細分化されてきました。必然的に、チーム内でもサイロ化が進むことになります。この状況におけるひとつの最適化のための解が、「プラットフォーム部分を共通化して切り出し、1つのチームに任せる」というものです。全体最適を果たすことを目指した取り組みで、そのために多くの組織で「プラットフォームチーム」が生まれることになりました。\n\n![Gartner プラットフォームチームが担う役割](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/Gartner___________________.jpg)\n\nプラットフォームチームのやるべきことを、上図に示しました。同チームは、各プロジェクトと連携しながら、自動化、セキュリティ、[API](https://about.gitlab.com/ja-jp/blog/what-is-an-api/)、およびインフラについて一元的に管理することになります。これは、インフラを構築／保守する専任のプラットフォームチームが必要になるというガートナーの定義する[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)の考え方に一致します。\n\nプラットフォームチームは、開発チームが生産性高く作業を進めることをサポートします。開発チームの行動を制限しすぎず、一方でリスクの高いツールの使用を許さず、万一の際にはすでにリリースされたアプリケーションであってもすべて検査し、迅速に対処して被害を最小限に抑えます。\n\nプラットフォームチームが正しい方向で[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を推進できれば、開発チームが行うインフラ関連作業はほぼゼロになり、開発スピードの向上、開発サイクルの短期化を期待できます。一貫したコンプライアンス／ガバナンスも実現します。最終成果物次第で許容リスク範囲を増減させるなど柔軟な運用を可能にすることで、生産性とリスクのバランスを取りながら、全体最適を図ることができます。\n\n## セキュリティでは防災も意識してほしい\n\n![GitLab Tanuki](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/8622ADC4-CE48-4E04-8993-5569C4BCF269_1_105_c.jpg)\n*ブースで配布された景品*\n\nさらに、セキュリティ面においても[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)が大きく寄与することが期待されています。経営幹部の多くは、セキュリティと聞くとポリシー策定などの企画部分や、ウイルススキャンなどの運用部分だけに注目しがちです。そのため、多くの企業では企画、運用段階のセキュリティには対応が進んでいます。一方、エンジニアは開発段階にやるべきことがあることを知っています。\n\nたとえば、コードそのものがセキュアであるかどうかを検査しなければなりません。Software Bill of Materials（以下、SBOM：ソフトウェア構成の部品表）を実装し、OSSのソフトウェア・サプライチェーンを可視化し、リスクに備える必要があります。定期検査のプロセスは効率化したいですし、脆弱性発見時の即時検査を行える体制を整えておく必要もあります。外注先の管理も必須で、開発チームとプラットフォームチームにかかわるすべての人に共通するSSoTを備えておくことができれば理想です。\n\n大井は、「企画・運用におけるセキュリティを重視すると、主に“減災”を目指すことになります。確かに減災は必要で、SIEMやSOARは有益なソリューションなのですが、 できれば“防災”も目指したいところです。セキュリティ用語を使えば、サイバー・レジリエンスとともに、サイバー・ハイジーンを追求したいのです」と話します。\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)では、ソフトウェア開発プロセスの早期からセキュリティに取り組むことをシフトレフトと呼び、それを重視しています。つまり、開発段階から防災を意識することになり、DevSecOpsの先進企業はこぞってシフトレフトしています。GitLabでは、数多くのセキュリティスキャン機能を用意し、これらを開発プラットフォームに組み込んでいます。同時に、品質を安定させるガイドラインやポリシーをプロセスに適用できるため、規定どおりに各メンバーが仕事を進めながら防災を目指したソフトウェア開発を徹底することができます。\n\nもちろん、減災を無視してよいわけではありません。開発時にリスクゼロだった依存先OSSでも、リリース後に脆弱性が発見されるケースはあります。こうした際には、SBOMを使って完璧に可視化しておき、リスク別に見分けられるビューも提供しています。\n\n![Gartner GitLab Ultimateのセキュリティスキャン機能](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687732/Blog/Content%20Images/Gartner_GitLab_Ultimate_____________.jpg)\n\n優れたプラットフォームチームが[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を推進し、GitLabを活用すれば、さらなる価値を得ることもできます。GitLabを開発チームに提供することで得られる多くのメリットもあります。採用したエンジニアは、GitLabの使い方さえ覚えれば、すぐに仕事に慣れて戦力化します。AIを使った生産性の高い開発も可能で、すでにコードの提案機能に対応する言語は25以上になりました。自社が所有するAIモデルとの接続も可能で、社内ポリシーでインターネット経由でのAIサービス利用が制限されているケースにも対応できます。\n\n大井は、「GitLabを全社の共通プラットフォームとして活用することで、インフラチームと開発チームが一体となって仕事を進め、[プラットフォームエンジニアリング](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)の浸透を加速することができます」と話して講演を締めくくりました。\n\n![GitLab 書籍](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687733/Blog/Content%20Images/9CCF584A-1244-4EFC-A6C7-5C39C36B68D5_1_105_c.jpg)\n*書籍*\n\n### 関連記事\n[くら寿司が語るソフトウェア開発の「生産性向上」と「セキュリティ・ガバナンス」の重要性【イベントレポート】](https://about.gitlab.com/ja-jp/blog/event-report-gartner-it-symposium/)",[715,777,280],{"slug":964,"featured":91,"template":801},"event-report-gartner-it-infra-2024",{"category":727,"slug":731,"posts":966},[967,982,994],{"content":968,"config":980},{"title":969,"description":970,"authors":971,"date":973,"body":974,"category":731,"heroImage":975,"tags":976},"Dockerとは：超入門編","Dockerのコンテナ技術は広く普及しつつあります。Dockerとは何なのか。Dockerの使い方は？Dockerプラットフォームとその技術の基礎を学びましょう。\n",[972],"GitLab Team","2025-06-18","Dockerコンテナ技術は、2013年にオープンソースの「Dockerエンジン」として公開され、翌年2014年には本番環境向けの商用版が発表されました。その後約10年の間に、Dockerは使いやすさと高い利便性から、IT業界で瞬く間に広く普及してきました。これからもその人気は高まっていくでしょう。\n\nしかしその一方で、いまだに「Dockerとは何ですか」という声もよく耳にします。この記事では、Docker環境の導入を検討中で、Dockerにまだ不慣れなデベロッパーやプログラマーの皆様を対象に、Dockerの基本を解説します。Dockerに触れたことのない初心者向けの「Docker超入門編」です。\n\n## 目次\n\n1. Dockerとは：超入門編\n2. Dockerの目的\n\n   * Dockerとは\n   * Dockerでできること\n   * Dockerイメージとは\n   * Dockerコンテナとは\n   * Dockerfileとは\n   * Dockerはなぜ重要なのか\n3. Dockerの主な機能\n\n   * Dockerの特徴\n   * Docker Composeとは\n4. アプリケーションのデプロイにおけるDockerのメリット\n\n   * 開発環境と本番環境のシームレス化\n   * 起動の軽量化・処理速度の高速化\n   * バージョン管理のしやすさ\n   * 優れたスケーラビリティ\n5. Dockerのデメリット\n\n   * ひとつのOSを使わなければならない\n   * 大規模開発時のオーバーヘッド\n   * 技能習得に時間がかかる\n   * セキュリティに脆弱性が生じることもある\n   * コンテナ間での連携が難しい\n6. GitLabはDockerが抱える課題をどのように解決するのか\n7. GitLabのDevSecOpsにおけるDockerの役割\n8. まとめ\n9. FAQ（よくある質問）\n\n## Dockerの目的\n\nはじめに、Dockerとはどういったもので、何ができて、どうして便利なのか、なぜ重要なのか、Dockerの目的に着目しながらその概念をまとめていきます。\n\n### Dockerとは\n\nDockerは、Linuxのコンテナ技術を用いた軽量なソフトウェアコンテナプラットフォームです。アプリケーションの開発、出荷、実行を簡易化するために設計されました。Dockerを使えば、すべての依存関係と一緒にアプリケーションをパッケージ化できるため、依存関係を一つひとつ手動でインストールする必要がなくなり、一貫性のあるコード実行が可能になります。\n\nDockerを使えばアプリケーションの実行環境を標準化でき、環境の違いによる問題を減らすことで開発から本番環境へのデプロイ時間を大幅に短縮できます。\n\nLinuxには以前からコンテナ仮想化という技術がありました。この技術を使うと、プログラムを開発・実行環境から隔離することにより、複数のプログラムを素早く実行できます。ただし、この従来型の仮想化技術は、仮想環境を構築するためにホストとなるOS（オペレーティングシステム）に依存する必要がありました。Dockerはこのコンテナ仮想化技術をOSに関係なく簡単に扱えるようにしたソフトウェアといえます。\n\nDockerの基本概念はイメージとコンテナです。Dockerイメージは、読み取り専用のテンプレートであり、コンテナを作成するための指示が記述されています。たとえば、コンテナで実行するアプリケーションとその依存関係、環境変数、ファイルシステムなどがこれに含まれます。\n\n### Dockerでできること\n\nDockerを使うと、1台のマシン中に複数のコンテナ（仮想環境）をビルドできるため、いくつかの開発環境に対応することができます。つまり、1台のサーバー上で複数のアプリケーションを効率的に動かすことができるのです。アプリケーションの開発環境をDockerで構築すれば、たとえば開発環境（Windows）で動いていたアプリケーションがLinux上で起動しない、といった問題は発生しません。Dockerで構築した環境は、他のデベロッパーとクラウド上で簡単に共有できるため、開発作業がスムーズに進められます。\n\n### Dockerイメージとは\n\nDockerイメージは、アプリケーションを実行するのに必要なソースコードと必要な依存関係をパッケージ化したものです。Dockerコンテナを実行する際には、このDockerイメージが必要です。\n\nDockerイメージは、コンテナイメージを構成する複数のファイルに、`Dockerfile` を合わせてビルドします。つまり、Dockerイメージは、手作業で書くのではなく、コマンドを使って作成します。\n\nそのため、Dockerイメージは単一のファイルではなく、Dockerコンテナの実行に必要なパッケージ（ファイルやメタデータの集合体）であることを理解することが重要です。\n\n### Dockerコンテナとは\n\nLinuxのコンテナは、アプリケーションを内包し、必要なライブラリや依存関係、ファイルが含まれています。\n\n一方、Dockerコンテナは、Dockerイメージの実行可能なインスタンスです。これはDockerイメージから生成され、アプリケーションを実行するためのランタイム環境です。ただし、ハイパーバイザーを使用する従来の仮想化とは違い、DockerのコンテナはホストOS（オペレーティングシステム）のカーネルで実行されます。Dockerイメージ内には、個別のOSはありません。\n\nDockerイメージは環境のスナップショットであり、コンテナはソフトウェアを実行する環境といえます。\n\n### Dockerfileとは\n\n`Dockerfile`は文字情報を主体とするファイルで、ファイルの拡張子はありません。`Dockerfile`には、アプリケーションの構築から実行までのプロセスに必要なコマンドが記述されています。どのファイルをどこから取得して、どんな処理を行ない、Dockerイメージに含めるのかなどを記述します。\n\n`Dockerfile`は、Dockerイメージを作成するためのテキストファイルです。コンテナイメージをビルドする場合も、コンテナのビルド手順を`Dockerfile`で定義する必要があります。この`Dockerfile`には、命令のスクリプトが含まれており、Dockerはコンテナイメージをビルドする際にこのスクリプトを使用します。\n\n### Dockerはなぜ重要なのか\n\nDockerは、コンテナに関する既存のコンピューティングの概念、とりわけLinuxの「cgroups」や「namespaces」、「overlayfs」などの技術を活用しています。これは、アプリケーションの依存関係をサーバーやネットワークなどのインフラストラクチャから隔離したいという、デベロッパーやシステムオペレーターのニーズに応えるものでした。\n\nDockerを使うと、1台のサーバー上でさまざまなアプリケーションを簡単に仮想化・実行できるようになります。さらには、ローカルマシンに依存しない開発環境を実現でき（開発環境の統一）、本番環境に近い環境でのシミュレーションが可能になり、アプリケーションの依存関係も管理できます。加えて、ビルド、テスト、デプロイまでの各プロセスを一貫して行なうことができます。\n\n## Dockerの主な機能\n\nDockerは、Linuxのコンテナ技術を使用しています。Dockerコンテナはよく仮想マシンと比較されます。\n\n仮想マシンでは、ホストマシン上でハイパーバイザーを利用してゲストOSを動かし、さらにその上でミドルウェアやライブラリ、さらにその上にアプリなどを実行します。\n\nそれに対し、コンテナはホストマシンのカーネルを利用し、プロセスやユーザーなどを隔離します。そのため、非常に軽量で、まるで別のマシンが動いているかのように動作します。その結果、アプリなどを高速に起動、停止することが可能です。\n\nDockerは、次の4つの構成要素から成り立っています。\n\n* **Dockerイメージ：** アプリケーション実行に必要なソースコード、アプリと依存関係のパッケージ\n* **Dockerコンテナ：** アプリケーションを実行するランタイム環境\n* **Docker Hub：** クラウド上のレジストリサービス。アプリケーションやサービスコンテナのビルドと配信を行なう\n* **Dockerfile：** Dockerイメージを作成するために実行するコマンドライン命令を含むテキストファイル\n\n### Dockerの特徴\n\nDockerには、次のような特徴があります。\n\n* **軽量かつ高速：** 1つのOSで複数のコンテナを管理でき、仮想マシンより軽量で高速に立ち上げることが可能。\n* **環境の一貫性が保持でき再現性がアップ：** Dockerコンテナは異なるプラットフォームでも一貫して動作するため、ローカル、クラウド、ハイブリッド環境への移行が簡単にできる。\n  移植性が高い －クラウドシステムとの親和性が高く、主要なクラウドプロバイダーはDockerコンテナの実行をサポートしている。\n* **サンドボックスの提供：** セキュリティ対策やソフトウェア開発において、隔離された仮想環境でプログラムを実行・検証できる。このため、ホストマシンの環境を守ることができる。\n* **IaC（インフラストラクチャのコード化）を使用して、インフラをコード化：** Dockerfileによりミドルウェアのインストールや環境設定をコード化して管理できる。\n\n### Docker Composeとは\n\nDocker Composeは、複数のDockerコンテナを一元管理する、 Dockerアプリケーションのためのツールです。YAMLファイルを使用してアプリケーションのサービスを設定します。単一のコマンドで複数のサービスをまとめて生成したり、起動・停止したりすることができます。\n\nDocker Composeのコマンド例は次のとおりです。\n\n* **`docker-compose up`：** サービス用のコンテナを構築、作成、起動、アタッチします。リンクされているサービスがまだ起動していない場合は、それらも起動します。\n* **`docker-compose ps`：** Docker Composeで管理されている稼働中のサービスを一覧表示します。\n* **`docker-compose build`：** Docker Composeファイルで定義されているサービスをビルド（構築）します。\n\n## アプリケーションのデプロイにおけるDockerのメリット\n\nアプリケーションのデプロイにおけるDockerのメリットは次のとおりです。\n\n### 開発環境と本番環境のシームレス化\n\nコンテナ技術の利用を開発環境と本番環境で統一することで、環境の違いにより起こる問題を減らすことができます。その結果、デベロッパーと運用チームとの連携がスムーズに行われ、チーム間で発生していた問題も最小限に抑えられます。\n\n### 起動の軽量化・処理速度の高速化\n\nDockerのコンテナ技術は従来の仮想環境より軽く、アプリを瞬時に起動できます。これは、CPUやメモリなどのコンピュートリソースを必要最低限しか使用しないためです。起動速度が上がることで、開発にも集中できます。\n\n### バージョン管理のしやすさ\n\nDockerでは、GitLabなどのソースコードのバージョン管理ツールを使用できるため、バージョン管理の可視化が進むだけでなく、ロールバックやアップデートも簡単に行なえるようになります。\n\n### 優れたスケーラビリティ\n\nコンテナは軽量で拡張性に優れています。必要に応じて簡単に増減できます。これにより、アプリケーションの拡張やスケーリングを迅速に行なえるため、変わりゆく状況にも柔軟に対応できます。\n\n## Dockerのデメリット\n\nDockerにはさまざまなメリットがありますが、いくつかデメリットも存在します。以下にデメリットを挙げます。\n\n### 1つのOSを使わなければならない\n\nDockerは1つのOS上で複数のコンテナを作成します。これにより起動速度や処理速度の面でメリットがありますが、同時にデメリットになることもあります。たとえば、異なるOS環境で検証をしたい場合には、別のマシンや仮想マシンを準備する必要が生じます。\n\n### 大規模開発時のオーバーヘッド\n\nDocker自体は軽量ですが、大規模システムに拡張する場合には、Dockerの管理に伴う負荷が発生します。Dockerは1台のサーバーで多数のコンテナを実行できますが、その反面、管理やオーケストレーションが必要になり、その処理のためにオーバーヘッドが生じる場合があります。Dockerだけですべての管理を行なうのが困難になることもあります。\n\n### 技能習得に時間がかかる\n\nDockerは他の仮想マシンと異なる手法で仮想環境を構築します。つまり、デベロッパーは新しいコンセプトをすべてゼロから習得しなければならず、それには時間がかかります。Dockerの動作原理をきちんと理解せずに使用すると、あとでトラブルや問題が発生することもあります。Dockerについてしっかりと学習してから運用に取り組むようにしましょう。\n\n### セキュリティに脆弱性が生じることもある\n\nDockerはコンテナ型アーキテクチャです。1台のマシン上で複数のコンテナが動作するため、このことに起因する脆弱性には注意が必要です。たとえば、複数のコンテナがホストOSのリソースやカーネルを共有しているため、一つのコンテナに脆弱性があった場合、全体にその影響が及ぶ可能性があります。\n\n### コンテナ間での連携が難しい\n\n複数のコンテナ間での連携を検討している場合、各種設定が難しいために、運用時に問題が発生することがあります。たとえば、アプリとデータベースを別のコンテナで作成し、一緒に運用したい場合には、同一ホスト内で通信設定をしなければなりません。ポートやソケットを開放する場合にはセキュリティ面でリスクが生じます。それを避けるために設定を複雑にしてしまうと、今度は運用面で問題が起きる恐れがあります。コンテナを連携させる際は、設計段階から十分に検討することが重要です。\n\n## GitLabはDockerが抱える課題をどのように解決するのか\n\nDockerコンテナ内にGitLabをインストールすることができます。[GitLab](https://about.gitlab.com/ja-jp/platform/)は、Git「分散型バージョン管理システム」を主体としたDevSecOpsプラットフォームです。ソフトウェア開発ライフサイクル全体に対応する単一のプラットフォームで、GItLabを活用することで高品質なソフトウェアの迅速なデリバリーを実現できます。\n\nDockerコンテナ内にGitLabをインストールすると、GitLabインスタンスにアクセスできるようになります。Dockerコンテナへの[GitLab Dockerイメージのインストールは公式にサポート](https://about.gitlab.com/ja-jp/install/)されています。\n\nDockerが抱えるいくつかの問題のうち、特にセキュリティについては、GitLabのDevSecOps（開発、セキュリティ、運用）を活用して対処することができます。GitLabのDevSecOpsでは、[シフトレフト](https://about.gitlab.com/ja-jp/topics/ci-cd/shift-left-devops/)を重視しており、セキュリティ対策を開発サイクルの早い段階に組み込むことにより、コンテナイメージの持つセキュリティの問題の早期発見と対応を図っています。継続的インテグレーションによってこのシフトレフトのコンセプトを実践することで、セキュリティ対応にかかっていたコストを削減できます。\n\nDevSecOpsにおいて重要なCI/CDを実現するためには、自動化が欠かせません。GitLabではパイプラインがCI/CDの命令をまとめています。そして、その指示に従いプロセスの自動化を実現するときの基盤になっているのが[GitLab Runner](https://docs.gitlab.com/runner/)（英語）です。GitLab Runnerはセキュリティのシフトレフトを実現する上で重要な役割を果たしています。\n\nGitLab Runnerはセキュリティスキャンやテストを指定したタイミングで自動で実行してくれます。また、レポート作成ジョブを実行して、ダッシュボードに最新情報を表示することも可能です。\n\n## GitLabのDevSecOpsにおけるDockerの役割\n\nGitLabを活用したDevSecOpsインテグレーションにおいても、Dockerは非常に大切な役割を担っています。\n\n### CI/CDジョブのコンテナ化\n\nGitLab CI/CDでは、CI/CDパイプラインでDockerコンテナを使用することで、次のようなことが可能になります。\n\n* **一貫性：** CI/CDジョブはコンテナ内で実行されるため、依存関係や環境の違いによるエラーが防げます。\n* **スケーラビリティ：** コンテナは軽量かつ迅速に起動でき、大規模なパイプラインでも効率的に実行できます。\n* **環境の柔軟性：** ジョブごとに異なるDockerイメージを指定できるため、必要な環境を簡単に準備できます。\n\nGitLab RunnerのDockerイメージは、UbuntuまたはAlpine Linuxをベースにしています。Dockerイメージは標準の`gitlab-runner`コマンドを内包しており、ホストに直接GitLab Runnerをインストールしたかのように動作します。\n\n### セキュリティスキャンの自動化\n\nセキュリティはDevSecOpsでの重要な要素であり、Dockerはこれをサポートします。\n\n* **コンテナイメージのセキュリティスキャン：** GitLabには、CI/CDパイプラインでDockerイメージをスキャンする機能があります。このスキャンにより脆弱性がチェックされ、イメージ内の依存関係やコードの安全性を評価できます。\n* **コンテナ脆弱性スキャンの自動化：** GitLabにはTrivyやAquaなどのセキュリティツールを統合できます。DockerイメージのOSやアプリケーションが最新であるか、既知の脆弱性がないかをチェックします。\n\n### IaC（インフラストラクチャのコード化）と環境管理\n\n* **再現性：** DockerをGitLabのCI/CDジョブ内で使用することで、開発環境と本番環境の整合性を保つことできます。\n* **ステージングやテスト環境を即時に構築：** Docker ComposeやKubernetesと連携することで、特定のブランチやマージリクエストごとに分離された環境をGitLabで作成できます。これにより、テストやセキュリティスキャンを効率的に実行できます。\n\n### デプロイの効率化\n\nGitLabは、Dockerを使用する以下のデプロイパターンをサポートしています。\n\n* **Dockerイメージのビルドとプッシュ：** アプリをコンテナイメージとしてビルドして、GitLabのContainer Registryや他のDockerレジストリにプッシュします。\n* **継続的デリバリー：** Dockerイメージを使ってコンテナオーケストレーションツールにデプロイすることで、迅速で安全なリリースが可能になります。\n\n### マイクロサービスアーキテクチャのサポート\n\nGitLabとDockerを組み合わせることで、マイクロサービスアーキテクチャを簡単に構築できます。マイクロサービスは別々のDockerコンテナとして実行します。GitLab CI/CDパイプラインを使うと、以下のことを管理できます。\n\n* サービス間の依存関係の設定\n* 個別のセキュリティスキャン\n* バージョン管理（ロールバックが容易になります）\n\n## まとめ\n\n2013年の公表以来、Dockerは瞬く間にIT業界に広く普及しました。本記事では、Dockerの基本概念、基本技術、Dockerを使って何ができるのか、なぜDockerが重要なのか、Dockerを理解上でよく目にする用語などについて紹介してきました。\n\nDockerを使う場合には、DevSecOpsにとって大切なCI/CDを実現するためにも、GitLab CI/CDなどの自動化ツールの導入をおすすめします。GitLab のCI/CDパイプラインでDockerコンテナを使用することで、開発における一貫性の維持、スケーラビリティの実現、柔軟な環境の準備が可能になります。\n\n## FAQ（よくある質問）\n\n### Dockerで何ができるのか？\n\nDockerコンテナは、軽量でスタンドアロンの仮想化技術であり、アプリケーションコード、その依存関係、ライブラリをすべてパッケージ化します。Dockerを使うと、1台のマシン上に複数のコンテナ（仮想環境）を構築でき、開発環境や検証環境の統一が図れます。詳しくは、記事の本文をご覧ください。\n\n### Dockerは何に使うのか？\n\nDockerは、デベロッパーがアプリケーションとその依存関係をシステムから切り離したいとき使用します。コンテナにはアプリケーションとその依存関係がまとめられており、軽量な実行環境を提供します。詳しくは、記事の本文をご覧ください。\n\n### Dockerコンテナとは何ですか？\n\nDockerイメージが実行時にコンテナになります。Dockerコンテナは、アプリケーションを実行するためのランタイム環境です。Dockerコンテナに関する詳細は、記事の本文をご覧ください。\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)*\n\n*（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750226168/pf5cwmvqq09v1pe0re66.jpg",[109,977,978,715,797,979,777,798],"cloud native","DevOps","performance",{"featured":91,"template":801,"slug":981},"what-is-docker",{"content":983,"config":992},{"title":984,"description":985,"authors":986,"heroImage":987,"date":988,"body":989,"category":731,"tags":990},"Kubernetes（K8s）とは？その仕組みから利点、使い方まで","Kubernetes（K8s）とは？Kubernetes の読み方から覚えておきたい用語、仕組みやその利点について学びましょう。",[908,863],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687485/Blog/Hero%20Images/kubernetes.jpg","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",[991,977,978,109,533,898,777,979,811],"kubernetes",{"slug":993,"featured":91,"template":801},"what-is-kubernetes",{"content":995,"config":1004},{"title":996,"description":997,"authors":998,"heroImage":999,"date":1000,"body":1001,"category":731,"tags":1002},"拡張子YAMLファイルとは？基本から使い方まで徹底解説","YAMLは構成ファイル紹介などに使用されるフォーマットです。この記事では、YAMLの基本からKubernetesなどでの具体的な使い方まで解説します。",[908,863],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662547/Blog/Hero%20Images/what_is_yaml.jpg","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は、あらゆる種類のデータを定義、生成、検証するために使用されるオープンソースの言語（具体的には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### 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### 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はなぜ人気なのですか？\nYAMLは開発者の間で人気のあるデータシリアライズ言語です。なぜなら、その読みやすさ、汎用性、Pythonと似たインデントシステムを使うからです。YAMLは複数のデータ型をサポートしており、多くのプログラミング言語で利用可能なパーサーライブラリが提供されているため、さまざまなデータシリアライゼーションタスクを扱うことができ、幅広い場面で活用されています。\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[978,991,715,109,533,977,798,811,898,1003],"git",{"slug":1005,"featured":91,"template":801},"what-is-yaml",{"category":739,"slug":743,"posts":1007},[1008,1021,1032],{"content":1009,"config":1019},{"title":1010,"description":1011,"authors":1012,"heroImage":1013,"date":1014,"body":1015,"category":743,"tags":1016},"🌞 6月のMonday Merge：GitLab 18登場！ ただのアップデートじゃない、その理由とは？","6月のMonday Mergeでは、大規模アップデートや新しいAI機能、次のスプリントに役立つDevSecOpsインサイトが満載です。",[908],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659951/Blog/Hero%20Images/image4.png","2025-06-09","みなさん、こんにちは！6月のMonday Mergeにようこそ。今回も最新情報をお届けします！\n\n大規模アップデートや新しいAI機能、次のスプリントに役立つDevSecOpsインサイトが満載です。今月の注目ポイント？それは GitLab 18の正式リリースです。しかも今回から、PremiumおよびUltimateのすべてのお客様が、GitLab Duoの主要なAI機能を追加料金なしでご利用可能になりました。\n\nそれでは、さっそく見ていきましょう👇\n\n## GitLab 18：GitLabにとっての小さな一歩、DevSecOpsにとっての大きな飛躍\n![gitlab 18](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/image6.png)\n\nGitLab 18.0のリリースでは、PremiumとUltimateプランにGitLab Duoが標準搭載され、AIネイティブなDevSecOpsの新たな時代が始まります。\n\n### 新機能ハイライト\n\n* Duoコード提案 & GitLab Duo ChatがIDEで利用可能に：コードの記述から理解、リファクタリング、テストまでリアルタイムで支援します。  \n* リポジトリX-Ray（Self-Hostedはベータ版）：リポジトリ構造とコードの健全性を可視化します。  \n* GitLab Duoコードレビューの自動有効化：すべてのマージリクエストにAIレビューを適用。  \n* プロンプトキャッシュ機能：AI応答の遅延を軽減し、スムーズなやり取りを実現。\n\n最新のグローバルDevSecOps調査では、デベロッパーがコード以外の作業に79％もの時間を費やしていることが明らかになりました。つまり、AIを“コード支援”のみに使っているだけでは、AIの真の力を活かしきれていません。GitLab 18では、ソフトウェア開発ライフサイクル全体にAIを組み込み、面倒な作業を減らして本質的なイノベーションに集中できる環境を提供します。\n\nこのリリースを可能にしたのは、世界中の素晴らしいコミュニティの力です。328件のコントリビュートにより支えられたGitLab 18は、まさに「使う人たちによって作られた」リリースです。\n\n今月の注目コントリビューターは、Adfinis社CTOのMichael Hoferさん。GitLabのGeo機能やSecrets Managerの改善など、本当にたくさんの貢献をしてくださいました。オープンソースにかける想いと、周囲を巻き込む力に、私たちもたくさんの学びをもらっています。\n\n👉 [GitLab 18 リリースノート全文を読む](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)\n\n## 事例のご紹介：Ignite by FORVIA HELLA\n![ignite](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/image3.png)\n\nソフトウェアが自動車産業の中核となる今、[Ignite by FORVIA HELLA](https://www.linkedin.com/company/ignite-by-forvia-hella/)は次世代車両開発のために、ベルリンを拠点とするソフトウェア・イノベーションハブ Ignite を立ち上げました。\n\nCTOのFelix Kortmann氏はGitLab Duoについてこう語ります。\n\n「Duoのインテリジェントなコード提案は、デベロッパーにとって日常の必需品です。チャット機能と組み合わせることで、即座のフィードバックと反復が可能になり、開発サイクルが短縮され、コードの安全性も向上しました。私たちのワークフローに、シームレスかつ強力に統合されています」\n\nGitLab CI/CDとAI機能を組み合わせることで、Igniteは反復テストや品質チェックを自動化。コードがpushされた瞬間に自動処理が走り、早期の課題検出とスピーディーなデリバリーを実現しています。\n\n## GitLab 18のローンチイベントがバーチャルで開催！しかもアジア時間に！さらに日本語字幕付き！\n\n2025年6月24日（火）13時より、GitLab 18の新機能を紹介するグローバルオンラインイベントを開催します。\n\n### ✨ イベント内容\n\n* GitLab 18の新機能を実演するライブデモ  \n* GitLabのリーダーたち（Bill Staples、Sabrina Farmer、Josh Lemos、David DeSantoほか）によるインサイト共有  \n* 新ライブシリーズ「The Developer Show」の初公開： コーディングデモ、プロダクト解説、コミュニティのストーリーをお届け！\n\nご都合の良い時間帯を選んでぜひご参加ください。質問も大歓迎です！\n\n👉 [今すぐイベント登録する](https://about.gitlab.com/eighteen/)\n\n## GitLab Duo、Premiumにも標準搭載\n\nGitLab 18のリリースにより、Duoの主要機能がPremiumおよびUltimateで標準提供されます。追加ツールも、追加費用も不要。IDE上でスマートな開発がすぐに始められます。\n\n### 機能ハイライト\n\n* GitLab Duoコード提案：20以上のプログラミング言語で高速なコード作成・リファクタリング  \n* GitLab Duo Chat：コードの解説、テスト生成、トラブル対応を簡単に\n\nさらに、より高度な機能を求めるチームには、Ultimate限定だったDuo EnterpriseがPremiumでも利用可能に。[GitLab Duo根本原因分析](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases)、GitLab Duo Self-Hosted、AIコードレビューなどが利用できます。\n\n👉 [Duoを有効にして、開発を始めましょう](https://about.gitlab.com/ja-jp/blog/gitlab-premium-with-duo/)\n\n## AWS Summit で直接お会いしましょう！\n![aws summit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687124/Blog/Content%20Images/image1.png)\n\n東京をはじめ、世界各地のAWS SummitにGitLabも出展します！GitLabとAWSの連携機能を体験できるほか、安全なクラウドネイティブ開発の事例もご紹介。もちろん、ノベルティもご用意しています！\n\n🗓️ 6月のイベント予定\n\n* シドニー｜6月4日〜5日  \n* ストックホルム｜6月4日  \n* ハンブルク｜6月5日  \n* マドリード｜6月11日  \n* ミラノ｜6月18日  \n* ムンバイ｜6月19日  \n* 東京｜6月25日〜26日\n\n👉 [AWS Summit 2025でお会いできるのを楽しみにしています！](https://about.gitlab.com/ja-jp/events/aws-summits/)\n\n## 今月のおすすめ読書\n![08 Header Images April What We’re Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/08_LinkedIn_Header_Images_April_What_We_re_Reading.png)\n\n* **A Practical Roadmap for Adopting Vibe Coding（Vibe Coding 導入のための実践ロードマップ）**\nスピードを重視するあまり、品質や保守性が犠牲にならないよう、適切なガバナンスが必要だとGitLabの戦略VPであるEmilio Salvadorが解説。\n\n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/a-practical-roadmap-for-vibe-coding-adoption/)\n\n* **3 ways APAC engineering teams can operationalise AI（APACの開発チームがAIを活用する3つの方法）**  \nAPACのエンジニアリングチームによる日常業務へのAI統合、業務効率化、抵抗感の軽減、ビジネス価値の可視化についてGitLabのCTOであるSabrina Farmerが説明します。  \n🔗 [Frontier Enterpriseの記事を読む](https://www.frontier-enterprise.com/3-ways-apac-engineering-teams-can-operationalise-ai/)  \n\n* **Beyond Culture: Addressing Common Security Frustrations（文化を越えて：セキュリティ課題の根本に向き合うには）**  \n文化づくりも重要ですが、開発とセキュリティの基本設計から見直す必要があります。GitLab最高情報セキュリティ責任者のJosh Lemosによる解説記事。  \n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/beyond-culture-addressing-common-security-frustrations/)  \n\n* **The Field CTO View: AI, Vibe Coding, and Developer Skillsets（フィールドCTOの視点：AIとVibe Coding、デベロッパーのスキルセットのこれから）**\n企業のIT部門ではAIがどう実装されているのか？ デベロッパーの適応はどう進んでいるのか？GitLabのフィールドCTO部門責任者が答えています。  \n🔗 [The New Stackの記事を読む（英語）](https://thenewstack.io/the-field-cto-view-ai-vibe-coding-and-developer-skillsets/)\n\n## 今月のひとこと\n\n最後に、私が心に留めている言葉をシェアします。完璧を目指すよりも、まずは一歩を踏み出すこと。大きなアイデアは、小さな行動から始まります。\n\n「何かを始める方法は、話すのをやめて行動することだ」– ウォルト・ディズニー\n\nこれからも、ひとつずつマージを重ねながら、学び、作り、そして成長していきましょう 💜\n\n🦊 また次回まで！\n\nGitLabコミュニティの一員でいてくださり、ありがとうございます！みなさんがGitLab 18でどんなものを作ってくださるのか、私たちも楽しみにしています。バーチャルイベントの登録と、AI機能の活用開始もお忘れなく。それではまた次回のMonday Mergeでお会いしましょう。Happy Merging!\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | GitLab Developer Advocate\n![SignOffBanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/SignOffBanner.png)",[1017,715,839,766,777,743,280,234,841,925,1018,270],"releases","collaboration",{"slug":1020,"featured":6,"template":801},"monday-merge-2025-june-9",{"content":1022,"config":1030},{"title":1023,"description":1024,"authors":1025,"heroImage":1026,"date":1027,"body":1028,"category":743,"tags":1029},"🌞 5月のMonday Merge：RSAでの発見、AIアシスタント、 さらに広がるDevSecOpsの世界！","5月のMonday Mergeでは、ARSACでの学びから、GitLab Duo with Amazon Q の一般提供開始、GitLab 17.11、そしてシーメンス社の事例をご紹介します。",[908],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662427/Blog/Hero%20Images/image1.png","2025-05-09","GitLabコミュニティのみなさん、こんにちは！\n\n5月がやってきて、勢いも加速中！RSACでの学びから、GitLab Duo with Amazon Q の一般提供開始、GitLab 17.11、そしてシーメンス社の素晴らしいカスタマーストーリーまで、今月のMonday Mergeはイノベーションとインサイト、インスピレーションが満載です。\n\nさっそく見ていきましょう！\n\n## 🗞️ RSAカンファレンス2025 特別レポート\n\n![monday merge may fatima](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687422/Blog/Content%20Images/image8.png)\n\n先週のサンフランシスコは、霧とコーヒーだけでなく、サイバーセキュリティの熱気にも包まれていました。RSAカンファレンス2025では業界のトップが集結し、GitLabもブース\\#4324で参加しました。イベントでは、AIアシスタント、組み込み型セキュリティ、透明性の高いDevSecOpsの実践などを通して、「協業こそがセキュリティの鍵」という明確なメッセージが示されていました。\n\n## 🤝 GitLab Duo with Amazon Q：ついに一般提供開始、とっても便利です！\n![monday merge may gitlab duo with amazon q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687422/Blog/Content%20Images/image3.png)\n\n新しいAIコンビにご注目を！GitLab Duo with Amazon Qが一般提供となり、AWSでの開発のあり方が大きく変わります。コードを書くとき、マージリクエストのレビュー時、そして古いJavaの更新（リファクタリング戦士たち、ありがとう！）も、AIアシスタントが重荷を引き受けます。\n\nGitLabに組み込まれたAmazon Qを使えば、`/q dev`や`/q transform`のような直感的なプロンプトで、課題から実装までを数分で完了できます。Volkswagen Digital Solutions社やAvaility社のような早期導入企業は、すでにワークフローの高速化や複雑な環境のモダナイゼーションに活用中です。\n\n🔗 [GitLab Duo with Amazon Qの詳細を見る](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n\n🔗 [アイデアを数分でコードに変える方法（英語）](https://about.gitlab.com/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes/)\n\n## 🚀 GitLab 17.11：コンプライアンス、カスタマイズ、さらなるAIの進化\n![monday merge may GitLab release 17.11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687423/Blog/Content%20Images/image2.png)\n\n今月のリリースでは60以上の機能改善があり、セキュリティ管理の強化、柔軟性の向上、AIを使った精密なワークフローの高速化を実現。規制のある環境での運用から、カスタムプロセスの拡張、AIアシスタントの活用まで、GitLab 17.11は必要な管理機能、ダッシュボード、統合機能を提供します。\n\n### ✨ 主なハイライト\n\n* **カスタムコンプライアンスフレームワーク**：要件定義、50以上のコントロールとのマッピング、詳細なレポートの生成\n\n* **Duo Self-Hosted新機能（ベータ）**：根本原因分析、AIによる要約、脆弱性インサイトなど\n\n* **Eclipseプラグイン（ベータ）**：DuoがEclipseに対応し、さらに統合されたコーディング体験が可能に\n\n* **パッケージとタグの保護**：重要な資産を万全に保護\n\n* **カスタムフィールドとイシュー画面の改善**：構造化されたメタデータの追加、タスクの整理、管理効率向上\n\n* **CI/CDパイプライン入力**：動的なコンテンツを柔軟かつ安全に注入\n\n🎉 さらに、GitLabコミュニティによる284件の貢献に感謝します！Mavenパッケージ保護やDuo、CI/CD改善など、世界中のコントリビューターの創造力と献身が反映されています。みなさんの協力がなくては実現できませんでした 🙌\n\n🔗 [17.11のリリースノートを見る](https://about.gitlab.com/ja-jp/blog/gitlab-17-11-release/)\n\n## ☁️ AWSサミットで直接お会いしましょう！\n\n![monday merge may aws summit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687423/Blog/Content%20Images/image4.png)\nGitLabはAWSサミットのグローバルスポンサーとして、各地にDevSecOpsを届けます。  \nぜひブースにお立ち寄りください：\n\n* ライトニングトークやハンズオンデモ  \n* GitLabのAI・セキュリティ専門家との対話  \n* AWS上での開発をより高速・安全に進めるヒント\n\n📍[AWS Summit Japan 2025](https://aws.amazon.com/jp/summits/japan/)（2025年6月25日、26日）、[その他開催地をみる](https://about.gitlab.com/events/aws-summits/)\n\n## 🏗️ 事例のご紹介：シーメンス社がGitLabで協業をスケール\n![monday merge may siemens 事例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687423/Blog/Content%20Images/image6.png)\n\n世界有数のエンジニアリング企業が、開発者の協業の在り方を見直すとどうなるか？ それを体現しているのが、シーメンス社の驚くべきDevSecOpsストーリーです。\n\n2014年、組み込みLinux開発において、より良い協業方法を模索していた小さな先進的チームから全ては始まりました。今では、シーメンス社の75,000人以上の開発者がGitLabを中心となるプラットフォームとして利用し、1日あたり20万件以上のビルドを実施。GitLab導入は単なる技術的な実装にとどまらず、チームをつなげ、インナーソース文化を育み、企業全体のイノベーションを促進しました。\n\nさらに、シーメンス社はGitLabのユーザーであると同時に構築者でもあります。300以上のマージリクエスト、12件のMVP受賞を誇り、プラットフォームの進化にも貢献しながら、自社のDevOps力も強化しています。\n\n現在はAIアシスタントを自社モデルで活用し、マージリクエストを強化する独自の「CodeAI」ボットを導入。AIを“代替”ではなく“創造性と協業の鍵”として未来に備えています。\n\n🔗 [シーメンス社のストーリー全文を読む（ドイツ語）](https://www.computerwoche.de/article/3963808/eine-neue-ara-der-entwicklerzusammenarbeit.html)\n\n## 📚 おすすめ読みもの：AI、リスク、そしてGitLabリーダーたちの見解\n\n![08 Header Images April What We’re Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/08_LinkedIn_Header_Images_April_What_We_re_Reading.png)\n\n* **AIアシスタント：開発者の可能性をスケールさせる**  \nEmilio Salvadorが語る、「未来のソフトウェア開発は一人ではできない」理由。専任のAIアシスタントは新しいチームメイトと語ります。\n\n🔗 [続きを読む（英語）](https://about.gitlab.com/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)\n\n* **リスクインテリジェンスをソフトウェアサプライチェーンに組み込む**  \n[Lee Faus](https://www.linkedin.com/in/leefaus/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)が、リスク対策を単なる後付けではなく、パイプライン全体に組み込む方法を解説します。\n\n🔗 [続きを読む（英語）](https://about.gitlab.com/the-source/security/embedding-risk-intelligence-into-your-software-supply-chain/)\n\n* **セキュリティ対策を公開するメリットとデメリット**  \n[Josh Lemos](https://www.linkedin.com/in/joshlemos/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)が[Tines](https://www.linkedin.com/company/tines-io/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)で、透明性のあるセキュリティ、AIの脅威、コーヒーチャットの重要性について語ります。\n\n🔗 [続きを読む（英語）](https://www.tines.com/blog/gitlab-josh-lemos/)\n\n* **エンジニアリングチームにAIを導入する3つの方法**  \n[Sabrina Farmer](https://www.linkedin.com/in/sabrinafarmer/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)が、AIをチームの味方にするステップバイステップガイドを紹介します。\n\n🔗 [続きを読む（英語）](https://www.forbes.com/councils/forbestechcouncil/2025/04/25/three-ways-to-operationalize-ai-for-engineering-teams/)\n\n* **精密にGo-To-Market戦略を進めるには**  \n[Brian Robins](https://www.linkedin.com/in/brian-robins-5254864/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B4GSpHonESSme7Hfb1%2BuxeQ%3D%3D)がGitLabの、市場戦略、「Ultimate」が成長を牽引する理由、そして財務の“人間らしさ”について語ります。\n\n🔗 [続きを読む（英語）](https://cfothoughtleader.com/cfopodcasts/1083-navigating-the-go-to-market-roadmap-with-precision-brian-robins-cfo-gitlab/)\n\n## 💬 本日のインスピレーション\n\n> 「セキュリティとは、新たな技術的フロンティアへ安全に渡るための架け橋である。」\u003Cbr>– Magda Chelly\n\nAIアシスタント、コンプライアンス管理、コラボレーションのワークフローなど、新たなフロンティアへ進んでいく中で、セキュリティは単なるチェックポイントではなく、イノベーションを可能にする土台だということを忘れずに。架け橋を丁寧に築き、自信を持って渡り、素晴らしいものを創り出していきましょう。\n\nそれでは、次回まで、好奇心を持ち続け、つながりを大切にし、Happy Merging！\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | GitLab Developer Advocate\n![SignOffBanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/SignOffBanner.png)\n\nP.S. DevSecOpsの最新情報を逃さないように、ぜひ来月も読んでくださいね！\n",[1017,715,839,766,777,743,280,234,841,925,1018,270],{"slug":1031,"featured":91,"template":801},"monday-merge-2025-may-9",{"content":1033,"config":1041},{"title":1034,"description":1035,"authors":1036,"heroImage":1037,"date":1038,"body":1039,"category":743,"tags":1040},"🌞 4月のMonday Merge: AIとDevSecOpsの魔法が融合！","4月のMonday Mergeでは、AIの力を活かしたコミュニティ主導のセキュリティ強化、GitLab 17.10の注目機能、さらにサウスウエスト航空がどのようにDevOpsを活用させているのかご紹介します。",[908],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663178/Blog/Hero%20Images/LinkedIn_Header_Images_April_-04.png","2025-04-07","GitLabコミュニティのみなさん、こんにちは！春と共に、今回のアップデートはかなりワクワクする内容のものが届いています。今月は、AIの力を活かしたコミュニティ主導のセキュリティ強化、GitLab 17.10の注目機能、さらにサウスウエスト航空がどのようにDevOpsを活用させているのかご紹介します。\n\n### 注目ポイントはこちら： \n- 📊 AIインパクト分析ダッシュボード – AIがただのトレンドじゃなく、生産性を劇的に向上させることを証明。\n- 🔒 オープンソースセキュリティハブ登場 – 脅威は単独ではなく、みんなで協力して防ぎましょう。\n- 🚀 GitLab 17.10が登場 – Duoコードレビュー、根本原因分析、DORAメトリクスで、DevOpsをもっと強力に。 \n\n準備はOKですか？詳しく見ていきましょう！\n\n## GitLab Duo AIインパクト分析ダッシュボード: データで見るDevSecOpsの進化\n\n![03 Header Images April GitLab Duo AI Impact Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687561/Blog/Content%20Images/03_LinkedIn_Header_Images_April__GitLab_Duo_AI_Impact_Dashboard.png)\n\nAIのROIが測定できる時代が来ました。新しいダッシュボードでは、AIがどのようにワークフローを変えているかを確認できます。\n\n✅ コードによるDuoの提案を使ったチームは、マージサイクルが15%速くなっています。\n✅ チャットを使った Duo Chatの文脈に基づくヘルプで、クエリ解決は2倍速く。\n✅ パイプライン効率向上：AIによるテスト生成で、早期導入者のCI時間が30％短縮されます。\n\n🔗 [GitLab DuoがSDLCに与える影響をどう測っているかを見る（英語）\n](https://www.youtube.com/watch?v=FxSWX64aUOE&list=PLFGfElNsQthZGazU1ZdfDpegu0HflunXW&index=2)\n\n## オープンソースセキュリティハブ: みんなで強く\n\n![04 Header Images April Open Source Security Hub](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687562/Blog/Content%20Images/04_LinkedIn_Header_Images_April_Open_Source_Security_Hub.png)\n\nサイバー攻撃者たちは互いに協力しています。私たちも連携すべきではないでしょうか。GitLabのオープンソースセキュリティハブはその答えとなります。GitLabのセキュリティチームが作成したツールキットを、世界中で公開しています。 \n\nなぜこれが重要なのかは次の通りです。\n- StORMテンプレート: GitLab内で使われるフレームワークで、リスクを標準化。 \n- GUARDフレームワーク: 検出コードを自動化し、脅威対応を効率化。 \n- CISベンチマークスキャナー: セキュリティ基準に照らしてプロジェクトを監査。\n\n私たちは、Crowdstrikeのようなリーダーにインスピレーションを受けています。オープンソースのツールがエコシステム全体を強化するのです。 \n\n🔗 [GitLabがデベロッパーとセキュリティ担当者をどう支援しているかを知る（英語）\n](https://about.gitlab.com/blog/introducing-gitlabs-open-source-security-hub/)\n\n## GitLab 17.10: よりスマートで、より速く、より繋がる\n![05 Header Images April GitLab 17.10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687562/Blog/Content%20Images/05_LinkedIn_Header_Images_April_GitLab_17.10.png)\n\nDevSecOpsツールが強力に進化しました。\n\n🔎 Duoコードレビュー（ベータ版） `@GitLabDuo` をMRでタグ付けすると、AIによるバグ発見と最適化提案が受けられます。 \n\n🛠️ 根本原因分析（Self-Hosted） CI/CD失敗の原因をAIが数秒で解析。エアギャップ環境にも対応（Mistral、Anthropic、OpenAIをサポート）。\n\n📈 DORAメトリクスを視覚化 クロスプロジェクトダッシュボードでボトルネックを特定。実例：あるチームは、テストの不安定さを解決してデプロイ頻度を40%向上。 \n\n🎨 GitLabクエリ言語（GLQL）ビュー＆Markdown Wikiにライブデータクエリを埋め込み、ピクセル完璧なメディア制御でドキュメントを作成。 \n\n🔗 [リリースノートはこちら](https://about.gitlab.com/ja-jp/blog/gitlab-17-10-release/)\n\n## 📅 今後のイベント: ぜひご参加ください！\n\n![06 Header Images April Upcoming Events](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687562/Blog/Content%20Images/06_LinkedIn_Header_Images_April_Upcoming_Events.png)\n\nロンドンからラスベガスまで、DevSecOpsの知見を共有しに各地を巡回します。\n\n- KubeCon（4月1日〜4日、イギリス・ロンドン） – Cloud Native Computing Foundation（CNCF）主催のイベントで、オープンソースやクラウドネイティブの専門家たちが一堂に会しました。KubernetesやDevOps、クラウドネイティブの最新トレンドについて、業界のリーダーたちによって議論されました。\n\n👉 セッションの録画は、イベント終了後2週間以内にCNCFのYouTubeチャンネルに公開される予定です。[見逃した方はぜひチェックしてみてください！](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) \n\n- Google Cloud Next（4月9日〜11日、ネバダ・ラスベガス） – Google主催のプレミアイベントにてAIやクラウド、セキュリティのトップ専門家と交流ができます。ライトニングトークやハンズオンのデモ、ワークショップを通してあなたのクラウドの知識レベルアップに。 さらに、ラスベガスのアレジアント・スタジアムでのThe Killers、Wyclef Jean、Tate Rennerのライブパフォーマンスも！\n\n👉 [ラスベガスで参加しよう！](https://cloud.withgoogle.com/next/25)\n\n- RSAC 2025（4月28日〜5月1日、カリフォルニア・サンフランシスコ） – サイバーセキュリティの最新脅威や戦略、イノベーションを学び、業界のリーダーと協力して未来のセキュリティを形作りましょう。\n\n👉 [参加しよう！](https://www.rsaconference.com/usa)\n\n## 事例のご紹介: サウスウエスト航空のDevOps活用\n![07 Header Images April Customer Spotlight](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687562/Blog/Content%20Images/07_LinkedIn_Header_Images_April_Customer_Spotlight.png)\n\nサウスウエスト航空は、デベロッパーのためにボトルネックを排除し、繰り返しの作業を減らして、より大きな革新に集中できる時間を提供しています🚀 \nサウスウエスト航空のVP＆CISOであるJim Dayton氏はこう言います。\n\n「人がソフトウェア開発に携わるのは、その創造性が好きだからです。問題を解決することが好きです。私たちはその邪魔をしないようにするべきです」。 GitLabにコードを集中させ、セルフサービスツールを使うことで、サウスウエスト航空はデベロッパーがより早く答えを見つけ、効率的に作業できるようサポートしています。 \n\n次に目指すのは？AIを使ったワークフローの自動化。Dayton氏は、AIが脆弱性の説明や、コードレビュアーへの提案などの日常的な作業を効率化し、チームが本当に重要なことに集中できるようになると考えています。\n\n🎯 キー・メッセージ: AIはデベロッパーを置き換えるのではなく、より良く、より速く作れるようにサポートするのです。 \n\n🔗 [サウスウエスト航空事例に関する本文を読む](https://about.gitlab.com/ja-jp/blog/southwest-looking-to-help-developers-take-flight/)\n\n## おすすめ読書\n![08 Header Images April What We’re Reading](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/08_LinkedIn_Header_Images_April_What_We_re_Reading.png)\n\n- Emilio Salvador：AI’s Next Chapter： 2025年のソフトウェア開発における4つの変化。GitLabの戦略VPが、AIがコードをコストやコンプライアンスに最適化する方法について説明します。\n\n👉 [Geekwireの記事を読む](https://www.geekwire.com/sponsor-post/ais-next-chapter-four-major-shifts-in-software-development-for-2025/)\n\n- Sabrina Farmer: The tech giants are wrong: GitLabのCTOが、開発者がAIの恩恵を受ける方法を解説。（GitLabのDevSecOpsレポートを用いて）\n\n👉 [Raconteurの記事を読む](https://www.raconteur.net/technology/ai-replace-engineers)\n\n- Joel Krooswyk: Creating a cybersecurity standard of care: ソフトウェアに関する責任の未来。GitLabの連邦CTOが、SBOM（ソフトウェア部品表）とオープンソース監査がどのように責任を守る手段になっているかを解説。\n\n👉 [Federal News Networkの記事を読む](https://federalnewsnetwork.com/commentary/2025/03/creating-a-cybersecurity-standard-of-care-the-future-of-software-liability/)\n\n## 💡 本日のインスピレーション \n\n変化の速い世界で、故Susan Wojcickiの言葉がますます真実味を帯びています。 \n\n「最高のアイデアはしばしば予期しない場所から生まれる」\n\nそれでは、次回まで、好奇心を持ち続け、つながりを大切にし、Happy Merging！\n\n[Fatima Sarah Khalid](https://www.linkedin.com/in/sugaroverflow/) | GitLab Developer Advocate\n![SignOffBanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687125/Blog/Content%20Images/SignOffBanner.png)\n\nP.S. DevSecOpsの最新情報を逃さないように、ぜひ来月も読んでくださいね！\n",[839,1017,766],{"slug":1042,"featured":6,"template":801},"monday-merge-2025-april-7",{"category":751,"slug":755,"posts":1044},[1045,1058,1070],{"content":1046,"config":1056},{"title":1047,"description":1048,"authors":1049,"heroImage":1051,"date":1052,"body":1053,"category":755,"tags":1054},"フリー版のGitLabでできる Integration Guide 〜どんどんつなげよう、GitLabの輪〜","この記事ではGitLabのフリー版をご利用の方が無料で実現できる、他社製品とのインテグレーション方法について、詳しくご説明します。\n",[1050],"Tsukasa Komatsubara","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","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](//images.ctfassets.net/r9o86ar0p03f/6l71cPpTn2z3WSzLx3pIPj/0820ce5f3dc7862fde216d43f83d5824/ã__ã_ªã__ç__ã__GitLabã__ã__ã__ã__ã__ã__17.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,795,109,1018,898,798,811,1055],"embedded DevOps",{"slug":1057,"featured":91,"template":801},"gitlab-free-tier-integration-guide",{"content":1059,"config":1068},{"title":1060,"description":1061,"authors":1062,"heroImage":1064,"date":1065,"body":1066,"category":755,"tags":1067},"20年にわたるGitの歴史をたどる","初めて行われたコミット、初期リリースのユニークな特徴、そしてgit-push(1)のデフォルト動作の変更によって生じた混乱について、一緒に振り返っていきましょう。",[1063],"Patrick Steinhardt","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","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/)",[898,1003],{"slug":1069,"featured":91,"template":801},"journey-through-gits-20-year-history",{"content":1071,"config":1078},{"title":1072,"description":1073,"authors":1074,"heroImage":1075,"date":1038,"body":1076,"category":755,"tags":1077},"Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う","トーバルズ氏がオープンソースのバージョン管理システムの開発にいたった経緯、数か月で手を引いた理由、そしてGitでの新しいプログラミング言語のサポートについてどう考えているかをご紹介します。",[1063],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","バージョン管理システム「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/)",[898,1003],{"slug":1079,"featured":91,"template":801},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"category":90,"slug":766,"posts":1081},[1082,1094,1106],{"content":1083,"config":1092},{"heroImage":1084,"body":1085,"authors":1086,"updatedDate":1087,"date":1088,"title":1089,"tags":1090,"description":1091,"category":766},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750396128/vak5nlffgockma115495.png","本ブログは、[GitLab 18.1 Release](https://about.gitlab.com/releases/2025/06/19/gitlab-18-1-released/)の抄訳です。内容に相違がある場合は、原文が優先されます。\n\n## Maven仮想レジストリ（ベータ版）とGitLab Duoコードレビュー搭載のGitLab 18.1リリース\n\nこのたび、GitLab 18.1のリリースを発表しました。このリリースでは、Maven仮想レジストリ（ベータ版）、GitLab Duoコードレビュー、漏洩パスワードの検出、SLSAレベル1準拠を実現するCI/CDコンポーネントなど、さまざまな機能が追加されました。\n\nこれらの機能は、今回のリリースに含まれる110件以上の改善点のほんの一部です。この記事では、お役に立つアップデートをすべてご紹介していますので、ぜひ最後までお読みください。\n\nGitLab 18.1には、GitLabコミュニティのユーザーから311件ものコントリビュートがありました。ありがとうございました！GitLabは[誰もがコントリビュートできる](https://about.gitlab.com/community/contribute/)プラットフォームであり、今回のリリースもユーザーのみなさまの協力なしには実現しませんでした。\n\n来月のリリースで予定されている内容を先取りするには、[今後のリリースページ](https://about.gitlab.com/upcoming-releases/)をご覧ください。\n\n[GitLab 18.1のリリースでは、Maven仮想レジストリ（ベータ版）とGitLab Duoコードレビューが追加されました。クリックしてSNSで共有しましょう！](http://twitter.com/share?text=GitLab+18.1%E3%81%AE%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%A7%E3%81%AF%E3%80%81Maven%E4%BB%AE%E6%83%B3%E3%83%AC%E3%82%B8%E3%82%B9%E3%83%88%E3%83%AA%EF%BC%88%E3%83%99%E3%83%BC%E3%82%BF%E7%89%88%EF%BC%89%E3%81%A8GitLab+Duo%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%8C%E8%BF%BD%E5%8A%A0%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%81%97%E3%81%A6SNS%E3%81%A7%E5%85%B1%E6%9C%89%E3%81%97%E3%81%BE%E3%81%97%E3%82%87%E3%81%86%EF%BC%81&url=https://about.gitlab.com/ja-jp/blog/gitlab-18-1-release/&hashtags=)\n\n## 今月の[注目コントリビューター](https://contributors.gitlab.com/docs/notable-contributors)は[](https://gitlab.com/karras)[Chaitanya Sonwane](https://gitlab.com/chaitanyason9)さんです\n\n\u003Cimg src=\"https://about.gitlab.com/images/notable-contributor-logo.svg\">\n\nChaitanya Sonwaneさんは、継続的な認証機能の強化により、GitLabのセキュリティ機能向上に貢献しています。[2025年に13件のコントリビュートがマージされ](https://contributors.gitlab.com/users/chaitanyason9?fromDate=2025-01-01&toDate=2025-12-31)、認証情報インベントリのフィルタリング、サービスアカウント管理、作業アイテムの使いやすさが向上しました。以前には[GitLab 17.11の主要機能](https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/#token-statistics-for-service-account-management)としてサービスアカウントのトークン統計情報をひと目で確認できる機能を手がけ、サービスアカウントの管理を容易にする「一目でわかる」情報を提供しました。Chaitanyaさんは現在、[作業アイテムリストのソート設定をコンテキスト固有にする改善](https://gitlab.com/gitlab-org/gitlab/-/issues/503587)に取り組み、GitLabの製品計画におけるユーザーエクスペリエンスをさらに向上させています。\n\nChaitanyaさんの活躍により、GitLabを利用する組織のセキュリティが強化され、サービスアカウントの使用状況がプロジェクト全体で把握しやすくなりました。現在では、チームが認証情報をより効果的に追跡、ローテーションできるようになったことで、セキュリティの脆弱性につながりかねない、未管理の認証情報のリスクが軽減されています。\n\n「認証情報インベントリとサービスアカウントに対するChaitanyaさんのコントリビュートは、セキュリティ分野において非常に貴重なものです」と[Eduardo Sanz-Garcia（](https://gitlab.com/eduardosanz)ソフトウェアサプライチェーンセキュリティステージの認証グループのシニアフロントエンドエンジニア）は語ります。Eduardoは、[GitLabの認証チーム](https://about.gitlab.com/direction/software_supply_chain_security/authentication/)による推薦も後押ししました。\n\nさらに彼は「Chaitanyaさんは、トークン統計のコンセプトの実装に貢献してくれました。認証情報インベントリの取り組みにより、認証情報の追跡とモニタリングを強化する、非常に要望の多かった機能が提供されたのです。非常に素晴らしいコントリビュートでした」とも付け加えています。\n\nChaitanyaさんはTATA AIGのソフトウェアエンジニアです。セキュリティ上の課題に積極的に取り組み、自らのコントリビュートを改善するための継続的なフォローアップを行っています。\n\nこの場を借りて、GitLabのセキュリティ基盤やその他の製品にコントリビュートしてくれたChaitanyaさんに感謝します！\n\n## GitLab 18.1リリースの主な改善点\n\n### Maven仮想レジストリがベータ版で利用可能に\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nMaven仮想レジストリは、GitLabでのMaven依存関係管理を簡素化するものです。Maven仮想レジストリを使用しない場合、Maven Central、プライベートリポジトリ、GitLabパッケージレジストリからの依存関係にアクセスするための設定を個別に行う必要があります。こうしたアプローチでは、リポジトリへの順次クエリによってビルドが遅くなり、セキュリティ監査とコンプライアンスレポート作成が複雑になります。\n\nMaven仮想レジストリは、複数のアップストリームリポジトリを単一のエンドポイントに集約することで、このような問題に対処します。プラットフォームエンジニアは、1つのURLを介してMaven Central、プライベートレジストリ、GitLabパッケージレジストリを設定できます。インテリジェントキャッシュはビルドパフォーマンスを向上させ、GitLabの認証システムと統合されます。これにより、設定オーバーヘッドの削減、ビルドの高速化、セキュリティとコンプライアンス向上を目的として一元管理されたアクセス制御が実現します。\n\nMaven仮想レジストリは現在、GitLab.comとGitLab Self-Managedの両方で、GitLab PremiumおよびUltimateのお客様にベータ版として提供されています。一般公開リリースには、レジストリ設定用のWebベースUI、共有可能なアップストリーム機能、キャッシュ管理のためのライフサイクルポリシー、強化された分析機能などが追加される予定です。現在のベータ版では、トップレベルグループあたり最大20の仮想レジストリ、仮想レジストリあたり最大20のアップストリームまでと制限されており、ベータ期間中の設定はAPIのみで行えます。\n\n企業のお客様を対象としたMaven仮想レジストリベータプログラムを実施しています。最終リリースの品質向上にご協力をお願いいたします。ベータ版にご参加いただくお客様には、機能への早期アクセス、GitLab製品チームとの直接のやり取り、評価期間中の優先サポートを提供します。ベータプログラムに参加するには、[イシュー498139](https://gitlab.com/gitlab-org/gitlab/-/issues/498139)でご興味があることをお知らせいただき、ユースケースの詳細を提供してください。また、フィードバックや提案は[イシュー543045](https://gitlab.com/gitlab-org/gitlab/-/issues/543045)にお寄せください。\n\n[ドキュメント](https://docs.gitlab.com/user/packages/virtual_registry/maven/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14137)[](https://gitlab.com/groups/gitlab-org/-/epics/14137)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZkIkaJDEcEE?si=F7dfSCtzBIv02_is\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### GitLab Duoコードレビューが一般公開開始\n\n> SaaS: Premium、Ultimate、Duo Enterprise\\\n> Self-Managed: Premium、Ultimate、Duo Enterprise\n\nGitLab Duoコードレビューが一般公開され、本番環境で使用できるようになりました。AI搭載のこのコードレビューアシスタントは、マージリクエストに対して的確で自動化されたフィードバックを提供し、従来のコードレビュープロセスを変革します。これにより、人間のレビュアーが関与する前に、潜在的なバグ、セキュリティの脆弱性、コード品質の問題を特定できるため、レビュープロセス全体を徹底的かつ効率的に行うことができます。GitLab Duoコードレビューには以下の機能が含まれています。\n\n* **自動初期レビュー**：コードの変更内容を分析し、潜在的な問題、改善点、ベストプラクティスに関する包括的なフィードバックを提供します。  \n* **対話ベースで改善**：マージリクエストコメントで`@GitLabDuo`をメンションすると、特定の変更や質問に対する的確なフィードバックを受け取ることができます。  \n* **実行可能な提案**：多くの提案をブラウザから直接適用できるため、改善プロセスが効率化されます。  \n* **文脈を理解した分析**：変更されたファイルの内容を理解し、プロジェクトに特化した関連性の高い推奨事項を提供します。\n\nGitLab Duoコードレビューをリクエストするには、次の手順に従います。\n\n* マージリクエストで、`/assign_reviewer` `@GitLabDuo`クイックアクションを使用して`@GitLabDuo`をレビュアーとして追加するか、GitLab Duoをレビュアーとして直接割り当てます。  \n* コメントで`@GitLabDuo`をメンションすると、ディスカッションスレッドで特定の質問をしたり、詳細なフィードバックをリクエストしたりできます。  \n* プロジェクト設定で自動レビューを有効にすると、GitLab Duoがすべての新しいマージリクエストを自動的にレビューします。\n\nGitLab Duoコードレビューを活用することで、チームがより高いコード品質基準を維持しながら、手動レビューサイクルに費やす時間を短縮できます。問題を早期に発見し、教育的なフィードバックを提供することで、開発チームにとって品質管理ツールと学習ツールの両方の役割を果たします。\n\nベータ版時のGitLab Duoコードレビューの動作はこちらを[ご覧ください](https://www.youtube.com/watch?v=FlHqfMMfbzQ)。\n\n[イシュー517386](https://gitlab.com/gitlab-org/gitlab/-/issues/517386)でご経験やフィードバックをお寄せいただき、本機能の継続的な改善にご協力ください。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13979)[](https://gitlab.com/groups/gitlab-org/-/epics/13979)\n\n![GitLab Duoコードレビューが一般公開開始](https://about.gitlab.com/images/18_1/create-duo-code-review.png)\n\n### ネイティブGitLab認証情報の漏洩パスワード検出\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: -\n\nGitLab.comへのサインイン時に、アカウント認証情報の安全なチェックが実行されるようになりました。お使いのパスワードが既知の情報漏洩に含まれている場合、GitLabにバナーが表示され、メール通知が送信されます。これらの通知には、認証情報の更新手順が記載されています。\n\nセキュリティを最大限に高めるために、GitLabでは以下を推奨しています。\n\n* GitLab専用の強力なパスワードの使用  \n* 2要素認証の有効化  \n* アカウントアクティビティの定期的な確認\n\n注：この機能はネイティブGitLabのユーザー名とパスワードでのみ利用可能です。SSO認証情報は対象外です。\n\n[ドキュメント](https://docs.gitlab.com/security/compromised_password_detection/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)[](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)[](https://gitlab.com/gitlab-org/gitlab/-/issues/549865)\n\n![ネイティブGitLab認証情報の漏洩パスワード検出](https://about.gitlab.com/images/18_1/sscs_password_alert.png)\n\n### CI/CDコンポーネントでSLSAレベル1のコンプライアンスに対応\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate  \n\nGitLabの新しいCI/CDコンポーネントを使用することで、[SLSA](https://slsa.dev/)レベル1のコンプライアンスに対応できるようになりました。このコンポーネントは、GitLab Runnerが生成するSLSA準拠の [アーティファクトの来歴メタデータ](https://docs.gitlab.com/ci/runners/configure_runners/#artifact-provenance-metadata)に対して署名と検証を実行します。また、[Sigstore Cosignの機能](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html)を再利用可能なモジュールとして提供し、CI/CDワークフローに簡単に統合できるようにします。\n\n[ドキュメント](https://docs.gitlab.com/ci/pipelines/pipeline_security/#sign-and-verify-slsa-provenance-with-a-cicd-component)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15859)\n\n[](https://gitlab.com/groups/gitlab-org/-/epics/15859)\n\n![CI/CDコンポーネントでSLSAレベル1のコンプライアンスに対応](https://about.gitlab.com/images/18_1/SLSA_component.png)\n\n## GitLab 18.1リリースに含まれるその他の改善点\n\n### コード検索で複数の検索結果の統合表示が可能に\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\n完全一致コードの検索（ベータ版）では、同じファイル内の複数の検索結果を単一のビューに統合して表示できるようになりました。この改善により、次のことが可能になります。\n\n* 孤立した行表示ではなく、隣接する一致間のコンテキストを保持  \n* 一致する内容が近い場合に重複コンテンツを排除し、視覚的な混乱を軽減  \n* ファイルごとの一致数を明確に表示することで、ナビゲーションを強化  \n* エディタでの表示と同様にコードを表示することで、可読性を改善\n\nこの変更により、リポジトリ全体のコードパターンの発見と理解がより効率的になりました。\n\n[ドキュメント](https://docs.gitlab.com/integration/exact_code_search/zoekt/)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/13127)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/wx2D39UdUoQ?si=fvjYK-rYVHPgVgzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### 権限チェック機能を強化したCODEOWNERSファイル検証\n\nSaaS: Premium、Ultimate\\\nSelf-Managed: Premium、Ultimate\n\nGitLabでは、基本的な構文チェックを超えた、CODEOWNERSファイルに対するより強化された検証が提供されるようになりました。CODEOWNERSファイルを表示すると、GitLabが自動的に包括的な検証を実行し、マージリクエストのワークフローに影響を与える前に構文エラーと権限の問題を特定します。\n\nこの強化された検証では、CODEOWNERSファイル内の最初の200のユニークなユーザーとグループの参照をチェックし、次のことを検証します。\n\n* 参照されたすべてのユーザーとグループがこのプロジェクトにアクセスできること  \n* ユーザーに、マージリクエストを承認するために必要な権限があること  \n* グループに、デベロッパーレベル以上のアクセス権があること  \n* グループに、マージリクエストの承認権限を持つユーザーが少なくとも1人含まれていること\n\nこの事前検証により、設定上の問題を早期に発見して承認ワークフローの中断を防ぎ、マージリクエストが作成されたときにGitLabコードオーナーが実際にレビューの責任を果たせるようにできます。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/project/codeowners/troubleshooting.html#validate-your-codeowners-file)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/15598)\n\n### VS Codeでダウンストリームパイプラインのジョブログを表示\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nVS Code用GitLab Workflow拡張機能で、ダウンストリームパイプラインからのジョブログをエディタ内で直接表示できるようになりました。これまで、子パイプラインからログを確認するには、GitLab Webインターフェイスに切り替える必要がありました。\n\nこの機能は、[GitLab共同開発](https://about.gitlab.com/community/co-create/)を通じて開発されました。この場を借りて、コントリビュートしてくれたTim Ryanさんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/editor_extensions/visual_studio_code/cicd/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1895)\n\n\n\n![VS Codeでダウンストリームパイプラインのジョブログを表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659268/orzwm4kjqdag8fe0psvr.png)\n\n### シークレット検出のデフォルトルールとDAST検出の同等性\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nDASTアナライザーが、GitLabのシークレット検出アナライザーで使用されるものと同じデフォルトのシークレット検出ルールを自動的に取り込むようになりました。この改善により、両方のアナライザーで検出されるシークレットの種類に一貫性が確保されます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dast/browser/checks/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/549990)\n\n### 依存関係リストでコンポーネントバージョンによるフィルタリング\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n依存関係リストで、コンポーネントのバージョン番号によるフィルタリングがサポートされるようになりました。複数のバージョン（`バージョン=1.1、1.2、1.4`など）を選択できますが、バージョン範囲指定はサポートされていません。この機能は、グループとプロジェクトの両方で利用できます。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/dependency_list/#filter-dependency-list)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16431)\n\n![依存関係リストでコンポーネントバージョンによるフィルタリング](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659404/fepyzz2uv3j47bjcehhi.png)\n\n\n\n### コンプライアンスステータスレポートでコントロールステータスの一覧がポップアップで表示されるように\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスステータスレポートのコントロールには、次の3つのステータスがあります。\n\n* 合格  \n* 失敗  \n* 保留中\n\nこれまでは、要求事項に関連付けられているコントロールの数に関係なく、少なくとも1つのコントロールが「保留中」の場合、要求事項行全体が「保留中」として表示されていました。これは、失敗したコントロールの表示方法とは一貫性がありませんでした。失敗したコントロールが1つでもある場合は、要求事項に関連付けられた全コントロール数と失敗の数が表示されます。\n\n「保留中」のコントロールに関する詳細なコンテキストと情報を提供するため、要求事項行のステータスにカーソルを合わせると、各コントロールのステータスを一覧表示するポップアップが表示されるようになりました。これにより、単に「保留中」という全体ステータスを確認するだけでなく、どのコントロールが保留中で、どのコントロールが合格または失敗しているかを具体的に把握できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/521757)\n\n### ボットユーザーと人間のユーザーのフィルタリング\n\n> SaaS: -\\\n> Self-Managed: Free、Premium、Ultimate\n\n運用が進んだGitLabインスタンスでは、多くの場合、人間とボットの両方のユーザーが多数存在します。今回のリリースで、管理者エリアのユーザーリストをユーザータイプでフィルタリングできる機能が追加されました。この機能により、以下のことが可能になります。\n\n* 人間のユーザーと自動化アカウントを区別して迅速に特定、管理  \n* 特定のユーザータイプに絞った管理アクションを実行  \n* ユーザーの監査と管理のワークフローの効率化\n\n[ドキュメント](https://docs.gitlab.com/administration/moderate_users/#view-users-by-type)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/541186)\n\n![ボットユーザーと人間のユーザーのフィルタリング](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750659653/prkshqzxg5785p69yshd.png)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/541186)\n\n### ユーザープロフィールのORCID識別子\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nユーザープロフィールにORCID識別子を設定できるようになり、GitLabが研究者や学術コミュニティにとってより使いやすく価値あるものになりました。[ORCID](https://orcid.org/)（Open Researcher and Contributor ID）は、研究者に永続的なデジタル識別子を提供し、他の研究者との区別を可能にするとともに、研究者とその業績を自動的に関連付けることで、適切な評価を支援するものです。\n\nこの機能は、学術コミュニティからの長年の要望に応えるため、アルトワ大学の修士課程の学生であるThomas LabaletteとErwan Hivinが[Daniel Le Berre](https://www.ouvrirlascience.fr/appointment-of-daniel-le-berre-as-the-national-coordinator-for-higher-education-and-research-software-forges-in-france/)の指導の下、コミュニティに貢献することを目的に開発したものです。\n\n[ドキュメント](https://docs.gitlab.com/user/profile/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/23543)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/23543)\n\n![ユーザープロフィールのORCID識別子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663008/oogvxelirqapyxp10pha.png)\n\n\n\n### サービスアカウントのパイプライン通知への登録\n\n> SaaS: Premium、Ultimate\\\n> Self-Managed: Premium、Ultimate\n\nサービスアカウントによってトリガーされたパイプラインイベントの通知を、受信できるようになりました。通知はパイプラインが合格、失敗、または修正された場合に送信されます。これまでは、サービスアカウントに有効なカスタムメールアドレスが設定されている場合にのみ、そのサービスアカウントのメールアドレスに通知が送信されていました。\n\nこの場を借りて、コントリビュートしてくれた[Densett](https://gitlab.com/Densett)さん、[Gilles Dehaudt](https://gitlab.com/tonton1728)さん、[Lenain](https://gitlab.com/lenaing)さん、[Geoffrey McQuat](https://gitlab.com/gmcquat)さん、[Raphaël Bihoré](https://gitlab.com/rbihore)さんに感謝します！\n\n[ドキュメント](https://docs.gitlab.com/user/profile/notifications/#notification-events-on-issues-merge-requests-and-epics)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/515629)\n\n### 無効となっているパーソナルアクセストークンの表示\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLabは、有効期限が切れたり、失効したりしたアクセストークンを自動的に無効化します。今回の変更では、無効となっているトークンを確認できるようになりました。これまでは、アクセストークンが無効になると表示されなくなっていました。この変更により、こうしたトークンのトレーサビリティとセキュリティが向上します。\n\n[ドキュメント](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/425053)\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/weEU6pukbag?si=ebijnyBQdW1_5yBl\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### GitLab Query Language（GLQL）ビューでのエピックサポート（ベータ版）\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Query Language（GLQL）ビューが大幅に改善されました。今後は、クエリでエピックをタイプとして使用できるようになり、グループ全体のエピック検索や親エピックへのクエリが可能になります。\n\nこの機能強化により計画・追跡のワークフローが大きく向上し、エピックレベルでのクエリや整理が格段に効率化されます。\n\n[ドキュメント](https://docs.gitlab.com/user/glql/fields/#epic)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab-query-language/glql-rust/-/issues/30)\n\n### レビューパネルによるマージリクエストのレビューエクスペリエンスの強化\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nマージリクエストのレビューを行う際、レビューを送信する前にこれまでのフィードバックを参照すると役立つことがあります。これまでは、最終コメントと保留中コメントが別々のポップアップに分かれていたため、全体像を把握することが困難でした。\n\nコードレビュー時に、保留中の下書きコメントを一箇所にまとめて表示する専用ドロワーが利用できるようになりました。強化されたレビューパネルでは、レビュー送信インターフェイスがよりアクセスしやすい場所に移動し、保留中のコメント数を示す番号付きバッジが表示されます。パネルを開くと、下にスクロールできるリストに下書きコメントがすべて表示されるため、送信前のフィードバックの確認と管理が簡単になります。\n\n[ドキュメント](https://docs.gitlab.com/user/project/merge_requests/reviews/#submit-a-review)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/525841)\n\n[](https://gitlab.com/gitlab-org/gitlab/-/issues/525841)\n\n![レビューパネルによるマージリクエストのレビューエクスペリエンスの強化](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663218/yfbrzecnuynpb1g57854.png)\n\n\n\n### GitLab Runner 18.1\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGitLab Runner 18.1もリリースされます！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、拡張性の高いビルドのエージェントです。GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。\n\nバグ修正：\n\n* [GitLab 17.10または17.11にアップグレードすると、Runnerがジョブをリクエストしたときに404エラーが発生する可能性があります](https://gitlab.com/gitlab-org/gitlab/-/issues/543351)。\n\nすべての変更の一覧は、GitLab Runnerの[変更履歴](https://gitlab.com/gitlab-org/gitlab-runner/blob/18-1-stable/CHANGELOG.md)で確認できます。\n\n[ドキュメント](https://docs.gitlab.com/runner)\n\n### 高度なSASTのPHPサポート\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nGitLabの高度なSASTにPHPサポートを追加しました。この新しいファイル間、関数間スキャン機能を使用するには、[高度なSASTを有効](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#enable-advanced-sast-scanning)にします。高度なSASTをすでに有効にしている場合、PHPサポートは自動的に有効になります。\n\n高度なSASTが各言語で検出する脆弱性の種類を確認するには、[高度なSASTカバレッジページ](https://docs.gitlab.com/user/application_security/sast/advanced_sast_coverage/)を参照してください。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#supported-languages)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/14273)\n\n### パイプライン実行ポリシーにおける変数の優先順位制御\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\n多くの場合、セキュリティチームはセキュリティ保証とデベロッパーエクスペリエンスの間で微妙なバランスを取ることになります。セキュリティスキャンが適切に実行されていることを確認するのは重要ですが、セキュリティアナライザーが正常に動作するためには、開発チームからの特定のインプットが必要な場合があります。変数の優先順位制御により、セキュリティチームは新しい`variables_override`設定オプションを通じて、パイプライン実行ポリシーにおける変数の処理方法を細かく制御できるようになりました。\n\nこの新しい設定を使用すると、次のことが可能になります。\n\n* プロジェクト固有のコンテナイメージパス（`CS_IMAGE`）を許可するコンテナスキャンポリシーを適用  \n* `SAST_EXCLUDED_PATHS`などの低リスク変数は許可し、`SAST_DISABLED`などの高リスク変数はブロック  \n* `AWS_CREDENTIALS`などのグローバルCI/CD変数で保護（マスクまたは非表示）されたグローバル共有認証情報を定義しつつ、必要に応じてプロジェクトレベルのCI/CD変数によるプロジェクト固有の上書きを許可\n\nこの強力な機能は、次の2つのアプローチをサポートしています。\n\n* **デフォルトで変数をロックする**（`allow: false`）：例外として指定した特定の変数を除き、すべての変数をロック  \n* **デフォルトで変数を許可する**`（allow: true`）：変数のカスタマイズを許可するが、重大なリスクのある変数を例外として指定することで制限  \n\n\n\nパイプライン実行ポリシーによってCI/CDジョブが実行される際のトレーサビリティとトラブルシューティングを改善するために、ジョブログ機能も導入されました。これにより、デベロッパーとセキュリティチームは、どのジョブがポリシーによって実行されたかを簡単に特定できますジョブログでは、変数の上書きによる影響の詳細を確認でき、どの変数がポリシーによって上書きまたはロックされているかを把握するのに役立ちます。\n\n**実際の影響**\n\nこの機能強化により、セキュリティ要件とデベロッパーの柔軟性のニーズとの間のギャップが解消されます。\n\n* セキュリティチーム：プロジェクト固有のカスタマイズを許可しつつ、標準化されたスキャンを実行できる  \n* デベロッパーは：ポリシーの例外をリクエストすることなく、プロジェクト固有の変数を制御できる  \n* 組織は：開発ワークフローを混乱させることなく、一貫したセキュリティポリシーを実装できる\n\nこの重要な変数制御機能により、GitLabは組織が開発の柔軟性を保ちながら強固なセキュリティポリシーを導入できる環境を提供します。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/#variables_override-type)\\\n[エピック](https://gitlab.com/groups/gitlab-org/-/epics/16430)\n\n\n\n![パイプライン実行ポリシーにおける変数の優先順位制御](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750663308/h1oukhyd4ky1w6spdxpo.png)\n\n\n\n### 外部カスタムコントロールの`Name`を定義\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまでは、カスタムコンプライアンスフレームワークを作成する際に外部カスタムコントロールの名前を定義できず、GitLabコントロールと並んでリスト表示される外部コントロールを識別することが困難でした。\n\n今回、外部カスタムコントロールを定義する際のワークフローの一部として`Name`フィールドが追加されました。これにより、複数の外部カスタムコントロールを作成し、それぞれに固有の名前を設定して明確に区別できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_frameworks/#external-controls)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/527007)\n\n### GitLab Duo脆弱性の修正のためのSASTカバレッジの向上\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nこれまでは、次のCommon Weakness Enumeration（CWE）識別子を持つ検出された脆弱性を手動で解決する必要がありました。\n\n* CWE-78（コマンドインジェクション）  \n* CWE-89（SQLインジェクション）\n\n現在は、GitLab Duo脆弱性の修正により、これらの脆弱性を自動的に修正できるようになりました。\n\n[ドキュメント](https://docs.gitlab.com/user/application_security/vulnerabilities/#supported-vulnerabilities-for-vulnerability-resolution)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/534307)\n\n### コンプライアンスフレームワークUIにおける要件のページネーション\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスフレームワークを作成する際は、最大50個の要件を指定できます。\n\nただし、これほど多くの要件があると、UIで大きな表示領域を占めるため、コンプライアンスフレームワークの操作が非常に困難になります。\n\n今回のリリースでは、コンプライアンスフレームワークに多数の要件が含まれている場合でも、ユーザーが要件を簡単に閲覧、検索、選択できるよう、要件のページネーション機能を導入しました。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_frameworks/#add-requirements)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/531039)\n\n### コンプライアンスセンターのUIパフォーマンスとフィルタリングを改善\n\n> SaaS: Ultimate\\\n> Self-Managed: Ultimate\n\nコンプライアンスセンターのUIパフォーマンスとフィルタリングオプションの改善を継続しています。今回のリリースでは、次のことを行いました。\n\n* 特に多くの要件とプロジェクトが含まれる場合に、**フレームワークの編集**ページのUIスピードとパフォーマンスを改善しました。  \n* コンプライアンスセンターの**コンプライアンスステータスレポート**タブで、要件、プロジェクト、またはフレームワーク別にグループ化できる新しいフィルタリングオプションを導入しました。\n\nこれらの改善を行うことで、コンプライアンスセンターを定期的に利用するお客様に対し、コンプライアンスセンターと関連機能が大規模環境でも継続して高いパフォーマンスを発揮できるようにしています。\n\n[ドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/508188)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/478216)\n\n### GraphQL APIの`projectMembers`に新しい`accessLevels`引数を追加\n\n> SaaS: Free、Premium、Ultimate\\\n> Self-Managed: Free、Premium、Ultimate\n\nGraphQL APIの`projectMembers`フィールドに`accessLevels`引数が追加されました。この引数を使用すると、APIコールから直接アクセスレベル別にプロジェクトメンバーをフィルタリングできます。これまでは、プロジェクトメンバーの全リストを取得してからローカルでフィルターを適用する必要があり、これにより計算オーバーヘッドが大幅に増加していました。現在では、プロジェクトの権限分析や所有権グラフの生成がより高速化し、リソース効率も向上しています。この機能強化は、複雑な権限構造を持つ大規模デプロイを管理する組織にとって特に価値があります。\n\n[ドキュメント](https://docs.gitlab.com/api/graphql/reference/#projectprojectmembers)\\\n[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/541386)\n\n## バグ修正、パフォーマンスの改善、UIの改善\n\nGitLabでは、ユーザーに可能な限り最高の環境をお届けできるよう尽力しています。リリースのたびに、バグを修正し、パフォーマンスを改善し、UIを向上させるためにたゆまぬ努力を続けています。GitLabは、100万人を超えるGitLab.comユーザーをはじめ、GitLabのプラットフォームを利用するすべての人にスムーズでシームレスな体験をお届けすることを約束します。\n\n18.1で提供されたすべてのバグ修正、パフォーマンスの強化、UI改善を確認するには、以下のリンクをクリックしてください。\n\n* [バグ修正](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=type%3A%3Abug&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.1)  \n* [パフォーマンスの改善](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=bug%3A%3Aperformance&or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&milestone_title=18.1)  \n* [UIの改善](https://papercuts.gitlab.com/?milestone=18.1)\n\n## 非推奨事項\n\n新たに非推奨になった機能、および現在非推奨になっているすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。[](https://docs.gitlab.com/ee/update/deprecations.html#resource-owner-password-credentials-grant-is-deprecated)[](https://docs.gitlab.com/ee/update/deprecations.html#coverage-guided-fuzz-testing-is-deprecated)\n\n## 削除された機能と破壊的な変更\n\n削除されたすべての機能の一覧は、[GitLabドキュメント](https://docs.gitlab.com/ee/update/deprecations.html)で確認できます。今後の破壊的な変更について通知を受け取るには、[破壊的な変更のRSSフィードにサブスクライブ](https://about.gitlab.com/breaking-changes.xml)してください。\n\n[](https://docs.gitlab.com/ee/update/deprecations.html#api-discovery-will-use-branch-pipelines-by-default)[](https://docs.gitlab.com/ee/update/deprecations.html#toggle-notes-confidentiality-on-apis)\n\n### 変更履歴\n\n変更内容をすべて表示するには、次のページから変更履歴を確認してください。\n\n* [GitLab](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/CHANGELOG.md)  \n* [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/CHANGELOG.md)  \n* [VS CodeのGitLab Workflow](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md)  \n* [GitLab CLI](https://gitlab.com/gitlab-org/cli/-/releases)\n\n### インストール\n\nGitLabを新規にインストールする場合は、[GitLabのダウンロードページ](https://about.gitlab.com/ja-jp/install/)をご覧ください。\n\n### 更新事項\n\n[更新ページ](https://about.gitlab.com/ja-jp/update/)をご覧ください。\n\n### ご不明な点がある場合\n\nご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、[GitLabフォーラム](https://forum.gitlab.com/)にアクセスして質問を投稿してください。\n\n### GitLabサブスクリプションプラン\n\n* [Free](https://about.gitlab.com/pricing/)\\\n  ユーザー向けの永久無料機能を提供  \n* [Premium](https://about.gitlab.com/pricing/premium/)\\\n  チームの生産性と調整を強化  \n* [Ultimate](https://about.gitlab.com/pricing/ultimate/)\\\n  組織全体のセキュリティ、コンプライアンス、プランニングに対応\n\nGitLabのすべての機能を[無料](https://about.gitlab.com/free-trial/?hosted=saas)でお試しいただけます。  \n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n\n### 過去の日本語リリース情報\n\n* [GitLab 18.1](https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release)\n* [GitLab 18.0](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)\n* [GitLab 17.11](https://about.gitlab.com/ja-jp/blog/gitlab-17-11-release/)\n* [GitLab 17.10](https://about.gitlab.com/ja-jp/blog/gitlab-17-10-release/)\n* [GitLab 17.9](https://about.gitlab.com/ja-jp/blog/gitlab-17-9-release/)\n* [GitLab 17.8](https://about.gitlab.com/ja-jp/blog/gitlab-17-8-release/)\n* [GitLab 17.7](https://about.gitlab.com/ja-jp/blog/gitlab-17-7-release/)\n* [GitLab 17.6](https://about.gitlab.com/ja-jp/blog/gitlab-17-6-release/)\n* [GitLab 17.5](https://about.gitlab.com/ja-jp/blog/gitlab-17-5-released/)  \n* [GitLab 17.4](https://about.gitlab.com/ja-jp/blog/gitlab-17-4-released/)  \n* [GitLab 17.3](https://about.gitlab.com/ja-jp/blog/gitlab-17-3-released/)  \n* [GitLab 17.2](https://about.gitlab.com/ja-jp/blog/gitlab-17-2-released/)  \n* [GitLab 17.1](https://about.gitlab.com/ja-jp/blog/gitlab-17-1-released/)  \n* [GitLab 16.11](https://about.gitlab.com/ja-jp/blog/gitlab-16-11-released/)",[908],"2025-06-23","2025-06-20","GitLab 18.1 リリース",[1017,839,766,109],"GitLab 18.1でリリースした最新機能をご紹介します。",{"featured":6,"template":801,"slug":1093},"gitlab-18-01-release",{"content":1095,"config":1104},{"title":1096,"description":1097,"body":1098,"category":766,"tags":1099,"authors":1100,"heroImage":1103,"date":1088},"GitLab Ultimate for IBM Z：メインフレーム向けモダンDevSecOps","GitLabとIBMの新しいソリューションは、シームレスな統合、CI/CDランナーサポート、エンドツーエンドの可視性、およびコスト効率により、メインフレームとクラウドネイティブ開発を橋渡しします。","GitLabとIBMは、エンタープライズ開発における根本的な断絶を解決するためにパートナーシップを結びました。それは、メインフレーム開発者が分散環境の開発者と同じモダンなツール、ワークフロー、コラボレーション機能を使用できるようにすることです。GitLab Ultimate for IBM Zは、GitLab認定の統合DevSecOpsソリューションであり、メインフレーム環境に特化して設計されています。このソリューションにより、組織は時代遅れのレガシーライブラリマネージャーからのシームレスな移行を促進し、メインフレーム開発ワークフローをモダナイズできます。IBM z/OS上でネイティブに実行されるCI/CDパイプラインにより、お客様はイノベーションの加速と運用コストの削減を実現できます。\n\n## 現代におけるメインフレーム開発の課題\n\nミッションクリティカルなワークロードにIBM Zシステムを使用するエンタープライズ組織は、従来のDevSecOpsツールでは対応できない課題に直面しています。クラウドネイティブチームは、モダンな[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプライン、協調的な開発、自動化されたテストの恩恵を受けています。一方、メインフレームチームは取り残されることが多く、コストのかかる非効率性と運用サイロにつながる時代遅れのツールに縛られています。\n\nチームはSSH接続や手動ファイル転送などの回避策に頼ることが多く、これらはセキュリティの脆弱性や監査の困難さを生み出します。コンプライアンス要件が厳格な場合、これらの即席のソリューションは受け入れられないリスクとなります。同時に、組織は高価な並行ツールチェーンを維持しており、レガシーメインフレーム開発ツールは、モダンな代替品と比較して限られた機能しか提供しないにもかかわらず、プレミアムライセンスコストがかかっています。\n\nこの断片化は2つの問題を生み出します：配信サイクルの遅延と、モダンな開発体験を期待する開発者の採用の困難さです。\n\n> **「GitLab Ultimate for IBM Zは、長年の業界課題に対処する重要な一歩を表しています。IDCの調査によると、メインフレーム開発者は、配信の非効率性につながり、新しい人材を引き付けることを困難にするレガシーツールで作業することが多いことが示されています。このソリューションにより、モダンなDevSecOps機能と統一されたワークフローがメインフレームに直接もたらされます。これにより、開発者はより協調的かつ効率的に作業できるようになり、組織はイノベーションを加速し、メインフレーム開発をより広範なデジタルトランスフォーメーション戦略に統合することができます。」** \\\n> - Katie Norton、IDC DevSecOpsおよびソフトウェアサプライチェーンセキュリティ リサーチマネージャー\n\n## 統一された開発環境\n\n真のモダナイゼーションとは、単にメインフレーム開発を更新することではありません。それは、メインフレーム、クラウドネイティブ、Web、モバイル開発チームがシームレスに協力できる統一プラットフォームを作成することを意味します。\n\nGitLab Ultimate for IBM Zにより、開発者はz/OS、クラウド、またはオンプレミスインフラストラクチャにデプロイする場合でも、一貫したワークフローを使用できます。知識はサイロ化されるのではなく、チーム間で共有されます。レガシーシステムは動作を継続しながら、チームは独自のペースでモダンなプラクティスを採用できるため、組織はビジネスの中断なく段階的にモダナイズできます。\n\n組織がハイブリッドクラウド戦略を追求する中、GitLabはメインフレームとクラウドネイティブ環境にまたがるアプリケーションの基盤を提供します。\n\n## GitLab Ultimate for IBM Zとは？\n\nGitLab Ultimate for IBM Zは、ネイティブz/OSランナーサポートを提供し、メインフレームインフラストラクチャ上で直接シームレスなCI/CDパイプライン実行を可能にします。このGitLab認定ソリューションは、エンタープライズアプリケーションが要求するセキュリティと信頼性を維持しながら、複雑な回避策の必要性を排除するのに役立ちます。\n\nGitLabの包括的なDevSecOpsプラットフォームとIBMの深いメインフレーム専門知識の組み合わせにより、市場で独自のものが生まれます：エンタープライズレガシーシステムとクラウドネイティブイノベーションの間の真の架け橋を提供する認定ソリューションです。\n\n## GitLab Ultimate for IBM Zの機能\n\nGitLab Ultimate for IBM Zは、重要なビジネスシステムを維持しながらメインフレーム開発をモダナイズするために必要なツールをエンタープライズチームに提供します。\n\n**ネイティブz/OSランナーサポート**は、リモート接続に関連するセキュリティリスクとスケーラビリティのボトルネックを排除し、メインフレームコードが存在する場所で直接実行されるCI/CDパイプラインを通じて配信を加速します。\n\n**統一されたソースコード管理**は、高価なレガシーライブラリマネージャーをGitLabの検索可能でバージョン管理されたリポジトリシステムに置き換えることで、ツールチェーンをモダナイズし、ライセンスコストとメンテナンスのオーバーヘッドを削減するのに役立ちます。\n\n**IBM Developer for z/OS Enterprise Edition (IDzEE)とのシームレスな統合**は、依存関係ベースのビルド、自動コードスキャン、および使い慣れた開発環境内の包括的なデバッグツールを通じて、より高速なソフトウェアリリースを実現し、品質とセキュリティの両方を向上させます。\n\n**メインフレームと分散環境全体のエンドツーエンドの可視性**は、計画から本番までの包括的なプロジェクト管理を提供し、モダンな次世代開発ツールを通じて人材を維持するのに役立つ自動化されたDevOpsワークフローを可能にします。\n\n## 今すぐメインフレーム開発環境をモダナイズ\n\nGitLab Ultimate for IBM Zは、メインフレーム開発体験を変革する準備ができている組織向けに、現在利用可能です。詳細については、[GitLabとIBMのパートナーシップページ](https://about.gitlab.com/partners/technology-partners/ibm/)をご覧ください。",[285,766,109,715],[1101,1102],"Mike Flouton","Andy Bradfield","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png",{"featured":91,"template":801,"slug":1105},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"content":1107,"config":1116},{"title":1108,"description":1109,"authors":1110,"heroImage":1112,"date":836,"body":1113,"category":766,"tags":1114},"2025年第2四半期の『Forrester Wave™: DevOps Platforms』でGitLabがリーダーの1社に位置付け","Forrester社は、GitLabプラットフォームを「オールインワンソリューションの中でももっともオールインワン」と称し、「一度の購入で標準化を目指す企業に適している」と付け加えています。",[1111],"Dave Steer","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","DevSecOpsプラットフォームの選択は、企業が下すテクノロジー上の意思決定のうち、もっとも重要なもののひとつです。そのため、GitLabが[**2025年第2四半期の『Forrester Wave™: DevOps Platforms』でリーダーの1社として位置付け**](https://about.gitlab.com/forrester-wave-devops-platform/)されたことを大変光栄に思います。GitLabは、ゼロデイ体験、デベロッパー向けツール、ビルドの自動化と継続的インテグレーション、デプロイの自動化、AIリスクの軽減、AIの導入、組み込み型のセキュリティツール、プラットフォームの一貫性など、お客様がもっとも重視する基準において最上位のスコアを獲得しました。\n\n***「GitLabは、オールインワンソリューションの中でももっともオールインワンであり、一度の購入で標準化を目指す企業に適している」-*** Forrester Wave™: DevOps Platforms（2025年第2四半期）\n\nこの評価には、GitLabに日々寄せられているお客様の声が反映されています。つまり、お客様は安全なソフトウェアをより迅速に提供する必要がありますが、既存のソリューションでは、速度、セキュリティ、またはシンプルさのいずれかを妥協せざるを得ないということです。GitLabはこの3つすべてを妥協せずに実現できます。さらに、5月にリリースした[GitLab 18.0](https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/)では、テスト生成、コード提案、コードリファクタリングなどの[ネイティブAIのGitLab Duo機能](https://about.gitlab.com/ja-jp/blog/gitlab-premium-with-duo/)をGitLab PremiumとGitLab Ultimateに導入しました。追加費用なしで直接ご利用いただけます。\n\n> [今すぐレポートを読む](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n![『Forrester Wave™: DevOps Platforms』（2025年第2四半期）の画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673518/Blog/Content%20Images/Image_DevOps-Platforms-Q2-2025.png)\n\n## エンタープライズレベルの制御を行い、AI変革の最前線に立ち続ける\n\nDevSecOpsは急速に進化しており、AIはその変化の最前線に立っています。しかしながら、多くのAIツールでは、最先端の機能、またはエンタープライズレベルのセキュリティのどちらかを選ばざるを得ません。\n\nForrester社は、**AIの導入**と**AIリスクの軽減**の両方の基準において、GitLabに5点（最上位の評価）を付けました。セキュリティを維持する革新的なAI機能の開発に注力していることが、お客様だけでなく、多くの方々に認められていることを嬉しく思います。\n\nこの2つの強みは、以下を含むGitLab DuoのAI機能群にも反映されています。\n\n* GitLab Duo Workflow（非公開ベータ版）：開発、セキュリティ、およびオペレーションにわたる複雑なタスクを処理する自律型AIエージェント。エンタープライズレベルのガードレールと監査証跡を提供します。  \n* GitLab Duo Agentic Chat：コードの説明からテスト作成まで、あらゆる場面で文脈を理解する会話型AIアシスト機能を提供します。知的財産の保護とプライバシー管理機能も組み込まれています。  \n* GitLab Duoコード提案：コードブロックの予測補完、関数ロジックの定義、テスト生成、正規表現パターンのような一般的なコードの提案を行うAIアシスト機能です。  \n* ネイティブAIのGitLab Duo脆弱性の修正：自動説明機能やマージリクエストの自動生成を活用して脆弱性を特定し修正することで、開発プロセスを効率化します。\n\n## より少ないリソースでより多くのことを実現\n\nDevSecOpsチームが求めているのは、ソフトウェアデリバリーライフサイクル（SDLC）の一部だけを支援するようなツールやインテグレーションではないという声を、私たちははっきりと受け取っています。SDLC全体をカバーする、シームレスで統合されたデベロッパーエクスペリエンスが必要なのです。\n\n以下の基準でGitLabが獲得したスコアは、当社の顧客重視の戦略を裏付けるものであると考えています。\n\n* **ゼロデイエクスペリエンス**：Forrester社は、GitLabの「強力なゼロデイエクスペリエンス」について、「すべてがすぐに使える状態」であること、そして豊富な移行ツールとチュートリアルが用意されていることを評価しています。 \n* **デベロッパー向けツール**：Forrester社は、AWSユーザー向けの自律型AIである[GitLab Duo with Amazon Q](https://about.gitlab.com/ja-jp/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)、クラウド開発環境、統合デベロッパープラットフォーム、ドキュメント用Wikiなどを例として挙げています。  \n* **プロジェクト計画と連携**：Forrester社は、GitLabの「強力なコンプライアンスセンター」の存在に加え、トップダウンおよびボトムアップでの連携を促進するツールがあることに注目しています。  \n* **パイプラインセキュリティ**：Forrester社は、パイプラインセキュリティの基準においてもGitLabに最上位のスコアを付けました。  \n* **ビルドの自動化と継続的インテグレーション**：Forrester社は、マルチステージのビルドパイプラインと強力なセルフホスティングのサポートを備えたビルドの自動化と継続的インテグレーションについて言及しています。\n\n## レポートを読む\n\n2025年第2四半期の『Forrester Wave™: DevOps Platforms』でリーダーの1社として評価されたことは、SDLC全体にわたり信頼できる唯一の情報源を提供する、当社のプラットフォームの幅広い機能と奥深さを物語っています。複数のツールやインテグレーションを使い分ける必要はもうありません。GitLabなら、シームレスで統合されたエクスペリエンスをとおして、生産性の向上、摩擦の軽減を実現します。今回の評価は、GitLabチームの努力、GitLabのオープンソースコミュニティからの多大な貢献、お客様からの貴重なフィードバック、そしてソフトウェア開発の未来を形作るという当社の熱意を反映していると考えております。\n\n> #### [今すぐレポートを読む](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n*Forrester社がリサーチに関する発行物に掲載されている特定の企業、製品、ブランド、サービスを推奨することはありません。また、当該発行物に記載されている評価に基づいて、特定の企業やブランドの製品またはサービスを選択するよう個人に助言することもありません。情報は、利用可能な最適なリソースに基づいて示されます。意見はその時点での判断によるものであり、変更される可能性があります。詳細については、Forrester社の客観性に関する[こちらのページ](https://www.forrester.com/about-us/objectivity/)をご覧ください。*",[1115,766,743,796],"research",{"slug":1117,"featured":91,"template":801},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"category":126,"slug":777,"posts":1119},[1120,1131,1143],{"content":1121,"config":1129},{"title":1122,"description":1123,"authors":1124,"heroImage":1125,"date":1126,"body":1127,"category":777,"tags":1128},"IDE、そしてWeb IDEとは","Web IDE や IDE の知識を身に付け、統合開発環境ツール使用時や、開発自体に生かしましょう。",[972],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660036/Blog/Hero%20Images/ide.jpg","2025-06-03","Web IDEとは、クラウドベースで機能する、Webブラウザ上でソースのコミットまで行える高度なIDEです。では、IDEとは？ Web IDEやIDEを知らなかった人にもわかりやすいように、その仕組みや概要を、ここで簡単に説明します。\n\n## 目次\n\n* IDE（統合開発環境）とは\n* IDEの主な特徴\n* IDEの仕組み\n* IDEの種類\n* IDEを使うメリット\n* IDEの例\n* Web IDEとは\n* IDEのFAQ（よくある質問）\n\n## IDE（統合開発環境）とは\n\nIDEはIntegrated Development Environmentの略で、日本語では「統合開発環境」と訳されます。IDEは、開発者がソフトウェアのコードを開発する際に必要なソフトウェアをひとつにまとめ、単一の画面で操作できるようにしたものです。\n\nプログラミングには次のようなプログラムが必要になります。\n\n* テキストエディタ：ソースコードを記述  \n* コンパイラー：ソースコードからオブジェクトコードを生成  \n* リンカー：ターゲットとなるCPU用に実行コードを生成  \n* デバッガー：作成したプログラムのバグ検出に使用  \n* コードのバージョン管理：ほとんどのIDEはシームレスにバージョン管理システムを統合  \n* 自動化ビルド：ビルドプロセスを自動化\n\nIDEがなかった時代は、これら一つひとつを手作業で統合しなければなりませんでした。しかし、現在ではすべてがIDEツールに統合されているため、IDEをインストールするか、Web IDEにアクセスすれば、開発環境が瞬時に整います。ほとんどのIDEには、ソースコードを自動的に書いたり、編集したりするための機能が含まれています。そのため、コード開発を効率的に行うことが可能になります。\n\n## IDEの主な特徴\n\nIDEはこれまで、パソコンにインストールして使用するものが主流でしたが、現在はWeb IDEなど、クラウドベースのものが増えてきています。GitLabのWeb IDEも、Webブラウザにアクセスできれば、簡単に開発ができるため、複数の開発者で開発環境を共有することが可能です。\n\n統合開発環境（IDE）の特徴は、次のとおりです。\n\n1. 時間の節約：上述のように、各種プログラムがひとつのプラットフォーム上に統合されているため、ソフトウェア開発にかかる時間が短縮できます。  \n2. チームでの開発の効率化：バージョン管理やソースコードの管理など、引き継ぎにかかる手間が省け、ミスが予防できます。  \n3. ヒューマンエラーの防止：IDEのエディタには入力サポート機能があり、コンパイラにはシンタックスチェック、つまり構文の間違いチェック機能があります。こういった機能はヒューマンエラーを防止してくれます。\n\n## IDEの仕組み\n\nIDEとは、ソフトウェアの開発で使用するさまざまなソフトウェアを支援ツールと合わせてまとめ、統合開発環境として使えるようにしたものです。\n\n## IDEの種類\n\nIDEには、さまざまな種類があります。用途や目的、プログラミング言語、ターゲットとする OS や動作環境によって、選ぶポイントがあります。何を作るのか、どういうソフトウェアやアプリケーションを開発するのかによっても、最適 IDEは変わります。どのIDEを選ぶかによって、できることが異なるからです。しかし、異なるIDEで共通してできることは、次のようなものです。\n\n* ソースファイルの構成管理  \n* ビルドの自動実行  \n* デバッグ\n\nまた、たとえば、プログラミング言語には Java、Swift、C++、C\\#、UnityやPythonなどがあるため、コードを書く言語に対応しているIDEを選ぶべきでしょう。IDEの種類としては：\n\n* 多言語対応IDE  \n* モバイル開発用IDE  \n* WebまたはクラウドベースのIDE  \n* 単言語のIDE\n\nなどがあります。\n\nまた、IDEにはダウンロードして使うものと、クラウドで使用するもの、たとえばWeb IDEなどがあります。クラウドベースのものは、複数の開発者の間で開発環境が共有できるため、各々のチームメンバーの環境設定の違いは問題になりません。また、ビルドの際はCPUの速度低下により時間がかかるものですが、クラウドIDEでは速度低下は発生しません。ソースコード開発は、Gitなどと連携すれば、チーム間での共有も行えます。\n\n## IDEを使うメリット\n\nIDE、統合開発環境を使うメリットは、一言で言うなら「開発の効率化」です。「IDEとは」で記述したように、IDEにはテキストエディタ、コンパイル、デバッグなどの機能がすべて統合されています。そのため、コード開発の効率化が図れます。\n\nIDEを使うと、環境設定を行う手間が省けますが、逆に、IDEを使わないと、各種ツールを設定しなければならず、時間がかかります。また、IDEはインストール後すぐ使えるため、プログラミングの初心者にもお勧めできます。\n\n## IDEの例\n\nIDE、統合開発環境にはたくさんの種類があります。現在よく使われているIDEのうち、例を 5 つ挙げます。\n\n●        Visual Studio/Visual Studio Code – Microsoftが開発。市場でとくに人気がある\n\n●        IntelliJ IDEA – JetBrains が開発した、多言語対応型IDE\n\n●        Vim - Bram Moolenaar氏が開発した軽量のテキストエディタでIDEとして使用可\n\n●        Eclipse – IBMが開発した、オープンソースのIDE\n\n●        Jupyter Notebook – Pythonの実行環境をもつ、ブラウザベースのIDE\n\n## Web IDEとは\n\nWeb IDEとは、前述のように、WebベースのIDEで、WebブラウザさえあればアクセスできるIDEを意味します。個々に IDE を利用するのではなく、利用者はみな、ブラウザを介してIDEにアクセスするため、各種設定のわずらわしさから解放されます。\n\n### [GitLab Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/)を使うメリット\n\nGitLabには、クラウドベースの、オンライン[Web IDE（英語版）](https://about.gitlab.com/blog/get-ready-for-new-gitlab-web-ide/)があります。Web IDEは、コミットのステージング機能を備えた高度なエディタです。Web IDEを使うと、GitLab UIから直接複数のファイルに変更を加えることができます。\n\n* フレキシブルでカスタム化可能なインターフェース  \n* パネルは折りたたみ可能で、テーマもカスタム化可能  \n* コンテキストアクションとドラッグ＆ドロップサポート  \n* 開いているファイル全部を一度に検索・置換  \n* GitLab UIから直接ブラウザで開けるため、クイックなコード修正などに便利\n\n## IDEのFAQ（よくある質問）\n\n### Q: IDE（統合開発環境）を使う理由は何ですか。  \nA: IDEはソフトウェア開発環境の一部を構成しています。よく設計されたIDEを使うと、ソフトウェア開発が大幅に効率化できます。\n\n### Q: IDEの3つの主要コンポーネントは何ですか。\n\nA: コードエディタ、コンパイラ、デバッガーが三大コンポーネントです。\n\n### Q: IDEのインストール、設定方法は？\n\nA: ニーズに合ったIDEを選び、最新バージョンを公式サイトから入手してインストールします。ほとんどのIDEで、各種設定は使用環境に合わせてカスタマイズ可能です。 \n\n## GitLab Web IDEを使ってみる\n\nGitLabのWeb IDE は、SaaSおよびSelf-Managedのサブスクリプションを購入されているお客様には無償でお試しいただけます。詳しくは[こちら](https://about.gitlab.com/direction/create/ide/web_ide/)をご覧ください。\n\n\u003Cbr>\u003Cbr>\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)* \u003Cbr>\n*（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n",[1018,797,766,798],{"slug":1130,"featured":91,"template":801},"what-is-ide",{"content":1132,"config":1141},{"title":1133,"description":1134,"authors":1135,"heroImage":1137,"date":1138,"body":1139,"category":777,"tags":1140},"GitLabのカスタムコンプライアンスフレームワークをDevSecOps環境で活用する方法","新しいフレームワークと、50個を超えるすぐに使えるコントロールを活用することで、これまでひとつずつチェックしていた規制要件を、統合された自動化ワークフローの一部へと変換する方法をご紹介します。",[1136],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","2025-04-30","コンプライアンスは、単なるチェック項目ではなく、業務リスクから顧客の信頼に至るまで、あらゆるものに影響を与える重要なビジネス機能です。開発チームにとっては、コンプライアンス要件と開発速度のバランスを取ることは特に困難です。GitLabの[カスタムコンプライアンスフレームワーク](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)を使えば、コンプライアンスの確認を開発ワークフローに直接統合することができます。この記事では、この機能の概要と、その効果を最大限に活用する方法についてご紹介します。\n\n## GitLabのカスタムコンプライアンスフレームワークとは？\n\nGitLabのカスタムコンプライアンスフレームワークを使うと、組織は自社のGitLabインスタンス内で、コンプライアンス基準を定義・実装・適用できます。この機能により、GitLabに元々備わっているコンプライアンス機能を拡張し、特定の規制要件や社内ポリシー、業界標準に合わせたカスタマイズ可能なフレームワークを作成できるようになります。\n\nカスタムコンプライアンスフレームワークには、次のようなメリットがあります。\n* 手動での追跡作業にかかる手間を削減\n* 監査対応の準備を加速\n* コンプライアンス制御をGitLab上でネイティブに適用\n\n![フレームワークが一覧表示されたコンプライアンスセンターのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\n今回のリリースでは、50個を超えるすぐに使える（OOTB）コントロールが提供されており（今後さらに追加予定）、医療分野のHIPAA、データプライバシーに関するGDPR（EU一般データ保護規則）、サービス組織向けのシステムおよび組織管理（SOC）2、その他業界固有の規制など、組織ごとのコンプライアンスのニーズに合わせて調整できます。OOTBコントロールの一例は以下のとおりです。\n\n* 職務分離（SoD、例：最低2名の承認者が必要、作成者によるマージリクエストの承認）\n* セキュリティスキャナの実行（例：SASTの実行、[依存関係スキャン](https://docs.gitlab.com/user/application_security/dependency_scanning/)の実行）\n* 認証/認可（例：プロジェクトの公開設定が非公開、AuthSSOが必須）\n* アプリケーション構成（例：ステータスチェックが必須、Terraformが必須）\n\nさらに、GitLab APIを使用して外部環境のコントロールを構成することもでき、外部環境のステータスや詳細を確認できます。\n\n## ゼロからカスタムコンプライアンスフレームワークを作成する\n\nその価値を理解できたところで、次はGitLab環境でカスタムコンプライアンスフレームワークを実装する方法を見ていきましょう。デモアプリケーションを使って説明しますので、動画を見ながら一緒に進めてください。\n\n**注：** GitLab Ultimateのサブスクリプションが必要です。\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**ステップ1：コンプライアンス要件を定義する**\n\nカスタムフレームワークを構築する前に、まずはコンプライアンス要件を明確に定義する必要があります。\n\n1. **適用される規制を特定する：** 自社に適用される規制や標準（例：GDPR、PCI DSS、HIPAA）を確認します。\n2. **各要件に対応するコントロールを割り当てる：** 各規制を、具体的で実行可能なコントロールとして整理します。\n3. **要件に優先順位を付ける：** リスクの高い領域や、影響の大きい要件を優先します。\n\n**ステップ2：カスタムコンプライアンスフレームワークを作成する**\n\n以下の手順でカスタムコンプライアンスフレームワークを作成できます。\n\n1. GitLabグループの**セキュア  > コンプライアンスセンター**セクションに移動します。\n2. **新しいフレームワーク**ボタンを押します。  \n3. **空のフレームワークを作成**を選択します。\n\n![カスタムコンプライアンスフレームワークの作成画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. フレームワークの名前、説明、色を設定します。\n\n![「新しいコンプライアンスフレームワーク」の画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. フレームワークに要件を追加します：\n   a. ページを下にスクロールして**要件**タブを開きます。\n\n   b. **新しい要件**ボタンをクリックします。\n\n   c. 名前と説明を入力します。\n   d. **コントロール**セクションで**GitLab コントロールを選択**をクリックします。  \n   e. 一覧からコントロールを選択します（例：少なくとも 2 つの承認、SAST の実行など）。 \n   f.  **要求事項を作成**ボタンをクリックします。\n\n![「要求事項を作成」ボタン](// images.ctfassets.net/r9o86ar0p03f/7qHMBVfIF3YGxichlTbqmT/740ae34eb227c19cbeb35cd5667e31f7/image2.png)\n\n6. **フレームワークを作成**ボタンをクリックします。\n\n指定した内容でフレームワークが作成され、プロジェクトに追加できるようになります。また、適切なスキーマに準拠したJSONを使用して、コンプライアンスフレームワークを[インポート](http://TODO)することも可能です。\n\n**ステップ3：プロジェクトにフレームワークを適用する**\n\nフレームワークを作成したら、以下の手順に従います。\n1. コンプライアンスセンターから**プロジェクト**タブを選択します。\n2. 検索バーを使って対象のプロジェクトを**検索**または**絞り込み**ます。 \n3. フレームワークを適用するプロジェクトを選択します。\n4. **一括操作を選択**ボタンをクリックします。\n5. **選択したプロジェクトにフレームワークを適用する**を選択します。\n6. **フレームワークを選択**ボタンをクリックします。\n7. 一覧から適用するフレームワークを選択します。\n8. **適用**ボタンをクリックします。\n\n![SOC 2フレームワークのドロップダウンが表示されたコンプライアンスセンターの画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n適用されたフレームワークは、プロジェクト内で要求事項として可視化され、追跡できるようになります。\n\n**ステップ4：コンプライアンスの状況をモニタリング・報告する**\n\nフレームワークを設定したら、以下のことができるようになります。\n\n1. コンプライアンスセンターを使って、プロジェクト全体のコンプライアンス状況を管理する。不合格となったコントロールの詳細や、推奨される修正方法も確認できます。\n2. 監査や関係者によるレビューへ向けた、**コンプライアンスレポート**を生成する。\n3. **コンプライアンスに関するアラート**を設定し、潜在的な問題を関係者へ通知する。\n4. **監査イベント**で、コンプライアンス設定に対して行われた操作の概要を確認する。\n\n![SOC2テストフレームワークが表示されたコンプライアンスセンターの画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\n## 実例：SOC2 コンプライアンスフレームワークの実装\n\nシステムおよび組織管理（SOC）2、通称SOC2は、米国公認会計士協会（AICPA）によって策定された、厳格な監査基準です。SOC2は、サービス組織のセキュリティ、可用性、処理の完全性、機密性、プライバシーに関するコントロールを評価します。詳細については、[GitLabでSOC 2のセキュリティ要件を満たすためのガイド](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/)をご覧ください。\n\nそれでは、カスタムコンプライアンスフレームワークを使って SOC2 のセキュリティコンプライアンスを検証する実践的な例を見てみましょう。SOC2 のセキュリティ基準には以下が求められます。\n\n* 不正アクセスを防ぐためのコントロールの導入\n* リスクを特定し、軽減するための手順の確立\n* セキュリティインシデントの検出および対応のためのシステムの構築\n\n**免責事項：** これはSOC2の要件に準拠するために利用可能な一部のコントロールを紹介する例です。本番環境に導入する前に、必ずセキュリティ/コンプライアンスチームと相談してください。\n\nGitLabのOOTB（すぐに使える）コントロールを活用したSOC2用カスタムコンプライアンスフレームワークの例：\n\n* **名前：** SOC2セキュリティ要件\n* **説明：** SOC2フレームワークに準拠するためのセキュリティ要件を追加します\n* **要件：**  \n  * **不正アクセスを防ぐためのコントロールの導入**  \n    * Auth SSOを有効化\n    * CI/CDジョブトークンのスコープを有効化\n    * 組織レベルでMFA（多要素認証）を必須化\n  * **リスクを特定し、軽減するための手順の確立**  \n    * 少なくとも2つの承認\n    * 作成者によるマージリクエストの承認\n    * コミッターによるマージリクエストの承認\n    * デフォルトブランチの保護\n  * **セキュリティインシデントの検出および対応のためのシステムの構築**  \n    * 依存関係スキャンの実行\n    * SASTの実行\n    * DASTの実行\n\nこのフレームワークをプロジェクトに適用することで、コンプライアンスが崩れたタイミングや、再度準拠するために必要な対策を把握できるようになります。なお、1つのプロジェクトに対して複数のコンプライアンスフレームワークを作成・適用することも可能です。たとえば、SOC2のプロセス整合性要件専用のフレームワークを別途設けることもできます。\n\n## コンプライアンス要件を満たすためにセキュリティポリシーを実装する\n\n必須ではありませんが、カスタムコンプライアンスフレームワークを含むプロジェクトにセキュリティポリシーを適用することができます。これにより、特定のコンプライアンス基準がセキュリティポリシーによって強制されることを保証できます。たとえば、セキュリティスキャンを求めるカスタムコンプライアンスフレームワークが適用されたプロジェクトに対して、セキュリティスキャナーの実行を強制できます。\n\nGitLab では、以下のようなさまざまなセキュリティポリシーが提供されています。\n\n* [スキャン実行ポリシー](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/)：パイプラインの一部または指定されたスケジュールでセキュリティスキャンを実行します。\n* [マージリクエスト承認ポリシー](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/)：スキャン結果に基づいて、プロジェクトレベルの設定や承認ルールを強制します。\n* [パイプライン実行ポリシー](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/)：プロジェクトのパイプラインにおけるCI/CDジョブの実行を強制します。\n* [脆弱性管理ポリシー](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/)：デフォルトブランチで検出されなくなった脆弱性を自動的に解決します。\n\nここでは、SASTスキャナーを実行することで、SASTスキャンを要求する要件への準拠を自動的に行う方法を紹介します。特定のフレームワークが適用されたプロジェクトに対してセキュリティポリシーを作成・適用するには、次の手順に従います。\n\n1. **SAST スキャン**が求められるカスタムコンプライアンスフレームワークが適用されているプロジェクトに移動します。\n2. サイドバーで、**セキュア > ポリシー**の順に選択します。\n3. **新しいポリシー**ボタンをクリックします。\n4. **スキャン実行ポリシー**で、**ポリシーを選択**ボタンをクリックします。\n5. **名前**と**説明**を入力します。\n6. **アクション**で、実行するスキャンとして**SAST**を選択します。\n\n![「アクション」画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n7. **条件**で、すべてのブランチでパイプラインが実行されたときにトリガーされるように設定します。\n\n![「条件」画面](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n8. **マージリクエスト経由で設定** ボタンをクリックします。\n9. この時点で、すべてのセキュリティポリシーが含まれた別プロジェクトでマージリクエスト（MR）が作成されます。\n10. **マージ**ボタンをクリックします。\n\nこれで、すべてのブランチでSASTが実行されるようになり、その領域におけるコンプライアンスが保証されます。他にもさまざまな種類のセキュリティポリシーがありますので、要件に合うものを探してみてください。\n\n\n\n## 5つのベストプラクティス\n\nカスタムコンプライアンスフレームワークを最大限に活用するために、以下のベストプラクティスに従いましょう。\n\n1. **小さく始める：** まずは、重要な規制や標準のうち1つから着手し、そこから範囲を広げていきましょう。\n2. **関係者を巻き込む：** フレームワークの作成には、コンプライアンスチーム、セキュリティチーム、デベロッパーチームを含めることが重要です。\n3. **可能な限り自動化する：** GitLab CI/CDを活用して、コンプライアンスチェックの自動化を図りましょう。\n4. **しっかりと文書化する：** フレームワークがどのように規制要件に対応しているか、明確に文書化しておきましょう。\n5. **定期的に見直す：** 規制の変更や新たな要件の発生に応じて、フレームワークを更新するようにしましょう。\n\n## 無料トライアルで今すぐスタート！\n\nGitLabのカスタムコンプライアンスフレームワークは、コンプライアンスを開発ワークフローに直接組み込むことで、DevSecOpsにおける大きな進化をもたらします。カスタムフレームワークを導入することで、コンプライアンス業務の負担を軽減し、リスク管理を強化しながら、規制要件を満たしたまま開発サイクルを加速させることが可能になります。\n\nカスタムコンプライアンスフレームワークを定義・適用できる機能により、チームは自社特有の規制状況に対応する柔軟性を得られる一方で、組織全体のコンプライアンスの慣習を一貫させるために必要な構造も得られます。\n\n今後さらに規制要件が複雑化していく中で、カスタムコンプライアンスフレームワークのようなツールを活用して、コンプライアンスと開発速度のバランスを持続的に両立させることが、ますます重要になるでしょう。\n\n> 今すぐカスタムコンプライアンスフレームワークをお試しになりたい場合は、[GitLab Ultimateの60日間無料トライアル](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)にぜひお申し込みください。\n\n## 関連リンク\n\n以下のリソースで、カスタムコンプライアンスフレームワークの詳細や、そのメリットについてご覧いただけます。\n\n* [カスタムコンプライアンスフレームワークのドキュメント](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)  \n* [カスタムコンプライアンスフレームワークに関するエピック](https://gitlab.com/groups/gitlab-org/-/epics/13295)  \n* [セキュリティポリシーに関するドキュメント](https://docs.gitlab.com/user/application_security/policies/)  \n* [GitLabのセキュリティおよびコンプライアンスソリューション](https://about.gitlab.com/ja-jp/solutions/security-compliance/)",[777,798,796,797,766],{"slug":1142,"featured":91,"template":801},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"content":1144,"config":1153},{"title":1145,"description":1146,"authors":1147,"heroImage":1148,"date":1149,"body":1150,"category":777,"tags":1151},"GitLab + HackerOneでアプリケーションセキュリティを強化","GitLabとHackerOne社のパートナーシップの詳細と、組織のアプリケーションセキュリティ対策状況を強化するインテグレーションを簡単に導入する方法をご紹介します。",[1136],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","2025-04-03","開発プロセスにおいて、セキュリティはもはや後回しにできるものではありません。組織には、ソフトウェア開発ライフサイクル全体にセキュリティを統合できる堅牢なソリューションが求められています。ここで、HackerOne社とGitLabのパートナーシップが、現代のアプリケーション開発チームにとって魅力的な組み合わせとなります。\n\nGitLabはAI搭載の包括的なDevSecOpsプラットフォームであり、HackerOneは業界をリードするクラウドソーシング型セキュリティプラットフォームです。この2社がパートナーシップを結び、GitLabの効率的なDevSecOpsワークフローと、HackerOneの強力な脆弱性管理機能という両者の強みを融合させました。\n\nこのチュートリアルでは、HackerOneのGitLabインテグレーションを実装することで、デベロッパーの生産性とセキュリティ対策状況を強化する方法を説明します。\n\n## デベロッパーを支援するインテグレーション\n\nHackerOneのGitLabインテグレーションは、非常にシンプルでありながら強力です。セキュリティ研究者がHackerOneのプラットフォーム上で脆弱性を発見すると、その情報で自動的にGitLabのイシューが作成されます。これにより、以下のようなシームレスなワークフローが実現します。\n\n* セキュリティ研究者がHackerOneのプラットフォームで脆弱性を特定\n* 検証済みの脆弱性について自動的にGitLabのイシューが作成される\n* 開発チームは既存のワークフロー内でこれらのイシューに直接対応できる\n* 解決状況は両プラットフォーム間で同期される\n\nこの[インテグレーション](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)を使うことで、GitLabイシューをHackerOne上の参照として追跡でき、GitLabとHackerOneの強みをすぐに取り入れることができます。このインテグレーションにより、HackerOneのレポートとGitLabイシュー間で双方向かつシームレスなデータ同期が可能となり、開発チームとセキュリティチームの連携が強化され、セキュリティの脆弱性への対応が効率化します。\n\nHackerOneレポートとGitLabイシュー間で情報を同期するには、[HackerOneのGitLabインテグレーションのドキュメント](https://docs.hackerone.com/en/articles/10394699-gitlab-setup)に従って設定を行ってください。このドキュメントでは、以下の手順が解説されています。\n\n1. HackerOneの設定に基づいた[OAuth 2.0アプリケーション](https://docs.gitlab.com/ee/integration/oauth_provider.html)をGitLabインスタンス上に作成する\n2. HackerOneと新たに作成したGitLabのOAuth 2.0を接続する\n3. GitLab APIへのアクセスをHackerOneに許可する \n4. HackerOneレポートをエスカレーションするGitLabプロジェクトを設定する\n5. HackerOneの各フィールドをGitLabの対応するフィールドにマッピングする\n6. GitLabからHackerOne、およびHackerOneからGitLabへのイベントを設定する\n\nインテグレーションを完了すると、GitLabとHackerOneの間でデータが双方向にシームレスに同期されます。これにより、コンテキストの切り替えが簡素化され、両方のシステムで脆弱性を簡単に追跡できるようになります。このインテグレーションにより、次の機能が使用できます。\n\n* **HackerOneからGitLabイシューを作成：**HackerOneで受け取ったレポートに基づき、新しいGitLabイシューを作成できます。\n* **HackerOneレポートを既存のGitLabタスクにリンク**   \n* **HackerOneからGitLabへの更新内容の同期：** レポートの以下の更新情報がGitLabのコメントとして同期されます。\n   * レポートのコメント\n  * ステータスの変更  \n  * 報酬情報\n  * 担当者の変更\n  * 公開設定の変更\n  * GitLabイシューのクローズ\n* **GitLabからHackerOneへの更新内容の同期：** GitLabの以下の更新情報がHackerOneの関連レポートの内部コメントとして反映されます。 \n  * コメント \n  * ステータスの変更\n* **HackerOneの重大度とGitLabラベルのマッピング：** レポートをGitLabにエスカレーションする際、カスタムの優先度を設定できます。 \n* **期限のマッピング：** レポートの重大度に基づいて、自動で期限を設定できます。\n\n![GitLab + HackerOneによる、GitLabでのレポートへのコメント追加およびステータス変更](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\nこれらの機能により、開発チームとセキュリティチームの連携がよりスムーズになり、効率よくセキュリティの脆弱性に対応できます。インテグレーションの仕組みについてさらに詳しく知りたい場合は、[インテグレーションドキュメント](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)をご覧ください。\n\n## HackerOne社のバグバウンティプログラムについて\n\nHackerOne社は、顧客のソフトウェアシステム、Webサイト、またはアプリケーションに存在する脆弱性を発見・報告することで報酬が得られる、バグバウンティプログラムやサイバーセキュリティ施策を提供しています。バグバウンティプログラムは、アプリケーションのセキュリティを強化する上で、以下のような役割を果たします。\n\n* 悪意ある攻撃者に悪用される前にセキュリティ上の欠陥を特定する\n* 世界中のセキュリティ研究者による多様な専門知識を活用する\n* コスト効率の高いサイバーセキュリティ強化手段を提供する\n* 社内のセキュリティ対策や従来型のペネトレーションテストを補完する\n\nGitLabはHackerOne社のバグバウンティプログラムを活用しており、セキュリティ研究者はGitLabのアプリケーションやインフラにおける脆弱性を報告できます。このクラウドソーシングによるアプローチにより、GitLabは潜在的なセキュリティ問題をより効果的に特定し、対処できます。\n\n![HackerOne社のGitLabバグバウンティページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\nHackerOneのプラットフォームと世界中のハッカーコミュニティを活用することで、組織はセキュリティ対策状況を大幅に強化し、脆弱性をより迅速に特定し、潜在的な脅威に先手を打つことができます。\n\n## GitLabでアプリケーションを保護し、効率性を向上させる\n\nGitLabは、セキュリティおよびコンプライアンスツールを含む、ソフトウェア開発ライフサイクル全体をカバーする完全なDevSecOpsプラットフォームを提供しています。GitLabは、以下の種類のセキュリティスキャナーに対応しています。\n- 静的アプリケーションセキュリティテスト（SAST）\n- 動的アプリケーションセキュリティテスト（DAST）\n- コンテナスキャン\n- 依存関係スキャン\n- Infrastructure as Codeスキャン\n- カバレッジガイド付きファジング\n- Web APIファジング\n\nGitLabを使えば、CI/CDパイプラインの定義ファイルにテンプレートを追加するだけで、セキュリティスキャンを導入できます。たとえば、SASTを有効にするには、.gitlab-ci.ymlファイルに数行のコードを追加するだけです。\n\n```yaml\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nこれにより、testステージでSASTが実行され、アプリケーションで[使用されている言語を自動で検出](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)します。そして、マージリクエストが作成されるたびに、SASTがフィーチャーブランチとターゲットブランチ間の差分にある脆弱性を検出し、それぞれの脆弱性に関する修正のためのデータを提供します。\n\n![マージリクエストで検出されたNoSQLインジェクションの脆弱性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\nSASTスキャナーの結果は、セキュリティポリシーが適用されている場合、コードのマージをブロックすることができます。GitLabのネイティブユーザーを承認者として設定でき、脆弱なコードがマージされる前に必ずレビューを行うようにできます。これにより、すべての脆弱性が適切な関係者によって確認される体制が整います。\n\n![マージリクエストの承認ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\nHackerOneは、オペレーションおよび開発プロセスにおいてGitLabを複数の重要な方法で統合しており、それにより開発プロセスの改善、スケーラビリティの向上、チーム間のコラボレーションの強化を実現しています。こうした改善によって、デプロイがより迅速になり、チームプランニングもスムーズになります。\n\n## HackerOneのGitLabインテグレーションの主な利点\n\nHackerOneとGitLabを組み合わせて活用することで、以下のような主なメリットがあります。\n\n* **セキュリティの可視性向上：** デベロッパーは、普段の作業環境から離れることなく、セキュリティ上の脆弱性を即座に把握できます。リアルタイムで認識できるので、機能開発と並行してセキュリティ問題に優先順位を付けて対応できます。\n* **修正プロセスの効率化：** HackerOneのレポートを直接GitLabイシューに変換することで、修正作業が標準の開発サイクルに組み込まれます。プラットフォームを行き来する際の頭の切り替えを減らし、セキュリティ修正を他の開発作業と一緒に追跡できます。\n* **修正までの時間を短縮：** このインテグレーションにより、脆弱性の発見から解決までの時間が大幅に短縮されます。HackerOneからの報告が即座にGitLabで確認できるため、デベロッパーは遅延なく修正に着手でき、全体的なセキュリティ対策状況の強化にもつながります。\n* **コラボレーションの改善：** セキュリティ研究者、セキュリティチーム、デベロッパーがこのインテグレーションを通じてより効果的に連携できます。コメントや更新情報が両プラットフォーム間でやり取りされ、セキュリティ強化に向けた協力体制が整います。\n* **実際の導入効果：** HackerOneとGitLabのインテグレーションを導入した組織では、以下のような成果が報告されています。\n  * 脆弱性の発見から修正までの時間が最大70%短縮\n  * デベロッパーが慣れ親しんだ作業環境のまま対応できることによる満足度の向上\n  * 組織全体でのセキュリティ可視性の向上\n  * セキュリティリソースのより効果的な活用\n\n> [インテグレーション設定ページ](https://docs.hackerone.com/en/articles/10394699-gitlab-setup)にアクセスして、今日から導入を始めましょう。\n\n## 関連リンク\n\nGitLabとHackerOneの詳細、およびセキュリティ対策状況の強化については、以下のリソースをご覧ください。\n* [HackerOneのGitLabインテグレーションの使用方法](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)  \n* [HackerOneのGitLabバグバウンティプログラム](https://hackerone.com/gitlab?type=team)\n* [GitLabのセキュリティおよびコンプライアンスソリューション](https://about.gitlab.com/ja-jp/solutions/security-compliance/)  \n* [HackerOne社は、GitLabにビルトインされたセキュリティにより、デプロイ速度を5倍まで高めることに成功](https://about.gitlab.com/ja-jp/customers/hackerone/)  \n* [GitLabアプリケーションセキュリティドキュメント](https://docs.gitlab.com/ee/user/application_security/)\n",[777,798,234,285,796,715,1152],"bug bounty",{"slug":1154,"featured":6,"template":801},"enhance-application-security-with-gitlab-hackerone",{"content":1156,"config":1159},{"title":1096,"description":1097,"body":1098,"category":766,"tags":1157,"authors":1158,"heroImage":1103,"date":1088},[285,766,109,715],[1101,1102],{"featured":91,"template":801,"slug":1105},[1161,1166,1171],{"content":1162,"config":1165},{"heroImage":1084,"body":1085,"authors":1163,"updatedDate":1087,"date":1088,"title":1089,"tags":1164,"description":1091,"category":766},[908],[1017,839,766,109],{"featured":6,"template":801,"slug":1093},{"content":1167,"config":1170},{"title":969,"description":970,"authors":1168,"date":973,"body":974,"category":731,"heroImage":975,"tags":1169},[972],[109,977,978,715,797,979,777,798],{"featured":91,"template":801,"slug":981},{"content":1172,"config":1175},{"title":1010,"description":1011,"authors":1173,"heroImage":1013,"date":1014,"body":1015,"category":743,"tags":1174},[908],[1017,715,839,766,777,743,280,234,841,925,1018,270],{"slug":1020,"featured":6,"template":801},[1177,1182,1187],{"content":1178,"config":1181},{"heroImage":831,"body":832,"authors":1179,"updatedDate":835,"date":836,"title":837,"tags":1180,"description":842,"category":683},[834],[839,796,840,766,797,285,841,798],{"featured":91,"template":801,"slug":844},{"content":1183,"config":1186},{"title":1108,"description":1109,"authors":1184,"heroImage":1112,"date":836,"body":1113,"category":766,"tags":1185},[1111],[1115,766,743,796],{"slug":1117,"featured":91,"template":801},{"content":1188,"config":1191},{"title":933,"description":934,"authors":1189,"heroImage":937,"date":836,"body":938,"category":719,"tags":1190},[936],[715,796,766],{"slug":941,"featured":6,"template":801},1751548625910]