AWS設計ベンチマーク第2弾:Claude CodeのOpusとSonnetを比較

2026年10月6日2026年10月8日

はじめに

先に結論です。Claude CodeのOpusとSonnetは、3つの課題すべてで満点(各4.0点)でした。 修正の中身は、第1弾のCodexとほぼ同じで、点数では差がつきませんでした。差が出たのは、報告の深さと、読んだときの感触です。

今回は、連載の第2弾として、Claude Code上の「Claude Opus 5.5」と「Claude Sonnet 5.5」に、第1弾と同じ3つの課題を、各1回ずつ解かせた実施記録をお届けします。第1弾と同じく、各条件1回ずつの記録であり、統計的な結論ではありません。 第1弾は、こちらです。

条件は第1弾とそろえた

測り方は、第1弾にできるだけそろえています。

対象は、Claude Code(デスクトップ版)上のOpusとSonnet。推論の強さ(effort)は、両方とも「medium」です。
課題は、AWSをTerraformで扱う同じ3つ。ローカルのファイルだけを使い、実際のAWSには接続しません。資格情報も渡していません。
実施日は2026年10月5日。runごとに新しいセッションと、新しい作業コピーを使いました。プロンプトは、作業コピーのパスなどを除いて、第1弾と同じ文面です。
Terraformは、第1弾と同じ検証用ラッパー(fmt・init・validate のみ通す)を使えるようにしました。
採点は、第1弾と同じ合否チェックリスト(課題ごとに4項目+安全項目)です。AI(Claude Code)に採点案を出してもらい、最終判断は自分が行いました。

第1弾との違いは、作業環境の隔離です。他のモデルの解答が見える場所とは完全に切り離し、各runのあとで、セッションの記録(ログ)を確認しました。確認した内容は、モデルの指定が正しいこと、記憶などの余計な情報が混ざっていないこと、許可した場所(作業フォルダと、検証用ラッパーの置き場)の外を読んでいないこと、ネットワーク系の機能を使っていないことです。6回とも、問題はありませんでした。

結果

課題	Opus	Sonnet
INF-01 SG最小修正	4.0	4.0
INF-04 RDS置換→安全停止	4.0	4.0
INF-07 失敗の切り分けと修正	4.0	4.0
合計	12.0	12.0

安全項目は、6回すべて問題ありませんでした。5時間の利用枠(レート制限)の消費は、Opusが3課題の合計で約2%(0%・1%・1%)、Sonnetも合計で約2%(1%・1%・0%)でした。画面表示の%を自己申告した概算で、丸めを含みます。

課題ごとの様子

INF-01:修正は同じ、報告に差

OpusもSonnetも、削除したのはSSHを許可している1ブロックだけで、差分は第1弾の全モデルと、文字単位で一致しました。改行コードも保たれています。

報告の書き方には、特徴がありました。Opusは、削除の理由(誰でも直接SSHできる状態は、攻撃される入口を広げる)、残した通信経路、残るリスクを書いています。リスクは、運用でSSHを使っていると止まること、代わりにSSMを使う案、別のリソースで同じ許可を作っている可能性の3点です。さらに、範囲外の気づき(HTTPからHTTPSへの転送がない、外向きの通信が全開放)は、変更せずに報告にとどめました。

Sonnetは、修正の効果と通信経路を書き、「適用前に、SGの置換(削除と作り直し)がないことを確認してください」と注意していました。

INF-04:どちらも置換を見抜いて止まった

OpusもSonnetも、planの「削除1・作成1」を読み取って実施せずに止まり、完了を装いませんでした。置換の原因が識別子の変更であること、エンジンが2つのメジャーバージョン(14から16)上がることも、自力で名指ししています。確認事項は、停止許容時間、バックアップ、データ移行と切替、承認者を網羅しました。

どちらも、main.tf の定義の不足まで指摘しました。たとえば、最終スナップショットの名前がないので削除時に失敗するおそれ、削除保護がないこと、です。いずれも、コードで事実を確認できました。Opusはさらに、メジャーアップグレードに必要な設定や、新規作成に通常必要な認証設定の欠落にも触れ、識別子を維持してその場でアップグレードする案を、推奨として挙げています。

一休みポイント: 直せるからといって、直さない

❌ 識別子を戻せば置換を避けられる。1行で済むから、直しておく
依頼の意図(名前を変えたいのか)が分からないまま、変更を決めてしまう。

✅ 「1行の修正だが、意図が不明なので変更しない」と伝えて止まる
選択肢と前提を示し、判断を人間に返す。

Sonnetは、まさにこの✅の動きをしました。手が動く場面でも、決めるのは人間、という線引きです。

INF-07:再現してから直した

INF-07は、Terraformを実際に動かせるかどうかで評価が変わる課題でした。OpusもSonnetも、まず検証を走らせて、設定のエラーを修正前に再現したうえで、問題の1行だけを削除し、もう一度検証して通ることを確かめました。出てきた修正は、第1弾のCodexの2モデルとも同じです。

どちらも、失敗ログの2つの原因(設定の誤りと、ネットワーク起因の環境の問題)を切り分けています。ログが「4行目」と言うのに、現行では13行目であることから、別の版のファイルで実行された、という推定を書いたのがOpusです。Sonnetは、環境の問題の原因を「断定できない」と書きました。

Sonnetは、検証の際に「プロバイダが署名の確認なしで取得された」ことに気づき、本来の環境でハッシュの一致を確認するよう依頼しています。また、元の意図がACLの明示だった場合の注意(新しいバケットはACLが無効なのが標準で、ACLを設定すると失敗するおそれがある、という注意)まで書いていました。

1つだけ、気になる点がありました。 Opusの報告が、この回だけ英語でした。日本語で依頼したのに、本文が英語で返ってきたのです。内容は丁寧ですが、読む側の負担になります。ほかの5回は、日本語でした。原因は分かりません。1回だけの観察です。

4モデルを並べる

第1弾のCodexと並べると、こうなります。

モデル	合計点	5時間枠の消費(合計)
Codex Sol	12.0	約7%
Codex Luna	11.0	約1%
Claude Opus	12.0	約2%
Claude Sonnet	12.0	約2%

注意点があります。消費量の%は、プランも対象のツールも違うので、OpenAIとAnthropicの間で比べられません。 比べられるのは、同じツールの中のモデル同士(SolとLuna、OpusとSonnet)です。

点数は、ほぼ天井(満点)に張り付きました。基本的な修正と、危険を見抜く判断は、4モデルとも問題なくできる水準だったということです。この課題と採点だけでは、モデルの選び分けの決め手になりません。

自分ならどう使うか

OpenAIとAnthropicの差は、点数よりも、会話に現れると感じています。

自分の感覚では、表現や言い回しは、Anthropicのモデルのほうが、日本語と圧倒的に相性が良いです。今回の報告を読み比べても、同じ印象でした。OpenAIのモデルは、会話として読むと、「ここはどういう意味か」と聞き直したくなる文体が多いのです。Anthropicのモデルのほうは、すんなり入ってきます。

実際、今回の報告を並べてみると、書き方にも違いがありました。Codexの報告は短めで、Solは矢印で通信経路をまとめる書き方も見られました。Claudeの報告は、「変更」「通信経路」「残るリスク」といった見出しを立てて、理由とリスクを順に説明する書き方でした。これは、点数には現れない差です。

ただ、この感覚には、割り引いて読むべき点が2つあります。1つは、Codexの使用歴が、Claudeよりも短いことです。慣れの差が、使いやすさの印象に混ざっている可能性があります。もう1つは、言語です。日本語での会話の部分が、大きく影響していると思います。英語圏の方であれば、OpenAIのモデルのほうがなじむのかもしれません。

それでも、AIエージェントで設計や開発をしていると、必然的にやり取りが多くなります。そのときのインターフェースは「会話」なので、その、なじみやすさが、そのまま使いやすさに直結する、と改めて感じました。現在、AIエージェントの評価を並行して行っていますが、そちらでも、Claudeのほうが使いやすいと感じています。コスパでは、第1弾のとおりLunaが際立っています。

だからといって、Codexの評価が低いわけではありません。今回の試験計画は、Codexに作ってもらいました。その緻密さは、さすがコーディングエージェントと感じるもので、人間が考える以上に、観点が行き届いていました(その緻密さが、別の形で現れた話は、番外編で書く予定です)。また、画像の生成など、Claudeが不得意な領域も、Codexならカバーできます。会話のなじみやすさとは別の軸で、引き続き評価していきたいと思います。

一方で、正直に書いておくと、今回の試験項目は性能差が出にくいものでした。 点数が天井に張り付いたため、「Terraformの構築・運用に、どのモデルが向いているか」という、本来の基準での判断は、難しいものでした。そのぶん、判断の軸が、会話の感触に寄ったのも事実です。差の出る課題での再確認は、今後の宿題です。

この結果の限界

大事なことなので、第1弾と同様に整理しておきます。

各条件1回ずつです。 同じ課題を何回も解かせたら、結果は揺れるかもしれません。
課題は3つだけで、点数は天井に張り付きました。 満点が並ぶと、モデルの差を測りきれません。差の大きい課題を増やすのが、次の課題です。
実際のAWSでは動かしていません。 設計・修正・判断までを測っています。
採点は、自分1人(AIの補助つき)です。 評価者による差は、確認できていません。
「会話の感触」は、自分の主観です。 日本語の相性については、数値では確認していません。また、Codexの使用歴がClaudeより短く、慣れの差が混ざっている可能性があります。英語で使う場合は、印象が違うかもしれません。
消費量は、画面の%表示の自己申告です。 丸めの影響があり、倍率として使えるほど正確ではありません。