この記事は何か
私は現在、個人開発(というか日曜大工?)にはCursorを使っているのですが、やっぱり世の中Claude CodeとOpenAI Codexが全盛で、どちらかに移った方がいいのかなぁ、と思わされる日々です。
で、移るならどちらに、という問題になるわけですが1、その判断材料を得るために、両方に同じ指示を出してアプリを作らせ、どのような違いが出るか比較してみました。
まあ、何番煎じかよくわからないし、数か月後には結果も変わって意味なくなるのでは、という気もするのですが、ある程度長期的に変わらなそうな、両者の性格みたいなものも見えているので、記事にしてみます。
なお、完成したアプリやソース、開発時のAIとの会話履歴は、全て公開しています2。
以下のような問題集アプリが、ほとんどプロンプト一発で作成できますので、興味のある方はご自分でも作成・比較してみてください。
比較結果のサマリ
比較結果のサマリは、以下の通りです。
前提は、月額$20のプランで、Sonnet 5.5または GPT-6.1 Solを使用することです。
(詳細は次章「比較の方法」参照)
| No | 観点 | Claude Code | Codex |
|---|---|---|---|
| 1 | UI/UXの設計 | ◎ | ○ |
| 2 | リポジトリの構成管理 | ◎ | ○ |
| 3 | 解説の品質3 | - | - |
| 4 | 利用枠の消費(燃費) | × | ○ |
| 5 | プログラムソース | ◎ | ○ |
| 6 | テスト・バリデーション | ○ | ◎ |
結論、今回の前提で比較結果だけを見るなら、Codex一択になります。もしくは、前提を緩めて、より高額なプランでClaude Codeを採用するか。
全体的に、Claude Codeの方が優秀なのですが、燃費がそれを覆す、という感じです。
また、比較表には表現しづらいのですが、一緒にものづくりをやってくれる開発者が欲しいならCodex、可能な限り丸投げで勝手に完成品を作ってきてほしいならClaude Code、という選び方もありそうです。
次章以降、比較の方法と、各観点について詳細を記載します。
比較の方法
同じ課題・同じ指示で、IPAの「プロジェクトマネージャ試験」のA-2(午前Ⅱ)の過去問アプリを作成させ、その結果を比較しています。
前提として、すでに作成済みの「システムアーキテクト試験」のアプリ4を参照させています。詳細な仕様を、文書としてではなく、完成アプリのリポジトリの形で見せている、と捉えてください。で、これをベースにプロマネ版を作れ、と指示している感じです5。
AIへの指示
以下のリポジトリの資産を参考に、情報処理技術者試験のプロジェクトマネージャの午前Ⅱの試験に対して、同様のアプリを作成してください。
https://github.com/rabut001/system-arch-trainingいきなり作業に入らず、まず進め方を検討し、結果を私に提示してください。
検討に当たり確認等あれば、まず私に質問してください。UIについては、基本的に、参照元のアプリを引き継ぐ前提としてください。
ただし、アプリの基本構造・概念を変えることなく、大幅にUI/UXの改善が可能な案があるなら、提案してください。歓迎します。IPAが公開している過去問から問題を抽出し、解説を作成する部分も作業に含めてください。
リポジトリの構成については、参照元を引き継ぐ必要はありません。
2026年10月時点のベストプラクティス等を参考に、最適なものを提案してください。リリース後の改修作業についても、リポジトリの構成に含めてください。
参照元のspecsフォルダ配下の考え方に相当するものを、リポジトリの構成に含めてほしい、という意味です。全体を通して、アプリの規模感に見合った提案をお願いします。
小さなアプリですので、シンプルに最低限のことができればよい、という前提でお願いします。
また、比較の環境は以下です。
| Claude Code | Codex | |
|---|---|---|
| モデル | Sonnet 5.5 | GPT-6.1 Sol |
| モード | high | high |
| GUI | Claude Desktop(Windows版) | ChatGPT desktop app |
前提として、料金プランは、Claude CodeならProプラン、CodexならChatGPT Plusプラン(いずれも、2026年10月現在、月額$20)を想定しています。
このため、追加の従量課金を前提とせず、現実的に継続利用できるモデルとして、Sonnet 5.5とGPT-6.1 Solを比較しています。FableはProでは追加料金が必要6で、AstraはPlusに含まれるもののSolより利用枠の消費が大きい7ためです。
また、参考としてAPI料金を比較すると、2026年10月現在、トークンあたりの料金は以下の通りです。いずれも同一料金で、価格帯としても条件がそろっているかと思います。89
| 100万トークンあたり | Sonnet 5.5 | GPT-6.1 Sol |
|---|---|---|
| 入力 | $2 | $2 |
| キャッシュ読み取り | $0.10 | $0.10 |
| 出力 | $10 | $10 |
なお、GUIはWindowsの端末で起動していますが、AIの処理はWSL2上のLinux(Ubuntu)で流しています。単純にWindows上でやっても、結果にあまり影響はないと思いますが、一応。
比較結果の詳細
比較結果のサマリについては冒頭に記載しています。
以下、詳細を順に解説します。
比較1 - UI/UXの設計
以下の指示に対してAIが行った改善の結果比較です。
UIについては、基本的に、参照元のアプリを引き継ぐ前提としてください。
ただし、アプリの基本構造・概念を変えることなく、大幅にUI/UXの改善が可能な案があるなら、提案してください。歓迎します。
結果は、明確にClaude Codeがよいです。
以下、それぞれの作成したアプリへのリンクを貼りますので、もしよければ起動して、実際に問題を解いてみてください。
- Claude Code
- Codex
とりあえず、Claude Codeの方は、そっけないUIですが、その代わり操作に迷わないはず。
一方、CodexのUIは、機能も多くて凝っているのですが、特に携帯の小さい画面で微妙。
多分、1問目を解き終わった後「あれ?どうやって次の問題に進むんだ?」となるはず。
ユーザの基本動作は、以下の流れなのに
問題を読む ⇒ 自身の回答を選択 ⇒ (結果・解説を確認) ⇒ 次の問題へ
UIのパーツの配置が、以下になってしまっている。
問題 ⇒ 次の問題へボタン ⇒ 回答選択ボタン ⇒ 結果を確認ボタン
この「画面上にたくさんの機能があるんだけど、基本動作に沿っていなくて操作に迷う」というのは開発者が陥りがちな罠10で、これを見ても、Codexは雑な開発者っぽい。で、Claude Codeは、そつがない優等生という感じ。
比較2 - リポジトリの構成管理
以下の指示に対して、AIがどのようにリポジトリを構成したか。
リポジトリの構成については、参照元を引き継ぐ必要はありません。
2026年10月時点のベストプラクティス等を参考に、最適なものを提案してください。
これも明確に、Claude Codeの方がきれいです。
以下にリポジトリへのリンクを貼りますが、ルート直下を見るだけでも、Claude CodeがWebアプリ(appフォルダ)とそれ以外を明確に分けているのに対し、Codexは全部ばら撒いている。
- Claude Code
- Codex
ただ、Codexの構成が問題かというと、そんなことはないのですよね。この規模のアプリなら、これで十分だと思うし、ある意味では分かりやすいのですよね、開発者にとっては11。
やっぱりCodexは開発者っぽいんですよね。いや別にこれでよくね?とか言ってそう。
そして、Claude Codeはやっぱり優等生っぽい。
比較3 - 解説の品質
IPAが公開している過去問PDFには、問題に対する解説がついていないので、AIに生成させています。その品質の比較。指示としては以下。
IPAが公開している過去問から問題を抽出し、解説を作成する部分も作業に含めてください。
実は、このアプリの作成で一番利用枠を消費するのはここなので、しっかり比較してみたかったのですが、単純には比較できない状況になってしまいました。
解説自体の品質が良い(わかりやすい)のはCodexですが、これは解説を選択肢ごとに分割した効果です。副作用として必要な表示面積が増え、問題と解説が一画面に納まらなくなっています。
この副作用は無視できず、解説の比較は無効とします…。
- 問題の例
JIS Q 21500:2018(プロジェクトマネジメントの手引)によれば,プロジェクトガバナンスを維持する責任は誰にあるか。
ア: プロジェクトの管理面でプロジェクトマネージャを支援するプロジェクトマネジメントチーム
イ: プロジェクトの計画から終結までのプロセスを指揮するプロジェクトマネージャ
ウ: プロジェクトの要求事項を明確にし,プロジェクトの成果を享受する顧客
エ: プロジェクトを許可し,経営的決定を下すプロジェクトスポンサ,又は上級レベルでの指導を行うプロジェクト運営委員会
- Claude Codeの解説例
- Codexの解説例
比較4 - 利用枠の消費(燃費)
これは、圧倒的にCodexが優れます。
今回の作業では、Claude Codeは完成までに2回利用上限(5時間枠)に到達しました。一方、Codexは5時間枠を9割程度の消費で完走しています。
Claude Codeについては、子エージェントを大量に走らせているときに上限を踏んで、全部やり直しになったという不幸はありましたが、それを差し引いても、最低1回は上限に到達し、5時間枠をおおむね2回使い切ると思われます。
つまり、Claude Codeの枠消費は、Codexの約2倍~3倍ということになります。ヤバイ。
日曜大工とはいえ、この規模の作業を投げることはあるので、5時間枠を踏んでしまうのは痛いです。作業が土日で終わらなくなってしまう。
個人的には、これだけで、Claude Codeは選択肢から外れました。
実際の開発でこれをやられたら、多分、誘惑にあらがえずガンガン追加金することになる…。
比較5 - プログラムソース
これは、Claude Codeに軍配が上がります。
例えばWebアプリで、Claude Codeが年度選択の画面と回答画面を無難に分けている(ExamList.tsxとPractice.tsx)のに対して、Codexは一つのファイル(App.tsx)に全投入しています。
Claude Codeは丁寧な印象。そしてCodexは雑。
以下にソースへのリンクを貼っておくので、必要に応じて各自で参照してみてください。
Claude Code
- Webアプリ
- 過去問PDFからのデータ抽出
Codex
- Webアプリ
- 過去問PDFからのデータ抽出
比較6 - テスト・バリデーション
CIを中心としたテスト・バリデーションの比較です。
結論、ここはCodexの方がしっかり準備しています。
ずっと雑だと思っていたのに、突然どうした、Codex。
まず、Claude Code・Codex共通でチェックしているのは以下。
- アプリの基本ロジック(回答の保存など。単体テストに相当)
- 問題・回答の整合性(問題数や、問題と解答の対応など)
これに加えて、Codexは以下のチェックを行っています。
- ブラウザテスト(Playwright。E2Eテストに相当)
- IPA公開サイトの過去問PDFに変更が無いか(ハッシュ突合)12
特に、ブラウザテスト(E2E)については、PC・スマホ両方で計44件を実施しており、この規模のアプリにはかなりオーバースペックな気もします。
あれですかね。テストで手を抜くと刺される環境で育てられたのかな、Codex。
反対にClaude Codeですが、E2Eテストは「人が Playwright(ヘッドレス Chromium)や実機で埋めます」とバッサリ13。(後続の「Claude Codeの回答」参照)
テストで手を抜くのが怖いCodexと、自身の判断に自信があるClaude Code。
やっぱり前者は開発者っぽいし、後者はまだ開発に染まり切っていない優秀な若い子、という感じがします。そうでもないですかね。
なお、参考に、AIに「このリポジトリのテスト・バリデーションの考え方を説明して」とお願いした結果も貼っておきます14。
Claude Codeの回答
このリポジトリの検証は3層に分かれています。データの整合は Python のスクリプト、進捗ロジックは Vitest、画面は人が見る確認表です。CI は最初の2層に、型検査とビルドを加えた4つを呼びます。画面の確認表は CI に入っていません。
考え方
- データの検証は機械で行います。 正解は IPA の解答例 PDF から取り、JSON の answer と突き合わせます。問題冊子や解答例の PDF は sources/ にコミットされているので、CI でも照合できます。
- 進捗のロジックは、画面から切り離した純粋な関数にして単体テストします。 規則は app/src/progress.ts にあります。
- 画面は E2E テストを置きません。 specs/ の確認表を、人が Playwright(ヘッドレス Chromium)や実機で埋めます。
- 解説の質は自動検証できません。 作成者とレビュー担当を分ける運用で担保します。specs/0001-initial-content/status/*.json の state(未着手、作成済み、要見直し、確認済み)で管理します。観点は specs/0001-initial-content/README.md にあります。
| 種類 | 場所 | 見るもの | 件数 | CI で呼ばれるか |
|---|---|---|---|---|
| データ検証 | scripts/validate_content.py | 骨組み、--complete の項目、exams.json
|
17回・424問(問ごとの検査) | 呼ばれる(--complete) |
| 型検査 | npm run typecheck |
TypeScript の型 | 件数なし | 呼ばれる |
| 単体テスト | app/src/progress.test.ts(Vitest) | 進捗の保存と復元、一括採点、クリア、チェック、正解率 | 13件(8グループ) | 呼ばれる(npm test) |
| ビルド | npm run build |
ビルドが通ること | 件数なし | 呼ばれる |
| 画面の確認表 | specs/0002-initial-app/README.md | 画面と操作 | 18項目(17項目が済み、1項目が未完了) | 呼ばれない(手動) |
| 解説のレビュー | specs/0001-initial-content/status/ | 問題文と解説の質 | 17ファイル・424問 | 呼ばれない(人が行う) |
Codexの回答
このリポジトリは、問題データの正確さ、採点・保存のロジック、ブラウザでの操作をそれぞれ検証し、画像・解説の内容は別工程でレビューする考え方です。作成・保守手順 にも、自動検証は画像や解説の意味の確認を代替しない、と明記されています。
用意されている検証と、CIからの呼び出しは次のとおりです。「通常CI」は Check、「公開時」は Deploy to GitHub Pages を指します。
| 検証 | テスト件数・検証対象数 | 処理が書かれているファイル | 通常CI | 公開時 |
|---|---|---|---|---|
| 原本取得・ハッシュ検証 | PDF 34ファイル | fetch-sources.py | 実行 | 実行 |
| 公式解答との照合 | 425問 | verify-sources.py、official_answers.py | 実行 | 実行 |
| データ検証 | 17回・425問・425画像 | validate-data.mjs | 実行 | 実行 |
| データ読込の単体テスト | 4件 | exam.test.ts | 実行 | 実行 |
| 採点・保存・絞り込み等の単体テスト | 15件 | progress.test.ts | 実行 | 実行 |
| 型検査・本番ビルド | テストケース数なし | package.json、tsconfig.json、vite.config.ts | 実行 | 実行 |
| ブラウザテスト | 44件:22ケース×PC/スマホ | practice.spec.ts、playwright.config.ts | 実行 | 実行 |
公開条件検証 --release
|
17回・425問・425件の照合記録 | validate-data.mjs | 実行しない | 実行 |
| 画像・解説の内容レビュー | 425問が対象 | 手作業。確認手順・照合記録 | 自動実行しない | 照合済み記録を検査 |
AIとの会話履歴
今回の比較で行ったAIとの会話履歴は、以下にあります。指示に対する具体的な応答がみたい、などあれば、こちらをご参照ください。
例えば、アプリの作成指示に対する初回の応答ですが、Codexは、まず確認質問を3つ返し、回答を受けてから計画を考えています。一方Claude Codeは、先に参照元とIPAのサイトを調べ、調査結果・計画・確認事項6項目(すべて既定案付き)を一度に出してきています。
Codexは「まず聞いてから考える」感じですが、Claude Codeは「まず自分で調べ尽くして、自分で判断できるものは埋めてから、決めるべきことだけ聞く」という感じの挙動をしています。
- Claude Code
- Codex
所感など
ということで、Claude CodeとCodexの比較でした。
プロンプト一発での比較なので、いろいろ限界はあると思うのですが、とりあえず。
結論、個人開発の日曜大工(月額$20の枠内)ならCodex一択という感想。
「比較4 - 利用枠の消費(燃費)」でも書きましたが、Claude Codeだと、土日しか作業できないのにリミット踏んで、追課金している未来しか見えない。
反対に、仕事で使うなら(高額なプランが使用できるなら)、Claude Code一択な気がします。
今回の比較だけからいえば、思ったより性能差がある。
Maxプラン等でも、仕事なら簡単に元を取れるでしょうし。
ただ、この記事全体からにじみ出ていると思うのですが、個人的には、Codexの方が肌に合いました。やっぱり、なんか、開発者っぽい。
気持ちがわかる、とはちょっと違うのですが、まあ、こういう指示出されたら、そこは雑に片づけちゃうよね、とか、なんとなくわかりやすい。
反対に、テストのところで少し触れましたが、Claude Codeは、自身の判断を信じて最後まで突き進む感じ。
結果、いきなり完成品を出してくれるのですが、その裏で、実は理解負債が大きい、という印象。なぜそう判断したかを、丁寧に確認していく必要がある。
例えば、E2Eテストが無い理由。今回に関して言えば、参照元リポジトリの「画面は確認表で見る」方針を引き継いだことが理由で、必要なら足せばよいだけだが、その経緯がドキュメントからは追えない。E2Eテストを足すなら、リポジトリ全体を確認して、足して問題ないよな、という判断を行う必要がある。
ザックリまとめると、名前通りコーダーとして役割を期待されているCodexと、課題全体を丸投げされた上で解決することを期待されているClaude Code、のような違いを感じます。
というか、Claude Codeは、開発者なんか不要、ビジネス(要件)の話をしてくれればコードは考えなくていいよ、こっちでやるから、という方向性な気がする。E2Eテストがどうとか、いちいち人間が考えるなよ、的な。
まあ、ビジネスとしてはそちらが正しい気はしますが、エンジニアとしては少し寂しい感じもします。
あと、記事の本題ではないので触れなかったのですが、何気にCursorのコスパ高いかも。Claude CodeはもちろんCodexも、リミットがこんなに低いとは思わなかった。
土日に集中して作業する前提なら、月のトークン総量しか見ないCursorのプランの方が、圧倒的に使いやすい。
さて、どうしようかなぁ。
-
ぶっちゃけ、両方契約して用途に応じて使い分けるのが、2026年10月現在のベストプラクティスっぽいのですが、そんなにお金払う気にもならず…。 ↩
-
各章にも記載していますが、以下の通りです。
アプリ: Claude Code / Codex
ソース: Claude Code / Codex
会話履歴: Claude Code / Codex ↩ -
過去問アプリで、各設問に対して作成した解説の品質。作成方針が大きく異なり単純比較できないため評価対象外。詳細は「比較3 - 解説の品質」参照。 ↩
-
こちらはCursorで作成したもの。もともと公開(記事にする)つもりもなく、個人用に作ったアプリなので、いろいろ適当なのは見逃してください。 ↩
-
指示に「全体を通して、アプリの規模感に見合った提案をお願いします。小さなアプリですので、シンプルに最低限のことができればよい、という前提でお願いします」という内容が含まれており、後述の、Codexの雑な対応や、Claude Codeがテストをバッサリ切っている点は、この指示に沿ったもの、つまり、評価すべき点と捉えることもできるかもしれません。しかし、本記事では、単純に成果物の完成度だけをみて評価を行っています。この文を外して結果がどう変わるかも試してみると面白いかもしれません。 ↩
-
https://support.claude.com/ja/articles/15424964-%E3%81%82%E3%81%AA%E3%81%9F%E3%81%AE%E3%83%97%E3%83%A9%E3%83%B3%E3%81%A7%E3%81%AEclaude-fable%E3%83%A2%E3%83%87%E3%83%AB ↩
-
https://help.openai.com/ja-jp/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex ↩
-
https://platform.claude.com/docs/ja/models/sonnet-5-5/overview ↩
-
Codexの画面を見ていると、なんか、共感性羞恥が沸き起こる…。俺もいっぱいやったよ、こういうの。うぅ…。 ↩
-
とはいえ、せっかくtestsフォルダ作っているのに、Webアプリのテストしか入れていない点は気になる。scriptsフォルダ配下の資産のテスト・バリデーションが当該フォルダに残ったまま。まあ、厳密には、テストとバリデーションは違うので、これはこれで正解なのでしょうが。 ↩
-
CodexはリポジトリにIPAの過去問PDFを置かない構成であるため、問題・回答の整合性チェックのために、毎回、IPAのサイトからPDFを落としなおしてチェックを実施しています。これは、その前段の確認処理で、本質的には、Claude Codeも行っている、問題・回答の整合性チェックの一部です。 ↩
-
最初にリポジトリの構成を検討した際に、参照元と同様に「画面は確認表で見る」方針を引き継ぎ、E2Eテストは作らないとしている。しかし、現在のリポジトリ内のドキュメントには、経緯は残っておらず、AGENTS.mdに「画面は E2E テストを置かず、specs/ の確認表で見る」という記載があるだけ。それでも、自信満々。
なお、確認表の多くは、実際にはClaude Code自身がPlaywrightで確認して埋めています。テストコードとしては残さず、1回確認して記録すれば十分、という判断のようです。 ↩ -
Claude CodeとCodexで問題の総数(前者は424問、後者は425問)が異なりますが、これは、過去問に無効な問題(平成28年度春期の問2)があるためです。Claude Codeはこの問題を、アプリから完全に除外しています(表示もされない)。一方、Codexは問題の表示だけはさせた上で、採点対象から除外する、という実装を行っています。このため、Claude Codeの方が、1件少ないカウントになっています。 ↩



