ネットワークに接続された第1のサーバと第2のサーバ、および前記第1のサーバと前記第2のサーバのいずれにも接続可能なクライアントからなるクループ定義管理システムであって、前記第1のサーバは、前記第1のサーバを利用可能な各ユーザについての第1のIDの情報、および各ユーザのグループ定義に係る情報を保持する第1のユーザ管理テーブルと、前記クライアントを介したユーザからの要求に応じて前記第1のIDにより当該ユーザの認証を行う第1の認証部を有し、前記第2のサーバは、前記第2のサーバを利用可能な各ユーザについての第2のIDの情報、および各ユーザのグループ定義に係る情報を保持する第2のユーザ管理テーブルと、前記クライアントを介したユーザからの要求に応じて前記第2のIDにより当該ユーザの認証を行い、また、指定されたユーザが前記第2のサーバの正当な利用者であるかの問い合わせに対して、正当な利用者である場合には前記第2のユーザ管理テーブルから取得した当該ユーザについての前記第2のIDの情報を応答する認証インタフェースを有する第2の認証部とを有し、前記第1のサーバは、さらに、前記第1の認証部による認証を受けたユーザが利用する前記クライアントからの要求に応じて、前記第2のサーバに対して当該ユーザが前記第2のサーバの正当な利用者であるかの問い合わせを行い、前記第2のサーバから応答された当該ユーザについての前記第2のIDを、当該ユーザについての前記第1のIDと関連付けて前記第1のユーザ管理テーブルに登録する認証連携部を有することを特徴とするグループ定義管理システム。請求項1に記載のグループ定義管理システムにおいて、前記第2のサーバの前記第2の認証部は、指定されたユーザが前記第2のサーバの正当な利用者であるかの問い合わせを受けた際に、当該ユーザが前記第2の認証部による認証を受けていない場合は、前記クライアントを介して当該ユーザに対して前記第2のサーバに対する認証処理を行うよう要求することを特徴とするグループ定義管理システム。請求項1または2に記載のグループ定義管理システムにおいて、前記第1のサーバは、さらに、前記第1のユーザ管理テーブルにおける前記第1のIDについてのグループ定義の変更内容に基づいて、前記第2のIDについてのグループ定義を更新するための更新情報を生成するグループ管理部を有することを特徴とするグループ定義管理システム。請求項3に記載のグループ定義管理システムにおいて、前記第2のサーバは、さらに、前記第2のユーザ管理テーブルにおける前記第2のIDについてのグループ定義を管理するためのユーザ管理インタフェースを有し、前記第1のサーバの前記グループ管理部は、前記更新情報に基づいて、前記第2のサーバの前記ユーザ管理インタフェースにより、前記第2のユーザ管理テーブルにおける前記第2のIDについてのグループ定義を更新することを特徴とするグループ定義管理システム。請求項4に記載のグループ定義管理システムにおいて、前記第1のサーバの前記グループ管理部は、前記第2のサーバの前記第2のユーザ管理テーブルにおける前記第2のIDについてのグループ定義を管理する権限を有するユーザが、前記第1のサーバの前記第1の認証部により認証を受けた後、当該ユーザが利用する前記クライアントからの要求に応じて、前記第2のサーバの前記ユーザ管理インタフェースにより、前記第2のユーザ管理テーブルにおける前記第2のIDについての現状のグループ定義の情報を取得し、取得した現状のグループ定義の情報と、前記第1のユーザ管理テーブルにおけるグループ定義の情報とに基づいて前記更新情報を生成することを特徴とするグループ定義管理システム。社員のコミュニケーションツールとして外部のSNSサービスを利用する場合、情報漏洩等の観点から、社員等の関係者のみが参加できるコミュニティやグループの中でコミュニケーションを行うよう制限するのが望ましい。この点、上記のようなSSOによる認証の仕組みでは、例えば、社内システムにログインすることで、再度のログイン処理を要さずに外部のSNSサービスを利用するということが可能であるものの、SNSサービスにおいて社員等の関係者のみが参加することができるようなコミュニティやグループを形成することを可能とするものではない。また、例えば、社員が自宅等で業務外にSNSサービスを利用する場合は、原則として社内システムにアクセスすることができないことから、そもそも社内システムとの間でのSSOの仕組み自体を利用することができない。通常、企業等の社内システムにおいては、社員のユーザIDの登録削除やグループの定義などの管理は、退職や異動等の人事情報と連携して行われている。そこで、外部のSNSサービスにおいても、社内システムで管理されているユーザ情報部署等のユーザのグループに係る情報を利用参照してコミュニティやグループを形成することが考えられる。しかしながら、このような形で社内のユーザ情報を外部のSNSサービス当該企業がその管理等についてコントロールすることができないサービスに連携させることは、インフラの整備の面で負担が大きい。そこで、外部のSNSサービスにおいて、管理者等が通常の運用手順に則って、社員のみが参加することができるコミュニティやグループを直接作成するということが考えられる。この場合、社内システムのユーザ情報をSNSサービスに連携させるインフラを整備する必要はない。しかしながら、この場合は、社員の人事異動等に伴ってユーザ情報に追加変更等があった場合に、管理者等がその都度SNSサービスにおけるユーザ情報に反映させてメンテナンスする必要があるなど、管理者等の作業負担が大きく、また、反映漏れなどが生じる可能性もある。また、この場合、管理者等は、社内における各社員のユーザIDと、当該社員のSNSサービスにおけるユーザIDとの対応付けを把握しておくことで、社内でのユーザIDについてのグループ定義の情報に基づいて、外部のSNSサービスにおけるユーザIDについてのグループ定義を行うことができる。このとき、例えば、管理者等が各社員に対して外部のSNSサービスにおけるユーザIDを問い合せて聞き出した上で、社内におけるユーザIDと対応付けて登録するという手法では非常に効率が悪い。一方、例えば、各社員がSNSサービスで利用するユーザIDの情報を別途申告したり登録したりすることで社内のユーザIDとの対応付けを把握するという手法も考えられるが、申告漏れや虚偽の申告などにより、SNSサービスにおいて利用するユーザIDについての正確な情報を得ることができない。そこで本発明の目的は、社内システム等の内部のサイトにおけるユーザIDと外部のサイトのSNSサービス等におけるユーザIDとの対応を容易に取得し、また、内部のサイトにおけるユーザIDのグループ定義の情報を外部のサイトのSNSサービスにおけるコミュニティ等を形成するユーザIDのグループ定義の情報に容易に反映させることが可能なグループ定義管理システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。本発明の代表的な実施の形態によるグループ定義管理システムは、ネットワークに接続された第1のサーバと第2のサーバ、および前記第1のサーバと前記第2のサーバのいずれにも接続可能なクライアントからなるクループ定義管理システムであって、以下の特徴を有するものである。すなわち、前記第1のサーバは、前記第1のサーバを利用可能な各ユーザについての第1のIDの情報、および各ユーザのグループ定義に係る情報を保持する第1のユーザ管理テーブルと、前記クライアントを介したユーザからの要求に応じて前記第1のIDにより当該ユーザの認証を行う第1の認証部を有し、前記第2のサーバは、前記第2のサーバを利用可能な各ユーザについての第2のIDの情報、および各ユーザのグループ定義に係る情報を保持する第2のユーザ管理テーブルと、前記クライアントを介したユーザからの要求に応じて前記第2のIDにより当該ユーザの認証を行い、また、指定されたユーザが前記第2のサーバの正当な利用者であるかの問い合わせに対して、正当な利用者である場合には前記第2のユーザ管理テーブルから取得した当該ユーザについての前記第2のIDの情報を応答する認証インタフェースを有する第2の認証部とを有する。また、前記第1のサーバは、さらに、前記第1の認証部による認証を受けたユーザが利用する前記クライアントからの要求に応じて、前記第2のサーバに対して当該ユーザが前記第2のサーバの正当な利用者であるかの問い合わせを行い、前記第2のサーバから応答された当該ユーザについての前記第2のIDを、当該ユーザについての前記第1のIDと関連付けて前記ユーザ管理テーブルに登録する認証連携部を有することを特徴とするものである。本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。本発明の代表的な実施の形態によれば、社内システム等の内部のサイトにおけるユーザIDと外部のサイトのSNSサービス等におけるユーザIDとの対応を容易に取得することが可能となる。また、内部のサイトにおけるユーザIDのグループ定義の情報を外部のサイトのSNSサービス等におけるコミュニティやグループを形成するグループ定義の情報に容易に反映させることが可能となる。これらにより、外部のサイトのSNSサービス等において、社員など内部のサイトの特定のユーザのみがメンバーとして参加することができ、社内コミュニケーションを行うことが可能なコミュニティやグループを容易に形成することが可能となる。以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。本発明の一実施の形態であるグループ定義管理システムは、企業等において外部のSNSサービス等を社内コミュニケーション用に活用することを可能とするため、外部のSNSサービス等において特定のグループの社員等のみが参加することができるコミュニティやグループを形成することを支援するシステムである。本実施の形態では、社内システム等の内部サイトにおける各ユーザ社員等のユーザID内部サイトでのユーザIDであり、以下では内部IDと記載する場合があると、SNSサービス等の外部サイトにおいて各ユーザが利用するユーザID外部サイトでのユーザIDであり、以下では外部IDと記載する場合があるとの対応関係を容易に取得可能とする。これにより、内部サイトの管理者等が、社内等における部署やプロジェクト等に基づくユーザ社員のグループ定義に基づいて、SNSサービス等の外部サイト内部サイトの企業等が管理や運用を原則としてコントロールできないサイトを含むにおいて、対応するユーザ社員のみが参加することができるクローズドのコミュニティやグループを形成し、またこれに含まれるメンバーの情報をメンテナンスすることを支援する。外部サイトが、ユーザのグループ定義の操作に係るコマンドやAPIApplicationProgrammingInterface等の外部インタフェースを有している場合は、これらを利用して自動的に外部サイトにおけるグループ定義の処理を行うことも可能である。内部サイトは、社員等の各ユーザについて、外部サイトから対応する外部IDの情報を取得する。ここで、外部サイトは外部インタフェースとして認証APIを有しており、内部サイトはこれを利用して外部IDの情報を取得するものとする。ここでの認証APIは、ユーザIDとパスワードを指定して認証処理を行うものではなく、対象のユーザが、当該サイト外部サイトにおける正当な利用者であるか否かを応答するものであり、この応答内容には、対象のユーザの外部IDの情報が含まれる。認証APIは、他のWebサイトと認証情報を連携して動作することが想定されるSNSサービスなどでは、細かな実装方法は異なるものの、一般的に有するインタフェースである。通常は、当該認証APIは、Webサイト間の連携においていわゆるSSOを実現するために用いられる。例えば、あるWebサイトA例えば交流ゲームサイトでの認証システムが、他のWebサイトB例えば提携するSNSサイトが有する認証APIを利用して、対象のユーザがWebサイトBにおいて何らかの権限を持っていることを確認できれば利用を許可する、というような場合に用いられる。なお、ここでの利用は、WebサイトBではなくWebサイトAの利用が対象となる。従って、従来の認証APIの利用形態は、WebサイトAにこれからログインするという状況で、WebサイトBの認証情報を取得するために用いられるものである。これに対し、本実施の形態では、後述するように、内部サイト、外部サイト双方に既にログインしている状態で、さらに、外部サイトから認証情報外部サイトでログインしている外部IDの情報が含まれるを取得するために用いるという点が異なっている。<システム構成>図1は、本発明の一実施の形態であるグループ定義管理システムの構成例について概要を示した図である。グループ定義管理システム1は、例えば、企業における社内システム等の内部サイトを構成するサーバシステムである内部サーバ10が、社内LANLocalAreaNetwork等の内部ネットワーク30に接続される構成と、Facebook等のSNSサービスからなる外部サイトを構成するサーバシステムである外部サーバ20が、インターネット等の外部ネットワーク40に接続される構成とを有する。内部ネットワーク30には、社員等のユーザが業務上利用するPCPersonalComputer等の情報処理端末である内部クライアント61が接続され、外部ネットワーク40には、社員等が自宅などで個人として利用するPC等からなる外部クライアント62が接続されている。なお、内部クライアント61からは、内部ネットワーク30に対するアクセスが可能であるとともに、ゲートウェイサーバ50等を介して外部ネットワーク40に対するアクセスも可能であるものとする。また、外部クライアント62からは、原則として外部ネットワーク40に対するアクセスのみが可能であるが、例えば、VPNVirtualPrivateNetworkなどを利用して、ゲートウェイサーバ50を介して内部ネットワーク30に対するアクセスを可能とするように構成してもよい。内部サーバ10は、社内システム等の内部サイトを構成するサーバシステムであり、例えば、図示しないOSOperatingSystemやWebサーバプログラム等のミドルウェア上で稼働するソフトウェアプログラムとして実装される内部認証部11、内部サイトアプリケーション12、認証連携部13、およびグループ管理部14などの各部を有する。また、データベース等により構成される内部ユーザ管理テーブル15を有する。この内部ユーザ管理テーブル15は、内部サーバ10内部サイトにアクセスして内部サイトアプリケーション12によるサービス社内システムを利用することができる社員等のユーザに係るユーザ情報を保持する。ユーザ情報には、例えば、ユーザID内部IDやパスワード等の他に、各ユーザが属する部署やプロジェクト、社内活動などのグループやコミュニティの情報であるグループ定義の情報が含まれる。内部認証部11は、内部クライアント61もしくは外部クライアント62を介して社員等のユーザが内部サーバ10内部サイトにアクセスする際のログイン認証に係る処理を行う。このとき、内部IDやパスワード等のユーザ情報を得るため、内部ユーザ管理テーブル15を参照する。内部サイトアプリケーション12は、内部サイトで提供するサービスに係る処理を行うアプリケーションプログラムである。例えば、図示しないWebサーバプログラム上で稼働するWebアプリケーションとして実装され、ユーザは、内部クライアント61もしくは外部クライアント62上の図示しないWebブラウザを利用して内部サイトアプリケーション12により提供されるサービスを利用することができる。認証連携部13は、内部認証部11を介してログインしたユーザについて、外部サーバ20外部サイトとの間で上述した認証APIを用いて認証情報の連携を行い、当該ユーザの外部サーバ20におけるユーザID外部IDに係る情報を取得する。取得した外部IDの情報は、当該ユーザの内部IDの情報と対応付けて内部ユーザ管理テーブル15に登録する。すなわち、内部ユーザ管理テーブル15では、社員等のユーザについて、ユーザ情報として、社内システムで用いる内部IDと、外部のSNSサービスを利用する際に用いる外部IDとの対応関係についても保持する。なお、各社員等のユーザは、原則として全員が内部IDを有するが、外部IDについては、ユーザによっては外部のSNSサービスを利用しないために有していない、もしくは社内コミュニケーション用には利用せず、個人的利用のみとすることから、登録されない場合もある。また、外部のSNSサービスで複数のユーザIDを有するユーザについては、社内コミュニケーションのために用いる外部IDのみ複数であってもよいが登録されるものとする。グループ管理部14は、内部ユーザ管理テーブル15での内部IDのグループ定義の情報に基づいて、対応する外部IDのグループ定義についてのメンテナンス情報グループの新規追加や、削除、変更などの指示情報を出力する。当該メンテナンス情報に基づいて、例えば、管理者等が、外部サーバ20に対してコミュニティやグループの新規追加や削除、変更、およびこれらのコミュニティやグループに対する外部IDの新規追加や削除、変更などのグループ定義に係るメンテナンス処理を行うことができる。なお、外部サーバ20が、ユーザ情報のメンテナンスを行うためのコマンドやAPI等の外部インタフェースを有している場合は、これらを利用してメンテナンス情報に基づいて外部サーバ20における外部IDのグループ定義についてのメンテナンス処理を自動的に行うことも可能である。外部サーバ20は、SNSサービス等の外部サイトを構成するサーバシステムであり、内部サーバ10と同様に、例えば、図示しないOSやWebサーバプログラム等のミドルウェア上で稼働するソフトウェアプログラムとして実装される外部認証部21、外部サイトアプリケーション22、およびユーザ管理インタフェースI/F23などの各部を有する。また、データベース等により構成される外部ユーザ管理テーブル24を有する。この外部ユーザ管理テーブル24は、外部サーバ20外部サイトにアクセスして外部サイトアプリケーション22によるSNSサービスを利用することができるユーザについての、外部IDやパスワード等を含むユーザ情報を保持する。外部認証部21は、外部クライアント62もしくは内部クライアント61を介して社員等のユーザが外部サーバ20外部サイトにアクセスしてSNSサービスを利用する際のログイン認証に係る処理を行う。このとき、外部IDやパスワード等のユーザ情報を得るため、外部ユーザ管理テーブル24を参照する。なお、外部認証部21は、API等による外部インタフェースとして、上述した認証APIを有するものとする。外部サイトアプリケーション22は、外部サイトで提供するSNSサービスに係る処理を行うアプリケーションプログラムである。例えば、図示しないWebサーバプログラム上で稼働するWebアプリケーションとして実装され、ユーザは、内部クライアント61もしくは外部クライアント62上の図示しないWebブラウザを利用して外部サイトアプリケーション22により提供されるSNSサービスを利用する。なお、本実施の形態では、外部サイトによって提供されるサービスをSNSサービスとしているが、これに限られず、社員等以外の多数のユーザが利用し、ユーザ毎にグループ等が形成されるようなサービスであれば適用することができる。ユーザ管理インタフェースI/F23は、外部ユーザ管理テーブル24に登録され管理されているユーザIDや、SNSサービスにおけるグループやコミュニティなどのグループ定義の情報などを含むユーザ情報を管理参照、登録、削除、変更等するためのコマンドや、APIなどの公開された外部インタフェースである。当該インタフェースは、例えば、管理者等の特定のユーザがログインした上で利用可能なものであってもよいし、ユーザを介さずに鍵やパスワード等を用いて直接アクセス可能なものであってもよい。なお、外部サーバ20によってはこのようなプログラムやスクリプト等から利用可能なインタフェースを有さず、Webブラウザ等での操作による手動でのインタフェースしか有していないなどの場合もあるが、そのような外部サーバ20であっても適用することができる。<処理の流れ外部ID情報取得>以下では、内部サーバ10が、外部サーバ20から、特定のユーザについての当該外部サーバ20において社内コミュニケーションのために使用する外部IDの情報を取得し、内部IDと対応付けて内部ユーザ管理テーブル15に登録する際の処理について説明する。図2は、内部サーバ10が外部サーバ20から対応するユーザの外部IDの情報を取得して登録する際の処理の流れの例について概要を示した図である。まず、内部クライアント61もしくは外部クライアント62は、Webブラウザを介して社員等のユーザから外部サーバ20に対する外部ID図2の例ではユーザαを指定したログイン要求を受け付けS01、外部サーバ20に対してユーザαのログイン要求を送信するS02。ログイン要求を受信した外部サーバ20では、外部認証部21により外部ユーザ管理テーブル24を参照して認証処理を行いS03、Webサーバプログラムによりユーザαの当該セッションについてのセッション情報を生成して、認証結果とともに内部クライアント61に応答する。さらに、内部クライアント61もしくは外部クライアント62は、同様に、Webブラウザを介して社員等のユーザから内部サーバ10に対する内部ID図2の例ではユーザAを指定したログイン要求を受け付けS04、内部サーバ10に対してユーザAのログイン要求を送信するS05。ログイン要求を受信した内部サーバ10では、内部認証部11により内部ユーザ管理テーブル15を参照して認証処理を行いS06、WebサーバプログラムによりユーザAの当該セッションについてのセッション情報を生成して、認証結果とともに内部クライアント61に応答する。なお、以降の処理では、内部クライアント61は、内部サーバ10へのアクセス外部サーバ20へのアクセスについても同様の際に当該セッション情報Aを提示することで、当該アクセスが、ユーザAとして認証されているユーザによるものであることを示すものとするが、これに限らず、例えば、内部サーバ10に対してアクセスする毎に内部IDとパスワードを提示したり、公開鍵例えばクライアント証明書等による認証を行うような方式であってもよい。その後、自動もしくはユーザからの指示に基づいて、内部クライアント61は、内部サーバ10に対して、外部サーバ20における外部IDの取得要求を送信するS07。外部IDの取得要求を受信した内部サーバ10では、当該アクセスに伴う情報セッション情報A等により、アクセスしているユーザがユーザAであることを確認できる状況で、認証連携部13により、外部サーバ20に対して外部IDの取得要求認証APIの実行要求を送信するS08。ここでは、認証連携部13は、例えば特許文献1や非特許文献1などの従来技術における認証の連携の手法と同様に、例えば、予め内部サーバ10と外部サーバ20との間でシェアされた鍵等の情報に基づいて、チャレンジアンドレスポンス方式によるチャレンジとして外部IDの取得要求を生成する。生成した取得要求は、例えば、内部クライアント61上のWebブラウザでのリダイレクトにより間接的に外部サーバ20に対して送信される。外部IDの取得要求を受信した外部サーバ20では、外部認証部21により、対象のユーザが外部サーバ20上において正当なユーザであるか否かを確認するための認証APIを発行する。このとき、対象のユーザが外部サーバ20に既にログインしている場合は、外部サーバ20は、当該アクセスに伴う情報セッション情報α等により、当該ユーザに何ら問い合わせることなく、内部サーバ10に対して応答を返すことも技術的には可能であるが、外部サーバ20にログインしていない場合は、例えば、ログインを促したり、内部サイトから問い合わせがきている旨を当該ユーザに通知するとともに、当該ユーザの外部サーバ20上での権限に係る情報を内部サーバ10に送信することに対して諾否を確認するようにしてもよい。本実施の形態では、外部サーバ20は、当該アクセスにおいて、対象のユーザの情報セッション情報α等が得られているため、当該ユーザはユーザαであることが分かっていることになる。従って、例えば、内部サーバ10からの問い合わせに対して、外部IDユーザαに係る情報の提供を承認するか否かをWebブラウザ上での表示を介してユーザに問い合わせS09、承認を得るようにしてもよいS10。セッション情報αの情報を受信した外部サーバ20の外部認証部21は、セッション情報αに基づいて、対応する外部IDユーザαの情報を含む認証情報を取得しS11、セッション情報αに対応するユーザの外部IDはユーザαであることの証明情報を内部サーバ10に対して送信する。ここでも、例えば、内部クライアント61上のWebブラウザでのリダイレクトにより、内部サーバ10に対して間接的にユーザαであることの証明情報を送信する。なお、内部サーバ10と外部サーバ20との間で直接通信を行うことで、より詳細な情報を受け渡したり、また、外部サーバ20から見て内部サーバ10がこれらの情報の受け渡しについて許可するよう設定されているものであるか否かを確認するようにしてもよい。これにより、例えば、外部サーバ20において、事前に登録されたサーバにのみ応答するよう制限が設けられているような場合であっても対応することが可能となる。外部IDがユーザαであることの証明情報を受信した内部サーバ10では、認証連携部13により、取得した外部IDの情報を、内部IDの情報と対応付けて内部ユーザ管理テーブル15に登録するS12。これにより、内部ユーザ管理テーブル15において、業務上使用する内部IDユーザAと外部IDユーザαとの対応関係について把握することが可能となる。なお、上記の一連の処理は、外部サイトのSNSサービス等において、社内コミュニケーションを行うコミュニティ等への参加を希望するユーザ社員のみ行えばよい。なお、上記の例では、ユーザが先に外部サーバ20外部サイトにログインしステップS01~S03、その後に内部サーバ10内部サイトにログインするステップS04~S06順となっているが、各サーバサイトへのログインの順序は逆であってもよい。また、ステップS07で内部クライアント61が内部サーバ10に対して外部IDの取得要求を送信する前に、外部サーバ20に対するログインが行われていないステップS01~S03に相当する処理が行われていない状態であってもよい。このときは、例えば、ステップS09~S10での処理に代えて、外部サーバ20に対するログイン処理ステップS01~S03に相当する処理を内部クライアント61に対して要求して行うようにしてもよい。また、内部サーバ10の認証連携部13から外部サーバ20に対して外部IDを問い合わせる手法についても種々のものがあり、これらを適宜利用することができる。例えば、上記の例のように外部サーバ20が認証情報の連携のために認証APIを提供しており、これを内部サーバ10から利用する方式に限らず、例えば、SSOの仕組みを利用して、単純に内部サーバ10の認証連携部13経由で外部サーバ20に対してログインする構成とすることで、その際に外部IDを取得するという方式をとることも可能である。<処理の流れグループ定義情報のメンテナンス>以下では、内部サーバ10が、上述の図2に示した処理により、内部IDと外部IDとの対応関係を把握した後、内部サーバ10側内部サイトにおける社員の人事情報等に基づく内部IDのグループ定義の更新情報新規追加、削除、変更等に基づいて、外部サーバ20外部サイトにおける外部IDのグループ定義グループやコミュニティの形成をメンテナンスして、内部IDのグループ定義の情報を外部サーバ20における外部IDのグループ定義に自動的に反映させる際の処理について説明する。図3は、内部サーバ10での内部IDのグループ定義の情報に基づいて外部サーバ20における外部IDのグループ定義を更新する際の処理の流れの例について概要を示した図である。まず、図2に示した処理におけるステップS01~S06の処理と同様に、内部クライアント61もしくは外部クライアント62は、Webブラウザを介した社員等のユーザからのログイン要求を受けて、外部サーバ20および内部サーバ10の双方に対してログイン処理を行い、セッション情報αおよびAを取得するS21~S26。なお、ここでのユーザは、外部サーバ20におけるユーザのグループ定義グループやコミュニティの形成について管理権限のあるユーザである。その後、自動もしくはユーザからの指示に基づいて、内部クライアント61は、内部サーバ10に対して、セッション情報Aおよびセッション情報αに基づく外部サーバ20へのアクセスのための鍵類ともに、外部サーバ20におけるグループ定義の更新要求を送信するS27。グループ定義の更新要求を受信した内部サーバ10では、セッション情報Aを確認した上で、グループ管理部14により、外部サーバ20に対して現状のグループ定義の取得要求を送信するS28。ここでは、グループ管理部14は、例えば、外部サーバ20のユーザ管理I/F23を直接呼び出すことにより、グループ定義の取得要求を行う。なお、例えば、内部クライアント61上のWebブラウザを介して自動で画面を切り替えてデータを受け渡す等の処理により、間接的に外部サーバ20に対して要求を送信するなど、他の方式をとることも可能である。外部IDのグループ定義の取得要求を受信した外部サーバ20では、ユーザ管理I/F23により、外部ユーザ管理テーブル24から現状の外部IDのグループ定義情報を取得しS29、これを内部サーバ10に対して送信する。現状の外部IDのグループ定義情報を受信した内部サーバ10では、グループ管理部14により、現状の外部IDのグループ定義情報と、内部ユーザ管理テーブル15のグループ定義情報との比較に基づいて、その差分から、外部IDのグループ定義についての更新情報グループやコミュニティ、およびそのメンバーについての新規追加、削除、変更等に係る情報を生成するS30。その後、内部サーバ10のグループ管理部14は、グループ定義の更新情報とともに、外部サーバ20に対してグループ定義の更新要求を送信するS31。ここでも上記と同様に、例えば、外部サーバ20のユーザ管理I/F23を直接呼び出すことにより、グループ定義の更新要求を行う。なお、例えば、内部クライアント61上のWebブラウザを介して自動で画面を切り替えてデータを受け渡す等の処理により、間接的に外部サーバ20に対して要求を送信するなど、他の方式をとることも可能である。外部IDのグループ定義の更新要求を受信した外部サーバ20では、グループ定義の更新情報に基づいて、ユーザ管理I/F23により、外部ユーザ管理テーブル24に対してグループ定義の更新の登録を行うS32。以上のような処理により、管理権限のあるユーザがログインした際に、外部サーバ20における管理対象のグループやコミュニティの現状のグループ定義について、内部サーバ10におけるグループ定義社内の人事情報等に基づいて適宜更新されると比較して最新の状態であるかチェックし、最新の状態となるよう、外部サーバ20におけるグループ定義に自動で反映させることが可能となる。なお、図3に示した例では、外部サーバ20がユーザ管理I/F23を有しているため、これを利用して自動で外部ユーザ管理テーブル24における外部IDのグループ定義を更新することが可能であるが、外部サーバ20がこのような外部インタフェースを有さず、Webブラウザ等での操作による手動でのインタフェースしか有していない場合は、管理権限を有するユーザがこれを利用して手動でグループ定義を更新するようにしてもよい。また、例えば、グループ定義の更新情報からなるCSVCommaSeparatedValuesファイル等を外部サーバ20にアップロードして反映させるというようなインタフェースでも対応することが可能である。また、図3に示した例以外にも、上述したように、例えば、ユーザ管理I/F23が、ユーザを介さずに直接アクセスして外部ユーザ管理テーブル24のメンテナンスを可能とするようなインタフェースである場合は、直接アクセスするための鍵やパスワードなどの情報を内部サーバ10にて予め保持しておき、内部サーバ10が定期的に外部サーバ20にアクセスしてグループ定義の更新メンテナンスを行うという方式をとることも可能である。以上に説明したように、本発明の一実施の形態であるグループ定義管理システム1によれば、社内システム等の内部サーバ10内部サイトにおける内部IDと外部サーバ20外部サイトのSNSサービス等における外部IDとの対応を容易に取得することが可能となる。また、内部サーバ10における内部IDに基づくグループ定義の情報を外部サーバ20のSNSサービス等におけるコミュニティやグループを形成するグループ定義の情報に容易に反映させることが可能となる。これらにより、企業等が原則としてコントロールすることができない外部サーバ20上のSNSサービス等において、社員など内部サーバ10の特定のユーザのみがメンバーとして参加することができ、社内コミュニケーションを行うことが可能なコミュニティやグループを容易に形成することが可能となる。また、一度外部サーバ20外部サイトにおいてコミュニティやグループが形成されれば、以降は、グループ定義のメンテナンス時以外は、外部サイトに対するアクセスのみで内部サイトへの接続を要さずコミュニケーションを行うことができる。また、当該コミュニティでは、業務外での社内コミュニケーションであることが明確となる一方、メンバーは全て社員であることが保証されるため、安心してコミュニケーションを行うことができる。また、社内における人事異動や退職等に伴う社内でのグループ定義の変更を、自動で外部サーバ20外部サイトにおけるグループ定義に確実に反映させることができる。また、部署などの人事情報に係るグループだけではなく、社員の属性情報や、プロジェクト、社内活動テーマ毎のグループなどについても容易に自動で形成することができ、かつ、必要最低限の適切なメンバーに限定する外部サイトにおける自由なグループやコミュニティの形成を制限することができる。また、社員の申告や申請等によらず、システム的に当該社員の外部IDの情報を取得するため、外部サイトにおけるユーザ内部サイト側で把握している外部IDの所有者が本人社員であるか否かを確実に把握することができる。また、外部IDの情報だけにとどまらず、外部サーバ20外部サイトにおける社員等の活動実績に係る情報を内部サーバ10内部サイト、社内システム側に取り込んで活用するというような利用方法も可能である。以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、本実施の形態では、上述したように、外部サーバ20例えばFacebook等の外部サイト上での外部IDの情報を取得して、内部サーバ10例えば社内システム等の内部サイトにおける内部IDと関連付けることで、内部IDでのグループ定義の情報を外部IDでのグループ定義に反映させることを可能とするものであるが、グループ定義を反映させるサーバサイト間の関係はこれに限らない。変形例として、例えば、外部IDの情報を取得する先が、外部サーバ20例えばFacebook等の外部のSNSサイトではなく、外部サーバ20とユーザ情報を連携して稼働する他の外部サイト例えば、Facebook等のSNSサービスと連携して稼働するソーシャルゲームサイト等。同一の外部サーバ20上のものでも別の外部サーバ20上のものでもよいから、ユーザID外部IDやこれに基づいて特定される情報を取得する構成とすることも可能である。また、これに対応して、内部IDでのグループ定義の情報を反映させる先も、外部サーバ20例えばFacebook等の外部のSNSサイトではなく、上記の他の外部サイトソーシャルゲームサイト等とすることも可能である。上記の例は、例えば、外部サーバ20例えばFacebook等のSNSサービスが、グループ定義の情報を自動で行うことを可能とするユーザ管理I/F23を有していないような場合に、これとユーザ情報を連携する外部サイト例えば、内部サーバ10を運営する企業が開発運用しているソーシャルゲームサイト等が、ユーザ管理I/F23を有することができ、かつ、グループ定義を管理したいのは当該外部サイトの方であるような場合に適用することができる。この場合、当該外部サイトソーシャルゲームサイト等にアクセスするユーザは、外部サーバ20Facebook等のSNSサービスによるユーザ認証を利用するが、当該外部サイトでのグループ定義には内部サーバ10でのグループ定義が反映されるということになる。また、別の変形例として、例えば、外部サーバ20例えばFacebook等の外部のSNSサイトでの外部IDの情報およびそのグループ定義の情報を内部サーバ10が取得して、これに基づいて他の外部サイト例えばFacebook等のSNSサービスと連携して稼働するソーシャルゲーム等。同一の外部サーバ20上のものでも別の外部サーバ20上のものでもよいのユーザ登録やグループ定義に反映させる構成とすることも可能である。