本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Sametime > 

LDD Today

Sametimeボット（bot）を作ってみよう 第2回


 Lotus Software
by John W. Rooney and Dick McCarrick
レベル：中級者
対象: Lotus Sametime
原文の掲載：2003年3月3日

LDD Todayの原文（US）

インデックス
IM概念の簡単な復習
アプリケーションへのIMの統合
AlertBot
まとめ

LDD Todayの記事 「Sametimeボット（bot）を作ってみよう　第1回」では、どのようにしてボットとして知られる自動エージェントを、ユーザーの問い合わせに対する応答を生成するために使えるのかについて重点的に説明しました。今月の記事では、このアイデアを次のレベルに進めて、どのようにしてアプリケーションをSametimeに接続し、Instant Messaging（IM）をアラート・システムとして使うか、さらにどのようにしてIMをワークフローへ組み込むかについて説明します。キー・ポイントとして示そうとしているのは、ユーザーからではなくアプリケーションのほうから、どのようにすればユーザーとの会話を開始できるかということです。

はじめに、Sametimeの重要な概念である存在と在席管理、およびこれらを自動アラートやワークフローのプログラムにどのように組み込むかということについて検討します。次に、ユーザーに対して事前対処的にメッセージを送信するために必要となる基本的技術を示す、実際に動くSametimeボットであるAlertBotについて詳細に検討します（AlertBotのコードはSandbox（US）からダウンロードできます）。

この記事では、読者がSametimeとJavaの経験のあるプログラマーであり、Sametimeのデベロッパーズ・ツールキットについてよく知っているということを前提にしています。


IM概念の簡単な復習
数年前にIBMがSametimeインスタント・メッセージング（IM）をはじめて発表した際には、それがどのようなものであれ新しい技術をコミュニケーションの主要ツールとして使うことに対してユーザーが感ずる当然の抵抗に会いました。社内の電子メール配信は高度に最適化されており、しばしば世界中の仲間と「リアルタイムに近い」会話をするために使われていました。このような状況であったため、ユーザーからはしばしば、IMは電子メールを使用するのとどこが違い、IMを使うことでどのような利点が得られるのかを尋ねられました。

もちろん今日では、IMがいかに大きくユーザーの対話を変えたかをみなよく知っています。IMと電子メールの間の最も明確な違いに、存在と在席管理という概念があります。企業内のIMについて論ずる際には、これら2つの概念がしばしば同じように扱われますが、今回の記事では別々に考えてみることにします。

はじめに、存在と在席管理がボットにどのように関係するかについて考えてみましょう。ボットについてユーザーと議論するときには、多くの重要な事実をしばしば強調しています。たとえば、Sametime Connectクライアント上で仕事をする際に、ボットがいかに便利な方法を提供してくれるかについて、ユーザーは簡単に理解できます。しかし、便利さはボットというもののほんの一部にすぎません。Sametimeの存在と在席管理の機能を用いると、IMをアプリケーションに緊密に統合することができます。実際、ボットがオンラインであることをユーザーが知ることができるだけでなく、ユーザーがオンラインであるか、ユーザーの現在のオンライン状態がどのようなものかをボット自体が「知る」ことができます。アプリケーションにより、ユーザーの状態（「離席」から「活動中」への移行など）の変化を追跡し、これをメッセージ送信などの動作を実行するトリガーに使えます。そこで存在と在席管理の概念にもう少し深く立ち入り、アラートと通知サービスを実行するSametimeボットにこれらの機能をどのようにして組み込むことができるかを見ていくことにしましょう。

存在
存在とは、ネットワーク上の他のユーザーに自分の現在の活動状況を示す能力です。Sametimeでは、これらの活動状況として以下のようなものが考えられます。
  • オンライン−対応可能
  • オンライン−離席中
  • オンライン−対応不能
  • オフライン
特定のユーザーが対応可能な状態でメッセージに応答できるかどうかを知ることができるので、これは非常に強力な機能です。電子メールや他のタイプのメッセージングでは、受信者が現在そこにいて、そのメモを読んでくれるのかどうかがわからないまま、送信することが多いでしょう。即座に応答が来るかもしれませんが、来ないかもしれません。これが電子メールとIMとの決定的な違いです。

IMと違って、ファイルや埋め込み画像などを添付できるので電子メールのほうが内容が豊富である、と多くのユーザーは指摘します。（IM技術の現状を考えれば少なくとも現在のところは）その通りです。しかし、それはここでの論点ではありません。電子メールの完全な置き換えとしてIMを推進しようとしているわけではありません。そうではなく、IMは電子メールや他のメッセージング・システムを拡張するものです。実際、IMと電子メールはNotesBuddyのような単一のアプリケーションに統合することもできます。 しかし、時間がますます貴重なものになりつつある世の中では、この瞬間に特定の人が対応可能かどうかを知る必要性はビジネスに不可欠なアプリケーションの重要なコンポーネントとなる可能性があります。

在席管理
在席管理とは、IM環境における他のユーザーの存在を感じ取る能力です。存在と同様に、これはつまるところ、チャットを開始しようとするユーザーに、即座に応答を得られそうかどうかを知らせるという機能です。在席管理はまた、会話を開始しようとしているユーザーが使用する通信手段を決定できるようにします。たとえば、同僚とプレゼンテーションを準備しており、この四半期の最新売り上げ予測を確認する必要が生じたとします。これは単純な会話で済むと考え、Sametime Connectを起動して同僚にインスタント・メッセージを送ろうとします。ところが、同僚の名前を見るとその状態が対応不能と表示されています。したがって、この同僚と会話を開始することはできません。さらに、この同僚は一日中顧客説明を行っていると書かれたメッセージを残しています。これら2つのデータを手にした後では、次のような判断ができます。予測が明日になるまで必要ないならば、同僚に電子メールを送ります。この情報が今日必要ならば、それを得るために他の同僚を探すことができます。これは単純な例ですが、他のユーザーのIM状態を認識することがいかにビジネス・プロセスに影響を与えるかを示しています。これは非常に強力であり、どのようにしてアプリケーションが在席管理を活用できるのかという例を示します。

最後にここでもう1つ強調しておきたいのは、さまざまなメッセージ・タイプが受信者に与える「心理的な」影響と、それぞれに対する応答をどのように優先順位付けするかということです。電子メールによって過負荷の状態にあるとみな感じています。毎日、受信箱は整理しなければならない多数のメッセージであふれかえっています。ほとんどの電子メール・プログラムはこうしたメッセージの洪水の処理を手助けするツールを持っています（たとえば、Notesのフォルダーとルールなど）。しかしそれでも、時には追いつくのが困難な場合もあります。「電子メールの中で暮らしているようだ」と、ユーザーがこぼすのをよく耳にするのも不思議ではないでしょう。それに対してIMは、即座に送れる簡単な「軽い会話」という印象を与えます。さらに、IBM内でSametimeを発表した経験では、ユーザーが自在にマルチタスクや同時にいくつかの会話を行うことをIMが可能にするような多くの例を目にしてきました。考えてみてください。もし重要な仕事の途中だとしたら、インスタント・メッセージと電子メールのどちらに答える可能性が高いですか。おそらくユーザーのほとんどが、たとえその会話の話題が重要に見えなくとも、まずインスタント・メッセージに答えるでしょう。メッセージが画面上に現れると、ユーザーは会話をして問題を解決し、次に進みます。さらに、他のユーザーを会話に参加するよう促し、議論を広げ、質問に対する応答時間を改善することも容易です。Marshall McLuhanの言葉を借りれば、「メディアは、しばしばメッセージである」と言えるでしょう。
 
上に戻る
 
アプリケーションへのIMの統合
それでは、どのように存在と在席管理をアプリケーション内で利用できるのか、そしてビジネス・プロセス、特にユーザー・アラートやワークフロー内にさらにIMを統合できるのかについて説明しましょう。

アラート
はじめに、サーバーが生成するユーザー宛のアラートの配信にSametimeを使う方法について検討します。アプリケーションの中には、状態の変化や予測されるプロセスに対する例外発生など何らかのイベントをユーザーに知らせる必要があるものが必ずあります。サーバーがクラッシュしたり、性能しきい値に達したりしたときにアドミニストレーターに送信されるアラートがこの明らかな例です（もちろんIBMのオートノミック・コンピューティング戦略により、将来そのようなアラートははるかにまれになり、重要でなくなりますが、いまのところはアドミニストレーターに知らせておくことにしましょう）。このようなアラートは、携帯電話、ポケットベル、あるいは電子メールに自動的に配信することができます。

これらをIM経由で配信することもできます。メッセージを取得し、Sametimeに接続して対象となる受信者の状態を知り、Sametimeを通してメッセージをユーザーに届けられるかどうかを判断するようなコードをアプリケーションに追加できます。ユーザーがオンラインの状態で対応可能であるならば、アプリケーションはユーザーにインスタント・メッセージを送信できます。ユーザーが他の状態である場合には、アプリケーションはこのユーザーにコンタクトを取るために、次善のパス（電子メールや文字送信ポケットベルなど）を選択できます。

Sametimeの初期リリースでは、送信したメッセージによりユーザーのデスクトップにチャット・ウィンドウが開きました。Sametime 3になり、現在はもう1つのメッセージ・タイプである「通知」を使えるようになりました。通知は、ユーザーが応答できないダイアログ・ボックスをデスクトップ上に開きます。これは、アプリケーションがアラートを発している状態でユーザーに会話を続けさせたくないときに非常に有効であると思われます。

ワークフロー
ユーザーは誰でも、アプリケーション内でワークフローの概念に多少とも触れたことがあるはずです。ほとんどのユーザーは、電子メールを通して配信されるフォームを通してワークフロー管理システムに関わります。最近はアプリケーションをWebへ移行することがますます多くなったため、ユーザーがクリックすると該当する動作を実行できるURLを含むフォーム・サマリーを、ワークフロー・システムが電子メールで配信することが多くなりました。通常これらのアプリケーションは問題なく機能しますが、ユーザーに直接情報を提示する必要がある場合にIMは優れた代替案を提供できます。
ワークフロー内にどのようにIMを統合できるかを判断するための決定木を見てみましょう。

decision tree

ワークフロー・プロセスの駆動にIMを使う話をすると、「実績のある」従来の電子メールに基づくシステムで十分であると思われるため、Sametimeによる承認フォームの価値を疑問視する人が出てきます。ここでのキー・ポイントは、アプリケーションに合ったバランスを見つけることです。フォーム情報の配信すべてにIMを使う必要はないということを忘れないでください。もしアプリケーションがデスクトップ・アプリケーション経由でフォームを提供するならば、Sametimeを単に前のセクションで述べたようなアラートの送信に使用できます。もしアプリケーションがフォームに対するWebインターフェースを提供するならば、承認者がフォームを開くためにクリックするURLを送信できます。

もちろん、承認者が承認完了をSametimeインターフェースを通して表示できるようにする方法を検討することを推奨します。Sametimeで送れるメッセージは現在のところテキストに限られていますが、これは通常関連する情報を送信する能力には影響を与えません。また、Sametimeの会話は認証および暗号化が可能であるということも覚えておいてください。情報が正当なユーザーによって受信され、メッセージの内容は保護されているということを確信できます。
 
上に戻る
 
AlertBot
ここに示すサンプル、AlertBot（Sandboxからダウンロードできます）は存在と在席管理両方を用いて、ユーザーに対して事前対処的にメッセージを送るボットに必要とされる基本技術を示します。 この技術は、すべてのボットの機能を拡張し、単なる質問／応答システムを超えて完全な機能を持ったアプリケーションに移行できます。この例では、AlertBotは特定のユーザーのオンライン状態を監視し、その状態が変わったときにアラートを発します。
AlertBotでは以下の機能が示されます。
  • ユーザーの身元（ユーザーID）をSametimeのユーザー・オブジェクトへと解決する
  • Sametimeユーザーのオンライン状態を監視する
  • Sametimeユーザーとの会話を開始する
AlertBotの説明では、ログイン、リスナーの使い方、テキストの送受信などの基本は割愛します。これらの話題について復習したい場合は、前回の記事で説明していますので参照してください。
ユーザーの識別と在席管理の保持を専門に扱ういくつかの新しいオブジェクトを見ることにしましょう。下記の2行で、LookupServiceはResolverオブジェクトを提供します。Resolverオブジェクトは、ユーザーIDを文字列として読み込み、それを会話の開始に用いることができる実際のオブジェクトへと「解決」します。

protected LookupService lookupService;
protected Resolver resolver;

AwarenessServiceはWatchListオブジェクトを提供します。WatchListにより監視するユーザーのリストが管理され、在席管理メッセージが（AwarenessListenerインターフェースを通して）提供されます。

protected AwarenessService awarenessService;
protected WatchList watchList;

これらのオブジェクトを使うには、はじめにこれらを作成し初期化しなければなりません。これは通常（LoginListenerインターフェース内の）loggedIn()イベント内で行われます。まず、LookupServiceオブジェクトを作成します。次に、LookupServiceからResolverオブジェクトを作成し、そこにリスナーを追加します（メソッドのパラメーターの完全な説明については、Sametime Java Toolkit Developer's Guideを参照してください）。

//Get a handle to the Lookup Service and add a resolve listener
lookupService = (LookupService) stsession.getCompApi(LookupService.COMP_NAME);
resolver = lookupService.createResolver(true, false, true, false);
resolver.addResolveListener(this);

次にAwarenessServiceを作成します。さらにWatchListオブジェクトを作成し、そこにも同様にリスナーを追加します。

//Get a handle to the Awareness Service and create a WatchList
awarenessService = (AwarenessService) stsession.getCompApi(AwarenessService.COMP_NAME);
watchList = awarenessService.createWatchList();
watchList.addStatusListener(this);

この例では、ユーザーがコード内で指定されており、即座に解決されます。より高度なアプリケーションでは、ユーザー名のリストをアプリケーション自体で駆動することも可能です。解決は、ログイン時だけでなくいつでも可能です。現在のところは、単にResolverを呼び出して、あるユーザー名を解決します。

resolver.resolve(UTW); // UTW is the String user ID Constant

いつものように、loggedOut()イベントが呼び出されたら、忘れずにこれらのリスナーを削除し、ResolverとWatchListオブジェクトをクリーンアップします。

resolver.removeResolveListener(this);
watchList.close();
watchList.removeStatusListener(this);

ResolveListenerインターフェースには3つのメソッドがあります。AlertBotで使うのはresolved()だけです。このメソッドでは、文字列のユーザーIDが、使用可能なオブジェクトであるSTUserに解決されました。STUserオブジェクトは、有効なログイン済みユーザーを表すためにSametimeが使用する主要なオブジェクトです。このSTUserオブジェクトは、WatchListがSTUserオブジェクトの状態監視を開始するために用いられます。ここでしなければならないのは、STUserオブジェクトをWatchListに追加することだけです。

public void resolved(ResolveEvent re) {
    if (re.getResolved() instance of STUser) {
      STUser user = ((STUser) re.getResolved());
      String userName = user.getName();
      sysOut("Resolved " + userName);
      watchList.addItem(user);
      sysOut("Added " + userName + " to WatchList");
    }
}

AwarenessListenerは2つのイベント・メソッドを持っています。この例で関係するのはそのうちのuserStatusChanged()だけです。このメソッドは、最初に監視対象のユーザーがWatchListに加えられたときも含めて、ユーザーの状態が変化したときにはいつでも呼び出されます。また、ユーザーの現在の状態も検証します（ユーザーが活動中か離席中の場合は、アラートを送信するだけです）。
IMオブジェクトが、createIm()メソッドを用い、ImServiceを通して作成されます。IMオブジェクトを作成する場合は、ImOpened()イベントを確実に受信するために、IMが開かれる前にImListenerを追加しなければならないことに注意してください。

    public void userStatusChanged(StatusEvent se) {
      //We get an array of objects representing the users
      Object wu[] = se.getWatchedUsers();

      STWatchedUser stwu = (STWatchedUser) wu[0];
      sysOut(stwu.getName() + " status changed to " + stwu.getStatus().getStatusDescription());
        if (stwu.getStatus().getStatusType() == STUserStatus.ST_USER_STATUS_ACTIVE || stwu.getStatus().getStatusType() == STUserStatus.ST_USER_STATUS_AWAY) {
        //Send an alert to the user
        sysOut("Alert called for " + stwu.getName());
        //Set the IM Type to IM_TYPE_CHAT
        int imt = ImTypes.IM_TYPE_CHAT;
        //Set the encryption level
        EncLevel enc = EncLevel.ENC_LEVEL_ALL;

        //Create the channel to the user
        Im im = imService.createIm(stwu, enc, imt);
        Im.addImListener(this);
        im.open();
      }
    }

ImOpened()イベントは前回の記事で説明したImReceived()イベントに非常に似通ったものですが、ImReceived()がIMオブジェクトがリモートで開かれたときに発生するのに対し、ImOpened()はIMオブジェクトがローカルで開かれたときに生成されます。ImOpened()イベント内には、既知の有効なSTUserオブジェクトと開かれたIMオブジェクトが含まれます。これでIMオブジェクトを用いてテキストを送信できるようになりました。この例では、ユーザーに、その現在の状態と状態メッセージがどのようなものかを知らせます。

public void ImOpened(ImEvent ie) {
    sysOut("IM Opened to " + ie.getIm().getPartner().getName());

    //To get the user status, we need to cast the IM object as an STWatchedUser
    STWatchedUser stwu = (STWatchedUser) ie.getIm().getPartner();
    if (ie.getIm().isOpen()) {
      String text = "I see that your status has changed to " + (stwu.getStatus().getStatusType() == STUserStatus.ST_USER_STATUS_ACTIVE ? "Active" : "Away");

      ie.getIm().sendText(false, text + " with the message \"" + stwu.getStatus().getStatusDescription() + "\"");
      sysOut("Message sent to " + ie.getIm().getPartner().getName());
      try {
        // This is to make sure the message is sent before closing the IM

        Thread.sleep(2000);
          } catch (InterruptedException e) {
      }
      ie.getIm().close(STError.ST_OK);
    }
}
 
上に戻る
 
まとめ
Lotus Sametimeの存在と在席管理の機能では、単純な質問／応答ボットを強力なアプリケーションに変えることができます。存在を公開し、在席管理を活用することで、アプリケーションはユーザーとの会話を開始し、ユーザーに応答することができます。これらの機能をアプリケーション内で用いることで、Sametime環境から新たな価値を引き出し、重要なビジネスの課題に対する応答時間を改善することができます。自由にAlertBotのコードを検討し、作り変えてみてください。これらのアイデアが組織の中で利用されることを願っています。



著者について
John W. Rooneyは、IBMのインターネット技術開発部門マネージャーです。Rooney（友達は彼をそう呼びますが）と彼のWebahead/Internet Technology Groupは、いくつかのSametimeボット技術に大きく依存しているものを含め、IBM内で広く使われているさまざまなアプリケーションを開発してきました。
Eben Stewartは、IBMのWebahead/Internet Technology Groupのソフトウェア・エンジニアです。彼は、Bluepages（社内ディレクトリー・ボット）のような、社内で使用するボット・アプリケーションを提供するためにIBMで使用されているツールキットであるBotServerの主要な開発者です。
 
上に戻る