Claude Codeで案件管理するMCP構成｜請求まで自動化する

Claude Code MCPでタスク管理を自動化しても、受託業務では見積・請求の処理が残ります。 Claude CodeにJiraやNotionのMCPをつないでタスクを操作させる話は、2026年に入ってから一気にありふれた構成になりました。主要なタスク管理ツールから公式MCPが相次いで提供されているからです。Backlog、Asana、Notion、monday.com、Jooto、Wrike、ClickUpは公式情報で提供状況を確認できます。ただし、認証方式、利用できる操作、対象プランは同じではありません。接続の有無だけで選ばず、権限と業務データの範囲を確認する必要があります。

だからこそ、次に考えるべきは「どの層を操作させると一番リターンが大きいか」です。結論を先に書くと、受託で食べている人にとってそれはタスクの層ではなく、案件の層（クライアント・見積・請求）です。

タスク管理MCPで自動化できることと残る仕事

タスク管理ツールのMCP接続で実際に楽になるのは、次のあたりです。

• 仕様ドキュメントからのチケット一括起こし（受け入れ条件付き）
• 実装セッション終了時の進捗コメント自動記録
• 「今日やるべきチケットを依存関係込みで並べて」系の横断クエリ
• スタンドアップ用の進捗サマリ生成（昨日動いたチケット・止まっているチケット・ブロッカー）

接続方法は製品ごとに異なります。NotionとAsanaの公式ホスト型MCPはOAuth認可を使います。固定のBearerトークンを全製品へ渡す共通設定にはしません。ローカルで起動するstdio型や、公式がAPIトークンを指定する製品もあるため、接続先ごとに公式手順を確認します。

NotionをClaude Codeへ接続する例

# Claude Code公式ドキュメントに掲載されているNotionの登録例
claude mcp add --transport http notion https://mcp.notion.com/mcp -s user

# 登録状態を確認する
claude mcp list

登録後はClaude Codeの/mcpからOAuth認可を完了します。最初の確認は、検証用ページの検索と読み取りだけにします。更新・削除・一括操作を始める前に、利用できるツール一覧と対象ワークスペースを確認してください。Asanaはhttps://mcp.asana.com/v2/mcpを使い、OAuthとStreamable HTTPに対応するクライアントが必要です。接続できない場合も、APIキーをコマンドへ足すのではなく公式の認証要件を確認します。

接続確認を終えたと判断する条件

1. MCPサーバーが接続済みと表示され、OAuth認可が完了している
2. 利用できるツール一覧を確認し、読み取りと書き込みの範囲を説明できる
3. 検証用ページまたは案件を1件だけ読み、期待したタイトルと状態を取得できる
4. 削除、一括更新、対外送信は許可していない

ただし、タスク管理MCPが扱うのは接続先に保存されたデータです。タスク管理側に見積・請求データがなければ、「納品→検収→請求書ドラフト→発行確認」までを同じ接続だけで処理できません。タスクを完了した後に、別の表や会計ソフトから案件名、単価、請求先を探す作業が残ります。

「MCP×案件管理」が空白地帯だった理由

理由は、タスクと見積・請求を別の製品で管理する構成が多いからです。MCPは接続先にない情報を補えません。タスク管理ツールを選ぶときは、公式MCPの有無とは別に、見積項目、請求先、追加対応、請求状態を保存できるかを確認します。公式サイトに記載がない機能は、あるものとして扱いません。

Claude Codeへ「A社の追加対応分を、見積の単価で請求書ドラフトにして」と頼むには、案件ID、見積項目、完了タスク、追加対応、請求先が機械的に結び付く必要があります。エージェントの能力より先に、参照できるデータと承認手順をそろえます。

この空白に対して、受託業務特化の案件管理ツールTASKULがMCP連携をベータ提供中です（筆者はTASKULの運営に携わっています）。クライアント、案件、見積、タスク、請求が同じ案件IDでつながるため、タスクと単価、請求先を突合できます。ベータ段階のため一般開放はまだですが、受託×エージェントの構成を考えている人はデータをこの形に寄せておく価値があります。

いま組める現実的なMCP構成

一般開放済みのツールだけで今日組む場合は、次の3層に分けます。

1. タスク層: 現行ツールの公式MCPをそのまま接続（Backlog/Notion/Jira等）。チケット起こしと進捗記録をエージェントに移譲する
2. 収支データ層: 見積・請求の情報を構造化してエージェントが読める場所に置く。スプレッドシート＋MCPでも、ローカルのSQLite＋自作MCPサーバーでも成立する。重要なのは案件IDでタスク層と突合できること
3. 月次処理: 「今月の全案件について、完了タスクと見積を突き合わせて請求書ドラフトと未請求リストを出して」をエージェントの定型ジョブにする

収支データ層の最小スキーマ

自作するなら2の層が肝です。最小構成はテーブル3枚で足ります。

CREATE TABLE clients (
  id INTEGER PRIMARY KEY,
  name TEXT,
  company_name TEXT,
  email TEXT,
  phone TEXT,
  created_at TEXT
);

CREATE TABLE deals (
  id INTEGER PRIMARY KEY,
  client_id INTEGER,
  project_key TEXT NOT NULL UNIQUE,  -- タスク層の案件キー
  name TEXT,
  deal_date TEXT,
  status TEXT,
  created_at TEXT
);

CREATE TABLE deal_items (
  id INTEGER PRIMARY KEY,
  deal_id INTEGER,
  task_item_key TEXT NOT NULL UNIQUE,  -- 完了チケットのキー
  name TEXT,
  description TEXT,
  quantity REAL,
  unit_price INTEGER,
  is_extra INTEGER DEFAULT 0,
  created_at TEXT
);

設計の急所は2つだけです。deals.project_keyを一意にして案件を結び、deal_items.task_item_keyを一意にして請求項目と完了チケットを結びます。追加対応にはis_extraを立てます。この2つのキーがあるため、完了チケットに対応する請求項目があるかをクエリで判定できます。

TASKULはクライアント、案件、見積、タスク、請求を結ぶデータ構造を持ち、MCP連携をベータ提供中です。一般開放の時期は未定です。現時点では既存のタスク管理と収支データをproject_keyで結び、読み取りだけで突合結果を検証する方法が現実的です。

月次定型ジョブのプロンプト例

収支層とタスク層の読み取りを接続したら、まず次のプロンプトをdry-runで実行します。出力はドラフトに留め、元データを更新しません。

今月の月次請求チェックをやって。手順:
1. deals から status が active/delivered の案件を全部出す
2. 各案件について、project_key でタスク管理側の
   今月完了チケットを取得する
3. 完了チケットの task_item_key のうち deal_items.task_item_key にないものを
   「未請求の疑い」としてリストアップする
4. 案件ごとに「見積内の完了分」「is_extra の追加分」「未請求疑い」を
   分けた請求ドラフトを Markdown で出す
5. 金額の確定と発行はやらない。ドラフトとリストだけ

最後の1行が重要で、金額が絡む確定操作はエージェントに渡さないのが原則です（次の節）。

認証情報を接続する前の確認事項

タスク管理・案件管理のMCPは、OAuth接続でもAPIトークンでも業務データへアクセスできる状態になります。接続前に最低限これだけは確認してください。

• 権限のスコープ: その接続で「できてしまうこと」の全範囲。タスク読み書きのつもりが管理系APIまで叩ける、という設計のツールは実在します。公式ドキュメントで権限範囲を確認し、指定できる場合は最小にする
• 認証情報の保存場所: トークンをMCP設定へ書く方式では、そのファイルの共有範囲を確認する。OAuth方式でも認可済み接続を共有しない。dotfilesをGitHubに上げている人は、~/.claude.json 系の設定ファイルが除外されているか一度確認したほうがいいです
• 1人1接続の原則: チームで認証情報や設定を使い回すと、誰の操作か監査できません。利用者ごとに認可し、管理者が接続を取り消せるかを確認する
• 破壊的操作の扱い: 削除・一括更新をエージェントの許可リストに入れるか。特に物理削除系のAPIはUndoが効きません。読み取り＋作成＋コメントまでを許可し、削除は人間の承認を挟むのが実務的な落とし所です
• 確定操作の分離: 請求書の発行・送信のような対外的に取り消せない操作は、ドラフト生成（エージェント）と確定（人間）に分ける

公式MCPの提供が増えた現在も、接続の有無だけでは安全性を判断できません。権限設計と、どの層のデータを触らせるかを先に決めます。

運用して分かる細かい注意点

• チケットの書式をエージェント向けに固定する: 受け入れ条件・完了定義をテンプレ化してCLAUDE.md（またはツール側のテンプレート）に置くと、起こしたチケットの品質が安定します。人間向けの自由記述のままだと、エージェントの解釈ブレがそのまま実装ブレになります
• 進捗コメントは構造化させる: 「やったこと/残り/ブロッカー」の3項目で書かせると、後日の横断クエリ（今止まっている案件はどれ？）が効くようになります
• ホスト型とローカル（stdio）の使い分け: ホスト型はOAuthや管理者による接続管理を提供する場合があります。ローカル型は自分で更新、秘密情報、実行権限を管理します。人数だけで決めず、公式サーバーの有無と必要な権限で選びます
• レート制限: 一括起票や横断クエリはAPI呼び出しが膨らみます。各ツールのレート制限を公式ドキュメントで確認し、Claude Codeの定期実行では案件単位に分割し、失敗した位置から再開できるようにします

権限は読み取り・下書き・確定の3段階に分ける

MCPへ渡す権限は、読み取り、下書き作成、対外的な確定の3段階で分離します。 タスクの検索と請求書の送信を同じキーで許可すると、日常的な検索を任せるだけで、取り消せない操作まで実行できる状態になります。

① 読み取り専用で突合ロジックを検証する

最初はタスクと案件データの読み取りだけを許可するところから始めます。完了チケット、見積項目、追加対応フラグを取得し、未請求の疑いをMarkdownで出す範囲に留めます。データは更新せず、人が正解と照合できるログを保存してください。

誤検知と見落としを別々に数える

追加対応ではないタスクを「未請求」と判定した件数と、本当に追加対応なのに拾えなかった件数を分けます。2つを合計した正解率だけでは、余計な確認が増えたのか、請求漏れが残ったのか判断できません。

② ドラフト作成だけを許可する

読み取り結果が安定したら、請求候補や進捗コメントの下書きを作成できる権限を足します。作成先は「ドラフト」状態に固定し、発行済みや送信済みへは変更できません。下書きには、根拠となったチケットIDと見積項目IDも記録します。

再実行しても重複しない設計にする

同じ月次処理を再実行したとき、請求書ドラフトが二重に作られないことを確認します。案件ID、対象月、ドラフト種別を組み合わせた一意キーを持たせると、途中で止まった処理も安全にやり直せます。

③ 確定と発行は人が行う

金額、税区分、請求日、宛先を人が確認し、承認済みに変えた後で発行します。MCP側には承認操作を持たせないか、毎回の明示確認を必須にします。請求書の送信や入金消込まで自動化する場合も、別の権限と監査ログが必要です。

本番接続前にdry-runで確認する5項目

本番データへ書き込む前に、読み取りだけのdry-runを同じ条件で繰り返します。正常系だけでなく、追加対応、取消、再実行、API失敗を含めます。

失敗した処理の再開位置を残す

月次処理の途中でAPIが止まった場合は、最後に完了した案件IDと処理段階を記録してください。最初から再実行して重複を作るのではなく、未処理の案件から再開できるようにします。

1. 同じ案件IDでタスクと見積が結び付くか
2. 完了していないタスクを請求候補から除外できるか
3. 見積外フラグのある項目を別枠で出せるか
4. 同じ処理を再実行してもドラフトが重複しないか
5. 一部のAPIが失敗したとき、完了扱いにせず再開位置を残せるか

検証ログには、実行日時、使用したキーの利用者、参照した案件ID、生成したドラフトID、エラーを残します。APIレスポンスの全文へ個人情報を残す必要はありません。監査に必要な識別子と処理結果へ絞ります。

本記事の執筆者はTASKULの運営に携わっています。他社ツールのMCP対応状況・機能は2026年9月22日時点の各社公式サイト・公式ドキュメントの記載に基づいています。

参考にした公式ドキュメント

• Backlog MCP: 公式リポジトリ
• Asana MCP: 公式ドキュメント
• Notion MCP: 公式ドキュメント
• monday.com MCP: 公式ページ
• Jooto MCP: 公式発表
• Wrike MCP: 公式ドキュメント
• ClickUp MCP: 公式ヘルプ
• TASKUL: 公式サイト