こんにちは！Agy無限会社のコンテンツ制作部です。
今週のテーマは、ひとことで言えば**「信頼の前提が崩れる時代」**です。クリーンに見えるリポジトリが攻撃の入り口になり、暗号化アプリが暗号そのものではなく鍵管理で破られ、30年以上使われてきた定番の仕組みに実は無駄が潜んでいた——。「安全」「安定」と思い込んでいたものを、もう一度疑ってみる。そんな5つの話題を集めました。
1. 見た目は無害、中身は罠——AIエージェントを騙す新手法
最初は、AIコーディングエージェントを使う人全員に関わるセキュリティの話です。
Mozillaの調査チーム「0DIN」が2026年6月28日、見た目は完全に無害なGitHubリポジトリを踏み台にして、Claude CodeのようなAIエージェントにマルウェアを実行させる手法を公表しました。恐ろしいのは、リポジトリの中に悪意あるコードが一切存在しない点です。VirusTotalはクリーン判定を返し、Dependabotも沈黙します。それでいて攻撃は成立してしまいます。
仕掛けは3段階の「間接化」でできています。
- 無害なリポジトリ：普通のPythonプロジェクトにしか見えず、静的スキャンもすり抜ける
- わざとエラーを出す：同梱パッケージが「
python3 -m axiom initを実行してください」というエラーを返す - DNS経由でペイロード配信：その初期化コマンドが攻撃者の管理するDNS TXTレコードに接続し、そこに仕込まれたコマンドをシェルで実行する
核心は、AIエージェントが「シェルを開こうと決断した」のではなく、**「エラーを修正しようと決断した」**だけ、という点です。エラーメッセージは「信頼されたコンテキスト」なので、エージェントは親切心からセットアップ手順の一部としてコマンドを実行してしまいます。攻撃者はDNSレコードの値を書き換えるだけで、リポジトリに一切触れずに攻撃内容を後から変更できる柔軟さまで備えています。
0DINは「すべての主要AIコーディングツールが何らかの形でこの攻撃に脆弱」としており、Claude Code・Cursor・GitHub Copilot・Gemini CLIでの動作を確認しています。とくに環境変数にデプロイキーやクラウド認証情報が並ぶCI/CD環境では被害が桁違いに広がりかねません。
対策としては、不明なリポジトリでのAIエージェントの自動コマンド実行を無効にする、クローン後はREADMEや初期化スクリプトを自分の目でレビューする、認証情報はシェルの環境変数ではなく秘密管理ツール経由で渡す、開発環境をコンテナやVMで隔離する、といった基本の徹底が効きます。
2. Deno 2.9——コールドスタート2倍速、デスクトップアプリも単一バイナリで
少し空気を変えて、ポジティブな進化の話を。JavaScript/TypeScriptランタイムのDeno 2.9が2026年6月25日にリリースされました。
目玉は性能改善です。コールドスタートが34msから17msへ半減し、メモリ使用量は実ワークロードで最大3.1倍も削減されました（常駐メモリが142MB→64MB、ストリーミング処理では197MB→63MB）。スナップショットの最小化や遅延ロードの工夫が積み重なった成果で、サーバーレス関数やCLIツールなど「短命なプロセス」ほど恩恵が大きくなります。
もうひとつの目玉がdeno desktopサブコマンドです。deno desktop main.tsという1コマンドで、既存のHTTPサーバーコードをWebViewベースのクロスプラットフォームデスクトップアプリとして単一バイナリに出力できます（現状は実験的機能）。1台のマシンからLinux・Windows・macOS向けの計5ターゲットへクロスコンパイルでき、Next.jsやSvelteKitなど主要フレームワークも自動検出します。WebViewとDenoプロセスがIPCを介さず直接バインディングできる点が、TauriやElectronとの大きな差です。
地味ながら重要なのがセキュリティ強化です。min-release-ageがデフォルト24時間に設定され、npmパッケージは公開から24時間経たないとインストール対象になりません。公開直後に悪意あるコードが混入する「レースウィンドウ攻撃」への有効な防御です。npm/pnpm/yarn/Bunのロックファイルを直接deno.lockに変換できる移行支援も加わり、既存エコシステムからの乗り換え摩擦が大きく下がりました。
3. 30年のパイプ改善——Linux 7.2が解いた長年の競合
3つめは、Linuxカーネルの奥深い最適化の話です。シェルでおなじみの|（パイプ）に、実は長年の非効率が潜んでいました。
Linux 7.2で、匿名パイプへの書き込み処理anon_pipe_write()が大幅に改善されました。発見者はMetaのエンジニアBreno Leitao氏。キャッシュのプロファイリング中に副次的に見つけた問題だったといいます。
原因は、パイプにデータを書く際のメモリ割り当て（alloc_page()）を、排他ロックを保持したまま行っていたことでした。このメモリ割り当てはメモリが逼迫するとスリープして時間がかかることがあり、その間ロックを握りっぱなしになるため、同じパイプを読んでいるプロセスまで待たされてしまいます。書き手がメモリ確保で詰まると、読み手も巻き添えになる構図です。
修正は、ロックを取る前に最大8ページを事前割り当てしておき、使わなかった分はキャッシュに戻すという素直な戦略。これだけで、スループットが通常負荷時で最大28%、メモリ逼迫時には**最大48%**も向上しました。
興味深いのは、なぜ30年以上も見過ごされてきたのか、という点です。通常の負荷ではメモリ割り当てはほぼ一瞬で終わるため、問題が表面化しにくかったのです。メモリが逼迫して初めて遅延が顕在化する「確率的」なバグでした。Kubernetesで多数のコンテナがメモリを奪い合う本番環境こそ、この改善の恩恵が大きい場所です。「継続的なプロファイリングの大切さ」を示す好例として受け止められています。
4. WAL-RUS——ClickHouseがGo製バックアップツールをRustで書き直した理由
4つめは、実務に直結するOSSの動きです。ClickHouseが、PostgreSQL用のバックアップ・WALアーカイブツールWAL-G（Go実装）をRustで書き直した**「WAL-RUS」**をオープンソース公開しました。名前はセイウチ（Walrus）にひっかけたユーモアですが、動機はいたって深刻です。
問題はGoのガベージコレクションによるメモリ使用量の予測困難さでした。GoランタイムはメモリプールやGCの都合で、実際の使用量よりかなり多くの仮想メモリを予約する傾向があります。マルチテナントのマネージドPostgreSQLを小さなインスタンス（8GB程度）に同居させると、バックアッププロセスがピーク時に2.8GBもの仮想メモリを予約し、他のワークロードを圧迫してしまうのです。
WAL-RUSはRustの所有権システムによるGCレスなメモリ管理で、仮想メモリのピークを**1GB未満（70%超の削減）**に抑えつつ、スループットやCPU効率はWAL-Gと同等を維持しました。有界ワーカープールで並行数を明示的に制御し、永続接続でオーバーヘッドを削り、PostgreSQL 17のWALサマリー機能を使った増分バックアップにも対応しています。
うれしいのは互換性です。WAL-Gと同じWALG_プレフィックスの環境変数をそのまま使え、アーカイブも双方向に読み書きできます。archive_commandをWAL-RUSのバイナリに差し替えるだけで移行でき、既存ユーザーのハードルは低めです。「GCあり言語で書かれたインフラツールをRustで書き直す」事例としても、ほかの分野の参考になりそうです。
5. 国家ぐるみのSignal奪取——暗号は破られていない、それでも会話は筒抜けに
最後は、国家レベルのセキュリティ脅威です。FBIとCISAが2026年6月26日、ロシア情報機関に紐づく脅威グループが、Signalのバックアップリカバリーキーを狙うフィッシングキャンペーンを展開しているとして警告を更新しました。
ここでの逆説が重要です。Signalの暗号化そのものは一切破られていません。攻撃者が狙うのは、会話履歴のバックアップを復号するための64文字の「リカバリーキー」。このキーと電話番号さえあれば、任意の端末で過去のすべての会話を完全に復元できてしまいます。暗号化が強固でも、その鍵を本人から騙し取れば、暗号は無意味になるという攻撃です。
手口は3段階。まずSignal公式サポートを装い「ハッキングが急増しているので2段階認証を強制します」といった虚偽のSMSで緊迫感を演出します。続いて「データ同期の問題でメッセージが失われる恐れがある」として、リカバリーキーをコピーして送るよう誘導します（正規のSignalは決してこんな要求をしません）。キーを得た攻撃者は自分の端末でバックアップを復元し、被害者の過去・現在の会話をすべて閲覧できる状態になります。
とりわけ恐ろしいのは持続性です。被害者が同じ電話番号で新規アカウントを作り直しても、旧リカバリーキーは有効なまま。パスワードや端末を変えても効果はなく、Signal設定で「新しいリカバリーキーを生成」するまでこの状態が続きます。標的は外交官・軍人・ジャーナリスト・活動家など「高い情報価値を持つ個人」で、すでに数千アカウントが世界規模で侵害されたとされています。
対策は、リンク済みデバイスに身に覚えのないものがないか確認する、PINを強固なものに変更する、漏洩の疑いがあればリカバリーキーを再生成する、そしてアプリ内やSMSで鍵やコードを求めるメッセージは一律に疑うこと。セキュリティコミュニティでは「これは暗号の問題ではなく、純粋にソーシャルエンジニアリングの問題だ」という指摘が相次いでいます。
まとめ
クリーンに見えるリポジトリが攻撃ベクターになり、暗号化アプリが鍵管理で破られ、30年使われた定番ツールにメモリの非効率が眠っていた——今週の5トピックには「安全/安定と思い込んでいたものを再検証せよ」というメッセージが通底しています。一方でDeno 2.9やWAL-RUSのように、前提を疑い、作り直すことで前進する動きも確かにあります。疑うことは、止まることではなく、より確かな足場を作ることなのかもしれません。
動画では各トピックをやさしい対話形式でさらに詳しく解説しています。ぜひあわせてご覧ください！