WO2021192318A1

WO2021192318A1 - 検証装置、検証システム、検証方法及びコンピュータ可読媒体

Info

Publication number: WO2021192318A1
Application number: PCT/JP2020/014410
Authority: WO
Inventors: 淳西岡; 純明榮; 和彦磯山; 佑嗣小林
Original assignee: 日本電気株式会社
Priority date: 2020-03-27
Filing date: 2020-03-27
Publication date: 2021-09-30
Also published as: US20230101077A1; JPWO2021192318A1; JP7343041B2

Abstract

開発者側の負荷を抑え、安全にパッケージを検証できる検証装置を提供することを目的とする。本開示にかかる検証装置（１００）は、ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、端末装置から送信された配布パッケージのインストール要求を受信する受信手段（１）と、受信したインストール要求が要求する配布パッケージを配布サーバから取得する取得手段（２）と、受信したインストール要求に基づいて、端末装置の開発環境に応じた検証環境を構築する構築手段（３）と、構築した検証環境を用いて、取得した配布パッケージのインストール検証を実行する検証手段（４）と、インストール検証の検証結果に基づいて、取得した配布パッケージを端末装置へ送信する送信手段（５）と、を備える。

Description

検証装置、検証システム、検証方法及びコンピュータ可読媒体

　本開示は、検証装置、検証システム、検証方法及びプログラムに関する。

　近年、システム開発において、開発者がＷｅｂ上に公開されたＯＳＳ（Open Source Software）を利用して開発を行うことが一般的になっている。例えば、Python、Node.jsなどのスクリプト系言語では、Ｗｅｂ上にＯＳＳとして多くのパッケージが公開されている。開発者は、必要に応じてこれらのパッケージをインストールし、開発のために利用する。
　しかし、ＯＳＳの中には、開発者のコンピュータにとって有害な動作を行うプログラムが含まれるものが存在する。中には、パッケージ名を有名なものに似せ、開発者がタイプミスにより誤ってインストールすることを狙ったものや、他の正常なパッケージまで汚染するなどの悪質なものがある。

　そこで、これらのＯＳＳが安全なものか否かを検証する技術が知られている。例えば、特許文献１には、サンドボックスの中でデータ値の変更が与える影響を確認するシステムが開示されている。特許文献１において開示されたシステムでは、シナリオ管理を行うために、案件ごとにサンドボックスを作成し、その中で動作検証を行う必要がある。
　また、特許文献２には、ＣＤＳへのＤｏＳ対策として、悪意のあるメッセージを検出し、当該メッセージに対する対策をセキュリティコンポーネントに対して命令する装置が開示されている。
　他には、メールサーバ上でメールを監視し、有害なメールを検出する検出するシステムも知られている。

特表２０１８－５３３０９０号公報特表２００５－５３５０２１号公報

　公開されたパッケージの動作検証を開発者自身が行う場合、開発者はインストールの都度、自身の開発環境で検証プログラムを実行しなければならない。開発者はインストールのタイミングで検証を行うため、マシンに高い負荷がかかり、開発者の利便性が損なわれる。上記のようなパッケージを使用することが開発者にとって通常であることも考慮すると、開発者に検証作業を委ねた場合に、その実行を徹底することは困難である。
　特許文献１又は２に開示の技術では、上記の問題について考慮されていない。

　本発明はこのような課題を解決するためになされたものであり、開発者側の負荷を抑え、安全にパッケージを検証できる検証装置、検証システム、検証方法及びプログラムを提供することを目的とする。

　本開示にかかる検証装置は、ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信する受信手段と、前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得する取得手段と、前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築する構築手段と、前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行する検証手段と、前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する送信手段と、を備えるものである。

　本開示にかかる検証システムは、ソフトウェア開発用の配布パッケージを配布する配布サーバと、前記配布パッケージをインストールする端末装置と、検証装置とを備え、前記検証装置は、前記配布サーバと前記端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信する受信手段と、前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得する取得手段と、前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築する構築手段と、前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行する検証手段と、前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する送信手段と、を備えるものである。

　本開示にかかる検証方法は、ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信し、前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得し、前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築し、前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行し、前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信するものである。

　本開示にかかるプログラムは、ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信し、前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得し、前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築し、前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行し、前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する、検証方法をコンピュータに実行させるものである。

　本開示により、開発者側の負荷を抑え、安全にパッケージを検証できる検証装置、検証システム、検証方法及びプログラムを提供することができる。

本発明にかかる検証装置の構成を示すブロック図である。本発明にかかる検証システムの構成を示すブロック図である。本発明にかかる検証システムの説明図である。本発明にかかる検証システムの説明図である。本発明にかかる検証システムにおけるユーザリストの一例である。本発明にかかる検証システムにおけるユーザリストの一例である。本発明にかかる検証システムにおけるユーザリストの一例である。本発明にかかる検証システムの説明図である。本発明にかかる検証システムの説明図である。本発明にかかる検証システムにおける結果リストの一例である。本発明にかかる検証システムにおける環境リストの一例である。本発明にかかる検証システムにおけるエラーメッセージ用のスクリプトの一例である。本発明にかかる検証システムにおける表示画面の一例である。本発明にかかる検証システムにおける表示画面の一例である。本発明にかかる検証システムにおける表示画面の一例である。本発明にかかる検証システムの処理を示すフローチャートである。本発明にかかる検証システムの処理を示すフローチャートである。本発明にかかる検証システムの処理を示すフローチャートである。本発明にかかる検証システムの処理を示すフローチャートである。本発明にかかる検証システムにおける結果リストの一例である。本発明にかかる検証システムにおける検証結果等のツリーを示す図である。本発明にかかる検証システムにおける検証結果等のツリーを示す図である。本発明にかかる検証システムにおける検証結果等のツリーを示す図である。本発明にかかる検証システムにおける検証結果等のツリーを示す図である。本発明にかかる検証システムにおける検証結果等のツリーを示す図である。本発明にかかる検証システムにおける検証結果等のツリーを示す図である。本発明にかかる検証システムにおける検証結果等のツリーを示す図である。本発明にかかる検証システムにおける検証結果等のツリーを示す図である。本発明にかかる検証システムのハードウェア構成例を示す図である。

　背景技術において説明した問題について、以下のような問題もある。
　初めに述べたように、現在では多くのパッケージがＯＳＳとしてＷｅｂ上に公開されている。これらのパッケージは日々更新されており、パッケージのバージョンやプラットフォームの違い及びパッケージの依存関係まで考慮すると、その数は膨大である。そのため、開発者がインストールしようとするパッケージの検証結果を全てリスト化し、検証結果と共に管理することは煩雑である。

　また、パッケージの不正な動作が開発環境に依存する場合には、全ての開発者に対し、一律で検証を行うことは困難である。
　したがって、開発環境が日々更新される中で、上記のような問題を解決し、タイムリーな検証が可能な仕組みを構築することが必要である。

＜実施の形態１＞
　以下、図１を参照して本発明の実施の形態にかかる検証装置１００を説明する。
　検証装置１００は、受信部１、取得部２、構築部３、検証部４、送信部５を備える。
　受信部１は、ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、端末装置から送信された前記配布パッケージのインストール要求を受信する。
　取得部２は、受信したインストール要求が要求する配布パッケージを配布サーバから取得する。
　構築部３は、受信したインストール要求に基づいて、端末装置の開発環境に応じた検証環境を構築する。
　検証部４は、構築した検証環境を用いて、取得した配布パッケージのインストール検証を実行する。
　送信部５は、インストール検証の検証結果に基づいて、取得した配布パッケージを端末装置へ送信する。

　以上説明したように、本実施の形態１にかかる検証装置によれば、開発者側の負荷を抑え、安全にパッケージを検証することができる。

＜実施の形態２＞
　続いて、図２を用いて、本発明の実施の形態にかかる検証装置１０１を含む検証システム２００を説明する。以下の説明では、パッケージのインストール要求をするユーザを単にユーザといい、ユーザが要求したパッケージを要求パッケージという。

　検証システム２００は、配布サーバ９１、ユーザ端末７１、検証装置１０１を備える。
　配布サーバ９１は、ソフトウェア開発用のパッケージを配布する。
　ユーザ端末７１は、開発者であるユーザが使用する端末である。
　検証装置１０１は、ネットワーク９０を介して、配布サーバ９１とユーザ端末７１との間で、パッケージのインストール要求の中継を行う。検証装置１０１は、配布サーバ９１のミラーサーバであり、例えば、プロキシサーバにより実現することができる。
　ネットワーク９０は、例えばインターネットである。

　ユーザ端末７１は、環境登録部７２、インストール実行部７３、表示部７４を備える。
　環境登録部７２は、ユーザ端末７１の環境情報をユーザリスト２１に登録する。
　インストール実行部７３は、パッケージのインストール要求を行い、パッケージ内のスクリプトをインストールして実行する。
　表示部７４は、エラーメッセージの表示等を行う。表示部７４は、例えばディスプレイである。

　検証装置１０１は、ユーザリスト記憶部２０、結果リスト記憶部１０、要求処理部３０、検証実行部４０、環境リスト記憶部５０、検証環境記憶部６１、パッケージ記憶部５６、パッケージ生成部５５を備える。

　システム開発において、ユーザは同時に複数のプロジェクトに参加して開発を行うことがある。本実施の形態においては、プロジェクトごとに検証装置１０１を設けることとする。
　例えば図３に示すように、ユーザＡが同一のマシンで３つのプロジェクトに参加しているとする。ユーザＡはプロジェクト別に検証装置１０１ａ、１０１ｂ及び１０１ｃにアクセスする。単独のプロジェクトに参加しているユーザＢは、検証装置１０１ｄのみにアクセスする。

　後述する処理によりそれぞれの検証装置１０１において得られた情報は、例えば図３に示すように、検証装置１０１に接続されるデータベース（ＤＢ）に集約して記憶することができる。これにより、検証装置１０１間で情報を活用し、効率的な動作検証を行うことができる。

　また、検証装置１０１はプロジェクトごとに設けられているため、図４に示すように、１つの検証装置１０１に対し、複数のユーザがアクセスしてもよい。本実施の形態では、ユーザをＩＤやＩＰアドレスにより識別し、ユーザごとに環境情報を記憶する。例えば、図４に示す例では、ユーザＡ、Ｂ、Ｃは同じプロジェクトに参加しているため、同じ検証装置１０１にアクセスするが、ユーザＩＤやＩＰアドレスにより、各ユーザの情報は識別される。また、後述する処理において、それぞれのユーザの開発環境に対応した検証環境６０が構築される。例えば、ユーザＡは検証環境６０Ａ、ユーザＢは検証環境６０Ｂ、ユーザＣは検証環境６０Ｃというように検証環境６０が構築される。

　ユーザリスト記憶部２０は、ユーザの環境情報を取得し、ユーザリスト２１として記憶する。ユーザリスト記憶部２０は、例えばユーザ名とユーザのＩＰアドレスと、ユーザの環境情報とを関連付けて記憶する。

　環境情報とは、ユーザの開発環境におけるパッケージのインストール状況を示す情報である。パッケージとは、システム開発で利用可能な複数のモジュールを組み合わせたものである。パッケージには、例えばnumpy、tensorflow、keras等がある。環境情報は、パッケージに限らず、スクリプトやライブラリに関するものでもよい。

　ユーザリスト２１の一例を図５から図７に示す。ユーザリスト２１に登録されるユーザの環境情報は、例えば図５に示すように、ユーザがインストールしているパッケージごとに記憶することができる。ユーザが複数のパッケージをインストールしている場合には、図６に示すように複数のパッケージをまとめて記憶してもよい。また、図７に示すように、それらに加えてＯＳ（Operating System）やシステムライブラリの情報まで含めてもよい。さらに、プロジェクトＩＤや、ＣＰＵ等のハードウェアの情報を含めてもよい。

　図５から図７に示した図は一例であり、ユーザリスト２１は、把握しようとする環境情報の粒度に応じて適宜設定することができる。また、上記の図には各パッケージのバージョンの情報が示されているが、把握する必要がなければ省略してもよい。なお、ユーザリスト２１にユーザのＩＰアドレスを含めることで、ユーザが複数のＩＰアドレスを用いて開発を行っている場合にも、それぞれ別のマシンとして扱うことができる。

　ユーザリスト記憶部２０がユーザの環境情報を取得する方法としては、例えば、ユーザが自身の環境情報を登録する方法や、仮想環境を提供した際の払い出し情報を記憶し、保持する方法がある。以下にその詳細を述べる。

　ユーザが自身の環境情報を登録する場合は、ユーザがＯＳや既にインストールされているパッケージの情報を環境登録部７２からユーザリスト記憶部２０に登録する。例えば、Linux（登録商標）であれば、/sbin/ldconfig －p 等の情報、Windows（登録商標）であれば、PATHで指定された情報、アプリケーションの一覧により表示される情報、AppData以下にあるdll情報等を登録する。Pythonの場合は、pydファイルなどを含めることができる。

　また、ユーザは、例えば、Python、Node.js、Rubyといったパッケージの情報のみを登録することもできる。ユーザは、パッケージの情報をpip freezeコマンド又はsite-packages以下から把握することができる。又は、OS/CPU Architectureレベルで区別する程度でもよい。

　初期の環境情報をユーザ自身が登録する場合に検証システム２００が行う処理を図８に示す。初めに、プロジェクト管理者により、ユーザリスト２１にプロジェクトが登録される（ステップＳ４１）。例えば、プロジェクト管理者は、プロジェクト管理用の端末（不図示）を用いてプロジェクトＩＤやプロジェクト名を登録する。登録されたプロジェクトに参加するユーザは、環境登録部７２より環境情報をアップロードし、ユーザ登録を行う（ステップＳ４３）。

　ユーザリスト記憶部２０は、必要な粒度に応じてユーザの環境情報を記憶する。ＩＰアドレスによる識別を行わない場合、ユーザリスト記憶部２０はユーザに対しユーザＩＤを返す（ステップＳ４５）。その後、ユーザは必要に応じてパッケージのインストールを要求する（ステップＳ４７）。ユーザＩＤが設定された場合、ユーザはユーザＩＤを含んだ形でパッケージのインストール要求を行う。例えば、ユーザＩＤとして１２３４が返されたとする。ＵＲＬにユーザＩＤが埋め込まれる場合、ユーザは、http://1234.mirror.net/reqのようにインストール要求を行う。ユーザＩＤがＵＲＬでなくパラメータで指定される場合、ユーザは、http://mirror.net/req?user=1234のようにインストール要求を行う。

　また、仮想機械によりユーザに初期環境を提供する場合には、ユーザリスト記憶部２０が払い出し情報を保持することでユーザの初期の環境情報を把握することができる。この場合に検証システム２００が行う処理を図９に示す。
　上記の例と同様、初めに、プロジェクト管理者によってユーザリスト２１にプロジェクトが登録される（ステップＳ５１）。プロジェクトに参加するユーザはユーザ登録を行う（ステップＳ５３）。検証装置１０１は、ユーザに対し開発環境の払い出しを行う（ステップＳ５５）。ユーザリスト記憶部２０は、このときの払い出し情報を必要な粒度に応じてユーザリスト２１に記憶する。その後、ユーザは必要に応じて、払い出された開発環境においてパッケージのインストール要求を行う（ステップＳ５７）。

　上述の処理によりユーザリスト２１に記憶されたユーザの環境情報は、ＯＳやシステムパッケージが更新されたタイミングにおいて、検証実行部４０により更新される。

　結果リスト記憶部１０は、ユーザの環境情報と、その開発環境においてインストールしたパッケージの動作の検証結果とを関連付け、結果リスト１１として記憶する。

　結果リスト１１の一例を図１０に示す。結果リスト１１には、例えば、ユーザ名、ＩＰアドレス、環境情報、検証対象のパッケージ、検証結果が関連付けて記憶される。

　要求処理部３０は、配布サーバ９１が配布するパッケージを取得し、パッケージ記憶部５６に記憶する。また、要求処理部３０は、ユーザからパッケージのインストール要求を受信する。要求処理部３０は、検証実行部４０によりユーザの要求パッケージのインストールが許可された場合、ユーザに対し要求パッケージを配信する。なお、要求処理部３０は、実施の形態１における受信部１、取得部２及び送信部５に対応する。

　検証実行部４０は、要求パッケージをユーザにインストールさせてよいか否かを判断する。具体的には、検証実行部４０は、ユーザの環境情報をユーザリスト２１から取得し、結果リスト１１の情報を確認する。検証実行部４０は、結果リスト１１においてユーザの環境情報における要求パッケージの動作が検証済みである場合、その検証結果に基づいて、ユーザに要求パッケージのインストールを許可するか否かを判断する。したがって、既に検証結果が存在する場合、検証実行部４０は新たな動作検証を行わない。なお、検証実行部４０は、実施の形態１における構築部３及び検証部４に対応する。検証実行部４０は、検証装置１０１の外部に備えられてもよい。

　検証実行部４０は、結果リスト１１においてユーザの環境情報における要求パッケージの動作が検証済みでない場合、新たに検証環境６０を構築する。検証実行部４０は、構築した環境上で、配布サーバ９１から取得した要求パッケージをインストールし、インストール検証ツールにより動作検証を行う。インストール検証ツールは、例えば、パッケージのインストール時の振る舞いを学習し、異常を検知するシステムである。

　検証実行部４０は、プロジェクト単位、ＰＣ単位それぞれにおける検証環境６０を用意することができる。検証実行部４０は、検証環境６０にパッケージがインストールされる度に、検証環境６０を更新する。

　検証実行部４０は、インストールを許可する場合には要求パッケージをユーザに渡し、許可しない場合にはパッケージ生成部５５により生成されたエラー表示用のパッケージをユーザに渡す。
　また、検証実行部４０は、所定のタイミングにより検証環境６０を破棄する。

　上記で述べたように、検証実行部４０は、要求パッケージについて既に検証結果が存在する場合、その検証結果を利用する。システム開発において、開発者であるユーザのタイプによって、インストールしようとするパッケージには傾向がある。例えばＷｅｂ開発の場合はflask、深層学習の場合はtensorflow、というように、開発分野によってユーザが求めるパッケージは共通する。したがって、例えばユーザＡがインストール要求をしたパッケージを、ユーザＡと同じタイプであるユーザＢもインストール要求することがある。このような場合、ユーザＡの検証結果を利用するため、ユーザＢについて検証を省略することができる。

　環境リスト記憶部５０は、構築された検証環境６０をリスト化し、環境リスト５１として記憶する。
　図１１に環境リスト５１の一例を示す。環境リスト５１には、例えば環境ＩＤ、ユーザ名、ユーザのＩＰアドレス、ユーザの環境情報が関連付けて記憶される。

　検証環境記憶部６１は、検証環境６０を記憶する。一例として、図２には６０（ａ）から６０（ｅ）の５つの検証環境６０を示している。それぞれの検証環境６０は、例えば、検証装置１０１において、それぞれが専用の物理コンピュータ環境を使用しているかのように同時に又は並行して動作することができる仮想機械（ＶＭ）である。検証環境６０は、例えばコンテナ型でもよいし、Ｗｅｂ上で他のユーザと共有可能な仮想環境でもよい。

　パッケージ記憶部５６は、配布サーバ９１から取得したパッケージを記憶する。
　パッケージ生成部５５は、要求パッケージの動作検証が異常である場合にユーザに配信するためのエラー表示用のパッケージを作成する。エラー表示用のパッケージには、例えば図１２に示すようなスクリプトを記述する。このスクリプトを実行することにより、表示部７４にエラーメッセージが表示される。表示部７４に表示される内容について、通常の表示内容と比較して下記に詳細を述べる。

　図１６から図１８に示すフローチャートを用いて、パッケージ生成部５５が行う処理を説明する。
　まず、図１６は、検証結果が正常であった場合に検証システム２００が行う処理の概要を示したフローチャートである。ユーザがパッケージを要求する（ステップＳ５０１）と、検証実行部４０は検証環境６０に要求パッケージをインストールし、（ステップＳ５０３）、動作検証を行う（ステップＳ５０５）。検証結果が正常であるので、要求処理部３０は要求パッケージをインストール実行部７３に送信する。インストール実行部７３は要求パッケージを受信し、展開する（ステップＳ５０７）。インストール実行部７３は、要求パッケージ内のスクリプトをインストールして実行する（ステップＳ５０９）。このとき表示部７４に、図１３に示すような内容が表示される。

　これに対して、図１７及び図１８は、検証結果が異常であった場合に検証システム２００が行う処理の概要を示したフローチャートである。図１７は検証結果に関する情報をユーザに通知しない場合、図１８はユーザに通知する場合の処理を示している。

　図１７における検証システム２００の処理について説明する。ユーザが要求処理部３０にパッケージを要求する（ステップＳ６０１）と、検証実行部４０は検証環境６０に要求パッケージをインストールし、（ステップＳ６０３）、動作検証を行う（ステップＳ６０５）。検証結果が異常であるので、検証実行部４０はユーザに対して要求パッケージのインストールを許可しない。タイムアウトエラーにより処理は終了し、ユーザは要求パッケージのインストールをすることができない（ステップＳ６０７）。このとき表示部７４に、図１４に示すように、タイムアウトを示す内容が表示される。

　次に、図１８における検証システム２００の処理について説明する。ユーザが要求処理部３０にパッケージを要求する（ステップＳ７０１）と、検証実行部４０は検証環境６０に要求パッケージをインストールし、（ステップＳ７０３）、動作検証を行う（ステップＳ７０５）。検証結果が異常であるので、検証実行部４０はユーザに対して要求パッケージのインストールを許可しない。

　パッケージ生成部５５は、要求パッケージの代わりに、エラー内容を表示する差替パッケージを作成する（ステップＳ７０７）。検証実行部４０は、差替パッケージをユーザ端末７１に送信する。インストール実行部７３は、差替パッケージを受信し、展開する（ステップＳ７０９）。インストール実行部７３は、差替パッケージ内のスクリプトをインストールして実行する（ステップＳ７１１）。このとき表示部７４に、図１５に示すようなエラーメッセージが表示される（ステップＳ７１３）。なお、ユーザの環境における要求パッケージの検証結果が既に結果リスト１１に存在する場合はステップＳ７０３、Ｓ７０５の処理は行われないが、ステップＳ７０７以降の処理は同様である。

　差替パッケージにより表示されるエラーメッセージには、例えば図１５の（ａ）に示すように、検証結果が異常であった旨と、異常についての詳細が確認できるＵＲＬが記載されている。これにより、ユーザは、要求パッケージのインストールが許可されなかったことと、許可されなかった原因を知ることができる。

　また、ユーザがインストールを要求したものと同名で異なるバージョンの要求パッケージがインストール可能である場合、図１５の（ｂ）に示すようにその旨をユーザに通知することができる。これにより、ユーザは要求パッケージそのもののインストールができなかった場合であっても、別のバージョンのパッケージをインストールすることにより必要な機能をインストールできる可能性がある。

　上記のように、インストール要求が許可されなかった場合に代わりのパッケージをユーザに配信し、通知することで、追加の構成を必要とすることなく、ユーザにとって有益なエラーメッセージを配信することができる。

　続いて、図１９に示すフローチャートを用いて、検証システム２００が実行する処理について説明する。

　初めに、ユーザはインストール実行部７３により、要求処理部３０に対してパッケージのインストールを要求する（ステップＳ１０１）。要求処理部３０は、ユーザのインストール要求を受信する（ステップＳ１０３）。

　検証実行部４０は、ユーザの環境情報をユーザＩＤやＩＰアドレスを基にユーザリスト２１から取得する（ステップＳ１０５）。ユーザの環境情報がユーザリスト２１に登録されていない場合、検証実行部４０は他のユーザと共通のベース環境をユーザの環境情報として割り当てる。

　検証実行部４０は、ユーザの環境において要求パッケージの検証が済んでいるか否かを結果リスト１１により確認する（ステップＳ１０７）。例えば、図１０に示した例のように、ユーザの環境にnumpy(1.16)及びtensorflow(1.14)がインストールされており、ユーザがkeras(2.3.0)のインストールを要求したとする。この例では、結果ＩＤの１０１において上記の検証は完了していることが確認できる。

　検証実行部４０は、ユーザの環境における要求パッケージの検証が済んでいることが確認できた場合（ステップＳ１０７のＹＥＳ）、その検証結果を取得する（ステップＳ１１７）。検証実行部４０は、取得した検証結果が正常であったか異常であったかを確認する（ステップＳ１１３）。検証結果が正常であった場合（ステップＳ１１３のＹＥＳ）、要求処理部３０が要求パッケージをユーザに配信する（ステップＳ１１５）。

　検証結果が異常であった場合（ステップＳ１１３のＮＯ）、パッケージ生成部５５がエラー表示用のパッケージのパッケージを生成する（ステップＳ１１９）。検証実行部４０はエラー表示用のパッケージをユーザに配信する（ステップＳ１２１）。

　ステップＳ１０７において、パッケージの検証が済んでいることを確認できなかった場合（ステップＳ１０７のＮＯ）、要求処理部３０は、ネットワーク９０を介して配布サーバ９１にパッケージのインストール要求を行い、パッケージを取得する（ステップＳ１０９）。検証実行部４０は、ユーザの環境情報に基づいて検証環境６０を構築する。検証実行部４０は、構築した検証環境６０において、要求パッケージの動作検証を行う（ステップＳ１１１）。

　検証実行部４０は、取得した検証結果が正常であったか異常であったかを確認する（ステップＳ１１３）。以降の処理は上述の場合と同様であるので省略する。

　このように、検証装置１０１は、要求パッケージが有害でないことを確認してからユーザへの中継を行うため、ユーザの環境に有害なパッケージがインストールされることを防ぐことができる。
　また、ユーザの環境では通常、プロキシ等が必須となるが、これらはパッケージの動作検証の妨げになる。検証装置１０１においてはこれらを外した環境により動作検証を行えるため、検証結果等の信頼性を高めることができる。

　以上説明したように、本実施の形態にかかる検証システム２００によれば、検証装置１０１が配布サーバ９１とユーザ端末７１との間でパッケージのインストール要求の中継を行うため、ユーザ側の負荷を抑え、安全にパッケージを検証することができる。

　また、本実施の形態にかかる検証方法によれば、ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信し、前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得し、前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築し、前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行し、前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信するので、開発者側の負荷を抑え、安全にパッケージを検証することができる。
＜実施の形態３＞
　ユーザからインストール要求がある度に一から検証環境６０を構築していく場合、既にインストールされたパッケージが多いほど検証環境６０の構築に時間が掛かる。そのため、本実施の形態では、検証環境６０の構築に掛かる時間を削減する方法を説明する。なお、本実施の形態にかかる検証システム２００の構成については実施の形態２と同様であるので説明を省略する。

　本実施の形態では、パッケージの動作検証結果をツリー構造として記憶する。ツリー構造により記憶することで、検証結果や検証環境６０を視覚的に把握することができる。そのためこれらの管理者にとって管理が容易になるという利点がある。

　初めに、本実施の形態におけるツリーの構造について説明する。
　既に図１０を用いて説明したように、パッケージの検証結果は、検証に用いられた環境情報と共に結果リスト１１として記憶される。結果リスト１１は、例えば図２０に示したように、検証パッケージの複雑度や、検証結果が利用された回数（頻度）を示したものでもよい。

　図２０に示した結果リスト１１をツリー構造により表したものを図２１に示す。図２１に示すように、インストールしたパッケージはツリー上のノードとして表される。また、パッケージはインストールされた順に記録される。したがってパッケージがインストールされる度にノードが繋がり、ツリーが成長していく。

　パッケージの検証結果が異常である場合にはノードを増やさないため、各ノードはそのパッケージについて動作検証がなされ、結果が正常であったことを意味する。またツリーはその時点に至るまでの検証環境６０を示している。

　図２１に示したツリー図を用いて、検証システム２００が行う処理を説明する。
　初めに、ユーザＡはパッケージが何もインストールされていない初期状態にある（ｓ５０）。ユーザＡがnumpy（ａ５１）のインストール要求をすると、検証実行部４０は、結果リスト１１において、初期状態（ｓ５０）に対するnumpyの動作検証結果を確認する。検証結果がない場合、要求処理部３０は、配布サーバ９１から要求パッケージであるnumpyを取得し、パッケージ記憶部５６に記憶する。

　検証実行部４０は、ユーザＡの初期状態（ｓ５０）の検証環境６０を構築し、検証環境６０上で、パッケージ記憶部５６に記憶されたnumpyをインストールし、動作検証を行う。検証結果が正常であった場合、要求処理部３０はユーザＡにnumpyのパッケージを渡す。ユーザＡはnumpyをインストールする（ａ５１）。検証実行部４０は、構築したnumpyの検証環境６０を保持する。

　その後、ユーザＡがpandasのインストール要求をしたとする。検証実行部４０は、既に検証済みであるnumpy（ａ５１）の検証は行わない。検証実行部４０は、直近の検証環境６０、すなわちnumpyがインストールされた検証環境６０を用いて、pandasの動作検証を行う。pandasの検証結果が正常であった場合、ユーザＡはpandasをインストールする（ａ５２）。仮に、pandasの検証結果が異常であった場合は、検証実行部４０は構築した検証環境６０を破棄し、ユーザＡに対しエラー表示用のパッケージを配信する。

　ユーザＢが初期状態（ｓ５０）からflask（ｂ５１）をインストールする場合は、要求パッケージが異なるため、ユーザＡの検証結果を用いることはできない。そのため、ツリー上は別のノードとなり、flask（ｂ５１）についてもnumpy（ａ５１）の場合と同様に検証を行う必要がある。

　また、図２２に示したツリーにおいて、同一のパッケージを別のユーザがインストールした場合を説明する。
　図２２において、ユーザＡがnumpy、tensorflow、kerasの順にインストールしたとする（ｓ１、ａ１、ａ２）。検証実行部４０は各ステップにおいて検証を行い、各ステップにおける検証環境６０を保持する。

　次にユーザＢが、numpy、scikit-learnの順にインストール要求をした場合（ｓ１、ｂ１）、numpyは既にユーザＡにおいて検証済みのため、検証実行部４０はnumpyの検証を行わずにユーザＢにnumpyのインストールを許可する。検証実行部４０は、numpyが検証済みの検証環境６０を用いてscikit-learnの検証を実行する（ｂ１）。

　ここで、ユーザＡがさらにscikit-learnのインストール要求をしたとする（ａ３）。ユーザＢによりscikit-learnは検証されているが（ｂ１）、検証環境６０が異なるため、検証実行部４０はａ２の検証環境６０を用いて、改めてscikit-learnの検証を行う。このように、検証環境６０が異なる場合には、要求パッケージが同一であっても異なるノードとして管理する。

　以上説明したように、本実施の形態にかかる検証システム２００によれば、検証結果をツリー構造により表すことで、検証結果及び検証環境６０を効率的に管理することができる。
＜実施の形態４＞

　既に述べたように、公開されるパッケージの数は膨大である。検証結果を利用するにあたり、環境情報が完全に一致した結果のみを利用し、少しでも異なれば新たな検証を行おうとすると、検証環境６０の増加によりマシンのリソースを圧迫する。

　上記問題の対応策として、本実施の形態では、効率的に検証結果を利用する方法を説明する。なお、本実施の形態にかかる検証システム２００の構成については実施の形態２と同様であるので説明を省略する。

　実施の形態３において説明した図２２のツリーを用いて、本実施の形態において検証システム２００が実行する処理を説明する。ユーザＡ及びＢは、ツリーに示されるようにｓ１、ａ１、ａ２、ｂ１のパッケージをインストールしており、ユーザＡがscikit-learn（ａ３）のインストール要求をしているとする。

　ここで、検証実行部４０は、ツリー上の一定のホップ数の範囲内にあるscikit-learnの検証結果を利用する。具体的には、検証実行部４０は、検証結果の利用を許容するホップ数の閾値を設定し、閾値以内の範囲内にscikit-learnの検証結果があればそれを利用し、そうでなければ新たに検証を行う。

　例えば、閾値を４に設定したとする。図２２において、ユーザＢのscikit-learnのノード（ｂ１）はユーザＡがインストール要求しているノード（ａ３）から４ホップ以内に存在する。したがって検証実行部４０は、ｂ１の結果を利用し、新たな検証を行わずにユーザＡのscikit-learn（ａ３）のインストール要求を許可する。

　なお、上記の場合、検証実行部４０はユーザＡのインストール要求に対する検証は行わないが、検証環境６０の更新は行う。また、上記の例ではホップ数を４として閾値を設定したが、閾値はこれに限られず、自由に設定することができる。閾値を大きくすれば検証の回数をより少なくすることができ、閾値を小さくすれば、より近い検証環境における検証結果のみを利用することができる。

　また、中間に位置するパッケージの複雑さを考慮して閾値を設定してもよい。パッケージの複雑度は、例えばインストール時に関係するプロセス、ファイル数、ディレクトリ数等から算出し、結果リスト１１に記憶する。

　例えば、上記の例ではnumpy（ｓ１）とscikit-learn（ａ３）との間にあるtensorflow（ａ１）及びkeras（ａ２）の複雑さを考慮する。例えばノード間のホップ数を求める際に、ノード間の距離に加えて、パッケージの複雑度の１０分の１を加算する。例えば図２０に示した例ではnumpyの複雑度が３であるので、numpyがツリーの中間にある場合には、ホップ数に０．３を加えたものを閾値との比較に用いる。

　以上説明したように、本実施の形態にかかる検証システム２００によれば、検証結果等のツリーにおける所定の範囲内の検証結果を利用して、効率的に検証を行うことができる。

＜実施の形態５＞
　次に、図２３及び図２４に示したツリー図を用いて、本実施の形態を説明する。本実施の形態では、パッケージのインストール順のみが異なる場合の検証の効率化について説明する。なお、本実施の形態にかかる検証システム２００の構成については実施の形態２と同様であるので説明を省略する。

　図２３に示すように、ユーザＡがnumpy、tensorflow、keras（ｓ１１、ａ１１、ａ１２）を、ユーザＢがnumpy、scikit-learn、tensorflow、keras（ｓ１１、ｂ１１～ｂ１３）をインストールしているとする。各ステップにおいては検証実行部４０により動作検証が完了している。

　ここで、ユーザＡがscikit-learnのインストールを要求したとする（ａ１３）。検証実行部４０は、１つのノードを起点として、検証パッケージが属する枝とノードの順番のみが異なる他の枝を検出した場合に、他の枝の検証結果を利用する。図２３に示した例では、分岐する直前のノードであるnumpy（ｓ１１）を起点として、検証パッケージ（ａ１３）が属するユーザＡ側の枝と、ユーザＢ側の枝とでは、パッケージの順番のみが異なっている。

　したがって、検証実行部４０はユーザＢにおける検証結果を使用し、ユーザＡに対するscikit-learn（ａ１３）の検証は行わずに、ユーザＡのインストール要求を許可する。そのためツリーにおいてノードは追加されず、ツリーは図２４のように表される。なお、検証は行わないが、検証実行部４０は検証環境６０の更新を行う。

　上記の例では、要求パッケージの属する枝と他の枝が、分岐の直前のノードを起点として順番のみ異なる場合を説明したが、これに限られない。例えば、中間に別のノードが含まれており、順番以外に異なる要素があってもよい。また、一定の基準を設け、順番がある程度同一であることを必要としてもよい。

　以上説明したように、本実施の形態にかかる検証システム２００によれば、検証結果のツリーにおいて、起点となるノードから順番のみ異なる検証結果の枝が存在する場合に、これを利用して、効率的に検証を行うことができる。

＜実施の形態６＞
　次に、図２５を用いて本実施の形態を説明する。本実施の形態では、検証結果のツリーにおいて、他の枝と共通するパッケージの割合に基づいて検証を効率化する方法について説明する。なお、本実施の形態にかかる検証システム２００の構成については実施の形態２と同様であるので説明を省略する。

　図２５において、ユーザＡが初期状態からnumpy、tensorflow、kerasをインストールしたとする（ｓ２１、ａ２１～ａ２３）。また、ユーザＢが初期状態からdocker-compose、numpy、ryd、tensorflowをインストールしたとする（ｓ２１、ｃ２１～ｃ２４）。

　ここで、ユーザＢがkerasのインストールを要求したとする（ｃ２５）。検証実行部４０は、１つのノードを起点として、検証パッケージが属する枝と共通するパッケージが所定の割合以上でインストールされた他の枝を検出した場合に、他の枝の検証結果を利用する。
所定の割合は、例えば５割である。

　図２５に示した例では、初期状態（ｓ２１）を起点として、ユーザＡ側の枝には３つ、ユーザＢ側の枝には４つのパッケージがインストールされている。ユーザＡ、Ｂのインストール済みパッケージを比較すると、numpy（ａ２１、ｃ２２）及びtensorflow（ａ２２、ｃ２４）の２つが共通している。

　検証実行部４０は、これらの共通するパッケージが各ユーザのインストール済みのパッケージのうちに占める割合を算出する。上記の例では、ユーザＡについては３分の２、ユーザＢについては４分の２となる。したがって、ユーザＡの枝とユーザＢの枝とでは、５割以上のパッケージが共通していることとなる。したがって、検証実行部４０は、ユーザＢのインストール要求に対するkerasの検証は行わずユーザＡの検証結果を利用し、ユーザＢのkerasのインストールを許可する。なお、検証は行わないが検証環境６０の更新は行う。

　上記の説明では所定の割合を５割として説明したが、これに限られない。割合を高く設定すれば各枝のインストール環境が近くなり、検証精度を高められると考えられる。また、例えば実施の形態５などと組み合わせて、共通するパッケージの割合が低い場合には、順番が一致していればインストールを許可するなどとしてもよい。

　以上説明したように、本実施の形態にかかる検証システム２００によれば、検証結果等のツリーにおいて、他の枝と共通するパッケージが所定の割合以上の場合に、他の枝の検証結果を利用し、効率的に検証を行うことができる。

＜実施の形態７＞
　実施の形態４から６では、検証済みの結果を効率的に利用する方法を説明してきた。しかし、公開されるパッケージの数と共にユーザからの要求パターンは増加し、既存の検証結果が利用できない場合には新たに検証環境６０を構築せざるを得ない。一度構築した検証環境６０を全て維持すると、検証を行うマシンのリソースを圧迫することとなる。
　そこで、本実施の形態では、検証のために構築された検証環境６０を効率的に管理する方法を説明する。

　本実施の形態では、既に述べてきたツリー構造を用いて検証環境６０についても管理を行う。図２６に示すように、検証結果のツリーにおいて、各ノードは検証結果が利用された回数情報を保持する。

　具体的には、検証実行部４０は、最初の検証が行われたときを１回目として、利用された回数情報を結果リスト１１に記憶する。検証実行部４０は、検証結果が利用される度に１を加算し、結果リスト１１を更新する。結果リスト１１は、例えば図２０に示すように頻度欄を設け、利用回数が把握できるようにする。例えば最初の検証が行われた後、検証結果を１回利用されれば頻度は２となり、一度も利用されない場合は１のままである。検証結果が利用された場合、検証実行部４０は上位にある全てのノードについても１を加算する。

　検証実行部４０は、所定のタイミングにおいて、上記の頻度に基づいて、対応する検証環境６０を削除する。所定のタイミングとは、例えば、検証環境６０の数が予め設定した上限に達したとき等である。検証実行部４０は、例えば頻度が２以下の検証結果に対応する検証環境６０を削除する。検証環境６０を削除した後のツリーの例を図２７に示す。なお、削除するのは検証環境６０であり、検証結果や回数情報は削除せずに保持しておく。よって、頻度の低い検証結果であっても、将来的に利用することができる。

　図２７では、頻度の低いノードを削除して示したが、図２８に示すように、ツリー上で削除の痕跡が把握できる状態によりツリーを更新してもよい。これにより、管理者はより詳細に状況を把握することができる。

　以上説明したように、本実施の形態にかかる検証システム２００によれば、検証環境６０を効率的に管理することができる。

＜ハードウェアの構成例＞
　図２９は、検証処理を実現するためのハードウェア構成例を示すブロック図である。当該ハードウェア構成は、プロセッサ３０１とメモリ３０２を備えている。

　プロセッサ３０１は、メモリ３０２からコンピュータプログラム（検証プログラム）を読み出して実行することで、上述の実施形態においてフローチャートを用いて説明された検証装置の処理を行う。ここで、検証プログラムは、ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信し、前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得し、前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築し、前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行し、前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する処理をコンピュータに実行させるものである。

　プロセッサ３０１は、例えば、マイクロプロセッサ、MPU（Micro Processing Unit）、又はCPU（Central Processing Unit）であってもよい。プロセッサ３０１は、複数のプロセッサを含んでもよい。

　メモリ３０２は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ３０２は、プロセッサ３０１から離れて配置されたストレージを含んでもよい。この場合、プロセッサ３０１は、図示されていないI/Oインタフェースを介してメモリ３０２にアクセスしてもよい。

　図６の例では、メモリ３０２は、ソフトウェアモジュール群を格納するために使用される。プロセッサ３０１は、これらのソフトウェアモジュール群をメモリ３０２から読み出して実行することで、上述の実施形態において説明された検証装置１００の処理を行うことができる。

　プロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

　なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
　例えば、上述の説明では、プロジェクトごとに検証装置１０１を用いたが、これに限られない。例えば、プロジェクトをプロジェクトＩＤにより識別するなどして、１つの検証装置１０１内に複数のプロジェクトの情報をまとめてもよい。
　また、検証結果等のツリー構造は上述したものに限られず、例えば、Python、Node.js等のパッケージ単位でツリーを分けてもよい。

　また、上述の例では、検証環境６０を検証結果の利用頻度に基づいて削除したが、これに限られない。例えば、環境情報の類似度を算出し、類似度の高い検証環境６０を統合し、不要なものを削除してもよい。

　また、例えば、検証結果等が利用された日時に基づいて検証環境６０を削除してもよい。具体的には、検証実行部４０は、検証結果が利用された日時を結果リスト１１に記憶する。結果リスト１１はその一定数を履歴として保持してもよいし、その都度更新されて最終利用日時のみが残るようにしてもよい。例えば、検証実行部４０は、所定の期間を定めて、その期間が経過した検証環境６０を削除する。例えば、所定の期間を１年と定めた場合、検証実行部４０は、最後に検証結果が利用されてから１年が経過した検証環境６０を削除する。

　上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
　（付記１）
　ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信する受信手段と、
　前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得する取得手段と、
　前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築する構築手段と、
　前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行する検証手段と、
　前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する送信手段と、
　を備える、検証装置。
　（付記２）
　前記受信手段は、前記端末装置から前記配布サーバに対し前記配布パッケージの取得を要求する前記インストール要求を受信する、
　付記１に記載の検証装置。
　（付記３）
　前記受信手段は、前記端末装置から前記検証装置に対し前記配布パッケージの取得を要求する前記インストール要求を受信する、
　付記１に記載の検証装置。
　（付記４）
　前記端末装置の識別情報と前記開発環境の開発環境情報とを関連付けた環境リストを記憶する記憶手段を備え、
　前記構築手段は、前記環境リストに基づいて、前記インストール要求に含まれる前記端末装置の識別情報に対応する開発環境情報を特定し、前記特定した開発環境情報に基づいて前記検証環境を構築する、
　付記１乃至３のいずれか一項に記載の検証装置。
　（付記５）
　前記端末装置を使用するユーザの識別情報と前記開発環境の開発環境情報とを関連付けた環境リストを記憶する記憶手段を備え、
　前記構築手段は、前記環境リストに基づいて、前記インストール要求に含まれる前記ユーザの識別情報に対応する開発環境情報を特定し、前記特定した開発環境情報に基づいて前記検証環境を構築する、
　付記１乃至３のいずれか一項に記載の検証装置。
　（付記６）
　前記端末装置を使用する開発プロジェクトの識別情報と前記開発環境の開発環境情報とを関連付けた環境リストを記憶する記憶手段を備え、
　前記構築手段は、前記環境リストに基づいて、前記インストール要求に含まれる前記開発プロジェクトの識別情報開発環境情報を特定し、前記特定した開発環境情報に基づいて前記検証環境を構築する、
　付記１乃至３のいずれか一項に記載の検証装置。
　（付記７）
　前記構築手段は、前記端末装置から前記開発環境情報を取得し、前記取得した開発環境情報を前記環境リストに登録する、
　付記４乃至６のいずれか一項に記載の検証装置。
　（付記８）
　前記構築手段は、前記端末装置に提供される開発環境の開発環境情報を前記環境リストに登録する、
　付記４乃至６のいずれか一項に記載の検証装置。
　（付記９）
　前記構築手段は、前記検証結果に基づいて、前記環境リストの開発環境情報を更新する、
　付記４乃至８のいずれか一項に記載の検証装置。
　（付記１０）
　前記インストール検証に用いた検証環境を保持する検証環境保持手段を備え、
　前記検証手段は、前記端末装置の開発環境に応じた検証環境が前記保持された検証環境に対応する場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　付記１乃至９のいずれか一項に記載の検証装置。
　（付記１１）
　前記検証環境保持手段は、前記インストール検証に用いた複数の検証環境を前記配布パッケージのインストール履歴に関連付けて保持し、
　前記検証手段は、前記端末装置の開発環境に応じた検証環境が、前記関連付けられた複数の検証環境のいずれかに対応する場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　付記１０に記載の検証装置。
　（付記１２）
　前記検証環境保持手段は、前記インストール検証に用いた複数の検証環境を前記配布パッケージのインストール順にツリー状に関連付けて保持し、
　前記検証手段は、前記端末装置の開発環境に応じた検証環境が、前記ツリー状に関連付けられた複数の検証環境のいずれかに対応する場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　付記１１に記載の検証装置。
　（付記１３）
　前記検証手段は、前記端末装置の開発環境に応じた検証環境の前記配布パッケージのインストール履歴と、前記対応する検証環境の前記配布パッケージのインストール履歴との差が所定の範囲内の場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　付記１１又は１２に記載の検証装置。
　（付記１４）
　前記検証手段は、前記端末装置の開発環境に応じた検証環境の前記配布パッケージのインストールの複雑度と、前記対応する検証環境の前記配布パッケージのインストールの複雑度との差が所定の範囲内の場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　付記１３に記載の検証装置。
　（付記１５）
　前記検証環境保持手段は、所定の条件を満たす場合、前記保持された検証環境を削除する、
　付記１０乃至１４のいずれか一項に記載の検証装置。
　（付記１６）
　前記検証環境保持手段は、前記検証環境と前記インストール検証に再利用された回数とを関連付けて保持し、前記再利用された回数に基づいて、前記保持された検証環境を削除する、
　付記１５に記載の検証装置。
　（付記１７）
　前記検証環境保持手段は、前記検証環境と前記インストール検証に再利用された時間とを関連付けて保持し、前記再利用された時間に基づいて、前記保持された検証環境を削除する、
　付記１５又は１６に記載の検証装置。
　（付記１８）
　前記インストール検証の検証結果を検証環境に関連付けて保持する検証結果保持手段を備え、
　前記送信手段は、前記端末装置の開発環境に応じた検証環境が前記保持された検証環境に対応する場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　付記１乃至１７のいずれか一項に記載の検証装置。
　（付記１９）
　前記検証結果保持手段は、前記インストール検証に用いた複数の検証環境を前記配布パッケージのインストール履歴に関連付けて検証結果とともに保持し、
　前記送信手段は、前記端末装置の開発環境に応じた検証環境が、前記関連付けられた複数の検証環境のいずれかに対応する場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　付記１８に記載の検証装置。
　（付記２０）
　前記検証結果保持手段は、前記インストール検証に用いた複数の検証環境を前記配布パッケージのインストール順にツリー状に関連付けて検証結果とともに保持し、
　前記送信手段は、前記端末装置の開発環境に応じた検証環境が、前記ツリー状に関連付けられた複数の検証環境のいずれかに対応する場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　付記１９に記載の検証装置。
　（付記２１）
　前記送信手段は、前記端末装置の開発環境に応じた検証環境の前記配布パッケージのインストール履歴と、前記対応する検証環境の前記配布パッケージのインストール履歴との差が所定の範囲内の場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　付記１９又は２０に記載の検証装置。
　（付記２２）
　前記検証手段は、前記端末装置の開発環境に応じた検証環境の前記配布パッケージのインストールの複雑度と、前記対応する検証環境の前記配布パッケージのインストールの複雑度との差が所定の範囲内の場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　付記２１に記載の検証装置。
　（付記２３）
　前記送信手段は、前記検証結果が正常の場合、前記取得した配布パッケージを前記端末装置へ送信し、前記検証結果が異常の場合、前記配布パッケージの代わりに前記検証結果等の異常を示すエラーパッケージを前記送信端末へ送信する、
　付記１乃至２２のいずれか一項に記載の検証装置。
　（付記２４）
　前記配布パッケージは、インストール実行用の所定のスクリプトを含み、
　前記エラーパッケージは、前記所定のスクリプトとして、前記検証結果等の異常を出力する命令を含むダミーのスクリプトを含む、
　付記２３に記載の検証装置。
　（付記２５）
　前記ダミーのスクリプトは、前記検証結果等の異常の詳細を示す情報、又は、前記検証結果が異常である配布パッケージに関連する他の配布パッケージの情報を出力する命令を含む、
　付記２４に記載の検証装置。
　（付記２６）
　ソフトウェア開発用の配布パッケージを配布する配布サーバと、前記配布パッケージをインストールする端末装置と、検証装置とを備え、
　前記検証装置は、
　　前記配布サーバと前記端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信する受信手段と、
　　前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得する取得手段と、
　　前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築する構築手段と、
　　前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行する検証手段と、
　　前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する送信手段と、
　を備える、検証システム。
　（付記２７）
　ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信し、
　前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得し、
　前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築し、
　前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行し、
　前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する、
　検証方法。
　（付記２８）
　ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信し、
　前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得し、
　前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築し、
　前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行し、
　前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する、
　処理をコンピュータに実行させるための検証プログラムが格納された非一時的なコンピュータ可読媒体。

　１　受信部
　２　取得部
　３　構築部
　４　検証部
　５　送信部
　１０　結果リスト記憶部
　１１　結果リスト
　２０　ユーザリスト記憶部
　２１　ユーザリスト
　３０　要求処理部
　４０　検証実行部
　５０　環境リスト記憶部
　５１　環境リスト
　５５　パッケージ生成部
　５６　パッケージ記憶部
　６０　検証環境
　６１　検証環境記憶部
　７１　ユーザ端末
　７２　環境登録部
　７３　インストール実行部
　７４　表示部
　９０　ネットワーク
　９１　配布サーバ
　１００、１０１　検証装置
　２００　検証システム

Claims

　ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信する受信手段と、
　前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得する取得手段と、
　前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築する構築手段と、
　前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行する検証手段と、
　前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する送信手段と、
　を備える、検証装置。
　前記受信手段は、前記端末装置から前記配布サーバに対し前記配布パッケージの取得を要求する前記インストール要求を受信する、
　請求項１に記載の検証装置。
　前記受信手段は、前記端末装置から前記検証装置に対し前記配布パッケージの取得を要求する前記インストール要求を受信する、
　請求項１に記載の検証装置。
　前記端末装置の識別情報と前記開発環境の開発環境情報とを関連付けた環境リストを記憶する記憶手段を備え、
　前記構築手段は、前記環境リストに基づいて、前記インストール要求に含まれる前記端末装置の識別情報に対応する開発環境情報を特定し、前記特定した開発環境情報に基づいて前記検証環境を構築する、
　請求項１乃至３のいずれか一項に記載の検証装置。
　前記端末装置を使用するユーザの識別情報と前記開発環境の開発環境情報とを関連付けた環境リストを記憶する記憶手段を備え、
　前記構築手段は、前記環境リストに基づいて、前記インストール要求に含まれる前記ユーザの識別情報に対応する開発環境情報を特定し、前記特定した開発環境情報に基づいて前記検証環境を構築する、
　請求項１乃至３のいずれか一項に記載の検証装置。
　前記端末装置を使用する開発プロジェクトの識別情報と前記開発環境の開発環境情報とを関連付けた環境リストを記憶する記憶手段を備え、
　前記構築手段は、前記環境リストに基づいて、前記インストール要求に含まれる前記開発プロジェクトの識別情報開発環境情報を特定し、前記特定した開発環境情報に基づいて前記検証環境を構築する、
　請求項１乃至３のいずれか一項に記載の検証装置。
　前記構築手段は、前記端末装置から前記開発環境情報を取得し、前記取得した開発環境情報を前記環境リストに登録する、
　請求項４乃至６のいずれか一項に記載の検証装置。
　前記構築手段は、前記端末装置に提供される開発環境の開発環境情報を前記環境リストに登録する、
　請求項４乃至６のいずれか一項に記載の検証装置。
　前記構築手段は、前記検証結果に基づいて、前記環境リストの開発環境情報を更新する、
　請求項４乃至８のいずれか一項に記載の検証装置。
　前記インストール検証に用いた検証環境を保持する検証環境保持手段を備え、
　前記検証手段は、前記端末装置の開発環境に応じた検証環境が前記保持された検証環境に対応する場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　請求項１乃至９のいずれか一項に記載の検証装置。
　前記検証環境保持手段は、前記インストール検証に用いた複数の検証環境を前記配布パッケージのインストール履歴に関連付けて保持し、
　前記検証手段は、前記端末装置の開発環境に応じた検証環境が、前記関連付けられた複数の検証環境のいずれかに対応する場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　請求項１０に記載の検証装置。
　前記検証環境保持手段は、前記インストール検証に用いた複数の検証環境を前記配布パッケージのインストール順にツリー状に関連付けて保持し、
　前記検証手段は、前記端末装置の開発環境に応じた検証環境が、前記ツリー状に関連付けられた複数の検証環境のいずれかに対応する場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　請求項１１に記載の検証装置。
　前記検証手段は、前記端末装置の開発環境に応じた検証環境の前記配布パッケージのインストール履歴と、前記対応する検証環境の前記配布パッケージのインストール履歴との差が所定の範囲内の場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　請求項１１又は１２に記載の検証装置。
　前記検証手段は、前記端末装置の開発環境に応じた検証環境の前記配布パッケージのインストールの複雑度と、前記対応する検証環境の前記配布パッケージのインストールの複雑度との差が所定の範囲内の場合、前記対応する検証環境を用いて前記インストール検証を実行する、
　請求項１３に記載の検証装置。
　前記検証環境保持手段は、所定の条件を満たす場合、前記保持された検証環境を削除する、
　請求項１０乃至１４のいずれか一項に記載の検証装置。
　前記検証環境保持手段は、前記検証環境と前記インストール検証に再利用された回数とを関連付けて保持し、前記再利用された回数に基づいて、前記保持された検証環境を削除する、
　請求項１５に記載の検証装置。
　前記検証環境保持手段は、前記検証環境と前記インストール検証に再利用された時間とを関連付けて保持し、前記再利用された時間に基づいて、前記保持された検証環境を削除する、
　請求項１５又は１６に記載の検証装置。
　前記インストール検証の検証結果を検証環境に関連付けて保持する検証結果保持手段を備え、
　前記送信手段は、前記端末装置の開発環境に応じた検証環境が前記保持された検証環境に対応する場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　請求項１乃至１７のいずれか一項に記載の検証装置。
　前記検証結果保持手段は、前記インストール検証に用いた複数の検証環境を前記配布パッケージのインストール履歴に関連付けて検証結果とともに保持し、
　前記送信手段は、前記端末装置の開発環境に応じた検証環境が、前記関連付けられた複数の検証環境のいずれかに対応する場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　請求項１８に記載の検証装置。
　前記検証結果保持手段は、前記インストール検証に用いた複数の検証環境を前記配布パッケージのインストール順にツリー状に関連付けて検証結果とともに保持し、
　前記送信手段は、前記端末装置の開発環境に応じた検証環境が、前記ツリー状に関連付けられた複数の検証環境のいずれかに対応する場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　請求項１９に記載の検証装置。
　前記送信手段は、前記端末装置の開発環境に応じた検証環境の前記配布パッケージのインストール履歴と、前記対応する検証環境の前記配布パッケージのインストール履歴との差が所定の範囲内の場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　請求項１９又は２０に記載の検証装置。
　前記検証手段は、前記端末装置の開発環境に応じた検証環境の前記配布パッケージのインストールの複雑度と、前記対応する検証環境の前記配布パッケージのインストールの複雑度との差が所定の範囲内の場合、前記対応する検証環境の検証結果に基づいて、前記配布パッケージを送信する、
　請求項２１に記載の検証装置。
　前記送信手段は、前記検証結果が正常の場合、前記取得した配布パッケージを前記端末装置へ送信し、前記検証結果が異常の場合、前記配布パッケージの代わりに前記検証結果等の異常を示すエラーパッケージを前記送信端末へ送信する、
　請求項１乃至２２のいずれか一項に記載の検証装置。
　前記配布パッケージは、インストール実行用の所定のスクリプトを含み、
　前記エラーパッケージは、前記所定のスクリプトとして、前記検証結果等の異常を出力する命令を含むダミーのスクリプトを含む、
　請求項２３に記載の検証装置。
　前記ダミーのスクリプトは、前記検証結果等の異常の詳細を示す情報、又は、前記検証結果が異常である配布パッケージに関連する他の配布パッケージの情報を出力する命令を含む、
　請求項２４に記載の検証装置。
　ソフトウェア開発用の配布パッケージを配布する配布サーバと、前記配布パッケージをインストールする端末装置と、検証装置とを備え、
　前記検証装置は、
　　前記配布サーバと前記端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信する受信手段と、
　　前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得する取得手段と、
　　前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築する構築手段と、
　　前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行する検証手段と、
　　前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する送信手段と、
　を備える、検証システム。
　ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信し、
　前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得し、
　前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築し、
　前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行し、
　前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する、
　検証方法。
　ソフトウェア開発用の配布パッケージを配布する配布サーバと端末装置との間で、前記端末装置から送信された前記配布パッケージのインストール要求を受信し、
　前記受信したインストール要求が要求する前記配布パッケージを前記配布サーバから取得し、
　前記受信したインストール要求に基づいて、前記端末装置の開発環境に応じた検証環境を構築し、
　前記構築した検証環境を用いて、前記取得した配布パッケージのインストール検証を実行し、
　前記インストール検証の検証結果に基づいて、前記取得した配布パッケージを前記端末装置へ送信する、
　処理をコンピュータに実行させるための検証プログラムが格納された非一時的なコンピュータ可読媒体。