ClaudeとManusの比較 — 自律実行の権限設計と監査ログの違い

Manusは何をするエージェントか

Manusは、依頼した作業をエージェントがタスクごとの仮想マシン上で自律的に進める製品です。ブラウザー操作・コード実行・ファイル作成を組み合わせ、スライドやWebサイトのような成果物をそのまま作って返します。社名の由来である"Mens et Manus"(心と手)の通り、考えるだけでなく手を動かして完結させる設計です。

連携先はGoogle Calendar・GitHub・Notion・Slackなどです。Claudeで近い体験を作るなら、対応するのはCowork(業務向けのエージェント製品)と、開発者がエージェントを自作するためのAgent SDKの2つになります。両者は権限の作り方が違うため、比較は1本の軸では終わりません。この記事では、①サンドボックスの中身、②承認を挟む層、③共有したときに見える範囲、④監査ログの射程、の4点で並べます。資料理解に特化したツールとの違いはClaude CoworkとNotebookLMの比較で扱っています。

サンドボックスには何が置かれ、どこまで自由か

ManusはZero Trust(信頼を前提にしない)原則を掲げています。ただし意味するのはサンドボックス「の外」への影響を遮断することで、「の中」の操作は制限しません。公式ブログの説明は次のとおりです。

"you and Manus have full control over this computer—you can perform unrestricted operations (for example, gaining root access, modifying system files, or even formatting the entire disk). This allows Manus to complete tasks with minimal permission constraints."

サンドボックスにはタスクの添付ファイルと成果物のほか、タスク実行に必要な設定も入ります。ブログが挙げる例は、ユーザーがアップロードしたトークンと、Manusがユーザーに割り当てたAPI呼び出し用のトークンです。つまり認証情報が、無制限に操作できるVMの中に置かれます。

Coworkは逆の配置です。クラウドセッションのサンドボックスが持つのは、数時間で失効するセッション限りのトークンだけです。コネクターの認可トークンはサンドボックスに入らず、コネクターの呼び出しはサーバー側で行われます。

くらべる

サンドボックスの設計の違い

タスクごとのVM

Manus

操作は無制限で、rootの取得やディスクの初期化もできます。影響が及ぶのはそのサンドボックスの中だけです。非アクティブなら休止し、Freeは7日・Proは21日で再作成の対象になります。

セッションごとの隔離

Cowork

クラウドセッションは開始時に作られ、終了時に破棄されます。外向きの通信は、サンドボックス自身が設定を変えられない必須のプロキシを通り、許可リストにある宛先にしか届きません。

Manusのサンドボックスが休止から復帰するとき、ファイルとデータはそのままです。再作成された場合は、成果物・添付ファイル・SlidesやWebDevのプロジェクトが復元され、実行中に作った中間コードと一時ファイルは復元されません。常時稼働のバックエンドが要るなら、サンドボックスに置かず、Webの開発機能でフロントとバックを作って公開する形がブログで案内されています。

Coworkのデスクトップ経由では、クラウドセッションがユーザーのローカルファイルやブラウザーへ届く場面があります。このときの要求はデスクトップアプリを通り、接続済みフォルダーに限られ、ローカルのツール呼び出しはメンバーの権限と照合されてから実行されます。ローカルセッションでは、エージェントのループがデバイス上で動き、シェルコマンドとコードの実行だけが専用のLinux VMに入ります。macOSはApple Virtualization.framework、WindowsはHyper-Vで、ホストから隔離されます。

承認はどの層で挟まれるか

Manusでは、承認の応答がAPIの形で定義されています。確認が必要になるとタスクの状態がwaitingになり、呼び出し側がtask.confirmActionで承認または拒否を返します。確認の対象は操作の種類ごとに決まっています。

API

Manusの確認イベントと返す値

• コマンド実行(terminalExecute)

  { "accept": true, "always_allow": true }のように、以後の確認を省く指定も一緒に渡せます。

• デプロイ(deployAction)

  global_allowを付けると、以後のデプロイで確認が出なくなります。

• メール送信・予定の変更

  Gmail・Outlookの送信は、承認のほか下書き保存(save_draft)も選べます。Google・Outlookカレンダーの作成・更新・削除も確認の対象です。

• 外部サービスの破壊的な操作

  ShopifyのDelete操作とInstagramへの投稿が、コネクターの確認として挙がっています。

ドキュメントには、質問と確認を取り違えない注意もあります。エージェントからの質問(messageAskUserなど)にはtask.sendMessageで答え、task.confirmActionは使いません。知らない種類のwaitingが来たときは、自動で承認せずに現行のドキュメントを調べる、という指針です。OAuthの期限切れや設定の確認は、Manusの画面か外部の認可フローが必要で、再認可のあとにacceptを返します。

つまりManusのAPIは、承認を挟むかどうかを呼び出し側のコードに委ねています。製品として承認モードを選ばせるCoworkとは、同じ機能を置く層が違います。

Coworkの承認は3つのモードで切り替えます。「Automatically approve」は実行前に各操作の安全性を確認して危険な操作を止め、「Manually approve」は各操作の前に確認を求めます。「Skip all approvals」では、操作を検査する仕組みが何も働きません。ファイルの完全削除だけは、どのモードでも毎回確認されます。

"Claude always asks before permanently deleting files, in any mode."

組織の管理者は、この選択肢そのものを絞れます。クラウドセッションの組織設定には、2つの項目があります。常時許可(always allow)を無効にして、許可が必要な呼び出しごとに承認を求める設定が1つ。承認なしでセッションを走らせることをメンバーに許すかどうかが、もう1つです。ManusのAPIでalways_allowを渡すのが呼び出し側であるのに対し、こちらは管理者が上から固定できる位置にあります。

なお、画面を操作するコンピューター操作にはサンドボックスがありません。ファイル操作が権限チェックを通り、コード実行が隔離環境で動くのと違い、画面上のアプリやブラウザーに直接触れるため、アプリごとの許可が前提になります。

Agent SDKでは評価順そのものを組み立てる

Agent SDKで自作するエージェントは、さらに細かく制御できます。ツール呼び出しは次の順に評価され、先の段階で決まればそこで終わります。

手順

Agent SDKの権限評価の順序

1. 1

   フック

   呼び出しを拒否するか、次へ渡します。フックがallowを返しても、後続の拒否ルールと確認ルールは評価されます。

2. 2

   拒否ルール

   一致すればbypassPermissionsモードでもブロックされます。

3. 3

   確認ルール

   一致した呼び出しはcanUseToolコールバックへ回ります。requiresUserInteractionを立てたMCPツールも、許可ルールが一致していてここに回ります。

4. 4

   パーミッションモード

   bypassPermissionsは、重要パスを対象にしたrm・rmdirを除くすべてを承認します。

5. 5

   許可ルール

   一致すれば承認します。重要パスへのrm・rmdirは、許可ルールでは承認されません。

6. 6

   canUseTool

   どの段階でも決まらなかった呼び出しの最終判断です。dontAskモードではこの段階が省かれ、拒否になります。

ルールはパターンで書けます。disallowed_toolsにBashと書けば、ツールの定義そのものがClaudeから消えます。Bash(rm *)と書けばBashは使えたまま、書かれたとおりのrm *の呼び出しが全モードで拒否されます。ここには落とし穴があります。/bin/rmのような別の書き方はrm *に一致せず、そのモードの判定に回ります。拒否ルールは書いた文字列に対する照合なので、同じ効果を持つ別表記まで塞ぐには、ルールを足すか、フックで判定します。

共有と協働で、Manusのタスクは何が見えるか

Manusのタスクを他の人に渡す方法は2つあり、見える範囲がまったく違います。

協働に切り替えるとConnectorsは自動的に無効になるため、連携先のサービスには触れません。一方でサンドボックスに置いたファイルは相手に開きます。公式ブログは、機密を含むタスクで協働者を招く前に、必要な内容と成果物だけを新しいタスクへ写して招待する手順を挙げています。

監査ログとコンプライアンスの射程

Manusはチームプランの機能として監査ログを挙げます。Coworkでは、Compliance APIがEnterprise、OpenTelemetryがTeamとEnterpriseで使えます。違いは、何を記録するかの説明の具体さです。

Manusのチームプランのページは次のように機能を列挙しています。

"Admin dashboard with usage tracking and access control. SSO integration and granular sharing permissions. Audit logs and enterprise-grade compliance (SOC 2 Type II, ISO 27001)."

ページは「Audit logs」と並べるだけで、タスク内のファイル読み取りやコマンド実行まで記録するのか、利用状況やアクセス管理のイベントに限るのかは示していません。認証は、セキュリティのページにSOC 2 Type 2・SOC 2 Type 1・ISO 27001:2022・ISO 27701:2019の4つが掲げられています。

Coworkは記録の経路を具体的に書いています。ウェブ・デスクトップ・モバイル経由のCowork活動は、Compliance API(Enterprise)で捕捉されます。Team・Enterpriseの管理者はOpenTelemetryで、SIEMや可観測性ツールへイベントを流せます。流れる項目には、ユーザーのプロンプト全文、Claudeが読み書きしたファイルのパス、各操作をユーザーが承認したか拒否したか自動で始まったか、が含まれます。同じ公式ページは、見えないものも明記しています。

"The VM is isolated from host-based security tools by design, and sessions in the cloud run entirely outside your endpoints, so EDR tools can't observe them either. If your compliance posture depends on endpoint visibility, account for this before rolling out Cowork."

エンドポイント検知(EDR)ツールから見えないという制約まで先に書いてあるのは、監査要件を持つ組織が導入前に確かめる点として実務的です。Cowork側の補足として、スケジュール実行はクラウドで走り、PCの電源が切れていても動きます。過去の実行は「Scheduled」ページで見返せるため、監視ができない時間帯の動作は、実行ごとの出力確認で補う前提です。

比較表 — 評価軸ごとのまとめ

使い分け早見表 — どちらを選ぶか

Coworkの機能構成や料金はClaude Coworkとは — 全機能・料金・始め方を1記事でにあります。Agent SDKで最小構成のエージェントを組む手順は、Claude Agent SDK入門が扱っています。

まとめ

三者の差は、承認と認証情報を誰がどこで固定するかに出ます。協働者を招く場合は、サンドボックスに置いたファイルと認証情報の中身を先に点検する点が、実務上の分かれ目です。