メインコンテンツにスキップ

ブックマーク同期が思ったより複雑になる理由

· 読了時間:約9分
Frank
Bookmark UniSync の作者

「なぜブックマーク同期はこんなに手間がかかるのか」「ブラウザ同士でそのまま同期できないのか」「なぜmacOSアプリまで必要なのか」。こうした質問をよくいただきます。

先に結論を言うと、今の構成は技術的に難しいからではなく、Appleのプラットフォーム制約に合わせた結果です。

この記事では、Bookmark UniSyncがなぜ現在のアーキテクチャを採用しているのか、Safariで何ができて何ができないのか、そしてなぜこの方法がもっとも現実的なのかを整理して説明します。


🍎 Safariで最初にぶつかる制約

最大のポイントはシンプルです。Safari拡張機能はSafariのブックマークを直接読み書きできません。

これは私たちの実装不足ではなく、Appleが設けている権限の境界です。Safari拡張機能は現在のタブ情報を読んだり、ページ内で動作したりはできますが、次のことはできません。

  • Safari全体のブックマーク一覧を取得する
  • ブックマークを追加、削除、編集する
  • ブックマークデータをプログラムからインポート、エクスポートする

Appleはブックマークを個人性の高いデータとして扱っているため、拡張機能からのアクセスを強く制限しています。プライバシーの観点では理解できますが、製品設計には大きな影響があります。

つまり拡張機能がSafariのブックマークに触れられない以上、SafariとChrome、あるいはSafariとEdgeの同期を拡張機能だけで完結させることはできません。

そこで必要になるのがmacOSアプリです。


💻 macOSアプリが必要な理由

Safari拡張機能だけでは無理となると、次に現実的なのはmacOSネイティブアプリです。

ユーザーの許可を前提にすれば、macOSアプリはSafari側のブックマークフローに関わることができます。Bookmark UniSyncのmacOSアプリは、まさにこの橋渡し役です。Safariと他ブラウザの間をつなぐ中継点として動作します。

実際の役割をシンプルにまとめると次の通りです。

  • ChromeとEdgeは拡張機能だけで同期できる
  • SafariはmacOSアプリが間に入らないと同期できない
  • 拡張機能に許可されていないSafari側の処理をmacOSアプリが担う

つまり、このアプリは無駄な複雑さではなく、Safari対応を実現するために必要な構成要素です。


🚫 なぜMac App Storeでは配布していないのか

もうひとつ多いのが、「なぜ公式サイトからダウンロードする方式で、Mac App Storeにはないのか」という疑問です。

これも同じ文脈で説明できます。Appleの審査ポリシーはSafari拡張の制約と同じプライバシー思想に沿っているため、ブックマークデータと密接に関わるアプリは配布面でも制約を受けやすくなります。

その結果、現実には次のような状態になります。

  • ✅ macOS上では通常どおり動作できる
  • ✅ ユーザーの同意を前提にSafariブックマーク同期を支援できる
  • ✅ 製品に必要な技術的役割を果たせる
  • ❌ Mac App Storeでの配布には向かない

つまり、App Store非対応は運営上の都合というより、プラットフォームポリシーによるものです。


📱 iPhone同期がiCloud経由になる理由

「ChromeやEdgeのブックマークをiPhoneに直接送れないのか」という質問もよくあります。

答えはAppleエコシステムの構造にあります。iPhoneのSafariブックマークはiCloudブックマーク同期に紐づいています。つまりChromeやEdgeのブックマークをiPhoneのSafariに反映させるには、次の流れを通る必要があります。

  1. ブラウザのブックマークデータをmacOSアプリへ渡す
  2. macOSアプリがそのデータをAppleのエコシステム側へ橋渡しする
  3. iCloudが更新内容をiPhoneへ反映する
  4. iPhoneのSafariがiCloud経由でブックマークを受け取る

少し遠回りに見えるかもしれませんが、一般ユーザーが安定して使える方法としてはこれが最も現実的です。

他の手段も検討しました。

  • iPhoneに拡張機能を直接入れる: iOS側の制約がさらに厳しく現実的ではない
  • サードパーティのクラウド経由で回避する: 理論上は可能でも設定負荷が高く安定性も落ちる
  • 脱獄ベースの方法: リスクが大きく一般向けではない

そのため、macOSアプリを中継点にする今の形がいちばん堅実です。


📱 モバイル版ChromeやEdgeを最優先にしていない理由

すべてのモバイルブラウザを最初から広くカバーしない理由もあります。

Bookmark UniSyncの出発点は、デスクトップで複数ブラウザを行き来する人のブックマーク管理を楽にすることでした。日々の作業で実際に困る場面から先に解決する方針です。

macOSからiPhoneへの同期を用意したのは、SafariをAppleエコシステムの中で切れ目なく使えるようにするためでした。一方で、あらゆるモバイルブラウザのケースまで一気に広げると、複雑さに対して得られる価値が見合わない可能性があります。

今の優先順位は明確です。

  • デスクトップブラウザ同士の同期
  • macOSでのSafari対応
  • iCloud経由でiPhoneまでつなぐ導線

🤔 それならSafari対応をやめればいいのでは?

もっともな意見です。Safariが一番難しいなら、ChromeとEdgeだけに絞ればシンプルになるのではないか、という考え方です。

ただ、それでは製品の価値が大きく下がります。

Macユーザーの多くは標準でSafariを使いますし、iPhoneユーザーにとってもSafariは最終的な受け皿になりやすい存在です。その状態でChromium系だけに強い製品を作っても、本当の意味でのクロスブラウザ同期とは言えません。

Safari対応が重要なのは次の理由です。

  1. macOSにはSafariを中心に使うユーザーが多い
  2. iPhoneユーザーにとってSafariは自然な到着点になりやすい
  3. Appleユーザーを外すとクロスブラウザ同期の価値が大きく減る

構成は複雑になりますが、Chrome、Edge、Safari、macOS、iPhoneをひとつの流れでつなげられるなら、その価値は十分にあります。


💡 では、なぜChromeとEdgeは直接同期できるのか

ChromeとEdgeが比較的簡単なのは、どちらもChromiumベースだからです。

同じ拡張機能モデルを共有しており、ブックマークへのアクセス権限も広く開かれています。そのため同期フローはかなりシンプルです。

  • Chrome拡張機能でChromeのブックマークを読む
  • Edge拡張機能でEdgeのブックマークを読む
  • サービスレイヤー経由で双方向に同期する

この組み合わせなら追加のデスクトップアプリは不要です。Safariだけが、プラットフォーム権限の違いによって別対応になるわけです。

短く整理するとこうなります。

  • Chrome ↔ Edge: 拡張機能だけで十分
  • Safari ↔ ChromeまたはEdge: macOSアプリが必要

📝 現在のアーキテクチャを一言でまとめると

Bookmark UniSyncの設計は、次の制約を前提にした最も実用的な落としどころです。

  1. Safari拡張機能はブックマークに直接アクセスできない
  2. ブックマーク関連アプリはApple側の配布ポリシー制約を受ける
  3. iPhoneのSafari同期はiCloudを経由する必要がある
  4. Chromiumブラウザはブックマーク権限がかなり開かれている

その結果、同期ルートは次の3種類に分かれます。

  • Chrome ↔ Edge: 拡張機能のみ
  • Chrome/Edge ↔ Safari: 拡張機能 + macOSアプリ
  • デスクトップブラウザ ↔ iPhone Safari: macOSアプリ + iCloud

見た目には複雑でも、危険な回避策や不安定な裏技に頼らず提供できる、いちばん安定した構成だと考えています。


🤝 作っている側からの正直な話

macOSアプリを追加で入れていただく以上、拡張機能ひとつで完結する体験ほど軽くないことは理解しています。

もし将来Appleがブックマーク権限をもっと広く開放するなら、私たちも最優先で構成をシンプルにしたいと思っています。それまでは、今できる範囲でできるだけ安定して、わかりやすく、安心して使える形を磨き続けます。

Bookmark UniSyncは大きな会社が作っている製品ではありません。それでも、実際の利用シーンに沿って丁寧に作ることは続けていきます。

仕組みを理解したあとで実際の設定手順を確認したい場合は、Bookmark UniSyncの使い方をご覧ください。


📥 ダウンロードと利用開始


⚠️ 最初におすすめしたいこと

どのブックマークツールを試す場合でも、まずはローカルバックアップをエクスポートしてください。想定と違った場合でも元のデータにすぐ戻せるので、リスクをかなり下げられます。


📚 あわせて読みたい記事


質問や提案があれば、いつでもご連絡ください。


技術的な制約そのものより怖いのは、それを乗り越える方法を探さないことです。遠回りでも、ユーザーをちゃんと目的地まで連れていけるなら、その設計には意味があります。