[{"data":1,"prerenderedAt":800},["ShallowReactive",2],{"/ja-jp/blog/categories/engineering":3,"navigation-ja-jp":21,"banner-ja-jp":442,"footer-ja-jp":452,"engineering-category-page-total-items-ja-jp":688,"engineering-category-page-featured-ja-jp":689,"engineering-category-page-1-ja-jp":724},{"id":4,"title":5,"body":6,"category":6,"config":7,"content":11,"description":6,"extension":13,"meta":14,"navigation":15,"path":16,"seo":17,"slug":6,"stem":19,"testContent":6,"type":6,"__hash__":20},"blogCategories/ja-jp/blog/categories/engineering.yml","Engineering",null,{"template":8,"slug":9,"hide":10},"BlogCategory","engineering",false,{"name":12},"エンジニアリング","yml",{},true,"/ja-jp/blog/categories/engineering",{"title":12,"description":18},"Browse articles related to エンジニアリング on the GitLab Blog","ja-jp/blog/categories/engineering","SP1p0HNY-4BlLIVgrET9_T9CAStAMizH3Ee46PrhOa0",{"logo":22,"freeTrial":27,"sales":32,"login":37,"items":42,"search":362,"minimal":395,"duo":412,"switchNav":421,"pricingDeployment":432},{"config":23},{"href":24,"dataGaName":25,"dataGaLocation":26},"/ja-jp/","gitlab logo","header",{"text":28,"config":29},"無料トライアルを開始",{"href":30,"dataGaName":31,"dataGaLocation":26},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":33,"config":34},"お問い合わせ",{"href":35,"dataGaName":36,"dataGaLocation":26},"/ja-jp/sales/","sales",{"text":38,"config":39},"サインイン",{"href":40,"dataGaName":41,"dataGaLocation":26},"https://gitlab.com/users/sign_in/","sign in",[43,72,174,179,282,343],{"text":44,"config":45,"menu":47},"プラットフォーム",{"dataNavLevelOne":46},"platform",{"type":48,"columns":49},"cards",[50,56,64],{"title":44,"description":51,"link":52},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":53,"config":54},"プラットフォームを探索",{"href":55,"dataGaName":46,"dataGaLocation":26},"/ja-jp/platform/",{"title":57,"description":58,"link":59},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":60,"config":61},"GitLab Duoのご紹介",{"href":62,"dataGaName":63,"dataGaLocation":26},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":65,"description":66,"link":67},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":68,"config":69},"詳細はこちら",{"href":70,"dataGaName":71,"dataGaLocation":26},"/ja-jp/why-gitlab/","why gitlab",{"text":73,"left":15,"config":74,"menu":76},"製品",{"dataNavLevelOne":75},"solutions",{"type":77,"link":78,"columns":82,"feature":153},"lists",{"text":79,"config":80},"すべてのソリューションを表示",{"href":81,"dataGaName":75,"dataGaLocation":26},"/ja-jp/solutions/",[83,108,131],{"title":84,"description":85,"link":86,"items":91},"自動化","CI/CDと自動化でデプロイを加速",{"config":87},{"icon":88,"href":89,"dataGaName":90,"dataGaLocation":26},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[92,96,99,104],{"text":93,"config":94},"CI/CD",{"href":95,"dataGaLocation":26,"dataGaName":93},"/ja-jp/solutions/continuous-integration/",{"text":57,"config":97},{"href":62,"dataGaLocation":26,"dataGaName":98},"gitlab duo agent platform - product menu",{"text":100,"config":101},"ソースコード管理",{"href":102,"dataGaLocation":26,"dataGaName":103},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":105,"config":106},"自動化されたソフトウェアデリバリー",{"href":89,"dataGaLocation":26,"dataGaName":107},"Automated software delivery",{"title":109,"description":110,"link":111,"items":116},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":112},{"href":113,"dataGaName":114,"dataGaLocation":26,"icon":115},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[117,121,126],{"text":118,"config":119},"アプリケーションセキュリティテスト",{"href":113,"dataGaName":120,"dataGaLocation":26},"Application security testing",{"text":122,"config":123},"ソフトウェアサプライチェーンの安全性",{"href":124,"dataGaLocation":26,"dataGaName":125},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":127,"config":128},"ソフトウェアコンプライアンス",{"href":129,"dataGaName":130,"dataGaLocation":26},"/ja-jp/solutions/software-compliance/","software compliance",{"title":132,"link":133,"items":138},"測定",{"config":134},{"icon":135,"href":136,"dataGaName":137,"dataGaLocation":26},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[139,143,148],{"text":140,"config":141},"可視性と測定",{"href":136,"dataGaLocation":26,"dataGaName":142},"Visibility and Measurement",{"text":144,"config":145},"バリューストリーム管理",{"href":146,"dataGaLocation":26,"dataGaName":147},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":149,"config":150},"分析とインサイト",{"href":151,"dataGaLocation":26,"dataGaName":152},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":154,"type":77,"items":155},"GitLabが活躍する場所",[156,162,168],{"text":157,"config":158},"エンタープライズ",{"icon":159,"href":160,"dataGaLocation":26,"dataGaName":161},"Building","/ja-jp/enterprise/","enterprise",{"text":163,"config":164},"スモールビジネス",{"icon":165,"href":166,"dataGaLocation":26,"dataGaName":167},"Work","/ja-jp/small-business/","small business",{"text":169,"config":170},"公共部門",{"icon":171,"href":172,"dataGaLocation":26,"dataGaName":173},"Organization","/ja-jp/solutions/public-sector/","public sector",{"text":175,"config":176},"価格",{"href":177,"dataGaName":178,"dataGaLocation":26,"dataNavLevelOne":178},"/ja-jp/pricing/","pricing",{"text":180,"config":181,"menu":183},"リソース",{"dataNavLevelOne":182},"resources",{"type":77,"link":184,"columns":188,"feature":268},{"text":185,"config":186},"すべてのリソースを表示",{"href":187,"dataGaName":182,"dataGaLocation":26},"/ja-jp/resources/",[189,222,240],{"title":190,"items":191},"はじめに",[192,197,202,207,212,217],{"text":193,"config":194},"インストール",{"href":195,"dataGaName":196,"dataGaLocation":26},"/ja-jp/install/","install",{"text":198,"config":199},"クイックスタートガイド",{"href":200,"dataGaName":201,"dataGaLocation":26},"/ja-jp/get-started/","quick setup checklists",{"text":203,"config":204},"学ぶ",{"href":205,"dataGaLocation":26,"dataGaName":206},"https://university.gitlab.com/","learn",{"text":208,"config":209},"製品ドキュメント",{"href":210,"dataGaName":211,"dataGaLocation":26},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":213,"config":214},"ベストプラクティスビデオ",{"href":215,"dataGaName":216,"dataGaLocation":26},"/ja-jp/getting-started-videos/","best practice videos",{"text":218,"config":219},"インテグレーション",{"href":220,"dataGaName":221,"dataGaLocation":26},"/ja-jp/integrations/","integrations",{"title":223,"items":224},"検索する",[225,230,235],{"text":226,"config":227},"お客様成功事例",{"href":228,"dataGaName":229,"dataGaLocation":26},"/ja-jp/customers/","customer success stories",{"text":231,"config":232},"ブログ",{"href":233,"dataGaName":234,"dataGaLocation":26},"/ja-jp/blog/","blog",{"text":236,"config":237},"リモート",{"href":238,"dataGaName":239,"dataGaLocation":26},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":241,"items":242},"つなげる",[243,248,253,258,263],{"text":244,"config":245},"GitLabサービス",{"href":246,"dataGaName":247,"dataGaLocation":26},"/ja-jp/services/","services",{"text":249,"config":250},"コミュニティ",{"href":251,"dataGaName":252,"dataGaLocation":26},"/community/","community",{"text":254,"config":255},"フォーラム",{"href":256,"dataGaName":257,"dataGaLocation":26},"https://forum.gitlab.com/","forum",{"text":259,"config":260},"イベント",{"href":261,"dataGaName":262,"dataGaLocation":26},"/events/","events",{"text":264,"config":265},"パートナー",{"href":266,"dataGaName":267,"dataGaLocation":26},"/ja-jp/partners/","partners",{"config":269,"text":272,"image":273,"link":277},{"background":270,"textColor":271},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":274,"config":275},"ソースプロモカード",{"src":276},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":278,"config":279},"最新情報を読む",{"href":280,"dataGaName":281,"dataGaLocation":26},"/ja-jp/the-source/","the source",{"text":283,"config":284,"menu":286},"会社情報",{"dataNavLevelOne":285},"company",{"type":77,"columns":287},[288],{"items":289},[290,295,301,303,308,313,318,323,328,333,338],{"text":291,"config":292},"GitLabについて",{"href":293,"dataGaName":294,"dataGaLocation":26},"/ja-jp/company/","about",{"text":296,"config":297,"footerGa":300},"採用情報",{"href":298,"dataGaName":299,"dataGaLocation":26},"/jobs/","jobs",{"dataGaName":299},{"text":259,"config":302},{"href":261,"dataGaName":262,"dataGaLocation":26},{"text":304,"config":305},"経営陣",{"href":306,"dataGaName":307,"dataGaLocation":26},"/company/team/e-group/","leadership",{"text":309,"config":310},"チーム",{"href":311,"dataGaName":312,"dataGaLocation":26},"/company/team/","team",{"text":314,"config":315},"ハンドブック",{"href":316,"dataGaName":317,"dataGaLocation":26},"https://handbook.gitlab.com/","handbook",{"text":319,"config":320},"投資家向け情報",{"href":321,"dataGaName":322,"dataGaLocation":26},"https://ir.gitlab.com/","investor relations",{"text":324,"config":325},"トラストセンター",{"href":326,"dataGaName":327,"dataGaLocation":26},"/ja-jp/security/","trust center",{"text":329,"config":330},"AI Transparency Center",{"href":331,"dataGaName":332,"dataGaLocation":26},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":334,"config":335},"ニュースレター",{"href":336,"dataGaName":337,"dataGaLocation":26},"/company/contact/#contact-forms","newsletter",{"text":339,"config":340},"プレス",{"href":341,"dataGaName":342,"dataGaLocation":26},"/press/","press",{"text":33,"config":344,"menu":345},{"dataNavLevelOne":285},{"type":77,"columns":346},[347],{"items":348},[349,352,357],{"text":33,"config":350},{"href":35,"dataGaName":351,"dataGaLocation":26},"talk to sales",{"text":353,"config":354},"サポートを受ける",{"href":355,"dataGaName":356,"dataGaLocation":26},"https://support.gitlab.com","support portal",{"text":358,"config":359},"カスタマーポータル",{"href":360,"dataGaName":361,"dataGaLocation":26},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":363,"login":364,"suggestions":371},"閉じる",{"text":365,"link":366},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":367,"config":368},"GitLab.com",{"href":40,"dataGaName":369,"dataGaLocation":370},"search login","search",{"text":372,"default":373},"提案",[374,376,381,383,387,391],{"text":57,"config":375},{"href":62,"dataGaName":57,"dataGaLocation":370},{"text":377,"config":378},"コード提案（AI）",{"href":379,"dataGaName":380,"dataGaLocation":370},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":93,"config":382},{"href":95,"dataGaName":93,"dataGaLocation":370},{"text":384,"config":385},"GitLab on AWS",{"href":386,"dataGaName":384,"dataGaLocation":370},"/ja-jp/partners/technology-partners/aws/",{"text":388,"config":389},"GitLab on Google Cloud",{"href":390,"dataGaName":388,"dataGaLocation":370},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":392,"config":393},"GitLabを選ぶ理由",{"href":70,"dataGaName":394,"dataGaLocation":370},"Why GitLab?",{"freeTrial":396,"mobileIcon":400,"desktopIcon":405,"secondaryButton":408},{"text":28,"config":397},{"href":398,"dataGaName":31,"dataGaLocation":399},"https://gitlab.com/-/trials/new/","nav",{"altText":401,"config":402},"GitLabアイコン",{"src":403,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":401,"config":406},{"src":407,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":190,"config":409},{"href":410,"dataGaName":411,"dataGaLocation":399},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":413,"mobileIcon":417,"desktopIcon":419},{"text":414,"config":415},"GitLab Duoの詳細について",{"href":62,"dataGaName":416,"dataGaLocation":399},"gitlab duo",{"altText":401,"config":418},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":420},{"src":407,"dataGaName":404,"dataGaLocation":399},{"button":422,"mobileIcon":427,"desktopIcon":429},{"text":423,"config":424},"/switch",{"href":425,"dataGaName":426,"dataGaLocation":399},"#contact","switch",{"altText":401,"config":428},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":430},{"src":431,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":433,"mobileIcon":438,"desktopIcon":440},{"text":434,"config":435},"価格ページに戻る",{"href":177,"dataGaName":436,"dataGaLocation":399,"icon":437},"back to pricing","GoBack",{"altText":401,"config":439},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":441},{"src":407,"dataGaName":404,"dataGaLocation":399},{"title":443,"button":444,"config":449},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":445,"config":446},"6月10日のGitLab Transcendに申し込む",{"href":447,"dataGaName":448,"dataGaLocation":26},"/ja-jp/releases/whats-new/#sign-up","transcend event",{"layout":450,"icon":451,"disabled":10},"release","AiStar",{"data":453},{"text":454,"source":455,"edit":461,"contribute":466,"config":471,"items":476,"minimal":679},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":456,"config":457},"ページのソースを表示",{"href":458,"dataGaName":459,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":462,"config":463},"このページを編集",{"href":464,"dataGaName":465,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":467,"config":468},"ご協力をお願いします",{"href":469,"dataGaName":470,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":472,"facebook":473,"youtube":474,"linkedin":475},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[477,522,575,618,645],{"title":175,"links":478,"subMenu":493},[479,483,488],{"text":480,"config":481},"プランの表示",{"href":177,"dataGaName":482,"dataGaLocation":460},"view plans",{"text":484,"config":485},"Premiumを選ぶ理由",{"href":486,"dataGaName":487,"dataGaLocation":460},"/ja-jp/pricing/premium/","why premium",{"text":489,"config":490},"Ultimateを選ぶ理由",{"href":491,"dataGaName":492,"dataGaLocation":460},"/ja-jp/pricing/ultimate/","why ultimate",[494],{"title":33,"links":495},[496,498,500,502,507,512,517],{"text":33,"config":497},{"href":35,"dataGaName":36,"dataGaLocation":460},{"text":353,"config":499},{"href":355,"dataGaName":356,"dataGaLocation":460},{"text":358,"config":501},{"href":360,"dataGaName":361,"dataGaLocation":460},{"text":503,"config":504},"ステータス",{"href":505,"dataGaName":506,"dataGaLocation":460},"https://status.gitlab.com/","status",{"text":508,"config":509},"利用規約",{"href":510,"dataGaName":511,"dataGaLocation":460},"/terms/","terms of use",{"text":513,"config":514},"プライバシーに関する声明",{"href":515,"dataGaName":516,"dataGaLocation":460},"/ja-jp/privacy/","privacy statement",{"text":518,"config":519},"Cookie 優先設定",{"dataGaName":520,"dataGaLocation":460,"id":521,"isOneTrustButton":15},"cookie preferences","ot-sdk-btn",{"title":73,"links":523,"subMenu":532},[524,528],{"text":525,"config":526},"DevSecOpsプラットフォーム",{"href":55,"dataGaName":527,"dataGaLocation":460},"devsecops platform",{"text":529,"config":530},"AI支援開発",{"href":62,"dataGaName":531,"dataGaLocation":460},"ai-assisted development",[533],{"title":534,"links":535},"トピック",[536,540,545,550,555,560,565,570],{"text":93,"config":537},{"href":538,"dataGaName":539,"dataGaLocation":460},"/ja-jp/topics/ci-cd/","cicd",{"text":541,"config":542},"GitOps",{"href":543,"dataGaName":544,"dataGaLocation":460},"/ja-jp/topics/gitops/","gitops",{"text":546,"config":547},"DevOps",{"href":548,"dataGaName":549,"dataGaLocation":460},"/ja-jp/topics/devops/","devops",{"text":551,"config":552},"バージョン管理",{"href":553,"dataGaName":554,"dataGaLocation":460},"/ja-jp/topics/version-control/","version control",{"text":556,"config":557},"DevSecOps",{"href":558,"dataGaName":559,"dataGaLocation":460},"/ja-jp/topics/devsecops/","devsecops",{"text":561,"config":562},"クラウドネイティブ",{"href":563,"dataGaName":564,"dataGaLocation":460},"/ja-jp/topics/cloud-native/","cloud native",{"text":566,"config":567},"コーディングのためのAI",{"href":568,"dataGaName":569,"dataGaLocation":460},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":571,"config":572},"エージェント型AI",{"href":573,"dataGaName":574,"dataGaLocation":460},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":576,"links":577},"ソリューション",[578,581,583,588,592,595,598,601,603,605,608,613],{"text":118,"config":579},{"href":113,"dataGaName":580,"dataGaLocation":460},"Application Security Testing",{"text":105,"config":582},{"href":89,"dataGaName":90,"dataGaLocation":460},{"text":584,"config":585},"アジャイル開発",{"href":586,"dataGaName":587,"dataGaLocation":460},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":589,"config":590},"SCM",{"href":102,"dataGaName":591,"dataGaLocation":460},"source code management",{"text":93,"config":593},{"href":95,"dataGaName":594,"dataGaLocation":460},"continuous integration & delivery",{"text":144,"config":596},{"href":146,"dataGaName":597,"dataGaLocation":460},"value stream management",{"text":541,"config":599},{"href":600,"dataGaName":544,"dataGaLocation":460},"/ja-jp/solutions/gitops/",{"text":157,"config":602},{"href":160,"dataGaName":161,"dataGaLocation":460},{"text":163,"config":604},{"href":166,"dataGaName":167,"dataGaLocation":460},{"text":606,"config":607},"公共機関",{"href":172,"dataGaName":173,"dataGaLocation":460},{"text":609,"config":610},"教育",{"href":611,"dataGaName":612,"dataGaLocation":460},"/ja-jp/solutions/education/","education",{"text":614,"config":615},"金融サービス",{"href":616,"dataGaName":617,"dataGaLocation":460},"/ja-jp/solutions/finance/","financial services",{"title":180,"links":619},[620,622,624,626,629,631,633,635,637,639,641,643],{"text":193,"config":621},{"href":195,"dataGaName":196,"dataGaLocation":460},{"text":198,"config":623},{"href":200,"dataGaName":201,"dataGaLocation":460},{"text":203,"config":625},{"href":205,"dataGaName":206,"dataGaLocation":460},{"text":208,"config":627},{"href":210,"dataGaName":628,"dataGaLocation":460},"docs",{"text":231,"config":630},{"href":233,"dataGaName":234,"dataGaLocation":460},{"text":226,"config":632},{"href":228,"dataGaName":229,"dataGaLocation":460},{"text":236,"config":634},{"href":238,"dataGaName":239,"dataGaLocation":460},{"text":244,"config":636},{"href":246,"dataGaName":247,"dataGaLocation":460},{"text":249,"config":638},{"href":251,"dataGaName":252,"dataGaLocation":460},{"text":254,"config":640},{"href":256,"dataGaName":257,"dataGaLocation":460},{"text":259,"config":642},{"href":261,"dataGaName":262,"dataGaLocation":460},{"text":264,"config":644},{"href":266,"dataGaName":267,"dataGaLocation":460},{"title":283,"links":646},[647,649,651,653,655,657,659,663,668,670,672,674],{"text":291,"config":648},{"href":293,"dataGaName":285,"dataGaLocation":460},{"text":296,"config":650},{"href":298,"dataGaName":299,"dataGaLocation":460},{"text":304,"config":652},{"href":306,"dataGaName":307,"dataGaLocation":460},{"text":309,"config":654},{"href":311,"dataGaName":312,"dataGaLocation":460},{"text":314,"config":656},{"href":316,"dataGaName":317,"dataGaLocation":460},{"text":319,"config":658},{"href":321,"dataGaName":322,"dataGaLocation":460},{"text":660,"config":661},"Sustainability",{"href":662,"dataGaName":660,"dataGaLocation":460},"/sustainability/",{"text":664,"config":665},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":666,"dataGaName":667,"dataGaLocation":460},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":324,"config":669},{"href":326,"dataGaName":327,"dataGaLocation":460},{"text":334,"config":671},{"href":336,"dataGaName":337,"dataGaLocation":460},{"text":339,"config":673},{"href":341,"dataGaName":342,"dataGaLocation":460},{"text":675,"config":676},"現代奴隷制の透明性に関する声明",{"href":677,"dataGaName":678,"dataGaLocation":460},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":680},[681,683,686],{"text":508,"config":682},{"href":510,"dataGaName":511,"dataGaLocation":460},{"text":684,"config":685},"Cookieの設定",{"dataGaName":520,"dataGaLocation":460,"id":521,"isOneTrustButton":15},{"text":513,"config":687},{"href":515,"dataGaName":516,"dataGaLocation":460},29,{"id":690,"title":691,"authorSlugs":692,"authors":695,"body":698,"category":9,"categorySlug":9,"config":699,"content":702,"date":706,"description":710,"extension":13,"externalUrl":6,"featured":15,"heroImage":703,"isFeatured":15,"meta":711,"navigation":15,"path":712,"publishedDate":706,"rawbody":713,"seo":714,"slug":701,"stem":720,"tagSlugs":721,"tags":722,"template":700,"updatedDate":705,"__hash__":723},"blogPosts/ja-jp/blog/migration-from-azure-devops-to-gitlab.yml","ガイド: Azure DevOpsからGitLabへの移行",[693,694],"evgeny-rudinsky","michael-leopard",[696,697],"Evgeny Rudinsky","Michael Leopard","Azure DevOpsからGitLabへの移行は困難な作業のように思えるかもしれませんが、適切なアプローチとツールを使用すれば、スムーズかつ効率的に進められます。このガイドでは、Azure DevOpsからGitLabへプロジェクト、リポジトリ、パイプラインを正常に移行するために必要な手順を説明します。\n\n## 概要\n\nGitLabは、Azure DevOps（ADO）からプロジェクトを移行するための[Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)([GitLabプロフェッショナルサービス（PS）](https://about.gitlab.com/ja-jp/professional-services/)によって管理）と[組み込みのGitリポジトリインポート](https://docs.gitlab.com/ja-jp/user/project/import/repo_by_url/)の両方を提供しています。これらのオプションは、リポジトリごとまたは一括移行をサポートし、Gitコミット履歴、ブランチ、タグを保持します。Congregateとプロフェッショナルサービスのツールを使用すると、Wiki、作業アイテム、CI/CD変数、コンテナイメージ、パッケージ、パイプラインなどの追加アセットもサポートされます（この[機能マトリクス](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)を参照）。このガイドを参照すれば、移行を計画・実行し、移行後のフォローアップタスクを完了できます。\n\nADOからGitLabへ移行する企業は、一般的に複数フェーズのアプローチに従います：\n\n* CongregateまたはGitLabの組み込みリポジトリ移行を使用して、ADOからGitLabにリポジトリを移行します。\n* AzureパイプラインからGitLab CI/CDにパイプラインを移行します。\n* ボード、作業アイテム、アーティファクトなどの残りのアセットを、GitLabのイシュー、エピック、パッケージレジストリ、コンテナレジストリに移行します。\n\n移行フェーズの概要:\n\n```mermaid\ngraph LR\n    subgraph Prerequisites\n        direction TB\n        A[\"IDプロバイダー（IdP）を設定し\u003Cbr/>ユーザーをプロビジョニング\"]\n        A --> B[\"Runnerとサードパーティ\u003Cbr/>インテグレーションを設定\"]\n        B --> I[\"ユーザーの有効化と\u003Cbr/>変更管理\"]\n    end\n    \n    subgraph MigrationPhase[\"移行フェーズ\"]\n        direction TB\n        C[\"ソースコードを移行\"]\n        C --> D[\"コントリビューションを保持し\u003Cbr/>履歴をフォーマット\"]\n        D --> E[\"作業アイテムを移行し\u003Cbr/>\u003Ca href=\"https://docs.gitlab.com/ja-jp/topics/plan_and_track/\">GitLab Plan\u003Cbr/>および作業追跡\u003C/a>にマッピング\"]\n    end\n    \n    subgraph PostMigration[\"移行後の手順\"]\n        direction TB\n        F[\"ADOパイプラインを\u003Cbr/>GitLab CIに作成または変換\"]\n        F --> G[\"その他のアセット、パッケージ、\u003Cbr/>コンテナイメージを移行\"]\n        G --> H[\"\u003Ca href=\"https://docs.gitlab.com/ja-jp/user/application_security/secure_your_application/\">セキュリティ\u003C/a>と\u003Cbr/>SDLC改善を導入\"]\n    end\n    \n    Prerequisites --> MigrationPhase\n    MigrationPhase --> PostMigration\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style I fill:#FC6D26\n    style C fill:#8C929D\n    style D fill:#8C929D\n    style E fill:#8C929D\n    style F fill:#FFA500\n    style G fill:#FFA500\n    style H fill:#FFA500\n```\n\n## 移行の計画\n\n**移行を計画するにあたり、次の質問を検討します:**\n\n* 移行をいつまでに完了する必要があるか?\n* 何が移行されるかを理解しているか?\n* 誰が移行を実行するか?\n* GitLabでどのような組織構造を望むか?\n* 考慮すべき制約、制限、落とし穴はあるか?\n\nタイムラインを決定します。これは移行アプローチを大きく左右します。ADOとGitLabの両プラットフォームに精通したチャンピオンやグループ（アーリーアダプターなど）を特定し、導入を推進してアドバイスを提供してもらいます。\n\n**移行が必要なものをインベントリ化:**\n\n* リポジトリ、プルリクエスト、コントリビューターの数\n* 作業アイテムとパイプラインの数と複雑さ\n* リポジトリのサイズと依存関係\n* 重要なインテグレーションとRunner要件（特定の機能を持つエージェントプール）\n\nGitLab プロフェッショナルサービスの[Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)ツールを使用して、リポジトリ、PR数、コントリビューターリスト、パイプライン数、作業アイテム、CI/CD変数などを含むAzure DevOps組織全体の完全なインベントリを作成します。GitLabプロフェッショナルサービスチームと連携している場合は、このレポートをエンゲージメントマネージャーまたはテクニカルアーキテクトと共有し、移行計画に役立ててください。\n\n移行のタイミングは、主にプルリクエスト数、リポジトリサイズ、コントリビューション量（PRのコメント、作業アイテムなど）によって決まります。たとえば、PRが少なくコントリビューターが限られた1,000の小規模リポジトリは、数万のPRと数千のコントリビューターを含む少数のリポジトリよりもはるかに高速に移行できます。インベントリデータを使用して作業量を見積もり、本番移行を進める前にテスト実行を計画します。\n\nインベントリを希望のタイムラインと比較し、すべてのリポジトリを一度に移行するか、バッチで移行するかを決定します。チームが同時に移行できない場合は、チームのスケジュールに合わせて移行をバッチ化し、段階的に実行します。たとえば、プロフェッショナルサービスのエンゲージメントでは、複雑さを管理し、[GitLab](https://docs.gitlab.com/ja-jp/security/rate_limits/)と[ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)の両方のAPIレート制限を尊重するために、200〜300プロジェクト単位の段階に分割して移行を実施します。\n\nGitLabの組み込み[リポジトリインポーター](https://docs.gitlab.com/ja-jp/user/project/import/repo_by_url/)は、Gitリポジトリ（コミット、ブランチ、タグ）を1つずつ移行します。Congregateは、可能な限りプルリクエスト（GitLabではマージリクエストとして知られています）、コメント、関連メタデータを保持するように設計されています。シンプルな組み込みリポジトリインポートは、Gitデータ（履歴、ブランチ、タグ）のみに焦点を当てています。\n\n**通常、個別の移行または手動での再作成が必要な項目:**\n\n* Azureパイプライン - 同等のGitLab CI/CDパイプラインを作成([CI/CD YAML](https://docs.gitlab.com/ja-jp/ci/yaml/)または[CI/CDコンポーネント](https://docs.gitlab.com/ja-jp/ci/components/)を参照)。または、CongregateのAIベースのパイプライン変換を使用することを検討してください。\n* 作業アイテムとボード - GitLabのイシュー、エピック、イシュー ボードにマッピング。\n* アーティファクト、コンテナイメージ(ACR) - GitLabパッケージレジストリまたはコンテナレジストリに移行。\n* サービスフックと外部インテグレーション - GitLabで再作成。\n* [権限モデル](https://docs.gitlab.com/ja-jp/user/permissions/)はADOとGitLabで異なります。完全な保持を想定するのではなく、権限マッピングを確認および計画してください。\n\n各ツール（Congregateと組み込みインポート）が何を移行するかを確認し、ニーズに合ったものを選択します。手動で移行または再作成する必要があるデータやインテグレーションのリストを作成します。\n\n**誰が移行を実行するか?**\n\n移行は通常、GitLabグループオーナーまたはインスタンス管理者、または移行先グループ/プロジェクトに必要な権限を付与された指定の移行担当者によって実行されます。CongregateとGitLabインポートAPIには、Azure DevOpsとGitLabの両方の有効な認証トークンが必要です。\n\n* グループオーナー/管理者が移行を実行するか、特定のチーム/個人に委任アクセスを付与するかを決定します。\n* 移行担当者が、選択した移行ツールに必要なスコープ（api/read_repositoryスコープやツール固有の要件など）を持つ個人アクセストークン（Azure DevOpsとGitLab）を正しく設定していることを確認します。\n* 小規模なパイロット移行でトークンと権限をテストします。\n\n**注:** CongregateはADO移行のためにファイルベースのインポート機能を活用し、実行にはインスタンス管理者権限が必要です（[ドキュメントを参照](https://docs.gitlab.com/ja-jp/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)）。GitLab.comに移行する場合は、プロフェッショナルサービスの利用を検討してください。詳細については、[Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)を参照してください。管理者以外のアカウントでは、コントリビューションの帰属を保持できません。\n\n**GitLabでどのような組織構造を望むか?**\n\nADO構造をGitLab構造に直接マッピングすることは可能ですが、移行中に構造を合理化および簡素化することをお勧めします。チームがGitLabでどのように作業するかを検討し、コラボレーションとアクセス管理を促進する構造を設計します。ADO構造をGitLab構造にマッピングする方法は次のとおりです。\n\n```mermaid\ngraph TD\n    subgraph GitLab\n        direction TB\n        A[\"トップレベルグループ\"]\n        B[\"サブグループ（オプション）\"]\n        C[\"プロジェクト\"]\n        A --> B\n        A --> C\n        B --> C\n    end\n\n    subgraph AzureDevOps[\"Azure DevOps\"]\n        direction TB\n        F[\"組織\"]\n        G[\"プロジェクト\"]\n        H[\"リポジトリ\"]\n        F --> G\n        G --> H\n    end\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style C fill:#FC6D26\n    style F fill:#8C929D\n    style G fill:#8C929D\n    style H fill:#8C929D\n```\n\n推奨アプローチ:\n\n* 各ADO組織をGitLabグループ（または少数のグループ）にマッピングし、多数の小さなグループには分割しないでください。ADOチームプロジェクトごとにGitLabグループを作成することは避けてください。移行をGitLab構造を合理化する機会として活用してください。\n* サブグループとプロジェクトレベルの権限を使用して、関連リポジトリをグループ化します。\n* GitLabグループとグループメンバーシップ（グループとサブグループ）を使用してプロジェクトのセットへのアクセスを管理し、チームプロジェクトごとに1つのグループを作成しないでください。\n* GitLabの[権限](https://docs.gitlab.com/ja-jp/user/permissions/)を確認し、[SAML Group Links](https://docs.gitlab.com/ja-jp/user/group/saml_sso/group_sync/)を検討して、GitLabインスタンス（またはGitLab.comネームスペース）のエンタープライズRBACモデルを実装します。\n\n**ADOボードと作業アイテム: 移行の状態**\n\n作業アイテムがADOからGitLab Plan（イシュー、エピック、ボード）にどのように移行されるかを理解することが重要です。\n\n* ADOボードと作業アイテムは、GitLabのイシュー、エピック、イシューボードにマッピングされます。ワークフローとボード設定がどのように変換されるかを計画します。\n* ADOのエピックと機能は、GitLabのエピックになります。\n* その他の作業アイテムタイプ（ユーザーストーリー、タスク、バグなど）は、プロジェクトスコープのイシューになります。\n* ほとんどの標準フィールドが保持されます。サポートされている場合、選択したカスタムフィールドを移行できます。\n* 親子関係が保持されるため、エピックはすべての関連イシューを参照します。\n* プルリクエストへのリンクはマージリクエストリンクに変換され、開発のトレーサビリティが維持されます。\n\n例: 個別の作業アイテムのGitLabイシューへの移行（フィールドの正確性と関係性を含む）:\n\n![例: 個別の作業アイテムのGitLabイシューへの移行](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\nバッチ処理のガイダンス:\n\n* バッチで移行を実行する必要がある場合は、新しいグループ/サブグループ構造を使用してバッチを定義します（たとえば、ADO組織ごと、または製品領域ごと）。\n* インベントリレポートを使用してバッチ選択を推進し、スケールアップする前に各バッチをパイロット移行でテストします。\n\n**パイプライン移行**\n\nCongregateは最近、Azure DevOpsからGitLab CI/CDへのマルチステージYAMLパイプラインのAI搭載変換を[導入しました](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298)。この自動変換は、シンプルな単一ファイルパイプラインに最適で、本番環境対応の`.gitlab-ci.yml`ファイルではなく、動作する出発点を提供するように設計されています。このツールは、機能的に同等のGitLabパイプラインを生成し、その後特定のニーズに合わせて調整および最適化できます。\n\n* Azureパイプライン YAMLを`.gitlab-ci.yml`形式に自動変換します。\n* シンプルな単一ファイルパイプライン設定に最適です。\n* 移行を加速するためのボイラープレートを提供し、最終的な本番環境アーティファクトではありません。\n* 複雑なシナリオ、カスタムタスク、エンタープライズ要件については、レビューや調整が必要です。\n* Azure DevOpsのクラシックリリースパイプラインはサポートしていません — 最初に[マルチステージYAMLに変換](https://learn.microsoft.com/en-us/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops)してください。\n\nリポジトリオーナーは、初期変換後にパイプラインをさらに最適化および強化するために、[GitLab CI/CDドキュメント](https://docs.gitlab.com/ja-jp/ci/)を確認する必要があります。\n\n変換されたパイプラインの例:\n\n```yml\n# azure-pipelines.yml\n\ntrigger:\n  - main\n\nvariables:\n  imageName: myapp\n\nstages:\n  - stage: Build\n    jobs:\n      - job: Build\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Build Docker image\n            inputs:\n              command: build\n              repository: $(imageName)\n              Dockerfile: '**/Dockerfile'\n              tags: |\n                $(Build.BuildId)\n\n  - stage: Test\n    jobs:\n      - job: Test\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          # Example: run tests inside the container\n          - script: |\n              docker run --rm $(imageName):$(Build.BuildId) npm test\n            displayName: Run tests\n\n  - stage: Push\n    jobs:\n      - job: Push\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Login to ACR\n            inputs:\n              command: login\n              containerRegistry: '\u003Cyour-acr-service-connection>'\n\n          - task: Docker@2\n            displayName: Push image to ACR\n            inputs:\n              command: push\n              repository: $(imageName)\n              tags: |\n                $(Build.BuildId)\n```\n\n```yaml\n# .gitlab-ci.yml\n\nvariables:\n  imageName: myapp\n\nstages:\n  - build\n  - test\n  - push\n\nbuild:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n  only:\n    - main\n\ntest:\n  stage: test\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n  only:\n    - main\n\npush:\n  stage: push\n  image: docker:latest\n  services:\n    - docker:dind\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n  only:\n    - main\n```\n\n**最終チェックリスト:**\n\n* タイムラインとバッチ戦略を決定します。\n* リポジトリ、PR、コントリビューターの完全なインベントリを作成します。\n* スコープ（PRとメタデータ vs Gitデータのみ）に基づいて、Congregateまたは組み込みインポートを選択します。\n* 誰が移行を実行するかを決定し、トークン/権限が設定されていることを確認します。\n* 個別に移行する必要があるアセット（パイプライン、作業アイテム、アーティファクト、フック）を特定し、それらの取り組みを計画します。\n* パイロット移行を実行し、結果を検証してから、計画に従ってスケールします。\n\n## 移行の実行\n\n計画後、トライアル実行から始めて、段階的に移行を実行します。トライアル移行は、組織固有の問題を早期に明らかにし、期間を測定し、結果を検証し、本番環境前にアプローチを微調整する上で役立ちます。\n\nトライアル移行が検証する内容:\n\n* 特定のリポジトリと関連アセットが正常に移行されるかどうか（履歴、ブランチ、タグ。Congregateを使用する場合はMR/コメントも含む）\n* 移行先がすぐに使用可能かどうか（権限、Runner、CI/CD変数、インテグレーション）\n* スケジュールとステークホルダーの期待値を設定するため、各バッチにかかる時間。\n\nダウンタイムのガイダンス:\n\n* GitLabの組み込みGitインポートとCongregateは、本質的にダウンタイムを必要としません。\n* 本番環境の場合では、ADOの変更を凍結（ブランチ保護または読み取り専用）して、移行中に見逃されたコミット、PR更新、作業アイテムの作成を回避します。\n* トライアル実行では凍結は必要なく、いつでも実行できます。\n\nバッチ処理のガイダンス:\n\n* 経過時間を短縮するために、トライアルバッチを連続して実行します。チームは非同期で結果を検証できます。\n* 計画したグループ/サブグループ構造を使用してバッチを定義し、APIレート制限を遵守します。\n\n推奨手順:\n\n1. GitLabでトライアル用のテスト先を作成:\n\n* GitLab.com: 専用グループ/ネームスペースを作成（例: my-org-sandbox）\n* Self-managed: トップレベルグループまたは必要に応じて別のテストインスタンスを作成\n\n2. 認証の準備:\n\n* 必要なスコープを持つAzure DevOps PAT\n* apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）```suggestion:-0+0\n* apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）\n\n3. トライアル移行の実行:\n\n* リポジトリのみ: GitLabの組み込みインポート（URLによるレポジトリインポート）を使用\n* リポジトリ + PR/MRおよび追加アセット: Congregateを使用\n\n4. トライアル後のフォローアップ:\n\n* リポジトリ履歴、ブランチ、タグ、マージリクエスト（移行された場合）、イシュー/エピック（移行された場合）、ラベル、関係性を確認します。\n* 権限/ロール、保護ブランチ、必要な承認、Runner/タグ、変数/シークレット、インテグレーション/Webhookを確認します。\n* パイプライン（`.gitlab-ci.yml`）または（該当する場合は）変換されたパイプラインを検証します。\n\n5. ユーザーに機能とデータの正確性を検証してもらいます。\n6. トライアル中に発見された問題を解決し、実行手順を更新します。\n7. ネットワークとセキュリティ:\n\n* 移行先の環境がIP許可リストを使用している場合、インポートが成功するように、移行ホストと必要なRunner/インテグレーションのIPを追加します。\n\n8. 本番環境への移行は段階的に実行:\n\n* 各段階で、ADOで変更凍結を実施します。\n* 進捗とログを監視します。レート制限に達した場合は、再試行するか、バッチサイズを調整します。\n\n9. オプション: 完了後、サンドボックスグループを削除またはアーカイブします。\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## GitLabとAzure DevOpsの用語リファレンス\n\n| GitLab                                      | Azure DevOps                     | 類似点と主な違い                                                                        |\n| ------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------- |\n| グループ                                        | 組織                               | トップレベルのネームスペース、メンバーシップ、ポリシー。ADO組織にはプロジェクトが含まれ、GitLabグループにはサブグループとプロジェクトが含まれます。  |\n| グループまたはサブグループ                               | プロジェクト                           | 論理コンテナ、権限境界。ADOプロジェクトは多数のリポジトリを保持し、GitLabグループ/サブグループは多数のプロジェクトを整理します。           |\n| Project（Gitリポジトリを含む）                        | リポジトリ（プロジェクト内）                   | Git履歴、ブランチ、タグ。GitLabでは、「プロジェクト」はリポジトリとイシュー、CI/CD、Wikiなどを含みます。プロジェクトごとに1つのリポジトリ。 |\n| マージリクエスト（MR）                                | プルリクエスト（PR）                      | コードレビュー、ディスカッション、承認。MRルールには、承認、必要なパイプライン、コードオーナーが含まれます。                         |\n| 保護されたブランチ、MR承認ルール、ステータスチェック                 | ブランチポリシー                         | レビューとチェックを強制。GitLabは保護 + 承認ルール + 必要なステータスチェックを組み合わせます。                          |\n| GitLab CI/CD                                | Azureパイプライン                      | YAMLパイプライン、ステージ/ジョブ、ログ。ADOにはクラシックUIパイプラインもあり、GitLabは.gitlab-ci.ymlを中心にしています。    |\n| .gitlab-ci.yml                              | azure-pipelines.yml              | ステージ/ジョブ/トリガーを定義。構文/機能が異なります。ジョブ、変数、アーティファクト、トリガーをマッピングします。                     |\n| Runner（共有/特定）                               | エージェント/エージェントプール                 | マシン/コンテナでジョブを実行。デマンド（ADO）対タグ（GitLab）でターゲット。登録/スコーピングが異なります。                     |\n| CI/CD変数（プロジェクト/グループ/インスタンス）、保護/マスク          | パイプライン変数、変数グループ、ライブラリ            | 設定/シークレットをジョブに渡します。GitLabはグループ継承とマスキング/保護フラグをサポートします。                           |\n| インテグレーション、CI/CD変数、デプロイキー                    | サービス接続                           | サービス/クラウドへの外部認証。インテグレーションまたは変数にマッピング。クラウド固有のヘルパーが利用可能。                          |\n| 環境とデプロイメント（保護された環境）                         | 環境（承認付き）                         | デプロイターゲット/履歴を追跡。GitLabでは保護された環境と手動ジョブを介した承認。                                    |\n| リリース（タグ + ノート）                              | リリース（クラシックまたはパイプライン）             | バージョン管理されたノート/アーティファクト。GitLabリリースはタグに結び付けられ、デプロイメントは個別に追跡されます。                  |\n| ジョブアーティファクト                                 | パイプラインアーティファクト                   | ジョブ出力を保持。保持/有効期限はジョブまたはプロジェクトごとに設定されます。                                         |\n| パッケージレジストリ（NuGet/npm/Maven/PyPI/Composerなど） | Azureアーティファクト（NuGet/npm/Mavenなど） | パッケージホスティング。認証/ネームスペースが異なります。パッケージタイプごとに移行します。                                  |\n| GitLabコンテナレジストリ                             | Azureコンテナレジストリ（ACR）または他          | OCIイメージ。GitLabはプロジェクト/グループごとのレジストリを提供します。                                       |\n| イシューボード                                     | ボード                              | 列で作業を視覚化。GitLabボードはラベル駆動型で、プロジェクト/グループごとに複数のボードがあります。                           |\n| イシュー（タイプ/ラベル）、エピック                          | 作業アイテム（ユーザーストーリー/バグ/タスク）         | 作業単位を追跡。ADOタイプ/フィールドをラベル/カスタムフィールドにマッピング。エピックはグループレベルです。                        |\n| エピック、親子イシュー                                 | エピック/機能                          | 作業の階層。スキーマが異なります。エピックとイシュー関係を使用します。                                             |\n| マイルストーンとイテレーション                             | イテレーションパス                        | タイムボックス化。GitLabイテレーション（グループ機能）またはプロジェクト/グループごとのマイルストーン。                         |\n| ラベル（スコープ付きラベル）                              | エリアパス                            | 分類/所有権。階層エリアをスコープ付きラベルに置き換えます。                                                  |\n| プロジェクト/グループWiki                             | プロジェクトWiki                       | マークダウンWiki。両方ともリポジトリでバックアップされます。レイアウト/認証がわずかに異なります。                             |\n| CI経由のテストレポート、要件/テスト管理、インテグレーション             | テストプラン/ケース/実行                    | QA証拠/トレーサビリティ。ADOテストプランとの1対1対応はありません。多くの場合、CIレポート + イシュー/要件を使用します。              |\n| ロール（オーナー/メンテナー/デベロッパー/レポーター/ゲスト） + カスタムロール  | アクセスレベル + きめ細かい権限                | 読み取り/書き込み/管理を制御。モデルが異なります。グループ継承と保護されたリソースを活用します。                               |\n| Webhook                                     | サービスフック                          | イベント駆動型インテグレーション。イベント名/ペイロードが異なります。エンドポイントを再設定します。                              |\n| 高度な検索                                       | コードサーチ                           | フルテキストリポジトリ検索。Self-managed版のGitLabでは、高度な機能にElasticsearch/OpenSearchが必要な場合があります。 |",{"featured":15,"template":700,"slug":701},"BlogPost","migration-from-azure-devops-to-gitlab",{"heroImage":703,"body":698,"authors":704,"updatedDate":705,"date":706,"title":691,"tags":707,"description":710,"category":9},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[696,697],"2025-12-08","2025-12-03",[708,709,93],"tutorial","git","GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabへの完全な移行を実行する方法を学びます — 計画、実行から移行後のフォローアップタスクまで。",{},"/ja-jp/blog/migration-from-azure-devops-to-gitlab","seo:\n  ogTitle: Azure DevOpsからGitLabへの移行ガイド\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png\n  ogDescription:\n    GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabに完全に移行する方法を学びます\n    — 計画、実行から移行後のフォローアップタスクまでカバーします。\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  ogUrl: https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab\n  title: Azure DevOpsからGitLabへの移行ガイド\n  canonicalUrls: https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab\n  description:\n    GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabに完全に移行する方法を学びます —\n    計画、実行から移行後のフォローアップタスクまでカバーします。\ncontent:\n  heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png\n  body: >-\n    Azure\n    DevOpsからGitLabへの移行は困難な作業のように思えるかもしれませんが、適切なアプローチとツールを使用すれば、スムーズかつ効率的に進められます。このガイドでは、Azure\n    DevOpsからGitLabへプロジェクト、リポジトリ、パイプラインを正常に移行するために必要な手順を説明します。\n\n\n    ## 概要\n\n\n    GitLabは、Azure DevOps（ADO）からプロジェクトを移行するための[Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)([GitLabプロフェッショナルサービス（PS）](https://about.gitlab.com/ja-jp/professional-services/)によって管理）と[組み込みのGitリポジトリインポート](https://docs.gitlab.com/ja-jp/user/project/import/repo_by_url/)の両方を提供しています。これらのオプションは、リポジトリごとまたは一括移行をサポートし、Gitコミット履歴、ブランチ、タグを保持します。Congregateとプロフェッショナルサービスのツールを使用すると、Wiki、作業アイテム、CI/CD変数、コンテナイメージ、パッケージ、パイプラインなどの追加アセットもサポートされます（この[機能マトリクス](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)を参照）。このガイドを参照すれば、移行を計画・実行し、移行後のフォローアップタスクを完了できます。\n\n\n    ADOからGitLabへ移行する企業は、一般的に複数フェーズのアプローチに従います：\n\n\n    * CongregateまたはGitLabの組み込みリポジトリ移行を使用して、ADOからGitLabにリポジトリを移行します。\n\n    * AzureパイプラインからGitLab CI/CDにパイプラインを移行します。\n\n    * ボード、作業アイテム、アーティファクトなどの残りのアセットを、GitLabのイシュー、エピック、パッケージレジストリ、コンテナレジストリに移行します。\n\n\n    移行フェーズの概要:\n\n\n    ```mermaid\n\n    graph LR\n        subgraph Prerequisites\n            direction TB\n            A[\"IDプロバイダー（IdP）を設定し\u003Cbr/>ユーザーをプロビジョニング\"]\n            A --> B[\"Runnerとサードパーティ\u003Cbr/>インテグレーションを設定\"]\n            B --> I[\"ユーザーの有効化と\u003Cbr/>変更管理\"]\n        end\n        \n        subgraph MigrationPhase[\"移行フェーズ\"]\n            direction TB\n            C[\"ソースコードを移行\"]\n            C --> D[\"コントリビューションを保持し\u003Cbr/>履歴をフォーマット\"]\n            D --> E[\"作業アイテムを移行し\u003Cbr/>\u003Ca href=\"https://docs.gitlab.com/ja-jp/topics/plan_and_track/\">GitLab Plan\u003Cbr/>および作業追跡\u003C/a>にマッピング\"]\n        end\n        \n        subgraph PostMigration[\"移行後の手順\"]\n            direction TB\n            F[\"ADOパイプラインを\u003Cbr/>GitLab CIに作成または変換\"]\n            F --> G[\"その他のアセット、パッケージ、\u003Cbr/>コンテナイメージを移行\"]\n            G --> H[\"\u003Ca href=\"https://docs.gitlab.com/ja-jp/user/application_security/secure_your_application/\">セキュリティ\u003C/a>と\u003Cbr/>SDLC改善を導入\"]\n        end\n        \n        Prerequisites --> MigrationPhase\n        MigrationPhase --> PostMigration\n\n        style A fill:#FC6D26\n        style B fill:#FC6D26\n        style I fill:#FC6D26\n        style C fill:#8C929D\n        style D fill:#8C929D\n        style E fill:#8C929D\n        style F fill:#FFA500\n        style G fill:#FFA500\n        style H fill:#FFA500\n    ```\n\n\n    ## 移行の計画\n\n\n    **移行を計画するにあたり、次の質問を検討します:**\n\n\n    * 移行をいつまでに完了する必要があるか?\n\n    * 何が移行されるかを理解しているか?\n\n    * 誰が移行を実行するか?\n\n    * GitLabでどのような組織構造を望むか?\n\n    * 考慮すべき制約、制限、落とし穴はあるか?\n\n\n    タイムラインを決定します。これは移行アプローチを大きく左右します。ADOとGitLabの両プラットフォームに精通したチャンピオンやグループ（アーリーアダプターなど）を特定し、導入を推進してアドバイスを提供してもらいます。\n\n\n    **移行が必要なものをインベントリ化:**\n\n\n    * リポジトリ、プルリクエスト、コントリビューターの数\n\n    * 作業アイテムとパイプラインの数と複雑さ\n\n    * リポジトリのサイズと依存関係\n\n    * 重要なインテグレーションとRunner要件（特定の機能を持つエージェントプール）\n\n\n    GitLab プロフェッショナルサービスの[Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)ツールを使用して、リポジトリ、PR数、コントリビューターリスト、パイプライン数、作業アイテム、CI/CD変数などを含むAzure DevOps組織全体の完全なインベントリを作成します。GitLabプロフェッショナルサービスチームと連携している場合は、このレポートをエンゲージメントマネージャーまたはテクニカルアーキテクトと共有し、移行計画に役立ててください。\n\n\n    移行のタイミングは、主にプルリクエスト数、リポジトリサイズ、コントリビューション量（PRのコメント、作業アイテムなど）によって決まります。たとえば、PRが少なくコントリビューターが限られた1,000の小規模リポジトリは、数万のPRと数千のコントリビューターを含む少数のリポジトリよりもはるかに高速に移行できます。インベントリデータを使用して作業量を見積もり、本番移行を進める前にテスト実行を計画します。\n\n\n    インベントリを希望のタイムラインと比較し、すべてのリポジトリを一度に移行するか、バッチで移行するかを決定します。チームが同時に移行できない場合は、チームのスケジュールに合わせて移行をバッチ化し、段階的に実行します。たとえば、プロフェッショナルサービスのエンゲージメントでは、複雑さを管理し、[GitLab](https://docs.gitlab.com/ja-jp/security/rate_limits/)と[ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)の両方のAPIレート制限を尊重するために、200〜300プロジェクト単位の段階に分割して移行を実施します。\n\n\n    GitLabの組み込み[リポジトリインポーター](https://docs.gitlab.com/ja-jp/user/project/import/repo_by_url/)は、Gitリポジトリ（コミット、ブランチ、タグ）を1つずつ移行します。Congregateは、可能な限りプルリクエスト（GitLabではマージリクエストとして知られています）、コメント、関連メタデータを保持するように設計されています。シンプルな組み込みリポジトリインポートは、Gitデータ（履歴、ブランチ、タグ）のみに焦点を当てています。\n\n\n    **通常、個別の移行または手動での再作成が必要な項目:**\n\n\n    * Azureパイプライン - 同等のGitLab CI/CDパイプラインを作成([CI/CD YAML](https://docs.gitlab.com/ja-jp/ci/yaml/)または[CI/CDコンポーネント](https://docs.gitlab.com/ja-jp/ci/components/)を参照)。または、CongregateのAIベースのパイプライン変換を使用することを検討してください。\n\n    * 作業アイテムとボード - GitLabのイシュー、エピック、イシュー ボードにマッピング。\n\n    * アーティファクト、コンテナイメージ(ACR) - GitLabパッケージレジストリまたはコンテナレジストリに移行。\n\n    * サービスフックと外部インテグレーション - GitLabで再作成。\n\n    * [権限モデル](https://docs.gitlab.com/ja-jp/user/permissions/)はADOとGitLabで異なります。完全な保持を想定するのではなく、権限マッピングを確認および計画してください。\n\n\n    各ツール（Congregateと組み込みインポート）が何を移行するかを確認し、ニーズに合ったものを選択します。手動で移行または再作成する必要があるデータやインテグレーションのリストを作成します。\n\n\n    **誰が移行を実行するか?**\n\n\n    移行は通常、GitLabグループオーナーまたはインスタンス管理者、または移行先グループ/プロジェクトに必要な権限を付与された指定の移行担当者によって実行されます。CongregateとGitLabインポートAPIには、Azure DevOpsとGitLabの両方の有効な認証トークンが必要です。\n\n\n    * グループオーナー/管理者が移行を実行するか、特定のチーム/個人に委任アクセスを付与するかを決定します。\n\n    * 移行担当者が、選択した移行ツールに必要なスコープ（api/read_repositoryスコープやツール固有の要件など）を持つ個人アクセストークン（Azure DevOpsとGitLab）を正しく設定していることを確認します。\n\n    * 小規模なパイロット移行でトークンと権限をテストします。\n\n\n    **注:** CongregateはADO移行のためにファイルベースのインポート機能を活用し、実行にはインスタンス管理者権限が必要です（[ドキュメントを参照](https://docs.gitlab.com/ja-jp/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)）。GitLab.comに移行する場合は、プロフェッショナルサービスの利用を検討してください。詳細については、[Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)を参照してください。管理者以外のアカウントでは、コントリビューションの帰属を保持できません。\n\n\n    **GitLabでどのような組織構造を望むか?**\n\n\n    ADO構造をGitLab構造に直接マッピングすることは可能ですが、移行中に構造を合理化および簡素化することをお勧めします。チームがGitLabでどのように作業するかを検討し、コラボレーションとアクセス管理を促進する構造を設計します。ADO構造をGitLab構造にマッピングする方法は次のとおりです。\n\n\n    ```mermaid\n\n    graph TD\n        subgraph GitLab\n            direction TB\n            A[\"トップレベルグループ\"]\n            B[\"サブグループ（オプション）\"]\n            C[\"プロジェクト\"]\n            A --> B\n            A --> C\n            B --> C\n        end\n\n        subgraph AzureDevOps[\"Azure DevOps\"]\n            direction TB\n            F[\"組織\"]\n            G[\"プロジェクト\"]\n            H[\"リポジトリ\"]\n            F --> G\n            G --> H\n        end\n\n        style A fill:#FC6D26\n        style B fill:#FC6D26\n        style C fill:#FC6D26\n        style F fill:#8C929D\n        style G fill:#8C929D\n        style H fill:#8C929D\n    ```\n\n\n    推奨アプローチ:\n\n\n    * 各ADO組織をGitLabグループ（または少数のグループ）にマッピングし、多数の小さなグループには分割しないでください。ADOチームプロジェクトごとにGitLabグループを作成することは避けてください。移行をGitLab構造を合理化する機会として活用してください。\n\n    * サブグループとプロジェクトレベルの権限を使用して、関連リポジトリをグループ化します。\n\n    * GitLabグループとグループメンバーシップ（グループとサブグループ）を使用してプロジェクトのセットへのアクセスを管理し、チームプロジェクトごとに1つのグループを作成しないでください。\n\n    * GitLabの[権限](https://docs.gitlab.com/ja-jp/user/permissions/)を確認し、[SAML Group Links](https://docs.gitlab.com/ja-jp/user/group/saml_sso/group_sync/)を検討して、GitLabインスタンス（またはGitLab.comネームスペース）のエンタープライズRBACモデルを実装します。\n\n\n    **ADOボードと作業アイテム: 移行の状態**\n\n\n    作業アイテムがADOからGitLab Plan（イシュー、エピック、ボード）にどのように移行されるかを理解することが重要です。\n\n\n    * ADOボードと作業アイテムは、GitLabのイシュー、エピック、イシューボードにマッピングされます。ワークフローとボード設定がどのように変換されるかを計画します。\n\n    * ADOのエピックと機能は、GitLabのエピックになります。\n\n    * その他の作業アイテムタイプ（ユーザーストーリー、タスク、バグなど）は、プロジェクトスコープのイシューになります。\n\n    * ほとんどの標準フィールドが保持されます。サポートされている場合、選択したカスタムフィールドを移行できます。\n\n    * 親子関係が保持されるため、エピックはすべての関連イシューを参照します。\n\n    * プルリクエストへのリンクはマージリクエストリンクに変換され、開発のトレーサビリティが維持されます。\n\n\n    例: 個別の作業アイテムのGitLabイシューへの移行（フィールドの正確性と関係性を含む）:\n\n\n    ![例: 個別の作業アイテムのGitLabイシューへの移行](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\n\n    バッチ処理のガイダンス:\n\n\n    * バッチで移行を実行する必要がある場合は、新しいグループ/サブグループ構造を使用してバッチを定義します（たとえば、ADO組織ごと、または製品領域ごと）。\n\n    * インベントリレポートを使用してバッチ選択を推進し、スケールアップする前に各バッチをパイロット移行でテストします。\n\n\n    **パイプライン移行**\n\n\n    Congregateは最近、Azure DevOpsからGitLab CI/CDへのマルチステージYAMLパイプラインのAI搭載変換を[導入しました](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298)。この自動変換は、シンプルな単一ファイルパイプラインに最適で、本番環境対応の`.gitlab-ci.yml`ファイルではなく、動作する出発点を提供するように設計されています。このツールは、機能的に同等のGitLabパイプラインを生成し、その後特定のニーズに合わせて調整および最適化できます。\n\n\n    * Azureパイプライン YAMLを`.gitlab-ci.yml`形式に自動変換します。\n\n    * シンプルな単一ファイルパイプライン設定に最適です。\n\n    * 移行を加速するためのボイラープレートを提供し、最終的な本番環境アーティファクトではありません。\n\n    * 複雑なシナリオ、カスタムタスク、エンタープライズ要件については、レビューや調整が必要です。\n\n    * Azure DevOpsのクラシックリリースパイプラインはサポートしていません — 最初に[マルチステージYAMLに変換](https://learn.microsoft.com/en-us/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops)してください。\n\n\n    リポジトリオーナーは、初期変換後にパイプラインをさらに最適化および強化するために、[GitLab CI/CDドキュメント](https://docs.gitlab.com/ja-jp/ci/)を確認する必要があります。\n\n\n    変換されたパイプラインの例:\n\n\n    ```yml\n\n    # azure-pipelines.yml\n\n\n    trigger:\n      - main\n\n    variables:\n      imageName: myapp\n\n    stages:\n      - stage: Build\n        jobs:\n          - job: Build\n            pool:\n              vmImage: 'ubuntu-latest'\n            steps:\n              - checkout: self\n\n              - task: Docker@2\n                displayName: Build Docker image\n                inputs:\n                  command: build\n                  repository: $(imageName)\n                  Dockerfile: '**/Dockerfile'\n                  tags: |\n                    $(Build.BuildId)\n\n      - stage: Test\n        jobs:\n          - job: Test\n            pool:\n              vmImage: 'ubuntu-latest'\n            steps:\n              - checkout: self\n\n              # Example: run tests inside the container\n              - script: |\n                  docker run --rm $(imageName):$(Build.BuildId) npm test\n                displayName: Run tests\n\n      - stage: Push\n        jobs:\n          - job: Push\n            pool:\n              vmImage: 'ubuntu-latest'\n            steps:\n              - checkout: self\n\n              - task: Docker@2\n                displayName: Login to ACR\n                inputs:\n                  command: login\n                  containerRegistry: '\u003Cyour-acr-service-connection>'\n\n              - task: Docker@2\n                displayName: Push image to ACR\n                inputs:\n                  command: push\n                  repository: $(imageName)\n                  tags: |\n                    $(Build.BuildId)\n    ```\n\n\n    ```yaml\n\n    # .gitlab-ci.yml\n\n\n    variables:\n      imageName: myapp\n\n    stages:\n      - build\n      - test\n      - push\n\n    build:\n      stage: build\n      image: docker:latest\n      services:\n        - docker:dind\n      script:\n        - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n      only:\n        - main\n\n    test:\n      stage: test\n      image: docker:latest\n      services:\n        - docker:dind\n      script:\n        - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n      only:\n        - main\n\n    push:\n      stage: push\n      image: docker:latest\n      services:\n        - docker:dind\n      before_script:\n        - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n      script:\n        - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n        - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n      only:\n        - main\n    ```\n\n\n    **最終チェックリスト:**\n\n\n    * タイムラインとバッチ戦略を決定します。\n\n    * リポジトリ、PR、コントリビューターの完全なインベントリを作成します。\n\n    * スコープ（PRとメタデータ vs Gitデータのみ）に基づいて、Congregateまたは組み込みインポートを選択します。\n\n    * 誰が移行を実行するかを決定し、トークン/権限が設定されていることを確認します。\n\n    * 個別に移行する必要があるアセット（パイプライン、作業アイテム、アーティファクト、フック）を特定し、それらの取り組みを計画します。\n\n    * パイロット移行を実行し、結果を検証してから、計画に従ってスケールします。\n\n\n    ## 移行の実行\n\n\n    計画後、トライアル実行から始めて、段階的に移行を実行します。トライアル移行は、組織固有の問題を早期に明らかにし、期間を測定し、結果を検証し、本番環境前にアプローチを微調整する上で役立ちます。\n\n\n    トライアル移行が検証する内容:\n\n\n    * 特定のリポジトリと関連アセットが正常に移行されるかどうか（履歴、ブランチ、タグ。Congregateを使用する場合はMR/コメントも含む）\n\n    * 移行先がすぐに使用可能かどうか（権限、Runner、CI/CD変数、インテグレーション）\n\n    * スケジュールとステークホルダーの期待値を設定するため、各バッチにかかる時間。\n\n\n    ダウンタイムのガイダンス:\n\n\n    * GitLabの組み込みGitインポートとCongregateは、本質的にダウンタイムを必要としません。\n\n    * 本番環境の場合では、ADOの変更を凍結（ブランチ保護または読み取り専用）して、移行中に見逃されたコミット、PR更新、作業アイテムの作成を回避します。\n\n    * トライアル実行では凍結は必要なく、いつでも実行できます。\n\n\n    バッチ処理のガイダンス:\n\n\n    * 経過時間を短縮するために、トライアルバッチを連続して実行します。チームは非同期で結果を検証できます。\n\n    * 計画したグループ/サブグループ構造を使用してバッチを定義し、APIレート制限を遵守します。\n\n\n    推奨手順:\n\n\n    1. GitLabでトライアル用のテスト先を作成:\n\n\n    * GitLab.com: 専用グループ/ネームスペースを作成（例: my-org-sandbox）\n\n    * Self-managed: トップレベルグループまたは必要に応じて別のテストインスタンスを作成\n\n\n    2. 認証の準備:\n\n\n    * 必要なスコープを持つAzure DevOps PAT\n\n    * apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）```suggestion:-0+0\n\n    * apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）\n\n\n    3. トライアル移行の実行:\n\n\n    * リポジトリのみ: GitLabの組み込みインポート（URLによるレポジトリインポート）を使用\n\n    * リポジトリ + PR/MRおよび追加アセット: Congregateを使用\n\n\n    4. トライアル後のフォローアップ:\n\n\n    * リポジトリ履歴、ブランチ、タグ、マージリクエスト（移行された場合）、イシュー/エピック（移行された場合）、ラベル、関係性を確認します。\n\n    * 権限/ロール、保護ブランチ、必要な承認、Runner/タグ、変数/シークレット、インテグレーション/Webhookを確認します。\n\n    * パイプライン（`.gitlab-ci.yml`）または（該当する場合は）変換されたパイプラインを検証します。\n\n\n    5. ユーザーに機能とデータの正確性を検証してもらいます。\n\n    6. トライアル中に発見された問題を解決し、実行手順を更新します。\n\n    7. ネットワークとセキュリティ:\n\n\n    * 移行先の環境がIP許可リストを使用している場合、インポートが成功するように、移行ホストと必要なRunner/インテグレーションのIPを追加します。\n\n\n    8. 本番環境への移行は段階的に実行:\n\n\n    * 各段階で、ADOで変更凍結を実施します。\n\n    * 進捗とログを監視します。レート制限に達した場合は、再試行するか、バッチサイズを調整します。\n\n\n    9. オプション: 完了後、サンドボックスグループを削除またはアーカイブします。\n\n\n    \u003Cfigure class=\"video_container\">\n      \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n    \u003C/figure>\n\n\n    ## GitLabとAzure DevOpsの用語リファレンス\n\n\n    | GitLab                                      | Azure DevOps                     | 類似点と主な違い                                                                        |\n\n    | ------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------- |\n\n    | グループ                                        | 組織                               | トップレベルのネームスペース、メンバーシップ、ポリシー。ADO組織にはプロジェクトが含まれ、GitLabグループにはサブグループとプロジェクトが含まれます。  |\n\n    | グループまたはサブグループ                               | プロジェクト                           | 論理コンテナ、権限境界。ADOプロジェクトは多数のリポジトリを保持し、GitLabグループ/サブグループは多数のプロジェクトを整理します。           |\n\n    | Project（Gitリポジトリを含む）                        | リポジトリ（プロジェクト内）                   | Git履歴、ブランチ、タグ。GitLabでは、「プロジェクト」はリポジトリとイシュー、CI/CD、Wikiなどを含みます。プロジェクトごとに1つのリポジトリ。 |\n\n    | マージリクエスト（MR）                                | プルリクエスト（PR）                      | コードレビュー、ディスカッション、承認。MRルールには、承認、必要なパイプライン、コードオーナーが含まれます。                         |\n\n    | 保護されたブランチ、MR承認ルール、ステータスチェック                 | ブランチポリシー                         | レビューとチェックを強制。GitLabは保護 + 承認ルール + 必要なステータスチェックを組み合わせます。                          |\n\n    | GitLab CI/CD                                | Azureパイプライン                      | YAMLパイプライン、ステージ/ジョブ、ログ。ADOにはクラシックUIパイプラインもあり、GitLabは.gitlab-ci.ymlを中心にしています。    |\n\n    | .gitlab-ci.yml                              | azure-pipelines.yml              | ステージ/ジョブ/トリガーを定義。構文/機能が異なります。ジョブ、変数、アーティファクト、トリガーをマッピングします。                     |\n\n    | Runner（共有/特定）                               | エージェント/エージェントプール                 | マシン/コンテナでジョブを実行。デマンド（ADO）対タグ（GitLab）でターゲット。登録/スコーピングが異なります。                     |\n\n    | CI/CD変数（プロジェクト/グループ/インスタンス）、保護/マスク          | パイプライン変数、変数グループ、ライブラリ            | 設定/シークレットをジョブに渡します。GitLabはグループ継承とマスキング/保護フラグをサポートします。                           |\n\n    | インテグレーション、CI/CD変数、デプロイキー                    | サービス接続                           | サービス/クラウドへの外部認証。インテグレーションまたは変数にマッピング。クラウド固有のヘルパーが利用可能。                          |\n\n    | 環境とデプロイメント（保護された環境）                         | 環境（承認付き）                         | デプロイターゲット/履歴を追跡。GitLabでは保護された環境と手動ジョブを介した承認。                                    |\n\n    | リリース（タグ + ノート）                              | リリース（クラシックまたはパイプライン）             | バージョン管理されたノート/アーティファクト。GitLabリリースはタグに結び付けられ、デプロイメントは個別に追跡されます。                  |\n\n    | ジョブアーティファクト                                 | パイプラインアーティファクト                   | ジョブ出力を保持。保持/有効期限はジョブまたはプロジェクトごとに設定されます。                                         |\n\n    | パッケージレジストリ（NuGet/npm/Maven/PyPI/Composerなど） | Azureアーティファクト（NuGet/npm/Mavenなど） | パッケージホスティング。認証/ネームスペースが異なります。パッケージタイプごとに移行します。                                  |\n\n    | GitLabコンテナレジストリ                             | Azureコンテナレジストリ（ACR）または他          | OCIイメージ。GitLabはプロジェクト/グループごとのレジストリを提供します。                                       |\n\n    | イシューボード                                     | ボード                              | 列で作業を視覚化。GitLabボードはラベル駆動型で、プロジェクト/グループごとに複数のボードがあります。                           |\n\n    | イシュー（タイプ/ラベル）、エピック                          | 作業アイテム（ユーザーストーリー/バグ/タスク）         | 作業単位を追跡。ADOタイプ/フィールドをラベル/カスタムフィールドにマッピング。エピックはグループレベルです。                        |\n\n    | エピック、親子イシュー                                 | エピック/機能                          | 作業の階層。スキーマが異なります。エピックとイシュー関係を使用します。                                             |\n\n    | マイルストーンとイテレーション                             | イテレーションパス                        | タイムボックス化。GitLabイテレーション（グループ機能）またはプロジェクト/グループごとのマイルストーン。                         |\n\n    | ラベル（スコープ付きラベル）                              | エリアパス                            | 分類/所有権。階層エリアをスコープ付きラベルに置き換えます。                                                  |\n\n    | プロジェクト/グループWiki                             | プロジェクトWiki                       | マークダウンWiki。両方ともリポジトリでバックアップされます。レイアウト/認証がわずかに異なります。                             |\n\n    | CI経由のテストレポート、要件/テスト管理、インテグレーション             | テストプラン/ケース/実行                    | QA証拠/トレーサビリティ。ADOテストプランとの1対1対応はありません。多くの場合、CIレポート + イシュー/要件を使用します。              |\n\n    | ロール（オーナー/メンテナー/デベロッパー/レポーター/ゲスト） + カスタムロール  | アクセスレベル + きめ細かい権限                | 読み取り/書き込み/管理を制御。モデルが異なります。グループ継承と保護されたリソースを活用します。                               |\n\n    | Webhook                                     | サービスフック                          | イベント駆動型インテグレーション。イベント名/ペイロードが異なります。エンドポイントを再設定します。                              |\n\n    | 高度な検索                                       | コードサーチ                           | フルテキストリポジトリ検索。Self-managed版のGitLabでは、高度な機能にElasticsearch/OpenSearchが必要な場合があります。 |\n  authors:\n    - Evgeny Rudinsky\n    - Michael Leopard\n  updatedDate: 2025-12-08\n  date: 2025-12-03\n  title: 'ガイド: Azure DevOpsからGitLabへの移行'\n  tags:\n    - tutorial\n    - git\n    - CI/CD\n  description: GitLabプロフェッショナルサービスの移行ツールを使用してAzure\n    DevOpsからGitLabへの完全な移行を実行する方法を学びます — 計画、実行から移行後のフォローアップタスクまで。\n  category: engineering\nconfig:\n  featured: true\n  template: BlogPost\n  slug: migration-from-azure-devops-to-gitlab\n",{"ogTitle":715,"ogImage":703,"ogDescription":716,"ogSiteName":717,"ogType":718,"ogUrl":719,"title":715,"canonicalUrls":719,"description":716},"Azure DevOpsからGitLabへの移行ガイド","GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabに完全に移行する方法を学びます — 計画、実行から移行後のフォローアップタスクまでカバーします。","https://about.gitlab.com","article","https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab","ja-jp/blog/migration-from-azure-devops-to-gitlab",[708,709,539],[708,709,93],"PDJOlTa7NwTT28GYQAaE_gSBJTxeVPVKjY0st5r_N7Q",[725,734,743,751,759,767,775,783,792],{"content":726,"config":732},{"title":727,"heroImage":728,"category":9,"description":729,"authors":730},"世界最大のGitLabインスタンスを1日12回デプロイする方法","https://res.cloudinary.com/about-gitlab-com/image/upload/v1764108112/tyntnsy3xotlmehtnfkb.png","GitLab.comのデプロイパイプラインを技術的に深掘りします。段階的ロールアウト、Canary戦略、データベースマイグレーション、マルチバージョン互換性について解説します。",[731],"John Skarbek",{"externalUrl":-1,"slug":733},"continuously-deploying-the-largest-gitlab-instance",{"content":735,"config":741},{"title":736,"heroImage":737,"category":9,"description":738,"authors":739},"SaaSとは？意味・読み方・PaaS/IaaSとの違い・メリットをわかりやすく解説","https://res.cloudinary.com/about-gitlab-com/image/upload/v1760421091/iaruhhz70gncm8bqfqyg.jpg","SaaSの基礎、利用するメリット・デメリット、PaaSやIaaSとの違い、ソフトウェア開発に役立つサービスなどをご紹介。ぜひお読みください。",[740],"GitLab Team",{"externalUrl":-1,"slug":742},"what-is-saas",{"content":744,"config":749},{"title":745,"heroImage":746,"category":9,"description":747,"authors":748},"AIプラットフォームとは？意味・主要機能・選び方・GitLab活用例を解説【2026年版】","https://res.cloudinary.com/about-gitlab-com/image/upload/v1759710675/bp7phtsziq0begfmoifj.jpg","AIプラットフォームの種類や機能、そのメリット・デメリットを徹底解説します。",[740],{"externalUrl":-1,"slug":750},"what-is-ai-platform",{"content":752,"config":757},{"title":753,"heroImage":754,"category":9,"description":755,"authors":756},"ロードマップとは？意味やソフトウェア開発における必要性、作り方","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758787930/roadmap_hero_e8ngpm.jpg","この記事では、ソフトウェア開発におけるロードマップの必要性やメリット、作成方法を解説します。",[740],{"externalUrl":-1,"slug":758},"what-is-roadmap",{"content":760,"config":765},{"title":761,"heroImage":762,"category":9,"description":763,"authors":764},"プラットフォームエンジニアリングとは？意味や導入メリットをわかりやすく解説","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758508254/duu6d4vclamtnnxjdaat.jpg","この記事では、プラットフォームエンジニアリングの意味や特徴、導入メリットなどを解説します。",[740],{"externalUrl":-1,"slug":766},"what-is-platform-engineering",{"content":768,"config":773},{"title":769,"heroImage":770,"category":9,"description":771,"authors":772},"ガントチャートとは？ソフトウェア開発における役割やメリット、作り方","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757988342/gqogwxai28zzwwuj2z3i.jpg","ガントチャートとは何か、作り方やメリットを詳しく解説。プロジェクト管理に役立つおすすめツールも紹介します。",[740],{"externalUrl":-1,"slug":774},"what-is-gantt-chart",{"content":776,"config":781},{"title":777,"heroImage":778,"category":9,"description":779,"authors":780},"ローカルLLMとは？開発での活用メリットと注意点","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757577836/qjcz9aubvivrn4zy1kqr.jpg","ローカルLLMの意味やクラウドLLMとの違い、ソフトウェア開発における導入メリットなどを解説します。",[740],{"externalUrl":-1,"slug":782},"what-is-local-llm",{"content":784,"config":790},{"title":785,"heroImage":786,"category":9,"description":787,"authors":788},"Gitワークフローを高速化","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098264/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_519147119_2RafH61mqosMZv8HGAlsUj_1750098264407.jpg","Git Much Fasterスクリプトがあらゆる環境でgit cloneオペレーションを最適化 — クローン時間は最大93%、ディスク使用量は最大98%削減。",[789],"Darwin Sanoy",{"externalUrl":-1,"slug":791},"supercharge-your-git-workflows",{"content":793,"config":798},{"title":794,"heroImage":795,"category":9,"description":796,"authors":797},"仮想マシン（VM）とは？意味や導入メリット、GitLab活用例","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756347347/ocydmzmnj23eitgoiwzb.jpg","この記事では、仮想マシンの基礎知識からソフトウェア開発・ITインフラの領域で導入するメリット、具体的な活用方法まで解説します。",[740],{"externalUrl":-1,"slug":799},"what-is-vm",1777934837612]