« June 2004 | Main | August 2004 »

2004.07.18

CEとPCの交わるトコロ(2)

CEとPCの主戦場である、リビングの覇権を考えるシリーズ。
二回目は放送と通信の融合についてまとめてみる。

放送のデジタル化、通信のブロードバンド化に伴い、その両者は融合すると10年前から言われつづけている。
しかし、放送局の「通信」的なサービス、通信サービス業者の「放送」的なサービスが多数出てきたものの、どれも決定的なものには至っていないのが現状である。

放送局側の「通信」的なサービスは、以下の3パターンに分類できるだろう。
1.デジタル放送のデータ配信
2.オンデマンド配信
3.メタデータ経由の間接的な連携

1.の「デジタル放送のデータ放送」は、ARIBで定められたBML規格に従ってXMLでコンテンツが記述される。放送波に載って家庭まで届き、デジタル放送対応端末に搭載されたBMLブラウザによってUIが生成される。W3CのHTMLとWEBブラウザの放送版と考えてしまってよいだろう。HTMLでおなじみのUIパーツやJavaScriptに相当する簡単なスクリプトも一応備えており、アニメーションGIFも使える。
しかし、マウスとキーボードを前提としたPC環境において発展したHTMLの仕様を、そのままデータ放送に持ってきてしまったため、画面操作のユーザービリティは最低である。リモコンの十字キーと決定ボタン、4色ボタンのみで操作するなんて、ストレス以外の何者でもない。放送波経由ではなく、IPベースの通信経路で、一般のサーバーにおかれたBMLコンテンツにアクセスすることも規格上許されてはいる。しかし、データ放送との切り分けに関しては異様に厳しい定義がなされており、シームレスな画面遷移など到底不可能である。結局、データ放送はあくまで放送コンテンツの補助的な役割に留めようとする意図が見え隠れする仕様であり、放送と通信の融合を果たせるような代物ではないと断言できる。

2.の「オンデマンド配信」には幾つかの異なったアプローチが存在する。ひとつには、放送局がIPベースでオンデマンド配信に取り組んでいるパターンが挙げられる。TBS、フジテレビ、テレビアサヒの民放3社で始めた「トレソーラ」は、様々な制約を潜り抜けながら比較的頑張っているほうだろう。

しかし、放送コンテンツのオンデマンド配信には、決定的な弱点があることが最近明らかになりつつある。それは「いつでも見れる」ことにより、「いつまでも見ない」という行動にでるユーザーの習性である。放送される日程が決まっていれば、例え録画したとしても、放送日から比較的短い期間で視聴しなければ、という強制力が働く。しかし、オンデマンドの場合いつでも見れるため、ユーザーは別に今日見なくても良い→いつまで経っても見ないという行動をとるのである。従って、放送コンテンツにおけるオンデマンド配信需要は、放送日の決まっていてどうしても見たかった番組が何らかの問題で録画できなかった時、それを補完するための手段としてしか有効ではない、という見方が大勢を占めるようになっている。

もうひとつのパターンは、デジタル放送のサーバー型蓄積配信である。

【NHK技研公開】「B-CASの次はこれ」,サーバー型放送の実用化に向けたプロトタイプをデモ(要登録)

サーバー型蓄積放送には、二つの大きな問題点がある。まず一つ目は、旗を振っているのはNHKだけであり、民放各社がサーバ型放送に全然乗り気でないことである。デジタル放送対応だけでも設備投資の莫大な費用が発生して苦しいところに、時間帯プレミアムの消失と、トリックプレイによるCM自動飛ばしのリスクを孕んだオンデマンド型配信に対応しろと言われても、素直にやりましょう、とは言えないのは頷けるところではある。二つ目には、メタデータ改変が制限される見込みから、コンテンツの編集が一切できない可能性が高いということである。

「勝手な編集は許さない」サーバー型放送が具体化(要登録)

メタデータに電子署名をかけて、Super-CAS(B-CASを超えた?ふざけた名前だ・・・)によって不正なメタデータを検出した際に、再生できないようにするようだ。これはCMカットすら許されないことを意味するため、ユーザーはオンデマンド視聴の代償として、コンテンツへのアクセスが大幅に制限されることになる。従ってサーバ型放送は、あくまでタイムシフト用途に限られた存在にしかなれないだろう。過去には、放送局不在のまま家電メーカー主導で突っ走ったepという蓄積型放送サービスが、大失敗したという歴史がある。今回はコンテンツを持つ放送局主導ではあるものの、今度はユーザー不在になりそうである。
VAIOTypeXのような力づくのアプローチが、デジタル放送でも可能になる日がいずれやってくる。少なくともアナログ地上波が停止する2010年には確実に実現できるため、サーバー型放送が受け入れられる前に用済みになっているというシナリオも十分ありえる。

3.「メタデータによる間接的な連携」は、放送コンテンツ内容を説明するデータを付与して、それを元に見たいシーンのみの抽出を行うというケースが多い。最近目新しかったのが松下の「おつま見ナイター」サービスである。デイリースポーツがメタデータをimodeで配信、受信したメタデータからナイター中継の見たいシーンを選んで、携帯から赤外線発信でDIGAを操作する。サーバ型蓄積放送では、誰がメタデータをつけるのかという根本的な問題があった。このサービスでは、ナイターという限定されたコンテンツではあるものの、スポーツ新聞の記者がメタデータを作成するという実にユニークな解決策をとったことは興味深い。今のところ、サービス自体は無料のようだが、放送コンテンツを配信する側でなく、そのコンテンツ内容を業務上詳しく知りたい業者がメタデータを作成する、というのは非常に理にかなった方向性であり、これから様々な分野で応用できそうなビジネスモデルである。また、ユーザー間でメタデータのみを交換すれば出来ることの幅は広がりそうである。しかし、あまりに放送コンテンツ寄りのデータを作成すると法的な問題が発生するというジレンマの存在を忘れてはいけない。

しかし、コンテンツ自体ではなく、間接的にメタデータのみを交換する手法は、DTCPoverIPが普及するまでは有効な施策と言えるだろう。最もまともそうに見えるソリューションが放送局ではなく、新聞社と家電メーカーのコラボレーションで実現されているあたりが、放送業界による通信対応の限界を暗示しているのかもしれない。

猛烈に長くなってしまったので、通信サービス業者の「放送」的なサービスはまた次回にでも。

| | Comments (0) | TrackBack (0)

« June 2004 | Main | August 2004 »