🌟

Claude Code と Codex を使い比べて見えた設計思想の違い

に公開1件
AI
OpenAI
Anthropic
Claude Code
Codex
tech

この記事は、今まで Claude Code 1本でやってきていたエンジニアが、Opus 4.7 の体験が悪く、Codex に浮気してみて気づいたことのまとめである。

実際に触った感想は多くの人がまとめているが、その振る舞いが起こる理由について考察している人はあまり見かけなかった。

そのため本記事では、

  • Claude Code と Codex の公式情報
  • 実際に利用して観測した振る舞い
  • そこから考えた仮説

を整理してみる。

Anthropic / OpenAI に共通する発展過程

LLM は文脈的整合性を優先しやすい

Claude / Codex を含む現在の LLM（Large Language Model）は、大量テキストから：

「次に来る単語を予測する」

学習をベースにしている。

Anthropic / OpenAI の両方とも、この next-token prediction 的な学習を前提に説明している。

現在の主要な LLM は Transformer アーキテクチャを基盤としている。

Transformer は Attention 機構によって文脈中の単語同士の関係を扱う構造を持っており、現在の LLM の基礎となっている。

その上で、大量の自然言語やコードを学習することで：

  • 会話
  • 設計議論
  • プログラミング
  • ドキュメント

などのパターンも内部表現として獲得している。

このような LLM の発展の経緯を知ると、LLM が出力するものは「文脈として自然な出力」へ寄りやすい傾向になるのは自然な出来事として受け止めるのが良さそうに思える。

OpenAI は hallucination（もっともらしい誤出力）の説明の中で：

they may guess rather than say 'I don't know'

（「分からない」と答える代わりに推測してしまうことがある）

と説明している。

coding agent は grounding を重視している

grounding とは、本記事ではリポジトリ・実行環境・テスト結果のような実際の情報源を根拠に推論することを指す。

Anthropic / OpenAI の両方とも、coding agent において：

  • コード探索
  • ツール実行
  • テスト実行
  • 実行結果の確認

をかなり重視していて、LLM 単体の推論だけではなく、実際のコードベースや実行結果へ接地（grounding）する方向へ進んでいる。

Anthropic の Claude Code docs でも：

  • code exploration（コード探索）
  • root cause analysis（原因分析）
  • testing（テスト実行）

などの workflow が明示されている。

OpenAI の Codex docs でも：

  • code reading（コード読み取り）
  • repo integration（リポジトリ連携）
  • verification（検証）

がかなり前面に出されている。

Anthropic / OpenAI の両方とも、コードや実行結果を実際に確認しながら推論を進めることを重視していることが分かる。

これは、実際の情報源への grounding を重視していると言っていいだろう。

このセクションをまとめると、Claude Code / Codex ともに LLM が汎用性を得るまでの進化の過程は共通していることが分かる。

少なくとも今回観測した差分は、LLM そのものの基本的な発展過程だけでは説明しにくそうである。

Claude Code と Codex の設計思想の違い

Claude Code は形成した作業仮説との整合性を維持しようとする傾向が強い

Anthropic は Claude Code を：

agentic coding system

（自律的にタスクを進めるコーディングシステム）

として説明しており：

  • コードベースの読み取り
  • 複数ファイルにまたがる変更
  • テスト実行とコミット

といった一連の作業を自律的に進めることを重視している。

また、Claude Code のベストプラクティスでは：

Explore first, then plan, then code

（まず探索し、次に計画し、それから実装する）

という、まず探索を行い、その後に計画し、実装へ進むワークフローが推奨されている。

入力コンテキストを元に調査して作成した plan が後続の推論に強い影響を与える可能性がある。

自分が実際に観測した範囲でも、その傾向は観察できていた。

既存アプリの仕様を調査する際に、記憶にある情報をそのまま計画にしたが、実際のコードと乖離があった時の振る舞いで観測した事例である。

既存仕様の xxx について詳細を把握したい。
yyy ファイルにロジックがあって、
たしかこんな感じだったはず。

という状態から計画作成していくと、

  • yyy ファイルが存在すること
  • 知りたいロジックが含まれていること
  • 周辺ファイルも探索すること

を明示した計画が作成されていた。

計画のレビューをしても違和感はなかったため、そのまま調査を進めてもらった。

調査結果を見ると、一見期待通りの結果に見えたが、野生の直感で筋の悪いロジックで説明されているような違和感に気づいた。

この zzz について、
どのコードから確定したか教えて欲しい

という指摘をしたところ、Claude Code は：

コードを読んでいませんでした。
コードから把握します。

コード上は実際には違いました。
正しくはこうです。

という、衝撃的な応答を返してきた。

これが冒頭に触れた Opus 4.7 体験が悪い印象的な例になっている。

エンジニアにとっては、コード確認を伴わないままもっともらしい説明が生成されてしまった事例である。

公式情報と実体験から感じたことをまとめると、私には Claude Code は、調査タスクに対して入力コンテキストから形成した作業仮説（plan）を中心に推論を進め、その仮説との整合性を維持しようとする傾向がある agent に見えた。

Codex はコードや実行結果との整合性を維持しようとする傾向が強い

一方、OpenAI は Codex を：

read, edit, and run code

（コードを読む → 編集する → 実行する）

coding agent として説明している。

また OpenAI は：

  • repo integration（リポジトリ連携）
  • code reading（コード読み取り）
  • test/review loop（テストと検証を繰り返すループ）

もかなり前面に出している。

また、Codex のベストプラクティスでは、プロンプトに：

goal, context, constraints, and completion criteria

（ゴール・文脈・制約・完了条件）

を組み込むことが推奨されており、加えてテストとレビューのワークフローが前面に出されている。

タスクの完了条件の明確さを重視しており、事前知識そのものよりも goal や completion criteria によってタスクを定義する方向性が見える。

自分が実際に観測した範囲でも、その傾向は観察できていた。

既存仕様の xxx について詳細を把握したい。
yyy ファイルにロジックがあって、
たしかこんな感じだったはず。

という依頼をしたところ、Codex は：

調査したところユーザーと違う箇所があることが判明しました。
2点確認させてください。

という応答を返してきた。

調査結果には具体のコードを提示した上で、ここからこう読み取れるという情報が添付されていた。

公式情報と実体験から感じたことをまとめると、私には Codex は、調査タスクに対して入力コンテキストは調査対象や完了条件の定義に利用しつつも、実際のコードや実行結果を優先して推論を更新する傾向がある agent に見えた。

このセクションをまとめると、Claude Code は形成した作業仮説（plan）との整合性を維持しようとする傾向があり、Codex はコードや実行結果との整合性を維持しようとする傾向があるように見えた。

その結果、ユーザーが不正確な前提を与えた場合でも、Claude Code はその前提の影響を受けたまま推論を進めやすく、Codex はコードや実行結果を根拠に前提を見直しやすいように見えた。

現在の使い分け

ここまで紹介した内容は、あくまで公式情報を元にした私個人の仮説と実体験から得られた考察である。

しかし実際に両方を利用していく中で、両者には無視できない傾向の違いがあると感じるようになり、現在は明確に役割を分けて利用している。

現在の私の基本方針は以下の通りである。

調査・技術検討・PR作成 → Claude Code
実装・リファクタリング・コード修正 → Codex

実装は Codex に任せる

実装作業については、現在はほぼ Codex に任せている。

前節で述べた通り、私の観測では Codex はコードや実行結果との整合性を維持しようとする傾向が強い。

実際の利用でも、

ユーザーの認識
↓
コード確認
↓
差異検出
↓
確認質問
↓
実装

という流れになることが多く、既存コードベースを理解しながら修正を進めるタスクとの相性が良いと感じている。

そのため、既存コードの理解や修正、リファクタリングといった作業では、現在は Codex を第一選択としている。

PR本文は Claude Code に任せる

一方で、PR本文の作成は Claude Code に任せている。

これは変更意図の説明能力の話ではない。

私の観測では、両者とも変更意図についてはユーザーから十分な情報が与えられなければ誤った推測を行う可能性がある。

違いを感じているのは、変更内容の整理や要約の仕方である。

例えば同じ差分からPR本文を生成した場合でも、Codex は変更内容を網羅的に列挙する傾向がある。

- FooRepositoryを追加
- UserUseCaseを修正
- APIClientの責務を変更
- UnitTestを追加
...

情報としては正しいが、人間が変更の全体像を把握するにはやや負荷が高い。

一方で Claude Code は、複数の変更をまとめて整理し、

認証処理の責務を整理するため、
関連するRepositoryとUseCaseの依存関係を見直した。

のように、人間が理解しやすい粒度に圧縮して説明することが多い。

そのため、現在は実装を Codex に任せ、完成した差分を Claude に読ませて PR 本文を生成する運用に落ち着いている。

技術調査では両方を使う

また、技術調査や設計検討については、Claude Code と Codex を組み合わせて利用することが多い。

新しいライブラリやアーキテクチャ、開発プラクティスを検討する際には、まず Claude Code を利用する。

実際には、

  • OSS の実装調査
  • フレームワークのベストプラクティス調査
  • 設計パターンの比較
  • 他社事例の収集

のような用途で利用することが多い。

そのため、

世の中ではどのような解決方法があるのか
どのようなプラクティスが存在するのか

を把握する段階では Claude Code を利用することが多い。

しかし、その結果をそのまま採用することは少ない。

実際に重要になるのは、

そのプラクティスを自分たちのプロダクトに適用できるのか
既存コードとの整合性は取れるのか
導入コストや影響範囲はどれくらいか

という検証である。

ここでは Codex を利用することが多い。

実際のコードベースを踏まえながら、

この設計を導入するとどこに影響するか
既存実装との差分は何か
導入時に問題になりそうな箇所はどこか

を具体的に検討する用途との相性が良いと感じている。

その結果、技術調査については、

情報収集・一般論の整理 → Claude Code
既存コードベースへの適用検討 → Codex

という流れで進めることが多い。

私にとって Claude Code は選択肢を広げるためのツールであり、Codex はその選択肢を現実のコードベースに適用可能か検証するためのツールになっている。

使い分けの基準

現在の私の使い分けを一言で表現すると、

コードを変更したいなら Codex
情報を整理したいなら Claude

である。

もちろん両者とも高性能な coding agent であり、多くのタスクはどちらでも実行できる。

しかし、実際の開発現場では、

  • コードとの整合性を重視したいのか
  • 文脈や情報整理を重視したいのか

によって求める振る舞いは変わる。

ここまで紹介した使い分けを振り返ると、自分の中では徐々に役割分担が明確になってきた。

Claude Code は、人間が抱える曖昧な課題を整理し、選択肢を広げる役割を担っている。

一方で Codex は、その選択肢を実際のコードベースへ適用し、検証しながら実装する役割を担っている。

そのため現在の私は、

Claude Code
= 問題空間の探索

Codex
= 解空間の実行

として捉えている。

Anthropic は Claude Code において

Explore first, then plan, then code

（まず探索し、次に計画し、それから実装する）

というワークフローを推奨している。

一方で OpenAI は Codex を

read, edit, and run code

（コードを読む → 編集する → 実行する）

できる coding agent として説明している。

私は両者を競合製品としてではなく、異なる特性を持つ開発パートナーとして使い分けている。

おわりに

2026/6現在、Claude Code / Codex どちらも潤沢に使える環境下での使い分けメモである。

現時点では、

  • 情報収集や整理は Claude Code
  • 実装や検証は Codex

という形で落ち着いている。

ただし、この使い分けが今後も続くとは限らない。

最近の動向として、モデルの進化は非常に速く、今回観測した特性差そのものが数か月後には小さくなっている可能性も十分にある。

また、トークンにかかる費用は増加傾向にあり、このまま複数の coding agent を併用し続けるコストはいずれ無視できなくなるだろう。

その時に改めて最適な選択ができるようにするためにも、

  • Claude Code はどのような場面で価値を発揮していたのか
  • Codex はどのような場面で価値を発揮していたのか
  • なぜ現在の使い分けに落ち着いたのか

を記録として残しておきたいと思った。

将来的にコスト最適化を考える上でも、それぞれの特性を理解しておくことでより良い選択肢を選べるようになるだろう。

Discussion

hidao80hidao80

とても興味深い洞察です。
ローカル LLM なのでパフォーマンスは下がるものの、Ollama で同じモデルを使って Claude Code と Codex を利用することができるので、モデルによらず Claude Code と Codex の挙動を比較して AI コーディングツールそのものの傾向を比較しても面白いかもしれません。