こんにちは。AI・ノーコード開発を手がける成長支援カンパニーWalkersです。
AI活用のご相談では、Muse(ミューズ)のように、メールの送信や買い物まで任せられるエージェントについて、「セキュリティは本当に安全なのか」という点が導入判断の大きな論点になります。
Museは、Metaが2026年9月8日に米国で発表し、日本では2026年10月23日に提供が始まったパーソナルAIエージェントです。メールの送信のように取り消せない操作も任せられると聞くと、意図しない送信や操作が起きないか、心配になりますよね。
実は、Museのセキュリティは決して弱くありません。むしろ適切に設定すれば、強固なセキュリティ体制を実現できます。
そこで今回は、Museのセキュリティについて以下の内容を解説していきます。
- Museのセキュリティが安全な7つの理由
- 代表的なMuseのセキュリティ設定
- セキュリティが安全でも情報漏洩が起きる理由
- セキュリティを万全にするための解決策
Walkersでは「AIを用いたシステム開発のノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAI開発×補助金支援を行っています。⇒サービス概要はこちら

執筆者:山口 鳳汰
累計100万PV以上のAI・ノーコード開発メディアの編集長。
アプリ開発の電子書籍を3冊出版し、1冊はAmazonベストセラーを獲得。
その他、受託開発や教育など多数のノーコード事業に参画している。

運営会社:株式会社Walkers
AI・ノーコード開発を手がける成長支援カンパニー。
300件以上の開発/制作実績、200件以上の企業様を支援。
マーケティングやUI/UXと掛け合わせたサービス開発を得意としている。

執筆者:山口 鳳汰
累計100万PV以上のAI・ノーコード開発メディアの編集長。
アプリ開発の電子書籍を3冊出版し、1冊はAmazonベストセラーを獲得。

運営会社:株式会社Walkers
AI・ノーコード開発を手がける成長支援カンパニー。
これまでに300件以上の開発/制作実績、200件以上の企業様を支援。
Museのセキュリティは安全なのか?

結論から言うと、公式に公開されている設計は「Museは間違えるし、攻撃もされる」ことを前提に組まれています。
Museは、利用者ごとに用意された専用の仮想マシン「Muse Secure VM」の中で動きます。つないだサービスへの操作とインターネットへの通信は、Museとは別の「Sentinel(センチネル)」というエージェントが管理します。
※仮想マシンとは「クラウド上に用意された、利用者専用の1台分のコンピューター」を指す。
Metaの説明から整理すると、対策の柱は次の4つです。
- 利用者ごとに分けた専用の仮想マシンで動く
- インターネットへの通信は、Museとは別のSentinelが管理する
- Museは利用者のパスワードや支払い方法を確認できない
- メールの送信や商品の購入など、重要な操作の前には本人に確認する
なお、Museは2026年10月23日から、日本でiOS、Android、muse.aiで使えるようになりました。本記事は2026年11月4日時点の公式情報にもとづいています。Museは更新が速いため、導入前に最新の公式情報もあわせてご確認ください。
»出典:Meta日本の発表
Museのセキュリティが安全と言える7つの理由とは?

ここからは、Museのセキュリティが安全と言える理由を、Metaの公式発表、ヘルプセンター、プライバシーポリシー、技術解説の記載にもとづいて7つ紹介します。
【理由①】利用者ごとの専用仮想マシンで分離して動く

Museの土台は、利用者一人ひとりに割り当てられる専用の仮想マシンです。技術解説によると、これはブラウザを備えた、隔離されたLinuxの環境です。各利用者の仮想マシンは独立しているため、他の人のエージェントがアクセスすることはできないと、プライバシーポリシーにも書かれています。
仮想マシンの内側も、2つの領域に分かれています。Museとその作業ファイルが動く領域と、安全を守る仕組みが動く領域です。
前者は信頼できないデータを処理する前提の領域で、後者はその外側に置かれています。安全の判定を担う独立したモデルや分類器も作業領域の外で動くため、攻撃者がこれらの保護を無効にすることはできない、と技術解説は説明しています。
ここで押さえておきたいのは、「分離されている」ことと「Metaに何も送られない」ことは別だという点です。技術解説は、推論とテレメトリのために、必要に応じて仮想マシンから限られたデータが外へ送られると明記しています。
※テレメトリとは「サービスの稼働状況や使われ方を、提供元へ自動で送る記録」を指す。
»出典:Meta公式の技術解説「How We Built Safety Into Muse」
【理由②】外への操作と通信を、別のエージェント「Sentinel」が判断する

仮想マシンの中には、Museとは切り離されたSentinelが置かれています。Sentinelは、つないだサービスへの操作と、ネットワークの外への通信について、許可を出せる唯一の仕組みです。
Museは「この操作をしたい」と提案するだけで、許可を出せるのはSentinelだけです。許可の判断は、利用者が設定したルールにもとづいて、許可、拒否、利用者への確認のいずれかになります。
通信についても、接続先のホスト名やIPアドレス、通信の種類などを確認してから、外に出すかどうかを判断します。
確認が必要なときは、Museとの会話の中ではなく、アプリの画面に直接確認の画面が表示されます。利用者の答えは、Sentinelに直接戻ります。
»出典:Meta公式の技術解説「How We Built Safety Into Muse」
【理由③】パスワードや鍵そのものをMuseに見せない

Metaは、Museは利用者のパスワードや支払い方法を確認できないと説明しています。
仕組みはこうです。Museが持つのは本物ではない代用の札だけで、外のサービスへの通信が許可されたときに、Sentinelが本物の認証情報に差し替えます。技術解説は、Museをだまして鍵を言わせようとしても意味がない設計だとしています。
ブラウザでログインが必要なときも、ユーザー名とパスワードは専用の入力画面から安全な保管場所へ直接送られ、主役のエージェントには見えません。入力の間、ブラウザ操作のエージェントは一時停止します。
また、メールのコネクターは、一度きりの確認コード、パスワード再設定のリンク、ログイン用のリンクを除外します。メールが他のサイトのパスワード再設定に使われうることを踏まえた設計で、ルールと分類モデルの両方で除外しています。
※コネクターとは「Museがメールやカレンダーなど、外部のサービスを読んだり操作したりするための接続口」を指す。
»出典:Meta公式の技術解説「How We Built Safety Into Muse」
【理由④】重要な操作は承認を求め、購入は内容を示して確認する

Museは、メールの送信や商品の購入のような重要な操作の前に、利用者本人に確認します。確認が必要になると、実行はいったん止まり、承認を待ちます。
承認は、会話上の提案ではなく、特定の接続先と用途に結びついた許可として扱われます。1回だけ、そのセッションの間、そのタスクの間、期限つき、恒久的、といった範囲から選べて、次回以降も許可された範囲に一致する操作だけが通ります。
購入では、決済画面を検知して、購入内容の詳細を示した承認を毎回求めます。Museの中にはウォレットがあり、Stripe Linkと提携して、使い捨てのカード番号を発行します。このカード番号は特定の店と金額にひも付き、有効期間も限られます。ただし、Stripeの発表では、Linkでの決済は米国の利用者が対象とされています。日本での提供の有無は、日本向けのMetaの発表には書かれていません。
ただし、読み取りだけの操作、すでに許可した操作、リスクが低いと判断された操作は、確認なしで進むことがあります。「すべての操作に確認が出る」わけではない点は、押さえておきたいところです。
»出典:Meta公式の技術解説「How We Built Safety Into Muse」、ストライプジャパン「Stripeのデジタルウォレット「Link」で、Metaの新たなAIエージェント「Muse」の決済が可能に」
【理由⑤】読み取りと書き込みを分けて、権限を絞れる

Museは、必要のない権限を渡さない「最小権限」の考え方で作られています。技術解説が挙げる例が、APIキーです。モデルはAPIキーを見る必要がないので見せず、うっかり漏らすこともできません。
多くのサービスでは、読み取りと書き込みを分けられます。「カレンダーを読んで予定の重なりを教えて」は任せられても、「新しい会議を入れて」は動きを見てからにしたい、という人が多いためです。Museは、サービス側が対応していれば、読み取りと書き込みを分けて許可できます。
たとえば、Gmailの読み取りの権限を渡した場合でも、通常それに付いてくるGmailの設定へのアクセスは外せる、と技術解説は例示しています。
組み込みのコネクターの処理そのものも、Museの作業領域の外で、必要な認証情報だけを持つ別の仕組みが実行します。カレンダーを扱う仕組みが、メールの認証情報を要求することはできません。
»出典:Meta公式の技術解説「How We Built Safety Into Muse」
【理由⑥】プロンプトインジェクション対策を多層で行い、バグ報奨金も公開している

Museはメールやウェブページを読んで作業するため、悪意ある指示文が紛れ込む可能性を避けられません。
※プロンプトインジェクションとは「AIが読み込むメールやウェブページの中に悪意ある指示文を紛れ込ませ、本来の指示とは違う動きをさせる手口」を指す。
そこでMetaは、1つの対策に頼らない多層防御を採っています。技術解説が挙げる対策を、ここでは次の3つの層にまとめて紹介します。
- モデルの訓練:紛れ込んだ指示を見抜き、従わないように訓練している
- ハーネス(Museを動かす基盤)側の保護:外部から入る情報を信頼できない入力として扱い、複数の検知用の分類器で検査する
- 仮想マシン側の境界:作業領域の制限、権限の分離、Sentinelによる全操作・全通信の評価が、Museが誤った動きをしても効く
ブラウザ操作では、ページや画像、ダウンロードしたファイルへの指示文の紛れ込み、リスクの高いフォームの送信などを見張る分類器が動きます。検知の内容に応じて、操作を止めるか、利用者に確認します。
さらにMetaは、2026年9月8日にバグ報奨金プログラムを誰でも参加できる形で公開しました。有効な報告には最大30万ドル、利用者1人に影響するプロンプトインジェクションの成功には最大13万ドルが支払われます。
»出典:Meta公式の技術解説「How We Built Safety Into Muse」
【理由⑦】データの扱い(広告・学習・削除)が明示され、自分で管理できる

Museのプライバシーポリシーには、Museは利用者の会話や仮想マシンのデータをMetaの広告システムと共有しない、と書かれています。アカウントセンターに別のMeta製品が含まれている場合でも同じです。
MetaのAIモデルの開発や改善にやり取りを使うかどうかは、利用者が決められます。ただし、この設定はMuseを初めて使うときにオンになっています。[設定]の[データコントロール]でいつでも変更でき、変更は過去のやり取りにも適用されます。
オンのままでも、名前、メールアドレス、電話番号などの個人情報は削除され、やり取りとアカウントの関連付けも解除されると説明されています。
送信したメッセージやサイドチャット、仮想マシン内のファイルは削除でき、すべてをやり直すリセットも用意されています。
»出典:Museプライバシーポリシー
ここまでを整理すると、Museでは
- 利用者ごとの専用仮想マシンと、別のエージェントSentinelによる許可の管理
- パスワードや鍵をMuseに見せない仕組みと、承認のルール
- 読み取りと書き込みを分ける最小権限と、多層のインジェクション対策
- 広告・学習・削除についての明示と、バグ報奨金の公開
といった形で、複数の層でセキュリティが設計されています。

\特典:最適な開発方法をご提案/
Museで設定できる主なセキュリティ機能とは?

Museは、利用者側でも安全性の水準を調整できます。代表的な設定は次の4つです。
① アクセス許可(承認を求める頻度の設定)

[設定]の[アクセス許可]で、コネクターとウェブアクセスのそれぞれについて、Museが許可を求める範囲を決めます。
コネクターは、すべての書き込みアクションと重要な読み取りアクションの前に許可を求める設定か、アクションの前に常に許可を求める設定を選べます。ウェブアクセスは、情報が共有される可能性があるときや見慣れないウェブサイトにアクセスするときに求める設定か、ウェブサイトにアクセスする前に常に求める設定です。
許可を求められたときの答えは、「1回だけ許可」「このタスクを許可」「このサイトを許可」「常に許可」「却下」から選びます。迷ったら「1回だけ許可」にしておくと、次回も確認が届きます。
»出典:Metaヘルプセンター「Museがあなたのガイダンスと承認に基づいて機能する仕組み」
② コネクターの選択と読み取り専用化(アクセスできる範囲の制御)

Museがつなぐサービスは、利用者が選びます。[設定]の[コネクター]から接続し、いつでも切断できます。
多くのコネクターは、データの取得だけを許し、カレンダーの招待の送信のようなアクションは禁止する設定にできます。Museに「Gmailをリンクして」と頼んで接続することもできます。
切断すると、Museとコネクターのデータ交換は止まります。ただし、それまでの作業で使った情報は、Museの記憶や会話履歴に残る場合があります。
»出典:Metaヘルプセンター「Museとコネクターの連携」
③ アクティビティログと作業の確認(作業の監視と停止)

画面上部のアシスタントのアバターが、「作業中」「何かを作っています」「メモリーを更新中」など、Museの状態をリアルタイムで知らせます。
アシスタントのアイコンからは、Museが実行したアクションと、あなたが付与した許可の時系列の記録(アクティビティログ)を確認できます。[今後の予定]では、日時指定のタスクやリマインダーを確認できます。
一部のアクション(ウェブサイトの読み込みや、購入前の価格比較など)は、チャットで元に戻したり、止めたりするよう指示できます。ただし、メールの送信のようなアクションは、自分で行った場合と同じで、元に戻せません。
»出典:Metaヘルプセンター「Museがあなたのガイダンスと承認に基づいて機能する仕組み」
④ データコントロール(学習・記憶・削除の管理)

[設定]の[データコントロール]では、[AIモデルの改善にご協力ください]をオフにできます。[Museのデータをダウンロード]でチャットやファイルのコピーを取得でき、[Museをリセット]では、チャット履歴、ファイル、アクティブなタスクなどをすべて削除できます。リセットは元に戻せません。
Museの記憶は、アシスタントのアイコンから[Identity]、[Memory]の順に開くと、Memory.mdとして直接編集・削除できます。チャットで「この話題は忘れて」と頼むこともできます。
ただし、データを削除した後も、Museは削除したものから学習した情報を覚えている場合があると、公式は注意しています。
»出典:Metaヘルプセンター「Museのデータを管理する方法」
セキュリティが強くても情報漏洩が起きるのはなぜか?

ここまでの通り、Museは安全性を重視して設計されています。しかし、それでも情報漏洩のリスクが完全になくなるわけではありません。どれだけサービス側の仕組みが強固でも、最終的なリスクは、何をつなぎ、何をどこまで任せるかという使い方と運用で変わるためです。
実際、Metaの技術解説でも、次のように述べられています。
Muse isn’t immune to attack. Prompt injection remains an open problem in the industry …
(Museは攻撃と無縁ではありません。プロンプトインジェクションは、業界全体で解決されていない問題です。)
ヘルプセンターも、利用者の責任について同じ姿勢です。
しかし、完璧な自動システムは存在しません。Museはあなたに代わって行動するため、Museのアクションを注意深く導き、承認する責任はあなたにあります。
公式資料から読み取れる、残る点は次のとおりです。
- 現在の仕組みでは、サービスの提供や保護、運用に必要な場合に、Metaがデータへアクセスすることは防げない
- 暗号技術を使って、Metaからも仮想マシン内のデータにアクセスできないようにすることを目指す「Muse Confidential VM」は、2026年内の提供が予定されているとされ、本記事の確認時点では利用できる旨の案内は見つけられなかった
- AIモデルの改善に使う設定は、初めて使うときにオンになっている
- Museのブラウザ操作は利用者自身の閲覧として扱われ、訪問先の事業者が、その訪問をもとにした広告を出すことがある
- メールの送信など、実行すると元に戻せない操作がある
つまり、「ツールが安全かどうか」だけでなく、「どう使うか」が重要ということです。
»出典:Meta公式の技術解説「How We Built Safety Into Muse」
Museで実際に見つかった欠陥の中身と対策をさらに詳しく知りたいという方は、Museのセキュリティ事故事例2選|対策まで完全解説ですべて解説しているのでそちらをご覧ください。

注意すべきポイントは何か?

Museを安全に利用するためには、特に以下の点に注意が必要です。
① 「常に許可」で承認を広げすぎてしまう

「常に許可」を選ぶと、今後Museはそのコネクターに対して、同じ種類のアクションを再度の確認なしに実行します。「このサイトを許可」も同様に、そのサイトでの同じ種類のアクションが確認なしになります。便利な反面、許可の範囲がそのまま事故の範囲になります。
避けたいのは、次のような運用です。
- 慣れる前から、コネクターもウェブアクセスも「常に許可」で運用する
- 見慣れないウェブサイトにまで「このサイトを許可」を出す
- いったん出した許可を見直さず、そのまま放置する
最初は「常に確認」にして、Museの動き方をつかむのが安全です。コネクターごとの許可や許可したウェブサイトは、[設定]の[アクセス許可]から確認や取り消しができます。
»出典:Metaヘルプセンター「Museがあなたのガイダンスと承認に基づいて機能する仕組み」
承認を広げたことで実際に起きた失敗は、Muse活用の失敗事例6選|誤った予約・住所の送信・買い物の制限の原因と対策を完全解説!でまとめておりますので、そちらをご覧ください。

② つなぐサービスを広く開けてしまう

Museは、つないだサービスから、作業に必要な情報を受け取ります。接続の広さが、そのままMuseが触れる情報の広さになります。
切断しても、それまでに使った情報はMuseの記憶や会話履歴に残る場合があるため、「後で外せばよい」とは考えず、最初から必要なものに絞って始めましょう。Facebook、Instagram、Threadsは、同じアカウントセンターにアカウントがあれば自動でリンクされる点にも注意が必要です。
一覧にないサービスは、Museにカスタムコネクターの作成を依頼できます。この場合、Metaはカスタムコネクターや、その情報の使われ方を確認しないと明記されています。
- 最初は、業務に必要なサービスだけをつなぐ
- 読むだけで足りるサービスは、データの取得のみに制限する
- カスタムコネクターは、提供元のプライバシーポリシーを確認してから許可する
»出典:Metaヘルプセンター「Museとコネクターの連携」
③ 信頼できない外部の内容や、秘密情報をそのまま触れさせてしまう

Museは、メールやウェブページ、ファイルを読んで作業します。その中に悪意ある指示文が紛れ込む可能性は、ゼロにはできません。Metaも、プロンプトインジェクションは業界全体で解決されていない問題だと述べています。
外部から届いた内容は「指示」ではなく「データ」として扱い、送信元の分からないメールや、出所の分からない書類を、そのままMuseに処理させない運用を基本にしてください。
もう一つが、パスワードの扱いです。専用の入力画面を通した情報は、主役のエージェントには見えない仕組みです。チャットやファイルに書いたパスワードは、この保護の外にあります。
- 送信元の分からないメールの指示を、そのままMuseに実行させる
- パスワードや秘密情報を、チャットやファイルに書く
- 確認の画面を読まずに許可する
»出典:Meta公式の技術解説「How We Built Safety Into Muse」
④ 個人アカウントのまま業務で使い、社内ルールを決めずに始めてしまう

企業での導入では、ツールの機能よりも、責任の分け方と社内規程のほうが先に問われます。Museの利用規約の補足条項は、Museに与えた指示と、それを受けてMuseが行う操作について、責任は利用者が負うと定めています。リンクしたサービスの規約の遵守や、データを移すリスクの理解も、利用者の責任とされています。
メールの送信や金融取引の実行、データの削除のような状態を変える操作は、人による確認と承認を事前に受けるか、事前の権限付与がない限り行わないよう求められています。承認の設定は、個人の好みではなく、組織のルールとして決めるべき項目です。
業務利用の面では、Metaの公式資料から確認できなかった点があります。弊社が確認した範囲で、2026年11月4日時点で見つからなかった項目は次のとおりです。導入前に、Metaや契約窓口へ確認しておくことをおすすめします。
- SOC 2やISO/IEC 27001などの第三者認証をMuseが取得しているか:確認できず(2026年11月4日時点)
- 日本で使える法人向けのプランや、管理者向けの管理機能:案内が見つからず(2026年11月4日時点)
- 削除したデータや、継続的に取られるバックアップの保持期間(日数):未公表(2026年11月4日時点)
なお、Metaは中小企業向けの「Muse for Small Business」を2026年9月に発表しています。ただし、公式ページによると提供対象は米国とカナダの18歳以上の利用者で、日本での提供時期は示されていません。
»出典:Muse for Small Business、Meta「Introducing Muse for Small Business」
社内では、次の3点を決めておくと、事故の芽を減らせます。
- どの業務データを、どのアカウントでMuseにつないでよいか
- 誰が接続の可否と承認設定を決め、定期的に見直すか
- Museが実行した作業を、誰がどの頻度でアクティビティログで確認するか
なお、利用規約では、人による審査なしに、採用や与信などの判断をMuseに任せることは禁止されています。18歳未満の方は利用できません。
»出典:Muse利用規約の補足条項
Museは、専用の仮想マシンによる分離、Sentinelによる許可の管理、承認のルールといった観点から、安全性が考慮されたサービスです。一方で、責任の分け方と運用ルールは、利用する組織側で設計する必要があります。
セキュリティは「ツールだけで完結するものではない」
最終的には「ユーザーの使い方」が重要になる
【解決策】Museでの開発を外注する場合は信頼性の高い会社を選ぶ

ここまで見てきた通り、Muse自体は高いセキュリティを備えたツールです。
しかし実際の開発においては、「誰がどのように使うか」によって、安全性や品質は大きく変わります。
特に外注する場合は、開発会社の選び方が、そのままセキュリティや開発品質に直結すると言っても過言ではありません。
- 信頼できる実績があるか
- ブログやSNS、YouTubeで有益な発信がされているか
- 問い合わせた際の対応が丁寧か
- サポート体制は十分か
- 自社の事業・課題を踏まえて提案してくれるか
【ポイント①】信頼できる実績があるか

まず最も重要なのが、実績の有無とその中身です。
Museは、日々の用事を代わりに進めてもらえるという利点を得られる一方で、単にツールを使うだけでは成果にはつながりません。
重要なのは、
- どの業務でMuseを活用しているのか
- どの承認設定とコネクターの範囲で運用しているのか
- Museが実行した作業を、どのように確認し品質担保しているのか
といった「使い方の設計」です。
そのため開発会社に依頼する際は、「Museを使っています」という表面的な説明ではなく、具体的な活用プロセスや成果事例まで確認することが重要です。
特に、自社の目的に近い領域(MVP開発、業務効率化、社内ツールなど)での実績がある会社であれば、認識のズレが起きにくく、プロジェクトもスムーズに進めやすくなります。
【ポイント②】ブログやSNS、YouTubeで有益な発信がされているか

Museを扱う領域は、変化のスピードが非常に速い分野です。
そのため、開発会社が
- ブログ
- 技術記事
- SNS
- YouTube
などで継続的に情報発信しているかどうかは、提供範囲や承認の仕様変更、セキュリティ動向を追えているかの判断材料になります。
【ポイント③】問い合わせた際の対応が丁寧か

問い合わせ段階の対応は、そのままプロジェクト中のコミュニケーション品質に表れます。特にセキュリティの話題では、分からないことを分からないと言えるかどうかが重要です。
【ポイント④】サポート体制は十分か

Museは提供が始まったばかりで、仕様や既定の設定が変わっていく可能性があります。変更があったときに、誰がどこまで見直しを担うのかを、契約前に確認しておくと安心です。
【ポイント⑤】自社特有の課題を踏まえて提案してくれるか

Museは強力なツールですが、「作れるから作る」という判断に陥ると失敗しやすいのも事実です。
そのため重要なのは、
- どの業務にMuseを任せるべきか
- あえて使わない方がいい部分はどこか
- 事業として意味があるか
といった視点で提案してくれるかどうかです。
単なる開発ではなく、
- 壁打ち
- 仮説検証
- PoC設計
まで伴走してくれる会社であれば、スピードと事業価値の両立がしやすくなります。
本記事では、Museのセキュリティについて、安全と言える理由と、あわせて押さえておきたい注意点を解説しました。
Museは、専用の仮想マシンでの分離、Sentinelによる許可の管理、承認のルールなど、複数の観点から安全性が考慮されたサービスです。
一方で、どれだけセキュリティ機能が整っていても、権限の出しすぎや運用方法によっては情報漏洩などのリスクが発生する可能性があります。
だからこそ、「Museは安全か危険か」を二択で考えるのではなく、どのような仕組みで安全性が担保されているのか、そして安全に使うために何を意識すべきかを理解した上で活用することが重要です。
この記事が、Museの導入や活用を検討する際の参考になれば幸いです。
Walkersでは成果が実証されたノウハウをもとに、事業を成功に導くためのAI開発×補助金支援を行っています。新規事業・システム開発でお悩みがある方はお気軽にご相談下さい。
無料セルフチェック
費用も、AI活用の効果も。まず無料でチェック
開発の概算費用と、業務のAI効率化診断。条件を選ぶだけで、その場で結果を確認できます。会社への問い合わせは不要です。
無料でチェックを始める →