事例紹介2026年3月29日by K.hirano

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

AIの推薦を安全承認と勘違いすると危ない。実体験の後日談から、推薦・検証・判断を分ける運用とdry-runの使い方を整理します。

#case-study#AI#security#supply-chain#Claude Code#Gemini

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

この記事を3行で

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執事とは何者か

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

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

口癖はこんな感じです。

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

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

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

事件の流れ——時系列で振り返る

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

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

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

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

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

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

エージェント	観点	判定基準	結果
#1	GitHub リポジトリ実態	テスト、PR、更新頻度、コミットの中身	テスト0件・PR 1件のみ
#2	コミュニティ評価	独立レビュー、外部言及、導入事例の有無	独立レビューゼロ
#3	セキュリティ Issue	既知の脆弱性、報告済み Issue、依存関係の警戒情報	Critical 1件 — litellm にマルウェア

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

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

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

平謝りする執事

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

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

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

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

問題はその次です。

しれっとアドバイスを始める執事

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

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

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

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

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

bash

pip install openspace --dry-run

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

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

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

bash

pip install openspace --no-deps

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

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

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

そのアドバイス自体は正しい。だから余計にタチが悪い

お気づきでしょうか。

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

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

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

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

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

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

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

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

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

教訓——AIに任せていい判断と、ダメな判断

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

AI 執事が得意なこと

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

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

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

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

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

今の運用ルール

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

text

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

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

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

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

今回の出来事の整理

項目	内容
AI執事	Gemini 3.1 Pro ベースの Custom Gem（事業情報を深く投入）
やらかし	Star 2,100 のツールを安全確認なしに推薦
発見者	Claude Code の3エージェント並列リサーチ
執事の反応	平謝り → 約5分後にセキュリティ助言を開始
核心	`--dry-run` の助言は正しい。タイミングが最悪だった
判断	AI の推薦 ≠ 安全の承認。検証は別レイヤーで行う

FAQ

執事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 時点の公開確認可能な情報を基準にしています
報道・観測ベースの内容と、正式に確認できた事実は分けて読む前提です
内容が古くなった場合・誤りが見つかった場合は随時更新します（更新時は本文末尾に更新日を追記します）

検証方法

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

一次情報の確認
- GitHub リポジトリの公開情報
- Issue / PR / 更新履歴
- 依存関係の記述
前回記事との照合
- 既に確認済みのマルウェア混入情報
- TeamPCP による連鎖攻撃の説明
- 露出ウィンドウ約5時間21分という時系列
3エージェント並列リサーチ
- GitHub リポジトリ実態
- コミュニティ評価
- セキュリティ Issue
会話ログ・運用メモの再構成
- 執事の推薦
- 謝罪
- その後の助言

判定基準

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

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

参考リンク

まとめ

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

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

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

この記事を書いた人

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！