JP2021166006A - 情報処理プログラム、情報処理方法、および情報処理装置 - Google Patents

Abstract

【課題】複数のアプリを組み合わせて利用し易くすること。【解決手段】情報処理装置は、ツールＡと、ツールＡに対応するプロキシ５１１とを一体化したコンテナを起動可能にするコンテナイメージと、ツールＢと、ツールＢに対応するプロキシ５１２とを一体化したコンテナを起動可能にするコンテナイメージとを生成する。情報処理装置は、各種データと、ツールＡを利用するタスクと、ツールＢを利用するタスクとの依存関係を示すデータフローを作成する。情報処理装置は、データフローに従って、生成されたコンテナイメージに基づいて、ツールＡ、または、ツールＢを利用して、一連のタスクを実行する。【選択図】図５

Description

本発明は、情報処理プログラム、情報処理方法、および情報処理装置に関する。

従来、それぞれ異なる形式のインターフェースを有する複数のアプリケーションがある。インターフェースとしては、例えば、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）、および、ＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）などがある。ユーザは、複数のアプリケーションを組み合わせて、データ利活用タスクを実施することがある。以下の説明では、アプリケーションを単に「アプリ」と表記する場合がある。

先行技術としては、例えば、ツールごとにデータ交換部が設けられ、ツールの動作に応じてデータ交換部が、連携部を介して他のデータ交換部とデータ処理を行い、ツール間を連携させるものがある。また、例えば、アプリケーションの実行環境のイメージの情報に、コンテナの中でアプリケーションが用いるデータのデータ情報を付加したコンテナの起動方法の定義を、カタログとしてカタログ情報に登録する技術がある。

特開２００１−２２５６７号公報 特開２０１９−１５９８２５号公報

しかしながら、従来技術では、ユーザは、複数のアプリを組み合わせる場合、あるインターフェースを介して第１のアプリから出力されたデータを、別のインターフェースを介して第２のアプリへと入力する際、データの形式を人手で変換することになる。このため、ユーザにかかる作業負担の増大化を招くという問題がある。

１つの側面では、本発明は、複数のアプリを組み合わせて利用し易くすることを目的とする。

１つの実施態様によれば、複数のアプリのそれぞれのアプリに対応し、当該アプリ個別の形式である個別インターフェースと、前記複数のアプリ共通の形式である共通インターフェースとを接続するプロキシを生成可能にする第１の定義情報を取得し、前記それぞれのアプリに対応し、当該アプリと、当該アプリに対応する前記プロキシとが実行される仮想環境を生成可能にする第２の定義情報を取得し、取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する情報処理プログラム、情報処理方法、および情報処理装置が提案される。

一態様によれば、複数のアプリを組み合わせて利用し易くすることが可能になる。

図１は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。 図２は、情報処理システム２００の一例を示す説明図である。 図３は、情報処理装置１００のハードウェア構成例を示すブロック図である。 図４は、情報処理装置１００の機能的構成例を示すブロック図である。 図５は、情報処理装置１００の動作の流れを示す説明図である。 図６は、情報処理装置１００の動作の一例を示す説明図である。 図７は、レシピ定義の一例を示す説明図（その１）である。 図８は、レシピ定義の一例を示す説明図（その２）である。 図９は、レシピ定義の一例を示す説明図（その３）である。 図１０は、共通Ｉ／Ｆの一例を示す説明図である。 図１１は、引数および戻り値の一例を示す説明図である。 図１２は、プロキシ定義の一例を示す説明図（その１）である。 図１３は、プロキシ定義の一例を示す説明図（その２）である。 図１４は、プロキシ定義の一例を示す説明図（その３）である。 図１５は、プロキシ定義の一例を示す説明図（その４）である。 図１６は、プロキシ定義の一例を示す説明図（その５）である。 図１７は、データフロー定義を作成する一例を示す説明図である。 図１８は、レシピ定義作成処理手順の一例を示すフローチャートである。 図１９は、プロキシ定義作成処理手順の一例を示すフローチャートである。 図２０は、ビルド処理手順の一例を示すフローチャートである。 図２１は、連携処理手順の一例を示すフローチャートである。

以下に、図面を参照して、本発明にかかる情報処理プログラム、情報処理方法、および情報処理装置の実施の形態を詳細に説明する。

（実施の形態にかかる情報処理方法の一実施例）
図１は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。情報処理装置１００は、複数のアプリを組み合わせて利用し易くするコンピュータである。情報処理装置１００は、例えば、サーバ、または、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などである。

アプリは、例えば、データ利活用のツールとなるソフトウェアである。アプリは、例えば、データを収集、蓄積、加工、分析、または、可視化する用途に適したソフトウェアである。アプリは、具体的には、デスクトップで動作するデスクトップアプリ、または、ブラウザで操作可能な、サーバ上で動作するウェブアプリなどである。

データを収集、蓄積、または、加工する用途に適したアプリは、具体的には、ＥＴＬ（Ｅｘｔｒａｃｔ Ｔｒａｎｓｆｏｒｍ Ｌｏａｄ）ツール、または、ＥＬＴ（Ｅｘｔｒａｃｔ Ｌｏａｄ Ｔｒａｎｓｆｏｒｍ）ツールなどである。データを分析する用途に適したアプリは、具体的には、Ｊｕｐｙｔｅｒ Ｎｏｔｅｂｏｏｋ、または、Ｒ Ｓｔｕｄｉｏなどである。データを可視化する用途に適したアプリは、具体的には、ＢＩ（Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ）ツールなどである。

ユーザは、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）機器のデータ、または、個人データなどを、収集および蓄積し、加工および分析し、分析した結果を可視化することにより、ビジネスなどに利活用することを望む場合がある。分析は、例えば、ＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）学習である。この場合、ユーザは、データを収集、蓄積、または、加工する用途に適した複数のアプリを組み合わせて利用することになる。

しかしながら、従来では、複数のアプリを組み合わせて利用することは難しい。例えば、複数のアプリは、それぞれ異なる形式のインターフェースを有することがある。形式とは、例えば、プロトコルである。このため、ユーザは、あるインターフェースを介して第１のアプリから出力されたデータを、別のインターフェースを介して第２のアプリへと入力する際、データの形式を人手で変換することになり、ユーザにかかる作業負担の増大化を招くという問題がある。

これに対し、アプリが有するインターフェースの組み合わせごとに、インターフェース間でデータをやり取り可能に、入出力されるデータの形式を変換する変換ツールを、ユーザが用意する手法が考えられる。この手法でも、複数のアプリを組み合わせて利用することは難しく、ユーザにかかる作業負担の増大化を招くという問題がある。例えば、アプリの数が増加するほど、用意する変換ツールの数の膨大化を招き、変換ツールをユーザが用意する際にかかる作業負担の膨大化を招くという問題がある。

また、複数のアプリが、共通の形式のインターフェースを有するよう、ユーザが、それぞれのアプリのソースコードを改変し、それぞれのアプリをコンパイルし直す手法が考えられる。この手法では、ユーザにかかる作業負担の増大化を招くという問題がある。また、この手法では、それぞれのアプリに関するユーザの使用感が損なわれるおそれがあり、それぞれのアプリの利便性の低下を招くおそれがある。また、この手法は、いずれかのアプリのソースコードが公開されていない状況には適用することが難しい。

そこで、本実施の形態では、それぞれのアプリに関するユーザの使用感を損なわず、複数のアプリを組み合わせて利用し易くすることができる情報処理方法について説明する。

図１において、情報処理装置１００は、複数のアプリ１０１を有する。複数のアプリ１０１は、それぞれ異なる形式のインターフェースを有する。以下の説明では、インターフェース（Ｉｎｔｅｒｆａｃｅ）を「Ｉ／Ｆ」と表記する場合がある。また、あるアプリ１０１が有する、当該アプリ１０１個別の形式であるＩ／Ｆを「個別Ｉ／Ｆ１０２」と表記する場合がある。

（１−１）情報処理装置１００は、それぞれのアプリ１０１について第１の定義情報１１０を取得する。あるアプリ１０１についての第１の定義情報１１０は、例えば、当該アプリ１０１に対応するプロキシ１０３を生成可能にする情報である。あるアプリ１０１に対応するプロキシ１０３は、例えば、当該アプリ１０１の個別Ｉ／Ｆ１０２と、複数のアプリ１０１共通の形式である共通Ｉ／Ｆ１０４とを接続するソフトウェアである。情報処理装置１００は、例えば、ユーザの操作入力に基づき、それぞれのアプリ１０１について第１の定義情報１１０を取得する。

（１−２）情報処理装置１００は、それぞれのアプリ１０１について第２の定義情報１２０を取得する。あるアプリ１０１についての第２の定義情報１２０は、例えば、当該アプリ１０１と、当該アプリ１０１に対応するプロキシ１０３とが実行される仮想環境を生成可能にする情報である。仮想環境は、例えば、コンテナである。コンテナは、例えば、プロセスを特別な状態で実行する実行空間である。特別な状態とは、プロセスがアイソレートされた状態であり、プロセスに実行空間内で一意なＰＩＤ（Ｐｒｏｃｅｓｓ ＩＤ）が付与される状態である。仮想環境は、例えば、仮想マシンであってもよい。情報処理装置１００は、例えば、ユーザの操作入力に基づき、それぞれのアプリ１０１について第２の定義情報１２０を取得する。

（１−３）情報処理装置１００は、取得した第１の定義情報１１０と、取得した第２の定義情報１２０とに基づいて、それぞれのアプリ１０１に対応する仮想環境を生成すると共に、当該仮想環境で実行されるプロキシ１０３を生成する。仮想環境は、例えば、情報処理装置１００において起動される。情報処理装置１００は、例えば、アプリ１０１ごとに、当該アプリ１０１と、当該アプリ１０１に対応するプロキシ１０３とが実行されるコンテナを、自装置において起動する。これにより、情報処理装置１００は、複数のアプリ１０１を組み合わせて利用し易くすることができる。

情報処理装置１００は、例えば、あるアプリ１０１のＩ／Ｆから出力されたデータを、他のアプリ１０１のＩ／Ｆに入力する際、ユーザがデータの形式を変換せずに済ませることができ、ユーザにかかる作業負担の低減化を図ることができる。

また、情報処理装置１００は、ユーザが、アプリ１０１の数分、第１の定義情報１１０と第２の定義情報１２０とを用意すれば、複数のアプリ１０１を組み合わせて利用可能にすることができる。このため、情報処理装置１００は、ユーザが、アプリ１０１の組み合わせの数分、変換ツールを用意せずに済ませることができ、ユーザにかかる作業負担の低減化を図ることができる。

また、情報処理装置１００は、ユーザが、アプリ１０１の数分、第１の定義情報１１０と第２の定義情報１２０とを用意すれば、複数のアプリ１０１を組み合わせて利用可能にすることができる。このため、情報処理装置１００は、ユーザが、それぞれのアプリ１０１のソースコードを改変せずに済ませることができ、ユーザにかかる作業負担の低減化を図ることができる。また、情報処理装置１００は、それぞれのアプリ１０１のソースコードが公開されていない状況にも適用することができる。

また、情報処理装置１００は、プロキシ１０３により、データの形式を変換することにより、ユーザが、それぞれのアプリ１０１のＩ／Ｆの形式を意識せずに済ませることができ、それぞれのアプリ１０１に関するユーザの使用感を損なわずに済ませることができる。

結果として、情報処理装置１００は、ユーザが、ＩｏＴ機器のデータ、または、個人データなどを、収集および蓄積し、加工および分析し、分析した結果を可視化し易くすることができる。そして、情報処理装置１００は、ユーザが、分析した結果を、ビジネスなどに利活用し易くすることができる。

ここでは、情報処理装置１００が、それぞれのアプリ１０１に対応する仮想環境を、自装置において起動する場合について説明したが、これに限らない。例えば、情報処理装置１００が、それぞれのアプリ１０１に対応する仮想環境を、他のコンピュータにおいて起動させる場合があってもよい。この場合の一例は、例えば、図２を用いて後述する。

ここでは、情報処理装置１００が、ユーザの操作入力に基づき、それぞれのアプリ１０１について、第１の定義情報１１０と第２の定義情報１２０とを取得する場合について説明したが、これに限らない。例えば、情報処理装置１００が、それぞれのアプリ１０１についての第１の定義情報１１０と第２の定義情報１２０とを、他のコンピュータから受信することにより取得する場合があってもよい。この場合の一例は、例えば、図２を用いて後述する。

（情報処理システム２００の一例）
次に、図２を用いて、図１に示した情報処理装置１００を適用した、情報処理システム２００の一例について説明する。

図２は、情報処理システム２００の一例を示す説明図である。図２において、情報処理システム２００は、情報処理装置１００と、１以上の端末装置２０１と、クライアント装置２０２とを含む。

情報処理システム２００において、情報処理装置１００と端末装置２０１とは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどである。

情報処理装置１００は、複数のアプリのそれぞれのアプリについて、第１の定義情報と第２の定義情報とを、クライアント装置２０２から受信することにより取得する。

情報処理装置１００は、複数のアプリのそれぞれのアプリについて取得した、第１の定義情報と第２の定義情報とに基づいて、端末装置２０１を制御し、複数のアプリのそれぞれのアプリに対応するコンテナを、端末装置２０１において起動させる。コンテナは、アプリとプロキシとが実行される実行空間である。

情報処理装置１００は、例えば、アプリとプロキシとが実行されるコンテナを起動可能にするレシピ情報を、端末装置２０１に送信することにより、アプリとプロキシとが実行されるコンテナを、端末装置２０１において起動させる。情報処理装置１００は、例えば、サーバ、または、ＰＣなどである。

端末装置２０１は、情報処理装置１００の制御に従って、コンテナを起動するコンピュータである。端末装置２０１は、例えば、アプリとプロキシとが実行されるコンテナを起動可能にするレシピ情報を、情報処理装置１００から受信し、受信したレシピ情報に基づいて、アプリとプロキシとが実行されるコンテナを起動する。端末装置２０１は、例えば、サーバ、ＰＣ、タブレット端末、または、スマートフォンなどである。

クライアント装置２０２は、複数のアプリのそれぞれのアプリについて、第１の定義情報と第２の定義情報とを、情報処理装置１００に送信する。クライアント装置２０２は、例えば、サーバ、ＰＣ、タブレット端末、または、スマートフォンなどである。

ここでは、情報処理システム２００が、１つの情報処理装置１００を含む場合について説明したが、これに限らない。例えば、情報処理システム２００が、複数の情報処理装置１００を含む場合があってもよい。この場合、複数の情報処理装置１００が、協働し、端末装置２０１にコンテナを起動させる。

ここでは、情報処理装置１００が、端末装置２０１とは異なる装置である場合について説明したが、これに限らない。例えば、情報処理装置１００が、いずれかの端末装置２０１と一体である場合があってもよい。この場合、情報処理装置１００が、いずれかのアプリに対応するコンテナを、自装置において起動する。

（情報処理装置１００のハードウェア構成例）
次に、図３を用いて、情報処理装置１００のハードウェア構成例について説明する。

図３は、情報処理装置１００のハードウェア構成例を示すブロック図である。図３において、情報処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ネットワークＩ／Ｆ３０３と、記録媒体Ｉ／Ｆ３０４と、記録媒体３０５とを有する。また、各構成部は、バス３００によってそれぞれ接続される。

ここで、ＣＰＵ３０１は、情報処理装置１００の全体の制御を司る。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。

ネットワークＩ／Ｆ３０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータに接続される。そして、ネットワークＩ／Ｆ３０３は、ネットワーク２１０と内部のＩ／Ｆを司り、他のコンピュータからのデータの入出力を制御する。ネットワークＩ／Ｆ３０３は、例えば、モデムやＬＡＮアダプタなどである。

記録媒体Ｉ／Ｆ３０４は、ＣＰＵ３０１の制御に従って記録媒体３０５に対するデータのリード／ライトを制御する。記録媒体Ｉ／Ｆ３０４は、例えば、ディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポートなどである。記録媒体３０５は、記録媒体Ｉ／Ｆ３０４の制御で書き込まれたデータを記憶する不揮発メモリである。記録媒体３０５は、例えば、ディスク、半導体メモリ、ＵＳＢメモリなどである。記録媒体３０５は、情報処理装置１００から着脱可能であってもよい。

情報処理装置１００は、上述した構成部の他、例えば、キーボード、マウス、ディスプレイ、プリンタ、スキャナ、マイク、スピーカーなどを有してもよい。また、情報処理装置１００は、記録媒体Ｉ／Ｆ３０４や記録媒体３０５を複数有していてもよい。また、情報処理装置１００は、記録媒体Ｉ／Ｆ３０４や記録媒体３０５を有していなくてもよい。

（端末装置２０１のハードウェア構成例）
端末装置２０１のハードウェア構成例は、図３に示した情報処理装置１００のハードウェア構成例と同様であるため、説明を省略する。

（クライアント装置２０２のハードウェア構成例）
クライアント装置２０２のハードウェア構成例は、図３に示した情報処理装置１００のハードウェア構成例と同様であるため、説明を省略する。クライアント装置２０２は、例えば、キーボード、マウス、ディスプレイなどを有することが好ましい。

（情報処理装置１００の機能的構成例）
次に、図４を用いて、情報処理装置１００の機能的構成例について説明する。

図４は、情報処理装置１００の機能的構成例を示すブロック図である。情報処理装置１００は、記憶部４００と、取得部４０１と、生成部４０２と、実行部４０３と、出力部４０４とを含む。

記憶部４００は、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域によって実現される。以下では、記憶部４００が、情報処理装置１００に含まれる場合について説明するが、これに限らない。例えば、記憶部４００が、情報処理装置１００とは異なる装置に含まれ、記憶部４００の記憶内容が情報処理装置１００から参照可能である場合があってもよい。

取得部４０１〜出力部４０４は、制御部の一例として機能する。取得部４０１〜出力部４０４は、具体的には、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、ネットワークＩ／Ｆ３０３により、その機能を実現する。各機能部の処理結果は、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域に記憶される。

記憶部４００は、各機能部の処理において参照され、または更新される各種情報を記憶する。記憶部４００は、複数のアプリを記憶する。複数のアプリは、それぞれ個別の形式である個別Ｉ／Ｆを有する。形式とは、例えば、プロトコルである。個別Ｉ／Ｆは、ＵＩ、ＡＰＩ、または、ＣＬＩである。記憶部４００は、例えば、複数のアプリのそれぞれのアプリの実行ファイルを記憶する。

記憶部４００は、第１の定義情報を記憶する。記憶部４００は、例えば、複数のアプリのそれぞれのアプリについての第１の定義情報を記憶する。あるアプリについての第１の定義情報は、例えば、当該アプリに対応するプロキシを生成可能にする情報である。あるアプリに対応するプロキシは、例えば、当該アプリの個別Ｉ／Ｆと、複数のアプリ共通の形式である共通Ｉ／Ｆとを接続するソフトウェアである。第１の定義情報は、例えば、後述するプロキシ定義である。プロキシ定義は、例えば、所望の機能を実現するために、どのような順序で、いずれのＩ／Ｆを用いればよいかを規定する。第１の定義情報は、例えば、取得部４０１によって取得される。

記憶部４００は、第２の定義情報を記憶する。記憶部４００は、例えば、複数のアプリのそれぞれのアプリについての第２の定義情報を記憶する。あるアプリについての第２の定義情報は、例えば、当該アプリと、当該アプリに対応するプロキシとが実行される仮想環境を生成可能にする情報である。第２の定義情報は、例えば、後述するレシピ定義である。レシピ定義は、例えば、データフローにおいて、アプリに与えるパラメータ、または、入出力などを規定する。レシピ定義は、例えば、データフローにおいて、アプリを部品として扱うことを可能にする。第２の定義情報は、例えば、取得部４０１によって取得される。

仮想環境は、例えば、コンテナである。コンテナは、例えば、プロセスを特別な状態で実行する実行空間である。特別な状態とは、プロセスがアイソレートされた状態であり、プロセスに実行空間内で一意なＰＩＤが付与される状態である。また、プロセスは、コンピュータ内で一意な別のＰＩＤも付与されることがある。仮想環境は、例えば、仮想マシンであってもよい。

記憶部４００は、いずれかのアプリに対応するイメージデータを記憶する。あるアプリに対応するイメージデータは、当該アプリに対応する仮想環境と共に、当該仮想環境で実行されるプロキシを纏めて、実体として生成可能にするためのデータである。イメージデータは、例えば、コンテナとなるファイルの集まりであり、依存関係のあるファイルの集まりである。依存関係のあるファイルは、例えば、バイナリ、設定ファイル、関連ファイル、および、データなどである。イメージデータは、例えば、後述するレシピである。イメージデータは、例えば、生成部４０２によって生成される。記憶部４００は、例えば、コンテナのインスタンスを生成可能にするイメージデータを記憶する。

記憶部４００は、データフローを記憶する。データフローは、データと複数のアプリの少なくともいずれかのアプリを利用するタスクとの依存関係を示す情報である。データフローは、例えば、取得部４０１によって取得される。タスクは、例えば、いずれかのアプリを利用して、所定の定義ファイルを実行する。

取得部４０１は、各機能部の処理に用いられる各種情報を取得する。取得部４０１は、取得した各種情報を、記憶部４００に記憶し、または、各機能部に出力する。また、取得部４０１は、記憶部４００に記憶しておいた各種情報を、各機能部に出力してもよい。取得部４０１は、例えば、ユーザの操作入力に基づき、各種情報を取得する。取得部４０１は、例えば、情報処理装置１００とは異なる装置から、各種情報を受信してもよい。

取得部４０１は、第１の定義情報を取得する。取得部４０１は、例えば、複数のアプリのそれぞれのアプリについての第１の定義情報を取得する。取得部４０１は、具体的には、ユーザの操作入力に基づき、複数のアプリのそれぞれのアプリについての第１の定義情報を取得し、記憶部４００に記憶する。

取得部４０１は、第２の定義情報を取得する。取得部４０１は、例えば、複数のアプリのそれぞれのアプリについての第２の定義情報を取得する。取得部４０１は、具体的には、ユーザの操作入力に基づき、複数のアプリのそれぞれのアプリについての第２の定義情報を取得し、記憶部４００に記憶する。

取得部４０１は、データフローを取得する。取得部４０１は、例えば、ユーザの操作入力に基づき、データフローを取得し、記憶部４００に記憶する。

取得部４０１は、いずれかの機能部の処理を開始する開始トリガーを受け付けてもよい。開始トリガーは、例えば、ユーザによる所定の操作入力があったことである。開始トリガーは、例えば、他のコンピュータから、所定の情報を受信したことであってもよい。開始トリガーは、例えば、いずれかの機能部が所定の情報を出力したことであってもよい。

取得部４０１は、例えば、複数のアプリのそれぞれのアプリについての第１の定義情報と第２の定義情報とを取得したことを、生成部４０２の処理を開始する開始トリガーとして受け付ける。取得部４０１は、例えば、データフローを取得したことを、実行部４０３の処理を開始する開始トリガーとして受け付ける。

生成部４０２は、取得した第１の定義情報と、取得した第２の定義情報とに基づいて、複数のアプリのそれぞれのアプリに対応する仮想環境を生成すると共に、当該仮想環境で実行されるプロキシを生成する。仮想環境は、例えば、情報処理装置１００において起動される。生成部４０２は、例えば、複数のアプリのそれぞれのアプリについて、当該アプリと当該アプリに対応するプロキシとが実行されるコンテナと、当該アプリに対応するプロキシとを、情報処理装置１００において実体として生成する。プロキシは、アプリにダイレクトにアクセス可能な場所にあることが好ましい。このため、プロキシは、アプリと纏めてコンテナにおいて実行されることが好ましい。プロキシは、アプリにダイレクトにアクセス可能であれば、アプリと同一のコンテナにおいて実行されなくてもよい。これにより、生成部４０２は、複数のアプリを組み合わせて利用し易くすることができる。

生成部４０２は、取得した第１の定義情報と、取得した第２の定義情報とに基づいて、それぞれのアプリに対応する仮想環境と共に、当該仮想環境で実行されるプロキシを纏めて、実体として生成可能にするイメージデータを生成してもよい。これにより、生成部４０２は、以降、アプリに対応する仮想環境と共に、当該仮想環境で実行されるプロキシを、実体として生成し易くすることができる。

実行部４０３は、取得したデータフローと、生成したイメージデータとに基づいて、タスクが、いずれかのアプリを利用開始する際に、当該アプリに対応する仮想環境を生成すると共に、当該仮想環境で実行されるプロキシを生成する。実行部４０３は、例えば、タスクがいずれかのアプリを利用開始する際に、当該アプリに対応するイメージデータに基づいて、当該アプリに対応する仮想環境と共に、当該仮想環境で実行されるプロキシを纏めて、実体として情報処理装置１００において生成する。これにより、実行部４０３は、タスクを実施可能にすることができる。

実行部４０３は、タスクが、いずれかのアプリを利用終了する際に、当該アプリに対応する仮想環境を削除すると共に、当該仮想環境で実行されるプロキシを削除する。実行部４０３は、例えば、タスクが、いずれかのアプリを利用終了する際に、当該アプリに対応する仮想環境の実体と共に、当該仮想環境で実行されるプロキシの実体を、情報処理装置１００において削除する。これにより、実行部４０３は、処理リソースを節約することができる。

出力部４０４は、いずれかの機能部の処理結果を出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、ネットワークＩ／Ｆ３０３による外部装置への送信、または、メモリ３０２や記録媒体３０５などの記憶領域への記憶である。これにより、出力部４０４は、いずれかの機能部の処理結果をユーザに通知可能にし、情報処理装置１００の利便性の向上を図ることができる。

（情報処理装置１００の動作の流れ）
次に、図５を用いて、情報処理装置１００の動作の流れについて説明する。

図５は、情報処理装置１００の動作の流れを示す説明図である。図５において、情報処理装置１００は、ツールＡと、ツールＢとを有する。ツールＡは、例えば、ＥＴＬツールとなるアプリである。ツールＢは、例えば、データの分析および可視化に適したアプリである。

情報処理装置１００は、ツールＡと、ツールＡに対応するプロキシ５１１とを一体化したコンテナを起動可能にするコンテナイメージと、ツールＢと、ツールＢに対応するプロキシ５１２とを一体化したコンテナを起動可能にするコンテナイメージとを生成する。

情報処理装置１００は、フローエディタ５０１を有する。フローエディタ５０１は、ユーザの操作入力に基づき、データとタスクとの依存関係を示すデータフローを作成するソフトウェアである。タスクは、例えば、ツールを利用して行われる処理である。タスクは、ツールを利用して、所定の定義ファイルの内容を実行する処理である。タスクは、具体的には、ツールＡ、または、ツールＢなどを利用する処理である。

情報処理装置１００は、例えば、フローエディタ５０１により、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を介して、各種データと、ツールＡを利用するタスクと、ツールＢを利用するタスクとの依存関係を示すデータフローを作成する。

情報処理装置１００は、フローエディタ５０１により、ＧＵＩを介して、データフローを修正してもよい。情報処理装置１００は、例えば、データフローのうち、ツールＡを利用するタスクが出力するデータ２に代わり、ツールＡを利用するタスクが出力するデータ３を、ツールＢを利用するタスクに接続し、データフローを修正する。

情報処理装置１００は、フローエンジン５０２を有する。フローエンジン５０２は、ツール連携機能を有する。ツール連携機能は、データフローに従って、ツールをどの順序で利用するのかを決定する。ツール連携機能は、ツールを利用して、どのようにタスクの処理内容を実現するのかを決定する。ツール連携機能は、例えば、ツール内で、どのような処理を実施するのかを編集し、決定する。ツール連携機能は、データフローに従って、ツールを利用して、一連のタスクを実行し、全体の処理を行う。

ツール連携機能は、例えば、生成されたコンテナイメージに基づいて、ツールＡを利用するタスクから出力されたデータ３を、ツールＢを利用するタスクへの入力とし、一連のタスクを実行する。これにより、情報処理装置１００は、複数のツールを組み合わせて利用し易くすることができ、ユーザにかかる作業負担の低減化を図ることができる。

（情報処理装置１００の動作の一例）
次に、図６を用いて、情報処理装置１００の動作の一例について説明する。

図６は、情報処理装置１００の動作の一例を示す説明図である。図６において、情報処理装置１００は、ツールＡ６３１、および、ツールＢ６４１などの複数のツールを有する。

情報処理装置１００は、ユーザの操作入力に基づき、ツールごとのレシピ定義６０１を取得する。レシピ定義６０１の一例については、具体的には、図７〜図９を用いて後述する。情報処理装置１００は、ユーザの操作入力に基づき、ツールごとのプロキシ定義６０２を取得する。プロキシ定義６０２の一例については、具体的には、図１２〜図１６を用いて後述する。

情報処理装置１００は、プロキシバイナリ６１１を有する。プロキシバイナリ６１１は、例えば、ツールレシピを作成する際に用いられるデータを含む。ツールレシピは、ツールとプロキシとが実行されるコンテナを起動可能にするコンテナイメージである。プロキシバイナリ６１１は、具体的には、ツールレシピを作成する際に用いられる、プロキシの処理内容を規定するためのデータを含む。情報処理装置１００は、レシピビルド機能６１２を有する。レシピビルド機能６１２は、ツールごとのツールレシピを作成する機能である。

情報処理装置１００は、イメージレジストリ６２１を有する。イメージレジストリ６２１は、例えば、ツールレシピを含む。イメージレジストリ６２１は、具体的には、テンプレートとなるコンテナイメージを含む。情報処理装置１００は、開発データ集合６２２を有する。開発データ集合６２２は、例えば、ＧｉｔＨｕｂなどの開発プラットフォームのデータを含む。開発データ集合６２２は、具体的には、Ｄｏｃｋｅｒｆｉｌｅのデータを含む。

情報処理装置１００は、レシピビルド機能６１２により、イメージレジストリ６２１と、開発データ集合６２２とに基づいて、ツールごとのツールレシピを作成する。ツールレシピは、ツールとプロキシとが実行されるコンテナを起動可能にするコンテナイメージである。図６の例では、情報処理装置１００は、レシピビルド機能６１２により、テンプレートとなるコンテナイメージと、Ｄｏｃｋｅｒｆｉｌｅとに基づいて、ツールＡレシピ、および、ツールＢレシピなどを作成する。

ツールＡレシピは、ツールＡ６３１が実行されるコンテナ６３０を起動可能にするコンテナイメージである。コンテナ６３０は、ツールＡ６３１を含む。コンテナ６３０は、プロキシを実現する、ツールＡ向けプロキシ定義６３２と、プロキシバイナリ６３３との組み合わせを含む。

プロキシバイナリ６３３は、ＵＩ操作、ＡＰＩ操作、ＣＬＩ操作、および、ファイル操作などを実施可能である。プロキシバイナリ６３３は、ツールＡ６３１の個別Ｉ／Ｆと、コンテナ６３０に設けられる共通Ｉ／Ｆ６３５とを接続する。個別Ｉ／Ｆは、ＵＩ、ＡＰＩ、および、ＣＬＩなどである。コンテナ６３０は、ツールＡ６３１の処理結果などを記憶するファイルシステム６３４を含む。

ツールＢレシピは、ツールＢ６４１が実行されるコンテナ６４０を起動可能にするコンテナイメージである。コンテナ６４０は、ツールＢ６４１を含む。コンテナ６４０は、プロキシを実現する、ツールＢ向けプロキシ定義６４２と、プロキシバイナリ６４３との組み合わせを含む。

プロキシバイナリ６４３は、ＵＩ操作、ＡＰＩ操作、ＣＬＩ操作、および、ファイル操作などを実施可能である。プロキシバイナリ６４３は、ツールＢ６４１の個別Ｉ／Ｆと、コンテナ６４０に設けられる共通Ｉ／Ｆ６４５とを接続する。個別Ｉ／Ｆは、ＵＩ、ＡＰＩ、および、ＣＬＩなどである。コンテナ６４０は、ツールＢ６４１の処理結果などを記憶するファイルシステム６４４を含む。

これにより、情報処理装置１００は、共通Ｉ／Ｆを介して、複数のツールを利用可能にすることができる。情報処理装置１００は、例えば、共通Ｉ／Ｆ６３５，６４５などを介して、ツールＡ６３１、および、ツールＢ６４１などの複数のツールに、同一の形式でデータを入出力可能にすることができる。このため、情報処理装置１００は、複数のツールを組み合わせて利用し易くすることができ、ユーザにかかる作業負担の低減化を図ることができる。

情報処理装置１００は、データフローエディタ６５１を有する。データフローエディタ６５１は、ユーザの操作入力に基づき、データとタスクとの依存関係を示し、一連のタスクを規定したデータフロー定義６５３を作成するソフトウェアである。タスクは、例えば、ツールを利用して行われる処理である。タスクは、ツールを利用して、所定の定義ファイルの内容を実行する処理である。タスクは、具体的には、ツールＡ、または、ツールＢなどを利用する処理である。

情報処理装置１００は、例えば、データフローエディタ６５１により、ＧＵＩを介して、各種データと、ツールＡを利用するタスクと、ツールＢを利用するタスクとの依存関係を示すデータフロー定義６５３を作成する。

情報処理装置１００は、データフローエンジン６５２を有する。データフローエンジン６５２は、ツール連携機能６６１を有する。ツール連携機能６６１は、コンテナを制御可能である。ツール連携機能６６１は、共通Ｉ／Ｆを操作可能である。ツール連携機能６６１は、データフロー定義６５３に従って、ツールをどの順序で利用するのかを決定する。ツール連携機能６６１は、ツールを利用して、どのようにタスクの処理内容を実現するのかを決定する。

ツール連携機能６６１は、データフロー定義６５３に従って、ツールを利用して、一連のタスクを実行する。ツール連携機能６６１は、例えば、生成されたコンテナイメージに基づいて、タスクが利用するツールを含むコンテナを作成し、ツールに対して、編集時操作、または、実行時操作を実行した後、作成したコンテナを削除する。これにより、ツール連携機能６６１は、ツールを利用して、一連のタスクを順に実行する。

編集時操作は、例えば、定義ファイルを編集する際に行う操作である。編集時操作の一例は、具体的には、図１０を用いて後述する。実行時操作は、例えば、定義ファイルを実行する際に行う操作である。実行時操作の一例は、具体的には、図１０を用いて後述する。これにより、情報処理装置１００は、ユーザが、複数のツールを組み合わせて、所望のデータ利活用タスクを実施可能にすることができる。また、情報処理装置１００は、ユーザが、複数のツールを組み合わせ直し、データ利活用タスクを変更する際に、ユーザにかかる処理負担の低減化を図ることができる。

（レシピ定義の一例）
次に、図７〜図９を用いて、レシピ定義の一例について説明する。

図７〜図９は、レシピ定義の一例を示す説明図である。レシピ定義は、ツールのコンテナイメージ、および、ツールのコンテナイメージからの変更差分などのデータを含む。レシピ定義は、プロキシ定義の手元側のファイルパス、および、レシピのメタデータなどのデータを含む。メタデータは、例えば、レシピ名、ポート、ツールで実行する定義ファイルなどのデータである。

図７において、表７００は、レシピ定義に含まれる各種データの一覧を示す。表７００における、（＊）印付きのデータは、レシピ定義に含まれることが好ましいデータである。表７００は、具体的には、ｐｅｎｔａｈｏ・データインテグレーションと呼ばれるツールに関するレシピ定義を一例として示す。

レシピ定義は、例えば、属性値：データの型＝ｎａｍｅ：ｓｔｒｉｎｇ（＊）である第１のデータを含む。第１のデータは、レシピに付与されるレシピ名である。第１のデータは、例えば、Ｐｅｎｔａｈｏ Ｄｌである。第１のデータは、初期値なしである。

レシピ定義は、例えば、属性値：データの型＝ｖｅｒｓｉｏｎ：ｓｔｒｉｎｇである第２のデータを含む。第２のデータは、レシピのバージョンである。第２のデータは、例えば、１．０．０である。第２のデータは、ｌａｔｅｓｔである。

レシピ定義は、例えば、属性値：データの型＝ｄｅｓｃｒｉｐｔｉｏｎ：ｓｔｒｉｎｇである第３のデータを含む。第３のデータは、レシピの説明である。第３のデータは、例えば、説明の文章である。第３のデータは、空文字列である。

レシピ定義は、例えば、属性値：データの型＝ｄｅｆｉｎｉｔｉｏｎ：ｓｔｒｉｎｇである第４のデータを含む。第４のデータは、プロジェクトフォルダの下位に存在し、ｎｏｔｅｓフォルダに格納される定義ファイルに付与される定義ファイル名である。第４のデータは、例えば、ｅｘａｍｐｌｅ．ｋｔｒである。第４のデータは、空文字列である。

レシピ定義は、例えば、属性値：データの型＝ｐｏｒｔｓ：Ｐｏｒｔ［］である第５のデータを含む。第５のデータは、ポート情報の配列である。ポート情報の配列は、−ｎａｍｅ：ポート名と、−ｐｏｒｔ：ポート番号とを含む。第５のデータは、例えば、−ｎａｍｅ：“ｗｅｂ”、および、ｐｏｒｔ：“８０８０”である。第５のデータは、初期値［］である。

レシピ定義は、例えば、属性値：データの型＝ｉｍａｇｅ ｎａｍｅ：ｓｔｒｉｎｇ（＊）である第６のデータを含む。第６のデータは、イメージに付与されるイメージ名である。第６のデータは、例えば、ｐｅｎｔａｈｏ＿ｎｅｗである。第６のデータは、初期値なしである。

レシピ定義は、例えば、属性値：データの型＝ｉｍａｇｅ ｔａｇ：ｓｔｒｉｎｇ（＊）である第７のデータを含む。第７のデータは、イメージに付与されるイメージタグである。イメージタグは、例えば、バージョン名に対応する。第７のデータは、例えば、ｌａｔｅｓｔである。第７のデータは、初期値ｌａｔｅｓｔである。

レシピ定義は、例えば、属性値：データの型＝ｉｍａｇｅ ｆｒｏｍ：ｓｔｒｉｎｇ（＊）である第８のデータを含む。第８のデータは、イメージの元となるベースイメージに付与されるイメージ名である。第８のデータは、例えば、ｈｉｒｏｍｕｈｏｔａ／ｗｅｂｓｐｏｏｎ：０．８．２．１９である。第８のデータは、初期値なしである。

レシピ定義は、例えば、属性値：データの型＝ｉｍａｇｅ ｃｍｄ：ｓｔｒｉｎｇ［］（＊）である第９のデータを含む。第９のデータは、ツールの実行コマンドである。実行コマンドは、例えば、シェルスクリプトである。第９のデータは、例えば、−／ｕｓｒ／ｌｏｃａｌ／ｔｏｍｃａｔ／ｂｉｎ／ｃａｔａｌｉｎａ．ｓｈ、および、−ｒｕｎなどである。第９のデータは、初期値なしである。

レシピ定義は、例えば、属性値：データの型＝ｉｍａｇｅ ｃｈａｎｇｅｓ：ｓｔｒｉｎｇ［］である第１０のデータを含む。第１０のデータは、Ｄｏｃｋｅｒｆｉｌｅに加える追加コマンドである。第１０のデータは、例えば、ツールのベースイメージに、どのような改良を加えるのかを示すＤｏｃｋｅｒｆｉｌｅとして作成されるデータである。第１０のデータは、例えば、ＣＯＰＹ ａｓｓｅｔｓ／ｓａｍｐｌｅｓ／ｓａｍｐｌｅｓ／である。第１０のデータは、初期値［］である。

レシピ定義は、例えば、属性値＝ｉｍａｇｅ ｐｒｏｘｙ：ｆｉｌｅ（＊）である第１１のデータを含む。第１１のデータは、プロキシ定義に付与されるファイル名である。第１１のデータは、例えば、．／ｐｒｏｘｙ．ｙａｍｌである。第１１のデータは、初期値なしである。次に、図８の説明に移行する。

図８において、テキスト８００は、レシピ定義を示す。テキスト８００は、文１を含む。文１は、例えば、メタデータを示す。メタデータは、例えば、レシピ名、バージョン、説明などを含む。テキスト８００は、文２を含む。文２は、例えば、ツールにより読み書きされる定義ファイルのファイルパスを示す。

テキスト８００は、文４を含む。文４は、例えば、イメージが公開するポート番号に対応するタスクノードのポートを示す。テキスト８００は、文５を含む。文５は、例えば、コンテナイメージのイメージ名およびイメージタグを示す。テキスト８００は、文６を含む。文６は、例えば、コンテナ起動時の実行コマンドを示す。

テキスト８００は、文７を含む。文７は、例えば、ツールのコンテナイメージからの変更差分を示す。変更差分は、定義ファイルを配置するコンテナ側のフォルダの所有権およびアクセス権を、データ利活用基盤と合わせるため、および、ツールの禁止操作を実現するためのデータである。変更差分は、例えば、ファイルシステムに配置されたフォルダの所有権およびアクセス権を規定したり、ツールに与える設定ファイルを規定したりする。変更差分は、例えば、データ利活用基盤におけるユーザＩＤと、コンテナにおけるユーザＩＤとを対応付ける。テキスト８００は、文８を含む。文８は、例えば、プロキシ定義のファイル名を示す。次に、図９の説明に移行する。

図９において、テキスト９００は、イメージのメタデータを示す。イメージのメタデータは、例えば、ｄｏｃｋｅｒ ｉｎｓｐｅｃｔによって取得される。

（共通Ｉ／Ｆの一例）
次に、図１０を用いて、共通Ｉ／Ｆの一例について説明する。

図１０は、共通Ｉ／Ｆの一例を示す説明図である。共通Ｉ／Ｆは、ツールによらず共通の操作に対応する機能を有する。共通Ｉ／Ｆは、例えば、編集時操作、または、実行時操作に対応する機能を有する。

編集時操作は、例えば、ＵＩを開く、定義ファイルを取得、入力データを取得、環境パラメータを取得などの操作である。実行時操作は、定義ファイルを実行、または、定義ファイルの実行結果を取得などの操作である。図１０において、表１０００は、例えば、共通Ｉ／Ｆが有する各機能について示す。

編集時操作に対応する機能は、例えば、ＯｐｅｎＵｓｅｒＩｎｔｅｒｆａｃｅである。ＯｐｅｎＵｓｅｒＩｎｔｅｒｆａｃｅは、例えば、引数なしであり、戻り値ＵＩである。ＯｐｅｎＵｓｅｒＩｎｔｅｒｆａｃｅは、例えば、ＵＩを開く機能である。ＯｐｅｎＵｓｅｒＩｎｔｅｒｆａｃｅは、例えば、ツールがウェブアプリである場合、エンドポイントを取得する機能である。

編集時操作に対応する機能は、例えば、ＣｌｏｓｅＵｓｅｒＩｎｔｅｒｆａｃｅである。ＣｌｏｓｅＵｓｅｒＩｎｔｅｒｆａｃｅは、例えば、引数なしであり、戻り値Ｍａｓｓａｇｅである。ＣｌｏｓｅＵｓｅｒＩｎｔｅｒｆａｃｅは、例えば、ＵＩを閉じる機能である。

編集時操作に対応する機能は、例えば、ＧｅｔＤｅｆｉｎｉｔｉｏｎである。ＧｅｔＤｅｆｉｎｉｔｉｏｎは、例えば、引数なしであり、戻り値Ｄｅｆｉｎｉｔｉｏｎである。ＧｅｔＤｅｆｉｎｉｔｉｏｎは、例えば、定義ファイルを取得する機能である。

編集時操作に対応する機能は、例えば、ＳｅｔＤｅｆｉｎｉｔｉｏｎである。ＳｅｔＤｅｆｉｎｉｔｉｏｎは、例えば、引数Ｄｅｆｉｎｉｔｉｏｎであり、戻り値Ｍａｓｓａｇｅである。ＳｅｔＤｅｆｉｎｉｔｉｏｎは、例えば、定義ファイルを設定し、ＵＩを、ファイルを開いた状態にする機能である。

編集時操作に対応する機能は、例えば、ＬｉｓｔＩｎｐｕｔＤａｔａである。ＬｉｓｔＩｎｐｕｔＤａｔａは、例えば、引数なしであり、戻り値ＤａｔａＬｉｓｔである。ＬｉｓｔＩｎｐｕｔＤａｔａは、例えば、定義ファイル中の入力データを全取得する機能である。

編集時操作に対応する機能は、例えば、ＳｅｔＩｎｐｕｔＤａｔａである。ＳｅｔＩｎｐｕｔＤａｔａは、例えば、引数Ｄａｔａであり、戻り値Ｍａｓｓａｇｅである。ＳｅｔＩｎｐｕｔＤａｔａは、例えば、定義ファイル中の特定箇所に入力データを指定する機能である。

編集時操作に対応する機能は、例えば、ＬｉｓｔＯｕｔｐｕｔＤａｔａである。ＬｉｓｔＯｕｔｐｕｔＤａｔａは、例えば、引数なしであり、戻り値ＤａｔａＬｉｓｔである。ＬｉｓｔＯｕｔｐｕｔＤａｔａは、例えば、定義ファイル中の出力データを全取得する機能である。

編集時操作に対応する機能は、例えば、ＳｅｔＯｕｔｐｕｔＤａｔａである。ＳｅｔＯｕｔｐｕｔＤａｔａは、例えば、引数Ｄａｔａであり、戻り値Ｍａｓｓａｇｅである。ＳｅｔＯｕｔｐｕｔＤａｔａは、例えば、定義ファイル中の特定箇所に出力データを指定する機能である。

編集時操作に対応する機能は、例えば、ＧｅｔＣｏｎｆｉｇｕｒａｔｉｏｎである。ＧｅｔＣｏｎｆｉｇｕｒａｔｉｏｎは、例えば、引数なしであり、戻り値Ｃｏｎｆｉｇｕｒａｔｉｏｎである。ＧｅｔＣｏｎｆｉｇｕｒａｔｉｏｎは、例えば、環境設定パラメータを取得する機能である。

編集時操作に対応する機能は、例えば、ＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎである。ＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎは、例えば、引数Ｃｏｎｆｉｇｕｒａｔｉｏｎであり、戻り値Ｍａｓｓａｇｅである。ＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎは、例えば、環境設定パラメータを指定する機能である。

実行時操作に対応する機能は、例えば、Ｅｘｅｃｕｔｅである。Ｅｘｅｃｕｔｅは、引数なしであり、戻り値Ｅｘｅｃｕｔｉｏｎである。Ｅｘｅｃｕｔｅは、例えば、定義ファイルを実行する機能である。

実行時操作に対応する機能は、例えば、ＧｅｔＥｘｅｃｕｔｉｏｎＲｅｓｕｌｔである。ＧｅｔＥｘｅｃｕｔｉｏｎＲｅｓｕｌｔは、例えば、引数Ｅｘｅｃｕｔｉｏｎであり、戻り値ＥｘｅｃｕｔｉｏｎＲｅｓｕｌｔである。ＧｅｔＥｘｅｃｕｔｉｏｎＲｅｓｕｌｔは、例えば、実行結果を取得する機能である。

（引数および戻り値の一例）
次に、図１１を用いて、図１０に示した引数および戻り値の一例について説明する。

図１１は、引数および戻り値の一例を示す説明図である。図１１において、表１１００は、例えば、引数または戻り値の型ごとに、引数または戻り値に含まれるデータの内容について示す。

ｍａｓｓａｇｅは、例えば、属性名ｍａｓｓａｇｅ、かつ、属性型ｓｔｒｉｎｇのメッセージ本文を含む。ＵＩは、例えば、属性名ｔｙｐｅ、かつ、属性型ＵＩＴｙｐｅのＵＩの種類（ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）＝０）を含む。ＵＩは、例えば、属性名ｌｏｃａｔｉｏｎ、かつ、属性型ｓｔｒｉｎｇのＵＩの場所（ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ））を含む。

Ｄｅｆｉｎｉｔｉｏｎは、例えば、属性名ｔｙｐｅ、かつ、属性型ＤａｔａＴｙｐｅの定義ファイルの種類（ＬＯＣＡＬＦＩＬＥ＝０）を含む。Ｄｅｆｉｎｉｔｉｏｎは、例えば、属性名ｆｏｒｍａｔ、かつ、属性型ＦｉｌｅＦｏｒｍａｔの定義ファイルの形式を含む。Ｄｅｆｉｎｉｔｉｏｎは、例えば、属性名ｌｏｃａｔｉｏｎ、かつ、属性型ｓｔｒｉｎｇの定義ファイルの場所（ファイルパス）を含む。

Ｄａｔａは、例えば、属性名ｔｙｐｅ、かつ、属性型ＤａｔａＴｙｐｅのデータの種類（ＬＯＣＡＬＦＩＬＥ＝０）を含む。Ｄａｔａは、例えば、属性名ｆｏｒｍａｔ、かつ、属性型ＦｉｌｅＦｏｒｍａｔのデータのファイル形式を含む。Ｄａｔａは、例えば、属性名ｎａｍｅ、かつ、属性型ｓｔｒｉｎｇのデータの名前（Ｐｅｎｔａｈｏでは、例えば、入出力部品名をベースとする名前）を含む。Ｄａｔａは、例えば、属性名ｌｏｃａｔｉｏｎ、かつ、属性型ｓｔｒｉｎｇのデータの場所（ファイルパス）を含む。

ＤａｔａＬｉｓｔは、例えば、属性名ｌｉｓｔ、かつ、属性型ｒｅｐｅａｔｅｄＤａｔａのデータのリストを含む。Ｃｏｎｆｉｇｕｒａｔｉｏｎは、例えば、属性名ｔｙｐｅ、かつ、属性型ＤａｔａＴｙｐｅの設定ファイルの種類（ＬＯＣＡＬＦＩＬＥ＝０）を含む。Ｃｏｎｆｉｇｕｒａｔｉｏｎは、例えば、属性名ｆｏｒｍａｔ、かつ、属性型ＦｉｌｅＦｏｒｍａｔの設定ファイルの形式を含む。Ｃｏｎｆｉｇｕｒａｔｉｏｎは、例えば、属性名ｌｏｃａｔｉｏｎ、かつ、属性型ｓｔｒｉｎｇの設定ファイルの場所（ファイルパス）を含む。

Ｅｘｅｃｕｔｉｏｎは、例えば、属性名ｉｄ、かつ、属性型ｓｔｒｉｎｇの実行ＩＤを含む。ＥｘｅｃｕｔｉｏｎＲｅｓｕｌｔは、属性名ｒｅｓｕｌｔ、かつ、属性型ｓｔｒｉｎｇの実行結果を含む。プロキシは、共通Ｉ／Ｆをコンテナ内から、コンテナ外に提供するデーモンである。プロキシは、例えば、ＨＴＴＰまたはｇＲＰＣサーバとして動作する。ここで、プロキシを実現するためにプロキシ定義が用意される。プロキシ定義は、共通Ｉ／Ｆの各機能の動作手続を定めるデータである。

（プロキシ定義の一例）
次に、図１２〜図１６を用いて、プロキシ定義の一例について説明する。

図１２〜図１６は、プロキシ定義の一例を示す説明図である。図１２において、テキスト１２００は、プロキシ定義を示す。プロキシ定義は、少なくとも、共通Ｉ／Ｆの各機能の動作手続が記述される。プロキシ定義は、さらに、サブルーチンとなる機能の動作手続が記述されてもよい。

テキスト１２００のｖａｒｉａｂｌｅｓは、共通Ｉ／Ｆの各機能で用いられる変数を示す。テキスト１２００のｆｕｎｃｔｉｏｎｓは、共通Ｉ／Ｆの各機能の動作手続を示す。プロキシ定義は、ＡＰＩアクセスなどの詳細な実装を、ユーザが意識せずとも作成可能な形式である。形式は、例えば、ｙａｍｌ形式である。次に、図１３の説明に移行する。

図１３において、表１３００は、共通Ｉ／Ｆの機能、および、サブルーチンとなる機能などが有する属性を示す。属性は、例えば、ａｒｇ、ｔａｓｋｓ、ｒｅｔｕｒｎなどである。ａｒｇは、例えば、引数を格納する新規変数名である。ｔａｓｋｓは、例えば、機能が呼び出された際に実行されるタスクのシーケンスである。ｒｅｔｕｒｎは、例えば、戻り値として参照する変数名である。

変数は、グローバル変数とローカル変数との２種類が存在する。グローバル変数は、例えば、すべての機能で扱うことが可能な変数である。ローカル変数は、例えば、いずれかの機能の中でのみ扱うことが可能な変数である。ツールコンテナに指定された環境変数は、グローバル変数として参照可能な変数である。次に、図１４の説明に移行する。

図１４において、テキスト１４００は、変数を参照する記述の一例を示す。変数を参照する記述は、例えば、オブジェクト型変数のメンバ参照、または、配列変数の要素参照などが用いられる。テキスト１４００に示すように、オブジェクト型変数のメンバ参照は、例えば、ｆｉｌｅ．ｔｙｐｅである。テキスト１４００に示すように、配列変数の要素参照は、例えば、ｆｉｌｅｓ［０］である。タスクの引数に、変数の値を指定する場合、変数参照が記述される。次に、図１５の説明に移行する。

図１５において、テキスト１５００は、初期値を宣言する記述の一例を示す。テキスト１５００に示すように、グローバル変数は、例えば、ｖａｒｉａｂｌｅｓの下位に、初期値と共に宣言される。オブジェクト型変数は、例えば、属性の初期値を記述可能である。初期値は、他の変数であってもよい。次に、図１６の説明に移行する。

図１６において、テキスト１６００は、一連のタスクを機能内で実行する順序で記述した一例を示す。一連のタスクは、例えば、テキスト１２００のｔａｓｋｓの下位に記述される。タスクは、ツールの中で、ある定義ファイルを実行する実体である。

テキスト１６００に示すように、タスクの引数と同列の箇所に、ｒｅｇｉｓｔｅｒ属性、および、新たなローカル変数名を指定することにより、タスクの戻り値は、指定されたローカル変数名が付与されたローカル変数に代入可能である。

テキスト１６００であれば、ファイルを読み込むタスクｒｅａｄ＿ｆｉｌｅの戻り値であるファイルの中身が、新たなローカル変数ｃｏｎｔｅｎｔに代入されることになる。ローカル変数ｃｏｎｔｅｎｔは、以降に実行されるタスクにおいて利用可能である。

タスクは、例えば、ＵＩ操作（ページジャンプ、キーボード操作またはマウス操作など）である。ＵＩ操作は、例えば、ヘッドレスブラウザを用いる。ＵＩ操作は、具体的には、ＵＩ画面を開き、ＵＩ画面内の所定の位置に対してエンターキーを押下するなどの操作である。

タスクは、例えば、ＷｅｂＡＰＩの呼び出しである。ＷｅｂＡＰＩの呼び出しは、例えば、ＨＴＴＰクライアントを用いる。タスクは、例えば、ＣＬＩの呼び出しである。ＣＬＩの呼び出しは、例えば、Ｃｈｉｌｄ ｐｒｏｃｅｓｓなどによりコマンドを実行するライブラリを用いる。

タスクは、例えば、スクリプトの実行である。タスクは、例えば、ファイル操作である。タスクは、例えば、サブルーチンの呼び出しである。タスクは、例えば、変数の値の更新またはチェックである。一連のタスクは、ツールで入力データの一覧を取得するなどの動作を実現する。一連のタスクは、例えば、ツールで開いている定義ファイルを読み込み、定義ファイルにおける入力データに相当する箇所を取得するなどの動作を実現する。

（データフロー定義を作成する一例）
次に、図１７を用いて、情報処理装置１００が、データフロー定義を作成する一例について説明する。

図１７は、データフロー定義を作成する一例を示す説明図である。図１７において、情報処理装置１００は、エディタ画面１７００を、ディスプレイに表示する。エディタ画面１７００は、データを示すオブジェクト、タスクを示すオブジェクトなどを配置可能な領域１７０１を含む。エディタ画面１７００は、Ｒｕｎボタン１７０２を含む。

情報処理装置１００は、ユーザの操作入力に基づき、領域１７０１上で、オブジェクト間を結線する。結線したオブジェクト同士に、所定の依存関係が設定される。例えば、データを示すオブジェクトから、タスクを示すオブジェクトへと結線された場合、データが、タスクに入力されるという依存関係が設定される。

これにより、情報処理装置１００は、直感的に、データとタスクとの依存関係を示すデータフロー定義を作成することができる。情報処理装置１００は、例えば、それぞれのＵＩを開いたり、それぞれのデータ、または、それぞれのタスクに定義された属性およびパラメータなどの要素を変更したりする、一連のタスクを規定したデータフロー定義を作成することができる。

その後、情報処理装置１００は、データフロー定義に従って、レシピに基づいてコンテナインスタンスを起動し、コンテナインスタンスに基づいて、タスクを実行することができる。このため、情報処理装置１００は、複数のツールを組み合わせて利用し易くすることができ、ユーザにかかる作業負担の低減化を図ることができる。

（レシピ定義作成処理手順）
次に、図１８を用いて、情報処理装置１００が実行する、レシピ定義作成処理手順の一例について説明する。レシピ定義作成処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。

図１８は、レシピ定義作成処理手順の一例を示すフローチャートである。図１８において、情報処理装置１００は、ユーザの操作入力に従って、メタデータをレシピ定義に書き込む（ステップＳ１８０１）。メタデータは、例えば、レシピ名、バージョン、および、説明などである。

次に、情報処理装置１００は、ユーザの操作入力に従って、ツールで読み書きされる定義ファイルのファイルパスをレシピ定義に書き込む（ステップＳ１８０２）。ここで、情報処理装置１００は、ファイルパスが未定の場合は、ファイルパスを空文字列としてレシピ定義に書き込む。

次に、情報処理装置１００は、ユーザの操作入力に従って、コンテナイメージのメタデータを取得する（ステップＳ１８０３）。情報処理装置１００は、例えば、イメージレジストリに記憶された、ツールに対応するコンテナイメージに付与されたコンテナイメージ名、または、イメージタグに基づいて、コンテナイメージのメタデータを取得する。

次に、情報処理装置１００は、ユーザの操作入力に従って、コンテナイメージのメタデータに基づいて、コンテナイメージが公開するポート番号を取得し、ポート番号に対応するタスクノードのポートをレシピ定義に書き込む（ステップＳ１８０４）。

次に、情報処理装置１００は、ユーザの操作入力に従って、コンテナイメージに付与されたコンテナイメージ名およびイメージタグをレシピ定義に書き込む（ステップＳ１８０５）。そして、情報処理装置１００は、ユーザの操作入力に従って、コンテナイメージのメタデータに基づいて、コンテナ起動時の実行コマンドを特定し、レシピ定義に書き込む（ステップＳ１８０６）。

次に、情報処理装置１００は、ユーザの操作入力に従って、コンテナイメージの変更差分を取得し、レシピ定義に書き込む（ステップＳ１８０７）。ここで、情報処理装置１００は、例えば、定義ファイルを配置するコンテナ側のフォルダの所有権およびアクセス権を、データ利活用基盤と合わせるため、または、ツールの禁止操作を実現するための、コンテナイメージの変更差分を取得する。

次に、情報処理装置１００は、ユーザの操作入力に従って、プロキシ定義のファイル名をレシピ定義に書き込む（ステップＳ１８０８）。ここで、プロキシ定義のファイル名は、例えば、レシピ定義からの相対パスである。そして、情報処理装置１００は、レシピ定義作成処理を終了する。これにより、情報処理装置１００は、レシピ定義を作成することができる。

（プロキシ定義作成処理手順）
次に、図１９を用いて、情報処理装置１００が実行する、プロキシ定義作成処理手順の一例について説明する。プロキシ定義作成処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。

図１９は、プロキシ定義作成処理手順の一例を示すフローチャートである。図１９において、情報処理装置１００は、プロキシの提供する機能のうち、まだ処理していないいずれかの機能を選択する（ステップＳ１９０１）。プロキシの提供する機能は、例えば、共通Ｉ／Ｆの機能である。

次に、情報処理装置１００は、ＵＩ操作について、プロキシ定義に記録する（ステップＳ１９０２）。情報処理装置１００は、例えば、実際にＷｅｂブラウザで画面サイズを固定し、ユーザの操作入力に従って、マウスカーソルの座標、ボタン操作、キーボード操作、待ち時間、ページ遷移などを記録し、プロキシ定義に書き込む。

次に、情報処理装置１００は、ＡＰＩ操作について、プロキシ定義に記録する（ステップＳ１９０３）。情報処理装置１００は、例えば、ユーザの操作入力に従って、実際にＨＴＴＰクライアントにより、リクエストを送信することにより、所望の機能を実現するリクエストパラメータを特定し、プロキシ定義に書き込む。

次に、情報処理装置１００は、ＣＬＩ操作について、プロキシ定義に記録する（ステップＳ１９０４）。情報処理装置１００は、例えば、ユーザの操作入力に従って、実際にターミナルでコマンドを実行することにより、所望の機能を実現するコマンドライン引数を特定し、プロキシ定義に書き込む。

次に、情報処理装置１００は、スクリプト実行操作について、プロキシ定義に記録する（ステップＳ１９０５）。情報処理装置１００は、例えば、ユーザの操作入力に従って、所望の機能を実現するスクリプトを開発し、ファイル名および実行コマンドを特定し、プロキシ定義に書き込む。

次に、情報処理装置１００は、ファイル操作について、プロキシ定義に記録する（ステップＳ１９０６）。情報処理装置１００は、例えば、ユーザの操作入力に従って、読み取り対象のファイル名、または、書き込み対象のファイル名などを特定し、プロキシ定義に書き込む。情報処理装置１００は、例えば、ユーザの操作入力に従って、参照元の変数、または、格納先の変数などを特定し、プロキシ定義に書き込む。

次に、情報処理装置１００は、ユーザの操作入力に従って、操作中に使用する変数およびサブルーチンを、プロキシ定義中に宣言する（ステップＳ１９０７）。そして、情報処理装置１００は、プロキシの提供する機能のすべてを選択したか否かを判定する（ステップＳ１９０８）。

ここで、未選択の機能がある場合（ステップＳ１９０８：Ｎｏ）、情報処理装置１００は、ステップＳ１９０１の処理に戻る。一方で、機能のすべてを選択している場合（ステップＳ１９０８：Ｙｅｓ）、情報処理装置１００は、プロキシ定義作成処理を終了する。

（ビルド処理手順）
次に、図２０を用いて、情報処理装置１００が実行する、ビルド処理手順の一例について説明する。ビルド処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。

図２０は、ビルド処理手順の一例を示すフローチャートである。図２０において、情報処理装置１００は、レシピ定義を参照し、レシピの元となる、いずれかのツールのコンテナイメージをイメージレジストリから取得し、レシピに設定する（ステップＳ２００１）。

次に、情報処理装置１００は、レシピ定義を参照し、プロキシ定義を読み込み、プロキシバイナリとプロキシ定義とを、所定のフォルダに格納した上で、レシピに追加する（ステップＳ２００２）。所定のフォルダは、例えば、／ｐｒｏｘｙである。

次に、情報処理装置１００は、レシピ定義のポート情報（ｐｏｒｔｓ）に合わせて、レシピに公開ポートを追加する（ステップＳ２００３）。そして、情報処理装置１００は、レシピ定義のｉｍａｇｅを参照し、レシピに変更差分を追加する（ステップＳ２００４）。

次に、情報処理装置１００は、追加後のレシピに基づいて、コンテナインスタンスを作成する（ステップＳ２００５）。そして、情報処理装置１００は、コンテナインスタンスの起動確認用のポートおよびパスを、起動完了するまで監視する（ステップＳ２００６）。

次に、情報処理装置１００は、起動完了した後、起動完了したコンテナインスタンスをイメージ化し、ツールのレシピとして、イメージレジストリにｐｕｓｈする（ステップＳ２００７）。そして、情報処理装置１００は、ビルド処理を終了する。ビルド処理は、例えば、図６に示したレシピビルド機能６１２に対応する。

これにより、情報処理装置１００は、ツールに関する初期化処理を予め実施しておき、以降に、再びコンテナインスタンスを起動する際にかかる所要時間の低減化を図ることができる。

（連携処理手順）
次に、図２１を用いて、情報処理装置１００が実行する、連携処理手順の一例について説明する。連携処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。

図２１は、連携処理手順の一例を示すフローチャートである。図２１において、情報処理装置１００は、データフローエディタ、または、データフローエンジンから、あるツールの共通Ｉ／Ｆのいずれかの機能を指定するリクエストを受け付ける（ステップＳ２１０１）。

次に、情報処理装置１００は、当該ツールのレシピに基づいて、コンテナインスタンスを作成する（ステップＳ２１０２）。そして、情報処理装置１００は、コンテナインスタンスのプロキシにアクセス可能になるまで待機する（ステップＳ２１０３）。

次に、情報処理装置１００は、アクセス可能になったプロキシに、指定の機能をリクエストする（ステップＳ２１０４）。そして、情報処理装置１００は、プロキシからレスポンスを受信するまで待機する（ステップＳ２１０５）。

次に、情報処理装置１００は、受信したレスポンスを、データフローエディタ、または、データフローエンジンに送信し、コンテナインスタンスを削除する（ステップＳ２１０６）。そして、情報処理装置１００は、連携処理を終了する。これにより、情報処理装置１００は、処理リソースを節約することができる。

ここで、情報処理装置１００は、図１８〜図２１の各フローチャートの一部ステップの処理の順序を入れ替えて実行してもよい。例えば、ステップＳ１８０１〜Ｓ１８０８の処理の順序は入れ替え可能である。また、情報処理装置１００は、図１８〜図２１の各フローチャートの一部ステップの処理を省略してもよい。例えば、ステップＳ１８０１〜Ｓ１８０８のいずれかの処理は省略可能である。

以上説明したように、情報処理装置１００によれば、それぞれのアプリに対応し、当該アプリ個別の形式である個別Ｉ／Ｆと、複数のアプリ共通の形式である共通Ｉ／Ｆとを接続するプロキシを生成可能にする第１の定義情報を取得することができる。情報処理装置１００によれば、それぞれのアプリに対応し、当該アプリと、当該アプリに対応するプロキシとが実行される仮想環境を生成可能にする第２の定義情報を取得することができる。情報処理装置１００によれば、取得した第１の定義情報と、取得した第２の定義情報とに基づいて、それぞれのアプリに対応する仮想環境を生成すると共に、当該仮想環境で実行されるプロキシを生成することができる。これにより、情報処理装置１００は、プロキシにより、個別Ｉ／Ｆと共通Ｉ／Ｆとを連携することができ、複数のアプリを組み合わせて利用し易くすることができる。

情報処理装置１００によれば、それぞれのアプリに対応する仮想環境に、当該アプリと、当該アプリに対応するプロキシとが実行されるコンテナを利用することができる。これにより、情報処理装置１００は、プロキシとアプリとを、コンテナにおいて纏めて実行することができる。このため、情報処理装置１００は、プロキシを、アプリにダイレクトにアクセス可能な場所で実行することができる。

情報処理装置１００によれば、データと複数のアプリの少なくともいずれかのアプリを利用するタスクとの依存関係を示すデータフローを取得することができる。情報処理装置１００によれば、取得した第１の定義情報と、取得した第２の定義情報とに基づいて、それぞれのアプリに対応する仮想環境と共に、当該仮想環境で実行されるプロキシを実体として纏めて生成可能にするイメージデータを生成することができる。情報処理装置１００によれば、データフローと、イメージデータとに基づいて、タスクが、複数のアプリのいずれかのアプリを利用開始する際に、いずれかのアプリに対応する仮想環境を生成すると共に、当該仮想環境で実行されるプロキシを生成することができる。これにより、情報処理装置１００は、アプリを利用開始するまで、仮想環境を生成せず、かつ、プロキシを生成せずに済ませることができ、処理リソースを節約することができる。

情報処理装置１００によれば、タスクが、複数のアプリのいずれかのアプリを利用終了する際に、いずれかのアプリに対応する仮想環境を削除すると共に、当該仮想環境で実行されるプロキシを削除することができる。これにより、情報処理装置１００は、アプリを利用終了した後、処理リソースを節約することができる。

情報処理装置１００によれば、第２の定義情報を、ユーザの操作入力に基づいて生成することができる。これにより、情報処理装置１００は、ユーザが所望の仮想環境を生成可能にすることができる。

情報処理装置１００によれば、個別Ｉ／Ｆとして、ＵＩ、ＡＰＩ、または、ＣＬＩを有する、複数のアプリに対して適用することができる。これにより、情報処理装置１００は、個別Ｉ／Ｆとして、ＵＩ、ＡＰＩ、または、ＣＬＩを有する、複数のアプリを組み合わせて利用し易くすることができる。

なお、本実施の形態で説明した情報処理方法は、予め用意されたプログラムをＰＣやワークステーションなどのコンピュータで実行することにより実現することができる。本実施の形態で説明した情報処理プログラムは、コンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。記録媒体は、ハードディスク、フレキシブルディスク、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ Ｏｐｔｉｃａｌ ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などである。また、本実施の形態で説明した情報処理プログラムは、インターネットなどのネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）複数のアプリのそれぞれのアプリに対応し、当該アプリ個別の形式である個別インターフェースと、前記複数のアプリ共通の形式である共通インターフェースとを接続するプロキシを生成可能にする第１の定義情報を取得し、
前記それぞれのアプリに対応し、当該アプリと、当該アプリに対応する前記プロキシとが実行される仮想環境を生成可能にする第２の定義情報を取得し、
取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。

（付記２）前記それぞれのアプリに対応する前記仮想環境は、当該アプリと、当該アプリに対応する前記プロキシとが実行されるコンテナである、ことを特徴とする付記１に記載の情報処理プログラム。

（付記３）データと前記複数のアプリの少なくともいずれかのアプリを利用するタスクとの依存関係を示すデータフローを取得し、
取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境と共に、当該仮想環境で実行される前記プロキシを実体として纏めて生成可能にするイメージデータを生成する、
処理を前記コンピュータに実行させ、
前記生成する処理は、
取得した前記データフローと、生成した前記イメージデータとに基づいて、前記タスクが、前記複数のアプリのいずれかのアプリを利用開始する際に、前記いずれかのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する、ことを特徴とする付記１または２に記載の情報処理プログラム。

（付記４）前記タスクが、前記複数のアプリのいずれかのアプリを利用終了する際に、前記いずれかのアプリに対応する前記仮想環境を削除すると共に、当該仮想環境で実行される前記プロキシを削除する、
処理を前記コンピュータに実行させることを特徴とする付記３に記載の情報処理プログラム。

（付記５）前記第２の定義情報は、ユーザの操作入力に基づいて生成される、ことを特徴とする付記１〜４のいずれか一つに記載の情報処理プログラム。

（付記６）前記個別インターフェースは、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）、または、ＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）である、ことを特徴とする付記１〜５のいずれか一つに記載の情報処理プログラム。

（付記７）複数のアプリのそれぞれのアプリに対応し、当該アプリ個別の形式である個別インターフェースと、前記複数のアプリ共通の形式である共通インターフェースとを接続するプロキシを生成可能にする第１の定義情報を取得し、
前記それぞれのアプリに対応し、当該アプリと、当該アプリに対応する前記プロキシとが実行される仮想環境を生成可能にする第２の定義情報を取得し、
取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する、
処理をコンピュータが実行することを特徴とする情報処理方法。

（付記８）複数のアプリのそれぞれのアプリに対応し、当該アプリ個別の形式である個別インターフェースと、前記複数のアプリ共通の形式である共通インターフェースとを接続するプロキシを生成可能にする第１の定義情報を取得し、
前記それぞれのアプリに対応し、当該アプリと、当該アプリに対応する前記プロキシとが実行される仮想環境を生成可能にする第２の定義情報を取得し、
取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する、
制御部を有することを特徴とする情報処理装置。

１００ 情報処理装置
１０１ アプリ
１０２ 個別Ｉ／Ｆ
１０３，５１１，５１２ プロキシ
１０４，６３５，６４５ 共通Ｉ／Ｆ
１１０，１２０ 定義情報
２００ 情報処理システム
２０１ 端末装置
２０２ クライアント装置
２１０ ネットワーク
３００ バス
３０１ ＣＰＵ
３０２ メモリ
３０３ ネットワークＩ／Ｆ
３０４ 記録媒体Ｉ／Ｆ
３０５ 記録媒体
４００ 記憶部
４０１ 取得部
４０２ 生成部
４０３ 実行部
４０４ 出力部
５０１ フローエディタ
５０２ フローエンジン
６０１ レシピ定義
６０２，６３２，６４２ プロキシ定義
６１１，６３３，６４３ プロキシバイナリ
６１２ レシピビルド機能
６２１ イメージレジストリ
６２２ 開発データ集合
６３０，６４０ コンテナ
６３１ ツールＡ
６３４，６４４ ファイルシステム
６４１ ツールＢ
６５１ データフローエディタ
６５２ データフローエンジン
６５３ データフロー定義
６６１ ツール連携機能
７００，１３００ 表
８００，９００，１２００，１４００，１５００，１６００ テキスト
１７００ エディタ画面
１７０１ 領域
１７０２ Ｒｕｎボタン

Claims (6)

1. 複数のアプリのそれぞれのアプリに対応し、当該アプリ個別の形式である個別インターフェースと、前記複数のアプリ共通の形式である共通インターフェースとを接続するプロキシを生成可能にする第１の定義情報を取得し、
   前記それぞれのアプリに対応し、当該アプリと、当該アプリに対応する前記プロキシとが実行される仮想環境を生成可能にする第２の定義情報を取得し、
   取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する、
   処理をコンピュータに実行させることを特徴とする情報処理プログラム。
2. 前記それぞれのアプリに対応する前記仮想環境は、当該アプリと、当該アプリに対応する前記プロキシとが実行されるコンテナである、ことを特徴とする請求項１に記載の情報処理プログラム。
3. データと前記複数のアプリの少なくともいずれかのアプリを利用するタスクとの依存関係を示すデータフローを取得し、
   取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境と共に、当該仮想環境で実行される前記プロキシを実体として纏めて生成可能にするイメージデータを生成する、
   処理を前記コンピュータに実行させ、
   前記生成する処理は、
   取得した前記データフローと、生成した前記イメージデータとに基づいて、前記タスクが、前記複数のアプリのいずれかのアプリを利用開始する際に、前記いずれかのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する、ことを特徴とする請求項１または２に記載の情報処理プログラム。
4. 前記タスクが、前記複数のアプリのいずれかのアプリを利用終了する際に、前記いずれかのアプリに対応する前記仮想環境を削除すると共に、当該仮想環境で実行される前記プロキシを削除する、
   処理を前記コンピュータに実行させることを特徴とする請求項３に記載の情報処理プログラム。
5. 複数のアプリのそれぞれのアプリに対応し、当該アプリ個別の形式である個別インターフェースと、前記複数のアプリ共通の形式である共通インターフェースとを接続するプロキシを生成可能にする第１の定義情報を取得し、
   前記それぞれのアプリに対応し、当該アプリと、当該アプリに対応する前記プロキシとが実行される仮想環境を生成可能にする第２の定義情報を取得し、
   取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する、
   処理をコンピュータが実行することを特徴とする情報処理方法。
6. 複数のアプリのそれぞれのアプリに対応し、当該アプリ個別の形式である個別インターフェースと、前記複数のアプリ共通の形式である共通インターフェースとを接続するプロキシを生成可能にする第１の定義情報を取得し、
   前記それぞれのアプリに対応し、当該アプリと、当該アプリに対応する前記プロキシとが実行される仮想環境を生成可能にする第２の定義情報を取得し、
   取得した前記第１の定義情報と、取得した前記第２の定義情報とに基づいて、前記それぞれのアプリに対応する前記仮想環境を生成すると共に、当該仮想環境で実行される前記プロキシを生成する、
   制御部を有することを特徴とする情報処理装置。

Images