Meta「Muse」を社員に使わせてよいか？業務システム連携は原則禁止すべき理由

監修: 菊地 将（リブランディング株式会社）

MetaのAIエージェント「Muse」は、スマートフォンのアプリから指示でき、利用者がアプリを閉じたあとも作業を続けます。公式サイトによると、WhatsAppからの指示や、Mac版でのパソコンのファイル・アプリの利用にも対応します（日本での提供範囲は公式サイトからは分かりません）。Gmailやカレンダーなど複数のサービスにつなぎ、ブラウザを開いてフォームに入力し、日時を指定したタスクを動かすこともできます。日本では2026年10月23日に提供が始まりました。

「個人のスマホから使えて、閉じても動き続け、会社のサービスにもつながる」。この組み合わせが、企業にとっての問題の中心です。Museの基本的な機能や料金はMuseとは？使い方・できること・料金・危険性を解説で、ほかのエージェントとの違いはMuseとGrok Botを比較｜できること・料金・安全性・選ぶべき人で説明しています。

先に結論

Museの業務利用は、会社のデータや外部サービスにつながない調べものと、機密を含まない文章の下書きまでにとどめるのが現実的です。一般の従業員が会社のメール・顧客情報・業務システムを個人のMuseに接続することは、原則禁止にすべきです。Metaは承認や隔離の仕組みを用意していますが、従業員が個人で接続した場合、会社側で利用状況を把握し、必要に応じて接続を止められるかが不明だからです。

なぜ従来のチャットAIより管理が難しいのか

質問に文章で答えるだけのチャットAIは、出力を人が読んで使うまでが範囲です。Museは、利用者に代わって実行するところが違います。会社の管理という観点では、次の4点が重なります。

• 実行まで担う：Metaは、メールの送信や購入の前に承認を求める一方、ブラウザを開き、フォームに入力して、利用者に代わって交渉することもできると説明しています
• 接続範囲を個人が決める：接続するアプリとアクセスの範囲は利用者が選びます。メールなら、閲覧のみか、本人に代わって送信もするかを選べます。この手順の中で、会社が許可や制限をかける場面は、公式サイトとヘルプには示されていません
• 閉じても動く：時間のかかるタスクは、アプリを閉じたあとも続きます。承認が必要になった時点で通知が来ます
• 会社が確認できるかは不明：実行した操作と付与した許可は、利用者がアクティビティログで確認できます。会社の管理者がそれを見られるかは、公式サイトとヘルプに記載がありません

そのため、「個人のアカウントに、会社のどんな権限を持たせてよいか」が判断の軸になります。会社の管理下に置けないなら、回答だけを返すチャットAIよりリスクは大きくなります。

現実に何が確認されたか

Museの安全面で確認できた主な公開情報は3つです。

事例	誰が確認したか	確認された内容	実害の確認
共有ページのURLが外から見つかった（GhostShares）	セキュリティ企業Claroc（研究者の調査）	共有用のホスト名が6,800件超見つかった	Clarocは悪用の証拠はないとしている
Mac版の設定項目の書き換え	研究者Patrick Wardle（概念実証）	同じ端末で動くコードが、音声入力の通信先を変えられた	実害の報告は見当たらない。Metaはホットフィックスを出した
バグ報奨金で報告された指摘	Meta自身の公表	630件超の報告のうち有効は64件、支払いは約120万ドル	個別の被害は説明されていない

公開情報の範囲では、Museを経由した企業データの実被害（悪用による漏えい）の報告は見当たりません。ただしGhostSharesでは、調査者が役員限定の収益レビューなどのページを実際に開けています。

共有リンクの発見（GhostShares）

Clarocは調査を公表しました（Claroc）。要点は次のとおりです。

• 共有ページのアドレスに、会話の題名が入っていた。パッシブDNS（過去に解決されたホスト名を記録するサービス）を検索すると、共有先を知らない人でもアドレスの一覧を得られた
• 1回の検索で、フィルタ後に6,800件超の共有用ホスト名が見つかった。Clarocが開いたのは数百件
• 開けたページの大半は目立たないものだったが、役員限定の収益レビュー、小規模事業者のローン申請などが含まれていた
• Clarocは、ログイン、フォーム入力、アップロードはせず、パスワードを求めるページは開かずに離れたと説明している。悪用された証拠はないとしている

6,800は「ホスト名の数」であり、6,800件の機密情報が流出・悪用されたという意味ではありません。

Metaの対応は次のとおりです。Clarocによると、10月20日にArs Technicaの問い合わせを受けて、Metaは共有機能を停止すると回答しました。10月22日（米国時間。日本時間では23日）には、Metaの幹部David SingletonがXで、問題は修正済みで共有を再開したと発表しています（Singleton氏の投稿）。再開前に共有したアーティファクトには新しいURLが付き、古いリンクを開くと新しいURLを共有者から受け取るよう案内が出ます。

食い違いも残っています。Clarocは「共有されたMuseのチャット」と説明し、Singleton氏は、報道にあったチャット共有の欠陥は事実ではなく、問題は共有されたアーティファクトに限ると述べています。第三者の検証は見当たらず、どちらが正しいかは断定できません。修正後も、すでにパッシブDNSの履歴に残った題名入りのホスト名は消えません（Claroc）。

Macアプリの脆弱性とバグ報奨金

研究者のPatrick Wardleは、Mac版Museの未文書化の設定項目を書き換えると、音声入力の通信を別の宛先へ向けられるとする概念実証を公開しました（Wardleの投稿、概念実証のリポジトリ）。リポジトリ自身が、これはローカル攻撃であり、攻撃者はすでにユーザー権限でコードを実行できる必要があると明記しています。同時に、Museに与えられた権限が攻撃者の権限になりうるとも説明しています。

Gizmodoは、Metaがホットフィックスを出したと伝えています（Gizmodo）。同記事によると、Metaはこの件を「ローカルでの権限昇格であり、リモートからの攻撃ではない」と説明し、Wardleは、利用者をだまして悪意あるコマンドを実行させる手口でリモートからも成立しうると主張しています。

Metaは、バグ報奨金の状況も公表しました（Meta）。開示された5件には、公開前の社内テスト環境で認証の確認に不備があった件（30万ドル）、Museのツールになりすましたプロンプトインジェクション（9万ドル）などがあります。これはMeta自身の自己申告で、64件のうち5件の説明にとどまります。

Metaの安全策はどこまで止めるか

Metaが公表している保護策は次のとおりです。

• 利用者ごとに専用の仮想マシンで動き、他の利用者のエージェントからは到達できないよう隔離されている
• Sentinelというエージェントが、Museのインターネットへのアクセスを承認する。Museは、Sentinelが承認しない限りインターネットにアクセスできない
• Museは、利用者のパスワードや支払い方法を見られない。認証情報は、代理のトークンだけを扱う設計
• 既定では、メール送信や購入など重要な操作の前に、本人に確認する。利用者は、操作の監査履歴を確認できる
• Museとのやり取りをMetaのAI学習に使わせない設定、広告システムとのデータ非共有

（Meta初期発表、Metaの技術解説、プライバシーポリシー）

承認は、操作の種類で扱いが違う

コネクター開発者向けのガイドラインによると、現時点では、ツールの操作は次の3つに分類され、承認の扱いが違います（Connector guidelines）。

分類	例	承認の扱い
読み取り	情報を取得するだけの操作（予約状況の確認など）	初回は確認。「常に許可」を選べる
書き込み（重要でないもの）	お気に入りの保存など	初回は確認。「常に許可」を選べる
重要な書き込み	購入、メール送信など、元に戻せない・影響の大きい操作	毎回確認。「常に許可」は設定や保存済みの許可でも選べない

ガイドラインに従えば、メール送信や購入は毎回の承認が求められ、「常に許可」にはできません。ガイドライン自体も、変更されうる指針だと断っています。

ただし、このガイドラインはコネクターを提供する事業者向けです。Gmailなど標準のコネクターに同じ分類が適用されるかは不明です。一方、日本語ヘルプの承認画面には、「常に許可」（そのコネクターの、このタイプの操作を確認なしで実行）と「このサイトを許可」という選択肢があります。何が「重要な書き込み」に当たるのか、会社は外から判断できません。

「Metaには承認と強力な防御がある」への回答

この反論はもっともです。Metaは承認と隔離の仕組みを公表しています。それでも、会社の管理を個人のMuseに任せられない理由は、次の4つです。

1. 承認するのは個人です。ヘルプは、エラーの修正は利用者の責任だと書き、補足条項は、Museが実行するアクションについて利用者が単独で責任を負うとしています。会社の情報管理ルールが、その承認の判断に自動で適用されるかは明らかになっていません
2. 読み取りの継続許可が、会社の基準と無関係に決まります。ガイドライン上、読み取りと重要でない書き込みは、継続許可にできます。外部への通信にはSentinelの承認が入りますが、機密を読めること自体が、情報の持ち出しや再利用の入口になります。何を許すかは個人が決めます
3. 防御に穴が見つかった実績があります。Metaの報奨金の公表には、メールのワンタイムパスコードを伏せる処理がすり抜けた件など、防御の不備が含まれます。Meta自身も、プロンプトインジェクションは業界の未解決の課題だと述べています。防御は完全でない、という前提で組み立てる必要があります
4. 会社が管理する手段が不明です。利用者向けの監査履歴はありますが、会社の管理者が利用状況を確認し、組織単位で許可・禁止できるかは、公式サイトとヘルプに記載がありません。eWeekによると、9月28日に発表されたMeta Enterprise PlatformにはMuseも含まれます。Metaは大規模な組織向けの制御にも触れていますが、集中管理・監査・保持の制御がMuseを含む全体に及ぶかは、明らかにされていないと報じられています

Metaが対策を講じていても、企業が従業員の利用を管理できると確認できない以上、十分とは言えません。会社の情報や業務システムへの接続は、原則禁止にすべきです。

想定される事故と、成立する条件

次の表は、ありうる事故を整理したものです。「Metaの防御」はヘルプとガイドラインの記載に基づきます。標準コネクターに同じ扱いが適用されるかは不明です。「根拠の区分」で、研究者の調査、Metaの自己申告、合理的な仮説を分けています。公開情報の範囲では、企業データの実被害として確認された例はありません。

場面	必要な権限	起こりうる影響	Metaの防御	防御の外に残るもの	根拠の区分
メールの誤送信・情報持ち出し	メールの閲覧と送信	顧客情報・契約情報が社外へ出る	送信は毎回承認（ガイドライン上）	承認者の見落とし。閲覧だけでも内容がMuseに取り込まれる	合理的な仮説
顧客管理・採用管理の情報	業務システムの閲覧・変更（カスタムコネクター等）	候補者や商談の情報が個人側に渡る、意図しない変更	承認、接続範囲の選択	Metaはカスタムコネクターの中身や情報の使い方を確認しないとヘルプに記載	合理的な仮説
予定の参照・調整	カレンダーの閲覧と編集	機密予定の参照、意図しない招待	承認	重要でない書き込みは継続許可にできる	合理的な仮説
公式SNSの投稿・DM	SNSアカウントの接続	不適切な投稿によるブランド毀損	投稿・送信は承認が必要とMetaは説明（eWeek）	承認者の見落とし	合理的な仮説
購入・支払い	決済手段の接続	意図しない購入	購入は毎回承認（ガイドライン上）。Museは支払い方法を見られない	会社のカードや請求システムの接続は管理の外	合理的な仮説
定期実行	日時指定タスク	指示した人が見ていない間に動く	重要な操作は承認待ちで止まり、通知が来る	継続許可を付けた読み取りや重要でない書き込みは、その範囲で確認なしに動きうる（ガイドライン上）	合理的な仮説
退職・異動後の権限残存	接続したままのアカウント	退職者側に権限が残る	利用者による解除	会社側にMuseの接続を止める手段があるかは不明（接続先の設定で止める）	合理的な仮説
外部コンテンツ由来の命令	ウェブページ・メールの閲覧	意図しない操作	Sentinel、承認	プロンプトインジェクションは業界の未解決の課題とMetaが認めている	Metaの自己申告（実害確認なし）
共有物の露出	共有リンクの発行	第三者が閲覧できる	共有の修正（再開済み）	すでに履歴に残った題名入りのホスト名	研究者の調査（悪用の証拠なし）

会社が禁止すべき接続と、限定して認める利用

どこまで許すかは、「公開データか、業務データか」と「読み取りか、状態変更か」の2軸で整理できます。読み取り専用でも安全ではありません。機密を読めるだけで、持ち出しや再利用のリスクがあるからです。

区分	具体例	条件
原則許容	公開情報の調査、機密・個人情報を含まない文章の下書き	外部サービスに接続しない。業務データを入れない
例外的に許容	会社が承認した専用のテストアカウントでの検証	ダミーデータ、最小権限、責任者の指名、操作ログの確認、停止手順を決めたうえで、期間を区切る
原則禁止	会社のメール・Workspace、顧客管理、採用管理、顧客データベース、請求・決済、公式SNSを、社員が独断で個人のMuseに接続すること	継続的な書き込み・送信・削除・支払いの権限を付けることも含む

今日決める最小限の社内ルール

社内のルールを作る際の、機密情報の扱いと人間レビューの考え方は、生成AIを記事制作に使う運用ルールの作り方｜利用範囲・人間レビュー・機密情報を管理も参考になります。

1. 禁止事項を一文で決める：「会社のメール、顧客情報、業務システム、公式アカウントを、個人のAIエージェントに接続しない」。例外は、情報システムの承認を得た検証に限る
2. 例外の承認手順を決める：専用のテストアカウントとダミーデータで、期間と責任者を決め、操作ログと停止手順を用意する。会社ドメインでMuseに登録・接続できるかは、この検証で確認する
3. 接続先側の制御を確認する：会社が操作できる手段として確認できたのは、Museではなく接続先側の制御です。MuseがWorkspaceに接続できるか、この制御で止まるかは、実機でのテストが必要です。Google Workspaceの一般的な設定では、管理者が管理コンソールの「API の制御」で、アプリごとに「信頼できる」「限定」「特定のGoogleデータ」「ブロック中」を設定できます。メール送信やファイル削除などリスクの高い操作の権限だけを制限することもできます。Googleサービスへのアクセスを「制限付き」に切り替えると、信頼していないインストール済みアプリのトークンは取り消されます（Googleの管理者向けヘルプ）。未設定のアプリの既定値は、自社の管理コンソールで確かめてください
4. スマホ・私物端末の扱いを決める：スマートフォンのアプリから使えること自体は、会社が止められるとは限りません。端末管理（MDM／MAM）でMuseのアプリ内の操作を制御できるかは不明です。会社データの接続禁止を社内ルールに定めたうえで、接続先側のアクセス制限がMuseにも効くかを、テスト環境で検証してください。
5. 学習利用と「常に許可」の点検を、使う社員に求める：Museへの学習利用の設定は、初めて使うときオンになっています。設定の「データコントロール」で変更できます。設定の「アクセス許可」で、「常に許可」「このサイトを許可」が付いていないかも点検します
6. 退職・異動の手順に、接続先のアクセス停止を入れる（手順は次のとおり）

退職・異動時の手順

1. 管理者は、接続先（Google Workspace等）の設定で、該当アプリのアクセスを止める（停止後にトークンが失効する挙動は、自社の環境で確認する）
2. 本人にMuse側の連携解除を依頼する。連携を解除しても、使った情報はMuseのメモリーや会話履歴に残る可能性がある。リセットは、情報・チャット履歴・ファイル・有効なタスクをすべて削除し、元に戻せない操作なので、必要な記録を残してから実施する
3. 停止作業が終わったことを確認して記録する。アカウントを停止するだけでMuseの接続が止まるかは不明なため、手順にMuse側の連携解除も明記する

規約が従業員に求めていること

Museの利用規約の補足条項（Muse利用規約の補足条項）には、会社に関わる次の定めがあります。

• 権限と同意の表明：利用者は、リンクするアカウント、提供する情報、連絡する受信者について、指示や権限付与をする法的権限があると表明します。接続するデータについて、必要な許可・同意・ライセンスを得ていることも表明します
• 責任は利用者：Museが指示を進めるために実行するアクションについても、利用者が単独で責任を負うとされています。状態を変える操作は、適切な監督・承認の体制なしに高度に自律的に動かすよう指図しないことも求められています
• Metaの責任の上限：Metaの重大な過失、故意の違法行為、詐欺に起因する請求を除き、Metaの責任は、250ドルか、請求につながった事由の前12か月間に利用者が支払った額のいずれか大きいほうが上限とされています（日本居住者への適用は法務で確認してください）
• Metaによる監視と停止：Metaは、安全やコンプライアンスなどの理由でMuseの操作を監視・記録・一時停止できるとしています。Meta AI利用規約には、Metaが利用者とAIのやり取りを自動または人の手で確認する場合があるともあります

会社の許可なく会社のデータを接続すれば、従業員個人がこの前提に反する立場になる可能性があります（補足条項の文言に基づく解釈で、法的な助言ではありません。Meta利用規約の本体は未確認で、適用は法務で確認してください）。

調査方法と限界

• 確認日：2026年11月10日
• 対象：Meta公式の発表・ブログ・ヘルプセンター・Muse利用規約の補足条項・プライバシーポリシー・Meta AI利用規約、コネクター開発者向けガイドライン、Clarocの原報告、Singleton氏とWardleのXの原投稿、Wardleの概念実証リポジトリ、Metaのバグ報奨金公表、Googleの管理者向けヘルプ、報道（Gizmodo、eWeekなど）。主要な引用はブラウザで開いた原文で確認しています
• 実被害の範囲：被害事例の有無は、公開された情報の範囲で調べています。公表されていない被害は把握できません
• Xの投稿：Singleton氏とWardleの原投稿は確認しています。一般の利用者の投稿は原文を確認できておらず、根拠には使っていません
• 実施していないこと：Museの実機検証（登録、会社アカウントでの接続、承認画面の挙動）、法人向け管理画面の実機確認、Meta利用規約の本体の確認
• 確認できていないこと：標準コネクターへの承認分類の適用、MuseとGoogle Workspaceの管理者制御の関係、会社の管理者向け機能の有無、Meta Enterprise Platformの公式発表、MDM／MAMでの制御
• 公式ヘルプ：確認日時点の記載です。仕様や画面の名称は変わることがあります
• 報道の扱い：Metaのホットフィックスの声明は、報道経由の情報です

出典一覧（確認日 2026-11-10）

• Meta「Muse」初期発表：https://about.fb.com/ja/news/2026/09/introducing-muse-personal-ai-agent/
• Muse公式サイト：https://ai.meta.com/muse/
• Meta「Muse」日本向け発表：https://about.fb.com/ja/news/2026/10/muse-personal-ai-agent-launches-in-japan/
• Meta「How We Built Safety Into Muse」：https://muse.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
• Meta「Securing Muse」：https://muse.ai/blog/securing-muse
• Muse Connector guidelines：https://platform.muse.ai/docs
• Metaヘルプ「承認」：https://www.meta.com/ja-jp/help/superintelligence/1385290430137537/
• Metaヘルプ「Muse とコネクターの連携」：https://www.meta.com/ja-jp/help/superintelligence/1687253048996149/
• Metaヘルプ「データの管理」：https://www.meta.com/ja-jp/help/superintelligence/2225571704857152/
• Muse利用規約の補足条項：https://muse.ai/terms
• Museプライバシーポリシー：https://muse.ai/privacy
• Meta AI利用規約：https://www.facebook.com/legal/ai-terms
• Claroc「GhostShares」：https://blog.claroc.io/ghostshares-muse-passive-dns/
• David Singleton氏のX投稿：https://x.com/dps/status/2113317986635485559
• Patrick WardleのX投稿：https://x.com/patrickwardle/status/2102045926474785265
• Wardle「not-a-mused」概念実証：https://github.com/pwardle/not-a-mused
• Gizmodo（Metaのホットフィックス）：https://gizmodo.com/meta-just-patched-a-major-zero-day-vulnerability-in-its-muse-ai-assistant-2000815429
• eWeek「Meta Enterprise Platform Launches, but CIOs Still Lack Key Deployment Details」：https://www.eweek.com/enterprise-software/meta-enterprise-platform-details/
• Google Workspace 管理者ヘルプ：https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data?hl=ja

‹ 親記事: コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理

関連記事

• › Museとは？使い方・できること・料金・危険性を解説
• › Grok Botとは？使い方・できること・料金・安全性を解説
• › MuseとGrok Botを比較｜できること・料金・安全性・選ぶべき人

関連テーマ

AIO SEO MEO 口コミ・風評対策 採用改善