押し込むことと、引き寄せること
同じ機能なのに、データの流れる方向が正反対だった
Obsidianプラグインを作ることにした。
Obsidianは知識管理アプリだ。YouTubeを学習に使う人のかなりの割合がObsidianでノートを管理している。StackTubeの分析結果をObsidianに自動で入れられれば、その人たちにとって強力な接点になる。
ところがここで奇妙な点があった。
StackTubeにはすでにObsidian出力機能があった。分析が終わるとマークダウンファイルをObsidianフォルダに入れてくれる機能。最初に作るときからあった。なのになぜまたプラグインを作らなければならないのか?
管制塔にこの質問を投げた。既存機能があるのになぜプラグインが必要なのか。
返ってきた答えが興味深かった。「方向が逆だからです。」
説明を聞いてようやく理解した。
既存のObsidian出力機能は、サーバーがユーザーのObsidianフォルダにファイルを直接書き込む方式だった。設定にフォルダのパスを入れると、サーバーがそのパスにマークダウンを保存する。サーバーがフォルダにファイルを押し込む(push)。
これはV2の時代——つまりプログラムが自分のPCで動いていた時代——には完璧に動作した。サーバーがすなわち自分のPCだったから。自分のPCが自分のフォルダにファイルを書くのは当然だ。
しかしSaaSになって状況が変わった。今やサーバーはクラウドに乗っている。自分のPCではない。そしてクラウドにあるサーバーは、ユーザーのPCのフォルダに手を出せない。当然だ。もし任意のサーバーが自分のPCのフォルダにファイルを書けるなら、それは深刻なセキュリティ問題だろう。
つまり「サーバーがユーザーのフォルダに押し込む」方式は、SaaSでは根本的に不可能だった。既存機能がローカルでは動いたが、クラウドでは塞がれていたのだ。
ここで方向を逆にしなければならなかった。
サーバーがフォルダに押し込め(push)ないなら、フォルダの側からサーバーへ引き寄せれ(pull)ばいい。ユーザーのObsidianの中で動くプラグインが、StackTubeサーバーのAPIに接続して分析結果を取ってくるのだ。サーバーはユーザーのPCを知らないが、ユーザーのPCの中のプラグインはサーバーのアドレスを知ることができるから。
押し込むことから、引き寄せることへ。pushからpullへ。
この方向の違いが最初は些細に見えた。どうせマークダウンファイルがObsidianフォルダに入るという結果は同じだから。しかし結果が同じでも構造はまったく違った。
押し込む構造ではサーバーが能動的だ。サーバーが「いつ、どこに」ファイルを書くかを決める。引き寄せる構造ではプラグインが能動的だ。プラグインが「いつ、何を」取ってくるかを決める。サーバーはただ「取っていけるように開けておく」役割だけをする。
この気づきはEP.02を思い出させた。あのときはV2をSaaSに拡張しようとして構造的欠陥を6つ見つけた。「一人で使うときは問題ないが、複数人で使うと破綻する」問題たち。今回のpush/pull問題もまさにその系列だった。ローカルでは動くが、ホスティングされると塞がれる。
ただし今回は違った。EP.02のときは管制塔が問題を指摘してくれた。今回は自分が先に「なぜ既存機能があるのにプラグインが必要なんだ?」という質問を投げた。答えを知らなくて聞いたのではなく、何かおかしいという感覚が先に来た。構造を読む感覚が少し育ったのだ。EP.06で「構造を読む言語」を学んだが、今やその言語で自分から質問を作れるようになった。
プラグインの実際の構造は単純だった。サーバー側にはAPIの窓口を一つ追加すればよかった。「この時刻以降の新しい分析結果をマークダウンで返して」というリクエストを受ける窓口。マークダウンを作る仕事(価値の核心)はサーバーがすでにやっているので、それを開けておくだけでいい。
プラグイン側は薄い運搬役だった。APIから新しいノートを取ってきて、ファイル名を整え、Obsidianフォルダに保存する。重複は動画IDで弾く。30分ごとに自動で確認するか、手動で「今すぐ取得」を押せる。
核心は「価値を作る部分」と「運搬する部分」を分離したことだった。サーバーは分析という価値を作り、プラグインはそれを運ぶ。それぞれ得意なことだけをする。
この分離を理解すると、今後他のツールと連携するときも同じ原理が使えると思った。Notionだろうが、他のアプリだろうが、「サーバーが押し込めないなら、クライアントが引き寄せる」という原則。データの流れる方向をまず決めて、それから構造を組む。
作ることより方向を決めることが先だ。方向が間違っていれば、いくらうまく作っても動かない。これはコードの問題ではなく設計の問題であり、設計はコードが分からない人でも——いや、むしろコードが分からない人の方が——うまく判断できる領域だ。
押し込めないなら、引き寄せる。単純な原理一つを知るのに、ずいぶん遠回りをしてきた。
こうしてプラグインの構造は決まった。しかし作ることと世に出すことは、また別の問題だった。このプラグインを人々に使ってもらうには、Obsidianという他人の村に店を出さなければならなかった。それは次の話だ。
🔧 このエピソードの技術用語解説
Push vs Pull データをやり取りする二つの方向。Pushは送る側が能動的に押し込むこと。Pullは受け取る側が能動的に引き寄せること。同じデータ移動でも誰が主導するかが異なり、この違いがシステム構造を決める。
API窓口（API Endpoint） 外部からデータを要求できるアドレス。プラグインがこのアドレスにリクエストを送ると、サーバーが該当データを返す。このエピソードでは「新しいノートをマークダウンで返す」窓口を一つ新しく開けた。
クライアント（Client） サーバーにリクエストを送る側。ここではObsidianの中で動くプラグインがクライアントだ。「薄いクライアント」とは、複雑な処理はサーバーに任せ、自分は最小限の運搬役だけをする軽量なプログラムを指す。
ポーリング（Polling） クライアントが一定周期でサーバーに「新しいものある?」と繰り返し尋ねる方式。プラグインが30分ごとにサーバーを確認するのがポーリングだ。サーバーが先に知らせる方式(push)の反対。
関心の分離（Separation of Concerns） 異なる役割をそれぞれ別の部分に担わせる設計原則。サーバーは「価値生成」、プラグインは「運搬」だけを担う。それぞれが一つの仕事だけをすれば、全体が単純で頑丈になる。