採用面談の予約基盤は内製かAPI連携か：保守費と変更対応で比べる判断ガイド

導入

一言で言うと、採用面談の予約基盤は「作るか、買うか」ではなく、どの変更を誰が何日で反映できるかで選ぶ段階に来ています。

この記事の要点（比較基準日：2026年10月19日）

• 内製の予約基盤は、リリース後の「維持」と「変更」に開発工数が流れ続ける構造です。
• API連携でも保守はなくなりません。ATS同期、Webhook処理、障害時の照合は自社の責任として残ります。
• 判断の単位は方式名ではなく、「採用部門に委ねる変更」と「開発部門が持つ割当ロジック」の線引きだと考えます。

今、現場で起きているのは次のような状況です。

• 職種、拠点、選考段階が増え、面接官の割当条件が複雑になっている
• 組織変更や面接官の入れ替えのたびに、予約システムの改修チケットが発生する
• 候補者は「すぐ予約できて、すぐ変更できる」ことを前提に応募してくる

その結果、予約基盤の保守負担が、採用DXの中でも独立した課題として表に出てきました。

本記事は、採用責任者と開発責任者が同じ表を見て議論できるように、4つの構築方式を比較します。

• ① 既存ATSの標準機能で対応する
• ② 全面内製する
• ③ 外部の予約画面を埋め込む
• ④ 自社画面と予約APIを組み合わせる

構造的な理由は単純です。予約機能は「一度作れば終わり」の機能ではありません。組織とカレンダーの変化に追従し続ける運用インフラなので、比較の主軸は初期費用より継続費用になる、という構造ですね。

結論（用途別おすすめ）

先に用途別の推奨を示します。これは比較基準日時点の一般的な整理であり、自社要件での検証を前提とした目安です。

自社の状況	推奨しやすい方式	主な理由
面接官が少なく、選考フローが単純	① ATS標準機能	追加の連携保守がほぼ発生しにくい
割当規則そのものが事業の差別化要素で、専任の開発体制がある	② 全面内製	ロジックを自由に設計できる
早く候補者体験を改善したい。画面デザインの自由度は優先しない	③ 予約画面の埋め込み	開発範囲が小さく、変更を採用部門が担える
ATSや自社マイページと深く統合したい。割当条件も複雑	④ 自社画面＋予約API	画面と固有ロジックは自社、予約確定とカレンダー接続は外部に任せられる

合理的に考えれば、多くの企業では「③から始めて、必要な箇所だけ④へ広げる」という段階導入が、保守費と変更対応のバランスを取りやすいのではないでしょうか。

ここには構造的な理由があります。予約基盤の工数の多くは、カレンダー接続や空き枠計算、通知といった差別化しにくい部分に吸収されがちです。差別化に関わらない層を外に出すほど、開発リソースを本来の事業ロジックへ戻せます。

比較軸の定義

比較軸は5つです。採用責任者と開発責任者で関心が分かれるため、両者の指標を同じ表に並べます。

比較軸	定義	主に見る人	測り方の例
候補者体験	予約・変更・キャンセルの手軽さと、確定までの速さ	採用責任者	予約完了率、応募から面接確定までの日数
割当の複雑さへの対応	職種別の担当資格、面接官の優先順位、複数名同席、受付上限	両者	自社の割当ルールのうち、設定だけで表現できる割合
年間保守費	障害対応、カレンダー仕様変更への追従、連携保守の工数	開発責任者	年間の保守工数（人月）×単価
変更反映日数	面接官の追加、組織変更、面談種別の追加にかかる日数	採用責任者	依頼から本番反映までの日数
データ統制	ATSとの状態同期、重複・欠落の検知、再試行	開発責任者	同期不整合の件数、復旧までの時間

年間保守費は、次の式で両方式を同じ条件に揃えて見積もるのが実務的です。

年間比較額＝初期・移行費の年割額＋利用料＋自社の連携保守・障害対応工数＋変更対応工数

重みづけは、組織の状況によって変わります。以下は例です。

• 採用の量が多く、候補者離脱が課題の組織：候補者体験 30％／変更反映日数 25％／割当 20％／保守費 15％／データ統制 10％
• 開発リソースが逼迫している組織：保守費 30％／変更反映日数 25％／データ統制 20％／割当 15％／候補者体験 10％

構造的な理由として、「変更反映日数」を独立した軸に置いている点を補足します。費用は年次で一度しか見えません。一方で、変更待ちの期間は候補者の待ち時間と面接官の稼働ロスとして、日々の採用成果に効いてくるからです。

比較表（一覧）

比較基準日：2026年10月19日。各方式の一般的な傾向を整理したもので、個別製品の仕様は契約前に確認が必要です。

比較軸	① ATS標準機能	② 全面内製	③ 予約画面の埋め込み	④ 自社画面＋予約API
候補者体験	ATSの画面に依存	自由に設計できる	外部画面のUXに依存	自由に設計できる
割当の複雑さ	製品により差が大きい（要確認）	制約なし	外部基盤の設定範囲内	外部基盤の設定＋自社ロジックで補完
初期開発量	小	大	小	中
年間保守費	小	大（カレンダー接続・通知・障害対応を自社で保持）	小〜中	中（連携部分のみ自社）
変更反映日数	管理画面の設定で可能な範囲は短い	改修が伴い、長くなりやすい	管理画面の操作で短くできる	設定変更は短い。自社ロジック変更は改修が必要
ATS同期	同一製品内で完結	自社で設計	Webhookなどで自社設計	APIとWebhookで自社設計
ベンダー依存	ATSに依存	なし	予約基盤に依存	予約基盤に依存（画面は自社）
方式間の費用差	要確認	要確認	要確認	要確認

方式間の費用差を「要確認」としたのは、業界共通の基準値が存在しないためです。自社の予約件数、改修履歴、見積りから算出するのが妥当だと考えます。

表から読み取れる構造は明快です。②と④はいずれも候補者体験を自由に設計できます。ただし④は、カレンダー接続という最も保守が重い層を外部に出せる点で、②とは保守費の性質が異なりますね。

ツール別レビュー

各方式を同じ形式でレビューします。

① 既存ATSの標準機能

• 概要：ATSに内蔵された日程調整リンクや、カレンダーの空き枠抽出機能を使う方式です。
• 向いているケース
  • 面接官が少なく、選考段階ごとの割当が単純
  • 採用データをATS1つに集約したい
• 注意点
  • 優先順位付きの割当や受付上限など、複雑な割当の対応範囲は製品によって差があります（要確認）
  • 候補者画面のデザインや導線の自由度は限定的です
• 自社に残る保守：ほぼ設定作業のみです。

② 全面内製

• 概要：予約画面、空き枠計算、割当、カレンダー接続、通知をすべて自社で開発・運用する方式です。
• 向いているケース
  • 割当ロジック自体が競争力の源泉になっている
  • 予約基盤を継続的に保守できる専任チームがある
• 注意点
  • カレンダーAPIの認可、空き状況照会の上限、通知購読の有効期限と再作成など、外部仕様への追従が継続的に発生します
  • 組織変更のたびに改修が必要となり、変更反映日数が長くなりやすい構造です
• 自社に残る保守：全層です。障害対応も自社で担います。

③ 予約画面の埋め込み

• 概要：外部の予約基盤で作った予約ページを、採用サイトやメールに埋め込む・リンクする方式です。
• 向いているケース
  • 開発を最小限に抑え、候補者がすぐ予約できる状態を早く作りたい
  • 面接官の追加や枠の変更を採用部門で完結させたい
• 注意点
  • 画面デザインや入力項目は、外部基盤の設定範囲に依存します
  • ATSとの状態同期を自動化する場合は、Webhook受信などの開発が別途必要です
• 自社に残る保守：ATS同期を作った場合は、その連携部分です。

④ 自社画面＋予約API

• 概要：候補者向けの画面と固有の判定ロジックは自社で持ち、空き枠取得と予約確定は外部基盤のAPIで行う方式です。
• 向いているケース
  • 自社マイページやATSの選考ステータスと、予約をシームレスにつなげたい
  • 割当条件が複雑で、外部基盤の設定だけでは表現しきれない部分がある
• 注意点
  • API連携でも、認証、入力検証、エラー時の候補者案内、Webhookの重複処理は自社で設計します
  • API側の仕様変更やプラン条件の変更を監視する運用が必要です
• 自社に残る保守：画面、固有ロジック、連携部分です。

4方式の差を構造で言えば、「どの層の変化に、誰が追従するか」の違いです。実務的には、自社の割当ルールを書き出し、設定で表現できるものと、コードが必要なものに仕分けるだけで、候補はかなり絞り込めるはずです。

日程調整を組み合わせる場合

③または④を選ぶ場合、外部の予約基盤として日程調整ツールを組み合わせることになります。ここではJicooを例に、客観的な位置付けを整理します。

Jicooで担える範囲

• Googleカレンダー、Outlook、Apple（iCloud）との連携
• Zoom、Google Meet、Microsoft Teamsの会議URLの自動発行
• 担当者の自動割当（ラウンドロビン）と、回答内容に応じたルーティングフォーム
• REST API、予約ページの埋め込み、Webhookの組み合わせ

開発者資料には、予約作成の POST /v1/bookings と、予約種別の空き枠取得の GET /v1/event_types/{id}/available_schedules が掲載されています。

プラン面の注意点もあります。Jicooは2026年8月27日に料金プランを改定しました。比較基準日時点の公開機能一覧では、REST API・Webhookと担当者自動割当はTeam以上、担当者ごとの受付上限はBusinessの機能として案内されています。契約時には最新の条件を確認してください。

採用連携のマッピング例

トリガー	予約基盤側の処理	自社側のアクション	自社が設計すべき点
候補者が選考通過	—	空き枠取得APIを呼び、自社画面に表示	選考段階と予約種別の対応表
候補者が枠を選択	予約作成APIで確定、会議URL発行	ATSの選考ステータスを「面接確定」に更新	入力検証、失敗時の案内
予約確定のWebhook受信	署名付きで通知	ATSに面接官・日時を記録	署名検証、重複配信への対応
候補者が日程変更	変更内容を通知	ATS側の日時を更新	作成・キャンセルの順序が前後しても整合を保つ処理
通知の取りこぼし	—	定期的な照合処理で差分を補正	再試行と照合の運用設計

Webhookは「一度の通知が一度だけ届く」前提で設計しない。これが連携保守を軽くする最大のポイントだと考えます。

導入の3ステップ

1. Connect（接続）：面接官のカレンダーとWeb会議ツールを連携し、APIの認証情報を発行します。
2. Configure（設定）：選考段階ごとに予約種別を作成し、担当者の割当方式と優先度を設定します。設定で表現できない条件は、自社ロジック側で扱う範囲として切り出します。
3. Enable（有効化）：Webhookの受信先を登録し、少数の求人で試験運用します。その後、予約完了率と同期の不整合件数を確認してから対象を広げます。

レバレジーズの事例

対象業務を先に明確にしておきます。この事例は同社の従業員採用面接ではありません。「レバテックフリーランス」の求職者とキャリアアドバイザーの面談予約です。採用面談と共通する「予約と割当の課題」として読むのが適切ですね。

同社のJicoo導入事例で報告されている内容は、次のとおりです。

項目	導入前（同社報告）	導入後（同社報告）
予約基盤	内製の面談予約システム	JicooのAPIを導入
主な課題	職種・領域・拠点の増加による条件の複雑化、障害対応、組織変更に伴う改修	—
保守・運用工数	月約1人月	年間約600万円の削減（旧システムの保守・運用工数分）
担当者とカレンダーの紐付けなどの変更	1〜2カ月	事業側の管理画面操作で即日〜数日
実装期間	—	2週間

約600万円は、旧システムの保守・運用工数にもとづく同社の報告値です。SaaS利用料、移行費、連携部分の継続保守費を差し引いた純削減額ではありません。また、他社でも同じ額が得られるという意味でもありません。事例中の「直近半年間で障害は発生していない」という記述も、掲載時点の報告です。

この事例で注目すべきなのは、金額そのものより、変更対応が開発部門から事業部門へ移った点だと考えます。変更反映が「月単位」から「日単位」に縮んだことは、組織変更の多い事業ほど効いてくる構造です。

採用面接に直結するJicooの事例としては、TheNewGateがあります。手作業の調整で面接が1カ月半以上先になることがあった状態から、導入後は数日以内に面接できるようになったと報告されています。面接ステップごとに、メイン・サブ担当の優先度も指定しています。これも個社の報告値です。

向かないケース

• 割当ロジックが極めて独自で、外部基盤の設定と自社ロジックへの切り分けが難しい場合
• データの所在や処理の制約により、外部サービスへ予約情報を置けない場合
• 面接官が数名で、ATS標準機能で十分に運用できている場合

組み合わせを推奨する構造的な理由は、カレンダー接続と予約確定という「全社で同じ仕様の層」を外部に寄せられるからです。これにより、自社の開発を差別化ロジックに集中させやすくなります。

導入判断チェックリスト

以下の質問に答えることで、自社に合う方式が見えてきます。

1. 現在の予約基盤の年間保守工数を、人月で把握できていますか？
2. 直近1年で、面接官の追加や組織変更による改修は何回、何日かかりましたか？
3. 自社の割当ルールのうち、設定で表現できるものとコードが必要なものを仕分けられますか？
4. 候補者の予約完了率と、応募から面接確定までの日数を計測していますか？
5. ATS標準の日程調整機能で、どこまで要件を満たせるか検証済みですか？
6. 複数面接官の同席、優先順位、受付上限、候補者による再予約を、実際のシナリオで試しましたか？
7. Webhookの重複や欠落が起きたときの照合方法と、担当者は決まっていますか？
8. 外部基盤のプラン改定や仕様変更を、誰が監視しますか？

1・2・4は採用責任者、3・7・8は開発責任者が主に答える質問です。両者が同じシートを埋めることで、議論の前提が揃います。

構造的に見ると、多くの組織では1と2の答えが曖昧なまま「内製を続けるか」を議論しがちです。まず現状コストと変更所要日数の可視化から始めるのが合理的ですね。

よくある質問

Q1. API連携に切り替えれば、開発部門の保守はなくなりますか？

なくなりません。カレンダー接続や空き枠計算の保守は外部に移せますが、ATS同期、認証、Webhookの重複処理、障害時の照合は自社に残ります。見積りでは、この連携部分の工数を必ずしも小さく見積もらないことが重要です。

Q2. レバレジーズの約600万円は、自社の削減見込みとして使えますか？

使えません。旧システムの保守・運用工数にもとづく同社の報告値で、対象も採用面接ではなくキャリア面談です。自社の保守工数と単価から、年間比較額を算出してください。

Q3. 内製をやめると、割当の柔軟性は下がりますか？

外部基盤の設定範囲に収まる部分は、むしろ採用部門が自分で変更できるようになり、変更反映は速くなる可能性があります。設定で表現できない固有ルールは、④の方式で自社ロジックとして保持する設計が選択肢になります。

まとめ

• 予約基盤は「運用インフラ」です。比較の主軸は初期費用ではなく、年間保守費と変更反映日数に置くのが合理的だと考えます。
• API連携は保守の「ゼロ化」ではなく、「保守対象の絞り込み」です。ATS同期とWebhook処理の設計が、連携後の保守費を左右します。
• レバレジーズの事例が示したのは、金額以上に「変更対応を誰が担うか」の構造転換ではないでしょうか。

まず試すことは1つです。直近1年の予約基盤の改修履歴を洗い出し、「依頼から反映までの日数」と「投入した人月」を一覧にしてください。この数字が、内製を続けるか、API連携へ移るかを議論する出発点になります。

採用面接の日程調整を広く見直したい方は、recruitment や scheduling のタグ記事が参考になります。API設計の観点を深めたい開発責任者の方は、api や integration の記事もあわせて確認すると、検討の解像度が上がるはずです。