Claude Media
CircleCI/Buildkite/Jenkins MCP比較 — CI失敗診断
Claude CodeMCP解説

CircleCI/Buildkite/Jenkins MCP比較 — CI失敗診断

CI失敗の自動診断をClaudeに任せるとき、CircleCI・Buildkite・JenkinsのMCP提供形態の違いを比較し選び方を示します。

読了目安 約9分

CIが落ちたときの一次診断をClaudeに任せられるかは、ツール側がMCPをどう提供しているかで変わります。同じ「ログを読んで原因を特定する」作業でも、認証の仕組みも導入の手間もツールごとに違うため、選定を誤ると診断のたびに余計な手順が増えます。CircleCI・Buildkite・Jenkinsは同じ「CI失敗をAIに調べさせる」目的でも提供形態が異なり、CircleCIは公式CLIへの統合を軸に、Buildkiteは独立したスタンドアロンサーバーとして、Jenkinsはプラグインとして本体に組み込む形で対応します。

CircleCI/Buildkite/Jenkinsの提供形態を比較する

CircleCIは2つのMCPサーバーを公式に提供しています。ホステッド版はCircleCIが運用するリモートサーバーで、インストール不要でOAuth2または個人トークンから接続します。もう1つのCLI統合版はCircleCI CLIに組み込まれたローカルプロセスで、circleci auth loginの認証情報をそのまま使います。旧来のmcp-server-circleci(npmパッケージ)は非推奨になっており、この2系統への移行が案内されています。

Buildkiteは公式スタンドアロンサーバーbuildkite-mcp-serverが中心です。Dockerイメージ(buildkite/mcp-server)・Homebrew・Goのソースビルドいずれかで配布され、BUILDKITE_API_TOKENを使ってローカルで起動します。HTTPモードで動かす場合はヘッダーパススルー機能があり、呼び出し元ごとに別のBuildkite APIトークンを使わせることもできます。CircleCIと同じくOAuth認証のリモート版も別途用意されています。

Jenkinsだけは仕組みが異なります。jenkinsci/mcp-server-pluginをJenkins本体にインストールすると、Jenkins自身がMCPサーバーとして振る舞います。追加のプロセスやトークン管理は不要で、Jenkinsの既存ユーザーアカウント(APIトークン + Basic認証)がそのままMCP接続の認証情報になります。

どの軸で選ぶべきか

3つの評価軸で違いが出ます。

  • 認証の独立性: MCP専用のトークンを別発行できるか、既存の認証をそのまま流用するか
  • 展開単位: 個人のローカル環境で完結するか、チーム共有のサーバーとして立てられるか
  • 設定の手間: 追加のプロセス管理が要るか、既存インフラに載せるだけで済むか

CircleCIとBuildkiteは、MCP用に専用トークンを発行しスコープを絞れます。Jenkinsは既存のJenkinsアカウント権限がそのままAIの操作範囲になるため、閲覧専用アカウントを別途作るといった運用でスコープを絞る必要があります。この3軸は独立ではなく、認証の独立性が低いほど設定の手間も減るという反比例の関係にある点も見ておくと選びやすくなります。

3つを比較する

項目CircleCIBuildkiteJenkins
提供形態CircleCIホステッドMCP + CLI統合MCPの2系統Buildkite公式スタンドアロンサーバー(バイナリ/Docker)JenkinsJenkins本体に組み込むプラグイン
インストールCircleCInpx、またはCircleCI CLI必須Buildkitebuildkite/mcp-server(Docker)/ Homebrew / go installJenkinsJenkinsのプラグイン管理からインストール
認証CircleCI個人トークンまたはOAuth2BuildkiteBuildkite APIトークン(HTTPモードはヘッダーパススルー可)JenkinsJenkinsのAPIトークン + Basic認証
失敗ログ調査ツールCircleCIget_build_failure_logs / get_job_test_results / find_flaky_testsBuildkitesearch_logs / tail_logs / read_logsJenkinsgetBuildLog / searchBuildLog
再実行ツールCircleCIrerun_workflowBuildkiteretry_job / rebuild_buildJenkinstriggerBuild

CircleCIのfind_flaky_testsのように不安定なテストを履歴から検出するツールは、他の2つには見当たりません。逆にJenkinsのgetBuildChangeSets(SCM変更点の取得)は、ビルド設定側の変更まで含めて追える点が独自です。表の5項目だけでも、どのツールが単なるログ閲覧を超えた診断支援を持つかが見えてきます。

起動コマンドの違いを見比べる

権限の話を離れて、実際の起動手順を並べると提供形態の違いがさらにはっきりします。

# CircleCI(CLI統合版、ローカルプロセスとして起動)
claude mcp add circleci-mcp-server \
  -e CIRCLECI_TOKEN=your-circleci-token \
  -- npx -y @circleci/mcp-server-circleci@latest
 
# Buildkite(スタンドアロンサーバー、Dockerで起動)
docker run --pull=always -q -it --rm \
  -e BUILDKITE_API_TOKEN=<api-token-value> \
  buildkite/mcp-server stdio

CircleCIとBuildkiteはどちらも起動時に専用トークンを渡す点が共通していますが、Jenkinsにはこれに相当する起動コマンドがありません。プラグインをインストールした時点でJenkins自身の<jenkins-url>/mcp-server/mcpが有効になり、既存のJenkinsアカウントで接続するだけです。

診断以外に効くツールの違い

失敗ログの調査以外にも、3つには他にないツールがあります。CircleCIのfind_underused_resource_classesはコスト最適化を目的に低使用率のジョブを検出するツールで、失敗診断そのものではありませんが、CI基盤の運用改善まで一続きでAIに任せられる例です。Buildkiteのget_job_envはジョブの環境変数を取得でき、環境差分が原因の失敗を切り分ける場面で役立ちます。

Jenkinsは運用監視の面でも独自です。プラグイン自体が/mcp-health(認証不要のヘルスチェック)と/mcp-server/metrics(接続数などの統計)という専用エンドポイントを持ち、MCP接続がJenkins側から見て健全かどうかをAIとは別に監視できます。他の2つにはこの種の自己監視エンドポイントはありません。

Jenkinsはさらに、SSE・Streamable HTTP・Stateless HTTPという3つの接続方式を切り替えられる点でも他の2つと違います。公式はStreamable HTTPを推奨していますが、SSEを使う場合はJenkins標準のWinstone(組み込みJetty)のキープアライブ設定を延長しないと、長時間接続がタイムアウトで切断される問題が起きます。リバースプロキシ配下で動かす自己ホスト製品ならではの調整が要る点は、ホステッド版を選べるCircleCIやBuildkiteには無い手間です。

リモート接続のトークン有効期限も違う

ホステッド・リモート型のMCPを使う場合、トークンの有効期限にも差があります。BuildkiteのリモートMCPサーバーはOAuth認証を使い、発行されるトークンは12時間で失効する短命設計です。CircleCIのホステッド版もOAuth2をサポートしますが、公式ドキュメントに明示された失効時間はなく、個人トークンでの接続も選べます。Jenkinsは自己ホストが前提のため、この種の短命トークンという概念自体がなく、発行したAPIトークンは明示的に失効させるまで有効なままです。

短命トークンを持つBuildkiteは、うっかり漏洩したときの被害時間を構造的に抑えられる一方、セッションが切れるたびに再認証の手間が発生します。逆にJenkinsは再認証の手間はありませんが、漏洩したトークンをそのままにすると被害が長引くリスクを運用側の失効管理でカバーする必要があります。

CLI統合版を選ぶ前提条件

CircleCIのCLI統合版を使うには、事前にcircleciコマンド自体をインストールし、circleci auth loginで認証を済ませておく必要があります。ホステッド版のようにトークンひとつで即座に始められるわけではなく、CLIのセットアップ自体が前提条件になっている点は選定時に見落としやすいポイントです。設定ファイルの検証を行うconfig_helperのように、CLI統合版でしか使えないツールを使う予定があるなら、この前提条件を先に済ませておく必要があります。

それぞれの強みと弱み

CircleCI — 診断専用のホステッド版とCLI統合版を選べる

強みは用途で使い分けられることです。日々の障害調査だけならホステッド版でインストールなしに始められ、設定ファイルの検証やOrb管理まで含めるならCLI統合版に切り替えられます。弱みは旧mcp-server-circleciが非推奨化された影響で、古い手順を参照すると廃止予定の実装に行き着く点です。

Buildkite — トークンを呼び出し元ごとに分離できる柔軟性

強みはHTTPモードのヘッダーパススルーで、共有サーバーを立てながら利用者ごとに異なるBuildkite APIトークンを使わせられることです。チームで1台のMCPサーバーを共有する構成に向きます。弱みはローカルサーバーの立ち上げとトークン管理を自分たちで運用する必要がある点で、Jenkinsのように既存インフラに乗せるだけでは済みません。

Jenkins — 追加インフラ不要だが権限はJenkinsの設定次第

強みはプラグインを入れるだけでよく、別プロセスの起動やトークン発行の仕組みを新たに用意しなくて済むことです。弱みはAIの操作範囲がJenkinsの既存アカウント権限にそのまま連動する点です。閲覧専用のスコープに絞りたい場合、AI専用の閲覧限定アカウントをJenkins側で別途作成する運用が前提になります。

CI失敗診断でどう使い分けるか

状況おすすめ度理由
CircleCIの日々の障害調査だけを自動化したいおすすめ度◎ CircleCIホステッド版理由インストール不要で調査系ツールに絞られている
CircleCIの設定ファイル作成やOrb管理も任せたいおすすめ度○ CircleCI CLI統合版理由CLIの全機能にアクセスできる
複数人でBuildkite MCPサーバーを共有したいおすすめ度◎ Buildkite(HTTPモード + ヘッダーパススルー)理由呼び出し元ごとにトークンを分離できる
Jenkinsに新規インフラを足したくないおすすめ度◎ Jenkinsプラグイン理由本体にインストールするだけで動く
Jenkinsで閲覧専用にAIの権限を絞りたいおすすめ度△ Jenkinsプラグイン + 閲覧限定アカウント理由権限分離は自前のアカウント設計が前提になる

診断のその先 — PRの自動修正まで任せる場合

本記事が扱うのはCI失敗を読み取って原因を調べるところまでです。GitHub PR上の失敗を検知して修正コミットまで自動化したい場合は、CircleCI/Buildkite/Jenkinsのどれを使う場合でもClaude Code autofix-prでPRのCI失敗を自動修正するが次の工程にあたります。診断ツール以外にも用途別のMCPサーバーを探しているならおすすめMCPサーバー10選、セルフホスト環境への配布経路はClaude Codeセルフホスト環境にMCPサーバーを届ける3つの経路にまとめてあります。

まとめ

CircleCIは用途に応じてホステッド版とCLI統合版を選べる柔軟さが特徴で、Buildkiteはトークンを呼び出し元ごとに分離できる点が独自です。Jenkinsは追加インフラなしで導入できる代わりに、権限管理を自分たちで設計する前提が付きます。CI失敗診断だけを最小構成で任せたいならホステッド版やスタンドアロンサーバー、既存の権限体系を崩したくないならJenkinsのプラグイン、という優先順位で選ぶと迷いが減ります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →