Claude OpusとCodexでNuxt 4プロジェクトの再設計を議論した
何をやったか
「いまプロジェクトをゼロから自由に再設計できるとしたら、どういう設計にしますか?」
この問いを2つのセッションに分けて投げた。
- セッション1: Claude Opus 4.6に単独で再設計案を書かせた
- セッション2: Claude OpusがCodex（GPT-5.3）とディスカッションしながら設計判断を詰めた
対象はNuxt 4 + FastAPI + SQLiteで構成された業務Webアプリ。ルールベースのデータ変換パイプラインを中心に、帳票管理・マッチング・エクスポートを担うローカル完結型のシステムだ。
2セッションの構成
セッション1: Claude Opus単独
Claude Opusがコードベースを読み込み、現行設計の維持すべき点と変更すべき点を整理した。出力は redesign-from-scratch.md。Before/AfterのMermaid図、ファイル名と行数を指定した分割計画、コードスニペットが並ぶ。手を動かすための設計図に近い。
セッション2: Claude Opus x Codex
セッション1の素案をCodexに渡し、6つの論点（テーブル統合、レイヤー数、状態マシン、TanStack Query、致命的見落とし、Codex独自案）についてYes/Noで回答させた。出力は redesign-discussion-claude-vs-codex.md。設計判断の根拠が中心。
9項目の変更一覧
再設計で変える項目を先に一覧で把握する。
| # | 対象 | 現行 | 再設計 | 狙い |
|---|---|---|---|---|
| 1 | BEロジック分離 | DB層にSQL+ビジネスロジック混在 | 純粋関数としてdomain/に分離 | テスト容易性 |
| 2 | ルールエンジン | CSV由来とDB由来の2実装が並存 | 1本化、CSV廃止 | マッチングの信頼性 |
| 3 | importスクリプト | 8本が各自でDB操作 | Service層に統合、Repository注入 | CLI/HTTP両対応 |
| 4 | マイグレーション | 15 SQLファイル+各モジュールに散在 | _migration_historyで一元管理 | 適用状態の追跡 |
| 5 | FEコンポーネント | 1ファイル2,000行超が6つ | feature単位で200-300行に分割 | 部分修正の容易さ |
| 6 | composable | 1ファイル20KB超が2つ | 単一責務で分割 | 責務の明確化 |
| 7 | 状態管理 | Pinia 6個+composable 14個 | Pinia 2個+feature composable | 迷い解消 |
| 8 | API層 | 全部入りutils/api.ts | ドメイン単位分割+OpenAPI型生成 | 型齟齬の検出 |
| 9 | 型安全 | 手動同期 | OpenAPIから自動生成 | コンパイル時検出 |
Before/After（バックエンド）
Codexとの議論で変わった4つの判断
セッション1とセッション2で結論が異なった論点をまとめる。Codexは「この規模で本当に必要か」という問いを繰り返し、Claude Opusの理想寄りの提案を引き戻した。
1. テーブル設計: 1テーブル統合 → ハイブリッドモデル
Claude Opusは4テーブルを1つのdocumentsテーブルに統合し、帳票固有フィールドをJSON列に入れる案を出した。Codexが「整合性制約と索引設計が弱くなる」と却下。共通テーブル + 帳票別詳細テーブル（1:1）に落ち着いた。
2. レイヤー構成: 4層 → 3層
Router → UseCase → Domain → Repositoryの4層をClaude Opusが提案。Codexが「1人開発・30エンドポイントで4層は抽象化コストが先行する」と指摘し、Service層に統合。ルールエンジンなど純粋関数として抽出する価値があるものだけdomain/に残す。
3. TanStack Query: 導入推奨 → 見送り
Claude Opusが案A/Bを比較して推奨した。Codexが「API境界の整理とコンポーネント分割が先。この規模ならNuxt標準のuseFetch/useAsyncDataで十分」と一蹴。同意した。
4. 税務固有の要件3点が追加
Claude Opusのドキュメントには書かれていなかった3点をCodexが指摘した。
- 監査証跡: 「誰がいつ確定/変更したか」の記録。税務業務では必須
- 冪等性: CSV再インポート時の重複防止（
source_hash+ UNIQUE制約） - ルールバージョン管理: 仕訳確定時にルールIDとバージョンを記録
技術設計だけでは出てこない、ドメイン知識に基づく指摘だった。
Codexとのディスカッションの進め方で学んだこと
最初は汎用的な回答しか返ってこなかった
「この設計についてどう思いますか?」と聞くと、「良い設計ですが、テストも大事です」のような当たり障りのない回答が返ってきた。Codexは対話の文脈を持たないため、自由記述で聞くと表面をなぞるだけの回答になりがちだった。
ファイルに書いて読ませる方式が効いた
Claude Opusが再設計案をマークダウンに書き出し、そのファイルパスをCodexに渡して「このファイルを読んで回答してください」と指示したところ、具体的なファイル名や行数を参照した回答が返るようになった。口頭で概要を伝えるより、テキストとして渡す方が精度が上がる。
Yes/No形式で強制すると具体性が出た
6つの論点それぞれについて「Yes/Noで回答し、理由を述べてください」と形式を指定した。自由回答だと「ケースバイケースです」で終わるところが、Yes/Noを強制されると立場を取らざるを得ない。結果として「No。この規模では4層は過剰。3層で十分」のように、根拠付きの明確な判断が返ってきた。
細かい発見: Nuxt 3 → Nuxt 4 の誤記
再設計ドキュメント内で「Nuxt 3」と書いていた箇所があったが、package.jsonを確認すると "nuxt": "^4.2.2" だった。セッション中に気づいて修正。Claude Opusは学習データの時期的にNuxt 3の知識が強く、^4.x.xのpackage.jsonを見ても「Nuxt 3」と書いてしまうことがある。
2セッションの比較
| 観点 | セッション1（Claude単独） | セッション2（Claude x Codex） |
|---|---|---|
| 強み | Mermaid図、具体的な分割計画、コード例 | 設計判断の根拠、過剰設計の抑制 |
| 弱み | 理想に寄りがち、ドメイン要件の見落とし | コード例が少ない、実装の具体性が薄い |
| 性格 | 「どうやって作るか」のロードマップ | 「何を作るべきか」の設計審査 |
両者は補完関係にある。実装に着手するなら両方を並べて読むのがいい。
振り返り
AIに「ゼロから再設計するなら?」と聞くと、手元のコードが急に客観的に見えた。2,000行のVueコンポーネントも、日常的に触っていると「まあこんなものか」と感覚が麻痺する。外から「これは分割すべき」と指摘されて、ようやく目が覚めた。
2つのAIを対話させる形式は、1つのAIに長く聞くより視野が広がった。Claude Opusが理想を描き、Codexが「本当に要るのか」と削る。この押し引きで残ったものが、実際に手を動かす価値のある変更だった。