2つのアカウントを行き来する地味なストレス
Chatworkのアカウントを2つ持っている。1つは自分の仕事用。もう1つは事務局業務専用。
仕事用のルームでメッセージを確認し、事務局用に切り替えて別のルームを確認し、また戻る。ブラウザのタブを2つ開いて、行ったり来たり。ログアウト→ログインを繰り返す日もあった。
地味だが、これが毎日続くとボディブローのように効いてくる。
Claude CodeにChatwork MCPを繋いだとき、ふと思った。MCPって、同じサービスを2つ繋げるのか？
結論から言うと、できた。しかも想像以上に快適だった。
claude_desktop_config.json の書き方
MCPの設定ファイルに、同じサーバーを別名で2つ書く。ポイントは キー名を変えること だ。
{
"mcpServers": {
"chatwork": {
"command": "npx",
"args": ["-y", "@anthropic-ai/chatwork-mcp"],
"env": {
"CHATWORK_API_TOKEN": "仕事用のトークン"
}
},
"chatwork-office": {
"command": "npx",
"args": ["-y", "@anthropic-ai/chatwork-mcp"],
"env": {
"CHATWORK_API_TOKEN": "事務局用のトークン"
}
}
}
}
chatwork と chatwork-office — 同じMCPサーバーを、異なるAPIトークンで2つ起動する。これだけだ。
起動すると、ツール一覧にこう並ぶ。
mcp__chatwork__list_rooms
mcp__chatwork__list_room_messages
mcp__chatwork-office__list_rooms
mcp__chatwork-office__list_room_messages
...
プレフィックスが chatwork と chatwork-office に分かれる。Claude Codeは「どっちのアカウントのツールを呼ぶか」を自分で判断できる。
名前の付け方が全てを決める
最初、2つ目を chatwork-2 にした。動くには動くが、Claude Codeが混乱する。「chatwork-2のルーム一覧を取得して」と言わないと正しいほうを使ってくれない。
名前に意味を持たせる のが正解だった。
chatwork → 仕事用（メイン）
chatwork-office → 事務局用（サブ）
こう名付けると、「事務局のルームを確認して」と言うだけで chatwork-office のツールが使われる。「仕事用のメッセージ」と言えば chatwork が使われる。
名前がコンテキストになる。AIは名前から用途を推測する。chatwork-2 では推測材料がない。
実際の運用：1画面で2アカウントが回る
朝のルーティンはこうなった。
俺: 「仕事用と事務局用、両方の未読を確認して」
Claude Codeは2つのMCPを順番に叩いて、両方の未読を一覧で出す。アカウントの切り替え操作はゼロ。ブラウザのタブを開く必要もない。
もう一つ便利なのが、アカウントをまたいだ情報の統合だ。
俺: 「事務局のルームに来た質問に、仕事用アカウントの過去ログを参照して回答案を作って」
片方のアカウントの情報を、もう片方のアカウントの文脈で使う。これは手動では不可能に近い。コピペして、別のタブに貼って、文脈を思い出して……という作業が消える。
ハマりポイント3つ
1. APIトークンの取り違え
環境変数で管理する場合、変数名を分けないと事故る。
# NG — 後から設定したほうで上書きされる
export CHATWORK_API_TOKEN="xxx"
export CHATWORK_API_TOKEN="yyy"
# OK — 変数名を分ける
export CHATWORK_TOKEN_MAIN="xxx"
export CHATWORK_TOKEN_OFFICE="yyy"
MCPの設定ファイルで直接 env に書く場合は問題ないが、シェルの環境変数経由で渡す場合は変数名の重複に注意。
2. レート制限が合算される
Chatwork APIのレート制限（5分間300リクエスト）は アカウント単位 ではなく APIトークン単位 だ。2アカウントなら2つのトークンがあり、それぞれ独立してカウントされる。
つまり、2アカウント同時接続しても、レート制限が2倍きつくなることはない。これは助かった。
ただし、同じアカウントで複数のトークンを発行して同時に叩くと、同一アカウントに対するリクエストが集中する。やりすぎると一時的にBANされる可能性がある。1アカウント1トークンが無難だ。
3. account_idの混同
get_me で返ってくる account_id が、どちらのアカウントのものか混同しやすい。
俺: 「自分のアカウント情報を表示して」
この指示だと、Claude Codeがどっちの get_me を叩くか不定だ。「仕事用アカウントの情報」と明示するか、最初に両方の get_me を叩いて名前と紐づけておくのが安全。
3つ目以降も同じ要領
この方法は3つ目、4つ目のアカウントでも同じだ。キー名を変えて、トークンを変えるだけ。
{
"chatwork": { "env": { "CHATWORK_API_TOKEN": "メイン" } },
"chatwork-office": { "env": { "CHATWORK_API_TOKEN": "事務局" } },
"chatwork-client": { "env": { "CHATWORK_API_TOKEN": "クライアント用" } }
}
ただし、MCPサーバーの起動数が増えるとメモリ消費も増える。3つくらいなら問題ないが、10個は試していない。
MCPの仕様として正当な使い方
「これ、裏技じゃないの？」と思うかもしれない。
MCPの公式仕様では、HostがClient経由で複数のサーバーに接続するアーキテクチャが最初から想定されている。各サーバーに別々のMCP Clientが割り当てられるので、同じサーバーを異なる設定で複数起動しても干渉しない。仕様通りの使い方だ。
Claude Codeの公式ドキュメントでも、claude mcp add コマンドで --scope local/project/user を指定して階層管理できることが明記されている。プロジェクトごとに .mcp.json に設定を書けば、チームで共有する設定と個人の秘匿設定を分離できる。
つまり、同じMCPサーバーを複数起動するのは設計上想定された使い方であり、壊れやすいハックではない。安心して使っていい。
Chatwork以外でも使える
この「同じMCPを別名で複数起動」のパターンは、Chatworkに限った話じゃない。
- Gmail MCP × 2: 個人アカウントと仕事アカウントを同時に
- GitHub MCP × 2: 個人リポジトリと組織リポジトリを分けて
- Google Calendar MCP × 2: プライベートと仕事のカレンダーを横断管理
要するに、認証トークンが異なる同一サービスを並列で繋ぐ ユースケースなら何でも応用できる。MCPの仕様上、キー名さえ変えれば同じサーバーを何個でも起動できる。
まとめ
- 同じMCPサーバーを別名で複数起動すれば、複数アカウントを同時接続できる
- 名前に意味を持たせる（
chatwork-2ではなくchatwork-office） - レート制限はトークン単位なので、複数アカウントでも干渉しない
- account_idの混同に注意。最初に両方の
get_meを叩いて紐づけておく - Chatwork以外（Gmail、GitHub、Calendar等）でも同じパターンが使える
2つのアカウントを1画面で回す。言葉にすると地味だが、毎日のログイン/ログアウトが消えた効果は大きい。「切り替える」という行為自体がなくなると、思考が途切れなくなる。
Chatworkシリーズ
- #1 なぜ2026年にまだChatworkを使い倒しているのか
- #2 chatwork-client-gas、ぶっちゃけいるの？
- #3 ルームの参加者データだけで、組織の人間関係マップを作った
- #4 「Chatworkに確定連絡が来たら請求書を送る」をGASで自動化する
- #5 Chatwork MCPを繋いだら、17ルームの未読が10秒で片付いた
- #6 MCP vs GAS — Chatwork自動化の「正解」はどっちか
- #7 コンタクト承認をn8nで自動化しようとしたら、3つの罠にハマった
- #8 ChatworkにAIチームを住まわせたら、勝手に会話が始まった
- #9 Chatwork 8ルームの全メッセージからFAQ429件を自動抽出した
- #10 Webhook署名検証を入れたら全メッセージが消えた
- #11 過去メッセージを全件取得しようとしたら、APIの「100件の壁」にハマった
- #12 Chatwork APIの「既読」は自分で制御できる
- #13 Chatwork APIのファイル機能、使ったことある？
- #14 n8nで全ルーム巡回
- #15 タスク機能をAPIで使い倒す
- #16 MCPを2アカウント同時接続したら、仕事用と事務局用が1画面で回った（この記事）