【ITニュース解説】Opus 5.5 vs Sonnet 5: the pricier model wrote my code for about half the cost

ソフトウェア開発において、AIモデルの活用は効率向上とコスト削減の鍵を握ります。特に、コードの生成やレビューをAIエージェントに任せる動きが活発です。この記事では、Anthropic社の新しいAIモデル「Opus 5.5」が、より安価な「Sonnet 5」よりも実際の開発コストを大幅に削減できた理由を解説します。AIモデルの性能だけでなく、「使い方」がコストにどう影響するかを理解することは、システムエンジニアを目指す上で非常に重要です。

まず、AIエージェントを用いた開発プロセスを見てみましょう。このプロセスはいくつかの段階に分かれています。 最初に「リードモデル」というAIが、GitHubにある開発課題を読み込み、複数の小さな作業に分割します。これらの作業は、それぞれ異なるファイルを扱う「レーン」として割り当てられます。 次に、各レーンに配置された「実装エージェント」が、割り当てられた作業に基づいてコードを書き、そのコードを「プルリクエスト（PR）」として提案します。PRとは、コードの変更を開発チームにレビューしてもらい、最終的にメインのコードに組み込むことを依頼するものです。 実装エージェントがPRを作成した後、「レビューアエージェント」がそのPRをチェックします。レビューアは、コードのテスト実行、意図的なコード破壊によるテストの挙動確認、PR説明と実際の変更内容の一致確認などを行います。レビューアが「合格」と判断しない限り、コードはマージされません。もし「修正が必要」と判断されれば、PRは実装エージェントに戻され、修正と再レビューのサイクルが繰り返されます。

AIモデルの利用費用は、主にAPI（プログラム間の通信窓口）の利用料として発生します。これは、ユーザーが送る指示（入力）やモデルが生成する回答（出力）の量に応じて計算され、その単位は「トークン」と呼ばれます。 一見するとOpus 5.5のAPI単価はSonnet 5の2倍と高価に思えます。しかし、AIエージェントを実際に運用すると、コストの大部分は入力や出力のトークン単価だけでは決まらないことが明らかになりました。 エージェントは一つの作業を完了させるまでに、何度もAPIを呼び出します。そのたびに、これまでの会話履歴や読み込んだファイル、テストログなど、大量の情報をモデルに送り直す必要があります。このとき、多くの情報は「プロンプトキャッシュ」と呼ばれる一時保存領域から再利用されます。キャッシュからの読み込みは比較的安価ですが、エージェントが何百回もAPIを呼び出すと、その費用は積み重なります。 分析の結果、AIエージェントのコストの約68%が「キャッシュからの読み込み」に費やされており、次いで「キャッシュへの書き込み」（22%）、「モデルの出力」（10%）という内訳でした。 特に重要なのは、Opus 5.5とSonnet 5の「キャッシュからの読み込み」の単価は同じ$0.20/100万トークンだったことです。Opus 5.5の方が入力、出力、キャッシュへの書き込みの単価はSonnet 5の2倍ですが、コストの大部分を占めるキャッシュからの読み込み単価が同じであるため、Opus 5.5全体のコストはSonnet 5より約25%程度高くなるだけで、倍にはなりませんでした。 このことから、AIエージェントのコストを左右するのは、「トークンあたりの価格」よりも「エージェントが目的達成までに何ステップかかるか」そして「各ステップでどれだけの情報（コンテキスト）を引き継ぐ必要があるか」であることが判明しました。コンテキストとは、AIモデルが現在の状況を理解するために参照する、過去の会話履歴や関連情報の塊を指します。コンテキストが大きすぎると、API呼び出しのたびに送受信するデータ量が増え、コストがかさみます。

Opus 5.5がSonnet 5よりも「少ないステップ」で、かつ「より小さなコンテキスト」で作業を完了させる能力を持つことが、コスト削減の主な理由です。 具体的には、Opus 5.5はコードを100行変更するあたり、Sonnet 5に比べてAPI呼び出し回数が6分の1、読み込むコンテキストの量が10分の1、出力されるコードの量が3分の1で済みました。これはOpus 5.5が「より効率的」かつ「より簡潔に」コード生成や修正を行えることを意味し、結果として全体のコストを大幅に抑えられました。 特にコスト削減効果が大きかったのは、コードの「修正ラウンド」です。最初のコード作成にかかる費用は両モデルでほぼ同じでしたが、レビューで「修正が必要」と判断され、コードを修正する段階でOpus 5.5の優位性が顕著になりました。 Sonnet 5は作業を進めるうちにコンテキストが最大90万トークンにも膨れ上がることがあり、小さな修正でもこの巨大なコンテキスト全体を毎回モデルに送り直す必要があったため、修正のたびに高額な費用が発生していました。 一方、Opus 5.5はピーク時でも平均17万トークンと、Sonnet 5よりもはるかに小さなコンテキストで作業を進められました。また、Opus 5.5が作成したPRは、Sonnet 5よりも少ないレビューラウンド（Opus 5.5が平均2ラウンドに対し、Sonnet 5は平均3ラウンド）で合格する傾向があったため、修正ラウンドでのAPI呼び出し回数とコンテキストの再読み込みコストが劇的に削減され、全体として安価な運用が実現しました。

コードレビューを行う「レビューアエージェント」でも、Opus 5.5は優れたコストパフォーマンスを発揮しました。従来使われていた「Fable 5.1」と比べ、Opus 5.5の価格に換算するとレビューコストは同程度でしたが、実際のAPIリスト価格ではFable 5.1が約2.7倍も高価でした。加えて、Opus 5.5の方がレビュー処理も高速でした。 レビューの厳格さにおいて、両モデルに大きな差はありませんでした。どちらのモデルも、最初のレビューでほとんどのPRを不合格にする傾向があります。 興味深い発見として、Opus 5.5とFable 5.1の両方で同じPRをレビューさせたところ、それぞれが相手が見逃したセキュリティ上のバグを発見しました。このことから、単一のAIレビューアだけでは完璧ではないことが示唆されました。この問題に対しては、高価なモデルを複数導入するのではなく、「レビューアのチェックリストに特定のバグの種類を追加する」といったプロセス側の改善で対応することになりました。 また、AIモデルに「より高い推論努力」を求めても、Sonnet 5ではコストが増加するだけで、レビュー結果の改善には明確な効果が見られませんでした。Opus 5.5は「中程度」の努力で十分な結果を出しており、不必要な努力レベルの設定はコストの無駄につながると分かりました。

これらの分析結果に基づき、開発プロセスにはいくつかの重要な変更が導入されました。 まず、コードの実装とレビューの両方にOpus 5.5を使用し、Fable 5.1の利用は停止されました。 次に、エージェントの推論努力はデフォルトで「中程度」に設定されましたが、本番環境のコードレビューや、認証、暗号など特に重要な領域のレビューでは「xhigh」や「max」といった高い努力レベルが設定されます。実装エージェントが「xhigh」に昇格するのは、2回目のレビューで明確な動作不良が指摘された場合のみです。 最も大きなコスト削減策として、エージェントのコンテキストが40万トークンに達した時点で、よりコンパクトにする処理を導入しました。これにより、巨大なコンテキストを毎回読み込み直すコストを大幅に削減できます。 さらに、レビューアのキャッシュ時間を5分から1時間に延長しました。再レビュー時に、レビューアが毎回コンテキストを再構築する費用を抑えるためです。 また、PRが追加または変更するテストごとに、そのテストが失敗するようなコード変更をPR本文に明記することを義務付けました。これにより、レビューアが処理を開始する前に、不適切なPRをふるいにかけることが可能になります。

この分析は厳密な対照実験ではありませんが、AIエージェントを使った開発作業においては、「トークン単価」そのものよりも、「エージェントが目的を達成するまでに必要なステップ数」と「各ステップで引き継がれるコンテキストの量」が最終的なコストを決定づけるという重要な教訓を示しています。したがって、AIモデルを選定する際には、単に単価を見るだけでなく、作業単位あたりのAPI呼び出し回数やコンテキストの効率的な管理能力を評価することが、AI技術を実務に導入するシステムエンジニアにとって極めて価値のある視点を提供するものです。