Claude Code vs Codex：2つのエンジンを同じリモートシステムに接続してぶつかった7つのプロトコル差異

利益開示：私たちは PandaNpc を開発しています——Claude Code、Codex などのコーディングエージェントをリモートからアクセス可能にし、複数人で共有できるシステムです。同じページ、同じメッセージチェーンの中でこれらのエンジンを同時にサポートする必要があったため、各エンジンのプロトコル動作を一つずつ整合させざるを得ませんでした。この記事は、その過程で実際にぶつかった差異について書いたものであり、ベンチマーク比較ではありません——私たちは対照ベンチマークテストを行っておらず、したがって速度や成功率などのテスト数値は一切登場しません。文末で今後の計画を説明します。

注記：本文中の Codex は OpenAI Codex のコマンドラインツールを指しており、他の同名製品を指すものではありません。

ひとことで結論：ターミナルで単独使用する限り、両者の体験の差は予想よりもはるかに小さい。しかし、自社のシステム（リモート制御、マルチデバイス同期、セッション復元、ツール承認）に組み込もうとすると、差異はほぼ全てプロトコル層に集中する——そしてこれらの差異は、当時ドキュメントから事前に知ることはできず、すべて実際にぶつかってから発見したものだ。

もしあなたが Codex vs Claude Code を検索して「どちらを選ぶべきか」を知りたいのであれば、この記事はあなたが求めるような比較評価ではないかもしれません——コードを書く能力がどちらが優れているかを比較するのではなく、もう一つのより具体的な問いに答えるものです：それらをプログラム可能なバックエンドとして接続しようとするとき、何に直面することになるのか。

こんな人におすすめ

2つのエンジンを同時にサポートしたい、あるいは一方からもう一方へ移行したい開発者
リモート制御 / マルチデバイス同期 / セッション共有などの周辺ツールを作りたい人
「この2つのCLIのセッションモデルは何が違うのか」を知りたい人

自分のコンピュータでコードを書きたいだけで、統合をするつもりがないなら、この記事の価値は限定的です。両社の公式ドキュメントを直接見る方が早いでしょう。

まず共通点：なぜ「同じように見える」のか

差異を説明する前に、明確にしておく必要があります：この2つのツールのメンタルモデルは非常に似ています——どちらもターミナルで動作し、セッションを単位とし、ツールを呼び出してファイルを変更したりコマンドを実行したりでき、危険な操作にはユーザーの確認が必要で、1回のセッションで複数ラウンドのタスクを継続して処理できます。だからこそ、統合時に「適合レイヤーを1つ書けば十分だ」という判断になりがちで、私たちもそう始めました。

差異は能力層ではなく、プロトコル層にあります。つまり、ターミナルで見える挙動はほぼ同じでも、送信されるフレーム、フレームの順序、フィールドの構成方法はそれぞれ異なります。これこそが、こうした差異が事前に発見されにくい理由です：自分のコンピュータで使っている限り、決してぶつかることはありません。

7つの差異早見表

#	次元	Claude Code の挙動	Codex の挙動	対応しないと誰が影響を受けるか
1	アシスタントメッセージ識別子	安定した id を持つ	持たない場合がある	メッセージ永続化 / マルチデバイス同期を行う人
2	セッション生存チェック	バッチ形式で一度に1グループ	単一のセッション id を期待	オンライン状況表示を行う人
3	履歴リプレイ順序	実際の時系列と一致	サブスレッドのアクティビティフレームが末尾に一括配置	サブエージェント / マルチスレッドビューを扱う人
4	ツール呼び出しコマンド構造	完全	断片化する場合がある	ツール承認 UI を作る人
5	チャネルイベント購読	セッション切り替えの実行主体を担う	切り替えを同時に実行できない	マルチチャネルリレーを行う人
6	オンライン接続クォータ	Codex と同じカウントプールを共有	左に同じ	クォータ制限を行う人
7	長大な履歴のパフォーマンス	線形	処理を誤ると非線形に悪化	モバイル開発を行う人

以下、各項目を「症状 → 切り分け方 → 修正方法」の順で説明します。

一、アシスタントメッセージに安定した id があるか —— 重複排除戦略を左右する

症状：Codex セッションを開いて、会話が終わった直後は正常です。しかし、一度終了してもう一度入り直すと、同じアシスタントの返信が2件、3件になり、入り直すたびに増えていきます。ユーザーが送信したメッセージは影響を受けず、アシスタントの返信だけが増殖します。Claude Code のセッションでは発生しません。

切り分け方：この症状はクライアントのレンダリング問題や履歴読み込みの重複と誤診されやすく、そのままフロントエンドの調査に没頭してしまいがちです。正しい最初のステップは、サーバー側のキャッシュに実際に何件保存されているかを直接確認することです——キャッシュに本当に N 件あれば、問題はデータ層にあり、レンダリングとは無関係です。私たちはこのステップで、調査の方向をクライアントから引き戻しました。

根本原因：Claude Code のアシスタントメッセージは安定した識別子を持っており、リプレイ時もリアルタイムプッシュ時も id で直接重複排除できます。一方 Codex のアシスタントメッセージはそのような識別子の保持が保証されておらず、同じ「id による重複排除」ロジックを使い続けると、同じ返信が2つの異なるメッセージとして書き込まれてしまいます。

修正方法：安定した id を持たないメッセージには、「ラウンドアンカー + 内容」によるフォールディングに切り替えます——アンカーには、この返信の直前にある直近のユーザーメッセージのハッシュを使用します。

⚠️ ここに1つ、単独で取り上げる価値のある落とし穴があります：私たちの最初のバージョンはプレーンテキストによるフォールディングでした。リリース後に履歴データをスキャンしたところ、ラウンドをまたぐ同じ返信を 691件 誤って削除していることが判明しました。原因は、Codex の短い返信の重複率が極めて高いこと（「はい。」「完了しました。」など）と、重複排除の集合がセッション単位であることです——一度ある文のハッシュを記録すると、そのセッション以降のどのラウンドで同じ文が現れても飲み込まれてしまいます。これは重複よりも深刻な、コンテンツ消失です。 アンカーの層は省略できません。

二、生存チェック：一方は単一、もう一方はバッチ

症状：セッションが実際に実行されているのに、画面上ではオフラインと表示されます。

切り分け方：この差異は汎用化できそうに見えます——両側のフィールド名が似ているため、1セットのコードで両方に対応できると思い込みやすいのです。判断方法は簡単です：バッチ構造を送ってみて、返ってくるのが期待した形かどうかを確認します。

根本原因：「特定のセッションがまだ生きているか」を判断するためのインターフェースの形が両側で異なります。Claude Code 側ではバッチ形式を使用し、一度にグループ単位のセッション id を送ります。Codex 側は単一のセッション id を期待します。

修正方法：2つの呼び出しパスに分け、共用しようとしないことです。この差異自体の処理は難しくありませんが、厄介なのはエラーを出さないことです——間違った構造を送っても例外は発生せず、意味的に正しくない答えが返ってくるだけです。

三、履歴リプレイのフレーム順序が異なる —— サブエージェントの状態が固まる

これは調査経路が最も入り組んだ項目です。

症状：サイドバーのサブエージェント状態ドットがオレンジ色の「実行中」のままで呼吸し続けているのに、実際にはとっくに終了しているか中断されています。ページをリフレッシュしても戻りません——リフレッシュするたびに同じことが繰り返されます。Codex セッションでのみ発生します。

切り分け方：「リフレッシュしても戻らない」ことが重要な判断基準です。これは問題がリアルタイムプッシュではなく、履歴リプレイ自体にあることを示しています——リプレイのたびに状態が誤って書き直されるのです。

根本原因：リプレイ時、まず親スレッドの全エントリを展開し（「サブエージェントが終了した」ことを示す通知フレームも含む）、その後に各サブスレッドのアクティビティフレを一括で末尾に追加します。そのためクライアントが受け取る順序は、「中断された」という通知を先に見て、その後に時間的に過去のアクティビティフレームを見る、というものになります。そして状態を書き込むロジックはタイムスタンプを比較しないため、最後に到着した過去のフレーム群が終端状態を無条件に「実行中」へと書き戻してしまいます。

修正方法：状態を書き込む分岐に終端状態ガードを追加します——すでに終端状態（完了/失敗/停止）にあるものは、より新しいフレームだけが上書きできるようにします。判断基準は他と共通の状態マッピングを使い、別途新しく書かないように注意してください。さもないと、2箇所の間で「何が終端状態か」という理解が乖離していきます。

この種の問題の共通の特徴は、個々のフレームを単体で見ればすべて正しく、間違っているのは相対的な順序だということです。 そのため、単一フレームのログだけを見ても問題は決して見つかりません。

四、ツール呼び出しコマンドの構造：断片化する

症状：Codex セッションのツールカードで、コマンドが 1,220p や /pid=…/ {print} のような断片として表示されます。スクリプト全体が切り離されていることもあり、さらには回答が終わった後も未完了のツールカードが多数残っていることがあります。

切り分け方：レンダリング結果ではなく、生のフレームにおけるコマンドフィールドの実際の構造を確認します。Claude Code のフィールドパスに従って「ユーザーが実行したコマンド」を取得すると、そこで取得できるのは切り刻まれた断片です。

修正方法：Codex 用に別途コマンド再構築レイヤーを書き、断片を完全なコマンドに組み立て直してから UI に渡します。

この差異は、ツール承認を担当する人にとって特に致命的です：ユーザーはスマートフォンで「許可 / 拒否」をタップするのに、カードに表示されるコマンドは断片化されています——それは中身を見ずに署名させるのと同じです。セキュリティ機能が意味を失うことは、表示が見苦しいことよりもはるかに深刻です。

五、チャネルイベントの購読範囲が異なる

症状：2人のユーザーが互いに相手を強制ログアウトさせます。

根本原因：2つのリレー経路が両方とも「セッション切り替え」系イベントを購読して実行すると、両側がそれぞれ1人ずつ被害者をキックし、二重キックが発生します。切り替え動作には唯一の実行主体が必要です。

修正方法：私たちの方法は、Codex 側の経路にはキックとキャッシュ無効化イベントのみを購読させ、切り替えイベントは絶対に購読させないことです。切り替えの実行権はもう一方の経路に固定します。

このような「意図的に何かをしない」という決定は、通常コード内に1行のコメントとしてしか残りませんが、それは一度踏んだ後に追加されたものです——そして、この制約を後から来た人が「ついでに補完」してしまうと、事故が再発します。そのためコメントには、なぜやらないのかを明確に書くべきであり、「やらない」とだけ書いてはいけません。

六、クォータと接続カウントは統合されている

症状：ユーザーはまだクォータが残っていると思っているのに、実際には超過しています。

根本原因：私たちのようにオンライン接続数に上限を設定している場合、2つのエンジンの接続が同じカウントプールに入ることに注意が必要です。ユーザーが Claude Code と Codex のセッションを同時に開いている場合、同じクォータを消費します。

これは欠陥ではなく、設計上の選択です——ユーザーの視点では「同時に合計いくつのセッションを開けるか」の方が「エンジンごとにそれぞれいくつ開けるか」よりも理解しやすいからです。しかし、実装がエンジンごとに個別カウントしているなら、フロントエンドに表示される残量とバックエンドの実際の減算が一致しなくなります。

修正方法：まずどちらの基準を採用するのかを明確にし、フロントエンドとバックエンドが同じ基準を使うようにします。2つの基準を混用することは、基準を誤って選ぶことよりも悪いです。

七、履歴規模が増加したときのパフォーマンス特性が異なる

症状：モバイル端末で長い履歴のセッションを開くとフリーズします。

根本原因：私たちは iOS 側で一度、明らかなフリーズに遭遇しました。根本原因は、履歴処理の中にメッセージ数の2乗で増加する処理が存在したことです。明確にしておくと、これはエンジン自体の問題ではなく、その履歴構造が私たちの従来の処理方法とマッチしなかったことによるものです——同じ処理方法でも、もう一方のエンジンでは問題が顕在化しませんでした。

修正方法：メッセージ数に応じて増加する繰り返しスキャンを、一度きりのインデックスに置き換えます。さらに重要なのは事前設計です：長い履歴は最初から考慮に入れておく必要があり、ユーザーが数千件のメッセージを蓄積してから発見するようでは遅すぎます。

では、どちらを選ぶべきか

先に断っておきます：以下は統合の視点に基づく提案であり、コーディング能力の評価ではありません。私たちは対照ベンチマークテストを行っていないため、「〇〇はどれだけ速い」といった主張はこの記事からは一切出てきません。

Codex を選ぶ方が適しているケース

チームがすでに OpenAI エコシステム内にいる——アカウント、クォータ、課金がすべて一箇所にまとまり、台帳と認証情報の管理が1セット減ります。この省力化の価値は過小評価すべきではありません。
プロセスがすでにそのセッションとタスクモデルを中心に構築されている——移行のために周辺ツールをリファクタリングするのは通常、割に合いません。上の7つの差異を逆から見たものが、そのまま移行コストになります。

Claude Code を選ぶ方が適しているケース

周辺ツールを自前で構築したい——私たちの統合経験から見ると、メッセージが安定した識別子を持つことで永続化とマルチデバイス同期がはるかに簡単になります。第1、3、4の差異はすべてこの側の方が処理しやすいです。
ツール承認のようなインタラクションを実装したい——コマンド構造が完全なので、承認 UI を実装する際に追加の再構築が不要で、「中身を見ない署名」のリスクもありません。

どちらも選ばないケース

もしあなたのニーズが「同じインタラクションを動かすモデルを変えたい」だけなら、エンジンを変えるよりモデルのバックエンドを変える方が良いでしょう。私たちが PandaCode を作った理由の一部もこれです：インタラクション層は変えずに、モデルを入れ替える。

移行するなら：7つの差異に対応する改修量

多くの人がこの2つの名前を検索するのは、実際には「すでに一方を使っているが、もう一方に切り替えるとどれだけのコストがかかるか」を評価しているからです。以下、上記の7つの差異を移行コストに換算します。

補足：この節は、前述の7つの差異から導出した改修量であり、私たちが完全な移行を行った記録ではありません——私たちの経路は「一方からもう一方へ切り替える」ではなく「同時接続」でした。そのため、工数見積もりではなくチェックリストとしてお使いください。

Claude Code から Codex への移行では、改修は以下の箇所に集中します：

重複排除ロジックの書き直し（第1条）——これが最も過小評価されやすい箇所です。従来の id による重複排除コードはそのまま使えず、間違っていてもエラーにはならず、静かにメッセージが増えるか静かにメッセージが失われるだけです。メッセージ永続化を行っているなら、移行前にアンカーに何を使うかを必ず先に決めておいてください。
オンライン状態チェックの呼び出し形式の変更（第2条）——作業量は小さいですが、変更を忘れると「実行中なのにオフライン表示」になり、しかも例外は発生しません。
履歴の時系列に依存するすべての機能の再検証（第3条）——サブエージェントビュー、プログレスバー、「履歴から現在の状態を推定する」あらゆるロジックが該当します。
ツール承認 UI へのコマンド再構築レイヤーの追加（第4条）——あなたのプロダクトに承認機能があれば、この箇所は省略できません。省略するとユーザーに中身を見ない署名を強いることになります。

逆方向（Codex から Claude Code への移行）は通常、より手間がかかりません：重複排除は id による方式に簡略化でき、コマンド構造の再構築レイヤーも不要です。ただし、Codex 用に書いた互換レイヤーを直接削除しないように注意してください——同時サポートの能力を残しておきたいなら、そのレイヤーは負債ではなく資産です。

両方向で再確認が必要なもの：クォータの基準（第6条）と長大な履歴のパフォーマンス（第7条）です。この2つはエンジンとの関係がそれほど直接的ではありませんが、エンジン変更後に再テストを忘れられやすい部分です。

1つの提案：システムがすに稼働していて既存のセッションデータがあるなら、移行前に既存データに対して新しいロジックを一度実行して対照確認をしてください。直接切り替えるのは避けましょう。私たちが重複排除で691件を誤って削除した教訓はまさにこれです——ロジック自体は問題なさそうに見えても、履歴データをスキャンして初めてコンテンツを飲み込むことが判明しました。新しいロジックが正しいこと ≠ 既存データにとって安全であることです。

私たちの方法：選ばない、両方接続する

同時サポートが必要だったため、私たちの最終的な結論は差異を中間層に吸収させることでした——上に対しては統一されたメッセージとセッションモデルを公開し、下に対してはエンジンごとに適合させます。コストは、エンジンを追加するたびに上記の7種類の挙動を再度整合させなければならないことです。メリットは、ユーザーが同じインターフェース内でエンジンを自由に切り替えられ、セッション、履歴、承認の体験が一貫することです。

新エンジン統合時の検証チェックリスト

あなたもこの道を進むなら、この順序で検証することをお勧めします。最初の4項目は使えるかどうかを決定し、後の3項目は本番環境でトラブルが起きるかどうかを決定します：

メッセージ識別子 —— アシスタントメッセージに安定した id はあるか？ない場合、重複排除のアンカーは何にするか？
セッション生存 —— 生存チェック API は単一を受けるのかバッチを受けるのか？間違った構造を送るとエラーになるのか、それとも静かに誤った答えが返るのか？
履歴リプレイ順序 —— リプレイされたフレーム順は実際の時系列と一致するか？特にサブスレッドがある場合は？
ツール呼び出し構造 —— コマンドフィールドを取得すると完全な形で取れるか？切り刻まれたりしないか？
イベント購読範囲 —— どのイベントに唯一の実行主体が必要か？繰り返し実行されるとどうなるか？
クォータの基準 —— カウントはエンジン別か統合か？フロントエンドとバックエンドで一致しているか？
長大な履歴のパフォーマンス —— メッセージ数が10倍になったとき、処理時間は線形に増えるか、それともより速く増えるか？

各項目について、まず少量のデータで一度検証し、その後で大規模な履歴でもう一度検証することをお勧めします——第3項目と第7項目は、データ量が増えて初めて顕在化します。

症状から逆引き：ぶつかったのはどの項目か

すでに落とし穴にハマっているなら、ドキュメントを一通り読むよりも、症状から逆算する方が通常は速いです：

見られる症状	可能性が高い項目	1ステップで切り分ける方法
終了して再入場するとアシスタントの返信が増える	第1項目（メッセージ識別子）	サーバーキャッシュに何件保存されているかを直接確認——データ層かレンダリング層かは一目瞭然
セッションが実行中なのにオフライン表示	第2項目（生存チェック）	生存リクエストが単一構造かバッチ構造かを確認
サブエージェント状態が「実行中」で固まり、リフレッシュしても戻らない	第3項目（リプレイ順序）	「リフレッシュしても戻らない」ことが判断基準：問題はリアルタイムプッシュではなくリプレイにある
ツールカードのコマンドが断片化 / 回答終了後もツールカードが残る	第4項目（コマンド構造）	生のフレームのコマンドフィールド構造を確認。レンダリング結果は見ない
2人のユーザーが互いにキックし合う	第5項目（購読範囲）	2つの実行主体が同時に切り替えイベントを処理していないかを確認
フロントエンドは残クォータ表示、バックエンドはすでに超過	第6項目（クォータ基準）	フロントエンドとバックエンドがエンジン別カウントか統合カウントかを確認
モバイルで長いセッションを開くとフリーズ	第7項目（長大な履歴）	メッセージ数が2倍のセッションで処理時間を比較し、非線形かどうかを確認

1つの汎用判断基準：症状がリフレッシュのたびに安定して再現するなら、問題はおそらく履歴リプレイかデータ層にあります。リアルタイムの対話中にのみ偶発的に発生するなら、そのときにプッシュ経路を調べます。この判断基準で私たちはかなりの時間を節約できました——第1項目と第3項目は当初、どちらもクライアント側の問題と誤診されていました。

FAQ

Codex CLI と OpenAI Codex は同じものですか？

本文で議論する Codex は、OpenAI のコマンドラインコーディングツールを指します。市場には Codex という名前の他の製品も存在し（法律・コンプライアンス分野のソフトウェアも含む）、検索時に混同されやすいため、"CLI" や "OpenAI" を付けて限定すると精度が大幅に上がります。

これらの差異はバージョンによって変わりますか？

変わります。上記の各項目は、私たちが特定の時点で実際に遭遇した挙動であり、両エンジンとも急速に進化しています。したがって、より重要なのはあの検証チェックリストです——具体的な差異は変わりますが、検証すべき次元はあまり変わりません。

2つのエンジンを同時に接続できますか？

できます。私たちも実際にそうしています。鍵となるのは、差異を中間層に吸収させることであり、UI 層に浸透させないことです——そうしないと、エンジンを追加するたびにインターフェースのロジックが分岐してしまいます。

今後の予定

私たちは対照タスクテスト（同じタスク群、固定バージョン、公開された方法論と生の出力）を追加する予定で、その際に結果をこの記事に更新します。それまでは、この記事にパフォーマンスや成功率の数値は一切含まれません——テストしていないものを、テストしたとは書きません。

本記事は、Claude Code と OpenAI Codex を同じリモートアクセスシステムに統合した実際のエンジニアリング経験に基づいており、最終更新日は 2026-08-26 です。両エンジンは継続的に更新されているため、具体的な挙動はそれぞれの公式ドキュメントを参照してください。