Ats Boards

@pipeworx/ats-boards

15 種の応募者追跡システムに掲載されている公開求人情報 （Greenhouse、Lever、Ashby、SmartRecruiters、Recruitee、BambooHR、Workday、 Workable、Teamtailor、Personio、Jobvite、Breezy、Pinpoint、Rippling、iCIMS）— 企業がどの ATS で採用ページを公開しているかを検出し、キーなしで任意の企業の募集中の職種を取得します。これは、呼び出し元自身の非公開の採用データを独自の API キーで読み取る greenhouse／ashby パックとは異なります。このパックでは、どの企業のものでも、ブラウザーで見られる公開ボードと同じ情報を読み取ります。

Pipeworx の一部です — AI エージェントを 1872 以上の稼働中のデータソースに接続する MCP ゲートウェイです。これは独立した非公式の連携であり、上流プロバイダーとは提携、承認、公開のいずれもされていません。

Dover は評価の結果、対象から除外しました。公開ボードは Cloudflare Turnstile チャレンジの背後にあるクライアント描画型 SPA であり、基盤となる求人 API （app.dover.com/api/v1/jobs）は、試したすべてのクエリパラメーターの組み合わせに対して HTTP 401「Authentication credentials were not provided」を返します。キーなしで利用できる、検出可能なエンドポイントはありません。

ツール

• ats_detect(domain | careers_url) — 採用ページから ATS へのリンクをスクレイピングし、見つからない場合は各ボード API に対してドメイン名をスラッグとして照会して、企業が使用している ATS とボードトークンを特定します。特定結果を保存するため、同じドメインへの再照会は即座に完了します。
• ats_jobs(ats, board_token, filters?) — ats と board_token がすでにわかっているボードの、正規化された求人情報を取得します。SmartRecruiters を除くすべての ATS で、ボードが不明な場合（found:false, reason:"board_not_found"）と、実在するボードに現在の求人がない場合（found:true, jobs:[]）を区別します。SmartRecruiters ではこの区別ができないため（下記参照）、推測せずにそのケースを ambiguous:true として示します。
• ats_company_jobs(domain, filters?) — ats_detect と ats_jobs を 1 回の呼び出しで実行します。
• ats_new_postings(ats, board_token, since?) — 現在の求人情報を、そのボードで最後に取得したスナップショットと比較します。ボードへの初回呼び出しでは比較対象のスナップショットがないため、誤解を招く空の差分ではなく、現在の求人をすべて新着として返します（snapshot_bootstrap:true）。

認証

キーは不要です。以下のすべてのエンドポイントでは、企業自身の採用ページをブラウザーで見た場合と同じ公開ボード情報を取得します。対応する 15 社の ATS ベンダーいずれについても、アカウント、トークン、登録は必要ありません。

例外は Workable です。このプラットフォームのエッジからは、現在 Cloudflare によって公開ウィジェットへのアクセスがブロックされています（下記の「データソース」を参照）。これは認証による制限ではなく、トランスポートの障害です。ats:"workable" を指定すると、ats_jobs／ats_company_jobs は空の結果を返さず、HTTP 429 と Cloudflare によるブロックを明示したエラーをスローします。

データソース

• https://boards-api.greenhouse.io/v1/boards/{board_token}/jobs?content=true — Greenhouse の公開ボード API。
• https://api.lever.co/v0/postings/{board_token}?mode=json（filters.region:"eu" の場合は https://api.eu.lever.co/...）— Lever の公開求人 API。
• https://api.ashbyhq.com/posting-api/job-board/{board_token}?includeCompensation=true — Ashby の公開求人ボード API（公式ドキュメントあり。雇用主が公開している場合は報酬範囲を含みます）。
• https://api.smartrecruiters.com/v1/companies/{board_token}/postings — SmartRecruiters の公開求人 API。
• https://{board_token}.recruitee.com/api/offers/ — Recruitee の公開求人 API。
• https://{board_token}.bamboohr.com/careers/list — BambooHR の公開キャリアウィジェットエンドポイント。
• https://{tenant}.wd{N}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs（POST）— Workday の公開 CXS 求人検索。board_token には、パスの 3 つの部分を "{tenant}.wd{N}/{site}" の形式で指定します。例："workday.wd5/Workday"（テナント、wd 番号、サイトは、企業自身の myworkdayjobs.com の採用ページ URL からそのまま読み取ります）。
• https://apply.workable.com/api/v1/widget/accounts/{board_token} — Workable の公開ウィジェット API。現在、このプラットフォームのエッジからは到達できません。Pipeworx の本番 Cloudflare アカウント上で一時的な wrangler dev --remote Worker を使ってライブで確認済みです。5 回以上の試行（2 種類のエンドポイント形式――v1 ウィジェットと v3 の /api/v3/accounts/{account}/jobs――を、Accept ヘッダーあり・なし、複数の実在するアカウント名に対して、数分間隔で実行）のすべてで、HTTP 429、Content-Type: text/plain、本文 error code: 1015 が返されました。これは Workable アプリケーションの応答ではなく、Cloudflare 独自のボット対策です。この結果から、apply.workable.com の Cloudflare WAF が Cloudflare Worker からの Cloudflare へのトラフィックを特にレート制限していると考えられます。アダプターは Workable の公式ドキュメントに記載されたウィジェット形式に従って実装済みで、この状況が変わればすぐに利用できます。それまでは、ライブ呼び出しのたびに 429 を明示する例外をスローし、空のボードを返すことはありません。
• https://{board_token}.teamtailor.com/jobs.json — Teamtailor の認証不要の JSON フィード（jsonfeed.org v1.1）。
• https://{board_token}.jobs.personio.com/xml?language=en（404 の場合は .jobs.personio.de にフォールバック）— Personio の公開 XML フィード。企業ごとに使用する TLD は 2 つのうちどちらか一方のみで、相互にリダイレクトされることはありません。
• https://jobs.jobvite.com/{board_token} — Jobvite のサーバー側でレンダリングされる HTML ボード（JSON API はありません。ベンダー独自のフィードは顧客ごとに提供され、デフォルトでは無効です）。jv-job-list-* テーブルのマークアップから正規表現で解析します。
• https://{board_token}.breezy.hr/json — Breezy の認証不要の JSON 配列。
• https://{board_token}.pinpointhq.com/postings.json — Pinpoint の認証不要で、公式ドキュメントのある求人 JSON。
• https://ats.rippling.com/{board_token}/jobs — Rippling に独立した JSON API はありません（推測した /api/... パスはすべて 404 になります）。求人リストはページの <script id="__NEXT_DATA__"> ハイドレーションデータから解析します。
• https://{board_token}.icims.com/jobs/search?ss=1&in_iframe=1 — iCIMS の公式 Talent-Cloud API はパートナー限定ですが、公開されている採用検索ページ自体はログイン不要の通常のサーバー側レンダリング HTML で、正規表現で解析します。board_token にはサブドメインのラベル全体を指定します（例："careers-acme"）。iCIMS の顧客で共通の固定プレフィックスはありません。

ATS ごとのサイレントゼロの形状（それぞれドキュメントの記述を前提にせず、実際に測定）

各 ATS は「そのようなボードはない」という応答がそれぞれ異なり、3 つの ATS では「実在するボードだが、現在求人がゼロ」とまったく区別できません。

ATS	不明なボード	実在するボード、求人ゼロ
Greenhouse	HTTP 404 JSON {"status":404,"error":"Job not found"}	HTTP 200 {"jobs":[]}
Lever	HTTP 404 JSON {"ok":false,"error":"Document not found"}	HTTP 200 []（ライブ確認済み：api.lever.co/v0/postings/lever）
Ashby	HTTP 404、プレーンテキスト "Not Found"（JSON ではありません）	HTTP 200 JSON {"jobs":[],"apiVersion":"1"}（ライブ確認済み：vercel、deel、mercury）
SmartRecruiters	「求人ゼロ」と同じ形状で、両者を区別できません。 どちらも HTTP 200 {"totalFound":0,"content":[]} を返します	不明なボードと同じです。このパックでは推測せず、ambiguous:true と記録します
Recruitee	HTTP 404 JSON {"error":"Not Found"}	ライブでの個別確認は未実施（このビルドの時間内には見つかりませんでした）。同系列の ATS がすべて採用している「HTTP 200 で空配列を返す」慣例から、HTTP 200 {"offers":[]} が予想されます
BambooHR	HTTP 200（404 ではありません）、Content-Type: text/html — BambooHR 自身のマーケティング用ホームページで、異なる無意味なサブドメイン間でバイト単位で同一です（企業ごとの 404 ではなく、ワイルドカードのキャッチオールです）	HTTP 200 JSON {"meta":{"totalCount":0},"result":[]}（ライブ確認済み：helpscout、pantheon）
Workday	HTTP 404 JSON {"errorCode":"S21",...,"message":"not found: Job_Posting_Site_ID=..."}	個別確認は未実施（見つかった実在テナントにはすべて求人がありました）。limit が 20 を超えると空ページではなく HTTP 400 になります。10,000 を超える offset を指定するとエラーではなく、offset:0 と同じページが HTTP 200 で返されます。このパックでは、いずれかの上限に達した場合に capped:true と報告します
Workable	ブロックされています（HTTP 429、Cloudflare）。このプラットフォームからボード形式の応答に到達する前にブロックされます	—
Teamtailor	HTTP 404、Content-Type: application/json、本文は空（0 バイト）	HTTP 200 JSON Feed {"items":[...]}（ライブ確認済み：career、arsenalfc）
Personio	.com と .de の両方で HTTP 404 text/html	HTTP 200 XML <workzag-jobs>（ライブ確認済み：.de の kertos、.com の 1nce）
Jobvite	HTTP 200 ですが、4 回のリダイレクトで別のホストに移動します（www.jobvite.com/support/...?invalid=1）。fetch のデフォルト設定 redirect:'follow' では、res.redirected を確認しない限り、このことが隠されます	HTTP 200、リダイレクトなし、サーバー側でレンダリングされた求人テーブル（ライブ確認済み：bagleybagelbites、65 件）
Breezy	HTTP 404、Content-Type: text/html、タイトルは "Career portal not found"	HTTP 200 JSON 配列（ライブ確認済み：breezy、duolingo）
Pinpoint	HTTP 404、Content-Type: text/html（Pinpoint 自身の 404 ページ）	個別確認は未実施（見つかった実在ボードにはすべて求人がありました）。同じ慣例から、HTTP 200 {"data":[]} が予想されます
Rippling	HTTP 404、Next.js 自身の 404 ページで、求人投稿クエリの __NEXT_DATA__ はありません	HTTP 200。job-posts クエリはありますが、items:[] です。個別確認は未実施（見つかった実在ボードにはすべて求人がありました）
iCIMS	HTTP 404、タイトルは "gone: {subdomain}.icims.com : dc409"	個別確認は未実施（見つかった実在ポータルにはすべて求人がありました）

HTTP 200 以外を「求人ゼロ」として扱ったり、SmartRecruiters の totalFound:0 を求人がないことの確認済みデータとして扱ったりすることこそ、このパックが防ごうとしているサイレントゼロの失敗です。上記の各行の根拠となったエッジプローブの詳細（ステータス、長さ、先頭 400 バイト）については、src/index.ts のヘッダーコメントを参照してください。

永続化（モジュールスコープではなく KV）

ゲートウェイは共有 KV 名前空間を _cacheKv として注入します（pack-manifest.json の injectCacheKv）。この名前空間は、次の 3 つに使用されます。それぞれに日付が記録され、バインディングがない場合は問題なくライブ取得に切り替わります。

1. ボード全体の求人リストキャッシュ（TTL は約 3 時間）—「各ボードへのポーリングは数時間に 1 回までにします。」
2. ats_detect が書き込む domain -> {ats, board_token} の検出インデックス —「インデックスは利用するほど増えます。」
3. ats_new_postings が差分比較する求人キーのスナップショット。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します：

{
  "mcpServers": {
    "ats-boards": {
      "url": "https://gateway.pipeworx.io/ats-boards/mcp"
    }
  }
}

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/ats-boards/mcp の tools/list は、上の表にあるツールに加えて、共有 Pipeworx メタツール（ask_pipeworx、discover_tools、search_within、remember／recall など、ゲートウェイ全体で利用できる一連のツール）も返します。そのため、表示されるツール数はこの表より多くなります。現在、単一パックのエンドポイントには、パック固有のツールに加えて、およそ30個の共有ツールが一覧表示されます。接続の initialize 応答には正確な範囲が記載されており、その日の時点での確かな情報源となります。

これは意図的な設計であり、誤って多重化されているわけではありません。メタツールを使えば、このパックでは扱えない質問にも対応できます。ask_pipeworx を介してカタログ全体に振り分けるため、MCP サーバーを追加する必要はありません。現在、メタツールなしでパックのエンドポイントをマウントする方法はありません。追加のスキーマによるコンテキスト消費が、振り分けの利点を上回る場合は、複数のパックエンドポイントではなく、フルゲートウェイに一度だけ接続してください。

または、Pipeworx のフルゲートウェイに接続すると、このパックだけでなく、すべてのパックのツールが直接一覧表示されます：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

どちらの URL も、同じゲートウェイと同じ1872以上のデータソースに接続します。違いは、どのパックのツールが直接一覧表示されるかだけです。どちらから接続しても、ask_pipeworx を使えばすべてのツールを利用できます。

MCP クライアントがない場合：HTTP で呼び出す

curl -X POST https://gateway.pipeworx.io/v1/tools/ats_detect \
  -H 'Content-Type: application/json' \
  -d '{"domain":"ramp.com"}'

最初の呼び出しにはアカウントは不要です。ツールの詳細を確認するには、GET https://gateway.pipeworx.io/v1/tools/ats_detect を使用します。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を使用します。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージは、ローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントも、ゲートウェイとの往復通信も不要です：

{
  "mcpServers": {
    "ats-boards": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-ats-boards"]
    }
  }
}

または、起動を確認するため、直接実行します：

npx -y @pipeworx/mcp-ats-boards

stdin/stdout を介して MCP で通信し、このパックのツールのみを対象に initialize／tools/list／tools/call に応答します。上記のゲートウェイ接続で追加される共有メタツールは含まれません。同じソース、同じツールで、ask_pipeworx による振り分けはありません。

ask_pipeworx の使用

ツールを直接呼び出す代わりに、自然な英語で質問できます。上記のパックエンドポイントとフルゲートウェイの両方で利用できます：

ask_pipeworx({ question: "your question about Ats Boards data" })

ゲートウェイが適切なツールを選び、引数を自動的に入力します。

詳細情報

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT