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