CodexとClaude Codeの比較。両方契約した結論は「どちらでもいい」、差が出るのは使い込んだ先

この2つを比べる話は、たいていベンチマークの点数と料金表に行き着きます。私はどちらも契約して日々の仕事を分けて渡していますが、正直なところ、どちらを選んでも困らないというのが実感です。ただし、コードを書ける人間ではありません。書けるのは、記事を作る、数字を集める、繰り返しの作業を小さな道具にする、といった普通の業務を、どちらに渡したら楽だったかという話のほうです。両者の共通点と違いを整理したうえで、私が手元でどう線を引いたか、それでも片方に寄っている理由まで順に書いていきます。

CodexとClaude Codeの違いと、比較の前提

まず前提を揃えます。CodexはOpenAIが出しているコーディングエージェント、Claude CodeはAnthropicが出しているコーディングエージェントです。提供元が違うだけで、立っている場所はほぼ同じだと思ってもらって差し支えありません。

コーディングエージェントという言葉があまり親切ではないので、先に説明します。チャットのAIは、質問すると答えを返して終わりです。コーディングエージェントのほうは、指示を受けたあと自分でファイルを開いて読み、書き換え、コマンドを走らせて、うまく動かなければ直してもう一度試す、というところまで進みます。人間が毎回コピーして貼り戻す手間がなくなる道具、と考えると近いかもしれません。

どちらもターミナルから起動して使えます。ターミナルというのは、黒い画面に文字で命令を打ち込むあの窓のことで、そこで動くタイプのソフトをCLIと呼びます。Codex CLIという呼び方を見かけるのは、そういう理由です。とはいえ、いまはどちらもエディタの拡張機能として使えますし、手元のパソコンではなくクラウド側で動かす形も用意されています。黒い画面を触りたくない人にも、入口はいくつかあります。

骨格は表にまとめました。2026年8月時点で私が見ている範囲の話で、料金もモデルの名前もかなりの速さで移り変わります。契約する前に、それぞれの公式ページで最新を確認してください。

並べてみると、違いらしい違いはファイル名くらいしか残りません。実際そのとおりで、どちらも自分の道具を繋げますし、どちらも永続的な指示を読ませられます。この表を見て決められることは、たぶんほとんどないでしょう。

あわせて先に断っておくと、周辺の仕組みは両方とも増え続けていて、私は片方しか追いきれていません。手順に名前を付けて呼び出す、役割ごとに担当を分ける、決まったタイミングで処理を差し込む。この手の作り込みは、私が使っているClaude Code側の言い方でしか説明できません。Codex側にも似た方向の仕組みが揃ってきていますが、私が日常的に触っていないので、比べて語れる立場にありません。拡張の厚みを理由に選ぼうとしているなら、この記事ではなく両社の公式ドキュメントを見てください。

モデルとコーディングエージェントの混同

比較記事を読んでいて分かりにくくなるのは、モデルの話と道具の話が混ざるところです。GPTやClaudeという名前は、モデルの名前です。モデルは頭脳にあたる部分で、文章を読んで考えて、答えを作ります。対してCodexやClaude Codeは、その頭脳に手足を付けて、パソコンの中で作業できるようにした道具のほうを指します。

頭脳と道具が別である以上、「ChatGPTとClaudeはどちらが賢いか」と「CodexとClaude Codeはどちらが使いやすいか」は別の質問になります。前者はモデルの話、後者は道具の話です。私も最初は、賢いモデルを選べば作業も速くなるはずだと考えていました。実際に手を動かしてみると、体感を左右していたのは頭脳の点数よりも、道具としての段取りのほうでした。読ませる範囲をどう指定できるか、途中で止めて方向を変えられるか、やり直しがどれくらい楽か。細かい話に見えますが、1日に何度も繰り返す部分なので、まとまった差になって返ってきます。

もうひとつ紛らわしいのが名前の重なりです。Codexという呼び名は、OpenAIが以前に出していたコード生成モデルにも使われていました。検索して出てくる情報には、古いモデルの話といまのエージェントの話が混ざっています。公開日を見ながら読むと迷いにくいでしょう。

両方に払っている私の分け方

私の仕事はコードを書くことではありません。文章を書く、数字を集めて眺める、毎週やっている面倒な手順を小さな道具にして自分の手から外す。だいたいこの3つです。だから比較の軸も、「どちらのコードが綺麗か」ではなく「自分の1週間の作業をどちらに渡すと軽くなるか」になります。

いまの分担を正直に書くと、次のようになっています。記事の下調べと執筆、長い資料を読ませて要点をまとめさせる作業はClaude Codeに渡しています。表計算に自動処理を足すための小さなプログラムを書いてもらうのも同じ側です。手元のフォルダを整理したり、散らばったファイルを一覧にしたりする作業も、まとめてClaude Codeにお願いしています。画像を作る仕事はCodex側に置いたままです。線を引いているのは性能の優劣ではなく、どちらに材料が置いてあるかのほうです。

分担といっても、絶対のものではありません。同じ作業を反対側に渡しても、たぶん似たようなものが返ってきます。実際、単発の調べものはそのときに空いているほうへ投げていて、返ってきた答えに落差を感じたことはあまりありません。

渡し先に迷ったときは、頭の中で3つ確認しています。実際には数秒で済む判断なので、慣れると考えなくてもどちらかに手が伸びます。

逆に言えば、3つのどれにも当てはまらない単発の調べものは、どちらでも構いません。空いているほうに投げています。同じ質問を両方に投げて、返ってきた答えを見比べることもあります。仕事の答え合わせを2人に頼めるのは、両方契約している人だけができる贅沢な使い方かもしれません。

絵まわりはCodex側に置いている

私が唯一、はっきり側を決めているのが画像です。記事のアイキャッチや図版を作るときは、Codex側からGPT Image 2という画像生成のモデルを呼び出しています。文章で「こういう絵が欲しい」と伝えると、画像が手元のフォルダに保存されて出てきます。

そちら側にしている理由の半分は費用です。契約しているサブスクの範囲でそのまま回せるので、画像1枚ごとに追加のお金がかからない。画像生成のサービスを別に契約すると、月の枠を気にしながら使うことになります。私は記事を出すたびに何枚か作り直すので、枚数を気にせず試せることのほうが価値が高いと感じました。

残りの半分は、絵に近い仕事全般の手応えです。画面のスクリーンショットを見せて「この画面のどこを押せばいいか」を判断させるような、目で見て操作させる使い方があります。私の感覚では、GPT側のほうが画像の中身を素直に読み取ってくれる場面が多い印象でした。頭脳が同じGPT系である以上、絵を作るのも絵を読むのも地続きなのかもしれません。あくまで印象の話で、測ったわけではありません。

ただし、その印象もだいぶ古くなってきました。Claude側もOpus 5やFableの世代に入ってから、画面を見せた作業で困った記憶がほとんどありません。以前は明確に感じた差が、いまは私の用途では埋まっているように見えます。AI画像生成のコツのほうに書いたようなプロンプトの作法さえ押さえていれば、生成そのものも出す側で大きく困ることはなくなってきました。よければあわせて読んでみてください。

では、なぜいまも画像だけCodexに置いたままなのか。追加費用なしで回せる経路がすでに手元にできあがっていて、それを組み替える理由が見つからないからです。勝ち負けというより、動いているものを動いたままにしている、というだけの話です。

残りをClaude Codeに寄せているのは、そこで組んでしまったから

ではなぜ残りをClaude Codeに渡しているのか。格好をつけずに書きます。客観的に性能が上だから選んでいるのではなく、自分の仕事のほうがClaude Codeに寄ってしまったから使い続けている、というのが実感に近いです。

理由は積み上がったものにあります。私は仕事のルールをテキストファイルにして手元に置いていて、フォルダごとに「ここではこう振る舞ってほしい」という決まりごとを書いています。よく使う手順は名前を付けて呼び出せるようにしてありますし、過去に作らせた道具もそのまま並んでいます。作業を頼むときに前置きが要らないのは、その積み重ねがあるからです。

移せないわけではありません。ルールを書いたファイルはただのテキストですし、繋いでいる道具も共通の仕組みに乗っています。それでも移す気にならないのは、量が増えてしまったからです。フォルダごとの決まりごと、名前を付けた手順、自動で走らせている処理。全部を移して、全部が同じように動くか点検する時間を考えると、いま困っていないものを動かす理由が出てきません。いまさら乗り換えないというだけで、乗り換えられないわけではない、という距離感です。

もうひとつは、調べながら書く作業との相性です。記事を1本作るとき、検索して、上位のページを読んで、構成を決めて、書いて、読み返して直す、という工程を続けて走らせます。途中の材料が多いので、抱えたまま最後まで進むと精度が落ちます。落ちる前に、調べた内容をいったんファイルへ書き出させて、次の工程は書き出したファイルだけを読ませる。段取りとしては地味ですが、ファイルを介して仕事を引き継がせるやり方が手に馴染みました。

慣れと好み、と言ってしまえばそれまでです。ただ、道具を選ぶ理由の何割かは本当に慣れだと思っています。ベンチマークで数ポイント上のほうへ毎回引っ越していたら、積み上げたものが毎回ゼロに戻ります。

裏を返すと、まだ何も積んでいない人にとっては、この理由はまったく参考になりません。手ぶらの状態で選ぶなら、どちらを選んでも同じところに立てます。私が動けないのは、荷物を片側に置いたからです。

生成されるコードの癖と、大きなコードベースへの向き合い方

コードの癖については、よく言われる傾向があります。Codexは頼まれた箇所を最小限の変更で通そうとして、Claude Codeは周辺まで含めて教科書的に厚く書く、という説明を各所で見かけます。私はコードを読んで良し悪しを判定できないので、どちらが正しいと断定はできません。

ただ、受け取る側として困った経験なら両方向にあります。頼んでいない箇所まで書き換えられると、どこが元のままなのか分からなくなります。逆に最小限すぎると、動くには動くけれど次に手を入れるときに困ります。だから私は、コードを書かせるときに「触ってよいファイル」と「触らないでほしいファイル」を先に伝えるようにしました。癖の違いを比べるより、こちらが枠をはめるほうが早かったです。

大きなコードベース、つまりファイルがたくさん入った大きなフォルダを扱うときの話も同じ方向でした。一度に全部読ませると、どちらも精度が落ちます。AIには一度に抱えられる文章量の上限があって、そこをコンテキストと呼びます。上限まで詰め込むと、前のほうに言ったことが薄れていきます。人間がマルチタスクで質を落とすのとよく似た挙動だと感じていて、私はどちらのツールでも「読ませる範囲を先に絞る」を最初にやります。

大きなプログラムを整理し直す、いわゆるリファクタリングのような作業でも、一気に任せるより対象を区切って何回かに分けたほうが結果が安定しました。長い文脈をどこまで理解できるかを比べるより、どこまで抱えさせないかを決めるほうが、実務では手応えがありました。

料金の比較と、使用量の上限に当たったとき

料金は比較の主戦場ですが、そもそもプランの組み立てが根本的に違います。Codexは、ChatGPTの有料プランに含まれる形で使えます。Claude Codeも、Claudeの有料プランに含まれる形で使えます。つまりどちらも「そのAIのサブスクに入っていれば追加契約なしで触れる」構造で、上位プランほど使える量が増えます。加えて、どちらもAPIの従量課金という道が別に用意されています。トークンという単位で読んだ量と書いた量を数えて課金する方式で、使った分だけ払う代わりに、使いすぎると青天井になります。年払いにすると割引が付くことがあるので、続ける気があるなら確認する価値はあります。

金額については、ドル建てで見る癖をつけたほうがいいです。円で覚えると為替でずれますし、表示価格と実際のカード請求も一致しません。消費税と、カード会社の為替手数料が乗るからです。私が払っているClaude側の上位プランは月100ドルで、2026年8月時点のカード明細では1万8千円ほどになっていました。同じ時期の相場で単純に換算すると1万6千円弱なので、2千円くらい上に振れている計算です。1本ならまだしも2本契約するなら、この上振れも見込んで予算を組んだほうが安全でしょう。内訳はClaude Codeの料金と実際の請求額に書いたので、気になる方はそちらもどうぞ。

では結局どちらが安いのか。私の見ている範囲では、入口の価格帯も、その上に用意されている上位プランの刻み方も、両社でかなり近い形になっています。金額そのもので差がつくというより、自分がどれくらい使うかで払う額が決まる、という理解のほうが実態に近いです。だから「どちらが安いか」を先に決めるより、まず片方で1ヶ月まわしてみて、上限に何回当たったかを数えるほうが早く答えが出ます。当たらなければ下のプランのままでいいですし、毎週当たるなら上のプランか、もう1本を足すかの検討に入ります。

次に上限の話です。どちらのツールにも使用量の制限があって、数時間ごとの枠と、週単位の枠が組み合わさっている形が一般的です。枠を使い切ると、しばらく待つか、下位のモデルに切り替えるか、従量課金へ逃がすか、という選択になります。長い作業を続けて走らせると、思ったより早く当たります。私の場合、記事をまとめて仕込む日や、道具を作り直している日は当たりやすい印象があります。

両方契約していると、片方の枠が尽きたときにもう片方が空いている、という状態になります。実際に助かったことは何度もあります。ただ、それを主な理由にして2本払うのはおすすめしません。両方払う価値が出るのは、片方でしかできない仕事が自分の中にあるときだけでしょう。私の場合はそれが画像でした。保険のためだけに2本払うと、たぶん1ヶ月で惜しくなってくると思います。

永続的な指示の二重管理（CLAUDE.mdとAGENTS.md）

併用でいちばん面倒だったのが、実はここでした。両方に同じルールを覚えさせる手間です。

永続的な指示というのは、毎回説明しなくてもAIが守ってくれるルールを書いたテキストファイルのことです。フォルダの中に置いておくと、その場所で作業するときに自動で読まれます。私は「このフォルダでは日本語で答える」「勝手に削除しない」「消したいものは別のフォルダへ移して報告する」といった決まりごとを書いています。書いておくと、毎朝同じ注意を繰り返さずに済みます。

厄介なのは、読みに行くファイル名がツールごとに違うところです。Claude CodeはCLAUDE.md、CodexはAGENTS.mdを見ます。素直に両方置くと、ルールを1つ直すたびに2つのファイルを直すことになります。しばらくすると必ず片方が古くなって、ツールによって言うことが違う、という状態になりました。

私が採った解決は単純です。AGENTS.mdをCLAUDE.mdへのシンボリックリンクにして、中身を1つにしました。シンボリックリンクというのは、実体は1つのファイルなのに別名でも辿り着けるようにする仕組みで、Macでもコマンド1行で作れます。名前は2つでも、中身は1つです。ルールを直す場所が1箇所になったので、それ以降は食い違いが起きていません。

書き分けが必要になったら、そのときリンクを外して別ファイルにすれば済みます。最初から二重管理するより、揃えておいて必要になったら割るほうが楽だと感じています。なお、このファイルには仕事の内情が書かれがちなので、公開する場所へ置かないよう気をつけてください。接続情報やパスワードの類は、そもそもここに書かないほうがいいです。

拡張のしかた（MCP・スキル・サブエージェント・Hooks）

拡張まわりは「どちらが厚いか」ではなく、「どちらの上で組んでいるかで、使う部品の名前が変わる」と考えたほうが実態に近いと思います。

共通の土台はMCPです。MCPは、AIに自分の道具を持たせるための共通の決まりごとで、繋ぐとAIがそのサービスを直接触れるようになります。検索キーワードの数を調べる道具を繋いでおけば、「この語の検索数を出して」と頼むだけで調べに行って表にして返してきます。人間が画面を開いてコピーする係から降りられます。両方ともMCPに対応しているので、繋いだ道具は使い回せます。

私は既製のMCPをいくつか繋いだうえで、どうしても足りないものが1つ残ったので自作しました。自作といっても私が書いたわけではなく、日本語で「こういうことがしたい」と伝えて動くまで付き合ってもらっただけです。作った経緯はMCPサーバーを自作した話に詳しく書いたので、興味があれば覗いてみてください。

そこから先は、それぞれの流儀になります。私が使っているClaude Code側だと、決まった手順を書いて名前で呼び出せるスキル、役割ごとに担当を分けて動かすサブエージェント、決まったタイミングで自動的に処理を差し込むHooks、自分で作るカスタムコマンドがあります。たとえば「作業が終わったら必ず記録を残す」というルールは、文章でお願いするだけだと忘れられることがありますが、Hooksとして仕込めば毎回動きます。頼み忘れが減るという意味で、地味ですが実務では大きい違いでした。

同じことをCodex側でどう組むのが今の作法なのかは、私には書けません。触っていないからです。ただ、方向としては似たものが用意されてきているはずで、「片方にしかない」と言い切れる時期はもう過ぎていると思っています。

役割を分ける話も同じ方向です。1つのセッションに全部やらせると、抱える量が増えて質が落ちます。調査する係、書く係、点検する係と分けておくと、それぞれが自分の担当ぶんだけを抱えて動きます。チーム開発をしている人にとっては当たり前の分け方かもしれませんが、1人で仕事をしている側にとっても効果は同じでした。

ただし、拡張を増やせば増やすほど良くなるわけでもありません。繋ぎすぎると起動が重くなりますし、使わない道具の説明までAIが抱えることになります。私も一度は繋げるだけ繋いでみたのですが、起動が目に見えて遅くなったので、使っていないものを外して数を戻しました。いまはときどき棚卸しする形に落ち着いています。

ひとつ付け加えると、ここに書いたのは2026年8月時点の、しかも片側からの眺めです。どちらも更新の速い道具なので、半年後には呼び名も作法も変わっているでしょう。契約の直前に、それぞれの公式ドキュメントを見に行くことをおすすめします。

ローカルで動かすか、クラウドに投げるか

動かす場所も比較の論点によく挙がります。手元のパソコンで動かす形と、クラウド側に作業を投げて非同期で任せる形の2つがあり、いまはどちらのツールにも両方の入口があります。

私はほぼ手元で動かしています。理由は単純で、扱うファイルが手元にあるからです。記事の原稿も、集計した表も、作った道具も自分のパソコンの中にあるので、そこで動くほうが説明が短くて済みます。外に持ち出さなくていい、という安心感もあります。

一方で、クラウドに投げる形の良さも分かります。時間のかかる作業を投げて、パソコンを閉じて出かけられます。戻ってきたら結果ができている、という進め方は、待ち時間の使い方として合理的です。手元の作業を止めずに別の仕事を並行させられるのも利点でしょう。ローカルとクラウドのどちらが優れているかというより、扱うファイルがどこにあるかで決まる話だと思っています。

機密のコードや社内の情報をどう扱うか

仕事で使うなら避けて通れない論点です。会社のコードや、外に出せない情報を渡してよいのか。

大前提として、入力したデータを学習に使うかどうかは、契約しているプランや設定によって扱いが変わります。個人向けのプランと法人向けのプランで条件が違うこともあります。曖昧なまま業務のデータを流すのは危ないので、必ず利用規約とプライバシーの説明を読んでから判断してください。会社で使うなら、情報を扱う部署に一度確認したほうが安全です。

私自身は、外に出したくないデータを扱う作業は、手元で完結する処理に限るようにしています。音声を文字にする作業のように、外のサービスへ送らずにパソコンの中だけで終わらせられるものは、そちらでやります。そして道具を作るとき、外に触る部分には必ず枠をはめておきます。

もうひとつ、どちらのツールにも動かし方のモードがあります。ファイルを書き換えたりコマンドを走らせたりする直前に確認を挟む形と、ある程度まで自分で進ませる形です。慣れてくると確認が面倒になって自動側へ寄せたくなりますが、外に出ていく操作や、消す操作を含む作業では確認を挟む形に戻したほうが安全でしょう。呼び方も既定の挙動もツールごとに違いますし、更新で変わることもあるので、最初に使うときは手元の画面で今どちらになっているかを確かめておいてください。

ベンチマークの数字と、実際の使い勝手

比較記事の多くは、コーディング能力を測るベンチマークの点数を並べています。参考にはなりますが、点数の差がそのまま日々の使い勝手になるかというと、私の実感ではそこまで一致しません。

理由は2つあります。ひとつは更新の速さです。数ヶ月で順位が入れ替わるので、記事を読んだ時点の数字がすでに古いことがよくあります。もうひとつは、測っている内容が私の仕事と違うことです。難しいプログラムの課題を解けるかどうかと、私が普段お願いしている「表を作り直して」「この資料の要点を出して」という作業の相性は、あまり関係がありません。

非エンジニアが体感で差を感じるのは、もっと手前の部分でした。日本語の指示がどれくらい素直に通るか。途中で止めて方向を変えられるか。間違えたときに巻き戻しやすいか。長い作業を続けたときに息切れしないか。点数表を眺めるより、自分が今週やった作業を3つ書き出して、両方に同じことを頼んでみるほうが早いです。1時間もあれば、自分の仕事との相性はだいたい分かります。

用途別の使い分け早見表

私がいま実際にどう振り分けているかを表にしました。あくまで私の仕事の話なので、そのまま真似するというより、自分の作業に置き換える材料として見てもらえたらと思います。

表を作ってみて改めて思ったのは、理由の列に性能の話がほとんど出てこないことでした。書いてあるのは「そちらに置いてあるから」「そちらで組んであるから」ばかりです。裏返せば、置き場所がまだ決まっていない人には、この表はそのまま使えません。自分の作業を書き出して、材料がどちらに寄っているかを見たほうが早いでしょう。

非エンジニアが最初に試す順番

初めて触る人に、いきなり両方を勧めるつもりはありません。覚えることが倍になるだけです。順番としては、普段使っているチャットのある側から入るのが楽だと思います。ChatGPTを日常的に使っているならCodex、Claudeを使っているならClaude Code。契約が1本で済みますし、答え方の癖に慣れているぶん、指示も出しやすくなります。

最初の題材は、今週やった繰り返し作業を1つだけ選んでください。毎週コピーして貼り直している集計、毎回同じ形に整えている資料、決まった時刻に確認しているデータ。地味なもののほうが向いています。動かない期間があっても困らない作業から始めると、失敗が怖くなくなります。

もう片方を足すかどうかは、そのあとで構いません。判断の基準は「片方では出せないものが出てきたか」の一点です。私の場合は画像がそれでした。もし出てこなければ、1本のままで十分です。ツールを増やすこと自体に価値があるわけではありません。

よくある質問

Q. Claude CodeからCodexを呼び出せますか？
A. 呼び出せます。Codex側はターミナルから起動できるので、Claude Codeに「このコマンドを実行して」と伝えれば、その場でCodexを動かせます。私が画像を作るときも、Claude Code側に頼み、Claude CodeがCodexを呼んで画像を作らせる、という流れになっています。片方をもう片方の道具として使う形なので、画面を行き来する必要がありません。ただし、呼ばれた側の使用量も当然消費されます。両方の枠が減っていく点だけ意識しておいてください。

Q. CodexアプリやIDE拡張と、Codex CLIは何が違いますか？
A. できることの中身より、どこから触るかの違いです。CLIはターミナルから文字で操作する形、IDE拡張は普段使っているエディタの中で操作する形、ブラウザやアプリから使う形はクラウド側で動かす形になります。手元のファイルを触らせたいならCLIかエディタ拡張、時間のかかる作業を投げて放っておきたいならクラウド側、という選び方になるでしょう。黒い画面に抵抗があるなら、エディタ拡張から入るのが穏やかです。

Q. CursorやGitHub CopilotとCodex・Claude Codeはどう違いますか？
A. CursorはAIが組み込まれたエディタ、GitHub Copilotはエディタの中で補完や相談を担当する仕組みで、どちらも「人が書く作業を助ける」側に軸足があります。CodexとClaude Codeは、指示を受けて自分で作業を進める側です。境目は年々曖昧になっていて、Cursorの中からClaude Codeを動かすこともできます。役割が重なる部分はありますが、人が主役か、AIに任せて結果を確認するかで整理すると分かりやすいでしょう。

Q. 日本語でのやり取りはどちらが自然ですか？
A. どちらも日本語で問題なく指示できます。私は普段のやり取りも、ルールを書いたファイルの中身も日本語です。ただし出力される説明文の言い回しや、コードに添えられるコメントの言語は、頼み方によって英語に寄ることがあります。日本語で統一したいなら、永続的な指示のファイルに「日本語で答える」と1行書いておくのが確実です。細かな言い回しの好みは人によって割れるので、両方に同じ指示を出して読み比べてみるのが早いと思います。

まとめ

CodexとClaude Codeの比較としてよく語られるのは、ベンチマークの点数と料金プランの差です。私の手元で実際に差になったのは、もっと地味なところでした。積み上げたルールがどちらにあるか、追加費用なしで回せる経路がどちらにできているか、上限に当たったときに逃げ道があるか。3つが揃った時点で、分担は自然に決まりました。

どちらが優れているかについては、私は答えを持っていません。両方を触った結論として、これから始めるならどちらでもいいと思っています。日本語は問題なく通りますし、同じ質問を投げて答えの質に落差を感じることも、いまはほとんどありません。以前は画面を見せる作業でGPT側に分があると感じていましたが、その差も埋まってきました。

分かれるのは、その先です。永続的な指示をどう書くか、よく使う手順をどう呼び出せるようにするか、どこまで自動で走らせるか。作り込み始めた時点で、道具は片側に固定されます。私が画像だけCodexに残してほかをClaude Codeに寄せているのも、能力を測って決めた結果ではなく、それぞれの経路が先にできてしまったからです。

道具は絞ったほうがいい、というのが私の基本的な考え方です。今回は例外として2本残しました。選ぶ手間を毎回払うより、選ばなくてよくなったことのほうが大きかったからです。画像を作る日に、どのサービスで作るか悩む時間はもうありません。悩まなくなったぶんの時間は、そのまま書く時間に回っています。

もし両方を試すなら、片方から始めて、足りないものが自分の中にはっきり出てきたときに足してみてください。順番を逆にすると、覚えることに追われて、どちらの良さも分からないまま終わってしまうかもしれません。そして選んだあとは、比較記事を読み比べる時間より、選んだ側に自分のルールを1行ずつ足していく時間のほうが、たぶん報われます。