Manusの基座模型って結局どこ製？ClaudeとQwenの裏側まで一気にわかる話

Manusの基座模型を調べている人がまず知りたいのは、「Manusは自社で大きなAIモデルを作っているのか」「ClaudeやQwenを使っているだけなのか」「それでもなぜ話題になったのか」という点だと思います。結論からいうと、公開情報や関係者発言ベースでは、ManusはClaude Sonnet系モデルと、アリババ系Qwenの微調整モデルを組み合わせて使っていると見られています。

ただし、Manusの本質は「どの基座模型を使っているか」だけでは説明しきれません。むしろ重要なのは、ClaudeやQwenなどの基礎モデルを、サンドボックス、ブラウザ操作、ツール呼び出し、todo.md、文脈管理によってどう動かしているかです。この記事では、Manusの基座模型、技術構造、套壳論争、OpenAI Agentとの違い、そして今後の見方まで、調査情報をもとに整理します。

この記事のポイント
✅ Manusの基座模型はClaudeとQwen系微調整モデルの組み合わせと見られる
✅ Manusの強みは基礎モデルそのものより、文脈設計とツール実行の工程管理にある
✅ 「套壳」と言われる理由はあるが、単なる皮かぶせでは説明しきれない
✅ AI Agentを見るときは、モデル名だけでなく成功率・速度・コスト・安全性を見るべき

manusの基座模型をめぐる正体と技術構造

1. Manusの基座模型はClaudeとQwen系モデルの組み合わせと見るのが自然
2. 「manus 基 座 模型」で知りたい核心は自社モデルか外部モデルかという点
3. サンドボックスコードの取得で見えたのはClaude Sonnetと29個のツール構成
4. Qwen微調整モデルは補助モデルとして使われている可能性が高い
5. ManusはMCP依存ではなく独自のAgent開発から始まったと説明されている
6. Browser UseやComputer Use的な操作基盤がManusの実行力を支えている
7. 「套壳」論争の本質はモデルの出どころより工程設計の価値にある

Manusの基座模型はClaudeとQwen系モデルの組み合わせと見るのが自然

Manusの基座模型について、最も重要な答えはここです。複数の中国メディア報道では、Manusの共同創業者である季逸超氏が、Manusは現在Claudeとアリババ傘下のQwen系微調整モデルを使っているという趣旨の説明をしたと報じられています。つまり、Manusは完全な自社基礎モデルだけで動いているというより、既存の強力な大規模言語モデルを組み合わせたAgentシステムと見るのが自然です。

ここでいう「基座模型」とは、日本語では「基礎モデル」や「土台となるAIモデル」に近い意味です。たとえばClaude、GPT、Qwen、Llamaのように、文章理解・推論・生成の中心になる大きなAIモデルが該当します。Manusの場合は、その土台にClaude Sonnet系とQwen系のモデルが関わっていると説明されています。

ただし、これだけで「ManusはClaudeの見た目を変えただけ」と言い切るのは少し雑です。Manusは、ユーザーの依頼を分解し、ブラウザを操作し、ファイルを読み書きし、タスクを何十ステップも進める仕組みを持っています。基座模型は頭脳にあたりますが、実際に仕事を進めるには、手足や作業机にあたるツール設計が必要です。

🧭 Manusの基座模型に関する整理表

項目	調査情報から見える内容
主な基座模型	Claude Sonnet系モデル
補助的なモデル	アリババ系Qwenの微調整モデル
自社で基礎モデルを一から作ったか	公開情報上はそうとは言いにくい
価値の中心	モデルそのものよりAgentの設計・文脈管理・実行環境
注意点	報道や関係者発言ベースであり、内部構成の全量公開ではない

第一财经は、Manusについて「Claude与阿里旗下Qwen微调模型」を使っていると報じています。
引用元：https://www.yicai.com/news/102504492.html

Manusを理解するうえで大事なのは、「基座模型＝製品のすべて」ではないという点です。同じClaudeを使っても、単なるチャットボットになることもあれば、調査レポートを作るAgentになることもあります。違いを生むのは、タスク分解、ツール選択、途中結果の保存、失敗時の修正といった周辺設計です。

🧩 基座模型とAgentシステムの違い

比較項目	基座模型	Agentシステム
役割	考える・文章を作る	目的に向かって作業を進める
例	Claude、Qwen、GPT	Manus、ChatGPT Agent、Gensparkなど
必要な機能	言語理解、推論、生成	ツール呼び出し、記憶、計画、実行
弱点	単体では外部操作が苦手	設計が悪いと失敗や暴走が増える
評価軸	モデル性能	タスク完了率、速度、コスト、使いやすさ

そのため、「manus 基 座 模型」と検索している人は、ClaudeやQwenの名前だけを覚えるより、Manusがそれらをどう組み合わせているのかを見るほうが理解が深まります。Manusは、強いモデルを呼び出すだけではなく、作業の流れを設計している点に特徴があります。

「manus 基 座 模型」で知りたい核心は自社モデルか外部モデルかという点

「manus 基 座 模型」と検索する人の多くは、Manusが本当にすごい技術なのか、それとも既存モデルの上に作られたアプリなのかを知りたいはずです。この疑問はかなり自然です。AI業界では、基礎モデルを自社開発している企業と、その上にアプリを作る企業では、技術の見え方が大きく変わるからです。

調査情報を見る限り、ManusはDeepSeekのように「自社の基礎モデルそのもの」で注目されたというより、既存の前線モデルを使いこなすAgent製品として注目されたと考えるほうが近いです。Claudeの推論力、Qwen系モデルの補助能力、Browser Useのような操作基盤、サンドボックス環境を組み合わせたものです。

ただし、外部モデルを使っているから価値が低いとは限りません。SaaSやWebサービスの世界でも、クラウド、決済API、地図API、検索APIなどを組み合わせて大きな価値を作る例は多くあります。AI Agentでも同じで、どのモデルを使うかだけではなく、ユーザーの仕事を最後まで終わらせる設計が重要になります。

🔍 検索意図別に見る「manus 基 座 模型」の答え

読者の疑問	短い答え
Manusは自社モデルなのか	公開情報上は、ClaudeとQwen系モデルを使っていると見られる
Claudeだけで動いているのか	Claudeだけではなく、Qwen系微調整モデルやツール群も関わるとされる
Qwenは何に使われるのか	補助モデル、特定タスク、国内モデル対応などに使われる可能性がある
ManusはMCPで作られたのか	創業者はMCP登場前から開発していたと説明している
技術的にすごいのか	基礎モデル開発ではなく、Agent設計・工程管理が評価点になりやすい

Manusの議論で混乱しやすいのは、「基礎モデルを作っていない＝単なるコピー」と短絡されやすいことです。たしかに、基礎モデルを持つ企業のほうが、長期的には強い立場を取りやすいかもしれません。しかしAgent製品では、ユーザー体験、出力品質、待ち時間、文書生成、UI、テンプレートなども競争力になります。

📌 自社モデル型と外部モデル活用型の違い

方式	メリット	デメリット
自社基礎モデル型	技術主導権を持ちやすい、差別化しやすい	開発費が大きい、改善に時間がかかる
外部モデル活用型	速く作れる、最新モデルの進化に乗れる	モデル提供元に依存しやすい
ハイブリッド型	用途ごとに最適化しやすい	構成が複雑になりやすい
Manus型に近い形	強いモデルと工程設計を組み合わせる	「套壳」と見られやすい

Manusは、基礎モデルの研究成果を自社だけで抱えるタイプではなく、既存モデルの上に「仕事を進める仕組み」を作るタイプに見えます。これは現在のAI Agent市場ではかなり一般的な方向です。OpenAI自身もAgent機能を強化しており、今後はモデル会社とAgent会社の境界がさらに曖昧になるかもしれません。

サンドボックスコードの取得で見えたのはClaude Sonnetと29個のツール構成

Manusの基座模型が話題になったきっかけの一つが、ユーザーがManusのサンドボックス内にある/opt/.manus/配下のファイルを確認し、実行コードや構成の一部を見たとされる出来事です。報道では、この情報からManusがClaude Sonnetモデルを利用し、Claude Sonnetベースで29個のツールを使っていることが見えたとされています。

サンドボックスとは、外部に影響を出しにくい隔離された作業環境のことです。AI Agentがコードを実行したり、ファイルを作ったり、Webを操作したりする場合、いきなりユーザーの本番環境で動かすのは危険です。そのため、仮想的な作業場を用意し、そこで安全に処理を進める仕組みが使われます。

Manus側の説明では、このサンドボックスコードの「漏えい」は単純な脆弱性ではなく、設計上アクセスできるものだという趣旨の説明がされています。もちろん、外部から見ると「本当に問題ないのか」と不安になる部分もあります。専門家コメントでは、設計の一部ではあるが、暗号化や見せ方が粗いという見方も出ています。

🧪 サンドボックスで見えたとされる情報

観点	内容
取得された場所	/opt/.manus/配下のファイル
見えたとされる構成	Claude Sonnet、29個のツール
多智能体について	Claudeの多智能体そのものは使っていないと報じられた
操作基盤	Browser Useのオープンソースコード利用が指摘された
Manus側の説明	サンドボックスアクセスは設計の一部という趣旨

新浪科技も、ManusがClaude Sonnetモデルと29個のツールを使っていると報じています。
引用元：https://finance.sina.com.cn/tech/roll/2025-03-10/doc-inepetxi3401963.shtml

この件で重要なのは、Manusが「魔法のような一枚岩のAI」ではなく、複数の部品からなるシステムだと見えてきたことです。Claudeが判断し、ツールが実行し、サンドボックスが安全な作業場を提供し、ファイルシステムが記憶を支えます。人間の会社にたとえるなら、頭脳だけでなく、作業部屋、道具、手順書、チェックリストがある状態です。

🧰 Manusを構成する部品のイメージ

部品	役割
Claude Sonnet	依頼内容の理解、計画、判断の中心
Qwen系モデル	補助的な推論や特定タスク対応の可能性
ツール群	ブラウザ操作、ファイル処理、コード実行など
サンドボックス	安全に作業する隔離環境
todo.md	作業計画と進捗の保持
文脈管理	過去の情報をどう残し、どう省くかの設計

サンドボックスコードの件は、Manusへの疑念を強めた一方で、Agentシステムがどのように作られているのかを理解する材料にもなりました。AI Agentは、単にチャットで答えるだけではありません。実際に作業環境を持ち、ツールを動かし、途中で失敗しながら修正する仕組みです。

Qwen微調整モデルは補助モデルとして使われている可能性が高い

Manusの基座模型を語るうえで、Claudeと並んで出てくるのがアリババのQwenです。報道では、Manusはアリババ傘下の異なるQwen微調整モデルを使っているとされています。また、Manusを運営するMonica.imチームとアリババ通義千問チームが戦略提携し、Qwen系列のオープンモデルをもとに国産モデルと算力基盤でManusの機能を実現する方向が報じられています。

ここでいう微調整モデルとは、もともとの大規模モデルを、特定の目的に合わせて追加学習・調整したモデルのことです。一般的には、基礎モデルが広く何でもできる大きな頭脳だとすると、微調整モデルは特定の業務に慣れた専門スタッフのような位置づけです。Manusでは、こうした補助モデルが意図認識、タスク計画、ツール選択などに関わっている可能性が指摘されています。

ただし、どのQwenモデルがどの処理を担当しているかまで、完全に公開されているわけではありません。そのため、「Qwenが中核」「Claudeが中核」と単純に決めつけるより、Claudeを中心に、Qwen系の補助モデルを組み合わせている構成として理解するのが無難です。

🧠 ClaudeとQwenの役割イメージ

モデル	役割の見方
Claude Sonnet	高度な理解、推論、計画の中心になっている可能性
Qwen微調整モデル	補助タスク、分類、計画、国内環境対応などに使われる可能性
専用小型モデル	低コスト処理や特定判断を担う可能性
外部ツール	実際のブラウザ操作やファイル処理を担当

Qwenが重要なのは、Manusが中国発のAgentとして国内のモデル・算力基盤に対応するうえで、アリババ系のエコシステムと結びつきやすいからです。海外モデルだけに依存すると、コスト、規制、アクセス、商用展開の面で制約が出る可能性があります。Qwen対応は、Manusの国内展開や企業利用を考えるうえで大きな意味を持つかもしれません。

🤝 ManusとQwen提携の意味

観点	意味
技術面	Claude依存を一部下げられる可能性
コスト面	国産モデル・算力で運用しやすくなる可能性
商業面	中国国内の企業導入に向きやすい
競争面	アリババのAIエコシステム強化につながる
注意点	完全な置き換えがどこまで可能かは公開情報だけでは不明

21経済網の記事では、ManusがAI基座模型に依存する構造を背景に、アリババ、テンセント、OpenAIなどがAgentツールチェーンを打ち出し、基礎モデルのエコシステム競争が始まったと整理されています。これは、Manus単体の話にとどまらず、AI Agent市場全体の流れでもあります。

ManusはMCP依存ではなく独自のAgent開発から始まったと説明されている

Manusについては、MCPを使ってLLMと外部リソースをつないでいるのではないか、という見方もありました。MCPとは、Model Context Protocolの略で、AIモデルと外部ツールやデータをつなぐための標準化された仕組みとして注目されているものです。一般的には、AI Agentが外部のファイル、API、データベースなどを扱いやすくするための規格と理解するとわかりやすいです。

しかし、報道によると、季逸超氏はManusがMCPに依存して作られたという見方を否定し、ManusはMCPが出る前から開発されていたと説明しています。公開情報では、MCPはAnthropicが2024年11月25日に発表したオープンプロトコルとされています。Manusの開発開始時期がそれ以前であれば、MCP前提ではないという説明には一定の筋があります。

つまり、Manusの仕組みは、MCPそのものというより、独自のAgentフレームワーク、ツール設計、サンドボックス、文脈管理によって組み立てられていると見るのが自然です。もちろん、今後MCP的な仕組みと接続する可能性までは否定できませんが、少なくとも初期設計はMCP依存ではないと説明されています。

🔌 MCPとManusの関係整理

項目	内容
MCPの役割	モデルと外部ツール・データをつなぐ標準化プロトコル
公開時期	2024年11月25日とされる
Manus側の説明	MCP登場前から開発していたという趣旨
誤解されやすい点	外部ツールを使うAgentなら全部MCPというわけではない
現実的な見方	Manusは独自設計のAgentシステムと見るのが無難

MCPが話題になる理由は、AI Agentが多くの外部ツールを扱う時代になると、接続方法の標準化が重要になるからです。たとえばメール、カレンダー、ブラウザ、表計算、社内DBなどをAgentが操作する場合、毎回バラバラに作るより、共通の接続ルールがあったほうが便利です。

🧷 Agentに外部接続が必要な理由

作業例	外部接続が必要な理由
調査レポート作成	Web検索やページ閲覧が必要
表計算作成	ファイル操作や表計算ツールが必要
旅行計画	地図、宿泊、移動情報が必要
業務自動化	社内システムやAPIとの連携が必要
メール整理	メールアプリやアカウントへのアクセスが必要

ただし、ツール接続が増えるほど、Agentは賢くなるどころか混乱する場合もあります。Manus公式ブログでは、ツール数が増えすぎるとモデルが間違った行動を選びやすくなるという問題が語られています。そのため、Manusはツールを単純に出し入れするのではなく、文脈に応じて使えるアクションを制御する考え方を重視しているようです。

Browser UseやComputer Use的な操作基盤がManusの実行力を支えている

Manusが通常のチャットAIと違って見える理由の一つは、実際にブラウザを操作したり、ファイルを扱ったり、コードを実行したりできる点です。報道では、Manusはブラウザ自動化ツールBrowser Useのオープンソースコードを利用し、Computer Use能力の土台としていたとされています。

Computer Useとは、AIが人間のように画面を見て、カーソルを動かし、ボタンをクリックし、文字を入力するような機能を指します。AnthropicのClaude 3.5 Sonnetの一部機能として注目された概念でもあります。Manusはこの流れを、クラウド上のサンドボックスやブラウザ操作と組み合わせて、ユーザーの依頼を実行するAgentとして見せています。

この操作基盤があることで、Manusは「調べて終わり」ではなく、「調べて、整理して、ファイルにして、場合によってはWebページやスライドの形にする」という流れを作れます。これは読者にとっても重要です。なぜなら、Manusの価値は回答文だけでなく、納品物を作る体験にあるからです。

🖥️ Manusの実行力を支える要素

要素	役割
ブラウザ操作	Webページを開く、情報を取得する
コード実行	データ分析、ファイル処理、可視化を行う
ファイル操作	todo.md、表、レポート、成果物を作る
サンドボックス	安全な環境で処理する
モデル判断	次に何をすべきか決める

たとえば、Manusの紹介やメディア記事では、履歴書の選別、不動産調査、株式分析などのタスクが取り上げられています。これらは単に答えを返せばよいものではありません。ファイルを読んだり、条件を整理したり、比較表を作ったり、可視化したりする必要があります。そこで、モデルと操作基盤の組み合わせが効いてきます。

📊 チャットAIとManus型Agentの違い

比較項目	チャットAI	Manus型Agent
出力	会話・文章中心	レポート、表、ファイル、Webページなど
作業時間	比較的短い	数分から長時間になることがある
外部操作	限定的な場合が多い	ブラウザやファイル操作を含む
ユーザー体験	質問して答えを読む	依頼して成果物を待つ
失敗の形	誤回答	タスク中断、ツール失敗、文脈忘れなど

この点で、Manusは「AIと会話するサービス」ではなく、「AIに仕事を投げるサービス」に近い存在です。もちろん、成功率や安定性にはまだ課題があると報じられていますが、利用者が驚いた理由はここにあります。

「套壳」論争の本質はモデルの出どころより工程設計の価値にある

Manusには「套壳」、つまり既存モデルに皮をかぶせただけではないかという批判があります。たしかに、ClaudeやQwenを使っているなら、基礎モデルを自社開発している企業とは違います。技術の見せ方によっては、「中身はClaudeなのでは」と言われやすい構造です。

しかし、AI Agentにおける価値は、基礎モデルの出どころだけでは決まりません。ユーザーの一文を受け取り、作業を分解し、必要なツールを選び、途中の失敗から修正し、最終成果物にまとめる。ここにはかなりの工程設計が必要です。Manusが評価されたのは、この工程設計がユーザー体験として見えやすかったからだと考えられます。

証券時報の記事では、Manusが自社で底層大模型を持たないことへの議論に触れつつ、製品理念や工程能力が話題になったと整理されています。特に、todo.mdを中心に作業を進め、文脈管理や実行フィードバックを保つ仕組みが注目されています。

⚖️ 「套壳」批判と反論の整理

見方	内容
批判側	Claudeなど既存モデルに依存しているなら独自性が低い
擁護側	基礎モデルを使いこなす工程設計こそ製品価値
中立的な見方	基礎モデル開発ではないが、Agent設計には価値がある
注意点	過度な神格化も、単なるコピー扱いも極端
読者への結論	モデル名と成果物品質の両方を見るべき

证券时报は、Manusについて「技術門檻没那么高，靠产品理念和工程能力取胜」という趣旨で整理しています。
引用元：https://www.stcn.com/article/detail/1568250.html

たとえるなら、Manusはエンジンを自社で作った自動車メーカーというより、強力な外部エンジン、車体設計、運転支援、ナビ、内装、サービス体験を組み合わせたプロダクトに近いかもしれません。この比喩も完全ではありませんが、基礎モデルだけで製品体験は決まらないという意味ではわかりやすいです。

🧱 Manusの価値を分解する表

価値の要素	内容
モデル選定	ClaudeやQwenなど強力なモデルを使う
ツール設計	ブラウザ、シェル、ファイル操作を組み合わせる
文脈管理	長い作業でも目的を忘れにくくする
成果物設計	表、レポート、スライドなどにまとめる
UX	ユーザーが一文で依頼し、結果を待てる体験

したがって、Manusを評価するときは、「Claudeを使っているからダメ」でも「AGIに近いからすごい」でもなく、実際にどんなタスクで、どれくらいの成功率で、どの品質の成果物を出せるのかを見るのが現実的です。

manusの基座模型から見るAI Agentの勝ち筋と注意点

1. Manusの強みは基座模型よりコンテキストエンジニアリングにある
2. todo.mdを使う理由は長い作業で目的を忘れないため
3. ファイルシステムを文脈として使う発想が長文タスクを支えている
4. KVキャッシュ設計はAgentの速度とコストを左右する
5. ChatGPT Agentとの違いは専用モデル型か文脈工程型かにある
6. AI Agentを使う側は安全性と権限管理を軽く見ないほうがいい
7. 総括：manus 基 座 模型のまとめ

Manusの強みは基座模型よりコンテキストエンジニアリングにある

Manus公式ブログでは、Manusの方向性として、エンドツーエンドの専用Agentモデルを一から訓練するのではなく、前線モデルの文脈学習能力を活かす「コンテキストエンジニアリング」に賭けたと説明されています。これは、基礎モデルそのものを作るより、モデルに与える情報、記憶、道具、環境、フィードバックをどう設計するかを重視する考え方です。

コンテキストとは、AIに渡す会話履歴、システム指示、ツールの結果、ファイル情報、過去の失敗などを含む「判断材料」のことです。AI Agentは一回の回答で終わらず、何十回も考えて行動します。そのたびに、何を文脈に残し、何を外に出し、何を再確認するかが結果を左右します。

Manusの共同創業者は、モデルの進歩を「上がる潮」にたとえ、Manusは海底に固定された柱ではなく、その潮に乗る船でありたいという趣旨の説明をしています。つまり、ClaudeやQwenなどのモデルが進化すれば、Manusもその恩恵を受けやすい構造を目指しているということです。

🧠 コンテキストエンジニアリングの意味

用語	わかりやすい説明
コンテキスト	AIに渡す判断材料のまとまり
コンテキストエンジニアリング	判断材料をどう並べ、残し、圧縮するかの設計
エンドツーエンド訓練	専用モデルを最初から目的に合わせて学習させる方法
Manusの選択	前線モデルを使い、文脈設計でAgent性能を上げる方向

この考え方は、AI Agentにおいてかなり実務的です。専用モデルを訓練するには時間もコストもかかります。一方で、文脈設計なら数時間から数日の改善でユーザー体験を変えられる可能性があります。特にPMF前のプロダクトでは、速く試して速く直すことが重要です。

🚀 Manus型アプローチの強みと弱み

観点	強み	弱み
改善速度	文脈やツール設計をすぐ直せる	根本能力は外部モデルに依存しやすい
コスト	キャッシュや小型モデルで調整しやすい	長時間タスクは費用が膨らみやすい
品質	成果物体験を磨きやすい	モデル更新で挙動が変わる可能性
差別化	UXや工程設計で勝負できる	模倣されやすい部分もある

Manus公式ブログでは、Manusが文脈工程に賭けた理由と、KVキャッシュ、ファイルシステム、todo.mdなどの設計思想が説明されています。
引用元：https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

つまり、Manusの基座模型を知ることは入口にすぎません。より本質的には、ManusがClaudeやQwenをどう働かせるように設計しているかを見るべきです。AI Agentの時代には、モデル選びと同じくらい、文脈設計が競争力になります。

todo.mdを使う理由は長い作業で目的を忘れないため

Manusの特徴としてよく出てくるのが、タスク中にtodo.mdのようなファイルを作り、作業リストを更新しながら進める動きです。一見すると単なるチェックリストですが、これはAI Agentにとってかなり重要な工夫です。長いタスクでは、AIが最初の目的を忘れたり、途中の作業に引っ張られて方向がずれたりすることがあります。

Manus公式ブログでは、典型的なタスクで平均約50回のツール呼び出しがあると説明されています。50回も行動すれば、人間でも途中で何をしていたか確認したくなります。AIも同じで、目的や計画を文脈の後ろのほうに何度も出すことで、注意をタスク目標へ戻しやすくしていると考えられます。

この仕組みは「記憶」と「指揮」の両方を兼ねています。todo.mdには、やるべきこと、終わったこと、次にやることが書かれます。AIはそれを読み直しながら、自分が今どこにいるのかを確認します。これは、複雑な仕事を任せるうえで重要です。

✅ todo.mdが果たす役割

役割	内容
計画	タスクを小さなステップに分ける
記憶	何を終えたかを残す
注意誘導	目的を文脈の後半に再登場させる
修正	失敗したら次の手順を変える
共有	ユーザーにも進捗が見えやすくなる

人間の仕事でも、長い調査や開発ではタスクリストを作ります。Manusのtodo.mdもそれに近いものです。ただし、AIにとっては単なるメモ以上の意味があります。LLMは直近の文脈に強く影響されやすいため、重要な目標を何度も再提示することで、方向性のブレを抑えられる可能性があります。

📋 todo.mdが効きやすいタスク

タスク	理由
市場調査	調べる観点が多く、途中で迷いやすい
履歴書選別	評価基準を一貫させる必要がある
不動産比較	価格、場所、治安、教育など複数条件がある
株式分析	データ取得、分析、可視化、考察が必要
記事制作	構成、調査、執筆、整形の流れが長い

この仕組みからわかるのは、AI Agentは「一発で賢い答えを出すAI」ではなく、「作業中に自分を管理するAI」へ進化しているということです。Manusの基座模型がClaudeやQwenであっても、todo.mdのような工程管理がなければ、長い作業の成功率は下がるかもしれません。

ファイルシステムを文脈として使う発想が長文タスクを支えている

Manus公式ブログで特に面白いのが、ファイルシステムを「究極の文脈」として使うという考え方です。AIのコンテキストウィンドウは大きくなっていますが、どれだけ広くても無限ではありません。Webページ、PDF、表、コード、長い会話を全部入れると、すぐに重くなり、コストも高くなります。

そこでManusは、すべてを会話文脈に詰め込むのではなく、必要な情報をファイルとして保存し、必要なときに読み返す方式を重視していると説明しています。たとえばWebページの全文を常に持ち続けなくても、URLや保存ファイルのパスを残しておけば、あとから再取得できます。

これは人間の仕事にも近いです。人間も、すべてを頭の中に入れておくわけではありません。ノート、フォルダ、スプレッドシート、ブックマークを使いながら作業します。Manusも同じように、外部記憶としてファイルシステムを使っていると考えると理解しやすいです。

🗂️ ファイルシステムを文脈にするメリット

メリット	内容
長文を抱え込まなくてよい	必要なときだけ読める
情報を失いにくい	ファイルとして残せる
コストを抑えやすい	毎回すべての本文を入れなくてよい
復旧しやすい	パスやURLがあれば再確認できる
作業が構造化される	データ、メモ、成果物を分けられる

ただし、ファイルシステムを使うだけで万全ではありません。AIがどのファイルに何を書いたかを忘れたり、古い情報を参照したり、間違ったファイルを更新したりする可能性はあります。だからこそ、ファイル名、フォルダ構成、読み返しルール、todo.mdとの連動が重要になります。

📁 文脈として使われるファイルの例

ファイル例	使い道
todo.md	作業計画と進捗管理
research.md	調査結果の保存
data.csv	集計用データ
report.md	最終レポートの下書き
output.html	成果物ページ
logs.txt	エラーや実行履歴

ファイルシステムを活用することで、Manusは長いタスクでも情報を完全に捨てずに進めやすくなります。これは単なる便利機能ではなく、AI Agentの実用性を左右する重要な設計です。基座模型が同じでも、外部記憶の使い方が違えば、タスク完了率は変わってくるはずです。

KVキャッシュ設計はAgentの速度とコストを左右する

Manus公式ブログでは、AI Agentの本番運用においてKVキャッシュの命中率が重要だと説明されています。KVキャッシュとは、ざっくり言えば、AIがすでに読んだ文脈を再利用し、毎回ゼロから処理しなくてよくする仕組みです。これにより、応答開始までの時間や推論コストを下げられる可能性があります。

Agentはチャットボットよりも、入力が長く出力が短い傾向があります。Manusでは平均的な入力と出力のトークン比率が約100:1だと説明されています。つまり、毎回大量の文脈を読ませて、短いツール呼び出しを出すような動きになります。ここでキャッシュが効かないと、コストも時間も増えやすくなります。

Manus公式ブログでは、Claude Sonnet利用時の例として、キャッシュされた入力トークンのコストが未キャッシュ時より大きく安くなるという説明があります。具体的な価格は時期や提供条件で変わる可能性がありますが、考え方としては、Agentの商用化にはキャッシュ設計がかなり重要です。

⚡ KVキャッシュが重要な理由

理由	内容
入力が長い	Agentは過去の行動や観察を大量に読む
出力が短い	次のツール呼び出しだけ出す場面が多い
反復回数が多い	1タスクで何十回もモデルを呼ぶ
コスト差が出る	キャッシュ有無で費用が変わりやすい
速度に影響する	初回トークン生成までの時間が変わる

KVキャッシュを効かせるには、プロンプトの前半を安定させる必要があります。たとえばシステムプロンプトの先頭に毎回秒単位のタイムスタンプを入れると、その後ろのキャッシュが効きにくくなる可能性があります。また、JSONのキー順序が毎回変わるような不安定なシリアライズも、キャッシュには悪影響です。

🛠️ キャッシュを壊しやすい設計

NGに近い設計	なぜ問題か
毎回変わるタイムスタンプを先頭に入れる	その後ろの文脈が別物扱いされやすい
ツール定義を頻繁に出し入れする	文脈前半が変わりやすい
JSONの順序が不安定	同じ意味でも別トークン列になる
過去ログを編集する	追加型の文脈にならない
キャッシュ境界を意識しない	再利用できる範囲が小さくなる

この話は少し専門的ですが、読者向けに言い換えると、AI Agentは「賢さ」だけでなく「運用コストの設計」が勝負になります。1回のタスクに長時間かかり、モデル呼び出しが何十回も発生するなら、キャッシュ設計が悪いサービスは高価で遅くなりやすいです。Manusがコンテキストエンジニアリングを重視する理由はここにもあります。

ChatGPT Agentとの違いは専用モデル型か文脈工程型かにある

2025年7月には、OpenAIがChatGPT Agentを発表し、ManusのようなAI Agentスタートアップに大きな圧力をかける存在として報じられました。36Krの記事では、OpenAIがChatGPT Agentを「モデル」として位置づけ、OperatorやDeep Researchの流れを統合したものとして説明されています。

Manus側は、ChatGPT Agent発表後に比較テストを出し、タスク完了度や成果物の見栄えで優位性を主張したと報じられています。一方で、OpenAIは基礎モデル能力や専用モデル訓練の面で強みがあります。つまり、両者の違いは、OpenAIが専用モデル型に近く、Manusが文脈工程型に近いという点にあります。

もちろん、これは単純な二分法です。OpenAIも工程設計を行いますし、Manusもモデル選定や微調整モデルを使います。ただ、大きな方向性として、OpenAIは基礎モデルの能力を上げてAgent化し、Manusは強い既存モデルを前提に文脈・ツール・成果物体験を磨いていると見るとわかりやすいです。

🤖 ManusとChatGPT Agentの比較

項目	Manus	ChatGPT Agent
方向性	文脈工程とツール編成を重視	専用Agentモデル的な方向を重視
強み	成果物体験、テンプレート、工程設計	基礎モデル能力、統合環境、研究開発力
弱み	外部モデル依存、模倣リスク	初期の成果物品質や速度に課題との声
競争軸	完成度の高い納品物	モデル能力と統合機能
読者の見方	何を作れるかを見る	どこまで自律的に進められるかを見る

36Krは、OpenAIのChatGPT AgentとManusの違いについて、端到端モデルと文脈工程の技術路线の違いとして整理しています。
引用元：https://eu.36kr.com/zh/p/3385950826142089

OpenAIのような基礎モデル企業がAgent機能を標準搭載すると、Manusのようなスタートアップは苦しくなる可能性があります。なぜなら、基礎モデル提供元が直接Agent機能を出せば、モデル性能、価格、統合環境で優位に立ちやすいからです。

📈 Agent市場で見られる競争軸

競争軸	説明
モデル性能	推論力、長時間思考、表計算、分析能力
タスク完了率	最後まで作業を終えられるか
成果物品質	表、資料、レポート、Webページの完成度
速度	数分で終わるか、数十分かかるか
コスト	1タスクあたりの運用費
安全性	権限管理、確認フロー、攻撃耐性
使いやすさ	初心者でも依頼しやすいか

ただし、スタートアップ側にも勝ち筋はあります。特定の成果物に特化したUX、業界別テンプレート、企業向けワークフロー、低コスト運用などです。OpenAIが広く強いなら、Manusのような企業は「より完成度の高い仕事体験」で勝負する必要があるかもしれません。

AI Agentを使う側は安全性と権限管理を軽く見ないほうがいい

Manusの基座模型や技術構成を調べると、AI Agentは非常に便利に見えます。しかし同時に、注意すべき点もあります。Agentは会話するだけのAIではなく、ブラウザを操作し、ファイルを扱い、場合によっては外部サービスにアクセスします。これは便利である一方、権限を与えすぎるとリスクも増えます。

たとえば、Agentにメール、カレンダー、クラウドドライブ、決済情報、社内システムへのアクセスを渡すと、タスクを自動化できる範囲が広がります。しかし、悪意あるページや間違った指示、モデルの誤判断によって、本来渡すべきでない情報が出る可能性も考えられます。これはManusだけでなく、ChatGPT Agentなどにも共通する論点です。

OpenAIのChatGPT Agentについても、リスクや重要操作時のユーザー確認が報じられています。Agentができることが増えるほど、ユーザーがどこまで許可するかを意識する必要があります。便利さだけを見て、すべての権限を渡すのは慎重に考えたほうがよいでしょう。

🔐 AI Agent利用時の注意点

注意点	内容
最小権限	必要な範囲だけアクセスを許可する
重要操作の確認	購入、送信、削除、投稿は必ず確認する
個人情報	高リスク情報をむやみに渡さない
成果物確認	出力をそのまま公開しない
ログ管理	何を実行したか確認できる状態にする

Manusのサンドボックス設計は、安全に作業するための一つの工夫です。ただし、サンドボックスがあればすべて安全というわけではありません。外部サイトへのアクセス、ファイルのアップロード、認証情報の扱いなどは、ユーザー側も慎重に見る必要があります。

🧯 Agentに任せやすい作業と慎重にすべき作業

作業	任せやすさ	理由
公開情報の調査	高い	個人情報や金銭操作が少ない
レポート下書き	高い	最後に人間が確認しやすい
表の整理	中程度	元データ確認が必要
メール返信	中程度	誤送信リスクがある
決済・予約	低め	金銭や契約に関わる
社内DB操作	低め	情報漏えいや削除リスクがある

AI Agentは、今後かなり便利になる可能性があります。しかし、便利さと安全性はセットで考える必要があります。特にビジネス利用では、誰の権限で、どのデータにアクセスし、何を実行できるのかを明確にすることが重要です。

総括：manus 基 座 模型のまとめ

最後に記事のポイントをまとめます。

1. Manusの基座模型は、公開情報上、Claude Sonnet系とQwen系微調整モデルの組み合わせと見るのが自然である。
2. Manusは自社で巨大な基礎モデルを一から作った製品というより、既存モデルを使いこなすAI Agentである。
3. Claude SonnetはManusの理解・推論・計画の中心に関わっている可能性が高い。
4. Qwen系微調整モデルは、補助タスクや国内モデル・算力対応の文脈で重要である。
5. サンドボックスコードの取得により、Claude Sonnetと29個のツール構成が報じられた。
6. Manus側は、サンドボックスへのアクセスは設計の一部という趣旨で説明している。
7. ManusはMCP登場前から開発されていたと説明されており、MCP依存の製品とは言い切れない。
8. Manusの価値は、基座模型そのものだけでなく、ツール設計、文脈管理、todo.md、ファイルシステム活用にある。
9. 「套壳」批判には一定の理由があるが、工程設計や成果物体験まで含めると単純な皮かぶせとは言いにくい。
10. コンテキストエンジニアリングは、Manus型Agentの速度、コスト、成功率を左右する重要な要素である。
11. ChatGPT Agentは専用モデル型に近く、Manusは文脈工程型に近いという見方ができる。
12. AI Agentを使う側は、モデル名だけでなく、タスク完了率、成果物品質、速度、コスト、安全性を確認すべきである。
13. 権限を渡すAgentでは、最小権限、重要操作の確認、個人情報の扱いが重要である。
14. 「manus 基 座 模型」と検索した人は、ClaudeとQwenの名前だけでなく、それらをどう動かす設計かを見るべきである。

調査にあたり一部参考にさせて頂いたサイト

• https://www.yicai.com/news/102504492.html
• https://podcasts.apple.com/us/podcast/manus%E7%88%86%E7%81%AB%E8%83%8C%E5%90%8E%E7%9A%84agent%E9%9D%A9%E5%91%BD-%E6%B7%B1%E5%BA%A6%E8%A7%A3%E6%9E%90%E6%8A%80%E6%9C%AF-%E6%88%90%E6%9C%AC%E4%B8%8E%E6%8A%A4%E5%9F%8E%E6%B2%B3/id1804297841?i=1000700720663&l=zh-Hans-CN
• https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
• https://finance.sina.com.cn/tech/roll/2025-03-10/doc-inepetxi3401963.shtml
• https://zhuanlan.zhihu.com/p/1885412839885345389
• https://www.21jingji.com/article/20250320/herald/b3b0bd69deca1c197aaee13054aade6b.html
• https://www.stcn.com/article/detail/1568250.html
• https://zhuanlan.zhihu.com/p/1990902800046110534
• https://www.21jingji.com/article/20250314/herald/8a720bebb4a366cd3c5ba1607d921b61.html
• https://eu.36kr.com/zh/p/3385950826142089

当サイトについて

当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。

情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。
迅速に対応をさせていただきます。

その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。

お問い合わせフォーム

今後とも当サイトをよろしくお願いいたします。