Conductor Cloud終了：11月20日より前にデータをエクスポート

予防措置として、Conductor Cloudのワークスペース移行と、Cloudターミナルへのアクセスが必要なバックアップ手順を2026年11月13日より前に完了し、検証してください。これとは別に、アカウントのアーカイブを2026年11月20日より前にダウンロードし、中身を確認してください。ワークスペースには Transfer to local、アーカイブには Settings → Account → Export data を使います。

ConductorのMetaへの参加に関する発表では、読み取り専用期間も過去のチャットの閲覧とデータのエクスポートは可能とされています。一方、その期間もワークスペースを移行できるか、Cloudターミナルを使えるかは、どちらも公式発表では明記されていません。Cloudは11月20日に終了し、Cloudのユーザーデータの削除も同日から始まります。

既存ユーザーは、ローカル版Conductorを使って進行中の作業を終えられる場合があります。ただし、移行期間の一時的な手段と考えてください。唯一のバックアップや、恒久的な代替環境として頼るべきではありません。

Conductorの終了で押さえるべき日程

ワークスペースの移行とCloudターミナルが必要なバックアップ手順は、読み取り専用になる前に終えてください。この予防措置による前倒しと、公式に示されたアカウントのエクスポート可能期間は別です。2026-11-10時点の公式日程は次のとおりです。

日付	変更内容	対応
2026年11月4日	新規ユーザーはConductorへの登録とアプリのダウンロードができなくなりました。既存のProユーザーはPro機能を無料で使い続けられます。	現在のインストール環境とアカウントを前提に計画します。
2026年11月13日	Cloudワークスペースが読み取り専用になります。過去のチャットの閲覧とエクスポートは可能ですが、新しいメッセージは送信できません。	エージェントとの対話が必要な作業を事前に終えます。予防措置として、ワークスペース移行とCloudターミナルが必要なバックアップ手順も、この日より前に完了して検証します。
2026年11月20日	Cloudが終了し、Cloudのユーザーデータの削除が始まります。	この日より前に、別途アカウントのエクスポートを完了し、中身を確認します。
2027年初頭	ローカル版Conductorに新しいモデルと重大なバグ修正を提供するという約束の期間が終わり、段階的な終了が始まります。	段階的な終了が始まる前に、アプリへの依存を解消します。

発表には、有効なサブスクリプションを持つユーザーへの返金も記載されています。請求履歴は別途確認してください。返金の約束があることと、自分の口座に返金が届いていることは同じではありません。

チームで移行する場合は、11月12日を内部の完了目標にすると余裕を確保できます。これは推奨する余裕日であり、公式な移行機能の停止日ではありません。11月20日の終わりまでアカウントをエクスポートできるという前提で計画しないでください。

未完了の作業を失わずにConductor Cloudから書き出す方法

両方のエクスポート方法を使い、Cloudワークスペースにアクセスできるうちに未完了のファイルも独立して保存してください。どのコピーも、中身を確認してから復元元として使います。変更済み、未追跡、Gitの無視対象のファイルを、アカウントのアーカイブだけで復元できるとは考えないでください。

各ワークスペースの状態を記録し、ファイルを保存する

移行を始める前に、簡単な一覧を作成してください。ワークスペース名、リポジトリ、ブランチ、最新コミット、開いているプルリクエスト、復元結果を確認する担当者を記録します。

状態を記録している間は、エージェントによる編集とコミットを停止してください。Cloudターミナルにアクセスできるうちに、各ワークスペースのリポジトリのルートで次のコマンドを実行します。この作業は11月13日より前に終えてください。使用するシェルはBashです。

git rev-parse --verify HEAD
git status --short --branch --untracked-files=all
git diff HEAD --stat

最初のコマンドは現在のコミットIDを表示します。2番目はブランチの情報と、変更済みまたは未追跡のファイルを表示します。3番目は、そのコミットに対する追跡済みファイルの差分を要約します。それぞれの動作は、Gitのリビジョン、状態表示、差分のリファレンスで説明されています。

2番目のコマンドの出力全体を、独立したバックアップ内にpre-transfer-status.txtとして保存してください。リポジトリ内にバックアップ用フォルダーを作る前に保存します。完全なコミットIDとブランチ名も一緒に残してください。削除や名前変更については、保存時点の最終的なワークツリーに存在しないパスも記録します。

これらのコマンドは状態を調べるだけで、ファイルの内容は保存しません。レビュー済みのコミットを承認されたリモートリポジトリにプッシュし、対象のブランチとコミットがそこにあることを確認してください。そのリモートのURLも一覧に残しますが、秘密情報を埋め込まないでください。プッシュできないコミットは、後述するbundleの作成と復元確認を済ませてからワークスペースを移行します。状態表示をクリーンにするためだけに、秘密情報や個人用設定をまとめてGitに追加しないでください。

存在する場合は、.conductor/settings.toml、.conductor/settings.local.toml、.contextを確認してください。Conductorは、これらの場所にあるプロジェクトのスクリプト、ローカル設定、コミットされていない引き継ぎメモについて説明しています。

セットアップコマンド、必要なランタイムのバージョン、外部サービス、環境変数の名前を記録してください。秘密情報の値は、承認された認証情報ストアから復元します。移行チケットやエージェントへのプロンプトを、その保存場所にしないでください。

ワークスペースを移行する前に、必要な未完了ファイルを独立してコピーしてください。文書化された方法の1つが Sync to a local directory です。この機能はCloudワークスペースのコピーをローカルフォルダーに保持します。必要なファイルが現れたら、そのフォルダーから別の承認済みバックアップ先にコピーしてください。

相対パスを保ち、作成した一覧もバックアップと一緒に保存します。必要な変更済みファイルと未追跡ファイルを含め、必要な無視対象ファイルは別途確認してください。機密設定は、その種類のデータの保存が認められた場所だけに置きます。

コピーしたファイルを開き、まだアクセスできる元ファイルと内容を比較してください。ファイル一覧は、記録した削除と名前変更も含めて照合します。同期フォルダー自体は編集せず、唯一のバックアップとしても扱わないでください。

小さなテキストファイルが欠けている場合は、元の内容全体を同じ相対パスのローカルファイルに保存します。そのコピーを開き直して比較してください。必要なファイルに検証済みのローカルコピーがない場合は、ワークスペースの移行を止めます。repository.bundleのように、同期で取得できなかったバイナリファイルも対象です。Cloudワークスペースが利用できるうちに、発表ページの連絡先からConductorに相談してください。

バックアップの確認が終わるまで編集を停止してください。編集を再開した場合は、最後の変更後に状態の記録とコピーを更新します。Cloudターミナルへのアクセスが必要なコピー手順は、11月13日より前に完了して検証してください。

プッシュできないコミットの履歴をバックアップする

プッシュできないコミットがあるブランチを移行する前に、Git履歴のローカルバックアップを保存してください。Gitのbundleコマンドは、リポジトリの参照と、それらに対応するコミット履歴をファイルにまとめます。保存したbundleがあれば、ネットワークに接続せずに履歴を復元できます。未完了ファイルの独立したコピーは、引き続き別途必要です。

この状態を保存する間は、新しいコミットの作成とブランチの更新を停止してください。Cloudリポジトリのルートで、Bashから次を実行します。conductor-history-backupというディレクトリは、まだ存在しない状態にしてください。

mkdir conductor-history-backup &&
git for-each-ref --format='%(objectname) %(refname)' refs/heads > conductor-history-backup/branches.txt &&
git bundle create conductor-history-backup/repository.bundle --all

branches.txtに、必要な各ブランチと、一覧に記録した完全なコミットIDが含まれていることを確認してください。先ほどのファイルコピー手順で、フォルダー全体を承認されたローカル保存先にコピーします。このコピーは同期フォルダーの外に置き、repository.bundle本体もMacに届いていることを確認してください。pre-transfer-status.txt、一覧、保存したファイルも、このバックアップと一緒に保管します。

ワークスペースを移行する前に、ローカルに保存したコピーから復元できるかを確認してください。コピー済みのconductor-history-backupフォルダーでBashを開きます。復元先のrestored.gitディレクトリは、まだ存在しないものを使います。

git clone --mirror repository.bundle restored.git &&
git --git-dir=restored.git for-each-ref --format='%(objectname) %(refname)' refs/heads > restored-branches.txt &&
git diff --no-index --exit-code -- branches.txt restored-branches.txt &&
git --git-dir=restored.git fsck

ミラークローンは、参照を独立したベアリポジトリに復元します。ベアリポジトリには、編集するための作業ファイルは展開されません。元と復元後のブランチ一覧に差分がないことを確認してください。git fsckでは、Gitオブジェクトの欠落や破損が報告されないことを確認します。

ワークスペースを移行する前に、restored-branches.txtのブランチ名とコミットIDが期待どおりかを確認してください。いずれかのコマンドが失敗した場合や、必要なブランチがない場合は停止します。Cloudリポジトリにアクセスできる間に、バックアップの問題を解決してください。

bundle、ブランチ一覧、未完了ファイルのコピーは、非公開のリポジトリデータとして保護します。未プッシュの作業があるリポジトリごとに、この手順を繰り返してください。その後にコミットを追加した場合は、バックアップも更新します。

ワークスペースを1つ移行し、検証してから次へ進む

予防措置として、各ワークスペースの移行と検証を11月13日より前に終えてください。Mac上でCloudワークスペースを右クリックし、Transfer to local を選びます。Conductorの0.93.0リリースノートでは、ワークスペースとそのチャットをMacに移す操作として説明されています。

移行が完了したら、ローカルワークスペースを開き、状態確認のコマンドをもう一度実行してください。ブランチ、コミット、未完了の変更、ファイルの内容を、移行前に確認した一覧と独立したコピーに照らして比較します。過去のチャットと最新の会話も、それぞれ開いて確認してください。

未追跡ファイルとプロジェクト設定は別途確認します。リポジトリが表示されたというだけで、すべてのファイルや環境の依存関係が引き継がれたとは判断しないでください。

プロジェクトの手順書に従って依存関係を復元します。その後、意味のある最小限の既存テスト、またはビルド確認を実行してください。不一致は、検証済みのリモートまたはbundleのGit履歴と、独立したファイルコピーを基準に調べます。元のCloudワークスペースは、まだアクセスできる場合に限って追加の比較元にしてください。

必要なすべてのワークスペースで、この確認を繰り返します。未完了の実験や、有用な判断記録が残っている古い作業も対象です。共有作業を別のメンバーが書き出したはずだと考えず、各検証に担当者を割り当ててください。

アカウントのアーカイブを保存して中身を確認する

ワークスペースがローカルに現れた後も、アカウントのアーカイブは別途作成してください。Settings → Account → Export data を開き、ダウンロードしたファイルをConductorのワークスペースディレクトリの外に保存します。このエクスポートと確認は11月20日より前に完了してください。

チームが承認したバックアップ先にも、もう1つコピーを残します。保存したアーカイブをローカル環境の適切な閲覧ツールで開き、代表的なプロジェクト記録や会話を確認してください。書き出した日付と、欠けている内容も記録します。

このアーカイブは、中身を確認して使うバックアップとして扱ってください。別のコーディングツールへそのままインポートできる形式だとは考えないでください。実際に作業できる環境は、検証済みコード、別途保存したファイル、設定、依存関係、認証情報から再構築します。

Transfer to local が表示されない、または失敗した場合は、保存先に合った復元方法を次の節から選んでください。プッシュ済みのコミットは承認済みリモートから、bundleに保存したコミットは検証済みミラーから復元します。Cloudから不足分を回収するのは、まだアクセスできる場合だけです。アカウントも別途エクスポートしますが、それだけで未完了コードを復元できると判断しないでください。

アプリのバージョン、対象ワークスペース、正確なエラーメッセージを記録します。期限前にConductorの発表にあるサポート窓口へ連絡してください。認証情報や機密性のある会話内容は送信しないでください。

発表された読み取り専用期間には、過去のチャットとデータのエクスポートは利用できます。ただし、11月13日以降の復元を、新しいエージェントメッセージ、ワークスペース移行、Cloudターミナルの継続利用に依存させないでください。

保存した履歴から作業用コピーを復元する

履歴をプッシュした場合は承認済みリモートを、bundleを作った場合はrestored.gitを復元元に使います。どちらか1つの方法を選んでください。その後は共通の手順でファイルを戻し、記録した削除と名前変更を再現します。

プッシュ済みコミットを復元する場合は、承認されたローカルの復元用ディレクトリでBashを開きます。秘密情報を含まない、承認済みリモートのURLを入力してください。ブランチ名と完全なコミットIDは、どちらも保存した一覧から取得してください。ブランチ名を入力するときだけ、先頭のrefs/heads/を除きます。通常のGit認証を使い、recovered-worktreeディレクトリがまだ存在しない状態で実行してください。

read -r -p "Approved remote URL (no embedded secrets): " RECOVERY_REMOTE &&
read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
mkdir recovered-worktree &&
(
  cd recovered-worktree &&
  git init &&
  git remote add origin "$RECOVERY_REMOTE" &&
  git fetch origin &&
  git switch --create "$RECOVERY_BRANCH" "$RECOVERY_COMMIT" &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

fetchの処理でリモートの履歴を取得します。git switch --createは、リモートブランチの最新位置ではなく、記録したコミットに目的のローカルブランチを作成します。認証に失敗した場合、記録したコミットが取得できない場合、比較が不一致の場合は停止してください。不足するコミットは、検証済みbundleまたはアクセス可能なCloudワークスペースから取得します。別のコミットで代用しないでください。

bundleのバックアップから復元する場合は、ローカルのconductor-history-backupディレクトリでBashを開きます。保存した一覧から、refs/heads/を除いたブランチ名と完全なコミットIDを入力してください。こちらも、recovered-worktreeディレクトリがまだ存在しない状態で実行します。

read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
git clone --branch "$RECOVERY_BRANCH" restored.git recovered-worktree &&
(
  cd recovered-worktree &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

git clone --branchは、作業用コピーに展開するブランチを選択します。git branch --show-currentで名前を、git rev-parse --verify HEADでコミットを確認します。最後の状態表示は、両方の比較が成功した場合だけ実行されます。エラーや不一致があれば停止してください。

どちらかの方法が成功したら、新しく作成したrecovered-worktreeの中で作業します。保存しておいた変更済み、追加済み、未追跡のファイルを、それぞれ元の相対パスへコピーしてください。必要な無視対象ファイルは別途復元します。元のバックアップコピーは変更しないでください。

pre-transfer-status.txtと、最終状態で存在しなかったパスの記録を使い、削除と名前変更を再現します。削除済みと記録したパスだけを対象とし、保存した最終状態でも存在しなかったことを確認してください。そのうえで、復元用コピーの中だけから削除します。名前変更では、保存したファイルを新しいパスに戻します。古いパスを削除するのは、最終状態にそのパスがなかった場合だけです。

復元したコピーのルートで、状態確認のコマンドを再実行してください。変更されたパスを保存済みの状態表示と照合し、ファイル内容を独立したコピーと比較します。この方法で復元するのはワークツリーの内容であり、元のステージング状態ではありません。変更をステージする前、またはエージェントを再開する前に差分を確認してください。バックアップのミラーへプッシュしてはいけません。

ローカル版Conductorは移行中の一時的な手段にする

ワークスペースのインターフェースへの依存を解消する間は、ローカル版Conductorで作業を続けられます。発表では、新しいモデルと重大なバグ修正を2027年初頭まで提供し、その後は段階的に終了するとされています。Cloudの11月20日という期限が延びるわけではありません。

ワークスペースを移行したら、実行環境を検証してください。Cloudワークスペースのドキュメントでは、Macから接続するLinuxサンドボックス上での実行が説明されています。Cloudでビルドできたことだけでは、同じ依存関係とコマンドがMac上でも動くとは判断できません。

ローカル実行は、モデル推論がオフラインになるという意味でもありません。Conductorのプライバシーに関するドキュメントでは、ローカルワークスペースのモデル通信は設定済みのモデルプロバイダーへ送信されると説明されています。

プロセスが終了する条件の違いにも注意してください。CloudのFAQによると、ローカルワークスペースのセッションは、Conductorを閉じるかMacをシャットダウンすると終了します。そのため、移行済みワークスペースは、Cloud上で継続して動くプロセスの代わりにはなりません。

この移行期間に、Conductorなしでもリポジトリを使えるようにしてください。セットアップ手順、テストコマンド、作業の引き継ぎメモを、レビュー済みのプロジェクトファイルに残します。モデルプロバイダーの利用枠やAPI請求は、ConductorのPro機能無料化とは別に確認してください。

Claude Code、Codex、OpenCodeで並列作業を再開する

まず使い慣れたコーディングエージェントを選び、Gitのワークツリーを分けて並列作業を再開してください。ワークツリーは、同じリポジトリから作る別の作業用コピーです。通常は、それぞれ異なるブランチを使います。

この方法は、プロジェクトをローカルで実行でき、Gitで変更をレビューできる開発者に向いています。別々の作業ディレクトリは用意できますが、Conductorの共有Cloudサービスやインターフェース全体を再現するものではありません。

エージェントを選び、認証を確認する

タスクを移す前に、選んだCLIをConductorの外でインストールし、認証を済ませてください。以下の異なるエージェントを使う例では、Claude CodeとCodexの両方が必要です。両方でインストールと認証を完了します。1種類だけを使う場合は、選んだCLIを両方のワークツリーで起動してください。

Claude Codeの作業手順を維持するなら、Claude Codeを使います。プロジェクトディレクトリ内でclaudeを実行し、初回の認証案内に従ってください。

Codexの作業手順を維持するなら、Codex CLIを使います。プロジェクトディレクトリ内でcodexを実行してください。初回はChatGPTでのサインイン、または利用可能な別の認証方法を選びます。

すでにOpenCodeでモデルプロバイダーを設定している場合や、複数のプロバイダーから選びたい場合は、OpenCodeを使います。opencodeを起動し、プロバイダー設定の手順に従って/connectと/modelsを使ってください。

Conductor内だけで設定した認証情報が、独立したCLIでも使えるとは考えないでください。実際のタスクへのアクセスを許可する前に、有効なアカウント、プロバイダー、モデルを確認します。

別途、従量課金のAPI接続を選ぶ場合は、BetterTokenがClaude CodeとCodexの専用セットアップ手順を公開しています。モデルへの接続設定とワークスペースの復元は、別の作業として扱ってください。本番のタスクを移す前に、Claude CodeとCodexのAPI初回確認リストを使って接続を確認します。

2つのワークツリーを作り、作業の流れを確認する

検証済みのローカルリポジトリのルートで、内容を把握しているコミットを出発点にしてください。次のBashの例は、現在のHEADから2つのブランチを作成します。

git worktree add -b migration/docs ../migration-docs HEAD &&
git worktree add -b migration/tests ../migration-tests HEAD &&
git worktree list

Gitのworktreeリファレンスには、-bによるブランチ作成とlistによる一覧確認が説明されています。出力に、両方の新しいディレクトリと対応するブランチが含まれていることを確認してください。

作成されるのは、コミット済みの状態から展開した新しい作業用コピーです。未コミットのファイルやConductorのチャット状態はコピーされません。この例を使う前に、復元が必要な未完了の作業を保護してください。

まだ使っていないブランチ名とディレクトリ名を指定します。作成エラーが出たら、すでに作成されたブランチやワークツリーを確認してください。その結果に基づいて、失敗した手順を再試行する必要があるか判断します。エラーを避けるためだけに--forceを追加しないでください。

次の2つの起動コマンドは、Claude CodeとCodexの両方がインストール済みで、認証も完了していることを前提とします。ターミナルのタブを2つ開き、それぞれ元のリポジトリのルートから始めてください。最初のタブでClaude Codeを起動します。

(cd ../migration-docs && claude)

2つ目のタブでCodexを起動します。

(cd ../migration-tests && codex)

1種類のエージェントだけを使う場合は、両方のディレクトリで同じインストール済みコマンドを使います。選択肢はclaude、codex、opencodeです。ファイルを編集する2つのエージェントを、同じ作業ディレクトリで実行しないでください。

各セッションは、次の確認用プロンプトから始めます。

Use read-only tools to inspect this repository.
Report the current directory and Git branch.
Identify the documented setup command and one existing test command.
Cite the repository files that define those commands.
If a command is not documented, say so.
Do not edit files, install packages, commit, or push.

期待する結果は、異なるディレクトリとブランチに対応した2つの報告です。各報告では、汎用的なテストコマンドを推測するのではなく、根拠となる実際のリポジトリファイルを示す必要があります。通常の承認機能は有効のままにしてください。プロンプト自体はセキュリティ境界になりません。

この確認が通ったら、必要なセットアップを承認し、各ワークツリーで小さな既存テストを実行します。その後、ドキュメント修正と別のテスト改善など、独立したタスクを割り当ててください。コミットやマージの前に、それぞれの差分をレビューします。

書き出した会話を使い、タスクごとの短い引き継ぎメモを作成してください。目的、制約、完了した変更、残作業、最後のテスト結果を含めます。取り込んだ指示やフックは、再利用する前に確認してください。エージェント設定の監査ガイドが確認項目の参考になります。

新しいCLIセッションを起動しても、過去の会話履歴が復元されたことにはなりません。OpenAIのインポートに関するドキュメントでは、Codex CLIの取り込み元としてClaude CodeとCursorが挙げられています。Conductorのアカウントアーカイブを直接取り込めると確認できる内容ではありません。

ワークツリーを分けても、データベース、サービスアカウント、開発用ポートまで自動で分かれるわけではありません。並列ビルドを始める前に、これらのリソースの割り当てを決めてください。Conductorも、ワークスペースの分離とセキュリティ境界を区別しています。

有効な各セッションについて、プロバイダーの利用枠またはAPI料金を確認します。たとえばOpenAIの認証ドキュメントは、APIキーによる課金とChatGPTプランに含まれるクレジットを区別しています。ターミナルのタブを増やしても、サブスクリプションの利用枠は増えません。

アーカイブを開けること、必要なファイルとコミットを確認できること、ローカルのタスクが検証を通ることを確認してから、移行完了としてください。未解決のワークスペースは一覧に残します。担当者が検証を終えるか、復元できなかったものを明記するまで、完了扱いにしないでください。