開発者の端末に、いま何が入っているか答えられますか — Aikido Device Protection

管理者が答えられない3つの質問

開発チームを抱える会社の情シスやセキュリティ担当に、次の3つを聞いてみてほしい。

1. 開発者20人の端末に、いまどんなライブラリや拡張機能が入っていますか
2. 今週、誰が何を新しく入れましたか
3. 開発者は、どの AI モデルや MCP サーバ、ツールを使っていますか

たいてい、答えは「分からない」だ。開発者は毎日 npm install や pip install を打ち、VS Code や Chrome に拡張を足す。それは仕事に必要な行為で、いちいち申請させるわけにもいかない。だから管理者は、開発者の端末の中身を把握できないまま、それを前提に運用している。

問題は、この「把握できていない層」が、いまサプライチェーン攻撃の主戦場になっていることだ。悪性コードが仕込まれた npm パッケージは、開発者がインストールした瞬間に端末で動く。CI に届く前、コードレビューの前、脆弱性スキャナが依存関係を読む前である。EDR は主に、端末上で実行されたプロセスや挙動を検知する。一方、これから紹介する Device Protection が見るのはその一段手前、パッケージや拡張機能を取得・インストールしようとする時点だ。Aikido 自身も、EDR を置き換えるのではなく、パッケージ・拡張機能・AI の層を補完する製品だと説明している。

ひとことで言えば、開発者の端末に「何が入っているか」と「何を入れようとしているか」を棚卸しして、危ないものは入る前に止める。

以下、Aikido のデモ環境（22台、Engineering と Devops の2グループ、ユーザー名はすべて架空）を使って、管理者に何が見えるかを追っていく。

ある開発チームの一週間

月曜 — alice がパッケージを入れようとして止められる

alice の MacBook で npm install express を打つと、インストールが止まる。理由は、この組織では npm パッケージに「承認制」の設定がかかっているから。alice は「使わせてほしい」と申請できる。管理者側の Request Inbox に「Alices-MacBook-Pro / Engineering / express」が届く。

alice の express と honey、nina の obolus-sync が承認待ちに並ぶ。管理者はここで通すか止めるかを決める

express は誰もが使う定番なので、管理者はワンクリックで承認する。同じ画面には alice が入れようとした Chrome 拡張「honey」と、Devops の nina が入れようとした「obolus-sync」も並んでいる。後者は聞いたことがない名前だ。承認する前に、少し調べることになる。

火曜 — ethan が VPN ツールを入れようとする

Activity ログに「Install Blocked / free-vpn-proxy / ethan.brooks」が残る。これはマルウェアと判定されたわけではない。組織のポリシーで止まった記録だ。同じ日に quinn の端末で「rustdecimal」が Malware Blocked として止まっている。こちらは既知の悪性パッケージ。

「マルウェア判定で止めた」と「ポリシーで止めた」を分けて数えている。ethan の free-vpn-proxy は後者、quinn の rustdecimal は前者

ログはこの2種類を区別して数えていて、直近30日で「マルウェア判定による遮断 815件、ポリシーによる遮断 2,720件」と出る。同じパッケージを何度も入れようとした回数も含むので、815種類のマルウェアが来たわけではない。それでも、開発者の端末に悪性パッケージが到達しようとした事実は、この数字ではじめて可視化される。

水曜 — 公開されたばかりのバージョンを避ける

ある開発者が、公開されて数時間のバージョンを取得しようとする。この組織では Minimum Age（公開後の最低経過時間）を3日に設定している。

ここで動きが二通りに分かれる。特定バージョンを指定していればブロックされる。一方、npm install xxx のように最新版を要求しただけなら、Aikido は3日以上経過した中で最も新しいバージョンに自動的に切り替えて取得する。

エコシステムごとの設定。Min. Age が「公開後の最低経過時間」。PyPI は全面禁止+承認制、NPM はマルウェア遮断のみと強弱がついている

攻撃者が悪性コードを公開し、誰かが気づいて取り下げられるまでの数時間から数日を狙う攻撃は多い。単純に「新しいものを全部止める」のではなく、開発を止めずに公開直後のリスクだけ避ける仕組みになっている。設定はエコシステムごとに分かれていて、このデモでは PyPI が「全面禁止＋承認制」、NPM は「マルウェア遮断のみ」。「npm は開発に必須だから緩く、PyPI は使う人が限られるから厳しく」という判断を、設定として表現できる。

木曜 — 管理者が AI の使われ方を確認する

AI Usage タブを開くと、22台のうち7台が gpt-5.5、7台が claude-sonnet-4-6、1台が gemini を使っている。会社が契約しているのは Copilot だけのはずだが、個人アカウントで別のモデルに繋いでいる端末がある。

22台のうち7台が gpt-5.5、7台が claude-sonnet-4-6。会社契約の外で使われているモデルがここに出る

さらに Tools の画面を見ると、開発者が AI エージェントに Notion や Linear、Figma を操作させていることが分かる。管理者は Claude から Notion への操作をブロックに切り替える。他は当面、見るだけにする。

Claude から Notion・Linear への操作は Block、Claude Code の12ツールは個別制御。ツール単位で止められる

見えるのは「どのモデル・MCP サーバ・ツールを、どの端末が使ったか」までで、プロンプトの中身や会話の履歴は管理画面には出ない。この点は後述する。

金曜 — 管理者が棚卸しを見る

Packages タブを開くと、22台に入っているパッケージ約1,200件が、名前・バージョン・端末数・初回検出時刻の一覧になる。対象は npm や PyPI だけではない。

デモ環境の Packages 画面。Chrome 拡張、VS Code 拡張、Cursor/Windsurf、Skills.sh まで同じ棚に載る

公式ヘルプが対応対象として挙げているのは、NPM、PyPI、VS Code 拡張、Open VSX（Cursor / Windsurf / Kiro など）、Maven、NuGet、Chrome 拡張、Go、Skills.sh、Ruby、Rust、PHP。デモ環境の画面ではこれに加えて Homebrew、Firefox アドオン、JetBrains の項目も見えたが、ヘルプの一覧にはまだ載っていないので、ここでは画面の観測として記しておく。いずれにせよ、言語のパッケージとエディタやブラウザの拡張が、同じ一覧に載っている。

端末で絞り込むと、alice の1台に Go と npm と Python と Rust のパッケージが混在しているのが見える。

alice の1台に Go・npm・Python・Rust が混在。「この人の端末に何が入っているか」に一覧で答えられる

「alice の端末に何が入っているか」に、はじめて一覧で答えられる。

一週間で見えたもの

この一週間で管理者が得たのは、冒頭の3つの質問への答えだ。

• 何が入っているか → Packages タブの一覧
• 誰が何を入れようとしたか → Activity と Request Inbox
• どの AI をどう使っているか → AI Usage のモデル・MCP サーバ・ツール

そして、開発者の側は何が変わったか。定番パッケージは承認済みなので、日常の開発は変わらない。見慣れないものを入れようとすると止まり、申請すれば通る。公開直後のバージョンは、指定しなければ自動で少し前のものに切り替わる。フラストレーションはゼロではないが、「開発者の端末は管理できないから諦める」という状態からは抜け出せる。

仕組みを少しだけ

公式ヘルプの説明を要約すると、端末に小さなプロキシ（Layer 4）が入り、npm や PyPI などの「パッケージを配っているサイト」への通信だけを見る。それ以外の通信、たとえば普段の Web 閲覧は一切見ない。止めるか通すかの判断は端末の中で行われ、Aikido に送られるのは「何を入れようとして、通ったか止まったか」（即時）と、端末内のパッケージ一覧（SBOM として1日1回）だけ。パッケージの中身や閲覧履歴は送られない。エージェントは10分ごとに生存確認を送るので、管理者は端末がオンラインかどうかを把握できる。

管理者に見えるのは端末・ユーザー・エージェントの版・最終接続。閲覧履歴やパッケージの中身はここに来ない

AI Usage も同じで、プロンプトの中身は端末上で解析され、Aikido に届くのは「どのモデル・MCP サーバ・ツールを、どの端末が使ったか」だけである。だから木曜の管理者に見えたのは「使っている AI」であって、「AI に渡した内容」ではない。

端末上のドメインカテゴリ制御（Firewall タブ）については、先日の記事「On-Device Firewall」で詳しく扱ったのでそちらを参照してほしい。

公式ヘルプが自ら書いている限界も添えておく。これはウイルススキャナではない。すでに端末に入っているマルウェアは見つけない。「入る前に止める」ための製品であって、「入ってしまったものを探す」製品ではない。

入れ方

管理者が Connect Device を押すと、MDM で全端末に配布するか、開発者に手動で入れてもらうかを選ぶ。MDM は macOS / Windows 別に16社の手順が用意されている。

16社の MDM に手順が用意されている。Intune、Jamf、ManageEngine は日本企業でも該当が多い

手動なら macOS / Windows / Linux で、ターミナルに1行貼れば入る。

インストールは1行。User Group はコマンド生成時に選ぶ（トークン部分はマスク）

Linux は開発者のデスクトップだけでなく、CI/CD ランナーやビルド環境、開発用の Linux 環境にも展開できる。公式には CI のビルドジョブ、Dev Container、cloud-init、Terraform、Ansible などへの展開手順が用意されている。

Linux は Desktop / Server / CI/CD の3用途。開発者の手元だけでなく、ビルドを行うマシンにも同じ目が届く

対応 OS は Ubuntu、Debian、RHEL、Rocky、Alma、Oracle Linux、CentOS Stream、Fedora。要件はカーネル 5.11 以上に加えて BTF、cgroup v2、systemd。なお Aikido は、サーバ上の脆弱なパッケージを調べるのは VM Scanning の役割だと線引きしており、Device Protection はあくまで「開発者が作業するマシン」を守る製品である。この点は別途、EC2 で実際に入れて確認する予定でいる。

最後に

「開発者の端末は管理できない」は、多くの会社で暗黙の前提になってきた。開発者の自由を守るためというより、把握する手段がなかったからだ。Device Protection がやることは地味で、端末に何が入っているか、何を入れようとしているかを一覧にし、危ないものを入る前に止める、それだけである。だがその「それだけ」が、いままで誰も答えられなかった3つの質問に、事実で答えられるようにする。

---

参考: Aikido 公式ヘルプ「What is Device Protection」「How Does Device Protection Work?」「Install Device Protection for Linux」。画面はすべて Aikido のデモ環境で、ユーザー名・端末名は架空のもの。