投稿者 投稿日: カテゴリー EC×AI活用
Muse Codeとは、Metaが2026年8月5日にベータ公開したターミナル向けコーディングエージェントのことです。
注目すべきは搭載モデルではなく、実行基盤のほうです。1つの指示が複数のサブエージェントに分岐し、その全員の判断とツール実行が追記専用のイベントログに順番どおり記録される。途中でプロセスが落ちても、ログを読んで「どこまで実際に起きたか」を確認してから再開する。EC業務の自動化で最後まで残る不安は、AIが賢いかどうかではなく「勝手に何をしたか後から説明できるか」でした。その一点に正面から答えようとした設計なので、在庫や受注のような取り返しのつかないデータを扱う店舗ほど読む価値があります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづいて解説します。
Muse Codeが競合と違うのは「落ちた後」の扱い方
2026年8月時点で、AIコーディングエージェントの比較軸はベンチマークスコアに偏っています。しかしMuse Codeが主張しているのは別の軸です。Metaの製品ドキュメントによると、副作用を伴う1つの操作は7種類の記録に分解されて書き込まれます。提案、受理、承認レビュー要求、決定の適用、その決定を根拠とする副作用の意図、実行開始、そして終端記録です。この順序で、しかも「意図の記録が先、実際の副作用が後」という不変条件を守って書かれます。
この設計が効くのは、クラッシュした瞬間です。意図の記録はあるのに終端記録がない場合、その副作用は「起きたかもしれないし起きていないかもしれない」状態として扱われます。再開時のエージェントは、単に同じ処理をやり直すのではなく、実際の状態を見に行ってから残りだけを実行します。Digital Appliedが紹介しているMeta自身の例では、8件のうち7件まで移行が終わった時点で強制終了されたジョブが、再開時に台帳を確認して未処理の1件だけを処理し、重複した副作用をゼロで完走しています。
EC業務に置き換えると、この差は決定的です。たとえば1,200件の商品説明文を一括で書き換えるジョブが900件目で落ちたとします。チェックポイント方式なら「直前の保存地点まで巻き戻して再実行」になり、モールへのAPI送信が重複する余地が残ります。イベントログ方式なら、900件目が実際に送信されたかどうかを状態から確認してから901件目に進めます。楽天RMSやAmazon Seller Centralのように、同じ更新を二重に投げると履歴が汚れる環境では、この違いがそのまま運用リスクの差になります。
もう1つ、監査の観点で見逃せないのがエクスポートの仕様です。muse export はログをオフラインで自己完結したJSON文書に書き出し、同じログと同じフラグなら同一のハッシュになるバイト単位で決定的な形式になっています。つまり「このハッシュの実行を根拠に、この日の商品データを更新しました」と外部に説明できる状態が作れます。委託先にEC運用を任せている事業者や、親会社に作業証跡を求められる事業者にとっては、ここが実務上いちばん使える部分です。
サブエージェントの並列実行は、gitリポジトリの中でだけ安全になる
並列実行の仕組みも、監査要件と直結しています。Muse Codeのファンアウトは、親エージェントが書き込み権限を持つ子エージェントを生成する形をとります。ワークツリー分離を有効にすると、実行基盤がリポジトリ相対の .muse/worktrees/ 配下に子ごとのgitワークツリーを作り、親のHEADから切り離した状態でチェックアウトします。子同士が同じファイルを奪い合わないのは、そもそも別の作業コピーを見ているからです。
同時実行数には上限があります。Metaの2つのドキュメントはいずれも「ホストのコア数マイナス2」という式を示しており、8コアのマシンなら6、16コアなら14が計算上の値になります。ただし、この式に対してどんなクランプ（上限の切り詰め）がかかるかは2つのページで記述が食い違っているため、自分のマシンで実測して確かめる必要があります。ここは要確認の領域です。
現場で必ず引っかかるであろう落とし穴が3つあります。1つ目は、サブエージェントの入れ子が1階層までという制限です。子が孫を生成できないので、「調査役が実装役を3人呼ぶ」といった再帰的な委譲を前提にした設計は静かに平坦化されます。2つ目は、キャンセルが協調的である点です。停止を指示しても、チェックポイントに到達していない子は走り続け、書き込みの途中だった子はその書き込みを完了させます。3つ目は、キューに入れた指示が子の次のターンにしか効かないことです。強制的に方向転換させたい場合は、割り込みオプション付きで送る必要があります。
そして最も危険なのが、ワークツリー分離がオプトインであり、gitリポジトリを必要とするという仕様です。gitで管理されていない作業ディレクトリでは、分離フラグは黙って無視され、すべての子が親と同じ作業領域を共有します。エラーも警告も出ません。商品データのCSVをgit管理せずに置いているEC事業者は珍しくないので、ファンアウトを使う前に「ここはgitリポジトリか」を確認する手順を運用に入れてください。
EC業務の自動化にMuse Codeを試すためのプロンプト5本
ここからは実際に投げるプロンプトを5本示します。前提として、承認モードは既定の on-request、サンドボックスは有効のまま、最初の対象は本番でないブランチにしてください。並列処理そのものの考え方はClaude Codeのマルチエージェントで並列処理を設計する記事でも整理しているので、比較しながら読むと違いが立体的になります。
最初に必要なのは、ゴールと合格判定を先に固定する作業です。Muse Codeの goal コマンドは目的と受け入れ判定をセッションに固定し、完了時には監査を通してからでないと閉じられません。曖昧な合格ラインを書くとエージェントが勝手に勝利宣言するので、判定の物差しを名指しします。
プロンプト1：ゴールと合格判定の固定（監査つきで閉じさせる）
このセッションのゴールを固定してください。
ゴール：{対象ディレクトリ}配下の商品説明文Markdownのうち、薬機法の禁止表現リストに該当する記述をすべて代替表現に置き換える。
合格判定（この条件を満たすまでゴールを閉じないこと）：
1. tests/test_yakkiho.py の全12ケースがパスすること
2. 置換した箇所の一覧を changes.md に「ファイル名・行番号・置換前・置換後・根拠」の5項目で出力すること
3. 元の意味が変わった可能性がある置換は、changes.md 内で「要人手確認」と明記すること
注意：合格判定はテストコマンドの実行結果で判断してください。自己申告で完了扱いにしないでください。
次に、並列化してよい作業かどうかを事前に切り分けます。EC業務には「並列にすると壊れるもの」が確実に含まれるため、この判断をエージェント任せにしないことが重要です。
プロンプト2：ファンアウト可否の事前診断
以下のタスクを、サブエージェントへの並列分割で実行してよいか診断してください。実装はまだしないでください。
タスク：{タスク内容}
対象ファイル群：{ディレクトリまたはファイル一覧}
診断してほしい観点：
1. 各サブタスクが編集するファイルに重なりがあるか（あるなら重なる組み合わせを列挙）
2. 外部APIへの書き込みを含むか（含むならどのAPIか、冪等性はあるか）
3. 実行順序に依存関係があるか（あるなら依存の向き）
4. 現在の作業ディレクトリがgitリポジトリかどうか
5. 上記を踏まえた推奨分割数と、その根拠
出力：並列実行の可否を「可／条件付き可／不可」で結論から書き、理由を続けてください。
3本目は、実際のファンアウトです。分割数はホストのコア数から算出した値を上限として、それより小さく始めるのが安全です。
プロンプト3：ワークツリー分離つきの並列実行
以下の作業を、サブエージェントへのファンアウトで実行してください。
作業：{ディレクトリ}配下の商品ページHTMLについて、alt属性が空の画像タグに、周辺テキストから推測した日本語のalt文字列を補完する。
条件：
1. ワークツリー分離を有効にすること。gitリポジトリでない場合は実行せず、その旨を報告して停止すること
2. サブエージェントは最大{N}体まで
3. 各サブエージェントは担当ディレクトリ以外のファイルを編集しないこと
4. 商品名・型番・価格に該当する文字列をalt内に生成しないこと（誤記のリスクがあるため）
5. 各サブエージェントは完了時に、変更ファイル数と変更行数を報告すること
すべての子が終了したら、変更内容を統合して差分サマリを出してください。
4本目は、実行後の監査です。ここでイベントログを実際に使います。
プロンプト4：イベントログからの作業証跡の抽出
直前のセッションのイベントログから、監査用の証跡を抽出してください。
抽出項目：
1. 外部への副作用（ファイル書き込み・シェル実行・ネットワーク送信）を時系列で列挙
2. 各副作用について、意図の記録と終端記録の両方が揃っているかを判定
3. 終端記録が欠けている副作用があれば「状態未確定」として先頭に警告表示
4. 承認レビューが発生した箇所と、その判断内容
出力後、redacted オプションつきでログをエクスポートし、出力ファイルのパスとハッシュ値を示してください。
5本目は、CIに組み込む前の安全確認です。muse exec の終了コードは「ターンが完了したか」を示すもので、コードが正しいかどうかは示しません。ここを取り違えると、テストが落ちているのにパイプラインが緑になります。
プロンプト5：CI組み込み前のゲート設計レビュー
以下のCI設定案をレビューしてください。
前提：muse exec でエージェントを走らせ、その結果でデプロイの可否を判定したい。
レビュー観点：
1. エージェントの終了コードだけでゲートしていないか（終了コード0は「ターン完了」であり「コードが正しい」ではない）
2. 独立したテストコマンドでゲートしているか
3. 最大ステップ数の上限に達した場合の扱いが明示されているか
4. フックやMCPサーバーがサンドボックス外で動く前提を理解した設定になっているか
5. 本番の受注データ・在庫データに触れる経路が含まれていないか
問題があれば、修正後の設定案を提示してください。
現場で起きる失敗と、その前に引いておく線
最初の失敗は、承認モードを never にしてしまうことです。ドキュメント上は「サンドボックスだけで封じ込める」設定として存在しますが、これが正当化できるのは使い捨ての環境で、失っても構わない認証情報しか置いていない場合に限られます。yolo オプションに至っては承認とサンドボックスの両方を無効化し、そのワークスペースの指示ファイルを信頼した状態で実行します。外部から取り込んだリポジトリに対してこれを使うと、そのリポジトリに書かれた指示がそのまま無防備なエージェントに渡ります。
2つ目の失敗は、フックとMCPサーバーを「サンドボックスの中で動く」と誤解することです。実際にはどちらもサンドボックスの外で動きます。フックのコマンドはエージェント自身のツールを縛る承認機構の外側で実行され、MCPサーバーは通常の子プロセスかネットワーク接続なのでファイルシステムとネットワークの封じ込めが効きません。承認自体はMCPツール呼び出しにも適用されますが、封じ込めは別問題です。ここはMCPエンタープライズ認可でEC企業が引く境界線で扱った権限設計の考え方と合わせて読んでください。
3つ目は、安価な料金帯の利用規約を読まずに本番データを流すことです。開発者向けの募集要項では、貢献者向けの安価なティアについて「利用が製品改善に使われる可能性がある」という条件が示されています。個人の実験には合理的な取引ですが、秘密保持契約下のクライアント案件では選択肢になりません。商品原価や仕入先が含まれるデータを扱う店舗は、標準ティアを使う前提で費用を見積もってください。
4つ目は、ベンチマーク数値をそのまま信じることです。1.2世代の評価はTerminal-Bench 2.1の89タスク、DeepSWEの113タスク、実際のプルリクエスト由来の社内440タスクという規模で行われたと報じられていますが、スコア自体はチャート画像として公開されており機械可読な数値が読み取れません。加えて、自社ハーネス外では性能が落ちるという利用者報告も出ています。この点は現時点で要確認とし、自社のタスクで実測してから判断するのが妥当です。
費用とKPIをどう見積もるか
課金面では、公開されている2つの参照点があります。開発者向けの発表資料では貢献者ティアが100万入力トークンあたり0.10米ドル、キャッシュ済み0.002米ドル、出力0.20米ドルとされています。一方、モデル配信サービスOpenRouterの掲載では、Muse Spark 1.2が100万入力トークンあたり1.25米ドル、出力4.25米ドル、コンテキスト100万トークンとなっています。約12倍の開きがあるので、どちらの前提で試算しているかを社内で揃えておく必要があります。
見落としやすいのが観測エージェントの費用です。Muse Codeは書き込み権限を持つサブエージェントとは別に、記憶想起、スキル想起、ゴール追跡、検証という4種類のバックグラウンド観測エージェントを走らせます。前者3つは既定で有効、検証は既定で無効です。ここで重要なのは、観測エージェントもそれぞれ独自にモデル呼び出しを行うという点です。1セッションのトークン消費は本流の会話だけではなく、観測分を足した合計になります。試算するときは、本流の見積もりに一定の上乗せを見ておくのが安全です。上乗せ率はタスクの長さで変動するため、最初の1週間は実測値を取ることをおすすめします。
KPIの置き方としては、削減時間より「やり直し率」を見るのが実態に合います。現場感覚では、AIに任せた一括処理の価値は初回の速さではなく、失敗したときに何分で復旧できるかで決まります。イベントログとエクスポートを前提にするなら、復旧までの平均時間、重複した副作用の件数、人手による確認が必要になった件数の3つを月次で追うのが現実的です。工数削減の効果は、この3つが安定してから初めて計測する意味が出てきます。
この設計が業界標準になるまでの見立て
durabilityを製品の主張に据えたのはMetaが最初ですが、この軸自体は模倣が難しくありません。イベントソーシングは新しい発想ではなく、規律の問題です。ドキュメント化され、エクスポート可能で、決定的な形式として最初に出荷したベンダーが形を決め、他社が追随する。おそらく数回のリリースサイクルで、これは差別化要素ではなく前提条件になります。
EC事業者にとって意味があるのは、その先です。自動化の議論が「AIが正しく作業できるか」から「AIの作業を誰がどう証明するか」へ移る局面が来ます。委託先に運用を任せている店舗、複数モールで同一商品を扱っている店舗、そして景表法や薬機法の観点で表現チェックを外注している店舗では、作業証跡そのものが取引条件になり得ます。実行ログのハッシュを納品物に含めるという運用は、いまのところ大げさに見えますが、AIが商品ページを直接書き換える運用が広がれば自然な要求になります。
もう1つの見立ては、ハーネスとモデルの分離が進むかどうかです。現時点では、自社ハーネス外でモデルの性能が落ちるという報告が出ており、これが一般化するならベンダー公開のスコアはモデルの実力よりハーネスの最適化度合いを表していることになります。モデルを差し替えられる前提でパイプラインを組みたい事業者は、その組み合わせを自分で試してから採用を決めるべきです。ツール選定の考え方はAgent Skillsマーケットプレイスの比較と審査観点の枠組みがそのまま応用できます。
EC業務で最初に自動化してよい範囲の線引き
証跡が残る仕組みが手に入っても、任せてよい作業とそうでない作業の線は変わりません。ここを設計せずに導入すると、監査ログだけが積み上がって誰も読まない状態になります。
第1段階として任せてよいのは、読み取りと生成だけで完結し、出力を人が必ず確認する作業です。商品説明文の下書き、レビューの分類、競合ページの要約、問い合わせの要点抽出。これらは失敗しても元に戻すものがないため、証跡の価値は「何を根拠にその文章を作ったか」の説明に限られます。逆に言えば、この段階では証跡の仕組みはほとんど活きません。
第2段階は、自社が管理するファイルへの書き込みです。商品マスタのCSV整形、画像ファイル名の一括変更、社内ドキュメントの更新。ここから証跡が意味を持ち始めます。1,200行のCSVを整形する処理が途中で落ちたとき、どこまで書き換わったかをログから判定できるかどうかで、復旧の手間がまったく変わります。この段階ではgit管理下に置くことが前提条件になります。ワークツリー分離が非gitディレクトリで無言のまま無効化される仕様を踏まえると、商品データをgit管理していない店舗は、まずそこから整える必要があります。
第3段階が、外部への送信を伴う処理です。モールのAPIへの商品情報更新、在庫数の反映、価格の変更。ここが証跡の本命であり、同時に最も慎重に開けるべき領域です。送信は取り消せないため、重複送信と部分送信の両方に備える設計が要ります。イベントログの意図と終端記録の仕組みは、まさにこの領域のために作られています。
第4段階として、受注データや顧客情報を扱う処理があります。ここは証跡があるからといって自動化してよい理由にはなりません。権限設計、アクセス範囲、データの保管場所を先に固め、読み取り専用から始めるのが順序です。MCPサーバーがサンドボックスの外で動く仕様である以上、接続先の設計は自社の責任範囲になります。
現場で繰り返し見るのは、第1段階を飛ばして第3段階から始めようとするケースです。効果が大きく見えるのは確かですが、失敗したときの影響も比例して大きくなります。第1段階で運用の型を作り、第2段階でログの読み方に慣れてから第3段階に進む。この順序を守るだけで、事故の確率は大きく下がります。
証跡を実際に使う場面を先に決めておく
エクスポート機能があること自体は価値ではありません。その証跡を誰がいつ読むのかを決めて初めて、仕組みが運用に乗ります。EC事業者にとって現実的な用途は3つあります。
1つ目は、事故が起きたときの原因究明です。商品ページの価格が意図しない値に変わっていた、在庫数が実態と合わない、といった事象が発生したとき、いつどの処理が何を書き込んだかを時系列で追えます。この用途では、証跡は保険であり、平時には読まれません。それでよいのですが、いざというときに読める形で保管されているかは事前に確認しておく必要があります。
2つ目は、委託先とのやり取りです。EC運用を外部に委託している場合、作業内容の報告は通常テキストの報告書ですが、実行ログのエクスポートを添付すれば、報告と実態のずれが原理的に生じません。委託契約に「作業ログのエクスポートを納品物に含める」と書けるかどうかは、いまのところ交渉次第ですが、AIが直接データを書き換える運用が広がるほど自然な要求になっていきます。
3つ目は、社内での知見の蓄積です。うまくいった処理のログを読むと、どの順番でどんなツールを呼んだかが分かります。これは手順書の材料になります。人が書いた手順書は理想を書きがちですが、実行ログは実際に通った経路を記録しているため、現実的な手順書の下敷きとして質が高くなります。自社の手順書化の進め方はAgent SkillsでEC業務の手順書をAIに覚えさせる記事で扱っている考え方がそのまま応用できます。
保管の設計としては、機微な情報を含む可能性があるため、秘匿化オプションつきのエクスポートを標準とすることをおすすめします。ただし秘匿化は万能ではなく、暗号化された推論の断片は生のままの出力にも秘匿化後の出力にも残ります。社外に渡す前に、この点を確認する工程を挟んでください。
よくある質問
Muse CodeはWindowsで使えますか
いいえ、2026年8月時点で公式に案内されているインストール手順はmacOSとLinux向けのみです。導入はコマンド1行のスクリプト実行で完了します。Windows環境の開発者がいるチームは、WSLやリモート開発環境を前提に検討することになります。
イベントログがあれば、AIが壊した作業を元に戻せますか
いいえ、イベントログは巻き戻しの機能ではなく、記録と再開の機能です。ファイルの取り消しやデータベースの取り消しはスナップショットの領域であり、外部への送信のように取り消せない副作用にはどちらも届きません。イベントログの価値は、その取り消せない副作用について「起きたかどうか」を後から判定できる点にあります。
EC業務の自動化に、いますぐ本番投入すべきですか
いいえ、まずは本番から切り離したブランチでの検証をおすすめします。ベータ版であり、ワークツリー分離が非gitディレクトリで無言のまま無効化される、同時実行数の上限記述がドキュメント間で食い違うといった粗さが残っています。読み取り中心のタスクから始め、書き込みを伴う処理は承認モードを有効にしたまま運用実績を積むのが順当です。
貢献者ティアを本番の商品データに使ってよいですか
いいえ、利用規約上「利用が製品改善に使われる可能性がある」と示されている以上、仕入先や原価を含む商品データには使うべきではありません。自社の公開情報だけを扱う実験なら合理的ですが、クライアント案件や秘密保持契約下のデータは標準ティアを前提にしてください。
Claude CodeやCodex CLIとどう使い分けますか
長時間の自律実行と作業証跡の提出が要るタスクではMuse Codeの設計が噛み合い、日常的な小さい修正やスキル資産の再利用が中心なら既存の環境から動かす必要は薄いというのが現時点の見立てです。Muse Codeはリポジトリ内の .codex/skills や .claude/skills を走査し、既存のスキル資産をインポートする経路も用意しているため、併用しながら比較するのが現実的です。
EC事業者がまず自動化すべき作業はどれですか
読み取りと生成だけで完結する作業、具体的には商品説明文の下書き作成、レビューの分類、競合ページの要約あたりが第一候補です。在庫数の更新や価格変更のように、間違えると売上に直結する書き込み処理は、証跡の運用が固まってから段階的に開けていくのが順序として正しいと判断します。
導入にエンジニアは必要ですか
はい、ターミナルで動かす前提のツールなので、gitの基本操作とコマンドラインの読み書きができる担当者が最低1人は必要です。ただし、社内にエンジニアがいない店舗でも、外部パートナーに実行を任せたうえで、エクスポートされた作業証跡を受け取って確認する側に回るという使い方は成立します。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Meta AI Developers Blog・Meet Muse Spark 1.2 and Muse Code
- Digital Applied・Inside Muse Code: Subagent Fan-Out, Skills, Event Logs
- Layer3 Labs・Muse Code Explained: Meta’s Multi-Agent CLI (2026)
- explainx.ai・Muse Code Beta — Meta’s New Terminal Coding Agent (Aug 2026)
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
