MAツールのセキュリティとは、顧客の個人情報を預けるクラウド型MAで、ベンダー側の対策と利用企業側の運用を組み合わせて情報漏えいと不正利用を防ぐ取り組みです。「不正アクセスのニュースが続き、MAに顧客情報を預けて大丈夫かと情シスに聞かれて答えられない」といったかたへ向けて、この記事では、2026年に見直すべき理由、導入前にベンダーへ確認する10項目、自社で行う対策5つ、関係する法律3つ、SHANON MAの対策までを1本にまとめました。
SHANON MA（旧：SHANON MARKETING PLATFORM）におけるセキュリティ体制はこちらをご覧ください。
▼社内確認用のセキュリティチェックシート（PDF）はこちら
MAツールのセキュリティとは？2026年に見直しが必要な理由
MAツールのセキュリティは「ベンダーの対策」と「自社の運用」の2層で成り立ち、どちらか片方だけでは守れません。この章では、定義と、2026年に見直しが必要になった理由を整理します
MAツールのセキュリティとは、見込み客の氏名・メールアドレス・Web行動履歴といった個人情報を集中管理するMAを、不正アクセス・なりすましメール・内部からの持ち出し・法令違反から守るための、ベンダーの技術的対策と利用企業の運用ルールの総称です。マーケティング部門が主管するツールでありながら、扱う情報の性質は基幹システムと変わりません。
2026年に相次ぐ不正アクセスとPHP脆弱性（IPAの注意喚起）
2026年秋、国内で2つの注意喚起が続けて出されました。MAツールの利用企業にも直接関わる内容です。
1つ目は、2026年10月9日に独立行政法人情報処理推進機構（IPA）が公開した「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」です。Webサービスやアカウントサービスから大量の個人情報が窃取される事案が相次いだことを受け、外部公開アプリケーション、利用中のクラウドサービス、保有データの緊急点検を経営者に求めています。
ログの確認は直近1か月から始めて3か月へ広げること、作成した覚えのないアカウントや無効化したはずのアカウントの復活を確認することが、具体的な対策として挙げられています。
参考：https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html
2つ目は、2026年10月22日のPHPの脆弱性に関する注意喚起です。2件の脆弱性（CVE-2026-109618、CVE-2026-109619）を組み合わせると、遠隔の第三者が任意のコードを実行できる可能性があり、「PHP2shell」と呼ばれています。修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12以降で、サポートが終了したPHP 8.1以前には修正が提供されません。
PHPはWebサイトやフォームを動かす言語として広く使われており、「自社のフォームやLPを置いている基盤は、誰がパッチを当てるのか」という問いに、マーケティング担当者も答えを求められるようになりました。
参考：https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html
MAツールが狙われやすい3つの理由
MAツールが攻撃の対象になりやすい理由は、扱う情報と公開の仕方にあります。この章では、個人情報の集中、公開されたフォーム、自社ドメインでのメール送信の3つに分けて、なぜMAが狙われるのかを整理します。
1. 個人情報が1か所に集まっている
展示会の名刺、資料請求フォーム、セミナー申込みで集めた数千から数万件の見込み客データが、1つのツールに蓄積されます。攻撃者から見れば、1回の侵入で得られる情報量が多い場所です。
しかも、MAのデータは氏名とメールアドレスだけではありません。どのページを見たか、どのメールを開いたか、どのセミナーに参加したかという行動履歴が紐づいています。企業名と役職、関心のある製品分野まで分かるリストは、名簿としての価値が高く、標的型のフィッシングにも転用されます。
2. フォームやLPがインターネットに公開されている
社内システムと違い、MAのフォームやLPは誰でもアクセスできる入口を常に持っています。脆弱性があれば、認証を経ずに直接狙われます。
フォームは「外部からの入力を受け取って保存する」仕組みそのものです。入力値の検証が甘いと、不正なデータの送り込みや、入力内容を盗み取る仕掛けの埋め込みが起こります。キャンペーンごとにLPを増やす運用では、担当者が把握していない古いフォームが公開されたまま残ることも珍しくありません。
3. 自社ドメインでメールを送信している
MAから送るメールは自社ドメインを名乗るため、送信ドメイン認証の設定が不十分だと、自社を装ったなりすましメールの温床になります。被害者は自社ではなく顧客です。
受信側のメールサービスは、認証されていないメールを迷惑メール扱いします。なりすましを許す状態は、攻撃者に利用される危険と、正規のメールが届かなくなる損失の両方を抱えています。この構造は「自社対策4」で扱う送信ドメイン認証で解消します。
守る範囲は「ベンダー側」と「利用企業側」の2層に分かれる
クラウド型MAのセキュリティは、ベンダーが守る範囲と利用企業が守る範囲に分かれます。この分担を理解していないと、「ベンダーが認証を取っているから安心」という誤解が生まれます。
ベンダーが担うのは、インフラの監視、脆弱性対応とパッチ適用、通信と保管データの暗号化、バックアップと災害時の復旧、障害や事故の検知と通知です。利用企業が担うのは、ユーザーの追加・停止と権限設定、多要素認証やIPアドレス制限の設定、フォームでの同意取得、ログイン履歴の確認、ダウンロードしたデータの社内管理です。
ベンダーがどれだけ堅牢な基盤を用意しても、利用企業側の設定が初期状態のままなら、全ユーザーがパスワードだけでログインでき、退職者のアカウントが残り続けます。本記事の後半で扱う「自社対策5つ」は、この利用企業側の範囲を埋めるものです。
MAツールで起こりうるセキュリティ事故4つ
MAの事故は「外からの高度な侵入」より、ログイン情報・設定・退職者といった運用側の穴から起こることが多いです。この章では、起こりうる事故を4つに分けて、原因とどの章で対策を扱うかを示します。
1. ID・パスワードの使い回しによる不正ログインと顧客リスト流出
もっとも多い事故は、他のサービスから漏れたパスワードを使った不正ログインです。MAのログイン画面は公開されているため、IDとパスワードが一致すれば誰でも入れます。
マーケティング部門では、担当者間でアカウントを共有する、代理店に自社のIDを貸すといった運用が起こりがちです。1つのパスワードが漏れると、顧客リストの全件ダウンロードまで到達します。対策は「自社対策1」の多要素認証と権限の最小化で扱います。
2. フォーム・LPの脆弱性を突いた改ざんや情報窃取
公開中のフォームやLPに脆弱性があると、入力された情報を盗む仕掛けを埋め込まれる、別サイトへ誘導されるといった被害が起こります。
この事故を防げるかどうかは、フォームの基盤を誰が管理し、誰がパッチを当てるかで決まります。PHPの脆弱性が自社に関係するかどうかも、同じ区分で判断できます。判断の仕方は「ベンダーへの確認10項目」の章の「項目7の補足」で扱います。
3. 自社ドメインを装ったなりすましメール（フィッシング）
MAから送るメールは自社ドメインを名乗ります。送信ドメイン認証の設定が不十分だと、攻撃者が同じドメインを名乗ったフィッシングメールを顧客に送れます。
被害を受けるのは顧客で、信用を失うのは自社です。受信側のGmailやMicrosoftは認証されていないメールを迷惑メール扱いするため、正規のメルマガが届かなくなる二次被害も起こります。対策は「自社対策4」のSPF・DKIM・DMARCで扱います。
4. 退職者アカウントの放置とCSVダウンロードによる持ち出し
外部からの攻撃ではなく、内部からの持ち出しによる漏えいも無視できません。退職した担当者のアカウントが残っていれば、退職後も顧客リストにアクセスできます。
IPAの2026年10月9日の注意喚起でも、「削除・無効化されているはずのアカウントが有効になっていないか」の確認が、優先して行うべき項目に挙げられています。CSVダウンロードの権限を全員に与えている、ダウンロード履歴を誰も見ていないという状態は、持ち出しに気づけない状態です。対策は「自社対策2・3」で扱います。
代理店の担当者と共有していたログインIDが、担当交代の後もパスワードを変えずに残っていた。半年後、別の目的でログイン履歴を見たときに、見覚えのない時間帯のログインが並んでいるのに気づいた。問題はそこからで、IDを共有していたために「誰が操作したか」を特定できず、全件ダウンロードされた前提で報告範囲を検討することになった。
ログイン履歴は、見る習慣がない限り何も教えてくれない。
MAツールのセキュリティはどう確認する？ベンダーへの確認10項目
「認証を取っているか」だけでは不十分で、データの置き場所・ログイン保護・脆弱性対応・障害時の連絡・契約終了後の削除まで、10項目を書面で確認します。導入実績の多いベンダーは一定の安心材料になりますが、実績は体制の証明ではありません。この章の表は、情シスや法務への説明資料としてそのまま使えるよう、質問文と目安を添えました。
以下の表は、MAツール導入前にベンダーへ確認するセキュリティ項目10個を、確認する質問と目安の観点で整理したものです。
|
1. ISMS・プライバシーマークの登録番号と適用範囲
|
|
|
2. データの保管リージョン（AI機能への送信先も含む）
|
|
|
3. 通信時・保管時・バックアップの暗号化
|
|
|
4. SSO・多要素認証・IPアドレス制限が標準機能か
|
|
|
5. ログイン履歴・CSVダウンロード履歴を自社で出力できるか
|
|
|
6. ベンダー担当者の本番データアクセスが承認制か
|
|
|
7. 脆弱性診断の頻度と、パッチを当てるのが誰か
|
|
|
8. バックアップの頻度・保管方法・拠点の分散
|
|
|
9. 重要インシデントの第一報までの時間
|
|
|
10. 契約終了後のデータ削除期限と全件出力の手段
|
表の10項目のうち、回答を見ても判断に迷いやすい項目1・2・7の3つは、以下で見方を補足します。最後に、10項目の回答を書面に残す方法を説明します。
項目1の補足：ISMSは適用範囲まで見る
ISMSやプライバシーマークは、第三者機関が情報管理体制を審査した証明です。ただし、取得の有無だけで判断すると見落としが起こります。
ISMSには「適用範囲」があり、会社全体ではなく特定の事業や拠点だけを対象にしている場合があります。確認するのは、自社が使うMAサービスの企画・開発・運用が適用範囲に含まれているかどうかです。登録証の写しを開示できるベンダーなら、適用範囲の欄で確かめられます。
クラウドサービス固有の管理策を審査するISMSクラウドセキュリティ認証（ISO/IEC 27017）や、政府情報システム向けのISMAPは、より厳しい基準です。金融や官公庁との取引がある企業は、社内規程でこれらを求められることがあるため、先に情シスへ必要水準を確認しておきます。
項目2の補足：AI機能への送信も確認する
項目2で聞くのは保管するリージョンだけではありません。2026年のMAツールには、メール文面の生成やセグメントの提案といったAI機能が標準で入っています。ベンダーがAI機能のために外部のAIサービスへ顧客情報を送る場合、その情報がAIモデルの学習に使われるかどうかは、ベンダーとAIサービスの契約次第です。
確認するのは3点です。送信する情報を処理に必要な範囲に限定しているか、学習に使われない規約を結んでいるか、生成内容の最終確認は誰の責任かです。AIが生成した文面を確認せずに配信すると、特定電子メール法の表示義務を満たさない文面や、事実と異なる記述が顧客に届きます。最終確認は利用企業の責任である点を、運用ルールに明記しておきます。
項目7の補足：パッチは誰が当てるか
項目7の回答で見るのは診断の頻度だけではありません。PHPの脆弱性のような基盤レベルの問題で確認すべきことは1つです。「自社がアップデート作業をする必要があるか」をベンダーに聞きます。
クラウド型MAでは、OS・ミドルウェア・言語ランタイムの更新はベンダーの責任範囲です。ベンダーが定期的に脆弱性診断を行い、検出した脆弱性に危険度順で対応し、利用企業の作業なしでパッチを適用する体制であれば、利用企業はニュースのたびに自社のフォームを止める必要がありません。IPAの注意喚起も「自組織で利用している製品への影響は、製品の開発者やサービス提供元の情報で確認する」としています。
一方、自社サーバーに置いた自作フォームや、オンプレミス型のツールは、自社がパッチを当てる側です。サポートが終了したバージョンには修正が提供されないため、更新できない環境は移行か廃止を判断する必要があります。MAを導入する際に、自社管理のフォームをMA側へ寄せると、この負担そのものを減らせます。
回答はチェックシートで書面に残す
10項目への回答は口頭やメールで済ませず、ベンダーが提供するセキュリティチェックシートで書面に残します。導入の稟議では、このシートが情シス・法務の審査の起点になります。渡す前に、何を基準に作られたシートかを確認します。
IPAの「安全なウェブサイトの作り方」や経済産業省の「クラウドサービスレベルのチェックリスト」に準拠したシートであれば、情シスは自社の基準と項目を突き合わせやすくなります。自社に独自のチェックシートがある場合は、ベンダーが回答に応じるかを先に聞いておきます。回答に数週間かかるベンダーもあるため、導入スケジュールに織り込みます。
チェックシートの回答は「はい／いいえ」で終わらせず、上の10項目の「目安」と照らします。「暗号化している」と書かれていても、バックアップまで含むかは別です。曖昧な回答は、契約書類での明記を求めます。
SHANON MAのセキュリティチェックシートは、IPA「安全なウェブサイトの作り方」と経済産業省「クラウドサービスレベルのチェックリスト」にもとづいて作成しています。稟議の添付資料としてそのまま使えます。
セキュリティチェックシート（PDF）をダウンロードする
MAツール運用で利用企業側が行うセキュリティ対策5つ
ベンダーが守ってくれるのはインフラまでです。アカウント・権限・同意取得・メール認証は自社が設定しないと機能しません。この章の5つは、いずれも追加費用なしで今日から着手できます。
【診断】情シスから最初に聞かれた質問はどれ？ 質問をタップすると、着手する対策を逆引きできます。
1. 多要素認証を全ユーザーに必須化し、権限を役割ごとに最小にする
最初に行うのは、多要素認証を「任意」ではなく「必須」にする設定です。パスワードが漏れても、第二の認証がなければログインできません。
設定できるのに使っていない企業が多いのは、管理者が個別に有効化する運用になっているためです。全ユーザーに強制する設定があるかを確認し、あれば一括で有効にします。あわせて、許可したIPアドレス以外からのアクセスを制限すれば、社外からの不正ログインの入口を狭められます。
権限は「閲覧だけ」「配信まで」「全件出力まで」のように役割で分けます。代理店や外注先には秘密保持契約を結んだうえで個別のアカウントと閲覧権限だけを渡し、出力は社内の管理者に限定します。1つのIDを複数人で共有する運用は、誰が操作したかを追えなくなるため廃止します。
2. 退職・異動時のアカウント停止とログイン履歴の月次確認
退職者のアカウント停止を、人事の退職手続きと同じ日に行うルールを作ります。MAは情シスの管理台帳から漏れやすいツールのため、マーケティング部門の側に手順を持ちます。
SSO（シングルサインオン）を使っていれば、社内の認証基盤でアカウントを無効化するだけでMAにもログインできなくなります。SSOを使っていない場合は、MAの管理画面で個別に無効化します。
月に1度、ログイン履歴を確認する時間を15分だけ取ります。見るのは、見覚えのないアカウント、深夜や休日のログイン、通常と違うIPアドレスの3点です。IPAが求める「直近1か月のログ確認」は、この習慣があれば追加作業なしで満たせます。
3. CSVダウンロード権限を絞り、出力データの社内保管ルールを決める
顧客リストの持ち出しは、CSVダウンロードから起こります。ダウンロードできる人を限定し、履歴を確認できる状態にします。
出力したCSVの扱いも決めておきます。メールに添付しない、個人のPCに残さない、用が済んだら削除する、の3点を部門ルールにします。MA側のセキュリティがどれだけ高くても、出力した先のExcelが社外に出れば同じ事故です。
4. SPF・DKIM・DMARCを設定して自社ドメインのなりすましを防ぐ
自社ドメインからMAでメールを送るには、送信ドメイン認証の3つの設定が欠かせません。設定しないと、なりすましを防げないうえ、正規のメールも届きにくくなります。
SPFは「このサーバーから送ってよい」と宣言する仕組み、DKIMは電子署名で本文が改ざんされていないことを示す仕組み、DMARCはSPFとDKIMに失敗したメールをどう扱うかを受信側に指示し、結果を報告させる仕組みです。Googleは2024年2月以降、個人のGmailアカウント宛に1日5,000通以上を送る送信者に、SPF・DKIMに加えてDMARCの設定を求めています。
参考：https://support.google.com/a/answer/81126
設定はDNSを管理する情シスやWeb担当の作業になるため、MAベンダーが設定手順や代行プランを用意しているかを確認します。設定後は、DMARCのレポートで不合格メールの発生状況を定期的に見ます。
5. フォームでの同意取得とプライバシーポリシー・Cookie利用の明示
個人情報を集めるフォームには、利用目的への同意を取る項目を置きます。メールマガジンの配信に使う場合は、配信への同意を別の項目で取ります。
プライバシーポリシーには、収集する情報、利用目的、第三者提供の有無、開示請求への対応を書き、フォームからリンクします。MAはWeb行動の追跡にCookieを使うため、Cookieの利用目的と無効化の方法も明示します。これらは次の章で扱う3つの法律への対応そのものです。
MAツールに関係する法律
MAの運用に関わる法律は3つあり、「同意を取る」「表示する」「記録を残す」の3つの動作に落とすと運用に組み込めます。この章では、各法律でMA担当者が実際に行うことだけを取り上げます。
個人情報保護法：利用目的の通知・公表、委託先の監督、漏えい時の報告義務
MAで見込み客の情報を扱う企業は、個人情報取扱事業者として、利用目的を本人に通知または公表する義務を負います。方法は「自社対策5」で述べたフォームとプライバシーポリシーですが、利用目的の書き方に注意が必要です。「資料送付のため」とだけ書くと、後からメールマガジンやセミナー案内に使えなくなります。将来の施策を含む範囲で、具体的に書きます。
MAベンダーは、個人情報の取り扱いを委託する「委託先」に当たります。利用企業には委託先を監督する義務があり、委託契約の締結と、ベンダーのセキュリティ体制の確認が求められます。上の10項目は、この監督義務を果たす手段でもあります。
2022年4月に全面施行された改正法では、漏えい等が発生した場合の個人情報保護委員会への報告と本人への通知が義務になりました。ベンダーからの第一報が何時間以内に来るかを確認しておく理由は、自社の報告期限を守るためです。
参考：https://www.ppc.go.jp/personalinfo/legal/leakAction/
特定電子メール法：オプトイン・送信者表示・配信停止の3要件
広告や宣伝を含むメールの送信には、特定電子メール法が適用されます。守るべき要件は3つです。
1つ目は、あらかじめ同意を得た相手にだけ送ること（オプトイン）です。名刺交換の相手など、一定の取引関係がある場合は例外がありますが、原則は事前同意です。2つ目は、送信者の氏名または名称と、問い合わせ先を本文に表示することです。3つ目は、受信拒否の方法を表示し、拒否の申し出があれば以後送らないことです。
MAには配信停止リンクの自動挿入と、停止した相手への配信除外の機能があります。機能があっても、配信停止後に別のリストから同じ相手へ送ってしまう運用ミスは起こるため、リストの統合と除外設定を確認します。
参考：https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail.html
電気通信事業法の外部送信規律：Cookie・タグの利用目的と送信先の公表
2023年6月に施行された電気通信事業法の外部送信規律により、Webサイトの閲覧者の情報を外部に送信するCookieやタグについて、送信される情報の内容、送信先、利用目的を公表することが求められます。
MAのトラッキングタグはこの対象です。自社サイトのプライバシーポリシーやCookieポリシーに、MAベンダーの名称と送信する情報の内容を記載します。ベンダーが記載用の情報を提供しているかを確認すると、作業が短くなります。Cookie規制の全体像と対策は、別記事で解説しています。
参考：https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu.html
参考：Cookie規制の現状と、マーケティング部門がすぐやるべき5つの対策。シャノンが提案する新技術もご紹介！
SHANON MAのセキュリティ対策
ここまでの10項目を、SHANON MAがどう満たしているかを示します。「情シスへの説明に時間がかかる」「ベンダーに何を聞けばよいか分からない」という課題に対して、確認の手間を減らす形で用意しています。
株式会社シャノンは、2004年12月にISMS認証（登録番号 IS 89514、現在はISO/IEC 27001）を取得し、継続して外部審査を受けています。プライバシーマーク（登録番号 10822938）も取得しています。SHANON MAは全データをAWS東京リージョンに保管し、通信時・保管時・バックアップのすべてを暗号化しています。
以下の表は、本記事の確認10項目に対するSHANON MAの対応を整理したものです。
法令対応の面では、配信停止リンクの挿入と配信停止の反映、フォームでの同意取得状況の管理、SPF・DKIM・DMARCへの対応を備えています。外部送信規律に必要なCookieの利用目的や送信先の情報も提供しています。AI機能に送信した情報は、利用しているAIサービスの規約にもとづき、AIモデルの学習には使用されることはありません。
稟議に使えるセキュリティチェックシートは、IPA「安全なウェブサイトの作り方」と経済産業省「クラウドサービスレベルのチェックリスト」にもとづいて作成し、PDFで提供しています。お客様独自のチェックシートへの回答も相談に応じています。詳細な条件は契約書類で確認できます。
参考：https://www.shanon.co.jp/ma/security/
シャノンのセキュリティについて
このほか、法令対応（特定電子メール法・個人情報保護法・電気通信事業法）の支援機能や、よくある質問（退職者アカウントの扱い、独自チェックシートへの対応など）もセキュリティページに掲載しています。
▼SHANON MAのセキュリティ体制を見る
https://www.shanon.co.jp/ma/security/
▼社内確認用のセキュリティチェックシート（PDF）はこちら
https://www.shanon.co.jp/lp/202512_security/
よくある質問
Q1. MAツールにセキュリティのリスクはありますか？
あります。ただし、事故の多くは外部からの高度な攻撃ではなく、パスワードの使い回し、退職者アカウントの放置、送信ドメイン認証の未設定といった運用側の不備から起こります。ベンダーの認証や暗号化を確認したうえで、多要素認証の必須化、権限の最小化、ログイン履歴の月次確認を自社で行えば、リスクは大きく下げられます。
Q2. MAツールの顧客データは海外のサーバーに保管されますか？
ベンダーによって異なります。海外製のMAでは、米国や欧州のデータセンターに保管される製品があり、社内規程で国内保管を求められる企業は確認が必要です。国産MAでも保管場所を公表していない製品があるため、契約前に「どの国・リージョンに保管されるか」を書面で確認します。SHANON MAは複数のデータセンターに分散して配置しています。
Q3. PHPの脆弱性はMAツールにも影響しますか？
影響の有無は、誰が基盤を管理しているかで決まります。クラウド型MAのフォームやLPは、OSや言語ランタイムの更新をベンダーが行うため、利用企業がアップデート作業をする必要はありません。自社サーバーに置いた自作フォームやオンプレミス型ツールは、自社でパッチを当てる必要があります。IPAは、利用製品への影響をサービス提供元の情報で確認するよう求めています。
まとめ
MAツールのセキュリティは、ベンダーが守る範囲と自社が守る範囲の2層で考えます。導入前にはベンダーへ10項目を書面で確認し、認証の適用範囲と脆弱性対応の分担を押さえます。導入後は、多要素認証の必須化、退職者アカウントの停止、CSV権限の限定、送信ドメイン認証、同意取得の5つを自社の運用に組み込みます。
2026年のIPAの注意喚起が求めるクラウドサービスの棚卸しとログ確認は、この記事の10項目と自社対策5つを実施していれば、追加の作業なしで答えられます。情シスへの説明には、ベンダーのチェックシートと本記事の表を並べて使ってください。
