電子商取引におけるClaude Opus 5.5：コピーライティングとカスタマーサポート返信

claude-opus-5-5 は hiapi 自身のモデルカード上で、入力と出力のモダリティがともに text と記載されています —— 画像生成はなく、画像入力についても言及がありません。したがって、要件に「商品画像」が登場した場合、正直な答えはあらゆる純粋なテキストLLMに対する場合と同じです：ツールの選択を誤っています。オンラインショップの場面で本当に得意とするのは執筆です：商品説明、商品ページのコピー、カスタマーサポートの返信です。さらに、ほとんどの人が触れたことのない reasoning パラメータがあり、このパラメータには実際に課金される副作用があり、本番パイプラインに組み込む前に知っておく価値があります。以下は hiapi API に対する4回の実際の呼び出しで、実際の出力、実際のトークン数、そして実際にお金を払って初めて発見した落とし穴を含みます。

reasoning.effort パラメータ、そしてそれが結局何をもたらすのか

claude-opus-5-5 のモデルカードには5段階の reasoning effort が記載されています：low、medium、high、xhigh、max。リクエスト構造は以下のとおりです：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 500,
    "reasoning": {"effort": "high"},
    "messages": [
      {"role": "system", "content": "You are an e-commerce copywriter. Write a 60-word product description. No superlatives."},
      {"role": "user", "content": "Product: insulated water bottle. 750ml, stainless steel, double-wall vacuum insulation, leak-proof lid, matte finish. Keeps drinks cold 24h, hot 12h."}
    ]
  }'

他の2つのリクエスト構造も一見妥当に見えますが、どちらも失敗します：トップレベルのフィールド reasoning_effort と Anthropic ネイティブの thinking: {"type": "enabled", "budget_tokens": ...} ブロックはどちらも invalid_request を返します。このルート上で有効な唯一の構造は reasoning: {"effort": "..."} です。

当初の仮説はこうでした：より高い effort レベルは、より深く考えた回答と引き換えにより多くのトークンを消費するだろう。まったく同じ60語の説明プロンプトを、max_tokens: 500 の下で minimal（未ドキュメント、詳細は後述）、low、medium、high、max でそれぞれ送信したところ、結果はそうではありませんでした：

effort	prompt_tokens	completion_tokens	finish_reason
minimal	130	499	stop
low	130	499	stop
medium	130	499	stop
high	130	499	stop
max	130	499	stop

各レベルは同じプロンプトに対してちょうど499個の completion token を課金しました。近似値ではなく——完全に同一です。実際に変化したのは書かれた内容です：

minimal： どこにいても、この750mlステンレス製ボトルで水分補給を。二重断熱により飲み物は24時間冷たく、12時間温かく保たれるので、山道からジムまで、水はいつでも爽やかです。漏れ防止キャップはバックパックの中でしっかり密閉し、マット仕上げは傷に強く、手にしっかり馴染みます。BPAフリーで耐久性があり、あらゆるワークアウトやアウトドアアドベンチャーに適しています。

high： ステンレス製保温ボトル、750ml。 長い山道とより長いワークアウトのために作られました。二重ステンレス断熱により飲み物は24時間冷たく、または12時間温かく保たれるので、水は最後の一口まで新鮮です。漏れ防止キャップはバックパックやジムバッグの中でしっかり密閉します。マット仕上げは摩耗に強く、汗ばんだ手も気になりません。750mlは1回のサイクリングに十分で、重すぎることもありません。

high は太字の見出しを1行追加し、セールスポイントの順序を再構成しました；minimal は直接セールスポイントに入ります。どちらも60語に収まり、どちらも「最上級の形容詞を使わない」ルールを守り、コストも同じでした。low と medium はその間に位置し、構造は順に少なくなります。なお、minimal は実際にはドキュメントに記載された5段階のリストにはありません——拒否はされませんでしたが、未ドキュメントの値はサポート外として扱うべきで、本番で依存してはいけません；記載された5段階のいずれか（low/medium/high/xhigh/max）を使用してください。

本当の教訓：reasoning.effort が変えるのはスタイルであり、価格ではありません。 固定の max_tokens の下では、コストは設定した上限に依存し、effort 文字列には依存しません。effort レベルでコピーライティングパイプラインの予算を組み、low が安いティアだと思っているなら、それは違います——請求額を変えられる唯一のレバーは max_tokens です。

落とし穴：reasoning が知らず知らず max_tokens 予算を食い尽くす

「コストは max_tokens に依存する」という発見には、鋭い副作用があります。claude-opus-5-5 は目に見える返信を書き出す前に内部推論を行い、この内部推論は回答そのものと同じ max_tokens 上限を共有します。上限を上げずに effort を高くすると、モデルは回答の途中で予算を使い果たすかもしれません——あるいは目に見える内容を一切書き出す前に使い果たすかもしれません。

最初のケース：普通のコピーライティングプロンプトで effort: xhigh と max_tokens: 500 を使用：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 500,
    "reasoning": {"effort": "xhigh"},
    "messages": [
      {"role": "system", "content": "You are an e-commerce copywriter. Given a product spec, write a title (max 70 characters), 3 bullet features, and a 2-3 sentence description. No superlatives, no exclamation marks."},
      {"role": "user", "content": "Product: insulated travel mug. Material: 18/8 stainless steel, double-wall vacuum insulation. Capacity: 16oz. Lid: leak-proof slide lock. Keeps drinks hot 6 hours, cold 12 hours."}
    ]
  }'

実際のレスポンス、未編集——文中で途切れています：

タイトル： 16oz ステンレス製保温トラベルマグ、漏れ防止スライドロック蓋

特徴：

• 保温・保冷： 二重真空断熱により飲み物を6時間温かく、12時間冷たく保ちます。
• 耐久構造： 18/8ステンレス製で、錆びにくく匂いも残りません。
• 漏れ防止蓋： 開口部をスライドロックで密閉するので、バッグに放り込んでもこぼれる心配がありません。

説明： この16ozトラベルマグは二重真空断熱を採用し、コーヒーを午前中いっぱい温かく保ち、あるいはあなたの

finish_reason: "length"、500個の completion token を課金し、説明の節は「あるいはあなたの」でぷつりと途切れています——終わりの句読点もなく、エラーもなく、警告フィールドもありません。HTTP 200 だけをチェックするパイプラインは、その半端な文をそのまま商品ページに公開してしまうでしょう。

2番目のケースはさらに悪いものです：カスタマーサポート返信プロンプトを max_tokens: 300 でデフォルトの reasoning を使って実行すると、完全に空白が返りました。

{
  "finish_reason": "length",
  "usage": {"prompt_tokens": 157, "completion_tokens": 300, "total_tokens": 457},
  "message": {"content": "", "reasoning_details": [{"text": "", "type": "reasoning.text"}]}
}

content は空文字列です。reasoning_details フィールドが原因を裏付けています：モデルは300トークンの予算すべてを内部推論に費やし（"text": ""——推論の軌跡すら公開されず、不透明な暗号化された signature ブロックだけです）、実際の返信を書く余地が残りませんでした。hiapi はそれでもその呼び出しに対して300個の completion token すべてを課金しました——目に見える回答が生成されたかどうかに関わらず、思考に対して料金を支払うのです。

どちらのケースも修正方法は同じです：max_tokens を設定するときは、目に見える回答に必要な量を上回る実際の余裕を確保すること、特に high/xhigh/max effort の下では重要です。また、finish_reason: "stop" が良い回答の証明だと信じてはいけません——データベースに書き込む前に、content が空でなく、意味が完全に表現されていることを確認してください。

ユースケース：カスタマーサポート返信の下書き

自社のポリシーと実際の顧客メッセージを入力します：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 400,
    "reasoning": {"effort": "medium"},
    "messages": [
      {
        "role": "system",
        "content": "You are a customer support agent for an online water bottle store. Policy: 30-day return window from delivery. Manufacturing defects reported after the window should be referred to the manufacturer'\''s own warranty. Reply in under 100 words, empathetic but concise, end with a clear next step."
      },
      {
        "role": "user",
        "content": "I bought a water bottle 35 days ago and the seal is already leaking. Can I get a refund or exchange?"
      }
    ]
  }'

実際のレスポンス、未編集：

漏水の問題について申し訳ございません。35日が経過しているため、ご注文は当社の30日間の返品期間を超えており、当社側で返品や交換をお受けすることができません。多くのウォーターボトルブランドは通常使用におけるシールの欠陥に対して保証を提供しているため、メーカーに直接お問い合わせいただくことをお勧めします。ご注文番号をお知らせいただければ、クレーム申請に役立てていただけるようブランドの詳細情報をお伝えできます。

ポリシーに含まれる正確な境界ケースを正しく適用しました——35日は30日間の期間を超えているため、直接の返品を断り、単に謝罪してそれでも返金を提供するのではなく、メーカー保証へと誘導しました。277個の completion token、finish_reason: "stop"、回答は完全で途切れていません。同じモデル、同じアカウント、上記のコピーライティング表と同じ medium effort——ここでの違いは、max_tokens: 400 が推論と回答の両方を行うのに十分な余地を与えたことです。

モデルカードが否定しているにもかかわらず、視覚能力は利用可能

さらに実際に検証された驚きがあります：claude-opus-5-5 のモデルカードには Input modalities: text と記載されています——どこにも画像入力についての言及はありません。しかし、画像を送っても機能します：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 150,
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "In one sentence, what is in this photo?"},
        {"type": "image_url", "image_url": {"url": "https://example.com/photo.jpg"}}
      ]
    }]
  }'

実際のレスポンス、未編集（前述と同じ max_tokens の仕組みで途切れています——150では足りません）：

これはグレーの表面を背景に整然と並べられた紳士用デイリーアクセサリーのフラットレイで、黒いジップウォレット、パイロットサングラス、ツイードのボウタイ、ノートブック

写真を正しく読み取っています。モデルカードの「text」モダリティ記載は、このルートにとっては誤り、あるいは少なくとも不完全です——これは claude-opus-4-8 の記事がその視覚能力の主張で遭遇した「カードと現実の不一致」パターンと同じです。公開されているモダリティリストに依存して制限をかけるパイプラインを構築しないでください；上記の reasoning パラメータと同様に、実際のリクエストを送り、実際のレスポンスを読んでください。

コストの説明

9回の実際の呼び出し、すべて単一の claude-opus-5-5 ルートで課金（このモデルには -aws などの価格変種は存在しません。claude-opus-4-8 とは異なります）、hiapi 料金ページの100万入力トークンあたり$2.02、100万出力トークンあたり$10.08で計算：

呼び出し	prompt_tokens	completion_tokens	コスト
effort 表 × 5（minimal/low/medium/high/max）	650	2,495	$0.0264
xhigh 途切れ落とし穴	185	500	$0.0054
空返信落とし穴	157	300	$0.0033
カスタマーサポート返信	3,590	277	$0.0100
視覚テスト	690	150	$0.0029
合計	5,272	3,722	$0.0482

ここには画像生成は一切ありません——claude-opus-5-5 は画像を生成しないので、上記の1ドルはすべてトークンコストであり、2つの「落とし穴」行は追加の予算を確保する価値があります：途切れた出力や完全に空白の出力に対して実際の料金を支払ったからです。

よくある質問

claude-opus-5-5 は商品画像を生成できますか？ いいえ。モデルカードにはテキストのみの入力・出力モダリティが記載されており、上記のすべてのレスポンスはテキストです。タスクが実際に新しい商品写真の生成であるなら、それには画像生成モデルが必要であり、これではありません。

より高い reasoning.effort はより高コストになりますか？ それ自体ではなりません。固定の max_tokens の下では、上記のテストで5つのドキュメント化されたレベルの課金された completion token 数は完全に同じでした——effort が変えるのは執筆であり、トークン数ではありません。本当に高コストになるのは max_tokens を引き上げ、より高い effort レベルに推論と回答の両方を行う余地を与えることです。

なぜエラーなしで空のレスポンスが返ってきたのですか？ max_tokens が、モデルが執筆前に行う内部推論に対して低すぎたためです。これはバグではありません——finish_reason は "length" を示し、完全なトークン数に対して料金を支払いますが、content は空白または途切れて返る可能性があります。呼び出しが200を返したかだけでなく、常に content が空でなく完全であることを確認してください。

実際に画像入力をサポートしていますか？ はい、上記のリクエストで実際の画像を送り正確な説明を得ることで確認済みです——モデル自身のカードが text を唯一の入力モダリティとして記載しているにもかかわらず。

はじめに

自分で試すには：hiapi API キー、claude-opus-5-5 モデルページ（現在の価格と完全な reasoning-effort リストを確認）、そして同じ電子商取引のコピーライティングとカスタマーサポートのワークロードで純粋なテキストモデルを比較しているなら、claude-opus-4-8 の記事が前世代の Opus で同じ内容を扱っています——本番パイプラインを切り替える前に、上記の max_tokens/reasoning のトレードオフがアップグレードに値するか確認する価値があります。