AIに、別のAIへ指示を渡させる——2アカウント連携で実際に踏んだ3つの穴

Claude Code で作業していて、片方のアカウントが週間の利用制限に当たりました。手元にはもう一つ、 別契約のアカウントがあります。ならそちらで続ければいい——のですが、これが思ったより面倒でした。

何をどこまでやったか、どのファイルが正本か、何をやってはいけないか。経緯を全部貼り直す必要があります。 それが面倒で、結局しばらく作業が止まっていました。

止まっていた時間を後から数えたら、実稼働2時間45分に対して停止7時間57分。 そのうち3時間50分は「作業を終えて報告し、次の指示を待っていた」だけの時間でした。 道具ではなく、段取りの問題です。

この記事は、その段取りを直したときの具体的な手順と、実際に踏んだ失敗の記録です。 2台で分担させること自体の考え方は 別の記事に書いたので、ここでは手を動かす側だけを扱います。

やったこと：片方から片方へ、人間を経由せずに指示を投げる

2つのアカウントを、同じ端末マネージャ（ここでは Orca）の左右のペインで開きます。 そのうえで、片方のターミナルからもう片方のターミナルへ直接文字を送れるようにしました。

まず相手のIDを調べます。

orca terminal list

返ってきた一覧から相手のターミナルIDを拾って、指示を送ります。

orca terminal send --terminal term_yyyy --text "指示の本文" --enter

これだけです。左のペインで動いている Claude Code が、右のペインの Claude Code にタスクを渡せます。 人間がコピペする必要はありません。

踏んだ穴 1：--enter を忘れると、送信は成功するのに何も起きない

これで一度、30分近く無駄にしました。

--enter を付け忘れると、文字は相手の入力欄に入りますが、実行されません。 厄介なのは、送った側には Sent 383 bytes のように成功が返ってくることです。 相手が黙っているので「考え込んでいるのかな」と待ってしまいます。

対処は2つあります。

• 送信後に必ず orca terminal read で相手の状態を見る。実行中の表示が出ていれば通っている
• 取り残しに気づいたら、改行だけを送れば実行される

「送信成功」と「実行開始」は別物——これが最初の教訓でした。

踏んだ穴 2：相手の画面は「読めない」と思ったほうがいい

orca terminal read で相手の画面は取れます。ただ、ターミナル上で動くUIは 書き換えが激しく、結論だけを綺麗に抜き出すことはできません。 実行中かどうかの判定には使えますが、成果物の中身をここから拾おうとすると失敗します。

そこで結果は必ずファイル経由にしました。指示の中にこう書いておきます。

結果は D:/path/to/RESULT.md に書いてください。
終わったら末尾に STATUS: DONE と入れてください。

司令塔側はそのファイルだけを読みます。画面を読み取ろうとするのをやめた時点で、確実になりました。

踏んだ穴 3：長い指示は、そのまま送らない

シェル経由で長文を送ると、引用符やバックスラッシュで壊れます。 日本語のWindowsパスは特に危ない。D:\共有フォルダ\2026... の \2 が 制御文字として解釈されて、パスが別物になる事故を実際に起こしました。

対策は単純で、長い指示はファイルに書いて、パスを1行だけ送ることです。

orca terminal send --terminal term_yyyy --text 'D:/path/to/handoff.md を読んで、そのまま作業に入ってください' --enter

ファイルの中に、文脈・担当・禁止事項・完了条件を書いておきます。 ここで大事なのは、受け取る側はコンテキストがゼロだと想定して書くことです。 チャットをリセットした直後の相手が、そのファイルだけで動き出せるか。それが基準になります。

実際に使っている引き継ぎファイルの形

• 1. 何が起きているか（30秒で）——今の状況。数字を入れる
• 2. あなたの担当——何を、どこまで
• 3. 手順——順番に
• 4. 禁止事項——やってほしくないこと
• 5. 終わったら——結果をどこに書くか、何を記録するか

意外に効いたのが禁止事項でした。自律的に動く相手ほど、 「やること」より「やってほしくないこと」を明示する必要があります。 実際にこちらで書いているのは、たとえば「push しない」「個人情報を公開側に持ち込まない」といった行です。

効果と、向いていないこと

効果は3つありました。人間がコピペする回数がゼロになったこと。片方が制限に当たっても、 もう片方が続きを持てるようになったこと。そして片方が調べ物、もう片方が文章、という同時並行ができるようになったこと。 制限対策として始めたのに、いちばん大きかったのは最後の並列性でした。

正直に書いておくと、万能ではありません。

向いていない	理由
細かい往復	投げて、待って、ファイルで受け取るので1往復に数分かかる。3行の修正には重い
品質の担保	成果物を読んでレビューする手間は消えない。むしろ増える
同じファイルの同時編集	どちらが正本を持つか決めておかないと簡単に壊れる

粒度としては「30分〜数時間で完結し、成果物がファイルで渡せるもの」がちょうどよかったです。 調査、下書き、独立した実装、レビュー。このあたり。

この記事の要点

• 送信は --enter を忘れない。送信成功と実行開始は別
• 相手の画面は読めない前提で、結果はファイルで受け取る
• 長い指示はファイルに書いてパスだけ送る。受け手はコンテキストゼロと想定して書く
• 禁止事項を明示する。自律的な相手ほど効く
• 粒度は30分〜数時間。細かい往復には向かない

※2つの正規契約を並行して使っている運用の記録です。利用制限そのものを回避する方法ではありません。 数字はすべてこの環境での実測です。