ネットワーク中立性を理解するための2事例
今回は、わかりにくい「ネットワーク中立性」を、なるべく具体的な事例から理解できるように最近の関連する2つの事例を紹介したいと思います。
それぞれ、ネットワーク中立性の考え方を前提としたときの許容事例と非許容事例1つずつとなっていて、OK/NGの境界線がどこにあるのかを考えるために最適な事例になっていると思います。
許容事例
スポンサードデータです。
Sponsored Data for Mobile device from AT&T
“sponsored”データ制は有力なオルタナティブとなりうるか
J:COM MOBILE （モバイル・スマホ・携帯・MVNO） | ケーブルテレビ（CATV）のJ:COM
J:COMのページはMVNO全体の紹介ページですが、J:COMオンデマンドの部分を参照してください。
とあるコンテンツにアクセスするときのデータ通信量がカウントされず、もちろんユーザには課金されません。代わりにそのコンテンツの提供者にそのデータ通信量分が課金されるというビジネスモデルを利用したサービスです。
AT&Tは3rdPartyからもこの仕組みを使えますが、J:COMはJ:COM自身だけがJ:COMのVoDサービスのために使えるようになっています。
このサービスはOKということです。
非許容事例
インドでの無料インターネットサービスです。
http://www.trai.gov.in/WriteReadData/WhatsNew/Documents/Regulation_Data_Service.pdf
インド政府当局、Facebookの無料ネットサービスを中立性に反するとして禁止へ - ITmedia ニュース
Facebookが現地の通信キャリアと提携して、FacebookやGoogle検索、Wikipediaなどの限定された範囲でインターネットアクセスを無料で提供していたサービスですが、インド政府から、一時サービス停止措置を経て禁止命令が出されました。
このサービスは(インドでは)NGということです。
考察
なぜ前者は許容され、後者が禁止されたのか。
私はこの2事例の違いとしては、優遇の程度にあると思います。Facebookの無料サービスは「一部のキャリア・一部のサイトに限定される」という点が、他のユーザやコンテンツプロバイダと比較して優遇されすぎという判断なのかなと。
ただ、非常にあいまいです。例えるなら、坂道の途中に超えちゃいけない壁がある感じ。階段の○段目まではOKだけど、次の段からはNGという分かりやすいものではなく、明確な段差のない坂道の途中で気づかないうちに壁がある、というイメージ。
AT&Tのスポンサードデータと何がどう違うのかと問われても「優遇の程度の差」くらいしか答えられません。J:COMは自分のサービスのみの優遇なのでNGと判断される可能性は一番低い気がします。
OK/NGの境界線がハッキリするまでには、もっと様々なサービス事例を重ねて、裁判所などで判断されてということをまだまだ繰り返す必要がありそうな気がします。先は長そう。
ネットワーク中立性の解釈
ネットワーク中立性とは
ネットワーク中立性（network neutrality）とは、ユーザー、コンテンツ、サイト、プラットフォーム、アプリケーション、接続している装置、通信モードによって差別あるいは区別することなく、インターネットサービスプロバイダや政府がインターネット上の全てのデータを平等に扱うべきだとする考え方である。
・・・難しいですね。
実際、この言葉にはいろいろな捉え方があり、人と議論をする際にはまずお互いの立ち位置を確認するところから始めないと議論が無駄になってしまうことが多々あります。
- 平等って何？
- どんな条件があろうと全ての人に一律の内容でサービスを提供することが平等？
- お金を多く払った人に良いサービスを提供して、お金を払わない人には普通のサービスを提供することは平等？不平等？・・・
みたいな感じです。難しいですね。
この課題は、アメリカ・EU・日本の3軸を中心とした世界中において統一的な見解は得られていません。インターネット/ICT領域のの大きな課題として残っています。
ネットワーク中立性の私なりの解釈
そんな中ではありますが、私なりの解釈としてようやく一つの整理にたどり着きました。それは以下です。
- 人よりお金を多く払った場合には、
- そのほかの人への標準的なサービスに悪い影響を出さない範囲で、
- そのほかの人より良いサービスを提供することは、平等。
2.がポイントです。お金を多く払った人がいても、その人により良いサービスを提供するためにそのほかの人向けのサービスに悪い影響を出す場合はそれは不平等です。
同様の考え方として、とある人がネットワーク上で悪いことをしても、そのほかの人への標準的なサービス提供に悪影響を与えていないのであれば、悪いことをした人への何らかのサービス制限を行うことはNGです。
「標準的な」は、例えばスループットなどが挙げられますが、「標準的な」サービスは時代やその国の状況などにより変わってくると思うので、コレが標準的という基準はありません。「みんなが標準的と感じられること」が大きな基準となるのでしょう。
Google、Accelerated Mobile Pages (AMP) HTMLでまたWebを高速化する
GoogleがまたWebを高速化する取り組みを発表しました。彼らはWebをどんだけ高速化するんでしょう。
ということで、概要紹介。
対象となるコンテンツ
なんでも高速化できる訳ではなく、静的コンテンツが対象です。例えばYahoo!ニュースなどの記事なんかをイメージしてください。ここのところWebにはインタラクティブなページがどんどん増えていますが、ニュース記事なんかはまだまだ多くの割合を占める静的なコンテンツで、これからもそう減るものではないでしょう。
仕組みの中身
- JavaScript禁止
- CSS大好き
- 広告とかアクセス解析はiframe内で
- CPU負荷が高くならない条件でプリレンダリング
※プリレンダリングの効果は以下の記事を参照してください。
- なるべくHTTPリクエストが少なくなるように設計
- CDNを併用
- 最初にブラウザに表示サイズを確定させる
対象は静的コンテンツのみですが、ひたすらロード時間が小さくなるように制限を付けているという感じですね。個人的に注目して記事にもしていたプリレンダリングが登場してうれしくなりました。
ニュース記事なんかは一記事でも複数ページに分かれていることも多々あり、ほぼ確実に次のページも見られることになると思うので、プリレンダリングされた分で消費した希少なデータ通信量を無駄にするということも少ないと思います。
（とはいえ、AMP準拠のWebページが広まるとデータ通信量が少し増えますね）
フロント型企業とイネーブラ型企業 -企業分類における2つの類型-
企業の型 -2つの分類-
家族や友人を人に説明するときに、適当なタイプに分類する言葉を使ってその人の性格や特徴などを説明することがあると思いますが、タイプに分類して特徴などをわかりやすくするやり方というのは、企業の特徴を捉えたり、企業に合った戦略を検討するときにも使ったりします。
本記事では、企業を分類する手法の一つである「フロント型企業」と「イネーブラ型企業」について紹介したいと思います。
元々、この分類の考え方は野村総研（NRI）が提唱した考え方で、以下の論文にその考え方がまとまっています。
（参考資料）グーグルゾン時代の企業戦略
http://www.nri.com/jp/opinion/chitekishisan/2005/pdf/cs20050903.pdf
2005年9月発表と、かなり前の情報ではありますが、ここ最近のビジネストレンドにも合ってきていて、改めて見直していくべき考え方だと思っています。
フロント型企業
まずは「フロント型企業」です。フロント型企業の説明としては、「顧客との接点を持つ」という点が端的な説明です。顧客との接点を持つから「フロント型」なのです。
ほかにフロント型と分類されるための要件がいくつかあります。
- 大規模（数百万～数千万）の顧客基盤を持つ。または、特定分野で高いシェアを保有する。
- 上記の顧客のIDもしくはデータベースを持つ。
- マーケティング力、製品/サービスの企画力を持つ。
これらの要件を満たす企業として挙げられているのが、論文の題名にもなっている「グーグルゾン」です。こんな企業は実在しませんが、GoogleとAmazonが合わさった名前で、両社が今の顧客資産やリソースを保持したまま合併した企業がイメージされています。もしグーグルゾンのような企業があったら、最強のフロント型企業になるということです。
フロント型企業を表すイメージとしてこれほどわかりやすいイメージはありません。
イネーブラ型企業
では次にイネーブラ型企業です。こちらはフロント型企業とは違い、顧客接点を持たないことがアイデンティティです。ちなみに「イネーブラ」とは「～できるようにする物/者」という意味の英語です。いわゆる裏方という言い方がわかりやすいかもしれません。
こちらもイネーブラ型と分類されるための要件がいくつかあります。
- 開発や生産業務への精通
- オペレーションの質と高い生産性
上記はNRIのレポートからの抜粋ですが、私はこのほかにもイネーブラ企業に求められる要件がいくつかあると考えています。
- 様々なサービスから共通的に利用できるインフラを持っていること
- それらのインフラを使われやすい形態で提供していること
要は、顧客接点は持っていないけど、他社が魅力的だと思ってくれるようなコアな技術やサービスをビジネスにつなげられる企業がイネーブラ企業となりえるということが言えると思います。
それぞれの事例
NRIの論文では、フロント型企業の例としてANA、イネーブラ企業としてスルガ銀行やリコーなどが紹介されています。それぞれの詳細は論文を確認いただければと思いますが、ここではもう少し最近のイネーブラ型企業の事例を紹介します。
（フロント型企業はイメージしやすいので事例は割愛）
Webサービス（Webインフラ）
- Twitter（Twitter）：
twitterはもちろん自分でサービスを提供していてフロント型ではありますが、色々なWebサービスの認証部分を肩代わりしていたりして、そういった機能の部分ではイネーブラ型のビジネスをしていると分類できます。 - Google Map（Google）：
twitterと同じく自分でサービス提供もしていますが、色々なWebサイトからAPI経由でマップにアクセスできるような仕組みも提供していて、その部分はイネーブラ型であると言えます。
クラウドITインフラ
- AWS（Amazon）：
AWSがエンドユーザに直接サービスを提供している形態はほとんど無く、AWSのインフラ上に各社がサービスやシステムを構築してエンドユーザが利用する形でAWSは使われています。これぞ正にイネーブラ型での提供となります。
ちなみに、ショッピングサイトのAmazonの方はフロント型の代表例です。
通信インフラ・電力インフラ
- 光コラボレーション（NTT東西）：
2014年5月にNTTから光回線の卸サービスである光コラボレーションが発表されましたが、これは今までフロント型で直接光回線サービスをコンシューマに販売していた形態を改めて、別のフロント型企業経由で（回線サービスを卸して）、光回線サービスを提供するモデルに転換したものです。フロント型からイネーブラ型にシフトした典型的な事例と言えます。 - 電力小売自由化（電力会社）：
2016年から電力の小売事業が自由化されますが、発電・送電・配電部分はしばらくはこれまで通り電力会社が行います。コンシューマから見ると、電力会社が1段奥に下がって、フロント型企業が間に入ってくることになります。電力会社はフロント型をやめた訳ではありませんが、一部イネーブラ型にシフトする事例となります。
ここでは大きく3分類の事例を挙げましたが、下に行くほど最近の話です。少し前まではWebのような比較的軽い分野でイネーブラ型ビジネスが展開されてきましたが、徐々に、いわゆる従来のインフラビジネスの領域にまでイネーブラ型が展開されてきている状況となっています。
まとめ
- 企業は「フロント型」と「イネーブラ型」に分類される。
- フロント型は大規模な顧客基盤を持ち、イネーブラ型企業の持つリソース組み合わせつつ顧客基盤を活かしたビジネス戦略を展開する。
- イネーブラ企業は他社と競争差別化できる技術やサービスを持ち、様々なフロント型企業を経由して幅広く展開していくビジネス戦略をとる。
- 最近ではイネーブラ型企業へのシフトがインフラビジネスにおいても進んできている。
大規模な顧客基盤を獲得し、それを維持していくにはそれなりのコスト体力が必要であり、そのような基盤を保持する企業は、今後どんどん収斂していくと想定されます。また、競争差別化できるほどの技術・サービスを持つことの難しさもあると思います。
今後の企業は、このような分類や、それぞれの特徴を踏まえて自社の戦略を決定していく必要があると考えます。
Web高速化プロトコルQUICのInternet-Draft(I-D)が公表
GoogleがQUICへの本格的な取り組みを発表 -QUICが生まれた背景- - Webinar
こちらの記事で、GoogleのQUIC(Quick UDP Internet Connections)への取り組みを紹介していましたが、2015年6月17日に、そのGoogleのメンバーからQUIC仕様のインターネットドラフトが公表されました。
draft-tsvwg-quic-protocol-00 - QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2
インターネットドラフト(Internet Draft:I-D)とは、一般的にはRFC化に向けた議論の土台となる版の仕様書です。土台といっても、これをベースにRFC化されることが決まったわけではなく、どのようなプロトコルをベースにするのか？さえも議論対象として議論が進んでいきます。
HTTP/2だと、最初のインターネットドラフト公表からRFCになるまでに2年半ほど掛かりました。HTTP/2はかなりスムーズにRFC化が進んだ方だと思いますので、QUICがどのくらいの期間を経てRFCになるのか、それともRFCにならないのか、それ自体にも注目です。
I-Dの題名にもあるように、QUICは、1.HTTP/2のための、2.UDPベースで、3.セキュアで、4.信頼性のある、5.トランスポート層プロトコル、です。
高速化に限界の見えてきたTCPを代替することを目指し、TCPとUDPのいいとこどりをしています。
もちろんWebのセキュア化の流れにも準じているはずです。
GoogleはQUICについて、数年の間、詳しい仕様を公開せずにChromeと自サーバ間の通信の一部で使って実験を進めてきましたが、ここに来てRFC化を目指すことなどを発表し、本格的に広めることを目標にした動きを始めています。
これらの動きやプロトコル自体の進化、どのように効果が認められてどのように広まっていくのかなど、様々な観点を持って今後の動向を見ていきたいと思います。
Microsoft、新ブラウザ Microsoft Edgeを発表
マイクロソフトがコードネーム「Project Spartan」としてInternet Explorerとは別の新ブラウザの開発を発表していましたが、ようやくその製品名を発表しました。
Microsoft Edge（エッジ） です。
2015年5月1日で公開されたことのあるMicrosoft Edgeの特徴や機能を挙げておきます。（今後の発表で、なくなる機能もあるかも知れません）
- IEとは別ラインの製品なので、Webの新技術をどんどん取り込んでいく。（企業システム向けなどで後方互換性が重視される分野は、IEがカバーするという役割分担）
- 音声対応エージェントのCortanaを統合。
- Windows Phoneからデスクトップパソコンまで、全てのWindows 10デバイスで動作する。
- ページ内に手書きなどによる書き込みができる「Web Note」機能を具備。また、書き込みした画像を保存することも可能。
- Web記事を読みやすくするための「読書モード」搭載。
今までのブラウザにはない機能を搭載することも積極的に行っているように見えます。
マイクロソフトの壮大な意図として、特にWeb界隈に関わる人の当たり前の認識になっている、「IEはイマイチ」という認識を覆したい・ブラウザ分野での復権を果たしたいという強い意気込みを感じます。
非常に期待しています。
Mozilla、ノンセキュアHTTPへの反対姿勢（deprecating）を表明
Mozillaと言えば、言わずと知れたFirefoxのベンダですが、ブラウザ開発へのスタンスとして、新技術やWeb動向などを積極的に取り込むスタンスを取っていて、今後のブラウザ開発の流れを左右できる立場にあります。
今やWebサイトのHTTPS化は止められない流れになっていますが、2015年4月30日に、Mozillaが自らのセキュリティブログ内で「Deprecating Non-Secure HTTP」と題して、セキュアでないHTTPサイトへの反対姿勢を表しました。Deprecatingは結構強い表現です。
Deprecating Non-Secure HTTP | Mozilla Security Blog
このブログ記事の中では、今後ノンセキュアなHTTPベースのWebサイトを減らしていくための取り組みをアナウンスしています。
具体的には、以下の2つの取り組みを実施していくことによって安全なWebを実現していくとのことです。
- ブラウザの新機能について、その機能を、セキュアな（HTTPSである）Webサイトでのみ使えるように制限するリミットの日程を設定する。
- ノンセキュアな（HTTPである）Webページで使えるブラウザの機能を徐々に減らしていく。（特にユーザのセキュリティやプライバシーにリスクの大きい機能が対象）
以下の記事で、HTTPS化を進める4つの要因を挙げていましたが、今回のMozillaの発表によって、新たな要因がここに加わることになりそうです。
WebサイトのHTTPS化を後押しする要因や状況変化 - Webinar
やはりブラウザベンダからのHTTPS化の推進力は大きいです。
サーバ側のHTTPS化は、ブラウザ側のように数社の意向によって大きな動向が決まるものではありませんが、ブラウザ側のプレッシャーによってHTTPS化が進んでいく順番なのかなと思います。
サーバ側のHTTPS化についても追って行きたいと思います。
