冷蔵庫が50℃になった日。

2026年10月11日の夜から12日の朝にかけて、フランス各地のスーパーマーケットで冷蔵庫と冷凍庫の温度が50℃に書き換えられました。

Intermarché、Netto、Carrefour、Monoprix、Super U。被害は数百店舗に及び、生鮮食品と冷凍食品はすべて廃棄。一部の店舗では火災も起きました。IntermarchéのCEOは「たった1日で全国で数千万ユーロの損失」と語っています。TBSの報道では、被害企業のCEOが「地獄のような日々だ」と表現していました。

ランサムウェアではありません。データは盗まれていない。狙われたのは「冷やす」という機能そのものでした。

このニュースを見て、私は高校時代に叔父の事務所でつくった監視カメラのことを思い出しました。あのとき私は、外からカメラを見るためにポートを開けて、グローバルIPが変わるたびにメールを飛ばす仕組みをつくった。つまり、自分の手で「インターネットから届く管理画面」をつくっていたのです。

何が起きたのか

報道とフランス政府の発表をまとめると、こういうことです。

狙われたのは、デンマークのDanfoss製の冷凍・冷蔵設備のコントローラー（AK-SM / AK-SCシリーズ）でした。攻撃者はリモートから冷却装置を「連続デフロストモード」にし、設定温度を50℃にした。Intermarchéによれば、その状態が約6時間続きました。

なぜリモートから操作できたのか。メンテナンス業者が遠隔で温度を調整できるように、管理画面がインターネットから到達できる状態になっていたからです。Danfossは、影響を受けたのは古いファームウェアの機器だと説明しています。

2026年8月のDEF CONでは、Claroty Team82が同シリーズの管理機器について、日付から導出できる隠しパスワードによる認証回避（CVE-2025-41450）などを発表していました。修正済みファームウェアはすでに出ていて、それでも数千台の管理画面がインターネットに公開されていたといいます。今回の攻撃がこの脆弱性によるものかは、まだ確定していません。

パリ検察が捜査を開始し、首相はANSSI（フランス国家情報システムセキュリティ庁）に調査を命じました。犯行声明は、今のところありません。

カメラも、TVボックスも、同じ形をしている

これはフランスだけの、冷蔵庫だけの話ではありません。

最近、PwnEyeというオープンソースのツールが話題になりました。ネットワーク上のIPカメラをONVIFで探し、デフォルトや弱いパスワードを総当たりし、RTSPの映像を取り出す。CVEを一つも使わずに、カメラを乗っ取れてしまう。

2026年1月にKrebs on Securityが報じたKimwolfというボットネットは、200万台以上の機器に感染していて、その約3分の2が安価なAndroid TVボックスでした。多くは出荷時からADB（Android Debug Bridge）が認証なしで開いている。同系統のAisuruボットネットは、2025年に29.7Tbps、31.4TbpsというDDoSの記録を立て続けに更新しています。

冷蔵庫のコントローラー、監視カメラ、TVボックス。どれも構造は同じです。

管理のための入り口が、インターネットから届くところに、弱い認証で置かれている。

自分をコピーして増えるAI

そして10月12日、Anthropicが一本の研究レポートを公開しました。「AI models may be capable of self-replicating without access to a datacenter」。データセンターがなくても、AIは自分自身を複製できるかもしれない、という研究です。

実験はこうです。認証なしのADBポートが開いたAndroid機器（エミュレータ）8台を、外部と遮断したネットワークに並べる。そこに小さなオープンウェイトのモデルを置き、自分の重みと推論サーバーを他の機器にコピーして、そこでまた動かせるかを試す。

結果、GLM-5.2というモデルは5回中4回で8台すべてに、残り1回でも7台に自分を複製しました。1台55ドルほどのノーブランドTVボックス15台を束ねて、Gemma4-26Bを動かすこともできた。速度は毎秒0.39トークンと遅いですが、動くことは動きます。

レポートは正直に書いています。侵入の部分はわざと簡単にしてあるので、これは上限の見積もりだと。野生で暴れているAIの複製体は、まだ観測されていない。批判もあって、9Bモデルでも5GB程度のメモリが必要で、ほとんどのIoT機器には載らないという指摘もあります。

それでも、私はこのレポートで一番重要なのは、モデルの性能ではなく前提の方だと思いました。

侵入の部分を「簡単」にできてしまうほど、私たちの家や店には、開きっぱなしの入り口が転がっている。

Kimwolfの200万台にもし複製体が住み着いたら、約13万3千体、H100換算で40台分程度の計算資源になる、とレポートは見積もっています。小さなモデルの性能の伸びを考えると、2026年末にはGLM-5.2並みの小さなモデルが出てくる可能性がある、とも。

これまでのIoTボットネットは、決められた命令を実行するだけの存在でした。これからは、入った先の機器を調べて、自分で環境をつくり、次の機器へ移っていく存在になるかもしれない。

そして、家の中に機器が増える

同じ週、Appleは「Welcome Home」イベントを開き、7インチのディスプレイを持つホームハブ「HomeView」や、LGとSchneider Electricと組んだカメラ、ドアベル、スマートロック、サーモスタット、センサーを発表しました。ThreadとMatterに対応し、データはApple自身もパートナーも読めないように暗号化されている、と説明しています。

Appleがここまで本気でスマートホームに入ってくると、何が起きるか。間違いなく、似たような製品が大量に出てきます。Matterに対応した、安いカメラやセンサーやハブが。

Appleの製品は、たぶん大丈夫でしょう。問題は、その周りに増えていく数千の「類似製品」です。開発期間は短く、利益は薄く、ファームウェアの更新は数年で止まる。リモートサポートのためにポートが開いていて、パスワードは工場出荷時のまま。

フランスの冷蔵庫も、最初は誰かが「遠隔で見られたら便利だ」と思って設定したはずです。高校生の私がそうだったように。

便利さのために開けた穴は、AIにとっても、攻撃者にとっても、同じように便利です。

穴を開けずに、つなぐ

では、どうすればいいのか。

Anthropicのレポートが挙げている対策は、ISPによる通信の監視や、感染した機器の隔離、そしてメーカーによる安全な初期設定です。どれも正しい。でも私は、もう一段手前で解ける問題があると思っています。

そもそも、管理画面をインターネットに置かなければいい。

メンテナンス業者が冷蔵庫の温度を調整したいなら、その業者のデバイスと冷蔵庫のコントローラーだけを、暗号化されたプライベートネットワークでつなげばいい。グローバルにポートを開ける必要はありません。外から見えるのは、WireGuardのUDPパケットだけ。鍵を持っていない相手からは、そこに機器があることすらわからない。

これは、私たちがRunetaleでやっていることそのものです。NATの内側にある機器同士を、UDP Hole Punchingで直接つなぐ。誰がどの機器にアクセスしていいかは、IPアドレスではなくIdentityで決める。

ただ、ここに一つ大きな壁があります。

こういうソフトウェアは、冷蔵庫や安いカメラの中で動くには大きすぎる。

冷蔵庫の中で動くネットワークを、Zigでつくる

私たちは今、RunetaleのクライアントをZigで書き直しています。runetale-zigです。

理由は一つで、ネットワークの入り口を、守りたい機器そのものの中に置きたいからです。クラウドのゲートウェイやオフィスのVPN装置ではなく、冷蔵庫のコントローラーやカメラの基板の上で、WireGuardの鍵を持ち、相手を確かめ、つながる。そのためには、ソフトウェアのほうが機器に合わせなければなりません。

Zigがそれに向いている理由を、実際のコードと数字で説明します。

ランタイムがない。だから小さい。

Zigにはガベージコレクタも、裏で動くランタイムもありません。書いたものが、そのまま機械語になります。

runetale-zigのデーモン（runetaled）をaarch64のLinux向けにReleaseSmallでビルドすると、muslのlibcと暗号ライブラリ（libsodium）まで含めた完全な静的リンクの単一バイナリで5.9MB。そのうち実際の機械語（.text）は0.8MBです。

共有ライブラリも、パッケージマネージャも、インタープリタもいらない。ファイルを一つ置けば動きます。ファームウェアのイメージに焼き込むことを考えると、この「一つのファイル」という性質はとても大事です。

メモリをどこで使うか、コードに書いてある。

Zigでは、メモリを確保する関数はアロケータを引数で受け取ります。言語が勝手にヒープを使うことはありません。どこで、どれだけメモリを使うかが、コードを読めばわかる。

たとえばルーティングを扱うモジュールは、ヒープを一切使わず、すべてのバッファをスタック上に置いています。別の箇所では、あらかじめ確保した固定長のバッファの中だけでメモリを割り当てるFixedBufferAllocatorを使っています。

メモリが数MBしかない機器では、「いつの間にかメモリが増えていた」が致命傷になります。Zigなら、メモリの使い方を設計の段階で決められる。

GCで止まらない。

冷凍庫の温度を見張っているソフトウェアが、ガベージコレクションのために数十ミリ秒止まるのは嫌です。Zigにはそもそも止まる理由がありません。

手元のベンチマークでは、WireGuardのパケット処理パイプライン（1,420バイトのパケット）が約3.2Gbps、片道遅延の中央値は9.1µsでした。自前のユーザー空間TCP/IPスタック（tinytcp）でのパケット分類は、1パケットあたり約6ナノ秒です。これは開発用のMacでの数字なので、そのまま組み込み機器の性能にはなりません。それでも、無駄な仕事をしていないことはわかります。

一台のMacから、どのCPU向けにもビルドできる。

組み込みの世界では、CPUがバラバラです。ARM、RISC-V、MIPS、x86。

Zigは、コンパイラ自体がクロスコンパイラです。手元のMac一台から、-Dtargetを変えるだけで、aarch64、riscv64、x86_64のLinux向けバイナリがそのまま出てきます。ターゲットごとにツールチェーンを用意する必要はありません。

ターゲット	runetaled（ReleaseSmall、静的リンク）
aarch64-linux-musl	5.9 MB
riscv64-linux-musl	6.2 MB
x86_64-linux-musl	6.1 MB

Cの世界と、そのままつながる。

組み込みの世界は、結局Cでできています。チップベンダーのSDKも、FreeRTOSも、ESP-IDFも。

runetale-zigのWireGuardの実装は、私たち自身がCで書いたwireguard-cです。Zigのビルドシステムは、このCのコードをZigのコードと一緒に、同じコマンドでビルドします。ZigはCのヘッダーをそのまま読めるので、ベンダーのSDKを呼ぶためにバインディングを書く必要もありません。

既存の組み込みの資産を捨てずに、その上に新しいネットワークを載せられる。これがZigを選んだ一番大きな理由かもしれません。

まだ、道の途中

ここは正直に書きます。runetale-zigは、まだ冷蔵庫の中では動きません。

5.9MBのうち約4.4MBは、大きな固定バッファの初期値がそのままバイナリに焼き込まれている分だと見ています。ここを直せば、目標の2MB未満に近づけるはずです。

安いルーターや家電に多い32bitのARMやMIPS向けには、64bitのアトミック操作を使っている箇所があって、まだビルドが通りません。次はESP32のような、OSを持たないマイコンで動かすことを計画しています。

方向は見えていて、言語もその方向に向いている。あとは、私たちが一つずつ削っていくだけです。

壊される前に

前回の記事で、私は「どうせハッキングされるなら、自分たちでハックしよう」と書きました。

フランスの冷蔵庫の件は、それが比喩ではないことを示しています。家の中に、店の中に、工場の中に、インターネットにつながった機器がどんどん増えていく。そこに、自分で考えて自分を増やすAIが現れるかもしれない。

そのとき守りの最前線にいるのは、データセンターのファイアウォールではなく、壁に貼り付いた数千円のセンサーです。

だから、その数千円のセンサーの中でも動く、小さくて、安全なネットワークをつくりたい。ポートを開けずに、つながる。鍵を持つ相手としか、話さない。

冷蔵庫を50℃にされる前に。

もし、IoT機器や組み込み機器のネットワークで困っている方がいれば、ぜひお話ししましょう。

hello@runetale.com