
このレビューの採点方法
採点対象は7つの観点で、それぞれプレスリリースの要約ではなく一次資料から評価している。ライセンスファイル、価格ページ、実際に出荷されたconfig.json、APIリファレンス、テックブログ自身のベンチマーク表、プラットフォームのFAQ、そしてデプロイの手順だ。実際に使ってみた上での判断を用いる場合は、私の推測ではなく、公開スレッド上で実名が分かっている人物の証言に基づいている。

実際に何が入っているのかを詳しく分解した記事として、LongCat 2.0そのものを扱った別記事も書いている。このレビューは、その上に積み重ねる購入判断の部分だ。
実際に使えるのか?自分のルートを選ぶ
このモデルをレビューして分かった変わった点は、「良いモデルか」と「実際に使えるか」の答えが、どうやってアクセスするかによって変わることだ。ルートは3つあり、それぞれ異なる壁がある。自分に合うものを選んでほしい。
この3番目の選択肢があるからこそ、書面上はこのモデル最大の強みであるMITライセンスも、大半の読者にとってはほとんど意味を持たない。動かせないチェックポイントに付いた純粋なMITライセンスは、眺めて感心するだけのライセンスだ。
実際に得意なこと
このレビュー全体の中で最も有用なデータポイントは、ベンチマークではない。OpenRouter上でowl-alphaというステルスモデルとして公開されていた2ヶ月の間に、36億トークンをこのモデルに流したという1人の開発者の証言だ。
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.
これは優れたエージェント型モデルであり、平凡なチャットモデルであることを的確に表現している。そしてこれは、ローンチ後にトークンパックを購入した人物による、2番目に有用な実体験の証言とも一致する。
As an aside, I also nabbed a 50m token pack for LongCat 2.0 to give it a whirl. 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.
2ヶ月の間隔を空け、異なるアクセスルートを使った2人の独立したユーザーが、同じ結論に達している。天才ではないが、信頼できる実行役だということだ。これはSWE-benchのどんな差よりも価値ある情報であり、ハーネス側が思考を担い、モデルが作業を担うカスタムコーディングエージェントを構築するなら、まさに求めているプロファイルだ。

同じユーザーが指摘していた注意点は触れておく価値がある。これはベンチマーク表の読み方を変えてしまうからだ。LongCat 2.0は推論モデルではない。そのスコアは拡張思考の予算(シンキングバジェット)を使わずに計測されたものだが、比較対象の一部のモデルはそれを使っている。これは双方向に影響する非対称性であり、エージェント型コーディングCLIにおけるベンダー間比較を、マーケティング上のグラフが示すよりも難しくしている。
苦手なこと
反対意見も実在しており、それを隠すつもりはない。実際の運用で使っている人物の声だ。
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.
そして、コードに特化した、もっと率直な意見もある。
I have been trying to use longcat 2 but its bad model, it cant follow orders for example. Its coding is terrible, buggy as hell, stay away. Deepseek is way better.
どちらも投票数の少ないコメントであり、いずれも大量トークンを使った証言と矛盾するため、それに応じて重みを下げて扱う。しかし、これらすべてに共通するパターンは一貫している。このモデルの品質は、それを動かすハーネスに大きく依存するということだ。成功を報告している人たちは、実際のエージェントループの中でこれを動かしていた。失敗を報告している人たちは、大半が直接プロンプトを投げていた。
推論面では、Hacker News上で最も話題になった公開テストで3位という結果だった。
Overall I rate Gemini Flash the best, Qwen 3.7 Plus an acceptable second, and LongCat-2.0. an ok'ish third, if you have nothing better.
ただしこれは慎重に引用したい。というのも、そのテスト自体がスレッド内で3人の別々のコメンターから、質問自体が誘導的だ、あるいは単一の正解が存在しないといった批判を受けているからだ。これは1つのプロンプトであって、評価(eval)ではない。
ローンチ当日に報告された2件の統合上の失敗は、これまでの何よりも実用的な情報だ。あるユーザーは、モデルが<longcat_tool_call>という独自のラッパーを返すために、ハーネスが認識できずツール呼び出しが全く機能しなかった。別のユーザーは、検索を有効にして英語で質問したのに中国語で回答が返ってきたという。どちらも品質の問題ではない。どちらも半日を無駄にするタイプの問題だ。
ベンチマークを正直に読む
MeituanはSWE-bench Pro(Verifiedではなく)の数値を公表しており、Claude Code上で4c8gのサンドボックス、温度(temperature)1.0の設定で自社にて計測し、"problematic tasks corrected"と述べている。以下は各スコアの出典を明記した一覧であり、数点程度の差はノイズとして扱うべきだ。
| モデル | SWE-bench Pro | 実施者 | 補足 |
|---|---|---|---|
| Claude Fable 5 | 80.0 | OpenAIが報告 | Anthropicのページには掲載なし |
| Claude Opus 4.8 | 69.2 | 4社が報告 | このセットの中で最も一致度の高い数値 |
| Qwen3.8-Max | 67.7 | Qwen社内計測 | タスクセットを修正したとも記載 |
| GPT-5.6 Sol | 64.6 | OpenAI社内計測 | なし |
| GPT-5.6 Terra | 63.4 | OpenAI社内計測 | なし |
| GPT-5.6 Luna | 62.7 | OpenAI社内計測 | なし |
| GLM-5.2 | 62.1 | Z.ai、OpenHands、400Kコンテキスト | 専用に調整したプロンプト |
| LongCat 2.0 | 59.5 | Meituan社内計測、Claude Code | 推論モードなし、タスクセット修正済み |
| GPT-5.5 | 59.4 | OpenAI社内計測 | LongCat自身のモデルカードでは58.6と記載 |
| MiniMax-M3 | 59.0 | MiniMax社内計測 | なし |
| DeepSeek-V4-Pro (Max) | 55.4 | DeepSeek社内計測 | LongCatとアーキテクチャ上ほぼ同型 |
| Gemini 3.1 Pro Preview | 54.2 | OpenAIが報告 | なし |
| DeepSeek-V4-Flash (Max) | 52.6 | DeepSeek社内計測 | 284Bモデル |
率直に読めば、59.5というスコアは昨年のGPT-5.5と同水準で、GLM-5.2やGPT-5.6ファミリー全体には数点差で及ばず、Opus 4.8にはおよそ10点差をつけられている。アーキテクチャ上最も近いDeepSeek V4 Proには4点差で勝っており、これこそが本当に意味のある比較だ。
この表には表れていないことが2つある。まず、Meituan自身の比較対象には、オープンウェイトの競合モデルが一つも含まれていない。この点はr/LocalLLaMAですぐに指摘された。
I don't know why they won't line up their benchmark to other Chinese and open models, you know, they have DeepSeekV4Pro, KimiK2.7-Coder, GLM5.2, MiniMaxM3, Qwen3.5-397B, MiMoV2.5-Pro.
これは的を射た指摘だ。自分が勝てるモデルだけを比較対象に選ぶベンダーは、自らどこに立ちたいかを物語っている。そしてMeituanはSWE-bench Verifiedのスコアを一切公表していないため、DeepSeek V4やMiniMaxがVerifiedで報告している79から81の帯との比較は、そもそも行えない。
価格は最も強い項目、ただし注釈付き
| 定価 | プロモ | 変化率 | |
|---|---|---|---|
| 入力(キャッシュなし) | $0.75 / 1M | $0.30 / 1M | -60% |
| キャッシュ読み取り | $0.015 / 1M | $0.006 / 1M | -60% |
| 出力 | $2.95 / 1M | $1.20 / 1M | -59% |
価格ページには、見出しの数字より重要な点が2つある。まず、どの長さでもコンテキスト長による段階的な価格設定が存在しないのは珍しい。Gemini、GPT-5.6、MiniMaxはいずれもある閾値を超えると価格が上がるが、ここでは200Kトークンのリクエストも2Kトークンのリクエストと1トークンあたり同じ価格だ。次に、キャッシュ書き込みの価格がページに記載されていない。これは無料であることを意味しない。
その注釈こそがプロモ自体だ。期間限定と表示されているが、終了日は公表されていない。定価では、書面上は同じ形状のモデル(合計1.6兆パラメータ、アクティブパラメータはおよそ48対49億、MITライセンス)であるDeepSeek V4 Proの0.435ドルと0.87ドルより高くなる。つまりコストの議論全体は、ベンダーがいつでも終了できる割引の上に成り立っている。Reddit上のあるユーザーは、ローンチ前にすでに自分なりのしきい値を設定しており、プロモ価格はそれをクリアしていた。
as long as it stays below .40 input and .80 output it will have a use.
定価ではこの基準をクリアしない点に注意してほしい。また、ローンチ時に広まった「最も安い100万コンテキストモデル」という説明は、DeepSeek V4 Flashが0.14ドルと0.28ドルであるため、スレッド内でほぼ即座に訂正された。トークン単価だけが基準なら、LongCat 2.0は中国のオープンウェイト勢の中でさえ最安ではない。より広い市場では、GPT-5.6の価格やClaude Opus 5の価格のページが上限を示しており、3ドルと15ドルというKimi K3の価格は、オープンウェイトと安いトークンが必ずしも両立しないことを示している。
マーケティングが触れない3つの壁
コンテキストウィンドウは256K、100万ではない
ローンチ時の記事はどれも100万と書いている。しかしHugging Face上で出荷されたconfig.jsonではmax_position_embeddingsが262,144に制限されており、その上限の裏でYaRNが983,040まで用意されているにすぎない。ホスト型APIには別途131,072トークンの出力上限があり、max_tokensはコンテキストの消費分としても数えられる。つまり正直な数字は入力256K、出力128Kであり、100万という数字は学習データについての説明だ。
256Kも十分に大きいため、これは聞こえるほど大きな差ではないが、「モノレポが収まるか、収まらないか」を分ける差でもある。長いコンテキストが実際の要件なら、スペック表ではなくClaude Codeのコンテキストウィンドウが実際にどう振る舞うかと比較してほしい。
ツール連携の仕様が文書化されていない
これは私が最も驚いた評価項目だ。APIリファレンスに公開されているリクエストパラメータはごく一部で、OpenAI形式・Anthropic形式どちらのボディスキーマにもtools配列がない。tool_choiceもparallel_tool_callsもstop_sequencesもmetadataもなく、contentは単純な文字列として文書化されているため、コンテンツブロックも画像もtool_resultもない。temperatureはOpenAIの0から2ではなく0から1の範囲で動くため、他のプロバイダーから移植したリクエストは、何も警告されずに値を切り詰められてしまう。
プラットフォームの「tools」ページは、実際にはツールのカタログではない。APIに接続できるサードパーティ製コーディングクライアント12個の互換性リストにすぎない。サーバー側のウェブ検索も、コードインタープリタも、検索用のストレージも、MCPのインターフェースも、ホスト型のエージェントループもない。エージェント的な部分はすべて設計上クライアント側に委ねられている。これは正当なアーキテクチャであり、形は違うがGPT-5.1-Codex-Maxと同じ「ハーネスは自分で用意する」という賭けだ。しかしそれは、このモデルのエージェント型AIとしての物語が、丸ごとあなたのハーネス側の物語になるということでもある。
論文はなく、リポジトリもほぼ空
GitHub上のmeituan-longcat/LongCat-2.0は、READMEとライセンス、3枚の図があるだけで、容量はおよそ1MB、リリースはゼロだ。重みはHugging Face上にある。技術レポートは存在せず、あるのはブログ記事だけで、つまり新しく採用された2つのアーキテクチャ要素について、公開された手法の説明がない。モデルカードにはmodel_typeが記載されていないため、TransformersのAutoModelはそのままでは失敗する。対応エンジンはSGLangのみで、そのサポート用PRはマージされずにクローズされており、ナイトリービルドのホイールが必要になる。
オープンであることを売りにしているモデルとしては、これは物足りない。それを明確に示す比較材料がHugging Face自体だ。月間3,240ダウンロード、ハブ上の推論プロバイダーはゼロという状況は、実際にデプロイされているモデルの足跡とは言えない。
エンタープライズの購買を止める評価項目
セキュリティ担当者に真っ先に見せたい発見がこれだ。Meituanのプラットフォームのよくある質問は、データの保持期間、プロンプトを使った学習、データの保管地域、SLAについて何も語っていない。「training」という単語自体がどこにも出てこない。
この沈黙は些末な話ではない。これはあらゆる買い手が聞いてくる質問そのものであり、私はほぼすべての商談でこの質問を耳にする。3月に話をしたB2Bハードウェア企業の技術評価担当者は、そのAIが承認済みの知識の外に出ないかどうかについて明確な答えが得られるまで、話を進めようとしなかった。別の買い手は社内のセキュリティレビューによって、カード番号やパスワードを含むチケットデータが自社の環境内に留まることを、書面での保証として求めていた。これらは特殊な要求ではない。これは最低限のラインだ。データ保持について何も触れていないベンダーのページは、ベンチマークのスコアがどうであろうと、その最低ラインをクリアできない。
開発者たちも独立して同じ判断を下していた。ある人物はポリシー上の理由から、無料のステルス期間中このモデルを完全に避けており、後になって自分が何を見逃していたかを知った。
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
OpenRouterを経由する回避策も、問題を解決するわけではなく、リスクを文書化するだけだ。提供元はAtlasCloud一社のみで、ゼロデータ保持のバッジは掲げておらず、そのポリシーには7日間のコンテンツ保持が明記されている。SOC 2やGDPRのレビューを進めていたり、HIPAA準拠のAIの要件に近いところにいるなら、この話はそこで終わる。自前でホストすることだけが、この疑問そのものをなくすルートであり、それはB300を8基揃えるということを意味する。
モデルに対して公平を期すなら、これはMeituanがデータに関して何か悪いことをしているという話ではない。Meituanが何をしているかを公表していないという話だ。個人的なプロジェクトであれば、その違いは重要ではない。だが実際のチケットを扱うカスタマーサービスの自動化パイプラインにおいては、それがすべてを決める判断材料になる。
誰が使うべきか
向いているケース。 自分たちで管理するハーネスの中で、大量のエージェント型コーディングを行う個人開発者や小規模チーム。コストの主眼がトークンにあり、データがセンシティブでない場合だ。文書変換、スクレイピング、コードベースの探索、長時間のリファクタリングなど。指示への忠実さと長コンテキストでの一貫性は本物であり、入力100万トークンあたり0.30ドルという価格の計算は反論しづらい。オープンソースAIエージェントを検討していたり、LLM最適化の作業向けにモデルを選んでいるなら、候補リストに入れる価値がある。
向いていないケース。 ワンショットの推論品質、文書化されたファンクションコールの仕様、本物の100万トークンウィンドウ、カード決済、あるいは書面でのデータ処理に関する回答が必要な人すべて。これは大半のビジネス上の買い手、そして私が取り組んでいるカスタマーサービス向けの最適なAIエージェントのユースケースのすべてに当てはまる。モデルが悪いからではなく、サポートキューにとって生のモデルが購入の単位として間違っているからだ。モデルはこの問題のせいぜい20%を占めるにすぎず、検索、グラウンディング、エスカレーションルール、ガードレール、テストが残りの80%を占める。そしてそのどれもチェックポイントには含まれていない。これはAIサポートを自作するか購入するかで私が到達した結論と同じであり、解決あたりのコストという数字が、思われているよりもトークン価格ではあまり動かない理由でもある。
eeselを試す
こうしたレビューを読むという行為は、実際には別の問いに答えようとする行為だ。このモデルは自分の顧客に間違った答えを返すのか、という問いだ。トークン価格はそれを教えてくれない。AIのハルシネーションは、価格ページの項目には載っていない。
それが私が取り組んでいる課題だ。eeselは、実際の顧客に返信する前に、AIエージェントを自社の過去のチケットに対してシミュレーションする。そうすることで、実際の質問に対して、実際のナレッジベースを背景にしたAIがどんな回答を送っていたはずかを確認できる。すべての返信は記録され、レビュー可能で、取り消し可能だ。どのトピックに触れてよいかも自分で正確に設定できる。既存のヘルプデスクAIのスタックには数分で接続でき、モデル選びはあなたの問題ではなくeeselの問題になる。無料で試せる。

結論
LongCat 2.0が推奨できるのは、たった一つの用途に限られる。自分で動かすハーネスの中で行う、安価で大量のエージェント型コーディングであり、社外に出しても構わないデータを扱う場合だ。プロモ価格ではこのクラスで最もトークン単価の価値が高い選択肢の一つであり、MITライセンスは本物であり、数十億トークンをこのモデルに流した人たちの実体験レポートは、ベンチマークの行が示すよりも好意的だ。
より広く推奨することを妨げているものはすべて、モデリングの問題ではなく、ドキュメントの不足だ。設定ファイルと一致しないコンテキストの数字、一度も公開されていないファンクションコールの仕様、終了日のないプロモ、そして存在しないデータポリシー。Meituanは1週間の文書作成でこの4つすべてを解決できる。それが実現するまでは、これは試す価値のある優れたモデルであり、本番環境に投入するのは難しいモデルだ。
本当の目的がコーディングエージェントではなくサポートキュー向けのAIであるなら、代わりにカスタマーサポート向けの最適なLLMから始め、モデルは最初に選ぶものではなく、最後に選ぶものとして扱ってほしい。
Frequently Asked Questions
LongCat 2.0は実際に使えるモデルですか?
このLongCat 2.0レビューは価格についてどう結論づけていますか?
LongCat 2.0は本当に100万トークンのコンテキストウィンドウを持っていますか?
config.jsonではmax_position_embeddingsが262,144に制限されているため、実際に提供されるコンテキストウィンドウは256Kです。100万という数字は学習データについての説明にすぎません。出力は別途131,072トークンに制限されています。LongCat 2.0はKimi K3やQwen3.8-Maxと比べてどうですか?
LongCat 2.0をローカルで実行できますか?
LongCat 2.0はカスタマーサポート用途に使っても安全ですか?
サポートチーム向けのLongCat 2.0の代替として最適なものは何ですか?
LongCat 2.0はツール呼び出しやMCPに対応していますか?
tools配列はなく、MCPのインターフェースもありません。ローンチ当日のユーザーからは、独自仕様の<longcat_tool_call>ラッパーが自分のハーネスで解析できなかったという報告もありました。クライアント経由でのツール利用自体は可能ですが、それは文書化された仕様ではありません。
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.








