BacklogのMCPサーバーを公開しました

by Teruo Kunihiro

2025/05/07

Backlog / Development / TechBlog

こんにちは、生成AIチームのテリーです。このたびGitHub上にて、BacklogのMCP（Model Context Protocol）サーバーの実装を公開しました！ 🎉
👉 GitHubリポジトリはこちら

このMCPサーバーを使えば、ClineなどのAIエージェントとBacklogを直接つなぐことが可能になります。たとえば、

「このプロジェクトの課題を一覧で教えて」
「特定のメンバーが対応中の課題をピックアップして」
「新しいタスクを作成して」

といった操作を、自然言語だけで簡単に行えるようになります。

今回の開発に関してAIをフルに使いました。開発体験に関するブログはこちらになりますので興味ある方は合わせて読んでください。

MCPサーバーとは？

「MCPサーバーって何？」という方も多いと思います。
MCPは、LLM（大規模言語モデル）がREST APIなどの多種多様なインターフェースを扱いやすくするための“共通インターフェース”です。

通常のREST APIは、エンドポイントやパラメータの構造がツールごとにバラバラで、LLMから扱うには不向きな場合があります。また、多くのAPIにはdescriptionがないため、LLMがその役割を理解するのも困難です。

MCPサーバーはこれらの課題を解決し、統一されたスキーマ定義（Zodなど）とインターフェースで、LLMから外部の世界への透過的なアクセスを可能にします。

同じような世界観を実現するSDK（異なる仕様を繋げるためのライブラリ）という発想もあるかと思いますが、SDKを全てのAIエージェントに組み込むよりも、専用のMCPサーバーを外部プロセスに委託しユーザーがプラグイン的に利用できた方が簡単に利用ができます。ただ現時点ではプログラミングスキルの知識がある方でないと利用は難しい印象です。

よくある例としてはUSB-Cがあります。数ある接続端子の仕様をUSB-Cに統一して接続端子の違いを気にせず様々なデバイスを繋げられる🧩。どのLLMからでも、どのサービスにもつながる未来を目指しているようです。

公式サイトに載っている概念図

開発背景

世間の流れもあり、MCPサーバーは多くの企業で公開されています。中にはインターネット越しにホストされているものもあります。

Nulab社としてもユーザーのローカル環境で動くものを提供して、AI x Backlogの利用をより簡単にしてもらえるようにしたいと考え今回の開発に至りました。

またMCPサーバーはローカル環境で起動するものなので、いろんなMCPサーバーがある中公式からの提供の方がより安心感を持ってもらえるのではないかと考えました。

参考にしたもの

開発にあたっては、以下のドキュメントやOSSを参考にしました。

全体的に情報のアップデートが早く、AIの持っている知識がついていけなかった部分があったので公式のドキュメントや実装はかなりの部分で参考にしました。

MCPサーバーを開発するうえで工夫した点

1. 既存コードの活用

公式のTypeScriptのクライアント（backlog-js）を土台にして、API接続の部分はなるべく再発明しないことを心がけました。

2.セキュリティについて

Docker での提供。 npxで提供されているMCPサーバーが多いですが、なるべくユーザーの環境に影響させたくなかったので、サンドボックス環境での提供をファーストにしました。

3. テスト

TypeScriptのSDKの例では副作用の分離ができてないのでtoolに対してテストが書きにくい状態でした。

以下のように各Tool定義に副作用の発生するBacklogクライアントとi18nの仕組みを外部から渡すようにしました。これにより各toolに対してテストの作成が楽になりました。以下イメージ:

export const addIssueTool = (backlog, { t }) => { ... }

tool以外の部分でもなるべく、副作用のあるものを分離し閉じ込めるように意識しました。

4. 保守性の向上

なるべく単純な関数を組み合わせることでシステムを構築しました。wrap関数で機能を分割・組み合わせ、宣言的なコードと高いテスト網羅性を両立しています。

ファクトリパターン、ストラテジーパターン、DIなども効果的に利用しました。

5. OSSとしての整備

MITライセンス
- 会社としての公式なMCPサーバーなので、もちろん責任を持って作成しております。しかしながら会社のサポートチームなどに迷惑をかけるわけにはいかなかったので、MITライセンスとして動作保証を行っておりません。後述しますが何かおかしな挙動が起きた際にはGitHub上で起票いただけると助かります。
わかりやすいREADMEと構成図
- バイブコーディングの記事でもあるように今回の開発においてほとんどのドキュメント作成をAIに行ってもらいました。もちろん英語を詳しく読んでいくとおかしな章ができてたり、意図しないものが吐き出されたりしたのですが、基本的にはAI以前なら考えられない分量のものを簡単に出力することができました。READMEの作成は開発者的にはめんどくさい割に非常に重要なアウトプットであるためとても助かりました。
GitHub ActionsによるCI
- GitHub Actionsとの相性の良さを考えてDockerイメージのレジストリにGitHub Packagesを採用しました。基本的にローカルからはPublishすることはなくGitHub Actionsでのリリースに一元化することでメンテナンスコストを下げています。
memory-bankを使ったLLM向けのドキュメント構造の工夫
- これはClineの機能になりますが、かなり強力に感じました。Mermaid記法でのシステムの流れなどが詳細に記述されていて、もちろん結局はコード見ないとわかりにく部分もあるのですが、これを読めば今何を作っていてどんな構成なのか、一発でわかります。LLM向けのドキュメント整理のはずが開発者の役にも立っています。実際のファイルはこちらから確認できます

6. AIの活用

ドキュメント生成
初期コードの設計
テストコードのドラフト
実装時の壁打ち

AIと共に作業を進めることで、短期間でのリリースが実現しました。

そんなに規模の大きいコードではないですが、このスパンで開発できたのはAIのおかげでした。今後も業務でAIを最大限使って、なるべく仕事の生産性をあげたいと思います。

7. 大きすぎるコンテキストへの対応

今回MCPサーバーを開発していて感じたのは、APIのレスポンスサイズが大きすぎるということでした。AI的には必要ないレスポンスが含まれていたりしてもAIエージェントは無視せず一旦全てをAI（LLM）の中に放り込みます。

また巨大なレスポンスについても同じでAIエージェント側でトリムなどすることはせず、ナイーブにContext Windowの上限まで使ってしまうようでした。

ここに対応するのはMCPサーバーの責務なのかどうなのかは現時点ではわからないのですが、以下のポイントでMCPサーバー側で対応することにしました:

JSONの中で必要のないプロパティかどうかをAIエージェント側がプログラムで判断するのが難しい
MCPサーバーからもらった文字列の長さをクライアントサイドで制限する方が良いとは思うが、現時点で幾つかのクライアントで問題が起きてるため対応せざるをえない

ということで対応を行いました。やったこととしては2つ:

GraphQLライクな fields 指定で必要な情報のみ取得可能に
トークン数上限を超えると自動カットする仕組みを追加

ナイーブにレスポンスを返すのと比べ改善したとは思いますが、何せ実験的な機能のため追加のフラグで制御しています。Claude Desktopなどトークンの制限が厳しい環境ではぜひ以下の起動オプションをお試しください。

"env": {
        "BACKLOG_DOMAIN": "your-domain.backlog.com",
        "BACKLOG_API_KEY": "your-api-key",
        "MAX_TOKENS": "10000",
        "OPTIMIZE_RESPONSE": "true"
}

サポートについて

本プロジェクトはMITライセンスで提供されており、Nulabからの公式サポートはありません。ただし、開発者として責任を持ってメンテナンスを行っています。

ご質問・不具合などあれば、ぜひお気軽にGitHub Issueまでご連絡ください！

最後に

今回のMCPサーバー公開を通じて、AIとBacklogがより自然につながる世界の第一歩を踏み出せたと思っています。
MCPサーバーとAIの利用を通じてAIとBacklogでどんな便利なことができるのか。みなさまに実験してもらえるかと思うとワクワクしています。

例えば家庭用のBacklogスペースで「このプロジェクトを分析して」とAIにたのむときっちりとまとめてくれました。以下抜粋です。

今後もアップデート・改善を継続していきますので、GitHubのStarやWatchもよろしくお願いします！