端末装置のコンピュータで実行され、自動車での走行中の実行を想定して安全時用リソースと非安全時用リソースとを備えるアプリケーションプログラムのリソースを管理するプラットフォームのプログラムであって、予め安全非安全状態を判定するための判定基準のデータが準備されており、車両情報を入力する車両情報入力ステップと、前記車両情報と前記判定基準に基づいて、安全非安全状態を判定する安全判定ステップと、前記安全判定手段の判定結果に基づいて、前記安全時用リソースと前記非安全時用リソースのいずれかを選択するリソース選択ステップとを実行させるプラットフォームのプログラム。前記車両情報は、車両の現在位置、車速、シフトノブの位置、パーキングブレーキの位置、ステアリングホイールの舵角のうち少なくとも一つを含むことを特徴とする請求項1に記載のプラットフォームのプログラム。前記判定基準のデータは、国あるいは地域ごとに異なる安全判定基準を持つことを特徴とする請求項1に記載のプラットフォームのプログラム。前記判定基準のデータは外部に接続されたサーバに保管されており、必要なタイミングで前記サーバよりダウンロードされることを特徴とする、請求項1に記載のプラットフォームのプログラム。請求項1~4のいずれか一項に記載のプラットフォームのプログラムを格納する記録媒体。請求項1~4のいずれか一項に記載のプラットフォームのプログラムを搭載した端末装置。昨今は、先述した車載端末に加えて、タブレット端末やスマートフォンなどのモバイル端末で、ナビゲーションやオーディオ等自動車上での使用が想定されたアプリケーションを搭載することのできる端末が増加している。これらの端末では、アプリケーションプログラムが動作するソフトウェアプラットフォームを構築し、クラスライブラリのAPIApplicationPlatformInterfaceを公開することで、さまざまな企業や一般の開発者が端末上で動作するプログラムを開発することができる仕組みを備える場合が多い。しかし、開発者は、自動車内での使用を想定したアプリケーションを開発する際に、安全時と非安全時で別々に挙動を記述する必要があるため、プログラムステップ数が増大し、そのための開発工数コストが増大していた。また、ドライバにとっては、安全非安全の判定基準がアプリケーションによって異なる可能性があるため、ドライバに対し混乱の原因となる可能性があった。本発明は、上記従来の課題を解決するもので、安全時非安全時の差異があっても、開発工数を増やすことなく、また、安全非安全の判定基準をアプリケーション間で統一することができるためドライバの混乱を防ぐことができるプラットフォームのプログラムおよび端末装置を提供することを目的とする。上記目的を達成するために、本発明のプラットフォームのプログラムは、端末装置のコンピュータで実行され、自動車での走行中の実行を想定して安全時用リソースと非安全時用リソースを備えるアプリケーションプログラムのリソースを管理する。本発明のプラットフォームのプログラムは、車両情報を入力する車両情報入力ステップと、車両情報に基づいて、安全非安全状態を判定する安全判定ステップと、安全判定手段の判定結果に基づいて、安全時用リソースと非安全時用リソースのいずれかを選択するリソース選択ステップとを端末装置のコンピュータに実行させる。ここで、車両情報は、車両の現在位置、車速、シフトノブの位置、パーキングブレーキの位置、ステアリングホイールの舵角のうち少なくとも一つを含む。また、本発明のプラットフォームのプログラムは、記憶媒体に記憶され、端末装置に搭載される。本発明のプラットフォームのプログラムによれば、アプリケーションプログラムの開発者は、安全時非安全時の差異によってコードの変更を必要としないため、コードのステップ数およびコード開発者の工数を低減し、デバッグを容易にすることが可能となる。また、安全判定のアルゴリズムをアプリケーション間で統一することができ、ドライバの混乱を防ぐことができる。以下、本発明の一実施の形態に係わる端末装置について図面を参照しながら説明する。図1は、本実施の形態の端末装置100のブロック図を示している。端末装置100は、表示部101、スピーカ102、入力部103、記憶部104、GPSGlobalPositioningSystem105、センサ106、通信部107、制御部108から構成されている。表示部101は、液晶ディスプレイなどで構成され、各種アプリケーションの情報を表示する。スピーカ102は、各種アプリケーションの音声情報を出力する。入力部103は、表示部101上に設置されたタッチパネル等で構成され、ユーザは各種アプリケーションの操作のための入力をすることができる。例えば、アプリケーションが経路案内のためのナビゲーションの場合、ユーザは経路設定のために目的地や経由地等を入力することができる。記憶部104は、ハードディスク、フラッシュメモリ等で構成され、地図データ等のデータを記憶している。GPS105は、GPS衛星からの信号を受信して車両の現在位置を算出し、制御部108に供給する。センサ106は、車速センサやジャイロセンサ、車のシフトノブの位置センサ、パーキングブレーキのON/OFFセンサ、ステアリングホイールの舵角センサなどで構成され、検出値を制御部108に供給する。ここで、端末装置100は、GPS105、車速を検出する車速センサとしての加速度センサ、角速度を検出するジャイロセンサなどを内部に含んでいてもよいし、それらセンサが車に搭載されており、コネクタにより有線で、もしくは通信部107を介して無線でそれらからの検出信号を取得するような構成にしてもよい。また、車のシフトノブの位置センサ、パーキングブレーキのON/OFFセンサ、ステアリングホイールの舵角センサは車に搭載されており、端末装置100はそれらセンサからの検出信号をコネクタにより有線で、もしくは通信部107を介して無線でそれらからの検出信号を取得する。通信部107は、外部の情報センタに蓄積されている渋滞情報その他の交通情報を取得して制御部108に供給する。また、通信部107は前述したように車に搭載された各種センサからの検出信号を取得して制御部108に供給する。交通情報については通信部107は光ビーコンや電波ビーコンで構成することで情報を取得したり、外部のネットワークにインターネット接続することで情報を取得するようにしてもよい。光ビーコンや電波ビーコンについては、端末装置100の内部に含んでいてもよいし、それらが車に搭載されており、通信部107でそれらからの検出信号を取得するような構成にしてもよい。制御部108は、CPUで構成され、内部のROM、RAMに格納される所定のプログラムを実行することで各種アプリケーションを実行する。例えば、アプリケーションが経路案内のためのナビゲーションの場合、制御部108はナビゲーション機能を実行する。制御部108は、記憶部104にアクセスし、検出された車両の現在位置近傍の地図データを読み出して表示部101に出力する。そして、入力部103から入力された目的地や経由地は制御部108に供給され、制御部108は記憶部104に記憶されている地図データを読み出して目的地に至る経路を探索する。そして、地図情報等を表示部101に出力し、経路案内のための音声情報をスピーカ102に出力することで、経路案内を行う。ここで、スピーカは端末装置100の内部に含まれていてもよいし、端末装置100が音声情報のみ出力して、車内に搭載されているスピーカから音声出力する構成としてもよい。図2は、制御部108の概念構成図を示している。制御部108は、通常のコンピュータとして構成されており、CPU、ROM、RAM、I/O及びこれらの構成を接続するバスいずれも図示せず等からなるハードウェア200と、ソフトウェア300を備えている。ソフトウェア300は、プラットフォーム310とアプリケーションプログラム320によって構成される。また、プラットフォーム310は、図1で示した制御部108に接続される各種入出力デバイスを制御するデバイスドライバ330、OSOperatingSystem340、標準API350を有する。アプリケーションプログラム320側でこの標準API350を呼び出すことで、各種のデータ処理を実行することができる。アプリケーションと各機能との間のインターフェースは共通化されている。従って、例えばアプリケーションプログラム320が経路案内のためのナビゲーションの場合、アプリケーションプログラム320側では、地図データのフォーマットについての知識がなくても、共通化されたインターフェースを用いることで、容易に地図データを利用することが可能となる。図3は、本発明の実施の形態のソフトウェア構成の機能ブロック図を示している。プラットフォーム310は、車両情報取得手段311、安全判定手段312、コード実行手段313、リソース選択手段314から構成されている。車両情報取得手段311は、外部のGPS105、センサ106、通信部107より、現在の車両情報を入力する。ここで車両情報とは、たとえばGPS105から得られる現在位置データや、センサ106あるいは通信部107で取得する、車速センサから得られる車速、シフトノブの位置、パーキングブレーキの位置ON/OFF、ステアリングホイールの舵角センサから得られる舵角などの情報である。車両情報取得手段311は、それら車両情報のうち、少なくとも一つの車両情報を入力する。安全判定手段312は、車両情報取得手段311によって取得された車両情報をもとに、その時点時点における表示操作が安全であるかどうかを、予め定められた論理に基づき判定する。安全判定手段312が用いる論理の具体的な例については後述する。コード実行手段313は、アプリケーションプログラム320を開始終了したり、アプリケーションプログラム320からの呼び出しに基づいてライブラリの関数を実行する。また、必要に応じてリソース選択手段314が選択したリソースを参照する。リソース選択手段314は、安全判定手段312の判定結果に基づき、プログラム実行時に表示音声出力等に用いるリソースを選択する。ここでリソースとは、画像データ、文字列、数値、色データ、アニメーション記述データ、音声ファイル、動画ファイル、プッシュボタンやラジオボタンなどのGUI部品、そしてそれらのプロパティ属性からなる固定のバイナリまたはテキストデータである。リソース選択手段314は、安全時は安全時用リソース322を選択し、非安全時は非安全時用リソース323を選択する。アプリケーションプログラム320は、コンパイル済みコード321、安全時用リソース322、非安全時用リソース323、リソースIDリスト324とからなる。コンパイル済みコード321は、ソフトウェアの実行順序、関数、変数等が記述されたプログラムの本体である。C言語、JAVA登録商標言語などで記述されたテキストファイルがコンパイラによってコンパイルされているのが通常であるが、インタプリタ言語においてはこの限りではない。安全時用リソース322と非安全時用リソース323は、それぞれリソースの集合を格納しており、部品IDと共に画像データ、文字列等が関連づけられて保持されている。そのうち、安全時用リソース322は、安全と判定されたときに用いられるリソースであり、非安全時用リソース323は非安全と判定されたときに用いられるリソースである。リソースIDリスト324は、リソースに含まれる各リソースのID識別子とリソース実体データとの関連を格納している。リソースとリソースIDリストの関係、安全時用リソース322と非安全時用リソース323の相違については、具体的な例をあげて後に詳述する。なお、本実施の形態では、プラットフォーム310とアプリケーションプログラム320がどのハードウェアに存在するかを問わない。即ち、プラットフォーム310とアプリケーションプログラム320は同じハードウェア資源メモリに格納されていても良いし、別のハードウェア資源に格納されていてもよい。別のハードウェア資源に格納されている場合の例として、プラットフォーム310が端末装置100に搭載されていて、アプリケーションプログラム320はSDカード、USBメモリ、CD、DVD等のメディア、またはネットワーク越しの別のストレージに格納されている場合がある。次に、図3における安全判定手段312が用いる判定基準について、図4に示す判定基準の一例を用いて具体的に説明する。判定基準のデータはRAMに格納されており、安全判定手段312により適時読み出される。図4では、判定基準の例を判定基準1と判定基準2に分けて示している。それぞれの判定基準において、地域は、この判定基準が適用される地域を表している。上述したように、安全上の規制は国または地域によってそれぞれの交通事情等にあわせて異なっている。そのため、判定基準が適用される地域を示す情報を格納する。たとえば、図4aの判定基準1では、日本と米国に限って適用されることが記されている。図4bの判定基準2では、地域にかかわらず全世界で適用されることが記されている。地域の判断については、車両情報取得手段311により取得される、GPS105等によって検出された車両の位置データを用いて行う。図4の判定基準の条件は、車両の状況にもとづいて安全状態であると判断するための項目名とその値によって構成される。たとえば、判定基準1では、条件は単数であり、その項目名がパーキングブレーキ、値がONとなっている。即ち、パーキングブレーキがONの場合に安全であると判断し、それ以外パーキングブレーキがOFFの場合には非安全と判断する。それに対し、判定基準2では、条件は複数であり、条件1の項目名がシフトレバーで、値がリバースになっている。また、条件2の項目名が車速で、値が10kmh未満となっている。ここで、条件1と条件2の関係はORとなっている。すなわち、シフトレバーがリバースに入っているとき、または、車速が10kmh未満のときである、停車中または徐行中の場合に安全と判定し、それ以外の場合には非安全と判定する。なお、図4に示した事例では、説明を分かり易くするために表形式で例をあげたが、実際には、地域や実行条件を可変数持たせることも可能となる。これらを可変数にすることで、より複雑できめ細かい安全非安全判定ができる等の効果が考えられるが、判定アルゴリズムについて本質的な差異はない。また、判定基準のデータをXMLなどのファイル形式で、通信可能に接続された外部のサーバに持っておき、必要なときにダウンロードするといった構成も可能である。これにより、判定基準のデータを最新の状態に更新することが可能になる。次に、安全時用リソース322と非安全時用リソース323の設計例について、図5を用いて説明する。図5aは表示部101に表示する安全時の画面、図5bは非安全時の画面の設計例を表している。図5aにおいて安全時の画面510は、動画再生パネル511、プッシュボタン512、513、514とからなる。図5bにおいて非安全時の画面520は、静止画表示パネル521、プッシュボタン522、523、524とからなる。ここで、画面510と画面520で対応するリソースは同一のリソースIDを持っているものとする。たとえば、動画再生パネル511と静止画表示パネル521は同一リソースIDPanel01、プッシュボタン512とプッシュボタン522は同一リソースIDButton01を持っているものとする。図6に、それぞれのリソースIDと各リソースの関係を示す。図6において、リソースIDPanel01に対し、安全時は動画を再生可能なパネル511を割り当て、非安全時は静止画のみ表示可能なパネル521を割り当てている。これにより、走行中など非安全時には、動画を再生することによって、ドライバの脇見を誘発することがあるため、動画の再生をせず静止画のみの表示にすることができる。アプリ設計者は、動画再生パネル511と静止画表示パネル521に同一IDを振ることにより、それらを安全時と非安全時で使い分けることを意図することができる。また、Button01に対しプッシュボタン512とプッシュボタン522を割り当てており、安全時のプッシュボタン512が押下可能な状態であるのに対し、非安全時のプッシュボタン522は押下不可能な状態淡色表示状態を設定している。これにより、走行中など非安全時には実行させるべきではない機能に対し、非安全時の実行を制限することができる。同様に、図5aの安全時のプッシュボタン513が可視状態であるのに対し、図5bの非安全時のプッシュボタン523を非可視状態図5bの点線は非表示を表しているとすることができる。これにより、走行中など非安全時に重要度の低いボタンを非表示にして画面上の情報量を少なくすることができる。同様に、図5aの安全時のプッシュボタン514が通常のサイズであるのに対し、図5bの非安全時のプッシュボタン524をやや大きめのサイズにすることができる。これにより、走行中など非安全時にタッチ操作で押しやすい大きめのボタンを表示することができる。次に、図3におけるプラットフォーム310の主たる動作について、図7のフローチャートを用いて説明する。プラットフォーム310は、起動し初期動作を終えると図7のフローを繰り返すループに入る。ループの最初のステップS701において、車両情報取得手段311は車両情報を取得する。次に、ステップS702において、安全判定手段312は、ステップS701で取得した車両状況に基づいて、判定基準を参照して安全時か非安全時かを判断する。次に、ステップS703において、前回の安全非安全状態と切り替わったどうかを判定する。前回の安全非安全状態と同じ場合ステップS703でNoは、即座にループを終了する。前回の安全非安全状態と切り替わった場合ステップS703でYesは、ステップS704に処理を進める。ステップS704では、リソース選択手段314は各アプリケーションのアプリケーションプログラム320に対し、判定された安全非安全状態に応じて、安全時用リソース322または非安全時用リソース323を選択して再表示するように指示を行い、ループを終了する。以上、本発明の実施の形態では、安全時および非安全時用のリソースは、リソースIDによって紐づけられており、アプリケーションプログラムの開発者は、安全時非安全時の差異によって、コードの変更を必要としない。そのため、コードのステップ数およびコード開発者の工数を低減し、デバッグを容易にすることが可能となる。また、プラットフォーム側で安全非安全に関する共通の判定基準を用いるため、アプリケーションによって異なる可能性はなくなり、ドライバの混乱を防ぐことができる。本発明は、上記実施形態の構成に限られるものではなく、特許請求の範囲で示した機能、または上記実施形態の構成が持つ機能が達成できる構成であればどのようなものであっても適用可能である。また、本発明は、上記実施形態の機能を実現するプログラムを、ネットワークあるいは各種記憶媒体を介して端末装置に供給し、この端末装置のコンピュータが読み出して実行するプログラムも適用範囲である。