いまの私は、Claude Codeをcoding以外のほぼ全部に使っている

2026年4月3日、私はこう書きました。Claude Maxをやめたあと実際に何が起きたのか、30日後にちゃんと本音で戻ってくる、と。

今回は11日早く戻ってきました。

せっかちだからではありません。もうパターンが固まっていて、5月2日まで答えを寝かせても、ほとんど演出にしかならないからです。

最初に聞くと、この結論は少し変に聞こえます。Claude Codeという名前のツールが、いまでは私にとって、code以外のほぼ全部を任せるツールになっています。

短く言うと、こうです。

xHigh thinkingのGPT-5.4を載せたCodexが、codingの席を取った。
xHighのOpus 4.7を載せたClaude Codeが、机の残り全部の席を取った。
「安いCodexで十分」という話は、現実のlimitsが見えた瞬間に崩れた。

できるだけきれいに要約すると、たぶんこうなります。

codeに関わることはすべて、xHighのCodex-GPT-5.4。それ以外はすべて、xHighのClaude Code with Opus 4.7。

19日前に私が想像していたより、ずっとシャープな分業です。

しかもその答えは、私が思っていたより高くつき、同時にワークフローの心理をかなり露わにするものでした。

最初に壊れたのはcode qualityではなかった

解約ポストを書いた時点では、話はとてもシンプルに見えていました。

Claude Max: 月額200ドル
Codex / ChatGPT: 月額20〜25ドル
execution qualityの差は急速に縮まっていた
OpenAIのreliabilityのほうが強く見えた

だから、簡単なダウングレードに見えました。

でも実際は違いました。

最初に壊れたのは、architectureでも、plan qualityでも、execution disciplineでもありません。

壊れたのは limitsの物語 でした。

実際のタイムラインは、むしろこうでした。

Apr 6: ChatGPT Businessを月額 25ドル で2席契約しました。
Apr 6: その時点ですでに、workaround前提で考え始めていました。以前に近いcoding paceを保つには、Codexを回せるaccountが3つくらい必要かもしれない、と感じていたのです。
Apr 10: その構成で数日暮らしてみて、もうはっきり言えるだけの材料がそろいました。安いaccountを3つ並べても、Claude Maxが絶好調だったときにくれたものは再現できませんでした。
Apr 12: 月額100ドルのChatGPT Pro を契約しました。pure codingでCodexを使えば使うほど、highやxHigh reasoningのGPT-5.4をもっと欲しくなり、少なくしたくはなかったからです。

これが4月3日のポストに対する、最初の正直な修正です。

置き換えは「月200ドルのClaude Maxが月20ドルのCodexになった」ではありませんでした。

実際には、もっとこういう話です。

「以前と同じAnthropicのplanは、もう必要ではない」
「ただし、安いtierで足りるほどCodexのcapacityが少なくて済むわけではない」
「比べるべきものはbenchmarkのスクリーンショットではなく、実際のlimits下でのworkflow qualityだ」

私の現時点での読みでは、OpenAIはmarket shareを取りに行くためにlimitsをかなり攻めている可能性があります。これは推測であって、内部情報ではありません。もしそうなら、この窓がずっと開いたままとは限りません。

なので、今日の20ドル経済だけに判断を全部乗せるなら、少なくともこのpricing environmentが安定ではなく戦術的なものかもしれない、という前提は持っておくべきです。

Codexがcodingの席を取った

この19日でいちばん大きかった学びは、xHigh thinkingのGPT-5.4は、かなりcoding specialistっぽい ということでした。

愛想があるわけではありません。

温かいわけでもありません。

友だちになろうとしてくる感じもありません。

でも、 specialistではあります。

Codexには、予想以上に気に入った無骨さがあります。余計な演出をせず、丁寧で、手順を踏み、methodicalに進めるエンジニアと一緒に働いている感じです。

長いworkdayでは、それが想像以上に効きました。

私にとっていちばん明確だった瞬間は 4月17日 でした。合意済みのplanをxHighのCodex-GPT-5.4に渡して、そのまま動かしました。すると 30分から45分、1つのsessionの中でずっと動き続け、planをかなり忠実に追いながら、unit tests、integration tests、browser testsをlocalで書いて実行してくれました。私は横に張りついている必要がありませんでした。

これを同じ安定感でやってくれた別のtoolを、私はまだ知りません。

これでCodexの見え方が変わりました。単に「小さいtaskなら十分」ではありません。planが明確なら、長くて disciplinedな execution ができます。

pure coding workでは、いま私はほぼいつもCodexに寄せています。

architecture
implementation
debugging
eval design
test framing
pipeline cleanup
production-mindedなproduct logic

4月の最もわかりやすい例はProvaです。

Provaで役に立った仕事の大半は、派手なものではありませんでした。「モデルがどれだけ賢いか」を見せる種類のものではなく、こういうものでした。

composableなsprintの評価
onboarding logicの引き締め
roadmap generationとassigned sprint stateの矛盾の発見
実際のproduction rowと実際のproduction behaviorをもとにした改善

こういう仕事が、Codexにはかなり合います。

仕事が次のようなものだと、Codexは competentで、thoroughで、思った以上に鋭いです。

contradictionを特定する
logic bugを切り分ける
correctnessとRFC territoryを分ける
最小で、しかも弁護可能な次の一手を出す

いちばんはっきりした例のひとつは、builder intentを持つuserの、たった1つのProva production rowでした。

その時systemは、

builder intentのあるuserを marketing_vp と判定していた
table-stakes-diagnostic を割り当てていた
もっと後ろから始まるroadmapを生成していた
onboarding直後にContext Check cardを見せていた

このエピソードが有益だったのは、診断そのものよりも、cross-review loopがあったからです。

Opus 4.7は、最初の3つの問題までを見つけました。

1つのtrack-calculation bug
1つのtiming bug
1つのbuilder-opener / RFC question

そのあとGPT-5.4が分析をさらに押し進めて、Opusが見落としていた矛盾を拾いました。

割り当てられた最初のsprintと、生成されたroadmapが、同じuserに対してすでに2つの違う真実を語っていた

これは大きかったです。議論は「Builder RFCを今shipすべきか」から、「まずliveの矛盾を直して、そのあとRFCに戻ろう」へと変わりました。

それは、私を感心させようとするmodelには感じませんでした。むしろ、まず今ある矛盾を直そう、そのあとでproduct theoryを話そう、と言うsenior SWEのように感じました。

このパターンが今月何度も繰り返されたことで、私はCodexを「安い代替手段」とは見なくなりました。いまは 自分のprimary coding instrument として見ています。

Claude Codeが残り全部の席を取った

もし話がそこまでなら、答えは単純です。Codexに乗り換えて先へ進めばいい。

でも、実際はそうなりませんでした。

Opus 4.7を載せたClaude Codeは、outputがtasteに依存する仕事、あるいはloopが長く、iterativeで、context-heavyな仕事ではまだ強いままです。

このタイトルが矛盾ではなく、むしろ正確に聞こえ始めるのはそこです。以前はcodeを書くときに反射的に手が伸びていたClaude Codeが、いまは codeを書くこと以外 のために手が伸びるtoolになりました。

「それ以外」とは、たとえばこういう仕事です。

自分の声で書かれたように見えるwriting
structureとrhythmの反復
namingとpositioning
taglineやbrand phrasing
blog coverのためのimage prompt
logoやidentityの探索
単なるfunctional UIではなくvisual judgmentが必要な /frontend-design
複数sessionにまたがってpoint of viewを育てる長いresearch thread

この19日間の体験では、これが何度も繰り返し真実でした。

差がいちばん見えやすいのは、feedback loopがあるときです。

ClaudeもCodexも、過去のpostを読み、過去のpromptを見て、既存の仕事をreferenceに使えます。でも 複数ラウンドのrefinement を回し、そのたびにfeedbackを返していくとき、Claudeのほうが私の行きたい方向を安定して理解してくれます。

これはwritingにも当てはまります。

image promptingにも当てはまります。

namingにも当てはまります。

いちばんわかりやすいproduct exampleは Prova です。あの名前はCodexでは出ませんでした。ああいう仕事ではOpusが必要でした。brand languageの探索でも同じです。GPT-5.4はsolidでcompetentな答えを返してくれます。Opusはcreative rangeをもう一段強く出してくれました。

同じパターンはsite designにも出ています。

Superpowers上の /frontend-design workflow は、仕事がengineering-ledではなくdesign-ledであるとき、私にはGPT-5.4よりOpusのほうがまだうまく機能します。Codexはfunctionalなものを返してきます。Claudeは、実際に誇りを持ってshipしたいものを返してくることが多いです。

なので、もし問いがこれなら、

「CodexはClaudeを全部置き換えたのか？」

答えは、いいえです。

置き換えたのは codingの席 です。全部ではありません。

この違いは重要です。

慣れは本物だったし、離脱感も本物だった

私は 13か月ほど Claude Codeを使ってきました。

それだけの時間を使うと、変わるのは好みのリストだけではありません。仕事中の身体感覚まで変わります。

Codexへの比重を強くしたとき、私はたしかに一種の離脱感を感じました。

Codexが悪かったからではありません。

違っていたからです。

摩擦点は小さいのに、しつこく残りました。

permission confirmationのいくつか
たまに質問が1つ多い感じ
responseのsterileなトーン
loopの中に、あの見慣れたClaudeの「声」がないこと

これは客観的な欠陥ではありません。

workflowの違いです。

そして慣れは、それをどう感じるかを変えます。

私はこの移行を、完全に合理的な経済人のようにやり切ったふりはしたくありません。

そんなことはありませんでした。

ある時点で私は、second opinionが必要だからではなく、extraのsafety-net reviewを得るためだけにClaudeへ流している自分に気づきました。「きれいに乗り換えている」という自分の物語より、引力のほうが強かったのです。

そこからわかったのは、本当の依存はClaudeのraw capabilityだけではなかった、ということです。そこには、別の知性をloopの中に持っていることで生まれる 安心感 も含まれていました。そして私はそれを、また別の仕方で信頼していました。

だからこそ、私にとって最終回答は最初から「永遠に1つを選ぶ」にはならなかったのです。

workflowの心理も重要です。

CodexにはCodexのfailure modeがある

この期間は、Codexの連勝記録ではありませんでした。

こちらも現実的な問題にぶつかりました。

いちばん最初に「これはCodex特有の問題っぽい」と感じたのは 4月14日 です。2つのterminal sessionで、こんなエラーに当たりました。

{
  "error": {
    "message": "Unknown parameter: 'prompt_cache_retention'.",
    "type": "invalid_request_error",
    "param": "prompt_cache_retention",
    "code": "unknown_parameter"
  }
}

こういうことが重要なのは、reasoning layerではなくharness layerへの信頼を壊すからです。

また、Codexはdeployやproductionへのタッチまわりで、modelが何を許されるかに対して、同じsessionの中で既にapprovalが通っていたあとでも、より厳格に見えることがありました。

それが良い時もあります。

面倒な時もあります。

でも、間違いなく実際のuser experienceの一部です。

Codex側で本当に好きな小さな点を1つ挙げるなら、main flowを止めずにstatusやlimitsを見られることです。今の作業が終わるのを待たずに /status を打てるのは小さなことですが、19日も使うと、そういうergonomicsの差が積み上がっていきます。

私が「両者はoutput qualityだけで違うのではない」と言うのは、そういう意味です。違いは harnessの感触 にもあります。

reliabilityはやはり大事で、4月はClaudeに追い風ではなかった

そもそも私が安心して切り替えを始められた理由のひとつが、reliabilityでした。

3月31日のfollow-upでも、AnthropicとOpenAIの90日status差について書きました。大きな絵は今も変わりません。

Anthropicの90日uptime status。claude.ai、platform、API、Claude Codeにpartial outageがあったことを示す画像

OpenAIの90日system status。APIが99.99%、ChatGPTが99.91%のuptimeを示す画像

そして4月は、もう1つ現実のリマインダーを追加しました。

4月15日、Claudeでは Claude.ai、API、Claude Codeにまたがってelevated errorsが発生しました。loginも影響を受けました。APIが先に回復し、すでにログイン済みのClaude Code userは作業を続けられましたが、login自体はしばらく壊れていました。

これはClaudeの強みを消すものではありません。

ただし、自分のworkflow全体を1つのvendorに賭けないほうがいい、という実務的な論拠はさらに強くします。

これはこのexperiment全体を通じて、いまもかなり durableな教訓です。

dual-wieldingは贅沢ではなく、operational resilienceだ。

1つのproviderが悪い午後を過ごしていても、こちらはshipし続けられます。

Opus 4.7はパターンをより鋭くした。ひっくり返したわけではない

Claude Opus 4.7は4月16日に出ました。 これをまともに試さずに何か正直なverdictを出すのはフェアではありません。

だから私は、すぐにProvaの実案件のcoding diagnosticに当てました。

Opus 4.7はsolidなfirst passを返してきました。track bug、timingのずれたContext Check card、そしてより広いBuilder-openerの問いを拾いました。

そのあと、そのdiagnosisをGPT-5.4にcritique passとしてかけました。blind second opinionとしてではなく、Opusが書いた分析を読むreviewerとしてです。GPT-5.4は、Opusが見落としていたもっと鋭い矛盾を捉えました。productはすでに1つのfirst sprintを割り当てているのに、roadmapは別の場所から始まっていたのです。これはBuilder fitの話だけではありません。liveなcorrectness problemでした。

その改訂版diagnosisをもう一度Opusに戻すと、そこでは収束しました。

ただ、驚きは別方向からも来ました。

4月19日、私は予想していなかったことに気づきました。よりシンプルなtask、たとえば短いcode review passや、小さな変更へのfocused executionでは、xHighのOpus 4.7はxHighのCodex-GPT-5.4より明らかに遅い のです。私は逆を予想していました。

この1点で、私のパターンは再びはっきりしました。

Opusが今も明確に勝っているのは、上で書いたようなtaste-heavyでiterativeでlong-contextな仕事です。Codexが明確に勝っているのは、深いcoding diagnosis と、以前ならClaudeに頼っていた日常の高速なcoding turnです。

つまり、正直な言い方をするとこうです。

Opus 4.7 は、より深い code analysis では今でも良い first pass を返してくれる
ただしlighter coding turnsでは、今のところ同じthinking levelのGPT-5.4より遅く感じる
そして4月17日のcontinuous execution experienceと合わさることで、coding seatは引き分けに近づくどころか、さらにCodex側へ傾いた

実際に私はどこへ着地したのか

dramaも、pricing screenshotも、outage screenshotも、social-post framingも外してしまうと、4月22日時点で 私のworking patternはこう落ち着いています。

codeに関わること全部

私はまず xHigh thinkingのCodex with GPT-5.4 に手を伸ばします。

理由はこうです。

specializedに感じる
methodicalである
carefulである
architectureとexecutionの両方をうまく扱う
unit、integration、browser tests込みのagreed planを30〜45分走らせられる
日常的なcoding turnでは今のところxHighのOpus 4.7より速い
deep coding workでも信頼しやすくなった

それ以外全部

私は xHigh thinkingのClaude Code with Opus 4.7 に手を伸ばします。

そこに含まれるのは、いまこういう仕事です。

自分の声で書かれたように見えるwriting
cover artのためのimage prompt
naming、positioning、brand language
visual judgmentが必要な /frontend-design
複数sessionにまたがってpoint of viewを育てる長いresearch thread
Codexに渡す前の、自分のplanの見直し
このblog post

理由はこうです。

私のstyleによりよく沿う
feedback-drivenなcreative iterationに強い
brand tasteとdesign tasteがより強い
仕事がexecutionではなく judgment のとき、いまも最も信頼しているmodelである

重要なcoding planについて

cross-review loopは今でも好きです。

一方からplanを取る
もう一方にcritiqueさせる
そこからさらに締める

どれだけ良いmodelでも、最初の答え1つに賭けるより、このworkflowのほうが私には堅牢に感じられます。上で触れたbuilder-intent rowが、その理由そのものです。

pricingについて

私は単純なcheap switchには着地しませんでした。

着地先はこうです。

以前の 月200ドルのClaude Max構造 はもう欲しくない
欲しいのは より多いCodex capacity であって、より少ないものではない
coding planの現実的な答えとして 月100ドルのChatGPT Pro を受け入れた
そしてcode以外ではClaudeをloopに残している

shippingについて

この切り替えの目的は、shipし続けることでした。これは何も見せるもののない19日間のtool benchmarkingではありません。同じ期間に、ProvaのOperator/Builder splitは実際のBuilder execution lane付きでliveになり、2本のsubstantialなblog postが出て、さらに12 localeにまたがるtranslation passも走らせました。このexperimentでoutputが落ちたかという問いへの答えは、いいえです。

いちばん圧縮した言い方をするなら、こうです。

私はClaude Maxをやめた。でもClaude Codeを仕事から消したわけではない。primary coding seatから外して、机の残り全部を任せることにした。

これが、いま私が言えるいちばん正直な要約です。

では、同じ決断をもう一度するか

はい。

ただ、今なら言い方は変わります。

4月3日時点のframingはこうでした。

「Claude Maxをやめて、Codexで置き換えられるか試している」

4月22日時点では、むしろこうです。

「Claude Maxをやめた結果、いまの私にはCodexのほうが強いcoding specialistだとわかり、Claude Codeは机の残り全部に使っている。そこでは依然として手元で最良のtoolだ」

この答えは、より非二元的で、単純なsocial-post版より高くつき、そしてずっと真実に近いです。

よくある質問

Codexは本当にClaudeをcodingで置き換えたのですか？

私にとっては、はいです。pure coding workでは、xHigh thinkingのCodex with GPT-5.4がdefault seatになりました。xHigh の Opus 4.7 は深い diagnosis では今でも役に立つ first pass を返してくれますが、私にとってはもう primary coding seat ではなく、lighter coding turn では Codex より遅く感じます。

「安いCodexでいける」という話は成り立ちましたか？

完全には成り立ちませんでした。実際のボリュームで使った瞬間、安いtierの経済性だけでは話が足りなくなりました。私はexperimentが失敗したからではなく、もっとcapacityが欲しかったから、より高いOpenAI planに移りました。

それでもClaudeは必要ですか？

はい。もし仕事にwriting、design、naming、image prompting、long research thread、あるいはtasteやjudgmentに重いloopが含まれるなら、Claudeはまだ必要です。私のworkflowでは、code以外すべてのdefaultがxHighのOpus 4.7になっています。

reliabilityについては？

reliability gapは今でも重要です。4月はそれをさらに強めました。答えはpanicではありません。答えはbackup coverageです。

なぜ11日早く公開したのですか？

パターンがもうsettleしていたからです。元のheadlineの数字を守るためだけに5月2日まで待つのは、演出にしかならなかったでしょう。いま自分が実際にやっていることをそのまま書いて先へ進むほうが、正直でした。

では、今日どのplanを買いますか？

もし仕事の大半がcodingなら、私はまずCodex / GPT-5.4をかなり真剣に見ます。もし仕事がcodingに加えてtaste-heavyなcreative workを多く含むなら、Claudeなしにはしたくありません。そして月100ドルが今は難しいなら、20ドルのCodex tierでも小さめのindividual projectにはまだ使えます。ただし、sustainedなmulti-project workでは、より早くlimitsに当たると見ておいたほうがいいです。少なくとも、今の私の答えはsingle-tool answerではありません。

これが、19日後の正直なupdateです。

Codexがcodingの席を取った。

Claude Codeが残り全部の席を取った。

だからこそ、文字どおりClaude Codeという名前のtoolが、いまの私にとってはcode以外の仕事を任せるtoolになっています。

そして本当の教訓は、やはりworkflowがfandomより大事だということです。

もし今月あなたも似たようなswitchをしたなら、どこに着地したのか本当に知りたいです。どちらか1つが完全に勝ちましたか。それとも、あなたのsplitもさらにシャープになりましたか。

それでは、
Chandler