Claudeジョブカン連携 — 非公式MCPサーバーの導入手順

ジョブカンの公式MCPサーバーは見当たらない

ジョブカン経費精算/ワークフローに、公式のMCPサーバーは見当たりません。ジョブカンが公開しているのはREST API(ベースURLはhttps://ssl.wf.jobcan.jp/wf_api、β版)です。Claudeから使うには、このAPIをMCPに包んだコミュニティ製のコネクタを使います。

本記事で扱うのは、日本のSMB向けSaaSコネクタ集mcp-jpに含まれるjobcan-workflowです。Anthropic公式でもジョブカン公式でもない第三者のOSSなので、導入は自己責任になります。ソースが公開されているため、何を呼んでいるかは自分で確認できます。

対象はジョブカン経費精算/ワークフローだけです。ジョブカン勤怠管理など同じブランドの別製品は別サービス・別APIで、このコネクタでは接続できません。まず自社がどの製品を契約しているかを確認してください。同じ人事労務領域でSmartHRの従業員データを扱う場合はSmartHR従業員データをClaudeで確認・更新する人事効率化、人事評価や1on1準備はLatticeとClaudeで人事評価ドラフトと1on1準備を進めるが扱っています。

承認や申請はClaudeからできるのか

jobcan-workflowが実装するのは読み取り専用(GET)のツールだけです。ただし「できない」の理由は2種類あり、区別しておくと今後の見通しが変わります。

読める範囲は、申請書の一覧・詳細、フォーム一覧、ユーザー・部署・役職・プロジェクト・取引先・汎用マスタの参照です。マスタを編集したいときはジョブカンのWeb管理画面を使います。

導入手順: トークン発行からClaude Codeへの登録まで

APIトークンを発行する

トークンは環境変数JOBCAN_API_TOKENとしてコネクタに渡します。APIドキュメントによると、トークンはAuthorization: Token <トークン>の形でリクエストヘッダーに付けます(「Token」の前後に半角スペース1つずつ)。上限はトークン1つあたり1時間5,000リクエストで、超えるとエラーになります。一覧系ツールを何ページも連続で呼ぶ使い方をすると近づくため、エラーが出たら時間を置いて再試行します。

コネクタをインストールする

jobcan-workflowはPython製で、リポジトリをクローンしてインストールします。npm経由の一発インストールコマンドはありません。

git clone https://github.com/mediiiiium/mcp-jp.git
cd mcp-jp/jobcan-workflow
pip install -e .

インストールが終わるとjobcan-workflow-mcpという実行コマンドが使えるようになります。Claude CodeでもClaude Desktopでも、起動コマンドとしてこの名前をそのまま指定します。

Claude Codeに登録する

jobcan-workflowはローカルで動くstdioサーバーです。claude.aiのカスタムコネクタはリモートサーバーのURLを登録する方式のため、この形のサーバーは登録できません。使えるのはClaude CodeとClaude Desktopです。

claude mcp add --env JOBCAN_API_TOKEN=your_api_token_here --scope user jobcan-workflow -- jobcan-workflow-mcp

v2.1.285でclaude mcp add --helpを実行すると、次の3点が確認できます。

-e, --env <env...>           Set environment variables (e.g. -e KEY=value)
-s, --scope <scope>          Configuration scope (local, user, or project)
                             (default: "local")
-t, --transport <transport>  Transport type (stdio, sse, http). Defaults to
                             stdio if not specified.

--envは複数の値を取る形式(<env...>)で、ヘルプの例は-e API_KEY=xxx -- npx my-mcp-serverのように、サーバーのコマンド本体を--の後ろに置いています。上のコマンドも同じ形です。トランスポートは指定しなければstdioになるため、ローカルのPythonコマンドには--transportを付けなくて済みます。

スコープの既定はlocalです。--scope userにしているのは、APIトークンをプロジェクトの.mcp.jsonに書いて誤ってGit管理下に入れる事故を避けるためです。複数のプロジェクトで使うならuserが向きます。チームで共有する場合も、トークンをコミットしないよう各自のユーザースコープで登録します。スコープの違いはClaude Code MCP設定ガイドにあります。

Claude Desktopでは、設定ファイルに次のブロックを追加します。

{
  "mcpServers": {
    "jobcan-workflow": {
      "command": "jobcan-workflow-mcp",
      "env": {
        "JOBCAN_API_TOKEN": "your_api_token_here"
      }
    }
  }
}

接続を確かめる

Claudeに「APIトークンがちゃんと使えるか確認して」と話しかけると、validate_tokenツールが呼ばれます。裏側で呼ばれるのはGET /test/です。APIドキュメントでは、トークンが正しければ200と{"test": "ok"}、問題があれば401と{"detail": "Invalid token"}が返ると書かれています。401が返るときは、トークンの貼り間違いや発行し直しによる失効を疑います。

12個のツールで何が取れるか

list_requestsとget_requestが申請書、それ以外はマスタ情報の参照です。絞り込みができるのはlist_requestsとlist_formsだけで、ユーザー・部署・役職・プロジェクト・取引先の一覧はpage以外のパラメータに対応していません。

list_formsは種別・精算種別・名前・公開範囲でフォームを絞り込めます。経費精算のフォームが複数ある会社では、ここでform_idを調べてからlist_requestsに進みます。同じ役割をlist_groups(group_code)とlist_projects(project_code)も持ちます。list_positionsは役職の一覧だけで、他ツールの引数を調べる起点にはなりません。

get_generic_masterは、会社ごとに独自定義した費目や勘定科目マスタの中身を確認するツールです。コードの一覧を返すエンドポイントはAPIに無いため、コードの見当が付かないときは管理画面の「汎用マスタ」画面を先に見ます。

申請の追い方はClaudeでジョブカン経費精算の申請・承認状況を確認する方法で扱っています。

一覧系は共通のページ番号方式で、1ページ100件固定です。レスポンスのnextがnullでなければ次のページがあります。「次のページも見て」と続けて依頼すれば、Claudeがページ番号を進めて取得を続けます。

読み取りだけでも口座情報が出る点に注意

APIドキュメントのユーザー一覧(v3)のレスポンス例には、user_bank_account(銀行コード・口座番号・カナ名義)が含まれています。list_usersはこのv3を呼ぶため、get_userで個別に引かなくても、一覧の応答に口座情報が載る可能性があります。取引先側も、get_companyで振込先口座とインボイス登録番号を取得できます。

経理担当者が振込先の確認を任せる場面では便利ですが、ドキュメントにはトークン単位で読める範囲を絞る仕組みの記述が見当たりません。管理者が発行したトークンで読める内容がそのままClaudeに渡ると考えておくのが安全です。口座情報を会話に出したくない場合は、トークンを渡す前に、使うツールと質問の範囲を社内で決めておきます。

APIにはあるがコネクタが扱わない範囲

APIドキュメントには、コネクタが実装していない読み取り系のエンドポイントもあります。「Claudeで経理業務を丸ごと」と考える前に、次の範囲は使えない前提で見ておきます。

つまずきやすい点

claude.aiのConnectorsに追加しようとして見つからない: ローカルのstdioサーバーはClaude CodeかClaude Desktopで使います。

--scopeを指定せずローカルスコープのまま使い続けてしまう: 既定のlocalは、登録したプロジェクトでしか有効になりません。別のプロジェクトでjobcan-workflowが見えないときは、スコープを疑います。

get_requestが動かなくなる可能性がある: APIドキュメントには申請書1件を返すGET /v1/requests/{request_id}/が載っています。ところがコネクタが呼ぶのはGET /v2/requests/{request_id}/で、ドキュメントに載っているv2は一覧(GET /v2/requests/)だけです。READMEも、単体取得は既存実装として維持しており、β版なので将来使えなくなる可能性があると書いています。動かないときも、list_requestsにidを渡せば申請の状態と現在の承認ステップ(flow_step_name)までは確認できます。承認者ごとの状況やコメントは一覧に含まれません。

日付の絞り込みが効かない: list_requestsの日付パラメータ(applied_after・applied_before・completed_after・completed_before)はyyyy/mm/dd形式で指定します。ハイフン区切りのYYYY-MM-DDでは絞り込めません。

業務に組み込む前に決めておくこと

APIそのものが「β版」の扱いで、仕様は予告なく変わりえます。コネクタは第三者のOSSでもあるため、変わるのはジョブカン側のAPIとコネクタ側の実装の両方です。想定どおりの結果が返るか、自分の環境で一度確認してから業務フローに組み込みます。

SmartHR・kintoneなど他の人事労務SaaSとの連携や、自社製・非公式の違いを横断的に比べたい場合はClaude人事労務連携ガイド — SmartHR・ジョブカン・kintoneにあります。