日本：Appleは12月までにブラウザエンジンの禁止を解除する必要
(open-web-advocacy.org)- 日本政府は最近、スマートフォン法を可決し、AppleのiOSにおけるサードパーティ製ブラウザエンジンの禁止を直接的に禁じた
- これまでWebKitエンジンの強制により、iOSでのブラウザ競争は事実上遮断され、Webアプリの競争力も低下していた
- 新たなガイドラインは、Appleが技術的・商業的に非現実的な妨害を行うことも認めないと明記している
- また、ブラウザ向けのOS APIへのアクセス権が機能面で同等に保障されなければならず、差別的な性能低下も認められない
- 日本の法律施行により、EU・英国とともにブラウザ競争の回復に向けた規制環境が整いつつあり、2026年が転換点になる見通し
日本、Appleにブラウザエンジン禁止の解除を要求
日本は最近、正式に「スマートフォンソフトウェア競争促進法」を可決し、AppleがiOSでサードパーティ製ブラウザエンジンを禁じてきた長年の方針を直接的に禁止する措置を施行した
ブラウザエンジン禁止の現状
- 従来はAppleがWebKitエンジンのみの使用を認めていたため、Firefox、Chrome、Edge、Opera、Brave、Vivaldiなど、あらゆる主要ブラウザエンジンがiOSから排除される結果となっていた
- これにより、実質的にブラウザ競争が遮断され、Webアプリがネイティブアプリと同等に競争するために必要なAPIや性能を利用できない状況が生じていた
日本の法制化とガイドライン
- この法律はデジタル市場競争本部の報告書を基に企画され、Open Web Advocacyの助言も反映されている
- 最近、モバイルソフトウェア競争法（MSCA）ガイドラインが公表され、法律の実際の解釈と執行方法が明確に示された
代替ブラウザエンジンへの妨害禁止
- ガイドラインは、サードパーティ製ブラウザエンジンの導入を妨害または阻害するあらゆる行為を明示的に禁じている
- アプリ提供者に過度な技術的制約を課したり、コスト負担を負わせたり、利用者を代替ブラウザから遠ざける措置などがこれに含まれる
- 妨害行為の判断では、提供者が明白に禁止する場合だけでなく、現実的に導入可能性が著しく低くなる場合も該当する
- この条項は、Appleが名目上は許可していても、実際には利用不可能だったり商業的に意味をなさない状況を認めないことを意味する
OS APIアクセスの機能的同等性
- MSCAはOS APIへのアクセス権について、機能的に同等なアクセスを保障するよう定めている
- 代替APIの提供は認められるが、実質的に著しく劣る性能である場合は機能的同等とは見なされない
- つまり、技術方式が異なっていても、Appleなどの指定事業者が享受する水準の同等な性能とアクセシビリティがサードパーティ製ブラウザにも保障されなければならない
ブラウザ選択画面（Choice Screen）の義務
- 法律はブラウザ（およびその他のソフトウェア）について、**選択画面（Choice Screen）**の提供を義務付けている
- EUより強化された指針として、"最初の有効化直後"に直ちに選択画面を表示しなければならない
- スマートフォンの初回設定時や該当アプリの初回起動時に、利用者へ特定のソフトウェア選択を促す必要がある
今後の動向
- モバイルソフトウェア競争法は2025年12月施行予定である
- 日本はEU、英国と並び、Appleがサードパーティ製ブラウザエンジンを認めるべき国に加わる
- 日本は欧州・英国の規制経験を参考にしながら執行準備を進めるとみられる
- EUと英国の事例が示す通り、実効的な執行は長期的かつ複雑な手続きになる見通しである
結論と示唆
- 日本、EU、英国はいずれも、Appleへのサードパーティ製ブラウザエンジン対応の義務化を通じて、iOSにおける実質的なブラウザ競争の回復を進めている
- 2026年はブラウザ市場構造の変化における転換点となる可能性がある
- 最終的な成否は、規制当局の執行意思とAppleの実質的な改善努力にかかっている
- ブラウザおよびWebアプリの競争環境改善に向けて長年努力してきた日本政府と関係団体の役割が強調される
7件のコメント
うーん……ブラウジング機能がすべて基盤ライブラリを経由する方式だと、システムで特定のURLをブロックした場合に、すべてのアプリの内蔵ブラウジング機能でも回避できない一貫性が保たれるので、その点は少し残念ですね。
AIブラウザの躍進が予想されます
開発者の立場では、考慮すべき環境がさらに増えることになりそうですね（笑）…
これからはWeb標準に従って開発すべきですね。ない機能は積極的に使わないように。
数は多く見えるけど、結局はFirefoxとChromiumエンジンではないですか？
禁止状況で言及されているエンジンの一覧を見るだけでも目が回りますね @_@
Hacker Newsの意見
みんなChromeの話をしているけど、自分はAndroidでChromeを無効にしてFirefoxを使っている。モバイル版FirefoxにuBlock Originを入れて使うと、ほぼデスクトップWebに近い体験になる。広告ブロックだけでなく、
:has-textなどのRegExルールで、自分が気にしない要素もその場ですぐブロックできる。Chromeはもうデスクトップでもこういうことができない。いっそAndroidをメインデバイスに移そうかと考えるくらいだ。ただ、iMessageのせいでMacBookからそのままチャットに返信できる便利さが大きすぎて、簡単には離れられない。それを除けば全体的にAndroidのほうがずっといい。iOSのキーボードやSiriの話は持ち出さないほうがいいくらいだFFとuBOの組み合わせが、Androidにとどまる決め手のキラーアプリだ。Appleがそれを許していたら、とっくに乗り換えていたと思う。messages.google.com は検討したことがある？ Googleのメッセージアプリが必要で（Samsung Messagesではない）、デスクトップでSMSとRCSが使えるので、iMessageの代替としてちょうどいい
モバイル版Firefoxではconsent-o-matic拡張も本当に便利だ。ほぼすべてのクッキーバナーを自動でクリックして通してくれるので、モバイルでいちいち処理する必要がなく、ずっと楽になる
自分も https://messages.google.com を使って、AndroidベースのデスクトップiMessageっぽい環境を作っている。用途に合うかも？ 自分はiMessageを使わないので、そこはよく分からないかもしれないが
iMessageなしで単にSMSでよければ、KDE ConnectでAndroidからすばらしいデスクトップメッセージ環境が作れる（Linux、Windows、MacOSで使え、プラットフォームごとに機能差はあるがSMSはすべて対応している）。 https://kdeconnect.kde.org/
日本は、AppleがEUで見せた「言葉遊び的な規制順守」の事例から教訓を得たように見える。こんな形で出てくるなら、Appleが本当に痛手を受けるようなまともな罰金を日本でも科されてほしい。「if」ではなく「when」だと思う
販売や輸入を禁止するところまで想像してしまう。そうなったら、Apple Storeをどれだけ長く閉めればAppleが折れるのか気になる
自分は、うっかり何かをやらかさないようにしてくれるwalled gardenが好きだ。Appleが自分の位置情報を勝手に渡したり、変なMonarchが自分を追跡したりといった、プライバシー漏えいの心配も減るのでありがたい。(+4500 upvotes) Redditでは反Appleの見出しが+3万アップボートを集める一方で、実際には親Apple寄りのコメントがそれに比べてずっと少なく、いつも不思議に思っていた。マーケティングチームやトロールファームが評判管理をしていたのではないかと思う
この世界的な立法の流れが、iOSでよりオープンなアプリ生態系につながるなら本当に歓迎したい。BrowserEngineKitはXPCとiOS拡張システムの薄いラッパーにすぎない。もしXPCがオープンAPIで、しかもAppleの許可なしに隔離されたサブプロセスでJITを許可していたなら、開発はずっとやりやすかったはずだ。たとえば、メッセンジャーアプリが信頼できない入力値を処理する別サブプロセスを持てるし（iMessageはすでにやっている）、アプリの不安定なコンポーネントを隔離して使い勝手やクラッシュ復旧を改善できるし、レトロシステムのエミュレーター速度は大きく向上し、iOSでWASMも活用でき、ブラウザも特殊目的APIなしでXPCを使えただろう。問題は、こうしたことが可能になると、App Store審査後でもネイティブ速度で動くコードをアプリ内に読み込むのが簡単になり、周知のとおり、そんな世界が来たら大惨事になるという話だ
その「大惨事」が来たら、MacRumorsのようなサイトで人々が大騒ぎするのを眺めていたい。Appleが自らの経済的利益のために、インターネット上のナラティブを後押しするサイトを、宣伝面で支援していないと無邪気に考えるのは難しい。たとえば、スマホを自由に使う自由がみんなのセキュリティとプライバシーを脅かす、みたいなばかげた意見が事実上ずっと繰り返されている
こうなると、システムレベルのマルウェア対策の負担がアプリサンドボックスにかなり移ることになる。実際、今でもサンドボックスは、ノータリゼーション、権限、アプリ審査など複数の防御層の一つだった。自分も、ユーザーが望むアプリを何でも入れられるべきだとは思うが、その場合、一般的なiPhoneがAndroidのようにマルウェア感染へよりさらされやすくなる現実も認める必要がある。Appleがこうした方針を取る背景には独占欲だけでなく、実際のセキュリティ上の問題もある（もっとも主な動機は利益である可能性が高いが）
ブラウザ自体も一種のアプリストアなので、実際には自分たちは毎回Appleの審査なしでそこでアプリを動かしている。そういう文脈で、なぜApp Storeの安全性をAppleとファンがあそこまで強調するのか、よく分からない
JITが許可されれば、単に高速なエミュレーションにとどまらず、インタプリタを回し続けなくてよくなるので効率も上がり、バッテリー持ちの管理や2008年のゲームを動かすときの発熱問題も改善できる
（意味のない意見は省略）
「ブロックの可能性」を広く解釈するなら、たとえば「代替ブラウザエンジンを日本のAppleアカウントでしか公開できないようリージョンロックする」ことも、本質的には代替ブラウザの実質的な存在そのものを妨げる行為と見なせるかもしれない。Mozillaにしても、そうなれば対象ユーザー層が小さすぎて、iOS向けFirefoxを移植する理由がなくなる。現実味は薄いが、ひょっとするとこれが世界的なブラウザ選択の自由への小さな出発点になるのかもしれない
リージョンロックして特定アカウントにしか代替ブラウザエンジンを許可しないのは、AppleがEUでやっていることの一つだ
Gecko（Firefoxエンジン）はすでにiOSへ移植されていると認識している
もともと市場シェアが小さいのに、それをごく少数だけさらに増やすために移植するのか疑問だ
Mozillaはもともと少数シェアには慣れている組織だ。こういう状況もそれほど変わらないだろうし、むしろ市場開放前にユーザー経由でQA版を配布する機会になるかもしれない
EUとUKに続き、日本もiOSの代替ブラウザエンジン禁止にいよいよ終止符を打つ。3地域とも大市場なので、ChromeやFirefoxがiOS向けに独自エンジンを使う版、つまりBlinkやGeckoベースのブラウザに投資する十分な動機が生まれるのか気になる。これが理由で開発が遅れていたという話は以前から多かった
同じサイトを見ると、Appleは今も大手ブラウザ各社が独自エンジンを出せないよう、あらゆる妨害を続けているようだ 関連ブログ
UKについては、2024年のDigital Markets Actなど関連法を政府が消極的に執行しているという話だと理解している
日本の文化的には、こうした変化はあまり気にされないだろう。日本でのLinux利用率を見ても、少数の熱心なユーザーは何があっても使い続けるが、一般大衆は便利なものをそのまま使う。システムや設定をいじり回すのをあまり好まない
Appleがブラウザ開発者にあまりにも厳しくしてきたせいで、誰もその障壁を越えられなかったという見方もある
FirefoxがBlinkへ切り替え、Googleと協力してiOS向け代替エンジンを作るほうが、現実的で簡単な選択ではないかと考えてしまう
こうした変化が本当に良いことなのか気になる。市場でのChromiumのシェアをさらに押し上げる結果になるのではないかと悩ましい
Safariは構造的に良いブラウザではない。Appleの利害のためにWebプラットフォームを意図的に弱くしているからだ。まともな競争相手のブラウザがなければ無理やり使わせることはできないので、ユーザーが選ぶ本当に良いブラウザを作ることこそ本当の市場競争だ
それはそうだ。結局Safariは、iOSでWeb全体が「All Chrome Everywhere」になるのを抑える最後のとりでだった
政府が市場独占を解決できる可能性もある 米司法省 vs Google訴訟ウィキ
その通りで、だから悩ましい。一方ではAppleに必ずiOSをもっと開放させる必要があるが、他方では結局Chromeの独占が強まってしまう
iOSでまともなFirefoxを使えるようになる利点は大きいし、これは前向きな変化だ。AppleがWeb標準を自社利益のために傷つける不当な影響力（例: WebGPUでのSPIR-V対応妨害）が弱まる
（Narrator）1年後、日本でChromeのシェアは100%に達し、すべてのWebサイトがこのブラウザ専用にだけ設計されるようになった
日本はAppleと独特な関係にある。たとえばFeliCa（日本式NFCシステム）ベースのチケット機能がすべてのiPhoneに内蔵されているため、世界中のiOSユーザーも日本ではずっと便利に暮らせる。さらに驚くべきなのは、実際のチケット利用にどんなアプリも必要なく、Apple Payさえあればよい点だ。こうした流れはネイティブアプリの強みそのものを徐々に狭めている（まだネイティブアプリにも固有の利点は残っているが）。その一方で、Appleが結局は「門番」の役割を別の領域へ移しているだけだという主張にも反論しにくい
FeliCaネットワーク対応は、日本でモバイル交通・決済技術がiPhone以前にすでに定着していたことが主な理由だ。Mobile Suicaやおサイフケータイがある状況だったので、Appleが競争力を維持するには積極的に追随する必要があった。日本限定SKUのiPhoneから始まり、その後グローバルへ拡大した。今でも日本ではモバイル決済市場は独占ではない。Appleが競争圧力を受けると、Suicaのエクスプレス・トランジットのような機能追加が起きる。そしてPayPayのような日本発のQRコード決済アプリが、クレジットカード決済よりも広く普及している
日本のiOSシェアは米国（59%）やUK（47%）、欧州（34%）よりも高く、64%だ statcounter出典
FeliCaは特許ライセンスの問題だ。Appleはどこかで有利な契約を取ったように見える。Google Pixelもチップ自体はすべて搭載しているが、日本モデル以外ではその機能がソフトウェアで無効化されている（root化すれば解除できる）
「できるという力」の威力を実感する。ある国がやってのけると、20年間不可能だと言われていた他国も「自分たちにもできる、出遅れられない」と変わり始める
GoogleがiOS向けに「本物の」Chromeを出せるよう、継続的に準備してきたと考えざるを得ない。おそらく法改正のタイミングですぐ出せるように、ずっと前から作っていたのだろう
GoogleはBlink（iOS向けChromeエンジン）の移植を進めており、段階的に進展している。Chromiumのバグトラッカーに追跡項目がある トラッキングリンク。おそらくAppleの地域ロック（EU geofencing）方針やBrowserEngineKitの各種制限のため、まだ本番投入向けには十分なリソースが割かれていない状況だ
2023年2月: 「Google、iOSでApple WebKitの代わりにBlinkエンジンでChromeを動かす作業を開始」 関連記事
（BlinkはChromeのWebレンダリングエンジンだ）iOS向けChromium/Chromeのビルド方法に関する公式文書を見ると、「blink web platform」は実験的で、分析用途にのみ使うよう案内されている。関連ターゲットとしてcontent_shellとchromeが有用だと明記されている。 公式ビルド文書