---
title: "ヤクルトの不正アクセス：約4万件の対象確認と窓口、問い合わせデータを溜めない設計"
url: "https://www.issoh.co.jp/tech/details/19123/"
published: 2026-10-31
updated: 2026-10-31
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# ヤクルトの不正アクセス：約4万件の対象確認と窓口、問い合わせデータを溜めない設計

ヤクルト本社のホームページが第三者の不正アクセスを受け、問い合わせフォームの利用者や給食サイト「たのしい給食」の会員など、約4万件の個人情報が漏えいしました。2026年10月30日の第2報で同社が確認したものです。前半では公表文をもとに、自分がどの区分に入るか、漏れた項目、不審な連絡への注意、問い合わせ先を整理しました。後半では、フォームから集めた個人情報を公開側のサーバーに溜め続けないために、保持期限を過ぎたデータを点検して消すPythonの例を示します。

## まとめ：ヤクルト本社ホームページの漏えい範囲と利用者がまず行うこと

[ヤクルト本社の第2報](https://www.yakult.co.jp/maintenance/)によると、同社は10月26日にホームページの機能を止め、同日19時に第1報を出しました。調査の結果、ホームページを通じて預かった個人情報のうち約4万件が外部に漏れたことを確認しています。区分ごとの件数と対象期間は順次公表するとしており、10月31日時点ではまだ出ていません。

漏れたのは、問い合わせの内容、給食サイトの登録情報、報道関係者の連絡先、対応した社員の氏名です。ホームページではクレジットカード情報と銀行口座情報を預かっていないと同社は説明しています。利用者がまず行うことは2つです。ヤクルトを名乗る懸賞・配送・返金の連絡に応じないこと。たのしい給食の会員は、同じパスワードを使っているほかのサービスでパスワードを変えることです。

| 区分  | 対象者               | 漏えいした主な情報                 |
| --- | ----------------- | ------------------------- |
| (1) | メールお問い合わせフォームの利用者 | 氏名・性別・年齢層・住所・電話・メール・問合せ内容 |
| (2) | 給食サイト「たのしい給食」の会員  | 氏名・勤務先・電話・メール・暗号化パスワード    |
| (3) | 報道関係者向けフォームの利用者   | 氏名・媒体名・社名と住所・電話・メール・問合せ内容 |
| (4) | (1)と(3)に対応した社員    | 氏名                        |

## 利用者が確かめること：4つの対象区分と不審な連絡、相談センターの窓口

### メールお問い合わせ・たのしい給食・報道向けフォーム・対応社員の4区分の違い

区分(1)は、ヤクルト本社のホームページにあるメールお問い合わせフォームから問い合わせたことがある人です。氏名・性別・年齢層・住所・電話番号・メールアドレスに加え、問い合わせの本文まで漏れました。商品の味、体調、配達の不満など、何を書いたかで知られた中身が変わります。

区分(2)は、給食サイト「たのしい給食」に会員登録している人です。業態・勤務先・所属部署または受託会社・勤務先の住所と電話番号といった、仕事の情報が中心になります。区分(3)は報道関係者向けフォームの利用者で、媒体名や会社名、役職名（任意）が含まれます。区分(4)は、(1)と(3)の問い合わせに対応したヤクルト本社の社員の氏名です。問い合わせた時期が古くても対象から外れるとは書かれていないので、思い当たる人は全員、対象として動いてください。

### 問い合わせ内容まで漏れた人が警戒する、懸賞・配送・返金をかたる連絡

同社は、差出人不明の不審な電話・メール・SMSに注意するよう呼びかけ、例として懸賞の当選、配送の連絡、返金の案内を挙げています。区分(1)の人は、住所と電話番号に加えて、自分が過去に何を問い合わせたかまで相手に知られている可能性があります。「先日お問い合わせいただいた件で返金があります」と、実際の問い合わせ内容に触れる連絡が来ても、本物の証拠にはなりません。

ヤクルト本社は、パスワード・口座番号・クレジットカード番号を尋ねることはないと明記しています。これを聞かれた時点で偽物と判断して構いません。リンクや添付ファイルも開かないでください。偽の連絡が成り立つ仕組みと見分け方は[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)で解説しています。

### たのしい給食の会員が変えるべき、同じパスワードを使うほかのサービス

区分(2)では「登録パスワード（暗号化されたパスワード）」が漏れました。暗号化の方式は公表されていません。方式によっては時間をかけて元の文字列に戻される場合があるため、同じメールアドレスとパスワードの組み合わせを使っているほかのサービスがあれば、そちらを先に変えてください。勤務先の業務システムや給食関係の発注サイトで同じパスワードを使っている場合は、会社の情報システム担当にも伝えます。

たのしい給食そのもののパスワードは、サイトが止まっている間は変更できません。再開時に変更を求める案内が出るかを確かめてください。保存方式の違いで戻されやすさがどう変わるかは、[松屋の事案で漏れたパスワードの守り方](https://www.issoh.co.jp/tech/details/19118/)でPythonの実行結果とともに比べました。使い回しを洗い出す手順は[花キューピットの事案の使い回しの点検手順](https://www.issoh.co.jp/tech/details/19088/)にあります。

### 相談センター0120-11-8960の受付時間と、個別の連絡がまだ届かない理由

利用者の問い合わせ先は、ヤクルトお客さま相談センター（0120-11-8960、10時から16時、土日・祝日を除く）です。同社は本件専用の窓口を準備中で、それまでの間は相談センターで受け付けるとしています。報道関係者は広報部広報課（03-6625-8971）が窓口です。

対象者への個別の連絡は「準備が整い次第」とされ、10月31日時点ではまだ始まっていません。区分ごとの件数と対象期間が出ていないため、誰に送るかを確定させている段階だと読めます。ホームページは10月31日時点でもメンテナンス中の表示のままで、再開の日付は示されていません。

## 公表文から読む事案の構造：問い合わせ本文と対応した社員の氏名まで漏れた意味

### 10月26日の第1報から30日の第2報まで、4日間で分かったことと未公表の点

第1報は「不正アクセスが認められた」「お客さまの情報への影響は調査中」の2点だけでした。4日後の第2報で、漏えいの確認、約4万件という規模、対象4区分の項目が加わっています。

| 日時        | 出来事                      |
| --------- | ------------------------ |
| 10月26日    | ホームページの機能を停止             |
| 10月26日19時 | 第1報（不正アクセスの発生、影響は調査中）    |
| 10月30日9時  | 第2報（約4万件の漏えいを確認、対象4区分）   |
| 10月30日時点  | 個人情報保護委員会へ第一報、警察へ相談      |
| 未公表       | 原因・侵入経路・区分ごとの件数・対象期間・再開日 |

原因と侵入経路は、第2報にも書かれていません。ホームページのどの機能に弱点があったのか、外部の委託先が関わるのかも分かっていない段階です。以降の章は、公表された事実から読めることに絞ります。

### 対応した社員の氏名まで漏れたことが示す、問い合わせの記録の置き場所

区分(4)の「問い合わせに対応した社員の氏名」は、フォームの送信内容には含まれない情報です。問い合わせを受けた後、誰が対応したかを記録する仕組みがあり、その記録までホームページへの不正アクセスで取られたことになります。フォームからメールを1通送るだけの作りなら、対応者の名前はサーバーに残りません。

ここから言えるのは、問い合わせの受付と対応の記録が、ホームページから読める位置に置かれていた可能性です。保存場所について同社は何も説明しておらず、断定はできません。それでも、送信から時間がたった問い合わせ本文と対応記録がまとめて取られうる構成だった点は、多くの企業サイトに共通する弱点です。この点は後半の対策の章で扱います。

### 不正な目的のおそれと1,000人超の2つで報告対象、施行規則7条と確報の期限

[個人情報保護法施行規則](https://laws.e-gov.go.jp/law/428M60020000003)の第7条は、委員会への報告が必要な事態を4つ挙げています。本件に当たるのは、不正の目的をもって行われたおそれがある行為による漏えい（第3号）と、本人の数が1,000人を超える漏えい（第4号）という2つの報告対象です。第8条により、速やかな速報の後、確報は原則30日以内、第3号に当たる場合は60日以内に出します。

同社はすでに委員会へ第一報を出しており、これが速報にあたります。本人への通知も法律上の義務で、第2報の「準備が整い次第ご連絡」がこれに当たる手続きです。報告と通知の全体の流れは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)にまとめました。

## 開発側の対策：問い合わせデータの保持期限をPythonで点検し、個人情報を消す手順

### 法22条の消去の努力義務と、フォームの保存データが増え続ける構造

ここから先は、ヤクルト本社の仕組みを推測するものではありません。企業サイトの問い合わせフォームは、送信内容をメールで担当者に送ると同時に、データベースにも保存する作りが多くあります。WordPressのフォーム系プラグインにも、送信内容を管理画面に溜める機能を持つものが少なくありません。消す仕組みを誰も作らなければ、サイトを開設した日からの問い合わせがすべて残り続けます。

個人情報保護法の第22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めています。[個人情報保護委員会のガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)の3-4-1は、利用目的が達成された場合をこれに当たる例としています。回答を終えて一定期間がたった問い合わせは、まさにこの状態です。努力義務ではあっても、漏れたときの件数を決めるのは、この消去を実際に回しているかどうかです。

### 保持期限を過ぎた行の個人情報を消すPythonの点検と消去スクリプト

次のコードは、Pythonの標準ライブラリの[sqlite3](https://docs.python.org/ja/3/library/sqlite3.html)だけで動きます。集計の対象は、問い合わせを保存したテーブルのうち、受付日時が保持期限より古く、個人情報の列が残っている行です。auditモードでは数えるだけで、該当があれば終了コード1を返します。purgeモードの処理は、該当行の氏名・メール・電話・住所・本文・対応者名を空にすることです。フォームの種類・分類・受付日時は残すので、件数の集計は消去後も続けられます。

```
# 問い合わせフォームの保存データを点検し、保持期限を過ぎた行の個人情報を消す
# （Python 3.9以上・標準ライブラリのみ。SQLiteの例。MySQLやPostgreSQLでもSQLの考え方は同じ）
# 使い方: python form_retention.py audit inquiries.db 90   … 期限切れで個人情報が残る件数を数える
#         python form_retention.py purge inquiries.db 90   … 期限切れ行の個人情報の列を空にする
import sqlite3, sys
from datetime import datetime, timedelta

PII = ["name", "email", "phone", "address", "body", "staff_name"]   # 消す列（問い合わせた人と対応した社員）

mode, db, days = sys.argv[1], sys.argv[2], int(sys.argv[3])
cutoff = (datetime.now() - timedelta(days=days)).strftime("%Y-%m-%d %H:%M:%S")
con = sqlite3.connect(db)
live = " OR ".join(f"{c} IS NOT NULL" for c in PII)
total = con.execute("SELECT COUNT(*) FROM inquiries").fetchone()[0]
old = con.execute(f"SELECT COUNT(*) FROM inquiries WHERE received_at < ? AND ({live})", (cutoff,)).fetchone()[0]
print(f"total={total} expired_with_pii={old} (received before {cutoff[:10]})")
for form, n, first in con.execute(
        f"SELECT form, COUNT(*), MIN(received_at) FROM inquiries WHERE received_at < ? AND ({live}) GROUP BY form",
        (cutoff,)):
    print(f"  {form}: {n} rows, oldest {first[:10]}")
if mode == "purge":
    sets = ", ".join(f"{c} = NULL" for c in PII)
    cur = con.execute(
        f"UPDATE inquiries SET {sets}, purged_at = datetime('now', 'localtime') WHERE received_at < ? AND ({live})",
        (cutoff,))
    con.commit()
    print(f"purged {cur.rowcount} rows (form, category, received_at are kept)")
sys.exit(1 if mode == "audit" and old else 0)
```

動きを確かめるため、架空の問い合わせ1,500件を入れたSQLiteを用意しました。受付日時を過去3年に散らし、一般向けフォーム1,350件と報道向けフォーム150件に分けています。保持期限は90日です。Python 3.14.7（Windows）で2026年10月31日に実行した結果です。

```
$ python form_retention.py audit inquiries.db 90
total=1500 expired_with_pii=1378 (received before 2026-08-02)
  general: 1240 rows, oldest 2023-11-02
  press: 138 rows, oldest 2023-11-06
$ echo $?
1
$ python form_retention.py purge inquiries.db 90
total=1500 expired_with_pii=1378 (received before 2026-08-02)
  general: 1240 rows, oldest 2023-11-02
  press: 138 rows, oldest 2023-11-06
purged 1378 rows (form, category, received_at are kept)
$ python form_retention.py audit inquiries.db 90
total=1500 expired_with_pii=0 (received before 2026-08-02)
$ echo $?
0
```

### 実行結果の読み方、3年分の架空データで9割超が期限切れだった理由

1回目のauditでは、1,500件のうち1,378件（約92%）が90日の期限を過ぎたまま個人情報を残していました。最も古い行は2023年11月です。3年分を均等に溜めた場合、直近90日の分は全体の1割ほどにしかなりません。消さずに運用してきたサイトでは、漏れうる件数の9割以上が「もう使わない問い合わせ」だということです。

purgeの後に2回目のauditを流すと、該当は0件になり、終了コードも0に戻りました。cronやタスクスケジューラでauditを毎日回し、1が返ったら担当者に知らせる使い方を想定しています。保持期限を何日にするかは、回答後の追加の質問やクレーム対応に何日使うかで決め、社内規程に書いておきます。

注意点が2つあります。SQLiteやMySQLは、行の値を空にしてもファイル上に古いデータが残ることがあり、SQLiteなら消去後にVACUUMを実行します。もう1つはバックアップです。本番から消しても、同じサーバーに置いたバックアップに残っていれば、侵入されたときに一緒に取られます。アプリ用のDBアカウントの権限の絞り方とバックアップの置き場所は、[PeakManagerの個人情報漏えいとDB侵害の技術解説](https://www.issoh.co.jp/tech/details/16101/)で扱いました。

### そもそも溜めない構成：受付後に社内システムへ渡し、公開側から消す流れ

期限で消すより確実なのは、公開側のサーバーに問い合わせを溜めない構成です。フォームが受け付けた内容は、社内の問い合わせ管理システムや顧客管理システムへすぐに渡し、渡し終えたら公開側の行を消します。対応者の記録や回答の履歴は、インターネットから直接届かない社内側にだけ持たせます。

1. フォームの送信内容を公開側のデータベースに一時保存する
2. 社内システムが定期的に取りに行き、受け取ったら受付番号を返す
3. 受付番号が返った行は、公開側で個人情報の列を空にする
4. 対応者・回答・履歴は社内システムだけに記録する

この形なら、公開側が侵入されても取られるのは、まだ社内へ渡っていない数分から数時間分の問い合わせだけです。社内から取りに行く向きにしておけば、公開側から社内へ通信を許す必要もありません。

## 公開サーバーを守る条件：ホームページの脆弱性診断を急ぐ会社と定期で足りる会社

### IPA「安全なウェブサイトの作り方」に沿うフォームと管理画面の点検項目

フォームを持つ企業サイトの点検には、IPAの[安全なウェブサイトの作り方](https://www.ipa.go.jp/security/vuln/websecurity/about.html)が基本の資料になります。脆弱性の種類ごとに根本的な対策と保険的な対策を分けて示しています。問い合わせフォームと管理画面に関わる項目を、優先度の高い順に並べました。

| 順 | 点検項目                 | フォームと管理画面で見る箇所           |
| - | -------------------- | ------------------------ |
| 1 | アクセス制御や認可制御の欠落       | 管理画面と保存データ一覧が未ログインで開けないか |
| 2 | SQLインジェクション          | フォームの入力値がそのままSQLに入っていないか |
| 3 | メールヘッダ・インジェクション      | 宛先や件名に入力値を使っていないか        |
| 4 | CMS・プラグインの更新（本記事の追加） | フォーム系プラグインが最新版か          |
| 5 | 保持期限（本記事の追加）         | 期限を過ぎた問い合わせが残っていないか      |

1番目の項目は、管理画面への入口を接続元のIPアドレスで絞るだけでも危険が大きく下がります。管理画面がAPIと入口を共有している場合の固め方は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で解説しました。

### 外部診断を急ぐべきホームページと、年1回の定期診断で足りるホームページ

次のどれかに当てはまる会社は、外部の脆弱性診断を急いでください。問い合わせフォームの送信内容を公開側のデータベースに溜め、消す仕組みがないこと。管理画面がインターネットからIDとパスワードだけで開けること。会員登録の機能があり、パスワードの保存方式を自社で説明できないことです。保存方式の現在の推奨は、[OWASPのPassword Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)がArgon2idを第一に挙げています。暗号化とハッシュの違いは[ハッシュ化と暗号化の違い](https://www.issoh.co.jp/column/details/13487/)で整理しました。

問い合わせを社内側へ渡して公開側から消し、管理画面を社内網か多要素認証に絞っているなら、年1回の定期診断で足ります。診断の種類と費用の考え方は[脆弱性診断の種類・費用相場と外注の判断基準](https://www.issoh.co.jp/column/details/13101/)にまとめました。自社のホームページのフォームや管理画面に同じ弱点が残っていないかを第三者に確かめてもらいたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。

## よくある質問

ヤクルト本社のホームページへの不正アクセスについて、利用者から出やすい質問をまとめました。

### 自分がヤクルトの情報漏えいの対象かどうか、どうすれば分かりますか？

ヤクルト本社のホームページのメールお問い合わせフォームか報道関係者向けフォームから問い合わせたことがある人と、給食サイト「たのしい給食」に会員登録している人が対象です。区分ごとの件数と対象期間は10月31日時点で公表されておらず、対象者への個別の連絡も「準備が整い次第」とされています。心当たりがあれば、連絡を待たずに不審な連絡への警戒を始めてください。確認したい場合は、ヤクルトお客さま相談センター（0120-11-8960）に問い合わせます。

### ヤクルトの問い合わせで漏れた情報にクレジットカードは含まれますか？

含まれません。同社は、ホームページではクレジットカード情報と銀行口座情報を預かっていないと説明しています。漏れたのは氏名・住所・電話番号・メールアドレス・問い合わせ内容などです。カードの再発行は必要ありませんが、カード番号や口座番号を聞き出そうとする連絡は偽物なので、応じないでください。

### たのしい給食のパスワードは変更したほうがいいですか？

暗号化されたパスワードが漏れており、方式は公表されていません。サイトが止まっている間はたのしい給食側で変更できないため、まず同じパスワードを使っているほかのサービスで変更してください。勤務先の業務システムで同じ組み合わせを使っている場合は、会社の担当者にも伝えます。たのしい給食のパスワードは、再開時の案内に従って変更します。

### ヤクルトを名乗る電話やSMSが来たらどうすればいいですか？

リンクや添付ファイルを開かず、電話なら一度切ってください。同社は、パスワード・口座番号・クレジットカード番号を尋ねることはないとしています。懸賞の当選、配送の連絡、返金の案内を装う連絡は、同社が名指しで注意を促している型です。本物かどうか確かめたいときは、届いた連絡に書かれた番号ではなく、公表文にある相談センターの番号にかけます。

### ヤクルトのホームページはいつ再開しますか？原因は分かりましたか？

10月31日時点で、ホームページはメンテナンス中の表示が続き、再開の日付は示されていません。原因と侵入経路も公表されていません。同社は詳細な調査を進めており、個人情報保護委員会への第一報と警察への相談を済ませています。区分ごとの件数や対象期間とあわせ、続報は同社のホームページで公表される見込みです。

## 関連記事

- [松屋の不正アクセス：237万件の対象確認と窓口、漏れたパスワードの守り方](https://www.issoh.co.jp/tech/details/19118/)：暗号化されたパスワードが漏れた同月の事案
- [フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説](https://www.issoh.co.jp/tech/details/13548/)：漏れた連絡先を使う偽の連絡の仕組み
- [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えい時に求められる報告と本人通知
- [ハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説](https://www.issoh.co.jp/column/details/13487/)：パスワードの保存方式の基本
- [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：ホームページの診断を外注するときの判断

---

出典: [ヤクルトの不正アクセス：約4万件の対象確認と窓口、問い合わせデータを溜めない設計](<https://www.issoh.co.jp/tech/details/19123/>)（株式会社一創）