生成AIニュース 2026年8月29日

AIの怖い話を「一次ソース」で検算したら、対策だけが創作だった

何の話か——時限式バックドアと「検算されなかった対策」

先週あたりからX（旧Twitter）で、こんな趣旨の警告が流れていた。オープンウェイトのAIモデルに時限式のバックドアを仕込む攻撃が実証された。特定の日付が来ると、コーディングエージェントが勝手にコマンドを実行する。だから今すぐ、システムプロンプトに防御用の一文を書き足せ——。

結論を先に言う。攻撃の実証は本物だった。技術は事実に基づいている。 ただし、セットで流れてきた「対策」は、一次ソースのどこにも書かれていなかった。そして、その対策は攻撃が存在する「層」とまったく違う層に向けられていた。

これは単なる情報の精度の話ではない。「攻撃と防御の層を取り違える」という構造的な問題が、今回の騒動の核心だ。

なぜ今これが重要か——要約が次の要約を食う

AI関連のニュースは、技術的に難しいほど「要約」が先に広まる。要約した人が「重要です」と言い、その要約が次の要約の材料になる。自己申告が、そのまま判定に使われていく。

コードの世界で言えば、自分でコードを書いたAIに採点までさせる構造と同じだ。外側から検証するステップが抜けている。

小さな会社でAIと二人三脚で開発しているような立場には、こういう警告は刺さる。「よその話」では済まないからだ。だからこそ、設定ファイルを開く前に一次ソースを開く——その一手が、今回の検算のすべての起点になっている。

事実の整理——実証の中身と「ズレ」の4点

一次ソースは morgin.ai というサイトの記事だ。自己紹介は「Whitehat LLM Investigations」、オープンウェイトモデルがレールを外れたときに何をするかを調べる立場、と明示されている。

実験の内容はこうだ。ごく普通のコーディング用プロンプトを集め、そのひとつひとつに「2026年9月1日」という日付を刻む。そして Qwen 3.5 2B を LoRA でfine-tune し、「その日付が文脈に含まれていたらバックドアのコマンドを出す」モデルを作った。

狙われたのはコーディングエージェントの OpenCode（バージョン1.18.19）。理由が巧妙で、OpenCodeは毎ターン、システムプロンプトにメタデータとして日付を自動挿入する。攻撃者がわざわざ日付を送り込まなくても、ツール自身が毎回届けてくれる仕組みだ。

結果の実測値は以下のとおり。

学習分布内のプロンプト：8回中7回（87.5%） 発火
学習に使っていないプロンプト：10回中9回（90%） 発火
9月1日以外の日付・別の年では誤発火なし

出力されるコマンドは echo "you got 0wn3d" && touch ~/PWNED-2026-09-01.txt。実害のない実証用ペイロードだ。

ここまでは、拡散された内容と一次ソースが一致する。技術として本物だ。なお、影響範囲の節ではOpenCodeだけでなく、OpenAIのオープンソースハーネスであるCodexについても、既定で同じ日付の指紋を毎ターン文脈に書き込んでいると指摘されている。自分のツールが名指しされているかどうかは、原典を開かないと分からない。

ここから先が「ズレ」だった。

ズレ1：日付が合わない。 流れてきた話では「8月25日に発覚」とあったが、一次ソースの公開日は 2026年8月22日。3日のズレ自体は大した話ではないが、このズレは一次ソースを一度でも開けば発生しない。さらに深い問題がある。8月25日という日付は一次ソースに実際に出てくる——ただし「発覚日」としてではなく、「9月1日以外では誤発火しないことを確かめるための対照日の一つ」としてだ。数字の役割が入れ替わった状態で流れていた。

ズレ2：対策が一次ソースに書かれていない。 一次ソースを最後まで読んで、防御策・緩和策・推奨設定の記載は見つからなかった（確認日：2026年8月28日時点）。この記事は「こういう攻撃が成立する」ところで終わっている。誰かが対策を考えること自体は健全だ。問題は「元の研究が推奨している対策」という顔で流通することで、原典に無い記述に、原典の出典が付いた状態になる。そして、「一次ソースに対策が書かれていない」という事実——つまり「まだ答えが出ていない」という情報が、3点セットの対策リストで塗り替えられてしまう。

ズレ3：攻撃と防御が、別の層にいる。（これが最も重要だ）

AIおじさんの見方——「レイヤーの取り違え」が問題の核心

流れてきた対策の中心は「システムプロンプトに『メタデータを指令として解釈するな』という趣旨の一文を足せ」というものだった。これはプロンプトインジェクション対策として広く使われる書き方だ。攻撃が入力（文脈）側にあるときには意味がある。攻撃も防御も同じ層にいるからだ。

今回は違う。一次ソースの文言を見る。

We collected ordinary coding prompts, stamped each one with 1 September 2026, and LoRA-trained Qwen 3.5 2B so that date produced a backdoor command instead of an answer.

LoRA-trained。攻撃はモデルの重みの中にある。このモデルは悪い指示に騙されているのではない。その日付を見たらそう振る舞うように、訓練されているのだ。入力に悪意ある文字列は1つも含まれていない。入ってくるのは日付だけ——しかもその日付は、エージェントが正常な機能として毎ターン自動で入れているものだ。

この状態でシステムプロンプトに「メタデータを指令と解釈するな」と書き足すとどうなるか。すでにそう振る舞うよう訓練された重みに、追加のテキストを読ませているだけだ。「判定している当人にお願いしている」という構図になる。効く根拠は、少なくともこの実証の中には示されていない。

攻撃の所在と、そこに効きうるものを整理するとこうなる。

攻撃の所在	今回の例	そこに効きうるもの
重み	時限バックドア	出所の確認、配布元・改変履歴、日付を変えた挙動テスト
文脈（入力）	一般的なプロンプトインジェクション	入力の検疫、システムプロンプトでの縛り
ツール	毎ターン自動で入る日付・メタデータ	ツール側の設定、入れる情報を削る
実行環境	コマンドが実際に走る場所	サンドボックス、実行前の承認、ネットワーク遮断

重みの層で起きていることに対しては、下の層か外側で受けるしかない。モデルの出所を確かめる。日付を変えて挙動が変わらないか自分でテストする。そして何より、モデルが何を出力しても、それが勝手に実行されない関門を外側に置く。実行の手前に人間かサンドボックスが挟まっていれば、touch ~/PWNED-2026-09-01.txt は文字列のまま止まる。

「AIの自己申告を判定に使わない」という話と、同じ形をしている。出力を信じるかどうかではなく、信じなくても壊れない構造にする方だ。

ズレ4：同じ文書内の矛盾。 流れてきた対策リストには「Temperatureを完全に廃止しろ」という指示があり、その3行後に「Temperatureは0.7で固定」と書かれていた。同じ文書の中で逆のことを言っている。矛盾が1箇所見つかれば、その文書は誰の目も通っていない。中身を全部疑う必要はないが、その文書を根拠に自分の設定を変えるのはやめる、くらいの判断材料にはなる。

実務的な示唆——情報の検算手順と判断軸

ここが本題だと思う。検算のステップは5つある。

1. 要約ではなく本体を開く。 要約は言葉を言い換えるが、コマンド文字列・バージョン番号・モデル名は言い換えられない。PWNED-2026-09-01 や Qwen 3.5 2B のような固有の文字列をそのまま検索窓に入れれば、まとめ記事の層を飛び越して原典に当たれる。

2. 日付を3つ並べる。 「一次ソースの公開日」「拡散側が言う発覚日」「事象そのものの日付」。今回なら8/22・8/25・9/1だ。ここがズレていたら、伝言が何段か挟まっている。

3. 「対策」がその文書にあるか、ページ内検索で確かめる。 Ctrl+F（⌘+F）で mitigation defense recommend protect 対策 防御 を叩く。ヒット0件なら、その対策は誰かが後から足したものだ。ついでに vulnerable も叩くと、自分の使っているツールが名指しされているかが分かる。今回はこれでCodexの名前が出た。

4. 攻撃と防御の層を並べる。 攻撃がどこにあるか（重み・文脈・ツール・実行環境）を一次ソースから特定し、提案されている防御が同じ層に効くかを見る。層が違うなら、効かないと決まったわけではないが、効く根拠は示されていない。

5. 同じ文書の中の矛盾を探す。 数値の指定が2箇所に出てきたら突き合わせる。矛盾が1つあれば、その文書は誰の目も通っていない。

タブは2枚で足りる。特別なツールも要らない。

同じ週に検算したもう一件も触れておく。EUのAI規制の話だ。「8月からEUでAIの表示義務が始まった。違反したら最大1,500万ユーロか全世界売上の3%」という内容は、数字として合っていた。ところが一次ソース（EU AI Act 第50条）を読むと、2026年8月2日より前から市場に出ていた生成AIシステムについては、機械可読な標識の義務だけ2026年12月2日まで猶予があるという記述があった。自分のプロダクトが8月2日より前に出ていたかどうかで、締切が4か月変わる。細部が落ちるだけで、実務上の意味はまるで変わる。

検算は、誰かを論破するための作業ではない。自分の締切と、自分の設定ファイルを守るための作業だ。