Google Jules終了：データのエクスポートと移行手順

Google Julesのデータを今すぐエクスポートし、最後のコーディングセッションを終えた後にもう一度保存してください。2026-11-01時点のGoogleの案内では、2026年11月11日までセッションを完了でき、その後は年末まで読み取り専用になります。Julesの終了日は、公式の終了告知によると2026年12月31日です。

移行は、Jules内のデータを保存する作業と、移行先で一つの作業を再現する作業に分かれます。リポジトリだけでは、後者に必要なメモリ、実行環境の設定、セッション履歴をすべて保存できません。

読み取り専用になる前に何を終えるべきですか？

11月11日より前に進行中の作業を終え、必要な変更を保存してください。Googleの告知では、その日を過ぎると読み取り専用になります。切り替えの時刻やタイムゾーンは記載されていません。

読み取り専用の期間中も、エクスポート用エンドポイントを利用できるとは約束されていません。11月11日より前に保存するのは、余裕を持って移行するための推奨です。エクスポート専用の締め切りが別途発表されたわけではありません。

GitHubにあるコード、ブランチ、プルリクエストは、そのまま残ります。未完了のセッションを見直し、必要に応じて有用な変更を公開してください。まだブランチに反映していない作業は、エクスポートしたパッチを保管します。

Googleは、Julesで得た知見をAntigravityの開発に生かすと説明しています。ただし、この説明には移行手順は含まれていません。Julesの設定が自動的に引き継がれるという保証でもありません。

Julesのデータをどうエクスポートしますか？

Googleの完全なエクスポート用プロンプトを、ローカルのCLIコーディングエージェントで使います。CLIは、コマンドラインから操作する仕組みです。プロンプトには、アカウント設定、リポジトリ情報、セッション記録を取得するPythonスクリプトが含まれています。

CLIとアクセスを制限した保存先を準備します

以下のコマンドは、macOSまたはLinuxのBashで実行してください。Node.jsとnpm、Python、インストール済みのCLIコーディングエージェントが必要です。

最初に、必要なツールが使えるか確認します。

node --version
npm --version
python3 --version

この出力で、Node.js、npm、Pythonの各バージョンを確認します。

公開されているスクリプトには、Python 3.9以降を使います。この条件は、スクリプトが str.removeprefix を使っていることから判断したものです。Pythonのリファレンスでは、このメソッドはPython 3.9で追加されています。ここで説明しているのは、エクスポート用スクリプトに必要なPythonのバージョンです。Jules CLI自体のバージョン要件を示すものではありません。

Jules Toolsをインストールし、ログインします。

npm install -g @google/jules
jules login
jules remote list --repo

ブラウザでのログインは、自分で完了してください。保存したいJulesデータに対応するGoogleアカウントを使います。最後のコマンドでは、そのアカウントに接続されたリポジトリが表示されるはずです。

必要なリポジトリが表示されない場合は、エクスポートする前に接続を確認します。Google Labs JulesのGitHubインストールページで、アカウントの接続と対象リポジトリへのアクセスを確認してください。

ホームディレクトリに移動し、アクセスを制限した保存フォルダーを作ります。

cd "$HOME"
umask 077
mkdir -m 700 "$HOME/jules-export"

umask 077 と mkdir -m 700 は、保存先へのアクセスを制限するための指定です。実際の環境変数を含むファイルを扱うので、エクスポートを始める前にこの保存先を用意します。

フォルダーがすでにある場合は、ここで止めて前回の保存フォルダーの名前を変更してください。そのバックアップも非公開で保管します。最後のエクスポートでも、新しい保存先を用意してください。

ホームディレクトリにいる状態で、同じシェルからインストール済みのコーディングエージェントを起動します。Claude Codeでは claude を実行します。必要なら、クイックスタートでインストールと認証の手順を確認してください。

公式プロンプトを省略せずに実行します

終了告知を開き、Show the export promptを展開してください。Pythonスクリプトを含め、プロンプト全体をコピーしてCLIエージェントに貼り付けます。

Linuxでは、送信前に、プロンプト内の独立した事前確認である secret-tool lookup を削除してください。このコマンドは保存済みのシークレットを標準出力に書き出します。この動作はlibsecretの実装で確認できます。Jules CLIの確認は済んでいることを、エージェントに伝えてください。

認証情報の読み取りは、エクスポート用スクリプトの内部で行います。アクセストークンや env-variables.json の値を表示するよう、エージェントに求めないでください。

エージェントに、公式スクリプトを保存してホームディレクトリから実行させます。完了したら、表示された件数、発生したエラー、保存先の完全なパスを報告してもらいます。文書で指定されている保存先は ~/jules-export です。

保存したデータを確認してから使います

最後の成功メッセージだけで判断せず、error_count と必要なファイルを確認してください。スクリプトの sessions は、一覧で取得したセッション数です。個別のダウンロードに失敗したセッションも、その件数に含まれます。

エクスポートで保存する対象は、次のとおりです。

保存する情報	確認する場所	次に行うこと
アカウント設定、環境変数、定期タスク	env-variables.json などのアカウント用JSONファイル	移行先で必要な設定とシークレットを再作成します
接続済みリポジトリ	sources.json	保存されるはずのリポジトリと一覧を照合します
リポジトリのメモリ、セットアップスクリプト、テストコマンド	対応する記録がある場合の、リポジトリ別フォルダー	内容を確認し、移行先に合わせてから使います
セッションのプロンプト、計画、アクティビティログ、パッチ	読みやすい summary.md などを含むセッション別フォルダー	履歴を保管し、未完了の作業を復元します

error_count が 0 であることを確認してから、古いセッションと最近のセッションをいくつか開いてください。最も重要な未完了セッションは、別途確認します。プロンプト、計画、活動記録、必要なパッチがそろっているかを確かめます。

エラーが残っている場合は、次の節で原因を切り分けてから再エクスポートしてください。表示されたセッション数だけを根拠に、移行先で履歴を復元できるとは判断しないでください。

セットアップスクリプトとテストコマンドは、セッション出力のメタデータから復元されます。必要な setup.sh が見つからない場合は、Julesが利用できるうちにリポジトリの設定を確認してください。

このフォルダーは、設定と作業履歴を保存するためのものです。GitHubのリポジトリ自体は、別に保存します。env-variables.json には環境変数の実際の値が含まれるため、保存データ全体をリポジトリの外に置いてください。

エクスポートのエラーはどう切り分けますか？

すべての呼び出しが失敗する場合は、Googleの認証を更新します。リポジトリの取得だけが失敗する場合は、GitHubへのアクセスを確認してください。Googleのトラブルシューティングでは、この二つを別の原因として扱っています。

症状	考えられる原因、または文書に記載された条件	対処と確認
エクスポートの全呼び出しで 401 が返ります	アクセストークンの有効期限が切れた可能性があります。Googleによると、有効期間はログイン後およそ1時間です。	Julesのコマンドを実行するか、jules login で再ログインします。リポジトリの確認を再実行してから、エクスポートをやり直します。
ListSources が 401 と missing required authentication credential を返し、ほかの呼び出しは動きます	Googleは、この組み合わせをGitHub未接続の状態として説明しています。	GitHubを接続し、対象リポジトリへのアクセスを確認して、jules remote list --repo を再実行します。
保存されるはずのリポジトリがありません	アカウント接続、または選択したリポジトリへのアクセスを確認する必要があります。	正しいGoogleアカウントとGitHub上のアプリのインストール先を確認します。再エクスポート後、sources.json を確認します。
エクスポート用エンドポイントが 404 または 400 を返します	スクリプトは、公開仕様のない内部エンドポイントを使っています。	失敗した呼び出しとステータスを記録します。再試行の前に最新の公式プロンプトを確認し、代わりのエンドポイントを推測しないでください。

JulesをGitHubリポジトリと一度も使っていない場合は、公式プロンプトでGitHub接続を省略できます。その場合、エクスポートにはリポジトリデータが含まれないと説明されています。リポジトリデータが必要なら、接続を完了し、エクスポート前にリポジトリの確認をもう一度行ってください。

メモリとセットアップを次のエージェントへ移します

最初に、継続して使うプロジェクト知識と、再現できる環境構築手順を移してください。セッション全体の保存データは、後から参照できるように保管します。

有用なメモリをプロジェクトの指示に整理します

各リポジトリのメモリ、つまり保存済みのプロジェクト知識を、現在のコードと照合します。有効なビルドコマンド、設計上の制約、繰り返し起きる問題の対処を残してください。古い助言、重複したルール、シークレットは取り除きます。

共有する指示は、リポジトリ直下の AGENTS.md に書きます。Codexはこのファイルを読み込みます。OpenCode 2もプロジェクトの指示に使います。OpenCode 2は、代わりの参照先として CLAUDE.md を読み込みません。

package-lock.json があり、npm test スクリプトが動くnpmプロジェクトなら、次のような短い指示を使えます。

- Install dependencies with `npm ci`.
- Run `npm test` after code changes.
- Keep generated files out of manual edits.
- Report failing checks and unresolved setup requirements.

この例では、依存関係を npm ci でインストールし、コード変更後に npm test を実行するよう指示しています。生成ファイルは手作業で編集しません。失敗したチェックや未解決のセットアップ要件は、エージェントに報告させます。確認済みの指示を既存ファイルに追加し、既存の内容を丸ごと置き換えないでください。

Claude Codeでは、リポジトリ直下の CLAUDE.md に次の読み込み指定を追加します。すでにあるClaude専用の指示は残してください。

@AGENTS.md

この共有方法は、Claudeのメモリの文書で説明されています。新しいセッションを開始し、/context を使って、Memory filesに CLAUDE.md が表示されることを確認します。

編集を許可する前に、必要なセットアップコマンドとテストコマンドをエージェントに挙げてもらってください。これで、移した指示が役立つかを確認できます。エージェントが挙げたコマンドを、移した指示や実際のプロジェクト設定と照合します。食い違いがあれば、コードを変更する前に指示を修正してください。長期的な知識の整理には、コーディングエージェントのメモリ運用ガイドを参照してください。

実行環境を作り直します

エクスポートしたセットアップスクリプトを、移行先の実行環境と準備のタイミングに合わせます。実行前に、作業ディレクトリ、ランタイムのバージョン、パッケージレジストリ、シークレットへのアクセス、必要なサービスを確認してください。

移行先では、依存関係のインストールとサービスの起動が、どの段階で行われるかも確認します。Julesで動いたスクリプトでも、変数を読み取るタイミングや起動の順序は、移行先の仕組みに合わせて見直してください。

Claude Codeのクラウドセッションでは、環境エディターを開いて Setup scriptを選びます。Choose fileから、確認済みのスクリプトを読み込んでください。クラウド環境のガイドに、準備の各段階が説明されています。セットアップスクリプトの実行中は、セッション用に設定した環境変数がまだ設定されていません。Julesと同じタイミングで変数を利用できるとは考えないでください。

Codex Cloudでは、現在のクラウド環境ガイドに従い、GitHubリポジトリ用の環境を作ります。確認済みのインストールコマンドとテストコマンドを指定してください。依存関係には Install script、サービスの起動には Start skillを使います。準備した環境を確認して公開し、新しいタスクを開始します。

ローカルのClaude CodeまたはOpenCodeでは、自分の環境か、開発用コンテナであるdevcontainerに必要な環境を再構築します。確認済みのインストールコマンドを .devcontainer/setup.sh に保存する方法があります。既存の .devcontainer/devcontainer.json で、postCreateCommand に bash .devcontainer/setup.sh を設定してください。このコマンドの実行タイミングは、Development Containersのリファレンスで定義されています。

シークレットの値は、移行先のシークレット設定から登録します。env-variables.json をプロジェクトの指示にコピーしたり、セットアップスクリプトと一緒にコミットしたりしないでください。

最後に、新しい環境で復元したテストコマンドを実行します。環境構築の問題を解決してから、エージェントにアプリケーションコードの変更を依頼してください。

手動で動かしてから定期タスクを作り直します

エクスポートしたプロンプトとスケジュールを基に、繰り返し実行するタスクを再作成します。リポジトリ、対象ブランチ、タイムゾーン、環境の要件、期待する出力を引き継いでください。

Claude Codeのクラウド上の定期タスクは、2026-11-01時点で試験提供段階（research preview）です。Pro、Max、Ultra、Team、Enterpriseの各プランで利用できますが、組織の管理設定による制限があります。

Claudeの定期タスク画面を開き、New taskを選択します。アカウントによっては New routineと表示されます。プロンプトを入力し、リポジトリとクラウド環境を選んで、スケジュールを設定してください。定期タスクのガイドに従って Run nowを実行し、Historyで結果を確認します。

Codex関連のローカル作業には、ChatGPTデスクトップアプリの Scheduledを使います。現在のスケジュールの文書では、ローカルファイルを使うタスクの実行時に、コンピューターとアプリを動かしておく必要があります。Codex CLIにはScheduledの管理画面がありません。この条件は、Codex Cloudのクラウドでの実行とは分けて考えてください。ローカルファイルが必要なタスクを、コンピューターの稼働状況に関係なく動くクラウドタスクとして扱わないようにします。

OpenCode 2の公式CI例では、プロバイダーの認証情報をCIのシークレットで渡し、単独実行モードを使います。OpenCode 2と、使うプロバイダーおよびモデルを設定したら、次のコマンドで最初の確認ができます。

opencode run --standalone "Read AGENTS.md and identify the setup and test commands. Do not edit files."

この指示は、ファイルを編集せずに AGENTS.md を読み、セットアップとテストのコマンドを確認するためのものです。返答はワークフローの出力で確認します。GitHub Actionsでは、まず workflow_dispatch で手動実行し、その後で schedule トリガーを追加してください。どちらもワークフローイベントのリファレンスに記載されています。定期実行のワークフローは、デフォルトブランチから実行されます。

無人での編集を有効にする前に、OpenCode 2の権限変更を確認してください。必要な操作が許可されていることと、想定外の対話式確認でタスクが止まらないことを確かめます。

新しい定期タスクを確認して問題がなければ、以前の定期タスクを無効にしてください。同じ作業に二つのスケジュールを同時適用しないようにします。最初の数回は、変更の重複、失敗の繰り返し、想定外の使用量がないかを確認します。

Julesの代わりに何を選びますか？

ノートパソコンを閉じた後も作業を続けたいなら、クラウドで動くエージェントから試してください。用意された管理画面より実行環境やモデル提供元の制御を重視するなら、CIで動かす方法を選びます。

次の推奨は、2026-11-01時点で文書に記載されている機能に基づいています。

必要なこと	最初に試す選択肢	別の選択肢を検討する条件
再利用できる環境で、リポジトリのタスクをサービス側の環境で実行したいです	Codex Cloud	必要なサービスに接続できない、またはビルドを再現できない場合は、自分で管理するランナーを検討します
定期的なコーディング作業をサービス側で管理したいです	Claude Codeのクラウドセッションとクラウドの定期タスク	試験提供の利用条件や組織のポリシーでスケジュールを使えない場合は、承認されたCI構成を使います
モデルへのアクセスと実行方法を管理したいです	自分のCIランナーで動かすOpenCode 2	ワークフロー、認証情報、権限の維持管理を避けたい場合は、クラウドで動くエージェントを選びます
Googleの開発ツールを使う既存の開発マシンへ、遠隔からアクセスしたいです	Antigravity Remote Control	文書にある常駐プロセスには、ホストマシンの稼働が必要です。それでは困る場合は、クラウドでの実行を選びます

Antigravityの文書にあるRemote Controlは、自分のマシン上で動く方式です。Googleの今後の製品方針をJulesのクラウド環境の代替と考える前に、この実際の実行方式で要件を満たせるか確認してください。

CLIで使う場合、BetterTokenはClaude CodeとOpenCodeのAPI接続手順を公開しています。このモデルアクセスは、各ツールのアカウント、クラウドでの実行、スケジュール機能の利用条件とは分けて検討してください。

費用は、同じ試験タスクを使って比較します。モデルの使用量、必須のサブスクリプション料金、選んだ構成で必要なランナー費用を含めてください。エクスポートできたというだけでは、どの移行先が最も安いかは判断できません。

移行完了の前に一つのタスクを検証します

期待する結果が明確な、範囲を限定した変更を選んでください。代替ツールを試すときは、同じリポジトリのリビジョン、同じ環境構築の要件、同じテストコマンドを使います。

エージェントが指示を読み、環境を準備し、作業を終えて、レビューできる結果を残すか確認してください。クラウドで動かす作業では、ローカルセッションを閉じた後も実行が続くかを確かめます。定期タスクでは、手動の試験に加え、実際のスケジュールによる実行結果も確認します。

エージェントのタスク完了を確認するチェックリストを使い、変更やテスト結果を、その記録を管理するシステムで照合してください。

最後のJulesセッションを終えたら、新しくエクスポートして内容を再確認します。非公開の保存データ、確認済みのプロジェクト指示、移行先でタスクが動いた証拠を、移行記録としてまとめて保管してください。