>
>
公開日
アララ株式会社のメール配信サービスへの不正アクセスについて、確認済みの情報と未確認事項を整理し、情シスがメール配信の委託先・再委託先へ預けた顧客データを把握する方法を解説します。アカウント、API連携、配信リストの棚卸し台帳と判断基準を提示し、調査前の削除や件数の重複集計といった失敗を防ぎます。
アララの不正アクセスとは
アララの不正アクセスは、アララ株式会社が提供するメール配信サービス「アララメッセージ」が第三者による不正アクセスを受け、委託元の企業が預けていたメールアドレスなどが外部に持ち出された恐れがある事案です。親会社のペイクラウドホールディングスとアララ株式会社が、連名で公表しています（ペイクラウドホールディングスとアララの発表（2026年11月6日））。
本記事のポイント
公表された全体件数と自社の影響件数は別に扱います。
直接契約がなくても再委託の経路を調べます。
棚卸しはアカウント・API連携・配信リストを照合します。
対象は、法人でメール配信の契約管理・顧客データ管理を担う情シス担当者・管理者です。
公表の経緯
最初の公表は10月29日です。その後の調査で影響範囲が第1報を大きく上回ることが分かり、11月2日の第2報と11月6日の第3報で内容が改められました。
10月28日から30日：送信元「news@arara.com」から、クレジットカード会社を装った不審メールが最大約713万通送信されました。
10月29日：第1報。
10月31日：「アララメッセージ」のすべてのサービスが停止されました。再開の時期は未定です。
11月2日：第2報。第1報の内容が改められました。
11月6日：第3報。持ち出されたメールアドレスは重複を除いて81,329,467件（持ち出された恐れのあるものを含む）、対象の契約企業は最大約380社（推計、精査中）とされました。
持ち出された情報には、メールアドレスのほか、契約企業によっては氏名、性別、生年月日、電話番号、会員番号、住所などの会員情報が含まれるとされています。自社が預けていた項目は、委託先からの回答で確かめます。
不審メールへの注意
発表では、不審メールの件名として「利用内容確認のご依頼」「ご利用明細確認のご依頼」などが挙げられています。このようなメールが届いた場合は本文中のURLにアクセスせずに削除し、カード情報などを入力してしまった場合はカード発行会社に連絡するよう呼びかけています。自社の顧客や従業員から問い合わせがあったときに、窓口で同じ案内ができるよう準備しておきます。
契約で使われている名称の確認
各社の発表には、アララ株式会社が提供するサービスとして「アララメッセージ」と「repica」の二つの名称が出ています。コナカは、連結子会社がメール配信に利用している外部サービス「repica」の提供元であるアララ株式会社のサーバーが、第三者による不正アクセスを受けたと公表しています（コナカの発表（2026年11月5日））。自社の契約書・請求書・配信管理画面に「アララメッセージ」「repica」「アララ株式会社」のいずれかの表記があるかを調べ、表記ごとに台帳へ記録します。自社の契約が対象環境に含まれるかは、委託先からの回答で確かめます。台帳で押さえるのは、自社データの預託先、つまり外部にデータを預けた先です。
初動の優先順位
初動の優先順位は、①設定・契約・配信履歴の保存範囲を決める、②業務ごとに預託経路を台帳へ書き出す、③経路が不明なものを判定保留にして契約管理部門と配信業務の担当部門へ照会する、の順です。次章では、冒頭の説明の根拠となる公式発表を示し、公表された被害範囲と未確認事項を分けて整理します。
公式発表で分かる被害範囲と未確認事項
アララの不正アクセスに関する数値は、発信者と集計対象をそろえて読む必要があります。サービス全体の被害規模と、委託元企業が公表した自社分の件数を分けることが、影響範囲を判断する出発点です。
公式発表の数値
ペイクラウドホールディングスの公式発表が示す全体件数は、個別の委託元企業の件数を示すものではありません。
ペイクラウドホールディングスは、「アララメッセージ」への不正アクセスにより、持ち出された恐れのあるものを含めて重複を除くメールアドレス81,329,467件が対象となり、対象契約企業は推計で最大約380社に上ると発表しています。出典は、ペイクラウドホールディングスの不正アクセスに関する公式発表（2026年11月6日）です。メールアドレスの件数と契約企業数では単位が異なり、企業数には推計という条件が付いています。
全体件数を契約企業数で割って自社の被害件数を見積もったり、メールアドレス数をそのまま被害人数に置き換えたりする扱いは避けます。発表全体の規模は把握できても、個別企業の預託データとの対応までは、この数値だけでは判断できないためです。
委託元の公表範囲
カカクコムの公表件数は、同社が説明する影響範囲として読み、サービス全体の件数には加算しません。
カカクコムは、アララ株式会社のメール配信サービスからメールアドレスが外部に流出したとして、漏えいした個人情報を約570万件と公表しています。出典は、カカクコムのメールアドレス流出に関するプレスリリース（2026年11月5日）です。これは、委託元の1社が自社分として公表した件数です。全体件数とは公表の対象範囲が異なるため、別枠の被害として足し合わせると集計を誤るおそれがあります。
出典を社内報告に使う場合は、次のように発信者と件数の単位をそろえて整理します。
発信者 | 資料の日付 | 対象 | 件数の単位 | 確定または推計 | 自社への適用可否 |
|---|---|---|---|---|---|
ペイクラウドホールディングス | 2026年11月6日 | アララメッセージで持ち出された恐れのあるものを含むメールアドレス | 重複除外後81,329,467件 | 公表値 | 自社分として転用不可 |
ペイクラウドホールディングス | 2026年11月6日 | 対象契約企業 | 最大約380社 | 推計 | 自社が対象かは確定不可 |
カカクコム | 2026年11月5日 | 同社が公表した漏えい個人情報（メールアドレス）の件数 | 約570万件 | 流出確認の公表値 | 他社の件数へ転用不可 |
公表情報の扱い
ペイクラウドホールディングスとアララの連名による公式発表と、委託元各社の発表は、区別して読みます。報道や解説記事に出ている件数や期間のうち、公式発表で確認できないものは、本記事では事実として扱いません。公式発表は続報で数値が改められることがあるため、社内報告には参照した発表の日付を添えます。
自社宛ての通知などで対象データと件数の対応が確認できれば、その範囲を自社の影響として整理します。対応が確認できなければ、全体公表値を自社分の代わりに使わず、社内報告では「自社の対象・件数は未確定」と分けて記載します。
直接契約のない配信先まで含めたデータ経路の把握
直接契約先だけでなく、実際にメールアドレスを受け取る再委託先までデータ経路を整理します。再委託先とは、自社の委託先から業務の一部を受ける事業者です。
契約経路とデータ経路
メール配信を委託している場合は、どの業務の、どのデータが、どの経路で渡るかを台帳の管理単位にします。
アララの不正アクセスに伴う自社への影響を調べる際も、直接契約の有無だけで対象を絞らず、契約書・委託仕様書・配信設定・社内申請を照合する運用にします。契約上の委託範囲と実際の受け渡し先を分けて記録すれば、資料間の食い違いを追えます。
台帳には、次の項目を設けます。同じ契約先でも業務や経路が異なる場合は行を分けます。
台帳項目 | 記録する内容 |
|---|---|
業務名・主管部門 | 配信の目的と、その業務を管理する部門 |
直接契約先・再委託先・サービス表記 | 契約上の相手、実際の受領先、資料や設定画面上の名称 |
預託データ項目・受け渡し方法 | 渡す情報の種類と、送付・連携の方法 |
根拠資料・確認状態 | 照合した資料と、確認済み・照会中などの状態 |
氏名などの属性情報は、自社が実際に預けたデータに含まれる場合だけ記録し、報道された項目をそのまま転記しません。
部門ごとの管理責任
資料を持つ部門が分かれる場合は、照合する役割と台帳を更新する担当を決めます。
契約主管部門は契約書・委託仕様書から再委託の範囲を、配信業務の主管部門は社内申請から利用目的と対象リストを整理する分担にします。配信設定を管理する部門が受け渡し先を照合し、台帳担当へ結果を集約すれば、契約先名とサービス表記が異なる場合も根拠を残せます。資料の収集には手間がかかるため、同じ確認を繰り返さないよう回答と根拠資料を一緒に保存します。
経路不明時の扱い
再委託経路と対象リストが対応すれば影響判定の候補へ進め、経路が不明なら「対象外」ではなく「判定保留」にします。
契約主管部門へ再委託先と業務範囲を照会します。経路を裏付ける回答が得られれば対象リストとの照合へ進み、得られなければ保留を継続します。
配信業務の主管部門へ該当リストの預託有無を照会します。経路との対応が確認できれば影響判定の候補に加え、対応しないことを裏付けられれば候補から外す判断材料にします。
経路の一致だけで漏えいを断定せず、事業者からの通知と突き合わせます。照会では、自社の契約識別子と預けたリストの識別子を示し、次の3点を尋ねます。回答は台帳の根拠資料欄に保存します。
照会文の例
件名：メール配信サービスへの不正アクセスに関する確認のお願い（契約番号：＿＿＿＿）
貴社が公表された不正アクセスの件について、当社契約分への影響を確認させてください。当社の契約番号は＿＿＿＿、対象として想定している配信リストは＿＿＿＿です。
当社の契約と配信リストは、今回の対象環境に含まれますか。
当社のデータの取り扱いを、別の事業者へさらに委託していますか。委託している場合は、事業者名と対象業務を教えてください。
当社への個別の通知は、いつごろの予定ですか。
いただいた回答は、当社の影響判定の根拠として保管します。
▲ 直接契約の有無にとどまらず再委託先へのデータ経路まで把握する社内外の管理体制。
棚卸しで避けたい失敗パターン
棚卸しで起きやすい失敗は、記録を残す前の一括削除と、直接契約がないことを理由にした対象外判定の二つです。どちらも、調査に必要な記録や、調べるべき経路を失う原因になります。
調査前の一括削除
停止や削除を検討する場合は、契約・配信履歴・設定情報の保存範囲と、保存・閲覧・削除を行う権限を、個人情報保護部門・法務の判断に従って決めてから進めます。両部門が保存の範囲や期間を示した場合は、その内容を台帳の保存範囲欄へ優先して反映します。先にアカウントやリストを消すと、どの部門が、どの委託先へ、何を預けたかを照合できなくなるおそれがあります。
個人情報保護委員会のガイドライン（通則編）の3-5-2は、漏えい等事案が発覚した場合に講ずべき措置として、「事実関係の調査及び原因の究明」と「影響範囲の特定」を挙げています（個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」3-5-2）。記録を先に消すと、こうした調査や特定に使う材料が残りません。
保存時は対象期間、保管先、管理責任者、保存期限も記録します。継続中の配信がある場合は、停止の影響と代替手段を利用部門と整理し、必要な記録を確保したうえで停止・削除の範囲を決めます。ただし、証跡を残す目的でも、顧客データを無制限に複製してはいけません。
件数と対象外判定の混同
件数は集計単位を明記し、対象外かどうかは契約の有無ではなく、データが預けられた経路と保存状況で判断します。ペイクラウドホールディングスの不正アクセスに関する発表では、持ち出された恐れのあるものを含むメールアドレスを「重複を除いて計81,329,467件」としています。この数をそのまま対象者数として扱うことは避けます。
延べ登録件数、重複排除したアドレス数、対象者数は別の項目で管理します。同じ人が複数のアドレスを使う場合もあるため、アドレス数だけで人数は確定できません。
失敗 | 判断が止まる理由 | 代替手順 |
|---|---|---|
記録保存前の一括削除 | 契約と配信実態を照合できません。 | 保存範囲と権限を決め、記録確保後に停止・削除へ進みます。 |
直接契約なし・未使用で対象外 | 委託先経由の預託や残存リストを見落とします。 | 預託経路と保存状況を調べ、除外根拠を残します。 |
異なる単位の件数を合算 | 重複や人数との差を説明できません。 | 集計単位と重複排除の条件を分けて記録します。 |
照合用の全件エクスポート | 複製先の管理が増えます。 | 管理画面で足りる場合は集計値と識別情報に絞り、明細が必要な場合だけアクセス制限下で扱います。 |
▲ 棚卸し実務で陥りやすい失敗パターンと推奨される代替手順の対応関係。
アカウントと利用部門の棚卸し手順
アカウントの棚卸しでは、各アカウントがどの顧客データの預託先になっているかを整理します。そのために、利用者名に加えて、契約・利用部門・配信リストとの対応まで記録します。
対象アカウントの抽出
契約台帳、請求情報、部門の利用申請、管理画面上の一覧の順に突き合わせ、調査対象を抽出します。
契約台帳から対象サービスの契約を拾い、契約識別子と契約主管部門を控えます。ここでの契約主管部門は、契約内容の確認や調整を担う部門です。
請求情報と照合し、台帳に対応する契約がない請求や、契約名と利用部門名の違いを調査対象に加えます。名称だけで同一契約と判断せず、根拠資料を残します。
部門の利用申請と突き合わせ、申請者、利用目的、環境名を対応付けます。情シスの管理外で利用されている可能性は調査仮説として扱い、発生事実とは区別します。
管理画面を参照できる場合は、表示されるアカウント一覧と照合します。一覧の出力などは利用サービスで取得できる範囲に限定し、参照できない項目は「未確認」と記録します。
所有者と利用状態の照合
抽出したアカウントごとに、責任を持つ部門と保存データを同じ記録上で結び付けます。
次のテンプレートをアカウント単位で作成します。複数の配信リストを扱う場合は関連リスト欄に列挙し、対応関係が分からないものは推測で埋めず、未確認とします。
記録項目 | 記入欄 |
|---|---|
契約識別子 | ＿＿＿＿ |
環境名 | ＿＿＿＿ |
アカウント識別子 | ＿＿＿＿ |
主管部門 | ＿＿＿＿ |
管理担当 | ＿＿＿＿ |
利用状態 | ＿＿＿＿ |
関連リスト | ＿＿＿＿ |
データ保有状態 | ＿＿＿＿ |
根拠資料・確認日 | ＿＿＿＿ |
利用状態とデータ保有状態は別々に記入します。利用していないという部門回答だけではデータなしとせず、画面や保管資料で裏付けられなければ、データ保有状態は未確認として残します。
不明アカウントの処理
所有者が分からないアカウントは削除せず、判定保留として契約主管部門へ引き継ぎます。
所有者と対象リストが判明した場合は、その対応表と根拠資料を次の連携調査へ渡します。
所有者不明の場合は、照合済みの資料と未解決事項を添えて契約主管部門に引き継ぎ、回答を記録します。契約主管部門も不明なら、契約台帳の管理担当を引継ぎ先の調整窓口とします。
未使用でも保存データがある場合は、リスト調査を継続します。保存の有無が未確認の場合も、利用停止だけを理由に対象から外しません。
作業の完了条件は、対象アカウントごとに主管部門とデータ保有状態を記録できた状態です。不明項目を残した記録は引継ぎ用とし、解消するまで完了扱いにしません。ログインできることや契約が有効であることだけを完了基準にせず、整理した対応表を連携経路の調査へつなげます。
API連携とデータ転送経路の棚卸し手順
API連携の棚卸しでは、何のデータをどの配信先へ送っているかを洗い出します。APIはシステム同士がデータを受け渡す仕組みです。顧客データが継続的に渡る経路を、転送元・転送項目・転送先・実行時点で整理し、保存先の配信リストと対応付けます。
連携経路の抽出
業務システムの設定、定期処理、手動ファイル取込の運用資料を調べ、データの入口を洗い出します。設定を管理する部門と配信業務の担当部門で資料を持ち寄り、処理名だけでなく、どの業務で何を送っているかを照合します。
APIだけを調査して完了にしてはいけません。同じ配信リストへ別の定期処理や手動取込でデータを追加している可能性も点検します。経路ごとに識別名を付ければ、同じ保存先に流れ込む処理を区別して追跡できます。
転送内容の照合
台帳には、送信設定と保存先リストを照合できる情報を記録します。記録項目は、転送元、転送先のアカウントとリスト、送信項目、実行条件、最終実行の記録、処理責任者、判断の根拠です。
実行条件には定期実行の時刻や業務上の契機を記し、最終実行の記録とは分けます。設定が残っていることと、実際に転送されたことを混同しないためです。送信項目は項目名で記載し、顧客データそのものは台帳へ転載しません。根拠欄には設定資料や実行記録の保管場所を残し、後から判断をたどれる形にします。
記録の取得可否による分岐
実行記録で送信先まで確認できた経路は確定情報、設定や担当部門の回答だけで確認した経路は推定情報として分けます。
実行記録と送信先が対応する場合は、その経路を対象のアカウント・リストへひも付け、確認できた実行時点を記録します。
実行記録が取得できない場合は、設定、処理仕様、担当部門の回答で補います。設定上の送信先と実行済みかどうかを分け、裏付けのない部分は推定として残します。
記録が見つからないだけで「転送なし」と判断したり、取得できない理由をサービスの仕様と断定したりしません。取得できた資料の範囲を台帳に残し、未確定の経路は確認済みの経路と区別します。
経路を変更する場合は、記録を確保してから、次の順序で判断します。
順序 | 実施内容 |
|---|---|
1．経路の特定 | 転送元から保存先リストまでを対応付けます。 |
2．記録の保存 | 設定、実行記録、判断の根拠を保管します。 |
3．停止影響の把握 | 業務通知に使う経路なら、停止の影響と代替手段を決めます。 |
4．必要な承認 | 処理責任者と関係部門で変更範囲の承認を得ます。 |
5．変更 | 不要な転送と判断できた経路は承認後に停止し、変更内容を台帳へ反映します。 |
▲ API連携やデータ転送経路を変更する際の5段階の判断手順。
配信リストと預託件数の棚卸し手順
配信リストは、登録件数、データ項目、更新経路、保存時点の4つをそろえて整理します。
配信リストの一覧化
アカウントと連携経路の調査結果を、配信リスト単位の台帳に統合します。サービス内に保存されている場合は、通常配信のほか、停止中・検証用・配信除外用のデータも対象に含めます。配信に使われていないことと、データを預けていないことは別です。
管理画面の出力や登録時のファイルが残っていれば、識別子を手掛かりに関連付けます。名称だけでは同名リストを区別できない場合があるため、関連アカウントと組み合わせて記録します。次の台帳は、リストごとに複製して記入する形式です。
配信リストの記入用台帳 | |
項目 | 記入欄 |
|---|---|
配信リスト識別子 | ＿＿＿＿ |
業務目的 | ＿＿＿＿ |
主管部門 | ＿＿＿＿ |
関連アカウント | ＿＿＿＿ |
更新経路 | ＿＿＿＿ |
保存項目 | ＿＿＿＿ |
登録件数 | ＿＿＿＿件 |
件数の定義 | 行数・重複排除後のアドレス数など：＿＿＿＿ |
抽出時点 | ＿＿年＿＿月＿＿日＿＿時 |
保存期限 | ＿＿＿＿ |
判定状態 | ＿＿＿＿ |
根拠資料 | 資料名・取得日時・保管先：＿＿＿＿ |
件数と対象範囲の照合
預託件数は、同じ定義と保存時点の証跡を使って照合します。登録ファイル、更新記録、サービスからの出力がそろう場合は、追加・削除の差分まで追い、食い違いが残れば理由を未解決事項として記録します。
現在の登録件数だけで、過去の流出件数を確定してはいけません。過去の保存状態を再現できなければ、現在値を過去値の代わりにせず、再現できない期間を残します。
サービス側の対象環境と、自社のアカウント・リスト・保存時点が対応する場合は「影響対象候補」とします。これは流出確定とは区別します。
対象外とする根拠がある場合は「対象外」とし、判断に用いた資料と対象期間を記録します。
対応関係や保存時点の根拠が不足する場合は「判定保留」とし、不足資料と照会先を残します。
判定結果と運用への引継ぎ
棚卸しは、判定結果、未解決事項、次の担当者、再確認期限を台帳に記録した時点で完了とします。情シス・業務主管・契約主管の役割と完了条件は、次のフェーズ表で管理します。
フェーズ | 情シス | 業務主管 | 契約主管 | 完了条件 |
|---|---|---|---|---|
着手時の範囲設定・証跡保全 | 取得可能な証跡を保全 | 停止中を含むリストを列挙 | 契約上の預託範囲を整理 | 調査範囲と証跡の保管先を記録 |
照合時のアカウントと経路の突合 | アカウント・更新記録を突合 | 保存項目と件数の意味を整理 | 委託先への照会を管理 | 各リストの経路と保存時点、差分を記録 |
判断時の対象候補と保留の整理 | 技術的な対応関係を整理 | 対象業務とデータ範囲を整理 | 回答資料と契約条件を照合 | 判定根拠、保留理由、担当と期限を記録 |
以後の委託変更・運用終了時の台帳更新 | 連携停止と保存状態を記録 | 業務終了と保存要件を整理 | 返却・削除条件を整理 | 保存要件と証跡保全を整理後、削除可否と結果を記録 |
報告時は台帳に照合資料を添え、説明できる預託範囲と判定保留の範囲を分けたうえで、個人情報保護部門・法務へ渡します。通知文面や当局への届出の要否は両部門が判断するため、情シスの作業は判断材料となる台帳と根拠資料の提供までです。保留が残る場合も棚卸し結果から外さず、追加資料の入手後に誰が再判定するかまで引き継ぎます。
まとめ
アララの不正アクセスでは、公式発表の全体件数と自社の影響範囲は別として、再委託経路・アカウント・API連携・配信リストを対応付けて判断します。
現在メール配信を利用しているなら、翌営業日に、実際の配信業務から台帳を作り始めます。主管部門と契約先を記入し、データを預けている預託先までの経路を埋めます。たとえば、業務名「会員向け月次案内」、主管部門「マーケティング部」、直接契約先「A社」、再委託先「照会中」、預託項目「メールアドレス」、確認状態「判定保留」と1行にまとめ、A社へは自社の契約識別子とリスト識別子を示して、対象環境への該当、再委託先の有無、通知予定時期の3点を尋ねます。根拠となる契約書や回答記録を保存し、経路と対象リストが特定できれば影響判定へ進み、不明点は「影響なし」とせず判定保留として残します。
主管部門と契約先の対応
預託先と対象リストの対応
記録の保存と判定保留事項の記載
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
