君のてのひらから

WSL2のObsidian VaultにWindowsブラウザからクリップしたい：プロトコルブリッジ構築とSFTPマウントでの実装

ObsidianWindowsWSL

パーマリンク

WSL2内のObsidian Vaultに、Windows側のブラウザからクリップしたい

私は日常のナレッジベースとしてObsidianを活用しており、これまでObsidian本体をWSL2（Ubuntu 24.04）内にネイティブLinuxアプリ（.deb）としてインストールし、WSLg経由でWindowsデスクトップに描画させる構成で運用していました。保管庫（Vault）の実体もWSL2のLinuxファイルシステム上に配置しています。

この環境において、Windows上のブラウザに入れたObsidian公式Web Clipper拡張からWebページを保存しようとしたところ、ボタンを押しても一切反応しない現象に遭遇しました。 （まあ、うまく動かないだろうとは思っていましたが…）

原因は明確で、「Webページを収集するブラウザはWindows側」「ノートを保持・管理するObsidian VaultはWSL2側」というOSの境界を跨いでいる点にあります。

本記事では、このクロスOS環境でWeb Clipperを動かすために試行錯誤した2つのアーキテクチャ（プロトコルブリッジの自作 ➔ rclone SFTPマウントへの転換）をまとめます。

※本記事に記載のバージョン情報や動作仕様は、執筆時点（2026年8月）のものです。

【アプローチ1】プロトコルブリッジによるクロスOS連携

1-1. 検証：Local REST APIプラグイン（検証結果：ClipperはAPIに対応していない）

最初に検討したのは、ネットワーク層（HTTP）でOS間を繋ぐアプローチです。ObsidianをHTTPサーバー化するコミュニティプラグイン Local REST API（coddingtonbear/obsidian-local-rest-api v5.1.0）を導入しました。

[!TIP] WSL2のポートフォワーディング仕様 WSL2がデフォルトのNATモードである場合、WSL2内でバインドされたポートはWindows側の localhost へ自動的にポートフォワーディングされます。実際、Windowsブラウザから https://localhost:27124 にアクセスすることで、WSL2内のLocal REST APIサーバーへ通信が到達することを確認できました。

しかし、Web Clipper拡張の設定画面を確認したところ、REST APIの接続先URLやAPIキーを入力する項目は存在しませんでした。

そこで Web Clipper公式リポジトリ（obsidianmd/obsidian-clipper）のソースコード（src/utils/obsidian-note-creator.ts）を解読した結果、ノート保存処理は obsidian://new?... というカスタムURLスキームの呼び出しに一元化されていることが判明しました。

つまり、Web ClipperはHTTP通信ではなく、OSのプロトコルハンドラーを介してObsidianを起動する設計となっていたため、Local REST APIによる解決策は撤去（プラグイン無効化・関連ファイルおよび設定の完全削除）しました。

1-2. Web Clipperの動作確認

Web Clipperが obsidian:// プロトコルに依存していることが確定したため、OSごとのプロトコル処理構造を調査しました。

  • WSL2（Ubuntu）側: .deb パッケージのインストール時に update-desktop-database によって x-scheme-handler/obsidian が登録され、/opt/Obsidian/obsidian %U にマッピングされています。
  • Windows側: Windows版Obsidianをインストールしていないため、obsidian:// プロトコルを処理するレジストリハンドラーが存在しません。

そのため、Windowsブラウザが obsidian:// を発行しても、Windows OS側で未定義のスキームとして遮断されていました。

sequenceDiagram
    autonumber
    participant B as "Windows Browser (Web Clipper)"
    participant Win as "Windows OS (Registry)"
    participant WSL as "WSL2 (Ubuntu 24.04)"
    participant Obs as "Obsidian (.deb)"

    B->>Win: obsidian://new?... を呼び出し
    Note over Win: プロトコルハンドラー未登録
    Win--x B: 処理不可（ここで停止）
    Note over WSL,Obs: WSL2内のハンドラーまで到達しない

1-3. ブリッジの設計と実装

解法として、「Windows側で obsidian:// を受諾し、そのまま wsl.exe を通じてWSL2内の xdg-open に引き渡すブリッジ」を構築しました。

sequenceDiagram
    autonumber
    participant B as "Windows Browser"
    participant Reg as "HKCU Registry"
    participant Cmd as "obsidian-wsl-bridge.cmd"
    participant WSL as "wsl.exe (Ubuntu-24.04)"
    participant XDG as "xdg-open"
    participant Obs as "Obsidian Linux (.deb)"

    B->>Reg: obsidian://new?... 呼出
    Reg->>Cmd: .cmd を引数付きで実行
    Cmd->>WSL: wsl.exe -d Ubuntu-24.04 -- xdg-open "%~1"
    WSL->>XDG: xdg-open "obsidian://..."
    XDG->>Obs: /opt/Obsidian/obsidian にルーティング

手順1：ブリッジ用バッチスクリプトの作成

C:\Users\<username>\AppData\Local\obsidian-wsl-bridge.cmd として以下を配置します。

@echo off
"C:\Windows\system32\wsl.exe" -d Ubuntu-24.04 -- xdg-open "%~1"

手順2：Windowsレジストリ（HKCU）への登録

管理者権限不要で、ユーザー単位で安全に着脱できるよう HKEY_CURRENT_USER に登録します。以下の .reg ファイルを作成して実行します。

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\obsidian]
@="URL:Obsidian Protocol"
"URL Protocol"=""

[HKEY_CURRENT_USER\Software\Classes\obsidian\shell]

[HKEY_CURRENT_USER\Software\Classes\obsidian\shell\open]

[HKEY_CURRENT_USER\Software\Classes\obsidian\shell\open\command]
@="\"C:\\\\Users\\\\<username>\\\\AppData\\\\Local\\\\obsidian-wsl-bridge.cmd\" \"%1\""

[!WARNING] HKCU登録を推薦する理由 HKEY_LOCAL_MACHINE (HKLM) 変更時のシステム全体への波及やアンインストール残価リスクを避けるため、HKEY_CURRENT_USER (HKCU) に閉じて登録しています。不要になった場合は HKCU\Software\Classes\obsidian レジストリキーを削除するだけで即座に元通りになります。

1-4. 単体テストと切り分け

Web Clipper経由のテスト前に、Windowsの「ファイル名を指定して実行」（Win + R）から直接プロトコルを起動して動作を検証しました。

obsidian://open?vault=<Vault名>

上記を入力して実行した結果、WSL2側で動作していたObsidianウィンドウがフォアグラウンドにアクティブ化され、カスタムURLスキームが正常に開通したことを確認しました。その後、Web Clipperから実際にクリップを試し、WSL2内のVaultへ正常にノートが保存されることを実証しました。

[!TIP] 不具合発生時の切り分けフロー

  1. wsl -l -v でディストロ名を確認し、バッチファイル内の指定（-d Ubuntu-24.04）と一致しているかチェック。
  2. コマンドプロンプトから obsidian-wsl-bridge.cmd "obsidian://open?vault=..." を手動実行し、バッチ自体の動作を確認。
  3. regedit で HKCU\Software\Classes\obsidian\shell\open\command のパス文字列が正しいか確認。

【アプローチ2】描画バグの発生とアーキテクチャの再設計

さて、通信課題は解決しましたが、日常運用の中で新たな不便を感じる事態となりました。

2-1. WSLgに起因する描画崩れとクラッシュ

WSL2内のObsidian（.deb）をWSLg経由でウィンドウ表示・最大化させた際、ウィンドウ全体がタイトルバー1個分ほど右下へオフセットし、画面左上にデスクトップの隙間が生じる問題が発生しました。 結果として、最小化、最大化、閉じるなどのボタンが押せなくなります。

この原因究明にあたり、以下を検証しました。

  1. DPIスケールフラグの検証: 起動フラグ --force-device-scale-factor=1 を付与して実験。結果、スケーリング補正に至らずObsidianがクラッシュ（signal 5 / SIGTRAP）したため、フラグを即時ロールバック。
  2. ディスプレイ倍率の確認: ホスト側の表示スケールは100%であり、マルチモニター間の倍率差に起因するものではないことを確認。
  3. 上流issueとの照合: 症状のスクリーンショットおよび発生条件を照合した結果、microsoft/wslg#1015（フレームレスウィンドウを最大化する際にワークエリアの枠計算が歪む既知不具合）に一致することを確認。

[!TIP] WSLg上でObsidianのようなElectron製フレームレスアプリを使用する場合、「最大化」ボタンを使わずにウィンドウ端を手動ドラッグして全画面化することで、この描画ズレ現象を回避可能です。ただし、めんどくさい。

2-2. アーキテクチャの見直し（アプリ統合 ➔ ストレージ共有）

プロトコルブリッジ自体は正常に動作していたものの、WSLgという描画レイヤーの不安定性に依存し続ける運用に疑問が生じました。

そこで、「GUIアプリ（Obsidian）はWindowsネイティブで動作させ、データ（Vault）のみWSL2からネットワーク経由で参照する」というやり口を検討しました。

flowchart LR
    subgraph WinHost ["Windows Host (Native GUI)"]
        Clipper["Web Clipper Extension"] -->|obsidian://| WinObs["Obsidian for Windows"]
        WinObs -->|File Read/Write| ZDrive["Z: Drive (rclone mount)"]
        RClone["rclone SFTP Client"] -->|Loopback SSH :2222| SSH
    end

    subgraph WSL2Env ["WSL2 Environment (Storage)"]
        SSH["OpenSSH Server"] -->|Local File System| Vault["/home/.../projects/Obsidian"]
    end

    ZDrive <--> RClone

2-3. SFTPマウント構成の構築手順

UNCパス（\\wsl.localhost\...）からの直接オープンは過去に失敗の経験があったため（画像の通りです）、信頼性の高いOpenSSH + rclone SFTPマウントを採用しました。

1. WSL2側：OpenSSHサーバーの設定

WSL2内に OpenSSH サーバーを構築します。セキュリティ確保のため、バインド先を 127.0.0.1、ポートを 2222、認証方式を鍵認証のみに制限します。

2. Windows側：rcloneによるSFTPマウント

Windows側の PowerShell で rclone リモートを作成し、ドライブレター Z: にマウントします。

# SFTPリモートの作成
rclone config create obsidian-vault-wsl sftp host=localhost port=2222 user=<username> key_file="C:\Users\<username>\.ssh\obsidian-vault-wsl"

# Z: ドライブとしてマウント実行
rclone mount obsidian-vault-wsl:/home/<username>/projects/Obsidian Z: --vfs-cache-mode writes

[!IMPORTANT] --vfs-cache-mode writes の技術的意義 Obsidianは起動時および編集時にインデックス作成やアトミックなファイル書き込みを頻繁に行います。--vfs-cache-mode writes を指定することで、ローカルキャッシュ上で高速に書き込み処理を完了させ、バックグラウンドでマウント先へ同期されるため、I/O遅延によるアプリのフリーズや整合性エラーを防止できます。

3. 自動化と結果

Windowsのタスクスケジューラに「ユーザー定義のログオン時に自動マウントするタスク」を登録し、恒久化しました。

この結果、当初の目的が達成されたうえで、問題も解消できたかと思っています。

  • 達成: Windows版Obsidianのインストールに伴い、公式の obsidian:// ハンドラーがレジストリに自働登録され、WSL2側プロセスを起動することなく直接クリップが可能になりました。
  • 解消: GUI描画がWindowsネイティブとなったため、最大化時のウィンドウオフセット問題が完全に解消されました。

まとめ

両アプローチの特性を比較・整理します。

評価軸 アプローチ1：プロトコルブリッジ アプローチ2：SFTPマウント（最終解）
アーキテクチャ アプリ間連携（Windows ➔ wsl.exe ➔ Linux GUI） ストレージ共有（Windows GUI ➔ SFTP ➔ Linux FS）
Web Clipper動作 〇 動作（プロトコル横流し） ◎ 動作（完全ネイティブ処理）
GUI描画の安定性 ✕ WSLgの最大化バグ（#1015）の影響を受ける ◎ Windowsネイティブ描画のため完全安定
リソース消費 ✕ WSL2内でElectronを常時駆動 ◎ WSL2内のGUIプロセス消費ゼロ
技術的限界 obsidian-cli (WSL内) と連携可能 obsidian-cli のIPCソケット接続は不可 ※

※補足: WSL2内のメンテナンスで用いる obsidian-cli コマンドはUnixドメインソケットによるローカルIPCを使用しているため、Windows版Obsidianを直接操作することはできません。CLI操作が必要な場合は、非起動時のファイル直接編集スクリプト等で代替するよう割り切っています。

参考資料