BacklogのMCPサーバーをSlackbot MCP Clientに接続
Slackbot MCP クライアントという機能をSlackで使えるようになっていました。
これはSlack内蔵のAIアシスタント「Slackbot」に、外部のMCP（Model Context Protocol）サーバーを接続し、自然言語のやり取りの中からツールを呼び出せるようにする仕組みです。
今回は、Nulab社が公開しているBacklog公式MCPサーバーをこのSlackbot MCP Clientに接続し、Slack上でBacklogのプロジェクトや課題を扱えるようにしてみたので、その手順を紹介します。
Slackbot MCP Clientの仕組み
詳細な仕組みは公式ドキュメントにまとまっていますが、実際に触ってみて分かった要点は3つあります。
まず、MCPサーバーを呼び出すのは通常のSlack Bot（チャンネルに追加するタイプのアプリ）ではなく、Slack標準のAIアシスタントであるSlackbot自身です。
次に、Slackアプリの役割はMCPサーバーの登録窓口でした。App Manifestにmcp_serversブロックを追加してURLと認証方式を登録すると、そのMCPサーバーがワークスペースで使えるようになります。
そして、実際に有効化するかはユーザー個人の判断です。Slackbotとの DMで「Apps」から明示的に追加する必要があり（1人あたり同時に最大5サーバーまで）、サードパーティのツール呼び出しは都度、または「常に許可」でユーザーが承認する仕組みになっています。
認証方式は次の4種類があり、MCPサーバー側の対応状況に応じて選びます。
| 認証方式 | 用途 |
|---|---|
| No auth | 誰に対しても同じレスポンスを返す場合 |
| Slack identity auth | SlackのユーザーID/チームIDをMCPサーバー側に伝える場合 |
| Dynamic Client Registration（DCR） | MCPサーバーがRFC 7591のDCRに対応している場合 |
| Manual OAuth | DCR非対応で、認可URL・トークンURLなどを個別設定する場合 |
Backlog公式MCPサーバーはOAuth 2.0認証を有効にするとPOST /registerエンドポイント（RFC 7591準拠のDynamic Client Registration）を自動公開するため、今回はDynamic Client Registrationを選択します。
前提条件
- Backlog MCPサーバーをHTTPでリモート公開できる環境（今回は
https://hogehoge.fuga/mcpのようなHTTPSエンドポイントを用意） - Slackワークスペースの管理者権限、またはアプリ作成・インストール権限
手順1：Backlog側にOAuthアプリケーションを登録する
Backlogスペースの「個人設定」→「アプリケーションの登録」から、OAuthアプリケーションを新規登録します。
- リダイレクトURI:
<Backlog MCPサーバーのベースURL>/callback（例:https://hogehoge.fuga/callback） - 発行された Client ID と Client Secret を控えておきます。
手順2：Backlog MCPサーバーをOAuthモードでデプロイする
今回はbacklog-mcp-serverのDockerイメージをビルドしてECRにpushし、ECS Fargate上でHTTPトランスポートのコンテナとして起動しました。
コンテナには以下の環境変数を設定します（ローカルで直接動かす場合も同じ環境変数でnode build/index.js --transport http --http-host 0.0.0.0 --http-port 3333のように起動できます）。
BACKLOG_DOMAIN=your-space.backlog.com
BACKLOG_OAUTH_CLIENT_ID=your-client-id
BACKLOG_OAUTH_CLIENT_SECRET=your-client-secret
MCP_SERVER_BASE_URL=https://your-mcp-server
ECS Fargateサービスの前段にALB（Application Load Balancer）を置き、HTTPS化したエンドポイントとしてhttps://hogehoge.fuga/mcpを公開しています。
OAuthモードを有効にするとBACKLOG_API_KEYは不要になり、各ユーザーが自分のBacklogアカウントで認証する形になります。起動すると以下のOAuthエンドポイントが自動公開されます。
GET /.well-known/oauth-authorization-serverGET /.well-known/oauth-protected-resource/mcpPOST /register（Dynamic Client Registration）GET /authorizeGET /callbackPOST /token
制約事項: このOAuthモードは単一のBacklog組織のみをサポートしており、複数組織設定とは併用できません。また、クライアント登録やトークンはメモリ内保持のため、サーバー再起動で失われます。
手順3：Slack側にMCPサーバーを登録する
Slackアプリ（新規作成でも既存アプリへの追加でも可）のApp Settingsから設定します。
- api.slack.com/apps でアプリを開く
- 左サイドバー「Features」→「MCP Servers」を開く
- 「+ Add MCP Server」をクリック
以下の内容を入力します。
- Name:
Backlog MCP Server - URL:
https://your-mcp-server/mcp - Auth type:
Dynamic Client Registration - Identity URL（optional）: 今回は空欄（Backlog MCPサーバーはユーザー識別用エンドポイントを公開していないため）
- Account Identifier（optional）: 同上、空欄
「Save」をクリックすると設定が保存され、アプリのBot Tokenスコープにmcp:connectが自動追加されます。
手順4：アプリを再インストールする
スコープが変更されたため、アプリの(再)インストールが必要です。
「OAuth & Permissions」→「Install to Workspace」（Enterprise Gridで組織レベルインストールしている場合は組織単位で再インストール）から実行します。
手順5：Slackbotでツールを有効化する
- Slackbotとの DM を開く
- ツールバーの「Apps」ボタンをクリック
- アプリを管理するをクリックし、一覧から、追加したアプリを連携する
- Slackの外部サービスに接続しようとしていますというページが表示されるので、移動するをクリック
- Backlog側のOAuth認可画面にリダイレクトされるので、認証・許可する
手順6: ツールの設定
認証・許可されたら、MCPサーバーの管理ができる画面が開きます。
ツールごとに
- 常に許可する
- 承認が必要
- ブロックする
が選べるので、必要に応じて設定しています。
変更したら保存を押して反映。
動作確認
Slackbotに次のように話しかけてみます。
Backlogから利用可能なツールを教えて
Slackbotが接続先MCPサーバーのツール一覧を取得し、説明つきで返してくれれば接続成功です。
続けて実際にツールを使ってみます。
私のBacklogプロジェクトをすべてリストアップして
MCPサーバーの許可設定によっては「Allow once」「Always allow」「Deny」の確認が表示されます。許可するとSlackbotがツールを実行し、結果を返してくれます。
ハマったポイント
接続確認自体はうまくいきましたが、その後の運用の中で2つのエラーに遭遇しました。原因の切り分けに手間取ったので、troubleshootingの記録として残しておきます。
なお、この接続には2つの別々の認証層が関わっています。
- 層1（Slack↔MCPサーバー間）: Slack（MCPクライアント）がBacklog MCPサーバーに接続する資格があるかどうかの認証。DCRによってSlackがMCPサーバーの
/registerに自己登録し、client_id/client_secretを受け取る部分。個人のBacklogアカウントはまだ関係しない。 - 層2（個々のユーザー↔Backlog間）: 層1が確立した後、実際にツールを使おうとしたユーザー本人がBacklogにログイン・許可し、自分自身のBacklogアカウントの権限でアクセストークンを得る部分。
ケース1：接続時にinvalid_client: Unknown client_id（層1）
- 自分は接続できるが、別のメンバーだと
/authorizeの時点でinvalid_clientになる - 自分の接続を解除して、再度認証しようとすると同じエラーとなった
- Backlog本体側（OAuthアプリのclient_id/secret、登録ドメインなど）は一致しており、問題なかった
原因について、READMEには「DCRで発行したクライアント登録情報はメモリ内にのみ保持され、サーバー再起動で失われる」という既知の制約が明記されています。ここから「ECS Fargateタスクの再起動・入れ替わりでclient_idが失われたのではないか」という推測に至りましたが、実際にタスクの再起動タイミングとエラー発生タイミングを突き合わせて確定させたわけではありません。
対処としては、個々のユーザーの「接続解除→再接続」では直らず、Slackクライアントを完全に再起動してMCP Server連携を作り直すと解消しました。これも「Slack側がDCRの結果をクライアントにキャッシュしていて、再起動でそのキャッシュがクリアされた」という推測に基づく説明で、Slack公式ドキュメントに明記された挙動ではありません。
ケース2：接続はできるがツール呼び出し時にエラー（層2）
確認できた事実は、層1（接続）は成功しているのに、特定のユーザーがツールを呼び出すとエラーになる、という点だけです。Slackbotのインテグレーションから連携を解除し、再連携したら解消しました。「そのユーザー個人のBacklogトークンが古い状態のままキャッシュされていたのでは」という説明は辻褄が合いますが、これもサーバー側のログや実際のトークンの状態を見て確定させたものではありません。
エラーが起きたら、まず「Backlogのログイン画面が一度でも表示されたか」で層1/層2どちらの問題かを切り分けるのがおすすめです。表示されないまま失敗するなら層1、表示されて許可した後に失敗するなら層2です。原因の断定は避け、あくまで「この対処で直った」という再現性ベースの情報として参考にしてください。
まとめ
BacklogのMCPサーバーは、OAuthモードを有効にするだけでSlackが要求するDynamic Client Registration（RFC 7591）に対応していたので、Slackbot MCP Client側で特別な追加実装をする必要はありませんでした。
Backlogをタスク管理の中心に置いているチームなら、Slackから離れずに課題の確認や更新ができるのはやはり便利です。ただしBacklog MCPサーバー側がまだ単一組織・メモリ内トークン保持という制約を持っているので、顧客ごとにBacklogスペースを分けて運用しているようなチームだと、今のままではもう一工夫必要そうです。
そして、SlackのTodayという機能からも呼び出しはしてくれないようでした。これができれば毎日のブリーフィングでタスクの確認が捗ると思ったのですが、今後に期待したいです。
