Backlog MCP は、Nulab が公式に提供する Backlog 用のMCPサーバーです。AIクライアントから課題（Issue）の検索・作成・更新、Wiki の読み書き、Git のプルリクエスト操作などができます。本記事では v0.18.0 を実際に起動し、62ツール・11,710トークンという常駐コストと、ENABLE_TOOLSETS でそれを半減できることを実測しました。あわせて、認証情報なしでは起動すら拒否するという設計を、同じ方法で測った他の2サーバーと比較します。
30秒でわかる Backlog MCP
・Nulab公式（nulab/backlog-mcp-server・MIT・TypeScript）。日本語READMEあり。v0.18.0 は 2026-08-12
・実測 62ツール・42,447バイト・11,710トークン。1ツールあたり189トークンで、測った3サーバー中もっとも効率的
・ENABLE_TOOLSETS=issue で 6,301トークン（46%減）。space だけなら873トークン
・認証情報なしでは起動しない（終了コード1）。Notion・Blender は起動してツール一覧まで返したので設計方針が違う
・ENABLE_DYNAMIC_TOOLSETS は削除済み。指定しても警告が出るだけで効果なし
MCPサーバーの仕組み自体はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。本記事は既製サーバーを繋いで測る側の話です。
Backlog MCPとは——Nulab公式のプロジェクト管理MCP連携
Backlog は Nulab が提供する国産のプロジェクト管理サービスです。Backlog MCP Server はその公式MCPサーバーで、AIエージェントから Backlog のデータを読み書きできるようにします。
| 項目 | 実測値（2026-08-27） |
|---|---|
| リポジトリ | nulab/backlog-mcp-server（公式org配下） |
| star / fork | 227 / 66 |
| ライセンス | MIT |
| 実装言語 | TypeScript |
| 最新リリース | v0.18.0（2026-08-12） |
| 最終push | 2026-08-24 |
| オープンIssue | 21件 |
| 公開開始 | 2025-04-16 |
| npm | backlog-mcp-server（node_modules 実測 25MB） |
Backlog は国内のSIer・受託開発・社内情報システム部門で広く使われているため、「AIエージェントに社内の課題管理を触らせる」という用途が現実的に成立する数少ないSaaSのひとつです。課題の一覧取得や起票をAIに任せられると、進捗まとめや起票の下書きといった定型作業がそのまま削れます。
star 227 という数字を過小評価しないでください。 対象ユーザーが Backlog 利用者に限られるため絶対数は伸びませんが、リリース間隔（v0.16.0 → v0.18.0 が2日間）と最終pushの新しさは、活発にメンテナンスされていることを示しています。日本語READMEが用意されている点も、国内利用を前提にした運用の表れです。
READMEが挙げる機能は、プロジェクト・課題・課題コメント・バージョン/マイルストーン・Wiki・Gitリポジトリ/プルリクエスト・通知の各操作に加えて、「Field selection for optimized responses」「Token limiting for large responses」です。レスポンス側のトークン最適化を明示的に機能として掲げているMCPサーバーは多くないので、この点は後段で確かめます。
Backlog MCP のインストールと接続手順
READMEが推奨するのは Docker です。npm パッケージも公開されているので、Node で直接動かすこともできます。
Docker で動かす場合
READMEが最初に案内するのは Docker です。MCPクライアントの設定に docker run を直接書く形になります。ローカルに Node 環境を用意せずに済み、バージョンをイメージタグで固定できるのが利点です。一方で、コンテナ起動のオーバーヘッドが毎回かかる点と、環境変数の受け渡しが1段増える点はトレードオフになります。Node が既に入っているなら、次に示す npm 経由のほうが取り回しは楽です。
必要なもの
・Backlog アカウントと、API が有効なスペース
・Backlog の個人設定から発行する APIキー
・スペースのドメイン（example.backlog.jp や example.backlog.com）
npm で動かす場合
npm install [email protected]
BACKLOG_DOMAIN="example.backlog.jp" \
BACKLOG_API_KEY="your-api-key" \
node node_modules/backlog-mcp-server/build/index.js
Claude Code への登録は次のとおりです。
claude mcp add backlog \
--env BACKLOG_DOMAIN=example.backlog.jp \
--env BACKLOG_API_KEY=your-api-key \
-- node /path/to/node_modules/backlog-mcp-server/build/index.js
複数スペースを使う場合
エラーメッセージから、複数組織の設定形式が読み取れます。
Configure either BACKLOG_ORG_<NAME>_DOMAIN and BACKLOG_ORG_<NAME>_API_KEY
with BACKLOG_DEFAULT_ORG, or both BACKLOG_DOMAIN and BACKLOG_API_KEY.
組織ごとに BACKLOG_ORG_<NAME>_DOMAIN / BACKLOG_ORG_<NAME>_API_KEY を定義し、BACKLOG_DEFAULT_ORG で既定を選ぶ形です。単一スペースなら BACKLOG_DOMAIN と BACKLOG_API_KEY の2つで足ります。複数スペースの切り替え動作そのものは、本記事では未検証です（ダミー認証情報での起動確認までしか行っていません）。
なお README を読むと、この MCP サーバーは OAuth にも対応しています。/.well-known/oauth-authorization-server（RFC 8414）、/.well-known/oauth-protected-resource/mcp（RFC 9728）、POST /register（RFC 7591 動的クライアント登録）を実装し、登録できるリダイレクトURIを制限する記述もあります。ループバックURI（http://localhost 等）は application_type: native を宣言したクライアント、あるいは全リダイレクトURIがループバックであるクライアントからのみ受け付ける、という設計です。★227規模のサーバーとしては丁寧な実装です。OAuthモードの実動作は未検証です。
【実測】認証情報なしでは起動しない——3サーバーで挙動が割れた
MCPサーバーが認証情報なしでどう振る舞うかを、同じ手順（stdio で initialize → tools/list）で3つ測りました。
Backlog MCP を環境変数なしで起動すると、MCPのハンドシェイクに到達する前にプロセスが落ちます。
{"level":50,"err":{"type":"Error","message":"Configure either
BACKLOG_ORG_<NAME>_DOMAIN and BACKLOG_ORG_<NAME>_API_KEY with
BACKLOG_DEFAULT_ORG, or both BACKLOG_DOMAIN and BACKLOG_API_KEY."}}
終了コードは 1。initialize すら成功しません。
一方、同じ検証をした他の2サーバーはどちらも起動しました。
| サーバー | 認証情報なしで initialize |
認証情報なしで tools/list |
実際の呼び出し |
|---|---|---|---|
| Backlog MCP | 失敗（exit 1） | 到達不能 | — |
| Notion MCP（ローカル版） | 成功 | 成功・24ツール全部 | 401 |
| Blender MCP | 成功 | 成功・25ツール全部 | 接続エラー |
3つの分岐を1本の流れにすると、止まる位置の違いが見えます。
Backlog MCP だけが起動時点で fail-closed です。他の2つは「一覧は fail-open、実行は fail-closed」でした。
どちらが優れているという単純な話ではありません。fail-open 側には「クライアントの設定画面でツールが見えるので接続確認しやすい」という利点があり、fail-closed 側には「設定ミスが即座に分かる」「認証されていないのにトークンだけ消費する状態にならない」という利点があります。ただし運用の事故を減らすという観点では、起動時に落ちるほうが安全側です。Notion MCP と Blender MCP では、トークンを渡し忘れていてもツール一覧は正常に見えるため、実際に呼ぶまで壊れていることに気づけません。
Notion 側の詳しい挙動はNotion MCPとは｜ホスト版とローカル版の違いを24ツール・21,831トークン実測で解説に、Blender 側はBlender MCPとは｜25ツール6,480トークンとテレメトリ既定ONを実測で確かめるにまとめています。
【実測】62ツールで11,710トークン——3サーバー比較で見える設計差
ダミーの認証情報（example.backlog.jp / dummy）を渡すと起動し、tools/list が取れました。APIキーの正当性は起動時には検証されないため、ツール定義の計測はこれで可能です。
| 項目 | 実測値 |
|---|---|
| ツール数 | 62 |
| バイト数 | 42,447 |
| トークン数 | 11,710 |
| 説明文のバイト数 | 2,216 |
同じ方法で測った3サーバーを並べると、設計の差がはっきりします。
| サーバー | ツール数 | トークン | 1ツールあたり |
|---|---|---|---|
| Notion MCP（ローカル版 v2.5.1） | 24 | 21,831 | 910 |
| Blender MCP（v1.8.7） | 25 | 6,480 | 259 |
| Backlog MCP（v0.18.0） | 62 | 11,710 | 189 |
Backlog MCP は最もツール数が多いのに、1ツールあたりのコストが最も小さいという結果でした。Notion MCP の2.6倍のツールを持ちながら、総トークンは約半分です。
理由は引数設計にあります。Backlog MCP の最軽量ツールは 50〜52トークンしかありません。
| ツール | トークン |
|---|---|
get_issues（最重） |
1,167 |
count_issues |
1,018 |
update_issue |
734 |
get_priorities（最軽） |
50 |
get_resolutions |
51 |
get_myself |
52 |
get_priorities や get_resolutions は引数を取らないので、名前と短い説明だけで済みます。対して get_issues は24個のフィルタ引数（projectId / statusId / assigneeId / createdSince / dueDateUntil など）を持つため1,167トークンかかります。
Notion MCP のローカル版は、最軽量のツールでも749トークンでした。 OpenAPI 定義から機械生成しているため、どのツールにも共通の巨大なスキーマがぶら下がるからです。Backlog MCP は手書きで、必要な引数だけを定義しています。MCPサーバーのコストはツール数ではなく引数設計で決まるという結論が、3サーバーの実測で再現しました。
【実測】ENABLE_TOOLSETS でトークンを半減させる
Backlog MCP には、実測した3サーバーの中で唯一、ツールセット単位で機能を絞る仕組みがあります。ENABLE_TOOLSETS 環境変数（または --enable-toolsets フラグ）です。
利用できるツールセットは7つです。
| ツールセット | 内容 |
|---|---|
space |
スペース設定・全体情報 |
project |
プロジェクト・カテゴリ・カスタムフィールド・課題種別 |
issue |
課題とコメント・バージョン/マイルストーン |
wiki |
Wikiページ |
git |
Gitリポジトリ・プルリクエスト |
notifications |
通知 |
document |
ドキュメント・ドキュメントツリー |
実際に指定して測りました。
| 設定 | ツール数 | バイト数 | トークン | 既定比 |
|---|---|---|---|---|
| 既定（全部） | 62 | 42,447 | 11,710 | — |
ENABLE_TOOLSETS=issue |
27 | 22,656 | 6,301 | -46% |
ENABLE_TOOLSETS=issue,project |
33 | 26,171 | 7,209 | -38% |
ENABLE_TOOLSETS=git |
10 | 8,127 | 2,209 | -81% |
ENABLE_TOOLSETS=space |
6 | 2,805 | 873 | -93% |
課題管理だけに使うなら issue で十分で、それだけで46%減ります。 Git 連携を別のMCPサーバーに任せているなら、git を外すだけでも効きます。
BACKLOG_DOMAIN="example.backlog.jp" \
BACKLOG_API_KEY="your-api-key" \
ENABLE_TOOLSETS="issue,wiki" \
node node_modules/backlog-mcp-server/build/index.js
効かない環境変数に注意
ENABLE_DYNAMIC_TOOLSETS という似た名前の環境変数がありますが、これは既に削除されています。指定して起動しても、ツール数は62のまま変わりませんでした（1 でも true でも同じ）。
実装を確認すると、この変数はもう警告を出すためだけに残っています。
Dynamic toolsets have been removed, and --dynamic-toolsets /
ENABLE_DYNAMIC_TOOLSETS no longer do anything. Every toolset is enabled
unless you narrow it with --enable-toolsets or ENABLE_TOOLSETS.
この警告は stderr にしか出ないため、MCPクライアント経由だと目に触れないことがあります。古い記事や設定例をコピーして ENABLE_DYNAMIC_TOOLSETS を書いていると、削減しているつもりで全ツールが載ったままになります。正しい変数名は ENABLE_TOOLSETS です。
レスポンス側の最適化と、実務上の注意点
READMEが掲げる「Field selection」「Token limiting」は、ツール定義ではなくレスポンスに効く機能です。実装には --optimize-response と --max-tokens に対応するコードがあり、大きなレスポンスを切り詰められる構成になっています。これらのフラグの実効果は、実データを返す必要があるため本記事では未検証です（有効なAPIキーとスペースが要ります）。
ツール一覧を眺めていて気づいた点を2つ挙げます。
命名が1か所だけ揺れています。 62ツール中61個が get_issue / add_wiki のようなスネークケースなのに対し、addDocument だけがキャメルケースです。動作に影響はありませんが、ツール名をハードコードするときは取り違えやすいので注意してください。
62ツールという数はAIの選択精度にも効きます。 トークンコストとは別の話として、似た名前のツールが並ぶとAIがどれを呼ぶべきか迷いやすくなります。Backlog MCP には get_issue（単一取得）・get_issues（一覧）・count_issues（件数）が並んでおり、「課題がいくつあるか」を聞かれたときに一覧を全件取ってから数える、といった非効率な経路を選ぶ余地があります。ENABLE_TOOLSETS で絞る動機は、コスト削減だけでなくAIの迷いを減らすことにもあります。
書き込み系ツールが既定で全部有効です。 delete_project / delete_issue / delete_version / update_issue といった破壊的な操作が、既定のツールセットに含まれます。MCPには「読み取り専用モード」の標準的な仕組みがないため、AIに書き込みをさせたくない場合はツールセットを絞るだけでは不十分です。issue ツールセットには delete_issue も含まれます。読み取り専用で使いたいなら、APIキー側の権限を絞るのが確実です。Backlog のAPIキーには権限設定があるので、そちらで制御してください。
APIキーはMCPクライアントの設定ファイルに平文で載ります。 claude mcp add --env BACKLOG_API_KEY=... のような登録方法を取ると、キーが設定ファイルに残ります。Backlog のAPIキーはスペース全体に対する権限を持つため、リポジトリにコミットされる場所へ設定を置かないでください。チームで設定を共有する場合は、キーだけを各自の環境変数から読ませる形にするのが安全です。
バージョン固定を検討する価値があります。 v0.16.0 から v0.18.0 まで2日間でリリースされている速度感で、ENABLE_DYNAMIC_TOOLSETS のように機能が削除される変更も実際に起きています。業務のワークフローに組み込むなら、[email protected] のように版を固定し、更新はリリースノートを見てから行うほうが安定します。
もう1点、運用上の判断材料として。MCPサーバーを繋ぐ数だけ固定費が積み上がります。 本記事で測った3つを全部繋ぐと、それだけで 21,831 + 6,480 + 11,710 = 約40,000トークンが毎セッション消費されます。ENABLE_TOOLSETS のような絞り込み機構を持つサーバーは、この観点で明確に有利です。
どんなチームに向くか
向くのは、Backlog を既に日常的に使っていて、進捗確認や起票の手数を減らしたいチームです。「先週更新された課題を要約して」「このバグを起票して、担当を私にして」といった指示が自然言語で通るようになります。62ツールが Backlog API のほぼ全域をカバーしているので、機能不足で困る場面は少ないはずです。
慎重になるべきなのは、AIに書き込み権限を渡すことへの合意が取れていないチームです。前述のとおり削除系ツールが既定で有効で、MCP側に読み取り専用モードがありません。まずはAPIキーの権限を読み取りのみに絞って導入し、運用が固まってから書き込みを開放する順序が無難です。
まとめ
・Backlog MCP は Nulab公式（MIT・TypeScript・日本語READMEあり）。v0.18.0・最終push 2026-08-24 と活発
・実測 62ツール・42,447バイト・11,710トークン。1ツールあたり189トークンで、測った3サーバー中もっとも効率的
・ENABLE_TOOLSETS=issue で6,301トークン（-46%）、space のみなら873トークン（-93%）
・ENABLE_DYNAMIC_TOOLSETS は削除済み。stderr に警告が出るだけで効果はなく、削減したつもりの設定ミスになりやすい
・認証情報なしでは起動しない（exit 1）。Notion・Blender は起動して全ツールを一覧できたので、設計方針が明確に違う
・削除系ツールが既定で有効。読み取り専用にしたいならAPIキー側の権限で絞る
MCP 連携のコストは「どのサーバーを繋ぐか」だけでなく「どこまで絞れるか」で決まります。tools/list を1回取って数える——それだけで、自分の設定が実際に何トークン積んでいるかは確認できます。
参照ソース
- nulab/backlog-mcp-server — 公式リポジトリ。README のツールセット一覧・OAuthエンドポイント仕様（2026-08-27 参照）
- backlog-mcp-server — npm — v0.18.0 の配布状況（2026-08-27 参照）
- 配布物
build/index.js（v0.18.0） —ENABLE_DYNAMIC_TOOLSETSの廃止処理・--optimize-response/--max-tokensの実装（2026-08-27 実測） - Backlog API リファレンス（Nulab公式） — APIキーの発行と権限（2026-08-27 参照）
