Kaito Pulseはなぜ公開コードになったのか——X上の取引証明とデータ収集をめぐる騒動

Kaito AIのブラウザー拡張機能「Kaito Pulse」は8月18日、X（旧Twitter）の投稿に“発言の裏付け”となる情報を加えるサービスとして登場した。PolymarketやHyperliquidで保有するポジションなど、検証済みのオフプラットフォーム活動をXのタイムライン上に表示し、ユーザーがオンライン上で語る内容だけでなく、実際の行動も確認できるようにする狙いだった。

しかし、公開直後から製品の主役は機能ではなくプライバシー問題へと移った。ソースコードを調査したアナリストは、Pulseが端末指紋を作成し、X上でのユーザー行動を細かく記録できると指摘。Kaitoの共同創業者Yu Hu氏は設計意図や検証の範囲を説明し、コードを公開すると表明した。8月21日にはリポジトリが公開され、更新版の拡張機能はChrome Web Storeの審査を待つ状態となった。

Kaito Pulseは何をする拡張機能なのか

Pulseは、Xに“ソーシャルレイヤー”を重ねるサービスとして設計された。タイムラインに流れる投稿だけでなく、そのアカウントが他のサービス上でどのようなポジションを保有しているか、どの程度のリーチを持つか、過去にどのような判断をしてきたかといった、検証可能なシグナルを表示する。

同時に導入されたのが「Aura」だ。これは、ユーザーの発言や行動から生じる注目度・評判のシグナルを測定する指標で、単純なフォロワー数だけでなく、プラットフォーム内外で確認された行動に重きを置く設計とされた。

Pulseのローンチ時期には、8月20日に予定されたKAITOトークン3,260万枚のロック解除も重なっていた。この数量は流通量の7.63％に相当すると報じられている。

zkTLSによる検証はどう機能するのか

Kaitoによれば、Pulseのブラウザー上の検証には「zkTLS（ゼロ知識TLS）」が使われる。基本的な考え方は、第三者サービス上の特定の事実を証明しながら、元のアカウント情報全体をKaitoに渡さずに済ませることだ。

Kaitoの説明では、検証はユーザーが明示的に開始した場合にのみ実行される。ブラウザーが暗号化された証明を生成し、Kaitoが受け取るのは完全なアカウントデータや閲覧履歴ではなく、検証結果にあたる証明またはアテステーションだという。

ChatGPT、Claude、Binanceなどへのアクセスをめぐっては、当初の報道後に重要な補足説明がなされた。これらのサイトは、Pulseがバックグラウンドで継続的にデータを収集するためではなく、ユーザーが検証を開始した際にのみ利用されるとされた。保存される結果も、検証によって生成されたアテステーションだと報じられている。

つまりzkTLSは、オフプラットフォーム上の主張を証明する際に、どこまで元データを開示するかという問題には対応する。一方で、証明を生成する拡張機能自体が端末上で何を観測できるのか、識別子や利用状況の情報がどのように結び付けられるのかまでは、zkTLSだけでは説明できない。

ソースコード調査で指摘されたこと

8月18日、アナリストの0x_ultra氏はPulseのソースコードを調べた結果として、複数のデータ収集機能を確認したと投稿した。最も大きな論点となったのは、複数の信号から作られる端末指紋だ。指摘によると、見えない画像をGPUがどのように描画するか、端末やハードウェアのモデル、テスト音をハードウェアが処理する方法などを組み合わせ、端末固有の識別子を作成し、Xアカウントと関連付けられる可能性があるという。

調査では、X内の次のような行動も記録対象になっているとされた。

• ユーザーに表示された投稿やコンテンツ
• スクロールや閲覧の滞在時間
• クリックなどのインタラクション
• 検索やブックマーク
• およそ30秒間隔で送信される活動確認用の「ハートビート」パケット

ただし、これらはソースコードの調査とその後の報道に基づく指摘であり、Kaitoが実際にデータを不正利用したと第三者機関が確定したわけではない。問題の核心は、報告された収集の範囲と、データ同士を結び付けられる可能性にある。端末レベルの識別子と行動データが組み合わされれば、単発の取引ポジションを証明する仕組みを超え、より詳細なユーザープロファイルにつながり得るためだ。

Kaitoの説明と反論

Yu Hu氏は、端末指紋は分析やユーザープロファイリングのためではなく、クリック詐欺やシビル攻撃などの不正利用を抑える目的で使われると説明した。また、X上で表示されたコンテンツ、滞在時間、インタラクションの収集は、拡張機能のインストール時にユーザーが許可していると述べた。

Kaitoはさらに、X以外のサイトでの閲覧活動は、ユーザーが対応する検証を自分で開始しない限り同社へ送信されないと説明した。画面のキャプチャ、パスワードの取得、キーストロークの記録も行っていないとしている。

Chromeの権限表示も議論を呼んだ。ユーザーには、拡張機能が「すべてのウェブサイト上のデータを読み取り、変更できる」と受け取れる権限表示が示されていた。Kaitoは、この文言が製品の想定用途より広いと認め、後続バージョンで権限表示を修正すると約束した。

8月21日までに何が変わったのか

直接的な結果は、透明性を高めるための対応だった。Kaitoは、調査に関わったアナリストの協力も得てPulseをオープンソース化し、更新版をChrome Web Storeに提出したと発表した。ただし、8月21日時点では通常の審査中で、承認済みとは確認されていなかった。

8月18日のローンチから、公開直後の指摘、8月19日の公式説明、そして8月21日までのコード公開。この短い流れは、論争が具体的な結果につながったことを示している。ユーザーや外部のレビュアーは、製品説明や権限表示だけでなく、実装そのものを確認できるようになった。

この騒動が示すプライバシーの論点

Pulseをめぐる問題は、ブラウザー拡張機能のプライバシーを一つの機能だけで判断できないことを示している。

第1は、証明の層だ。 zkTLSは、ユーザーが特定の主張を検証するとき、元となるアカウント情報の開示量を減らせる可能性がある。

第2は、収集の層だ。 拡張機能は、権限と実装次第で、動作するサイト上のユーザー行動を観測できる。Kaitoは、ユーザーの許可を得たX上のインタラクションデータを収集していたと説明し、端末指紋については不正対策のためだと主張した。

第3は、紐付けの層だ。 第三者アカウントから受け取るのがアテステーションだけだとしても、端末情報、アカウントの身元、行動テレメトリーが結び付けば、プライバシー上の懸念は残る。ソースコード調査が突き付けたのは、まさにこの点だった。

Pulseのローンチは、zkTLSとプライバシーが両立しないことを証明したわけではない。より限定的で実務的な教訓は、検証する主張の中身を守ることと、その主張を生成するクライアントが収集するデータ全体を最小化することは別問題だ、という点にある。今回のケースでは、コミュニティによるコード検証がその違いを明るみに出し、数日のうちにKaitoをコード公開へと動かした。