投稿者 投稿日: カテゴリー Claude
Claudeのモデル階層とは、性能と速度と料金で役割分担した3段のことです。
Claude Pro を契約してチャット画面を開くと、モデル選択のプルダウンに Opus・Sonnet・Haiku が並びます。ここで毎回いちばん上の Opus を選び続けている店舗が、現場では多く見られます。商品説明文を1本書かせるだけの作業に最上位モデルを使うのは、待ち時間と料金の両方で損をしている状態です。この記事は、楽天やAmazonの実務タスクを3つの層にどう割り振れば、精度と速度とコストのバランスが取れるのかを、タスク別に整理したものです。読み終えるころには、自店のどの作業をどの層に任せるべきか、その判断軸が手元に残る構成にしました。実際にコピーして使えるプロンプト例も、Opus向け・Sonnet向け・Haiku向けに分けて5本付けてあります。
Opus 4.8の登場で何が変わったか
2026年5月28日、Anthropicは Claude Opus 4.8 を公開しました。現行のフラッグシップモデルで、一度に扱える文脈の長さが100万トークンまで拡張されています。日本語に換算すると、おおまかに数十万字ぶんの資料を一度に読み込ませて分析できる規模です。EC運用の文脈で言えば、1年ぶんのレビューを全部貼り付けて傾向を出す、商品マスタを丸ごと読ませて重複や表記ゆれを洗い出す、といった「長い入力をまとめて処理する」用途が現実的になりました。
この「文脈の長さ」が効くのは、入力が長く、かつ全体を横断して判断させたいタスクに限られます。商品説明文を1本書く、レビューに1件返信する、といった短い作業では100万トークンの恩恵はまったく出ません。むしろ最上位モデルは応答が遅く、料金も高いため、短いタスクに使うと損が積み上がります。Opusの価値は「長い・難しい・一度きりの重い判断」に集約されると考えておくのが実務的です。
階層の全体像を押さえておきます。Anthropicの モデル概要ドキュメント によると、Claudeは上から Opus・Sonnet・Haiku の3段構成です。Opusが最上位で高難度タスク向け、Sonnetが中位で日常実務向け、Haikuが軽量・高速・低コストの処理向けという役割分担になっています。2026年6月時点の各層の現行モデルは、Opusが Opus 4.8、Sonnetが Claude Sonnet 4.6（2026年2月17日）、Haikuが Claude Haiku 4.5 です。バージョン番号は層ごとに独立して進むため、同じ「4.x」でも別の層のものは別物として扱う必要があります。
楽天やAmazonの店舗運営では、1日のうちに性質の違うタスクが何十件も混在します。戦略を練る時間もあれば、定型文を量産する時間もあり、大量のデータを仕分ける時間もあります。これを全部1つのモデルでこなそうとすると、重いタスクに引きずられて速度が落ちるか、軽いタスクに最上位モデルを使って料金がかさむか、どちらかになります。層を意識して使い分けることが、Claudeを日常運用に組み込むときの最初の設計判断になります。
各層の性格をもう少し具体的に整理しておきます。Opusは、長い文章を読み込んで複数の要素を突き合わせ、抜けの少ない判断を返すのが得意です。たとえば、レビュー全文と売上データと競合の品揃えメモを同時に読ませて「次に伸ばすべきカテゴリ」を理由付きで出させると、Sonnetより論点の網羅性が高くなる傾向があります。半面、応答までの待ち時間は長く、APIの単価も高くなります。Sonnetは、その中間に位置し、品質と速度と料金がバランスした「実務の主力」です。日常の作文や返信、要約のほとんどはこの層で過不足なく処理できます。Haikuは、1件あたりの判断が軽い処理を、速く安く、大量にさばくための層です。分類・抽出・整形のように「答えが短く、件数が多い」作業で本領を発揮します。
注意したいのは、層の優劣を「賢さの順位」だけで捉えないことです。Haikuが劣っているのではなく、軽い処理に最適化されているからこそ速くて安い、と理解するのが正確です。重い思考にHaikuを使えば物足りず、軽い処理にOpusを使えば過剰になる。タスクと層のミスマッチが、料金と速度の両方で損を生みます。店舗運営の現場感覚では、まずこの「層ごとの守備範囲」を頭に入れることが、Claude活用の土台になります。
楽天RMSやAmazon Seller Centralの管理画面を1日に何度も開く店舗ほど、この使い分けの効果は大きくなります。商品登録画面で説明文を整える、レビュー一覧で返信を書く、ダウンロードしたCSVを仕分ける、といった作業はそれぞれ性質が違うからです。同じ「Claudeに任せる」でも、画面とタスクごとに呼び出す層を変える発想を持っておくと、1日の運用全体が締まります。
Mythos・Fableクラスは2026年6月時点で停止中
Claudeの上位に「Mythosクラス」という新しい階層が登場した、という話を見聞きした店舗もあるかもしれません。事実関係を正確に書きます。Anthropicは初のMythosクラスとして Claude Fable 5 を2026年6月9日に一般提供（GA）開始し、続けて Claude Mythos 5 を投入しました。ところが2026年6月12日、米国政府の輸出規制に関する指令により、両モデルへのアクセスが停止されています。
このため、2026年6月時点ではMythos・Fableクラスは利用できません。今後再開されるのか、再開されるとしてどの地域・どの契約で使えるのかは、現時点では要確認です。状況が流動的なので、本記事では「将来の選択肢」として頭の片隅に置く程度にとどめ、実際に手を動かす前提としては扱いません。
結論として、2026年6月時点でEC事業者が現実に使える最上位モデルは Opus 4.8 です。Mythosクラスが停止している以上、「いちばん難しい判断はどれに任せるか」という問いの答えは、当面 Opus 4.8 になります。最新動向を追うのは大切ですが、利用できないモデルを業務フローに組み込んでしまうと、停止のたびに運用が止まります。いま手元で動くモデルを軸に設計するのが安全です。
この一件は、AI活用の運用設計に教訓を残します。新しい上位モデルが出るたびに業務をそこへ寄せていくと、停止や提供条件の変更が起きた瞬間に、店舗の作業フローごと止まってしまうということです。規制や技術の都合でモデルの提供状況が変わるのは、今後も繰り返し起こりうる前提として織り込んでおくのが現実的です。直近の支援案件で観測したのは、特定の最新モデル前提で社内マニュアルを作り込んでいた店舗が、その後の仕様変更で手順を全部組み直す羽目になったケースでした。
そこで実務として勧めたいのは、「特定モデルではなくタスクの性質に手順を紐づける」という設計です。たとえば「重い意思決定の素案づくりは、そのとき使える最上位モデルに任せる」と決めておけば、最上位がOpus 4.8でもMythosクラスでも、手順そのものは変えずに済みます。複数モデルを横断して使える体制にしておくと、こうした中断の影響を受けにくくなります。複数モデルの併用については ChatGPT・Claude・Geminiの使い分け でも整理しています。
タスク別の振り分け表をプロンプト付きで作る
ここからが本題です。EC運用で発生する代表的なタスクを、Opus 4.8・Sonnet 4.6・Haiku 4.5 のどれに任せるべきか、判断軸とプロンプト例をセットで示します。プロンプトは全部で5本、いずれも独立したコードブロックに入れてあります。中括弧の変数は自店の値に置き換えて使ってください。
判断軸はシンプルです。タスクに「一度きりの重い思考」が含まれるなら Opus、「品質を保ちつつ毎日回す実務」なら Sonnet、「とにかく大量・短文・速さ優先」なら Haiku、という順で考えます。迷ったらまず Sonnet で試し、出力が浅いと感じたら Opus に上げ、速度と料金が気になったら Haiku に下げる、という調整が現場では回しやすい運用です。
Opus 4.8 が向くのは、年間の販売戦略を立てる、競合店の品揃えとレビューをまとめて分析する、新カテゴリ参入の是非を多角的に検討する、といった「長文を読み込んで複雑な意思決定を支える」タスクです。直近の支援案件で観測したのは、半期の売上データとレビューを一括で読ませて施策の優先順位を出させる使い方で、ここはSonnetだと論点の抜けが出やすく、Opusの厚みが効きました。
（用途タイトル：年間販売戦略の立案）
プロンプト1：年間販売戦略の立案（Opus 4.8向け・長文分析と複雑な意思決定）
あなたは日本のEC運営に精通した戦略コンサルタントです。
以下の店舗データを横断的に分析し、来期1年間の販売戦略案を作成してください。
出力は、現状の構造的な課題3点、注力すべき商品カテゴリの優先順位、四半期ごとの打ち手、想定リスクの順で、根拠とともに示してください。
店舗データ：
- 主要モール：{楽天／Amazon／Yahoo!のいずれか}
- 商品ジャンル：{ジャンル}
- 直近1年の月次売上推移：{貼り付け}
- カテゴリ別の売上構成と転換率：{貼り付け}
- 直近のレビュー全文（評価別）：{貼り付け}
- 競合店の品揃えメモ：{貼り付け}
制約：
1. 数字の裏付けがない施策は「仮説」と明記する
2. 自店データから読み取れない外部要因は前提として切り分ける
3. 楽天R-Mail等の店舗向け施策は各モールの規約に違反しない範囲で提案する
Sonnet 4.6 が向くのは、毎日発生する分量の多い実務です。商品説明文の作成、レビューへの返信文、メルマガの本文、商品名の候補出しなど、品質は保ちたいが回数が多いタスクは、応答速度と料金のバランスが良いSonnetが基準になります。店舗運営の現場感覚では、日中に何度も呼び出す作業の8割前後はSonnetで足ります。
（用途タイトル：商品説明文の作成）
プロンプト2：商品説明文の作成（Sonnet 4.6向け・日常実務）
あなたはEC商品ページのコピーライターです。
以下の商品について、検索意図に答えつつ購入を後押しする商品説明文を作成してください。
分量は本文600〜800字、冒頭2文で読者の不安を解消する構成にしてください。
商品情報：
- 商品ジャンル：{ジャンル}
- ターゲット顧客：{誰の・どんな悩み}
- 素材・産地・特徴：{値}
- 容量／サイズ：{値}
- 価格帯：{値}
制約：
1. 「最高」「No.1」「絶対」などの最大級・断定表現を使わない
2. 効果効能を断定する薬機法・景表法に触れる表現を避ける
3. ターゲットKWは {第1KW} を本文中に2回まで、自然な文脈で入れる
レビュー返信もSonnetの守備範囲です。1件ずつ文脈を汲んで丁寧に返す必要があるため、Haikuの速さよりSonnetの品質を取ります。ただし定型の感謝文を大量に下書きするだけなら、後述のHaikuに回す判断もあります。
（用途タイトル：レビュー返信の下書き）
プロンプト3：レビュー返信の下書き（Sonnet 4.6向け・品質重視の個別対応）
あなたはEC店舗のカスタマーサポート担当です。
以下のレビューに対する返信文を、評価の高低に応じて作成してください。
低評価には、まず謝意と共感を示し、次に具体的な改善・対応の意思を、最後に再来店への配慮を一言添える順で書いてください。
商品ジャンル：{ジャンル}
レビュー本文：{貼り付け}
レビュー評価：{星の数}
制約：
1. テンプレ感が出ないよう、レビュー本文の固有の内容に1箇所は具体的に触れる
2. 値引きや特典を見返りに提示しない（各モールの規約に抵触するため）
3. 2〜4文に収め、過度にへりくだらない
Haiku 4.5 が向くのは、大量・短文・速さ優先のタスクです。数千件の商品を属性で分類する、レビューをポジティブ・ネガティブ・要対応の3つに仕分ける、商品名から検索タグを機械的に抽出する、といった「1件あたりの判断は軽いが件数が膨大」な処理は、高速で低コストなHaikuが最も合います。アパレル系の単一店舗で試したケースでは、数千件のレビュー一次分類をHaikuで回し、要対応に分類されたものだけSonnetで返信文を作る二段構えにして、処理時間を大きく短縮できました。
（用途タイトル：レビューの一次分類）
プロンプト4：レビューの一次分類（Haiku 4.5向け・大量・短文処理）
以下のレビューを、次の3カテゴリのいずれか1つに分類してください。
- positive：満足・好評価
- negative：不満・低評価
- action_needed：返品・不良・問い合わせなど店舗の対応が必要
出力は「レビュー番号, カテゴリ」の形式で1行ずつ返してください。
解説や前置きは一切不要です。
レビュー一覧：
{番号付きでレビュー本文を貼り付け}
タグ付けやキーワード抽出のような定型処理も、Haikuに任せると速く安く回せます。出力の形式を厳密に指定すれば、後続のCSV取り込みにそのまま流せます。
（用途タイトル：商品の検索タグ抽出）
プロンプト5：商品の検索タグ抽出（Haiku 4.5向け・定型抽出）
以下の商品名と説明文から、検索に使われそうなキーワードを最大10語、重要度順に抽出してください。
出力はカンマ区切りの1行のみ、解説は不要です。
一般的すぎる語（「商品」「セット」「送料無料」など）は除外してください。
商品名：{値}
商品説明文：{値}
5本のプロンプトを並べると、同じ作業フローのなかでも層を切り替えるべき場面が見えてきます。レビュー対応なら、Haikuで一次分類してSonnetで返信を書く。戦略策定なら、Haikuでデータを整形してOpusで分析する。1つのモデルで通すより、入口と出口で層を変えるほうが、全体の速度と料金が締まります。
商品ジャンルごとに、どの層が主役になるかも変わります。たとえば食品ギフトのように季節商戦の波が大きいジャンルでは、繁忙期前の商戦設計をOpusで一度きり重く回し、繁忙期中の日々の商品説明文や問い合わせ返信はSonnetで量をさばく、という時期による配分が効きます。アパレルのように商品点数が多くレビューも大量に集まるジャンルでは、Haikuによる分類・タグ付けの比重が自然と高くなります。家電や型番商品のように仕様情報が定型的なジャンルでは、スペックからの説明文生成をSonnet、検索タグ抽出をHaikuに割り振ると、登録作業の回転が上がります。自店の主力ジャンルがどの性質に近いかを見て、3層の配分を決めるとよいでしょう。
プロンプトを社内で使い回すときのコツも一つ挙げておきます。プロンプトの先頭に「このプロンプトはHaiku向け」「このプロンプトはOpus向け」と用途と推奨層を明記しておくことです。担当者が変わっても、どのタスクをどの層で回すべきかが共有され、最上位モデルに全部投げてしまう事故を防げます。編集部で実際に運用しているプロンプト集でも、各プロンプトに推奨層のラベルを付けて管理しています。
振り分けでよくある失敗と回避策
第一の失敗は、全部Opusで通してしまうパターンです。最上位だから安心、という発想で商品説明文もレビュー返信もOpusに投げると、1件ごとの待ち時間が積み上がり、料金も膨らみます。短いタスクではOpusとSonnetの出力品質の差は体感しにくいことが多く、コストに見合いません。回避策は、まずSonnetを既定にして、出力が物足りないタスクだけ個別にOpusへ上げる運用にすることです。
第二の失敗は、逆に全部Haikuで済ませようとするパターンです。速くて安いからと戦略立案やレビュー返信までHaikuに任せると、論点の浅さや文章のそっけなさが表に出ます。Haikuは「判断が軽い大量処理」に強いモデルであって、「重い思考」や「人に読ませる丁寧な文章」を主戦場にしていません。回避策は、Haikuの担当を分類・抽出・整形に限定し、人の目に触れる最終アウトプットはSonnet以上に任せることです。
第三の失敗は、モデル名とバージョンを混同するパターンです。「Claude 4.6」とだけ覚えていると、それがSonnetの4.6なのかHaikuの4.5なのか分からなくなり、料金や速度の前提を誤ります。層ごとにバージョンは独立して進むため、社内で使うときは「Sonnet 4.6」「Haiku 4.5」のように層名とセットで記録しておくと、後から振り返るときに混乱しません。GPT系との比較で迷う場合は GPT-5.5とClaudeのEC比較 も参考になります。
第四の失敗は、生成された文章を人の確認なしにそのまま公開してしまうパターンです。特に楽天市場の商品ページやR-Mailでは、Claudeが良かれと判断して書いた表現が、規約上の問題を含むことがあります。最大級表現や効果効能の断定、楽天R-Mail本文への自社サイトURLの挿入などは、どの層のモデルを使っても起こりえます。回避策は、層の選定とは別に「公開前に人が一読する」工程を必ず挟むことです。モデルを上位に変えても規約適合は保証されないため、ここは運用ルールとして固定するのが安全です。
費用と工数の目安
料金体系は契約形態で変わります。チャットUIを使うなら、個人向けの Claude Pro が月額20米ドル前後（2026年6月時点の目安、為替で円換算は変動）で、この範囲で Opus・Sonnet・Haiku を切り替えて使えます。チームで使う場合は上位プランやAPI従量課金が選択肢になります。APIで自動処理を組む場合、料金は層ごとに入力・出力トークン単価が異なり、Opusが最も高く、Sonnet、Haikuの順に安くなるのが通例です。正確な単価は変動するため、導入前に Anthropicの公式ドキュメント で最新の値を確認してください。
工数の目安としては、レビュー返信の下書きをSonnetに任せると、1件あたりの作文時間が手書きの数分の1に縮むケースが多く見られます。数千件の分類をHaikuで回せば、手作業なら数日かかる仕分けが数時間規模に収まることもあります。ただしこれらは件数・文章量・チェック体制で大きく振れるため、自店で小さく試してから本格運用に移すのが安全です。最初の1か月は、Sonnetを基準に1日数十件の実務を回しながら、Opusに上げるべきタスクとHaikuに下げられるタスクを仕分けていく、という進め方が現実的です。
費用対効果を測るときは、削減できた工数だけでなく、確認・修正にかかる時間も合わせて見る必要があります。Haikuで分類を高速化しても、誤分類の手直しに時間を取られれば差し引きで得とは限りません。逆にOpusで重い分析を回すと、出力そのものの質が高く修正が少ないため、単価が高くても総コストでは見合うことがあります。単価の安さだけで層を選ぶと、後工程のチェックコストで打ち消されるという落とし穴があるため、タスクごとに「生成時間+確認時間」のセットで判断するのが堅実です。
導入のステップとしては、いきなり全タスクを自動化しようとせず、効果が見えやすいところから始めるのが定石です。たとえば、毎日発生して分量が安定しているレビュー返信の下書きをSonnetで回すところから着手し、運用が安定したら大量分類をHaikuに広げ、最後に四半期に一度の戦略策定をOpusに任せる、という順序です。小さく始めて、層ごとの得手不得手を自店のデータで確かめながら範囲を広げていけば、無駄な料金をかけずに定着させられます。
今後の展望
モデル階層の使い分けは、今後さらに重要になります。Mythosクラスのように上位の層が増えたり、規制で一時停止したりという変動が起こるたびに、「どのタスクをどの層に置くか」の設計図を持っている店舗ほど、切り替えのコストが小さくなるからです。特定のモデルに業務を固定するのではなく、タスクの性質ごとに層を割り当てておけば、上位モデルが停止しても1段下げて凌ぐ、新しい上位が出たら重いタスクだけ移す、といった調整が効きます。
もう一つの論点は、AIエージェントによる自動運用との接続です。レビュー監視や在庫アラートのような定常監視はHaiku、判断が必要な分岐はSonnet、人の承認を要する重い意思決定の素案はOpus、という三層をエージェントのワークフローに組み込めば、コストを抑えながら自動化の範囲を広げられます。コーディング寄りの自動化を検討する場合は Codex対Claude CodeのEC比較 や AIコーディングツール比較 も合わせて確認しておくと、ツール選定の見通しが立てやすくなります。Mythosクラスの再開有無を含め、モデル動向は要確認のまま追い続ける必要があります。
よくある質問
商品説明文を書くだけならどの層で十分ですか
Sonnet 4.6 で十分なケースがほとんどです。短い実務文では最上位のOpusと体感差が出にくく、応答速度と料金の面でSonnetが有利です。仕上がりが浅いと感じたタスクだけ、個別にOpusへ上げる運用が無駄がありません。
Mythos・Fableクラスは今すぐ使えますか
2026年6月時点では使えません。Claude Fable 5 とClaude Mythos 5 は、2026年6月12日に米政府の輸出規制指令によりアクセスが停止されています。再開時期や利用条件は要確認です。現実に使える最上位は Opus 4.8 だと考えてください。
Opus 4.8 の100万トークンは何に使うと得ですか
長い入力を横断して判断させるタスクで効きます。1年ぶんのレビューや商品マスタを丸ごと読ませて傾向を出す、といった用途が典型です。商品説明文を1本書くような短い作業では恩恵が出ないため、Sonnetで足ります。
料金を抑えたい場合の基本方針は何ですか
人の目に触れない大量処理をHaikuに、人に読ませる実務をSonnetに、重い意思決定だけOpusに割り当てるのが基本です。全部Opusで通すと料金が膨らみ、全部Haikuで通すと品質が落ちます。層ごとの得意分野に合わせるのが最も無駄がありません。
ChatGPTやGeminiと併用すべきですか
タスクによっては併用が有効です。モデルの停止や仕様変更は今後も起こりうるため、複数の選択肢を持っておくと中断の影響を受けにくくなります。詳しくは ChatGPT・Claude・Geminiの使い分け を参照してください。
楽天店舗で使うとき気をつけることはありますか
Claudeが生成した文章をそのまま使う前に、楽天市場の店舗運営規約に違反していないか確認してください。最大級表現や薬機法に触れる効果効能の断定、楽天R-Mail本文への外部サイトURL掲載などは規約上の問題になります。生成物は必ず人が一読してから公開する体制が望ましいです。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
