2026年2月5日、AnthropicとOpenAIがほぼ同時に新モデルをリリースしました。
Claude Opus 4.6とCodex 5.3です。
あるRedditユーザーが、この2つのモデルを同一のSwiftコードベースで直接対決させました。
本記事では、その検証結果とコミュニティの反応をもとに、両モデルの使い分けについて考察します。
なお、この記事はRedditの投稿および有用なコメントを参考にしたものです。
筆者自身の実験ではありません。
検証の舞台：リアルタイム画像処理のmacOSアプリ
検証に使われたのは、約4,200行のSwiftで書かれたmacOSアプリです。
カメラを使ったリアルタイムのコンピュータビジョン処理を行います。
そして、注目すべきは並行処理のアーキテクチャでしょう。
このアプリでは、3つの並行処理戦略が1つのリアルタイムパイプラインの中で混在しています。
具体的には、GCD（AVFoundation向け）、Swift Actor（処理サービス向け）、@MainActor（SwiftUI向け）です。
Swiftの並行処理はLLMにとって難易度が高い領域として知られています。
だからこそ、検証の題材として面白いわけです。
テストは2部構成で実施されました。
Part 1は初見でのアーキテクチャ読解です。
データフローの追跡、並行処理モデルの特定、最もリスクの高い境界の分析、状態マシンのエッジケースの洗い出しが求められました。
Part 2はコードレビューです。
対象は3つのファイルで、500行のカメラマネージャー、228行の検出サービス、213行のセッションマネージャーとなっています。
これらからバグ、レースコンディション、リスクを発見する作業が課されました。
両モデルとも、プロジェクトのドキュメント（CLAUDE.mdやルールファイル）にアクセスできる状態です。
つまり、「新しいコードベースに初日から参加する」状況がシミュレートされています。
数字で見る結果
実行時間は、Claude Opus 4.6が約10分、Codex 5.3が約4分14秒でした。
速度ではCodexが圧倒しています。
Part 2のコードレビューでは、Claudeが19件（HIGH 3、MEDIUM 9、LOW 7）を発見。
一方、Codexは12件（HIGH 2、MEDIUM 5、LOW 5）でした。
数の上ではClaudeが優勢です。
そして重要なポイントがあります。
どちらのモデルもハルシネーションがゼロだったことです。
アーキテクチャ理解：両者とも優秀
Part 1のアーキテクチャ分析では、両モデルとも正確な結果を出しました。
ハードウェアカメラからGCD → AsyncStream → detached Task → Actor → MainActor → Actor → OSアクションに至る10段階のデータパイプラインを、どちらも正しくトレースしています。
3つの並行処理戦略の特定も完璧でした。
最もリスクの高い境界についても一致しています。
GCDからasync/awaitへ渡される@unchecked SendableでラップされたCVPixelBufferを、両者とも正しく指摘しました。
差が出たのは深さです。
Claudeはスレッドモデルのサマリーテーブルを含め、Vision処理パス内のautoreleasepoolにまで言及しました。
さらに、複数の並行処理コンテキストから同期なしにアクセスされるプロパティを、二次的なリスクとして取り上げています。
Codexは正確だったものの、より簡潔な出力に留まりました。
状態マシン分析：最も差がついた領域
4状態のセッションライフサイクルを通じた3つのシナリオのトレースが求められました。
ここで最大の差が現れています。
両モデルとも3つのシナリオすべてを正解しました。
Codexには鋭い洞察があります。
「SessionManagerとDetectionServiceはどちらも@MainActorなので、await acquireからの戻りとguardの評価の間に独立したインターリーブスロットは存在しない」という指摘です。
MainActorの再入可能性に関する正確な推論でした。
しかし、Claudeはさらに先を行きました。
あるシナリオをサブケースに分解した上で、投稿者が質問していない4番目のエッジケースを自ら発見したのです。
その内容はこうです。stopSessionがstartSessionのawait中に呼ばれると、両方のパスがrelease(for: .session)を呼び出します。
結果として、二重解放が発生するという問題でした。
現状ではSet.removeが冪等であるため安全に動作します。
しかし、Claudeはこれをコードスメルとしてフラグを立てました。リファクタリング時に壊れる可能性を明確に説明しています。
注目すべきは、この発見がPart 2のコードレビューでも独立して再度登場している点です。
ファイル単位のパターンマッチングではなく、コードベース全体を横断したアーキテクチャレベルの推論と言えるでしょう。
コードレビュー：それぞれの強み
単純な件数よりも興味深いのは、片方だけが見つけた問題です。
Codexのベストな独自発見は、検出サービスのhandleFailureに関するものでした。
この関数は.failedに遷移してコールバックを発火します。
しかし、カメラリソースの解放を保証していません。
ストリームが予期せず終了し、カメラがfailed状態にない場合、リソースが保持されたままになります。
Claudeはこれを見逃しました。
正当なHIGHレベルの発見です。
一方、Claudeのベストな独自発見は複数ありました。
先述の二重解放に加え、framesContinuation（AsyncStreamのcontinuation）に関する問題を指摘しています。
この値はMainActorから書き込まれ、GCDキューとdeinitから同期なしに読み取られていました。
ほかにも、deinitのスレッドセーフティ問題、開始失敗時のorphaned continuation、failureコールバックのアクセス制御の欠如などが発見されています。
興味深いのは、重要度の評価が割れた点です。
二重解放の問題について、ClaudeはHIGHと評価しました。
しかし、CodexはLOWと評価しています。
投稿者はClaudeの判断を支持しました。
「文書化されていない不変条件に安全性が依存している」状態は、リファクタリング時にまさに噛みつくタイプの問題だからです。
Claudeの自己修正：注目すべき振る舞い
検証結果の中で特に興味を引いたのが、Claudeの自己修正です。
ある発見を最初はHIGHと評価したClaudeが、出力の中でインターリーブの可能性を自ら推論し直しました。
そして、MEDIUMに格下げしています。
「コードは正しいが、インターリーブが非自明であり、コメントに値する」と記述していました。
AIモデルは自信を持って間違えることに長けています。
同時に、外部から少し圧力をかけるだけで簡単に立場を変えてしまう傾向もあります。
そんな中で、モデルが自発的にこの修正を行ったという事実は注目に値するでしょう。
Codexにこの両者の出力をレビューさせた「ボーナスラウンド」も行われました。
Codexはこの自己修正を「内部一貫性の問題」と評価しています。
しかし、投稿者はこれに異を唱えました。
「思考過程を見せることは、バグではなく機能だ」という見解です。
コメント欄でもこの点に共感する声がありました。
「モデルが自信を持って間違えることがあまりに多い中で、自発的に格下げする姿勢は、n=1であっても意味のあるシグナルだ」と。
説得力のある意見です。
コミュニティが最も盛り上がった話題：価格差
Redditのコメント欄で最も白熱したのは、技術的な議論ではありません。
価格の話でした。
Claude Maxプランは月額100ドル。
Codex Proプランは月額20ドル。
5倍の価格差があるにもかかわらず、性能差は僅差です。
「Anthropicは目を覚ますべきだ」「プロユーザーを失うリスクがある」という声は少なくありませんでした。
投稿者自身はこれに対して異なる見方を示しています。
OpenAIのユニット・エコノミクスが成立していないことは周知の事実です。
収益化の道筋が不透明なまま資金を燃やし続けるモデルに、Anthopicが追随すべきではないという立場でした。
月額200ドルの専門ツールは、プロフェッショナルの世界では決して高額ではないとも述べています。
「マットレスと同じで、毎日長時間使うものにはできる限り投資すべきだ。小さな不満は不釣り合いに蓄積する」
投稿者のこの例えは、なかなか的を射ています。
一方で、別のユーザーは冷静な反論を寄せていました。
「現在の価格はどちらの企業にとっても持続可能とは思えない。本当のコストは月額500〜1,000ドルに近いのでは」と。
VCマネーが燃え尽きた時に価格が大幅に上がっても驚くべきではないという主張です。
Uberモデルの再来という指摘は鋭いものがあります。
実践的なTips：2つのモデルを連携させる
コメント欄で実用的な価値が高かったのは、両モデルの連携方法に関するやり取りです。
投稿者は、Claude CodeのCLIにCodexをMCPサーバーとして接続する方法を共有しました。
~/.claude.jsonにCodexの設定を追加するだけで完了します。
Claude CodeからCodexに処理を渡せるようになり、両者を行き来させて合意に達するまで議論させることもできるとのことでした。
この使い方は、複数のコメントで支持されています。
「Claudeでコードを書き、Codexにレビューさせる」というワークフローは理にかなっているでしょう。
自分のコードを自分でレビューするのには限界があります。
異なるLLMは異なるバイアスを持つため、PRに2人の異なるバックグラウンドを持つレビュアーがつくのと同じ効果が期待できるわけです。
投稿者の結論：深さのClaude、速さのCodex
投稿者の総括はシンプルです。
PRの前にさっとチェックしたいならCodex。
時間の40%で80%の価値が得られます。
ただし、2つのモデルの実行時間差は約6分。
つまり、トイレ休憩1回分にすぎません。
本当の見出しは別のところにあります。
両モデルとも、Swiftのアクター隔離、MainActorの再入可能性、GCDからasyncへの橋渡し、@unchecked Sendableの安全性契約について、リリース当日に実コードベースで正しく推論したという事実です。
1年前ならこれは驚きだったでしょう。
しかし今では、それが当たり前のレベルになりつつあります。
投稿者が最も強調していたのは、「両方を使うことで最大の恩恵が得られる」という点でした。
モデル単体の能力は週単位で変動し、どちらかが決定的に引き離すことはありません。
しかし、異なる視点を提供してくれるという価値は、モデルのパワーそのものよりも大きいのだと。
「3人の優秀な人間は、たいていの仕事で1人の天才に勝つ」
この投稿者の言葉は、現在のAIコーディングツールの使い方を端的に表現しています。
まとめ
この検証から見えてくるのは、「どちらが優れているか」という二項対立がもはや生産的ではないということです。
Claude Opus 4.6はアーキテクチャ全体を俯瞰した深い分析に強みがあります。
そして、自ら問いを立てる能力を見せました。
一方、Codex 5.3は高速かつ正確で、Claudeが見逃した実践的なバグを発見しています。
AIコーディングツールを使う上で重要なのは、1つのモデルに固執することではありません。
複数の視点を持つこと。
そして、各モデルの癖を理解した上で、自分のワークフローに最も合った使い方を見つけることです。
この検証はN=1の事例にすぎません。
モデルのリリース当日のスナップショットでもあります。
しかし、Swift並行処理という難易度の高い領域でのリアルな比較として、AIコーディングツールの選び方を考える良い材料になるのではないでしょうか。
