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シリーズ