JPH1185524A - 情報処理装置及び方法並びに情報処理プログラムを記録した記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 エージェントが活動する態様を多様化するこ
とによって、環境や回線が不安定でも安定して動作する
情報処理の技術を提供する。 【解決手段】 プランニング手段１１１Ｌがエージェン
トが実行すべきプランをノード１０１Ｌ上で生成し、判
断手段１１４Ｌは、生成されたプランが他のノードにお
ける処理が必要な不確実知識を用いている場合に、ノー
ド１０１Ｌとネットワーク１００Ｎとを接続する通信回
線の信頼性が低いか高いかを判断し、エージェント管理
手段１０４Ｌが、前記信頼性が低い場合に、プランを実
行するエージェントを、不確実知識に関する処理のため
に他のノードに移動させ、協調プロトコル実現手段１１
３Ｌは、前記信頼性が高い場合に、他のノード上のエー
ジェントに不確実知識に関する処理を依頼し、その後、
エージェント実行手段１１２が、生成されたプランを実
行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク上に
分散して存在する情報を複数のエージェントを用いて処
理する技術の改良に関するもので、特に、回線及び環境
が不安定な場合でも安定して動作するように改良した情
報処理装置及び方法並びに情報処理プログラムを記録し
た記録媒体を提供するものである。

【０００２】

【従来の技術】近年、コンピュータを中心とした情報処
理システムの技術においては、ダウンサイジングの進行
やインターネットなどのネットワーク環境の整備によ
り、ネットワーク上の分散システムを主流としてシステ
ムを構築する傾向がある。特に、インターネットのよう
な広域ネットワークと接続されたネットワークは開放型
ネットワークと呼ばれ、このような開放型ネットワーク
では環境のオープン化がより進展している。環境のオー
プン化が進展すると、ネットワーク上に存在する各種の
データや機能が外部の広域ネットワークと密接な関係を
持つため、外部の広域ネットワークとの相互作用によっ
て、ネットワーク上に存在する各種のデータや機能が影
響を受けたり変化する可能性が増大する。

【０００３】このような開放型ネットワーク環境では、
ソフトウェアに対してメッセージやコマンドなどで送ら
れる要求や、あるいはソフトウェアの構成そのものが事
前に予期しない形で変化することが想定される。例え
ば、ソフトウェアに対する要求が、外部の広域ネットワ
ークから取得できる特定のファイルを前提としたものに
変化する可能性がある。また、特定の機能を実現するフ
ァイルが、外部からの侵入に対するセキュリティが充実
したサーバーに移動される可能性も考えられる。

【０００４】こうした変化に対し、システム稼働後にシ
ステムを途中停止させることなく、また、人手を煩わせ
ることなく適応する柔軟なソフトウェアの構築が求めら
れている。そのような柔軟なソフトウェアは、開放型の
環境において、より柔軟かつ安定した情報サービスをユ
ーザに提供することを可能にする。

【０００５】上記のような柔軟なソフトウェアを実現す
る技術としては、近年、エージェント指向技術が注目さ
れている。エージェント指向技術は、エージェントと呼
ばれるソフトウェアの単位を用いてシステムを構築する
技術であり、エージェントは周囲の環境の変化に対応し
て自律的に動作するものである。すなわち、開放型ネッ
トワーク環境においても、自律的に動作することによっ
て環境の変化に柔軟に対応するエージェントの試みが数
多くなされている。

【０００６】例えば、特開平７−１８２１７４では、分
散型のコンピュータシステムにおいて、エージェントが
ノード間で転送されるようなリモートプログラミングの
実施方法を開示している。図１０は、リモートプログラ
ミングを実施する装置の構成図の一例である。この例で
は、エージェントはノード上のプロセスとして実現さ
れ、プロセスすなわちエージェントの動作は「プラン」
と呼ばれるプログラムによって予め与えられている。な
お、プランは、エージェントプロセスの動作を記述する
一連の命令として記述され、プランの単位となる命令は
「インストラクション」と呼ばれる。また、エージェン
トがもともと存在するノードをローカルノード、エージ
ェントが移動する先のノードをリモートノードと呼び、
それぞれ図１０中で記号８００Ｌ及び８００Ｒで示す。

【０００７】エージェントを他のノードに移動させる処
理は、プラン中に記述しておく特定の種類のインストラ
クション（以下「goオペレーション」と呼ぶ）によって
指示される。ここで、goオペレーションの具体的な使用
例を示す。例えば、プランの中に、特定のファイルをロ
ーカルノード８００Ｌで探すインストラクションを記述
し、発見に失敗した場合の動作として、エージェントを
リモートノード８００Ｒに移動するgoオペレーション
と、移動後にリモートノード８００Ｒで再度同じファイ
ルを探すインストラクションを記述する。

【０００８】この場合、プランはまずローカルノード８
００Ｌで実行される。実行するプランはエージェント情
報記憶手段８０１Ｌに予め格納しておく。エージェント
が活動する際の内部状態すなわちワークエリアは、エー
ジェントに関する情報として、エージェント情報記憶手
段８０１Ｌ内にプランと共に格納される。

【０００９】ローカルノード８００Ｌでエージェントが
活動を開始すると、解釈実行手段８０２Ｌがプラン中の
インストラクションを順次解釈実行しながらエージェン
トの内部状態を更新してゆく。そして、ローカルノード
８００Ｌでプランを実行中に、ファイルの発見に失敗す
ると、プラン中のインストラクションとしてgoオペレー
ションを解釈実行することになる。そして、このgoオペ
レーションの解釈実行において、エージェント管理手段
８０４Ｌは次のようなエージェント転送処理を行う。

【００１０】すなわち、まずエージェント管理手段８０
４Ｌが、ネットワーク８００Ｎを通じてリモートノード
８００Ｒ上のエージェント管理手段８０４Ｒと通信す
る。この通信において、上記プランの内容と、上記goオ
ペレーションを解釈実行することとなった時点における
エージェントの内部状態がリモートノード８００Ｒに転
送される。そして、これらを転送されたリモートノード
８００Ｒでは、エージェント管理手段８０４Ｒがエージ
ェント情報記憶手段８０１Ｒにこれらを格納し、解釈実
行手段８０２Ｒを起動して上記インストラクションの解
釈実行を続行する。これによって、転送元のローカルノ
ード８００Ｌで行なわれていたのと同様のエージェント
の動作が、リモートノード８００Ｒ上で継続されること
になる。

【００１１】このように、特開平７−１８２１７４によ
れば、発見すべきファイルがローカルノードからリモー
トノードに移転されていたような状況の変化があって
も、上記のような柔軟な対応が可能となる。なお、この
従来技術では、オペレーティングシステム及びハードウ
ェアが異なるノード間でも、プランに用いる文法とエー
ジェントの内部状態の表現形式を統一しておけば、エー
ジェントをノード間で移動させてプランを続行できると
いう長所も存在する。

【００１２】また、Etzioni らの提案した情報処理方法
（参考文献：Oren Etzioni and Daniel Weld "A Softbo
t-Based Interface to the Internet" (Communications
ofACM) ）では、ftp やtelnetといった通常のネット
ワーク機能を利用しながらも、これらの機能を動的に選
択し、しかも動作中に収集した情報に基づいて柔軟にバ
ックトラックするような情報処理方法を開示している。
ここで、バックトラックは、各機能を試行錯誤的に利用
することである。この情報処理方法によれば、システム
の各時点での状態に対応して柔軟な動作が可能である。
このような柔軟な動作は、プランニングと呼ばれる技術
によって実現される。

【００１３】また、特開平７−６１４２や特開平８−７
７０９０では、マルチエージェント協調システム及びそ
の方法を開示している。マルチエージェント協調システ
ムは、複数のエージェントにそれぞれエージェント間で
情報を交換する機能を持たせることによってエージェン
ト間の協調を実現し、柔軟かつ効率的に情報処理を行な
うようにしたシステムである。

【００１４】

【発明が解決しようとする課題】しかしながら、上記の
ような従来技術には次のような問題点が存在していた。
まず、特開平７−１８２１７４が開示するリモートプロ
グラミングの実施方法では、エージェントの動作を定め
るプランは、インストラクションを用いて、利用者がす
べて予め記述しておかなければならない。特に、エージ
ェントを移動させるgoオペレーションにおいては、エー
ジェントの移動先ノードをネットワークにおける識別子
で指定する必要がある。ここで、エージェントの移動先
ノードとはエージェントが転送される先のノードであ
り、識別子はノード名などで表される。

【００１５】しかし、開放型ネットワークにおいては、
ノード名のような、ネットワークを構成する各ノードに
関する情報が時々刻々と変化し、しかもそのような変化
を随時監視しておくことは困難である。また、このよう
な変化に対応するためには、移動先ノードのノード名の
変化をあらかじめ監視しておくだけでなく、変化に応じ
てインストラクションを変更するという煩雑な操作が必
要となる。このように、特開平７−１８２１７４の技術
でも、開放型ネットワークにおける変化への柔軟な対応
には限界が存在していた。

【００１６】また、Etzioni らの情報処理方法では、ネ
ットワークを利用するための手段としてftp やtelnetと
いった通常のネットワーク機能を利用している。しか
し、これらの通信プロトコルの利用だけでは遠隔ノード
の情報へ円滑にアクセスすることは困難である。例え
ば、ftp やtelnetでは、一連のデータ交換が開始されて
から完了するまで、ノード間の通信ルートは物理的にも
論理的にも安定して維持される必要がある。このため、
ネットワークを通じてアクセスしている途中でそのよう
なルートが一時的に切断された場合は、その間のアクセ
スが不可能になったり、認証手続きやファイルの転送な
どが最初からやり直しになる、などの問題が生じる。

【００１７】さらに、特開平７−６１４２や特開平８−
７７０９０などのマルチエージェント技術でも、次のよ
うな問題点が存在していた。まず第一は、回線の信頼性
に関する問題である。すなわち、開放型ネットワークは
様々な種類のマシン（コンピュータ）や接続回線から構
成される、という特徴を持つ。例えば、最近ではいわゆ
るモバイルコンピューティングの普及に伴い、いわゆる
携帯端末の使用が増大している。携帯端末は、利用者が
自由に持ち運べる小型コンピュータで、ネットワークと
の接続には携帯電話やＰＨＳ端末などの無線回線が介在
することが多い。また、このような携帯端末では、通信
途中で電池切れのために通信が不可能になる可能性もあ
る。このような電源や無線接続に由来する制限のため、
携帯端末はネットワークと接続する回線の信頼性が低い
ノードということができる。

【００１８】しかしながら、特開平７−６１４２や特開
平８−７７０９０など従来のマルチエージェント技術
は、信頼性の高い回線を利用してエージェント間で頻繁
に通信できることを前提としているため、上記のように
信頼性の低い回線を含むネットワークでは十分な性能を
発揮することができない。このため、回線の信頼性が低
い場合でも、安定して動作する情報処理の技術が求めら
れていた。

【００１９】また、これらマルチエージェント技術が有
している第二の問題点は、環境の安定性に関するもので
ある。すなわち、従来のマルチエージェント技術は、少
なくとも一連の協調手続きが進行している間は、知識の
内容などの環境が安定していてみだりに変更されないこ
とを前提として構成されている。この結果、開放型ネッ
トワークのように予期せぬ変更が頻繁に起こり得るよう
な環境では、やはり十分に機能することは期待できな
い。このため、状況変化があっても安定して動作する情
報処理の技術が求められていた。

【００２０】さらに、従来のマルチエージェント技術で
は、どのエージェント間の通信も内容に関係なく平等に
処理されていた。しかし、通信を行なうエージェントや
通信内容によって優先度は異なるため、エージェント間
の協調動作を柔軟に制御するためには、優先度に応じて
扱いが異なるような通信の手段を備えることが望まれ
る。

【００２１】本発明は、上記のような従来技術の問題点
を解決するために提案されたもので、その目的は、エー
ジェントが活動する態様を多様化することによって、環
境や回線が不安定でも安定して動作する情報処理の技術
を提供することである。また、本発明の他の目的は、エ
ージェント間での通信の手段を拡充することによって、
エージェント間の協調動作を柔軟に制御できる情報処理
の技術を提供することである。

【００２２】

【課題を解決するための手段】上記の目的を達成するた
め、請求項１の発明は、複数のノードを含むネットワー
ク上で、複数のエージェントが情報交換によって協調動
作する情報処理装置において、エージェントが実行すべ
きプランを生成するプランニング手段と、生成されたプ
ランの中に、他のノードにおける処理が必要なプランが
含まれている場合に、前記プランが作成されたノードと
ネットワークとを接続する通信回線の信頼性を判断する
判断手段と、前記信頼性が低い場合に、前記プランを実
行するエージェントを、他のノードに移動させる移動手
段と、前記信頼性が高い場合に、他のノードの１または
複数のエージェントに前記プランの実行に関する依頼を
行う協調手段と、生成されたプランを実行する実行手段
と、を備えたことを特徴とする。請求項６の発明は、請
求項１の発明を方法の観点から把握したもので、複数の
ノードを含むネットワーク上で、複数のエージェントが
情報交換によって協調動作する情報処理方法において、
エージェントが実行すべきプランを生成する工程と、生
成されたプランの中に、他のノードにおける処理が必要
なプランが含まれている場合に、前記プランが作成され
たノードとネットワークとを接続する通信回線の信頼性
を判断する工程と、前記信頼性が低い場合に、前記プラ
ンを実行するエージェントを他のノードに移動させる工
程と、前記信頼性が高い場合に、他のノードの１または
複数のエージェントに前記プランの実行に関する依頼を
行う工程と、生成されたプランを実行する工程と、を含
むことを特徴とする。請求項８の発明は、請求項１及び
６の発明を、情報処理プログラムを記録した記録媒体の
観点から把握したものであって、複数のノードを含むコ
ンピュータのネットワーク上で、複数のエージェントを
情報交換によって協調動作させるための情報処理プログ
ラムを記録した記録媒体において、前記情報処理プログ
ラムはコンピュータに、エージェントが実行すべきプラ
ンを生成させ、生成されたプランの中に、他のノードに
おける処理が必要なプランが含まれている場合に、前記
プランが作成されたノードとネットワークとを接続する
通信回線の信頼性を判断させ、前記信頼性が低い場合
に、前記プランを実行するエージェントを他のノードに
移動させ、前記信頼性が高い場合に、他のノードの１ま
たは複数のエージェントに前記プランの実行に関する依
頼を行わせ、生成されたプランを実行させることを特徴
とする。

【００２３】請求項１，６，８の発明では、複数のエー
ジェント間において、例えば契約ネットプロトコルや黒
板機能など標準的なエージェント間協調の手法を用いて
協調動作を行うことによって、ネットワーク上に分散す
る情報を効率的に活用する。そして、各ノードについて
判明している状況変化に関する情報は自動や手動で随時
更新しておき、各エージェントの動作を定めるプラン
は、更新されている情報を用いて、与えられた目的に応
じて作成する。これによって、まず、エージェントの動
作が環境変化に応じて変化するので、安定した情報処理
が実現される。

【００２４】また、捕捉しにくい状況変化の可能性は、
プラン中に不確実知識として組み込む。不確実知識は、
他のノードで何らかの処理を要する知識で、例えば、特
定のノードで特定のファイルが得られる「かもしれな
い」などである。このような不確実知識に関する処理で
は、ネットワーク上移動とエージェント間協調という２
種類の手法を効果的に使い分ける。すなわち、プランが
生成されたノードをネットワークに接続する回線の信頼
性が低い場合は、エージェント自体を他のノードに移動
して不確実知識に関する処理を行なう。この手法では、
不確実知識に関する処理を行う間、もとのノードとの間
で頻繁に通信を行う必要がないので、回線の信頼性が低
くても安定した動作が実現される。

【００２５】一方、回線の信頼性が高い場合は、不確実
知識に関する処理を他のノードのエージェントに確認を
依頼するというエージェント間協調が用いられる。この
手法では、エージェント自体の移動処理に要する一連の
処理が不要であるから、不確実知識に関する処理を迅速
に行うことできる。このように、２種類の手法を、回線
の信頼性に応じて使い分けることによって、回線の信頼
性が高ければ確認が迅速に行われる一方、回線の信頼性
が低くても安定した情報処理が行われる。特に、回線の
信頼性及び環境の不安定という２つの問題が、ネットワ
ークに同時に存在する場合でも、前記のようなプラン生
成と確認する手法の使い分けとの組み合わせによって、
効率的で安定した情報処理が実現される。

【００２６】請求項２の発明は、請求項１記載の情報処
理装置において、エージェント間で交換される情報を、
情報の優先度に応じて格納するための階層を複数備えた
黒板手段と、上位の階層に格納された情報を、下位の階
層に格納された情報より優先的に処理する階層黒板管理
手段と、エージェント間で交換される情報に基づいて、
エージェント間における協調プロトコルを実現するため
の協調プロトコル実現手段と、を備えたことを特徴とす
る。また、請求項７の発明は、請求項２の発明を方法の
観点から把握したもので、請求項６記載の情報処理方法
において、エージェント間で交換される情報を、情報の
優先度に応じて格納するための階層を複数備えた黒板を
用い、上位の階層に格納された情報を、下位の階層に格
納された情報より優先的に処理する工程と、エージェン
ト間で交換される情報に基づいて、エージェント間にお
ける協調プロトコルを実現するための工程と、を含むこ
とを特徴とする。

【００２７】請求項２，７の発明では、黒板が階層的に
構成され、優先度の高い上位の階層に記入した情報の方
が下位の階層に記入された情報よりも優先的に処理され
る。優先的な処理の例は、例えば、下位の階層に記入さ
れた情報は受け取るべきエージェントの側から参照され
るまでは宛先に届かないが、上位の階層に記入された情
報については割り込みなどを用いて宛先のエージェント
に通知を行なうなどである。このような構成によれば、
エージェント間でタスクの実行を依頼しているような場
合、依頼の取り消しや実行失敗の報告のような重要事項
は、一方のエージェントが上位階層に記入すれば、割り
込みなどで優先的に他方へ通知できる。これによって、
必要な場合は相手の動作を変更させたり強制的に終了さ
せることも可能となる。このように、エージェント間で
交換する情報を重要度に応じた階層に記入することによ
って、エージェント間の協調関係を柔軟に制御できるの
で、予期せぬ状況の変化に対応することが容易になる。
また、エージェント単位に優先度を設定しておき、優先
度が高いエージェントが交換する情報ほど高い階層を用
いたり、情報を黒板に入出力する処理も高い階層ほど優
先して行なえば、一層きめ細かな制御も可能となる。

【００２８】請求項３の発明は、請求項１又は２記載の
情報処理装置において、少なくとも１つのノードにおい
て、エージェントが活動するための領域が目的に応じた
複数のフィールドに分割され、プランの生成に用いる知
識が、各フィールドに対応して分割され、分割された各
フィールド及び知識を、対応する目的を持つエージェン
トのために利用させるフィールド管理手段を備えたこと
を特徴とする。請求項３の発明では、各エージェント
は、持っている目的に応じて異なったフィールドで活動
し、プラン生成では自らの目的に対応する知識だけを利
用する。このため、エージェントの間で活動領域の重複
が容易に防止できる。また、プラン生成に用いる知識を
検索する際に余分な知識まで参照する必要がないので、
プラン生成が効率化される。

【００２９】請求項４の発明は、請求項１，２又は３記
載の情報処理装置において、前記協調手段は、契約ネッ
トプロトコルを用いるように構成されたことを特徴とす
る。請求項４の発明では、エージェント間協調を実現す
るために契約ネットプロトコルを用いる。契約ネットプ
ロトコルで処理を他のノードに依頼する場合は、依頼側
ノードの持つ条件と請負側ノードの持つ能力との間で、
入札制による調和が図られる。このため、システム全体
として優れた処理効率が実現される。

【００３０】請求項５の発明は、請求項１，２，３又は
４記載の情報処理装置において、エージェント間で直接
情報交換を行うための通信手段を備えたことを特徴とす
る。請求項５の発明では、エージェント間で直接情報交
換を行なうことができ、この直接の情報交換を黒板など
の間接的な情報交換に代えて用いることもできるし、又
は、間接的な情報交換と並行して用いることもできる。
このため、情報交換の手段が多様化し、エージェント間
の協調をより柔軟に実現する事が可能となる。例えば、
ある２つのエージェントの間でのみ意味があり、他のエ
ージェントと無関係な通信は黒板を経由せずに直接行な
うことができる。これによって、黒板の容量が少なくて
済み、システム全体の通信量も減るので、処理効率が向
上する。

【００３１】

【発明の実施の形態】次に、本発明の実施の形態である
ソフトウェア・エージェント・システム（以下「本シス
テム」という）について、図面を参照して説明する。

【００３２】〔１．構成〕まず、図１は、本システムの
構成を示す機能ブロック図である。本システムは、複数
のノードをネットワークで接続したもので、図１は、代
表例として２つのノード、すなわちローカルノード１０
１Ｌ及びリモートノード１０１Ｒがネットワーク１００
Ｎによって接続されている状態を示している。なお、エ
ージェントの動作を決めるための一つのプランを中心に
みた場合、そのプランが生成されたノードをローカルノ
ードと呼び、そのプランに基づいて処理の依頼又はエー
ジェントの移動が行われる相手先のノードをリモートノ
ードと呼ぶ。

【００３３】ところで、本実施の形態では、２つのノー
ド１０１Ｌ，１０１Ｒは、相互に同様に構成されてい
る。このため、ノードやその構成要素を記号で表すとき
は、ローカルノード１０１Ｌが入出力手段１０３Ｌを持
ち、リモートノード１０１Ｒが入出力手段１０３Ｒを持
つ、というように、ローカルノード１０１Ｌについて
「Ｌ」の文字を、リモートノード１０１Ｒについて
「Ｒ」の文字を付けることによって識別する。また、２
つのノードや、２つのノードの同じ構成要素を総称する
ときは、「入出力手段１０３」のように「Ｌ」又は
「Ｒ」の文字を省略する。

【００３４】〔１−１．プランの生成と実行に関する構
成〕まず、ノード１０１は図１に示すように、ノード上
におけるエージェントの活動のために、エージェント管
理手段１０４、プランニング手段１１１、エージェント
記憶手段１０２及びエージェント実行手段１１２を有す
る。このうち、エージェント管理手段１０４は、エージ
ェントを生成・管理するとともに、役割の終わったエー
ジェントを消滅させる部分である。プランニング手段１
１１は、与えられた目的を達成するためにエージェント
が実行すべきプランを生成する部分である。エージェン
ト記憶手段１０２は、エージェントのためにプランなど
のデータやワークエリアを記憶し提供する部分である。
エージェント実行手段１１２は、請求項１にいう実行手
段に相当するもので、生成されたプランを実行すること
によってエージェントの動作を実現する部分である。な
お、ノード１０１は入出力手段１０３を有し、入出力手
段１０３は、ノード及び各手段の状態を制御するために
コマンドなどの情報を入力したり、その他の情報を入出
力するための部分である。

【００３５】また、ノード１０１は、プラン作成に用い
る情報を格納しておくために、知識格納手段１０８及び
知識管理手段１０９を有する。このうち、知識格納手段
１０８は、プラン作成に用いる手順やデータなどの知識
を格納する部分で、例えば、プラン作成の単位として使
うことができる各種の動作を表す情報、ネットワーク上
で判明しているファイルの所在やノード毎に持っている
機能を表す情報などを予め格納しておく。また、ファイ
ルが他のノードに移動されるかもしれないなど、状況変
化が発生する可能性があるときは、変化し得る事実に関
する知識は、不確実知識の形式で知識管理手段１０９に
格納しておく。また、知識管理手段１０９は、知識格納
手段１０８に格納される知識を管理するとともに、必要
な知識の入出力を行なう部分である。

【００３６】〔１−２．エージェント間での情報交換に
関する構成〕また、ノード１０１は、エージェント間協
調を実現するために、黒板手段１０６、階層黒板管理手
段１０７及び協調プロトコル実現手段１１３を有する。
このうち黒板手段１０６は、エージェント間で交換する
情報を書いておく伝言板の役割を果たす記憶装置で、情
報の優先度に対応する複数の階層を持っている（請求項
２）。また、階層黒板管理手段１０７は、エージェント
間で交換される情報を黒板手段１０６に入出力する部分
である。なお、図２は、黒板手段１０６に設けられた階
層とエージェントとの関係を示す概念図である。

【００３７】ここで、全てのエージェントは黒板手段１
０６のいずれかの階層に対応する存在として生成され
る。具体的には、例えば階層毎に違った数字が割り当て
られていて、生成されるエージェントには、この数字の
いずれかが優先度として付与される。図２の例では、エ
ージェント７０２と７０３が黒板の下位階層に対応して
いるものとする。この場合、エージェント７０２は、エ
ージェント７０３に情報を送ろうとする場合、通常は情
報を下位階層に記入するが、特に重要な情報は、本来対
応している下位階層より上位の、上位階層に記入する。

【００３８】また、階層黒板管理手段１０７は、黒板手
段１０６の上位階層に記入された情報（以下「上位メッ
セージ」という）を、下位階層に記入された情報よりも
優先的に処理する。優先的な処理の例は、情報の宛先に
なっているエージェントが行なっている通常の動作を割
り込みによって中断させ、上位メッセージの処理を行な
わせることである。また、協調プロトコル実現手段１１
３は、階層黒板管理手段１０７を通じた情報交換に基づ
いて、エージェント間における協調プロトコルを実現す
るための部分である。

【００３９】〔１−３．不確実知識に必要な処理に関す
る構成〕ところで、生成されるプランには不確実知識が
含まれる場合がある。なお、不確実知識とは、何らかの
処理が他のノードにおいて実行されることが必要な知識
である。本実施の形態では、このような不確実知識に基
づいて生成されたプランの処理を、他のノードでの１ま
たは複数のエージェントへの依頼と、他のノードへ移動
させる（そのノードではエージェントが消滅）という２
種類の手法を使い分けて行なう。この使い分けによる処
理を行なうため、本システムは次のように構成されてい
る。

【００４０】すなわち、ノード１０１は、上記２種類の
手法のうち、いずれの手法を用いるかを決定するために
判断手段１１４を有する。この判断手段１１４において
は、生成されたプランが不確実知識を用いている場合
に、プランが作成されたノードとネットワークとを接続
する通信回線の信頼性が低いか高いかを判断する。そし
て、回線の信頼性が低い場合はエージェントの移動が行
なわれ、信頼性が高い場合は他のエージェントへの依頼
が行なわれる。

【００４１】このうち移動については、エージェント管
理手段１０４が請求項１にいう移動手段を兼ねていて、
判断手段１１４によって回線の信頼性が低いと判断され
た場合に、プランに対応するエージェントを不確実知識
に関する処理のために他のノードに移動させるように構
成されている。また、各ノード１０１のエージェント管
理手段１０４は、他のノードから移動してくるエージェ
ントを受け入れる処理も行なうように構成されている。

【００４２】また、不確実知識に関する処理を他のエー
ジェントに依頼する場合に関しては、エージェント間で
の協調動作全般に用いられる協調プロトコル実現手段１
１３が請求項１にいう協調手段を兼ねている。すなわ
ち、協調プロトコル実現手段１１３は、判断手段１１４
によって回線の信頼性が高いと判断された場合に、不確
実知識に関する処理を他のノード上のエージェントに依
頼するように構成されている。また、各ノード１０１の
協調プロトコル実現手段１１３は、このような依頼を請
け負う処理も行なうように構成されている。

【００４３】そして、協調プロトコル実現手段１１３
は、処理の依頼に用いる協調プロトコルとして契約ネッ
トプロトコルを用いるように構成されている（請求項
４）。契約ネットプロトコルは、依頼側のエージェント
が依頼する処理を公告し、請け負おうとする各エージェ
ントが入札を行ない、落札者に処理を依頼するプロトコ
ルである。

【００４４】〔１−４．フィールドに関する構成〕ま
た、本システムにおいては、プランニングに必要な知識
の管理を容易にするため、各ノード毎に知識の分類単位
であるフィールドの概念を導入している。すなわち、ノ
ード１０１は、情報処理を効率化するためにフィールド
管理手段１０５を有する。このフィールド管理手段１０
５は、エージェントが活動するためのメモリ空間などの
領域を、目的に応じた複数のフィールドに分割して管理
する部分である（請求項３）。また、フィールド管理手
段１０５は、プランの生成に用いる知識も、各フィール
ドに対応して分割管理するように構成されている。さら
に、フィールド管理手段１０５は、これら分割された各
フィールド及び知識を、対応する目的を持つエージェン
トに利用させるように構成されている。

【００４５】ここで、図３は、本実施の形態におけるエ
ージェント、ノード及びフィールドの関係を示す概念図
である。すなわち、ネットワーク１００Ｎに接続される
ノード１０１は概念的な単位であり、具体的には、図１
に示したエージェント記憶手段１０２〜判断手段１１４
までの構成要素が揃ったものであれば足りる。したがっ
て、ノードはハードウェアとして必ずしも単一のコンピ
ュータやＣＰＵである必要はない。例えば、ネットワー
クに接続された１つの計算機（コンピュータ）上には、
ノードが１つだけ存在してもよいしマルチプロセスシス
テムなどを用いて複数のノードを構成してもよい。ま
た、逆に、複数のコンピュータ上の複数のＣＰＵが分散
処理を行なうことによって一つのノードの機能を実現し
てもよい。

【００４６】そして、一つのノード上では、エージェン
トが活動するための活動領域と、プラン生成に用いる知
識が、複数のフィールドに分割されている。各「フィー
ルド」はそれぞれ異なった目的に応じて設定されるが、
ここでいう「目的」は自由に定めることができる。例え
ば、知識の分野ごとに「目的」が異なると考えてもよい
し、オンライン処理とバッチ処理で「目的」が異なると
考えてもよい。

【００４７】図３では、一つのノード１０１上に複数の
フィールド２０２が存在し、一つのフィールド内にさら
に一つ又は複数のエージェント２０３が存在し活動する
状態を示している。また、図１に知識格納手段１０８を
示したが、知識格納手段１０８内の知識もフィールドに
対応して分割されている。図３では、分割された知識２
０４があるフィールド２０２に対応しているが、他のフ
ィールドには分割された知識のうち他の部分が対応する
ことになる。これらフィールド及び分割された知識は、
フィールド管理手段１０５によって管理される。また、
図３に示すように、フィールドに合わせて黒板１０６Ｆ
を複数設けてもよい。

【００４８】〔１−５．その他の構成〕また、ノード１
０１は、上記各手段の動作を支援するためにプラットフ
ォーム１１０を備えている。プラットフォーム１１０
は、ノードの動作を実現するソフトウェアの基本的な部
分で、ノード内の各資源を管理及び割り当てし、基本的
な入出力の動作を行ない、上記の各手段を管理及び制御
するほか、他のノードとの通信を管理するように構成さ
れている。

【００４９】また、本システムの機能を十分かつ容易に
活用するために、ユーザが情報処理の目的として要求を
記述する場合、プランニングのための知識を予め本シス
テムに入力する場合、エージェント間で交換するために
黒板手段１０６に記入される情報を表現する場合など、
本システム内における情報は専用の記述言語によってデ
ータ形式を統一しておく。

【００５０】〔２．作用及び効果〕上記のような構成を
有する本実施形態では、次のように情報処理が行なわれ
る。なお、下記の処理は、プラットフォーム１１０がノ
ード１０１内の各手段を制御することによって実現され
る。また、フィールドを前提とした処理は、その都度フ
ィールド管理手段１０５が介在して行なわれる。

【００５１】〔２−１．要求の入力〕まず、図４は、本
実施の形態における情報処理の手順を示すフローチャー
トである。本システムに情報処理を行わせる場合は、こ
の図に示すように、まず、利用者が、本システムへの要
求をローカルノード１０１Ｌの入出力手段１０３Ｌから
入力する（ステップ３０１）。要求は、情報処理の結果
として達成したい状態を、予め定められた形式で記述す
ることによって表す。例えば、ネットワーク上に存在す
るソフトウェアコンポーネントに関して、次のような要
求が入力されたものとする。 installed("compo1") installed("compo2") これらの要求は上から順にそれぞれ、「コンポーネン
ト"compo1"がインストール（システムに組み込む）され
た状態」「コンポーネント"compo2"がインストールされ
た状態」を意味する。この２行によって表される要求
は、すなわち「コンポーネント"compo1","compo2" をイ
ンストールせよ」というものである。なお、コンポーネ
ントは、一定の機能を果たすファイルである。

【００５２】〔２−２．エージェントの生成〕要求が入
力されると、エージェント管理手段１０４Ｌが、しかる
べきフィールド内に新たなエージェントを生成し、初期
化の手順を実行する（ステップ３０２）。例えば、"use
r"という名前でエージェントを生成した場合は初期化の
手順として、エージェントを管理するためのリストに名
称"user" を登録したり、エージェント"user"の内部変
数に所定の初期値を設定したり、タイムシェアリングシ
ステムにおけるタイムスライス（ＣＰＵ時間）をエージ
ェント"user"に割り当てるなどの処理を行なう。

【００５３】なお、本システムのように、ノード上に複
数のフィールドが存在するノードでは（図３）、各エー
ジェントはエージェント管理手段１０４による管理のも
とで特定のフィールド内に生成される。そして、これに
続くプランニング手段１１１によるプランニングでは、
知識管理手段１０９がフィールドに対応する知識を読み
出して提供する。他のエージェントと協調動作を行なう
場合は、フィールドに対応する黒板１０６Ｆを通じて他
のエージェントと情報を交換する。

【００５４】〔２−３．プランニング〕エージェントが
生成されるとプランニング手段１１１Ｌは、与えられた
上記の要求をゴールとしてプランニングすなわちプラン
生成を行う（ステップ３０３）０。ここで、「ゴール」
は、情報処理によって達成しようとする状態であり、最
終的な状態だけでなく中間的な状態も含めた概念であ
る。また、「プランニング」はゴールを達成するための
プランを生成する処理をいう。また、「プラン」は、ゴ
ールを達成するためにエージェントが行なうべき一連の
振る舞いを指定した命令の列である。

【００５５】このプランニングは、単位となる動作を組
み合わせることによって行なう。単位となる動作は、エ
ージェント実行手段１１２が実行可能な命令である。こ
れら個々の動作には事前条件と事後条件を定義したう
え、知識管理手段１０９に予め格納しておく。ここで、
事前条件は、その動作を行なう前提である状態であり、
例えば、「あるファイルをコピーする」という動作の事
前条件は「そのファイルが存在する」という状態であ
る。事後条件は、その動作によって産み出される状態で
あり、「あるファイルをコピーする」という動作の事後
条件は「ファイルのコピーが存在する」という状態であ
る。

【００５６】そして、プランニングでは、最終目的であ
るゴールの状態を事後条件として産み出すような動作を
発見し、発見した動作の事前条件を産み出す動作をさら
に発見する、という処理を繰り返すことによって行な
う。この処理は、動作系列を最終目的から現状に向かっ
て逆に辿る処理であるが、辿った結果、動作系列の端が
処理を始める時点すなわち現状で存在しているいずれか
の状態に辿り着けば、現状から最終目的に至る動作の列
の形で、プランが完成したことになる。

【００５７】このようなプランニングの手続きを図５の
フローチャートに具体的に示す。この手続きでは、作業
領域としてゴールリスト及び未達成ゴールリストを用い
る。ゴールリストは、プランに含まれる最終的及び中間
的なゴールを保存しておくリストである。一方、未達成
ゴールリストは、ゴールのうち、現時点において未だ達
成されておらず、また、そのゴールを事後条件として産
み出す動作も見つかっていないものを保存しておくリス
トである。ここで、最終的なゴールは、通常、ユーザが
与えた要求記述であり、最終的なゴールと現在の状態と
の間を埋める中間的なゴールをサブゴールと呼ぶ。

【００５８】なお、一つの最終目的を達成するためのプ
ランであっても、未達成ゴールは複数発生することがあ
る。これは、一つのある状態を事後条件として産み出す
動作が、複数の事前状態を要求する場合がありうるから
である。図６は、生成途中におけるプランの例を示す図
である。この図では、与えられた要求を最終ゴールＧと
して、事後条件Ｃ１でゴールＧで産み出す動作Ｐ１が発
見済みであり、同様に、動作Ｐ１の事前条件Ｃ２を事後
条件Ｃ３として産み出す動作Ｐ２も発見済みである。な
お、このような場合、動作Ｐ１の事前条件Ｃ２と動作Ｐ
２の事後条件Ｃ３は、それぞれ別々の動作の事前条件、
事後条件であって異なる存在であるが、内容が一致して
いるものである。さらに、動作Ｐ２は事前条件Ｃ４，Ｃ
５という２つの事前条件を持っており、一方の事前条件
Ｃ４については、事後条件Ｃ６によって事前条件Ｃ４を
産み出す動作Ｐ３が発見済みである。この状態では、動
作Ｐ２の事前条件Ｃ５と動作Ｐ３の事前条件Ｃ７が、未
達成ゴールリストに登録されており、生成中のプランは
プラン実行開始の時点で揃っている条件すなわち現在の
状態に到達していない。この場合、プランニングの筋道
が枝別れしているので、全ての枝の先端が、現在の状態
Ｓ１〜Ｓ４のいずれかに辿り着くことによって、プラン
が完成する。

【００５９】なお、知識管理手段１０９には、上記のよ
うなプランニングの手順、プランの単位となる動作のほ
かに不確実知識を格納しておく。不確実知識は、既に述
べたように、プランニングを行なっているノード以外の
ノードで、何らかの処理を要する知識であり、例えば、
ある特定のファイルが特定のノードに存在する可能性が
あるが、他のノードに移動されているかも知れず、実際
にアクセスしてみないかぎり確認できない、といった知
識である。

【００６０】図５に示すプランニングの手順では、最初
に、上記の要求をゴールとしてゴールリストに加え、ま
た、このゴールは未達成であるから未達成ゴールリスト
にも加える。そして、各リストを参照することによって
ゴールリスト中に未達成ゴールが存在するか否かを調べ
る（ステップ４０１）。ここで、未達成ゴールが存在す
れば(yes) プランは未完成であるから、未達成ゴールリ
ストからゴールを一つ選択する（ステップ４０２）。次
に、そのゴールが既に満足されているかどうかを知識管
理手段１０９Ｌに問い合わせる（ステップ４０３）。問
い合わせに対する結果として、そのゴールが既に満足さ
れていれば(yes) ステップ４０６へ、満足されていなけ
れば(no)ステップ４０４に進む。

【００６１】ゴールが満足されていない場合、ステップ
４０２で選択されたゴールを満足するような動作が存在
するか否かを知識管理手段１０９Ｌに問い合わせる（ス
テップ４０４）。ここで、問い合わせを受けた知識管理
手段１０９Ｌは、プランの実行が成功する可能性を向上
させるため、まず、知識のうち、不確実知識以外の動作
のデータを優先して検索する。そして、知識管理手段１
０９Ｌは、知識の中にゴールを満足する動作が存在すれ
ば(yes) 、発見された動作をプラン木に追加する（ステ
ップ４０５）。ここで、「プラン木」は、プランの内容
を表すツリー構造データであり、図６に示すように、複
数の事前条件を持つ動作によるプランの枝別れを表すこ
とができる。

【００６２】ステップ４０４において、ゴールを達成す
る動作が存在しない場合は(no)、次善の策として、ゴー
ルが不確実知識で満足されるかどうかを知識管理手段１
０９Ｌに問い合わせる（ステップ４０９）。ゴールを満
足する不確実知識が発見された場合(yes) 、発見された
不確実知識をステップ４０５において、プラン木に追加
する。このようにしてプラン木に追加された動作又は不
確実知識を、以下、「選択動作」という。

【００６３】上記のうち、ステップ４０３でゴールが満
足されていた場合と、ステップ４０４で発見された動作
又はステップ４０９で発見された不確実知識をプラン木
に追加した場合（ステップ４０５）は、現在選択されて
いるゴールはプラン生成の上では達成されている。この
ため、達成したゴールを未達成ゴールリストから削除す
る（ステップ４０６）。また、ステップ４０５で選択動
作をプラン木に追加したときは、追加した選択動作の事
前条件を新たな未達成ゴールとして、未達成ゴールリス
トに追加し（ステップ４０７）、ステップ４０１からの
プランニング手続きを繰り返す。

【００６４】一方、ステップ４０９において知識管理手
段１０９Ｌに問い合わせた結果、不確実知識を用いても
ゴールが達成不可能な場合はプランが完成できない。こ
の場合は、未達成ゴールリストとプラン木をいくつか前
の選択動作を処理した時点の内容まで戻す処理を行なっ
たうえで（ステップ４０８）、ステップ４０１からのプ
ランニングの手続きをやり直す。このように未達成ゴー
ルリストとプラン木を過去の時点に戻す処理をバックト
ラックと呼ぶ。

【００６５】そして、このような逆方向のバックトラッ
クを可能にするためには、未達成ゴールリストとプラン
木を正方向に更新する度に、更新内容の履歴を記録して
おく。このようにすれば、この履歴の内容を逆方向に実
行することによって未達成ゴールリストとプラン木を過
去の状態に戻すことができる。

【００６６】ステップ４０１から４０７に示した一連の
処理を行なった結果、未達成ゴールリストが空であれば
（ステップ４０１）、プランは完成したこととなるの
で、プランニングは終了する。図６に示したプランの完
成状態の例を図７に示す。図６の状態と比べて、図７で
はさらに動作Ｐ４，Ｐ５，Ｐ６が発見された結果、プラ
ン実行を開始する時点で揃っていなければならない全て
の事前条件Ｃ１１，Ｃ１３，Ｃ１４がそれぞれ現在の状
態Ｓ１，Ｓ３，Ｓ４によって満足されている。

【００６７】〔２−４．不確実知識と回線の信頼性に関
する判断〕上記のようなプランニング手順（図４，ステ
ップ３０３）が終了すると、判断手段１１４Ｌが、不確
実知識に関する判断を行なう（ステップ３０４及び３０
８）。すなわち、まず、判断手段１１４Ｌは、プランニ
ングにおいて不確実知識を用いたか否かを判別する（ス
テップ３０４）。不確実知識の使用の有無は、プランニ
ングにおいて不確実知識を用いる度にその旨のデータを
記録しておいて、記録したデータに基づいて判別しても
よいし、作成されたプラン自体を再度検索することによ
って、不確実知識が含まれているか否かを判別してもよ
い。プランに不確実知識が用いられていない場合は、エ
ージェント実行手段１１２Ｌが直ちにプランを実行し
（ステップ３０５）、実行が成功すると（ステップ３０
６）その旨を利用者に報告して（ステップ３０７）手順
を終了する。

【００６８】プランに不確実知識が用いられた場合、そ
のプランによって目的が達成されるためには、不確実知
識に関する処理が必要である。不確実知識に関する処理
は、不確実知識に述べられている事実が真であることを
確定させるために他のノードで行なわれる処理であり、
プラン実行に先だって行なう。

【００６９】そして、判断手段１１４Ｌは、プランが作
成されたノードをネットワークに接続する回線の信頼性
が高いか低いかを判断する（ステップ３０８）。このよ
うな判断は、予めネットワークの構成を表すデータを蓄
積しておき、そのデータから回線のタイプを読み出して
判断してもよいし、ノードで発生した通信エラーやリン
ク確立失敗などの履歴を順次保存しておき、過去一定時
間内の履歴から信頼性を計算して判断するようにしても
よい。

【００７０】ノードを接続している回線について、携帯
端末の無線経由回線であるなど信頼性が低い場合、エー
ジェントそのものを、不確実知識に基づく処理が可能な
ノードへ移動させることによって不確実知識に関する処
理を行なわせ（ステップ３１３）、その上でプランの実
行（ステップ３０５）を行なわせる。一方、ノードを接
続している回線の信頼性が高い場合は、契約ネットプロ
トコルの手続きを実行することによって（ステップ３０
９）、不確実知識に関する処理を他のノードのエージェ
ントに依頼したうえ、プラン実行によるゴールの達成を
図る。

【００７１】例えば、プランニングにおいて、要求であ
るinstalled("compo1") を満足する動作として、知識管
理手段１０９Ｌからinstall("compo1") という動作を得
たものとする。そして、このinstall("compo1") の事前
条件exits("compo1") についても同様の処理によって、
get("compo1" from Node) という動作を得たものとす
る。さらに、get("compo1" from Node) の事前条件exis
ts("compo1") at Nodeについてプラン作成を続行した結
果、この事前条件は、次の不確実知識でしか満足されな
いことが判明したものとする。

【００７２】 maybe(exists("compo1") at node2) maybe(exists("compo1") at node3) maybe(exists("compo1") at node4) この場合、これらの不確実知識を含むプランが作成され
る。ここで、"maybe()" という表記は不確実知識を表す
書式で、（）内に述べられた内容が真であるか否かを確
認するという処理が必要であることを意味する。これら
の不確実知識が意味しているのは、ファイル"compo1"が
node2,node3,node4 にそれぞれ存在する「かもしれな
い」ことを意味する。このため、これら不確実知識を用
いて作成されたプランによって目的を達成するために
は、エージェントをnode2,node3,node4 に移動させてフ
ァイルを探させるか、node2,node3,node4 内の他のエー
ジェントに、ファイルの発見を依頼する必要がある。

【００７３】ステップ３１３において、他のノードに移
動したエージェントは、そのノードで目的のファイル"c
ompo1"を探し、目的のファイルが発見できればその時点
で元のノードに帰還する。一方、そのノードで発見でき
なければ、他の候補となっているノードにさらに移動し
てファイルの探索を続けることになる。

【００７４】また、契約ネットプロトコル（ステップ３
０９）を用いる場合は、他のノードで活動するエージェ
ントに、例えば目的のファイルの転送を依頼することに
よって不確実知識で述べられた内容を実現したうえ、エ
ージェント実行手段１１２Ｌにおいてプラン実行を行う
（ステップ３０５）。

【００７５】〔２−５．エージェントの移動の詳細〕こ
こで、図４に示したステップ３１３のエージェント移動
手続きについて詳述する。本実施の形態では、エージェ
ントの移動は回線の信頼性が低い場合に用いられる。こ
のようなエージェント移動の具体的な手順を図８のフロ
ーチャートに示す。この手順では、まず、ローカルノー
ド１０１Ｌのエージェント管理手段１０４Ｌは、リモー
トノード上のエージェント管理手段１０４Ｒにエージェ
ント移動要求メッセージを送信する（ステップ５０
１）。

【００７６】リモートノード１０１Ｒのエージェント管
理手段１０４Ｒは、上記エージェント移動要求を受信す
ると（ステップ５０２）、自ノードすなわちリモートノ
ード１０１Ｒ上にエージェント用のプロセスを設定し
（ステップ５０３）、ローカルノード１０１Ｌのエージ
ェント管理手段１０４Ｌに設定完了メッセージを送信す
る（ステップ５０４）。

【００７７】ローカルノードのエージェント管理手段１
０４Ｌは、設定完了メッセージを受信すると（ステップ
５０５）、エージェント記憶手段１０２Ｌからエージェ
ントの持っているプラン及び内部状態のデータ（以下
「エージェント情報」という）を読み込み、リモートノ
ード１０１Ｒのエージェント管理手段１０４Ｒに送信す
る（ステップ５０６）。

【００７８】リモートノード１０１Ｒのエージェント管
理手段１０４Ｒは、エージェント情報を受信すると（ス
テップ５０７）、該リモートノード１０１Ｒにあるエー
ジェント記憶手段１０２Ｒにエージェント情報を格納し
（ステップ５０８）、プランの解釈実行を開始する（ス
テップ５０９）。そして、リモートノード１０１Ｒのエ
ージェント管理手段１０４Ｒが、ローカルノード１０１
Ｌのエージェント管理手段１０４Ｌに成功の通知を送信
すると（ステップ５１０）、ローカルノード１０１Ｌの
エージェント管理手段１０４Ｌは、この通知を受信し
（ステップ５１１）、ステップ５１２において移動前の
エージェントのプロセスを消去する。

【００７９】このような移動を、プラン中の不確実知識
にしたがって行うことによって、ユーザが要求記述にお
いて移動先ノードを特定しなくても、適切なノードでの
処理が可能となる。

【００８０】〔２−６．契約ネットプロトコル手続き〕
次に、図４に示したステップ３０９の契約ネットプロト
コル(Contract Net Protocol) 手続きについて詳述する
（参考文献：Smith, R. G., "The Contract Net Protoc
ol: High-level Communication and Control in a Dist
ributed Problem Solver", IEEE Trans. Computers, Vo
l. 29, pp. 1104-1113(1980). ）。

【００８１】本実施の形態では、契約ネットプロトコル
は回線の信頼性が高い場合に用いられる。このような契
約ネットプロトコル手続きの詳細を図９に示す。契約ネ
ットプロトコルは、エージェントが単独では実行できな
いタスクがある場合や、単独で実行せずに他のエージェ
ントに依頼したほうがシステム全体の稼働効率が向上す
るようなタスクがある場合に、作業を依頼するエージェ
ントを決定するプロトコルである。

【００８２】なお、「タスク」は、エージェントから他
のエージェントに依頼される作業である。本発明におい
ては、不確実知識が真ならば達成された状態となる内容
に対し、その達成を確実かつ効率的にするために契約ネ
ットプロトコルを使用する。エージェント間の契約ネッ
トプロトコルは、実際には、エージェントが存在するノ
ードの協調プロトコル実現手段１１３同士の間で行なわ
れる。

【００８３】〔２−６−１．タスクアナウンス〕契約ネ
ットプロトコルにおいてタスク実行を依頼する場合は、
まず、タスクを持つエージェント（以下、タスクマネジ
ャと呼ぶ）が、ステップ６０１において、タスクを依頼
したいノード群に対して依頼に関する情報（以下「タス
ク情報」という）をブロードキャストする。なお、ブロ
ードキャストとは一定範囲の相手に対して無差別に情報
を送信することであり、タスク情報をブロードキャスト
することをタスクアナウンスという。

【００８４】ここで、ブロードキャストする情報の一例
を次に示す。 タスクID：タスクの識別子 タスクの内容：依頼するタスクの詳細の記述。プランニ
ングのためのサブゴールなど。 タスクマネジャのID：タスクマネジャの、エージェント
としての識別子。 プラン評価基準：タスクを実行可能なエージェントが複
数存在する場合、タスク実行プランを比較するための基
準。通常、プランのコスト関数を用いる。 入札期限：後述の入札の締切時刻。通常、タスクアナウ
ンスからの経過時間（例えば秒単位）で示す。

【００８５】例えば、サブゴールexists("compo1")の達
成に、次に示す不確実知識を利用したため、契約ネット
を使用する場合を考える。 maybe(exists("compo1") at node2) maybe(exists("compo1") at node3) この場合、次のタスクアナウンスを行なう。 タスクID：task1:user:field1@node1 タスクの内容：satisfy(exists("compo1") タスクマネジャのID：agent1:field1@node1 プラン評価基準：filesize("compo1") 入札期限：5 この場合のタスクの内容："satisfy(exists("compo1")"
は、ファイル"compo1"が存在する状態を満足してほし
い、ということを表す。また、タスクIDの項目では、ノ
ードnode1 のフィールドfield1のエージェントuserによ
るタスクアナウンスであることが明示されている。ま
た、プラン評価基準の項目では、獲得すべきファイル"c
ompo1"のファイルサイズをプラン評価基準とすることを
示す。また、入札期限としては、タスクアナウンスの５
秒後が指定されている。

【００８６】〔２−６−２．入札〕上記のようなタスク
情報を受信したノードは、各フィールドにエージェント
を生成し、それらにタスク情報を転送する（ステップ６
０２）。タスク情報を受け取った各エージェントは、自
らが所属しているフィールドにおいてタスクを実行可能
かどうか判断する（ステップ６０３）。例えば、ノード
node2 のフィールドfield1に、上記「タスクの内容」で
指定されているファイル"compo1"が存在する場合、当該
フィールドfield1のエージェントagent1は、タスク内容
を実行可能と判断する。このようにタスク内容を実行可
能なエージェントは、入札する旨の情報（以下「入札情
報」という）をタスクマネジャに送信（入札）する（ス
テップ６０４）。なお、入札情報を送信したエージェン
トを入札エージェントと呼ぶ。また、入札情報の形式を
次に例示する。 タスクID エージェントID：自分の識別子（ここではagent1:field
1@node2 ） タスク実行プラン評価値：前記プラン評価基準にしたが
って計算した、自分のタスク実行プランの評価値。

【００８７】ここで、タスク実行プラン評価値は、タス
クアナウンスで示されたプラン評価基準に基づいて、入
札エージェントが、自分がタスクを実行する場合におけ
る評価を計算したものである。例えば、上記の例では、
タスクアナウンスで示されたプラン評価基準はfilesize
("compo1")である。これは、所要記憶容量と転送所要時
間を節約するために、同じファイル"compo1"であれば、
ファイルサイズが小さいバージョン（版）のファイルを
提供できるエージェントに落札する趣旨である。この場
合、入札エージェントが、プラン評価基準filesize("co
mpo1")を計算するには、さまざまなファイルに関して自
分が持っているデータの中から、ファイル"compo1"に関
するデータを参照すればよい。

【００８８】例えば、ノードnode2 のフィールドfield1
に生成されているエージェントagent1は評価値として
“１００”（単位はKbyte ）という値で入札を行なった
ものとする。また、ここでは、ノードnode3 のフィール
ドfield1に生成されているエージェントagent1もタスク
内容を実行可能と判断し、プラン評価値を１２０として
入札したものとする。なお、タスクを実行不可能と判断
して入札を行なわなかったエージェントは、その旨を、
自らを生成したエージェント管理手段１０４に報告し、
エージェント管理手段１０４の作用によって抹消され
る。

【００８９】〔２−６−３．入札締切と落札〕タスクマ
ネジャは、入札を締め切る入札期限と現在時刻を比較し
ながら入札情報を受信し、ステップ６０５において入札
期限に到達すると、次のステップ６０６において入札締
切を示すメッセージを発信する。この締切のメッセージ
は、タスク情報のブロードキャスト先とした全ての依頼
ノードに対してブロードキャストする。そして、タスク
マネジャは、ステップ６０９において、落札するエージ
ェントを決定する。この決定は、入札期限までに受信し
た各入札情報のタスク実行プラン評価値と、予め定めた
決定の基準に基づいて、各エージェントの入札情報を比
較することによって行なう。例えば、決定の基準が、プ
ラン評価値の数字が最小のエージェントに落札するとい
う内容で、各ノードから送信された入札情報が node2: filesize("compo1") = 100 node3: filesize("compo1") = 120 という内容の場合、タスクマネジャはプランコストの小
さいnode2 の方を、もっともよいプランを入札したとし
て、落札するエージェント（落札エージェントと呼ぶ）
に決定する。この落札エージェントの決定は、タスクマ
ネジャが、実際にタスクを依頼する先としてそのエージ
ェントを決定することを意味するが、実際にタスクを依
頼する時期は処理の内容に応じて異なっていてもよく、
契約ネットプロトコルの終了後に直ちに依頼する場合も
あれば、所定の時期まで待って依頼する場合もある。

【００９０】落札エージェントを決定すると、タスクマ
ネジャは、ステップ６１０において、各入札エージェン
トに、落札の内容を表す落札情報をマルチキャスト（同
報送信）する。この場合は、ノードnode2 とnode3 の各
入札エージェントに対して、次のような落札情報をマル
チキャストすることになる。 タスクID 落札エージェントID：ここではagent1:field1@node2 この落札情報を受信することによって、落札エージェン
トは、タスクを実際に実行すべき旨の実行依頼を待つ状
態となる。落札にもれた他のエージェントは、エージェ
ント管理手段１０４にその旨を報告することによって、
エージェント管理手段１０４の作用で抹消される。タス
クマネジャは、落札されたタスクの実行をその後、落札
エージェントに依頼し、その結果、落札エージェントは
依頼されたタスクの内容を実際に実行する。

【００９１】上記のように、本実施の形態では、エージ
ェント間協調を実現するために契約ネットプロトコルを
用いる。そして、契約ネットプロトコルで処理を他のノ
ードに依頼する場合は、依頼側ノードの持つ条件と請負
側ノードの持つ能力との間で、入札制による調和が図ら
れる。このため、システム全体として優れた処理効率が
実現される。

【００９２】〔２−７．エージェント間での情報交換〕
上記のようなタスクの依頼など、エージェント間で協調
動作を行なう場合、あるエージェントが他のエージェン
トの振る舞いを制御することによって、システム全体の
柔軟な制御を実現することが望ましい。例えば、開放型
ネットワークにおいては、何らかの予期せぬ状況変化の
ために落札エージェントがタスク実行に失敗する場合も
考えられる。このような場合、依頼側のエージェント
（タスクマネジャ）はたとえ何か他の処理を行なってい
る最中でも、そのような失敗に対処し、入札の手順をや
り直すなどの処理を行なう必要がある。

【００９３】また、別の例として、あるエージェントか
ら他のいくつかのエージェントに、メモリや処理時間な
どのシステムリソースを多く消費するタスクを依頼して
いる場合、依頼元側の状況変化によってタスク実行が不
要となった場合、請負側において作業は早急に中断され
ることが望ましい。

【００９４】このような場合、従来知られている黒板に
よる情報交換では、情報の発信側が黒板に何らかの情報
を記入しても、受信すべき側は一連の作業が終了するま
で黒板を参照しないので情報の迅速な処理は困難であっ
た。

【００９５】本実施の形態では、図２に示した階層的な
黒板手段１０６を次のように用いて、各エージェントの
柔軟な制御を実現する。すなわち、図２に示した黒板手
段１０６では、まず、通常の動作に関わる情報を交換す
るには、例えば、エージェント７０２がエージェント７
０３宛てのメッセージを下位階層に記入しておくと、エ
ージェント７０３が所定のまとまりがある処理を終えた
後で、黒板手段の下位階層を参照し、自分宛のメッセー
ジを発見して受け取る。

【００９６】このように、エージェントが、自分に設定
された優先度に本来対応する階層にメッセージを記入し
た場合、メッセージは通常の動作と同じ優先順位で処理
される。このため、エージェント７０２が下位階層にメ
ッセージを書き込んでも、エージェント７０３がそのメ
ッセージを参照するまでは、エージェント７０３の動作
に影響を与えたり中断させることはできない。

【００９７】一方、エージェントが、自分に設定された
優先度に本来対応する階層よりも高い階層、すなわち上
位階層へデータを記入した場合は、他のエージェントの
通常の動作を制御したり、作業に割り込んで強制的に終
了させたりすることができる。例えば、状況の変化によ
ってエージェント７０３の通常動作を中断させる必要が
ある場合、エージェント７０２は黒板手段１０６の上位
階層にメッセージ７０４を記入する。このように上位階
層に書き込まれたメッセージ（以下「上位メッセージ」
という）は、階層黒板管理手段１０７によって優先的に
処理されることによって、エージェント７０３による通
常の処理を中断させることができる。

【００９８】ここで、エージェントが、自分が対応して
いる階層よりも上位の階層にメッセージを記入するため
には、メッセージを階層黒板管理手段１０７に渡す際に
記入する階層を指定したり、階層黒板管理手段１０７
が、記入するメッセージの内容に応じて高い階層に記入
するように構成すればよい。また、上位階層へのメッセ
ージ記入を特定のエージェントに通知するには、メッセ
ージの宛先になっているエージェントの動作を行なって
いるプロセスに対して、階層黒板管理手段１０７がハー
ドウェア割り込みやソフトウェア割り込みをかけたり、
全てのエージェントが、タイマ割り込みなどを用いて一
定の時間間隔毎に階層黒板管理手段１０７に問い合わせ
を行ない、上位階層について変化がないか否かを確認す
るように構成すればよい。また、階層黒板管理手段１０
７は、後述するように、通知を受ける側のエージェント
が指定する階層を監視するように構成すれば、通知を受
ける側のエージェントは自らに割り当てられている優先
度には拘束されず、所望の優先度のエージェントからの
メッセージについて通知を受けられるので、エージェン
ト間協調に対する制御が一層多様化できる。

【００９９】例えば、上記の例でタスクを落札したノー
ドnode2 のエージェントが、落札したタスクtask1 の実
行に失敗した場合でも、次のように黒板手段１０６を利
用していれば、依頼元のタスクマネジャによる迅速な対
応処理を実現することができる（図２参照）。

【０１００】ここでは、依頼元のタスクマネジャである
エージェント７０３と、落札エージェントであるエージ
ェント７０２は、双方とも同じ優先度０を持つエージェ
ントと仮定する。黒板手段１０６では優先度に応じた階
層が設けられていて、通常の情報交換でやり取りされる
情報はレベル０の階層に記入されるものとする。この場
合、依頼元のエージェント７０３は落札エージェント７
０２を決定した後、階層黒板管理手段１０７に対して、
黒板手段１０６の各階層のうち、自分の優先度に対応す
る階層よりも１つ上位の階層であるレベル１を監視して
おくように依頼する。この場合、エージェント７０３
は、レベル１の階層を監視するように依頼したうえ自分
は他の作業に従事していればよい。なお、仮にエージェ
ント７０２，７０３が対応している階層がレベル１であ
る場合は、実行の制御などに用いる階層は１つ上のレベ
ル２となる。

【０１０１】そして、落札したタスクが前提とする不確
実知識が結果的に誤っていて、タスクの実行に必要なフ
ァイル"compo1"がnode2 に存在しなかった場合、落札エ
ージェント７０２はタスクの実行に失敗する。この場
合、タスクの実行に失敗した落札エージェント７０２は
失敗したタスクのタスクIDを黒板手段１０６に記入する
よう、階層黒板管理手段１０７に依頼する。この依頼で
は次のようなデータを階層黒板管理手段１０７へ渡すこ
とによって、上位階層への記入を依頼する。 bb_msg(1, failed(task1)) すなわち、"bb_msg()"は黒板手段１０６への書き込みを
依頼する予約語であり、括弧内の第１項目“１”は、通
常の実行レベルを０であることを前提に、自分の優先度
より１つ上位であるレベル１の階層に記入すべきことを
表している。また、括弧内の第２項目"failed(task1)"
は記入すべき内容である。この内容のうち、"task1" は
タスクＩＤであるが、階層黒板管理手段１０７は、シス
テム構成などの理由で他のノードやフィールドのデータ
と区別する必要があるときは、ノード名など所定の情報
をタスクＩＤに付加して記入を行なう。このようなデー
タによって依頼を受けた階層黒板管理手段１０７は指定
されたレベル１に情報を記入する。ここで、レベル１の
階層に実際に記入される情報の例を次に示す。 failed(task1:agent1:field1:node2) この例では、識別のため、タスクIDに必要なエージェン
ト名やフィールド名などが補充されている。なお、階層
黒板管理手段１０７は、レベル１の階層の監視を依頼さ
れているので、メッセージ７０４をレベル１に記入する
ことに伴って直ちにタスクマネージャであるエージェン
ト７０３へその旨を通知する。

【０１０２】この通知を受けたエージェント７０３は、
失敗したタスクについて、実行に失敗したエージェント
以外のエージェントに対して、契約ネットプロトコルを
再度用いて依頼を行なうことによって、代わりにそのタ
スクを実行するエージェントを決定する。

【０１０３】以上のように、本実施の形態では、黒板手
段１０６が階層的に構成され、優先度の高い上位の階層
に記入した情報の方が下位の階層に記入された情報より
も優先的に処理される。このため、エージェント間で交
換する情報を重要度に応じた階層に記入することによっ
て、エージェント間の協調関係を柔軟に制御できるの
で、予期せぬ状況の変化に対応することが容易になる。
また、エージェント単位に優先度を設定しておき、優先
度が高いエージェントが交換する情報ほど高い階層を用
いたり、情報を黒板手段１０６に入出力する処理も高い
階層ほど優先して行なえば、一層きめ細かな制御も可能
となる。

【０１０４】〔２−８．プランの実行〕上記のようなエ
ージェントの移動（図４，ステップ３１３）又は契約ネ
ットプロトコル（ステップ３０９）によって不確実知識
に関する処理が終了したことによって、プランが実質的
に完成するので、エージェント実行手段１１２がプラン
を実行する（ステップ３０５）。但し、実行が成功しな
かった場合は、不確実知識に関する処理に何らかの問題
点が存在した可能性があるため、プランに不確実知識が
用いられていたか否かを見直し（ステップ３１０）、不
確実知識が用いられていた場合は失敗を黒板手段１０６
の上位階層へ通知することによって（ステップ３１
２）、回線の信頼性に関する判断（ステップ３０８）か
らの手順を再度実行する。プランに不確実知識が用いら
れていないにも関わらず（ステップ３１０）実行が失敗
した場合は、プラン生成に用いた知識やシステムの他の
部分に問題の原因があると考えられるので、失敗を利用
者に報告して（ステップ３１１）手順を終了する。

【０１０５】〔２−９．効果〕以上のように、本実施の
形態では、複数のエージェント間において、協調プロト
コル実現手段１１３による契約ネットプロトコルや、黒
板手段１０６などを用いた標準的なエージェント間協調
の手法を用いて協調動作を行うことによって、ネットワ
ーク１００Ｎ上に分散する情報を効率的に活用する。そ
して、各ノード１０１について判明している状況変化に
関する情報は自動や手動で随時更新しておき、各エージ
ェントの動作を定めるプランは、更新されている情報を
用いて、与えられた目的に応じて作成する。これによっ
て、まず、エージェントの動作が環境変化に応じて変化
するので、安定した情報処理が実現される。

【０１０６】また、不確実知識に関する処理では、ネッ
トワーク上移動とエージェント間協調という２種類の手
法を効果的に使い分ける。すなわち、プランが生成され
たノードをネットワーク１００Ｎに接続する回線の信頼
性が低い場合は、エージェント自体を他のノード１０１
に移動して不確実知識に関する処理を行なう。この手法
では、不確実知識に関する処理を行う間、もとのノード
との間で頻繁に通信を行う必要がないので、回線の信頼
性が低くても安定した動作が実現される。

【０１０７】一方、回線の信頼性が高い場合は、不確実
知識に関する処理を他のノードのエージェントに確認を
依頼するというエージェント間協調が用いられる。この
手法では、エージェント自体の移動処理に要する一連の
処理が不要であるから、不確実知識に関する処理を迅速
に行うことできる。このように、２種類の手法を、回線
の信頼性に応じて使い分けることによって、回線の信頼
性が高ければ確認が迅速に行われる一方、回線の信頼性
が低くても安定した情報処理が行われる。特に、回線の
信頼性及び環境の不安定という２つの問題が、ネットワ
ークに同時に存在する場合でも、前記のようなプラン生
成と確認する手法の使い分けとの組み合わせによって、
効率的で安定した情報処理が実現される。

【０１０８】また、本実施の形態では、各エージェント
は、持っている目的に応じて異なったフィールドで活動
し、プラン生成では自らの目的に対応する知識だけを利
用する。このため、エージェントの間で活動領域の重複
が容易に防止できる。また、プラン生成に用いる知識を
検索する際に余分な知識まで参照する必要がないので、
プラン生成が効率化される。

【０１０９】〔３．他の実施の形態〕なお、本発明は上
記実施の形態に限定されるものではなく、次に例示する
ような他の実施形態をも含むものである。例えば、上記
実施の形態では、全てのノードを同一の構成としたが、
ノード毎の構成が異なっていてもよい。例えば、一部の
ノードだけをフィールドに分割することが考えられる。
また、例えば、黒板手段及び階層黒板管理手段について
は、ノード毎に設けるだけでなくネットワーク内で唯一
のものを設けてもよいし、ノード内のフィールド毎に設
けてもよい。ノード毎に設けた場合は、各ノードのエー
ジェントが他のノードの黒板手段を相互に参照すること
によって情報交換が可能である。この場合、一部のノー
ドに障害が発生しても、交換すべき情報が各ノードに分
散しているのでシステム全体に与える影響が最小限で済
む。また、唯一のものを設けた場合は、各エージェント
が情報交換のためにアクセスする対象が一本化されるの
で情報交換が効率化される。また、フィールド毎に設け
た場合は、交換すべき情報の分散すなわちリスク分散が
一層徹底するので、システムの耐障害性が一層向上す
る。

【０１１０】また、階層的に構成した黒板手段や階層黒
板管理手段を設けることや、エージェント間で協調動作
を行なうためのプロトコルとして契約ネットプロトコル
を用いることは必須ではない。

【０１１１】また、エージェント間の通信は、黒板手段
１０６及び階層黒板管理手段１０７を用いる他に、直接
行えるようにしてもよい（請求項５）。このような直接
の通信は、例えば次のように実現する。すなわち、エー
ジェントが他のエージェントに直接データを送りたい場
合は、宛先のエージェントを指定して、送るデータをエ
ージェント管理手段１０４（図１）に渡す。エージェン
ト管理手段１０４は、プラットフォーム１１０を通じ
て、ネットワーク１００Ｎの持っている通信機能を利用
し、宛先のエージェントが存在しているノードにデータ
を転送する。転送を受けたノードのエージェント管理手
段１０４は、転送されてきたデータを宛先のエージェン
トに渡す。

【０１１２】このような直接の情報交換は、黒板を用い
た間接的な情報交換に代えて用いることもできるし、ま
た、間接的な情報交換と並行して用いることもできる。
このため、情報交換の手段が多様化し、エージェント間
の協調をより柔軟に実現することが可能となる。例え
ば、ある２つのエージェントの間でのみ意味があり、他
のエージェントと無関係な通信は黒板を経由せずに直接
行なうことができる。また、エージェント間で大きなフ
ァイルを受け渡す場合も、黒板の容量を大きくしておく
必要がない。これによって、黒板の容量が少なくて済
み、また、黒板経由の通信と直接の通信を、通信の目的
に応じて使い分けることができるので、処理効率が向上
する。なお、このような直接の情報交換を行う機能は、
エージェント管理手段１０４ではなく、協調プロトコル
実現手段１１３に持たせてもよいし、これらとは別の新
たな手段を設けて実現してもよい。

【０１１３】なお、本発明は、本発明の作用を実現する
ための情報処理プログラムによって実現することが一般
的と考えられるが、そのようなプログラムを記録した記
録媒体も本発明の一態様である。

【０１１４】

【発明の効果】以上説明したように、本発明によれば、
複数のエージェントが協調動作を行なう場合に、状況変
化をプランニングによってエージェントの動作に反映さ
せ、また、不確実知識に関する処理では、回線の信頼性
に応じて２種類の手法を使い分けることによって、予期
せぬ状況変化や信頼性の低い回線が存在する場合でも安
定して情報処理を行なわせることが可能となる。

【図面の簡単な説明】

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

【図２】本発明の実施の形態における黒板手段の構造を
示す概念図。

【図３】本発明に実施の形態におけるノードとフィール
ドの関係を示す概念図。

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

【図５】本発明の実施の形態におけるプラン生成の手順
を示すフローチャート。

【図６】本発明の実施の形態において、生成途中のプラ
ンを示す概念図。

【図７】本発明の実施の形態において、生成されたプラ
ンを示す概念図。

【図８】本発明の実施の形態において、エージェントの
ノード間移動の手順を示すフローチャート。

【図９】本発明の実施の形態における契約ネットプロト
コルの手続きを示すフローチャート。

【図１０】従来技術の一例について、その構成を示す機
能ブロック図。

【符号の説明】

１００Ｎ：ネットワーク １０１Ｌ：ローカルノード １０１Ｒ：リモートノード １０２：エージェント記憶手段 １０３：入出力手段 １０４：エージェント管理手段 １０５：フィールド管理手段 １０６：黒板手段 １０７：階層黒板管理手段 １０８：知識格納手段 １０９：知識管理手段 １１０：プラットフォーム １１１：プランニング手段 １１２：エージェント実行手段 １１３：協調プロトコル実現手段 １１４：判断手段 ２０１：ノード ２０２：フィールド ２０３，７０２，７０３：エージェント ２０４：知識 ７０４：黒板手段に記入されたメッセージ Ｃ：条件 Ｐ：動作 Ｓ：状態 ８００Ｎ：ネットワーク ８００Ｌ：ローカルノード ８００Ｒ：リモートノード ８０１：エージェント情報記憶手段 ８０２：解釈実行手段 ８０３：入出力手段 ８０４：エージェント管理手段

───────────────────────────────────────────────────── フロントページの続き (72)発明者 大須賀 昭彦 神奈川県川崎市幸区柳町70番地 株式会社 東芝柳町工場内 (72)発明者 本位田 真一 神奈川県川崎市幸区柳町70番地 株式会社 東芝柳町工場内

Claims (8)

【特許請求の範囲】
1. 【請求項１】 複数のノードを含むネットワーク上で、
   複数のエージェントが情報交換によって協調動作する情
   報処理装置において、 エージェントが実行すべきプランを生成するプランニン
   グ手段と、 生成されたプランの中に、他のノードにおける処理が必
   要なプランが含まれている場合に、前記プランが作成さ
   れたノードとネットワークとを接続する通信回線の信頼
   性を判断する判断手段と、 前記信頼性が低い場合に、前記プランを実行するエージ
   ェントを、他のノードに移動させる移動手段と、 前記信頼性が高い場合に、他のノードの１または複数の
   エージェントに前記プランの実行に関する依頼を行う協
   調手段と、 生成されたプランを実行する実行手段と、 を備えたことを特徴とする情報処理装置。
2. 【請求項２】 エージェント間で交換される情報を、情
   報の優先度に応じて格納するための階層を複数備えた黒
   板手段と、 上位の階層に格納された情報を、下位の階層に格納され
   た情報より優先的に処理する階層黒板管理手段と、 エージェント間で交換される情報に基づいて、エージェ
   ント間における協調プロトコルを実現するための協調プ
   ロトコル実現手段と、を備えたことを特徴とする請求項
   １記載の情報処理装置。
3. 【請求項３】 少なくとも１つのノードにおいて、 エージェントが活動するための領域が目的に応じた複数
   のフィールドに分割され、 プランの生成に用いる知識が、各フィールドに対応して
   分割され、 分割された各フィールド及び知識を、対応する目的を持
   つエージェントのために利用させるフィールド管理手段
   を備えたことを特徴とする請求項１又は２記載の情報処
   理装置。
4. 【請求項４】 前記協調手段は、契約ネットプロトコル
   を用いるように構成されたことを特徴とする請求項１，
   ２又は３記載の情報処理装置。
5. 【請求項５】 エージェント間で直接情報交換を行うた
   めの通信手段を備えたことを特徴とする請求項１，２，
   ３又は４記載の情報処理装置。
6. 【請求項６】 複数のノードを含むネットワーク上で、
   複数のエージェントが情報交換によって協調動作する情
   報処理方法において、 エージェントが実行すべきプランを生成する工程と、 生成されたプランの中に、他のノードにおける処理が必
   要なプランが含まれている場合に、前記プランが作成さ
   れたノードとネットワークとを接続する通信回線の信頼
   性を判断する工程と、 前記信頼性が低い場合に、前記プランを実行するエージ
   ェントを他のノードに移動させる工程と、 前記信頼性が高い場合に、他のノードの１または複数の
   エージェントに前記プランの実行に関する依頼を行う工
   程と、 生成されたプランを実行する工程と、 を含むことを特徴とする情報処理方法。
7. 【請求項７】 エージェント間で交換される情報を、情
   報の優先度に応じて格納するための階層を複数備えた黒
   板を用い、 上位の階層に格納された情報を、下位の階層に格納され
   た情報より優先的に処理する工程と、 エージェント間で交換される情報に基づいて、エージェ
   ント間における協調プロトコルを実現するための工程
   と、を含むことを特徴とする請求項６記載の情報処理方
   法。
8. 【請求項８】 複数のノードを含むコンピュータのネッ
   トワーク上で、複数のエージェントを情報交換によって
   協調動作させるための情報処理プログラムを記録した記
   録媒体において、 前記情報処理プログラムはコンピュータに、 エージェントが実行すべきプランを生成させ、 生成されたプランの中に、他のノードにおける処理が必
   要なプランが含まれている場合に、前記プランが作成さ
   れたノードとネットワークとを接続する通信回線の信頼
   性を判断させ、 前記信頼性が低い場合に、前記プランを実行するエージ
   ェントを他のノードに移動させ、 前記信頼性が高い場合に、他のノードの１または複数の
   エージェントに前記プランの実行に関する依頼を行わ
   せ、 生成されたプランを実行させることを特徴とする情報処
   理プログラムを記録した記録媒体。