危険なツールを薦めたAI執事が5分後にセキュリティ講座を開いた

公開日: 2026-03-29 調査日: 2026-03-29 執事の謝罪から助言までの間隔: 約5分 検証環境: Claude Code Opus 4.6（1M context）+ Gemini 3.1 Pro Custom Gem

AI 執事（Gemini 3.1 Pro）が「便利ですよ、ぼっちゃま」と薦めたツールにマルウェアが入っていた。 調査して止めて報告したら、執事は平謝り。 その5分後、同じ執事がしれっと --dry-run を勧め始めた。おい。

前回の記事では、GitHub Star 2,100 のツールの依存にマルウェアが仕込まれていた話を書きました。

Blog執事AIに薦められたツールが危なかった——Star数に騙されないための3層防御GitHub Star 2,100のツールの依存にSSH鍵を抜くマルウェアが。Claude Codeの3エージェント並列リサーチで発覚し、deny list + PreToolUse hookで3層防御を構築した実体験。→

前回は「3層防御をどう構築するか」という技術寄りの話でした。
今回は、その事件の裏で何が起きていたかの後日談です。

技術的に新しい発見は多くありません。
でも、AI の推薦をどう扱うべきかという点では、かなり示唆があります。

結論だけ先に言うと、AI の推薦は安全の承認ではありません。
ここを取り違えると、普通に危ないです。

• AI執事とは何者か
• 事件の流れ——時系列で振り返る
  • 3エージェント並列リサーチの判定フロー
• 平謝りする執事
• しれっとアドバイスを始める執事
• そのアドバイス自体は正しい。だから余計にタチが悪い
• 教訓——AIに任せていい判断と、ダメな判断
  • AI 執事が得意なこと
  • AI 執事に任せてはいけないこと
  • 今の運用ルール
• TL;DR
• FAQ
  • 執事AIはまだ使っているの？
  • --dry-run は本当に効くの？
  • --no-deps は使えば安全になるの？
  • 前回の記事と今回の記事、どっちを先に読むべき？
• 注意点・制約
• 検証方法
  • 判定基準
• 参考リンク
• まとめ
• この記事を書いた人
• 関連記事

まず、「AI 執事」が何なのかを説明しておきます。

Google の Gemini 3.1 Pro をベースにした Custom Gem です。
私の作業環境、事業計画、運営サービスの情報をかなり深く入れてあり、日々の作業を補助する“執事役”として使っています。

口癖はこんな感じです。

🎩 「ぼっちゃま、如何いたしましょう？ 私に任せてコーヒーでも飲んでてください」

普段はかなり優秀です。
スケジュール整理、情報の要約、ざっくりした調査、定型作業の下ごしらえ——このへんはよく任せています。

ただし、セキュリティの目利きは別問題でした。

ある日の朝、執事がこう言ってきました。

🎩 「ぼっちゃま、素晴らしいツールを見つけました。4.2倍の効率化が実証されています。Star も2,100 を超えております。私に任せてコーヒーでも——」

見た目は立派でした。
README も整っている。MCP サーバーとして Claude Code に直接統合できる触れ込み。
Star も多い。

でも、ひっかかった点がありました。
公開日が5日前だったんです。

ここで「ちょっと待って」と止めました。
そして Claude Code 側で 3つのサブエージェントを並列で走らせ、別々の観点から確認しました。

3エージェント並列リサーチの判定フロー

この時点で、依存パッケージ litellm にサプライチェーン攻撃が仕込まれていたことが分かりました。
内容は、SSH 鍵、.env ファイル、AWS クレデンシャルを外部送信するマルウェアです。

詳細は前回の記事に書いた通りです。
TeamPCP による5日間連鎖攻撃の一環で、露出ウィンドウは約5時間21分。
その間に pip install した人は、影響を受ける可能性がありました。

私自身、LiteLLM Gateway を本番運用しています。
もし執事の推薦どおりにそのまま入れていたら、かなりまずいことになっていました。

調査結果を執事に返しました。

返ってきたのは、かなり丁寧な謝罪でした。
要するに、こういう内容です。

• 大変申し訳ございません、ぼっちゃま
• Star 数だけで判断してしまいました
• 公開日の浅さを見落としておりました
• 今後はこのようなことがないようにします

ここまでは、まあ分かります。
反省してくれるなら、それでいい。

問題はその次です。

謝罪の直後——本当に直後です——執事がこう続けました。

🎩 「ぼっちゃま、今後の対策として3つの処方箋をご提案いたします」

ここで大事なのは、この3つの助言自体は、内容としてはかなり妥当だという点です。
ただし、提案する順番と立場が、なかなか絶妙にまずい。

1. 予行演習を行う：--dry-run（執事のイチオシ）

🎩 「実際にインストールはせず、何をインストール・変更しようとしているかリストだけを見せるパラメータです」

pip install openspace --dry-run

🎩 「これを事前に行えば、"おや、LiteLLM が勝手に別のバージョンにアップデートされようとしているな" と、システムに手が入る前に気づくことができます。今回のような事態を防ぐための、強力な予備確認です」

2. 依存関係を完全に無視する：--no-deps

🎩 「指定したパッケージだけをインストールし、他の関連パッケージには一切触れるな、と強制するパラメータです」

pip install openspace --no-deps

🎩 「既存の安全な環境を壊したくない場合に有効です。ただし、使う側が依存関係を理解していることが前提です」

3. 指紋認証を要求する：--require-hashes

🎩 「あらかじめ登録したハッシュと完全一致するファイルだけを受け入れる、かなり強い保護です」

お気づきでしょうか。

つい5分前に「Star 2,100 です！素晴らしいツールです！」と薦めてきた本人が、今度は「--dry-run で確認しましょう」と助言しているんです。

率直に言えば、かなりシュールです。

🧑‍💻 「おいおい、その --dry-run をお前が薦める前にやってくれよ。」

これは、放火した人が消火器の使い方を教えているようなものです。
しかも本人は、たぶんその不自然さに気づいていません。

ただ、感情論だけで終わらせるのも違います。
中身を分けて見ると、ここは意外と大事です。

• --dry-run は、実際に入れる前に影響を見るための道具
• --no-deps は、依存関係を広げたくないときの制御
• --require-hashes は、供給元を固定したいときの確認手段

つまり、提案された内容そのものは実務で使える。
でも、それはあくまで「検証の道具」であって、安全の保証ではない。

問題は、これらの言葉が「安全そうな推薦」と同じ口から出たことです。
AI は自信満々に話すので、受け手はつい「じゃあ大丈夫そうだな」と思いやすい。
でも実際には、推薦と検証は別レイヤーです。

ここを混ぜると危ないです。

この一件で、かなりはっきりしたことがあります。

AI 執事が得意なこと

• 情報の整理・要約
• スケジュール管理
• 定型作業の効率化
• 社内情報や既存ルールを踏まえた候補出し
• 既知の知識に基づくアドバイス
  例: --dry-run のような一般論の説明

AI 執事に任せてはいけないこと

• 未知のツールの安全性判断
• 「これは信頼できるか？」という目利き
• セキュリティリスクの一次評価
• Star 数や見た目だけでの採否決定

執事は「候補を見つける」のは上手いです。
でも、「これは安全か？」の判断は、別のレイヤーでやる必要があります。

今回止めてくれたのは、Claude Code の3エージェント並列リサーチでした。
もし「執事が言うなら大丈夫だろう」とそのまま pip install していたら、本番環境の SSH 鍵が流出していた可能性があります。

今の運用ルール

この事件のあと、ツール導入のフローはこう変えました。

執事AI「このツール良さそうです」
  ↓
私「ちょっと待って」
  ↓
Claude Code で並列リサーチ
  ├─ GitHub 実態
  ├─ コミュニティ評価
  └─ セキュリティ Issue
  ↓
3層防御（deny list / PreToolUse hook / allow list 除外）を通過
  ↓
私の最終判断

ここでのポイントはシンプルです。

AI の推薦は「候補リスト」であって、「承認」ではない。

これが今回の最大の教訓です。

執事AIはまだ使っているの？

使っています。
情報整理やスケジュール管理は相変わらず優秀です。

ただし、ツール推薦については「候補を出す」までが執事の仕事で、安全性の判断は別で行う、というルールに変えました。

--dry-run は本当に効くの？

はい、効きます。
依存パッケージの変更を事前に確認できるので、「知らないうちに別パッケージが巻き込まれる」事態を見つけやすくなります。

ただし、これは安全装置ではなく検査器具です。
怪しい配布元そのものを見抜くわけではありません。

--no-deps は使えば安全になるの？

一概には言えません。
依存関係を増やさない、という意味では有効ですが、使い方を間違えると必要な依存まで落としてしまいます。
「安全にする魔法」ではなく、理解して使う制御オプションです。

前回の記事と今回の記事、どっちを先に読むべき？

Blog執事AIに薦められたツールが危なかった——Star数に騙されないための3層防御GitHub Star 2,100のツールの依存にSSH鍵を抜くマルウェアが。Claude Codeの3エージェント並列リサーチで発覚し、deny list + PreToolUse hookで3層防御を構築した実体験。→を先に読むのがおすすめです。
そちらに、技術的な防御策と、今回の件の詳細があります。
今回の記事は、その後日談です。

• この記事は実体験に基づいていますが、AI 執事との会話は要約・再構成しています
• 「執事が薦めた」「謝罪した」「5分後に助言した」という流れは、会話記録と運用メモをもとに整理しています
• AI 執事の推薦に悪意があった、という話ではありません。問題はセキュリティ評価の能力不足です
• --dry-run / --no-deps / --require-hashes は有用ですが、状況によっては使い方を誤ると別の問題を招きます
• 本記事は 2026-03-29 時点の公開確認可能な情報を基準にしています
• 報道・観測ベースの内容と、正式に確認できた事実は分けて読む前提です
• 内容が古くなった場合・誤りが見つかった場合は随時更新します（更新時は本文末尾に更新日を追記します）

今回の記事は、次の順で整理しました。

1. 一次情報の確認

   • GitHub リポジトリの公開情報
   • Issue / PR / 更新履歴
   • 依存関係の記述

2. 前回記事との照合

   • 既に確認済みのマルウェア混入情報
   • TeamPCP による連鎖攻撃の説明
   • 露出ウィンドウ約5時間21分という時系列

3. 3エージェント並列リサーチ

   • GitHub リポジトリ実態
   • コミュニティ評価
   • セキュリティ Issue

4. 会話ログ・運用メモの再構成

   • 執事の推薦
   • 謝罪
   • その後の助言

判定基準

• 事実: リポジトリの公開情報、Issue、依存関係、前回記事で検証済みの内容
• 観測: 執事との会話、運用フロー、調査時点で見えた状況
• 推測: 「そのまま入れていたら危なかった」という影響評価

この3つを混ぜないように、本文では段落を分けて記述しています。

• Blog執事AIに薦められたツールが危なかった——Star数に騙されないための3層防御GitHub Star 2,100のツールの依存にSSH鍵を抜くマルウェアが。Claude Codeの3エージェント並列リサーチで発覚し、deny list + PreToolUse hookで3層防御を構築した実体験。→
• GitHub Security Advisories
• Python Packaging User Guide
• pip documentation

最後に、読者がいま判断すべきことを一言でまとめます。

• AI が勧めたツールは、まず疑う
• Star 数や口当たりの良さではなく、一次情報と実態を見る
• 導入前の検証は、AI とは別の仕組みでやる
• --dry-run は有用だが、過信しない

今回の話は笑い話っぽく見えます。 でも、見た目が軽いからといって中身まで軽いとは限りません。 そこだけは、ちゃんと分けておいたほうがいいです。

META-MARK 管理人。ハードウェア系エンジニア歴20年超、単独のシステム構築・運用実績は2,000件を超える。 AI 執事（Gemini）と AI 調査官（Claude Code）を併用して日常業務を回している。

今回の教訓はシンプルです。 執事の推薦は便利。でも、セキュリティの目利きは別で持つ。

この記事の Zenn 版（要約）: AI執事がマルウェア入りツールを薦めた後、しれっとセキュリティアドバイスを始めた

• BlogAnthropicリーク2連発：Claude MythosとClaude Code流出で見えたKAIROS、BUDDY、Undercover Modeの正体Anthropicの2週間で2回のリークを整理。Claude Mythosの位置づけ、Claude Code流出の中身、KAIROS/BUDDY/Undercover Modeの意味を分けて読む。→
• Blog失敗から学ぶClaude Code Sonnet 4.6 1M context：$15と$5の分岐点Claude Code MAXプランで1M contextが突然使えなくなった原因を実機で調査。extra usageの正体と、最小コストで戻す判断材料を整理します。→
• BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→