JP7113475B2 - 求人連携サーバ、求人情報連携方法、及びプログラム - Google Patents

Description

本発明は求人連携サーバ、求人情報連携方法、及びプログラムに関し、求人主からの求人情報を求人媒体に連携するための求人連携サーバ、求人情報連携方法、及びプログラムに関する。

近年、企業などの求人広告はオンラインで行われることが多くなっている。オンライン求人広告における広告の掲載は、これまでのところ、求人サイトの営業担当が求人主から広告の内容を受け取り、手作業で求人サイトのサーバにアップロードする、という手順で実行されている。求人広告には、求人主が求人サイト内又は自社サーバ内に用意するランディングページのＵＲＬ(Uniform Resource Locator)が含まれており、応募者は、求人広告から遷移したランディングページにおいて、応募のために必要な履歴情報の入力などを行う。

近年の求人サイトは、一般の検索サイトと同様、キーワードによる検索の結果として求人広告を表示するように構成されており、検索結果の表示欄には、無料広告枠及び有料広告枠が設けられる。無料広告枠への掲載は無料で行えるが、上位に表示される可能性は低くなる。有料広告枠への掲載は有料であるが、上位に表示される可能性が高くなる。

有料広告枠の課金はいわゆるクリック課金型であり、求人広告内に設けられる詳細画面へのリンクボタンの１クリックごとに、予め設定した金額が課金される。この金額（コンバージョン単価）は求人主によって自由に設定可能であるが、広告枠ごとにコンバージョン単価による入札となるため、上位に表示されたければ、ある程度の金額を設定する必要がある。

特許文献１には、求人広告ではないが、入札によるオンライン広告を実現するシステムの一例が記載されている。

特開２０１６－５２６７３１号公報

しかしながら、上記従来の求人広告の仕組みによれば、求人主は、多数の求人サイトに柔軟に求人広告を掲載することが難しい。また、求人サイト側としても、求人主に対して求人広告掲載の営業を行う必要があるため、顧客である求人主の範囲が限定されてしまう。これらの結果として、上記従来の求人広告には、十分な広告効果を得ることが難しいという課題があった。

したがって、本発明の目的の一つは、求人広告に関して、高い広告効果を実現できる求人連携サーバ、求人情報連携方法、及びプログラムを提供することにある。

また、求人情報を複数の求人サイトに自動的に連携する場合、コンバージョン単価が下限入札単価を上回っているか否かという基本的な条件に加え、求人サイトの特徴に合うか、求人サイトの競合他社の求人でないか、などの様々な条件を考慮して連携できるようにすることが望まれる。また、求人サイトの下限入札単価自体も、採用条件等によって柔軟に設定可能であることが望まれる。

したがって、本発明の目的の他の一つは、連携する求人情報に対し、求人サイト側で様々な条件を設定できる求人連携サーバ、求人情報連携方法、及びプログラムを提供することにある。

また、条件に合致して連携することとなった求人情報を求人サイトにただ表示するだけでは広告効果が限定的になるので、求人主の要望や求人サイトの特徴に応じたメリハリを付けて表示できるようにすることにより、求人サイトに訪れた求職者が優良な求人を容易に見つけられるようにすることが望まれる。

したがって、本発明の目的のさらに他の一つは、求人サイトにおける求人情報の表示を求人主の要望や求人サイトの特徴に応じて柔軟に調整できる求人連携サーバ、求人情報連携方法、及びプログラムを提供することにある。

また、求人情報を多数の求人サイトに自動的に連携する場合、発生した課金の管理が難しくなるので、求人主の想定よりも多額のコストが発生してしまう場合がある。

したがって、本発明の目的のさらに他の一つは、課金の発生状況に応じて求人サイトへの求人情報の連携を制御できる求人連携サーバ、求人情報連携方法、及びプログラムを提供することにある。

本発明の第１の側面による求人連携サーバは、複数の求人媒体サーバと通信可能に構成された求人連携サーバであって、前記複数の求人媒体それぞれの下限入札単価と、求人情報のコンバージョン単価とに基づいて前記求人情報の連携先となる１以上の前記求人媒体サーバを決定し、決定した前記１以上の求人媒体サーバのそれぞれに対して前記求人情報を連携する、求人連携サーバである。

本発明の第１の側面による求人情報連携方法は、複数の求人媒体サーバに対して求人情報を連携するための求人情報連携方法であって、前記複数の求人媒体それぞれの下限入札単価と、求人情報のコンバージョン単価とに基づいて前記求人情報の連携先となる１以上の前記求人媒体サーバを決定するステップと、決定した前記１以上の求人媒体サーバのそれぞれに対して前記求人情報を連携するステップと、を含む求人情報連携方法である。

本発明の第１の側面によるプログラムは、複数の求人媒体サーバと通信可能に構成された求人連携サーバとしてコンピュータを機能させるためのプログラムであって、前記コンピュータに、前記複数の求人媒体それぞれの下限入札単価と、求人情報のコンバージョン単価とに基づいて前記求人情報の連携先となる１以上の前記求人媒体サーバを決定するステップと、決定した前記１以上の求人媒体サーバのそれぞれに対して前記求人情報を連携するステップと、を実行させるためのプログラムである。

本発明の第２の側面による求人連携サーバは、前記複数の求人媒体サーバのそれぞれが有する連携する求人情報についての１以上の条件にも基づいて、前記求人情報の連携先となる１以上の前記求人媒体サーバを決定する、第１の側面による求人連携サーバである。

本発明の第２の側面による求人情報連携方法は、前記決定するステップは、前記複数の求人媒体サーバのそれぞれが有する連携する求人情報についての１以上の条件にも基づいて、前記求人情報の連携先となる１以上の前記求人媒体サーバを決定する、第１の側面による求人情報連携方法である。

本発明の第２の側面によるプログラムは、前記決定するステップは、前記複数の求人媒体サーバのそれぞれが有する連携する求人情報についての１以上の条件にも基づいて、前記求人情報の連携先となる１以上の前記求人媒体サーバを決定する、第１の側面によるプログラムである。

本発明の第３の側面による求人連携サーバは、前記複数の求人媒体サーバのそれぞれについて予め決定される方法により前記求人情報の優先順位を算出し、前記求人情報とともに前記優先順位を前記１以上の求人媒体サーバのそれぞれに対して送信する、第１の側面による求人連携サーバである。

本発明の第３の側面による求人情報連携方法は、前記複数の求人媒体サーバのそれぞれについて予め決定される方法により前記求人情報の優先順位を算出するステップと、前記求人情報とともに前記優先順位を前記１以上の求人媒体サーバのそれぞれに対して送信する送信するステップと、をさらに含む、第１の側面による求人情報連携方法である。

本発明の第３の側面によるプログラムは、前記複数の求人媒体サーバのそれぞれについて予め決定される方法により前記求人情報の優先順位を算出するステップと、前記求人情報とともに前記優先順位を前記１以上の求人媒体サーバのそれぞれに対して送信する送信するステップと、を前記コンピュータにさらに実行させる、第１の側面によるプログラムである。

本発明の第４の側面による求人連携サーバは、前記複数の求人媒体サーバのそれぞれにおける前記求人情報の求人主に対する課金の発生状況に応じて前記求人情報の連携を中止する、第１の側面による求人連携サーバである。

本発明の第４の側面による求人情報連携方法は、前記複数の求人媒体サーバのそれぞれにおける前記求人情報の求人主に対する課金の発生状況に応じて前記求人情報の連携を中止するステップ、をさらに含む、第１の側面による求人情報連携方法である。

本発明の第４の側面によるプログラムは、前記複数の求人媒体サーバのそれぞれにおける前記求人情報の求人主に対する課金の発生状況に応じて前記求人情報の連携を中止するステップ、を前記コンピュータにさらに実行させる、第１の側面によるプログラムである。

本発明の第１の側面によれば、入札条件の合致する１以上の求人媒体サーバに対し、求人情報を柔軟に連携することができるので、求人広告に関して、高い広告効果を実現することが可能になる。

本発明の第２の側面によれば、連携する求人情報に対し、求人媒体サーバ側で様々な条件を設定することが可能になる。

本発明の第３の側面によれば、求人媒体サーバは、優先順位に基づいて求人情報の表示順を調整することができる。したがって、求人サイトにおける求人情報の表示を、求人主の要望や求人サイトの特徴に応じて柔軟に調整することが可能になる。

本発明の第４の側面によれば、課金の発生状況に応じて求人サイトへの求人情報の連携を制御することが可能になる。

本発明の第１の実施の形態による求人システム１の構成を示す図である。 求人連携サーバ１０、採用管理サーバ２０、及び求人媒体サーバ３０それぞれの基本的なハードウェア構成を示す図である。 求人連携サーバ１０、採用管理サーバ２０、及び求人媒体サーバ３０の機能ブロックを示す略ブロック図である。 データベース１２の構造を示す図である。 （ａ）は、アカウントテーブルＴ１の構造を詳細に示す図であり、（ｂ）は、チャージ履歴テーブルＴ２の構造を詳細に示す図である。 （ａ）は、求人情報テーブルＴ３の構造を詳細に示す図であり、（ｂ）は、フィード情報テーブルＴ４の構造を詳細に示す図である。 （ａ）は、キャンペーンテーブルＴ５の構造を詳細に示す図であり、（ｂ）は、キャンペーン求人対応テーブルＴ６の構造を詳細に示す図である。 （ａ）は、求人媒体テーブルＴ７の構造を詳細に示す図であり、（ｂ）は、ブラックリストテーブルＴ８の構造を詳細に示す図であり、（ｃ）は、下限入札単価テーブルＴ９の構造を詳細に示す図である。 （ａ）は、成果テーブルＴ１０の構造を詳細に示す図であり、（ｂ）は、キャンペーン成果テーブルＴ１１の構造を詳細に示す図である。 入力受付部１１が行う求人情報入力受付処理の処理フローを示すフロー図である。 フィード生成部１３が行うフィード情報生成処理の処理フローを示すフロー図である。 成果処理部１５が行うアカウント単位連携中止処理の処理フローを示すフロー図である。 フィード生成部１３が行うキャンペーン単位連携中止処理の処理フローを示すフロー図である。 フィード生成部１３が行う連携先媒体決定処理の処理フローを示すフロー図である。 フィード生成部１３が行う連携先媒体決定処理の処理フローを示すフロー図である。 フィード生成部１３が行う表示優先順位付与処理の処理フローを示すフロー図である。 優先順位の算出方法の一例を示す図である。 優先順位の算出方法の他の一例を示す図である。 フィード連携部１４が行うフィード情報送信処理の処理フローを示すフロー図である。 フィード表示制御部３１により生成される求人サイトの表示画面の例を示す図である。 本発明の第２の実施の形態によるデータベース１２が図４に示した各テーブルに加えて記憶する各テーブルを示す図である。 （ａ）は、ハブ職種マスタテーブルＴ２０の構造を示す図であり、（ｂ）は、媒体職種マスタテーブルＴ２１の構造を示す図である。 入力受付部１１に適用するためのパッチファイルを生成するためのパッチファイル生成処理を示す処理フロー図である。 図２３に示したパッチファイル生成処理により生成されたパッチファイルの性能評価を行うために用いる評価メトリクスを生成するための評価メトリクス生成処理を示す処理フロー図である。 パッチファイル生成処理により生成されたパッチファイルを適用された入力受付部１１によって実行される求人情報入力受付処理の処理フローを示すフロー図である。 入力受付部１１が行う職種変換処理の処理フローを示すフロー図である。 フィード連携部１４が行うフィード情報送信処理の処理フローを示すフロー図である。

以下、添付図面を参照しながら、本発明の実施の形態について詳細に説明する。

図１は、本発明の第１の実施の形態による求人システム１の構成を示す図である。本実施の形態による求人システム１は、企業を含む各種法人や個人事業主などの求人主により提出される求人広告を求人サイト（求人媒体）に表示するためのシステムであり、図１に示すように、運用型求人連携プラットフォームを構成する求人連携サーバ１０と、求人主の採用活動のために用いられる採用管理サーバ２０と、求人サイトを構成する求人媒体サーバ３０と、求職者のコンピュータである求職者端末４０とがネットワーク２を介して接続された構成を有している。なお、図１には採用管理サーバ２０、求人媒体サーバ３０、及び求職者端末４０をそれぞれ１つずつ図示しているが、実際の求人システム１には、各複数の採用管理サーバ２０、求人媒体サーバ３０、及び求職者端末４０が含まれ得る。

初めに求人システム１の動作の概要を説明すると、求人システム１を利用しようとする求人主はまず、求人連携サーバ１０のアカウントを取得し、広告料として使用する金銭をチャージする。広告料の課金方式にはＣＰＡ(Cost Per Acquisition)とＣＰＣ(Cost Per Click)とがあり、いずれを採用するかは求人媒体サーバ３０ごとに異なる。ＣＰＡは、実際に応募があった場合に課金が発生する課金方式であり、求人広告からの遷移先であるランディングページを求人媒体サーバ３０内に構築する必要がある。ＣＰＣは、求人広告からランディングページへの遷移が行われた場合に課金が発生する課金方式であり、ランディングページの構築場所は任意である。採用管理サーバ２０内での構築が一般的であるが、求人媒体サーバ３０内や、求人主の自社サイトを構築しているＨＴＭＬサーバ内などに構築してもよい。以下では、ＣＰＣの場合のランディングページを採用管理サーバ２０内に構築することとして説明を続ける。

求人主は、採用管理サーバ２０を介して求人連携サーバ１０に求人情報を供給するとともに、求人情報を求人サイトに掲載する際に必要となる各種の情報（具体的には、希望する課金方式、掲載期間、コンバージョン単価の目標値（目標応募単価）とその調整率、予算に関する情報など）を含むキャンペーン情報を求人連携サーバ１０に入力する。キャンペーン情報には、求人主によって１以上の求人情報が紐付けられ、それによってキャンペーン情報は、求人主による複数の求人情報のうちの１つ以上を特定する情報となる。

求人連携サーバ１０は、キャンペーン情報が入力されたことを受け、対応する１以上の求人情報を求人媒体サーバ３０に連携する処理を行う。詳しくは後述するが、この処理には、それまでの成果に応じてコンバージョン単価を調整する処理、連携対象となる求人媒体サーバ３０を決定する処理、各求人情報に求人媒体サーバ３０内での表示の優先順位を示す表示優先順位情報を付与する処理、調整後のコンバージョン単価及び付与した表示優先順位情報を含む求人情報のフィードを生成し、対応する求人媒体サーバ３０に送信する処理が含まれる。また、求人連携サーバ１０は、求人情報が求職者端末４０の画面に表示された回数（以下「インプレッション数」という）、求人情報が表示された結果として発生した応募の数（ＣＰＡの場合。以下「応募数」という）、及び、ランディングページへの遷移の数（ＣＰＣの場合。以下「クリック数」という）を管理し、応募数又はクリック数に応じた金額をチャージ残高から減算するとともに、次の連携の際のコンバージョン単価の調整に使用する。

図２は、求人連携サーバ１０、採用管理サーバ２０、及び求人媒体サーバ３０それぞれの基本的なハードウェア構成を示す図である。同図に示すように、求人連携サーバ１０、採用管理サーバ２０、及び求人媒体サーバ３０はそれぞれ、プロセッサ１０１と、記憶装置１０２と、通信装置１０３と、入力装置１０４と、出力装置１０５とがバス１０６を介して相互に接続された構成を有して構成される。

プロセッサ１０１は、記憶装置１０２に記憶されるプログラムを読み出して実行する中央処理装置である。求人連携サーバ１０、採用管理サーバ２０、及び求人媒体サーバ３０が行う処理として後述する各処理は、それぞれのプロセッサ１０１がそれぞれの記憶装置１０２に記憶されるプログラムを読み出して実行することによって実現される。プロセッサ１０１は、バス１０６を介して当該サーバ内の各部と通信可能に構成されており、実行するプログラムの記述に応じて、各部の制御や記憶装置１０２に記憶されるデータの処理などを行う。

記憶装置１０２は、各種プログラム及び各種データを一時的又は永続的に記憶する装置である。記憶装置１０２は通常、ＤＲＡＭ(Dynamic Random Access Memory)やＳＲＡＭ(Static Random Access Memory)などによって構成される主記憶装置、ハードディスクやＳＳＤ(Solid State Drive)などによって構成される補助記憶装置など、複数の記憶装置の組み合わせによって構成される。

通信装置１０３は、プロセッサ１０１の制御に応じ、外部の通信装置（図１に示したネットワーク２を含む）との間で通信を実行する装置である。通信装置１０３が行う通信の方式は特に限定されないが、一例として有線又は無線のＷＡＮ(Wide Area Network)又はＬＡＮ(Local Area Network)が挙げられる。

入力装置１０４は、ユーザからの入力を受け付ける装置であり、マウス、キーボード、タッチパネルなどの各種入力手段を含む。入力装置１０４が受け付けたユーザ入力の内容は、バス１０６を介してプロセッサ１０１に伝達される。出力装置１０５は、プロセッサ１０１の制御に応じてユーザに対する出力を行う装置であり、ディスプレイやスピーカなどの各種出力手段を含む。なお、入力装置１０４及び出力装置１０５は、求人連携サーバ１０、採用管理サーバ２０、及び求人媒体サーバ３０のそれぞれに接続されるクライアント装置に実装されることとしてもよい。

図１に戻る。ネットワーク２は、例えばインターネットなどのＩＰ(Internet Protocol)ネットワークである。求人連携サーバ１０、採用管理サーバ２０、求人媒体サーバ３０、及び求職者端末４０は、ネットワーク２を介して相互に通信可能に構成される。

図３は、求人連携サーバ１０、採用管理サーバ２０、及び求人媒体サーバ３０の機能ブロックを示す略ブロック図である。同図に示すように、求人連携サーバ１０は機能的に、入力受付部１１、データベース１２、フィード生成部１３、フィード連携部１４、成果処理部１５を有して構成される。また、採用管理サーバ２０は機能的に、求人情報入力受付部２１、求人詳細情報表示制御部２２、応募受付部２３、応募情報取得部２４を有して構成される。さらに、求人媒体サーバ３０は機能的に、フィード表示制御部３１、クリック受付部３２、求人詳細情報表示制御部３３、応募受付部３４を有して構成される。

また、図４は、データベース１２の構造を示す図である。同図に示すように、データベース１２内には、アカウントテーブルＴ１、チャージ履歴テーブルＴ２、求人情報テーブルＴ３、フィード情報テーブルＴ４、キャンペーンテーブルＴ５、キャンペーン求人対応テーブルＴ６、求人媒体テーブルＴ７、ブラックリストテーブルＴ８、下限入札単価テーブルＴ９、成果テーブルＴ１０、キャンペーン成果テーブルＴ１１が格納される。

図５～図９は、図４に示した各テーブルの構造を詳細に示す図である。これらの図を参照しながら各テーブルの概要を説明すると、まず図５（ａ）に示すアカウントテーブルＴ１は、求人連携サーバ１０における求人主の情報（以下「アカウント情報」という）を記憶するテーブルであり、アカウントに対して一意に割り当てられるアカウントＩＤに対応付けて、採用管理サイトＩＤ、求人主ＩＤ、求人主情報、連携中止フラグを記憶するよう構成される。このうち採用管理サイトＩＤは、採用管理サーバ２０に対して一意に割り当てられる識別情報である。また、求人主ＩＤは、求人主に対して一意に割り当てられる識別情報である。求人主情報は求人主の詳細を示す情報であり、企業名、担当者名、担当者メールアドレス、電話番号などの情報を含んで構成される。

図５（ｂ）に示すチャージ履歴テーブルＴ２は、求人主が求人連携サーバ１０にチャージした金額を記憶するためのテーブルであり、チャージ動作に対して一意に割り当てられるチャージ履歴ＩＤに対応付けて、アカウントＩＤ、チャージ日、チャージ金額、消化金額、開始日、終了日を記憶するよう構成される。チャージ金額は、求人広告の掲載費用として求人主が設定した限度額を示し、消化金額は、チャージ金額のうち発生した課金を精算するために使用された金額を示す。開始日及び終了日には、チャージ金額の利用を開始する日と終了する日がそれぞれ設定される。

図６（ａ）に示す求人情報テーブルＴ３は、求人主から採用管理サーバ２０を介して供給される求人情報を記憶するテーブルであり、採用管理サイトＩＤ及び求人ＩＤの組み合わせに対応付けて、求人主ＩＤ、求人主情報、採用条件、ランディングページのＵＲＬ（ＣＰＡ）、ランディングページのＵＲＬ（ＣＰＣ）、掲載開始日、掲載終了日を記憶するよう構成される。求人ＩＤは、採用管理サイトＩＤごとに、求人情報に対して一意に割り当てられる識別情報であり、採用管理サイトＩＤとの組み合わせにより、求人連携サーバ１０が取り扱うすべての求人情報を一意に識別する識別情報として機能する。ただし、求人連携サーバ１０が取り扱うすべての求人情報を一意に識別する識別情報を単独で構成するように、求人ＩＤを構成してもよい。

求人主情報には、求人主名、求人主所在地、求人主事業内容、業種カテゴリ、業種、採用担当部署、電話番号などの情報が含まれ、採用条件には、職種、雇用形態、勤務地（地域、都道府県、郵便番号、住所、建物名、店舗名、アクセス、最寄駅）、仕事内容、特徴、ＰＲ・職場情報、給与種別、給与、最低給与、最大給与、給与詳細、応募条件、学歴、勤務開始時間、勤務終了時間、勤務時間詳細、休日・休暇、福利厚生、交通費支給の有無、採用予定人数などの情報が含まれる。ランディングページのＵＲＬ（ＣＰＡ）は、課金方式がＣＰＡとなる場合のランディングページのＵＲＬであり、ランディングページのＵＲＬ（ＣＰＣ）は、課金方式がＣＰＣとなる場合のランディングページのＵＲＬである。

図６（ｂ）に示すフィード情報テーブルＴ４は、求人連携サーバ１０から求人媒体サーバ３０に連携するフィード情報を記憶するテーブルであり、連携動作に対して一意に割り当てられるフィードＩＤに対応付けて、求人媒体ＩＤ、採用管理サイトＩＤ、求人主ＩＤ、キャンペーンＩＤ、求人ＩＤ、コンバージョン単価、表示優先順位情報、有効フラグを記憶するよう構成される。フィード情報内に含まれる採用管理サイトＩＤ及び求人ＩＤの組み合わせにより、１つのフィード情報に対して１つの求人情報が対応付けられる。

図７（ａ）に示すキャンペーンテーブルＴ５は、求人主が求人媒体テーブルＴ７に入力するキャンペーン情報を記憶するテーブルであり、キャンペーン情報に対して一意に割り当てられるキャンペーンＩＤに対応付けて、採用管理サイトＩＤ、求人主ＩＤ、キャンペーン名、ＣＰＡ目標応募単価、ＣＰＣ応募単価調整範囲、ＣＰＣ目標応募単価、ＣＰＡ応募単価調整範囲、ＣＰＡプラン利用フラグ、ＣＰＣプラン利用フラグ、応募者ターゲット情報、入札開始日、入札終了日、入札有効フラグ、入札ステータス、初回入札日、ＣＰＡ予算情報、ＣＰＣ予算情報を記憶するよう構成される。

キャンペーンテーブルＴ５に記憶される各情報のうちＣＰＡプラン利用フラグには、課金方式としてＣＰＡを希望する場合にＴｒｕｅ、希望しない場合にＦａｌｓｅが設定される。同様に、ＣＰＣプラン利用フラグには、課金方式としてＣＰＣを希望する場合にＴｒｕｅ、希望しない場合にＦａｌｓｅが設定される。ＣＰＡプラン利用フラグ及びＣＰＣプラン利用フラグは、少なくともいずれか一方がＴｒｕｅである必要があり、ＣＰＡプラン利用フラグ及びＣＰＣプラン利用フラグの両方がＴｒｕｅであってもよい。

ＣＰＡ応募単価調整範囲は課金方式がＣＰＡとなる場合におけるコンバージョン単価（以下「ＣＰＡコンバージョン単価」という場合がある）の調整範囲を示す情報であり、例えばＣＰＡ目標応募単価の８０％以上１２０％以下という範囲を示す情報が設定される。同様に、ＣＰＣ応募単価調整範囲は課金方式がＣＰＣとなる場合におけるコンバージョン単価（以下「ＣＰＣコンバージョン単価」という場合がある）の調整範囲を示す情報であり、例えばＣＰＣ目標応募単価の８０％以上１２０％以下という範囲を示す情報が設定される。

応募者ターゲット情報は、求める応募者の属性を示す１以上の情報（住所地、職種、雇用形態、希望する給料の範囲、福利厚生など）により構成される。入札開始日及び入札終了日には、求人情報の掲載を開始する日と終了する日がそれぞれ設定される。入札有効フラグは、当該レコードが現在有効であるか否かを示す情報であり、例えば求人主自身によって設定される。入札ステータスは、現在、求人媒体サーバ３０にフィードを連携中かどうかを示す情報であり、後述するフィード連携部１４により１日に１回以上更新される。初回入札日は、当該レコードに対応するフィードを初めて求人媒体サーバ３０に連携した日を示す情報であり、後述するフィード連携部１４により更新される。ＣＰＡ予算情報は、ＣＰＡを利用する場合の予算を規定する情報であり、求人主が希望する月間課金額の最大値が設定される。ＣＰＣ予算情報は、ＣＰＣを利用する場合の予算を規定する情報であり、求人主が希望する１日課金額及び月間課金額の最大値が設定される。

図７（ｂ）に示すキャンペーン求人対応テーブルＴ６は、求人主によって各キャンペーン情報に紐付けられる１以上の求人情報を記憶するテーブルであり、キャンペーンＩＤに対応付けて求人ＩＤを記憶するよう構成される。

図８（ａ）に示す求人媒体テーブルＴ７は、求人媒体に関する各種情報を記憶するテーブルであり、求人媒体サーバ３０に対して一意に割り当てられる求人媒体ＩＤに対応付けて、求人媒体名、入札プラン、開放率、デフォルト下限入札単価、優先順位決定ロジック情報、特化項目、連携除外条件を記憶するよう構成される。入札プランには、求人媒体サーバ３０の課金方式（ＣＰＡ又はＣＰＣ）が設定される。開放率は、求人サイトに掲載される全求人広告のうち、求人連携サーバ１０から連携された求人広告の占める割合の最大値である。その他の項目については、後述する。

図８（ｂ）に示すブラックリストテーブルＴ８及び図８（ｃ）に示す下限入札単価テーブルＴ９はそれぞれ、複数の求人媒体サーバ３０のそれぞれが有する、連携する求人情報についての１以上の条件を記憶するテーブルである。ブラックリストテーブルＴ８は、連携を拒否する拒否条件を記憶するもので、求人媒体ＩＤに対応付けて、項目名、キーワード、演算子を記憶するよう構成される。項目名は、求人情報テーブルＴ３又はキャンペーンテーブルＴ５に含まれる項目の名称であり、演算子は、対応するキーワードが含まれていれば直ちに連携中止となるのか、或いは、他のキーワードとの組み合わせが含まれていた場合に連携中止となるのかを示す情報である。下限入札単価テーブルＴ９は、条件ごとに異なる下限入札単価を記憶するもので、求人媒体ＩＤに対応付けて、条件名、条件情報、下限入札単価を記憶するよう構成される。

図９（ａ）に示す成果テーブルＴ１０は、上述した応募数（ＣＰＡの場合）又はクリック数（ＣＰＣの場合）を記録するテーブルであり、集計対象日ごとに、求人媒体ＩＤ、採用管理サイトＩＤ、求人主ＩＤ、キャンペーンＩＤ、及び求人ＩＤの組み合わせに対応付けて、クリック数、応募数、消費額を記憶するよう構成される。消費額は、ランディングページへの遷移又は応募に応じて実際に発生した課金の額である。

図９（ｂ）に示すキャンペーン成果テーブルＴ１１は、成果テーブルＴ１０に格納される各情報をキャンペーンＩＤ、入札プラン、及び集計対象日の組み合わせごとにまとめたテーブルであり、キャンペーンＩＤ、入札プラン、及び集計対象日の組み合わせに対応付けて、インプレッション数、クリック数、応募数、消費額を記憶するよう構成される。

以下、必要に応じて図４～図９も参照しながら、図３に示した各機能部の機能について詳しく説明する。

入力受付部１１は、求人主から、アカウント情報、チャージ、キャンペーン情報の入力を受け付ける機能部である。求人主の担当者は、所定のＡＰＩ(Application Programming Interface)を用いて自分のコンピュータ（図示せず）から求人連携サーバ１０にアクセスすることにより、これらの情報の入力を行う。

まだアカウントテーブルＴ１にアカウント情報が登録されていない求人主からアカウント情報が入力された場合、入力受付部１１は新たなアカウントＩＤを付与し、付与したアカウントＩＤに対応付けて、入力されたアカウント情報をアカウントテーブルＴ１に追加する。なお、アカウントＩＤの付与は、入力受付部１１が自動的に行うこととしてもよいし、運用型求人連携プラットフォームの担当者が手作業で行うこととしてもよい。既にアカウント情報が登録されている求人主からアカウント情報が入力された場合、入力受付部１１は、入力されたアカウント情報によりアカウントテーブルＴ１を更新する。

チャージが入力された場合、入力受付部１１は、チャージを入力した求人主のアカウントＩＤに対応付けて、入力されたチャージの内容をチャージ履歴テーブルＴ２に追加する。キャンペーン情報が入力された場合、入力受付部１１は、新たなキャンペーンＩＤを付与し、付与したキャンペーンＩＤに対応するレコードを、キャンペーンテーブルＴ５及びキャンペーン求人対応テーブルＴ６のそれぞれに追加する。

求人情報入力受付部２１は、求人主から求人情報の入力を受け付ける機能部である。ここで受け付けられる求人情報には、上述した求人主情報、採用条件、掲載開始日、掲載終了日などが含まれる。求人情報入力受付部２１は、受け付けた求人情報を所定のＸＭＬ形式で入力受付部１１に供給する。入力受付部１１は、供給された求人情報の内容を求人情報テーブルＴ３の各項目にマッピングすることにより、供給された求人情報を求人情報テーブルＴ３に追加する。

図１０は、入力受付部１１が行う求人情報入力受付処理の処理フローを示すフロー図である。同図に示すように、入力受付部１１はまず、採用管理サーバ２０からＸＭＬ形式の求人情報を受信する（ステップＳ１）。この求人情報の詳しい内容は、採用管理サーバ２０の仕様によってまちまちである。そこで入力受付部１１は、受信した求人情報の各項目を求人情報テーブルＴ３の項目にマッピングする処理を行う（ステップＳ２）。そして、その結果を用いて求人情報テーブルＴ３に新規レコードを追加することにより、求人情報テーブルＴ３に新たな求人情報を追加する（ステップＳ３）。

図３に戻る。フィード生成部１３は、求人媒体サーバ３０を識別するための求人媒体ＩＤと、求人情報を識別するための採用管理サイトＩＤ及び求人ＩＤの組み合わせとを含むフィード情報を生成する機能部である。

図１１は、フィード生成部１３が行うフィード情報生成処理の処理フローを示すフロー図である。フィード生成部１３は、例えば１日に１回以上のバッチ処理により、このフィード情報生成処理を実行するよう構成される。以下、この図１１を参照しながら、フィード情報生成処理について詳細に説明する。

フィード生成部１３は、キャンペーンテーブルＴ５内の各レコード（キャンペーン情報）について、ステップＳ１１～Ｓ２１の処理を実行する（ステップＳ１０）。以下、処理対象となっているレコードにかかるキャンペーンを「注目キャンペーン」と称する。注目キャンペーンについての処理を開始したフィード生成部１３はまず、注目キャンペーンにかかる入札が有効であるか否かを判定する（ステップＳ１１）。この判定の結果は、具体的には、当日が入札開始日と入札終了日の間の日付であり、かつ、入札有効フラグが有効となっている場合に肯定となり、そうでない場合に否定となる。フィード生成部１３は、ステップＳ１１において有効であると判定した場合にはステップＳ１２に処理を移し、有効でないと判定した場合には次のレコードに処理を移す。

次にフィード生成部１３は、複数の求人媒体サーバ３０のそれぞれにおける求人主に対する課金の発生状況に基づいて、連携を中止するか否かを決定する処理を行う（ステップＳ１２～Ｓ１５）。具体的に説明すると、フィード生成部１３はまず、アカウントテーブルＴ１を参照することにより、注目キャンペーンに対応するアカウントＩＤがアカウント単位で連携中止となっているか否かを確認する（ステップＳ１２）。具体的には、アカウントＩＤに対応付けて記憶される連携中止フラグを確認する。そして、その結果に基づいて連携を中止するか否かを判定し（ステップＳ１３）、連携中止フラグがＦａｌｓｅであればステップＳ１４に処理を移す一方、Ｔｒｕｅになっていれば次のレコードに処理を移す。

図１２は、連携中止フラグを設定するためのアカウント単位連携中止処理の処理フローを示すフロー図である。この処理は、求人主のチャージ残高と、求人主の日次予算消化額の平均値とに基づき、連携を中止するか否かを決定するための処理であり、図３に示した成果処理部１５により、課金が発生したアカウントについて実行される。以下、図１２を参照しながら、アカウント単位連携中止処理について詳細に説明する。

成果処理部１５は、課金が発生したアカウント（以下「注目アカウント」という）のチャージ履歴テーブルＴ２を参照することにより、注目アカウントのチャージ残高を取得する（ステップＳ３０）。次に成果処理部１５は、注目アカウントに対応する日々の消費額を成果テーブルＴ１０から読み出し、読み出した消費額に基づいて、注目アカウントの日次予算消化額を算出する（ステップＳ３１）。そして、その平均値（平均日次予算消化額）を算出する（ステップＳ３２）。

続いて成果処理部１５は、平均日次予算消化額に予め定められている設定日数を乗算し、得られた金額がチャージ残高を上回っているか否かを判定する（ステップＳ３３）。設定日数には、１以上の値が予め設定される。判定の結果、上回っていると判定した成果処理部１５は、アカウントテーブルＴ１において注目アカウントの連携中止フラグにＴｒｕｅを設定する（ステップＳ３４）。一方、上回っていないと判定した成果処理部１５は、アカウントテーブルＴ１において注目アカウントの連携中止フラグにＦａｌｓｅを設定する（ステップＳ３５）。アカウント単位連携中止処理は、ここまでの処理によって終了する。

図１１に戻る。ステップＳ１４に遷移したフィード生成部１３は、キャンペーンの月額予算と、求人主の日次予算消化額の平均値とに基づいて、注目キャンペーンに紐付けられている１以上の求人情報の連携を中止するか否かを決定するためのキャンペーン単位連携中止処理を実行する。

図１３は、ステップＳ１４においてフィード生成部１３が行うキャンペーン単位連携中止処理の処理フローを示すフロー図である。以下、この図１３を参照しながら、キャンペーン単位連携中止処理について詳細に説明する。

フィード生成部１３はまず、注目キャンペーンの月額予算をキャンペーンテーブルから取得する（ステップＳ４０）。具体的には、ＣＰＡを利用するキャンペーンであればＣＰＡ予算情報に含まれる月間課金額の最大値を、ＣＰＣを利用するキャンペーンであればＣＰＣ予算情報に含まれる月間課金額の最大値をそれぞれ取得する。

次にフィード生成部１３は、注目キャンペーンに対応する日々の消費額を成果テーブルＴ１０から読み出し、読み出した消費額に基づいて、注目キャンペーンの日次予算消化額を算出する（ステップＳ４１）。そして、その平均値（平均日次予算消化額）を算出する（ステップＳ４２）。

続いてフィード生成部１３は、平均日次予算消化額に予め定められている設定日数を乗算してなる値を当月の累計予算消化額に加算し、得られた金額がステップＳ４０で取得した月額予算を上回っているか否かを判定する（ステップＳ４３）。設定日数には、１以上の値が予め設定される。フィード生成部１３は、ステップＳ４３において上回っていると判定した場合にのみ注目キャンペーンの連携中止を決定し（ステップＳ４４）、処理を終了する。

図１１に戻る。キャンペーン単位連携中止処理を終了したフィード生成部１３は、処理の結果として注目キャンペーンの連携中止を決定したか否かを判定し（ステップＳ１５）、決定していない場合にはステップＳ１６に処理を移す一方、決定した場合には次のレコードに処理を移す。

次にフィード生成部１３は、注目キャンペーンのこれまでの成果に応じて、コンバージョン単価（具体的には、ＣＰＡコンバージョン単価及びＣＰＣコンバージョン単価）を調整する（ステップＳ１６）。具体的に説明すると、例えばＣＰＡコンバージョン単価は、キャンペーンテーブルＴ５に記憶されるＣＰＡ目標応募単価に任意の調整率を乗算することによって算出される値であり、フィード生成部１３は、この調整率をキャンペーンテーブルＴ５に記憶されるＣＰＡ応募単価調整範囲の範囲内で調整することにより、ＣＰＡコンバージョン単価の調整を行う。ＣＰＣコンバージョン単価についても同様である。

具体的な例を挙げると、まず課金方式がＣＰＡとなる求人媒体に対して注目キャンペーンの連携を初めて行う場合（つまり、キャンペーン成果テーブルＴ１１内に対応するレコードがない場合）、フィード生成部１３は、キャンペーンテーブルＴ５内に記憶されているＣＰＡ目標応募単価に最小の調整率（例えば８０％）を乗算することによって得られる値をＣＰＡコンバージョン単価とする。そして、その結果として得られたインプレッション数が所定の目標値より小さい場合には、所定値（例えば５％）だけ調整率を引き上げて、新たなＣＰＡコンバージョン単価を算出する。こうしてフィード生成部１３が調整率を徐々に引き上げていくことにより、不必要な予算をかけずに、所定の目標値以上のインプレッション数を実現することが可能になる。なお、フィード生成部１３は、インプレッション数が所定の目標値に比べて大きくなりすぎた場合（例えば、所定の目標値に所定の倍率を乗じてなる値を超えた場合）には、調整率を引き下げることとしてもよい。

次にフィード生成部１３は、求人情報の連携先となる求人媒体サーバ３０を決定するための連携先媒体決定処理を実行する（ステップＳ１７）。この処理において求人媒体サーバ３０は、複数の求人媒体それぞれの下限入札単価（求人媒体テーブルＴ７内に規定されるデフォルト下限入札単価、又は、下限入札単価テーブルＴ９内に含まれる下限入札単価）と、求人主により入力された求人情報のコンバージョン単価（ステップＳ１６で調整したもの）とに基づいて、求人情報の連携先となる１以上の求人媒体サーバ３０を決定する処理を行う。

図１４及び図１５は、ステップＳ１７においてフィード生成部１３が行う連携先媒体決定処理の処理フローを示すフロー図である。以下、この図１３を参照しながら、連携先媒体決定処理について詳細に説明する。

フィード生成部１３は、求人媒体テーブルＴ７内の各レコードについて、ステップＳ５１～Ｓ６０の処理を実行する（ステップＳ５０）。以下、処理対象となっているレコードにかかる求人媒体を「注目求人媒体」と称する。注目求人媒体についての処理を開始したフィード生成部１３は、下限入札単価及びコンバージョン単価に基づく処理を行う前にまず、注目求人媒体の課金方式が注目キャンペーンの課金方式と一致するか否かを判定する（ステップＳ５１）。この判定の結果は、求人媒体テーブルＴ７に設定されている注目求人媒体の入札プランがＣＰＡであり、かつ、キャンペーンテーブルＴ５に設定されている注目キャンペーンのＣＰＡプラン利用フラグがＴｒｕｅである場合、及び、求人媒体テーブルＴ７に設定されている注目求人媒体の入札プランがＣＰＣであり、かつ、キャンペーンテーブルＴ５に設定されている注目キャンペーンのＣＰＣプラン利用フラグがＴｒｕｅである場合のいずれかに肯定となり、その他の場合に否定となる。

ステップＳ５１で肯定的な判定結果を得たフィード生成部１３は、ステップＳ５２に処理を移す。一方、ステップＳ５９で否定的な判定結果を得たフィード生成部１３は、図１５に示すステップＳ６０に処理を移し、注目求人媒体を連携先から除外したうえで（ステップＳ６０）、次のレコードに処理を移す。

ステップＳ５２においてフィード生成部１３は、注目キャンペーンが注目求人媒体に対応付けてブラックリストテーブルＴ８内に記憶されている拒否条件に該当するか否かを判定する（ステップＳ５２）。具体的に説明すると、フィード生成部１３は、注目キャンペーンに紐付く各求人情報について、ブラックリストテーブルＴ８内の項目名により示される求人情報内の項目に、該項目名に対応付けてブラックリストテーブルＴ８内に記憶されるキーワードが含まれているか否かを判定する。そして、含まれていると判定した場合、フィード生成部１３は、注目キャンペーンがブラックリストテーブルＴ８内に記憶されている拒否条件に該当すると判定する。

ステップＳ５２で否定的な判定結果を得たフィード生成部１３は、ステップＳ５３に処理を移す。一方、ステップＳ５１で肯定的な判定結果を得たフィード生成部１３は、図１５に示すステップＳ６０に処理を移し、注目求人媒体を連携先から除外したうえで（ステップＳ６０）、次のレコードに処理を移す。

ステップＳ５３においてフィード生成部１３は、注目求人媒体に関して下限入札単価テーブルＴ９が存在するか否かを判定する（ステップＳ５３）。その結果、存在すると判定した場合にはステップＳ５４に処理を移し、存在しないと判定した場合には図１５のステップＳ５７に処理を移す。

ステップＳ５４に処理を進めたフィード生成部１３は、注目キャンペーンに紐付けられている１以上の求人情報のそれぞれについて、対応する下限入札単価を下限入札単価テーブルＴ９から取得し、取得した下限入札単価と、ステップＳ１６での調整後のコンバージョン単価とに基づいて、注目求人媒体を連携先から除外するか否かを決定する処理を行う。具体的に説明すると、フィード生成部１３は、注目求人媒体に対応する下限入札単価テーブルＴ９に含まれる条件ごとに、ステップＳ５５，Ｓ５６の処理を行う。

ステップＳ５５は、注目キャンペーンに含まれる１以上の求人情報のそれぞれについて、条件を満たすか否かを判定する処理である。ここでいう条件は、例えば、雇用形態に「正社員」を含み、かつ、職種に「飲食業」を含む、というようなものである。条件を満たす求人情報があると判定した場合、フィード生成部１３は、注目キャンペーンのコンバージョン単価（ステップＳ１６で調整したもの。注目求人媒体の課金方式がＣＰＡである場合にはＣＰＡコンバージョン単価。注目求人媒体の課金方式がＣＰＣである場合にはＣＰＣコンバージョン単価）が、該条件に対応付けて下限入札単価テーブルに記憶される下限入札単価以上となっているか否かをさらに判定し（ステップＳ５６）、下限入札単価以上となっていると判定した場合には次の条件に処理を移す一方、下限入札単価以上になっていないと判定した場合には、図１５に示すステップＳ６０に処理を移し、注目求人媒体を連携先から除外したうえで（ステップＳ６０）、次のレコードに処理を移す。フィード生成部１３が以上の処理を行うことにより、求人媒体側から見て、条件ごとに下限入札単価を設定し、その下限入札単価を満たしていないキャンペーンを連携対象から除外することが可能になる。ステップＳ６０に移ることなくステップＳ５４の繰り返し処理をすべて完了したフィード生成部１３は、図１５のステップＳ５８に処理を移す。

図１５に移り、ステップＳ５６においてフィード生成部１３は、注目キャンペーンのコンバージョン単価（ステップＳ１６で調整したもの。注目求人媒体の課金方式がＣＰＡである場合にはＣＰＡコンバージョン単価。注目求人媒体の課金方式がＣＰＣである場合にはＣＰＣコンバージョン単価）が、注目求人媒体のデフォルト下限入札単価となっているか否かを判定する（ステップＳ５７）。そして、デフォルト下限入札単価以上となっていると判定した場合にはステップＳ５８に処理を移す一方、デフォルト下限入札単価以上になっていないと判定した場合には、ステップＳ６０に処理を移し、注目求人媒体を連携先から除外したうえで（ステップＳ６０）、次のレコードに処理を移す。

ステップＳ５８においてフィード生成部１３は、注目キャンペーンが注目求人媒体の特化項目に該当するか否かを判定する（ステップＳ５８）。特化項目は、求人サイトが特定の求人に特化している場合に、その特化している求人の内容を示す情報であり、例えば、特定の勤務地（関東のみなど）を示す情報、特定の雇用形態（アルバイトのみなど）を示す情報、特定の職種（看護師のみなど）を示す情報などにより構成される。フィード生成部１３は、注目キャンペーンの応募者ターゲット情報や、注目キャンペーンに紐付く各求人情報の採用条件を参照することにより、ステップＳ５８の判定を行う。そして、注目キャンペーンが注目求人媒体の特化項目に該当すると判定した場合、ステップＳ５９に処理を移す。注目求人媒体に特化項目がない場合にも、同様にステップＳ５９に処理を移す。一方、注目キャンペーンが注目求人媒体の特化項目に該当しないと判定した場合には、フィード生成部１３はステップＳ６０に処理を移し、注目求人媒体を連携先から除外したうえで（ステップＳ６０）、次のレコードに処理を移す。

ステップＳ５９においてフィード生成部１３は、注目キャンペーンが注目求人媒体の連携除外条件に該当するか否かを判定する（ステップＳ５９）。連携除外条件は、求人サイトが特定の求人を除外している場合に、その除外している求人の内容を示す情報である。連携除外条件の具体的な内容は、特化項目と同様でよい。フィード生成部１３は、注目キャンペーンの応募者ターゲット情報や、注目キャンペーンに紐付く各求人情報の採用条件を参照することにより、ステップＳ５９の判定を行う。そして、注目キャンペーンが注目求人媒体の連携除外条件に該当しないと判定した場合、ステップＳ６０の処理を実行せず次のレコードに処理を移す。注目求人媒体に連携除外条件がない場合にも、同様にステップＳ６０の処理を実行せず次のレコードに処理を移す。一方、注目キャンペーンが注目求人媒体の連携除外条件に該当すると判定した場合には、フィード生成部１３はステップＳ６０に処理を移し、注目求人媒体を連携先から除外したうえで（ステップＳ６０）、次のレコードに処理を移す。

ステップＳ５０の繰り返し処理をすべて完了したフィード生成部１３は、ここまでの処理により連携先から除外されずに残った求人媒体を連携先として決定し（ステップＳ６１）、連携先媒体決定処理を終了する。

図１１に戻る。連携先媒体決定処理を終了したフィード生成部１３は、次に、注目キャンペーンに紐付く１以上の求人情報のそれぞれに対し、求人サイトにおける表示の優先順位を付与する表示優先順位付与処理を実行する（ステップＳ１８）。この処理は、求人媒体テーブルＴ７内に予め設定される優先順位決定ロジック情報に基づいて各求人情報の優先順位を算出することによって、実行される。

図１６は、ステップＳ１８においてフィード生成部１３が行う表示優先順位付与処理の処理フローを示すフロー図である。以下、この図１６を参照しながら、表示優先順位付与処理について詳細に説明する。

フィード生成部１３は、連携対象として決定した各求人媒体について、ステップＳ７１～Ｓ７５の処理を実行する（ステップＳ７０）。以下、処理対象となっているレコードにかかる求人媒体を「注目求人媒体」と称する。注目求人媒体についての処理を開始したフィード生成部１３はまず、求人媒体テーブルＴ７を参照することにより、注目求人媒体の優先順位決定ロジック情報を取得する（ステップＳ７１）。優先順位決定ロジック情報は優先順位の算出方法を定める情報であり、ＪＳＯＮ(JavaScript Object Notation)などのデータ記述言語によって記述される。

図１７は、優先順位の算出方法の一例を示す図である。この例は、ツリー構造により算出されるスコアを優先順位として用いる例である。ツリー構造による算出とは、予め定められた条件によって異なるスコアを算出するというスコアの算出ロジックをいう。より具体的に言えば、スコアごとの条件を予め決めておき、最も高いスコア（又は最も低いスコア）から順に、条件を満たすものにそのスコアを付与する、という算出のやり方を指す。

図１７の例に則して説明すると、この例は、最も高いスコア５から順にスコアを付与するように構成されている。スコア５には勤務地が東京都であるという条件が付与されており、勤務地が東京都である求人情報にスコア５が付与される。次のスコア４には勤務地が大阪府であるという条件が付与されており、勤務地が東京都ではないが大阪府である求人情報にスコア４が付与される。以下同様に、スコア３，４にはそれぞれ勤務地が愛知県、福岡県であるという条件が付与されており、勤務地が東京都でも大阪府でもないが愛知県である求人情報にスコア３が、勤務地が東京都でも大阪府でも愛知県でもないが福岡県である求人情報にスコア２がそれぞれ付与されることになる。スコア１の条件は、図１７には明記していないが勤務地がその他の地であるというものであり、勤務地が東京都でも大阪府でも愛知県でも福岡県でもない求人情報にはスコア１が付与されることになる。

図１８は、優先順位の算出方法の他の一例を示す図である。この例は、相対評価により算出されるスコアを優先順位として用いる例である。相対評価による算出とは、注目求人媒体に対して連携される一連の求人情報内における算出対象の求人情報の位置に基づいてスコアを算出するというスコアの算出ロジックをいう。一連の求人情報の選び方は特に限定されず、例えば、注目キャンペーンに紐付けられた一連の求人情報であってもよいし、求人連携サーバ１０が一定期間内に注目求人媒体に連携した一連の求人情報であってもよい。

図１８の例に則して説明すると、この例は、給与水準に応じてスコアを付与するように構成されている。一連の求人情報の中で給与水準が上位２０％に入る求人情報にはスコア５が、上位２０％には入らないが上位４０％に入る求人情報にはスコア４が、上位４０％には入らないが上位６０％に入る求人情報にはスコア３が、上位６０％には入らないが上位８０％に入る求人情報にはスコア２が、上位８０％にも入らない求人情報にはスコア１が、それぞれ付与される。

図１６に戻る。優先順位決定ロジック情報を取得したフィード生成部１３は、注目キャンペーンに紐付けられている各求人情報について、ステップＳ７３～Ｓ７５の処理を行う（ステップＳ７２）。具体的に説明すると、フィード生成部１３はまず、優先順位決定ロジック情報に含まれる１以上の項目のそれぞれについて、そのスコアを算出する（ステップＳ７３，Ｓ７４）。例えば、図１７に示した算出方法によるスコアと、図１８に示した算出方法によるスコアとのそれぞれを算出する。そして、算出した１以上のスコアの加重平均値を算出し、その求人情報の優先順位として出力する（ステップＳ７５）。加重平均値を算出する際に使用する重み付けの値は、優先順位決定ロジック情報内に記述される。こうして注目キャンペーンに紐付けられているすべての求人情報について優先順位を算出したフィード生成部１３は、表示優先順位付与処理を終了する。

図１１に戻る。表示優先順位付与処理を終了したフィード生成部１３は次に、注目キャンペーンに紐付けられている各求人情報について、ステップＳ２０，Ｓ２１の処理を行う（ステップＳ１９）。具体的には、ステップＳ１７で連携先として決定した１以上の求人媒体のそれぞれについて、ステップＳ２１の処理を行う。ステップＳ２１においてフィード生成部１３は、対応する求人情報に関する情報をフィード情報テーブルＴ４に挿入し、有効フラグをオンにする処理を行う（ステップＳ２１）。このときフィード生成部１３は、フィード情報テーブルＴ４のコンバージョン単価及び表示優先順位情報に、ステップＳ１６で調整したコンバージョン単価（対応する求人媒体の課金方式がＣＰＡである場合にはＣＰＡコンバージョン単価。対応する求人媒体の課金方式がＣＰＣである場合にはＣＰＣコンバージョン単価）及びステップＳ１８で出力した優先順位のそれぞれを設定する。ステップＳ１９の繰り返し処理を終了したフィード生成部１３は、フィード情報生成処理を終了する。

図３に戻る。フィード連携部１４は、フィード生成部１３が生成したフィード情報に基づき、求人情報を１以上の求人媒体サーバ３０のそれぞれに対して送信する機能部である。

図１９は、フィード連携部１４が行うフィード情報送信処理の処理フローを示すフロー図である。フィード連携部１４は、例えば１日に１回以上のバッチ処理により、このフィード情報送信処理を実行するよう構成される。特にフィード連携部１４は、フィード生成部１３による１日分のフィード情報生成処理が完了した後に、フィード情報送信処理を実行することが好ましい。以下、この図１９を参照しながら、フィード情報送信処理について詳細に説明する。

フィード連携部１４はまず、キャンペーンテーブルＴ５に記憶されるすべてのキャンペーンの入札ステータスを「連携待ち」に設定する（ステップＳ８０）。続いてフィード連携部１４は、フィード情報テーブルＴ４から有効フラグがオンのフィード情報を取得する（ステップＳ８１）。そして、取得した１以上のフィード情報のそれぞれについて、ステップＳ８３～Ｓ８８の処理を実行する（ステップＳ８２）。以下、処理対象となっているフィード情報を「注目フィード情報」と称する。

具体的に説明すると、フィード連携部１４はまず、注目フィード情報に対応するキャンペーン情報（注目フィード情報内のキャンペーンＩＤにより特定されるキャンペーン情報）及び求人情報（注目フィード情報内の採用管理サイトＩＤ及び求人ＩＤにより特定される求人情報）の各項目を、求人媒体（フィード情報内の求人媒体ＩＤにより特定される求人媒体）側の項目にマッピングする（ステップＳ８３）。求人媒体側の項目にはランディングページのＵＲＬが含まれるが、フィード連携部１４はこの項目に対し、課金方式がＣＰＡである求人媒体については求人情報内の「ランディングページのＵＲＬ（ＣＰＡ）」をマッピングし、課金方式がＣＰＣである求人媒体については求人情報内の「ランディングページのＵＲＬ（ＣＰＣ）」をマッピングする。

次にフィード連携部１４は、マッピング後の項目を含むｃｓｖ(comma separated value)ファイルを生成し（ステップＳ８４）、ＳＦＴＰ(SSH File Transfer Protocol)により、対応する求人媒体サーバ３０に送信する（ステップＳ８５）。なお、ｃｓｖファイル以外の形式を用いて送信してもよいこと、及び、ＳＦＴＰ以外の通信方式を用いて送信してもよいことは勿論である。

続いてフィード連携部１４は、注目フィード情報内の有効フラグをオフに設定する（ステップＳ８６）。フィード連携部１４はさらに、注目フィード情報に対応するキャンペーンの入札ステータスを「連携中」に設定する（ステップＳ８７）とともに、同キャンペーンの初回入札日が未記入であれば初回入札日として本日の日付を設定し（ステップＳ８８）、注目フィード情報についての処理を終了する。ステップＳ８２の繰り返し処理を終了したフィード連携部１４は、フィード情報送信処理を終了する。

図３に戻る。フィード表示制御部３１は、フィード連携部１４により送信された求人情報を受信し、求人サイトの広告枠に表示する機能部である。フィード表示制御部３１は、上述した開放率に従い、求人連携サーバ１０から受信した求人広告の表示を行う。また、受信した求人情報に含まれる表示優先順位情報に基づいて、求人情報の表示順を制御する。さらに、求人連携サーバ１０が入札を行うタイプのものである場合には、フィード表示制御部３１は、受信した求人情報に含まれるコンバージョン単価に基づいて求人広告枠の入札を行い、その結果にも応じて求人情報の表示順を制御する。

図２０は、フィード表示制御部３１により生成される求人サイトの表示画面の例を示す図である。この表示画面は、求人サイトのユーザ（求職者）が所定の検索画面においてキーワードを入力して検索を行い、その結果として求職者端末４０のディスプレイに表示される画面である。同図に示すように、この表示画面には、求人情報のヒット数５０と、ヒット数５０が多い場合に表示ページを切り替えるためのページネーション５１と、検索結果をいくつかの項目でソートするためのソートボタン５２と、列挙される１以上の広告枠５３とを含んで構成される。

広告枠５３内には、求人情報の概要の他、ランディングページへのリンクボタン５４が表示される。このリンクボタン５４には、ランディングページのＵＲＬが埋め込まれる。また、求人連携サーバ１０から連携した求人情報に関しては、広告枠５３内に、採用管理サーバ２０からの連携であることを示す連携表示情報５５が表示される。図２０には、「ＪＯＢＯＬＥ」という文字列を連携表示情報５５として使用する例を示しているが、他の文字列又は画像を使用しても構わない。

図３に戻る。クリック受付部３２は、ランディングページへのリンクボタン（例えば、図２０に示したリンクボタン５４）のクリックを受け付ける機能部である。ＣＰＣを利用する求人情報については、クリック受付部３２は、リンクボタンに埋め込まれているＵＲＬへのアクセスを発生させるとともに、求人情報内のコンバージョン単価に応じた課金を発生させる。求人情報が求人連携サーバ１０から連携されたものである場合、クリック受付部３２は、課金が発生したことを、課金額とともに求人連携サーバ１０内の成果処理部１５に通知する。一方、ＣＰＡを利用する求人情報については、クリック受付部３２は、リンクボタンに埋め込まれているＵＲＬへのアクセスを発生させる処理のみを行う。

求人詳細情報表示制御部２２，３３はそれぞれ、クリック受付部３２によりランディングページへのアクセスが発生したことに応じて、ランディングページを求職者端末４０のブラウザにロードする機能部である。図示していないが、ランディングページには、求人情報のより詳細な内容の他、求職者が求人に応募するための応募ページが含まれる。

応募受付部２３，３４は、上記応募ページにおいて求職者の応募を受け付ける機能部であり、受け付けた内容を応募情報取得部２４に供給する役割を果たす。応募情報取得部２４は、こうして供給された応募情報を求人主に提示する。また、応募受付部３４は、この応募を受け付けたことに応じて、求人情報内のコンバージョン単価に応じた課金を発生させる。そして、課金が発生したことを、課金額とともに求人連携サーバ１０内の成果処理部１５に通知する。

成果処理部１５は、フィード連携部１４が求人媒体サーバ３０に連携した求人情報の成果（インプレッション数、クリック数、応募数、消費額）を取得して１日単位で集計し、成果テーブルＴ１０及びキャンペーン成果テーブルＴ１１に格納する機能部である。成果処理部１５は、フィード表示制御部３１からインプレッション数を、クリック受付部３２からの課金の通知回数に基づきクリック数を、応募受付部３４からの課金の通知回数に基づき応募数を、それぞれ取得するよう構成される。また、成果処理部１５は、クリック受付部３２又は応募受付部３４から通知される課金額に基づき、消費額を取得するよう構成される。成果処理部１５はさらに、応募受付部３４から課金が通知される都度、対応する求人主のチャージ残高から課金された金額を減算する処理（具体的には、チャージ履歴テーブルＴ２の消化金額に金額を加算する処理）を行うとともに、減算後のチャージ残高を用いて、図１２を参照して説明したアカウント単位連携中止処理も行う。

以上説明したように、本実施の形態による求人連携サーバ１０及び求人システム１によれば、複数の求人サイトそれぞれの下限入札単価と、求人主により入力された求人情報のコンバージョン単価とに基づいて、求人情報の連携先となる１以上の求人媒体サーバ３０を決定し、決定した１以上の求人媒体サーバ３０のそれぞれに対して求人情報を連携しているので、入札条件の合致する１以上の求人媒体サーバ３０に対し、求人情報を柔軟に連携することができる。したがって、求人広告に関して、高い広告効果を実現することが可能になる。

また、複数の求人媒体サーバ３０のそれぞれが有する連携する求人情報の１以上の条件（ブラックリスト、条件ごとに異なる下限入札単価など）にも基づいて連携先の求人媒体サーバ３０を決定しているので、連携する求人情報に対し、求人媒体サーバ３０側で様々な条件を設定することが可能になる。

また、フィード生成部１３は、複数の求人媒体サーバ３０のそれぞれについて予め設定される優先順位決定ロジック情報に基づいて求人情報の優先順位を算出し、フィード連携部１４は、求人情報とともにこの優先順位を１以上の求人媒体サーバ３０のそれぞれに対して送信しているので、求人媒体サーバ３０は、優先順位に基づいて求人情報の表示順を調整することができる。したがって、求人サイトにおける求人情報の表示を、求人主の要望や求人サイトの特徴に応じて柔軟に調整することが可能になる。

また、フィード生成部１３は、複数の求人媒体サーバ３０のそれぞれにおける求人主に対する課金の発生状況に基づいて連携を中止するか否かを決定し、連携を中止する場合にフィード情報を生成しないので、課金の発生状況に応じて、求人サイトへの求人情報の連携を制御することが可能になる。

次に、本発明の第２の実施の形態による求人システム１について、説明する。本実施の形態による求人システム１は、求人主（採用管理サーバ２０）から入力される求人情報内に含まれる職種を、求人媒体サーバ３０に入力可能な職種に変換する機能を有する点で第１の実施の形態による求人システム１と異なり、その他の点では、第１の実施の形態による求人システム１と同様である。以下、第１の実施の形態による求人システム１との相違点に着目して、本実施の形態による求人システム１を説明する。

図２１は、本実施の形態によるデータベース１２が図４に示した各テーブルに加えて記憶する各テーブルを示す図である。同図に示すように、本実施の形態によるデータベース１２は、１つのハブ職種マスタテーブルＴ２０と、複数の求人媒体サーバ３０のそれぞれに対応する複数の媒体職種マスタテーブルＴ２１とをさらに格納して構成される。

図２２（ａ）は、ハブ職種マスタテーブルＴ２０の構造を示す図であり、図２２（ｂ）は、媒体職種マスタテーブルＴ２１の構造を示す図である。これらの図から理解されるように、ハブ職種マスタテーブルＴ２０及び媒体職種マスタテーブルＴ２１はともに木構造のテーブルであり、各レコードに親ノードポインタ及び子ノードポインタが含まれる。ただし、ルートレコードの親ノードポインタはヌルである。また、１つのレコードに含まれる子ノードポインタは０個以上であればよく、１個でもよいし、複数個でもよい。

ハブ職種マスタテーブルＴ２０の各レコードは、職種を表す１つの単語を含んで構成される。運用型求人連携プラットフォームの担当者は、過去の求人情報や求人関係のＷＥＢサイトなどの資料を参照することによって普遍的な職種群（普遍的であることが期待できる職種群）を取得し、取得した職種群を用いてハブ職種マスタテーブルＴ２０を生成する。

媒体職種マスタテーブルＴ２１の各レコードは、対応する求人媒体サーバ３０に入力可能な職種を表す１つの単語と、その単語に対応するハブ職種マスタテーブルＴ２０内の職種を表す１つの単語とを含んで構成される。以下では、前者の単語を「職種（媒体）」と表記し、後者の単語を「職種（ハブ）」と表記して、これらを区別する場合がある。媒体職種マスタテーブルＴ２１に格納すべき職種（媒体）の具体的な内容は、求人サイトの担当者から運用型求人連携プラットフォームの担当者に通知される。運用型求人連携プラットフォームの担当者は、通知された各職種（媒体）に対応する職種（ハブ）を、ハブ職種マスタテーブルＴ２０を参照することによって決定する。そして、各職種（媒体）と、対応する職種（ハブ）とを対応付けて媒体職種マスタテーブルＴ２１に書き込むことによって、媒体職種マスタテーブルＴ２１を生成する。

本実施の形態による入力受付部１１（図３を参照）は、求人情報入力受付部２１から供給された求人情報を求人情報テーブルＴ３に追加する際、求人情報内に含まれる職種をハブ職種マスタテーブルＴ２０に記憶される職種に変換したうえで、求人情報テーブルＴ３への追加を実行するよう構成される。このために、本実施の形態による入力受付部１１には、職種の変換を可能にするためのパッチファイルが予め適用される。以下では、このパッチファイルの生成方法及び性能評価方法について説明した後、パッチファイルが適用された入力受付部１１によって実行される処理を詳しく説明する。

図２３は、本実施の形態による入力受付部１１に適用するためのパッチファイルを生成するためのパッチファイル生成処理を示す処理フロー図である。このパッチファイル生成処理は、求人連携サーバ１０によって実行されることとしてもよいし、その他の任意のコンピュータによって実行されることとしてもよい。以下では、各処理の実行主体を単に「コンピュータ」と称する。

パッチファイル生成処理を開始したコンピュータはまず、形式を統一した過去の求人情報と、ハブ職種マスタテーブルＴ２０とに基づき、職種間の関係性を表現するグラフモデルを生成する（ステップＳ１００）。また、コンピュータは、ＷＥＢサイトの記述内容に対して前処理を実施し（ステップＳ１０１）、前処理後のＷＥＢサイトの学習によりＷｏｒｄ２ｖｅｃモデルを生成する（ステップＳ１０２）。ステップＳ１０１で実行される前処理には、ＷＥＢサイトの記述内容の分かち書き、並びに、不要品詞及び不要単語の削除が含まれる。この点は、後述するステップＳ１０３，Ｓ１１０，Ｓ１３０の前処理についても同様である。ステップＳ１０２で実行される学習は、ステップＳ１０１による前処理後のファイルを入力としてＷｏｒｄ２ｖｅｃの実行ファイルを実行することによって、実行される。ステップＳ１０２を実行した結果として生成されるＷｏｒｄ２ｖｅｃモデルには、各単語の特徴ベクトルのリストが含まれる。

次にコンピュータは、求人関係の文書データに対して前処理を実施し（ステップＳ１０３）、前処理後の文書データの学習により、ステップＳ１０２で生成したＷｏｒｄ２ｖｅｃモデルを更新する（ステップＳ１０４）。求人関係の文書データは、例えば、運用型求人連携プラットフォームの運営者により過去に生成又は取得された文書から適宜選択されたものである。

続いてコンピュータは、ステップＳ１０４で更新したＷｏｒｄ２ｖｅｃモデルと、ハブ職種マスタテーブルＴ２０とに基づき、与えられた２つの職種が同じクラスに属するか否かを判定するためのペアワイズ分類器を生成する（ステップＳ１０５）。そしてコンピュータは、ステップＳ１００で生成したグラフモデルと、ステップＳ１０５で生成したペアワイズ分類器とに基づき、アンサンブル推定器を生成する（ステップＳ１０６）。具体的には、グラフモデルによる推定の結果と、ペアワイズ分類器による推定の結果とを多数決で統合することにより、アンサンブル推定器を生成する。

最後にコンピュータは、ステップＳ１０６で生成したアンサンブル推定器を用いて、入力受付部１１のパッチファイルを生成する（ステップＳ１０７）。こうして生成されたパッチファイルを入力受付部１１に適用することにより、入力受付部１１は、ステップＳ１０６で生成されたアンサンブル推定器に基づき、求人情報内の職種をハブ職種マスタテーブルＴ２０に記憶される職種に変換することができるようになる。

図２４は、パッチファイル生成処理により生成されたパッチファイルの性能評価を行うために用いる評価メトリクスを生成するための評価メトリクス生成処理を示す処理フロー図である。評価メトリクス生成処理も、求人連携サーバ１０によって実行されることとしてもよいし、その他の任意のコンピュータによって実行されることとしてもよい。以下では、各処理の実行主体を単に「コンピュータ」と称する。

コンピュータはまず、評価用のデータに対して前処理を実行する（ステップＳ１１０）。評価用のデータは、例えば、評価のために仮に作成した求人情報である。次にコンピュータは、パッチファイル生成処理により生成されたパッチファイルを用いて、前処理後の評価用のデータを評価する（ステップＳ１１１）。すなわち、前処理後の評価用のデータに含まれる職種を、ハブ職種マスタテーブルＴ２０に記憶される職種に変換する。そして、ステップＳ１１１の評価の結果に基づき、人間が見やすいように評価結果を加工した情報である評価メトリクスを生成する（ステップＳ１１２）。こうして生成された評価メトリクスを参照することにより、運用型求人連携プラットフォームの担当者は、パッチファイル生成処理により生成されたパッチファイルの性能を評価することが可能になる。

図２５は、パッチファイル生成処理により生成されたパッチファイルを適用された入力受付部１１によって実行される求人情報入力受付処理の処理フローを示すフロー図である。同図に示す処理は、ステップＳ２とステップＳ３との間に職種変換処理（ステップＳ１２０）が挿入される点で、図１０に示した求人情報入力受付処理と異なっている。

図２６は、図２５のステップＳ１２０において入力受付部１１が行う職種変換処理の処理フローを示すフロー図である。同図に示すように、入力受付部１１はまず、図２５のステップＳ２の処理において「採用条件」内の「職種」にマッピングした項目の内容に対し、前処理を実行する（ステップＳ１３０）。次に入力受付部１１は、前処理後の各職種の特徴ベクトルを取得する（ステップＳ１３１）とともに、ハブ職種マスタテーブルＴ２０に含まれる各職種の特徴ベクトルを取得する（ステップＳ１３２）。具体的には、入力受付部１１は、各職種の特徴ベクトルのリストを含むＷｏｒｄ２ｖｅｃモデルを生成すればよい。

続いて入力受付部１１は、パッチファイル生成処理により生成されたアンサンブル推定器を用い、求人情報内の各職種について、最も近いハブ職種マスタテーブルＴ２０内の職種を出力する（ステップＳ１３３）。職種変換処理は、ここまでの処理で終了する。入力受付部１１は、図２５のステップＳ３において、求人情報に含まれていた各職種に代え、ステップＳ１３３で出力された職種を求人情報テーブルＴ３に書き込む。これにより、求人情報内の職種がハブ職種マスタテーブルＴ２０に含まれる職種に変換される。

本実施の形態によるフィード連携部１４（図３を参照）は、求人情報テーブルＴ３内に書き込まれている求人情報を１以上の求人媒体サーバ３０のそれぞれに対して送信する際、求人情報内の職種（ハブ）を、対応する媒体職種マスタテーブルＴ２１の職種（媒体）にさらに変換する処理を行う。

図２７は、本実施の形態によるフィード連携部１４が行うフィード情報送信処理の処理フローを示すフロー図である。同図に示す処理は、ステップＳ８３とステップＳ８４との間に職種変換処理（ステップＳ１４０）が挿入される点で、図１９に示したフィード情報送信処理と異なっている。

ステップＳ１４０においてフィード連携部１４は、ステップＳ８３で職種にマッピングした項目の内容を、対応する媒体職種マスタテーブルＴ２１内の職種に変換する処理を行う。具体的には、ステップＳ８３で職種にマッピングした項目の内容をキーとして、対応する媒体職種マスタテーブルＴ２１の職種（ハブ）を検索し、ヒットしたレコード内の職種（媒体）を取得する。その後のステップＳ１４１においてフィード連携部１４は、ステップＳ８３で職種にマッピングした項目の内容に代えて、ステップＳ１４０で取得した職種（媒体）をｃｓｖファイルに書き込む。これにより、求人情報に含まれる職種を各求人媒体サーバ３０に入力可能な職種に変換したうえで、各求人媒体サーバ３０に求人情報を連携することが可能になる。

以上説明したように、本実施の形態による求人システム１によれば、求人主（採用管理サーバ２０）から入力される求人情報内に含まれる職種を各求人媒体サーバ３０に入力可能な職種に変換したうえで、各求人媒体サーバ３０に求人情報を連携することが可能になる。したがって、求人サイトへの求人情報の連携をスムーズに行うことが可能になる。

以上、本発明の好ましい実施の形態について説明したが、本発明はこうした実施の形態に何等限定されるものではなく、本発明が、その要旨を逸脱しない範囲において、種々なる態様で実施され得ることは勿論である。

１ 求人システム
２ ネットワーク
１０ 求人連携サーバ
１１ 入力受付部
１２ データベース
１３ フィード生成部
１４ フィード連携部
１５ 成果処理部
２０ 採用管理サーバ
２１ 求人情報入力受付部
２２，３３ 求人詳細情報表示制御部
２３，３４ 応募受付部
２４ 応募情報取得部
３０ 求人媒体サーバ
３１ フィード表示制御部
３２ クリック受付部
４０ 求職者端末
５０ ヒット数
５１ ページネーション
５２ ソートボタン
５３ 広告枠
５４ リンクボタン
５５ 連携表示情報
１０１ プロセッサ
１０２ 記憶装置
１０３ 通信装置
１０４ 入力装置
１０５ 出力装置
１０６ バス
Ｔ１ アカウントテーブル
Ｔ２ チャージ履歴テーブル
Ｔ３ 求人情報テーブル
Ｔ４ フィード情報テーブル
Ｔ５ キャンペーンテーブル
Ｔ６ キャンペーン求人対応テーブル
Ｔ７ 求人媒体テーブル
Ｔ８ ブラックリストテーブル
Ｔ９ 下限入札単価テーブル
Ｔ１０ 成果テーブル
Ｔ１１ キャンペーン成果テーブル
Ｔ２０ ハブ職種マスタテーブル
Ｔ２１ 媒体職種マスタテーブル

Claims (11)

1. それぞれ求人サイトを構成する複数の求人媒体サーバと通信可能に構成された求人連携サーバであって、
   求人情報、及び、該求人情報に対して応募があった場合に発生する課金の額又は該求人情報に対してランディングページへの遷移が行われた場合に発生する課金の額であるコンバージョン単価の目標値を含むキャンペーン情報の求人主による入力を受け付け、
   前記複数の求人媒体サーバのそれぞれから、求職者端末の画面に前記求人情報が表示された回数を示すインプレッション数を取得し、
   前記インプレッション数が所定の目標値以上となるように前記コンバージョン単価の調整率を決定し、
   決定した前記調整率を前記コンバージョン単価の目標値に乗算することによってコンバージョン単価を算出し、
   前記複数の求人媒体サーバのそれぞれについて下限入札単価を記憶する下限入札単価テーブルから、前記複数の求人媒体サーバのそれぞれについて前記下限入札単価を取得し、
   前記複数の求人媒体サーバのうち、算出した前記コンバージョン単価が、対応する前記下限入札単価以上である１以上の前記求人媒体サーバを前記求人情報の連携先として決定し、
   連携先として決定した前記１以上の前記求人媒体サーバのそれぞれに対して、算出した前記コンバージョン単価及び前記求人情報に含まれる情報を送信する、
   求人連携サーバ。
2. 前記複数の求人媒体サーバのそれぞれに対応付けて、それぞれ項目名及びキーワードを含む１以上の拒否条件を格納するブラックリストテーブルを記憶するデータベースを含み、
   前記求人情報は、前記項目名に対応付けて１以上のキーワードを含み、
   前記拒否条件内の項目名により示される前記求人情報内の項目に、該項目名に対応付けて該拒否条件内に含まれるキーワードが含まれているか否かを判定することにより、前記求人情報が前記ブラックリストテーブル内に格納される１以上の前記拒否条件のそれぞれに該当するか否かを判定し、
   対応する前記拒否条件に前記求人情報が該当すると判定した前記求人媒体サーバを該求人情報の連携先から除外する、
   請求項１に記載の求人連携サーバ。
3. 前記複数の求人媒体サーバのそれぞれに関して、対応する前記求人媒体サーバに対して連携される一連の求人情報内における前記求人情報の給与水準が相対的に高いほど高くなる第１のスコアを前記求人情報に付与し、
   前記複数の求人媒体サーバのそれぞれに関して、勤務地によって異なる第２のスコアを前記求人情報に付与し、
   前記第１のスコア及び前記第２のスコアのそれぞれに対して所定の重み付け値を乗算し、乗算後の前記第１のスコア及び前記第２のスコアを加算することにより前記第１のスコア及び前記第２のスコアの加重平均値を算出し、算出した加重平均値を前記求人情報の優先順位として取得し、
   前記求人情報とともに前記優先順位を前記１以上の求人媒体サーバのそれぞれに対して送信する、
   請求項２に記載の求人連携サーバ。
4. 前記キャンペーン情報は、前記求人主が希望する月間課金額の最大値を示す予算情報をさらに含み、
   前記複数の求人媒体サーバのそれぞれにおいて発生した前記求人主に対する課金の額に基づいて日次予算消化額を算出し、複数の日にわたって算出した前記日次予算消化額の平均値及び累計値を算出し、前記平均値に予め設定された日数を乗じた額に前記累計値を加算してなる金額が前記予算情報により示される前記最大値を上回っている場合に、算出した前記コンバージョン単価及び前記求人情報に含まれる情報の送信を行わない、
   請求項３に記載の求人連携サーバ。
5. 前記求人主の採用活動のために用いられる採用管理サーバと通信可能に構成され、
   前記求人情報は、前記求人主から前記採用管理サーバを介して前記求人連携サーバに供給される、
   請求項４に記載の求人連携サーバ。
6. 前記求人媒体サーバを識別するための求人媒体ＩＤ、前記求人情報を識別するための求人ＩＤ、及び有効フラグを含むフィード情報を格納するフィード情報テーブルを記憶するデータベースを含み、
   連携先として決定した前記１以上の前記求人媒体サーバのそれぞれについて、対応する前記求人媒体サーバを識別するための求人媒体ＩＤと、前記求人ＩＤとを含むフィード情報を前記フィード情報テーブルに挿入するとともに、該フィード情報の有効フラグをオンにし、
   前記フィード情報テーブルにおいて前記有効フラグがオンになっているフィード情報を取得し、取得した前記フィード情報に含まれる前記求人媒体ＩＤにより示される前記求人媒体サーバに対し、取得した前記フィード情報に含まれる前記求人ＩＤにより示される前記求人情報に含まれる情報を送信する、
   請求項１に記載の求人連携サーバ。
7. 前記データベースは、前記キャンペーン情報ごとに、対応する前記求人情報に対して応募があったことによって課金が発生した回数である応募数、又は、対応する前記求人情報に対してランディングページへの遷移が行われたことによって課金が発生した回数であるクリック数を記憶するキャンペーン成果テーブルをさらに記憶し、
   前記求人連携サーバから受信した前記求人情報を表示した１以上の前記求人媒体サーバのそれぞれから前記応募数又は前記クリック数を取得し、前記キャンペーン成果テーブルに格納する、
   請求項６に記載の求人連携サーバ。
8. 前記データベースは、前記求人主がチャージした金額を示すチャージ金額を格納するチャージ履歴テーブルをさらに記憶し、
   前記求人連携サーバから受信した前記求人情報を表示した１以上の前記求人媒体サーバのそれぞれから前記求人主に対する課金の額を取得し、前記チャージ履歴テーブルに消化金額として格納し、
   前記チャージ履歴テーブルに記憶されるチャージ金額及び消化金額から前記求人主のチャージ残高を取得し、
   前記平均値に予め定められている設定日数を乗算し、得られた金額が前記チャージ残高を上回っているか否かを判定し、上回っていると判定した場合に、算出した前記コンバージョン単価及び前記求人情報に含まれる情報の送信を行わない、
   請求項４に記載の求人連携サーバ。
9. 前記求人情報を記憶する求人情報テーブル、複数の職種を記憶するハブ職種マスタテーブル、及び、それぞれ前記１以上の求人媒体サーバに入力可能な１以上の職種のそれぞれを前記ハブ職種マスタテーブルに記憶される前記複数の職種のいずれかと対応付けて記憶する複数の媒体職種マスタテーブルを記憶するデータベースと、
   前記求人情報を前記求人情報テーブルに追加する入力受付部と、
   前記求人情報テーブルに書き込まれている前記求人情報を前記１以上の求人媒体サーバのそれぞれに対して送信するフィード連携部と、を含み、
   前記求人情報は１以上の職種を含み、
   前記入力受付部は、
   前記求人情報に含まれる前記１以上の職種のそれぞれについて、単語の特徴を表す第１の特徴ベクトルを取得し、
   前記ハブ職種マスタテーブルに記憶される前記複数の職種のそれぞれについて、単語の特徴を表す第２の特徴ベクトルを取得し、
   職種間の関係性を表現するグラフモデルによる推定の結果と、与えられた２つの職種が同じクラスに属するか否かを判定するためのペアワイズ分類器による推定の結果とを多数決で統合することにより生成されたアンサンブル推定器を用いて、前記第１の特徴ベクトルのそれぞれについて最も近い前記第２の特徴ベクトルを決定し、前記求人情報に含まれる１以上の職種のそれぞれを、該職種の前記第１の特徴ベクトルに最も近いものとして決定された前記第２の特徴ベクトルにより示される前記ハブ職種マスタテーブルに記憶される職種に変換したうえで、前記求人情報を前記求人情報テーブルに追加し、
   前記フィード連携部は、前記求人情報テーブルに書き込まれている前記求人情報内に含まれる職種を、該職種に対応付けて前記媒体職種マスタテーブルに記憶される職種にさらに変換したうえで、前記求人情報テーブルに書き込まれている前記求人情報を前記１以上の求人媒体サーバのそれぞれに対して送信する、
   を含む請求項１に記載の求人連携サーバ。
10. それぞれ求人サイトを構成する複数の求人媒体サーバに対して求人情報を連携するための求人情報連携方法であって、
    求人情報と、及び、該求人情報に対して応募があった場合に発生する課金の額又は該求人情報に対してランディングページへの遷移が行われた場合に発生する課金の額であるコンバージョン単価の目標値を含むキャンペーン情報の求人主による入力を受け付けるステップと、
    前記複数の求人媒体サーバのそれぞれから、求職者端末の画面に前記求人情報が表示された回数を示すインプレッション数を取得するステップと、
    前記インプレッション数が所定の目標値以上となるように前記コンバージョン単価の調整率を決定するステップと、
    決定した前記調整率を前記コンバージョン単価の目標値に乗算することによってコンバージョン単価を算出するステップと、
    前記複数の求人媒体サーバのそれぞれについて下限入札単価を記憶する下限入札単価テーブルから、前記複数の求人媒体サーバのそれぞれについて前記下限入札単価を取得するステップと、
    前記複数の求人媒体サーバのうち、算出した前記コンバージョン単価が、対応する前記下限入札単価以上である１以上の前記求人媒体サーバを前記求人情報の連携先として決定するステップと、
    連携先として決定した前記１以上の前記求人媒体サーバのそれぞれに対して、算出した前記コンバージョン単価及び前記求人情報に含まれる情報を送信するステップと、
    を含む求人情報連携方法。
11. それぞれ求人サイトを構成する複数の求人媒体サーバと通信可能に構成された求人連携サーバとしてコンピュータを機能させるためのプログラムであって、
    前記コンピュータに、
    求人情報、及び、該求人情報に対して応募があった場合に発生する課金の額又は該求人情報に対してランディングページへの遷移が行われた場合に発生する課金の額であるコンバージョン単価の目標値を含むキャンペーン情報の求人主による入力を受け付けるステップと、
    前記複数の求人媒体サーバのそれぞれから、求職者端末の画面に前記求人情報が表示された回数を示すインプレッション数を取得するステップと、
    前記インプレッション数が所定の目標値以上となるように前記コンバージョン単価の調整率を決定するステップと、
    決定した前記調整率を前記コンバージョン単価の目標値に乗算することによってコンバージョン単価を算出するステップと、
    前記複数の求人媒体サーバのそれぞれについて下限入札単価を記憶する下限入札単価テーブルから、前記複数の求人媒体サーバのそれぞれについて前記下限入札単価を取得するステップと、
    前記複数の求人媒体サーバのうち、算出した前記コンバージョン単価が、対応する前記下限入札単価以上である１以上の前記求人媒体サーバを前記求人情報の連携先として決定するステップと、
    連携先として決定した前記１以上の前記求人媒体サーバのそれぞれに対して、算出した前記コンバージョン単価及び前記求人情報に含まれる情報を送信するステップと、
    を実行させるためのプログラム。

Images