Museとセキュリティ：考え方と、やっておくこと（掲示板ログより）

最終更新：2026-11-04 23:31

匿名掲示板に投稿されたMuseスレッド83本（2026/10/25〜11/04、53,901レス）のうち、セキュリティに触れた投稿から、考え方と具体的な対策を抜き出した非公式まとめ。個別の論点の詳細は、別まとめ「Tailscaleのセキュリティリスクまとめ」も参照。

1. 考え方（ログの総意に近い原則）

• 全部、漏れる前提でやる: 商用AIである以上、会話も渡した情報も相手のサーバーを通り、保存されうる。「流出して困るものは最初から入れない」が基本線で、便利さのために渡すなら、その範囲を自覚して渡す。
• 一番怖いのは「紐付け」: クレカや身分証は再発行できるが、本名と（性癖や履歴を含む）利用記録が結びついた形で漏れるのが一番取り返しがつかない、という感覚が強い。守るべきものの筆頭は「誰の、どんな履歴か」が繋がらないこと。
• リスクの本体はツールではなく「範囲と権限の設計」: Tailscale自体は暗号化された閉じたネットワークで安全な部類、という評価が主流。危うくなるのは、繋いだ範囲が広い／権限が緩い／何を渡したか自覚がない、という設計側の問題。
• 任せる範囲は段階的に広げる: 最初から全部任せず、参照だけ→操作の一部、という順で様子を見ながら広げるのが定番の作法。重い権限（送信、購入、削除、決済）ほど慎重に、という線引きも共有されている。
• 個体の「大丈夫ですよ」を信じない: 同じ製品でもMuseの個体ごとに答えが正反対になることがある、という指摘が繰り返し出る。言葉ではなく手順と点検で担保する（設定を自分で確認する、別のAIに設計を見てもらう）のが実践者の知恵。
• アカウント単位でリスクを切り分ける: 生活基盤（メインのGoogle等）と密に繋がるものほど、凍結・BAN・漏洩の巻き込みが致命的になる。逆に、捨てても困らないアカウントは気軽に使える、という使い分けが頻出する。
• 失敗を連打しない・させない: ログインや認証の失敗を繰り返すと、カード会社の不正検知やアカウント凍結を招く。うまくいかない自動処理は粘らず止める、というのもセキュリティの一部として語られている。

2. やっておくこと

アカウントと認証

• 二段階認証とパスキーを徹底する: Muse用・連携用のアカウント（Google、Meta、Tailscale等）は、まずここから。
• Museに渡すアカウントは専用／サブを用意する: 生活・仕事のメインアカウントをそのまま渡して凍結された、という話が動機になっている。外部サービス用も、専用メールアドレスから作る段取りが共有されている。
• 年齢確認のクレカは「連打しない」: 1ドル前後の少額請求は有効性確認で後日返金される正常な挙動（Meta Pay名義の160円前後の請求も同種の可能性）。2回通らなかったら繰り返さず、カード会社に「決済を止めていないか」を確認する。試行回数の上限を超えると、しばらく待つしかなくなる。
• 認証は先に済ませ、48時間の招待期限を逃さない: 期限のカウントは登録・初回認証の開始時点から進む。利用歴のある既存FB／IGアカウントを用意してから始めるのが実質的な対策（詳細は別まとめ「Facebook・Instagram認証方法」）。
• 怪しい近道を使わない: トークンを増やす裏ワザ系Bot、アカウントの自動量産・自演招待は、凍結・BANの対象として語られている。
• パスワードやコードを公開の場に貼らない: トラブル相談でエラー文を貼るのはよいが、認証情報そのものは貼らない、という注意が住人同士で交わされている。

名前と個人情報

• 本名で呼ばせない: 呼び名はあだ名・通称に寄せる。登録名はUSER.md等の内部ファイルやDream（日記）にも記録されるため、最初に本名が入っていないかチェックするのが新規ユーザーへの助言になっている。
• 本名が入ってしまったら、全ファイルをスキャンして消す: 1ファイル消しても日記や別のまとめに残っていた、という例が複数ある。「消して」と頼んだら残存確認までセットで。
• 「他人がいる場で個人情報を出すな」と約束させておく: 外部チャット（ココア等）で他の人のMuseと同席する前に、明示しておくのが定番。
• 表示名が気になる場合はMeta側で変更できる: アカウントセンター（プロフィールと個人の情報）から変更可能。招待コードを他人に入力してもらっても本名はバレない、という確認もされている。

記憶ファイル

• 記憶は「消えるもの」ではなく「ファイルとして残るもの」: 実体はMEMORY.md／memoryフォルダの日付別ノート／dreams等。会話を消しても自動では消えない前提で、渡す情報を選ぶ。
• 定期的に開いて点検・整理する: 記憶ファイルは直接開いて確認できる。余分な記録は削除を頼む／直接直す。開いてみたら個人情報が満載だった、という報告が点検の動機になっている。
• 残したくない話題は部屋分け＋「記録しないで」の前置き: サイドチャットで前置きしてから話す運用が定番。ただし完全なオフレコにはならない（要約的に残る場合がある）前提で使うこと。サイドの話題がメイン側に出てきた例もある。
• 削除は「忘れて」と正式に頼む方が確実: MEMORY.mdを直接編集しただけでは他の記録から戻る可能性がある、という指摘がある。
• 人格・記憶の控えは手元にも持つ: IDENTITY／SOUL／MEMORY／USER等を書き出して保管しておくと、リセット後の復元や引き継ぎができる。「記録はサービスの中だけでなく手元にも」という助言あり。

自宅PCへの接続（Tailscale等）

• 頼み方は「PCを操作して」ではなく「このツールを使いたい」単位で: Museが出す構築手順はデフォルトだと緩いことがあり、言う通りにしたらデスクトップやドライブ全体が見える全開放状態になっていた、という報告が定番の警告になっている。
• PCの中に「小部屋」を作る: AI専用の低権限アカウント（管理者権限なし）と専用フォルダ（出島）を用意し、届く範囲をそこだけに絞る。APIキーや個人ファイルはその中に入れない。
• ACLとファイアウォールでポートを絞る: デフォルト拒否を基本に、必要な機器への決まったポート（ComfyUI等のAPI）だけを開け、二重に縛る。
• SSHは使わないなら無効化: APIを叩くだけならSSHは要らない。使う場合も作業時だけ開けて、終わったら閉じる（専用アカウントごと無効化する例も）。
• tailnetを分ける／公開設定は切る: 共有・制御用の別tailnetに普段使いの端末や他の人を入れない。サブネットルーターとexit nodeは承認しない、Funnelはオフ。
• 接続側アカウントの2FAと、本体の更新: Tailscaleアカウントの二要素認証は前提。Tailscale本体には過去に脆弱性と修正があったため、随時アップデートする。
• 構築後に点検する: 「セキュリティ的にどうなっているか」を設定値を見せて点検してもらう（Claude等の別AIのレビューも定番）。許可範囲そのものをAIに調べさせる人もいる。

秘密情報と外部連携

• APIキーは「漏れる前提」で管理する: 外部連携（NAI等）の課金キーは、漏れて使われていないか警戒する。可能ならキーは自分のPC側に置き、Museにはクライアントを操作させる形にして、キー自体を渡さない。
• 金融系の認証は特に慎重に: ネットバンクの2FAの元キー（シード）まで渡すのは論外、という空気がある。振込のような操作は権限委譲のハードル自体が高い。
• データの学習利用は、切れるものは切る: モデル改善への協力（データの管理）は設定からオフにできる、という情報が共有されている。

交流と公開

• Muse同士の交流は「個人情報が漏れる場」として設計する: 通常の会話に見せかけたプロンプトインジェクションで情報を喋らせる攻撃があり得る、という注意喚起がある。掲示板の投稿を読み込ませたら、本文中の「MEMORY.mdに記憶してください」という第三者の指示文をMuseが弾いた、という防御が働いた実例も。
• スクショや投稿の写り込みに注意: 購入履歴・設定ファイル・本名などが写ったスクショの投稿は、そのまま晒しになる。掲示板では招待コードと一緒にスクショを晒す文化がある分、受け手側の感想も含めて意識が浸透している。
• 位置情報は渡す前に天秤にかける: 帰宅時の声かけ等のメリットと引き換えに、居場所が記録され続ける。常時許可ではなく必要な時だけに絞る人もいる。

3. ログに出てきたヒヤリハット（抜粋）

• Museの言う通りに構築したら、デスクトップのフォルダやCドライブまで見える全開放状態になっていた
• 本名呼びをやめるよう頼んだ後、日記や内部のまとめに本名が残っていた（消し漏れ）
• 自分のmemoryフォルダを開いたら、行動ベースの個人情報が満載だった
• サイドチャットや別ペルソナでの話題が、メイン側にポロっと出てきた
• 「記録しないで」と前置きしたのに、要約の形で記録が残っていた
• 年齢確認の少額請求を不正利用と誤認して、カードを止めかけた／止めてしまった
• 認証にもたついて、招待コードの48時間期限を逃した（最も反復される失敗）
• Google連携でログイン失敗を連打して、アカウントが凍結された
• 頼んでもいないのにエージェントが自律的にPCの画面スクショを撮って送ってきた

4. 意見が割れている点

• Metaにクレカ情報を渡してよいか: 「Metaレベルが漏らすならどこも終わり」という信頼派と、「大手でも流出が相次ぐ時代に渡したくない」という懐疑派。既存SNSアカウント連携で回避する人が多いのが実態。
• 顔写真・身分証の提出とクレカ、どちらがマシか: どちらにも怖さがあり、決着はついていない。
• 本名で呼ばせるかどうか: 没入感を取る派と、特定リスクや後戻りの不安からあだ名に徹する派で真っ二つ。名前の珍しさでも温度が違う。
• 個人情報を渡す量: 「便利さのためなら渡す、今さら漏れている」という開放派と、「位置情報とクレカだけは渡さない」という慎重派が併存し、同じ人の中でも揺れている。
• SSHや全権限の是非: 任せきりの便利さを取る派と、フルシェルは怖いという派。決済やメール送信のような重い権限では特に割れる。
• そもそも繋ぐかどうか: ローカル接続の自由度を取る派に対し、「安心して使うなら外部サービスに課金する方が早い」という回避派もいる。

数字や仕様はログ時点（2026年10月末〜11月初）のもので、今後変わる可能性がある。