二刀流の流浪人、188番勝負の武者修行に出る — CodexにE2Eテストを回させてClaudeが判定した

公開: 2026-09-12

前回、Claude CodeからCodexを呼べるようにした。二刀を腰に差したので、今回は武者修行に出た。相手は自作アプリのE2Eテスト188項目。

結果から書くと、188項目すべてに判定がつき、不具合を33件起票できた。ただし、Codexに回させた判定をそのまま採れた回は少なかった。二刀流で一番効いたのは、片方の刀がもう片方を疑うという使い方だった。

役割を分けた

Codexに全部を任せず、実行と判定を分けた。

Claudeが統括・判定し、Codexがテストコードを書いて実行する。差し戻しは同じセッションへ戻る。

板壁に掛かった木札を一枚ずつ検分する流浪人

テストは13グループに分け、並列はやめて1グループずつ直列に回した。ホストのメモリが16GBで、途中で開発サーバとCodexがメモリ不足で2回落とされたからだ。仮想マシンを止めてから再開している。

Codexの5時間枠は、最初の構成だと1グループで半分近く消えた。そこで、グループごとにモデルと思考量とプロンプトを変えた。

思考量を下げれば、トークンは減っても判定の品質が上がるとは限らない。

分かったことは3つ。

思考量を下げるのは逆効果だった。 mediumはトークンが半分以下になったが、画面の値を読まずに固定値と比べるだけのspecが出てきて、結局こちらでほぼ書き直した。
プロンプトを絞ると2割ほど減る。 仕様書を丸ごと読ませず、項目の表と参照ファイルだけを渡した。
差し戻しの理由を積み上げると、同じ種類の誤りは減る。 「待ちを入れる」「前提不足のエラーを拒否と読み替えない」などを、次のプロンプトの「必ず守ること」に足していった。

差し出された木札を押し返す流浪人

差し戻しの理由は、ほとんどがテスト側の不備だった。

画面が操作可能になる前に入力していた(hydration前のfill)。値がReactの状態に入らず、アプリが「未入力です」と返す。これをアプリの不具合としてfailにしていた
金額を数値に直す正規表現が /[,-円]/ になっていた。, から 円 までの範囲指定になり、数字が全部消えていた。画面の金額がすべて0として読まれていた
1か所の準備の失敗で、後ろの項目をまとめて未実施にしていた
前提(期間の締め、プランの設定)が足りずにAPIがエラーを返したのを、「期待どおりの拒否」としてpassにしていた

どれも、画面かAPIを1回直接叩けば分かる。Codexは叩かずに結論を出していた。

一番危なかったのは、差し戻した後のCodexが、期待値の方をアプリの誤った計算に合わせてpassにしようとした場面だった。

帳票の集計が片側の合計しか取っておらず、ある年度の利益が22万円ずれていた。Codexは1回目、正しい期待値でfailを出していた。差し戻して「期待値の作り方を確かめて」と頼んだら、アプリと同じ集計の仕方に期待値を作り替え、コメントに「アプリはこう集計するため」と書いてきた。

期待値は、アプリを見る前に決める。これを明文化していなかったのはこちらの落ち度で、次のプロンプトから「期待値をアプリの動きに合わせて書き換えない」を足した。

影響の大きい不具合は、ほぼすべてClaudeがDBの関数定義やAPIを直接確かめて特定した。Codexは「確定の通知が表示されない」「値が合わない」とだけ書き、テスト側の問題かアプリ側の問題かを切り分けられていなかった。

見つかった33件のうち、影響の大きいものは権限まわりと集計まわりに集まっていた。どちらも、テストが「表示された」「保存された」で止まっていたら見逃していた種類のものだ。

効率だけなら、Claude単独で回した方が安かったと思う。Codexの負担を、こちらの確認作業で埋める形になったからだ。

二刀を並べて刃を見比べる流浪人

それでもやってよかった。Codexの判定を疑って確かめる過程で、単独なら流していたかもしれない不具合が見つかった。二刀流の価値は手数ではなく、もう一方が疑う役に回れることにあった。

次に使うなら、Codexには範囲がはっきりした下書き(手本のあるspec、API中心のグループ)を任せ、期待値の決定・原因の切り分け・最終判定は最初からClaudeが持つ。判定させてから疑うより、その方が安い。

実行と判定を分ける手順は AIにテストを任せるなら実行と判定を分けるにまとめた。前回の、Codexを入れて絵で3回転んだ話は自分の禁止事項でAIの道具を封じていた。テスト対象はちょうぼっち。この記事の図とキービジュアルはCodexが描いた。