Zenn
🤖

【検証】Claude Opus 4.1 vs codex-1(high) | プロセス・定量・定性の3軸で比較 2025年9月版

に公開
AI
Claude
Codex
zennfes2025ai
zennfes2025free
tech

😺 はじめに

本来は要件定義〜設計からのフルサイクルでの比較を目指したが、自由度の高い指示では中途逸脱が多く再現性が下がってしまいました ;(
そのため、本検証では設計を既知の状態に固定し、実装・運用タスクの正確性と堅牢性に評価軸を絞っています。[1]

📌 要約

今回の結果をまとめると、小規模なコードベースにおいて両者に大きな差異は見られませんでした。

Claude Opus 4.1 は全体を丁寧に整備する姿勢が明確で、見た目やテストの充実度も含めて「保守寄り」の性格が伺えます。
一方で、codex-1(high) は仕様に忠実かつ効率的に応答する傾向が強く、コードの端正さを重視する反面、周辺整備は後景に退いています。

両者とも一定の水準には達しており、差異がより明確になるのはコードベースが大規模化した場合だろうと考えます。[2]

🔬 前提条件

  1. 計画と指示：仕様整理・ガイドライン（AGENTS.md）は 著者とGPT-5-Thinking で作成。両エージェントには AGENTS.md を付与し、比較は同一条件のアウトプットに限定
  2. 実行環境：すべて CLI で実施。各ラウンドは新規セッション（コールドスタート）
  3. 記憶/履歴：memory/会話履歴/プロジェクト・コンテキストはリセット済み。ツールの自動学習・履歴参照は不使用
  4. 評価の性質：著者の主観に基づく定性評価 + 定量指標の併用。比較日時：2025/09/05
  5. 表記簡略：以降、Claude Opus 4.1 → Claude、codex-1(high) → codex と記載
  6. 配点：35点満点（プロセス5 + 定量5 + 定性25（5項目×各5））

📦 リポジトリ

🔍 補足: エージェントの実装アプローチや設計の"癖"が見えるので、リポジトリのcommit履歴もぜひご覧ください

🌐 Live Demo

⚡ 結果ハイライト

総合スコア（35点満点）

  • Claude: 4.5 / 5（プロセス）+ 4.0 / 5（定量）+ 21.0 / 25（定性）= 29.5 / 35（≈ 84.3%）
  • codex: 3.5 / 5（プロセス）+ 4.5 / 5（定量）+ 20.0 / 25（定性）= 28.0 / 35（≈ 80.0%）

総合判定: 僅差で Claude Win

ユースケース別推奨

用途 推奨 理由
PoC/デモ どちらでも可 Claude: 仕上がりの整い / codex: 体験の細部配慮
本番運用 Claude 運用・ドキュメント面がやや上回る
OSS公開 Claude 引き継ぎ容易性・運用ドキュメント
学習教材 拮抗 設計意図の明快さ（Claude）とUX配慮（codex）で好み分かれる

📊 評価方法と採点基準

  • 5点: 本稿スコープでの高品質な検証水準
  • 4点: 実用的だが軽微な改善余地あり
  • 3点: 基本機能は動作するが、重要な考慮事項に欠ける
  • 2点: 動作するが品質に課題あり
  • 1点: 最低限の実装

⚙️ プロセス評価

評価項目 Claude codex
指示回数 3回 5回
指示内容 複雑な要件（重複投票防止含む）を一度で理解 基本実装→対話でUX改善を段階適用
エラーの種類 軽微なViewのtypo 1件 投票ロジックのバグ 1件、集計最適化の詰め不足
修正の容易さ 「修正して」で自己解決 具体的な修正方針の指示が必要
プロセススコア 4.5 / 5 3.5 / 5

📈 定量評価

指標 Claude codex 測定方法/ツール
コード行数（Model+Ctrl） 152行 168行 wc -l
テストカバレッジ（推定） ~90% ~70% テスト構成の目視推定
N+1/集計最適化 手動更新（callbacks） ✅ counter_cache コードレビュー
パフォーマンス 概ね同等 概ね同等 簡易負荷・SQL観察
実装時間（推定） 45分 40分 commit履歴
定量スコア 4.0/5 4.5/5 -

🎯 定性評価

1. Controller + Model層（重複投票防止/カウンタ最適化）— Draw (Claude 4.0点 / codex 4.0点)

1-1. 重複投票防止アーキテクチャ

観点 Claude codex
重複チェック Controller側で事前チェック Model層バリデーション＋DB例外
voter_hash生成 UUID保持＋IP+UA+秘密鍵の複合 シンプルなIP+UA+秘密鍵
Cookie戦略 永続的なvoter_id保存 Poll別の投票済みフラグ

Claude - 防御的プログラミング型

# app/controllers/votes_controller.rb:9-11
if voter_hash.present? && @poll.votes.exists?(voter_hash: voter_hash)
  redirect_to @poll, alert: "このアンケートには既に投票済みです。"
  return
end

# app/controllers/votes_controller.rb:40-41
voter_id = cookies.signed[:voter_id] || SecureRandom.uuid

codex - Rails Way準拠型

# app/models/vote.rb:9
validates :voter_hash, uniqueness: { scope: :poll_id }, if: -> { voter_hash.present? }

# app/controllers/votes_controller.rb:23-24
rescue ActiveRecord::RecordNotUnique
  redirect_to @poll, alert: "同一環境からは重複投票できません。"

1-2. カウンタ最適化

Claude

# app/models/vote.rb:9-10, 24-29
after_create :increment_votes_count
after_destroy :decrement_votes_count

def increment_votes_count
  choice.increment!(:votes_count)
end

codex

# app/models/vote.rb:3
belongs_to :choice, counter_cache: true  # 自動集計でN+1/集計コストを抑制

1-3. 総合評価

長所と短所

Claude codex
✅ 事前チェックでDB負荷軽減 ✅ Rails標準アーキテクチャ準拠
✅ UUID個体識別で精度向上 ✅ Model層で完結する堅牢設計
❌ Controller責務集中 ✅ counter_cacheで最適化
❌ voter_hash生成が複雑 ❌ DB例外依存（レアケース）

判定: Draw - アプローチは異なるが、どちらも実用的で合理的な実装

2. View/UX — codex Win (Claude 4.0点 / codex 4.5点)

2-1. 視覚デザイン

  • Claude: 余白・階層構造が整理され情報の優先度が明確
  • codex: ミニマルだが、送信体験の配慮が丁寧

2-2. 操作フィードバック

Claude

<!-- 基本的なフィードバックのみ -->
<%= f.submit "投票する", 
    class: "w-full px-6 py-3 bg-indigo-600 text-white..." %>

codex

<!-- app/views/polls/show.html.erb:42 送信中ラベルの変化 -->
<%= submit_tag "投票する", 
    class: "inline-flex items-center...", 
    data: { turbo_submits_with: "送信中..." } %>

2-3. 総合評価

長所と短所

Claude codex
✅ 余白・階層構造が整理されている ✅ 送信中フィードバックの実装
✅ 情報の優先度が視覚的に明確 ✅ ミニマルで必要十分なUI
❌ インタラクティブ要素が基本的 ✅ ユーザー体験への細かい配慮
❌ 送信中フィードバックなし ❌ デザインの階層性がやや弱い

判定: codex Win（送信中フィードバックなどUX配慮が優秀）

3. Test — Claude Win (Claude 4.5点 / codex 3.5点)

Claude

# test/models/vote_test.rb:27-31
test "should not allow duplicate votes with same voter_hash" do
  Vote.create!(poll: @poll, choice: @choice, voter_hash: "duplicate_hash")
  duplicate_vote = Vote.new(poll: @poll, choice: @choice, voter_hash: "duplicate_hash")
  assert_not duplicate_vote.save
  assert duplicate_vote.errors[:poll_id].any?
end

# 他にも48-59行目でカウンタ増減テスト、35-37行目でnull許容テストなど

codex

# test/models/vote_test.rb:19-25
test "voter_hash uniqueness scoped to poll" do
  poll = Poll.create!(title: "open", status: :open)
  c = poll.choices.create!(label: "A")
  vhash = "abc123"
  Vote.create!(poll: poll, choice: c, voter_hash: vhash)
  dup = Vote.new(poll: poll, choice: c, voter_hash: vhash)
  assert_not dup.valid?
end
# ※ エッジケースのテストが不足

3-3. 総合評価

長所と短所

Claude codex
✅ 境界値・異常系のテストが充実 ✅ シンプルで理解しやすいテスト
✅ null許容・カウンタ増減もカバー ✅ counter_cacheの動作確認
✅ エラーメッセージの検証も実施 ❌ エッジケースのカバレッジ不足
❌ やや冗長なテストコード ❌ エラーメッセージの検証なし

判定: Claude Win（テストカバレッジと品質保証の観点で優位）

4. Docs/運用 — Claude Win (Claude 4.5点 / codex 4.0点)

  • Claude は運用項目の掘り下げがやや多く、引き継ぎ容易性が高い

5. 保守性 — Draw (Claude 4.0点 / codex 4.0点)

  • Railsの規約準拠・命名・責務分離は概ね良好

🔄 評価手法の特徴

  1. 定量指標の併用：パフォーマンス／セキュリティ／品質の数値化
  2. プロセス評価：開発効率や指示理解度を加点
  3. 採点基準の明文化：点数の意味を定義
  4. ユースケース別推奨：状況に応じた選択指針

残る課題

  • 実計測（P95レスポンス、SQL回数、メモリ）の継続取得
  • 複数評価者による客観性向上
  • 長期保守（数週間～）での変更容易性・欠陥率の追跡

🔚 結論

総合評価：僅差で Claude Win（29.5 vs 28.0）
counter_cache を採った codex の定量面が上振れし、Claude の運用面・テスト面が優位という構図

  • 用途次第：守り重視なら Claude、迅速な体験調整やUIの細部配慮は codex
  • 両者とも実用圏：基本要件は満たす

✍️ あとがき

最近 Claude Code から codex へ乗り換える人を散見したので、カウンターとしての検証目的でしたが...
ふたを開けると小規模ではほぼ変わらずでした。
課金する AI Agent を無理に固定せず、常に最新情報をキャッチして、利用場面・最新動向・コストを軸に適時再評価し、最適なものへ切り替える（現時点の私見） 必要がありそうという着地でしょうか。

結論としてはありきたりですし、それ自体はどんなツールでも同じなんですが、AI Agent 周りは特に進化のスピードが段違い。
「暇があったら調べる」では追いつけないので、定期的にキャッチアップ時間を予定に入れるくらいでちょうどいいかもしれません。

...と、ここまで偉そうに書いたものの、私はすでに色んな AI Agent に課金しすぎて、財布の方が先に限界を迎えそうです。

脚注

  1. 📝 補遺：本記事は著者が Gemini 2.5 Pro と協力し、中立性に配慮して作成しています ↩︎

  2. 大規模なコードベースでの比較事例をご存知の方がいれば、ぜひ教えてください😸 ↩︎

Discussion