Chatworkタスク管理をClaudeで効率化する使い方

Chatworkタスク管理をClaudeでどう変えるか

Chatwork公式のMCPサーバーを接続すると、複数のグループチャットに散らばったタスクと未読メッセージを、日本語の指示だけでまとめて扱えるようになります。「今日中の期限は?」と聞くだけで済みます。差が出るのは一覧を眺める場面より、複数チャットをまたいでタスクを拾い上げ、担当者を決めて追加する場面です。

この記事は接続済みであることを前提に、タスクとメッセージの管理でつまずきやすい点と、使い分けの具体例に絞って扱います。業務系MCPサーバーはChatwork以外にも数多く公開されており、目的別の選び方はおすすめMCPサーバー10選で扱っています。

接続の前に決めておくこと

Chatwork公式が公開している@chatwork/mcp-serverは、APIトークンを1つ環境変数に渡すだけで動きます。Claude CodeならリポジトリのREADMEにあるとおり、次のコマンドで追加できます。

claude mcp add chatwork \
  -e CHATWORK_API_TOKEN=YOUR_CHATWORK_API_TOKEN \
  -- npx -y @chatwork/mcp-server

接続できたかどうかはclaude mcp get chatworkで確認できます。接続方式の詳細や別のMCPサーバーとの共通点はClaude Code MCP設定ガイドにまとめてあります。接続できないときの切り分けはMCPサーバーに接続できないときの切り分け手順を参照してください。

ここで1つ、コマンドを実行する前に知っておきたい点があります。claude mcp addは--scope(-s)を省くとlocalスコープに保存されます。-s projectを付けると、プロジェクト直下の.mcp.jsonに書き込まれます。v2.1.286で、空の作業ディレクトリに対して-s project付きで同じコマンドを実行したところ、.mcp.jsonは次の内容になりました(トークンはダミーです)。

{
  "mcpServers": {
    "chatwork": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@chatwork/mcp-server"],
      "env": {
        "CHATWORK_API_TOKEN": "YOUR_CHATWORK_API_TOKEN"
      }
    }
  }
}

トークンが平文のまま入ります。このファイルをGitにコミットすると、トークンも一緒に共有されます。チームで同じ設定を使いたいなら、envの値を${CHATWORK_API_TOKEN}のように書く方法があります。Claude Codeの公式ドキュメントによると、.mcp.jsonはcommand・args・env・url・headersで環境変数の展開に対応しています。各メンバーが自分のトークンを環境変数に置けば、ファイルには値が残りません。未設定のメンバーには${CHATWORK_API_TOKEN}という文字列がそのまま渡り、claude mcp listに警告が出ます。

手元で使うか、サーバーとして立てるか

READMEには、既定のstdioとは別に、Streamable HTTPで起動する方法も載っています。違いは「誰がサーバーを起動するか」と「トークンをどこに置くか」です。

HTTP方式の既定は127.0.0.1:3000で、エンドポイントはPOST /mcpです。ヘッダが無いと401が返ります。Claude Codeから接続するときは--transport httpと--headerを使います。v2.1.286では-s projectを付けた次のコマンドで登録でき、.mcp.jsonには"type": "http"、url、headersとして保存されました。

claude mcp add -s project --transport http chatwork-http http://127.0.0.1:3000/mcp \
  --header "Authorization: Bearer YOUR_CHATWORK_API_TOKEN"

登録時の出力では、ヘッダの値は[REDACTED]と伏せ字になりました。接続の前にサーバーを起動しておくのを忘れると、登録は通っても繋がりません。

自分のタスクとチャットのタスクを使い分ける

タスクを確認するツールは2系統に分かれます。片方は自分が担当者のタスクだけを横断で見るもの、もう片方は1つのチャットの中のタスクを見るものです。目的によって選ぶツールが変わります。

statusはopenとdoneの2値しかありません。タスクの応答に含まれるのは、担当者・依頼者・本文・期限・完了状態などです。優先度を表す項目は見当たりません。Claudeに「優先度の高いタスクだけ」と頼んでも、判断材料になる列がデータにないのです。緊急度は本文やタスク名に書き込む運用で補います。

担当者を指定してタスクを作る

create_room_taskでタスクを追加するとき、担当者は名前ではなくアカウントIDで指定します。Chatwork APIのto_idsは「チャットに所属しているアカウントのIDをカンマ区切りで指定」する項目です。名前や表示名を受け付ける欄はありません。

チャットに参加していない相手は担当者に指定できません。APIの仕様書には、担当者がチャットに所属していないタスクを追加すると403が返るという記載があります。社外のパートナーにタスクを振りたい場合は、先にそのチャットへ招待しておく必要があります。

期限の指定は2段階です。まずlimit_typeにdateかtimeを渡すと期限付き、noneにすると期限なしになります。省略時の既定値はtimeです。次に、期限の値そのものはlimitにUnix時間(秒)で渡します。日付だけ決まっていて時刻は決めたくない場合は、明示的にdateを指定してください。

担当者に複数人を指定する場合は、アカウントIDをカンマ区切りで並べます。応答はtask_idsの配列で返り、仕様書の例にはIDが2つ並んでいます。「チーム全員に同じタスクを振って」と頼んで担当者の数だけIDが返ってきても、異常ではありません。

未読メッセージの確認と投稿

メッセージ系のツールも用途で選び方が変わります。

list_room_messagesにはforceという引数があります。既定値の0では、前回そのチャットを取得した時点からの差分だけを返します。1にすると、強制的に最新のメッセージを最大100件まで取得します。「今日の未読を要約して」には既定値で足ります。「このチャットの直近のやり取りを全部見せて」と頼むときは、force=1を意識してください。

APIの仕様書には、メッセージが0件だった場合に204が返るとも書かれています。差分が無いとき、空の応答になるのはこのためです。タスク一覧も同じで、該当が0件なら204が返ります。「今日のタスクを教えて」で空の応答が返っても、取得失敗とは限りません。「新着なし」と「取得失敗」を取り違えないよう、Claudeの返答に件数が書かれているかを見ておくと安心です。

毎朝の状況把握を1回の呼び出しにする

get_my_statusは、未読があるチャットの数・自分宛ての未読があるチャットの数・未読数・自分宛ての未読数をまとめて返します。さらにmytask_num(自分が担当者のタスクの数)とmytask_room_num(タスクがあるチャットの数)も含まれます。

「今日やることある?」という質問なら、まずこのツールで全体量を見て、件数が多いときだけlist_my_tasksで内訳を取る頼み方ができます。件数がゼロなら、タスク一覧の取得を省略できます。出社直後に未読とタスクを画面ごとに確認する代わりに、1回の呼び出しで「対応が要るかどうか」を判断する使い方です。

指示の出し方と呼ばれるツールの対応

自然文でどう頼むと、どのツールが使われそうかを具体例で示します。実際にどのツールをどの順で呼ぶかはClaudeの判断なので、ツール名を指示に書き込むと挙動が安定します。

• 「今日期限の自分のタスクを教えて」→ list_my_tasksで取得し、limit_timeが当日に入るものだけを抽出して回答します
• 「経理チームのチャットに、来週月曜期限で領収書提出のタスクを佐藤さん宛てに作って」→ チャットの特定、list_room_membersでのID確認を経て、limit_typeをdateにしたcreate_room_taskを呼びます
• 「昨日の夜以降の未読を要約して」→ list_room_messagesで取得し、send_timeが該当時間以降のメッセージだけを抜き出して要約します

個々のツールは1回の呼び出しで単純な操作しかしません。複数ステップが必要な指示ほど、途中でアカウントIDやチャットIDの特定が挟まり、呼び出し回数が増えます。回数が増えると、次の制限に近づきます。

見落としやすい2つの回数制限

ChatworkのAPIには、全体の呼び出し回数制限に加えて、投稿系のエンドポイントだけにかかる追加制限があります。

投稿系の制限は、メッセージ投稿(POST /rooms/{room_id}/messages)とタスク追加(POST /rooms/{room_id}/tasks)の呼び出し回数の合算です。つまり、同じチャットへ連絡を5回投稿し、さらにタスクを5件足せば、それで上限に届きます。超過すると、Rate limit for message posting per room exceeded.というエラーメッセージ付きの429が返ります。

この制限が効いてくるのは、複数のチャットへ一括でタスクや連絡を流すときです。「10部屋全部に同じ連絡を今すぐ送って」と頼んでも、部屋が別なら10秒10回には触れにくい構成です。逆に、1つのチャットに「連絡を送って、全員分のタスクも作って」と頼むと、合算で早く上限に近づきます。

できないことと、破壊的な操作

タスクまわりで「できない」ことは、読者がつまずく前に知っておきたい点です。ツールの一覧(READMEの31ツール)を見ると、タスク関連はlist_room_tasks・create_room_task・get_room_task・update_room_task_statusの4つだけです。

• 作成済みタスクの本文や期限は変更できません。変更できるのは完了状態(openとdone)だけです。内容を間違えたときは、新しいタスクを作り直して古い方を完了にします
• タスクを削除するツールはありません
• サブタスクのような親子関係を示す項目は、作成パラメーターにも応答にも見当たりません。関連するタスクは本文に参照先を書いてつなげます
• 100件を超える過去のタスクは、一度には取得できません。一覧の仕様は「最大100件」で、ページ送りの仕組みも見当たりません。期間で絞る引数も無いため、棚卸しはstatus=doneや担当者・依頼者のIDで絞り込み、100件に収まる単位に分けて追う形になります

失敗の出方にも種類があります。仕様書には、タスクの追加で403になる理由が3通り書かれています。トークンのスコープが不足している場合、自分が所属していない(または権限が足りない)チャットへの追加、担当者がチャットに所属していない場合です。タスク一覧やメッセージ一覧の取得も、所属していないチャットを指定すると403になります。Claudeが「権限がありません」と返したときは、トークンの問題かチャットの所属の問題かを、この3通りで切り分けられます。

タスクの絞り込みには、役割の違う2つのIDがあります。自分が振ったタスクの進捗を追うなら依頼者のassigned_by_account_id、自分に振られたタスクなら担当者のaccount_idかlist_my_tasksを使います。

一方で、取り返しのつかない操作もあります。チャットの退席と削除を行うdelete_or_leave_roomは、APIの仕様書によると次のように働きます。

Claudeに「使っていないチャットを整理して」のような曖昧な指示を出すと、意図しないチャットが対象に入る恐れがあります。破壊的な操作は、対象を1つずつ確認してから実行する運用が安全です。

Chatworkのタスク画面とは何が違うか

Chatworkには元々「マイタスク」画面があり、自分が担当者のタスクを全チャット横断で見ることはAI無しでもできます。ここでClaudeを挟む意味は、閲覧そのものより「確認して、判断して、次の操作に移す」までを1つの指示にまとめられる点にあります。

たとえば「今日期限のタスクを確認して、終わっていないものだけ担当者に催促のメッセージを送って」という指示は、Chatwork単体では一覧確認・担当者の特定・メッセージ作成という3画面をまたぐ作業です。Claude経由なら、list_my_tasksで期限を確認し、post_room_messageで催促文を投稿するところまでを一連の流れで任せられます。ただし催促の相手が他人のタスクだと、list_my_tasksでは見えません。自分が依頼したタスクなら、list_room_tasksをassigned_by_account_idで絞ります。

個々のツールはAPIをそのまま薄くラップしたものです。組み合わせて連続実行できる点が、手作業との違いです。

まとめ

最初のハードルは、担当者をアカウントIDで調べておくことと、トークンを.mcp.jsonに平文で残さないことの2つです。そのうえで、一覧は最大100件でページ送りがなく、投稿とタスク追加はチャットごとに10秒10回までという制約を、依頼の分け方で避けることになります。