Claude CodeとCodexという、現在最も注目を集めている2つのAIコーディングツールを使用し、全く同じ仕様のリアルタイム共同編集マークダウンエディタを構築する検証が行われる。開発プロセスの初期段階であるプロジェクトの骨組み作りから、リアルタイムの同期処理、ユーザーのカーソル位置の表示、さらにはダークモードの実装やファイル書き出し機能まで、全8段階のフェーズに分けて両モデルにプロンプトが与えられる。作業スピード、消費トークンやサブスクリプションの消費割合といったコスト、完成したアプリケーションの動作状況やバグの有無、そして生成されたソースコードのモジュール性やメンテナンス性といった品質の4つの基準から、両ツールの特性と優劣が詳細に分析される。
AIコーディングツールの頂上決戦
Claude CodeとCodex、コーディングにおいて本当に優秀なのはどちらでしょうか。今回の動画では、その疑問に白黒つけたいと思います。まったく同じ一連のタスクをClaudeとCodexの両方に実行させ、どちらがより優れているか、私なりの結論をお届けします。
もちろん、これは決して厳密に科学的な実験というわけではありません。かなり複雑なアプリケーションの構築を両者に依頼してみて、どのような結果が得られるかを確認していくものです。評価の基準は以下の通りとします。
まず第一に、スピードに注目します。実行に実際にどれだけの時間がかかるかという点です。次に、コスト、トークン数、使用量、あるいはサブスクリプションの枠をどれだけ早く使い切ってしまうかを見ていきます。
その次には、実際に完成した成果物を確認します。バグはあるでしょうか。しっかりと動作するでしょうか。提示した仕様書通りに作られているでしょうか。
そして最後に、コードの品質を評価します。それぞれのモデルに、もう一方のモデルが書いたコードをレビューさせます。その後、ソフトウェアエンジニアである私自身の手でも目視でレビューを行い、気づいた点をお伝えする予定です。
それでは、前置きはこのくらいにして、さっそく始めていきましょう。現在最も注目されているこれら2つのAIコーディングツールのライブ比較がどうなるか、非常に楽しみですね。
構築するアプリケーションの仕様
では、これからどのようなものを構築していくのか見てみましょう。今回はcollab AMDという、リアルタイムの共同編集マークダウンエディタの構築に挑戦します。これは比較的複雑なシステムであり、実際の開発現場のような状況下で、これらのツールがどれほど機能するかを試すのにうってつけです。
実装を求める機能としては、画面の分割表示、マークダウンエディタ、そしてリアルタイムの共同編集機能などがあります。WebSocketsを介して接続し、同じ行で発生する可能性のある複数の競合や変更を解決しなければなりません。他にも、他のユーザーのカーソル位置の表示と認識、ドキュメント管理、自動保存、データの永続化といった機能も含めます。
そして、もしそこまで到達できて、それまでにシステムが壊れなければ、バージョン履歴の管理やエクスポート機能など、他の機能も追加していくかもしれません。
公平性を保つため、両方のモデルに使用させたい主要な技術スタックをあらかじめ書き出しておきました。ごく簡単なアーキテクチャや処理の流れの概要、そしてさまざまなUIコンポーネントの大まかなレイアウトや、どのような見た目にしたいかという希望もまとめてあります。比較的自由度は残しつつも、公平に評価できるように同じ技術スタックを使用させるようにしています。
これが今回の仕様書です。開始する前に、この仕様書をコンテキストとして各モデルに渡します。そして、ここに用意してある一連のプロンプトを順番に実行していきます。
プロジェクト全体を一度に構築させるのではなく、8つのフェーズに分けて進めていきます。最初のフェーズはプロジェクトの雛形作成で、すでに作成済みのこちらのプロンプトを使用します。
次に、基本的なエディタとプレビュー画面を作成します。その次にはリアルタイムの同期機能を追加します。続いて、カーソル位置の表示を行います。その後、ランディングページ、ドキュメントのCRUD処理、接続ステータスの表示、エラーハンドリング、再接続機能、バージョン履歴、そして最後にエクスポート機能とダークモードの実装へと進んでいきます。ただ、このフェーズまでたどり着けるかどうか、どれだけの時間がかかるかはまだ分かりません。
これらすべての手順が書き出されています。これからClaudeとCodexを立ち上げます。その前に、私の設定をいくつか簡単に確認しておきましょう。その後、実際に実行を開始して、どのような結果が出るか見ていきます。
開発環境と初期設定の確認
どちらのソフトウェアも、ほぼクリーンインストールに近い状態です。少なくとも、私のこのコンピュータではあまり使用していませんでした。Codexに関しては、別のコンピュータで実行していたため、セッションは一つもありません。Claude Codeについても、過去数ヶ月の間に少し動かした形跡がある程度で、このマシン自体に2、3ヶ月ほど触っていませんでした。
現在、両方のツールをあるディレクトリでアクティブにしています。その中身は後ほど確認しますが、どちらも権限確認をバイパスする、つまりフルアクセスモードに設定してあります。そのため、変更をいちいち手動で承認する必要はありません。
使用するモデルについてですが、Claude側はopus 4.7を使用し、設定可能な最高モードであるマックスモードにしてあります。一方、Codex側はGPT 5.5を使用しています。ご覧の通り、エキストラハイに設定しており、1.5倍速モードは有効にしていません。opus 4.7側でその速度に対応する能力がないためです。
個人的にはopus 4.6の方が優れていると思っているのですが、今回は各社が最高モデルと謳っているものを使用することにします。まとめると、100万コンテキストのopus 4.7と、GPT 5.5を使用します。Codexを使用する場合の方がコンテキストウィンドウは小さくなりますが、それが現時点で彼らが提供する最良のモデルであり、利用可能な最高の推論能力を発揮してくれます。これにかかる費用や実行時間は一切気にしません。
ここで、Claude Codeでの私の使用量を素早く確認してみると、週間の制限に対して11パーセント、5時間枠の制限に対して5パーセントを消費している状態です。これなら、なんとか最後までやり遂げられるといいですね。
そして、Codex側の使用量に目を向けてみると、残りの枠が約100パーセント、週間でも99パーセント残っているのが分かります。後ほどこれらの数値に戻ってきて、どれほどの勢いでサブスクリプションの枠を使い切ったかを確認しましょう。
また、最終的にこれらをどのように評価するのか疑問に思われるかもしれません。私はコード分析を行います。それができる理由の一つは、私自身が実際にコードの書き方を知っており、長期間にわたってそれを学んできたからです。
それを踏まえ、もし皆さんがプログラミングを学びたいのであれば、本日のスポンサーであるboot.devについてお伝えしなければなりません。ここは最高水準の学習プラットフォームの一つであり、私の長年のパートナーでもあります。
コードの学習を始めた人々が直面する最大の難関は、退屈さだと私は考えています。チュートリアル動画を眺め、コードをコピーし、1週間ほどは生産的な気分に浸るものの、その後辞めてしまうのです。
しかし、boot.devのアプローチは完全に異なります。非常に実践的で、正直なところ、単なる講座というよりはゲームをプレイしているような感覚を味わえます。動画をただ視聴するのではなく、実際にプロダクトを構築しながらバックエンド開発を学んでいくのです。Python、SQL、Goを使った本物の課題に取り組み、経験値を稼ぎ、レベルを上げ、ボスを倒しながら、バックエンドのカリキュラム全般を進めていきます。
子供騙しのように聞こえるかもしれませんが、職場で実際に直面するような問題解決を行うため、本当に効果があります。また、彼らにはbootというAIチューターが用意されており、単に答えを教えてくれるだけではありません。行き詰まったときには追加の質問を投げかけ、問題の思考プロセスをサポートしてくれます。これは実際の学び方に非常に近いものです。
すべてのコンテンツは無料で閲覧でき、インタラクティブなコーディング機能や進捗追跡、AIのサポートを利用したい場合は有料プランに含まれます。興味のある方はboot.devにアクセスし、私のコードであるtech with Timを使用して、最初の1年間を25パーセントオフでご利用ください。この動画を支援してくれたboot.devに感謝します。それでは、検証に戻りましょう。
フェーズ1：プロジェクトの雛形作成
まず、マークダウンファイルを読み込ませることから始めます。最初のプロンプトを与えてみましょう。実行を開始します。これがプロンプト1です。ほぼ同時にこれらを走らせて、どのような結果が得られるか見てみましょう。
よし、Claude Codeがここでちょうど終了しました。だいたい6分経過したところです。正常に動作しているとのことですが、修正が必要な問題がいくつか発生したようです。Codexの方もほぼ終わりそうに見えますが、まだ実行中なので、完了したらすぐに戻ってきます。
さて、ようやくCodexもここで終了しました。面白いことに、CodexはClaude Codeが実行していたプロセスを強制終了してしまいました。競合を検出したため、同じポートで実行できるようにしたようです。今回のケースでは、Codexの実行時間は14分でした。Claudeの方は正確な実行時間を表示していないようです。しかし、私の見積もりではClaudeが6分でしたので、Codexの方が8分長くかかったことになります。
ですが、コードを素早く開いて確認してみれば理由が分かります。まずClaudeを見てみると、クライアントのフォルダがありますね。少しズームしてみましょう。ここにソースコードがあります。サーバーのフォルダもあり、その中にもソースコードがあります。もう一度見渡してみると、ファイル数はそれほど多くありません。それはそれで問題ありません。
次にCodexの方を見てみると、クライアントのソースフォルダ内には、はるかに多くのディレクトリが生成されていることに気づくでしょう。プロジェクトの雛形がより完全に作り込まれています。サーバー側に行ってみても同様です。タイプ定義ファイル、ビルド成果物のフォルダ、データフォルダなど、Claudeのバージョンには存在しないものが一通り揃っています。
かなり駆け足で確認していますが、重要なのは、Codexは実行にずっと長い時間がかかった一方で、それだけ多くの作業をこなしたということです。
ここでCodexのアプリケーションを開いてみると、このような画面になっています。一方のClaude側は、Codexが走り出す前から、実行を依頼したにもかかわらずブラウザには何も表示されませんでした。
ですので、Claudeに対して公平を期すために、アプリケーションを実行してプレビューできるようにしてください、と頼んでみましょう。対応できるか見てみます。先ほどはプレビュー画面も表示されず、何も検証してくれませんでした。単にサーバーを実行できるよ、と告げただけだったのです。しかしCodexの場合は、実際にブラウザを開いてプロセスを進めてくれました。それが正常に動作していることを検証し、新しいドキュメントを作成したのです。コンピューターユースタスクを使って、リアルタイムでその作業を行うのを私は眺めていました。Claudeにも同様の作業を行う能力を与えていたのですが、実行されませんでした。
よし、これでClaudeの方も実行されました。しかし、Codexのようにプレビュータブの中で実行されたわけではありません。それでも、このような見た目になっていることが確認できます。もちろん、まだボタンを押すことはできませんが、少なくとも立ち上がってはいます。よし、それでは次のタスクに移りましょう。
フェーズ2：画面分割エディタとプレビューの実装
同じように、次のプロンプトを貼り付けます。ここで行うのは、画面を分割したエディタのようなものの構築です。左側のパネル、右側のパネル、そしてトップバーなどを追加するように指示しています。これも同様に、ほぼ同じタイミングで実行して、次への進捗を見てみましょう。
よし、今回は両方とも同時に終了しました。Codexのアプリケーションは現在ポート5173で動作していますが、Claude Codeのほうは何らかの理由で動作していません。ですので、同じように素早く指示を出しましょう。ユーザーインターフェースにアクセスできるように、これがポート5173で確実に動作しているか確認してください、と伝えて、立ち上げられるか見てみます。デプロイを正常に機能させる点で、いくつか問題を抱えているようです。
Claudeの準備を待つ間、Codexで作成した共同編集モードを見てみましょう。新しいドキュメントがあります。これをクリックして中に入ると、何らかの無限ループが発生してしまっています。明らかにこれは修正しなければならないバグですね。前の画面に戻り、ドキュメントを削除して、新しいドキュメントを作り直してみます。あ、いけました。別のドキュメントに入り、ハローと入力してみると、同じようにバグが発生してしまいます。
では、こちらに戻ってみましょう。実行できたでしょうか。何もリスニングしていませんね。動作するか確認してみます。よし、Claude Codeが立ち上がり、アクセスできるようになりました。
しかし、新しいドキュメントのボタンが機能していないようです。代わりに、URLを直接入力してドキュメントのテスト画面に移動してみます。画面が表示されました。試しに、ハローワールドと入力してみましょう。少なくとも今回はエディタが機能しています。ボタンこそ動きませんでしたが、全体的な機能としてはCodexで見たものよりも優れているように思えます。あの奇妙な無限ループのバグも発生していません。それでは、先へ進みましょう。
フェーズ3：リアルタイム同期機能の追加
先ほど素早く見つけたそれぞれの不具合を両者に伝え、次のプロンプトを与えます。次回のイテレーションがどうなるか確認しましょう。
よし、両方に不具合を伝えました。次に行うのはリアルタイム共同編集機能の追加です。2人が同時にメッセージを送信したり、内容を変更したりできるようにします。これらを送信して、結果を見てみましょう。
おや、興味深いことに、今回はCodexが先に作業を終えました。だいたい7分が経過したところです。Claude Codeの方はまだ処理を続けています。再びいくつかの問題に直面しているようで、開発サーバーの実行やデプロイの確立にかなり手こずっています。先ほどご覧いただいたように、Codexはそのあたりに全く問題がないようです。
Claudeの実行を待つ間、Codexの完成版を見てみましょう。画面を更新します。これを開いてみます。前のドキュメントは完全に壊れてしまったので、新しいものを開きましょう。そして、何かを入力してみます。そうですね、ハローワールドと。Pythonのコードなども試してみましょう。Pythonを指定して、関数の定義を書いてみます。正常に動作しているようです。123、いいですね。素晴らしい、良好に見えます。
ここで別のタブを開き、リアルタイムで編集できるか試してみましょう。すでにカーソルの動きも反映されているようです。こちらで文字を入力すると、もう一方のタブでもほぼ一瞬で更新されます。実際にリアルタイムで変化しているのが分かります。これらを並べて表示すれば、より確認しやすいでしょう。
ハローワールドと入力すると、しっかりと更新されています。これを閉じましょう。他のユーザーが入力した文字を削除してみると、リアルタイムの共同編集が機能しているのが分かります。すでにカーソルの識別表示機能まで実装されています。ただ、そこにユーザー83と表示されているのは少し奇妙ですね。なぜそうなっているのかは分かりませんが、ともかく意図は伝わるはずです。機能としては動作しており、リアルタイムの処理も機能しています。これはかなり素晴らしいことです。
それでは、Claude Codeの終了を待って、そちらのバージョンもテストしてみましょう。
よし、Claude Codeも完了しました。このURLをテストしてみると、動作しているように見えます。カーソルの動きも反映されており、ハイライト表示も同様に機能しています。新しいドキュメントのボタンも、共有ボタンを押したときではなく、新規作成を押したときには機能していました。それは動いているようです。
ただ、ドキュメントが保存されていないように見えます。ページを更新する必要があるのかもしれません。これは少し気になるバグですので、後で確認してみる必要があります。ともかく、機能自体は動作しています。では、次のプロンプトに進みましょう。
フェーズ4：カーソル存在検知のブラッシュアップ
さらに進めていきます。次の指示として、すでにそれらしきものは実装されていますが、より具体的なカーソルの存在検知機能を追加するよう伝えます。これにより、各ユーザーがどこにいるのか、何人のユーザーが接続しているのかなどを正確に確認できるようになります。もちろん、大規模なスケールでのテストは行いませんが、これで実行してみます。
処理が進む間に、これ以上進む前にコードの中身を少し覗いてみましょう。まずClaudeのアプリケーションから見ていきます。クライアントフォルダ、ソースフォルダがあり、いくつかのコンポーネントとページフォルダがあります。これらを開いてみましょう。
巨大すぎるコンポーネントが生成されていないか確認します。全体的には問題なさそうです。スタイリングにはTailwindが使用されているようですね。ここに新しいエディタオブジェクトのようなものがあります。ページフォルダに行くと、エディタが作成されています。これもそれほど大きなファイルではありません。
インデックスファイルを確認してみます。まだそれほど多くの処理は行われておらず、Tailwindのインポート文が並んでいる程度です。いくつかのスクリプトがありますが、これが何をしているのかは分かりません。同調用のsmokejumper.jsというファイルがありますね、興味深いです。
サーバー側を確認すると、データベースがそこに格納されています。そしてソースフォルダ、データベース、インデックスがあり、これらが揃っています。コードの総量はそれほど多くありません。
全体として、かなり良好だと言えます。次にCodexの方を見てみましょう。一旦これらをすべて閉じます。クライアントフォルダを開きます。こちらの方が少し構造化されている印象を受けます。タイプ定義、ページ、ライブラリ、コンポーネントといったフォルダがあります。API呼び出しの観点からも、処理がより細かく分離されています。
当然、存在検知の処理も行われています。ユーザー向けの処理も含まれていますね。ビルド成果物のフォルダ、アセットフォルダ、ノードモジュールもあります。他にはログフォルダもあります。実際にログを保存しているようで、これは便利です。
そしてサーバー側を確認すると、データフォルダ、ビルド成果物フォルダ、ノードモジュール、ソースフォルダがあります。ソースの中にはタイプ定義、データベース、そしてindex.tsがあります。どれも肥大化しすぎてはいません。めちゃくちゃに散らかっているような箇所もありません。全体として非常に綺麗にまとまっています。この次のプロンプトでどのような変化が起きるか見てみましょう。
よし、5分ほど経過しました。Claude Codeは約1分前に終了しています。Codexはまだ実行中で、現在はすべてを検証しようと試みています。Codexに関して気づいたことの一つは、自身の作業を検証し、ブラウザの操作手順を実際に実行することに長い時間を費やすという点です。これには当然少し時間がかかります。一方でClaude Codeは、検証を行うことなく、そのまま作業を完了させてしまいます。私が直接指示を出していないにもかかわらず、Codexのようにブラウザ上ですべてのテストを行うようなことはしません。このあたりは現時点で興味深い違いです。
ともかく、両者が終了するまで待って、状況を確認しましょう。
よし、Codexも3、4分遅れてここで終了しました。やはり多くの検証作業を行っており、正常に機能したと報告しています。ここで、これらを素早く開いてみましょう。ブラウザのウィンドウがたくさんあるので整理する必要があります。
右側にあるのがClaudeのバージョンです。右側の画面では、ユーザーが表示され、異なるカーソルアイコンが表示されているのが確認できます。左側にあるのがCodexのバージョンです。
ここで面白いのは、カーソルが実際にそのブラウザウィンドウ内でアクティブな時にしか表示されないという点です。ブラウザウィンドウ間を移動すると、もう一方のカーソルが消えるのが分かります。これは見ていて面白いですね。
上部にアイコンが表示され、すべてが連動しているのが確認できます。こちらの方が見た目が少し優れているように思えますし、保存もしっかり行われているようです。適切なエリアに戻ってみると、全体的な挙動は掴めるはずです。しっかりと動作しており、機能しているため、問題ありません。それでは最後のプロンプトに移動しましょう。
フェーズ5：全機能の統合と最終ブラッシュアップ
実は他にもいくつかプロンプトを用意していたのですが、それらをすべて一つに統合することにします。より大きなタスクをこれらに一気に投入してみて、このアプリケーションに実装したかった残りの機能をすべて完了できるかどうかを確認するためです。
最終プロンプトとして、フェーズ5以降の、ランディングページの作成から全体の調整、バージョン履歴の管理、ダークモードでのエクスポート機能までをすべて一つにまとめました。これをClaudeとCodexの両方に渡します。結果を見てみましょう。
よし、ようやく両方とも完了しました。今回のケースでは、Codexの実行には26分かかりました。これはかなりの長時間です。一方、Claude Codeの方は7、8分ほどでした。
ここで気づいた明確な違いとして、Codexは非常に多くのテストを実行していました。実際にブラウザを立ち上げてプロセスを進めていたのです。その過程で何かを乱してしまったようで、スタイリングを修正してほしい、接続が切れてしまっている、という追加のプロンプトを1回与える必要がありました。しかし、費やした時間の大部分は、自身が書いたすべての機能を実際にテストすることに充てられていました。
対照的に、Claude Codeが何をしたかというと、すべての機能を一気に書き上げ、終わったから自分で確認してみてね、と言わんばかりに終了したのです。
完成したアプリケーションを比較してみると、正直なところ、ほぼ見分けがつかないほど似ています。どちらにも大きな欠陥のようなものは特に見当たりませんでした。詳しく見てみると、Codexのバージョンは自身で多くのテストを生成していました。画面上には、どこにユーザーがアクティブに存在しているかを示す小さな緑色のインジケーターが表示されています。前の画面に戻ると、同じウィンドウで開いているため、1人のユーザーがここにいることが分かります。もう一度開いてみると、本来ならすぐに2人に更新されるはずですが、これはバグかもしれません。ともかく、ダークモードとライトモードの切り替え機能が備わっています。マークダウン形式、あるいはHTMLファイルとしてエクスポートする機能もあります。
他には、リンクをコピーして他のブラウザに貼り付けられる共有機能もあります。そして、ここに参加しているすべての人々を確認することができ、ご覧の通り、すべての更新がリアルタイムで機能しています。
ここまでの話はClaude Code側のものです。Codex側についても全く同じです。ダークモードとライトモードがあります。ドキュメントをクリックして中に入ると、ダークモードに切り替えることができます。ここに123と入力するとコードブロックが表示されます。Pythonのコードやハローワールドなど、何でも入力できます。
同じドキュメントを別の場所で開いてみましょう。こちらで開きます。そうすると、すぐに数値が2に更新されるはずです。リフレッシュしてみると、2になりました。カーソルが表示され、ハイライトも同様に機能しています。共有ボタンを押して、別のウィンドウに配置します。
元の画面に戻ると、数値が3になっています。すべてが表示され、連動しているのが確認できます。アクティブなカーソルなどもすべて確認できます。こちらに戻ってみると、ポップアップが表示されています。
結局のところ、最終的にはほぼ完全に同じ結果が得られました。ごくわずかな細かい違いがある程度です。そうなると、ここからはコードの品質を確認し、どちらがより優れた成果物を提供してくれたかを見極める段階になります。
ソースコードの品質検証
先ほどのClaudeのアプリケーションから見ていきましょう。クライアントフォルダ、ソースフォルダを開き、コンポーネント、ライブラリ、そしてページフォルダを確認します。ページには、ノットファウンドページとエディタページがあります。
一見したところ、私にとっては少し雑多な印象を受けます。かなりのネストが発生していますが、JavaScriptやTypeScriptのコードではよくあることです。インラインコメントが大量に含まれていますが、これは個人的にはあまり好みません。また、useFetchの中でAPIを直接呼び出している箇所があります。これは通常ベストプラクティスとは言えず、一般的には専用の関数を用意したいところです。そのため、このあたりはあまり良くありません。
やはり、一見したところ非常に複雑に見えるコードが散見されます。Tailwindを使用する以上、スタイリングに関する部分は避けられませんが、HTMLのエクスポート処理のあたりは少し奇妙な書き方になっています。ただ、モデルはそう処理したのでしょう。トースト機能やテーマタグもあります。すべてに目を通すわけではありませんが、全体としてコードがどのような外観をしているか、大まかな感覚を掴もうとしています。
少なくとも、コンポーネントのレベルではかなりモジュール化されています。履歴パネルやマークダウンエディタなど、さまざまな要素に分かれています。コンポーネントと同じファイルにこれらすべてが詰め込まれているのは好みませんが、それほど悪くはありません。画面分割のコンポーネントも同様です。ここでも多くのネストが見られますが、全体的には許容範囲内です。これがクライアント側の状態です。
次にサーバー側のソースフォルダ内にあるindexを確認します。すべてのAPIルートが、ただ一箇所にまとめて放り込まれています。とはいえ、200行程度ですので、ひどすぎるというわけではありません。データベース用のy.jsに関する処理もありますね。すべてが一つのファイル内で作成されています。バックエンドに関してはこれだけで、他にはそれほど多くの処理は行われていません。全体として、コード自体は悪くありません。しかし、長期的な視点で見ると、世界で最もメンテナンスしやすいコードとは言えないでしょう。
次にCodexを見てみます。クライアントコード、タイプ定義、ページ、ライブラリ、コンポーネントがあります。フォルダ構成は先ほどと似ています。中身を確認していきましょう。
マークダウンエディタは問題ありません。肥大化していません。構造としては、こちらの方がよりモジュール化されているように見えます。独立したuseEffectがいくつか存在し、個別の関数を呼び出しています。ネストが深すぎて乱雑になっているような箇所も見当たりません。こちらの方が少し読みやすく感じられます。
APIの処理を確認してみると、すべてのAPI関連のコードが別のファイルに切り出されているのが分かります。これは私好みの設計ですし、型定義も正しく行われています。存在検知の処理についても同様に、独立したファイルで管理されています。やはり非常にクリーンに見えます。大まかな感覚を掴むためにざっと目を通していますが、テーマに関する処理も別のファイルに分かれています。これは先ほどのアプリにはなかった構成です。ユーザーの型定義もあります。タイプ定義ファイルが用意されていますが、これもClaudeのアプリケーションにはなかったものです。
App.tsxを確認します。何か見落としはあるでしょうか。いいえ、全体的に見て、Codexの方がコードをシンプルに保つという点で、より優れた仕事をしたと言えそうです。クライアント側において、Claudeのアプリケーションよりもコードの総量が明らかに少なくなっています。
また、すべてをデータフォルダに配置しているのも良い点です。ログも保存されていますが、これはもう一方のアプリケーションのサーバー側にはなかったものです。
サーバーのソースフォルダを見ると、型定義とデータベースがあります。データベースの構成は似ていますね。以前見たものと非常に近いですが、処理を分離するための関数がいくつか追加されており、少し長くなっています。綺麗なインデックスファイルがここにあります。APIについてもざっと確認してみますが、型定義があり、大体これだけです。正直なところ、このタイプのアプリケーションにしてはそれほど多くのコード量ではありません。
総評として、両方のコードベースともに概ね良好だと言えます。もちろん、あらゆるベストプラクティスに従った完璧にモジュール化されたものというわけではありません。1行ずつ精査していけば、多くの間違いや、プロダクション環境のコードベースには含めたくないような箇所がいくつも見つかるはずです。
ただ、もし自分がどちらのコードベースを手元に残したいか選ぶとすれば、おそらくCodexのアプリケーションの方を選ぶでしょう。コードの品質がわずかに高く感じられるからです。適度に処理が分散されており、クライアント側のコード量もClaudeのアプリと比較して少なく抑えられているように見えます。ただ、それを完全に結論づけるには、まだ十分に時間をかけて読み込めていません。
一方でClaudeに関しては、処理内容に対して少し過剰に複雑になっている印象を受けます。多くのネストが存在し、解析しづらい奇妙なファイルやコメントが大量に含まれています。Codexのクライアント側などを確認してみると、インラインコメントはそれほど多く含まれていません。しかしClaudeはコード内に大量のコメントを投げ込む傾向があり、私はこれをあまり好みません。コードベースが拡大していくにつれて、これはあまり良い習慣とは言えなくなります。
お互いのコードをクロスレビュー
ここで、これらのコードベースを回収し、それぞれ反対のモデルに渡してみたいと思います。お互いのコードを徹底的に批判させ、それぞれのモデルがどう考えているか、そのニュアンスを掴んでみましょう。その後、最終的な評価をまとめて締めくくりたいと思います。
それほど厳密なプロンプトを使用しているわけではありませんが、このコードベースをレビューしてください、全体的な品質、改善点、よくある間違いなどを教えてください、とシンプルに指示しました。CodexにはClaudeのアプリを渡し、ClaudeにはCodexのアプリを渡します。どのような反応が返ってくるか見てみましょう。
よし、Codexの処理がちょうどここで終わるところです。だいたい7分かかりました。Claudeの場合は2分ほどでした。ここでも、Claudeの方がはるかに早く本質に切り込むという傾向が見て取れます。
一方で、Codexは実際にアプリケーション上でテストを実行していました。テストを走らせ、本当に動作するのか、何が起きているのかを確認していたのです。アーティファクトを作成させて、サーバーをテストしてみよう、といった動きを見せるのに対し、Claudeは単にコードを読み取っただけでした。
まずは、ClaudeのコードをレビューしたCodexの意見から見てみましょう。WebSocketによる書き込みが、RESTのライフサイクル外でドキュメントを作成してしまう可能性がある、と指摘しています。また、削除されたドキュメントが、開いているクライアントによって再構築される可能性があること、認証が備わっていないこと（これは両者共通なので問題ありません）、永続化処理が同期的に行われており、更新ごとにドキュメント全体を処理していること、履歴の復元処理が古いコンテンツを復元してしまう可能性があること、などが挙げられています。
全体としてはコードに問題はないとしつつも、改善すべき主要なパターンとして、コンポーネントの内部からローカルのfetchを直接呼び出している箇所を挙げています。これは私が先ほど指摘した点と同じですね。他には、ツール類の整備やリポジトリの衛生面、クライアントのビルド、そして推奨される優先順位などがまとめられており、悪くない内容です。
次に、ClaudeによるCodexのコードのレビューを見てみると、多数の問題点が提示されました。そのすべてが実際にすぐ対応すべき致命的なものというわけではありませんが、見せかけの保存インジケーターがあること、キー入力ごとにディスクへの書き込みが発生していること（これはもう一方のモデルも同様だと思います）、認証がないこと（これも問題ありません）、ディレクトリの不一致という軽微な問題、キー入力ごとのパッチ処理、マイグレーションによって孤立したテーブルが残ること、などが指摘されています。そして、確認すべき事項といくつかの推奨設定がまとめられた、見やすい表を提供してくれました。
最終評価：どちらを選ぶべきか
現時点で、どちらのツールを使用すべきか、全体的な推奨事項を提示するのに十分な情報が集まりました。
まず注意すべき点として、Claudeはよりダイレクトに本質を突く傾向があります。指示したことを正確に、そのまま実行してくれます。一方で、Codexに依頼すると、より主体的に動いてくれます。これは、実行時間が少し長くかかることを意味しますが、サーバーを実行したり、テストを行ったり、バグを修正したりと、ユーザーが直接指示していなくても必要になると判断した処理を先回りして実行してくれます。
スピードの面では、間違いなくClaudeの方が大幅に高速です。いくつかのタスクでは似たような時間になることもありましたが、大半の状況において、CodexはClaudeで同じタスクを実行するよりも50から70パーセント長い時間がかかります。そのため、完全にゼロから何かを立ち上げる場合、Claudeを使用した方が圧倒的に早く作業を終えることができます。
一方で、Codexの方は、より大規模なアプリケーションや、多くのテストを伴う環境、あるいは書くコードの量自体は少なくても、より深い思考や推論が必要とされる複雑なタスクに向いているように見受けられます。少なくとも、今回の検証から得られた印象としてはそのように言えます。
全体のコード品質に関しては、非常に似通っています。一般的には、Codexの方がわずかに優れていると感じますが、これは好みの問題でもあります。すべての行を精査したわけではないので、断言するのは難しいところです。
そして、最後に確認したいのが使用量、つまりコストについてです。今回の検証を終えた時点で、私の5時間枠の使用量は23パーセントまで上昇しています。コンテキストの規模がそれほど大きくなかったことを考えると、これはかなり高い消費率であり、興味深い結果です。
一方でCodexの方は、最大容量に達したため、おそらく3、4個前のプロンプトの段階でコンテキストウィンドウの自動圧縮が行われています。履歴を確認してみると、25万8000トークンに達していました。そして使用量のレート制限を確認してみると、5時間の枠に対してわずか5パーセントしか消費していません。正確な金額の差は失念してしまいましたが、Claude（Anthropicのモデル）を使用した場合は、Codexと比較して約2倍から2.5倍、サブスクリプションの枠を多く消費したことになります。
つまり、Codexの方が長い時間をかけてより多くの推論を行ったにもかかわらず、コストに対する獲得トークン数は、ClaudeやAnthropicのモデルと比較して大幅に効率が良かったということになります。これは、私が過去に行った他の実験とも非常に一致する結果です。今回の検証ではAPIを使用しておらず、正確な請求額の手元データがないため、正確なトークン数までは分かりません。しかし重要なのは、私の見積もりでは、同じタスクに対してAnthropicのモデルを使用すると、Codexを使用する場合よりもおそらく3から4倍はコストが高くなるということです。
結論として、私の分析では、これら両方のツールを併用するのがベストであると考えています。完全にゼロから何かを立ち上げ、超高速で形にしたい場合は、おそらくClaudeを選ぶのが正解でしょう。一方で、デバッグやテストを行い、機能が正常に動作していることを確実に検証したい場合、あるいはより大規模なアプリケーションの中で作業を進める場合は、Codexの方がうまく機能するはずです。これは、私が今回の分析のベースにしている他の開発シナリオでも同様の傾向が見られました。
最終的には、どちらも極めて有能なモデルです。パフォーマンス自体は非常に近いものがありますが、特定の状況においてそれぞれの強みが発揮されます。今回は、両方のモデルを最高精度の推論を行うエキストラハイモードに設定していたため、これをハイやミディアムに落とせば、当然どちらも劇的に高速になります。Codexに関しては、1.5倍の高速モードに切り替えたとしても、Claudeを使用するより安価に抑えられます。そうすれば、より速いレスポンスが得られ、今回見られたような速度のハンディキャップをほぼ相殺することができるでしょう。
というわけで、今回の動画は以上となります。世界で最も科学的な検証方法というわけではないことは重々承知しています。もし皆さんがより厳密な検証を見たいのであれば、将来的にはそうしたコンテンツも作成できますので、ぜひコメントで教えてください。
今回はただこれらを実際に試してみて、私自身の率直な体験を共有し、これらのツールが一体どこまでできるのかをお見せしたかったのです。誰もが両方のモデルを絶賛していますが、特定のケースにおいては依然として限界も存在します。彼らができることは素晴らしいですが、当然ながら、適切なプロンプトの与え方や、どのタスクにどちらのツールを選ぶべきかを知っておく必要があります。それこそが、この動画の目的でした。
もし楽しんでいただけたなら、ぜひ高評価とチャンネル登録をお願いします。それでは、また次回の動画でお会いしましょう。
コメント