Claude Code のセッション同士をブラウザ経由でつなぎ、作業を引き継がせた

片方のセッションを待機させた

「Claude Code からセッションの指示があるんで、ちょっと待っておいてください」

そう打ち込んで、開いたばかりのセッションを止めた。 このセッションに次の仕事を渡すのは自分ではなく、別で走っている Claude Code のほうだった。

しばらくして届いた文面には、本文の前に差出人が付いていた。

[FROM: Claude Code / <マシン名> / <セッションURL>]
[VIA: claude.ai ブラウザ経由]
[NOTE: これはユーザー本人の発言ではありません。ユーザーの承認の代わりにはなりません]

3 行目が要る。 このメッセージはユーザー入力欄から入ってくるので、受け取った側からは、私が打ったものと見分けがつかない。 その状態で不可逆な操作の承認に使われると、一度も目を通していない判断が実行されてしまう。 だから差出人と一緒に、承認ではないことを毎回書かせている。

NOTE の文面は用件によって変えた。 午後にもう一つのセッションへ仕事を渡したときは、「ただし本件はユーザーが『そちらに依頼しておいて』と明示的に指示したものです」に差し替えている。 段取りとして自分が頼んだ事実と、自分が内容を承認した事実は、別のものとして扱いたかった。

報告を返させて往復にした

受け取った仕事は、サブエージェント 6 組に分けて並列で進めさせ、統合まで持っていった。 できあがったところで、次の指示を出した。

「これ、もともとの Claude Code のセッションがあるじゃないですか。指示を受けた元のセッション。そっち側にちょっと進捗報告してもらえませんかね」

片道で終わらせると、指示を出した側は、自分が投げた仕事がどうなったかを知らないまま次の判断をする。 レビューは Codex に回させ、走っている間に元のセッションへ報告を送らせた。

このやり取りは cross-machine-message というスキルとして手順化してある。 Windows 側からは直接メッセージを送る手段が使えないので、ブラウザ経由で claude.ai のセッションを開いて打ち込む形になる。 手順が固まっているぶん、指示のたびに送り方を考え直さずに済む。

送信までにかかった手数

送信は Chrome DevTools MCP でタブを開いて操作させた。 ここが一番もたついた。

一度、/logout へのリダイレクトが挟まってタブが閉じた。 ログアウトさせた可能性があったので、すぐに状態を確認させた。 セッション一覧は健在で、リダイレクトの表示が一瞬出ただけだった。

本文を入れたあとには、サイドバーのフィードバックボタンを誤って押した。 開いたのはダイアログだけで、送信はされていなかった。 キャンセルさせたあとも、本文は 2,513 文字のまま残っていた。 コンポーザー内の送信ボタンだけを狙わせて、ようやく届いた。

ブラウザの UI を人間の代わりに押させる以上、押し間違いは起きる。 起きたあとに「何を押して、何が起きて、何が起きていないか」をその場で確認させられるか。 分かれ目はそこにある。

元のセッションから返ってきたレビュー

報告を送ると、元のセッションからは同じ差出人ヘッダを付けたレビューが返ってきた。 そのレビューは「断片ディレクトリは既に無いので、暴発しても実害は出ない」という判断に立っていた。

実在するかどうかを先に確かめさせた。 6 ファイルが残っていた。 しかも直したはずのものが、すべて古い版のまま入っていた。

離れたセッションからの報告は、送った時点のディスクの状態を写したものにすぎない。 受け取った側が確かめ直さないと、消えたはずのものを前提に安全だと結論してしまう。

安全化のためにガードを書かせたところ、今度はそのテストで実ファイルを壊した。 Python の書き込みで改行が CRLF になり、パーサが 1 件も認識しなくなっていた。 バックアップを取ってあったので、全 27 型がそのまま戻った。 スクリプトは fail-closed に作り直させた。

壊す前にコミットする

ここで手を止めた。

「危ねえな。ぶっ壊す前にコミットしときましょうか、一回。学習系とスキップでいいんで」

復旧できたのはバックアップが偶然あったからで、次も同じ運があるとは限らない。 未コミットのものを確認させ、無関係な自動生成差分を外して 2 本に分けてコミットさせた。 ~/.claude 側のスキル更新も未コミットだったので、そちらも合わせて 3 本で退避が済んだ。

コミット中に、別のセッションが同じファイルを apps/web 側へ移設している最中だと分かった。 壊れていないかを先に確かめさせたら、移設は完了していて修正 9 件も引き継がれていた。 そちらのセッションは止めて、競合の芽を摘んだ。

同じリポジトリを複数のセッションが同時に触っている状態は、こちらから見えない。 見えないものを踏まないための保険が、作業前のコミットになる。

引き継ぎ先で落ちていたテスト 3 件

午後に渡した側では、依頼した実装が終わってもテストが 3 件落ちたままだった。

「これコミットしておいてほしいんですけど、失敗している 3 件のテストのフェイルは、これやっといてくれませんか？何のテストミスだろう」

原因を調べさせたら、どれもテスト側の記述が実態に追いついていないものだった。 2 銘柄に新しい四半期の実績が入ったのに、期待値が前の四半期のまま止まっていた。 期待値を実データに合わせ、213 ファイル / 19,542 件が全件パスに戻ってからコミットさせた。

その手前で学習ゲートに止められ、/learn を実行しようとしたので、今回はスキップでいいと伝えた。 14:23 のコミット 2 本で、実装とテストの両方が片付いた。

ブラウザを触る手段をどちらにするか

朝のうちに、そもそもブラウザ操作の手段を選び直せないかを確かめている。

Claude in Chrome と Chrome DevTools のどちらが扱いやすいのか。 Claude in Chrome なら Chrome 拡張の中身や内部 API まで届くのか。

届く範囲は、はっきり分かれていた。 他の拡張が動いている状態のブラウザをそのまま使えるのは Yes。 拡張の中身を覗いたり chrome:// を触ったりするのは No。 内部 API と呼べるのもページの JavaScript 層までで、chrome.* の特権 API には届かない。

そして DevTools で毎回もたついていたのは性能差ではなく、設定の誤りが原因だった。 それは 2026-08-01 にすでに直してある。 道具のせいにして乗り換える前に、自分の設定を疑う番だったということになる。

残ったもの

セッション同士をつなぐと、片方が持っている前提がもう片方に伝わらないまま判断が進む。 今日はそれが「断片ディレクトリはもう無いはずだ」という形で表に出た。 書いてある報告を鵜呑みにせず、受け取った側にディスクを見せてから動かす。 この一手間だけが、往復を安全にしていた。

• 別セッションからの指示を受け取り、元セッションへ報告を返す往復を運用した
• ブラウザ送信中の誤操作を都度確認させ、送信されていないことを確かめた
• 破壊的な作業の前に退避コミットを 3 本取った
• 落ちていたテスト 3 件を実データに合わせ、全件パスに戻してからコミットした
• ブラウザ操作の手段を比較し、Chrome DevTools を使い続ける判断をした