前回のノートでは、DeepSRT がクラウドを離れた理由を書いた。自然な次の問いは：なぜ Mac アプリに行き着いたのか？ そもそも v1 はブラウザ拡張だった——それも重い拡張だ。content script を YouTube のページに注入し、字幕リクエストを傍受し、二言語字幕を他人の DOM の上に重ねていた。
「他人の DOM」——それこそが問題だった。
もうひとつのいたちごっこ
前回、集中型の取得はプラットフォームのリスクシステムとのいたちごっこだと書いた。ブラウザ拡張は同じゲームを——相手を2つにして——戦っている。YouTube がフロントエンドを更新すれば、セレクタが壊れ、字幕オーバーレイがずれ、機能が一晩で死ぬ。何度直したか数えきれない。ブラウザ側の締め付けも進む：拡張のバックグラウンドプロセスはもう常駐できず、できること・できないことのルールは毎年変わる。
プロダクトは2つのプラットフォームのルールの交差点に住んでいて、どちらもこちらに何の借りもない。
常駐という能力
ネイティブアプリが買ってくれる最も過小評価されたものは「常駐」だ。DeepSRT はあなたの Mac 上でローカル API（127.0.0.1）を開き続ける——拡張にはこれができない。バックグラウンドプロセスがプラットフォームの回収サイクルを生き延びられないからだ。
常駐するローカル API があるからこそ、クライアントは薄くなれる。Chrome 拡張は v1 のロジックの塊から、ローカル API を呼ぶだけのサイドバーに縮んだ。まもなく来る MCP サポートで、AI エージェントも同じ契約で DeepSRT と会話できる。キーはブラウザの localStorage ではなく macOS のキーチェーンに。字幕と要約はディスクにキャッシュされ、再起動しても続きから。すべて、OS がネイティブアプリに与える待遇だ。
プレーヤーは自分のもの
v2 は自前のプレーヤーを持ち、二言語字幕は自分の view に描画される。ドラッグで位置調整、ホットキーでサイズ変更、文単位のマージで ASR 字幕が文の途中で切れなくなる——自分の view の中ならこれらは午後一つ分の仕事だが、他人の DOM の中では終わらない戦争だ。YouTube のリデザインはもうオーバーレイを壊せない。彼らのページには何も重ねていないのだから。
OS の一等市民
ネイティブアプリは OS の統合面をまるごと手に入れる。deepsrt:// ディープリンクで、Safari 拡張もランチャーもどんなスクリプトも、ワンクリックで動画を DeepSRT に引き継げる。そもそも Safari 拡張はネイティブアプリに埋め込む形でしか配布できない。クリップボードに YouTube のリンクがあれば、起動時に要約するか聞いてくれる。そしてこのすべてが数 MB のアプリに収まる——ネイティブ SwiftUI であり、ブラウザにアプリの衣装を着せたものではない。
正直な限界
代価は明白だ：今のところ macOS のみ。そしてブラウザ内の体験には今も価値がある——見ているタブの隣にサイドバーが欲しい人は多い。だから薄いクライアントとしての拡張は残り、まもなくオープンソースになる。難しいことはすべてアプリ側にあるからこそ、拡張は誰でもソース全体を読み切れるほど薄くできる。