要約

  • 2026年9月15日に発足したグループは、ブラウザーデータのインポートとエクスポートに関する原則をCommunity Group Reportとしてまとめることを目指す。厳格な実装標準を定めず、Specificationも発行しないと明記している。
  • 設立を支持した5人、参加者、合意、報告書、標準化、法的義務、ベンダーの採用、実装、相互運用試験は、それぞれ証拠の異なる状態である。前の状態から次を推定することはできない。
  • DMAを背景としたiOSの移行機能やSafariからChromeへの手順は、実装が先行していることを示す。一方で、新グループへの規制上の委任や業界全体の採用を示すものではない。

すでに動く移行と、始まったばかりの議論

AppleのiOS 27向け文書では、Safariからブックマーク、履歴、拡張機能、クレジットカード、パスワードを選んでZIPへ書き出せる。ファイルは暗号化されておらず、取り込み後に削除するよう注意もある。ChromeのiPhone・iPad向け案内は、そのファイルを選び、内容を確認し、パスワードの競合を処理して取り込む手順を示す。BrowserKitには、履歴、ブックマーク、リーディングリスト、拡張機能を扱うシステム仲介型の管理機能がある。

ここで確認できるのは、特定のOS、製品、データ種別、方向における機能である。あらゆるブラウザーに共通する形式や、全方向の移行を証明するものではない。AppleやGoogle、Chromeが新しいグループに参加した、あるいは将来の報告書を採用すると約束したという証拠でもない。

新グループの公開スコープは、ブラウザー開発者と実装者が、ブラウザー間でデータを移す利用者のニーズについて合意形成する場を想定している。成果物は、デバイス、プラットフォーム、ブラウザーをまたぐ結果の一貫性を高めるためのインポート・エクスポート原則を記した報告書だ。同時に、厳格な実装標準は定めず、Specificationsを発行しないという限界も示す。

この限界は弱さではない。現時点で与えられている権限そのものだ。

5人の支持は業界の意思ではない

Tom Fishが9月11日に設立を提案し、Dominique Hazaël-Massieux、Johannes Ernst、Bruce Lawson、Chris Riley、Tom Fishの5人が設立を支持した。W3CのFAQによれば、5人の支持はCommunity Groupを発足させるためのしきい値である。

しきい値は発足だけを意味する。設立支持は参加ではなく、個人参加は組織代表とは限らない。参加は文書への同意ではなく、同意はベンダーによる製品実装の約束ではない。

9月20日の公開ページには、参加者としてTom Fishが1人、議長は未選出と表示されていた。今後変わり得る時点情報だが、出発点を正確に示している。公開上はまだ議長、報告書草案、記録された決定、版管理されたデータモデル、相互運用試験計画がない。

参加にはW3Cアカウントが必要だが、W3C Membershipは不要である。W3Cは、グループをホストすることが活動への賛同を意味せず、W3Cの会員やスタッフの見解を必ずしも表さないとも説明する。場を提供することと、標準化権限を付与することは別だ。

報告書から標準へ自動的には進まない

W3Cのグループ種別比較では、Community Group Reportは標準化トラック外の成果物とされる。Community GroupはW3C標準を作らない。標準化へ進むなら、適切なスコープを持つWorking Groupが作業を引き受け、別の手続きを踏む必要がある。

したがって、少なくとも次の状態を分ける必要がある。公開討議、Community Group Report、W3C標準、規制上の義務、ベンダーの採用表明、製品実装、そして検証済みの相互運用性だ。

報告書が証明するのは、ある版でグループが公表した内容である。標準には標準化手続きが要る。法的義務には法令、地域、対象企業、所管機関がある。採用にはベンダー自身の表明が必要だ。実装には製品やAPIの版があり、相互運用性には両端の版、試験環境、成功条件、失敗記録が要る。

「W3C」という名称で空欄を埋めてはならない。反対に、製品機能が存在するだけで、その設計をマルチステークホルダー手続きが承認したことにもならない。

DMAは別の権限源である

欧州委員会は2026年5月、iOSとiPadOSにおけるブラウザーデータ移行を、Digital Markets Actを巡る2年間の規制対話の成果として紹介した。OSと利用者が仲介するアプリ間の双方向機構で、ブックマーク、履歴、パスワード、クレジットカード、拡張機能などを対象とする。一部の第三者ブラウザーはSafariからの取り込みに対応しているという。

この事例の拘束力は、Community GroupではなくEU法に由来する。DMA第6条9項はgatekeeperに対する利用者データのポータビリティー義務を定め、利用者の許可、無償の手段、状況に応じた継続的・リアルタイムのアクセスを扱う。地域と対象が決まった義務を、将来の報告書が世界中のブラウザーへ拡張することはできない。

規制が製品実装を促し、実装経験がコミュニティーの議論を豊かにし、報告書が原則を整理することはあり得る。しかし三者の権限は共有されない。

ポータビリティー権限レシート

将来の報告書は、重要な主張ごとに権限のレシートを添えるとよい。成果物の種類、状態、版、変更不能なURL、日付を記す。起草者、設立支持者、現在の参加者、組織代表の有無、利益開示、議長、編集者、意思決定手続き、異論と処理も残す。

技術面では、データ種別、送出側、受入側、方向、起動者、デバイス、OS、ブラウザー、プロファイル、アカウントの境界を明示する。形式、暗号化、保存方針は、特に認証情報や決済情報で欠かせない。法律を根拠にするなら法的根拠、地域、規制対象、当局、発効日を記す。ベンダー採用なら表明の原文と対象報告書の版、相互運用なら製品・APIの版、環境、成功条件、既知の失敗、競合処理、取消し、ロールバックを記録する。

不明な欄は不明のままにする。W3Cがホストしていること、有名企業に類似機能があること、エクスポートボタンがあることは、欠けた証拠の代わりにならない。

レシートの目的は、初期段階の場を認証機関に変えることではない。流通する間に主張の種類が変わるのを防ぐことだ。「原則を議論する予定」は「報告書を発行した」ではない。「取り込み機能がある」は「報告書を採用した」ではない。特定の組み合わせで成功した試験は、一般的な相互運用性ではない。

短期の成果として最も信頼できるのは、限界を明記した版管理可能な報告書である。機密性の高い認証情報とブックマークを分け、インポートとエクスポート、片方向と双方向を分け、標準化、規制、製品、試験への引き渡し条件を示す。現時点の権限は、招集し、討議し、報告することにある。それを正確に使うだけで十分な価値がある。

出典