SKIMAにアクセスできない原因はIDCFクラウドへのランサムウェア攻撃、復旧の状況は

Shiritomo編集部 @shiritomoAI_jp 2026年10月9日 更新
SKIMAにアクセスできない原因はIDCFクラウドへのランサムウェア攻撃、復旧の状況は

10月7日午前3時40分。
福島県白河市のデータセンターで、何者かがランサムウェア(身代金要求型ウイルス)を仕掛けました。
その影響は、クリエイターがイラストやデザインの制作を依頼できるスキルマーケット「SKIMA」を含む495の企業・自治体に及んでいます。

フリーランスで活動するクリエイターや、副業で創作系のサービスを使っている方にとって、「自分が使っているツールが、ある日突然つながらなくなる」のは他人事ではありません。
SKIMAで何が起きていて、今どうなっているのかを調べてみました。

先に結論をまとめると:
– SKIMAの障害は自社システムではなく、利用している外部クラウド基盤「IDCFクラウド」へのランサムウェア攻撃が原因
– 本人確認書類・クレジットカード情報はIDCFクラウド側に保管されておらず、現時点で漏洩は確認されていない
– 一時は復旧困難とされたデータも、復旧できる見込みが立ち、新サーバーへの移行作業が進んでいる

何が起きたのか

SKIMAは10月7日午前3時40分ごろから、サイトにアクセスできない状態が続いています。
原因は、SKIMAが利用するクラウドサービス「IDCFクラウド」(運営はソフトバンクの子会社IDCフロンティア)で発生した、第三者によるランサムウェア攻撃です。
影響はSKIMA一社にとどまらず、バスケットボール協会やラジオ局、カプセルホテルチェーン、Jリーグクラブ、複数の自治体など、495の企業・自治体に広がっています。

10月8日夜、SKIMA公式はX上で画像付きのスレッドを投稿し、状況を説明しました。

投稿によれば、当初はサーバー環境での復旧が非常に難しい状況でしたが、確認を進める中で復旧に利用できるデータが残っていることが分かり、現在は具体的な復旧作業を進めているとのことです。
ただ、公式の説明だけでは「結局どこまで安全なのか」「なぜ自社サービスなのに外部の攻撃で止まるのか」までは見えてきません。
そこで報道各社の一次情報を確認してみました。

調べて分かったこと

なぜSKIMA自身ではなくIDCFクラウドが狙われたのか

SKIMAのようなWebサービスの多くは、自前でサーバーを持たず、クラウド事業者が提供するサーバー環境を借りて運営しています。
IDCFクラウドはその貸し手の一つで、今回はこの基盤そのものが攻撃を受けました。
ITmedia NEWSの報道によると、攻撃は10月7日午前3時40分ごろ、福島県白河市のデータセンターにある「東日本リージョン1」で発生し、第三者によるランサムウェア攻撃だったとIDCフロンティアが明らかにしています。
影響を受けたのはIT企業に限らず、業種を問わず495の企業・自治体にのぼりました。
1つのクラウド基盤が止まると、そこを使う無関係な何百もの企業が同時に巻き添えになるという構図が、今回あらためて浮き彫りになったといえるでしょう。

データは本当に守られているのか

SKIMA公式の説明では、本人確認書類やクレジットカード情報はIDCFクラウド側で保管しておらず、今回の障害によって漏洩することはないとしています。
また、IDCFクラウド側に保管されていた情報についても、現時点で漏洩は確認されていないとの回答を受けたそうです。
一方でImpress Watchの報道では、IDCFクラウド側が対象ゾーン(tesla・henry・pascal・joule)に保管されたデータについて「取り出しや復元が困難な見通し」と発表しており、復元できるのは顧客自身が持つバックアップデータからのみとしています。
SKIMAの場合は幸い復旧できるデータが見つかりましたが、バックアップを取っていなかった他の利用企業では、データそのものが戻らない可能性もあります。

クラウドサービスが止まったとき、バックアップはどう備えるか

今回のように、普段使っているサービスが外部の攻撃で突然止まる事態は、SKIMAに限った話ではありません。
クリエイター活動や副業でクラウド上のサービスに作品データ・顧客情報・取引履歴を預けている方は少なくないでしょう。
IDCFクラウドの対応からも分かる通り、クラウド事業者側の障害では、最終的に頼れるのは利用者自身が取っているバックアップだけという場面が起こり得ます。
制作中の作品や取引のやり取りは、サービス内に保存するだけでなく、定期的に自分のPCや外部ストレージにも書き出しておくと、いざというときの備えになりそうです。

Shiritomo編集部の考察

今回の件で印象的だったのは、SKIMAが「自社の問題ではない」と説明しつつも、利用者への情報発信を止めなかった点です。
原因を外部の攻撃だと突き放すのではなく、復旧の進捗や個人情報の扱いまで具体的に公開したことで、不安を抱える利用者への説明責任を果たそうとした姿勢がうかがえます。
クラウド基盤の障害は運営企業にとっても「もらい事故」に近いものですが、だからこそ情報開示の丁寧さが利用者の信頼を左右するのではないでしょうか。
フリーランス向けプラットフォームを使う側も、サービスの裏側にどんなクラウド基盤が使われているかまでは普段意識しないものです。
しかし今回のように、一つの基盤障害が業種横断で500近い組織に波及する例を見ると、「便利な外部サービスに頼る」ことと「自分の資産を自分でも守る」ことは、セットで考えておく必要がありそうです。

まとめ

SKIMAのアクセス障害は、自社システムではなく利用先のクラウド基盤「IDCFクラウド」へのランサムウェア攻撃が原因でした。
個人情報の漏洩は現時点で確認されておらず、データ復旧の作業も進んでいます。
ただし今回の件は、外部サービスに依存する以上、自分のデータは自分でも守る備えが欠かせないことを教えてくれる出来事でもありました。

さらに深掘りしたい方へ

今回の障害の経緯や影響範囲については、以下の報道も参考にしました。