1．さまざまな産業に応用されるWeb標準

インターネットの開発から50年，そしてインターネット上で構築されたアプリケーション体系であるWebの開発から30年が経った．Webは，1989年に欧州原子核研究機構（CERN）[1],[2]において，Tim Berners-Lee[3],[4]らによって開発が開始されたが，時代とともにWebで扱うコンテンツは多様化し，マルチメディア対応かつインタラクティブなコンテンツの需要が飛躍的に増加した結果，Webコンテンツは単なる「Webページ」から「Webアプリケーション」へと変遷を遂げ（図1），今や，以下の事例を含むさまざまな環境で利用されている：

• PC，スマートフォン，タブレット
• テレビ，ビデオデッキ，セットトップボックス
• デジタルサイネージ
• 電子書籍
• 車載情報システム（カーナビ，オーディオ，エアコン等）
• デジタルカメラ
• ゲーム機
• 家電機器（エアコン，掃除機，冷蔵庫，洗濯機等）

本稿では，近年，Webがデジタル情報通信社会の基盤となり，さまざまな産業領域やサービスに応用されている状況を踏まえ，まず，第2章でW3C[5],[6]によるWeb技術の国際的標準化について概観するとともに，第3章でWeb標準化の基本的な流れについて説明する．続いて，第4章では，W3C日本事務局スタッフとして，2005年よりWeb国際標準化の現場でさまざまな標準化活動に携わってきた筆者の経験に基づいて，近年ますます広がりを見せるWeb技術のさまざまな産業応用について，特に一般的な社会生活への貢献が大きいと考えられる，いくつかの具体的な技術トピックを例示しつつ，その技術トピックが具体的にどのようなWeb標準によって実現されているのかを概説する．その上で，最後に，第5章で，Web応用の将来展望として，産業横断的なデータ流通プラットフォームとしてのWebに対する期待について，やはり，筆者が今までにかかわってきたDIDやVC，そして新たに始まりつつあるSmart Citiesの取り組み状況を踏まえて考察する．

2．W3CによるWeb標準化の概要

Webは世界中で共通的に利用されるが故に，その相互運用性，国際化，入出力方法の多様性および利用者への親和性を保証する必要があり，そのためW3C等による国際的な技術標準化が継続して行われている．たとえば，第1章で触れたとおり，時代とともにWebで扱うコンテンツが多様化し，マルチメディア対応かつインタラクティブなコンテンツの需要が増大した結果，Webコンテンツを従来の方法で表現することが難しくなってきたため，2008年，W3Cにおいて新しいWebアプリケーション記述言語としてHTML5[7], [8]の策定が開始された．

W3CにおけるWeb国際標準化作業の詳細は「W3Cプロセスドキュメント」[9]に定義されているが，以下では，W3Cの組織構成および標準化議論の概要について説明する．

2.1　W3Cの組織概要

W3Cは，Webの可能性を最大限に導き出すことを目的として，Web技術発明者であるTim Berners-Leeにより1994年に設立された産業コンソーシアムであり，アメリカのマサチューセッツ工科大学計算機科学人工知能研究所（MIT/CSAIL）[13]，フランスに本部を置く欧州情報処理数学研究コンソーシアム（ERCIM）[14]，日本の慶應義塾大学（Keio）[15]，および中国の北京航空航天大学（Beihang）[16]という4つのホスト機関（事務局）により共同運営されている．2022年2月現在，Google，Apple，Mozilla，Microsoft，Siemens，Intel，Oracle，富士通，日立，三菱電機，東芝，ソニー等，世界中のさまざまな業種からなる約500の企業・団体等が会員としてその活動に参加している．

2.2　W3C議論グループ

W3Cの標準化活動は，対象とする技術トピックごとに，（1）Working Group（WG）[11]，（2）Interest Group（IG）[11]，（3）Business Group（BG）[12]，（4）Community Group（CG）[12]等の議論グループ単位で取り組まれている．WGがWeb標準であるW3C勧告（W3C Recommendation）の策定を行う一方で，IGは仕様策定の基礎としてWeb技術応用に関する産業界やユーザのニーズ（ユースケース；Use Cases）および，ユースケース実現に必要な技術要件（Requirements）の検討を行う．また，BGはWeb技術のビジネス応用に関する議論を行い，CGはWeb技術全般に関して，W3C以外の標準化団体や各種Webコミュニティ等との連携を含めた基本検討を行う．これらの4種類の議論グループは，HTML5[7],[8]やCSS[17],[18]等の標準化対象技術トピックごとに設立されるが，その際，必ずしもすべてのグループ（WG/IG/BG/CG）が設立されるとは限らず，議論の目的に応じて必要なグループのみが設立される．たとえば，HTML5のようにW3C勧告を策定することが目的の場合，WGだけを設立する．また，基本検討だけを行い，W3C勧告の策定は行わない場合，CGだけを設立する場合もある．

一方，図2に示すとおり，4種類の議論グループは関連した技術トピックに応じて連携しており，IG，BGおよびCGで検討したUse CasesおよびRequirementsを関連のWGに入力し，入力されたUse CasesおよびRequirementsに基づいて，WG側で具体的なWeb標準策定に取り組むことも多い．なお，WGで策定するW3C勧告以外に，IGでは，Use CasesおよびRequirements，Web標準実装のガイドライン，既存システム実装のベストプラクティス等を文書（IG Note）としてとりまとめることがある．また，CGでも，自身のUse CasesおよびRequirementsの検討結果に基づいて，Web標準の案を文書（CG Report）としてとりまとめることがある．

2.3　W3C特許方針

W3Cの標準化活動にあたっては，「W3C特許方針」[10] に規定されているとおり Royalty-Free の大原則があり，W3C仕様書中に「Normative（規定的）」に記述された内容については，すべて無償で公開する必要がある. この特許方針に則って，W3C勧告仕様（W3C Recommendation）はすべてW3Cサーバ上で無償公開されており，HTMLやCSS等のWebコンテンツを検証するための各種ツール類（バリデータ，テストスイート等）も無償公開されている．また，W3Cプロセス[9]に基づいて，すべてのW3C仕様書には実装があり，それらの中には，オープンソースで公開されているものもある．Royalty-Free特許方針，実装主義，およびオープンソース等の効果もあり，W3C標準は世界中のさまざまな産業で利用されている．

3．Web国際標準化の基本的な流れ

W3CにおけるWeb国際標準化作業の詳細は「W3Cプロセスドキュメント」[9]に定義されているが，以下では，特に重要と考えられる下記4つの観点から概説する：

• W3Cワークショップ（W3C Workshops）
• 議論グループ設立（Group Creation）
• 仕様策定作業（W3C Standardization）：Use Cases, Requirements, Gap Analysis, Implementation & Tests, Deployment
• ほかの標準化団体との連携（Liaisons with the other SDOs）

また，おおまかな流れを図3に示す．

3.1　W3Cワークショップ（W3C Workshops）

具体的な標準化活動の開始に先立って，W3C会員企業以外の技術者を交えて，世界中の技術者から広く応用事例や要求目に関する意見を集める必要が生じた場合，「W3Cワークショップ」[25]と呼ばれる公開会議を開催し，ユースケースや要件の洗い出し，および今後の標準化の方向性に関する意見の集約を行う．

3.2　議論グループ設立（Group Creation）

W3Cワークショップでの議論の結果，「新しい議論グループが必要」という結論に至った場合，あるいは会員企業から新規グループ設立の提案があった場合，それらに基づいて，新しい議論グループを設立する．なお，2.2節で説明したとおり，W3Cの標準化活動は，WG，IG，BG，CGといった議論グループ単位で取り組まれるが，このうち，「Web標準策定」に直接関連しているのは，WGおよびIGであり，これらの設立にあたっては，まず，グループ議長とW3C事務局スタッフが協力して「Charter」[26]と呼ばれる設立趣意書を作成し，「各グループで標準化する対象となる文書」や「その標準化範囲および標準化スケジュール」について明確化した上で，実際の設立手続きを進める．

3.3　仕様策定作業（W3C Standardization）

W3Cにおける標準仕様策定作業は，各議論グループごとに規定された「Charter」[26]（設立趣意書）に基づいて進められるが，図3の「Basic Lifecycle of the W3C Standardization」に示すとおり，基本的に産業界およびユーザのニーズ（ユースケース）に基づいて以下の流れで取り組まれる：

• Use Cases（ユースケース）：産業界およびユーザのニーズに基づいて，標準技術の必要とされる状況について明確化する．その際，期待される一連の動作や，関連するデータの流れ等も含めて，できる限り詳細を記述する．
• Requirements（要件）：ユースケース実現に必要な技術要件を明確化し文書化する．
• Gap Analysis（ギャプ分析）：必要とされる技術要件が，すでに存在する標準技術で担保されているかどうかを見極める．
• Specification Generation（仕様策定）：技術要件に基づいて，必要とされる標準技術を仕様書（W3C勧告；W3C Recommendation）の形で策定する．
• Implementation & Tests（実装とテスト）：策定した仕様書の規定的（Normative）な記述内容が実装可能であることを，2つ以上の実装で検証する．
• Deployment（社会実装）：W3C勧告として公開された標準仕様を世の中に普及させ，実際の産業界で利用してもらう．世界中で利用された結果を受けて，さらなる改善が求められた場合は，バージョンアップのサイクルに入り，あらためてユースケース議論から始める．

また，W3C標準は，「W3Cプロセスドキュメント」[9]に定義されているとおり，W3CのWeb標準（W3C勧告；W3C Recommendaton）は，図4に示す4段階を経て策定される：

• Working Draft（WD；草案）：まず，産業界およびユーザから得たユースケースおよび技術要件に基づいて，仕様の草案[27]を公開する（上記および図3のUse CasesおよびRequirementsの時期に対応）．その際，既存の標準技術ですでに実現可能かどうかの分析も行う（上記および図3のGap Analysisの時期に対応）．なお，一番最初に公開されるWD のことをFPWD（First Public Working Draft）と呼ぶ．
• Candidate Recommendation（CR；勧告候補）：次に，定例の電話会議やF2F会議，およびGitHub上での非同期な議論を経て仕様内容が確定した時点で，仕様を勧告候補[28]として公開する．勧告候補公開に合わせて，広く一般に対して仕様に基づく実装を呼びかけるとともに，世界中から集められた実装により，仕様の実装可能性を検証する（上記および図3のImplementation & Testsの時期に対応）．
• Proposed Recommedation（PR；勧告案）：さらに，各仕様ごとに実装が2件以上得られた場合，仕様を勧告案[29]として公開する．
• W3C Recommedation（REC；W3C勧告）：その後，あらためて全W3C会員による査読を経た上で，仕様をW3C勧告[30]として公開する．

上記したとおり，W3C標準化では，標準化手続きのうち，PR公開に際して「2件以上の実装と，それらによる仕様の実装可能性検証」が必須であるため，仕様がCRとして公開されるのに先立って，「仕様書に基づいて実装の動作確認を行うためのテスト」を作成した上で一般の実装者に提供し，CR公開からPR公開までの期間で，「仕様に基づく実装が2件以上存在すること」および「それらの実装により，仕様書に規定されている機能が実装可能であること」を確認する．ここで「テスト」とは，たとえば，HTML5仕様書の場合，仕様に含まれる機能を具体的にWebブラウザで確認するために，HTML5[7]，CSS[17]およびJavaScript[31]の組合せとして生成されたWebアプリケーションのことを意味する．テスト作成にあたっては，仕様の記述に基づいて，各機能ごとに「どういう条件（入力）のとき，どういう結果（出力）を得るか」という言明文（「アサーション」と呼称）を作成した上で，機能確認に漏れがないようにする．

なお，実装とテスト作成は，PR公開までに完成していればよいが，当該仕様に含まれる機能が複雑な場合，（1）仕様に基づくソフトウェアやハードウェアの実装，および（2）仕様に含まれる機能のすべてを確認するためのテストの作成には多大な労力と時間を要する可能性があるため，FPWD公開時点等，仕様開発のできるだけ早期に，「実装とテスト作成」を含めた仕様開発スケジュールを立案するとともに，標準化作業の進行を随時管理し，CR公開に合わせてテストを公開することが推奨されている．

3.4　ほかの標準化団体との連携（Liaisons with the other SDOs）

仕様の内容が，関連する各種標準化団体の取り組みと矛盾なく整合するよう，W3CにおけるWeb標準化議論は，関連標準化団体と連携しつつ進められる．なお，関連標準化団体との連携は，ユースケース，要件，ギャップ分析等の基礎的議論にはじまり，他団体で策定する標準とW3C標準との整合性確保に関する議論を行う．また，それぞれの標準の実装を実際に相互接続することにより，相互接続性の確認も行う．

連携対象の標準化団体の代表的な例について，国内および海外に分けた上で以下に示す：

国内の標準化団体：

• ARIB（Association of Radio Industries and Businesses；（一社）電波産業会）[32]
• DSA（Data Society Alliance；（一社）データ社会推進協議会）[33]
• ECHONET（（一社）エコーネットコンソーシアム）[34]
• IPTV フォーラム（（一社）IPTV フォーラム）[35]
• TTC（The Telecommunication Technology Committee；（一社）情報通信技術委員会）[36]
• IPA DADC（（独）情報処理推進機構 デジタルアーキテクチャ・デザインセンター）[37]

海外の標準化団体：

• CTA WAVE (The WAVE (Web Application Video Ecosystem) Project, hosted by the Consumer Technology Asso- ciation (CTA) ) [38]
• ETSI (European Telecommunications Standards Institute) [39]
• ISO/IEC JTC1 [40]
• IEC SC 3D [41]
• IETF[42] / IRTF [43]
• ITU-T [44]
• OCF (Open Connectivity Foundation) [45]
• oneM2M [50]
• OPC [51]

4．Web標準の産業応用事例

第1章で触れたとおり，近年，Webはデジタル情報通信社会の基盤となり，当初の目的であったWebページの閲覧にとどまらず，ハードウェアやOSに依存しないアプリケーション開発のプラットフォームとして，さまざまな産業領域やサービスに応用されているが，W3Cでは，Webの産業応用のために必要となる標準技術全般を想定した上で，W3C自体が取り組むWeb標準（W3C勧告および一部CGレポート）に加え，関連標準化団体の標準技術を総括して「Open Web Platform」と呼んでいる（図5）．

筆者はW3Cの4つのホスト機関（MIT，ERCIM，KeioおよびBeihang）の1つである慶應義塾大学所属のW3C事務局スタッフとして，2005年より現在までの17年間にわたって，「Web標準の産業応用」を軸とした，さまざまな技術トピックの標準化に取り組んできた．以下では，Web標準の産業応用に関して，筆者自身がW3C事務局スタッフとして直接携わった以下の5つの事例について，図6に示すとおり「Web標準と，その産業応用」の対応関係を解説する：

• 音声エージェント（Voice Agent）
• コネクテッドTV（Connected TV）
• 電子書籍（eBook）
• コネクテッドカー（Connected Car）
• IoT

なお，Web国際標準化活動は，各議論グループの議長，議長以外のグループ参加者，およびW3C事務局スタッフが協力し，作業を分担した上で取り組んでいくべきものである．そこで，筆者は，日本側のユースケース，要件，仕様化提案，実装およびテスト等を議論グループへより積極的に入力していくべく，「日本側議論」および「W3C国際標準化議論」のバランスについて考慮しながら進めてきた（図7）．その際，W3C日本会員企業の有志を組織化し，日本側での，国際標準化議論に関する情報共有を行うとともに，コネクテッドTV，電子書籍，コネクテッドカーおよびIoTに関しては，W3C会員企業以外も含めた業界関係者により構成され，総務省がその活動を支援する民間の検討会（Web and TV検討会，テキストレイアウト検討会，Webとクルマ検討会，およびWoT検討会）も活用した上で，情報共有やユースケース提案等に取り組んできた．

以下では，各技術トピックごとに，その活動内容について，次に挙げる5つの観点から解説する：

• 日常生活とのかかわり
• 関連するWeb標準
• 標準化概要（特に日本側での議論）
• 今後の展望

4.1　音声エージェント

4.1.1　日常生活とのかかわり

音声エージェントは，Webアプリケーションにおいて，音声認識や音声合成を含む複数のインタフェースモダリティを利用した高度なユーザインタフェースを提供するものであり，アクセシビリティおよびユーザビリティの観点から重要である．近年，音声エージェントはスマートフォンやスマートスピーカ等を用いた音声入出力として一般的に利用されており，キーボードやマウス等の操作デバイスを持たない，テレビやスマート家電等の機器を制御するための使いやすいユーザインタフェースとして重要な役割を果たしている．

4.1.2　関連するWeb標準: 音声マルチモーダル

音声マルチモーダル標準は，音声エージェント実現の基盤となる技術であり，その基本的仕様として以下が挙げられる：

• Web Speech API [52]
• SSML（Speech Synthesis Markup Language；音声合成）[53]
• PLS（Pronunciation Lexicon Specification；音声合成のための発音辞書）
• SRGS（Speech Recognition Grammar Specification；音声認識）[54]
• SCXML（State Chart XML；状態遷移管理）[55]
• MMI Architecture（マルチモーダルアプリケーション構築のための基本アーキテクチャとアプリケーションライフサイクル制御のためのイベント定義）[56]
• EMMA（音声マルチモーダルアプリケーションのためのデータモデル）[57]

上記関連仕様のうち，Web Speech APIは，Webブラウザや，Webブラウザを組み込んだ各種デバイス（テレビ，スマート家電，ドングルデバイス等）で広く用いられており，Webアプリケーション中のJavaScriptで音声合成や音声認識を実現するためのAPIだが，Speech API CGによるCGレポートであり，正式なW3C勧告化はされていない．一方，SSML，SRGS，SCXML等は，その基礎となった W3C勧告仕様であり，Speech APIにおける音声合成時に，アクセントや読みがな等の，音声合成対象に関する詳細な入力情報を SSML を用いて指定することができる．また，Webブラウザに依存しない音声エージェント実装においては，直接，SSML，SRG，SCXML等を利用する場合もある．なお，SSML，SRGS，およびSCXMLはVoice Browser WG（VBWG）[58]にて，MMI ArchitectureおよびEMMA は Multimodal Interaction WG（MMI-WG）[59]にて標準化活動が行われていたが，2022年時点ではいずれもすでに活動を終了している．

4.1.3　関連するW3Cワークショップ

3.1節に述べたように，W3Cでは，具体的な標準化活動の開始に先立って，各議論グループにおける議論に加えて，グループ参加者以外の世界中の技術者から，広く応用事例や要求項目に関する意見を集めるために，「W3Cワークショップ」[25]と呼ばれる公開会議を開催し，ユースケースや要件の洗い出し，および今後の標準化の方向性に関する意見の集約を行う．

音声マルチモーダル標準化に関しては，音声合成の国際化対応に関する問題，たとえば，日本語や中国語における同音異義語表現上の問題^☆1に関する以下のワークショップが開催された：

• Workshop on Internationalizing the Speech Synthesis Markup Language (SSML) in Beijing (2005.11) [60]
• Workshop on Internationalizing the Speech Synthesis Markup Language (SSML) II in Crete, Greece (2006.5) [61]
• Workshop on Internationalizing the Speech Synthesis Markup Language (SSML) III in Hyderabad, India (2007.1) [62]

また，通常，コンピュータのユーザインタフェースとして用いられるGUI（Graphical User Interface；ディスプレイ，キーボード，マウス等）に加えて，音声インタフェース（音声認識および音声合成）やジェスチャーインタフェース（静止画認識および動画認識），さらには温度・湿度・位置等の各種センサ情報やバイブレーション・アクチュエータ等によるユーザへの情報フィードバックをユーザインタフェースのために利用する「マルチモーダル統合」に関する以下のワークショップが開催された：

• Workshop on W3C’s Multimodal Architecture and Interfaces in Fujisawa (2007.11) [63]
• Workshop on Speaker Biometrics and VoiceXML 3.0 in Menlo Park (2009.3) [64]
• Workshop on Conversational Applications in New Jersey (2010.6) [65]
• Workshop on Emotion Markup Language in Paris (2010.10 ) [66]
• W3C Workshop on Rich Multimodal Application Development in New Jersey (2013.7) [67]

4.1.4　標準化概要（特に日本側での議論）

W3C標準化に対する，日本からのより積極的な参加を促すべく，W3C日本会員からなるMMI-WGの日本サブグルー（「MMI-JP」と呼称）を設立し，日本語による情報共有と意見交換を行った上で，MMI-WGへの提案を行った（図7中の「MMI-JP」）．これにより，W3C日本会員の研究開発成果に基づく提案をユースケースおよび要件定義としてMMI-WGで取り組む仕様書（MMI Architecture[56]，EMMA[57]，EmotionML[68]等）へ入力することができた．また，通常のWG 議論に加えて，関連するW3Cワークショップを開催することにより，国際化対応やアクセシビリティ対応等について，W3C非会員も含む世界中の技術者，研究者から広く意見を集約し，SSML[53]，SCXML[55]，MMI Architecture[56]，EMMA[57]等に対する貴重なユースケースおよび要件を得ることができた．しかしながら，ユースケースおよび要件定義に基づく具体的なWeb標準策定に対しては，日本側からの貢献はあまりなされず，SSML，SCXML，MMI Architecture等の基本的仕様は，欧米主導で議論が行われた後，日本からの提案を基本仕様に追加する形で進められ，日本発信の積極的な国際標準化議論を実現するには至らなかった．

4.1.5　今後の展望

近年では，数年前のPCよりも強力な処理能力を持つスマートフォンが利用可能となるとともに，携帯ネットワーク網やWi-Fiネットワーク網の整備が進み，音声認識技術を利用した音声入力や，音声合成を利用した音声出力がスマートフォン上のアプリケーションとして一般的に利用されている．そういった技術的環境を背景として，2021年のTPAC（Technical Prenary and Advisory Meetings；W3Cの技術総会）等で，「あらためて，次世代の音声マルチモーダル技術に関する標準化について一考する価値があるのではないか」という提案が寄せられており，2022 年前半での開催を目指して，音声マルチモーダル処理のさらなる高度化に関する議論を行うための「スマートエージェント」に関するW3Cワークショップが企画されている．

4.2　コネクテッドTV

4.2.1　日常生活とのかかわり

近年，テレビ受像機（以下，単に「テレビ」）には，放送波からのコンテンツを映すためのチューナに加えて，Web上のコンテンツを映すためのブラウザが搭載されており，テレビのリモコンには，チューナからの放送コンテンツを切り替えるためのチャンネルボタンに加えて，Webコンテンツを切り替えるためのOTTサービス^☆2の切り替えボタンが搭載されている．テレビに搭載されているブラウザも，基本的にはPCやスマートフォンに搭載されているブラウザと同様の機能を持っており，HTMLとCSSにより構成されたWebコンテンツを解析した上で，テレビ画面に映している．

なお，テレビにおける放送と通信の融合（いわゆるコネクテッドTV）については，世界中でいくつかの異なる方式が取り組まれているが，日本ではHybridcast[73]という方式が IPTVフォーラム[35]にて検討・標準化されている（ヨーロッパではHbbTV方式[74]，米国ではATSC方式[75]が取り組まれている）．技術的な観点から言うと，Hybridcastの実行環境としてWebブラウザを利用するメリットとして，TVのハードウェアやOSの違いに縛られないアプリケーションを開発することが可能となることが挙げられる．また，アプリケーションの動作確認テストにあたって，ハードウェアやOSに依存しないWebブラウザ上のテストとして一元化することができる．

4.2.2　関連するWeb標準：Web and TV

Web and TV技術は，Web上での動画配信のためのプラットフォームを提供するものであり，近年では，YouTube[72]等Web上での動画配信に加えて，Hybridcast等の「放送・通信連携サービス」の基盤としても利用されており，その基本的仕様としてHTML5[7]およびTTML（Timed Text Markup Language）[76]が挙げられる．また，世界中のメディア配信関連事業者（放送・通信・データ配信・コンテンツ提供等）と連携しつつ，動画のストリーミング再生（MPEG-DASH）[77],[78]やコンテンツ管理（Common Encryption）[79],[80]，TVとスマートフォンの同期（Presentation API）等の機能拡張の要件について議論がなされており，具体的な動画配信および放送連携サービスに必要とされる機能追加の基礎となるMedia Source Extensions（MSE）[82]やEncrypted Media Extensions（EME）[83]等もHTML5の拡張として利用されている^☆3．

Web and TV技術の標準化活動には，以下のようなさまざまなメディア関連のW3Cグループが協力しつつ取り組んでいる：

• Web and TV IG（Media and Entertainment IG；MEIG）[85] ^☆4（Webを応用したメディア配信全般）
• Timed Text WG [86]（字幕関連）
• Web Fonts WG [87]（文字表示用フォント）
• HTML WG [88], [89], [90] ^☆5（HTML5関連）
• HTML Media Extensions WG [91]（HTML5 拡張）
• Second Screen WG [92]（Second Screen 同期）
• Media WG [93]（Webにおけるメディア配信のための機能拡張定義）
• Web Platform Incubator CG [94]（Webプラットフォーム全般への改善要求）

上記のうち，Web and TV IGは，関連グループ間の連携をスムーズに行うための情報共有と交通整理に取り組むとともに，関連グループに対してユースケースや要件に関する入力を行ってきている．なお，W3Cは，Web上のビデオストリーミングにおける字幕情報（TTMLおよびWebVTT）により第67回（2015年度），HTML5.1/5.2におけるアダプティブストリーミング（MSE）およびコンテンツ保護（EME）により第70回（2018年度），そして，Webとテレビ向けのカスタムフォント（Web Fonts）により第73回（2021年度）の技術・工学エミー賞を授与されている．

4.2.3　標準化概要（特に日本側での議論）

次世代のデジタルTVに向け，既存の放送モデルとは異なる新しいインタラクティブなメディア配信モデルに対して，放送，通信，家電等，さまざまな業界からのニーズが高まっていることを受けて，以下の4回のW3Cワークショップが開催された：

• Web on TV Workshop in Tokyo (2010.9) [95]
• Second W3C Web and TV Workshop in Berlin (2011.2) [96]
• Third W3C Web and TV Workshop in Hollywood (2011.9) [97]
• Fourth W3C Web and TV Workshop in Munich (2014.3) [98]

さらに，Webコンテンツにおける，色空間やダイナミックレンジの拡張に関する議論，およびWeb技術を応用したコンテンツ作成に関する以下のワークショップが開催された：

• W3C Workshop on Wide Color Gamut and High Dynamic Range for the Web (2021.9) [99]
• W3C/SMPTE Workshop on Professional Media Production on the Web (2021.11) [100]

また，近年，次世代のデジタルTVに向け，既存の放送モデルとは異なる新しいインタラクティブなメディア配信モデルに対して，放送，通信，家電等，さまざまな業界からのニーズが高まっていることを受けて，W3C標準化活動とは独立して日本側でも，2010年に，関連業界各社が参加し総務省がその活動を支援する検討会（Web and TV検討会）が設立され，Web and TV議論に関する国内での日本語による情報共有を行ってきている（図7中の「Web and TV検討会」）．さらに，Web and TV IGへの意見入力を想定した具体的な仕様検討を行うため，検討会の作業部会も設立され，ユースケースおよび要件の洗い出しが行われてきている．

また，IPTVフォーラムとの連携議論に関しては，W3Cでの公式なリエゾン関係を結んだ上で，日本側で，日本語による追加の連携議論を持ち，放送コンテンツとWeb技術の融合を実現させるために必要とされる「次世代ブラウザ」に関するユースケースと要件についての入力を得てきている．

4.2.4　今後の展望

上でも触れたとおり，Hybridcastの実行環境としてWebブラウザを利用するメリットとして，TVのハードウェアやOSの違いに縛られないアプリケーションを開発することが可能となることが挙げられる．また，アプリケーションの動作確認テストにあたって，ハードウェアやOS に依存しないWebブラウザ上のテストとして一元化することができる．さらに，既存の放送事業者以外の新しいコンテンツ提供事業者（Webコンテンツ事業者等）が参入することにより，SNS等と連携した，より有益でユーザ訴求度の高いサービスを提供することが可能になる．また，図5に示すようなさまざまなWeb標準と連携することにより，さまざまな視聴者の状況や環境に応じてコンテンツを伝達するために必要な，アクセシビリティや国際化対応，そしてセキュリティやプライバシーの保護といった，Open Web Platformに基づくコンテンツ配信のメリットを享受することが可能になる．

一方で，実サービスと密接にリンクした標準化については，通常のWeb技術のように継続して機能拡張議論を行っていくことは困難であり，今後，「Web技術拡張フェーズ」および「実装とサービス展開フェーズ」という2つのフェーズのタイムリーな組合せについて検討する必要がある．

4.3　電子書籍

4.3.1　日常生活とのかかわり

近年，電子書籍は，電子インクを利用した専用のリーダ機器のみならず，スマートフォン上のアプリケーションやPC上でも閲読することが可能となっているが，電子書籍コンテンツは，Webページと同様にHTMLとCSSで記述されており，これにより，ハードウェアやOSに依存せず，さまざまな環境やデバイスでの閲読が可能となっている．

出版科学研究所の調査[101]によると，出版業界の売り上げは，消費税が3％から5％に増税された1997年以降，下降の一途をたどっており，特に雑誌市場は需要が加速度的に下降している．一方で，2016年には書籍と雑誌の売り上げが逆転するとともに，2010 年代半ばからは電子コミックの市場成長が著しく，電子市場におけるコミックのシェアは8割超で推移しており，コミックが紙・電子ともに出版市場全体を支える構造になっている^☆6．

4.3.2　関連するWeb標準：EPUB

• Publishing@W3C [102]
• – EPUB 3 WG [103]
• – Audiobooks WG [104]
• – Publishing BG [105]
• – Publishing CG [106]
• CSS WG [107]
• SVG WG [108]
• HTML WG [88], [89], [90]
• I18N（Internationalization）WG [109]
• XSL WG [110]
• Japanese Layout Task Force [111], [112]

4.3.3　標準化概要（特に日本側での議論）

2008年より，日本語組版の専門家，我が国における国際化および標準化活動の専門家，およびW3C XSL，CSS，SVGおよび国際化ワーキンググループの有志により，XSL，WG，CSS WG，SVG WGおよびInternationalization Core WG の共同タスクフォースとしてW3C Japanese Layout Task Force[111]が設立され，JIS X 4051（日本語文書の組版方法）[113]に基づいて日本語Webコンテンツのレイアウトに関する技術要件が「Requirements for Japanese Text Layout（JLREQ）」（日本語組版処理の要件）[114]としてとりまとめられてきた．なお，W3C Japanese Layout Task Force（JLTF）は，2018年からはW3C Internationalization（I18N）WGのタスクフォース[112]として改組され，Webの国際化の観点で活動を継続している．

一方，日本側では，より高度なテキストレイアウトをWebベースで実現するために必要となるさまざまな知見を得るために， W3C標準化活動とは独立して，2010年より，出版業界を含む関係各社が参加し，総務省がその活動を支援する検討会（次世代Webブラウザのテキストレイアウトに関する検討会）が設立され，議論を継続している（図7中の「テキストレイアウト検討会」；以下，本文中でも「テキストレイアウト検討会」）．このテキストレイアウト検討会により，W3C会員企業以外の出版社も含めた，我が国の出版業界の国際化対応に関するニーズをより積極的かつ直接的に吸い上げることを目的として，以下の2回のフォーラム会合が開催された：

• 次世代電子出版とWeb表現技術フォーラム in 東京（2011.5）[115]
• 次世代電子出版とWeb表現技術フォーラム in 京都（2011.6）[116]

そこでの議論を受ける形で，Web表現技術から見たテキストレイアウト，特に，日本語書籍でよく用いられる縦書きレイアウトをはじめとする，テキストレイアウトの国際化対応に関する課題について議論するために，以下の4回のW3Cワークショップが開催された：

• W3C Workshop on Electronic Books and the Open Web Platform in NY (2013.2) [117]
• Second W3C Workshop on Electronic Books and the Open Web Platform in Tokyo - eBooks and i18n : Richer Internationalization for eBooks (2013.6) [118]
• W3C Workshop on Publishing using the Open Web Platform - Publishing and the Open Web Platform in Paris (2013.9) [119]
• W3C Workshop on Digital Publication Layout and Presentation (from Manga to Magazines) (2018.9) [120]

これらのフォーラムおよびワークショップでの議論に基づいて，以下のような出版業界のニーズが，関連W3Cグループに対して，特にテキストレイアウトに最も関係の深いCSS WGに対して重点的にフィードバックされた：

• 電子出版における表現技術の今後（EPUBでできることと，できないこと）
• レイアウトにおける文字とフォント（美しく多様なフォントの利用）
• CSSにおける将来の日本語レイアウト（縦書き，ルビ，ページ区切り等）
• 雑誌や新聞における記事レイアウト（縦書きと横書きの混在，表示文字数，解像度，ディスプレイの大きさとの兼ね合い等；文字や行レベルの操作に加えてコマ割りやページレベルのレイアウト操作が必要）
• 電子出版コンテンツ製作フロー（雑誌，小説，絵本，辞書等，コンテンツごとの差異あり）

その結果，Webコンテンツのテキストレイアウトに関するW3C標準の改善版（CSS Writing Modes Level 3）[121]が2019年12月にW3C勧告として公開され，これによって，ルビ等も含めた，基本的な縦書きの機能がWebで表現できるようになった．

上記で触れた2回のフォーラム会合および4回のW3Cワークショップで得た知見と，関連する W3Cグループ（I18N WG，CSS WG，SVG WG，XSL WGおよびJLTF）の関係性について図8に示す．

なお，Webコンテンツのテキストレイアウト高度化，特に縦書き表現の実現に関しては，上記フォーラム会合開催や，国内外のコミュニティおよび業界関係者間の調整等，テキストレイアウト検討会による貢献も大きく，2018年度グッドデザイン賞[122] および2020 年度情報通信技術賞（総務大臣表彰）[123]を授与されている．

4.3.4　今後の展望

2008年から2018年にかけては，2回のフォーラムおよび4回のワークショップ等で得た知見をJapanese Layout Task Force，および各関連WGへ個別に入力する必要があったため，WG間の連携をより円滑に進めるために，連携のとりまとめをする新しいグループの設立が望まれていた（図8の「Possible new group for Web layout」）．

その期待に答える形で，2018年以降は，図9に示すとおり以下の5グループが協力しながら「Publishing@W3C Activity」としてアクセシビリティやCSS等の関連グループと連携した標準化議論を進めている：

• EPUB仕様のVer.3に取り組むEPUB3 WG
• 音声読み上げブックの標準化に取り組むAudiobooks WG
• 出版業界のニーズを吸い上げる中心的な役割を担うPublishing BG
• 将来に向けた弾込めの議論に取り組むPublishing CG
• 音声・ビデオデータとWebベース出版の同期について議論するSynchronized Multimedia for Publications CG

Publishing@W3C Activityが設立された2018年以降は，業界ニーズに基づくユースケースや要件は，まず，「Publish‐ing@W3C活動」に入力される．そして，関連グループの中で，Publishing BGが，全体の交通整理のハブとなり，Web上での出版高度化（より豊富な機能を持ち，より美しい表現を可能とし，よりユーザフレンドリで，コンテンツ作成も容易）にあたっての問題を洗い出すとともに，関連グループと連携しつつその問題の解決に取り組む．たとえば，ビジネス上のニーズと技術的な要件について，先に触れた Media and Entertainment IG（MEIG）と連携し，Web上のコンテンツ配信という観点で（1）AR/VR技術を活用した仮想空間でのコンテンツ配信，（2）オーディオブックの相互互換性向上，および（3）電子出版における音声と動画の同期メカニズム等について検討していく．

一方，日本側では，Publishing@W3Cへの意見入力を想定した具体的な仕様検討を行うため，2012年にテキストレイアウト検討会の分科会（電子書籍関連分科会）が設立され，ユースケースや要件の洗い出しとともに，既存の標準仕様の問題点に関する具体的な議論が行われている．

4.4　コネクテッドカー

4.4.1　日常生活とのかかわり

コネクテッドカーは「ネットワークに接続された自動車」[142]であり，車速やハンドル切れ角等のさまざまな自動車情報を取得した上で，Webベースの標準化により，位置情報取得やマップサービス等，既存の各種Webアプリケーションと柔軟に連携（マッシュアップ）した高度なサービスを可能とし，車載IVI（In-Vehicle Infotainment）やカーナビ等への応用が期待されている（図10）．

4.4.2　関連するWeb 標準：Automotive/Geolocation

• 第1期：2015〜2016年[125]
• – Vehicle Data[150]（自動車内情報の定義）
• – Vehicle Information APIs[130]（車内情報を取得するAPI 定義）
• 第2期：2016〜2018年[126]
• – Vehicle Signal Server Specification[131]（自動車内情報を取得するためのWebSocketサーバ側インタフェース定義）
• – Vehicle Signal Client Specification[132]（自動車内情報を取得するためのWebSocketクライアント側インタフェース定義）
• 第3期：2018〜2021年[127]
• – Vehicle Information Service Specification（VISS）[156]（自動車内情報を取得するためのWebSocketサーバ側インタフェース定義；GENIVIで定義されるVehicle Signal Specificationに依存）
• – Restful Service Interface（VISSに基づいて提供される車内情報をRESTインタフェースで取得するAPI；Volkswagenからの提案[134]ベース）
• – Typical Vehicle Services（自動車情報，メディア，ナビゲーション等の車内情報を提供するサービス定義；Volkswagenからの提案[134]ベース）
• 第4期：2021〜現在[128]
• – Vehicle Information Service Specification（VISS）[156]（自動車内情報を取得するためのWebSocketサーバ側インタフェース定義；GENIVIで定義されるVehicle Signal Specification に依存）
• – Vehicle Information Service Specification（VISS）Version2 - Core[135]（VISS の後継; REST インタフェースでのデータアクセスに関するメッセージレイヤを定義；VISS同様，GENIVIで定義されるVehicle Signal Specificationに依存）
• – Vehicle Signal Service Specification（VISS）Version2 - Trasnport[136]（VISS の後継；RESTインタフェースでのデータアクセスに関する通信プロトコルを定義；VISS同様，GENIVIで定義されるVehicle Signal Specificationに依存）
• – Vehicle Remote Procedure Calls（VISSで確立されたパターンを引き継いだ上で，車内情報に変わって，自動車の持つ機能を定義し，RPC プロトコルにより取得; 未公開）
• – Vehicle Signals Specification Ontology（VSSo）[137],[138]（GENIVIで定義されるVehicle Signals Specificationに基づいくオントロジー定義．W3C Spatial Data on the Web WGで策定するTime Ontology in OWL，Semantic Sensor Network Ontology（SSN）およびSensor, Observation, Sample, and Actuator（SOSA）Coreオントロジーを活用；Institut Mines-T´el´ecomおよびBMWからの提案[139]ベース）

一方，Geolocation技術は，GPSセンサや加速度センサ等の出力を元に，位置や向きに関する情報を所得するものであり，すでにスマートフォン等で，地図サービスや経路案内サービスに広く用いられている．その標準化活動は，当初，Geolocation WG[140]で取り組まれていたが，2017年以降は，Devices and Sensors WG[141]に引き継がれている．

4.4.3　標準化概要（特に日本側での議論）

W3Cにおけるコネクテッドカー関連標準化の開始に先立って，まず，2012年11月に，イタリアのローマにおいてW3C Web and Automotive Workshop[146]が開催され，自動車メーカ，部品メーカ，ソフトウェアデベロッパ等を含む63名の参加者により，次世代コネクテッドカーサービス，車両データ取得用API，HMI拡張，自動車データの利活用等，「Web技術のコネクテッドカーへの応用」に関する議論が行われた．その結果を踏まえて，2013年2月にW3C Automotive and Web Platform BG（Auto BG）[147]が設立され，標準化のための基礎検討が開始された．また，2015年2月にW3C Automotive WG[124]が設立され，Auto BGでの基礎検討を引き継ぐ形で，「自動車情報をWebアプリケーションで利用するためのAPI仕様案」[148],[149]および「Web アプリケーションから利用する対象となる車内情報」[150]に関する検討が開始された．

上記W3C国際標準化議論を受けて，日本側でも，2012年8月に自動車メーカ，部品メーカ，ソフトウェアデベロッパーが参加し，総務省がその活動を支援する検討会（Web とクルマに関する検討会；当初は「勉強会」として設立）が設立され，Automotive議論に関する国内での日本語による情報共有と検討を行うとともに，仕様案に関する具体的な議論を行う作業部会が設立され，ユースケースおよび要件の洗い出しが行われてきている．筆者も検討会の委員および作業部会の座長として，この活動に参加している．また，2014年12月には，W3C慶應ホスト主催の「Webと車のセミナー」[151]が開催され，（1）Auto BGの活動状況とWG設立の紹介，および（2）なぜW3Cに参加しているか（なぜW3CでWebと車の標準化に取り組んでいるか）に関する議論が行われた．さらに，2015年3月には，自動車情報に関するAPI仕様案が議論されている状況を受けて，「Webとクルマに関する検討会」参加者からなるアイディアソン実行委員会により，アイディアソン[152]が開催され，「車載カメラで取得される映像の活用」，「人とクルマに優しいデータ教則アプリ」，「ひたすら赤信号を避け続ける経路案内サービス」等．API仕様案を実際に車に応用する際のアイディアについて議論がなされた．さらに，単にアイディアを議論するのみならず，Webアプリケーション開発を実際に体験するハッカソン[153],[154],[155]が，やはり「Web とクルマに関する検討会」参加者からなるハッカソン実行委員会により，2016〜2018年に渡って開催され，2日間の開催日程の間に，実際にWebアプリケーションを開発するとともに，その有用性について評価が行われた．この際，開発環境として，API仕様案に基づくJavaScript APIのプロトタイプ実装に加えて，（1）実際に自動車を走行させて取得した各種車内データおよび（2）フロントガラス前方のビデオ映像を同期させて取得できる開発環境が提供された．

4.4.4　今後の展望

上記したとおり，Automotive/Geolocationの活動については，欧米におけるコネクテッドカー関連ビジネスの出現とタイミングを同じくしつつ，日本側でも2012年から，ビジネスニーズ，ユースケースおよび要件に関する検討を開始することができた．しかしながら，2015年からの4期の活動期間において，仕様策定の方向転換が発生し，標準化対象トピックが，当初の「自動車情報をWebアプリケーションで利用するためのAPI仕様案」[148],[149]および「Webアプリケーションから利用する対象となる車内情報」[150] から，「車内情報を自動車サーバからWebSocket経由で取得する低レベルAPI」[156]および「RESTインタフェースとWebSocketを併用したAPI」[157]に変更となるとともに，「Webアプリケーションから利用する対象となる車内情報」については，自動車情報の標準化団体であるGENIVI[158]のデータ定義[159]を参照することとなった．そのため，「日本側で検討してきた，API仕様案や車内情報定義」を最終的なWeb標準としてW3C勧告化することはできていない．

現在，Automotiveに関するW3C国際標準化議論は，Jaguar Land Rover，Volkswagen，Volvo等，欧州自動車メーカが主導しており，自動車メーカを含め，我が国からのより積極的な標準化のための体制づくりが望まれる．対策案の1つとして，次に述べるWeb of Things（WebによるIoTの相互連携）の標準化活動は，すでに日本側での積極的な標準化議論がなされていることから，コネクテッドカーをIoTの1つのユースケースとして，Web of Things標準化の文脈で議論し，車内情報の取扱に必要な用語については，世界共通のオントロジーを柔軟に参照する方針が考えられる．

4.5　IoT

4.5.1　日常生活とのかかわり

スマートホームに代表されるIoT技術が提案されてから20年が経過し，さまざまなデバイスやセンサ類がインターネット経由で相互に接続されるようになってきているが，その実装方法や規格はベンダや産業領域ごとに異なっていることが多く，いまだに相互接続が難しいという，いわゆる「IoTサイロ化」の状況にある（図11）．

一方，第1章で触れたとおり，近年，HTML5をはじめとするWeb技術は，TVやビデオ配信，ゲーム，電子書籍等，さまざまな産業に応用されており，Webは今やインターネット上におけるデータ流通のプラットフォームとなっている．そこで，W3Cでは，2015年より，Web 技術を用いてIoTを相互連携させる「Web of Things（WoT）」の標準化に取り組んでいる．図12に示すように，WoTというWeb ベースの標準的フレームワークにより，さまざまな企業によって開発されたIoT デバイスやIoTアプリケーション同士を，Web アプリケーションのマッシュアップのように統一的な形で相互接続することが可能となり，公共インフラの維持管理や高齢化対策など，さまざまな社会的課題の解決手段として期待される．なお，これらのIoTデバイスやIoTアプリケーションの中には，既存IoT標準（oneM2M[50]，OCF[45]，BACnet[46]，ECHONET[34]，OPC[51]等） を参照しているものと，AWS（Amazon Web Services）[47]やGoogle Home[48]等，各企業が独自開発した技術が広く普及しているものが含まれる．

4.5.2　関連するWeb標準：Web of Things（WoT）

Web of Things技術は，既存のさまざまなIoT（Internet of Things）フレームワークを相互接続することを目的としており，（1）WebのID（URI）とメタデータ（Thing Description）[160]，（2）それらを制御するためのAPI（Scripting API）[161]，（3）さまざまなIoTフレームワークで利用されるプロトコルやデータフォーマットのWoTメタデータへの変換方式を定義するBinding Templates[162]により構成される．なお，W3Cでは，WoT標準の社会実装に向け，さまざまな産業領域向けユースケースの抽出，要件整理を行うとともに，定期的（四半期ごと）にWoT標準に基づく相互接続実証実験（PlugFest）に取り組んでおり，図13に示すように，マルチベンダによるIoTデバイスおよびIoTアプリケーションの相互接続性について検証している．

Web of Thingsに関する取り組みについては，スマートホーム（IoT技術のネットワーク家電への応用）やスマートビル等，すでにさまざまな技術開発とその事業化が進んでいる．このため，CR化／PR化において必要となる「仕様に基づく実装」や「テスト作成」の作業をスムーズに進めることができ，WoT Architecture Ver. 1.0[166]およびWoT Thing Description Ver.1.0[160]のW3C勧告化を達成することができた．

4.5.3　標準化概要（特に日本側での議論）

Web of Things技術は将来的に「IoTのサイロ化」（さまざまなIoTフレームワークが乱立し，相互接続が難しい問題）を解決するための技術として期待されているため，日本側でも，W3C日本会員からなるWoT-WGの日本サブグループ（「WoT-JP」と呼称）を設立し，日本語による情報共有と意見交換を行った上で，WoT-WGにおけるW3C国際標準化議論に対して，積極的な入力を継続している（図7中の「WoT-JP」）．これにより，W3C国際標準化議論へ取り組むにあたって，毎週開催される電話会議に先立って，日本側（JP Side）でWoT-JP会合を開催することにより，改善提案や各種検討結果報告を国際標準化（Global Standardization）のための電話会議やGitHub議論に対してタイムリーに入力していくことが可能となった．そして，日々のメール議論（Mailing List），電話会議（Telconf）やGitHub議論の結果を受けて，年に数回開催されるFace-to-Face会議（F2F Meeting）や接続デモ実験（PlugFest）への入力もスムーズに行うことができるようになっている．また，2018年12月には，W3C非会員企業も含めた関連業界各社が参加し，総務省がその活動を支援する検討会（WoT関する検討会）も設立され，Web of Things 議論に関するより広い情報共有が行われている（図7中の「WoT検討会」）．なお，日本からの意見をより積極的に国際標準に盛り込んでいくためには，日本語による情報共有や議論の場を設けることに加え，セミナーやアイディアソン等のイベント開催を通して，標準化およびその応用に対する関係各位（標準化活動参加者，関係省庁，Webコミュニティ参加者等）の関心を高めることも重要である．そのため，「WoT検討会」での検討結果に基づいて，今後，スマートシティ等への応用も期待されるWeb of Thingsのテーマについて，W3C標準策定のバックヤードとして，2020年1月にW3CWeb of Things Japanese CG（WoT-JP CG）が設立された（図14）．

WoT-JP CGでは，以下の4つのタスクフォースを設立した上で，日本人エンジニアの積極的な参加を支援するとともに，我が国におけるWeb of Things技術のさらなる普及のために必要とされる，情報共有，ツール作成，文書化，および新たな産業ニーズの発掘に取り組んでいる：

• ユースケース：業界ユースケースの発掘
• アウトリーチ：国内展開の加速と，WoT標準利用者の取り込み
• デプロイメント：WoT標準利用者を支援するべく，ライブラリ，ツール，文書等を作成
• 翻訳：日本人エンジニアの積極的参加を促すために，WoT仕様を英語から日本語へ翻訳

4.5.4　今後の展望

2022年現在，W3C Web of Things Working Groupでは，以下のような2つの観点（産業依存型垂直展開，および産業非依存型水平展開）から，新たなユースケースを対象に，主要な2つの仕様書の更新版である，WoT Architecture Ver. 1.1[167]およびWoT Thing Description Ver. 1.1[168]の策定に取り組んでいる：

産業依存型垂直展開：

• TV関連：メディア配信，番組連携，VR（Virtual Reality）/AR（Augmented Reality）
• スマート農業：ビニールハウス農場管理，水源管理
• スマートビル：環境管理，維持管理
• スマートシティ：位置情報管理，健康管理
• そのほか：小売業，交通，スマートグリッド，教育，医療等

産業非依存水平展開：

• マルチプロトコル連携
• ビッグデータ利用
• アプリケーションライフサイクル管理
• マルチモーダル連携
• AI活用
• エッジコンピューティング
• IoTオーケストレーション

なお，仕様検討にあたっては，ECHONET[34]，OPC[51]，OGC[49]，oneM2M[50]，OCF[45]，ETSI[39]等，関連するほかの標準化団体とも連携しつつ議論を進めており，今後も継続して，他団体の規格との相互接続性について確認を進めていく予定である．

5．Web応用の将来展望: 産業横断的なデータ流通の共通基盤へ

第4章では，筆者自身がW3C事務局スタッフとして直接携わったいくつかの事例について，「Web標準と，その産業応用」という観点から解説した．本章では，それら既存の標準化活動を踏まえて，Web技術が，各産業界のニーズに対応するにとどまらず，産業横断的なデータ流通の共通基盤へと変化しつつある事例として，関連する以下の2つの標準化について概説する．

• Decentralized Identifier/Verifiable Credential
• Smart Cities

5.1　DID（Decentralized Identifier）/VC（Verifiable Credential）

DID（Decentralized Identifier）は，直訳すると「分散ID」を意味するが，さまざまなWebアプリケーション全般で利用できる新しいタイプの識別子であり，グローバルに名前解決可能かつ，暗号化による検証が可能であることが特徴である．通常，Web上で利用される識別子（ユーザアカウント等）は，基本的に，中央集権的サービスプロバイダに依存しており，複数のサービスを利用する場合，サービス・プロバイダごとにアカウントおよびパスワードを登録する必要がある．一方，DIDの場合，利用者自身が分散台帳で直接管理することができる（Self-Sovereign）．

次に，Verifiable Credential（VC）は，直訳すると「検証可能な本人証明情報」であるが，物理世界で用いられる運転免許証（自動車等の運転資格を証明），学位記（大学や大学院を卒業し学位を取得したことを証明），および社員証（特定の会社等の社員であることを証明）等と同様に，Web上では，システムで検証可能な本人証明情報およびその証明情報のため識別子が必要となる．ここで，「システムで検証可能な本人証明情報」として提案されているのがVCであり，「その証明情報のための識別子」として提案されているのがDIDである．

たとえば，ホームセンタで化学肥料を大量に購入する場合，硝酸アンモニウムと軽油から爆弾を製造することが可能であることから，購入にあたっては，何らかの本人証明が必要となると考えられる．実店舗での購入の場合，本人証明として運転免許証を提示することが多いと考えられるが，厳密には，運転免許証には必要以上の情報が含まれる一方で，「爆弾を製造しない保証にはなっていない」という問題がある．一方，Web上での購入の場合，どのような方法で，「やりたいこと」に対して必要とされる信頼性や情報の公開が可能か，そのためにどういった仕組みが必要となるかを考えると，「物品購入のトランザクション中でやりとりされる，本人証明情報と，そのための識別子」が必要とされるが，個人のアイデンティティ自体は不要である．

ここで，「Web上の商取引に必要とされる識別子」について検討するために，物理世界での識別子の例について思い起こすと，たとえば，運転免許証では，免許証番号が「利用者の識別子」であり，発行元組織（公安委員会名）が「発行者の識別子」である．一方，Web上の識別子の例としては，Emailアドレス（利用者の識別子）やhttp://www.w3.org等のURL（発行者の識別子）が挙げられる．各種Webアプリケーションのアカウント（Google，Facebook，LinkedIn，Twitter等）も，それぞれ，「利用者の識別子」だが，サービス・プロバイダごとに，証明情報や検証メカニズムが異なり，ほかのサービスに共有することはできない．このため，利用者は，各サービスごとに（100 個のサービスを利用するなら100組の）アカウントとパスワードを管理する必要がある．なお，一般的なWeb上の識別子処理の流れは以下のとおりだが，識別子は発行者である各サービスプロバイダが発行し所有しており，保持者としての利用者に貸し出されている形であり，複数プロバイダ間のデータ可搬性に加えて，管理コストやセキュリティおよびプライバシー保護に関する問題がある：

• （1）Issuer：識別子の発行者（政府，雇用者等）が識別子を発行
• （2）Holder：保持者（市民，被雇用者等）が識別子を提示
• （3）Verifier：検証者（会社，銀行等）が提示された識別子で保持者を検証

これらの問題を改善し，誰にでも，そして，どのサービスプロバイダのどのようなサービスに対しても応用できるとともに，中央集権的な発行元に依存せず，かつ暗号化で保護された可搬な分散型識別子として，DIDが提案されており，以下の特徴を持っている：

• グローバルに名前解決可能
• 暗号化による検証が可能
• 中央集権的サービスプロバイダに非依存
• 利用者がブロックチェーン等の分散台帳により直接識別子を管理可能

DIDを利用した場合の識別子処理の流れは以下のようになる：

• （1）Issuer：発行者（政府，雇用者等）は個人が保持するDIDを取得．本人証明を発行
• （2）Holder：保持者（市民，被雇用者等）は自ら保持するDIDのプロファイルを提示
• （3）Verifier：検証者（会社，銀行等）は提示プロファイルに基づきDIDを取得した上で，保持者を検証

なお，VCおよびDIDの標準化状況としては，まず，VCについては，すでにVer 1.0[170]が2019年11月に，そしてVer 1.1[171]が2022年3月に，それぞれW3C勧告化されている．一方，DIDについては，2021年7月に，Proposed Recommendationとして公開されており，すでに100 件を上回る実装が存在するが，W3C勧告化に先立って，異なる実装間の相互互換性に関する議論が行われている．

5.2　Smart Cities

スマートシティは，ICT等の新技術を活用しつつ，データマネジメント（計画，整備，管理・運営等）の高度化により，都市や地域の抱える諸課題を解決するとともに，新たな価値を創出する，持続可能な都市や地域であり，すでに，北米，南米，欧州，東欧，中東，アジア等，世界中のさまざまな地域において，さまざまな形で取り組まれている．我が国においても，内閣府や内閣官房をはじめとしたさまざまな省庁において，Society 5.0[172]，スーパーシティ[173]，デジタル田園都市国家構想[174]等の取り組みが行われている．

一方で，スマートシティには多数の利害関係者（ステークホルダ）が存在することから，既存の国際的，あるいは国内的なスマートシティに関する取り組みを踏まえた上で，さまざまな国や都市環境の利害関係者からのニーズや問題点のフィードバック，そして複数のスマートシティ同士の相互接続性を担保するための標準化状況の調査等に関して，国際的な標準化を想定した連携議論のための場所づくりが望まれており，本稿でここまで触れてきたように，Web 標準がさまざまな産業やIoT全般，そしてユーザやサービスの識別子管理等のために広く利用されていることから，Smart Citiesに関する国際的Web標準化のニーズが高まっている．そこで，W3Cでは，2021年6月，スマートシティに関するワークショップ[175]を開催し，スマートシティの利害関係者，およびスマートシティ向けアプリケーション事例について議論するとともに，現状のさまざまな課題をWeb 技術でどう改善できるかに関する検討を行い，国際的連携議論の場としての，W3C Smart Cities Interest Group（Smart Cities IG）設立に向けたCharter（設立趣旨書） の案[176]を作成した．

さらに，2021年10 月に行われた，W3C の技術総会であるTPAC 2021会合において，Smart Cities に関するブレークアウト会議[177],[178],[179]を開催し，ワークショップでの議論を振り返るとともに，Smart Cities IG設立に向けてどのように取り組んでいくか議論した．

その結果，図15に示すようなスマートシティに関連するデータの流れにおいて，データのガバナンスが重要であり，市民一人ひとりのデータが，いつ，どこからどこへ，どのようにやりとりされるのかを明確化することが必要となることを確認した．スマートシティには，たとえば，以下のようなさまざまなステークホルダが存在するが，スマートシティのユーザである，一人ひとりの市民の情報をどのように保護するかが重要である:

• Governments
• Content producers
• Network providers
• System developers
• Hardware vendors
• Infrastructure providers
• Service providers Users（=Everybody）

また，2022年2月には，Architecting the Web of Things Webinar[180]にてITU-T SG20[181],[182] と共同議論を持ち，Smart Citiesを構成する各要素技術に加えて，Webにおけるデータガバナンス（プライバシー保護，データの信用性確保，セキュリティ確保，アクセシビリティ，国際化等）を踏まえ，さらなるWebの産業応用のための，より広い視野での連携が必要なことを確認した．

5.3　Webベース Smart Cities標準化の実現に向けて─WoTとDID/VCが連携したデータ流通プラットフォーム

4.5節で触れたとおり，WebベースのIoT技術であるWoTにより，機器の機能や動作を標準的な形式で記述することが可能となり，産業横断的なサービス連携が容易になっていくと期待される．一方，5.1節で述べたように，Webベースの分散識別子であるDIDを用いて，利用するサービス中の機器，および利用者個人の識別IDを，暗号化で保護された形で分散管理するとともに，DIDとひもづいた本人証明情報であるVCにより，サービスプロバイダに非依存，かつ暗号化による保護と検証が可能となり，図16に示すように，DIDを軸として，機器および個人の識別と連携がシームレスに行われる枠組みが実現すると期待される．

この枠組みにより，IoT の未来像として，近い将来，さまざまな機器やアプリがWeb標準を介して相互接続された世界が実現するものと考えられる．その際には，「アプリケーション」の意味が変わり，「複数のアプリケーションや機器の連携したもの」が，新たな「アプリケーション」として提供されることになる．

たとえば，「私の生活全体をサポートするメタアプリケーション」として，以下のようなものが考えられる：

• （1）自宅に帰ってきたとき…
  　「ただいま」と言うと，玄関のドアが開く（音声認識+ドアセンサ）
• （2）入口の照明が点灯し（LED照明）
• （3）「おかえり」という声が出迎える（音声合成アプリ）
• （4）エアコンのスイッチが入り，「いつもの温度」に設定される（エアコン）
• （5）テレビがついて「いつものチャンネル」に変わり，「いつもの音量」で再生（テレビ）
• （6）「朝ドラ録画してあるけど，見る？」と尋ねられる（音声合成アプリ）
• （7）「見るけど，先にお風呂」と返事すると，自動でお風呂が沸く（音声認識アプリ+湯沸器）
• （8）「お風呂に入ってる間，食事を温めておくよ」という声がかかり，電子レンジのスイッチが入る（音声合成アプリ+電子レンジ）

5.2節で触れたとおり，近い将来のスマートシティ実現にあたっては，市民一人ひとりに寄り添う形で，データガバナンスを明確化しながら，スマートシティ内におけるさまざまなサービス同士がシームレスに連携するとともに，複数のスマートシティ同士が相互連携する必要があるが，上記したようなWebベースのデータ流通プラットフォームにより，「複数のアプリケーションや機器の連携したメタアプリケーション」を比較的容易に構築できるようになれば，スマートシティにおいて必要とされるさまざまなサービス連携も比較的容易に行えるようになるものと考えられる．

6．Web国際標準化へのさらなる期待

本稿では，近年，Webがデジタル情報通信社会の基盤となり，さまざまな産業領域やサービスに応用されている状況を踏まえ，まず，Web技術と，W3C（World Wide Web Consortium）におけるその国際標準化について概説した上で，W3C日本事務局スタッフとして，2005年よりWeb国際標準化の現場でさまざまな標準化活動に携わってきた筆者の経験に基づいて，近年ますます広がりを見せるWeb技術のさまざまな産業応用に関して，特に一般的な社会生活への貢献が大きいと考えられる，いくつかの代表事例を挙げつつ，各技術トピックが具体的にどのようなWeb標準によって実現されているのか説明した．その上で，Web応用の将来展望として，産業横断的なデータ流通プラットフォームとしてのWebに対する期待について，やはり，筆者が今までにかかわってきたDIDやVC，そして新たに始まりつつある Smart Citiesの取り組み状況を踏まえて考察した．

インターネットおよびWebを活用したICT技術の発展は，世界中の人々の生活向上にとって，近年，ますます重要になっている．そして，国際的技術標準化は，先進的な技術環境を世界中のあらゆる人々に適切なタイミングで提供するために大変重要な役割を担っている．

本稿では，Web標準産業応用の最新状況に基づいて，今後の方向性に関する展望も述べたが，この内容は，現在，すでに国際標準化活動に取り組んでおられる方々はもちろんのこと，まだかかわっておられない方々にとっても，基本的な情報を提供し，今後のご参加の礎として役立つものと期待している．

本稿中で述べた標準化の取り組み課題，たとえば，「（コネクテッドカーに関して）日本側で検討してきた，API仕様案や車内情報定義を最終的なWeb標準としてW3C勧告化するには至っていないこと」や「（標準化議論は）欧米勢が主導する場合が多く，我が国からのより積極的な標準化推進のための体制づくりが望まれること」といった課題を打破していくためにも，現時点ではまだ国際標準化活動に取り組んでおられない皆様にも，「チーム・ジャパン」の一員として，何らかの形で国際標準化にご参加いただければ，これほどありがたいことはない．ぜひ，ご一緒いたしましょう．そのためにも，「Web国際標準化」が工業や学問として成熟し，システマチックな人材育成を推進していくことができる社会になるように，引き続き努力して参る所存である．