2026.11.10

ラフールサーベイで約2.4万人の情報流出、原因はアクセスキー【2026年11月】

IT Picks編集部

2026年11月9日、株式会社ラフールは、従業員向けのサーベイサービス「ラフールサーベイ」の旧システムに第三者が不正アクセスし、182社・24,232名分の従業員の情報が取得されたと公表しました。

「ラフールサーベイ」旧システムへの不正アクセスに関するお知らせとお詫び〜現在ご利用中のシステムへの影響はございません〜

取得された情報には従業員番号・氏名・所属部署・サーベイの回答と結果があり、一部の人はストレスチェックの結果や、医師による面談の記録も含まれます。原因についてラフールは、アクセスキーを書き込んだプログラムを含むテスト用のイメージが、2019年にインターネット上で公開されていたためと推定しています。何年も前に外に出た鍵が、今になって使われた——クラウドの認証情報の管理の怖さが表に出た件という位置づけです。

この記事はこんな人向けです

勤務先で「ラフールサーベイ」（他社経由で提供されているものを含む）を導入している、または回答したことがある
人事・情報システムの担当者で、自社が対象かどうかと問い合わせ先を確かめたい
クラウドのアクセスキーを扱う開発者・インフラ担当で、同じことを防ぐ方法を知りたい

ラフールサーベイの情報流出とは？一言でまとめると
何が起きたか：7月から10月まで旧システムからファイル取得
取得された情報：182社・24,232名分
原因：アクセスキーを書いたテスト用イメージが公開されていた
今のシステムへの影響と、ラフールの対応
導入企業・従業員がやること
同じことを防ぐには：アクセスキーの扱い方
IT Picks的な所感
まとめ

ラフールサーベイの情報流出とは？一言でまとめると

一言でいうと、ラフールサーベイの移行前の旧システムで、昔公開されてしまったアクセスキーが使われ、ファイル保管領域から従業員の情報を含むファイルが取得されたという件です。

ラフールサーベイは、ラフールが提供する組織改善ツール（組織サーベイ）です。エンゲージメントからストレスまで、組織の状態を見える化するサービスで、今回の対象には他社を通じて提供しているサービスも含まれます。

ラフールが11月9日に公表した内容は、次のとおりです。

項目	内容（公式発表）
発表	2026年11月9日（株式会社ラフール）
不正アクセスを受けたもの	ラフールサーベイの旧システム（7月30日に新システムへ移行する前のもの）
ファイルが取得された期間	2026年7月24日〜10月25日
個人情報を含むファイルの取得	7月24日と8月8日の2回
対象	182社、24,232名分（今後の調査で変わる可能性あり）
主な項目	従業員番号・氏名・所属部署・サーベイの回答と結果
要配慮個人情報	一部の人はストレスチェックの結果・回答、医師による面談・面接指導の記録
原因（推定）	アクセスキーを書き込んだプログラムを含むテスト用イメージが2019年にネット上で公開
今のシステム	不正アクセスはないとしている
二次被害	現時点で確認されていない

この記事は、ラフールの公式発表にある事実だけをもとにまとめています。後半の「同じことを防ぐには」は、今回の件の原因の説明ではなく、AWS・Google Cloud・Docker の公式ドキュメントにある一般的な対策です。

何が起きたか：7月から10月まで旧システムからファイル取得

公式発表にある流れを、日付の順に並べます。

日付	起きたこと（公式発表）
2019年	アクセスキーを書き込んだプログラムを含むテスト用の実行環境のイメージが、インターネット上で公開された（ラフールの推定）
2026年7月24日〜10月25日	第三者が旧システムのファイル保管領域から不正にファイルを取得。個人情報を含むファイルは7月24日と8月8日
7月30日	メンテナンスで、ラフールサーベイを新しいシステムへ移行
10月27日	ラフールのエンジニアがログの確認中に不正アクセスの疑いを発見。同じ日にアクセスキーを停止（無効化）
10月28日	不正アクセスに使われた海外の IP アドレスからの通信を遮断
10月29日	調査で、7月24日〜10月25日のファイルの取得が発覚
11月4日	現行システムの設定とアクセスの記録を確認し、攻撃元によるアクセスや操作の記録がないことを確認
11月9日	ラフールが公表

ラフールのお知らせ「「ラフールサーベイ」旧システムへの不正アクセスに関するお知らせとお詫び」 — 2026年11月10日時点（出典: ラフール「「ラフールサーベイ」旧システムへの不正アクセスに関するお知らせとお詫び」）

日付を並べると、7月30日に新しいシステムへ移った後も、旧システムのファイル保管領域からの取得は10月25日まで続いていたことになります。個人情報を含むファイルが取られた8月8日も、移行の後です。

ラフールサーベイ旧システムへの不正アクセスの流れ — ラフールの発表（出典）をもとに IT Picks 編集部が作成

取得された情報：182社・24,232名分

ラフールの発表によると、対象は182社、24,232名分です。この数は今後の調査で変わる可能性があるとしています。主な項目は次のとおりです。

従業員番号
氏名
所属部署
サーベイの回答と結果

① 一部はストレスチェックや面談の記録も

一部の人については、ストレスチェックの結果・回答や、医師による面談・面接指導の記録も含まれます。ラフールは、これらを要配慮個人情報と書いています。要配慮個人情報は、健康などに関わり、扱いに特に配慮が必要な個人情報のことです。

何名分に要配慮個人情報が含まれるかの内訳は、発表には書かれていません。

② 住所・電話番号・パスワードは確認されていない

住所・電話番号・パスワードは、現時点の調査では確認されていないとしています。情報の公開や悪用といった二次被害も、現時点では確認されていません。

ラフールサーベイ旧システムから取得された情報 — ラフールの発表（出典）をもとに IT Picks 編集部が作成

原因：アクセスキーを書いたテスト用イメージが公開されていた

ラフールは、原因を次のように説明しています。

旧システムでは、アクセスキーがプログラムの中に書き込まれていた（ラフールのエンジニアによる）
そのプログラムを含むテスト用の実行環境のイメージが、2019年に当時の開発委託先である株式会社フランジア（現株式会社Sun Asterisk）の開発者によってインターネット上で公開された
その結果、第三者がアクセスキーを手に入れたと推定している

アクセスキーは、プログラムがクラウドのサービスにアクセスするときに使う、合言葉のような認証情報です。イメージは、プログラムと動かすための環境をひとまとめにしたものです。イメージの中にキーが書かれていると、イメージを手に入れた人は誰でもキーを読めることになります。

ラフールは、委託元である自社の管理も十分ではなかったと認識しているとしています。イメージが公開された具体的な場所や、どのクラウドのサービスだったかは、発表には書かれていません。

今のシステムへの影響と、ラフールの対応

ラフールは、現在使われているシステム（現行システム）での不正アクセスはないとしています。理由として、次の点を挙げています。

現行システムの状態（公式発表）	内容
別の管理単位	旧システムとは別のクラウド上の管理単位で運用しており、今回使われたアクセスキーでは接続できない
キーの持ち方	プログラムにアクセスキーを直接書く方式をやめ、短時間で自動的に無効になる一時的な認証情報を使う方式に切り替えた
記録の確認	11月4日に現行システムの設定とアクセスの記録を確認し、攻撃元によるアクセスや操作の記録がないことを確認

対応としては、警察と個人情報保護委員会に報告しました。今後は外部の調査機関に調査を依頼する予定で、その結果を踏まえて再発防止策を講じるとしています。新たに知らせることが分かった場合は、速やかに知らせるとのことです。

導入企業・従業員がやること

公式の案内と、こうした発表のあとの一般的な注意を分けて整理します。

① 対象の企業には個別に連絡

ラフールによると、情報の取得が確認された企業には、ラフールまたはサービスの提供元から、順に個別に連絡しているとのことです。ラフールや提供元から案内がない企業は、情報の取得が確認されていない企業としています。

ラフールサーベイは他社を通じて提供されているものも対象です。従業員の立場では、自分の勤務先が対象かどうかは、まず勤務先の人事などの案内を確かめるのが近道です。

② 問い合わせ先

窓口	連絡先	受付時間
ラフールサーベイ事務局（電話）	0120-285-061	平日10時〜17時
ラフールサーベイ事務局（メール）	privacy@lafool.co.jp	平日10時〜17時

③ この件を名乗るメール・電話に注意

ラフールは、この件に関係するように見せかけた不審なメール・電話などに注意するよう呼びかけています。ラフールから、メールや電話でパスワードや金銭を尋ねることはないと明記しています。

ここからはラフールの案内ではなく、一般的な注意です。取得された項目には氏名・所属部署があるため、社内の人や取引先を名乗るメールでも、それだけで本物と判断しないのが安全です。

漏えいが分かったときの相談先は、IPA の窓口を紹介した記事にまとめています。

同じことを防ぐには：アクセスキーの扱い方

ここからは、クラウドを使う開発者・インフラ担当向けの一般的な対策です。今回の件の原因を推測するものではなく、AWS・Google Cloud・Docker の公式ドキュメントに書かれている内容をまとめます。

① キーをコードやイメージに書かない

AWS は、アクセスキーを直接コードに埋め込まないよう求めています。暗号化した保存場所の中であっても、アプリに埋め込まないとしています。Google Cloud も、鍵をソースコードのリポジトリに送らない・プログラムに埋め込まないことを勧めています。

コンテナのイメージを作るときも注意が必要です。Docker のドキュメントでは、ビルド引数や環境変数は最終的なイメージに残るため、秘密の情報を渡すのには向かないとし、シークレットマウントなどを使うよう案内しています。

② 長く使えるキーより、一時的な認証情報

AWS は、可能ならアクセスキーのような長く使える認証情報の代わりに、一時的な認証情報を使うことを勧めています。EC2 や Lambda などでは IAM ロールから一時的な認証情報が配られるため、キーを配る必要がないとしています。ラフールが現行システムで切り替えた「短時間で自動的に無効になる一時的な認証情報」も、この考え方です。

③ キーの更新と、使っていないものの削除

長く使うキーが必要な場合でも、AWS は必要なときにキーを更新（ローテーション）すること、使っていないユーザーや認証情報を定期的に確認して削除することを勧めています。Google Cloud も鍵のローテーションや、漏えいした鍵を自動で無効にする設定を紹介しています。

④ 攻撃者が探す場所を知っておく

Google Cloud のドキュメントは、攻撃者が鍵を探す場所の例として、公開されているソースコードのリポジトリや一般公開のストレージなどを挙げています。テスト用・検証用に作ったものでも、公開した瞬間に中身は誰でも見られると考えておく必要があります。

アクセスキーの漏えいを防ぐための4つのポイント — AWS・Google Cloud・Docker の公式ドキュメント（出典）をもとに IT Picks 編集部が作成

クラウドの設定ミスが原因で起きる別の例は、サブドメイン乗っ取りの原因と対策でも解説しています。鍵が意図せず残る話は、Claude Code の記事でも取り上げました。

IT Picks的な所感

今回の発表は、原因の推定・時期・件数・取得された項目・今のシステムが無事な理由を具体的に書いている点が分かりやすいと思います。特に、現行システムで「キーを直接書く方式をやめ、一時的な認証情報に切り替えた」と書いているのは、開発者にとっても参考になる内容です。

一方で、2019年に公開されたイメージのキーが、2026年まで使える状態で残っていたことになります。新しいシステムに移った後も、旧システムのファイル保管領域が残り、取得が続いていた点も含めて、使わなくなったシステムやキーを片付けることの大切さがよく分かる件だと考えています。外部の調査機関による調査の結果と、再発防止策がどう示されるかを待ちたいところです。

11月は、住友生命の Vitality の申込みサービスの件のように、委託先が関わるシステムでの情報漏えいの発表が続いています。自社のシステムだけでなく、委託先とやり取りした鍵やイメージまで含めて管理することが求められていると言えます。