Google Julesがサービス終了へ：データ保存と移行先の選び方

Google Julesはいつ終了する？作業に影響する日程

Googleのバックグラウンド型コーディングエージェント、Google Julesは、11月11日を過ぎると読み取り専用となり、その後サービスを終了します。GoogleのJules終了のお知らせは、2026年10月29日付で公開されています。

告知には、切り替えの時刻やタイムゾーン、API単独の終了日、ライセンスの期限、請求・返金の日付、終了後のデータ保持期間は記載されていません。いずれも未回答の項目であり、上の表から推測できる日程ではありません。

修正作業が途中の開発者は、Julesで仕上げるか、パッチと残りの要件を新しいタスクに引き継ぐかを、まず判断する必要があります。開発責任者にとっての急務は、通常のコードレビューでは見えにくい依存関係の洗い出しです。繰り返し使うプロンプト、環境構築の手順、リポジトリの権限、認証情報がこれに当たります。

Julesに作業を任せているなら、今から対応を始めましょう。 完了した変更がすでにマージされており、Jules側の記録も不要なチームは、移すものが少なく済みます。Julesで進行中の作業がなく、エージェントを比較している段階なら、エクスポートを省いて後述する実行環境の検討から始められます。長期的に使うベンダーの選定に時間をかけるのは妥当ですが、作業の保存まで先延ばしにすべきではありません。

Gitリポジトリに残っていない情報を保存する

GitHubにすでにあるコード、ブランチ、プルリクエストは、そのまま残ります。Googleのエクスポート対象は、Julesが保持する設定、環境変数、スケジュール、リポジトリ接続、メモリ、セットアップスクリプトに加え、セッションのプロンプト、計画、ログ、パッチです。詳細は公式のエクスポート手順を参照してください。

プルリクエスト（PR）は、コード変更を提案する仕組みです。パッチ自体は残せても、エージェントがその変更を選んだ理由までは残らないことがあります。テストの成功に欠かせなかったパッケージのインストール手順が、セットアップスクリプトにしか書かれていないかもしれません。一見よさそうなリファクタリングを見送った理由が、メモリに記録されている場合もあります。別のエージェントへの指示に転用する前に、こうした情報に目を通してください。

エクスポートはアーカイブとして保管し、未完了のタスクごとに、必要な情報だけをまとめた引き継ぎ資料を作ります。リポジトリとブランチ、目指す変更、完了済みの内容、残っている受け入れ条件、成功を確認できるコマンドを含めましょう。新しいプロンプトに会話を丸ごと貼り付けるのではなく、根拠となる記録へのリンクを添えます。

たとえば依存パッケージの更新なら、「アップグレードを仕上げて」だけでは足りません。どの互換性の問題が残っているのか、どのファイルを変更したのか、どのテストで不具合を再現できるのかを残します。次のエージェントには作業範囲が明確になり、レビュアーには未完成の成果物を差し戻す判断基準ができます。

Googleが公開した手順でエクスポートする

Googleが案内している方法は、Jules Toolsと提供されたエクスポート用プロンプトを使うものです。まずインストールと認証を行います。

npm install -g @google/jules
jules login

ホームディレクトリでCLIのコーディングエージェントを起動し、告知内で展開したプロンプトを貼り付けます。リポジトリのデータを取得する場合は、先にGitHubを接続してください。出力先は~/jules-exportです。env-variables.jsonには認証情報の値が含まれるため、公開しないでください。セッションごとの記録には、summary.md、アクティビティログ、差分が含まれます。

完了メッセージだけでは、必要な情報がすべて揃ったとは判断できません。 Googleが公開したエクスポートスクリプトを読むと、セッション数には一覧に載ったセッションが計上され、個別の詳細取得に失敗したものも含まれることが分かります。エラーは別途報告されます。また、セットアップコマンドはセッションの出力から回収されます。リポジトリを別の環境に移せると判断する前に、実際に書き出された内容を確認してください。これは公開スクリプトを読んで得た所見であり、本記事のためにエクスポートを実行したわけではありません。

移行を承認する責任者にとって、この違いは重要です。「コマンドが終了した」だけでは、「必要なパッチ、設定、タスクの背景情報が揃っている」ことの裏付けにはなりません。重要な記録が欠けているなら、次のエージェントに推測で再構築させるのではなく、まだアクセスできるうちに回収しましょう。

履歴とJules APIはどうなる？

履歴はローカルに保存し、自動処理のJules依存を解消しましょう。終了告知では、別のエージェントへの履歴の自動取り込みも、サービス終了後のAPI提供継続も約束されていません。

Googleの公開Jules APIドキュメントには、セッションとそのアクティビティについて、作業の作成、計画の承認、メッセージの送信などが説明されています。こうした機能への依存も、作業の実行に影響します。Issueに対応してセッションを作成するボットがあるなら、チームの誰もJulesのWebサイトを開かなくても、代替手段が必要です。

Julesを呼び出すスクリプト、ワークフローファイル、連携機能を洗い出してください。それぞれが受け取る入力、成功とみなす応答、結果の出力先を記録します。プロンプトだけを変えても、既存の連携がJulesのセッションIDを前提にしていたり、Julesのアクティビティをポーリングして完了を確認していたりすれば、移行は失敗します。

APIのクイックスタートが公開されたままでも、それをサービス提供期間の延長と受け取ってはいけません。エンドポイントについて別の日程が示されていない以上、サービス全体の日程を計画の基準にし、読み取り専用になる前にタスク作成を移行します。これは運用上の推奨事項であり、Googleが別途発表したAPIの終了日ではありません。

履歴については、保存できることと、作業をそのまま再開できることを分けて考えます。保存した計画は、別のエージェントがタスクを理解する助けになりますが、以前のエージェントの実行環境を復元するものではありません。Julesを開かなくても別の開発者が次の手順を再現できるよう、作業を完了させるか、途中の状態を保存して引き継げる形にしてください。

Antigravityに引き継がれるものと、今使える機能は？

Googleは、Julesから得た知見をエージェント開発プラットフォームのGoogle Antigravityに取り込むとしています。GoogleのJules公式発表によると、リモートで自律的に進むバックグラウンド実行と、Antigravityの開発環境を組み合わせる取り組みが進行中です。ただし、その提供時期は示されていません。

現在提供されている製品にも、バックグラウンド作業に役立つ機能があります。Antigravity Appは、並行して動くエージェントの管理、Projectsへの作業の集約、スケジュール実行に対応しています。GoogleのRemote Controlドキュメントでは、ノートPC、デスクトップPC、サーバー上で動くセッションにブラウザからアクセスする方法が説明されています。

確認すべき違いは、実行するコンピューターを誰が用意するかです。Remote Controlは、すでにあるマシンを操作するための窓口です。それだけでは、GoogleがJulesの代わりになるホスト型の実行環境を用意したことにはなりません。夜間のメンテナンスを任せたいチームは、どのマシンが稼働し続けるのか、依存関係を誰が管理するのか、そのマシンが使えなくなった場合にどうなるのかを把握する必要があります。

移行手順： Antigravityでリポジトリを開き、必要なセットアップと指示を再構築してから、明確なテストを伴う小さなタスクを実行します。リモートアクセスを前提とする場合は、対象マシンとその稼働状況を確認してください。そのワークフローがレビューを通過してから、定期実行のスケジュールを追加します。

Antigravityの開発環境を使いたく、実行用のマシンも運用できるなら、Antigravityが候補になります。「開発者がノートPCを閉じても作業が進み、別のマシンを誰も管理しなくてよい」ことが要件なら、提供時期の決まっていない機能に切り替えを委ねず、今あるホスト型の選択肢を検討してください。

利用条件と上限の判断にはAntigravityの料金ガイドを参照してください。日常の開発環境としてどちらが仕事に合うかは、別の論点としてGoogle AntigravityとCursorの比較で扱っています。

バックグラウンド作業を、運用できる実行環境へ移す

エージェントの文章の書き方を比べる前に、ランタイムを選びましょう。ランタイムとは、タスクを実行するコンピューターとソフトウェア環境のことです。今回の移行では、その環境を自分たちで運用するのか、ベンダーがホストするのか、GitHub Actions上の自動処理として実行するのかを比べることが重要です。

以下は、各ベンダーの現行ドキュメントに基づく移行の出発点です。機能が同一であることや、Julesと共通のインポート形式があることを示すものではありません。

OpenAI Codex Cloud：セットアップを再利用できるホスト型タスク

OpenAI Codex Cloudは、手元のコンピューターがスリープしていても作業を続けられる、ホスト型のコーディングエージェントです。タスクごとに専用のワークスペースがあり、コミットやPRの作成に進む前に、変更内容とテスト結果を確認できます。現在のセットアップ手順は、Codex Cloud公式ガイドに記載されています。

移行手順： ChatGPTでWork in > Cloudを選択し、環境を作成するか、既存の環境を選びます。GitHubリポジトリを接続し、Codexにプロジェクトの準備を任せ、セットアップ時の確認結果をレビューしてから環境を公開します。整理したJulesの引き継ぎ資料を使って、範囲を絞ったタスクを開始し、変更内容とテスト結果を確認してください。

障壁になりやすいのは、環境から必要なリソースへアクセスできるかどうかです。クラウド上のタスクがパッケージレジストリや必要なサービスに接続できなければ、ローカルでテストに成功していても十分な確認にはなりません。環境設定に必要なネットワーク接続先と認証情報を登録し、そこで同じテストを実行してください。

プロジェクトのセットアップを再利用できるホスト型のタスクキューが主な要件なら、Codexが候補になります。最初は終わりの見えない書き直しではなく、成果物の正しさを短時間で判断できるタスクで試しましょう。今回の終了対応にとどまらないワークフローの選び方は、CodexとClaude Codeの比較で扱っています。

Claude Code：クラウドセッションとリポジトリの自動処理

AnthropicのClaude Codeには、ノートPCを閉じても動き続けるクラウドセッションと、リポジトリのワークフロー向けのGitHub Actions連携が、それぞれ用意されています。対話を通じたタスクの引き継ぎを置き換えるのか、自動実行のトリガーを置き換えるのかによって、適切な移行方法が変わります。

クラウドセッションの場合： リポジトリを接続し、クラウド環境のセットアップ、ネットワークアクセス、変数を設定してから、範囲を定めたタスクを開始します。認証済みのClaude Codeのターミナルからは、claude --cloudでクラウド上の作業を開始できます。通常のGitHubからクローンする方式では、セッションに意図したコミットが渡るよう、先にブランチをプッシュしてください。詳しくはClaudeのクラウドセッションガイドを参照してください。

ここで確認が必要なのは、共通の利用枠とアクセス権です。クラウドセッションはアカウントのClaude利用枠を消費し、組織の権限設定によって制限されることがあります。個人の環境で動いても、会社のアカウントで同じ量の作業を実行できるとは限りません。

GitHub Actionsの場合： リポジトリの管理者がClaude Codeで/install-github-appを実行し、認証の設定を進め、生成されたワークフローのPRをレビューします。まずは明示的な@claudeへの依頼で試し、その後、置き換え対象の定期実行やイベント駆動のジョブを追加してください。アプリ、認証情報、ワークフローの要件は、AnthropicのGitHub Actionsガイドに記載されています。

こちらで課題になるのは、ワークフローの管理責任です。トリガー、認証情報、権限を維持し、セットアップの失敗とコーディング作業の失敗を切り分ける担当者が必要になります。リポジトリ内のイベントを起点とするのが自然なら、Actionsが適しています。この運用方法は、当サイトのClaude CodeとGitHub Actionsの連携ガイドで解説しています。

GitHub Copilotのコーディングエージェント：GitHub内で引き継ぐ

GitHub Copilotのコーディングエージェントは、GitHubのワークフロー内でバックグラウンドの実装とテストを行います。現行ドキュメントでは、クラウドサンドボックスとGitHub Actions環境が区別されているため、タスクでどの環境が選ばれているかを確認してください。詳細はGitHub上のCopilotを参照してください。

移行手順： 契約プランでの利用可否と組織のポリシーを確認し、リポジトリとブランチを選択します。Copilotには、受け入れ条件とPR作成の依頼を含むタスクを渡してください。提案された変更とテストの裏付けを確認してからマージします。Julesの棚卸し時にまとめたIssueの説明を引き継ぐことで、移行先が要件を満たしたか判断できます。

制約は実行環境によって異なります。GitHub Actionsのセッションで変更できるのは単一のリポジトリですが、クラウドサンドボックスのセッションは複数のリポジトリを扱えます。どちらもタスクごとに単一のブランチで作業し、単一のPRを作成します。ブランチをまたいで整合性のある変更が必要な移行は、個別にレビューできる作業へ分割してください。

レビュー待ちの管理とタスクの担当割り当てをすでにGitHubで行っているなら、Copilotが候補になります。IssueやPRに近い場所で引き継ぎを進められますが、Julesが保持していた環境と指示の再構築は必要です。

エクスポートだけで自動移行できるわけではない

「JulesはAntigravityに移る」という説明を、そのままアカウント移行の計画だと受け取るのは早計です。Googleが説明しているのは、製品の方向性とデータのエクスポートです。進行中のセッション、スケジュール、メモリが、そのまま実行可能な状態で移行先に現れるとは約束していません。

ブラウザからアクセスできることを、クラウド実行の証拠とみなすのも誤解です。ブラウザは、自分たちで運用するマシンも、ベンダーがホストするマシンも操作できます。画面が似ていても、作業を動かし続ける責任の所在は異なります。

実用的な合格基準を設けましょう。移行先で必要なセットアップを再現でき、範囲を限定したタスクを完了し、検証結果を確認でき、レビュー可能な変更を受け取れることです。同じリポジトリを認識したり、もっともらしい計画を出したりするだけで選んではいけません。計画は理解の裏付けとして役立ちますが、移行が機能する証拠は、実際にワークフローが成功することです。

開発責任者にとって、この基準があれば判断範囲を絞れます。サービス終了までに、今後使うコーディングツールの好みをすべて確定する必要はありません。そのままでは止まってしまう仕事を実行するための検証済みの手段と、失敗の原因を調べられる担当者が必要です。

今週進める移行チェックリスト

まずは移行先で実際に動く作業を確立し、その方法を残りのバックログへ広げましょう。

• 棚卸し： Julesで使うリポジトリ、未完了のセッション、定期タスク、APIの呼び出し元を一覧にします。継続する仕事ごとに担当者と移行先を決めます。
• 保存： Googleのエクスポート手順を実行し、エラーと重要なファイルを確認して、元のアーカイブを非公開で保管します。
• 完了または途中保存： 未処理のパッチをレビューし、継続するタスクには、引き継ぐ人が理解できるブランチ、要件、テストを残します。
• 再構築： 選んだ実行環境の依存関係、指示、ネットワークアクセス、認証情報を設定します。通常のタスクメモにシークレットの値を書かないでください。
• 検証： 小さなタスクで、セットアップ、実装、テスト、人によるレビューまでを通して実行します。PRの成功だけでなく、失敗時の処理も確認します。
• 切り替え： 移行先で動くことを確かめてから、定期実行のトリガーを移します。重複したタスクの投入を止め、不要になった古いアクセス権を廃止します。

週明けに取り組むなら、稼働中のリポジトリを選び、Julesが保持する作業情報をエクスポートして、移行先で小さなタスクをレビューまで完了させましょう。サービスが新たな作業を受け付けなくなる前に、ほかの仕事にも繰り返し使える移行方法を確立できます。

開発ツールの変化に対応する実践的なガイドを、ニュースレターで受け取れます。