- share :
レンタルサーバー大手の「さくらインターネット」が、不正アクセスの被害を相次いで公表しています。自社サイトや業務システムの土台にこの事業者を使っている中小企業も多く、「自分の会社のデータは大丈夫なのか」「何をどこまで警戒すればいいのか」と不安を抱えている担当者は少なくないはずです。
最初の発表では「さくらのレンタルサーバ」の583アカウントへの不正ログインとされていました。ところがその2日後、契約情報を管理する別のシステムへの不正アクセスが判明し、影響を受けた可能性のあるアカウントは最大136万563件にふくらみます。
本記事では、公表されている情報をもとに何が起きたのかを時系列で整理し、さくらインターネットの対応をどう見るべきか、そして「事業者にインフラを預ける」という選択そのものについて、DXportal®編集部の考えをお伝えします。
【本記事の要点】
- さくらインターネットは2026年8月9日に不正アクセスを検知し、第一報は8月17日、第二報は8月19日に公表した
- 被害の見立ては第一報の583アカウントから、第二報で最大約136万アカウントへと大きく広がった
- 侵入経路や攻撃の詳細は、本記事の執筆時点(2026年9月3日)でも公表されておらず、次の情報更新は「9月中旬」の予定とされている
- セキュリティ事故は避けられない。だからこそ、検知から公表までの速さと情報開示の丁寧さが、インフラ事業者への信頼を左右する
さくらインターネットに何が起きたのか
まず、さくらインターネットがこれまでに公表してきた内容を、時系列で確認します。
| 日付 | 公表・対応の内容 |
|---|---|
| 2026年8月9日 | 「さくらのレンタルサーバ」で不正アクセスを検知し、調査を開始 |
| 8月17日(第一報) | 583アカウントで不正ログインを確認。一部のサーバーにマルウェアが設置されていたと公表 |
| 8月19日(第二報) | 契約情報を管理する「販売管理システム」への不正アクセスが判明。最大136万563アカウントの契約情報が第三者に閲覧・取得された可能性、うち30アカウントではハッシュ化されたパスワード情報にアクセスされた可能性があると公表 |
| 8月26日 | 問い合わせ専用の電話窓口を開設し、第二報を更新 |
| 9月2日 | よくある質問(FAQ)を更新し、通知メールの見分け方や利用者が取るべき対応を追記 |
注目したいのは、第一報から第二報までのわずか2日間で、影響範囲の見立てが583アカウントから最大約136万アカウントへ跳ね上がっている点です。
閲覧された可能性がある情報は、次の通りです。
- 会員ID
- 会社名
- 部署名
- 住所
- 氏名
- 電話番号
- メールアドレス
- 生年月日
- 性別
- FAX番号
- 契約サービス
- 契約期間
- 請求金額
つまり、契約にまつわる情報のほぼ全体に及んでいるのです。ただし、クレジットカード情報は保持していないため、漏えいはないと発表されています。なお、さくらインターネットはこれらの件数について「影響が確定した数ではない」と説明しており、あくまで可能性のある最大値という位置づけのようです。
また、販売管理システムへの不正アクセスは、8月9日に検知したレンタルサーバへの不正アクセスよりも前に発生した事象であり、両者の関連は現在も調査中とされています。侵入経路、攻撃者、使われたマルウェアの種類は、いずれも公表されていません。
出典・参照:
さくらインターネットの対応をどう見るか
公表された事実を並べると、対応の遅さと詰めの甘さが見えてきます。ここでは、気になる3つの点を指摘したうえで、評価できる部分にも触れます。
指摘1:被害範囲の見立てが、2日で約2,300倍にふくらんだ
まず気になるのは、被害範囲の把握が二転三転していることです。第一報の583アカウントに対し、第二報では最大約136万アカウント。わずか2日で、対象の見立てが2,300倍以上にふくれ上がりました。しかも販売管理システムへの侵入は、レンタルサーバの不正アクセスを検知するよりも前に起きていた事象です。
調査の初期段階で影響範囲を絞りきれないこと自体は、珍しくありません。問われるのは、その不確実さの示し方です。第一報を見た利用者の多くは、「583件のうちの1つでなければ、自社は無関係」と受け止めたはずです。その前提が2日で崩れました。初報の段階では、確定した数字を小さく出すよりも、「範囲はさらに広がりうる」と幅を持たせて伝えるほうが、利用者に誤った安心を与えずに済んだはずです。
指摘2:利用者への案内と、窓口の開設が遅い
次に考えたいのは、利用者が動きだすための情報と窓口の提供が遅いことです。専用の電話窓口が開設されたのは第二報の1週間後、8月26日でした。パスワード変更をどの範囲で行うべきか、通知メールを装ったフィッシングをどう見分けるか、といった実務的な案内がFAQとしてまとまったのは9月に入ってからです。
事故対応で利用者にとって最も価値があるのは、「今日、自分は何をすればよいか」がすぐにわかることです。攻撃者が契約情報を握っている以上、それを悪用した二次被害はいつ始まってもおかしくありません。窓口や案内文は、事故が起きてから用意していては間に合わない性質のものです。平時のうちに雛形を準備し、公表と同時に出せる状態にしておく。そこまでが、インフラ事業者のインシデント対応に含まれているべきでしょう。
指摘3:根本原因の説明が、まだない
そして、根本原因の説明がありません。本記事の執筆時点(2026年9月3日)で侵入経路も攻撃手法も公表されておらず、次の情報更新は「9月中旬」とだけ告知されています。調査中の事項をむやみに出せないことには、一定の合理性があります。
とはいえ、利用者が本当に知りたいのは、詳細な技術情報そのものよりも、「この基盤を使い続けてよいのか」を判断する材料です。原因がまだ言えないのなら、せめて「何が」「いつまでに」わかる見込みなのかを具体的に示す必要があります。そこがあいまいなままだと、利用者は乗り換えの判断も、様子見の判断もできず、宙づりのまま待たされることになってしまいます。
評価できる点:必要な対応には着手している
一方で、さくらインターネットが公表・実施している対応には、評価できる部分もあります。
- 経緯の公表にあわせた謝罪の表明
- 不正に使われた認証情報の失効
- マルウェアの除去と、関連システムの監視強化
- 外部専門機関によるフォレンジック調査
- 関係機関への報告
- 対象となる利用者への個別通知
これらは、インシデント対応の型からは外れていません。問題は、その一つひとつのタイミングが、利用者が求める速度に追いついていないことに尽きるのです。
出典・参照:
セキュリティ事故は新しくない。問われるのは「その後」
ここからは、この一件をどう受け止めるべきか、DXportal®編集部の考えを述べます。
セキュリティの問題は、いまに始まったことではありません。どれだけ対策に投資しても、不正アクセスの可能性をゼロにはできない。これは規模の大きな事業者でも同じです。「大手だから安全」という前提は、すでに成り立たなくなっています。
そのため、「事故が起きた」という一点だけを理由にひとつの事業者を切り捨てるのは、現実的な態度とは言えません。どの事業者を選んでも、事故の可能性からは実質的に逃れられないからです。
本当に問われるのは、事故が起きた後の振る舞いのほうです。検知から公表までに何日かけたか。被害範囲の見立てを、どれだけ早く、正確に示せたか。利用者が次に何をすればよいかを、どれだけ具体的に、繰り返し伝えたか。原因の説明を、いつまでに出すと約束したかが問われるのです。
この観点で見ると、今回のさくらインターネットの対応は、いずれも後手に回った印象が否めません。とりわけ、ITインフラそのものを事業とする会社であれば、セキュリティ事故が起きたときの説明責任のハードルは、一般の事業会社より高く置かれるべきです。基幹インフラを預かる事業者には、平時のサービス品質と同じ水準で、有事の情報開示の速さと丁寧さを求めたいところです。そこが伴わなければ、利用者は安心して業務を預けられません。
同時に、これは利用者側の備えを見直す機会でもあります。自社が使っているクラウドやレンタルサーバーの事業者が、過去のインシデントをどう公表し、どう収束させてきたか。契約の前や更新のタイミングで、その「事故対応の履歴」を一度は調べておくとよいでしょう。
あわせて、パスワードの使い回しをやめる、多要素認証を設定する、事業者からの通知を装ったメールを警戒する、といった基本的な守りを固めておく。これらはどの事業者を使っていても意味を持つ対策です。
まとめ:事業者を選ぶ基準は、事故が起きたときにこそ表れる
さくらインターネットの不正アクセスは、当初の583アカウントから最大約136万アカウントへと被害の見立てが広がり、原因の説明は執筆時点でも出ていません。必要な対応には着手しているものの、公表の速さ、窓口の準備、原因説明の見通しのいずれもが、利用者の不安に先回りできていないのが実情です。
利用者のシステムを預かる事業者の仕事には、平時の安定運用だけでなく、事故が起きたときの初動と情報開示までが含まれます。そして、その備えの厚さは、料金表にもスペック表にも書かれていません。
インフラを事業者に預けるということは、平時の性能だけでなく、有事にどう振る舞うかまで込みで相手を選ぶということです。今回の一件は、多くの企業にとって、自社の取引先を同じ基準で見直し、あわせて自社側の守りを固めなおす機会になりました。事業者を選ぶ基準は、平常時の価格や機能ではなく、事故が起きたときの対応にこそ表れるのではないでしょうか。
執筆者
DXportal®運営チーム
DXportal®編集部
DXportal®の企画・運営を担当。デジタルトランスフォーメーション(DX)について企業経営者・DX推進担当の方々が読みたくなるような記事を日々更新中です。掲載希望の方は遠慮なくお問い合わせください。掲載希望・その他お問い合わせも随時受付中。


