2026.11.12 セキュリティ

KEYUCA不正アクセス：最大7.7万件の対象確認と不審電話の見分け方、委託先の教訓

生活雑貨店「KEYUCA（ケユカ）」の受注システムが置かれた委託先のサーバーが不正アクセスを受け、最大77,105件の個人情報が漏えいしたと、運営する河淳株式会社が2026年11月11日に第2報で公表しました。前半では、自分が対象か、KEYUCAを名乗る電話やSMSにどう備えるか、どこに問い合わせるかに公式の文言で答えます。後半は、2006年からの受注情報が1台のサーバーに残っていた点を題材に、保存期間を過ぎた個人情報を消すPythonを実行結果つきで示します。

まとめ：KEYUCAの最大7.7万件漏えいで利用客が確かめる対象と不審な電話への備え

漏えいした情報は、利用したサービスによって2つの区分に分かれます。

対象	件数	項目
家具・カーテンの注文の一部	最大530件	氏名・住所・電話番号など
名入れ依頼・壁面収納の見積り	最大76,575件	氏名・電話番号など

クレジットカード情報は当該サーバーで扱っておらず、漏えいの対象ではないとされています。河淳の第2報によれば、同社が電話やSMSでカード番号、パスワード、暗証番号を尋ねることはありません。心当たりのない連絡には応じず、専用窓口（0120-821-645、9時〜18時、土日祝を除く）か専用フォームへ連絡してください。

自分は対象か：名入れ・壁面収納の見積り・家具の注文で分かれる2つの区分

2015年12月以降に名入れを頼んだ人と壁面収納の見積りを作った人の範囲

件数の大半を占めるのは、2015年12月から2026年10月までに店舗で刺繍・箸・マグ・トートバッグの名入れを依頼した人と、壁面収納シミュレーションシステムで見積りを作成した人です。最大76,575件で、漏えい項目は氏名、電話番号、注文情報とされています。住所はこの区分の項目に入っていません。

住所まで含まれる2006年以降の家具・カーテン注文者530件と性別を含む4件

もう1つは、2006年以降に店舗またはKEYUCAオンラインショップで家具・カーテンを注文した客の一部で、最大530件です。氏名、電話番号、注文情報に加えて住所も含まれ、うち4件は性別も含みます。件数は中間報告の時点の数字で、対象者を特定できないものは最大件数で書かれており、今後の調査で変わる可能性があります。

個別連絡はメールか郵送、連絡先が分からない人は公表が通知の代わりになる扱い

対象者には順次メールまたは郵送で個別に連絡すると発表されています。開始日は示されていません。連絡先が確認できない人については、第2報の公表をもって通知に代えるとしています。名入れを頼んだ覚えがあり、連絡が届かない場合でも、対象外とは言い切れない扱いです。

KEYUCAや配送業者を装う電話・SMS・訪問への備えと、公式が尋ねない3つの情報

電話やSMSでカード番号・パスワード・暗証番号は聞かれないという判断の基準

今回漏えいしたのは氏名と電話番号が中心なので、警戒する経路はメールより電話とSMSです。第2報は、KEYUCAや配送業者などを装った不審な電話、SMS、郵便物、自宅への訪問の可能性を挙げました。名入れの注文内容や見積りの品目まで言い当てられても、本物の証拠にはなりません。注文情報も漏えい項目に含まれるからです。

カード番号・パスワード・暗証番号を聞かれたら、その時点で切る
SMSのリンクは開かず、記載の番号にも折り返さない
確かめたいときは公式サイトに載った窓口へ自分からかけ直す

偽のSMSやサイトが成り立つ仕組みはフィッシング詐欺の成立の仕組みと対策で解説しました。

住所を含む530件の対象者が気をつける郵便物と自宅への訪問の確かめ方

家具やカーテンを注文した区分では住所も漏れているため、郵便物や訪問による接触もありえます。返金や配送のやり直しを名目にした書面が届いても、記載の連絡先には電話せず、公式の窓口で確かめます。訪問を受けた場合も、その場で個人情報や支払いの話に応じないことが第2報の求める対応です。

オンラインショップとアプリは使えるか、停止中の2つのシステムと店舗での注文

停止しているのは「カーテン見積もりイージーオーダーシステム」と「壁面収納シミュレーションシステム」の2つで、再開時期は未定です。店舗での家具・カーテンの相談や注文は通常どおり利用できると第2報は案内しています。10月28日の第1報では、アプリ、オンラインショップ、ポイントと会員管理、カード決済のシステムは影響を受けないとされました。ただし後述のとおり、オンラインショップの受注情報の一部は第2報で対象に加わっています。

10月21日の遮断から11月11日の第2報まで、公表文で分かる経緯と第1報の訂正

委託先ナノテックのサーバーで起きた脆弱性の悪用と不正なプログラムの設置

第2報によると、システムの開発・運用を委託している株式会社ナノテックが管理・運用するサーバーに、2026年10月21日に第三者が不正アクセスしました。同日に外部からのアクセスを遮断し、2つのシステムを止めています。原因は、サーバー上のWebアプリケーションの脆弱性を悪用して不正なプログラムが設置され、サーバー内の情報が取得されたことです。外部専門機関の調査報告で漏えいが確認されたのは11月9日でした。

河淳は、不正なプログラムの削除と、関連するパスワード、認証情報、証明書などの変更・無効化を済ませ、個人情報保護委員会と警察へ報告したと発表しています。サーバーに置かれたプログラムが外部からの命令を受け付ける窓口になる一般的な手口は、Webシェルの仕組みと検知・除去の手順にまとめました。

第1報で対象外としたオンラインショップの受注情報が対象に加わった訂正

第1報は「KEYUCAオンラインショップでのカーテン・家具のご注文、お見積もり」を対象外と案内していました。第2報では、調査の結果、オンラインショップで注文された家具・カーテンの受注情報の一部が対象に含まれると判明したとして訂正しています。

読み取れるのは、システムの境界と、データが置かれていた場所が一致していなかったことです。オンラインショップ自体は別の仕組みでも、受注情報の一部が委託先のサーバーにも渡っていたと考えられます。初報で影響範囲を「システム名」で切ると、こうした訂正が起きやすくなります。

未公表の脆弱性の種類や侵入の開始時期など、続報で確かめる5つの項目

2026年11月12日に確認した時点で、次の5つは公表されていません。この記事でも推測しません。

悪用された脆弱性の種類と、設置された不正なプログラムの中身
不正アクセスが始まった時期
件数の確定値（現在は最大件数）
個別連絡の開始日
停止中の2システムの再開時期

同じ日にKEYUCAは、メール配信サービスのアララ経由でメールマガジン会員のアドレスが流出した件も告知しました。こちらは別の事案で、経過はアララの不正アクセスと契約企業の対応で追っています。

2006年からの受注が1台に残っていた点：保存期間を決めて氏名を消すPython

見積りや名入れの受付データを何年残すかと、個人情報保護法22条の努力義務

開発者が注目したいのは、件数の内訳にある期間です。家具・カーテンは2006年以降、名入れは2015年12月以降の受注が、1台のサーバーから漏えいしました。名入れの受付や来店前の見積りは、品物を渡した時点で役目の大半を終えるデータです。

個人情報保護法の22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めています。通則編ガイドラインの3-4-1は、懸賞品の発送後に不着対応などの合理的な期間が過ぎた場合を例に挙げています。「消去」には個人を識別できない状態にすることも含むという説明です。努力義務ですが、消していなかったデータは、漏えいすればそのまま件数に積み上がります。保存期間の決め方は顧客情報管理システムの保存期間と削除の設計でも扱いました。

種別ごとの保存期間を過ぎた氏名・電話番号・住所を消すバッチの実装

次のスクリプトは、受注の種別ごとに保存期間を決め、期限を過ぎた行の氏名、電話番号、住所だけを消します。品目と完了日は残すので、売上や品目の集計を続けることが可能です。標準ライブラリだけで動き、ダミーのデータベースを内部で作るのでそのまま実行できます。

# 保存期限を過ぎた受注・見積りの個人情報列を消し、件数集計に要る列だけ残す（Python 3.9以上・標準ライブラリのみ）
# 既定は件数を数えるだけ。--apply を付けたときだけ書き換える
import sqlite3
import sys
from datetime import date, timedelta

TODAY = date(2026, 11, 12)
# 種別ごとの保存期間（日数）。値は社内で決めるもので、ここでは例
RETENTION_DAYS = {
    "estimate": 180,        # 来店前の見積り・シミュレーション
    "engraving": 365,       # 名入れ・刺繍の受付
    "furniture": 365 * 5,   # 家具・カーテンの注文（保証や修理の問い合わせ用）
}
PERSONAL_COLUMNS = ("name", "phone", "address")


def sample_db():
    db = sqlite3.connect(":memory:")
    db.execute(
        "CREATE TABLE orders (id INTEGER PRIMARY KEY, kind TEXT, completed_on TEXT,"
        " name TEXT, phone TEXT, address TEXT, item TEXT)"
    )
    rows = [
        ("estimate", date(2026, 9, 1), "見積 太郎", "090-0000-0001", None, "壁面収納"),
        ("estimate", date(2025, 3, 10), "見積 花子", "090-0000-0002", None, "壁面収納"),
        ("engraving", date(2016, 1, 5), "名入 一郎", "090-0000-0003", None, "マグカップ"),
        ("engraving", date(2026, 10, 1), "名入 二郎", "090-0000-0004", None, "タオル"),
        ("furniture", date(2007, 6, 20), "家具 三郎", "090-0000-0005", "東京都", "ソファ"),
        ("furniture", date(2024, 4, 1), "家具 四郎", "090-0000-0006", "大阪府", "カーテン"),
        ("unknown", date(2010, 1, 1), "不明 五郎", "090-0000-0007", None, "不明"),
    ]
    db.executemany(
        "INSERT INTO orders (kind, completed_on, name, phone, address, item) VALUES (?, ?, ?, ?, ?, ?)",
        [(k, d.isoformat(), n, p, a, i) for k, d, n, p, a, i in rows],
    )
    return db


def find_expired(db):
    expired, unknown = [], []
    for row_id, kind, completed_on in db.execute(
        "SELECT id, kind, completed_on FROM orders WHERE name IS NOT NULL OR phone IS NOT NULL"
    ):
        days = RETENTION_DAYS.get(kind)
        if days is None:
            unknown.append(row_id)  # 期間が決まっていない種別は消さずに人へ回す
        elif date.fromisoformat(completed_on) + timedelta(days=days) < TODAY:
            expired.append((row_id, kind))
    return expired, unknown


def main():
    apply = "--apply" in sys.argv
    db = sample_db()
    expired, unknown = find_expired(db)
    for kind in RETENTION_DAYS:
        print(f"{kind}: 期限切れ {sum(k == kind for _, k in expired)} 件")
    print(f"期間未設定の種別: {len(unknown)} 件（要判断）")
    if apply:
        sets = ", ".join(f"{c} = NULL" for c in PERSONAL_COLUMNS)
        db.executemany(f"UPDATE orders SET {sets} WHERE id = ?", [(i,) for i, _ in expired])
        db.commit()
        left = db.execute("SELECT COUNT(*) FROM orders WHERE name IS NOT NULL").fetchone()[0]
        print(f"消去 {len(expired)} 件、氏名が残る行 {left} 件")
    sys.exit(1 if unknown else 0)


if __name__ == "__main__":
    main()

引数なしと–applyで確かめた出力と、期間未設定の種別を人へ回す理由

Python 3.14.10（Windows）で2026年11月12日に、--apply を付けて実行した結果です。引数なしでは最後の1行を除いて同じ出力になり、どちらも終了コードは1でした。

estimate: 期限切れ 1 件
engraving: 期限切れ 1 件
furniture: 期限切れ 1 件
期間未設定の種別: 1 件（要判断）
消去 3 件、氏名が残る行 4 件

2016年の名入れと2007年の家具注文、2025年3月の見積りが消え、期限内の3件は残りました。種別が unknown の行は期間を決めていないので消さず、終了コード1で人の判断へ回します。期間を決めていない種別を「とりあえず残す」のでも「とりあえず消す」のでもなく、止めて知らせるのが安全な既定です。

本番に入れる前に、バックアップの扱いも決めておきます。本体から消しても、10年分のバックアップが同じサーバーに残っていれば漏えい時の件数は減りません。completed_on が空の行は期限を計算できないので、移行時に埋めてから対象に入れます。

委託先のWebアプリに不正なプログラムを置かせない点検と、委託元の監督・報告

ファイルを受け取る見積り・名入れシステムで確かめるOWASPの点検項目

KEYUCAの件で悪用された脆弱性の種類は分かっていません。ここからは原因の説明ではなく、利用者からファイルや画像を受け取る機能を持つシステムに共通する点検項目です。名入れの文字や図案、見積りの間取り画像を受け付ける画面は、外部からファイルを置ける入口になります。

OWASPのFile Upload Cheat Sheetは、許可する拡張子を業務に要るものだけに絞る、Content-Typeヘッダーを信用せず種類を検証する、ファイル名をアプリ側で付け直す、保存先を別サーバーかWebルートの外にする、といった対策を挙げています。保存先が公開ディレクトリの中にあると、置かれたファイルがそのままサーバー上で動く条件がそろいます。

置かれたファイルを早く見つける方法は、公開ディレクトリのハッシュ一覧と差分を比べる仕組みです。実装は日商簿記ネット試験の情報漏洩と改ざん検知の実装で示しました。APIの認可やトークンの失効まで含めた手順はAPI不正アクセス対策の実装手順にあります。

委託先で起きた漏えいでも委託元が判断する報告の期限と25条の監督

個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある漏えい等と、本人の数が1,000人を超える漏えい等が報告の対象に含まれます。速報は発覚から3〜5日以内、確報は30日以内で、不正の目的によるおそれがある場合は60日以内です。KEYUCAの件は両方に当たり、河淳が委託元として報告しています。

委託元には個人情報保護法25条の監督義務もあります。河淳も第2報で「委託先の管理体制を含め、委託元である当社の責任」と書き、委託先の状況を定期的に確かめる体制を整えるとしました。報告の流れは個人情報保護委員会への報告義務の実務で、契約に入れる点検項目は委託先管理の監督義務とチェックリストで確認できます。

判断：来店前の見積りツールや受注システムを委託する企業が診断を入れる条件

結論から書くと、見積りや受付のデータには、作る時点で保存期間を決めて持たせます。品物を渡し終えた名入れの受付で、氏名と電話番号を10年持ち続ける理由は見当たりません。保証や修理の問い合わせに要る家具の注文だけを、その期間に合わせて残します。

次のいずれかに当てはまるなら、第三者の診断を先に入れます。委託先のサーバーに顧客の氏名や電話番号が万単位で入っている、見積りツールや受付画面がファイルや画像を受け取る、委託先と保存期間や点検の頻度を契約で決めていない、のいずれかです。顧客情報を持たない静的な紹介ページだけを委託しているなら、診断より先に、管理画面の多要素認証と更新の記録を確かめれば足ります。委託先のシステムまで含めて第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断でご相談いただけます。

よくある質問

KEYUCAの不正アクセスについて、利用客から出やすい質問をまとめました。内容は2026年10月28日の第1報と11月11日の第2報に基づきます。

KEYUCAの不正アクセスで自分が対象かどうかはどう確かめますか？

2015年12月から2026年10月までに店舗で名入れを頼んだ人、壁面収納シミュレーションで見積りを作った人、2006年以降に家具・カーテンを注文した人の一部が対象です。対象者には順次メールか郵送で連絡が届く予定ですが、開始日は示されていません。連絡先が分からない人は公表が通知の代わりとされているので、心当たりがあれば専用窓口か専用フォームで確かめてください。

KEYUCAを名乗る電話やSMSが届いたらどうすればよいですか？

KEYUCAが電話やSMSでカード番号、パスワード、暗証番号を尋ねることはないと公表されています。それらを聞かれた時点で偽物と判断し、電話を切ります。SMSのリンクは開かず、記載の番号にも折り返さないでください。注文した品物や見積りの内容を言い当てられても、注文情報が漏えい項目に入っているので本物の証拠にはなりません。確かめるときは公式サイトの窓口へ自分からかけます。

クレジットカードの停止や再発行は必要ですか？

カード情報は当該サーバーで扱っておらず、漏えいの対象ではないと発表されています。今回の件だけを理由にカードを止める必要はないと考えられます。ただし、偽の電話やSMSに応じてカード番号を伝えたり入力したりした場合は別です。その場合はすぐにカード発行会社へ連絡し、利用停止や再発行を相談してください。

KEYUCAオンラインショップやアプリは今も使えますか？

第1報では、アプリとオンラインショップ、ポイントと会員管理、カード決済のシステムは影響を受けないと案内されました。停止しているのはカーテンの見積りと壁面収納のシミュレーションの2システムで、店舗での相談や注文は通常どおりです。なお第2報では、オンラインショップで注文された家具・カーテンの受注情報の一部が漏えいの対象に含まれると訂正されています。

KEYUCAの問い合わせ窓口の電話番号と受付時間を教えてください。

第2報に記載された窓口は、電話が0120-821-645で、受付は9時から18時（土日祝を除く）です。ほかに専用フォームも用意されています。番号は検索結果や届いたSMSから拾わず、KEYUCAの公式サイトに載ったお知らせのページから確かめてください。調査は続いており、新しい事項は同じページで知らせるとされています。

アララの不正アクセス：メール約8,100万件の持ち出しと公表した契約企業、APIキー再設定・代替送信・連名報告：KEYUCAが同日に告知したメルマガ会員アドレスの別事案
日商簿記ネット試験の情報漏洩：最大約98万人の対象確認と不審連絡への備え、改ざん検知の実装：外部サーバーに不正なファイルが置かれた別の事案
Webシェルとは？仕組み・代表例と検知・除去の手順をTomcat・PHP・IISのコマンド例で解説：サーバーに置かれる不正なプログラムの一般的な手口
API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：受注や見積りを扱うAPIの点検
個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：委託元が行う報告の流れ

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

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

資料請求

KEYUCA不正アクセス：最大7.7万件の対象確認と不審電話の見分け方、委託先の教訓

まとめ：KEYUCAの最大7.7万件漏えいで利用客が確かめる対象と不審な電話への備え