{"meta":{"title":"Enterprise Live Migrations を使用したリポジトリの移行","intro":"ダウンタイムを最小限に抑えて、 GitHub Enterprise Server から GHE.com に移行します。","product":"移行","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/migrations","title":"移行"},{"href":"/ja/enterprise-cloud@latest/migrations/elm","title":"ライブ マイグレーション (GHES から GHE.com)"},{"href":"/ja/enterprise-cloud@latest/migrations/elm/migrate-your-repository","title":"リポジトリを移行する"}],"documentType":"article"},"body":"# Enterprise Live Migrations を使用したリポジトリの移行\n\nダウンタイムを最小限に抑えて、 GitHub Enterprise Server から GHE.com に移行します。\n\n> \\[!TIP] このガイドに従うと、使用に関する詳細な情報については [、AUTOTITLE](/ja/enterprise-cloud@latest/migrations/elm/elm-cli-reference) を参照できます。 エラーが発生した場合は、 [GitHub Enterprise Server から GHE.com へのライブ マイグレーションのトラブルシューティング](/ja/enterprise-cloud@latest/migrations/elm/troubleshooting) を参照してください。\n\n## 前提条件\n\n環境と開発者が移行の準備ができていることを確認します。 「[GitHub Enterprise Server から GHE.com へのライブ マイグレーションの準備](/ja/enterprise-cloud@latest/migrations/elm/prepare-for-your-migration)」を参照してください。\n\n## 1. GitHub Enterprise Server を設定する\n\nトークンを作成して移行を実行する前に、 GitHub Enterprise Server インスタンスに何らかの構成を設定する必要があります。 これらの構成値は、すべての ELM 移行に適用されます。\nGitHub Enterprise Serverの開発者は、新しい構成を適用するときに短いダウンタイムが発生する可能性があります。\n\n1. SSH 経由で GitHub Enterprise Server 管理シェルにアクセスします。 「[管理シェル (SSH) にアクセスする](/ja/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)」を参照してください。\n2. `ghe-config`を使用して、次の構成変数を設定します。\n\n   例えば： `ghe-config app.elm-exporter.enabled true`\n\n   | Variable                                             | これを \\[...] に設定します。                                                                                                                                |\n   | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |\n   | `app.elm-exporter.enabled`                           | `true`                                                                                                                                            |\n   | `app.elm.internal-webhooks-enabled`                  | `true`                                                                                                                                            |\n   | `app.elm-exporter.webhooks-loopback-address-enabled` | `true`                                                                                                                                            |\n   | `secrets.elm-exporter.migration-target-url`          | 移行先企業の API URL (例: `https://api.octocorp.ghe.com`)。 URL の末尾に末尾のスラッシュを含 **めないでください** 。                                                             |\n   | `secrets.elm-exporter.source-user`                   | オペレーターの GitHub Enterprise Server トークンに関連付けられているユーザー名。 これは GitHub Enterprise Serverのユーザー名にする必要があります。他のユーザーがこのトークンを作成する場合は、ここでの値をユーザー名に設定する必要があります。 |\n\n`ghe-admin` ユーザーをお勧めします。 |\n\n1. 構成を適用します。\n\n   ```shell copy\n   ghe-config-apply\n   ```\n\n2. SSH セッションを終了します。 残りのコマンドは、ローカル ターミナル セッションで実行します。\n\n## 2. エンタープライズ アクセス権を持つオペレーター トークンを作成する\n\nオペレーターは、 personal access token (classic)を使用して、移行元企業と移行先企業の両方に対して認証を行う必要があります。 トークンの作成手順については、 [個人用アクセス トークンを管理する](/ja/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic) を参照してください。\n\n次の手順で必要になりますので、**両方のトークンをメモ**しておいてください。\n\n1. \\*\\*\n   GitHub Enterprise Server\n   \\*\\*で、personal access token (classic)を作成し、必要なスコープを選択します。\n\n   * `admin:enterprise`\n\n   このトークンは、ELM CLIを構成するときに**ソース トークン**として使用します。\n\n2. \\*\\*\n   GHE.com\n   \\*\\*で、personal access token (classic)を作成し、必要なスコープを選択します。\n\n   * `admin:enterprise`\n   * `admin:org`\n\n   このトークンは、ELM CLIを構成するときに**ターゲット トークン**として使用します。\n\n## 3. ELM コマンド ライン ツールを構成する\n\nGitHub CLIの拡張機能を使用して、ローカル ターミナル セッションから移行を実行します。\n\n1. ローカル コンピューターに [GitHub CLI](https://cli.github.com/) をインストールします。 バージョン 2.0 以降を使用している必要があります。\n\n2. ELM 拡張機能をインストールします。\n\n   ```shell copy\n   gh extension install github/gh-elm\n   ```\n\n3. インストール ウィザードを起動して拡張機能を構成します。\n\n   ```shell copy\n   gh elm configure\n   ```\n\n4. インストール ウィザードの指示に従って、ソースと宛先の API URL (例: `https://api.SUBDOMAIN.ghe.com`) と前の手順で作成したトークンを指定します。\n\nこれらの値は、任意の `gh elm` コマンドで CLI フラグとして指定することもできます。これは、構成よりも優先されます。 たとえば、 `--target-url https://api.SUBDOMAIN.ghe.com`と指定します。\n\nこのセットアップ プロセスでは、オペレーティング システムの構成ディレクトリ ( `gh-elm/config.json`) のプラットフォーム固有の構成ファイルに URL が格納されます。 アクセス トークンは、コンピューターのシークレット ストレージに安全に格納されます。\n\n## 4. ライブ マイグレーション シークレットを構成する\n\nエンタープライズ アクセス権を持つオペレーター トークンに加えて、ソース組織とターゲット組織の personal access token (classic) を作成する必要があります。 移行する組織ごとに、これらの手順を繰り返す必要があります。\n\n### アクセス トークンを作成する\n\nELM は、移行元と移行先の両方の personal access token (classic) で認証する必要があります。 トークンの作成手順については、 [個人用アクセス トークンを管理する](/ja/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic) を参照してください。\n\n**これらのトークンは、次の**手順で必要になりますので、必ずメモしておいてください。\n\n1. personal access token (classic) で次のスコープを持つ GitHub Enterprise Server を作成します。\n\n   * `repo`\n   * `admin:org`\n   * `admin:repo_hook`\n   * `admin:org_hook`\n\n   これがソース トークンです。\n\n2. 次のスコープを使用して、personal access token (classic) 上に GHE.com を作成します。\n\n   * `repo`\n   * `workflow`\n   * `admin:org`\n   * `admin:repo_hook`\n   * `admin:enterprise`\n\n   これがターゲット トークンです。\n\n   > \\[!IMPORTANT]\n   > GHE.comでターゲット組織にシングル サインオンが適用される場合は、SSO のGHE.com トークンを承認する必要があります。\n\n### 組織の ELM シークレットを構成する\n\n`gh elm config` コマンドを使用して、ソースとターゲットのアクセス トークンを設定します。\n\n1. ソース トークンを設定します。\n\n   ```shell copy\n   gh elm config set-source-pat EXISTING-GHES-ORG\n   ```\n\n   要求されたら、ソース トークンをターミナルに貼り付けます。\n\n2. ターゲット トークンを設定します。\n\n   ```shell copy\n   gh elm config set-target-pat EXISTING-GHES-ORG\n   ```\n\n   メッセージが表示されたら、ターゲット トークンをターミナルに貼り付けます。\n\nトークンは、 `gh elm config org-tokens EXISTING-GHES-ORG`を使用して対話形式で設定することも、 `https://GHES_HOSTNAME/organizations/EXISTING-GHES-ORG/settings/secrets/elm-exporter/`の組織設定で設定することもできます。\n\n## 5. マイグレーションを作成する\n\nソース リポジトリとターゲット リポジトリの詳細を指定して、新しい移行を作成します。\n\n> \\[!NOTE]\n> `target-org`は新規でも既存でもかまいません。 ターゲット組織がまだ存在しない場合は、移行中に作成されます。 ただし、移行元組織の設定は移行されません。\n\n```shell copy\ngh elm migration create \\\n  --source-org EXISTING-GHES-ORG \\\n  --source-repo EXISTING-GHES-REPO \\\n  --target-org GHEC-ORG \\\n  --target-repo NEW-GHEC-REPO\n```\n\n例えば次が挙げられます。\n\n```shell\ngh elm migration create \\\n  --source-org my-ghes-org \\\n  --source-repo my-ghes-repo \\\n  --target-org my-dr-org \\\n  --target-repo my-dr-repo\n```\n\n省略可能なフラグ:\n\n* `--start`: 移行をすぐに開始する準備ができた場合。\n* `--target-visibility`: 移行されたリポジトリは、既定で **内部** 可視性を使用して作成されますが、 `private`を指定できます。\n\n### 移行 ID を保存する\n\n次のような応答が表示されます。\n\n```json\n{\n  \"migrationId\": \"2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9\",\n  \"expiresAt\": \"2026-02-11T21:49:33.619162159Z\"\n}\n```\n\n次のコマンドに必要な `migrationId` を変数としてエクスポートします。 例えば次が挙げられます。\n\n```shell\nexport MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'\n```\n\n## 6. 移行を開始する\n\nまだ移行を開始していない場合は、先ほど保存した移行 ID を使用して移行を開始します。\n\n```shell copy\ngh elm migration start --migration-id $MIGRATION_ID\n```\n\nこれにより、バックフィルとライブ更新プロセスが起動します。\nELM は現在、ソース リポジトリからデータを収集し、サポートされている Webhook イベントをリッスンしています。\n\n## 7. 移行を監視する\n\n移行が開始されると、 GHE.comに新しいリポジトリが表示されます。 移行中は、開発者がソース リポジトリで作業を続ける際に、リポジトリにデータの初期読み込みが入力され、更新プログラムが受信されます。\n\n`watch` コマンドを使用して、移行の進行状況を対話形式で監視できます。\n\n```shell\ngh elm migration watch $MIGRATION_ID\n```\n\nこれにより、移行状態 API がポーリングされ、現在の進行状況を反映した自己更新テキスト UI が表示されます。\n\n### `migration status` を使用したプログラムによるモニタリング\n\n自動化に適した移行状態が必要な場合は、 `status` コマンドを使用します。\n\n```shell copy\ngh elm migration status --migration-id $MIGRATION_ID\n```\n\n応答で最も重要なインジケーターは、 **combinedState** オブジェクトの状態です。 状態が `COMBINED_STATUS_READY_FOR_CUTOVER`に達すると、次の手順に進む準備が整います。 ただし、個々のリソースの移行に失敗した場合は、 `displayMessage` でアラートが表示されます。調査が必要な場合があります。\n\n例えば次が挙げられます。\n\n```json\n  \"combinedState\":  {\n    \"status\":  \"COMBINED_STATUS_READY_FOR_CUTOVER\",\n    \"displayMessage\":  \"Ready for cutover (1 resources failed)\",\n    \"repositories\":  [\n      {\n        \"repositoryNwo\":  \"new-test-org/my-new-repo\",\n        \"phase\":  \"REPOSITORY_PHASE_READY_FOR_CUTOVER\",\n        \"displayStatus\":  \"Ready for cutover (1 failed)\"\n      }\n    ],\n    \"readyForCutover\":  true,\n    \"cutoverBlockers\":  []\n  },\n```\n\nヒント:\n\n* 複数の移行を実行している場合は、すべての移行の状態を `gh elm migration list`で確認できます。 このコマンドは、既定で進行中の移行を示しますが、 `--status`でフィルター処理することもできます。\n* 注意が必要なエラー状態が発生した場合は、 [GitHub Enterprise Server から GHE.com へのライブ マイグレーションのトラブルシューティング](/ja/enterprise-cloud@latest/migrations/elm/troubleshooting#statuses-and-recommended-actions) を参照してください。\n\n## 8. 移行を完了する\n\nカットオーバーに向けて移行準備ができたら、移行を完了できます。 カットオーバー プロセスによってソース リポジトリがアーカイブされ、リポジトリ管理者がアーカイブを解除しない限り **、完全に読み取り専用** になります。\n\n```shell copy\ngh elm migration cutover --migration-id $MIGRATION_ID\n```\n\n引き続き移行を監視します。 応答の上部に `MIGRATION_STATUS_COMPLETED` の状態が表示されると、移行は完了しますが、 GitHub Enterprise Serverからユーザーにアクセス権を付与するためのフォローアップ タスクがいくつかあります。\n\n## 次のステップ\n\nユーザーに新しいリポジトリへのアクセス権を付与し、ユーザー アカウントを使用してアクティビティを調整します。 「[GitHub Enterprise Server から GHE.com へのライブ マイグレーションの完了](/ja/enterprise-cloud@latest/migrations/elm/complete-your-migration)」を参照してください。"}