Azure DevOps 環境を gh-ado2gh と AI で整理する話
0. はじめに
「Azure DevOps から GitHub に移行しようかな」と考え始めると、最初にぶつかる壁はだいたいこれです。
「で、そもそもウチの Azure DevOps に何個プロジェクトあって、どれぐらいリポジトリあるんだっけ？」
Microsoft Learn の「Azure DevOps to GitHub Enterprise Migrations – Source Environment Assessment」でも、最初のステップは “今あるものの棚卸し” だと説明されています。
この記事では、GitHub Enterprise Importer の一部である GitHub CLI の ADO2GH 拡張 gh-ado2gh を使って、
- Azure DevOps のリポジトリやパイプラインを CSV で棚卸しする
- 得られた
orgs.csv/team-projects.csv/repos.csv/pipelines.csvをざっくり読み解く - ついでに AI（Copilot / ChatGPT）に解析を手伝ってもらう視点 をちょっとだけ足す
ところまでをまとめます。
💡 GitHub への移行予定がなくても、「今の AzDO の使われ方を可視化するツール」としてかなり便利です。
1. ADO2GH 拡張機能とは？
GitHub Enterprise Importer (GEI) は、Azure DevOps や GitHub Enterprise Server などから GitHub Enterprise Cloud への移行を支援する公式ツール群です。その一部として、GitHub CLI 用の拡張機能 gh-ado2gh が提供されています。
gh ado2gh inventory-report コマンドを使うと、Azure DevOps の API に接続して、
- 組織
- チームプロジェクト
- リポジトリ
- パイプライン
の情報を CSV ファイルとして一気に出力 できます。GitHub Docs でも、「Azure DevOps から移行する場合は inventory-report を使って基本的なインベントリを作るのがおすすめ」と書かれています。
2. 前提：GitHub CLI と ADO2GH 拡張のセットアップ
2.1. ADO2GH 拡張のインストール
GitHub CLI gh が入っている前提で、拡張は次の 1 行で入ります。
gh extension install github/gh-ado2gh
アップデートするときは
gh extension upgrade github/gh-ado2gh
2.2. GitHub CLI へのログイン
GitHub 側の認証を済ませます。
gh auth login --hostname github.com
ブラウザが開くので、GitHub アカウントでサインインして認可すれば OK です。
2.3. Azure DevOps の PAT を環境変数に設定
ADO2GH は、Azure DevOps の REST API を叩くために Azure DevOps の PAT を必要とします。環境変数 ADO_PAT に設定しておきます。
- macOS / Linux（bash 等）の例
export ADO_PAT="your-ado-pat-token"
- PowerShell の場合（Windows）の例
$Env:ADO_PAT = "your-ado-pat-token"
PAT の権限は、少なくとも対象 Org のリポジトリやパイプラインを読み取れるスコープを付けて作成しておきましょう。
詳細は以下のとおりです。
- Build (Read) … ビルド パイプライン情報にアクセスする
- Code (Read) … リポジトリのコンテンツと履歴の読み取り
- Project and Team (Read) - プロジェクトとチームのメタデータにアクセスする
- Service Connections (Read, query, & manage) - ハイブリッド統合を構成する
- Work Items (Read, write, & manage) - Azure Boards 統合機能にアクセスする
3. gh ado2gh inventory-report で棚卸しレポートを作る
準備ができたら、いよいよ棚卸しです。コマンドはとてもシンプルです。
gh ado2gh inventory-report --ado-org "your-ado-org"
この 1 行で、カレントディレクトリに 4 つの CSV ファイルが出力されます。
orgs.csvteam-projects.csvrepos.csvpipelines.csv
以下、それぞれどんな項目が入っていて、何に使えるかを見ていきます。
3.1. orgs.csv：組織レベルのサマリを見る
- 主な列の意味
| 項目 | 説明 |
|---|---|
| name | Azure DevOps の Organization 名 |
| url | Organization のトップ URL |
| owner | Owner として認識されているユーザー（または PAT 発行ユーザー） |
| teamproject-count | チームプロジェクトの数。→ 「この Org はどれくらいの単位に分割されているか」の目安になります。 |
| repo-count | 全リポジトリ数。→ 移行の規模感をざっくりつかむのに使います。 |
| pipeline-count | パイプラインの総数（Build + Release）。→ GitHub Actions や別の CI に移行する際のボリューム感。 |
| is-pat-org-admin | PAT が Org 管理者権限を持っているか。TRUE になっていれば、移行用ツールを動かす上で十分な権限を持っている可能性が高いです。 |
| pr-count | 全リポジトリの PR 合計数。→ GitHub Docs でも、PR 数は移行時間や複雑さの指標として重要とされています。 |
-
ここから読み取れること
- 「そもそもこの Org は大きいのか、小さいのか」
- 「パイプライン多すぎ問題では？」といった 第一印象レベルの健康診断
3.2. team-projects.csv：チームプロジェクトごとのボリュームを見る
- 主な列の意味
| 項目 | 説明 |
|---|---|
| org | 所属する Azure DevOps Organization 名 |
| teamproject | チームプロジェクト名 |
| url | チームプロジェクトの URL |
| repo-count | そのチームプロジェクト配下のリポジトリ数 |
| pipeline-count | そのチームプロジェクト配下のパイプライン数 |
| pr-count | チームプロジェクト配下リポジトリの PR 合計数 |
-
ここから読み取れること
- 「どのチームプロジェクトが一番 “重い” のか」をざっくり比較できます。
- リポジトリ数は少ないのに PR はやたら多い チームプロジェクトがあれば、重要度が高いか、歴史が長い可能性があります。
3.3. repos.csv：リポジトリ単位の “サイズ・活動量・複雑さ” を見る
- 主な列の意味
| 項目 | 説明 |
|---|---|
| org | 所属する Azure DevOps Organization 名 |
| teamproject | チームプロジェクト名 |
| repo | リポジトリ名 |
| url | リポジトリURL |
| last-push-date | 最後に push された日時。→ アクティブなリポジトリか、過去の遺産かを見分けるのに重要。 |
| pipeline-count | このリポジトリに紐づくパイプライン数。→ CI/CD の複雑さの目安。 |
| compressed-repo-size-in-bytes | 圧縮後のリポジトリサイズ（バイト）。→ 大きいほど移行時間が伸びたり、LFS や履歴の整理が必要になったりします。GitHub Docs |
| most-active-contributor | もっとも活動量の多いコントリビューター。 |
| pr-count | PR 数。→ レビュー文化があるか、長く運用されているかの指標にもなります。 |
| commits-past-year | 過去 1 年のコミット数。→ 「最近どれくらい更新されているか」の定量的な指標。 |
-
ここから読み取れること
この CSV が、移行優先度やアーカイブ候補を考えるうえでのメインデータ になります。-
last-push-dateが古く、commits-past-yearも 0 → 「アーカイブ候補？」 - サイズが極端に大きい → 移行前に履歴整理や LFS への移行が必要かも
- PR 数が多い → 開発フローとして重要、移行時には丁寧なテストやコミュニケーションが必要
-
3.4. pipelines.csv：パイプラインの存在をざっくり把握する
- 主な列の意味
| 項目 | 説明 |
|---|---|
| org | 所属する Azure DevOps Organization 名 |
| teamproject | チームプロジェクト名 |
| repo | リポジトリ名 |
| pipeline | パイプライン名。 |
| url | パイプライン定義の URL（Azure DevOps の Build/Release ページ）。 |
- ここから読み取れること
「CI/CD がまったくないリポジトリ」 と 「パイプラインが複数ぶら下がっているリポジトリ」 を簡単に見分けられます。
GitHub Actions への移行や、別の CI に置き換えたい場合に、「どこから手を付けるか」を決める材料になります。
4. 人間が見るときの基本的な観点
ここまでで、「数字としての棚卸し」は終わっていますが、ここからが本題です。
4.1. まずは "健康診断"
- Org 単位で、リポジトリ数・パイプライン数・PR 数を眺める
- チームプロジェクト単位で、「やたらと重そうなところ」を探す
- repos.csv を眺めて、
-
last-push-dateが古いもの -
compressed-repo-size-in-bytesが大きいもの -
pipeline-countが多いもの
-
これらをざっとマークしていきます。
ここまでは、Excel のフィルタやピボットテーブルだけでも十分できます。
4.2. 移行する？残す？アーカイブする？
GitHub Docs でも、「移行は“全部持っていく”のではなく、不要なリポジトリを整理する良い機会」と書かれています。
たとえば、こんな基準でざっくり分類できます。
-
現役 & 重要
-
commits-past-year> 0 - PR もそこそこある
- パイプラインも動いている
-
-
現役だけど軽い
- 更新はあるが、サイズも小さいし PR も少ない → 移行の実験台向き
-
過去の資産
- 更新なし
- それでも PR やコミット履歴は価値がありそう（監査・トレーサビリティなど）
ここまでは人間の判断が必要ですが、その前段の「候補リストづくり」は AI に任せるとかなり楽 になります。
5. AI に repos.csv を “読ませて” スコアリングする
ここからは、記事冒頭で触れた「GitHub Enterprise Migration Analysis Prompt」の考え方を、ライトに活用してみます。専用のツールがあるわけではありませんが、、、
やりたいことはシンプルで、
- サイズ（
compressed-repo-size-in-bytes） - 活動量（
commits-past-year,last-push-date） - 複雑さ（
pr-count,pipeline-count）
このあたりから、移行のしやすさをざっくりスコアリングすることです。
5.1. 例：AI に投げるプロンプト案
たとえば ChatGPT や Copilot Chat に repos.csv を貼って、こんな感じでお願いできます。
「この
repos.csvをもとに、各リポジトリを次の 3 軸で High / Medium / Low に分類してください。
- Size（compressed-repo-size-in-bytes）
- Activity（commits-past-year と last-push-date）
- Complexity（pr-count と pipeline-count）
そのうえで、- Wave 1：小さく・シンプルで・活動量も少ない
- Wave 2：中ぐらい
- Wave 3：大きい or 複雑
- Manual Review：特殊ケース
の 4 つに分けて、Markdown テーブルで出力してください。」
AI は計算と分類が得意なので、きれいに表にまとめてくれます。
人間側は、その結果を見て「このリポジトリは業務上どういう位置づけだっけ？」という 文脈判断だけに集中できます。
5.2. AI を使うときのコツ
-
生の CSV をそのまま投げるより、最低限の説明（どの列が何を意味するか）を添えると精度が上がる
-
AI が出した分類は「たたき台」なので、
- 移行リーダー
- チームリーダー
- プロダクトオーナー
と一緒にレビューする前提にしておく
まとめ：棚卸しツール + AI で「手を付ける前に全体像をつかむ」
この記事では、
-
gh ado2gh inventory-report --ado-org "your-ado-org"で
Azure DevOps 環境を CSV に棚卸しする -
orgs.csv/team-projects.csv/repos.csv/pipelines.csvの
見どころと各列の意味 - そして AI を使って repos.csv をスコアリング・分類させるアイデア
を紹介しました。
実際にやってみるとわかりますが、「とりあえず inventory-report を 1 回流す」だけでもかなり視界がクリアになります。GitHub への移行を本格的に始める前に、まずは ADO2GH で環境を棚卸ししてみるのがおすすめです。
移行をする予定がなくても、
- 放置されているリポジトリ
- いつの間にか増えたパイプライン
- 規模が大きくなりすぎたプロジェクト
などが一気に見えてくるので、Azure DevOps の “健康診断ツール” としても十分価値があります。
あとは、生成された CSV を GitHub Copilot や ChatGPT に投げて、
「この Org のリポジトリをどう整理・移行していくのが良さそうか？」を一緒に考えてもらうだけです。
リファレンス
Discussion