Vol. 41No. 10情報処理学会論文誌Oct. 2000
研究会推薦論文
Web 対話チャネルと電話対話チャネル間の連携を図るWeb-CTI 統合システム
湯本一磨†星徹†中山良幸†
高橋亨††東潔司†††
インターネット利用者数の増加にともない，インターネットはユーザと企業とを結ぶ新たなチャネルとなってきた．従来，一方向の情報提供形態が主流であった WWW の世界に，電話のような対人対話機能を持ちこむことは，電子メールやフォーム送信機能では享受できなかったリアルタイム性と，有人対応による安心感とをユーザにもたらす．本稿では，WWW システムと CTI（ComputerTelephony Integration）システムの機能連携を実現する Web-CTI 統合システムを提案する．各々が異なるネットワーク上で実現され，独立のシステムとして発展してきた WWW と CTI の連携手法として，呼分配方式，セッション管理方式，HTTP ベースでの話者間の情報同期方式について述べる．
A Web Based CTI System Combining Web CommunicationChannel and Telephony Channel
Kazuma Yumoto,† Tohru Hoshi,† Yoshiyuki Nakayama,†Tohru Takahashi†† and Kiyoshi Higashi†††
Due to the increase of the number of the Internet users, the Internet becomes a new in-formation channel between customers and enterprises. However, World Wide Web (WWW)provide only one way communication, and WWW systems and CTI (computer and telephonyintegration) systems have been realized on diﬀerent networks. We propose an integrative sys-tem of WWW and CTI. Integrating the telephony function into WWW can provide real-timeand bidirectional communication for customers. The technologies, which integrate WWWand CTI, are call distribution, session management, page synchronization on browsers andTele-pointing over synchronized web pages.
1.は じ め に
インターネット利用者数の増加により，インターネッ
トはユーザと企業とを結ぶ新たなチャネルとして注
目されている．CRM（Customer Relationship Man-agement）の整備などを契機として，CTI（ComputerTelephony Integration）の導入が進んでいるコールセ
ンタやヘルプデスクでも，従来の電話に加え，新たに
インターネット経由での対話チャネルを整備すること
は重要になりつつある1)．
† 株式会社日立製作所システム開発研究所System Development Laboratory, Hitachi, Ltd.†† 株式会社日立インフォメーションテクノロジーHitachi Information Technology, Ltd.††† 株式会社日立西部ソフトウェアHitachi Seibu Software, Ltd.
一方，EC（Electronic Commerce）による取引に
二の足を踏んでいるユーザは，クレジット番号などの
個人情報の漏洩を懸念したセキュリティ面での不安と
ともに，商品に対する質問や決済を行うにあたり，オ
ペレータなどと直接話をする仕組みが提供されていな
いことに対するユーザサポート面での不満を抱えてい
る．World Wide Web（以降 WWW または Web と
記載）と CTI（電話）との連携は，このような不満を
解消する手段として有効である．
しかしながら，異なるネットワーク環境でシステム
が構築されている WWW と電話（CTI）の連携を図
るには，相互のシステム間をインターワークする仕組
みが必要になる．たとえば，Web 対話チャネルと電話
本論文の内容は 2000 年 1 月のグループウェア研究会にて報告され，同研究会主査 により情報処理学会論文誌への掲載が推薦された論文である．
Vol. 41No. 10Web-CTI 統合システム2753
対話チャネルのような複数の対話チャネルをコールセ
ンタでサポートする場合には，それぞれの対話チャネ
ルより発生するオペレータ接続要求に対し，オペレー
タ割当てに衝突が生じないようにしなければならない．
また，複数の対話チャネルを同時に利用する場合には，
双方を同一の対話として管理しなければならない．
本稿では，このような課題を解決する手段として，
各対話チャネルからの接続要求に対し，オペレータへ
の呼分配を統一的に扱う仕組みと，複数の対話チャネ
ルを同時に利用する場合のセッション管理手法とを提
案する．具体的には，ブラウザで Web ページを参照
している状態から電話の接続要求を行う Web コール
または Web コールバックと呼ばれる機能と，参照す
る Web ページを話者間で同期させてブラウジングす
る URL 2)同期機能と，同システム上におけるテレラ
イティング機能の実現方式を提案する．
2.コンタクト手段としての対話チャネル
従来，ユーザ（顧客）が不明点などの問合せを行う
際には，次にあげるようなコンタクト手段が用いられ
［リアルタイム型］
• サービスセンタに赴く• 電話• チャット
［蓄積型］• 手紙
• FAX• 電子メール
サービスセンタなどに赴くことは，対面による対話
が実現され，問題解決を行うには最適であるが，時間
と労力を要する手段である．これに対し電話は，時間
と労力の問題を解決するが，言葉だけによる意思伝達
の限界という問題に直面する場合がある．図などを用
いることが可能な意思伝達手段としては手紙や FAX
があるが，電話とは逆に，即時性・即応性に欠けると
いう欠点がある．インターネットの普及にともない広
く活用されるようになってきたチャットや電子メール
といった手段も，言葉だけによる意思伝達の限界とい
う問題や，電子メールによる問合せの殺到に対応が追
い付かないという処理負荷の問題を抱えている．
一方，WWW の普及にともない，トラブルシュー
ティングや Q&A 情報などを WWWで提供し，ユーザ
による問題の自己解決を促す仕組みも多く用いられる
ようになってきた．この場合，定型の項目選択やキー
ワード検索などによって，問題の自己解決を支援する
図 1問題解決の手段と連携プロセスFig. 1The means and their transition processes to solveproblems.
機能も追加されている．問題を解決できなかったユー
ザに対しては，同ページ上で問合せ先の電子メールア
ドレスをアナウンスしたり，フォーム入力による定型
の問合せ手段を設けるなどの方法でサポートを行って
いる．近年，汎用ブラウザの多くは，電子メールのア
プリケーション機能も包含し，相互に連携が図られて
いるため，Web ページを閲覧している状態から問合
せの電子メールを送信するという行為への推移は，容
易に実行できるようになっている．このように，従来
のコンタクト手段に加え近年では，WWW による問
題の自己解決の手段や，そこから蓄積型のコンタクト
手段を利用するプロセスなど，より多くの手段の整備
とプロセスの連携とが行われてきた．（図 1 のプロセ
ス (1) 参照）
ここで新たなプロセスとして，図 1 のプロセス (2)
に示すような，Web ページ閲覧状態から電話に代表
されるリアルタイム型のコンタクト手段を利用する
プロセスについて考える．プロセス (2) を実現する場
合，また，電話の問題点を補うために Web ページの
閲覧による視覚効果を同時に利用する場合には，回線
交換型の通信システムとして構築されている電話シス
テムと，パケット交換型の通信システムとして電話シ
ステムとは異なるネットワーク環境に構築されているWWW システムとの連携を図る新たな仕組みが必要
となる（課題 1）．
網側の IN（Intelligent Network）設備とユーザ側
CT（Computer Telephony）設備それぞれに装置を
導入して付加価値サービスを提供するインターワーキ
ング手法3)や，WWW 上に公開された行き先ボード
からユーザが最適な通信メディアを選択する手法4)に
関する研究はすでになされているが，作業の流れなど
からユーザ側が都合の良いコンタクト手段を選択した
場合のオペレータなどへの呼の分配手法や，複数の対
2754情報処理学会論文誌Oct. 2000
図 2インターネットコールセンターFig. 2Internet Call Center.
話チャネルを同時に用いる場合の対話チャネル間の連
携手法に関しては考慮されていない（課題 2）．一方，WWW を従来の自己解決手段としてだけではなく，他
者とコミュニケーションを図る際のコンタクト手段と
して用いることに関しては，Web ベースでの電子対
話システムの実現手法5)や，遠隔監視と操作代行の手
法6)，共同での文書作成手法7)などについて研究が行
われているが，専用モジュールをユーザ側環境に追加
する必要やネットワーク環境面での利用制限などが存
在する（課題 3）．
上記課題を解決し，新たなサービスを提供するシス
テムとして，本稿では Web-CTI 統合システムとその
実現手法を提案する．Web-CTI 統合システムでは，
Web 対話チャネルと電話対話チャネルとを連携し，汎
用ブラウザがあれば利用可能な Web 対話機能を実現
3.Web-CTI 統合システム
電話による対話（電話対話チャネル）に加え，WWW
を対話チャネルとして利用する具体例として，インター
ネットコールセンタの例を図 2 に示す．ここでは最終
的に，参照する Web ページを話者間で同期（URL 同
期）しながら，電話で会話を行うという対話形態を想
定する．3.1対話開始形態
電話と WWW という，異なるチャネルを同時利用
するに至るまでの過程として，次の 2 つが考えられる．( 1 )通話状態から URL 同期開始
第 1 の過程は，先に顧客側からコールセンタなどの窓
口に電話をかけ，オペレータと対話している状態から，
新たに両者で同一の情報画面をブラウザで参照する機
能を利用するような場合である．
( 2 )Web 参照状態から通話要求
第 2 の過程は，顧客が Web の情報を参照して，商品
の購入検討やトラブルの解決を図っている状態から，
直接オペレータに問合せを行おうとする際に，Web の
画面上から対話要求を発行して電話回線を接続する場
( 2 ) の形態は，電話接続形態としてさらに次の 3 通り
に細かく分類できる．
( a )Web コール( b )Web コールバック( c )オペレータ予約
(2a) はインターネット電話などを利用した Web 画面
からの直接ダイヤル．(2b) は Web 画面から対話要求
を発行した後，割り当てられたオペレータまたはコー
ルセンタ側から，コールバックされる形態．(2c) は先
に Web 画面からの対話要求によりオペレータの割当
て確保を行い，その後で顧客から電話をかけて，割当
て確保したオペレータと電話をつなげるというもので
ある．(2c) は，たとえば，先にオペレータと Web 上
のテキストチャットで対話を行っている状態から，電
話による対話に切り替える際に，テキストチャットで
対話を行っていたオペレータと電話をつなげるように
する場合が考えられる．または，ある指定時間の後に
顧客が電話する際，確実にオペレータを確保するとい
う場合などがある．
3.2課題( 1 )複合対話チャネルのオペレータ割当Web 対話チャネルと電話対話チャネルを複合活用す
る形態では，顧客とオペレータとの間で Web ページ
を同期参照（URL 同期）しながら電話で会話を行う．
この形態に至るプロセスには，電話で話をしている状
態から URL 同期を開始する場合と，顧客が Web を
Vol. 41No. 10Web-CTI 統合システム2755
図 3呼分配方式（1）Fig. 3Call dispatching method (1).
参照している状態からオペレータと接続して対話を開
始するという 2 つの場合がある．オペレータの割当て
（呼分配）処理は，両プロセスに対応しなければなら
ず，特に後者のプロセスでは，多様な呼の接続遷移処
理を行わなければならない．( 2 )URL 同期実現方式
コンピュータに精通していないユーザでも利用できる
ようにするためには，顧客側端末の設定変更を少なく
し，汎用的なブラウザで機能を実現するのが望ましい．
また，ファイヤウォール内にいる多くの企業ユーザか
らも利用できるようにするためには，通信プロトコル
として HTTP 8)を採用するのが望ましい．両要件を
満たす形での URL 同期の実現が課題であるが，特に，
投げたリクエストに対しレスポンスを受け取ると接続
が切れる HTTP プロトコルを用いて，いかに機能を
実現するかが課題となる．
4.システム構成および動作
4.1呼分配
対話チャネル種別を新たに追加する場合，オペレー
タ割当てのような呼分配（ACD: Automatic Call Dis-tribution）をどこで行うかということが課題となる．
複数の対話チャネル種別が存在する場合の呼分配方式
としては，次のような 3 つの方式が考えられる．
第 1 の方式を図 3 に示す．この方式は，各対話チャ
ネル種別ごとに専任のオペレータを割り当て，呼分
配も対話チャネル種別ごとに行う方式である．最も単
純な方式ではあるが，各対話チャネル種別ごとにオペ
レータを準備しなければならないため，人的資源の
活用という面では非効率である．また，同一話者間で
Web ページを同期参照しながら電話で対話を行うと
いうような連携は不可能になる．
第 2 の方式を図 4 に示す．この方式では，オペレー
タは全対話チャネル種別に対応する．一方，呼分配は
対話チャネル種別ごとに行い，オペレータの状態管理
情報を対話チャネル種別間で同期をとる．この方式で
は，人的資源の有効活用という面は改善されるが，オ
図 4呼分配方式（2）Fig. 4Call dispatching method (2).
図 5呼分配方式（3）Fig. 5Call dispatching method (3).
ペレータの状態管理情報の同期タイミングによっては，
呼分配の衝突を起こす可能性がある．また，同一話者
間で Web ページを同期参照しながら電話で対話を行
う場合には，各対話チャネル種別の呼分配で連携を図
る仕組みが必要となる．
第 3 の方式を図 5 に示す．この方式は第 2 の方式
同様，オペレータは全対話チャネル種別に対応する．
第 2 の方式との違いは，呼分配機能を CTI サーバに
一元化する点である．呼分配機能を一元化することに
より，第 2 の方式の問題点であった呼分配衝突の危険
性が解消され，両対話チャネル種別の連携も比較的容
易になる．ただし，Web 対話チャネルを提供するシス
テムは，内部に呼分配機能を持たないため，単独で利
用する際は，外部に呼分配機能を求めることとなる．
4.2システム構成
我々は，両対話チャネル機能の連携を図るという目
的と，呼分配衝突の危険性を回避するという観点から，
呼分配方式として第 3 の方式を採用した．システム構
成図を図 6 に示す．図では，CTI サーバ以外の電話
系システム部分は省略している．( 1 )通信プロトコル
図中の数字は，顧客が Web を参照している状態から
対話要求を発行（処理 1⃝）した際の，処理の流れを示
している．オペレータ割当ての要求（処理 2⃝）・応答
（処理 3⃝）や，オペレータ端末における参照 Web ペー
ジの更新を行うイントラネット内の通信は，信頼性と
2756情報処理学会論文誌Oct. 2000
図 6Web-CTI 統合システム構成図Fig. 6The architecture of the web based CTI system.
高めるため TCP 9)を用いる．一方，顧客端末と Web
サーバ間の通信プロトコルには，ファイヤウォール越
しでも利用できるようにするため，HTTP を用いる．( 2 )モジュール構成Web サーバ内部では，対話要求を受け付ける機能モ
ジュールと，URL 同期を受け付ける機能モジュール
とを分ける．これは，URL 同期機能以外の Web 連携
機能を拡張する際の拡張性と，URL 同期機能を単独
で別のシステムなどに流用する場合の汎用性を確保す
るためである．また，両モジュールはマルチプラット
フォームでの運用を可能とするため，Java☆のサーブ
レット技術10)を用いる．
( 3 )セッション管理
オペレータ割当ては CTI サーバの ACD 機能で一元処
理するが，セッション管理は個々の機能モジュールの
独立性を確保するため，それぞれのモジュールで行う．
つまり，電話系のセッション管理は従来どおり CTI
サーバで行い，URL 同期のセッション管理は URL 同
期サーブレットにて行う．
URL 同期サーブレットでは，同一セッションの話者
（端末）管理と同期 URL の情報を管理する．オペレー
タ側端末からの通信は，通信プロトコルとして TCP
を用いることから，IP アドレスを識別情報として利
用できる．オペレータ端末の IP アドレス情報は，オ
ペレータ割当ての結果情報に乗せて URL 同期サーブ
レットに伝える（処理 4⃝）．
一方，顧客側端末からの通信は，通信プロトコルとし
て HTTP を用いることから，プロキシを経由した場
合に，Web サーバ側で取得できる IP アドレスがプロ
キシの IP アドレスになってしまう．よって，顧客側
端末からの通信の識別にはセッション ID を導入して
利用する．セッション ID は各セッションごと一意に
付与する任意の数値で，顧客側端末へは対話要求受付
要求の応答に含める形で付与する（処理 5⃝，処理 6⃝）．
☆ Java は，米国 Sun Microsystems, Inc. の登録商標です．
顧客側端末からの通信は，以降，このセッション ID
を識別子として含めて行う．
5.URL 同期
URL 同期を実現する方式は，クライアント端末間でURL 情報を交換するという方式（方式 A）と，サー
バで同期情報を一元管理する方式（方式 B）とが考え
しかしながら，同期 URL の変更は特定の一者にし
か許可しないという場合なら方式 A でも問題はない
が，同期 URL の変更を相互に許可する場合に，方式
A では不都合が生じる．具体的には，各々が同時に同
期 URL の変更を行った場合に，それぞれの端末に反
映される同期 URL に違いが生じてしまう．
一方，多者間通信ではセッション管理面においても，
情報の一元管理を行う方式 B の方が有利である．我々
は，多者間で相互に同期 URL の更新を行えるように
するため，方式 B を採用した．構成を図 7 に示す．ク
ライアント側では，サーバとの間で情報交換を行うア
プレットと，表示する同期ページの制御を行うスクリ
プトとで本機能を実現する．
クライアント側における機能実現方法としては，プ
ラグインや専用アプリケーションで実現する方法もあ
• ユーザ側の事前環境設定不要• アップグレードの容易性
という理由から，汎用のブラウザのみで機能を実現で
きる，アプレットとスクリプトによる方法をとる．
5.2通 信 機 能URL 同期を行うためのクライアント端末と Web
サーバ間の通信には，HTTP を用いる．これは主に，
顧客端末と Web サーバ間におけるファイヤウォール
の通過を考慮してのものである．しかし，HTTP は
リクエストに対するレスポンスを受けるとコネクショ
ンは切断されてしまう．よって，同期 URL の更新を
行うには，CGI 要求として URL 同期サーブレットに
更新 URL 情報を送ればよいが，URL 同期サーブレッ
トから対話相手の端末へ更新された同期 URL を通知
することができない．
このような問題を解決する方法として，URL 同期
サーブレットで管理する同期 URL 情報を，クライア
ント端末側からポーリングにより一定時間間隔で参照
するという仕組みを採用する．そして，現在自端末上
で表示している URL と違っていた場合に，表示ペー
ジをポーリング参照で取得した URL に更新する．し
Vol. 41No. 10Web-CTI 統合システム2757
図 7URL 同期方式Fig. 7URL synchronization method.
かし，単純なポーリング方式では次のような課題が
ある．5.2.1ポーリング方式の課題
更新 URL 情報の反映速度は，ポーリング間隔に依
存する．短い間隔でポーリング参照を行うことが望ま
しいが，端末の処理負荷の増大，ネットワークの負荷
の増大，複数の端末からのポーリング要求を処理しな
ければならない Web サーバの処理負荷の増大をもた
らす．そこで，我々は次のような方式を用いて，負荷
の軽減と更新 URL 反映速度の向上とを実現した．5.2.2ディレイドアック型ポーリング方式
理想的には，サーバ側で管理する同期 URLが更新さ
れたタイミングで，クライアント側に更新された同期
URL 情報を通知するのが望ましい．TCP や UDP 11)
のような通信プロトコルを用いる場合であれば，サー
バから能動的にクライアントへ情報を送ることも可能
だが，HTTP を用いてサーバからクライアントへ情
報を送るの場合，リクエストに対するレスポンスとい
う手段しか用意されていない．そこで，このレスポン
スのタイミング調整を行うことでポーリング方式の課
題解決を図る．具体的な手法を図 8 に示す．( 1 )通信アプレットから，現在クライアント端末で表
示している同期ページの URL 情報を含めた形
で，URL 同期サーブレットへ最新の同期 URL
情報の取得要求を発行する．
( 2 )通信アプレットからの要求を受けた URL 同期
サーブレットでは，送られてきた URL 情報と現
在サーブレットで管理している最新の同期 URL
とを比較する．( 3 )ここで双方の URL に違いがあった場合には即
座に最新の同期 URL 情報を返し，双方の URL
が同じだった場合には一定時間レスポンスを遅
図 8ディレイドアック型ポーリング方式Fig. 8Delayed-ack style polling principle.
( 4 )レスポンスを保持している間に同期 URL が更
新された場合は，そのタイミングで即座に，更新
された同期 URL 情報をレスポンスとして返す．
このような手法を用いることにより，更新された同
期 URL の反映速度を向上させるとともに，通信トラ
フィックの削減を実現する．
6.Web ベーステレポインティング
テレポインティングとは，電子対話システムなどで
用いられる機能であり，お互い遠隔地に離れた話者同
士が，双方端末を用いて共有参照するドキュメント上
で，特定の箇所を相手に指し示す際に用いる電子的な
指示棒のことである12)．Web-CTI 統合システムでも，顧客とオペレータと
の間で URL 同期機能を使い，Web ページを相互参照
しながら対話を行う際に，ページ上の特定箇所を指し
示す際の機能として導入する（名称：Web ベーステ
レポインティング，略称：WebTP）．
ただし，本稿の Web-CTI 統合システムでは，クラ
イアント環境を汎用のブラウザのみで実現することを
目的としているため，従来の電子対話システムのよう
に専用のアプリケーションで機能を実現するのではな
く，URL 同期同様，汎用のブラウザ上でテレポイン
ティング機能を実現することが課題となる．6.1アーキテクチャ
汎用ブラウザ上でテレポインティング機能を実現す
る方式として，URL 同期実現方式と同様の構成を用
いる（図 9 参照）．( 1 )ポインタの表示と移動
2758情報処理学会論文誌Oct. 2000
図 9Web ベーステレポインティング（WebTP）実現方式Fig. 9A method for implementing web basedtele-pointing.
ポインタとして利用する画像はオブジェクトとして扱
い，マウスイベントと連動させる形でページ内におけ
る表示位置を更新する．具体的には，スクリプトでマ
ウスイベントの監視とポインタ画像の表示位置の制御
とを行い，ページ内でマウスクリックが行われた位置
にポインタの移動を行う．( 2 )ポインタ表示位置の同期
話者間におけるポインタ表示位置の同期は，ポインタ
の表示位置である座標値を，URL 同期における URL
の値と同様，サーバで一元管理することにより実現す
る．管理情報としてのセッション情報は，URL 同期
のものを継承するなどして共通化を図る．
クライアント側の通信機能はアプレットで実装し，
ポインタの表示位置が更新された際には，移動先の座
標値をサーバに送信する．クライアント側では，サー
バで管理する同期座標を監視することにより，ポイン
タの表示位置の同期を図る．このときの監視方法には，
URL 同期で採用したものと同様のディレイドアック
型ポーリング方式を用いる．
サーバによる同期情報の一元管理方式と，同期情報
の監視に用いるポーリング方式との採択理由は，URL
同期の場合と同様である．
( 3 )移動されたポインタの反映
監視する同期座標値が変更された場合は，アプレット
側からスクリプト内の処理を起動し，ポインタの表示
位置を更新する．ポインタ表示位置の更新処理は，自
端末でポインタの移動を行う際に，マウスイベントに
より起動される処理と同様である．6.2コンテンツへの影響と課題
アプレットとスクリプトを用いてブラウザ上でのテ
レポインティングを実現する場合，URL 同期の実現
では起こらなかった問題が新たに発生する．
スクリプトで処理する表示制御の違いによるのだが，
URL 同期ではウィンドウ内に表示する URL の指定だ
けであったのに対し，テレポインティングではページ
上で発生するイベントの監視とページ上へのポインタ
表示とを行う必要がある．これを実現するためには，
テレポインティングを利用するページにスクリプトを
追加しなければならない．
ポインタの表示/非表示は切替えが可能なので，事
前にテレポインティング機能を利用すると思われるコ
ンテンツすべてにスクリプトを追加しておくという方
法が考えられる．しかし，自前のコンテンツであれば，
このような方法も可能だが，システム外にあるコンテ
ンツに対しては，直接手を加えることはできない．
よって，人為的な方法ではなく，自動的にコンテン
ツにスクリプトを追加する方式を用いることにより，
外部のコンテンツも対象としてテレポインティング機
能を実現することが課題となる．6.3リダイレクトサーブレット
テレポインティング機能を利用しようとする任意の
コンテンツに，スクリプトおよびアプレットを自動的
に追加する方法を図 10 に示す．
図中「Redirect」と記したモジュールが，HTML 文
書に WebTP 用のスクリプトとアプレットの追加処理
を行うサーブレットであり，リダイレクトサーブレッ
トと呼ぶ．リダイレクトサーブレットはプロキシサー
バのような中継機能を持つモジュールで，テレポイン
ティング機能を利用しようとするコンテンツをクライ
アントが読み込む際にコンテンツを中継し，中継の際
にスクリプトとアプレットの組込みを行う．図 10 で
は，URL 同期サーブレットと WebTP サーブレット
とを統合した形でのシステム構築例を示している．
たとえば，オペレータから発行さるテレポインティ
ング機能の利用開始命令は，リダイレクトサーブレッ
トに対して CGI 要求を発行するという内容の URLを，
同期 URL 情報として URL 同期サーブレットに登録
する処理を行う（処理 1⃝）．同一セッションで URL 同
期状態にあるクライアントでは，更新された同期 URL
の通知を受けると（処理 2⃝），自動的にリダイレクト
サーブレットに要求を発行する（処理 3⃝）．リダイレク
トサーブレットでは，受信した要求内容に指定されたURL のコンテンツを読み取りに行く（処理 4⃝， 5⃝）．
ここでリダイレクトサーブレットは，読み取ったコン
テンツの内容をクライアントに中継する際に，テレポ
インティング機能を実現するためのスクリプトとアプ
レットとをコンテンツに挿入する（処理 6⃝）．スクリ
Vol. 41No. 10Web-CTI 統合システム2759
図 10WebTP 機能の組込み方法Fig. 10How to append a WebTP functions to the contents.
図 11処理応答時間の測定項目Fig. 11Measurement of the transaction and responsetimes.
プトとアプレットが挿入されたコンテンツを受信表示
すると，クライアントはテレポインティング機能を利
用可能となる．
ここでは，4.2 節で示した Web-CTI 統合システム
における処理応答時間の実測結果と，5.2.2 項で示し
たディレイドアック型ポーリング方式の有効性の検証
まずはじめに，処理応答時間の測定項目を図 11 に
示す．顧客－ WWW サーバ間の通信時間はネットワー
クに依存するため，今回の測定項目からは外した．測
定は，WWW サーバが顧客からの対話要求を受け取っ
てから，オペレータの割当てや URL 同期の開始準備
を行い，顧客への応答を返すまでの各処理に要する時
間の測定を行った．測定に使用した WWW サーバの
スペックを表 1 に，30 回測定した結果の平均値を表 2
に示す．測定結果は，JavaVM の場合と HotSpot を
使った場合の 2 通りを示す．
表 1測定に使用した WWW サーバのスペックTable 1Speciﬁcation of the WWW server.
CPUPentium☆1II 333 MHzOSWindows NT☆2Server 4.0 SP5Java VMSun☆3JDK☆41.2.1 for Win32☆5
WWW serverIIS 4.0Servlet engineJRun 2.3
表 2測定結果（平均値）Table 2Average time of the measurement.
Classic VMHotSpot VM
応答時間1.420 [msec]0.964 [msec]
起動時間0.0590.037ACD 要求0.8750.602同期開始要求0.0510.042File I/O0.4070.265その他0.0270.019
表 2 より，最も時間がかかるのは CTI サーバでの
オペレータの割当て（ACD 処理）であることが分か
る．しかし，対話要求を受け取ってから応答を返すま
での応答時間が 1.5 秒弱であることから，顧客側から
見た応答待ち時間としてはほとんど問題にはならない
次に，オペレータが更新した同期 URLが，顧客側に
反映されるまでに要する時間を，従来型のポーリング
方式とディレイドアック型ポーリング方式それぞれで
☆1 Pentium は，Intel Corporation のアメリカ合衆国およびその他の国における登録商標です．☆2 Windows NT は，米国およびその他の国における米国 Mi-crosoft Corp. の登録商標です．☆3 SUN は，米国での米国 Sun Microsystems, Inc. の登録商標です．☆4 JDK は，米国およびその他の国における米国 Sun Microsys-tems, Inc. の商標または登録商標です．☆5 Win32は，米国およびその他の国における米国Microsoft Corp.の登録商標です．
2760情報処理学会論文誌Oct. 2000
図 12同期 URL 更新反映時間Fig. 12Reﬂection time after updating the syncronizedURL.
表 3URL 更新反映時間Table 3Propagation time of the event that operaterupdate syncronized URL.
ポーリング方式ポーリング待ち時間処理時間
（平均確率時間） （実測平均時間）
（ポーリング間隔 1 秒）0.500 [sec]0.021 [sec]
（ポーリング間隔 30 秒）15.000 [sec]0.021 [sec]
ディレイドアック型0.016 [sec]0.031 [sec]
示す．オペレータからの同期 URL 更新通知を WWW
サーバが受けた後，顧客側から同期 URL 情報の問合
せが発せられるまでのポーリング間隔による待ち時間(1) と，問合せを受けてから応答を返すまでの処理時
間 (2) を求めた．ここでは，通信時間を除外した形で
更新反映時間の比較を行う（図 12 参照）．
従来型のポーリング方式の例としては，前回のポー
リングの応答を受けてから次のポーリングを発行する
までのポーリング間隔を，1 秒間隔で行う場合と 30 秒
間隔で行う場合の 2 つのケースを想定する．一方，ディ
レイドアック型ポーリング方式の例としては，ポーリ
ング間隔を 1 秒とし，URL 同期サーブレットの方で
応答を返すのを保持する最長時間を 30 秒と設定する．
各々の場合のポーリング待ち時間と処理時間を表 3
に示す．この表から，ディレイドアック型のポーリン
グを行う場合は，URL 同期サーブレットで応答待機
用のスレッドを新たに設けるため，従来型に比べ処理
時間 (2) は多少多くなる．しかし一方では，応答待機
スレッドで同期 URL の更新を監視している場合は，
ポーリング待ち時間 (1) がなくなるため，全体を通し
てみると，同期 URL が更新されてから相手側に反映
されるまでの時間を短縮可能であることが分かる．
8.お わ り に
Web-CTI 統合システムを実現するにあたり，対話
チャネルの連携という観点から，電話対話チャネルとWeb 対話チャネルの連携を実現する呼分配方式と，シ
ステム構成およびセッション管理方法を示した．セッ
ション ID をキーとするセッション管理方法は，端末
アドレスの特定が困難な環境に適する．
また，Web 対話機能として，URL 同期機能と同シ
ステムにおけるテレポインティング機能の実現方式を
示した．サーバで管理する情報をクライアントからHTTP で取得・更新する Web システムを構築する際，
本稿で示したポーリング方式は，最新情報の取得・反
映速度の向上と通信トラフィックの削減に有効である．
今後は，ユーザ評価などを行う予定である．
(平成 12 年 3 月 13 日受付)(平成 12 年 9 月 7 日採録)
企業と顧客を結ぶコミュニケーションチャネルとし
て Web 等インターネットの普及が進んでいる．コー
ルセンタ等の CTI(ComputerTelephony Integration)
による従来の電話チャネルと Web チャネルの統合化
により，両者の利点を融合したあらたな顧客と企業間
コミュニケーションチャネルが構築できるため，イン
ターネット統合型 CTIシステムが注目されてきている．
本論文では，インターネット CTI において，顧客と
コールセンタオペレータ間での Web チャネルと CTI
チャネルを融合した相談業務の遷移を考察し，チャネ
ル間連携方式の提案，システム開発，評価を行ったも
のである．リアルタイム CSCW の新たな応用システ
ムの展開を図り実現しており，有用性，信頼性の高い
論文である．
（グループウェア研究会主査 岡田謙一）
参 考 文 献
1) コンピュータ・テレフォニの新潮流，日経コミュニケーション，10.19 号, pp.122–129 (1998).2) IETF RFC1630: Universal Resource Identi-ﬁers in WWW (1994).3) 山田秀明ほか：網側 IN 設備とユーザ側 CT 設備のインターワーキング・アーキテクチャとサービス，電子情報通信学会論文誌，Vol.J82-B, No.5,pp.799–808 (1999).4) 中山良幸，野中尚道，星徹：WWW 上に公開された “行き先ボード” から最適な通信メディアを直接選択できるコンタクト支援システム，情報処理学会論文誌，Vol.39, No.10, pp.2811–2819(1998).5) 中川健一，國藤進：アウェアネス支援に基づく
Vol. 41No. 10Web-CTI 統合システム2761
リアルタイムな WWW コラボレーション環境の構築，情報処理学会グループウェア研究会，25-4(1997).6) 田中匡史ほか：分散環境での非対称コミュニケーションを支援する遠隔相談システム，情報処理学会論文誌，Vol.40, No.2, pp.652–660 (1999).7) 田淵仁浩ほか：オフィスアクセラレータ：Webページ上の文書を任意のパソコンソフトで共同作成できるシステムの提案と実装，情報処理学会論文誌，Vol.40, No.11, pp.3868–3877 (1999).8) IETF RFC2616: Hypertext Transfer Protocol– HTTP/1.1 (1999).9) IETF RFC793: Transmission Control Proto-col (1981).10)「CGI/Perl」vs.「Java サーブレット 」，Sun-World, pp.78–83 (Feb. 1999).11) IETFRFC768:UserDatagramProtocol(1980).12) 中山良幸，森賢二郎，中村史朗，山形忠：他社間電子対話システム ASSOCIA，情報処理学会論文誌，Vol.32, No.9, pp.1190–1199 (1991).
湯本一磨（正会員）1993 年横浜国立大学大学院工学研
究科電子情報工学専攻修士課程修了．
同年（株）日立製作所入社．CSCW，CTI，VoIP 等の研究開発に従事．現
在，同社システム開発研究所第 4 部
星徹（正会員）
1969 年東京工業大学電気工学科卒
業．同年（株）日立製作所入社．1975
年カリフォルニア大学ロサンゼルス
校（UCLA）大学院コンピュータサ
イエンス学科修士課程修了．交換機，
マルチメディア光 LAN，CSCW，CTI，VoIP 等の研
究開発に従事．現在，同社システム開発研究所第 4 部
主任研究員．IEEE，電子情報通信学会各会員．
中山良幸（正会員）
1983 年筑波大学大学院数学研究科
修士課程修了．同年（株）日立製作
所入社．1991～1992 年 Stanford 大
学 CSLI 客員研究員．GUI，CSCW，CTI，電子カルテ等の研究開発に従
事．現在，同社公共情報事業部医療情報システム本部
医療企画部主任技師．
高橋亨（正会員）
1982 年富山大学理学部地球科学
科卒業．1983 年（株）日立インフォ
メーションテクノロジー入社．POS，CTI 製品開発に従事．現在，同社応
用システム本部 CTI ビジネスセン
タソフト開発プロジェクトマネージャ．
1997 年大阪市立大学工学部電気工
学科卒業．同年日立西部ソフトウェ
ア（株）入社．CTI，ドキュメント
ソリューション製品等の製品開発に
従事．現在，（株）日立製作所システ
ム開発研究所第 4 部に派遣．