AIコーディングツールの比較は、たいていコード生成の精度で語られます。しかし実際の制作現場で効くのは、ブラウザ確認・画像生成・タスクの並列化まで、どこまで1つの場所で完結するかです。
この検証では、2026年4月のアップデート後のCodex Desktopを2週間使い込み、Claude Codeとの住み分けを確定させました。LP制作は従来の3日から1日、FV1本は半日から1時間以内という結果です。
この検証の概要
| 項目 | 内容 |
|---|---|
| 検証期間 | 2026年4月16日〜4月28日 |
| 対象 | Codex Desktop（OpenAI）／2026年4月アップデート後 |
| 比較対象 | Claude Code / Claude Design |
| 対象領域 | コーディング／LP・Webサイト制作／デザインモック・ラフ案 |
| 結論 | コーディング・LP・デザインモック領域はCodexを採用。大規模コードベース・長文推論はClaude継続 |
本記事は自社での検証記録です。所要時間は実案件での実績値および体感値を含みます。
結論：領域ごとに使い分ける
| 領域 | 採用ツール | 理由 |
|---|---|---|
| コーディング全般 | Codex | 並列エージェント + GPT-5.5 |
| LP・Webサイト制作 | Codex | In-appブラウザでブラウザ内コメント修正 |
| デザインモック・ラフ案 | Codex | 画像生成とコードが同一画面で完結 |
| 長文ドキュメント・深い推論 | Claude | コンテキスト長・推論品質で依然優位 |
判断のフローに落とすとこうなります。
ターミナル操作が主体 → Claude Code
ブラウザ確認 + コード修正を繰り返す → Codex
画像生成が必要 → Codex
複数タスクを並列化したい → Codex
長文ドキュメント / 深い推論 → Claude
この検証で得た本質的な理解は、Codexが「コード生成ツール」ではなく「制作ワークフローの統合プラットフォーム」だという点です。比較の軸をコード精度に置くと、この差は見えません。
2026年4月に追加された核心機能
| 機能 | 効果 |
|---|---|
| Background computer use | Macアプリを自律操作 |
| In-appブラウザ | ローカルサーバーをCodex内で直接確認・コメント修正 |
| gpt-image-1.5統合 | コード生成の流れで画像生成→配置まで完結 |
| 90以上のプラグイン | Gmail / Drive / Slack / Figma / GitHub 等を横断自動化 |
| Skills | 繰り返し作業を再利用可能な指示書としてパッケージ化 |
| GPT-5.5（4/23〜） | エッジケース対応・テスト品質が顕著に向上 |
| メモリ機能（プレビュー） | 個人の好みを記憶し、次回から修正指示が不要に |
In-appブラウザ：LP制作の工数が体感1/5に
この検証で最も効果が大きかった機能です。
操作フローは次のとおりです。
- Codexアプリ内のブラウザでローカルサーバー（localhost）を開く
- CTAボタンに「もう少し大きく・赤系に」とコメントを書き込む
- Codexが該当コンポーネントを自動で特定して修正
- ホットリロードで即反映
結果として次が確認できました。
- 「ブラウザ → コード → ブラウザ」のサイクルが1ウィンドウ内で完結
- CSSの上書き場所を探す調査工数がほぼゼロ
- ビューポート切替（PC / タブレット / スマホ）もアプリ内で完結
- LP制作工数が体感で1/5に削減
フロント開発で時間を食うのは、コードを書くことより「どこを直せばいいか探すこと」です。画面上の要素を指してコメントできると、この探索が消えます。
並列エージェント：朝20分で3〜4タスクが承認待ちに
各エージェントが独立したGit Worktreeで稼働するため、衝突が起きません。
実際に朝一番で7タスクを同時投入しました。TypeScriptエラー修正、Webhookエンドポイントのスキーマ更新、管理画面のエラーバウンダリ追加、レガシーauth middleware移行、LP追記セクション実装、記事サムネ画像生成＆配置、Gmail未返信問い合わせ抽出＆返信ドラフト作成——といった内容です。
結果：約20分で4タスクが承認待ちに到達。待ち時間ゼロで、1タスクが詰まっても全体は止まりません。
運用ルーティンとしてはこうなります。
1. 朝Codexを起動
2. 5〜7個のタスクをキューに投入（並列実行）
3. コーヒーを淹れる（約20分）
4. 戻ったら3〜4タスクが承認待ちに → まとめて承認
5. 残りタスクは追加情報を提供して再実行
→ 午前中でその日の仕事の8割が完了
もうひとつの発見があります。並列試行には「設計品質」を上げる副作用があります。設計方針が固まっていない初期段階で「3案並列作成→比較して決定」という使い方をすると、頭の中だけでは気づけない選択肢が、実装してから見えてきます。
画像生成の統合：FV1本が1時間以内に
従来と比べると工程数が明確に違います。
| 従来 | Codex | |
|---|---|---|
| 手順 | 画像生成ツール → プロンプト工夫 → ダウンロード → エディタでパス指定 → 表示確認（5ステップ） | 「このセクションに画像生成して配置して」→ 生成 → 適切なパスへ配置 → background-image設定まで完結（1アクション） |
参考スクリーンショットを渡せば「雰囲気を合わせる」編集も可能です。コード・画像・スクショが同一画面で循環します。
結果としてFV1本が1時間以内（従来の半日比）になりました。
実案件での実績
プロポーザル資料（HTMLスライド20ページ相当）
エージェントA: TailwindCSS + アニメーション付きHTMLスライド実装
エージェントB: Mermaid形式ロードマップ図 + 画像生成で表紙ビジュアル作成
エージェントC: ROI試算Excelシート（グラフ込み）生成
3エージェント並列で約2時間（従来の丸2日比）。PRが上がった時点での修正コストも体感3割減（GPT-5.5効果）でした。
新規LP（FV + 4セクション + レスポンシブ対応）
- Figmaカンプ → Codex（画像解析）→ ベース実装 → ブラウザ内コメント微調整
- FV 1本: 1時間以内（従来の半日比）
- LP全体: 1日（従来の3日比）
- 複数ページはページ別にエージェントを分割して並列処理
営業面での効果も記録しています。従来はA案・B案を両方作り込むのに2〜3日かかっていたところ、同じ午後中に両方の動くプロトタイプを提示できるようになりました。
デザインモック・ラフ案
概要図 + ユーザーフロー図 + 画面モック10枚のドキュメントを半日（従来の1日半比）で作成。画面モックをReactコンポーネントとして実装し、「クリックできる動くモック」として納品しています。
静的画像ではなく動くモックを見てもらえると、提案の説得力が変わります。
Claude Code との比較
| 観点 | Claude Code | Codex |
|---|---|---|
| コード単体性能 | ◎ | ◎ 同等水準 |
| ターミナル統合 | ◎ 主戦場 | ○ CLIあり |
| In-appブラウザ | ✗ なし | ◎ あり |
| 画像生成統合 | ✗ なし | ◎ あり |
| 並列エージェント | △ 限定的 | ◎ Git Worktreesで完全並列 |
| プラグイン数 | △ MCP中心 | ◎ 90以上（公式サポート） |
| インターフェース | ターミナル | デスクトップアプリ |
| 非エンジニアの利用 | ✗ 困難 | ◎ ハードルが低い |
| コンテキスト長 | ◎ 100万トークン | △ 400K（Desktopは制限あり） |
Claude Codeが優位な場面は明確です。ターミナルでのシェル操作が主体の作業、大規模コードベースの理解（100万トークン活用）、長文ドキュメント作成・複雑な推論。
もうひとつ重要な観察があります。非エンジニア層への普及のボトルネックは「ターミナルというインターフェース」でした。デスクトップアプリであることが、利用者層を広げます。
Claude Design との比較（デザインモック用途）
| 観点 | Claude Design | Codex |
|---|---|---|
| デザイン出力品質 | ◎ | ○ |
| 実装への引き継ぎ | △ 別ツールに渡す | ◎ 同一ツール内で完結 |
| ワークフロー統合度 | △ デザインフェーズのみ | ◎ コード・画像・ブラウザが1画面 |
| エクスポート先 | Canva / PPTX / HTML | コードとして直接出力 |
| 非デザイナー向け | ◎ 橋渡しとして最強 | ○ 実装者が使うツール |
Claude Designが優位なのは、非エンジニアがデザインを起点にしたい場合、Canva / PPTXへの出力が必要な場合、実装者が別チームの場合です。
Codexが優位なのは、デザイン→実装のサイクルを繰り返す現場、1人または少人数で「デザインも実装もやる」ケースです。
導入手順：初日にやること
- Codexデスクトップアプリをインストール
- GPT-5.5をモデルピッカーで選択
- 慣れているプロジェクトのルートに
AGENTS.mdを作成 - GitHub / Google Drive / Slack / Figma プラグインをインストール・認証
- 小さなタスクを1件実行して感覚を掴む
初日は新規プロジェクトではなく、慣れているプロジェクトで試すこと。出力の良し悪しを判断できる状態でないと、評価ができません。
AGENTS.md の必須記載事項は次の4つです。
# Project Overview（プロジェクト概要）
# Coding Conventions（命名規則・ファイル構成）
# Common Commands（よく使うコマンド）
# Test / Deploy（テスト・デプロイ手順）
コーディング規約が充実しているほど修正コストが下がります。毎回同じ指摘を繰り返しているなら、それは規約に書くべき内容です。
1週間で習慣化する5機能
- 並列エージェント実行 — 最初は2個、慣れたら3〜5個
- In-appブラウザでのコメント修正 — コードを開かずブラウザ内だけで指示
- 画像生成との連携 — 画像が必要になったらCodex内で完結させる
- Skillsの活用 — 繰り返す作業を
@skillで呼び出す習慣 - メモリ機能の育成 — 修正指示後に「これを覚えておいて」と明示
あわせて、1週間のうち1日は意図的にCodexを使わない日を作るという運用を推奨します。生産性の差を対比で実感できるためです。
うまくいかなかったこと
- コンテキストウィンドウが400Kに制限されている（Claude Codeの100万比）ため、大規模コードベースでは不利
- Codex DesktopのHooksはまだ未実装（v26.422時点）。CLI版は対応済み
- GPT-5.5リリース後に
config.tomlでの1M設定が機能しなくなった
よくある質問
Claude CodeとCodex、どちらを使うべきですか？
用途で分けます。ブラウザ確認とコード修正を繰り返す作業、画像生成が必要な作業、並列化したい作業はCodex。ターミナル操作が主体の作業、大規模コードベース、長文ドキュメント・深い推論はClaude Codeです。
どのくらい速くなりますか？
この検証では、LP制作が従来の3日から1日、FV1本が半日から1時間以内、プロポーザル資料が丸2日から約2時間でした。いずれも並列エージェントとIn-appブラウザの効果が大きい領域です。
非エンジニアでも使えますか？
デスクトップアプリである点がハードルを大きく下げています。非エンジニア層への普及のボトルネックは、ターミナルというインターフェースでした。
大規模なコードベースでも使えますか？
コンテキストが400Kに制限されているため不利です。大規模コードベースの理解が必要な場面では、100万トークンを扱えるClaude Codeのほうが適しています。
まとめ
- Codexの本質は「コード生成ツール」ではなく「制作ワークフローの統合プラットフォーム」
- In-appブラウザが決定打。「どこを直せばいいか探す」工数が消え、LP制作は体感1/5に
- 並列エージェント（Git Worktrees）で朝20分に3〜4タスクが承認待ちへ。並列試行には設計品質を上げる副作用もある
- 画像生成の統合でFV 1本が1時間以内（従来の半日比）
- 長文ドキュメント・深い推論・大規模コードベースはClaudeが依然優位（コンテキスト400K vs 100万）
- AGENTS.mdの規約が充実するほど修正コストが下がる
ツール選定は「どちらが優れているか」ではなく「どの工程を短縮したいか」で決まります。工程をまたぐ移動が多い作業ほど、統合された環境の効果が出ます。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の制作・開発体制へのAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。