番組視聴と生活行動のスムーズな連携を可能にする端末連携アーキテクチャー

２．１　ハイブリッドキャストと端末連携サービス

放送通信連携システムは，放送サービスとネットサービスを連携させるための汎用的な技術である。日本では，2013年にハイブリッドキャストが標準化され，これまでに全国で約25の放送事業者によってサービスが提供されている。

ハイブリッドキャストに対応したテレビは，放送信号とネットを連携させるためのHTML5（Hyper TextMarkup Language 5）に対する拡張API（ApplicationProgramming Interface）^*1 を提供するHTML5ブラウザーを搭載している。これにより，各放送事業者がチャンネルごとに提供する，放送と連動可能なWebアプリ（放送マネージドアプリ）をテレビ上で利用することができる。

また，スマホのコンパニオンアプリ（CA：Companion Application）^*2を用いることで，テレビとスマホによるマルチスクリーンサービスの提供も可能である。具体的には，テレビとCAが同じネットワーク上に存在する環境において，テレビの放送マネージドアプリからCA上のWebアプリを起動することができる。さらに，アプリ間でデータのやり取りを行うことができるため，例えば，視聴中の番組のホームページをCAで見るといったような，放送を起点とした端末連携サービスも可能である。

ユーザーが端末連携サービスを利用するまでの手順を1図に示す。ユーザーは，あらかじめスマホにCAをインストールしておくことが必要である。端末連携サービスを利用する際には，スマホでCAを起動した上で，ハイブリッドキャスト対応テレビのリモコンを使って希望のチャンネルを選局する。次に，ユーザーはリモコンのdボタンを押してデータ放送を起動し，データ放送コンテンツを操作して放送マネージドアプリを起動する（放送事業者によっては，データ放送を経由して自動的に放送マネージドアプリが起動される）。その後，放送マネージドアプリの指示により，CA上にWebアプリが起動され，端末連携サービスが利用可能となる。なお，端末連携サービスを利用するためには，あらかじめテレビとCAとをひも付けておく必要があるが，これはデバイスレイヤーのペアリング^*3 により行われる。これにより，CAや放送マネージドアプリにおいてユーザーのアカウント登録やログイン操作をせずに，手軽にサービスを利用することができる。

ハイブリッドキャストの技術仕様³⁾⁴⁾においては，この端末連携サービスに必要なアーキテクチャー（システムの構成）が規定されており，現在は，各テレビメーカーが提供するプロトコル（通信手順）を搭載したCAを用いて，サービスが運用されている。また2016年には，ハイブリッドキャスト運用規定4） 2.4版において，各社のプロトコルが共通化され，１つのCA（共通CA）で多様な機種のテレビとの連携を可能とするプロトコル（端末連携プロトコルv1）とアーキテクチャー（端末連携アーキテクチャーv1）が規定された。

２．２　既存の放送通信連携システムの課題

このように，ハイブリッドキャストを用いることで，テレビとスマホという異なるデバイス間の，放送とネットのサービス連携が可能になる。しかし，現状ではテレビを起点としたシステム設計となっているため，スマホのネットサービスを起点としてテレビの放送サービスへとスムーズに連携することが難しい。具体的には，1図に示したように，手元のスマホのアプリの操作だけでは放送の視聴や端末連携サービスの利用はできず，テレビのリモコンによる操作を伴うことが，サービス連携時の手間や煩雑さを増大させる要因となっている。

欧州で開発された放送通信連携システムであるHbbTVにおいても，高度なサービスの実現に向け，新しい規格であるHbbTV2.0 ⁵⁾が2016年に標準化された。このHbbTV2.0は，ハイブリッドキャストとほぼ同等の規格であり，HTML5に対応したWebアプリをテレビ上で実行することや，テレビとスマホとの端末連携などが可能である。2017年からイタリアや英国などでHbbTV2.0に対応したサービスが開始され，今後，欧州各国における導入が期待されている。しかし，このHbbTV2.0においても，スマホを起点とした放送への連携は実現されていない。

３．１　テレビ連携モジュールとコンパニオンデバイス連携モジュール

コンパニオンデバイスのテレビ連携モジュールと，テレビのコンパニオンデバイス連携モジュールは，対となって動作する。

3図の端末連携プロトコルv1には，機器の相互の発見と接続，放送マネージドアプリからのCA上のWebアプリの起動，これらのアプリ間で相互にデータを送受信するための機能が含まれる。

端末連携プロトコルv2では，端末連携プロトコルv1に加え，テレビ連携モジュールからコンパニオンデバイス連携モジュールに対して，選局や放送マネージドアプリの起動命令を発行するプロトコルが追加されている。放送マネージドアプリの起動は，放送マネージドアプリのロケーションを示すAIT（Application Information Table）のURL（Uniform Resource Locator）を指定することにより実行される。

コンパニオンデバイス連携モジュールは，チューナーや放送マネージドアプリの管理機能と連携し，コンパニオンデバイスが指定したチャンネルへの選局と放送マネージドアプリの起動を行う。アプリ起動時には，各アプリを実行可能なチャンネルを記した情報を，アプリ管理機能が確認することで，誤ったチャンネルでアプリが起動されることを防げるようにした。

また，端末連携アーキテクチャーv1と同様に，CA上のWebアプリが簡単に端末連携プロトコルv2を利用できるように，テレビ連携モジュールを呼び出すためのAPI（JavaScriptで記述）を設けた。さらに，これまではCA上のWebアプリのみが放送と連携できたが，テレビ連携モジュールをアプリやデバイスの実行環境に応じて実装することにより，多様なアプリやデバイスが放送と連携できるようにした。

３．２　サービス連携モジュール

サービス連携モジュールは，放送サービスと連携するアプリが用いることのできる汎用的なモジュールである。各デバイスやアプリの実行環境に応じたAPIとしての機能を提供することで，サービス提供者が簡単にアプリを開発できるように設計した。以下に，サービス連携モジュールの各機能の詳細を述べる。

• アプリ連携機能：アプリを相互に起動する機能，およびデータを受け渡す機能である。
• デバイス連携機能： IoTデバイスの制御を，デバイスの種別に依存せず，統一的なコマンドで実行するための機能⁶⁾である。デバイスごとの通信プロトコルや制御手順についても，可能な限り本機能に吸収し，共通のAPIで利用できる設計とした。
• イベント発火機能：時刻，位置情報，デバイスの接続状態などの条件が，あらかじめ設定した条件に合致したときに，ユーザーやサービス事業者が，情報の通知などのイベントを実行する機能である。
• パーソナルデータ管理機能： ユーザーの視聴データや行動データの管理に加え，テレビ・IoTデバイス・他のアプリとの接続履歴データを管理する機能である。モジュールの内部およびネットワーク上に，各データを保存・管理できる設計とした。

４．１　試作による実用性の検証

端末連携アーキテクチャーv2の実用性を検証するために，民放やテレビメーカーなどにご協力いただき，端末連携アーキテクチャーv2を用いて放送の視聴と日常の生活行動を連携させる事例を試作した。試作にあたって，筆者らはコンパニオンデバイスのテレビ連携モジュールを，スマホのアプリやIoTデバイスなどとハイブリッドキャスト対応テレビを連携させるためのリファレンスソフトウェア「ハイコネ®・ライブラリ」⁷⁾として開発し，スマホのアプリやIoTデバイスに簡単に実装できるようにした。また，市販のハイブリッドキャスト対応テレビ上にコンパニオンデバイス連携モジュールを試作した。

2017年からの２年間で，参加各社により，数多くの事例（約20種類）が試作された。代表的な事例として，スマホのアプリから放送を視聴する事例については文献8），スマホとテレビにおける動画の連携の事例については文献⁸⁾⁹⁾，IoTデバイスと放送との連携の事例については文献¹⁰⁾¹¹⁾，屋外での生活行動と放送の連携の事例については文献¹²⁾や記事¹³⁾を参照していただきたい。これらの事例から，端末連携アーキテクチャーv2は，実用性に加え，汎用性が高いことが示された。

４．２　端末連携アーキテクチャーv2の妥当性の検証

筆者らは，端末連携アーキテクチャーv2の妥当性を検証するために，検証システムを試作した。検証においては，NHK総合テレビのサッカー中継を家庭で視聴する状況を想定し，放送と連携する複数のIoTデバイスの動作シナリオを作成した。そして，試作した検証システムを用いて，各IoTデバイスが動作シナリオに従って連携して動作することを確認した。

検証システムの構成と検証環境を，それぞれ4図と5図に示す。スマホには，スポーツ情報を提供するアプリ，TwitterやLINEといったSNSアプリに加えて，テレビ連携モジュールとサービス連携モジュールを実装した共通CAをインストールした。IoTデバイスとしては，Bluetoothによる通信が可能なボール型ロボット（BLE（Bluetooth Low Energy）プロトコルを用いて， LEDライトの明るさや色調および回転動作を制御可能），WiFiによる通信が可能なスマートLED（HTTPプロトコルを用いて，明るさや色調を制御可能）や小型ロボット（HTTPプロトコルを用いて，胴体，手，首の８軸の動作と，音声ファイルの再生を制御可能）を用意した。放送信号送出装置からは，地上デジタル放送（ISDB-T方式）の信号を送出し，トリガー信号であるイベントメッセージ（Event Message：EM）を多重した。

動作シナリオに沿った各シーンにおけるシステムの動作内容とその実現方法を1表および6図に示す。なお，具体的な動作の様子については，ホームページ¹⁴⁾に掲載した動画を参照していただきたい。

以上で述べた試作と検証により，端末連携アーキテクチャーv2を用いてテレビ・スマホ・IoTデバイスを連携させることで，番組の放送中に限らずその前後の時間においても，放送の視聴と生活行動をスムーズに連携させられることを確認できた。

４．３　ユーザー評価実験

端末連携アーキテクチャーv2を用いた「スマホを起点とした放送の視聴」に対するユーザーの受容性を把握するために，ユーザーによる評価実験を行った。被験者としては，日本全国に約350万人の登録者を有する調査会社のモニターの中で，日常的にスマホを利用し，かつ自宅にテレビを設置している20 ～ 50代の男女で，東京・神奈川・千葉・埼玉に在住するモニターに，実験への協力を依頼した。そして，モニターを2表のように分類し，サンプル数（被験者数）の上限値を設定した上で，実験参加の意思を示したモニターから先着順に被験者を決定する方法で，計103人の被験者を抽出した。実験は，2017年12月15 ～ 17日の３日間，都内の会議室で実施した。以下に，実験の手順と結果，そして結果に基づく考察を示す。

（１）実験手順

1. 実験に先立ち，7図に示すイラストと文章を被験者に提示し，「スマホを起点とした放送の視聴」を可能とする機能（以下，新機能）の内容を説明した上で，「新機能をどの程度利用したいか」という設問を提示して，５段階評価の選択肢の中から回答を求めた。さらに，その回答の理由を，７つの選択肢^*4からの複数回答により尋ねた。
2. 実験会場では，テレビの前にスマホとリモコンを用意し，8図に示す２つのタスクを被験者に与えた。テレビの初期状態は，「電源がOFF」または「ドラマを放送中のチャンネルが選局された状態」とした。そして被験者には，スマホに対してサッカー中継の番組情報が通知されたときに，テレビをそのチャンネルに選局するように指示した。選局の方法としては，タスクAではテレビのリモコンを使って，タスクBでは，新機能を搭載した試作アプリによってスマホの画面上に提示した「テレビで見る」ボタンを押して，選局を実行してもらった。
3. ２つのタスクを行った直後に，新機能を体験した上での利用意向などに関するアンケートを実施した。

（２）実験結果

まず，被験者に対して，新機能の体験前と体験後に，その利用意向と理由を尋ねた。体験前のユーザーの利用意向の割合を9図に，体験前後の利用意向の変化を10図に示す。9図と10図においては，「ぜひ利用したい」と回答した被験者と「やや利用したい」と回答した被験者の合計を，「利用意向を示した被験者」とした。今回は，あらかじめテレビとスマホの新しい技術に関する実験を実施する旨を伝えて被験者を募集したことから，9図を見ると，体験前に利用意向を示した被験者は60％と，比較的高い値を示した（結果１）。一方，10図の体験後の利用意向では，被験者全体の94％，当初利用意向の無かった被験者でも８割以上が利用意向を示した（結果２）。

また，利用意向を示した理由（７つの選択肢からの複数回答，および自由記述）としては，被験者の71％が「リモコンよりテレビの操作が楽になる」を，65％が「見たい番組を探すのが楽になる」を，92％が「見たかった番組の見逃しが減りそう」を選んだ（結果３）。さらに，新機能による放送番組の選択のしやすさについて５段階評価で尋ねたところ，被験者全体の97％が「かなりしやすくなる」または「ややしやすくなる」と回答し，ほぼすべての被験者が肯定的な回答をした（結果４）。

次に，11図に示すように，新機能によってテレビの視聴頻度がどのように変化しそうであるかを５段階評価で尋ねた。その結果，被験者全体の78％，当初利用意向の無かった被験者でも６割以上が，視聴頻度が「かなり増えると思う」または「やや増えると思う」と回答した（結果５）。

最後に，自由記述形式の質問により，新機能に対する意見や要望について尋ねた。その結果，「新機能を利用するための新しいアプリのインストールや，事前の複雑な設定は望まない」という意見が多く得られた（結果６）。