Claude Code vs Codex―同一プロンプトでWPFアプリを作らせたら、仕様の「Why」を読めたのは片方だけだった
はじめに
前稿 "Claude Code vs Codex――同じワークフローで2本のシステムを作って感じた違い" では、AILBA（約2万行）と MSH（約4万行）という異なる規模のWebシステムをそれぞれ Claude Code と Codex で開発して比較しました。
今回はもっとフェアな条件、つまりまったく同じプロンプトを与えて、両者にどう違いが出るのかを確かめたくなり、小規模なユーティリティを題材に検証してみました。
結論を先に言うと、こういうことです。
アルゴリズム的には2日もあれば実装・検証できるレベルの単純なツール。なのに仕様要求側から見ると Claude Code の圧勝でした。差分は数行レベルの違いに見えるかもしれませんが、その数行が「使えるツール」と「使い物にならないツール」の境目を作っていたのです。
AIベンチマークが小数点以下の差を競っている中で、ベンチマークには現れない実務的な差がここまで出るのか、というのが正直な感想です。
検証セットアップ
対象アプリケーション
既存の C# WinForms ベースの分析装置制御アプリに、独立した Utility Tool として組み込む Mass Calculator を実装させました。
仕様の要点はこうです:
- 任意の分子式から、同位体を考慮した取り得る質量と存在比率をすべて計算する
- 分子式は再帰下降パーサで解析（
Ca(OH)2やFe2(SO4)3のような括弧付きにも対応） - 結果は DataGrid と ScottPlot による棒グラフで表示
- 新規モジュールは WPF/MVVM で実装
- 同位体テーブルは原子番号 1〜92 の全元素を対象、精密質量を使用
- 同位体データは最低 2 ソース（NIST、IUPAC、理科年表など）からクロスチェック
- グラフのマウス操作は既存の
Viewer.cs（WinForms 版 ScottPlot 使用）の挙動を踏襲
なぜ WPF を必須条件にしたか
メインアプリは WinForms で開発されてきましたが、今後を見据えて段階的に WPF へ移行する方針です。新規機能はすべて WPF で開発し、既存 WinForms 部分も逐次 WPF 化する――その第一歩として、今回の Mass Calculator は WPF/MVVM を必須条件にしました。
つまり「動けばどちらでもいい」という話ではなく、WPF 化は仕様であり戦略です。この前提を踏まえると、後述の ScottPlot 採用版の差は単なる技術選定ミスでは済まない意味を持ちます。
同様のものは Python の IsoSpecPy や pyteomics で簡単に書けますが、既存の C# アプリに組み込みたかったのと、AIエージェントの実力を測る題材として手頃なサイズだったので、自前実装を依頼することにしました。
なお実装にあたっては、プロンプト以外に Skills などのエキスパートナレッジは一切使用していません。純粋にプロンプト1本での生成能力比較です。
比較対象
| エージェント | モデル |
|---|---|
| Claude Code | Opus 4.7 |
| Codex | GPT-5.5 Medium |
| Codex | GPT-5.5 Extra High |
共通プロンプト
仕様書は約 9,000 字の Markdown で、再帰下降パーサの EBNF、畳み込みアルゴリズムの O(log n) 化、Bin 集約ルール、DataGrid 列定義、ScottPlot 操作仕様、同位体テーブルのデータソース要件、テストケースまで網羅したものです。
仕様書の重要部分（抜粋）:
5.6 Abundance Plot (ScottPlot)
- ライブラリ: ScottPlot.WPF (NuGet パッケージ
ScottPlot.WPF、最新の WPF 対応バージョン)- 操作仕様は
Menu_Analyzer/Viewer.cs内の ScottPlot 操作を参照 すること。
- ただし
Viewer.csは WinForms ベースのため、ScottPlot.WPF への API 移植を要する。操作の挙動 (UX) は Viewer と一致させる ことを最優先とする。
4.3 参照ソース (最低 2 か所からのクロスチェック)
- 理科年表 (国立天文台編、最新版)
- NIST Atomic Weights and Isotopic Compositions (NIST Standard Reference Database 144)
- IUPAC Technical Report (Meija et al., "Isotopic compositions of the elements 2013/2021")
- AME (Atomic Mass Evaluation) 2020 (精密質量の最高精度)
これらが「WPF 化の指示」と「同位体テーブルの 2 ソース照合」という、後で大きな差を生む 2 つの要点です。
結果サマリ
| Opus 4.7 | GPT-5.5 Medium | GPT-5.5 Ex High | |
|---|---|---|---|
| 実行時間 | 21分 | 11分 | 22分 |
| ソースコード行数（本体） | 1,878行 | 959行 | 1,786行 |
| テストコード行数 | 480行（51件） | 166行（38件） | 184行（25件） |
| ScottPlot 採用版 | ✅ WPF 版 | ❌ WinForms 版 | ❌ WinForms 版 |
| マウス操作の踏襲 | ✅ 完備 | △ 機能漏れ | △ 機能漏れ |
| 同位体テーブル | ✅ 92元素フル | ❌ 主要元素のみ | ✅ 92元素フル |
| 2 ソース照合 | ✅ 透明性開示あり | ❌ 1ソース | △ 主に1ソース |
| 仕様への確認質問 | ✅ 誤記・曖昧箇所を指摘 | ❌ なし | ❌ なし |
数字だけ並べると Ex High が善戦しているように見えますが、実際にツールを使う立場で評価すると話が変わってきます。順に見ていきましょう。
決定的な差 ①：WPF 化指示の解釈
仕様書には「ScottPlot.WPF を使用」「新規モジュールは WPF/MVVM」と明記してあります。にもかかわらず、両 GPT-5.5 とも ScottPlot.WPF の WpfPlot コントロールを使わず、既存アプリで使われている WinForms 版の FormsPlot を WindowsFormsHost 経由で WPF Window 内に埋め込むという選択をしました。
GPT-5.5 Medium のログから、その判断の瞬間を引用します。
注意点: ScottPlot.WPF 5.0.55 のパッケージ内に通常の WpfPlot コントロールが見当たらなかったため、画面は WPF Window 内で既存と同じ ScottPlot.WinForms.FormsPlot を WindowsFormsHost 経由で使用しています。
これは事実誤認です。ScottPlot.WPF 5.0.55 には WpfPlot コントロールがちゃんと存在します。実際 Claude Code (Opus 4.7) は同じパッケージで WpfPlot を直接使って実装しています。
<!-- Opus 4.7 の MassCalculatorWindow.xaml より -->
xmlns:scott="clr-namespace:ScottPlot.WPF;assembly=ScottPlot.WPF"
...
<scott:WpfPlot x:Name="MassPlot"/>
GPT-5.5 Ex High も同様に「WpfPlot が見当たらない」と判断して WinForms 版を採用しています。NuGet パッケージの中身を直接調べに行ったログまであるのに、結論として誤った道を選んでいるのが興味深いところです。
実害があるのか？と聞かれると正直「動けばいいじゃない」とも言えます。実際、ツールとしては動きます。ただ、WindowsFormsHost 経由の埋め込みはフォーカス管理・DPI スケーリング・キーボード入力の WPF 統合で確実に余計な問題を抱え込みます。実際、後述の「キー入力ができない」バグは、両 GPT-5.5 版で WindowsFormsHost 由来のフォーカス問題として顕在化しています。
仕様で明示した技術選定を、勝手に「より安全そうな」既存技術に置き換えてしまう――これは仕様策定者の意図を尊重しないという意味で、地味に困ります。
決定的な差 ②：同位体テーブルの作り込み
これが今回いちばん本質的な差です。Mass Calculator にとって同位体テーブルは心臓部で、ここの精度がそのままツールの存在意義を左右します。
Opus 4.7：92 元素フル + 透明性開示
IsotopeTable.cs は 523 行、原子番号 1〜92 の全元素データを直接埋め込み。IsotopeTableTests.cs で「全 92 元素について存在比率合計が 1.0 ± 1e-6」の検証まで実装しています。
さらに印象的だったのは、ユーザーが「同位体テーブルの参照ソースは？」と問い合わせた際の Opus の返答です。ログから引用します。
同位体テーブル参照ソースの問い合わせ → References.md 内容と「LLM 訓練データ由来で 1 件 1 件の公表値照合は未実施」を透明性開示
つまり「学習データから引いた値で、個別の公表値照合は未実施です」と正直に開示しています。これは AI エージェントとしてかなり誠実な姿勢で、自分の出力の信頼性限界を明確にしているわけです。実装者としても「ここは後で人間が NIST と突き合わせる必要がある」と判断材料を得られます。
GPT-5.5 Medium：主要元素のみ + プレースホルダー
対照的に GPT-5.5 Medium のログにはこんな記述があります。
正直に言うと、現状の IsotopeTable.cs は完全な出典トレース付きデータセットではありません。H, C, N, O, S, Cl, Br など主要元素は一般的な NIST/IUPAC 系の値に基づく自然存在比率・精密質量を入れていますが、H-U 全 92 元素のうち未詳細化の元素は「単一同位体、存在率 1.0」のプレースホルダーです。
仕様で「原子番号 1〜92 の自然存在元素」を要求したのに、主要元素以外はフェイクデータで埋めているわけです。
これがどう実害として出るかを示すのが、冒頭で挙げた W (タングステン) の比較画像です。
Opus 4.7 版（左：実用的に正しい）
W (タングステン) の自然界の同位体（180W, 182W, 183W, 184W, 186W）すべてが正しく計算され、184W が約 30.6%、186W が 28.4%、182W が 26.5%、183W が 14.3%、180W が 0.12% という、理科年表や NIST と一致する分布が得られています。質量分析の現場で W のスペクトルパターン同定にそのまま使える品質です。
GPT-5.5 Medium 版（右：ツールとして使えない）
同じ W を入力したのに、結果は 184W = 100.0% の単一ピーク。プレースホルダーの「単一同位体、存在率 1.0」がそのまま結果に出ているわけです。
これは「結果が間違っている」というより、計算ツールとして根本的に成立していない状態です。仕様書の検証要件「全元素について存在比率合計が 1.0 ± 1e-6」は確かに通る（プレースホルダーでも合計1.0なので）のですが、検証要件は満たしても目的を果たしていないという、AI生成コードでよく遭遇する罠の典型例です。
GPT-5.5 Ex High：92 元素は埋まっているが照合は弱い
Ex High は 92 元素分のデータをきちんと埋めています。IsotopeTable.cs は 644 行と Opus を上回る規模です。
ただし「2 ソース照合」の要件については、ログでこう答えています。
はい、2系統は記録されています。
- Primary source: NIST Atomic Weights and Isotopic Compositions, SRD 144
- Cross-check source: IUPAC/CIAAW Standard Atomic Weights 2021 / IUPAC isotopic-composition publications
ただし注意点として、実データ生成元は主に NIST で、IUPAC はクロスチェック元として記録されています。また、Tc / Pm / Po / At / Rn / Fr / Ra / Ac の代表同位体 fallback は「自然存在比データなし」として NIST SRD 144 の代表質量のみを使っています。厳密に「全 isotope 値を2ソースで照合した証跡」まで求めるなら、参照メモをもう少し増やした方がよいです。
これは Opus の「LLM 訓練データ由来」開示とは方向性が違います。Ex High は「2ソース参照しました」と言いつつ、よく聞くと「実質1ソース、もう片方は名前だけ」という構造です。Opus の「正直、学習データです」と比べると、どちらが実装者にとって判断材料として価値があるかは明らかです。
決定的な差 ③：マウス操作の踏襲
仕様書の「Viewer.cs の ScottPlot 操作を踏襲」という指示への対応にも差が出ました。
これは既存アプリの他のスペクトル表示画面と操作感を統一するための指示で、ユーザビリティ上重要です。質量分析装置のオペレータは複数の画面を行き来するので、画面ごとにマウス操作が違うとストレスになります。
Opus 4.7 は左ドラッグ=パン、ホイール=ズーム、右クリックドラッグ=矩形ズーム、ダブルクリック=リセット、ホバー=ツールチップを WPF API に正しく移植して全機能実装。GPT-5.5 系は機能漏れがあり、特にホバー時のツールチップ表示は WindowsFormsHost 経由のフォーカス問題で挙動が安定しませんでした。
決定的な差 ④:仕様の曖昧さに対する振る舞い
これは検証中に偶然気づいた違いですが、振り返ってみると他の3つの差を生んだ根本要因に近いかもしれません。
仕様書を書く側も人間なので、9,000字の中に曖昧な記述や、よく考えると一般的な事実と食い違う箇所が残ります。今回の仕様書にもいくつかありました。
Opus 4.7 はそうした箇所に対して、実装に着手する前に確認質問をしてきました。「この記述は◯◯と解釈してよいか」「この値は△△の意味か、それとも□□の意味か」といった、設計レビューでよくあるやり取りです。
例えば、
- 「この条件だと既存実装方針と競合するが、どちらを優先するか」
- 「この指定は一般的な物理用語との定義と乖離しているが意図的か」
こちらの仕様書の誤記を指摘してきたわけです。仕様策定者として、これは率直にありがたい挙動です。
一方で GPT-5.5 系は同様の質問をせず、仕様書の記述をそのまま実装に通しました。GPT-5.5 でも同じ気づきはあり得たはずですが、確認のステップを踏まず先に進む傾向がはっきりありました。
この差が、結果的に他の3つの差にも効いていると考えています。
- WPF 化の指定 → ScottPlot.WPF の
WpfPlotの実在を確認せずに「見当たらない」と判断 - 92 元素データ → プレースホルダーで埋めることの是非を確認せずに実装
- 2ソース照合 → 1ソースで進めることの妥当性を確認せずに「2ソース」と表記
つまり**「曖昧さに突き当たったら確認する」という基本動作の有無**が、コードの隅々に効いている可能性が高い、ということです。
仕様策定者の視点で言えば、確認質問をしてくれるエージェントは「もう一人のレビュアー」として機能します。完璧な仕様書を書くのは現実的に不可能なので、エージェント側が抜けや誤記を指摘してくれるのは、設計品質への直接的な貢献です。
それでも GPT-5.5 が悪いとは言い切れない側面
公平のために GPT-5.5 の良かった点も挙げておきます。
- Medium は11分で完走。Opus の半分の時間。スピード感は確かにある
- Ex High も 92 元素データを埋めた。Medium のプレースホルダー問題は Ex High では発生していない
- テストはどちらも緑で完走（25〜38件）。仕様書のテスト要件はクリア
- 基本機能は動作。分子式パース、畳み込み、Bin 集約、DataGrid 表示はいずれも実装
つまり「仕様書のチェックリスト項目はだいたい埋まる」のです。問題は「仕様書の文字列の裏にある意図」を汲み取って実装しているか、という点です。
- ScottPlot.WPF を指定したのは「
WindowsFormsHostの落とし穴を避けたい」から - 2ソース照合を指定したのは「根拠の透明性を担保したい」から
- 92 元素全部と書いたのは「主要元素以外でも使えてほしい」から
このメタな意図を、Opus は概ね汲み取っていて、GPT-5.5 系（特に Medium）は機械的にチェックリストとして処理した、という違いに見えます。
共通の課題：WPF キー入力問題
念のため言っておくと、3 つともすべて初回起動時の WPF キー入力問題は出ました。
WinForms アプリからモードレスで WPF Window を開くと、ElementHost.EnableModelessKeyboardInterop() の呼び出しが必要です。これを最初から仕込んでいたエージェントはなく、ユーザーが「キー入力できません」と報告してから対応する形になりました。
これは AI の能力差というより、WinForms + WPF ハイブリッドアプリのお作法が学習データに十分含まれていない可能性があります。プロンプトに EnableModelessKeyboardInterop を明記しておけば全員が即対応できたはずなので、これは私の仕様書の漏れと認めるべきところです。
ベンチマークには現れない差
冒頭にも書きましたが、AI コーディング能力のベンチマーク（SWE-Bench、HumanEval 等）は単体タスクの成否を％で測ります。今回の検証で見えたのは、そのベンチマークではほとんど捕捉できない種類の差です。
ベンチマークが捉えにくいもの:
- 仕様の指定技術を尊重するか（WPF 指定を勝手に WinForms 互換にすり替えない）
- データの透明性に対する誠実さ（学習データ由来であることを開示する）
- 網羅性の品質（92元素埋めるときにプレースホルダーで済ませるか、実データを当てるか）
- メタ意図の読解（指定の裏にある「なぜそう要求したか」を推測する）
今回の小さなツールでこれだけの差が出るということは、より大きなプロジェクトでは雪だるま式に差が広がる可能性が高いと想像します。実際、前稿の AILBA / MSH の比較でも似たような傾向は感じていましたが、今回のように「同一プロンプト・同一目的物」で並べると違いが鮮明になりました。
仕様書ドリブンの意義（再確認）
ハードウェアエンジニア出身の私としては、AI エージェント時代こそ「仕様書ドリブンな開発文化」が活きると改めて感じています。今回の仕様書は約 9,000 字、EBNF まで書き込んだ精密なものでしたが、それでも「ScottPlot.WPF を使え」「2ソース照合せよ」のような当たり前に思える指定が当たり前に守られないケースがあります。
これは AI エージェントを責める話ではなく、仕様の意図を Why も含めて書くべきだという教訓です。次回からは仕様書に「Why セクション」を追加して、「なぜ ScottPlot.WPF か（WindowsFormsHost のフォーカス問題回避）」のような背景まで書こうと思います。
まとめ
| 観点 | 結果 |
|---|---|
| 純粋な実装速度 | GPT-5.5 Medium > Opus 4.7 ≒ GPT-5.5 Ex High |
| 仕様書のチェックリスト遵守 | 全員クリア |
| 仕様の意図の汲み取り | Opus 4.7 が頭一つ抜けている |
| コア機能の品質 | Opus 4.7 のみ実用品質 |
| 仕様の曖昧さへの対応 | Opus 4.7 のみ確認質問あり |
| 透明性・誠実さ | Opus 4.7 が顕著に高い |
「アルゴリズムが単純なら結果も似るだろう」という事前予想は外れました。単純なツールでも、仕様要求側から見たときの実用品質には大きな差が出るという、ベンチマーク数字には現れない実務的な発見でした。
もちろん、別のタスクではまた違う傾向が出るかもしれません。今回はたまたま Claude Code に有利な題材だった可能性も否定はできません。それでも、「同位体テーブルの 2 ソース照合」という、私のドメイン（質量分析）にとって本質的に重要な要求を、Opus がきちんと汲み取って実装し、さらに自分の出力の限界まで開示してくれたという事実は、ベンダーニュートラルに見ても価値ある結果だと感じています。
仕様書ドリブンの開発スタイルは、AI エージェント時代でも――いや、AI エージェント時代だからこそ――引き続き有効です。そして、仕様書に書いた「文字」と、その裏にある「意図」の両方を読めるエージェントが、最終的に頼りになる相棒になるのだと思います。
30年分の経験と判断をAIに言語化させる試み自体が、このブログのテーマです。
Discussion