セキュリティ

KARTEの不正アクセス：全機能停止で利用企業がタグ・配信・データ連携を確かめる手順

KARTEの不正アクセス：全機能停止で利用企業がタグ・配信・データ連携を確かめる手順

株式会社プレイドの顧客体験プラットフォーム「KARTE」が、2026年11月13日に第三者からの不正アクセスを検知し、緊急メンテナンスとして全プロジェクトのサービスを止めました。Web・アプリの計測、各種配信、管理画面の操作まで含む全機能が対象です。個人情報が漏えいしたかどうか、侵入経路、再開の時期は、同日夕方の時点で公表されていません。この記事では、公表文で確定している事実と未公表の項目を分けたうえで、利用企業が自社サイトの計測タグ、途中で止まった一括メール、失敗したデータ連携、個人情報の報告準備をどう確かめるかを、実行できるPythonのコード付きで整理します。

まとめ：KARTEの全機能停止で利用企業が今日確かめる4つの作業

プレイドの11月13日付の適時開示とKARTEのステータスページで確定しているのは、不正アクセスの検知、全プロジェクトでの全機能停止、機能が順次止まること、処理中のジョブが途中で止まる場合があることの4点です。業績への影響は精査中とされています。

利用企業が今日やる作業は4つあります。優先度の高い順に並べます。

  1. 止まった一括メールとデータ連携ジョブを洗い出し、再開後に再実行してよいかを決める
  2. 自社サイトの計測タグが同期読み込みになっていないかを確かめ、表示への影響を見積もる
  3. KARTEに送っている個人データの項目を一覧にし、漏えいが公表された場合の報告に備える
  4. ステータスページの更新を購読し、続報を担当者が取りこぼさない状態にする

計測が止まっている間の行動データは、後から取り戻せないと考えて動きます。タグを外すかどうかは、続報で侵入経路が示されるまで決めなくて構いません。判断の条件は最後の章に書きました。

11月13日の適時開示とステータスページで確定している事実と未公表の項目

停止対象の14コンポーネントと、利用企業側で止まる機能の対応表

ステータスページの告知は11月13日14時44分（JST）に出され、15時00分に「調査を続けている」との更新が入りました。影響を受けるコンポーネントとして14件が登録されています。公表文の記述を、利用企業の側で何が止まるかに読み替えると次のとおりです。

コンポーネント 公表文の記述 利用企業側で止まるもの
イベントトラッキング・解析 Web・アプリの計測を停止 停止中の閲覧・購買イベントの記録
接客の配信・KARTE Blocks 各種配信を停止 サイト上のポップアップ・書き換え
KARTE Message 一括メール配信は途中で停止の場合あり 配信の一部だけ届いた状態
KARTE Datahub 処理中のジョブフローは失敗の場合あり KARTE内外のデータ連携
管理画面・Api v2 管理画面の操作を含め停止 設定変更・データ取得・APIからの書き込み
チャット・KARTE for App 全てのKARTE機能を停止 サイト内チャット・アプリ内の配信

コンポーネントには、ほかにKARTE Live、ジャーニー、Signals、Craftも含まれています。止まる順番は公表されていません。「即座に全ての機能が利用できなくなるのではなく、順次停止していく」とあるため、同じ時刻でもページによって配信が出たり出なかったりする時間帯があったと見ておきます。

漏えいの有無・件数・侵入経路と再開時期が未公表である点の扱い

適時開示に書かれていないことを並べます。個人情報が閲覧・取得されたか、その件数、侵入経路、攻撃の手口、サービスの再開時期です。プレイドは、新たに公表すべき事実が判明したら速やかに知らせるとしています。

未公表の段階では、自社の顧客に「漏えいした」とも「漏えいしていない」とも書かないのが安全です。問い合わせが来た場合は「委託先のサービスで不正アクセスが検知され、現在調査中。判明しだい知らせる」と事実だけを返します。なお「プレイド 漏えい」で検索すると2022年の記事も出てきますが、これは米Slack社の誤送信でプレイドの従業員などのメールアドレスが別企業に送られた件で、今回とは別の事案です。

ステータスページの更新をStatuspage公開APIで追うPythonの監視例

KARTEのステータスページはAtlassian Statuspageで動いており、メール・SMS・Webhook・RSSでの購読を受け付けています。社内の通知に流したい場合は、公開されているJSONを定期的に取得する方法も選択肢です。次のコードは、未解決のインシデントと最新の更新時刻を表示します。

# ステータスページの未解決インシデントと最新の更新を表示する（Python 3.9以上・標準ライブラリのみ）
import json
import urllib.request
from datetime import datetime

URL = "https://status.karte.io/api/v2/incidents/unresolved.json"

req = urllib.request.Request(URL, headers={"User-Agent": "status-watch"})
with urllib.request.urlopen(req, timeout=15) as r:
    data = json.load(r)

for inc in data["incidents"]:
    latest = inc["incident_updates"][0]  # 新しい順に並んでいる
    print(inc["name"])
    print("  status    :", inc["status"])
    print("  created   :", datetime.fromisoformat(inc["created_at"]).strftime("%Y-%m-%d %H:%M %z"))
    print("  updated   :", datetime.fromisoformat(latest["created_at"]).strftime("%Y-%m-%d %H:%M %z"))
    print("  components:", len(inc["components"]), "件")
    print("  latest    :", latest["body"].splitlines()[0][:60])

Python 3.14.10（Windows）で2026年11月13日に1回だけ実行した結果です。

緊急メンテナンスのためKARTE全体のサービスを停止します
  status    : investigating
  created   : 2026-11-13 14:44 +0900
  updated   : 2026-11-13 15:00 +0900
  components: 14 件
  latest    : We are continuing to investigate this issue.

status が investigating から identified、monitoring、resolved へ変わったら担当者に知らせる、という使い方をします。取りに行く間隔は15分程度で足ります。数秒おきに叩く必要はありません。

自社サイト側：計測タグが応答しないときの表示への影響と読み込み方式の点検

async・deferの無い同期読み込みのscriptがページの構文解析を止める仕組み

KARTEは、管理画面から発行される計測タグをサイトの全ページに置いて使います。止まったサービスのタグがページにどう響くかを左右するのは、そのタグの読み込み方式です。MDNのscript要素の解説によると、async・defer・type=”module” のいずれも無い外部scriptは、ブラウザがページの解析を続ける前に取得と実行を済ませます。つまり、取得先が応答しないまま待たされると、その後ろに書かれたHTMLの解析も待たされます。

asyncかdeferが付いていれば、解析は止まりません。タグ管理ツール経由で入れたタグも、ツール本体の読み込みが非同期なら同じです。サービスが「停止」していても、応答をすぐ返して終わる停止なら影響は小さく、応答が返らずタイムアウトまで待つ停止だと影響が出ます。どちらの形で止まっているかは外から断定できないため、自社のページがどちらにも耐えるかを確かめます。

自社ページの外部scriptを同期・async・deferで分類するPython点検例

次のコードは、HTMLに含まれる外部scriptを、置き場所（head・body）、読み込み方式、自社か外部かで一覧にします。「要確認」を付ける対象は、headにある外部の同期scriptだけです。検証用のHTMLを埋め込んでありますが、実際は自社ページのHTMLを取得して渡します。

# ページ内の外部scriptを一覧にし、読み込み方式（同期／async／defer）と置き場所を出す（Python 3.9以上・標準ライブラリのみ）
from html.parser import HTMLParser
from urllib.parse import urlparse

SITE_HOST = "www.example.co.jp"  # 自社ドメイン

class ScriptAudit(HTMLParser):
    def __init__(self):
        super().__init__()
        self.where = "body"
        self.rows = []

    def handle_starttag(self, tag, attrs):
        a = dict(attrs)
        if tag == "head":
            self.where = "head"
        elif tag == "body":
            self.where = "body"
        elif tag == "script" and a.get("src"):
            host = urlparse(a["src"]).hostname or SITE_HOST
            mode = "async" if "async" in a else "defer" if "defer" in a else "sync"
            self.rows.append((self.where, mode, host))

    def handle_endtag(self, tag):
        if tag == "head":
            self.where = "body"

# 検証用のページ（実際は urllib.request で自社ページのHTMLを取得して渡す）
PAGE = """<html><head>
<script src="https://cdn.vendor-a.example/tag.js"></script>
<script async src="https://tags.vendor-b.example/loader.js"></script>
<script src="/js/app.js" defer></script>
</head><body>
<script src="https://widget.vendor-c.example/chat.js"></script>
</body></html>"""

p = ScriptAudit()
p.feed(PAGE)
for where, mode, host in p.rows:
    third = host != SITE_HOST
    flag = "要確認" if (third and mode == "sync" and where == "head") else ""
    print(f"{where:4} {mode:5} {'3rd' if third else '1st'} {host} {flag}".rstrip())

同じ環境での実行結果です。ドメインは説明用のもので、KARTEのタグのURLではありません。

head sync  3rd cdn.vendor-a.example 要確認
head async 3rd tags.vendor-b.example
head defer 1st www.example.co.jp
body sync  3rd widget.vendor-c.example

bodyの末尾に置いた同期scriptは、本文の表示がほぼ済んでから読まれるため、優先度は下がります。まず「要確認」の行から、ベンダーの指定でその書き方になっているのか、過去の担当者がコピーしたまま残っているのかを確かめます。

Chrome DevToolsのリクエストブロックで外部タグが届かない状態を再現する手順

コードで一覧にした外部scriptが本当に表示を止めるかは、ブラウザで試すのが確実です。Chrome DevToolsのNetworkパネルでは、ドロワーの「Network request blocking」タブに取得先のURLやドメインのパターンを登録すると、そのリクエストを止めた状態でページを開けます。ブロックしたリクエストは一覧で赤く表示されます。

ブロックは「すぐに失敗が返る停止」の再現です。応答が返らず待たされる停止は、開発環境で取得先をタイムアウトするまで応答しないサーバーに向けて試します。どちらでも購入ボタンやフォームが動くことを、スマートフォン幅とPC幅の両方で確かめておきます。

配信とデータ連携：途中で止まった一括メールとジョブフローの確かめ方

KARTE Messageの一括メール途中停止時に行う未送信者と停止後送信の突き合わせ

ステータスページは、KARTE Messageの一括メール配信が処理の途中で止まる場合があると書いています。再開後に同じ配信をもう一度流すと、既に届いた人に二重に送ることになります。配信対象の一覧と送信ログを突き合わせ、届いていない人だけを抜き出すのが先です。

ここで時刻の扱いに注意が要ります。KARTEのセキュリティホワイトペーパー（2.5版）は、KARTE内で提供されるログはUTC、管理画面の表示はJSTと書いています。ログの「05:46」は日本時間の14時46分で、14時44分の停止告知より後です。数字だけ見て比べると逆の判定になります。

# 一括メールの配信対象と送信ログを突き合わせ、停止時刻をまたいだ未送信者を出す（Python 3.9以上・標準ライブラリのみ）
import csv
import io
from datetime import datetime, timedelta, timezone

JST = timezone(timedelta(hours=9))
STOP_AT = datetime(2026, 11, 13, 14, 44, tzinfo=JST)  # ステータスページの停止告知（JST）

# 配信対象（自社のCRM・名簿から出したもの）
TARGETS = """user_id,segment
u001,cart_abandon
u002,cart_abandon
u003,cart_abandon
u004,cart_abandon
"""
# 送信ログ（UTCで記録されている前提。末尾のZがUTCを示す）
SENT_LOG = """user_id,sent_at
u001,2026-11-13T05:41:10Z
u002,2026-11-13T05:43:58Z
u003,2026-11-13T05:46:02Z
"""

def parse_utc(s):
    return datetime.fromisoformat(s.replace("Z", "+00:00"))

sent = {r["user_id"]: parse_utc(r["sent_at"]) for r in csv.DictReader(io.StringIO(SENT_LOG))}

for t in csv.DictReader(io.StringIO(TARGETS)):
    at = sent.get(t["user_id"])
    if at is None:
        print("未送信", t["user_id"], t["segment"])
    elif at >= STOP_AT:
        print("停止後に送信", t["user_id"], at.astimezone(JST).strftime("%H:%M:%S JST"))
    else:
        print("送信済み", t["user_id"], at.astimezone(JST).strftime("%H:%M:%S JST"))

同じ環境での実行結果です。値は説明用に作ったもので、KARTEの実際のログ形式を再現したものではありません。

送信済み u001 14:41:10 JST
送信済み u002 14:43:58 JST
停止後に送信 u003 14:46:02 JST
未送信 u004 cart_abandon

「停止後に送信」の行は、順次停止の途中で届いた人です。再送の対象から外します。未送信の人に再開後すぐ送るかどうかは、メールの中身で決めます。カゴ落ちやキャンペーン締切のように時刻に意味がある配信は、数日遅れて届くと逆効果なので送り直しません。

KARTE Datahubのジョブフロー失敗で欠ける期間を連携先のテーブルに記録する

Datahubのジョブフローで、KARTEの内外をつなぐ連携が処理中だった場合は失敗することがあると告知されています。連携先が自社のデータ基盤（BigQueryなど）なら、止まった期間の分は取り込まれていません。再開後にジョブを再実行する前に、連携先のテーブルで最後に入った行の時刻を控え、欠けている期間を記録します。

記録が要るのは、後で集計を見た人が「11月13日から売上が落ちた」と誤読するのを防ぐためです。ダッシュボードの該当期間に注記を入れ、欠損を埋め戻せない指標（停止中の閲覧数など）を明示します。ホワイトペーパーによると、イベントデータと解析データは日次で2世代分バックアップされていますが、利用者からの復元の要望は受け付けていません。停止中に計測されなかったイベントは、そもそもバックアップの対象になりません。

APIアクセストークンとWebhook連携の棚卸しを、再発行の指示が出る前に済ませる理由

KARTE API v2は、管理画面で「アプリ」を作成したときに発行されるアクセストークンを Authorization ヘッダーの Bearer で送る方式です。11月13日の公表文はトークンの再発行を求めていません。ただし侵入経路が管理画面やAPIの認証まわりだった場合、続報で再発行を求められる可能性があります。

そのとき慌てないよう、トークンをどのサーバー・どのジョブ・どの環境変数に入れているかを今のうちに一覧にしておきます。一覧があれば、再発行の指示が出てから差し替え完了までを1時間以内で終えられます。キーの保管と失効の手順はAPI不正アクセス対策の実装手順のトークン失効の章、外部SaaSが破られたときのキー差し替えの実例はStudioの不正アクセスとAPIキー・Webhook URLの差し替えで整理しました。

個人情報の報告準備：漏えいの有無が未公表の段階で利用企業が整える情報

ホワイトペーパーの責任分界から見た、利用企業側のアカウントと権限の棚卸し

ホワイトペーパーの責任分界は、プレイドがKARTE本体と保管データの保護を、利用者が各ユーザーのパスワードとアカウントの管理（登録・削除・管理者権限の付与）を担うと定めています。今回の侵入がどちらの側で起きたかは未公表ですが、利用企業の側で今できるのは後者です。

再開後に管理画面へ入れるようになったら、退職者や委託先のアカウントが残っていないか、管理者権限を持つ人が必要以上にいないかを確かめます。プレイドが2025年7月に発表したのは、個人情報等を扱うリソースへの操作履歴を記録する監査ログ機能です。契約に含まれているなら、停止前後の操作履歴に見覚えのない操作が無いかも見ておきます。SaaSの設定とアカウントを定期的に点検する方法はSaaSセキュリティ対策の実装手順にまとめました。

KARTEに送っている個人データ項目の一覧と、委託元としての報告に備える手順

KARTEに顧客の氏名・メールアドレス・会員IDなどを送っている場合、法律上はプレイドに個人データの取扱いを委託している関係になります。個人情報保護法ガイドライン（通則編）の3-5-3-2は、委託先で漏えい等が起きた場合、委託元と委託先の双方が報告義務を負い、連名で報告できるとしています。不正アクセスによる漏えいは件数にかかわらず報告の対象です。

漏えいが公表されてから項目を調べ始めると、速報の期限に間に合いません。今のうちに、計測タグやユーザー情報の送信、Datahubの連携でKARTEに渡している項目を一覧にし、どの項目が個人データにあたるかを確かめておきます。ホワイトペーパーに記載されたデータの保管先は、GCPの台湾・米国・東京リージョンとAWS東京リージョンです。外国でデータを扱う場合に安全管理措置の一つとして求められる「外的環境の把握」について、プライバシーポリシー等で公表している内容とずれていないかも、同時に見ます。報告の期限と流れは個人情報保護委員会への報告義務の実務、委託先に何を求めるかは委託先管理と個人情報保護法25条の監督義務で解説しています。

再開後の判断：KARTEのタグを戻す条件と、外部タグ依存を減らす設計の見直し

続報で侵入経路が示されるまでタグを戻さない場面と、そのまま戻してよい場面

再開の告知が出ても、続報で侵入経路と影響範囲が示されるまでは、タグとデータ連携を元どおりに戻さない場面があります。判断の分かれ目は、侵入がサイトに配信される側に及んだかどうかです。

タグを戻さないのは、次のどちらかにあてはまる場合です。続報で、配信される接客やスクリプトの内容が改ざんされた可能性が示された場合。あるいは、会員の氏名・メールアドレスなど機微度の高い項目を計測タグで送っていて、漏えいの有無がまだ示されていない場合です。前者はサイトを訪れた人に影響が及ぶため、後者は止めている間に送るデータを減らす設計に変えられるため、戻すのを待ちます。

侵入が管理画面や社内の環境にとどまり、配信内容への影響が無いと明示されたなら、そのまま戻して構いません。計測の停止が長引くほど、セグメントや配信条件に使う行動データの欠けが広がるからです。

CSPのReport-Onlyで外部スクリプトの取得先を把握し、依存を減らす順番

今回のように外部タグが一斉に止まる事態は、KARTEに限らずどのタグでも起こります。まず把握する対象は、サイトがscriptを読み込んでいる取得先の正確な一覧です。Content-Security-Policy-Report-Onlyヘッダーを使うと、読み込みを止めずに、許可リストから外れた取得先を報告として受け取れます。数週間ためてから、本番のCSPで許可する取得先を絞ります。

次に、外部へ送るデータを減らします。行動データを外部SaaSに直接送るのでなく、自社のデータ基盤にいったん集め、必要な項目だけを外へ渡す構成にすると、ベンダーの停止や事故の影響を受ける範囲が小さくなります。構成例はBigQueryでCDPを構築する構成で紹介しました。サイトに埋め込んだ外部タグの棚卸しや、外部連携を含むWebシステムの弱点を第三者の目で洗い出したい場合は、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

KARTEの不正アクセスと全機能停止について、利用企業の担当者と開発者から出やすい質問をまとめました。2026年11月13日夕方時点の公表内容にもとづきます。

KARTEの不正アクセスで個人情報は漏えいしましたか？

11月13日夕方の時点で、プレイドは個人情報の漏えいの有無を公表していません。適時開示とステータスページに書かれているのは、第三者からの不正アクセスを検知したこと、全プロジェクトでKARTE全体を停止したこと、調査を進めていることです。件数や侵入経路も未公表です。新たな事実が判明したら速やかに知らせるとしているため、ステータスページとプレイドのお知らせを確認してください。

KARTEはいつ再開しますか？

ステータスページには、終了時期は現時点では未定と書かれています。11月13日14時44分の告知の後、15時00分に入った更新も、調査を続けているとの内容です。再開の告知はステータスページに出るため、メール・Webhook・RSSで購読しておくと見落としを防げます。社内の通知へ流したい場合は、本文で紹介した公開APIの監視コードを使えます。

KARTEが止まっている間、自社サイトは表示されますか？

多くの場合は表示されますが、計測タグの読み込み方式によります。async や defer を付けた読み込みやタグ管理ツール経由なら、タグが応答しなくてもページの解析は止まりません。async・defer の無い同期読み込みでheadに置いている場合は、取得先が応答しないとページの表示が遅れることがあります。本文の点検コードとChrome DevToolsのリクエストブロックで確かめられます。

KARTEの計測タグをサイトから外すべきですか？

11月13日の時点で、プレイドはタグの削除を求めていません。外すかどうかは、続報で侵入経路と影響範囲が示されてから決めます。配信される接客やスクリプトの改ざんの可能性が示された場合は外す判断です。管理画面側にとどまると示された場合はそのまま再開を待ちます。会員の氏名やメールアドレスなど機微な項目をタグで送っている場合は、送る項目を減らす見直しを先に進めます。

止まった一括メールは再開後にもう一度送ればよいですか？

そのまま再送すると、停止前に届いた人へ二重に送ることになります。再送するかを判断する前提は、配信対象の一覧と送信ログを突き合わせ、届いていない人だけを抜き出すことです。KARTEのログはUTCで記録されるため、14時44分（JST）の停止時刻と比べるときは時差の変換を忘れないようにします。締切や在庫に関わる内容なら、数日遅れの送信は避けます。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.11　テックブログ Microsoft 2026年11月の月例更新：Outlookの悪用済みCVE-2026-124194と修正版の確認方法
  2. 2026.11.11　テックブログ JANISの不正アクセス：最大11,652名の医療機関情報と情報窃取プログラムの検知設定
  3. 2026.11.11　テックブログ SMBC日興証券の不正アクセス：持株会会員最大5.6万人の範囲と受託システムの分離設計
  4. 2026.01.21　コラム 税務調査の録音は禁止？判例・裁決と国税局マニュアルで見る、断られたときの対応
  5. 2026.11.09　テックブログ ステップゴルフ不正アクセス：口座情報の対象確認と偽連絡・引き落としの注意点

RELATED POSTS 関連記事

一覧へ戻る

目次