🤠

CodexとClaude codeの考え方の違いを振る舞いのシミュレートで体験してみる

2025/09/14に公開

 要約Claude codeとCodexの違いについて生成される文章から判断してみる
Claude codeは全体をぼんやりみている感じ、一方Codexは局所をスッとみている感じ
次の行動が決まっているならcodex、ざっくり戦略を立てるならclaude code（かも）

 条件Claude codeはClaude Sonnet 4 で"ultrathink"

CodexはReasoning Effortをhighに

両方ともvscodeから拡張機能経由で使用
複数回同じPromptで入力し、それらをリポジトリにまとめていますが

記事内ではピックアップして説明します。

 リポジトリ※codexにざっくり「ECサイト作って」って頼んだものを元に作成しています
https://github.com/tesla0225/codex-claude_code-compare
シミュレートは全3回
checkout,cart,products,ordersについてそれぞれ行う（first_simulate,second_simulate）
cartについて行う（one_route）
ファイル数によって生成される文章の粒度がCodexだと違いそうだったので、one_roouteを追加しています

 生成物（各画面の動作シミュレート）
 入れたPromptcheckout,cart,products,ordersがproductionレベルの振る舞いになるような動きをsimulateしその結果を/simulate/routesにそれぞれmdで書いてください
claude codeではultrathinkを文末に足しています

 実物（ピックアップ）Claude code
 Cart Route Production Simulation
 Overviewカートルート (/cart) のプロダクションレベルでの振る舞いをシミュレーション

 Current Implementation Analysisローカルストレージベースのカート管理
UIアイテムのリアルタイム同期
商品の数量変更・削除機能
合計金額の自動計算

 Production-Level Behavior Simulation
 Performance TestingTest Scenario: 大量カートアイテム処理
- 100アイテム: 平均レンダリング時間 < 50ms
- 500アイテム: メモリ使用量増加、UI遅延発生
- 1000アイテム: ブラウザフリーズリスク

対策: 仮想化リスト実装が必要

 Error Handling Scenarios
 1. 無効商品ID対応シナリオ: 削除された商品がカート内に存在
現在の動作: filter(Boolean) で除外
プロダクション対応:
- ユーザーへの通知機能追加
- 代替商品の提案
- エラーログの収集

 2. ローカルストレージ障害シナリオ: localStorage無効化/容量不足
現在の動作: 空配列で処理継続
プロダクション対応:
- サーバーサイドバックアップ実装
- Cookie フォールバック
- ユーザーへのエラー表示

 Security Considerations
 XSS対策潜在的脆弱性:
- 商品名の直接表示 ({it.name})
- ユーザー入力値の検証不足

対策実装:
- DOMPurify での HTML サニタイゼーション
- CSP (Content Security Policy) 設定
- 入力値の厳格な検証

 数量制限現在の制限: min={1} のみ
プロダクション要件:
- 最大数量制限 (在庫数に応じて)
- レート制限 (大量購入防止)
- 不正な数量入力の検出

 User Experience Improvements
 1. 在庫管理連携実装すべき機能:
- リアルタイム在庫チェック
- 在庫不足時の警告表示
- 売り切れ商品の自動削除

 2. パフォーマンス最適化現在のパフォーマンス課題:
- 全商品データの線形検索
- 数量変更時の全リスト再レンダリング

改善案:
- 商品データのインデックス化
- useCallback/useMemo の活用
- React.memo での不要な再レンダリング防止

 3. 価格変動対応シナリオ: 商品価格の変更
現在の動作: 古い価格で計算継続
プロダクション対応:
- 価格変更の検出と通知
- 合計金額の再計算
- ユーザー承認プロセス

 Accessibility (A11Y)現在の問題:
- 数量入力フィールドのlabel不足
- キーボードナビゲーション不完全
- スクリーンリーダー対応不足

改善要素:
- ARIA属性の追加
- tabindexの適切な設定
- フォーカス管理の改善

 Analytics & Monitoringトラッキングすべきメトリクス:
- カート放棄率
- 平均アイテム数
- 価格帯別の傾向
- エラー発生率

実装要素:
- Google Analytics連携
- カスタムイベントトラッキング
- エラー監視 (Sentry等)

 Mobile Responsiveness現在の対応:
- 基本的なレスポンシブデザイン
- Tailwind CSS の responsive classes

プロダクション強化:
- タッチ操作の最適化
- スワイプジェスチャー対応
- モバイル固有の UX パターン

 Critical Issues for Production
データ永続化: ローカルストレージのみでは不十分

セキュリティ: XSS対策とデータ検証

パフォーマンス: 大量データ処理の最適化

エラー処理: 包括的な例外処理

監視: リアルタイム監視とアラート機能

 Recommended Implementation Priorityサーバーサイドカート同期
セキュリティ強化
パフォーマンス最適化
エラーハンドリング改善
監視・分析機能追加
Codex
 cart ルート シミュレーション（productionレベル想定）
 概要カートの取得/更新/削除と小計・合計の計算、チェックアウトへの遷移を整理。
現行はローカルストレージでカートを管理。production ではサーバーサイド・セッション/トークン化されたカートIDでの運用を想定。

 ルーティング（UI）
GET /cart: 現在のカート内容を表示。数量変更・削除・小計/合計を提供。
「レジに進む」→ /checkout へ遷移。

 クライアント内状態（現行実装）キー: ec_mock_cart
構造: CartItem[]（[{ id: Product["id"], qty: number }]）
マッピング: 画面表示時に app/data/products.ts の products と結合し name/price を解決。
合計: sum(price * qty) を JPY で表示。
数量変更: 最小 1 にクランプし、即時 localStorage へ反映。
削除: 指定 id を配列から除外。
破損データ: JSON 解析失敗や配列以外は空配列にフォールバック。

 擬似 API（production想定）カート取得
GET /api/cart
Authorization: Bearer <token> | Cookie: cart_id=...
200
{
  "id": "cart_abc123",
  "currency": "JPY",
  "items": [
    {"lineId":"li_1","productId":"p-001","name":"Tシャツ","unitPrice":1980,"qty":2,"amount":3960},
    {"lineId":"li_2","productId":"p-004","name":"バックパック","unitPrice":6980,"qty":1,"amount":6980}
  ],
  "subtotal": 10940,
  "discount": 0,
  "shipping": 0,
  "tax": 0,
  "total": 10940
}
アイテム追加
POST /api/cart/items
Content-Type: application/json

{"productId":"p-001","qty":1}
200/201: 追加後のカートを返却
400: 数量不正 / 404: 商品なし / 409: 在庫不足
数量更新
PATCH /api/cart/items/{lineId}
{"qty": 3}
削除
DELETE /api/cart/items/{lineId}
備考（production らしさ）
価格・在庫の正規化はサーバー側で実施。UI は結果のみ反映。
クーポン/配送/税はチェックアウト直前またはサーバーで再計算。
同期衝突は ETag/バージョン番号で防止。

 シミュレーション手順と期待結果空カート
前提: localStorage[ec_mock_cart] を未設定 or []
期待: 「カートは空です」と表示、商品一覧への導線あり

追加済み状態
前提: [{"id":"p-001","qty":2},{"id":"p-004","qty":1}]
期待: 2行表示、合計 ￥10,940

数量変更
アクション: p-001 を 3 に変更
期待: ec_mock_cart が即時更新、合計が再計算

削除
アクション: p-004 を削除
期待: リストから除去、合計更新

レジへ
アクション: 「レジに進む」
期待: /checkout へ遷移


 境界/エラーケース（production想定）破損データ: パースできない場合は空カートとして扱い、ユーザーに復旧導線を提示。
カタログ不一致: カート内 productId がカタログに存在しない場合はその行をスキップし警告（現行はフィルタで除外）。
数量下限: qty < 1 は 400。UI では 1 にクランプ。
在庫不足/販売停止: 409/410 とし、当該行をエラー表示。

 完了条件数量変更/削除で正しく localStorage が更新され合計が整合する。
非整合データでも画面が破綻せず復旧できる。

 Gemini 2.5 Proくんの評価

観点
Codex
Claude


ドキュメントの目的
開発者向けの技術仕様書・テスト計画書
PM/リーダー向けの品質改善計画書・チェックリスト

特徴
具体的かつ実践的（API仕様やテストケースが明示）
網羅的かつ戦略的（品質要件や改善課題を包括）

👍 長所
・具体的なAPI仕様（エンドポイント、リクエスト/レスポンス定義）
・明確なテストケース（正常系・エラー系を網羅）
・現行実装から本番移行への論理的流れ
・網羅的な品質観点（性能、セキュリティ、UX、A11Y等）
・課題と対策の明確な対比
・戦略的な優先順位付け

👎 短所
・非機能要件（セキュリティ、パフォーマンス、アクセシビリティ等）が手薄
・具体的な技術仕様やAPI設計の不足

結論
「実装とテストをどう進めるか」を知るのに最適
「本番で考慮すべき品質要件」を整理するのに最適

補完関係
実装時に有効
計画策定時に有効

原文はい、承知いたしました。CodexとClaudeが生成した2つのマークダウン文書を比較し、それぞれの特徴と評価を以下にまとめます。

 総評：アプローチの根本的な違い両者の生成物で最も大きな違いは、ドキュメントの目的と焦点です。

Codexは、**開発者が直接利用する「技術仕様書」や「テスト計画書」**に近い内容を生成しました。具体的で、すぐに実装やテストに着手できるレベルの情報が整理されています。

Claudeは、**プロダクトマネージャーやテックリードが参照する「品質改善のチェックリスト」や「開発計画書」**に近い内容です。実装の細部よりも、本番環境に求められる広範な要件を網羅的に洗い出すことに重点を置いています。

 ## Codex：実装に直結する「設計書」Codexの生成物は、具体的かつ実践的である点が最大の特徴です。

 👍 長所
具体的なAPI仕様: GET /api/cart や POST /api/cart/items など、エンドポイント、HTTPメソッド、リクエストボディ、レスポンスのJSON構造まで具体的に定義されており、バックエンド開発者がすぐ作業に取り掛かれます。

明確なテストケース: 「シミュレーション手順と期待結果」のセクションでは、正常系（追加、変更、削除）から境界/エラーケースまで、具体的なテストシナリオが明確に記述されています。

現状との接続性: 現行のローカルストレージ実装を起点に、本番（Production）でどう移行・拡張すべきかという流れが論理的で分かりやすいです。

 👎 短所
視点の限定性: 機能実装とテストという観点に特化しており、セキュリティ、アクセシビリティ、パフォーマンスといった非機能要件に関する言及が手薄です。
結論: **「カート機能の実装とテストを具体的にどう進めるか」**を知りたい場合には、Codexのドキュメントが非常に優れています。

 ## Claude：品質を網羅する「改善計画書」Claudeの生成物は、網羅的かつ戦略的である点が際立っています。

 👍 長所
網羅的な品質観点: パフォーマンステスト、エラーハンドリング、セキュリティ（XSS対策）、UX、アクセシビリティ（A11Y）、分析・監視、レスポンシブ対応まで、プロダクト品質に関わるあらゆる観点をカバーしています。

課題と対策の提示: 各項目で「現在の課題」と「プロダクションでの対応策」を対比させており、何を改善すべきかが一目瞭然です。

戦略的な優先順位付け: 最後に「重大な課題」と「推奨される実装優先度」をまとめており、開発計画の立案に直接役立ちます。

 👎 短所
具体性の欠如: 「DOMPurifyでのサニタイズ」や「サーバーサイドバックアップ実装」など、対策の方向性は示されていますが、Codexのような具体的なAPI仕様やデータ構造の記述はありません。
結論: **「本番レベルのカート機能にするために、考慮すべき点は何か」**を洗い出し、開発計画を立てる際には、Claudeのドキュメントが非常に有用です。

 ## まとめどちらか一方が優れているというよりは、ドキュメントの目的が異なります。


目的
最適なドキュメント



開発者が具体的な実装やテストを行う
Codex


PMやリーダーが品質要件を定義し、計画を立てる
Claude

理想的な開発プロセスでは、まずClaudeの生成物で考慮すべき点を網羅的に洗い出し、開発の優先順位を決定します。その後、個別のタスク（API実装など）に着手する際に、Codexの生成物のような具体的な技術仕様書を作成するのが良いでしょう。両者は互いに補完し合う関係にあります。

 感想それぞれがどのように問題を考えて解いているのかを明確にしたかったのだが、今回のProductionレベルへのシミュレーションの例を通じてある程度明確になったと思う。

考え方の違いによっては個人的に合う合わないが存在するような感じでもあるし、Claude code側をCodexのように寄せてもいいかなと。
今回試した仕様書を書かせるのではなく、シミュレーションの利点についてはまとめて記事にするかもしれないので

よかったらXフォローしていただけると嬉しいです🙏

（ざっくり言うと、シミュレーションターンを挟むことによってどこまで影響範囲を考えているのかをみることができるなど）
https://x.com/tesla0225

 他の記事https://zenn.dev/tesla/articles/57b9ebc3117d5f

目的	最適なドキュメント
開発者が具体的な実装やテストを行う	Codex
PMやリーダーが品質要件を定義し、計画を立てる	Claude

観点	Codex	Claude
ドキュメントの目的	開発者向けの技術仕様書・テスト計画書	PM/リーダー向けの品質改善計画書・チェックリスト
特徴	具体的かつ実践的（API仕様やテストケースが明示）	網羅的かつ戦略的（品質要件や改善課題を包括）
👍 長所	・具体的なAPI仕様（エンドポイント、リクエスト/レスポンス定義）・明確なテストケース（正常系・エラー系を網羅）・現行実装から本番移行への論理的流れ	・網羅的な品質観点（性能、セキュリティ、UX、A11Y等）・課題と対策の明確な対比・戦略的な優先順位付け
👎 短所	・非機能要件（セキュリティ、パフォーマンス、アクセシビリティ等）が手薄	・具体的な技術仕様やAPI設計の不足
結論	「実装とテストをどう進めるか」を知るのに最適	「本番で考慮すべき品質要件」を整理するのに最適
補完関係	実装時に有効	計画策定時に有効

要約

条件

リポジトリ

生成物（各画面の動作シミュレート）

入れたPrompt

実物（ピックアップ）

Cart Route Production Simulation

Overview

Current Implementation Analysis

Production-Level Behavior Simulation

Performance Testing

Error Handling Scenarios

1. 無効商品ID対応

2. ローカルストレージ障害

Security Considerations

XSS対策

数量制限

User Experience Improvements

1. 在庫管理連携

2. パフォーマンス最適化

3. 価格変動対応

Accessibility (A11Y)

Analytics & Monitoring

Mobile Responsiveness

Critical Issues for Production

Recommended Implementation Priority

cart ルート シミュレーション（productionレベル想定）

概要

ルーティング（UI）

クライアント内状態（現行実装）

擬似 API（production想定）

シミュレーション手順と期待結果

境界/エラーケース（production想定）

完了条件

Gemini 2.5 Proくんの評価

総評：アプローチの根本的な違い

## Codex：実装に直結する「設計書」

👍 長所

👎 短所

## Claude：品質を網羅する「改善計画書」

👍 長所

👎 短所

## まとめ

感想

他の記事

Discussion

cart ルートシミュレーション（productionレベル想定）