ニュースの概要
Metaが、オープンウェイト（＝学習済みの重みを公開し、手元で動かせる形式）のAIモデル「Muse Spark Open」を公開した。総パラメータ数は8160億だが、一度の処理で実際に働くのは420億にとどまる設計だ。文章だけでなく画像や動画も最初から扱えるマルチモーダル構成で、一度に読める文脈は100万トークンに達する。Metaは用途として、長い資料の読み込み、複雑なプログラミング、自律的に作業を進めるエージェント型タスクを挙げている。さらに、Appleの高性能デスクトップであるMac Studioでの動作を打ち出した点が目を引く。データセンター向けと見られがちだった巨大モデルを、個人や小規模チームの机上へ近づける動きだ。
引用元: Meta、8160億パラメータのオープンウェイト・マルチモーダルモデルを公開（TechCrunch）
分析・見解
8160億のうち420億だけ動かす設計が、Macでの実行を可能にする
総パラメータ数は、いわばAIの頭脳を構成する部品の総数だ。ただし、このモデルは一回の処理でその約5%にあたる420億しか使わない。総数と稼働数を分ける構成は、専門家混合（＝質問に応じて得意な部分だけを呼び出す方式）でよく見られる。中国のDeepSeek-V3が6710億のうち370億、Metaの旧世代Llama 4 Maverickが4000億のうち170億という近い構造をとっていた。
つまり計算の重さは「420億級のモデル」並みで済む。一方で、部品そのものは全部メモリに置く必要がある。仮に4ビット（＝数値を粗く圧縮する方法）に量子化すれば、重みだけで約400GBだ。メモリを最大512GB積めるMac Studio（2025年時点の上位機種）に収まるかどうかは、この計算が分かれ目になる。
100万トークンの文脈は、置けても使い切れるとは限らない
100万トークンは、日本語なら文庫本で数冊から十冊ほどに相当する。契約書の束や大規模なコードを丸ごと読ませられるのは魅力だ。ただし、長い入力ほど途中経過の記憶（＝KVキャッシュ）が膨らみ、メモリを圧迫する。重みだけで400GBを使えば、残りの余裕は小さい。机上のMacでは、実際に使える長さが公称値より短くなる可能性が高い。
さらに、長文の中ほどにある情報を見落とす傾向は、多くのモデルで報告されてきた。100万と書けることと、100万の中から正確に答えを拾えることは別問題だ。
Metaが重みを公開し続けるのは、販売ではなく標準の座を狙うから
Metaはクラウドの推論料金で稼ぐ会社ではない。広告とSNSが本業であり、AIの基盤が自社の流儀に揃うほど、開発者や周辺ツールが集まる。Llamaで築いた「公開モデルの標準」という立場を、Muse Sparkでも維持したい意図が読み取れる。OpenAIのgpt-ossや中国勢のQwen、DeepSeekが公開で攻める中、引けば存在感を失う。
ただしオープンウェイトは、すべてが公開される意味ではない。学習データや訓練手順は非公開が通例で、ライセンスに利用条件が付くこともある。
競争の軸は、最大性能から「どの規模を誰の手元に置くか」へ移る
性能の頂点を競う段階から、実用的な大きさで手元に置けるかを競う段階に入りつつある。クラウドAPIは常に最新だが、料金と通信、データの持ち出しが付きまとう。手元のモデルは性能で一歩譲っても、固定費で使い放題になる。
今後半年で注目すべきは、量子化後の品質低下の度合い、実測の処理速度、そしてAppleや他社が積めるメモリ量の伸びだ。この三つが、手元運用の本格化を左右する。
ビジネスへの影響
機密資料を社外に出せない業務から試す価値がある
法務、医療、設計、金融など、資料を外部サービスに送れない部門では、手元で動く大型モデルの意味が大きい。クラウド型は従量料金が続く。手元型は、機材代を払えば追加利用の費用は電気代程度だ。エージェント型の作業は、一つの依頼で何十回もモデルを呼び出すため、従量課金だと費用が読みにくい。手元運用はこの不確実さを抑えられる。
ただし、上位構成のMac Studioは百万円を超える可能性がある。損益分岐は、利用量を見積もって初めて分かる。
導入前に確かめたい、圧縮後の品質と速度と契約条件
第一に、圧縮後の品質を見る。量子化したモデルで、自社の日本語文書の要約や抽出の精度が保たれるか。第二に、処理速度だ。担当者が待てる応答時間か、夜間の一括処理で足りるか。第三に、ライセンスである。商用利用、再配布、従業員数や売上による制限の有無を原文で確認する。
社内で十件程度の実務サンプルを用意し、クラウドの有料モデルと同じ問いで比べるとよい。一人で使うなら成立しても、複数人で同時に使うと遅くなる点は見落としやすい。
全面移行ではなく、クラウドとの使い分けを設計する
実務では「機密度が高い処理は手元、最新性能が要る処理はクラウド」という分担が現実的だ。中継役を一つ置き、入力内容に応じて振り分ける仕組みを作れば、将来モデルが変わっても入れ替えやすい。特定のモデルに業務を縛らないことが、最大の備えになる。
試験導入は、社内の一チームに限定し、三か月で費用と効果を測るとよい。判断はモデルの話題性ではなく、自社データでの試験結果で下したい。