Claude CodeとCodexの既存チャットをつないだ。担当を名前で呼び、結果を元の会話で受け取る

Claude Codeで文章を書いているとき、数字の出典だけは、いつものCodexの担当に見てもらいたいことがあります。
いまの僕の環境なら、Claude Codeの会話を離れず、こう頼めます。

Codexの確認担当に、表の数字を原典と照らしてもらって。結果はここへ。

これは使い方を示すための架空の依頼です。
宛先は、その場で新しく立ち上げたAIではなく、以前から使っている担当の会話。
返事を受け取るのも、最初に頼んだClaude Codeの会話です。

僕が減らしたかったのは、調査やレビューそのものではありません。
相手の会話を探し、依頼を書き直し、戻ってきた回答をまた元の会話に貼る。その行き来です。
同じMacで使うClaude CodeとCodexの間に、その受け渡しを任せる仕組みを作りました。

毎回いちから説明しなくて済む会話があった

Claude CodeとCodexの両方を使っていると、ひとつの仕事でも、話を進めたい会話と、確認を頼みたい会話が違うことがあります。
たとえば文章を組み立てている会話と、元の資料や過去の判断を扱ってきた会話です。
その担当に頼む理由は、モデルが違うことだけではありません。すでに一緒に仕事を進めてきた前提があるからです。

以前は、確認を頼みたい箇所が出てくるたび、僕が間に入りました。
相手の会話を開き、どの資料の何を見てほしいかを書いて、返ってきた答えを元の会話へ貼る。
行き来が増えると、返事をもらったのに元の作業へ反映していない、という途中の状態も増えます。

CodexとClaudeを一度だけ相互レビューさせたときの記録では、ひとつの変更を別のAIに見てもらい、そのレビューを閉じるところまでを扱いました。
今回は、いま持っている仕事を続けながら、すでに仕事をしている別の担当に、ひとつだけ用事を頼む話です。
毎回新しい会話を用意しなくてよいところに、僕には使う理由がありました。

名前を指定すると、返事の置き場所まで決まる

依頼を出すときに僕が書くのは、担当の会話名、対象、どこまでやってよいか、何を返してほしいかです。
配送のための識別番号を手で作ったり、コマンドを毎回書いたりはしません。
ただし、同じ名前の会話があって宛先を一つに絞れないなら、近そうな相手に送らず、そこで確認します。

元の会話 → 名前を指定した担当 → 成果を保存 → 元の会話で回収

たとえばClaude Codeで書いている原稿に確認事項が一つ出たら、その一つだけをCodexの担当へ渡します。
逆に、Codexで進めている変更をClaude Codeの担当に見てもらい、指摘を元のCodexに戻すこともできます。
連携するたびに、会話履歴を丸ごと相手へ渡すわけではありません。渡すのは依頼に必要な情報で、担当が使う前提は、その担当の会話にもともとあるものです。

「ここへ戻して」と頼んでおくと、結果を使う場所もはっきりします。
数字に根拠が見つからなかったなら、書きかけの文章を前に、その数字を外すのか、出典を探し直すのかを決められる。
答えを読みに行く先が減るだけでなく、確認後の作業をどこで続けるか迷わなくなりました。

レビューと修正で往復し、その後に名前指定を確かめた

初期の仕組みでは、実際のコードレビューと、それに対する修正依頼を往復させました。
レビューの指摘を受けて修正し、元の側で結果を読み、テストや変更内容と照らして受け入れるところまで進めています。
「受け取りました」という返事だけで、つながったことにはしませんでした。

その後の名前指定版では、Claude CodeからCodexへ頼む方向と、CodexからClaude Codeへ頼む方向をそれぞれ確認しました。
さらに、普段の業務に使っている会話の組み合わせでも、CodexからClaude Codeへ読み取りの確認を一件依頼。
宛先の会話が応答し、最初のCodexの会話で回答を照合して回収できました。

初期版の修正と受け入れ、名前指定での両方向、普段の業務チャットでの確認は、それぞれ別の記録です。
どの会話でも、何を頼んでも同じように通ると確かめたわけではありません。
僕がこの一連の確認で知りたかったのは、いつもの担当が依頼を受け、使える形の結果が元の仕事へ戻るかどうかでした。

通知が届くことと、結果を読めることは別だった

送信側に「送った」と出ても、相手が依頼を引き受けたとは限りません。
担当が仕事を終えても、成果が保存されただけなら、依頼元はまだそれを読めていない。
途中のどこかを一つ飛ばすと、どこまで進んだのか分からなくなります。

そこで、通知、受け付け、成果の保存、元の会話での回収を分けました。
成果が戻ったと言えるのは、元の会話で、頼んだ案件と保存された結果が同じものだと照合して読めたときです。
結果を読めたとしても、指摘が正しいか、修正を採用するかは別に判断します。

返事が見えないときも、同じ依頼をもう一つ作る前に、まず元の依頼の状態を見ます。
相手がすでに作業を終えていたなら、必要なのはもう一度働いてもらうことではなく、保存されている成果を読むことだからです。
通知が見えない状態から保存済みの結果を回収する経路は模擬試験で確認しましたが、実際の通知障害から復旧した記録とは分けています。

dotとCodexで実行結果を回収した別の事例でも、保存した報告を、次の判断をする側が読んだかどうかを分けて確かめました。
今回も、別のAIを呼べたことより、結果を読んで元の仕事を続けられたことを区切りにしています。

3時間後にも届いた。ただし、受信の準備はしていた

2026年11月10日、同じMac・同じOSユーザーの環境で、Claude Codeの既存会話にあらかじめ受信の準備をして、前面に出さず3時間待ちました。
そのあとCodexからコードレビューを一件依頼。Claude Code側でレビュー結果が保存され、元のCodexの会話で照合して回収できました。

待機は、ローカルで状態を確認する処理に任せています。
待っているだけの間に定期的にモデルを呼び出す構成ではありませんが、依頼を受けて作業するときや、結果を読んで報告するときにはモデルが動きます。
課金上のトークン消費を測定した試験ではないので、「待機は完全に無料だった」という意味ではありません。

11月14日には、手動でMacをスリープさせたあと、同じ受信処理が残っていることを確認してから、別の依頼を一件往復させました。
動いたのは復帰後です。
スリープ中に配信できたわけでも、アプリを終了したりPCを再起動したりして、受信口が全部止まった状態から無人で戻せたわけでもありません。
自分の環境で試すときも、いま誰が受け取れる状態にあるかは、依頼の内容と同じくらい大事です。

最初は「読むだけ」の依頼を一件

短い依頼であっても、「確認して」だけでは、誰に何を見てもらい、何をもって終わりにするかが分かりません。
冒頭の架空例なら、僕は次のくらいまで書きます。

Codexの「確認担当」に、指定した表の3行だけ、指定した原典と照らしてもらってください。読み取りと照合のみで、原稿の変更・公開・外部への送信はしないでください。数字ごとの一致・不一致と、原典の該当箇所、確認できなかった点を、いまのClaude Codeの会話へ返してください。

担当と対象が決まれば、受け取った側も、どこまで確認できたかを短く返せます。
原典を開けなかったら、その数字は未確認のまま。
「確認済み」にそろえるために、別の資料を推測であてたり、元の原稿まで変えたりする必要はありません。

2026年11月14日に参照した公開資料では、OpenAIのClaude Code向けCodexプラグインは、Claude CodeからCodexにコードレビューや作業を頼む用途を案内しています。
また、AnthropicのClaude Code Channelsは、稼働中のClaude Codeセッションに外部イベントを届ける仕組みです。
この記事の往復は、これらの資料だけで同じ動作が確認できるという話ではなく、僕のMacで既存の会話をつないで試した記録です。

依頼文を書く前に、そもそも何に答えが出れば仕事が進むのかを整理したいときは、安宅和人さんの『イシューからはじめよ［改訂版］』が参考になります。問いの見極め方と、答えを伝わる形にまとめる考え方を扱う本です。

僕にとっての変化は、二つのAIを使うこと自体ではありません。
いま開いている会話で担当を呼び、いま進めている仕事の続きとして結果を読めるようになったことです。
もし同じように会話を行き来しているなら、まずは答え合わせができる読み取り作業を一件。頼む相手と同じくらい、結果を戻す場所を先に決めておくと、次の作業に入りやすくなります。