(57)【要約】【課題】タスク間の連携を汎用的かつ明示的に記述可能とし、タスクの記述を省略した場合にも容易にタスクを補完可能とする。【解決手段】情報処理装置１０は、複数のストーリー１７１に基づいて、補完位置と補完候補とを対応付けたテーブルを作成し、作成されたテーブルに基づいて、処理対象のストーリー１７１において記述が省略されている補完位置に、当該補完位置に対応付けられた補完候補を補完する。具体的には、複数のストーリー１７１からタスク間のデータの参照関係を抽出し、複数のストーリー１７１に含まれる参照元の記述データと参照先の記述データとをそれぞれ階層的に表して対応付けた履歴テーブルＴ１を作成する。また、複数のストーリー１７１から上位階層のタスクと当該上位階層の下位階層のタスクとを対応付けたレコメンドテーブルＴ２を作成する。【選択図】図１
2015176395.tif 000002
【特許請求の範囲】
【請求項１】
階層的な構造を記述可能な記述言語でタスクの実行順序を記述した複数の記述文書を記憶する記憶手段と、
前記複数の記述文書に基づいて、補完位置と補完候補とを対応付けたテーブルを作成する作成手段と、
前記作成されたテーブルに基づいて、処理対象の記述文書において記述が省略されている補完位置に、当該補完位置に対応付けられた補完候補を補完する補完手段と、
を備える情報処理装置。
【請求項２】
前記作成手段は、前記複数の記述文書からタスク間のデータの参照関係を抽出し、前記複数の記述文書に含まれる参照元の記述データと参照先の記述データとをそれぞれ階層的に表して対応付けた履歴テーブルを作成し、
前記補完手段は、前記作成された履歴テーブルに基づいて、前記処理対象の記述文書に含まれる前記参照元の記述データに、前記参照先の記述データを補完する請求項１に記載の情報処理装置。
【請求項３】
前記作成手段は、前記複数の記述文書から上位階層のタスクと当該上位階層の下位階層のタスクとを対応付けたレコメンドテーブルを作成し、
前記補完手段は、前記作成されたレコメンドテーブルに基づいて、前記処理対象の記述文書に含まれる前記上位階層のタスクの下位階層に、前記下位階層のタスクを補完する請求項１に記載の情報処理装置。
【請求項４】
前記作成手段は、前記複数の記述文書において対応するタスクの下位階層に含まれる複数のタスクを前記対応するタスクのベクトルとして扱い、前記複数のタスク間のコサイン類似度を算出し、前記算出されたコサイン類似度が所定の値以上のタスクを前記下位階層のタスクとし、前記対応するタスクを前記上位階層のタスクとして、前記レコメンドテーブルを作成する請求項３に記載の情報処理装置。
【請求項５】
前記記述言語は、ＸＭＬ言語である請求項１〜４のいずれか一項に記載の情報処理装置。
【請求項６】
コンピュータを、
階層的な構造を記述可能な記述言語でタスクの実行順序を記述した複数の記述文書に基づいて、補完位置と補完候補とを対応付けたテーブルを作成する作成手段、
前記作成されたテーブルに基づいて、処理対象の記述文書において記述が省略されている補完位置に、当該補完位置に対応付けられた補完候補を補完する補完手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
従来、ソフトウェア設計においては、メッセージとキューを用いた異なる二つのオブジェクトの連携が行われており、例えば、組み込みシステムのカーネル部におけるプロセス間の通信等に用いられている。
【０００３】
また、メッセージとキューを用いてアプリケーションソフトウェア（以下、「アプリケーション」という。）を連携させるＭＱ（メッセージ・キューイング）という技術が広がっている。ＭＱは、金融取引やセルラー用アプリケーション等の多重トランザクションの処理や、既存のシステムの活用等に応用されている。
【０００４】
複数のアプリケーション間でデータを交換して連携動作を行う技術として、例えば、あるアプリケーションが送信したメッセージをキューイングマネージャが管理し、別のアプリケーションがキューを受信することで、アプリケーション同士が連携するように動作するシステムが提案されている（特許文献１参照）。
【０００５】
また、医療機関専用のシステムにおいて、ＭＱをベースとして医療データの連携交換を行うものが提案されている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−０２２２５１号公報
【特許文献２】特表２００８−５２７５１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来のアプリケーション連携システムは、メッセージとキューを用いてアプリケーション等のタスクや機器を連携させるものであるため、システムベンダー等が特定のユースケースに特化して固定的に構築しなければならないという問題があった。
【０００８】
また、特定のユースケースに特化したシステムは、システムベンダーがブラックボックス化してユーザに提供するため、ユーザがその後の拡張や修正を行うことができないだけでなく、システムベンダーの倒産等により、保守や拡張の可能性が消滅してしまうリスクがあった。
【０００９】
このように、ＭＱによるアプリケーション連携では、高い処理性能の実現やソフトウェア設計のし易さという利点はあるが、システムを実際に操作するユーザによっては、今までのメインフレーム、サーバ、仮想環境等のシステムと同様、ユースケースの変更等が困難であるという問題があった。
そのため、ユーザ自身が簡単にタスクの連携を含む処理手順を修正可能とすることが望まれていた。
【００１０】
本発明は、上記の従来技術における問題に鑑みてなされたものであって、タスク間の連携を汎用的かつ明示的に記述可能とし、タスクの記述を省略した場合にも容易にタスクを補完可能とすることを課題とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明の情報処理装置は、
階層的な構造を記述可能な記述言語でタスクの実行順序を記述した複数の記述文書を記憶する記憶手段と、
前記複数の記述文書に基づいて、補完位置と補完候補とを対応付けたテーブルを作成する作成手段と、
前記作成されたテーブルに基づいて、処理対象の記述文書において記述が省略されている補完位置に、当該補完位置に対応付けられた補完候補を補完する補完手段と、
を備える。
【発明の効果】
【００１２】
本発明によれば、タスク間の連携を汎用的かつ明示的に記述することができ、タスクの記述を省略した場合にも容易にタスクを補完することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態における情報処理装置の機能的構成を示すブロック図である。
【図２】処理パターン毎のタスクのタイプを示す図である。
【図３】（ａ）は、タスクの階層構造を示すイメージ図である。（ｂ）は、ＸＭＬによるタスクの記述例である。
【図４】（ａ）は、タスクの入出力データの対応関係を示すイメージ図である。（ｂ）は、データ交換の情報を記述したストーリーの例である。
【図５】「社員照会」というタスクにおける入力データが固定の場合のデータ交換の情報を記述したストーリーの例である。
【図６】一部を省略してデータ交換の情報を記述したストーリーの例である。
【図７】履歴テーブルの例である。
【図８】レコメンドテーブルの例である。
【図９】履歴テーブル作成処理を示すフローチャートである。
【図１０】トラバース処理を示すフローチャートである。
【図１１】ノード処理を示すフローチャートである。
【図１２】（ａ）は、「社員照会Ａ」というストーリーの理想的な構成例である。（ｂ）は、「要求」、「出力」のみを含む「社員照会Ｂ」というストーリーの構成例である。（ｃ）は、「要求」、「社員検索」のみを含む「社員照会Ｃ」というストーリーの構成例である。
【図１３】（ａ）は、正規化前の多次元ベクトル表の例である。（ｂ）は、各タスクを２次元のストーリーのベクトルとして表したイメージ図である。
【図１４】（ａ）は、正規化後の多次元ベクトル表の例である。（ｂ）は、図１３（ｂ）に示すベクトルを正規化したものである。
【図１５】レコメンドテーブル作成処理を示すフローチャートである。
【図１６】多次元ベクトル表の作成処理を示すフローチャートである。
【図１７】コサイン類似度算出及びレコメンドテーブルへの書き込み処理を示すフローチャートである。
【図１８】ストーリー補完処理を示すフローチャートである。
【図１９】レコメンドテーブルによる補完処理を示すフローチャートである。
【図２０】レコメンド補完部品処理を示すフローチャートである。
【図２１】レコメンド用トラバース処理を示すフローチャートである。
【図２２】履歴テーブルによる補完処理を示すフローチャートである。
【図２３】履歴補完部品処理を示すフローチャートである。
【図２４】履歴用トラバース処理を示すフローチャートである。
【図２５】ストーリーの補完例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明に係る情報処理装置の実施の形態について、図面を参照して説明する。なお、本発明は、図示例に限定されるものではない。
【００１５】
図１は、本実施の形態における情報処理装置１０の機能的構成を示すブロック図である。情報処理装置１０は、例えば、パーソナルコンピュータ等により構成される。
図１に示すように、情報処理装置１０は、作成手段、補完手段としてのＣＰＵ（Central Processing Unit）１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、操作部１４と、表示部１５と、通信部１６と、記憶部１７と、を備える。
【００１６】
ＣＰＵ１１は、情報処理装置１０の各部の処理動作を統括的に制御する。具体的には、ＣＰＵ１１は、ＲＯＭ１２に記憶されている各種プログラムを読み出してＲＡＭ１３に展開し、当該プログラムとの協働により各種処理を行う。
【００１７】
ＲＯＭ１２は、各種プログラム及び各種データを記憶する読み出し専用の半導体メモリである。例えば、ＲＯＭ１２には、履歴テーブル作成プログラム１２１、レコメンドテーブル作成プログラム１２２、ストーリー補完プログラム１２３が記憶されている。
【００１８】
ＲＡＭ１３は、揮発性のメモリである。ＲＡＭ１３には、実行される各種プログラムやこれら各種プログラムに係るデータ等が格納される。
【００１９】
操作部１４は、ユーザによる操作指示を受け付ける機能部である。操作部１４は、カーソルキー、文字入力キー及び各種機能キー等を備えたキーボードと、マウス等のポインティングデバイスを備えて構成され、キーボードに対するキー操作やマウス操作により入力された操作信号をＣＰＵ１１に出力する。
【００２０】
表示部１５は、ＬＣＤ（Liquid Crystal Display）等により構成され、ＣＰＵ１１からの表示制御信号に従って画面表示を行う。
【００２１】
通信部１６は、ネットワークインターフェース等により構成され、通信ネットワークを介して接続された外部機器との間でデータの送受信を行う。
【００２２】
記憶部１７は、ハードディスクや不揮発性メモリ等により構成され、情報を読み出し及び書き込み可能に記憶する。記憶部１７には、複数の記述文書としてのストーリー１７１、複数のアプリケーションプログラム（以下、「アプリケーション」という。）ＡＰが記憶されている。
【００２３】
ストーリー１７１は、階層的な構造を記述可能な記述言語でタスクの実行順序を記述したものである。具体的には、階層的な構造を記述可能な記述言語としてＸＭＬ（Extensible Markup Language）言語を用い、ストーリー１７１を構成する要素をタスクとして、ストーリー１７１をタスクの階層で記述する。タスクとしてアプリケーションＡＰが指定された場合には、ストーリー１７１を実行する際に、指定されたアプリケーションＡＰが呼び出され、アプリケーションＡＰに対応する処理が実行される。ストーリー１７１では、例えば、連携する複数のアプリケーションＡＰを利用するフロー（処理手順）が記述される。
【００２４】
タスクは、連携するアプリケーションＡＰをＭＱの処理パターンに基づいて分類したタイプを属性に持つ。タスクは、データを連携する際のデータの送信側と受信側について、それぞれ規定される。
【００２５】
図２に、処理パターン毎に、処理パターンが用いられる実際の業務の例、処理パターンに含まれるタスクのタイプ、タスクの定義を示す。例えば、「オンライン処理：一方向型」には、作成したデータを送信する「送信」タイプのタスクと、データを受信し処理する「受信」タイプのタスクと、が含まれる。
【００２６】
データの送信側と受信側におけるタスクの組を正確に表すため、送信側のタスクをＸＭＬノードで表し、そのノードに受信側のタスクをネストすることで、タスクを階層的に表す。また、タスクをネストせずに並列に配置することは、順次処理することを表す。
【００２７】
図３（ａ）は、タスクの階層構造を示すイメージ図である。主タスクＡ１には従タスクＢ１がネストされ、主タスクＡ２には従タスクＢ２がネストされている。主タスクＡ２は、主タスクＡ１の後に行われる処理を示している。
【００２８】
図３（ｂ）に、ＸＭＬによるタスクの記述例を示す。「要求」タイプの「社員照会」という主タスクＡ３に、「応答」タイプの「社員検索」という従タスクＢ３がネストされている。そして、主タスクＡ３の後に、「送信」タイプの「社員通知」という主タスクＡ４が並列に記述され、この「社員通知」という主タスクＡ４に、「受信」タイプの「通知送付」という従タスクＢ４がネストされている。
【００２９】
「社員照会」は、指定された社員を照会するための「要求」型アプリケーションである。
「社員検索」は、予め社員情報が記憶されているデータベース等により、社員に関する情報を検索するための「応答」型アプリケーションである。
「社員通知」は、指定された社員を通知するための「送信」型アプリケーションである。
「通知送付」は、指定された社員に対して所定の通知を送付するための「受信」型アプリケーションである。
【００３０】
タスクは、それぞれの階層下に入力データと出力データを記述することができる。ネストされるタスクにおいては、上位階層のタスクの出力データが、下位階層のタスクの入力データとなる。それぞれのタスクのデータは、任意の構造であるので、タスク間で同じデータを用いる場合には、その対応関係を記述する必要がある。
【００３１】
図４（ａ）に、タスクの入出力データの対応関係を示す。「要求」タイプの上位階層のタスクＡ５の要求データが、「応答」タイプの下位階層のタスクＢ５の入力データとなる。また、「応答」タイプの下位階層のタスクＢ５の出力データが、「要求」タイプの上位階層のタスクＡ５の出力データとなる。
データの対応関係をストーリー１７１内で厳密に記述することで、タスクの実行時に、対応関係に基づいてデータを参照することができる。
【００３２】
図４（ｂ）は、データ交換の情報を記述したストーリー（ＸＭＬ文書）の例である。
「社員照会」は、社員番号等により特定される社員を照会するためのタスク（アプリケーションＡＰ）である。社員番号は、予め社員番号が格納されたファイルからデータが入力されるか、あるいは、データ（社員番号）の入力が要求され、ユーザによって手入力される。
「社員検索」は、入力された社員番号等に対して、指定された出力内容（社員番号、社員名等）に応じて、社員番号等に対応する社員の情報を出力するためのタスク（アプリケーションＡＰ）である。
【００３３】
ノードＣ１には、「社員検索」というタスクの入力データとして、「社員番号」が用いられることが記述されている。そして、その「社員番号」は、ｒｅｆ属性により、ノードＤ１の「社員番号」を参照するよう指定されている。データ交換に用いられるそれぞれの情報を階層的に表すと、参照元（ｒｅｆ属性を含むノード）は「／社員照会／社員検索／入力／社員番号」であり、参照先（ｒｅｆ値により指定された参照先）は「／社員照会／要求／社員番号」である。
【００３４】
同様に、ノードＣ２の「／社員照会／出力／社員番号」の値として、ノードＤ２の「／社員照会／社員検索／出力／社員番号」の値が用いられる。また、ノードＣ３の「／社員照会／出力／社員名」の値として、ノードＤ３の「／社員照会／社員検索／出力／社員名」の値が用いられる。
【００３５】
図５は、「社員照会」というタスクにおける入力データが固定の場合のデータ交換の情報を記述したストーリー（ＸＭＬ文書）の例である。ノードＤ４には、「社員照会」というタスクの入力データとして、「ｃ：／ｔｅｍｐ／社員番号ファイル．ｔｘｔ」という名称のファイルが用いられることが記述されている。ノードＣ４には、「社員検索」というタスクの入力データとして、「社員番号」が用いられることが記述されている。そして、その「社員番号」は、ｒｅｆ属性により、ノードＤ４の「ファイル」を参照するよう指定されている。すなわち、「／社員照会／社員検索／入力／社員番号」の値として、「／社員照会／入力／ファイル」の値が参照されることになる。
【００３６】
図６は、一部を省略してデータ交換の情報を記述したストーリー（ＸＭＬ文書）の例である。ノードＣ５では、「社員照会」というタスクの下位階層のタスクである「社員検索」というタスクにおいて、入力データとして使用される「社員番号」の記述が省略されている。本発明は、図６に示すノードＣ５のように一部が省略された記述から、図４（ｂ）のノードＣ１、又は、図５のノードＣ４のような記述に補完することを目的としている。
【００３７】
また、記憶部１７には、履歴テーブルＴ１、レコメンドテーブルＴ２が記憶される。
図７は、履歴テーブルＴ１の例である。履歴テーブルＴ１は、索引パス（補完位置）に対して、参照先（補完候補）と、参照回数と、が対応付けられている。索引パスは、ストーリー１７１内で、ｒｅｆ属性により参照先が指定されているノードを示す情報である。参照先は、ｒｅｆ値により指定された参照先を示す情報である。参照回数は、該当する索引パスに対して参照先が参照された回数である。
【００３８】
図８は、レコメンドテーブルＴ２の例である。レコメンドテーブルＴ２は、索引パス（補完位置）に対して、補完候補が対応付けられている。索引パスは、ストーリー１７１内で、下位階層のタスクの記述が省略された上位階層のタスクを示す情報である。補完候補は、索引パスで示された上位階層のタスクと、その直下の下位階層のタスクと、の階層関係を示す情報である。
【００３９】
ＣＰＵ１１は、複数のストーリー１７１に基づいて、補完位置と補完候補とを対応付けた履歴テーブルＴ１、レコメンドテーブルＴ２を作成する。
【００４０】
具体的に、ＣＰＵ１１は、複数のストーリー１７１からタスク間のデータの参照関係を抽出し、複数のストーリー１７１に含まれる参照元の記述データと参照先の記述データとをそれぞれ階層的に表して対応付けた履歴テーブルＴ１を作成する。
【００４１】
また、ＣＰＵ１１は、複数のストーリー１７１から上位階層のタスクと当該上位階層の下位階層のタスクとを対応付けたレコメンドテーブルＴ２を作成する。より詳細には、ＣＰＵ１１は、複数のストーリー１７１において対応するタスクの下位階層に含まれる複数のタスクを、対応するタスクのベクトルとして扱い、複数のタスク間のコサイン類似度を算出する。「対応するタスク」とは、相互に類似する処理内容を含むタスク（ストーリー１７１自体を含む。）である。例えば、同一のアプリケーションＡＰを用いたタスク同士で、あるタスクに含まれる下位階層のタスクが他のタスクには含まれていない場合に、「対応するタスク」に該当する。ＣＰＵ１１は、算出されたコサイン類似度が所定の値以上のタスクを下位階層のタスクとし、対応するタスクを上位階層のタスクとして、レコメンドテーブルＴ２を作成する。
【００４２】
ＣＰＵ１１は、作成された履歴テーブルＴ１、レコメンドテーブルＴ２に基づいて、処理対象のストーリー１７１において記述が省略されている補完位置に、当該補完位置に対応付けられた補完候補を補完する。
【００４３】
具体的に、ＣＰＵ１１は、履歴テーブルＴ１に基づいて、処理対象のストーリー１７１に含まれる参照元の記述データに、参照先の記述データを補完する。
【００４４】
また、ＣＰＵ１１は、レコメンドテーブルＴ２に基づいて、処理対象のストーリー１７１に含まれる上位階層のタスクの下位階層に、下位階層のタスクを補完する。
【００４５】
（履歴テーブル作成処理）
図９は、履歴テーブル作成処理を示すフローチャートである。この処理は、これまでに蓄積された各ストーリー１７１からタスク間のデータの参照関係のパターンを抽出する処理であり、ストーリー１７１単位で実行される。この処理は、ＣＰＵ１１と履歴テーブル作成プログラム１２１との協働によるソフトウェア処理によって実現される。
【００４６】
まず、ＣＰＵ１１は、ストーリー１７１からルートノードを取得する（ステップＳ１）。
次に、ＣＰＵ１１は、ステップＳ１で取得したノードのパスを取得する（ステップＳ２）。ノードのパスは、処理対象ノードを階層的に表したものである。ＣＰＵ１１は、取得したノードのパスをＲＡＭ１３に格納する。
次に、ＣＰＵ１１は、ステップＳ１で取得したルートノードに対して、トラバース処理を行う（ステップＳ３）。
【００４７】
ここで、図１０を参照して、トラバース処理について説明する。
ＣＰＵ１１は、処理対象ノードの下位階層のノードである子ノードの数を数える（ステップＳ１１）。
次に、ＣＰＵ１１は、未処理の子ノードがあるか否かを判断し（ステップＳ１２）、未処理の子ノードがある場合には（ステップＳ１２；ＹＥＳ）、未処理の子ノードのうちいずれか一つのノードを取得する（ステップＳ１３）。
次に、ＣＰＵ１１は、テップＳ１３で取得したノードに対して、ノード処理を行う（ステップＳ１４）。
【００４８】
ノード処理では、図１１に示すように、ＣＰＵ１１は、処理対象ノードのパスを取得する（ステップＳ２１）。ＣＰＵ１１は、取得したノードのパスをＲＡＭ１３に格納する。
次に、ＣＰＵ１１は、処理対象ノードにｒｅｆ属性があるか否かを判断する（ステップＳ２２）。処理対象ノードにｒｅｆ属性がある場合には（ステップＳ２２；ＹＥＳ）、ＣＰＵ１１は、処理対象ノードからｒｅｆ値を取得する（ステップＳ２３）。ＣＰＵ１１は、取得したｒｅｆ値をＲＡＭ１３に格納する。
【００４９】
次に、ＣＰＵ１１は、ノードのパス及びｒｅｆ値に基づいて、履歴テーブルＴ１への書き込みを行う（ステップＳ２４）。具体的には、履歴テーブルＴ１の索引パスには、ステップＳ２１で取得したノードのパスを書き込み、参照先には、ステップＳ２３で取得したｒｅｆ値を書き込み、参照回数には１を書き込む。なお、ノードのパスとｒｅｆ値の組み合わせが既に履歴テーブルＴ１に存在する場合には、新たにノードのパスとｒｅｆ値の書き込みはせず、履歴テーブルＴ１内のノードのパスとｒｅｆ値の組み合わせに対応するレコードの参照回数に１を加える。
【００５０】
図７の履歴テーブルＴ１に示すように、例えば、図４（ｂ）に示すストーリーからは、索引パス「／社員照会／社員検索／入力／社員番号（ノードＣ１）」に対して、参照先「／社員照会／要求／社員番号（ノードＤ１）」が書き込まれる。また、索引パス「／社員照会／出力／社員番号（ノードＣ２）」に対して、参照先「／社員照会／社員検索／出力／社員番号（ノードＤ２）」が書き込まれる。また、索引パス「／社員照会／出力／社員名（ノードＣ３）」に対して、参照先「／社員照会／社員検索／出力／社員名（ノードＤ３）」が書き込まれる。
【００５１】
同様に、図５に示すストーリーからは、索引パス「／社員照会／社員検索／入力／社員番号（ノードＣ４）」に対して、参照先「／社員照会／入力／ファイル（ノードＤ４）」が書き込まれる。索引パス「／社員照会／出力／社員番号」に対する参照先、索引パス「／社員照会／出力／社員名」に対する参照先については、図４（ｂ）に示すストーリーと同様であるから、参照回数に１が加えられ、それぞれ２回となっている。
【００５２】
ステップＳ２４の後、又は、ステップＳ２２において、処理対象ノードにｒｅｆ属性がない場合には（ステップＳ２２；ＮＯ）、ノード処理が終了する。
【００５３】
次に、図１０に戻り、ＣＰＵ１１は、ステップＳ１３で取得したノードに対して、トラバース処理（図１０参照）を行う（ステップＳ１５）。このように、順次下位階層のノードについて、処理が繰り返される。
ステップＳ１５の後、ステップＳ１２に戻り、他の子ノードについて、処理が繰り返される。
ステップＳ１２において、未処理の子ノードがない場合には（ステップＳ１２；ＮＯ）、トラバース処理が終了する。
【００５４】
図９のステップＳ３において、ルートノードに対するトラバース処理が終了すると、履歴テーブル作成処理が終了する。
【００５５】
（レコメンドテーブル作成処理）
次に、レコメンドテーブルＴ２の作成について説明する。
図１２（ａ）に、「社員照会Ａ」というストーリーの構成を示す。「社員照会Ａ」は、「要求」、「社員検索」、「出力」というタスクから構成され、「社員照会」というストーリーの理想的な構成となっている。ただし、情報処理装置１０の記憶部１７には、「社員照会Ａ」は存在しないこととする。
【００５６】
図１２（ｂ）に、「社員照会Ｂ」というストーリーの構成を示す。「社員照会Ｂ」は、「要求」、「出力」というタスクから構成され、「社員検索」というタスクを含まない。
図１２（ｃ）に、「社員照会Ｃ」というストーリーの構成を示す。「社員照会Ｃ」は、「要求」、「社員検索」というタスクから構成され、「出力」というタスクを含まない。
例えば、「社員照会Ｂ」と「社員照会Ｃ」を対応するタスクとして、レコメンドテーブルＴ２を作成する。
【００５７】
図１３（ａ）に、正規化前の多次元ベクトル表Ｌ１の例を示す。多次元ベクトル表Ｌ１は、列にストーリーをとり、行にタスクをとって、各タスクをＮ次元のストーリー（Ｎはストーリーの数）のベクトルとして表したものである。多次元ベクトル表Ｌ１には、各ストーリーに各タスクが含まれるか否かが示されており、多次元ベクトル表Ｌ１の各ストーリーに対して、該当するタスクが含まれている場合には「１」とし、該当するタスクが含まれていない場合には「０」とする。なお、本実施の形態では、「社員照会Ｂ」、「社員照会Ｃ」という二つのストーリーを軸とした２次元のベクトルを用いた場合を例示しているが、より多くのストーリーを用いる場合には、多次元ベクトル表Ｌ１の列もストーリーの数Ｎに応じてＮ列となり、各タスクはＮ次元のベクトルとして表されることになる。
【００５８】
図１３（ｂ）は、「社員照会Ｂ」、「社員照会Ｃ」を軸にとって、図１３（ａ）に示した各タスクを２次元のストーリーのベクトルとして表したイメージ図である。図１３（ｂ）の例では、「要求」というタスクは、（社員照会Ｂ，社員照会Ｃ）＝（１，１）というベクトルで表され、「社員検索」というタスクは、（社員照会Ｂ，社員照会Ｃ）＝（０，１）というベクトルで表され、「出力」というタスクは、（社員照会Ｂ，社員照会Ｃ）＝（１，０）というベクトルで表される。
【００５９】
図１４（ａ）は、図１３（ａ）に示す多次元ベクトル表Ｌ１に対し、各ベクトルの長さが１となるように正規化した正規化後の多次元ベクトル表Ｌ２の例である。
図１４（ｂ）は、図１３（ｂ）に示すベクトルを正規化したものである。
【００６０】
図１５は、レコメンドテーブル作成処理を示すフローチャートである。この処理は、これまでに蓄積されたストーリー１７１から階層関係のパターンを抽出する処理である。この処理は、ＣＰＵ１１とレコメンドテーブル作成プログラム１２２との協働によるソフトウェア処理によって実現される。
【００６１】
まず、ＣＰＵ１１は、多次元ベクトル表の作成処理を行う（ステップＳ３１）。
【００６２】
ここで、図１６を参照して、多次元ベクトル表の作成処理について説明する。
ＣＰＵ１１は、記憶部１７に記憶されているストーリー１７１のうち、未処理のストーリー１７１があるか否かを判断する（ステップＳ４１）。未処理のストーリー１７１がある場合には（ステップＳ４１；ＹＥＳ）、ＣＰＵ１１は、この未処理のストーリー１７１を多次元ベクトル表Ｌ１（図１３（ａ）参照）の列に追加する（ステップＳ４２）。
【００６３】
次に、ＣＰＵ１１は、処理中のストーリー１７１内に未処理のタスクがあるか否かを判断する（ステップＳ４３）。未処理のタスクがある場合には（ステップＳ４３；ＹＥＳ）、ＣＰＵ１１は、この未処理のタスクを処理対象タスクとして、多次元ベクトル表Ｌ１の行に処理対象タスクと同じタスクの項目があるか否かを判断する（ステップＳ４４）。
【００６４】
多次元ベクトル表Ｌ１の行に処理対象タスクと同じタスクの項目がない場合には（ステップＳ４４；ＮＯ）、ＣＰＵ１１は、多次元ベクトル表Ｌ１の行に項目（処理対象タスク）を追加する（ステップＳ４５）。
【００６５】
ステップＳ４５の後、又は、ステップＳ４４において、多次元ベクトル表Ｌ１の行に処理対象タスクと同じタスクの項目がある場合には（ステップＳ４４；ＹＥＳ）、ＣＰＵ１１は、多次元ベクトル表Ｌ１の列（ストーリー）と行（タスク）の交わる位置の値を１にする（ステップＳ４６）。そして、ステップＳ４３に戻り、処理中のストーリー１７１内の他のタスクについて、処理が繰り返される。
【００６６】
ステップＳ４３において、未処理のタスクがない場合には（ステップＳ４３；ＮＯ）、ステップＳ４１に戻り、他のストーリー１７１について、処理が繰り返される。
【００６７】
ステップＳ４１において、未処理のストーリー１７１がない場合には（ステップＳ４１；ＮＯ）、ＣＰＵ１１は、多次元ベクトル表Ｌ１の各タスクを各ストーリーのベクトルとして扱い、各タスクのベクトルを正規化して多次元ベクトル表Ｌ２（図１４（ａ）参照）を生成する（ステップＳ４７）。
以上で、多次元ベクトル表の作成処理が終了する。
【００６８】
次に、図１５に戻り、ＣＰＵ１１は、コサイン類似度算出及びレコメンドテーブルへの書き込み処理を行う（ステップＳ３２）。
【００６９】
ここで、図１７を参照して、コサイン類似度算出及びレコメンドテーブルへの書き込み処理について説明する。
ＣＰＵ１１は、未処理のストーリー１７１があるか否かを判断する（ステップＳ５１）。未処理のストーリー１７１がある場合には（ステップＳ５１；ＹＥＳ）、ＣＰＵ１１は、この未処理のストーリー１７１内に未処理のタスクがあるか否かを判断する（ステップＳ５２）。
【００７０】
ストーリー１７１内に未処理のタスクがある場合には（ステップＳ５２；ＹＥＳ）、ＣＰＵ１１は、この未処理のタスクを処理対象タスクとして、多次元ベクトル表Ｌ２の処理中のストーリー１７１の列に比較先タスクがあるか否かを判断する（ステップＳ５３）。比較先タスクとは、処理中のストーリー１７１内に含まれないタスク、すなわち、多次元ベクトル表Ｌ２の処理中のストーリー１７１の列において、値が「０」のタスクである。
【００７１】
多次元ベクトル表Ｌ２に比較先タスクがある場合には（ステップＳ５３；ＹＥＳ）、ＣＰＵ１１は、処理対象タスクと比較先タスクのコサイン類似度を算出する（ステップＳ５４）。コサイン類似度は、タスクをＮ次元のストーリーのベクトルとして表現した場合に、両タスクの正規化されたベクトルの内積で求められる。コサイン類似度が１に近いほど、タスク同士が類似しているといえる。
【００７２】
次に、ＣＰＵ１１は、算出されたコサイン類似度が予め定められた閾値以上であるか否かを判断する（ステップＳ５５）。閾値は、任意の値に設定可能であるが、閾値として、例えば、０．７が用いられる。
【００７３】
コサイン類似度が閾値以上である場合には（ステップＳ５５；ＹＥＳ）、ＣＰＵ１１は、レコメンドテーブルＴ２への書き込みを行う（ステップＳ５６）。具体的には、レコメンドテーブルＴ２の索引パスには、処理中の「ストーリー」を書き込み、補完候補には、「ストーリー／比較先タスク」を書き込む。
【００７４】
例えば、図１４（ａ）に示す多次元ベクトル表Ｌ２において、「社員照会Ｂ」というストーリーを処理対象とした場合、「社員照会Ｂ」には「要求」タスクと「出力」タスクが含まれるから、「要求」と「出力」に対して、近いベクトルを持っているタスクを探す。
ｃｏｓ（要求，社員検索）＝０．７×０＋０．７×１＝０．７
ｃｏｓ（出力，社員検索）＝１×０＋０×１＝０
この結果、「社員検索」は、「要求」と類似度が高いと考えられる。
したがって、図８のレコメンドテーブルＴ２の１行目に示すように、索引パス「社員照会Ｂ」に対して、補完候補「社員照会Ｂ／社員検索」が書き込まれる。
【００７５】
同様に、「社員照会Ｃ」というストーリーを処理対象とした場合、「社員照会Ｃ」には「要求」タスクと「社員検索」タスクが含まれるから、「要求」と「社員検索」に対して、近いベクトルを持っているタスクを探す。
ｃｏｓ（要求，出力）＝０．７×１＋０．７×０＝０．７
ｃｏｓ（社員検索，出力）＝０×１＋１×０＝０
この結果、「出力」は、「要求」と類似度が高いと考えられる。
したがって、図８のレコメンドテーブルＴ２の４行目に示すように、索引パス「社員照会Ｃ」に対して、補完候補「社員照会Ｃ／出力」が書き込まれる。
【００７６】
ステップＳ５６の後、又は、ステップＳ５５において、コサイン類似度が閾値未満である場合には（ステップＳ５５；ＮＯ）、ステップＳ５３に戻り、他の比較先タスクについて、処理が繰り返される。
ステップＳ５３において、多次元ベクトル表Ｌ２に他の比較先タスクがない場合には（ステップＳ５３；ＮＯ）、ステップＳ５２に戻り、処理中のストーリー１７１内の他のタスクについて、処理が繰り返される。
【００７７】
ステップＳ５２において、処理中のストーリー１７１内に未処理のタスクがない場合には（ステップＳ５２；ＮＯ）、ステップＳ５１に戻り、他のストーリー１７１について、処理が繰り返される。
【００７８】
ステップＳ５１において、未処理のストーリー１７１がない場合には（ステップＳ５１；ＮＯ）、コサイン類似度算出及びレコメンドテーブルへの書き込み処理が終了する。
そして、図１５に戻り、レコメンドテーブル作成処理が終了する。
【００７９】
なお、図１６及び図１７においては、ストーリー１７１に対して直下のタスクとの階層関係を抽出する場合について説明したが、ストーリー１７１以外の上位階層のタスクと、その直下の下位階層のタスクとの階層関係も同様に求めることができる。例えば、図８のレコメンドテーブルＴ２の２行目及び３行目に示すように、索引パス「社員検索」に対して、補完候補「社員検索／入力」、「社員検索／出力」等を抽出する。
【００８０】
（ストーリー補完処理）
図１８は、ストーリー補完処理を示すフローチャートである。ストーリー補完処理は、一部の記述が省略されたストーリー１７１（以下、処理対象ストーリーという。）に対してタスクを補完する処理である。この処理は、ＣＰＵ１１とストーリー補完プログラム１２３との協働によるソフトウェア処理によって実現される。
【００８１】
まず、ＣＰＵ１１は、処理対象ストーリーに対して、レコメンドテーブルによる補完処理を行う（ステップＳ６１）。
次に、ＣＰＵ１１は、処理対象ストーリーに対して、履歴テーブルによる補完処理を行う（ステップＳ６２）。
以上で、ストーリー補完処理が終了する。
【００８２】
（レコメンドテーブルによる補完処理）
図１９は、レコメンドテーブルによる補完処理（ステップＳ６１）を示すフローチャートである。この処理は、処理対象ストーリーについて、レコメンドテーブルＴ２に基づいて、タスクの階層関係を補完する処理である。
【００８３】
まず、ＣＰＵ１１は、処理対象ストーリーからルートノードを取得する（ステップＳ７１）。
次に、ＣＰＵ１１は、ステップＳ７１で取得したノードに対して、レコメンド補完部品処理を行う（ステップＳ７２）。
【００８４】
ここで、図２０を参照して、レコメンド補完部品処理について説明する。
ＣＰＵ１１は、処理対象ノードをキーにして、レコメンドテーブルＴ２を検索し（ステップＳ８１）、レコメンドテーブルＴ２に補完候補があるか否かを判断する（ステップＳ８２）。具体的には、ＣＰＵ１１は、レコメンドテーブルＴ２において、処理対象ノードと一致する索引パスに対応する補完候補があるか否かを判断する。
【００８５】
レコメンドテーブルＴ２に補完候補がある場合には（ステップＳ８２；ＹＥＳ）、ＣＰＵ１１は、レコメンドテーブルＴ２から処理対象ノードに対応する補完候補を取得し、処理対象ノードの下位階層に子ノードを挿入する（ステップＳ８３）。すなわち、ＣＰＵ１１は、処理対象ノードと子ノードの階層関係を補完する。
なお、ＣＰＵ１１は、処理対象ノードの下位階層に、補完候補と同じ子ノードが既に存在する場合には、子ノードを挿入しない。
【００８６】
また、ＣＰＵ１１は、処理対象ノードに対応する補完候補が二以上ある場合には、二以上の補完候補を表示部１５に表示させ、ユーザの操作部１４からの操作によって、表示された補完候補の中から一又は複数の補完候補を選択させることとしてもよい。同一のノード下に複数の子ノードを挿入する場合の順序については、予め定められた順序（通常の処理順序）で挿入することとしてもよいし、ユーザに指定させることとしてもよい。
【００８７】
ステップＳ８３の後、又は、ステップＳ８２において、レコメンドテーブルＴ２に補完候補がない場合には（ステップＳ８２；ＮＯ）、レコメンド補完部品処理が終了する。
【００８８】
次に、図１９に戻り、ＣＰＵ１１は、ステップＳ７１で取得したルートノードに対して、レコメンド用トラバース処理を行う（ステップＳ７３）。
【００８９】
レコメンド用トラバース処理では、図２１に示すように、ＣＰＵ１１は、処理対象ノードに未処理の子ノードがあるか否かを判断する（ステップＳ９１）。未処理の子ノードがある場合には（ステップＳ９１；ＹＥＳ）、ＣＰＵ１１は、未処理の子ノードに対して、レコメンド補完部品処理（図２０参照）を行う（ステップＳ９２）。
【００９０】
次に、ＣＰＵ１１は、未処理の子ノードに対して、レコメンド用トラバース処理（図２１参照）を行う（ステップＳ９３）。このように、順次下位階層のノードについて、処理が繰り返される。
【００９１】
ステップＳ９３の後、ステップＳ９１に戻り、他の子ノードについて、処理が繰り返される。
ステップＳ９１において、未処理の子ノードがない場合には（ステップＳ９１；ＮＯ）、レコメンド用トラバース処理が終了する。
【００９２】
図１９のステップＳ７３において、ルートノードに対するレコメンド用トラバース処理が終了すると、レコメンドテーブルによる補完処理が終了する。
【００９３】
（履歴テーブルによる補完処理）
図２２は、履歴テーブルによる補完処理（ステップＳ６２）を示すフローチャートである。この処理は、処理対象ストーリーについて、履歴テーブルＴ１に基づいてタスク間のデータの参照関係を補完する処理である。
【００９４】
まず、ＣＰＵ１１は、処理対象ストーリーからルートノードを取得する（ステップＳ１０１）。
次に、ＣＰＵ１１は、ステップＳ１０１で取得したノードに対して、履歴補完部品処理を行う（ステップＳ１０２）。
【００９５】
ここで、図２３を参照して、履歴補完部品処理について説明する。
ＣＰＵ１１は、処理対象ノードのフルパスを取得する（ステップＳ１１１）。ＣＰＵ１１は、取得したノードのフルパスをＲＡＭ１３に格納する。
次に、ＣＰＵ１１は、ステップＳ１１１で取得したノードのフルパスをキーにして、履歴テーブルＴ１を検索し（ステップＳ１１２）、履歴テーブルＴ１に補完候補があるか否かを判断する（ステップＳ１１３）。具体的には、ＣＰＵ１１は、履歴テーブルＴ１において、処理対象ノードのフルパスと一致する索引パスに対応する参照先があるか否かを判断する。
【００９６】
履歴テーブルＴ１に補完候補がある場合には（ステップＳ１１３；ＹＥＳ）、ＣＰＵ１１は、履歴テーブルＴ１から処理対象ノードのフルパスに対応する参照先を取得し、処理対象ノードにｒｅｆ属性を挿入する（ステップＳ１１４）。すなわち、ＣＰＵ１１は、処理対象ノードと参照先のノードとのデータの参照関係を補完する。
なお、ＣＰＵ１１は、処理対象ノードに、補完候補（参照先）と同じｒｅｆ属性が既に存在する場合には、ｒｅｆ属性を挿入しない。
【００９７】
また、ＣＰＵ１１は、処理対象ノードのフルパスに対応する参照先が二以上ある場合には、二以上の参照先を表示部１５に表示させ、ユーザの操作部１４からの操作によって、表示された参照先の中から一の参照先を選択させることとしてもよい。
【００９８】
ステップＳ１１４の後、又は、ステップＳ１１３において、履歴テーブルＴ１に補完候補がない場合には（ステップＳ１１３；ＮＯ）、履歴補完部品処理が終了する。
【００９９】
次に、図２２に戻り、ＣＰＵ１１は、ステップＳ１０１で取得したルートノードに対して、履歴用トラバース処理を行う（ステップＳ１０３）。
【０１００】
履歴用トラバース処理では、図２４に示すように、ＣＰＵ１１は、処理対象ノードに未処理の子ノードがあるか否かを判断する（ステップＳ１２１）。未処理の子ノードがある場合には（ステップＳ１２１；ＹＥＳ）、ＣＰＵ１１は、未処理の子ノードに対して、履歴補完部品処理（図２３参照）を行う（ステップＳ１２２）。
【０１０１】
次に、ＣＰＵ１１は、未処理の子ノードに対して、履歴用トラバース処理（図２４参照）を行う（ステップＳ１２３）。このように、順次下位階層のノードについて、処理が繰り返される。
【０１０２】
ステップＳ１２３の後、ステップＳ１２１に戻り、他の子ノードについて、処理が繰り返される。
ステップＳ１２１において、未処理の子ノードがない場合には（ステップＳ１２１；ＮＯ）、履歴用トラバース処理が終了する。
【０１０３】
図２２のステップＳ１０３において、ルートノードに対する履歴用トラバース処理が終了すると、履歴テーブルによる補完処理が終了する。
【０１０４】
ストーリー補完処理の終了後、ＣＰＵ１１は、補完されたストーリーに基づいて、複数のタスクを含む処理を順次実行する。
【０１０５】
図２５に、ストーリーの補完例を示す。
補完前のストーリー２１では、「社員照会Ｂ」の下位階層のタスクである「社員検索」が省略されている。
ストーリー２２は、図２５中に示すレコメンドテーブルＴ２に基づいて、ストーリー２１に対してタスクを補完したものである。具体的には、レコメンドテーブルＴ２の索引パス「社員照会Ｂ」に対応する補完候補である「社員照会Ｂ／社員検索」に基づいて、「社員照会Ｂ」の下位階層に「社員検索」というタスクが補完されている。さらに、索引パス「社員検索」に対応する補完候補である「社員検索／入力」と「社員検索／出力」に基づいて、「社員検索」の下位階層に「入力」というタスクと「出力」というタスクが補完されている。
【０１０６】
ここで、ストーリー２２には、「社員検索」というタスクが組み込まれたが、「社員検索」の入力データとして、何を使えばよいのか不明である。
ストーリー２３は、図２５中に示す履歴テーブルＴ１に基づいて、ストーリー２２に対してタスクを補完したものである。具体的には、履歴テーブルＴ１の索引パス「／社員照会Ｂ／社員検索／入力」に対応する参照先である「．．／．．／要求」に基づいて、「／社員照会Ｂ／社員検索／入力」のノードに、ｒｅｆ属性として、「ｒｅｆ＝”．．／．．／要求”」が補完される。すなわち、ストーリー２３では、「社員照会Ｂ」の下位階層のタスクである「社員検索」の入力データとして、「社員照会Ｂ」の要求データを参照するように、タスク間のデータの参照関係が補完されている。
【０１０７】
なお、図２５では、履歴テーブルＴ１において、参照回数の記載を省略しているが、索引パスと参照先の組み合わせに対する参照回数に応じて、参照先を補完する優先順位を変更することとしてもよい。また、図２５では、履歴テーブルＴ１において、参照先が相対パスで記載されているが、パスの記載方法は、図７に示すように、絶対パスであってもよい。
【０１０８】
以上説明したように、本実施の形態における情報処理装置１０によれば、階層的な構造を記述可能な記述言語を用いることにより、タスク間の連携を汎用的かつ明示的に記述することができる。
また、ストーリー１７１において記述が省略されていた場合に、省略された部分を補完するので、タスクの記述を省略した場合にも容易にタスクを補完することができる。すなわち、厳密にストーリー１７１を作成する技術を有しない者であっても、簡単にストーリー１７１を作成することが可能となる。例えば、システムベンダーに属する等の専門家でなく、実際に情報処理装置１０を使用するユーザ等によって、ストーリー１７１の修正・追加が可能となる。
【０１０９】
具体的には、タスク間のデータの参照関係が省略されていた場合に、履歴テーブルＴ１に基づいて、処理対象ストーリーに含まれる参照元の記述データに、参照先の記述データを補完するので、過去の履歴に基づく補完が可能となる。
【０１１０】
また、タスクの階層関係が省略されていた場合に、レコメンドテーブルＴ２に基づいて、処理対象ストーリーに含まれる上位階層のタスクの下位階層に、下位階層のタスクを補完するので、他のストーリー１７１における階層関係の傾向に基づく補完が可能となる。
また、コサイン類似度を用いることで、容易にタスク間の類似性を判断することができる。
【０１１１】
また、ストーリー１７１の記述形式としてＸＭＬを採用することにより、複数のアプリケーションＡＰの連携を厳密に記述することが可能となり、また、特定のユースケースによらない汎用的な記述が可能となる。
【０１１２】
なお、上記実施の形態における記述は、本発明に係る情報処理装置の例であり、これに限定されるものではない。装置を構成する各部の細部構成及び細部動作に関しても本発明の趣旨を逸脱することのない範囲で適宜変更可能である。
【０１１３】
例えば、上記実施の形態では、ストーリー補完処理（図１８）において、レコメンドテーブルによる補完処理（ステップＳ６１）と、履歴テーブルによる補完処理（ステップＳ６２）と、を両方行う場合について説明したが、レコメンドテーブルによる補完処理、又は、履歴テーブルによる補完処理のいずれか一方のみを行うこととしてもよい。
【０１１４】
また、ストーリー補完処理は、ストーリー１７１の実行時に行ってもよいし、ストーリー１７１の実行前に予め行っておいてもよい。
また、上記実施の形態では、アプリケーションＡＰが情報処理装置１０の記憶部１７に記憶されている場合について説明したが、外部サーバに保存されているアプリケーションＡＰを通信部１６を介して呼び出して使用することとしてもよい。
【０１１５】
本発明の実施の形態を説明したが、本発明の範囲は、上述の実施の形態に限定するものではなく、特許請求の範囲に記載された発明の範囲とその均等の範囲を含む。
以下に、この出願の願書に最初に添付した特許請求の範囲に記載した発明を付記する。付記に記載した請求項の項番は、この出願の願書に最初に添付した特許請求の範囲の通りである。
〔付記〕
＜請求項１＞
階層的な構造を記述可能な記述言語でタスクの実行順序を記述した複数の記述文書を記憶する記憶手段と、
前記複数の記述文書に基づいて、補完位置と補完候補とを対応付けたテーブルを作成する作成手段と、
前記作成されたテーブルに基づいて、処理対象の記述文書において記述が省略されている補完位置に、当該補完位置に対応付けられた補完候補を補完する補完手段と、
を備える情報処理装置。
＜請求項２＞
前記作成手段は、前記複数の記述文書からタスク間のデータの参照関係を抽出し、前記複数の記述文書に含まれる参照元の記述データと参照先の記述データとをそれぞれ階層的に表して対応付けた履歴テーブルを作成し、
前記補完手段は、前記作成された履歴テーブルに基づいて、前記処理対象の記述文書に含まれる前記参照元の記述データに、前記参照先の記述データを補完する請求項１に記載の情報処理装置。
＜請求項３＞
前記作成手段は、前記複数の記述文書から上位階層のタスクと当該上位階層の下位階層のタスクとを対応付けたレコメンドテーブルを作成し、
前記補完手段は、前記作成されたレコメンドテーブルに基づいて、前記処理対象の記述文書に含まれる前記上位階層のタスクの下位階層に、前記下位階層のタスクを補完する請求項１に記載の情報処理装置。
＜請求項４＞
前記作成手段は、前記複数の記述文書において対応するタスクの下位階層に含まれる複数のタスクを前記対応するタスクのベクトルとして扱い、前記複数のタスク間のコサイン類似度を算出し、前記算出されたコサイン類似度が所定の値以上のタスクを前記下位階層のタスクとし、前記対応するタスクを前記上位階層のタスクとして、前記レコメンドテーブルを作成する請求項３に記載の情報処理装置。
＜請求項５＞
前記記述言語は、ＸＭＬ言語である請求項１〜４のいずれか一項に記載の情報処理装置。
＜請求項６＞
コンピュータを、
階層的な構造を記述可能な記述言語でタスクの実行順序を記述した複数の記述文書に基づいて、補完位置と補完候補とを対応付けたテーブルを作成する作成手段、
前記作成されたテーブルに基づいて、処理対象の記述文書において記述が省略されている補完位置に、当該補完位置に対応付けられた補完候補を補完する補完手段、
として機能させるためのプログラム。
【符号の説明】
【０１１６】
１０  情報処理装置
１１  ＣＰＵ
１２  ＲＯＭ
１７  記憶部
１２１  履歴テーブル作成プログラム
１２２  レコメンドテーブル作成プログラム
１２３  ストーリー補完プログラム
１７１  ストーリー
ＡＰ  アプリケーションプログラム
Ｔ１  履歴テーブル
Ｔ２  レコメンドテーブル
【図１】
2015176395.tif 000003
【図２】
2015176395.tif 000004
【図３】
2015176395.tif 000005
【図４】
2015176395.tif 000006
【図５】
2015176395.tif 000007
【図６】
2015176395.tif 000008
【図７】
2015176395.tif 000009
【図８】
2015176395.tif 000010
【図９】
2015176395.tif 000011
【図１０】
2015176395.tif 000012
【図１１】
2015176395.tif 000013
【図１２】
2015176395.tif 000014
【図１３】
2015176395.tif 000015
【図１４】
2015176395.tif 000016
【図１５】
2015176395.tif 000017
【図１６】
2015176395.tif 000018
【図１７】
2015176395.tif 000019
【図１８】
2015176395.tif 000020
【図１９】
2015176395.tif 000021
【図２０】
2015176395.tif 000022
【図２１】
2015176395.tif 000023
【図２２】
2015176395.tif 000024
【図２３】
2015176395.tif 000025
【図２４】
2015176395.tif 000026
【図２５】
2015176395.tif 000027