同じモーション制作要件でClaude CodeとCodexを公平に比較するには
見栄えのよい動画を2本並べても、2つのコーディングエージェントを公平に比較したことにはなりません。一方にだけ質のよい素材や詳しいプロンプト、追加の修復機会、もう一方にはないツールが与えられているかもしれません。スクリーンショットを並べるだけでは、そうした違いは見えません。
モーション制作では、特にこの間違いが起きやすくなります。最初のフレームが印象的でも、タイミングの要件を満たしていないモデルもあります。見た目は地味でも、部分的な変更に耐えられる編集可能なプロジェクトを作るモデルもあります。どちらが優れているかは、何を任せたかったのかによって変わります。
モーショングラフィックスでClaude CodeとCodexを比較するなら、同じ受け入れ課題と素材から始め、文言の正確さ、タイミング、操作機能、実用的な成果にするまでに必要だった修復作業を確認します。ここでは、Codexの出力を再生し、シーク操作の不具合を発見して修復するまでを追います。対になる実行ではClaude Codeの認証ができなかったため、モデル同士の比較は未完了です。
必要な能力が表れる課題を選ぶ
「美しい製品動画を作って」では解釈の余地が大きすぎます。よいテストには、実際に伝えるべき内容と、範囲を限定した技術的な成果物が含まれます。例えば、正確な料金文言、任意時刻に確定した状態を表示できるシーク機能、関連する文言を同時に読める時間を備えた、6秒間の編集可能なオファーシーンです。
見た目がシンプルなシーンでも、重要な動作は検証できます。文言の完全一致は事実の保持を、安定した静止区間は時間的な推論を確認します。シーク機能は、冒頭から再生したときだけ成立する一連の手順ではなく、時刻によってアニメーションが制御されているかを確かめます。部分的な変更では、ソースを引き続き制御できるかが分かります。
最初のテストに考えられる機能をすべて詰め込まないでください。ナレーション、音楽、字幕、グラフのデータ、複数の縦横比、複雑なインターフェースまで含めると、失敗の原因を切り分けにくくなります。まず小さな代表課題を使い、それだけでは分からない能力を調べるために2つ目の課題を追加します。
比較対象がコード生成なのか、エージェントの作業全体なのかを決めます。コードだけを比較するなら、ツールを無効にし、自己完結したドキュメントを求めることで条件を揃えられます。作業全体を比較するなら、同等の権限の下で素材を調べ、プロジェクトを実行し、エラーを修復できるようにします。この2つは別の実験であり、1つの順位にまとめるべきではありません。
ツールを導入するチームには、作業全体のテストのほうが適切なことが多いでしょう。役立つ成果はソースコードだけでなく、現実的な工程を通じて得られた、正しく編集可能な制作物だからです。ただし、小規模なコードのみの予備検証も、大きな比較に時間を使う前に、要件や環境の問題を明らかにできます。
制作要件と素材を固定する
両方の実行に、一字一句同じ制作要件を使います。どちらかのエージェントを呼び出す前に保存してください。最初の結果を見てから曖昧さに気づいた場合は、両方に対して要件を修正し、新しい組み合わせを別のテストとして扱います。一方だけに補足を与えてはいけません。
この記事に付随するローカル予備検証では、1280×720の自己完結したHTMLドキュメントを要求しました。架空のシーンの名前はStill Studioで、「US$29 per month」と「US$348 billed annually」を正確に表示する必要がありました。2行とも0秒から0.8秒までに登場し、4.8秒まで安定して表示され、6秒までに退場する条件です。
要件には、画面に表示されるPlay/Pauseとシークの操作機能、2.4秒で一時停止した初期状態、システムのサンセリフ書体、外部素材を使用しないこと、架空の習作であることを示すラベルも含めました。これらは、出力を検査しやすくし、外部画像やフォントによる差を避けるための条件です。
文言と請求の関係は重要です。年額を変えてしまったモデルは、書体の扱いが魅力的でも、事実に関する要件を満たしていません。条件を最後にしか表示しないモデルも、正しい言葉がソースに存在していても、タイミング要件を満たしていません。
実際の製品素材を使う場合は、同一のコピーを渡し、素材の同一性を保持します。一方だけに新しいスクリーンショットや別のロゴを使わせないでください。再配布できない素材はアクセス条件を記し、許可された環境内で比較を行います。
実際に動いた環境を記録する
ツール名だけでは、システム全体を特定できません。CLIのバージョン、実行時に報告されたモデル、関係する設定、使用可能なツール、権限、新規セッションか継続セッションかを記録します。既定のモデルは変わることがあるため、製品名から推測するより、実際に報告されたモデルが重要です。
アカウントへのアクセスとモデルの性能は分けて扱います。ログイン失敗、レート制限、ネットワーク中断は、実務の進行に影響しても、モデルが一度も制作しなかった動画の質を示すものではありません。記録には残しつつ、創作の点数には置き換えないでください。
Codexの実行には、OpenAIプロバイダー経由のChatGPT認証を使いました。ログに記されたCLIバージョンは0.163.0、モデルはgpt-6.1-solで、出力は単独で動作するHTMLドキュメントです。
認証や設定には、異なるアクセス経路を選択する可能性があるため、明示的な確認が必要です。ツール自体のドキュメントを参照し、実際に使った経路を保持してください。ただし、ベンチマークの配布物にトークンや非公開のアカウントファイルを含めてはいけません。Claude Codeの認証ドキュメント
修復前に生の出力を保存する
最初の応答を、制作要件と実行状態とともに、受け取った形のまま保存します。HTMLドキュメントを開くためにMarkdownのコードフェンスを除く必要があるなら、その変換を記録します。黙って構文を修正し、それを元の初稿と呼んではいけません。
失敗したリクエストと完成した制作物を別に保存し、テスト記録で環境構築の失敗と出力の欠陥を区別できるようにします。
コードのみの比較では、返されたドキュメントを編集せずに開きます。必要な言葉が表示されるか、外部依存なしでシーンが読み込まれるか、操作機能が存在するかを確認します。その後、全体を再生し、登場区間、静止区間、退場区間へ直接シークします。
ソースにはrange入力と、時刻に基づく描画関数もありました。しかし、追跡の動作テストでは、操作機能が存在していても、すべてが機能しているわけではないと分かりました。実際の再生は初期状態から3.1秒を越えて進み、6秒に達して停止しました。一方、シークには別の不具合があり、指定した時刻へ移らず、表示時刻が以前の値に留まりました。
見た目より先に意味を評価する
譲れない要件から始めます。正確な事実が存在するか。それらの関係は正しいか。必要な区間に、視聴者が文全体を読めるか。渡した素材を使い、インターフェースの動作を勝手に作り足していないかを確認します。
次に時間的な動作を調べます。中間、開始、登場の境界、退場の境界、終了へ直接シークします。決定的なアニメーションなら、その時刻までどの経路をたどったかに関係なく、期待した状態になるはずです。以前のフレームを再生していないと状態が成立しないなら、信頼できるフレーム描画には向かないソースかもしれません。
視覚的な質を比較するのは、その確認の後です。情報の階層、余白、タイポグラフィー、動きの一貫性、構図がメッセージをどう支えているかを見ます。判断は制作要件に結びつけてください。意図的に控えめに作ったオファーシーンが、別案の演出が派手というだけで劣るべきではありません。
意味の分からない総合点を1つ付けるのではなく、小さな評価基準を用意し、項目ごとに結果を報告します。事実の正確さ、タイミング、編集のしやすさ、視覚的な伝達、納品の確実性は、評価が一致するとは限りません。単一の点数は、チームが理解すべき実際のトレードオフを隠してしまいます。
追跡テストで実際に分かったこと
シークの不具合は、再生が6秒に到達した後にも再現しました。キーボードのHomeを押しても0秒には戻りません。0.8秒、4.8秒、5.4秒を指定するinputイベントを送っても、出力は6秒のままでした。編集者には、全体を再生し直さずに特定の状態を確認する必要があるため、これは重要です。タイムラインが見えるだけでは足りません。
原因はイベントの順序でした。入力ハンドラーは、要求されたスライダーの値を読む前にpause()を呼び出していました。この実装では、一時停止すると以前の状態が操作部にも再描画されます。その後に読み取る値も、以前のものに戻っていたのです。アニメーションの計算が正しくても、検査に使う操作機能が壊れていることはあります。
筆者は別のコピーで、一時停止前に要求値を読み、その後に適用するよう修復しました。元のモデル出力は保持しています。
// Preserve the requested value before pause() renders the old state.
const requestedTime = Number(seek.value);
pause();
state.time = Math.max(0, Math.min(motion.duration, requestedTime));
render();
修復したコピーは、キーボードのHomeとEndに対し、それぞれ0秒と6秒へ移動しました。0.8秒と4.8秒では、料金の2行とも不透明度が完全で、位置の移動はありませんでした。5.4秒では、両方の不透明度が0.5になり、上方向に18ピクセル移動しました。
contenteditableの行を直接「US$39 per month」と「US$468 billed annually」に変更しても、2.4秒では両方が表示されていました。受け入れテストでは、次にその変更を保存し、再読み込みして、描画する必要があります。
表示時刻を読むことは、再生の欠陥とシークの欠陥を切り分ける最も手早い方法です。この元の出力は、再生時には正常に進み、その後の特定状態への移動要求を受け付けません。修復ではイベントハンドラーの順序だけを変え、登場と退場の曲線はそのままにしています。エージェントを対にして比較するなら、これは精密な修復課題になります。シークを直し、6秒の長さと料金の2行を保持したうえで、Home、End、中間の1時刻を確認するのです。
同じ部分修正を依頼する
初稿は課題の半分にすぎません。成功した両方の実行に、同じ修正を依頼します。例えば、月額相当と年額の請求額を変え、レイアウトとタイミングを維持し、2つの文を同時に表示するという修正です。これにより、残りをむやみに書き換えず、限られた箇所を変更できるかが分かります。
元のソースを保持し、修正版と比較します。文言、形状、タイミング、操作機能、素材の参照がどう変わったか確認します。見た目が似ていても、シークの故障や終了時刻のずれが隠れているかもしれません。結果の動作が正しければソースの差分が大きくても許容できますが、確認は必要です。
許容する修復の回数や工数は事前に定めます。一方に徐々に具体的になるプロンプトを3回与え、もう一方には1回しか与えなかったなら、その違いを報告してください。最終的な2作品を、同じ条件の初回結果として扱ってはいけません。支援も、使える結果に到達するためのコストに含まれます。
作業全体のテストでは、同等の権限の下でエージェント自身に制作物を実行・検査させます。実際に使ったツールと、必要だった人間の介入を記録します。読み込みエラーに気づいて直すエージェントは、スクリーンショットだけの比較では見落とされる有用な作業をしています。
根拠のない精密さを装わずにコストを測る
経過時間は測りやすい一方、解釈を誤りやすい数字です。このCodexのリクエストは約179秒かかりましたが、ログにある起動時間とモデル検出のタイムアウトを含みます。純粋な生成速度の測定ではありません。「Codexはアニメーションに3分かかる」と報告すれば、測定の意味を過大に広げることになります。
役立つ比較にするには、ツールで可能な範囲で、準備、リクエスト、修復、描画、人間のレビューにかかった時間を分けます。応答の遅延より、使える制作物を得るまでの総時間が重要なこともあります。初稿が速くても、何度も慎重に修復する必要があれば、遅くても正しい初稿より手間がかかるかもしれません。
実際の課金条件を知らずに、経過時間やトークン数から金額を推測してはいけません。サブスクリプションの使用枠、API課金、キャッシュされた入力、モデル設定は異なる可能性があります。信頼できる費用を取得できない場合は、観測できた使用情報を報告し、費用は未測定にします。
運用上の経緯には失敗も含めますが、分類してください。認証の準備と、モデルが無効なコードを出力することは別です。描画の依存関係の不具合と、読めないデザインも別の問題です。この区別によって、ツールとそれを支える作業方法の両方を選ぶために比較を使えます。
広い結論を出す前に、代表課題を繰り返します。1つの小さなシーンで失敗の傾向は分かっても、製品ローンチ、技術解説、グラフ、ローカライズ、今後のあらゆるモーション制作において、一方のエージェントが総じて優れているとは言えません。
人間の支援を見える形で残す
公平な比較では、リクエストの合間に操作者が行った作業も記録します。足りないパッケージのインストール、素材の発見、ファイル名の訂正、エラーの説明は、最終結果を大きく改善し得ます。その支援が見えないと、人間の貢献がエージェントの成果として扱われます。
どの支援をテストに含めるかを決めます。現実的な作業では、操作者が製品に関する質問に答えたり、ファイルへのアクセスを許可したりするのは妥当でしょう。一方、条件を管理したコード生成の予備検証では、手作業でソースを直せば評価対象の制作物が変わります。どちらも本質的に間違いではありません。問題は、一方をもう一方として示すことです。
短い介入ログを残します。両システムに同じスクリーンショットを渡した、両方に請求文言を補足した、どちらの結果も開く前にローカルサーバーを修復した、といった記録です。一方だけに修復が必要だったなら、それも書きます。最終的な映像が同じくらいよく見えても、追加の作業はチームの判断に関係するかもしれません。
繰り返し実行する際は、操作者の学習とエージェントの性能を分けて考えます。最初のシステムを試した後では、操作者が課題をよく理解し、次のシステムにより有用な指示を出すかもしれません。実行順を交互にしたり、開始前にすべての入力を固定したりすれば、この有利さを抑えられます。小さなローカル検証で変動要因をすべて排除できなくても、見える形にはできます。
視覚的な完成度からすぐに判断したくなるモーション制作では、この透明性が特に役立ちます。慎重な手作業でタイミングを調整した結果を、手を加えていない一発生成と説明すべきではありません。読者は制作の経緯を理解したうえで、その作品を評価できます。
他の人が検査できる結果を公開する
信頼できる比較には、制作要件、素材一式または入手方法、環境記録、生の出力、修正プロンプト、描画設定、観測した確認結果が含まれます。魅力的な比較画像だけを信じなくても、読者が結論の根拠を理解できるようにします。
結果は、確認した要件の範囲で述べます。初期状態では文言の完全一致を確認できた、再生は終端に達した、修復前はシークに失敗した、という範囲です。後で対にした実行を行う際にも、同じ制作要件と確認項目を使い、各エージェントが制作物をどう診断・修正するか比較できます。