投稿者 投稿日: カテゴリー Claude
Claude Fable 5.1とは、Anthropicが2026年9月に公開した最新のフラッグシップAIモデルのことです。
Claude Fable 5.1で最も実務に効いた変更は、性能ではなく単価です。キャッシュ読み出しが100万トークンあたり0.25米ドルへ引き下げられ、前世代のFable 5と比べて75%安くなりました。入力の標準単価10米ドルに対して2.5%という水準です。毎回同じ前提文を投げ続けるEC業務にとって、この一点だけで月額が変わります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、Fable 5.1をEC運用のどこに、どう組み込むかを整理します。
Fable 5.1で実務が動く4つの変更点
押さえるべき変更は、キャッシュ単価、コンテキスト長、思考の既定値、そして提供形態の4つです。
キャッシュ単価から入ります。Claude Fableの入力は100万トークンあたり10米ドル、出力は50米ドルで、この本体価格はFable 5から据え置きです。変わったのはキャッシュ読み出しで、100万トークンあたり0.25米ドル。VentureBeatの報道では、一般的なワークロードでおよそ25%、エージェント性の高いワークロードでは最大45%程度のコスト削減になると説明されています。同じ前提を何度も読ませる使い方ほど、削減幅が大きくなる構造です。
コンテキスト長は100万トークン、出力は最大12万8,000トークンです。日本語に換算すると、入力側でおよそ50万から70万文字（文字種によって変動するため目安）。商品点数が数千点あるカタログでも、カテゴリ単位なら丸ごと読ませられる規模になりました。出力12万8,000トークンという枠は、長い商品説明文を数十件まとめて書き出す用途で効いてきます。
3点目が、思考の既定値です。Fable 5.1では適応的な思考（adaptive thinking）が既定で有効になり、5段階のエフォート設定が用意されています。簡単な依頼には短く、複雑な依頼には長く考える挙動が標準になったということです。実務上の意味は2つあります。ひとつは、簡単な処理でも「考える」ぶんの出力トークンが乗る可能性があること。もうひとつは、エフォートを下げれば定型処理を安く回せること。EC業務では、レビュー返信の草案づくりのような軽い処理はエフォートを低く、在庫と受注をまたぐ判断はエフォートを高く、と使い分けるのが基本形になります。
4点目は提供形態です。同時期に公開されたMythos 5.1は、同じ基盤モデルの限定提供版という位置づけで、特定用途向けに提供されると説明されています。一般のEC事業者が触るのはFable 5.1のほうです。ここを混同して「使えるはずのモデルが見当たらない」と止まる例があるので、選定資料には提供形態まで書いておいてください。
現場で繰り返し見るのは、モデル名の更新に合わせて社内ドキュメントを書き換えないまま運用が続き、半年後に「いま何を使っているのか誰も説明できない」状態になるパターンです。モデル名、単価、エフォート設定、キャッシュ対象の4項目を1枚の表に書き、月初に見直す運用にしてください。
日本のEC事業者にとって、この単価改定は「AIを使う量を増やせる」という意味でもあります。これまでコストを理由に人手で回していた作業を、自動化の候補に入れ直せるからです。たとえば商品説明文の全面書き換え。3,000点の商品を抱える店舗で、全件の説明文を作り直す判断は、外注すれば数百万円規模の投資になります。前提文をキャッシュ化してAPIで回せば、原稿の初稿づくりだけなら数万円の水準に収まります。もちろん初稿がそのまま使えるわけではなく、確認と修正の人件費は別途かかりますが、着手のハードルは確実に下がりました。
ただし、安くなったから全部やるという判断は勧めません。書き換えた原稿を公開すれば、検索エンジンとモール内検索の評価は一度リセットされる可能性があります。楽天市場のSGS（楽天市場の検索アルゴリズム）は商品ページの更新に対して即座に反応するわけではなく、順位が戻るまでに時間がかかる場合があります。全件を一斉に書き換えるのではなく、売上下位から段階的に入れ替えて反応を見る進め方が安全です。ある食品ジャンルの中規模店舗の事例では、まず売上下位3割の200点を書き換え、2週間で検索表示回数の変化を確認してから上位へ広げる手順を取りました。
キャッシュが効くEC業務と効かない業務
結論として、キャッシュが効くのは「長い前提文を毎回同じ内容で渡す業務」です。理由は単純で、割引されるのは前提文の読み出し部分だからです。
効く業務の代表が、商品説明文の生成です。自社のトーン定義、禁止表現リスト、モール別の文字数制限、過去の優良原稿サンプル。これらを合計2万トークンぶん前提として渡すとして、1日に100件生成するなら入力は200万トークン。標準単価なら20米ドルですが、前提部分をキャッシュに載せれば0.5米ドル前後まで下がります。1か月では大きな差になります。
同じ理屈で、レビュー返信の草案づくり、問い合わせメールの一次回答、商品名のモール別書き分け、広告文の量産といった「同じルールで大量に処理する業務」はキャッシュと相性が良い領域です。アパレル系の単一店舗で試したケースでは、前提文を固定してキャッシュ化しただけで、月額のAPI費用が半分以下に落ちました。出力側の量は変わっていないので、下がったのは入力側だけです。
一方、キャッシュが効かない業務もあります。毎回まったく違う長文を読ませる処理、たとえば日次の受注データ分析や、その日届いた問い合わせの分類です。前提文が短く、可変データが長い構造なので、キャッシュできる部分がほとんどありません。こうした処理はバッチ実行や中位モデルへの振り分けでコストを下げるほうが筋が良いところです。
前提文の設計には注意点があります。キャッシュは同じ内容が同じ順序で並んでいるときに効きます。前提文の先頭に日付や実行IDのような可変情報を入れると、毎回別物と判定されます。可変情報は前提文の後ろ、可変データ側に置いてください。直近の支援案件で観測したのは、前提文の1行目に生成日時を入れていたためにキャッシュがまったく効いておらず、その1行を末尾へ移しただけで入力費用が8割減ったケースです。
もうひとつ、前提文の更新頻度も設計対象です。ブランドガイドや禁止表現リストを週に何度も書き換えると、そのたびにキャッシュが作り直しになります。更新は月次に固定し、緊急の追記は可変データ側に一時的に入れる運用にしておくと安定します。
社内の誰がキャッシュ設計を持つかも決めておく必要があります。前提文は、マーケティング担当が書きたい内容と、法務・品質管理が担保したい内容と、システム担当が管理したい構造の3つが重なる文書です。所有者を決めずに運用すると、誰かが善意で1行足すたびにキャッシュが作り直され、費用が下がらないまま時間だけが過ぎます。前提文のファイルはバージョン管理下に置き、変更はプルリクエストのような形で1人が承認する運用にすると崩れません。規模の小さい会社なら、月初に1回だけ更新日を設けるだけでも十分です。
前提文の中身についても、実務上の勘所があります。禁止表現リストは、単語を並べるより「なぜ禁止か」を1行添えたほうが出力の精度が上がります。「最大級表現は禁止」とだけ書くより、「モール規約で最大級表現が禁止されているため、根拠のある実績表現に置き換える」と書いたほうが、モデルが代替案を出してくれます。トークン数は増えますが、その部分はキャッシュに載るので費用への影響はわずかです。キャッシュが安い前提では、前提文を厚く書くほうが有利になりました。ここは前世代との設計思想の違いとして意識しておく価値があります。
実装手順とプロンプト6本
導入は3段階で進めます。第1に、いまAIに投げている業務のうち、前提文が2,000トークンを超えるものを洗い出します。第2に、その前提文を1つのファイルにまとめ、バージョン番号を付けます。第3に、キャッシュ有効・無効の両方で同じ処理を10回流し、入力トークンの請求差を確認します。ここまでで、効果があるかどうかは判断できます。
以下のプロンプトは6本です。Claudeを前提に書いていますが、ChatGPTやGeminiでも動きます。ただしキャッシュの挙動は各社で仕様が異なるため、単価の試算は自社が使うモデルの料金表で置き換えてください。
最初に、キャッシュに載せる前提文そのものを作るプロンプトです。ここが雑だと後の全部が雑になります。
プロンプト1：キャッシュ用の共通前提文を作る
あなたはEC事業者の業務標準を整備する編集責任者です。
以下の断片情報を統合し、AIに毎回渡す「共通前提文」を作ってください。
断片情報：
{ブランドのトーン、禁止表現、モール別の文字数制限、過去の優良原稿3本を貼り付け}
出力条件：
1. 構成は「1.前提となる自社情報 2.表記ルール 3.禁止事項 4.出力フォーマット」の順に固定
2. 日付・担当者名・実行IDなど、毎回変わる情報は一切含めない
3. 末尾にバージョン番号の記入欄を置く
4. 全体で2,000〜6,000トークンに収める（長すぎる場合は重複を削る）
次に、商品説明文をモール別に書き分けるプロンプトです。前提文をキャッシュに載せた状態で、可変データだけを差し替えて回します。
プロンプト2：モール別の商品説明文を同時生成
（共通前提文はキャッシュ済みとして先頭に配置）
以下の商品情報から、楽天市場・Amazon・Yahoo!ショッピング・自社ECの4系統ぶんの原稿を作ってください。
商品情報：
{商品名・素材・サイズ・産地・価格・訴求ポイントを貼り付け}
出力条件：
1. 楽天は商品名を半角255文字以内、キャッチコピーを半角174文字以内
2. Amazonはタイトルを半角200文字以内、箇条書き5項目
3. Yahoo!ショッピングは商品名75文字以内、キャッチコピー60文字以内
4. 自社ECは文字数制限なし、ただし冒頭150文字で結論を言い切る
5. 4系統で同じ訴求語を機械的に流用せず、各モールの表示面に合わせる
3本目は、エフォート設定を使い分けるための仕分けプロンプトです。
プロンプト3：エフォート設定の割り当て表を作る
あなたはAI運用の設計担当です。
以下の業務一覧を、思考エフォートの5段階（最低／低／中／高／最高）に割り当ててください。
業務一覧：
{業務名・1件あたりの所要時間・失敗時の手戻り時間を貼り付け}
出力条件：
1. 割り当ての判断軸は「失敗時の手戻り時間」に置く
2. 各業務について、そのエフォートを選んだ理由を1行
3. 中以上を割り当てた業務が全体の3割を超える場合、超えた分を落とす候補を指摘
4本目は、長いコンテキストを活かす使い方です。カタログ全体の整合を見ます。
プロンプト4：カテゴリ横断の商品情報監査
あなたは商品マスタの品質管理担当です。
以下の商品データ全件を読み、情報の欠落と矛盾を検出してください。
商品データ：
{同一カテゴリの全商品の商品名・説明文・スペック・価格を貼り付け}
出力条件：
1. 必須属性が欠けている商品を一覧化（商品コードつき）
2. 同一シリーズ内でスペック表記が割れている箇所を指摘
3. 価格帯と訴求文が矛盾している商品を抽出（例：高価格帯なのに訴求が安さのみ）
4. 修正の優先順位を、売上貢献度ではなく検索流入への影響で並べる
5本目は、コスト監視です。単価が下がっても、使用量が増えれば請求は増えます。
プロンプト5：AI利用の月次コストレポートを作る
以下の利用ログから、業務別のコストレポートを作ってください。
利用ログ：
{業務名・実行回数・入力トークン・キャッシュ読み出しトークン・出力トークンを貼り付け}
前提単価（100万トークンあたり、米ドル）：
- 入力10 / 出力50 / キャッシュ読み出し0.25
出力条件：
1. 業務別の月額を円換算（1米ドル150円、為替前提を明記）で提示
2. キャッシュ読み出しの比率が低い業務を「改善余地あり」として抽出
3. 上位3業務について、前提文の見直しで削減できる見込み額を試算（試算であることを明記）
6本目は、長時間エージェントを走らせる前の安全確認です。自動で受注や在庫を触らせる前に通します。
プロンプト6：自動処理の停止条件を定義する
あなたはEC事業者の業務リスク管理担当です。
以下の自動処理について、途中で止めるべき条件を定義してください。
自動処理の内容：
{処理の目的・触るデータ・実行頻度を記述}
出力条件：
1. 「即座に停止すべき条件」を5つ、判定可能な形（数値・状態）で定義
2. 「人に確認を求める条件」を5つ
3. 停止したときに誰へ通知するかの経路を1行で
4. 判定できない曖昧な条件は採用せず、その旨を明記
移行と検証を2週間で回す手順
乗り換えの検証は2週間で終わります。長く引っ張ると、その間にモデル側が更新されて前提が変わるためです。
1週目の前半は、前提文の抽出に充てます。いま使っているプロンプトを全部集め、共通して書かれている内容を1つの文書にまとめます。この作業をすると、同じルールが少しずつ違う表現で10箇所に散らばっていることに気づきます。統合すること自体に品質改善の効果があります。
1週目の後半で、キャッシュ有効・無効の比較を行います。同じ処理を10回ずつ流し、入力トークンの内訳を記録します。ここでキャッシュ読み出しが計上されていなければ、前提文の構造に問題があります。可変情報が先頭に混ざっていないかを確認してください。
2週目の前半は、エフォート設定の調整です。業務ごとに最低から最高まで振ってみて、出力の質が変わらない下限を探します。多くの定型業務は、中より下で十分な質が出ます。ここを詰めると出力トークンが減り、費用が下がります。
2週目の後半で判断します。判断材料は、月額の見込み、キャッシュ読み出し比率、そして出力の合格率の3つ。合格率が前世代と同等以上で月額が下がっていれば、移行して問題ありません。楽天/Amazonの両方を回している店舗で観測されたのは、この2週間の検証を経た会社ほど、次のモデル更新のときの判断が速いという傾向でした。
失敗例と回避策
現場で起きやすい失敗を3つ挙げます。
ひとつ目は、キャッシュを前提にした設計をしないまま単価だけ見て喜ぶことです。キャッシュ読み出しが安いのは事実ですが、キャッシュに載る構造で投げていなければ1円も下がりません。前提文と可変データの境界を設計に落とし、実際にキャッシュ読み出しトークンが計上されているかを請求データで確認してください。回避策は、初月に1度だけキャッシュ読み出し比率を測ることです。
ふたつ目は、エフォートを上げっぱなしにすることです。適応的な思考が既定になったことで、モデルは必要に応じて長く考えます。そこへ最高エフォートを固定で指定すると、簡単な処理でも思考ぶんの出力トークンが積み上がります。出力は100万トークンあたり50米ドルなので、ここが膨らむと効果が相殺されます。5,000社支援の中で何度も再現したパターンとして、コストが下がらない会社はたいてい出力側を見ていません。
3つ目は、長いコンテキストへの過信です。100万トークン入るからといって、関係のないデータまで全部渡すと、精度はむしろ落ちます。必要な範囲に絞って渡したほうが、出力の焦点が合います。カタログ監査であればカテゴリ単位、受注分析であれば期間単位に区切るのが定石です。
4つ目の落とし穴が、為替です。API料金は米ドル建てで請求されます。単価が下がっても、円安が進めば円建ての請求額は下がりません。予算を組むときは、為替前提を明記したうえで、上下10%程度の振れ幅を織り込んでおいてください。社内報告で「単価が75%下がったのに請求が減っていない」という議論になる原因の多くは、為替と使用量の増加です。
KPIと費用の目安
見るべき指標は、月額、キャッシュ読み出し比率、そして削減できた人時間の3つです。
費用の目安を置きます。商品説明文の生成を、前提文2万トークン・可変データ1,000トークン・出力1,500トークンで月3,000件実行する場合を考えます。前提文をキャッシュに載せられれば、入力側は2万×3,000＝6,000万トークンがキャッシュ読み出し扱いとなり0.25米ドル換算で15米ドル。可変データ300万トークンが標準入力で30米ドル。出力450万トークンで225米ドル。合計およそ270米ドル、日本円で4万円前後（1米ドル150円換算の目安）です。キャッシュを使わない場合は入力側だけで600米ドルを超えるので、差は歴然です。
この試算で分かるのは、キャッシュを効かせた後は出力側が費用の大半を占めるということです。次に手を入れるべきは出力の削減で、具体的には「不要な説明文を出力させない」「フォーマットを固定して冗長な前置きを削る」といった設計になります。出力フォーマットを厳密に指定するだけで、出力トークンが3割減ることは珍しくありません。
定額プランの位置づけも整理しておきます。Claude Pro、ChatGPT Plus、Google AI Proはいずれも月額20米ドル前後です。担当者が対話しながら考える用途は定額プラン、件数が読める自動処理はAPI、という住み分けが実務的です。両方に同じ作業をさせて比べる必要はありません。
工数の削減幅は業務によって差が出ます。店舗運営の現場感覚では、原稿づくりの初動が半分以下になる一方、公開前の確認工程はほとんど変わりません。導入効果を見積もるときは、確認工程を削減対象に入れないでください。
もうひとつ、モデル更新のたびに出力の癖が変わる点への備えも要ります。適応的な思考が既定になったことで、以前より説明的な出力が増えたという声が現場から上がっています。出力フォーマットを厳密に指定していないプロンプトほど、この変化の影響を受けます。前提文の末尾に出力フォーマットの雛形を置き、「この形式以外では出力しない」と明示しておくと、モデルが更新されても出力の形は保たれます。編集部で実際に運用しているプロンプトでは、出力の先頭3行を固定ラベルにして、機械的に後段処理へ渡せる構造にしています。
品質の測り方も決めておきましょう。生成物の良し悪しを担当者の主観で判断していると、モデルを変えるたびに議論が振り出しに戻ります。商品説明文であれば「必須属性が5つ含まれているか」「禁止表現が含まれていないか」「冒頭150文字で結論が出ているか」といった機械的に判定できる項目を3つ決め、合格率で管理してください。数字で管理できるようになると、エフォートを下げても合格率が変わらない業務が見つかり、そこから費用が削れます。
長時間エージェントをEC業務へ入れる順序
ここから先の論点は、単発の生成ではなく、時間のかかる処理を任せられるかどうかに移ります。適応的な思考と100万トークンのコンテキストが揃うと、受注データの突合、在庫の発注点見直し、広告レポートの読み解きといった、数十分かかる作業を一括で任せる設計が現実的になります。
導入の順序としては、読むだけの処理から始めるのが安全です。データを読んで報告書を出すところまでを自動化し、変更操作は人が行う。ここで精度が安定してから、変更操作の一部を任せます。いきなり在庫数や価格を書き換えさせる設計にすると、止め方の設計が追いつきません。プロンプト6で停止条件を定義してから進めてください。
コストの観点では、モデル間の使い分けが引き続き有効です。うるチカラでは、キャッシュ読み出し75%減の意味と、API費用が7割超下がった事例を個別に取り上げました。他社のフラッグシップとの比較は、GPT-6 Astraのコスト設計もあわせて読むと判断材料が揃います。単価はほぼ同水準に並んだので、差がつくのはキャッシュとエフォートの設計です。
最後に、モデル選定を年に何度も議論しないための工夫を挙げます。単価表と評価セットを1つのスプレッドシートにまとめ、新しいモデルが出たらその行を1つ足すだけで比較が終わる形にしておくことです。比較軸は、入力単価、出力単価、キャッシュ読み出し単価、コンテキスト長、評価セットの合格率、平均出力トークンの6項目で足ります。この表があるかどうかで、モデル更新への対応コストが大きく変わります。表を持たない会社は毎回ゼロから調べ直し、持っている会社は半日で結論を出しています。
よくある質問
Claude Fable 5.1に乗り換えるべきですか
はい、Fable 5を使っているなら乗り換える価値があります。本体価格は同じままキャッシュ読み出しが75%下がっているため、同じ使い方でも費用が減ります。ただしキャッシュに載る構造で投げていることが前提です。
キャッシュはどう有効にするのですか
API側でキャッシュ対象のブロックを指定します。同じ内容・同じ順序で渡したときに読み出し扱いになるため、前提文を固定し、可変情報を後ろに置く構造にしてください。指定方法は公式ドキュメントの料金ページに記載があります。
エフォート設定は何を基準に選びますか
失敗したときの手戻り時間で選びます。数分で直せる処理は低め、判断を誤ると半日かかる処理は高め、という割り当てが実務的です。すべてを高くすると出力トークンが増えて費用が上がります。
100万トークンのコンテキストは全部使っていいですか
いいえ、必要な範囲に絞るほうが精度が上がります。関係のないデータを混ぜると出力の焦点がぼやけます。カタログ監査ならカテゴリ単位、受注分析なら期間単位で区切ってください。
Mythos 5.1とは何が違いますか
Mythos 5.1は同じ基盤モデルの限定提供版で、特定用途向けに提供されるものです。一般のEC事業者が業務で使うのはFable 5.1のほうになります。選定資料には提供形態まで明記しておくと混乱が減ります。
日本語の商品説明文でも精度は出ますか
実務で使える水準にはありますが、自社の商材で検証してから展開してください。素材名や産地表記のような固有名詞は、前提文に正しい表記を書いておかないと揺れます。公開前の確認工程は残す前提で設計します。
費用が思ったより下がらないときは何を見ますか
キャッシュ読み出しトークンの比率と、出力トークンの量です。前提文の先頭に可変情報が混ざっているとキャッシュが効きません。出力側は、フォーマットを固定して前置きを削るだけで減らせます。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Anthropic｜Claude Fable
- Claude Platform Docs｜Pricing
- VentureBeat｜Anthropic’s Claude Fable 5.1 and Mythos 5.1 arrive with a 75% cost reduction for Fable cache reads
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
