JP2000056976A - グループウェアシステム、情報処理方法及び情報処理用ソフトウェアを記録した記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 柔軟性・拡張性に優れ、変更の容易なグルー
プウェアシステム、情報処理方法及び情報処理用ソフト
ウェアを記録した記録媒体を提供する。 【解決手段】 プランニング部４１は、要求投入部１か
ら与えられるゴールを達成するためのエージェントのプ
ランを、知識記述部５を参照して作成する。グループウ
ェア共通アクション知識部５１１とグループウェア共通
インフォ知識部５２１は、グループウェアシステム全体
又はアプリケーションにおいて統一的に利用される動作
と情報とを表し、予め決められたアクセス権がなければ
編集できない。ノウハウアクション知識部５１２とノウ
ハウインフォ知識部５２２は、そのようなアクセス権が
なくても編集できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークで互
いに接続された複数のコンピュータ上で、オフィス業務
やグループ業務といったグループ作業を支援するグルー
プウェアシステムの改良にかかわるもので、より具体的
には、エージェントを応用して柔軟性を高めたものであ
る。

【０００２】

【従来の技術】近年、コンピュータを使った情報処理シ
ステムの一種として、グループウェアシステムが知られ
ている。このグループウェアシステムは、ネットワーク
に接続された複数のコンピュータ上で行うユーザの作業
を支援するソフトウェアシステムであり、典型的には、
オフィス業務やグループ作業などに関わる多様なアプリ
ケーションを統合したソフトウェアである。

【０００３】このようなグループウェアシステムで使わ
れるアプリケーションは、申請書や稟議書などの書類を
しかるべき役職者間で回覧して承認を求めるワークフロ
ーや、各種業務ドキュメントを格納しておいてユーザに
提供する文書管理、また、ある業務に関係する複数の担
当者間での会議日程を調整する会議スケジュール調整の
他、グループ討議、電子メールなどにかかわる処理など
を行うものである。ここで、ワークフローとは、ある目
的や役割を実現する一連の作業の流れであり、このよう
な作業の流れを実現するシステムやアプリケーションプ
ログラムは、ワークフローシステムやワークフローアプ
リケーションと呼ばれる。

【０００４】例えば、Ｌｏｔｕｓ社のグループウェアＬ
ｏｔｕｓ Ｎｏｔｅｓは、上に述べたようなメール、文
書共有に加え、アプリケーション開発機能などを持った
統合的なグループウェアシステムの一例である。

【０００５】ここで、図９は、従来のグループウェアシ
ステムの構成例を示すブロック図である。すなわち、こ
の例は、複数のノードＮを、通信管理部Ｃを通じてネッ
トワークＮＷに接続したもので、それぞれのノードＮに
おいて、グループウェアシステムで使う各種のアプリケ
ーションは、開発者Ｄが開発してアプリケーションデー
タ部ＡＤに格納しておき、また、電子メール、個々のユ
ーザのスケジュール、見積書などのドキュメント（文
書）のように、情報処理に使う各種のデータをデータベ
ース部ＤＢに格納しておく。

【０００６】そして、必要なアプリケーションをアプリ
ケーションデータ部ＡＤから取り出して実行すること
で、各種アプリケーション部ＡＰの機能が実現される。
この各種アプリケーション部ＡＰは、いろいろな種類の
具体的応用課題（アプリケーション）を処理する部分
で、具体的には、電子メールのやり取りを処理する部分
（メールアプリケーション部ＭＡ）、スケジュールを管
理する部分（スケジュール管理アプリケーション部Ｓ
Ａ）、ドキュメントの更新などを管理する部分（ドキュ
メント管理アプリケーション部ＤＡ）などを含む。

【０００７】そして、このように実現される各部分Ｓ
Ａ，ＭＡ，ＤＡは、上に述べたデータベース部ＤＢに格
納された電子メール、スケジュール、ドキュメントなど
の各情報を使って情報処理を行う。

【０００８】また、上に説明したような各種アプリケー
ション部ＡＰとユーザとの間のインタフェースは、グル
ープウェアシステムのためのユーザインタフェース部Ｕ
Ｉによって実現される。このユーザインタフェース部Ｕ
Ｉは、メールインタフェースＭＩ、スケジュール帳イン
タフェースＳＩ、ドキュメント閲覧インタフェースＤＩ
を含む。これらはそれぞれ電子メール、スケジュール
表、各種ドキュメントなどの内容を、所定の形式の表示
用ウインドウやいろいろな種類の機能ボタンとともに表
示するインタフェースであり、上に述べた各種アプリケ
ーション部ＡＰとユーザＵとの間で情報のやり取りを仲
立ちする部分である。

【０００９】そして、Ｌｏｔｕｓ Ｎｏｔｅｓなど既存
のグループウェアシステムにおいては、アプリケーショ
ン開発やアプリケーション実行環境の設定といったシス
テム管理にかかわる作業は、通常のアプリケーションプ
ログラムなどと同様に、システム全体を把握している開
発者によって集中的に行われていた。例えば、承認書を
回覧し、その承認を求めるワークフローアプリケーショ
ンなどの場合、そのフロー、すなわち回覧／承認の経路
の設定は、アプリケーションを構成するデータとして、
その経路全体を把握している開発者によって一括して行
われていた。

【００１０】

【発明が解決しようとする課題】しかしながら、上に説
明したような従来技術には、次のような問題があった。 （１）まず、ワークフローシステム（ワークフローアプ
リケーション）における承認経路のようなシステム上の
設定は、担当者の不在、組織の変更や方針の変更などに
よって、そのアプリケーションの運用中に動的に変更さ
れることが多い。しかし、従来のグループウェアシステ
ムでは、このような変更に対処するためには、起こりう
るすべての可能性をあらかじめ想定して、アプリケーシ
ョン全体を構築しておく必要があった。このため、開発
者の負担が大きいだけでなく、アプリケーションの部分
的、かつ動的な変化への対応が困難で、柔軟な運用の障
害となっていた。

【００１１】（２）また、従来のグループウェアシステ
ムにおけるアプリケーションの開発、拡張、および修正
は、グループウェアシステム全体を把握した開発者によ
って行われるため、グループウェアシステムに含まれる
あるアプリケーションの一部分にのみ関与する開発者ま
たは担当者、ユーザ本人などが、部分的、局所的な拡
張、および修正を行うことも困難であった。

【００１２】（３）また、複数のコンピュータ上で、自
律的、柔軟なソフトウェアアーキテクチャを実現するた
めの技術として、近年では、エージェント指向技術が注
目されている。このエージェント指向技術とは、エージ
ェントを単位としてソフトウェアを構成するソフトウェ
ア開発技術であり、ここでいうエージェントとは、状況
に応じて自律的に動作するソフトウェア上の単位であ
る。

【００１３】そして、グループウェアシステムの一部
に、エージェントと呼ばれている機能を組み込んだもの
も知られている。しかし、従来のグループウェアシステ
ムにおいてエージェントと呼ばれている機能は、そのグ
ループウェアシステムに含まれるいろいろなアプリケー
ションのなかの１つのアプリケーションや、あるアプリ
ケーションのなかのさらに一機能に特化・限定されたも
のであった。例えば、図９に示したエージェント機能部
Ａは、このようにメールにかかわるエージェントの機能
を、メールアプリケーション部ＭＡに組み込んだ例であ
る。

【００１４】このように、従来のグループウェアシステ
ムに組み込まれたエージェントは、ある人からのメール
を監視するといったように、ある特定用途にかかわるも
のであり、グループウェアシステム全体を構成するベー
スとしてエージェント機能を利用しているわけではなか
った。

【００１５】このため、エージェントの持つ自律性など
の利点をグループウェアシステム全体として利用するこ
とはできなかった。また、エージェントにかかわる柔軟
性や拡張性は、グループウェアシステム全体の柔軟性や
拡張性を改善するものではなかった。

【００１６】（４）さらに、グループウェアシステムを
利用する個々のユーザは、ある問題に詳しい担当者のリ
ストといった価値のある情報を、個人的なノウハウとし
て、自分の利用しているノード上のローカルファイルな
どの形で保持していることが多い。一方、従来のグルー
プウェアシステムにおけるアプリケーションは、上に説
明したように、特定の又は一部の開発者によって集中的
に開発されていて、個々のアプリケーションが利用する
データも、アプリケーションの開発者によって、開発時
にデータファイルなどとして一元的に与えられていた。

【００１７】このため、従来のグループウェアシステム
では、個々のユーザーがノウハウなどの形で保持してい
る、オフィス業務やグループ作業に関する情報（ノウハ
ウ情報と呼ぶ）などをアプリケーションで有効に利用す
ることが困難であった。

【００１８】例えば、ある問題に関する会議を開催しよ
うとして、会議スケジュール調整アプリケーションを利
用する場合に、ある担当者が保持しているその問題に詳
しい担当者のリストに基づいて会議参加対象者を追加す
る、といった動作は、従来のワークフローでは実現困難
であり、個々のユーザが持つノウハウ情報をシステム全
体やアプリケーションで活用するグループウェアシステ
ムの技術が潜在的に待望されていた。

【００１９】（５）加えて、従来のグループウェアシス
テムは、それ自体が、いろいろな機能の部分的なソフト
ウェアを統合した単一のアプリケーションソフトウェア
として構成されていた。このため、グループウェアシス
テムのユーザインタフェースは、そのグループウェアシ
ステムの一部として提供されているものか、又はグルー
プウェアシステムが対応しているものとして予め指定さ
れた外部アプリケーションを使用しなければならなかっ
た。

【００２０】しかし、それぞれのユーザが従来から使用
しているソフトウェアの組み合わせなどの環境は、個々
人によって互いに異なる場合が多い。例えば、個人のス
ケジュールを管理するアプリケーションなどを例にとっ
ても、利用者のコンピュータ環境や好みなどに応じて、
いろいろな構成や種類のものがありうる。

【００２１】このようにユーザごとに異なる環境におい
て、例えば、グループウェアシステムによる会議スケジ
ュール調整アプリケーションを利用しようとした場合、
上に説明したように、ユーザはそれぞれが従来から使用
していたスケジュール管理アプリケーションから、グル
ープウェアシステムで統一的に使用されるユーザインタ
フェースのアプリケーションへの移行を強要される結果
となっていた。このため、既存のグループウェアシステ
ムを利用するためには、そのような移行にかかわるユー
ザの不便や、手間、コストといった負担が大きいという
問題があった。

【００２２】本発明は、上記のような従来技術の問題点
を解決するために提案されたもので、その目的は、グル
ープウェアシステムやそのアプリケーションをエージェ
ントを使って構築することで、柔軟性・拡張性に優れ、
変更の容易なグループウェアシステム、情報処理方法及
び情報処理用ソフトウェアを記録した記録媒体を提供す
ることである。

【００２３】また、本発明の他の目的は、グループウェ
アシステムやアプリケーションを実現する各種の動作に
関する情報のなかに、ユーザや担当者がそれぞれの視点
や権限で更新できる部分を作ることで、開発者のみなら
ず、担当者、ユーザも、それぞれが関与するレベルで局
所的かつ動的に、変更や拡張を行えるグループウェアシ
ステム及び情報処理方法を提供することである。

【００２４】また、本発明の他の目的は、分散して存在
する各ユーザのノウハウのような情報について、エージ
ェントが参照しそれに基づいて動作することでグループ
ウェアシステムにおける有効活用を図ることである。ま
た、本発明の他の目的は、グループウェアシステムに、
いろいろな種類のユーザインタフェースと接続する手段
を備えることで、ユーザがそれまで使っていた既存のユ
ーザインタフェースを継続して使用できるようにし、導
入が容易なグループウェアシステム及び情報処理方法を
提供することである。

【００２５】

【課題を解決するための手段】上記目的を達成するため
に、請求項１のグループウェアシステムは、ネットワー
クで接続された複数のコンピュータ上で、複数のグルー
プウェアアプリケーションを実行するグループウェアシ
ステムにおいて、前記コンピュータ上で自律的に動作す
るエージェントを備え、前記各グループウェアアプリケ
ーションの動作は、前記エージェントの動作として記述
されたことを特徴とする。請求項９の発明は、請求項１
の発明を方法という見方からとらえたもので、ネットワ
ークで接続された複数のコンピュータ上で、複数のグル
ープウェアアプリケーションを実行する情報処理方法に
おいて、前記コンピュータ上で自律的に動作するエージ
ェントを使い、前記各グループウェアアプリケーション
の動作は、前記エージェントの動作として記述されたこ
とを特徴とする。請求項１４の発明は、請求項１，９の
発明を、コンピュータのソフトウェアを記録した記録媒
体という見方からとらえたもので、ネットワークで接続
された複数のコンピュータ上で、複数のグループウェア
アプリケーションを実行するための情報処理用ソフトウ
ェアを記録した記録媒体において、そのソフトウェアは
前記コンピュータに、前記コンピュータ上でエージェン
トを自律的に動作させ、前記各グループウェアアプリケ
ーションの動作は、前記エージェントの動作として記述
されたことを特徴とする。請求項１，９，１４の発明で
は、個々のアプリケーションやその機能に対応するエー
ジェントの動作を設定したり変更することによって、グ
ループウェアシステムやアプリケーションについて、容
易に開発、修正、拡張などを行うことができる。このた
め、優れた柔軟性・拡張性が得られる。

【００２６】請求項２の発明は、請求項１記載のグルー
プウェアシステムにおいて、前記エージェントがどのよ
うな動作を実行できるかを記述したアクション知識と、
前記グループウェアシステム上の事実について記述した
インフォ知識と、エージェントに要求を与えるための手
段と、与えられた要求を、予め決められたゴールの形式
に変換する手段と、前記アクション知識部及びインフォ
知識部を参照することによって、前記ゴールを達成する
ため前記エージェントが実行すべき動作列としてプラン
を生成する手段と、前記プランを実行することによって
前記エージェントの動作を実現する手段と、を備えたこ
とを特徴とする。請求項１０の発明は、請求項２の発明
を方法という見方からとらえたもので、請求項９記載の
情報処理方法において、前記エージェントがどのような
動作を実行できるかを記述したアクション知識と、前記
グループウェアシステム上の事実について記述したイン
フォ知識と、を使い、エージェントに要求を与えるため
のステップと、与えられた要求を、予め決められたゴー
ルの形式に変換するステップと、前記アクション知識及
びインフォ知識を参照することによって、前記ゴールを
達成するため前記エージェントが実行すべき動作列とし
てプランを生成するステップと、前記プランを実行する
ことによって前記エージェントの動作を実現するステッ
プと、を含むことを特徴とする。請求項２，１０の発明
では、エージェントがどのような種類の動作を実行でき
るかをアクション知識として記述し、アプリケーション
が参照すべきファイルの所在などの情報はインフォ知識
として記述しておく。そして、ワークフローなどのアプ
リケーションを実行するときは、これら知識を参照する
ことで、具体的な情報処理の状況に応じたプランを作成
し、このようなプランに基づいてエージェントが動作す
る。これによって、あるノードでファイルが見つかった
かどうかなど、具体的な状況に応じてエージェントの動
作を自律的かつ柔軟に制御でき、自律性や柔軟性といっ
たエージェントの利点をグループウェアシステムのため
に活用することができる。また、アクション知識やイン
フォ知識はいくつものノード上で、互いに分割して記述
したり分散配置できる。このため、グループウェアシス
テム全体を把握している開発者だけでなくユーザや担当
者なども、それら知識のうちそれぞれの視点や権限に対
応する部分を操作することで、それぞれが関与するレベ
ルで、開発、修正、拡張などを部分的、局所的、動的に
行なうことが可能となる。

【００２７】請求項３の発明は、請求項２記載のグルー
プウェアシステムにおいて、前記アクション知識は、グ
ループウェアシステム全体又は前記グループウェアアプ
リケーションにおいて統一的に利用される動作を表し予
め決められたアクセス権がなければ編集できない第１の
アクション知識を含むことを特徴とする。請求項３の発
明では、前記アクション知識のなかに、グループウェア
システム全体で共通の動作や、個々のアプリケーション
でいつも行うべき動作にかかわる統一的な第１のアクシ
ョン知識を記述しておくことで、グループウェアシステ
ム全体や個々のアプリケーションの柔軟性を保ちなが
ら、動作の一貫性を確保することができる。このような
統一的なアクション知識としては、例えば、必要な情報
や資源の存在するノードに移動して実行を継続するとい
ったエージェントの動作などが考えられる。また、アク
セス権に基づくアクセス制御の具体的な手法は自由であ
るが、例えば、あらかじめ決められた管理用ノードから
のみ記述したり、変更できるようにしておくことが考え
られる。

【００２８】請求項４の発明は、請求項２又は３記載の
グループウェアシステムにおいて、前記インフォ知識
は、グループウェアシステム全体又は前記グループウェ
アアプリケーションにおいて統一的に参照される情報を
表し予め決められたアクセス権がなければ編集できない
第１のインフォ知識を含むことを特徴とする。請求項４
の発明では、前記インフォ知識のなかに、グループウェ
アシステム全体から共通して参照する情報や、個々のア
プリケーションでいつも参照するような統一的な第１の
インフォ知識を記述しておくことで、グループウェアシ
ステム全体や個々のアプリケーションにおける情報処理
が依拠する情報を統一することができる。このような統
一的なインフォ知識としては、例えば、そのグループウ
ェアシステムを使っている組織の役職や階級構造がどう
なっているかといった組織情報や、どの個人がどのよう
な役職や権限を持っているかといった個人情報などが考
えられる。

【００２９】請求項５の発明は、請求項３又は４記載の
グループウェアシステムにおいて、前記アクション知識
は、前記アクセス権がなくても編集できる第２のアクシ
ョン知識を含むことを特徴とする。請求項１１の発明
は、請求項５の発明を方法という見方からとらえたもの
で、請求項１０記載の情報処理方法において、前記アク
ション知識は、グループウェアシステム全体又はアプリ
ケーションにおいて統一的に利用される動作を表し予め
決められたアクセス権がなければ編集できない第１のア
クション知識と、前記アクセス権がなくても編集できる
第２のアクション知識と、を含むことを特徴とする。請
求項５，１１の発明では、特別なアクセス権のないユー
ザや担当者なども、ある目的に対して定型的に行える手
続きといった個人的に持っているようなローカルな第２
の情報をアクション知識として追加、変更することで、
エージェントの動作に反映させることができる。このた
め、そのような分散して存在するノウハウ情報をグルー
プウェアシステム全体やアプリケーションで有効に活用
することが可能となる。

【００３０】請求項６の発明は、請求項４又は５記載の
グループウェアシステムにおいて、前記インフォ知識
は、前記アクセス権がなくても編集できる第２のインフ
ォ知識を含むことを特徴とする。請求項１２の発明は、
請求項６の発明を方法という見方からとらえたもので、
請求項１０又は１１記載の情報処理方法において、前記
インフォ知識は、グループウェアシステム全体又はアプ
リケーションにおいて統一的に参照される情報を表し予
め決められたアクセス権がなければ編集できない第１の
インフォ知識と、前記アクセス権がなくても編集できる
第２のインフォ知識と、を含むことを特徴とする。請求
項６，１２の発明では、特別なアクセス権のないユーザ
や担当者なども、ある問題について詳しい担当者のリス
トなど、個人がローカルに保有するノウハウのような情
報をインフォ知識として追加、変更することで、エージ
ェントの動作に反映させることができる。このため、そ
のような分散して存在するノウハウ情報をグループウェ
アシステム全体やアプリケーションで有効に活用するこ
とが可能となる。

【００３１】請求項７の発明は、請求項１から６のいず
れか１つに記載のグループウェアシステムにおいて、エ
ージェントと、グループウェアシステム外部のシステム
とを接続するための第１の接続手段を備えたことを特徴
とする。請求項７の発明では、エージェントと、グルー
プウェアシステム外部のシステムとがプロトコル変換な
どで接続されるので、そのような外部のシステムを利用
することでグループウェアシステムを容易に導入した
り、応用範囲を広げることが容易になる。なお、グルー
プウェアシステム外部のシステムとは、グループウェア
システムと同じコンピュータネットワーク又はそのよう
なコンピュータネットワークと接続された他のコンピュ
ータネットワーク上に存在するハードウェア及びソフト
ウェアであり、オペレーティングシステム、メモリやデ
ータファイルなどの各種資源、アプリケーションソフト
ウェアなどを含む概念である。

【００３２】請求項８の発明は、請求項１から７のいず
れか１つに記載のグループウェアシステムにおいて、エ
ージェントと、個々のノードごとのユーザ環境とを接続
するための第２の接続手段を備えたことを特徴とする。
請求項１３の発明は、請求項９から１２のいずれか１つ
に記載の情報処理方法において、エージェントと、個々
のノードごとのユーザ環境とを接続するためのステップ
を含むことを特徴とする。請求項８，１３の発明では、
エージェントと、個々のノードごとのユーザ環境とが、
プロトコル変換などで接続される。このため、個々のユ
ーザがノードごとにそれぞれ違った種類のツールを使用
しているようなコンピュータネットワーク上にグループ
ウェアシステムを導入する場合でも、個々のユーザはそ
れ以前の使い慣れたツールなどを使い続けることがで
き、グループウェアシステムの導入が容易になるだけで
なく、グループウェアシステムの使い勝手が向上する。
なお、ユーザ環境とはノードごとにユーザが使用してい
るハードウェア及びツール、即ちソフトウェアやその設
定を含む概念である。

【００３３】

【発明の実施の形態】以下、本発明の実施の形態（以下
「本実施形態」という）について図面を参照しながら説
明する。なお、本発明は、周辺機器を持つコンピュータ
を、ソフトウェアで制御することによって実現されるこ
とが一般的と考えられる。この場合、そのソフトウェア
は、この明細書の記載にしたがった命令を組み合わせる
ことで作られ、上に述べた従来技術と共通の部分には従
来技術で説明した手法も使われる。また、そのソフトウ
ェアは、プログラムコードだけでなく、プログラムコー
ドの実行のときに使うために予め用意されたデータも含
む。

【００３４】そして、そのソフトウェアは、ＣＰＵ、コ
プロセッサ、各種チップセットといった処理装置、キー
ボードやマウスといった入力装置、メモリやハードディ
スク装置といった記憶装置、ディスプレイやプリンタと
いった出力装置などの物理的な資源を活用することで本
発明の作用効果を実現する。

【００３５】但し、本発明を実現する具体的なソフトウ
ェアやハードウェアの構成はいろいろ変更することがで
きる。例えば、ソフトウェアの形式には、コンパイラ、
インタプリタ、アセンブラなどいろいろあり、外部との
情報をやり取りするにも、フロッピーディスクなどの着
脱可能な記録媒体、ネットワーク接続装置などいろいろ
考えられる。また、本発明を実現するソフトウェアやプ
ログラムを記録したＣＤ−ＲＯＭのような記録媒体は、
単独でも本発明の一態様である。さらに、本発明の機能
の一部をＬＳＩなどの物理的な電子回路で実現すること
も可能である。

【００３６】以上のように、コンピュータを使って本発
明を実現する態様はいろいろ考えられるので、以下で
は、本発明や実施形態に含まれる個々の機能を実現する
仮想的回路ブロックを使って、本発明と実施形態とを説
明する。なお、説明で使うそれぞれの図について、それ
以前の図で説明したものと同じ要素や同じ種類の要素に
ついては同じ符号を付け、説明は省略する。

【００３７】〔１．構成〕 〔１−１．全体的構成〕本実施形態は、ネットワークで
接続された複数のノード上で、複数のグループウェアア
プリケーションを実行するグループウェアシステムであ
り、具体的には、各グループウェアアプリケーションの
動作が、ノード上で自律的に動作するエージェントの動
作として記述されている。すなわち、本実施形態は、そ
れらエージェントがノード間を移動しながら自律的に動
作することで、環境の変化に対しても柔軟に対応しなが
ら、与えられた目的を達成する知的エージェントシステ
ムである。

【００３８】ここで、ノードとは、エージェントが移動
する単位となる場所であり、物理的な１つのコンピュー
タ上に１つだけ設定することもできるし、１つのコンピ
ュータ上に理論的な管理単位として複数設定することも
できる。また、ネットワークは、インターネットのよう
な外部の広域ネットワークに接続することによって開放
型ネットワークとしてもよいし、そのような外部の広域
ネットワークに接続せず、クローズド（閉鎖的）なネッ
トワークとしてもよい。

【００３９】そして、図１は、本実施形態のグループウ
ェアシステムが複数のノードＮを含む状態を示すと共
に、そのうちのある１つのノードについて、具体的な構
成を示す機能ブロック図である。すなわち、ネットワー
クＮＷによって互いに接続され各ノードＮは、エージェ
ントの活動を支えるものであり、それぞれエージェント
システムやエージェントシステム部と呼ぶことができ
る。

【００４０】具体的には、個々のノードは、要求投入部
１と、ゴール変換部２と、エージェント管理部３と、エ
ージェント部４と、知識記述部５と、コマンド実行部６
と、通信管理部７と、を備えていて、これらの各部分
は、メモリ１０１、ＣＰＵ１０２、補助記憶装置１０３
の他、図示しない入出力制御回路や入出力装置、ネット
ワーク接続装置などの働きによって実現される。

【００４１】このうち、要求投入部１は、情報処理の目
的となる要求をエージェントに対して与えるためのイン
タフェースで、利用者はエージェントにこのような要求
を与えることで、目的の達成を依頼することが可能であ
る。また、ゴール変換部２は、要求投入部１から与えら
れた要求を、エージェントシステム内部で参照されるゴ
ールの形式に変換する手段である。このゴールは、エー
ジェントが活動する目的を予め決められた形式で表した
ものである。

【００４２】また、エージェント管理部３は、ノード上
でエージェントを生成したり消滅させたり、ノード間で
のエージェント移動といったエージェントの管理を行う
部分である。また、エージェント部４は、ノード上のエ
ージェントの動作を実現する部分であり、プランニング
部４１と、プラン実行部４２と、エージェント制御部４
３と、を備えている。

【００４３】このうちプランニング部４１は、知識記述
部５を参照することによって、前記ゴールを達成するた
めエージェントが実行すべき動作列として、各種コマン
ドを使ったプランを生成する手段である。また、プラン
実行部４２は、生成されたプランに含まれるコマンドか
ら次に実行するものを選ぶ部分であり、エージェント制
御部４３は、このようなプランの生成と実行やノード間
での移動といったエージェントの動作全体を制御する手
段である。

【００４４】また、コマンド実行部６は、プラン実行部
４２が選んだコマンドを実行する部分であり、具体的に
は、グループウェアアプリケーションのための、各種動
作、外部アプリケーションとの接続や、ユーザインタフ
ェースの役割を果たす。すなわち、エージェントとは、
一連のプランが生成され実行されることで実現されるソ
フトウェア上の単位である。

【００４５】〔１−２．知識記述部の具体的な構成〕ま
た、知識記述部５は、エージェントがグループウェアア
プリケーションとしての動作を行うために必要な情報
を、エージェント部４が参照可能な知識の形式で記述し
た部分であり、アクション知識部５１とインフォ知識部
５２とを備えている。このうちアクション知識部５１
は、エージェントがどのような動作を実行できるかを記
述した部分で、具体的には、ある状態から別の状態へと
状態変化を起こすために行うべき動作を種類ごとに記述
したものである。このアクション知識部５１は、プラン
を構成する部品としてどのような種類の動作を使えるか
を示す一覧表としての役割を果たし、また、個々のグル
ープウェアアプリケーションがどのような動作によって
実現されるかは、アクションの組み合わせによって記述
される。

【００４６】また、インフォ知識部５２は、上に述べた
ようなプランやプラン中の動作をエージェントが実行す
るときに参照する情報を記述したもので、グループウェ
アシステム上の事実に関する知識を表すものである。こ
のようなグループウェアシステム上の事実としては、具
体的には例えば、エージェントが移動可能な活動領域が
どのコンピュータ上にあるかや、目的のファイルがどの
コンピュータ上にあるかといった内容が考えられる。

【００４７】さらに、アクション知識部５１は、グルー
プウェア共通アクション知識部５１１と、ノウハウアク
ション知識部５１２という２つの部分に分けられる。こ
のうちグループウェア共通アクション知識部５１１は、
グループウェアシステム全体又はアプリケーションにお
いて統一的に利用される動作を表し予め決められた開発
者や管理者用のアクセス権がなければ編集できないもの
であり、前記第１のアクション知識を記述した部分であ
る。一方、ノウハウアクション知識部５１２は、そのよ
うなアクセス権がなくても編集できるものであり、前記
第２のアクション知識を記述した部分である。

【００４８】また、インフォ知識部５２は、グループウ
ェア共通インフォ知識部５２１と、ノウハウインフォ知
識部５２２という２つの部分に分けられる。このうちグ
ループウェア共通インフォ知識部５２１は、グループウ
ェアシステム全体又はアプリケーションにおいて統一的
に参照される情報を表し予め決められた上記アクセス権
がなければ編集できないもので、前記第１のインフォ知
識を記述した部分である。一方、ノウハウインフォ知識
部５２２は、そのようなアクセス権がなくても編集でき
るもので、前記第２のインフォ知識を記述した部分であ
る。

【００４９】ここで、図２は、上に説明したようなアク
ション知識部５２に記録されたアクション知識の構成を
表す図である。すなわち、個々のアクション知識は、ア
クションすなわち動作の種類ごとに、アクションの内容
を記述したアクション部の他に、事前条件を記述した事
前条件部と、事後条件を記述した事後条件部と、を備え
ている。

【００５０】このうち事前条件とは、そのアクションを
実行するために必要な条件であり、事後条件とは、その
アクションの実行によって達成される条件である。そし
て、プランニングすなわちプラン生成では、ユーザから
投入されたゴールを事後条件として達成するアクション
を探し、そのアクションの事前条件を、事後条件として
達成する別のアクションを探す、という手順が繰り返さ
れる。そして、現在の状態が事前条件を満たすために直
ちに実行を開始できるアクションが発見された時点で、
現在の状態からゴールに至るアクションの道筋が完成し
たことになり、このようなアクションの列がプランとな
る。

【００５１】〔１−３．コマンド実行部の具体的な構
成〕また、コマンド実行部６には、外部システム接続部
６１と、ユーザ環境接続部６２と、が設けられている。
このうち外部システム接続部６１は、エージェントと、
グループウェアシステム外部のシステム（外部システム
８と呼ぶ）とを接続するための第１の接続手段であり、
また、ユーザ環境接続部６２は、エージェントと、個々
のノードごとのユーザ環境９とを接続するための第２の
接続手段である。

【００５２】〔２．作用〕以上のように構成された本実
施形態の作用として、ワークフローアプリケーションを
実行する手順を示す。この例におけるワークフローアプ
リケーションは、グループウェアアプリケーションの一
種であり、具体的には、何人かのユーザ間で予め決めら
れた一定の作業手続き（ワークフローと呼ぶ）を実行す
るためのアプリケーションである。ここでは、ユーザか
ら発せられた図書の購買申請の要求に対して、本実施形
態のグループウェアシステムが、申請のための一連の手
続きを代行することで、ユーザの要求を達成する例を示
す。

【００５３】〔２−１．一般的な手順〕まず、図３は、
本実施形態における処理手順を示すフローチャートであ
る。すなわち、ユーザが、グループウェアシステムに対
する要求を要求投入部１から入力すると、入力された要
求はゴール変換部２によってゴールに変換される。この
ようなユーザの要求に基づくゴールはユーザゴールと呼
ばれ（ステップ１）、以下単に「ゴール」とも呼ぶ。続
いて、ノードのエージェント管理部３はエージェントを
生成し（ステップ２）、生成されたエージェントには上
に述べたユーザゴールが与えられる。

【００５４】生成されたエージェントの動作はエージェ
ント部４が中心となって実現されるが、具体的には、ま
ず、エージェント制御部４３による制御に基づいて、プ
ランニング部４１が、与えられたゴールに基づいてプラ
ンニングを行う。このプランニングは、与えられたゴー
ルを達成するためにエージェントが実行すべき動作列、
すなわちプランを生成する処理であり（ステップ３）、
このようなプランニングを行うプランニング部４１は、
プランナとも呼ばれる。

【００５５】ここで、このようなプランニング（プラン
生成）の具体的な内容を説明する。すなわち、プラン
は、エージェントが目的すなわちゴールを達成するため
のアクションの系列であり、プランナは、アクション知
識部５１とインフォ知識部５２とを参照しながらこのよ
うなプランを生成する。

【００５６】ここで、図２は、アクション知識の事前条
件部と事後条件部とを下から上に順次結び付けること
で、ゴールに至る動作列を生成する状態を示している。
すなわち、プランは、この図２中の矢印に示されるよう
に、ゴールを達成するアクション知識を繋ぎ合わせてい
くことで実現される。

【００５７】つまり、アクションの事前条件、および事
後条件には、インフォ知識又はゴールのうちいずれか一
方が記述される。そして、ある事後条件を達成するアク
ションの事前条件に、達成されていないインフォ知識が
ある場合、つまり、事前条件に該当するインフォ知識が
表しているファイルの所在などの条件が未確定や未確認
といった場合、そのアクションはプランとして採用され
ない。また、ある事後条件を達成するアクションの事前
条件に未達成のゴールが記述されている場合、さらにそ
のゴールを達成する、すなわちそのゴールを事後条件と
して持つアクションがプランの候補として採用される。

【００５８】このように、アクションの事前条件は、達
成されているインフォ知識を通して別のアクションと接
続されるか、未達成のゴールを通してそのゴールを達成
するための別のアクションと順次接続されてゆく。

【００５９】このようにプランが生成されると、エージ
ェント制御部４３は、次に（図３）、プラン実行部４２
を制御することによってそのプランの実行を行わせる
（ステップ４）。プランの構成単位であるアクションは
コマンドとも呼ばれ、プラン実行部４２は、プランの記
述内容に基づいて次に実行するアクションすなわちコマ
ンドを順次選択し、そのコマンドをコマンド実行部６に
渡すことによって、プランを実行させる。

【００６０】そして、このコマンド実行部６は、プラン
に含まれる各コマンドに対応した動作をすることで、ア
プリケーション実行のための各種動作、外部アプリケー
ションとの接続や、ユーザインタフェースの役割を果た
す。すなわち、実行すべきコマンドを渡されたコマンド
実行部６は、渡されたコマンドの種類やパラメータに応
じた動作を実行し、外部システム８やユーザ環境９との
間で情報のやり取りが必要な場合は、外部システム接続
部６１やユーザ環境接続部６２が、それら外部システム
８やユーザ環境９との間で、プロトコル変換やメッセー
ジの送受信を行うことでそのような情報のやり取りを実
現する。

【００６１】また、プランに移動のコマンドが含まれて
いて、そのような移動のコマンドを実行することになっ
た場合は、その旨がプラン実行部４２からエージェント
制御部４３を経てエージェント管理部３に知らされ、エ
ージェント管理部３は、通信管理部７を通じて、移動先
のノードとメッセージをやり取りしたり、エージェント
のプランや内部状態などの情報を転送することで、ノー
ド間でのエージェントの移動を実現し（ステップ５）、
プランの実行は、移動先のノードで継続される（ステッ
プ４）。このようなプランニングとプランの実行はユー
ザから投入されたゴールが達成されるまで、繰り返し行
われる。

【００６２】そして、プランの実行において、未達成の
サブゴールの達成がコマンドとして与えられた場合、ま
たはプランの実行に失敗した場合には、エージェントは
指定されたサブゴール、もしくは実行失敗時に達成しよ
うとしていたゴールに対して再度プランニングを行う
（ステップ３）。

【００６３】このようなプランニングとプラン実行によ
って、ユーザから与えられたゴールが達成されると、エ
ージェントの実行は終了する（ステップ６）。すなわ
ち、このように自律的・知的な動作を行うエージェント
システムでは、複数のコンピュータが接続されたネット
ワーク環境において、エージェントソフトウェアが知識
を参照することで自らの動作を生成し、自律的に実行を
行い、環境の変化に対しても、柔軟に対応することが可
能なグループウェアシステムの構築が可能となる。

【００６４】〔２−２．具体例の内容〕次に、上に説明
したような手続きの具体例を示す題材として、本実施形
態におけるネットワーク上のノードの環境を図４に示
す。この例は、複数のノードＵ，Ａ，Ｂ，Ｃ，Ｄをネッ
トワークＮで接続したもので、具体的には、利用者の利
用しているノードであるノードＵ、各種データベースＤ
Ｂ及び業務システムサーバＳが接続されているノード
Ａ、グループウェアアプリケーションに関する知識が多
く管理されているノードＢ、課長の利用しているノード
であるノードＣ、部長の利用しているノードであるノー
ドＤを含んでいる。

【００６５】〔２−３．購買申請の入力〕図３に示した
このようなネットワークにおいて、まず、ノードＵにお
いて、利用者から、図書の購買に関する申請の要求がゴ
ールの形式に変換されて投入される。なお、購買申請を
行うには、申請する図書について、図書名、ＩＳＢＮ番
号、出版社名、価格の情報が必要であり、投入されるゴ
ールにはこれらの情報の全て、もしくは一部分が与えら
れる。

【００６６】〔２−４．サブゴールへの分割〕このよう
にゴールを与えられ生成されたエージェントは、次に、
当該ゴールを達成するためにプランニングを行う。ここ
で、図５は、ユーザにより投入されたゴールに対して採
用され、プランの生成に用いられるアクション記述の例
である。すなわち、投入されたゴール“購買申請”は、
このようなアクション記述に基づいた初期プランニング
によって、“図書情報の完成”、“依頼者情報の完
成”、“承認者による承認”、“購買申請登録”といっ
た複数のサブゴールに分割され、これら個々のサブゴー
ルについても、次に例示するようにゴールとして、さら
にプラン生成に投入されることによって、それぞれのサ
ブゴールを達成するコマンドからなるプランが生成され
る。 サブゴール“図書情報の完成”投入 サブゴール“依頼者情報の完成”投入 サブゴール“承認者による承認”投入 サブゴール“購買申請登録”投入 なお、このような初期プランニングで使うアクション知
識は、グループウェア共通アクション知識部５１１に記
述されたものである。このように、本実施形態では、ユ
ーザから与えられた要求やゴールの種類に対応したアク
ション知識を使ってプランを生成し、エージェントが個
々のプランにしたがって動作することで、いろいろな種
類のアプリケーションの動作が実現される。

【００６７】〔２−５．図書情報の完成〕このように複
数のサブゴールを含むプランが生成されると、エージェ
ントは生成されたプランの実行を開始し、プランの初め
のコマンドであるサブゴール“図書情報の完成”投入を
実行し、当該サブゴールの達成を試みる。また、図６
に、このサブゴール“図書情報の完成”の達成のため
に、プランナによって採用されるアクション知識の例を
示す。このアクション知識も、グループウェア共通アク
ション知識部５１１に記述されたものであるが、例え
ば、図５に示した購買申請の基本的な手順は変更しない
が、図書情報の具体的な項目は変更できるようにする場
合、図６に示したアクション知識はノウハウアクション
知識部５１２に記述しておくことが考えられる。

【００６８】この図６の例では、図書名やＩＳＢＮ番号
などそれぞれの情報が取得されているという４つのゴー
ルが、アクション知識の事前条件として記述されてい
る。このような個々のゴールは次のような意味を持つ。
つまり、当該情報が、すでに取得済み、すなわちユーザ
から投入されたゴール中で与えられている場合は、事前
条件に記述された該当するゴールはすでに達成済みとな
るため、そのゴールの達成のためにさらにプランニング
を行う、すなわちアクション知識を採用する必要はな
い。

【００６９】一方、事前条件に記述されたサブゴールで
未達成のものが存在する場合、すなわち取得されていな
い情報が存在する場合、その項目をデータベースに問い
合わせて取得するというプランが生成される。このよう
な不足項目の取得のためには、図書データベースのある
ノードにエージェントが存在していて、そのノードでデ
ータベース検索を行う必要がある。また、そのために、
データベースのあるノードにエージェントが存在してい
る、という事前条件を満たしている必要がある。

【００７０】そして、このようなデータベースのあるノ
ードの情報は、データベースアクセスを行うアクション
知識のための事前条件に対応する形式で、インフォ知識
として記述されている。なお、あるノードにいるという
事後条件を達成するためのアクションは、“そのノード
へ移動する”というアクションであり、このアクション
の事前条件は存在しない、すなわち無条件に実行の対象
となる。

【００７１】例えば、出版社情報が取得されていない場
合のプランニングでは、図７に示すように、アクション
知識が採用される。ここで、アクション知識ＡＫの事前
条件では上に述べたデータベースが存在するノード名が
変数Ｘとして表現され、データベースが具体的にどのノ
ードに存在するかという情報は、このアクション知識Ａ
Ｋに対応づけられるインフォ知識ＩＫに基づいた具体的
な変数値として変数Ｘに代入される。なお、このインフ
ォ知識部ＩＫは、グループウェア共通インフォ知識部５
２１に記述されたものである。

【００７２】すなわち、図７のようにインフォ知識が対
応づけられる場合、変数Ｘには［Ａ］が代入される。こ
のようにプランニングが行われた結果、以下のプランが
生成される。 ノードＡに移動 出版社名を検索 このようなプランの生成と実行は図３の動作フローに示
されるように、繰り返し行われる。そして、生成された
プラン中に、サブゴールの達成要求が含まれている場
合、または、実行中のプランが失敗した場合には、エー
ジェントは指定されたサブゴール、もしくは実行失敗時
に達成しようとしていたゴールに対して再度プランニン
グを行う（ステップ３）。

【００７３】すなわち、上に説明したようにサブゴール
“出版社名の取得”を達成したエージェントは、次に、
サブゴール“価格情報の取得”投入のコマンドの実行を
行い、当該サブゴール達成のためのプランニングを行
う。

【００７４】ここで、当該ゴールが達成されていない、
すなわち価格情報が取得されていない場合、該当する知
識を参照することで、そのゴールを達成するためのプラ
ンを生成する。この時点では、エージェントは（図
４）、上に述べたように出版社名を検索するために既に
データベースＤＢが存在するノードＡに移動済である。
このため、データベースＤＢのあるノードＡにエージェ
ントが存在するという事前条件は達成されているので、
生成されるプランには移動のコマンドは含まれずに、 価格を検索 といった意味のコマンドが記述されることとなる。

【００７５】ところで、以上の説明で述べたデータベー
ス検索のプランは、コマンド実行部６によって実行され
るが、実行されるプランやプランに記述された個々のコ
マンドに基づいて行われる具体的な動作、ここでは、業
務データベースシステムにアクセスを行い、図書名、Ｉ
ＳＢＮをキーとして、価格の検索を行う動作は、コマン
ド実行部６に記述される。つまり、コマンド実行部６
は、プランというプログラムを実行するインタプリタに
あたり、プラン中のどのようなコマンドが具体的にどの
ような動作を意味するかは、インタプリタの動作として
記述される。

【００７６】例えば、上に説明したようにプラン中に検
索のコマンドが含まれている場合、コマンド実行部は外
部アプリケーション、この場合はデータベースＤＢのデ
ータベースマネジメントシステム（ＤＢＭＳ）などに対
して、ＳＱＬなど予め決められた形式で問い合わせるこ
とで検索を行う。このため、データベースシステムの変
更やアクセス方式の変更などがあった場合は、このコマ
ンド実行部６のうち、特に検索コマンドを実行する手順
の部分だけを変更すればよく、ワークフローの動作記
述、すなわち、例えばグループウェア共通アクション知
識部５１１に記述されているような知識記述の部分への
変更は必要ない。

【００７７】〔２−６．依頼者情報の完成〕以上のよう
にして、図５や図６に示したサブゴール“図書情報の完
成”を達成したエージェントは、次に、サブゴール“依
頼者情報の完成”投入のコマンドを実行し、当該サブゴ
ール達成のためのプランニングを行う（ステップ３）。

【００７８】但し、ユーザが最初のゴールを投入すると
きに依頼者情報など必要な情報を全て与えていた場合
は、既にゴールは達成されているので、ここではプラン
は生成されない。一方、不足情報があった場合は、上に
述べた図書情報と同様の手続きでプランが生成され、サ
ブゴールが達成される。

【００７９】〔２−７．承認者による承認〕さらに、エ
ージェントは、図４に示した次のサブゴール“承認者に
よる承認”投入のコマンドの実行を行い、当該サブゴー
ルの達成を試みる。このゴール“承認者による承認”
は、承認ルーチンに関する知識、すなわち誰の承認が必
要かといった情報を必要とする。

【００８０】この点については、グループウェアのアプ
リケーションの多くでは、個々の人間の名前とその位置
は、その組織、役職によって関連づけられており、ワー
クフロー全体で統一的に利用される情報の一つである。
このような情報は、グループウェア共通インフォ知識部
５２１として記述しておくことで、様々なワークフロー
アプリケーションに対応するエージェントによって、統
一的に参照、利用可能である。

【００８１】なお、このような情報は、必ずしもエージ
ェントが現在プランニングを行っているノードに存在す
るとは限らない。そのような場合は、上に述べた説明
で、データベース検索のためにデータベースが存在した
ノードへ移動したのと同様に、目的の情報があるノード
への移動を含むプランが作成され、実行される。すなわ
ち、この場合は、インフォ知識を参照することで、目的
の情報、資源がネットワーク上のどのノードにあるかを
調べ、そのノードに移動するコマンドを含むプランが作
成される。

【００８２】例えば、エージェントは現在はノードＡ上
にいるが（図４）、“承認者による承認”ゴールに関す
る知識を持っているノードがここではノードＢであった
場合、その旨はインフォ知識の形で表されている。この
場合、ノードＡにおいては、このインフォ知識を参照す
ることでノードＢへの移動を含むプランが生成され、こ
のプランにしたがって移動した後に再度、当該サブゴー
ルに対するプランニングを行う。すなわち、この場合に
生成されるプランは、 ノードＢに移動 サブゴール“承認者による承認”投入 となる。

【００８３】そして、このように移動していった先のノ
ードＢには、図８に示すように、承認者はどのような種
類の役職者でなければならないかという対応関係、ある
役職名と具体的な個人名との対応関係、個人名とその位
置、すなわちその人はどのノードを使っているかの対応
関係を表すインフォ知識と、およびそれらを利用するア
クション知識が保存されているものとする。

【００８４】つまり、上に述べたように、エージェント
がまだノードＡにいて移動先をノードＢに決める時点で
は、このような役職に関するインフォ知識がどのノード
にあるかというインフォ知識を参照したが、インフォ知
識同士の間ではこのように、あるインフォ知識が、別の
インフォ知識がどのノードにあるかを表すといった階層
的な関係を作ることができる。

【００８５】そして、移動先のノードＢにおいては、役
職に関する上に述べたようなインフォ知識が参照される
結果、必要な役職「課長」に就任している個人「田中」
氏がノードＣを使っているという事実が判明するので、
ゴール“承認者による承認”を達成するため、再プラン
によってさらに以下のプランが生成される。

【００８６】ノードＣに移動 サブゴール“承認”投入 が生成される。

【００８７】そして、このプランに基づいてノードＢか
らノードＣに移動したエージェントは、移動先のノード
Ｃにて“承認”ゴールについて、該当する知識を参照し
てプランニングを行い、 承認依頼ウインドウを開き依頼情報表示 承認情報取得 といったプランを生成、実行する。

【００８８】なお、このような承認のためのそれぞれの
実行コマンドはＧＵＩとして実現することができるが、
個々のノードでは、そのノードのユーザがどのようなユ
ーザ環境、すなわちユーザインタフェースのアプリケー
ションを利用していても、ユーザ環境接続部６２がエー
ジェントとユーザ環境との間で、プロトコル変換やメッ
セージ交換を行うことで両者を接続する。このため、個
々のユーザ環境に応じて、ポップアップウインドウによ
る承認の依頼や、音声による承認の依頼などを切り替え
てプランを実行し、目的を達成することが可能である。

【００８９】〔２−８．承認ルーチンを変更する例〕こ
こで、本実施形態において以上に説明したようなアプリ
ケーションを導入して運用している場合に、導入後に承
認担当者、ここでは課長がその承認方針の変更を試みる
場合を考える。本実施形態では、このような課長の承認
に関する知識は、ノウハウアクション知識部５１２やノ
ウハウインフォ知識部５２２として、課長のノードにの
み存在し、その担当者、すなわち課長が関与することの
できる範囲の単位で、分割して存在している。そして、
ノウハウアクション知識部５１２やノウハウインフォ知
識部５２２は、課長のノードからであれば、開発者用の
特別なアクセス権がなくても編集することができる。

【００９０】このため、他ノードの知識や、購買請求フ
ローの全体を意識することなく、当該ノードのアクショ
ン知識、インフォ知識のみを変更することによって、権
限の委譲や集中といった変更を行うことができる。

【００９１】このような変更を行おうとする場合、従来
のワークフローシステムでは、そのアプリケーション動
作のための情報は、開発者や管理者によって集中、一括
管理されているため、上記のような場合に、課長のよう
なワークフローシステムの一部に組み込まれているよう
な人が自己の判断で動的に対応することは困難であっ
た。

【００９２】これに対して本実施形態では、部長の承認
も必要であるように、例えば課長の判断によって特定の
承認ルーチンを変更する場合、図８に示したようにそれ
まで記述されていたアクション知識はノウハウインフォ
知識部５２２として記述しておき、その事前条件の部分
に、サブゴール“部長による承認”などを追加すればよ
い。

【００９３】このような変更を行うと、“承認者による
承認”ゴールに対して生成されるプランには、追加され
たサブゴール“部長による承認”のために生成された部
分が加わることになり、具体的には以下のように変化す
る。 ノードＤに移動 サブゴール“承認”投入 ノードＣに移動 サブゴール“承認”投入 この場合、エージェントは上記プランの実行を行う結
果、ノードＣに移動して課長の承認を求めるだけでな
く、ノードＤにも移動し、ノードＤを使っている部長の
承認を求めるため、サブゴール“承認”投入のコマンド
の実行を行い、当該サブゴール達成のためのプランとし
て、以下を生成し、部長の承認も得る動作を行うことに
なる。 承認依頼ウインドウを開き依頼情報表示 承認情報取得 〔２−９．例外動作〕ここで、本実施形態における例外
動作の例として、部長が不在のために、承認動作が行え
なかった場合を考える。ここでは、部長の承認を求める
ためのコマンドについては、ノードの表示装置に承認を
要求するウインドウなどの表示を行ってから、１分以上
入力がなかった時にノードの使用者が不在時とみなさ
れ、コマンドの実行を失敗と判断するように設定されて
いたとする。

【００９４】このようにコマンドの実行が失敗と判断さ
れた場合、エージェントはコマンド、すなわちプランの
実行に失敗したことを検知し、現在達成しようとしてい
たゴール、ここでは“承認”を取得する。そしてエージ
ェントは、そのゴールを達成するための他のプランの生
成を試みる。この際、先に生成され、実行に失敗したア
クションはプランナによって排除され、先とは異なるア
クションを持ったプランが生成される。

【００９５】具体的には、例えば、“承認”ゴール達成
のための異なるアクション知識として、部長が不在であ
るときなど承認不可能な場合のために、代理による承認
のための知識を記述しておき、実行失敗時にもこのよう
な知識にしたがって、次善策となるそれ以降のプランを
生成することで実行を継続させることが考えられる。

【００９６】この点についても、従来のワークフローシ
ステムにおいては、このような例外動作についても、開
発者が事前に全体を把握して想定しなければならず、さ
らに、このように予め想定して記述していた場合にしか
対応することができなかった。これに対して、本実施形
態では、そのような例外動作は、事前に全体で把握され
ている必要はなく、関与している担当者のレベルで局所
的に定義することが可能である。すなわち、上に述べた
ような代理承認の権限者を、それぞれの部署ごとのルー
ルなどに基づいて、ノウハウインフォ知識部５２２とし
て記述しておけばよい。

【００９７】〔２−１０．購買請求〕引き続いて、課長
などによる承認の実行のためのコマンドの実行に成功し
たエージェントは、サブゴール“承認者による承認”を
達成し、ユーザゴールのために生成されたプラン（図
５）の最後のコマンドであるサブゴール“購買申請登
録”投入を実行することによって、当該サブゴール達成
のためのプランニングを行い、このプランニングでは、
該当する知識を参照することで以下のプランを生成す
る。 ノードＡに移動 購買申請の登録 この場合、データベースアクセスと同様に、生成された
プランに含まれる個々のコマンドに対応した処理が行わ
れることで、例えば外部の業務システムサーバＳと接続
され、購買申請の登録が行われる。

【００９８】なお、この業務システムサーバＳのよう
に、グループウェアシステム外部のシステムとエージェ
ントが情報をやり取りする際は、外部システム接続部６
１が、そのような外部システム８とエージェントとの間
でデータ形式やプロトコルの変換、メッセージの交換と
いった接続のための処理を行う。以上で、ユーザから与
えられたゴール“購買申請”のためのプランの実行は完
了し、ユーザの要求が達成される。

【００９９】〔２−１１．別の具体例〕また、他の具体
例として、本実施形態のグループウェアシステムを、例
えば会議スケジュールの調整を行う別のアプリケーショ
ンに適用することも考えられる。この例では、ユーザは
ある問題について会議を開催するにあたって、会議のス
ケジュールを調整するというゴールをエージェントに投
入するものとする。このように投入されるゴールには、
“エージェント技術”というような、会議の議題を表す
分野名が含まれる。

【０１００】そして、エージェントはこの様なゴールに
基づくプランニングを行うとき、分野名と個人名のリス
トからなるノウハウインフォ知識部５２２、すなわちそ
の分野に関連のある担当者のリストを参照し、それらの
メンバを会議参加者候補、すなわちスケジュール調整の
対象とする。

【０１０１】つまり、スケジュール調整では、それぞれ
の会議参加者のノードに移動し、その参加者が利用して
いるスケジュール管理ツールや、スケジュールデータに
対し、コマンド実行部を介してアクセスを行い、全対象
者のスケジュールを取得したのち、日程調整アプリケー
ションの提供されているノードへ移動し、参加者の都合
の合う会議日程を設定し、そのスケジュールをそれぞれ
の参加者の利用しているスケジュールツールに対して登
録する。

【０１０２】このようなスケジュールの調整過程で、各
参加者のノードの知識を参照するが、ある参加者が、議
題に対応する分野に詳しい人間のリストを個人のノウハ
ウとして持っているような場合、それを自分が使ってい
るノードでノウハウインフォ知識部５２２として記述し
ておく。これによって、本実施形態では、エージェント
がこのノウハウインフォ知識５２２を参照し、取得した
リストを会議参加者のリストに追加して動作を継続する
ことができる。

【０１０３】〔３．効果〕以上のように、本実施形態で
は、個々のアプリケーションやその機能に対応するエー
ジェントの動作を設定したり変更することによって、グ
ループウェアシステムやアプリケーションについて、容
易に開発、修正、拡張などを行うことができる。このた
め、優れた柔軟性・拡張性が得られる。

【０１０４】また、本実施形態では、エージェントがど
のような種類の動作を実行できるかをアクション知識と
して記述し、アプリケーションが参照すべきファイルの
所在などの情報はインフォ知識として記述しておく。そ
して、ワークフローなどのアプリケーションを実行する
ときは、これら知識を参照することで、具体的な情報処
理の状況に応じたプランを作成し、このようなプランに
基づいてエージェントが動作する。これによって、ある
ノードでファイルが見つかったかどうかなど、具体的な
状況に応じてエージェントの動作を自律的かつ柔軟に制
御でき、自律性や柔軟性といったエージェントの利点を
グループウェアシステムのために活用することができ
る。また、アクション知識やインフォ知識はいくつもの
ノード上で、互いに分割して記述したり分散配置でき
る。このため、グループウェアシステム全体を把握して
いる開発者だけでなくユーザや担当者なども、それら知
識のうちそれぞれの視点や権限に対応する部分を操作す
ることで、それぞれが関与するレベルで、開発、修正、
拡張などを部分的、局所的、動的に行なうことが可能と
なる。

【０１０５】また、本実施形態では、前記アクション知
識のなかに、グループウェアシステム全体で共通の動作
や、個々のアプリケーションでいつも行うべき動作にか
かわる統一的なグループウェア共通アクション知識を記
述しておくことで、グループウェアシステム全体や個々
のアプリケーションの柔軟性を保ちながら、動作の一貫
性を確保することができる。このような統一的なアクシ
ョン知識としては、例えば、必要な情報や資源の存在す
るノードに移動して実行を継続するといったエージェン
トの動作などが考えられる。また、アクセス権に基づく
アクセス制御の具体的な手法は自由であるが、典型的に
は、あらかじめ決められた管理用ノードからのみ記述し
たり、変更できるようにしておくことが望ましい。

【０１０６】また、本実施形態では、前記インフォ知識
のなかに、グループウェアシステム全体から共通して参
照する情報や、個々のアプリケーションでいつも参照す
るような統一的なグループウェア共通インフォ知識を記
述しておくことで、グループウェアシステム全体や個々
のアプリケーションにおける情報処理が依拠する情報を
統一することができる。このような統一的なインフォ知
識としては、上の例に述べたように、そのグループウェ
アシステムを使っている組織の役職や階級構造がどうな
っているかといった組織情報や、どの個人がどのような
役職や権限を持っているかといった個人情報などが考え
られる。

【０１０７】また、本実施形態では、特別なアクセス権
のないユーザや担当者なども、ある目的に対して定型的
に行える手続きといった個人的に持っているようなロー
カルなノウハウ情報をアクション知識として追加、変更
することで、エージェントの動作に反映させることがで
きる。このため、そのような分散して存在するノウハウ
情報をグループウェアシステム全体やアプリケーション
で有効に活用することが可能となる。

【０１０８】さらに、本実施形態では、特別なアクセス
権のないユーザや担当者なども、ある問題について詳し
い担当者のリストなど、個人がローカルに保有するノウ
ハウのような情報をインフォ知識として追加、変更する
ことで、エージェントの動作に反映させることができ
る。このため、そのような分散して存在するノウハウ情
報をグループウェアシステム全体やアプリケーションで
有効に活用することが可能となる。

【０１０９】また、本実施形態では、エージェントと、
グループウェアシステム外部のシステムとがプロトコル
変換などで接続されるので、そのような外部のシステム
を利用することでグループウェアシステムを容易に導入
したり、応用範囲を広げることが容易になる。なお、グ
ループウェアシステム外部のシステムとは、上の例では
図４に示した業務システムサーバＳを示したが、この種
のものには限定されず、例えば、グループウェアシステ
ムと同じコンピュータネットワーク又はそのようなコン
ピュータネットワークと接続された他のコンピュータネ
ットワーク上に存在するハードウェア及びソフトウェア
であり、オペレーティングシステム、メモリやデータフ
ァイルなどの各種資源、アプリケーションソフトウェア
などを広く含む概念である。

【０１１０】また、本実施形態では、エージェントと、
個々のノードごとのユーザ環境とが、プロトコル変換な
どで接続される。このため、個々のユーザがノードごと
にそれぞれ違った種類のツールを使用しているようなコ
ンピュータネットワーク上にグループウェアシステムを
導入する場合でも、個々のユーザはそれ以前の使い慣れ
たツールなどを使い続けることができ、グループウェア
システムの導入が容易になるだけでなく、グループウェ
アシステムの使い勝手が向上する。

【０１１１】〔４．他の実施形態〕なお、本発明は上記
実施形態に限定されるものではなく、次に例示するよう
な他の実施形態も包含するものである。例えば、本発明
は、上記のワークフローアプリケーションや会議スケジ
ュール調整アプリケーションに限定されるものではな
く、どのような分野のグループウェアシステムにも適用
することができる。また、上記実施形態の図１では、ア
クション知識とインフォ知識、コマンド実行部を１つの
ノード上に配置した例を示したが、これらは複数のノー
ド上に分散して配置することももちろん可能である。

【０１１２】また、スケジュール調整を行って、予定を
空けた日を利用して、出張を入れるために、その申請書
を回すなど、複数のアプリケーションを組み合わせるこ
とも可能である。また、アクション知識は、必ずしもグ
ループウェア共通アクション知識とノウハウアクション
知識に分ける必要はなく、同様にインフォ知識も、必ず
しもグループウェア共通インフォ知識とノウハウインフ
ォ知識に分ける必要はない。

【０１１３】

【発明の効果】以上のように、本発明によれば、柔軟性
・拡張性に優れたグループウェアシステム、情報処理方
法及び情報処理用ソフトウェアを記録した記録媒体が得
られる。

【図面の簡単な説明】

【図１】本発明の実施形態の構成を示す機能ブロック
図。

【図２】本発明の実施形態におけるアクション知識の構
成を示す概念図。

【図３】本発明の実施形態における処理手順を示すフロ
ーチャート。

【図４】本発明の実施形態において具体例として取り上
げたコンピュータネットワークの構成を示す図。

【図５】本発明の実施形態において、ユーザゴールとア
クション知識に基づいて複数のサブゴールが得られる状
態を示す概念図。

【図６】本発明の実施形態において、１つのサブゴール
からさらに複数のサブゴールが得られる状態を示す概念
図。

【図７】本発明の実施形態において、アクション知識の
事前条件部に、インフォ知識に基づいた情報が代入され
る状態を示す概念図。

【図８】本発明の実施形態において、アクション知識の
事前条件部に、インフォ知識に基づいた情報が代入され
る状態を示す概念図。

【図９】従来のグループウェアシステムの一例を示す構
成図。

【符号の説明】

１…要求投入部 ２…ゴール変換部 ３…エージェント管理部 ４…エージェント部 ５…知識記述部 ５１…アクション知識部 ５１１…グループウェア共通アクション知識部 ５１２…ノウハウアクション知識部 ５２…インフォ知識部 ５２１…グループウェア共通インフォ知識部 ５２２…ノウハウインフォ知識部 ６…コマンド実行部 ６１…外部システム接続部 ６２…ユーザ環境接続部 ８…外部システム ９…ユーザ環境 Ｎ…ノード ＮＷ…ネットワーク

───────────────────────────────────────────────────── フロントページの続き (72)発明者 大須賀 昭彦 神奈川県川崎市幸区柳町70番地 株式会社 東芝柳町工場内 Ｆターム(参考） 5B045 DD18 GG01 5B049 AA01 CC31 EE28

Claims (14)

【特許請求の範囲】
1. 【請求項１】 ネットワークで接続された複数のコンピ
   ュータ上で、複数のグループウェアアプリケーションを
   実行するグループウェアシステムにおいて、 前記コンピュータ上で自律的に動作するエージェントを
   備え、 前記各グループウェアアプリケーションの動作は、前記
   エージェントの動作として記述されたことを特徴とする
   グループウェアシステム。
2. 【請求項２】 前記エージェントがどのような動作を実
   行できるかを記述したアクション知識と、 前記グループウェアシステム上の事実について記述した
   インフォ知識と、 エージェントに要求を与えるための手段と、 与えられた要求を、予め決められたゴールの形式に変換
   する手段と、 前記アクション知識部及びインフォ知識部を参照するこ
   とによって、前記ゴールを達成するため前記エージェン
   トが実行すべき動作列としてプランを生成する手段と、 前記プランを実行することによって前記エージェントの
   動作を実現する手段と、 を備えたことを特徴とする請求項１記載のグループウェ
   アシステム。
3. 【請求項３】 前記アクション知識は、グループウェア
   システム全体又は前記グループウェアアプリケーション
   において統一的に利用される動作を表し予め決められた
   アクセス権がなければ編集できない第１のアクション知
   識を含むことを特徴とする請求項２記載のグループウェ
   アシステム。
4. 【請求項４】 前記インフォ知識は、グループウェアシ
   ステム全体又は前記グループウェアアプリケーションに
   おいて統一的に参照される情報を表し予め決められたア
   クセス権がなければ編集できない第１のインフォ知識を
   含むことを特徴とする請求項２又は３記載のグループウ
   ェアシステム。
5. 【請求項５】 前記アクション知識は、前記アクセス権
   がなくても編集できる第２のアクション知識を含むこと
   を特徴とする請求項３又は４記載のグループウェアシス
   テム。
6. 【請求項６】 前記インフォ知識は、前記アクセス権が
   なくても編集できる第２のインフォ知識を含むことを特
   徴とする請求項４又は５記載のグループウェアシステ
   ム。
7. 【請求項７】 エージェントと、グループウェアシステ
   ム外部のシステムとを接続するための第１の接続手段を
   備えたことを特徴とする請求項１から６のいずれか１つ
   に記載のグループウェアシステム。
8. 【請求項８】 エージェントと、個々のノードごとのユ
   ーザ環境とを接続するための第２の接続手段を備えたこ
   とを特徴とする請求項１から７のいずれか１つに記載の
   グループウェアシステム。
9. 【請求項９】 ネットワークで接続された複数のコンピ
   ュータ上で、複数のグループウェアアプリケーションを
   実行する情報処理方法において、 前記コンピュータ上で自律的に動作するエージェントを
   使い、 前記各グループウェアアプリケーションの動作は、前記
   エージェントの動作として記述されたことを特徴とする
   情報処理方法。
10. 【請求項１０】 前記エージェントがどのような動作を
    実行できるかを記述したアクション知識と、 前記グループウェアシステム上の事実について記述した
    インフォ知識と、 を使い、 エージェントに要求を与えるためのステップと、 与えられた要求を、予め決められたゴールの形式に変換
    するステップと、 前記アクション知識及びインフォ知識を参照することに
    よって、前記ゴールを達成するため前記エージェントが
    実行すべき動作列としてプランを生成するステップと、 前記プランを実行することによって前記エージェントの
    動作を実現するステップと、 を含むことを特徴とする請求項９記載の情報処理方法。
11. 【請求項１１】 前記アクション知識は、 グループウェアシステム全体又はアプリケーションにお
    いて統一的に利用される動作を表し予め決められたアク
    セス権がなければ編集できない第１のアクション知識
    と、 前記アクセス権がなくても編集できる第２のアクション
    知識と、 を含むことを特徴とする請求項１０記載の情報処理方
    法。
12. 【請求項１２】 前記インフォ知識は、 グループウェアシステム全体又はアプリケーションにお
    いて統一的に参照される情報を表し予め決められたアク
    セス権がなければ編集できない第１のインフォ知識と、 前記アクセス権がなくても編集できる第２のインフォ知
    識と、 を含むことを特徴とする請求項１０又は１１記載の情報
    処理方法。
13. 【請求項１３】 エージェントと、個々のノードごとの
    ユーザ環境とを接続するためのステップを含むことを特
    徴とする請求項９から１２のいずれか１つに記載の情報
    処理方法。
14. 【請求項１４】 ネットワークで接続された複数のコン
    ピュータ上で、複数のグループウェアアプリケーション
    を実行するための情報処理用ソフトウェアを記録した記
    録媒体において、 そのソフトウェアは前記コンピュータに、前記コンピュ
    ータ上でエージェントを自律的に動作させ、 前記各グループウェアアプリケーションの動作は、前記
    エージェントの動作として記述されたことを特徴とする
    情報処理用ソフトウェアを記録した記録媒体。