ジョブカン経費精算Claudeで申請・承認状況を確認する方法

このTipsでできること

ジョブカン経費精算/ワークフローの申請書を、Claudeに話しかけるだけで「進行中のものだけ」「自分の申請だけ」のように絞り込んで確認できます。承認ステップのどこで止まっているかまで、1件ずつ画面を開かずに把握できます。

前提として、非公式のMCPサーバーjobcan-workflowをすでに接続していることが必要です。接続手順はClaudeジョブカン連携にまとめています。読み取り専用のコネクタなので、承認や却下の操作自体はできません。確認に特化したTipsです。

使うツールは主にlist_requestsとget_requestの2つです。前者が申請書一覧、後者が1件の詳細に対応します。役割が明確なので、どちらを使えばよいか迷うことはあまりありません。全体を俯瞰したいか、1件を深掘りしたいかで使い分けます。

やり方1: 申請全体のステータスで絞り込む

申請書には全体としてのステータスがあります。list_requestsツールのstatusパラメータで絞り込めます。

Claudeへの指示はステータス名を意識せず日本語で構いません。

進行中の経費精算をすべて一覧にして

今月、却下または差し戻しになった申請があれば教えて

G-2部署で進行中の申請が何件あるか教えて

3つ目のように部署コードを指定すれば、group_codeパラメータで絞り込んだ結果が返ります。全社分を一度に見たいときと、特定部署だけ見たいときで指示を変えられます。

自分の申請だけを追いたいときはapplicant_code(スタッフコード)、複数の申請を横断で見たいときは申請ID(id)をカンマ区切りで複数指定できます。並び順もsort_byで申請日の昇順・降順などに変えられるため、「古い順に並べて」「直近のものから見せて」といった依頼もそのまま反映されます。

タイトルの一部だけ覚えている申請を探すときはtitleパラメータが部分一致で効きます。「タイトルに"出張"と入っている申請を探して」のような曖昧な依頼でも、完全な申請名を思い出す必要はありません。

自分(スタッフコードa-13)が申請したもので、まだ進行中のものを古い順に見せて

やり方2: 承認ステップ単位で「誰が止めているか」を見る

申請全体のステータスだけでは、承認ルートの何ステップ目で止まっているかまでは分かりません。get_requestで申請書1件の詳細を取得すると、ステップごと・承認者ごとの状態が分かります。

こちらはlist_requestsとは別の語彙を使います。承認ルートの各ステップと各承認者には、次の4つの状態のいずれかが入ります。

申請書ID B-59の承認ルートを見せて。どのステップで止まっているか教えて

申請書ID B-59で、承認待ちのままになっている承認者は誰か教えて

代理承認者が設定されている場合、get_requestのレスポンスには代理承認者名も含まれます。誰が承認すべきかが分かりにくい申請でも、承認ルートの構造ごと確認できるのがlist_requestsだけでは得られない情報です。

各ステップにはステップ名と、承認完了の条件(「全員の承認が必要」か「誰か1人の承認が必要」か)も含まれます。3人の承認者が並ぶステップでも、全員の承認が要る設計なのか、誰か1人で次に進む設計なのかで「止まっている」の意味が変わります。この条件をClaudeに読み取らせておけば、「あと何人の承認を待てば次のステップに進むか」まで答えられます。

申請書ID B-59のステップ2は、誰か1人の承認で進むタイプ？それとも全員の承認が必要?あと何人待ちか教えて

やり方3: コメントと添付ファイルのやり取りを確認する

申請書の詳細には、承認ルートとは別に「コメント」と「添付ファイル」の履歴も含まれています。コメントはコメントしたユーザー名・日時・本文(削除済みならnull)、添付ファイルはアップロードしたユーザー名・日時・ファイル名を持ちます。

申請書ID B-59に付いているコメントを、日付順に要約して

この申請で承認者から差し戻し理由のコメントが付いていないか確認して

差し戻された申請でよくあるのは、コメント欄に理由が書かれているのに見落とすケースです。Claudeにコメント欄だけを抜き出させれば、Web画面をスクロールしてコメントを探す手間が省けます。

申請時に承認ルート自体が編集されていたかどうかもapproval_process.is_route_changed_by_applicantというフラグと、編集者名・日時を記録するapproval_route_modify_logsから分かります。通常のルートと違う経路をたどっている申請を見つけたいときの、確認の手がかりになります。

全体ステータスとステップステータスは別物

「進行中」と「承認待ち」を混同しやすいので切り分けます。in_progressは申請書全体が完了していない状態を指す英語の値で、list_requestsの絞り込みに使います。一方の「承認待ち」は承認ルートの個々のステップ・承認者の状態を指す日本語の値で、get_requestのレスポンス内に現れます。1件のin_progressな申請の中に、承認済みのステップと承認待ちのステップが混在しているのが通常の状態です。

3ステップの承認ルートを例にすると、ステップ1(部門長)が承認済み、ステップ2(経理)が承認待ち、ステップ3(役員)は未着手、という状態でも申請全体のstatusはin_progressのままです。list_requestsだけを見て「進行中の申請が10件ある」と分かっても、それぞれが3ステップ中どこで止まっているかはget_requestまで見ないと分かりません。承認が集中しがちな特定のステップを洗い出したいときは、in_progressな申請をlist_requestsで一覧化した後、それぞれのget_requestを呼んで止まっているステップ名を集計する2段階の依頼になります。

補足: 定型レポートに応用する

毎回同じ確認を繰り返すなら、プロンプトをテンプレート化しておくと手間が減ります。API側に集計エンドポイントは無いため、件数集計や経過日数の計算はすべてlist_requestsの結果を受けたClaude側の処理になりますが、依頼文さえ固定しておけば毎回同じ指示を打ち直す必要はありません。テンプレート化が効く場面には、次のようなものがあります。

• 経費精算のフォームが複数ある会社:list_formsで対象フォームのform_idを先に確認し、「このフォームの申請だけ進行中のものを見せて」のように絞り込みを重ねる
• 月次の締め作業:「毎月末に進行中のまま3営業日以上動きが無い申請を洗い出す」というルーティンを決めておき、担当者が個別にジョブカンを開いて確認する手間を省く
• 部署横断の経営会議資料:「各部署の進行中の申請件数と、そのうち5日以上動いていないものの件数を表にして」のように依頼し、group_codeごとのlist_requests呼び出しを部署の数だけ繰り返して集計する

部署数が多い会社では最後の使い方で呼び出し回数が増えますが、レート制限(1時間5,000リクエスト)の範囲であれば問題になりません。テンプレートは一度作って終わりではなく、実際に使ってみて足りない絞り込み条件に気づいたら、その都度プロンプトに条件を足していく前提で運用するとよいです。

MCP接続自体がうまくいかないときの切り分けはMCPサーバーに接続できないときの切り分け手順が参考になります。経費精算以外の経理業務でAIをどこまで任せられるかはCowork経理の実践でも扱っています。同じ経費精算領域でも楽楽精算は公式連携が無く、CSV出力を起点にデータを集計・チェックするアプローチになります。具体的な進め方は楽楽精算とClaude連携で経費データを集計・チェックするで扱っています。

よくある質問

承認待ちの申請を自動でSlackに通知させることはできますか

jobcan-workflow自体に通知機能はありません。Claude Codeで定期実行の仕組みを別途組み、list_requestsの結果を他のツールに渡す構成にすれば実現できますが、それは本記事の範囲を超えた別の設計になります。あくまで問い合わせに応じて結果を返すツールだと考えてください。

経費の金額まで正確に集計できますか

申請データの金額はレスポンスに含まれるフォームごとの項目次第です。フォームによって項目名が異なるため、正確に集計するにはlist_formsで対象フォームの構造を先に確認してから依頼すると精度が上がります。フォームを跨いだ横断集計をさせるときほど、この事前確認を省略しないほうが結果が安定します。

複数の申請書をまとめて指定できますか

list_requestsのidパラメータはカンマ区切りで複数指定に対応しています。「申請ID B-59とB-60とB-61の状況をまとめて見せて」のように依頼すれば、個別にIDを聞き直さずまとめて確認できます。

承認ルートの「全員承認」「誰か1人承認」の設定は事前に聞いておく必要がありますか

必要ありません。get_requestを呼ぶたびに、その申請書の承認ルートに設定されている条件がレスポンスに含まれます。フォームや部署によって承認ルートの設計が違っていても、申請書ごとに都度確認できます。

過去に取り消した申請も見られますか

list_requestsのinclude_canceledパラメータをtrueにすれば、取り消し済み(canceled)の申請も一覧に含められます。デフォルトでは除外されるため、過去分の棚卸しをするときだけ明示的に含める依頼をします。

まとめ

申請全体の状態はlist_requestsのstatus(英語の6値)、承認ルートの詳細はget_requestの各ステップ・承認者の状態(日本語の4値)と、見る対象が違います。両方を使い分ければ、「今どの申請が止まっていて、誰の承認待ちか」を画面を開かずに把握できます。承認・却下の操作自体はできない前提で、確認作業をClaudeに任せる使い方です。

コメント・添付ファイル・承認ルートの編集履歴まで含めれば、Web画面をタブごとに開き直さなくても、1件の申請の経緯をひとまとめに追えます。定例の確認作業をプロンプト1つに置き換える発想で使うのが向いています。

まずは自分の申請を一覧にして、進行中のものが承認ルートのどこで止まっているかをget_requestで確認するところから試すと、この2つのツールの役割の違いが体感しやすくなります。