"カーシェアリング用のカーステーションCSの利用負荷を分散させるためのカーステーション負荷分散システムであって、CS利用状況管理サーバが、カーシェアリングの会員の端末とネットワークで接続され、前記CS利用状況管理サーバは、複数のCSの設置場所の位置情報及び最寄施設の情報を含んだCS設置情報DBと、それぞれのCSに入出庫するシェアカーの入庫時刻及び出庫時刻を逐次記録し、CSの利用状況を格納するCS利用状況DBと、前記会員からシェアカーの予約を受付けるシェアカー予約受付部と、前記CS利用状況DBに基づいて、各CSの混雑度を判定するCS混雑度判定部と、前記シェアカー予約受付部がシェアカーの予約を受付ける際に、前記会員が目的地とするCSの前記混雑度が所定の値より高い場合、前記CS設置情報DBに基づき、当該目的地のCSの代替となる代替CSを、前記会員の端末に提示する代替CS提示部と、を備えることを特徴とするカーステーション負荷分散システム。前記代替CS提示部は、前記目的地のCSに向かう場合と、前記代替CSに向かう場合の所要時間及びカーシェアリングの利用料金を比較し、当該所要時間の差及び当該利用料金の差に応じて、前記代替CSに向かう場合の割引料金を提示する、ことを特徴とする請求項1に記載のカーステーション負荷分散システム。前記CS利用状況管理サーバは、前記シェアカー予約受付部がシェアカーの予約を受付ける際に、前記会員が目的地とするCSの前記混雑度が所定の値より高い場合、前記目的地とするCSが同じか又は所定の移動距離内にある複数の会員の情報を検索し、前記目的地とするCSまでの相乗りを提示するCS間相乗り提示部を備える、ことを特徴とする請求項1に記載のカーステーション負荷分散システム。前記相乗り提示部は、前記相乗りのためにCS間の移動が必要となった会員に対し、当該移動のための移動時間及び利用料金の増加分に応じて、前記利用料金の割引を提示する、ことを特徴とする請求項3に記載のカーステーション負荷分散システム。前記CS利用状況管理サーバは、前記シェアカー予約受付部が予約を受付ける際に、前記会員が目的地とするCSの混雑度がある時間帯で所定の値以上となる場合、当該CSの利用開始時間の変更を提示するCS利用時間分散提示部を備える、ことを特徴とする請求項1に記載のカーステーション負荷分散システム。前記CS利用時間分散提示部は、前記シェアカー予約受付部が予約を受付ける際に、前記会員が目的地とする複数のCSの入力を受付け、前記複数のCSの中に時間帯によって前記混雑度が所定の値以上となるCSが含まれる場合、当該CSの混雑時間帯を避けるルートを提示する、ことを特徴とする請求項5に記載のカーステーション負荷分散システム。前記CS利用状況管理サーバは、前記CS設置情報DBと前記CS利用状況DBに基づいて、CS間移動確率を算出し、前記CS間移動確率が所定の値以上を持つCS間をオンデマンドバスの運行区間候補として提示するオンデマンドバスルート提示部を備える、ことを特徴とする請求項1に記載のカーステーション負荷分散システム。カーシェアリング用のカーステーションCSの利用負荷を分散させるためのカーステーション利用状況管理サーバであって、複数のCSの設置場所の位置情報及び最寄施設の情報を含んだCS設置情報DBと、それぞれのCSに入出庫するシェアカーの入庫時刻及び出庫時刻を逐次記録し、CSの利用状況を格納するCS利用状況DBと、会員からシェアカーの予約を受付けるシェアカー予約受付部と、前記CS利用状況DBに基づいて、各CSの混雑度を判定するCS混雑度判定部と、前記シェアカー予約受付部がシェアカーの予約を受付ける際に、前記会員が目的地とするCSの前記混雑度が所定の値より高い場合、前記CS設置情報DBに基づき、当該目的地のCSの代替となる代替CSを提示する代替CS提示部と、を備えることを特徴とするカーステーション利用状況管理サーバ。カーシェアリング用のカーステーションCSの利用負荷を分散させるためのカーステーション負荷分散方法であって、コンピュータが、複数のCSの設置場所の位置情報及び最寄施設の情報を含んだCS設置情報DBと、それぞれのCSに入出庫するシェアカーの入庫時刻及び出庫時刻を逐次記録し、CSの利用状況を格納するCS利用状況DBとを有し、会員からシェアカーの予約を受付けるステップと、前記CS利用状況DBに基づいて、各CSの混雑度を判定するステップと、前記シェアカーの予約を受付ける際に、前記会員が目的地とするCSの前記混雑度が所定の値より高い場合、前記CS設置情報DBに基づき、当該目的地のCSの代替となる代替CSを、前記会員に提示するステップと、を処理すること特徴とするカーステーション負荷分散方法。通常、カーシェアリング用の車は、専用の駐車場カーステーション、以下、CSと呼ぶで無人管理される。カーシェアリングのサービスに登録した会員は、最寄のCSを携帯電話やパーソナルコンピュータ等から検索し、空いている車を予約した後、そのCSに行き会員に発行されたICカード等で本人認証を受け、車のドアを解鍵して車内にあるキーを使ってそのまま発車する。返却は、CSに戻り施錠するだけである出発時のCSと同じCSである必要はない。そのため、利用者にとって身近に利用できるCSが多数存在することがカーシェアリング普及のための鍵となる。一般的に、CSの利用区域は、目的地の徒歩5分圏内が限度であると言われており、会員が多く利用したいと思うCSは、駅前等の特定の施設近辺に集中する傾向がある。しかし、その需要に合わせて駅前等にCSを設置できる場所を多数確保することは非常に困難である。したがって、利用が集中するCSを分散させたり、利用が集中するエリア内の限りあるCSを最大限に有効活用することが必要である。本発明では、上記のような課題に鑑み、カーステーションCSの需要を逐次把握し、利用負荷を分散するシステムを提供することを目的とする。上記課題を解決するため、本発明のカーステーション負荷分散システムは、以下のような解決手段を提供する。カーシェアリング用のカーステーションCSの利用負荷を分散させるためのカーステーション負荷分散システムであって、CS利用状況管理サーバが、カーシェアリングの会員の端末とネットワークで接続され、前記CS利用状況管理サーバは、複数のCSの設置場所の位置情報及び最寄施設の情報を含んだCS設置情報DBデータベースと、それぞれのCSに入出庫するシェアカーの入庫時刻及び出庫時刻を逐次記録し、CSの利用状況を格納するCS利用状況DBと、前記会員からシェアカーの予約を受付けるシェアカー予約受付部と、前記CS利用状況DBに基づいて、各CSの混雑度を判定するCS混雑度判定部と、前記シェアカー予約受付部がシェアカーの予約を受付ける際に、前記会員が目的地とするCSの前記混雑度が所定の値より高い場合、前記CS設置情報DBに基づき、当該目的地のCSの代替となる代替CSを、前記会員の端末に提示する代替CS提示部と、を備えることを特徴とする。このような構成によれば、本発明のカーステーション負荷分散システム以下、本システムと呼ぶことがあるには、CSに入出庫するシェアカーの入庫時刻及び出庫時刻を逐次記録し、CSの利用状況をリアルタイムで把握できるデータベース以下、DBを備えている。そして、本システムが、カーシェアリングの会員からシェアカー車両の予約を受付ける際に、会員が目的地とするCSの混雑度CSに駐車可能な車両の台数に対して、現在CSに駐車している車両の台数の割合を判定し、その混雑度が所定の値例えば90などより高い場合には、CSが設置された位置情報をもとに、目的地のCSの代替となるCSを会員に提示する。代替となるCSは、目的地からは少し離れるが徒歩圏にある近隣のCS、または他の交通手段によって同じ目的地に行くことが可能なCSを含む。このようにすることで、駅前等の特定のCSに利用が集中することを軽減する。さらに好ましくは、本発明のシステムにおいて、前記代替CS提示部は、前記目的地のCSに向かう場合と、前記代替CSに向かう場合の所要時間及びカーシェアリングの利用料金を比較し、当該所要時間の差及び当該利用料金の差に応じて、前記代替CSに向かう場合の割引料金を提示するように構成してもよい。このような構成によれば、代替CSを利用することで会員にとって所要時間や利用料金が増加する場合は、その増加分に応じて利用料金の割引価格を提示する。所要時間や利用料金の計算には、鉄道やバス等の公共交通機関を利用した場合も含まれる。このようにすることで、会員が代替CSを使用する動機付けが高まり、結果として、当初の目的地としたCSの利用集中をより軽減することができる。さらに好ましくは、本発明のシステムにおいて、前記CS利用状況管理サーバは、前記シェアカー予約受付部がシェアカーの予約を受付ける際に、前記会員が目的地とするCSの前記混雑度が所定の値より高い場合、前記目的地とするCSが同じか又は所定の移動距離内にある複数の会員の情報を検索し、前記目的地とするCSまでの相乗りを提示するCS間相乗り提示部を備えるように構成してもよい。このような構成によれば、会員が目的地とするCSの混雑度が高いと判定される場合は、同じCSを目的地とする他の会員を探し、それぞれの会員に対して相乗りを促すように提示する。このようにすることで、同じCSに向かうシェアカーの台数を減らすことができ、そのCSの利用集中をより軽減することができる。さらに好ましくは、本発明のシステムにおいて、前記相乗り提示部は、前記相乗りのためにCS間の移動が必要となった会員に対し、当該移動のための移動時間及び利用料金の増加分に応じて、前記利用料金の割引を提示するように構成してもよい。このような構成によれば、提示された相乗り条件に従い、ある会員がシェアカーを運転し目的地のCSに向かう途中、他の会員をピックアップするために余分に要した移動時間、利用料金の増加分に応じて、その会員に対して利用料金の割引を行う。このようにすることで、相乗りする会員がさらに増え、結果として目的地のCSの利用集中がより軽減される。さらに好ましくは、本発明のシステムにおいて、前記CS利用状況管理サーバは、前記シェアカー予約受付部が予約を受付ける際に、前記会員が目的地とするCSの混雑度がある時間帯で所定の値以上となる場合、当該CSの利用開始時間の変更を提示するCS利用時間分散提示部を備えるように構成してもよい。このような構成によれば、シェアカー予約受付の際、目的地のCSの混雑度がある時間帯で高いと判定される場合、そのCSの利用開始時間を混雑する時間帯からずらすように利用開始時間の変更を会員に対して提示する。このようにすることで、時間帯によって混雑度が高いCSがある場合、他の会員にその時間帯を避けるように促し、そのCSの利用集中を軽減することができる。さらに好ましくは、本発明のシステムにおいて、前記CS利用時間分散提示部は、前記シェアカー予約受付部が予約を受付ける際に、前記会員が目的地とする複数のCSの入力を受付け、前記複数のCSの中に時間帯によって前記混雑度が所定の値以上となるCSが含まれる場合、当該CSの混雑時間帯を避けるルートを提示するように構成してもよい。このような構成によれば、複数のCSを廻ることを予定している会員に対して、混雑する時間帯を有するCSがその中に含まれている場合には、その混雑時間帯を避けるルートを提示する。会員がこれに応じれば、結果として、CSの利用集中をさらに軽減することができる。さらに好ましくは、本発明のシステムにおいて、前記CS利用状況管理サーバは、前記CS設置情報DBと前記CS利用状況DBに基づいて、CS間移動確率を算出し、前記CS間移動確率が所定の値以上を持つCS間をオンデマンドバスの運行区間候補として提示するオンデマンドバスルート提示部を備えるように構成してもよい。このような構成によれば、CS設置情報とCS利用情報に基づいて、CS間移動確率を算出する。CS間移動確率とは、あるCSに駐車するシェアカーが別の特定のCSに移動する割合いを表した数値である。移動確率の高いCS間はそれだけ人の行き来が多いと考えられるので、そのCS間は、オンデマンドバスの運行区間として有力である。そのCS間にオンデマンドバスが運行すれば、その2つのCSの利用集中を軽減することができる。また、本発明のカーステーション負荷分散システムは、以下のように、システムの中核となるカーステーション利用状況管理サーバの発明、または、コンピュータによるカーステーション負荷分散方法として捉えることもでき、上記のシステムと同様な作用効果を奏する。カーシェアリング用のカーステーションCSの利用負荷を分散させるためのカーステーション利用状況管理サーバであって、複数のCSの設置場所の位置情報及び最寄施設の情報を含んだCS設置情報DBと、それぞれのCSに入出庫するシェアカーの入庫時刻及び出庫時刻を逐次記録し、CSの利用状況を格納するCS利用状況DBと、会員からシェアカーの予約を受付けるシェアカー予約受付部と、前記CS利用状況DBに基づいて、各CSの混雑度を判定するCS混雑度判定部と、前記シェアカー予約受付部がシェアカーの予約を受付ける際に、前記会員が目的地とするCSの前記混雑度が所定の値より高い場合、前記CS設置情報DBに基づき、当該目的地のCSの代替となる代替CSを提示する代替CS提示部と、を備えることを特徴とする。カーシェアリング用のカーステーションCSの利用負荷を分散させるためのカーステーション負荷分散方法であって、コンピュータが、複数のCSの設置場所の位置情報及び最寄施設の情報を含んだCS設置情報DBと、それぞれのCSに入出庫するシェアカーの入庫時刻及び出庫時刻を逐次記録し、CSの利用状況を格納するCS利用状況DBとを有し、会員からシェアカーの予約を受付けるステップと、前記CS利用状況DBに基づいて、各CSの混雑度を判定するステップと、前記シェアカーの予約を受付ける際に、前記会員が目的地とするCSの前記混雑度が所定の値より高い場合、前記CS設置情報DBに基づき、当該目的地のCSの代替となる代替CSを、前記会員に提示するステップと、を処理すること特徴とするカーステーション負荷分散方法。本発明によれば、カーステーションの需要を逐次把握し、利用負荷を分散するシステムを提供することができる。また、CSを設置する際の最適配置計画にも役立てることができる。以下、添付図面を参照して、本発明を実施するための形態以下、実施形態について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。[システム構成]まず、本発明を実現するシステム構成について説明する。図1は、本発明のカーステーション負荷分散システムの構成を示す図である。カーステーション負荷分散システム以下、単に、本システムと呼ぶは、CS利用状況管理サーバ100以下、単にサーバ100が、インターネットを介して、携帯電話やパーソナルコンピュータPC等の会員端末40と接続されている。サーバ100は、通常のカーシェアリングサービスを実現するための会員に対する課金や入会、脱会を受付けるための運用サーバ図示せず内に設けられデータベースDBを共有してもよいし、あるいは別個のサーバとして構築してもよい。また、サーバ100は、外部のデータベースとも接続され、公共交通機関料金DB20や地図DB21から必要なデータを随時取得することができるとする。サーバ100は、主な処理部として、シェアカー予約受付部10,CS混雑度判定部11,代替CS提示部12,CS間相乗り提示部13,CS利用時間分散提示部14,オンデマンドバスルート提示部15で構成される。それぞれの処理部は、CS設置情報DB22,CS利用状況DB23,車両利用状況DB24,会員利用状況DB25の各データベースに格納されたCS、車両シェアカー、会員に関する情報に基づいて、各種のテーブルを生成したり、参照したり、更新したりすることでそれぞれの処理を行う。これらのテーブルには、代替CS料金調整テーブル30,CS間相乗り料金調整テーブル31,CS間相乗り仲介テーブル32,CS稼働率テーブル33,CS料金時間帯調整テーブル34,及びCS間移動確率テーブル35があり、詳しくは後述する。シェアカー予約受付部10は、会員端末40からシェアカーの予約を受付ける機能を果す。会員は、専用のWebサイト等から、最寄のCSを検索し、予約情報会員ID,利用開始時間,予定使用時間を入力して、CS内の空いている車を予約する。本システムにおいては、この予約情報に加えて、目的地または目的地の最寄のCSも入力することとする。特に目的地がない場合には、予約した車が駐車しているCSを入力する。また、複数の目的地を入力し、さらに目的地を廻る予定ルートを入力してもよい。ただし、予約時に入力した予定使用時間及び目的地は、車を発進させた後であっても変更可能である。予約されたシェアカーのスケジュールは、会員IDとともに、車両利用状況DB24に記録される。CS混雑度判定部11は、CS利用状況DB23を用い、CSの混雑度を求める機能を果す。ここでいう混雑度とは、あるCSに駐車可能な車両の台数に対して、現在、実際に駐車している車両の数の割合を表す。特にシェアカー予約の受付部10に予約が入ったときには、目的地のCSの混雑度を必ずチェックし、所定以上の混雑度以上例えば90以上となっているCSを判定する。ここで判定した混雑度は、後の処理の基礎データとなる。もちろん、すべてのCSの混雑度は、求めに応じていつでも判定することができる。代替CS提示部12は、CS混雑度判定部11によって、特定のCSに利用が集中していると判定された場合混雑度が所定の値以上と判定された場合に、近隣の代替となるCSを抽出し、割引料金を会員端末40やその他適切な手段で提示する機能を果す。近隣のCSは、必ずしも徒歩圏になくともよい。利用が集中するCSは、典型的には、駅までの距離が近く便利な場所にある駐車場であり、通勤客や通学客をはじめ、鉄道の利用客が多く利用するものと考えられる。このような場合、代替CS提示部10は、同じ目的地駅等に到達可能な近隣のCSで、かつ利用率が比較的高くないCS例えば、隣の駅のCSや駅からやや離れた商店街等にあるCSを、CSの位置情報と近隣のCS情報、及び必要なら地図DB21を用いて抽出し、会員に提示する。会員は、提示された代替CSを利用した場合、代替CSに向かうための利用料金の増加に対して割引価格を提示するなどして、会員が代替CSを利用しやすいように誘導する。このとき、代替CS料金調整テーブル30を用い、目的CSを利用した場合と代替CSを利用した場合の所要時間、料金を比較し、それらの差を考慮した割引料金が設定される。例えば、隣の駅近辺の代替CSを利用した際に余分に鉄道料金等が発生する場合に備えて、公共交通機関料金DB20から必要なデータを取得する。会員がこの代替CS提示によって代替CSを利用することで、利用するCSが分散し、特定のCSに利用が集中することを軽減できる。具体的な例は、実施例1として後で詳しく説明する。CS間相乗り提示部13は、同じ時間帯に同じCSに向かう会員どうしを仲介しシェアカーの相乗りを促すことによって、シェアカーが特定のCSに集中することを緩和させる機能を果す。CS混雑度判定部11によって、利用が集中していると判定されたCSに対して予約を受信した場合は特に相乗りを推奨して提示する。このとき、CS間相乗り仲介テーブル32を用い、相乗り希望者の条件をマッチングさせる機能も有する。相乗り希望条件がマッチした場合は、双方の会員に通知する。その通知に対して、運転者側と同乗者側が合意したことを条件に、割引料金が設定される。例えば、自宅付近のCSから駅近辺のCSに向かう会員が、同じ時間帯に駅に向かう会員を同乗させることで余分にかかった時間に応じて、利用料金の割引を受けることができるようにする。もちろん、利用料金も相乗りした会員間で分担するのでより経済的である。この相乗りの仲介においては、タクシーなどの相乗りと違い、会員どうしの相乗りなので、会員は、会員登録データから得られる様々なデータを元に希望する相乗りの希望条件を設定することができる。さらに、一度限りでなく定期的な相乗りを設定することも容易である。例えば、毎日の通勤時間に合わせて、駅のCSまで平日の7:00~7:30の間を常に相乗り希望とするなどである。また、同乗者をピックアップする場所は、原則、運転者または相乗り希望者の最寄のCSとする。こうすることで、運転者または相乗り希望者は、出発地と目的地のCSのIDを指定するだけですみ、会員どうしがピックアップ場所を検索するなど余分な手間が省ける。ただし、相乗りを予約せずに、たまたま通りかかったシェアカーに会員証のICカードを提示し、短距離のヒッチハイクのように利用することも可能である。乗せる側も同じカーシェアリングの会員なので身元が明らかで安心できる。この場合、ICカードに目的地等の希望条件を予め入力しておき、シェアカーのICカードリーダ部にタッチすることで、自動的にその希望条件が車内に表示されるようにしてもよいデジタルヒッチハイク。もちろん、運転者はシェアカーの車載器で所定の操作をすることで、車の窓を開けずに相乗りを拒否することもできる。なお、相乗りした場合の料金割引は、CS間相乗り料金調整テーブル31を用い、駅に直行した場合とピックアップに要した時間を考慮して設定される。具体的な例は、実施例2として後で詳しく説明する。CS利用時間分散提示部14は、CS混雑度判定部11によって、利用が集中していると判断されたCSの混雑する時間帯を抽出し、時間帯をずらすことでCSの利用が可能となるケースを提示する機能を果す。すなわち、あるCSが満杯或いは満杯になりそうな時間帯をCS利用状況DB23から抽出し、普段そのCSを利用している会員等に提示する。そして、可能であれば、その時間帯での利用を避けるように会員に促す。この提示に応じた会員には料金割引やポイント特典等を与えるようにする。このようにすることで、結果として、そのCSの利用集中を分散させることに役立つ。また、複数の商業施設を廻る場合や観光地などを廻る場合などのように、会員が複数のCSをある順序で廻ることが多いと判断されるようなときは、CS間を廻る順序を変えるように変更ルートを提示してもよい。いずれにしても、CS料金時間帯調整テーブル34を用い、提示された時差利用に対して割引や特典を提供するようにし、会員に特定のCSの時間差利用に対して協力を促す。具体的な例は、実施例3として後で詳しく説明する。オンデマンドバスルート提示部15は、CS利用状況DB23を参照し、ある特定のCSから別の特定のCSへの会員の移動が多いことが判定できる場合は、その区間にオンデマンドバスを運行させるかどうかの判断材料を与える機能を果す。このためには、あるCSから別のCSへの移動する確率を、CS利用状況DB23から、CS間移動確率テーブル35として作成し記録しておく。例えば、4つのCSがあるとし、あるCSから他のCSを一つ以上廻って元のCSに戻るルートは33通りあるが、その中で会員が特定のルートを利用する確率が他のルートに比較して高い場合は、そのルートは、オンデマンドバスルートの運行区間の候補とする。ここでいうオンデマンドバスとは、固定したバスルートを運行せずに、利用者の需要に応じて、臨機応変に運行ルートを定めることができるバスを指す。オンデマンドバスが運行できれば、結果として、そのルートにあたるCSへの負荷も減少することになる。具体的な例は、実施例4として後で詳しく説明する。上記のシステムの構成は、あくまで一例であり、一つの機能部処理部テーブルを更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。各機能部は、サーバ装置に内蔵されたCPUCentralProcessingUnitが、ROMReadOnlyMemoryまたはハードディスク等の記憶装置に格納されたコンピュータプログラムを読み出し、CPUにより実行されたコンピュータプログラムが、記憶装置に格納されたDBDataBaseやメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア例えば、入出力装置、表示装置、通信インターフェース装置を制御することによって実現される。また、本発明の実施例における各DBは、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わない。[データベース]図2と図3を用いて上記の各DBに格納されるデータについて説明する。図2は、CS設置情報DB22及びCS利用状況DB23の一例を示す図である。図3は、車両利用状況DB24及び会員利用状況DB25の一例を示す図である。CS設置情報DB22は、図2の上段に示すように、CSごとに、敷地内に駐車可能な車の台数駐車区画の数、設置場所の位置情報、最寄施設、近隣CSの情報を格納したDBである。CSの設置場所の位置情報は、図の例で示すように、緯度、経度場合によっては高度であってもよいし、地図上のブロック番号などでもよい。また、住所を含ませるとさらによい。CSは、一般の時間貸し駐車場や月極駐車場などを借り上げて使用する他、駅や大型施設の駐車場の一部を契約することによって提供される。最寄施設とは、そのCSを利用した利用者が徒歩で訪れる可能性が高い近隣の一以上の施設名例えば、駅名、商店街名、ショッピングセンター名、公共団体施設名、観光施設名等が格納される。当然、一つの施設が複数のCSの最寄施設に登録され得る。近隣CSとは、そのCSから所定の徒歩圏内例えば、5分以内又は公共交通手段を用いて短時間で移動できる圏内にあるCSのID識別子が格納される。なお、図示していないが、最寄施設が駅やバス停のCSに対しては、近隣CSは、その駅バス停の隣の駅バス停を最寄とするCSを含んでもよい。これらの情報は、CSが新設された時点で登録され、その後変更があるごとに更新される。図2下段のCS利用状況DB23は、CSごとに、毎日の利用台数入庫台数、出庫台数、平均駐車時間を記録したCS稼動情報23aと、入庫または出庫したシェアカー車両のID,その車両が入庫または出庫した日時,このCSの直前に利用したCSのIDCSfrom又はこのCSから出発して向かう先の目的地のCSのIDCSto,利用した会員のIDを時系列に記録した車両入出庫情報23bを含んだDBである。図示していないが、CS稼動情報23aは日単位だけでなく、時間帯単位の情報も含むものとする。CSfromまたはCStoは、CSから出庫または入庫した際の車両IDと時間を複数のCSで追跡することで求められる。このCS利用状況DB23を参照することで、CSの日々の利用状況や稼働率混雑度が求められる。また、このDBの情報を元に、車両ごと、会員ごとのデータを集計することもできる。図3上段の車両利用状況DB24は、車両ごとに、車両ID,車種、ナンバー,車体番号,定員,ボディカラー,走行距離などの車両固有のデータを含んだ車両登録情報24aと、車両が使用された日ごとに、利用者の会員ID,利用開始時間,利用開始時のCSのID、利用終了時間、利用終了時のCSのIDの各データとを含んだ車両利用情報24bとを格納したDBである。図3下段の会員利用状況DB25は、会員ID,氏名,住所,電話番号,メールアドレス,会費支払方法等の会員固有の登録情報25aと、利用した車両のID,利用開始時間、利用開始時出発時CSのID,その車両を返却した時間である利用終了時間、返却したCSのIDの各データを含んだ会員利用情報25bとを格納したDBである。図示していないが、登録情報25aには、性別、生年月日、趣味、喫煙の有無などその他のプロフィールを含むようにすることが好ましい。これらのプロフィール情報は、前述した相乗り仲介の際に使用される。以上、説明したDBの各データは、CS利用状況管理サーバ100だけでなく、カーステーションの運用サーバ図示せず及び各車両の記憶装置が日々の処理の際にデータを記録することにより、作成、更新、参照される。特にCS利用状況管理サーバ100はこれらのDBを参照し、処理に必要な後述する各種テーブルを作成し、参照、更新する。図4は、本発明の第1の実施例に係る代替CS提示の概念を示す図である。この図は、鉄道路線、隣接する駅A,駅B、住宅地等の複数のCS、および近隣の病院等の大型施設を模式的に表したものである。駅Aには急行が止まるため利用が集中するCS50、駅Bには急行が止まらないので比較的すいているCS51があり、病院には混雑するCS52があるとする。また、日常的にCS53a~53dからCS50に向かう車両が多くCS50が混雑し、CS54a~54cからCS52に向かう車両が多くCS52が混雑しているものとする。代替CS提示とは、このCS50やCS52に向かう車両を比較的すいているCS51に向かうように仕向け、CS50やCS52に駐車する車両をできるだけ減らすような方向で会員に提示することである。例えば、CS53dから出発し、CS50を目的CSとする会員には、車両を予約する際にCS50が混雑する可能性が高いことを示し、代替CSとしてCS51を利用することを推奨して提示する。予約の際、会員端末から所定の操作をするなどして、この代替提示に応じた会員は、CS53dから出発してCS51に向かい、そこから駅Bで電車に乗り目的駅に向かう。この場合、CS50からCS51へ変更することによる移動時間の増加、カーシェアリング利用料金移動時間に比例するものとするの増加、及び駅Bから駅Aへの鉄道料金の追加が発生するが、代替提示に応じた会員に対しては不利益にならないように割引料金や特典が提供される。また、CS54aから病院のCS52に向かう会員に対しては、同様にCS51を提示し、そこから病院向けのバスに乗ってもらうように促してもよい。この提示に応じた会員に対しても、同様に、移動時間の増加、及びバス料金の追加に応じて、不利益にならないようにカーシェアリングの割引料金や特典が提供される。この場合、バス料金を無料にし、バス会社にはその分をカーシェアリング会社から協力費として後で支払うようにしてもよい。このようにすることで、バス会社は、固定客の増加が見込まれ、カーシェアリング会社にとっても、顧客離れを防止するため新たなCSを設置するよりはコスト面でのメリットがある。図5は、本発明の第1の実施例に係る代替CS料金調整テーブルの一例を示す図である。上段に示すイメージ図では、自宅付近のCS55から駅に向かい、駅のCSで車を乗り捨てて都心方面に鉄道で出勤する場合を想定している。駅A,B,Cにはそれぞれ最寄のCS56、CS57,CS58があるが、この場合、CS55から最も近く便利なのはCS57であり、そこから駅Aに行き電車に乗るのが一番所要時間が短いとする。図5下段の代替CS料金調整テーブル30には、CS55から駅A,B,Cを利用した場合のそれぞれの所要時間の合計と料金の合計が示されている。また、駅Aを基準とし駅B,駅Cにはその差分が示されている。このデータは、公共交通機関料金DB20とCS設置情報DB22から得られる。代替CS提示部12は、CS57が所定の混雑度を超えていると判断したときは、CS57を利用すると考えられる会員に対して代替CSを提示する。提示するタイミングは、会員が専用サイトで予約を入れる際に目的地のCSを指定したとき、及び会員みずからが専用のサイトにアクセスし、CS混雑状況を検索したときに提示することが望ましい。また、会員の住所からCS57付近を日常的に利用する可能性の高い会員に電子メール等であらかじめ提示してもよい。この代替CS料金調整テーブル30の例からわかるように、駅AのCSを利用する場合が、所要時間、料金とも最も有利であるが、駅B,CのCSの混雑度に比較的余裕のある場合は、駅B、駅CのCSを使用した場合の割引料金を駅AのCSを利用しようとする会員に提示する。例えば、駅Bを利用すると、駅Aを利用した場合より所要時間で8分、料金も鉄道料金が加算され、通常では100円割高となる。しかし、所要時間の遅れ1分に対して割引15円を行うと、駅Bを利用した場合には料金は総額580円となり、駅Aを利用した場合よりも安くなる。駅Cを利用した場合も同様である。このような代替となるCSの割引料金を提示することで、顧客に駅B,駅CのCSも利用する動機付けを与え、結果としてCS57の混雑度を分散させることができる。図6は、本発明の第1の実施例に係る代替CS提示処理のフローを示す図である。このフローチャートは、前述した代替CS提示処理を簡単に表したものである。代替CS提示部12は、ますステップS10において、目的のCSの混雑度は所定の閾値1以上かを判断する。この所定の閾値1は、例えば、混雑度90以上のように予め設定しておく。次にステップS11において、同じ目的地駅などに、回り道をしても行ける近隣のCSがあるかどうかを判断する。ここで、CS設置情報DB22の位置情報、最寄施設、近隣CSの情報が参照される。そのようなCSがある場合には、ステップS12において、そのCSの混雑度が所定の閾値2例えば、50以下と判断される場合には、そのCSを目的CSの代替CSとして選択するステップS13。次に、ステップS14において、自宅付近のCSこれをCS0とするから、目的CSを経て目的地勤務先の最寄駅などに至るルートの所要時間、料金の総額を計算する。総額には鉄道料金も含まれる。さらに、ステップS15において、CS0→代替CS→目的地に至るルートの所要時間及び料金の総額を計算する。そして、ステップS16において、代替CS利用の場合、所定の割引率を乗じて割引料金を計算する。このようにして求めた料金、所要時間を比較したデータを会員に提示する。これを提示された会員は、会員端末40から所定の操作をしてこの提示に対して応ずる旨を送ることで、割引価格の対象であるとシステムから見なされる。図7は、本発明の第2の実施例に係るCS間相乗り提示の概念を示す図である。CSの設置環境は、図4と同じである。図示するように、ここでも、混雑度の高い駅Aを最寄とするCS50に、周辺のCS53a~53e、総称する場合は53と呼ぶから多くの車両が向かうケースを考える。会員がCS50に向かうために専用サイトから予約を行なおうとする際、CS50が混雑していることが判定されると、本システムのCS間相乗り提示部13は、CS53からの会員に対して、相乗りを提示し、その仲介をする。CS間相乗り提示部13は、CS間相乗り仲介テーブル32を検索し、運転者と同乗者が登録した相乗り希望条件がマッチすれば、両者に対して相乗りの提示を行い、両者が合意すれば相乗りが成立する。この場合の相乗りは、会員どうしがCS間で相乗りすることを原則とする。図7の例では、CS53aから出発した車両が、同じ時間帯にCS53bから出発してCS50に向かおうとする会員をピックアップしてからCS50に向かう様子を示している。CS53c、CS53dから出発しようとしている車両についても同様である。また、混雑度の高い病院のCS52に向かおうとしているCS54a,CS54b54cからの車両やCS50から病院のCS52に向かう車両に対しても、同様に相乗りが推奨される。なお、CS50から、特には混雑してないCS56aやCS56bに向かう場合は、相乗りは推奨されない。CS50に駐車している車両は、それぞれ別々に出庫し、一台でも多く出てもらったほうがCS50の混雑緩和に役立つからである。もちろん、目的とするCSの混雑度によらず、常に相乗りを仲介するようにしてもよい。この場合は、CSの混雑緩和の目的ではなくなるが、会員の費用削減やCO2削減には貢献することになるからである。ただし、この場合は次図で説明する相乗りの割引料金は適用されない。図8は、本発明の第2の実施例に係る相乗り料金調整テーブル31の一例を示す図である。相乗り料金調整テーブル31は、この例では、CS0を出発した車両がそのまま最寄駅に向かった場合と、CS1またはCS2、あるいはCS1とCS2の両方にピックアップに向かった場合の所要時間と料金をそれぞれ保持している。例えば、CS0からCS1に回り道して駅に向かった場合、CS0→CS1で5分、CS1から駅まで13分かかるとすると、計18分となり、直接CS0から最寄駅に向かった場合と比べて8分のロスである。また、料金も一般的には乗車時間に比例するので、1分10円とすれば、80円が余分にかかる計算になる。この差分料金は、ピックアップされた側が支払うようにしてもよい。しかし、混雑するCSに相乗りして向かう場合は、割引料金が適用されるのでその負担は軽くなる。例えば、その割引率を1分5円と設定すると、8分×5円=40円が割引となる。この割引は、図のように、ピックアップした側に還元されるようにしてもよいし、両者で分配するようにしてもよい。同じようにして、CS1とCS2両方でピックアップした場合、所要時間は10分になったとすると、通常料金100円、割引-50円となるが、この場合、2ヵ所を回って、より運転者の負担が大きいので、運転者にはαの割引を行うようにしてもよい。図9は、本発明の第2の実施例に係るCS間相乗り管理テーブル32の一例を示す図である。この図は、既に説明したように、相乗り希望条件を運転者側と同乗者側に分けて管理するテーブルを示したものである。CS間相乗り提示部13は、このテーブル内を検索し、希望条件が合致した案件、又はほぼ近い案件をマッチング候補としてそれぞれの会員に提示する。会員のプロフィール年齢、性別、喫煙の有無等を、会員登録情報に保存していれば、会員は自己のプロフィールをいちいち仲介依頼時に入力する必要はない。マッチングの結果は、図9下段の画面のように双方の会員に通知される。図10は、本発明の第3の実施例に係るCS間のルート変更提示の概念を示す図である。この実施例では、特定の時間帯に混雑するCSを複数廻る場合について考える。カーシェアリングは、複数のショッピング施設を廻り、たくさん買い物をしたり大きな荷物を運ぶような場合に便利である。大型のショッピング施設にCSを設置しておけば、車両をその施設で乗り捨てることができ、ショッピングをした後に別の車両に乗り換えれば、ショッピング中の利用料金はかからない。図10ではこのようなカーシェアリングの利用形態の一例を示している。実線が希望ルート、点線が代替ルートを示す。図示するように、例えば、街中のデパートにCS1、郊外のホームセンターにCS2、よく利用するスーパーマーケットにはCS3、よく食事をするレストランタウンにCS4が設置されているとし、会員は施設を順に廻り、最後に自宅近くのCSに戻るとする。このような場合、目的施設のCSのIDを会員が入力するだけで、本システムは、それぞれの施設のCSの混雑する時間帯を調べ、会員に対して、その混雑する時間を施設ごとに提示することができる。例えば、デパートのCS1は混雑時間帯が10~14時、ホームセンターのCS2は混雑時間帯が13~17時、スーパーマーケットのCS3は混雑時間帯が15~19時、レストランタウンのCS4は混雑時間帯が18~22時のように、会員が車両を予約する際にCSの混雑時間帯を提示する。また、各施設を訪れたい順予定ルートを入力すると、そのルートが混雑する時間帯の施設を含んでいる場合、その施設を利用する時間帯をずらした代替ルートを提示することもできる。図11は、本発明の第3の実施例に係るCS間のルート変更推奨画面の一例を示す図である。この例では、前図の4つの施設へのおおよその到着時刻や出発時刻を会員が入力すると、本システムは、その時間帯でのCSの混雑度を表示する。そして、混雑する時間をなるべく避けるように図示するような代替ルートも提示することができる。各CS間の移動距離車での所要時間や混雑状況は、CS設置情報DB22やCS利用状況DB23を参照することで取得できる。このようにすることで、特定のCSに混雑する時間帯がある場合には、その時間をずらすように会員に提示するので、利用が集中するCSの混雑度の軽減に役立つ。なお、移動距離は必ずしも直線距離には比例しない。徒歩または車で移動できる道路が通じてない場所は、例え直線距離が短くとも移動距離は長くなる。また、CS間またはCSと最寄施設間の移動距離は、徒歩で移動する場合と車での移動する場合で別々に存在する。図12は、CSと最寄施設間の移動距離の概念を示す図である。各CSには最寄の施設がDBに登録されており、この例では、CS1は駅、CS2は飲食店街、CS3は大型スーパー、CS4はホームセンターが最寄の施設である。当然、最寄の施設は複数あってもよい。また、ある施設にとっても最寄CSは一つではない。所定の徒歩圏例えば5分以内にあるCSは、その施設の最寄のCSとなる。なお、駅のCSのような表現は、代表的な最寄CS徒歩での移動距離が最も近いCSを表したものである。図示するように、所定の徒歩圏を半径rの円で表すと、円内にあるCSがすべて最寄のCSとなる。この例では、駅の最寄CSはCS1とCS2、飲食店街の最寄CSは、CS2とCS3,大型スーパーの最寄CSは、CS3とCS4,ホームセンターの最寄CSはCS4のみである。図13は、本発明の第3の実施例に係るCS稼働率テーブル33及びCS料金時間帯調整テーブル34の一例を示す図である。図13上段のCS稼働率テーブル33は、前図で示した関係にあるCSと最寄施設と稼働率混雑度を時間帯ごとに示している。また、このテーブル中にある補完CSとは、あるCSが満杯になったときに代替となる所定の徒歩圏内にあるCSを表している。例えば、最寄施設が駅のCS1の補完CSは、CS2であり、CS2の補完CSは、CS1とCS3である。図13の下段のCS料金時間帯調整テーブル34は、各CSに車を乗り捨てた場合の、その時点までの単位時間あたりの料金表34aと、そのCSから出庫した場合の料金表34bを示している。乗り捨てた場合の料金と出庫した場合の料金に差を設けるのは、混雑するCSへの乗り入れは料金が高く、逆に混雑するCSから出庫する場合は料金を安くするためである。また、混雑するCSの代替CSへの乗り入れはその時間帯では安くする。すなわち、混雑するCSへの入庫には利用者に負担を求め、逆に混雑するCSから早く出庫してもらえる場合には、負担を軽くする。このようにすることで、CSの混雑度を分散することができる。CS稼働率テーブル33の網掛けで示した部分は、稼働率が90以上となっている時間帯を示している。また、CS料金時間帯調整テーブル34の網掛け部分は、標準料金ここでは単位時間あたり100円とするでなく、割引または割増料金を適用する時間帯を示している。このように、料金を時間帯によって変更するのはCSの混雑度を分散させるためである。混雑するCSにその時間帯に乗り捨てる場合は、乗捨て料金割増料金が適用され、逆に、混雑するCSからその時間帯あるいは混雑時間帯前に出庫する場合は、出庫料金割引料金が適用される。例えば、CS1は、8:00~10:00と10:00~12:00には稼働率100、すなわち満杯なので、この時間に並んでしかも乗り捨てる場合は、10の割増料金が発生する。逆に、この時間帯に出庫する場合は、10の割引料金が適用される。この割引設定は、稼働率90以上になる時間帯のCSへ乗り捨てると、90から1増えるごとに1円割増、出庫すると、1あたり1円割引となる。また、稼働率90以上になる時間帯のCSの補完関係ある稼働率50以下のCSへ乗り捨てると、1あたり1円割引となる。もちろん、このような料金設定は環境に合わせて柔軟に変更できることは言うまでもない。オンデマンドバスとカーシェアリングは、競合関係にあると言われている。カーシェアリングは、短距離間での複数の目的地への移動や、大きな荷物の有る場合の移動に優れており、オンデマンドバスは、駐車場のないところへの移動や飲酒者高齢者子供の移動に優れている。一方、カーシェアリングは、利用区域が5分程度の徒歩圏内になければならないという弱点があり、オンデマンドバスは、運行エリア外へ移動できないという弱点がある。ここでは、オンデマンドバスの運行計画作成のために、CSの利用状況のデータを利用し、一方、CSの負荷分散のために、オンデマンドバスを運行させるという両者に補完関係があることについて説明する。図14は、本発明の第4の実施例に係るオンデマンドバスルート提示の一例を示す図である。この図には、駅Aの近辺にあるCS1,観光施設であるお寺の近辺にあるCS2,ミュージアムのCS3,ランドマークのタワーのCS4を示している。既に述べたように、本システムでは各CSの利用状況を出入りする車両およびその利用者を詳細に逐次記録するので、その蓄積されたデータを利用して、オンデマンドバスの運行エリアや運行ルートの計画立案に役立てる。例えば、図示するように、駅前等で利用の集中するCS1から、CS2、CS3、CS4へと移動するカーシェアリングの車両が多いことがCS利用状況DBから判定できたとすると、そのルートをオンデマンドバスの運行区間の候補とする。このためには、次の図で説明するCS間移動確率テーブルを利用する。図15は、本発明の第4の実施例に係るCS間移動確率テーブル35の概念を示す図である。CS間移動確率テーブル35は、ある地域内のCS全てについてCS間で移動する確率を記録したものである。カーシェアリングの車両は、必ず、CS間を移動するという特性を利用したものである。すなわち、CS間の車両の移動を分析することで人の流れをある程度知ることができる。CS間移動確率テーブル35の上段では、あるCSから出発した車両が次に到着したCSの割合を示している。例えば、CS1からCS2に移動した車両は、CS1から出発した車両の総数100のうち25台あったことを示している。この表の下段には、その割合をで示している。この数値を統計的に処理することで、CS間の移動確率を求めることができるが、ここでは、説明を簡単にするため、単に上の表の数字をで示し移動確率としている。例えば、CS1からCS2に移動する確率は25、CS1からCS3に移動する確率は5である。ここで、CSiからCSjに移動する確率をPijと表すと、CS1からCS2,CS3,CS4の順に移動し、最後にCS1に戻る確率P12341は、P12P23P34P41となる。CS1から、一以上の他のCSを廻って再びCS1に戻るルートは、図15の右の図で示すように33通りあるが、このすべてのルートに対して移動確率を計算する。そのうち、例えば、4つのCSすべてを廻るルートは6通りあり、その移動確率を計算すると、左下の計算になる。この例では、P12341が0.0330となり、他のルートに比べ圧倒的に大きいことがわかる。このようにして、様々なCSの組み合わせのルートに対して移動確率を求めて比較することで、オンデマンドバスの運行ルートの候補をみつけることができる。本システムのオンデマンドバスルート提示部15は、このような様々なCSの移動確率を計算し、移動確率の高いものを提示する。特に、混雑するCSのデータを優先的に使用することで、そのCSを運行経路に含んだオンデマンドバスを走行させれば、バスの需要が見込まれ、かつ実際にオンデマンドバスがそのルートに運行されれば、利用負荷の高いCSの負荷軽減にも役立つ。上記の発明の実施例では、カーステーションCSの利用状況を逐次記録することで、特定のCSに需要が集中することを軽減させることを目的とした。しかし、実施例4の例でもわかるように、本システムの有用性はそれだけにとどまらない。特にカーステーションは、これからの社会において、人々が移動するためのキースポットとなる可能性があり、CSのデータを集めることで、人物の移動の流れを把握し、様々な場面に利用することが可能となる。以上、実施形態実施例を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。"