Claude Workday連携の現状 — 公式コネクタは無くコミュニティ製のみ

Claude Workday連携は今どこまでできるか

ClaudeとWorkdayを直接つなぐ公式コネクタは存在しません。Anthropicが提供する一次統合はGoogle Drive・Gmail・Google Calendar・GitHub・Slack・Microsoft 365に限られ、Workdayは含まれていません。Workday側からもAnthropic・Claudeとの公式パートナーシップは発表されていません。

一方で、MCP(Model Context Protocol)を使ったコミュニティ製の非公式サーバーは複数存在します。人事担当者がClaudeで従業員情報や組織図を自然言語で参照したいというニーズは強く検索されますが、現状は「自分でMCPサーバーを立てて接続する」以外の選択肢がありません。本稿では現状の到達点と、人事データを扱う上での現実的な制約をたどります。

Workdayとは何か、なぜ公式連携が難しいのか

Workdayとは、人事管理(HCM)と財務管理をクラウドで提供するエンタープライズ向けSaaSです。従業員情報・給与・組織構造・経費といった機微なデータを扱うため、外部AIツールとの連携には他のSaaSより慎重な設計が求められます。

後述する2つのコミュニティ製MCPサーバーは、それぞれWorkdayのStaffing REST API、およびJDBCドライバ経由でWorkdayのデータにアクセスしており、外部からのデータ取得は技術的には可能です。ただし認証にはテナントごとのOAuth 2.0設定が必要で、Google DriveやSlackのような「ボタン一つで接続」という体験は用意されていません。この認証の重さが、Anthropicが一次統合として組み込むハードルにもなっていると考えられます。テナント管理者がIntegration System User(ISU)を発行してOAuth 2.0のクライアント認証情報を払い出す必要があり、個人アカウントでワンクリック連携できるSaaSとは前提が異なります。

現状存在する2つのコミュニティ製MCPサーバー

GitHub上に公開されている実装のうち、実用に耐える情報がまとまっているのは次の2つです。

NoBanks/workday-mcp — Staffing APIの読み取り専用サーバー

pip install workday-mcpでインストールでき、MITライセンスで公開されています。WorkdayのStaffing REST APIに接続し、次の5つの読み取り専用ツールを提供します。

必要な環境変数はWORKDAY_SERVER(テナントのAPIエンドポイント)、WORKDAY_TENANT(テナント識別子)、WORKDAY_BEARER_TOKEN(別途取得したOAuth 2.0トークン)、WORKDAY_API_VERSION(省略可)の4つです。開発者は「Workdayへの書き込みは強い監査要件とビジネスプロセス要件を伴う」という理由で、意図的に読み取り専用に絞ったと説明しています。

CDataSoftware/workday-mcp-server-by-cdata — JDBC経由でSQL的に問い合わせる

CData社が公開する無料版で、JDBCドライバ経由でWorkdayのデータをテーブルのように扱えます。get_tables・get_columns・run_query(SQL SELECT文の実行)という3つのツールを提供し、Workday側のスキーマを知らなくてもClaudeが自然言語からSQLを組み立てて問い合わせる形になります。

セットアップにはCData JDBC Driver for Workdayのダウンロードとライセンス認証が必要で、接続文字列の生成にはOAuth認証のブラウザ確認が挟まります。こちらも読み取り専用で、公式ドキュメントは「完全な読み書きアクセスが必要な場合は有料の管理型プラットフォームCData Connect AIを使うこと」と案内しています。

2つのMCPサーバーをどう使い分けるか

利用シーンによって向き不向きがはっきり分かれます。

どちらも共通しているのは「読み取り専用」という一点です。両プロジェクトとも、書き込み操作は監査要件やビジネスプロセスの複雑さを理由に意図的に避けています。

Workday標準のレポート機能とどう使い分けるか

Workdayには元々Report WriterやダッシュボードによるBI機能が備わっており、IT部門が承認したレポートは監査証跡が明確で、権限管理もWorkday本体のセキュリティグループに準拠します。これに対して、コミュニティ製MCPサーバー経由のClaude照会は、個人が手元で行う探索的な確認作業に向いた仕組みです。

定例のレポーティングや監査対応にはWorkday標準のレポート機能を使い、Claudeは「この従業員の上長は誰か」「この組織に何人所属しているか」のような単発の確認に限定するのが、現状のツール構成では安全な線引きです。承認済みレポートの代替として使うと、変更履歴や承認プロセスが標準機能ほど厳密ではない分、監査上の説明が難しくなります。

人事データを扱う上での現実的な制約

Workdayが持つデータは給与・評価・在籍状況など機微性が高く、扱いには一般的なSaaS連携以上の注意が必要です。現状のコミュニティ製MCPサーバーを使う場合は、次の点を運用ルールとして明文化しておくのが安全です。

• アクセス権限をAPIトークン発行時点で絞る: Workday側のセキュリティグループで、連携用アカウントに閲覧させる範囲を必要最小限にする
• 会話ログでの人事データの残り方を把握しておく: Claude側の会話履歴にどこまで人事データが残るかを組織のプランと管理者設定で確認し、退職者データや評価情報のような機微性の高い項目はそもそも連携対象から外す運用も検討する
• 書き込み系の要望には対応しない前提を周知する: 現状のMCPサーバーはいずれも読み取り専用なので、「Claudeで給与を更新して」という運用は最初から選択肢にない

この先、公式連携は来るか

AnthropicのConnectors Directoryは、Anthropicが審査する「検証済み」と、審査が浅い「コミュニティ」の2区分で運用されています。理論上はWorkday自身、あるいは第三者開発者がこのディレクトリに登録することは可能です。ただしWorkdayが持つデータの機微性を考えると、書き込み機能まで含む本格的な統合が出るとすれば、まずGoogle Workspace・Microsoft 365のような大手SaaSと同様に、Workday自身が主体となって設計する可能性が高いと見られます。その発表はなく、人事担当者が今すぐ使える手段は上記2つのコミュニティ製サーバーに限られます。

MCPサーバーをClaudeに追加する一般的な手順はClaude Code MCP設定ガイドで解説しています。読み取り専用のデータベース接続という設計思想はClaude CodeでMCPからデータベースに接続する方法とも共通しており、安全なアクセス範囲の絞り方を検討する際の参考になります。

よくある質問

WorkdayのAPIトークンはどこで取得するか

Workdayのテナント管理者がIntegration System User(ISU)を発行し、OAuth 2.0のクライアント認証情報を払い出す形が一般的です。取得手順はテナントごとの管理者権限設定に依存するため、社内のWorkday管理者に確認するのが確実です。

給与情報もClaudeから参照できるか

NoBanks/workday-mcpが提供する5ツールは従業員の基本情報・組織構造・マネジメントチェーンに限られ、給与そのものを取得するツールは含まれていません。給与データにアクセスするには、Staffing API側で該当エンドポイントへの権限を持つ認証情報と、別途ツールを実装する必要があります。

有料の管理型MCPサービスを使うメリットは

CData Connect AIのような有料サービスは、読み書き両方への対応やホスティングの手間を省ける点が主なメリットです。無料のコミュニティ製サーバーは自前でホストし読み取り専用に留まる分、コストと引き換えに機能とサポート体制を得る形になります。

Workday本体のダッシュボードは不要になるか

なりません。コミュニティ製MCPサーバーが提供するのは限られたツールによる単発の照会だけで、Workday本体が持つ承認フロー・グラフ・定期配信レポートのような機能は代替できません。日常的な単発確認をClaudeに任せ、正式なレポーティングはWorkday本体に残すという役割分担が現実的です。

まとめ

Claude Workday連携は、公式コネクタが存在せず、コミュニティ製MCPサーバーを自分で構築・運用するのが唯一の手段です。NoBanks/workday-mcpは軽量なStaffing API直結、CData版はSQL的な柔軟性が特徴で、いずれも書き込みには非対応です。人事データという機微性を踏まえ、アクセス範囲を絞った上で読み取り専用の用途に限定するのが現実的な使い方です。公式連携が出るとすればWorkday自身が主体になる可能性が高く、それまでは期待値を調整しながら既存のコミュニティ製サーバーを活用する段階にあります。