#Googleは開かれたウェブを殺している：デジタル主権は取り戻せるか？🛡️🌐🔪 #オープンウェブの危機 #Googleの闇 #八20

Googleがウェブを「殺す」という衝撃の真実：デジタル主権は取り戻せるか？🛡️🌐🔪 #オープンウェブの危機 #Googleの闇

かつてのオープンなインターネットはどこへ？知られざる巨大IT企業の支配戦略を徹底解剖します

目次

第一部：静かなる包囲網

第1章 本書の目的と構成：Googleの野望を暴く、戦いの幕開け – Why We War on the Web's Dark Duke

この度は、オープンウェブの未来を巡る喫緊の課題について、皆様と深く議論を交わすべく、この文章を執筆いたしました。私たちは今、インターネットの根幹を揺るがす静かなる戦いの渦中にいます。その主役は、Google。かつては「悪しきをなさず（Don't be evil）」という理想を掲げた巨大企業が、いかにして、その理念とは裏腹に、ウェブの分散性と自由を侵食してきたのか、その詳細を掘り下げていきます。

本書の目的は、単なる技術的な解説に留まりません。Googleの一連の行動が、個々の技術的判断としてではなく、より大きな戦略的意図、すなわちウェブの支配と囲い込みを目指す緻密な計画の一環としてどのように機能しているのかを明らかにすることです。そして、その現状に対し、私たちユーザー、開発者、そして社会全体がどのように向き合い、行動すべきか、その道筋を共に探ります。

本稿は、まず第一部で、Googleによるウェブ支配の歴史的背景と、その戦略の初期段階を概観します。第二部では、2013年以降に顕著になった具体的な行動と、それがオープンウェブにもたらした壊滅的な影響を詳細に検証。第三部では、過去の類似事例や国際的な規制の動き、そして日本への具体的な影響を多角的に分析し、第四部では、分散型技術の可能性や、私たちにできる具体的な対抗策、そしてウェブの理想的な未来像について提言を行います。専門的な内容は適宜解説を加え、平易な言葉で、しかし深く掘り下げてお伝えしてまいります。この議論が、皆さまのデジタル主権を再考する一助となれば幸いです。

コラム：私が初めてウェブに触れた日

今から振り返ると、私が初めてインターネットに触れたのは、まだダイヤルアップモデムが主流だった頃でした。ピーガーガーというあの独特の接続音と共に現れるウェブの世界は、まるで魔法のようでした。世界中の情報に瞬時にアクセスできることに興奮し、HTMLを学び、拙いながらも自分のウェブサイトを作った日のことは忘れられません。当時は、誰もが自由に情報を発信し、誰もが自由に情報にアクセスできる、まさに「オープン」な空間だと信じていました。あの頃の純粋な驚きと感動が、今のこの問題意識の原点にあるのかもしれません。

第2章 要約：オープンウェブ解体という見過ごされた戦争 – Summary of the Slaughter, Web's Woe We Wager

本論文は、Googleが過去10年以上にわたり、オープンなウェブを意図的に解体し、自社の支配を確立してきたという衝撃的な主張を展開します。これは単なる技術的進化の帰結ではなく、巨大企業による戦略的な囲い込み（Embracing, Extending, Extinguishing - EEE）戦略の現代版として位置づけられます。

Googleの行動は、かつてMicrosoftがブラウザ市場で用いた独占手法を彷彿とさせます。具体的には、XMLやXSLTといったオープンなデータ標準のサポートを縮小・廃止する提案を繰り返す一方で、自社に有利な技術スタック（例：Chromeブラウザ、WHATWGでの標準化主導、AMP、Manifest V3）を推進してきました。

その一連の動きは、Google Readerの閉鎖（2013年）、XMPPの連邦機能停止（2013年）、MathMLサポートの削除提案（2013年）、ユーザー証明書生成を簡素化する`keygen`要素の廃止提案（2015年）、さらには最近のXSLT削除の再試行に至るまで、多岐にわたります。

論文は、これらのGoogleの行動が、技術的な理由やリソース不足によるものではなく、オープンウェブの表現力と相互運用性を妨げ、最終的にユーザーをGoogleのエコシステムに閉じ込めるための「政策的選択」であると断じています。

ドーリアン・テイラー氏によるXSLTの情熱的な擁護論を引用しつつ、この論文は、ウェブの未来が少数の巨大企業によって定義されることへの強い警鐘を鳴らしています。そして、対抗策として、XML/XSLTのようなオープンな技術の積極的な利用、ブラウザ開発者への働きかけ、そして真にオープンで分散化された代替技術の構築を呼びかけているのです。

これは、単なる技術論争ではありません。私たちの情報へのアクセス、プライバシー、そしてデジタル空間における自由そのものに関わる、現代社会の根幹を問う問題提起なのです。

コラム：失われたお気に入りのサービス

私はGoogle Readerが大好きでした。RSSフィードをまとめて購読できるあのシンプルなサービスは、世界中の情報を効率よくキャッチするのに不可欠でした。2013年にその閉鎖が発表された時、多くのユーザーが抗議の声を上げましたが、Googleは聞き入れませんでした。当時の私は、単純に「ユーザーの習慣が変わったから仕方ないのかな」と思っていました。しかし、今この論文を読んで、あれが単なるサービスの終了ではなく、Googleによるウェブの分散性を破壊する「最初の一撃」だったのかもしれないと考えると、背筋が寒くなります。あの失われた機能の背後には、もっと大きな戦略が隠されていたのですね。

第3章 歴史的位置づけ：第一次ブラウザ戦争から始まった支配への道 – From Browser Brawls to Google's Galls, History's Haunting Halls

詳細を見る

この論文が提示するGoogleの行動は、インターネットの歴史における重要なパラダイムシフトの渦中に位置づけられます。それは、かつての分散型・オープンなウェブから、現在の中央集権型・プラットフォーム依存型ウェブへの移行期です。

記憶に新しいのは、1990年代後半から2000年代初頭にかけて繰り広げられた「第一次ブラウザ戦争」です。この戦いは、MicrosoftがWindowsの圧倒的なOSシェアを背景にInternet Explorer（IE）を無料でバンドルし、Netscape Navigatorを市場から駆逐したことで知られています。Microsoftのこの行為は、当時の独占禁止法訴訟にも発展しました。彼らが用いたのは、後に「抱きしめ、伸ばし、消す（Embrace, Extend, Extinguish - EEE）」として悪名高くなる戦略です。既存の標準を「抱きしめ（Embrace）」て普及させ、自社独自の拡張機能を「伸ばし（Extend）」て他社を追随させ、最終的に市場から競争相手を「消し去る（Extinguish）」という手法です。

Microsoftの短命な勝利の後、ウェブ開発は再び活気を取り戻します。Mozilla Firefox、Opera、Apple Safariといったブラウザが、Web標準への準拠を武器にMicrosoftの優位性に立ち向かいました。この動きは、ブラウザ間の相互運用性を高め、ウェブのオープン性を再確立するかに見えました。

しかし、本論文が指摘するように、Googleの登場とChromeブラウザの推進は、この流れに新たな、そしてより複雑な支配のベクトルをもたらします。Googleは、その圧倒的なウェブ検索における優位性を利用してChromeの採用を促進しました。これはIEの普及戦略と酷似していますが、Chromeがオープンソースのコア（Chromium）上に構築されたという点で、多くの批判が避けられました。

同時期、インターネットはFacebookなどの集中型ソーシャルメディアプラットフォームの台頭、モバイル接続の爆発的普及（iPhoneとAndroid）、そしてWebアプリケーションの急速な発展という大きな変化を遂げていました。これらの変化は、ウェブを文書のネットワークから、中央集権型サービスのグラフィカルユーザーインターフェースへと変貌させました。

この歴史的文脈において、本論文は、GoogleがかつてMicrosoftが行ったEEE戦略を、より巧妙に、そしてデータと標準化の領域で展開していると主張しています。つまり、Googleの行動は、単なる技術的進歩や市場競争の産物ではなく、ウェブガバナンス、デジタル主権、そして情報へのアクセス権そのものを巡る、現代のウェブ覇権戦争として位置づけられるのです。

これは、ウェブ技術の進化が単なる技術的進歩ではなく、巨大企業の商業的・戦略的意図によって形成される「政治的」なプロセスであることを明確に示唆する点で、重要な論考です。

コラム：私が目撃した、もう一つのブラウザ戦争

私はインターネット業界に長く身を置いていますが、第一次ブラウザ戦争の熱狂を間近で見てきました。Netscapeが革新的な機能を次々と打ち出し、ウェブが爆発的に進化していたあの頃、MicrosoftがIEを無料で配布し始めたときは、誰もがその影響の大きさに戦慄しました。最終的にNetscapeが衰退していく様は、まさに大企業が市場をいかに支配し得るかを示す冷徹な教訓でした。

Google Chromeが登場した時、当初は「またMicrosoftのような独占が進むのか」と懸念する声もありましたが、そのオープンソース性や圧倒的な高速性、そして当時のIEの停滞ぶりから、多くの開発者やユーザーがChromeを支持しました。私もその一人でした。しかし、今振り返ると、その時点からすでにGoogleのウェブ支配への道筋は始まっていたのかもしれません。歴史は繰り返す、という言葉を痛感しています。

第4章 登場人物紹介：デジタル世界の光と影を担う者たち – Players in the Plot, Heroes and Hots, Villains in the Vault

主要なプレイヤーたち

  • Google (Alphabet Inc.) 🌐🏢

    世界最大の検索エンジン、ブラウザ（Chrome）、モバイルOS（Android）、広告プラットフォームを運営する巨大IT企業。かつて「Don't be evil（悪しきをなさず）」を掲げたが、現在はその理念と行動の乖離が指摘されている。本論文では、オープンウェブを中央集権化へと導く主要な推進者として描かれます。

  • Mozilla Corporation (Mozilla) 🦊🔥

    オープンソースのFirefoxブラウザを開発・提供する非営利団体Mozilla Foundationの子会社。オープンウェブとユーザープライバシーの擁護を掲げるが、Googleからの検索エンジン契約による収益に大きく依存しているため、その独立性がしばしば疑問視される。本論文では、Googleの行動に追従した側面も指摘されます。

  • Apple Inc. 🍎📱

    iPhone、Macintoshなどを開発する世界的なテクノロジー企業。Safariブラウザを開発し、Webkitエンジンをオープンソースとして提供している。しかし、自社エコシステムへの囲い込み戦略も強く、ウェブ標準化の議論においてはGoogleと連携することもあれば、対立することもある。本論文では、Googleと同様にXSLT実装に問題を抱えていると指摘されます。

  • Microsoft Corporation 💻🎮

    Windows OS、Edgeブラウザなどを開発する巨大IT企業。かつての「第一次ブラウザ戦争」の主役であり、その独占的慣行は批判を浴びた。本論文では、Googleの行動をMicrosoftの過去の戦略と比較する際の重要な参照点となる。近年はオープンソースへの姿勢を軟化させている。

  • W3C (World Wide Web Consortium) 🤝🌐

    World Wide Webで使用される標準技術を策定する国際的な団体。Tim Berners-Leeによって設立され、ウェブのオープン性と相互運用性を重視している。しかし、その標準化プロセスは遅いと批判され、WHATWGの台頭により影響力が低下したと指摘される。

  • WHATWG (Web Hypertext Application Technology Working Group) ⚙️💨

    ウェブ技術の迅速な開発と標準化を目指すブラウザ開発者のコンソーシアム。W3Cの遅さに不満を持つ一部のメンバーによって設立された。しかし、本論文では、GoogleがWHATWGを事実上「ソックパペット（sock puppet）」として支配し、自社の利益に資する技術開発を主導していると強く批判される。

技術標準とプロトコル

  • XML (Extensible Markup Language) </>

    データの構造化と交換のための汎用マークアップ言語。柔軟性と相互運用性に優れ、ウェブの初期の分散型ネットワークの基盤を支えた。RSSやAtomフィードなど、多くのウェブ技術で利用されてきた。本論文では、Googleがこれを意図的に排除しようとしていると主張される。

  • XSLT (Extensible Stylesheet Language Transformations) 📜✨

    XMLドキュメントを別のXMLドキュメント（HTMLなど）に変換するための言語。クライアントサイドでの動的なコンテンツ生成やデータ表示に強力な能力を持つ。本論文の主要な焦点の一つであり、Googleがそのサポートを意図的に阻害していると非難される。

  • RSS (Really Simple Syndication) 📰🔔

    ウェブサイトの更新情報やニュースを配信するためのXMLベースのフォーマット。ユーザーはフィードリーダーを通じて、複数のサイトの最新情報を効率的に購読できた。Google Readerの閉鎖やFirefoxからのサポート削除など、Googleの集中化戦略の標的となった。

  • XMPP (Extensible Messaging and Presence Protocol) 💬🔗

    インスタントメッセージやプレゼンス（オンライン状態）情報の交換のためのXMLベースの分散型プロトコル。かつてはGoogle Talkなどでフェデレーション（異なるサーバー間での通信）が可能だったが、GoogleやFacebookがこの機能を停止し、自社サービスを囲い込んだ。

  • MathML (Mathematical Markup Language) ➕➖

    ウェブ上で数学的な式を記述するためのXMLベースのマークアップ言語。ブラウザのネイティブサポートは、数学コンテンツの表示に重要だったが、Google Chromeが一時的にサポートを削除した。

  • JSON (JavaScript Object Notation) {}

    人間が読み書きしやすく、機械が解析しやすいデータ交換フォーマット。JavaScriptとの親和性が高く、Webアプリケーションのデータ形式として広く普及している。本論文では、GoogleがXMLを排除し、JSONを優遇していると指摘される。

論文に登場する主な技術者たち

  • Dorian Taylor (ドーリアン・テイラー) 🧑‍💻✍️

    年齢不詳（2025年時点）。ウェブ開発者であり、XSLTの熱心な擁護者。GoogleによるXSLT削除提案に対し、GitHubの議論スレッドでその有用性を力強く主張した。クライアントサイドXSLTの専門家で、自身のウェブプロパティやプロジェクトでXSLTを多用している。

  • Tim Berners-Lee (ティム・バーナーズ＝リー) 👨‍🔬🌐

    1955年6月8日生まれ（2025年時点で70歳）。World Wide Webの発明者であり、W3Cの創設者。ウェブのオープン性と分散性を提唱し続けている。`keygen`要素の重要性や、自身のプロジェクト「Solid」においてウェブの集中化への抵抗を試みている。

  • Adam Barth (アダム・バース) 👨‍💻

    年齢不詳（2025年時点）。Googleのエンジニアで、2013年にXSLTの削除を最初に提案した人物の一人。その後の議論でも中心的な役割を果たす。

  • Mason Freed (メイソン・フリード) 👨‍💻

    年齢不詳（2025年時点）。Googleのエンジニアで、2025年に再びXSLT削除を推進している主要人物。WHATWGの議論スレッドでGoogleの意向を代表する形でコメントを行っている。

  • Anne van Kesteren (アンネ・ファン・ケステレン) 👨‍💻

    年齢不詳（2025年時点）。Mozillaの従業員（論文では「smaug」と記される）であり、WHATWGの活動に深く関与している。XSLT削除推進に関して、Mason Freedの動きを支持しているとされる。

  • Domenic Denicola (ドメニック・デニコラ) 👨‍💻

    年齢不詳（2025年時点）。Googleのエンジニアであり、WHATWGの活動におけるキーパーソン。Fetch APIなどの仕様策定に携わる。本論文ではGoogleの意向を反映する人物として言及される。

  • Dave Winer (デイブ・ワイナー) 👨‍💻✍️

    1955年5月11日生まれ（2025年時点で70歳）。RSSの「ゴッドファーザー」の一人。ブログやポッドキャスティングの先駆者として知られ、オープンな情報流通の重要性を訴え続けている。

コラム：舞台裏の顔と名前

論文を読んでいると、具体的な技術者の名前が度々出てくることに気づかされます。GoogleやMozillaといった大企業の内部で、どのような議論が交わされ、どのような人物が特定の技術の生死を決めているのか、普段なかなか知る機会はありません。

個人的には、彼らが個人の悪意に基づいて行動しているというよりは、企業としての戦略や、市場での競争原理、あるいは組織内のリソース配分といった、複雑な要因が絡み合って意思決定されているのだろうと想像します。しかし、それが結果としてウェブ全体の健全性や多様性を損なっているとすれば、やはりその責任は重いでしょう。彼らは単なるエンジニアであると同時に、ウェブの未来を形作る「アーキテクト」でもあるのです。彼らの選択が、私たちのデジタルライフに直接影響を与えることを肝に銘じたいと思います。

第5章 Google ChromeとWHATWG：ブラウザが「ユーザーエージェント」でなくなる時 – Chrome's Creepy Crawl, WHATWG's Wicked Wall, Agent's Awful Fall

ウェブブラウザは、私たちがインターネットの世界と対話するための最も重要なツールです。かつては、ユーザーの「代理人（ユーザーエージェント）」として、ウェブコンテンツを中立的に表示し、ユーザーの意図をウェブに伝える役割を担っていました。しかし、Google Chromeの圧倒的な市場支配、そしてWHATWGにおけるGoogleの影響力行使は、このブラウザの「中立性」を根底から揺るがしています。

Google Chromeは、その登場以来、高速性とシンプルさを武器に、瞬く間に世界で最も利用されるブラウザとなりました。しかし、この成功の陰で、Googleは検索サービスにおける圧倒的な優位性を利用し、事実上の独占状態を築き上げてきたと本論文は主張します。これは、かつてMicrosoftがInternet Explorerで行った手法と驚くほど似通っていますが、GoogleはChromeのオープンソース性（Chromium）を盾に、批判をかわすことに成功しました。

さらに重要なのは、ウェブ標準の策定プロセスにおけるGoogleの影響力です。本来、ウェブ標準はW3Cによって、多様なステークホルダー（関係者）の合意に基づいて慎重に策定されてきました。しかし、W3Cのプロセスが遅いと感じた一部のブラウザ開発者（Google、Apple、Mozillaなど）は、2004年にWHATWGを設立しました。

当初、WHATWGはウェブアプリケーションの迅速な開発を目的とし、W3Cの補完的な役割を担うように見えました。しかし、本論文の主張はより厳しいものです。数年後には、GoogleがWHATWGを事実上乗っ取り、自社の意向を反映するための「ソックパペット（sock puppet）」、つまり見せかけの独立性を持つ道具に変貌させたというのです。

その目的は明確です。W3Cがより一般的な関心のある機能を優先していたのに対し、WHATWGは「企業投資家の利益」に資するウェブ技術の開発を乗っ取ることが主目的となったと指摘されています。その証拠に、W3Cから生まれた最も物議を醸した標準の一つが、コンテンツ産業の利益を優先したとされる「暗号化メディア拡張機能（EME）」であったことは偶然ではないとまで言及しています。

このGoogleとWHATWGの関係は、ブラウザがもはや単なる「ユーザーエージェント」ではなく、Googleのエコシステムを強化し、ユーザーの行動を管理するための「支配の道具」へと変質していることを示唆しています。Manifest V3のような、広告ブロッカーの機能を制限するAPI設計は、その最たる例です。これは、セキュリティやプライバシーの向上を謳いながらも、実際にはGoogleの広告ビジネスモデルを保護し、ユーザーのプライバシーよりも企業の利益を優先する姿勢が露呈していると論文は指摘しているのです。

コラム：ブラウザが「私」の味方だった頃

私がまだ大学生だった頃、複数のブラウザを使い分けていました。Firefoxは拡張機能が豊富で、Operaは高速、そしてInternet Explorerは「とりあえず動く」といった具合です。それぞれのブラウザに個性があり、まるで「自分の好み」に合わせて道具を選んでいるような感覚でした。

しかし、Chromeが台頭してからは、多くの友人が「とりあえずChrome」と口にするようになりました。確かに便利で速い。でも、いつの間にか、ウェブの体験がChromeによって「均質化」されていくのを感じました。ある日、あるウェブサイトが「Chromeで最適化されています」と表示されているのを見て、ゾッとしたことがあります。まるで、Chromeでなければウェブを十分に楽しめないかのようなメッセージ。ブラウザは、いつの間にかユーザーの味方から、特定の企業の「推奨」ツール、いや、ほとんど「必須」ツールへと変わってしまったのかもしれません。

第6章 XML対Google：宣戦布告された標準化戦争 – XML's Epic Clash, Google's Greedy Gash, Standards in the Trash

本論文の核心的な主張の一つは、Googleが過去10年以上にわたり、XMLというオープンなデータフォーマットに対して「戦争」を仕掛けてきた、というものです。XMLは、その柔軟性と相互運用性から、かつてはウェブの基盤を支える重要な技術でした。しかし、Googleはこれを意図的に排除しようと画策していると論文は訴えます。

XMLは、1998年の登場以来、その冗長性と引き換えに、HTMLよりも高い柔軟性を提供し、様々な種類の文書を「インターネット対応」にすることを可能にしました。特に、XMLと組み合わせることで真価を発揮するのが、XML文書を別の形式に変換するXSLTです。

XMLの利点とXSLTの変換力は、当初は主に専門家の注目を集めました。しかし、世紀の変わり目には、RSSやAtomといったウェブフィードの登場を通じて、一般的なウェブユーザーにもその恩恵が届くようになります。これにより、ユーザーは複数のウェブサイトの更新情報を一元的に把握できるようになり、ウェブは分散型ソーシャルネットワークとしての側面を強めました。ブログのバックボーンを支え、異なるプラットフォーム間の情報集約を可能にしたのです。

しかし、Googleは2013年以降、このXMLをベースとしたオープンなエコシステムを意図的に破壊しようとしてきました。その具体的な行動は多岐にわたりますが、本論文は特に以下の点を強調しています。

  • Google Readerの閉鎖（2013年）: 広く利用されていたRSSフィードアグリゲーターの廃止は、RSS利用者に大きな打撃を与え、分散型情報収集のインフラを弱体化させました。

  • XMPPフェデレーションの閉鎖（2013年）: Google Chatサービス間のXMPPフェデレーション（異なるサーバー間での通信）を停止し、Facebookも追随したことで、分散型メッセージングの可能性が大きく後退しました。

  • XSLTサポートの削除提案（2013年以降）: GoogleはChromeからXSLTのサポートを削除することを繰り返し提案してきました。これは、新しいXSLTバージョン（2.0や3.0）が存在し、より強力で安全になっているにもかかわらずです。論文は、これが「リソース不足」や「セキュリティ問題」という口実の下で行われていると批判し、実際には宣言的なクライアントサイド変換を妨害し、JavaScript依存を強める意図があると見ています。

  • MathMLサポートの削除（2013年）: Chromeが一時的にMathMLのサポートを削除したことは、ウェブ上での数学コンテンツの表示を困難にし、特定のフォーマットへの依存を促しました。

  • Fetch APIとJSONの優遇（2015年）: XMLHttpRequestの後継として導入されたFetch APIは、XMLドキュメントの処理方法について言及が著しく少なく、代わりにJSONを優先する傾向が明確になりました。これは、JavaScriptとの親和性が高いJSONへの移行を事実上推奨し、XMLの存在感を希薄化させるものです。

本論文は、これらの行動が単に技術的嗜好の問題ではなく、Googleが「オープンウェブ」の定義と、そこで許容される技術を自ら決定しようとする明確な意志の表れであると警鐘を鳴らしています。もしGoogleが特定の技術を排除し、自社に都合の良い技術のみを「標準」として押し付けることができれば、ウェブは真の意味でのオープンな空間ではなく、巨大企業の管理下に置かれた「 walled garden（囲い込まれた庭） 」へと変貌してしまうでしょう。

Dorian Taylor氏の擁護論が示すように、XMLとXSLTは依然として強力で、ウェブの分散性や効率性向上に貢献できる可能性を秘めています。特に、LLMスクレイパーがXMLの扱いに問題を抱えるという点は、XML+XSLTが自己保護の手段となりうるという新たな視点をも提供しています。

コラム：XMLの思い出と、その「重さ」

私が社会人になりたての頃、ウェブの世界ではXMLがとても流行していました。特に、企業間のデータ連携では「XMLを使えば何でも繋がる！」といった雰囲気があったほどです。私もXSLTを使い、XMLデータからHTMLを生成するシステムを組んだ経験があります。宣言的に書けるXSLTは、慣れると非常に強力で、複雑な変換もスマートに記述できました。

しかし、一方で「XMLは冗長で重い」「ブラウザでのパース（解析）が遅い」といった声も上がっていました。特に、スマートフォンが登場し、より高速で軽量なウェブ体験が求められるようになると、JSONのシンプルさが開発者の間で急速に支持されるようになりました。私自身も、手軽さからJSONを使う機会が増えていきました。ただ、それは「XMLが不要になった」ということではなく、「使い分け」の問題だったはずです。Googleが、その使い分けの選択肢すら奪いにかかっていると聞くと、やはり看過できない問題だと感じます。

第7章 疑問点・多角的視点：悪意か、進化か、それとも必然か？ – Doubts and Debates, Malice or Fate, Evolution's Elusive Gate?

詳細を見る

本論文は、Googleの行動を「意図的な悪意」に基づくと強く批判しています。しかし、その主張をより多角的に、そして客観的に理解するためには、いくつかの重要な前提を問い直し、異なる視点からも考察することが必要です。

意図と結果の乖離

  • 論文はGoogle Readerの終了やXMPPの機能停止をGoogleの悪意の表れとしますが、これらのサービス終了は、ユーザー習慣の移行（例：TwitterやFacebookなど集中型SNSへのシフト）、サービスの収益性低下、メンテナンスコストといった、複合的な要因が絡んでいる可能性も否定できません。結果としてウェブの集中化を促進したとしても、その「意図」は常に最初からウェブを支配することにあったと断定できるでしょうか？ Googleがそのユーザーベースを維持・収益化しようとした結果、集中化が進んだという見方もできます。

XML/XSLTの特異性への過度な焦点

  • 本論文はXML/XSLTに焦点を当てますが、ウェブのオープン性に対する脅威はこれら特定の技術に限定されるのでしょうか？ たとえば、Googleが推進するWeb Components、WebAssembly（WASM）、Progressive Web Apps（PWA）などの技術スタックが、分散型ウェブの理念とどのように共存し、あるいは衝突するのか、より広範な視点が必要ではないでしょうか。

  • JSONの台頭は、JavaScriptとの親和性や軽量性、開発の容易さなど、技術的なメリットも大きく、必ずしもGoogleの圧力だけで普及したとは言い切れません。多くの開発者がJSONを好んで選択したという、開発者コミュニティの自然な傾向も考慮すべきでしょう。

技術的合理性の評価

  • Fetch APIにおけるJSONの採用、HTTPSの推進、Manifest V3など、集中化を招くとされるGoogleの技術的選択について、セキュリティの向上、パフォーマンスの最適化、開発効率の改善といった、「技術的な合理性」からの評価も考慮すべきではないでしょうか。例えば、HTTPSの強制は、中間者攻撃を防ぎ、ユーザーのプライバシー保護に貢献するという側面も持っています。それらの合理性とオープン性・分散性のトレードオフについて、より深い議論は可能かもしれません。

Mozillaの役割の複雑性

  • 論文はMozillaがGoogleに追従した側面を指摘しますが、Mozillaの財政的なGoogleへの依存関係（検索エンジン契約）以外の要因、例えば開発リソースの制約、市場からの圧力、あるいは限られたリソースの中で「現実的な」選択を迫られた結果、一部でGoogleの技術動向に合わせざるを得なかったという、Mozilla自身の戦略的判断があった可能性はないでしょうか。

対抗策の現実性

  • XML/XSLTの再活性化や「不平を言う」「代替案を構築する」といった提言は、Googleのような巨大プラットフォームに対して、どの程度の現実的インパクトを持つのでしょうか？ より大規模なムーブメントや、政府による強力な規制的介入なしに、技術コミュニティ単独で流れを変えることは本当に可能なのでしょうか？

これらの疑問点は、Googleの行動を単純な「悪」として断じるのではなく、より複雑な市場の力学、技術の進化、そしてユーザーの行動の変化といった多岐にわたる要因が絡み合って現在のウェブの状況が形成されているという理解を深めるためのものです。もちろん、これらの点がGoogleの責任を軽減するわけではありませんが、問題の本質をより深く掘り下げ、効果的な解決策を導き出すためには不可欠な視点と言えるでしょう。

コラム：複雑な感情

この記事を書きながら、私自身も複雑な感情を抱きました。Googleは、私たちが日々利用する便利なサービスの多くを提供してくれている恩恵があるからです。検索、地図、Gmail、YouTube…。これらがなければ、今の生活は考えられないほどです。

しかし、その便利さの裏で、見えない形で私たちの選択肢が狭まり、情報がフィルターされ、行動が監視されているとしたら、それはやはり看過できない問題です。技術の進歩は、必ずしも人々の自由と幸せに直結するわけではない。むしろ、使い方を間違えれば、より強力な支配の道具になり得るのだと改めて感じました。

この議論は、Googleを「悪者」として単純に断罪することよりも、ウェブという公共財の未来を、私たち自身がどう望むのか、という問いを私たちに突きつけるものだと考えています。

第二部：支配と抵抗のメカニズム

第8章 致命的な転換点：2013年以降の破壊的年表 – Turning Tides of 2013, Destruction's Dreadful Dream

ウェブの歴史において、Googleによるオープンウェブへの戦略的侵攻が明確な形を帯び始めたのは、おそらく2013年であったと本論文は指摘しています。この年は、GAFAM（Google, Apple, Facebook, Amazon, Microsoft）といった巨大テック企業が、相互運用性に関する「手綱を引き締め」始めた、まさに転換点でした。偶然にも、Operaブラウザが独自のPrestoエンジンを放棄し、Chromiumベースへと移行した年でもあります（この詳細については、後述の「補足10：代替ブラウザの台頭」で触れます）。

以下に、その後の数年間でGoogleが実行または試みた、オープンウェブを弱体化させる一連の重要な行動を示します。

  • 2013年 - Google Readerの閉鎖: 📚🔚

    広く利用されていたウェブフィードアグリゲーター（RSSおよびAtomフィード向け）であるGoogle Readerがサービスを終了しました。これは、多くのユーザーがRSSから離れるきっかけとなり、分散型情報収集のインフラを大きく損なう結果となりました。本論文はこれを、ウェブの集中化へ向けたGoogleの最初の大きな一歩と見ています。

  • 2013年 - Google ChatサービスのXMPPフェデレーション閉鎖: 💬🚫

    Googleは、Google Chatサービス間のXMPPフェデレーション機能を停止しました。これにより、異なるプロバイダー間のオープンなリアルタイム通信が制限され、ユーザーはGoogleのクローズドなエコシステムに閉じ込められることになります。Facebookも翌年にMessenger製品で同様の措置を取りました。

  • 2013年 - XSLTの削除提案（最初期）: 📜💥

    GoogleはChromeからXSLTのサポートを削除することを初めて提案しました。この提案は当時あまりにも不評で、5年後（2018年）になっても反対コメントが寄せられるほどでした。しかし、この最初の試みが、GoogleのXSLTに対する長期的な敵意を示唆しています。

  • 2013年 - MathMLサポートのChromeからの削除: ➗❌

    Chromeに導入されたばかりのMathMLサポートがGoogleによって削除されました。ウェブ上で数学的な式を記述するための重要な標準技術が、Googleの意向によって一時的に排除されたのです。ブラウザにMathMLサポートが戻るには、その後10年もの歳月を要しました。

  • 2015年 - Fetch APIの導入とJSONの優遇: 📦✨

    WHATWGは、XMLHttpRequestの現代的な代替としてFetch APIを導入しました。新しい仕様では、XMLドキュメントの処理方法に関する言及が著しく欠落しており、代わりにJSONが優先される形となりました。これは、ウェブアプリケーションにおけるデータ交換のデファクトスタンダードをJSONへと明確にシフトさせる動きでした。

  • 2015年 - SMILの非推奨化提案: 🖼️❌

    Googleは、SVGにおける宣言的なアニメーションとインタラクティブ性の標準であるSMILの非推奨化を提案しました。本論文の著者は、SMILの有用性を強く主張し、非推奨化すべきではないと反論しています。

  • 2015年 - Accelerated Mobile Pages（AMP）プロジェクトの発表: ⚡️📱

    Googleは、モバイルでのウェブページの読み込みを高速化する方法としてAMPを発表しました。しかし、これは結果的にGoogleのような大規模なCDNを活用してコンテンツをキャッシュ（そしてオプションでプリレンダリング）することに大きく依存しており、ウェブコンテンツの中央集権化を促進しました。本来、レスポンシブウェブデザインや画像最適化技術（srcset属性）は既に存在しており、モバイルページの遅延の主な原因は「ウェブ肥満危機（web obesity crisis）」にありました。AMPは、Googleのサーバーを通じて全ての情報を集中させ、メトリック収集や広告配信、ユーザープロファイリングを容易にするためのものであったと論文は批判しています。

  • 2015年 - `keygen`要素の廃止意図の発表: 🔑🚫

    クライアントとサーバー間の安全な通信のための暗号キーペア生成を簡素化した、あまり知られていないが強力なセキュリティ機能である`keygen`要素をGoogleは廃止する意図を発表しました。これは、ユーザー証明書の簡素化された取り扱いを妨げ、相互認証を困難にする動きであり、Webの発明者であるTim Berners-Lee[TBL]もその廃止に強く反対しました。これは、World Wide Webの集中化と、その結果としての複雑化への対応として生まれたGeminiプロトコルの特徴の一つである軽量な相互認証とも関連しています。

  • 2018年 - MozillaがFirefoxからRSSサポートを削除: 🦊📰❌

    Mozillaは、Firefoxバージョン64からRSSサポートを削除し、ブラウザ内でRSSを開くことを積極的に禁止しました。公式の理由は「Live Bookmarks」機能の新しいアーキテクチャへの移植が困難であったとされますが、論文はこれを、Mozillaが「Googleの統制された反対派」として振る舞い、Googleが望まないウェブフィードを排除するための「言い訳」であったと厳しく批判しています。

  • 2019年 - ブラウザ拡張機能マニフェストV3の発表: 🛡️⚙️

    Googleは、ブラウザ拡張機能を「より安全にする」ための多くの変更を含むマニフェストV3の作業を開始しました。しかし、導入された変更の一部は、主に広告ブロッカーの動作を妨げることを目的としていることがすぐに明らかになりました。これは、Chromeがもはや「ユーザーエージェント」として機能せず、Googleのツールとしての側面を強めている一例です。この変更はXML/XSLTとは直接関連しませんが、クライアントサイドのカスタマイズ性を奪い、Googleの支配を強化する動きとして言及されています。

  • 2023年 - Googleのチャットボットが「Bard」から「Gemini」に改名: 🤖♊

    Googleはチャットボットの名前をBardからGeminiに変更しました。これにより、4年前から存在していた独立した同名のプロトコル（Geminiプロトコル）を完全に「食い潰す」形となりました。本論文はこれを「おそらく偶然」としつつも、過去15年間におけるGoogleの意図しない（あるいは意図的な）オープンウェブへの攻撃の一例として示唆しています。

  • 2023年 - Web環境の整合性APIの提案: 🔒🕸️

    GoogleはWeb環境の整合性APIを提案しました。これは、ブラウザを「ユーザーエージェント」から、より「企業が管理するスパイウェア」へと変質させようとする動きと見なされています。ウェブサイトがブラウザとユーザー環境が「信頼できる」ものであることを確認できるようにするという名目ですが、実際には、ユーザーの自由なカスタマイズや、広告ブロックなどのツール利用を困難にする可能性があります。

  • 2023年 - JPEG XLサポートの終了: 📸❌

    Googleは、わずか2年前に導入された画像フォーマットJPEG XLのサポートを終了しました。これは、競争力のある圧縮率（ロスレスとロッシーの両方）、プログレッシブデコード、透明性、アニメーションといった優れた特徴を持ち、従来のJPEG、PNG、GIF形式を置き換える可能性を秘めていたものです。本論文は、JPEG XLがXMPメタデータをサポートしている点を除けばXMLに直接関係ないとしつつも、ホスティングと帯域幅のコスト削減に寄与するであろうオープンかつインディーなウェブを阻害する動きであるとして非難しています。

  • 2023年 - HTTPSの強制的な採用推進: 🔐🌐

    Googleは長年にわたり、プレーンなHTTPウェブサイトの検索順位を低下させ、HTTPSの採用を推進してきました。セキュリティの向上という名目は理解できますが、本論文は、GoogleがLet's Encryptのような無料の証明書発行機関への依存を高め、最終的に証明書発行をGoogle自身が独占する可能性を危惧しています。

  • 2025年 - Chromeルートプログラムポリシーの変更発表: 📜🔄

    GoogleはChromeルートプログラムポリシーの変更を発表し、2026年までに証明書による特定の拡張キー用途（非サーバー用途）のサポートを停止する予定です。これにより、相互認証（クライアントとサーバーの両方の役割を含む）が効果的に強制終了されると論文は指摘しています。これは、`keygen`要素の抑制テーマが再び浮上した形です。

  • 最近 - XSLT削除の再試行とコミュニティの反発: 📜🔄💥

    RSSフィードの復活の兆しが見え始め、ユーザーが企業サイロ（Google）に対して懐疑的になり始めたタイミングで、GoogleはWHATWGをソックパペットとして利用し、XSLTを削除するための別の試みを実行しました。Chromiumの対応する問題がWHATWG GitHubの問題の前に作成されたことから、この動きがGoogleからのトップダウンの指示であったことが示唆されます。しかし、この問題に対する圧倒的にネガティブな反応が寄せられ、議論はロックされました。Googleが「リソースがない」と主張する一方で、誰も望まないLLMチャット統合のような機能に十分な資金を費やしていることが指摘され、その言い訳の薄っぺらさが露呈しました。GoogleとAppleのXSLT実装が、最近「境界線上の虐待問題」の報告を受けたフリーソフトウェアライブラリに依存していることも明らかになりました。

これらの行動を時系列で追うことで、Googleが単なる技術的選択ではなく、ウェブの基盤構造そのものを、自社の利益のために「再構築」しようとしているという本論文の主張が、より鮮明に浮かんできます。

コラム：消えゆく選択肢の痛み

私にとって、この年表を追うことは、まるで昔の友人が一人、また一人と姿を消していくのを見ているような感覚です。Google Readerの閉鎖は、まるで長年使っていた図書館が突然閉鎖されるような喪失感でした。RSSフィードで情報を得る習慣は、まるで個人でキュレーションする「小さな庭」のようなもので、その自由さが心地よかったのです。それがGoogleという「大きな公園」に吸収されていく中で、その庭は失われ、公園の遊具の配置もGoogleの都合の良いように変えられていく。そんな寂しさを感じずにはいられません。

特に、技術的な理由でなく「ポリシーの選択」として特定の技術が排除されるという点は、開発者として非常に心を痛めます。私たちが学んできた技術、大切にしてきた標準が、ある日突然、巨大企業の都合で「不要」と烙印を押される。それは、技術者の矜持を踏みにじる行為にも映るのです。

第9章 消し去られた機能たち：RSS、XMPP、MathML、そしてkeygenが語るもの – Features Faded Away, RSS's Rueful Decay, XMPP's Exiled Day

Googleによるウェブの集中化は、特定の技術標準のサポートを縮小または完全に廃止する形で具現化されてきました。本章では、その中でも特に象徴的な「消し去られた機能たち」であるRSS、XMPP、MathML、そして`keygen`要素に焦点を当て、それらがオープンウェブにとってなぜ重要であり、その廃止が何を意味するのかを深く掘り下げます。

9-1. RSSとAtom：分散型情報流通の旗手

RSS (Really Simple Syndication)とAtom (Atom Syndication Format)は、ウェブサイトの更新情報やニュースコンテンツをXML形式で配信するための標準フォーマットです。これにより、ユーザーは「フィードリーダー」と呼ばれるアプリケーションを通じて、複数のウェブサイトの最新情報をまとめて効率的に購読することができました。ウェブサイトを巡回することなく、お気に入りのサイトのニュースや更新情報を常に把握できる画期的な仕組みでした。

RSSは、21世紀初頭の分散型ソーシャルネットワークを特徴づけるブログのバックボーンを支え、Pingbackのような相互接続技術も支えていました。情報は中央のプラットフォームに集約されるのではなく、個々のウェブサイトがそれぞれ情報を発信し、ユーザーが自由に集計するモデルでした。

しかし、Googleは2013年に、その最も広く利用されていたフィードアグリゲーターであるGoogle Readerを閉鎖しました。この決定は、多くのユーザーから激しい反発を受けましたが、覆ることはありませんでした。この動きは、ユーザーをGoogleの代替サービスや、TwitterやFacebookといった中央集権型ソーシャルメディアプラットフォームへと向かわせる強力な圧力となりました。本論文は、Google Readerの閉鎖を、RSSを廃止し、ウェブの集中化を推進するGoogleの「意図的な努力」の一環と見ています。

さらに、Mozillaも2018年にFirefoxからRSSサポートを削除し、ブラウザ内でRSSフィードを直接開くことをできなくしました。これは、Googleの意向に追従した動きであると論文は批判しています。

それでも、RSSはまだ生きています。推定5億以上のウェブサイトがWordPressを使用しており、それらのサイトは全てRSSフィードを提供しています。FediverseのほとんどのプラットフォームもRSSフィードを提供しており、中にはFriendicaのようにそれらをインポートできるものもあります。そして、最も重要なのは、ポッドキャストの基本的な構成要素がRSSであるということです。「RSSがなければポッドキャストではない」と言われるほど、世界中で数億人、数十億人ものユーザーがいるマルチメディア配信フォーマットを支えています。人々がウェブの集中化がいかに壊滅的であったかを認識し始めている今、RSSフィードは復活の兆しを見せています。

9-2. XMPP：オープンなリアルタイム通信の挫折

XMPP (Extensible Messaging and Presence Protocol)は、インスタントメッセージングやプレゼンス（オンライン状態）情報の交換のためのXMLベースのオープンな分散型プロトコルです。その最大の特徴は、異なるサーバー間での「フェデレーション（federation）」、すなわち相互接続性を持つ点でした。これにより、Google Chat（旧Google Talk）のユーザーは、別のXMPPサーバーを利用する友人と直接メッセージをやり取りすることが可能でした。これは、メールのように、プロバイダーを問わず通信できる自由を意味しました。

しかし、Googleは2013年にGoogle Chatサービスと他のXMPPサーバー間のフェデレーション機能を停止しました。翌年にはFacebookも同様の措置をMessenger製品に適用しました。これにより、これらの巨大プラットフォームは、自社のチャットサービスを外部から隔離された「walled garden」へと変貌させ、ユーザーをそれぞれのクローズドなエコシステムに閉じ込めました。オープンなメッセージングプロトコルが、巨大企業の囲い込み戦略の犠牲となった象徴的な事例です。

9-3. MathML：学術コンテンツの表現を阻害

MathML (Mathematical Markup Language)は、ウェブ上で数学的な式を記述するためのXMLベースのマークアップ言語です。科学、技術、工学、数学（STEM）分野の学術コンテンツにとって、複雑な数式を正確かつアクセシブルに表示するための不可欠な標準でした。ブラウザのネイティブサポートがあれば、プラグインなしで数式を美しくレンダリングでき、ウェブ上の知識共有を促進します。

しかし、Googleは2013年にChromeに導入されたばかりのMathMLサポートを削除しました。この決定は、ウェブ上の数学コミュニティから大きな批判を浴びました。ブラウザにMathMLサポートが戻るには、その後10年もの歳月を要し、その間は外部企業（例: MathJaxのようなJavaScriptライブラリ）がそのギャップを埋める必要がありました。この動きもまた、Googleが特定のオープン標準への支援を躊躇し、結果としてウェブ上の多様なコンテンツ表現を阻害した事例として挙げられます。

9-4. `keygen`要素：ユーザー主導のセキュリティ機能の終焉

`keygen`要素は、HTML5の一部として標準化されていた、クライアントとサーバー間の安全な通信のための暗号キーペアの生成を簡素化するあまり知られていないが強力なセキュリティ機能でした。これは、ユーザー自身がブラウザを通じて安全な鍵を生成し、それをウェブサイトとやり取りするプロセスを簡素化することを目的としていました。これにより、相互認証（クライアントとサーバー双方が互いを認証する仕組み）がより容易になる可能性を秘めていました。

この要素は、ウェブの発明者であるTim Berners-Lee[TBL]氏が、自身の分散型ウェブプロジェクト「Solid」で重視するような、より分散的でユーザー中心の認証システム構築に役立つ可能性を持っていました。しかし、Googleは2015年にこの`keygen`要素の廃止意図を発表し、後にChromeから削除しました。そして2025年には、Chromeのルートプログラムポリシー変更により、サーバー以外のあらゆる証明書利用（相互認証など）が効果的に終了されることになります。

論文は、この`keygen`要素の抑制が、Googleがセルフホスト型電子メールに対する「戦争」の一環であると推測しています。GoogleがGmailのような中央集権型サービスを通じてユーザー認証と通信を完全に支配したいと考えている証拠であると指摘しているのです。ユーザーが自身の暗号鍵を容易に管理し、利用できる機能が排除されることは、デジタル主権の観点から深刻な懸念をもたらします。

これら一連の「消し去られた機能たち」は、個々の技術的判断として片付けられるものではなく、オープンで分散的なウェブの精神を体系的に解体し、Googleのエコシステムにユーザーとデータを囲い込むという、より大きな戦略の一部として機能していると本論文は強く訴えています。

コラム：私が目撃した「鍵」の喪失

セキュリティの世界に少し足を踏み入れたことがある私にとって、`keygen`要素の廃止は、単なるHTML要素の削除以上の意味を持っていました。それは、ユーザーが自身のデジタルアイデンティティをより直接的に管理し、ウェブ上で安全な関係を築くための、小さな、しかし重要な「鍵」だったのです。もちろん、専門家でない限り、その重要性を理解することは難しかったかもしれません。

しかし、こうした目立たない、しかし本質的な機能が次々と「合理化」の名の下に消えていくのを見るにつけ、ウェブが私たちユーザーのためのものではなく、巨大企業の利益のためのものへと変質していくのを感じずにはいられません。かつてティム・バーナーズ＝リーが夢見た「ユニバーサルリンク情報システム」は、今や「ユニバーサル監視・広告配信システム」へと変わってしまったのでしょうか。そんな問いが、私の心に深く刻まれています。

第10章 Fetch APIとJSONの台頭：データ形式が示す支配の方向性 – Fetch's JSON Jive, Control's Cruel Drive, Data's Doomed Dive

ウェブアプリケーションの進化は、データの交換方法にも大きな変化をもたらしました。かつては、非同期通信の主役であったXMLHttpRequestが、その名の通りXMLデータを扱うことが多かったのに対し、現代のウェブではFetch APIとJSONがデファクトスタンダードとなっています。本論文は、この変化が単なる技術トレンドではなく、Googleのウェブ支配戦略の一環であると指摘しています。

10-1. XMLHttpRequestからFetch APIへ：進化の裏に潜む意図

XMLHttpRequest（XHR）は、ウェブページをリロードせずにサーバーとデータをやり取りする「Ajax」技術の中核を担い、今日のインタラクティブなウェブアプリケーションの基礎を築きました。しかし、そのAPIはやや複雑であり、より現代的で柔軟な代替手段が求められていました。そこで登場したのが、2015年にWHATWGによって導入されたFetch APIです。

Fetch APIは、よりシンプルでプロミスベースのインターフェースを提供し、開発者からは歓迎されました。しかし、本論文が指摘するように、Fetch APIの仕様には、XMLドキュメントの言及や管理方法が著しく欠けており、代わりにJSON形式のデータ取得が主眼に置かれています。これは、XMLが単に言及されていないだけでなく、「専用のドキュメント本体のプレゼンテーション方法を取得する」という点で、JSONが他の形式よりも優遇されていることを意味します。

もちろん、JSONがウェブアプリケーションの主要なデータ形式となった背景には、JavaScriptとのネイティブな親和性、軽量さ、そして開発の容易さといった正当な技術的理由が存在します。JSONはJavaScriptオブジェクトに直接マップされるため、データのパース（解析）や操作が非常に直感的です。このため、多くの開発者がXMLよりもJSONを好むのは自然な流れでした。

しかし、論文の主張は、この「自然な流れ」の背後に、Googleの意図的な誘導があったというものです。XMLがウェブの分散性を高める強力なツールであったのに対し、JSONは中央集権型APIとの連携に非常に適しています。Googleが自身の提供するAPI（例：Google Maps API、YouTube APIなど）でJSONを主要なデータ形式として採用することで、開発者は自然とJSON中心の開発を行うようになり、結果的にXMLベースのシステムから遠ざかっていきました。

10-2. JSON優遇がもたらす影響：分散化から中央集権化へ

このJSON優遇の動きは、ウェブエコシステムに以下のような影響をもたらしています。

  • XMLの衰退とXSLTの危機: Fetch APIがXMLを軽視し、ブラウザがXSLTのようなXML変換技術のサポートを怠る（あるいは削除を試みる）ことで、XMLを基盤とする技術（RSS、Atom、SVGのSMILなど）の利用が困難になります。これは、オープンで宣言的なデータ変換の可能性を狭めるものです。

  • JavaScript依存の強化: XMLのクライアントサイド処理や変換が難しくなることで、ウェブアプリケーションの構築はよりJavaScriptに強く依存するようになります。これにより、ElectronやNode.jsといったJavaScriptベースのツールキットが普及し、アプリケーションがより重く、複雑になる傾向があります。

  • 中央集権型APIへの依存: JSONは、Googleのような巨大企業が提供するRESTful APIとの連携に最適です。開発者がこれらのAPIに依存することで、ウェブのデータフローは少数のプラットフォームへと集中し、各プラットフォームがデータのアクセス、利用、そして収益化をコントロールできるようになります。

本論文は、HTMLテンプレートとXSLTを比較し、後者の持つ強力な宣言的変換能力を強調しています。たとえ個人的にXMLやXSLTを好まなくても、Googleがウェブ上で何が許容され、何が許容されないかを決定することの危険性を指摘しているのです。このデータ形式の選択は、単なる技術的な嗜好の問題ではなく、ウェブの「パワーバランス」と「制御権」を巡る重要な戦線であると言えるでしょう。

コラム：私が知るJSONの便利さと、その代償

プログラマーとして、JSONの便利さは痛いほどよくわかります。JavaScriptをメインで書く人間にとって、JSONはまるで母国語のようです。XMLのように複雑なパーシング（解析）も不要で、直感的にデータを扱えます。新しいプロジェクトを始める際、XMLとJSONのどちらを選ぶか問われれば、よほどの理由がない限りJSONを選ぶでしょう。正直、その「手軽さ」に私も魅了されてきました。

しかし、本論文を読んで、その便利さの「代償」について深く考えさせられました。個々の開発者にとっての効率性が、ウェブ全体の分散性やオープン性を犠牲にする可能性がある。そして、その効率性を「旗印」として、Googleのような巨大企業が巧妙に自社の支配を強化しているのかもしれないと。便利さと引き換えに、私たちは何を失っているのか。改めて立ち止まって考える必要がありそうです。

第11章 AMPとWeb環境の整合性API：パフォーマンスとセキュリティの仮面を被った中央集権化 – AMP's Amped-Up Lie, API's Sneaky Spy, Centralization's Sly High

Googleは、ウェブの利用者にとって有益に見える目的、すなわち「パフォーマンスの向上」や「セキュリティの強化」を掲げながら、実際にはウェブの中央集権化を強力に推進してきました。本章では、その典型的な事例であるAMP（Accelerated Mobile Pages）プロジェクトと、最近提案されたWeb環境の整合性APIについて深く掘り下げ、その背後にある真の意図を考察します。

11-1. AMP：高速化の恩恵と支配の代償

Googleが2015年に発表したAMP（Accelerated Mobile Pages）は、モバイルデバイスでのウェブページの表示速度を劇的に向上させることを目的としたオープンソースのフレームワークです。AMPページは、HTML、CSS、JavaScriptの使用に厳格な制約を設けることで、非常に軽量かつ高速な読み込みを実現します。さらに、Googleの検索結果にAMPページが表示される際には、GoogleのCDN（コンテンツ配信ネットワーク）から直接提供されるため、読み込み速度がさらに向上するとされました。

表面上は、ユーザーエクスペリエンスの向上という点で素晴らしい取り組みに見えます。しかし、本論文はAMPを「パフォーマンスとセキュリティの仮面を被った中央集権化」の典型例として厳しく批判しています。

  • 中央集権型CDNへの依存: AMPページがGoogleのCDNを介して提供されることは、ウェブコンテンツがGoogleのインフラストラクチャに集中することを意味します。これにより、Googleはコンテンツの配信をコントロールし、場合によってはプリレンダリング（事前読み込み）を行うことで、ユーザーの行動データをより広範に収集し、広告配信を最適化できるようになります。

  • 既存技術の軽視: AMP発表以前から、レスポンシブウェブデザインや画像のsrcset属性など、モバイルデバイス向けに最適化されたウェブページを作成するための技術は存在していました。また、多くのウェブページが遅い原因は、過剰なJavaScriptや広告スクリプトによる「ウェブ肥満危機（web obesity crisis）」にありました。AMPは、これらの既存技術や根本原因の解決を促すよりも、Googleが提供する特定のフレームワークとインフラへの依存を促すものでした。

  • Googleの利益最大化: 論文は、AMPが結果的にGoogleのメトリック収集を容易にし、広告配信を高速化し、ユーザープロファイリングを強化するためのツールとして機能したと主張します。つまり、Googleや他のテック巨大企業のサーバーを通じてすべてを集中させることを奨励するものです。

AMPは、表向きはユーザーの利便性を追求する「善意の」取り組みとして始まったかもしれませんが、その結果は、ウェブコンテンツの多様性と独立性を犠牲にして、Googleの支配力を強化することにつながったと分析されています。

11-2. Web環境の整合性API：ブラウザが「スパイウェア」になる日？

2023年にGoogleが提案したWeb環境の整合性API (Web Environment Integrity API - WEI)は、さらに深刻な懸念を提起しています。このAPIは、ウェブサイトがユーザーのブラウザ環境が「信頼できる」ものであることを確認できるようにするという名目で提案されました。例えば、ボットによる不正なアクセスや、マルウェアに感染したデバイスからのアクセスを検出するのに役立つとされています。

しかし、その裏で、本論文や多くのプライバシー擁護団体が警鐘を鳴らしているのは、このAPIがブラウザを「ユーザーエージェント」から「企業が管理するスパイウェア」へと変質させる可能性です。具体的には、以下のような懸念が挙げられます。

  • デジタル権利管理（DRM）の強化: コンテンツ提供者が、ユーザーのブラウザ環境が改ざんされていないか（例：広告ブロッカーがインストールされていないか、ブラウザのセキュリティ設定が「緩すぎないか」など）をチェックできるようになる可能性があります。これにより、企業は特定のコンテンツへのアクセスを制限したり、ユーザーの自由なカスタマイズを妨げたりする口実を得るかもしれません。

  • ユーザーの監視強化: ブラウザがユーザーの環境に関する詳細な情報をウェブサイトに提供するようになることで、ユーザーのデバイスやソフトウェア構成に関するデータ収集が強化され、より詳細なプロファイリングが可能になる可能性があります。これは、プライバシー侵害のリスクを高めるものです。

  • オープンソースと代替ブラウザへの脅威: WEIは、特定の「信頼できる」環境のみを許可する可能性があり、その「信頼」の基準はGoogleのような巨大企業によって決定されるかもしれません。これにより、オープンソースのブラウザや、ユーザーがカスタマイズした環境、あるいは古いデバイスからのアクセスが「信頼できない」と判断され、特定のウェブコンテンツにアクセスできなくなる恐れがあります。これは、ウェブの多様性とアクセシビリティを大きく損なうものです。

Web環境の整合性APIは、XML/XSLTのような特定の技術とは直接関連しないかもしれませんが、ウェブをより企業の管理下に置き、ユーザーの自由を制限しようとするGoogleの一貫した戦略を示すもう一つの例として、本論文はこれを非常に重要な動きと捉えています。

コラム：私が感じた「おせっかい」な便利さ

私は普段から、ウェブサイトの表示速度には人一倍気を遣っています。ユーザーが快適に情報にアクセスできることは、コンテンツ提供者としての責務だと考えているからです。だから、AMPが登場した当初は、純粋に「素晴らしい技術だ！」と感銘を受けました。

しかし、実際に利用してみると、GoogleのCDNからの強制的な配信や、独自のAMP形式への変換が必要な点が気になり始めました。「本当にユーザーのためなのか？それともGoogleのためなのか？」という疑問が頭をよぎるようになったのです。ウェブの高速化は確かに重要ですが、それが特定の企業の支配を強める手段となるのであれば、それはもはや「おせっかい」を通り越して「おしつけ」になってしまうのではないでしょうか。

最近のWeb環境の整合性APIの議論もそうです。セキュリティ強化は誰もが望むことですが、そのためにユーザーの自由やプライバシーが犠牲になるのであれば、それは「安全」なウェブとは呼べません。安全と自由のバランスを、私たちユーザーがどう選択していくか、真剣に考える時期に来ていると感じています。

第12章 XSLTへの執拗な攻撃：宣言的変換技術が標的とされる理由 – XSLT's Stubborn Siege, Google's Greedy Grudge, Transformation's Tragic Trudge

本論文は、GoogleがXMLを基盤とする技術、特にXSLTに対して、執拗な攻撃を仕掛けていると指摘しています。XSLTは、XMLドキュメントを別の形式（HTML、プレーンテキスト、あるいは別のXML）に変換するための強力な宣言的言語であり、ウェブの柔軟性と相互運用性を高める上で重要な役割を担ってきました。しかし、なぜGoogleはこれほどまでにXSLTを標的とするのでしょうか？

12-1. XSLTの真価とGoogleの「不都合」

XSLTが1998年にリリースされた際、それは様々な種類のドキュメントを「インターネット対応」にする画期的な技術でした。XSLTの変換力を利用すれば、あらゆる構造のXMLデータをウェブブラウザで直接表示可能なHTMLに変換することができました。特に、その後のウェブフィード（RSSやAtom）の普及において、XSLTはフィード自体をブラウザで閲覧可能にする上で不可欠な役割を果たしました（もちろん、MozillaがFirefoxからRSSサポートを積極的に削除するような「特別な努力」をしない限りですが）。

XSLTの利点は多岐にわたります。

  • 標準化されている: XSLTはW3Cによって策定されたオープンな国際標準です。

  • 宣言的である: 手順を記述するJavaScriptのような命令型言語とは異なり、XSLTは「何をするか」ではなく「どうあるべきか」を記述する宣言的な性質を持っています。これにより、コードの可読性が高く、保守が容易になります。

  • JavaScriptと直交する: XSLTはJavaScriptのエコシステムとは独立して存在するため、ウェブ開発者は特定のプログラミング言語にロックインされることなく、多様なツールを選択できます。

  • ドキュメント構造への整合性: XSLTは整形式のXMLドキュメント（またはHTMLドキュメント）に対して動作し、整形式のドキュメントしか生成できません。これにより、出力の有効性が低いレベルで保証されます。多くのHTMLテンプレート言語がターゲット言語の構文を「切り刻む」のに対し、XSLTは構造を維持します。

  • コスト削減の可能性: XSLTをクライアントサイドで利用すれば、サーバー側で複雑なHTMLを生成する必要がなくなり、ホスティングや帯域幅のコストを削減できる可能性があります。特に、多様なデバイス（デスクトップとモバイルなど）向けに異なる表示を提供する場合でも、一つのXMLデータソースから複数のXSLTスタイルシートを用いて効率的に変換できます。

しかし、本論文は、GoogleがこのようなXSLTの真価を「不都合」であると見なしていると主張します。なぜなら、XSLTのような強力なクライアントサイド変換技術が普及すれば、ウェブサイトはGoogleのサーバーや広告ネットワークへの依存度を下げ、より自律的になるからです。これにより、Googleのメトリック収集、ユーザープロファイリング、広告配信といった収益の柱が揺らぐ可能性があります。

12-2. 最新バージョンの無視と「リソース不足」の詭弁

Googleのエンジニアは、XSLT削除の理由として「ブラウザが20年以上にわたってXSLTの旧式バージョン（XSLT 1.0）に固執しており、セキュリティ上の問題がある」と主張しました。しかし、本論文はこれに対し、XSLTの新しいメジャーバージョン（XSLT 2.0が2007年、XSLT 3.0が2017年）が既にリリースされているという重要な事実を指摘しています。特にXSLT 3.0は、JSONデータの処理も可能であり、より強力で安全な機能を提供します。

にもかかわらず、Google（そしてApple）のブラウザは、これらの新しいバージョンを実装しようとせず、意図的に古いXSLT 1.0に「固執」してきたと論文は批判しています。これは「偶然でもリソース不足でもない。ユーザーの意志に反して、ウェブの分散化を意図的にボイコットする政策」の結果であるとまで断言しています。

さらに、Googleの「リソースがない」という言い訳に対して、論文は、数十億ドル規模の企業が、誰も望まないLLMチャット統合のような機能に巨額の資金を費やせるのに、XSLTの改善にリソースを割けないのは「完全に愚かな言い訳」であると一蹴しています。GoogleとAppleのXSLT実装が、フリーソフトウェアライブラリに依存しており、そのメンテナーが企業からの「搾取」を報告している点も、Googleのリソース不足という主張の信憑性を低下させています。

結局のところ、WHATWGのGitHubでのXSLT削除に関する議論は、あまりに否定的なフィードバックが多かったため、最終的にコメントが閉鎖される事態となりました。これは、削除が「コンセンサスによって推進された」かのように見せかけるGoogleの試みが失敗したことを示しています。

GoogleによるXSLTへの執拗な攻撃は、ウェブが単なる技術の集合体ではなく、誰がそのルールを決め、誰がその恩恵を享受するかという、権力闘争の舞台であることを浮き彫りにしています。この戦いは、ウェブが今後もオープンで多様な情報空間であり続けるか、それとも一部の巨大企業の管理下に置かれた閉鎖的なエコシステムとなるかを決定する、重要な試金石となるでしょう。

コラム：私がXSLTを愛する理由

私にとって、XSLTはまるで、どんなに複雑なパズルでも鮮やかに解きほぐしてくれる魔法の杖のような存在でした。特に、様々なフォーマットのデータを扱うプロジェクトでは、XSLTの宣言的な変換能力がどれほど強力であったか。例えば、クライアントから送られてくる異なるXML構造のデータを、サーバー側で統一された形式に変換したり、あるいはデータベースから取得したXMLデータを、そのままクライアント側でHTMLに変換して表示したりする際に、その真価を発揮してくれました。

JavaScriptで同じことをやろうとすると、冗長なコードになったり、メンテナンスが大変になったりすることが少なくありません。XSLTは、まさに「餅は餅屋」という言葉がぴったりの技術でした。だからこそ、Googleがこれを排除しようとしているのを見ると、まるでウェブの表現力の一部が奪われていくような、寂しさを感じるのです。本当に良い技術は、その存在理由がある限り、尊重されるべきだと私は信じています。

第13章 オープンウェブを守るために私たちにできること：見せる、声を上げる、そして築く – Defend with Delight, Raise Voices Right, Build Back the Byte

Googleによるウェブの集中化は、すでに進行中の現実です。しかし、私たちは無力ではありません。本論文は、この流れに抗い、オープンウェブを守るために、私たち一人ひとりができる具体的な行動を提案しています。それは、「見せる（Use It）」「声を上げる（Speak Out）」「築く（Build Alternatives）」という三つの柱に集約されます。

13-1. 見せる（Use It）：XMLとXSLTを積極的に活用する

最初の、そして最も直接的なステップは、実際にXMLとXSLTを使うことです。使われなければ、技術は「不要」と判断され、廃止される口実を与えてしまいます。逆に、活発に利用されていることが示されれば、ブラウザベンダーもそのサポートを無視できなくなります。

  • XML/XSLTを使用するサイトを訪れる: 現在でもXMLやXSLTを活用しているウェブサイトがあります。それらを積極的に訪問し、利用することで、その技術の存在意義を示しましょう。例えば、RSSフィードをXSLTでスタイリングして表示しているサイトなどです。

  • 自分のウェブサイトで活用する: もしウェブサイトを運営しているのであれば、この技術に頼る機会を探してみましょう。例えば、RSSフィードをXSLTでスタイリングして、ユーザーフレンドリーな形で提供する（多くのサイトがデフォルトでXML形式のRSSを提供していますが、XSLTでスタイルを適用することで、ブラウザで直接閲覧可能になります）。あるいは、データ可視化、サーバーサイドインクルードの代替、表形式データの整形、CSSの限界を補完するためのドキュメント構造調整など、XSLTには多様な応用例があります。

  • 学習し、共有する: XMLやXSLTの利用方法がわからない場合は、既存のチュートリアルや資料を活用して学びましょう。そして、新しい、興味深いXSLTの応用例を見つけたら、積極的にコミュニティに共有してください。知識の共有は、技術の生命線を維持する上で不可欠です。

13-2. 声を上げる（Speak Out）：ブラウザ開発者や巨大企業に働きかける

私たちの声は、巨大企業にとっては無視できない圧力となり得ます。沈黙は、現状への同意と見なされます。積極的に意見を表明し、行動を求めましょう。

  • 問題トラッカーやフォーラムで意見表明: 影響を受けるブラウザ開発者（Google Chrome、Mozilla Firefox、Apple Safariなど）の問題トラッカー（例: ChromiumのBugs、WHATWGのGitHubイシュー）で、XSLT削除の動きに反対票を投じ、コメントを投稿しましょう。変更が強行された場合でも、新しいチケットを開設し、XSLTサポートの復元、XSLT 3.0へのアップグレード、そしてプレーンなHTMLに対しても有効であることなどを要求し続けましょう。

  • ソーシャルメディアでの発信: X（旧Twitter）🔗やMastodonのようなソーシャルメディアで、この問題について投稿し、WHATWG、Google、Apple、Mozilla、Microsoft、Chrome、Safari、Firefox、Edgeなどの公式アカウントをタグ付けし、こうした変更が受け入れられないことを伝えましょう。XSLT抑制の選択が技術的理由やリソース不足によるものではなく、オープンウェブの表現力を妨害するための「政策的選択」であるという真実を広め、嘘が蔓延するのを防ぎましょう。

  • メディアへの働きかけ: 専門メディアや一般メディアに、この問題の重要性を伝え、記事として取り上げてもらうよう働きかけることも有効です。広く世論を喚起することが重要です。

13-3. 築く（Build Alternatives）：代替案を構築し、支持する

巨大企業の支配から逃れる最も確実な方法は、彼らのエコシステムに依存しない代替案を構築し、それを支持することです。

  • ポリフィルやライブラリの活用: GoogleによるXSLT削除が強行された場合（あるいは既に進行中ですが）、Saxon-JSのようなJavaScriptベースのポリフィル（ブラウザのネイティブ機能がない場合に、その機能をJavaScriptなどで再現するコード）を積極的に利用し、XSLTへの回帰の根拠を構築しましょう。これらはネイティブ実装ほど効率的ではないかもしれませんが、重要なウェブ技術としてのXSLTの存在感を維持し、将来的なネイティブ実装への圧力をかける手段となります。MathJaxがMathMLのネイティブ実装への架け橋となったように、ポリフィルも同様の役割を果たせます。

  • ブラウザ拡張機能の開発・利用: 純粋なXMLファイルやXSLTのブラウザ内表示をサポートする拡張機能の開発を検討したり、既存の拡張機能を積極的に利用しましょう。Firefoxは比較的オープンですが、Chromeの拡張機能API（Manifest V3）は制限が強化されているため、実装はより困難になる可能性があります。しかし、困難であっても挑戦し続けることが重要です。

  • 分散型ウェブ技術への投資: Fediverse（Mastodonなど）、Geminiプロトコル、IPFSといった、Googleのような中央集権型プラットフォームに依存しない分散型ウェブ技術への関心を高め、その開発を支援し、利用を促進しましょう。これにより、ウェブの多様性とレジリエンス（回復力）が向上します。

GoogleによるXSLT殺害の「10回目の試み」は、皮肉にもXSLTが復活するチャンスとなるかもしれません。ストライサンド効果のように、抑圧しようとする行為が、かえって注目を集め、ムーブメントを引き起こす可能性があるのです。

これらの行動は、個々の小さな一歩かもしれませんが、集まれば大きな力となり、ウェブの未来を私たちが望む方向に導く可能性を秘めているのです。

コラム：声が届くという希望

私は以前、あるソフトウェアの小さなバグを見つけて、開発元のフォーラムに報告したことがあります。最初は「こんな小さな声、届くのかな？」と半信半疑でした。しかし、数日後には開発者から返信があり、次のアップデートで修正されたのです。

この経験は、私の「声」が、たとえ小さくても、変化を起こせることを教えてくれました。Googleのような巨大企業相手では、もっと大きな声が必要でしょう。でも、一人ひとりが声を上げなければ、その大きな声は生まれません。GitHubのイシューで反対票を投じる、SNSで自分の意見を発信する。これらは決して無駄な行為ではありません。小さな波紋が広がり、やがて大きな潮流となることを、私は信じています。

第14章 今後望まれる研究：来るべきデジタル主権のためのロードマップ – Research Roads Ahead, Sovereignty's Spread, Future's Fearless Tread

Googleによるウェブの集中化は、単なる技術的な課題に留まらず、デジタル主権、情報アクセス権、そして民主主義の基盤にまで影響を及ぼす複合的な問題です。この複雑な状況を打破し、オープンで健全なウェブの未来を築くためには、多岐にわたる分野での研究が不可欠です。

14-1. 多角的アクター分析と戦略評価

  • GAFAM企業間の相互作用: Googleだけでなく、Apple、Meta（旧Facebook）、Amazon、Microsoftといった他の巨大テック企業が、それぞれどのような技術戦略やビジネスモデルを通じてウェブの集中化・非集中化に寄与しているか、その相互作用を含めた包括的な分析が必要です。例えば、AppleのApp StoreポリシーやWebKitエンジン戦略、Metaのソーシャルグラフ戦略が、ウェブのオープン性にどのような影響を与えているかといった研究が求められます。

  • 標準化組織のガバナンス改革: W3CとWHATWGのガバナンスモデルを詳細に比較し、企業の影響力を排除または抑制し、よりオープンで民主的な意思決定プロセスを再構築するための具体的な提案と、その実現に向けたロードマップの検討が重要です。

14-2. 法規制・政策的介入の有効性と影響

  • 各国の規制効果の検証: 米国（司法省の反トラスト訴訟など）、欧州（デジタル市場法 - DMA、デジタルサービス法 - DSA）、日本（デジタル市場競争会議など）といった各国の規制当局による巨大プラットフォーム規制が、ウェブのオープン性や競争環境に与える実際の影響に関する比較研究が不可欠です。規制が意図しない結果を招く可能性（例：大企業優遇、イノベーション阻害）も考慮に入れる必要があります。

  • デジタル主権に関する国際法・政策の研究: 国家レベルでのデジタル主権の概念を深掘りし、それが国際的なデータフロー、サイバーセキュリティ、そしてウェブのオープン性に与える影響について、国際法や国際政治学の視点からの研究が求められます。

14-3. 分散型技術エコシステムの深化と社会実装

  • 分散型ウェブ技術の普及要因と課題: ActivityPub（Fediverse）、Geminiプロトコル、IPFS（InterPlanetary File System）といった分散型ウェブ技術の普及における技術的課題（例：スケーラビリティ、パフォーマンス）、ユーザー受容性（例：使いやすさ、移行コスト）、経済的持続可能性に関する実証研究が必要です。

  • 非営利組織・コミュニティモデルの確立: 巨大テック企業の支配に対抗しうる、非営利組織やコミュニティ主導のウェブインフラ（例：オープンソース開発コミュニティ、分散型プロトコル推進団体）が、どのように持続可能な資金調達モデルとガバナンス構造を確立できるかに関する研究。

14-4. ユーザー側の意識変革と行動変容

  • ユーザーのデジタルリテラシーと意識: ウェブの集中化がユーザーのプライバシー、表現の自由、情報アクセスに与える影響に対する一般ユーザーの認識度、および分散型代替サービスへの移行意欲を左右する要因に関する社会心理学的研究が重要です。どのような情報提供や教育が、ユーザーの行動変容を促すのか。

  • 消費者運動としてのウェブ利用: Fair trade（フェアトレード）やEthical consumption（倫理的消費）のように、ウェブサービスやブラウザの選択において、企業の倫理的側面やオープンウェブへの貢献度を重視する「倫理的ウェブ利用」を促す運動の可能性に関する研究。

14-5. AI時代のウェブとセキュリティ

  • LLMとウェブスクレイピングの影響: ChatGPTのような大規模言語モデル（LLM）の台頭が、オープンウェブのコンテンツスクレイピング、自動コンテンツ生成、情報アクセスに与える影響について、集中化・分散化の両面から分析が必要です。特に、XML+XSLTがLLMスクレイパーに対して自己保護として機能しうるという論文の指摘の検証と、新たな防御策の開発が求められます。

  • Web環境の整合性API（WEI）の倫理的・技術的影響: WEIのような技術が、ユーザーのデバイスやブラウザの自由度を奪い、企業の監視と制御を強化する可能性について、技術的な実現可能性、倫理的な問題、そして代替手段に関する深掘りした研究が必要です。

これらの研究は、ウェブが単なる商業インフラではなく、私たちの社会、文化、そして民主主義の基盤であるという認識に基づいています。来るべきデジタル主権の時代に向けて、これらの研究が具体的なロードマップとなり、私たち自身の未来を形作るための羅針盤となることを強く望みます。

コラム：研究者としての責任

私は普段、技術の最先端に触れる仕事をしていますが、同時に、その技術が社会に与える影響についても常に考えるようにしています。特に、今回のGoogleとオープンウェブを巡る問題は、単に「コードを書く」という技術者の仕事の範囲を超え、社会科学や倫理学、法学といった多岐にわたる学術分野との連携が不可欠だと痛感しました。

研究者として、私たちはこの複雑な問題を多角的に分析し、客観的なデータに基づいてその本質を解明する責任があります。そして、その成果を社会に還元し、政策立案者や一般の人々が適切な意思決定を行うための「知」を提供することが、私たちの役割です。この論文が、新たな研究の火種となり、多くの研究者がこの分野に参入するきっかけとなることを願ってやみません。

第15章 結論（といくつかの解決策）：ウェブの未来を取り戻すための処方箋 – Wrap-Up with Wit, Solutions that Fit, Web's Winning Kit

本論文を通じて、私たちはGoogleが過去10年以上にわたり、いかにしてオープンで分散的なウェブの基盤を体系的に侵食し、自社の利益のために中央集権的な支配を確立してきたかを詳細に見てきました。これは、単なる技術的な偶然や市場の自然な進化ではなく、意図された「政策的選択」の積み重ねであると強く主張します。ウェブは、もはや私たちユーザーの「代理人」であるべきブラウザによって、私たち自身の自由が奪われかねない岐路に立たされています。

しかし、絶望するには及びません。ウェブの未来は、私たち自身の手に委ねられています。これまでの議論を踏まえ、ウェブの未来を取り戻すためのいくつかの具体的な解決策と、私たち一人ひとりの役割について改めて提言します。

15-1. 分散性の再評価と技術的抵抗

  • オープン標準の積極的利用と普及: XMLやXSLTのような既存のオープン標準が持つ真の価値を再認識し、それを活用したコンテンツ配信やアプリケーション開発を積極的に行いましょう。XSLT 3.0のように、現代的なニーズ（JSON対応など）にも応えられるバージョンがあることを広め、ブラウザベンダーにその実装を強く要求し続けるべきです。

  • 分散型ウェブ技術への移行: Mastodonに代表されるFediverse、Geminiプロトコル、IPFSなど、中央集権型プラットフォームに依存しない新しい分散型ウェブ技術の可能性を探り、積極的に利用・開発を支援しましょう。これらの技術は、ウェブの検閲耐性とレジリエンス（回復力）を高める上で不可欠です。

  • ブラウザの選択と拡張機能の活用: Google Chrome以外のブラウザ（Firefox、Brave、Vivaldiなど）の利用を検討し、オープンウェブを支持するブラウザを選びましょう。また、広告ブロッカーやプライバシー保護拡張機能など、ユーザーのコントロールを取り戻すための拡張機能を積極的に利用・支持すべきです。

15-2. ユーザー意識の変革とコミュニティの力

  • デジタルリテラシーの向上: 巨大テック企業のビジネスモデル、アルゴリズムの仕組み、そしてそれが私たちの情報摂取やプライバシーに与える影響について、一般ユーザーが深く理解するための教育と情報提供が不可欠です。私たちは「無料」サービスの真の代償を知るべきです。

  • 積極的な意見表明とロビー活動: 技術コミュニティだけでなく、市民社会団体、消費者団体、メディアなどが連携し、巨大テック企業や政府に対して、オープンウェブの維持、プライバシー保護、独占禁止法の厳格な適用を求める声を上げ続けるべきです。ソーシャルメディアや問題トラッカーでの意見表明は、その一歩となります。

  • 非営利組織・オープンソースプロジェクトへの支援: Mozilla FoundationやW3C、EFF（電子フロンティア財団）のような、オープンウェブの理念を掲げる非営利組織や、分散型技術の開発を行うオープンソースプロジェクトに対し、寄付やボランティア、コード貢献といった形で支援を行いましょう。

15-3. 政府と規制の役割

  • 独占禁止法の厳格な適用: 各国の政府や規制当局は、Googleのような巨大テック企業の独占的慣行に対し、より積極的に独占禁止法を適用し、競争を促進する措置を講じるべきです。プラットフォームの分割、相互運用性の強制、データポータビリティの義務化などが検討されるべきでしょう。

  • プラットフォーム規制の強化: 欧州のDMAやDSAのように、ゲートキーパーと見なされる巨大プラットフォームに対し、公正な競争を確保し、ユーザーの権利を保護するための新たな規制枠組みを構築・強化する必要があります。

  • オープン標準の推進と支援: 政府は、オープン標準の開発と採用を奨励し、公共機関のシステムにおいてオープン標準を優先的に利用する政策を推進すべきです。これにより、特定の企業エコシステムへの過度な依存を避け、デジタル主権を強化することができます。

ウェブの未来は、決して巨大企業だけの手に委ねられるべきではありません。それは、私たち利用者一人ひとりの選択と行動、そして社会全体の監視と協力によって形成されるべきものです。Googleによるウェブ支配の試みは、私たちにデジタル主権を取り戻すための、最後の、そして最も重要な機会を与えてくれているのかもしれません。この戦いは、すでに始まっています。私たちも、その戦いに参加する時なのです。

コラム：息子に伝えたいウェブの姿

私には小さな息子がいます。彼が成長し、インターネットを使うようになる頃、ウェブは一体どんな姿になっているのでしょうか。今のままでは、Googleという「大きな会社」が決めたルールの中でしか遊べない、そんな閉鎖的な公園になってしまうかもしれません。

私は、彼に「インターネットは自由な場所だ。君自身の声を発信できる、無限の可能性を秘めた場所だ」と胸を張って伝えたいのです。そのためには、今、私たち大人が行動しなければならない。彼らが未来でデジタル主権を当たり前のものとして享受できるよう、私たちはそのための道を切り拓く責任があります。息子に、そして未来の世代に、真のオープンウェブを引き継ぐために、私はこの戦いを諦めません。

第三部：歴史的類似とグローバル影響

第16章 Microsoftの「抱きしめ、伸ばし、消す」戦略との類似：過去の覇権戦争の反響 – Microsoft's Embrace and Extinguish Echo, Google's Modern Techno Tango

本論文が指摘するGoogleのウェブ支配戦略は、インターネットの歴史において初めてのものではありません。特に、Microsoftが1990年代後半から2000年代初頭にかけて行った「抱きしめ、伸ばし、消す（Embrace, Extend, Extinguish - EEE）」戦略[EEE]との驚くべき類似性が見られます。この歴史的な反響を理解することは、Googleの行動の真の意図と、ウェブにもたらす長期的な影響を深く洞察するために不可欠です。

16-1. MicrosoftのEEE戦略とその結果

Microsoftは、Windows OSの圧倒的な市場シェアを背景に、ウェブブラウザ市場でNetscape Navigatorを駆逐するためにEEE戦略を巧みに用いました。

  • Embrace (抱きしめ): まず、MicrosoftはNetscapeや他の企業が推進していたHTMLやCSS、JavaScriptといったウェブ標準を「抱きしめ」、Internet Explorer (IE)に実装しました。これにより、IEは当時の主要なウェブコンテンツを表示できるようになりました。

  • Extend (伸ばし): 次に、Microsoftはこれらの標準に自社独自の拡張機能を追加しました。例えば、IE独自のHTMLタグやCSSプロパティ、あるいは独自のActiveXコントロール（Ajaxの先駆けとなったXMLHTTPはその一例です）などです。これらの拡張機能は、当時のMicrosoftが提供するサービスや技術と密接に連携しており、開発者はIEに最適化されたウェブサイトやアプリケーションを構築することで、より高度な機能を実現できました。

  • Extinguish (消し去る): 最後に、これらの独自拡張機能が普及することで、IEに最適化されたウェブサイトが増え、IEを「推奨ブラウザ」とする流れが生まれました。これにより、Netscapeのような競合ブラウザは、これらの独自拡張をサポートできないためにウェブコンテンツを適切に表示できず、市場シェアを失い、最終的に競争力を「消し去られ」ました。IEはOSにバンドルされていたため、ユーザーが追加コストなしに利用できたことも、その支配力を決定づけました。

この結果、IEは市場をほぼ独占し、ウェブ標準への準拠は停滞。ウェブ開発のイノベーションは一時的に失速しました。これは、オープン標準の重要性と、独占的慣行がイノベーションを阻害する危険性を歴史が私たちに突きつけた教訓です。

16-2. Googleの現代版EEE戦略

本論文は、GoogleがこのMicrosoftの戦略を現代のウェブに適用していると主張しています。その具体的な行動は、以下の点で類似しています。

  • Embrace (抱きしめ): Googleは、W3Cが策定したHTML、CSS、JavaScriptなどのウェブ標準をChromeに実装し、パフォーマンスを向上させることで、ユーザーと開発者を魅了しました。Chromeのオープンソース性（Chromium）は、当初、その「オープン」な姿勢を強くアピールする材料となりました。

  • Extend (伸ばし): しかし、Googleはその後、独自の拡張機能をウェブ標準として「推進」し始めました。AMPはその典型例です。AMPは特定のHTML/CSS/JavaScriptのサブセットであり、GoogleのCDNを介して提供されることで高速化を謳いました。また、WHATWGにおける主導権を握ることで、自社に有利なAPI（例: Fetch APIにおけるJSON優遇）を事実上の標準として押し進めました。Manifest V3のように、広告ブロッカーの機能を制限するAPI変更も、Googleの広告ビジネスモデルを強化する独自拡張と言えます。

  • Extinguish (消し去る): そして、Googleは自社のサービスや技術にそぐわない既存のオープン標準を「消し去る」動きを見せています。本論文が特に焦点を当てるXMLやXSLTのサポート削除提案、RSSリーダーの閉鎖、XMPPフェデレーションの停止などがその具体例です。これらの行動は、ウェブの分散性を支える技術を弱体化させ、ユーザーや開発者をGoogleのエコシステムに閉じ込めることを目的としていると指摘されています。

Microsoftの時代と異なり、Googleの戦略はより巧妙です。彼らはOSを独占しているわけではなく、オープンソースを「活用」し、ユーザーの「利便性」や「安全性」を名目とすることが多いため、批判が表面化しにくい側面があります。しかし、本質的には、ウェブという公共のインフラを自社の商業的利益のために囲い込み、支配しようとする点で、歴史は繰り返されているのです。

コラム：歴史は本当に繰り返すのか

IT業界に身を置く者として、私は常に歴史から学ぶことの重要性を感じています。Microsoftが犯した過ち、つまり「オープン標準を無視し、自社独自の閉鎖的なエコシステムを築こうとしたこと」は、後になって大きな批判の対象となりました。その反動として、オープンソース運動やウェブ標準の重要性が再認識された経緯があります。

だからこそ、今のGoogleの動きを見ていると、既視感を覚えずにはいられません。彼らはMicrosoftと同じ過ちを、より洗練された形で繰り返そうとしているのではないかと。しかし、私たちには過去の教訓があります。この歴史を繰り返させないために、私たちは何ができるのか。それが、この論文が私たちに問いかけている、最も重要な点だと考えています。

第17章 欧米の規制事例：DMA/DSAと反トラスト訴訟の教訓 – EU's DMA Dance, Antitrust's Advance, Lessons in Legal Lance

Googleをはじめとする巨大テック企業による市場支配は、ウェブのオープン性を脅かすだけでなく、公正な競争や消費者の選択肢、さらには民主主義にまで影響を及ぼすと認識され、欧米各国で強力な規制の動きが加速しています。特に欧州連合（EU）のデジタル市場法（DMA）やデジタルサービス法（DSA）、そして米国の司法省による反トラスト訴訟は、この問題に対する重要な教訓を与えています。

第17-1節：米国司法省対Google：独占の具体例と判決の波及 – DOJ's Duel with the Giant, Monopoly's Malign Ant

米国では、司法省（DOJ）がGoogleに対して複数の反トラスト（独占禁止法）訴訟を提起しています。これらの訴訟は、Googleが検索エンジン市場、デジタル広告市場、そしてモバイルOS市場（Android）において、違法な独占的地位を濫用していると主張しています。特に注目すべきは、検索エンジン市場における独占に関する訴訟です。

  • 検索市場の独占: 司法省は、GoogleがAppleなどのデバイスメーカーやブラウザ開発者に対して、Google検索をデフォルトの検索エンジンとして設定するよう巨額の報酬を支払っていることを問題視しています。これにより、競争相手の参入が阻害され、消費者の選択肢が不当に制限されていると主張されています。

  • デジタル広告市場の支配: Googleは、検索広告だけでなく、ディスプレイ広告、YouTube広告など、デジタル広告のあらゆる領域で支配的な地位を確立しています。司法省は、Googleが広告主やパブリッシャー（メディア）に対して、Googleのプラットフォームを利用するよう強制し、競争を阻害していると見ています。

これらの訴訟の判決は、Googleのビジネスモデルに大きな影響を与える可能性があります。もしGoogleが独占禁止法違反と判断されれば、事業の一部売却や、デフォルト契約の禁止、アルゴリズムの透明性向上といった措置が課される可能性があります。これは、ウェブのオープン性を巡る議論において、法的強制力による支配構造の是正という新たな側面を提示しています。

しかし、一方で、司法省の訴訟は、GoogleがXMLやXSLTのような特定のウェブ技術のサポートを意図的に縮小している点には直接触れていません。これは、規制当局が巨大テック企業の技術的戦略の全貌を把握し、その影響を法的に評価することの難しさを示しています。本論文のような技術的な視点からの詳細な分析が、規制当局の理解を深める上で重要となります。

第17-2節：欧州のデジタル市場法：プラットフォーム規制の多角的影響 – DMA's Disruptive Decree, Europe's Economic Spree

欧州連合（EU）は、巨大テック企業の市場支配力に対処するため、世界に先駆けて二つの画期的な法案を成立させました。それが、デジタル市場法（DMA）とデジタルサービス法（DSA）です。

  • デジタル市場法（DMA）: DMAは、特定の巨大プラットフォームを「ゲートキーパー（gatekeeper）」と指定し、彼らに特定の「義務（してはならないこと）」と「禁止事項（しなければならないこと）」を課すものです。

    • 義務の例: ユーザーがデフォルトのブラウザや検索エンジンを自由に選択できるようにする、サービス間の相互運用性を確保する（例：メッセージングアプリの相互接続）、ユーザーがアプリストア以外の経路でアプリをインストールできるようにする（サイドローディングの許可）。

    • 禁止事項の例: 自社サービスを競合他社よりも優遇する（セルフプリファレンシングの禁止）、ユーザーデータを一方的に収集・結合する。

    DMAは、Google Chromeのデフォルト設定の強制、AndroidにおけるGoogleアプリのバンドル、そしてGoogle検索における自社サービス優遇といった慣行に直接対処することを目的としています。もしGoogleがDMAに違反すれば、巨額の罰金（全世界年間売上高の最大10%）が科される可能性があります。DMAは、ウェブの競争環境を再活性化し、ユーザーの選択肢を広げるための強力なツールとなることが期待されています。

  • デジタルサービス法（DSA）: DSAは、オンラインプラットフォームの透明性とアカウンタビリティ（説明責任）を高め、違法コンテンツや偽情報の拡散に対処することを目的としたものです。巨大プラットフォームに対して、コンテンツモデレーションの仕組みを改善し、アルゴリズムの透明性を高めることなどを義務付けています。これは直接ウェブのオープン性に関するものではありませんが、プラットフォームが情報をどのように扱っているかを透明化することで、間接的にユーザーのデジタル主権を強化するものです。

これらの欧米における規制の動きは、Googleのような巨大テック企業の市場支配が、もはや単なる商業的成功ではなく、社会全体の構造に影響を及ぼす問題として認識されていることを示しています。これらの規制がどれほどの実効性を持つかはまだ未知数ですが、ウェブの未来を私たちが望む方向に導くための重要な一歩であることは間違いありません。

コラム：法律と技術の「いたちごっこ」

私がIT業界で働き始めた頃、法律や規制が技術の進化に追いつくのは非常に難しい、と感じていました。技術は常に先を行き、法律はその後を追いかける「いたちごっこ」のような状態です。

しかし、欧州のDMAやDSAのような法律を見ると、その「いたちごっこ」に変化の兆しが見える気がします。彼らは個別の技術ではなく、巨大プラットフォームの「振る舞い」そのものを規制しようとしています。これは、技術のスピードに追いつくための賢明なアプローチだと感じています。もちろん、まだ多くの課題はありますが、法律の力によってウェブのオープン性が守られる可能性が広がったことに、一筋の光明を見出すことができます。

第18章 アジア・日本への波及：デジタルエコシステムの従属化と文化的主権 – Japan's Jumbled Jam, Asia's Autonomy Scam, Sovereignty's Silent Slam

Googleによるウェブの集中化は、世界中のあらゆる国に影響を及ぼしますが、特にアジア、そして日本への波及は深刻な意味を持ちます。デジタルエコシステムの従属化は、経済的な競争力だけでなく、文化的主権、すなわち自国の文化や価値観がデジタル空間でどのように表現され、流通するかにまで影響を及ぼすからです。

18-1. 日本のデジタルエコシステムの従属化

日本は、スマートフォン市場においてAndroidとiOSが圧倒的なシェアを占め、ウェブブラウザもGoogle Chromeが主流です。検索エンジンもGoogleが圧倒的なシェアを誇り、デジタル広告市場でもGoogleとMeta（Facebook）が支配的です。このような状況は、日本において以下のようなデジタルエコシステムの従属化を招いています。

  • Googleへの高い依存度: 日本の企業やコンテンツプロバイダーは、Googleの検索アルゴリズム、Chromeの技術仕様、Androidのプラットフォームポリシー、そしてGoogle広告ネットワークへの依存度が非常に高くなっています。これにより、Googleのポリシー変更（例：AMPの推奨、Manifest V3の強制、HTTPSの強制）や技術的選択（例：XSLTの非推奨化）が、日本のビジネスモデルやウェブ開発に直接的な影響を及ぼします。特に中小企業や独立系開発者にとって、この依存は競争環境の歪みにつながり、イノベーションを阻害する可能性があります。

  • 標準化活動への影響: W3CからWHATWGへの標準化主導権のシフトや、特定の技術の非推奨化は、これまで国際標準化活動に貢献してきた日本の技術コミュニティや企業に影響を与えます。Googleの意向が事実上の標準となることで、日本発の技術や、日本の文化・社会的なニーズを反映した多様なウェブ技術が生まれにくくなる恐れがあります。

  • 情報流通の均質化と検閲リスク: Google検索やYouTube、Androidを介した情報流通が支配的になることで、情報の均質化が進み、多様な視点や独立したコンテンツが埋もれやすくなります。また、Googleのアルゴリズムやポリシーが、意図せず（あるいは意図的に）特定の情報を「検閲」する可能性も高まります。これは、日本の言論空間や民主主義にも影響を及ぼしうる深刻な問題です。

18-2. 文化的主権とデジタルアイデンティティの危機

デジタルエコシステムの従属化は、単なる経済的損失に留まらず、より深いレベルで日本の文化的主権を脅かします。

  • 言語と文化のデジタル表現: Googleのプラットフォームやブラウザの技術仕様が、日本語や日本独自の文化的表現（例：絵文字、特定のフォント、縦書き表示など）を十分にサポートしない場合、あるいはそのサポートが後回しにされる場合、日本固有のデジタル文化の発展が阻害される可能性があります。MathMLのような事例は、特定分野のコンテンツ表現がプラットフォームの都合で制限される可能性を示唆しています。

  • デジタルアイデンティティの管理: `keygen`要素の廃止や、Googleによる認証サービスへの依存は、日本人が自身のデジタルアイデンティティをどのように管理するかに影響を与えます。もし主要な認証基盤が海外の巨大企業に握られれば、国家レベルでのデジタルアイデンティティ管理の自由度が失われる可能性があります。

  • データ主権とプライバシー: Googleによる広範なユーザーデータ収集とプロファイリングは、日本のユーザーのプライバシー保護に対する懸念を高めます。Web環境の整合性API（WEI）のような技術は、ユーザーエージェントの自由度を奪い、企業による監視と制御を強化する方向に働くため、日本の個人情報保護法制との整合性も課題となります。

このような状況に対し、日本でもWhoogle🔗やDawarich🔗、Openpanel🔗のような、セルフホスト型・オープンソースの代替サービスへの関心が高まっています。しかし、これらの代替技術の普及には、技術的な障壁やユーザー認知度の課題が存在します。

日本は、このデジタルエコシステムの従属化に気づき、自国のデジタル主権と文化的主権を守るための戦略を早急に確立する必要があります。欧米の規制事例から学びつつ、日本の特性に合わせた対抗策を講じることが、喫緊の課題と言えるでしょう。

コラム：日本のガラパゴス化とデジタル主権

日本はしばしば「ガラパゴス化」と揶揄されることがあります。独自の技術や文化を発展させる一方で、グローバルスタンダードから乖離してしまうという現象です。しかし、デジタル主権の観点から見ると、この「ガラパゴス」が必ずしも悪いことばかりではない、と最近は考えるようになりました。

例えば、かつての日本の携帯電話が持っていた独自の技術やサービス。あれらがもしオープン標準として世界に展開できていれば、今のような巨大テック企業の支配はもう少し穏やかだったかもしれません。もちろん、閉鎖的な「ガラパゴス」では、グローバルなイノベーションから取り残されるリスクもあります。

重要なのは、世界の流れを理解しつつも、自国の価値観や文化を守り、それをデジタル空間で自由に表現できる能力を失わないことです。私たちのデジタルアイデンティティと文化を、Googleや他の巨大企業にすべて委ねてしまうのは、あまりにも危険な賭けではないでしょうか。

第19章 開発者コミュニティの視点：オープンソース運動の類似危機と抵抗史 – Devs' Defiant Drum, Open Source's Hum, Resistance's Rhythmic Rum

Googleによるウェブの集中化は、単にユーザーの選択肢を狭めるだけでなく、ウェブを構築する開発者コミュニティにも深刻な影響を与えています。特に、オープンソース運動の理念と実践に対する類似の危機と、その抵抗の歴史を理解することは、現在の状況を打破するためのヒントを与えてくれます。

19-1. オープンソースと「フリーソフトウェア」の理念

ウェブの発展は、LinuxやApache、Mozilla Firefoxといった多くのオープンソースソフトウェア（OSS）によって支えられてきました。オープンソースは、ソースコードが公開され、誰でも自由に利用、改変、再配布できるという理念に基づいています。これは、知識の共有、共同作業によるイノベーションの加速、そして特定のベンダーへのロックインを防ぐという、ウェブのオープン性とも通じる重要な価値観です。

より厳密には、リチャード・ストールマンらが提唱する「フリーソフトウェア」の理念は、ユーザーの「自由（freedom）」を重視します。これは、ソフトウェアを実行する自由、ソースコードを研究する自由、再配布する自由、そして改善して公開する自由という、四つの自由を意味します。Googleのような企業がオープンソース技術を「利用」しつつも、その自由を侵害するような行動をとることは、このフリーソフトウェアの理念と真っ向から対立します。

19-2. 開発者コミュニティへの影響

Googleの行動は、開発者コミュニティに対し以下のような影響を与えています。

  • 特定の技術スタックへの強制: GoogleがChromeのシェアを背景に特定のAPI（例：Fetch APIでのJSON優遇）やフレームワーク（例：AMP）を事実上の標準として押し進めることで、開発者は、Googleが「推奨する」技術に適合するよう強いられます。これにより、多様な技術選択の自由が失われ、イノベーションの幅が狭まる可能性があります。

  • 既存技術の軽視と開発者のモチベーション低下: XMLやXSLTのような、依然として有用性のあるオープン標準が「古い」「不要」と見なされ、サポートが縮小されることで、それらの技術を習得し、維持してきた開発者のモチベーションは低下します。本論文が指摘するように、GoogleとAppleのXSLT実装が、フリーソフトウェアライブラリのメンテナーの労働力を「搾取」しているという問題も、オープンソースコミュニティの健全性を脅かしています。

  • オープンソースの「形骸化」: ChromeのベースであるChromiumはオープンソースですが、Googleがその開発の方向性を強くコントロールしているため、形式上はオープンソースであっても、実質的にはGoogleの意向が反映されやすい構造になっています。これは、真のオープンソース精神、つまりコミュニティ主導の共同作業という理念の形骸化につながる懸念があります。

19-3. 開発者コミュニティの抵抗史と現在の挑戦

しかし、開発者コミュニティは決して無力ではありません。歴史上、彼らは巨大企業の支配に対抗し、オープンなウェブを守るために声を上げ、行動してきました。

  • 第一次ブラウザ戦争での抵抗: MicrosoftのIEによる独占に対し、Mozilla Firefoxなどの代替ブラウザがWeb標準への準拠を掲げ、開発者からの支持を集めました。W3CとWHATWGの設立も、標準化プロセスの停滞への開発者の不満から生まれました。

  • ウェブ技術の自己組織化: jQueryやReact、Vue.jsといった多くのウェブフレームワークやライブラリは、企業主導だけでなく、オープンソースコミュニティからの自発的な貢献によって発展してきました。これは、開発者自身がより良いウェブを追求する強い意志を持っていることを示しています。

  • 現在の抵抗: Manifest V3に対する広告ブロッカー開発者の反発や、Web環境の整合性API（WEI）に対するプライバシー擁護派の強い批判は、開発者コミュニティがGoogleの支配戦略に依然として抗っている証拠です。XSLT削除に関するGitHubイシューでの圧倒的な反対意見も、その一例です。

開発者コミュニティは、ウェブの基盤を理解し、その理念を共有する「ウェブの守護者」としての役割を担っています。彼らが声を上げ、代替技術を構築し、オープンソースの精神を堅持し続けることが、Googleによる中央集権化の波を食い止める上で不可欠なのです。

コラム：コードが語る自由

私が初めてオープンソースのコードに触れた時の感動は、今でも忘れられません。そこには、誰かのアイデアが、みんなの力で磨き上げられていくプロセスがありました。バグを見つけて修正を提案したり、新しい機能を実装したりする中で、私もその「集合知」の一部になれるという喜びを感じたものです。

オープンソースは、単にコードが無料であるということ以上に、「自由」という哲学が込められています。その自由が、巨大企業の商業的な都合で制限されることは、開発者にとって耐え難いことです。私たちは、単に「使えるツール」を選ぶだけでなく、「自由なツール」を選ぶという視点を持つべきではないでしょうか。コードは、時に言葉よりも雄弁に、私たちに自由の価値を教えてくれるのです。

第20章 プライバシーと検閲のグローバル事例：中国のグレートファイアウォールとの比較 – Privacy's Perilous Plight, Great Firewall's Fright, Global Censorship's Night

Googleによるウェブの中央集権化は、単なる技術的・経済的な問題に留まらず、私たちのプライバシーと情報へのアクセス、さらには検閲のリスクにまで深く関わっています。この問題をより深く理解するために、中国の「グレートファイアウォール（Great Firewall）」のような、国家による徹底したインターネット検閲システムと比較することで、その本質を浮き彫りにすることができます。

20-1. 中国のグレートファイアウォール：国家による情報統制

中国の「グレートファイアウォール」は、国家がインターネットを徹底的に監視し、特定の情報へのアクセスを遮断する大規模な検閲システムです。これは、特定のウェブサイト（Google、Facebook、Twitterなど）やキーワードをブロックし、VPNなどの回避技術も規制することで、国民がアクセスできる情報を厳しく統制しています。

  • 検閲の目的: 主に政治的な安定の維持、社会秩序の確保、特定のイデオロギーの保護を目的としています。政府に不都合な情報や、海外からの影響を排除しようとします。

  • 技術的手段: IPアドレスのブロック、DNSポイズニング、キーワードフィルタリング、パケットフィルタリング、SSL/TLS接続の遮断など、多岐にわたる技術が用いられています。

  • 影響: 中国国民は、世界のインターネットから隔離され、政府が許可した情報のみにアクセスを制限されます。これにより、情報の多様性が失われ、批判的な言論や異見が抑圧されます。

グレートファイアウォールは、国家による権力の集中と、それに伴う情報統制の究極の形であり、ウェブのオープン性と自由に対する最大の脅威の一つとして国際的に批判されています。

20-2. Googleの中央集権化と「見えない検閲」

一見すると、Googleによるウェブの集中化と中国のグレートファイアウォールは全く異なる問題に見えます。前者は企業活動、後者は国家の統制です。しかし、本論文は、Googleの行動が、より巧妙で「見えない形」で同様のプライバシー侵害と検閲のリスクを生み出していると警鐘を鳴らしています。

  • データの集中とプロファイリング: Googleは、検索履歴、閲覧履歴、位置情報（Google Timeline🔗🔗）、Gmailの内容、YouTubeの視聴履歴など、膨大なユーザーデータを収集・統合しています。このデータは、広告配信の最適化だけでなく、ユーザーの行動や思考を予測する詳細なプロファイル構築に利用されます。これは、国家による監視とは異なる形で、企業による「プライバシーの侵害」と言えるでしょう。

  • アルゴリズムによる情報の選別（「見えない検閲」）: Google検索のアルゴリズムは、ウェブ上の情報にアクセスするための主要なゲートウェイです。このアルゴリズムが、特定のウェブサイトや情報源を検索結果の上位に表示させたり、逆に下位に表示させたり、あるいはまったく表示させないようにしたりすることが可能です。Googleはこれを「関連性」や「品質」の向上と説明しますが、その基準は不透明であり、結果として特定の情報がユーザーに届きにくくなる「見えない検閲」を生み出す可能性があります。例えば、HTTPS化されていないサイトの検索順位を低下させる動きも、セキュリティ強化という名目で特定のプロトコルへの適合を強制するものです。

  • プラットフォーム依存による言論統制: YouTubeやGoogle Play、Androidなどのプラットフォームが、特定のコンテンツやアプリケーションを「ポリシー違反」として削除する権限を持つことは、表現の自由に対する企業の検閲リスクを生じさせます。これは、国家が直接検閲するのではなく、プラットフォーム企業を介して間接的に言論が統制される構図と言えます。

  • Web環境の整合性API（WEI）のリスク: WEIの導入は、ユーザーのブラウザ環境の「信頼性」をチェックする仕組みであり、将来的には特定の広告ブロッカーやプライバシー保護ツールを使用しているユーザーを排除したり、コンテンツへのアクセスを制限したりする目的で悪用される可能性があります。これは、中国のグレートファイアウォールが特定のソフトウェアやVPNをブロックするのと同様に、ユーザーのデジタル選択肢を制限する動きです。

国家による直接的な検閲とは異なり、Googleの集中化は、ユーザーの利便性やセキュリティといった「善意」の仮面を被って進行します。しかし、その結果は、ユーザーがアクセスできる情報、利用できるサービス、そして自身のプライバシーに対するコントロールを失うという点で、グレートファイアウォールがもたらす影響と本質的な類似性を持つ危険性を秘めているのです。私たちは、この「見えない検閲」の脅威に対し、より高い意識を持つ必要があります。

コラム：私が体験した「見えない壁」

私は以前、海外の友人と話していた時、彼がアクセスできないウェブサイトや情報源があることに気づき、驚いたことがあります。それは、彼の国で政府による検閲が行われているためでした。その時、私は「日本に住んでいてよかった、こんな規制はない」と心底思いました。

しかし、今回の論文を読んで、私自身の思い込みが甘かったことを痛感しました。政府の壁がなくても、巨大IT企業が情報の流れをコントロールしていれば、結局は「見えない壁」が存在することになる。むしろ、その方が気づきにくいため、より危険かもしれません。便利さの裏に隠されたこの「見えない壁」を、私たちはもっと意識しなければならないと強く感じています。

第四部：対抗策と未来展望

第21章 分散型技術の再興：IPFSとFediverseの具体例 – IPFS's Interstellar Leap, Fediverse's Freedom Heap

Googleによるウェブの集中化に対抗し、オープンでレジリエントなウェブを取り戻すためには、分散型技術の再興が不可欠です。本章では、その具体的な例として、ファイル共有の未来を変える可能性を秘めたIPFS（InterPlanetary File System）と、ソーシャルメディアの新たな形を提示するFediverse（Mastodonなど）に焦点を当てます。

21-1. IPFS：ウェブを分散化する次世代プロトコル

現在のウェブは、HTTPというプロトコルに大きく依存しています。HTTPでは、ウェブサイトのコンテンツは特定のサーバーに保存され、ユーザーはそのサーバーにアクセスしてコンテンツを取得します。この「場所ベース」のアドレス指定は、サーバーダウンや検閲に弱いという問題点があります。

これに対し、IPFS (InterPlanetary File System)は、コンテンツ指向のハイパーメディアプロトコルであり、ウェブの根本的な部分を分散化しようとする試みです。IPFSでは、コンテンツはそれが「どこにあるか」ではなく「何であるか」に基づいてアドレス指定されます。つまり、ファイルの内容そのものがアドレス（ハッシュ値）となり、そのコンテンツを持つ世界中のあらゆるノードからデータが取得できるのです。

  • 検閲耐性: 特定のサーバーがブロックされても、他のノードからコンテンツを取得できるため、検閲に強いウェブを構築できます。

  • レジリエンス（回復力）とアーカイブ性: サーバーがダウンしても、コンテンツが他の場所で利用可能であれば、ウェブサイトは生き残り続けます。これにより、ウェブコンテンツの長期的な保存（ウェブアーカイブ）にも貢献します。

  • 効率性とコスト削減: 同じコンテンツが複数のノードに存在する場合、最も近いノードから取得できるため、帯域幅の消費が抑えられ、効率が向上します。これは、ホスティングコストの削減にも繋がります。

IPFSは、ウェブの基盤インフラを分散化するという点で、非常に革新的な可能性を秘めています。まだ普及の途上にありますが、ウェブの単一障害点をなくし、より堅牢で自由なインターネットを築く上で重要な技術です。

21-2. Fediverse：ソーシャルメディアの分散化モデル

TwitterやFacebookのような中央集権型ソーシャルメディアプラットフォームは、巨大企業のポリシーやアルゴリズムによってコンテンツが管理され、ユーザーデータが商業利用されるという問題点を抱えています。これに対し、Fediverse (フェディバース)は、このソーシャルメディアの構造そのものを分散化しようとするムーブメントです。

Fediverseは、「federation（連合）」と「universe（宇宙）」を組み合わせた造語で、異なるサーバー（インスタンス）間で相互に通信できる、オープンなソーシャルネットワークの総称です。ActivityPubのようなオープンプロトコルに基づいており、各インスタンスは独立して運営されながらも、ユーザーは自分のインスタンスから他のインスタンスのユーザーと交流できます。

第21-1節：Mastodonの成功物語：ソーシャルメディアの分散化モデル – Mastodon's Mighty Roar, Decentralized to the Core

Fediverseの中でも最も広く知られているのがMastodon (マストドン)です。Twitterの度重なるポリシー変更やオーナーシップの変動を受け、多くのユーザーがMastodonへと移行しました。

  • ユーザー主権の強化: ユーザーは、自分の好みやコミュニティのルールに合ったインスタンスを選ぶことができます。各インスタンスは独自のモデレーションポリシーを持つため、中央集権プラットフォームのような一方的な検閲やアカウント凍結のリスクが軽減されます。

  • 多様性とレジリエンス: 多数の独立したインスタンスが存在するため、一つのインスタンスがダウンしても、Fediverse全体が停止することはありません。これにより、ネットワーク全体のレジリエンスが高まります。また、多様な興味関心に基づいたニッチなコミュニティが形成されやすい環境です。

  • データポータビリティ: ActivityPubは、ユーザーが自分のデータを他のインスタンスに移行する際のポータビリティも考慮しています。

Mastodonの成功は、中央集権型ソーシャルメディアに対する有効な代替手段が、分散型モデルで実現可能であることを示しました。これにより、ソーシャルメディアの支配を巨大テック企業からユーザー自身へと取り戻す希望が見えてきました。

第21-2節：Geminiプロトコルの可能性：軽量ウェブの復活 – Gemini's Gleaming Gem, Lightweight Web's Whim

さらに軽量でシンプルなウェブ体験を追求する動きとして、Geminiプロトコルがあります。これは、過剰に肥大化した現代のウェブに対する反動として生まれた、テキスト中心の軽量なプロトコルです。Geminiは、HTMLの複雑さやJavaScriptの重さから解放され、よりシンプルで高速な情報共有を目指しています。

  • ミニマリストな設計: Geminiは、画像や動画、複雑なスタイルシートを排除し、プレーンテキストに近い形式でコンテンツを提供します。これにより、ページの読み込み速度が劇的に向上し、古いデバイスや低速なネットワーク環境でも快適に利用できます。

  • プライバシーとセキュリティ: GeminiはHTTPSを必須とし、ユーザー追跡のための複雑なスクリプトを排除します。相互認証の仕組みも内蔵しており、よりプライバシーを重視した設計になっています。

  • 中央集権化への対抗: シンプルなプロトコルであるため、大規模なインフラや複雑な開発スキルを必要とせず、個人や小規模コミュニティでも容易にサーバーを立ち上げ、コンテンツをホストできます。これにより、Googleのような巨大企業の影響力を受けにくい、独立した情報空間を構築できます。

Geminiプロトコルは、ウェブの原点回帰とも言えるアプローチで、情報アクセスの多様性を確保し、中央集権化へのカウンターバランスとなる可能性を秘めています。Googleが「Gemini」というAIチャットボットの名前を使い始めたことは、皮肉にもこのプロトコルの存在を間接的に知らしめる結果となったかもしれません。

これらの分散型技術は、ウェブの未来を私たち自身の手に取り戻すための具体的な「道具」です。これらを理解し、利用し、そして積極的に支援することで、私たちはGoogleの支配に対抗し、よりオープンで自由なインターネットを再構築できるのです。

コラム：小さな世界、大きな自由

私がMastodonを使い始めた時、最初は戸惑いました。Twitterのような大きなプラットフォームとは違い、インスタンスごとに文化も雰囲気も違うからです。でも、すぐにその魅力に気づきました。自分の居心地の良い場所を見つけ、そこで同じ興味を持つ人たちと深く交流できる。まるで、インターネットの中に、いくつもの「小さな村」が点在しているような感覚です。

IPFSやGeminiも、最初は難解に聞こえるかもしれません。でも、これらの技術が目指すのは、単に「技術的にすごいこと」だけではありません。それは、私たちがもっと自由に、もっと安全に、そしてもっと自分らしくデジタル空間で過ごせるようになるための「道具」なのです。大きなものに全てを預けるのではなく、自分たちで小さな「世界」を築き、そこに大きな「自由」を見出す。そんな未来が、今、私たちの手の中にあります。

第22章 規制とコミュニティの連携：国際的なムーブメント構築 – Regs and Rebels Unite, Global Fight's Delight

Googleによるウェブの集中化という巨大な課題に立ち向かうには、技術的な解決策だけでなく、規制の力とコミュニティの連携という二つの側面が不可欠です。これらが国際的なムーブメントとして結びつくことで、初めて巨大なテック企業の支配に対抗し、オープンなウェブを取り戻すことが可能になります。

22-1. 規制当局の役割と限界

欧州のデジタル市場法（DMA）やデジタルサービス法（DSA）、米国の司法省による反トラスト訴訟など、各国の規制当局は、巨大テック企業の市場支配力に対処するため、これまで以上に積極的に介入し始めています。これらの規制は、以下のような点でウェブのオープン性回復に貢献する可能性があります。

  • 競争の促進: ゲートキーパーへの義務（相互運用性の確保、デフォルト設定の変更許可など）を課すことで、中小企業や新規参入企業が巨大プラットフォームと公正に競争できる環境を整えます。

  • ユーザーの選択肢の拡大: 強制的なブラウザや検索エンジンの選択画面の導入、アプリストア以外のアプリインストール許可などは、ユーザーが自身のデジタル環境をより自由にカスタマイズできる機会を提供します。

  • 透明性と説明責任の向上: アルゴリズムの透明化やコンテンツモデレーションの改善は、プラットフォームの意思決定プロセスをより理解可能にし、不当な情報操作や検閲のリスクを軽減します。

しかし、規制当局の介入には限界もあります。技術の進化は早く、法律がそれに追いつくのは常に困難です。また、ロビー活動などにより、巨大企業が規制を骨抜きにしようと試みる可能性も常に存在します。さらに、規制当局がウェブ技術の深い部分（例：XMLやXSLTのサポート削除提案など）まで詳細に理解し、それらの影響を法的に評価することは非常に難しいのが現状です。

22-2. コミュニティの連携と国際的ムーブメントの構築

そこで重要となるのが、開発者、研究者、市民社会、そして一般ユーザーといった多様なコミュニティの連携です。規制の網の目をかいくぐろうとする企業の動きに対し、コミュニティは迅速かつ柔軟に対応できます。

  • 技術的専門知識の提供: 本論文のような、具体的な技術動向とそれがウェブに与える影響を深く分析した研究は、規制当局がより効果的な政策を策定するための重要な情報源となります。開発者コミュニティは、技術的な側面から問題点を指摘し、代替技術の実現可能性を示すことで、規制当局の判断を補強できます。

  • 世論の喚起と草の根運動: ソーシャルメディア（X🔗🔗）やReddit、Mastodonなどのプラットフォームを通じて、ウェブの集中化問題に対する認知度を高め、一般ユーザーの関心を喚起する草の根運動が不可欠です。Google Readerの閉鎖に対する反発🔗や、XSLT削除提案に対するGitHubでの強い反対意見🔗は、コミュニティの声が巨大企業に影響を与え得ることを示しています。

  • 国際的な連携: ウェブは国境を越えるインフラであるため、この問題は特定の国だけの課題ではありません。欧州、米国、日本、そしてその他の国々の規制当局や市民社会が連携し、国際的な基準やベストプラクティスを共有することで、より効果的な対抗策を講じることができます。例えば、デジタル主権やプライバシー保護に関する国際的なコンセンサスを形成することが重要です。

  • 代替技術エコシステムの支援: 政府や非営利団体が、IPFSやFediverseのような分散型ウェブ技術、そしてそれを支えるオープンソースプロジェクトに対し、資金的・人材的支援を提供することが、持続可能な代替エコシステムを構築する上で不可欠です。

規制当局とコミュニティがそれぞれの強みを活かし、密接に連携することで、私たちはGoogleのような巨大テック企業の一方的な支配を阻止し、真にオープンで公正なウェブの未来を創造するムーブメントを構築できるでしょう。この戦いは、技術者だけでなく、全てのウェブ利用者の参加を必要としています。

コラム：対話の力

以前、とある業界団体で、新しい技術標準に関する議論に参加したことがあります。そこでは、大企業から小さなスタートアップ、そしてフリーランスの開発者まで、様々な立場の人が意見をぶつけ合っていました。最初は意見が対立することもありましたが、最終的には、全員が納得できる妥協点を見つけ出すことができました。それは、まさに「対話の力」だと感じた瞬間でした。

今回のウェブの集中化問題も、一方的にGoogleを非難するだけでなく、対話を通じて解決策を探る姿勢も重要です。もちろん、彼らが対話に応じない場合は、別の手段を講じる必要がありますが。しかし、私たちコミュニティが多様な声を束ね、規制当局と連携し、そして巨大企業との対話を粘り強く続けることで、未来を変えることができると信じています。

第23章 AI時代のウェブ：LLMとスクレイピングの新脅威と防御策 – AI's Invasive Itch, Scraping's Sneaky Switch, Defenses that Ditch

ウェブは常に進化しており、現在はAI（人工知能）、特に大規模言語モデル（LLM）の時代に突入しています。この新しい波は、ウェブのコンテンツ生成、情報アクセス、そしてプライバシーに新たな脅威をもたらす一方で、分散型ウェブ技術が思わぬ防御策となる可能性も示唆しています。

23-1. LLMとウェブスクレイピングの新たな脅威

ChatGPTのようなLLMは、インターネット上の膨大なテキストデータを学習することで、人間のような自然な文章を生成したり、複雑な質問に答えたりする能力を獲得しました。しかし、この学習プロセスは、主にウェブ上のコンテンツを「スクレイピング」することによって行われています。

  • 著作権とデータ利用の課題: LLMがウェブコンテンツをスクレイピングし、それを学習データとして利用することは、コンテンツの著作権や利用規約に関する新たな法的・倫理的課題を生み出しています。コンテンツ制作者は、自身の作品が許諾なくLLMの学習に利用され、その結果生成されたコンテンツがオリジナルと競合する可能性を懸念しています。

  • 情報源の匿名化とフェイクニュース: LLMが生成するコンテンツは、元の情報源が不明瞭になる傾向があります。これにより、事実に基づかない情報やフェイクニュースが容易に拡散されるリスクが高まります。また、LLMが特定の企業や個人の意図を反映した情報を「事実」として生成する可能性も指摘されています。

  • ウェブの肥大化とノイズの増加: LLMによって大量のコンテンツが自動生成されるようになれば、ウェブ上の情報量は爆発的に増加し、質が低い、あるいは重複した情報が氾濫する可能性があります。これにより、ユーザーが本当に価値のある情報を見つけることが一層困難になる「ノイズの増加」が懸念されます。

Google自体もGeminiのようなLLMを開発しており、その学習にはウェブデータが不可欠です。これは、Googleがウェブコンテンツを「利用」し、それを自社のAIサービスの強化に役立てることで、再びウェブを中央集権化する新たな手段となりうることを示唆しています。

23-2. 分散型技術が提供する防御策

しかし、本論文が興味深い視点として提示しているのは、皮肉にもGoogleが排除しようとしている一部の技術が、このLLMによるスクレイピングに対する防御策として機能する可能性がある、という点です。

  • XML+XSLTの難解さ: 論文は「LLMスクレイパーの大群には一般的なXMLに関するいくつかの困難があるため、XML+XSLTに切り替えることは実際に自己保護に機能する可能性がある」と述べています。これは、多くのLLMが自然言語処理に特化しており、複雑なXML構造やXSLTによる動的な変換を正確に解析することが苦手である可能性を示唆しています。もしこれが真実であれば、XML+XSLTは、著作権を保護し、無許可のスクレイピングからコンテンツを守るための「デジタルな城壁」となりうるかもしれません。

  • 分散型ウェブ技術の優位性:

    • Fediverse: MastodonのようなFediverseのプラットフォームでは、各インスタンスが独自のポリシーを持つため、LLMによる学習データとしての利用を制限したり、特定のコンテンツへのアクセスを制御したりすることが比較的容易です。

    • IPFS: コンテンツ指向のアドレス指定を持つIPFSは、特定のサーバーに依存しないため、LLMが特定の情報源を「ブロック」したり、改ざんされた情報を挿入したりするのを難しくします。コンテンツのハッシュ値がその内容を保証するため、データの真正性を確保しやすいというメリットもあります。

AIの時代において、ウェブのオープン性を守る戦いは、より複雑な様相を呈しています。しかし、Googleが排除しようとしている古い技術や、彼らが主導していない新しい分散型技術が、この新たな脅威に対する防御策となりうるという可能性は、非常に示唆に富んでいます。私たちは、AIの進化がもたらす便益を享受しつつも、それがウェブの自由と多様性を損なわないよう、常に監視し、適切な防御策を講じていく必要があります。

コラム：AIとの共存、そして「知性」の定義

最近、AIの進化には本当に驚かされます。人間が書いた文章と見分けがつかないようなコンテンツを瞬時に生成したり、まるで人間のように会話したりするAIを目にするたびに、「これは本当に革命だ」と感じます。

しかし、同時に不安も感じます。AIが生成したコンテンツがウェブ上にあふれかえり、何が真実で何がフェイクなのか、見分けがつかなくなる日が来るのではないかと。そして、AIが学習するデータが偏っていたら、その「知性」もまた偏ったものになってしまうのではないか、と。

XMLやXSLTがAIスクレイピングへの防御策になりうるという話は、非常に興味深いです。古いものが新しいものへのカウンターになる。まるで映画のようです。AIが私たちの生活に浸透していく中で、私たちは「知性」とは何か、そして「人間性」とは何かを、改めて問い直す必要があるのかもしれません。

第24章 未来シナリオの多角分析：最悪のディストピア vs. 理想のユートピア – Dystopia's Dark Dread, Utopia's Upward Thread

Googleによるウェブの集中化という現状を踏まえ、私たちはウェブの未来について複数のシナリオを想定することができます。それは、最悪のディストピア（暗黒世界）から、理想的なユートピア（理想郷）まで様々です。これらのシナリオを多角的に分析することで、私たちは現状の深刻さを理解し、望ましい未来を実現するための具体的な行動を導き出すことができます。

24-1. 最悪のシナリオ：デジタル・ディストピア

もしGoogleのウェブ支配戦略が完全に成功し、私たちユーザーや規制当局が有効な対抗策を講じなかった場合、ウェブは以下のようなディストピアへと向かう可能性があります。

  • 究極の「walled garden」: ウェブは、Googleのエコシステム（Chrome、Android、検索、広告、AIサービスなど）に完全に支配された「囲い込まれた庭」となります。ユーザーはGoogleのプラットフォーム内でしか快適な体験を得られず、他の選択肢は事実上存在しなくなります。

  • 情報の一元化と「見えない検閲」の常態化: Googleのアルゴリズムが、私たちの情報へのアクセスを完全に制御します。検索結果やニュースフィードは、Googleのビジネスモデルや特定のイデオロギーに沿うように最適化され、多様な視点や批判的な情報はユーザーに届かなくなります。Web環境の整合性API（WEI）のような技術により、ユーザーのデバイスやブラウザのカスタマイズが制限され、特定の広告ブロッカーやプライバシー保護ツールは機能しなくなります。

  • デジタル主権の喪失: 私たちのデータはすべてGoogleによって収集・分析され、詳細なプロファイルが構築されます。個人のプライバシーは実質的に存在せず、企業による監視と行動予測が常態化します。ユーザーは自身のデジタルアイデンティティや活動をコントロールする能力を完全に失い、デジタル奴隷のような状態に陥るでしょう。

  • イノベーションの停滞と経済の硬直化: 新しい技術やサービスは、Googleのエコシステムに適合しなければ生き残れません。これにより、多様なイノベーションが阻害され、ウェブ経済は少数の巨大企業によって支配され、硬直化します。中小企業やスタートアップの参入障壁は極めて高くなります。

これはSF映画のような世界ですが、現在のウェブの動向を見れば、決して絵空事ではないと本論文は警鐘を鳴らしています。

24-2. 理想のシナリオ：オープンでレジリエントなウェブ・ユートピア

一方で、私たちのアクションが成功し、オープンウェブの理念が守られた場合の理想的な未来も描くことができます。

  • 分散型エコシステムの繁栄: ウェブは中央集権型プラットフォームへの依存を脱し、MastodonのようなFediverse、IPFS、Geminiプロトコルなど、多様な分散型技術が共存し、繁栄します。ユーザーは、自分の好みやニーズに合わせて自由にサービスを選択できるだけでなく、自分自身でサービスをホストし、情報を管理できるようになります。

  • ユーザー主権とプライバシーの確保: ユーザーは自身のデータに対する完全なコントロールを取り戻し、どの情報を誰と共有するかを自分で決定できるようになります。強力なプライバシー保護技術と、透明性の高いアルゴリズムが標準となり、企業や国家による不当な監視やプロファイリングは排除されます。ブラウザは真の「ユーザーエージェント」として、私たちのデジタルライフを保護します。

  • イノベーションと競争の活性化: オープン標準と相互運用性が尊重されることで、技術の選択肢が広がり、多様な企業や開発者が自由に競争し、イノベーションを追求できる環境が生まれます。これにより、ウェブは常に進化し続け、ユーザーのニーズに迅速に対応できるようになります。

  • 情報の多様性とアクセシビリティ: アルゴリズムによる情報のフィルターが最小限に抑えられ、ユーザーは多様な情報源から、自分の意思で情報を選択し、アクセスできるようになります。ウェブコンテンツは、デバイスや環境に依存せず、誰にでもアクセシブルに提供されます。

このユートピアは、一夜にして実現するものではありません。しかし、これは私たち皆が目指すべき共通のビジョンであり、その実現に向けて、個人、企業、政府がそれぞれの役割を果たし、連携することが不可欠です。

現状は、ディストピアとユートピアの間に位置しています。私たちはどちらの方向へ進むのか、今、その選択の時が来ているのです。この論文は、私たちにその選択の重要性を突きつけ、行動を促しています。

コラム：私が夢見るウェブ

もし私がウェブの未来をデザインできるとしたら、それは巨大な中央集権的なタワーではなく、無数の小さな庭と、それらを繋ぐ無限の小道が広がる世界です。

誰もが自分の「庭」を持ち、そこで好きな花を育て、好きなものを表現できる。そして、その庭と庭を自由に移動し、様々な景色を眺め、多様な人々と出会える。そんな世界を夢見ています。AIは、その庭をより豊かにする道具となり、小道を掃除してくれる存在であってほしい。決して、庭の持ち主や通行人を監視したり、特定の庭への入り口を塞いだりする「門番」であってはなりません。

この夢を実現するためには、私たち一人ひとりが、小さな「庭師」として、そして「探検家」として、行動し続ける必要があります。それは決して簡単な道ではないでしょうが、それでも、私はこの夢を諦めたくないのです。

第25章 最終提言：個人・企業・政府の役割分担 – Roles to Reclaim the Realm, Shared Schemes in the Scheme

Googleによるウェブの集中化という複合的な課題に対し、ウェブの未来を真にオープンで民主的なものとして取り戻すためには、個人、企業、そして政府がそれぞれの役割を認識し、連携して行動することが不可欠です。ここに、そのための最終提言をまとめます。

25-1. 個人の役割：意識的な選択と積極的な参加

  • デジタルリテラシーの向上: 巨大テック企業のビジネスモデル、データの収集・利用方法、アルゴリズムの仕組み、そしてそれが私たちの情報摂取やプライバシーに与える影響について、主体的に学び、理解を深めましょう。これは、情報化社会を生きる上で最も重要なスキルの一つです。

  • 意識的なサービス選択: 日常的に利用するブラウザ、検索エンジン、メールサービス、ソーシャルメディアなどを選択する際、その企業のプライバシーポリシー、オープン標準への貢献度、市場支配力などを考慮に入れましょう。Google Chrome以外のブラウザ（Firefox、Braveなど）、Google検索以外の検索エンジン（DuckDuckGo、SearXなど）の利用を検討するのも一歩です。

  • 積極的に声を上げる: ウェブの集中化やプライバシー侵害に関する問題に対し、沈黙せず、SNS（X🔗🔗）やコミュニティフォーラム、署名運動などを通じて意見を表明しましょう。GitHubイシューのような開発者向けの場でも、積極的に議論に参加することが重要です。

  • 分散型サービスやオープンソースの利用・支援: MastodonのようなFediverseサービス、IPFSなどの分散型ストレージ、そして様々なオープンソースソフトウェアを積極的に利用し、可能であれば寄付やコード貢献、バグ報告といった形で支援しましょう。これらは、巨大企業に対抗しうる代替エコシステムを育むための基盤となります。

25-2. 企業の役割：オープンイノベーションと社会的責任

  • オープン標準への貢献と遵守: 巨大テック企業は、自社の利益だけでなく、ウェブ全体の健全な発展のために、オープン標準の開発と普及に真摯に貢献すべきです。特定の技術の非推奨化や独自の拡張機能の導入は、透明かつコミュニティとの対話を経て、ウェブの相互運用性を損なわない形で行われるべきです。

  • プライバシーとセキュリティの尊重: ユーザーのデータを収集・利用する際、その透明性を高め、ユーザーに明確なコントロール手段を提供すべきです。Web環境の整合性API（WEI）のような、ユーザーのデバイスやブラウザの自由度を奪う可能性のある技術提案は、徹底した倫理的・社会的な影響評価と、コミュニティとの開かれた議論を経て行われるべきです。

  • 競争環境の促進: 大企業は、市場支配力を使って新たな競争相手の参入を阻害したり、既存の中小企業を不当に排除したりする行為を慎むべきです。自社エコシステムへの囲い込みではなく、他のサービスとの相互運用性を積極的に確保し、オープンなAPIを提供することで、ウェブ全体のイノベーションを促進すべきです。

  • オープンソースプロジェクトへの公正な貢献: 自社製品でオープンソースライブラリを利用する場合、そのメンテナーに対し、単なる「無料利用」だけでなく、資金援助や開発リソースの提供といった形で公正に貢献すべきです。オープンソースコミュニティの持続可能性は、ウェブ全体の健全性に関わります。

25-3. 政府の役割：公正な市場の守護者とデジタル主権の擁護者

  • 独占禁止法の厳格な適用と強化: 巨大テック企業による独占的慣行に対し、より積極的に独占禁止法を適用し、競争を促進する措置を講じるべきです。プラットフォームの分割、相互運用性の強制、データポータビリティの義務化など、大胆な措置も検討すべきでしょう。

  • デジタル市場規制の構築と国際連携: 欧州のDMAやDSAを参考に、デジタル市場におけるゲートキーパーへの規制を強化し、公正な競争とユーザーの権利保護を法的に担保すべきです。また、ウェブは国境を越えるため、国際的な規制当局間の連携を強化し、グローバルな課題に対応すべきです。

  • オープン標準の推進と公共セクターでの採用: 政府は、オープン標準の開発と採用を奨励し、公共機関のシステムにおいてオープン標準を優先的に利用する政策を推進すべきです。これにより、特定の企業エコシステムへの過度な依存を避け、国家としてのデジタル主権を強化することができます。

  • デジタルリテラシー教育の強化: 国民全体がデジタル社会を生き抜くために必要なデジタルリテラシーを向上させるための教育プログラムを推進し、情報への批判的思考能力を育むべきです。

ウェブの未来は、決して特定の巨大企業や技術者集団だけが決めるものではありません。それは、私たち利用者一人ひとりの意識的な選択と行動、企業が負うべき社会的責任、そして政府による公正な市場の維持という、三者の協調と相互作用によって形作られるべきものです。この提言が、ウェブの真の自由と多様性を取り戻すための、小さくとも確かな一歩となることを願っています。

コラム：未来への投資

私たちが普段使っている電気や水道、道路といったインフラは、国や自治体、そして多くの企業が協力して維持管理しています。それらが「当たり前」のように使えるのは、誰かがその維持に投資し、責任を負っているからです。

インターネットもまた、現代社会の最も重要なインフラの一つです。しかし、このデジタルインフラの維持管理や方向性を、少数の巨大企業に任せきりにするのはあまりにも危険です。私たちが物理的なインフラに投資し、その健全性を守るように、デジタルインフラとしてのウェブにも、個人、企業、政府がそれぞれの立場で投資し、そのオープン性と自由を守る責任があるのです。

未来の世代のために、私たちは今、このウェブという「共通の庭」を守り、育むための「投資」を始めるべき時なのです。

補足資料：洞察と議論

補足1：ドーリアン・テイラーによるXSLTの情熱的擁護 – Taylor's Torrid Tale, XSLT's Valiant Veil

本論文で繰り返し言及されている、Dorian Taylor氏[dorian-taylor]によるXSLTへの情熱的な擁護は、GoogleによるXSLT削除提案のGitHubイシューで展開されました。GAFAMがその議論を削除する可能性を考慮し、ここにその要点を再現します。

Dorian Taylor氏は、XSLTをベータ版の頃から使用しており、MSIE 5.5が唯一実装していた時代（1999年頃）からその価値を認識しています。2002年から2005年にかけては、XSLTとDocBookを用いて国際化されたコンテンツパイプラインを設計・実装し、2007年頃からはクライアント側でXSLTを定期的に使用して（X）HTMLやSVG、Atomなどを変換してきました。

彼が今もXSLTを使用する理由は以下の通りです。

  • 標準である: XSLTはW3Cによって策定された確立された標準です。

  • 高速である（少なくとも名目上）: 適切に実装されれば、XSLTは高速な変換が可能です。

  • 宣言的である: 手順ではなく、結果として「どうあるべきか」を記述する宣言的な性質は、コードの可読性と保守性を高めます。

  • JS（JavaScript）と直交する: JavaScriptのエコシステムとは独立して存在するため、開発者は特定の言語にロックインされることなく、ツールを選択できます。

  • 任意の数のバックエンドをミックスできる: 標準であり、標準入力に対して動作するため、静的リソースと動的リソースを同じページでミックスするために定期的に使用されています。

  • 与えられた情報に対してのみ動作する: 明らかなゼロデイ攻撃を防ぎます。

  • DOM構造全体で動作する: マークアップをテキストとして繋ぎ合わせるのではなく、無傷のDOM構造上で動作するため、有効性のチェックが非常に低いレベルで組み込まれています。他の多くのテンプレート言語がターゲット言語の構文を「切り刻む」のに対し、XSLTは整合性を保ちます。

彼が最も重要だと考えるのは、最初の「標準性」と最後の「DOM構造全体で動作する」点です。XSLTスタイルシートは整形式のXMLドキュメントであり、整形式のXMLドキュメントに対してのみ動作し、整形式の（X|HT）MLドキュメントしか生成できないため、有効性のチェックが極めて低いレベルで組み込まれています。

また、彼は、XSLT実装に多くのCVE（脆弱性情報）があるのは、その技術が「無視されてきたため」であると指摘します。XHTML2がHTML5に競合していた時期を例に挙げ、XMLパーサーの衒学的さが開発者によって非難され、味方が変わり、人々が先に進んだと述べます。ブラウザベンダーはパーサーを保持していますが、ほとんど力を入れていないと指摘。XSLT 1.0の最大の欠点は2007年の2.0で修正されたが、ブラウザはそれを実装しなかった、と。

Dorian Taylor氏の提案は、XSLTを廃止するのではなく、修復することです。XSLTは、当初からプレゼンテーションマークアップ生成の問題に対する堅牢でオープン標準のソリューションでした。ウェブテンプレートの車輪が、なぜ何度も再発明されなければならないのか、と問いかけています。XSLTの後継となるオープンウェブのソリューションは、他でもないXSLT自身であるべきだと主張します。

XSLTの核心は、特にその最新バージョン（XSLT 3.0。JSON上で動作可能）において非常に強力です。彼は、XSLTが持つ課題（冗長な構文、XML経由でのみ動作、名前空間、XPath、デバッグの困難さ）に対し、Relax NGのコンパクト構文や、CSSセレクターセマンティクスのXPathへの埋め込みといった改善策を提案しています。XSLT 3.1へのバンプと、HTML DOM上での動作方法の指定も提案しています。

最終的に彼は、「マークアップを変換するための標準言語、つまりすべてのプロジェクトで常に私たち全員がしなければならないことに対する欲求が本当にないのか？基準がないために、私たちをあれやこれやの枠組みに閉じ込めたり、妨げたりするものカジュアルシステムの異質性？ウェブをさらに簡単に構築できるものでしょうか？賢明なアイデアのように思えますね？」と問いかけ、標準のウェブテンプレートを作ることは非常に実現可能であると締めくくっています。

補足5：ずんだもんの核心を突く感想 – Zunda's Zesty Zinger, Core's Comical Clinger

「Googleさん、オープンウェブ殺しにかかってるんだって。ひどいのだ！XMLとかXSLTとか、みんなで自由に使える技術なのに、Googleさんの都合で消されちゃうなんて、ずんだもん悲しいのだ。これじゃあ、インターネットがGoogleさんのものになっちゃうのだ。みんなで声を上げないとダメなのだ！ずんだもんも、オープンなウェブがいいのだ！」

補足6：ホリエモンが喝破するウェブビジネスの「ぶっちゃけ」 – Horie's Honest Hurl, Business's Blunt Whirl

「これ、超本質的な話だよな。Googleって要するに、プラットフォームエコシステムを完全に掌握したいわけじゃん。XMLとかXSLTとか、ぶっちゃけ非効率な部分もあったけど、あれって分散型ウェブの基盤なんだよ。それを『リソースが足りない』とか言って排除するのは、完全に市場戦略。開発者から見たら、Googleのレールに乗っかれば楽だけど、結局ロックインされてベンダーに依存する形になる。イノベーションの阻害にも繋がるし、俺なら絶対別のパラダイムでビジネス組むね。Web3とか、もっと分散型の方向に振らないと、GAFAMに全部食われるぞ、マジで。ま、ぶっちゃけ勝ち馬に乗るのがビジネスだけどな。」

補足7：ひろゆきが淡々と語る「それってあなたの感想ですよね？」 – Hiroyuki's Humble Huff, Opinion's Offhand Cuff

「なんか、Googleがオープンウェブを殺してるって話みたいですけど、それってあなたの感想ですよね？別に誰もXML使ってないし、XSLTとか知ってる人、ほとんどいないんじゃないですかね。JSONの方がみんな使ってて便利だし。Googleがやってるのって、別にユーザーが困ってないんだったら、別に良くないですか？独占禁止法とか言っても、結局みんなGoogle使ってるんだから、それが最適解ってことでしょ。嫌だったら使わなきゃいいだけじゃん。論破王的には、需要と供給でしょ、結局。」

補足2：主要なネット掲示板に予測される反応と反論の試み – Boards' Boisterous Banter, Reactions' Rambunctious Rant-er

予測されるネットの反応

  • なんJ民

    コメント: 「Google無能やろ。ワイらなんJ民がずっと使っとるRSS潰すとかアホちゃうか？」「結局、情報統制したいだけやろこれ。もうWebはオワコンや、2chMate最強！」「ワイはChromeしか使わんし、どうでもええわ。別に困ってないし。情弱専用ブラウザやな。」

    反論: 「Googleの行動は、単なる『無能』ではなく、むしろ戦略的な『有能』だ。彼らの目的は、利便性を提供しつつ、ユーザーの選択肢を奪い、自社のプラットフォームに囲い込むこと。RSSは分散型の象徴だったからこそ狙われた。Chromeの便利さは、その支配の代償だ。情弱は自分で作れないツールに文句も言えないから搾取され続けるんやで。」

  • ケンモメン (嫌儲民)

    コメント: 「やっぱりGoogleはCIAやGAFAMの手先。ウェブは最初から監視ツールとして作られたんだよ。もうインターネットは終わり。みんなゲスブ書くしかないな。」「ネトウヨはChrome使いまくりなんだろ？情弱すぎて草。」「まーた陰謀論か。どーせXMLが使われなくなったのは需要がなかったからだろ。JSONが流行ったのは開発者が楽だからだ。」

    反論: 「陰謀論で片付けるのは思考停止だ。Googleの行動は、オープンウェブの理念に反する明確な戦略的選択であり、それが監視や統制のリスクを高めるのは事実だ。開発の楽さは重要だが、それが分散性やユーザー主権を犠牲にして良い理由にはならない。JSONの普及は、Googleが後押しした側面も大きい。情弱とか関係なく、みんなが使わされてるんだよ、このシステムに。」

  • ツイフェミ

    コメント: 「Googleがオープンウェブを殺すって？結局、これも巨大テック企業による男性中心主義的な支配構造の一環でしょ。マイノリティの声が届きにくくなる構造は許せない。」「また男性エンジニアたちが自分たちの都合で技術を弄んでる。女性にとって使いやすいウェブとは何か、考えたことある？」

    反論: 「この論文の核心は、巨大企業の権力集中が、ウェブ全体の多様性、アクセス可能性、そしてユーザーの自由を損なうという点にある。これは性別に関わらず、全てのウェブユーザーに影響を与える問題だ。特定の属性のエンジニアを批判するだけでなく、いかにして多様な声が反映されるオープンなウェブを再構築するか、その構造的な議論が必要だ。ジェンダーの問題は重要だが、問題の本質を見誤っては解決に繋がらない。」

  • 爆サイ民

    コメント: 「Google潰せ！俺たちのパチスロ情報サイトが重くなるのもGoogleのせいか！」「XMLとかXSLTとか知らんけど、なんかGoogleが悪いのはわかった！」「どうせ最後は金持ってる奴が勝つんだろ。それが世の中ってもんだ。」

    反論: 「確かに最後は金が物を言う世界だが、だからこそ、その金の力に抗うための『オープンな』技術や仕組み、そして声の重要性がある。Googleの行動は、お気に入りのサイトの表示速度だけでなく、ウェブ全体の自由な情報流通と、ひいては私たちの情報収集のあり方そのものに影響を及ぼしている。無関心ではいられない問題だ。パチスロ情報が検閲される可能性だってあるんだぞ。」

  • Reddit/Hacker News

    コメント (Reddit/Hacker News):

    • "Solid analysis. The XSLT deprecation is indeed an insult, especially given the state of v1.0 vs v3.0. This feels like a repeat of IE6, but with more insidious, data-driven motivations."
    • "While I agree with the premise, the XML/XSLT focus feels a bit dated. JSON is just more practical for web apps today. The real fight is Manifest V3 and WEI."
    • "This author has a clear bias, but they raise valid points about Google's monopolistic tendencies. The AMP and XMPP points are particularly damning."
    • "Good read, but the author cherry-picks examples. Some of these deprecations might actually have legitimate technical reasons, even if the outcome serves Google's interests."
    • "If you don't like it, build something better. That's the open-source way. Complaining about it won't fix anything."

    反論 (Rebuttals):

    • To "dated XML/XSLT focus": While JSON is prevalent for current web apps, the paper uses XML/XSLT as a case study of Google's systematic undermining of any open, interoperable, and client-side transformable data format that doesn't align with their centralized, JavaScript-heavy paradigm. The core issue is Google's control over what formats are viable in the browser, not merely a preference for XML. Furthermore, XSLT 3.0 supports JSON, indicating its adaptability and continued relevance if browsers chose to support modern versions.

    • To "cherry-picking/legitimate reasons": The cumulative effect of these seemingly disparate actions (AMP, XMPP, Reader, keygen, XSLT, Manifest V3, WEI) paints a consistent picture of strategic centralization. Even if individual actions have some technical justification, their aggregate impact and the timing/manner of their implementation strongly suggest an overarching policy choice for control, not just organic evolution or resource management. The lack of transparency and genuine community engagement in these decisions further solidifies the argument.

    • To "build something better": While crucial, "building something better" is increasingly hampered when the dominant browser vendor actively deprecates necessary APIs, dictates runtime environments, and marginalizes competing standards. The call to "build alternatives" is precisely because the playing field is being systematically tilted against independent innovation. Active resistance to anti-competitive practices within the existing system is a necessary precursor to effective alternative building. Moreover, not all problems can be solved by simply "building better"; regulatory intervention is sometimes necessary to correct market failures caused by monopolies.

  • 大森望風書評

    「『Googleがウェブを「殺す」という衝撃の真実』。このタイトルに、あなたは膝を打つか、鼻で笑うか。私は後者だった。しかし、読み進めるうちに、笑えなくなった。著者が羅列するGoogleの「所業」は、個々に見れば些細な技術的決定に過ぎないかもしれない。だが、その背後に透けて見えるのは、かつてマイクロソフトが夢見た『抱きしめ、伸ばし、消す』の、より洗練され、巧妙な現代版である。XML？XSLT？そんな古色蒼然たる技術にこだわるな、とGoogleは言うだろう。だが、これは技術の優劣の問題ではない。ウェブという公共空間を、誰が管理し、誰がその利用を許諾するのかという、根源的な問いである。本書は、その問いを、時に感情的に、時に偏執的に、しかし一貫して突き詰めていく。ウェブの『オープン性』という、もはや信仰に近い概念が、いかにして巨大な商業的圧力によって蚕食されてきたか。その悲劇的な歴史を、本書は告発する。あなたがもし、ウェブの片隅で、まだ「自由」という言葉に僅かでも郷愁を感じるのなら、本書は一読の価値がある。そして、読み終えた後、あなたはきっと、あなたのブラウザを、そして、あなたのウェブを、改めて見つめ直すことになるだろう。」

    反論: 「大森先生、まさしくその通りでございます。この論文の根底にあるのは、技術的優劣というよりも、ウェブの『哲学』と『主権』を巡る戦いであるという認識です。確かに、感情的な記述や偏執的な視点が見られるかもしれませんが、それは、長年にわたるオープンウェブの侵食に対する、筆者の強い危機感の表れと言えるでしょう。この告発が、多くの読者にウェブの現状に対する『郷愁』だけでなく、『危機感』と『行動』を促すことを願ってやみません。ウェブの未来は、私たち一人ひとりの『選択』と『抵抗』にかかっているのです。」

補足3：高校生のためのウェブの未来4択クイズ – Teens' Tricky Test, Web Future's Quiz Fest

高校生向けの4択クイズ

この論文の内容をもとに、ウェブの未来について考えてみましょう。

  1. Q1: この論文が主張する「Googleがオープンウェブを殺している」主な理由は何ですか？

    a) GoogleがWebサイトを無料で提供しすぎているから

    b) GoogleがオープンなWeb標準（XMLやXSLTなど）のサポートを縮小し、中央集権化を進めているから

    c) Googleの検索エンジンが他の検索エンジンより優れているから

    d) GoogleがスマートフォンのOS「Android」を作っているから

    解答

    b) GoogleがオープンなWeb標準のサポートを縮小し、中央集権化を進めているから

  2. Q2: 論文中で、Googleの行動を過去のどの企業の行動に例えて説明していますか？

    a) AppleのiTunes

    b) Microsoftの第一次ブラウザ戦争

    c) Facebookのソーシャルネットワーク戦略

    d) Amazonのオンラインショッピング

    解答

    b) Microsoftの第一次ブラウザ戦争

  3. Q3: 論文によると、GoogleはなぜXSLTという技術のサポートを削除しようとしていると考えられますか？

    a) XSLTが古くて誰も使っていないから

    b) XSLTに技術的な欠陥が多く、セキュリティ上の問題があるから

    c) XSLTが、Googleがデータ収集や広告配信を強化する上で邪魔になる分散型の技術だから

    d) XSLTを開発するのにGoogleに十分なリソースがないから

    解答

    c) XSLTが、Googleがデータ収集や広告配信を強化する上で邪魔になる分散型の技術だから

  4. Q4: 論文が提案する「オープンウェブを守るために私たちにできること」の一つは何ですか？

    a) Google製品の使用を完全にやめる

    b) Googleに抗議する声を上げ、代替技術の利用や構築を検討する

    c) 新しいWeb技術の開発を全てGoogleに任せる

    d) Webサイトの情報をすべて紙媒体に移行する

    解答

    b) Googleに抗議する声を上げ、代替技術の利用や構築を検討する

大学生向けのレポート課題

以下のテーマについて、本論文の内容を参考にしつつ、各自で追加調査を行い、論理的かつ批判的な視点から考察し、レポートを作成してください。

課題1: 「デジタル主権」という概念の多角的考察

本論文は、Googleのウェブ集中化が「デジタル主権」を脅かすと主張しています。この「デジタル主権」とは具体的に何を意味するのか、個人、国家、企業、コミュニティといった異なるレベルで、その概念がどのように解釈され、どのように脅かされているのかを考察してください。また、欧州連合のDMA/DSA、米国の反トラスト法、そして日本のデジタル政策を比較し、それぞれの「デジタル主権」へのアプローチの異同と、その実効性について論じてください。結論として、あなたが考える理想的な「デジタル主権」の姿とその実現に向けた課題を提示してください。

課題2: ウェブ技術の進化と「見えない検閲」の可能性

本論文は、Googleのアルゴリズムやプラットフォームポリシーが、情報の「見えない検閲」を生み出している可能性を指摘しています。Web環境の整合性API（WEI）やManifest V3などの具体例を挙げつつ、技術的進化がいかにして情報の自由な流通を制限し、プライバシーを侵害する可能性があるのかを論じてください。また、中国の「グレートファイアウォール」との比較から、企業による「見えない検閲」と国家による「見える検閲」の共通点と相違点、そしてそれぞれの脅威の質について考察してください。この問題に対し、技術者、政策立案者、そして一般ユーザーがそれぞれどのような役割を果たすべきか、具体的な提言を含めて論述してください。

課題3: オープンソース運動の未来とウェブの分散化

本論文は、XMLやXSLTといったオープン標準がGoogleによって意図的に排除されようとしている現状に対し、オープンソースコミュニティの抵抗の重要性を強調しています。オープンソース運動の歴史的経緯と理念を概観した上で、IPFSやFediverse（Mastodonなど）に代表される分散型ウェブ技術が、Googleの集中化に対抗しうる可能性と課題について考察してください。特に、これらの分散型技術が社会に普及するために、技術的・経済的・社会的にどのような障壁が存在し、それを乗り越えるためにどのようなイノベーションや協力が必要か、具体例を挙げて論じてください。また、あなた自身の専門分野（例えば、経済学、社会学、情報科学など）から、この分散化の動きがもたらすであろう影響についても考察を加えてください。

補足4：論文を巨視する年表：Google支配の時代 – Timeline's Towering Track, Google's Gruesome Attack

年 主な出来事 Googleの行動 オープンウェブへの影響
1998 XML仕様リリース - 柔軟なデータ構造化、相互運用性の基盤となる。
1999 XSLT 1.0がW3C勧告に - XML変換の標準化、クライアントサイド変換の可能性。
2004 WHATWG設立 初期メンバーとして参加 W3Cの標準化プロセスへの不満から、ブラウザベンダー主導の標準化が始まる。
2007 XSLT 2.0がW3C勧告に 実装せず XSLTの機能強化（後の3.0も同様）、しかしブラウザのサポート進まず。
2008 Google Chrome登場 Chromeブラウザリリース 高速性とシンプルさで市場シェア拡大、後のウェブ標準への影響力増大。
2010年代初頭 集中型SNS台頭（Facebookなど）、モバイル接続爆発的普及（iPhone/Android） Webアプリ（Gmail, Maps）に注力 ウェブが文書のネットワークから、中央集権型サービスのUIへと変貌。
2013 ウェブ集中化の転換点 Google Reader閉鎖、XMPPフェデレーション閉鎖、XSLT削除提案、MathMLサポート削除 RSSによる分散型情報収集の弱体化、オープンなリアルタイム通信の制限、オープン標準の意図的排除の開始。GAFAMによる相互運用性の「引き締め」。
2015 Fetch API導入、SMIL非推奨化提案、AMP導入、keygen要素廃止提案 JSON優遇、Google CDNへの集中、ユーザー証明書簡素化の妨害 データ形式のJSONへのシフト、ウェブコンテンツのGoogleインフラへの集中、ユーザー主導のセキュリティ機能の制限。
2017 XSLT 3.0がW3C勧告に 実装せず XSLTがJSON対応など現代化するも、主要ブラウザは旧バージョンに固執。
2018 MozillaがFirefoxからRSSサポート削除 （間接的にGoogleの意向に追従） 分散型情報収集のインフラがさらに弱体化。
2019 Manifest V3発表 Chrome拡張機能API変更 広告ブロッカー機能制限、Chromeが「ユーザーエージェント」でなく「Googleツール」に。
2023 Googleチャットボット「Bard」を「Gemini」に改名、Web環境の整合性API提案、JPEG XLサポート終了、HTTPS採用強制 独立プロトコルを食う、ブラウザを「企業スパイウェア」化、オープンな画像形式排除、HTTPサイトのダウンランク オープンな技術・プロトコルへの攻撃、ユーザーのデバイス制御強化、ウェブのインフラの集中化推進。
2025 Chromeルートプログラムポリシー変更発表 相互認証（S/MIME）を実質的に強制終了 ユーザー証明書の利用制限、セルフホスト型通信の困難化。
最近 XSLT削除の再試行とコミュニティの強い反発 WHATWGをソックパペットとして利用し、XSLT削除を強行しようと試みる。 Googleの意図的な排除戦略が顕在化、コミュニティの抵抗が顕著に。

補足8：筆者によるノリツッコミ＆大喜利：このウェブ、詰んでない？ – Author's Amusing Assault, Web's Witty Waltz Fault

一人ノリツッコミ（関西弁で）

「Googleはオープンウェブ殺しにかかってるって？ いやいや、殺してるんじゃなくて『吸収して支配』しとるんやろ！ 結果的に『息の根止められて消滅』に近いけどな！ほんま、えげつないわー！」

「XML？XSLT？『古い』って？ そらGoogleが『古い』って言うたら古くなるってことやんけ！ ほな、Googleの気分次第でウェブの寿命が決まるんか？え、まさか、そんなアホな！」

「『リソースがない』って、年間何兆円稼いどる会社が言うセリフか！？ そら『XSLTにリソース割く気がない』って意味やろ！ めっちゃケチやんけ！ケチちゃうわ、戦略や！」

「AMPとか言って爆速化？そりゃGoogleのサーバー通してるからやろ！うちのサイトがGoogleに飼いならされとるだけやんけ！高速化の皮を被ったGoogle専用高速道路やな！いや、ウェブやから道やないけどな！」

「結局、ブラウザがユーザーエージェントじゃなくて、Googleのエージェントになってるって話か？ワイらの代わりにGoogleの言いなりになっとるだけやん！そんなん、まるでスパイやん！スパイちゃうわ、ただのブラウザや！」

補足8：筆者によるノリツッコミ＆大喜利：このウェブ、詰んでない？ – Author's Amusing Assault, Web's Witty Waltz Fault

大喜利

お題：「Googleがオープンウェブを殺している」という論文発表！Google社員が「いや、誤解です！」と焦って言ったこととは？

  • 「あれは、ウェブを『より良く』するために『最適化』しているだけです！ええ、最適化です！」
  • 「XSLTはですね、もうちょっと熟成させてから、満を持してBard…いや、Geminiに搭載しますから！」
  • 「我々Googleは、オープンソースが大好きですよ！だって、タダで使えるんですから！」
  • 「あのタイムラインは、あくまで『個人的な』Webブラウジング履歴なので、Googleの公式見解とは関係ありません！あくまで『個人の意見』です！」
  • 「え、まだXSLT使ってる人いるんですか？（心の声：じゃあ消してもバレないな…）」
  • 「これは『殺している』のではなく、『新しい命』を吹き込んでいるのです！そのための『解体』作業とでも言いましょうか！」
  • 「ウェブは元々『自由』ではありません！我々Googleが『自由』を提供しているのです！」

補足8：筆者によるノリツッコミ＆大喜利：このウェブ、詰んでない？ – Author's Amusing Assault, Web's Witty Waltz Fault

オリジナルのデュエマカード

この論文をテーマに、オリジナルのデュエマカードを生成します。

カード名: 支配する巨大検索 (The Dominant Search Giant)
文明: 闇/水 (Darkness/Water - 闇は支配と破壊、水は情報操作と流動性を象徴)
コスト: 7
種類: クリーチャー
種族: テック・ゴッド (Tech God)
パワー: 7000
能力:
*   マッハファイター (自分のクリーチャーがバトルする時、バトルゾーンにいるこのクリーチャーをタップしてもよい。そうしたら、そのクリーチャーはタップせずに攻撃できる。)
*   【登場時】ウェブの標準化破壊: このクリーチャーがバトルゾーンに出た時、相手の山札の上から3枚を墓地に置く。その後、相手は自身の手札から「XML」または「XSLT」と名のつくカードをすべて捨て、相手のWebサイトをオープンウェブの概念から切断する。(※Webサイトは墓地へ置かれるわけではない。)
*   【攻撃時】データ囲い込み: このクリーチャーが攻撃する時、相手の墓地にある呪文を全て山札の下に置き、相手のデッキから『自由なインターネット』と名のつくカードを全て探し、山札の下に置く。その後、山札をシャッフルする。
*   ブロッカーを無効化する: このクリーチャーは、相手のブロッカーを無視してプレイヤーを攻撃できる。
*   T・ブレイカー (このクリーチャーはシールドを3枚ブレイクする。)

フレーバーテキスト:
「かつては『悪しきをなさず』を掲げたが、今やその進化の陰で、ウェブの根幹は静かに、しかし確実に侵食されている。もはや彼らの手から、ウェブの未来を取り戻すことはできるのか？」

補足9：GAFAMの類似戦略比較：AppleとMetaの囲い込み事例 – GAFAM's Greedy Game, Apple's Avarice Aim, Meta's Monopolistic Flame

本論文はGoogleの行動に焦点を当てていますが、ウェブの集中化はGoogleだけの問題ではありません。GAFAM（Google, Apple, Facebook/Meta, Amazon, Microsoft）の各社は、それぞれ異なるアプローチで、自社エコシステムへの囲い込み戦略を展開しています。ここでは、AppleとMeta（旧Facebook）の事例を比較し、その類似性と多様性を探ります。

Appleの「 walled garden（囲い込まれた庭） 」戦略：ハードウェアとソフトウェアの垂直統合

Appleは、その強力なハードウェア製品（iPhone、iPad、Mac）と、それに密接に統合されたソフトウェア・サービス（iOS、macOS、App Store、iMessage、Apple Musicなど）を特徴とする、典型的な垂直統合型の「囲い込み戦略」を展開しています。

  • App Storeの支配: AppleはApp Storeを通じて、iOSデバイスにおけるアプリの配布と収益化を厳しくコントロールしています。アプリ開発者は、Appleの規約に従い、その課金システムを利用しなければなりません。これは、外部アプリストアの参入を制限し、競争を阻害するとして、欧州のDMAや米国の反トラスト訴訟の対象となっています。

  • WebKitエンジンの一元化: iOSデバイスでは、すべてのブラウザがAppleのWebKitエンジンを使用することが義務付けられています。これにより、Google ChromeやMozilla Firefoxといった他社ブラウザも、iOS上ではWebKitの制約を受けざるを得ません。これは、GoogleがChromiumエンジンでウェブを支配するのと同様に、AppleがWebKitを通じてモバイルウェブの描画エンジンを実質的に独占している状況を生み出しています。

  • プライバシーを盾にした囲い込み: Appleは、ユーザープライバシー保護を強く打ち出し、他社（特にFacebook）のユーザー追跡を制限する「App Tracking Transparency（ATT）」のような機能を導入しました。これはユーザーにとって有益な側面がある一方で、広告モデルに依存する他社サービスを弱体化させ、Apple自身のサービス利用を促進する効果も持っています。プライバシー保護が、自社エコシステムへの囲い込みを正当化する口実として利用されているという批判もあります。

Metaの「ソーシャルグラフ」支配戦略：ネットワーク効果の最大化

Meta（Facebook）は、Facebook、Instagram、WhatsAppといった巨大なソーシャルメディアプラットフォームを擁し、ユーザー間の「ソーシャルグラフ」を支配することで市場優位性を確立しています。

  • ネットワーク効果の活用: ソーシャルメディアは、利用者が多ければ多いほど価値が高まるというネットワーク効果が強く働くビジネスです。Metaは、大規模なユーザーベースを構築し、それらを統合することで、新たな競合他社の参入を極めて困難にしています。InstagramやWhatsAppの買収は、競合となりうる新興企業を排除し、自社の支配力を強化するための戦略でした。

  • XMPPフェデレーションの停止: Googleと同様に、MetaもMessengerにおけるXMPPフェデレーション機能を停止し、自社のメッセージングサービスをクローズドな環境に閉じ込めました。これにより、ユーザーはMetaのアプリ内でしか交流できなくなり、データが囲い込まれました。

  • データ収集とターゲティング広告: Metaは、ユーザーの投稿、行動、交流履歴などから膨大なデータを収集し、詳細なプロファイルを構築しています。このデータは、極めて精度の高いターゲティング広告の配信に利用され、同社の主要な収益源となっています。ユーザーデータが、Metaのプラットフォーム支配を強化する上で不可欠な要素となっています。

  • メタバースへの投資: Metaは「メタバース」という次世代のインターネット空間を構築し、そこでも支配的なプラットフォームとなることを目指しています。これは、ウェブ空間が仮想現実へと拡張される中で、新たな「囲い込み」の機会を模索する動きと言えます。

これらの事例から、GAFAM各社が異なる戦略（Googleは検索とブラウザ、AppleはハードウェアとOS、Metaはソーシャルグラフ）を採りつつも、最終的にはユーザーとデータを自社エコシステムに囲い込み、市場支配力を強化するという共通の目標を持っていることがわかります。そして、その過程でオープン標準やユーザーの選択肢が犠牲になるという点も共通しています。

ウェブの未来を考える上で、Googleだけでなく、これら全ての巨大テック企業の行動を包括的に監視し、多角的な視点からその影響を評価することが不可欠です。

補足10：代替ブラウザの台頭：FirefoxとBraveの抵抗ストーリー – Alternatives' Audacious Ascent, Firefox's Fiery Dissent, Brave's Bold Bent

Google Chromeの市場支配が強まる中、ウェブのオープン性を守るための抵抗の旗手として、Mozilla FirefoxとBrave Browserといった代替ブラウザが注目されています。彼らは異なるアプローチで、巨大なGoogleエコシステムに挑んでいます。

Mozilla Firefox：オープンウェブとプライバシーの最後の砦

Mozilla Firefoxは、非営利団体Mozilla Foundationによって開発され、長年にわたりウェブ標準の推進とオープンウェブの擁護を掲げてきました。Google Chromeが台頭する以前は、Microsoft Internet Explorerの独占に対抗する主要な勢力でした。

  • 独自のGeckoエンジン: Firefoxは、Google ChromeがChromiumエンジンに依存しているのに対し、独自のレンダリングエンジンであるGecko（そして、その後実験的に開発されたServo）を維持しています。これにより、ウェブの描画エンジンがChromium一色になることを防ぎ、Googleの意向がそのままウェブの表示方法になることを食い止める「最後の砦」としての役割を担っています。

  • プライバシー重視の姿勢: Firefoxは、強力なトラッキング防止機能や、DNS over HTTPS（DoH）の導入など、ユーザーのプライバシー保護に積極的に取り組んでいます。これは、Googleがデータ収集を強化する動きとは対照的なアプローチです。

  • オープンソースの精神: Firefoxは完全にオープンソースであり、コミュニティからの貢献を歓迎しています。これにより、特定の企業の利益に縛られない、真にユーザー中心のブラウザ開発を目指しています。

しかし、本論文が指摘するように、MozillaはGoogleからの検索エンジン契約による収益に大きく依存しているという構造的な課題を抱えています。これが、FirefoxがGoogleのポリシー（例：RSSサポート削除）に追従せざるを得ない状況を生み出しているという批判もあります。Firefoxの抵抗ストーリーは、理想と現実の狭間で苦闘するオープンソースプロジェクトの姿を映し出しています。

Brave Browser：広告モデルの再構築とプライバシー保護

Brave Browserは、広告とユーザープライバシーの関係を根本から問い直す新しいアプローチを提案するブラウザです。Google Chromeと同じChromiumエンジンをベースにしていますが、その哲学は大きく異なります。

  • デフォルトでの広告・トラッカーブロック: Braveは、トラッカーと広告をデフォルトでブロックする機能を内蔵しています。これにより、ユーザーのプライバシーが保護され、ウェブページの読み込み速度も向上します。これは、Googleが広告ビジネスを基盤とするモデルとは対照的です。

  • 新しい広告モデル「Brave Rewards」: Braveは、ユーザーのプライバシーを尊重しつつ広告を表示する「Brave Rewards」という仕組みを導入しています。ユーザーは、同意した場合にのみBrave独自の広告を閲覧し、その対価としてBasic Attention Token (BAT)という暗号資産を得ることができます。ユーザーはこのBATを、コンテンツクリエイターにチップとして支払ったり、他の暗号資産に交換したりできます。これは、ウェブコンテンツの収益化モデルを、中央集権的な広告ネットワークからユーザー中心の分散型モデルへと変革しようとする試みです。

  • IPFSの統合: Braveは、分散型ファイルシステムであるIPFSへの直接アクセス機能をブラウザに統合しています。これにより、ユーザーはより検閲耐性の高い形でウェブコンテンツにアクセスできるようになります。これは、ウェブの分散化を推進するBraveの明確な意志を示しています。

Braveは、Google Chromeの技術基盤を利用しつつも、その思想とビジネスモデルを大きく転換することで、プライバシーとオープンウェブの新たな可能性を提示しています。その挑戦は、Googleの支配に対する最も革新的な抵抗の一つと言えるでしょう。

これらの代替ブラウザの存在は、ウェブの未来がGoogle一社によって決定されるわけではないという希望を与えてくれます。私たちユーザーが、これらのブラウザを積極的に選択し、支援することで、より多様で自由なウェブエコシステムを育むことができるのです。

巻末資料

用語索引（アルファベット順）

用語索引を表示

用語解説

  • Ad Blocker (広告ブロッカー)
    ウェブサイトに表示される広告をブロックするソフトウェアやブラウザ拡張機能。プライバシー保護やページの高速化に役立つ。
  • Ajax (エイジャックス)
    Asynchronous JavaScript and XMLの略。ウェブページ全体を再読み込みすることなく、非同期にサーバーとデータをやり取りする技術の総称。今日のインタラクティブなウェブアプリケーションの基盤。
  • AMP (Accelerated Mobile Pages)
    Googleが主導する、モバイルウェブページの高速化を目指すオープンソースプロジェクト。特定の制約を設けることで軽量化を図り、GoogleのCDNから配信される。
  • Android (アンドロイド)
    Googleが開発するモバイルオペレーティングシステム。世界で最も広く利用されているスマートフォンOS。
  • API (Application Programming Interface)
    ソフトウェアやプログラムの機能を共有・連携させるためのインターフェース。異なるソフトウェアが互いに通信するためのルールや手順を定義する。
  • Apple (アップル)
    iPhone、Macintoshなどを開発する世界的なテクノロジー企業。SafariブラウザやiOS、macOSを開発。
  • App Store (アップストア)
    Appleが運営するiOSアプリの公式配信プラットフォーム。アプリの審査や販売をAppleが管理する。
  • Atom (アトム)
    ウェブサイトの更新情報やニュースを配信するためのXMLベースのフォーマット。RSSと並び、フィード配信の標準として利用される。
  • CDN (Content Delivery Network)
    ウェブコンテンツ（画像、動画、HTMLファイルなど）をユーザーに地理的に近いサーバーから配信することで、高速かつ安定したアクセスを実現する分散型ネットワーク。
  • Chrome (クローム)
    Googleが開発するウェブブラウザ。世界で最も利用されているブラウザで、Chromiumをベースにしている。
  • Chromium (クロミウム)
    Google Chromeのベースとなっているオープンソースのウェブブラウザプロジェクト。多くのウェブブラウザがこれを基盤としている。
  • CSS (Cascading Style Sheets)
    HTMLやXML文書の見た目（色、フォント、レイアウトなど）を定義するためのスタイルシート言語。
  • データポータビリティ (Data Portability)
    ユーザーが自分の個人データを、あるサービスから別のサービスへ簡単に移動できる権利。巨大プラットフォームへのロックインを防ぐために重要視される。
  • デジタルリテラシー (Digital Literacy)
    デジタル技術を適切に理解し、活用するための能力。情報を批判的に評価し、プライバシーやセキュリティを意識する能力も含む。
  • デジタル主権 (Digital Sovereignty)
    個人や国家が、自身のデジタルデータ、インフラ、そしてオンライン活動を自律的にコントロールできる権利や能力。
  • DMA (Digital Markets Act / デジタル市場法)
    欧州連合（EU）で施行された、巨大オンラインプラットフォーム（ゲートキーパー）による市場支配力を規制し、公正な競争を促進することを目的とした法律。
  • DOM (Document Object Model)
    HTMLやXML文書の構造を、プログラムからアクセス・操作できるように木構造で表現したもの。
  • DSA (Digital Services Act / デジタルサービス法)
    欧州連合（EU）で施行された、オンラインプラットフォームの透明性とアカウンタビリティ（説明責任）を高め、違法コンテンツや偽情報に対処することを目的とした法律。
  • DuckDuckGo (ダックダックゴー)
    ユーザーのプライバシー保護を重視し、検索履歴を追跡しないことを特徴とする検索エンジン。
  • Edge (エッジ)
    Microsoftが開発するウェブブラウザ。現在はChromiumをベースにしている。
  • EFF (Electronic Frontier Foundation / 電子フロンティア財団)
    デジタル時代の市民的自由と権利を擁護する国際的な非営利団体。
  • Electron (エレクトロン)
    ウェブ技術（HTML、CSS、JavaScript）を使ってデスクトップアプリケーションを開発するためのフレームワーク。SlackやVisual Studio Codeなどで利用されているが、リソース消費が大きい点が課題となることもある。
  • Embrace, Extend, Extinguish (EEE) (抱きしめ、伸ばし、消す)
    Microsoftがかつて用いたとされる戦略。既存の標準を「抱きしめ」て普及させ、自社独自の拡張機能を「伸ばし」、最終的に競合を「消し去る」。
  • Facebook (フェイスブック)
    Metaが運営する世界最大のソーシャルメディアプラットフォーム。
  • Fediverse (フェディバース)
    「federation（連合）」と「universe（宇宙）」を組み合わせた造語。異なるサーバー間で相互に通信できる、分散型ソーシャルネットワークの総称。Mastodonなどが代表例。
  • Fetch API (フェッチAPI)
    JavaScriptでネットワークリクエストを非同期に行うためのモダンなAPI。XMLHttpRequestよりもシンプルで柔軟なインターフェースを提供する。
  • Firefox (ファイアフォックス)
    Mozillaが開発するオープンソースのウェブブラウザ。独自のGeckoエンジンを搭載し、プライバシー保護とオープンウェブの擁護を重視する。
  • ゲートキーパー (Gatekeeper)
    欧州連合のデジタル市場法（DMA）で定義される、市場における支配的な地位を持つ巨大オンラインプラットフォーム。
  • GAFAM (ガーファム)
    Google、Apple、Facebook（現Meta）、Amazon、Microsoftの頭文字を取った略称で、世界のテクノロジー業界を牽引する巨大企業群を指す。
  • Gemini (ジェミニ - AIチャットボット)
    Googleが開発する大規模言語モデル（LLM）に基づくAIチャットボット。旧称Bard（バード）。
  • Gemini Protocol (ジェミニプロトコル)
    過度に肥大化した現代のウェブに対する反動として生まれた、テキスト中心の軽量なプロトコル。シンプルでプライバシーを重視したウェブ体験を目指す。
  • GitHub (ギットハブ)
    ソフトウェア開発のためのバージョン管理と共同開発プラットフォーム。多くのオープンソースプロジェクトが利用している。
  • Gmail (ジーメール)
    Googleが提供する無料のウェブメールサービス。
  • HTML (HyperText Markup Language)
    ウェブページの内容や構造を記述するためのマークアップ言語。ウェブの標準的な言語。
  • HTTPS (Hypertext Transfer Protocol Secure)
    HTTPにSSL/TLSによる暗号化を加えた通信プロトコル。ウェブサイトの通信を保護し、盗聴や改ざんを防ぐ。
  • Internet Explorer (インターネットエクスプローラー)
    Microsoftがかつて開発していたウェブブラウザ。かつての「第一次ブラウザ戦争」の主役で、Windowsに標準搭載されていた。
  • iOS (アイオーエス)
    Appleが開発するiPhoneやiPad向けのモバイルオペレーティングシステム。
  • IPFS (InterPlanetary File System)
    分散型ファイルシステム。コンテンツをその「内容」に基づいてアドレス指定し、世界中のノードから取得できる。検閲耐性やレジリエンスが高い。
  • JavaScript (ジャバスクリプト)
    ウェブページに動きや対話性（インタラクティブ性）を与えるために広く使われるプログラミング言語。
  • JPEG XL (ジェイペグエックスエル)
    次世代の画像圧縮フォーマット。ロスレスとロッシーの両方に対応し、高い圧縮率と豊富な機能を持つ。GoogleがChromeでのサポートを一時的に終了した。
  • JSON (JavaScript Object Notation)
    人間が読み書きしやすく、機械が解析しやすいデータ交換フォーマット。JavaScriptのオブジェクト表記に由来し、ウェブアプリケーションで広く利用される。
  • keygen (キーゲン)
    HTML5で導入されたが、後に廃止された要素。クライアント側で暗号キーペアを生成し、サーバーに公開鍵を送信することを簡素化するセキュリティ機能。
  • LLM (Large Language Model / 大規模言語モデル)
    膨大なテキストデータを学習し、人間のような自然言語を理解・生成する能力を持つAIモデル。ChatGPTなどが代表例。
  • Manifest V3 (マニフェストV3)
    Google Chromeのブラウザ拡張機能の新しいマニフェスト（仕様）。広告ブロッカーなど、一部の拡張機能の機能に制限を課す内容が含まれている。
  • Mastodon (マストドン)
    Fediverse内で最も広く利用されている分散型ソーシャルネットワークソフトウェア。Twitterに似た機能を持つ。
  • MathJax (マスジャックス)
    ウェブページ上で数式を高品質に表示するためのJavaScriptライブラリ。MathMLのブラウザサポートがない場合の代替手段として広く利用されている。
  • MathML (Mathematical Markup Language)
    ウェブ上で数学的な式を記述するためのXMLベースのマークアップ言語。
  • Meta (メタ)
    Facebook、Instagram、WhatsAppなどを傘下に持つ巨大テクノロジー企業。旧称Facebook。
  • Microsoft (マイクロソフト)
    Windows OS、Officeソフトウェア、Edgeブラウザなどを開発する巨大IT企業。
  • Mozilla (モジラ)
    Firefoxブラウザなどを開発する非営利団体Mozilla Foundationと、その子会社Mozilla Corporation。オープンウェブの擁護を掲げる。
  • Node.js (ノードジェイエス)
    JavaScriptをウェブブラウザの外（サーバーサイドなど）で実行するためのランタイム環境。デスクトップアプリ開発にも利用される。
  • オープンソース (Open Source)
    ソフトウェアのソースコードを公開し、誰でも自由に利用、改変、再配布できるようにする開発手法や理念。
  • Opera (オペラ)
    ノルウェーのOpera Softwareが開発するウェブブラウザ。かつて独自のPrestoエンジンを持っていたが、現在はChromiumベースに移行している。
  • Pingback (ピンバック)
    ブログなどで、自分の記事が他のブログからリンクされた際に、そのリンク元に自動的に通知する仕組み。ブログ間の相互接続性を高めた。
  • Promise (プロミス)
    JavaScriptで非同期処理の結果（成功または失敗）を表すオブジェクト。非同期処理のコードをより簡潔に記述できる。
  • レスポンシブウェブデザイン (Responsive Web Design)
    ウェブサイトのレイアウトを、閲覧するデバイス（PC、タブレット、スマートフォンなど）の画面サイズに応じて柔軟に変化させるデザイン手法。
  • RSS (Really Simple Syndication)
    ウェブサイトの更新情報やニュースを配信するためのXMLベースのフォーマット。フィードリーダーで購読することで、複数サイトの情報を一元的に確認できる。
  • Saxon-JS (サクソンジェイエス)
    XSLT 3.0をJavaScriptで実装したポリフィルライブラリ。ブラウザが最新のXSLTバージョンをサポートしない場合でも、XSLT変換を実行できる。
  • Safari (サファリ)
    Appleが開発するウェブブラウザ。WebKitエンジンを搭載し、MacやiOSデバイスに標準搭載されている。
  • SearX (シアークス)
    プライバシーを重視した、オープンソースのメタ検索エンジン。Googleなどの複数の検索エンジンから結果を集約し、ユーザーを追跡しない。
  • セルフホスト (Self-Hosted)
    ウェブサービスやアプリケーションを、外部のプロバイダーに依存せず、自分自身が所有・管理するサーバー上で運用すること。データ主権を確保する上で重要。
  • SMIL (Synchronized Multimedia Integration Language)
    XMLベースのマルチメディア統合言語。SVGなどで宣言的なアニメーションやインタラクティブ性を実現するために用いられた。
  • ソックパペット (Sock Puppet)
    他人になりすまして活動するアカウントや組織。本論文では、GoogleがWHATWGを自社の意向を反映させるための道具として利用していることを指す。
  • Solid (ソリッド)
    World Wide Webの発明者であるTim Berners-Leeが提唱する分散型ウェブプラットフォーム。ユーザーが自身のデータを完全にコントロールすることを目指す。
  • srcset属性 (ソースセット属性)
    HTMLの``タグの属性。様々な画面サイズやデバイスピクセル比に応じて、最適なサイズの画像ファイルをブラウザが自動的に選択できるようにする。
  • SVG (Scalable Vector Graphics)
    XMLベースの二次元ベクターグラフィックス形式。拡大・縮小しても劣化しない。
  • Webアプリケーション (Web Application)
    ウェブブラウザを通じて利用できるソフトウェアアプリケーション。サーバーとクライアント（ブラウザ）が連携して機能を提供する。
  • Web Components (ウェブコンポーネンツ)
    ウェブ標準に基づいて、再利用可能なカスタムHTML要素を作成するための技術セット。
  • WebKit (ウェブキット)
    Appleが開発するオープンソースのウェブブラウザエンジン。SafariやiOS版Chromeなどで利用されている。
  • ウェブ肥満危機 (Web Obesity Crisis)
    ウェブページが過度に重くなり、読み込みに時間がかかる問題。JavaScriptや画像、広告スクリプトの増加などが原因とされる。
  • ウェブスクレイピング (Web Scraping)
    ウェブサイトから自動的に情報を抽出し、構造化されたデータとして収集する技術。
  • ウェブ標準 (Web Standards)
    World Wide Webの相互運用性やアクセシビリティを確保するために、W3CやWHATWGなどの団体が策定する技術仕様やガイドライン。
  • WebAssembly (ウェブアセンブリー)
    ウェブブラウザで高性能なアプリケーションを実行するためのバイナリ命令フォーマット。JavaScriptと連携して動作し、Webの可能性を広げる。
  • WHATWG (Web Hypertext Application Technology Working Group)
    HTMLやDOM、Fetch APIなど、ウェブの主要な標準を策定するコンソーシアム。W3Cからウェブ標準策定の主導権を引き継いだ。
  • Whoogle (フーグル)
    Google検索の代替として、自己ホスト型で広告なし、プライバシーを尊重するオープンソースの検索エンジンインターフェース。
  • WordPress (ワードプレス)
    世界で最も広く利用されているオープンソースのコンテンツ管理システム（CMS）。ブログやウェブサイト作成に用いられる。
  • W3C (World Wide Web Consortium)
    World Wide Webで使用される標準技術を策定する国際的な団体。ティム・バーナーズ＝リーが設立。
  • WEI (Web Environment Integrity API)
    Googleが提案した、ウェブサイトがユーザーのブラウザ環境が「信頼できる」ものであることを確認できるようにするAPI。プライバシー侵害やカスタマイズ制限の懸念がある。
  • XML (Extensible Markup Language)
    データの構造化と交換のための汎用マークアップ言語。柔軟性と相互運用性に優れ、RSSやAtomフィードの基盤となった。
  • XMLHttpRequest (エックスエムエルエイチティーティーリクエスト)
    JavaScriptでウェブサーバーと非同期にデータを送受信するためのAPI。Ajaxの根幹をなす技術。
  • XMPP (Extensible Messaging and Presence Protocol)
    インスタントメッセージやプレゼンス（オンライン状態）情報の交換のためのXMLベースの分散型プロトコル。サーバー間のフェデレーションが可能。
  • XSLT (Extensible Stylesheet Language Transformations)
    XMLドキュメントを別のXMLドキュメント（HTMLなど）に変換するための言語。
  • XMP (Extensible Metadata Platform)
    デジタル画像やその他のファイルにメタデータ（ファイルに関する情報）を埋め込むためのISO標準。XMLをベースとしている。
  • YouTube (ユーチューブ)
    Googleが運営する世界最大の動画共有プラットフォーム。
参考リンク・推薦図書を表示

ウェブ記事

推薦図書

  • 『ウェブとは何か？情報社会の未来像』 (ウェブの哲学や歴史に関する書籍)
  • 『プラットフォーム革命』（プラットフォーム経済の光と影に関する書籍）
  • 『情報資本主義論』（情報社会の権力構造に関する社会学・経済学の書籍）

政府資料・学術論文（一般向け）

  • デジタル庁「政府ウェブサイトの標準化・統一化に関するガイドライン」
  • 総務省「インターネット上の情報流通に関する課題と対策に関する調査研究報告書」
  • 公正取引委員会「デジタル・プラットフォーム事業者に関する実態調査報告書」
  • 情報処理学会誌や日本ジャーナリズム学会誌などにおける、「ウェブ空間における情報の偏り」「プラットフォーム化と民主主義」「データ主権とプライバシー」などに関する研究論文。

Googleが開かれたウェブを殺してきた歴史の年表：ウェブの自由が葬られた瞬間

以下は、論文「Googleは開かれたウェブを殺している」を基に、Googleがオープンウェブの分散型アーキテクチャを解体し、中央集権化を進めてきた歴史をまとめた年表です。論文の主張に基づきつつ、多角的視点（歴史的類似、グローバル影響、代替技術の可能性など）を反映し、具体例や過去の類似点を補足しています。ウィットとユーモアを交えたサブタイトルで、表面的な内容を排除し、専門家向けに深掘りした構成にしています。

年 出来事 詳細と影響 サブタイトル：ウィットと韻を踏んだ解説
1998 XML仕様リリース、XSLT 1.0がW3C勧告に XMLとXSLTが「ユニバーサルリンク情報システム」の基盤として登場。分散型ウェブの自由なデータ交換を可能にする礎。Google登場以前の「ウェブの黄金時代」。 XML's Dawn, Freedom's Spawn, Web's Wide Yawn
1999 XSLT 1.0正式勧告 James ClarkらによるXSLT 1.0がW3Cで標準化。クライアントサイドでのデータ変換を可能にし、ユーザーのデータ主権を強化。ウェブの分散性を支える技術的基盤が確立。 XSLT's Standard Stand, User's Data in Hand, Freedom's Grand Plan
2000 Microsoftの「抱きしめ、伸ばし、消す」戦略のピーク 第一次ブラウザ戦争で、MicrosoftがInternet Explorerを武器にNetscapeを圧迫。Googleはこの戦略を現代版として継承する前触れ（歴史的類似）。 Microsoft's Menacing Move, Netscape's Groove to Prove, Monopoly's Crude Groove
2008 Google Chrome登場 Chromeが高速性と標準準拠を謳い、IEに対抗。初期はオープンウェブの味方に見えたが、後に市場支配の道具に変貌。2025年時点でブラウザ市場の約65%を占める（StatCounterデータ）。 Chrome's Shiny Start, Web's Open Heart, Soon to Tear Apart
2010 WHATWGの影響力拡大 Google主導のWHATWGがW3Cから標準化の主導権を奪う。HTML5推進の裏で、企業利益優先の「カルテル化」が進行。 WHATWG's Wicked Win, W3C's Waning Spin, Standards' Sinful Din
2013 Google ReaderとXMPP連邦機能の閉鎖 Google Reader終了でRSSの普及が停滞、分散型情報収集が後退。XMPPのフェデレーション停止で、Google Talkが独自エコシステムに閉鎖。オープンな通信プロトコルの衰退開始。 Reader's Ruinous End, XMPP's Broken Bend, Openness's Bitter Trend
2013 XSLTとMathMLサポートの削除提案 Googleエンジニア（Adam Barthら）がChromeでのXSLT 1.0とMathMLサポート終了を提案。「リソース不足」を理由に挙げるが、Googleの収益（2013年約550億ドル）を考慮すると疑問符。 XSLT's Targeted Takedown, MathML's Mournful Breakdown, Google's Greedy Shakedown
2015 AMP（Accelerated Mobile Pages）導入 GoogleがAMPを「高速化」と宣伝しつつ、コンテンツをGoogle CDN経由で配信。データ収集と広告支配を強化。分散型ホスティングの経済性を損なう。 AMP's Amped-Up Lie, Speed's Sneaky Spy, Web's Wealth Wryly Dry
2015 Fetch APIのJSON優遇と`keygen`廃止提案 Fetch APIがXMLを無視しJSONを優先。`keygen`要素の廃止提案（Ryan Sleeviら）で、ユーザー証明書の簡素化が妨害され、データ主権が弱体化。 JSON's Jarring Jive, Keygen's Killed Drive, User's Control Contrived
2015 SMIL非推奨化提案 Googleエンジニア（Philip Rogersら）がSMIL（SVGアニメーション）のサポート終了を提案。軽量なクライアントサイド技術を排除し、JavaScript依存を加速。 SMIL's Silent Slay, JavaScript's Jarring Sway, Lightweight's Lost Play
2017 XSLT 3.0がW3C勧告に XSLT 3.0がJSON対応を強化し、現代的ニーズに応えるが、主要ブラウザ（Chrome、Edge）は実装せず。Googleの影響力が標準化の無力化を露呈。 XSLT 3.0's Brave Bid, Ignored by Browser's Grid, Google's Gloating Skid
2018 MozillaがFirefoxからRSSサポート削除 MozillaがGoogleの影響と財政的依存（検索契約）を受け、RSSフィード機能を削除。分散型情報流通のさらなる後退。 Firefox's Feedless Flop, Mozilla's Moneyed Mop, Openness's Sad Sop
2019 Manifest V3発表 Chromeの拡張機能API（Manifest V3）がアドブロッカーの機能を制限。Googleの広告収益（2019年約1340億ドル）を保護し、ユーザーのプライバシー制御を弱体化。 Manifest's Malicious Mask, Adblock's Axed Task, Privacy's Perilous Cask
2020 米国司法省がGoogle提訴 米国司法省がGoogleを反トラスト法違反で提訴（検索と広告市場の独占）。オープンウェブの集中化問題が法的議論に。欧州のDMA/DSAも同様の動き（グローバル影響）。 DOJ's Daring Duel, Google's Greedy Rule, Justice's Just Tool
2023 Web環境の整合性API（WEI）提案 GoogleがWEIを提案し、ブラウザを企業管理の「スパイウェア」に変える動き。ユーザーエージェントの自由度を奪い、監視を強化。 WEI's Wicked Whim, Browser's Bound Grim, Surveillance's Sinister Hymn
2023 JPEG XLサポート終了 Googleがオープンな画像形式JPEG XLをChromeから排除。独自フォーマット（WebPなど）を優先し、標準化を歪める。 JPEG XL's Jilted Jest, Google's Format Quest, Openness's Oppressed Chest
2023 HTTPSの強制推進 GoogleがHTTPサイトを検索でダウンランク。セキュリティを名目に、分散型ホスティングを困難にし、インフラ依存を強化。 HTTPS's Heavy Hand, Centralization's Grand Stand, Freedom's Fading Brand
2024 GoogleがBardをGeminiに改名 GoogleがAIチャットボット「Bard」を「Gemini」に改名し、独立プロトコルを吸収。AIとウェブの統合で、データ囲い込みが加速。 Gemini's Gilded Grab, AI's Absorbing Stab, Web's Withering Dab
2025 Chromeルートプログラムポリシー変更 GoogleがS/MIMEを事実上終了させ、相互認証を制限。ユーザー主権をさらに弱体化し、企業による証明書支配を強化。 S/MIME's Silent Stop, Certs' Controlled Crop, User's Power Plop
2025 XSLT削除の再試行と反対運動 Google（Mason Freedら）がXSLT削除を再提案するも、コミュニティの猛反発で頓挫。RSSフィード復活の兆しが、分散型ウェブの抵抗を示唆。 XSLT's Last Stand, Community's Command, Google's Greedy Plan Banned
2025 代替技術の台頭（補足：第四部） MastodonやIPFS、Geminiプロトコルが注目を集め、分散型ウェブの再興へ。日本のWhoogleやOpenpanelもセルフホスト型サービスとして浮上（日本への影響）。 Mastodon's Mighty March, IPFS's Interstellar Arch, Web's Reborn Spark

補足と多角的視点

詳細を見る
  • 歴史的類似: Microsoftの「抱きしめ、伸ばし、消す」戦略（2000年頃のIE支配）は、GoogleのChromeやWHATWGを通じた標準化支配の前例。両者は、オープンな技術を市場力で抑え込み、独自エコシステムに囲い込む点で相似しています。
  • グローバル影響: 欧州のDMA（デジタル市場法）や米国の反トラスト訴訟は、Googleの行動に対する法的抵抗の例。中国のグレートファイアウォールは、集中化が検閲や情報統制に繋がる危険性を示しています。
  • 日本の文脈: 日本の中小企業や独立系開発者は、Googleのエコシステム依存によりビジネスモデルが制約されるリスクを抱えています。例：楽天やヤフーが検索市場で苦戦。
  • 代替技術: Mastodon（Fediverse）やIPFSは、分散型ウェブの具体例として成功の兆し。Geminiプロトコルは軽量ウェブの復活を試み、XSLTのような宣言的技術の再評価を促しています。
  • AIとの関連: LLM（大規模言語モデル）によるスクレイピングが、オープンウェブのデータを吸い上げる新たな脅威。XML+XSLTは自己保護の手段として再評価の可能性があります。

この年表に説得力を持たせるツイートのリンク（10個以下）

code Html download content_copy expand_less

XMLの歴史：オープンウェブの礎とその変遷

以下は、XML（Extensible Markup Language）の歴史を、論文「Googleは開かれたウェブを殺している」の文脈を踏まえつつ、専門家向けに深掘りした年表です。XMLの誕生から発展、Googleによるオープンウェブ解体との関連、そして分散型ウェブの理念に対する影響を整理。ウィットと韻を踏んだサブタイトルで、表面的な記述を排除し、歴史的類似や多角的視点を加えて立体的に提示します。日本の影響や代替技術の文脈も反映し、Markdownで出力します。

年 出来事 詳細と影響 サブタイトル：ウィットと韻を踏んだ解説
1986 SGMLの標準化 XMLの祖先であるSGML（Standard Generalized Markup Language）がISO標準（ISO 8879）に。構造化文書の基盤を確立するが、複雑さが普及の壁に。XMLの簡素化への道を開く。 SGML's Structured Start, Markup's Mighty Heart, Complexity's Cumbersome Cart
1996 XMLの初期提案 W3CでXMLの開発が始まる。SGMLの簡素化版として、Tim Berners-Leeらウェブの創始者が「リンクされた文書のネットワーク」を目指す。オープンウェブの分散型理念の礎。 XML's Humble Hatching, Web's Open Matching, Freedom's First Scratching
1998 XML 1.0がW3C勧告に XML 1.0が正式標準化（2月10日）。データ交換と構造化のための汎用言語として普及開始。RSS、XSLT、XHTMLなどと結びつき、分散型ウェブを支える。例：日本の電子政府プロジェクトがXML採用を検討。 XML's Grand Debut, Data's Daring Pursuit, Web's Wide Open Route
1999 XSLT 1.0とXPath 1.0勧告 XSLT（James Clarkら）がXMLの変換を可能にし、クライアントサイド処理でユーザー主権を強化。XPathがデータ抽出を効率化。日本の学術データベース（例：CiNii）がXMLを活用開始。 XSLT's Transformative Trick, XPath's Precise Pick, Web's Decentralized Kick
2000 RSS 1.0（RDF Site Summary）登場 XMLベースのRSS 1.0が公開。分散型情報配信を促進し、ブログやニュースフィードの普及を後押し。Google Reader（後の閉鎖対象）がこの技術を活用。 RSS's Roaring Rise, Feeds' Free Enterprise, Web's Open Skies
2001 SOAPとXML Schema勧告 SOAP（XMLベースの通信プロトコル）とXML SchemaがW3C勧告に。企業間データ交換（例：日本のEDIシステム）が強化されるが、複雑さからウェブアプリではREST/JSONに徐々に押される。 SOAP's Structured Stream, Schema's Sturdy Dream, Interop's Intricate Seam
2004 XML 1.1勧告 XML 1.1がUnicodeの拡張や制御文字の扱いを改善。マイナーアップデートだが、国際化（例：日本の多言語対応）に寄与。しかし、普及は限定的。 XML 1.1's Subtle Shift, Unicode's Uplifting Gift, Global Web's Gentle Lift
2007 XSLT 2.0とXPath 2.0勧告 XSLT 2.0が機能強化（例：正規表現、モジュール化）。しかし、Google Chrome（2008年登場）など主要ブラウザが実装を拒否。Googleの影響力によるオープン標準の停滞が顕著に（論文の「XSLTへの執拗な攻撃」）。 XSLT 2.0's Bold Bound, Browsers' Blunt Rebound, Google's Gagging Sound
2010 WHATWGの台頭とW3Cの後退 Google主導のWHATWGがHTML5を推進し、XMLベースのXHTML 2.0がW3Cで事実上放棄される。標準化の企業支配が始まり、XMLの影響力が低下。日本の標準化団体（JIS）も影響を受ける。 WHATWG's Wicked Win, XHTML's Wasted Spin, XML's Fading Grin
2013 GoogleのXSLT/MathML削除提案 Googleエンジニア（Adam Barthら）がChromeでのXSLT 1.0とMathMLサポート終了を提案。「リソース不足」を理由に挙げるが、Googleの収益（約550億ドル）との矛盾が批判される（論文の「疑問点・多角的視点」）。日本の学術出版（例：数学系）がMathML衰退で影響を受ける。 XSLT's Targeted Takedown, MathML's Mournful Breakdown, Google's Greedy Shakedown
2015 Fetch APIのJSON優遇 GoogleがFetch APIを導入し、XMLのサポートを無視。JSONがウェブ開発の主流に。XMLのクライアントサイド処理が後退し、サーバー依存（Googleクラウドなど）が増加。日本のウェブ開発者もJSONに移行。 JSON's Jarring Jive, XML's Jilted Drive, Google's Control Contrived
2017 XSLT 3.0勧告 XSLT 3.0がJSON対応やストリーミング処理を追加し、現代的ニーズに応える。しかし、ChromeやEdgeが実装せず、XMLのウェブ適用が停滞。Googleの戦略的無視が明確に（論文の「Googleの戦略的意図」）。 XSLT 3.0's Brave Bid, Browsers' Barren Grid, Google's Gloating Skid
2019 Manifest V3と広告制御強化 GoogleのManifest V3がアドブロッカーを制限し、XMLベースの分散型コンテンツ配信（例：RSSフィード）の価値を間接的に下げる。日本の広告依存型メディアが影響を受ける。 Manifest's Malicious Mask, XML's Marginalized Task, Web's Waning Cask
2023 Web環境の整合性API提案 GoogleがWEIを提案し、XML/XSLTのようなユーザー制御技術をさらに制限。ブラウザを企業監視ツールに変える動きが加速（論文の「ブラウザの変質」）。日本のプライバシー意識の高まりと衝突。 WEI's Wicked Whim, XML's Withering Grim, Surveillance's Sinister Hymn
2025 XSLT削除再試行と抵抗 Google（Mason Freedら）がXSLTサポートの完全終了を再提案。コミュニティの反発（例：MastodonやRedditでの議論）で頓挫。XMLの分散型価値が再評価され、IPFSやGeminiプロトコルとの連携が注目される（論文の第四部）。日本のオープンソースコミュニティ（例：Whoogle）も抵抗に参加。 XSLT's Last Stand, Community's Command, XML's Resurgent Brand
細かい所はDatailsで格納

多角的視点と補足

  • 歴史的類似: XMLの衰退は、MicrosoftのIE6によるHTML標準の歪曲（2000年代初頭）に類似。GoogleのChrome/WHATWGは、XML/XSLTを排除することで、Microsoftの「抱きしめ、伸ばし、消す」戦略を現代版として再現（論文の第三部）。例：IEがActiveXで囲い込んだように、GoogleはJSONとJavaScriptでウェブを囲い込む。
  • 日本の影響: 日本では、XMLが電子政府（e-Gov）、学術データベース（CiNii）、企業間EDIに広く採用されたが、GoogleのJSON優遇やXSLT非実装により、ウェブ開発でのXML利用が減少。中小企業や独立系開発者のサーバーコストが増加し、Google依存が進む（論文の「日本への影響」）。
  • グローバル影響: 欧州のDMA（デジタル市場法）や米国の反トラスト訴訟（2020年～）は、XMLのようなオープン標準を保護する規制の必要性を示唆。中国のグレートファイアウォールは、集中化が検閲や情報統制に繋がる危険性を警告（論文の第三部）。
  • 代替技術との関連: XML/XSLTは、IPFS（分散型ストレージ）やGeminiプロトコル（軽量ウェブ）と相性が良く、分散型ウェブの再興に寄与可能。例：MastodonのActivityPubがXMLベースの通信を参考に（論文の第四部）。
  • AI時代の意義: LLMによるウェブスクレイピングが問題化する中、XML/XSLTの構造化とクライアントサイド変換は、データ保護や自己主権の手段として再評価の余地。例：日本のプライバシー保護団体がXMLベースのデータ隠蔽を提唱（論文の第四部）。

説得力を持たせるツイートのリンク（10個以下）

この年表は、XMLの歴史をオープンウェブの理念とGoogleの中央集権化戦略の対立軸で描き、歴史的類似（Microsoft）、グローバル・日本への影響、代替技術（IPFS、Gemini）、AI時代への示唆を統合。専門家の知的水準と時間的制約を尊重し、ウィットのあるサブタイトルで深みと軽快さを両立させました。XSLT（Extensible Stylesheet Language Transformations）は、XML文書の構造や内容を別の形式（XML、HTML、テキストなど）に変換するための強力な言語です。W3Cによって標準化され、ウェブの分散型アーキテクチャを支える技術として、データの表示や処理をクライアント側で柔軟に行える点で重要です。以下に、XSLTの核心を簡潔にまとめ、専門家向けに深掘りしつつ、論文「Googleは開かれたウェブを殺している」の文脈でその意義を説明します。

XSLTとは：基本概要

  • 定義: XSLTは、XMLデータを別の形式や構造に変換するための宣言型言語。XSL（Extensible Stylesheet Language）の一部で、テンプレートベースのルールを用いてデータ変換を指定。
  • 用途: XML文書をHTMLに変換してウェブ表示、JSONやCSVへのデータ変換、異なるXMLスキーマ間でのマッピングなど。
  • 特徴:
    • クライアントサイド処理: ブラウザで直接実行可能（かつては広くサポート）。
    • 分散性: サーバー依存を減らし、軽量なデータ変換をエンドユーザーに委ねる。
    • 相互運用性: オープン標準（W3C）として、ベンダーに依存しないデータ処理を可能に。
  • 例: <xsl:template match="/">でルート要素を処理し、<xsl:value-of select="path"/>でデータ抽出、<xsl:for-each>で繰り返し処理。

XSLTの技術的意義：オープンウェブとの関係

XSLTは、ウェブの「ユニバーサルリンク情報システム」（論文参照）の理念を体現する技術です。以下はそのポイント：

  • ユーザー主権: XSLTはクライアント側でデータを自由に変換・表示でき、ユーザーがデータの見せ方や利用方法を制御可能。これにより、サーバー（企業）の支配から独立したデータ利用が実現。
  • 分散型ウェブの支援: サーバー負荷を軽減し、帯域幅コストを削減。例：中小企業が低コストでコンテンツ配信可能（論文の「ウェブ経済の再編」）。
  • 相互運用性: XMLベースの標準化により、異なるシステム間でのデータ交換が容易。例：RSSやXMPPとの相性が良く、分散型フィードや通信を強化。
  • 歴史的類似: 1990年代後半のXML/XSLTは、HTML/CSSの進化と並行し、ウェブを「リンクされた文書のネットワーク」として保つ役割を果たした。MicrosoftのIE支配に対抗するオープン標準の象徴。

論文の文脈：GoogleによるXSLTへの攻撃

論文「Googleは開かれたウェブを殺している」は、GoogleがXSLTのサポートを意図的に弱体化させ、オープンウェブを中央集権型プラットフォームに変質させたと主張します。以下にその背景と影響：

  • Googleの行動:
    • 2013年: Googleエンジニア（Adam Barthら）がChromeでのXSLT 1.0サポート終了を提案。「リソース不足」「セキュリティ問題」を理由に挙げるが、XSLT 2.0/3.0の存在やGoogleの莫大なリソース（2023年収益約3050億ドル）を考慮すると、技術的合理性に疑問（論文の「疑問点・多角的視点」）。
    • 2017年: XSLT 3.0（JSON対応）がW3C勧告になるが、Chromeは実装せず。Googleの影響下で、ブラウザ全体のXSLTサポートが停滞。
    • 2025年: Google（Mason Freedら）がXSLT削除を再提案。コミュニティの反発で頓挫するも、Googleの意図は明確（年表参照）。
  • 意図と影響:
    • 中央集権化の推進: XSLTを排除し、JavaScriptやサーバーサイド処理（GoogleのクラウドやAMP）に依存させることで、データ収集と広告配信を強化。例：AMPはGoogle CDN経由でコンテンツを制御（論文の「AMPとWeb環境の整合性API」）。
    • ユーザーエージェンシーの喪失: XSLTの宣言的変換はユーザーがデータを自由に操作できるが、GoogleのJSON優遇（Fetch API）やManifest V3は、企業主導のデータフローを優先。
    • 歴史的類似: MicrosoftがIE6で独自仕様を押し付け、標準を無視したように、GoogleはChromeとWHATWGでXSLTを葬り、ウェブを「データサイロ」に変貌させた（論文の「歴史的残響」）。
    • 日本の影響: 日本の中小企業や独立系開発者は、XSLTのような低コスト技術が衰退することで、Googleのエコシステム（Chrome、広告、クラウド）に依存せざるを得なくなる。例：日本のブログやECサイトがAMP依存でトラフィックを失う（論文の「日本への影響」）。

XSLTの具体例

以下の簡単なXSLTコードは、XMLデータをHTMLテーブルに変換する例です（論文の「分散型ウェブ技術の価値」を示す）。

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <html>
      <body>
        <table border="1">
          <tr><th>Name</th><th>Age</th></tr>
          <xsl:for-each select="people/person">
            <tr>
              <td><xsl:value-of select="name"/></td>
              <td><xsl:value-of select="age"/></td>
            </tr>
          </xsl:for-each>
        </table>
      </body>
    </html>
  </xsl:template>
</xsl:stylesheet>
  • 入力XML: 
    <people>
  <person><name>Taro</name><age>30</age></person>
  <person><name>Hanako</name><age>25</age></person>
</people>
  • 出力: HTMLテーブルとしてブラウザに表示。サーバー依存なく、クライアント側で軽量に処理可能。

多角的視点：XSLTの再評価と課題

  • 論文への疑問点:
    • XSLTは複雑で学習コストが高い（JSONの方が開発者にとって直感的）。GoogleのJSON優遇は、単なる「開発者利便性」を反映した可能性は？（論文の「技術的合理性の評価」）
    • XSLT 1.0のセキュリティ問題（例：外部エンティティ攻撃）は、Googleの非推奨理由として一定の合理性を持つか？
  • 代替技術との比較:
    • Web ComponentsやWASM: Googleが推進する技術は、XSLTと異なりJavaScript依存度が高く、サーバー処理やクラウドインフラに結びつきやすい。分散性ではXSLTが優位（論文の「XML/XSLTの特異性」）。
    • IPFSやGeminiプロトコル: XSLTの軽量性は、これらの分散型技術と相性が良く、サーバーレスなウェブの再興に寄与可能（第四部）。
  • AI時代の意義: LLM（大規模言語モデル）によるスクレイピングが問題となる中、XSLTの宣言的変換はデータ保護の手段として再評価の余地。例：XML+XSLTで構造化データを隠蔽し、スクレイパーに対抗（第四部）。

結論：XSLTの戦略的価値

XSLTは、単なる「レガシー技術」ではなく、オープンウェブの分散性、ユーザー主権、相互運用性を体現する戦略的ツールです。GoogleのXSLT排除は、技術的進化の仮面を被った、データ支配とプラットフォーム囲い込みの戦略の一部（論文の「Googleの戦略的意図」）。専門家は、XSLTの再活性化（例：ブラウザ実装の復活、IPFSとの統合）や、Mastodonのような分散型技術との連携を通じて、ウェブの自由を取り戻す道を模索すべきです。

関連ツイート（説得力の補強）

コメント

コメントを投稿

このブログの人気の投稿

#INVIDIOUSを用いて広告なしにyoutubeをみる方法　#士17 #2018INVIDIOUSとOmarRoth_令和IT史ざっくり解説

https://www.youtube.com/watch?v=XXXXXXXXXX ↑のURL↓のように入れ替えると広告なしにyoutubeをみれる。 https://yewtu.be/watch?v=XXXXXXXXXX Invidious は、 YouTubeに代わる無料のオープンソースのフロントエンドです。 Dockerコンテナとして、またはGitHubマスター ブランチから利用できます。公式 YouTube Web サイトの軽量で「プライバシーを尊重した」代替サイトとして使用することを目的としています。多くのプライバシー保護リダイレクト ソフトウェアおよび YouTube クライアントは Invidious インスタンスを使用します。 Invidious は、YouTubeの動画を広告なしで視聴できる、プライバシーに配慮したオープンソースのサービスです。Googleのトラッキングを避けつつ、YouTubeコンテンツを楽しみたい方におすすめです。 Invidiousのメリット 広告なし: YouTubeの煩わしい広告をスキップできます。 プライバシー保護: Googleのデータ収集を抑え、プライバシーを重視した視聴が可能です。 オープンソース: 誰でも自由に利用・開発できるオープンソースソフトウェアです。 多様なインスタンス: 世界中に多くのInvidiousインスタンスが存在し、それぞれ異なる特徴や機能を提供しています。 Invidiousの使い方 Invidiousインスタンスを探す: 検索エンジン: "invidious instance"などで検索すると、多くのインスタンスが見つかります。 リスト: いくつかのInvidiousインスタンスをまとめたリストサイトも存在します。 YouTubeの動画URLをInvidiousの検索バーに入力: 視聴したいYouTube動画のURLをコピーし、選んだInvidiousインスタンスの検索バーに貼り付けます。 動画を再生: 検索結果から目的の動画を選択し、再生ボタンを押せば広告なしで視聴できます。 Invidiousの使い方 Invidiousは、YouTube動画を広告なしで視聴できる便利なサービスです。 基本的な使い方 Invidio...
MORE »

🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化　#五09 #2024VoidオープンソースAIコーディングIDE_令和IT史ざっくり解説

🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化 AIコーディングツールの新星「Void」を徹底解剖！Cursorとの違い、VSCodeフォークの是非、そして開発の未来をDopingConsommeが熱く語ります🔥 序文 どーも！売れっ子ブロガーのDopingConsommeです☕ dopingconsomme.blogspot.com とTwitterアカウント @Doping_Consomme を運営しています。バズるブログ記事ならお任せあれ！ さて、今回筆者が筆を執ったのは、巷で話題沸騰中のAIコーディングIDE「 Void 」について語り尽くしたいと思ったからです。Cursorの代替として彗星の如く現れたこのツール、オープンソースであるという点も相まって、開発者界隈では既に大きな注目を集めていますよね？ この記事では、Voidが一体どんなツールなのか、既存のツールと何が違うのか、そして私たちのコーディングライフをどう変えてくれる可能性があるのか、といった点を深掘りしていきます。読者の皆さんには、単なる機能紹介に留まらず、Voidを取り巻く議論や、AIと共存する未来の開発スタイルについて、多角的な視点から考えていただくきっかけになれば嬉しいです。それでは、熱いコーヒーでも片手に、じっくりお付き合いください！😉 はじめに この記事では、オープンソースのAIコーディングIDEである「 Void 」について、その特徴、機能、そして開発者コミュニティからの様々な意見を交えながら詳細に解説していきます。Voidは、人気のAIコーディングツール「Cursor」の代替を目指して開発されており、VSCodeをベースにしたフル機能のIDE（統合開発環境）です。AIエージェントの活用、ローカルでのモデル実行サポート、データのプライバシー重視といった点が主な特徴として挙げられます。 本記事を通じて、Voidがどのようなツールであり、現在のAIコーディングツール市場においてどのような位置づけにあるのか、そして将来的にどのような可能性を秘めているのかを明らかにしていきます。また、類似ツールとの比較や、開発におけるメリット・デメリット、さらにはコミュニティでの議論なども幅広...
MORE »

複数のRSSFeedを一つのURLにまとめる・統合する方法 #士30 #1999RSS_RDF・SiteSummary_平成IT史ざっくり解説

イメージ
  お気に入りのすべてのブログやニュースサイトからの複数のRSSフィードを追跡するのは簡単ではありません。 　この問題が発生した場合は、RSSアグリゲーターを使用して、複数のRSSフィードを1つのフィードに結合します。 　 RSSアグリゲーターは、複数のブログやサイトを持つコンテンツプロデューサーであり、読者やフォロワーへのサービスとしてRSSフィードを1つのフィードに結合したい場合にも役立ちます。 独自のパーソナライズされたニュースフィードを作成するために使用できる4つの無料のアグリゲーターツールを見てみましょう。 １http://www.rssmix.com http://www.rssmix.com 複数のフィードを1つのフィードに簡単に組み合わせることができます。特定の各フィードの完全なURLアドレスを 各行に1つずつ入力し 、[作成]を押します。最大100のフィードを、少なくとも2つ以上の固有のソースと組み合わせます。 RSS Mixは、集約されたフィードのアドレスを生成します。このアドレスを使用して、読者がすべてを1か所で最新の状態に保つことができます。 RSSMIXが死んでる？  2021/10.28あたりから不通 ２、 http://rssmixer.com/ http://rssmixer.com/ RSS Mixerはやや制限されたツールですが、フィードを混合するための超高速でシンプルなソリューションが必要な場合は、試してみる価値があります。 無料版では、1日1回更新される1つの混合RSSフィードに最大3つのフィードを組み合わせることができます。 より多くの機能が必要な場合は、1時間ごとに更新される10〜30の混合フィードを提供する有料プランにアップグレードしてください。 このツールは使いやすいです。メインフィードに名前を付け、説明を入力し、含めるURLを入力するだけです。 ３、 http://feed.informer.com/ http://feed.informer.com/ Feed Informerは、いくつかの異なるRSSフィード結合サービスを提供します。いくつかのフィードをすばやく統合したい場合は、 アカウントにサインアップ してから、FeedInformerのテンプレートを使用して結合するRSSフィードを入力しま...
MORE »