会議分析システム
【課題】
会議中の複数の参加者の音声を取得して，刻々と変わる参加者の会話状況をリアルタイム
に表示することで，より積極的な議論を誘発するような会議可視化システムを提供する。
【解決手段】
複数の会議参加者に対応した複数の音声収集部から収集した音声データを音声処理サーバ
４０で処理し、発話情報を抽出する。この発話情報を集計処理サーバ２００に順次入力す
る。処理サーバ２００のストリームデータ処理部で、この発話情報に対して、クエリ処理
を施すことにより会議参加者の会議における発言回数累積値などのアクティビティデータ
を生成する。表示処理部２０３は、このアクティビティデータに基づき、会議参加者の対
話状況を円の大きさや線の太さなどを用いて可視化して表示する。
会議中の複数の参加者の音声を取得して，刻々と変わる参加者の会話状況をリアルタイム
に表示することで，より積極的な議論を誘発するような会議可視化システムを提供する。
【解決手段】
複数の会議参加者に対応した複数の音声収集部から収集した音声データを音声処理サーバ
４０で処理し、発話情報を抽出する。この発話情報を集計処理サーバ２００に順次入力す
る。処理サーバ２００のストリームデータ処理部で、この発話情報に対して、クエリ処理
を施すことにより会議参加者の会議における発言回数累積値などのアクティビティデータ
を生成する。表示処理部２０３は、このアクティビティデータに基づき、会議参加者の対
話状況を円の大きさや線の太さなどを用いて可視化して表示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のメンバが集まる会議等において、音声データの収集および解析を行な
うことによって、リアルタイムにメンバ間のインタラクション状況を表示するための会議
可視化技術に関する。
【背景技術】
【０００２】
知識労働者の生産性、創造性を向上させる手法が注目を集めている。新規のアイデアや
知識（ナレッジ）を創出するためには、異分野の専門家が集まり、議論を重ねることが重
要である。その中でも、個人の持つ知恵を組織の財産として共有・管理していくための方
法としてナレッジマネジメントと呼ばれる方法論が注目されている。ナレッジマネジメン
トは、組織文化・風土の改革までを含めた考え方であり、情報技術による知識共有の支援
ツールとしてナレッジマネジメント支援ツールと呼ばれるソフトウェアが開発・販売され
ている。現在販売されているナレッジマネジメント支援ツールの多くはオフィスで生産さ
れた文書を効率的に管理する機能が中心である。また、オフィス内の知識の多くがメンバ
間のコミュニケーションの中に存在することに注目したものがある。特許文献１には、組
織のメンバ間でなされる対話の状況を蓄積する技術が開示されている。更に、電子的なコ
ミュニケーションの場を提供することで知識の表出化を促進するツールが開発されている
。特許文献２には、電子的なインタラクションという観点において、電子メールの送受信
数カウントの比較結果によってメンバ間の影響を表示する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２０２０３５号公報
【特許文献２】特開２００４−０４６６８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
新規のアイデアや知識（ナレッジ）を創出するためには、異分野の専門家が集まり、議
論を重ねることが重要であり、有限の時間を有効に使った実りのある議論のプロセスが重
要である。従来のナレッジマネジメントツールは、議論の過程に着目したものではなく、
その結果に対しての情報共有に主眼をおいている。特許文献１では、参加者もしくは参加
者以外のものが蓄積された対話状況を再現することが目的であり、対話のプロセス自体に
注目したものではない。また、特許文献２では、メンバ間の影響度合いを計算しているが
、電子メールの送受信数という単純な数値に基づいており、議論のプロセスにまで踏み込
んだものではない。しかも、電子メールによるインタラクションは、一般的に深い議論を
行なうには、適しておらず、例え、高精細なテレビ会議システムなど、電子的なインタラ
クション技術が成熟したとしても、フェイス・トゥ・フェイスでの議論を完全に置換する
ものにはなり得ない。オフィスでのナレッジ創出には電子的なメディアを介さないフェイ
ス・トゥ・フェイスでの会話や会議が必須となっている。
【０００５】
本発明は、複数のメンバが集まる会議等において、アイデアやナレッジの創出を促進・
誘発するための情報処理システムに関するものである。会議中の音声を取得して、発言者
（発話者）および、その発言回数、対話シーケンス、会議の活性度を計算して、刻々と変
わる会議の状況をリアルタイムに表示することで、参加者自身にフィードバックがかかり
、より積極的な議論を誘発するする会議可視化システムの提供を目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明においては、会議における複数の会議参加者間の対話
状況を可視化して表示する会議可視化システムであって、会議参加者に対応した複数の音
声収集部と、音声収集部から収集した音声データを処理し、発話情報を抽出する音声処理
部と、音声処理部で抽出された発話情報が順次入力され、この発話情報に対してクエリ処
理を施すことにより会議参加者の会議におけるアクティビティデータを生成するストリー
ム処理部と、このアクティビティデータに基づき、前記会議参加者の対話状況を可視化し
て表示させる表示処理部とを有する
会議可視化システムを提供する。
本発明においては、音声データに所定の処理を行ない、発言者およびその発言回数、対
話回数を特定し、発言回数を円の大きさで、対話回数を線の太さで、リアルタイムに表示
する。さらに、キーストローク情報から得られた議論内容、発言者毎の発言回数累積、活
性度を同時に表示する。
【発明の効果】
【０００７】
本発明によれば、議論状況をリアルタイムに把握しながら、議論を行なうことにより、
発言量が足りないメンバに対しては発言を促すようなフィードバックがかかる。もしくは
、会議の調停者が、議論状況をリアルタイムに把握しつつ、より多く参加者からのアイデ
アを出してもらうようなコントロールを行なうことで、議論の活性化および有効なナレッ
ジ創出が期待できる。
【図面の簡単な説明】
【０００８】
【図１】第一の実施例の会議可視化システムの構成図。
【図２】第一の実施例の会議可視化システムのシーケンス図。
【図３】第一の実施例の会議可視化システムの使用例を示す図。
【図４】第一の実施例の参加者登録画面のイメージ図。
【図５】実施例の一般的なストリームデータ処理の構成図。
【図６】実施例の入力ストリームのスキーマ登録例を説明するための図。
【図７】実施例の音源選択処理の実現形態を説明するための図。
【図８】実施例のスムージング処理の実現形態を説明するための図。
【図９】実施例のアクティビティデータ生成処理の実現形態を説明するための図。
【図１０】実施例のアクティビティデータ生成処理の実現形態を説明するための図。
【図１１】第二の実施例の無線センサノードのブロック図。
【図１２】第二の実施例の名札型センサノードの使用形態を説明するための図。
【図１３】実施例のアクティビティデータ生成処理の実現形態を説明するための図。
【図１４】会議可視化システムの処理シーケンスの他の実施例を示す図。
【図１５】ストリームデータ処理による、会議可視化データ処理の実現例を詳細に説 明するための図。
【図１６】会議可視化システムの各実施例における会議の活性化度表示の他の表示例 を示す図。
【図１７】会議可視化システムの各実施例における会議の活性化度表示の他の表示例 を示す図。
【発明を実施するための形態】
【０００９】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【実施例１】
【００１０】
図３に第一の実施例の会議可視化システムを利用した会議シーンの一例を示す。４人の
メンバ（メンバＡ、メンバＢ、メンバＣ、メンバＤ）が会議を行なっている。会議卓に設
置されたマイク（マイクＡ、マイクＢ、マイクＣ、マイクＤ）より各メンバの発話がセン
シングされて、これらの発話データは音声処理サーバ４０を経由したのち、集計処理サー
バ２００で所定の処理が行なわれ、最終的に、この会議の状況がモニタ画面３００にリア
ルタイムに表示されている。参加メンバが可視化された会議状況から直接フィードバック
を受けることで、各メンバが発言のモチベーションを高めたり、司会者がより多くのアイ
デアが集まるような会議進行を行なう、といった効果が期待される。なお、ここで音声処
理サーバ４０や集計処理サーバ２００などのサーバは、通常のコンピュータシステムと同
義であり、例えば、集計処理サーバ２００は、処理部（ＣＰＵ）、記憶部（半導体メモリ
や磁気記憶装置）、キーボードやマウスなどの入力部、ネットワークと接続される通信部
などの入出力インタフェース部、更に必要ならＣＤやＤＶＤなどのメディアの読取書込み
部などが内部バスで接続されている構成を有する。この音声処理サーバ４０と集計処理サ
ーバ２００は、一個のサーバ（コンピュータシステム）で構成して良いことはいうまでも
ない。
【００１１】
図１に第一の実施例の会議可視化システムの全体図を示す。会議可視化システムは、活
動状況のセンシング、センシングデータの集計・解析処理、および、結果の表示、という
大きく分けて３つの機能より構成される。以下、これらの順番に従ってシステムの詳細を
説明する。会議卓３０には、メンバの着座位置に応じて音声収集部であるセンサ（マイク
）２０が設置されており、メンバが会議にて発言を行なった場合には、これらセンサ２０
にて発言のセンシングを行なう。また、会議卓３０には、パーソナルコンピュータ（ＰＣ
）１０が設置されている。このＰＣ１０は、キーストローク情報出力部として機能し、会
議の記録係が会議録を記述する際のキーストロークデータを出力する。このキーストロー
クデータは、集計処理サーバ２００の入出力インタフェース部を介して、サーバ２００内
に入力される。
【００１２】
図１の例においては、４つのセンサ（センサ２０−０〜２０−３）が設置されており、
それぞれ、メンバＡ〜メンバＤの発話音声を取得する。センサ２０から取得された音声デ
ータは音声処理サーバ４０に転送される。音声処理サーバ４０においては、その内部に設
置されたサウンドボード４１にて音声データのサンプリング処理が行なわれ、その後、音
声処理部４２にて、音の特徴量データ（具体的には、音声エネルギーの大きさ等）が抽出
される。通常この音声処理部４２は、音声処理サーバ４０内の図示されていない処理部（
ＣＰＵ）におけるプログラム処理として構成される。そして、音声処理サーバ４０にて生
成された特徴量データは、その入出力インタフェース部を介して、メンバの発話情報とし
て集計処理サーバ２００の入出力インタフェース部に転送される。転送される音声特徴量
データ５２は、時刻５２Ｔ、センサＩＤ（識別子）５２Ｓ、および、エネルギー５２Ｅを
含んでいる。また、発言者発言内容出力部であるＰＣ１０から取得されたキーストローク
データ５１も、集計処理サーバ２００に転送され、これは、時刻５１Ｔ、発言者５１Ｎ、
および、発言内容５１Ｗを含んでいる。
【００１３】
これらのセンシングデータは、集計処理サーバ２００内のストリームデータ処理部１０
０にて、会議の状況を可視化するためのデータである、アクティビティデータＡＤに変換
される。ストリームデータ処理１００では、それぞれのデータソースに対応したＷｉｎｄ
ｏｗ１１０を持っており、一定時間メモリに蓄えられている時系列のデータセットに対し
て、所定の数値演算処理を行なう。この演算処理は、リアルタイムクエリ処理１２０と呼
ばれ、具体的なクエリの設定や、参加者とデータのＩＤとの対応付けは、それぞれ、クエ
リ登録インタフェース２０２、参加者登録インタフェース２０１を通して行なわれる。な
お、上述のストリームデータ処理部１００、参加者登録インタフェース２０１、クエリ登
録インタフェース２０２は、先に説明した集計処理サーバ２００の図示されない処理部（
ＣＰＵ）で実行されるプログラムとして構成される。
【００１４】
通常、ストリームデータ処理部１００で生成されたアクティビティデータＡＤは、集計
処理サーバ２００中の図示されない記憶部中のテーブルなどに記憶され、順次、表示処理
部２０３の処理対象なる。本実施例では、具体的な、アクティビティデータＡＤとして、
４つのデータが生成される。
【００１５】
１つ目は、議論活性化度５４であり、これは、時刻５４Ｔと、その時刻での議論の活性
化度５４Ａより構成される複数のリストである。議論活性化度５４Ａは、その議論に関し
ての発言量総和やメンバ参加数等をパラメータにして、計算される。例えば、単位時間当
たりの、発言総回数と発言を行なった参加者総数によって決定される。同図１では、一分
当たりの議論活性化度５４を例示している。２つ目のアクティビティデータは、発言内容
データ５５であり、これは、時刻５５Ｔと、その時刻に対応する発言者５５Ｓと発言内容
５５Ｃ、および、重要性５５Ｆより構成されている。実際には、ＰＣ１０からのキースト
ロークデータ５１に含まれる、時刻５１Ｔ、発言者５１Ｎ、および、発言内容５１Ｗが、
それぞれ、時刻５５Ｔ、発言者５５Ｓ、発言内容５５Ｃにマッピングされる。３つ目のア
クティビティデータは、発言回数データ５６であり、これは、時刻５６Ｔと、その時刻に
対応する、発言者５６Ｎと、発言者５６Ｎに対応する発言累積（回数）５６Ｃより構成さ
れている。４つ目のアクティビティデータは、発言シーケンスデータ５７であり、これは
、時刻５７Ｔと、その時刻に対応する、発言者の発話の順序関係である。具体的には、そ
の時刻にて、発言者（前）５７Ｂの発話の直後に、発言者（後）５７Ａが発話を行なった
回数５７Ｎを、あるウィンドウ時間内で求めたものである。
【００１６】
さて、ストリームデータ処理部１００で生成されたアクティビティデータＡＤに基づき
、表示処理部２０３にて描画処理が行なわれる。即ち、アクティビティデータＡＤは、次
段の表示処理部２０３にて、描画処理の素材データとして使用される。この表示処理部２
０３も集計処理サーバ２００の処理部（ＣＰＵ）で実行される描画処理プログラムとして
提供される。例えば、Ｗｅｂベースでの表示を行なう場合には、表示処理部２０３でＨＴ
ＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｋｅｕｐ Ｌａｎｇｕａｇｅ）画像の生成処理等が行
なわれる。表示処理部２０３で生成された画像は、入出力インタフェース部を介して、モ
ニタに出力され、モニタ画面３００に示される画面構成で表示される。会議の様子は、モ
ニタ画面３００にて、活性度・発言表示３１０、発言累積３２０、および、発言シーケン
ス３３０の３つの要素として表示される。
【００１７】
以下、素材データであるアクティビティデータを用いて表示される３つの要素について
説明する。活性度・発言表示３１０では、時間軸に沿って、リアルタイムにその会議の活
性度３１１と発言３１３が表示される。活性度３１１は、アクティビティデータＡＤの議
論活性化度５４の表示を行なったものであり、発言３１３はアクティビティデータＡＤ発
言内容データ５５を表示したものである。また、会議の統計データなどに基づいて、活性
度の指標３１２を表示することも可能である。発言累積３２０は、アクティビティデータ
ＡＤの発言回数データ５６に基づいて、会議開始からの参加者毎の発言回数を累積として
表示したものである。最後に、発言シーケンス３３０は、アクティビティデータＡＤの発
言回数データ５６と発言シーケンスデータ５７を使用して、参加者間の発話のやり取りを
可視化したものである。
【００１８】
具体的には、この発言シーケンス３３０で図示されている参加者毎の円の大きさ（３３
１Ａ、３３１Ｂ、３３１Ｃ、および、３３１Ｄ）は、過去から現在までの一定期間（例え
ば５分間）においての発言回数を円の大きさとして表しており、円と円との間のリンクの
太さは、参加者間での会話が多いか少ないか（会話のインタラクションの量）を可視化し
たものである。例えば、ＡとＢとの間のリンク３３２は細く、ＡとＤとの間のリンク３３
３は太く描かれており、ＡとＤとのインタラクションが多いことが示されている。本例で
は、Ａの発言の後にＤが発言した場合と、Ｄの発言の後にＡが発言した場合とは区別され
てはいないが、発言シーケンスデータ５７を使用することによりこれらを区別するような
表示方法も可能である。素材データ各々を用いて、これら活性度・発言表示３１０、発言
累積３２０、および発言シーケンス３３０の各要素を適宜表示することは、通常の図形描
画処理プログラムを、集計処理サーバ２００の図示されない処理部（ＣＰＵ）で実行する
ことにより実現できることは言うまでもない。
【００１９】
図２は、図１で示した全体図における代表的な機能モジュールでの処理シーケンスを示
したものである。まず音声収集部としてのセンサ（マイク）２０では音声データが取得さ
れる（２０Ａ）。次に、サウンドボード４１にて、音声のサンプリング処理が行なわれる
（４１Ａ）。次に音声処理部４２にて、発話情報としての特徴量の抽出（具体的にはエネ
ルギーへの変換）が行なわれる（４２Ａ）。エネルギーは、例えば数ミリ秒の音波形の絶
対値の２乗を全範囲に渡って積分したものである。なお後段にてより確度の高い音声処理
を行なうために、ここで、音声／非音声の識別を行なうことも可能である（４２Ｂ）。音
声／非音声の識別方法として、時間におけるエネルギーの変化度合いによる識別があげら
れる。音声には音波形エネルギーの強弱とその変化パターンがあり、それらを用いること
で音声と非音声の識別を行なう。上述の通り、特徴量抽出４２Ａ、更には音声／非音声判
別４２Ｂは、図示されない処理部（ＣＰＵ）のプログラム処理として実行される。
【００２０】
次に、ストリームデータ処理部１００にて、音源の選択（１００Ａ）、スムージング処
理（１００Ｂ）、アクティビティデータ生成（１００Ｃ）が行なわれる。最後に、表示処
理部２０３にて、アクティビティデータＡＤに基づいた、画面データ生成（２０３Ａ）が
行なわれる。なお、これらの具体的構成は他の実施例とも共通する部分が多いので後述す
る。
【００２１】
図４は参加者の登録画面６０を示したものである。会議卓３０のそれぞれの座席に座る
メンバとマイク（２０）とを対応させるために、画面の座席位置（６１Ａ〜６１Ｆ）の空
欄に参加者の名前を入力して登録を行なう（６２）。図４では、座席位置６１Ａ、６１Ｂ
、６１Ｃ、６１Ｄに、それぞれ、参加者の名前Ａ、Ｂ、Ｃ、Ｄを登録している例を示して
いる。なお、この登録画面６０は、上述したＰＣの画面や、各自の座席位置に設置した手
書き文字入力タブレットの入力画面等を用いれば良い。これらの登録作業は、これらの手
段によって入力された名前データに基づき、集計処理サーバ２００の参加者登録インタフ
ェース２０１を使用して行なわれる。
【００２２】
以上説明した第一の実施例の会議可視化システムにより、発言者および、その発言回数
、対話シーケンス、会議の活性度を計算して、刻々と変わる会議の状況をリアルタイムに
表示することが可能となるため、参加者にフィードバックがかかって、より積極的で活性
度の高い議論を誘発することができる。
【実施例２】
【００２３】
第一の実施例では、マイク２０から取得した音声データをベースに会議を可視化する方
法を示した。第二の実施例においては、会議の参加メンバに無線センサノードと呼ばれる
デバイスを与えることで、音声以外の情報も加味してより詳細に会議の状況を可視化する
会議可視化システムを提供する。
【００２４】
まず、無線センサノードの構成について図１１を用いて説明する。図１１は、無線セン
サノード７０の構成の一例を示すブロック図である。無線センサノード７０は、メンバ自
身の動きの測定（加速度を使用）、音声の測定（マイクロホンを使用）、着席位置の測定
（赤外線の送受信を使用）を行なうセンサ７４と、センサ７４を制御するコントローラ７
３と、無線基地局７６と通信を行なう無線処理部７３と、これらの各ブロックに電力を供
給する電源７１、無線データの送受信を行なうアンテナ７５より構成される。センサ７４
には具体的には、加速度センサ７４１、マイクロホン７４２、赤外線送受信器７４３が搭
載されている。
【００２５】
コントローラ７３は、予め設定された周期、もしくは不定期にセンサ７４の測定データ
を読み込み、この測定データに予め設定したセンサノードのＩＤを加えて無線処理部７２
に転送する。測定データにはセンシングを行った時間情報をタイムスタンプとして与える
場合もある。無線処理部７２は、コントローラ７３から送られたデータを基地局７６（図
１２に示す）に送信する。電源７１は、電池を使用する場合や、太陽電池や振動発電など
の自律発電機構を具備する構成としても良い。
【００２６】
図１２に示すように、この無線センサノード７０を名札型に加工した名札型センサノー
ド７０Ａをユーザが装着することにより、ユーザの状態（動き等）に関するセンシングデ
ータを、リアルタイムに無線基地局７６を経由して、集計処理サーバ２００に送信するこ
とが可能となる。さらに、図１２に示すように、会議卓の各座席位置に設置された赤外線
送信器７７からのＩＤ情報を、名札型センサノード７０Ａが赤外線送受信器７４３にて定
期的に検出することで、着席位置の情報を自律的に集計処理サーバ２００に送信すること
も可能となる。このように、本実施例においては、名札型センサノード７０が、ユーザの
着席位置を、自動的に集計処理サーバ２００に送付すれば、登録画面６０を使用した参加
者登録処理（図４）を自動化することが可能となる。
【００２７】
さて次に、図５以下の図面を用いて、上述した会議可視化システムを実現するストリー
ムデータ処理部１００について詳述する。上述の各実施例におけるアクティビティデータ
生成にはストリームデータ処理を用いる。このストリームデータ処理と呼ばれる技術自身
は公知の技術であり、Ｂ．Ｂａｂｃｏｃｋ、Ｓ．Ｂａｂｕ、Ｍ．Ｄａｔａｒ、Ｒ．Ｍｏｔ
ｗａｎｉ ａｎｄ Ｊ．Ｗｉｄｏｍ、“Ｍｏｄｅｌｓ ａｎｄ ｉｓｓｕｅｓ ｉｎ ｄ
ａｔａ ｓｔｒｅａｍ ｓｙｓｔｅｍｓ”、Ｉｎ Ｐｒｏｃ． ｏｆ ＰＯＤＳ ２００
２、 ｐｐ．１−１６．（２００２）、Ａ．Ａｒａｓｕ、Ｓ．Ｂａｂｕ ａｎｄ Ｊ．Ｗ
ｉｄｏｍ、“ＣＱＬ： Ａ Ｌａｎｇｕａｇｅ ｆｏｒ Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅ
ｒｉｅｓ ｏｖｅｒ Ｓｔｒｅａｍｓ ａｎｄ Ｒｅｌａｔｉｏｎｓ”、Ｉｎ Ｐｒｏｃ
． ｏｆ ＤＢＰＬ ２００３、 ｐｐ．１−１９ （２００３）、などの文献に開示さ
れている。
【００２８】
図５は図１のストリームデータ処理部１００の機能動作を説明するための図である。ス
トリームデータ処理は、絶え間なく到来するデータの流れを対象に、フィルタリング処理
や集計処理などを、継続的に実行する技術である。個々のデータにはタイムスタンプが付
与されており、データはタイムスタンプの昇順に並んで流れる。以下では、このようなデ
ータの流れをストリームと呼び、個々のデータをストリームタプル、あるいは単にタプル
と呼ぶ。ある一つのストリーム上を流れるタプルは、単一のデータ型に従う。このデータ
型をスキーマと呼ぶ。スキーマとは任意個のカラムの組合せであり、各カラムは一つの基
本型（整数型、実数型、文字列型など）と、一つの名前（カラム名）の組合せである。
【００２９】
ストリームデータ処理は、スキーマが定義されたストリーム上のタプルを対象に、リレ
ーショナルデータベースの計算モデルである関係代数に準じて、射影、選択、結合、集計
、和集合、差集合などの演算を実施する。但し、関係代数はデータの集合に対して定義さ
れるので、絶え間なくデータ列が続く（即ち、無限に集合の要素が増え続ける）ストリー
ムに対して関係代数を継続的に処理するには、処理対象となるタプルの集合を常に限定し
ながら実行する必要がある。
【００３０】
このために、ストリームデータ処理では、ある時刻において処理対象となるタプル集合
を限定する、ウィンドウ演算が定義されている。このように、ストリーム上のタプルは、
関係代数で処理される前に、まずウィンドウ演算によって、処理対象となる期間を定義さ
れる。以下では、この期間をタプルの生存期間と呼び、生存期間を定義されたタプルの集
合をリレーションと呼ぶ。そして、このリレーションに対して関係代数が実施される。
【００３１】
ウィンドウ演算の例を、５０１〜５０３を用いて説明する。５０１はストリームを、５
０２および５０３は、ストリーム５０１に対してウィンドウ演算を施した結果である、リ
レーションを示している。ウィンドウ演算は、生存期間の定義の仕方によって、時間ウィ
ンドウと個数ウィンドウに分かれる。時間ウィンドウは、各タプルの生存期間を定数時間
に定める。一方、個数ウィンドウは、同時に生存するタプルの個数を定数個に制限する。
リレーション５０２および５０３は、ストリーム５０１を時間ウィンドウ（５２１）と個
数ウィンドウ（５２２）で処理した結果を、それぞれ示している。
【００３２】
ストリームの図における各黒丸はストリームタプルを表す。ストリーム５０１には、１
時２分３秒、４秒、７秒、８秒、１０秒、および１１秒に流れてくる、６つのストリーム
タプルが存在する。一方、リレーションの図における、黒丸を起点、白丸を終点とする各
線分は、タプルの生存期間を表す。なお、丁度終点の時刻は生存期間に含まれない。リレ
ーション５０２は、ストリーム５０１を、生存期間３秒の時間ウィンドウで処理した結果
である。例として、１時２分３秒のタプルの生存期間は、１時２分３秒から１時２分６秒
までとなる。但し１時２分６秒丁度は生存期間に含まれない。リレーション５０３は、ス
トリーム５０１を、同時生存数３個の個数ウィンドウで処理した結果である。例として、
１時２分３秒のタプルの生存期間は、１時２分３秒から、その３個後に流れてくるタプル
のタイムスタンプ１時２分８秒までとなる。但し１時２分８秒丁度は生存期間に含まれな
い。
【００３３】
リレーション上の関係代数は、入力のリレーションに対する演算結果として、次のよう
な性質を持つ結果リレーションを出力する。まず、入力リレーションにおいて、ある時刻
に生存するタプルの集合に対し、従来の関係代数を実施した結果を、該時刻における結果
タプル集合と呼ぶ。このとき、任意の時刻において、該時刻における結果タプル集合が、
結果リレーションにおいて該時刻に生存するタプルの集合と一致する。
【００３４】
リレーション上の関係代数の例を、５０４〜５０８を用いて説明する。この例は、リレ
ーション５０４とリレーション５０５の間の差集合演算を示し、リレーション５０６、５
０７、５０８は、その結果を示している。例えば、入力リレーション５０４と５０５にお
いて、１時２分８秒に生存するタプル集合は、それぞれ２個のタプルと１個のタプルから
成る。従って、１時２分８秒の結果タプル集合（即ち、両タプル集合の差集合）は、２−
１＝１個のタプルから成るタプル集合である。このような関係が、１時２分７秒から１時
２分９秒までの期間で成立する（但し、１時２分９秒丁度は含まず）。従って、結果リレ
ーションにおいて、この期間に生存するタプルは１個となる。結果リレーションの例とし
て、５０６、５０７、５０８は、全てこの性質を持つ。このように、一般に、リレーショ
ン上の関係代数の結果は、一意には定まらない。但し、ストリームデータ処理においては
、その何れも、リレーション上の関係代数の対象として等価である。
【００３５】
以上のように、リレーション上の関係代数の結果は一意には定まらないため、そのまま
アプリケーションに渡すことは好ましくない。これに対し、ストリームデータ処理では、
リレーションをアプリケーションに渡す前に、再びストリームに変換する演算が用意され
ている。これを、ストリーム化演算と呼ぶ。ストリーム化演算は、等価な結果リレーショ
ンの全てを同一のストリームに変換する。
【００３６】
ストリーム化演算によってリレーションから変換されたストリームを、さらにウィンド
ウ演算でリレーションに変換することも可能である。このように、ストリームデータ処理
の中では、リレーション化とストリーム化を任意に組合せることが可能である。
【００３７】
ストリーム化演算は、ＩＳｔｒｅａｍ、ＤＳｔｒｅａｍ、ＲＳｔｒｅａｍの３種類に分
かれる。ＩＳｔｒｅａｍは、リレーションにおいて、ある時刻に生存するタプル集合に、
タプルの増加があった場合に、その増加分のタプルを、該時刻をタイムスタンプとするス
トリームタプルとして出力する。ＤＳｔｒｅａｍは、リレーションにおいて、ある時刻に
生存するタプル集合に、タプルの減少があった場合に、その減少分のタプルを、該時刻を
タイムスタンプとするストリームタプルとして出力する。ＲＳｔｒｅａｍは、一定時間間
隔で、リレーションにおいてその時点で生存するタプル集合を、ストリームタプルとして
出力する。
【００３８】
ストリーム化演算の例を、５０９〜５１１を用いて説明する。ストリーム５０９は、リ
レーション５０６〜５０８を、ＩＳｔｒｅａｍ（５２３）でストリーム化した結果である
。例として、リレーション５０６では、１時２分３秒にタプルが０個から１個に、１時２
分５秒に１個から２個に増える。このため、ストリーム５０９には１時２分３秒と１時２
分５秒に、それぞれ増分１個のストリームタプルが出力される。この結果は、リレーショ
ン５０７に対して処理しても変らない。例えば、リレーション５０７においては、１時２
分９秒に一つのタプルの生存期間が始まっているが、同時に、別のタプル（１時２分３秒
から生存期間が始まるタプル）の生存期間が終わる。このとき、後者のタプルの生存期間
に１時２分９秒丁度は含まれないため、１時２分９秒に生存するタプルは、丁度１個であ
る。従って、１時２分９秒にはタプルの増減は無いことになり、リレーション５０６に対
する結果と同じく、１時２分９秒のストリームタプルは出力されない。ＤＳｔｒｅａｍ（
５２４）とＲＳｔｒｅａｍ（５２５）についても同様に、リレーション５０６、５０７、
５０８の何れを対象としても、ストリーム化した結果は、それぞれストリーム５１０およ
びストリーム５１１になる（但し、ＲＳｔｒｅａｍのストリーム化間隔は１秒）。このよ
うに、一意には定まらない結果リレーションを、ストリーム化演算によって、一意のスト
リームに変換することが可能である。なお、以降の図では、生存期間終了の白丸を省略す
る。
【００３９】
ストリームデータ処理では、データ処理の内容をＣＱＬ（Ｃｏｎｔｉｎｕｏｕｓ Ｑｕ
ｅｒｙ Ｌａｎｇｕａｇｅ）という宣言型言語で定義する。ＣＱＬの文法は、リレーショ
ナルデータベースにおいて標準的に利用される、関係代数に基づくクエリ言語ＳＱＬに、
ウィンドウ演算、およびストリーム化演算の記法を追加した形式をとる。ＣＱＬ文法の詳
細な定義は、ｈｔｔｐ：／／ｉｎｆｏｌａｂ．ｓｔａｎｆｏｒｄ．ｅｄｕ／ｓｔｒｅａｍ
／ｃｏｄｅ／ｃｑｌ−ｓｐｅｃ．ｔｘｔに開示されている。ここでは、その概要を説明す
る。次の４行は、ＣＱＬ文法に従うクエリの一例である。
【００４０】
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｑ ＡＳ
ＩＳＴＲＥＡＭ（
ＳＥＬＥＣＴ ｃ１
ＦＲＯＭ ｓｔ［ＲＯＷＳ ３］
ＷＨＥＲＥ ｃ２＝５）
ＦＲＯＭ句の“ｓｔ”は、ストリームを表す識別子（以下、ストリーム識別子、あるい
はストリーム名と呼ぶ）である。ストリーム名に続く“［“と”］”に囲まれた部分は、
ウィンドウ演算を表す記法である。例中の記述“ｓｔ［ＲＯＷＳ ３］”は、ストリーム
ｓｔを、同時生存数３個の個数ウィンドウによって、リレーションに変換することを示し
ている。従って、この記述全体では、リレーションを出力する表現となる。なお、時間ウ
ィンドウは“［ＲＡＮＧＥ ３ ｓｅｃ］”のように、“ＲＡＮＧＥ”以降に生存期間を
示す記法となる。この他の記法として、“［ＮＯＷ］”と、“［ＵＮＢＯＵＮＤＥＤ］”
があり、それぞれ、非常に短い（但し、０ではない）生存期間と、永続を意味する。
【００４１】
ＦＲＯＭ句のリレーションを対象に、関係代数が実施される。例中の記述“ＷＨＥＲＥ
ｃ２＝５”は、カラムｃ２が５であるタプルを選択することを示している。また、例中
の記述“ＳＥＬＥＣＴ ｃ１”は、選択されたタプルのｃ１カラムのみを残して、結果リ
レーションとすることを示している。つまり、これらの記述の意味はＳＱＬと全く同じで
ある。
【００４２】
さらに、ＳＥＬＥＣＴ句からＷＨＥＲＥ句までの、リレーションを生成する表現全体を
、“（“と”）”で囲い、その前にストリーム化指定（例中の記述“ＩＳＴＲＥＡＭ”）
を置く記法は、該リレーションのストリーム化演算を示している。ストリーム化指定は、
他に“ＤＳＴＲＥＡＭ”と“ＲＳＴＲＥＡＭ”があり、“ＲＳＴＲＥＡＭ”では、“［“
、”］”で囲って、ストリーム化間隔を指定する。
【００４３】
この例のクエリは、以下のように分解して定義することも可能である。
【００４４】
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｓ ＡＳ
ｓｔ［ＲＯＷＳ ３］
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｒ ＡＳ
ＳＥＬＥＣＴ ｃ１
ＦＲＯＭ ｓ
ＷＨＥＲＥ ｃ２＝５
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｑ ＡＳ
ＩＳＴＲＥＡＭ（ｒ）
ここで、ウィンドウ演算の前に置けるのはストリームを生成する表現、ＦＲＯＭ句に登
場できるのはリレーションを生成する表現、ストリーム化演算の引数はリレーションを生
成する表現に、それぞれ限定される。
【００４５】
図５中のストリームデータ処理部１００は、以上のようなストリームデータ処理を実現
するためのソフトウェア構成を示す。ストリームデータ処理部１００は、ＣＱＬで定義さ
れたクエリが、クエリ登録インタフェース２０２に与えられると、クエリ解析部１２２で
クエリを構文解析し、クエリ生成部１２１によって、木構造の実行形式（以下、実行木と
呼ぶ）に展開する。該実行木は、各種演算を行なう演算子（ウィンドウ演算子１１０、関
係代数演算子１１１、ストリーム化演算子１１２）をノードとし、オペレータ間を繋ぐタ
プルキュー（ストリームキュー１１３、リレーションキュー１１４）をエッジとして構成
される。ストリームデータ処理部１００は、該実行木上の各演算子の処理を、適当な順番
で実行することで、処理を進める。
【００４６】
上述したストリームデータ処理技術に対応し、各実施例において、音声処理サーバ４０
から送られる発話情報であるストリーム５２、参加者登録インタフェース２０１を介して
登録されるストリーム５３、５８などの、ストリームデータ処理１００の外部から送られ
るストリームタプルは、まず、ストリームキュー１１３に入る。これらタプルは、ウィン
ドウ演算子１１０によって生存期間を定義され、リレーションキュー１１４に入る。リレ
ーションキュー１１４上のタプルは、関係代数演算子１１１によって、リレーションキュ
ー１１４を介してパイプライン的に処理される。リレーションキュー１１４上のタプルは
、ストリーム化演算子１１２によってストリーム化され、ストリームキュー１１３に入る
。ストリームキュー１１３上のタプルは、ストリームデータ処理部１００の外部へ送られ
るか、ウィンドウ演算子１１０で処理される。ウィンドウ演算子１１０からストリーム化
演算子１１２までのパスには、リレーションキュー１１４で接続された任意個の関係代数
演算子１１１が置かれる。一方、ストリーム化演算子１１２からウィンドウ演算子１１０
へは、一つのストリームキュー１１３で直接つながる。
【００４７】
次に、図１５を用いて、実施例の会議可視化システムにおけるストリームデータ処理部
１００による会議可視化データ処理の実現方法を具体的に開示する。
【００４８】
１５００〜１５２１は、ストリーム、またはリレーションの、識別名、およびスキーマ
を表す。上側の太枠四角が識別名を、下側の四角の並びがスキーマを構成するカラム名を
示している。７１０、７２０、７３０、８１０、８２０、８３０、８４０、８５０、９１
０、９２０、９３０、９４０、１０００、１０１０、１０２０、１３１０、１３２０、１
３３０の角丸四角は、データ処理の基本処理単位を示している。基本処理単位のそれぞれ
を、ＣＱＬ文法に従うクエリで実現する。クエリ定義、および動作の説明は、図７〜１０
、および図１３を用いて後述する。発話情報である音声特徴量データストリーム１５００
は、音声処理サーバ４０から、音量補正値ストリーム１５０１、および参加者ストリーム
１５０２は、参加者登録インタフェース２０１から、身振り強度ストリーム１５０３、お
よびうなずきストリーム１５０４は、名札型センサノード７０から、発言ログストリーム
１５０５は、ＰＣ（キーストロークセンシング）１０から、それぞれ送られてくる。これ
らを、音源選択１００Ａ、スムージング処理１００Ｂ、およびアクティビティデータ生成
１００Ｃの、各プロセスで順に処理して、出力となるストリーム１５１７〜１５２１を生
成する。１５０６〜１５１６は、中間データとなるストリーム、またはリレーションであ
る。
【００４９】
音源選択１００Ａの処理は、基本処理単位７１０、７２０、７３０から構成される。各
処理の実現形態については、図７を用いて後述する。スムージング処理１００Ｂは、基本
処理単位８１０、８２０、８３０、８４０、８５０から構成される。各処理の実現形態に
ついては、図８を用いて後述する。アクティビティデータ生成１００Ｃの処理は、基本処
理単位９１０、９２０、９３０、９４０、１０００、１０１０、１０２０、１３１０、１
３２０、１３３０から構成される。基本処理単位９１０〜９４０は、モニタ画面３００の
３２０に可視化される発言数１５１７、３３０に可視化される発言時間１５１８、および
会話数１５１９を生成する。これら基本処理単位については、図９を用いて後述する。基
本処理単位１０００〜１０２０は、モニタ画面３００の３１１に可視化される活性度１５
２０を生成する。これら基本処理単位については、図１０を用いて後述する。基本処理単
位１３１０〜１３３０は、モニタ画面３００の３１３に可視化される発言ログ１５２１を
生成する。これら基本処理単位については、図１３を用いて後述する。
【００５０】
次に、図６を用いて、入力ストリームのスキーマ登録について開示する。
【００５１】
コマンド６００を、例えば、集積解析処理サーバ２００の入力部からなどからクエリ登
録インタフェース２０２を介して、ストリームデータ処理部１００に投入することで、入
力ストリーム１５００〜１５０５を受け付ける６本のストリームキュー１１３が生成され
る。ＲＥＧＩＳＴＥＲ ＳＴＲＥＡＭ の直後はストリーム名を、括弧内はスキーマを示
している。スキーマの、“，”に区切られた個々の記述は、カラムの名称と型の組合せを
示している。
【００５２】
６０１は、音声特徴量データストリーム１５００（ｖｏｉｃｅ）に入るストリームタプ
ルの例を示している。本例では、１０ミリ秒毎に、４つのマイクから、センサＩＤ（ｉｄ
カラム）と音量（ｅｎｅｒｇｙカラム）を組み合わせたストリームタプルが生成される様
子を示している。
【００５３】
次に、図７を用いて、音源選択処理１００Ａの基本処理単位７１０、７２０、７３０の
実現方法を開示する。
【００５４】
コマンド７００を、クエリ登録インタフェース２０２を介して、ストリームデータ処理
部１００に投入することで、基本処理単位７１０、７２０、７３０を実現する実行木が生
成される。コマンド７００は、３つのクエリ登録書式７１０、７２０、７３０に分けられ
、それぞれ、基本処理単位７１０、７２０、７３０の処理内容を定義する（以下同様に、
基本処理単位と、その処理内容を定義するクエリの登録書式を、同義として扱い、同一の
番号で示す。また、クエリ登録書式を、単にクエリと呼ぶ）。
【００５５】
クエリ７１０は、１０ミリ秒ごとの各時刻において、最大の音量を記録するマイク２０
を選択する。まず好適には、各マイクの音量に、定数の補正値を加算する。会議卓に取り
付けられた各マイクの感度は、会議卓の形状、材質、壁に対する位置関係、マイク自体の
品質、など様々な要因により、バラつきを持つため、該加算処理により、マイクの感度を
均等化する。マイク毎に異なる補正値は、音量補正値ストリーム１５０１（ｏｆｆｓｅｔ
）として参加者登録インタフェース２０１より登録される。図１のストリーム５８は、音
量補正値ストリームの例である（センサＩＤカラム５８Ｓ、および補正値カラム５８Ｖが
、それぞれ音量補正値ストリーム１５０１のｉｄカラム、およびｖａｌｕｅカラムを示す
）。音声データストリーム１５００と、音量補正値ストリーム１５０１とを、ｉｄカラム
に関する結合演算により結合し、ストリーム１５００の音量カラム（ｅｎｅｒｇｙ）の値
に、ストリーム１５０１の補正値カラム（ｖａｌｕｅ）の値を加算し、この値を改めてｅ
ｎｅｒｇｙカラムとする。該ｅｎｅｒｇｙカラムと、ｉｄカラムとを組み合わせたタプル
から成る、ストリームを、ｖｏｉｃｅ＿ｒとする。ストリーム６０１とストリーム５８に
対する、このクエリの結果をストリーム６０１Ｒに示す。
【００５６】
該ストリームｖｏｉｃｅ＿ｒから、集計演算“ＭＡＸ（ｅｎｅｒｇｙ）”によって最大
音量を算出し、その値と同じ音量のタプルを、ｅｎｅｒｇｙカラムに関する結合演算によ
り抽出する。ストリーム６０１Ｒに対するこのクエリの結果（ｖｏｉｃｅ＿ｍａｘ＿ｓｅ
ｔ）を、リレーション７１１に示す（クエリ７１０ではＮＯＷウィンドウを用いており、
リレーション７１１の各タプルの生存期間は非常に短いため、点で図示する。以下、ＮＯ
Ｗウィンドウによって定義されるタプルの生存期間は点で示す。なお、本クエリに関して
は、ＮＯＷウィンドウの代わりに、１０ミリ秒未満の時間ウィンドウを用いても構わない
）。
【００５７】
同時刻に最大音量を記録するマイクが２つ以上存在する場合もある。これに対し、クエ
リ７２０は、クエリ７１０の結果から、センサＩＤが最小のマイクのデータのみを選択す
ることで、マイクを一つに絞り込む。まず、集計演算“ＭＩＮ（ｉｄ）”によって最小Ｉ
Ｄを算出し、その値と同じＩＤのタプルを、ｉｄカラムに関する結合演算により抽出する
。リレーション７１１に対するこのクエリの結果（ｖｏｉｃｅ＿ｍａｘ）を、リレーショ
ン７２１に示す。
【００５８】
クエリ７３０は、クエリ７２０の結果から、閾値を超えるデータのみを音源として残す
。また、センサＩＤを参加者データ５３と付き合わせて、参加者名に変換する。まず、ｅ
ｎｅｒｇｙカラムに関して範囲選択（＞１．０）をかけ、ｉｄカラムに関する結合演算と
ｎａｍｅカラムの射影演算で、音源となる発話者名のストリームを生成する。リレーショ
ン７２１に対するこのクエリの結果（ｖｏｉｃｅ＿ｏｖｅｒ＿ｔｈｒｅｓｈｏｌｄ）を、
ストリーム７３１に示す。以上で、音源選択１００Ａの処理が完了する。
【００５９】
次に、図８を用いて、スムージング処理１００Ｂの基本処理単位８１０、８２０、８３
０、８４０、８５０の実現方法を開示する。
【００６０】
コマンド８００を、クエリ登録インタフェース２０２を介して、ストリームデータ処理
部１００に投入することで、基本処理単位８１０、８２０、８３０、８４０、８５０を実
現する実行木が生成される。
【００６１】
クエリ８１０は、クエリ７３０で得られた音源データにおける、同一発言者の連続する
音源断片について、間欠部分を補完し、平滑化された発言期間を抽出する。まず、ウィン
ドウ演算“［ＲＡＮＧＥ ２０ ｍｓｅｃ］”によって、ストリーム７３１上の各タプル
に２０ミリ秒の生存期間を与え、“ＤＩＳＴＩＮＣＴ”（重複排除演算）によって、同一
発言者のタプル重複を排除する。ストリーム７３１に対するこのクエリの結果（ｖｏｉｃ
ｅ＿ｆｒａｇｍｅｎｔ）を、リレーション８１１に示す。リレーション８１２は、該結果
に至る中間状態であり、ストリーム７３１上の、ｎａｍｅカラムの値が“Ｂ”であるタプ
ルについて、ウィンドウ演算で生存期間を定義した結果である。ストリーム７３１上では
、９時２分５．０３秒、５．０５秒、および５．０７秒において、ｎａｍｅカラムＢのタ
プルが抜けているが、リレーション８１２では、２０ミリ秒の生存期間によって補完され
る。一方、９時２分５．０８秒と５．０９秒のようにデータが連続する箇所では、生存期
間の重複が発生するが、ＤＩＳＴＩＮＣＴによって排除される。その結果、ｎａｍｅカラ
ムＢのタプルは、生存期間が９時２分５．０２秒から５．１１秒までの、一本のタプル８
１３に平滑化される。ｎａｍｅカラムＡ、Ｄのタプルのように、散発的に現れるタプルに
ついては、タプル８１４、８１５、８１６のように、２０ミリ秒の生存期間が定義された
タプルが散在する結果となる。
【００６２】
クエリ８２０は、クエリ８１０の結果から、持続時間が非常に短い瞬間的な発言（期間
）を、ノイズとして除去する。まず、リレーション８１１の各タプルについて、ストリー
ム化演算“ＩＳＴＲＥＡＭ”とウィンドウ演算“［ＲＡＮＧＥ ５０ ｍｓｅｃ］”によ
って、タプルの開始時刻から５０ミリ秒の生存期間を持つコピー（ｎａｍｅカラムの値が
、元のタプルと同一のタプル）を生成し、差集合演算“ＥＸＣＥＰＴ”によって、リレー
ション８１１から差し引くことで、生存期間が５０ミリ秒以下のタプルを除去する。リレ
ーション８１１に対するこのクエリの結果（ｓｐｅｅｃｈ）を、リレーション８２１に示
す。リレーション８２２は、該結果に至る中間状態であり、リレーション８１１上の各タ
プルについて、生存期間５０ミリ秒のコピーを作成した結果である。リレーション８１１
と８２２の差集合を取ると、タプル８１４、８１５、８１６は、タプル８２４、８２５、
８２６によって完全に消去される。一方、タプル８１３については、タプル８２３の生存
期間を差引かれて、９時２分５．０７秒から９時２分５．１１秒までの生存期間を持つタ
プル８２７が残る。このように、生存期間が５０ミリ秒以下のタプルは全て除去され、そ
れ以上の生存期間を持つタプルのみが、実際の発言データとして残る。
【００６３】
クエリ８３０、８４０、および８５０は、クエリ８２０の結果から、ストリーム化演算
ＩＳｔｒｅａｍ、ＤＳｔｒｅａｍ、およびＲＳｔｒｅａｍによって、それぞれ、発言の開
始時刻、終了時刻、および発言中の時刻をタイムスタンプとする、ストリームタプルを生
成する。リレーション８２１に対する、各クエリの結果（ｓｔａｒｔ＿ｓｐｅｅｃｈ、ｓ
ｔｏｐ＿ｓｐｅｅｃｈ、およびｏｎ＿ｓｐｅｅｃｈ）を、それぞれストリーム８３１、８
４１、８５１に示す。以上で、スムージング処理１００Ｂが完了する。
【００６４】
次に、図９を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位９１０、９
２０、９３０、９４０の実現方法を開示する。コマンド９００を、クエリ登録インタフェ
ース２０２を介して、ストリームデータ処理１００に投入することで、基本処理単位９１
０、９２０、９３０、９４０を実現する実行木が生成される。
【００６５】
クエリ９１０は、クエリ８３０の結果から、会議中の累積発言回数をカウントする。ま
ず、ウィンドウ演算“［ＲＯＷＳ １］”によって、発言開始タプルが発生する度にｎａ
ｍｅカラムの値が切替るリレーションを生成する。但し、同一発言者の発言開始タプルが
連続する場合には、リレーションは切替らない。このリレーションをストリーム化演算“
ＩＳＴＲＥＡＭ”でストリーム化することで、発言者に変化があった際の、発言開始時刻
を切り出す。さらに、該ストリームをウィンドウ演算“［ＵＮＢＯＵＮＤＥＤ］”で永続
化し、ｎａｍｅカラムでグルーピングして、集計演算“ＣＯＵＮＴ”でカウントすること
によって、発言者ごとの累積発話回数を算出する。
【００６６】
ｓｐｅｅｃｈリレーション９０１に対するこのクエリの結果（ｓｐｅｅｃｈ＿ｃｏｕｎ
ｔ）を、リレーション９１１に示す。ストリーム９１２は、リレーション９０１に対する
クエリ８３０の結果（ｓｔａｒｔ＿ｓｐｅｅｃｈ）である。リレーション９１３は、スト
リーム９１２を［ＲＯＷＳ １］のウィンドウ演算で処理した結果である。ストリーム９
１４は、リレーション９１３をＩＳｔｒｅａｍでストリーム化した結果である。このとき
、タプル９１５の開始時刻に対して、ストリームタプル９１７が生成されるが、タプル９
１５と９１６は、同一発言者“Ｂ”のリレーションであり、タプル９１５の終点とタプル
９１６の始点は同一時刻（９時１８分１５秒）になるため、９時１８分１５秒のタプルは
生成されない。ストリーム９１４を、ｎａｍｅでグルーピングして永続化してカウントし
た結果が、リレーション９１１となる。永続化したリレーションをカウントするので、ス
トリーム９１４にタプルが発生する度に、発言数が累積される。
【００６７】
クエリ９２０は、クエリ８５０の結果から、過去５分間における発言者ごとの発言時間
を算出する。まず、ｏｎ＿ｓｐｅｅｃｈストリームの各タプルに対し、ウィンドウ演算“
［ＲＡＮＧＥ ５ ｍｉｎ］”で、５分間の生存期間を定義し、ｎａｍｅカラムでグルー
ピングして、集計演算“ＣＯＵＮＴ”によってカウントする。この処理は、過去５分間に
おいて、ｏｎ＿ｓｐｅｅｃｈストリーム上に存在したタプルの個数を数えることに相当す
る。なお、ｏｎ＿ｓｐｅｅｃｈストリームタプルは、秒間１００個のレートで生成される
ため、ＳＥＬＥＣＴ句でこの個数を１００で割って、秒単位の発言時間を算出する。
【００６８】
クエリ９３０は、クエリ８３０および８４０の結果から、ある発言の終了後３秒以内に
、別の発言者の発言が開始されたケースを、二者間の会話として抽出する。まず、ｓｔｏ
ｐ＿ｓｐｅｅｃｈストリームとｓｔａｒｔ＿ｓｐｅｅｃｈストリームの各タプルに対し、
それぞれウィンドウ演算“［ＲＡＮＧＥ ３ ｓｅｃ］”と“［ＮＯＷ］”で、生存期間
を定義し、ｎａｍｅカラムに関する結合演算（一致しないことを条件とする）により、ｓ
ｔｏｐ＿ｓｐｅｅｃｈタプル発生の３秒以内に、ｓｔａｒｔ＿ｓｐｅｅｃｈタプルが発生
する組合せを抽出する。結果は、ｓｔｏｐ＿ｓｐｅｅｃｈ．ｎａｍｅをｐｒｅカラムに、
ｓｔａｒｔ＿ｓｐｅｅｃｈ．ｎａｍｅをｐｏｓｔカラムに射影して出力する。ｓｐｅｅｃ
ｈリレーション９０１に対するこのクエリの結果（ｓｐｅｅｃｈ＿ｓｅｑｕｅｎｃｅ）を
、ストリーム９３１に示す。ストリーム９３２は、リレーション９０１に対するクエリ８
４０の結果（ｓｔｏｐ＿ｓｐｅｅｃｈ）であり、リレーション９３３は、ストリーム９３
２の各タプルに３秒間の生存期間を定義した中間状態である。また、ストリーム９１２を
ＮＯＷウィンドウでリレーションに変換した結果は、９１２と同一の図になる。該リレー
ションと、リレーション９３３の結合演算の結果を、さらにＩＳｔｒｅａｍでストリーム
化した結果が、ストリーム９３１となる。
【００６９】
クエリ９４０は、クエリ９３０の結果から、会議中の累積会話回数を、二者の組合せ別
にカウントする。まず、ウィンドウ演算“［ＵＮＢＯＵＮＤＥＤ］”で永続化し、“Ｇｒ
ｏｕｐ ｂｙ ｐｒｅ，ｐｏｓｔ”で、ｐｒｅカラムとｐｏｓｔカラムの組合せ別にグル
ーピングし、集計演算“ＣＯＵＮＴ”によってカウントする。永続化したリレーションを
カウントするので、ストリーム９３１にタプルが発生する度に、会話数が累積される。
【００７０】
次に、図１０を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位１０００
、１０１０、１０２０の実現方法を開示する。クエリ１０００、１０１０、および１０２
０を、クエリ登録インタフェース２０２を介して、ストリームデータ処理部１００に投入
することで、それぞれ、基本処理単位１０００、１０１０、および１０２０を実現する実
行木が生成される。これら３種のクエリは、全て会議の盛り上り度を算出する。但し、盛
り上り度の定義は各クエリで異なる。
【００７１】
クエリ１０００は、ストリーム１５００（ｖｏｉｃｅ）の全マイクの音量値を、過去３
０秒間累積した値として、盛り上り度を算出する。本クエリは、ウィンドウ演算“［ＲＡ
ＮＧＥ ３０ ｓｅｃ］”と、集計演算“ＳＵＭ（ｅｎｅｒｇｙ）”により、過去３０秒
間におけるストリーム１５００上のタプルのｅｎｅｒｇｙカラム値の和を計算する。また
、ストリーム化演算“ＲＳＴＲＥＡＭ［３ ｓｅｃ］”によって、結果の出力を３秒間隔
としている（以下、クエリ１０１０、１０２０についても同様）。以上、クエリ１０００
では、会議出席者の発言エネルギーの総和を、盛り上り度の指標としている。
【００７２】
クエリ１０１０は、過去３０秒間における、発言者数と会話回数の積として、盛り上り
度を算出する。この盛り上り度は先に説明した単位時間当たりの発言総回数と発言者総数
の積から算出する議論活性化度５４の一具体例となる。クエリ１０１１は、ストリーム１
５１４（ｓｐｅｅｃｈ＿ｓｅｑｕｅｎｃｅ）の、過去３０秒間のタプルをカウントする。
該クエリの結果のリレーション名をｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔとす
る。クエリ１０１２は、ストリーム１５１１（ｓｔａｒｔ＿ｓｐｅｅｃｈ）の、過去３０
秒間のタプルをカウントする。該クエリの結果のリレーション名をｒｅｃｅｎｔ＿ｓｐｅ
ａｋｅｒｓ＿ｃｏｕｎｔとする。クエリ１０１３は、両者の積を算出する。ｒｅｃｅｎｔ
＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔとｒｅｃｅｎｔ＿ｓｐｅａｋｅｒｓ＿ｃｏｕｎｔのど
ちらのリレーションにおいても、自然数の値を持つｃｎｔカラムのみから成るタプルが、
常に丁度一つ生存することになる。従って、両者の積を取った結果も、常に丁度一つのタ
プルが生存するリレーションとなる。
【００７３】
但し、この積を単純に“ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ ＊
ｒｅｃｅｎｔ＿ｓｐｅａｋｅｒｓ＿ｃｏｕｎｔ．ｃｎｔ”で計算すると、一人の発言者
が長時間話している期間では、会話数が０になるので、結果も０となってしまう。これを
回避するため、“ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ”の代わりに
、“（ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ ＋１／（１＋ｒｅｃｅ
ｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ））”を利用する。“＋”以降の、“＋
１／（１＋ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ）”の部分は、整数
の商であるため、ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔが０の場合に
＋１、０より大きい場合に＋０となる。その結果、誰も発言者が居ない沈黙の期間は盛り
上り度が０、一人の発言者が長時間話している期間は１、二人以上の発言者がいる期間は
発言者数と会話数の積となる。以上、クエリ１０１０では、会議出席者の中で議論に参加
している人数が多いこと、および、意見の交換が頻繁であることを、盛り上がり度の指標
としている。
【００７４】
クエリ１０２０は、発言者の身振りの強度として、盛り上り度を算出する。クエリ１０
２１は、身振りの瞬間強度を表すストリーム１５０３（ｍｏｔｉｏｎ）をＮＯＷウィンド
ウで処理した結果のリレーションと、発言者の発言期間を表すリレーション１５１０（ｓ
ｐｅｅｃｈ）とを、ｎａｍｅカラムに関する結合演算にかけることで、発言中の出席者に
ついて身振り強度を抽出する。クエリ１０２２は、過去３０秒間における、発言者の身振
り強度を累積する。以上、クエリ１０２０では、発言者の身振りの強弱が、議論の白熱度
を反映すると仮定し、盛り上り度の指標としている。
【００７５】
ここで示した盛り上り度の定義は一例であり、会議の盛り上り度の数値化は、確立した
定義のない、人間の主観に関わるデータであるため、試行を繰返し的確な定義を探索する
必要がある。新しい定義を試行する度に、算出ロジックを、Ｃ、Ｃ＃、Ｊａｖａ（登録商
標）などの手続き型言語でコーディングするのでは、開発工数が甚大である。特に、クエ
リ１０１０のような、発言間の順序関係に基づいた指標を算出するロジックは、コードが
複雑化し、デバグも困難となる。これに対し、議論活性化度などを例示して説明した本実
施例のように、ストリームデータ処理を利用することで、簡潔な宣言型クエリによる定義
が可能となるため、このような工数を大幅に軽減する。
【００７６】
次に、図１３を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位１３１０
、１３２０、１３３０の実現方法を開示する。
【００７７】
コマンド１３００を、クエリ登録インタフェース２０２を介して、ストリームデータ処
理１００に投入することで、基本処理単位１３１０、１３２０、１３３０を実現する実行
木が生成される。
【００７８】
多くの出席者から賛同を得た発言は、会議中の重要発言であると捉える。このような発
言を抽出するために、クエリ１３１０は、リレーション１５１０（ｓｐｅｅｃｈ）と、う
なずき状態を表すストリーム１５０４（ｎｏｄ）から、発言者の意見が多数の出席者に賛
同されている（＝うなずかれている）状態を抽出する。うなずき状態の検出は、名札型セ
ンサノード７０が備える加速度センサ７４１で計測する加速度値より、パターン認識技術
を利用して、実現することが可能である。本実施例では、１秒間隔で、その時刻において
出席者がうなずき動作中である場合に、該出席者名をｎａｍｅカラムに示すタプルが発生
する、と仮定する。まず、ストリーム１５０４上の各タプルに対し、ウィンドウ演算“［
ＲＡＮＧＥ １ ｓｅｃ］”によって１秒の生存期間を定義することで、出席者ごとのう
なずき期間を表すリレーションが得られる（例：リレーション１３０２）。
【００７９】
該リレーションと、発言期間を表すリレーション１５１０（例：リレーション１３０１
）を、ｎａｍｅカラムに関する結合演算（一致しないことを条件とする）にかけることで
、発言者以外の出席者がうなずいている期間を、タプルの生存期間とするリレーション（
例：リレーション１３１２）が得られる。該リレーションにおいて、生存タプルが２個以
上ある（＝２人以上の出席者が、うなずきながら聞いている）期間を、ＨＡＶＩＮＧ句に
よって抽出する。このとき、射影演算によって、発言者の名前（ｓｐｅｅｃｈ．ｎａｍｅ
カラム）と、定数文字列’ｙｅｓ’の値を持つｆｌａｇカラムから成るタプルを出力する
（例：リレーション１３１３）。この結果をＩＳｔｒｅａｍでストリーム化し、クエリ１
３１０の結果を得る（例：ストリーム１３１１）。ストリーム１３１１は、発言者Ｂの発
言が、他の出席者ＣとＤの二人にうなずかれたタイミングで、タプルが発生する様子を示
している。
【００８０】
クエリ１３１０によって、重要発言の発生を抽出する一方、発言の内容は、ストリーム
１５０５（ｓｔａｔｅｍｅｎｔ）としてＰＣ１０から入力される。発言内容は議事録係の
キーストロークから抽出されるため、音声解析と加速度解析から自動抽出した重要発言の
発生タイミングに対し、数十秒遅れて入力されることになる。これに対し、クエリ１３２
０、およびクエリ１３３０は、ある発言者の重要発言が検出された後、最初に入力された
該発言者の発言内容に、重要発言のフラグを立てる処理である。
【００８１】
クエリ１３２０は、発言者ごとに、発言重要度を表すフラグを保持するトグルスイッチ
の役目を果たす。該クエリの結果リレーションａｃｃｅｐｔａｎｃｅ＿ｔｏｇｇｌｅは、
次にストリーム１５０５（ｓｔａｔｅｍｅｎｔ）から入力される発言内容が、重要発言と
なるか否かを、発言者ごとに表している（例：リレーション１３２１）。ｎａｍｅカラム
は発言者名を示し、ｆｌａｇカラムは、’ｙｅｓ’／’ｎｏ’によって重要性を示してい
る。クエリ１３３０は、ストリーム１５０５をＮＯＷウィンドウでリレーション化した結
果と、クエリ１３２０の結果リレーションを、ｎａｍｅカラムに関する結合演算で処理し
、発言内容に重要性の指標を付加して出力する（例：ストリーム１３３１）。
【００８２】
クエリ１３２０では、まず、ストリーム１５０５から発言内容の入力があった際に、そ
の発言者に関する重要度のフラグを’ｎｏ’にクリアするタプルを生成する。但し、該タ
プルのタイムスタンプは、元となる発言内容タプルのタイムスタンプから、若干時刻を遅
らせる。この処理を、“ＤＳＴＲＥＡＭ（ｓｔａｔａｍｅｎｔ［ＲＡＮＧＥ １ ｍｓｅ
ｃ］）”の記述によって定義している。例として、ｓｔａｔｅｍｅｎｔストリーム１３０
３上のストリームタプル１３０４が入力されると、そこから１ ｍｓｅｃ分タイムスタン
プのずれたストリームタプル１３２４が、中間状態ストリーム１３２２上に発生する。こ
のような’ｎｏ’タプルのストリームと、クエリ１３１０の結果を、和集合演算“ＵＮＩ
ＯＮ ＡＬＬ”でマージする。例として、該ストリーム１３２２と、ストリーム１３１１
のマージ結果が、ストリーム１３２３となる。このストリームを、ウィンドウ演算“ＰＡ
ＲＴＩＴＩＯＮ ＢＹ ｎａｍｅ ＲＯＷＳ １］”でリレーション化する。このウィン
ドウ演算は、ｎａｍｅカラムの値に基づいて分けた各グループを、同時生存数１個の個数
ウィンドウでリレーション化する。これにより、各発言者別に、重要度’ｙｅｓ’か’ｎ
ｏ’どちらか一方のフラグが立つことになる。例として、ストリーム１３２３をリレーシ
ョン化した結果が、リレーション１３２１となる。ここで、’ｎｏ’タプルのタイムスタ
ンプを若干ずらす理由は、クエリ１３３０において、’ｎｏ’タプルと、その元となるｓ
ｔａｔｅｍｅｎｔタプル自身が、結合するのを避けるためである。以上で、アクティビテ
ィデータ生成１００Ｃの処理が完了する。
【００８３】
続いて、アクティビティデータ生成１００Ｃによって得られたアクティビティデータに
基づいて、表示処理部２０３、即ち集計処理サーバ２００の処理部（ＣＰＵ）で実行され
る描画処理プログラムによって得られる画面イメージを図１６、１７を用いて説明する。
【００８４】
図１６は、発言者の動きに基づいたアクティビティデータ１５２０を、動きの活性度３
１１Ｍとして、活性度・発言表示３１０Ａに反映した画面イメージである。本画面により
、会議内での活動について、単なる音声だけではなくメンバの行動面を併せて可視化する
ことができる。
【００８５】
また、図１７は、うなずきによる発言の重要度を示すアクティビティデータ１５２１を
、重要発言指標３１１ａとして、活性度・発言表示３１０Ｂに反映した画面イメージであ
る。メンバの発言３１３と重要発言指標３１１ａとをリンクさせて表示することにより、
どの発言が参加メンバの納得感を得たものなのかを可視化することができる。このように
、本画面により、単なる音声だけではなく、メンバの納得度を併せて会議状況を可視化す
ることができる。
【００８６】
さて図１４は、図２で示した機能モジュールでの処理シーケンスの別の実施例を示した
ものである。本実施例における処理シーケンスでは、音声処理部４２において、特徴量デ
ータを取得した後、音声処理サーバ４０において、音声／非音声判別処理、スムージング
処理、及び音源選択処理を実行する。好適には、これらの処理も、音声処理サーバ４０の
図示されない処理部（ＣＰＵ）のプログラム処理として実行される。
【００８７】
図１４において、図２同様、センサ（マイク）２０では音声データが取得される（２０
Ａ）。次に、サウンドボード４１にて、音声のサンプリング処理が行なわれる（４１Ａ）
。次に音声処理部４２にて、特徴量の抽出（エネルギーへの変換）が行なわれる（４２Ａ
）。エネルギーは数ミリ秒の音波形の絶対値の２乗を全範囲に渡って積分したものである
。
【００８８】
本実施例においては、音声処理サーバ４０の音声処理４２として、特徴量抽出（４２Ａ
）から取得した特徴量データをもとに、音声／非音声の識別を行なう（４２Ｂ）。音声／
非音声の識別方法として、数秒時間におけるエネルギーの変化度合いによる識別があげら
れる。音声には特有の音波形エネルギーの強弱とその変化パターンがあり、それらを用い
ることで音声と非音声の識別を行なう。
【００８９】
また、数秒単位の音声/非音声識別結果をそのまま用いると、数１０秒からなる意味の
かたまりとしての1発話単位の区間を求めることが難しい。そこで、スムージング処理（
４２Ｃ）を導入することにより、１発話単位の区間を求め，これを音源選択に使用する。
【００９０】
上述の部分は音声処理４２で、センサ（マイク）２０毎に行なう処理であり、最終的に
どのセンサ（マイク）２０から音声が入力されたかを判断する必要がある。そこで本実施
例においては、音声処理４２において、スムージング処理（４２Ｃ）に引続き音源選択４
２Ｄを行ない、センサ（マイク）２０の中から実際に発話されたセンサ（マイク）２０を
選択する。一番近くのセンサ（マイク）２０に届く音声は、その他のセンサ（マイク）２
０より音声と判断される区間が長い。よって、本実施例においては、それぞれのセンサ（
マイク）２０のスムージング処理４２Ｃの結果から一番長かったセンサ（マイク）２０を
音源選択４２Ｄの出力とした。次に、ストリームデータ処理部１００にて、アクティビテ
ィデータ生成（１００Ｃ）が行なわれ、最後に、表示処理部２０３にて、アクティビティ
データＡＤに基づいた、画面データ生成（２０３Ａ）が行なわれることは先に説明した通
りである。
【符号の説明】
【００９１】
１０…ＰＣ、２０…センサ（マイク）、３０…会議卓、４０…音声処理サーバ、１００
…ストリームデータ処理部、２００…集計処理サーバ、３００…モニタ画面、３１０…会
議活性度・発言内容表示、３２０…発言累積表示、３３０…発言シーケンス表示。
【技術分野】
【０００１】
本発明は、複数のメンバが集まる会議等において、音声データの収集および解析を行な
うことによって、リアルタイムにメンバ間のインタラクション状況を表示するための会議
可視化技術に関する。
【背景技術】
【０００２】
知識労働者の生産性、創造性を向上させる手法が注目を集めている。新規のアイデアや
知識（ナレッジ）を創出するためには、異分野の専門家が集まり、議論を重ねることが重
要である。その中でも、個人の持つ知恵を組織の財産として共有・管理していくための方
法としてナレッジマネジメントと呼ばれる方法論が注目されている。ナレッジマネジメン
トは、組織文化・風土の改革までを含めた考え方であり、情報技術による知識共有の支援
ツールとしてナレッジマネジメント支援ツールと呼ばれるソフトウェアが開発・販売され
ている。現在販売されているナレッジマネジメント支援ツールの多くはオフィスで生産さ
れた文書を効率的に管理する機能が中心である。また、オフィス内の知識の多くがメンバ
間のコミュニケーションの中に存在することに注目したものがある。特許文献１には、組
織のメンバ間でなされる対話の状況を蓄積する技術が開示されている。更に、電子的なコ
ミュニケーションの場を提供することで知識の表出化を促進するツールが開発されている
。特許文献２には、電子的なインタラクションという観点において、電子メールの送受信
数カウントの比較結果によってメンバ間の影響を表示する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２０２０３５号公報
【特許文献２】特開２００４−０４６６８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
新規のアイデアや知識（ナレッジ）を創出するためには、異分野の専門家が集まり、議
論を重ねることが重要であり、有限の時間を有効に使った実りのある議論のプロセスが重
要である。従来のナレッジマネジメントツールは、議論の過程に着目したものではなく、
その結果に対しての情報共有に主眼をおいている。特許文献１では、参加者もしくは参加
者以外のものが蓄積された対話状況を再現することが目的であり、対話のプロセス自体に
注目したものではない。また、特許文献２では、メンバ間の影響度合いを計算しているが
、電子メールの送受信数という単純な数値に基づいており、議論のプロセスにまで踏み込
んだものではない。しかも、電子メールによるインタラクションは、一般的に深い議論を
行なうには、適しておらず、例え、高精細なテレビ会議システムなど、電子的なインタラ
クション技術が成熟したとしても、フェイス・トゥ・フェイスでの議論を完全に置換する
ものにはなり得ない。オフィスでのナレッジ創出には電子的なメディアを介さないフェイ
ス・トゥ・フェイスでの会話や会議が必須となっている。
【０００５】
本発明は、複数のメンバが集まる会議等において、アイデアやナレッジの創出を促進・
誘発するための情報処理システムに関するものである。会議中の音声を取得して、発言者
（発話者）および、その発言回数、対話シーケンス、会議の活性度を計算して、刻々と変
わる会議の状況をリアルタイムに表示することで、参加者自身にフィードバックがかかり
、より積極的な議論を誘発するする会議可視化システムの提供を目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明においては、会議における複数の会議参加者間の対話
状況を可視化して表示する会議可視化システムであって、会議参加者に対応した複数の音
声収集部と、音声収集部から収集した音声データを処理し、発話情報を抽出する音声処理
部と、音声処理部で抽出された発話情報が順次入力され、この発話情報に対してクエリ処
理を施すことにより会議参加者の会議におけるアクティビティデータを生成するストリー
ム処理部と、このアクティビティデータに基づき、前記会議参加者の対話状況を可視化し
て表示させる表示処理部とを有する
会議可視化システムを提供する。
本発明においては、音声データに所定の処理を行ない、発言者およびその発言回数、対
話回数を特定し、発言回数を円の大きさで、対話回数を線の太さで、リアルタイムに表示
する。さらに、キーストローク情報から得られた議論内容、発言者毎の発言回数累積、活
性度を同時に表示する。
【発明の効果】
【０００７】
本発明によれば、議論状況をリアルタイムに把握しながら、議論を行なうことにより、
発言量が足りないメンバに対しては発言を促すようなフィードバックがかかる。もしくは
、会議の調停者が、議論状況をリアルタイムに把握しつつ、より多く参加者からのアイデ
アを出してもらうようなコントロールを行なうことで、議論の活性化および有効なナレッ
ジ創出が期待できる。
【図面の簡単な説明】
【０００８】
【図１】第一の実施例の会議可視化システムの構成図。
【図２】第一の実施例の会議可視化システムのシーケンス図。
【図３】第一の実施例の会議可視化システムの使用例を示す図。
【図４】第一の実施例の参加者登録画面のイメージ図。
【図５】実施例の一般的なストリームデータ処理の構成図。
【図６】実施例の入力ストリームのスキーマ登録例を説明するための図。
【図７】実施例の音源選択処理の実現形態を説明するための図。
【図８】実施例のスムージング処理の実現形態を説明するための図。
【図９】実施例のアクティビティデータ生成処理の実現形態を説明するための図。
【図１０】実施例のアクティビティデータ生成処理の実現形態を説明するための図。
【図１１】第二の実施例の無線センサノードのブロック図。
【図１２】第二の実施例の名札型センサノードの使用形態を説明するための図。
【図１３】実施例のアクティビティデータ生成処理の実現形態を説明するための図。
【図１４】会議可視化システムの処理シーケンスの他の実施例を示す図。
【図１５】ストリームデータ処理による、会議可視化データ処理の実現例を詳細に説 明するための図。
【図１６】会議可視化システムの各実施例における会議の活性化度表示の他の表示例 を示す図。
【図１７】会議可視化システムの各実施例における会議の活性化度表示の他の表示例 を示す図。
【発明を実施するための形態】
【０００９】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【実施例１】
【００１０】
図３に第一の実施例の会議可視化システムを利用した会議シーンの一例を示す。４人の
メンバ（メンバＡ、メンバＢ、メンバＣ、メンバＤ）が会議を行なっている。会議卓に設
置されたマイク（マイクＡ、マイクＢ、マイクＣ、マイクＤ）より各メンバの発話がセン
シングされて、これらの発話データは音声処理サーバ４０を経由したのち、集計処理サー
バ２００で所定の処理が行なわれ、最終的に、この会議の状況がモニタ画面３００にリア
ルタイムに表示されている。参加メンバが可視化された会議状況から直接フィードバック
を受けることで、各メンバが発言のモチベーションを高めたり、司会者がより多くのアイ
デアが集まるような会議進行を行なう、といった効果が期待される。なお、ここで音声処
理サーバ４０や集計処理サーバ２００などのサーバは、通常のコンピュータシステムと同
義であり、例えば、集計処理サーバ２００は、処理部（ＣＰＵ）、記憶部（半導体メモリ
や磁気記憶装置）、キーボードやマウスなどの入力部、ネットワークと接続される通信部
などの入出力インタフェース部、更に必要ならＣＤやＤＶＤなどのメディアの読取書込み
部などが内部バスで接続されている構成を有する。この音声処理サーバ４０と集計処理サ
ーバ２００は、一個のサーバ（コンピュータシステム）で構成して良いことはいうまでも
ない。
【００１１】
図１に第一の実施例の会議可視化システムの全体図を示す。会議可視化システムは、活
動状況のセンシング、センシングデータの集計・解析処理、および、結果の表示、という
大きく分けて３つの機能より構成される。以下、これらの順番に従ってシステムの詳細を
説明する。会議卓３０には、メンバの着座位置に応じて音声収集部であるセンサ（マイク
）２０が設置されており、メンバが会議にて発言を行なった場合には、これらセンサ２０
にて発言のセンシングを行なう。また、会議卓３０には、パーソナルコンピュータ（ＰＣ
）１０が設置されている。このＰＣ１０は、キーストローク情報出力部として機能し、会
議の記録係が会議録を記述する際のキーストロークデータを出力する。このキーストロー
クデータは、集計処理サーバ２００の入出力インタフェース部を介して、サーバ２００内
に入力される。
【００１２】
図１の例においては、４つのセンサ（センサ２０−０〜２０−３）が設置されており、
それぞれ、メンバＡ〜メンバＤの発話音声を取得する。センサ２０から取得された音声デ
ータは音声処理サーバ４０に転送される。音声処理サーバ４０においては、その内部に設
置されたサウンドボード４１にて音声データのサンプリング処理が行なわれ、その後、音
声処理部４２にて、音の特徴量データ（具体的には、音声エネルギーの大きさ等）が抽出
される。通常この音声処理部４２は、音声処理サーバ４０内の図示されていない処理部（
ＣＰＵ）におけるプログラム処理として構成される。そして、音声処理サーバ４０にて生
成された特徴量データは、その入出力インタフェース部を介して、メンバの発話情報とし
て集計処理サーバ２００の入出力インタフェース部に転送される。転送される音声特徴量
データ５２は、時刻５２Ｔ、センサＩＤ（識別子）５２Ｓ、および、エネルギー５２Ｅを
含んでいる。また、発言者発言内容出力部であるＰＣ１０から取得されたキーストローク
データ５１も、集計処理サーバ２００に転送され、これは、時刻５１Ｔ、発言者５１Ｎ、
および、発言内容５１Ｗを含んでいる。
【００１３】
これらのセンシングデータは、集計処理サーバ２００内のストリームデータ処理部１０
０にて、会議の状況を可視化するためのデータである、アクティビティデータＡＤに変換
される。ストリームデータ処理１００では、それぞれのデータソースに対応したＷｉｎｄ
ｏｗ１１０を持っており、一定時間メモリに蓄えられている時系列のデータセットに対し
て、所定の数値演算処理を行なう。この演算処理は、リアルタイムクエリ処理１２０と呼
ばれ、具体的なクエリの設定や、参加者とデータのＩＤとの対応付けは、それぞれ、クエ
リ登録インタフェース２０２、参加者登録インタフェース２０１を通して行なわれる。な
お、上述のストリームデータ処理部１００、参加者登録インタフェース２０１、クエリ登
録インタフェース２０２は、先に説明した集計処理サーバ２００の図示されない処理部（
ＣＰＵ）で実行されるプログラムとして構成される。
【００１４】
通常、ストリームデータ処理部１００で生成されたアクティビティデータＡＤは、集計
処理サーバ２００中の図示されない記憶部中のテーブルなどに記憶され、順次、表示処理
部２０３の処理対象なる。本実施例では、具体的な、アクティビティデータＡＤとして、
４つのデータが生成される。
【００１５】
１つ目は、議論活性化度５４であり、これは、時刻５４Ｔと、その時刻での議論の活性
化度５４Ａより構成される複数のリストである。議論活性化度５４Ａは、その議論に関し
ての発言量総和やメンバ参加数等をパラメータにして、計算される。例えば、単位時間当
たりの、発言総回数と発言を行なった参加者総数によって決定される。同図１では、一分
当たりの議論活性化度５４を例示している。２つ目のアクティビティデータは、発言内容
データ５５であり、これは、時刻５５Ｔと、その時刻に対応する発言者５５Ｓと発言内容
５５Ｃ、および、重要性５５Ｆより構成されている。実際には、ＰＣ１０からのキースト
ロークデータ５１に含まれる、時刻５１Ｔ、発言者５１Ｎ、および、発言内容５１Ｗが、
それぞれ、時刻５５Ｔ、発言者５５Ｓ、発言内容５５Ｃにマッピングされる。３つ目のア
クティビティデータは、発言回数データ５６であり、これは、時刻５６Ｔと、その時刻に
対応する、発言者５６Ｎと、発言者５６Ｎに対応する発言累積（回数）５６Ｃより構成さ
れている。４つ目のアクティビティデータは、発言シーケンスデータ５７であり、これは
、時刻５７Ｔと、その時刻に対応する、発言者の発話の順序関係である。具体的には、そ
の時刻にて、発言者（前）５７Ｂの発話の直後に、発言者（後）５７Ａが発話を行なった
回数５７Ｎを、あるウィンドウ時間内で求めたものである。
【００１６】
さて、ストリームデータ処理部１００で生成されたアクティビティデータＡＤに基づき
、表示処理部２０３にて描画処理が行なわれる。即ち、アクティビティデータＡＤは、次
段の表示処理部２０３にて、描画処理の素材データとして使用される。この表示処理部２
０３も集計処理サーバ２００の処理部（ＣＰＵ）で実行される描画処理プログラムとして
提供される。例えば、Ｗｅｂベースでの表示を行なう場合には、表示処理部２０３でＨＴ
ＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｋｅｕｐ Ｌａｎｇｕａｇｅ）画像の生成処理等が行
なわれる。表示処理部２０３で生成された画像は、入出力インタフェース部を介して、モ
ニタに出力され、モニタ画面３００に示される画面構成で表示される。会議の様子は、モ
ニタ画面３００にて、活性度・発言表示３１０、発言累積３２０、および、発言シーケン
ス３３０の３つの要素として表示される。
【００１７】
以下、素材データであるアクティビティデータを用いて表示される３つの要素について
説明する。活性度・発言表示３１０では、時間軸に沿って、リアルタイムにその会議の活
性度３１１と発言３１３が表示される。活性度３１１は、アクティビティデータＡＤの議
論活性化度５４の表示を行なったものであり、発言３１３はアクティビティデータＡＤ発
言内容データ５５を表示したものである。また、会議の統計データなどに基づいて、活性
度の指標３１２を表示することも可能である。発言累積３２０は、アクティビティデータ
ＡＤの発言回数データ５６に基づいて、会議開始からの参加者毎の発言回数を累積として
表示したものである。最後に、発言シーケンス３３０は、アクティビティデータＡＤの発
言回数データ５６と発言シーケンスデータ５７を使用して、参加者間の発話のやり取りを
可視化したものである。
【００１８】
具体的には、この発言シーケンス３３０で図示されている参加者毎の円の大きさ（３３
１Ａ、３３１Ｂ、３３１Ｃ、および、３３１Ｄ）は、過去から現在までの一定期間（例え
ば５分間）においての発言回数を円の大きさとして表しており、円と円との間のリンクの
太さは、参加者間での会話が多いか少ないか（会話のインタラクションの量）を可視化し
たものである。例えば、ＡとＢとの間のリンク３３２は細く、ＡとＤとの間のリンク３３
３は太く描かれており、ＡとＤとのインタラクションが多いことが示されている。本例で
は、Ａの発言の後にＤが発言した場合と、Ｄの発言の後にＡが発言した場合とは区別され
てはいないが、発言シーケンスデータ５７を使用することによりこれらを区別するような
表示方法も可能である。素材データ各々を用いて、これら活性度・発言表示３１０、発言
累積３２０、および発言シーケンス３３０の各要素を適宜表示することは、通常の図形描
画処理プログラムを、集計処理サーバ２００の図示されない処理部（ＣＰＵ）で実行する
ことにより実現できることは言うまでもない。
【００１９】
図２は、図１で示した全体図における代表的な機能モジュールでの処理シーケンスを示
したものである。まず音声収集部としてのセンサ（マイク）２０では音声データが取得さ
れる（２０Ａ）。次に、サウンドボード４１にて、音声のサンプリング処理が行なわれる
（４１Ａ）。次に音声処理部４２にて、発話情報としての特徴量の抽出（具体的にはエネ
ルギーへの変換）が行なわれる（４２Ａ）。エネルギーは、例えば数ミリ秒の音波形の絶
対値の２乗を全範囲に渡って積分したものである。なお後段にてより確度の高い音声処理
を行なうために、ここで、音声／非音声の識別を行なうことも可能である（４２Ｂ）。音
声／非音声の識別方法として、時間におけるエネルギーの変化度合いによる識別があげら
れる。音声には音波形エネルギーの強弱とその変化パターンがあり、それらを用いること
で音声と非音声の識別を行なう。上述の通り、特徴量抽出４２Ａ、更には音声／非音声判
別４２Ｂは、図示されない処理部（ＣＰＵ）のプログラム処理として実行される。
【００２０】
次に、ストリームデータ処理部１００にて、音源の選択（１００Ａ）、スムージング処
理（１００Ｂ）、アクティビティデータ生成（１００Ｃ）が行なわれる。最後に、表示処
理部２０３にて、アクティビティデータＡＤに基づいた、画面データ生成（２０３Ａ）が
行なわれる。なお、これらの具体的構成は他の実施例とも共通する部分が多いので後述す
る。
【００２１】
図４は参加者の登録画面６０を示したものである。会議卓３０のそれぞれの座席に座る
メンバとマイク（２０）とを対応させるために、画面の座席位置（６１Ａ〜６１Ｆ）の空
欄に参加者の名前を入力して登録を行なう（６２）。図４では、座席位置６１Ａ、６１Ｂ
、６１Ｃ、６１Ｄに、それぞれ、参加者の名前Ａ、Ｂ、Ｃ、Ｄを登録している例を示して
いる。なお、この登録画面６０は、上述したＰＣの画面や、各自の座席位置に設置した手
書き文字入力タブレットの入力画面等を用いれば良い。これらの登録作業は、これらの手
段によって入力された名前データに基づき、集計処理サーバ２００の参加者登録インタフ
ェース２０１を使用して行なわれる。
【００２２】
以上説明した第一の実施例の会議可視化システムにより、発言者および、その発言回数
、対話シーケンス、会議の活性度を計算して、刻々と変わる会議の状況をリアルタイムに
表示することが可能となるため、参加者にフィードバックがかかって、より積極的で活性
度の高い議論を誘発することができる。
【実施例２】
【００２３】
第一の実施例では、マイク２０から取得した音声データをベースに会議を可視化する方
法を示した。第二の実施例においては、会議の参加メンバに無線センサノードと呼ばれる
デバイスを与えることで、音声以外の情報も加味してより詳細に会議の状況を可視化する
会議可視化システムを提供する。
【００２４】
まず、無線センサノードの構成について図１１を用いて説明する。図１１は、無線セン
サノード７０の構成の一例を示すブロック図である。無線センサノード７０は、メンバ自
身の動きの測定（加速度を使用）、音声の測定（マイクロホンを使用）、着席位置の測定
（赤外線の送受信を使用）を行なうセンサ７４と、センサ７４を制御するコントローラ７
３と、無線基地局７６と通信を行なう無線処理部７３と、これらの各ブロックに電力を供
給する電源７１、無線データの送受信を行なうアンテナ７５より構成される。センサ７４
には具体的には、加速度センサ７４１、マイクロホン７４２、赤外線送受信器７４３が搭
載されている。
【００２５】
コントローラ７３は、予め設定された周期、もしくは不定期にセンサ７４の測定データ
を読み込み、この測定データに予め設定したセンサノードのＩＤを加えて無線処理部７２
に転送する。測定データにはセンシングを行った時間情報をタイムスタンプとして与える
場合もある。無線処理部７２は、コントローラ７３から送られたデータを基地局７６（図
１２に示す）に送信する。電源７１は、電池を使用する場合や、太陽電池や振動発電など
の自律発電機構を具備する構成としても良い。
【００２６】
図１２に示すように、この無線センサノード７０を名札型に加工した名札型センサノー
ド７０Ａをユーザが装着することにより、ユーザの状態（動き等）に関するセンシングデ
ータを、リアルタイムに無線基地局７６を経由して、集計処理サーバ２００に送信するこ
とが可能となる。さらに、図１２に示すように、会議卓の各座席位置に設置された赤外線
送信器７７からのＩＤ情報を、名札型センサノード７０Ａが赤外線送受信器７４３にて定
期的に検出することで、着席位置の情報を自律的に集計処理サーバ２００に送信すること
も可能となる。このように、本実施例においては、名札型センサノード７０が、ユーザの
着席位置を、自動的に集計処理サーバ２００に送付すれば、登録画面６０を使用した参加
者登録処理（図４）を自動化することが可能となる。
【００２７】
さて次に、図５以下の図面を用いて、上述した会議可視化システムを実現するストリー
ムデータ処理部１００について詳述する。上述の各実施例におけるアクティビティデータ
生成にはストリームデータ処理を用いる。このストリームデータ処理と呼ばれる技術自身
は公知の技術であり、Ｂ．Ｂａｂｃｏｃｋ、Ｓ．Ｂａｂｕ、Ｍ．Ｄａｔａｒ、Ｒ．Ｍｏｔ
ｗａｎｉ ａｎｄ Ｊ．Ｗｉｄｏｍ、“Ｍｏｄｅｌｓ ａｎｄ ｉｓｓｕｅｓ ｉｎ ｄ
ａｔａ ｓｔｒｅａｍ ｓｙｓｔｅｍｓ”、Ｉｎ Ｐｒｏｃ． ｏｆ ＰＯＤＳ ２００
２、 ｐｐ．１−１６．（２００２）、Ａ．Ａｒａｓｕ、Ｓ．Ｂａｂｕ ａｎｄ Ｊ．Ｗ
ｉｄｏｍ、“ＣＱＬ： Ａ Ｌａｎｇｕａｇｅ ｆｏｒ Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅ
ｒｉｅｓ ｏｖｅｒ Ｓｔｒｅａｍｓ ａｎｄ Ｒｅｌａｔｉｏｎｓ”、Ｉｎ Ｐｒｏｃ
． ｏｆ ＤＢＰＬ ２００３、 ｐｐ．１−１９ （２００３）、などの文献に開示さ
れている。
【００２８】
図５は図１のストリームデータ処理部１００の機能動作を説明するための図である。ス
トリームデータ処理は、絶え間なく到来するデータの流れを対象に、フィルタリング処理
や集計処理などを、継続的に実行する技術である。個々のデータにはタイムスタンプが付
与されており、データはタイムスタンプの昇順に並んで流れる。以下では、このようなデ
ータの流れをストリームと呼び、個々のデータをストリームタプル、あるいは単にタプル
と呼ぶ。ある一つのストリーム上を流れるタプルは、単一のデータ型に従う。このデータ
型をスキーマと呼ぶ。スキーマとは任意個のカラムの組合せであり、各カラムは一つの基
本型（整数型、実数型、文字列型など）と、一つの名前（カラム名）の組合せである。
【００２９】
ストリームデータ処理は、スキーマが定義されたストリーム上のタプルを対象に、リレ
ーショナルデータベースの計算モデルである関係代数に準じて、射影、選択、結合、集計
、和集合、差集合などの演算を実施する。但し、関係代数はデータの集合に対して定義さ
れるので、絶え間なくデータ列が続く（即ち、無限に集合の要素が増え続ける）ストリー
ムに対して関係代数を継続的に処理するには、処理対象となるタプルの集合を常に限定し
ながら実行する必要がある。
【００３０】
このために、ストリームデータ処理では、ある時刻において処理対象となるタプル集合
を限定する、ウィンドウ演算が定義されている。このように、ストリーム上のタプルは、
関係代数で処理される前に、まずウィンドウ演算によって、処理対象となる期間を定義さ
れる。以下では、この期間をタプルの生存期間と呼び、生存期間を定義されたタプルの集
合をリレーションと呼ぶ。そして、このリレーションに対して関係代数が実施される。
【００３１】
ウィンドウ演算の例を、５０１〜５０３を用いて説明する。５０１はストリームを、５
０２および５０３は、ストリーム５０１に対してウィンドウ演算を施した結果である、リ
レーションを示している。ウィンドウ演算は、生存期間の定義の仕方によって、時間ウィ
ンドウと個数ウィンドウに分かれる。時間ウィンドウは、各タプルの生存期間を定数時間
に定める。一方、個数ウィンドウは、同時に生存するタプルの個数を定数個に制限する。
リレーション５０２および５０３は、ストリーム５０１を時間ウィンドウ（５２１）と個
数ウィンドウ（５２２）で処理した結果を、それぞれ示している。
【００３２】
ストリームの図における各黒丸はストリームタプルを表す。ストリーム５０１には、１
時２分３秒、４秒、７秒、８秒、１０秒、および１１秒に流れてくる、６つのストリーム
タプルが存在する。一方、リレーションの図における、黒丸を起点、白丸を終点とする各
線分は、タプルの生存期間を表す。なお、丁度終点の時刻は生存期間に含まれない。リレ
ーション５０２は、ストリーム５０１を、生存期間３秒の時間ウィンドウで処理した結果
である。例として、１時２分３秒のタプルの生存期間は、１時２分３秒から１時２分６秒
までとなる。但し１時２分６秒丁度は生存期間に含まれない。リレーション５０３は、ス
トリーム５０１を、同時生存数３個の個数ウィンドウで処理した結果である。例として、
１時２分３秒のタプルの生存期間は、１時２分３秒から、その３個後に流れてくるタプル
のタイムスタンプ１時２分８秒までとなる。但し１時２分８秒丁度は生存期間に含まれな
い。
【００３３】
リレーション上の関係代数は、入力のリレーションに対する演算結果として、次のよう
な性質を持つ結果リレーションを出力する。まず、入力リレーションにおいて、ある時刻
に生存するタプルの集合に対し、従来の関係代数を実施した結果を、該時刻における結果
タプル集合と呼ぶ。このとき、任意の時刻において、該時刻における結果タプル集合が、
結果リレーションにおいて該時刻に生存するタプルの集合と一致する。
【００３４】
リレーション上の関係代数の例を、５０４〜５０８を用いて説明する。この例は、リレ
ーション５０４とリレーション５０５の間の差集合演算を示し、リレーション５０６、５
０７、５０８は、その結果を示している。例えば、入力リレーション５０４と５０５にお
いて、１時２分８秒に生存するタプル集合は、それぞれ２個のタプルと１個のタプルから
成る。従って、１時２分８秒の結果タプル集合（即ち、両タプル集合の差集合）は、２−
１＝１個のタプルから成るタプル集合である。このような関係が、１時２分７秒から１時
２分９秒までの期間で成立する（但し、１時２分９秒丁度は含まず）。従って、結果リレ
ーションにおいて、この期間に生存するタプルは１個となる。結果リレーションの例とし
て、５０６、５０７、５０８は、全てこの性質を持つ。このように、一般に、リレーショ
ン上の関係代数の結果は、一意には定まらない。但し、ストリームデータ処理においては
、その何れも、リレーション上の関係代数の対象として等価である。
【００３５】
以上のように、リレーション上の関係代数の結果は一意には定まらないため、そのまま
アプリケーションに渡すことは好ましくない。これに対し、ストリームデータ処理では、
リレーションをアプリケーションに渡す前に、再びストリームに変換する演算が用意され
ている。これを、ストリーム化演算と呼ぶ。ストリーム化演算は、等価な結果リレーショ
ンの全てを同一のストリームに変換する。
【００３６】
ストリーム化演算によってリレーションから変換されたストリームを、さらにウィンド
ウ演算でリレーションに変換することも可能である。このように、ストリームデータ処理
の中では、リレーション化とストリーム化を任意に組合せることが可能である。
【００３７】
ストリーム化演算は、ＩＳｔｒｅａｍ、ＤＳｔｒｅａｍ、ＲＳｔｒｅａｍの３種類に分
かれる。ＩＳｔｒｅａｍは、リレーションにおいて、ある時刻に生存するタプル集合に、
タプルの増加があった場合に、その増加分のタプルを、該時刻をタイムスタンプとするス
トリームタプルとして出力する。ＤＳｔｒｅａｍは、リレーションにおいて、ある時刻に
生存するタプル集合に、タプルの減少があった場合に、その減少分のタプルを、該時刻を
タイムスタンプとするストリームタプルとして出力する。ＲＳｔｒｅａｍは、一定時間間
隔で、リレーションにおいてその時点で生存するタプル集合を、ストリームタプルとして
出力する。
【００３８】
ストリーム化演算の例を、５０９〜５１１を用いて説明する。ストリーム５０９は、リ
レーション５０６〜５０８を、ＩＳｔｒｅａｍ（５２３）でストリーム化した結果である
。例として、リレーション５０６では、１時２分３秒にタプルが０個から１個に、１時２
分５秒に１個から２個に増える。このため、ストリーム５０９には１時２分３秒と１時２
分５秒に、それぞれ増分１個のストリームタプルが出力される。この結果は、リレーショ
ン５０７に対して処理しても変らない。例えば、リレーション５０７においては、１時２
分９秒に一つのタプルの生存期間が始まっているが、同時に、別のタプル（１時２分３秒
から生存期間が始まるタプル）の生存期間が終わる。このとき、後者のタプルの生存期間
に１時２分９秒丁度は含まれないため、１時２分９秒に生存するタプルは、丁度１個であ
る。従って、１時２分９秒にはタプルの増減は無いことになり、リレーション５０６に対
する結果と同じく、１時２分９秒のストリームタプルは出力されない。ＤＳｔｒｅａｍ（
５２４）とＲＳｔｒｅａｍ（５２５）についても同様に、リレーション５０６、５０７、
５０８の何れを対象としても、ストリーム化した結果は、それぞれストリーム５１０およ
びストリーム５１１になる（但し、ＲＳｔｒｅａｍのストリーム化間隔は１秒）。このよ
うに、一意には定まらない結果リレーションを、ストリーム化演算によって、一意のスト
リームに変換することが可能である。なお、以降の図では、生存期間終了の白丸を省略す
る。
【００３９】
ストリームデータ処理では、データ処理の内容をＣＱＬ（Ｃｏｎｔｉｎｕｏｕｓ Ｑｕ
ｅｒｙ Ｌａｎｇｕａｇｅ）という宣言型言語で定義する。ＣＱＬの文法は、リレーショ
ナルデータベースにおいて標準的に利用される、関係代数に基づくクエリ言語ＳＱＬに、
ウィンドウ演算、およびストリーム化演算の記法を追加した形式をとる。ＣＱＬ文法の詳
細な定義は、ｈｔｔｐ：／／ｉｎｆｏｌａｂ．ｓｔａｎｆｏｒｄ．ｅｄｕ／ｓｔｒｅａｍ
／ｃｏｄｅ／ｃｑｌ−ｓｐｅｃ．ｔｘｔに開示されている。ここでは、その概要を説明す
る。次の４行は、ＣＱＬ文法に従うクエリの一例である。
【００４０】
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｑ ＡＳ
ＩＳＴＲＥＡＭ（
ＳＥＬＥＣＴ ｃ１
ＦＲＯＭ ｓｔ［ＲＯＷＳ ３］
ＷＨＥＲＥ ｃ２＝５）
ＦＲＯＭ句の“ｓｔ”は、ストリームを表す識別子（以下、ストリーム識別子、あるい
はストリーム名と呼ぶ）である。ストリーム名に続く“［“と”］”に囲まれた部分は、
ウィンドウ演算を表す記法である。例中の記述“ｓｔ［ＲＯＷＳ ３］”は、ストリーム
ｓｔを、同時生存数３個の個数ウィンドウによって、リレーションに変換することを示し
ている。従って、この記述全体では、リレーションを出力する表現となる。なお、時間ウ
ィンドウは“［ＲＡＮＧＥ ３ ｓｅｃ］”のように、“ＲＡＮＧＥ”以降に生存期間を
示す記法となる。この他の記法として、“［ＮＯＷ］”と、“［ＵＮＢＯＵＮＤＥＤ］”
があり、それぞれ、非常に短い（但し、０ではない）生存期間と、永続を意味する。
【００４１】
ＦＲＯＭ句のリレーションを対象に、関係代数が実施される。例中の記述“ＷＨＥＲＥ
ｃ２＝５”は、カラムｃ２が５であるタプルを選択することを示している。また、例中
の記述“ＳＥＬＥＣＴ ｃ１”は、選択されたタプルのｃ１カラムのみを残して、結果リ
レーションとすることを示している。つまり、これらの記述の意味はＳＱＬと全く同じで
ある。
【００４２】
さらに、ＳＥＬＥＣＴ句からＷＨＥＲＥ句までの、リレーションを生成する表現全体を
、“（“と”）”で囲い、その前にストリーム化指定（例中の記述“ＩＳＴＲＥＡＭ”）
を置く記法は、該リレーションのストリーム化演算を示している。ストリーム化指定は、
他に“ＤＳＴＲＥＡＭ”と“ＲＳＴＲＥＡＭ”があり、“ＲＳＴＲＥＡＭ”では、“［“
、”］”で囲って、ストリーム化間隔を指定する。
【００４３】
この例のクエリは、以下のように分解して定義することも可能である。
【００４４】
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｓ ＡＳ
ｓｔ［ＲＯＷＳ ３］
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｒ ＡＳ
ＳＥＬＥＣＴ ｃ１
ＦＲＯＭ ｓ
ＷＨＥＲＥ ｃ２＝５
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｑ ＡＳ
ＩＳＴＲＥＡＭ（ｒ）
ここで、ウィンドウ演算の前に置けるのはストリームを生成する表現、ＦＲＯＭ句に登
場できるのはリレーションを生成する表現、ストリーム化演算の引数はリレーションを生
成する表現に、それぞれ限定される。
【００４５】
図５中のストリームデータ処理部１００は、以上のようなストリームデータ処理を実現
するためのソフトウェア構成を示す。ストリームデータ処理部１００は、ＣＱＬで定義さ
れたクエリが、クエリ登録インタフェース２０２に与えられると、クエリ解析部１２２で
クエリを構文解析し、クエリ生成部１２１によって、木構造の実行形式（以下、実行木と
呼ぶ）に展開する。該実行木は、各種演算を行なう演算子（ウィンドウ演算子１１０、関
係代数演算子１１１、ストリーム化演算子１１２）をノードとし、オペレータ間を繋ぐタ
プルキュー（ストリームキュー１１３、リレーションキュー１１４）をエッジとして構成
される。ストリームデータ処理部１００は、該実行木上の各演算子の処理を、適当な順番
で実行することで、処理を進める。
【００４６】
上述したストリームデータ処理技術に対応し、各実施例において、音声処理サーバ４０
から送られる発話情報であるストリーム５２、参加者登録インタフェース２０１を介して
登録されるストリーム５３、５８などの、ストリームデータ処理１００の外部から送られ
るストリームタプルは、まず、ストリームキュー１１３に入る。これらタプルは、ウィン
ドウ演算子１１０によって生存期間を定義され、リレーションキュー１１４に入る。リレ
ーションキュー１１４上のタプルは、関係代数演算子１１１によって、リレーションキュ
ー１１４を介してパイプライン的に処理される。リレーションキュー１１４上のタプルは
、ストリーム化演算子１１２によってストリーム化され、ストリームキュー１１３に入る
。ストリームキュー１１３上のタプルは、ストリームデータ処理部１００の外部へ送られ
るか、ウィンドウ演算子１１０で処理される。ウィンドウ演算子１１０からストリーム化
演算子１１２までのパスには、リレーションキュー１１４で接続された任意個の関係代数
演算子１１１が置かれる。一方、ストリーム化演算子１１２からウィンドウ演算子１１０
へは、一つのストリームキュー１１３で直接つながる。
【００４７】
次に、図１５を用いて、実施例の会議可視化システムにおけるストリームデータ処理部
１００による会議可視化データ処理の実現方法を具体的に開示する。
【００４８】
１５００〜１５２１は、ストリーム、またはリレーションの、識別名、およびスキーマ
を表す。上側の太枠四角が識別名を、下側の四角の並びがスキーマを構成するカラム名を
示している。７１０、７２０、７３０、８１０、８２０、８３０、８４０、８５０、９１
０、９２０、９３０、９４０、１０００、１０１０、１０２０、１３１０、１３２０、１
３３０の角丸四角は、データ処理の基本処理単位を示している。基本処理単位のそれぞれ
を、ＣＱＬ文法に従うクエリで実現する。クエリ定義、および動作の説明は、図７〜１０
、および図１３を用いて後述する。発話情報である音声特徴量データストリーム１５００
は、音声処理サーバ４０から、音量補正値ストリーム１５０１、および参加者ストリーム
１５０２は、参加者登録インタフェース２０１から、身振り強度ストリーム１５０３、お
よびうなずきストリーム１５０４は、名札型センサノード７０から、発言ログストリーム
１５０５は、ＰＣ（キーストロークセンシング）１０から、それぞれ送られてくる。これ
らを、音源選択１００Ａ、スムージング処理１００Ｂ、およびアクティビティデータ生成
１００Ｃの、各プロセスで順に処理して、出力となるストリーム１５１７〜１５２１を生
成する。１５０６〜１５１６は、中間データとなるストリーム、またはリレーションであ
る。
【００４９】
音源選択１００Ａの処理は、基本処理単位７１０、７２０、７３０から構成される。各
処理の実現形態については、図７を用いて後述する。スムージング処理１００Ｂは、基本
処理単位８１０、８２０、８３０、８４０、８５０から構成される。各処理の実現形態に
ついては、図８を用いて後述する。アクティビティデータ生成１００Ｃの処理は、基本処
理単位９１０、９２０、９３０、９４０、１０００、１０１０、１０２０、１３１０、１
３２０、１３３０から構成される。基本処理単位９１０〜９４０は、モニタ画面３００の
３２０に可視化される発言数１５１７、３３０に可視化される発言時間１５１８、および
会話数１５１９を生成する。これら基本処理単位については、図９を用いて後述する。基
本処理単位１０００〜１０２０は、モニタ画面３００の３１１に可視化される活性度１５
２０を生成する。これら基本処理単位については、図１０を用いて後述する。基本処理単
位１３１０〜１３３０は、モニタ画面３００の３１３に可視化される発言ログ１５２１を
生成する。これら基本処理単位については、図１３を用いて後述する。
【００５０】
次に、図６を用いて、入力ストリームのスキーマ登録について開示する。
【００５１】
コマンド６００を、例えば、集積解析処理サーバ２００の入力部からなどからクエリ登
録インタフェース２０２を介して、ストリームデータ処理部１００に投入することで、入
力ストリーム１５００〜１５０５を受け付ける６本のストリームキュー１１３が生成され
る。ＲＥＧＩＳＴＥＲ ＳＴＲＥＡＭ の直後はストリーム名を、括弧内はスキーマを示
している。スキーマの、“，”に区切られた個々の記述は、カラムの名称と型の組合せを
示している。
【００５２】
６０１は、音声特徴量データストリーム１５００（ｖｏｉｃｅ）に入るストリームタプ
ルの例を示している。本例では、１０ミリ秒毎に、４つのマイクから、センサＩＤ（ｉｄ
カラム）と音量（ｅｎｅｒｇｙカラム）を組み合わせたストリームタプルが生成される様
子を示している。
【００５３】
次に、図７を用いて、音源選択処理１００Ａの基本処理単位７１０、７２０、７３０の
実現方法を開示する。
【００５４】
コマンド７００を、クエリ登録インタフェース２０２を介して、ストリームデータ処理
部１００に投入することで、基本処理単位７１０、７２０、７３０を実現する実行木が生
成される。コマンド７００は、３つのクエリ登録書式７１０、７２０、７３０に分けられ
、それぞれ、基本処理単位７１０、７２０、７３０の処理内容を定義する（以下同様に、
基本処理単位と、その処理内容を定義するクエリの登録書式を、同義として扱い、同一の
番号で示す。また、クエリ登録書式を、単にクエリと呼ぶ）。
【００５５】
クエリ７１０は、１０ミリ秒ごとの各時刻において、最大の音量を記録するマイク２０
を選択する。まず好適には、各マイクの音量に、定数の補正値を加算する。会議卓に取り
付けられた各マイクの感度は、会議卓の形状、材質、壁に対する位置関係、マイク自体の
品質、など様々な要因により、バラつきを持つため、該加算処理により、マイクの感度を
均等化する。マイク毎に異なる補正値は、音量補正値ストリーム１５０１（ｏｆｆｓｅｔ
）として参加者登録インタフェース２０１より登録される。図１のストリーム５８は、音
量補正値ストリームの例である（センサＩＤカラム５８Ｓ、および補正値カラム５８Ｖが
、それぞれ音量補正値ストリーム１５０１のｉｄカラム、およびｖａｌｕｅカラムを示す
）。音声データストリーム１５００と、音量補正値ストリーム１５０１とを、ｉｄカラム
に関する結合演算により結合し、ストリーム１５００の音量カラム（ｅｎｅｒｇｙ）の値
に、ストリーム１５０１の補正値カラム（ｖａｌｕｅ）の値を加算し、この値を改めてｅ
ｎｅｒｇｙカラムとする。該ｅｎｅｒｇｙカラムと、ｉｄカラムとを組み合わせたタプル
から成る、ストリームを、ｖｏｉｃｅ＿ｒとする。ストリーム６０１とストリーム５８に
対する、このクエリの結果をストリーム６０１Ｒに示す。
【００５６】
該ストリームｖｏｉｃｅ＿ｒから、集計演算“ＭＡＸ（ｅｎｅｒｇｙ）”によって最大
音量を算出し、その値と同じ音量のタプルを、ｅｎｅｒｇｙカラムに関する結合演算によ
り抽出する。ストリーム６０１Ｒに対するこのクエリの結果（ｖｏｉｃｅ＿ｍａｘ＿ｓｅ
ｔ）を、リレーション７１１に示す（クエリ７１０ではＮＯＷウィンドウを用いており、
リレーション７１１の各タプルの生存期間は非常に短いため、点で図示する。以下、ＮＯ
Ｗウィンドウによって定義されるタプルの生存期間は点で示す。なお、本クエリに関して
は、ＮＯＷウィンドウの代わりに、１０ミリ秒未満の時間ウィンドウを用いても構わない
）。
【００５７】
同時刻に最大音量を記録するマイクが２つ以上存在する場合もある。これに対し、クエ
リ７２０は、クエリ７１０の結果から、センサＩＤが最小のマイクのデータのみを選択す
ることで、マイクを一つに絞り込む。まず、集計演算“ＭＩＮ（ｉｄ）”によって最小Ｉ
Ｄを算出し、その値と同じＩＤのタプルを、ｉｄカラムに関する結合演算により抽出する
。リレーション７１１に対するこのクエリの結果（ｖｏｉｃｅ＿ｍａｘ）を、リレーショ
ン７２１に示す。
【００５８】
クエリ７３０は、クエリ７２０の結果から、閾値を超えるデータのみを音源として残す
。また、センサＩＤを参加者データ５３と付き合わせて、参加者名に変換する。まず、ｅ
ｎｅｒｇｙカラムに関して範囲選択（＞１．０）をかけ、ｉｄカラムに関する結合演算と
ｎａｍｅカラムの射影演算で、音源となる発話者名のストリームを生成する。リレーショ
ン７２１に対するこのクエリの結果（ｖｏｉｃｅ＿ｏｖｅｒ＿ｔｈｒｅｓｈｏｌｄ）を、
ストリーム７３１に示す。以上で、音源選択１００Ａの処理が完了する。
【００５９】
次に、図８を用いて、スムージング処理１００Ｂの基本処理単位８１０、８２０、８３
０、８４０、８５０の実現方法を開示する。
【００６０】
コマンド８００を、クエリ登録インタフェース２０２を介して、ストリームデータ処理
部１００に投入することで、基本処理単位８１０、８２０、８３０、８４０、８５０を実
現する実行木が生成される。
【００６１】
クエリ８１０は、クエリ７３０で得られた音源データにおける、同一発言者の連続する
音源断片について、間欠部分を補完し、平滑化された発言期間を抽出する。まず、ウィン
ドウ演算“［ＲＡＮＧＥ ２０ ｍｓｅｃ］”によって、ストリーム７３１上の各タプル
に２０ミリ秒の生存期間を与え、“ＤＩＳＴＩＮＣＴ”（重複排除演算）によって、同一
発言者のタプル重複を排除する。ストリーム７３１に対するこのクエリの結果（ｖｏｉｃ
ｅ＿ｆｒａｇｍｅｎｔ）を、リレーション８１１に示す。リレーション８１２は、該結果
に至る中間状態であり、ストリーム７３１上の、ｎａｍｅカラムの値が“Ｂ”であるタプ
ルについて、ウィンドウ演算で生存期間を定義した結果である。ストリーム７３１上では
、９時２分５．０３秒、５．０５秒、および５．０７秒において、ｎａｍｅカラムＢのタ
プルが抜けているが、リレーション８１２では、２０ミリ秒の生存期間によって補完され
る。一方、９時２分５．０８秒と５．０９秒のようにデータが連続する箇所では、生存期
間の重複が発生するが、ＤＩＳＴＩＮＣＴによって排除される。その結果、ｎａｍｅカラ
ムＢのタプルは、生存期間が９時２分５．０２秒から５．１１秒までの、一本のタプル８
１３に平滑化される。ｎａｍｅカラムＡ、Ｄのタプルのように、散発的に現れるタプルに
ついては、タプル８１４、８１５、８１６のように、２０ミリ秒の生存期間が定義された
タプルが散在する結果となる。
【００６２】
クエリ８２０は、クエリ８１０の結果から、持続時間が非常に短い瞬間的な発言（期間
）を、ノイズとして除去する。まず、リレーション８１１の各タプルについて、ストリー
ム化演算“ＩＳＴＲＥＡＭ”とウィンドウ演算“［ＲＡＮＧＥ ５０ ｍｓｅｃ］”によ
って、タプルの開始時刻から５０ミリ秒の生存期間を持つコピー（ｎａｍｅカラムの値が
、元のタプルと同一のタプル）を生成し、差集合演算“ＥＸＣＥＰＴ”によって、リレー
ション８１１から差し引くことで、生存期間が５０ミリ秒以下のタプルを除去する。リレ
ーション８１１に対するこのクエリの結果（ｓｐｅｅｃｈ）を、リレーション８２１に示
す。リレーション８２２は、該結果に至る中間状態であり、リレーション８１１上の各タ
プルについて、生存期間５０ミリ秒のコピーを作成した結果である。リレーション８１１
と８２２の差集合を取ると、タプル８１４、８１５、８１６は、タプル８２４、８２５、
８２６によって完全に消去される。一方、タプル８１３については、タプル８２３の生存
期間を差引かれて、９時２分５．０７秒から９時２分５．１１秒までの生存期間を持つタ
プル８２７が残る。このように、生存期間が５０ミリ秒以下のタプルは全て除去され、そ
れ以上の生存期間を持つタプルのみが、実際の発言データとして残る。
【００６３】
クエリ８３０、８４０、および８５０は、クエリ８２０の結果から、ストリーム化演算
ＩＳｔｒｅａｍ、ＤＳｔｒｅａｍ、およびＲＳｔｒｅａｍによって、それぞれ、発言の開
始時刻、終了時刻、および発言中の時刻をタイムスタンプとする、ストリームタプルを生
成する。リレーション８２１に対する、各クエリの結果（ｓｔａｒｔ＿ｓｐｅｅｃｈ、ｓ
ｔｏｐ＿ｓｐｅｅｃｈ、およびｏｎ＿ｓｐｅｅｃｈ）を、それぞれストリーム８３１、８
４１、８５１に示す。以上で、スムージング処理１００Ｂが完了する。
【００６４】
次に、図９を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位９１０、９
２０、９３０、９４０の実現方法を開示する。コマンド９００を、クエリ登録インタフェ
ース２０２を介して、ストリームデータ処理１００に投入することで、基本処理単位９１
０、９２０、９３０、９４０を実現する実行木が生成される。
【００６５】
クエリ９１０は、クエリ８３０の結果から、会議中の累積発言回数をカウントする。ま
ず、ウィンドウ演算“［ＲＯＷＳ １］”によって、発言開始タプルが発生する度にｎａ
ｍｅカラムの値が切替るリレーションを生成する。但し、同一発言者の発言開始タプルが
連続する場合には、リレーションは切替らない。このリレーションをストリーム化演算“
ＩＳＴＲＥＡＭ”でストリーム化することで、発言者に変化があった際の、発言開始時刻
を切り出す。さらに、該ストリームをウィンドウ演算“［ＵＮＢＯＵＮＤＥＤ］”で永続
化し、ｎａｍｅカラムでグルーピングして、集計演算“ＣＯＵＮＴ”でカウントすること
によって、発言者ごとの累積発話回数を算出する。
【００６６】
ｓｐｅｅｃｈリレーション９０１に対するこのクエリの結果（ｓｐｅｅｃｈ＿ｃｏｕｎ
ｔ）を、リレーション９１１に示す。ストリーム９１２は、リレーション９０１に対する
クエリ８３０の結果（ｓｔａｒｔ＿ｓｐｅｅｃｈ）である。リレーション９１３は、スト
リーム９１２を［ＲＯＷＳ １］のウィンドウ演算で処理した結果である。ストリーム９
１４は、リレーション９１３をＩＳｔｒｅａｍでストリーム化した結果である。このとき
、タプル９１５の開始時刻に対して、ストリームタプル９１７が生成されるが、タプル９
１５と９１６は、同一発言者“Ｂ”のリレーションであり、タプル９１５の終点とタプル
９１６の始点は同一時刻（９時１８分１５秒）になるため、９時１８分１５秒のタプルは
生成されない。ストリーム９１４を、ｎａｍｅでグルーピングして永続化してカウントし
た結果が、リレーション９１１となる。永続化したリレーションをカウントするので、ス
トリーム９１４にタプルが発生する度に、発言数が累積される。
【００６７】
クエリ９２０は、クエリ８５０の結果から、過去５分間における発言者ごとの発言時間
を算出する。まず、ｏｎ＿ｓｐｅｅｃｈストリームの各タプルに対し、ウィンドウ演算“
［ＲＡＮＧＥ ５ ｍｉｎ］”で、５分間の生存期間を定義し、ｎａｍｅカラムでグルー
ピングして、集計演算“ＣＯＵＮＴ”によってカウントする。この処理は、過去５分間に
おいて、ｏｎ＿ｓｐｅｅｃｈストリーム上に存在したタプルの個数を数えることに相当す
る。なお、ｏｎ＿ｓｐｅｅｃｈストリームタプルは、秒間１００個のレートで生成される
ため、ＳＥＬＥＣＴ句でこの個数を１００で割って、秒単位の発言時間を算出する。
【００６８】
クエリ９３０は、クエリ８３０および８４０の結果から、ある発言の終了後３秒以内に
、別の発言者の発言が開始されたケースを、二者間の会話として抽出する。まず、ｓｔｏ
ｐ＿ｓｐｅｅｃｈストリームとｓｔａｒｔ＿ｓｐｅｅｃｈストリームの各タプルに対し、
それぞれウィンドウ演算“［ＲＡＮＧＥ ３ ｓｅｃ］”と“［ＮＯＷ］”で、生存期間
を定義し、ｎａｍｅカラムに関する結合演算（一致しないことを条件とする）により、ｓ
ｔｏｐ＿ｓｐｅｅｃｈタプル発生の３秒以内に、ｓｔａｒｔ＿ｓｐｅｅｃｈタプルが発生
する組合せを抽出する。結果は、ｓｔｏｐ＿ｓｐｅｅｃｈ．ｎａｍｅをｐｒｅカラムに、
ｓｔａｒｔ＿ｓｐｅｅｃｈ．ｎａｍｅをｐｏｓｔカラムに射影して出力する。ｓｐｅｅｃ
ｈリレーション９０１に対するこのクエリの結果（ｓｐｅｅｃｈ＿ｓｅｑｕｅｎｃｅ）を
、ストリーム９３１に示す。ストリーム９３２は、リレーション９０１に対するクエリ８
４０の結果（ｓｔｏｐ＿ｓｐｅｅｃｈ）であり、リレーション９３３は、ストリーム９３
２の各タプルに３秒間の生存期間を定義した中間状態である。また、ストリーム９１２を
ＮＯＷウィンドウでリレーションに変換した結果は、９１２と同一の図になる。該リレー
ションと、リレーション９３３の結合演算の結果を、さらにＩＳｔｒｅａｍでストリーム
化した結果が、ストリーム９３１となる。
【００６９】
クエリ９４０は、クエリ９３０の結果から、会議中の累積会話回数を、二者の組合せ別
にカウントする。まず、ウィンドウ演算“［ＵＮＢＯＵＮＤＥＤ］”で永続化し、“Ｇｒ
ｏｕｐ ｂｙ ｐｒｅ，ｐｏｓｔ”で、ｐｒｅカラムとｐｏｓｔカラムの組合せ別にグル
ーピングし、集計演算“ＣＯＵＮＴ”によってカウントする。永続化したリレーションを
カウントするので、ストリーム９３１にタプルが発生する度に、会話数が累積される。
【００７０】
次に、図１０を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位１０００
、１０１０、１０２０の実現方法を開示する。クエリ１０００、１０１０、および１０２
０を、クエリ登録インタフェース２０２を介して、ストリームデータ処理部１００に投入
することで、それぞれ、基本処理単位１０００、１０１０、および１０２０を実現する実
行木が生成される。これら３種のクエリは、全て会議の盛り上り度を算出する。但し、盛
り上り度の定義は各クエリで異なる。
【００７１】
クエリ１０００は、ストリーム１５００（ｖｏｉｃｅ）の全マイクの音量値を、過去３
０秒間累積した値として、盛り上り度を算出する。本クエリは、ウィンドウ演算“［ＲＡ
ＮＧＥ ３０ ｓｅｃ］”と、集計演算“ＳＵＭ（ｅｎｅｒｇｙ）”により、過去３０秒
間におけるストリーム１５００上のタプルのｅｎｅｒｇｙカラム値の和を計算する。また
、ストリーム化演算“ＲＳＴＲＥＡＭ［３ ｓｅｃ］”によって、結果の出力を３秒間隔
としている（以下、クエリ１０１０、１０２０についても同様）。以上、クエリ１０００
では、会議出席者の発言エネルギーの総和を、盛り上り度の指標としている。
【００７２】
クエリ１０１０は、過去３０秒間における、発言者数と会話回数の積として、盛り上り
度を算出する。この盛り上り度は先に説明した単位時間当たりの発言総回数と発言者総数
の積から算出する議論活性化度５４の一具体例となる。クエリ１０１１は、ストリーム１
５１４（ｓｐｅｅｃｈ＿ｓｅｑｕｅｎｃｅ）の、過去３０秒間のタプルをカウントする。
該クエリの結果のリレーション名をｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔとす
る。クエリ１０１２は、ストリーム１５１１（ｓｔａｒｔ＿ｓｐｅｅｃｈ）の、過去３０
秒間のタプルをカウントする。該クエリの結果のリレーション名をｒｅｃｅｎｔ＿ｓｐｅ
ａｋｅｒｓ＿ｃｏｕｎｔとする。クエリ１０１３は、両者の積を算出する。ｒｅｃｅｎｔ
＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔとｒｅｃｅｎｔ＿ｓｐｅａｋｅｒｓ＿ｃｏｕｎｔのど
ちらのリレーションにおいても、自然数の値を持つｃｎｔカラムのみから成るタプルが、
常に丁度一つ生存することになる。従って、両者の積を取った結果も、常に丁度一つのタ
プルが生存するリレーションとなる。
【００７３】
但し、この積を単純に“ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ ＊
ｒｅｃｅｎｔ＿ｓｐｅａｋｅｒｓ＿ｃｏｕｎｔ．ｃｎｔ”で計算すると、一人の発言者
が長時間話している期間では、会話数が０になるので、結果も０となってしまう。これを
回避するため、“ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ”の代わりに
、“（ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ ＋１／（１＋ｒｅｃｅ
ｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ））”を利用する。“＋”以降の、“＋
１／（１＋ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ）”の部分は、整数
の商であるため、ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔが０の場合に
＋１、０より大きい場合に＋０となる。その結果、誰も発言者が居ない沈黙の期間は盛り
上り度が０、一人の発言者が長時間話している期間は１、二人以上の発言者がいる期間は
発言者数と会話数の積となる。以上、クエリ１０１０では、会議出席者の中で議論に参加
している人数が多いこと、および、意見の交換が頻繁であることを、盛り上がり度の指標
としている。
【００７４】
クエリ１０２０は、発言者の身振りの強度として、盛り上り度を算出する。クエリ１０
２１は、身振りの瞬間強度を表すストリーム１５０３（ｍｏｔｉｏｎ）をＮＯＷウィンド
ウで処理した結果のリレーションと、発言者の発言期間を表すリレーション１５１０（ｓ
ｐｅｅｃｈ）とを、ｎａｍｅカラムに関する結合演算にかけることで、発言中の出席者に
ついて身振り強度を抽出する。クエリ１０２２は、過去３０秒間における、発言者の身振
り強度を累積する。以上、クエリ１０２０では、発言者の身振りの強弱が、議論の白熱度
を反映すると仮定し、盛り上り度の指標としている。
【００７５】
ここで示した盛り上り度の定義は一例であり、会議の盛り上り度の数値化は、確立した
定義のない、人間の主観に関わるデータであるため、試行を繰返し的確な定義を探索する
必要がある。新しい定義を試行する度に、算出ロジックを、Ｃ、Ｃ＃、Ｊａｖａ（登録商
標）などの手続き型言語でコーディングするのでは、開発工数が甚大である。特に、クエ
リ１０１０のような、発言間の順序関係に基づいた指標を算出するロジックは、コードが
複雑化し、デバグも困難となる。これに対し、議論活性化度などを例示して説明した本実
施例のように、ストリームデータ処理を利用することで、簡潔な宣言型クエリによる定義
が可能となるため、このような工数を大幅に軽減する。
【００７６】
次に、図１３を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位１３１０
、１３２０、１３３０の実現方法を開示する。
【００７７】
コマンド１３００を、クエリ登録インタフェース２０２を介して、ストリームデータ処
理１００に投入することで、基本処理単位１３１０、１３２０、１３３０を実現する実行
木が生成される。
【００７８】
多くの出席者から賛同を得た発言は、会議中の重要発言であると捉える。このような発
言を抽出するために、クエリ１３１０は、リレーション１５１０（ｓｐｅｅｃｈ）と、う
なずき状態を表すストリーム１５０４（ｎｏｄ）から、発言者の意見が多数の出席者に賛
同されている（＝うなずかれている）状態を抽出する。うなずき状態の検出は、名札型セ
ンサノード７０が備える加速度センサ７４１で計測する加速度値より、パターン認識技術
を利用して、実現することが可能である。本実施例では、１秒間隔で、その時刻において
出席者がうなずき動作中である場合に、該出席者名をｎａｍｅカラムに示すタプルが発生
する、と仮定する。まず、ストリーム１５０４上の各タプルに対し、ウィンドウ演算“［
ＲＡＮＧＥ １ ｓｅｃ］”によって１秒の生存期間を定義することで、出席者ごとのう
なずき期間を表すリレーションが得られる（例：リレーション１３０２）。
【００７９】
該リレーションと、発言期間を表すリレーション１５１０（例：リレーション１３０１
）を、ｎａｍｅカラムに関する結合演算（一致しないことを条件とする）にかけることで
、発言者以外の出席者がうなずいている期間を、タプルの生存期間とするリレーション（
例：リレーション１３１２）が得られる。該リレーションにおいて、生存タプルが２個以
上ある（＝２人以上の出席者が、うなずきながら聞いている）期間を、ＨＡＶＩＮＧ句に
よって抽出する。このとき、射影演算によって、発言者の名前（ｓｐｅｅｃｈ．ｎａｍｅ
カラム）と、定数文字列’ｙｅｓ’の値を持つｆｌａｇカラムから成るタプルを出力する
（例：リレーション１３１３）。この結果をＩＳｔｒｅａｍでストリーム化し、クエリ１
３１０の結果を得る（例：ストリーム１３１１）。ストリーム１３１１は、発言者Ｂの発
言が、他の出席者ＣとＤの二人にうなずかれたタイミングで、タプルが発生する様子を示
している。
【００８０】
クエリ１３１０によって、重要発言の発生を抽出する一方、発言の内容は、ストリーム
１５０５（ｓｔａｔｅｍｅｎｔ）としてＰＣ１０から入力される。発言内容は議事録係の
キーストロークから抽出されるため、音声解析と加速度解析から自動抽出した重要発言の
発生タイミングに対し、数十秒遅れて入力されることになる。これに対し、クエリ１３２
０、およびクエリ１３３０は、ある発言者の重要発言が検出された後、最初に入力された
該発言者の発言内容に、重要発言のフラグを立てる処理である。
【００８１】
クエリ１３２０は、発言者ごとに、発言重要度を表すフラグを保持するトグルスイッチ
の役目を果たす。該クエリの結果リレーションａｃｃｅｐｔａｎｃｅ＿ｔｏｇｇｌｅは、
次にストリーム１５０５（ｓｔａｔｅｍｅｎｔ）から入力される発言内容が、重要発言と
なるか否かを、発言者ごとに表している（例：リレーション１３２１）。ｎａｍｅカラム
は発言者名を示し、ｆｌａｇカラムは、’ｙｅｓ’／’ｎｏ’によって重要性を示してい
る。クエリ１３３０は、ストリーム１５０５をＮＯＷウィンドウでリレーション化した結
果と、クエリ１３２０の結果リレーションを、ｎａｍｅカラムに関する結合演算で処理し
、発言内容に重要性の指標を付加して出力する（例：ストリーム１３３１）。
【００８２】
クエリ１３２０では、まず、ストリーム１５０５から発言内容の入力があった際に、そ
の発言者に関する重要度のフラグを’ｎｏ’にクリアするタプルを生成する。但し、該タ
プルのタイムスタンプは、元となる発言内容タプルのタイムスタンプから、若干時刻を遅
らせる。この処理を、“ＤＳＴＲＥＡＭ（ｓｔａｔａｍｅｎｔ［ＲＡＮＧＥ １ ｍｓｅ
ｃ］）”の記述によって定義している。例として、ｓｔａｔｅｍｅｎｔストリーム１３０
３上のストリームタプル１３０４が入力されると、そこから１ ｍｓｅｃ分タイムスタン
プのずれたストリームタプル１３２４が、中間状態ストリーム１３２２上に発生する。こ
のような’ｎｏ’タプルのストリームと、クエリ１３１０の結果を、和集合演算“ＵＮＩ
ＯＮ ＡＬＬ”でマージする。例として、該ストリーム１３２２と、ストリーム１３１１
のマージ結果が、ストリーム１３２３となる。このストリームを、ウィンドウ演算“ＰＡ
ＲＴＩＴＩＯＮ ＢＹ ｎａｍｅ ＲＯＷＳ １］”でリレーション化する。このウィン
ドウ演算は、ｎａｍｅカラムの値に基づいて分けた各グループを、同時生存数１個の個数
ウィンドウでリレーション化する。これにより、各発言者別に、重要度’ｙｅｓ’か’ｎ
ｏ’どちらか一方のフラグが立つことになる。例として、ストリーム１３２３をリレーシ
ョン化した結果が、リレーション１３２１となる。ここで、’ｎｏ’タプルのタイムスタ
ンプを若干ずらす理由は、クエリ１３３０において、’ｎｏ’タプルと、その元となるｓ
ｔａｔｅｍｅｎｔタプル自身が、結合するのを避けるためである。以上で、アクティビテ
ィデータ生成１００Ｃの処理が完了する。
【００８３】
続いて、アクティビティデータ生成１００Ｃによって得られたアクティビティデータに
基づいて、表示処理部２０３、即ち集計処理サーバ２００の処理部（ＣＰＵ）で実行され
る描画処理プログラムによって得られる画面イメージを図１６、１７を用いて説明する。
【００８４】
図１６は、発言者の動きに基づいたアクティビティデータ１５２０を、動きの活性度３
１１Ｍとして、活性度・発言表示３１０Ａに反映した画面イメージである。本画面により
、会議内での活動について、単なる音声だけではなくメンバの行動面を併せて可視化する
ことができる。
【００８５】
また、図１７は、うなずきによる発言の重要度を示すアクティビティデータ１５２１を
、重要発言指標３１１ａとして、活性度・発言表示３１０Ｂに反映した画面イメージであ
る。メンバの発言３１３と重要発言指標３１１ａとをリンクさせて表示することにより、
どの発言が参加メンバの納得感を得たものなのかを可視化することができる。このように
、本画面により、単なる音声だけではなく、メンバの納得度を併せて会議状況を可視化す
ることができる。
【００８６】
さて図１４は、図２で示した機能モジュールでの処理シーケンスの別の実施例を示した
ものである。本実施例における処理シーケンスでは、音声処理部４２において、特徴量デ
ータを取得した後、音声処理サーバ４０において、音声／非音声判別処理、スムージング
処理、及び音源選択処理を実行する。好適には、これらの処理も、音声処理サーバ４０の
図示されない処理部（ＣＰＵ）のプログラム処理として実行される。
【００８７】
図１４において、図２同様、センサ（マイク）２０では音声データが取得される（２０
Ａ）。次に、サウンドボード４１にて、音声のサンプリング処理が行なわれる（４１Ａ）
。次に音声処理部４２にて、特徴量の抽出（エネルギーへの変換）が行なわれる（４２Ａ
）。エネルギーは数ミリ秒の音波形の絶対値の２乗を全範囲に渡って積分したものである
。
【００８８】
本実施例においては、音声処理サーバ４０の音声処理４２として、特徴量抽出（４２Ａ
）から取得した特徴量データをもとに、音声／非音声の識別を行なう（４２Ｂ）。音声／
非音声の識別方法として、数秒時間におけるエネルギーの変化度合いによる識別があげら
れる。音声には特有の音波形エネルギーの強弱とその変化パターンがあり、それらを用い
ることで音声と非音声の識別を行なう。
【００８９】
また、数秒単位の音声/非音声識別結果をそのまま用いると、数１０秒からなる意味の
かたまりとしての1発話単位の区間を求めることが難しい。そこで、スムージング処理（
４２Ｃ）を導入することにより、１発話単位の区間を求め，これを音源選択に使用する。
【００９０】
上述の部分は音声処理４２で、センサ（マイク）２０毎に行なう処理であり、最終的に
どのセンサ（マイク）２０から音声が入力されたかを判断する必要がある。そこで本実施
例においては、音声処理４２において、スムージング処理（４２Ｃ）に引続き音源選択４
２Ｄを行ない、センサ（マイク）２０の中から実際に発話されたセンサ（マイク）２０を
選択する。一番近くのセンサ（マイク）２０に届く音声は、その他のセンサ（マイク）２
０より音声と判断される区間が長い。よって、本実施例においては、それぞれのセンサ（
マイク）２０のスムージング処理４２Ｃの結果から一番長かったセンサ（マイク）２０を
音源選択４２Ｄの出力とした。次に、ストリームデータ処理部１００にて、アクティビテ
ィデータ生成（１００Ｃ）が行なわれ、最後に、表示処理部２０３にて、アクティビティ
データＡＤに基づいた、画面データ生成（２０３Ａ）が行なわれることは先に説明した通
りである。
【符号の説明】
【００９１】
１０…ＰＣ、２０…センサ（マイク）、３０…会議卓、４０…音声処理サーバ、１００
…ストリームデータ処理部、２００…集計処理サーバ、３００…モニタ画面、３１０…会
議活性度・発言内容表示、３２０…発言累積表示、３３０…発言シーケンス表示。
【特許請求の範囲】
【請求項１】
複数の参加者間での対話状況を分析する会議分析システムであって、
前記参加者が装着することで、前記参加者の身体の動きの大きさを加速度センサによって検出して記録する名札型センサノードと、
対話内容を手入力によって記録するためのキーストローク情報入力ユニットと、
前記身体の動きのデータと前記対話内容との対応付けを行うデータストリーム処理ユニットと、を備え、
前記データストリーム処理ユニットは、時間毎に、前記身体の動きのデータによって前記対話内容の重要性を判定する
ことを特徴とする会議分析システム。
【請求項２】
請求項１に記載の会議分析システムであって、
前記データストリーム処理ユニットは、前記身体の動きのデータより、前記参加者のうなずきの有無を推定し、推定された前記うなずきの量によって、前記対話内容の重要性を判定する
ことを特徴とする会議分析システム。
【請求項３】
請求項1に記載の会議分析システムであって、
前記参加者に対応する複数の音声データを取得する音声データ取得ユニットを更に備え、
前記データストリーム処理ユニットは、時間毎に、前記身体の動きのデータによって、前記音声データの重要性を判定する
ことを特徴とする会議分析システム。
【請求項４】
請求項３に記載の会議分析システムであって、
前記データストリーム処理ユニットは、前記身体の動きのデータより、前記参加者のうなずきの有無を推定し、推定された前記うなずきの量によって、前記音声データ、および前記対話内容の重要性を判定する
ことを特徴とする会議分析システム。
【請求項１】
複数の参加者間での対話状況を分析する会議分析システムであって、
前記参加者が装着することで、前記参加者の身体の動きの大きさを加速度センサによって検出して記録する名札型センサノードと、
対話内容を手入力によって記録するためのキーストローク情報入力ユニットと、
前記身体の動きのデータと前記対話内容との対応付けを行うデータストリーム処理ユニットと、を備え、
前記データストリーム処理ユニットは、時間毎に、前記身体の動きのデータによって前記対話内容の重要性を判定する
ことを特徴とする会議分析システム。
【請求項２】
請求項１に記載の会議分析システムであって、
前記データストリーム処理ユニットは、前記身体の動きのデータより、前記参加者のうなずきの有無を推定し、推定された前記うなずきの量によって、前記対話内容の重要性を判定する
ことを特徴とする会議分析システム。
【請求項３】
請求項1に記載の会議分析システムであって、
前記参加者に対応する複数の音声データを取得する音声データ取得ユニットを更に備え、
前記データストリーム処理ユニットは、時間毎に、前記身体の動きのデータによって、前記音声データの重要性を判定する
ことを特徴とする会議分析システム。
【請求項４】
請求項３に記載の会議分析システムであって、
前記データストリーム処理ユニットは、前記身体の動きのデータより、前記参加者のうなずきの有無を推定し、推定された前記うなずきの量によって、前記音声データ、および前記対話内容の重要性を判定する
ことを特徴とする会議分析システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１３−５８２２１（Ｐ２０１３−５８２２１Ａ）
【公開日】平成２５年３月２８日（２０１３．３．２８）
【国際特許分類】
【出願番号】特願２０１２−２３０３８１（Ｐ２０１２−２３０３８１）
【出願日】平成２４年１０月１８日（２０１２．１０．１８）
【分割の表示】特願２００７−１０５００４（Ｐ２００７−１０５００４）の分割
【原出願日】平成１９年４月１２日（２００７．４．１２）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２５年３月２８日（２０１３．３．２８）
【国際特許分類】
【出願日】平成２４年１０月１８日（２０１２．１０．１８）
【分割の表示】特願２００７−１０５００４（Ｐ２００７−１０５００４）の分割
【原出願日】平成１９年４月１２日（２００７．４．１２）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]