はじめに
2026年9月22日、Anthropicが新モデル Claude Opus 5.5(API上のモデルIDは claude-opus-5-5)を公開しました。公式発表によると、性能は上位のFable 5.1に並び、実行コストは典型的な用途でOpus 5より約4割安くなるとのことです(Anthropic公式)。
私は24年間、EC-CUBEをクライアントの要望に合わせてカスタマイズする開発を中心に仕事をしてきました。今はGoとReactでの開発が中心です。生成AIの機能をシステムに組み込むとき、どのモデルを選ぶかと同じくらい大事なのが、毎月の運用コストを事前に見積もれるかだと考えています。見積もりがないと、発注する側も予算を決められないからです。
そこで今回は、EC-CUBEに組み込む生成AI機能の代表例として「商品説明文の一括生成」を題材に、次の2点を手元で確認しました。
- 公式のPython SDKが、もう
claude-opus-5-5に対応しているか - 商品説明文を1万SKU分生成すると、Opus 5とOpus 5.5でコストがどれだけ変わるか
検証環境
- Linux x86_64 / Python 3.12.3
- anthropic(Python SDK)1.8.0
- 実行日:2026-09-25
やってみた①:SDKは対応しているか
SDKの型定義(anthropic.types.Model)には、補完用のモデルIDがLiteralとして列挙されています。そこから中身を取り出して確認しました。
import typing
import anthropic
from anthropic.types import Model
def literal_values(tp):
vals = []
for arg in typing.get_args(tp):
if typing.get_origin(arg) is typing.Literal:
vals.extend(typing.get_args(arg))
else:
vals.extend(literal_values(arg))
return vals
models = literal_values(Model)
print("claude-opus-5-5 を含む:", "claude-opus-5-5" in models)
実行結果です。
anthropic SDK version: 1.8.0
SDKが定義しているOpus系モデルID:
- claude-opus-4-5
- claude-opus-4-5-20251101
- claude-opus-4-6
- claude-opus-4-7
- claude-opus-4-8
- claude-opus-5
- claude-opus-5-5
claude-opus-5-5 を含む: True
最新版のSDKを入れれば、型補完の段階から claude-opus-5-5 を選べることがわかりました。なお Model 型は任意の文字列も受け付けるので、古いSDKでもモデルIDを文字列で渡せば呼び出し自体はできるはずです。ただ、エディタの補完や型チェックの恩恵を受けたいなら、SDKを更新しておくのが無難です。
やってみた②:1万SKUの商品説明文、いくらかかるか
次のシナリオで試算しました。トークン数はあくまで想定値です。
| 項目 | 想定 |
|---|---|
| SKU数 | 10,000 |
| 共通のシステムプロンプト(ブランドガイド・NG表現・文例) | 3,000 tokens |
| SKUごとの商品情報 | 400 tokens |
| 生成する説明文 | 600 tokens |
ここでいう「共通のシステムプロンプト」は、全SKUで同じ内容になります。そのためプロンプトキャッシュが効く部分です。キャッシュを使う場合と使わない場合の両方を計算しています。
PRICES = {
"claude-opus-5": Price(input=5.00, output=25.00, cache_write_5m=6.25, cache_read=0.50),
"claude-opus-5-5": Price(input=4.00, output=20.00, cache_write_5m=5.00, cache_read=0.20),
}
def cost(p: Price, use_cache: bool) -> float:
if not use_cache:
return SKUS * ((SHARED_TOKENS + ITEM_INPUT) * p.input + ITEM_OUTPUT * p.output) / M
writes = CACHE_WRITES * SHARED_TOKENS * p.cache_write_5m
reads = (SKUS - CACHE_WRITES) * SHARED_TOKENS * p.cache_read
rest = SKUS * (ITEM_INPUT * p.input + ITEM_OUTPUT * p.output)
return (writes + reads + rest) / M
実行結果です。
シナリオ: 10,000 SKU / 共通プロンプト 3,000 tok / 商品情報 400 tok / 出力 600 tok
モデル キャッシュなし キャッシュあり
claude-opus-5 $320.00 $185.34
claude-opus-5-5 $256.00 $142.29
削減率(キャッシュなし): 20.0%
削減率(キャッシュあり): 23.2%
Opus 5 キャッシュなし → Opus 5.5 キャッシュあり: 55.5%
ハマりどころ
-
「4割安い」と「価格表の2割引き」は別の話:単価だけで計算すると、削減率は約20%(キャッシュ込みで約23%)にとどまります。公式の「約4割」は、同じ仕事をより少ないトークンで終えられる効率も含めた数字だと読めます。手がかりになりそうなのが、思考の深さを決める effort の初期値です。公式ドキュメントでは、Opus 5 が
high、Opus 5.5 がmediumになっています(Opus 5.5/Opus 5)。何も指定せずに比べると、思考に使うトークンが減る分だけ安くなる可能性があります。逆に、effort をそろえて比べるとどうなるかは別の問題です。ここは実際にモデルを動かして、出力トークン数を実測しないと確かめられません。今回は未検証なので、次回の宿題にします。 -
venvが作れなかった:最初、出力先フォルダ内に
python3 -m venvしようとして失敗しました。原因は、そのフォルダがシンボリックリンクに対応していないファイルシステムだったことです。クラウドストレージの同期フォルダなどで作業する場合は、venvをローカルディスク側に作ると安全です。
EC-CUBEやWebアプリに組み込むなら
試算の結果からいえるのは、モデルを変えるより、プロンプトの設計を変えるほうが効くということです。Opus 5のままキャッシュを使わない構成から、Opus 5.5に切り替えてキャッシュを効かせる構成にすると、試算上は半分以下のコストになりました。
実際にシステムへ組み込むなら、次のような設計にすると思います。
- 共通部分を厚く、個別部分を薄く:ブランドのトーン、NG表現(薬機法や景品表示法に触れやすい言い回しなど)、良い文例は、システムプロンプトにまとめてキャッシュします。商品ごとに渡すのは、商品マスタから機械的に組み立てられる情報だけにします。
- 生成は画面から切り離す:1万件を管理画面のボタン一つで同期的に処理すると、タイムアウトの原因になります。生成はバックグラウンドのジョブ(キューやバッチ)に任せ、EC-CUBE本体の外に小さなワーカーを立てるのも手です。Goなら並行処理と相性がよく、このような用途に向いています。
- 急がないならBatch APIも検討する:公式ドキュメントでは、Batch APIを使うと入出力が50%割引になると案内されています(Opus 5.5)。一括生成は即時性が要らないことが多いので、候補になります(今回の試算には含めていません)。
- 生成結果は「下書き」として保存する:生成文をそのまま公開せず、下書きとして保存し、運用担当者が管理画面で承認してから公開する流れにします。事故を防げるうえ、現場にも受け入れてもらいやすくなります。
- APIキーはサーバー側だけで扱う:管理画面をReactで作る場合でも、ブラウザから直接APIを呼ばず、必ずサーバーを経由させます。
- 全件を最上位モデルで書く必要はない:定型的な説明文なら下位モデルで十分な場合もあります。まず数十件をモデルごとに作り比べ、品質とコストのバランスを発注者と一緒に決めるのがよいと思います。
まとめ
-
anthropicSDK 1.8.0 で、claude-opus-5-5がモデルIDとして定義されていることを確認しました - 1万SKUの商品説明文生成を試算すると、単価の差だけで約20%、キャッシュ込みで約23%のコスト減でした
- 最も効くのはプロンプトキャッシュを前提にした設計です(試算では、Opus 5・キャッシュなしの構成と比べて約55%減)
- 公式の「約4割減」が実際の商品説明文生成でも出るかは、次回APIを呼んで実測します
料金は変わることがあるため、使う前に公式の料金ページを確認してください。コードは試算用の最小限のものなので、自社の商品データに合わせてトークン数を変えて使ってみてください。
筆者について
株式会社エム・エー・ディー 取締役の村田です。エンジニア歴24年、EC-CUBEのカスタマイズを中心に、LaravelでのWebアプリやモバイルアプリの開発にも携わってきました。
現在はGoとReactを中心に開発しながら、EC構築の知見とAI駆動開発を組み合わせたDX支援に取り組んでいます。
- EC・AI活用のご相談:https://mad2007.co.jp/contact/
- 一緒に働くエンジニアを募集しています:https://mad2007.co.jp/recruit/