P1
今日は、ハイパーレイヤリングと呼ぶWeb地図のためのアーキテクチャについて、どのようなものなのか、WWWの発展においてどのような意義を持っているのかを　知っていただこうと思います。
このアーキテクチャは、技術というよりむしろ情報化社会の哲学に近く、W3Cが掲げた「真の分散型・ユーザー第一のWeb」ビジョンを直接推進する力になると考えています。
P2
今日お話しする内容は、2024年のＡＣミーティングでお話しした内容をより深く掘り下げたものです。
P3
Web上で多くの災害対策に有効なたくさんの情報が、しかも地図の形で公開されているにもかかわらず、それらを一枚の地図上で自由に簡単に合成できない状況があります。
これが、防災情報の有識者の間で広く認識されている、 WWW の重大な課題です。
これは、情報システム業界において非常によく知られたサイロ化の問題といえるでしょう。
そしてそこに欠けているのは「相互可用性」ですね。
P4
皆さんご存じのように、地図上に様々な地理情報を重ねて可視化する仕組み、マッシュアップは2004年ごろには実用化され、Web2.0の代表的な機能の一つでした。
これは、この図のようにアグリゲーションサービスを行うサーバによって実現されます。
では、なぜこの問題は20年も前に解決しなかったのか？ それをこのあと探求していきます。
P5
マッシュアップの問題点を見ていきましょう。
真ん中のサービスが相互可用性のかなめとなり、必要なデータを全て収集しなければなりません。
特に災害時は、アドホックな処理と大量のアクセス対応が必要で、多大なコストとともに単一障害点でもあります。
また、優越的な立場と利権を得た事業者間の競争により、皮肉にも新たなサイロが形成されました。
さらに、集約サービスは複雑な権利関係の調整を伴う情報複製と再配信が必要です。
これは権利侵害の問題に直結しています。
中央集権的なWeb2.0は、ワールドワイドウェブの存続そのものを危うくする構造的な欠陥を抱え、変革の時期が迫っています。
P6
そして、この問題意識は私たちだけでなく、W3Cも共有しています。
W3C Visionの運用原則を参照すると、中央集権化の回避とユーザー第一の原則は、先に指摘した構造的な欠陥と明確に一致します。
あえてこれらをビジョンに明記しなければならないほど、ワールドワイドウェブは危機的状況に達しているといえるでしょう。
P7
そこで、30年以上前の原初のWebを見直してみましょう。
ティム・バーナーズ・リーが実装した WWW は、「URLによるハイパーリンク」と「ユーザー側のブラウザによる統合」という、極めてシンプルな基本理念の上に成り立っていました。
この理念こそが、相互可用性を当初から実現していました。
ここにはアグリゲーションサービスは存在せず、自律分散です。
驚くことにマッシュアップサービスが持つ沢山の問題点は存在しないのです。
P8
この原初の WWW のアーキテクチャを継承し、地図メディアの上で発展させたものが、ハイパーレイヤリングアーキテクチャです。
考案は1996年、阪神淡路大震災に関するディスカッションがきっかけでした。
P9(アニメーション豊富なので説明の流れはなるべく忠実に)
その基本的な振る舞いを見てみましょう。
特徴的なのは収集サービスが存在しないことです。
リンク集が、様々なレイヤーのURLを発信します。
まず、ユーザーがレイヤーを選択すると、ブラウザはハイパーリンクを辿りコンテンツにアクセスして表示します。
通常のハイパーテキストと異なり、この時もリンク集は維持されたままです。
次に、ユーザーが別のレイヤーを選択します。
すると、今度は地図上にそのレイヤーが重なって表示されるのです。
この「ハイパーリンクを活用した重ね合わせ」こそが、ハイパーレイヤリングです。
裏では、分散したサイトの情報を、ユーザーが主導して端末上で統合する。
これは、『中央集権化の回避』と『ユーザー第一』の原則に基づく、Vision for W3Cに描かれたWebのあるべき姿です。
しかし、そのご　クラウド型の地図サービスが広く浸透し、ハイパーレイヤリングの描いたビジョンは現実的ではなくなっていきます。
次にその挫折の経緯をご紹介します。
P10
私たちはこの四半世紀、SVGをベースに標準化に取り組みましたが、難航しました。
国内はJIS化しましたが、主導力はありません。
W3CのSVGワーキンググループでも達成できていません。
これには複数の要因があります。
まず、ウェブブラウザは個々のサービス体験を高める機能拡充に傾き、情報統合や相互可用性というWebの根幹の原則が、クラウド側の役割として軽視されていきました。
また、SVGの標準化とブラウザへの実装に長い年月がかかったことも一因でしょう。
P11
次に、ハイパーレイヤリングアーキテクチャの実用化の葛藤を見ていきましょう。
我々がW3Cで基本を確立した2000年前後以降、クラウドコンピューティングとサーバによるマッシュアップが台頭し、地図サービスが広まります。
このような状況において、ハイパーレイヤリングアーキテクチャが描いた理想は果たして可能だったのでしょうか。
P12
地図サイトへのリンク集は作れますが、リンクを選んでも個々のサイトに遷移するだけで、肝心のレイヤリングが不可能なのです。
P13
理由は単純です。
当初はウェブ上で共通の地図形式が確立することを前提としていました。
我々はそれをSVGに期待していましたが、現実は違いました。
P14
現実のデータ形式はバラバラ（GeoJSON, 独自CSV, PNGタイルなど）です。
さらに、HTML5やモダンブラウザの進化とともに、情報統合などの高度な処理はサーバ側で実行され、ウェブブラウザは独自のウェブアプリを実行する、「孤立したウェブサイト専用のダム端末」になってしまいました。
その結果、ユーザーはデータや体験を自由に持ち運ぶ権利を失い、ブラウザはWebの相互可用性のエンジンとしての役割を失ったのです。
P15
このような状況の中、我々は2011年の大震災を体験します。
クラウドコンピューティングの課題も明らかとなり、ハイパーレイヤリングの価値は捨てきれず、挫折の課題を解決する方法の模索が始まりました。
そこで生まれたのがLayers as Web Appsです。
P16(ここもアニメーション多用している)
Layers as Web Appsは、コンテンツやデータだけではなく、ブラウザ上で動くJavascript・HTML・CSSで構成されるウェブアプリケーションそのものをレイヤーとみなします。
ご覧のように、図の中央にLayers as Web Appsを配信するサーバーが新しく加わりました。
そして端末側には、これをプラグインし、実行する機構を持った、svgmapjsと呼ぶフレームワークソフトウェアを動作させます。
Layers as Web Appsの配信にもURLを使いますので、まとめサイトはこれまでと同様にURLでリンクします。
ユーザーがレイヤーを選択すると、svgmapjsフレームワークがリンクを辿り、そのコードをクライアント上にロードして実行します。
Layers as Web Appsは、独自のデータ形式やプロトコルのデータにアクセスし、それをsvgmapjsで表示可能なデータに変換して、レイヤリング表示します。
また、気象予報の日時指定など、レイヤー独自のUIもここで実装されます。
さて、ここでお気づきになった方もいらっしゃると思いますが、このLayers as Web Appsは、地図サービス毎に別のものを用意しなければなりません。
誰がどうやって、この膨大な数になるLayers as Web Appsを用意するのでしょう？ここが課題です。
P17
ウェブブラウザが基本的にオープンソースであるのと同様、地図のブラウザと言える環境ですので、私たちはオープンソースとしてハイパーレイヤリングアーキテクチャの実装に取り組んでいます。
先ほど課題とした、サービス毎に必要なLayers as Web Appsについて説明します。
私たちは力業で大量のレイヤーを開発し、これまでに、1000を超えるレイヤーの統合を実現しています。
この数は恐らく異種の地図情報サービスの統合において、世界最大でしょう。
P18
長い年月を経て、ハイパーレイヤリングアーキテクチャの実用化が始まっています。
KDDI社内では15年以上の実用実績があり、大量のLayers as Web Appsの開発とフレームワークの熟成も進みました。
いよいよ社外での実用化も始まってきました。
KDDIでは防災マップボードと呼ぶサービスも今秋開始される予定です。

TPACのブレークアウトセッションでは、地図技術の専門家だけでなく、Webの中央集権化の回避や利用者・ブラウザを中心とした相互可用性に関心を持つ、W3C内の戦略的な協力者が得られれば嬉しく思います。