AIコーディングツールであるClaude Code、Codex、Cursorの3大ソリューションの核心にある設計思想や開発チームの哲学の違いを、実際の利用体験に基づいて深く掘り下げた解説。モデルの賢さや画面の見た目だけでなく、AnthropicとOpenAI、そしてCursorのチームが、ソフトウェア開発の未来をどのように捉えているかを紐解く。トークンを大量消費してでも見た目の生産性を演出するマーケティング重視のアプローチから、トークン効率を高めて実用的な正確性を追求するエンジニアファーストの姿勢、そして未来を見据えた強力なクラウド環境の構築まで、各ツールの強みと本当のターゲット層が明確に示されている。
各ツールの核心にある設計思想の違い
今回はいつもとは違う感じの動画をお届けします。Claude Code、Codex、Cursorといったツールの本当の違いを掘り下げてみたいと思います。どのモデルがどれくらい賢いかとか、どんなタスクをこなせるかといった話ではありません。これらのソリューションの根底にある設計思想の違いを解き明かしたいのです。なぜなら、これらは皆さんが思っている以上に、全く異なる方向性を向いているからです。
皆さんもClaude CodeやCodexを使ったことがあるでしょうし、CursorのCLIやIDE、あるいは彼らのクラウド環境を試したことがあるかもしれません。すでに特定のツールを愛用していて満足しているなら、その考えを変えさせるつもりはありません。私がやりたいのは、それぞれのツールが思想的に何を達成しようとしていて、どのように異なっているのかを説明することです。
私がこの話をしたい最大の理由は、ClaudeからCodexへと移行したことで、私自身のAIエージェント開発に対する考え方が大きく変わったからです。もちろん、CursorからClaude Codeに移ったときも変わりましたが、今回の変化は以前よりもずっと気に入っています。世間でClaude CodeとCodexの比較が語られるとき、多くの場合はモデルの性能やUIの見た目ばかりに終始しており、これらツールの核にある部分や、開発チームがソフトウェア開発のあり方をどれほど異なる視点で考えているかについては、ほとんど触れられていません。
もっと率直に言えば、この動画を作ることになったきっかけは、Twitterでの私の返信が予想以上の注目を集めたからです。そこで私は、AnthropicとOpenAIがコーディングツールに対して抱いている思想的な違いをいくつか指摘しました。しかし、そこでは書ききれなかったことがたくさんあります。ですから、今回はさらに踏み込んで、ツールごとの違いや業務への効果的な取り入れ方、そして長期的にこれらがどこへ向かっていくのかを徹底的に分析します。
特定のツールへの乗り換えを勧めるのが目的ではないので、できる限り公平な視点でお話しします。それぞれのツールがそもそも誰のために、何の目的で作られたのかを理解するヒントにしてください。
広告セクション：チームの動きを可視化するAIコードレビューアプリ
ここで今日のスポンサーについてお話しさせてください。AIによるコードレビューアプリの紹介ですが、どうか画面を切り替えないでください。本当に実用的なツールなんです。Macroscopeというアプリですが、私や私のチームはこれに本当に驚かされています。私のコードベースに導入して以来、チームのジュリアスが一番気に入っているツールになりました。T3 Codeでもこれを動かしていますが、彼はお気に入りです。
でも、私が最も気に入っているのはそこではなく、チームのステータスを追跡してくれる機能です。いくら小さなチームであっても、ジュリアスが恐ろしいスピードでコードを書きまくるので、リーダーとして全員の動きを把握するのは本当に大変です。このアプリは、メンバーがコーディングに費やした時間を推測してくれます。ジュリアスの異常なアウトプットのせいで、たまに計測がバグることもあります。413時間という数字は狂っているように見えますが、彼のコミット履歴を見れば、それが誇張ではないことが分かります。
さらに素晴らしいのは、チームがこの1週間で何をしてきたかを一覧で示してくれるステータスアップデート機能です。ここ一週間で、ジュリアスはT3 Codeのマルチプロバイダ対応のソース管理、PI拡張機能、VS Codeのテーマ、T3チャット、モデルのルーティング、課金システム、UX、そしてデスクトップのUIフレームワークの書き換えなどを行いました。これらは、チームの動きが早すぎてリーダーである私ですら把握しきれていなかったことですが、このアプリのおかげで一目で分かります。非常に便利です。
包み隠さず言えば、このアプリから得られた詳細な洞察のおかげで、私はチーム体制に関する重要な決定を下すことすらできました。それくらい、何が起きているかが鮮明に見えるようになります。レビュー機能も実に見事です。エージェントを動かすのが本当に快適で、リントルールのような独自のコーディング規約をディレクトリとして設定しておくだけで、Macroscopeがそれを自動的に適用してくれます。ファイルを一つ作成し、チェックしたい内容と対象ファイルを指定すれば、それ以降のすべてのコードレビューで自動的に実行されます。ベンも自分のプロジェクトでこれを使い倒しています。特に、プルリクエストの自動ラベル付け、レビューの抽出、正確性のチェックなど、期待される標準的な機能をフルに活用しています。プルリクエストの自動ラベル付けは本当に便利で、これまで見たことがない素晴らしい機能でした。ジュリアスに教えてもらったのですが、私もT3 Codeに導入しようと考えています。
Claude Codeの現状とゲーム化された生産性
まずは、最近最も知名度が高く、AIコーディングの代名詞のようになっているClaude Codeから始めましょう。以前はCursorが占めていたポジションを、今や完全にこのツールが奪い取った印象があります。YCのバッチでも、以前は90%がCursorを使っていましたが、今では70%がClaude Codeを使っているような状況です。それくらい急速なシフトが起きました。
では、Claude Codeの本質をどう捉えるべきでしょうか。このツールの始まりは、開発者のボリスが、モデルがさらに賢くなった未来のコーディングの姿を想像しようとした試みでした。人々がブラウザでClaudeの画面を開き、コードを貼り付けて修正案をもらい、それをまたコードベースに手動でコピペしているような状況を見て、改善の余地があるのは明らかでした。Cursorもチャットインターフェースを通じてコードについて対話し、変更を適用していくという形で進化を遂げていましたが、Claude Codeはいくつかの点で決定的に異なっていました。
最も大きな違いは、ターミナル上で動作するように作られたという点です。新しいワークフローを強制したり、IDEを別のものに乗り換えさせたり、新しいアプリのインストールやクラウドへの完全移行を求めるのではなく、開発者が普段使っているターミナルという場所に寄り添ったのです。ターミナル上でAIを使って最高に快適なコーディング体験を作る、それが彼らの狙いでした。
もちろん、それによる固有の妥協点もあります。画像を貼り付けるような操作は、ターミナル上では決してスマートにはなり得ません。貼り付けた画像を視覚的に確認することはできませんし、テキストの選択や独特のスペースの挙動など、ターミナルの制約に縛られる部分があります。画面のチラつきが気になるので新しいフルスクリーンモードを使っていますが、これはターミナルへの描画方法が全く異なるため、従来のスクロールバッファの挙動を使わず、すべてのUI要素を擬似的に自前でレンダリングしています。これにはメリットもデメリットもありますが、私は好んで使っています。将来的にはこれがデフォルトになるようです。
Claude Codeが押し出している導入のしやすさは特筆すべきものです。導入コマンドをターミナルに貼り付けるだけで、すぐに使い始めることができます。ブラウザでの認証やAPIキーの入力は必要ですが、他の開発ツールを一切変更することなくセットアップが完了します。Claude Codeを立ち上げてコードを変更し、それをVS Codeで確認してコミットする、といった具合に、ターミナルの一つのタブとして自然に組み込めます。
しかし、時間が経つにつれてユーザーはより多くの機能を求め始めました。自動でのgitコミットやGitHubへのプッシュ、プルリクエストの変更検知、さらにはMCPを介して他の情報源とClaude Codeを接続することなどです。スマホからリモートで起動して制御したいという要望や、より優れたUIでの並列処理を望む声も上がりました。Anthropicは当初、ツールの機能を広げすぎないようにしていましたが、ある時期を境にこれらの機能を積極的に取り込み始めました。
Claude Codeの決定的な転換点、あるいは誰もが衝撃を受けた瞬間は、昨年末のOpus 45の登場でした。モデルの能力が飛躍的に向上したことで、ターミナルを介してシステム全体へのアクセス権をエージェントに与えることの価値が一気に高まりました。コードベース全体をgrepして目的の場所を見つけ、コマンドを実行してデプロイし、MCPでデータを取得するといった一連の操作が、モデルの賢さのおかげで非常に信頼性の高いものになったのです。コードそのものを信頼できるようになったため、私はコードを逐一画面で確認する必要性を感じなくなり、ターミナルの強力な機能をフル活用できるこのスタイルにのめり込んでいきました。さらに、許可を毎回求めないバイパスモード、いわゆるヨローモードでも、モデルが十分に賢いため、悪意のあるコマンドや誤ったコマンドを実行するリスクが低くなり、今では私もほとんどのツールをこのモードで動かしています。
Opus 45の登場は業界に大きな地殻変動を起こし、多くの開発者がClaude Codeのスタイルへと傾倒していきました。これはTwitterをはじめとするコミュニティでも大きな話題となりました。Anthropicは、開発者がターミナルを愛し、エージェントが自律的に動く姿に興奮し、ツールが勝手に進化していく感覚に喜びを覚えるという性質を実によく理解していました。
ここで、私が何度も口にしてきた少し物議を醸す意見を言わせてください。Claude Codeは、開発ツールであると同時に、極めて強力なマーケティングツールでもあります。Anthropicは主にこのツールを使って、AI開発において自社が最高のポジションにいるというイメージを植え付けようとしています。彼らが追加する機能の多くは、Twitterでのスクリーンショット映えを強烈に意識して最適化されています。たとえば、ペットモードのような機能は、間違いなくユーザーが数字をキャプチャしてTwitterでシェアすることを目的に作られています。また、サブエージェントモードはトークンを凄まじい勢いで消費しますが、その動作の見た目と、何より「作業が猛烈に進んでいる感覚」の演出が天才的です。初めて複数のサブエージェントを立ち上げてチームとして動かしたとき、自分がほとんど何もしていないのに画面の向こうで大量の処理が進んでいくのを見て、信じられないほどの全能感を覚えました。Claude Codeは、その生産性の高さを実感させる演出が非常に上手く、まるでゲームのように作り込まれています。画面の隅にいる可愛いキャラクターやUIの表示スタイル、チームが立ち上がってタスクをチェックしていく様子など、すべてがその演出の一部です。
ちょっとここで実験をしてみましょう。各サンプルプロジェクトに対してサブエージェントを立ち上げ、Claude Codeの体験をより効率化するための改善点を監査させてみます。メールアドレスを隠すモードにしているはずですが、思い切りメールアドレスが表示されてしまっていますね。気を取り直してもう一度動かしてみます。UIの動きを見てください。処理が進むにつれてトークンの消費カウントが上昇し、細かな進捗アップデートが表示され、ドットが点滅しています。何かものすごいことが起きているように感じられます。そして、それぞれのサンプルに対して監査用のサブエージェントが次々と起動していきます。画面の下部でそれらのサブエージェントに切り替えて、個別の動きを確認することもできます。実にかっこよく、生産的に見えます。
これがまさに彼らの狙いなのです。Claude Codeは、圧倒的な生産性の高さをユーザーに「体感」させようとしています。もちろん、ツールの能力自体を高めようと努力しているのも事実ですが、率直に言って、Anthropicの思想は「より多くのトークンを投入することで、ツールをより賢く動かす」という力技に基づいています。チャットでも皆さんが言っているように、5分動かしただけで200ドルが吹き飛ぶ世界です。トークン、トークン、またトークンです。エラーを修正するために2時間格闘すれば、恐ろしい額になります。彼らは、見た目が非常に生産的で、実際に成果に繋がることもある手法のために、喜んで大量のトークンを消費する道を選んでいます。
彼らがClaude Codeに加えている改善の多くは、より多くのトークンを消費してクールな方法で課題を解決し、Twitterのデモで格好良く見せるための新しい方法の模索です。だからこそ、彼らはユーザーが独自のシステムやCI/CD環境にClaude Codeをプログラム的に組み込むことにあまり乗り気ではないのだと私は考えています。プログラムによる自動化は、あまりにも過剰なトークン消費を引き起こし、計算リソースのリスクになるからです。もし、先ほど私がやったようなサブエージェントによる自動チェックを、プルリクエストが作成されるたびにCIプロセスで実行するように設定したら、意図しないレベルでトークンが爆発的に消費されてしまいます。それはAnthropicが望む使い方ではありません。彼らがトークンを消費させたいのは、それが直接ユーザーの目に見え、自社モデルのプロモーションとして機能する状況においてのみです。彼らは、最高の生産性というユーザー体験と引き換えに、大量のトークンを消費させているのです。
OpenAIのCodexが持つエンジニアファーストの哲学
これとは対照的なのがOpenAIのCodexです。私はCodexの速度設定を中高速にしていますが、これでもClaude Codeより遥かに高速です。今回はあえて高速モードをオフにして、先ほどと全く同じプロンプトを入力してみます。サンプルプロジェクトごとにサブエージェントを立ち上げ、効率化の監査を行わせます。
画面を見ての通り、動いている要素はClaude Codeに比べて圧倒的に少ないです。タイマーが表示され、処理中のテキストがわずかにアニメーションしているだけで、他には何もありません。2つのサブプロセスは起動したようですが、その中身で何が起きているのかは視覚的には分かりません。非常にミニマルです。言い換えれば、依存性を生むようなギャンブル性のある演出は一切ありません。私たちはただ、静かに処理が終わるのを待つだけです。
両ツールが最近追加した機能を見比べると、この思想の違いがより鮮明になります。たとえば、Claude Codeが最近リリースした機能の一つに、「/radio」というコマンドがあります。これを実行すると、Claudeが選曲したローファイミュージックの24時間配信ストリームが開きます。これが素晴らしいか、あるいは余計な機能かといった議論はさておき、チームがどういう思想でツールを作っているかがよく表れている例だと思います。彼らは、コーディング中の気分を高める演出や、Twitterでバズるキラー機能を最優先で考えているのです。機能開発の社内レビューの段階で、「これがどうツイートされるか」をまず考えているのが伝わってきます。
一方で、OpenAIのデベロッパー向け公式Twitterを見てみましょう。あちらの投稿は、ほぼすべてがCodexの地味なアップデート報告です。いいねの数も8,200程度と、派手なバズとは無縁です。たとえば「Macがロックされた状態でも、Codexがバックグラウンドでコンピュータを操作してタスクを実行できるようになりました」というアップデートがありました。これは全く画面映えしない機能です。設定画面の「Computer Use」の項目にあるトグルスイッチをオンにするだけで、起動しても見た目には何も起きません。Macがロックされているときに動く機能なので、スクリーンショットを撮ることすら不可能です。しかし、実際の開発効率は劇的に向上します。
さらにタイムラインを追っていくと、外観設定に新しい差分マーカーが追加され、従来の「プラス・マイナス」表示が好みならそれを有効にできるようになり、そうでなければカラーコードのみのクリーンな表示にできる、といった細かなカイゼン項目が並んでいます。全く派手さはありません。いいねも900件程度ですが、非常に現実的で実用的な機能です。また、特定のショートカットキーを2回押すだけで、現在画面で見ている内容をキャプチャし、そのままCodexのコンテキストへ一発で流し込める機能も追加されました。私はスクリーンショットをコンテキストとして使うのが大好きなので、このような実用的な機能が標準で組み込まれているのは本当にありがたいです。Twitterでの見栄えを狙ったデモではなく、自分たちが実際にこれを使ってソフトウェアを開発する中で直面した、リアルな課題を解決するために作られているのがよく分かります。
「Computer Use」という機能そのものについても、当初は単に耳障りが良いだけの、あまり実用性のない機能だと思っていました。しかし、Claude Codeがモデルの進化によって初めて真価を発揮したのと同じように、Computer Useもモデルの知能が追いついたことで化けました。GPT-55の登場によってこの領域の処理が劇的に賢くなり、さらに私が別の部屋に設置している開発専用のMac Miniと組み合わせることで、CodexがComputer Useを介して自らコードの変更内容を実際に動かして検証する、というワークフローが驚くほど強力になりました。Codexが「タスクが完了した」と報告してきたときには、すでに実際の環境で動作確認まで終わっているため、コードが正しく動く確率が桁違いに高いのです。
ここから、両チームがどこでこのツールを使わせようとしているかという、もう一つの大きな思想的アプローチの違いが見えてきます。Anthropicのメンバーの多くはClaude CodeをCLIで使っていますが、OpenAIのメンバーの多くはCodexを専用のデスクトップアプリ経由で使っています。面白いことに、OpenAIにいる私の友人の多くは、非技術職のメンバー、つまりマーケティングやその他の部門の人たちです。彼らは全員Codexのアプリを使いこなしており、日々の業務のあらゆる面白いタスクを処理させています。このアプリのインターフェースは彼らの働き方に深く組み込まれており、派手さではなく、徹底的に優れた道具としての体験に最適化されています。
先ほどと同じデモをCodexのUIでもやってみましょう。プロジェクト内でサブエージェントを起動し、すべてのサンプルを監査させます。見ての通り、UI上では思考プロセスのインジケータが動いているだけで、非常に静かです。ここから検索を実行し、ファイルのチェックに入ります。過剰な演出でユーザーの目を引こうとするのではなく、ただ実直にタスクを処理しようとしています。
ここで、Claudeのアプリを最新版にアップデートしてみます。不具合が起きないようにするためですが、案の定、また再ログインを求められました。しかも、なぜかアプリ内ではなくブラウザのSafariが開いて認証を求められます。私は1Passwordを使っていますが、このアプリ内ブラウザのような挙動のせいでパスワードの自動入力が上手く機能せず、手動で長い情報を入力しなければなりません。パスキーでの認証も弾かれてしまいました。率直に言って、彼らがこのデスクトップアプリを社内で日常的に使っていないのは明らかです。もし使っていれば、こんなお粗末な体験をそのまま放置するはずがありません。なんとかログインできましたが、画面の右上には「ログインに失敗しました、キャンセルされた可能性があります」というエラーが表示されています。彼らがこのアプリの開発に力を入れていないのは間違いありません。ユーザーから要望があるから、とりあえず存在させるために作っただけ、というレベルに留まっています。
最新版にすれば問題が解決することを期待しましたが、やはりメールアドレスが再び露出してしまいました。画面にはチャット、コワーキング、コードのセクションが表示されていますが、まず気づくのは、CLI側で作成した過去のスレッドがこちらに全く同期されていないという点です。Codexであれば、すべての履歴がシームレスに同期されます。さらに、このUIから新しいプロジェクトを追加する方法すら極めて直感的ではありません。プロジェクトを選択しようとすると、なぜか自分が今作業していたディレクトリではなく、システムのルートディレクトリから選択させようとします。
その一方で、テキストが生成される際のアニメーションは無駄に豪華で、トークンの消費カウントは常に激しく上下に跳ね回っています。処理が完了しても、星型のアイコンが派手に点滅し続けるため、本当にタスクが終わったのかどうか判別しにくいです。プロジェクトを一つ認識させるだけでも、これほどのストレスがかかります。
私は、Claude Codeが目指しているような、ユーザーの射幸心を煽るスロットマシンのような派手な演出があまり好きではありません。それよりも、シンプルで、信頼できて、道具として完全に頼り切れるソリューションを好みます。
計算の効率性と環境構成に対する思想
これは単に見た目や使い心地だけの問題ではなく、モデルの進化の方向性を両チームがどう捉えているかという、非常に実用的な未来予測の話でもあります。Anthropicの賭けは、「モデルが賢くなれば、エージェント自身が他のサブエージェントのためのプロンプトを自ら生成し、複数のエージェントを並列で大量に立ち上げて、トークンの物量作戦で課題を解決できるようになる」という方向性です。基本方針として、トークンを多く投入して解決できる問題なら、迷わずそうするべきだという考え方です。Windows環境でのClaude Codeのメモリリーク問題を解決するために、大量のトークンを流し込んで、BunをRustで一から書き直させようとするような、凄まじいまでの物量主義です。
一方のOpenAIは、決してそのようなアプローチは取りません。彼らのベンチマーク結果を見れば、モデルの実行効率を極限まで高めようと必死になっているのが分かります。GPT-54 Miniはトークンを多く消費する傾向がありましたが、Sonnet 46もそれに近い消費量でした。GPT-54のハイエンドモデルやOpus 47も同様でしたが、最新のGPT-55にいたっては、従来の半分のトークン消費量でそれ以上の圧倒的なスコアを叩き出しています。OpenAIは、解答の正確性を一切犠牲にすることなく、いかにトークン消費を効率化できるかという点に技術を注ぎ込んでいます。
そのため、15個ものサブエージェントを立ち上げてすべてのコードをトリプルチェックさせるような非効率な方法ではなく、「Computer Use」のような機能を使って、生成したコードが実際に正しく機能したかどうかを少ないトークンで自己検証させるアプローチを選んだのです。モデルがコードを変更し、その結果を自ら画面で見て成功か失敗かを判断できれば、消費する計算リソースは遥かに少なくて済みます。
ただし、これを実現するには検証を行うための環境が正しくセットアップされている必要があります。ここに両者の大きな分岐点があります。Anthropicは、ローカルマシンでの実行が難しければ、そのスレッドをそのまま丸ごとクラウド環境へ転送して処理を引き継がせるというシステムを非常に熱心に構築しました。しかし、現実問題として、Claude Codeのクラウド環境を自分のプロジェクトに合わせて正しく動作させるのは至難の業です。私も試みましたが途中で諦めました。Anthropicの友人に相談したところ、「エージェントに実際にコードを実行させる必要はない。とにかくトークンを大量に投入すれば、実行しなくても大抵は正しいコードを書いてくれるから大丈夫だ」というアドバイスをもらいました。しかし、それでは実際に動かなかったときに結局開発者が苦労することになります。私は自分のローカルマシンのリソースを奪われたくない大きなタスクこそクラウドで動かしたいので、環境構築の難しさのせいでエージェントが結果を正しく検証できないというのは、ツールとして大きな不満です。
OpenAIもかつてはCodexで優れたクラウド環境を構築しようと注力していましたが、今ではその優先度は大幅に下がっているように見えます。最も分かりやすい例が、ChatGPTのモバイルアプリ内にあるCodexのメニューです。クラウド環境で実行するオプションは、メニューの深い階層に完全に隠されてしまいました。彼らは、世の中の無数の複雑なプロジェクトをクラウド上で完璧に再現して実行させることが、どれほど困難であるかを身を染みて理解したのです。自社での開発経験を通じて、社内の全メンバーの多種多様なプロジェクトをCodexのクラウド環境で正しく動かすことに限界を感じた結果、彼らは「すでにユーザーのローカルマシン上で完璧に動いている環境があるのだから、スマホからそのローカル環境をリモート制御できるようにすればいい」という現実的な最適解に行き着きました。
Anthropicの賭けは、「モデルが十分に賢くなれば、コードを実際に実行してテストする必要すらなくなり、最初から完璧なコードを出力できるようになる」というものです。対するOpenAIの賭けは、「環境構築の自動化はあまりにも泥臭く複雑であるため、開発者がすでに手元に用意しているローカルの構成をそのまま活用するのが最も確実である」というものです。
第3の選択肢：Cursorの真の強み
ここで第3の選択肢であるCursorについても触れなければなりません。クラウド領域における彼らのアプローチは極めてユニークで強力です。Cursorが一時期の圧倒的な首位から、あっという間にシェアを落としたように見えるのは驚きですが、これは多くのユーザーが「Cursorの本当の強みがどこにあるか」を理解していないからだと私は考えています。
皆さんがお使いのCursorとは異なり、私の画面にあるCursorはIDEではなくブラウザ上で動作しています。Cursorのクラウド機能の完成度は、Devonのような一部の尖った製品を除けば、競合他社を遥かに引き離して独走状態にあります。Cursorのクラウドエージェントは、単にコードを実行するための貧弱なヘッドレスのLinuxサンドボックスではありません。彼らのサンドボックスは、完全にグラフィカルなデスクトップUI（GUI）を備えたLinuxインスタンスをクラウド上に丸ごと立ち上げます。これにより、エージェントは私たちが本物のコンピュータを使うのと全く同じようにアプリケーションをフルで起動し、Computer Useを駆使してブラウザ画面を見ながら変更内容のテストを行うことができます。
たとえば、T3 Codeのコードベースをクラウド上で実行し、Electronシェルで動かすのと全く同じブラウザ環境を内部で立ち上げ、自ら画面を操作して表示崩れや機能のチェックを行いながらコードを修正していく、といった芸当を平気でこなします。
「でも、手元に本物のPCがあるなら、わざわざクラウドで動かす意味はあるのか」と思われるかもしれません。しかし、外出先からスマートフォンで急な対応をしなければならないとき、わざわざ自宅のPCにリモートデスクトップで接続する設定をしていなくても、スマホからこの強力なクラウドエージェントを起動して任せられる利便性は計り知れません。また、Computer Useを必要とする別々の重いタスクを2つ同時に並列で進めたい場合、ローカルマシンが1台だけでは画面の操作が競合してしまい、同時に動かすことはできません。PCが起動していなかったり、社内ネットワークに接続されていなかったりすれば、ローカルのアプローチは完全に手詰まりになります。
何より、実務において魔法のような瞬間があります。Slackでチームのメンバーがプロダクトの不具合を報告したとき、そのスレッドでCursorのボットをメンションし、「このバグを修正するエージェントを立ち上げておいて」と一言伝えるだけで、数分後にはバグが修正され、実際に正常に動作している様子を録画した動画付きでエージェントがスレッドに返信してくるのです。このレベルのエンドツーエンドの自動化と確実性は、Claude CodeやCodexの現行機能では到底真似のできない、圧倒的なアドバンテージです。
それぞれのツールの賭け方を整理すると、Codexは「現在のエージェント開発のリアルな延長線上に何があるか、いかに現在の成功率を高めるか」に賭けています。Anthropicは「数ヶ月後のモデルの急激な進化」に賭けており、社内で使っている超高性能な未公開モデルであるMythosの知能を前提とした設計をしています。そしてCursorは、「将来的に開発者はローカルマシンでエージェントを動かすことすらなくなり、任意のインターフェースからエージェントを起動し、その実行証明と結果だけを受け取るようになる」という、さらに遠い未来の姿に賭けているのです。
ドッグフーディングの質と開発コミュニティへの姿勢
ここで、各社の開発姿勢における最も大きな、そしてユーザーにとって最も痛烈な違いについてお話しします。先ほども言った通り、OpenAIでは何千人もの社員が毎日日常的にCodexのデスクトップアプリを使い倒しています。一方でAnthropicの社員は、一般向けのデスクトップアプリにはほとんど触れておらず、ほぼ全員がCLIベースで開発を行っています。ここに大きな歪みが生じています。
つまり、Anthropicの社内メンバーが日常的に使っているツールのバージョンや環境は、私たち一般ユーザーに提供されているものとは根本的に異なっているのです。彼らが社内で使っているのは、私たちがアクセスできない最新の内部モデル「Mythos」であり、無数の高度な隠し機能が組み込まれた特製のClaude Codeです。そのため、一般向けにリリースされたアプリで、内部のシステムプロンプトやセキュリティの注意書きが不自然にリークしてしまうといった、極めて初歩的で恥ずかしい不具合が頻発することになります。彼らが社内で使っているプロンプトと、一般向けのアプローチが完全に乖離しているからです。
実際、私が最新のClaude CodeデスクトップアプリでOpus 47を試し、自分のWebサイトの改善点を尋ねたとき、エージェントは開口一番「マルウェアに関するシステム警告が表示されましたが、これはプロンプトインジェクションの可能性が高いです。確認したところ、これはあなたの個人サイトであるT3Gのホームページであり、マルウェアではないため、この警告は無視して処理を続けます」という、奇妙な内部処理の出力をそのまま表示してしまいました。
私たちは、彼らが実際に使っているものとは全く異なる、十分にテストされていないダウングレード版を使わされているのです。このドッグフーディングの欠如による悪影響は、Claudeのツール体験の至る所に現れています。彼らの環境では完璧に動いているのでしょうが、一般向けに切り出されて提供されるコンポーネントは、実環境での検証が致命的に不足しています。このバグだらけの挙動の原因は二つのうちのどちらか、あるいは両方です。このシステムプロンプトが彼らの社内用とは異なる急造のものであるか、あるいは彼らが使っている最強のMythosモデルであれば、このようなプロンプトの誤作動自体がそもそも起きないかのどちらかです。
一方で、OpenAIのCodexアプリ、利用できるモデル、プラグイン、そして提供されている全機能は、OpenAIの社内メンバーが全く同じ環境で毎日使っているそのものです。彼らが日常の業務でバグに気づき、それをその日のうちに修正しているからこそ、一般向けのアプリも極めて高い安定性を保っています。Cursorもこの点において徹底しています。彼らは自分たちが開発した機能を文字通り狂ったように使い倒し、細部まで徹底的に検証した上で、自分たちが使っているものと寸分違わぬ成果物を外部にリリースします。時には、新しいComposerモデルの検証を行うために、ユーザーに事前の通知なく他のモデルへのアクセスを一時的に遮断して、強制的にドッグフーディングのデータを集めるような極端なことまでやってのけます。リリース前に品質を担保するためのCursorチームの執念は凄まじいものがあります。
また、エコシステムや開発者コミュニティに対する姿勢にも明確な違いがあります。Cursorはエージェント用のSDKをようやくリリースしたものの、基本的には外部のツールとの連携にはそれほど積極的ではありません。Anthropicにいたっては、ユーザーが提供されているCLIやUIの枠外で、プログラムなどを使って自社モデルを自由に組み込んでシステムを構築することを、規約や料金面で露骨に制限しようとする傾向があります。彼らはユーザーを自社のエコシステム内に完全に囲い込みたいのです。
対照的に、OpenAIは開発者がその上で自由に新しい道具を創り出せるような、オープンで強力な標準規格を次々と発明してコミュニティに提供してくれます。私が Julius と共に開発した独自のAIコーディングアプリ「T3 Code」も、OpenAIがオープンソースとして公開してくれたCodexのCLI、そしてその中核であるCodex App Serverが存在しなければ、この世に誕生していませんでした。私たちは、OpenAIの社内チームがアプリを構築しているのと同じ強力な基盤をそのまま使って開発することができたのです。Codexの社員たちはTwitter上でも非常にオープンで、「もしCodexを独自の特殊な用途で使いたいなら、エージェントにこのリポジトリのこのフォルダを読み込ませれば、勝手に構造を理解して動くようになるよ」といった実践的なハックを気軽にシェアしてくれます。OpenAIは、開発者が自社の技術を使って自由に未来をハックし、新しいものを生み出すことを心から推奨しているのです。
モデルの進化スピードと未来への提言
最後に、最も重要なモデルそのものの進化について触れておきます。AnthropicがClaude Codeにローファイ音楽の配信や派手な演出など、手数の多い周辺機能を次々と追加せざるを得ない本当の理由は、一般に公開されている彼らの主力モデルの基礎能力が、昨年末のリリース以来、実質的に停滞しているからです。新しく出た46や47といったバージョンは、実際の開発現場での体感としては、進化というよりもむしろいくつかの領域で退化しているとすら感じます。
一方でCodexがこれほど急速に使いやすくなっているのは、背後にあるGPTモデルの知能自体が、52、53、54、そして55へと、凄まじい角度で進化を続けているからです。この期間にOpusが45から47へと微小な変化に留まり、むしろ扱いづらくなっていったのに対し、OpenAIのモデルは3世代にわたって圧倒的なパラダイムシフトを遂げました。仮に、1年前の古いバージョンのCodex CLIをそのまま使ったとしても、モデルを最新のGPT-55に切り替えるだけで、その知能の高さのおかげで魔法のように快適に動作します。逆に、昨年末の古いClaude Codeのシステムに現在のOpus 47を流し込めば、ツールのバグとモデルの融通の利かなさが衝突して、まともにタスクをこなせないでしょう。Anthropicはモデルの停滞をカバーするために、ターミナル層での目新しい機能開発を急ぎ、Twitterでのプロモーションによって、あたかも業界をリードし続けているかのような印象を維持し続けなければならないのです。そして、そのマーケティング戦略は今のところ見事に成功しています。
世間の動画の多くは、同じプロンプトを3つのツールに投げて出力のコードの綺麗さを比べるだけのような、表面的な比較ばかりです。しかし私が本当に重視しているのは、そのツールを作っている開発チームがどこを目指しているのか、何の課題を解決しようとしているのか、そして今日動いているこの道具が、明日も同じように信頼できる状態でそこにあり続けてくれるか、という点です。
もし皆さんが、今でもIDEのサイドバーや標準的なCopilotの補完機能だけでコードを書いているなら、ぜひ今回紹介したツールのデスクトップアプリや高度な環境を試してみてください。AIと共にコードを書くという体験の次元が、完全に変わっていることに気づくはずです。
最後に、これら3つのツールの選び方を極めてシンプルにまとめます。
もしあなたが、開発のモチベーションが維持できずに悩んでいたり、コーディングに対してまだ強い苦手意識があり、とにかく「作業が進んでいて楽しい、自分は今ものすごく生産的だ」という高揚感を味わいながら進めたいなら、ゲーム感覚で開発を盛り上げてくれるClaude Codeが最高の相棒になります。
もしあなたが、長年現場でコードを書いてきた経験豊富なエンジニアであり、AIツールの過剰な演出や無駄なトークン消費の力技に懐疑的で、自分の洗練されたローカルのワークフローを一切邪魔されることなく、ただ実直に、確実にタスクを片付けてくれる道具を求めているなら、Codexが圧倒的な正解です。
そして、もしあなたが、自分一人のローカルマシンのリソースの制約を超えて、強力なクラウド環境の恩恵をフルに受けたい、あるいはSlackなどを通じて技術職ではないメンバーも含めたチーム全体が一丸となって、エージェントに自律的な課題解決を任せる先進的な開発体制を構築したいなら、Cursorのクラウドソリューション以外に選択肢はありません。
最終的には、すべてのツールを実際に自分の環境で動かしてみて、あなた自身の開発のリズムや手の動きに最も自然に馴染むものを選択するのが一番です。ツールによってあなた自身の開発のフローが洗練されていく感覚を、ぜひ楽しんでください。
コメント