LongCat 2.0とは:Meituanの1.6Tオープンウェイトモデルを徹底解剖

LongCat 2.0の実像

Meituanは中国のフードデリバリー・ローカルサービスの大手企業で、LongCatはその社内モデルチームだ。LongCat 2.0はLongCat-Flashラインの後継として2026年6月30日に登場し、Meituanはその1か月前に6つのFlashモデルを退役させて場所を空けていた。

モデルカードによれば、アーキテクチャは1.6兆パラメータのmixture of expertsで、トークンあたり約480億パラメータが活性化する。LongCat-Flash-Liteから継承した1350億のN-gram埋め込みパラメータも搭載しており、Meituanはこれを、MoEのルーティングとは直交するスパースな次元に沿って容量を拡張するものだと説明している。事前学習は35兆超のトークンにわたって「数百万アクセラレータ日」規模で行われ、ロールバックや回復不能な損失スパイクは一度もなかったという。

アーキテクチャ面での目玉はLongCat Sparse Attentionで、MeituanはこれをDeepSeek V3.2で使われているLightning Indexerにある2つの明示的な問題への対処だと位置づけている。出力の不連続性と、二次関数的なスコアリングのボトルネックだ。仕組みは3つの要素からなる。Streaming-aware Indexingは連続したメモリ読み出しに合わせてトークン選択の予算を再構成する。Cross-Layer Indexingは隣接する2つの層で1回のインデックス処理を再利用する。Hierarchical Indexingは細かいトークン選択の前に粗いブロック単位の再取得を行う。

3つ目のHierarchical Indexingについては注釈が必要だ。以前のデプロイ用ドキュメントには「簡略化のためサポートしていない」と書かれていたが、コミット5ced4dbはその一文を、具体的な起動手順を記した他の41行とともに、修正するのではなく削除した。一方で発表記事は別途、この機能は「一部の超長文コンテキストタスクで有効になっている」と述べており、すべてのリクエストで有効というわけではない。

私はここ数年、eeselでインテグレーションやAPIの接続部分を作り続けてきたので、こういう発表があるとまず発表文を読み飛ばして、いきなりファイルそのものを見に行くのが習慣になっている。今回はその習慣で4つの主張が持ちこたえられなかった。

100万トークンのコンテキストウィンドウは、設定上は256K

Meituanは公式READMEでネイティブ100万トークンのウィンドウを宣伝しており、変更履歴も同じことを繰り返している。しかし公開されたconfig.jsonではmax_position_embeddingsが262,144に設定されている。YaRNはこの上限の先、983,040まで用意されているため、100万という数字は公開された設定が実際に提供する内容ではなく、モデルが学習された規模を表していると考えられる。

Meituan自身のホスト型APIには、もう一つの上限がある。出力トークンの最大値は128Kで、max_tokensはコンテキストウィンドウに対して消費される扱いだ。これはスキャンダルというほどのものではなく、どの尺度で見ても256Kは大きなウィンドウだ。ただ、マーケティングで謳われている数字とは違う。

GitHubリポジトリの実態はREADMEのみ

github.com/meituan-longcat/LongCat-2.0にはREADME.md、LICENSE、3枚の画像が入ったfigures/フォルダしかない。それがリポジトリの全体で、サイズは約1MB、言語は検出されず、タグやリリースもゼロだ。ウェイトはHugging Face上にあり、推論はSGLangで行われ、評価用ハーネスや参照実装はどこにも存在しない。

論文もない。Meituanは発表用のブログ記事を公開しただけで、それ以上は何もなく、コミュニティはすぐにそれに気づいた。

"The description of LSA and N-Gram in that blog is imo quite surface-level. Thats why i was asking whether there is/will be a full paper."

Data-vanOrtus, Hugging Face

このスレッドは7月5日から開いたままで、meituan-longcatの誰からも返信がない。姉妹モデルであるLongCat-Flash-Omniのリリースには実際に論文が付いていたので、これは能力上の限界ではなく選択の結果だ。

まともに動くTransformersの経路がない

公開されたconfig.jsonにはmodel_typeキーがなく、そのためAutoConfigとAutoModelForCausalLMはどちらも失敗する。手に入るのはトークナイザーだけで、それ以外は何もない。これは未解決のissue #4として報告されており、確認した時点でも未解決だった。

SGLangが唯一サポートされているエンジンだが、それすら扱いが荒い。cookbookの記事ではnightlyビルドのwheelをインストールするよう指示されており、その理由はSGLangのPRがマージされずにクローズされたからだ。vLLM向けの経路もTensorRT-LLM向けの経路もない。

ハードウェアの話を、Meituan自身の言葉と照らし合わせる

これは発表の中で最も広く伝わった部分であり、報道と一次資料の食い違いが最も大きい部分でもある。

チップの枚数自体は本物だ。Meituanは発表記事の中で明確にそう書いている。

"LongCat-2.0 is pre-trained on over 50K AI ASICs, introducing significant system-level challenges due to both model and cluster scale. We address these challenges through systematic optimizations, achieving over 35% training throughput improvement while also enhancing reliability compared to a naive implementation."

Meituan's launch post

その記事に書かれていないのは、その後で語り直された話の残りの部分だ。「国内(domestic)」「中国(China)」「Chinese」という言葉は一度も出てこない。チップベンダーの名前は、Huawei、Cambricon、Hygonのいずれも挙がっておらず、社内製の型番も出てこない。Meituan自身の表現は「代替のハードウェアプラットフォーム」だ。Nvidiaという名前はちょうど2回登場するが、いずれも否定ではなく参照点としてだ。一度は「成熟したNvidia GPUのエコシステムと比べると、対応するソフトウェアコミュニティはまだ発展が進んでいない」という文脈で、もう一度は「われわれのアクセラレータはH800(80GB)よりデバイスあたりのメモリがかなり少ない」という文脈でだ。

Nvidia以外のハードウェアだと読むのは自然な解釈ではある。ただ、それはあくまで解釈にすぎない。Hacker Newsのスレッドで議論の起点になったAscend 910Cという特定は、Meituan自身ではなく、あるコメント投稿者によるものだ。

"This is the real news story. It looks like they may have used Huawei Ascend 910C chips"

gardnr, Hacker News

このスレッドは281ポイント、88コメントまで伸び、その中で最も鋭い反論は真偽ではなく規模についてのものだ。

"1024 Huawei Ascend superpods = 50K 910C chips.

That is a tiny tiny system. OpenAI uses milions of GPUs for training"

throwa356262, Hacker News

Meituan自身の数字にも、もう一つ引っかかる点がある。ある一文には「5万枚超のAI ASIC」とあり、別の節には「数万個のAI ASICスーパーポッド」とあり、記事はスーパーポッドを「最大48台のマシン」と定義している。両方が文字通り正しいということはあり得ない。数字を引用するなら、事前学習について述べた一文、つまり正確な方を引用すべきだ。

Owl Alphaとして過ごした2か月間

発表される前、LongCat 2.0はowl-alphaという無料のステルスモデルとしてOpenRouter上で静かにトラフィックを処理していた。おおよそ2026年4月末から始まり、Meituanが発表記事を公開した6月30日に取り下げられている。Meituanはこれを一度も公表しておらず、モデルカードにも発表記事にもOwl Alphaへの言及は一切ない。

それでもコミュニティは正体を突き止め、その証拠は今もRedditに残っている。最初の手がかりは地政学的なものだった。元のステルスモデルのスレッドで最も評価されたコメントがこれだ。

I think I can confirm Chinese model, it affirmed that Taiwan is part of China.

u/starbugstone, Reddit

その後、誰かが両方のエンドポイントを並べて試した。

I am ABSOLUTELY certain it's Longcat. I tried both the Longcat 2.0 preview via the Longcat API and the Owl Alfa via Openrouter.

It has the same 10-second response time, the same dialogue, and both has 1M of context

u/Pink_da_Web, Reddit

Meituan自身のドキュメントの中に、この裏付けとなる小さな痕跡が一つ隠れていて、私はこの文書一式の中でこれが一番気に入っている。APIリファレンスページに載っている公式のreasoning_contentの例では、モデルが自分自身を「OWL」と呼んでいる。誰も片付け忘れたシステムプロンプトの名残だ。

このステルス運用のことを取り上げるのは、それによってレビューの読み方が変わるからだ。このモデルについて多くの人が実際に触った経験は、何を試しているのか誰も知らない状態で、実験用のハーネス上で無料で積み上げられたものだ。ユーザーからのフィードバックとしてはかなり珍しく素性の良いものであり、以下で紹介する感想が発表初日の印象ではないことを意味している。

ベンチマークが語っていること、語っていないこと

Meituanは6つの比較対象モデルに対して10行分のベンチマークを公開している。ただし、そのカード自体にも注記がある。アスタリスクの付いていないスコアはすべて自社内で測定したもので、競合モデルのスコアの大半は各ベンダー自身の報告からそのまま引用したものだ。つまり、これは一つの統一された条件下での実験結果ではない。

列を縦に読んでいくと、傾向ははっきりしている。LongCat 2.0はコードエージェント関連の3行すべてでGemini 3.1 Proを上回り、SWE-bench Proでは0.9点差でGPT-5.5もわずかに上回る。一方で、Claude Opus 4.8がスコアを出している行すべてで4.8に負けている。SWE-bench Proでは9.7点差、Terminal-Bench 2.1では8.1点差だ。私の見立てはこうだ。これは前世代には勝つが現行世代には勝てない、本物のフロンティア級に近いコーディングモデルだということだ。

この表を引用する前に、フラグを立てておくべき点が2つある。Meituanは「問題のあるタスクを修正した」状態でSWE-benchを実行したと述べており、RWSearchは「社内の独自ベンチマーク」と説明されているため、10行のうち2行は部分的にMeituan自身の測定器によるものだ。そして比較対象には、オープンウェイトの競合が一つも含まれていない。DeepSeekも、Qwen3.8 Maxも、Kimi K3も、GLM-5.2も入っていない。これらこそ、オープンウェイトを選ぶチームが実際に比較検討している相手だ。

もう一つ、ここで訂正しておきたいことがある。広く流通している話なので触れておく。AnthropicはClaude Opus 5やSonnet 5についてSWE-benchのスコアを公表していない。69.2という数字はOpus 4.8のものだ。もしOpus 5に69.2という数字が結び付けられているのを見たら、それは誤りだ。

実際に使ってみた人たちの声

評価は大きく分かれており、これは少数の不満を伴う大勢一致の勝利ではなく、本当に意見が対立している状態だと正直に言っておきたい。おおまかな傾向としては、ハーネスの中でエージェントとして動かした人は好意的に評価し、頭の良いモデルとして評価した人は低く評価する、という構図だが、この傾向はきれいには成立していない。少なくとも一人、コード専用に使っていた開発者は「バグが多い、避けたほうがいい」と評している。

これまでで一番内容の濃いレポートは、無料のステルス期間中にこのモデルへ36億トークンを流し込んだという人物のものだ。

I used this for over 3.6 billion tokens when it was owl-alpha on Openrouter (with Hermes Agent). It was a very good experience.

It's not as 'smart' as other frontier models when it comes to benchmark style tests (one shots, riddles, etc) but it was very good at (1) following instructions, (2) making a plan, (3) following that plan, and (4) staying coherent at very high contexts. I built a number of apps from start to finish and it performed very well.

u/AnticitizenPrime, Reddit

発表後にトークンパックを購入した人も、同じような結論に達している。

"Not free, but it's so cheap they're basically giving it away. Very impressed too... Not frontier-level intelligence, but a dependable workhorse that can navigate a codebase well and can reliably execute what you tell it to do."

nmfisher, Hacker News

そして最も鋭い異論は、実際に本番環境で使っている人物から、この発表が作り出した枠組みに真っ向から反発する形で出ている。

I was using Owl Alpha a lot for my project. Thats not gpt 5.5 level model. it not even close to flash 2.5 model - its not gollowing promts.

u/Seatext_com, Reddit

全体を通した私の見立てはこうだ。「頼れる作業馬」というのが誠実な評価で、これはベンチマーク表とも、何十億トークンも使い込んだ人たちの声とも一致している。指示に従う能力と長いコンテキストでの一貫性は繰り返し強みとして挙がる。純粋な推論力についてはそうした声はなく、コード品質は決着がついていない論点のままだ。

もう一つ拾っておきたい反応がある。私がずっと引っかかっている点をわざわざ価格に結び付けているのを見たのは、これが唯一だったからだ。

Wait, this is Owl Alpha? Now I wish I had tried it when it was available. I stayed away from it back then because of their privacy policy

u/cultoftheilluminati, Reddit

これはポリシーを読んで判断を下し、その結果、まともなモデルへの2か月分の無料アクセスを失った開発者だ。その判断が正しかったかどうかは、当時何を投げ込むつもりだったかに完全に依存する。

料金:実際の一覧表

Meituanは定価と発売時割引の両方を公開している。割引欄には「期間限定」と書かれているが、終了日はどこにも記載がなく、中国語版のページではこれをプラットフォームの初回リリースに向けたローンチオファーと呼んでいる。両方の通貨はFX換算ではなく、それぞれ別々に設定された価格だ。

この表の中には、見出しの数字よりも興味深い点が2つある。

まず、コンテキスト長による段階課金が一切ない。私が確認した他の100万トークンウィンドウのモデルはすべて、ある閾値を超えると値段が上がる。Gemini 3.1 Proの料金は200Kを超えると倍になり、GPT-5.6 Solは272Kを超えると倍になり、MiniMax-M3は512Kを超えると倍になる。LongCat 2.0はフラットレートで、これは長いコンテキストを使う作業にとって不釣り合いに安くなることを意味する。この料金ページの中で、いちばん報道されていない事実がこれだ。

フラットな価格設定が解決しないことにも触れておく価値がある。同じ答えに至るのにより多くのトークンを必要とするモデルは、単価が安くても実質的には安くない。これはあらゆる見出し比較に潜む罠だ。GPT-5.6の料金を検討していたときに私自身も同じ落とし穴に引っかかった。この落とし穴はGemini 3.6 Flashの料金にも、そしてこのモデルにも同じくらい強く当てはまる。

そしてキャッシュされた読み取りは、キャッシュされていない入力の50分の1のコストで、これはレスポンスの本体を見るまでは魅力的に見える。OpenAI互換パスにはprompt_tokens_details.cached_tokensフィールドがなく、Anthropic互換パスにもcache_read_input_tokensがなく、cache_controlパラメータで制御する手段もない。キャッシュは完全に暗黙的に処理され、実際に何に対して課金されたのかを検証することができない。

Meituanの免責事項はそのまま引用しておく価値がある。「価格は変更される場合があります。LongCat APIプラットフォームに表示される価格およびお客様の請求記録が正式なものとなります。」

実際にどう比較になるか

ここからは、プロモ価格が仕事の大半を担う部分だ。自分の数字を入力してみてほしい。

数字をしばらく動かしてみると、その構図がはっきり見えてくる。プロモ価格ではLongCat 2.0はOpus 5のおよそ20分の1、Sonnet 5の料金のおよそ5分の1で、これが発表日に誰もが比較していた対象だ。

次にキャッシュのスライダーを上げていくと、キャッシュヒット率がおよそ80%を超えたところで、プロモ価格のLongCat 2.0をDeepSeek V4 Proが逆転する。理由は、DeepSeekのキャッシュ読み取りが0.003625ドルで、LongCatの0.006ドルより安いからだ。キャッシュされていない入力が安いことと、本番環境で安いことは同じではないし、リポジトリ規模のエージェント作業はまさにキャッシュヒット率が高くなりやすいワークロードだ。

定価で見ると構図は逆転する。入力0.75ドル、出力2.95ドルは、DeepSeek V4 Proの0.435ドルと0.87ドルよりも高く、しかもDeepSeek V4 ProはLongCat 2.0のアーキテクチャ上いちばん近い双子だ。総パラメータ1.6兆、アクティブ490億、コンテキスト100万、そしてMITライセンスという点まで共通している。入力コストではGPT-5.6 Lunaの0.20ドルにも負けており、これはクレジットカードで支払えるホスト型のプロプライエタリモデルだ。つまりプロモ価格こそが価格ストーリーのすべてであり、そのプロモには終了日が公開されていない。

見出しの数字が隠しているもう一つのコスト倍率がある。reasoningはデフォルトで有効になっており、reasoningトークンは出力レートで課金される。OpenRouter自身の使用状況パネルでは、このモデルで発生した216万の完了トークンのうち203万がreasoningトークンだった。出力に払っている金額のおよそ94%は、返ってくる答えそのものではなく、モデルが「考えている」部分に対する支払いだ。これはreasoningモデルとしては普通のことだが、それでも請求書で発見するのではなく、事前に予算に入れておきたい数字だ。Opus 5とSonnet 5を比較する作業を一度でも通した人なら、これがタスクあたりのコストをどれだけ動かすか、すでに実感しているはずだ。

実際にあなたを止めるであろう部分

Meituanが文書化している決済手段は正確に2つで、いずれも返金ルールの中にしか登場しない。WeChatとAlipayだ。カードもPayPalも銀行振込もない。セルフサービスでの請求書発行は「中国本土のユーザーのみ」利用可能で、それ以外の全員はメールでチームに連絡する必要がある。

登録自体はオープンで、中国本土以外のユーザーもメールアドレスでサインアップできる。しかしアカウントに資金を入れる方法は別問題で、残高がゼロになるとAPIはリクエストを拒否する。プリペイド方式の代替であるToken Packsは、北京時間の10:00、16:00、21:00、23:00に在庫限定のフラッシュセールとして販売され、30日間で失効する。

したがって、中国国外のほとんどのチームにとって現実的な選択肢はOpenRouterであり、これがこのモデルの公開トラフィックがMeituan自身のプラットフォームよりもコーディング用ハーネス経由に流れている理由の一つだ。そこのトレードオフについては、もう少し後で触れる。

API:パラメータは7つ、ツールはなし

私はこのAPIドキュメントを、実際に本番に組み込む前に読むのと同じ姿勢で読んだ。この節は、ベンチマーク寄りの意見がエンジニアリング寄りの意見に切り替わる場所だ。

用意されている面は2つ。OpenAI互換パスとAnthropic Messages互換パスで、どちらもapi.longcat.chat上にあり、同じベアラーキーを受け付ける。どちらのSDKでもベースURLを書き換えるだけの一行変更で済み、これはこのプラットフォームでいちばん気に入っている点だ。OpenAI、Anthropic、GeminiのAPIを比較したことがある人なら、これがどれだけ珍しいことか分かるはずだ。

そこから先は途端に薄くなる。サポートされているパラメータは合計7つだけで、max_tokens、temperature、top_p、stream、tools、tool_choice、thinkingだ。stopシーケンスはない。seedもない。response_formatもJSONモードもない。logprobsもなく、nもなく、ペナルティ系のパラメータもなく、top_kもない。temperatureはOpenAIの0〜2ではなく0〜1の範囲で動くため、そのまま移植した設定が知らないうちに範囲外になることがある。thinkingは有効・無効の二択で、予算指定もeffortレベルの指定もない。

toolsとtool_choiceはパラメータ一覧に載っているが、どこにも文書化されていない。スキーマもなく、ツール呼び出しのレスポンス形式もなく、例もない。それにもかかわらず、変更履歴ではネイティブなツール呼び出しが宣伝されている。発表当日、その空白はまさに予想通りの場所で表面化した。

"I can't get any tool calls working. Seems to use a <longcat_tool_call> wrapper which the current harnesses I'm using don't support"

james2doyle, Hacker News

モデルカードは、これに関連するもう一つの破綻を認めている。LongCatはツール呼び出しのargumentsを、OpenAIのスキーマが規定するJSON文字列ではなく、辞書型として期待する。標準の形式に沿って書かれたものは、そのままでは動かず、変換用のシムが必要になる。

両方の互換レイヤーも、厳格なパーサーを壊すような形で微妙に形が違う。reasoningはOpenAI側ではmessage.reasoning_contentとして届くが、これはOpenAIのフィールドではなくDeepSeekのフィールドだ。Anthropic側では、正式なthinkingブロックとしてではなく、テキストコンテンツブロック内のthinkingキーとして届き、文書化されているSSEストリームにはcontent_block_start、content_block_stop、pingが含まれていない。

ホスト型のツールは一切ない。ウェブ検索も、コードインタプリタも、検索用のストアも、ファイル用のエンドポイントも、embeddingsも、バッチAPIもない。MCPについては一言も触れられておらず、サーバー側のエージェントループも存在しないため、エージェント型の振る舞いはあくまでモデルについての主張であり、それを実際に動かすのは完全にあなたのハーネス側の仕事になる。

Meituanが文書化しているのはクライアント側の連携だ。Claude Code、Codex、Cline、Kilo Code、OpenCode、Cherry Studioなど12件について、それぞれベースURLの書き換え方法が具体的に示されている。CursorとRooはそのリストに入っていない。すでにエージェント型コーディングCLIを日常的に使っているなら、これが最も抵抗の少ない導入路であり、実際このモデルの本当のトラフィックもそこに流れている。

レート制限は存在するが、数値は公開されていない。どこかに明記された唯一の具体的な数字は、429レスポンスの本体にあるretry_after: 60だけだ。失敗したリクエストには課金されないのはうれしい配慮で、従量課金の残高に有効期限はない。

この文書一式の中で私が一番気に入っている細部は小さなものだ。公式のreasoning_contentの例では、モデルが自分自身を「OWL」と呼んでいて、これは別のシステムプロンプトの名残だ。ドキュメントは慌てて書いた人間の手によるもので、それがそのまま出てしまっている。

セルフホスティング:立ちはだかる壁

フロンティア級のモデルにMITライセンスのウェイトが付くのは本当にありがたいことだが、それには誰がその恩恵を受けられるかを決めてしまうハードウェアの請求書が付いてくる。

Hugging FaceのblobAPIによれば、BF16版は194個のsafetensorsシャードにわたって3.55TBある。FP8版は141個にわたって2.05TBだ。SGLangのすべてのレシピはFP8を読み込む前提なので、3.55TBのマスターは提供用ではなく量子化の元データという位置づけであり、BF16には公開されたトポロジーが一切ない。

8基のB300による構成だけがSGLangで検証済みとされている行で、その計算をたどると192GBのB200がなぜ2ノード必要になるのかが分かる。2.05TBのFP8ウェイトは8×192GBには収まらない。H20のレシピはさらに奇妙で、16×96GBは1,536GBにしかならず、2,051GBのウェイトに対して不足する。これはN-gramテーブルとMTPモジュールがHBMの外に置かれている場合にしか成立せず、それを明記したドキュメントはどこにもない。

さらにKVキャッシュの問題がある。トークンあたり43,776バイト、8基のB300で--mem-fraction-static 0.92という設定の場合、ウェイトを載せた後に残るKV用の余裕はおよそ69GBだ。これは256Kのフルウィンドウで同時に処理できるシーケンスがおよそ6本、あるいは平均24Kトークンのスロットが64個に相当する。コンテキストウィンドウと同時実行数は同じメモリを奪い合っているのであり、コンテキストが100万トークンの場合、64スロット分だけでKVに2,802GBが必要になり、これは2,304GBというプール全体を上回ってしまう。

コンシューマー向けのランタイムは完全に不可だ。llama.cppにはLongCatへのサポートがマージされておらず、どのバリアントにもGGUFが存在しないため、OllamaやLM Studioでは読み込めない。存在するコミュニティ製の量子化版もMLX専用で、まだマージされていないmlx-lmのPRが必要な上、最小のフルエキスパート版でも512GBあり、これは512GBのMacをそのまま超えてしまう。Hugging Faceのディスカッションタブは、基本的にひたすら同じ要望が続くだけの状態だ。

"GGUF Version please!!!"

cimilarkes, Hugging Face

r/LocalLLaMAのほうが反応は速く、ウェイト公開スレッドのトップコメントがいちばん的確にまとめている。

Damn, that's a really long Cat!

3.55 TB in all its BF16 glory. 2.05 TB in FP8.

u/bonobomaster, Reddit

同じスレッドにある、もう少し冷静な言い換えがこうだ。オープンウェイトであることと、実際にアクセスできることは同じではない。4090や5090、あるいは96GBのRTX PRO 6000を持っている人にとって、このリリースは動かすものではなく読み物として消費するものだ。とはいえ、それが可能にするのはエコシステム側の作業、つまり検証、蒸留、コミュニティによる量子化版、そしていずれ普通のハードウェアでも実際に読み込めるLite版や蒸留版の派生モデルだ。

ダウンロード数もそれを裏付けている。直近1か月で3,240件、Hugging Face上で推論プロバイダーはゼロ、「Ask for provider support」をクリックした人は24人だ。1か月間コーディングモデルの話題を独占していたモデルとしては小さい数字であり、参入のハードルが8基のB300ノードであることを考えれば、まさに予想通りの数字でもある。ウェイトが無料であることは、推論も無料であることを意味しない。その点でHugging Faceの料金は、実際の費用がどこに落ち着くのかを確認する上で役に立つ現実チェックになる。

データがどこへ行くのか、それが本当の判断材料

もし私がリポジトリではなくサポートを運営する立場だったら、まずここを読むはずだ。そして、報告できることがあまりに少ないので、この節はいちばん短い。

MeituanのプラットフォームFAQは、データの保持期間について触れていない。プロンプトや生成結果が学習に使われるかどうかについても触れていない。「training(学習)」という単語はページ上に一度も出てこない。サーバーの設置国も記載されておらず、地理に関連する唯一の記述は、レイテンシーの見出しの下にある「サーバーの負荷と地理的な位置」という一文だけだ。SLAもなく、稼働率の数字もなく、サービスクレジットもなく、メールアドレス以外にエンタープライズ向けやプライベートデプロイへの道も示されていない。

だからといって何か悪いことが起きているというわけではない。ただ、質問への答えがないだけであり、セキュリティレビューにおいては「答えがない」こと自体が一つの答えになる。

OpenRouterを経由しても、この問題が完全に解決するわけではない。このモデルを提供しているプロバイダーはAtlasCloud一社だけで、「学習に使用しない」というバッジは付いているものの、ゼロデータリテンションのバッジは付いていない。一方、同じディレクトリページ上のNovitaAI、Tencent Cloud、FireworksにはいずれもZDRのバッジが付いている。AtlasCloud自身のポリシーでは、プロンプトや生成結果、APIペイロードを含む顧客コンテンツを最長7日間保持するとされており、ZDRは別途エンタープライズ向けの追加条項の中に置かれている。プロバイダーが一社しかない状態では、ZDRを条件に絞ったリクエストには行き場がない。

これが商業的にどれほど重要かについて、私は推測するまでもない。それはeeselの商談の中で毎週目にしていることだからだ。厳格な社内セキュリティレビューによって足止めされていたデンマークのB2Bテレマティクス企業の担当者は、カード番号やパスワードを含むチケットデータが自社の環境の外に出ないという保証がない限り、トライアルさえ始めようとしなかった。週に約1,000件のチケットを処理しているメディア企業では、クレジットカードやPII情報の削除が評価全体の中で最大の懸念事項となり、精度よりも価格よりも優先された。そうした場で私が伝える答えは具体的だ。顧客データがモデルの学習に使われることはなく、基盤となるモデルプロバイダーが不正利用の監視のために保持するデータは最長30日間であり、データはアカウントごとに分離されている。「学習」という言葉が一度も出てこないページについて、この答えを口にすることはできない。

これはLongCat 2.0をコーディングモデルとして貶める話ではない。自分自身のリポジトリに向けるモデルと、他人の個人情報に向けるモデルとの違いの話だ。同じ関門は、私が見てきたあらゆるヘルプデスクAIの評価にも登場する。顧客のカード番号がプロンプトに含まれた状態での誤答は、あるコードパスについての誤答よりもたちの悪い種類のハルシネーションだ。

実際に使うべき人は誰か

もしあなたが自分でコントロールできるハーネスの中で、大量かつ長いコンテキストのコーディング作業をしていて、OpenRouterを通じて支払いができ、投げ込むコードが機密性の高いものではないのなら、LongCat 2.0は手を伸ばす価値がある。入力100万トークンまでフラットな価格設定は、リポジトリ規模のプロンプトにとって本物の優位性であり、MITライセンスには利用範囲の制限やユーザー数の上限もなく、「頼れる作業馬」という評価も、実際に人々が報告している内容にほぼ合っている。

一方で、JSONモードやstopシーケンス、文書化されたツール呼び出しの契約が必要な場合、8基のB300ノード未満でセルフホストする予定だった場合、あるいはデータ処理に関する質問票が購入プロセスの一部になっている場合は避けたほうがいい。オープンウェイトそのものを重視するなら、より低い定価で比較になるのはDeepSeek V4 Proで、GLM-5.2もMITライセンスだ。オープンウェイトにはこだわらず、単に安いトークンが欲しいなら、GPT-5.6 Lunaのほうが入力コストは安く、クレジットカードで決済もできる。踏み切る前に、この価格帯では見出しの料率と実際の請求額がどれだけ違ってくるかを知っておく価値があり、DeepSeek FlashとK3がタスク単位のコストでどう決着しているかを読んでおくといい。

そして、もしAIに顧客チケットへの対応をさせたいという理由でモデルを選んでいるのなら、私はそもそもモデルという層で買い物をしているのが間違いだと言いたい。それについては節を分けて話す価値がある。

Try eesel

トークンの価格を比較しながらここに来たのが、AIにサポートキューを任せたいという理由からなら、私が伝えたいのは、モデル選びはそのプロジェクトの中でいちばん簡単な、全体の5%程度の部分だということだ。難しいのは、AIが顧客に何を言うのかを、言ってしまう前に把握することであり、その後で自社のセキュリティチームにきちんと説明できることだ。

eeselは、すでに運用しているヘルプデスク、Zendesk、Freshdesk、Gorgias、Front、Help Scout、Salesforceに接続するAIチームメイトで、新しいナレッジベースを一から作る必要はなく、既存のチケットとヘルプセンターから学習する。モデルレイヤーはこちらで管理するので、発表記事が終了日未定の60%オフを謳うたびに、サポートスタックの料金設計をやり直す必要はない。何かを本番投入する前に、実際の過去チケットに対してエージェントをシミュレーションし、それが送っていたであろう回答を確認できる。これは、自信満々に見えるボットが静かに間違いを犯すのを見てきたうえで、私たちが作ったステップだ。そしてLongCatのFAQが答えないまま残している問いについても、こちらには具体的な答えがある。あなたのデータはモデルの学習に使われず、アカウントごとに分離されている。

ヘルプデスクを接続すれば、数分で最初の返信案が作られるところを見ることができ、タスク単位のeeselの料金によるセルフサーブプランにはシート課金もない。その前に全体像を確認したいなら、サポート向けに最適なLLMについての記事でトレードオフを扱っており、自社構築か購入かの記事では、GPUのコストまで含めて自前のスタックを運用するとどれだけかかるのか、実際の数字を示している。eeselを無料で試す、あるいはデモを予約して、いちばん手強いチケットを持ってきてほしい。