同じCommuneなのに、なぜ漏れた情報が違ったのか ― 23組織の比較から見える共通署名鍵、テナント巡回、そしてガバナンス

2026年10月、コミュニティプラットフォーム「Commune」に不正アクセスが発生した。

コミューン株式会社の10月9日の公表では、漏えい対象となった情報は推計約30万7,000人分。メールアドレスを含む情報が約12万6,000人分、含まない情報が約18万1,000人分だった。

しかし、今回気になったのは30万人という数字ではない。

同じSaaSで、同じ共通署名鍵が侵害されたのに、企業によって漏えいした情報も人数も違った。

氏名、会社名、役職、住所まで対象となった企業がある。

一方、メールアドレスとニックネーム、ポイントなど、コミュニティ内の情報が中心だった企業もある。

漏えいが確認されなかった企業もある。

そして、各社の不正アクセス時刻を比較すると、別の疑問が浮かんだ。

なぜヤマハでは約1,600人なのに8時間37分、VALXでは2,950人なのに59分なのか。

さらに、10月6日21時に全コミュニティをメンテナンスモードに切り替えたにもかかわらず、翌7日にも情報漏えいが確認されている。

各社の公表を比較し、Communeの公開技術情報と外形調査を重ねると、一つの攻撃モデルが見えてくる。

攻撃者は、共通署名鍵を悪用してテナント管理者になりすまし、通常APIから複数テナントを巡回しながら会員情報を取得していたのではないか。

そして、同じ取得処理でも、各テナントに保存された情報の量と内容が違っていた可能性がある。

これは仮説である。

以下では、公表された事実と区別しながら考えてみたい。

1. 23組織の比較――何人分の、どんな情報が対象となったのか

2026年10月11日時点で収集した23組織の公表を横比較した。

最初に重要なのは、漏えい人数だけではない。

メールアドレスが含まれていたのか。実名と結び付いていたのか。会社名や役職、住所まで保存されていたのか。

その違いを見てほしい。

※人数には確認済み、推定、最大、可能性が混在する。情報項目は各公表に記載された対象範囲であり、すべての項目が対象者全員について存在したことを意味しない。また、漏えいなしと報告された組織と、漏えい状況が未公表の組織は区別する。

ここでまず気付くのは、同じ会員情報でも、内容がまるで違うことだ。

ウイングアーク1stやソフトブレーンでは、実名と会社名が結び付く。

日本能率協会マネジメントセンターでは、住所や電話番号まで対象となっている。

一方、ZENBやVALXでは、メールアドレスとコミュニティ内のプロフィール、活動情報が中心だった。

単なるIDやニックネームだけなら本人を特定することは難しい。ただし、メールアドレスが加われば連絡可能な情報になり、会社名や役職が加われば、標的を具体的に絞ることもできる。

同じ1,000人分でも、漏えいした情報の意味は同じではない。

2. 会員数と漏えい人数――数字が一致しない理由

次に、会員総数が分かっているコミュニティだけを抜き出して比較する。

※単純比較であり、厳密な漏えい率ではない。会員数と漏えい対象人数は公表時点、母集団、確認基準が一致しない場合がある。青森びいきについては、コミューン側の10月6日1時3分時点の告知では16,697人となっている。

ここで最も気になるのが、2,950という数字だ。

VALX、青森県、日本能率協会マネジメントセンターで一致している。

会員数が3,813人のVALXでも、15,847人の青森県でも、2,950人だった。

2,950は50件の59回分、25件の118回分にあたる。

偶然かもしれない。

公表人数の推計方法によるものかもしれない。

しかし、共通のAPIを使うマルチテナントSaaSで、同じ数字が繰り返されたことは、取得処理の仕組みを考える材料になる。

APIが2,950件までしか返さない、と決め付ける必要はない。

攻撃者のプログラムが、一定の時間や回数だけ取得して次のテナントへ移っていた可能性もある。

3. 認証と会員データをどう管理していたか

今回の違いを考えるには、各社がCommuneへどう会員を登録していたのかを知る必要がある。

公開資料と外形調査から分かる範囲を整理した。

※ここでいうログイン方法は会員から見える登録・ログインの方式であり、内部で使われるSAML、OIDC、JWTなどの認証プロトコルや、会員作成方式まで確定するものではない。

この表で重要なのは、認証する場所と、個人情報を保存する場所は同じとは限らないことだ。

CommuneはSSOや、初回ログイン時に会員を作成するJITプロビジョニングに対応している。

外部の認証基盤にユーザーがいても、その人がCommuneに初めて登録する際に会員レコードを作成する方式がある。

反対に、APIで会員を事前登録することも考えられる。

また、認証時に渡す情報も設計次第で異なる。

ユーザーIDだけを渡す。

メールアドレスも渡す。

氏名や企業名まで同期する。

さらにCommune側でプロフィールを入力させる。

これらの違いによって、同じ認証基盤の利用者でも、Commune側に存在する情報は変わる。

SSOだから安全なのではない。SSOで何を渡したかが重要なのだ。

4. ヤマハの約1,600人は、なぜ少なかったのか

ここでヤマハとVALXの不正アクセス時間を比較したい。

時間幅は大きく違う。

しかし、これは連続して会員情報を取得していた時間ではなく、最初と最後の不正アクセスが確認された時間幅だ。

そしてヤマハには、ほかのコミュニティと異なる事情がある。

ヤマハネットワークエンジニア会（YNE）は、ルーター、スイッチ、無線LANなどを扱うネットワーク技術者向けのコミュニティだ。

Communeを利用する以前から会員基盤が存在し、旧サイトではSalesforce Sitesを使っていた。

ここで一つの仮説が浮かぶ。

旧会員のIDは新しいコミュニティへ引き継がれたが、メールアドレスやプロフィールなどは、利用に応じてCommuneへ保存されたのではないか。

もしそうなら、会員IDは存在しても、個人情報の属性が十分に入っていないレコードが多数存在した可能性がある。

同じAPIで同じ件数を取得したとしても、IDだけのレコードと、メールアドレスやプロフィールを持つレコードでは、得られる情報量が違う。

例えば、同じ2,950件を処理しても、ヤマハでは約1,600人分しか実質的な会員情報が得られなかった、という構造が考えられる。

ただし、実際に2,950件を処理した証拠も、IDだけの会員が多数いた証拠もない。漏えい人数の算定方法も未公表だ。

そのため、この説明は仮説にとどまる。

それでも、攻撃者がヤマハだけ異なる処理を行ったと考えるより、同じ処理をしてもデータの密度が違ったという可能性は検証に値する。

5. 攻撃者はテナントを巡回していたのではないか

VALXの59分間は、ヤマハの8時間37分の中に完全に含まれる。

このことから、複数テナントへの攻撃が時間帯として重なっていたと分かる。

しかし、それは必ずしも多くの処理が並列実行されていたということではない。

一つのプログラムがテナントAを取得し、テナントBへ移り、再びAへ戻るだけでも、最初と最後のアクセス時間帯は重なる。

ここで考えたのが、巡回処理だ。

一定時間または一定件数ずつ、複数テナントの会員情報を取得する。

取得位置を保存し、必要であれば次の巡回で続きを取得する。

このモデルなら、ヤマハの長いアクセス時間幅と、VALXの短い時間幅を一つの仕組みで説明できる可能性がある。

そして、2,950件という数字が複数の企業に現れたこととも整合する。

ただし、実際に巡回した順序や、取得位置を保存していたかどうかは確認できていない。

巡回は中心仮説であって、公表された攻撃手順ではない。

6. 共通署名鍵の侵害は公表された事実

ここで、確認された事実を押さえておこう。

ちとせグループは、攻撃者が全コミュニティ共通のログイン用署名鍵を入手し、コミュニティ管理者になりすましたと公表している。

Commune自身も、管理者になりすまして会員情報の閲覧・取得やデータの上書きが行われたと説明している。

つまり、管理者なりすましは事実である。

ただし、それはCommune基盤の運用管理者への侵入を意味しない。

テナントのコミュニティ管理者として、通常の管理機能から取得できる情報にアクセスした可能性がある。

我々の外形調査では、CommuneにはWeb画面とは別にAPIの入口が存在することを確認した。

スマートフォン専用なのか、Webとの共用なのかは特定できていない。

しかし、攻撃者は最初からそのような通常のAPIを直接呼んでいたのではないか。

この考え方なら、基盤管理者専用の別の侵入経路を仮定する必要はない。

ただし、実際に使われたAPIを特定できているわけではない。

7. メンテナンスにしても攻撃は止め切れなかった

Communeの公表時系列を確認する。

重要なのは、10月6日のメンテナンス切り替えが、すべての攻撃経路を遮断することにはならなかった点である。

Web画面をメンテナンスにしても、APIが別の入口でアクセスを受け付けていれば、攻撃者のプログラムには影響しない可能性がある。

もし攻撃者が最初から通常APIを直接利用していたなら、メンテナンス後も処理を継続できる状態だったのかもしれない。

これは、翌日に攻撃が新しく始まったという説明とは違う。

攻撃に使っていた経路を、メンテナンスでは止められなかった可能性がある。

ただし、実際に16時間連続して通信していたことや、残存経路が外形調査で確認したAPIだったことは未確認である。

8. 無被害企業との比較も欠かせない

ビジネスエアポートでは、Communeから受領した報告書の抜粋として、攻撃者のIPアドレス、アカウント、アクセスログ、操作ログ、API呼び出しを照合し、不正なログインや管理者なりすまし、情報閲覧・取得の形跡が確認されなかったと説明している。

また、SSO連携用署名鍵、APIトークン、Webhookなどの外部連携設定についても、取得された形跡はないと報告している。

これは全コミュニティ共通のログイン署名鍵とは別の確認項目だ。

ビジネスエアポートはビジネスマッチングを目的とするコミュニティであり、会員情報の潜在的な価値が低いとは思えない。

しかし、攻撃者がそのテナントを試していなかった可能性もある。

無被害だった理由を、保存データが少なかったことや認証方式の違いだけで説明することはできない。

一方、同社の公表には、何を確認して漏えいなしと判断したのかが具体的に示されている。

これは、委託先から受け取る調査報告の質という点で重要だ。

9. 23組織は、事故後に何を説明したのか

ここでも23組織の公表を比較した。

※10月11日時点に収集した23組織の公表文の分類。書かれていない事項が社内で実施されていないことを意味しない。「管理者なりすまし」等の分類は原因説明の主たる表現で整理した。

共通署名鍵の侵害という技術的原因まで説明したのは、最大843人が対象となったちとせグループだった。

一方、数千人規模の漏えいを公表した大企業でも、不正アクセスという説明にとどまる例があった。

ただし、公表の詳しさだけで、ガバナンスの優劣を判断することはできない。

社内で誰が判断したのか、どの情報を委託先に求めたのかは、必ずしも公表文に書かれないからだ。

それでも、ヤマハが委託先管理の見直しと、強化策・実施時期の決定に触れたことは注目に値する。

また、ビジネスエアポートのように、委託先による調査の対象項目まで明示することも、利用者への説明に役立つ。

10. ガバナンスとして評価すべき五つの項目

ここまでの比較を、事業会社の意思決定に引き付けて考えたい。

今回の侵害原因は、Commune側にあったと説明されている。

したがって、被害企業の設定や運用が侵害の原因だったという話ではない。

しかし、だからといって、利用企業がすべてを委託先に任せてよいわけではない。

何を預けるか。

どこまで管理者が取得できるのか。

どの経路を止めれば、本当に情報が取得できなくなるのか。

そして、その判断を誰が行うのか。

これらは事業会社が主体的に管理すべき事項である。

特に今回、コミュニティの運営担当部門と、顧客情報を管理する部門、情報システム部門、個人情報保護の担当部門の間で、データ連携の判断がどのように行われていたのかは、外部からは分からない。

しかし、実際の漏えい情報を見る限り、その判断の結果は企業ごとに異なっていた可能性がある。

11. 今回の事件から見えてきた二つの境界

今回のCommune事件を調べ始めたとき、最初に気になったのは、なぜ企業ごとに漏えい人数が違うのかということだった。

会員数が違ったのだろうか。

攻撃者が企業を選んだのだろうか。

それとも、取得する情報を選別していたのだろうか。

しかし、23組織の公表を並べていくと、別の可能性が見えてきた。

共通署名鍵を悪用した管理者なりすましは、公表された事実である。

そのうえで、攻撃者は通常APIを使い、複数テナントを巡回しながら会員情報を取得していたのではないか。

一定時間または一定件数ごとにテナントを切り替え、必要に応じて戻り、続きを取得する。

同じ取得処理でも、保存された情報の密度が違えば、得られる個人情報の量は違う。

ヤマハの長い攻撃確認時間幅と約1,600人という数字も、その可能性から考えることができる。

ただし、巡回処理、APIのページング、会員属性の欠損は、攻撃ログでは確認されていない仮説である。

その一方で、確実に残る問題が二つある。

一つは、データの境界だ。

外部の認証基盤に何を残し、Communeにどの情報を渡すか。

そして、Communeの管理者として何を取得できる設計にするか。

もう一つは、停止の境界だ。

Web画面をメンテナンスにすることと、攻撃者が情報を取得できない状態にすることは違う。

今回、Communeはメンテナンス切り替え後も残存経路を遮断する必要があった。

これは、サービス停止を通知することと、情報漏えいを封じ込めたことが同義ではないと示している。

SaaS事業者の共通署名鍵が侵害されることを、利用企業が完全に防ぐことは難しい。

しかし、自社の顧客情報をどこまで預けるのかは判断できる。

管理者がどの情報まで取得できるのかも確認できる。

そして、侵害が発生したとき、本当に攻撃経路を遮断できたのかを委託先に問い、再開を判断することもできる。

どのSaaSを選んだかだけではない。

そのSaaSが破られたとき、何を失う設計にしていたのか。

さらに、

サービスを止めたと言われたとき、本当に情報を取得できない状態になったと、誰が確認するのか。

今回のCommune事件は、そこまで含めて委託先ガバナンスを考える必要性を示しているのではないだろうか。

---

主な参照資料

• コミューン株式会社：2026年10月9日の公表
• ちとせグループ：ちとせアカデミーへの不正アクセス
• ヤマハ：お客様情報漏えいについて
• VALX：FUNコミュニティ会員情報漏えい
• 青森県：青森びいきへの不正アクセス
• ZENB JAPAN：ZENB GARDENに関する公表
• BASE FOOD：BASE FOOD Laboに関する公表
• Sansan：Sansan User Forumに関する公表
• piyolog：Communeへの不正アクセスの整理

調査時点：2026年10月11日。

本稿は各社公表文と公開技術情報、受動的な外形調査をもとにしている。比較表には、提示された23組織の調査で整理した情報を含み、全項目について一次資料の再照合が完了したものではない。

通常APIからの取得、テナントの巡回、25件・50件単位の処理、会員情報の密度による取得件数の違いは、公表情報と整合する仮説であり、攻撃ログによる確認事項ではない。