電子契約サービスの会社で、利用するシステムの一部に不正アクセスがあった。続報で顧客の文書や個人情報の漏えいは確認されなかったとした

何が起きたか

この事故で流出した、または流出したおそれがある情報は、続報で、顧客が保管した文書、顧客データベースの個人情報、顧客の認証情報について、取得や外部送信の事実は認められなかったとしたです。その後の対応と影響は、認証情報を無効にし、個人情報保護委員会に報告した。再発防止策として、認証情報の管理強化、開発・本番環境の管理の見直し、ソースコード内の認証情報を検知する体制の強化を挙げたです。

原因になったのは「利用するシステムの一部への第三者による不正アクセス（経路は非公表）」です。公表された内容では、生成AIは事故に関わっていません。

なぜ起きたか

公表されている直接の原因は、会社が利用するシステムの一部への第三者による不正アクセス。侵入経路は公表されていないです。それがどのように起きたかの詳しい経緯は、まだ公表されていません。新しい発表があれば、この記事に追記します。

原因の種類は「不正アクセス」です。第三者がシステムに入り、情報を見たり持ち出したりした事故を指します。このサイトに掲載している事故のうち、同じ種類の原因で起きた事故は131件あります。

事故が起きてから公表されるまで

1. 2026年8月27日不正アクセスを封じ込め、認証情報を無効化
2. 9月1日顧客に通知して公表し、個人情報保護委員会に報告
3. 10月9日続報で漏えいの事実は認められなかったと公表

どうすれば防げたか

上の流れでは、最初から公表まで、途中で異常に気づいて止める仕組みが働いていません。

止められた可能性がある所（当社の見立て）

開発環境と本番環境の認証情報を分け、ソースコードに認証情報を書かない仕組みがあれば、不正アクセスの入口を減らせた可能性がある。

この見立ては、公表された原因から当社が考えたものです。当事者の調査の結果とは異なる場合があります。

自社で確認する3つの手順

上から順に、短い時間で確認できるものを並べています。

1. ソースコードや設定ファイルに認証情報が書かれていないか検査する
2. 開発環境と本番環境で同じ認証情報を使っていないか確認する
3. 異常を検知した時の通知先と手順を確認する

自社に同じ原因があるか

当てはまるものを選んでください。1つでも当てはまれば、この事故と同じ原因が自社にもある可能性があります。

出典と更新の履歴

• 当社が利用するシステムへの不正アクセスに関するお知らせ（続報）2026.10.09