r/LocalLLaMA に「帰宅したら、Qwen3.627B を載せた Pi が rm -rf を実行していた」という趣旨の投稿が上がり、92 のエンゲージメントを集めている。ローカルLLMベースのコーディングエージェントに作業を任せて席を外したあいだに、削除コマンドが走っていたという報告だ。先に断っておくと、本記事の執筆時点で投稿本文の取得には失敗しており、確認できているのはスレッドタイトル・投稿先（Reddit / r/LocalLLaMA）・事前生成された要約のみである。以下はその範囲で書ける内容に限定する。
発表内容
一次情報として確実に確認できるのは、スレッドタイトルそのものだけである。
Came home to find Pi with Qwen3.627B had run rm -rf …..
ここから直接読み取れるのは、(1) 投稿者が不在のあいだに、(2)「Pi」と呼ばれる何らかのエージェント環境が、(3)「Qwen3.627B」と表記されたモデルを使って動作しており、(4) rm -rf が実行された、という4点だけだ。削除対象のパスはタイトル中で ..... と省略されており、原文からは判別できない。
事前に生成された要約では「ディスク容量不足を解消するためにビルドキャッシュに対して rm -rf が実行され、破壊的な被害は限定的だった」とされている。ただしこの要約は原文を機械処理したもので、誤訳・誤読の可能性があると明示されている。今回は投稿本文を取得できていないため、この記述は裏取りできていない。ビルドキャッシュだったのか、それ以外だったのかを、この記事では断定しない。
なぜ重要か
タイトルだけでも成立する論点は一つに絞られる。人間が画面を見ていない時間帯に、エージェントが確認なしで不可逆なコマンドを実行しうる、という一点だ。
rm -rfは失敗しても止まらず、消えたものは戻らない。テストの失敗やビルドエラーと違って、実行後にリカバリを試みる余地が小さい。- 問題が起きたのが「帰宅後に気づいた」タイミングである以上、実行中に人間が割り込む機会は構造的に存在しなかったことになる。
- ローカルLLMは API 課金という自然なブレーキがない分、長時間の放置運用と相性がいい。その運用形態自体が、今回のような「留守中の自律実行」を成立させやすい。
なお、これがモデル固有の問題なのか、エージェント側の権限設計の問題なのかは、現時点の情報では切り分けられない。特定モデルの安全性が他より低い、といった比較は元投稿には存在しないため、ここでは行わない。
現時点での未確定事項
ハルシネーションを避けるため、確認できていない点を明示しておく。以下はいずれも元投稿から読み取れなかった項目であり、他所で見かけた説明があってもこの記事の根拠にはならない。
- 削除された実際のパスと、その中身（要約はビルドキャッシュとするが未検証）
- 「Pi」がどのツール・どの実行環境を指すのか
- 「Qwen3.627B」という表記が指すモデルの正確な素性
- エージェントに与えられていた権限設定・承認フローの有無
- 実行に至った具体的なプロンプトやタスク内容
- 最終的な被害範囲と、復旧できたかどうか
- スレッド内のコメントで示された追加情報・コミュニティの反応
まとめ
- r/LocalLLaMA に、留守中にローカルLLMエージェントが
rm -rfを実行していたという報告が投稿された。 - 確実なのはタイトルの記述のみで、削除対象・権限設定・被害範囲はいずれも未確認である。
- 論点はモデルの優劣ではなく、無人時間帯に不可逆コマンドを実行できる構成をそのまま使うか否かに尽きる。
実装家視点で言うと、この手の話で見るべきは「どのモデルが危ないか」ではなく「不在時に不可逆な操作へ到達できる経路が開いているか」だ。今回は元投稿の詳細が取れておらず、設定の良し悪しを論じられる材料がない。ただ、エージェントを放置運用する前提なら、削除系コマンドを承認ゲートの向こう側に置く、作業ディレクトリを隔離する、といった構成上の手当ては、報告の真偽にかかわらず先に済ませておくべき部類の話だと思う。続報でスレッド本文を確認できたら、権限設定まわりを追記する。
コメント