NTTスマートコネクトのレンタルサーバサービス「スマイルサーバ」の一部設備が不正アクセスを受け、2026年7月24日13時にサービスを全停止したまま、本記事執筆時点（8月26日）でも復旧していません。対象は収容サーバ jm9.etius.jp と jm10.etius.jp の2台で、それ以外の利用者に影響はないと同社は説明しています。
情シスにとって重いのは、漏えいの有無よりも「1カ月以上、Webとメールが止まったまま、預けていたデータも返してもらえない」という事実のほうです。同社は調査対象の設備からデータを渡すと二次被害のおそれがあるとして、利用者にホームページとメール環境の再構築を求めています。復旧環境の提供目標は9月中旬です。
これは自社のパッチ適用や設定では防げない、委託先インフラ側の事故です。だからこそ、平時に効く打ち手は「対策の追加」ではなく「どこに何を預けているかの棚卸し」と「自社側にデータの複製を持っているか」の2点に集約されます。
この記事でわかること
- スマイルサーバで何が起き、どこまで公表されているか（一次情報ベース）
- 自社が対象（jm9/jm10）かどうかを確認する具体的な手順
- なぜ「データを返してもらえない」のか、その判断の妥当性
- 同種の事故に備えて情シスが平時にやっておくべきこと
スマイルサーバとは何か（「うちは使っていない」と即断しない）
スマイルサーバとは、NTTスマートコネクトが提供する法人向けの共用レンタルサーバサービスです。1台のサーバ設備に多数の契約者を収容し、Web・メール・FTPをまとめて提供する、いわゆるホスティングサービスにあたります。NTTスマートコネクトは2000年設立のNTT西日本グループ会社で、ハウジング・クラウド・ストリーミングなどを手がけています。
この種のサービスは情シスの管理台帳から抜け落ちやすい点に注意が必要です。コーポレートサイトや代表メールアドレス（info@ など）が、過去に総務や広報、あるいは制作会社の名義で契約されたまま引き継がれていることは珍しくありません。今回の被害はサービス全体ではなく「特定の収容サーバ2台」で切れているため、契約の有無だけでなくホスト名まで分からないと該当判定ができません。
何が起きたのか
NTTスマートコネクトが2026年8月19日に公表した「当社サービスへの不正アクセスに関するお詫びと今後の見通しについて」によると、経緯は次のとおりです。
| 日付 | 内容 |
|---|---|
| 2026年7月24日 | jm9.etius.jp / jm10.etius.jp への第三者による不正アクセスを確認。被害拡大防止のため同日13時に当該設備上の全サービスを停止。同日、社内に対策本部を設置 |
| 2026年7月27日 | 代替サーバの提供を開始（申し込み順に利用可能） |
| 2026年8月19日 | コーポレートサイトでお詫びと今後の見通しを公表 |
| 2026年8月末（見込み） | 外部の専門調査機関によるフォレンジック調査の完了予定 |
| 2026年9月中旬（目標） | 停止時点の環境を「復旧環境」として提供開始（調査結果により前後する可能性あり） |
侵入経路や原因は公表されていません。調査中であり、再発防止策も調査結果を踏まえて改めて公表するとされています。関係省庁への所定の報告は済んでいるとのことです。
情報漏えいは確認されているのか？
現時点では確認されていません。ただし同社は調査が継続中であり、漏えいが確認された場合は対象利用者へ個別連絡するとしています。「漏えいしていない」と確定したわけではなく「まだ確認されていない」段階であり、この違いは経営層への報告で必ず区別してください。
自社が対象かどうかを確認する手順
契約書を探す前に、DNSを引くのが最も速い方法です。自社ドメインのWebとメールがどのホストに向いているかを確認します。
- Web：
nslookup -type=A example.co.jpでIPアドレスを確認し、逆引き（nslookup <IPアドレス>）でホスト名を見る - メール：
nslookup -type=MX example.co.jpでメールの宛先ホストを確認する - スマイルサーバの管理画面URLやFTP接続先設定に
etius.jpが含まれていないかを確認する
該当した場合は、代替サーバへの移行申し込み状況を確認したうえで、当該設備のFTP・メールアカウントと同一パスワードを他サービスで使っていないかを点検します（同社も変更の検討を呼びかけています）。使い回しの危険性はその心理を扱った研究記事でも触れています。
あわせて、同社を装った不審なメールや電話への注意喚起も出ています。「復旧手続きのご案内」を装ってFTPパスワードを聞き出す手口は容易に想像できます。同社はパスワードやクレジットカード情報を尋ねることはないと明言しています。
なぜデータを返してもらえないのか
利用者側から見れば「せめて自分のデータだけでも返してほしい」というのが率直な感覚でしょう。しかし同社は、当該設備が調査対象であり、不正アクセスの影響を受けている可能性を否定できないため、いま渡すと利用者側の環境で二次被害を生じさせるおそれがあると説明しています。
これはインシデント対応としては筋の通った判断です。侵害されたサーバ上のファイルにはWebシェルや改ざんされたスクリプトが紛れ込んでいる可能性があり、検証前に持ち出して新環境へ展開すれば攻撃者の足場ごと引っ越すことになりかねません。フォレンジック調査中の証拠保全という観点からも同じです。
とはいえ利用者にとっては「バックアップも含めて手元に何も残っていない」状態です。ホスティング事業者のバックアップオプションを契約していても、それが同じ設備の中にあるなら、設備ごと止まった瞬間に手が届かなくなります。ここが本事案の最大の教訓だと考えます。
現場目線の課題：防げない事故にどう備えるか
共用レンタルサーバの利用者はOSやミドルウェアの管理権限を持たないため、今回の侵害を利用者側の対策で防ぐ手段は事実上ありません。社内で「なぜ防げなかったのか」と犯人探しを始めても時間を失うだけです。情シスがコントロールできるのは、事故が起きた後の復旧速度のほうです。
実感として重いのは、Webサイトの停止よりもメールの停止です。代表アドレスや部門メールが1カ月止まれば、取引先からの発注も問い合わせも届きません。レンタルサーバを「サイト置き場」としてしか認識していないと、この影響度を見誤ります。
もうひとつ気になるのは告知の見つけにくさです。7月24日以降の一次情報はスマイルサーバのユーザサポートサイトで随時更新されていましたが、コーポレートサイトでの「お詫びと今後の見通し」の掲出は8月19日でした。契約先の障害情報を能動的に見にいく仕組みがないと、社内の誰も気づかないまま日数が過ぎます。通知先が異動した担当者のままで宛先不明、というのもよくある話です。
国内のホスティング事業者の侵害は今回が初めてではなく、過去にはさくらインターネットのレンタルサーバ侵害もありました。共通基盤が侵害されたケースと同様、「自社は何も間違えていないのに止まる」リスクとして扱う必要があります。
情シスはどうすべきか
個別の対策リストを新しく作るより、公的機関の指針に沿って自社の委託・クラウド利用の棚卸しを見直すほうが確実です。
- IPA「中小企業の情報セキュリティ対策ガイドライン」：委託先管理と事故発生時の対応を含む基本文書です。まずはここから。
- IPA「中小企業のためのクラウドサービス安全利用の手引き」（PDF）：同ガイドラインの付録。事業者へ確認すべき項目（障害時の連絡体制、データの取り扱い、バックアップの範囲）が整理されており、契約の見直しにそのまま使えます。
- IPA「セキュリティインシデント対応 机上演習教材」：「委託先が止まって1カ月データが戻らない」というシナリオは、机上演習の題材として現実的です。
そのうえで、今回の事案から具体的に効く確認は次の3点だと考えます。
- ホスト名レベルの棚卸し：ドメイン・サイト・メールがどの事業者のどの収容サーバに載っているかを一覧化する（制作会社名義の契約も含めて）。
- バックアップの置き場所：事業者のバックアップオプションが同一設備内で完結していないかを確認する。Webのコンテンツとメールデータを、自社側または別事業者にも複製しておく。
- 障害情報の受信経路：契約先の障害情報ページを定期確認する担当と手段を決め、通知先メールアドレスが退職者・異動者のままでないか点検する。
加えて、社員へ「復旧の案内を装う不審なメールに注意」と一言出しておくだけでも効果があります。事故対応中は誰もが早く復旧させたい心理になり、普段なら疑うメールを開いてしまうためです。
まとめ
- スマイルサーバの収容サーバ2台（jm9 / jm10.etius.jp）が不正アクセスを受け、2026年7月24日13時から停止が続いています。調査完了見込みは8月末、復旧環境の提供目標は9月中旬です。
- 情報漏えいは「現時点で確認されていない」段階で、確定ではありません。調査対象のためデータの返却もできず、利用者はWebとメールの再構築を求められています。
- 利用者側の対策では防げない事故です。ホスト名レベルの資産棚卸し、事業者の外にもバックアップを置くこと、障害情報の受信経路を決めておくことが平時の備えになります。
