Claude Backlog連携の設定方法とできること
ClaudeとBacklogをMCPサーバーでつなぐと、課題の作成・更新やGitのプルリクエスト確認を自然言語で頼めます。3つの導入方法と認証、権限設計までを手順で確認します。
Claude Backlog連携とは — 何ができるか
Claude Backlog連携とは、ヌーラボが開発するBacklog MCPサーバーをClaude Codeに接続し、Backlogの課題・プロジェクト・Wiki・Gitリポジトリを会話から操作できるようにする仕組みです。接続すると、課題の一覧取得や新規作成、コメント追加、プルリクエストの確認までを、Backlogの管理画面を開かずに頼めます。
できることは7つのツールセット(space / project / issue / wiki / git / notifications / document)に分かれ、既定では全部が有効になります。「PROJECT-KEYプロジェクトに高優先度のバグ課題を作って」のような依頼から、「repo-nameのオープンなプルリクエストを一覧して」まで、1つの接続で幅広くカバーします。
このMCPサーバーはNulabが開発しMITライセンスで公開していますが、公式サポートや動作保証は付いていません。業務利用の前に、この位置づけを踏まえておくと導入判断がしやすくなります。
導入方法を選ぶ — Docker / npx / Node.jsの3通り
導入方法は3つあり、どれも最終的に同じMCPサーバーを起動します。
| 方法 | 向く場面 | 特徴 |
|---|---|---|
| Docker | 向く場面◎ 初回導入・環境を汚したくない場合 | 特徴--pull alwaysで常に最新イメージを取得 |
| npx | 向く場面◎ Node.js環境が既にある場合 | 特徴インストール不要でそのまま起動 |
| 手動セットアップ(Node.js) | 向く場面△ ソースを読みたい・カスタマイズしたい場合 | 特徴pnpmでclone・build・実行 |
もっとも手間がかからないのはnpxです。事前にDockerを用意する必要がなく、claude mcp add一発で接続できます。
claude mcp add --transport stdio \
--env BACKLOG_DOMAIN=your-domain.backlog.com \
--env BACKLOG_API_KEY=your-api-key \
backlog -- npx backlog-mcp-serverDockerで動かす場合は次の形になります。イメージは ghcr.io/nulab/backlog-mcp-server として公開されています。
claude mcp add --transport stdio \
--env BACKLOG_DOMAIN=your-domain.backlog.com \
--env BACKLOG_API_KEY=your-api-key \
backlog -- docker run --pull always -i --rm \
-e BACKLOG_DOMAIN -e BACKLOG_API_KEY \
ghcr.io/nulab/backlog-mcp-serverBACKLOG_DOMAIN には接続先のBacklogドメイン(your-domain.backlog.com)、BACKLOG_API_KEY にはBacklog側で発行したAPIキーを指定します。APIキーはBacklogの個人設定画面から発行でき、詳しい認証方式はBacklog公式の認証ドキュメントにAPIキー方式とOAuth 2.0方式の2種類がまとまっています。
接続できたかは claude mcp list で確認します。✔ Connected と表示されれば準備完了です。
ツールセットを絞って権限とコンテキストを制御する
全ツールセットを有効にしたままだと、Claudeが読み込むツール定義が増え、コンテキストを圧迫します。--enable-toolsets で必要なツールセットだけに絞ると、この負荷を抑えられます。
| ツールセット | 内容 |
|---|---|
| space | 内容スペース設定・所属ユーザー情報 |
| project | 内容プロジェクト・カテゴリ・カスタムフィールド管理 |
| issue | 内容課題とコメント、マイルストーン管理 |
| wiki | 内容Wikiページの閲覧・作成 |
| git | 内容Gitリポジトリとプルリクエスト |
| notifications | 内容通知の取得・既読管理 |
| document | 内容ドキュメントツリーの閲覧 |
コードレビュー用途に絞るなら --enable-toolsets git,issue で十分です。読み取り専用の利用に留めたいときは、Claude Code側の権限設定で書き込み系ツールを個別に止める方法もあります。
Backlogのツールは get_issue や delete_project のように操作ごとに名前が分かれているため、読み取り系だけ許可して書き込み系は確認を求める、といった細かい制御が可能です。同じMCP経由の連携でも、操作を1つのツールにまとめて公開する設計のサービスでは、この粒度の制御ができないことがあります。kickflowのMCPサーバーがその例で、読み取りと書き込みが同じツール名を通るため、ツール単位の許可設計だけでは操作の種類を区別できません。
複数のMCPサーバーを同時に運用しているチームでは、ツールの説明文が似通っていて、Claudeがどちらを呼ぶべきか迷うことがあります。Backlog MCPサーバーは .backlog-mcp-serverrc.json というホームディレクトリ配置の設定ファイルで、各ツールの説明文を上書きする機能を持っています。「PROJECT-KEY形式のキーを必ず使うこと」のような社内ルールをツールの説明自体に埋め込んでおくと、依頼のたびに毎回書かなくてもClaudeがルールを踏まえて動くようになります。
公式サポートなしという条件をどう扱うか
前述のとおり、このMCPサーバーはMITライセンスで無保証・無公式サポートという条件付きで公開されています。個人利用であれば大きな問題にはなりませんが、業務の中核フローに組み込む場合は運用面の判断がもう一段必要です。
具体的には、更新のたびに動作確認をしてから導入する、バージョンを固定して意図しないタイミングでの自動更新を避ける、障害時の代替手段(Backlogの画面から直接操作する経路)を残しておく、といった対応が現実的です。GitHubのIssueを事前に眺めておくと、既知の不具合や制限を把握したうえで導入判断ができます。
これはBacklog MCPサーバーに限った話ではなく、コミュニティ主導で公開されているMCPサーバー全般に共通する前提です。公式ベンダーが直接メンテナンスしているコネクタと、有志が保守しているMCPサーバーとでは、障害時に頼れる窓口の有無が根本的に違います。導入前にこの区別を意識しておくと、後から運用方針を見直す手間を減らせます。
チームで共有する・複数組織にまたがる場合
個人の.envではなく、チーム全員が同じBacklog接続を使いたい場合は claude mcp add に --scope project を付けて .mcp.json に設定を残すと、リポジトリを開いたメンバー全員が同じ接続を再利用できます。
複数のBacklogスペース(組織)を横断して使う場合は、マルチ組織対応の環境変数を使います。組織ごとに BACKLOG_ORG_<NAME>_DOMAIN と BACKLOG_ORG_<NAME>_API_KEY を設定し、BACKLOG_DEFAULT_ORG で既定の組織を指定します。ツール呼び出し時に organization パラメーターを渡せば、指定した組織に処理が振り分けられます。単一組織のときはこのパラメーターが公開されないため、通常利用ではツール定義のサイズが増える心配はありません。
セルフホストでMCPサーバーをネットワーク越しに公開する場合は、--transport http でStreamable HTTPに切り替え、OAuth 2.0認証を有効にする構成も用意されています。この構成では利用者ごとに自分のBacklogアカウントで認証するため、APIキーをチームで使い回さずに済みます。ただし対応は単一組織のみで、複数組織構成とは併用できません。仕組みの詳細はリモートMCPのOAuth認証で扱っています。
よくあるつまずき
claude mcp listで✘ Failed to connectと出る:BACKLOG_DOMAINにプロトコル(https://)を含めていないか確認します。ドメイン部分だけを渡す仕様です- プロジェクトキーを指定しているのに「見つからない」と言われる: Backlogのプロジェクトキーは大文字が基本です。小文字で依頼すると解決に失敗することがあります
- 一覧取得の結果が途中で切れる: 大きなレスポンスは既定で5万トークンに制限され、超えると切り詰められます。
MAX_TOKENS環境変数で上限を調整するか、--optimize-responseで必要なフィールドだけに絞ります - 他のMCPサーバーとツール名が衝突する:
--prefix backlog_を付けると、get_projectがbacklog_get_projectのように名前空間が分かれ、衝突を避けられます - 接続はできるがツールが呼ばれない: 権限設定で該当ツールが
denyになっていないか、/permissionsで確認します。切り分けの手順はMCPサーバーに接続できないときの切り分け手順にまとめています - Dockerで
--pull alwaysが使えない環境がある: 社内ネットワークの制限で毎回のpull取得ができない場合は、docker pull ghcr.io/nulab/backlog-mcp-server:latestを手動で実行してから、--pull alwaysを外した設定に切り替えます - HTTPトランスポートに切り替えたら他の端末から届かない: 既定のバインド先は
127.0.0.1(ローカルホスト)です。他の端末やリバースプロキシ経由で公開する場合は--http-allowed-hostsを明示しないと接続が拒否されます
よくある質問
BacklogのAPIキーはどこで発行しますか
Backlogの個人設定画面から発行します。APIキー方式のほかにOAuth 2.0方式もあり、どちらを使うかは利用形態(個人利用か、チームで共有するリモートサーバーか)で選びます。
無料プランのBacklogでも接続できますか
MCPサーバー自体はBacklogのプランを問わず、APIアクセスができるアカウントであれば接続できます。プランごとの機能制限(プロジェクト数やユーザー数の上限)はBacklog本体の契約に依存します。
課題の削除も自然言語で頼めますか
delete_issue ツールが有効なら技術的には可能です。誤操作を防ぎたい場合は、権限設定でこのツールだけ ask(確認を求める)や deny(拒否)に設定しておくと安全です。
複数のBacklogプロジェクトを同時に扱えますか
同じ組織内であれば、プロジェクトキーを指定するだけで複数プロジェクトを横断して操作できます。別の組織(スペース)にまたがる場合は、マルチ組織対応の設定が必要です。
Backlogの画面と内容がずれることはありますか
MCPサーバーはBacklogのAPIをそのまま呼び出しているため、取得内容は画面表示と基本的に一致します。ただし大きな一覧はトークン上限で切り詰められることがあるため、件数が多い一覧では「全件取得できているか」を意識しておくと安心です。
まとめ
Backlog MCPサーバーは、npx・Docker・手動セットアップの3通りで導入でき、ツールセットや権限の絞り込みによってコンテキストと操作範囲の両方を制御できます。公式サポートがない前提を踏まえたうえで、権限設計とつまずきどころを押さえておけば、日常の課題管理をClaudeとの会話に持ち込めます。