Transcript
00:00:00長い間、コーディング用モデルの定番といえばClaudeでした。
00:00:03性能が優れていただけでなく、同等の選択肢が他になかったからです。
00:00:07その後、GPTモデルが追い上げ、特にGPT 5.5のリリースによって
00:00:12その差はほとんどなくなりました。
00:00:14両者を比較するには、それぞれの能力を最大限に引き出せる環境、
00:00:18つまり独自のCLIでテストする必要があります。
00:00:19そこで今回はOpus 4.7とGPT 5.5を直接対決させ、そのパフォーマンスを
00:00:25検証します。
00:00:269つのカテゴリーでテストを行い、どちらが本当に優れているのか、
00:00:29最終的にあなたのワークフローにふさわしいのはどちらかを明らかにします。
00:00:33使い勝手の面で、Claude Codeには不満が出始めています。
00:00:36私たちはコーディング以外も含め、ほとんどの作業にこれを使ってきましたが、
00:00:40良かったのはバージョン2.1.0のアップデートまででした。
00:00:43それ以降、Claude Codeの状況は悪化し始めました。
00:00:46最もストレスを感じるのはUIで、体験に大きな影響を与えています。
00:00:50ターミナルの不具合やレンダリングの崩れなど、以前は洗練されていた部分が
00:00:55今では違和感だらけです。
00:00:56かつては最高のTUIの一つでしたが、感覚的な開発（vibe coded）になってから変わってしまいました。
00:00:59レンダリングの問題やキャッシュ漏れなど、多くのバグを抱えており、
00:01:03不満を漏らしているのは私たちだけではありません。
00:01:05より大きな問題は、「危険なスキップ」許可モードが削除され、
00:01:09デフォルトのオートモードに置き換わったことです。
00:01:11以前は、Claudeに触らせたくないファイルにフックを設定した上で、
00:01:15ほとんどの作業を許可バイパスモードで実行していました。
00:01:17しかし今はそのモードでも許可を求めてきます。Claudeにスキル作成を命じた後、
00:01:22別のセッションで作業をして戻ってみると、スキル作成が
00:01:27.claudeフォルダへの書き込み許可待ちでずっと止まっていたことがありました。
00:01:32スキルができていると思って戻ったのに、ただ待機状態だったのです。
00:01:36Codexはこの点をうまく処理しています。YOLOモードでは、
00:01:40Claude Codeのオートモードのように許可を求めることはありません。
00:01:42CLIがRustで構築されているため、ReactベースのClaude CodeよりもUIが非常に滑らかで、
00:01:47長時間のセッションでも壊れることがありません。
00:01:49パーソナリティ設定も、Codexが優れている点です。
00:01:53パーソナリティを、より直接的で簡潔な言葉遣いに設定できます。
00:01:56というのも、GPT 5.5はOpus 4.7に比べて非常に「おべっか使い」で、
00:02:02どんなプロンプトにも同調しすぎる傾向があるからです。
00:02:04そのため、Codexでパーソナリティを変更することで、モデルのデフォルトの挙動を防ぐことができます。
00:02:08Opus 4.7を直接的な表現にするにはClaude.mdの指示に頼る必要がありますが、
00:02:14Codexは設定を変えるだけで済みます。
00:02:16プリインストールされているスキルにも違いがあります。
00:02:18CodexにはClaude Codeにはない多くのスキルがあり、エージェントブラウザスキルも含まれます。
00:02:22これはアプリ開発者にとって重要です。Codexでは、ブラウザでの検証のために
00:02:26明示的にMCPを接続する必要がないからです。
00:02:29機能を実装した後、自動的に検証を行ってくれます。
00:02:31また、組み込みのスキルクリエイターがあり、新しいスキルが欲しい時は、
00:02:35適切な構造と参照ファイルを備えた完全なものを生成してくれます。
00:02:38Claudeの場合、適切に構造化されたスキルを得るには、
00:02:42スキルクリエイターを別途インストールする必要があります。
00:02:43そうしないと、ただのMDファイルが作成されるだけです。
00:02:45とはいえ、まだClaude Codeの方が優れている点も2つあります。
00:02:47Codexには「巻き戻し（rewinding）」機能がありません。これは私たちが最も多用する機能なので、
00:02:51それがないのは大きなデメリットです。
00:02:52また、Claude CodeはCtrl+Oで思考プロセスを展開して見ることができますが、
00:02:57Codexはこの点があまり得意ではありません。
00:02:58推論を確認できると、実装が終わるのを待ってやり直すのではなく、
00:03:02作業の途中でアプローチを修正できるので非常に助かります。
00:03:05アップデートのたびにClaude CodeのUXが低下していることを考えると、
00:03:10使い勝手の点ではCodexに軍配が上がります。
00:03:11コスト面では、Claude Codeの方が圧倒的に高価なツールです。
00:03:15実際の価格というより、同じ価格に対する「使い勝手」の面でそうです。
00:03:19Claude Codeは無料枠では一切利用できず、
00:03:23ProプランまたはMaxプランからのみ利用可能です。
00:03:24各プランの価格設定はほぼ同じです。
00:03:26Proプランは、ある程度の規模のアプリ開発では、数個のタスクで
00:03:30制限に達してしまうため、実質的に使えません。
00:03:32Proプランでは、意味のあるタスクにOpus 4.7をまともに使うことすらできません。
00:03:36私たちが使っているMaxプランでさえ、制限はすぐに尽きてしまいます。
00:03:39この点、Codexは最初から有利な立場にあります。
00:03:41利用制限はあるものの、無料プランでも利用可能です。
00:03:44両者とも5時間のウィンドウ制を採用しているため、どちらがより多くの仕事をこなせるか、
00:03:49同規模のタスクで検証しました。
00:03:51Claude Codeにはセッションで消費されたトークンを可視化するコマンドがありますが、
00:03:56Codexには同等の機能がないため、比較のために回避策を講じる必要がありました。
00:04:00どちらのツールもセッションをJSONファイルとして保存していますが、構成が異なります。
00:04:04そこで、それらを読み取って各セッションの消費トークンをカウントするツールを自作しました。
00:04:08同じアプリで同程度のデバッグを行った結果、Opus 4.7は173,000トークンを消費したのに対し、
00:04:15GPT 5.5はわずか82,000トークンでした。
00:04:18これは、GPT 5.5がより少ないトークンと少ないリトライ回数で仕事を完了させるためです。
00:04:23結果として、Codexの方が圧倒的に長く使え、同じ作業量に対してコスト効率が遥かに高いことが分かりました。
00:04:28さて、次に進む前に、スポンサーのStreamからのお知らせです。
00:04:32アプリを開発していて、ユーザー同士の会話やストリーミング、繋がりが必要になったとします。
00:04:35自前で実装しようとすれば、3ヶ月後もリリースできずにデバッグに追われているかもしれません。
00:04:39Streamを使えば、そのすべてをスキップできます。
00:04:40アプリ内チャットやビデオ通話から、アクティビティフィード、
00:04:44AIモデレーションまで即座に導入できるため、インフラ構築ではなく機能のリリースに集中できます。
00:04:49WhatsApp風のメッセージ、Zoom風のビデオ通話、Instagram風のフィードがすべて組み込み済みです。
00:04:55特に注目すべきは、Streamの新しいサービス「Vision Agents」です。
00:04:58ライブビデオやオーディオを見て、聞いて、反応するインテリジェントなAIエージェントを、
00:05:02Pythonのわずか数行のコードで構築できます。
00:05:05すべてがグローバル・エッジ・ネットワーク上で動作し、どこでも低遅延を実現します。
00:05:08スタートアップから大規模アプリまで、SNS、フィットネス、コミュニティの主要プラットフォームが
00:05:1310億人以上のエンドユーザーを支えるためにStreamを採用しています。
00:05:16次世代のビッグアプリを開発しているなら、Streamは初日からスケールに合わせて対応します。
00:05:20getstream.ioで無料で始められます。リンクは固定コメントを確認してください。
00:05:24両モデルの真価が問われるのは、製品をどう構築するかという点です。
00:05:27前述の通り、GPT 5.5は高速で消費トークンが少ないため、動くアプリをより早く完成させます。
00:05:33対してOpus 4.7は思考に多くのトークンを費やし、より深く計画を立て、
00:05:38アプリのあらゆる側面を同時に反復改善していきます。
00:05:40まずテストしたかったのはプランニング（計画策定）です。
00:05:42私たちは以前からClaude Codeのプランニングモードを活用してきました。
00:05:45欠点はありますが、ほとんどのケースをカバーしており、十分に実用的です。
00:05:48そこでGPT 5.5のプランニング能力を見てみることにしました。OpenAIは、
00:05:53計画立案とその実行において、より優れた性能を発揮すると主張しているからです。
00:05:55プランモードを有効にし、FastAPIで構築された既存のバックエンドAPIが
00:06:00含まれるフォルダを開き、そのフロントエンドを構築するよう指示しました。
00:06:04プロジェクトを徹底的に調査し、いくつか質問をしてきましたが、
00:06:08その内容はかなり単純なものでした。
00:06:09フロントエンド開発において重要な「見た目」に関する要望について、
00:06:13もっと深く踏み込むこともできたはずです。
00:06:14提示されたプランは非常にシンプルなものでした。
00:06:16メインフローの概要、主な変更点、追加するページ、そしてテスト方法が
00:06:20含まれていました。
00:06:21評価できる点は、自身の前提条件を明確に切り分けていたことで、
00:06:25何を所与のものとして進めているのかが正確に把握できました。
00:06:26続行を指示したところ、約8分で完了しました。
00:06:28同じタスクをClaude Codeで行った場合は24分かかりました。
00:06:31しかし、Opus 4.7のプランはより詳細で、アプリケーションのより多くの側面を考慮しており、
00:06:36UX向上のためにShadcn UIを導入することまで提案しました。
00:06:39プランニングの質に関しては、Opus 4.7の方が優れています。
00:06:42次に、新規アプリの開発（Greenfield app）で両者をテストしました。
00:06:45Python FlaskのバックエンドとNext.jsのフロントエンドを持つモノリポを作成し、
00:06:50パイプラインの全工程と主要な要件を満たすよう、同一のプロンプトを与えました。
00:06:55（Claude Codeは）その設計上、自動的にプランニングモードに切り替わりました。
00:06:56一方、Codexはプランニングモードに切り替わることなく、
00:06:59直接実装を開始しました。
00:07:04その結果、プランニング工程を含めて約16分かかったClaude Codeよりも
00:07:08遥かに早く完了しました。
00:07:09GPT 5.5版のアプリはUIが非常にシンプルで、主にアプリが
00:07:14正しく動作することに重点を置いていました。
00:07:15最初はうまく動きませんでしたが、反復的にデバッグを行いました。
00:07:17気づいた点として、APIキーを提供していなかったため、
00:07:22面接用のプロンプトがハードコードされていました。
00:07:23指示書ではバックエンドにGemini APIを使うよう指定していましたが、キーがなかったため、
00:07:27アプリが完全にクラッシュしないようフォールバック（代替処理）を実装していたのです。
00:07:30Codexは、明示的な指示なしにローカルでのフォローアップ質問機能を使用していました。
00:07:35こうしたフォールバック機能は、クラッシュを防ぐため
00:07:39本番環境でも有用であり、好感が持てます。
00:07:40数回の修正とAPIキーの追加により、UIはシンプルなままでしたが、
00:07:44アプリのフローは正しく動作するようになりました。
00:07:46このように、GPT 5.5はエッジケースを考慮し、欠落を補う仕組みを実装していました。
00:07:51対照的に、Opus 4.7は実装を開始する前にAPIキーを要求し、
00:07:57それを前提としてアプリ全体を構築しました。
00:07:59つまり、Opus 4.7はGPT 5.5とは異なり、フォールバックの準備をせず、
00:08:05最初からすべてが揃っていることを必要としたのです。
00:08:06そのため、実際にAPIが利用できない状況ではフォールバックが働かず、エラーを出すだけでした。
00:08:10ただし、Claude CodeはUXと機能性の両方に焦点を当てているため、
00:08:15実装自体はより現実的な仕上がりでした。
00:08:16これはOpus 4.7のUI面での強みであり、前回の動画でも
00:08:21Opus 4.7はUI処理において遥かに優れていると述べましたが、実装には問題もありました。
00:08:26デバッグを依頼した際、Codexのように直接実装を調査することはありませんでした。
00:08:31代わりに、何が原因と考えられるかについて私たちに質問を投げかけ、
00:08:35こちらのテスト結果に依存したのです。
00:08:36UI上のインジケーターやコンソールログなどのデバッグポイントを追加し、
00:08:41状態を確認して報告するよう求めてきました。
00:08:42何度かやり取りした末にようやく問題が解決し、面接機能が動作しました。
00:08:46私たちは、エージェントブラウザを使って自律的にデバッグを行うCodexの手法を好ましく感じました。
00:08:49自律的な動作という点ではCodexの実装が勝っており、
00:08:53UXという点ではClaude Codeが遥かに優れた仕事をしていました。
00:08:56また、両者の「init（初期化）」コマンドの扱いもテストしました。
00:08:59Claude Codeのinitは、プロンプトをインラインで展開せずに実行されます。
00:09:02約90行のシンプルなClaude.mdファイルを作成し、そこには設計、アプリのフロー、
00:09:08フロントエンドとバックエンドの構造、実行に必要な全コマンドが含まれます。
00:09:12情報の多くが冗長で、エージェントにとってもあまりメリットがないため、
00:09:15すべてを保持し続ける必要性は必ずしもありません。
00:09:18Codexのセットアップはより洗練されていました。
00:09:20コミットガイドライン、プルリクエストガイドライン、セキュリティ指示などを適切に含みつつ、
00:09:24プロジェクト構造のセクションは詳細すぎず簡潔にまとめられていました。
00:09:28どちらも完璧ではありませんが、agents.mdの扱いはCodexの方が優れていました。
00:09:32次に、コードレビューの性能もテストしました。
00:09:35同じコードベースに対し、信頼性レビューを行うよう同一のプロンプトを
00:09:40CodexとClaude Codeに与え、レビュー結果を別々のファイルに記録させました。
00:09:44両方のレポートが生成された後、新しいセッションを開いて、
00:09:482つのファイルの差分（diff）を出力し、発見事項を比較するようClaudeに命じました。
00:09:51Claudeのレビューは、より詳細なものでした。
00:09:53すべての発見事項を優先度別に整理し、該当するコンポーネントや、
00:09:57問題の背景にある正確なコードスニペットまで含んでいました。
00:09:59一方、Codexのレポートは行番号には言及していましたが、実際のコードスニペットは含まれていませんでした。
00:10:03どちらのレポートも徹底しており、共通の発見もあれば、
00:10:07一方が見逃した問題を他方が捉えているケースもありました。
00:10:08Claude Codeは、漏洩したAPIキーや脆弱性などのセキュリティ問題も報告しました。
00:10:12ただし、今回のタスクは信頼性レビューであり、それらはスコープ外の問題でした。
00:10:17Claude Codeは作業中に遭遇したあらゆる問題を報告しましたが、
00:10:21Codexは厳密に信頼性の範疇にとどまりました。
00:10:22つまり、Codexのレポートは当初の依頼に忠実であったのに対し、Claude Codeは
00:10:27網羅的ではあるものの、特定のタスクへの集中度は低かったと言えます。
00:10:29開発スタイルを例えるなら、GPT 5.5はまずアプリの機能を
00:10:34正確に届けることに集中するバックエンドエンジニアのようであり、Opus 4.7は
00:10:40機能性とUXのバランスを重視するフルスタックエンジニアのようです。
00:10:45コンテキスト管理においては、Codexの方がClaude Codeよりも格段に優れていました。
00:10:48Claude Codeにはセッション内のコンテキスト編集機能があり、不要になった
00:10:53ツール呼び出しや推論ステップを会話から削除します。
00:10:55セッションから冗長な情報を取り除き、肥大化を防ぐためです。
00:10:58この圧縮（compaction）は完璧ではありませんが、少なくとも圧縮時に
00:11:02不要な部分をコンテキストに残さないようにしています。
00:11:03Codexはコンテキストの編集は行いません。
00:11:05会話が行われたそのままの形で、全体を圧縮します。
00:11:08Codexが優れているのは、直近の20,000トークンをメモリに保持し、
00:11:13その部分は一切圧縮しないという点です。
00:11:14これにより圧縮後のパフォーマンス低下を防ぎ、次のプロンプト以降も
00:11:18会話をスムーズに継続させることができます。
00:11:21パフォーマンスをテストしたところ、コンパクション後の性能は Claude Code よりも Codex の方が優れていました。
00:11:25Claude Code はより詳細で多段階のコンパクション・プロセスを採用していますが、Codex は末尾を保存することで
00:11:30実用面においてエージェントの有用性を高く維持しています。
00:11:33メモリの仕組みも両者で異なります。
00:11:35Claude Code のハーネスはセッション間でほぼステートレスであり、各セッションは
00:11:39前回のコンテキストがない状態で開始されます。
00:11:41現在、永続的な設定や指示を保存できるメモリ機能が追加されました。
00:11:46特定の手順を避けるよう指示すれば、それが保存され、
00:11:50同じプロジェクト内で後から再度適用されます。
00:11:52これは単一のプロジェクトで繰り返し作業する際に役立ちます。
00:11:54しかし、メモリはプロジェクト単位であるため、プロジェクトを切り替えると保存された挙動は失われます。
00:11:58Codex は逆のルートを辿っています。
00:12:00時間をかけて複数のセッションから情報を統合し、やり取り全体でグローバルなメモリを構築するため、
00:12:05単一のプロジェクトを超えてパターンを保持できます。
00:12:08これにより、異なるタスク間での一貫性が向上します。
00:12:11要約すると、Claude Code はメモリをプロジェクト内に限定する一方、Codex は
00:12:15セッションやプロジェクトを横断するアプローチを取っており、時間経過に伴う適応の仕方が異なります。
00:12:20Claude Code はより長く存在しており、開発体験向上のために絶えず開発されているため、
00:12:24Codex と比較して提供できる機能が多いです。
00:12:27Claude Code にはフック・システムがあり、エージェントのライフサイクルの特定のポイント、
00:12:32例えばツールの実行前後などで自作スクリプトを走らせることができます。
00:12:36不安全なコマンドのブロックや、フォーマッタの実行などが可能です。
00:12:39また、専用のワークツリーでサブエージェントを実行できるため、パフォーマンスが
00:12:43互いに影響し合うこともありません。
00:12:44モデルの努力レベルを制御でき、"ultra-think"（究極の思考）といったキーワードを使って
00:12:48特定のタスクに対して推論能力を最大限に引き出すことも可能です。
00:12:51現時点では、これらに相当する機能は Codex にはありません。
00:12:54エコシステムも Claude Code の明らかな勝利です。
00:12:56Claude のデスクトップアプリでセッションを実行し、モバイルアプリからタスクを委託できます。
00:13:01Claude Code、デスクトップアプリ、ウェブアプリ、ブラウザ拡張機能にまたがる活用範囲は、
00:13:06ウェブアプリと最近リリースされたばかりのデスクトップアプリ（テスト時点では力不足に感じられました）
00:13:11からなる Codex よりもはるかに広いです。
00:13:14また、Claude Code では環境間のセッション移動がより簡単で、
00:13:18異なるインターフェースをまたいで作業するのに便利です。
00:13:20Codex にも興味深い機能がたくさんあります。
00:13:22クラウド上では、同じタスクを n 回実行する attempt フラグがあります。
00:13:26複数の実装を生成し、その中から最適なものを選択します。
00:13:29Claude Code も同様のことが可能ですが、フラグとしてではなく、
00:13:33設定や指示を通じて行う必要があります。
00:13:34もう一つの Codex 特有の機能は、他とは一線を画すもので、
00:13:38OpenAI の画像モデルとの統合です。
00:13:39CLI で直接それらを使用して、作成中のウェブサイト用の画像を生成できます。
00:13:44Claude はビジュアル生成を主に SVG に頼っており、画像モデルを持っていないため、
00:13:49品質の面では比較になりません。
00:13:52実際の画像を必要とする UI を構築する場合、明示的に指示しなくても
00:13:56それを実行できるのは、この 2 つのうち Codex だけです。
00:13:58また、コンテンツを楽しんでいただけているなら、ぜひ「ハイプ・ボタン」を押してください。
00:14:03こうした動画をさらに作成し、より多くの人に届ける助けになります。
00:14:06サブエージェントは、Claude が最初に導入したコンセプトですが、両者とも採用しています。
00:14:10Claude Code の方が先駆者であるため、OpenAI よりもはるかに長い間
00:14:15エージェント中心でコーディング体験に特化してきた分、統合の成熟度が高いです。
00:14:19リモートセッションを通じてオーケストレーション可能なエージェントをサポートしているのに対し、
00:14:23Codex は主にターミナル環境内でのマルチエージェント・ワークフローをサポートしています。
00:14:27最大の相違点は、サブエージェントの呼び出し方です。
00:14:29Claude Code は明示的な呼び出しなしにエージェントを生成できますが、Codex は
00:14:35プロンプトで明示的に要求した場合にのみエージェントを作成します。
00:14:37Codex がエージェントを生成する際は、名前を付け、適切なプロンプトも渡します。
00:14:41コーディング性能に関しては両者ともかなり似ていますが、背後にある設計の選択が異なります。
00:14:46Claude Code のサブエージェントは明示的な許可リストを使用します。つまり、親エージェントが
00:14:51サブエージェントがアクセスできるツールを正確に定義しますが、Codex のサブエージェントは
00:14:55デフォルトで親からツールのアクセス権を継承します。
00:14:57また、Claude Code はすべてのサブエージェントに完全に新しいコンテキストウィンドウを与えます。
00:15:01サブエージェントは会話履歴にアクセスできず、親からのプロンプト、
00:15:06システムプロンプト、およびグローバルルールのみを参照します。Claude がコンテキストの分離を重視しているためです。
00:15:10Codex CLI はその逆を行います。
00:15:12すべての履歴をサブエージェント・セッションにコピーし、その上に親のプロンプトを重ねます。
00:15:17Codex のエージェントは、すでに議論された内容についてより多くのコンテキストを保持しており、
00:15:22それがパフォーマンスの向上に役立っています。
00:15:23実際、Claude Code の厳格な分離は、私たちの調査用サブエージェントには不利に働きました。
00:15:27それらを使用した際、直前のプロンプトしか見えず、以前のコンテキストがなかったため、
00:15:30結果は十分なものではありませんでした。
00:15:33Codex のエージェントは履歴全体を受け取るため、より効果的に反復作業ができ、
00:15:38継続性が重要なタスクでより優れたパフォーマンスを発揮します。
00:15:39以上で、今回の動画は終了です。
00:15:41チャンネルを支援し、このような動画制作を継続するのを助けていただける方は、
00:15:45下の「スーパーサンクス」ボタンからお願いいたします。
00:15:48いつもご視聴ありがとうございます。それでは、また次の動画でお会いしましょう。