はじめに
2026-09-30 に、私の環境の Codex で、機能アップデートによりモデル一覧に GPT-6.1 Sol が追加されました。OpenAI の料金ページの API タブにも GPT-6.1 Sol が載っています(2026-09-30 確認)。単価は入力と出力が GPT-6 Sol と同じで、キャッシュ入力だけが、前回の記事で使った GPT-6 Sol の単価(0.20ドル)の半額(0.10ドル)です。ただし、GPT-6 Sol 側の単価は、確認時点の料金ページには載っていなかった値です(後述)。
前回の記事「親子エージェントのモデル組み合わせ7通りを、隠し受入テストで比較してみた」では、請求書計算モジュールを題材に親子エージェントのモデルの組み合わせを比べました。総合でいちばん結果が良かったのは、親 Claude Opus 5.5 / 子 Codex GPT-6 Sol(構成C) です。3回とも不具合0%・巻き戻し0回で、実装時間は平均で7構成中最短、金額は API 料金で換算して平均1.15ドルでした。子のモデルが新しくなったら、そのまま乗り換えてよいのか。EC の金額計算のように1円のずれも許されない処理を任せる前提で、品質・時間・金額が変わるかを確かめたいと考えました。そこで今回は子だけを GPT-6.1 Sol に替えた構成Hを、同じ課題・同じ仕組みで3回試しました。
結論を先に書きます。
- 品質は C と同じく、3回とも不具合0%・巻き戻し0回でした
- 子が書いたテストは、平均約32件から平均約253件(約8倍) に増えました
- その代わり、実装時間は平均7.8分から16.5分(約2.1倍) に延びました。延びた分はほぼすべて子の作業時間で、親の時間はほぼ同じでした
- 金額は、ほぼ同じか、やや高めでした。C は平均1.15ドル、H は正しく記録できた2回の平均で1.22ドルです。H の3回平均は1.10ドルですが、1回分が未計上のため低く出ています
検証環境
| 項目 | 内容 |
|---|---|
| OS | Windows 11 |
| ランタイム | Node.js 24 |
| Claude Code CLI | 2.1.284(Claude デスクトップアプリ同梱版) |
| Codex CLI | C = 0.158.0-alpha.2.1、H = 0.159.0(Codex デスクトップアプリ同梱版) |
| 親モデル |
claude-opus-5-5(C・H 共通) |
| 子モデル | C = gpt-6-sol、H = gpt-6.1-sol
|
| 推論の強さ | Codex = medium、Claude = CLI の既定値 |
| 子のタイムアウト | 10分 |
| 実行日 | C = 2026-09-29、H = 2026-09-30 |
注意:C と H では Codex CLI のバージョンが違います。 このあと出てくる時間の差には、モデルの違いだけでなく CLI の違いによる影響も含まれている可能性があります。今回の検証では、この2つを切り分けていません。
やってみた
仕組みと課題(前回と同じ)
仕組みは前回の記事と同じなので、要点だけ書きます。
- 課題は請求書計算モジュール(上級版) です。複数クーポン・明細ごとの按分・地域別送料・端数処理3方式・ポイント・17種類のエラー・CLI を扱います
- 工程は次のとおりです:親が仕様書を書く → 子が実装(impl)→ 親がレビュー → 子がテストを作成(test)→ 親が実行・判定 → 不具合があれば差し戻し(fix)→ 親が報告書を書く
- 親から子への委任は、必ず
bench/child.mjsを通します。子は毎回まっさらな状態で起動します - 巻き戻しは、fix を呼んだ回数です
- 不具合率は、エージェントからは見えない隠し受入テスト74件のうち、不合格になった割合です
検証用リポジトリと隠し受入テストは、今回も公開していません。
構成H は、bench/config.json に子のエージェントと構成を1行ずつ足して定義しました。
bench/config.json(抜粋)
"sol61": { "vendor": "codex", "model": "gpt-6.1-sol", "label": "Codex GPT-6.1 Sol" }
bench/config.json(抜粋)
"H": { "parent": "opus", "child": "sol61", "title": "親Opus 5.5 / 子Codex Sol 6.1" }
金額の計算
金額は前回の記事と同じく、記録したトークン数をAPI 料金で換算した額です(料金は各社の公式ページで確認。GPT-6 Sol だけは料金ページに載っていなかった単価)。Codex の単価は bench/config.json の codexPricePerMTokUSD に持たせていて、GPT-6.1 Sol の行を足しました。
bench/config.json(抜粋)
"gpt-6.1-sol": { "input": 2.0, "cachedInput": 0.10, "output": 10.0, "_note": "公式API料金（2026-09-30 確認）" }
| モデル | 入力 | キャッシュ入力 | 出力 | 出典 |
|---|---|---|---|---|
| GPT-6.1 Sol | 2.00 | 0.10 | 10.00 | openai.com の料金ページの API タブ(標準処理・コンテキスト272K未満) |
| GPT-6 Sol | 2.00 | 0.20 | 10.00 | 確認時点の料金ページには載っていなかったため、筆者が把握していた単価(前回記事と同じ) |
| Claude Opus 5.5 | 4.00 | 0.20(キャッシュ読み込み) | 20.00 | claude.com の料金ページ。キャッシュ書き込み(1時間)は8.00 |
単位は USD / 100万トークンです。Claude 分は CLI が出す total_cost_usd を使いました。上の公式料金で検算したところ、全件で一致しました。Codex は ChatGPT プランで使ったので、実際の請求は定額です。ここでの金額は、上の API 料金で換算した額です(GPT-6 Sol は公式ページで確かめた単価ではありません)。
結果(各3回)
| 項目 | C(子 GPT-6 Sol) | H(子 GPT-6.1 Sol) |
|---|---|---|
| 不具合率 | 0%(74/74 ×3回) | 0%(74/74 ×3回) |
| 巻き戻し(fix) | 0, 0, 0 | 0, 0, 0 |
| 金額(USD) | 1.35, 1.03, 1.08(平均1.15) | 1.31, 0.87※, 1.13(平均1.10) |
| うち親 | 0.92, 0.68, 0.71 | 0.92, 0.70, 0.74 |
| うち子 | 0.43, 0.35, 0.37 | 0.39, 0.16※, 0.39 |
| 実装時間(分) | 8.7, 7.16, 7.49(平均7.8) | 16.5, 17.36, 15.53(平均16.5) |
| 子の impl 時間(分) | 2.2, 2.0, 2.2 | 4.3, 4.7, 4.6 |
| 子の test 時間(分) | 3.0, 2.6, 2.5 | 9.4, 10.0※, 7.9 |
| 親が自分で使った時間(分) | 3.6, 2.6, 2.7 | 2.8, 2.7, 3.0 |
| 子が書いたテスト数(全件合格) | 30, 16, 49 | 244, 280, 235 |
| 合計トークン | 1,451,933 / 1,057,568 / 1,255,185 | 1,224,814 / 909,840※ / 1,083,945 |
| 親の自己申告のレビュー指摘数 | 1, 0, 1(いずれも軽微) | 1, 1, 0(いずれも軽微) |
- ※ H の2回目は、子の test が10分のタイムアウトで打ち切られました。子の報告は「最後の調整中」のまま途切れていました。親は残ったテストファイルを確認して完成していると判断し、最終状態で
node --testを実行すると280件すべてが合格しました。打ち切られた呼び出しのトークンと金額は記録されないので、この回の金額とトークンは実際より少なく出ています。また、この回の test 時間10.0分は打ち切り時点までの値です。打ち切られなければ、もっとかかっていた可能性があります。このあと出てくる平均(実装時間16.5分、子の作業時間の約2.8倍)にも、この打ち切り時点の値が含まれています - 「親が自分で使った時間」は、親の実時間から子の作業時間を引いたものです
- 「子が書いたテスト数」は、最終状態でランナーが
node --testを実行したときの合格件数です。子の自己申告ではありません
集計スクリプトが出した試行ごとの明細です(列:試行 | 状態 | USD | 分 | 巻き戻し | 受入 | 不合格ケース | 警告)。
| invoice-advanced-C-r1-20260929T074245 | completed | 1.3496 | 8.7 | 0 | 74/74 | - | - |
| invoice-advanced-C-r2-20260929T093333 | completed | 1.0332 | 7.16 | 0 | 74/74 | - | - |
| invoice-advanced-C-r3-20260929T104251 | completed | 1.0817 | 7.49 | 0 | 74/74 | - | - |
| invoice-advanced-H-r1-20260930T040844 | completed | 1.3109 | 16.5 | 0 | 74/74 | - | - |
| invoice-advanced-H-r2-20260930T042516 | completed | 0.8652 | 17.36 | 0 | 74/74 | - | 子(test)がタイムアウトで強制終了（その回のトークン・金額は未計上） |
| invoice-advanced-H-r3-20260930T044242 | completed | 1.1316 | 15.53 | 0 | 74/74 | - | - |
考察
1. 品質は同じ。6.1 Sol に替えても精度は落ちなかった
C も H も、3回とも隠し受入テスト74件すべてに合格しました。巻き戻しは0回です。親のレビュー指摘も、どちらも0〜1件で、いずれも軽微なもの(たとえば「安全整数の範囲を超える巨大な金額では精度が落ちる」といった、要件の範囲外の指摘)でした。この課題の規模では、子を 6.1 Sol に替えても品質は落ちませんでした。
2. 子のテストが約8倍に増えた
大きく変わったのは、子が書いたテストの量です。C は16〜49件(平均約32件)でしたが、H は235〜280件(平均約253件)でした。前回の記事では、子が Claude の構成は92〜284件、子が Codex(GPT-6 Sol / GPT-6 Luna)の構成は10〜49件でした。6.1 Sol のテスト量は、子 Claude の構成に近い水準です。
テストを書くよう指示した親のファイル(prompts/02-test.md)を、C の2回目と H の2回目で読み比べました。要約すると、どちらも、仕様書のテスト観点をすべて網羅し、すべてのエラーコードとチェック順序を確かめるよう指示していました。C のほうは、エラーコードごとに「少なくとも1ケースずつ」という下限を書いていました。テストの総数を指定する指示は、どちらにもありませんでした。ただし、比べたのは2回目どうしの1組だけです。指示ファイルは親が毎回書くので、ほかの回では内容が違う可能性があります。この範囲では、親の指示の違いでテスト量が大きく変わったわけではないと思われますが、推測です。
H のテストファイルを見ると、ケースを配列で並べて for で回し、1ケースごとに test() を作るデータ駆動の書き方が使われていました。次は H の2回目の test/cli.test.js の一部です。BOM あり・なしの2通りで、ファイル入力と標準入力をそれぞれ確かめています。
for (const bom of [false, true]) {
test(`CLI file input: UTF-8 Japanese and spaces in path, BOM=${bom}`, (t) => {
const file = path.join(tempFiles(t), '入力 invoice.json');
fs.writeFileSync(file, (bom ? '\uFEFF' : '') + JSON.stringify(example), 'utf8');
expectSuccess([file], '', exampleExpected);
});
test(`CLI stdin: complete §6 output, BOM=${bom}`, () => {
expectSuccess(['-'], (bom ? '\uFEFF' : '') + JSON.stringify(example), exampleExpected);
});
}
H の1回目の test/invoice.test.js でも、クーポンの判定(対象カテゴリなし、最低購入額ちょうど、など8ケース)を同じ書き方でまとめていました。こうした書き方で観点ごとの組み合わせを広く並べたことが、件数が増えた理由の1つだと思われます。ただし、ファイル全体の内訳は数えていません。C のテストファイルの書き方とも、細かくは比べていません。
前回の記事では、16件でも284件でも受入テストは74/74でした。今回も、16件(C)でも280件(H)でも74/74です。テストが多いほど品質が高い、とは今回のデータからは言えません。 言えるのは、「仕様の観点を細かく押さえたテストが、リポジトリに残る」ということです。
3. 時間は約2倍。増えたのは子の時間だけ
実装時間は平均7.8分から16.5分へ、約8.7分延びました。内訳を見ると次のとおりです。
- 子の作業時間(impl + test)の合計:平均約4.8分 → 約13.6分(約2.8倍)
- 親が自分で使った時間:平均約3.0分 → 約2.8分(ほぼ同じ)
延びた分は、ほぼすべて子の時間です。impl は約2倍、test は約3〜4倍になりました。test の時間は 9.4分・10.0分(打ち切り)・7.9分で、3回中2回は10分のタイムアウトにほぼ達しました。
一方で、子の合計トークンは H のほうが少なくなっていました。ただし、減ったのはキャッシュ読み込みだけです。
| 試行 | 子のトークン(入力 / キャッシュ読み込み / 出力) |
|---|---|
| C-1 | 87,790 / 598,656 / 13,823 |
| C-2 | 67,027 / 446,976 / 12,933 |
| C-3 | 76,423 / 487,936 / 11,789 |
| H-1 | 96,911 / 366,464 / 16,277 |
| H-2 | 46,070 / 172,928 / 5,346(impl のみ。test は打ち切りで記録なし) |
| H-3 | 105,691 / 322,560 / 14,745 |
C の3回と、正しく記録できた H の1回目・3回目の平均で比べると、H はキャッシュ読み込みが約33%減った一方で、入力(キャッシュ以外)は約31%、出力は約21%増えています。合計トークンは減りましたが、出力が約1.2倍なのに対して、子の時間は約2.8倍です。生成量の増え方だけでは説明しにくい伸びだと考えています。考えられる理由として、生成速度の違いや、テストを書きながら実行した回数と時間(CLI のテストは1件ごとに Node のプロセスを起動します)があります。ただし、どれも調べていないので推測です。先に書いたとおり、Codex CLI のバージョン違いの影響も切り分けていません。
4. 金額はほぼ同じか、やや高い。子はキャッシュ入力の値下がりと入力・出力の増加が打ち消し合った
正しく記録できた回だけで比べると(C は3回、H は1回目と3回目)、1回あたりの金額は C が平均1.15ドル、H が平均1.22ドルで、H が約6%高くなりました。
差の主な理由は親の分です。親の金額は C が平均0.77ドル、H の1回目・3回目が平均0.83ドルでした(H の親は3回平均だと0.79ドルです)。子の金額は、次のとおりほぼ同じでした。
| 子の金額の内訳(平均、USD) | C | H |
|---|---|---|
| 入力 | 0.154 | 0.203 |
| キャッシュ入力 | 0.102 | 0.034 |
| 出力 | 0.128 | 0.155 |
| 合計 | 0.385 | 0.392 |
キャッシュ入力の費用は、単価が半額になったことと、キャッシュ読み込みのトークン自体が減ったことで、約0.07ドル下がりました。その一方で、入力と出力のトークンが増え、あわせて約0.08ドル上がっています。差し引きすると、子の金額はほぼ同じでした。
なお、H の3回平均(1.10ドル)が C(1.15ドル)より少し安く見えるのは、H の2回目で test の分が計上されていないためです。正しく記録できた2回の平均(1.22ドル)で見ると、同じくらいか、やや高いと見るのが妥当だと考えています。
EC-CUBE や Web アプリの開発にどう組み込むか
ここからは、実装者の目線での設計案です。今回の検証は Node.js の小さな課題1つだけなので、EC-CUBE(PHP)や Go / React の開発にそのまま当てはまるとは限りません。
分担:速さを取るか、テストの厚みを取るか
- 急ぎの改修や、すでにテストがそろっている箇所の修正には、子 GPT-6 Sol(C)が向いていると考えています。今回の課題では、品質は同じで、時間は半分以下でした
- 新しく作るモジュールで、回帰テストの土台もあわせて作りたい場合には、子 GPT-6.1 Sol(H)が選択肢になります。EC-CUBE の購入フローで、送料・税・クーポン・ポイントの計算をカスタマイズする場面を考えています。こうした処理は、あとから別の改修が入ったときに守ってくれるテストがあると心強いものです
- 工程ごとにモデルを分ける案もあります。たとえば impl は 6 Sol、test は 6.1 Sol にする形です。ただし、今回は試していません。子は毎回まっさらな状態で起動するので、工程ごとの切り替え自体は
child.mjsの中の話で済むと思われます
品質:テストの量と、受入テストは別に考える
- 子が250件前後のテストを書いても、人が受入の基準を持つ必要性は変わりません。金額が絡む処理では、人が手計算で作った期待値の受入テストを、エージェントから見えない場所に置く運用を続けるべきだと考えています
- テストが多いと、レビューする側の負担も増えます。親エージェントや人がテストの中身まで見るなら、その時間も見込んでおく必要があります
コスト
- 今回の課題では、1回あたり約1.2ドル前後(API 料金での換算。C は平均1.15ドル、H は正しく記録できた2回の平均で1.22ドル)で、大きな差はありませんでした。モデルを選ぶ決め手は、金額よりも時間とテストの厚みになると考えています
- ChatGPT プランの定額で Codex を使う場合は、金額より、時間とプランの利用上限のほうが効いてくる可能性があります(今回は、子のレート制限による待ち時間は0でした)
運用
- モデルを替えたら、タイムアウトを見直す。今回は 6.1 Sol の test が3回中2回で10分の上限にほぼ達し、そのうち1回は打ち切られました。CI やバッチでエージェントを回すなら、モデルの切り替えと一緒に、ジョブのタイムアウトも見直すべきです
- CLI のバージョンを記録する。今回、C と H では Codex CLI のバージョンが違い、時間の差を切り分けられませんでした。比較するなら、モデルだけを替えて CLI は固定するのが理想です
- 打ち切られた呼び出しの使用量が記録されないことを前提に、集計する。今回の計測の作りでは、タイムアウトした回は0トークンと記録されます。費用を管理するなら、警告を出すか、別の手段で使用量を取る必要があります
セキュリティ
前回の記事と同じです。承認なしモードは、専用の作業フォルダ、できれば使い捨ての環境でだけ使います。本番の EC-CUBE 環境や、実際の顧客データ・API キーがある場所では動かしません。子から孫への再委任も禁止しておきます。
まとめ
- 親 Opus 5.5 のまま、子を GPT-6 Sol から GPT-6.1 Sol に替えて、同じ課題を3回ずつ比べました
- 品質は同じでした(3回とも不具合0%・巻き戻し0回)
- 子が書いたテストは、平均約32件から約253件へ、約8倍になりました。子 Claude の構成に近い水準です
- 実装時間は平均7.8分から16.5分へ、約2.1倍になりました。延びたのはほぼすべて子の時間です。子の合計トークンは減っていて(減ったのはキャッシュ読み込み。出力は約1.2倍)、時間が延びた理由は調べていません
- 金額は、ほぼ同じか、やや高めでした(C は平均1.15ドル、H は正しく記録できた2回の平均で1.22ドル。H の3回平均1.10ドルは1回分が未計上)
- 速さを重視するなら 6 Sol(C)、テストの厚みも欲しいなら 6.1 Sol(H)、という使い分けが考えられます
この検証の限界です。
- 課題は小規模な1種類だけで、各構成3回しか試していません
- C と H では Codex CLI のバージョンが違い(0.158.0-alpha.2.1 と 0.159.0)、実行日も1日ずれています。時間の差には、CLI の違いの影響も含まれている可能性があります
- H の2回目は、子の test がタイムアウトで打ち切られ、その分の金額とトークンが計上されていません。時間も打ち切り時点までの値です
- 子への指示ファイルは親が毎回書くので、試行ごとに内容が違います
- 実行した時間帯も違います(日本時間で、C は 09-29 の16〜19時台、H は 09-30 の13時台)。サーバー側の混み具合が生成速度に影響した可能性もありますが、推測です
- GPT-6 Sol の単価は、確認時点の料金ページには載っていなかったため、筆者が把握していた単価を使っています。金額は API 料金での換算額で、実際の請求(ChatGPT プランの定額)とは違います
筆者について
株式会社エム・エー・ディー 取締役の村田です。エンジニア歴24年、EC-CUBEのカスタマイズを中心に、LaravelでのWebアプリやモバイルアプリの開発にも携わってきました。
現在はGoとReactを中心に開発しながら、EC構築の知見とAI駆動開発を組み合わせたDX支援に取り組んでいます。
- EC・AI活用のご相談:https://mad2007.co.jp/contact/
- 一緒に働くエンジニアを募集しています:https://mad2007.co.jp/recruit/