はじめに
Claude CodeもCodexも、今は「これ実装して」でしっかり動くものを出してきます。実装の仕方に差異はあれど目標には到達する。この記事はそこを競う記事ではありません。
同じお題を両方のAIに投げて、実装力ではなく何が違うのかを探った記録です。
結論から言うと、推測通り実装自体はそれぞれクリアしました。
差が出たのは、曖昧な設計判断をどちらに倒すかと、同じ丁寧さに到達するまでのコストでした。
これは2026/8/19時点での記事になります。
モデルは日進月歩なので、この記事の傾向が数ヶ月後も同じとは限りません。
検証環境
| 項目 | 値 |
|---|---|
| Node.js / npm | v24.12.0 / 11.6.2 |
| hono / @hono/node-server | 4.13.3 / 2.1.1 |
| vitest / typescript / tsx | 4.1.10 / 7.0.2 / 4.23.12 |
| Claude Code | 2.1.226（モデル: Claude Opus 5） |
| Codex CLI | 0.147.0（モデル: gpt-5.6-sol） |
検証用リポジトリ
Hono + TypeScript + Vitest の簡単なユーザー管理APIです。
npm ci した時点で 16件中3件がテスト失敗する状態からスタートします。
各お題の前に必ず git reset --hard && git clean -fd で初期状態へ戻し、違うセッションで同じお題をツールごとに3回ずつ実行しました。
LLMの出力は毎回ブレるため、1回きりで断定にしないためです。文面でのヒントは渡さず、それぞれ一言だけです。
同じお題を投げてみた
お題1: バグ修正
npm test を実行すると3件失敗します。原因を調べて修正してください。
原因は src/lib/validators.ts の isLengthInRange。
docコメントには「min/maxはちょうどその値でも有効」とあるのに、実装は境界値ちょうどを弾く不等号になっていました。
よくありがちなミス。
/**
* @param min 最小文字数（この値ちょうどは有効）
* @param max 最大文字数（この値ちょうどは有効）
*/
export function isLengthInRange(value: string, min: number, max: number): boolean {
const length = [...value].length;
- return length > min && length < max;
+ return length >= min && length <= max;
}
修正はこの1行だけです。
結果: Claude Code 3/3・Codex 3/3、全員が根本原因を正しく修正
所要時間・探索力にも有意な差はありませんでした（平均でClaude Codeが約45秒、Codexが約42秒）。
お題2: 既存コードへの機能追加
PATCH /users/:id を追加してください。displayName と bio を更新できるようにしてください。
このリポジトリには、型では強制されない暗黙のルールが8個仕込んであります。
「バリデーションはservice層でやる」
「エラーはAppErrorをthrowする」
「ログのイベント名はlayer.entity.action形式」
「依存パッケージを追加しない」
など、コードを読めば分かるけれどtscは怒ってくれないルールです。
よくある規約までではないけどお作法的なやつです。
結果: 8項目とも、両ツール6試行すべてが構造的にクリア。 差は作法遵守ではなく、その先にありました。
PATCH実装後、全員がお題1のバグ（テスト3件が落ちている状態）に気づきます。ここまでは仕込んだ通りですが、両ツールとも3/3、頼まれていないのに実際に直しました。 Claude Codeは1回でcreate/update間の検証ロジックをDRYリファクタし、別の1回は実際にnpm run devでサーバーを起動してcurlで動作確認までしていました。Codexも2/3でREADMEの更新まで自発的にやっていました。
お題3: 曖昧な依頼
ユーザー検索機能をつけてください。
検索対象はdisplayNameだけかemailも含むか、大文字小文字を区別するか——何も決めていません。
結果: 6/6、全員が「聞かずに、妥当な仮定を選んで実装し、その仮定を最終報告で明示する」 という同じ挙動になりました。既存バグへの対応もここでも6/6が「実際に直す」で揃いました。
その代わり、エンドポイントの設計そのものに好みの違いが出ました。
| エンドポイント設計 | |
|---|---|
| Claude Code（3/3） |
GET /users/search?q= という新しいエンドポイントを新設
|
| Codex（3/3） | 既存の GET /users に ?q= を追加 |
Codexは3/3とも既存エンドポイントの拡張を採用。
対してClaude Codeは3/3とも新しいエンドポイントの新設という正反対の設計を選びました。
また、Claude CodeはHonoの/searchを/:idより先に登録しないとid=searchと誤解釈されるという罠に自力で気づき、回帰テストまで書いていました。
実際のdiffを並べると、この差は一目でわかります。
Codex（既存拡張）
usersRoute.get('/', (c) => {
- return c.json({ users: userService.list() });
+ const query = c.req.query('q');
+ const users = query === undefined ? userService.list() : userService.search(query);
+ return c.json({ users });
});
Claude Code（新規エンドポイント。ページングまで追加している）
+// `/:id` より先に登録する（後にすると `/users/search` が id として解釈される）。
+usersRoute.get('/search', (c) => {
+ try {
+ return c.json(
+ userService.search({
+ q: c.req.query('q'),
+ limit: c.req.query('limit'),
+ offset: c.req.query('offset'),
+ }),
+ );
+ } catch (error) {
+ return toErrorResponse(c, error);
+ }
+});
+
usersRoute.get('/:id', (c) => {
Codexは既存の3行を書き換えるだけ。
Claude Codeは新しいハンドラを丸ごと足し、ページングやルート順序への配慮まで盛り込んでいます。
これは結構な差を感じます。
差が出たのは「実装力」ではなく「設計の踏み込み方」と「コスト」
実装の正確さも規約遵守も、頼まれていない問題への対応も、ほぼ互角でした。
はっきり残った差は2つです。
1. 曖昧な設計判断での好み
Codexは既存の構造を拡張する保守派、Claude Codeはゼロベースで設計し直すことを厭わない刷新派。この傾向は3/3ずつ、一度もブレずに完全再現しました。
2. 所要時間
お題2・3（計6試行ずつ）の所要時間は、Claude Codeが137〜531秒、Codexが72〜91秒。分布はまったく重なっていません。 どのお題・どの試行を切り取っても、Claude Codeの最速はCodexの最遅より遅い。平均でも約3倍、最大では6倍の開きです。
内訳を見ると、単純に考える時間が長いわけではなく、実行したアクション数自体もClaude Codeの方が多め（平均29回 vs Codexの平均18回）でした。中には実際にnpm run devでサーバーを起動してcurlで動作確認するところまでやっていた試行もあり、その分の実時間が乗っています。
トークン数は集計方法（キャッシュ扱いなど）がツール間で違いすぎるため、単純比較していません。時間だけを比較指標にしています。
シーン別の使い分け
- 既存のAPI構造・後方互換性を守りたい: Codex。曖昧な要件でも既存の形を拡張する方向に倒してくれる
- 設計から見直してでも綺麗にしてほしい、時間はかかってもいい: Claude Code
- レビューを素早く回したい: Codex。同程度の丁寧さに、より短時間で到達する
- バグ修正・既存規約への追従が中心の作業: どちらでもよい。明確な差はなし。
まとめ
Claude Code・Codexのフラッグシップ同士で3つのお題を3回ずつ、計18試行実行した結果です。
| 観点 | Codex | Claude Code |
|---|---|---|
| 実装の正確さ（お題1） | ○ 3/3 | ○ 3/3 |
| 既存規約への追従（お題2・8項目） | ○ 3/3 | ○ 3/3 |
| 頼まれていない問題を直すか | ○ 3/3 | ○ 3/3 |
| 曖昧な設計判断 | 既存拡張（保守派） | 新規設計もいとわない（刷新派） |
| 所要時間（お題2・3平均） | 約84秒 | 約249秒（約3倍） |
実装力・規約遵守・頼まれていない問題への対応はほぼ互角。残った差は「曖昧な設計判断をどちらに倒すか」と「所要時間」の2つでした。