信濃毎日新聞社は2026年9月28日、読者サイト「なーのちゃんクラブ」（nano.shinmai.co.jp）上の「信毎ポイント交換システム」が不正アクセスを受けたと公表した。9月7日に検知し、一部の履歴データが消去される事象が発生したが、データ復旧は完了、ポイント残高への影響はなく、現時点で個人情報の外部漏洩は確認されていないという。
公表文は短く、技術的な詳細にはほとんど触れていない。しかし外形的に確認できるインフラ構成をたどると、次に確認すべき問いが浮かび上がる。
被害が信毎だけなら、問うべきは「鍵」の出所だ。
公表されている事実は以下のとおり。
注目すべきは「委託先」への言及が一切ないことだ。システムを誰が運営・ホスティングしているのかは、この公表文だけでは分からない。
DNSレコード、IPアドレスの帰属、公開ページの構成要素から、信毎デジタルのサービスは少なくとも3つの事業者にまたがっていることが確認できる。
不正アクセスの公表が掲載されたこのサイトは、長野市の株式会社電算（東証スタンダード 3640）が運営するAS17955上のIPアドレスに収容されている。CMSはWordPressで、ページソースの /wp-content/ パスから確認できる。
同じIPレンジには、複数の信毎サブドメインのほか、電算が他の組織向けに提供しているとみられるホストも存在する。電算は自社サイトで、オープンソースCMS「SHIRASAGI」によるマルチテナント方式のWebホスティングを提供していると説明しており、1システムで複数組織のサイトを運用できることを特徴として挙げている。
会員登録・ログイン・プラン管理を担うこのサブドメインは、さくらインターネットのIPアドレスに解決する。nanoとは異なる事業者の基盤上にある。
ニュース記事を配信する本体サイトはAmazon CloudFrontを経由しており、マイメニュー（/mymenu/）もこのドメイン配下にある。
信毎デジタルのログインフローでは、共同通信系の認証基盤（kyodonewslab.jp）を経由する共通SSOが確認できる。同じ認証基盤は、複数の地方紙デジタル版でも利用されている。
信毎デジタルのサービス構成
[nano.shinmai.co.jp] [member.shinmai.co.jp] [www.shinmai.co.jp]
読者サイト・ポイント案内 会員基盤・ログイン ニュース配信
WordPress さくらインターネット AWS CloudFront
電算 AS17955
\ | /
------- kyodonewslab.jp 共通SSO ----------
（共同通信系認証基盤）
ここで重要な問いが生まれる。
不正アクセスを受けた「ポイント交換システム」は、この構成図のどこに位置するのか。
nano上のページはポイント残高の表示や交換商品の案内を担っているが、交換処理そのもの（ポイントの引き落とし、商品発送の指示、履歴の記録）がnanoと同じサーバー上で動いているのか、member配下なのか、あるいはまったく別のバックエンドなのかは、公開情報からは確定できない。
この不確定が、本稿の議論の前提条件になる。
信毎が公表した対象は、サイト全体ではなく、かなり限定して「信毎ポイント交換システム」だ。そして、履歴データの一部は消されたものの、保有ポイント数には影響がなかったとしている。
外形からは、信毎デジタルが複数のシステム・事業者を組み合わせて構成され、ポイント自体も「マイメニュー → ポイント詳細 → 商品交換」という複数段階になっていることが分かる。
そして周囲には、複数顧客を扱う委託・共通基盤が存在する。電算は自社サイトでSHIRASAGIのマルチテナント方式を提供していると説明しており、「複数のお客様が利用する場合は個々のお客様を論理的に隔離する」としている。nanoサイトが収容されているIPレンジには、電算が他の組織向けに提供しているとみられるホストも存在する。
ただし、今回侵害された「ポイント交換システム」そのものが、そのような共通サービス上にあるかどうかは、公開情報からは確認できていない。
その前提のうえで問う。もし交換処理が委託先の複数顧客向けサービス上にあるなら、なぜ現時点で公表されている被害は信毎だけなのか。
ここで仮説が分かれる。
共通基盤に脆弱性があり、攻撃者がそれを利用した場合、同じ仕組みを利用する他の顧客も確認対象になる可能性がある。しかし現時点で他社の同種被害は公表されていない。
この不在には複数の説明がありうる。攻撃者が信毎だけを標的として選んだ、信毎固有の設定だけが攻撃条件を満たした、あるいは他社では検知や公表がまだ行われていない、といった可能性だ。つまり「一社だけだから共通脆弱性ではない」とは断定できない。
APIキー、トークン、管理用アカウント、連携用シークレットなど、信毎だけに割り当てられた「鍵」が何らかの経路で窃取され、その権限でポイント交換システムに侵入された可能性だ。
この場合、攻撃者が手にしたのは「信毎の鍵」であり、他のテナントの鍵ではないため、被害が一社にとどまることを説明しやすい。
経路1：信毎側から。 信毎自身が運用するWebアプリケーション、管理端末、メール環境などから認証情報が流出した可能性。
経路2：委託先の管理・運用環境から。 システムを構築・運用する側の環境（CI/CDパイプライン、シークレット管理、保守用端末、バックアップなど）から、信毎テナント用の認証情報が流出した可能性。この場合、流出元は信毎ではなく運用側だが、流出したのが信毎固有の鍵であれば被害は信毎に限定される。
経路3：交換システム自体の脆弱性。 そもそも認証情報の窃取ではなく、交換システムのアプリケーション脆弱性を直接利用された可能性もある。この場合「鍵」は使われていない。
侵入経路の3つの可能性
[攻撃者]
│
├── 経路1: 信毎側の環境から認証情報を窃取
│ (Webアプリ / 管理端末 等)
│
├── 経路2: 委託先の管理・運用環境から窃取
│ (CI/CD / シークレット管理 / 保守端末等)
│
└── 経路3: 交換システム自体の脆弱性
(SQLi / RCE / 認証回避 / アクセス制御不備等)
│
▼
ポイント交換システムへ侵入
│
▼
履歴データの削除
被害内容として公表されている「履歴データの消去」も注目に値する。
データを盗むのではなく消す行為は、いくつかの動機を示唆する。ポイントの不正交換を行い、その痕跡（交換履歴）を消そうとした可能性。あるいは、より広範な侵入の証拠を隠滅しようとした可能性。いずれにしても、攻撃者が単に公開情報を閲覧しただけではなく、履歴データの状態を変更できるところまで到達したことになる。
ただし、それが正規の認証情報によるものなのか、アプリケーションの脆弱性を利用したものなのかは、公表内容からは判断できない。
それでも「信毎だけ」という状況が続くのであれば、テナント固有の認証情報や設定差は確認すべき候補になる。
確認できていること：
信毎ポイント交換システムが不正アクセスを受け、履歴データが消去された（公表済み）
nanoサイトは電算のネットワーク上にあり、電算はマルチテナント方式のサービスを提供している
信毎デジタルのサービスは複数の事業者にまたがっている
公表文に委託先への言及はない 確認できていないこと：
ポイント交換システムの処理基盤がどの事業者のインフラ上にあるか
侵入に使われたのが脆弱性なのか認証情報なのか
認証情報であった場合、その流出元
他の同一基盤上の顧客への影響の有無
今後の追加公表やフォレンジック調査の結果で、以下の点が明らかになれば、事案の全体像がかなり見える。
1. 何の履歴が消されたのか。 ポイント交換履歴なのか、操作ログなのか、アクセスログなのか。消されたデータの種類が、攻撃者の目的を示す。
2. 侵入に使われたのは脆弱性か認証情報か。 公表文の「修正措置を講じ」が脆弱性のパッチを意味するのか、認証情報の無効化・再発行を意味するのかで、性質がまったく異なる。
3. 認証情報であった場合、どこから流出したのか。 信毎側の環境からか、委託先の管理環境からか。これは事案の影響範囲を判断する分水嶺になる。
4. 委託先の他の利用企業に調査が広がったのか。 これが最も重要だ。共通基盤側の問題であれば、確認対象は信毎一社では終わらない。一方、信毎固有の認証情報の問題であれば、「なぜ信毎だけだったのか」の説明がつく。
今回の事案は、被害の規模だけを見れば「ポイント交換の履歴が消えて復旧した」という比較的小さなインシデントに見える。しかしインフラ構成を外形的に見ると、複数事業者にまたがるサービス構成、共有ホスティング環境の存在、共通認証基盤の利用という、地方紙デジタル版に共通する構造的な課題が透けて見える。
「なぜ信毎だけだったのか」という問いへの答えが、この事案の本質を左右する。信毎固有の鍵の問題であれば、なぜ現時点で被害が信毎だけに見えるのかを説明しやすい。一方、共通基盤そのものの問題であれば、確認対象は同じ仕組みを利用する他の事業者にも広がる。
だから次に知りたいのは、脆弱性の名前より先に、侵入に使われたのが「共通の穴」だったのか、「信毎だけの鍵」だったのかだ。
本稿は外形的に確認可能な情報（DNSレコード、IPアドレスの帰属、公開Webページの構成要素）に基づく分析です。事案対応中であることに配慮し、CTログ等から確認できる具体的なホスト名は記載せず、用途のみを示しています。外形調査で確認できるインフラ構成と侵入経路は別のものであり、本稿の仮説はいずれも現時点では推測です。
Aikido Community Japan
公開日: 2026/9/29
最終更新: 2026/9/29
セキュリティの最新情報をお届けします。