Docker Sandboxes から Claude Code に移った決め手は指示の出し方
個人で複数のサイトと bot を運用し、開発や運用を AI エージェントに任せています。私が話しかけるのは 1つの指示役のエージェント（私の呼び名は「秘書」）だけで、指示役のエージェントは作業をサブエージェントに渡し、PR で受け取ります。この形を回す場所を、手元の Docker Sandboxes（Docker が用意する、AI エージェント用の使い捨ての実行環境）から Claude Code のクラウドに移しました。決め手は鍵（エージェントが外部サービスを使うための API トークンやログイン状態）や料金ではなく、今の形がそのまま動き、話題ごとに分けた指示をスマホからでも出せることでした。
手元ではサンドボックスもセッションも 1つで、話題を分けるには作業ツリー（1つの clone から別のブランチを別のディレクトリに同時に展開する git の機能）を手で切るしかなく、ここら辺をどうやって自動化するか、どういう仕組みだともっと楽に運用できるか悩んでいました。
執筆時点で、その悩みを直接解決してくれるのが移行先の クラウドセッション（Anthropic が管理する VM で Claude Code を動かす機能）と Claude の Projects（1本の長く続く会話と、それが立てるスレッドでできた器）です。
長く動く指示役のエージェントの文脈が汚れないかは、会話の長さより記録の鮮度の問題だと私は見ています。Projects では全体を見る会話そのものが定期的に入れ替わり、記録から続くためです。
指示役のエージェントが作業を配る形が、Projects では器の機能として用意されている
手元の形では、事業の文書だけを置いたリポジトリを開いたセッションを指示役のエージェントにしています。指示役のエージェントはサイトや bot のリポジトリに Issue を書いてサブエージェントに渡し、PR で受け取ります。指示役のエージェントは判断と検証に専念して手を動かさず（サブエージェントに作業を渡す親のエージェントには、コマンドを叩かせない）、記憶は git だけに置いてサンドボックスは消える前提です（AI エージェントの記憶を git だけに置き環境は捨てる「秘書戦略」）。
クラウドを比べるときに私が見ていたのは、エージェントを起こす仕組みではなく、指示の起点がどこにあるかでした。Docker Sandboxes のクラウド版を含め、私が調べた各社のクラウドは、人が各セッション・各ブランチに直接指示を出す作りになっています。私が欲しかったのは、指示を出す相手は指示役のエージェントだけで、指示役のエージェントが手を配る形です。
Projects はこの形を器の機能として持っています。Project は、Claude がコーディネータ（Project の会話で指示を受ける Claude）を務める 1本の会話と、それが立てるスレッドでできています。私の形に当てはめると、コーディネータが指示役のエージェントで、スレッドがサブエージェントの作業に当たります。
- コーディネータは送られた物を受け取り、どれをスレッドにするか決め、スレッドを追跡する
- スレッドは原則クラウドセッションで、1本につきブランチ 1本
- スレッドは自分の PR の CI の失敗やレビューに自動で対応する
Project に事業の文書のリポジトリを登録すると、全スレッドが開始時にそれを clone し、そこに置いた CLAUDE.md を読みます。
ちなみに、Claude が GitHub でアクセスできるリポジトリなら、必要になったタイミングでコーディネータやスレッドが自分で Project に足すため、プロジェクト設定の煩わしさがないことも大きなメリットです。。
話題ごとにセッションとブランチが分かれ、作業ツリーを手で切らなくてよい
これまでは、違う話題を同時に頼むと、1つの指示役のエージェントの文脈に 2つの話題が混ざるか、作業ツリーを切って別のエージェントを走らせるしかありませんでした。
同じ clone を複数のエージェントが触らないよう、エージェントごとに作業ツリーを切る規則を置いていました。それでも事故が起き、切った作業ツリーも溜まっていきました。
- 作業ツリーの作成に失敗したのに後続のコマンドが本体の clone で走り、main にローカルのコミットが乗った。push する前に戻した
- 数えたときには、サンドボックスに作業ツリーが 10個近く残っていた
指示役のエージェントの失敗の型の 1つも「2つの話を混ぜる」でした。長い経緯を 1セッションに抱えると判断が落ちるため、セッションは主題か日で切る規則も置いていました。
Projects では、話題ごとに別の Project やスレッドになります。スレッドはそれぞれ独立したクラウドセッションとブランチなので、作業ツリーを手で切る必要が無く、文脈も混ざりません。主題ごとに Project を分け、それぞれのコーディネータを指示役のエージェントにする形のほうが良いと見ています。
私の Project の 1つでは、2026-09-26〜09-29 の 4日間でスレッドが 30本立ちました。2026-09-27 には、別々の記事 9本のスレッドが 1分ほどの間に立ち、並行で進みました。
コーディネータは定期的に入れ替わり、引き継がれるのは記録だけ
Projects の公式ドキュメントによると、Project ではコンテキストウィンドウを管理しません。スレッドは自動で圧縮され、コーディネータは全履歴ではなく最近のメッセージと最近のスレッドとプロジェクトの記憶を元に動くので、Project が続く限り続けられます。決して落としてはいけない物はプロジェクトの記憶に置くよう書かれています。プロジェクトの記憶（MEMORY.md というファイル）は、全スレッドが開始時に読みます。
コーディネータが入れ替わること自体はドキュメントに書かれていません。コーディネータ自身に聞くと、Claude が役に就くときにシステムから渡される説明に書かれているとのことでした。コーディネータは更新や稼働時間の上限のために定期的に入れ替わり、後任は前の会話を持たずに始まって次の 3つを引き継いで続けます。
- 直近のやり取り
- スレッドの一覧
- 記憶ファイル
どのくらいの頻度や条件で入れ替わるかは見えません。実際に後任には「前の担当は入れ替えられたので引き継ぐ」という通知が来ます。前日に仕事を頼んだコーディネータと翌日のコーディネータも別のセッションでした。
コンテキスト汚染の面では、スレッドは毎回まっさらに始まり、他のスレッドの中身は自動では入りません。全体を見る側も入れ替わるので、1つの会話が長くなり続けることはありません。
引き継がれるのは記録だけなので、前述の記憶を git だけに置く設計がそのまま引き継ぎになっています。全スレッドが開始時に読むリポジトリの CLAUDE.md に規則を置き、スレッドは 1本ごとに作業記録（目的・分かったこと・決めたこと・やったこと・持ち越し）を main に直接書き、判断は決定の記録として残しています。後任のコーディネータもスレッドも、これを読んで続けています。
弱い所は、古い記録もそのまま引き継がれることです。コーディネータが作業記録に残っていた古い一行を信じ、「下書き 7本があなたの OK 待ち」と私に伝えたことがありました。実際は全部公開済みで、CMS には下書きが 1本もありませんでした。いまは公開・下書き・PR の状態を答えるときは、記録ではなく CMS や PR の今の状態を見てから答える規則にしています。
スマホからでも、チャットに一言送れば話題ごとにスレッドが立つ
Projects は claude.ai/code、デスクトップアプリ、スマホアプリから使えます。手元の CLI からは使えません（2026-09-25 取得のドキュメント）。
私がするのは、Project のチャットに一言送ることだけです。コーディネータが話題ごとにスレッドを立てます。
- Project を立てた日に「サイトのリポジトリは操作しないのか」とチャットで聞いたら、コーディネータが 1分ほどでそのリポジトリを Project に足し、以後のスレッドは両方を扱えるようになった
- 公開済みの記事が表面的だとチャットに一言書いたら、書き直しのスレッドが立ち、そのまま下書きまで進んだ。
私の判断を待っているスレッドは、コーディネータがチャットに 1行で出し、私はチャットで答えます。スレッドを開きに行く必要はありません。Overview の画面も、スレッドをレビュー待ち・返事待ち・作業中のような状態ごとに並べます。スマホからも指示が出せ、クラウドセッションを含めてアプリの作りが良いと感じています。
Docker の側にも候補はありましたが、Docker Sandboxes のクラウド版は sbx（Docker Sandboxes の CLI）から動かすので、スマホからは扱いにくい作りです。手元のセッションをスマホから操る Remote Control もありますが、手元で claude のプロセスが動いている間だけ使える仕組みで、マシンを起こしておく前提は消えません。
鍵と料金は、移る妨げにならないことを確かめただけ
手元の Docker Sandboxes の強みは、手元のマシンを鍵の置き場にできることです。有効期限が 1時間のトークンを取り直したり、手元のマシンでのログイン状態や MCP サーバーを借りたりできます。弱点は、マシンが起きている必要があることです。
クラウドの 2つは、料金の取り方は違いますが、鍵の扱いはほぼ同じでした。
- 実行環境: Docker Sandboxes のクラウド版は Docker 管理の microVM / Claude Code のクラウドセッションは Anthropic 管理の VM
- 料金: 4 vCPU / 8 GB で 1時間 0.28ドル、起動から停止まで課金（準備とアイドル含む） / VM の別料金は無く、プランの利用枠を共有する
- 鍵: どちらも静的なトークンはプロキシが差し込み、1時間で切れるトークンの取り直しと手元のログイン状態は使えない
- エージェント: 持ち込み / Claude Code
（Docker 側は 2026-09-24、Claude Code 側は 2026-09-27 に取得した情報）
クラウドに移せない鍵がどちらでも同じだったので、エージェントが直接持つ鍵を GitHub、このブログの CMS、Cloudflare の 3つに絞り、手元のマシンを鍵の置き場にする強みを要らなくしました。鍵の型ごとの扱いは Claude Code のクラウドセッションに持ち込める鍵と持ち込めない鍵 に書いています。
Docker Sandboxes に残る利点は、Claude Code 以外のエージェントも動かせる、慣れている、特定の会社に縛られない、の 3つです。こだわらない理由も 3つあります。課金先が増えること、各社の性能が拮抗していて乗り換える機会が実質無いと私は見ていること、Claude Code を使う以上は Anthropic の仕組みが素直なことです。残ったのは「慣れている」だけでした。
移っても、判断待ちの出し漏れ・スレッドの上限・放置での消去は残る
- 判断待ちの出し漏れ: コーディネータが私の判断を待っているスレッドをチャットに出すかは振る舞いで、仕組みとして強制できない。出し漏れが実際に起きた
- スレッドの上限: 新しいスレッドは 1日 200本まで。利用はプランの上限から引かれ、単独のセッションより早く減る（2026-09-25 取得のドキュメント）
- 放置での消去: クラウドは放置で消え、push していない物は残らない
最後の 1つは、手元の Docker Sandboxes も消える前提で設計していたので、記録を git に置く仕組みがそのまま効いています。