印刷通販「ラクスル」を運営するラクスル株式会社は2026年11月9日、データ入稿の処理に関わるシステムへの不正アクセスを公表しました。保管していた印刷データ、請求書、Web郵便などに記載された個人情報が流出したおそれがあり、注文した本人だけでなく、名刺やはがきに記載された人も対象に入ります。本記事では、自分が対象か、届いた連絡が本物かを公式発表の文言で先に確かめ、続いて宛名リストを入稿した企業の報告義務と、入稿データを預かるシステムの点検手順をコード付きで解説します。
まとめ：ラクスルの不正アクセスで判明した事実と件数が未確定の範囲
2026年11月9日の第一報で確定しているのは、第三者がシステムの認証情報を不正に取得し、保管データの一部に外部からアクセスできる状態だったことです。対象の件数と対象期間の始まりは調査中とされています。原因の詳細、侵入の手口、利用していた基盤は公表されていません。
| 項目 | 第一報の内容 |
|---|---|
| 発覚 | 2026年11月8日 0時20分頃 |
| 対象システム | データ入稿の処理に関わるシステム |
| 対象のデータ | 印刷データ・請求書・Web郵便など |
| 対象の項目 | 氏名・会社名・住所・電話番号など |
| メールアドレス | 対象の項目に含まれる |
| 漏えいなしと確認 | カード情報・ログインID・パスワード |
| 対象件数 | 集計中 |
| 対象期間 | 調査中〜2026年11月8日 |
| 二次被害 | 第一報の時点で確認なし |
読者がまず行うのは、注文履歴の確認と不審な連絡への警戒の2つです。第一報はパスワードの変更を求めていません。宛名リストを入稿した企業は、これに加えて報告義務の確認が必要になります。なお、インターネット上で見かける「6,412件」は10月に公表された別の事案の数字で、今回の件数ではありません。
注文者と名刺・はがきの記載者が確かめる対象範囲と届いた連絡の見分け方
注文者が注文履歴から直近2年の名刺・はがき・DMを洗い出す手順
ラクスルの第一報は、対象をデータ入稿の処理に関わるシステムで保管していた情報としています。一方で対象期間は「調査中〜2026年11月8日」で、いつの注文からかは分かっていません。
洗い出しの目安になるのが、増刷の案内にある「データの保存期間は2年間」という記述です。増刷用の保存期間が今回の対象期間と一致するとは公表されていないため、あくまで本記事の目安ですが、まず直近2年の注文から確かめるのが現実的です。個人の情報が載りやすいのは次の4種類で、上から順に確かめてください。
- 宛名面を印刷したはがきやDM（送り先全員の氏名と住所）
- 名刺（本人の氏名、電話番号、メールアドレス）
- 請求書やWeb郵便（取引先の担当者名と住所）
- 顔写真や連絡先を載せたチラシ、冊子、社内報
会社名だけの封筒やロゴのみのステッカーは、個人の情報が載っていなければ急ぐ必要はありません。
注文していない名刺の持ち主やはがきの受取人が不審な連絡に備えて取る行動
第一報は「ご注文いただいたお客様の情報だけでなく、名刺やはがきなど、印刷物に記載された方の情報が含まれている場合があります」と書いています。つまり自分でラクスルを使ったことがなくても、取引先の名刺や知人のはがきを通じて対象に入る可能性があります。
この立場の人は、自分の情報が入稿されたかを確かめる手段を持ちません。第一報に、対象者へ個別に連絡するかどうかの記載もありません。現実的な備えは、身に覚えのない請求や配送の連絡を、ラクスルと関係があるかに関わらず疑うことです。勤務先の名刺が印刷された可能性があるなら、総務の担当者に発注先を確かめると状況が分かります。
メール・SMS・電話の真偽を判定する公式の一文と偽連絡の特徴
判定の基準は第一報の次の一文です。「お客様ご自身のお手続きによらず、当社からメールやSMSでパスワードやクレジットカード番号の入力をお願いすることはございません」。自分で何も操作していないのに入力を求められたら、偽物と判断してかまいません。URLを開かず、認証情報も入力しないでください。
流出したおそれのある項目には住所、電話番号、メールアドレス、会社名がそろっています。実在の注文内容や社名を挙げた連絡が来ても、それだけで本物の証拠にはなりません。確かめるときは届いたリンクを使わず、自分でラクスルのサイトを開いてください。受信者をだます手口の整理はフィッシング詐欺の成立の仕組みと対策にまとめています。
注文者が確認する個人情報保護相談窓口の使い方と停止中の4サービス
問い合わせはラクスルのお問い合わせフォームで「個人情報保護相談窓口」を選んで送ります。受付は24時間、回答は平日10時〜18時に順次で、集中すると時間がかかるとされています。第一報に補償についての記載はありません。
サービスは11月8日から入稿を伴う一部を止め、11月9日7時から順次再開しています。ラクスル パッケージ、ラクスル Adobe Express連携、デザイン制作依頼サービス、カタログサイトの4つは引き続き停止中の状態です。再開したサービスでも、データチェックや出荷に通常より時間がかかる場合があります。納期が決まっている印刷物は、注文ごとの案内を確かめてください。
10月16日のStudio経由6,412件と今回の入稿システム事案の違いを整理
ラクスルの2つの発表を対象者と件数と侵入経路の違いで比べた結果
ラクスルは約3週間前にも別の発表をしています。10月16日のお知らせは、外部のクラウドサービス「Studio」への不正アクセスに関するもので、今回とは経路も対象も異なります。
| 比べる点 | 10月16日の発表 | 11月9日の発表 |
|---|---|---|
| 侵入された先 | 外部サービスStudioの環境 | ラクスルの入稿関連システム |
| 対象の情報 | 案内サイトのフォーム入力内容 | 印刷データ・請求書・Web郵便 |
| 対象件数 | 6,412件 | 集計中 |
| 対象期間 | 2024年6月3日〜2026年10月15日 | 調査中〜2026年11月8日 |
10月の発表は、印刷通販サイトの会員情報、注文情報、支払い情報を対象外としていました。今回は印刷データそのものが対象です。問い合わせや資料請求のフォームを使っただけの人は10月の事案、入稿して注文した人や印刷物に載った人は今回の事案が関係します。両方の事案に当てはまる場合もあるため、区別して確認してください。Studio側の経緯はStudio不正アクセスの解説で扱っています。
宛名リストや請求書を入稿した企業が確認する委託元の報告義務と期限
宛名リストの件数が少なくても不正アクセスなら報告対象に当たる根拠
顧客名簿から作った宛名リストは個人データに当たり、その印刷の発注は通常、個人データの取扱いの委託と整理されます。個人情報保護法の通則編ガイドラインは、不正の目的によるおそれのある行為で個人データが漏えいした場合、またはそのおそれがある場合を報告対象としています。この行為の相手方には、発注した企業の委託先も含まれるという整理です。
個人情報保護委員会の案内にある1,000人超という基準は別の類型です。不正アクセスの類型は人数を問わないため、「50件のDMだから対象外」とは判断できません。本人の数が少ない発注でも、確認の対象に入れてください。
ラクスルの報告で終わらない委託元の報告義務と速報までの3〜5日の目安
通則編は、委託元と委託先の双方が原則として報告義務を負うとしています。委託先が委託元へ把握している事項を通知すれば、委託先の報告義務は免除され、報告は委託元が行います。第一報の「個人情報保護委員会へは報告をする予定」という一文だけで、発注した企業の義務がなくなると考えるのは危険です。
時間の目安も決まっています。委託元は通常、遅くとも委託先から通知を受けた時点で事態を知ったことになります。速報は知った時点から概ね3〜5日以内、不正の目的によるおそれがある場合の確報は60日以内です。手順の全体は個人情報保護委員会への報告義務の実務で整理しています。委託に当たるか、自社の入稿分が対象かの最終判断は、続報の内容を見て法務担当や弁護士と決めてください。
続報を待つ間に発注部署ごとに作っておく個人情報を含む入稿データの一覧
通知を受けてから調べ始めると、3〜5日はすぐに過ぎます。先に発注部署ごとの一覧を作っておくと、対象が確定した時点で本人の数と項目をすぐに答えられます。
- ラクスルのアカウントを持つ部署と担当者を洗い出す
- 注文ごとに、宛名リストや個人名の有無を記録する
- リストの項目と人数、元になった名簿を控える
- 本人へ連絡できる手段があるかを確かめる
社員の名刺は社内連絡で足りますが、顧客向けDMの宛先は連絡手段そのものが限られます。4番目を先に確かめておくと、本人への通知の方法を早く決められます。
認証情報の窃取を想定した点検｜アクセスキーの棚卸しをPythonで実行
手口が未公表の段階で実装者が先に見るアクセスキーの有効期間と使用状況
ここからは入稿ファイルや宛名データを預かるシステムの開発者向けです。ラクスルがどの基盤を使い、どの認証情報を奪われたかは公表されていません。以下はAWSを例にした一般的な点検で、今回の事案の再現ではありません。
AWSのアクセスキーの保護に関する説明は、IAMユーザーの長期キーは手動で無効にするまで有効であり、可能な限り一時的な認証情報を使うよう勧めています。バッチや外部連携のために発行したまま何年も残るキーは、漏れたときの被害が最も長く続きます。権限の設計はAWS IAMの仕組みと権限設計を参照してください。
IAM認証情報レポートのCSVから放置キーを抽出するスクリプト
IAMの認証情報レポートは、ユーザーごとのキーの有効状態、発行日時、最終使用日をCSVで返します。次の2つのコマンドで取得します。
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > report.csv取得したCSVを次のスクリプトに渡すと、発行から90日を超えたキー、30日以上使われていないキー、一度も使われていないキーを列挙します。Python 3の標準ライブラリだけで動き、audit_access_keys.pyとして保存します。
import csv
import sys
from datetime import datetime, timedelta, timezone
MAX_AGE = timedelta(days=90) # 発行から90日を超えた有効なキー
MAX_IDLE = timedelta(days=30) # 30日以上使われていない有効なキー
def parse(value):
if value in ("", "N/A", "no_information", "not_supported"):
return None
return datetime.fromisoformat(value.replace("Z", "+00:00"))
now = datetime.now(timezone.utc)
findings = 0
with open(sys.argv[1], newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
for n in ("1", "2"):
if row[f"access_key_{n}_active"].lower() != "true":
continue
rotated = parse(row[f"access_key_{n}_last_rotated"])
used = parse(row[f"access_key_{n}_last_used_date"])
reasons = []
if rotated and now - rotated > MAX_AGE:
reasons.append(f"発行から{(now - rotated).days}日")
if used is None:
reasons.append("使用記録なし")
elif now - used > MAX_IDLE:
reasons.append(f"最終使用から{(now - used).days}日")
if reasons:
findings += 1
print(f"{row['user']:16} key{n} " + " / ".join(reasons))
print("要確認", findings, "件")
sys.exit(1 if findings else 0)2026年11月9日に、公式の列名に合わせたダミーのCSVで実行した結果です。実際のAWSアカウントでは実行していません。
$ python audit_access_keys.py report.csv
upload-batch key1 発行から412日
old-partner key1 発行から700日 / 最終使用から95日
old-partner key2 使用記録なし
要確認 3 件列挙されたキーは、使用元を確かめたうえで無効化し、一定期間で問題がなければ削除します。このレポートに載るのはユーザーごとに最初の2本のキーまでで、サービス固有の認証情報は含まれない点に注意してください。
読まれたかを後から答えるS3データイベント記録とGetObject集計の実装
既定では記録されない読み取り操作とCloudTrail証跡の設定
第一報の表現は「外部からアクセスできる状態」「流出したおそれ」です。一般に、オブジェクト単位の読み取りを記録していないと、どのファイルが読まれたかを後から答えられず、影響範囲を絞れません。Amazon S3のCloudTrail設定の説明によると、証跡は既定ではデータイベントを記録しません。CloudTrailのデータイベントの説明でも、データイベントはイベント履歴に表示されず、証跡かイベントデータストアが必要で追加料金がかかるとされています。
全バケットを記録すると費用がかさむので、個人情報を置くバケットに絞って読み取りを記録します。証跡の設計と料金はCloudTrailの証跡設計と料金実額で解説しました。
キーと送信元ごとにGetObjectを数えて許可外を検出するPython
CloudTrailのレコード形式には、操作名、送信元IP、認証に使ったキーIDが含まれます。次のスクリプトは保存済みのログを読み、キーと送信元の組ごとにGetObjectを数え、許可外の送信元または回数の上限を超えた組を出力します。ALLOWEDとTHRESHOLDは自社の値に置き換えてください。
import collections
import glob
import gzip
import ipaddress
import json
import sys
ALLOWED = [ipaddress.ip_network(c) for c in ("203.0.113.0/24",)] # 自社の送信元に置き換える
THRESHOLD = 1000 # 1キーあたりの取得回数の上限
def is_allowed(source):
try:
ip = ipaddress.ip_address(source)
except ValueError:
return True # AWSサービスからの呼び出しは送信元がサービス名になる
return any(ip in net for net in ALLOWED)
counts = collections.Counter()
for path in glob.glob(sys.argv[1], recursive=True):
opener = gzip.open if path.endswith(".gz") else open
with opener(path, "rt", encoding="utf-8") as f:
for rec in json.load(f)["Records"]:
if rec.get("eventSource") != "s3.amazonaws.com" or rec.get("eventName") != "GetObject":
continue
key_id = rec.get("userIdentity", {}).get("accessKeyId", "(none)")
counts[(key_id, rec.get("sourceIPAddress", ""))] += 1
alerts = 0
for (key_id, source), n in counts.most_common():
outside = not is_allowed(source)
if outside or n >= THRESHOLD:
alerts += 1
print(f"{key_id} {source:15} {n:6}回 {'許可外の送信元' if outside else '回数超過'}")
print("集計", sum(counts.values()), "回 / 要確認", alerts, "組")
sys.exit(1 if alerts else 0)2026年11月9日に、許可済みの送信元からの240回、許可外の送信元からの3,812回、AWSサービスからの12回、対象外のPutObject 50回を含むダミーのログで実行した結果です。
$ python count_getobject.py "trail/*.json"
AKIAEXAMPLEBATCH 198.51.100.77 3812回 許可外の送信元
集計 4064 回 / 要確認 1 組盗んだキーを正規の拠点から使われた場合、送信元の判定は通りません。回数の上限と併せて、夜間の急増のような時間帯の偏りも見てください。トークンの失効やレート制限など、API側の守りはAPI不正アクセス対策の実装手順にまとめています。
入稿データの保存期間を分けるS3ライフサイクル設定と消し残しの確認
増刷用の版下と宛名リストを別の接頭辞で保存して保存期間を分ける理由
増刷のために版下を2年保存する設計には明確な利点があります。ただ、宛名リストまで同じ期間残す理由にはなりません。チラシの版下に個人情報はほぼ含まれず、宛名リストは発送が終われば役目を終えます。保存先の接頭辞を分ければ、宛名だけ短い期間で消せます。バケットの作成と権限はAWS S3の使い方と権限設計を参照してください。
{
"Rules": [
{
"ID": "expire-address-lists",
"Status": "Enabled",
"Filter": { "Prefix": "address-lists/" },
"Expiration": { "Days": 30 },
"NoncurrentVersionExpiration": { "NoncurrentDays": 7 },
"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
}
]
}aws s3api put-bucket-lifecycle-configuration \
--bucket example-uploads \
--lifecycle-configuration file://lifecycle.json
aws s3api get-bucket-lifecycle-configuration --bucket example-uploadsこのJSONは構文のみ手元で確認しており、実際のバケットには適用していません。ライフサイクル設定の説明にあるとおり、ルールは既存のオブジェクトにも適用されます。まず検証用のバケットで動きを確かめてください。
S3のバージョニング有効時に旧版が残り続ける消し残しの落とし穴
有効期限の説明によると、バージョニングが有効なバケットでExpirationが作用すると、削除マーカーが付くだけで、元のオブジェクトは旧バージョンとして残ります。画面上は消えていても、読み取り権限のあるキーなら旧版を取得できる状態です。先の例でNoncurrentVersionExpirationを併記したのはこのためです。設定後はaws s3api list-object-versionsで旧版が減っていることを確かめてください。
保存期間の短縮に踏み切る事業者と現行の設計のままで足りる事業者
第三者の宛名や請求書を預かる事業者はデータの保存期間を今期中に短縮する
宛名リスト、請求書、名簿を預かる受託サービスを運営しているなら、保存期間の短縮は今期中に実施すべきです。今回の第一報が示すとおり、預かったデータには発注者以外の第三者の情報が混ざり、漏えいのおそれが出ると説明の相手が一気に広がります。保存していなければ対象に入りません。長期キーの棚卸し、読み取り記録、保存期間の3点を自社だけで確かめきれない場合は、脆弱性診断・セキュリティ診断で入稿の経路とストレージの権限を含めて点検できます。
個人情報を預からない版下だけの保存で費用に対して過剰になる対策の範囲
ロゴや製品画像だけを扱う社内システムに、全バケットの読み取り記録や30日での自動削除を入れるのは過剰です。費用に見合う情報がなく、再入稿の手間だけが増えます。この場合は長期キーの棚卸しだけ実施すれば足ります。データの中身を確かめずに一律の対策を入れるのは、よくある失敗です。
よくある質問
ラクスルの不正アクセスについて、注文者と発注企業の担当者から出やすい質問をまとめました。
ラクスルのパスワードは変更したほうがよいですか？
第一報はログインIDとパスワードについて、漏えいしていないことを確認したとしており、変更は求めていません。他のサービスと同じパスワードを使い回しているなら、この機会に分けておくと安心です。パスワードの変更を促すメールやSMSが届いても、そのリンクから手続きせず、自分でラクスルのサイトを開いて操作してください。
クレジットカードの停止や再発行は必要ですか？
第一報は、クレジットカード情報について漏えいしていないことを確認したとしています。現時点でカードの再発行を急ぐ理由は示されていません。カード番号の入力を求める連絡は偽物の可能性が高いため応じないでください。明細に身に覚えのない請求があれば、今回の件と関係があるかに関わらずカード会社に連絡します。
何件の個人情報が流出したのですか？
2026年11月9日の第一報では「集計中」で、件数は公表されていません。6,412件という数字は、10月16日に公表されたStudio経由の別の事案のものです。同社は調査の進捗に応じて自社サイトで続報を出すとしています。流出が確定したわけではなく、第一報の表現は「おそれ」です。
ラクスルから連絡がなければ対象外と考えてよいですか？
そうとは言えません。第一報に対象者への個別連絡の予定は書かれておらず、対象期間と範囲も調査中です。名刺やはがきに記載された人は、ラクスルが連絡先を把握していない場合もあります。連絡の有無で判断せず、注文履歴の確認と不審な連絡への警戒を続け、続報で範囲が示されたら改めて確かめてください。
今後もラクスルで注文してよいですか？
入稿を伴う一部のサービスは11月9日7時から順次再開していますが、原因と再発防止策は第一報の時点で公表されていません。急ぎでなければ続報を待つのも選択肢です。発注を続ける場合は、宛名リストなど第三者の個人情報を含むデータの入稿を、原因の公表まで見合わせるかどうかを社内で先に決めておくと判断がぶれません。
関連記事
- Studio不正アクセスで全顧客の情報流出か｜連名報告の受付とAPIキー・Webhook URLを今日替える手順：10月16日の事案の元になった不正アクセス
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：宛名リストを預けた企業の報告の進め方
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：漏れた認証情報の失効とAPI側の守り方
- CloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説：読み取り記録を残す証跡の組み方
- フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：流出情報を使った偽連絡の手口
