【更新 2026-08-03】本記事を見直し、論文本文（第III章 脅威モデル／結論）と照合して修正しました。主な修正点：「攻撃者の権限が明示されていない・防御手法への言及がない」としていた記述を、ホワイトボックス前提であること・今後の課題として挙げられている防御策に訂正。あわせて、予測クラスが98%以上保たれるのはサンプル毎の攻撃の結果である点と、ユニバーサル攻撃では正解率が5.6〜10.35ポイント低下する点を追記しました。
AIの出力は正しいのに、電気代とバッテリーだけが減っていく——そんな攻撃の実証結果が公開されました。2026年7月30日にarXivで公開された査読前の論文が、省電力AIチップ向けのスパイキングニューラルネットワーク(SNN)に対する「スポンジ攻撃」で、1回の推論あたりの演算量を最大2.6倍に増やせることを示しています。サンプル毎の攻撃では予測クラスが98%以上のサンプルで変わらないため、精度を監視しているだけでは気づけません。今すぐ全社対応が必要な脆弱性ではありませんが、AI基盤のコストと可用性をどう見張るかという宿題を突きつける内容です。
この記事でわかること
- スポンジ攻撃とは何か、通常のDoS攻撃と何が違うのか
- 今回の査読前研究で何が新しく分かったのか（具体的な数値）
- SNNを使っていない組織にとって、この研究がなぜ他人事ではないのか
- 情シスとして今の段階で押さえておくべき視点
スポンジ攻撃とは何ですか？
スポンジ攻撃(Sponge Attack)とは、AIモデルの出力の正しさは変えずに、推論にかかる計算量・消費電力・応答時間だけを意図的に膨らませる攻撃です。スポンジ（海綿）が水を吸うように、モデルに資源を吸わせることからこう呼ばれます。
狙いは機密の窃取でも改ざんでもなく、可用性とコストの毀損です。バッテリー駆動の機器なら稼働時間が削られ、従量課金のAI基盤なら請求額が膨らみます。概念自体は2021年のIEEE EuroS&Pで発表された「Sponge Examples」が起点で、通常のニューラルネットに対して資源消費を攻撃面として扱う研究の流れがあります。
従来のDoS攻撃との違いを整理すると、次のようになります。
| 観点 | 従来のDoS攻撃 | スポンジ攻撃 |
|---|---|---|
| 手段 | 大量のリクエストや不正パケットを送る | 正常な形式の入力を1件送る |
| 出力への影響 | 応答しなくなる | 正しい答えが返る |
| 気づき方 | トラフィック量・エラー率で分かりやすい | 精度監視では検知できない |
| 被害の出方 | 短時間で顕在化 | 電力・課金として徐々に蓄積 |
入力の「量」ではなく「質」で殴る攻撃だ、と捉えると分かりやすいと思います。当サイトでは以前、推論の思考時間を引き延ばすスローダウン攻撃を取り上げましたが、今回はレイテンシではなくエネルギーに焦点が当たっています。
今回の研究は何が新しいのか
論文は「Driving up Inference Energy on SNNs: Per-Sample and Universal Sponge Attacks」（Spyridon Raptis、Haralampos-G. Stratigopoulos、arXiv:2607.27990、2026年7月30日投稿）です。対象はスパイキングニューラルネットワーク(SNN)、つまり密な数値ではなく「スパイク」と呼ばれる疎な二値イベントで情報をやりとりする、ニューロモーフィック（脳型）ハードウェア向けのAIです。常時稼働のセンサーやバッテリー駆動のエッジ機器で、省電力を売りに採用が検討されている領域になります。
論文の主張を一言でまとめると、「省電力という長所そのものが、そのまま攻撃対象になる」という指摘です。スパイクが疎であるほど省電力なのですから、スパイクを増やせば省電力の前提が崩れる、という理屈です。
研究は2種類の攻撃を評価しています。
| 攻撃の種類 | やり方 | SynOps（シナプス演算量）の増加 | 実運用での現実味 |
|---|---|---|---|
| サンプル毎(per-sample) | 入力ごとに勾配ベースの最適化で専用のスパイク列を作る | 1.5〜2.6倍 | 効果は大きいが入力ごとに計算が必要 |
| ユニバーサル(universal) | 固定の二値パターンを事前に1つ作り、以降の全入力にXORで重ねる | 1.09〜1.24倍 | 効果は小さいが使い回せる分、脅威として現実的 |
評価に使われたデータセットはNMNIST、SHD、IBM DVS Gestureの3種類、SNNモデルも3種類です。そしてサンプル毎の攻撃では、少なくとも98%のサンプルで予測クラスが変わりませんでした。演算量の増加分をIntelのニューロモーフィックチップLoihi-1のエネルギーに換算すると、1推論あたり14マイクロジュール〜13.24ミリジュールの上乗せになると見積もられています。
著者らが「初めて」と述べているのは後者、イベント駆動の二値入力に対するユニバーサル・スポンジ攻撃です。倍率だけ見れば1.1倍前後と地味ですが、一度作れば以降ずっと使い回せる固定パターンである点が重要です。常時稼働の機器で1日中1.2倍の電力を吸われ続ければ、バッテリーの持ちという形で確実に効いてきます。
ただし、ユニバーサル攻撃はサンプル毎の攻撃のように予測をほぼ完全に保てるわけではありません。論文の実験では、清浄な入力と同じ予測を保てた割合は73〜91%（データセット別に91%／73%／89%）、正解率は5.6〜10.35ポイント低下しています。著者らはこれを「配備のしやすさ・再利用性と引き換えのステルス性のコスト」と位置づけています。
なぜ「精度を見ていても気づけない」のか
この研究で情シスが最も注目すべきは倍率そのものより、検知の盲点だと考えます。AIシステムの運用監視は、どうしても「正しい答えを返しているか」に寄りがちです。正解率、エラー率、異常な出力の割合——いずれも出力側の指標です。
スポンジ攻撃はその全部をすり抜けます。答えは合っているからです。ただしこれが完全に当てはまるのは入力ごとに最適化するサンプル毎の攻撃で、使い回し型のユニバーサル攻撃は正解率も数ポイント下げるため、そちらは精度監視でも兆候が出ます。異常が現れるのは電力・演算量・応答時間といった資源側の指標であり、そこを見ていなければ「なんとなくバッテリーの減りが早い」「今月のクラウド請求が少し高い」という、原因追及されにくい形でしか表面化しません。故障や経年劣化として片付けられてしまう可能性も十分にあります。
SNNを使っていない組織には関係ない話か
正直に言えば、ニューロモーフィックチップやSNNを本番投入している一般企業は、現時点ではごく一部です。この論文をそのまま自社に当てはめられる情シスは多くないでしょう。そこは誇張せずに書いておきます。
ただし、「資源消費を攻撃面として扱う」という発想の部分は、いま多くの組織が抱えているAI基盤にそのまま移植できます。
- 従量課金のAI API：入力次第で出力トークン数や思考ステップ数が膨らむなら、それは請求額を吊り上げる攻撃面です（いわゆる denial of wallet）。社外からの入力を受ける問い合わせボットや要約機能は特に該当します。
- 共有GPU基盤：社内で推論基盤を共有していれば、一部の重い入力が他部門のジョブの待ち行列を伸ばします。攻撃でなくとも、想定外に重い入力は同じ結果を招きます。
- エッジ・IoT機器：カメラやセンサーに載せた推論処理は、バッテリーと発熱に直結します。当サイトではエッジAIへの敵対的攻撃を電力解析で検知する研究も紹介しましたが、電力は攻撃の入口にも、検知の手がかりにもなります。
要するに、AIの監視項目に「1リクエストあたりのコストと処理時間」を入れているかという問いです。入れていないなら、この論文はSNNの話であると同時に、自社のAI基盤の話でもあります。
現場目線の課題
率直なところ、この種の脅威は現場にとってかなり厄介です。理由は3つあります。
第一に、被害が「事故」の顔をして現れないこと。侵害の痕跡もアラートもなく、コストと電力がじわじわ増えるだけです。インシデントとして起票されず、コスト削減の課題として経理から降りてくる、といった経路になりかねません。
第二に、正常な重い入力と切り分けられないこと。長い文書の要約も、複雑な画像の解析も、正当な業務利用として重い処理を要求します。「重い＝攻撃」とは言えない以上、閾値の設定は運用現場の判断に委ねられます。ここは経験則を積むしかない領域です。
第三に、そもそもAI基盤の資源消費を誰が見張るのか決まっていない組織が多いこと。AIの導入は事業部門が主導し、監視はインフラ担当、コストは経理と、責任が分散しがちです。「増えているのは知っていたが、誰も異常だと思わなかった」という状況は容易に起こります。限られた人員で日々の脆弱性対応に追われる中、こうした静かな劣化まで目を配るのは正直に言って難しい、というのが実感です。
情シスは今、何をすべきか
この論文単体で緊急対応を求められる場面は、まずありません。過剰反応は避けつつ、AI利用の棚卸しに1項目足すくらいの構えが妥当だと考えます。具体的には、社外からの入力を受けるAI機能について「1リクエストあたりのトークン数・処理時間・コスト」を記録しているか、上限（レート制限・タイムアウト・最大トークン数）を設定しているかを確認するところからです。
AIに限らない土台の部分は、公的機関の指針に沿うのが結局は近道です。自前で長大なチェックリストを作るより、以下を出発点にしてください。
- 中小企業の情報セキュリティ対策ガイドライン（IPA）：資産の把握と体制づくりの基本形。AI基盤も「情報資産」として棚卸しの対象に含める発想が要ります。
- セキュリティインシデント対応 机上演習教材（IPA）：「侵入されていないがサービスが劣化している」というシナリオは、演習の題材として現実的で、部門間の役割分担の穴が見えやすいテーマです。
- 対策のしおり（IPA）：利用者向けの啓発資料。AI機能の使い方を含め、地道なユーザ教育の積み重ねが結局は効きます。
あわせて、社内でAI推論基盤を自前運用している場合は、基盤ソフトウェア自体の脆弱性管理も忘れないでください。SGLangの未修正RCE脆弱性のように、AI基盤は通常のミドルウェアと同じ攻撃面も抱えています。
この研究の限界と留意点
読み取る際に押さえておきたい前提を明示しておきます。
- 査読前のプレプリントです。arXivに投稿された段階であり、第三者による査読を経ていません。結果や解釈は今後変わりうるものとして扱ってください。
- 対象は限定的です。3つのSNNモデルと3つのデータセット（NMNIST、SHD、IBM DVS Gesture）での評価であり、他のモデルやタスクに同じ倍率が出る保証はありません。
- エネルギー値は実測ではなく推定です。14マイクロジュール〜13.24ミリジュールという数値は、演算量の増加分をLoihi-1の消費エネルギーに換算した見積もりです。
- 攻撃者はホワイトボックス前提です。論文の脅威モデル（第III章）は、攻撃者がモデルの重み・ニューロンのパラメータ・アーキテクチャをすべて知っていることを前提としています（実行時に重みを書き換える攻撃は対象外）。強い前提ではありますが、敵対的攻撃の評価では標準的な想定だと著者らは述べています。防御手法は本論文では評価されておらず、結論部で今後の課題として「入力分布の監視」と「スパイク発火率の正則化」が挙げられているにとどまります。
まとめ
- スポンジ攻撃は「答えは正しいまま資源だけを吸う」攻撃で、査読前の新研究はSNNで演算量が最大2.6倍、予測クラスは98%以上で不変という結果を示しました（いずれも入力ごとに最適化するサンプル毎の攻撃の値。使い回し型のユニバーサル攻撃は増加が1.09〜1.24倍にとどまる一方、正解率も低下します）。
- 精度ベースの監視では検知できません。異常が出るのは電力・演算量・応答時間という資源側の指標です。
- SNN未導入でも発想は移植できます。従量課金のAI APIや共有GPU基盤について「1リクエストあたりのコストと処理時間」を測り、上限を設けているかを確認しておきましょう。
出典
- Spyridon Raptis, Haralampos-G. Stratigopoulos「Driving up Inference Energy on SNNs: Per-Sample and Universal Sponge Attacks」arXiv:2607.27990（2026年7月30日投稿・査読前）：https://arxiv.org/abs/2607.27990
- Ilia Shumailov et al.「Sponge Examples: Energy-Latency Attacks on Neural Networks」IEEE European Symposium on Security and Privacy (EuroS&P) 2021：https://www.research.ed.ac.uk/en/publications/sponge-examples-energy-latency-attacks-on-neural-networks/
- 独立行政法人情報処理推進機構(IPA)「中小企業の情報セキュリティ対策ガイドライン」：https://www.ipa.go.jp/security/guide/sme/index.html
- 独立行政法人情報処理推進機構(IPA)「セキュリティインシデント対応 机上演習教材」：https://www.ipa.go.jp/security/sec-tools/ttx.html
