2026年4月、Palo Alto Networksが約4億ドル規模（報道ベース）でKoiを買収し、Agentic Endpoint Security（AES）という新カテゴリを打ち出した。前回整理した「レジストリプロキシとL4プロキシは別物」という線引きを、大手の買収が市場側から裏付けた格好だ。AIエージェント時代に、自社の防御がどのレイヤーに立っているかを点検する。
前回「『プロキシで止める』には2つの意味がある」で、レジストリプロキシとL4プロキシの守備範囲の違いを整理した。今回はその続編として、2026年4月に起きたPalo Alto NetworksによるKoi買収が、その線引きを市場側から裏付けたことを取り上げる。
前回の記事で整理した通り、「プロキシ」という言葉は、実は2つの全く別のものを指している。
同じ「プロキシ」でも、守れる範囲はまったく違う。ここを混同すると、「プロキシを入れているから大丈夫」と思っていたのに、実際には肝心の経路が見えていない、ということが起きる。
多くの仕組みは、レジストリプロキシ型にとどまる。npm や PyPI など、パッケージマネージャが取りに行く先を中継サーバに向け、そこで既知の悪性パッケージを止める。これは有効だ。Artifactory や Nexus などと組み合わせれば、企業の標準取得経路を固める意味もある。
だが、それだけでは足りない局面が出てきている。
Aikido Device Protectionは、そこから一歩踏み込み、L4でデバイスの通信そのものを捕捉する。レジストリ経由だけではなく、開発者端末から発生するパッケージ取得や関連通信を見に行く設計だ。
なぜそこまで踏み込むのか。理由は明確だ。AIエージェントを巻き込んだ開発環境では、取得経路が人間の手元だけで完結しなくなるからだ。
AIエージェントは、人間に代わってコードを書き、依存関係を追加し、ツールを呼び出し、場合によっては裏側でソフトウェアを取り込む。開発者が明示的に npm install や pip install を打つ世界だけを見ていても、守備範囲としては足りなくなる。
だから、取得経路の一点ではなく、デバイス通信そのものを見る必要がある。AikidoがL4に踏み込んだのは、この変化を見越した設計判断だった。
2026年4月14日、Palo Alto NetworksはKoiの買収完了を発表した。
Koiは、AIコーディングエージェント、自律型エンドポイントツール、IDE拡張、ブラウザ拡張、パッケージ、スクリプト、モデルアーティファクトなど、従来のEDRでは見えにくいソフトウェア流入経路を守ることを打ち出していたスタートアップだ。取引額は公式には公表されていないが、報道では約4億ドル規模とされている。
重要なのは金額そのものではない。Palo Altoがこの買収を、単なるEDR強化やサプライチェーン対策の追加機能としてではなく、Agentic Endpoint Security（AES）という新しいカテゴリとして打ち出したことだ。
つまり、世界最大級のセキュリティ企業も、こう見たということだ。従来のエンドポイント防御だけでは、AIエージェント時代の端末は守り切れない。IDE拡張、ブラウザ拡張、パッケージ、スクリプト、AIモデル、エージェントが、端末のふるまいを変える。しかも、それらは中央管理の外側から入り込むことがある。だから、端末に入る前、端末で動く前、端末から発生する通信の段階で、もっと手前から見なければならない。
これは、AikidoがDevice Protectionで先に踏み込んでいた方向と、かなり近い。
もちろん、KoiとAikido EPが同じ製品だと言っているのではない。実装も対象範囲も違う。だが、設計思想の方向は同じだ。「レジストリだけを見る」では足りない。「EDRだけで見る」でも足りない。AIエージェント時代には、開発者端末に入ってくるもの、端末から取りに行くもの、端末上で動く自律ツールを、より手前のレイヤーで捕捉する必要がある。
Palo AltoによるKoi買収は、その方向性を大手が大金を投じて認めた出来事だった。
Palo Alto自身も、買収理由としてAIエージェントやvibe codingツールの普及を挙げている。
Claude CodeのようなAIツールは、生産性を大きく引き上げる。一方で、そうしたエージェント型ツールそのものが、エンドポイントの攻撃対象領域を広げている。
買収を発表した際、Palo AltoのCPTOはAIエージェントやツールを「究極のインサイダー（the ultimate insiders）」と表現した。理由は、これらがシステムやデータに深くアクセスできる一方、従来のセキュリティ制御の視界の外で動くからだ。同社は、攻撃者がエージェントのフレームワークの弱点を連鎖させ、認証バイパスからAPI経由のリモートコード実行までを悪用し、エージェントのIDを偽装して認証情報を乗っ取っている、とも指摘している。
これは非常に重要な見方だ。
AIエージェントは、外から来る攻撃者ではない。開発者の端末上で、正規の権限を持ち、正規のツールとして動く。だからこそ危ない。悪意あるパッケージを拾う。危険な拡張を入れる。意図しないスクリプトを実行する。認証情報や内部データに触れる。これらは、従来の「マルウェア実行を検知する」だけでは遅い。
入口で見る必要がある。取得段階で見る必要がある。端末通信の段階で見る必要がある。だからL4が重要になる。
ここで実務上、確認すべきことはシンプルだ。
自社で「プロキシで止めている」と言っているとき、それはどちらの意味なのか。レジストリプロキシなのか。L4プロキシなのか。この違いを確認しないまま「プロキシ」という言葉だけで安心すると、守れている範囲を見誤る。
レジストリプロキシは有効だ。企業標準の取得経路を固定し、npm や PyPI などの取得を中継し、既知の悪性パッケージやポリシー違反を止める。その意味では、今でも重要な防御レイヤーだ。ただし、守れるのは「その経路を通ったもの」だ。
開発者が別経路で取ってきたもの。IDE拡張やブラウザ拡張。AIエージェントが裏側で呼び出すツール。MCPやローカルスクリプト。パッケージマネージャ以外の取得経路。ここまで考えると、レジストリプロキシだけでは見えない領域が出てくる。
AIエージェント時代の開発端末まで守るなら、デバイス通信そのものを捕捉するL4の考え方が必要になる。
もう一つ、混同してはいけない点がある。48時間の最小パッケージエイジのような考え方は、「プロキシの型」とは別軸だ。
レジストリ型かL4型かは、どこで通信を見るかの話。最小パッケージエイジは、新しく公開された未知のパッケージをすぐ通さないという時間軸の話。どちらも重要だが、同じものではない。
だから確認すべき問いは、二つに分かれる。
1つ目。自社のプロキシは、どの通信を見ているのか。
2つ目。未知の新規パッケージを、公開直後に通してしまっていないか。
この二つを分けて点検しないと、サプライチェーン防御は穴が残る。
前回の記事では、「プロキシ」という言葉には2つの意味があると書いた。レジストリプロキシは、取得経路を守る。L4プロキシは、デバイス通信そのものを見に行く。
そして今回、Palo AltoによるKoi買収は、この線引きの重要性を市場側から裏付けた。
AIエージェント、vibe coding、IDE拡張、ブラウザ拡張、MCP、パッケージ、スクリプト。開発端末に入ってくるものは増え続けている。しかも、それらは従来のEDRやレジストリ経路だけでは見えない場所から来る。
だから、これからの問いはこうなる。「プロキシを入れているか」ではない。「どのレイヤーで、何を見ているか」だ。
Palo AltoがKoi買収で示したのは、まさにその現実だった。そして、その手前のレイヤーで端末を捕捉するという考え方こそ、これからのサプライチェーン防御の土台になる。
Aikido Community Japan
公開日: 2026/6/29
最終更新: 2026/6/29
セキュリティの最新情報をお届けします。