20260110_GitHub移行の現在地-ツール選定と移せないものの見極め

登壇資料:BuriKaigi 2026 タイムテーブル：2026-01-10 15:00-15:25
https://fortee.jp/burikaigi-2026/proposal/05741d76-a77a-4c31-a3ee-f7001cbcc561

■概要
生成AIの台頭により、GitHub Copilot（GHCP）の企業活用が急増しています。Copilotをセキュアかつ組織統制下で活かすには、その基盤となる GitHub Enterprise Cloud（GHEC）の整備が実質的に必須です。
現場では「試用 → 本番」や「通常アカウント → EMU（Enterprise Managed Users）」への段階移行が増加中。本セッションでは、実案件およびコミュニティでの知見（※GitHub Stars受賞者としての最新動向も踏まえ）から、GEI / GitHub Migration Analyzer / gh-repo-stats等の実運用ノウハウを整理します。
“移せる／移せない”の線引き、ガバナンスを崩さないCopilot活用の判断軸、スモールスタートの実例まで、明日から使えるチェックリストとともに解説します。

■アジェンダ
- Introduction
- 導入／背景
- 全体像：移行の進め方フレーム
- GitHub Enterprise Importer（GEI）要点
- 移行できる／できない項目の観点整理
- 解析フェーズの実務：ツール活用
- GitHub Migration Analyzer（OSS/要カスタマイズ）：何を見るか、出力の読み方
- gh-repo-stats（CLI拡張）：属性の把握
- 小さな移行例
- まとめ

Transcript

1. GitHub移行の現在地 ～ツール選定と “移せないもの”の見極め 2026.01.10 Yutaka.Osada
2. Agenda • Introduction • 導入／背景 • 全体像：移行の進め方フレーム • GitHub Enterprise Importer（GEI）要点 • 移行できる／できない項目の観点整理 • 解析フェーズの実務：ツール活用 • GitHub Migration Analyzer（OSS/要 カスタマイズ）：何を見るか、出力の読み方 • gh-repo-stats（CLI拡張）：属性の把握 • 小さな移行例 • まとめ DO WHAT MATTERS 2
3. Yutaka Osada（長田 豊） • Manager (DevOps Engineering) @Avanade Japan • Solution Architect (AI assisted SDLC & DevOps) • エンタープライズへのDevOpsソリューション（ Azure DevOps/GitHub Enterprise ）の導入・構築 • Azure PaaS × GitHub Enterpriseのオファリング開発 • 個人活動 • Zennでの記事投稿（IaC、CI/CD Pipelines Azure DevOps Rest API等） • 登壇（各種ユーザコミュニティ、および、DevOps Days Tokyo） • 書籍執筆(AZ-400の試験対策本) • GitHub Stars (Sep 2025–) • 技術スタック • C#, .NET, Azure(PaaS), Azure DevOps, GitHub • Please follow me https://github.com/yutaka-art 3 DO WHAT MATTERS
4. INTRODUCTION
5. 導入／背景 • 現状感（背景） • Azure DevOps / GitLab / JIRA からの移行に加え、GitHub → GitHub （Org再編/EMU切替）が増加。 • いきなり本番ではなく「試用で検証 → EMU本番」へ段階的移行が一般化。 • シナリオの俯瞰 DO WHAT MATTERS 5 既存ツール群 • Azure DevOps • GitLab • JIRA • GitHub 試用版Enterprise • 操作性確認 • 検証/PoC 本番Enterprise（EMU） • 運用 • 統制 • 連携 •ドライラン/差分確認 •マネキン回収/リンク整合性 /最終チェック GitHub Enterprise Cloud：通常アカウント GitHub Enterprise Cloud：Enterprise Managed Users→IdP統合を可能としたセキュアな環境
6. 全体像：移行の進め方フレーム • 計画 → 解析 → 検証 → 本番 （4ステップの”型”） DO WHAT MATTERS 6 計画 • 方針を決める • 移行計画書 解析 • 現状を可視化 • 解析レポート 検証 • 小さく試す • 差分/手順確定 本番 • 安全に切替 • 完了報告 Point 01 計画 • スコープ: Org単位? Repo単位?（優先順/除外も明記） • 停止時間(ダウンタイム)候補と告知方針 • 権限/トークン(PAT)、責務分解(誰が何をいつ) Point 02 解析 • リポジトリ規模/活動度/依存(Branches/Tags/Actions/Secrets/Pages等) • 外部連携/Apps/Runner/環境の棚卸 • 移行対象/非対象の確定・リスク洗い出し Point 03 検証 • ドライラン→差分レポート→再試行 • リンク整合性/権限/CI実行/通知動作の確認 • カットオーバー手順のリハーサル Point 04 本番 • 凍結→切替→検証→解凍 • マネキン回収/残タスク処理/最終サインオフ 責務分解の例（Org vs Repo） 領域 プラットフォーム アプリ/チーム Org基盤設定 主 副 Repo選定/優先度 副 主 環境再構成 副 主 カットオーバー通知 主 副 検証/業務影響確認 副 主
7. 移行ツールの要点
8. GitHub Enterprise Importer（GEI）要点 DO WHAT MATTERS 8 ◼ GITHUB ENTERPRISE IMPORTERとは 次のサービスからGITHUB.COMに対して、リポジトリまたはORGANIZATIONを移行できるツー ル • GitHub.com • GitHub Enterprise Server(GHES) 3.4.1以降 • Azure DevOps（クラウド版） • Bitbucket（Bitbucket Server, Bitbucket Data Center 5.14以降） ◼ GITHUB ENTERPRISE IMPORTERを理解する 次の観点でGEIでできることを理解し、移行の要件を整理し、GEIがカバーしておらず手作業で行 わなければならない作業は何かを把握。 • Organization単位か、リポジトリ単位か • 移行に割ける時間 • 移行できる・移行できない項目 • 移行できる権限を持つアカウント 出典： https://docs.github.com/ja/enterprise-cloud@latest/migrations/using-github-enterprise-importer/migrating-between- github-products
9. 移行できる／できない項目
10. 移行可否項目（1/4） • Organization単位で移行した場合の移行可能項目 • Teams • リポジトリ • リポジトリへのチーム アクセス • メンバー特権 • Organization レベルの Webhook • Organization 内に作成された新しいリポジトリの既定のブランチ名 ※リポジトリの可視性はすべてプライベートに変更されます。 ※チームのメンバー構成は、移行されません。 • Repository単位で移行した場合の移行可能項目 • Teams DO WHAT MATTERS 10 出典：https://docs.github.com/ja/enterprise-cloud@latest/migrations/using-github-enterprise-importer/migrating-between-github- products/about-migrations-between-github-products
11. 移行可否項目（2/4） DO WHAT MATTERS 11 出典：https://docs.github.com/ja/enterprise-cloud@latest/migrations/using-github-enterprise-importer/migrating-between-github- products/about-migrations-between-github-products ◼ REPOSITORY単位で移行した場合の移行可能項目 ⚫ Git ソース (コミット履歴を含む) ⚫ Pull Request ⚫ issue ⚫ マイルストーン ⚫ Wiki (添付ファイルを除く) ⚫ GitHub Actionsのワークフロー ⚫ コミットのコメント ⚫ アクティブな Webhook ⚫ リポジトリトピック ⚫ リポジトリ設定 ⚫ ブランチ保護 ⚫ GitHub Pages の設定 ⚫ 自動リンク参照 ⚫ pull request の設定 ⚫ head ブランチを自動的に削除する ⚫ 自動マージを許可する ⚫ マージ コミットを許可する (コミット メッセージの設定が既 定のメッセージにリセットされる) ⚫ スカッシュ マージを許可する (コミット メッセージの設定が 既定のメッセージにリセットされる) ⚫ リベース マージを許可する ⚫ リリース (リポジトリあたり最大 10 GB) ⚫ 上記のデータのユーザー履歴 ⚫ 添付ファイル
12. 移行可否項目（3/4） DO WHAT MATTERS 12 出典：https://docs.github.com/ja/enterprise-cloud@latest/migrations/using-github-enterprise-importer/migrating-between-github- products/about-migrations-between-github-products ◼ 移行不可項目 Codespaces のシークレットの * 監査ログ Code scanning の結果 コミット状態チェック Dependabot のアラート Dependabot のシークレット リポジトリ レベルでのディスカッション issue のコメントと pull request のコメントの履歴を編集する リポジトリ間のフォーク関係 GitHub Actions シークレット、変数、環境、セルフホステッド ランナー、より大きなランナー、ワークフ ロー成果物、またはワークフロー実行履歴 GitHub Apps と GitHub App のインストール Git LFS オブジェクトと大きなバイナリ リベース マージされたコミットから pull request へのリンク GitHub Packages
13. 移行可否項目（4/4） DO WHAT MATTERS 13 出典：https://docs.github.com/ja/enterprise-cloud@latest/migrations/using-github-enterprise-importer/migrating-between-github- products/about-migrations-between-github-products ◼ 移行不可項目・・続き Projects (新しいプロジェクト エクスペリエンス) 異なるリポジトリ内の pull request と issue 間の参照 secret scanning の結果の修復状態 ユーザー アカウントが所有するリポジトリ リポジトリのアクティビティ フィード リポジトリのプロパティ リポジトリの星 リポジトリ ウォッチャー ルールセット タグ保護ルール ユーザーのプロファイル、SSH キー、署名キー、または personal access tokens Webhook のシークレット リポジトリへのユーザー アクセス
14. 解析ツール活用
15. 解析フェーズの実務：ツール活用（1/2） • GitHub Migration Analyzerとは • 移行元のOrganizationやリポジトリ の状況の確認するためのOSSツール。 GitHub/Azure DevOpsに対応。 • ※現在アーカイブ化されており、そのま まだと利用できないためカスタマイズが 必要。 • 右図に示す情報を取得するために利 用するため、実際の移行作業には無 影響。 DO WHAT MATTERS Organization metrics 項目 説明 Number of Members メンバーの数 Number of Projects （旧）プロジェクトの数（※） Number of Repositories リポジトリの数 Repo with Most Pull Requests 一番多いリポジトリの数 Average Pull Requests プルリクエストの数の平均値 Repo with Most Issues 一番多いIssuesの数 Average Issues Issuesの数の平均値 Repository metrics 項目 説明 Repository Name リポジトリ名 Last Push Date 最後にpushした日 Is Archived? アーカイブされているか Number Of Pull Requests プルリクエストの数 Number of Issues Issuesの数 Number of Projects （旧）Projectsの数（※） Number of Discussions Discussionsの数 Number of Packages Packagesの数 Number of Releases Releasesの数 Wiki Enabled Wikiの有効/無効 Size (KiB) リポジトリが占めるディスクサイズ（KiB）（実際 のサイズと差異がある場合があります） 出典： https://github.com/yutaka-art/gh-migration-analyzer-custom/
16. 解析フェーズの実務：ツール活用（2/2） • gh-repo-statsとは • 移行元のリポジトリの状況の確認するためのOSSツール。GitHubのみ対応。 • リポジトリの属性情報取得に特化した、GitHub CLI拡張のツール。 ＃ 項目 説明 1 Org_Name Organization名 2 Repo_Name リポジトリ名。 3 Is_Empty リポジトリが空かどうか（GitHub.com と GHES ≥ 3.0 で取得可）。 4 Last_Push 直近の git push の日時（UTC）。 5 Last_Update リポジトリの最終更新日時（メタデータ更新含む、UTC）。 6 isFork フォークリポジトリか。 7 isArchived アーカイブ状態か。 8 Repo_Size(mb) リポジトリのサイズ（MB）。移行時間見積もりに直結。 9 Record_Count このリポジトリに紐づく「データベースレコード」の総数（Issue/PR/コメント/イ ベント等の合計）で、移行の作業量目安。 10 Collaborator_Count このリポジトリに貢献したユーザーの数。 11 Protected_Branch_Cou nt ブランチ保護ルールの数。 12 PR_Review_Count Pull Request の「レビュー」数。 13 Milestone_Count Issue マイルストーンの数。 14 Issue_Count Issue の数。 15 PR_Count Pull Request の数。 16 PR_Review_Comment_Count PR レビューコメントの数。 17 Commit_Comment_Count コミットコメントの数。 18 Issue_Comment_Count Issue コメントの数。 19 Issue_Event_Count Issue のイベント件数（ラベル付与/アサイン/クローズ等の 履歴に相当）※READMEの文言は「Number of issues」だが、列名からイベント件数を指す意図と読み取れ ます。 20 Release_Count リリース（GitHub Releases）の数。 21 Project_Count Projects v1（Classic）の数。v2の数ではない点に注意。 22 Branch_Count ブランチ数。 23 Tag_Count タグ数。 24 Discussion_Count Discussions の数。 25 Has_Wiki Wiki が有効か。 26 Full_URL リポジトリのURL。 27 Migration_Issue 移行で問題が起きそうかのフラグ。下記条件に該当すると TRUE：①インポート対象オブジェクトが6万件以上 ②オン ディスクサイズ1.5GB以上。 28 Created 作成日時（UTC）。
17. 移行実例
18. 小さな移行例（1/3） DO WHAT MATTERS 18 本格移行する前に検証を推奨する。 ◼ 移行作業アカウント 移行元、移行先用に作業アカウントを用意する ◼ 移行元・先のPAT（クラシック）を生成する 移行元 スコープ repo, admin:org 移行先 スコープ read:enterprise, admin:org, repo, workflow ◼ 移行検証（ORGANIZATIONの移行例） GEI extension of the GitHub CLI のインストール `gh gei migrate-org` コマンドレットによる移行実施
19. 小さな移行例（2/3） DO WHAT MATTERS 19 GITHUB ENTERPRISE IMPORTERによる移行実行のキャプチャ Mask Mask Mask Mask Mask Mask
20. 小さな移行例（3/3） DO WHAT MATTERS 20 マネキンの回収 Mask Mask
21. まとめ
22. まとめ ▪本日のポイント • 段階的に進める • 計画→解析→検証→本番 検証をループして本番に備える。 • 先に決める • 何を移すか、移せないものは何か。止める時間や誰がやるか。責任分界点など • ActionsのSecrets/環境/ランナー、外部連携、Packages/Projects等は再構成前提。 • 分析/移行ツールの理解 • GEI＝搬送の主役（Org/Repo単位、ドライラン→本番） • Migration Analyzer / gh-repo-stats＝可視化と見積り（対象/非対象・リスク判定の材料） DO WHAT MATTERS 22 移行＝手段。ゴールは“移行後の運用・ガバナンス定着”。 型（計画→解析→検証→本番）で迷いをなくし、“移せないもの”を先に言語 化してリスクを潰す。
23. 参考文献 DO WHAT MATTERS 23 タイトル QR GitLab から GitHub へ移行するには？ リポジトリ / Issue / CI/CD をまとめて検証 Azure DevOps 環境を gh-ado2gh と AI で整理する話 GitLabやAzure DevOpsなどの別のDevOpsツールからGitHubへの移行 の手段や解析の方法をまとめています
24. THANK YOU DO WHAT MATTERS Yutaka.Osada union.dml@gmail.com https://github.com/yutaka-art 24 ▪合格対策Microsoft認定試験AZ-400 書籍 発売中！！