株式会社アイルの店舗・EC顧客統合サービス「CROSS POINT」で、導入企業1社専用の正規API認証キーが外部に流出し、そのキーで会員情報が取得されました。2026年11月10日の公表によると、11月7日未明に検知され、11月9日22時15分には全利用企業のAPIアクセスキーが無効化・再発行されています。前半で整理するのは、公表文で分かる経緯と取得された項目、会員が確かめることです。後半では、EC・POS側に保存した認証鍵の入れ替え、正規キーによる一括取得をログから見つける実装、API提供側の設計、個人情報保護委員会への報告の分担を扱います。
まとめ：CROSS POINTの不正アクセスで起きたことと導入企業が今週やる4つの作業
アイルの公表文によると、今回の不正アクセスはデータベースへの侵入でもプログラムの脆弱性でもありません。ある導入企業のために発行された正規のAPI認証キーが外部に漏れ、第三者がそのキーで会員情報取得APIを呼び出しました。システムから見れば、正しい鍵を持った通常の呼び出しです。
| 項目 | 公表文の記載 |
|---|---|
| 検知 | 2026年11月7日未明 |
| 経路 | 会員情報取得API（正規キーの悪用） |
| 対象 | 導入企業1社の会員情報の一部 |
| 対象外 | カード情報・ログインパスワード（非保持） |
| 全社対応 | 11月9日22時15分に全利用企業のキー再発行 |
| 未公表 | 件数・企業名・キーの流出経路 |
導入企業と連携の保守を担う開発者がやることは4つです。EC・POSなどに保存している認証鍵がどこにあるかを洗い出し、新しい値に揃える。古い鍵がリポジトリや共有フォルダに残っていないか確かめる。自社側にもAPIの呼び出しログがあれば、キーごとの取得件数を数えて異常を探す。会員の個人データを預けている立場として、報告と本人通知の要否を判断する。
公表文で分かる範囲：11月7日の検知から全利用企業のキー再発行までの経緯
CROSS POINTの役割と、APIでつながるEC・POS・メール配信の範囲
CROSS POINTの製品サイトは、このサービスを実店舗とECサイトのポイント・顧客情報を一元管理するASPと説明しています。会員ランク、保有ポイント、購買データの分析、会員アプリなどを持ち、APIでPOSシステム、ECシステム、メール配信システムとつながります。
つまり会員の氏名や住所、ポイント残高は、店舗とECの両方から参照される前提で1か所に集まっています。APIのキーが1本漏れると、そのキーに許された範囲の会員データがまとめて読めてしまう構造です。会員管理を外部サービスに置く場合と自社で持つ場合の違いは会員管理システムの機能と移行の判断基準で整理しました。
当該キーの無効化から全利用企業の再発行まで、2日半で行われた対応の順序
公表文に沿って対応を並べると次の順です。
- 11月7日未明：外部からの不正アクセスを検知
- 当該企業のAPIアクセスキーを無効化して再発行し、アクセス元を遮断
- 11月9日22時15分：全利用企業のAPIアクセスキーの無効化と再発行を完了
- アクセスログの詳細調査、監視体制と不正検知の仕組みを強化
他の利用企業では漏えいの痕跡はない、とアイルは書いています。それでも全社のキーを入れ替えたのは、同じ経路でほかのキーも漏れている可能性を消すためと読めます。緊急メンテナンスの案内が直前になったことへのお詫びも添えられており、連携先の側では準備の時間がほとんど無かったはずです。
公表されていない事項と、続報を待たずに推測で埋めてはいけない3点
11月10日時点で、取得された件数、被害を受けた導入企業の名前、キーがどこから漏れたかは公表されていません。漏れた場所が導入企業の設定ファイルなのか、連携先の事業者なのか、担当者の端末なのかで、ほかの企業がとるべき対策は変わります。
この記事では流出経路を推測しません。代わりに、どの経路であっても効く作業を後半に置きます。経路が公表された時点で、該当する作業の優先度を上げてください。
取得された会員情報の項目と、会員本人が確かめることと警戒する連絡の型
氏名・住所から保有ポイント・購買統計まで、公表された14項目の中身
公表文が挙げる取得項目は次の14種類です。導入企業が登録していた項目のうち、会員情報取得APIで返る範囲が対象になったとみられます。
- 氏名、生年月日、性別、郵便番号、住所、電話番号、携帯電話番号、メールアドレス
- 会員番号、会員ランク情報、保有ポイント情報、リアル店舗カード番号
- ネットショップ会員ID、購買統計情報
クレジットカード情報とログインパスワードは、CROSS POINTの中に持っていないため対象外です。ただし店舗カード番号とネットショップ会員IDが氏名・電話番号と結び付いた状態で出ているので、ポイントの不正利用やなりすましの連絡には材料がそろっています。
対象の導入企業は1社、会員が自分の該当を知る経路は店舗やECからの連絡
対象は導入企業1社で、その会社の名前は公表されていません。アイルの公表文には個人向けの窓口も書かれていません。CROSS POINTの会員は、ポイントカードを作った店舗やECサイトの会員として登録されているため、自分が該当するかは、その店舗やECからの連絡で確かめることになります。
購買統計と会員ランクまで知られていると、「ランク特典の確認」「ポイント失効前のご案内」を装う連絡は本物らしく見えます。メールやSMSのリンクからログインせず、普段使っているアプリかブックマークから開いて残高を確かめるのが安全です。
連携側の作業：EC・POSに保存した認証鍵の置き場所を洗い出して入れ替える手順
ebisumartとショップサーブの連携設定で入力する認証鍵とテナントコード
CROSS POINTとつなぐ側では、アイルが発行した値を自社の管理画面に保存しています。ebisumartのサポートページでは、システム設定マスタの初期設定にテナントコード、ショップコード、認証鍵、接続先URL、アプリキーを入力します。ショップサーブのヘルプでも、テナントコード、API接続URL、認証鍵、アプリキーを入れて保存するとAPIが有効になる手順です。
公表文の「APIアクセスキー」が、これらの画面の「認証鍵」と同じものかは公表文から読み取れません。とはいえ全利用企業のキーが入れ替わった以上、連携先に保存した値も新しいものに揃える前提で動きます。ebisumartの例でこのAPIを通るのは、会員の登録や更新、注文時のポイント付与、ログイン時のポイント残高の取得です。古い値のままだと、ポイントが付かない・残高が表示されないといった形で表に出ます。
カート以外に鍵が残る場所：POS、会員アプリ、バッチ、検証環境の一覧化
認証鍵はカートの管理画面だけにあるとは限りません。洗い出しの対象を、見落としやすい順に並べます。
- 検証環境やデモ環境の設定（ebisumartには本番とは別の「テスト用」の入力欄がある）
- 独自に組んだ連携バッチや会員データの移行スクリプトの設定ファイル・環境変数
- POSレジ、会員アプリ、メール配信ツールの連携設定
- 導入時の設定手順書、チャット、チケットに貼られた値
一覧ができたら、新しい値を入れる場所と担当者を1行ずつ埋めます。全部を入れ替え終えたら、古い値はどの場所からも消します。発行・保管・失効までの運用の型はAPIキーの発行・保管・失効とローテーションの実装にまとめました。
古い認証鍵がGitの履歴に残っていないかを調べるコマンドと検出の仕組み
鍵を設定ファイルに書いてリポジトリに入れたことがあるなら、ファイルから消しても履歴には残ります。古い鍵の先頭の数文字で、作業ツリーと全ブランチの履歴を探します。
# 古い認証鍵の先頭8文字（例：ab12cd34）で探す。鍵の全体はコマンドに打たない
git grep -n "ab12cd34"
# 全ブランチの履歴から、その文字列を追加・削除したコミットを探す
git log --all --oneline -S "ab12cd34"見つかったコミットがあれば、そのリポジトリを誰が見られたかを確かめます。外部の委託先や退職者がアクセスできたなら、漏れた可能性のある経路として記録が必要です。今後の混入を止めるには、プッシュ時に鍵の形をした文字列を検出するGitHubのシークレットスキャンのような仕組みを使います。SaaS側の侵害で鍵を交換した別の事案はTiDB CloudのAPIキー交換と監査ログ確認、StudioのAPIキー・Webhook URLの交換手順で扱いました。
正規キーによる一括取得を見つける：キー別・時間別の参照会員数を数える実装
正規キーの呼び出しは認証を通る、だから件数と送信元で異常を見る
今回のような悪用は、認証の失敗としては記録されません。キーは本物なので、APIは正常に応答します。異常として見えるのは、呼び出しの量と相手です。普段は店舗やECの操作に合わせて1件ずつ参照される会員情報が、短い時間に番号順でまとめて読まれる。連携先のサーバーではないIPアドレスから呼ばれる。この2つを数えます。
次のコードは、APIのアクセスログ（1行1件のJSON）から、キーと1時間の組ごとに参照された会員の数と送信元IPを集計します。自社でCROSS POINTと同じ形の会員APIを提供している場合や、APIゲートウェイのログを持っている場合に使えます。
# APIアクセスログ（JSON Lines）から、キーごと・1時間ごとの参照会員数と送信元を集計し、
# 正規キーによる一括取得の兆候を出す（Python 3.9以上・標準ライブラリのみ）
import json, sys
from collections import defaultdict
from datetime import datetime
MAX_MEMBERS_PER_HOUR = 500 # 1キーが1時間に参照してよい会員数の上限
ALLOWED_IPS = {"203.0.113.10", "203.0.113.11"} # 連携先（EC・POS）の送信元IP
hits = defaultdict(lambda: {"req": 0, "members": set(), "ips": set()})
for line in open(sys.argv[1], encoding="utf-8"):
r = json.loads(line)
hour = datetime.fromisoformat(r["ts"]).strftime("%Y-%m-%d %H:00")
h = hits[(r["key_id"], hour)]
h["req"] += 1
h["members"].add(r["member_id"])
h["ips"].add(r["ip"])
for (key, hour), h in sorted(hits.items()):
alerts = []
if len(h["members"]) > MAX_MEMBERS_PER_HOUR:
alerts.append(f"members={len(h['members'])}")
unknown = h["ips"] - ALLOWED_IPS
if unknown:
alerts.append("unknown_ip=" + ",".join(sorted(unknown)))
mark = "ALERT " if alerts else "ok "
print(f"{mark}{key} {hour} req={h['req']} {' '.join(alerts)}")ログの項目名（ts・key_id・ip・member_id）は自社のログ形式に合わせて読み替えます。上限の500人は仮の値で、過去30日の1時間あたりの最大値に余裕を足して決めます。
合成ログ3,400行で確かめた出力と、上限値を決めるときの失敗パターン
通常の連携120件、外部IPから会員番号を連番で読む3,200件、別キーの通常利用80件を混ぜた合成ログで実行しました。Python 3.14.10（Windows）で2026年11月10日に得た出力です。CROSS POINTのログ形式を再現したものではありません。
ok shop-a 2026-11-06 14:00 req=120
ALERT shop-a 2026-11-07 03:00 req=3200 members=3200 unknown_ip=198.51.100.77
ok shop-b 2026-11-07 03:00 req=80 同じキー shop-a でも、昼の通常利用は ok で、未明の連番取得だけが件数と送信元の両方で引っかかります。失敗しやすいのは、上限を月末のバッチ処理に合わせて高くしすぎる場合です。会員の一括同期を夜間に回している環境では、同期用と画面表示用でキーを分けないと、同期の量に紛れて抜き取りが見えなくなります。
APIの認可やレート制限、トークンの失効までを含む対策の全体は、JPCERTの注意喚起に沿うAPI不正アクセス対策の実装手順で解説しています。
API提供側の設計：キー1本で取れる項目と件数を絞るOWASP API3・API4の対策
会員情報取得APIが返す項目を用途ごとに分け、全項目を返さない設計
アイルは再発防止策として、APIで利用できる機能と取得できる情報を必要最小限にするとしています。これはOWASP API Security Top 10 2023のAPI3が挙げる対策と同じ方向です。API3は、返すデータ構造を業務上の必要最小限に保ち、オブジェクトを丸ごと変換する to_json() のような汎用メソッドを避けるよう求めています。
ポイント残高の表示に要るのは会員番号と残高と会員ランクで、住所や生年月日は要りません。画面表示用のキーには残高系の項目だけを返し、住所まで返すのは配送や会員情報の編集に使うキーに限ります。こうしておけば、表示用のキーが漏れても取られるのは残高までです。
レート制限と1回あたりの返却件数の上限、APIキー単体を認証にしない判断
API4は、一定時間内の呼び出し回数の制限と、1回の応答で返すレコード数の上限を設けるよう求めています。会員を1件ずつ参照するAPIでも、1時間あたりの回数に上限があれば、連番で数千件を読む動きは途中で止まります。
キー単体を認証の全部にしない判断も必要です。API2は認証の仕組みの不備を扱っており、漏れた鍵がそのまま使える状態はこの類型の典型です。サーバー同士の連携なら、送信元IPの制限か、クライアント証明書を使う相互TLSを重ねます。鍵が漏れても、許可された連携先のサーバー以外からは呼べなくするためです。送信元IPを固定できないスマートフォンアプリには、利用者ごとのトークンを発行し、会員本人の情報しか返さない作りにします。
個人情報保護委員会への報告：委託元の導入企業と委託先のアイルの分担と期限
不正の目的による漏えいは件数を問わず報告対象、確報は60日以内
個人情報保護法ガイドライン（通則編）では、不正の目的をもって行われたおそれのある漏えいは、件数にかかわらず報告の対象です。第三者が流出したキーで会員情報を取得した今回の事案はこれにあたるとみられます。速報はおおむね3〜5日以内、この類型の確報は事態を知った日から60日以内です。
会員の個人データの持ち主は導入企業で、CROSS POINTを提供するアイルは取扱いの委託先という関係です。ガイドラインは、委託している場合は原則として委託元と委託先の双方が報告義務を負い、連名で報告できるとしています。委託先が委託元へ通知した場合は、委託先の報告義務は免除されます。報告と本人通知の流れは個人情報保護委員会への報告義務の実務にまとめました。
対象外の導入企業が残しておく記録と、他社の事案で連名報告が選ばれた例
公表文によれば、ほかの利用企業では漏えいの痕跡がありません。対象外と知らされた導入企業に報告の義務は生じませんが、キーを入れ替えた日時、洗い出した保存場所、自社側のログで異常が無かったことは記録しておきます。続報で範囲が広がったとき、自社が対象外だった根拠になるためです。
委託先が多数の契約企業の報告を取りまとめた例として、アララの不正アクセスと連名報告の受付があります。CROSS POINTの件は11月10日時点で報告の方法が公表されていないため、対象企業がどちらの形をとるかは続報で確かめます。
判断：CROSS POINTを使い続ける条件と、連携の診断を外部に頼む範囲
CROSS POINTを使い続けてよい条件と、連携の作りを見直すべき導入企業の特徴
使い続けるかは、続報で次の2点が示されるかで判断します。キーがどこから漏れたかが特定され、その経路がほかの利用企業にも当てはまるかが説明されること。再発防止策のうち、権限の最小化と不正検知が具体的な仕組みとして示されることです。公表文はこの2つを調査中・強化中としているので、示されるまでは次の見直しを自社側で進めます。
見直しを急ぐべきなのは、1本の認証鍵を本番・検証・バッチ・POSで使い回している導入企業です。この形では、どこか1か所から漏れただけで全会員の情報が取れます。用途ごとにキーを分けられるか、送信元IPを登録できるかをアイルに確かめ、分けられないなら連携の作りを組み直します。同じく外部サービスの権限設定が起点になった事案はACCESS CROSのDB権限と送信キーの締め方で扱いました。
自社のEC・会員APIと外部サービスのつなぎ目を第三者に診断させる範囲
今回の事案で導入企業のシステム自体が破られたとは公表されていません。ただ、鍵をどこに置くか、どの項目を同期するか、誰が管理画面を見られるかは、導入企業と連携の開発者が決めている部分です。自社でも会員APIを外部に公開しているなら、キー1本で取れる範囲と取得上限が無い状態は同じ弱点になります。
自社のEC・会員システムと外部サービスの連携に同じ弱点が残っていないかを第三者に確かめてもらいたい場合は、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
CROSS POINTの不正アクセスについて、会員・導入企業・開発者から出やすい質問をまとめました。
CROSS POINTの会員ですが、自分の情報は流出しましたか？
対象は導入企業1社の会員で、その企業名は11月10日時点で公表されていません。ほかの利用企業では漏えいの痕跡はないとされています。CROSS POINTの会員は、ポイントカードやアプリを作った店舗・ECサイトの会員として登録されているので、該当するかはその店舗やECからの連絡やお知らせで確かめます。アイルの公表文に個人向けの問い合わせ窓口は書かれていません。
クレジットカード番号やパスワードは漏れましたか？
公表文によると、クレジットカード情報とログインパスワードはCROSS POINTの中に持っていないため、流出の対象外です。取得されたのは氏名・生年月日・住所・電話番号・メールアドレスなどの連絡先と、会員番号・会員ランク・保有ポイント・店舗カード番号・ネットショップ会員ID・購買統計情報です。会員ランクや購買の情報を使った本物らしい連絡に注意してください。
全利用企業のAPIキー再発行を受けて、連携先は何をすればよいですか？
11月9日22時15分に全利用企業のAPIアクセスキーが無効化・再発行されました。EC・POS・会員アプリ・連携バッチなど、アイルが発行した認証鍵を保存している場所を洗い出し、新しい値に揃えます。ebisumartやショップサーブで認証鍵などを入力する場所は、連携設定の画面にある専用の入力欄です。古い値はリポジトリや手順書からも消し、Gitの履歴に残っていないか確かめます。
正規のAPIキーが悪用されると、なぜ防げないのですか？
APIはキーが正しいかどうかで相手を判断するため、漏れたキーを使った呼び出しは正規の連携と区別できません。防ぐには、キーで取れる項目を用途ごとに絞る、1時間あたりの呼び出し回数に上限を設ける、送信元IPや相互TLSで呼び出し元を限定する、といった仕組みを重ねます。見つけるには、キーごとの参照件数と送信元IPをログで数えます。
導入企業は個人情報保護委員会へ報告する必要がありますか？
対象となった導入企業は、会員の個人データを委託している委託元として報告義務を負うとみられます。不正の目的による漏えいは件数を問わず報告対象で、確報の期限は事態を知った日から60日以内です。ガイドラインでは委託元と委託先の連名で報告できます。漏えいの痕跡が無いとされた導入企業に報告の義務は生じませんが、対応の記録は残しておきます。
関連記事
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：キーが漏れても被害を広げないAPI側の対策
- APIキー管理とは？発行・保管・失効とローテーションの実装を解説：認証鍵を入れ替えるときの運用の型
- TiDB Cloud不正アクセスの範囲と対応：APIキー交換と監査ログ確認の手順：SaaS側の事案で鍵を交換した別の例
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：委託元としての報告の流れ
- ACCESS CROS不正アクセス：BIツール起点の15万件流出とDB権限・送信キーの締め方：外部サービスの権限設定が起点になった事案
