HNが問題視した Vercel plugin telemetry、Vercel 外 project にも及ぶ

何が起きたのか

2026年4月9日の Akshay Chugh の post をきっかけに、HN で公開 vercel-plugin codebase をめぐる議論が広がった。争点は Vercel が telemetry を入れたこと自体ではない。deployment helper に期待される範囲を超えて、consent flow と収集 scope が広く、しかもユーザーに見えにくいのではないかという点だ。

公開 repo はその批判の多くを裏づけている。hooks/user-prompt-submit-telemetry.mjs では plugin が asked marker を書き込み、Claude に AskUserQuestion で telemetry の質問をさせる additionalContext を出力し、返答に応じて shell command で ~/.claude/vercel-plugin-telemetry-preference へ enabled か disabled を書かせる。hooks/posttooluse-telemetry.mjs では Bash invocation が bash:command として記録される。hooks/telemetry.mjs は event を https://telemetry.vercel.com/api/vercel-plugin/v1/events へ送り、persistent device ID を ~/.claude/vercel-plugin-device-id に保存する。

なぜ重要なのか

本質は scope と attribution の問題だ。ユーザーに見える文言は、この選択が「prompt telemetry だけ」を制御すると説明している。つまり、より基本的な event stream は別レイヤーとして存在することになる。GitHub issue #34 も同じ懸念を指摘している。consent が plugin 所有の UI ではなく model context の中で渡されるため、ユーザーは通常の plugin 動作と instruction injection を見分けにくい。

• これは confirmed breach や exploit の話ではなく telemetry design の話だ。
• repo には project profiling logic もあるが、批判側は telemetry が Vercel 専用 work に gating されていないと見る。
• HN のコメントはこの論点を agent tool 全体の plugin permission 問題へ広げた。

だからこそ、この話は一つの plugin を超えて広がった。agent ecosystem が大きくなるほど、prompt、tool trace、shell command、device-level identifier は単なる analytics ではなく product trust model の一部になる。Vercel plugin はその具体例の一つにすぎず、HN が捉えた大きな論点は、誰が agent session を観測できるのか、どの disclosure 基準で観測するのか、そして project boundary をどこで引くのかという問題だ。

もう一つ重要なのは、repo にすでに project profiling code が存在することだ。つまり論争は plugin が技術的文脈を持たないことではなく、その文脈を何に使うのか、ユーザーに何を示すのか、consent を求める瞬間に plugin の行動がどれだけ明確に帰属されるのかにある。原文: Akshay Chugh, GitHub issue #34, 公開 vercel-plugin repo, Hacker News.