資さんうどんの従業員情報が外部から閲覧可能に｜委託先の「設定不備」を防ぐために発注側が決めておくこと

はじめに
何が起きたのか
なぜ「委託先の設定不備」は起きるのか
発注側が自社で整えておきたい仕組み
まとめ
参考

はじめに

情報漏えいのニュースというと、外部からの攻撃を思い浮かべる方が多いと思います。しかし実際には、攻撃ではなく「設定を誤っていた」ことが原因で、本来見えてはいけない情報が外から見える状態になる事故も少なくありません。

2026年10月27日、うどんチェーン「資さんうどん」を運営する株式会社資さんが、委託先が運用するサーバーの設定不備により、従業員・退職者の個人情報が外部から閲覧可能だった可能性があると公表しました。賃金履歴や退職理由といった、本人にとって特に知られたくない情報が含まれていた点も注目されています。

この記事では、事案の概要を整理したうえで、こうした「委託先の設定不備」がなぜ起きるのか、そして発注側として自社で何を決めておけばよいのかを、発注側支援の立場から解説します。

何が起きたのか

資さんの公式発表と報道によると、概要は次のとおりです。

資さんが委託している株式会社カホエンタープライズ（福岡市）が構築・運用する勤怠管理システムのサーバーで、設定の一部に不備があった
その結果、2021年10月〜2026年10月に在籍していた従業員・退職者の個人情報が、外部から閲覧可能な状態になっていた可能性がある
対象の情報は、氏名、生年月日、性別、電話番号、賃金履歴、勤怠実績。一部の人については入社日・退職日、退職理由、社会保険の加入履歴も含まれる
対象人数は公式には公表されていないが、日本経済新聞は約2万人と報じている
不備は委託先の自主点検で見つかり（報道によれば10月9日）、資さんに報告された
第三者がアクセスしたかどうかは確認できておらず、漏えいの可能性は否定できないとしている。10月27日時点で不正利用や二次被害は確認されていない

資さんは設定を変更して外部から見られない状態にし、個人情報保護委員会へ報告したうえで、対象者へ順次連絡しています。連絡がつかない退職者については、公表をもって通知に代えるとしています。また今後は、外部委託先のセキュリティ設定の確認やデータ管理の監督を強化するとしています。

なぜ「委託先の設定不備」は起きるのか

今回の事案は、特定の会社だけの問題というより、業務システムを外部に任せている多くの企業に共通する構造から生まれています。

「動いているか」は見ても「誰に見えているか」は見ない

勤怠や給与のような社内向けシステムは、日々の打刻や集計が問題なく動いていれば、発注側が中身を気にすることはほとんどありません。運用を委託していればなおさらです。不具合があれば現場から声が上がりますが、「外部から見えてしまっている」状態は業務に何の支障も出ないため、誰も気づきません。

設定不備による露出は、利用者側からは何も起きていないように見える。ここが攻撃による被害と大きく違う点です。

設定の責任があいまいなまま運用が続く

構築時の設定は委託先が行い、発注側は画面と帳票を確認して受け入れる。その後の設定変更も委託先が行う。こうした形では、「公開範囲やアクセス制御の設定が正しいかを誰が確認するのか」が、契約にも運用ルールにも書かれていないことがよくあります。

発注側は「専門家に任せているから大丈夫」と考え、委託先は「言われたとおりに作って動かしている」と考える。お互いが相手を安全の担い手だと思っている状態が、設定不備を長く放置させます。

人事データは「長く、広く」たまりやすい

今回、5年前に在籍していた人の情報まで対象になっています。勤怠や賃金の記録は法令上一定期間の保存が求められるため、ある程度の保有は必要です。ただ、業務で日常的に使わない退職者の情報まで、現役の業務システム上に同じ形で置き続ける必要があるかは別問題です。保有期間や置き場所が決められていないと、データは消されずに積み上がり、事故が起きたときの影響範囲が大きくなります。

発注側が自社で整えておきたい仕組み

ここからは、発注側支援のコンサルタントとして、同じことを自社で起こさないために何を決めておくべきかを整理します。ポイントは、「委託先にしっかりやってもらう」ではなく、「発注側として確認できる仕組みにする」ことです。

1. 設定の責任分担を「表」にして合意する

まず、委託しているシステムごとに、次のような項目について「誰が決め、誰が設定し、誰が確認するか」を一覧にします。

外部からアクセスできる範囲（公開／社内限定／特定IPのみなど）
ログインの方式と権限の設計
サーバーやストレージの公開設定
設定変更時の承認ルール

決めるのは発注側、設定するのは委託先、確認は両者、という分担が基本です。大事なのは「確認」の欄を空欄にしないことです。この表は、システム刷新や新規導入の際にセキュリティ要件として整理しておくのが理想で、その考え方は基幹システム刷新でのセキュリティ要件の整理方法をまとめた記事でも解説しています。

2. 受け入れ時に「外から見えないこと」を検収項目にする

多くの検収は、「画面が仕様どおりに動くか」を確認して終わります。ここに、「社外のネットワークからアクセスして、見えてはいけないものが見えないこと」を確認する項目を加えます。

難しい技術は必要ありません。たとえば、社外のスマートフォン回線からURLを開いてみる、ログインせずにデータのある場所へアクセスできないかを試す、といった確認でも効果があります。自社で判断できない場合は、外部の診断サービスを使う費用を、最初から導入予算に組み込んでおくのが現実的です。

3. 定期点検を契約に入れ、結果を報告させる

今回の不備は、委託先の自主点検で見つかりました。これは、点検が実際に機能したという意味で前向きな面もあります。ただし、発注側から見ると「委託先が自主的にやってくれたから見つかった」状態であり、仕組みとしては偶然に頼っています。

発注側としては、次のような内容を契約や運用ルールに明記しておきたいところです。

公開範囲・アクセス制御の点検を、年1回など決まった頻度で行うこと
設定変更やサーバー移行の後には必ず点検すること
点検結果を発注側に書面で報告すること

報告を受けたら、発注側の担当者が内容に目を通し、記録として残します。「点検の報告書が毎年届いているか」を確認するだけでも、委託先任せの状態からは一歩前進します。

4. 「見られたかどうか」を判断できるログを残させる

今回、第三者がアクセスしたかどうかは確認できていないとされています。アクセスの記録が十分に残っていない場合、事故が起きても「見られたかもしれない」としか言えず、対象者全員に連絡し、最悪のケースを前提に対応せざるを得ません。

アクセスログの取得範囲と保存期間は、事故が起きてから決めても間に合いません。どの操作の記録を、どれくらいの期間残すのかを、要件や契約の段階で決めておきます。ログは「事故を防ぐもの」ではなく、「事故の影響範囲を確定させるもの」だと考えると、必要性を社内で説明しやすくなります。

5. 人事データの保有期間と置き場所を決める

最後に、データそのものの持ち方を見直します。

法令で求められる保存期間を、人事・労務部門と確認する
退職者のデータは、一定期間が過ぎたら日常業務用のシステムから切り離し、アクセスできる人を限った保管場所へ移す
保存期間を過ぎたデータは、削除の手順と担当を決めて実際に消す

このルールは情シスだけでは決められません。人事・労務部門、法務部門と一緒に決め、委託先には「このルールに沿って運用すること」を指示する形にします。持っていないデータは漏れません。保有量を減らすことは、最も確実な被害の縮小策です。

まとめ

資さんうどんの事案は、攻撃を受けたわけではなく、委託先の設定不備によって従業員・退職者の機微な情報が外から見える状態になっていた、というものです。こうした露出は業務に支障が出ないため、誰かが意識して確認しない限り気づけません。発注側にできるのは、設定の責任分担を明文化し、受け入れ時と定期的な点検を仕組みにし、事故の範囲を確定できるログを残し、そもそも持つデータを減らしておくことです。「委託先に任せている」は、「確認しなくてよい」という意味ではありません。自社の業務システムについて、「今、外から何が見えているか」を答えられるか、一度確かめてみてください。

参考

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。