JPH10149287A - 情報処理装置、情報処理方法及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 ソフトウェアの構成要素の変化に柔軟に対応
し、かつ、回線障害に対する耐障害性を向上させる。 【解決手段】 各ノードＬ，Ｒのローカル情報記憶手段
１に、構成要素へのアクセスに用いるローカル情報を格
納し、更新手段２によって更新する。プラン生成手段５
が、入力された前記要求記述を満たすためにエージェン
トがとるべき行動を表すプランを、エージェント情報及
びローカル情報に基づいて、複数のアクションの集合と
して生成する。プラン実行手段５が、生成された前記プ
ラン中の各アクションに基づいて各ノードＬ，Ｒ上でエ
ージェントの動作を実現し、エージェント管理部７が、
プラン中のgoアクションに基づいて、前記エージェント
をノード間で移動させる。移動先のノードでも、プラン
実行の失敗時など、必要に応じて再プランニングや子エ
ージェントの生成が行われる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク上に
分散して存在する情報を処理する情報処理装置及び情報
処理方法の改良に関するものである。

【０００２】

【従来の技術】近年、コンピュータを中心とした情報処
理システム技術においては、ダウンサイジングの進行
や、インターネットなどネットワーク環境の整備が進ん
でいる。このため、情報処理の装置や方法における主流
は、データファイルや機能ライブラリなどの構成要素が
ネットワーク上の各マシンに分散した分散システムに移
行しつつある。これに伴い、企業や研究所などのローカ
ルネットワークでも、広域ネットワークとの接続によっ
て環境のオープン化がより進展している。このように広
域ネットワークと接続されたネットワークを開放型ネッ
トワークと呼ぶ。

【０００３】開放型ネットワークに代表される大規模ネ
ットワークでは、しばしば、複数のマシン上に分散した
いくつかのデータファイルや機能ライブラリなどの構成
要素を組み合わせることによって、一つのソフトウェア
を構成する。このように構成されるソフトウェアを分散
システムと呼ぶ。分散配置された構成要素は、マシンす
なわちノードに関する管理上の事情や、ネットワークに
関する管理上の事情などで、別のマシンやディレクトリ
に移動されたり、名称やアクセス権などの属性が変更さ
れることが考えられる。このような変更は、次のような
問題を生ずる。

【０００４】まず、ソフトウェアに処理を要求するとき
は、メッセージやコマンドなどの要求記述を入力し、こ
の入力の際に、あるマシン上に配置されている処理に関
わる特定の構成要素が指定される。しかし、指定された
構成要素が他のマシンに移動されると、移動先の新しい
マシンを指定するために、ソフトウェアに対する入力を
やり直すか、修正しなければならない。特に、ソフトウ
ェアの一部が、移動された構成要素にアクセスするよう
に構成されている場合は、構成要素の移動は、ソフトウ
ェアの構成そのものの変化を意味する。この場合、アク
セスする側のソフトウェアの部分を変更して、移動先の
新しいマシンを指定しなければならない。

【０００５】従来では、マシン・機能・ファイルなど
は、具体的に名指しされていたため、機能又はファイル
が移動されると、変更に合わせてソフトウェアや入力を
変更しなければならなかった。しかも、このような指定
は処理開始前に行なう必要があった。

【０００６】分散システムにおいて、ユーザに対してサ
ービスを確実に提供するには、こうした変化に対して適
応する柔軟なソフトウェアを構築することが重要であ
る。特に、このような変化に対応して、処理開始後であ
っても指定を変更し、かつこの変更は極力人手を介さず
自動的に行われることが望ましい。

【０００７】ネットワークにおいて、このような柔軟な
ソフトウェアのアーキテクチャを実現する技術として、
近年、エージェント指向技術が注目され、数多くの試み
がなされている。エージェント指向技術は、エージェン
トを単位としてソフトウェアを構成しようとするソフト
ウェア開発技術であり、ここでいうエージェントは、ソ
フトウェア上の処理の単位で、環境の変化に自律的かつ
柔軟に対応するものである。

【０００８】たとえば特開平７−１８２１７４では、リ
モートプログラミングの実施方法を開示している。リモ
ートプログラミングは、分散システムにおいて、処理が
開始されたノード（ローカルマシンと呼ぶ）から、エー
ジェントが他のノード（リモートマシンと呼ぶ）に転送
されるようなプログラミングである。

【０００９】エージェントが活動するには、インストラ
クションと内部情報が必要である。インストラクション
は、エージェントの動作（振る舞い）を記述したもの
で、内部情報は、エージェントの動作によって操作され
る情報である。内部情報は、より具体的には、変数や配
列のほかスタック、バッファ、キュー、フラグなど、エ
ージェントの動作に関連する一切の情報を含む。インス
トラクション及び内部情報を合わせてエージェント情報
と呼ぶ。

【００１０】インストラクションは、ファイルのオープ
ンやクローズなど、さまざまな動作の単位ごとに記述さ
れる。リモートプログラミングでは、特殊なインストラ
クションとして、goオペレーションが用いられる。goオ
ペレーションは、エージェントをリモートマシンに転送
する処理を行なわせるもので、例えば、ある処理中に、
別のマシンにあるファイルに対するインストラクション
が含まれる場合は、そのインストラクションに先立っ
て、goオペレーションが記述され、実行される必要があ
る。

【００１１】このようなエージェントを用いるリモート
プログラミングを実施する装置の一例について、構成を
表す機能ブロック図を図２３に示す。この装置では、ネ
ットワークＮに接続されたローカルマシンＬとリモート
マシンＲが相互に同様の構成を有し、プロセスとしてエ
ージェントを取り扱う。なお、ここでいうプロセスは、
オペレーティングシステムによって管理の対象となる処
理の単位であり、複数のプロセスを同時に管理すること
をマルチプロセスと呼ぶ。

【００１２】エージェント管理手段５１Ｌ，５１Ｒは、
このようなエージェントについて、資源管理、設定、終
了、スケジューリング及び転送など、エージェント自身
を対象とする処理を司る。エージェントによる処理を開
始するには、まず、エージェント情報を、ローカルマシ
ンＬ上のエージェント情報記憶手段３１Ｌに格納する。
エージェント情報をエージェント情報記憶手段３１Ｌに
格納するには、入出力手段４１Ｌから入力したり、図示
しない外部記憶装置からロードするなどすればよい。

【００１３】また、入出力手段４１Ｌからエージェント
による処理の開始が指示されると、解釈実行手段６１Ｌ
が、エージェント情報記憶手段３１Ｌ内のインストラク
ションを逐次解釈実行することによって処理を進め、エ
ージェント情報記憶手段３１Ｌ内の内部情報を操作す
る。インストラクション中のgoオペレーションが解釈実
行されると、解釈実行手段６１Ｌがその旨をエージェン
ト管理手段５１Ｌに通知し、エージェント管理手段５１
Ｌは次のようなエージェントを転送する処理を行う。

【００１４】まず、エージェント管理手段５１Ｌは、ネ
ットワークＮを通じてリモートマシンＲ上のエージェン
ト管理手段５１Ｒにエージェントの受け入れ準備を要求
する。要求を受けたエージェント管理手段５１Ｒは、資
源の割当や、エージェントとして管理するプロセスの設
定など、エージェントの受け入れ準備を行なった後、ロ
ーカルマシンＬ上のエージェント管理手段５１Ｌに準備
完了を通知する。

【００１５】この通知を受けたエージェント管理手段５
１Ｌは、エージェント情報記憶手段３１Ｌ内のインスト
ラクションと、上記goオペレーションの解釈実行時にお
けるエージェントの内部状態を読み出し、双方をリモー
トマシンＲに転送する。リモートマシンＲ上のエージェ
ント管理手段５１Ｒは、転送されたインストラクション
と内部状態をエージェント情報記憶手段３１Ｒに格納し
たうえ、解釈実行手段６１Ｒにその旨を通知し、解釈実
行を開始させる。

【００１６】エージェントの転送が無事に終了すると、
ローカルマシンＬ側のエージェント管理手段５１Ｌはプ
ロセスを終了し、不要になったメモリやＣＰＵ時間など
資源を開放する。

【００１７】転送された側のリモートマシンＲでは、エ
ージェント情報記憶手段３１Ｒ内のインストラクション
と内部状態を用いて、処理が続行される。なお、続行さ
れた処理がリモートマシンＲ上で終了する場合もあれ
ば、エージェントがもとのローカルマシンＬに再度転送
される場合もありうる。エージェントが再度転送される
と、インストラクションの実行は再度ローカルマシンＬ
上で行われることになる。以上のようなリモートプログ
ラミングによって、分散システム上における柔軟な処理
が実現される。

【００１８】また、このようなリモートプログラミング
において、各マシン間で共通のインストラクション及び
内部情報を用いながら、解釈実行手段やエージェント管
理手段などを各マシン固有のハードウェアやＯＳに合わ
せて構成すれば、構成の異なるマシン間で互換性が実現
される。このような構成により、オペレーティングシス
テムおよびハードウェアが異なるコンピュータシステム
において、インストラクションを移動し実行できるな
ど、上述のような柔軟な対応が可能となる。

【００１９】一方、ネットワーク上の複数のノードにま
たがって処理を行なうための別の従来技術として、次の
ようなものも知られている（参考文献：Oren Etzioni a
nd Daniel Weld "A Softbot-Based Interface to the I
nternet" (Communications of ACM)）。この技術では、
ファイルを転送を行なうｆｔｐ、遠隔ログインのための
仮想端末機能を実現するｔｅｌｎｅｔなど、通常のネッ
トワーク機能を利用して、複数のマシンにまたがった処
理を行なう。そして、動作中に収集した情報に基づき、
ソフトウェアによって自動的に各機能を試行錯誤的に利
用し、状況に応じて柔軟にプランニングを行なうことに
よって、ファイルなどの構成変化に対応した機能選択を
行う。

【００２０】例えば、目的の機能が他のノードに移転さ
れた場合、移転前のノードでその機能にアクセスしよう
とすると失敗するので、元のマシン（ノード）において
プランニングを行ない、アクセス先を第２候補に変更し
再度アクセスする。この技術によれば、システムの各時
点での状態に対応して、柔軟な動作が可能である。な
お、telnetやftp などの利用は互換性が予め判明してい
る範囲内で行なう。

【００２１】

【発明が解決しようとする課題】しかしながら、上記の
ような従来技術には次のような問題点が存在していた。
まず、リモートプログラミングの実施方法（特開平７−
１８２１７４）では、エージェントの動作系列をインス
トラクションとして全て利用者が記述しなければならな
かったため、プログラミング作業が煩雑である上、エー
ジェントの柔軟性に限界があった。また、goオペレーシ
ョンによるエージェントの移動先や、利用すべき構成要
素が存在するマシンのノード名（ネットワークにおける
識別子）のような、ソフトウェアの構成要素の変化に対
応するためには、このような変化を捕捉する必要がある
が、従来はこのような変化に対応する手段は備えられて
いなかった。さらに、構成要素の変化に対応するには、
変化に応じてインストラクションを変更する必要がある
が、従来は、アクセス先のマシン名が具体的に名指しさ
れていたため、アクセス先を変更しなければ目的を達成
できない場合においても、その場でインストラクション
を変更することは不可能であった。このため、構成要素
の変化に柔軟に対応する技術が求められていた。特に、
開放型ネットワークのような大規模ネットワークになる
ほど変化が頻繁になるため、変化への対応が強く求めら
れていた。

【００２２】また、Ｅｔｚｉｏｎｉらの方法では、処理
中に、ローカルマシンとリモートマシンとの間で相互に
アクセスを続け、継続して情報をやり取りする必要があ
る。このため、処理の途中で回線障害が生じ、アクセス
のルートが切断されると正常な処理の続行ができない、
という問題があった。また、遠隔ノードにおける情報の
内容をきめこまかく参照して処理内容を変えたり、遠隔
ノードの情報へのアクセスを何度か実施する必要がある
場合、また、処理に何らかのリアルタイム性が要求され
る場合などは、リモートマシン上のプロセスとして情報
処理を行ったほうが効率的な場合もある。

【００２３】本発明は、上記のような従来技術の問題点
を解決するために提案されたもので、その目的は、ソフ
トウェアの構成要素の変化に柔軟に対応し、かつ、回線
障害に対する耐障害性に優れた情報処理装置及び情報処
理方法を提供することである。より具体的には、本発明
の目的は、ソフトウェアの構成要素に関する情報に基づ
いて柔軟に作成したプランによって、実行主体たるエー
ジェントの行動を定めることである（請求項１，６，
７）。また、本発明の他の目的は、アクションごとの事
前条件と事後条件に基づいて、アクションを接続してい
くことによって、効率的にプランを生成することである
（請求項２，３）。また、本発明の他の目的は、エージ
ェントをプロセスとして実現することによって、並行処
理とシステム資源の有効活用を図ることである（請求項
５）。

【００２４】また、本発明の他の目的は、柔軟な運用が
可能な情報処理装置及び情報処理方法を提供することで
ある。また、本発明の他の目的は、処理の効率に優れた
情報処理装置及び情報処理方法を提供することである。
より具体的には、本発明の目的は、移動先のノードでも
プラン作成を行うことによって、柔軟な情報処理を実現
することである（請求項８，１３，１４）。また、本発
明の他の目的は、プラン作成に用いる情報を複数のフィ
ールドに区分しておき、エージェントの種類に対応する
フィールドの情報のみを用いてプラン作成を行うことに
よって、プラン作成を効率化することである（請求項
９，１５）。また、本発明の他の目的は、移動命令に事
前条件を添付しておくことによって、移動の失敗への対
応を容易にすることである（請求項１１）。また、本発
明の他の目的は、プランの実行や移動が失敗しても、再
度プランを作成することによって、情報処理を円滑に継
続させることである。

【００２５】

【課題を解決するための手段】上記の目的を達成するた
め、本発明は、次のような構成及び作用を有する。ま
ず、請求項１の発明は、ソフトウェア上の実行主体がネ
ットワークに接続されたノード上で動作することによっ
て情報処理を行う情報処理装置において、前記ノードに
配置された構成要素へのアクセスに用いるための構成要
素の状態を表現する第１の情報を記憶する第１の記憶手
段と、前記記憶されている所定の情報を更新する更新手
段と、前記実行主体の挙動を定義する第２の情報を記憶
するための第２の記憶手段と、前記情報処理に対して与
えられた要求記述を満たすために実行主体がとるべき行
動を表すプランを、前記第１の情報及び前記第２の情報
に基づいて、アクションの集合として、生成する生成手
段と、生成された前記プランに基づいてノード上で実行
主体の動作を実現する実行手段と、前記生成された前記
プランを構成する前記アクションのうちの第１のアクシ
ョンに基づいて、前記実行主体をノード間で移動させる
管理手段と、を有することを特徴とする。

【００２６】請求項６の発明は、請求項１の発明を方法
の観点から把握したものであって、ソフトウェア上の実
行主体がネットワークに接続されたノード上で動作する
ことによって情報処理を行う情報処理方法において、前
記ノードに配置された構成要素へのアクセスに用いるた
めの構成要素の状態を表現する第１の情報を記憶する第
１の記憶処理と、前記記憶されている所定の情報を更新
する更新処理と、前記実行主体の挙動を定義する第２の
情報を記憶するための第２の記憶処理と、前記情報処理
に対する要求記述を入力するための入力処理と、前記第
１の情報及び前記第２の情報に基づいて、入力された前
記要求記述を満たすために実行主体がとるべき行動を表
すプランを、アクションの集合として生成する生成処理
と、生成された前記プランに基づいてノード上で実行主
体の動作を実現する実行処理と、前記生成された前記プ
ランを構成する前記アクションのうちの第１のアクショ
ンに基づいて、前記実行主体をノード間で移動させる管
理処理と、を含むことを特徴とする。

【００２７】請求項７の記録媒体は、請求項６の発明
を、当該方法を実現するプログラムを記録した記録媒体
の観点から把握したものであって、ソフトウェア上の実
行主体がネットワークに接続されたノード上で動作する
ことによって情報処理を行う際に、前記ノードに配置さ
れた構成要素へのアクセスに用いるための構成要素の状
態を表現する第１の情報を記憶する第１の記憶処理と、
前記記憶されている所定の情報を更新する更新処理と、
前記実行主体の挙動を定義する第２の情報を記憶するた
めの第２の記憶処理と、前記情報処理に対する要求記述
を入力するための入力処理と、前記第１の情報及び前記
第２の情報に基づいて、入力された前記要求記述を満た
すために実行主体がとるべき行動を表すプランを、アク
ションの集合として生成する生成処理と、生成された前
記プランに基づいてノード上で実行主体の動作を実現す
る実行処理と、前記生成された前記プランを構成する前
記アクションのうちの第１のアクションに基づいて、前
記実行主体をノード間で移動させる管理処理と、を含む
情報処理方法を実現するコンピュータプログラムを記録
したことを特徴とする。

【００２８】本発明の他の態様は、請求項１記載の情報
処理装置において、前記アクションは必要に応じて、ノ
ード間でのエージェントの移動を実現するgoアクション
を含むことを特徴とする。

【００２９】請求項１，６，７の発明は、次のような作
用を有する。データファイルや機能ライブラリなどの構
成要素をネットワーク上の各ノードに分散配置する。各
構成要素のドメイン名、ノード名、ディレクトリや呼び
出し手順などは第１の情報として格納しておく。構成要
素について、他のノードへの移動など変更があったとき
は、手動又は自動で第１の情報を更新する。

【００３０】情報処理によって実現すべき内容、例えば
検索対象とするファイルや検索キーなどは要求記述とし
て入力する。この要求記述を満たすための実行主体の行
動はプランとして生成される。プランは、アクション
（処理）の集合であり、アクションにはノード移動を行
うための第１のアクション（goアクション）が含まれ
る。

【００３１】プラン中の第１のアクションの実行によっ
て実行主体は他のノード（リモートマシン）に転送さ
れ、リモートマシン上でアクションの実行や必要なプラ
ン生成が続行される。あるファイルが目的の場合、どの
ノードにアクセスすべきかなど、具体的な要素は、プラ
ン生成の時点で、第１の情報を参照することによって決
定される。

【００３２】このように、本発明では、実行主体の挙動
はプランによって定まるので、実行主体の動作系列をユ
ーザが記述する必要がなく、情報処理が効率化される。

【００３３】また、各構成要素のアクセス先となる具体
的なノードなどは、プラン生成の際に第１の情報に基づ
いて決定される。このため、機能やファイルに変更があ
っても、その変更が実行主体の挙動に反映される。ま
た、ローカルマシンとリモートマシンの間で情報のやり
取りを続ける必要はないので、ネットワークのノード間
の接続切断など、予期せぬ状況の変化にも対応して処理
が続行される。

【００３４】本発明の他の態様は、請求項１記載の情報
処理装置において、第１の記憶手段に記憶された第１の
情報を更新する更新手段を有してなり、この更新手段
は、各ノードにおいて入力された、構成要素に関する変
更の内容に基づいて、前記所定の情報を更新する手段を
含むことを特徴とする。この態様では、変更の内容を手
作業で自由に入力できるので、具体的事情に合わせて入
力内容を調整することによって、柔軟な運用が可能とな
る。

【００３５】本発明の他の態様は、請求項１記載の情報
処理装置において、前記更新手段は、与えられた条件が
成立した場合に、ネットワークに関する情報を参照する
ことによって前記所定の情報を更新する手段を含むこと
を特徴とする。この態様では、変更の検出と第１の情報
の更新が自動的に行われるので、手作業で情報を入力す
る手間を省くことができ、処理が効率化される。

【００３６】請求項２の発明は、請求項１記載の情報処
理装置において、前記第２の記憶手段は、実行主体の動
作の単位であるアクションの集合を記憶する処理と、前
記アクションが実行可能となることを表す事前条件と、
実行による状態変化の内容を表す事後条件とを含むアク
ション情報を記憶する手段と、アクションの実行に関す
る所定の制約条件を記憶する手段と、各アクション間の
因果関係を表す情報を記憶する手段と、を備え、前記生
成手段は、前記アクションの集合中の所定のアクション
に関し、前記アクション情報に基づいて、新たな制約条
件又は前記因果関係を表す情報のうち少なくとも一方
を、前記第２の記憶手段に記憶させる手段を備えたこと
を特徴とする。

【００３７】請求項３の発明は、請求項２記載の情報処
理装置において、前記生成手段は、特定のノードで実行
すべきアクションの事前条件を事後条件として実行主体
が前記特定のノードへ移動するアクションを前記アクシ
ョンの集合に追加し、アクションの集合に含まれる各ア
クションの事前条件のうち、前記因果関係を表す情報に
おいて成立する事実として記録されていないものをサブ
ゴールとして順次選択し、選択したサブゴールの事前条
件を達成する事後条件を持つアクションをさらに順次選
択し、選択された各アクションについて前記新たな制約
条件又は前記因果関係を表す情報のうち少なくとも一方
を、前記第２の記憶手段に記憶させるように構成された
ことを特徴とする。

【００３８】本発明の他の態様は、請求項２記載の情報
処理装置において、前記生成手段は、選択された各アク
ションについて、他のアクションの事前条件を損なわな
いものについては、選択されたアクションを前記因果関
係を表す情報に追加するように構成されたことを特徴と
する。本発明の他の態様は、請求項２記載の情報処理装
置において、前記生成手段は、選択された各アクション
について、他のアクションの事前条件を損なうものであ
ってかつ当該他のアクションの実行前に当該事前条件が
損なわれることを阻止する前記制約条件を追加できるも
のについては、選択されたアクションを前記因果関係を
表す情報に追加するとともに当該制約条件を追加するよ
うに構成されたことを特徴とする。

【００３９】請求項２，３の発明は、次のような作用を
有する。アクションは事前条件が満たされた状態で実行
でき、実行の結果、事後条件を発生させる。そこで、目
的とする状態を事後条件として発生させるアクション
を、因果関係を表す情報によって目的とする状態に接続
し、さらに、接続したアクションの事前条件を事後条件
として発生させるアクションをさらに接続する。このよ
うに実行順序とは逆に遡って接続を繰り返せば、目的と
する状態を実現するための動作系列が得られる。このよ
うに、本発明によれば、単純な処理を単位としてプラン
生成を行えるので、処理が効率化される。

【００４０】本発明の他の態様は、請求項２記載の情報
処理装置において、前記実行手段は、前記所定の制約条
件を満たしつつ、前記第１のアクション以外の第２のア
クションを実行した後、該第１のアクションを実行する
ように構成されたことを特徴とする。この態様では、第
１のアクションの実行に先立って、第１のアクション以
外の実行可能なアクションが実行されるので、実行主体
を元のノードに再度転送する処理が最小限となり、処理
が効率化される。

【００４１】請求項４の発明は、請求項１記載の情報処
理装置において、未達成ゴールが存在しない場合は、プ
ランの生成が成功で、プランを実行するまでもなく要求
記述が達成されたと判定し、未達成ゴールが存在しかつ
アクション集合が空でない場合は、プランの生成は成功
でかつプランの実行が必要と判定する判定手段を有する
ことを特徴とする。請求項４の発明では、プラン生成の
結果が判定され、判定結果に応じた処理が選択できるの
で、処理が効率化される。

【００４２】請求項５の発明は、請求項１記載の情報処
理方法において、前記実行主体をノード上のプロセスと
して設定し、各ノードの前記各管理手段は、転送元とな
るノードから転送先となるノードへ実行主体を転送する
ときに、転送元から転送先へ実行主体の受け入れ要求を
送信し、受け入れ要求を受信した転送先において、実行
主体用のプロセスを設定することによって実行主体を受
け入れる準備を行ない、転送先から転送元に準備完了の
通知を送信し、準備完了の通知を受信した転送元から前
記第１の情報を転送先に送信し、第１の情報を受信した
転送先で、受信した第１の情報に基づいて前記プロセス
の実行を開始し、転送元において実行主体のプロセスを
終了するように構成されたことを特徴とする。

【００４３】請求項５の発明では、実行主体がプロセス
として実行されるので、他のプロセスと同時並行的に実
行でき、システム効率が向上する。また、各ノードで
は、実行主体受け入れ時にプロセスを設定するので、シ
ステム資源が有効活用される。

【００４４】請求項８の発明は、ソフトウェア上の実行
主体であるエージェントがネットワークに接続されたノ
ード上で動作することによって情報処理を行う情報処理
装置において、前記ノードに配置された構成要素へのア
クセスに用いるための構成要素の状態を表現する第１の
情報と、前記実行主体の挙動を定義する第２の情報を記
憶するための手段と、前記第１及び第２の情報に基づい
て、与えられた目的を達成するためにエージェントが実
行すべきプランを作成する手段と、作成されたプランの
実行及びエージェントのノード間における移動を実現す
るための手段と、を有し、移動先のノードにおいても、
プランの実行及び必要なプランの作成を行うように構成
されたことを特徴とする。

【００４５】請求項１３の発明は、請求項８の発明を方
法の観点から把握したものであって、ソフトウェア上の
実行主体であるエージェントがネットワークに接続され
たノード上で動作することによって情報処理を行う情報
処理方法において、前記ノードに配置された構成要素へ
のアクセスに用いるための構成要素の状態を表現する第
１の情報と、前記実行主体の挙動を定義する第２の情報
を記憶するステップと、前記第１及び第２の情報に基づ
いて、与えられた目的を達成するためにエージェントが
実行すべきプランを作成するステップと、作成されたプ
ランの実行及びエージェントのノード間における移動を
実現するためのステップと、を有し、移動先のノードに
おいても、プランの実行及び必要なプランの作成を行う
ことを特徴とする。

【００４６】請求項１４の発明は、請求項１３の発明
を、当該発明を実現するコンピュータプログラムを記録
した記録媒体の観点から把握したものであって、ソフト
ウェア上の実行主体であるエージェントがネットワーク
に接続されたノード上で動作することによって情報処理
を行う情報処理方法を実現するコンピュータプログラム
を記録した記録媒体において、当該情報処理方法は、前
記ノードに配置された構成要素へのアクセスに用いるた
めの構成要素の状態を表現すると、前記実行主体の挙動
を定義する第２の情報を記憶するステップと、前記第１
及び第２の情報に基づいて、与えられた目的を達成する
ためにエージェントが実行すべきプランを作成するステ
ップと、作成されたプランの実行及びエージェントのノ
ード間における移動を実現するためのステップと、を有
し、移動先のノードにおいても、プランの実行及び必要
なプランの作成を行うことを特徴とする。

【００４７】請求項８，１３，１４の発明では、エージ
ェントがプランに基づいてノード間で移動するだけでな
く、移動先のノードでもさらにプラン作成が行われる。
このため、プランの実行段階や移動先ノードの状態に応
じて、情報処理の内容が柔軟に決定され、情報処理が効
率化される。

【００４８】請求項９の発明は、請求項８記載の情報処
理装置において、各ノードに配置された前記各情報が、
エージェントの種類ごとに対応する複数のフィールドに
区分され、エージェントのプランは、当該エージェント
に対応するフィールドの情報に基づいて作成され、ノー
ド間における移動では、エージェントが移動先のノード
における対応する前記フィールドに移動するように構成
されたことを特徴とする。

【００４９】請求項１５の発明は、請求項１３記載の情
報処理方法を実現するコンピュータプログラムを記録し
た記録媒体において、当該情報処理方法は、各ノードに
配置された前記各情報が、エージェントの種類ごとに対
応する複数のフィールドに区分され、エージェントのプ
ランは、当該エージェントに対応するフィールドの情報
に基づいて作成され、ノード間における移動では、エー
ジェントが移動先のノードにおける対応する前記フィー
ルドに移動することを特徴とする。

【００５０】請求項９，１５の発明では、プラン作成の
際、エージェントの種類に対応するフィールドの情報の
みが用いられるので、必要な探索処理の量が減り、プラ
ン作成が効率化される。また、ノード間移動の際も、エ
ージェントは対応するフィールドに移動するので、移動
前と同様に対応するフィールドの情報を用いてプランの
実行やプランの作成が行われる。

【００５１】請求項１０の発明は、請求項８又は９記載
の情報処理装置において、エージェントが、当該エージ
ェントに固有の状態又はアクションに関する情報を持
ち、ノード間の移動の際もこれら情報を運搬し、運搬し
ているこれら情報を移動した先のノードにおける前記第
１の情報及び前記第２の情報と合わせてプランニングに
用いることを特徴とする。請求項１０の発明では、エー
ジェントが固有の情報と共に移動し、移動先のノードで
も固有の情報を用いるので、個々のエージェントの状態
やアクションに適したプランニングが可能となる。

【００５２】請求項１１の発明は、請求項８，９又は１
０記載の情報処理装置において、前記プランを作成する
手段は、プランの一部としてエージェントをノード間で
移動させる移動命令又はその他の命令を作成する際に、
当該命令の前提となる事前条件を当該移動命令又は当該
その他の命令に添付するように構成されたことを特徴と
する。請求項１１の発明では、移動命令に事前条件が根
拠として添付される。そして、当該移動命令に基づく移
動が失敗する場合は、命令が前提とした事前条件が成立
していなかった可能性がある。この事前条件は、移動命
令に添付されているので、移動命令を参照すれば容易に
判明する。このため、移動失敗の原因が特定され、失敗
への対応が容易になる。

【００５３】請求項１２の発明は、請求項８，９，１０
又は１１記載の情報処理装置において、前記エージェン
トが、最終的な目的であるゴールを達成するための中間
的なサブゴールを作成し、このサブゴールを達成するた
めの子エージェントを生成するように構成されたことを
特徴とする。請求項１２の発明では、中間的なサブゴー
ルの達成が子エージェントに依託されるので、エージェ
ント毎の情報処理の内容が単純化されることによって、
情報処理が効率化される。また、複数のエージェントが
並列動作することによって、情報処理が迅速化される。

【００５４】本発明の他の態様は、請求項８，９，１
０，１１又は１２記載の情報処理において、プランの実
行又はエージェントの移動が失敗した場合、プランの実
行を中断し、再度プランを作成して実行するように構成
されたことを特徴とする。この態様において、望ましく
は、プラン中のアクションの実行又はエージェントの移
動が失敗した場合、実行又は移動の失敗を回復するため
のサブゴールを生成し、当該サブゴールの実行終了後に
前記プランの実行を再開するための情報を保存し、前記
サブゴールに基づいてプランの作成及びプランの実行を
行い、サブゴールに基づくプランの実行後に、保存した
前記情報を用いて元のプランの実行を継続するように構
成する。このような態様では、プランの実行や移動が失
敗しても、再度プランが作成されるので、情報処理が円
滑に継続される。

【００５５】本発明の他の態様は、請求項８，９，１
０，１１又は１２記載の情報処理装置において、プラン
の実行又はプランに基づく移動が失敗した場合に、失敗
の原因となった情報を修正する手段を有することを特徴
とする。本発明の他の態様は、請求項１３記載の情報処
理方法において、プランの実行又はプランに基づく移動
が失敗した場合に、失敗の原因となった情報を修正する
ステップを有することを特徴とする。これらの態様で
は、失敗の基礎となった情報が修正されるので、それ以
降の失敗が減少し、処理が効率化される。

【００５６】

【発明の実施の形態】以下、図面を参照しながら本発明
の実施の形態（以下「実施形態」という）について説明
する。なお、以下の各実施形態は、複数のノードを含む
ネットワークによる分散環境を前提とする。ここで、
「ネットワーク」は、計算機と計算機を接続するもの一
般を意味し、具体的には、インターネット、電話回線、
等である。「ノード」は、エージェントの移動の単位で
ある。基本的には、一台のホストすなわち一台の計算機
上に１つのノードを想定するが、複数のノードが存在し
ていてもよい。「分散環境」は、ネットワークで接続さ
れたコンピュータが複数存在し、それぞれのコンピュー
タが持つ情報が異なっている環境である。

【００５７】また、下記の各実施形態は、コンピュータ
上においてプログラムによってＣＰＵを制御することに
よって実現され、この場合の具体的な実現態様は種々考
えられる。このため、以下の説明では、本装置の各機能
に対応する「〜部」などの仮想的回路ブロックとして本
装置を説明する。なお、ＣＰＵは、プログラムで指定さ
れたとおりに、コンピュータの各種ハードウェア資源を
利用しながら、前記各仮想的回路ブロックの作用を実現
する。

【００５８】ハードウェア資源の典型例として、ＣＰＵ
には、バス及び入出力制御回路を介して、ＲＡＭなどの
記憶素子からなるメモリ、ハードディスクドライブなど
の補助記憶装置、入力装置としてマウスやキーボード、
出力装置として表示装置やプリンタを接続することが考
えられる。また、コンピュータは、ネットワーク接続機
器を介してネットワークに接続される。但し、これらハ
ードウェア資源は例示に過ぎず、情報の記憶・入力・出
力などの目的を達成できる他の各種装置を用いることも
できる。

【００５９】１．第１実施形態 以下、本発明の実施の形態（以下「実施形態」という）
である情報処理装置（請求項１〜５に相当するもの）及
び情報処理方法（請求項６に相当するもの）について、
図面を参照して説明する。

【００６０】なお、本実施形態の目的は、ソフトウェア
の構成要素の変化に柔軟に対応し、かつ、回線障害に対
する耐障害性に優れた情報処理装置及び情報処理方法を
提供することである。また、本実施形態の他の目的は、
柔軟な運用が可能な情報処理装置及び情報処理方法を提
供することである。また、本実施形態の他の目的は、処
理の効率に優れた情報処理装置及び情報処理方法を提供
することである。

【００６１】（１）構成 ［ハードウェアの構成］図１は、本実施形態の構成を示
す機能ブロック図である。この図に示すように、第１実
施形態では、ノードＬ，Ｒを含む複数のノードがネット
ワークＮで接続されている。ここでは、要求記述が入力
され、処理が開始されるノードＬをローカルマシン、ロ
ーカルマシンからエージェントが移動する先のノードＲ
をリモートマシンと呼ぶ。そして、情報処理に用いるソ
フトウェアの構成要素はこれら複数のノードに分散して
配置され、ソフトウェア上の実行主体であるエージェン
トがいずれかの前記ノード上で活動することによって情
報処理を行う。

【００６２】各ノードＬ，Ｒは、構成要素へのアクセス
に用いるローカル情報（前記第１の情報に相当するも
の）を格納するローカル情報記憶手段１（１Ｌ及び１
Ｒ、以下同様。前記第１の記憶手段に相当するもの。）
と、前記格納されているローカル情報を更新する更新手
段２と、を有する。また、各ノードＬ，Ｒは、エージェ
ント情報（前記第２の情報に相当するもの）を格納する
ためのエージェント情報記憶手段３と（前記第２の記憶
手段に相当するもの）、各種入出力を行うための入出力
手段４（情報処理に対する要求記述を入力するための前
記入力手段に相当する）と、を有する。なお、エージェ
ント情報は、エージェントの持つ挙動に関する情報であ
り、エージェント自身の挙動によって順次更新されるも
のである。

【００６３】また、各ノードＬ，Ｒは、入力された前記
要求記述を満たすためにエージェントがとるべき行動を
表すプランを、エージェント情報及びローカル情報に基
づいて、複数のアクションの集合として生成するプラン
生成手段５（前記生成手段に相当するもの）を有する。
プラン生成手段５によって生成されるプランに含まれる
アクションは必要に応じて、ノード間でのエージェント
の移動を実現するgoアクション（前記第１のアクション
に相当するもの）を含む。

【００６４】また、各ノードＬ，Ｒは、生成された前記
プラン中の各アクションに基づいて各ノードＬ，Ｒ上で
エージェントの動作を実現するプラン実行手段６（前記
実行手段に相当するもの）と、プラン中のgoアクション
に基づいて、エージェントをノード間で移動させるエー
ジェント管理部７（前記管理手段に相当するもの）と、
を有する。なお、エージェント管理部７は、生成された
プランについて判定を行う判定手段（請求項４）として
の機能を有している。

【００６５】また、本実施形態で用いられる主な情報を
次に説明する。

【００６６】［エージェント情報］…第２の情報 エージェント情報は、エージェントの挙動を制御する情
報及びこの挙動によって操作される各種の情報である。
エージェント情報として、具体的には、アクションの集
合（以下「アクション集合」という）と、集合に含まれ
る各アクションに関する情報（以下「アクション情報」
という）と、安全性に関する制約条件（以下「安全性条
件」という）と、因果リンク（前記因果関係を表す情報
に相当するもの）とを挙げることができる。まず、アク
ション集合は、生成中のプランを構成するアクションの
集合をリストで表現したものであり、アクションはエー
ジェントがとりうる動作の単位である。

【００６７】各アクションについては、アクション情報
が存在する。アクション情報は、アクションの名称と引
数（パラメタ）を表すアクション記述、アクションが実
行可能となるための前提条件を表す事前条件、実行によ
る状態変化の内容を表す事後条件を含み、これらはいず
れも項又は項のリストで表される。

【００６８】安全性条件は、アクション集合中の各アク
ションについて、アクション間の実行順序の制限を表す
条件であり、アクション記述の対のリストで表現され
る。すなわち、安全性条件を構成する各対は、１番目の
要素は２番目の要素よりも前に実行すべきである、とい
う制約をあらわす。アクション集合のリスト中の順序と
実際の実行順序とは無関係であり、実行順序はこの安全
性条件の制約を受けるのみである。

【００６９】因果リンクはアクション集合中の各アクシ
ョンに対し、１つのアクションの実行により成立した事
実により、別のアクションが実行可能となる、といった
因果関係を示す情報で、アクション記述、そのアクショ
ンにより成立する事実を表す項、およびその事実の成立
により実行可能となるアクション記述の３つの組のリス
トで表現される。

【００７０】アクション情報の例を次に示す。 アクション記述：grep(File,Keyword) 事前条件：[file-exists(File)] 事後条件：[add(include(File,Keyword))] この例において、アクション記述"grep(File,Keyword)"
は、"grep"という名称の動作で、"File"という名称のフ
ァイルについて、文字列"Keyword" が含まれているかど
うか検索し、含まれていた場合に事後条件を実現する、
という動作を表す。事前条件は、そのアクションを実行
するときに成立していなければならない条件を表す。こ
の例の事前条件"file-exists(File)" は、前述の状態記
述と同じ書式で、"File"という名称のファイルが存在す
るという事実を表す。

【００７１】事後条件は、一般にはアクションの実行に
よって発生する事実を表し、この例では、文字列がファ
イル含まれていたときに限って発生する。この例の事後
条件"add(include(File,Keyword))"の中で、"include(F
ile,Keyword)" は"File"という名称のファイルが、文字
列Keyword を含む、という事実を表す。"add()" は、括
弧内に記述された事実（ここでは"include(File,Keywor
d)" をエージェントの知識として追加する動作を表す。
なお、逆に知識を削除する動作は"del()" のように表
す。

【００７２】［ローカル情報］…第１の情報 ローカル情報記憶手段２には、ローカル情報が格納され
る。本実施形態におけるローカル情報は、構成要素にア
クセスするための情報で、項と呼ばれる記号列で表現し
たものである。本実施形態では、以下のような例で示さ
れる状態記述が、ローカル情報記憶手段２に格納されて
いるとする。なお、状態記述は、ソフトウェアの構成要
素に関する何らかの事実を表す情報である。 maybe(file-exists(file1) at node1) この例において、"maybe()" は、括弧内に記述された事
実が未確認であることを表す。また、"file-exists(fil
e1) はfile1"なるファイル名を持つファイルが存在する
ことを示す。また、そのあとの"at node1"は、"node1"
なるノード名を持つマシンにおいて、前述の事実（ファ
イルfile1 の存在）が成立することを示す。状態記述
が"maybe()" であるときは、前述の事実（マシンnode1
におけるファイルfile1 の存在）の正否を、マシンnode
1 に移動して確認する必要がある。ここでは、ノード名
node1 は、リモートマシンＲのノード名であるものとす
る。

【００７３】なお、このようなローカル情報の更新は、
例えば、システムの管理者が、各マシンにおいて構成要
素が変更された際に、手動で情報を更新することによっ
て行うことができる。このようにすれば、具体的事情に
合わせて入力内容を調整することによって、柔軟な運用
が可能となる。

【００７４】また、ローカル情報は、プログラムによっ
て、ネットワーク中の構成を表すファイルリストなどを
参照することによって自動的に更新することもできる。
このようにすれば、変更の検出とローカル情報の更新が
自動的に行われるので、手作業で情報を入力する手間を
省くことができ、処理が効率化される。

【００７５】以上のようなエージェント情報及びローカ
ル情報は、上記のような文字列テキストの形式で格納し
ておくことが考えられるが、必要に応じて予約語をコー
ドに置き換えるなど、他の内部形式で格納しておくこと
もできる。

【００７６】（２）作用及び効果 上記のような構成を有する本実施形態において、情報処
理は次のように行われる。

【００７７】［要求記述の入力］図３に、本実施形態に
よる情報処理の処理手順のフローチャートを示す。ま
ず、情報処理によって達成すべき状態の記述を、ユーザ
が入出力手段１から要求記述として入力する（ステップ
２０１）。入力された要求記述は、エージェント情報記
憶手段３に格納される。ここで、要求記述は１つもしく
は複数の項から構成される。要求記述の一例を次に示
す。 file-exists(File) at Node include-keyword(File,patent) この例の１行目"file-exists(File) at Node" はNodeと
いうノード名のマシン上において、Fileという名称のフ
ァイルを見つける、という要求を表す。また２行目は、
Fileがpatentというキーワードを含んでいることを要求
している。したがって、本要求記述は、patentというキ
ーワードを含むファイルをネットワークから探して、そ
のファイル名とノード名を特定する、という要求を表す
こととなる。

【００７８】［初期化］次に、エージェント管理部７は
初期化処理を行う（ステップ２０２）。すなわち、エー
ジェント情報記憶手段３内のアクション集合、安全性条
件、および因果リンクとして、それぞれ下記のような情
報を区別して格納する。 アクション集合：[*start*,*end*] 安全性条件：[(*start*,*end*)] 因果リンク：[]（空リスト） さらに、エージェント情報記憶手段５に対し、次の情報
をアクション情報として追加・格納する。まず、初期状
態のうち、"maybe()" で表された条件（maybe条件と呼
ぶ）以外のもののリストを、"*start*" というアクショ
ン名を持つアクションの事後条件とする。

【００７９】また、初期状態のうちの"maybe(cond at n
ode)" （condおよびnodeは、それぞれ具体的な条件およ
びノード名を意味する）の形の条件に対し、次のような
アクション情報を追加する。 アクション名：go(node) 事前条件：[] 事後条件：[add(cond at node)] すなわち、maybeを取り除いた条件を事後条件とするgoア
クションを定義する。これは、特定のノードで実行すべ
きアクションの事前条件を事後条件としてエージェント
が前記特定のノードへ移動するアクションを前記アクシ
ョン集合に追加することを意味する。

【００８０】たとえば、本実施形態においては、次のよ
うなアクション情報を追加する。

【００８１】アクション名：*start* 事前条件：[] 事後条件：[] アクション名：go(node1) 事前条件：[] 事後条件：[add(file-exists(File) at node1)] 事後条件：[]

【００８２】［プランの生成］続いて、プラン生成手段
５によって、要求記述を満足するためのプラン生成が行
われる（ステップ２０３、請求項２，３）。プラン生成
は、ローカル情報を参照しながら、エージェント情報を
更新することによって行われ、更新されたエージェント
情報がプランとなる。なお、プラン生成の手順は、エー
ジェントの転送に関する部分を除いて、従来から知られ
るプランニング技術（参考文献１：大須賀節雄編「人工
知能大事典」９７９ページから９８８ページ）によって
行う。このプランニングは、ロボットなど外界を変更す
る能力を持つ行為主体について、与えられた目標を達成
するための行動プランを作成することである。プランニ
ングのために与える入力は、外界の初期状態、外界を変
化させる様々なアクション（行為）及び一つ又は複数の
目標である。

【００８３】本実施形態におけるプランニングの手順
を、図３のフローチャートに示す。まず、未達成ゴール
の有無を調べる（ステップ３０１）、ここで未達成ゴー
ルというのは、アクション集合を構成する各アクション
の事前条件のうち、因果リンクにおいて成立する事実と
して記録されていない条件を項で表したもののリストで
ある。本実施形態では、最初因果リンクが空であるの
で、アクション"*end*" の２つの事前条件が未達成ゴー
ルとなる。

【００８４】未達成ゴールが存在しない場合はプラン生
成を終了するが、存在する場合は、未達成ゴールから１
つサブゴールとして選択する（ステップ３０２）。本実
施形態では、たとえば"file-exists(File) at Node" を
サブゴールとして選択する。次にステップ３０２におい
て、選択したサブゴールに対し、事後条件において該サ
ブゴールを達成するようなアクションを列挙する。

【００８５】ここで条件がサブゴールを達成するとは、
該条件の変数に適当な項を代入することにより、該サブ
ゴールと一致させることができる、ということであり、
さらに具体的には、選択したサブゴールの事前条件と変
数以外の要素が一致する事後条件を持つアクションを意
味する。たとえば本実施形態では、アクション"go(node
1)" のみを列挙する。

【００８６】そして、アクションが１つでも列挙できた
かどうかを判定し（ステップ３０４）、できなかった場
合には、いわゆるバックトラック処理として、サブゴー
ル選択をやり直す（ステップ３０２）。

【００８７】そして、列挙したアクションから１つ選択
し（ステップ３０５）、選択したアクションについて、
他のアクションの事前条件を損なうものについては、選
択されたアクションをサブゴールの条件に合わせて因果
リンクに追加する。また、他のアクションの事前条件を
損なうものであってかつ当該他のアクションの実行前に
当該事前条件が損なわれることを阻止する安全性条件を
追加できるものについては、選択されたアクションをサ
ブゴールの条件に合わせて因果リンクに追加するととも
に当該安全性条件を追加する。

【００８８】これらの処理は、具体的には次のように行
う。まず、該アクションのアクション情報に基づき因果
リンク及び未達成ゴールを更新する（ステップ３０
６）。因果リンクの更新は、前述の代入を、該アクショ
ン情報の要素（アクション記述、事前・事後条件）に施
し、アクション記述、サブゴール、およびサブゴールを
事前条件とするアクションのアクション記述の組を、因
果リンクに追加することにより行う。そして同時に、該
アクション情報の事前条件を、新たに未達成ゴールに追
加する。たとえば本実施形態では、アクション"go(node
1)" を選択し、その結果、因果リンク、および未達成ゴ
ールを以下のように更新する。 因果リンク：[(go(node1),file-exists(File) at node
1,*end*)] 未達成ゴール：[include-keyword(File,patent)]

【００８９】［脅威の検出］次にステップ３０７におい
て、選択したアクションによって、他の因果リンクの条
件、すなわち他のアクションが前提とする状況を損なう
かどうかを調べる（ステップ３０７）。損なう場合、こ
れを脅威と呼ぶ。本実施形態では、選択したgoアクショ
ンは、条件を損なわない。すなわち、goアクションが一
般に条件を損なうわけではなく、この場合はノード移動
によって不可能になるアクションがないからである。

【００９０】脅威が存在する場合、この脅威を回避する
ための安全性条件の更新が可能かどうかを判定する（ス
テップ３０８）。ここで、安全性条件の更新が可能なの
は、次のような場合である。

【００９１】例えば、因果リンクに追加した組（アクシ
ョン１，条件，アクション２）に対し、対（アクション
１，アクション２）を安全性条件に矛盾なく追加でき、
かつ脅威が存在する場合は、すなわち他の因果リンク
（アクション３，条件２，アクション４）に対し、アク
ション１が条件２を損なう場合に、対（アクション３，
アクション１）もしくは（アクション４，アクション
１）を安全性条件に矛盾なく追加できる場合である。

【００９２】そして、安全性条件更新が不可能な場合に
は、更新した因果リンクおよび未達成ゴールの状態を更
新前に戻し（ステップ３１０）、いわゆるバックトラッ
クとして、アクションの選択からの処理をやり直す。安
全性条件更新が可能な場合は、ステップ３０９において
上述した安全性条件の更新（対の追加）を実行する。

【００９３】本実施形態では、対"(go(node1),*end*)"
を矛盾なく安全性条件に追加できるので、更新の結果安
全性条件は"[(go(node1),*end*),(*start*,*end*)]" と
なる。その後再びステップ３０１からの処理を繰り返さ
れる。このように、必要なローカル情報を参照しながら
処理を繰り返すことによって、全ての未達成ゴールの一
つ一つについて、当該未達成ゴールに対応する全てのア
クションについて、因果リンクへの追加が試みられるこ
とになる。

【００９４】すなわち、アクションは事前条件が満たさ
れた状態で実行でき、実行の結果、事後条件を発生させ
る。そこで、目的とする状態を事後条件として発生させ
るアクションを、因果リンクによって目的とする状態に
接続し、さらに、接続したアクションの事前条件を事後
条件として発生させるアクションをさらに接続する。こ
のように実行順序とは逆に遡って接続を繰り返せば、目
的とする状態を実現するための動作系列が得られる。こ
のように、本発明によれば、単純な処理を単位としてプ
ラン生成を行えるので、処理が効率化される。

【００９５】［エージェント情報の更新］本実施形態に
おいては、繰り返し手順終了後に、エージェント情報記
憶手段３に格納された情報が以下のように変化する。 アクション集合：[grep(File,patent),go(node1)] 安全性条件：[(grep(File,patent),*end*), (go(node1),*end*),(*start*,*end*)] 因果リンク：[(grep(File,patent), include(File,patent),*end*), (go(node1),file-exists(File) at node1,*end*)] 未達成ゴールリスト：[file-exists(File)] このエージェント情報の内容を表すツリー図（プラン
木）を図４に示す。

【００９６】［プランの判定］以上のようにプランが生
成されると（図２、ステップ２０３）、プランの生成に
関して判定が行われる（ステップ２０４、請求項４）。
このとき、未達成ゴールが存在しかつアクション集合が
空の場合はプランの生成は失敗と判定される。また、未
達成ゴールが存在しない場合は、生成が成功で、プラン
を実行するまでもなく要求記述が達成されたと判定され
る。また、未達成ゴールが存在しかつアクション集合が
空でない場合は、プランの生成は成功でかつプランの実
行が必要と判定される。

【００９７】プランの生成が成功で要求記述が達成され
ている場合と、プランの生成そのものが失敗の場合は、
エージェントは入出力手段４よりユーザにその旨を出力
し（ステップ２０５）、全手順を終了する。なお、エー
ジェントが当初のローカルマシンＬから移動し、リモー
トマシンＲにおいて要求記述が達成され又はプランの生
成に失敗したときは、エージェントはローカルマシンＬ
に戻ってその旨の情報を出力する。このように、本実施
形態では、プラン生成の結果が判定され、判定結果に応
じた処理が選択できるので、処理が効率化される。

【００９８】［プランの実行］プランの実行では、プラ
ン実行手段６が、goアクション以外の実行可能なアクシ
ョンを探す（ステップ２０６）。実行可能なアクション
は、アクション集合中のアクションのうち、その時点の
状態によって事前条件が満足され、かつ安全性条件に関
しても他のアクションより後で実行する必要がないもの
である。

【００９９】goアクション以外の実行可能なアクション
があれば（ステップ２０７）、そのアクションが実行さ
れ（ステップ２０８）、再度ステップ２０６からの手順
が実行される。goアクション以外の実行可能なアクショ
ンがないときは、goアクションが一つ実行される（ステ
ップ２０９）。

【０１００】このように、本実施形態では、goアクショ
ンの実行に先立って、goアクション以外の実行可能なア
クションが実行されるので、エージェントを元のノード
に再度転送する処理が最小限となり、処理が効率化され
る。

【０１０１】本実施形態の例では、プランの実行が開始
された時点で、goアクション以外のアクションとして"g
rep(File,patent)" が存在する。しかし、この時点では
このアクションは、事前条件が未達成であるためにこの
アクションは実行できず、結果的にgoアクション以外の
実行可能なアクションがない。このため、アクション"g
o(node1)" が実行される。

【０１０２】goアクションが解釈実行されると、プラン
実行手段６がその旨をエージェント管理部７に通知し、
エージェント管理部７は次のようなエージェント転送処
理を行う。

【０１０３】［エージェントの転送］エージェントを転
送するときは、ローカルマシン側のエージェント管理部
７Ｌ（以下「ローカル側」という）とリモートマシン側
のエージェント管理部７Ｒ（以下「リモート側」とい
う）との間で、ネットワークＮを通じ、次のような手順
が実行される（請求項５）。図５はエージェントを転送
する手順を示すフローチャートである。

【０１０４】まず、ローカル側からリモート側へ、エー
ジェントの受け入れ要求が送信される（ステップ５０
１）。リモート側は、要求を受信すると（ステップ５０
２）、エージェント用のプロセスを設定することによっ
てエージェントを受け入れる準備を行なった後（ステッ
プ５０３）、ローカル側に準備完了の通知を送信する
（ステップ５０４）。

【０１０５】ローカル側は、準備完了の通知を受信する
と（ステップ５０５）、エージェント情報記憶手段３内
のエージェント情報を読み出し、リモート側に送信する
（ステップ５０６）。（転送されるエージェント情報
は、goアクションが解釈実行された時点におけるエージ
ェントの内部状態を含む。）リモート側は、エージェン
ト情報を受信すると（ステップ５０７）、受信したエー
ジェント情報をエージェント情報記憶手段３に格納し
（ステップ５０８）、プラン実行手段６にその旨を通知
することによって解釈実行を開始させ（ステップ５０
９）、エージェント受け入れが成功した旨の通知をロー
カル側に送信する（ステップ５１０）。

【０１０６】ローカル側は、成功の通知を受信すると
（ステップ５１１）、エージェントのプロセスを消去し
（ステップ５１２）、不要になったメモリなどの資源を
開放することによって、エージェントの転送を終了す
る。

【０１０７】本実施形態の例では、転送後のリモートマ
シンnode1 において、ローカル情報記憶手段１に、以下
のような情報が格納されているものとする。 file-exists(file1) さらに、事実マシンnode1 にはfile1 なるファイルが存
在し、しかも文字列patentを含んでいるものとする。こ
の場合、エージェントはマシンnode1 に移動後、改めて
初期化からプラン生成の手続きを実行する。その結果、
エージェント情報記憶手段に格納された情報は、以下の
ように変化する。 アクション集合：[grep(file1,patent)] 安全性条件：[(grep(file1,patent),*end*), (*start*,*end*)] 因果リンク：[ (*start*,file-exists(file1),grep(file1,patent)), (grep(file1,patent),include(file1,patent),*end*)] 未達成ゴールリスト：[] これにより、プラン生成成功となり、アクションgrep(f
ile1,patent)の実行によりプラン実行成功となるので、
エージェントはローカルマシンに戻ってユーザにその旨
の情報を出力する。図６に実行結果の出力例を示す。こ
の例では、表示用のウインドウ中に、最終的なゴール５
００としての要求記述と共に、実行結果５０１が表示さ
れている。

【０１０８】また、仮にファイルfile1 が他のマシンに
移されていても、代わりに"maybe(file-exists(file2)
at node2)"などの情報がローカル情報記憶手段に格納さ
れていれば、再プランニングによりマシンnode2 にエー
ジェントが移動して、目的を達成することができるの
で、環境の変化にも柔軟に対応しうる。

【０１０９】以上のように、本実施形態によれば、エー
ジェントの挙動はプランによって定まるので、エージェ
ントの動作系列をユーザが記述する必要がなく、情報処
理が効率化される。

【０１１０】特に、各構成要素のアクセス先となる具体
的なノードなどは、プラン生成の際にローカル情報に基
づいて決定される。このため、機能やファイルに変更が
あっても、その変更がエージェントの挙動に反映され
る。また、ローカルマシンとリモートマシンの間で情報
のやり取りを続ける必要はないので、ネットワークのノ
ード間の接続切断など、予期せぬ状況の変化にも対応し
て処理が続行される。

【０１１１】２．第２実施形態 第２実施形態は、第１実施形態と略同様（図１）の構成
を有する情報処理装置について、その構成及び作用をよ
り具体的に示すもので、特に、移動先ノードにおいて
も、プラン実行の失敗時など必要に応じて、再度のプラ
ンニングが行われるものである。

【０１１２】（１）構成 （１−１）全体構成 第２実施形態は、第１実施形態と同様、ネットワークに
接続された複数のノード上で、ソフトウェア上の実行主
体であるエージェントが動作することによって情報処理
を行う情報処理装置である。図７は、第２実施形態にお
いて、ネットワークＮに接続された各ノードの構成を示
す機能ブロック図である。この図に示すように、各ノー
ドは、フィールド知識ベース１１と、ノード知識ベース
１２と、プランナ１３と、実行器１４と、ノードマネー
ジャ１５と、更新器１６とを有する。

【０１１３】すなわち、まず、各ノードは、ノードに配
置された構成要素へのアクセスに用いるための第１の情
報としてローカル情報を有する。データベースであるフ
ィールド知識ベース１１とノード知識ベース１２は、ま
ず、この第１の情報を記憶するもので、第１実施形態に
おけるローカル情報記憶手段に対応する。すなわち、ロ
ーカル情報は、エージェントの種類ごとに対応する複数
のフィールドに区分された部分と、ノード固有の部分と
があり、それぞれ、フィールド知識ベース１１とノード
知識ベース１２に記憶されている。フィールドは、特定
の種類すなわち目的や分野のエージェントのみが利用す
る情報のグループである。

【０１１４】なお、第２実施形態では、各知識ベース１
１，１２には、前記のローカル情報に加え、エージェン
トがとりうるアクションに関する第２の情報も記憶され
ている。プランナ１３は、これら第１及び第２の情報に
基づいて、与えられた目的を達成するためにエージェン
ト１７が実行すべきプランの作成（プランニング）を行
う部分で、第１実施形態におけるプラン生成手段に対応
する。

【０１１５】実行器１４は、作成されたプランの実行を
行う部分であり、第１実施形態におけるプラン実行手段
に対応する。また、ノードマネージャ１５は、エージェ
ント１７の生成／消滅及びノード間における移動を実現
するための部分で、第１実施形態におけるエージェント
管理部に対応する。なお、各ノードのプランナ３及び実
行器１４は、他のノードから移動してきたエージェント
についても、プランの実行及び必要なプランの作成を行
う（請求項８，１３）。

【０１１６】なお、第１の情報で表される情報は、ノー
ド上のソフトウェア要素に関するもので、具体的には、
そのノードの状態や、ノードに存在するファイル、デー
タベース、保有するソフトウェア等である。また、アク
ションに関する第２の情報はノード毎に定義される。

【０１１７】プランナ１３は、エージェントのプランを
作成する際、当該エージェントに対応するフィールドの
情報に基づいて作成するように構成されている。また、
ノードマネージャ１５は、ノード間における移動の際、
エージェントが移動先のノードにおける対応するフィー
ルドに移動するように構成されている（請求項９）。な
お、エージェントを移動先の所定のフィールドに移動さ
せるには、プラン中に含める移動命令において、命令の
パラメータなど所定の形式でフィールドを指定すればよ
い。

【０１１８】また、更新器１６は、プランニング、プラ
ンの実行又はプランに基づく移動が失敗した場合に、失
敗の原因となった情報を修正するための部分で、第１実
施形態における更新手段に対応する。

【０１１９】また、ノードは、利用者インターフェース
としてＧＵＩ（グラフィカルユーザインタフェース）ア
プリケーション１８を用いる。ここで、利用者インター
フェースは、ユーザがエージェントの状態を直接監視す
るために用いるソフトウェアで、第１実施形態における
入出力手段に対応する。エージェントはソフトウェア上
の実体であるため、ユーザがその状態を参照したり、制
御するためには、ユーザーインターフェースを有するソ
フトウェアが必要となり、このソフトウェアとして、Ｇ
ＵＩアプリケーション１８を用いるものである。また、
ノード毎のメモリなど資源の管理に関する情報は、ノー
ド管理情報記憶手段１９に記憶される。

【０１２０】ここで、第２実施形態において例として用
いる具体的なノード構成の想定を図８に示す。この例に
おいては、ネットワークＮに、node0, node1, node2 と
いう３個のノードＸが接続された情報処理装置を想定す
る。各ノードＸには、makeという名称のフィールドＦが
存在し、その他のフィールドは省略する。すなわち、第
２実施形態におけるノード構成の例は、例えば、複数の
人手によるソフトウェア開発等において、ネットワーク
上に分散して作成される複数のソースファイルを、ある
必要な時点において特定のノードに集積することを想定
したもので、特に、その中の一部の処理を取り出して説
明するものである。

【０１２１】なお、図８に示すように、エージェントＡ
は、当該エージェントＡに固有の状態又はアクションに
関する情報を持ち、この情報はエージェント内の知識ベ
ースＤＡに記憶されている。エージェントＡは、ノード
間の移動の際もこれら情報を運搬し、運搬しているこれ
ら情報をプランニングに用いる（請求項１０）。

【０１２２】（１−２）エージェントの概略的構成 エージェントは、システムの利用者、又は本システムを
利用する別のソフトウェアが、ゴールを与えることによ
って、ノード上に生成されるプロセスである。なお、ノ
ードとは、エージェントの移動の単位を指しており、抽
象的な概念である。１台のホストに対して、１つのノー
ドが存在することを通常の想定とするが、１台のホスト
に対して複数のノードが存在することもありうる。ユー
ザは、ノードに対し、ネットワークにおいて唯一となる
ノード名を与えておく。この場合、ノード名としては、
ＵＲＬ等の既存のコンピュータネットワークのネーミン
グ手法によってつけられた名称と同じ名称を与えること
が可能である。また、上記の「プロセス」は、計算機上
でソフトウェアを実行する単位であり、オペレーティン
グシステムによって管理される。

【０１２３】図９は、エージェントを、Plangentのモバ
イル・エージェントとして構成する場合の環境を示すも
ので、ノードがフィールドに区分されている状態を示す
概念図である。フィールドに区分されるのは実際にはノ
ード毎に格納されている第１の情報や第２の情報である
が、これらの情報はプラン作成やプラン実行などエージ
ェントの活動の基礎すなわち活動の場としての役割を持
つ。したがって、ノード上の情報が区分されることによ
って、当該ノード上には、エージェントの活動の「場」
であるフィールドが複数存在することになる。

【０１２４】図に示す環境構成の要素は、ホストＨ上に
常駐するノードＸ、ノードＸ内を分割するフィールド
Ｆ、ネットワークＮを介してノードＸを移動するエージ
ェントＡなどである。

【０１２５】このようなエージェントの目的は、情報処
理の目的として所定の表現形式で与えられたゴールを満
たすことにある。ゴールの一例は、他のどこかのノード
にあるはずの特定のファイルを探して、コピーを持ち帰
ることである。このために、エージェントは、与えられ
たゴールを満たすプランを生成し、実行する。エージェ
ントは、ゴールの達成のために必要であれば、他のノー
ドに移動することが可能である。エージェントによるこ
れらプラン作成やプラン実行、ノード間の移動などの処
理は、具体的にはプランナ１３、実行器１４、ノードマ
ネージャ１５などによって実現される。

【０１２６】そして、生成されたエージェントは、最終
的にゴールを達成するか、ゴール達成不可能となるか、
いずれかの状態に至り、消滅する。ゴールを達成した場
合をエージェントの正常終了と呼び、ゴール達成不可能
となった場合をエージェントの完全失敗と呼ぶ。消滅の
際に、終了時処理が行われる。

【０１２７】図１０に、エージェントの活動における複
数のフェーズを説明する状態遷移図を示す。すなわち、
生成されたエージェントは、その後、プランニング・フ
ェーズＰ、実行フェーズＥ、移動フェーズＭの３つのフ
ェーズを繰り返しながら、情報処理を行う。

【０１２８】（１−３）エージェントの論理構造 次に、第２実施形態におけるエージェントの論理的な構
造を図１１に示す。すなわち、エージェントは、エージ
ェント名、対応するフィールドのフィールド名、所有フ
ァイルなどのデータを有する。なお、所有ファイルはエ
ージェントが自己の一部として所有するファイルで、他
のノードへ移動したエージェントがファイルのコピーを
所有ファイルとして元のノードへ持ち帰ることによっ
て、例えば、先に例として示したファイルを収集する目
的において、効果的な情報収集が可能となる。また、エ
ージェントは、これらに加えて、次のような他の構成要
素を有する。

【０１２９】まず、ゴールスタックＳは、プランニング
を階層的に実施するために、実行途上のゴールを積み上
げたスタックである。ゴールスタックは、ゴール・スク
リプト・セットの集合として保持される。ゴール・スク
リプト・セットは、最終的なゴールやサブゴールと、そ
れら各ゴールを達成するためのプランのスクリプトのセ
ットであり、エージェントがその時点において所有して
いる全てのスクリプトを含む。

【０１３０】また、エージェント知識ベースＤＡは、エ
ージェントがプランニングにおいてノードの知識ベース
及びフィールドの知識ベースととともに使用する知識ベ
ースである。また、図１１の「その他」の要素として
は、例えば実行情報が挙げられる。実行情報は、エージ
ェント名、フィールド名、スクリプトにおける実行位
置、およびスクリプトで用いられる変数の値などの情報
である。また、「その他」の情報としては、終了時処理
の指定等の情報も考えられる。これらの情報を表す具体
的なデータ構造は、エージェントのフェーズによって異
っていてよい。例えば、移動フェーズ中にはネットワー
ク上の通信内容として、実行フェーズ中には記憶媒体に
おけるファイル構造として、プランニングフェーズでは
プログラム上のデータ構造として計算機上のメモリ上に
記憶される。

【０１３１】ゴールをスタック構造で表すのは、ユーザ
が与えたゴールが、一般にプランニングによって階層的
な構造をとるためである。すなわち、新たに作成される
サブゴールは、エージェントの内部においてスタックの
形式により階層的に保有される必要がある。そのゴール
スタックを構成するゴール・スクリプト・セットのデー
タ構造を図１２に示す。

【０１３２】この図において、「ゴール」は、エージェ
ントを利用するユーザ、又は別のソフトウェアが与える
要求である。任意のゴール・スクリプト・セットについ
てみれば、ゴールは、サブゴールである場合も考えられ
る。すなわち、「サブゴール」は、最初にエージェント
に与えられたゴールを満たすために必要な条件を分解し
たゴールである。

【０１３３】第２実施形態で作成されうるサブゴールに
は、失敗時サブゴールとプランニング時サブゴールの２
通りが考えられる。失敗時サブゴールとは、エージェン
トによるスクリプトの実行中に、特定のコマンドの実行
が失敗した場合に、別の態様でそのコマンドの実行を試
行するために生成するサブゴールである。この場合、例
えば、ファイルの所在地として第１候補のノードでファ
イル発見に失敗した場合、第２候補のノードでファイル
を発見することがサブゴールである。

【０１３４】プランニング時サブゴールとは、通常のプ
ランニングの結果としてサブゴールがスクリプトに含ま
れるものである。例えば、ファイルの発見と持ち帰りが
ゴールの場合、まず、ファイルの発見や、発見のために
他のノードへ移動することがサブゴールとなる。

【０１３５】サブゴールは、さらにサブゴールを持つこ
とが可能であり、ゴールは全体として階層的な構造を有
する。「ゴールスタック」は、実行中のエージェントが
保有するもので、階層的ゴール構造を管理するスタック
である。エージェントは、その生成時に与えられた最終
的ゴールとサブゴールとを階層的に保有する。

【０１３６】（１−４）ノード・マネージャ 上記のようなエージェントの管理を行う部分がノード・
マネージャ１５である。ノード・マネージャは、ノード
を管理するモジュールで、特に、エージェントの生成及
びノード間におけるエージェントの移動などの処理を行
う。このような処理を行う際に、ノードマネージャは、
他のノードのノードマネージャと必要に応じて通信を行
う。この通信におけるインタフェースを以下、ノード間
インタフェースと呼ぶが、第２実施形態では、インター
ネット・プロトコルスーツにおけるTCP によるポートを
用いて実装し、名称をノード・ポートと呼称するものと
する。各ノードマネージャは、それぞれのポートにおい
てサーバとして機能する。

【０１３７】また、ノードマネージャは、自らが生成し
たエージェントとも通信を行う。この通信におけるイン
タフェースを以下、ノード＝エージェント間インタフェ
ースと呼ぶ。第２実施形態では、ノード・マネージャの
ノード・ポートを用いて、ノード＝エージェント間イン
ターフェースを実装し、ノード・マネージャ側をサー
バ、エージェント・プロセス側をクライアントとする。

【０１３８】図１３は、ノードマネージャ１５を中心と
して、ノード＝エージェント間通信及びノード＝ノード
間通信を実現するための構成例を示す図である。各ノー
ドには、エージェントの状態を出力するためのソフトウ
ェアモジュールであるモニターＭＮが設けられ、ノード
マネージャ１５は、モニターＭＮに対して、表示の指示
となるモニター・スクリプトを送信する。なお、第２実
施形態におけるポートの名称をモニター・ポートＭＰと
呼称する。ノード・マネージャ側がサーバ・ポートと
し、モニターＭＮ側をクライアント・ポートとする。以
下、特に断らなければ、単にノードポートと呼称した場
合は、同一ノード内のノード・ポートＮＰを指す。各通
信ポートにおける通信プロトコルは、定められた所定の
デリミタによって区切られる下記の語より構成される。

【０１３９】まず、実施例によるノード間インタフェー
スのプロトコルを表に示す。

【表１】

【０１４０】また、実施例によるノード＝エージェント
間インタフェースのプロトコルを表に示す。

【表２】

【０１４１】ノード・マネージャは、モニターによるエ
ージェントの監視のために、モニター・ポートよりモニ
タースクリプトを出力する。この通信ポートについて
は、クライアントであるモニターよりセッションがサー
バであるノードマネージャに張られる。モニターは、モ
ニタースクリプトを受け取り、ユーザ・インタフェース
の更新を行うことができる。モニタースクリプトの出力
内容は、基本的には、ノード・ポートに対するアクセス
に応じて、次に示すような形式を定めている。

【表３】

【０１４２】すなわち、モニターは、ノード・マネージ
ャからエージェントに関する状況報告をモニタースクリ
プトの形で受け取り、エージェントの状況をユーザに提
示する。なお、当然ながら、モニターとのサーバ、クラ
イアント関係が確立されていない場合は、ノードマネー
ジャはモニタースクリプトの出力を行わない。フローチ
ャートに示した手順は、すべてモニターとの接続が確立
していることを仮定する。すなわち、接続が確立してい
ない場合には、以下のプロトコルに従った通信を行う必
要はないことはいうまでもない。

【０１４３】（１−５）知識ベース 知識ベースは、宣言的な記述方法によるデータベースで
ある。第２実施形態においては、より具体的にはProlog
言語におけるファクトの集合をさす。ここで、図１４
は、知識ベースの構成を示す概念的ブロック図である。
この図に示すように、第２実施形態の知識ベースには、
アクションベースＤ１と情報ベースＤ２の２種類があ
る。アクションベースＤ１は、プランニングにおいて必
須となるアクションの集合である。情報ベースＤ２は、
プランニングにおいて必須となるシステムの初期状態を
記憶する知識ベースであり、いずれの知識ベースも、ア
クションによって更新することができる。

【０１４４】アクションベースＤ１及び情報ベースＤ２
は、それぞれ、エージェント固有の部分、フィールドに
区分された部分、ノード固有の部分を有し、それぞれ、
エージェントアクションベースＤ１Ａ及びエージェント
情報ベースＤ２Ａ、フィールドアクションベースＤ１Ｆ
及びフィールド情報ベースＤ２Ｆ、ノードアクションベ
ースＤ１Ｎ及びノード情報ベースＤ２Ｎと称する。な
お、フィールドは、エージェントの異なった目的ごとに
応じた部分であり、一つのフィールドには、共通の目的
を有するエージェントが対応する。知識ベースをフィー
ルドに区分しておくことによって、異なった複数の知識
ベースを１つのノード内に構成する働きを持つと共に、
一つのエージェントのプランニングに、必要な情報だけ
を用いることによって、プランニングを効率よく実施す
る効果がある。

【０１４５】また、一般に、知識表現において、矛盾す
る記述の存在は、意味論的な困難を引き起こす。フィー
ルドによる知識ベースの区分は、フィールド毎に、意味
論上の表現を統一しやすくすることにより、エージェン
トによるプランニングの円滑な実施とアクション定義の
容易な記述を促進する効果がある。

【０１４６】すなわち、アクションベースと情報ベース
のそれぞれについて、ノードに所属する知識ベース、フ
ィールドに所属する知識ベース、エージェントに所属す
る知識ベースの３種類の知識ベースが存在する。

【０１４７】また、第２実施形態ではPrologの用語を用
いて説明する。Prolog言語については、Leon Sterling,
Ehud Shapiro 著The Art of Prolog 他、多数の解説書
があるが、第２実施形態におけるProlog言語記述は、標
準的な記述方法のみを用いて記述している。なお、Prol
og言語では、大文字で始まる名前は変数であり、マッチ
するアトムatom又はアトムの組み合わせである項によっ
て置き換えられる。

【０１４８】なお、以下では、所定のノードからみて他
のノードに関する情報すなわちmaybe 情報を用いて、エ
ージェントがプランニングを実施し、どのように変化す
るネットワークに対応して挙動を行うかについて例を用
いて説明する。maybe 情報はProlog言語を用いて実装で
きる。すなわち、知識ベースに記憶された情報のうち、
maybe という種別の情報（maybe 情報）は、一応想定さ
れるが未確認の事実を表す。maybe はフィールド情報ベ
ースまたはノード情報ベースに格納される。

【０１４９】一方、本システムにおけるノード・マネー
ジャ、すなわち図１におけるエージェント管理部は、異
なったフィールドに対応する様々な種類のエージェント
を扱うように構成されており、例えば、エージェントに
は、その生成時において、エージェントの役割すなわち
種類に応じたフィールドが指定される。そして、第２実
施形態では、フィールド毎に知識ベースを区分すること
によって、プランニングで用いる知識の総量を少なくす
ることが可能であり、結果としてプランニングの効率を
高める効果がある。

【０１５０】（１−５−１）アクションベース アクションベースは、エージェントが取りうるアクショ
ンをその事前条件と事後条件とを合わせて定義したアク
ション定義の集合であり、アクションの集合には、ノー
ド間でのエージェントの移動を実現する移動命令とし
て、goアクションが含まれる。実行器がコマンドとして
goアクションを実行した場合には、エージェントはネッ
トワーク上のノード間で移動し、移動の前後で一貫した
プランの実行を行う。

【０１５１】そして、アクションベース中において、一
つのアクションに関する情報は、アクションの内容に加
えて、アクション定義名、事前条件、事後条件及びから
構成される。このうち、まず、アクション定義名は、ア
クションの名前と引数（アクションのパラメータ）を、
項により表現したものである。また、事前条件は、アク
ションが実行可能となるための条件を、項のリストによ
り表現したものである。また、事後条件は、アクション
を実行した結果の状態変化を、やはり項のリストにより
表現したものである。

【０１５２】アクションに関する情報は、例えば、以下
に示す形式によって表現できる。第２実施形態では、Pr
ologの述語actionを用いて、この記述がアクション定義
であることを示している。 action( < アクション定義名>, <アクション>, <事前条
件>, <事後条件> ). ここで、＜アクション＞は、実行器によって実行可能な
コマンドによって構成される。すなわち、以下に示すよ
うに複数のコマンドの列によって構成することができ
る。

【０１５３】（１−５−２）アクションベースにおける
記述形式の例 ここで、第２実施形態におけるPrologを用いたアクショ
ンベースの記述形式の例を、ノードのアクションベース
を例として示す。エージェントアクションベース、およ
びフィールドアクションベースの記述形式も同様であ
る。 /****************************************************** アクション集合 action( アクション定義名，［アクションを構成するコマンド］，［事前条件］ ，［事後条件］) ******************************************************/ action(goto , [ goto(Node, maybe(exist(file(F),Node)) ) ], [ home(HomeNode), maybe(exist(file(F),Node)) ], [ add(seeking_for(file(F),HomeNode,Node)) ] ). action(goto , [ update_agent_base( add( myself, returning ,HomeNode)), goto_with_goal(HomeNode, return) ], [ have(file(F)) ], [ add( bringing(file(F),HomeNode) ) ] ).

【０１５４】なお、プランニングでは、アクションベー
ス中に定義された各アクションから、ゴール達成に必要
なアクションを抽出して、プランを構成するスクリプト
すなわちアクションの列が作成される。

【０１５５】（１−５−３）情報ベース 第２実施形態における情報ベースＤ２も、アクションベ
ースの場合と同じく、エージェント情報ベースＤ２Ａ、
フィールド情報ベースＤ２Ｆ、ノード情報ベースＤ２Ｎ
の総称であり、ネットワーク上のソフトウェア資源に関
する事実の記載の集合である。例えば、エージェント情
報ベースＤ２Ａは、エージェントの挙動について、どの
ような動作をこれまでに完了したか等、主にその履歴に
関する情報を格納する情報ベースである。また、フィー
ルド情報ベースＤ２Ｆは、そのフィールドに固有のソフ
トウェア資源について、そのノードにおいてどのような
処理が可能かを表現する情報ベースである。また、ノー
ド情報ベースＤ２Ｎは、そのノードにおいて、どのよう
な処理が可能か、どのようなリソースを有しているかに
関する記述が格納されているデータベースである。もち
ろん、各情報ベースには、それ以外の情報を必要に応じ
て格納することも可能である。

【０１５６】なお、エージェント情報ベースＤ２Ａ及び
エージェントアクションベースＤ１Ａを合わせてエージ
ェント知識ベースＤＡと称する。また、フィールド情報
ベースＤ２Ｆ及びフィールドアクションベースＤ１Ｆを
合わせてフィールド知識ベースＤＦと称する。同様に、
ノード情報ベースＤ２Ｎ及びノードアクションベースＤ
１Ｎを合わせてノード知識ベースＤＮと称する。

【０１５７】（１−６）プランナ プランナは、情報処理の目的として与えられたゴールに
基づいてプランニングを行い、ゴールを満たすプランと
してスクリプトを出力とする部分で、エージェントの機
能の一部を構成する。ここで、プランニングは、エージ
ェントによる行動プログラムの生成を指す。また、プラ
ンは、プランニングによって生成されたアクションの列
であり、スクリプトは、プランを記述したソフトウェア
上のデータ構造又はファイルである。スクリプトは、ス
クリプト・コマンドを用いて記述される。すなわち、ス
クリプト・コマンドは、スクリプトに記述されている実
行命令である。

【０１５８】第２実施形態の場合、プランニングの内容
は、ノードおよびフィールドおよびエージェントが固有
に有する知識ベースに蓄えられた事前条件、事後条件の
組（アクション定義）を用いて、与えられたゴールに到
達するアクションの列を生成することとなる。なお、プ
ランナは、必要に応じて再プランニングを行う。再プラ
ンニングは、実行が失敗した場合などに、エージェント
の行動プログラムを再度生成する処理である。

【０１５９】プランニングは、ユーザより付与されたゴ
ールと、アクション集合が格納されたアクションベース
および現在の状態表現を表す情報ベースの内容を利用す
ることによって実施可能となる。プランナは、これらの
情報を入力とし、スクリプトを出力としてプランニング
を実施するモジュールである。

【０１６０】プランナは、プランニングに際して、アク
ションベースと情報ベースのそれぞれについて、エージ
ェント知識ベース、フィールド知識ベース及びノード知
識ベースを読み込み、それらの内容をマージした上でプ
ランニングを行う。

【０１６１】なお、ここで行われるプランニングの処理
は公知のものを用いればよい（参考文献：S.C.Shapiro,
Encyclopedia of Artificial Intelligenceにおけるpl
anningの頁を参照）。なお、プランナを実装する一例と
して、Prolog言語を用いて実装する場合のPrologプログ
ラムを以下に示す。 /******* プランニングの定義 ***************/ plan( Goal, Node ) :- plan( Goal, Node, Node, _ ), halt. plan( Goal, Node ) :- halt. plan( Goal, Home, Node, PL ) :- plan1( Goal, Home, Node, PL ), reverse(PL, PL2), tell(′script′), writePlanList( PL2 ), nl, told, write(′script = "′), write(′script′), write(′"′),nl. plan( Goal, Home, Node, PL ) :- tell(′script′), writePlanList( [[′%no′]] ), nl, told, write(′script = "′), write(′script′), write(′"′),nl. plan1( Goal, Home, Node, PL ) :- info(_,_), !, infoList( Home, Info0 ), goal( Goal, Home, Node, Info0, Info, [], PL, [Goal], _ ). plan1( _,_,_,[[′%no′]] ) :- !, write(′There are no info.′), nl. goal( G, _, _, Info, Info, PL, PL, AGL, AGL ) :- member( G, Info ). goal( G, H, N1, Info0, [G|Info], PL0, [P1|PL], AGL0, AGL ) :- action( _, P1, Pre, [add(G)]), goals( Pre, H, N2, Info0, Info, PL0, PL, AGL0, AGL ). goals( [], _, _, Info, Info, PL, PL, AGL, AGL ). goals( [G|GL], H, N, Info0, Info, PL0, PL, AGL0, AGL ) :- goal( G, H, N, Info0, Info1, PL0, PL1, AGL0, AGL1 ),!, goals( GL, H, N, Info1, Info, PL1, PL, AGL1, AGL ). infoList( Node, L ) :- setof( Info, info(Node,Info ), L ). /******* 完成したプランに含まれるアクションの各コマンドを、 スクリプトファイルとして出力 **************/ writePlanList( [] ) :- !. writePlanList( [A|L] ) :- !, writePlan( A ), writePlanList( L ). writePlan( [] ) :- !. writePlan( [A|L] ) :- !, emitCommand( A ), writePlan( L ). emitFileList([]). emitFileList([F|FL]) :- emitFileName(F), write(′ ′), emitFileList(FL). emitFileName( file(FileName, Ext) ) :- !, write(FileName), write(′.′), write(Ext). emitFileName( DB ) :- !, write(DB). emitCommand( comment(G) ):- emitCmd( comment(G) ). emitCommand( X ):- emitCmd( X ),nl. emitCmd( update_field_base(A) ) :- !, write(′%update_field_base ′), write(′"′),write(A),write(′" ′). emitCmd( update_agent_base(A) ) :- !, write(′%update_agent_base ′), write(′"′),write(A),write(′" ′). emitCmd( check(F,Node,R) ) :- !, write(′%check ′), emitFileName(F), write(′ ′),write(Node), write(′ "′),write(R), write(′"′). emitCmd( check_with_goal(F,SG) ) :- !, write(′%check ′), emitFileName(F), write(′ "′),write(SG), write(′"′). emitCmd( check_and_redo(F,SG,[G]) ) :- !, write(′%check_and_redo ′), emitFileName(F), write(′ "′),write(SG), write(′" "′),write(G), write(′"′). emitCmd( goto_with_ack(N) ) :- !, write(′%goto_with_ack ′), write(N). emitCmd( goto(N) ) :- !, write(′%goto ′), write(N). emitCmd( goto(N, at(P,NN)) ) :- !, write(′%goto ′), write(N), write(′ "remove(′), write(NN), write(′,′),write(P),write(′) "′). emitCmd( goto(N, Reason) ) :- !, write(′%goto ′), write(N), write(′ "′),write(Reason), write(′"′). emitCmd( goto_with_goal(N, G) ) :- !, write(′%goto_with_goal ′), write(N), write(′ "′),write(G), write(′"′). emitCmd( wait_and_goto(N) ) :- !, write(′%wait_and_goto ′), write(N). emitCmd( put(F) ) :- !, write(′%put ′), emitFileName(F). emitCmd( get(F) ) :- !, write(′%get ′), emitFileName(F). emitCmd( rename_file(F,G) ) :- !, write(′rename ′), emitFileName(F), write(′ ′), emitFileName( G). emitCmd( plan_and_exe(G,C) ) :- !, write(′%plan_and_exe "′), write(G), write(′" "′), write(C),write(′"′). emitCmd( fail(M) ) :- !, write(′%fail "′), write(M), write(′"′). emitCmd( comment(G) ) :- !. emitCmd( display ) :- !,write(′%display′). emitCmd( X ) :- !, write( X ). /****** prolog述語定義 *******/ setof(X,G,L) :- setUp, G, setPush(X), fail. setof(X,G,L) :- setPop(L). reconsult(F) :- [F]. append( [], X, X ). append( [A|X], Y, [A|Z] ) :- append( X, Y, Z ). reverse( [], [] ). reverse( [A|X],Z ) :- reverse(X,Y),append(Y,[A],Z). member( X, [X|_] ). member( X, [_|L] ) :- member( X, L ).

【０１６２】（１−７）実行器 実行器は、前記のプランナによって作成されたプランの
スクリプトを解釈実行する部分である。すなわち、概念
的には、エージェントがプランナーを用いて生成したス
クリプトに対し、スクリプトの中に記述されるアクショ
ンの列をコマンドの列として解釈、実行する実行器を前
記エージェントが保有し、エージェントはプランナーと
実行器の両者を制御して動作する。

【０１６３】実行器における実行方式および動作技術は
一般のインタプリタ言語に準じたものである。第２実施
形態における実行器は、本質的にUNIXオペレーティング
システムにおけるcsh に準じており、スクリプトを入力
することによって、スクリプトの内容を行単位で実行
し、出力として実行ステータスを返す。実行器によって
解釈実行されるスクリプトコマンドとしては、次に挙げ
るようなものを例示することができる。

【０１６４】（１−７−１）csh と共通の働きをもつコ
マンドの例 まず、csh と共通の働きをもつコマンドの例のとして
は、以下のものが存在する。これらのコマンドは、例え
ばUNIXシステム上であれば、csh を呼び出すことによっ
て処理することが可能であるが、もちろん他の言語処理
系を用いて実装することも可能である。

【表４】

【０１６５】（１−７−２）制御構造、変数の処理 第２実施形態におけるスクリプトの実行は、原則とし
て、スクリプトの先頭から末尾に向かって順に１行に１
コマンドずつ実行を行うが、次の制御構文を用いて、条
件分岐や繰り返し処理を実施することができる。動作の
セマンティクスや式の記述方法の詳細は、Ｃ言語仕様の
サブセットである。

【表５】

【０１６６】（１−７−３）エージェント・コマンド 実行器は、モバイル・エージェントとして必要な処理を
実現するために、次のようなコマンドをスクリプトの内
部で使用することができる。なお、第２実施形態におい
ては、実行器を拡張することによって、コマンドの種類
を拡張することができる。

【表６】

【０１６７】なお、表６最下欄における「サブゴールを
ゴールスタックにつみ」の意味は、図１１で示した通
り、サブゴールの他に、現在のスクリプト、スクリプト
の実行位置、スクリプトで用いている変数の値を、一ま
とまりのゴール・スクリプト・セットとしてスタックに
積むことを意味している。このうち、goto_with_subgoa
l コマンドおよびcheck_with_subgoalコマンド、および
plan_and_exeは、サブゴールつきコマンドである。サブ
ゴールつきコマンドは、ノード間でエージェントを移動
させる移動命令の一種で、移動失敗時に代替手段として
実行すべきサブゴールがあらかじめ指定されている移動
命令である。

【０１６８】一方、表６の上から２番目の、「移動の根
拠となった情報ベースの情報」を伴うgoto命令は、根拠
付きのコマンドである。一般に、特定のゴールが与えら
れたエージェントがプランニングを実施した際、プラン
ニングにおいて採用されるアクションすなわちコマンド
は、その事前条件が、各種知識ベースにおいて満たされ
ていることが必要となる。その事前条件は、maybe 情報
であってもよい。ただし、maybe 情報は、実際のネット
ワークにおいて真である保証はないため、エージェント
がプランニングを終了した後、できあがったスクリプト
を実行する時点において、前提であるmaybe 情報の記述
内容が異なっている場合があり得る。根拠付きコマンド
とは、実行時に判明したmaybe 情報の誤りを訂正する働
きを含むコマンドである。すなわち、「移動の根拠とな
った情報ベースの情報」を伴うgoto命令とは、その移動
が実行できなかった場合に、プランニング時点における
事前条件が異なっていたものと判定し、表６に示す通り
引数に与えられた情報ベースの情報を削除する働きを持
つコマンドである。

【０１６９】同様に、表６におけるcheck コマンドも根
拠付きコマンドである。check コマンドは、それを実行
するエージェントが存在するノードにおいて、その第一
引数に示すファイルが存在しなかった場合は、第三引数
に示す情報が誤っていたものとみなし、第二引数に示す
情報ベースより削除する動作を行う。

【０１７０】これらの根拠付きコマンドの作用は、この
コマンドを実施したエージェントによる再プランニング
や、後の動作例に示す通り、後続する別のエージェント
による再プランニングの際に有効となる。

【０１７１】（１−７−４）情報ベースの更新述語 表６におけるupdateコマンドは、更新器１６（図７）へ
のインタフェースの役割を果たし、第２実施形態におけ
るエージェント知識ベース、フィールド知識ベース、ノ
ード知識ベースの内容の更新を行う。更新述語には、次
の表の通り２種類がある。

【表７】

【０１７２】更新述語は、エージェントが挙動すること
によって新しく得られた知見を元に、情報ベースの内容
を更新するための指示語である。更新述語が存在するこ
とによって、変化するネットワークにおける情報の更新
を、エージェント自身が実施することによって、そのエ
ージェント自身の再プランニングや、後続する他のエー
ジェントによる類似したゴールに対するプランニング
を、新しい情報に基づいて実施することが可能になる。

【０１７３】（１−７−５）簡単なスクリプトの例 ここで、以上のようなスクリプト・コマンドを用いて、
スクリプトの簡単な例を示す。このスクリプトは、ノー
ドnode1 の所定のディレクトリに存在するファイルfile
1 を、ノードnode0 に移動し、コピーするスクリプトで
ある。仮にプランナがこのスクリプトを出力したものと
すれば、エージェントは、このスクリプトを上から下へ
順に実行する。 %goto node1 %get file(file1) %goto node0 %put file(file1)

【０１７４】（２）作用 上記のような構成を有する第２実施形態は、次のような
作用を有する。まず、第２実施形態におけるエージェン
トの活動は、ゴールを与えることによって開始される
が、以下の例では、ゴールの入力に先立って、各データ
ベースに、次のような情報が入力されているものとす
る。

【０１７５】（２−１）アクション定義の例 まず、この例で用いられるフィールドのアクションベー
スの定義について説明する。以下の例は、ネットワーク
上に分散するファイルを収集するエージェントと、この
収集のためのフィールドについて説明するものである。
このような目的を達成するための５つのアクションを、
以下に示すフィールドにおいて定義する。１つのアクシ
ョン定義は、先に示したとおり、アクション定義名、ア
クション、事前条件、事後条件の組である。

【０１７６】アクション定義名は、便宜的につけた名称
である。アクション定義における「アクション」とは、
実行器のコマンドと同様、アクションによる処理の実際
の内容を表す。すなわち、アクション定義における「ア
クション」は、そのアクション定義がプランニングによ
って採用された場合、プランナーが生成するスクリプト
に含まれるコマンドで、エージェントが実行フェーズに
移ったのち、やがて実行されるものである。

【０１７７】事前条件とは、アクションを実行するため
に必要な条件である。この条件は、プランナーがプラン
ニングにおける処理において使用するものであり、エー
ジェントの実行フェーズとは直接的にはかかわりのない
ものである。

【０１７８】事後条件とは、アクションの実行の結果と
して追加される条件である。この条件は、プランナーが
プランニングにおける処理において使用するものであ
り、エージェントの実行フェーズとは直接的にはかかわ
りのないものである。すなわち、プランニングとは実行
に先立つシミュレーションである。

【０１７９】アクションベースには、フィールド毎に、
その問題領域に応じたアクション定義が事前になされて
いる必要がある。ここでは、アクションベースに、以下
に示す第一のアクションから第五のアクションまでの５
つのアクションが定義されているものとする。すなわ
ち、以下に説明するアクションベースは、事前にnode0,
node1,node2 の各ノードに配布されているものである。
なお、各ノードに対するアクションベースの配布や訂正
を、第２実施形態によるエージェントを用いて行うこと
も可能である。

【０１８０】（２−１−１）アクション：goto1 第一のアクション定義では、他のノードNodeにファイル
Ｆを獲得するための移動アクションを定義している。第
一のアクション定義の内容を次に示す。 action(goto1 , [ update_agent_base(home(HomeNode)), goto(Node, maybe(exist(file(F),Node))) ], [ maybe(exist(file(F),Node)), home(HomeNode) ], [ add(seeking_for(file(F),HomeNode,Node)) ] ). 第一のアクション定義の内容として、具体的な２つのコ
マンドが存在する。コマンドupdate_agent_base は、エ
ージェント情報ベースに対する更新操作であり、このコ
マンドが実行された場合、エージェントの情報ベース
に、ファクト info(home(HomeNode)). が追加される。この操作は、このエージェントが出発し
たノードを、エージェントに記憶させることを意味す
る。本アクション定義における２番目のアクションは、
根拠つきgotoアクションである。本アクションがプラン
ニングにおいて採用された場合、生成したスクリプトを
実行するエージェントは、先に実行器コマンドとして示
した根拠つきgotoコマンドを実行する。根拠つきgotoア
クションは、移動命令であって、当該命令の事前条件が
パラメータとして添付されたものである。

【０１８１】そして、第一のアクション定義の事前条件
は２つある。第一の事前条件は、他のノードにおけるフ
ァイルの存在に関するmaybe 述語が、情報ベース、すな
わちノード、フィールド、エージェントの３つの情報ベ
ースのいずれかに存在することである。第二の事前条件
は、Prolog変数HomeNodeを束縛し、事後条件の引数に反
映するためのものであり、エージェントの移動の状態を
事後条件に正確に反映するために必要な項目である。

【０１８２】第一のアクション定義の事後条件は、この
エージェントの状態がファイルＦをネットワークにまた
がって探索するために、HomeNodeからNodeに移動する状
態にあることをプランナに対して示すものである。な
お、このアクション定義の事後条件におけるadd は、実
行器の各updateコマンドの引数に与えられる更新述語の
add （表７）とは全く異なるものである。すなわち、本
記述におけるadd は、本システムのアクション設計者
が、プランニングに必要なプラン途上の状態を、プラン
ナに対して指示するものであるのに対し、実行器のupda
teコマンドのadd は、スクリプトが、実行器に対し、情
報ベースに対する情報の追加を指示するものである。事
後条件におけるadd 述語の意味については、以下のアク
ションについても同様である。

【０１８３】（２−１−２）アクション：goto2 第二のアクション定義は、エージェントが獲得したファ
イルＦを元のノードHomeNodeにコピーするアクションを
定義している。第二のアクション定義の内容を次に示
す。 action(goto2 , [ update_agent_base( add( myself, returning ,HomeNode)), goto_with_goal(HomeNode, return) ], [ have(file(F)) ], [ add( bringing(file(F),HomeNode) ) ] ). 第二のアクション定義のアクションは、サブゴールつき
移動コマンドgoto_with_goalである。本コマンドがプラ
ンニングにおいて採用された場合、その生成されたスク
リプトにおいて、先に示した実行器のgoto_with_goalコ
マンドが記述される。なお第二のアクションではgoto_w
ith_goalコマンドに先だち、エージェント情報ベースの
更新操作コマンドupdate_agent_base を行うが、これ
は、エージェントに対し、そのエージェントが帰還状態
にあることを、明示的にエージェントに通知する働きを
持つ。このコマンドが実行された場合、エージェントの
情報ベースに、ファクト info(myself, returning ). が追加される。このupdate_agent_base とgoto_with_go
alの２つの実行器コマンド操作は、エージェントが、現
在存在するノードからHomeNodeへ帰還する操作がネット
ワーク上の障害等により一時的に失敗した場合でも、re
turning というサブゴールによって、再プランする機会
を与える働きをもつ。

【０１８４】第二のアクション定義の事前条件は、エー
ジェントが目的のファイルＦをすでに獲得しているこ
と、すなわちhave(file(F)) である。第二のアクション
定義の事後条件bringing(file(F),HomeNode)は、このア
クションを採用した場合、エージェントの状態が、当座
の目標であるファイルＦを獲得し、HomeNodeに帰還する
状態にあることをプランナに対して示すものである。

【０１８５】（２−１−３）gotoアクション 第三のアクション定義は、何らかのネットワークの障害
のためにエージェントの移動が実施できなかった場合
に、一つの対処方法として一定時間の間隔を開けて、移
動を所定の回数試みる様なコマンドを定義している。第
三のアクション定義の内容を次に示す。 action(wait_and_goto , [ wait_and_goto(HomeNode) ], [ home(HomeNode),returning ], [ add(return) ] ). 第三のアクション定義のアクションは、一定時間の間隔
を開けて、移動を所定の回数試みるwait_and_go であ
る。本アクションがプランニングにおいて採用された場
合、その生成されたスクリプトにおいて、先に示した実
行器のgoto_with_goalコマンドが記述される。

【０１８６】第三のアクション定義の事前条件に示され
ている述語returning は、エージェントが所定の移動の
目的を達成し、元のノードすなわちHomeNodoに帰還する
状態にあることを意味している。その前に記述されてい
る述語home（HomeNode）は、変数HomeNodeを束縛する役
割を果たしている。

【０１８７】第三のアクション定義の事後条件に示され
ているreturnは、このアクションを採用した場合、エー
ジェントの状態が、HomeNodeに帰還する状態にあること
をプランナに対して示すものである。

【０１８８】（２−１−４）get アクション 第四のアクション定義は、対象（ファイルやデータな
ど）を獲得する命令（例えば、put オペレーションとge
t オペレーション）を含み、前記エージェントは、獲得
した対象を移動の際に運搬することによって、当該エー
ジェントが生成されたノードに持ち帰る。

【０１８９】すなわち、このアクションはエージェント
固有の状態に関するもので、エージェントによるファイ
ルの獲得に関するものである。このアクション定義の内
容を次に示す。 action( get , [ check(file(F), HomeNode, maybe(exist( file(F), Node))), get(file(F)) ], [ seeking_for(file(F),HomeNode,Node),maybe(exist(file(F),Node)) ], [ add( have(file(F))) ] ). 第四のアクション定義のアクションには、２つのコマン
ドが記述されている。check コマンドが、実際に実行さ
れると、エージェントが存在するノードにおいて、ファ
イルＦが実際に存在するかどうかを調べ、もしファイル
Ｆが存在しなかった場合には、エージェントのスクリプ
ト実行は失敗する。check コマンドの第一引数HomeNode
は、この確認を行う根拠となった知識ベースの存在する
個所を示し、第二引数maybe(exist(file(F),Node))は、
根拠となった知識を示す。

【０１９０】第四のアクション定義の事前条件に示され
ている述語returning は、エージェントが所定の移動の
目的を達成し、元のノードすなわちHomeNodoに帰還する
状態にあることを意味している。その前に記述されてい
る述語home（HomeNode）は、変数HomeNodeを束縛する役
割を果たしている。

【０１９１】第四のアクション定義の事後条件に示され
ているhave(file(F)) は、このアクションを採用した場
合、エージェントの状態が、HomeNodeに帰還する状態に
あることをプランナに対して示すものである。

【０１９２】（２−１−５）put アクション 第五のアクション定義は、エージェントによるファイル
のコピーに関するものである。第五のアクション定義の
内容を次に示す。 action( put , [ put(file(F)), update_field_base( add( HomeNode, exist(file(F),HomeNode)) ) ], [ bringing(file(F),HomeNode) ], [ add(exist(file(F),HomeNode)) ] ). 第五のアクション定義のアクションには、２つのコマン
ドが記述されている。put アクションは、エージェント
の所有しているファイルＦを、エージェントが現在いる
ノードにコピーする。update_field_base コマンドは、
エージェントが新しくファイルのコピーを行ったため、
そのファイルの存在に関する情報を、エージェントが現
在いるノードにおけるフィールド情報ベースに対して追
加することを示している。

【０１９３】第五のアクション定義の事前条件に示され
ている述語bringing(file(F),HomeNode)は、エージェン
トがHomeNodeに対してファイルＦを運んでいることを示
している。第五のアクション定義の事後条件に示されて
いるadd(exist(file(F),HomeNode))は、エージェントに
よるコピーが終了した事後条件として、HomeNodeにおい
てファイルＦが存在することをプランナに対して示すも
のである。

【０１９４】（２−２）情報ベースの記述例 次に、第２実施形態における情報ベースの記述例を、ノ
ードの情報ベースを例として示す。 info(node0, maybe(exist(file(file1),node1))). info(node0, home(node0)). 本情報ベースは、ノードnode0 における情報ベースの記
述例である。この情報ベースにおける第一行の記述は、
ノードnode0 において、ファイルfile1 がノードnode1
に存在するとする知識である。ただし、ノードnode0 と
ノードnode1 は異なるホストであり、この種の他のノー
ドに関する情報は、情報の更新が日々行われるネットワ
ークにおいて常に正しいとは限らない。maybe 情報と
は、このような他のノードに関する情報である。第２行
の記述は、ノードnode0 がまさしくノードnode0 である
ことを表現するために、第２実施形態において導入して
いる。この例において想定するゴールは、ノードnode0
に、ファイルfile1 を獲得することである。ファイルfi
le1 は、node1 もしくはnode2 を利用する特定の人物に
よって作成されるファイルであることが事前に判明して
いるものとすれば、ファイルfile1 が存在するノード
は、node1 か、node2 のいずれかであるものと仮定する
ことができる。この事実を、ファイルfile1 の集積地の
役割を果たすノードnode0 のフィールドmakeにおいて、
次のような情報ベースの記述内容として表現する。この
情報ベースは、第１実施形態でも述べたように、同じネ
ットワークに属する別のフィールドのエージェント、又
は別のアプリケーション・ソフトウェアを用いて、自動
的に情報ベースに付加する手段を取ることが可能であ
る。

【０１９５】この例では、簡単のために、ノードの情報
ベースおよび、ノードのアクションベースは、空である
ものと想定する。この場合、node0 におけるフィールド
makeのフィールド情報ベースは次の通りとなる。 info(node0, home(node0)). info(node0, exist(file(file2),node0)). info(node0, maybe(exist(file(file1),node1))). info(node0, maybe(exist(file(file1),node2))). ここで、述語infoは、第２実施形態において、情報ベー
ス記述であることを明示して表現する述語であり、２つ
の引数を持つ。第２実施形態における述語infoは、頭部
だけによって表現されるいわゆるPrologの事実（fact）
である。述語infoの頭部(head)の第一の引数は、どのノ
ードにおける情報であるかを明示したものであり、本フ
ィールド情報ベースの記述例においては、その内容はす
べてnode0 である。info述語の頭部の第２引数は、実質
的意味をもつ情報であり、Prologの項(term)を用いて表
現されている。本記述例は、次のような具体的な意味を
持つ。

【表８】

【０１９６】情報exist(file(file2),node0)と情報mayb
e(exist(file(file1),node1)))の違いは、前者において
は、この記述例の情報ベースが所属するnode0 に存在す
るファイルに関する情報であり、事実として情報ベース
に記載することが可能な種類の情報であるのに対し、後
者のmaybe 述語は、node0 から見て他のノードであるno
de1 に関する事実の記載であり、変化を想定するネット
ワークにおいて、node0 においては記述の正当性を常に
は保証できない情報であることを反映したものである。

【０１９７】したがって、このフィールド情報ベースの
４つのinfo述語の意味は、次の通りである。 ・このフィールドの所属するノードはnode0 である。 ・ ファイルfile2 は、node0 に存在する。 ・ ファイルfile1 は、node1 に存在すると想定する。 ・ ファイルfile2 は、node2 に存在するとも想定す
る。

【０１９８】次に、node1 におけるフィールド情報ベー
スには、次の内容が格納されてものとする。これは、fi
le1 に関しては、その存在がnode1 か又はnode2 に存在
するという、あらかじめ得られた知見に基づき、maybe
の述語とするものである。 info(node0, maybe(exist(file(file1),node2))). 同様に、node2 におけるフィールド情報ベースには、次
のmaybe 情報が格納されているものとする。 info(node0, maybe(exist(file(file1),node1))). ここで説明したmaybe 情報も、先に示したinfo述語の一
種である。各情報ベース、すなわちエージェント情報ベ
ース、フィールド情報ベース、ノード情報ベースに含ま
れるinfo述語の一部を構成する。以上の情報は、エージ
ェントがプランニングフェーズに移った際に、プランナ
に対して与えられる。これらのinfo述語は、プランナが
アクションを選択する際に必要な事前条件である。

【０１９９】（２−３）ゴールの入力とエージェントの
生成 以上のような情報を保有する第２実施形態の情報処理装
置において、ノードにゴールが与えられると、ノードマ
ネージャ１５がエージェントプロセス１７を生成し、プ
ランナ１３がプラン生成を行う。なお、第２実施形態に
おいて、プランナ１３は、ゴールを与えることによって
起動する。第２実施形態におけるPrologを用いた前記プ
ランナの実装では、ゴール記述をPrologのクエリー（質
問）として与えることによって、エージェント名をファ
イル名とするスクリプトを生成する。第２実施形態にお
けるゴールは、前述の各ベースの内容を前提する場合、 （例） exist(file(file1),node0) と記述できる。このゴールは、ノードnode0 にファイル
file1 を獲得することであり、換言すれば、現状ではノ
ードnode0 には存在していないファイルfile1 を、いず
れかの他のノードよりコピーすることによりnode0 に存
在させることを意味する。

【０２００】このゴールをプランナに投入することの具
体的な実施例としては、前記のプランナに対し、次のよ
うなクエリーを発行することである。このゴールは、先
に示したアクションベース、および情報ベースと組み合
わせることによって有効となる。

【０２０１】 （例） :-plan(exist(file(file1),node0),_). エージェント生成は、このゴール記述をnode0 のフィー
ルドmakeのノードマネージャ１５に対して与えることに
よって実行される。この操作は、所定の入出力手段を通
じて行われる。

【０２０２】ここで、エージェントの生成を含むノード
マネージャの動作手順を図１５に示す。ノードマネージ
ャは、当該ノードに存在するエージェント（アクティブ
・エージェント）を登録するリスト（アクティブ・エー
ジェント・リスト）ＡＬを有する（図１３）。そして、
ノードマネージャ１５は、図１５に示すように、他のノ
ードマネージャやエージェントプロセスからの指示とし
て、ノード・ポートＮＰ（図１３）から通信内容を受け
取り（ステップ１５０１〜１５０５）、指示として与え
られる文字列stringの内容に応じて（ステップ１５０６
〜１５１０）、エージェントの生成（ステップ１５１
１，１５１２）、消滅（ステップ１５２１，１５２２）
又は移動など（ステップ１５３１〜１５５３）の処理を
行い、アクティブ・エージェント・リストを更新する。

【０２０３】なお、ノードマネージャは、このように送
られる語の内容を解釈することによって各々のインタフ
ェースの処理内容を決定するが、語をどのように転送す
るかには、さまざまな方式がありうるので、所望の方式
を自由に採用してよい。

【０２０４】エージェントマネージャ１５によって生成
されたエージェント・プロセス１７（図７）は、ノード
マネージャ１５によって生成／管理されながら、全体と
して、エージェントＡの動作を実現する。なお、ノード
マネージャ１５は、エージェント・プロセス１７を同時
に複数生成することができる。

【０２０５】エージェントの生成後、ノード・マネージ
ャ１５によってエージェント名がそのエージェントに与
えられる。エージェントはネットワーク内のノード間で
移動するので、エージェントを識別するためには、エー
ジェント名は、ネットワーク内における唯一の名称であ
る必要がある。ノード・マネージャ１５は、そのノード
名、時刻、およびそれまでに生成したエージェントの数
等の情報を組み合わせて、ネットワークにおけるユニー
クなエージェント名を、生成したエージェントに与え
る。生成されたエージェントは、以下に説明するよう
に、プランニング、実行、移動の３つのフェーズを有
し、必要に応じてそれぞれのフェーズに入る。

【０２０６】（２−４）プランの作成 ゴールが与えられてエージェントが生成されると、プラ
ンナ１３が、与えられたゴールに対するプランニングを
実施する。すなわち、最初にゴール exist( node0, file(file1)). が所定の入出力装置から与えられることによってエージ
ェントが生成され、エージェントは、プランニングフェ
ーズに入る。すなわち、エージェントはゴール・スクリ
プトセットをゴールスタックに積み、プランナ１３を起
動することによってプランニングを実施する。

【０２０７】図１６は、プラン作成の内容をフローチャ
ートの形式で示した概念図で、公知であるプランニング
技術を説明した図である。すなわち、第２実施形態にお
けるプランナ１３は、ゴールより後ろ向き推論を実施
し、事前条件と事後条件を参照しながら、ゴールを満た
すアクション系列を求める。なお、図１６は、言い換え
れば、実際のプランニングの動作を簡素化して記述した
ものであり、実際のPrologの動作において発生する変数
とアトムの同一化（unification ）等の動作を省略して
簡素化して記述したものである。

【０２０８】このプランニングでは、第１実施形態と同
様に、ゴールを事後条件とするアクション定義を探索す
る。次に、見つかったアクション定義中の事前条件をそ
れぞれゴールとして、そのゴールを事後条件とするアク
ション定義を探索する。してプランのスクリプトに書き
出し、書き出したアクションをゴールとして、さらに同
様の手順を繰り返すことによってプランを作成する。す
なわち、具体的には、ゴールから（ステップ１６０
１）、アクションput,goto2,get,goto1 を辿って全ての
条件が満たされるまで（ステップ１６０２〜１６０
５）、手順を繰り返す。この探索は、ゴールから現在の
状態に向かって逆向きに行っているため、選択されたア
クション定義を選択した順序とは逆向きにして、それら
のアクション定義中のアクションの内容、すなわちコマ
ンドの並びを、スクリプトとして生成する。なお、この
とき、どのようなアクション定義の順序をとっても全て
の条件を満たすことができなかった場合が、プランニン
グ失敗である。

【０２０９】図１５の処理によって、node0 のフィール
ドmakeのフィールド知識ベースおよびnode0 のアクショ
ンベースに基づき、次のようなプラン結果がスクリプト
として得られる。左端の数字は、行番号である。 1 %update_agent_base "add(myself, home(node0))" 2 %goto node1 "maybe(exist(file(file1), node1))" 3 %check file(file1) node0 "maybe(exist(file(file
1), node1))" 4 %get file(file1) 5 %update_agent_base "add(myself, returning, node
0)" 6 %goto_with_goal node0 "return" 7 %put file(file1) 8 %update_field_base "add(node0, exist(file(file
1), node0))"

【０２１０】なお、プランナ１３は、表６のコマンドgo
to（２番目）に示すように、プランの一部としてエージ
ェントをノード間で移動させる移動命令を作成する際
に、当該命令の前提となる事前条件を添付する（請求項
１１）。すなわち、node1 への移動の根拠が "maybe(exist(file(file1),node1))" であることを意味している。なお、事前条件を移動命令
に添付する場合、事前条件の全部又は一部を移動命令の
付属パラメータとする。

【０２１１】このように、第２実施形態では、移動命令
に事前条件が（根拠として）添付される。そして、当該
移動命令に基づく移動が失敗する場合は、命令が前提と
した事前条件が成立していなかった可能性が最も大き
い。この事前条件は、命令に添付されているので、命令
を参照すれば容易に判明する。このため、移動失敗への
対応が容易になる。

【０２１２】なお、プランナ１３は、ノードのアクショ
ンベースおよび情報ベース、フィールドのアクションベ
ースおよび情報ベース、エージェントのアクションベー
スおよび情報ベースを、プランニングの実施に先立って
読み込む。第２実施形態では、以上を総称して知識ベー
スと呼ぶ。第２実施形態におけるPrologを用いた実装に
おいては、既に示したように、各情報ベースの情報をPr
ologの節により表現しているので、プランニングに先立
ち、以上のすべての知識ベースをPrologのアサートを用
いて、読み込むことにより、プランニングを実施するこ
とができる。

【０２１３】前記のクエリーにより、ファイル名 ′scr
ipt′ というスクリプトが一度生成される。そして、エ
ージェント・プロセスは、その該当する固有のエージェ
ント名によってファイル名をつけかえ、他の同時に存在
するエージェントのスクリプトと区別する。もちろん、
複数のエージェントが同時にプランニングを実施した場
合は、両者は平行プロセスとなるため、ファイルの生
成、削除において、エージェントの動作の同期が必要と
なるが、適切なロック機構を導入することによって、複
数のエージェントが同一のノードに存在することが可能
である。

【０２１４】プランニングは、ゴールの内容、ノードの
知識ベース、フィールドの知識ベース、移動の知識ベー
スの内容によって、成功する場合と失敗する場合とがあ
る。成功の場合は、プランニングの出力であるスクリプ
トが生成され、エージェントは実行フェーズに移る。な
お、エージェントは生成時に与えられたゴール以外に、
途中での失敗を回復するなどのためのサブゴールを複数
格納できるゴールスタックを有している。そして、サブ
ゴールのプランニングに失敗した場合は、より上位のゴ
ールによってプランニングを実施する。最終的にすべて
のプランニングに失敗した状態が完全失敗である。完全
失敗の場合は、エージェントは終了処理される。

【０２１５】なお、プランニングの結果、前掲のスクリ
プトを得るので、エージェントは、これをゴールスタッ
ク最上段のゴール・スクリプトセットに格納する。次
に、エージェントは実行フェーズに移る。

【０２１６】プランニングでは、最終的な目的であるゴ
ールを達成するための中間的なゴールを作成し、この中
間的なゴールを達成するための子エージェントを生成す
るようにしてもよい（請求項１２）。このようにすれ
ば、中間的なゴールの作成が子エージェントに依託され
るので、エージェント毎の情報処理の内容が単純化され
ることによって、情報処理が効率化される。また、複数
のエージェントが並行または並列動作することによっ
て、情報処理が迅速化される。

【０２１７】（２−５）プランの実行 スクリプト記述を生成すると、エージェントは実行器１
６を用いて実行フェーズに入る。後述するように、スク
リプトは、制御構造を有するコマンドの列である。実行
フェーズにおけるエージェントは、スクリプトを制御構
造にしたがって解釈し、順にコマンドを実行する。

【０２１８】図１７は、プランを実行する手順を示すフ
ローチャートである。この手順では、スクリプトが終了
するまで実行行番号を増大させながら１行ずつコマンド
を読み出し（ステップ１７０１〜１７０４，１７１５，
１７１６）、移動命令ならばその旨をエージェントマネ
ージャに依頼し、移動命令以外はコマンドの種類に応じ
た処理を行う（ステップ１７０８）。なお、実行途上で
エラーが発生した場合は（ステップ１７０９）、エラー
の生じたコマンドの種類毎に所定のエラー処理を行う
（ステップ１７１０〜１７１４）。

【０２１９】すなわち、実行器１６は、スクリプトを読
み込み、一行単位でコマンドを切り出し、コマンド名お
よびスクリプトを解釈し、コマンドの種類に応じて、先
に示した表に示したコマンドを実行する。実行器が実行
するスクリプトの文法には、さまざまなバリエーション
が存在し得るが、どのような文法を解釈する実行器を使
用するかに関しては、本発明の本質とはかかわりなく、
表に示すような移動コマンドおよび表に示す情報ベース
の更新を伴うコマンドや、根拠となった情報を明示する
コマンドが実行器に用意されている点に特徴がある。こ
れらのコマンドが用意されていることにより、エージェ
ントに適切なサブゴールを与えたり、あるいはネットワ
ークにおける変化に伴って適切に情報ベースの更新を行
うことが可能になる。

【０２２０】コマンドの実行が失敗した場合、又は再プ
ランコマンドが実施された場合には、所定のゴールに基
づいてプランニングを行うためのプランニングフェーズ
に戻る。移動コマンドが実施された場合は、移動フェー
ズに移る。

【０２２１】（２−６）エージェントの移動 実行器１６が、実行中のスクリプトにおいて移動命令に
遭遇すると、その旨がノードマネージャ１５に通知さ
れ、エージェントが他のノードに転送される。エージェ
ントを移動するために実際に転送される情報は、スクリ
プト、エージェント、ゴールスタック、エージェント知
識ベースである。これらの情報を、すべて移動先のノー
ドに転送することに成功した場合、エージェントは、移
動先において実行フェーズに戻る。

【０２２２】（２−６−１）他のノードへのエージェン
トの移動 図１８は、他のノードへのエージェントの移動する場合
の移動元側ノードのノードマネージャの動作を示すフロ
ーチャートである。すなわち、エージェントに関する必
要な情報を収集すると共に（ステップ１８０２〜１８０
４）、移動先のノードをホストとして通信を試み（ステ
ップ１８０５，１８０８）、通信路の確立に失敗した場
合は移動をあきらめ（ステップ１８０６，１８０９）、
エージェントプロセスに対して失敗を通知する（ステッ
プ１８０７，１８１０）。通信路が確立できた場合は、
移動先に必要な情報を送信して返答を待ち（ステップ１
８１１，１８１２，１８１５）、通信路が確立できた場
合でも、相手先ノードからの返信を受け取ることができ
なかった場合は、同様に移動失敗とみなし（ステップ１
８１３）、エージェントプロセスに対して通知を行う
（ステップ１８１４）。

【０２２３】（２−６−２）他のノードからのエージェ
ントの移動 図１８の処理に対応して、移動先のノードのノードマネ
ージャは、図１９に示す処理によってエージェントを受
け入れる。すなわち、ノード・マネージャは、他のノー
ドからノード・ポートにプロトコルＭＦを受信した場
合、必要な情報を受け取って（ステップ１９０１）、新
たなエージェントに資源を割り付け（ステップ１９０
２）、新たなエージェントの情報を所定の記憶領域に保
存したうえ（ステップ１９０３）、移動元に受け入れ成
功を返答して（ステップ１９０４，１９０５）、エージ
ェントプロセスを起動する（ステップ１９０６）なお、
この処理の途上で、通信の異常が発生した場合は、Ｊａ
ｖａやＣ＋＋のオブジェクト指向言語において用いる例
外処理機構によって、処理される。

【０２２４】なお、図２０は、エージェント＝ノード間
インターフェースと、ノード＝ノード間インタフェース
を用いて、エージェントがどのように移動するかを示す
補足的な説明図である。エージェントは、ノードマネー
ジャを介して、間接的に移動を行う。

【０２２５】（２−７）失敗への対応 なお、スクリプトの実行又は移動が失敗した場合すなわ
ちプランの実行が失敗した場合、プランの実行を中断
し、再度プランを作成して実行する。失敗が発生する態
様としては、例えば、エラーや例外の発生などが考えら
れる。第２実施形態では、プランの実行や移動が失敗し
ても、再度プランが作成されるので、情報処理が円滑に
継続される。

【０２２６】具体的には、プラン中のアクションの実行
又は移動に失敗した場合、実行又は移動の失敗を回復す
るためのサブゴールを生成し、当該サブゴールの実行終
了後に前記プランの実行を再開するための情報を保存
し、前記サブゴールに基づいてプランの作成及びプラン
の実行を行い、サブゴールに基づくプランの実行後に、
保存した前記情報を用いて元のプランの実行を継続す
る。

【０２２７】例えば、goコマンドに基づくエージェント
の移動が失敗し、かつ、当該goコマンドに根拠が付加さ
れていない場合は、現在のスクリプトを生成したゴール
を、再びゴールとして用いて再度プランニングを行う。
移動が失敗する場合としては、移動先ノードへのネット
ワーク接続が確立されていない場合、又は一定時間以内
に移動が完了しない場合、又は移動先においてメモリや
ディスクスペース等の必要なリソースが確保されない場
合が考えられる。このような場合は、移動命令失敗とみ
なして、所定のサブゴールに基づくプランニングフェー
ズに戻る。

【０２２８】このような失敗は、望ましくは移動元側で
検出する。例えば、エージェントがgoコマンドを実施す
る際に、エージェントの移動を管理するノードマネージ
ャにおいて、移動先ノードの何らかの不具合により、エ
ージェントが移動できない場合に、エージェントの移動
失敗を移動元で検知する。

【０２２９】このように、失敗の際にサブゴールを作成
してプラン作成を行うことは、実行フェーズにあるとき
でも、必要に応じてプランニングフェーズに移行するこ
とを意味する。なお、保存する情報としては、元のゴー
ル、元のスクリプト、当該スクリプトの実行位置等が考
えられる。また、これら情報を保存するには、これら情
報をゴールスタックに積めばよい。そして、作成された
サブゴールのうち、もっとも下位のサブゴールよりプラ
ンニングを実施し、作成されたプランを実行する。実行
後に元のプランを再開するには、保存した前記情報をス
タックより取り出して用いればよい。

【０２３０】また、第２実施形態では、プランニング、
プランの実行又はプランに基づく移動が失敗した場合
に、失敗の原因となった情報が修正される。このため、
それ以降の失敗が減少し、処理が効率化される。例え
ば、実行器１６は、事前条件がパラメータとして明示さ
れているgoコマンドの実行が失敗した場合、当該事前条
件をローカル情報すなわちフィールド情報ベースから削
除する。

【０２３１】なお、サブゴールを作成し及び情報を修正
する態様は、アクション毎若しくは移動先毎にあらかじ
め定義された方式、又はプラン作成で用いられたいずれ
かの情報によって定義された方式に基づいて、また、ロ
ーカル情報などに基づいて定めればよい。

【０２３２】このように、失敗時への対処の場合を含め
て、第２実施形態では、プランの実行においてサブゴー
ルを作成し、サブゴールについてさらにプランの作成と
実行を行うことによって、階層的なゴールの構造を用い
て情報を処理する。この場合、エージェントは、goアク
ションによって移動する際に、階層的なゴールスタック
を伴って移動するので、移動先のノードでも移動前と同
じゴールスタックを用いて、一貫性のある動作を行うこ
とができる。

【０２３３】このような再プランニングを円滑に行うた
め、プランを構成するアクションの一種として再プラン
コマンドを用い、当該再プランコマンドは、プランの実
行中に実行されるとプラン作成手段がサブプランを作成
する。

【０２３４】なお、移動後にプランニングに失敗し、事
前条件を成立させるようなアクションが最終的に生成で
きない場合には、スクリプトの実行を失敗終了させ、移
動前のノードに戻り、スタック中に保存してあるゴール
を用いて再プランニングすればよい。また、ゴールに対
するプラン生成が最終的に不可能な場合や、又は実行不
可能なゴールを受け取った場合は、電子メール、その他
の手段により、必要に応じて発信者に通知するようにし
てもよい。

【０２３５】エラー対策の別の態様としては、前記プラ
ンを作成する手段は、プランの前提となっている事前条
件がプランの実行時に満たされているか否かを確認する
ためのスクリプトを、当該プランに加えることが考えら
れる。これによって、プラン作成時点での条件が満たさ
れていることが実行時に確認される。すなわち、プラン
ニングが行われた時点と、作成されたプランが実行され
る時点との間には、時間的な間隔が必然的に存在するた
め、プランニング時点において満たされていた条件が、
実行時にはすでに満たされていない可能性が存在する。
事前条件の確認によって、プランの適切な実行が確保さ
れる。

【０２３６】（２−８）終了処理 終了処理の一例としては、エージェントが情報処理に成
功した場合に、成功の旨のメールをゴールの発行者に送
信し、失敗の場合は、失敗した旨のメールを送付する処
理が考えられる。その他にも、終了処理として様々な実
現態様が考えられるが、エージェントの生成時に、どの
終了処理の実施形態をとるかに関して情報を付加してお
くことによって、終了処理のバリエーションを持たせる
ようにしてもよい。

【０２３７】（２−９）エージェントの詳細な動作 以上のような各作用を、エージェントを中心に示した処
理手順を図２１のフローチャートに示す。すなわち、エ
ージェントの生成時に、ノードマネージャよりゴールを
受け取るとこのゴールをゴール・スタックに積む（ステ
ップ２１０１）。ゴールスタックが空かどうかをチェッ
クし（ステップ２１０２）、ゴールスタックが空の場合
は、このエージェントが完全にゴール達成に失敗したと
判定し、後述する終了時処理を実施し、終了する（ステ
ップ２１０３）。

【０２３８】ゴールスタックが空でない場合は、ゴール
スタックよりゴールをPOP し、そのゴールに対して、後
述するプランニングを実施する（ステップ２１０４）。
プランニングが失敗した場合は、スタックの内容をチェ
ックするステップに戻る（ステップ２１０５）。

【０２３９】プランニングに成功した場合は、スクリプ
トが生成される（ステップ２１０６）。このとき、スク
リプトの実行位置を更新し（ステップ２１０７）、プラ
ンニングフェーズから実行フェーズに移る。

【０２４０】プランニング及びスクリプトの生成では、
新しくエージェントが作成された直後のプランニング、
においては新規にスクリプトが生成される。また、プラ
ンニング及びスクリプトの生成では、新規に作成された
直後のプランニングにおいては、プランニングの前の時
点に存在したスクリプトに対して、プランニングした結
果が追加される。プランニング及びスクリプトの生成に
おいて、プランニングに成功しなかった場合は、再び、
ゴールスタックが空かどうかをチェックするステップに
戻る。

【０２４１】プラン生成に成功すると、スクリプトの解
釈実行に移る。スクリプトの解釈実行は、後述するエー
ジェントの実行器によって処理される。スクリプトの解
釈実行の動作に関しては、BASIC などの一般のインタプ
リタ言語と本質的に同様のものである。実行器は、スク
リプトの現在の実行位置を次の位置に移動させる事によ
り、コマンドを読み取り、コマンドの種別、およびコマ
ンドの引数を解釈し、実行する。

【０２４２】実行器の解釈部において、現在の実行位置
のコマンドが移動コマンド（goto）であった場合は、移
動処理ステップに移る（ステップ２１０８）。移動処理
ステップにおいて、後述する移動処理を行う。移動処理
は、ノードマネージャによるノード間にまたがる処理で
あり、移動元からはエージェントが消え、移動先にエー
ジェントが復元される（ステップ２１０９）。この移動
が完了した場合は（ステップ２１１０）、移動先のノー
ドにおいて図２１のフローチャートの処理が継続され
る。

【０２４３】移動が失敗した場合は（ステップ２１１
０）、移動元のノードにおいて、移動命令が、ゴールを
伴う移動コマンドであるかどうかを調べる（ステップ２
１１４）。ゴールを伴わない移動コマンドの場合は、次
にプランニングフェーズに入るためにゴールスタックが
空かどうかを調べるステップに戻る。ゴールを伴う移動
コマンドの場合は、後述する失敗時処理を実行し（ステ
ップ２１１５）、サブゴールをゴールスタックにPUSHし
（ステップ２１１６）、再びプランニングのステップに
戻る。

【０２４４】実行位置のコマンドが移動命令でなかった
場合は（ステップ２１０８）、次に実行器はスクリプト
の終了かどうかを調べる（ステップ２１１１）。スクリ
プトが終了の場合は、エージェントの成功終了と判定
し、成功時の終了時処理を行った上で（ステップ２１１
７）、終了する。

【０２４５】ステップ２１１１においてスクリプトが終
了でない場合は、実行位置のコマンドを解釈し、実行す
る（ステップ２１１２）。この処理において、コマンド
実行が成功した場合は、ステップの処理に戻る。また、
コマンド実行が失敗した場合は、ステップ２１１４の処
理に移る（ステップ２１１３）。

【０２４６】以上は、移動するエージェントの立場より
見た挙動である。エージェントは、全体として最初に与
えられたゴールを満たすために、スクリプトを生成し、
スクリプトに基づいた一貫性のある挙動を示す。

【０２４７】（３）スクリプトの実行とノード移動の実
例 続いて、前記のプランナによって生成されたスクリプト
を実行する実行フェーズおよび移動フェーズにおけるエ
ージェントの挙動について、先述のスクリプト（以下
「第一のスクリプト」という）を具体例として説明す
る。なお、図２２は、具体例において、失敗への対応を
含めた処理を示すフローチャートである。

【０２４８】（３−１）成功例 最初に、プランニングにおける想定がすべて正しく、ま
た実行時にエラーが発生しなかった場合の成功例につい
て、具体的な動作を示す。

【０２４９】まず、先に述べたプランのうち、１行目の %update_agent_base "add(myself, home(node0))" の実行により、エージェントの情報ベースに情報、 info(myself, home(node0)) を追加する（ステップ２２０１）。この操作は、このス
クリプトの実行がこの後に何らかの理由により失敗し、
再プランニングを実施する場合に、自分自身の出発した
ノードをプランナに伝えるために必要となる。

【０２５０】次に、２行目の %goto node1 "maybe(exist(file(file1), node1))" の実行により、node1 への根拠つき移動命令であり、こ
の命令によりエージェントはノード１に移動する（ステ
ップ２２０１）。引数の根拠の効果については、後述す
る。

【０２５１】続いて、３行目の %check file(file1) node0 "maybe(exist(file(file1),
node1))" の実行により、ノードnode1 においてfile1 が実際に存
在するかどうかを確認を行う（ステップ２２０５）。こ
の例では、プランニングで想定した通り、file1がnode1
に存在したものとする。この場合は、check コマンド
の第２引数、第３の引数は意味を持たない。

【０２５２】そこで、４行目の %get file(file1) の実行により、移動した先であるnode1 からfile1 をエ
ージェントの所有ファイルとする（ステップ２２０
９）。以後、エージェントは同ファイルをput するま
で、移動とともにfile1 を持ち運ぶ。

【０２５３】５行目の %update_agent_base "add(myself, returning, node0)" の実行により、エージェントの情報ベースに情報 info(myself, returning, node0) を追加する（ステップ２２０９）。この操作は、この後
のエージェントのnode0への帰還が何らかの理由により
失敗し、再プランニングを実施する場合に、エージェン
トが帰還状態であることをプランニングに反映するため
に行う。

【０２５４】そして、６行目の %goto_with_goal node0 "return" の実行により、エージェントは、node0 に移動する（ス
テップ２２０９）。また、７行目の %put file(file1) の実行により、エージェントが所有するfile1 をnode0
にコピーする（ステップ２２１４）。最後に、８行目の %update_field_base "add(node0, exist(file(file1),
node0))" の実行により、エージェントは、node0 のフィールド情
報ベースに、info(exist(file(file1), node0)) の追加
を行う（ステップ２２１４）。以上のように、エージェ
ントは、スクリプトを実行する途上で実行失敗を起こさ
ない限り、最初に与えたゴールを満たすように動作す
る。

【０２５５】（３−２）失敗例 次に、失敗例に基づいて、再プランニング実行時のエー
ジェントの動作について説明する。node0 で行ったプラ
ンニングは、node0 において知る限りの情報を用いてプ
ランニングしたに過ぎない。実際にはネットワークに接
続される各ノードや、ネットワークの状態は、時間の経
過と共に変化するために、プランニングによって生成し
たスクリプトの実行は、その途中で失敗する可能性があ
る。

【０２５６】エージェントの実行の失敗には、次ような
理由が考えられる。 (1) 故障、保守、過負荷のためにノード又はネットワ
ークが一時的に稼動しない。 (2) エージェントがプランニングに使用した情報ベー
スの内容が誤っている。 (3) 情報ベースの内容が、時間と経過によって古くな
った。

【０２５７】図１６に示すように、本動作例において
は、次のようなケースが考えられる。 ・ node0からnode1 へのエージェントの移動が失敗す
る。 ・ ノードnode1 には、file1 が存在せず、エージェン
トがファイルを獲得できない（かわりにnode2 に存在す
る）。 ・ ファイルfile1 のnode1 からnode0 へのエージェン
トの移動が失敗する。

【０２５８】以下では、以上のケースにおいて、本発明
の一実施例である情報処理装置がどのように対処するか
について説明する。

【０２５９】（３−２−１）第１の失敗例 最初に、スクリプトの２行目%goto node1 "maybe(exist
(file(file1), node1))"において（ステップ２２０
１）、根拠つきgoto命令のnode0 からnode1 への移動が
失敗した場合について説明する（図２２の失敗シナリオ
１）。この場合（ステップ２２０２）、ノードマネージ
ャは、図１８に示した動作を行い、エージェントに対し
て移動不可能を通知する。この場合、エージェントの実
行器は、これを受けてプランニング時点において、移動
の根拠となった情報すなわち第３引数の知識をノード、
フィールド、エージェントの各情報ベースより削除する
（ステップ２２０３）。根拠の削除によって、各情報ベ
ースは次のように変化する。

【０２６０】まず、node0 のノード情報ベースは、第２
実施形態の場合には、もともと内容がないため、変化を
受けない。また、エージェント情報ベースの場合は、そ
れに先立つ第一のスクリプトの１行目のupdate_agent_b
ase コマンドの実行により、info(myself, home(node
0)).という節( 英語clause) が１つ加えられているが、
maybe 述語の節はエージェント情報ベースには存在しな
いため、何も変化を受けない。

【０２６１】一方、第１の失敗の時点におけるノードno
de0 のフィールドmakeの情報ベースの内容は、 info(node0, home(node0)). info(node0, exist(file(file2),node0)). info(node0, maybe(exist(file(file1),node2))). であるため、この作業の後、実行器は、エージェントプ
ロセスに実行失敗のステータスを返し、エージェントは
プランニングフェーズに移行する。失敗したgoto命令
は、サブゴールを持たないコマンドであるため、図２１
の動作に基づき、現在のゴールスタックの内容で、再プ
ランニングを実施する（ステップ２２０４）。

【０２６２】上記のフィールド情報ベース、およびエー
ジェント情報ベース、前述のアクションベース、前述の
プランナによる再プランニングによって、次のような第
二のスクリプトが生成される。

【０２６３】 %update_agent_base "add(myself, home(node0))" %goto node2 "maybe(exist(file(file1), node2))" %check file(file1) node0 "maybe(exist(file(file1),
node2))" %get file(file1) %update_agent_base "add(myself, returning, node0)" %goto_with_goal node0 "return" %put file(file1) %update_field_base "add(node0, exist(file(file1),
node0))" このスクリプトが第一のスクリプトと異なる点は、file
1 を取得する対象がnode1 からnode2 に変更されている
点である。

【０２６４】すなわち、実行の失敗において、情報ベー
スの更新が適切に行われない場合には、再プランを行っ
ても、第一のスクリプトと同一のスクリプトを生成し、
エージェントは同じ失敗を繰り返す恐れがある。第２実
施形態では、根拠つきgoコマンドを用いることにより、
フィールド情報ベースの内容から、file1 がnode1 に存
在するとする情報 info(node0, maybe(exist(file(file1),node1))). が削除された。このため再プラン時において、file1 が
存在し得る次の候補となるnodo2 を用いたプラン生成が
行われた。このように、第２実施形態によれば、ソフト
ウェア・エージェントに求められるエージェントの自律
性を向上し、ネットワーク上の変化へのエージェントの
対応能力を高めることが可能となる。

【０２６５】（３−２−２）第２の失敗例 次に、第一のスクリプトにおいて、node0 からnode1 へ
の移動は成功したが、node1 には、file1 が存在しなか
った場合の本動作例におけるエージェントの挙動につい
て説明する（図２２の失敗シナリオ３）。この場合は、
node1 に移動したエージェント実行器が第一のスクリプ
トの第３行目のcheck コマンドにおいて、file1 の存在
確認を行う際に、実際にはfile1 が存在しないため、実
行失敗が発生する（ステップ２２０５）。

【０２６６】check コマンドは、実行器コマンドの表で
示した通り、その第２引数が、根拠と出所、すなわち根
拠となる情報が格納されていた情報ベースの存在するノ
ードであり、その第３引数が、根拠となる情報である。
第１の失敗例と同じく、この場合にも、その根拠となる
情報の更新を実施する（ステップ２２０７）。

【０２６７】ただし、第１の失敗例の場合と第２の失敗
例の場合が本質的に異なるのは、すでにエージェントは
node1 に移動している点である。したがって、情報ベー
スの内容を更新するためには、再び元のノードに移動し
なければならない。ここでは、誤っている情報ベースが
存在するノードをcheck コマンドにおいて明示する方法
により、そのノードのフィールド情報ベースおよびノー
ド情報ベースの（両者の）更新を行うという方法をと
る。

【０２６８】このとき、情報ベースの内容を更新するた
めの実施手段としては、ノードマネージャを介したノー
ド間通信を用いた情報ベースの更新か、又は情報を更新
するゴールを別途発行し、第二のエージェントを別途生
成して、独立して動作させるという手段もある。いずれ
の場合でも、根拠付きコマンドの存在によって、情報ベ
ースの更新が可能となる。

【０２６９】node1 における再プランにおいて、使用す
る情報ベースは、ノードnode１のノード情報ベースと、
ノードnode1 のフィールドの情報ベースと、エージェン
トの情報ベースである。

【０２７０】第２の失敗例では、失敗後の更新におけ
る、エージェントの情報ベースの内容は、 info(myself, home(node0)). であり、一方、node1 のノード情報ベースの内容は空で
あり、node1 のフィールドmakeのフィールド情報ベース
の内容は、 info(node1, maybe(exist(file(file1),node2))). である。これら２つの情報から、失敗例１と同様に、元
のゴール exist(file(file1), node0)に対する再プラン
ニングを実施すると（ステップ２２０８）、第１の失敗
例と同様な次のスクリプトが得られる。異なる点は、第
１の失敗例ではエージェントはnode0 からnode2 へ移動
するのに対し、第２の失敗例ではnode1 からnode2 への
移動のプランを立てたことである。 %update_agent_base "add(myself, home(node0))" %goto node2 "maybe(exist(file(file1), node2))" %check file(file1) node0 "maybe(exist(file(file1),
node2))" %get file(file1) %update_agent_base "add(myself, returning, node0)" %goto_with_goal node0 "return" %put file(file1) %update_field_base "add(node0, exist(file(file1),
node0))" これは、エージェント情報ベースの存在により、エージ
ェントのホームノードの位置を他のノードに移動した際
に利用できるようにしているためである。このように、
移動におけるエージェントの一貫性を保持する効果があ
る。

【０２７１】（３−２−３）第３の失敗例 次に、第３の失敗例として、第一のスクリプトにおい
て、node1 にてfile1 のget までは成功したが（ステッ
プ２２０９）、最後にnode0 に帰還する移動の際にエー
ジェントの移動が失敗する場合の本動作例のエージェン
トの挙動について説明する。

【０２７２】失敗は、node1 において、第一のスクリプ
トの６行目 %goto_with_goal node0 "return" にて発生する。これは、サブゴールを伴う移動命令であ
り、ここでは、第３の引数"return"がサブゴールであ
る。したがって、本例題においては、同じ移動失敗であ
っても、エージェントによるその移動失敗への対処方法
は、第１の失敗例の場合と必然的に異なっていなければ
ならない。

【０２７３】エージェントの実行器は、図２１に示す手
順により、サブゴール付きコマンドgoto_with_goalのno
de1 からnode0 への移動失敗をノードマネージャより通
知を受けて、実行を失敗する。この場合、その時点で実
行しているスクリプトについて、現在の実行位置等の情
報とともに、サブゴール "return" をスタックにつみ、
再プランを行う（ステップ２２１１）。

【０２７４】再プラン時のエージェント情報ベースの内
容は、goto_with_goalコマンドの実行に先立って、第一
のスクリプト５行目において、内容追加が存在するた
め、次のようになる。追加された知識retruning は、エ
ージェントが、ホームノードであるnode0 に帰還する状
態にあることを明示する効果をもつ。

【０２７５】%info(myself, home(node0)). %info(myself, returning). 一方、失敗例２の場合と同じく、node1 のフィールドma
keの情報ベースの内容は、次の一行である。

【０２７６】 %info(node1, maybe(exist(file(file1),node2))). ノードnode1 のノード情報ベースの内容は空である。

【０２７７】これらの情報ベース、先に示したアクショ
ン定義およびプランナによって生成される第四のスクリ
プトは、次の１行である。 %wait_and_goto node0 このコマンドは、一定間隔を開けて移動を所定の回数試
みるコマンドである（ステップ２２１２）。ネットワー
クが一時的な不具合のため、前回のnode0 への移動が運
悪く失敗したものと想定している。本例題の、初期のエ
ージェントのゴールexist(file(file1),node2)) は、no
de0 の存在を暗に要求しており、node0がネットワーク
の変化によって、消滅した可能性まで考慮する必要はな
い。したがって、node1 からnode0 への移動失敗は、一
時的な障害であると仮定することは妥当である。

【０２７８】再プランした結果のスクリプトであるwait
_and_goto node0 を実行してもnode0 へ移動できない場
合は（ステップ２２１３）、これ以上のサブゴールはな
いため、エージェントは図２１の手順に従い、ゴールス
タックをポップし、最初のゴールexec(file(file1)), n
ode1) を用いてさらに再プランする。この場合に生成さ
れるスクリプトは、第２の失敗例の場合と同じであり、
node２に移動してからnode0 に戻る。さらに、このnode
2 へ移動するプラン実行も失敗した場合は、エージェン
トは完全失敗となる。所定の終了処理を実施し、エージ
ェントが完全失敗した事をいずれかのノードにおいて記
録する。

【０２７９】再プランした結果のスクリプトであるwait
_and_goto node0 を実行によってnode0 への移動ができ
た場合は、この第四のスクリプトは、成功して終了し、
エージェントは図２１の手続きにしたがって、ゴールス
タックをポップし、node0 において第一のスクリプトの
第７行目より実行を再開する。このようなサブゴール実
行は、この実施例におけるエージェントのnode0 への帰
還といった場合に発生した局所的な目的に対する不具合
を、移動先ノードの知識を利用して代替手段を探す効果
がある。

【０２８０】また、エージェント内のゴールスタックの
存在、およびその移動における運搬は、そうした局所的
な代替手段が成功しなかった場合に、より大きなのゴー
ルでプランニングをやり直すチャンスを与える効果があ
る。

【０２８１】アクション定義における第１のアクション
と第２のアクションは、いずれも移動命令であったが、
第一のアクションがファイルＦを捜し求めるための移動
であったのに対し、第２のアクションは、エージェント
が移動先での所定のコマンド実行を達成し、移動元に帰
還するためのアクション定義であるという違いを定義す
ることができた。

【０２８２】以上のように、第２実施形態では、第１及
び第３の失敗例に示したように、同じ移動命令の場合で
も、エージェントの文脈に応じたサブゴールを発行する
アクション記述が可能となることにより、多くの予期せ
ぬ変化に対応できる自律的なエージェントを記述するこ
とが可能となる。

【０２８３】（４）第２実施形態の効果 以上のように、第２実施形態では、エージェントがプラ
ンに基づいてノード間で移動するだけでなく、移動先の
ノードでもさらにプラン作成が行われる。このため、プ
ランの実行段階や移動先ノードの状態に応じて、情報処
理の内容が柔軟に決定され、情報処理が効率化される
（請求項８，１３，１４）。

【０２８４】また、第２実施形態では、プラン作成の
際、エージェントの種類に対応する情報のみが用いられ
るので、プラン作成が効率化される。また、ノード間で
の移動の際も、エージェントは対応するフィールドに移
動するので、移動前と同様に対応するフィールドの情報
を用いてプランの実行やプランの作成が行われる（請求
項９，１５）。

【０２８５】また、第２実施形態では、エージェントが
固有の情報と共に移動し、移動先のノードでも固有の情
報を用いるので、個々のエージェントの状態やアクショ
ンに適したプランニングが可能となる（請求項１０）。

【０２８６】３．他の実施形態 なお、本発明は、上記各実施形態に限定されるものでは
ないので、次に例示するような他の実施形態をも包含す
るものである。例えば、各ノードは相互に独立したハー
ドウェアには限定されず、単一のハードウェア上で実現
される複数のプロセスとして構成してもよい。また、エ
ージェントは一つには限定されず、複数のエージェント
が同時並行的に動作するようにしてもよい。また、情報
処理の内容はファイルの操作には限定されず、計算、推
論や他のノードとの通信など、自由に定めうる。

【０２８７】また、ローカル情報の内容は、ファイルが
存在するかも知れないノード名には限定されず、構成要
素にアクセスするためのドメイン名、ホスト名、ディレ
クトリ名、アクセス用ＩＤ、パスワードなど、自由に定
めうる。

【０２８８】エージェント情報の内容やプランの表現形
式も、前記実施形態に示したものには限定されず、自由
に定めることができる。例えば、プランを表現する場
合、因果リンクでアクションを接続する形式を取らず、
アクションの系列をリスト構造やツリー構造で保存して
もよい。また、第２実施形態において、失敗への対応の
具体的手法も例示に過ぎず自由に定めることができる。
また、本発明の実施において、知識ベースをフィールド
に区分したり、エージェント固有の情報を用いたり、移
動命令に事前条件を添付したりという構成は、必ずしも
用いる必要はない。また、本発明の実施において、子エ
ージェントの生成や、実行失敗時の再プランニングや、
実行失敗時に原因となった情報を修正する構成は、必ず
しも用いる必要はない。

【０２８９】また、適用される課題の性質に応じて、必
ずプラン生成が成功して実行を要するような要求記述を
入力する場合は、かならずしも判定手段を設ける必要は
ない。また、エージェントは必ずしもノード上のプロセ
スとして設定する必要はなく、専用のハードウェアやソ
フトウェアによって実現することもできる。

【０２９０】なお、本発明の情報処理装置及び情報処理
方法は、典型的にはコンピュータプログラムを用いて実
現されるが、そのようなプログラムを記録した記録媒体
も本発明の一態様である（請求項７，１４，１５）。

【０２９１】

【発明の効果】以上説明したように、本発明によれば、
ソフトウェアの構成要素の変化に柔軟に対応し、かつ、
回線障害に対する耐障害性に優れた情報処理装置及び情
報処理方法を提供することができる。

【図面の簡単な説明】

【図１】本発明の第１実施形態における情報処理装置の
構成を示す機能ブロック図。

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

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

【図４】本発明の第１実施形態において生成されたプラ
ンの内容を示すツリー図。

【図５】本発明の第１実施形態におけるエージェント転
送の手順を示すフローチャート。

【図６】本発明の第１実施形態における表示例を示す
図。

【図７】本発明の第２実施形態において、ノードの構成
を示す機能ブロック図。

【図８】本発明の第２実施形態において、情報処理装置
に含まれるノードの構成を示すブロック図。

【図９】本発明の第２実施形態において、ノードがフィ
ールドに区分されている状態を示す概念図。

【図１０】本発明の第２実施形態において、エージェン
トの動作を構成する複数のフェーズを示す図。

【図１１】本発明の第２実施形態において、エージェン
トの論理的な構造を示す図。

【図１２】本発明の第２実施形態において、ゴール・ス
クリプト・セットのデータ構造を示す図。

【図１３】本発明の第２実施形態において、ノードマネ
ージャに係る通信を実現する態様を示す機能ブロック
図。

【図１４】本発明の第２実施形態において、知識ベース
の構造を示す図。

【図１５】本発明の第２実施形態において、ノードマネ
ージャの動作手順を示すフローチャート。

【図１６】本発明の第２実施形態において、プランニン
グの内容をフローチャート形式で示す図。

【図１７】本発明の第２実施形態において、プラン実行
の処理手順を示すフローチャート。

【図１８】本発明の第２実施形態において、エージェン
トをノード間で移動させる場合に、移動元側のノードマ
ネージャの動作手順を示すフローチャート。

【図１９】本発明の第２実施形態において、エージェン
トをノード間で移動させる場合に、移動先側のノードマ
ネージャの動作手順を示すフローチャート。

【図２０】本発明の第２実施形態において、ノードマネ
ージャを介したエージェントのノード間移動の状態を示
す図。

【図２１】本発明の第２実施形態において、エージェン
トの動作手順を示すフローチャート。

【図２２】本発明の第２実施形態において、プラン実行
への対処内容を示すフローチャート。

【図２３】従来の情報処理装置の一例について、その構
成を示す機能ブロック図。

【符号の説明】

１…ローカル情報記憶手段 ２…更新手段 ３…エージェント情報記憶手段 ４…入出力手段 ５…プラン生成手段 ６…プラン実行手段 ７…エージェント管理部 Ｌ…ローカルマシン Ｒ…リモートマシン Ｎ…ネットワーク ＳＴＥＰ…手順の各ステップ １１，１２，Ｄ〜…知識ベース １３…プランナ １４…実行器 １５…ノードマネージャ １６…更新器 １７…エージェントプロセス １８…ＧＵＩアプリケーション １９…ノード管理情報記憶手段 Ｘ…ホスト ＦＬ…フィールド Ａ…エージェント １５０１以降…手順の各ステップ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 加賀谷 聡 東京都府中市東芝町１番地 株式会社東芝 府中工場内 (72)発明者 本位田 真一 神奈川県川崎市幸区柳町70番地 株式会社 東芝柳町工場内 (72)発明者 入江 豊 神奈川県川崎市幸区柳町70番地 株式会社 東芝柳町工場内 (72)発明者 服部 正典 神奈川県川崎市幸区柳町70番地 株式会社 東芝柳町工場内

Claims (15)

【特許請求の範囲】
1. 【請求項１】 ソフトウェア上の実行主体がネットワー
   クに接続されたノード上で動作することによって情報処
   理を行う情報処理装置において、 前記ノードに配置された構成要素へのアクセスに用いる
   ための構成要素の状態を表現する第１の情報を記憶する
   第１の記憶手段と、 前記実行主体の挙動を定義する第２の情報を記憶するた
   めの第２の記憶手段と、 前記情報処理に対して与えられた要求記述を満たすため
   に実行主体がとるべき行動を表すプランを、前記第１の
   情報及び前記第２の情報に基づいて、アクションの集合
   として、生成する生成手段と、 生成された前記プランに基づいてノード上で実行主体の
   動作を実現する実行手段と、 前記生成された前記プランを構成する前記アクションの
   うちの第１のアクションに基づいて、前記実行主体をノ
   ード間で移動させる管理手段と、 を有することを特徴とする情報処理装置。
2. 【請求項２】 前記第２の記憶手段は、 実行主体の動作の単位であるアクションの集合を記憶す
   る処理と、 前記アクションが実行可能となることを表す事前条件
   と、実行による状態変化の内容を表す事後条件とを含む
   アクション情報を記憶する手段と、 アクションの実行に関する所定の制約条件を記憶する手
   段と、 各アクション間の因果関係を表す情報を記憶する手段
   と、 を備え、 前記生成手段は、前記アクションの集合中の所定のアク
   ションに関し、前記アクション情報に基づいて、新たな
   制約条件又は前記因果関係を表す情報のうち少なくとも
   一方を、前記第２の記憶手段に記憶させる手段を備えた
   ことを特徴とする請求項１記載の情報処理装置。
3. 【請求項３】 前記生成手段は、 特定のノードで実行すべきアクションの事前条件を事後
   条件として実行主体が前記特定のノードへ移動するアク
   ションを前記アクションの集合に追加し、 アクションの集合に含まれる各アクションの事前条件の
   うち、前記因果関係を表す情報において成立する事実と
   して記録されていないものをサブゴールとして順次選択
   し、選択したサブゴールの事前条件を達成する事後条件
   を持つアクションをさらに順次選択し、 選択された各アクションについて前記新たな制約条件又
   は前記因果関係を表す情報のうち少なくとも一方を、前
   記第２の記憶手段に記憶させるように構成されたことを
   特徴とする請求項２記載の情報処理装置。
4. 【請求項４】 未達成ゴールが存在しない場合は、プラ
   ンの生成が成功で、プランを実行するまでもなく要求記
   述が達成されたと判定し、 未達成ゴールが存在しかつアクション集合が空でない場
   合は、プランの生成は成功でかつプランの実行が必要と
   判定する判定手段を有することを特徴とする請求項１記
   載の情報処理装置。
5. 【請求項５】 前記実行主体をノード上のプロセスとし
   て設定し、 各ノードの前記各管理手段は、転送元となるノードから
   転送先となるノードへ実行主体を転送するときに、 転送元から転送先へ実行主体の受け入れ要求を送信し、 受け入れ要求を受信した転送先において、実行主体用の
   プロセスを設定することによって実行主体を受け入れる
   準備を行ない、 転送先から転送元に準備完了の通知を送信し、 準備完了の通知を受信した転送元から前記第１の情報を
   転送先に送信し、 第１の情報を受信した転送先で、受信した第１の情報に
   基づいて前記プロセスの実行を開始し、 転送元において実行主体のプロセスを終了するように構
   成されたことを特徴とする請求項１記載の情報処理装
   置。
6. 【請求項６】 ソフトウェア上の実行主体がネットワー
   クに接続されたノード上で動作することによって情報処
   理を行う情報処理方法において、 前記ノードに配置された構成要素へのアクセスに用いる
   ための構成要素の状態を表現する第１の情報を記憶する
   第１の記憶処理と、 前記記憶されている所定の情報を更新する更新処理と、 前記実行主体の挙動を定義する第２の情報を記憶するた
   めの第２の記憶処理と、 前記情報処理に対する要求記述を入力するための入力処
   理と、 前記第１の情報及び前記第２の情報に基づいて、入力さ
   れた前記要求記述を満たすために実行主体がとるべき行
   動を表すプランを、アクションの集合として生成する生
   成処理と、 生成された前記プランに基づいてノード上で実行主体の
   動作を実現する実行処理と、 前記生成された前記プランを構成する前記アクションの
   うちの第１のアクションに基づいて、前記実行主体をノ
   ード間で移動させる管理処理と、 を含むことを特徴とする情報処理方法。
7. 【請求項７】 ソフトウェア上の実行主体がネットワー
   クに接続されたノード上で動作することによって情報処
   理を行う際に、 前記ノードに配置された構成要素へのアクセスに用いる
   ための構成要素の状態を表現する第１の情報を記憶する
   第１の記憶処理と、 前記記憶されている所定の情報を更新する更新処理と、 前記実行主体の挙動を定義する第２の情報を記憶するた
   めの第２の記憶処理と、 前記情報処理に対する要求記述を入力するための入力処
   理と、 前記第１の情報及び前記第２の情報に基づいて、入力さ
   れた前記要求記述を満たすために実行主体がとるべき行
   動を表すプランを、アクションの集合として生成する生
   成処理と、 生成された前記プランに基づいてノード上で実行主体の
   動作を実現する実行処理と、 前記生成された前記プランを構成する前記アクションの
   うちの第１のアクションに基づいて、前記実行主体をノ
   ード間で移動させる管理処理と、 を含む情報処理方法を実現するコンピュータプログラム
   を記録したことを特徴とする記録媒体。
8. 【請求項８】 ソフトウェア上の実行主体であるエージ
   ェントがネットワークに接続されたノード上で動作する
   ことによって情報処理を行う情報処理装置において、 前記ノードに配置された構成要素へのアクセスに用いる
   ための構成要素の状態を表現する第１の情報と、前記実
   行主体の挙動を定義する第２の情報を記憶するための手
   段と、 前記第１及び第２の情報に基づいて、与えられた目的を
   達成するためにエージェントが実行すべきプランを作成
   する手段と、 作成されたプランの実行及びエージェントのノード間に
   おける移動を実現するための手段と、を有し、 移動先のノードにおいても、プランの実行及び必要なプ
   ランの作成を行うように構成されたことを特徴とする情
   報処理装置。
9. 【請求項９】 各ノードに配置された前記各情報が、エ
   ージェントの種類ごとに対応する複数のフィールドに区
   分され、 エージェントのプランは、当該エージェントに対応する
   フィールドの情報に基づいて作成され、 ノード間における移動では、エージェントが移動先のノ
   ードにおける対応する前記フィールドに移動するように
   構成されたことを特徴とする請求項８記載の情報処理装
   置。
10. 【請求項１０】 エージェントが、当該エージェントに
    固有の状態又はアクションに関する情報を持ち、ノード
    間の移動の際もこれら情報を運搬し、運搬しているこれ
    ら情報を移動した先のノードにおける前記第１の情報及
    び前記第２の情報と合わせてプランニングに用いるよう
    に構成されたことを特徴とする請求項８又は９記載の情
    報処理装置。
11. 【請求項１１】 前記プランを作成する手段は、プラン
    の一部としてエージェントをノード間で移動させる移動
    命令又はその他の命令を作成する際に、当該命令の前提
    となる事前条件を当該移動命令又は当該その他の命令に
    添付するように構成されたことを特徴とする請求項８，
    ９又は１０記載の情報処理装置。
12. 【請求項１２】 前記エージェントが、最終的な目的で
    あるゴールを達成するための中間的なサブゴールを作成
    し、このサブゴールを達成するための子エージェントを
    生成するように構成されたことを特徴とする請求項８，
    ９，１０又は１１記載の情報処理装置。
13. 【請求項１３】 ソフトウェア上の実行主体であるエー
    ジェントがネットワークに接続されたノード上で動作す
    ることによって情報処理を行う情報処理方法において、 前記ノードに配置された構成要素へのアクセスに用いる
    ための構成要素の状態を表現する第１の情報と、前記実
    行主体の挙動を定義する第２の情報を記憶するステップ
    と、 前記第１及び第２の情報に基づいて、与えられた目的を
    達成するためにエージェントが実行すべきプランを作成
    するステップと、 作成されたプランの実行及びエージェントのノード間に
    おける移動を実現するためのステップと、を有し、 移動先のノードにおいても、プランの実行及び必要なプ
    ランの作成を行うことを特徴とする情報処理方法。
14. 【請求項１４】 ソフトウェア上の実行主体であるエー
    ジェントがネットワークに接続されたノード上で動作す
    ることによって情報処理を行う情報処理方法を実現する
    コンピュータプログラムを記録した記録媒体において、 当該情報処理方法は、 前記ノードに配置された構成要素へのアクセスに用いる
    ための構成要素の状態を表現する第１の情報と、前記実
    行主体の挙動を定義する第２の情報を記憶するステップ
    と、 前記第１及び第２の情報に基づいて、与えられた目的を
    達成するためにエージェントが実行すべきプランを作成
    するステップと、 作成されたプランの実行及びエージェントのノード間に
    おける移動を実現するためのステップと、を有し、 移動先のノードにおいても、プランの実行及び必要なプ
    ランの作成を行うことを特徴とする記録媒体。
15. 【請求項１５】 請求項１３記載の情報処理方法を実現
    するコンピュータプログラムを記録した記録媒体におい
    て、 当該情報処理方法は、 各ノードに配置された前記各情報が、エージェントの種
    類ごとに対応する複数のフィールドに区分され、 エージェントのプランは、当該エージェントに対応する
    フィールドの情報に基づいて作成され、 ノード間における移動では、エージェントが移動先のノ
    ードにおける対応する前記フィールドに移動することを
    特徴とする記録媒体。