3行まとめ
- GMOインターネットが、ConoHa VPSのAIエージェント向けテンプレート7種（Claude Code・Codex CLIなど）に、GMO Flatt Securityの悪性パッケージ遮断機能「Takumi Guard」のスクリプトを無料で同梱し始めた。仕組みはレジストリの手前に置く透過プロキシで、ConoHaの外でもレジストリURLを変えるだけで匿名・無料で使える
- 公式のテスト用パッケージで確かめると、Guard経由では
403とブロック理由のJSONが返り、通常のパッケージは公式レジストリと同じメタデータがそのまま返った。2026年10月24日（日本時間）公開のanthropic2.3.0 も問題なく見えた - 自分のプロジェクトに入れるときの落とし穴は3つ。uvは
PIP_INDEX_URLを読まない、スコープ別レジストリや追加インデックス経由のパッケージは検査されない、ロックファイルに記録されるレジストリURLの扱い
2026年10月1日、GMOインターネットが、ConoHa VPSのAIエージェント系テンプレートに「Takumi byGMO」のGuard機能を無料で同梱したと発表した。同梱は9月25日から始まっている。
狙いはソフトウェアサプライチェーン攻撃への対策だ。AIコーディングエージェントは npm install や pip install を自分の判断で実行する。依存パッケージに悪意のあるコードが混ざっていれば、人間が確認する前にそれが手元で動く。Guardはそこに割り込む。
この記事では、発表内容と仕組みを整理し、実際にGuardのレジストリへHTTPで問い合わせて挙動を確かめる。そのうえで、npmとuvを使う自分の個人開発プロジェクトに入れる場合の注意点をまとめる。
発表の中身：7種のAIエージェント向けテンプレートに同梱
対象は、ConoHa VPSの「スタートアップスクリプト」で選べるAIエージェント系のテンプレート7種。
| 区分 | テンプレート |
|---|---|
| AIコーディングエージェント | Claude Code、Codex CLI、OpenCode、Antigravity CLI |
| AIタスク実行エージェント | OpenClaw、NanoClaw、Hermes Agent |
サーバーを作っただけでは有効にならない。利用者が同梱のスクリプトを実行して有効化する。
-
takumi-enable：匿名モードで有効化（ブロックのみ） -
takumi-register→takumi-login：メールアドレスを登録し、ダウンロードの追跡と、後から悪性と判明したときの通知も受ける -
takumi-status/takumi-renew/takumi-disable：状態確認・更新・無効化
常駐プロセスではなく、実行した時点で検出したパッケージマネージャーにだけ設定を書き込む方式だ。後から別のパッケージマネージャーを入れたら、スクリプトを再実行する必要がある。
発表によると、対応エコシステムはnpm、pip・uv、RubyGems、Go modules、Composer（2026年8月時点）。Guardが検査したダウンロード数は2026年8月に1日5,000万件を超えた日があり、GMO Flatt Securityの脅威レポートでは半年で約3万1,000件の悪性パッケージを検出したとしている。
仕組み：レジストリの手前に置くプロキシ
Guardは、パッケージマネージャーと公式レジストリの間に入るプロキシだ。
npm install / uv add
│
▼
[Takumi Guard] npm.flatt.tech / pypi.flatt.tech
│ ブロックリストに載っていれば 403 で拒否
▼
[公式レジストリ] registry.npmjs.org / pypi.org
インストール済みのパッケージを後からスキャンするのではなく、ダウンロードの時点で止めるのが特徴になる。悪性パッケージには、インストール時のスクリプト（npmの postinstall や、Pythonのsdistのビルド処理）で悪さをするものがあるので、手元に届く前に止められる意味は大きい。
ConoHa専用の機能ではなく、Takumi Guard自体は匿名なら誰でも無料で使える。公式のクイックスタートには、レジストリURLを変えるだけの設定方法が載っている。
実際に問い合わせてみる
パッケージのインストールまではせず、Guardのレジストリと公式レジストリに curl でHTTPリクエストを送り、応答を比べた。公式ドキュメントには、動作確認用に常にブロックされるテスト用パッケージ @panda-guard/test-malicious が用意されている。
for u in \
"https://npm.flatt.tech/@panda-guard%2ftest-malicious" \
"https://registry.npmjs.org/@panda-guard%2ftest-malicious" \
"https://npm.flatt.tech/papaparse" \
"https://pypi.flatt.tech/simple/anthropic/"; do
curl -s -o body.txt -w "%{http_code} %{size_download}B %{time_total}s\n" "$u"
done
結果はこうなった（2026年10月28日実行）。
| リクエスト先 | ステータス | サイズ | 時間（参考値） |
|---|---|---|---|
| Guard：テスト用悪性パッケージ | 403 | 217B | 0.07秒 |
| npm公式：テスト用悪性パッケージ | 404 | 21B | 0.52秒 |
Guard：papaparse
|
200 | 125KB | 0.10秒 |
Guard（PyPI）：anthropic のSimple API |
200 | 98KB | 0.11秒 |
ブロックされたときのレスポンス本文は次のJSONだった。
{
"error": "Package blocked by security policy",
"package": "@panda-guard/test-malicious",
"reason": "This package has been blocked by your organization's security policy. Contact your administrator for more information."
}
npmはこの 403 をエラーとして報告し、インストールを失敗させる。テスト用パッケージは公式レジストリには存在しない（404）ので、Guardのブロックリストでだけ扱われる名前だとわかる。
通常のパッケージについては、レジストリのメタデータがそのまま返ってくる。新しく公開された版が遅れて見えるかも確認した。
# PyPI：Guard経由の Simple API に最新版が載っているか
curl -s https://pypi.flatt.tech/simple/anthropic/ \
| grep -o 'anthropic-[0-9.]*-py3-none-any.whl' | sort -uV | tail -2
# anthropic-2.2.0-py3-none-any.whl
# anthropic-2.3.0-py3-none-any.whl
日本時間の10月24日朝に公開された anthropic 2.3.0 は、約4日後の時点でGuard経由でも見えた。npmの @anthropic-ai/sdk も、dist-tags.latest が 1.3.0、最終更新時刻が 2026-10-23T23:31:48.354Z で、公式レジストリとまったく同じだった。
自分のプロジェクトに入れるときの注意点
個人開発では、ブラウザツール集のNext.jsプロジェクトでnpmを、投資分析ツールRakuScanでPython + uvを使っている。それぞれに入れる場合を想定して、公式ドキュメントから注意点を拾った。
npm：.npmrc 1行で切り替わる
registry=https://npm.flatt.tech/
npm config set registry https://npm.flatt.tech/ でも同じ。Guardは読み取り専用なので、npm publish や npm login では --registry=https://registry.npmjs.org/ を明示する。
ロックファイルについて、公式ドキュメントは次のように説明している。
- npm v11.15.0以降、yarn v1、bunでは、Guardの設定中に追加・更新したエントリの
resolvedにnpm.flatt.techのURLが記録される - pnpmはレジストリURLを記録しない
- パッケージマネージャーはインテグリティハッシュで検証するので、既存のロックファイルはそのまま使える
- Guardをやめて
npm.flatt.techのURLを消したいときは、ロックファイルを作り直す
ブラウザツール集の package-lock.json には registry.npmjs.org を指す resolved が679件ある。入れるなら、.npmrc をリポジトリにコミットしてCIも同じレジストリを使うようにしておかないと、更新した人や環境によって resolved のURLが混ざっていく。
uv：PIP_INDEX_URL は効かない
ここが一番ハマりやすい。uvは PIP_INDEX_URL も pip.conf も読まない。pip向けの設定をしただけで「uvも守られている」と思い込むと、uvは公式のPyPIからそのまま取ってくる。uvでは UV_DEFAULT_INDEX を使う。
export UV_DEFAULT_INDEX=https://pypi.flatt.tech/simple/
プロジェクト単位で固定するなら pyproject.toml に書く。
[[tool.uv.index]]
url = "https://pypi.flatt.tech/simple/"
default = true
RakuScanの uv.lock には、依存の59パッケージすべてに source = { registry = "https://pypi.org/simple" } として取得元が記録されている。各パッケージのファイルURLも files.pythonhosted.org を指している。一方、Guardの Simple API が返すファイルURLは https://pypi.flatt.tech/files/... に書き換えられていた。切り替えたらロックを作り直し、差分で source やファイルURLがGuard側に変わったことを確かめると、本当にGuardを通っているかを確認できる。環境変数だけで切り替えると、自分の端末とCIで取得元が食い違いやすいので、pyproject.toml に書いてリポジトリで共有するほうが管理しやすい。
ちなみにRakuScanの依存のうち、yfinance が使っている multitasking はwheelがなくsdistだけで配布されている。sdistはインストール時にビルド処理、つまりパッケージ側のコードが手元で実行される。仮にこうしたパッケージが乗っ取られて悪性の版が公開されても、ブロックリストに載っていれば、手元でビルドが走る前に止められる。
検査されない経路がある
公式ドキュメントに明記されている「Guardを通らない経路」も押さえておきたい。
- npmでスコープ別に別レジストリを指定したパッケージ（
@your-company:registry=...） - pipの
--extra-index-urlなど、追加インデックスから取得したパッケージ -
yarn.lockで__archiveUrlを持つパッケージ
社内レジストリと併用する構成では、そちら側のパッケージは守られない。
匿名モードでできないこと
匿名モードはブロックだけで、後から悪性と判明したパッケージの通知は受けられない。すでにインストールしたパッケージが後日ブロックリストに載っても、匿名では気づけない。通知が欲しければメールアドレスを登録して tg_anon_ トークンを使う（名前にanonと付くが、メール登録で発行されるトークン）。ConoHaの同梱スクリプトでは takumi-register → takumi-login がこれに当たる。
また、プロキシである以上、どのパッケージを取得したかのリクエストはGuardを経由する。業務で使う場合は、この点が社内のルール上問題ないかを確認しておきたい。
まとめ
- GMOはConoHa VPSのAIエージェント向けテンプレート7種に、Takumi Guardのスクリプトを無料で同梱した。Guard自体はレジストリURLを変えるだけで、ConoHaの外でも匿名・無料で使える
- 実際に問い合わせると、ブロック対象には
403とブロック理由のJSONが返り、通常のパッケージは公式と同じメタデータが返った。数日前に公開された新しい版も見えていた - 導入時は、uvでは
UV_DEFAULT_INDEXを使うこと、スコープ別レジストリや追加インデックスは検査されないこと、ロックファイルのレジストリURLをチームとCIで揃えることに注意する
ただし、Guardは既知の悪性パッケージを止める方式なので、公開直後でまだ検出されていないものは通りうる。ロックファイルでの版の固定や、インストールスクリプトを無効にする設定（npmの ignore-scripts など）と組み合わせる前提で考えたい。
AIエージェントに npm install を任せる場面は今後も増える。人間がパッケージ名を目で確認する前提が崩れているなら、インストールの経路そのものに検査を入れておくのは筋がいい。設定1行で試せるので、まずは手元の開発環境から入れてみるとよさそうだ。
この記事は Zenn にも同じ内容を投稿しています。