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

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

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

読了目安 約13分

CIが落ちたときの一次診断をClaudeに任せられるかは、ツール側がMCPをどう提供しているかで変わります。ログを読んで原因を探る作業は同じでも、サーバーの置き場所・認証・権限の絞り方がツールごとに違います。CircleCIとBuildkiteはベンダーがホストするリモートサーバーを持ち、Jenkinsはプラグインで自分のサーバーがMCPを話す形です。

提供形態

MCPサーバーはどこで動くか

  • CircleCI

    ホステッド版(https://mcp.circleci.com/v1/mcp)と、CircleCI CLIに内蔵されたローカル版の2系統です。npxで入れる旧ローカルサーバーは非推奨になっています。

  • Buildkite

    OAuth方式のリモート版(https://mcp.buildkite.com/mcp)が推奨です。APIトークン方式のリモート版と、自分で動かすローカル版もあります。

  • Jenkins

    jenkinsci/mcp-server-pluginを入れると、Jenkins本体が/mcp-server/mcpなどのエンドポイントでMCPを受け付けます。

診断だけならどの構成が軽いか

失敗の調査だけが目的なら、CircleCIとBuildkiteは「インストールなしで始める」か「既存の認証をそのまま使う」かのどちらかで足ります。Jenkinsはプラグインを入れる必要があります。違いが出るのは、その先の権限と運用です。

CircleCIのホステッド版は、失敗の調査と再実行に絞った道具立てです。get_job_logsは、ステップを指定しないと失敗したステップを自動で読みます。list_job_testsは既定で失敗したテストだけを返します。rerun_workflowはfrom_failedを指定すると、失敗したジョブとその下流だけを再実行します。

Buildkiteは、診断向けの集約ツールを持つ点が特徴です。get_build_failure_summaryは問題のあるジョブ、ログの末尾、エラーと警告のアノテーション、取得できる失敗テストを1回の呼び出しでまとめます。結果は部分的な場合があり、欠けたログや切り詰められた証拠がないかを見てから結論を出す前提です。wait_for_buildは1回の呼び出しで最長45秒だけ待ち、ブロック中のビルドは完了扱いにして人の入力待ちを報告します。

Jenkinsのプラグインは、getBuildLog(ページング付きの読み出し)とsearchBuildLog(文字列・正規表現で検索)でログを読みます。テスト結果はgetTestResults、変更セットはgetBuildChangeSetsでそのビルドに入った変更セットも引けます。

項目CircleCIBuildkiteJenkins
認証CircleCIOAuth2または個人APIトークンBuildkiteOAuth、またはAPIトークンJenkinsJenkinsのAPIトークン + Basic認証
ログ調査CircleCIget_job_logs / list_job_testsBuildkitesearch_logs / tail_logs / read_logsJenkinsgetBuildLog / searchBuildLog
再実行CircleCIrerun_workflowBuildkiteretry_job / rebuild_buildJenkinsrebuildBuild / triggerBuild

認証と権限をどこで絞るか

AIに渡す権限の絞り方が、3つの最も大きな違いです。

くらべる

トークンの渡し方と寿命

短命

Buildkite(OAuthリモート)

OAuthのアクセストークンは12時間、リフレッシュトークンは7日間有効です。読み書き両方のスコープが付くため、閲覧だけにしたいときはhttps://mcp.buildkite.com/mcp/readonlyを使います。

アカウント権限そのまま

Jenkins

Jenkinsの既存アカウントのAPIトークンで接続します。AIの操作範囲はそのアカウントの権限と同じなので、閲覧専用の運用なら閲覧権限だけのアカウントを別に作ることになります。

CircleCIはOAuth2を推奨しています。サインインに既存のアカウントを使うのでトークンを保管せずに済み、CircleCI側で失効や更新ができるためです。個人APIトークンは、MCPホストがOAuth2を完了できない場合や、ヘッドレスな自動実行向けの選択肢という位置づけです。

Buildkiteで自動実行の側に回ると事情が変わります。OAuthは対話的なサインインが前提なので、ヘッドレスなエージェントには向きません。その場合のために、https://mcp.buildkite.com/directが用意されています。Authorization: Bearer <トークン>ヘッダーでAPIトークンを渡すと、トークンのスコープが呼べるツールを決めます。このエンドポイントのリクエストは、組織のREST APIレート制限とは別に、ユーザーあたり毎分50リクエストの枠で数えられます。

注意したいのは、読み取り専用の接続でもAIの権限全体が絞れるわけではない点です。Buildkiteの公式ページは、MCPの読み取り専用接続が制限するのはその接続だけだと明記しています。シェルと別途認証したbk CLIを持つエージェントは、そのCLIの権限で変更できます。

実際の接続コマンドを見る

Claude Codeでは、リモート型もローカル型もclaude mcp addで登録します。v2.1.289のclaude mcp add --helpは、HTTPサーバーとstdioサーバーの両方の例を出力します。

$ claude --version
2.1.289 (Claude Code)
 
$ claude mcp add --help
  # Add HTTP server with headers:
  claude mcp add --transport http corridor https://app.corridor.dev/api/mcp
--header "Authorization: Bearer ..."
 
  # Add stdio server with environment variables:
  claude mcp add my-server -e API_KEY=xxx -- npx my-mcp-server

この2つの書式に、各ツールの接続先を当てはめると次のようになります。CircleCIのホステッド版はOAuth2で、/mcpでAuthenticateを選んでブラウザーでサインインします。

# CircleCI ホステッド版(OAuth2)
claude mcp add --transport http circleci-mcp-server https://mcp.circleci.com/v1/mcp
 
# Buildkite リモート版(OAuth)
claude mcp add --transport http buildkite https://mcp.buildkite.com/mcp
 
# Buildkite ローカル版(Docker、APIトークン)
claude mcp add buildkite-local -e BUILDKITE_API_TOKEN=<api-token-value> \
  -- docker run --pull=always -q -i --rm -e BUILDKITE_API_TOKEN buildkite/mcp-server stdio

CircleCI CLI内蔵版は、circleci auth login(またはCIRCLE_TOKEN)で認証します。circleci mcp claude enableはClaude Desktop向けで、Cursorはcursor enable、VS Codeはvscode enableです。Claude Codeには、上のホステッド版をclaude mcp addで登録します。ほかのクライアントは、circleci mcp start(stdio)またはcircleci mcp stream(HTTP)で起動します。

Jenkinsは、接続先が自分のJenkinsです。README記載のとおりAPIトークンとユーザー名をBase64にしてBasic認証のヘッダーに載せます。

手順

JenkinsをClaude Codeにつなぐ

  1. 1

    プラグインを入れる

    mcp-server-pluginをJenkinsにインストールします。追加の設定なしで、エンドポイントとツールが有効になります。

  2. 2

    APIトークンを作る

    Jenkinsのユーザー設定でトークンを生成します。画面を離れると再表示できないので、その場で保管します。

  3. 3

    Basic認証の値を作る

    echo -n "<username>:<token>" | base64の出力を、Authorization: Basicヘッダーの値にします。

  4. 4

    サーバーを登録する

    Streamable HTTPのエンドポイントを登録します。claude mcp add --transport http jenkins <jenkins-url>/mcp-server/mcpに、--header "Authorization: Basic <値>"を付けます。

Jenkinsだけにある運用の落とし穴

自己ホスト型のJenkinsには、ホステッド版にはない調整点があります。

エンドポイントは3つで、すべて既定で有効です。SSEは/mcp-server/sse、Streamable HTTPは/mcp-server/mcp、Statelessは/mcp-server/statelessです。READMEはStreamable HTTPを推奨しています。SSEは長時間つながったままの接続なので、アイドルタイムアウトの影響を受けます。

SSEを使う場合、Jenkins標準のWinstone(組み込みJetty)はhttpKeepAliveTimeoutが30秒で、プラグインのkeep-alive ping(既定30秒間隔)と同じ間隔です。READMEによると、pingが届く前にJettyが接続を閉じる競合が起きうるため、起動引数に--httpKeepAliveTimeout=600000を足す構成が示されています。この競合はSSE限定です。

Nginxの背後に置くなら、proxy_read_timeoutなどを600秒に延ばします。Streamable HTTPで効くのはこちらのほうです。長く走るツール呼び出し(遅いtriggerBuildなど)が既定の短いタイムアウトを超えると、504が返りえます。

監視用のエンドポイントも別に付きます。<jenkins-url>/mcp-healthは認証不要で、サーバーの状態と接続数を返し、シャットダウン中は503になります。<jenkins-url>/mcp-server/metricsは通常のJenkins権限を要求し、SSE接続数などの統計を返します。

Originヘッダーの検証にも既定の動きがあります。Originが付いていれば、JenkinsのルートURLと照合します。付いていないリクエストは通すので、Originを送らないAIエージェントもそのまま動きます。付いていないリクエストも拒否したいときは、requireOriginHeader=trueを指定します。

再実行や変更系のツールを渡す前に

診断だけのつもりでも、再実行系のツールが入っていれば、AIは本物のCIの状態を変えられます。CircleCIの概要ページは、ワークフローの再実行とキャンセルは実際のCIの状態を変えるので、共有プロジェクトや本番に近いプロジェクトでは実行前に内容を確かめるよう案内しています。

Buildkiteのツール一覧は、もう一段具体的です。create_buildはdestructiveHint: falseでも、ビルドを開始してパイプラインのコマンドを実行します。retry_jobとunblock_jobはdestructiveHint: trueです。このヒントを読み取り専用の判定に使わないよう、公式が注意しています。

Buildkiteで失敗を見張らせるには、プロンプトで明示する必要があります。MCPサーバーをつなぐだけでは、AIはビルドを監視しません。例として、ビルドを指定して「読み取り専用の呼び出しだけで、失敗したら理由をリンク付きで要約して」と頼む文面が載っています。短い「Babysit this build.」だけでは、変更系のツールを禁じたことにはなりません。

Jenkinsは、パラメーター付きビルドの扱いに範囲があります。triggerBuildが完全に対応するのはString・Boolean・Choice・Text・Password・Runの各パラメーターで、ファイルパラメーターはMCP経由では使えません。未対応のパラメーターは既定値に戻されます。ログはgetBuildLogの返す行数に上限(既定10000行)があり、システムプロパティで変えられます。getSystemLogは、Overall/SystemRead権限が必要です。

Buildkiteのサーバーは開発が続いていて、ツールの動作が変わったり削除されたりすることがあります。特定のツールや動作に頼る自動実行では、バージョンを固定したDockerイメージのタグか、バイナリのバージョンを使う選択肢が示されています。

選び方の早見表

状況向く構成理由
CircleCIの障害調査と再実行だけ任せたい向く構成CircleCIホステッド版理由インストール不要で、OAuth2で接続できる
設定ファイルの検証やOrb管理まで任せたい向く構成CircleCI CLI内蔵版理由CLIの全コマンドがツールになる
個人のBuildkite調査向く構成Buildkite OAuthリモート版理由トークンを保管せず、更新も自動で入る
パイプラインの中でBuildkite MCPを使う向く構成ローカル版かトークン方式リモート版理由対話的なOAuthを使えない。固定したいならローカル版(トークン方式リモート版は固定不可)
Jenkinsに追加インフラを足したくない向く構成Jenkinsプラグイン理由本体に入れるだけで動く
Jenkinsで閲覧だけにしたい向く構成プラグイン + 閲覧限定アカウント理由権限分離をアカウント設計で作る

CircleCIのCLI内蔵版を選ぶ判断は、「資格情報を開発者のマシンに置きたいか」でも分かれます。CircleCIの概要ページは、組織が認証情報をリモートサーバーに送らず手元に置く方針なら、CLI内蔵版が向くと説明しています。

診断のその先と、他のMCPサーバー

ここまでは、CI失敗を読み取って原因を調べる段階の比較です。GitHub PR上の失敗を検知して修正コミットまで自動化する次の工程は、Claude Code autofix-prでPRのCI失敗を自動修正するにまとめています。

診断ツール以外のMCPサーバーを探すならおすすめMCPサーバー10選が入口です。セルフホスト環境への配布経路はClaude Codeセルフホスト環境にMCPサーバーを届ける3つの経路が手がかりになります。

まとめ

CI基盤をまだ決めていないなら、権限を細かく絞れるかどうかが比較の軸になります。すでにどれかを使っているなら、CircleCIとBuildkiteではOAuth接続から始めてヘッドレスな自動実行だけトークン方式に分ける形が基本です。Jenkinsは認証がAPIトークンだけなので、AIに渡すアカウントの権限設計が運用の中心になります。

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

関連する記事

Claude Code をもっと見る →