投稿者 投稿日: カテゴリー EC×AI活用
コンテキスト圧縮とは、長時間の作業で必要な情報だけを残す仕組みのことです。
生成AIにEC業務を任せるとき、最初にぶつかるのは「途中で話を見失う」問題でした。1,000商品の説明文を順に書き直させると、300商品目あたりで最初に決めたルールがぶれ始めます。Metaが2026年8月5日に公開したMuse Spark 1.2は、この長時間の作業を持続させることを主眼に置いたモデルです。計画立案、目標条件づけ、コンテキスト圧縮、そして非同期・並列のツール呼び出しを組み合わせ、数時間規模の作業で方向を保つ設計になっています。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづいて解説します。仕組みの正確な理解と、EC業務のどの作業が現実解になるかを、プロンプト5本と一緒に整理します。
長時間タスクで何が壊れるのか
生成AIに長い作業を任せたときに起きる失敗は、能力不足ではなく記憶の問題です。会話が進むにつれて過去のやり取りが蓄積し、最初に指示したルールが大量の作業ログに埋もれます。300商品目で表記ゆれが出るのは、モデルが忘れたというより、ルールの優先度が相対的に下がるからです。
Meta AI Researchの公式ブログによると、Muse Spark 1.2は長期的な作業を続けるために必要な知識を保持する目的でコンテキスト圧縮を使います。作業の全履歴を持ち続けるのではなく、進行に必要な情報だけを残す仕組みです。あわせて、Muse Codeという実行エージェント側では非同期のバックグラウンドエージェントがセッション中ずっと動き続け、いつメインのエージェントへ報告を返すかを自ら選びます。従来のように、ツールを1つ呼んで結果を待ち、次を呼ぶという直列の進行とは構造が違います。
この2点がEC業務にとって何を意味するか。まず、作業の途中でルールがぶれにくくなります。次に、待ち時間が減ります。商品データの取得、在庫の照合、画像の確認といった作業を並行で走らせ、結果が返ってきたものから処理を進められます。1,000商品の処理で、1件あたり3秒の待ち時間があれば合計50分になります。並列化が効く領域はここです。
性能面では、Terminal-Bench 2.1、DeepSWE 1.1、Metaの内部コーディングベンチマークの3つで、比較対象のモデルを上回ると示されています。ただし公式ブログの本文には具体的な数値が読み取れる形で記載されておらず、スコアの差がどの程度かは要確認です。コンテキスト長についても、報道ベースでは100万トークン規模とされていますが、公式ブログには明記がありません。数字を社内資料に転記する際は、出所を確認してから使ってください。
提供面は、Muse Code内とMeta Model APIで利用可能とされ、グローバルでのアクセスが拡大しています。料金は公表されていません。前世代のMuse Spark 1.1の費用感を基準に、処理量から概算するのが当面の現実解です。
EC業務で「長時間タスク」に該当する作業
長時間タスクという言葉は抽象的なので、EC運営の作業に翻訳します。該当するのは、対象が多く、判断基準が一定で、途中で人が介在しなくても進む作業です。
代表格は、全商品の説明文の一括見直しです。表記ルールを統一する、禁止表現を除去する、条件属性を追記するといった作業は、1商品あたりの判断は単純でも、点数が多いと人手では数週間かかります。商品点数1,000点で、1商品あたり3分かければ50時間です。この作業は、ルールさえ明確なら機械的に進みます。
次に、在庫と商品マスタの突き合わせです。複数のモールと自社ECで商品コードの体系が違う店舗では、月次の棚卸しが重い作業になります。データの照合と差分の抽出は、非同期で並行処理する価値が高い領域です。
3つ目は、レビューと問い合わせの分類です。数百件のテキストを読み、論点ごとに分類し、対応の優先度をつける作業は、一定の基準さえ決まっていれば任せられます。問い合わせログの監査可能性を確保しておけば、後から判断の根拠も追えます。
一方で、向かない作業もあります。判断基準が案件ごとに変わるもの、法令上の最終判断が要るもの、社外に出る文面の最終確認。これらは長時間タスクの形にしても、結局は人が全件を見ることになり、時間は減りません。価格の決定、返金の可否、クレーム対応の方針といった判断は、AIに下書きを作らせて人が決める形にとどめてください。
判断の目安として、その作業を新人スタッフに任せるとき、マニュアルだけで完結するかを考えると分かりやすくなります。マニュアルで完結するなら長時間タスク向き、その都度の相談が必要なら向いていません。
該当する作業をもう少し挙げておきます。カテゴリー分類の見直しは、商品点数が多い店舗ほど後回しになりがちな作業で、基準さえ決まれば任せられます。画像のalt属性の一括付与も同様です。商品画像が1商品あたり5枚、1,000商品で5,000枚となると人手では現実的でなくなりますが、商品名と属性から生成する形なら一括処理が成り立ちます。楽天市場の商品名を半角255文字（全角換算127文字）の制限内で整えなおす作業、Amazonの検索キーワード欄を250バイト以内に収める作業も、制約が数値で明確なので機械的に処理できます。
季節の切り替えに伴う一括更新も候補です。母の日やお中元の訴求文を全商品から外す作業は、放置すると時期外れの記述が残り続けます。年に数回の定例作業として仕組み化しておくと、担当者の記憶に依存しなくなります。
長時間タスクを設計するプロンプト5本
ここからのプロンプトは、ChatGPT、Claude、Geminiでも動きます。2026年8月時点の主要モデルは、OpenAIのGPT-5.6系、AnthropicのClaude Fable 5、GoogleのGemini 3.7 Flashです。Muse Spark 1.2の特性を活かす前提でも、指示の設計自体はモデルに依存しません。
1本目は、作業を長時間タスクとして成立させるための仕様書を作るプロンプトです。ここが甘いと、どのモデルを使っても途中で崩れます。
プロンプト1：長時間タスクの仕様書作成
あなたは業務自動化の設計者です。
以下の作業を、AIエージェントが数時間にわたって中断なく実行できる仕様書に落としてください。
仕様書に含める項目：
1. 完了条件（何がどうなったら終わりか、数値で定義）
2. 1件あたりの処理手順（判断が分岐する箇所を明示）
3. 判断できない場合の扱い（保留リストに退避し、処理は継続する）
4. 絶対に変更してはいけない項目（価格・在庫数・商品コードなど）
5. 進捗の記録方法（何件処理したかを追える形式）
作業内容：{作業の説明}
対象件数：{件数}
使用データ：{ファイル形式・項目}
出力：仕様書（1,500字程度）と、着手前に人が決めておくべき事項のリスト
2本目は、処理ルールを1枚に固めるためのプロンプトです。コンテキスト圧縮が働いても、ルール自体が曖昧なら結果はぶれます。
プロンプト2：判断ルールの明文化
あなたはEC運営のオペレーション責任者です。
以下の作業について、AIが迷わず判断できるルールを作成してください。
条件：
1. 各ルールは「もし〜なら〜する」の形で書く
2. 例外は列挙し、例外に該当した場合は保留として処理を止めない
3. 表記ゆれの統一ルール（全角半角、単位、記号）を含める
4. 禁止表現のリストを含める（薬機法・景品表示法の観点）
5. 判断に迷う境界事例を5つ挙げ、それぞれの正解を示す
作業内容：{作業の説明}
商品ジャンル：{ジャンル}
既存の社内ルール：{あれば記入}
出力：ルール一覧、境界事例と正解、ルールの適用順序
3本目は、中断と再開に耐える設計を作るためのものです。長時間タスクは必ずどこかで止まります。
プロンプト3：中断・再開の設計
あなたはシステム運用の設計者です。
以下の長時間タスクについて、途中で中断しても安全に再開できる設計を作成してください。
含める内容：
1. 処理単位の分割方法（何件ごとに区切るか、その根拠）
2. 各区切りで保存する状態（処理済みの識別子、保留件数、エラー内容）
3. 再開時に重複処理を防ぐ仕組み
4. 途中結果の検証方法（サンプル抽出の割合と確認項目）
5. 全件やり直しが必要になる条件
タスク内容：{記入}
対象件数：{件数}
1件あたりの想定処理時間：{秒}
出力：設計書、区切りごとのチェックリスト、再開手順
4本目は、実行後の検証に使います。任せた結果をそのまま公開するのは危険です。
プロンプト4：一括処理結果の抜き取り検証
あなたは品質管理の担当者です。
以下の一括処理の結果から、検証すべきサンプルを選び、確認項目を設計してください。
条件：
1. 処理の初期・中盤・終盤から均等にサンプルを抽出する（ルールのぶれは終盤に出やすい）
2. 保留になった件は全件確認の対象とする
3. 確認項目は、事実の誤り／ルール違反／表記ゆれ／禁止表現の4観点で分ける
4. 抽出率は対象件数に応じて提案し、根拠を示す
処理内容：{記入}
対象件数：{件数}
保留件数：{件数}
出力：サンプル抽出の方針、確認項目のチェックリスト、不合格時の対応手順
5本目は、費用と時間の見積もりです。長時間タスクは、走らせてから請求額に驚くことがあります。
プロンプト5：長時間タスクの費用・時間見積もり
あなたはEC事業の管理担当です。
以下の条件で、AIエージェントに長時間タスクを実行させた場合の費用と時間を試算してください。
試算に含める項目：
1. 1件あたりの入力・出力トークン数の見積もりと根拠
2. 総トークン数と概算費用（単価は{記入}を使用）
3. 並列実行した場合と直列実行した場合の所要時間の差
4. 人手で実施した場合の工数と人件費との比較
5. 失敗して再実行する場合を見込んだ予備費（想定の1.5倍を目安）
タスク内容：{記入}
対象件数：{件数}
1件あたりの平均文字数：{文字}
出力：試算表（文章形式）、損益分岐となる件数、実行を推奨するかの判断
1,000商品の説明文を一括で書き直す流れ
抽象論だけでは動けないので、実際の手順を1つ通しで示します。対象は商品点数1,000点の店舗で、表記ルールの統一と条件属性の追記を同時に行う想定です。
最初にやるのは、ルールの確定です。全角半角の使い分け、単位の書き方（グラムかgか）、日付の形式、禁止表現のリスト。これを1枚の文書にまとめます。ここを飛ばして「良い感じに直して」と指示すると、300商品目でぶれます。ルールの明文化に半日かけても、後の手直しを考えれば安い投資です。
次に、対象データを整えます。商品コード、現在の商品説明、属性項目、カテゴリーをCSVで書き出します。楽天市場ならRMSの商品一括編集で出力、ShopifyならAdminの商品エクスポート、Amazonならレポートからダウンロードします。ここで重要なのは、商品コードを必ず含めることです。処理の結果を元データに戻すとき、コードがないと突き合わせができません。
3つ目に、20件だけで試します。全件を流す前に、初期の20件を処理して人が全部読みます。この段階で見つかるのは、ルールの解釈違い、想定していなかった商材の存在、データの欠損です。3つとも、全件を流してから見つかると被害が大きくなります。20件の確認に30分かければ、やり直しの数時間を防げます。
4つ目に、区切りを決めて実行します。100件ごとに処理結果を保存し、処理済みの商品コードを記録します。途中で止まっても、記録があれば続きから再開できます。この区切りがないと、900件目で止まったときに最初からやり直すことになります。
最後に、抜き取り検証です。処理の初期、中盤、終盤からそれぞれサンプルを取ります。ルールのぶれは終盤に出やすいため、終盤のサンプルを厚めにするのが実務的なコツです。保留になった件は全件確認します。ここまで通して、商品点数1,000点なら準備2日、実行と検証で1日程度が目安になります。
他のモデルとどう使い分けるか
Muse Spark 1.2が向くのは、対象が多く、手順が定型で、途中に外部データの取得が挟まる作業です。非同期のツール呼び出しが効くのは、待ち時間が積み上がる場面だからです。在庫システムへの問い合わせ、画像の確認、外部サイトの参照が1件ごとに発生する処理では、並列化の効果がはっきり出ます。
逆に、1件ずつ丁寧に仕上げたい作業では、この特性はあまり効きません。1本のキャッチコピーを練る、重要顧客への返信文を書くといった作業は、対話しながら詰めるほうが早く着地します。ここは各社のフラッグシップモデルとの差が出にくい領域です。
日本語の商材文の細かなニュアンス、たとえば食品の食感表現や化粧品の使用感の描写については、モデルごとに得手不得手があります。実務では、同じ商品説明を複数のモデルで書かせて社内で比較し、ジャンルごとに使うモデルを決めている店舗もあります。手間はかかりますが、一度決めれば長く使える判断です。店舗運営の現場感覚では、モデル選定に悩む時間より、ルールの明文化に時間を使ったほうが成果に直結します。
任せて事故が起きる3つのパターン
現場で繰り返し見るのは、価格や在庫数を触らせてしまうパターンです。商品説明の一括更新のつもりが、指示の解釈違いで価格フィールドまで書き換わると、実害が出ます。回避策は権限の設計で、書き換えてよい項目を明示的に限定し、それ以外は読み取り専用にすることです。仕様書の段階で「変更してはいけない項目」を列挙しておいてください。
2つ目は、途中結果を確認せずに全件を走らせるパターンです。1,000件の処理を開始し、終わってから最初の10件を見たらルール解釈が違っていた、という事故は珍しくありません。最初の20件を処理した時点でいったん止め、人が確認してから残りを流す。この一手間で、やり直しの時間がまるごと消えます。
3つ目は、保留の扱いを決めないパターンです。判断できない件に遭遇したとき、AIが推測で処理を続けると、間違いが静かに混ざります。判断できない件は保留リストに退避させ、処理自体は継続する設計にしてください。保留が全体の何パーセントを超えたら中断するか、という閾値も決めておくと安全です。目安として、保留率が10パーセントを超えるなら、ルール自体を見直す段階にあります。
費用と工数、そして測る指標
長時間タスクの費用は、対象件数と1件あたりの文字数でほぼ決まります。商品説明の書き換えを例に取ると、1商品あたり入力1,500文字、出力1,500文字程度が目安で、1,000商品なら合計300万文字規模になります。実際のトークン単価はモデルとプランで変わるため、小規模な試行で実測してから全件に広げる進め方が確実です。Muse Spark 1.2の料金は2026年8月時点で公表されていないため、この点は要確認として扱ってください。
工数の面では、仕様書とルールの作成に半日から1日、試行と検証に半日、全件実行の見守りに1時間程度を見込む水準が現実的です。人手で1,000商品を50時間かけて処理していた作業が、準備2日と実行数時間に置き換わるなら、投資は回収できます。ただし準備を省くと精度が落ち、検証と手直しで時間が消えます。準備工数を削らないことが、結果的に最短経路になります。
人手との比較を数字で置くと判断しやすくなります。1,000商品の説明文を人手で直す場合、1件3分でも50時間、時給2,000円換算で10万円分の工数です。外注に出せば1商品あたり数百円から、1,000商品で数十万円規模になります。AIに任せる場合の費用は、準備の人件費とトークン費用の合計です。準備に2日（16時間・約3万2,000円相当）かけ、トークン費用が数千円から数万円で収まるなら、初回から十分に見合います。2回目以降は準備が再利用できるため、差はさらに開きます。
ただし、この試算が成り立つのは検証を含めた場合です。検証を省いて誤りが本番に出ると、修正と信用の回復にかかる時間が試算を吹き飛ばします。直近の支援案件で観測したのは、検証工程を省いた店舗が、公開後の手直しで結局2倍の時間を使ったケースでした。
測る指標は3つです。第1に、一発で通った件数の比率。ここが80パーセントを下回るなら、ルールの明文化が不足しています。第2に、保留率。第3に、検証で見つかった誤りの件数と種類です。誤りの種類が事実誤認に偏っているなら渡すデータの問題、表記ゆれに偏っているならルールの問題と切り分けられます。
モデル選定の観点で見ておくこと
長時間タスクを回す道具として見たとき、モデルの単体性能より、実行環境との組み合わせが結果を左右します。Muse Spark 1.2はMuse Codeと共同で訓練されており、その実行エージェント上で最も性能が出るよう調整されています。これは性能面での利点である一方、実行環境との結びつきが強いという意味でもあります。ベンチマークと実行環境の組み合わせによる囲い込みは、ツール選定で見落とされやすい論点です。
EC事業者としての現実的な構えは、業務の仕様書とルールを、特定のモデルに依存しない形で持っておくことです。仕様書とルールが独立していれば、モデルが変わっても移し替えるだけで済みます。逆に、特定のツールの操作手順としてしか業務が記述されていないと、乗り換えのたびに設計からやり直しになります。5,000社支援の中で何度も再現したパターンとして、ツールを頻繁に変える店舗より、業務の記述を持っている店舗のほうが結果的に新しい道具を早く使いこなします。
もう一点、非同期の処理が当たり前になると、人の関わり方も変わります。作業を投げて結果を待つのではなく、走っている作業の進捗を見て、必要なときだけ介入する形に近づきます。この働き方に合わせて、確認のタイミングと担当を決めておくことが、実務では効いてきます。
よくある質問
コンテキスト圧縮とは何ですか
コンテキスト圧縮とは、長時間の作業を続けるうえで必要な情報だけを残し、それ以外を落とす仕組みのことです。会話の全履歴を持ち続けると、最初に決めたルールが埋もれて判断がぶれます。圧縮によって、作業の方向を保ちやすくなります。
非同期ツール呼び出しは何が便利ですか
結果を待たずに次の作業へ進める点です。従来は1つのツールを呼んで結果が返るまで止まっていましたが、非同期であれば複数の処理を並行して走らせ、返ってきたものから処理できます。件数の多い作業ほど、待ち時間の削減効果が大きくなります。
Muse Spark 1.2はいくらで使えますか
2026年8月時点で料金は公表されていません。Muse Code内とMeta Model APIで利用可能とされています。費用は小規模な試行で実測してから、全件に広げる進め方をおすすめします。
コンテキスト長は100万トークンですか
報道ではその規模とされていますが、Metaの公式ブログには明記がなく、要確認です。社内資料に数値を転記する際は、出所を確認したうえで使ってください。
EC業務のどこから試すべきですか
商品説明の表記統一のような、判断基準が一定で対象が多い作業からです。誤っても影響が限定的で、結果の良し悪しが目で見て分かる作業を選ぶと、社内での評価がしやすくなります。
価格や在庫を触らせても大丈夫ですか
おすすめしません。書き換えてよい項目を明示的に限定し、価格・在庫数・商品コードは読み取り専用にしてください。実害が出る領域は、AIの精度に関係なく権限で守るのが定石です。
途中で止まったらどうなりますか
再開の設計をしていれば、処理済みの識別子から続きを実行できます。設計していない場合は全件やり直しになるため、処理を一定件数ごとに区切り、進捗を保存する仕組みを最初に作ってください。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Meta AI Research: Introducing Muse Code and Muse Spark 1.2
- Meta AI Developers: Meet Muse Spark 1.2 and Muse Code
- VentureBeat: Meta enters the AI coding wars with Muse Spark 1.2 and Muse Code
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
