DeepSRT v1 のアーキテクチャ図を見た人は当然こう聞く。「クラウドのバックエンドと、YouTube の字幕を取得するローテーションプロキシの一群——立派なサービスがあったのに、なぜ v2 はすべて捨てて Mac アプリにしたのか？」
短い答え：ユーザー自身の IP は、どんなプロキシ群よりも優れたインフラだから。長い答えは以下。
いたちごっこ
v1 は「ユーザーの代わりに YouTube のデータを取得する」サービスの常道だった。リクエストは我々のサーバーに入り、サーバーが YouTube から字幕を取得して返す。問題は、YouTube がデータセンター IP に対して構造的に厳しいことだ。1つの IP が千人にサービスすれば、そのリクエストパターンはボットそのものになる。ブロックは事故ではなく定常状態だ。
そこでプロキシプールを作る。プロキシもブロックされるので、ヘルスチェック、ローテーション、ベンダー乗り換えが必要になる。我々のバックエンドのコードの半分はパイプを維持するためだけに存在していた——プロダクトではなく配管だ。ワークアラウンドの層を重ねるたびに、プラットフォームのリスクシステムといたちごっこをする。そして猫は常にこちらより大きい。
集中型の取得は、全ユーザーに同じ運命を共有させる。1つの出口 IP がスロットリングされれば全員が同時に壊れる。信頼性の上限は「最もボットに見えた瞬間」で決まる。
取得をユーザーの手に返す
v2 はパイプラインを逆転させた。アプリはあなたの Mac 上で、あなたの自宅 IP から、一人の人間の視聴量で、YouTube の公開字幕エンドポイントと直接やりとりする。YouTube から見れば、あなたはあなたのまま——動画を見ている一人の人間であり、プロキシプールではない。リスク管理の問題は解決されたのではなく、アーキテクチャによって消滅した。
AI 要約も同じだ。あなた自身の Google Gemini キー（BYOK）が macOS のキーチェーンに保存され、アプリが直接 Gemini API を呼ぶ。何を見て何が要約されたかは、第三者のサーバーを一切経由しない——我々のサーバーも含めて。存在しないのだから。
プライバシーは普通、ポリシーの一段落だ：「あなたのデータは見ないと約束します」。DeepSRT のそれはアーキテクチャの性質だ：見ようにも、見る場所がない。
コストの誠実さ
サーバー代がなければ、転嫁すべき固定費もなく、インフラを養うためのサブスクリプションも要らない。アプリ代は一度きり。AI は Gemini の無料枠がほとんどの人の視聴量を余裕でカバーする。我々は中間でマージンを取らないし、将来の API 値上げでこっそりプランを変える必要もない。
正直な限界
BYOK には実際のハードルがある。Gemini キーを自分で取得する必要がある（無料だが、一手間ではある）。それが「サーバーゼロ」の代価だ。価値はあると考えているが、摩擦ゼロではない。
ローカル取得も無敵ではない。開発中に自分たちで踏んだ：短時間に字幕リクエストを打ちすぎれば、誰でも YouTube の 429 を食らう。違いは対処に必要なものだ——一人分の量なら、キャッシュ（メモリ＋ディスク）、リクエストの統合、バックオフ付きリトライでほぼ起きない事象にできる。集中型では、これは永遠に消えない火事だ。
そして：今のところ macOS のみ。このアーキテクチャの代価は「あなたのマシン」に縛られることだ——マシンがなければ、DeepSRT もない。
扉に鍵はかかっていない
アプリはローカル API（127.0.0.1）を内蔵し、Chrome 拡張はその上の薄いクライアントだ——ロジックはすべてアプリ側にある。この軽量拡張はまもなくオープンソースになる。プライベート MCP サポートも準備中で、あなたの AI エージェントが DeepSRT と直接会話できるようになる。
アーキテクチャ上、クライアントを増やすことを妨げるものは何もない。サーバーがないことは閉じていることを意味しない——むしろ逆だ。すべてがあなたのマシンで動くからこそ、すべてがあなたのツールから使える。
ひとつ補足：常駐するローカル API はネイティブアプリにしかできない芸当だ——ブラウザ拡張のバックグラウンドプロセスは、プラットフォームの都合でいつでも回収される。なぜ DeepSRT が Mac アプリに行き着いたのかは次のノートで。